"データを送信するためのデバイスにおいて、サーバからデータと関連付けられたショートコードを受信するよう構成された受信機と、前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、可聴音声の再生成のために前記信号を送信するよう構成された送信機とを含み、前記ショートコードはグローバルに一意であることを特徴とするデバイス。請求項1に記載のデバイスにおいて、前記可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および/または音楽を含むことを特徴とするデバイス。請求項1または2に記載のデバイスにおいて、前記ショートコードは、アプリケーションヘッダを含むことを特徴とするデバイス。請求項1乃至3の何れか1項に記載のデバイスにおいて、前記ショートコードは、前記データのインデックスであることを特徴とするデバイス。請求項1乃至4の何れか1項に記載のデバイスにおいて、モバイルテレコミュニケーションデバイス用のコントローラであることを特徴とするデバイス。請求項1乃至5の何れか1項に記載のデバイスにおいて、前記受信機は、モバイルテレコミュニケーションネットワーク上で前記ショートコードを受信するよう構成されることを特徴とするデバイス。請求項1乃至6の何れか1項に記載のデバイスにおいて、前記ショートコードは、既定の固定長のものであることを特徴とするデバイス。請求項7に記載のデバイスにおいて、前記ショートコードの長さは、32~1024ビットであることを特徴とするデバイス。請求項1乃至8の何れか1項に記載のデバイスにおいて、前記信号は、音楽記述言語形式であることを特徴とするデバイス。請求項9に記載のデバイスにおいて、前記信号は、MIDI形式であることを特徴とするデバイス。請求項1乃至10の何れか1項に記載のデバイスにおいて、前記信号は、冗長符号化を含むことを特徴とするデバイス。請求項11に記載のデバイスにおいて、前記信号は、冗長性に対してリードソロモン符号を使用することを特徴とするデバイス。請求項1乃至12の何れか1項に記載のデバイスにおいて、前記データは、URLであることを特徴とするデバイス。請求項1乃至13の何れか1項に記載のデバイスにおいて、送信する前記データをユーザが決定することができるよう構成されたユーザ入力デバイスと、前記データを前記サーバに送信するよう構成されたトランシーバとをさらに含むことを特徴とするデバイス。データを受信するためのデバイスにおいて、マイクロホンで検出された音声信号を受信するよう構成された受信機と、前記音声信号をショートコードに復号するよう構成されたデコーダと、前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含み、前記ショートコードはグローバルに一意であることを特徴とするデバイス。請求項15に記載のデバイスにおいて、前記音声信号は、少なくとも何らかの鳥の鳴き声および/または音楽を含むことを特徴とするデバイス。請求項15または16に記載のデバイスにおいて、前記ショートコードは、アプリケーションヘッダを含むことを特徴とするデバイス。請求項17に記載のデバイスにおいて、前記アプリケーションヘッダを読み取り、前記アプリケーションヘッダに応じて前記ショートコードの処理を決定するよう構成されたプロセッサをさらに含むことを特徴とするデバイス。請求項15乃至18の何れか1項に記載のデバイスにおいて、前記ショートコードは、前記データのインデックスであることを特徴とするデバイス。請求項15乃至19の何れか1項に記載のデバイスにおいて、モバイルテレコミュニケーションデバイス用のコントローラであることを特徴とするデバイス。請求項15乃至20の何れか1項に記載のデバイスにおいて、前記トランシーバは、モバイルテレコミュニケーションネットワーク上で前記データにアクセスするよう構成されることを特徴とするデバイス。請求項15乃至21の何れか1項に記載のデバイスにおいて、前記ショートコードは、既定の固定長のものであることを特徴とするデバイス。請求項22に記載のデバイスにおいて、前記ショートコードの長さは、32~1024ビットであることを特徴とするデバイス。請求項15乃至23の何れか1項に記載のデバイスにおいて、前記デコーダは、ピッチ追跡を使用して前記音声信号の復号を補助することを特徴とするデバイス。請求項15乃至24の何れか1項に記載のデバイスにおいて、前記データは、URLであることを特徴とするデバイス。請求項15乃至25の何れか1項に記載のデバイスにおいて、前記データにアクセスするステップは、前記データを前記デバイスに回収するステップを含むことを特徴とするデバイス。請求項15乃至26の何れか1項に記載のデバイスにおいて、前記音声信号は、請求項1乃至14の何れか1項に記載のデバイスから受信することを特徴とするデバイス。請求項15乃至27の何れか1項に記載のデバイスにおいて、前記音声信号を受信した際に前記ショートコードおよび/または音声スペクトルを表示するよう構成されたディスプレイをさらに含むことを特徴とするデバイス。データを非同期送信するためのデバイスにおいて、サーバからショートコードを受信するよう構成された受信機と、前記受信したショートコードを格納するよう構成されたメモリと、前記受信したショートコードをデータと関連付けるよう構成されたプロセッサと、前記受信したショートコードを第2のデバイスに送信するよう構成された送信機と、前記関連付けを前記サーバに送信するよう構成された送信機とを含むことを特徴とするデバイス。請求項29に記載のデバイスにおいて、前記受信したショートコードを送信する際、前記サーバに接続できないことを特徴とするデバイス。請求項29または30に記載のデバイスにおいて、前記受信したショートコードは、ダイレクトインターフェース上で前記第2のデバイスに送信することを特徴とするデバイス。請求項29乃至31の何れか1項に記載のデバイスにおいて、前記ダイレクトインターフェースは、音声インターフェースであることを特徴とするデバイス。請求項29乃至32の何れか1項に記載のデバイスにおいて、前記デバイスは前記第2のデバイスと並置されることを特徴とするデバイス。請求項29乃至33の何れか1項に記載のデバイスにおいて、前記関連付けを前記サーバに送信する前に、前記ショートコードを受信し、次いで、送信するよう構成されることを特徴とするデバイス。請求項29乃至34の何れか1項に記載のデバイスにおいて、送信する前記データをユーザが決定することができるよう構成されたユーザ入力デバイスをさらに含むことを特徴とするデバイス。データを送信するためのサーバにおいて、ショートコードをデータと関連付けるよう構成されたプロセッサと、前記関連付けを格納するよう構成されたメモリと、前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、可聴音声の再生成のためにデバイスに前記信号を送信するよう構成された送信機とを含み、前記ショートコードはグローバルに一意であることを特徴とするサーバ。請求項36に記載のサーバにおいて、前記可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および/または音楽を含むことを特徴とするサーバ。請求項36または37に記載のサーバにおいて、前記ショートコードは、アプリケーションヘッダを含むことを特徴とするサーバ。請求項36乃至38の何れか1項に記載のサーバにおいて、前記ショートコードは、データのインデックスであることを特徴とするサーバ。請求項36乃至39の何れか1項に記載のサーバにおいて、前記送信機は、モバイルテレコミュニケーションネットワーク上で前記信号を送信するよう構成されることを特徴とするサーバ。請求項36乃至40の何れか1項に記載のサーバにおいて、前記送信機は、モバイルテレコミュニケーションネットワーク上で前記信号を送信するよう構成されることを特徴とするサーバ。請求項41に記載のサーバにおいて、前記信号は、着信音としてSMSチャネル上で送信することを特徴とするサーバ。請求項36乃至42の何れか1項に記載のサーバにおいて、前記ショートコードは、既定の固定長のものであることを特徴とするサーバ。請求項43に記載のサーバにおいて、前記ショートコードの長さは、32~1024ビットであることを特徴とするサーバ。請求項36乃至44の何れか1項に記載のサーバにおいて、前記信号は、音楽記述言語形式であることを特徴とするサーバ。請求項45に記載のサーバにおいて、前記信号は、MIDI形式であることを特徴とするサーバ。請求項36乃至46の何れか1項に記載のサーバにおいて、前記信号は、冗長符号化を含むことを特徴とするサーバ。請求項36乃至47の何れか1項に記載のサーバにおいて、前記信号は、冗長性に対してリードソロモン符号を使用することを特徴とするサーバ。請求項36乃至48の何れか1項に記載のサーバにおいて、前記データは、URLであることを特徴とするサーバ。請求項36乃至49の何れか1項に記載のサーバにおいて、前記デバイスから送信する前記データを受信するよう構成された受信機をさらに含むことを特徴とするサーバ。請求項36乃至50の何れか1項に記載のサーバにおいて、前記デバイスは、モバイルテレコミュニケーションデバイスであることを特徴とするサーバ。請求項36乃至51の何れか1項に記載のサーバにおいて、第2のデバイスから前記ショートコードを受信するよう構成された受信機と、前記受信したショートコードと関連付けられた前記データへのアクセスを前記第2のデバイスに提供するよう構成されたプロセッサとをさらに含むことを特徴とするサーバ。請求項52に記載のサーバにおいて、前記データへのアクセスは、前記第2のデバイスに前記データを送信するステップを含むことを特徴とするサーバ。データを非同期送信するためのサーバにおいて、メモリにショートコードを保存するよう構成されたプロセッサと、前記保存したショートコードをデバイスに送信するよう構成された送信機と、前記保存したショートコードとデータとの間の関連付けを受信するよう構成された受信機と、前記保存したショートコードと前記データとの間の前記関連付けを格納するよう構成されたメモリと、第2のデバイスから要求を受信するよう構成された受信機において、前記要求は前記保存したショートコードを含む、受信機と、前記要求を前記データと関連付けるよう構成されたプロセッサとを含むことを特徴とするサーバ。データを送信するためのデバイスにおいて、請求項1乃至14の何れか1項に記載のデバイスまたは請求項36乃至53の何れか1項に記載のサーバによって生成された信号を格納するよう構成されたメモリと、前記格納された信号から音声信号を生成するよう構成された音声出力とを含むことを特徴とするデバイス。トランザクションを認証するためのデバイスにおいて、ユーザから認証入力を受信するよう構成された入力デバイスと、ユーザ識別情報を格納するよう構成されたメモリと、ユーザ識別情報および前記認証入力を可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、可聴音声の再生成のために前記信号を送信するよう構成された送信機とを含むことを特徴とするデバイス。データを送信するための方法において、aサーバからデータと関連付けられたショートコードを受信するステップと、b前記ショートコードを可聴的に一意な形式の信号に符号化するステップと、c可聴音声の再生成のために前記信号を送信するステップとを含み、前記ショートコードはグローバルに一意であることを特徴とする方法。データを受信するための方法において、aマイクロホンを介して音声信号を受信するステップと、b前記音声信号をショートコードに復号するステップと、c前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするステップとを含み、前記ショートコードはグローバルに一意であることを特徴とする方法。データを非同期送信するための方法において、aサーバからショートコードを受信するステップと、bデバイス上に前記受信したショートコードを格納するステップと、c前記受信したショートコードをデータと関連付けるステップと、d前記受信したショートコードを第2のデバイスに送信するステップと、e前記関連付けを前記サーバに送信するステップとを含むことを特徴とする方法。データを送信するための方法において、aショートコードをデータと関連付けるステップと、b前記ショートコードを可聴的に一意な形式の信号に符号化するステップと、c可聴音声の再生成のためにデバイスに前記信号を送信するステップとを含み、前記ショートコードはグローバルに一意であることを特徴とする方法。データを非同期送信するための方法において、aショートコードを保存するステップと、b前記保存したショートコードを第1のデバイスに送信するステップと、c前記保存したショートコードとデータとの間の関連付けを受信するステップと、d前記保存したショートコードと前記データとの間の前記関連付けを格納するステップと、e第2のデバイスから要求を受信するステップにおいて、前記要求は前記保存したショートコードを含む、ステップと、f前記要求を前記データと関連付けるステップとを含むことを特徴とする方法。データを送信するための方法において、メモリに格納された信号から音声信号を生成するステップにおいて、前記格納された信号は請求項57または請求項60のどちらかに記載の方法によって以前に生成される、ステップを含むことを特徴とする方法。トランザクションを認証するための方法において、a入力デバイスを介してユーザから認証入力を受信するステップと、bユーザ識別および前記認証入力を可聴的に一意な形式の音声信号に符号化するステップと、c可聴音声の再生成のために前記音声信号を送信するステップとを含むことを特徴とする方法。データを通信するためのシステムにおいて、ショートコードをデータと関連付けるよう構成されたプロセッサ、および、前記関連付けを格納するよう構成されたメモリを含むサーバと、前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、スピーカ、および、前記スピーカ上での可聴音声の再生成のために前記信号を送信するよう構成された送信機を含む第1のデバイスと、マイクロホン、前記マイクロホンで検出された音声信号を受信するよう構成された受信機、前記音声信号をショートコードに復号するよう構成されたデコーダ、および、前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含む第2のデバイスとを含み、前記ショートコードはグローバルに一意であることを特徴とするシステム。請求項64に記載のシステムにおいて、前記サーバは、前記エンコーダを含むことを特徴とするシステム。請求項64に記載のシステムにおいて、前記第1のデバイスは、前記エンコーダを含むことを特徴とするシステム。データを非同期送信するためのシステムにおいて、サーバからショートコードの保存を要求するよう構成されたトランシーバ、送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイス、前記データと前記ショートコードとの間の関連付けを生成するよう構成されたプロセッサ、前記関連付けを格納するよう構成されたメモリ、ダイレクトインターフェース上で第2のデバイスに前記ショートコードを送信するよう構成された送信機、および、前記関連付けを前記サーバに送信するよう構成された送信機を含む第1のデバイスと、ダイレクトインターフェース上で前記第1のデバイスからショートコードを受信するよう構成された受信機、および、前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバを含む第2のデバイスと、第1のデバイスからショートコードを保存するという要求を受信するよう構成された受信機、メモリにショートコードを保存するよう構成されたプロセッサ、前記保存したショートコードを前記第1のデバイスに送信するよう構成された送信機、前記保存したショートコードとデータとの間の関連付けを受信するよう構成された受信機、前記保存したショートコードと前記データとの間の前記関連付けを格納するよう構成されたメモリ、第2のデバイスから要求を受信するよう構成された受信機において、前記要求は前記保存したショートコードを含む、受信機、および、前記第2のデバイスからの前記要求を前記データと関連付けるよう構成されたプロセッサを含むサーバとを含むことを特徴とするシステム。請求項67に記載のシステムにおいて、前記ダイレクトインターフェース上で前記ショートコードを送信または受信する際、前記第1および第2のデバイスの一方または両方は、前記サーバにアクセスできないことを特徴とするシステム。請求項67または68に記載のシステムにおいて、前記ダイレクトインターフェースは、ダイレクト音声インターフェースであることを特徴とするシステム。請求項67乃至69の何れか1項に記載のシステムにおいて、前記第1および第2のデバイスは、並置されることを特徴とするシステム。請求項67乃至70の何れか1項に記載のシステムにおいて、前記第1のデバイスは、請求項1乃至14の何れか1項に記載のデバイスを含み、前記第2のデバイスは、請求項15乃至28の何れか1項に記載のデバイスを含むことを特徴とするシステム。請求項57乃至63の何れか1項に記載の方法を実行するよう構成されることを特徴とするコンピュータプログラム。請求項72に記載のコンピュータプログラムを格納するよう構成されることを特徴とするコンピュータ可読媒体。デバイス上のコンテンツにアクセスするためのシステムにおいて、多数のコンテンツ要素/機能性の少なくとも1つと音声信号を一致させるため、および、前記デバイス上に格納された前記少なくとも1つのコンテンツ要素/機能性へのアクセスを提供するため、無線で直接前記音声信号を受信するよう構成されたプロセッサと、前記多数のコンテンツ要素/機能性を格納するよう構成されたメモリとを含むことを特徴とするシステム。請求項74に記載のシステムにおいて、前記プロセッサは、前記音声信号をショートコードに復号するようさらに構成され、前記ショートコードを使用して前記音声信号を一致させることを特徴とするシステム。請求項74または75に記載のシステムにおいて、前記多数のコンテンツ要素の前記少なくとも1つは、マルチメディアであることを特徴とするシステム。請求項74乃至76の何れか1項に記載のシステムにおいて、前記コンテンツ要素は、ネットワーク接続上で定期的に受信することを特徴とするシステム。請求項74乃至77の何れか1項に記載のシステムにおいて、前記アクセスは、前記デバイスの位置、時間および前記デバイスのユーザの履歴のセットから選択される1つまたは複数の制約にさらに依存することを特徴とするシステム。請求項74乃至78の何れか1項に記載のシステムにおいて、前記アクセスは、多数の音声信号の受信にさらに依存することを特徴とするシステム。バウチャを引き換えるためのシステムにおいて、音声信号を送信するよう構成された第1のデバイスにおいて、前記音声信号はバウチャと関連付けられる、第1のデバイスと、前記音声信号を受信するよう構成された第2のデバイスにおいて、多数の一意なバウチャの1つと前記音声信号を一致させ、前記バウチャを引き換えることができることを確認する、第2のデバイスと、多数の一意なバウチャを格納するためのメモリにおいて、前記バウチャは一般的なバウチャである、メモリとを含むことを特徴とするシステム。請求項80に記載のシステムにおいて、前記音声信号は、前記第1のデバイスのユーザに特有のユーザ識別子を含むことを特徴とするシステム。請求項80または81に記載のシステムにおいて、前記第1のデバイスは、第3のデバイスから前記音声信号を受信することを特徴とするシステム。請求項82に記載のシステムにおいて、前記第1のデバイスは、前記無線インターフェース上で直接第3のデバイスから前記音声信号を受信することを特徴とするシステム。請求項80乃至83の何れか1項に記載のシステムにおいて、前記第2のデバイスは、前記音声信号をショートコードに復号するようさらに構成され、前記ショートコードを使用して前記音声信号を一致させることを特徴とするシステム。請求項80乃至84の何れか1項に記載のシステムにおいて、前記メモリは、前記第2のデバイスに位置することを特徴とするシステム。請求項80乃至85の何れか1項に記載のシステムにおいて、前記第1のデバイスおよび/または第の2のデバイスは、前記バウチャの引き換えを確認する前に、1つまたは複数の制約に対して前記バウチャをチェックするようさらに構成され、前記1つまたは複数の制約は、前記第1のデバイスの位置、時間および引き換えられたバウチャの数のセットから選択されることを特徴とするシステム。送金するためのシステムにおいて、モバイルデバイスから特定の金銭的価値に対する識別子に対する要求を受信し、前記モバイルデバイスに前記要求された識別子を返信し、前記識別子の有効性を確認するという要求を受信し、受信側のデバイスの口座への前記送金を実施するよう構成された信頼できる第三者と、受信側のデバイスから識別子の有効性を確認するという要求を受信し、前記第1の信頼できる第三者と通信して前記識別子の有効性を確認し、有効性を確認した時点で、前記受信側のデバイスの口座への前記送金を実施し、前記受信側のデバイスに有効性確認応答を返信するよう構成された第2の信頼できる第三者と、前記第1の信頼できる第三者からの特定の金銭的価値に対する識別子を要求し、前記識別子を前記モバイルデバイス上に格納し、前記識別子を音声として受信側のデバイスに非同期送信するよう構成されたモバイルデバイスと、音声形式で前記識別子を受信し、前記第2の信頼できる第三者に前記識別子を送信するよう構成された受信側のデバイスとを含むことを特徴とするシステム。請求項87に記載のシステムにおいて、前記特定の金銭的価値は、時間、位置、ベンダー、目的およびベンダーのタイプのセットから選択される1つまたは複数の制約範囲内で利用可能でも、再利用可能でもあることを特徴とするシステム。請求項87または88に記載のシステムにおいて、前記第1の信頼できる関係者および前記第2の信頼できる関係者は、並置されることを特徴とするシステム。モバイルデバイス上にユーザインターフェースを提供して、第2のデバイスへのデータアイテムの送信を管理するための方法において、aモバイルデバイス上のディスプレイ上にユーザに関連する多数のデータアイテムを表示するステップと、b前記データアイテムの少なくとも1つを選択するユーザ入力を前記モバイルデバイス上で受信するステップと、c前記少なくとも1つの選択されたデータアイテムを前記第2のデバイスに送信するための多数の通信オプションを前記モバイルデバイス上に表示するステップにおいて、前記通信オプションの少なくとも1つは、前記第2のデバイス上のマイクロホンによる受信のため、前記モバイルデバイスのスピーカから音声として前記データアイテムを送信するステップを含む、ステップと、d前記通信オプションの少なくとも1つを選択するユーザ入力を受信するステップと、e前記少なくとも1つの選択された通信オプションを使用して、前記少なくとも1つの選択されたデータアイテムを前記他のデバイスに送信するステップとを含むことを特徴とする方法。データを通信するためのシステムにおいて、ショートコードをデータと関連付けるよう構成されたプロセッサ、および、前記関連付けを格納するよう構成されたメモリを含むサーバと、前記ショートコードを一意な形式の信号に符号化するよう構成されたエンコーダと、スピーカ、および、前記スピーカ上での不可聴音声の再生成のために前記信号を送信するよう構成された送信機を含む第1のデバイスと、マイクロホン、前記マイクロホンで検出された音声信号を受信するよう構成された受信機、前記音声信号をショートコードに復号するよう構成されたデコーダ、および、前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含む第2のデバイスとを含み、前記ショートコードはグローバルに一意であることを特徴とするシステム。請求項91に記載のシステムにおいて、前記サーバは、前記エンコーダを含むことを特徴とするシステム。請求項91に記載のシステムにおいて、前記第1のデバイスは、前記エンコーダを含むことを特徴とするシステム。データを送信するためのシステムにおいて、データを第1の音声信号に符号化するよう構成されたエンコーダ、および、前記第1の音声信号を可聴音声で再生成するよう構成されたスピーカを含む第1のデバイスと、第2の音声信号を可聴音声で再生成するよう構成されたスピーカ、第3の音声信号を受信するよう構成されたマイクロホン、前記第2の音声信号を取り除くために前記第3の音声信号を処理するよう構成された信号プロセッサ、および、前記処理された第3の音声信号をデータに復号するよう構成されたデコーダを含む第2のデバイスとを含むことを特徴とするシステム。デバイス上のコンテンツにアクセスするためのコンピュータ実装方法において、a無線で直接音声信号を受信するステップと、b多数のコンテンツ要素/機能性の少なくとも1つと前記音声信号を一致させるステップと、c前記デバイス上に格納された前記少なくとも1つのコンテンツ要素/機能性へのアクセスを提供するステップとを含むことを特徴とする方法。バウチャを引き換えるための方法において、a音声信号を送信する第1のデバイスにおいて、前記音声信号はバウチャと関連付けられる、第1のデバイスと、b前記音声信号を受信する第2のデバイスと、c多数の一意なバウチャの1つと前記音声信号を一致させ、前記バウチャを引き換えることができることを確認する、前記第2のデバイスとを含み、前記バウチャは一般的なバウチャであることを特徴とする方法。送金するための方法において、a第1の信頼できる第三者からの特定の金銭的価値に対する識別子を要求するモバイルデバイスと、b前記モバイルデバイスから特定の金銭的価値に対する識別子に対する前記要求を受信する前記第1の信頼できる第三者と、c前記モバイルデバイスに前記識別子を返信する前記第1の信頼できる第三者と、d前記識別子を前記モバイルデバイスで格納する前記モバイルデバイスと、e前記識別子を音声として受信側のデバイスに非同期送信する前記モバイルデバイスと、f音声形式で前記識別子を受信する前記受信側のデバイスと、g第2の信頼できる第三者に前記識別子を送信する前記受信側のデバイスと、h前記受信側のデバイスから識別子の有効性を確認するという要求を受信する前記第2の信頼できる第三者と、i前記第1の信頼できる第三者と通信して前記識別子の有効性を確認する前記第2の信頼できる第三者と、j前記第2の信頼できる第三者から前記識別子の有効性を確認するという要求を受信する前記信頼できる第三者と、k前記受信側のデバイスの口座への前記送金を実施する前記第1の信頼できる第三者と、l前記識別子の有効性を確認すると、前記受信側のデバイスの口座への前記送金を実施する前記第2の信頼できる第三者と、m前記送金を実施した時点で、前記受信側のデバイスに有効性確認応答を返信する前記第2の信頼できる第三者とを含むことを特徴とする方法。データを通信するための方法において、aグローバルに一意なショートコードをデータと関連付けるサーバと、b前記関連付けを格納する前記サーバと、c前記ショートコードを一意な形式の信号に符号化するエンコーダと、dスピーカ上での不可聴音声の再生成のために前記信号を送信する第1のデバイスと、eマイクロホンで検出された音声信号を受信する第2のデバイスと、f前記音声信号をショートコードに復号するデコーダと、g前記ショートコードを使用して、前記サーバで前記ショートコードと関連付けられたデータにアクセスするトランシーバとを含むことを特徴とする方法。データを送信するための方法において、aデータを第1の音声信号に符号化する第1のデバイスと、b前記第1の音声信号を可聴音声で再生成する前記第1のデバイスと、c第2の音声信号を可聴音声で再生成する第2のデバイスと、d第3の音声信号を受信する前記第2のデバイスと、e前記第2の音声信号を取り除くために前記第3の音声信号を処理する前記第2のデバイスと、f前記処理された第3の音声信号をデータに復号する前記第2のデバイスとを含むことを特徴とする方法。請求項95乃至99の何れか1項に記載の方法を実行するよう構成されることを特徴とするコンピュータプログラム。請求項100に記載のコンピュータプログラムを格納するよう構成されることを特徴とするコンピュータ可読媒体。本発明は、データを通信するためのデバイス、サーバ、方法およびシステムを提供する。発明者は、スピーカとマイクロホンを使用して、並置されたデバイス音声送信を探知できるほど近くに位置するデバイス間で、音声形式でデータを通信できることを決定した。発明者は、データが通信されている際に個人がそれを決定できるように、音声が人間に聞こえるものであることが望ましいことをさらに決定した。例えば、一個人がデバイスから別の個人のデバイスにデータを送信している場合に、両者が、データが送信されていることを確信していることが望ましい場合がある。発明者は、可聴音声送信が音声に一意なものであれば望ましいことをさらに決定した。すなわち、個人は、あるセットのデータの可聴信号を別のセットのデータの可聴信号と合理的に区別することができる。また、発明者は、上記の仕様によるデータ通信が長時間の送信をもたらすことも決定した。したがって、発明者は、データと関連付けられた参照コードまたはショートコードの使用、および、データに代わる参照コードの後続の送信を考案した。それに応じて、本発明の一態様は、ショートコードとデータとの関連付け、可聴的に一意な形式の信号へのショートコードの符号化、および、信号の可聴音声の再生成を含み得る。信号は、検出してショートコードに復号することができ、データは、ショートコードとの関連付けを使用してアクセスすることができる。ここで、図1~2を参照して、上記の態様による本発明の実施形態について説明する。受信機101と、エンコーダ102と、送信機103とを備え得る第1のデバイス100が示されている。デバイス100は、モバイルテレコミュニケーションデバイス内のコントローラであり得る。受信機101は、サーバ104からデータと関連付けられたショートコードを受信するよう構成することができる。受信機101は、モバイルテレコミュニケーションネットワーク上でサーバ104からショートコードを受信することができる。あるいは、デバイス100およびサーバ104は、同じデバイス内のコントローラであり得る。データは、URL、Eメールアドレスおよび/もしくは電話番号および/もしくは連絡者名などの連絡先、文書、口座情報、バウチャ、金融トークンなどのトークン、または、他の任意のタイプのデータであり得る。エンコーダ102は、ショートコードを可聴的に一意な形式の信号に符号化するよう構成することができる。可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および/または音楽を含み得る。音楽は、西洋の楽音の平均律を利用することも、微分音を使用することもできる。可聴的に一意な形式は、信号の可聴音声の再生成の美的または独特の性質を改良するためだけの音声を含み得、ショートコードとは関連しない。好ましい実施形態では、エンコーダ102は、ショートコードを信号に変換し、その結果、ショートコードデータ自体の少なくとも一部は、鳥の鳴き声および/または音楽形式に構造化される。それに加えて、信号は、信号の音声に対する一意性を改良するためおよび/または信号の可聴音声の再生成における心地良い音を改良するため、ショートコードから導出されない他の要素を含み得る。ショートコードは、グローバルに一意なものであり得る。すなわち、各ショートコードは、データとの関連付けを1つのみ有することができる。したがって、サーバ104の位置をショートコード内に組み込む必要はない。したがって、ショートコードの長さを増加する必要はない。ショートコードは、アプリケーションヘッダを含み得る。ヘッダは、サーバ104でまたはデバイス100で追加することができる。ヘッダは、好ましくは、サーバ104を使用することなく、ショートコード内で検出可能である。好ましくは、ショートコードは、固定長のものである。あるいは、符号化プロセスは、信号内のショートコードの長さを含む。送信機103は、可聴音声の再生成のために信号を送信するよう構成することができる。好ましくは、送信機103は、可聴音声の再生成のために信号をスピーカに送信することができるか、またはその代替として、送信機103は、後の可聴音声の再生成のための通信プロトコル上で信号を伝達することができる。代替の実施形態では、第1のデバイス100は、ショートコードを格納するよう構成されたメモリも備え得る。この実施形態では、デバイス100は、後にこのショートコードを回収して、可聴音声の再生成のために符号化することができる。一実施形態では、第1のデバイス100は、どのデータをショートコードと関連付けるかをユーザが決定することができるよう構成されたユーザ入力デバイスも備え得る。そして、第1のデバイス100は、この関連付けをサーバ104に通信するためのトランシーバも含み得る。また、第2のデバイス105も示されている。第2のデバイス105は、受信機106と、デコーダ107と、トランシーバ108とを備え得る。受信機106は、マイクロホンから音声信号を受信するよう構成される。一実施形態では、音声信号は、第1のデバイス100によって送信されるものである。あるいは、音声信号は、事前にメモリ上に音声信号を格納するテレビ、コンピュータまたはリレーなどの別のデバイス内のスピーカから送信することができる。デコーダ107は、音声信号をショートコードに復号するよう構成される。トランシーバ108は、サーバ104と通信して、ショートコードを使用することによってショートコードと関連付けられたデータにアクセスするよう構成される。代替の実施形態では、第2のデバイス105およびサーバ104は、さらなるデバイス内に存在し得、音声信号は、第3のデバイスを通じて伝達することができる。一実施形態では、データにアクセスするステップは、第2のデバイス105にデータを回収するステップを伴う。一実施形態では、第2のデバイス105は、受信したショートコードまたは音声スペクトルなどの音声信号の表現を表示するよう構成された視覚ディスプレイをさらに備え得る。また、サーバ104も示されている。サーバ104は、プロセッサ109と、メモリ110と、エンコーダ111と、送信機112とを備え得る。プロセッサ109は、ショートコードをデータと関連付けるよう構成することができる。メモリ110は、関連付けを格納するよう構成することができる。エンコーダ111は、ショートコードを可聴的に一意な形式の信号に符号化するよう構成することができる。送信機112は、可聴音声の再生成のために第1のデバイス100に信号を送信するよう構成することができる。一実施形態では、サーバがエンコーダ111を備える場合は、第1のデバイス100は、エンコーダ102を必要としない。一実施形態では、送信機112は、モバイルネットワークなどのテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。信号は、例えば、着信音として、SMSチャネルまたはMMSチャネル上で送信することができる。信号は、USSD非構造付加サービスデータとして送信することができる。サーバ104は、要求側のデバイスから音声信号を受信するための受信機と、音声信号をショートコードに復号するよう構成されたデコーダと、ショートコードを使用してデータにアクセスするよう構成されたプロセッサとをさらに備え得る。データにアクセスするステップは、要求側のデバイスにデータを送信するステップを含み得る。ここで、本発明の実施形態による方法について説明する。一方法200では、ステップ201において、データと関連付けられたショートコードをサーバから受信する。ステップ202では、ショートコードを可聴的に一意な形式の信号に符号化する。ステップ203では、可聴音声の再生成のために信号を送信する。ショートコードは、データとの複数の関連付けを有さないという点において、グローバルに一意なものである。この方法は、モバイルデバイスなどの単一のデバイス上で実行することができる。さらなる方法204では、ステップ205において、マイクロホンを介して音声信号を受信する。ステップ206では、音声信号をショートコードに復号する。ステップ207では、ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスする。この方法は、モバイルデバイスなどの単一のデバイス上で実行することができる。さらに、さらなる方法208では、ステップ209において、ショートコードをデータと関連付ける。ステップ210では、ショートコードを可聴的に一意な形式の信号に符号化する。ステップ211では、可聴音声の再生成のためにデバイスに信号を送信する。この方法は、モバイルテレコミュニケーションネットワークとインターフェースを取るサーバなどのサーバ上で実行することができる。当業者であれば、方法のすべてまたは少なくとも一部を1つまたは複数のコンピュータプログラム内で実施できることが理解されよう。例えば、モバイルテレコミュニケーションデバイスのための方法200、204は、iPhoneアプリケーション内、Androidアプリケーション内、Symbian内または他の任意のプログラミング言語内で、コンピュータプログラムコードとして作成することができる。サーバのための方法208は、Python/Django、PHP、Python、RubyonRAILSまたは他の任意のシステムなどの任意のコンピュータプログラミング言語、システムまたはフレームワークで作成することができる。ここで、図3および4を参照して、本発明の実施形態について説明する。本発明のこの実施形態は、Chirpと呼ばれる。Chirpは、少量のデータを符号化する音声を使用するピアツーピアおよびオンライン共有をサポートするプロトコルおよびアプリケーションセットを含む。この実施形態では、ピアツーピアは、物理的に並置するデバイス、通常、携帯電話/モバイルデバイスを意味し、オンラインは、ソーシャルネットワークまたは標準のウェブサービスを通じたものを意味し、少量のデータは、およそ32~1024ビットを意味し、音声は、音楽などの耳に心地良い可聴音を意味する。代替の実施形態では、音声は不可聴である。現モバイルデバイス内のスピーカは、ほぼすべての人間の聞こえる範囲を上回る最大20kHzまでの音声を送信することができる。いくつかの現モバイルデバイス内のマイクロホンは、最大22kHzまでの音声を受信することができる。18kHzを上回る音声の範囲は、ほとんどの成人には不可聴である。したがって、音声は、大部分のモバイルデバイスまたは専門スピーカによって大部分は不可聴周波数で送信することができ、大部分のモバイルデバイスによって不可聴周波数で受信することができる。可聴音声は、ユーザがデータ送信を可聴音声で確認でき、可聴音声は、商品知名度や目新しさの価値をユーザに確立するという点において有利であり得、あるデータ送信は、送信されているものをユーザが部分的に検証できるように認識可能な可聴音声を有し得る。不可聴音声は、音声が心地良いものでなくともよく、したがって、より大きなデータ圧縮率を使用できる可能性があるという点において有利であり得る。典型的な使用例では、2つのデバイスは互いに近くに位置し、ある人物が短いデータを別の人物にChirpする。送信側のデバイスは音声を生成し、受信側のデバイスは音声を受信して復号する。この音声は、2人のユーザには可聴であり、その結果、ユーザはデータ交換が行われたことを知ることができる。転送されるデータは短い文字列であり、その文字列は、アプリケーション特有のコードもしくはウェブサービスによって生成されたショートコードの何れかであるか、または、生成された何らかの別の形式のコードである。この特定の音声のポイントツーポイント転送は、多くの異なる大規模な相互作用に組み込むことができる。具体的には、データ転送は音声で実施されるため、音声送信が可能ないかなるデバイスも、Chirpを再生することができる。さらに、音声記録が可能ないかなるデバイスも、後のプレイバックのためにChirpを記録することができる。したがって、いかなるウェブページもChirpを再生することができ、マイクロホンへのアクセスを有するFlashまたはJavaアプレットなどのウェブページ上のいかなるアプレットもChirpを受信することができる。Chirpは、例えば、ラジオまたはテレビのネットワークなどの任意の通信ネットワークまたはシステム上で伝達することができ、次いで、同通信ネットワークまたはシステムは、Chirpを可聴音声で再生成することができる。基本プロトコルプロトコルスタックどのようにデータが転送されるかについて説明するプロトコルには3つの部分がある。意味コード化-アプリケーション特有の意味へのショートコードの符号化300Esおよび復号301Ds。データコード化-音楽記述形式へのショートコードの符号化302Edおよび復号303Dd。転送コード化-音波306への音楽記述の符号化304Etおよび復号305Dt。図3ではプロトコルが示されている。プロセス307のアプリケーションは、chirpを要求し、アプリケーションデータを符号化プロセスEsに渡す。したがって、Esは、以下の関数と見なすことができる。Es:A,B→CAは文字列としてのアプリケーション識別子であり、Bは文字列としてのアプリケーションデータであり、Cは出力文字列である。関数Esは、プロセス307上でローカルに実施することができるか、または、好ましくは、ウェブサービスを利用することができる。文字列Aは、通常、小さなアプリケーションサンプルから引き出されることになる例えば、それはURLであり得、したがって、シンボルAはURLであり得る。文字列Bは、任意の長さのものである。ショートコードCは、32~1024ビットの固定長のものである。固定長は、実装形態に応じて指定される。次いで、このショートコードは、符号化プロセスEdによって音楽記述言語に符号化され、Edは、以下の関数と見なすことができる。Ed:C→DDは音楽記述言語MDLのコードのシーケンスである。MDLの一例はMIDIであり、コードはMIDIコードのシーケンスであり得る。一実施形態では、値は、単にピッチ値であるか、またはその代替手段では、ノート音符のボリュームまたは動的振幅の変化、ノートの長さ、音色特性を含む他の可聴パラメータ、および、可能な場合は、そのようなパラメータの連続変調であり得る。したがって、ショートコードCは、ASCII文字の文字列として表すことができ、音楽コードDは、MIDI制御コードのシーケンスであり得る。MIDIを使用する1つの利点は、MIDI再生が大部分のプラットホーム上で利用可能であるかまたは利用可能にすることができる能力であることである。あるいは、デバイス特有の着信音形式を使用することができる。音声プロセスにおける干渉に起因して復号プロセスは不明確である場合があるため以下で論じる、Edは、リードソロモン符号などの冗長コード化スキームを使用することができる。符号化の最終ステップは、Dを音波に符号化することである。事実上、これはMDLプレーヤである。Et:D→EEは、WAVなどの任意の音声形式であり得る。MP3もしくはMP4またはAIFFなどの代替の音声形式も使用できることが理解されよう。MIDIを使用する場合、音声セットを選択することができるすなわち、音声サンプルが実際に再生または合成される。音声セットおよびピッチ範囲を選択して、再生成の容易性例えば、低周波数は、通常小型の低出力スピーカを特徴とするモバイルデバイス上ではあまりうまく再生成されないおよび復号目的のための検出の容易性などの音声送信および受信のある要件を満たす信号Eを生成することができる。復号プロセス308の第1のステップは、MDL例えば、MIDIコードへの音の復号である。Dt:E’→D’E’は、音声が追加のノイズを有し得、復号の際にバックグラウンドノイズを含み得ることを示し、したがって、D’は、MDL例えば、MIDIコードのシーケンスであり、Dとは同じではない可能性がある。このDtプロセスは、ピッチ検出システムも含み得る。次のステップは、このMIDIシーケンスをショートコードに復号することであり、関数Ddによって実現される。符号化ステップにおいて冗長コードを使用したため、復号プロセスは、高い確率で、元のショートコードCを返す。Dd:D’→C最終プロセスは、ショートコードを復号することである。Ds:C→A,Bショートコードは、アプリケーションAおよびアプリケーションデータBを特定する。以前のEsと同様に、この復号は、アプリケーションでローカルに実施することができるか、または、ウェブサービスを活用して実行することができる。TCP/IPプロトコルスタックの例えを用いて説明することができる。具体的には、プロトコルの異なる層は、異なる方法で実現することができる。一般層TCP/IPスタックのIPに相当は、ショートコードである。TCP/IPと同様に、送信媒体への特定の符号化は、他のタイプのコード化で実現することができる。例えば、QRコード。送信における信頼性は、音声復号の信頼性、すなわち、関数Dtにおけるピッチ追跡と、EsおよびDsにおける符号化の冗長との音声の2つの態様によって決定することができる。Dsと関連して、周波数変調またはPCMコード化などの異なる音声特性を使用することができる。選択される異なるタイプの音声特性は、例えば、非常に低価のハードウェア上または組み込まれたウェブアプレットでこのステップを実行する場合、符号化ステップEd、Etの容易性とのバランスを保つことができる。ステップEsおよびDsは、フレキシブルであり得る。任意のアプリケーションを相互作用させるには、メッセージの意味論に同意する必要があるという意味で、半開にできるのはこの層である。通常、例えば、IPには、特に、使用される高レベルのプロトコルについて説明する短いヘッダがある。Chirpプロトコルはポイントツーポイントプロトコルであるため複数の聴取者がいる可能性があるが、以下を参照、シングルヘッダバイトとしてアプリケーションを特定することができる。このバイトのある特定の値は保存され、特定のアプリケーションを示す例えば、URLとして0×01またはコード化されたISBNとして0×02。次いで、これにより、復号プロセスは、どのアプリケーションが残りの7バイト64ビットコードと仮定または127バイト1024ビットコードと仮定を処理すべきかを決定することができる。一実施形態では、ショートコードの長さは、ショートコード自体に符号化される。しかし、この考えられる1つの不利な点は、復号音声Dtが未知のショートコードの長さすなわち、未知数の検出ノートを処理する必要があることである。ショートコードの長さを符号化するかどうかの選択は、目的とする用途正真正銘のピアツーピア方式で多量のデータを共有するため、または、多量のデータおよびパス識別子に対してウェブサービスを使用するかどうかに依存し得る。音楽符号化音楽符号化の一実施形態について説明する。ショートコードが64ビットであると仮定すると、これは4ビットのチャンクに分けることができ、16ノートのアルファベットが生じることになる。16の異なる周波数をアルゴリズムで選択することができるか、または、2オクターブ弱のキーを使用することができ、その結果、曲のノートはキーに含まれる。16の異なるノートは、長さが16ノートの信号またはChirpを生じさせることになる。あるいは、共通のノートパターン、アルペジオおよび進行を使用したより複雑なコード化スキームを利用することができる。これらはすべて、簡単なランダムシーケンスより多くのノートを使用することができる。復号目的のため、ノートごとにピッチが変化することを保証することが好ましい場合がある。これは、ノートの長さおよび位相の復号の不明瞭性を回避する際に役立てることができる。したがって、アルファベットをシンボル1つ分拡張することができる。URL共有サービスここで、図4を参照して、本発明の実施形態を利用するシナリオについて説明する。このシナリオでは、2人のユーザ間でURLを共有することになっている。Aliceは、プロセス400ChirpAppを実行しているスマートフォンを持っている。Bobは、プロセス401ChirpAppを実行しているスマートフォンを持っている。Aliceは、BobとURLを共有することを希望している。ChirpAppは、図14a、14bおよび14cで説明されるユーザインターフェースを利用することができる。代替の実施形態では、プロセス400および401は、異なるアプリケーションおよび/または音声によるデータ送信専用ではないアプリケーションに統合することができる例えば、プロセス400、401を写真アプリケーションに統合して、写真の共有を容易にすることができる。プロセスの概要図4を参照すると、ステップは以下の通りである。402-Aliceは、アプリケーションChirpAppにテキストをペーストし、アプリケーションChirpAppは、Esプロセスに渡される例えば、URLは、www.bbc.co.ukであり得る。403-Esプロセスは、WebShortenWsと呼ばれるウェブサービスに要求を出す。404-Wsは、URLに対するテキスト文字列コードハッシュコードをEsに返し例えば、6xf42d3edfG、ハッシュコードとURLとの関係をデータベースに格納することも行うストア。405-Esは、このコードを取り、ウェブurlに対するアプリケーションコード例えば、0×01をその先頭に追加し、それをEdに渡す。406-Edは、これを音楽コードに変換する。407-音楽が再生される。408-プロセス401は、音声を受信する。409-それは、音楽コードに復号され、Ddに渡される。410-Ddは、それをショートコードに復号し、それをDsに渡す。411-Dsは、0×01を取り除き、次いで、WebLengthenWlと呼ばれるウェブサービスにハッシュコードを送信する。412-Wlは、ストアでハッシュコードを調べ、対応する長いURL例えば、www.bbc.co.ukをDsに返す。413-Dsは、ウェブブラウザウィンドウにURLを渡し、それを開く。この実施形態では、EsおよびDsはそれぞれ、リモート手順を利用して表を調べる。ウェブサービスは、複数のエントリポイントこの場合、WsおよびWlを有するウェブサービスである。これらのサービスは両方とも、ハッシュコードをURLにマッピングする表を含むストアへのアクセスが必要である。各ハッシュコードは、一意なURLにマッピングされる。これは、生成されたショートコードがピアツーピアから送信されるためである。また、それは、Es自体はURLから直接ショートコードを生成できないことも意味する。ハッシュコードは、既定の長さの表のインデックス値であり得る。このシステムに必要なコードの長さは、かなり短いものであり得る。ちなみに、bit.lyのURLは、ベース62のアルファベットa~z、A~Z、0~9からの6文字である。これは、大体30ビットの情報を生じさせる。より大きなスペースを復号することを保証するため、少なくとも64ビットのコードが使用される。一実施形態では、符号化は、Aliceのスマートフォンのウェブブラウザに内蔵されている。一実施形態では、ChirpAppは、マルチメディア表示を含む例えば、それはTwitterクライアントである。代替の実施形態では、ステップ402において、Aliceは、複数のURLを格納することができるが、ウェブサービスから1つのコードのみを受信する場合がある。代替の実施形態では、ユーザデバイス上のアプリケーションは、ユーザの最近の10のお気に入り、最近閲覧したFourSquareの場所または最近メンションしたTwitterの連絡先をChirpとして符号化することを許可することができる。この情報は、ChirpAppによってそのアプリケーションから取り入れることができる。一実施形態では、ステップ406において、Edは、以下の形式にショートコードを符号化することができる。フロントドアの音符号化ショートコードChirpの終了フロントドアの音は、受信機が送信の開始を特定することステップ408においてを可能にする事前に定義された音であり、符号化ショートコードは、音声に符号化されたアプリケーションコードおよびハッシュコードであり、Chirpの終了は、送信の終了を定義する事前に定義された音である。開始および終了音を定義する利点は、受信機を補助することである。また、形式は、次のChirpも送信されようとしていることを示す追加のさらなるChirp音も含み得る。そのような場合は、フロントドアの音は必ずしも必要ではない。さらなるChirp音は、事前に定義された音であり得るか、または、Chirpがさらにいくつ予定されているかを示すことができる。さらなるChirp音は、Chirpの終了音前に現れる場合がある。ユーザ経験は、ChirpAppを実行するステップと、データにペーストするステップとを含み得る。代替ステップは、Chirpボタンをアプリケーションすなわち、ウェブブラウザに組み込むステップである。このボタンを押した時点で、ウェブサービスへのクエリを行うことによってショートコードが生成され、次いで、およそ1~2秒内に音声が現れる。一実施形態では、Bobは、音声が始まる前に、ChirpAppのインスタンスを実行する必要がある。あるいは、Bobは、後の復号のために音声を記録することができる。音声が到達し始めた時点で、ショートコードの表現が現れ、受信プロセスが機能していることを示すことができる。これは、音声レベルが機能していることを示す音声スペクトル視覚化を伴う場合がある。完全な音声が受信された時点で、ユーザにショートコードを明かすことができる。bit.lyなどのURL短縮サービスは、通常、ベース6252の大文字および小文字と、数字の6文字を使用する。これに対する一代替手段は、ベース36大文字なしの6文字である。一部のサービスは、ショートコードが長い間利用可能であることを保証しない。したがって、URL短縮サービスは、およそ36ビットlog262×6=約35.72またはlog236×6=約31.02をサポートすべきである。ショートコードがベース62の6文字列の場合、これは、36ビットまたは5バイト実際には4.5バイトで表すことができる。したがって、関数Esの入力は5バイトである。何らかの冗長を提供するため、マッピングは、リードソロモン9,5符号などのエラー訂正コードを使用することができ、これは、9バイトが出力であり、4エラー修正バイトがあることを意味する。したがって、9バイト72ビットがMIDIコードに符号化される。この実施形態は、振幅も他の変調も使用せず、簡単なピッチのみを使用して説明する。MIDIノートの使用可能範囲の中央は、C4MIDIノート60からG6MIDIノート91まで、すなわち、32の使用可能ノートである。これは、15のノートが使用されることを意味する。一実施形態では、ノートの1つは2ビットのみを符号化し、他の3ビットは保存される。これが第1のMIDIノートとなる。これは、第1のトーンが4つの値60、68、76、84の1つのみから選択されることを意味する。後続のノートは順次コード化することができる。この特定の実施形態では、第1のノートは、160ミリ秒間再生される。第2のノートから第15のノートまでは、80ミリ秒間再生される。したがって、曲の全長は1.28秒となる。曲を復号するため、ピッチ検出を使用することができる。音声での符号化は、周波数キーイングシステムである。FFT実装形態と調整されたフィルタバンク実装形態の両方とも使用することができる。一実装形態は、32の目標周波数でGoertzelアルゴリズムを利用する。次いで、160ミリ秒長の目標トーンを探す。第1のコードの3ビットが保存されているため、その範囲内のいかなるトーンも検出することができる。この実施形態では、第1のMIDIコードの最も高い2ビットのみを取るすなわち、コード-60/8。さらなる復号は、符号化とは反対に進行する。15のMIDIコードが9バイトのデータに変換され、リードソロモン符号を通じて5バイトのシーケンスに復号される。これは、長さ6のベース62の文字列に変換することができる。長さ7の文字列が作成された場合は、これはエラーとなり、エラー訂正コードが未検出であったことを意味する。リードソロモン符号は、抹消を訂正することができる。したがって、フィルタバンクが何れの時間ステップでもピークを検出しないか、または、ノイズのためピークが不明瞭である場合は、関連バイトを抹消としてマーク付けすることができ、それらを訂正することができる。発明者は、ユーザのデバイスがサーバにアクセスできない場合に、デバイスを用いてユーザとのデータの送信のやり取りを可能にすることが望ましいことも決定した。それに応じて、本発明のさらなる一態様は、サーバからショートコードを受信するステップと、第1のデバイス上にショートコードを格納するステップと、ショートコードをデータと関連付けるステップと、ショートコードを第2のデバイスに送信するステップと、次いで、データとショートコードとの関連付けをサーバに送信するステップとを含み得る。ショートコードとのデータの非同期関連付けは、何れのデバイスもオンライン状態であることを必要とせずに、または、ショートコードとデータとの関連付けに関する情報を有するサーバにアクセスして、2つのデバイス間でのデータへの単なる参照の送信を可能にすることができる。したがって、それは、参照またはショートコードの使用によって第2のデバイスによるデータへの非同期アクセスを可能にすることができる。ここで、図5~6を参照して、上記の態様による本発明の実施形態について説明する。デバイス500が示されている。デバイス500は、受信機501と、メモリ502と、プロセッサ503と、第1の送信機504と、第2の送信機505とを備え得る。受信機501は、サーバ506からショートコードを受信するよう構成することができる。好ましくは、サーバ506は、モバイルテレコミュニケーションネットワークまたはインターネットなどの通信ネットワークを介してアクセス可能なものである。代替の実施形態では、サーバ506およびデバイス500は、モバイル通信デバイスなどのさらなるデバイス内に存在する。メモリ502は、受信したショートコードを格納するよう構成することができる。メモリ502は、フラッシュメモリでも、プロセッサ503内に統合されたメモリでもあり得る。プロセッサ503は、受信したショートコードをデータと関連付けるよう構成することができる。プロセッサ503は、ユーザ入力デバイスを介してユーザからデータを関連付けるための入力を受信することができる。入力は、データ自体であり得る。第1の送信機504は、第2のデバイスにショートコードを送信するよう構成することができる。第1の送信機504は、ダイレクトインターフェース可聴チャネル、Bluetooth、視覚的表示および検出、IR、NFC、ワイヤレスまたはRFなどの両方のデバイス間の直接のインターフェースを使用してショートコードを送信することができる。第2の送信機505は、ショートコードとデータとの関連付けをサーバ506に送信するよう構成することができる。好ましくは、第2の送信機505は、受信機501と同じ通信システムを使用する。また、サーバ506も示されている。サーバ506は、プロセッサ507と、送信機508と、第1の受信機509と、メモリ510と、第2の受信機511とを備え得る。プロセッサ507は、メモリ510にショートコードを保存するよう構成することができる。サーバ506は、示されるデバイス500などのデバイス上のユーザからの要求に応じて、ショートコードを保存することができる。ショートコードは、サーバ506が割り当てることができるか、またはその代替の実施形態では、要求内でユーザが指定することができる。送信機508は、示されるデバイス500などのデバイスに、保存されたショートコードを送信するよう構成することができる。第1の受信機509は、保存されたショートコードとデータとの関連付けを受信するよう構成することができる。関連付けは、デバイスから受信することができる。メモリ510は、保存したショートコードとデータとの関連付けを格納するよう構成することができる。メモリ510は、サーバが継続的にオンライン状態を保つ場合は、RAMなどの揮発性メモリでも、不揮発性メモリでも、冗長のため両方でもあり得る。第2の受信機511は、第2のデバイスから要求を受信するよう構成することができる。要求は、ショートコードを含み得る。プロセッサ507は、要求をデータと関連付けるよう構成することができる。プロセッサ507は、ショートコードを使用して、データとの関連付けを回収することができる。プロセッサ507は、要求に従ってデータをさらに処理することができる。ここで、本発明の実施形態によるさらなる方法について説明する。一方法600では、ステップ601において、サーバからショートコードを受信する。ステップ602では、デバイス上に受信したショートコードを格納する。ステップ603では、受信したショートコードをデータと関連付ける。ステップ604では、受信したショートコードを第2のデバイスに送信する。ステップ605では、関連付けをサーバに送信する。方法は、モバイルテレコミュニケーションデバイス上で実行することができる。別の方法606では、ステップ607において、ショートコードを保存する。ステップ608では、保存したショートコードを第1のデバイスに送信する。ステップ609では、保存したショートコードとデータとの関連付けを受信する。ステップ610では、保存したショートコードとデータとの関連付けを格納する。ステップ611では、第2のデバイスから要求を受信する。要求は、保存したショートコードを含み得る。ステップ612では、要求をデータと関連付ける。方法は、サーバ上で実行することができる。当業者であれば、方法のすべてまたは少なくとも一部を1つまたは複数のコンピュータプログラム内で実施できることが理解されよう。例えば、モバイルテレコミュニケーションデバイスのための方法600は、iPhoneアプリケーション内、Androidアプリケーション内、Symbian内または他の任意のプログラミング言語内で、コンピュータプログラムコードとして作成することができる。サーバのための方法606は、Python/Django、PHP、Python、RubyonRAILSまたは他の任意のシステムなどの任意のコンピュータプログラミング言語、システムまたはフレームワークで作成することができる。非同期URL共有サービスここで、特に図7を参照して、本発明の実施形態について説明する。この特定のシナリオでは、Aliceは、BobとURLを共有することを希望するが、彼らの一者または両者がオンライン状態ではない。プロセスの概要図7を参照すると、以下のタイムラインでプロセスが示され、ウェブサーバプロセス700、Aliceのアプリケーションプロセス701およびBobのアプリケーションプロセス702の3つのプロセスが示されている。時間は、左から右へ進行する。703-Aliceのデバイス上のプロセス701ChirpAppがオンライン状態の際、関数CachePre-cacheCpは、ハッシュコードのセットを保存するように、WebReserveと呼ばれるウェブサービス700に要求を出す。704-これらのコードは、ストアに格納され、未だURLにはマッピングされていない。705-Wrは、コードをCpに返し、Cpは、今後の使用のためにローカルにそれを格納する。706-ここで、AliceがURLのChirpを試みる際、Aliceのデバイスはオフライン状態である。しかし、プレキャッシュされたハッシュコードの1つを使用することができる。したがって、符号化プロセスEsは、これらのプレキャッシュされたコードの1つを使用して、ショートコード、音楽コードを生成し、音声を生成することができる。707-Chirpが送信される。708-プロセス702ChirpAppを実行しているBobのデバイスはChirpを受信するが、Bobのデバイスもオフライン状態である。Bobのデバイスは、段階Dt、Ddを超えてChirpを復号することはできない。たとえオンライン状態であったとしても、この時点でウェブサービスWlは保存されたコードの隣にブランクのURLを見つけるため、ショートコードを復号することはできないだろう。709-プロセス701がオンライン状態となると、関数CacheUpdaterCuは、ハッシュコードとURLとの新しい関係を中継する。710-ウェブサービスWebUpdaterWuは、この新しい関係をストアに格納する。ここで、いかなるプロセスも、ハッシュコードからURLを調べることができる。711-プロセス702がオンライン状態となると、それは、すべての非復号のショートコードのフェッチを試みる。それは、前述同様に、ハッシュコードをWlに渡す。712-Wlは、ここでは非ブランクのショートコードからURLへのマッピングを調べる。713-WlはURLをDsに返す。714-プロセス702はウェブブラウザを始動する。好ましくは、プロセスは、ユーザアカウントを使用して、他の誰かによってWuが更新されることを防ぐ。それは、有料サービスであり得る。ここでは、Chirpを完全に復号できない期間すなわち、AliceがハッシュコードとURLとの関係をウェブサービスにアップロードする前がある。しかし、ステップ708では、AliceとBobは、ショートコードが送信されていることを確認することができる。一実施形態では、彼らのデバイスのそれぞれのデバイス上のユーザインターフェースは、比較のためにショートコードを表示することができ、および/または、ユーザインターフェースは、BobがChirpを再度再生することを可能にし、両ユーザともそれを聞き取って2つの音が同じであることを確認することができる。音が同じであれば、原理上は、首尾よくデータを調べることができる。ChirpAppは、Chirpを完全に復号できる際にそれをBobに知らせることができる。Bobがオンライン状態となって時点で、ステップ709の実行に対してAliceが未だオンライン状態となっていないことはあり得ない。この時点で、Chirpは、元の送信者からの更新保留として特定され得る。したがって、Chirpは、後日復号するためにウイルスのように拡散させることができる例えば、特定の時間にリリースされたフィルムトレーラクリップにリンクする。この特定の実施形態では、両プロセスの機能性は、両デバイスに展開された単一のアプリケーションChirpApp内に含まれる。このアプリケーションは、図3および4と関連して説明されたものと同じアプリケーションであり得る。プロセスを別々のアプリケーション内に含めることができることも理解されよう。ここで、本発明のさらなる実施形態について説明する。機能不可Dumbリレー機能不可リレーに対して考えられるいくつかの実装形態、すなわち、復号できないが、単に生の音声または音楽記述の記録および送信のみを行うプロセスが存在する。符号化および復号ステップは、それら自体がウェブサービスとして提供され得る。ウェブサービスは、ダウンロード可能なChirpをMP3として提供することも、ウェブブラウザでのChirpの再生をサポートすることもできる。これは、スピーカが取り付けられていれば、ウェブブラウザは即座にChirpを生成できることを意味する。それに加えて、これらのサービスは、MMSなどの他のゲートウェイを通じて触れることができる。先述の通り、Chirp自体は、音声であるため、これらの機能をサポートする任意のタイプのデバイスによって記録および中継することができる。これは、簡素な電話固定電話およびスマートフォン以外の携帯電話を含む。また、Chirpは、デジタルメディアに格納することも、テープ、ビニール盤またはビデオテープなどのアナログメディアに格納することもできる。アナログメディアとデジタルメディアの両方にChirpを記録できるということは、テレビなどの大型の機能不可リレー上での放送用の他のメディアにもChirpを適合できることを意味する。例えば、テレビ広告は、Chirp音声トラックを含み得る。保存コードサービス生成された音楽コードのいくつかは、周知の曲のように聞こえる場合がある。EdとDdが可逆機能であれば、これらの曲のバージョンをMIDIなどのMDLで作成することができ、次いで、対応するショートコードを見つけて、保存することができる。これは、有料サービスであり得る。このプロセスは、テーマ曲Windowsの開始、Intelのジングルなどの捕捉および特定のウェブサービスへのそれらのリダイレクトに対してうまく機能するであろう。厳密なピアツーピアモデル1つのモデルは、スタンドアロンアプリケーションにChirpを組み込むことである。次いで、ショートコードは、アプリケーション特有の意味論を有することができる。例えば、バウチャを共有したアプリケーションでは、モバイルデバイスにダウンロードされたアプリケーションに、画像としてバウチャ自体を組み込むことができる。特定のChirpがデバイスで聞こえると、バウチャのロックが解除されることになるが、コードは、単にアプリケーションでバウチャをアクティブ状態にするためにある。Chirpがデバイスで聞こえた時点で、そのデバイスは、Chirpを中継できるようになる。これにより、バウチャまたはクーポンのウイルスのような共有が可能となる。それに加えて、バウチャが広まった参加者の数を符号化して、バウチャを適切に渡すことができ、また恐らく、バウチャが他の誰かに渡った回数も符号化することができよう。これを行うには、ショートコードが1つのバウチャと一致しない場合もあり得るが、コード生成ループがあり、それにより、既知のシーケンスにおいて次のショートコード、したがってChirp音声を生成することができる。したがって、受信アプリケーションは、どのショートコードかを見分けることばかりでなく、その履歴についての何かを見分けることも可能となる。これにより、ある特定の人数がそれを保有した後でのみ与えられるタイプのバウチャコードを有効にすることができる。別の概念は、新しいバンドビデオの一部またはビデオのトレーラなどの他のメディアタイプをウイルスのように共有することであろう。その結果、ユーザは、アプリケーションをダウンロードする際にメディアのランダム部分を入手することになるが、ユーザと友人は、Chirpコードを交換することによってメディアの他の部分を収集することが可能である。これにより、友人のグループは、ビデオまたは音声トラックをまとめて即座に組み立てることができるようになり、メディアの周りでの相互作用が容易になる。リモート操作の例一例は、聴取者の近くの機器例えば、ChirpAppのウェブバージョンを実行しているPCに信号として組み込まれたChirpとの会話に基づく。これにより、例えば、コールセンタ職員は、あるページへ強制的に移動させることによって、ローカルのPCをリモート制御できるようになる。これを実施する一方法は、ウェブページ上のFlashアプレットにChirp読取機を組み込むことである。Flashは、マイクロホンへのアクセスを有するため、テレビまたはスピーカフォンからの出力などのローカル環境でChirpを聞き取ることができる。したがって、リモートオペレータは、話している間に、Chirpを送信することができ、Chirpはウェブページ上のアプレットで聞こえるようになる。次いで、アプレットは、ページを変えること、アニメーション化することなどによって、ウェブページを操作することができる。それは、そうでなければ制限される可能性があるウェブサイトのある特定のエリアを起動するための安全なコードを運ぶことさえも考えられる。その利用可能性は、PCの技術サポートにおいてであろう。信頼できるピアツーピアおよび安全なピアツーピアこれまで説明されてきたように、Chirpは、一方向のデータ転送に使用することができる。論じられるように、Chirpは、放送テレビなどの非対話的なメディア上で放送することができる。しかし、スマートフォンや他のプラットホームを用いることで、送信者は、ほぼ確実に受信者として機能できるようになる。送信者と受信者の両者とも送信も受信も可能な場合は、複数段階プロトコルを実施することができる。例えば、2つのデバイスは、識別情報例えば、こんにちは、私はデバイスXですを表し、こんにちはX、私はデバイスYですと応答させるコードおよびChirpを送信することによって、ハンドシェイクを行うことができる。次いで、デバイスXは、Y、ChirpZを送りますというメッセージを送信することができ、X、YはChirpZを受信しましたという応答で返すことができる。これにより、Chirp転送はより信頼できるものとなる。デバイスXは、Zのコピーを手に入れることができ、そのコピーに何らかの形で歪みが生じた場合は、デバイスXは再送信することができるため、適正にデバイスYがChirpを受信したことを検出することができる。また、デバイスXは、ある特定の時間内に何の連絡もなく、デバイスで聞こえなかったかまたは応答できなかったかの何れかであると想定した場合にも、再送信することができる。何れの場合にも、デバイスのユーザがChirpを聞き取れる可能性があり、データが再送信されたかまたは再送信する必要があるかどうかを理解できる可能性があり、必要ならばデバイスのユーザは干渉できることを理解することが重要である。上記に付け加えて、公開/秘密鍵の交換を使用してChirpZを符号化することも可能である。デバイスは、簡単な識別子よりもむしろ、公開鍵KPXおよびKPYを交換する。次いで、KPrXの秘密鍵でChirpを符号化して、暗号化されたChirpZ’を作成することができる。次いで、デバイスYは、コンテンツが安全であることと、送信者が確かにXであることの両方を知ることができる。すべてのピアツーピアシステムに対し、トランザクションの登録が可能なように、ウェブサービス上にオーディットトレールが存在し得る。具体的には、ウェブサービス上に公開鍵を格納することができる。ChirpとPinピアツーピアサービスの拡張の1つは、支払サービスなどの外部サービスとの相互作用を容易にすることである。支払サービスは、トークンの何らかの形式の交換を必要とし、Chirpはそのトークンであり得る。これは、少なくとも3つの異なる方法で機能することができる。第1に、Chirp自体は、Chirpを生成するアプリケーションが、ウェブサービスからいくつかのChirpコードを購入することができ、それらを受信者に中継できるという意味で、貴重なものであり得る。したがって、Chirpアプリケーションは一種の財布として機能し、送信者がオンライン状態である必要はない。受信者はオンライン状態であってもなくともよい。Chirpが多大な量に対するものである場合は、受信者は、それが未だ使用されていないことを検証できるオンラインサービスにそれを転送することによって、即座にそれを現金化することを希望する場合がある。第三者がChirpを耳にした場合は、その第三者は、それを現金化する際に受信者を打ち負かす必要がある。それらは、これを行うため、物理的に近くなければならない。安全な転送を使用することが可能である。第2に、Chirpアプリケーションは、ウェブサービスを運営するためにUK銀行口座で現在分配されているセキュリティデバイスと同様に機能することができる。アプリケーションは、通常のVISAまたは他のクレジット/デビットカードの詳細を符号化することができ、ユーザは、通常のPINを入力することができる。ウェブサービスにタイプする8桁のコードを捉える代わりに、デバイスは、Chirpを8桁コードにすることになる。受信者は、カードネットワークでこのコードを検証することができる。図8を参照して、本発明の実施形態によるデバイス800について説明する。示されるデバイス800は、入力デバイス801と、メモリ802と、エンコーダ803と、送信機804とを備え得る。入力デバイス801は、ユーザから認証入力を受信するよう構成することができる。メモリ802は、ユーザ識別を格納するよう構成することができる。エンコーダ803は、可聴的に一意な形式の信号にユーザ識別および認証入力を符号化するよう構成することができる。送信機804は、可聴音声の再生成のために信号を送信するよう構成することができる。デバイス800は、トランザクションの認証に使用することができる。好ましくは、トランザクションは、金融取引であり、ユーザ識別は、ユーザ口座情報を含むかまたはそれに関連する。あるいは、トランザクションは、物理的アクセスまたはワイヤレスネットワークへのアクセスに対してなど、ユーザを認証するためのトランザクションであり得る。また、エンコーダは、デバイス800のIMEIなど、デバイス800の位置またはデバイス800用の識別子を信号に符号化することもできる。それに加えて、可聴信号を受信する受信デバイスは、ユーザ識別情報をユーザと一致させ、ユーザをユーザに対する認証の履歴記録と一致させることによって、または、ユーザを受信デバイスのユーザのソーシャルネットワークと一致させることによって、デバイス800またはデバイス800のユーザをさらに認証することができる。また、受信デバイスは、先の時間のデバイス800の先の位置を使用してスプーフィングを防止するために、デバイス800が受信デバイスの位置にもっともらしく位置し得るかどうかを計算することによって、および、先の位置と現在の位置との間の移動時間が可能かどうかを計算することによって、デバイス800をさらに認証することもできる。図9を参照して、本発明の実施形態による方法900について説明する。ステップ901では、認証入力デバイスを介してユーザから認証入力を受信する。ステップ902では、ユーザ識別および認証入力を可聴的に一意な形式の音声信号に符号化する。ステップ903では、可聴音声の再生成のために音声信号を送信する。第3に、Chirpアプリケーションは、銀行サービス間のリレーとして動作し得る。すなわち、送信者は、ワンタイムChirpコードに対するオンラインサービスを依頼することになる。受信者は、これを即座に現金化しなければならないことになっており、トランザクションは、効果的に、2つのオンライン銀行サービス間のループを閉じる。先述の安全なサービスと組み合わせると、Chirpを使用して他のシナリオを容易にすることができる。小型の音声放送機器が組み込まれたグリーティングカードは、金銭価値を実際に反映し得る。マイクロペイメントまたはクレジットは、店内公示システム上で広めることができる。認証Chirpアプリケーションをデバイス上で実行することができ、そのデバイスに所有者がいるため、多要素認証MFAを使用することができる。具体的には、銀行セキュリティデバイスとの類似性に従って、Chirpアプリケーションは、ユーザからのPINにアクセスできるばかりでなく、ウェブサービスからのID、GPSからのユーザの位置の履歴、デバイスのIMEI番号にもアクセスすることができる。これらのいくつかまたはすべては、ショートコードに符号化することができる。他の複数の要素は、デバイスカメラ、加速度計および社会的履歴からのデータを含み得る。対形成Chirpアプリケーションは、Chirpを使用して、Bluetooth接続用のPINを分配することができる。アプリケーションは、必要ならば、デバイス上でBluetoothを初期化することができるそれには、ポップアップメニューを通じたユーザ承認が必要とされる場合がある。同様に、対形成スキームは、WiFiまたはRFID用に、すなわち、対形成セキュリティの強化またはユーザ経験の円滑化に二次チャネルが役立つものの何れに対しても、初期化することができる。ゲームアプリケーション操作の特定の変形形態は、Chirpを使用して、マルチユーザゲームをサポートすることである。これは、戦略ゲーム、カードゲーム、アドベンチャーゲーム、取引ゲームなどの展開が遅いゲームに特に適するであろう。ハードウェアチップ上のChirp物理的なインターフェースがアクセス不可能であるか、または、制御モバイルデバイスによってより安くもしくは好都合にアクセス可能な状態にすることができるかの何れかの場合は、マイクロホンを装備したハードウェアで、組み込まれたChirpを使用して、デバイスを制御することができる。Chirpは、音声を介して制御メッセージを送信することができる。考えられる用途は、オーブンタイマのプログラミングまたはPVR上でのペアレンタルコントロールの設定を含む。制御メッセージは、Chirpのシーケンスとして送信することができる。オーブンまたはPVRに対する動作を決定するシーケンス。Chirp受信機は、USBドングル上に構築することができる。USBドングルは、音声を受信するためのマイクロホンと、音声をショートコードに変換するデコーダと、ショートコードと関連付けられたデータを入手するためにウェブサービスにアクセスするためのメカニズムとを含み得る。USBドングルが差し込まれるコンピュータのwifi能力をメカニズムが利用することも、USBドングルがwifiトランシーバを含むこともできる代替のトランシーバは、最終的にネットワーク接続を介したウェブサービスへの接続を容易にするBluetoothまたは他のRFのように構想することができる。URLと有効期限ウェブサービスを復号に使用することができるため、さまざまな特性、例えば、受信者の位置例えば、主なペイロードを手に入れるため、受信者は送信者の位置の近くでなければならない、時間、ソーシャルネットワーク例えば、友達の友達のみ、ランダムな報酬支払例えば、宝くじ、識別例えば、Chirp内で最終受信者を符号化し、その人物に特有のコンテンツをアクティブ状態にするに応じて異なる復号を実行することができる。ウェブアプリケーションの制御一実施形態では、ウェブアプリケーションは、Chirpを受信して復号し、復号したChirpを使用してウェブアプリケーション内の動作を制御するように適合させることができる。代替の例では、Chirpは単なる音声であり得、ウェブアプリケーションは、音声を動作に一致させることができる。音声は、格納された音声への直接マッピング、フィンガープリント法またはショートコード用のサーバを用いたショートコードへの復号を使用して、ウェブアプリケーション内に格納されたデータと一致させることができる。ウェブアプリケーションは、Javaアプリケーションなどのクライアント側のものでも、ウェブブラウザが音声をサーバに渡す場合はサーバ側のものでもあり得ることが理解されよう。ここで、図10を参照して、本発明のさらなる実施形態について説明する。発明者は、モバイルデバイス上に以前に格納されたコンテンツのロック解除が有用であることを発見した。コンテンツのロックを解除するための前のシステムは、コードをダウンロードしてデバイス上に格納されたコンテンツにアクセスすることを含む。また、デバイス上の機能性のロックも解除されることも同様に望ましいであろう。コンテンツ要素は、バーチャルグッズを表し得る。したがって、音声を使用して、デバイス上のバーチャルグッズのロックを解除することができる。ここで、本発明のこの実施形態において、音声の受信と同時にモバイルデバイス1001上のコンテンツのロックを解除するためのシステムについて説明する。本発明のこの実施形態では、コンテンツ/機能性を入手する2つの方法があり得る。1アプリケーションをダウンロードするかまたは入手する際に、コンテンツをダウンロードする。2アプリケーションによってコンテンツをデバイスにプッシュするかまたはデバイスにプルする。例えば、毎日、新聞のコンテンツをモバイルデバイスにプッシュすることができる。デバイス1001上のアプリケーションは、コンテンツアクセスを管理することができる。例えば、アプリケーションは、wifi接続への接続が可能な場合に、ネットワークトランシーバ1002を介してコンテンツアクセスを自動化することができるすなわち、3G上での広帯域の使用を削減するため。アプリケーションは、プロセッサ1003によって実行することができる。コンテンツ要素1004は、デバイス1001のメモリ1005上に格納することができる。コンテンツ1004がそのロックを解除するためのコードを含むことも、コンテンツ1004をコードで暗号化することも、アクセシビリティコードを格納するアプリケーションによって、コンテンツ1004へのアクセスを管理することもできる。コードは、ショートコードであり得る。コードは、デバイス1001に特有でも、コンテンツ1004に特有でもあり得る。コンテンツ1004は、マルチメディア、URL、アプリケーション機能性例えば、ゲームまたは新しいゲームレベルのロックを解除する、または、新しいコードでさえもあり得る。コンテンツへのアクセスを得るためコンテンツのロックを解除するため、デバイス1001は、デバイス1001のマイクロホン1006から音声を受信することができる。音声は、図3で説明された符号化プロセスに従って、音声内でショートコードを符号化することができ、音声自体がコードであることも、コードを入手するために音声をフィンガープリントすることもあり得る。音声が符号化される場合は、音声は、音声デコーダ1007によってコードに復号される。コードは、デバイス1001上に格納されたコンテンツ1004と一致させ、コンテンツへのアクセスを提供する。コンテンツへのアクセスは、コンテンツアプリケーション1009によってユーザインターフェース1008を通じてユーザに提供することができる。例えば、コンテンツはMP3であり得、デバイス上の音楽プレーヤ上でMP3を再生することによって、アクセスが提供される場合がある。代替の実施形態では、コードに加えて、コンテンツへのアクセスの提供にさらなる制約が必要とされる。例えば、複数のコードを受信する必要がある場合も、ユーザデバイス1001が特定の位置例えば、搭載GPSチップによって決定されるようにになければならない場合も、それが特定の時間帯内または特定の時間の前/後になければならない場合もある。音声は、テレビもしくはラジオ上の放送またはPAシステム上で、別のモバイルデバイスからのピアツーピア音声送信を介して受信することができる。音声は、この明細書の他の場所で説明されるようなChirpであり得る。本発明のこの実施形態の潜在的利点は、オフライン状態の間にユーザ間でコードを共有できるということである。その上、コンテンツをダウンロードする必要なく、コードがコンテンツのロックを解除するため、オフライン状態で即座に満足を得ることができる。ここで、図11を参照して、さらに、本発明のさらなる実施形態について説明する。バウチャは、商品またはサービスと引き換えることができるトークンである。一般的なバウチャは、ユーザにもトランザクションにも特有でないバウチャである。一般的なバウチャは、現在、紙形式または電子形式である。一般的なバウチャは、紙形式のバウチャを渡すかもしくは示すことによって、または、モバイルデバイス画面などの視覚ディスプレイ上に電子バウチャを表示することによって引き換えられる。発明者は、一般的なバウチャを引き換える先行技術の代替手段を提供することが望ましいという結論を下した。ここで、バウチャが音声で引き換えられる場合の本発明の実施形態について詳細に説明する。第1のユーザデバイス1101が示されている。好ましくは、第1のデバイス1101は、スマートフォンなどのモバイルユーザデバイスである。第1のデバイス1101は、ネットワーク接続1103上でウェブサービスとしてアクセス可能であり得るデータベース1102からバウチャを受信することができる。バウチャは、バウチャ用の識別子として表すことができる。あるいは、第1のユーザデバイス1101は、第2のユーザデバイス1104から音声でバウチャを受信することができる。好ましくは、第2のユーザデバイス1104は、モバイルユーザデバイスである。その上、第2のユーザデバイス1104は、さらに別のユーザデバイスからバウチャを受信して、初めにデータベース1102からバウチャを受信した第1の発信元デバイスから現デバイス1101へのユーザデバイス共有の連鎖を形成した可能性がある。バウチャが音声形式で受信されない場合は、図3に示される符号化方法に従って、音声形式でバウチャを符号化することができる。その上、第1のユーザデバイス1101は、バウチャを音声に符号化する際に、バウチャ識別子を有する一意なユーザ識別子を含み得る。一実施形態では、符号化音声は、以下の形式で符号化することができる。バウチャ識別子共有数発信元ID照会人ID発信元IDは、連鎖内でバウチャを直接共有する第1のユーザの識別子であり、照会人IDは、現ユーザにバウチャを提供する最後のユーザの識別子である。代替の実施形態では、発信元から最後の照会人までの共有の連鎖内のユーザはすべて、符号化音声に追加することができる。この形式は、バウチャを共有する挙動の後の分析を可能にすることができる。音声は、第1のユーザデバイス1101上のスピーカ1105を通じて無線インターフェース上で送信することができる。商業デバイス1106が示されている。商業デバイス1106は、メモリ上に格納されたデータベース1107を含むことも、データベース1107へのアクセスを単に有することもできる。データベース1107およびデータベース1102は、同じデータベースでもよい。データベース1107は、多数のバウチャ1108を格納する。商業デバイス1106は、第1のユーザデバイス1105から送信された音声を受信することができる。音声は、商業デバイス1106上のマイクロホン1109を介して受信することができる。商業デバイス1006は、受信した音声をデータベース1107内の多数のバウチャ1108と一致させることができる。音声は、音声フィンガープリント法を介して、データベース1107内に格納された音声と直接一致させることも、音声は、図3で説明されるようにショートコードを符号化し、音声を復号し、ショートコードをバウチャ1008と一致させることもできる。一致させたバウチャに関連する情報は、バウチャの価値の検証のために商業デバイス1106上に表示することができる。例えば、バウチャは、第1のユーザデバイス1101のユーザが、50割引の購入品を受け取ること、または、購入品とともに無料ギフトを受け取ることを示す場合がある。バウチャの引き換えには制約がある場合がある。制約は、バウチャの送信に責任を有する第1のユーザデバイス1101上のアプリケーション上で施行すること、および/または、商業デバイス1106側で施行することができる。制約は、ユーザ1人当たりのバウチャの数の限度を含み得る。この例では、商業デバイス1106は、使用されたユーザ識別子およびバウチャを記録するためのデータベース1120を含むことも、同データベース1120へのアクセスを有することもできる。制約は、バウチャの引き換えを最初の100人例えばに限定するため、バウチャの総数限度を含み得る。制約は、考えられるバウチャ引き換えの場所例えば、複数の所在地があるベンダーの特定の場所または時間の制限を含み得る。ここで、図12を参照して、さらに、本発明のさらなる実施形態について説明する。伝統的には、紙幣、貨幣または譲渡不可能なバウチャなどの物理的トークンを使用して関係者間で送金が行われる。このプロセスの明確に不利な点は、物理的トークンは失いやすい可能性があり、取り扱いに関連するコストまたは不便性があるということである。送金するための他の方法は、クレジットカード、デビットカードおよびプリペイドカードなどの電子手段を含む。そのような方法は、かなりのインフラ要件すなわち、特殊な読取デバイスを有し、クレジット/デビットカードは、ユーザベースの認証プロセスも必要とする。発明者は、送金するための代替のシステムが望ましいという結論を下した。ここで、音声を使用して送金が行われる本発明の実施形態について説明する。第1のモバイルユーザデバイス1201が示されている。モバイルユーザデバイス1201は、着信音の付いたSMSメッセージを受信することができる任意の携帯電話であり得る。あるいは、モバイルユーザデバイス1201は、音声任意の形式、例えば、MP3、MIDIでを受信して格納することができるかまたはコードを受信してコードを音声に符号化することができるスマートフォンであり得る。第1のモバイルユーザデバイス1201は、モバイルテレコミュニケーションネットワーク1203上で、信頼できる第三者1202銀行などからの特定の金銭的価値に対する一意な識別子を要求することができる。信頼できる第三者1202は、識別子を生成して、識別子と特定の金銭的価値の両方をデータベース1204に格納することによって、要求を処理することができる。一代替手段では、信頼できる第三者1202は、第1のモバイルユーザデバイス1201のユーザが保有する銀行口座または他の金銭口座の借記を指示することができる。識別子は、ショートコードであり得る図3で説明されるように。信頼できる第三者1202は、識別子をMDL形式に符号化し図3で説明されるように、符号化識別子を第1のモバイルユーザデバイス1201に送信することができる。あるいは、信頼できる第三者1202は、第1のモバイルユーザデバイス1201に直接識別子を送信することができ、第1のモバイルユーザデバイス1201が識別子自体を符号化することができる。さらなる代替手段では、信頼できる第三者1202が、識別子をMDLに符号化し、次いで、音声に符号化することができる。さらに、さらなる代替手段では、識別子は音声であり得る。識別子符号化されていない、MDLに符号化された、または、音声のは、第1のモバイルユーザデバイス1201上のメモリ1205上に格納される。例えば、識別子は、着信音として受信することができる。第1のモバイルユーザデバイス1201のユーザが特定の金銭的価値の使用を希望する際、第2のデバイス1207に対し、スピーカを通じて音声1206として識別子を再生することができる。識別子が音声形式でない場合は、第1のモバイルユーザデバイス1201は、識別子を音声形式に符号化することができる図3で説明されるように。第2のデバイス1207は、商業デバイスまたは別のユーザデバイスであり得る。第2のデバイス1207は、識別子の有効性を確認し、通信ネットワーク1209上で信頼できる第三者1202または、仲介物1208と連絡を取ることによって特定の金銭的価値の受信を実施し、識別子を送信することができる。第2のデバイス1207は、信頼できる第三者1202に送信する前に、受信した音声をショートコードまたは他のコードに復号することができる。一代替手段では、第2のデバイス1207は、信頼できる第三者1202を呼び出し、第1のデバイスからの音声を信頼できる第三者1202へ中継することによって、識別子を送信する。信頼できる第三者1202または、仲介物1208は、特定の金銭的価値と識別子を一致させることによって、データベース1204内で識別子を検証する。検証ステップは、不正行為の防止に役立てるための特定の金銭的価値の使用に対する制約を含み得、例えば、特定の金銭的価値は、地理的な位置例えば、LondonまたはUKへの制限も、特定のベンダーまたはベンダーファミリー例えば、Starbucksへの制限も、特定の時間への制限も、特定の目的例えば、本の購入のみへの制限も有し得る。代替の実施形態では、特定の金銭的価値は、制約の範囲内で再利用が可能であり、例えば、特定の金銭的価値は、1日1回または週に5回の利用が可能である。信頼できる第三者1202は、特定の金銭的価値の反復使用を防ぐため、識別子を使用済みとマーク付けすることができる。検証された時点で、信頼できる第三者1202は、第2のデバイス1207に関連する銀行または他の金銭口座への特定の金銭的価値の転送を実施することができる。信頼できる第三者1202は、識別子の有効性の検証を第2のデバイス1207に送信することができる。したがって、第2のデバイス1202または第2のデバイスのユーザは、第1のデバイス1201のユーザによって着手されたトランザクションの終結を促進することができる例えば、商品もしくはサービスを提供することによって、または、会場へのアクセスを提供することによって。その上、上記の実施形態は、PKIなどの暗号化を使用することによって変更することができ、これは、音声を使用して起こり得るハンドシェイクプロセスを伴う場合がある。しかし、特定の金銭的価値は第2のデバイス1207によって即座に検証されるため、これは、第1のデバイス1201と第2のデバイス1207との安全な接続に対する要件を軽減することができる。上記で説明されるものに対する代替の実施形態では、第1のデバイス1201をパイプとして使用し、第2のデバイス1207に対するトランザクションを検証することができる。これは、第1のデバイス1201は接続されているが、第2のデバイス1207は接続されていない場合に有用であり得る。図13を参照して、そのような実施形態について説明する。第1のモバイルユーザデバイス1301転送側のデバイスが示されている。特定の金銭的価値は、信頼できる第三者1302から第1のデバイス1301によって要求される。信頼できる第三者1302は、特定の金銭的価値に対する識別子を第1のモバイルユーザデバイス1301に送信する。第1のモバイルユーザデバイス1301は、トランザクションに対応する音声1303を第2のデバイス1304受信デバイスに送信する。第2のデバイス1304は、信頼できる第三者1302と通信するためのリレーとして第1のデバイス1301を使用して、特定の金銭的価値を検証することができる。例えば、第2のデバイス1304は、信頼できる第三者1302まで中継される暗号化メッセージ認証要求1305を送信することができ、信頼できる第三者1302は、第2のデバイス1303によって検証され得る暗号化された応答認証価値1306で応答することができる。あるいは、第2のデバイス1303は、信頼できる第三者1302からの秘密の応答を要求することができるすなわち、第2のデバイス1303と信頼できる第三者1302のみが知っている質問に対する回答。不正行為を阻止するため、質問は、一回限りの質問であり得る。信頼できる第三者1302および第2のデバイス1303は、認証プロセスを管理するための認証エンジン1307および1308を含み得る。特定の金銭的価値は、通常、現金、カードまたはマイクロペイメントで行われる支払いを含み得る。本発明のこの実施形態は、仮想の送金に使用することができる。図14a、14bおよび14cを参照して、本発明のさらなる実施形態について説明する。ChirpユーザインターフェースUIは、3つの機能聴取、Chirpおよび格納専用の3つの画面S1~3から構成される。この実施形態で言及されるChirpは、図3を参照して説明されるショートコードを符号化する音声の送信である。しかし、代替の実施形態では、Chirpは、図10、11、12、13または15で使用できるような任意のデータを符号化する音声も含み得る。初期ロード後、音声データ受信に対して適正なモードにアプリケーションをすぐに切り替えられるように、アプリケーションはデフォルトのS1聴取になる。S1聴取:S1は、マイクロホンを起動し、デバイスを検出モードに切り替え、Chirp信号を聴取し始める。S1は、リアルタイムでの波形表示によって、マイクロホンを介して検出可能なすべての音事象人間の耳で容易に検出可能または明らかでなくなる音まで。その音も含むをリアルタイムで表示する。ユーザは、aマイクロホンがアクティブ状態であること、および、b素早い目視検査によって音声検出レベルマイクロホンの感度が適切に設定されていることを容易に識別することができる。また、ユーザは、ローカル環境がcChirpの送信または受信前に、比較的騒々しいかまたは静かであるか、そして、それに応じて音声データの転送の達成が難しいかまたは簡単かを決定することができる。直前の数秒間に示されるピークおよび周囲の音エネルギーの測定値は、波形を動的に着色し直す悪状態の場合は赤色、許容値は黄色、最適状態の場合は緑色ことによって表示される。これらの3つの変数を表示するため、ユーザが複数の視覚様式を利用できるようにすることが予想される。音視覚化エリアの真下では、英数字またはアイコンを含む一連のタンブラは、検出順に検出されるように、無線音声入力から捉えた復号データを表示する。また、S1は、S2へのリンクも含むChirpボタンを見ること。S2Chirp:S2は、格納されたデータかまたは最近捕捉されたデータを共有するための一連の異なるデータプロトコルを集約する。画面の上部では、ユーザは、受信された最後の英数字のショートコードを見ることができ、その真下では、視覚、可聴およびテキスト分配方法を含むしかし、これらに限定されない、そのショートコードを共有するための多くの利用可能な方法を見ることができる。可聴方法内では、Chirpとマーク付けされたボタンを押すと、コードは、他のChirpクライアントアプリケーション用に音で再表現される。視覚方法内では、ショートコードは、EPOSシステムを使用して、考えられる引き換え用のQRコードとして動的に表現および表示される外部のスキャンまたは画像取込デバイスを介して。また、他のオープンソース、または、Aztecコード、セマコード、Microsoft高密度コードを含む2D視覚的コードのファミリーの専用メンバーもサポートされ得る。テキスト方法内では、Twitter、EメールまたはSMSクライアントアプリケーションを開いて、これらのアプリケーションのコンテンツフィールドに現在アクティブ状態のショートコードを事前に追加するための手段が提供される。これらのオペレーションのすべては、シングルクリックで達成される。さらに便利なことに、TwitterまたはEメール共有の場合、受信者の利益のためのクリック可能なリンクは、適正なプロトコルタイプとサーバアドレスを単にコードの先頭に追加することによって、Chirpアプリケーションによって構築され、通常、これはhttp://chirp.io/であり得るが、好ましくは、例えばChirpにリンクされたファイルは、ftpまたは他のファイル共有プロトコルを使用したアプリケーションを介して取り扱われる場合がある。呼び出されるべきすべての外部のアプリケーションまたは機能は、その機能に適切なアイコンでマーク付けすることができる。最後に、上記で与えられた手段の一方または他方によるChirpの検出またはChirpアプリケーションへのデータの受信によって、ローカルファイルが起動されるかまたはアクセス可能になる場合、アイコンは、感嘆符を表示することができ、そのコンテンツは、コンテンツのタイトル例えば、LuckyChirpを表示するアイコンまたはボタンをクリックすることによって利用可能にすることができ、そのコンテンツ音声、映像、グラフィックス、HTML、対話式ゲームデータまたは機能は、適切なクライアントアプリケーションを使用することによって開くことも、ホストアプリケーション自体で取り扱うこともできる。S2は、単一ボタンを介して各共有方法が呼び出し可能な状態で、そして、各サブアプリケーションが知的に自動的に補われた状態で、単一画面にすべての共通の共有機能を集約する。あるいは、クリップボードコピーバッファにショートコード文字列を事前に追加することもでき、ユーザは、デスクトップまたはOSレベルに切り替えることによってChirpアプリケーションを離れ、ユーザの好ましいメール、Twitter、2Dコード作成アプリケーションへナビゲートし、そこから変換するかまたは送信するかの何れかまたは両方のためショートコードにペーストすることができる。S2に示される方法は、共有方法を制限せずに必要なフローを予想することによって、明らかに高速であり、より効率的な共有を可能にするため、好ましい。さらなる代替手段は、動的に作成されたプロキシリターンEメールもしくはSMSアドレスの使用および/または適切で永久的な真の送信トレイへのCC送信によって、さらに迅速なロード時間のための軽量のアウトバウンドのみのアプリケーションを使用することである。このようにしてプロキシアカウントを使用して、希望する場合は、好都合なことに、Chirpを他の通信とは別々に保持することができる。また、S2は、サーバ側での後の分析のためおよびS3上での表示のため、行われた共有の数および共有モードを記録することができる。S3格納インターフェースは、ローカルでまたはサーバを介しての何れかでChirpと一致した一意な識別子のリポジトリとして機能する。第1のセクションは、最近の受信トレイ活動最近受信したn個のChirpnはユーザが定義するを示すためのトグル機能の付いた、逆の順序での最近受信した5つのChirpを示す。Chirpは、サーバにアクセスすることによって決定することも、デバイス側の情報から決定することもできる状態と関連し得る。例えば、サーバ側のChirpと関連するデータが未だアップロードされていない場合は、Chirpの状態は未だ利用不可能であるか、または、Chirpと関連するデータが期限切れの場合例えば、データが期間限定のバウチャのような時間依存性である場合は、Chirpの状態は期限切れであり得、サーバ側で未だChirpがアクセスされていない場合は、状態はアクセスなしであるか、または、Chirpがアクセス条件と関連している場合特定の場所または特定の時間の間でなければならないなどは、状態はその条件と関連するかもしくはChirpの状態は隠された状態であり得、そういう場合には、Chirpは表示すらされない可能性がある。状態は、Chirpのバックグラウンドの着色によってユーザインターフェース内に示すことができる。ページは、ユーザの略歴、地理またはタスクコンテキスト別に、音声音声表現はローカルに格納されるを介して即座に送信できるアイテムを大まかに細分化する。略歴は、Facebook、LinkedIn、Twitterなどのソーシャルネットワークプロフィールアドレスを含む、共有可能なマイクロ形式としてのユーザの詳細な連絡先、ホームページおよび/または仕事の詳細を含み得る。音声送信用にこれらのデータアイテムを準備するため、ユーザは、これらのサービスのそれぞれに対して、彼または彼女の一意なユーザ名を入力しなければならない場合があり、Chirpアプリケーションは、簡単な共有のために音声として符号化された完全なhttp://アドレスを返すか、または、一意なユーザ名が見つからない場合は、不明瞭性解消を要求する。地理は、地理的に位置付けされたすべてのURLを含み、例としては、地図アプリケーション上で最近検索された場所例えば、地図検索のユーザ履歴から入手、場所に基づくソーシャルネットワーク上の地域別チェックインなどが挙げられる。典型的な使用例は、提案された会合場所、お勧めの小売業者などのワンクリック共有である。コンテキストに即した格納は、1つのアプリケーションもしくはアプリケーションクラス、または、デバイスの態様に関連するアイテムを含み得、例としては、1つまたは複数のブラウザに対するお気に入りもしくは履歴、最近再生された音楽、最近かけた電話からの電話番号、最近受信/送信したEメールからのEメールアドレス、連絡先リストからの電話番号、カレンダーイベント、または、デバイス上の最新の活動に関連するデータ例えば、ユーザが最近地図アプリケーションを閲覧し、その上で場所を特定した場合、データアイテムは地図位置であり得るが挙げられる。送信できるアイテムは、カメラロール上に格納された画像またはデバイス上のアプリケーションのリストなどの任意のローカルに格納されたデータであり得る。代替の実施形態では、任意のウェブベースのデータも送信することができ、そのようなアイテムは、FacebookのいいねlikeまたはAmazonのほしい物リスト/おすすめ商品であり得る。大抵の場合、適切なファイルハンドラまたは視覚表現が存在するかどうかを決定するために解析されるようなアイテム文字列、例えば、twitter.com文字列は、Twitterクライアントが取り扱いユーザによって定義されるように、適切なアイコンが与えられる。それに加えて、データアイテムは、デバイス上にローカルに格納されたゲームに関連するトークンピアツーピアで持ち込むことも、販売することも、取引することも可能なゲーム内のコンテンツであり得る。それに加えて、S3では、受信および送信されたユーザChirpの記録を表示することができ、共有メカニズムを奨励するため、場合により、高い共有比に基づいて、格納されたコンテンツのロックを解除するポイントが、ポイントに授与され得る。ユーザは、リフレッシュを押すことによって、データセット例えば、日替わりセールを手動でリフレッシュすることができる。次いで、サーバは、このトピックに関連する新しいChirpに対してクエリを行うこの場合、今日の特売品。代替の実装形態では、アプリケーションがロードされている場合、または、リアルタイムのメッセージングプロトコルを介して、例えばXMPP上で、新しいデータがクライアントアプリケーション上の1つまたは複数の関連セットにプッシュされる場合、データは自動リフレッシュされる。利用可能なセットのリストは、動的に形成することができるすなわち、即座にChirp可能な情報の新しいセットは、サーバ上で定義することができ、デバイス上のアプリケーションは、サーバと連携して、ユーザにChirpへのアクセスを提供することができる。図15を参照して、さらに、さらなる実施形態について説明する。第1のデバイスと第2のデバイスの両方の送信を聞き取るデバイスによる中間者攻撃に関して、第1のデバイスと第2のデバイスとの間の送信のセキュリティを改善するため、発明者は、両デバイスが同時に送信できることを発見した。聴取側のデバイスは、マイクロホンですべての音声を検出し、検出した音声からそれら自体の送信信号を取り除くことによって、送信側のデバイスの音声信号を検出することができる。この不明瞭化プロセスは、無計画な中間者攻撃において不利な点となり得る。また、音声信号を同時に送信する両デバイスは、美的に心地良いデュエットを提供することもできる。また、音声信号を同時に送信する両デバイスは、データ送信時間を削減することもできる。これは、同期的に行える場合に2つのデバイス間で暗号化鍵を共有する際に、特に有用であり得る。図15は、第1のデバイス1501と第2のデバイス1502とを示す。2つのデバイスは、交換に着手して、デバイスの後の音声同時送信を調整することができる。交換は、音声を使用してダイレクト無線インターフェース上で起こることも、電気通信システムを通じてなど、別のチャネルを通じて事前に定義されることも調整されることもあり得る。交換は、トーンの交換を伴う。調整は、時間同期化と基準ピッチトーンとを含み得る。好ましくは、デバイスの少なくとも1つは、モバイルテレコミュニケーションデバイスである。代替の実施形態では、2つのデバイスは、リアルタイムのフィードバックモデルでデバイスの受信した送信信号を使用して、デバイスのさらなる送信を適合させることによって、それら自体の同時送信内で、それらの同時送信を調整する。聴取者に音楽のように聞こえることにより同時送信がより美的に心地良く現れ得るというような同じ音楽キーを選択することによって、送信を調整することができる。送信を調整する他の方法は、和音内で音声を再生成するデバイス例えば、各デバイスは、3和音の1つまたは複数を送信することができるを含み得る。第1のデバイス1501は、第1のデバイス1501内のスピーカ1504上で第1の音声信号1503を送信することができる。第2のデバイス1502は、第2のデバイス内のスピーカ1506上で第2の音声信号1505を同時にまたは音声信号の重複をもたらすほど十分に同時に送信することができる。音声信号1503、1505は、データを符号化することができる。データは、図3で説明されるような方法を使用して、エンコーダ1507によって符号化することができる。データ送信が一方向の場合、音声信号の一方の信号1503のみがデータを符号化することができる。あるいは、データ送信が双方向の場合、両方の音声信号がデータを符号化することができる。データ送信信号を受信するデバイスすなわち、第1および/または第2のデバイス1502は、マイクロホン1508を使用して音声を聞き取り、次いで、信号プロセッサ1509を使用して、受信した音声信号を処理し、それら自体の送信信号を取り除くことができる。処理された信号は、デコーダ1510によって復号し、音声信号内に格納されたいかなるデータも回収することができる。一実施形態では、ピッチ、タイミングおよび音色のジッタリングスケジュール発振器の波形は、デバイス間で交換して、不明瞭化プロセスに役立てることができる。スケジュール交換は、調整段階の一部であり得る。本発明の実施形態において符号化された任意の音声に関連して、音声の一部を符号化して、それらの特徴を他の特徴と可聴音声で区別することができる。例えば、データの存在を示すためにタグを開閉するなど、プロトコルが構造上の共通の特徴を含む場合、これらの特徴は、共通の音で定義することができる例えば、ベントノート、急降下、トリル音または美的非コード伝達事象。それに加えて、データを符号化して、関連するデータとのその区別可能性を補助することができる。例えば、5ポンドを表すデータは、10ポンドを表す音声と完全に区別可能に符号化することができ、データが暗号化などの他の非共通の要素を含む場合、音声は、区別可能性を補助するために共通の要素を含み得、例えば、5ポンドのトークンを表す音声の暗号化された部分を共通の音声部分と組み合わせて、トークンが5ポンドを表すことを示すことも、URLまたはJPEGを表す音声の符号化された部分が一意な音声部分を含み、音声がURLに関連するかまたは音声がJPEGもしくは写真に関連するかを示すこともできる。この音声部分は、受信側のデバイスで復号することも、音声のコンテンツタイプを聴取者に可聴音声で示すためだけに存在することもできる。符号化されたデータタイプを示すことと同様に、音声部分は、誰からデータが送信されたか例えば、音声の送信機またはデータの発信元/所有者例えば、データを発信/所有する会社、例えば、データがバウチャであれば、バウチャを引き換える会社またはバウチャスキームオペレータを示すことができる。本発明は、コンピュータハードウェア上またはハードウェア自体の中で実行するソフトウェアとして実装できることが理解されよう。本発明のいくつかの実施形態の潜在的利点は、データは音声で送信され、すべてのモバイルデバイスは音声の受信および送信が可能なため、些細な変更が施すことでほとんどのモバイルデバイスでシステムを利用できることである。本発明のいくつかの実施形態のさらなるの潜在的利点は、デバイスの一方または両方がオフライン状態の際に、デバイス間でデータを通信できることである。本発明はその実施形態の説明によって示され、本発明はかなり詳細に説明されてきたが、添付の特許請求の範囲をそのような詳細に制限することまたは何らかの方法で限定することは出願人の意図ではない。追加の利点と変更形態は、当業者であれば容易に明らかであろう。したがって、そのより幅広い態様での本発明は、装置および方法を代表する具体的な詳細に限定されず、説明に役立つ実例が示され、説明される。それに応じて、そのような詳細からの逸脱は、出願人の本発明の一般概念の精神または範囲から逸脱することなく行うことができる。"