JP2017225155A - データ通信システム - Google Patents

Abstract

【課題】ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、可聴音声の再生成のために信号を送信するよう構成された送信機とを含み、ショートコードはグローバルに一意なものである、デバイスを提供する。
【解決手段】サーバを使用して、ショートコードとデータとの間の関連付けを格納する。ユーザデバイスは、第２のユーザデバイスへのショートコードの送信に使用する。次いで、第２のユーザデバイスは、サーバで関連付けにアクセスし、データにアクセスする。ショートコードは、２つのデバイス間で可聴的に一意な信号を介して送信される。また、すべて音声を使用した、バウチャを引き換えるため、送信するため、デバイス上のコンテンツのロックを解除するため、トランザクションを認証する。
【選択図】図６

Description

本発明は、データ通信の分野である。しかし、具体的には、本発明は、限定的にではなく、モバイルデバイスとのデータ通信のやり取りに関する。

データを物理的環境に組み込むための多くの既存の方法があり、短縮ＵＲＬまたはテキストコード、ＱＲコード(登録商標)、バーコードおよびＲＦＩＤコードの非動的な視覚的表示を含む。

ポスターや他の活字メディアは、一般には、既に、ｂｉｔ．ｌｙなどのＵＲＬ短縮サービスからのＵＲＬおよび／またはショートコードのテキスト形式を含む。これらの活字コードを使用するには、活字コードをウェブブラウザに入力しなければならない。これらのテキスト形式は、ＵＲＬを保持するため、ペンもしくは鉛筆または優れた記憶力を必要とする。これは、記憶が難しい英数字の文字列を使用するｂｉｔ．ｌｙなどの現行のＵＲＬ短縮サービスにおいて特に問題となり得る。記憶しやすいコードを使用する代替のショートコーディングサービスはあるが、利用可能な記憶しやすいコードは限られる可能性があることが理解されよう。

ＱＲコード(登録商標)は、比較的多量のデータ（１Ｋ）をピクトグラフで表すための方法である。コードは、マーカーがどのタイプの符号化を含むかを示すヘッダと、ペイロードとを含む。コードは、完全なＵＲＬまたは他のデータペイロード、例えば、小さな画像を符号化できるほど十分大きい。ＱＲコード(登録商標)の主な欠点は、それらは視覚的に比較的大きいこと、コードを認識できるようにするためにコードをカメラの間近に示す必要があること、低光量またはカメラが移動している場合に復号ステップが失敗する可能性があること、および、コードは人間が読み取れるものではないことを含む。人間にとっては、２つの異なるコードが区別できるものであることは視覚的に分からない。

一般的な印刷コードの中では、バーコードは、定着したコード化メカニズムである。コードの意味論は、国際規格によって定義される。異なるウェブリソース（例えば、ＣｕｅＣａｔ）にコードをマッピングするオンラインサービスがある。しかし、バーコードは、ＱＲコード(登録商標)の不利な点の多くを共有する。

ＲＦＩＤ（無線自動識別）タグは、人が携帯することも、物体に取り付けることもできる、物理的デバイスにコードを組み込む方法である。ＲＦＩＤを読取端末に近づけると、コードを受動的に読み取ることができる。この受動的なまたは半受動的なコード読み取りは、ユーザの挙動に対して許容性がある（例えば、カードと読取機との一般的な近接関係がトランザクションを容易にするのに十分である）ため、状況によっては極めて魅力的である（例えば、オイスターカード）。しかし、ユーザがＲＦＩＤタグを作成するための簡単なツールはなく、消費者では通常入手できないハードウェアが必要とされる。

また、オンラインデバイス間には、多くのデータ転送技術がある。例えば、Ｅメール、Ｔｗｉｔｔｅｒなどのインターネットサービスを使用することができる。これらのサービスのいくつかは、ユーザが受信者の識別子を知っている必要がある。その上、これらのインターネットサービスは、データ転送の発生を確認するため、両者のデバイスがある時点でオンライン状態である必要がある。したがって、これらのサービスを非同期的に使用する能力はない。例えば、Ｅメールまたは他の任意のウェブサービスでは、オフライン状態の場合、着手した時点で、将来的にデータ転送が完了するという保証はない。すなわち、Ｅメールはキューに登録されるが、一度も送信されないことも、デバイスの盗難にあうこともあり得る。

モバイルデバイス間でのピアツーピア転送の場合、最も広く普及されている技術は、Ｂｌｕｅｔｏｏｔｈ(登録商標)である。これは、２つのデバイス間の高帯域幅チャネルである。しかし、有用性の問題があり、それに従って、名目上は多くのデバイス上で利用可能であるにもかかわらず、ユーザに広く敬遠されている。例えば、データ転送を可能にするための異なるプロトコルを有する異なるデバイスでの２つのデバイスの対形成の同期化は成り行き次第である。

また、本質的にはＲＦＩＤタグと読取機の技術を一緒に組み合わせた近距離無線通信（ＮＦＣ）の規格も増えている。この技術は、Ｂｌｕｅｔｏｏｔｈ(登録商標)の競合相手である。１つの利点は、アクティブデバイスが静的なＲＦＩＤタグを模倣できるようになることである（例えば、携帯電話がオイスターカードを「模倣」できる）。これは、デバイスが、多くの支払およびセキュリティアクセスシステムを含むすべての既存のＲＦＩＤ読取システムと相互作用できるようになることを意味する。ＮＦＣのプロトタイプは存在するが、この技術は、ユーザが新しいハンドセットやデバイスを手に入れる必要がある。現在のところ、この技術を備えた消費者デバイスは未だ少ししか販売されていない。ＮＦＣが大きな市場シェアを占めるに至るには、３〜５年かかる可能性がある。

本発明の目的は、先行技術の不利な点を克服するデータを通信するためのシステムを提供するか、または、少なくとも役に立つ代替手段を提供することである。

本発明の第１の態様によれば、データを送信するためのデバイスにおいて、
サーバからデータと関連付けられたショートコードを受信するよう構成された受信機と、
ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のために信号を送信するよう構成された送信機とを含み、ショートコードはグローバルに一意なものである、デバイスを提供する。

可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。一部の信号は、ショートコードの何れも符号化しない場合があり、信号の可聴音声の再生成の美的または独特の性質を改良するためだけのデータを含み得る。それに加えて、一部の信号は、冗長性を符号化することができる。ショートコードは、アプリケーションヘッダを含み得る。ショートコードは、データのインデックスであり得る。デバイスは、モバイルテレコミュニケーションデバイス用のコントローラであり得る。

受信機は、モバイルテレコミュニケーションネットワーク上でショートコードを受信するよう構成することができる。

ショートコードは、既定の固定長のものであり得る。ショートコードは、３２〜１０２４ビットであり得る。信号は、音楽記述言語形式であり得る。信号は、ＭＩＤＩ形式であり得る。信号は、冗長符号化を含み得る。信号は、冗長性に対してリードソロモン符号を使用することができる。

データは、ＵＲＬであり得る。

デバイスは、送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイスと、データをサーバに送信するよう構成されたトランシーバとをさらに含み得る。

本発明のさらなる態様によれば、データを受信するためのデバイスにおいて、
マイクロホンで検出された音声信号を受信するよう構成された受信機と、
音声信号をショートコードに復号するよう構成されたデコーダと、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含み、ショートコードはグローバルに一意なものである、デバイスを提供する。

音声信号は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。ショートコードは、アプリケーションヘッダを含み得る。デバイスは、アプリケーションヘッダを読み取り、アプリケーションヘッダに応じてショートコードの処理を決定するよう構成されたプロセッサをさらに含み得る。

ショートコードは、データのインデックスであり得る。

デバイスは、モバイルテレコミュニケーションデバイス用のコントローラであり得る。

トランシーバは、モバイルテレコミュニケーションネットワーク上でデータにアクセスするよう構成することができる。

ショートコードは、既定の固定長のものであり得る。ショートコードは、３２〜１０２４ビットであり得る。

デコーダは、ピッチ追跡を使用して音声信号の復号を補助することができる。

データは、ＵＲＬであり得る。データにアクセスするステップは、データをデバイスに回収するステップを含み得る。音声信号は、第１の態様のデバイスから受信することができる。デバイスは、音声信号を受信した際にショートコードおよび／または音声スペクトルを表示するよう構成されたディスプレイをさらに含み得る。

本発明のさらなる態様によれば、データを非同期送信するためのデバイスにおいて、
サーバからショートコードを受信するよう構成された受信機と、
受信したショートコードを格納するよう構成されたメモリと、
受信したショートコードをデータと関連付けるよう構成されたプロセッサと、
受信したショートコードを第２のデバイスに送信するよう構成された送信機と、
関連付けをサーバに送信するよう構成された送信機と
を含む、デバイスを提供する。

デバイスは、受信したショートコードを送信する際、サーバに接続できない可能性がある。

受信したショートコードは、ダイレクトインターフェース上で第２のデバイスに送信することができる。

ダイレクトインターフェースは、音声インターフェースであり得る。

デバイスと第２のデバイスは、並置することができる。

デバイスは、関連付けをサーバに送信する前に、ショートコードを受信し、次いで、送信することができる。

デバイスは、送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイスをさらに含み得る。

本発明のさらなる態様によれば、データを送信するためのサーバにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサと、
関連付けを格納するよう構成されたメモリと、
ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のためにデバイスに信号を送信するよう構成された送信機とを含み、
ショートコードはグローバルに一意なものである、サーバを提供する。

可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。

ショートコードは、アプリケーションヘッダを含み得る。

ショートコードは、データのインデックスであり得る。

送信機は、モバイルテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。

送信機は、モバイルテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。

信号は、着信音としてＳＭＳチャネル上で送信することができる。

ショートコードは、既定の固定長のものであり得る。ショートコードの長さは、３２〜１０２４ビットであり得る。

信号は、音楽記述言語形式であり得る。

信号は、ＭＩＤＩ形式であり得る。

信号は、冗長符号化を含み得る。

信号は、冗長性に対してリードソロモン符号を使用することができる。

データは、ＵＲＬであり得る。

サーバは、デバイスから送信するデータを受信するよう構成された受信機をさらに含み得る。

デバイスは、モバイルテレコミュニケーションデバイスであり得る。

サーバは、第２のデバイスからショートコードを受信するよう構成された受信機と、受信したショートコードと関連付けられたデータへのアクセスを第２のデバイスに提供するよう構成されたプロセッサとをさらに含み得る。

データへのアクセスは、第２のデバイスにデータを送信するステップを含み得る。

本発明のさらなる態様によれば、データを非同期送信するためのサーバにおいて、
メモリにショートコードを保存するよう構成されたプロセッサと、
保存したショートコードをデバイスに送信するよう構成された送信機と、
保存したショートコードとデータとの関連付けを受信するよう構成された受信機と、
保存したショートコードとデータとの関連付けを格納するよう構成されたメモリと、
第２のデバイスから要求を受信するよう構成された受信機において、要求は保存したショートコードを含む、受信機と、
要求をデータと関連付けるよう構成されたプロセッサと
を含む、サーバを提供する。

本発明のさらなる態様によれば、データを送信するためのデバイスにおいて、
第１の態様のデバイスまたは第４の態様のサーバによって生成された信号を格納するよう構成されたメモリと、
格納された信号から音声信号を生成するよう構成された音声出力と
を含む、デバイスを提供する。

本発明のさらなる態様によれば、トランザクションを認証するためのデバイスにおいて、
ユーザから認証入力を受信するよう構成された入力デバイスと、
ユーザ識別情報を格納するよう構成されたメモリと、
ユーザ識別情報および認証入力を可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のために信号を送信するよう構成された送信機と
を含む、デバイスを提供する。

エンコーダは、デバイス位置およびデバイス識別子のセットからの１つまたは複数を信号に符号化するようさらに構成することができる。デバイス識別子は、ＩＭＥＩ（国際移動体装置識別番号）であり得る。

本発明のさらなる態様によれば、トランザクションを認証するためのデバイスにおいて、
マイクロホンから、上記の態様で主張されるように、第２のデバイスによって生成された信号を受信するよう構成された受信機と、
信号からユーザ識別情報および認証データを復号し、ユーザ識別情報および認証入力に基づいて第２のデバイスを認証するよう構成されたプロセッサと
を含む、デバイスを提供する。

信号は、デバイス位置およびデバイス識別子のセットからの１つまたは複数を用いてさらに符号化することができる。デバイス識別子は、ＩＭＥＩであり得る。

プロセッサは、第２のデバイスの履歴およびユーザ識別情報のユーザがデバイスのユーザのソーシャルネットワーク内にいるかどうかのセットからの１つまたは複数を参照しても、第２のデバイスを認証することができる。

本発明のさらなる態様によれば、データを送信するための方法において、
ａ）サーバからデータと関連付けられたショートコードを受信するステップと、
ｂ）ショートコードを可聴的に一意な形式の信号に符号化するステップと、
ｃ）可聴音声の再生成のために信号を送信するステップとを含み、ショートコードはグローバルに一意なものである、方法を提供する。

本発明のさらなる態様によれば、データを送信するための方法において、
ａ）ショートコードをデータと関連付けるステップと、
ｂ）ショートコードを可聴的に一意な形式の信号に符号化するステップと、
ｃ）可聴音声の再生成のためにデバイスに信号を送信するステップとを含み、ショートコードはグローバルに一意なものである、方法を提供する。

本発明のさらなる態様によれば、データを送信するための方法において、
メモリに格納された信号から音声信号を生成するステップにおいて、格納された信号は２つの前態様の何れかの方法によって以前に生成される、ステップ
を含む、方法を提供する。

本発明のさらなる態様によれば、データを受信するための方法において、
ａ）マイクロホンを介して音声信号を受信するステップと、
ｂ）音声信号をショートコードに復号するステップと、
ｃ）ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするステップとを含み、ショートコードはグローバルに一意なものである、方法を提供する。

本発明のさらなる態様によれば、データを非同期送信するための方法において、
ａ）サーバからショートコードを受信するステップと、
ｂ）デバイス上に受信したショートコードを格納するステップと、
ｃ）受信したショートコードをデータと関連付けるステップと、
ｄ）受信したショートコードを第２のデバイスに送信するステップと、
ｅ）関連付けをサーバに送信するステップと
を含む、方法を提供する。

本発明のさらなる態様によれば、データを非同期送信するための方法において、
ａ）ショートコードを保存するステップと、
ｂ）保存したショートコードを第１のデバイスに送信するステップと、
ｃ）保存したショートコードとデータとの関連付けを受信するステップと、
ｄ）保存したショートコードとデータとの関連付けを格納するステップと、
ｅ）第２のデバイスから要求を受信するステップにおいて、要求は保存したショートコードを含む、ステップと、
ｆ）要求をデータと関連付けるステップと
を含む、方法を提供する。

本発明のさらなる態様によれば、トランザクションを認証するための方法において、
ａ）入力デバイスを介してユーザから認証入力を受信するステップと、
ｂ）ユーザ識別および認証入力を可聴的に一意な形式の音声信号に符号化するステップと、
ｃ）可聴音声の再生成のために音声信号を送信するステップと
を含む、方法を提供する。

本発明のさらなる態様によれば、データを通信するためのシステムにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
関連付けを格納するよう構成されたメモリ
を含むサーバと、
ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
スピーカ、および、
スピーカ上での可聴音声の再生成のために信号を送信するよう構成された送信機
を含む第１のデバイスと、
マイクロホン、
マイクロホンで検出された音声信号を受信するよう構成された受信機、
音声信号をショートコードに復号するよう構成されたデコーダ、および、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
を含む第２のデバイスと
を含み、
ショートコードはグローバルに一意なものである、システムを提供する。

サーバは、エンコーダを含み得る。あるいは、第１のデバイスは、エンコーダを含み得る。

本発明のさらなる態様によれば、データを非同期送信するためのシステムにおいて、
サーバからショートコードの保存を要求するよう構成されたトランシーバ、
送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイス、
データとショートコードとの関連付けを生成するよう構成されたプロセッサ、
関連付けを格納するよう構成されたメモリ、
ダイレクトインターフェース上で第２のデバイスにショートコードを送信するよう構成された送信機、および、
関連付けをサーバに送信するよう構成された送信機
を含む第１のデバイスと、
ダイレクトインターフェース上で第１のデバイスからショートコードを受信するよう構成された受信機、および、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバ
を含む第２のデバイスと、
第１のデバイスからショートコードを保存するという要求を受信するよう構成された受信機、
メモリにショートコードを保存するよう構成されたプロセッサ、
保存したショートコードを第１のデバイスに送信するよう構成された送信機、
保存したショートコードとデータとの関連付けを受信するよう構成された受信機、
保存したショートコードとデータとの関連付けを格納するよう構成されたメモリ、
第２のデバイスから要求を受信するよう構成された受信機において、要求は保存したショートコードを含む、受信機、および、
第２のデバイスからの要求をデータと関連付けるよう構成されたプロセッサ
を含むサーバと
を含む、システムを提供する。

ダイレクトインターフェース上でショートコードを送信または受信する際、第１および第２のデバイスの一方または両方は、サーバにアクセスできない可能性がある。

ダイレクトインターフェースは、ダイレクト音声インターフェースであり得る。

第１および第２のデバイスは、並置することができる。

本発明のさらなる態様によれば、デバイス上のコンテンツにアクセスするためのシステムにおいて、
多数のコンテンツ要素／機能性の少なくとも１つと音声信号を一致させるため、および、デバイス上に格納された少なくとも１つのコンテンツ要素／機能性へのアクセスを提供するため、無線で直接音声信号を受信するよう構成されたプロセッサと、
多数のコンテンツ要素／機能性を格納するよう構成されたメモリと
を含む、システムを提供する。

プロセッサは、音声信号をショートコードに復号するようさらに構成することができ、音声信号は、ショートコードを使用して、コンテンツ要素／機能性と一致させる。

多数のコンテンツ要素の少なくとも１つは、マルチメディアであり得る。

コンテンツ要素は、ネットワーク接続上で定期的に受信することができる。

アクセスは、デバイスの位置、時間およびデバイスのユーザの履歴のセットから選択される１つまたは複数の制約にさらに依存し得る。

アクセスは、多数の音声信号の受信にさらに依存し得る。

本発明のさらなる態様によれば、バウチャを引き換えるためのシステムにおいて、
音声信号を送信するよう構成された第１のデバイスにおいて、音声信号はバウチャと関連付けられる、第１のデバイスと、
音声信号を受信するよう構成された第２のデバイスにおいて、複数の一意なバウチャの１つと音声信号を一致させ、バウチャを引き換えることができることを確認する、第２のデバイスと、
多数の一意なバウチャを格納するためのメモリにおいて、バウチャは一般的なバウチャである、メモリと
を含む、システムを提供する。

音声信号は、第１のデバイスのユーザに特有のユーザ識別子を含み得る。

第１のデバイスは、第３のデバイスから音声信号を受信することができる。

第１のデバイスは、無線インターフェース上で直接第３のデバイスから音声信号を受信することができる。

第２のデバイスは、音声信号をショートコードに復号するようさらに構成することができ、ショートコードを使用して音声信号を一致させる。

メモリは、第２のデバイス側に位置し得る。

第１のデバイスおよび／または第の２のデバイスは、バウチャの引き換えを確認する前に、１つまたは複数の制約に対してバウチャをチェックするようさらに構成することができ、１つまたは複数の制約は、第１のデバイスの位置、時間および引き換えられたバウチャの数のセットから選択される。

本発明のさらなる態様によれば、送金するためのシステムにおいて、
モバイルデバイスから特定の金銭的価値に対する識別子に対する要求を受信し、モバイルデバイスに識別子を返信し、識別子の有効性を確認するという要求を受信し、受信側のデバイスの口座への送金を実施する、信頼できる第三者サーバと、
受信側のデバイスから識別子の有効性を確認するという要求を受信し、第１の信頼できる第三者と通信して識別子の有効性を確認し、有効性を確認した時点で、受信側のデバイスの口座への送金を実施し、受信側のデバイスに有効性確認応答を返信する、第２の信頼できる第三者サーバと、
第１の信頼できる第三者サーバからの特定の金銭的価値に対する識別子を要求するモバイルデバイスにおいて、識別子は、デバイス上に格納され、音声として受信側のデバイスに非同期送信される、モバイルデバイスと、
音声形式で識別子を受信し、第２の信頼できる第三者サーバに識別子を送信する、受信側のデバイスと
を含む、システムを提供する。

特定の金銭的価値は、時間、位置、ベンダー、目的およびベンダーのタイプのセットから選択される１つまたは複数の制約範囲内で利用可能でも、再利用可能でもあり得る。

第１の信頼できる関係者サーバおよび第２の信頼できる関係者サーバは、並置も、同じサーバであることもあり得る。

本発明のさらなる態様によれば、モバイルデバイス上にユーザインターフェースを提供して、第２のデバイスへのデータアイテムの送信を管理するための方法において、
ａ）モバイルデバイス上のディスプレイ上にユーザに関連する多数のデータアイテムを表示するステップと、
ｂ）データアイテムの少なくとも１つを選択するユーザ入力をモバイルデバイス上で受信するステップと、
ｃ）少なくとも１つの選択されたデータアイテムを第２のデバイスに送信するための多数の通信オプションをモバイルデバイス上に表示するステップにおいて、通信オプションの少なくとも１つは、第２のデバイス上のマイクロホンによる受信のため、モバイルデバイスのスピーカから音声としてデータアイテムを送信するステップを含む、ステップと、
ｄ）通信オプションの少なくとも１つを選択するユーザ入力を受信するステップと、
ｅ）少なくとも１つの選択された通信オプションを使用して、少なくとも１つの選択されたデータアイテムを他のデバイスに送信するステップと
を含む、方法を提供する。

本発明のさらなる態様によれば、データを通信するためのシステムにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
関連付けを格納するよう構成されたメモリ
を含むサーバと、
ショートコードを一意な形式の信号に符号化するよう構成されたエンコーダと、
スピーカ、および、
スピーカ上での不可聴音声の再生成のために信号を送信するよう構成された送信機
を含む第１のデバイスと、
マイクロホン、
マイクロホンで検出された音声信号を受信するよう構成された受信機、
音声信号をショートコードに復号するよう構成されたデコーダ、および、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
を含む第２のデバイスと
を含み、
ショートコードはグローバルに一意なものである、システムを提供する。

サーバは、エンコーダを含む。あるいは、第１のデバイスは、エンコーダを含む。

本発明のさらなる態様によれば、データを送信するためのシステムにおいて、
データを第１の音声信号に符号化するよう構成されたエンコーダ、および、
第１の音声信号を可聴音声で再生成するよう構成されたスピーカ
を含む第１のデバイスと、
第２の音声信号を可聴音声で再生成するよう構成されたスピーカ、
第３の音声信号を受信するよう構成されたマイクロホン、
第２の音声信号を取り除くために第３の音声信号を処理するよう構成された信号プロセッサ、および、
処理された第３の音声信号をデータに復号するよう構成されたデコーダ
を含む第２のデバイスと
を含む、システムを提供する。

本発明のさらなる態様によれば、上記の態様の何れかの方法を実行するよう構成されたコンピュータプログラムを提供する。

本発明のさらなる態様によれば、上記の態様のコンピュータプログラムを格納するよう構成されたコンピュータ可読媒体を提供する。

本発明のさらなる態様は、特許請求の範囲内で説明する。

ここで、添付の図面を参照して、単なる例示として、本発明の実施形態について説明する。

図１は、本発明の実施形態による２つのデバイスとサーバを示すブロック図を示す。 図２は、本発明の実施形態による３つの方法を示すフロー図を示す。 図３は、本発明の実施形態によるプロトコルスタックのブロック図を示す。 図４は、本発明の実施形態によるＵＲＬ共有を示すブロック図を示す。 図５は、本発明の実施形態によるさらなるデバイスとさらなるサーバを示すブロック図を示す。 図６は、本発明の実施形態による２つの方法を示すフロー図を示す。 図７は、本発明の実施形態による非同期ＵＲＬ共有を示すブロック図を示す。 図８は、本発明の実施形態によるさらなるデバイスを示すブロック図を示す。 図９は、本発明の実施形態によるさらなる方法を示すフロー図を示す。 図１０は、本発明の実施形態による、音声を使用したデバイス上のコンテンツのロック解除を示すブロック図を示す。 図１１は、本発明の実施形態による、音声を使用したバウチャの引き換えを示すブロック図を示す。 図１２は、本発明の実施形態による、音声を使用して送金するための第１のシステムを示すブロック図を示す。 図１３は、本発明の実施形態による、音声を使用して送金するための第２のシステムを示すブロック図を示す。 図１４ａは、本発明の実施形態による、ユーザインターフェースを示すモバイルデバイス上のスクリーンショットを示す。 図１４ｂは、本発明の実施形態による、ユーザインターフェースを示すモバイルデバイス上のスクリーンショットを示す。 図１４ｃは、本発明の実施形態による、ユーザインターフェースを示すモバイルデバイス上のスクリーンショットを示す。 図１５は、本発明の実施形態による、音声を使用してデバイス間のデータ送信を不明瞭化するためのシステムを示すブロック図を示す。

本発明は、データを通信するためのデバイス、サーバ、方法およびシステムを提供する。

発明者は、スピーカとマイクロホンを使用して、並置されたデバイス（音声送信を探知できるほど近くに位置するデバイス）間で、音声形式でデータを通信できることを決定した。

発明者は、データが通信されている際に個人がそれを決定できるように、音声が人間に聞こえるものであることが望ましいことをさらに決定した。例えば、一個人がデバイスから別の個人のデバイスにデータを送信している場合に、両者が、データが送信されていることを確信していることが望ましい場合がある。

発明者は、可聴音声送信が音声に一意なものであれば望ましいことをさらに決定した。すなわち、個人は、あるセットのデータの可聴信号を別のセットのデータの可聴信号と合理的に区別することができる。

また、発明者は、上記の仕様によるデータ通信が長時間の送信をもたらすことも決定した。したがって、発明者は、データと関連付けられた参照コードまたはショートコードの使用、および、データに代わる参照コードの後続の送信を考案した。

それに応じて、本発明の一態様は、ショートコードとデータとの関連付け、可聴的に一意な形式の信号へのショートコードの符号化、および、信号の可聴音声の再生成を含み得る。信号は、検出してショートコードに復号することができ、データは、ショートコードとの関連付けを使用してアクセスすることができる。

ここで、図１〜２を参照して、上記の態様による本発明の実施形態について説明する。

受信機１０１と、エンコーダ１０２と、送信機１０３とを備え得る第１のデバイス１００が示されている。デバイス１００は、モバイルテレコミュニケーションデバイス内のコントローラであり得る。受信機１０１は、サーバ１０４からデータと関連付けられたショートコードを受信するよう構成することができる。受信機１０１は、モバイルテレコミュニケーションネットワーク上でサーバ１０４からショートコードを受信することができる。あるいは、デバイス１００およびサーバ１０４は、同じデバイス内のコントローラであり得る。

データは、ＵＲＬ、Ｅメールアドレスおよび／もしくは電話番号および／もしくは連絡者名などの連絡先、文書、口座情報、バウチャ、金融トークンなどのトークン、または、他の任意のタイプのデータであり得る。

エンコーダ１０２は、ショートコードを可聴的に一意な形式の信号に符号化するよう構成することができる。可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。音楽は、西洋の楽音の平均律を利用することも、微分音を使用することもできる。可聴的に一意な形式は、信号の可聴音声の再生成の美的または独特の性質を改良するためだけの音声を含み得、ショートコードとは関連しない。好ましい実施形態では、エンコーダ１０２は、ショートコードを信号に変換し、その結果、ショートコードデータ自体の少なくとも一部は、鳥の鳴き声および／または音楽形式に構造化される。それに加えて、信号は、信号の音声に対する一意性を改良するためおよび／または信号の可聴音声の再生成における心地良い音を改良するため、ショートコードから導出されない他の要素を含み得る。

ショートコードは、グローバルに一意なものであり得る。すなわち、各ショートコードは、データとの関連付けを１つのみ有することができる。したがって、サーバ１０４の位置をショートコード内に組み込む必要はない。したがって、ショートコードの長さを増加する必要はない。

ショートコードは、アプリケーションヘッダを含み得る。ヘッダは、サーバ１０４でまたはデバイス１００で追加することができる。ヘッダは、好ましくは、サーバ１０４を使用することなく、ショートコード内で検出可能である。

好ましくは、ショートコードは、固定長のものである。あるいは、符号化プロセスは、信号内のショートコードの長さを含む。

送信機１０３は、可聴音声の再生成のために信号を送信するよう構成することができる。好ましくは、送信機１０３は、可聴音声の再生成のために信号をスピーカに送信することができるか、またはその代替として、送信機１０３は、後の可聴音声の再生成のための通信プロトコル上で信号を伝達することができる。

代替の実施形態では、第１のデバイス１００は、ショートコードを格納するよう構成されたメモリも備え得る。この実施形態では、デバイス１００は、後にこのショートコードを回収して、可聴音声の再生成のために符号化することができる。

一実施形態では、第１のデバイス１００は、どのデータをショートコードと関連付けるかをユーザが決定することができるよう構成されたユーザ入力デバイスも備え得る。そして、第１のデバイス１００は、この関連付けをサーバ１０４に通信するためのトランシーバも含み得る。

また、第２のデバイス１０５も示されている。第２のデバイス１０５は、受信機１０６と、デコーダ１０７と、トランシーバ１０８とを備え得る。受信機１０６は、マイクロホンから音声信号を受信するよう構成される。一実施形態では、音声信号は、第１のデバイス１００によって送信されるものである。あるいは、音声信号は、事前にメモリ上に音声信号を格納するテレビ、コンピュータまたはリレーなどの別のデバイス内のスピーカから送信することができる。デコーダ１０７は、音声信号をショートコードに復号するよう構成される。トランシーバ１０８は、サーバ１０４と通信して、ショートコードを使用することによってショートコードと関連付けられたデータにアクセスするよう構成される。代替の実施形態では、第２のデバイス１０５およびサーバ１０４は、さらなるデバイス内に存在し得、音声信号は、第３のデバイスを通じて伝達することができる。

一実施形態では、データにアクセスするステップは、第２のデバイス１０５にデータを回収するステップを伴う。

一実施形態では、第２のデバイス１０５は、受信したショートコードまたは音声スペクトルなどの音声信号の表現を表示するよう構成された視覚ディスプレイをさらに備え得る。

また、サーバ１０４も示されている。サーバ１０４は、プロセッサ１０９と、メモリ１１０と、エンコーダ１１１と、送信機１１２とを備え得る。プロセッサ１０９は、ショートコードをデータと関連付けるよう構成することができる。メモリ１１０は、関連付けを格納するよう構成することができる。エンコーダ１１１は、ショートコードを可聴的に一意な形式の信号に符号化するよう構成することができる。送信機１１２は、可聴音声の再生成のために第１のデバイス１００に信号を送信するよう構成することができる。一実施形態では、サーバがエンコーダ１１１を備える場合は、第１のデバイス１００は、エンコーダ１０２を必要としない。

一実施形態では、送信機１１２は、モバイルネットワークなどのテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。信号は、例えば、着信音として、ＳＭＳチャネルまたはＭＭＳチャネル上で送信することができる。信号は、ＵＳＳＤ（非構造付加サービスデータ）として送信することができる。

サーバ１０４は、要求側のデバイスから音声信号を受信するための受信機と、音声信号をショートコードに復号するよう構成されたデコーダと、ショートコードを使用してデータにアクセスするよう構成されたプロセッサとをさらに備え得る。データにアクセスするステップは、要求側のデバイスにデータを送信するステップを含み得る。

ここで、本発明の実施形態による方法について説明する。

一方法２００では、ステップ２０１において、データと関連付けられたショートコードをサーバから受信する。ステップ２０２では、ショートコードを可聴的に一意な形式の信号に符号化する。ステップ２０３では、可聴音声の再生成のために信号を送信する。ショートコードは、データとの複数の関連付けを有さないという点において、グローバルに一意なものである。この方法は、モバイルデバイスなどの単一のデバイス上で実行することができる。

さらなる方法２０４では、ステップ２０５において、マイクロホンを介して音声信号を受信する。ステップ２０６では、音声信号をショートコードに復号する。ステップ２０７では、ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスする。この方法は、モバイルデバイスなどの単一のデバイス上で実行することができる。

さらに、さらなる方法２０８では、ステップ２０９において、ショートコードをデータと関連付ける。ステップ２１０では、ショートコードを可聴的に一意な形式の信号に符号化する。ステップ２１１では、可聴音声の再生成のためにデバイスに信号を送信する。この方法は、モバイルテレコミュニケーションネットワークとインターフェースを取るサーバなどのサーバ上で実行することができる。

当業者であれば、方法のすべてまたは少なくとも一部を１つまたは複数のコンピュータプログラム内で実施できることが理解されよう。例えば、モバイルテレコミュニケーションデバイスのための方法２００、２０４は、ｉＰｈｏｎｅ(登録商標)アプリケーション内、Ａｎｄｒｏｉｄアプリケーション内、Ｓｙｍｂｉａｎ内または他の任意のプログラミング言語内で、コンピュータプログラムコードとして作成することができる。サーバのための方法２０８は、Ｐｙｔｈｏｎ／Ｄｊａｎｇｏ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｒｕｂｙ ｏｎ ＲＡＩＬＳまたは他の任意のシステムなどの任意のコンピュータプログラミング言語、システムまたはフレームワークで作成することができる。

ここで、図３および４を参照して、本発明の実施形態について説明する。本発明のこの実施形態は、Ｃｈｉｒｐと呼ばれる。

Ｃｈｉｒｐは、少量のデータを符号化する音声を使用するピアツーピアおよびオンライン共有をサポートするプロトコルおよびアプリケーションセットを含む。この実施形態では、ピアツーピアは、物理的に並置するデバイス、通常、携帯電話／モバイルデバイスを意味し、オンラインは、ソーシャルネットワークまたは標準のウェブサービスを通じたものを意味し、少量のデータは、およそ３２〜１０２４ビットを意味し、音声は、音楽などの耳に心地良い可聴音を意味する。

代替の実施形態では、音声は不可聴である。現モバイルデバイス内のスピーカは、ほぼすべての人間の聞こえる範囲を上回る最大２０ｋＨｚまでの音声を送信することができる。いくつかの現モバイルデバイス内のマイクロホンは、最大２２ｋＨｚまでの音声を受信することができる。１８ｋＨｚを上回る音声の範囲は、ほとんどの成人には不可聴である。したがって、音声は、大部分のモバイルデバイスまたは専門スピーカによって大部分は不可聴周波数で送信することができ、大部分のモバイルデバイスによって不可聴周波数で受信することができる。可聴音声は、ユーザがデータ送信を可聴音声で確認でき、可聴音声は、商品知名度や目新しさの価値をユーザに確立するという点において有利であり得、あるデータ送信は、送信されているものをユーザが部分的に検証できるように認識可能な可聴音声を有し得る。不可聴音声は、音声が心地良いものでなくともよく、したがって、より大きなデータ圧縮率を使用できる可能性があるという点において有利であり得る。

典型的な使用例では、２つのデバイスは互いに近くに位置し、ある人物が短いデータを別の人物に「Ｃｈｉｒｐ」する。送信側のデバイスは音声を生成し、受信側のデバイスは音声を受信して復号する。この音声は、２人のユーザには可聴であり、その結果、ユーザはデータ交換が行われたことを知ることができる。転送されるデータは短い文字列であり、その文字列は、アプリケーション特有のコードもしくはウェブサービスによって生成されたショートコードの何れかであるか、または、生成された何らかの別の形式のコードである。

この特定の音声のポイントツーポイント転送は、多くの異なる大規模な相互作用に組み込むことができる。具体的には、データ転送は音声で実施されるため、音声送信が可能ないかなるデバイスも、Ｃｈｉｒｐを再生することができる。さらに、音声記録が可能ないかなるデバイスも、後のプレイバックのためにＣｈｉｒｐを記録することができる。したがって、いかなるウェブページもＣｈｉｒｐを再生することができ、マイクロホンへのアクセスを有するＦｌａｓｈまたはＪａｖａ(登録商標)アプレットなどのウェブページ上のいかなるアプレットもＣｈｉｒｐを受信することができる。Ｃｈｉｒｐは、例えば、ラジオまたはテレビのネットワークなどの任意の通信ネットワークまたはシステム上で伝達することができ、次いで、同通信ネットワークまたはシステムは、Ｃｈｉｒｐを可聴音声で再生成することができる。

基本プロトコル
プロトコルスタック
どのようにデータが転送されるかについて説明するプロトコルには３つの部分がある。
意味コード化−アプリケーション特有の意味へのショートコードの符号化３００（Ｅｓ）および復号３０１（Ｄｓ）。
データコード化−音楽記述形式へのショートコードの符号化３０２（Ｅｄ）および復号３０３（Ｄｄ）。
転送コード化−音波３０６への音楽記述の符号化３０４（Ｅｔ）および復号３０５（Ｄｔ）。

図３ではプロトコルが示されている。

プロセス３０７のアプリケーションは、ｃｈｉｒｐを要求し、アプリケーションデータを符号化プロセスＥｓに渡す。したがって、Ｅｓは、以下の関数と見なすことができる。
Ｅｓ：（Ａ，Ｂ）→Ｃ
Ａは文字列としてのアプリケーション識別子であり、Ｂは文字列としてのアプリケーションデータであり、Ｃは出力文字列である。関数Ｅｓは、プロセス３０７上でローカルに実施することができるか、または、好ましくは、ウェブサービスを利用することができる。文字列Ａは、通常、小さなアプリケーションサンプルから引き出されることになる（例えば、それはＵＲＬであり得、したがって、シンボルＡは「ＵＲＬ」であり得る）。文字列Ｂは、任意の長さのものである。ショートコードＣは、３２〜１０２４ビットの固定長のものである。固定長は、実装形態に応じて指定される。

次いで、このショートコードは、符号化プロセスＥｄによって音楽記述言語に符号化され、Ｅｄは、以下の関数と見なすことができる。
Ｅｄ：（Ｃ）→Ｄ
Ｄは音楽記述言語（ＭＤＬ）のコードのシーケンスである。ＭＤＬの一例はＭＩＤＩであり、コードはＭＩＤＩコードのシーケンスであり得る。一実施形態では、値は、単にピッチ値であるか、またはその代替手段では、ノート（音符）のボリュームまたは動的振幅の変化、ノートの長さ、音色特性を含む他の可聴パラメータ、および、可能な場合は、そのようなパラメータの連続変調であり得る。したがって、ショートコードＣは、ＡＳＣＩＩ文字の文字列として表すことができ、「音楽コード」Ｄは、ＭＩＤＩ制御コードのシーケンスであり得る。ＭＩＤＩを使用する１つの利点は、ＭＩＤＩ再生が大部分のプラットホーム上で利用可能であるかまたは利用可能にすることができる能力であることである。あるいは、デバイス特有の着信音形式を使用することができる。

音声プロセスにおける干渉に起因して復号プロセスは不明確である場合があるため（以下で論じる）、Ｅｄは、リードソロモン符号などの冗長コード化スキームを使用することができる。

符号化の最終ステップは、Ｄを音波に符号化することである。事実上、これはＭＤＬプレーヤである。
Ｅｔ：（Ｄ）→Ｅ
Ｅは、ＷＡＶなどの任意の音声形式であり得る。ＭＰ３もしくはＭＰ４またはＡＩＦＦなどの代替の音声形式も使用できることが理解されよう。

ＭＩＤＩを使用する場合、音声セットを選択することができる（すなわち、音声サンプルが実際に再生または合成される）。音声セットおよびピッチ範囲を選択して、再生成の容易性（例えば、低周波数は、通常小型の低出力スピーカを特徴とするモバイルデバイス上ではあまりうまく再生成されない）および復号目的のための検出の容易性などの音声送信および受信のある要件を満たす信号Ｅを生成することができる。

復号プロセス３０８の第１のステップは、ＭＤＬ（例えば、ＭＩＤＩ）コードへの音の復号である。
Ｄｔ：（Ｅ’）→Ｄ’
Ｅ’は、音声が追加のノイズを有し得、復号の際にバックグラウンドノイズを含み得ることを示し、したがって、Ｄ’は、ＭＤＬ（例えば、ＭＩＤＩ）コードのシーケンスであり、Ｄとは同じではない可能性がある。このＤｔプロセスは、ピッチ検出システムも含み得る。

次のステップは、このＭＩＤＩシーケンスをショートコードに復号することであり、関数Ｄｄによって実現される。符号化ステップにおいて冗長コードを使用したため、復号プロセスは、高い確率で、元のショートコードＣを返す。
Ｄｄ：（Ｄ’）→Ｃ

最終プロセスは、ショートコードを復号することである。
Ｄｓ：（Ｃ）→Ａ，Ｂ

ショートコードは、アプリケーションＡおよびアプリケーションデータＢを特定する。以前のＥｓと同様に、この復号は、アプリケーションでローカルに実施することができるか、または、ウェブサービスを活用して実行することができる。

ＴＣＰ／ＩＰプロトコルスタックの例えを用いて説明することができる。具体的には、プロトコルの異なる層は、異なる方法で実現することができる。「一般」層（ＴＣＰ／ＩＰスタックのＩＰに相当）は、ショートコードである。ＴＣＰ／ＩＰと同様に、送信媒体への特定の符号化は、他のタイプのコード化で実現することができる。例えば、ＱＲコード(登録商標)。

送信における信頼性は、音声復号の信頼性、すなわち、関数Ｄｔにおけるピッチ追跡と、ＥｓおよびＤｓにおける符号化の冗長との音声の２つの態様によって決定することができる。Ｄｓと関連して、周波数変調またはＰＣＭコード化などの異なる音声特性を使用することができる。選択される異なるタイプの音声特性は、例えば、非常に低価のハードウェア上または組み込まれたウェブアプレットでこのステップを実行する場合、符号化ステップ（Ｅｄ、Ｅｔ）の容易性とのバランスを保つことができる。

ステップＥｓおよびＤｓは、フレキシブルであり得る。任意のアプリケーションを相互作用させるには、メッセージの意味論に同意する必要があるという意味で、半開にできるのはこの層である。通常、例えば、ＩＰには、特に、使用される「高レベルの」プロトコルについて説明する短いヘッダがある。Ｃｈｉｒｐプロトコルはポイントツーポイントプロトコルであるため（複数の聴取者がいる可能性があるが、以下を参照）、シングルヘッダバイトとしてアプリケーションを特定することができる。このバイトのある特定の値は保存され、特定のアプリケーションを示す（例えば、ＵＲＬとして０×０１またはコード化されたＩＳＢＮとして０×０２）。次いで、これにより、復号プロセスは、どのアプリケーションが残りの７バイト（６４ビットコードと仮定）または１２７バイト（１０２４ビットコードと仮定）を処理すべきかを決定することができる。

一実施形態では、ショートコードの長さは、ショートコード自体に符号化される。しかし、この考えられる１つの不利な点は、復号音声（Ｄｔ）が未知のショートコードの長さ（すなわち、未知数の検出ノート）を処理する必要があることである。ショートコードの長さを符号化するかどうかの選択は、目的とする用途（正真正銘のピアツーピア方式で多量のデータを共有するため）、または、多量のデータおよびパス識別子に対してウェブサービスを使用するかどうかに依存し得る。

音楽符号化
音楽符号化の一実施形態について説明する。ショートコードが６４ビットであると仮定すると、これは４ビットのチャンクに分けることができ、１６ノートの「アルファベット」が生じることになる。１６の異なる周波数をアルゴリズムで選択することができるか、または、２オクターブ（弱）のキーを使用することができ、その結果、曲のノートはキーに含まれる。１６の異なるノートは、長さが１６ノートの信号または「Ｃｈｉｒｐ」を生じさせることになる。

あるいは、共通のノートパターン、アルペジオおよび進行を使用したより複雑なコード化スキームを利用することができる。これらはすべて、簡単なランダムシーケンスより多くのノートを使用することができる。

復号目的のため、ノートごとにピッチが変化することを保証することが好ましい場合がある。これは、ノートの長さおよび位相の復号の不明瞭性を回避する際に役立てることができる。したがって、アルファベットをシンボル１つ分拡張することができる。

ＵＲＬ共有サービス
ここで、図４を参照して、本発明の実施形態を利用するシナリオについて説明する。

このシナリオでは、２人のユーザ間でＵＲＬを共有することになっている。Ａｌｉｃｅは、プロセス４００（「ＣｈｉｒｐＡｐｐ」）を実行しているスマートフォンを持っている。Ｂｏｂは、プロセス４０１（「ＣｈｉｒｐＡｐｐ」）を実行しているスマートフォンを持っている。Ａｌｉｃｅは、ＢｏｂとＵＲＬを共有することを希望している。

ＣｈｉｒｐＡｐｐは、図１４ａ、１４ｂおよび１４ｃで説明されるユーザインターフェースを利用することができる。代替の実施形態では、プロセス４００および４０１は、異なるアプリケーションおよび／または音声によるデータ送信専用ではないアプリケーションに統合することができる（例えば、プロセス４００、４０１を写真アプリケーションに統合して、写真の共有を容易にすることができる）。

プロセスの概要
図４を参照すると、ステップは以下の通りである。
４０２−Ａｌｉｃｅは、アプリケーション（「ＣｈｉｒｐＡｐｐ」）にテキストをペーストし、アプリケーション（「ＣｈｉｒｐＡｐｐ」）は、Ｅｓプロセスに渡される（例えば、ＵＲＬは、「ｗｗｗ．ｂｂｃ．ｃｏ．ｕｋ」であり得る）。
４０３−Ｅｓプロセスは、Ｗｅｂ Ｓｈｏｒｔｅｎ（Ｗｓ）と呼ばれるウェブサービスに要求を出す。
４０４−Ｗｓは、ＵＲＬに対するテキスト文字列コード（「ハッシュコード」）をＥｓに返し（例えば、「６ｘｆ４２ｄ３ｅｄｆＧ」）、ハッシュコードとＵＲＬとの関係をデータベースに格納することも行う（「ストア」）。
４０５−Ｅｓは、このコードを取り、ウェブｕｒｌに対するアプリケーションコード（例えば、０×０１）をその先頭に追加し、それをＥｄに渡す。
４０６−Ｅｄは、これを音楽コードに変換する。
４０７−音楽が再生される。
４０８−プロセス４０１は、音声を受信する。
４０９−それは、音楽コードに復号され、Ｄｄに渡される。
４１０−Ｄｄは、それをショートコードに復号し、それをＤｓに渡す。
４１１−Ｄｓは、０×０１を取り除き、次いで、Ｗｅｂ Ｌｅｎｇｔｈｅｎ（Ｗｌ）と呼ばれるウェブサービスにハッシュコードを送信する。
４１２−Ｗｌは、ストアでハッシュコードを調べ、対応する長いＵＲＬ（例えば、ｗｗｗ．ｂｂｃ．ｃｏ．ｕｋ）をＤｓに返す。
４１３−Ｄｓは、ウェブブラウザウィンドウにＵＲＬを渡し、それを開く。

この実施形態では、ＥｓおよびＤｓはそれぞれ、リモート手順を利用して表を調べる。ウェブサービスは、複数のエントリポイント（この場合、ＷｓおよびＷｌ）を有するウェブサービスである。これらのサービスは両方とも、ハッシュコードをＵＲＬにマッピングする表を含むストアへのアクセスが必要である。各ハッシュコードは、一意なＵＲＬにマッピングされる。これは、生成されたショートコードがピアツーピアから送信されるためである。また、それは、Ｅｓ自体はＵＲＬから直接ショートコードを生成できないことも意味する。

ハッシュコードは、既定の長さの表のインデックス値であり得る。

このシステムに必要なコードの長さは、かなり短いものであり得る。ちなみに、ｂｉｔ．ｌｙのＵＲＬは、ベース６２のアルファベット（ａ〜ｚ、Ａ〜Ｚ、０〜９）からの６文字である。これは、大体３０ビットの情報を生じさせる。より大きなスペースを復号することを保証するため、少なくとも６４ビットのコードが使用される。

一実施形態では、符号化は、Ａｌｉｃｅのスマートフォンのウェブブラウザに内蔵されている。一実施形態では、ＣｈｉｒｐＡｐｐは、マルチメディア表示を含む（例えば、それはＴｗｉｔｔｅｒクライアントである）。

代替の実施形態では、ステップ４０２において、Ａｌｉｃｅは、複数のＵＲＬを格納することができるが、ウェブサービスから１つのコードのみを受信する場合がある。

代替の実施形態では、ユーザデバイス上のアプリケーションは、ユーザの最近の１０のお気に入り、最近閲覧したＦｏｕｒＳｑｕａｒｅの場所または最近メンションしたＴｗｉｔｔｅｒの連絡先をＣｈｉｒｐとして符号化することを許可することができる。この情報は、ＣｈｉｒｐＡｐｐによってそのアプリケーションから取り入れることができる。

一実施形態では、ステップ４０６において、Ｅｄは、以下の形式にショートコードを符号化することができる。
フロントドアの音＋符号化ショートコード＋Ｃｈｉｒｐの終了
フロントドアの音は、受信機が送信の開始を特定すること（ステップ４０８において）を可能にする事前に定義された音であり、符号化ショートコードは、音声に符号化されたアプリケーションコードおよびハッシュコードであり、Ｃｈｉｒｐの終了は、送信の終了を定義する事前に定義された音である。開始および終了音を定義する利点は、受信機を補助することである。また、形式は、次のＣｈｉｒｐも送信されようとしていることを示す追加のさらなるＣｈｉｒｐ音も含み得る。そのような場合は、フロントドアの音は必ずしも必要ではない。さらなるＣｈｉｒｐ音は、事前に定義された音であり得るか、または、Ｃｈｉｒｐがさらにいくつ予定されているかを示すことができる。さらなるＣｈｉｒｐ音は、Ｃｈｉｒｐの終了音前に現れる場合がある。

ユーザ経験は、ＣｈｉｒｐＡｐｐを実行するステップと、データにペーストするステップとを含み得る。代替ステップは、「Ｃｈｉｒｐボタン」をアプリケーション（すなわち、ウェブブラウザ）に組み込むステップである。このボタンを押した時点で、ウェブサービスへのクエリを行うことによってショートコードが生成され、次いで、およそ１〜２秒内に音声が現れる。一実施形態では、Ｂｏｂは、音声が始まる前に、ＣｈｉｒｐＡｐｐのインスタンスを実行する必要がある。あるいは、Ｂｏｂは、後の復号のために音声を記録することができる。音声が到達し始めた時点で、ショートコードの表現が現れ、受信プロセスが機能していることを示すことができる。これは、音声レベルが機能していることを示す音声スペクトル視覚化を伴う場合がある。

完全な音声が受信された時点で、ユーザにショートコードを明かすことができる。

ｂｉｔ．ｌｙなどのＵＲＬ短縮サービスは、通常、ベース６２（５２の大文字および小文字と、数字）の６文字を使用する。これに対する一代替手段は、ベース３６（大文字なし）の６文字である。一部のサービスは、ショートコードが長い間利用可能であることを保証しない。したがって、ＵＲＬ短縮サービスは、およそ３６ビット（ｌｏｇ_２（６２）×６＝約３５．７２またはｌｏｇ_２（３６）×６＝約３１．０２）をサポートすべきである。

ショートコードがベース６２の６文字列の場合、これは、３６ビットまたは５バイト（実際には４．５バイト）で表すことができる。

したがって、関数Ｅｓの入力は５バイトである。何らかの冗長を提供するため、マッピングは、リードソロモン（９，５）符号などのエラー訂正コードを使用することができ、これは、９バイトが出力であり、４エラー修正バイトがあることを意味する。したがって、９バイト（７２ビット）がＭＩＤＩコードに符号化される。この実施形態は、振幅も他の変調も使用せず、簡単なピッチのみを使用して説明する。ＭＩＤＩノートの使用可能範囲の中央は、Ｃ４（ＭＩＤＩノート６０）からＧ６（ＭＩＤＩノート９１）まで、すなわち、３２の使用可能ノートである。これは、１５のノートが使用されることを意味する。一実施形態では、ノートの１つは２ビットのみを符号化し、他の３ビットは保存される。これが第１のＭＩＤＩノートとなる。これは、第１のトーンが４つの値６０、６８、７６、８４の１つのみから選択されることを意味する。後続のノートは順次コード化することができる。

この特定の実施形態では、第１のノートは、１６０ミリ秒間再生される。第２のノートから第１５のノートまでは、８０ミリ秒間再生される。したがって、曲の全長は１．２８秒となる。

曲を復号するため、ピッチ検出を使用することができる。音声での符号化は、周波数キーイングシステムである。ＦＦＴ実装形態と調整されたフィルタバンク実装形態の両方とも使用することができる。一実装形態は、３２の目標周波数でＧｏｅｒｔｚｅｌアルゴリズムを利用する。

次いで、１６０ミリ秒長の目標トーンを探す。第１のコードの３ビットが保存されているため、その範囲内のいかなるトーンも検出することができる。この実施形態では、第１のＭＩＤＩコードの最も高い２ビットのみを取る（すなわち、（コード−６０）／８）。

さらなる復号は、符号化とは反対に進行する。１５のＭＩＤＩコードが９バイトのデータに変換され、リードソロモン符号を通じて５バイトのシーケンスに復号される。これは、長さ６のベース６２の文字列に変換することができる。長さ７の文字列が作成された場合は、これはエラーとなり、エラー訂正コードが未検出であったことを意味する。

リードソロモン符号は、抹消を訂正することができる。したがって、フィルタバンクが何れの時間ステップでもピークを検出しないか、または、ノイズのためピークが不明瞭である場合は、関連バイトを抹消としてマーク付けすることができ、それらを訂正することができる。

発明者は、ユーザのデバイスがサーバにアクセスできない場合に、デバイスを用いてユーザとのデータの送信のやり取りを可能にすることが望ましいことも決定した。

それに応じて、本発明のさらなる一態様は、サーバからショートコードを受信するステップと、第１のデバイス上にショートコードを格納するステップと、ショートコードをデータと関連付けるステップと、ショートコードを第２のデバイスに送信するステップと、次いで、データとショートコードとの関連付けをサーバに送信するステップとを含み得る。

ショートコードとのデータの非同期関連付けは、何れのデバイスも「オンライン状態」であることを必要とせずに、または、ショートコードとデータとの関連付けに関する情報を有するサーバにアクセスして、２つのデバイス間でのデータへの単なる「参照」の送信を可能にすることができる。したがって、それは、参照またはショートコードの使用によって第２のデバイスによるデータへの非同期アクセスを可能にすることができる。

ここで、図５〜６を参照して、上記の態様による本発明の実施形態について説明する。

デバイス５００が示されている。デバイス５００は、受信機５０１と、メモリ５０２と、プロセッサ５０３と、第１の送信機５０４と、第２の送信機５０５とを備え得る。

受信機５０１は、サーバ５０６からショートコードを受信するよう構成することができる。好ましくは、サーバ５０６は、モバイルテレコミュニケーションネットワークまたはインターネットなどの通信ネットワークを介してアクセス可能なものである。代替の実施形態では、サーバ５０６およびデバイス５００は、モバイル通信デバイスなどのさらなるデバイス内に存在する。

メモリ５０２は、受信したショートコードを格納するよう構成することができる。メモリ５０２は、フラッシュメモリでも、プロセッサ５０３内に統合されたメモリでもあり得る。

プロセッサ５０３は、受信したショートコードをデータと関連付けるよう構成することができる。プロセッサ５０３は、ユーザ入力デバイスを介してユーザからデータを関連付けるための入力を受信することができる。入力は、データ自体であり得る。

第１の送信機５０４は、第２のデバイスにショートコードを送信するよう構成することができる。第１の送信機５０４は、ダイレクトインターフェース（可聴チャネル、Ｂｌｕｅｔｏｏｔｈ(登録商標)、視覚的表示および検出、ＩＲ、ＮＦＣ、ワイヤレスまたはＲＦなどの両方のデバイス間の直接のインターフェース）を使用してショートコードを送信することができる。

第２の送信機５０５は、ショートコードとデータとの関連付けをサーバ５０６に送信するよう構成することができる。好ましくは、第２の送信機５０５は、受信機５０１と同じ通信システムを使用する。

また、サーバ５０６も示されている。サーバ５０６は、プロセッサ５０７と、送信機５０８と、第１の受信機５０９と、メモリ５１０と、第２の受信機５１１とを備え得る。

プロセッサ５０７は、メモリ５１０にショートコードを保存するよう構成することができる。サーバ５０６は、示されるデバイス５００などのデバイス上のユーザからの要求に応じて、ショートコードを保存することができる。ショートコードは、サーバ５０６が割り当てることができるか、またはその代替の実施形態では、要求内でユーザが指定することができる。

送信機５０８は、示されるデバイス５００などのデバイスに、保存されたショートコードを送信するよう構成することができる。

第１の受信機５０９は、保存されたショートコードとデータとの関連付けを受信するよう構成することができる。関連付けは、デバイスから受信することができる。

メモリ５１０は、保存したショートコードとデータとの関連付けを格納するよう構成することができる。メモリ５１０は、サーバが継続的にオンライン状態を保つ場合は、ＲＡＭなどの揮発性メモリでも、不揮発性メモリでも、冗長のため両方でもあり得る。

第２の受信機５１１は、第２のデバイスから要求を受信するよう構成することができる。要求は、ショートコードを含み得る。プロセッサ５０７は、要求をデータと関連付けるよう構成することができる。プロセッサ５０７は、ショートコードを使用して、データとの関連付けを回収することができる。プロセッサ５０７は、要求に従ってデータをさらに処理することができる。

ここで、本発明の実施形態によるさらなる方法について説明する。

一方法６００では、ステップ６０１において、サーバからショートコードを受信する。ステップ６０２では、デバイス上に受信したショートコードを格納する。ステップ６０３では、受信したショートコードをデータと関連付ける。ステップ６０４では、受信したショートコードを第２のデバイスに送信する。ステップ６０５では、関連付けをサーバに送信する。方法は、モバイルテレコミュニケーションデバイス上で実行することができる。

別の方法６０６では、ステップ６０７において、ショートコードを保存する。ステップ６０８では、保存したショートコードを第１のデバイスに送信する。ステップ６０９では、保存したショートコードとデータとの関連付けを受信する。ステップ６１０では、保存したショートコードとデータとの関連付けを格納する。ステップ６１１では、第２のデバイスから要求を受信する。要求は、保存したショートコードを含み得る。ステップ６１２では、要求をデータと関連付ける。方法は、サーバ上で実行することができる。

当業者であれば、方法のすべてまたは少なくとも一部を１つまたは複数のコンピュータプログラム内で実施できることが理解されよう。例えば、モバイルテレコミュニケーションデバイスのための方法６００は、ｉＰｈｏｎｅ(登録商標)アプリケーション内、Ａｎｄｒｏｉｄアプリケーション内、Ｓｙｍｂｉａｎ内または他の任意のプログラミング言語内で、コンピュータプログラムコードとして作成することができる。サーバのための方法６０６は、Ｐｙｔｈｏｎ／Ｄｊａｎｇｏ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｒｕｂｙ ｏｎ ＲＡＩＬＳまたは他の任意のシステムなどの任意のコンピュータプログラミング言語、システムまたはフレームワークで作成することができる。

非同期ＵＲＬ共有サービス
ここで、特に図７を参照して、本発明の実施形態について説明する。

この特定のシナリオでは、Ａｌｉｃｅは、ＢｏｂとＵＲＬを共有することを希望するが、彼らの一者または両者がオンライン状態ではない。

プロセスの概要
図７を参照すると、以下のタイムラインでプロセスが示され、ウェブサーバプロセス７００、Ａｌｉｃｅのアプリケーションプロセス７０１およびＢｏｂのアプリケーションプロセス７０２の３つのプロセスが示されている。時間は、左から右へ進行する。

７０３−Ａｌｉｃｅのデバイス上のプロセス７０１（「ＣｈｉｒｐＡｐｐ」）がオンライン状態の際、関数Ｃａｃｈｅ Ｐｒｅ−ｃａｃｈｅ（Ｃｐ）は、ハッシュコードのセットを保存するように、Ｗｅｂ Ｒｅｓｅｒｖｅと呼ばれるウェブサービス７００に要求を出す。

７０４−これらのコードは、ストアに格納され、未だＵＲＬにはマッピングされていない。

７０５−Ｗｒは、コードをＣｐに返し、Ｃｐは、今後の使用のためにローカルにそれを格納する。

７０６−ここで、ＡｌｉｃｅがＵＲＬのＣｈｉｒｐを試みる際、Ａｌｉｃｅのデバイスはオフライン状態である。しかし、プレキャッシュされたハッシュコードの１つを使用することができる。したがって、符号化プロセスＥｓは、これらのプレキャッシュされたコードの１つを使用して、ショートコード、音楽コードを生成し、音声を生成することができる。

７０７−Ｃｈｉｒｐが送信される。

７０８−プロセス７０２（「ＣｈｉｒｐＡｐｐ」）を実行しているＢｏｂのデバイスはＣｈｉｒｐを受信するが、Ｂｏｂのデバイスもオフライン状態である。Ｂｏｂのデバイスは、段階Ｄｔ、Ｄｄを超えてＣｈｉｒｐを復号することはできない。たとえオンライン状態であったとしても、この時点でウェブサービスＷｌは保存されたコードの隣にブランクのＵＲＬを見つけるため、ショートコードを復号することはできないだろう。

７０９−プロセス７０１がオンライン状態となると、関数Ｃａｃｈｅ Ｕｐｄａｔｅｒ（Ｃｕ）は、ハッシュコードとＵＲＬとの新しい関係を中継する。

７１０−ウェブサービスＷｅｂ Ｕｐｄａｔｅｒ（Ｗｕ）は、この新しい関係をストアに格納する。ここで、いかなるプロセスも、ハッシュコードからＵＲＬを調べることができる。

７１１−プロセス７０２がオンライン状態となると、それは、すべての非復号のショートコードのフェッチを試みる。それは、前述同様に、ハッシュコードをＷｌに渡す。

７１２−Ｗｌは、ここでは非ブランクのショートコードからＵＲＬへのマッピングを調べる。

７１３−ＷｌはＵＲＬをＤｓに返す。

７１４−プロセス７０２はウェブブラウザを始動する。

好ましくは、プロセスは、ユーザアカウントを使用して、他の誰かによってＷｕが更新されることを防ぐ。それは、有料サービスであり得る。

ここでは、Ｃｈｉｒｐを完全に復号できない期間（すなわち、ＡｌｉｃｅがハッシュコードとＵＲＬとの関係をウェブサービスにアップロードする前）がある。しかし、ステップ７０８では、ＡｌｉｃｅとＢｏｂは、ショートコードが送信されていることを確認することができる。一実施形態では、彼らのデバイスのそれぞれのデバイス上のユーザインターフェースは、比較のためにショートコードを表示することができ、および／または、ユーザインターフェースは、ＢｏｂがＣｈｉｒｐを「再度再生」することを可能にし、両ユーザともそれを聞き取って２つの音が同じであることを確認することができる。音が同じであれば、原理上は、首尾よくデータを調べることができる。ＣｈｉｒｐＡｐｐは、Ｃｈｉｒｐを完全に復号できる際にそれをＢｏｂに知らせることができる。Ｂｏｂがオンライン状態となって時点で、ステップ７０９の実行に対してＡｌｉｃｅが未だオンライン状態となっていないことはあり得ない。この時点で、Ｃｈｉｒｐは、「元の送信者からの更新保留」として特定され得る。したがって、Ｃｈｉｒｐは、後日復号するためにウイルスのように拡散させることができる（例えば、特定の時間にリリースされたフィルムトレーラクリップにリンクする）。

この特定の実施形態では、両プロセスの機能性は、両デバイスに展開された単一のアプリケーション（ＣｈｉｒｐＡｐｐ）内に含まれる。このアプリケーションは、図３および４と関連して説明されたものと同じアプリケーションであり得る。プロセスを別々のアプリケーション内に含めることができることも理解されよう。

ここで、本発明のさらなる実施形態について説明する。

機能不可（Ｄｕｍｂ）リレー
機能不可リレーに対して考えられるいくつかの実装形態、すなわち、復号できないが、単に生の音声または音楽記述の記録および送信のみを行うプロセスが存在する。

符号化および復号ステップは、それら自体がウェブサービスとして提供され得る。ウェブサービスは、ダウンロード可能なＣｈｉｒｐをＭＰ３として提供することも、ウェブブラウザでのＣｈｉｒｐの再生をサポートすることもできる。これは、スピーカが取り付けられていれば、ウェブブラウザは即座にＣｈｉｒｐを生成できることを意味する。

それに加えて、これらのサービスは、ＭＭＳなどの他のゲートウェイを通じて触れることができる。

先述の通り、Ｃｈｉｒｐ自体は、音声であるため、これらの機能をサポートする任意のタイプのデバイスによって記録および中継することができる。これは、簡素な電話（固定電話）およびスマートフォン以外の携帯電話を含む。

また、Ｃｈｉｒｐは、デジタルメディアに格納することも、テープ、ビニール盤またはビデオテープなどのアナログメディアに格納することもできる。アナログメディアとデジタルメディアの両方にＣｈｉｒｐを記録できるということは、テレビなどの大型の機能不可リレー上での放送用の他のメディアにもＣｈｉｒｐを適合できることを意味する。例えば、テレビ広告は、Ｃｈｉｒｐ音声トラックを含み得る。

保存コードサービス
生成された音楽コードのいくつかは、周知の曲のように聞こえる場合がある。ＥｄとＤｄが可逆機能であれば、これらの曲のバージョンをＭＩＤＩなどのＭＤＬで作成することができ、次いで、対応するショートコードを見つけて、保存することができる。これは、有料サービスであり得る。このプロセスは、テーマ曲（Ｗｉｎｄｏｗｓの開始、Ｉｎｔｅｌのジングルなど）の捕捉および特定のウェブサービスへのそれらのリダイレクトに対してうまく機能するであろう。

厳密なピアツーピアモデル
１つのモデルは、スタンドアロンアプリケーションにＣｈｉｒｐを組み込むことである。次いで、ショートコードは、アプリケーション特有の意味論を有することができる。例えば、バウチャを共有したアプリケーションでは、モバイルデバイスにダウンロードされたアプリケーションに、画像としてバウチャ自体を組み込むことができる。特定のＣｈｉｒｐがデバイスで聞こえると、バウチャのロックが解除されることになるが、コードは、単にアプリケーションでバウチャをアクティブ状態にするためにある。Ｃｈｉｒｐがデバイスで聞こえた時点で、そのデバイスは、Ｃｈｉｒｐを中継できるようになる。

これにより、バウチャまたはクーポンのウイルスのような共有が可能となる。それに加えて、バウチャが広まった参加者の数を符号化して、バウチャを適切に渡すことができ、また恐らく、バウチャが他の誰かに渡った回数も符号化することができよう。これを行うには、ショートコードが１つのバウチャと一致しない場合もあり得るが、コード生成ループがあり、それにより、既知のシーケンスにおいて次のショートコード、したがってＣｈｉｒｐ音声を生成することができる。したがって、受信アプリケーションは、どのショートコードかを見分けることばかりでなく、その履歴についての何かを見分けることも可能となる。これにより、ある特定の人数がそれを保有した後でのみ与えられるタイプのバウチャコードを有効にすることができる。

別の概念は、新しいバンドビデオの一部またはビデオのトレーラなどの他のメディアタイプをウイルスのように共有することであろう。その結果、ユーザは、アプリケーションをダウンロードする際にメディアのランダム部分を入手することになるが、ユーザと友人は、Ｃｈｉｒｐコードを交換することによってメディアの他の部分を収集することが可能である。これにより、友人のグループは、ビデオまたは音声トラックをまとめて即座に組み立てることができるようになり、メディアの周りでの相互作用が容易になる。

リモート操作の例
一例は、聴取者の近くの機器（例えば、ＣｈｉｒｐＡｐｐのウェブバージョンを実行しているＰＣ）に信号として組み込まれたＣｈｉｒｐとの会話に基づく。これにより、例えば、コールセンタ職員は、あるページへ強制的に移動させることによって、ローカルのＰＣをリモート制御できるようになる。

これを実施する一方法は、ウェブページ上のＦｌａｓｈアプレットにＣｈｉｒｐ読取機を組み込むことである。Ｆｌａｓｈは、マイクロホンへのアクセスを有するため、テレビまたはスピーカフォンからの出力などのローカル環境でＣｈｉｒｐを「聞き取る」ことができる。したがって、リモートオペレータは、話している間に、Ｃｈｉｒｐを送信することができ、Ｃｈｉｒｐはウェブページ上のアプレットで聞こえるようになる。次いで、アプレットは、ページを変えること、アニメーション化することなどによって、ウェブページを操作することができる。それは、そうでなければ制限される可能性があるウェブサイトのある特定のエリアを起動するための安全なコードを運ぶことさえも考えられる。その利用可能性は、ＰＣの技術サポートにおいてであろう。

信頼できるピアツーピアおよび安全なピアツーピア
これまで説明されてきたように、Ｃｈｉｒｐは、一方向のデータ転送に使用することができる。論じられるように、Ｃｈｉｒｐは、放送テレビなどの非対話的なメディア上で放送することができる。しかし、スマートフォンや他のプラットホームを用いることで、送信者は、ほぼ確実に受信者として機能できるようになる。

送信者と受信者の両者とも送信も受信も可能な場合は、複数段階プロトコルを実施することができる。例えば、２つのデバイスは、識別情報（例えば、「こんにちは、私はデバイスＸです」を表し、「こんにちはＸ、私はデバイスＹです」と応答させるコードおよびＣｈｉｒｐ）を送信することによって、ハンドシェイクを行うことができる。次いで、デバイスＸは、「Ｙ、Ｃｈｉｒｐ Ｚを送ります」というメッセージを送信することができ、「Ｘ、ＹはＣｈｉｒｐ Ｚを受信しました」という応答で返すことができる。これにより、Ｃｈｉｒｐ転送はより信頼できるものとなる。デバイスＸは、Ｚのコピーを手に入れることができ、そのコピーに何らかの形で歪みが生じた場合は、デバイスＸは再送信することができるため、適正にデバイスＹがＣｈｉｒｐを受信したことを検出することができる。また、デバイスＸは、ある特定の時間内に何の連絡もなく、デバイスで聞こえなかったかまたは応答できなかったかの何れかであると想定した場合にも、再送信することができる。何れの場合にも、デバイスのユーザがＣｈｉｒｐを聞き取れる可能性があり、データが再送信されたかまたは再送信する必要があるかどうかを理解できる可能性があり、必要ならばデバイスのユーザは干渉できることを理解することが重要である。

上記に付け加えて、公開／秘密鍵の交換を使用してＣｈｉｒｐ Ｚを符号化することも可能である。デバイスは、簡単な識別子よりもむしろ、公開鍵Ｋ_ＰＸおよびＫ_ＰＹを交換する。次いで、Ｋ_ＰｒＸの秘密鍵でＣｈｉｒｐを符号化して、暗号化されたＣｈｉｒｐ Ｚ’を作成することができる。次いで、デバイスＹは、コンテンツが安全であることと、送信者が確かにＸであることの両方を知ることができる。

すべてのピアツーピアシステムに対し、トランザクションの登録が可能なように、ウェブサービス上にオーディットトレールが存在し得る。具体的には、ウェブサービス上に公開鍵を格納することができる。

ＣｈｉｒｐとＰｉｎ
ピアツーピアサービスの拡張の１つは、支払サービスなどの外部サービスとの相互作用を容易にすることである。支払サービスは、トークンの何らかの形式の交換を必要とし、Ｃｈｉｒｐはそのトークンであり得る。これは、少なくとも３つの異なる方法で機能することができる。

第１に、Ｃｈｉｒｐ自体は、Ｃｈｉｒｐを生成するアプリケーションが、ウェブサービスからいくつかのＣｈｉｒｐコードを「購入」することができ、それらを受信者に中継できるという意味で、「貴重なもの」であり得る。したがって、Ｃｈｉｒｐアプリケーションは一種の財布として機能し、送信者がオンライン状態である必要はない。受信者はオンライン状態であってもなくともよい。Ｃｈｉｒｐが多大な量に対するものである場合は、受信者は、それが未だ使用されていないことを検証できるオンラインサービスにそれを転送することによって、即座に「それを現金化する」ことを希望する場合がある。第三者がＣｈｉｒｐを耳にした場合は、その第三者は、それを現金化する際に受信者を「打ち負かす」必要がある。それらは、これを行うため、物理的に近くなければならない。安全な転送を使用することが可能である。

第２に、Ｃｈｉｒｐアプリケーションは、ウェブサービスを運営するためにＵＫ銀行口座で現在分配されているセキュリティデバイスと同様に機能することができる。アプリケーションは、通常のＶＩＳＡまたは他のクレジット／デビットカードの詳細を符号化することができ、ユーザは、通常のＰＩＮを入力することができる。ウェブサービスにタイプする８桁のコードを捉える代わりに、デバイスは、Ｃｈｉｒｐを８桁コードにすることになる。受信者は、カードネットワークでこのコードを検証することができる。

図８を参照して、本発明の実施形態によるデバイス８００について説明する。

示されるデバイス８００は、入力デバイス８０１と、メモリ８０２と、エンコーダ８０３と、送信機８０４とを備え得る。入力デバイス８０１は、ユーザから認証入力を受信するよう構成することができる。メモリ８０２は、ユーザ識別を格納するよう構成することができる。エンコーダ８０３は、可聴的に一意な形式の信号にユーザ識別および認証入力を符号化するよう構成することができる。送信機８０４は、可聴音声の再生成のために信号を送信するよう構成することができる。

デバイス８００は、トランザクションの認証に使用することができる。好ましくは、トランザクションは、金融取引であり、ユーザ識別は、ユーザ口座情報を含むかまたはそれに関連する。あるいは、トランザクションは、物理的アクセスまたはワイヤレスネットワークへのアクセスに対してなど、ユーザを認証するためのトランザクションであり得る。

また、エンコーダは、デバイス８００のＩＭＥＩなど、デバイス８００の位置またはデバイス８００用の識別子を信号に符号化することもできる。それに加えて、可聴信号を受信する受信デバイスは、ユーザ識別情報をユーザと一致させ、ユーザをユーザに対する認証の履歴記録と一致させることによって、または、ユーザを受信デバイスのユーザのソーシャルネットワークと一致させることによって、デバイス８００またはデバイス８００のユーザをさらに認証することができる。

また、受信デバイスは、先の時間のデバイス８００の先の位置を使用してスプーフィングを防止するために、デバイス８００が受信デバイスの位置にもっともらしく位置し得るかどうかを計算することによって、および、先の位置と現在の位置との間の移動時間が可能かどうかを計算することによって、デバイス８００をさらに認証することもできる。

図９を参照して、本発明の実施形態による方法９００について説明する。

ステップ９０１では、認証入力デバイスを介してユーザから認証入力を受信する。ステップ９０２では、ユーザ識別および認証入力を可聴的に一意な形式の音声信号に符号化する。ステップ９０３では、可聴音声の再生成のために音声信号を送信する。

第３に、Ｃｈｉｒｐアプリケーションは、銀行サービス間のリレーとして動作し得る。すなわち、送信者は、ワンタイムＣｈｉｒｐコードに対するオンラインサービスを依頼することになる。受信者は、これを即座に現金化しなければならないことになっており、トランザクションは、効果的に、２つのオンライン銀行サービス間の「ループを閉じる」。

先述の安全なサービスと組み合わせると、Ｃｈｉｒｐを使用して他のシナリオを容易にすることができる。小型の音声放送機器が組み込まれたグリーティングカードは、金銭価値を実際に反映し得る。マイクロペイメントまたはクレジットは、店内公示システム上で広めることができる。

認証
Ｃｈｉｒｐアプリケーションをデバイス上で実行することができ、そのデバイスに所有者がいるため、多要素認証（ＭＦＡ）を使用することができる。具体的には、銀行セキュリティデバイスとの類似性に従って、Ｃｈｉｒｐアプリケーションは、ユーザからのＰＩＮにアクセスできるばかりでなく、ウェブサービスからのＩＤ、ＧＰＳからのユーザの位置の履歴、デバイスのＩＭＥＩ番号にもアクセスすることができる。これらのいくつかまたはすべては、ショートコードに符号化することができる。他の複数の要素は、デバイスカメラ、加速度計および社会的履歴からのデータを含み得る。

対形成
Ｃｈｉｒｐアプリケーションは、Ｃｈｉｒｐを使用して、Ｂｌｕｅｔｏｏｔｈ(登録商標)接続用のＰＩＮを分配することができる。アプリケーションは、必要ならば、デバイス上でＢｌｕｅｔｏｏｔｈ(登録商標)を初期化することができる（それには、ポップアップメニューを通じたユーザ承認が必要とされる場合がある）。

同様に、対形成スキームは、ＷｉＦｉまたはＲＦＩＤ用に、すなわち、対形成セキュリティの強化またはユーザ経験の円滑化に二次チャネルが役立つものの何れに対しても、初期化することができる。

ゲーム
アプリケーション操作の特定の変形形態は、Ｃｈｉｒｐを使用して、マルチユーザゲームをサポートすることである。これは、戦略ゲーム、カードゲーム、アドベンチャーゲーム、取引ゲームなどの展開が遅いゲームに特に適するであろう。

ハードウェア（チップ上のＣｈｉｒｐ）
物理的なインターフェースがアクセス不可能であるか、または、制御モバイルデバイスによってより安くもしくは好都合にアクセス可能な状態にすることができるかの何れかの場合は、マイクロホンを装備したハードウェアで、組み込まれたＣｈｉｒｐを使用して、デバイスを制御することができる。Ｃｈｉｒｐは、音声を介して制御メッセージを送信することができる。考えられる用途は、オーブンタイマのプログラミングまたはＰＶＲ上でのペアレンタルコントロールの設定を含む。

制御メッセージは、Ｃｈｉｒｐのシーケンスとして送信することができる。オーブンまたはＰＶＲに対する動作を決定するシーケンス。

Ｃｈｉｒｐ受信機は、ＵＳＢドングル上に構築することができる。ＵＳＢドングルは、音声を受信するためのマイクロホンと、音声をショートコードに変換するデコーダと、ショートコードと関連付けられたデータを入手するためにウェブサービスにアクセスするためのメカニズムとを含み得る。ＵＳＢドングルが差し込まれるコンピュータのｗｉｆｉ能力をメカニズムが利用することも、ＵＳＢドングルがｗｉｆｉトランシーバを含むこともできる（代替のトランシーバは、最終的にネットワーク接続を介したウェブサービスへの接続を容易にするＢｌｕｅｔｏｏｔｈ(登録商標)または他のＲＦのように構想することができる）。

ＵＲＬと有効期限
ウェブサービスを復号に使用することができるため、さまざまな特性、例えば、受信者の位置（例えば、主なペイロードを手に入れるため、受信者は送信者の位置の近くでなければならない）、時間、ソーシャルネットワーク（例えば、友達の友達のみ）、ランダムな報酬支払（例えば、宝くじ）、識別（例えば、Ｃｈｉｒｐ内で「最終受信者」を符号化し、その人物に特有のコンテンツをアクティブ状態にする）に応じて異なる復号を実行することができる。

ウェブアプリケーションの制御
一実施形態では、ウェブアプリケーションは、Ｃｈｉｒｐを受信して復号し、復号したＣｈｉｒｐを使用してウェブアプリケーション内の動作を制御するように適合させることができる。代替の例では、Ｃｈｉｒｐは単なる音声であり得、ウェブアプリケーションは、音声を動作に一致させることができる。音声は、格納された音声への直接マッピング、フィンガープリント法またはショートコード用のサーバを用いたショートコードへの復号を使用して、ウェブアプリケーション内に格納されたデータと一致させることができる。

ウェブアプリケーションは、Ｊａｖａ(登録商標)アプリケーションなどのクライアント側のものでも、ウェブブラウザが音声をサーバに渡す場合はサーバ側のものでもあり得ることが理解されよう。

ここで、図１０を参照して、本発明のさらなる実施形態について説明する。

発明者は、モバイルデバイス上に以前に格納されたコンテンツのロック解除が有用であることを発見した。コンテンツのロックを解除するための前のシステムは、コードをダウンロードしてデバイス上に格納されたコンテンツにアクセスすることを含む。また、デバイス上の機能性のロックも解除されることも同様に望ましいであろう。

コンテンツ要素は、バーチャルグッズを表し得る。したがって、音声を使用して、デバイス上のバーチャルグッズのロックを解除することができる。

ここで、本発明のこの実施形態において、音声の受信と同時にモバイルデバイス１００１上のコンテンツのロックを解除するためのシステムについて説明する。

本発明のこの実施形態では、コンテンツ／機能性を入手する２つの方法があり得る。
１）アプリケーションをダウンロードするかまたは入手する際に、コンテンツをダウンロードする。
２）アプリケーションによってコンテンツをデバイスにプッシュするかまたはデバイスにプルする。例えば、毎日、新聞のコンテンツをモバイルデバイスにプッシュすることができる。

デバイス１００１上のアプリケーションは、コンテンツアクセスを管理することができる。例えば、アプリケーションは、ｗｉｆｉ接続への接続が可能な場合に、ネットワークトランシーバ１００２を介してコンテンツアクセスを自動化することができる（すなわち、３Ｇ上での広帯域の使用を削減するため）。アプリケーションは、プロセッサ１００３によって実行することができる。

コンテンツ要素１００４は、デバイス１００１のメモリ１００５上に格納することができる。

コンテンツ１００４がそのロックを解除するためのコードを含むことも、コンテンツ１００４をコードで暗号化することも、アクセシビリティコードを格納するアプリケーションによって、コンテンツ１００４へのアクセスを管理することもできる。コードは、ショートコードであり得る。

コードは、デバイス１００１に特有でも、コンテンツ１００４に特有でもあり得る。

コンテンツ１００４は、マルチメディア、ＵＲＬ、アプリケーション機能性（例えば、ゲームまたは新しいゲームレベルのロックを解除する）、または、新しいコードでさえもあり得る。

コンテンツへのアクセスを得るため（コンテンツのロックを解除するため）、デバイス１００１は、デバイス１００１のマイクロホン１００６から音声を受信することができる。音声は、図３で説明された符号化プロセスに従って、音声内でショートコードを符号化することができ、音声自体がコードであることも、コードを入手するために音声をフィンガープリントすることもあり得る。音声が符号化される場合は、音声は、音声デコーダ１００７によってコードに復号される。

コードは、デバイス１００１上に格納されたコンテンツ１００４と一致させ、コンテンツへのアクセスを提供する。コンテンツへのアクセスは、コンテンツアプリケーション１００９によってユーザインターフェース１００８を通じてユーザに提供することができる。例えば、コンテンツはＭＰ３であり得、デバイス上の音楽プレーヤ上でＭＰ３を再生することによって、アクセスが提供される場合がある。

代替の実施形態では、コードに加えて、コンテンツへのアクセスの提供にさらなる制約が必要とされる。例えば、複数のコードを受信する必要がある場合も、ユーザデバイス１００１が特定の位置（例えば、搭載ＧＰＳチップによって決定されるように）になければならない場合も、それが特定の時間帯内または特定の時間の前／後になければならない場合もある。

音声は、テレビもしくはラジオ上の放送またはＰＡシステム上で、別のモバイルデバイスからのピアツーピア音声送信を介して受信することができる。

音声は、この明細書の他の場所で説明されるようなＣｈｉｒｐであり得る。

本発明のこの実施形態の潜在的利点は、オフライン状態の間にユーザ間でコードを共有できるということである。その上、コンテンツをダウンロードする必要なく、コードがコンテンツのロックを解除するため、オフライン状態で即座に満足を得ることができる。

ここで、図１１を参照して、さらに、本発明のさらなる実施形態について説明する。

バウチャは、商品またはサービスと引き換えることができるトークンである。一般的なバウチャは、ユーザにもトランザクションにも特有でないバウチャである。一般的なバウチャは、現在、紙形式または電子形式である。一般的なバウチャは、紙形式のバウチャを渡すかもしくは示すことによって、または、モバイルデバイス画面などの視覚ディスプレイ上に電子バウチャを表示することによって引き換えられる。

発明者は、一般的なバウチャを引き換える先行技術の代替手段を提供することが望ましいという結論を下した。

ここで、バウチャが音声で引き換えられる場合の本発明の実施形態について詳細に説明する。

第１のユーザデバイス１１０１が示されている。好ましくは、第１のデバイス１１０１は、スマートフォンなどのモバイルユーザデバイスである。

第１のデバイス１１０１は、ネットワーク接続１１０３上でウェブサービスとしてアクセス可能であり得るデータベース１１０２からバウチャを受信することができる。バウチャは、バウチャ用の識別子として表すことができる。あるいは、第１のユーザデバイス１１０１は、第２のユーザデバイス１１０４から音声でバウチャを受信することができる。好ましくは、第２のユーザデバイス１１０４は、モバイルユーザデバイスである。その上、第２のユーザデバイス１１０４は、さらに別のユーザデバイスからバウチャを受信して、初めにデータベース１１０２からバウチャを受信した第１の発信元デバイスから現デバイス１１０１へのユーザデバイス共有の連鎖を形成した可能性がある。

バウチャが音声形式で受信されない場合は、図３に示される符号化方法に従って、音声形式でバウチャを符号化することができる。その上、第１のユーザデバイス１１０１は、バウチャを音声に符号化する際に、バウチャ識別子を有する一意なユーザ識別子を含み得る。

一実施形態では、符号化音声は、以下の形式で符号化することができる。
バウチャ識別子＋共有数＋発信元ＩＤ＋照会人ＩＤ
発信元ＩＤは、連鎖内でバウチャを直接共有する第１のユーザの識別子であり、照会人ＩＤは、現ユーザにバウチャを提供する最後のユーザの識別子である。代替の実施形態では、発信元から最後の照会人までの共有の連鎖内のユーザはすべて、符号化音声に追加することができる。この形式は、バウチャを共有する挙動の後の分析を可能にすることができる。

音声は、第１のユーザデバイス１１０１上のスピーカ１１０５を通じて無線インターフェース上で送信することができる。

商業デバイス１１０６が示されている。商業デバイス１１０６は、メモリ上に格納されたデータベース１１０７を含むことも、データベース１１０７へのアクセスを単に有することもできる。データベース１１０７およびデータベース１１０２は、同じデータベースでもよい。データベース１１０７は、多数のバウチャ１１０８を格納する。

商業デバイス１１０６は、第１のユーザデバイス１１０５から送信された音声を受信することができる。音声は、商業デバイス１１０６上のマイクロホン１１０９を介して受信することができる。

商業デバイス１００６は、受信した音声をデータベース１１０７内の多数のバウチャ１１０８と一致させることができる。

音声は、音声フィンガープリント法を介して、データベース１１０７内に格納された音声と直接一致させることも、音声は、図３で説明されるようにショートコードを符号化し、音声を復号し、ショートコードをバウチャ１００８と一致させることもできる。

一致させたバウチャに関連する情報は、バウチャの価値の検証のために商業デバイス１１０６上に表示することができる。例えば、バウチャは、第１のユーザデバイス１１０１のユーザが、５０％割引の購入品を受け取ること、または、購入品とともに無料ギフトを受け取ることを示す場合がある。

バウチャの引き換えには制約がある場合がある。制約は、バウチャの送信に責任を有する第１のユーザデバイス１１０１上のアプリケーション上で施行すること、および／または、商業デバイス１１０６側で施行することができる。

制約は、ユーザ１人当たりのバウチャの数の限度を含み得る。この例では、商業デバイス１１０６は、使用されたユーザ識別子およびバウチャを記録するためのデータベース１１２０を含むことも、同データベース１１２０へのアクセスを有することもできる。

制約は、バウチャの引き換えを最初の１００人（例えば）に限定するため、バウチャの総数限度を含み得る。

制約は、考えられるバウチャ引き換えの場所（例えば、複数の所在地があるベンダーの特定の場所）または時間の制限を含み得る。

ここで、図１２を参照して、さらに、本発明のさらなる実施形態について説明する。

伝統的には、紙幣、貨幣または譲渡不可能なバウチャなどの物理的トークンを使用して関係者間で送金が行われる。このプロセスの明確に不利な点は、物理的トークンは失いやすい可能性があり、取り扱いに関連するコストまたは不便性があるということである。

送金するための他の方法は、クレジットカード、デビットカードおよびプリペイドカードなどの電子手段を含む。そのような方法は、かなりのインフラ要件（すなわち、特殊な読取デバイス）を有し、クレジット／デビットカードは、ユーザベースの認証プロセスも必要とする。

発明者は、送金するための代替のシステムが望ましいという結論を下した。

ここで、音声を使用して送金が行われる本発明の実施形態について説明する。

第１のモバイルユーザデバイス１２０１が示されている。モバイルユーザデバイス１２０１は、着信音の付いたＳＭＳメッセージを受信することができる任意の携帯電話であり得る。あるいは、モバイルユーザデバイス１２０１は、音声（任意の形式、例えば、ＭＰ３、ＭＩＤＩで）を受信して格納することができるかまたはコードを受信してコードを音声に符号化することができるスマートフォンであり得る。

第１のモバイルユーザデバイス１２０１は、モバイルテレコミュニケーションネットワーク１２０３上で、信頼できる第三者１２０２（銀行など）からの特定の金銭的価値に対する一意な識別子を要求することができる。

信頼できる第三者１２０２は、識別子を生成して、識別子と特定の金銭的価値の両方をデータベース１２０４に格納することによって、要求を処理することができる。一代替手段では、信頼できる第三者１２０２は、第１のモバイルユーザデバイス１２０１のユーザが保有する銀行口座または他の金銭口座の借記を指示することができる。

識別子は、ショートコードであり得る（図３で説明されるように）。

信頼できる第三者１２０２は、識別子をＭＤＬ形式に符号化し（図３で説明されるように）、符号化識別子を第１のモバイルユーザデバイス１２０１に送信することができる。あるいは、信頼できる第三者１２０２は、第１のモバイルユーザデバイス１２０１に直接識別子を送信することができ、第１のモバイルユーザデバイス１２０１が識別子自体を符号化することができる。さらなる代替手段では、信頼できる第三者１２０２が、識別子をＭＤＬに符号化し、次いで、音声に符号化することができる。さらに、さらなる代替手段では、識別子は音声であり得る。

識別子（符号化されていない、ＭＤＬに符号化された、または、音声の）は、第１のモバイルユーザデバイス１２０１上のメモリ１２０５上に格納される。例えば、識別子は、着信音として受信することができる。

第１のモバイルユーザデバイス１２０１のユーザが特定の金銭的価値の使用を希望する際、第２のデバイス１２０７に対し、スピーカを通じて音声１２０６として識別子を再生することができる。識別子が音声形式でない場合は、第１のモバイルユーザデバイス１２０１は、識別子を音声形式に符号化することができる（図３で説明されるように）。第２のデバイス１２０７は、商業デバイスまたは別のユーザデバイスであり得る。

第２のデバイス１２０７は、識別子の有効性を確認し、通信ネットワーク１２０９上で信頼できる第三者１２０２（または、仲介物１２０８）と連絡を取ることによって特定の金銭的価値の受信を実施し、識別子を送信することができる。第２のデバイス１２０７は、信頼できる第三者１２０２に送信する前に、受信した音声をショートコードまたは他のコードに復号することができる。一代替手段では、第２のデバイス１２０７は、信頼できる第三者１２０２を呼び出し、第１のデバイスからの音声を信頼できる第三者１２０２へ中継することによって、識別子を送信する。

信頼できる第三者１２０２（または、仲介物１２０８）は、特定の金銭的価値と識別子を一致させることによって、データベース１２０４内で識別子を検証する。検証ステップは、不正行為の防止に役立てるための特定の金銭的価値の使用に対する制約を含み得、例えば、特定の金銭的価値は、地理的な位置（例えば、ＬｏｎｄｏｎまたはＵＫ）への制限も、特定のベンダーまたはベンダーファミリー（例えば、Ｓｔａｒｂｕｃｋｓ）への制限も、特定の時間への制限も、特定の目的（例えば、本の購入のみ）への制限も有し得る。

代替の実施形態では、特定の金銭的価値は、制約の範囲内で再利用が可能であり、例えば、特定の金銭的価値は、１日１回または週に５回の利用が可能である。

信頼できる第三者１２０２は、特定の金銭的価値の反復使用を防ぐため、識別子を使用済みとマーク付けすることができる。検証された時点で、信頼できる第三者１２０２は、第２のデバイス１２０７に関連する銀行または他の金銭口座への特定の金銭的価値の転送を実施することができる。信頼できる第三者１２０２は、識別子の有効性の検証を第２のデバイス１２０７に送信することができる。したがって、第２のデバイス１２０２または第２のデバイスのユーザは、第１のデバイス１２０１のユーザによって着手されたトランザクションの終結を促進することができる（例えば、商品もしくはサービスを提供することによって、または、会場へのアクセスを提供することによって）。

その上、上記の実施形態は、ＰＫＩなどの暗号化を使用することによって変更することができ、これは、音声を使用して起こり得るハンドシェイクプロセスを伴う場合がある。しかし、特定の金銭的価値は第２のデバイス１２０７によって即座に検証されるため、これは、第１のデバイス１２０１と第２のデバイス１２０７との安全な接続に対する要件を軽減することができる。

上記で説明されるものに対する代替の実施形態では、第１のデバイス１２０１をパイプとして使用し、第２のデバイス１２０７に対するトランザクションを検証することができる。これは、第１のデバイス１２０１は接続されているが、第２のデバイス１２０７は接続されていない場合に有用であり得る。

図１３を参照して、そのような実施形態について説明する。

第１のモバイルユーザデバイス１３０１（転送側のデバイス）が示されている。特定の金銭的価値は、信頼できる第三者１３０２から第１のデバイス１３０１によって要求される。信頼できる第三者１３０２は、特定の金銭的価値に対する識別子を第１のモバイルユーザデバイス１３０１に送信する。

第１のモバイルユーザデバイス１３０１は、トランザクションに対応する音声１３０３を第２のデバイス１３０４（受信デバイス）に送信する。

第２のデバイス１３０４は、信頼できる第三者１３０２と通信するためのリレーとして第１のデバイス１３０１を使用して、特定の金銭的価値を検証することができる。例えば、第２のデバイス１３０４は、信頼できる第三者１３０２まで中継される暗号化メッセージ（認証要求１３０５）を送信することができ、信頼できる第三者１３０２は、第２のデバイス１３０３によって検証され得る暗号化された応答（認証価値１３０６）で応答することができる。あるいは、第２のデバイス１３０３は、信頼できる第三者１３０２からの秘密の応答を要求することができる（すなわち、第２のデバイス１３０３と信頼できる第三者１３０２のみが知っている質問に対する回答。不正行為を阻止するため、質問は、一回限りの質問であり得る）。信頼できる第三者１３０２および第２のデバイス１３０３は、認証プロセスを管理するための認証エンジン１３０７および１３０８を含み得る。

特定の金銭的価値は、通常、現金、カードまたはマイクロペイメントで行われる支払いを含み得る。

本発明のこの実施形態は、仮想の送金に使用することができる。

図１４ａ、１４ｂおよび１４ｃを参照して、本発明のさらなる実施形態について説明する。

Ｃｈｉｒｐユーザインターフェース（ＵＩ）は、３つの機能（聴取、Ｃｈｉｒｐおよび格納）専用の３つの画面（Ｓ１〜３）から構成される。

この実施形態で言及されるＣｈｉｒｐは、図３を参照して説明されるショートコードを符号化する音声の送信である。しかし、代替の実施形態では、Ｃｈｉｒｐは、図１０、１１、１２、１３または１５で使用できるような任意のデータを符号化する音声も含み得る。

初期ロード後、音声データ受信に対して適正なモードにアプリケーションをすぐに切り替えられるように、アプリケーションはデフォルトのＳ１（聴取）になる。

（Ｓ１）聴取：Ｓ１は、マイクロホンを起動し、デバイスを「検出」モードに切り替え、Ｃｈｉｒｐ信号を聴取し始める。Ｓ１は、リアルタイムでの波形表示によって、マイクロホンを介して検出可能なすべての音事象（人間の耳で容易に検出可能または明らかでなくなる音まで。その音も含む）をリアルタイムで表示する。

ユーザは、ａ）マイクロホンがアクティブ状態であること、および、ｂ）素早い目視検査によって音声検出レベル（マイクロホンの感度）が適切に設定されていることを容易に識別することができる。

また、ユーザは、ローカル環境がｃ）Ｃｈｉｒｐの送信または受信前に、比較的騒々しいかまたは静かであるか、そして、それに応じて音声データの転送の達成が難しいかまたは簡単かを決定することができる。直前の数秒間に示されるピークおよび周囲の音エネルギーの測定値は、波形を動的に着色し直す（悪状態の場合は赤色、許容値は黄色、最適状態の場合は緑色）ことによって表示される。

これらの３つの変数を表示するため、ユーザが複数の視覚様式を利用できるようにすることが予想される。

音視覚化エリアの真下では、英数字またはアイコンを含む一連の「タンブラ」は、検出順に検出されるように、無線音声入力から捉えた復号データを表示する。

また、Ｓ１は、Ｓ２へのリンクも含む（Ｃｈｉｒｐボタンを見ること）。

（Ｓ２）Ｃｈｉｒｐ：Ｓ２は、格納されたデータかまたは最近捕捉されたデータを共有するための一連の異なるデータプロトコルを集約する。画面の上部では、ユーザは、受信された最後の英数字のショートコードを見ることができ、その真下では、視覚、可聴およびテキスト分配方法を含む（しかし、これらに限定されない）、そのショートコードを共有するための多くの利用可能な方法を見ることができる。

可聴方法内では、Ｃｈｉｒｐとマーク付けされたボタンを押すと、コードは、他のＣｈｉｒｐクライアントアプリケーション用に音で再表現される。

視覚方法内では、ショートコードは、ＥＰＯＳシステムを使用して、考えられる引き換え用のＱＲコード(登録商標)として動的に表現および表示される（外部のスキャンまたは画像取込デバイスを介して）。また、他のオープンソース、または、Ａｚｔｅｃコード、セマコード、Ｍｉｃｒｏｓｏｆｔ高密度コードを含む２Ｄ視覚的コードのファミリーの専用メンバーもサポートされ得る。

テキスト方法内では、Ｔｗｉｔｔｅｒ、ＥメールまたはＳＭＳクライアントアプリケーションを開いて、これらのアプリケーションのコンテンツフィールドに現在アクティブ状態のショートコードを事前に追加するための手段が提供される。これらのオペレーションのすべては、シングルクリックで達成される。さらに便利なことに、ＴｗｉｔｔｅｒまたはＥメール共有の場合、受信者の利益のためのクリック可能なリンクは、適正なプロトコルタイプとサーバアドレスを単にコードの先頭に追加することによって、Ｃｈｉｒｐアプリケーションによって構築され、通常、これは「ｈｔｔｐ：／／ｃｈｉｒｐ．ｉｏ／」であり得るが、好ましくは、（例えば）Ｃｈｉｒｐにリンクされたファイルは、ｆｔｐまたは他のファイル共有プロトコルを使用したアプリケーションを介して取り扱われる場合がある。

呼び出されるべきすべての外部のアプリケーションまたは機能は、その機能に適切なアイコンでマーク付けすることができる。

最後に、上記で与えられた手段の一方または他方によるＣｈｉｒｐの検出またはＣｈｉｒｐアプリケーションへのデータの受信によって、ローカルファイルが起動されるかまたはアクセス可能になる場合、アイコンは、感嘆符を表示することができ、そのコンテンツは、コンテンツのタイトル（例えば、「Ｌｕｃｋｙ Ｃｈｉｒｐ」）を表示するアイコンまたはボタンをクリックすることによって利用可能にすることができ、そのコンテンツ（音声、映像、グラフィックス、ＨＴＭＬ、対話式ゲームデータまたは機能）は、適切なクライアントアプリケーションを使用することによって開くことも、ホストアプリケーション自体で取り扱うこともできる。

Ｓ２は、単一ボタンを介して各共有方法が呼び出し可能な状態で、そして、各サブアプリケーションが知的に自動的に補われた状態で、単一画面にすべての共通の共有機能を集約する。

あるいは、クリップボード（コピーバッファ）にショートコード文字列を事前に追加することもでき、ユーザは、「デスクトップ」またはＯＳレベルに切り替えることによってＣｈｉｒｐアプリケーションを離れ、ユーザの好ましいメール、Ｔｗｉｔｔｅｒ、２Ｄコード作成アプリケーションへナビゲートし、そこから変換するかまたは送信するかの何れか（または両方）のためショートコードにペーストすることができる。Ｓ２に示される方法は、共有方法を制限せずに必要なフローを予想することによって、明らかに高速であり、より効率的な共有を可能にするため、好ましい。

さらなる代替手段は、動的に作成されたプロキシリターンＥメールもしくはＳＭＳアドレスの使用および／または適切で永久的な「真の」送信トレイへのＣＣ送信によって、さらに迅速なロード時間のための軽量の「アウトバウンドのみ」のアプリケーションを使用することである。このようにして（プロキシアカウントを使用して）、希望する場合は、好都合なことに、Ｃｈｉｒｐを他の通信とは別々に保持することができる。

また、Ｓ２は、サーバ側での後の分析のためおよびＳ３上での表示のため、行われた共有の数および共有モードを記録することができる。

Ｓ３（格納）インターフェースは、ローカルでまたはサーバを介しての何れかでＣｈｉｒｐと一致した一意な識別子のリポジトリとして機能する。

第１のセクションは、最近の「受信トレイ」活動（最近受信したｎ個のＣｈｉｒｐ（ｎはユーザが定義する）を示すためのトグル機能の付いた、逆の順序での最近受信した５つのＣｈｉｒｐ）を示す。

Ｃｈｉｒｐは、サーバにアクセスすることによって決定することも、デバイス側の情報から決定することもできる状態と関連し得る。例えば、サーバ側のＣｈｉｒｐと関連するデータが未だアップロードされていない場合は、Ｃｈｉｒｐの状態は「未だ利用不可能」であるか、または、Ｃｈｉｒｐと関連するデータが期限切れの場合（例えば、データが期間限定のバウチャのような時間依存性である場合）は、Ｃｈｉｒｐの状態は「期限切れ」であり得、サーバ側で未だＣｈｉｒｐがアクセスされていない場合は、状態は「アクセスなし」であるか、または、Ｃｈｉｒｐがアクセス条件と関連している場合（特定の場所または特定の時間の間でなければならないなど）は、状態はその条件と関連するかもしくはＣｈｉｒｐの状態は「隠された」状態であり得、そういう場合には、Ｃｈｉｒｐは表示すらされない可能性がある。状態は、Ｃｈｉｒｐのバックグラウンドの着色によってユーザインターフェース内に示すことができる。

ページは、ユーザの略歴、地理またはタスクコンテキスト別に、音声（音声表現はローカルに格納される）を介して即座に送信できるアイテムを大まかに細分化する。

略歴は、Ｆａｃｅｂｏｏｋ、ＬｉｎｋｅｄＩｎ、Ｔｗｉｔｔｅｒなどのソーシャルネットワークプロフィールアドレスを含む、共有可能なマイクロ形式としてのユーザの詳細な連絡先、ホームページおよび／または仕事の詳細を含み得る。音声送信用にこれらのデータアイテムを準備するため、ユーザは、これらのサービスのそれぞれに対して、彼または彼女の一意なユーザ名を入力しなければならない場合があり、Ｃｈｉｒｐアプリケーションは、簡単な共有のために音声として符号化された完全なｈｔｔｐ：／／アドレスを返すか、または、一意なユーザ名が見つからない場合は、不明瞭性解消を要求する。

地理は、地理的に位置付けされたすべてのＵＲＬを含み、例としては、地図アプリケーション上で最近検索された場所（例えば、地図検索のユーザ履歴から入手）、場所に基づくソーシャルネットワーク上の地域別「チェックイン」などが挙げられる。典型的な使用例は、提案された会合場所、お勧めの小売業者などのワンクリック共有である。

コンテキストに即した格納は、１つのアプリケーションもしくはアプリケーションクラス、または、デバイスの態様に関連するアイテムを含み得、例としては、１つまたは複数のブラウザに対する「お気に入り」もしくは履歴、最近再生された音楽、最近かけた電話からの電話番号、最近受信／送信したＥメールからのＥメールアドレス、連絡先リストからの電話番号、カレンダーイベント、または、デバイス上の最新の活動に関連するデータ（例えば、ユーザが最近地図アプリケーションを閲覧し、その上で場所を特定した場合、データアイテムは地図位置であり得る）が挙げられる。

送信できるアイテムは、カメラロール上に格納された画像またはデバイス上のアプリケーションのリストなどの任意のローカルに格納されたデータであり得る。代替の実施形態では、任意のウェブベースのデータも送信することができ、そのようなアイテムは、Ｆａｃｅｂｏｏｋの「いいね（ｌｉｋｅ）」またはＡｍａｚｏｎのほしい物リスト／おすすめ商品であり得る。

大抵の場合、適切なファイルハンドラまたは視覚表現が存在するかどうかを決定するために解析されるようなアイテム文字列、例えば、ｔｗｉｔｔｅｒ．ｃｏｍ文字列は、Ｔｗｉｔｔｅｒクライアントが取り扱い（ユーザによって定義されるように）、適切なアイコンが与えられる。

それに加えて、データアイテムは、デバイス上にローカルに格納されたゲームに関連する「トークン」（ピアツーピアで持ち込むことも、販売することも、取引することも可能なゲーム内のコンテンツ）であり得る。

それに加えて、Ｓ３では、受信および送信されたユーザＣｈｉｒｐの記録を表示することができ、共有メカニズムを奨励するため、場合により、高い共有比に基づいて、格納されたコンテンツのロックを解除するポイントが、ポイントに授与され得る。

ユーザは、リフレッシュを押すことによって、データセット（例えば、日替わりセール）を手動で「リフレッシュ」することができる。次いで、サーバは、このトピックに関連する新しいＣｈｉｒｐに対してクエリを行う（この場合、今日の特売品）。

代替の実装形態では、アプリケーションがロードされている場合、または、リアルタイムのメッセージングプロトコルを介して、例えばＸＭＰＰ上で、新しいデータがクライアントアプリケーション上の１つまたは複数の関連セットにプッシュされる場合、データは自動リフレッシュされる。

利用可能なセットのリストは、動的に形成することができる（すなわち、即座にＣｈｉｒｐ可能な情報の新しいセットは、サーバ上で定義することができ、デバイス上のアプリケーションは、サーバと連携して、ユーザにＣｈｉｒｐへのアクセスを提供することができる）。

図１５を参照して、さらに、さらなる実施形態について説明する。

第１のデバイスと第２のデバイスの両方の送信を聞き取るデバイスによる中間者攻撃に関して、第１のデバイスと第２のデバイスとの間の送信のセキュリティを改善するため、発明者は、両デバイスが同時に送信できることを発見した。聴取側のデバイスは、マイクロホンですべての音声を検出し、検出した音声からそれら自体の送信信号を取り除くことによって、送信側のデバイスの音声信号を検出することができる。この不明瞭化プロセスは、無計画な中間者攻撃において不利な点となり得る。

また、音声信号を同時に送信する両デバイスは、美的に心地良い「デュエット」を提供することもできる。

また、音声信号を同時に送信する両デバイスは、データ送信時間を削減することもできる。これは、同期的に行える場合に２つのデバイス間で暗号化鍵を共有する際に、特に有用であり得る。

図１５は、第１のデバイス１５０１と第２のデバイス１５０２とを示す。２つのデバイスは、交換に着手して、デバイスの後の音声同時送信を調整することができる。交換は、音声を使用してダイレクト無線インターフェース上で起こることも、電気通信システムを通じてなど、別のチャネルを通じて事前に定義されることも調整されることもあり得る。交換は、トーンの交換を伴う。調整は、時間同期化と基準ピッチトーンとを含み得る。好ましくは、デバイスの少なくとも１つは、モバイルテレコミュニケーションデバイスである。

代替の実施形態では、２つのデバイスは、リアルタイムのフィードバックモデルでデバイスの受信した送信信号を使用して、デバイスのさらなる送信を適合させることによって、それら自体の同時送信内で、それらの同時送信を調整する。

聴取者に音楽のように聞こえることにより同時送信がより美的に心地良く現れ得るというような同じ音楽キーを選択することによって、送信を調整することができる。送信を調整する他の方法は、和音内で音声を再生成するデバイス（例えば、各デバイスは、３和音の１つまたは複数を送信することができる）を含み得る。

第１のデバイス１５０１は、第１のデバイス１５０１内のスピーカ１５０４上で第１の音声信号１５０３を送信することができる。第２のデバイス１５０２は、第２のデバイス内のスピーカ１５０６上で第２の音声信号１５０５を同時に（または音声信号の重複をもたらすほど十分に同時に）送信することができる。

音声信号１５０３、１５０５は、データを符号化することができる。データは、図３で説明されるような方法を使用して、エンコーダ１５０７によって符号化することができる。データ送信が一方向の場合、音声信号の一方の信号１５０３のみがデータを符号化することができる。あるいは、データ送信が双方向の場合、両方の音声信号がデータを符号化することができる。

データ送信信号を受信するデバイス（すなわち、第１および／または第２のデバイス１５０２）は、マイクロホン１５０８を使用して音声を聞き取り、次いで、信号プロセッサ１５０９を使用して、受信した音声信号を処理し、それら自体の送信信号を取り除くことができる。処理された信号は、デコーダ１５１０によって復号し、音声信号内に格納されたいかなるデータも回収することができる。

一実施形態では、ピッチ、タイミングおよび音色のジッタリングスケジュール（発振器の波形）は、デバイス間で交換して、不明瞭化プロセスに役立てることができる。スケジュール交換は、調整段階の一部であり得る。

本発明の実施形態において符号化された任意の音声に関連して、音声の一部を符号化して、それらの特徴を他の特徴と可聴音声で区別することができる。例えば、データの存在を示すためにタグを開閉するなど、プロトコルが構造上の共通の特徴を含む場合、これらの特徴は、共通の音で定義することができる（例えば、ベントノート、急降下、トリル音または美的（非コード伝達）事象）。それに加えて、データを符号化して、関連するデータとのその区別可能性を補助することができる。例えば、５ポンドを表すデータは、１０ポンドを表す音声と完全に区別可能に符号化することができ、データが暗号化などの他の非共通の要素を含む場合、音声は、区別可能性を補助するために共通の要素を含み得、例えば、５ポンドのトークンを表す音声の暗号化された部分を共通の音声部分と組み合わせて、トークンが５ポンドを表すことを示すことも、ＵＲＬまたはＪＰＥＧを表す音声の符号化された部分が一意な音声部分を含み、音声がＵＲＬに関連するかまたは音声がＪＰＥＧもしくは写真に関連するかを示すこともできる。この音声部分は、受信側のデバイスで復号することも、音声のコンテンツタイプを聴取者に可聴音声で示すためだけに存在することもできる。符号化されたデータタイプを示すことと同様に、音声部分は、誰からデータが送信されたか（例えば、音声の送信機）またはデータの発信元／所有者（例えば、データを発信／所有する会社、例えば、データがバウチャであれば、バウチャを引き換える会社またはバウチャスキームオペレータ）を示すことができる。

本発明は、コンピュータハードウェア上またはハードウェア自体の中で実行するソフトウェアとして実装できることが理解されよう。

本発明のいくつかの実施形態の潜在的利点は、データは音声で送信され、すべてのモバイルデバイスは音声の受信および送信が可能なため、些細な変更が施すことでほとんどのモバイルデバイスでシステムを利用できることである。

本発明のいくつかの実施形態のさらなる潜在的利点は、デバイスの一方または両方がオフライン状態の際に、デバイス間でデータを通信できることである。

本発明はその実施形態の説明によって示され、本発明はかなり詳細に説明されてきたが、添付の特許請求の範囲をそのような詳細に制限することまたは何らかの方法で限定することは出願人の意図ではない。追加の利点と変更形態は、当業者であれば容易に明らかであろう。したがって、そのより幅広い態様での本発明は、装置および方法を代表する具体的な詳細に限定されず、説明に役立つ実例が示され、説明される。それに応じて、そのような詳細からの逸脱は、出願人の本発明の一般概念の精神または範囲から逸脱することなく行うことができる。

Claims (14)

1. データを送信するためのデバイスにおいて、
   サーバからデータと関連付けられたショートコードを受信するよう構成された受信機と、
   前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
   可聴音声の再生成のために前記信号を送信するよう構成された送信機と、
   送信する前記データをユーザが決定することができるよう構成されたユーザ入力デバイスと、
   前記データを前記サーバに送信するよう構成されたトランシーバとを含み、
   前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化することを特徴とするデバイス。
2. 請求項１に記載のデバイスにおいて、前記ショートコードは、前記データのインデックスであることを特徴とするデバイス。
3. 請求項１又は２に記載のデバイスにおいて、前記信号は、音楽記述言語形式であることを特徴とするデバイス。
4. データを受信するためのデバイスにおいて、
   マイクロホンで検出された音声信号を受信するよう構成された受信機と、
   前記音声信号をショートコードに復号するよう構成されたデコーダと、
   前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含み、前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化し、前記データがトランシーバから前記サーバに送信され、送信する前記データが、ユーザ入力を介して、ユーザ入力デバイスで決定されることを特徴とするデバイス。
5. 請求項４に記載のデバイスにおいて、前記データへのアクセスは、前記データを前記デバイスに回収することを含むことを特徴とするデバイス。
6. 請求項４又は５に記載のデバイスにおいて、前記音声信号は、請求項１乃至３の何れか１項に記載のデバイスから受信することを特徴とするデバイス。
7. データを送信するためのサーバにおいて、
   トランシーバからデータを受信するよう構成された受信機と、
   ショートコードをデータと関連付けるよう構成されたプロセッサと、
   前記関連付けを格納するよう構成されたメモリと、
   前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
   可聴音声の再生成のために第１のデバイスに前記信号を送信するよう構成された送信機と
   を含み、
   前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化し、送信する前記データが、ユーザ入力を介して、ユーザ入力デバイスで決定されることを特徴とするサーバ。
8. 請求項７に記載のサーバにおいて、第２のデバイスから前記ショートコードを受信するよう構成された受信機と、前記受信したショートコードと関連付けられた前記データへのアクセスを前記第２のデバイスに提供するよう構成されたプロセッサとをさらに含むことを特徴とするサーバ。
9. データを送信するためのデバイスにおいて、
   請求項１乃至３の何れか１項に記載の前記デバイスによって生成された信号又は請求項７又は８に記載の前記サーバによって生成された信号を格納するよう構成されたメモリと、
   前記格納された信号から音声信号を生成するよう構成された音声出力と
   を含むことを特徴とするデバイス。
10. データを送信するための方法において、
    ａ）送信するデータを、ユーザ入力を介して、ユーザ入力デバイスで決定するステップと、
    ｂ）サーバに前記データを送信するステップと、
    ｃ）前記サーバからデータと関連付けられたショートコードを受信するステップと、
    ｄ）前記ショートコードを可聴的に一意な形式の信号に符号化するステップと、
    ｅ）可聴音声の再生成のために前記信号を送信するステップとを含み、前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化することを特徴とする方法。
11. データを受信するための方法において、
    ａ）マイクロホンを介して音声信号を受信するステップと、
    ｂ）前記音声信号をショートコードに復号するステップと、
    ｃ）前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするステップとを含み、前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化し、前記データがトランシーバから前記サーバに送信され、送信する前記データが、ユーザ入力を介して、ユーザ入力デバイスで決定されることを特徴とする方法。
12. データを送信するための方法において、
    サーバにおいて、
    ａ）トランシーバから送信するデータを受信するステップと、
    ｂ）ショートコードをデータと関連付けるステップと、
    ｃ）前記ショートコードを可聴的に一意な形式の信号に符号化するステップと、
    ｄ）可聴音声の再生成のためにデバイスに前記信号を送信するステップとを含み、前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化し、送信する前記データが、ユーザ入力を介して、ユーザ入力デバイスで決定されることを特徴とする方法。
13. データを通信するためのシステムにおいて、
    ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
    前記関連付けを格納するよう構成されたメモリ
    を含むサーバと、
    前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
    スピーカ、および、
    前記スピーカ上での可聴音声の再生成のために前記信号を送信するよう構成された送信機
    を含む第１のデバイスと、
    マイクロホン、
    前記マイクロホンで検出された音声信号を受信するよう構成された受信機、
    前記音声信号をショートコードに復号するよう構成されたデコーダ、および、
    前記ショートコードを使用して、前記サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
    を含む第２のデバイスと、
    送信する前記データをユーザが決定することができるよう構成されたユーザ入力デバイスと、
    前記データを前記サーバに送信するよう構成されたトランシーバと
    を含み、
    前記ショートコードは前記サーバにおいてグローバルに一意であり、前記信号が一定量のデータを符号化することを特徴とするシステム。
14. 請求項１０乃至１２の何れか１項に記載の方法を実行するよう構成されることを特徴とするコンピュータプログラム。

Images