(57)【要約】  本発明は、データを通信するためのシステムに関する。具体的には、モバイルデバイスとデータ通信をやり取りするためのシステムについて説明する。１つのシステムは、サーバを使用して、ショートコードとデータとの間の関連付けを格納することを伴う。ユーザデバイスは、第２のユーザデバイスへのショートコードの送信に使用することができる。次いで、第２のユーザデバイスは、サーバで関連付けにアクセスし、データにアクセスすることができる。ショートコードは、２つのデバイス間で可聴的に一意な信号を介して送信される。また、すべて音声を使用した、バウチャを引き換えるため、送金するため、デバイス上のコンテンツのロックを解除するため、トランザクションを認証するためのさらなるデバイス、システムおよび方法も開示する。モバイルデバイス上でデータ通信を管理するための方法をさらに開示する。それに加えて、データを非同期送信するためのシステムは、ショートコードをデータと関連付ける前に、サーバでショートコードを保存するステップを使用することによって開示する。【特許請求の範囲】
【請求項１】
データを送信するためのデバイスにおいて、
サーバからデータと関連付けられたショートコードを受信するよう構成された受信機と、
前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のために前記信号を送信するよう構成された送信機とを含み、前記ショートコードはグローバルに一意であることを特徴とするデバイス。
【請求項２】
請求項１に記載のデバイスにおいて、前記可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含むことを特徴とするデバイス。
【請求項３】
請求項１または２に記載のデバイスにおいて、前記ショートコードは、アプリケーションヘッダを含むことを特徴とするデバイス。
【請求項４】
請求項１乃至３の何れか１項に記載のデバイスにおいて、前記ショートコードは、前記データのインデックスであることを特徴とするデバイス。
【請求項５】
請求項１乃至４の何れか１項に記載のデバイスにおいて、モバイルテレコミュニケーションデバイス用のコントローラであることを特徴とするデバイス。
【請求項６】
請求項１乃至５の何れか１項に記載のデバイスにおいて、前記受信機は、モバイルテレコミュニケーションネットワーク上で前記ショートコードを受信するよう構成されることを特徴とするデバイス。
【請求項７】
請求項１乃至６の何れか１項に記載のデバイスにおいて、前記ショートコードは、既定の固定長のものであることを特徴とするデバイス。
【請求項８】
請求項７に記載のデバイスにおいて、前記ショートコードの長さは、３２〜１０２４ビットであることを特徴とするデバイス。
【請求項９】
請求項１乃至８の何れか１項に記載のデバイスにおいて、前記信号は、音楽記述言語形式であることを特徴とするデバイス。
【請求項１０】
請求項９に記載のデバイスにおいて、前記信号は、ＭＩＤＩ形式であることを特徴とするデバイス。
【請求項１１】
請求項１乃至１０の何れか１項に記載のデバイスにおいて、前記信号は、冗長符号化を含むことを特徴とするデバイス。
【請求項１２】
請求項１１に記載のデバイスにおいて、前記信号は、冗長性に対してリードソロモン符号を使用することを特徴とするデバイス。
【請求項１３】
請求項１乃至１２の何れか１項に記載のデバイスにおいて、前記データは、ＵＲＬであることを特徴とするデバイス。
【請求項１４】
請求項１乃至１３の何れか１項に記載のデバイスにおいて、送信する前記データをユーザが決定することができるよう構成されたユーザ入力デバイスと、前記データを前記サーバに送信するよう構成されたトランシーバとをさらに含むことを特徴とするデバイス。
【請求項１５】
データを受信するためのデバイスにおいて、
マイクロホンで検出された音声信号を受信するよう構成された受信機と、
前記音声信号をショートコードに復号するよう構成されたデコーダと、
前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含み、前記ショートコードはグローバルに一意であることを特徴とするデバイス。
【請求項１６】
請求項１５に記載のデバイスにおいて、前記音声信号は、少なくとも何らかの鳥の鳴き声および／または音楽を含むことを特徴とするデバイス。
【請求項１７】
請求項１５または１６に記載のデバイスにおいて、前記ショートコードは、アプリケーションヘッダを含むことを特徴とするデバイス。
【請求項１８】
請求項１７に記載のデバイスにおいて、前記アプリケーションヘッダを読み取り、前記アプリケーションヘッダに応じて前記ショートコードの処理を決定するよう構成されたプロセッサをさらに含むことを特徴とするデバイス。
【請求項１９】
請求項１５乃至１８の何れか１項に記載のデバイスにおいて、前記ショートコードは、前記データのインデックスであることを特徴とするデバイス。
【請求項２０】
請求項１５乃至１９の何れか１項に記載のデバイスにおいて、モバイルテレコミュニケーションデバイス用のコントローラであることを特徴とするデバイス。
【請求項２１】
請求項１５乃至２０の何れか１項に記載のデバイスにおいて、前記トランシーバは、モバイルテレコミュニケーションネットワーク上で前記データにアクセスするよう構成されることを特徴とするデバイス。
【請求項２２】
請求項１５乃至２１の何れか１項に記載のデバイスにおいて、前記ショートコードは、既定の固定長のものであることを特徴とするデバイス。
【請求項２３】
請求項２２に記載のデバイスにおいて、前記ショートコードの長さは、３２〜１０２４ビットであることを特徴とするデバイス。
【請求項２４】
請求項１５乃至２３の何れか１項に記載のデバイスにおいて、前記デコーダは、ピッチ追跡を使用して前記音声信号の復号を補助することを特徴とするデバイス。
【請求項２５】
請求項１５乃至２４の何れか１項に記載のデバイスにおいて、前記データは、ＵＲＬであることを特徴とするデバイス。
【請求項２６】
請求項１５乃至２５の何れか１項に記載のデバイスにおいて、前記データにアクセスするステップは、前記データを前記デバイスに回収するステップを含むことを特徴とするデバイス。
【請求項２７】
請求項１５乃至２６の何れか１項に記載のデバイスにおいて、前記音声信号は、請求項１乃至１４の何れか１項に記載のデバイスから受信することを特徴とするデバイス。
【請求項２８】
請求項１５乃至２７の何れか１項に記載のデバイスにおいて、前記音声信号を受信した際に前記ショートコードおよび／または音声スペクトルを表示するよう構成されたディスプレイをさらに含むことを特徴とするデバイス。
【請求項２９】
データを非同期送信するためのデバイスにおいて、
サーバからショートコードを受信するよう構成された受信機と、
前記受信したショートコードを格納するよう構成されたメモリと、
前記受信したショートコードをデータと関連付けるよう構成されたプロセッサと、
前記受信したショートコードを第２のデバイスに送信するよう構成された送信機と、
前記関連付けを前記サーバに送信するよう構成された送信機と
を含むことを特徴とするデバイス。
【請求項３０】
請求項２９に記載のデバイスにおいて、前記受信したショートコードを送信する際、前記サーバに接続できないことを特徴とするデバイス。
【請求項３１】
請求項２９または３０に記載のデバイスにおいて、前記受信したショートコードは、ダイレクトインターフェース上で前記第２のデバイスに送信することを特徴とするデバイス。
【請求項３２】
請求項２９乃至３１の何れか１項に記載のデバイスにおいて、前記ダイレクトインターフェースは、音声インターフェースであることを特徴とするデバイス。
【請求項３３】
請求項２９乃至３２の何れか１項に記載のデバイスにおいて、前記デバイスは前記第２のデバイスと並置されることを特徴とするデバイス。
【請求項３４】
請求項２９乃至３３の何れか１項に記載のデバイスにおいて、前記関連付けを前記サーバに送信する前に、前記ショートコードを受信し、次いで、送信するよう構成されることを特徴とするデバイス。
【請求項３５】
請求項２９乃至３４の何れか１項に記載のデバイスにおいて、送信する前記データをユーザが決定することができるよう構成されたユーザ入力デバイスをさらに含むことを特徴とするデバイス。
【請求項３６】
データを送信するためのサーバにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサと、
前記関連付けを格納するよう構成されたメモリと、
前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のためにデバイスに前記信号を送信するよう構成された送信機と
を含み、
前記ショートコードはグローバルに一意であることを特徴とするサーバ。
【請求項３７】
請求項３６に記載のサーバにおいて、前記可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含むことを特徴とするサーバ。
【請求項３８】
請求項３６または３７に記載のサーバにおいて、前記ショートコードは、アプリケーションヘッダを含むことを特徴とするサーバ。
【請求項３９】
請求項３６乃至３８の何れか１項に記載のサーバにおいて、前記ショートコードは、データのインデックスであることを特徴とするサーバ。
【請求項４０】
請求項３６乃至３９の何れか１項に記載のサーバにおいて、前記送信機は、モバイルテレコミュニケーションネットワーク上で前記信号を送信するよう構成されることを特徴とするサーバ。
【請求項４１】
請求項３６乃至４０の何れか１項に記載のサーバにおいて、前記送信機は、モバイルテレコミュニケーションネットワーク上で前記信号を送信するよう構成されることを特徴とするサーバ。
【請求項４２】
請求項４１に記載のサーバにおいて、前記信号は、着信音としてＳＭＳチャネル上で送信することを特徴とするサーバ。
【請求項４３】
請求項３６乃至４２の何れか１項に記載のサーバにおいて、前記ショートコードは、既定の固定長のものであることを特徴とするサーバ。
【請求項４４】
請求項４３に記載のサーバにおいて、前記ショートコードの長さは、３２〜１０２４ビットであることを特徴とするサーバ。
【請求項４５】
請求項３６乃至４４の何れか１項に記載のサーバにおいて、前記信号は、音楽記述言語形式であることを特徴とするサーバ。
【請求項４６】
請求項４５に記載のサーバにおいて、前記信号は、ＭＩＤＩ形式であることを特徴とするサーバ。
【請求項４７】
請求項３６乃至４６の何れか１項に記載のサーバにおいて、前記信号は、冗長符号化を含むことを特徴とするサーバ。
【請求項４８】
請求項３６乃至４７の何れか１項に記載のサーバにおいて、前記信号は、冗長性に対してリードソロモン符号を使用することを特徴とするサーバ。
【請求項４９】
請求項３６乃至４８の何れか１項に記載のサーバにおいて、前記データは、ＵＲＬであることを特徴とするサーバ。
【請求項５０】
請求項３６乃至４９の何れか１項に記載のサーバにおいて、前記デバイスから送信する前記データを受信するよう構成された受信機をさらに含むことを特徴とするサーバ。
【請求項５１】
請求項３６乃至５０の何れか１項に記載のサーバにおいて、前記デバイスは、モバイルテレコミュニケーションデバイスであることを特徴とするサーバ。
【請求項５２】
請求項３６乃至５１の何れか１項に記載のサーバにおいて、第２のデバイスから前記ショートコードを受信するよう構成された受信機と、前記受信したショートコードと関連付けられた前記データへのアクセスを前記第２のデバイスに提供するよう構成されたプロセッサとをさらに含むことを特徴とするサーバ。
【請求項５３】
請求項５２に記載のサーバにおいて、前記データへのアクセスは、前記第２のデバイスに前記データを送信するステップを含むことを特徴とするサーバ。
【請求項５４】
データを非同期送信するためのサーバにおいて、
メモリにショートコードを保存するよう構成されたプロセッサと、
前記保存したショートコードをデバイスに送信するよう構成された送信機と、
前記保存したショートコードとデータとの間の関連付けを受信するよう構成された受信機と、
前記保存したショートコードと前記データとの間の前記関連付けを格納するよう構成されたメモリと、
第２のデバイスから要求を受信するよう構成された受信機において、前記要求は前記保存したショートコードを含む、受信機と、
前記要求を前記データと関連付けるよう構成されたプロセッサと
を含むことを特徴とするサーバ。
【請求項５５】
データを送信するためのデバイスにおいて、
請求項１乃至１４の何れか１項に記載のデバイスまたは請求項３６乃至５３の何れか１項に記載のサーバによって生成された信号を格納するよう構成されたメモリと、
前記格納された信号から音声信号を生成するよう構成された音声出力と
を含むことを特徴とするデバイス。
【請求項５６】
トランザクションを認証するためのデバイスにおいて、
ユーザから認証入力を受信するよう構成された入力デバイスと、
ユーザ識別情報を格納するよう構成されたメモリと、
ユーザ識別情報および前記認証入力を可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のために前記信号を送信するよう構成された送信機と
を含むことを特徴とするデバイス。
【請求項５７】
データを送信するための方法において、
ａ）サーバからデータと関連付けられたショートコードを受信するステップと、
ｂ）前記ショートコードを可聴的に一意な形式の信号に符号化するステップと、
ｃ）可聴音声の再生成のために前記信号を送信するステップとを含み、前記ショートコードはグローバルに一意であることを特徴とする方法。
【請求項５８】
データを受信するための方法において、
ａ）マイクロホンを介して音声信号を受信するステップと、
ｂ）前記音声信号をショートコードに復号するステップと、
ｃ）前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするステップとを含み、前記ショートコードはグローバルに一意であることを特徴とする方法。
【請求項５９】
データを非同期送信するための方法において、
ａ）サーバからショートコードを受信するステップと、
ｂ）デバイス上に前記受信したショートコードを格納するステップと、
ｃ）前記受信したショートコードをデータと関連付けるステップと、
ｄ）前記受信したショートコードを第２のデバイスに送信するステップと、
ｅ）前記関連付けを前記サーバに送信するステップと
を含むことを特徴とする方法。
【請求項６０】
データを送信するための方法において、
ａ）ショートコードをデータと関連付けるステップと、
ｂ）前記ショートコードを可聴的に一意な形式の信号に符号化するステップと、
ｃ）可聴音声の再生成のためにデバイスに前記信号を送信するステップとを含み、前記ショートコードはグローバルに一意であることを特徴とする方法。
【請求項６１】
データを非同期送信するための方法において、
ａ）ショートコードを保存するステップと、
ｂ）前記保存したショートコードを第１のデバイスに送信するステップと、
ｃ）前記保存したショートコードとデータとの間の関連付けを受信するステップと、
ｄ）前記保存したショートコードと前記データとの間の前記関連付けを格納するステップと、
ｅ）第２のデバイスから要求を受信するステップにおいて、前記要求は前記保存したショートコードを含む、ステップと、
ｆ）前記要求を前記データと関連付けるステップと
を含むことを特徴とする方法。
【請求項６２】
データを送信するための方法において、
メモリに格納された信号から音声信号を生成するステップにおいて、前記格納された信号は請求項５７または請求項６０のどちらかに記載の方法によって以前に生成される、ステップ
を含むことを特徴とする方法。
【請求項６３】
トランザクションを認証するための方法において、
ａ）入力デバイスを介してユーザから認証入力を受信するステップと、
ｂ）ユーザ識別および前記認証入力を可聴的に一意な形式の音声信号に符号化するステップと、
ｃ）可聴音声の再生成のために前記音声信号を送信するステップと
を含むことを特徴とする方法。
【請求項６４】
データを通信するためのシステムにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
前記関連付けを格納するよう構成されたメモリ
を含むサーバと、
前記ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
スピーカ、および、
前記スピーカ上での可聴音声の再生成のために前記信号を送信するよう構成された送信機
を含む第１のデバイスと、
マイクロホン、
前記マイクロホンで検出された音声信号を受信するよう構成された受信機、
前記音声信号をショートコードに復号するよう構成されたデコーダ、および、
前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
を含む第２のデバイスと
を含み、
前記ショートコードはグローバルに一意であることを特徴とするシステム。
【請求項６５】
請求項６４に記載のシステムにおいて、前記サーバは、前記エンコーダを含むことを特徴とするシステム。
【請求項６６】
請求項６４に記載のシステムにおいて、前記第１のデバイスは、前記エンコーダを含むことを特徴とするシステム。
【請求項６７】
データを非同期送信するためのシステムにおいて、
サーバからショートコードの保存を要求するよう構成されたトランシーバ、
送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイス、
前記データと前記ショートコードとの間の関連付けを生成するよう構成されたプロセッサ、
前記関連付けを格納するよう構成されたメモリ、
ダイレクトインターフェース上で第２のデバイスに前記ショートコードを送信するよう構成された送信機、および、
前記関連付けを前記サーバに送信するよう構成された送信機
を含む第１のデバイスと、
ダイレクトインターフェース上で前記第１のデバイスからショートコードを受信するよう構成された受信機、および、
前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバ
を含む第２のデバイスと、
第１のデバイスからショートコードを保存するという要求を受信するよう構成された受信機、
メモリにショートコードを保存するよう構成されたプロセッサ、
前記保存したショートコードを前記第１のデバイスに送信するよう構成された送信機、
前記保存したショートコードとデータとの間の関連付けを受信するよう構成された受信機、
前記保存したショートコードと前記データとの間の前記関連付けを格納するよう構成されたメモリ、
第２のデバイスから要求を受信するよう構成された受信機において、前記要求は前記保存したショートコードを含む、受信機、および、
前記第２のデバイスからの前記要求を前記データと関連付けるよう構成されたプロセッサ
を含むサーバと
を含むことを特徴とするシステム。
【請求項６８】
請求項６７に記載のシステムにおいて、前記ダイレクトインターフェース上で前記ショートコードを送信または受信する際、前記第１および第２のデバイスの一方または両方は、前記サーバにアクセスできないことを特徴とするシステム。
【請求項６９】
請求項６７または６８に記載のシステムにおいて、前記ダイレクトインターフェースは、ダイレクト音声インターフェースであることを特徴とするシステム。
【請求項７０】
請求項６７乃至６９の何れか１項に記載のシステムにおいて、前記第１および第２のデバイスは、並置されることを特徴とするシステム。
【請求項７１】
請求項６７乃至７０の何れか１項に記載のシステムにおいて、前記第１のデバイスは、請求項１乃至１４の何れか１項に記載のデバイスを含み、前記第２のデバイスは、請求項１５乃至２８の何れか１項に記載のデバイスを含むことを特徴とするシステム。
【請求項７２】
請求項５７乃至６３の何れか１項に記載の方法を実行するよう構成されることを特徴とするコンピュータプログラム。
【請求項７３】
請求項７２に記載のコンピュータプログラムを格納するよう構成されることを特徴とするコンピュータ可読媒体。
【請求項７４】
デバイス上のコンテンツにアクセスするためのシステムにおいて、
多数のコンテンツ要素／機能性の少なくとも１つと音声信号を一致させるため、および、前記デバイス上に格納された前記少なくとも１つのコンテンツ要素／機能性へのアクセスを提供するため、無線で直接前記音声信号を受信するよう構成されたプロセッサと、
前記多数のコンテンツ要素／機能性を格納するよう構成されたメモリと
を含むことを特徴とするシステム。
【請求項７５】
請求項７４に記載のシステムにおいて、前記プロセッサは、前記音声信号をショートコードに復号するようさらに構成され、前記ショートコードを使用して前記音声信号を一致させることを特徴とするシステム。
【請求項７６】
請求項７４または７５に記載のシステムにおいて、前記多数のコンテンツ要素の前記少なくとも１つは、マルチメディアであることを特徴とするシステム。
【請求項７７】
請求項７４乃至７６の何れか１項に記載のシステムにおいて、前記コンテンツ要素は、ネットワーク接続上で定期的に受信することを特徴とするシステム。
【請求項７８】
請求項７４乃至７７の何れか１項に記載のシステムにおいて、前記アクセスは、前記デバイスの位置、時間および前記デバイスのユーザの履歴のセットから選択される１つまたは複数の制約にさらに依存することを特徴とするシステム。
【請求項７９】
請求項７４乃至７８の何れか１項に記載のシステムにおいて、前記アクセスは、多数の音声信号の受信にさらに依存することを特徴とするシステム。
【請求項８０】
バウチャを引き換えるためのシステムにおいて、
音声信号を送信するよう構成された第１のデバイスにおいて、前記音声信号はバウチャと関連付けられる、第１のデバイスと、
前記音声信号を受信するよう構成された第２のデバイスにおいて、多数の一意なバウチャの１つと前記音声信号を一致させ、前記バウチャを引き換えることができることを確認する、第２のデバイスと、
多数の一意なバウチャを格納するためのメモリにおいて、前記バウチャは一般的なバウチャである、メモリと
を含むことを特徴とするシステム。
【請求項８１】
請求項８０に記載のシステムにおいて、前記音声信号は、前記第１のデバイスのユーザに特有のユーザ識別子を含むことを特徴とするシステム。
【請求項８２】
請求項８０または８１に記載のシステムにおいて、前記第１のデバイスは、第３のデバイスから前記音声信号を受信することを特徴とするシステム。
【請求項８３】
請求項８２に記載のシステムにおいて、前記第１のデバイスは、前記無線インターフェース上で直接第３のデバイスから前記音声信号を受信することを特徴とするシステム。
【請求項８４】
請求項８０乃至８３の何れか１項に記載のシステムにおいて、前記第２のデバイスは、前記音声信号をショートコードに復号するようさらに構成され、前記ショートコードを使用して前記音声信号を一致させることを特徴とするシステム。
【請求項８５】
請求項８０乃至８４の何れか１項に記載のシステムにおいて、前記メモリは、前記第２のデバイスに位置することを特徴とするシステム。
【請求項８６】
請求項８０乃至８５の何れか１項に記載のシステムにおいて、前記第１のデバイスおよび／または第の２のデバイスは、前記バウチャの引き換えを確認する前に、１つまたは複数の制約に対して前記バウチャをチェックするようさらに構成され、前記１つまたは複数の制約は、前記第１のデバイスの位置、時間および引き換えられたバウチャの数のセットから選択されることを特徴とするシステム。
【請求項８７】
送金するためのシステムにおいて、
モバイルデバイスから特定の金銭的価値に対する識別子に対する要求を受信し、前記モバイルデバイスに前記要求された識別子を返信し、前記識別子の有効性を確認するという要求を受信し、受信側のデバイスの口座への前記送金を実施するよう構成された信頼できる第三者と、
受信側のデバイスから識別子の有効性を確認するという要求を受信し、前記第１の信頼できる第三者と通信して前記識別子の有効性を確認し、有効性を確認した時点で、前記受信側のデバイスの口座への前記送金を実施し、前記受信側のデバイスに有効性確認応答を返信するよう構成された第２の信頼できる第三者と、
前記第１の信頼できる第三者からの特定の金銭的価値に対する識別子を要求し、前記識別子を前記モバイルデバイス上に格納し、前記識別子を音声として受信側のデバイスに非同期送信するよう構成されたモバイルデバイスと、
音声形式で前記識別子を受信し、前記第２の信頼できる第三者に前記識別子を送信するよう構成された受信側のデバイスと
を含むことを特徴とするシステム。
【請求項８８】
請求項８７に記載のシステムにおいて、前記特定の金銭的価値は、時間、位置、ベンダー、目的およびベンダーのタイプのセットから選択される１つまたは複数の制約範囲内で利用可能でも、再利用可能でもあることを特徴とするシステム。
【請求項８９】
請求項８７または８８に記載のシステムにおいて、前記第１の信頼できる関係者および前記第２の信頼できる関係者は、並置されることを特徴とするシステム。
【請求項９０】
モバイルデバイス上にユーザインターフェースを提供して、第２のデバイスへのデータアイテムの送信を管理するための方法において、
ａ）モバイルデバイス上のディスプレイ上にユーザに関連する多数のデータアイテムを表示するステップと、
ｂ）前記データアイテムの少なくとも１つを選択するユーザ入力を前記モバイルデバイス上で受信するステップと、
ｃ）前記少なくとも１つの選択されたデータアイテムを前記第２のデバイスに送信するための多数の通信オプションを前記モバイルデバイス上に表示するステップにおいて、前記通信オプションの少なくとも１つは、前記第２のデバイス上のマイクロホンによる受信のため、前記モバイルデバイスのスピーカから音声として前記データアイテムを送信するステップを含む、ステップと、
ｄ）前記通信オプションの少なくとも１つを選択するユーザ入力を受信するステップと、
ｅ）前記少なくとも１つの選択された通信オプションを使用して、前記少なくとも１つの選択されたデータアイテムを前記他のデバイスに送信するステップと
を含むことを特徴とする方法。
【請求項９１】
データを通信するためのシステムにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
前記関連付けを格納するよう構成されたメモリ
を含むサーバと、
前記ショートコードを一意な形式の信号に符号化するよう構成されたエンコーダと、
スピーカ、および、
前記スピーカ上での不可聴音声の再生成のために前記信号を送信するよう構成された送信機
を含む第１のデバイスと、
マイクロホン、
前記マイクロホンで検出された音声信号を受信するよう構成された受信機、
前記音声信号をショートコードに復号するよう構成されたデコーダ、および、
前記ショートコードを使用して、サーバで前記ショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
を含む第２のデバイスと
を含み、
前記ショートコードはグローバルに一意であることを特徴とするシステム。
【請求項９２】
請求項９１に記載のシステムにおいて、前記サーバは、前記エンコーダを含むことを特徴とするシステム。
【請求項９３】
請求項９１に記載のシステムにおいて、前記第１のデバイスは、前記エンコーダを含むことを特徴とするシステム。
【請求項９４】
データを送信するためのシステムにおいて、
データを第１の音声信号に符号化するよう構成されたエンコーダ、および、
前記第１の音声信号を可聴音声で再生成するよう構成されたスピーカ
を含む第１のデバイスと、
第２の音声信号を可聴音声で再生成するよう構成されたスピーカ、
第３の音声信号を受信するよう構成されたマイクロホン、
前記第２の音声信号を取り除くために前記第３の音声信号を処理するよう構成された信号プロセッサ、および、
前記処理された第３の音声信号をデータに復号するよう構成されたデコーダ
を含む第２のデバイスと
を含むことを特徴とするシステム。
【請求項９５】
デバイス上のコンテンツにアクセスするためのコンピュータ実装方法において、
ａ）無線で直接音声信号を受信するステップと、
ｂ）多数のコンテンツ要素／機能性の少なくとも１つと前記音声信号を一致させるステップと、
ｃ）前記デバイス上に格納された前記少なくとも１つのコンテンツ要素／機能性へのアクセスを提供するステップと
を含むことを特徴とする方法。
【請求項９６】
バウチャを引き換えるための方法において、
ａ）音声信号を送信する第１のデバイスにおいて、前記音声信号はバウチャと関連付けられる、第１のデバイスと、
ｂ）前記音声信号を受信する第２のデバイスと、
ｃ）多数の一意なバウチャの１つと前記音声信号を一致させ、前記バウチャを引き換えることができることを確認する、前記第２のデバイスと
を含み、
前記バウチャは一般的なバウチャであることを特徴とする方法。
【請求項９７】
送金するための方法において、
ａ）第１の信頼できる第三者からの特定の金銭的価値に対する識別子を要求するモバイルデバイスと、
ｂ）前記モバイルデバイスから特定の金銭的価値に対する識別子に対する前記要求を受信する前記第１の信頼できる第三者と、
ｃ）前記モバイルデバイスに前記識別子を返信する前記第１の信頼できる第三者と、
ｄ）前記識別子を前記モバイルデバイスで格納する前記モバイルデバイスと、
ｅ）前記識別子を音声として受信側のデバイスに非同期送信する前記モバイルデバイスと、
ｆ）音声形式で前記識別子を受信する前記受信側のデバイスと、
ｇ）第２の信頼できる第三者に前記識別子を送信する前記受信側のデバイスと、
ｈ）前記受信側のデバイスから識別子の有効性を確認するという要求を受信する前記第２の信頼できる第三者と、
ｉ）前記第１の信頼できる第三者と通信して前記識別子の有効性を確認する前記第２の信頼できる第三者と、
ｊ）前記第２の信頼できる第三者から前記識別子の有効性を確認するという要求を受信する前記信頼できる第三者と、
ｋ）前記受信側のデバイスの口座への前記送金を実施する前記第１の信頼できる第三者と、
ｌ）前記識別子の有効性を確認すると、前記受信側のデバイスの口座への前記送金を実施する前記第２の信頼できる第三者と、
ｍ）前記送金を実施した時点で、前記受信側のデバイスに有効性確認応答を返信する前記第２の信頼できる第三者と
を含むことを特徴とする方法。
【請求項９８】
データを通信するための方法において、
ａ）グローバルに一意なショートコードをデータと関連付けるサーバと、
ｂ）前記関連付けを格納する前記サーバと、
ｃ）前記ショートコードを一意な形式の信号に符号化するエンコーダと、
ｄ）スピーカ上での不可聴音声の再生成のために前記信号を送信する第１のデバイスと、
ｅ）マイクロホンで検出された音声信号を受信する第２のデバイスと、
ｆ）前記音声信号をショートコードに復号するデコーダと、
ｇ）前記ショートコードを使用して、前記サーバで前記ショートコードと関連付けられたデータにアクセスするトランシーバと
を含むことを特徴とする方法。
【請求項９９】
データを送信するための方法において、
ａ）データを第１の音声信号に符号化する第１のデバイスと、
ｂ）前記第１の音声信号を可聴音声で再生成する前記第１のデバイスと、
ｃ）第２の音声信号を可聴音声で再生成する第２のデバイスと、
ｄ）第３の音声信号を受信する前記第２のデバイスと、
ｅ）前記第２の音声信号を取り除くために前記第３の音声信号を処理する前記第２のデバイスと、
ｆ）前記処理された第３の音声信号をデータに復号する前記第２のデバイスと
を含むことを特徴とする方法。
【請求項１００】
請求項９５乃至９９の何れか１項に記載の方法を実行するよう構成されることを特徴とするコンピュータプログラム。
【請求項１０１】
請求項１００に記載のコンピュータプログラムを格納するよう構成されることを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ通信の分野である。しかし、具体的には、本発明は、限定的にではなく、モバイルデバイスとのデータ通信のやり取りに関する。
【背景技術】
【０００２】
データを物理的環境に組み込むための多くの既存の方法があり、短縮ＵＲＬまたはテキストコード、ＱＲコード、バーコードおよびＲＦＩＤコードの非動的な視覚的表示を含む。
【０００３】
ポスターや他の活字メディアは、一般には、既に、ｂｉｔ．ｌｙなどのＵＲＬ短縮サービスからのＵＲＬおよび／またはショートコードのテキスト形式を含む。これらの活字コードを使用するには、活字コードをウェブブラウザに入力しなければならない。これらのテキスト形式は、ＵＲＬを保持するため、ペンもしくは鉛筆または優れた記憶力を必要とする。これは、記憶が難しい英数字の文字列を使用するｂｉｔ．ｌｙなどの現行のＵＲＬ短縮サービスにおいて特に問題となり得る。記憶しやすいコードを使用する代替のショートコーディングサービスはあるが、利用可能な記憶しやすいコードは限られる可能性があることが理解されよう。
【０００４】
ＱＲコードは、比較的多量のデータ（１Ｋ）をピクトグラフで表すための方法である。コードは、マーカーがどのタイプの符号化を含むかを示すヘッダと、ペイロードとを含む。コードは、完全なＵＲＬまたは他のデータペイロード、例えば、小さな画像を符号化できるほど十分大きい。ＱＲコードの主な欠点は、それらは視覚的に比較的大きいこと、コードを認識できるようにするためにコードをカメラの間近に示す必要があること、低光量またはカメラが移動している場合に復号ステップが失敗する可能性があること、および、コードは人間が読み取れるものではないことを含む。人間にとっては、２つの異なるコードが区別できるものであることは視覚的に分からない。
【０００５】
一般的な印刷コードの中では、バーコードは、定着したコード化メカニズムである。コードの意味論は、国際規格によって定義される。異なるウェブリソース（例えば、ＣｕｅＣａｔ）にコードをマッピングするオンラインサービスがある。しかし、バーコードは、ＱＲコードの不利な点の多くを共有する。
【０００６】
ＲＦＩＤ（無線自動識別）タグは、人が携帯することも、物体に取り付けることもできる、物理的デバイスにコードを組み込む方法である。ＲＦＩＤを読取端末に近づけると、コードを受動的に読み取ることができる。この受動的なまたは半受動的なコード読み取りは、ユーザの挙動に対して許容性がある（例えば、カードと読取機との一般的な近接関係がトランザクションを容易にするのに十分である）ため、状況によっては極めて魅力的である（例えば、オイスターカード）。しかし、ユーザがＲＦＩＤタグを作成するための簡単なツールはなく、消費者では通常入手できないハードウェアが必要とされる。
【０００７】
また、オンラインデバイス間には、多くのデータ転送技術がある。例えば、Ｅメール、Ｔｗｉｔｔｅｒなどのインターネットサービスを使用することができる。これらのサービスのいくつかは、ユーザが受信者の識別子を知っている必要がある。その上、これらのインターネットサービスは、データ転送の発生を確認するため、両者のデバイスがある時点でオンライン状態である必要がある。したがって、これらのサービスを非同期的に使用する能力はない。例えば、Ｅメールまたは他の任意のウェブサービスでは、オフライン状態の場合、着手した時点で、将来的にデータ転送が完了するという保証はない。すなわち、Ｅメールはキューに登録されるが、一度も送信されないことも、デバイスの盗難にあうこともあり得る。
【０００８】
モバイルデバイス間でのピアツーピア転送の場合、最も広く普及されている技術は、Ｂｌｕｅｔｏｏｔｈである。これは、２つのデバイス間の高帯域幅チャネルである。しかし、有用性の問題があり、それに従って、名目上は多くのデバイス上で利用可能であるにもかかわらず、ユーザに広く敬遠されている。例えば、データ転送を可能にするための異なるプロトコルを有する異なるデバイスでの２つのデバイスの対形成の同期化は成り行き次第である。
【０００９】
また、本質的にはＲＦＩＤタグと読取機の技術を一緒に組み合わせた近距離無線通信（ＮＦＣ）の規格も増えている。この技術は、Ｂｌｕｅｔｏｏｔｈの競合相手である。１つの利点は、アクティブデバイスが静的なＲＦＩＤタグを模倣できるようになることである（例えば、携帯電話がオイスターカードを「模倣」できる）。これは、デバイスが、多くの支払およびセキュリティアクセスシステムを含むすべての既存のＲＦＩＤ読取システムと相互作用できるようになることを意味する。ＮＦＣのプロトタイプは存在するが、この技術は、ユーザが新しいハンドセットやデバイスを手に入れる必要がある。現在のところ、この技術を備えた消費者デバイスは未だ少ししか販売されていない。ＮＦＣが大きな市場シェアを占めるに至るには、３〜５年かかる可能性がある。
【００１０】
本発明の目的は、先行技術の不利な点を克服するデータを通信するためのシステムを提供するか、または、少なくとも役に立つ代替手段を提供することである。
【発明の概要】
【００１１】
本発明の第１の態様によれば、データを送信するためのデバイスにおいて、
サーバからデータと関連付けられたショートコードを受信するよう構成された受信機と、
ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のために信号を送信するよう構成された送信機とを含み、ショートコードはグローバルに一意なものである、デバイスを提供する。
【００１２】
可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。一部の信号は、ショートコードの何れも符号化しない場合があり、信号の可聴音声の再生成の美的または独特の性質を改良するためだけのデータを含み得る。それに加えて、一部の信号は、冗長性を符号化することができる。ショートコードは、アプリケーションヘッダを含み得る。ショートコードは、データのインデックスであり得る。デバイスは、モバイルテレコミュニケーションデバイス用のコントローラであり得る。
【００１３】
受信機は、モバイルテレコミュニケーションネットワーク上でショートコードを受信するよう構成することができる。
【００１４】
ショートコードは、既定の固定長のものであり得る。ショートコードは、３２〜１０２４ビットであり得る。信号は、音楽記述言語形式であり得る。信号は、ＭＩＤＩ形式であり得る。信号は、冗長符号化を含み得る。信号は、冗長性に対してリードソロモン符号を使用することができる。
【００１５】
データは、ＵＲＬであり得る。
【００１６】
デバイスは、送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイスと、データをサーバに送信するよう構成されたトランシーバとをさらに含み得る。
【００１７】
本発明のさらなる態様によれば、データを受信するためのデバイスにおいて、
マイクロホンで検出された音声信号を受信するよう構成された受信機と、
音声信号をショートコードに復号するよう構成されたデコーダと、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバとを含み、ショートコードはグローバルに一意なものである、デバイスを提供する。
【００１８】
音声信号は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。ショートコードは、アプリケーションヘッダを含み得る。デバイスは、アプリケーションヘッダを読み取り、アプリケーションヘッダに応じてショートコードの処理を決定するよう構成されたプロセッサをさらに含み得る。
【００１９】
ショートコードは、データのインデックスであり得る。
【００２０】
デバイスは、モバイルテレコミュニケーションデバイス用のコントローラであり得る。
【００２１】
トランシーバは、モバイルテレコミュニケーションネットワーク上でデータにアクセスするよう構成することができる。
【００２２】
ショートコードは、既定の固定長のものであり得る。ショートコードは、３２〜１０２４ビットであり得る。
【００２３】
デコーダは、ピッチ追跡を使用して音声信号の復号を補助することができる。
【００２４】
データは、ＵＲＬであり得る。データにアクセスするステップは、データをデバイスに回収するステップを含み得る。音声信号は、第１の態様のデバイスから受信することができる。デバイスは、音声信号を受信した際にショートコードおよび／または音声スペクトルを表示するよう構成されたディスプレイをさらに含み得る。
【００２５】
本発明のさらなる態様によれば、データを非同期送信するためのデバイスにおいて、
サーバからショートコードを受信するよう構成された受信機と、
受信したショートコードを格納するよう構成されたメモリと、
受信したショートコードをデータと関連付けるよう構成されたプロセッサと、
受信したショートコードを第２のデバイスに送信するよう構成された送信機と、
関連付けをサーバに送信するよう構成された送信機と
を含む、デバイスを提供する。
【００２６】
デバイスは、受信したショートコードを送信する際、サーバに接続できない可能性がある。
【００２７】
受信したショートコードは、ダイレクトインターフェース上で第２のデバイスに送信することができる。
【００２８】
ダイレクトインターフェースは、音声インターフェースであり得る。
【００２９】
デバイスと第２のデバイスは、並置することができる。
【００３０】
デバイスは、関連付けをサーバに送信する前に、ショートコードを受信し、次いで、送信することができる。
【００３１】
デバイスは、送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイスをさらに含み得る。
【００３２】
本発明のさらなる態様によれば、データを送信するためのサーバにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサと、
関連付けを格納するよう構成されたメモリと、
ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のためにデバイスに信号を送信するよう構成された送信機とを含み、
ショートコードはグローバルに一意なものである、サーバを提供する。
【００３３】
可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。
【００３４】
ショートコードは、アプリケーションヘッダを含み得る。
【００３５】
ショートコードは、データのインデックスであり得る。
【００３６】
送信機は、モバイルテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。
【００３７】
送信機は、モバイルテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。
【００３８】
信号は、着信音としてＳＭＳチャネル上で送信することができる。
【００３９】
ショートコードは、既定の固定長のものであり得る。ショートコードの長さは、３２〜１０２４ビットであり得る。
【００４０】
信号は、音楽記述言語形式であり得る。
【００４１】
信号は、ＭＩＤＩ形式であり得る。
【００４２】
信号は、冗長符号化を含み得る。
【００４３】
信号は、冗長性に対してリードソロモン符号を使用することができる。
【００４４】
データは、ＵＲＬであり得る。
【００４５】
サーバは、デバイスから送信するデータを受信するよう構成された受信機をさらに含み得る。
【００４６】
デバイスは、モバイルテレコミュニケーションデバイスであり得る。
【００４７】
サーバは、第２のデバイスからショートコードを受信するよう構成された受信機と、受信したショートコードと関連付けられたデータへのアクセスを第２のデバイスに提供するよう構成されたプロセッサとをさらに含み得る。
【００４８】
データへのアクセスは、第２のデバイスにデータを送信するステップを含み得る。
【００４９】
本発明のさらなる態様によれば、データを非同期送信するためのサーバにおいて、
メモリにショートコードを保存するよう構成されたプロセッサと、
保存したショートコードをデバイスに送信するよう構成された送信機と、
保存したショートコードとデータとの関連付けを受信するよう構成された受信機と、
保存したショートコードとデータとの関連付けを格納するよう構成されたメモリと、
第２のデバイスから要求を受信するよう構成された受信機において、要求は保存したショートコードを含む、受信機と、
要求をデータと関連付けるよう構成されたプロセッサと
を含む、サーバを提供する。
【００５０】
本発明のさらなる態様によれば、データを送信するためのデバイスにおいて、
第１の態様のデバイスまたは第４の態様のサーバによって生成された信号を格納するよう構成されたメモリと、
格納された信号から音声信号を生成するよう構成された音声出力と
を含む、デバイスを提供する。
【００５１】
本発明のさらなる態様によれば、トランザクションを認証するためのデバイスにおいて、
ユーザから認証入力を受信するよう構成された入力デバイスと、
ユーザ識別情報を格納するよう構成されたメモリと、
ユーザ識別情報および認証入力を可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
可聴音声の再生成のために信号を送信するよう構成された送信機と
を含む、デバイスを提供する。
【００５２】
エンコーダは、デバイス位置およびデバイス識別子のセットからの１つまたは複数を信号に符号化するようさらに構成することができる。デバイス識別子は、ＩＭＥＩ（国際移動体装置識別番号）であり得る。
【００５３】
本発明のさらなる態様によれば、トランザクションを認証するためのデバイスにおいて、
マイクロホンから、上記の態様で主張されるように、第２のデバイスによって生成された信号を受信するよう構成された受信機と、
信号からユーザ識別情報および認証データを復号し、ユーザ識別情報および認証入力に基づいて第２のデバイスを認証するよう構成されたプロセッサと
を含む、デバイスを提供する。
【００５４】
信号は、デバイス位置およびデバイス識別子のセットからの１つまたは複数を用いてさらに符号化することができる。デバイス識別子は、ＩＭＥＩであり得る。
【００５５】
プロセッサは、第２のデバイスの履歴およびユーザ識別情報のユーザがデバイスのユーザのソーシャルネットワーク内にいるかどうかのセットからの１つまたは複数を参照しても、第２のデバイスを認証することができる。
【００５６】
本発明のさらなる態様によれば、データを送信するための方法において、
ａ）サーバからデータと関連付けられたショートコードを受信するステップと、
ｂ）ショートコードを可聴的に一意な形式の信号に符号化するステップと、
ｃ）可聴音声の再生成のために信号を送信するステップとを含み、ショートコードはグローバルに一意なものである、方法を提供する。
【００５７】
本発明のさらなる態様によれば、データを送信するための方法において、
ａ）ショートコードをデータと関連付けるステップと、
ｂ）ショートコードを可聴的に一意な形式の信号に符号化するステップと、
ｃ）可聴音声の再生成のためにデバイスに信号を送信するステップとを含み、ショートコードはグローバルに一意なものである、方法を提供する。
【００５８】
本発明のさらなる態様によれば、データを送信するための方法において、
メモリに格納された信号から音声信号を生成するステップにおいて、格納された信号は２つの前態様の何れかの方法によって以前に生成される、ステップ
を含む、方法を提供する。
【００５９】
本発明のさらなる態様によれば、データを受信するための方法において、
ａ）マイクロホンを介して音声信号を受信するステップと、
ｂ）音声信号をショートコードに復号するステップと、
ｃ）ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするステップとを含み、ショートコードはグローバルに一意なものである、方法を提供する。
【００６０】
本発明のさらなる態様によれば、データを非同期送信するための方法において、
ａ）サーバからショートコードを受信するステップと、
ｂ）デバイス上に受信したショートコードを格納するステップと、
ｃ）受信したショートコードをデータと関連付けるステップと、
ｄ）受信したショートコードを第２のデバイスに送信するステップと、
ｅ）関連付けをサーバに送信するステップと
を含む、方法を提供する。
【００６１】
本発明のさらなる態様によれば、データを非同期送信するための方法において、
ａ）ショートコードを保存するステップと、
ｂ）保存したショートコードを第１のデバイスに送信するステップと、
ｃ）保存したショートコードとデータとの関連付けを受信するステップと、
ｄ）保存したショートコードとデータとの関連付けを格納するステップと、
ｅ）第２のデバイスから要求を受信するステップにおいて、要求は保存したショートコードを含む、ステップと、
ｆ）要求をデータと関連付けるステップと
を含む、方法を提供する。
【００６２】
本発明のさらなる態様によれば、トランザクションを認証するための方法において、
ａ）入力デバイスを介してユーザから認証入力を受信するステップと、
ｂ）ユーザ識別および認証入力を可聴的に一意な形式の音声信号に符号化するステップと、
ｃ）可聴音声の再生成のために音声信号を送信するステップと
を含む、方法を提供する。
【００６３】
本発明のさらなる態様によれば、データを通信するためのシステムにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
関連付けを格納するよう構成されたメモリ
を含むサーバと、
ショートコードを可聴的に一意な形式の信号に符号化するよう構成されたエンコーダと、
スピーカ、および、
スピーカ上での可聴音声の再生成のために信号を送信するよう構成された送信機
を含む第１のデバイスと、
マイクロホン、
マイクロホンで検出された音声信号を受信するよう構成された受信機、
音声信号をショートコードに復号するよう構成されたデコーダ、および、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
を含む第２のデバイスと
を含み、
ショートコードはグローバルに一意なものである、システムを提供する。
【００６４】
サーバは、エンコーダを含み得る。あるいは、第１のデバイスは、エンコーダを含み得る。
【００６５】
本発明のさらなる態様によれば、データを非同期送信するためのシステムにおいて、
サーバからショートコードの保存を要求するよう構成されたトランシーバ、
送信するデータをユーザが決定することができるよう構成されたユーザ入力デバイス、
データとショートコードとの関連付けを生成するよう構成されたプロセッサ、
関連付けを格納するよう構成されたメモリ、
ダイレクトインターフェース上で第２のデバイスにショートコードを送信するよう構成された送信機、および、
関連付けをサーバに送信するよう構成された送信機
を含む第１のデバイスと、
ダイレクトインターフェース上で第１のデバイスからショートコードを受信するよう構成された受信機、および、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバ
を含む第２のデバイスと、
第１のデバイスからショートコードを保存するという要求を受信するよう構成された受信機、
メモリにショートコードを保存するよう構成されたプロセッサ、
保存したショートコードを第１のデバイスに送信するよう構成された送信機、
保存したショートコードとデータとの関連付けを受信するよう構成された受信機、
保存したショートコードとデータとの関連付けを格納するよう構成されたメモリ、
第２のデバイスから要求を受信するよう構成された受信機において、要求は保存したショートコードを含む、受信機、および、
第２のデバイスからの要求をデータと関連付けるよう構成されたプロセッサ
を含むサーバと
を含む、システムを提供する。
【００６６】
ダイレクトインターフェース上でショートコードを送信または受信する際、第１および第２のデバイスの一方または両方は、サーバにアクセスできない可能性がある。
【００６７】
ダイレクトインターフェースは、ダイレクト音声インターフェースであり得る。
【００６８】
第１および第２のデバイスは、並置することができる。
【００６９】
本発明のさらなる態様によれば、デバイス上のコンテンツにアクセスするためのシステムにおいて、
多数のコンテンツ要素／機能性の少なくとも１つと音声信号を一致させるため、および、デバイス上に格納存された少なくとも１つのコンテンツ要素／機能性へのアクセスを提供するため、無線で直接音声信号を受信するよう構成されたプロセッサと、
多数のコンテンツ要素／機能性を格納するよう構成されたメモリと
を含む、システムを提供する。
【００７０】
プロセッサは、音声信号をショートコードに復号するようさらに構成することができ、音声信号は、ショートコードを使用して、コンテンツ要素／機能性と一致させる。
【００７１】
多数のコンテンツ要素の少なくとも１つは、マルチメディアであり得る。
【００７２】
コンテンツ要素は、ネットワーク接続上で定期的に受信することができる。
【００７３】
アクセスは、デバイスの位置、時間およびデバイスのユーザの履歴のセットから選択される１つまたは複数の制約にさらに依存し得る。
【００７４】
アクセスは、多数の音声信号の受信にさらに依存し得る。
【００７５】
本発明のさらなる態様によれば、バウチャを引き換えるためのシステムにおいて、
音声信号を送信するよう構成された第１のデバイスにおいて、音声信号はバウチャと関連付けられる、第１のデバイスと、
音声信号を受信するよう構成された第２のデバイスにおいて、複数の一意なバウチャの１つと音声信号を一致させ、バウチャを引き換えることができることを確認する、第２のデバイスと、
多数の一意なバウチャを格納するためのメモリにおいて、バウチャは一般的なバウチャである、メモリと
を含む、システムを提供する。
【００７６】
音声信号は、第１のデバイスのユーザに特有のユーザ識別子を含み得る。
【００７７】
第１のデバイスは、第３のデバイスから音声信号を受信することができる。
【００７８】
第１のデバイスは、無線インターフェース上で直接第３のデバイスから音声信号を受信することができる。
【００７９】
第２のデバイスは、音声信号をショートコードに復号するようさらに構成することができ、ショートコードを使用して音声信号を一致させる。
【００８０】
メモリは、第２のデバイス側に位置し得る。
【００８１】
第１のデバイスおよび／または第の２のデバイスは、バウチャの引き換えを確認する前に、１つまたは複数の制約に対してバウチャをチェックするようさらに構成することができ、１つまたは複数の制約は、第１のデバイスの位置、時間および引き換えられたバウチャの数のセットから選択される。
【００８２】
本発明のさらなる態様によれば、送金するためのシステムにおいて、
モバイルデバイスから特定の金銭的価値に対する識別子に対する要求を受信し、モバイルデバイスに識別子を返信し、識別子の有効性を確認するという要求を受信し、受信側のデバイスの口座への送金を実施する、信頼できる第三者サーバと、
受信側のデバイスから識別子の有効性を確認するという要求を受信し、第１の信頼できる第三者と通信して識別子の有効性を確認し、有効性を確認した時点で、受信側のデバイスの口座への送金を実施し、受信側のデバイスに有効性確認応答を返信する、第２の信頼できる第三者サーバと、
第１の信頼できる第三者サーバからの特定の金銭的価値に対する識別子を要求するモバイルデバイスにおいて、識別子は、デバイス上に格納され、音声として受信側のデバイスに非同期送信される、モバイルデバイスと、
音声形式で識別子を受信し、第２の信頼できる第三者サーバに識別子を送信する、受信側のデバイスと
を含む、システムを提供する。
【００８３】
特定の金銭的価値は、時間、位置、ベンダー、目的およびベンダーのタイプのセットから選択される１つまたは複数の制約範囲内で利用可能でも、再利用可能でもあり得る。
【００８４】
第１の信頼できる関係者サーバおよび第２の信頼できる関係者サーバは、並置も、同じサーバであることもあり得る。
【００８５】
本発明のさらなる態様によれば、モバイルデバイス上にユーザインターフェースを提供して、第２のデバイスへのデータアイテムの送信を管理するための方法において、
ａ）モバイルデバイス上のディスプレイ上にユーザに関連する多数のデータアイテムを表示するステップと、
ｂ）データアイテムの少なくとも１つを選択するユーザ入力をモバイルデバイス上で受信するステップと、
ｃ）少なくとも１つの選択されたデータアイテムを第２のデバイスに送信するための多数の通信オプションをモバイルデバイス上に表示するステップにおいて、通信オプションの少なくとも１つは、第２のデバイス上のマイクロホンによる受信のため、モバイルデバイスのスピーカから音声としてデータアイテムを送信するステップを含む、ステップと、
ｄ）通信オプションの少なくとも１つを選択するユーザ入力を受信するステップと、
ｅ）少なくとも１つの選択された通信オプションを使用して、少なくとも１つの選択されたデータアイテムを他のデバイスに送信するステップと
を含む、方法を提供する。
【００８６】
本発明のさらなる態様によれば、データを通信するためのシステムにおいて、
ショートコードをデータと関連付けるよう構成されたプロセッサ、および、
関連付けを格納するよう構成されたメモリ
を含むサーバと、
ショートコードを一意な形式の信号に符号化するよう構成されたエンコーダと、
スピーカ、および、
スピーカ上での不可聴音声の再生成のために信号を送信するよう構成された送信機
を含む第１のデバイスと、
マイクロホン、
マイクロホンで検出された音声信号を受信するよう構成された受信機、
音声信号をショートコードに復号するよう構成されたデコーダ、および、
ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスするよう構成されたトランシーバと
を含む第２のデバイスと
を含み、
ショートコードはグローバルに一意なものである、システムを提供する。
【００８７】
サーバは、エンコーダを含む。あるいは、第１のデバイスは、エンコーダを含む。
【００８８】
本発明のさらなる態様によれば、データを送信するためのシステムにおいて、
データを第１の音声信号に符号化するよう構成されたエンコーダ、および、
第１の音声信号を可聴音声で再生成するよう構成されたスピーカ
を含む第１のデバイスと、
第２の音声信号を可聴音声で再生成するよう構成されたスピーカ、
第３の音声信号を受信するよう構成されたマイクロホン、
第２の音声信号を取り除くために第３の音声信号を処理するよう構成された信号プロセッサ、および、
処理された第３の音声信号をデータに復号するよう構成されたデコーダ
を含む第２のデバイスと
を含む、システムを提供する。
【００８９】
本発明のさらなる態様によれば、上記の態様の何れかの方法を実行するよう構成されたコンピュータプログラムを提供する。
【００９０】
本発明のさらなる態様によれば、上記の態様のコンピュータプログラムを格納するよう構成されたコンピュータ可読媒体を提供する。
【００９１】
本発明のさらなる態様は、特許請求の範囲内で説明する。
【図面の簡単な説明】
【００９２】
ここで、添付の図面を参照して、単なる例示として、本発明の実施形態について説明する。
【００９３】
【図１】図１は、本発明の実施形態による２つのデバイスとサーバを示すブロック図を示す。
【図２】図２は、本発明の実施形態による３つの方法を示すフロー図を示す。
【図３】図３は、本発明の実施形態によるプロトコルスタックのブロック図を示す。
【図４】図４は、本発明の実施形態によるＵＲＬ共有を示すブロック図を示す。
【図５】図５は、本発明の実施形態によるさらなるデバイスとさらなるサーバを示すブロック図を示す。
【図６】図６は、本発明の実施形態による２つの方法を示すフロー図を示す。
【図７】図７は、本発明の実施形態による非同期ＵＲＬ共有を示すブロック図を示す。
【図８】図８は、本発明の実施形態によるさらなるデバイスを示すブロック図を示す。
【図９】図９は、本発明の実施形態によるさらなる方法を示すフロー図を示す。
【図１０】図１０は、本発明の実施形態による、音声を使用したデバイス上のコンテンツのロック解除を示すブロック図を示す。
【図１１】図１１は、本発明の実施形態による、音声を使用したバウチャの引き換えを示すブロック図を示す。
【図１２】図１２は、本発明の実施形態による、音声を使用して送金するための第１のシステムを示すブロック図を示す。
【図１３】図１３は、本発明の実施形態による、音声を使用して送金するための第２のシステムを示すブロック図を示す。
【図１４】図１４ａ、１４ｂ、１４ｃは、本発明の実施形態による、ユーザインターフェースを示すモバイルデバイス上のスクリーンショットを示す。
【図１５】図１５は、本発明の実施形態による、音声を使用してデバイス間のデータ送信を不明瞭化するためのシステムを示すブロック図を示す。
【発明を実施するための形態】
【００９４】
本発明は、データを通信するためのデバイス、サーバ、方法およびシステムを提供する。
【００９５】
発明者は、スピーカとマイクロホンを使用して、並置されたデバイス（音声送信を探知できるほど近くに位置するデバイス）間で、音声形式でデータを通信できることを決定した。
【００９６】
発明者は、データが通信されている際に個人がそれを決定できるように、音声が人間に聞こえるものであることが望ましいことをさらに決定した。例えば、一個人がデバイスから別の個人のデバイスにデータを送信している場合に、両者が、データが送信されていることを確信していることが望ましい場合がある。
【００９７】
発明者は、可聴音声送信が音声に一意なものであれば望ましいことをさらに決定した。すなわち、個人は、あるセットのデータの可聴信号を別のセットのデータの可聴信号と合理的に区別することができる。
【００９８】
また、発明者は、上記の仕様によるデータ通信が長時間の送信をもたらすことも決定した。したがって、発明者は、データと関連付けられた参照コードまたはショートコードの使用、および、データに代わる参照コードの後続の送信を考案した。
【００９９】
それに応じて、本発明の一態様は、ショートコードとデータとの関連付け、可聴的に一意な形式の信号へのショートコードの符号化、および、信号の可聴音声の再生成を含み得る。信号は、検出してショートコードに復号することができ、データは、ショートコードとの関連付けを使用してアクセスすることができる。
【０１００】
ここで、図１〜２を参照して、上記の態様による本発明の実施形態について説明する。
【０１０１】
受信機１０１と、エンコーダ１０２と、送信機１０３とを備え得る第１のデバイス１００が示されている。デバイス１００は、モバイルテレコミュニケーションデバイス内のコントローラであり得る。受信機１０１は、サーバ１０４からデータと関連付けられたショートコードを受信するよう構成することができる。受信機１０１は、モバイルテレコミュニケーションネットワーク上でサーバ１０４からショートコードを受信することができる。あるいは、デバイス１００およびサーバ１０４は、同じデバイス内のコントローラであり得る。
【０１０２】
データは、ＵＲＬ、Ｅメールアドレスおよび／もしくは電話番号および／もしくは連絡者名などの連絡先、文書、口座情報、バウチャ、金融トークンなどのトークン、または、他の任意のタイプのデータであり得る。
【０１０３】
エンコーダ１０２は、ショートコードを可聴的に一意な形式の信号に符号化するよう構成することができる。可聴的に一意な形式は、少なくとも何らかの鳥の鳴き声および／または音楽を含み得る。音楽は、西洋の楽音の平均律を利用することも、微分音を使用することもできる。可聴的に一意な形式は、信号の可聴音声の再生成の美的または独特の性質を改良するためだけの音声を含み得、ショートコードとは関連しない。好ましい実施形態では、エンコーダ１０２は、ショートコードを信号に変換し、その結果、ショートコードデータ自体の少なくとも一部は、鳥の鳴き声および／または音楽形式に構造化される。それに加えて、信号は、信号の音声に対する一意性を改良するためおよび／または信号の可聴音声の再生成における心地良い音を改良するため、ショートコードから導出されない他の要素を含み得る。
【０１０４】
ショートコードは、グローバルに一意なものであり得る。すなわち、各ショートコードは、データとの関連付けを１つのみ有することができる。したがって、サーバ１０４の位置をショートコード内に組み込む必要はない。したがって、ショートコードの長さを増加する必要はない。
【０１０５】
ショートコードは、アプリケーションヘッダを含み得る。ヘッダは、サーバ１０４でまたはデバイス１００で追加することができる。ヘッダは、好ましくは、サーバ１０４を使用することなく、ショートコード内で検出可能である。
【０１０６】
好ましくは、ショートコードは、固定長のものである。あるいは、符号化プロセスは、信号内のショートコードの長さを含む。
【０１０７】
送信機１０３は、可聴音声の再生成のために信号を送信するよう構成することができる。好ましくは、送信機１０３は、可聴音声の再生成のために信号をスピーカに送信することができるか、またはその代替として、送信機１０３は、後の可聴音声の再生成のための通信プロトコル上で信号を伝達することができる。
【０１０８】
代替の実施形態では、第１のデバイス１００は、ショートコードを格納するよう構成されたメモリも備え得る。この実施形態では、デバイス１００は、後にこのショートコードを回収して、可聴音声の再生成のために符号化することができる。
【０１０９】
一実施形態では、第１のデバイス１００は、どのデータをショートコードと関連付けるかをユーザが決定することができるよう構成されたユーザ入力デバイスも備え得る。そして、第１のデバイス１００は、この関連付けをサーバ１０４に通信するためのトランシーバも含み得る。
【０１１０】
また、第２のデバイス１０５も示されている。第２のデバイス１０５は、受信機１０６と、デコーダ１０７と、トランシーバ１０８とを備え得る。受信機１０６は、マイクロホンから音声信号を受信するよう構成される。一実施形態では、音声信号は、第１のデバイス１００によって送信されるものである。あるいは、音声信号は、事前にメモリ上に音声信号を格納するテレビ、コンピュータまたはリレーなどの別のデバイス内のスピーカから送信することができる。デコーダ１０７は、音声信号をショートコードに復号するよう構成される。トランシーバ１０８は、サーバ１０４と通信して、ショートコードを使用することによってショートコードと関連付けられたデータにアクセスするよう構成される。代替の実施形態では、第２のデバイス１０５およびサーバ１０４は、さらなるデバイス内に存在し得、音声信号は、第３のデバイスを通じて伝達することができる。
【０１１１】
一実施形態では、データにアクセスするステップは、第２のデバイス１０５にデータを回収するステップを伴う。
【０１１２】
一実施形態では、第２のデバイス１０５は、受信したショートコードまたは音声スペクトルなどの音声信号の表現を表示するよう構成された視覚ディスプレイをさらに備え得る。
【０１１３】
また、サーバ１０４も示されている。サーバ１０４は、プロセッサ１０９と、メモリ１１０と、エンコーダ１１１と、送信機１１２とを備え得る。プロセッサ１０９は、ショートコードをデータと関連付けるよう構成することができる。メモリ１１０は、関連付けを格納するよう構成することができる。エンコーダ１１１は、ショートコードを可聴的に一意な形式の信号に符号化するよう構成することができる。送信機１１２は、可聴音声の再生成のために第１のデバイス１００に信号を送信するよう構成することができる。一実施形態では、サーバがエンコーダ１１１を備える場合は、第１のデバイス１００は、エンコーダ１０２を必要としない。
【０１１４】
一実施形態では、送信機１１２は、モバイルネットワークなどのテレコミュニケーションネットワーク上で信号を送信するよう構成することができる。信号は、例えば、着信音として、ＳＭＳチャネルまたはＭＭＳチャネル上で送信することができる。信号は、ＵＳＳＤ（非構造付加サービスデータ）として送信することができる。
【０１１５】
サーバ１０４は、要求側のデバイスから音声信号を受信するための受信機と、音声信号をショートコードに復号するよう構成されたデコーダと、ショートコードを使用してデータにアクセスするよう構成されたプロセッサとをさらに備え得る。データにアクセスするステップは、要求側のデバイスにデータを送信するステップを含み得る。
【０１１６】
ここで、本発明の実施形態による方法について説明する。
【０１１７】
一方法２００では、ステップ２０１において、データと関連付けられたショートコードをサーバから受信する。ステップ２０２では、ショートコードを可聴的に一意な形式の信号に符号化する。ステップ２０３では、可聴音声の再生成のために信号を送信する。ショートコードは、データとの複数の関連付けを有さないという点において、グローバルに一意なものである。この方法は、モバイルデバイスなどの単一のデバイス上で実行することができる。
【０１１８】
さらなる方法２０４では、ステップ２０５において、マイクロホンを介して音声信号を受信する。ステップ２０６では、音声信号をショートコードに復号する。ステップ２０７では、ショートコードを使用して、サーバ側でショートコードと関連付けられたデータにアクセスする。この方法は、モバイルデバイスなどの単一のデバイス上で実行することができる。
【０１１９】
さらに、さらなる方法２０８では、ステップ２０９において、ショートコードをデータと関連付ける。ステップ２１０では、ショートコードを可聴的に一意な形式の信号に符号化する。ステップ２１１では、可聴音声の再生成のためにデバイスに信号を送信する。この方法は、モバイルテレコミュニケーションネットワークとインターフェースを取るサーバなどのサーバ上で実行することができる。
【０１２０】
当業者であれば、方法のすべてまたは少なくとも一部を１つまたは複数のコンピュータプログラム内で実施できることが理解されよう。例えば、モバイルテレコミュニケーションデバイスのための方法２００、２０４は、ｉＰｈｏｎｅアプリケーション内、Ａｎｄｒｏｉｄアプリケーション内、Ｓｙｍｂｉａｎ内または他の任意のプログラミング言語内で、コンピュータプログラムコードとして作成することができる。サーバのための方法２０８は、Ｐｙｔｈｏｎ／Ｄｊａｎｇｏ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｒｕｂｙ  ｏｎ  ＲＡＩＬＳまたは他の任意のシステムなどの任意のコンピュータプログラミング言語、システムまたはフレームワークで作成することができる。
【０１２１】
ここで、図３および４を参照して、本発明の実施形態について説明する。本発明のこの実施形態は、Ｃｈｉｒｐと呼ばれる。
【０１２２】
Ｃｈｉｒｐは、少量のデータを符号化する音声を使用するピアツーピアおよびオンライン共有をサポートするプロトコルおよびアプリケーションセットを含む。この実施形態では、ピアツーピアは、物理的に並置するデバイス、通常、携帯電話／モバイルデバイスを意味し、オンラインは、ソーシャルネットワークまたは標準のウェブサービスを通じたものを意味し、少量のデータは、およそ３２〜１０２４ビットを意味し、音声は、音楽などの耳に心地良い可聴音を意味する。
【０１２３】
代替の実施形態では、音声は不可聴である。現モバイルデバイス内のスピーカは、ほぼすべての人間の聞こえる範囲を上回る最大２０ｋＨｚまでの音声を送信することができる。いくつかの現モバイルデバイス内のマイクロホンは、最大２２ｋＨｚまでの音声を受信することができる。１８ｋＨｚを上回る音声の範囲は、ほとんどの成人には不可聴である。したがって、音声は、大部分のモバイルデバイスまたは専門スピーカによって大部分は不可聴周波数で送信することができ、大部分のモバイルデバイスによって不可聴周波数で受信することができる。可聴音声は、ユーザがデータ送信を可聴音声で確認でき、可聴音声は、商品知名度や目新しさの価値をユーザに確立するという点において有利であり得、あるデータ送信は、送信されているものをユーザが部分的に検証できるように認識可能な可聴音声を有し得る。不可聴音声は、音声が心地良いものでなくともよく、したがって、より大きなデータ圧縮率を使用できる可能性があるという点において有利であり得る。
【０１２４】
典型的な使用例では、２つのデバイスは互いに近くに位置し、ある人物が短いデータを別の人物に「Ｃｈｉｒｐ」する。送信側のデバイスは音声を生成し、受信側のデバイスは音声を受信して復号する。この音声は、２人のユーザには可聴であり、その結果、ユーザはデータ交換が行われたことを知ることができる。転送されるデータは短い文字列であり、その文字列は、アプリケーション特有のコードもしくはウェブサービスによって生成されたショートコードの何れかであるか、または、生成された何らかの別の形式のコードである。
【０１２５】
この特定の音声のポイントツーポイント転送は、多くの異なる大規模な相互作用に組み込むことができる。具体的には、データ転送は音声で実施されるため、音声送信が可能ないかなるデバイスも、Ｃｈｉｒｐを再生することができる。さらに、音声記録が可能ないかなるデバイスも、後のプレイバックのためにＣｈｉｒｐを記録することができる。したがって、いかなるウェブページもＣｈｉｒｐを再生することができ、マイクロホンへのアクセスを有するＦｌａｓｈまたはＪａｖａアプレットなどのウェブページ上のいかなるアプレットもＣｈｉｒｐを受信することができる。Ｃｈｉｒｐは、例えば、ラジオまたはテレビのネットワークなどの任意の通信ネットワークまたはシステム上で伝達することができ、次いで、同通信ネットワークまたはシステムは、Ｃｈｉｒｐを可聴音声で再生成することができる。
【０１２６】
基本プロトコル
プロトコルスタック
どのようにデータが転送されるかについて説明するプロトコルには３つの部分がある。
意味コード化−アプリケーション特有の意味へのショートコードの符号化３００（Ｅｓ）および復号３０１（Ｄｓ）。
データコード化−音楽記述形式へのショートコードの符号化３０２（Ｅｄ）および復号３０３（Ｄｄ）。
転送コード化−音波３０６への音楽記述の符号化３０４（Ｅｔ）および復号３０５（Ｄｔ）。
【０１２７】
図３ではプロトコルが示されている。
【０１２８】
プロセス３０７のアプリケーションは、ｃｈｉｒｐを要求し、アプリケーションデータを符号化プロセスＥｓに渡す。したがって、Ｅｓは、以下の関数と見なすことができる。
Ｅｓ：（Ａ，Ｂ）→Ｃ
Ａは文字列としてのアプリケーション識別子であり、Ｂは文字列としてのアプリケーションデータであり、Ｃは出力文字列である。関数Ｅｓは、プロセス３０７上でローカルに実施することができるか、または、好ましくは、ウェブサービスを利用することができる。文字列Ａは、通常、小さなアプリケーションサンプルから引き出されることになる（例えば、それはＵＲＬであり得、したがって、シンボルＡは「ＵＲＬ」であり得る）。文字列Ｂは、任意の長さのものである。ショートコードＣは、３２〜１０２４ビットの固定長のものである。固定長は、実装形態に応じて指定される。
【０１２９】
次いで、このショートコードは、符号化プロセスＥｄによって音楽記述言語に符号化され、Ｅｄは、以下の関数と見なすことができる。
Ｅｄ：（Ｃ）→Ｄ
Ｄは音楽記述言語（ＭＤＬ）のコードのシーケンスである。ＭＤＬの一例はＭＩＤＩであり、コードはＭＩＤＩコードのシーケンスであり得る。一実施形態では、値は、単にピッチ値であるか、またはその代替手段では、ノート（音符）のボリュームまたは動的振幅の変化、ノートの長さ、音色特性を含む他の可聴パラメータ、および、可能な場合は、そのようなパラメータの連続変調であり得る。したがって、ショートコードＣは、ＡＳＣＩＩ文字の文字列として表すことができ、「音楽コード」Ｄは、ＭＩＤＩ制御コードのシーケンスであり得る。ＭＩＤＩを使用する１つの利点は、ＭＩＤＩ再生が大部分のプラットホーム上で利用可能であるかまたは利用可能にすることができる能力であることである。あるいは、デバイス特有の着信音形式を使用することができる。
【０１３０】
音声プロセスにおける干渉に起因して復号プロセスは不明確である場合があるため（以下で論じる）、Ｅｄは、リードソロモン符号などの冗長コード化スキームを使用することができる。
【０１３１】
符号化の最終ステップは、Ｄを音波に符号化することである。事実上、これはＭＤＬプレーヤである。
Ｅｔ：（Ｄ）→Ｅ
Ｅは、ＷＡＶなどの任意の音声形式であり得る。ＭＰ３もしくはＭＰ４またはＡＩＦＦなどの代替の音声形式も使用できることが理解されよう。
【０１３２】
ＭＩＤＩを使用する場合、音声セットを選択することができる（すなわち、音声サンプルが実際に再生または合成される）。音声セットおよびピッチ範囲を選択して、再生成の容易性（例えば、低周波数は、通常小型の低出力スピーカを特徴とするモバイルデバイス上ではあまりうまく再生成されない）および復号目的のための検出の容易性などの音声送信および受信のある要件を満たす信号Ｅを生成することができる。
【０１３３】
復号プロセス３０８の第１のステップは、ＭＤＬ（例えば、ＭＩＤＩ）コードへの音の復号である。
Ｄｔ：（Ｅ’）→Ｄ’
Ｅ’は、音声が追加のノイズを有し得、復号の際にバックグラウンドノイズを含み得ることを示し、したがって、Ｄ’は、ＭＤＬ（例えば、ＭＩＤＩ）コードのシーケンスであり、Ｄとは同じではない可能性がある。このＤｔプロセスは、ピッチ検出システムも含み得る。
【０１３４】
次のステップは、このＭＩＤＩシーケンスをショートコードに復号することであり、関数Ｄｄによって実現される。符号化ステップにおいて冗長コードを使用したため、復号プロセスは、高い確率で、元のショートコードＣを返す。
Ｄｄ：（Ｄ’）→Ｃ
【０１３５】
最終プロセスは、ショートコードを復号することである。
Ｄｓ：（Ｃ）→Ａ，Ｂ
【０１３６】
ショートコードは、アプリケーションＡおよびアプリケーションデータＢを特定する。以前のＥｓと同様に、この復号は、アプリケーションでローカルに実施することができるか、または、ウェブサービスを活用して実行することができる。
【０１３７】
ＴＣＰ／ＩＰプロトコルスタックの例えを用いて説明することができる。具体的には、プロトコルの異なる層は、異なる方法で実現することができる。「一般」層（ＴＣＰ／ＩＰスタックのＩＰに相当）は、ショートコードである。ＴＣＰ／ＩＰと同様に、送信媒体への特定の符号化は、他のタイプのコード化で実現することができる。例えば、ＱＲコード。
【０１３８】
送信における信頼性は、音声復号の信頼性、すなわち、関数Ｄｔにおけるピッチ追跡と、ＥｓおよびＤｓにおける符号化の冗長との音声の２つの態様によって決定することができる。Ｄｓと関連して、周波数変調またはＰＣＭコード化などの異なる音声特性を使用することができる。選択される異なるタイプの音声特性は、例えば、非常に低価のハードウェア上または組み込まれたウェブアプレットでこのステップを実行する場合、符号化ステップ（Ｅｄ、Ｅｔ）の容易性とのバランスを保つことができる。
【０１３９】
ステップＥｓおよびＤｓは、フレキシブルであり得る。任意のアプリケーションを相互作用させるには、メッセージの意味論に同意する必要があるという意味で、半開にできるのはこの層である。通常、例えば、ＩＰには、特に、使用される「高レベルの」プロトコルについて説明する短いヘッダがある。Ｃｈｉｒｐプロトコルはポイントツーポイントプロトコルであるため（複数の聴取者がいる可能性があるが、以下を参照）、シングルヘッダバイトとしてアプリケーションを特定することができる。このバイトのある特定の値は保存され、特定のアプリケーションを示す（例えば、ＵＲＬとして０×０１またはコード化されたＩＳＢＮとして０×０２）。次いで、これにより、復号プロセスは、どのアプリケーションが残りの７バイト（６４ビットコードと仮定）または１２７バイト（１０２４ビットコードと仮定）を処理すべきかを決定することができる。
【０１４０】
一実施形態では、ショートコードの長さは、ショートコード自体に符号化される。しかし、この考えられる１つの不利な点は、復号音声（Ｄｔ）が未知のショートコードの長さ（すなわち、未知数の検出ノート）を処理する必要があることである。ショートコードの長さを符号化するかどうかの選択は、目的とする用途（正真正銘のピアツーピア方式で多量のデータを共有するため）、または、多量のデータおよびパス識別子に対してウェブサービスを使用するかどうかに依存し得る。
【０１４１】
音楽符号化
音楽符号化の一実施形態について説明する。ショートコードが６４ビットであると仮定すると、これは４ビットのチャンクに分けることができ、１６ノートの「アルファベット」が生じることになる。１６の異なる周波数をアルゴリズムで選択することができるか、または、２オクターブ（弱）のキーを使用することができ、その結果、曲のノートはキーに含まれる。１６の異なるノートは、長さが１６ノートの信号または「Ｃｈｉｒｐ」を生じさせることになる。
【０１４２】
あるいは、共通のノートパターン、アルペジオおよび進行を使用したより複雑なコード化スキームを利用することができる。これらはすべて、簡単なランダムシーケンスより多くのノートを使用することができる。
【０１４３】
復号目的のため、ノートごとにピッチが変化することを保証することが好ましい場合がある。これは、ノートの長さおよび位相の復号の不明瞭性を回避する際に役立てることができる。したがって、アルファベットをシンボル１つ分拡張することができる。
【０１４４】
ＵＲＬ共有サービス
ここで、図４を参照して、本発明の実施形態を利用するシナリオについて説明する。
【０１４５】
このシナリオでは、２人のユーザ間でＵＲＬを共有することになっている。Ａｌｉｃｅは、プロセス４００（「ＣｈｉｒｐＡｐｐ」）を実行しているスマートフォンを持っている。Ｂｏｂは、プロセス４０１（「ＣｈｉｒｐＡｐｐ」）を実行しているスマートフォンを持っている。Ａｌｉｃｅは、ＢｏｂとＵＲＬを共有することを希望している。
【０１４６】
ＣｈｉｒｐＡｐｐは、図１４ａ、１４ｂおよび１４ｃで説明されるユーザインターフェースを利用することができる。代替の実施形態では、プロセス４００および４０１は、異なるアプリケーションおよび／または音声によるデータ送信専用ではないアプリケーションに統合することができる（例えば、プロセス４００、４０１を写真アプリケーションに統合して、写真の共有を容易にすることができる）。
【０１４７】
プロセスの概要
図４を参照すると、ステップは以下の通りである。
４０２−Ａｌｉｃｅは、アプリケーション（「ＣｈｉｒｐＡｐｐ」）にテキストをペーストし、アプリケーション（「ＣｈｉｒｐＡｐｐ」）は、Ｅｓプロセスに渡される（例えば、ＵＲＬは、「ｗｗｗ．ｂｂｃ．ｃｏ．ｕｋ」であり得る）。
４０３−Ｅｓプロセスは、Ｗｅｂ  Ｓｈｏｒｔｅｎ（Ｗｓ）と呼ばれるウェブサービスに要求を出す。
４０４−Ｗｓは、ＵＲＬに対するテキスト文字列コード（「ハッシュコード」）をＥｓに返し（例えば、「６ｘｆ４２ｄ３ｅｄｆＧ」）、ハッシュコードとＵＲＬとの関係をデータベースに格納することも行う（「ストア」）。
４０５−Ｅｓは、このコードを取り、ウェブｕｒｌに対するアプリケーションコード（例えば、０×０１）をその先頭に追加し、それをＥｄに渡す。
４０６−Ｅｄは、これを音楽コードに変換する。
４０７−音楽が再生される。
４０８−プロセス４０１は、音声を受信する。
４０９−それは、音楽コードに復号され、Ｄｄに渡される。
４１０−Ｄｄは、それをショートコードに復号し、それをＤｓに渡す。
４１１−Ｄｓは、０×０１を取り除き、次いで、Ｗｅｂ  Ｌｅｎｇｔｈｅｎ（Ｗｌ）と呼ばれるウェブサービスにハッシュコードを送信する。
４１２−Ｗｌは、ストアでハッシュコードを調べ、対応する長いＵＲＬ（例えば、ｗｗｗ．ｂｂｃ．ｃｏ．ｕｋ）をＤｓに返す。
４１３−Ｄｓは、ウェブブラウザウィンドウにＵＲＬを渡し、それを開く。
【０１４８】
この実施形態では、ＥｓおよびＤｓはそれぞれ、リモート手順を利用して表を調べる。ウェブサービスは、複数のエントリポイント（この場合、ＷｓおよびＷｌ）を有するウェブサービスである。これらのサービスは両方とも、ハッシュコードをＵＲＬにマッピングする表を含むストアへのアクセスが必要である。各ハッシュコードは、一意なＵＲＬにマッピングされる。これは、生成されたショートコードがピアツーピアから送信されるためである。また、それは、Ｅｓ自体はＵＲＬから直接ショートコードを生成できないことも意味する。
【０１４９】
ハッシュコードは、既定の長さの表のインデックス値であり得る。
【０１５０】
このシステムに必要なコードの長さは、かなり短いものであり得る。ちなみに、ｂｉｔ．ｌｙのＵＲＬは、ベース６２のアルファベット（ａ〜ｚ、Ａ〜Ｚ、０〜９）からの６文字である。これは、大体３０ビットの情報を生じさせる。より大きなスペースを復号することを保証するため、少なくとも６４ビットのコードが使用される。
【０１５１】
一実施形態では、符号化は、Ａｌｉｃｅのスマートフォンのウェブブラウザに内蔵されている。一実施形態では、ＣｈｉｒｐＡｐｐは、マルチメディア表示を含む（例えば、それはＴｗｉｔｔｅｒクライアントである）。
【０１５２】
代替の実施形態では、ステップ４０２において、Ａｌｉｃｅは、複数のＵＲＬを格納することができるが、ウェブサービスから１つのコードのみを受信する場合がある。
【０１５３】
代替の実施形態では、ユーザデバイス上のアプリケーションは、ユーザの最近の１０のお気に入り、最近閲覧したＦｏｕｒＳｑｕａｒｅの場所または最近メンションしたＴｗｉｔｔｅｒの連絡先をＣｈｉｒｐとして符号化することを許可することができる。この情報は、ＣｈｉｒｐＡｐｐによってそのアプリケーションから取り入れることができる。
【０１５４】
一実施形態では、ステップ４０６において、Ｅｄは、以下の形式にショートコードを符号化することができる。
フロントドアの音＋符号化ショートコード＋Ｃｈｉｒｐの終了
フロントドアの音は、受信機が送信の開始を特定すること（ステップ４０８において）を可能にする事前に定義された音であり、符号化ショートコードは、音声に符号化されたアプリケーションコードおよびハッシュコードであり、Ｃｈｉｒｐの終了は、送信の終了を定義する事前に定義された音である。開始および終了音を定義する利点は、受信機を補助することである。また、形式は、次のＣｈｉｒｐも送信されようとしていることを示す追加のさらなるＣｈｉｒｐ音も含み得る。そのような場合は、フロントドアの音は必ずしも必要ではない。さらなるＣｈｉｒｐ音は、事前に定義された音であり得るか、または、Ｃｈｉｒｐがさらにいくつ予定されているかを示すことができる。さらなるＣｈｉｒｐ音は、Ｃｈｉｒｐの終了音前に現れる場合がある。
【０１５５】
ユーザ経験は、ＣｈｉｒｐＡｐｐを実行するステップと、データにペーストするステップとを含み得る。代替ステップは、「Ｃｈｉｒｐボタン」をアプリケーション（すなわち、ウェブブラウザ）に組み込むステップである。このボタンを押した時点で、ウェブサービスへのクエリを行うことによってショートコードが生成され、次いで、およそ１〜２秒内に音声が現れる。一実施形態では、Ｂｏｂは、音声が始まる前に、ＣｈｉｒｐＡｐｐのインスタンスを実行する必要がある。あるいは、Ｂｏｂは、後の復号のために音声を記録することができる。音声が到達し始めた時点で、ショートコードの表現が現れ、受信プロセスが機能していることを示すことができる。これは、音声レベルが機能していることを示す音声スペクトル視覚化を伴う場合がある。
【０１５６】
完全な音声が受信された時点で、ユーザにショートコードを明かすことができる。
【０１５７】
ｂｉｔ．ｌｙなどのＵＲＬ短縮サービスは、通常、ベース６２（５２の大文字および小文字と、数字）の６文字を使用する。これに対する一代替手段は、ベース３６（大文字なし）の６文字である。一部のサービスは、ショートコードが長い間利用可能であることを保証しない。したがって、ＵＲＬ短縮サービスは、およそ３６ビット（ｌｏｇ２（６２）×６＝約３５．７２またはｌｏｇ２（３６）×６＝約３１．０２）をサポートすべきである。
【０１５８】
ショートコードがベース６２の６文字列の場合、これは、３６ビットまたは５バイト（実際には４．５バイト）で表すことができる。
【０１５９】
したがって、関数Ｅｓの入力は５バイトである。何らかの冗長を提供するため、マッピングは、リードソロモン（９，５）符号などのエラー訂正コードを使用することができ、これは、９バイトが出力であり、４エラー修正バイトがあることを意味する。したがって、９バイト（７２ビット）がＭＩＤＩコードに符号化される。この実施形態は、振幅も他の変調も使用せず、簡単なピッチのみを使用して説明する。ＭＩＤＩノートの使用可能範囲の中央は、Ｃ４（ＭＩＤＩノート６０）からＧ６（ＭＩＤＩノート９１）まで、すなわち、３２の使用可能ノートである。これは、１５のノートが使用されることを意味する。一実施形態では、ノートの１つは２ビットのみを符号化し、他の３ビットは保存される。これが第１のＭＩＤＩノートとなる。これは、第１のトーンが４つの値６０、６８、７６、８４の１つのみから選択されることを意味する。後続のノートは順次コード化することができる。
【０１６０】
この特定の実施形態では、第１のノートは、１６０ミリ秒間再生される。第２のノートから第１５のノートまでは、８０ミリ秒間再生される。したがって、曲の全長は１．２８秒となる。
【０１６１】
曲を復号するため、ピッチ検出を使用することができる。音声での符号化は、周波数キーイングシステムである。ＦＦＴ実装形態と調整されたフィルタバンク実装形態の両方とも使用することができる。一実装形態は、３２の目標周波数でＧｏｅｒｔｚｅｌアルゴリズムを利用する。
【０１６２】
次いで、１６０ミリ秒長の目標トーンを探す。第１のコードの３ビットが保存されているため、その範囲内のいかなるトーンも検出することができる。この実施形態では、第１のＭＩＤＩコードの最も高い２ビットのみを取る（すなわち、（コード−６０）／８）。
【０１６３】
さらなる復号は、符号化とは反対に進行する。１５のＭＩＤＩコードが９バイトのデータに変換され、リードソロモン符号を通じて５バイトのシーケンスに復号される。これは、長さ６のベース６２の文字列に変換することができる。長さ７の文字列が作成された場合は、これはエラーとなり、エラー訂正コードが未検出であったことを意味する。
【０１６４】
リードソロモン符号は、抹消を訂正することができる。したがって、フィルタバンクが何れの時間ステップでもピークを検出しないか、または、ノイズのためピークが不明瞭である場合は、関連バイトを抹消としてマーク付けすることができ、それらを訂正することができる。
【０１６５】
発明者は、ユーザのデバイスがサーバにアクセスできない場合に、デバイスを用いてユーザとのデータの送信のやり取りを可能にすることが望ましいことも決定した。
【０１６６】
それに応じて、本発明のさらなる一態様は、サーバからショートコードを受信するステップと、第１のデバイス上にショートコードを格納するステップと、ショートコードをデータと関連付けるステップと、ショートコードを第２のデバイスに送信するステップと、次いで、データとショートコードとの関連付けをサーバに送信するステップとを含み得る。
【０１６７】
ショートコードとのデータの非同期関連付けは、何れのデバイスも「オンライン状態」であることを必要とせずに、または、ショートコードとデータとの関連付けに関する情報を有するサーバにアクセスして、２つのデバイス間でのデータへの単なる「参照」の送信を可能にすることができる。したがって、それは、参照またはショートコードの使用によって第２のデバイスによるデータへの非同期アクセスを可能にすることができる。
【０１６８】
ここで、図５〜６を参照して、上記の態様による本発明の実施形態について説明する。
【０１６９】
デバイス５００が示されている。デバイス５００は、受信機５０１と、メモリ５０２と、プロセッサ５０３と、第１の送信機５０４と、第２の送信機５０５とを備え得る。
【０１７０】
受信機５０１は、サーバ５０６からショートコードを受信するよう構成することができる。好ましくは、サーバ５０６は、モバイルテレコミュニケーションネットワークまたはインターネットなどの通信ネットワークを介してアクセス可能なものである。代替の実施形態では、サーバ５０６およびデバイス５００は、モバイル通信デバイスなどのさらなるデバイス内に存在する。
【０１７１】
メモリ５０２は、受信したショートコードを格納するよう構成することができる。メモリ５０２は、フラッシュメモリでも、プロセッサ５０３内に統合されたメモリでもあり得る。
【０１７２】
プロセッサ５０３は、受信したショートコードをデータと関連付けるよう構成することができる。プロセッサ５０３は、ユーザ入力デバイスを介してユーザからデータを関連付けるための入力を受信することができる。入力は、データ自体であり得る。
【０１７３】
第１の送信機５０４は、第２のデバイスにショートコードを送信するよう構成することができる。第１の送信機５０４は、ダイレクトインターフェース（可聴チャネル、Ｂｌｕｅｔｏｏｔｈ、視覚的表示および検出、ＩＲ、ＮＦＣ、ワイヤレスまたはＲＦなどの両方のデバイス間の直接のインターフェース）を使用してショートコードを送信することができる。
【０１７４】
第２の送信機５０５は、ショートコードとデータとの関連付けをサーバ５０６に送信するよう構成することができる。好ましくは、第２の送信機５０５は、受信機５０１と同じ通信システムを使用する。
【０１７５】
また、サーバ５０６も示されている。サーバ５０６は、プロセッサ５０７と、送信機５０８と、第１の受信機５０９と、メモリ５１０と、第２の受信機５１１とを備え得る。
【０１７６】
プロセッサ５０７は、メモリ５１０にショートコードを保存するよう構成することができる。サーバ５０６は、示されるデバイス５００などのデバイス上のユーザからの要求に応じて、ショートコードを保存することができる。ショートコードは、サーバ５０６が割り当てることができるか、またはその代替の実施形態では、要求内でユーザが指定することができる。
【０１７７】
送信機５０８は、示されるデバイス５００などのデバイスに、保存されたショートコードを送信するよう構成することができる。
【０１７８】
第１の受信機５０９は、保存されたショートコードとデータとの関連付けを受信するよう構成することができる。関連付けは、デバイスから受信することができる。
【０１７９】
メモリ５１０は、保存したショートコードとデータとの関連付けを格納するよう構成することができる。メモリ５１０は、サーバが継続的にオンライン状態を保つ場合は、ＲＡＭなどの揮発性メモリでも、不揮発性メモリでも、冗長のため両方でもあり得る。
【０１８０】
第２の受信機５１１は、第２のデバイスから要求を受信するよう構成することができる。要求は、ショートコードを含み得る。プロセッサ５０７は、要求をデータと関連付けるよう構成することができる。プロセッサ５０７は、ショートコードを使用して、データとの関連付けを回収することができる。プロセッサ５０７は、要求に従ってデータをさらに処理することができる。
【０１８１】
ここで、本発明の実施形態によるさらなる方法について説明する。
【０１８２】
一方法６００では、ステップ６０１において、サーバからショートコードを受信する。ステップ６０２では、デバイス上に受信したショートコードを格納する。ステップ６０３では、受信したショートコードをデータと関連付ける。ステップ６０４では、受信したショートコードを第２のデバイスに送信する。ステップ６０５では、関連付けをサーバに送信する。方法は、モバイルテレコミュニケーションデバイス上で実行することができる。
【０１８３】
別の方法６０６では、ステップ６０７において、ショートコードを保存する。ステップ６０８では、保存したショートコードを第１のデバイスに送信する。ステップ６０９では、保存したショートコードとデータとの関連付けを受信する。ステップ６１０では、保存したショートコードとデータとの関連付けを格納する。ステップ６１１では、第２のデバイスから要求を受信する。要求は、保存したショートコードを含み得る。ステップ６１２では、要求をデータと関連付ける。方法は、サーバ上で実行することができる。
【０１８４】
当業者であれば、方法のすべてまたは少なくとも一部を１つまたは複数のコンピュータプログラム内で実施できることが理解されよう。例えば、モバイルテレコミュニケーションデバイスのための方法６００は、ｉＰｈｏｎｅアプリケーション内、Ａｎｄｒｏｉｄアプリケーション内、Ｓｙｍｂｉａｎ内または他の任意のプログラミング言語内で、コンピュータプログラムコードとして作成することができる。サーバのための方法６０６は、Ｐｙｔｈｏｎ／Ｄｊａｎｇｏ、ＰＨＰ、Ｐｙｔｈｏｎ、Ｒｕｂｙ  ｏｎ  ＲＡＩＬＳまたは他の任意のシステムなどの任意のコンピュータプログラミング言語、システムまたはフレームワークで作成することができる。
【０１８５】
非同期ＵＲＬ共有サービス
ここで、特に図７を参照して、本発明の実施形態について説明する。
【０１８６】
この特定のシナリオでは、Ａｌｉｃｅは、ＢｏｂとＵＲＬを共有することを希望するが、彼らの一者または両者がオンライン状態ではない。
【０１８７】
プロセスの概要
図７を参照すると、以下のタイムラインでプロセスが示され、ウェブサーバプロセス７００、Ａｌｉｃｅのアプリケーションプロセス７０１およびＢｏｂのアプリケーションプロセス７０２の３つのプロセスが示されている。時間は、左から右へ進行する。
【０１８８】
７０３−Ａｌｉｃｅのデバイス上のプロセス７０１（「ＣｈｉｒｐＡｐｐ」）がオンライン状態の際、関数Ｃａｃｈｅ  Ｐｒｅ−ｃａｃｈｅ（Ｃｐ）は、ハッシュコードのセットを保存するように、Ｗｅｂ  Ｒｅｓｅｒｖｅと呼ばれるウェブサービス７００に要求を出す。
【０１８９】
７０４−これらのコードは、ストアに格納され、未だＵＲＬにはマッピングされていない。
【０１９０】
７０５−Ｗｒは、コードをＣｐに返し、Ｃｐは、今後の使用のためにローカルにそれを格納する。
【０１９１】
７０６−ここで、ＡｌｉｃｅがＵＲＬのＣｈｉｒｐを試みる際、Ａｌｉｃｅのデバイスはオフライン状態である。しかし、プレキャッシュされたハッシュコードの１つを使用することができる。したがって、符号化プロセスＥｓは、これらのプレキャッシュされたコードの１つを使用して、ショートコード、音楽コードを生成し、音声を生成することができる。
【０１９２】
７０７−Ｃｈｉｒｐが送信される。
【０１９３】
７０８−プロセス７０２（「ＣｈｉｒｐＡｐｐ」）を実行しているＢｏｂのデバイスはＣｈｉｒｐを受信するが、Ｂｏｂのデバイスもオフライン状態である。Ｂｏｂのデバイスは、段階Ｄｔ、Ｄｄを超えてＣｈｉｒｐを復号することはできない。たとえオンライン状態であったとしても、この時点でウェブサービスＷｌは保存されたコードの隣にブランクのＵＲＬを見つけるため、ショートコードを復号することはできないだろう。
【０１９４】
７０９−プロセス７０１がオンライン状態となると、関数Ｃａｃｈｅ  Ｕｐｄａｔｅｒ（Ｃｕ）は、ハッシュコードとＵＲＬとの新しい関係を中継する。
【０１９５】
７１０−ウェブサービスＷｅｂ  Ｕｐｄａｔｅｒ（Ｗｕ）は、この新しい関係をストアに格納する。ここで、いかなるプロセスも、ハッシュコードからＵＲＬを調べることができる。
【０１９６】
７１１−プロセス７０２がオンライン状態となると、それは、すべての非復号のショートコードのフェッチを試みる。それは、前述同様に、ハッシュコードをＷｌに渡す。
【０１９７】
７１２−Ｗｌは、ここでは非ブランクのショートコードからＵＲＬへのマッピングを調べる。
【０１９８】
７１３−ＷｌはＵＲＬをＤｓに返す。
【０１９９】
７１４−プロセス７０２はウェブブラウザを始動する。
【０２００】
好ましくは、プロセスは、ユーザアカウントを使用して、他の誰かによってＷｕが更新されることを防ぐ。それは、有料サービスであり得る。
【０２０１】
ここでは、Ｃｈｉｒｐを完全に復号できない期間（すなわち、ＡｌｉｃｅがハッシュコードとＵＲＬとの関係をウェブサービスにアップロードする前）がある。しかし、ステップ７０８では、ＡｌｉｃｅとＢｏｂは、ショートコードが送信されていることを確認することができる。一実施形態では、彼らのデバイスのそれぞれのデバイス上のユーザインターフェースは、比較のためにショートコードを表示することができ、および／または、ユーザインターフェースは、ＢｏｂがＣｈｉｒｐを「再度再生」することを可能にし、両ユーザともそれを聞き取って２つの音が同じであることを確認することができる。音が同じであれば、原理上は、首尾よくデータを調べることができる。ＣｈｉｒｐＡｐｐは、Ｃｈｉｒｐを完全に復号できる際にそれをＢｏｂに知らせることができる。Ｂｏｂがオンライン状態となって時点で、ステップ７０９の実行に対してＡｌｉｃｅが未だオンライン状態となっていないことはあり得ない。この時点で、Ｃｈｉｒｐは、「元の送信者からの更新保留」として特定され得る。したがって、Ｃｈｉｒｐは、後日復号するためにウイルスのように拡散させることができる（例えば、特定の時間にリリースされたフィルムトレーラクリップにリンクする）。
【０２０２】
この特定の実施形態では、両プロセスの機能性は、両デバイスに展開された単一のアプリケーション（ＣｈｉｒｐＡｐｐ）内に含まれる。このアプリケーションは、図３および４と関連して説明されたものと同じアプリケーションであり得る。プロセスを別々のアプリケーション内に含めることができることも理解されよう。
【０２０３】
ここで、本発明のさらなる実施形態について説明する。
【０２０４】
機能不可（Ｄｕｍｂ）リレー
機能不可リレーに対して考えられるいくつかの実装形態、すなわち、復号できないが、単に生の音声または音楽記述の記録および送信のみを行うプロセスが存在する。
【０２０５】
符号化および復号ステップは、それら自体がウェブサービスとして提供され得る。ウェブサービスは、ダウンロード可能なＣｈｉｒｐをＭＰ３として提供することも、ウェブブラウザでのＣｈｉｒｐの再生をサポートすることもできる。これは、スピーカが取り付けられていれば、ウェブブラウザは即座にＣｈｉｒｐを生成できることを意味する。
【０２０６】
それに加えて、これらのサービスは、ＭＭＳなどの他のゲートウェイを通じて触れることができる。
【０２０７】
先述の通り、Ｃｈｉｒｐ自体は、音声であるため、これらの機能をサポートする任意のタイプのデバイスによって記録および中継することができる。これは、簡素な電話（固定電話）およびスマートフォン以外の携帯電話を含む。
【０２０８】
また、Ｃｈｉｒｐは、デジタルメディアに格納することも、テープ、ビニール盤またはビデオテープなどのアナログメディアに格納することもできる。アナログメディアとデジタルメディアの両方にＣｈｉｒｐを記録できるということは、テレビなどの大型の機能不可リレー上での放送用の他のメディアにもＣｈｉｒｐを適合できることを意味する。例えば、テレビ広告は、Ｃｈｉｒｐ音声トラックを含み得る。
【０２０９】
保存コードサービス
生成された音楽コードのいくつかは、周知の曲のように聞こえる場合がある。ＥｄとＤｄが可逆機能であれば、これらの曲のバージョンをＭＩＤＩなどのＭＤＬで作成することができ、次いで、対応するショートコードを見つけて、保存することができる。これは、有料サービスであり得る。このプロセスは、テーマ曲（Ｗｉｎｄｏｗｓの開始、Ｉｎｔｅｌのジングルなど）の捕捉および特定のウェブサービスへのそれらのリダイレクトに対してうまく機能するであろう。
【０２１０】
厳密なピアツーピアモデル
１つのモデルは、スタンドアロンアプリケーションにＣｈｉｒｐを組み込むことである。次いで、ショートコードは、アプリケーション特有の意味論を有することができる。例えば、バウチャを共有したアプリケーションでは、モバイルデバイスにダウンロードされたアプリケーションに、画像としてバウチャ自体を組み込むことができる。特定のＣｈｉｒｐがデバイスで聞こえると、バウチャのロックが解除されることになるが、コードは、単にアプリケーションでバウチャをアクティブ状態にするためにある。Ｃｈｉｒｐがデバイスで聞こえた時点で、そのデバイスは、Ｃｈｉｒｐを中継できるようになる。
【０２１１】
これにより、バウチャまたはクーポンのウイルスのような共有が可能となる。それに加えて、バウチャが広まった参加者の数を符号化して、バウチャを適切に渡すことができ、また恐らく、バウチャが他の誰かに渡った回数も符号化することができよう。これを行うには、ショートコードが１つのバウチャと一致しない場合もあり得るが、コード生成ループがあり、それにより、既知のシーケンスにおいて次のショートコード、したがってＣｈｉｒｐ音声を生成することができる。したがって、受信アプリケーションは、どのショートコードかを見分けることばかりでなく、その履歴についての何かを見分けることも可能となる。これにより、ある特定の人数がそれを保有した後でのみ与えられるタイプのバウチャコードを有効にすることができる。
【０２１２】
別の概念は、新しいバンドビデオの一部またはビデオのトレーラなどの他のメディアタイプをウイルスのように共有することであろう。その結果、ユーザは、アプリケーションをダウンロードする際にメディアのランダム部分を入手することになるが、ユーザと友人は、Ｃｈｉｒｐコードを交換することによってメディアの他の部分を収集することが可能である。これにより、友人のグループは、ビデオまたは音声トラックをまとめて即座に組み立てることができるようになり、メディアの周りでの相互作用が容易になる。
【０２１３】
リモート操作の例
一例は、聴取者の近くの機器（例えば、ＣｈｉｒｐＡｐｐのウェブバージョンを実行しているＰＣ）に信号として組み込まれたＣｈｉｒｐとの会話に基づく。これにより、例えば、コールセンタ職員は、あるページへ強制的に移動させることによって、ローカルのＰＣをリモート制御できるようになる。
【０２１４】
これを実施する一方法は、ウェブページ上のＦｌａｓｈアプレットにＣｈｉｒｐ読取機を組み込むことである。Ｆｌａｓｈは、マイクロホンへのアクセスを有するため、テレビまたはスピーカフォンからの出力などのローカル環境でＣｈｉｒｐを「聞き取る」ことができる。したがって、リモートオペレータは、話している間に、Ｃｈｉｒｐを送信することができ、Ｃｈｉｒｐはウェブページ上のアプレットで聞こえるようになる。次いで、アプレットは、ページを変えること、アニメーション化することなどによって、ウェブページを操作することができる。それは、そうでなければ制限される可能性があるウェブサイトのある特定のエリアを起動するための安全なコードを運ぶことさえも考えられる。その利用可能性は、ＰＣの技術サポートにおいてであろう。
【０２１５】
信頼できるピアツーピアおよび安全なピアツーピア
これまで説明されてきたように、Ｃｈｉｒｐは、一方向のデータ転送に使用することができる。論じられるように、Ｃｈｉｒｐは、放送テレビなどの非対話的なメディア上で放送することができる。しかし、スマートフォンや他のプラットホームを用いることで、送信者は、ほぼ確実に受信者として機能できるようになる。
【０２１６】
送信者と受信者の両者とも送信も受信も可能な場合は、複数段階プロトコルを実施することができる。例えば、２つのデバイスは、識別情報（例えば、「こんにちは、私はデバイスＸです」を表し、「こんにちはＸ、私はデバイスＹです」と応答させるコードおよびＣｈｉｒｐ）を送信することによって、ハンドシェイクを行うことができる。次いで、デバイスＸは、「Ｙ、Ｃｈｉｒｐ  Ｚを送ります」というメッセージを送信することができ、「Ｘ、ＹはＣｈｉｒｐ  Ｚを受信しました」という応答で返すことができる。これにより、Ｃｈｉｒｐ転送はより信頼できるものとなる。デバイスＸは、Ｚのコピーを手に入れることができ、そのコピーに何らかの形で歪みが生じた場合は、デバイスＸは再送信することができるため、適正にデバイスＹがＣｈｉｒｐを受信したことを検出することができる。また、デバイスＸは、ある特定の時間内に何の連絡もなく、デバイスで聞こえなかったかまたは応答できなかったかの何れかであると想定した場合にも、再送信することができる。何れの場合にも、デバイスのユーザがＣｈｉｒｐを聞き取れる可能性があり、データが再送信されたかまたは再送信する必要があるかどうかを理解できる可能性があり、必要ならばデバイスのユーザは干渉できることを理解することが重要である。
【０２１７】
上記に付け加えて、公開／秘密鍵の交換を使用してＣｈｉｒｐ  Ｚを符号化することも可能である。デバイスは、簡単な識別子よりもむしろ、公開鍵ＫＰＸおよびＫＰＹを交換する。次いで、ＫＰｒＸの秘密鍵でＣｈｉｒｐを符号化して、暗号化されたＣｈｉｒｐ  Ｚ’を作成することができる。次いで、デバイスＹは、コンテンツが安全であることと、送信者が確かにＸであることの両方を知ることができる。
【０２１８】
すべてのピアツーピアシステムに対し、トランザクションの登録が可能なように、ウェブサービス上にオーディットトレールが存在し得る。具体的には、ウェブサービス上に公開鍵を格納することができる。
【０２１９】
ＣｈｉｒｐとＰｉｎ
ピアツーピアサービスの拡張の１つは、支払サービスなどの外部サービスとの相互作用を容易にすることである。支払サービスは、トークンの何らかの形式の交換を必要とし、Ｃｈｉｒｐはそのトークンであり得る。これは、少なくとも３つの異なる方法で機能することができる。
【０２２０】
第１に、Ｃｈｉｒｐ自体は、Ｃｈｉｒｐを生成するアプリケーションが、ウェブサービスからいくつかのＣｈｉｒｐコードを「購入」することができ、それらを受信者に中継できるという意味で、「貴重なもの」であり得る。したがって、Ｃｈｉｒｐアプリケーションは一種の財布として機能し、送信者がオンライン状態である必要はない。受信者はオンライン状態であってもなくともよい。Ｃｈｉｒｐが多大な量に対するものである場合は、受信者は、それが未だ使用されていないことを検証できるオンラインサービスにそれを転送することによって、即座に「それを現金化する」ことを希望する場合がある。第三者がＣｈｉｒｐを耳にした場合は、その第三者は、それを現金化する際に受信者を「打ち負かす」必要がある。それらは、これを行うため、物理的に近くなければならない。安全な転送を使用することが可能である。
【０２２１】
第２に、Ｃｈｉｒｐアプリケーションは、ウェブサービスを運営するためにＵＫ銀行口座で現在分配されているセキュリティデバイスと同様に機能することができる。アプリケーションは、通常のＶＩＳＡまたは他のクレジット／デビットカードの詳細を符号化することができ、ユーザは、通常のＰＩＮを入力することができる。ウェブサービスにタイプする８桁のコードを捉える代わりに、デバイスは、Ｃｈｉｒｐを８桁コードにすることになる。受信者は、カードネットワークでこのコードを検証することができる。
【０２２２】
図８を参照して、本発明の実施形態によるデバイス８００について説明する。
【０２２３】
示されるデバイス８００は、入力デバイス８０１と、メモリ８０２と、エンコーダ８０３と、送信機８０４とを備え得る。入力デバイス８０１は、ユーザから認証入力を受信するよう構成することができる。メモリ８０２は、ユーザ識別を格納するよう構成することができる。エンコーダ８０３は、可聴的に一意な形式の信号にユーザ識別および認証入力を符号化するよう構成することができる。送信機８０４は、可聴音声の再生成のために信号を送信するよう構成することができる。
【０２２４】
デバイス８００は、トランザクションの認証に使用することができる。好ましくは、トランザクションは、金融取引であり、ユーザ識別は、ユーザ口座情報を含むかまたはそれに関連する。あるいは、トランザクションは、物理的アクセスまたはワイヤレスネットワークへのアクセスに対してなど、ユーザを認証するためのトランザクションであり得る。
【０２２５】
また、エンコーダは、デバイス８００のＩＭＥＩなど、デバイス８００の位置またはデバイス８００用の識別子を信号に符号化することもできる。それに加えて、可聴信号を受信する受信デバイスは、ユーザ識別情報をユーザと一致させ、ユーザをユーザに対する認証の履歴記録と一致させることによって、または、ユーザを受信デバイスのユーザのソーシャルネットワークと一致させることによって、デバイス８００またはデバイス８００のユーザをさらに認証することができる。
【０２２６】
また、受信デバイスは、先の時間のデバイス８００の先の位置を使用してスプーフィングを防止するために、デバイス８００が受信デバイスの位置にもっともらしく位置し得るかどうかを計算することによって、および、先の位置と現在の位置との間の移動時間が可能かどうかを計算することによって、デバイス８００をさらに認証することもできる。
【０２２７】
図９を参照して、本発明の実施形態による方法９００について説明する。
【０２２８】
ステップ９０１では、認証入力デバイスを介してユーザから認証入力を受信する。ステップ９０２では、ユーザ識別および認証入力を可聴的に一意な形式の音声信号に符号化する。ステップ９０３では、可聴音声の再生成のために音声信号を送信する。
【０２２９】
第３に、Ｃｈｉｒｐアプリケーションは、銀行サービス間のリレーとして動作し得る。すなわち、送信者は、ワンタイムＣｈｉｒｐコードに対するオンラインサービスを依頼することになる。受信者は、これを即座に現金化しなければならないことになっており、トランザクションは、効果的に、２つのオンライン銀行サービス間の「ループを閉じる」。
【０２３０】
先述の安全なサービスと組み合わせると、Ｃｈｉｒｐを使用して他のシナリオを容易にすることができる。小型の音声放送機器が組み込まれたグリーティングカードは、金銭価値を実際に反映し得る。マイクロペイメントまたはクレジットは、店内公示システム上で広めることができる。
【０２３１】
認証
Ｃｈｉｒｐアプリケーションをデバイス上で実行することができ、そのデバイスに所有者がいるため、多要素認証（ＭＦＡ）を使用することができる。具体的には、銀行セキュリティデバイスとの類似性に従って、Ｃｈｉｒｐアプリケーションは、ユーザからのＰＩＮにアクセスできるばかりでなく、ウェブサービスからのＩＤ、ＧＰＳからのユーザの位置の履歴、デバイスのＩＭＥＩ番号にもアクセスすることができる。これらのいくつかまたはすべては、ショートコードに符号化することができる。他の複数の要素は、デバイスカメラ、加速度計および社会的履歴からのデータを含み得る。
【０２３２】
対形成
Ｃｈｉｒｐアプリケーションは、Ｃｈｉｒｐを使用して、Ｂｌｕｅｔｏｏｔｈ接続用のＰＩＮを分配することができる。アプリケーションは、必要ならば、デバイス上でＢｌｕｅｔｏｏｔｈを初期化することができる（それには、ポップアップメニューを通じたユーザ承認が必要とされる場合がある）。
【０２３３】
同様に、対形成スキームは、ＷｉＦｉまたはＲＦＩＤ用に、すなわち、対形成セキュリティの強化またはユーザ経験の円滑化に二次チャネルが役立つものの何れに対しても、初期化することができる。
【０２３４】
ゲーム
アプリケーション操作の特定の変形形態は、Ｃｈｉｒｐを使用して、マルチユーザゲームをサポートすることである。これは、戦略ゲーム、カードゲーム、アドベンチャーゲーム、取引ゲームなどの展開が遅いゲームに特に適するであろう。
【０２３５】
ハードウェア（チップ上のＣｈｉｒｐ）
物理的なインターフェースがアクセス不可能であるか、または、制御モバイルデバイスによってより安くもしくは好都合にアクセス可能な状態にすることができるかの何れかの場合は、マイクロホンを装備したハードウェアで、組み込まれたＣｈｉｒｐを使用して、デバイスを制御することができる。Ｃｈｉｒｐは、音声を介して制御メッセージを送信することができる。考えられる用途は、オーブンタイマのプログラミングまたはＰＶＲ上でのペアレンタルコントロールの設定を含む。
【０２３６】
制御メッセージは、Ｃｈｉｒｐのシーケンスとして送信することができる。オーブンまたはＰＶＲに対する動作を決定するシーケンス。
【０２３７】
Ｃｈｉｒｐ受信機は、ＵＳＢドングル上に構築することができる。ＵＳＢドングルは、音声を受信するためのマイクロホンと、音声をショートコードに変換するデコーダと、ショートコードと関連付けられたデータを入手するためにウェブサービスにアクセスするためのメカニズムとを含み得る。ＵＳＢドングルが差し込まれるコンピュータのｗｉｆｉ能力をメカニズムが利用することも、ＵＳＢドングルがｗｉｆｉトランシーバを含むこともできる（代替のトランシーバは、最終的にネットワーク接続を介したウェブサービスへの接続を容易にするＢｌｕｅｔｏｏｔｈまたは他のＲＦのように構想することができる）。
【０２３８】
ＵＲＬと有効期限
ウェブサービスを復号に使用することができるため、さまざまな特性、例えば、受信者の位置（例えば、主なペイロードを手に入れるため、受信者は送信者の位置の近くでなければならない）、時間、ソーシャルネットワーク（例えば、友達の友達のみ）、ランダムな報酬支払（例えば、宝くじ）、識別（例えば、Ｃｈｉｒｐ内で「最終受信者」を符号化し、その人物に特有のコンテンツをアクティブ状態にする）に応じて異なる復号を実行することができる。
【０２３９】
ウェブアプリケーションの制御
一実施形態では、ウェブアプリケーションは、Ｃｈｉｒｐを受信して復号し、復号したＣｈｉｒｐを使用してウェブアプリケーション内の動作を制御するように適合させることができる。代替の例では、Ｃｈｉｒｐは単なる音声であり得、ウェブアプリケーションは、音声を動作に一致させることができる。音声は、格納された音声への直接マッピング、フィンガープリント法またはショートコード用のサーバを用いたショートコードへの復号を使用して、ウェブアプリケーション内に格納されたデータと一致させることができる。
【０２４０】
ウェブアプリケーションは、Ｊａｖａアプリケーションなどのクライアント側のものでも、ウェブブラウザが音声をサーバに渡す場合はサーバ側のものでもあり得ることが理解されよう。
【０２４１】
ここで、図１０を参照して、本発明のさらなる実施形態について説明する。
【０２４２】
発明者は、モバイルデバイス上に以前に格納されたコンテンツのロック解除が有用であることを発見した。コンテンツのロックを解除するための前のシステムは、コードをダウンロードしてデバイス上に格納されたコンテンツにアクセスすることを含む。また、デバイス上の機能性のロックも解除されることも同様に望ましいであろう。
【０２４３】
コンテンツ要素は、バーチャルグッズを表し得る。したがって、音声を使用して、デバイス上のバーチャルグッズのロックを解除することができる。
【０２４４】
ここで、本発明のこの実施形態において、音声の受信と同時にモバイルデバイス１００１上のコンテンツのロックを解除するためのシステムについて説明する。
【０２４５】
本発明のこの実施形態では、コンテンツ／機能性を入手する２つの方法があり得る。
１）アプリケーションをダウンロードするかまたは入手する際に、コンテンツをダウンロードする。
２）アプリケーションによってコンテンツをデバイスにプッシュするかまたはデバイスにプルする。例えば、毎日、新聞のコンテンツをモバイルデバイスにプッシュすることができる。
【０２４６】
デバイス１００１上のアプリケーションは、コンテンツアクセスを管理することができる。例えば、アプリケーションは、ｗｉｆｉ接続への接続が可能な場合に、ネットワークトランシーバ１００２を介してコンテンツアクセスを自動化することができる（すなわち、３Ｇ上での広帯域の使用を削減するため）。アプリケーションは、プロセッサ１００３によって実行することができる。
【０２４７】
コンテンツ要素１００４は、デバイス１００１のメモリ１００５上に格納することができる。
【０２４８】
コンテンツ１００４がそのロックを解除するためのコードを含むことも、コンテンツ１００４をコードで暗号化することも、アクセシビリティコードを格納するアプリケーションによって、コンテンツ１００４へのアクセスを管理することもできる。コードは、ショートコードであり得る。
【０２４９】
コードは、デバイス１００１に特有でも、コンテンツ１００４に特有でもあり得る。
【０２５０】
コンテンツ１００４は、マルチメディア、ＵＲＬ、アプリケーション機能性（例えば、ゲームまたは新しいゲームレベルのロックを解除する）、または、新しいコードでさえもあり得る。
【０２５１】
コンテンツへのアクセスを得るため（コンテンツのロックを解除するため）、デバイス１００１は、デバイス１００１のマイクロホン１００６から音声を受信することができる。音声は、図３で説明された符号化プロセスに従って、音声内でショートコードを符号化することができ、音声自体がコードであることも、コードを入手するために音声をフィンガープリントすることもあり得る。音声が符号化される場合は、音声は、音声デコーダ１００７によってコードに復号される。
【０２５２】
コードは、デバイス１００１上に格納されたコンテンツ１００４と一致させ、コンテンツへのアクセスを提供する。コンテンツへのアクセスは、コンテンツアプリケーション１００９によってユーザインターフェース１００８を通じてユーザに提供することができる。例えば、コンテンツはＭＰ３であり得、デバイス上の音楽プレーヤ上でＭＰ３を再生することによって、アクセスが提供される場合がある。
【０２５３】
代替の実施形態では、コードに加えて、コンテンツへのアクセスの提供にさらなる制約が必要とされる。例えば、複数のコードを受信する必要がある場合も、ユーザデバイス１００１が特定の位置（例えば、搭載ＧＰＳチップによって決定されるように）になければならない場合も、それが特定の時間帯内または特定の時間の前／後になければならない場合もある。
【０２５４】
音声は、テレビもしくはラジオ上の放送またはＰＡシステム上で、別のモバイルデバイスからのピアツーピア音声送信を介して受信することができる。
【０２５５】
音声は、この明細書の他の場所で説明されるようなＣｈｉｒｐであり得る。
【０２５６】
本発明のこの実施形態の潜在的利点は、オフライン状態の間にユーザ間でコードを共有できるということである。その上、コンテンツをダウンロードする必要なく、コードがコンテンツのロックを解除するため、オフライン状態で即座に満足を得ることができる。
【０２５７】
ここで、図１１を参照して、さらに、本発明のさらなる実施形態について説明する。
【０２５８】
バウチャは、商品またはサービスと引き換えることができるトークンである。一般的なバウチャは、ユーザにもトランザクションにも特有でないバウチャである。一般的なバウチャは、現在、紙形式または電子形式である。一般的なバウチャは、紙形式のバウチャを渡すかもしくは示すことによって、または、モバイルデバイス画面などの視覚ディスプレイ上に電子バウチャを表示することによって引き換えられる。
【０２５９】
発明者は、一般的なバウチャを引き換える先行技術の代替手段を提供することが望ましいという結論を下した。
【０２６０】
ここで、バウチャが音声で引き換えられる場合の本発明の実施形態について詳細に説明する。
【０２６１】
第１のユーザデバイス１１０１が示されている。好ましくは、第１のデバイス１１０１は、スマートフォンなどのモバイルユーザデバイスである。
【０２６２】
第１のデバイス１１０１は、ネットワーク接続１１０３上でウェブサービスとしてアクセス可能であり得るデータベース１１０２からバウチャを受信することができる。バウチャは、バウチャ用の識別子として表すことができる。あるいは、第１のユーザデバイス１１０１は、第２のユーザデバイス１１０４から音声でバウチャを受信することができる。好ましくは、第２のユーザデバイス１１０４は、モバイルユーザデバイスである。その上、第２のユーザデバイス１１０４は、さらに別のユーザデバイスからバウチャを受信して、初めにデータベース１１０２からバウチャを受信した第１の発信元デバイスから現デバイス１１０１へのユーザデバイス共有の連鎖を形成した可能性がある。
【０２６３】
バウチャが音声形式で受信されない場合は、図３に示される符号化方法に従って、音声形式でバウチャを符号化することができる。その上、第１のユーザデバイス１１０１は、バウチャを音声に符号化する際に、バウチャ識別子を有する一意なユーザ識別子を含み得る。
【０２６４】
一実施形態では、符号化音声は、以下の形式で符号化することができる。
バウチャ識別子＋共有数＋発信元ＩＤ＋照会人ＩＤ
発信元ＩＤは、連鎖内でバウチャを直接共有する第１のユーザの識別子であり、照会人ＩＤは、現ユーザにバウチャを提供する最後のユーザの識別子である。代替の実施形態では、発信元から最後の照会人までの共有の連鎖内のユーザはすべて、符号化音声に追加することができる。この形式は、バウチャを共有する挙動の後の分析を可能にすることができる。
【０２６５】
音声は、第１のユーザデバイス１１０１上のスピーカ１１０５を通じて無線インターフェース上で送信することができる。
【０２６６】
商業デバイス１１０６が示されている。商業デバイス１１０６は、メモリ上に格納されたデータベース１１０７を含むことも、データベース１１０７へのアクセスを単に有することもできる。データベース１１０７およびデータベース１１０２は、同じデータベースでもよい。データベース１１０７は、多数のバウチャ１１０８を格納する。
【０２６７】
商業デバイス１１０６は、第１のユーザデバイス１１０５から送信された音声を受信することができる。音声は、商業デバイス１１０６上のマイクロホン１１０９を介して受信することができる。
【０２６８】
商業デバイス１００６は、受信した音声をデータベース１１０７内の多数のバウチャ１１０８と一致させることができる。
【０２６９】
音声は、音声フィンガープリント法を介して、データベース１１０７内に格納された音声と直接一致させることも、音声は、図３で説明されるようにショートコードを符号化し、音声を復号し、ショートコードをバウチャ１００８と一致させることもできる。
【０２７０】
一致させたバウチャに関連する情報は、バウチャの価値の検証のために商業デバイス１１０６上に表示することができる。例えば、バウチャは、第１のユーザデバイス１１０１のユーザが、５０％割引の購入品を受け取ること、または、購入品とともに無料ギフトを受け取ることを示す場合がある。
【０２７１】
バウチャの引き換えには制約がある場合がある。制約は、バウチャの送信に責任を有する第１のユーザデバイス１１０１上のアプリケーション上で施行すること、および／または、商業デバイス１１０６側で施行することができる。
【０２７２】
制約は、ユーザ１人当たりのバウチャの数の限度を含み得る。この例では、商業デバイス１１０６は、使用されたユーザ識別子およびバウチャを記録するためのデータベース１１２０を含むことも、同データベース１１２０へのアクセスを有することもできる。
【０２７３】
制約は、バウチャの引き換えを最初の１００人（例えば）に限定するため、バウチャの総数限度を含み得る。
【０２７４】
制約は、考えられるバウチャ引き換えの場所（例えば、複数の所在地があるベンダーの特定の場所）または時間の制限を含み得る。
【０２７５】
ここで、図１２を参照して、さらに、本発明のさらなる実施形態について説明する。
【０２７６】
伝統的には、紙幣、貨幣または譲渡不可能なバウチャなどの物理的トークンを使用して関係者間で送金が行われる。このプロセスの明確に不利な点は、物理的トークンは失いやすい可能性があり、取り扱いに関連するコストまたは不便性があるということである。
【０２７７】
送金するための他の方法は、クレジットカード、デビットカードおよびプリペイドカードなどの電子手段を含む。そのような方法は、かなりのインフラ要件（すなわち、特殊な読取デバイス）を有し、クレジット／デビットカードは、ユーザベースの認証プロセスも必要とする。
【０２７８】
発明者は、送金するための代替のシステムが望ましいという結論を下した。
【０２７９】
ここで、音声を使用して送金が行われる本発明の実施形態について説明する。
【０２８０】
第１のモバイルユーザデバイス１２０１が示されている。モバイルユーザデバイス１２０１は、着信音の付いたＳＭＳメッセージを受信することができる任意の携帯電話であり得る。あるいは、モバイルユーザデバイス１２０１は、音声（任意の形式、例えば、ＭＰ３、ＭＩＤＩで）を受信して格納することができるかまたはコードを受信してコードを音声に符号化することができるスマートフォンであり得る。
【０２８１】
第１のモバイルユーザデバイス１２０１は、モバイルテレコミュニケーションネットワーク１２０３上で、信頼できる第三者１２０２（銀行など）からの特定の金銭的価値に対する一意な識別子を要求することができる。
【０２８２】
信頼できる第三者１２０２は、識別子を生成して、識別子と特定の金銭的価値の両方をデータベース１２０４に格納することによって、要求を処理することができる。一代替手段では、信頼できる第三者１２０２は、第１のモバイルユーザデバイス１２０１のユーザが保有する銀行口座または他の金銭口座の借記を指示することができる。
【０２８３】
識別子は、ショートコードであり得る（図３で説明されるように）。
【０２８４】
信頼できる第三者１２０２は、識別子をＭＤＬ形式に符号化し（図３で説明されるように）、符号化識別子を第１のモバイルユーザデバイス１２０１に送信することができる。あるいは、信頼できる第三者１２０２は、第１のモバイルユーザデバイス１２０１に直接識別子を送信することができ、第１のモバイルユーザデバイス１２０１が識別子自体を符号化することができる。さらなる代替手段では、信頼できる第三者１２０２が、識別子をＭＤＬに符号化し、次いで、音声に符号化することができる。さらに、さらなる代替手段では、識別子は音声であり得る。
【０２８５】
識別子（符号化されていない、ＭＤＬに符号化された、または、音声の）は、第１のモバイルユーザデバイス１２０１上のメモリ１２０５上に格納される。例えば、識別子は、着信音として受信することができる。
【０２８６】
第１のモバイルユーザデバイス１２０１のユーザが特定の金銭的価値の使用を希望する際、第２のデバイス１２０７に対し、スピーカを通じて音声１２０６として識別子を再生することができる。識別子が音声形式でない場合は、第１のモバイルユーザデバイス１２０１は、識別子を音声形式に符号化することができる（図３で説明されるように）。第２のデバイス１２０７は、商業デバイスまたは別のユーザデバイスであり得る。
【０２８７】
第２のデバイス１２０７は、識別子の有効性を確認し、通信ネットワーク１２０９上で信頼できる第三者１２０２（または、仲介物１２０８）と連絡を取ることによって特定の金銭的価値の受信を実施し、識別子を送信することができる。第２のデバイス１２０７は、信頼できる第三者１２０２に送信する前に、受信した音声をショートコードまたは他のコードに復号することができる。一代替手段では、第２のデバイス１２０７は、信頼できる第三者１２０２を呼び出し、第１のデバイスからの音声を信頼できる第三者１２０２へ中継することによって、識別子を送信する。
【０２８８】
信頼できる第三者１２０２（または、仲介物１２０８）は、特定の金銭的価値と識別子を一致させることによって、データベース１２０４内で識別子を検証する。検証ステップは、不正行為の防止に役立てるための特定の金銭的価値の使用に対する制約を含み得、例えば、特定の金銭的価値は、地理的な位置（例えば、ＬｏｎｄｏｎまたはＵＫ）への制限も、特定のベンダーまたはベンダーファミリー（例えば、Ｓｔａｒｂｕｃｋｓ）への制限も、特定の時間への制限も、特定の目的（例えば、本の購入のみ）への制限も有し得る。
【０２８９】
代替の実施形態では、特定の金銭的価値は、制約の範囲内で再利用が可能であり、例えば、特定の金銭的価値は、１日１回または週に５回の利用が可能である。
【０２９０】
信頼できる第三者１２０２は、特定の金銭的価値の反復使用を防ぐため、識別子を使用済みとマーク付けすることができる。検証された時点で、信頼できる第三者１２０２は、第２のデバイス１２０７に関連する銀行または他の金銭口座への特定の金銭的価値の転送を実施することができる。信頼できる第三者１２０２は、識別子の有効性の検証を第２のデバイス１２０７に送信することができる。したがって、第２のデバイス１２０２または第２のデバイスのユーザは、第１のデバイス１２０１のユーザによって着手されたトランザクションの終結を促進することができる（例えば、商品もしくはサービスを提供することによって、または、会場へのアクセスを提供することによって）。
【０２９１】
その上、上記の実施形態は、ＰＫＩなどの暗号化を使用することによって変更することができ、これは、音声を使用して起こり得るハンドシェイクプロセスを伴う場合がある。しかし、特定の金銭的価値は第２のデバイス１２０７によって即座に検証されるため、これは、第１のデバイス１２０１と第２のデバイス１２０７との安全な接続に対する要件を軽減することができる。
【０２９２】
上記で説明されるものに対する代替の実施形態では、第１のデバイス１２０１をパイプとして使用し、第２のデバイス１２０７に対するトランザクションを検証することができる。これは、第１のデバイス１２０１は接続されているが、第２のデバイス１２０７は接続されていない場合に有用であり得る。
【０２９３】
図１３を参照して、そのような実施形態について説明する。
【０２９４】
第１のモバイルユーザデバイス１３０１（転送側のデバイス）が示されている。特定の金銭的価値は、信頼できる第三者１３０２から第１のデバイス１３０１によって要求される。信頼できる第三者１３０２は、特定の金銭的価値に対する識別子を第１のモバイルユーザデバイス１３０１に送信する。
【０２９５】
第１のモバイルユーザデバイス１３０１は、トランザクションに対応する音声１３０３を第２のデバイス１３０４（受信デバイス）に送信する。
【０２９６】
第２のデバイス１３０４は、信頼できる第三者１３０２と通信するためのリレーとして第１のデバイス１３０１を使用して、特定の金銭的価値を検証することができる。例えば、第２のデバイス１３０４は、信頼できる第三者１３０２まで中継される暗号化メッセージ（認証要求１３０５）を送信することができ、信頼できる第三者１３０２は、第２のデバイス１３０３によって検証され得る暗号化された応答（認証価値１３０６）で応答することができる。あるいは、第２のデバイス１３０３は、信頼できる第三者１３０２からの秘密の応答を要求することができる（すなわち、第２のデバイス１３０３と信頼できる第三者１３０２のみが知っている質問に対する回答。不正行為を阻止するため、質問は、一回限りの質問であり得る）。信頼できる第三者１３０２および第２のデバイス１３０３は、認証プロセスを管理するための認証エンジン１３０７および１３０８を含み得る。
【０２９７】
特定の金銭的価値は、通常、現金、カードまたはマイクロペイメントで行われる支払いを含み得る。
【０２９８】
本発明のこの実施形態は、仮想の送金に使用することができる。
【０２９９】
図１４ａ、１４ｂおよび１４ｃを参照して、本発明のさらなる実施形態について説明する。
【０３００】
Ｃｈｉｒｐユーザインターフェース（ＵＩ）は、３つの機能（聴取、Ｃｈｉｒｐおよび格納）専用の３つの画面（Ｓ１〜３）から構成される。
【０３０１】
この実施形態で言及されるＣｈｉｒｐは、図３を参照して説明されるショートコードを符号化する音声の送信である。しかし、代替の実施形態では、Ｃｈｉｒｐは、図１０、１１、１２、１３または１５で使用できるような任意のデータを符号化する音声も含み得る。
【０３０２】
初期ロード後、音声データ受信に対して適正なモードにアプリケーションをすぐに切り替えられるように、アプリケーションはデフォルトのＳ１（聴取）になる。
【０３０３】
（Ｓ１）聴取：Ｓ１は、マイクロホンを起動し、デバイスを「検出」モードに切り替え、Ｃｈｉｒｐ信号を聴取し始める。Ｓ１は、リアルタイムでの波形表示によって、マイクロホンを介して検出可能なすべての音事象（人間の耳で容易に検出可能または明らかでなくなる音まで。その音も含む）をリアルタイムで表示する。
【０３０４】
ユーザは、ａ）マイクロホンがアクティブ状態であること、および、ｂ）素早い目視検査によって音声検出レベル（マイクロホンの感度）が適切に設定されていることを容易に識別することができる。
【０３０５】
また、ユーザは、ローカル環境がｃ）Ｃｈｉｒｐの送信または受信前に、比較的騒々しいかまたは静かであるか、そして、それに応じて音声データの転送の達成が難しいかまたは簡単かを決定することができる。直前の数秒間に示されるピークおよび周囲の音エネルギーの測定値は、波形を動的に着色し直す（悪状態の場合は赤色、許容値は黄色、最適状態の場合は緑色）ことによって表示される。
【０３０６】
これらの３つの変数を表示するため、ユーザが複数の視覚様式を利用できるようにすることが予想される。
【０３０７】
音視覚化エリアの真下では、英数字またはアイコンを含む一連の「タンブラ」は、検出順に検出されるように、無線音声入力から捉えた復号データを表示する。
【０３０８】
また、Ｓ１は、Ｓ２へのリンクも含む（Ｃｈｉｒｐボタンを見ること）。
【０３０９】
（Ｓ２）Ｃｈｉｒｐ：Ｓ２は、格納されたデータかまたは最近捕捉されたデータを共有するための一連の異なるデータプロトコルを集約する。画面の上部では、ユーザは、受信された最後の英数字のショートコードを見ることができ、その真下では、視覚、可聴およびテキスト分配方法を含む（しかし、これらに限定されない）、そのショートコードを共有するための多くの利用可能な方法を見ることができる。
【０３１０】
可聴方法内では、Ｃｈｉｒｐとマーク付けされたボタンを押すと、コードは、他のＣｈｉｒｐクライアントアプリケーション用に音で再表現される。
【０３１１】
視覚方法内では、ショートコードは、ＥＰＯＳシステムを使用して、考えられる引き換え用のＱＲコードとして動的に表現および表示される（外部のスキャンまたは画像取込デバイスを介して）。また、他のオープンソース、または、Ａｚｔｅｃコード、セマコード、Ｍｉｃｒｏｓｏｆｔ高密度コードを含む２Ｄ視覚的コードのファミリーの専用メンバーもサポートされ得る。
【０３１２】
テキスト方法内では、Ｔｗｉｔｔｅｒ、ＥメールまたはＳＭＳクライアントアプリケーションを開いて、これらのアプリケーションのコンテンツフィールドに現在アクティブ状態のショートコードを事前に追加するための手段が提供される。これらのオペレーションのすべては、シングルクリックで達成される。さらに便利なことに、ＴｗｉｔｔｅｒまたはＥメール共有の場合、受信者の利益のためのクリック可能なリンクは、適正なプロトコルタイプとサーバアドレスを単にコードの先頭に追加することによって、Ｃｈｉｒｐアプリケーションによって構築され、通常、これは「ｈｔｔｐ：／／ｃｈｉｒｐ．ｉｏ／」であり得るが、好ましくは、（例えば）Ｃｈｉｒｐにリンクされたファイルは、ｆｔｐまたは他のファイル共有プロトコルを使用したアプリケーションを介して取り扱われる場合がある。
【０３１３】
呼び出されるべきすべての外部のアプリケーションまたは機能は、その機能に適切なアイコンでマーク付けすることができる。
【０３１４】
最後に、上記で与えられた手段の一方または他方によるＣｈｉｒｐの検出またはＣｈｉｒｐアプリケーションへのデータの受信によって、ローカルファイルが起動されるかまたはアクセス可能になる場合、アイコンは、感嘆符を表示することができ、そのコンテンツは、コンテンツのタイトル（例えば、「Ｌｕｃｋｙ  Ｃｈｉｒｐ」）を表示するアイコンまたはボタンをクリックすることによって利用可能にすることができ、そのコンテンツ（音声、映像、グラフィックス、ＨＴＭＬ、対話式ゲームデータまたは機能）は、適切なクライアントアプリケーションを使用することによって開くことも、ホストアプリケーション自体で取り扱うこともできる。
【０３１５】
Ｓ２は、単一ボタンを介して各共有方法が呼び出し可能な状態で、そして、各サブアプリケーションが知的に自動的に補われた状態で、単一画面にすべての共通の共有機能を集約する。
【０３１６】
あるいは、クリップボード（コピーバッファ）にショートコード文字列を事前に追加することもでき、ユーザは、「デスクトップ」またはＯＳレベルに切り替えることによってＣｈｉｒｐアプリケーションを離れ、ユーザの好ましいメール、Ｔｗｉｔｔｅｒ、２Ｄコード作成アプリケーションへナビゲートし、そこから変換するかまたは送信するかの何れか（または両方）のためショートコードにペーストすることができる。Ｓ２に示される方法は、共有方法を制限せずに必要なフローを予想することによって、明らかに高速であり、より効率的な共有を可能にするため、好ましい。
【０３１７】
さらなる代替手段は、動的に作成されたプロキシリターンＥメールもしくはＳＭＳアドレスの使用および／または適切で永久的な「真の」送信トレイへのＣＣ送信によって、さらに迅速なロード時間のための軽量の「アウトバウンドのみ」のアプリケーションを使用することである。このようにして（プロキシアカウントを使用して）、希望する場合は、好都合なことに、Ｃｈｉｒｐを他の通信とは別々に保持することができる。
【０３１８】
また、Ｓ２は、サーバ側での後の分析のためおよびＳ３上での表示のため、行われた共有の数および共有モードを記録することができる。
【０３１９】
Ｓ３（格納）インターフェースは、ローカルでまたはサーバを介しての何れかでＣｈｉｒｐと一致した一意な識別子のリポジトリとして機能する。
【０３２０】
第１のセクションは、最近の「受信トレイ」活動（最近受信したｎ個のＣｈｉｒｐ（ｎはユーザが定義する）を示すためのトグル機能の付いた、逆の順序での最近受信した５つのＣｈｉｒｐ）を示す。
【０３２１】
Ｃｈｉｒｐは、サーバにアクセスすることによって決定することも、デバイス側の情報から決定することもできる状態と関連し得る。例えば、サーバ側のＣｈｉｒｐと関連するデータが未だアップロードされていない場合は、Ｃｈｉｒｐの状態は「未だ利用不可能」であるか、または、Ｃｈｉｒｐと関連するデータが期限切れの場合（例えば、データが期間限定のバウチャのような時間依存性である場合）は、Ｃｈｉｒｐの状態は「期限切れ」であり得、サーバ側で未だＣｈｉｒｐがアクセスされていない場合は、状態は「アクセスなし」であるか、または、Ｃｈｉｒｐがアクセス条件と関連している場合（特定の場所または特定の時間の間でなければならないなど）は、状態はその条件と関連するかもしくはＣｈｉｒｐの状態は「隠された」状態であり得、そういう場合には、Ｃｈｉｒｐは表示すらされない可能性がある。状態は、Ｃｈｉｒｐのバックグラウンドの着色によってユーザインターフェース内に示すことができる。
【０３２２】
ページは、ユーザの略歴、地理またはタスクコンテキスト別に、音声（音声表現はローカルに格納される）を介して即座に送信できるアイテムを大まかに細分化する。
【０３２３】
略歴は、Ｆａｃｅｂｏｏｋ、ＬｉｎｋｅｄＩｎ、Ｔｗｉｔｔｅｒなどのソーシャルネットワークプロフィールアドレスを含む、共有可能なマイクロ形式としてのユーザの詳細な連絡先、ホームページおよび／または仕事の詳細を含み得る。音声送信用にこれらのデータアイテムを準備するため、ユーザは、これらのサービスのそれぞれに対して、彼または彼女の一意なユーザ名を入力しなければならない場合があり、Ｃｈｉｒｐアプリケーションは、簡単な共有のために音声として符号化された完全なｈｔｔｐ：／／アドレスを返すか、または、一意なユーザ名が見つからない場合は、不明瞭性解消を要求する。
【０３２４】
地理は、地理的に位置付けされたすべてのＵＲＬを含み、例としては、地図アプリケーション上で最近検索された場所（例えば、地図検索のユーザ履歴から入手）、場所に基づくソーシャルネットワーク上の地域別「チェックイン」などが挙げられる。典型的な使用例は、提案された会合場所、お勧めの小売業者などのワンクリック共有である。
【０３２５】
コンテキストに即した格納は、１つのアプリケーションもしくはアプリケーションクラス、または、デバイスの態様に関連するアイテムを含み得、例としては、１つまたは複数のブラウザに対する「お気に入り」もしくは履歴、最近再生された音楽、最近かけた電話からの電話番号、最近受信／送信したＥメールからのＥメールアドレス、連絡先リストからの電話番号、カレンダーイベント、または、デバイス上の最新の活動に関連するデータ（例えば、ユーザが最近地図アプリケーションを閲覧し、その上で場所を特定した場合、データアイテムは地図位置であり得る）が挙げられる。
【０３２６】
送信できるアイテムは、カメラロール上に格納された画像またはデバイス上のアプリケーションのリストなどの任意のローカルに格納されたデータであり得る。代替の実施形態では、任意のウェブベースのデータも送信することができ、そのようなアイテムは、Ｆａｃｅｂｏｏｋの「いいね（ｌｉｋｅ）」またはＡｍａｚｏｎのほしい物リスト／おすすめ商品であり得る。
【０３２７】
大抵の場合、適切なファイルハンドラまたは視覚表現が存在するかどうかを決定するために解析されるようなアイテム文字列、例えば、ｔｗｉｔｔｅｒ．ｃｏｍ文字列は、Ｔｗｉｔｔｅｒクライアントが取り扱い（ユーザによって定義されるように）、適切なアイコンが与えられる。
【０３２８】
それに加えて、データアイテムは、デバイス上にローカルに格納されたゲームに関連する「トークン」（ピアツーピアで持ち込むことも、販売することも、取引することも可能なゲーム内のコンテンツ）であり得る。
【０３２９】
それに加えて、Ｓ３では、受信および送信されたユーザＣｈｉｒｐの記録を表示することができ、共有メカニズムを奨励するため、場合により、高い共有比に基づいて、格納されたコンテンツのロックを解除するポイントが、ポイントに授与され得る。
【０３３０】
ユーザは、リフレッシュを押すことによって、データセット（例えば、日替わりセール）を手動で「リフレッシュ」することができる。次いで、サーバは、このトピックに関連する新しいＣｈｉｒｐに対してクエリを行う（この場合、今日の特売品）。
【０３３１】
代替の実装形態では、アプリケーションがロードされている場合、または、リアルタイムのメッセージングプロトコルを介して、例えばＸＭＰＰ上で、新しいデータがクライアントアプリケーション上の１つまたは複数の関連セットにプッシュされる場合、データは自動リフレッシュされる。
【０３３２】
利用可能なセットのリストは、動的に形成することができる（すなわち、即座にＣｈｉｒｐ可能な情報の新しいセットは、サーバ上で定義することができ、デバイス上のアプリケーションは、サーバと連携して、ユーザにＣｈｉｒｐへのアクセスを提供することができる）。
【０３３３】
図１５を参照して、さらに、さらなる実施形態について説明する。
【０３３４】
第１のデバイスと第２のデバイスの両方の送信を聞き取るデバイスによる中間者攻撃に関して、第１のデバイスと第２のデバイスとの間の送信のセキュリティを改善するため、発明者は、両デバイスが同時に送信できることを発見した。聴取側のデバイスは、マイクロホンですべての音声を検出し、検出した音声からそれら自体の送信信号を取り除くことによって、送信側のデバイスの音声信号を検出することができる。この不明瞭化プロセスは、無計画な中間者攻撃において不利な点となり得る。
【０３３５】
また、音声信号を同時に送信する両デバイスは、美的に心地良い「デュエット」を提供することもできる。
【０３３６】
また、音声信号を同時に送信する両デバイスは、データ送信時間を削減することもできる。これは、同期的に行える場合に２つのデバイス間で暗号化鍵を共有する際に、特に有用であり得る。
【０３３７】
図１５は、第１のデバイス１５０１と第２のデバイス１５０２とを示す。２つのデバイスは、交換に着手して、デバイスの後の音声同時送信を調整することができる。交換は、音声を使用してダイレクト無線インターフェース上で起こることも、電気通信システムを通じてなど、別のチャネルを通じて事前に定義されることも調整されることもあり得る。交換は、トーンの交換を伴う。調整は、時間同期化と基準ピッチトーンとを含み得る。好ましくは、デバイスの少なくとも１つは、モバイルテレコミュニケーションデバイスである。
【０３３８】
代替の実施形態では、２つのデバイスは、リアルタイムのフィードバックモデルでデバイスの受信した送信信号を使用して、デバイスのさらなる送信を適合させることによって、それら自体の同時送信内で、それらの同時送信を調整する。
【０３３９】
聴取者に音楽のように聞こえることにより同時送信がより美的に心地良く現れ得るというような同じ音楽キーを選択することによって、送信を調整することができる。送信を調整する他の方法は、和音内で音声を再生成するデバイス（例えば、各デバイスは、３和音の１つまたは複数を送信することができる）を含み得る。
【０３４０】
第１のデバイス１５０１は、第１のデバイス１５０１内のスピーカ１５０４上で第１の音声信号１５０３を送信することができる。第２のデバイス１５０２は、第２のデバイス内のスピーカ１５０６上で第２の音声信号１５０５を同時に（または音声信号の重複をもたらすほど十分に同時に）送信することができる。
【０３４１】
音声信号１５０３、１５０５は、データを符号化することができる。データは、図３で説明されるような方法を使用して、エンコーダ１５０７によって符号化することができる。データ送信が一方向の場合、音声信号の一方の信号１５０３のみがデータを符号化することができる。あるいは、データ送信が双方向の場合、両方の音声信号がデータを符号化することができる。
【０３４２】
データ送信信号を受信するデバイス（すなわち、第１および／または第２のデバイス１５０２）は、マイクロホン１５０８を使用して音声を聞き取り、次いで、信号プロセッサ１５０９を使用して、受信した音声信号を処理し、それら自体の送信信号を取り除くことができる。処理された信号は、デコーダ１５１０によって復号し、音声信号内に格納されたいかなるデータも回収することができる。
【０３４３】
一実施形態では、ピッチ、タイミングおよび音色のジッタリングスケジュール（発振器の波形）は、デバイス間で交換して、不明瞭化プロセスに役立てることができる。スケジュール交換は、調整段階の一部であり得る。
【０３４４】
本発明の実施形態において符号化された任意の音声に関連して、音声の一部を符号化して、それらの特徴を他の特徴と可聴音声で区別することができる。例えば、データの存在を示すためにタグを開閉するなど、プロトコルが構造上の共通の特徴を含む場合、これらの特徴は、共通の音で定義することができる（例えば、ベントノート、急降下、トリル音または美的（非コード伝達）事象）。それに加えて、データを符号化して、関連するデータとのその区別可能性を補助することができる。例えば、５ポンドを表すデータは、１０ポンドを表す音声と完全に区別可能に符号化することができ、データが暗号化などの他の非共通の要素を含む場合、音声は、区別可能性を補助するために共通の要素を含み得、例えば、５ポンドのトークンを表す音声の暗号化された部分を共通の音声部分と組み合わせて、トークンが５ポンドを表すことを示すことも、ＵＲＬまたはＪＰＥＧを表す音声の符号化された部分が一意な音声部分を含み、音声がＵＲＬに関連するかまたは音声がＪＰＥＧもしくは写真に関連するかを示すこともできる。この音声部分は、受信側のデバイスで復号することも、音声のコンテンツタイプを聴取者に可聴音声で示すためだけに存在することもできる。符号化されたデータタイプを示すことと同様に、音声部分は、誰からデータが送信されたか（例えば、音声の送信機）またはデータの発信元／所有者（例えば、データを発信／所有する会社、例えば、データがバウチャであれば、バウチャを引き換える会社またはバウチャスキームオペレータ）を示すことができる。
【０３４５】
本発明は、コンピュータハードウェア上またはハードウェア自体の中で実行するソフトウェアとして実装できることが理解されよう。
【０３４６】
本発明のいくつかの実施形態の潜在的利点は、データは音声で送信され、すべてのモバイルデバイスは音声の受信および送信が可能なため、些細な変更が施すことでほとんどのモバイルデバイスでシステムを利用できることである。
【０３４７】
本発明のいくつかの実施形態のさらなるの潜在的利点は、デバイスの一方または両方がオフライン状態の際に、デバイス間でデータを通信できることである。
【０３４８】
本発明はその実施形態の説明によって示され、本発明はかなり詳細に説明されてきたが、添付の特許請求の範囲をそのような詳細に制限することまたは何らかの方法で限定することは出願人の意図ではない。追加の利点と変更形態は、当業者であれば容易に明らかであろう。したがって、そのより幅広い態様での本発明は、装置および方法を代表する具体的な詳細に限定されず、説明に役立つ実例が示され、説明される。それに応じて、そのような詳細からの逸脱は、出願人の本発明の一般概念の精神または範囲から逸脱することなく行うことができる。
【図１】
2013545333.tif 000002
【図２】
2013545333.tif 000003
【図３】
2013545333.tif 000004
【図４】
2013545333.tif 000005
【図５】
2013545333.tif 000006
【図６】
2013545333.tif 000007
【図７】
2013545333.tif 000008
【図８】
2013545333.tif 000009
【図９】
2013545333.tif 000010
【図１０】
2013545333.tif 000011
【図１１】
2013545333.tif 000012
【図１２】
2013545333.tif 000013
【図１３】
2013545333.tif 000014
【図１４ａ】
2013545333.tif 000015
【図１４ｂ】
2013545333.tif 000016
【図１４ｃ】
2013545333.tif 000017
【図１５】
2013545333.tif 000018