JP7411481B2

JP7411481B2 - 通信端末、通信方法及びプログラム

Info

Publication number: JP7411481B2
Application number: JP2020065826A
Authority: JP
Inventors: 研一池田
Original assignee: Smart Solution Technology Inc
Current assignee: Smart Solution Technology Inc
Priority date: 2020-04-01
Filing date: 2020-04-01
Publication date: 2024-01-11
Anticipated expiration: 2040-04-01
Also published as: JP2021164091A

Description

本発明は、通信端末、通信方法及びプログラムに関する。

近年、携帯端末などの通信端末を用いて個人の認証を行い、ポイント付加などの電子決済を行う技術が用いられている。しかしながら、携帯端末のネットワーク環境は状況により不安定であり、このような状況下ではポイント付加などの電子決済を行うことが困難となっていた。そこで、当該携帯端末のネットワーク環境ではなく、店舗側のネットワーク環境を用いて通信を行いポイント付加などの電子決済を行うことが考えられている。

このように、店舗側のネットワーク環境を用いて電子決済を行うために、例えば、誘導式ＲＦＩＤ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙＩｄｅｎｔｉｆｉｅｒ）を用いた近接通信により携帯端末から個人ＩＤを取得し処理を行うものが知られている。しかしながら、全ての携帯端末にＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）タグが備えられているとは限らない。そのため、このような通信端末について近接通信により認証を行うための様々な技術が提案されている。

例えば、特許文献１には、携帯端末側にて送信データとして音声を出力し、受信した音声から送信データを取得する、などといったように、音声を伝送媒体として認証を行う技術が提案されている。

国際公開第２０１２/０４６８８５号

このように、特許文献１に記載の技術のように、音声を伝送媒体として使用することで、携帯端末のネットワーク環境を使用することなく様々なサービスの提供が可能となる。例えば、店舗等に設置された端末から音声を繰り返し出力し、所定のアプリケーションをインストールしたユーザの携帯端末にて当該音声を受信することで、当該来店したユーザに対してポイントを加算するといったサービスが考えられる。しかしながら、繰り返し出力される音声（通信データ）について、出力された通信データの先頭から末尾までを受信して初めて当該通信データの解析が可能となるため、ユーザのアプリケーションの起動タイミングが出力中の音声の中盤であった場合には、当該出力中の音声の次に出力される音声の先頭を待ち、当該次に出力される音声の先頭から末尾まで受信する必要があった。すなわち、ユーザのアプリケーションの起動タイミングにより、受信した音声（通信データ）の解析時間にばらつきが生じてしまい、処理時間の短縮化という観点からすると未だ十分ではなかった。

本発明は、このような背景に基づいてなされたものであり、処理時間を短縮化することのできる通信端末、通信方法及びプログラムを提供することを目的とする。

上記目的を達成するため、本発明の第１の観点に係る通信端末は、
送信端末から繰り返し周期的に出力される音声信号を通信データとして、任意のタイミングから順次受信する受信手段と、
前記受信手段で受信した一周期分または一周期の一部分の前記通信データを、前記受信した通信データにおける前記一周期の先頭位置に基づいて、前記一周期の前記音声信号に対応する通信データの対応位置へと配置する配置手段と、を備え、
前記配置手段は、前記受信した音声信号における前記一周期分の通信データにおける前記一周期の先頭位置を特定し、前記送信端末から前記一周期分の前記音声信号の出力が開始されてから前記一周期分の前記音声信号の出力が終了するまでの期間に前記受信手段により前記音声信号の受信を開始した場合、前記受信手段により順次受信した前記通信データを、前記先頭位置が先頭となる前記一周期の通信データの対応位置へと順次配置することにより、前記周期的に出力された音声信号の前記一周期分の前記通信データを生成する、
ことを特徴とする。

上記目的を達成するため、本発明の第２の観点に係る通信方法は、
受信手段が、送信端末から繰り返し周期的に出力される音声信号を通信データとして、任意のタイミングから順次受信する受信ステップと、
配置手段が、前記受信ステップで受信した一周期分または一周期の一部分の前記通信データを、前記受信した通信データにおける前記一周期の先頭位置に基づいて、前記一周期の前記音声信号に対応する通信データの対応位置へと配置する配置ステップと、を備え、
前記配置ステップでは、前記受信した音声信号における前記一周期分の通信データにおける前記一周期の先頭位置を特定し、前記送信端末から前記一周期分の前記音声信号の出力が開始されてから前記一周期分の前記音声信号の出力が終了するまでの期間に前記受信ステップにより前記音声信号の受信を開始した場合、前記受信ステップにより順次受信した前記通信データを、前記先頭位置が先頭となる前記一周期の通信データの対応位置へと順次配置することにより、前記周期的に出力された音声信号の前記一周期分の前記通信データを生成する、
ことを特徴とする。

上記目的を達成するため、本発明の第３の観点に係るプログラムは、
コンピュータを、
送信端末から繰り返し周期的に出力される音声信号を通信データとして、任意のタイミングから順次受信する受信手段、
前記受信手段で受信した一周期分または一周期の一部分の前記通信データを、前記受信した通信データにおける前記一周期の先頭位置に基づいて、前記一周期の前記音声信号に対応する通信データの対応位置へと配置する配置手段、として機能させ、
前記配置手段は、前記受信した音声信号における前記一周期分の通信データにおける前記一周期の先頭位置を特定し、前記送信端末から前記一周期分の前記音声信号の出力が開始されてから前記一周期分の前記音声信号の出力が終了するまでの期間に前記受信手段により前記音声信号の受信を開始した場合、前記受信手段により順次受信した前記通信データを、前記先頭位置が先頭となる前記一周期の通信データの対応位置へと順次配置することにより、前記周期的に出力された音声信号の前記一周期分の前記通信データを生成する、
ことを特徴とする。

本発明によれば、処理時間を短縮化することができる。

本発明の実施の形態に係る通信システムの構成を示す図である。通信端末の構成を示すブロック図である。携帯端末の構成を示すブロック図である。（Ａ）は、ポイントサーバの構成を示すブロック図であり、（Ｂ）は、ポイント記憶部のデータテーブルの一例を示す図である。音声信号出力処理の一例を示すフローチャートである。音声信号生成処理の一例を示すフローチャートである。畳み込み符号器の一例を示す説明図である。（Ａ）～（Ｄ）は、ビット列データの遷移を示す説明図である。音声信号の出力例を示す図である。携帯端末の処理とポイントサーバの処理の一例を示すフローチャートである。受信音声復号処理の一例を示すフローチャートである。（Ａ）は、送信データと受信データの説明図であり、（Ｂ）～（Ｅ）は、受信データの説明図である。（Ａ）は、送信データの説明図であり、（Ｂ）～（Ｅ）は、受信データの遷移を示す説明図である。（Ｆ）および（Ｇ）は、受信データの遷移を示す説明図である。（Ａ）は、送信データの説明図であり、（Ｂ）および（Ｃ）は、受信データの説明図である。送信順序定義情報の一例を示す図である。音声信号の送信方法を説明するための説明図である。（Ａ）および（Ｂ）は、インタリーブについての説明図である。

まず、この実施の形態に係る通信システム１について、図１を参照して説明する。この実施の形態における通信システム１は、携帯端末２００を所有するユーザが当該店舗（図示する例では所定の空間Ｓ）に来店した際（チェックインした際）に、当該ユーザがアプリケーション（携帯端末２００に予めインストールされているものとする）を起動することにより、通信端末１００から出力される音声信号を受信して当該ユーザにポイントを加算するシステムである。なお、この実施の形態における通信システム１は、ユーザがアプリケーションを起動したタイミング、すなわち通信端末１００から出力されている音声信号の受信開始タイミングによって生じる解析時間のばらつきを防止することができるとともに、出力された音声信号（通信データ）の先頭から末尾までといった１周期分のデータを受信せずとも（例えば８０％分の受信であっても）、当該音声信号（通信データ）を解析することができるものとなっている。以下、このような通信システム１について説明する。なお、この実施の形態では、通信方式として高速周波数ホッピング方式（ＦａｓｔＦｒｅｑｕｅｎｃｙＨｏｐｐｉｎｇ；以下、ＦＦＨ方式と言う）を採用しているが、あくまでも一例であり、その他の通信方式を採用してもよい。

図１に示すように、通信システム１は、通信端末１００と、携帯端末２００と、ポイントサーバ３００と、を備えている。通信端末１００は、所定の空間Ｓ、例えば、店舗内部に配置され、通信端末１００と携帯端末２００とは、所定の空間Ｓ内で音声を伝送媒体として通信を行う。携帯端末２００とポイントサーバ３００とは、インターネット等の通信ネットワーク２を介してデータを送受信する。

図２は、通信端末１００の構成を示すブロック図である。通信端末１００は、当該来店客にポイントを加算するための音声信号の出力を行う端末であり、例えば、商品の決済処理を行う店舗端末や、リーダライタなどである。リーダライタは、ユーザがＩＣ（ＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）チップを有するＩＣカード、通信端末等の物体を近接させると当該ＩＣチップに記憶されたデータを読み取り、書き込み（読み書き処理）を行う装置である。なお、当該通信端末１００は、店舗端末やリーダライタなどの、決済処理やデータの読み書き処理を行う機能を有する端末とは別の、来店客にポイントを加算するための音声信号を出力する機能を備えた専用端末であってもよく、以下では、理解を容易にするため、当該通信端末１００が当該専用端末である場合を例に説明する。

通信端末１００は、操作部１１０と、発音部１２０と、記憶部１３０と、変調部１４０と、通信部１７０と、制御部１８０と、を備えている。通信端末１００の各部は、内部バスを介して相互に通信可能に接続されている。なお、図示は省略しているが、通信端末１００は、マイクを含む集音部を備えていてもよい（後述する携帯端末２００が備える集音部２３０及びマイク２３１と同一又は同等の構成であればよい）。なお、当該通信端末１００は、操作部１１０を備えていなくてもよい。

操作部１１０は、ユーザの操作を受け付け、受け付けた操作に対応する操作信号を制御部１８０に供給する。操作部１１０は、例えば、音量調節スイッチ、タッチパネル等を含む。また、操作部１１０は、例えば、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）ケーブルにより通信端末１００の本体に接続された外付けのテンキー（図示省略）であってもよい。

発音部１２０は、スピーカ１２１を含み、変調部１４０から供給された音声信号をＤ／Ａ（デジタル／アナログ）変換し、スピーカ１２１に供給する。これにより、デジタル音声信号が、空気振動（音）に変換され、出力される。なお、この実施の形態では、非可聴帯域の音声信号を出力することにより、人間にはほぼ聞こえないものとなっている。これは、可聴帯域の音声信号が出力されることによりユーザに不快感を与えることを防止するためである。

記憶部１３０は、例えば、ＲＡＭ（ＲａｎｄｏｍＡＣＣＥＳＳＭｅｍｏｒｙ）、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）、フラッシュメモリ、ハードディスク等を含む。記憶部１４０は、制御部１８０にて実行されるプログラム１３１や周波数ホッピングのホッピングパターンを示すＦＨパターン１３２、各種の情報（図示省略）を記憶する。また、記憶部１３０は、制御部１８０が動作するためのワークメモリとして機能する。

変調部１４０は、制御部１８０の制御に従って、当該制御部１８０により生成された、送信対象のデータであるビット列データを音声信号に変換する。より詳細に説明すると、変調部１４０は、制御部１８０から供給されたビット列データで搬送波を変調し、変調された搬送波（音声信号）を発音部１２０に出力する。なお、変調部１４０にて実行される音声信号の変調の処理は、有線通信や無線通信で用いられている一般的な処理と同様の処理であればよい。この実施の形態では、通信方式としてＦＦＨ方式を採用しているため、変調部１４０は、制御部１８０から供給されたビット列データを狭帯域変調によって変調（一次変調）してから（中間周波数信号としてから）、１パケット区間を複数のシンボルに分け、シンボル毎に異なる周波数に拡散する変調（二次変調）を行う処理が行われればよい。なお、１パケット区間に何個の周波数をどの順で順次出力するか（ホッピングパターン）については、ＦＨパターン１３２に基づいて行われる。

通信部１７０は、制御部１８０の制御に従って、携帯端末２００との間で無線信号を送受信することが可能なインターフェースである。

制御部１８０は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）等を備え、記憶部１３０に記憶されているプログラム１３１を実行することにより、図５に示す音声信号出力処理や、図６に示す音声信号生成処理を実行する。制御部１８０は、音声信号を生成する機能としての音声信号生成部１８１を備えている。

音声信号生成部１８１は、来店客にポイントを加算するための音声信号を生成するための機能部である。この実施の形態における音声信号生成部１８１は、送信対象のデータに基づいて、音声通信により携帯端末２００に出力する送信情報をビット列データとして生成し、変調部１４０へ出力する。送信対象のデータは、来店客に対してポイントの加算を許可する情報である。なお、音声信号生成部１８１は、送信対象のデータに対し、例えばＣＲＣ（ＣｙｃｌｉｃＲｅｄｕｎｄａｎｃｙＣｈｅｃｋ）の付与、畳み込み符号化、インタリーブなどの処理を行う。

以上が、通信端末１００の構成である。なお、この他にも現在時刻を計測する計時部を備えていてもよく、計時部は、現在時刻を計測するＲＴＣ（ＲｅａｌＴｉｍｅＣｌｏｃｋ）を備えていればよい。ＲＴＣは、例えば、電池を内蔵し、通信端末１００の電源がオフの間も計時を継続すればよい。そして、当該計時部により計測された現在時刻であるＲＴＣ時刻を示す情報についても、送信対象のデータとして携帯端末２００へ音声信号として出力されてもよい。

図３は、携帯端末２００の構成を示すブロック図である。携帯端末２００は、例えば、スマートフォンであり、通信端末１００から出力された音声信号を受信してポイントサーバ３００へポイントの加算を要求する端末である。携帯端末２００は、操作部２１０と、表示部２２０と、集音部２３０と、記憶部２４０と、復調部２５０と、通信部２６０と、制御部２７０と、を備えている。携帯端末２００の各部は、内部バスを介して相互に通信可能に接続されている。なお、図示は省略しているが、携帯端末２００は、スピーカを含む発音部を備えていてもよい（通信端末１００が備える発音部１２０及びスピーカ１２１と同一又は同等の構成であればよい）。

操作部２１０は、ユーザの操作を受け付け、受け付けた操作に対応する操作信号を制御部２７０に供給する。表示部２２０は、制御部２７０から供給されるデータに基づいて各種の画像、画面等を表示する。操作部２１０と表示部２２０とは、タッチパネルによって一体に構成されている。タッチパネルは、ユーザによる所定の操作を受け付ける操作画面を表示すると共に、操作画面においてユーザが接触操作を行った位置に対応する操作信号を制御部２７０に供給する。

集音部２３０は、マイク２３１を含み、当該通信端末１００から出力された音声信号を受信し、受信した音声信号をＡ／Ｄ（アナログ／デジタル）変換し、復調部２５０へ供給する。

記憶部２４０は、例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ハードディスク等を含む。記憶部２５０は、記憶部１４０は、制御部２７０に実行されるプログラム（図示省略）やユーザ毎に割り振られたユーザＩＤ２４１、通信端末１００に記憶されているものと同一のＦＨパターン１３２、各種の情報（図示省略）を記憶する。を含む。また、記憶部２４０は、制御部２７０が動作するためのワークメモリとしても機能する。

復調部２５０は、集音部２３０から供給された音声信号を復調する。なお、復調部２５０にて実行される音声信号の復調の処理は、有線通信や無線通信で用いられている一般的な処理と同様の処理であればよい。上述したように、この実施の形態では、通信方式としてＦＦＨ方式を採用しているため、復調部２５０は、集音部２３０から供給された音声信号から、送信側と同じホッピングパターンに基づいて、一次変調出力の中間周波数信号を取り出し、これをさらに復調してビット列データへと戻す処理が行われればよい。

通信部２６０は、制御部２７０の制御に従って、例えば、通信端末１００、ポイントサーバ３００との間で無線信号を送受信することが可能なインターフェースである。

制御部２７０は、ＣＰＵ等を備え、携帯端末２００の各部の制御を行う。制御部２７０は、記憶部２４０に記憶されているプログラムを実行することにより、図１０の携帯端末の処理を実行する。具体的に、制御部２７０は、通信端末１００から出力された音声信号を解析し、ポイントサーバ３００に対してポイントの加算を要求する処理（ポイント加算要求を送信する処理）を行う。ポイント加算要求には、当該携帯端末２００のユーザを特定するユーザＩＤ２４１を示す情報と、ポイントの加算を許可することを示す情報（通信端末１００から出力された音声信号に含まれる情報）が含まれていればよい。なお、当該通信端末１００から出力された音声信号にＲＴＣ時刻が含まれている場合には、当該ＲＴＣ時刻をポイント加算要求に含めてポイントサーバ３００に対して送信すればよい。
以上が、携帯端末２００の構成である。

図４（ａ）は、ポイントサーバ３００の構成を示すブロック図である。ポイントサーバ３００は、例えば、サーバ等の汎用コンピュータである。ポイントサーバ３００は、携帯端末２００からの要求に応じてポイントを加算する処理を行うサーバである。当該ポイントサーバ３００は、図示するように、記憶部３１０と、通信部３３０と、制御部３４０と、を備えている。ポイントサーバ３００の各部は、内部バスを介して相互に通信可能に接続されている。

記憶部３１０は、例えば、ＲＡＭ、ＲＯＭ、フラッシュメモリ、ハードディスク等を含む。記憶部３１０は、制御部３４０に実行されるプログラムや各種のデータ、加算ポイントの値等を記憶する。加算ポイントは、チェックイン毎にユーザの合計ポイントに加算されるポイントであり、当該加算ポイントの値は、管理者によって予め設定されている。また、記憶部３１０は、制御部３４０が動作するためのワークメモリとしても機能する。さらに、記憶部３１０は、ポイント記憶部３１１を有する。

図４（ｂ）は、ポイント記憶部３１１のデータテーブルの一例を示す図である。ポイント記憶部３１１は、ユーザＩＤ、加算ポイント及び合計ポイントに関する情報を記憶する。なお、例えば、通信端末１００から出力された音声信号にＲＴＣ時刻が含まれている場合、すなわち音声信号出力時の時刻が含まれている場合には、携帯端末２００から送信されるポイント加算要求に当該ＲＴＣ時刻が含まれているため、ポイント加算時において当該ＲＴＣ時刻（音声信号出力時の時刻）を、ポイント記憶部３１１のデータテーブルに登録するようにしてもよい。これによれば、いつ出力された音信号声によりポイントが加算されたかといったことの解析が可能となる。これに加え、ポイントサーバ３００自体が計時部（通信端末１００の計時部と同様の構成であればよい）を備え、ポイント加算時において当該ポイントサーバ３００の計時部にて計測したＲＴＣ時刻（ポイント加算時の時刻）を、ポイント記憶部３１１のデータテーブルにさらに登録するようにしてもよい。これによれば、音声信号出力時の時刻に加え、ポイント加算時の時刻が登録されることから、これらの差が予め定められた閾値以上の場合にはポイントを加算しないなど、不正なポイント加算要求を防止することができる。

通信部３３０は、制御部３４０の制御に従って、例えば携帯端末２００との間で無線信号を送受信することが可能なインターフェースである。

制御部３４０は、ＣＰＵ等を備え、ポイントサーバ３００の各部の制御を行う。制御部３４０は、記憶部３１０に記憶されているプログラムを実行することにより図１０に示すポイントサーバの処理を実行する。制御部３４０は、機能的に、ポイント加算部３４１を備えている。

ポイント加算部３４１は、携帯端末２００から送信されたポイント加算要求に含まれるユーザＩＤに対応する合計ポイントをポイント記憶部３１１から読み取り、読み取られた合計ポイントに、ポイント記憶部３１１に記憶された加算ポイントを加算して、当該記憶部３１０のデータテーブルを更新する。なお、この実施の形態では、通信端末１００から出力される音声信号にはポイントの加算を許可する情報が含まれ、当該情報により、ポイントサーバ３００に記憶された加算ポイントが加算される例を示したが、通信端末１００から出力される音声信号に、加算するポイント数の情報（加算ポイント数情報）を含めるようにしてもよい。そして、携帯端末２００にて、ポイント加算要求に当該加算ポイント数情報を含め、ポイントサーバ３００において当該ポイント加算要求に含まれる加算ポイント数のポイントを加算するようにしてもよい。これによれば、店舗側で加算するポイントを独自に変更可能となる。したがって、例えば、店舗独自のキャンペーンを行う場合など、店舗独自のサービスの提供が容易になる。
以上が、ポイントサーバ３００の構成である。

次に、通信システム１の動作について説明する。

まず、通信端末１００の動作について、図５～図９を参照して説明する。図５は、通信端末１００が実行する音声信号出力処理の一例を示すフローチャートである。この実施の形態では、例えば、開店時において店員などの店舗側ユーザの操作部１１０への操作が行われることにより、記憶部１３０に記憶されているプログラム１３１が実行され、当該音声信号出力処理の実行が開始される。また、当該音声信号出力処理は、閉店時において店舗側ユーザの操作部１１０への操作が行われることで終了する。なお、例えばタイマ設定により開始と終了が自動で制御されてもよい。すなわち、この実施の形態では、音声信号出力処理が一旦実行された後は、店舗側ユーザによる終了操作が行われるまで、当該音声信号出力処理（より具体的にはステップＳ１２の音声信号の出力の処理）が継続して行われる。

音声信号出力処理の実行を開始すると、まず、制御部１８０は、音声信号生成部１８１の機能により、音声信号生成処理を行う（ステップＳ１１）。図６は、図５のステップＳ１１の処理にて実行される音声信号生成処理の一例を示すフローチャートである。図６に示す音声信号生成処理において、制御部１８０は、まず、送信対象データを生成する（ステップＳ１０１）。ステップＳ１０１では、来店客に対してポイントの加算を許可する情報を送信対象のデータとして、ビット列データを生成する。

ステップＳ１０１の処理を実行した後、制御部１８０は、当該ビット列データに対し、ＣＲＣの付与や暗号化などといった暗号化等前処理を行う（ステップＳ１０２）。

続いて制御部１８０は、暗号化等前処理を行った後のビット列データに対し、畳み込み符号化処理を施す（ステップＳ１０３）。この実施の形態におけるステップＳ１０３では、図７に示す拘束長７の畳み込み符号器による演算を行うことにより当該ビット列データを畳み込み符号化すればよい。なお、ステップＳ１０３における符号化は、畳み込み符号による符号化に限定されず、例えば、ＢＣＨ（Ｂｏｓｅ－Ｃｈａｕｄｈｕｒｉ－Ｈｏｃｑｕｅｎｇｈｅｍ）符号、ＲＳ（Ｒｅｅｄ－Ｓｏｌｏｍｏｎ）符号、ターボ符号、ＬＤＰＣ（ＬｏｗＤｅｎｓｉｔｙＰａｒｉｔｙＣｈｅｃｋ）などの符号化方式であってもよい。

図６のステップＳ１０３の処理を実行した後、制御部１８０は、符号化レートの高いパンクチャード符号に対応するデータが先に出力されるよう、当該符号化レートの高い順にデータをインタリーブし（ステップＳ１０４）、変調部１４０に当該インタリーブ後のデータを供給する。

当該インタリーブ後のデータが供給されると、変調部１４０では、当該インタリーブ後のデータを変調する処理や、ウィンドウの追加などの変調等後処理を行い（ステップＳ１０５）、変調後のデータを発音部１２０へと供給し、音声信号生成処理を終了する。

続いて、図８を参照して、当該音声信号生成処理の具体例を説明する。図示するように、図６のステップＳ１０１及びステップＳ１０２の処理が実行された後のビット列データが図８（Ａ）に示すデータである場合を例に説明する。なお、この例では、理解を容易にするため、図示するようにビット列データにはＧ００～Ｇ１３といったインデックス値を付加している。

図６のステップＳ１０３の処理において、まず、畳み込み符号におけるシフトレジスタの最終値を「０」に戻すため、拘束長－１に対応するダミーデータを付加する。具体的に、拘束長は７であることから、図８（Ｂ）に示すようにダミーデータとして６個の「０」を付加する（図示するＧ１４～Ｇ１９のインデックスに対応するデータ）。続いて図６のステップＳ１０３の処理において、図８（Ｂ）に示すデータを畳み込み符号化して、図８（Ｃ）に示すようにＵ００～Ｕ１９のインデックスに対応するデータとＶ００～Ｖ１９のインデックスに対応するデータとを生成する。

次に、図６のステップＳ１０４の処理を実行することで、図８（Ｃ）に示すデータを図８（Ｄ）に示すようにインタリーブする。上述したように、ステップＳ１０４の処理では、符号化レートの高いパンクチャード符号に対応するグループのデータが先に出力されるよう、当該符号化レートの高い順にインタリーブされる。図示する例では、Ｕ００、Ｕ０４、Ｕ０８、Ｕ１２、Ｕ１６といったＵ００のパンクチャード符号に対応するグループのデータが最も符号化レートが高く、次いでＵ０２、Ｕ０６、Ｕ１０、Ｕ１４、Ｕ１８といったＵ０２のパンクチャード符号に対応するグループのデータが高く、続いてＵ０１、Ｕ０５、Ｕ０９、Ｕ１３、Ｕ１７といったＵ０１のパンクチャード符号に対応するグループのデータと、Ｕ０３、Ｕ０７、Ｕ１１、Ｕ１５、Ｕ１９といったＵ０３のパンクチャード符号に対応するグループのデータとなっている。そのため、図８（Ｄ）に示すように、Ｕ００のインデックスに対応するグループのデータを先頭に配置し、次いでＵ０２のインデックスに対応するグループのデータ、その次にＵ０１のインデックスに対応するグループのデータ、その後Ｕ０３のインデックスに対応するグループのデータ、といった順にインタリーブしている。なお、図８（Ｄ）に示すように、Ｖ００～Ｖ１９のインデックスに対応するデータも、Ｕ００～Ｕ１９と同様の順にインタリーブされればよい。具体的に、Ｕ００～Ｕ０３、Ｖ００～Ｖ０３のビットデータを例に説明すると、符号化レート４／４（当該符号化レート４／４の例は、訂正能力が低いため、一般に知られた符号化レートの名称ではないが、この実施の形態ではパンクチャード符号の一つとして扱うものとしている）の場合には、パンクチャード処理によりＶ００～Ｖ０４のビットデータが間引かれ、符号化レート４／５の場合には、パンクチャード処理によりＶ０１～Ｖ０３のビットデータが間引かれ、符号化レート２／３の場合には、パンクチャード処理によりＶ０１とＶ０３のビットデータが間引かれ、符号化レート１／２の場合には、いずれのビットデータも間引かれないこととなる。すなわち、符号化レートが下がるに従って、間引かれるビットデータが少なくなる。なお、符号化レート３／４の場合には、Ｕ００～Ｕ０２、Ｖ００～Ｖ０２のビットデータについて、パンクチャード処理によりＶ０１とＵ０２のビットデータが間引かれることとなる。この実施の形態では、符号化レート３／４の場合、他の符号化レートの場合と比較して周期が変わってしまうため、符号化レート４／４、４／５、２／３、および１／２におけるＵ００～Ｕ０３、Ｖ００～Ｖ０３のビットデータを用いて説明する。Ｕ００～Ｕ０３、Ｖ００～Ｖ０３のビットデータを、符号化レートの高い順に並べると、Ｕ００～Ｕ０３（符号化レート４／４）、Ｖ００（符号化レート４／５）、Ｖ０２（符号化レート２／３）、Ｖ０１、Ｖ０３（符号化レート１／２）となる。そして、ＵとＶとの対称性を考慮し、Ｕ０～Ｕ３を、Ｖ０～Ｖ３と同様の順（Ｖ００、Ｖ０２、Ｖ０１、Ｖ０３の順）に並べると、Ｕ００、Ｕ０２、Ｕ０１、Ｕ０３となる。すなわち、符号化率が高く、間引かれる割合が高い符号のビットが先に送信され、符号化率が低く、間引かれる割合が低い符号のビットのうち、未送信のビットが続けて送信されるよう並べられる。そして、Ｕ０４～Ｕ０７、Ｖ０４～Ｖ０７についてもＵ００～Ｕ０３、Ｖ００～Ｖ０３と同様であり、Ｕ００やＶ００に対応するビットデータの集まりを、それぞれＵ００のパンクチャード符号に対応するグループのデータ、Ｖ００のパンクチャード符号に対応するグループのデータと呼ぶ（Ｕ０１～Ｕ０３、Ｖ０１～Ｖ０３についても同様）。このことから、図８（Ｄ）に示すように、Ｕ００、Ｕ０４、Ｕ０８、Ｕ１２、Ｕ１６といったＵ００のパンクチャード符号に対応するグループのデータ、次いでＵ０２、Ｕ０６、Ｕ１０、Ｕ１４といったＵ０２のパンクチャード符号に対応するグループのデータ、続いてＵ０１、Ｕ０５、Ｕ０９、Ｕ１３といったＵ０１のパンクチャード符号に対応するグループのデータ、Ｕ０３、Ｕ０７、Ｕ１１、Ｕ１５、Ｕ１９といったＵ０３のパンクチャード符号に対応するグループのデータ、の順に出力されるようインタリーブされることとなる。

そして、図８（Ｄ）に示すように、Ｕ００～Ｕ１９、次いでＶ００～Ｖ１９のインデックスに対応するデータが、図５のステップＳ１２の処理により音声信号として順次出力され、１パケット分出力されることとなる。

図５に戻り、ステップＳ１１における音声信号生成処理を実行した後、制御部１８０は、ステップＳ１１により発音部１２０へと供給された変調後のデータをＤ／Ａ変換してスピーカ１２１に供給することにより、音声信号を出力する（ステップＳ１２）。

上述したように、この実施の形態では、店舗側ユーザによる終了操作が行われるまで、当該音声信号出力処理は終了しない。そのため、一旦ステップＳ１１の処理が行われた後は、図示するように、当該終了操作が行われるまで、ステップＳ１２の処理が繰り返し実行され、ステップＳ１１にて生成された音声信号が繰り返し出力される。なお、ステップＳ１２の処理が実行され音声信号が出力された後、再度ステップＳ１２の処理が実行され再び音声信号が出力されるまでの期間は、１パケット区間よりも十分に短い時間となっている。すなわち、１パケットの音声信号が出力されてから、再度１パケットの音声信号が出力されるまでのインターバル期間が１パケット区間よりも十分に短い時間となっており、１パケットの音声信号が出力されてから連続的に次の１パケットの音声信号が出力される。なお、この実施の形態では、理解を容易にするため、１パケットの音声信号の出力が完了した後に、次の１パケットの音声信号が出力される例を示しているが、例えば、１パケットの音声信号の出力中に、次の１パケットの音声信号を重ねて出力してもよい。具体的に、１周期（１パケット）の音声信号を出力する場合において、当該出力中の１パケットの音声信号における最後の部分のシンボルの出力に重ねて、次の１パケットの最初の部分のシンボルを出力してもよい。すなわち、パケット周期の誤差が１シンボル長に比べて十分小さければよく、連続的の概念には、１パケットの音声信号の出力が完了した後に次の１パケットの音声信号が連続して出力されることに加え、１パケットの出力に重ねて次の１パケットの音声信号が出力されることも含まれる。

このように、図５のステップＳ１２の処理が繰り返し実行されることで、図８に示すＵ００～Ｖ１９のインデックスに対応するデータが、音声信号として図９に示すように繰り返し出力されることとなる。なお、この実施の形態では、図示するように、１周期、すなわち１パケットの音声信号出力期間が２．４秒間となっている。店舗に来店した顧客側ユーザは、来店に伴い携帯端末２００にインストールされているアプリケーションを起動させることで、当該繰り返し出力される音声信号を受信して、ポイントを加算する。また、この実施の形態では、理解を容易にするため、出力される音声は固定のデータ長であり、当該データ長が送信側と受信側とにおいて予め設定されているものとする。そのため、受信側では、未受信部分がどの程度の長さであるかが特定できるものとなっている。また、出力される音声は可変長のデータ長であってもよく、その場合には、例えばヘッダを作成し、当該ヘッダ部分にデータ長を示す情報を含めて出力すればよい。受信側では、当該ヘッダ部分に含まれるデータ長により当該出力される音声のデータ長を特定し、未受信部分がどの程度の長さであるかを特定すればよい。

次に、携帯端末２００の動作（ポイントサーバ３００の動作も含む）について、図１０～図１４を参照して説明する。図１０は、携帯端末２００が実行する携帯端末の処理の一例（ポイントサーバ３００が実行するポイントサーバの処理の一例も含む）を示すフローチャートである。当該携帯端末の処理は、顧客側ユーザによる操作部２１０への操作によりアプリケーションが起動することで実行を開始する。

携帯端末の処理の実行を開始すると、まず、制御部２７０は、顧客側ユーザによる操作部２１０の操作を受け付ける（ステップＳ２１）。具体的に、ステップＳ２１では、例えば、顧客側ユーザによる来店ポイント加算操作（チェックイン操作）を受け付ける。当該来店ポイント加算操作は、例えば、起動したアプリケーションにより表示された来店ポイント加算の項目を選択する操作であればよい。

ステップＳ２１の処理が行われると、制御部２７０は、集音部２３０に含まれるマイク２３１を起動して（ステップＳ２２）、通信端末１００からの音声信号の受信を開始する（ステップＳ２３）。通信端末１００から音声信号の受信を開始すると、制御部２７０は、受信した音声信号を復号する受信音声復号処理を実行する（ステップＳ２４）。

図１１は、図１０のステップＳ２４にて行われる受信音声復号処理の一例を示すフローチャートである。図１１に示す受信音声復号処理において、制御部２７０は集音部２３０を制御して、通信端末１００から音声信号を受信する（ステップＳ２０１）。ステップＳ２０１では、例えば、記憶部２４０に記憶されているＦＨパターン１３２に従って受信周波数を有効化し音声信号を受信する。なお、受信した音声信号は、当該集音部２３０によりＡ／Ｄ変換され、復調部２５０へ供給される。

ステップＳ２０１の処理を実行した後、制御部２７０は、復調部２０５の機能により、受信した音声信号を復調する処理や、不要な情報を削除することにより必要な情報を取得する処理を行う復調等前処理を行い（ステップＳ２０２）、受信データとしてのビット列データ（図１３参照）を制御部２７０へ供給する。

ステップＳ２０２の処理を実行した後、制御部２７０は、音声信号における先頭位置を特定する（ステップＳ２０３）。具体的に、ステップＳ２０３の処理では、例えば、受信した音声信号のホッピングパターンと記憶部２４０に記憶されているＦＨパターン１３２とを照合し、受信した音声信号が当該１パケットにおけるいずれのシンボルに対応する音声信号であるかを判定することで、当該１周期の音声信号における先頭（１パケット中の先頭）の位置を特定する（１周期の音声信号における後半部を受信した場合には、末尾の位置を先頭の位置とする）。なお、ステップＳ２０３の処理では、例えば、受信した音声信号のシンボルから当該１周期の音声信号の先頭までの距離と、当該シンボルから末尾までの距離のうち、距離の短い方を先頭の位置として特定すればよい。すなわち、前半部を受信した場合には当該受信した音声信号に対応する先頭部分を先頭位置として特定し、後半部を受信した場合には当該受信した音声信号に対応する末尾部分を、１周期の音声信号の先頭位置として特定すればよい。なお、ステップＳ２０２の処理により１周期の音声信号における先頭（１パケット中の先頭）の位置が一旦特定された後は、当該受信音声復号処理が終了するまで、ステップＳ２０３の処理をスキップすればよい。

ステップＳ２０３の処理を実行した後、制御部２７０は、当該ステップＳ２０３の処理で特定した先頭位置に基づいて、ステップＳ２０１の処理で受信した音声信号を、当該１周期の音声信号における対応位置へ配置する（ステップＳ２０４）。具体的に、ステップＳ２０４の処理では、ステップＳ２０３の処理で特定した先頭位置を基準とした１周期の音声信号（１パケットのビット列データ）のうちの対応するシンボルへ、当該ステップＳ２０２にて取得したビット列データを配置する（図１２参照）。すなわち、ステップＳ２０４の処理では、後半部、前半部、後半部といった順に受信した場合には、ステップＳ２０３の処理において、最初に受信される後半部と、次に受信される前半部との間が先頭位置であると特定されるため、最初に受信した後半部が最後に受信した後半部の後に付加されるように、また、前半部、後半部、前半部といった順に受信した場合には、ステップＳ２０３の処理において、最初に受信される前半部より前の位置が先頭位置であると特定されるため、最後に受信した前半部が最初に受信した前半部の前に付加されるように、受信した音声信号の並び替えを行う。したがって、ステップＳ２０４の処理が繰り返し実行されることで、受信した音声信号が１周期の音声信号（１パケットのビット列データ）のうちの対応するシンボルへと順次配置されることから、いずれのタイミングで音声信号を受信した場合であっても（当該出力中の音声信号を途中から受信した場合であっても）、少なくとも１周期分の音声信号を受信することで、当該１周期分の音声信号を生成することができる。

続いて制御部２７０は、１周期の音声信号のうち、未だ受信していない未受信部分に中間値としての「０．５」をセットする（ステップＳ２０５）。具体的に、ステップＳ２０５の処理では、ステップＳ２０３の処理で特定した先頭位置を基準とした１周期の音声信号（１パケットのビット列データ）のうち、未だ受信していないシンボルに対応する部分に中間値として「０．５」を挿入する。なお、中間値に限られず、ダミーデータを挿入してもよい。なお、１シンボルが２ビットで構成される場合には、それぞれに中間値としての「０．５」を挿入すればよい。

ステップＳ２０５の処理を実行した後、制御部２７０は、当該中間値を挿入したビット列データに対し、図６のステップＳ１０４の処理におけるインタリーブとは逆の動作であるデインタリーブを行うことで（ステップＳ２０６）、データの並びを元に戻す。ステップＳ２０６の処理を実行した後、制御部２７０は、デインタリーブ後のデータについて、ビダビアルゴリズムにより、復号および誤り訂正処理を行い（ステップＳ２０７）、誤り訂正後のデータに含まれるＣＲＣついてＣＲＣ判定を行う（ステップＳ２０８）。そして、ＣＲＣ判定結果が正常であれば当該ステップＳ２０９においてＹｅｓと判定し、当該ＣＲＣ判定結果が正常であるビット列データを正常なビット列データとして記憶し、全てのＣＲＣ判定結果が正常でない場合には、Ｎｏと判定すればよい。なお、ステップＳ２０７の処理では、図６のステップＳ１０３にて符号化されたビット列データを復号および誤り訂正処理できれば、ビダビアルゴリズムに限られない。

ステップＳ２０９においてＣＲＣ判定の判定結果が正常である場合には（ステップＳ２０９；Ｙｅｓ）、受信音声復号処理を終了する。一方、正常でない場合には（ステップＳ２０９；Ｎｏ）、ステップＳ２０１の処理に戻り、ステップＳ２０１～Ｓ２０９の処理を繰り返し実行する。

続いて、図１２～図１４を参照して、当該受信音声復号処理の具体例を説明する。この例では、図１２（Ａ）に示すタイミング（図示するアプリ起動のタイミング）で携帯端末２００のアプリケーションが起動され、当該受信音声復号処理が開始されたものとする。また、理解を容易にするためこの例では、１周期の８０％に対応する音声信号を受信した際に当該受信音声復号処理におけるステップＳ２０８にて正常と判定され、当該受信音声復号処理が終了する場合を例に以下説明する。

まず、図１２を参照して当該受信音声復号処理の概要について説明する。まず、受信音声復号処理が開始されると、図１１のステップＳ２０１の処理にて音声信号が受信される。例えば、現在の状況が図１２（Ｂ）に示すように、出力された音声信号の後半部の音声信号のみを受信したような状況の場合、図１１のステップＳ２０３の処理により、当該受信した後半部の末尾の位置を、１周期の音声信号における先頭位置として特定し、ステップＳ２０４の処理において、図１２（Ｃ）に示すように、当該受信した後半部の音声信号が、１周期の音声信号における対応位置へと配置される。

そして、図１１のステップＳ２０５の処理により、図１２（Ｃ）に示す未受信部のシンボルに対応する部分に中間値として「０．５」が挿入される。その後、ステップＳ２０７およびステップＳ２０８の処理が実行されるものの、図１２（Ｂ）および図１２（Ｃ）に示す例の場合、受信した音声信号が少ないことから、エラー訂正に失敗し、ＣＲＣが不一致となり、図１１のステップＳ２０９にてＮｏと判定されるため、ステップＳ２０１の処理が再度実行され、音声信号を再度受信することとなる。

続いて図１２（Ｄ）に示すように、図１２（Ｂ）に示す状態からさらに音声信号を受信し、１周期の８０％に対応する音声信号を受信した場合、図１１のステップＳ２０４の処理において、図１２（Ｂ）に示す状態の後に受信した前半部の音声信号と、その後に受信した後半部の音声信号とが、図１２（Ｅ）に示すように、それぞれ１周期の音声信号における対応位置へ配置される。このように、図１１のステップＳ２０４の処理が繰り返し実行されることで、受信した音声信号が１周期の音声信号（１パケットのビット列データ）のうちの対応するシンボルへと順次配置されることから、いずれのタイミングで音声信号を受信した場合であっても（当該出力中の音声信号を途中から受信した場合であっても）、少なくとも１周期分の音声信号を受信すれば（図示する未受信部分も受信すれば）、当該ステップＳ２０４の処理により、当該１周期分の音声信号を生成することができることとなる。

そして、図１１のステップＳ２０５の処理により、図１２（Ｅ）に示す未受信部のシンボルに対応する部分に中間値として「０．５」が挿入され、ステップＳ２０７およびステップＳ２０８の処理が実行される。上述したように、この例では、１周期の８０％に対応する音声信号を受信した際に当該受信音声復号処理におけるステップＳ２０９にてＹｅｓと判定されることから、これにより、当該受信音声復号処理が終了することとなる。

次に、図１３～図１４を参照して、当該受信音声復号処理におけるビット列データの具体例について説明する。なお、図示する例は、図１２（Ｄ）に示すように図１２（Ｂ）に示す状態からさらに音声信号を受信し、１周期の８０％に対応する音声信号を受信した場合の例を示している。

まず、図１１のステップＳ２０１の処理により、通信端末１００から音声信号が順次受信され、図１１のステップＳ２０２の処理が行われることで、図１３（Ｂ）に示す受信データとしてのビット列データが順次制御部２７０へ供給される。なお、図１３（Ａ）は送信データを示しており、図８（Ｄ）に示すＵ００～Ｖ１９のインデックスに対応するビット列データとなっている。また、図１３に示す例では、図１３（Ａ）に示すビット列データを受信した際、エラーにより、図１３（Ｂ）に示す２つのビットが反転しているものとする。

具体的に、図１３（Ｂ）に示す例では、図８（Ｄ）に示すＵ００～Ｖ１９のインデックスに対応するビット列データの後半部におけるＶ０１～Ｖ１９のインデックスに対応するデータを受信し、その後前半部におけるＵ００～Ｕ１９のインデックスに対応するデータ、そして後半部におけるＶ００とＶ０４のインデックスに対応するデータを受信し、Ｖ０８～Ｖ１８のインデックスに対応するデータは未受信である場合の例を示している。

そして、図１１のステップＳ２０４の処理が行われることで、図１３（Ｃ）に示すように、受信した前半部のビット列データと後半部のビット列データとが、それぞれ１周期のビット列データにおける対応位置へ配置され、図１１のステップＳ２０５の処理が行われることで、図１３（Ｄ）に示すように、未受信部分であるＶ０８～Ｖ１８のインデックスに対応するデータ部分に、中間値である「０．５」が挿入される。

続いて図１１のステップＳ２０６の処理が行われることで、図１３（Ｄ）に示すビット列データが、図１３（Ｅ）に示すようにＵ００～Ｕ１９のインデックスに対応するデータとＶ００～Ｖ１９のインデックスに対応するデータとの並びに戻ることとなる。なお、図示する例では、理解を容易にするため、ビット列データにインデックス値を付与している。

そして、図１１のステップＳ２０７の処理が行われることで、復号および誤り訂正が行われ、図１４（Ｇ）に示すように、図８（Ａ）と同様のビット列データとなる。なお、図１４（Ｆ）における点線部分に示すように、符号化レートが２／３である場合と同様の符号パターンであることから、誤り訂正能力が高く、図１１のステップＳ２０７の処理において行われた復号および誤り訂正処理の結果に含まれるＣＲＣの判定結果が、図１１のステップＳ２０８の処理にて正常と判定されることとなる。その結果として、図１４（Ｇ）に示すように、図８（Ａ）に示す１周期のビット列データに対応する送信データと同様のビット列データが取得されることとなる。

このように、この実施の形態によれば、図１１のステップＳ２０３およびＳ２０４の処理により、アプリケーションを起動したタイミングが出力中の音声の中盤であった場合であっても、当該出力中の音声の次に出力される音声の先頭を待つことなく処理が可能となる。すなわち、いずれのタイミングでアプリケーションを起動した場合であっても処理が可能となり、処理時間を短縮化することができる。さらに、１周期分の音声を受信しなくとも（１周期分の受信を待つことなく）、図１１のステップＳ２０５～Ｓ２０８により、１周期分の音声に復号および誤り訂正可能である。したがって、１周期分の音声を受信せずとも処理が可能となり、さらなる処理時間の短縮化が可能となる。

図１０に戻り、ステップＳ２４における受信音声復号処理を実行した後、制御部２７０は、ポイントサーバ３００に対してポイントの加算を要求するポイント加算要求を送信する（ステップＳ２５）。ステップＳ２５では、記憶部２４０に記憶されているユーザＩＤ２４１を示す情報と、ポイントの加算を許可することを示す情報（通信端末１００から出力された音声信号に含まれる情報）とを対応付けた情報を、ポイント加算要求としてポイントサーバ３００に送信する。なお、ポイントの加算を許可することを示す情報は、ステップＳ２４にて取得したビット列データから予め定められたビット列を抽出することにより取得すればよい。

ポイントサーバ３００の側では、携帯端末２００から送信されたポイント加算要求を受信すると、ポイントサーバの処理を開始する。なお、携帯端末２００の側では、当該ポイントサーバ３００へポイント加算要求を送信した後は、当該ポイントサーバ３００からポイント加算処理の処理結果を受信するまで待機する。

ポイントサーバ３００の制御部３４０は、ポイントサーバの処理を開始すると、まず、受信したポイント加算要求からユーザＩＤ２４１を特定する（ステップＳ３１）とともに、ポイントの加算を許可することを示す情報が正常な情報であることを特定する（図示省略）。

ステップＳ３１の処理を実行した後、制御部３４０は、ポイント加算部３４１の機能により、ステップＳ３１の処理で特定したユーザＩＤのユーザのポイントを加算するポイント加算処理を実行し（ステップＳ３２）、当該ポイント加算処理の処理結果を携帯端末２００へ送信してから（図示省略）、ポイントサーバの処理を終了する。具体的に、ステップＳ３１の処理では、ポイント記憶部３１１のデータテーブルに登録されている加算ポイントの値を合計ポイントの値に加算することで当該データテーブルを更新する処理を行う。そして、当該処理が正常に行われた場合には、その旨を示す成功結果を、合計ポイント値とともに携帯端末２００へ送信する一方、エラーが生じた場合には、その旨を示す失敗結果を携帯端末２００へ送信する。

携帯端末２００の側では、ポイントサーバ３００から送信されたポイント加算処理の処理結果を受信すると、表示部２２０に当該ポイント加算処理の処理結果を表示することで顧客側ユーザへチェックイン操作の終了を報知し（ステップＳ２６）、携帯端末の処理を終了する。具体的に、ステップＳ２６の処理では、例えば成功結果と合計ポイント値を受信した場合、当該チェックイン操作によりポイント値が加算されたことを示す成功表示を行うとともに、受信した合計ポイント値を表示する。一方、失敗結果を受信した場合には、当該チェックイン操作においてエラーが発生してポイント値が加算されていないことを示す失敗表示を行う。なお、当該失敗表示を行う場合には、再度チェックイン操作を行うことを促す促進表示を行うようにしてもよい。また、失敗結果を受信した場合、特に処理を行わなくてもよい。

以上が携帯端末２００の動作（ポイントサーバ３００の動作も含む）である。このように、この実施の形態における携帯端末２００は、アプリケーションを起動したタイミングが出力中の音声の中盤であった場合であっても、当該出力中の音声の次に出力される音声の先頭を待つことなく、ポイントサーバ３００へポイント加算要求を送信する。これにより、ポイントが加算されるまでの処理時間を短縮することができる。また、１周期分の音声を受信しなくとも（１周期分の受信を待つことなく）、ポイントサーバ３００へポイント加算要求を送信することができるため、ポイントが加算されるまでの処理時間をさらに短縮することができる。

（変形例）
この発明は、上記の実施の形態に限定されず、種々の変形及び応用が可能である。上記実施の形態で示した全ての技術的特徴を備えるものでなくてもよく、従来技術における少なくとも１つの課題を解決できるように、上記実施の形態で説明した一部の構成を備えたものであってもよい。また、下記の変形例で示す構成をそれぞれ組み合わせてもよい。

上記実施の形態では、通信方式として高速周波数ホッピング方式（ＦＦＨ方式）を採用した例を示したが、上述したように、その他の通信方式を採用してもよい。また、上記実施の形態では、通信端末１００を送信側の端末、携帯端末２００を受信側の端末として説明したが、これは一例である。例えば、携帯端末２００を送信側の端末とし、通信端末１００を受信側の端末としてもよい。また、通信端末１００と携帯端末２００が双方向に通信可能であり、通信端末１００と携帯端末２００のそれぞれが、送信側の端末としての機能と受信側の端末としての機能の両方を備えており、状況に応じて送信側と受信側とを切り替え可能としてもよい。さらに、上記実施の形態では、理解を容易にするため、通信端末１００と携帯端末２００との通信を例に説明したが、通信端末１００同士、携帯端末２００同士の通信であってもよい。すなわち、送信側の端末としての機能と受信側の端末としての機能を備えている端末同士における双方向の通信であってもよい。

上記実施の形態では、図１１のステップＳ２０３の処理において、受信した音声信号のホッピングパターンと記憶部２４０に記憶されているＦＨパターン１３２とを照合し、受信した音声信号が当該１パケットにおけるいずれのシンボルに対応する音声信号であるかを判定することで、当該１周期の音声信号における先頭（１パケット中の先頭）の位置を特定する（１周期の音声信号における後半部を受信した場合には、末尾の位置を先頭位置とする）例を示したが、これは一例である。通信方式として高速周波数ホッピング方式（ＦＦＨ方式）以外の通信方式を採用している場合には、例えば、プリアンブルにより先頭位置を特定してもよい。また、送信データに位置情報（例えばインデックス）を含めた音声信号を送信することで、受信側において当該位置情報（インデックス値）により先頭の位置を特定するようにしてもよい。先頭の位置を基準とした１周期の音声信号（１パケットのビット列データ）のうちの対応するシンボルへと受信した音声信号を配置できれば、先頭の位置を特定する方法は任意である。

また、上記実施の形態では、後半部、前半部、後半部といった順に受信した場合には、図１１のステップＳ２０３の処理において、最初に受信される後半部と、次に受信される前半部との間を先頭位置であると特定し、前半部、後半部、前半部といった順に受信した場合には、ステップＳ２０３の処理において、最初に受信される前半部より前の位置を先頭位置であると特定する例を示したが、これは一例である。いずれの場合であっても、先に受信される後半部と、次に受信される前半部との間を先頭位置であると特定するようにしてもよい。そして、図１１のステップＳ２０４の処理において、当該先頭位置以前に受信した音声信号と、当該先頭位置より後に受信した音声信号とが入れ替わるように受信した音声信号を順次配置することで、当該１周期分の音声信号を生成するようにしてもよい。

また、上記実施の形態では、図９に示すように、同一の音声信号が繰り返し出力される例について説明したが、必ずしも同一の音声信号でなくてもよく、異なる音声信号が連続的に出力されてもよい（なお、音声信号の長さについては共通であるものとする）。この場合には、例えば、図１５（Ａ）に示す送信データ１と送信データ２におけるＧ０３のインデックスに対応するデータといったように、同一のインデックスに対応するデータが異なっていればよい。なお、図１５に示す例では、理解を容易にするため、誤り訂正符号を使用しない例を示している。また、図示する例では、同一のインデックスに対応するデータとして１ビットのデータが異なる例を示しているが、１ビットに限られず、例えば、同一のインデックスに対応する１バイトのデータが異なるなど、同一のインデックスに対応するデータであれば、複数ビット異なっていてもよい。

図１５（Ａ）に示すように、Ｕ０３のインデックスに対応するデータが異なる送信データ１と送信データ２とが連続的に出力される場合、携帯端末２００において１周期分の音声信号を受信すると、図１５（Ａ）に示すように、（１）送信データ１のＵ０３のインデックスに対応するデータを含む音声信号を受信するときと、（２）送信データ２のＵ０３のインデックスに対応するデータを含む音声信号を受信するとき、といったように、送信データ１のＵ０３に対応するデータと送信データ２のＵ０３に対応するデータとのいずれかを含む音声信号を受信することとなる。

そのため、（１）送信データ１のＵ０３のインデックスに対応するデータを含む音声信号を受信した場合は、図１１のステップＳ２０４の処理により、図１５（Ｂ）に示すように、送信データ１として処理が可能となる。また、（２）送信データ２のＵ０３のインデックスに対応するデータを含む音声信号を受信した場合は、図１１のステップＳ２０４の処理により、図１５（Ｃ）に示すように、送信データ２として処理が可能となる。したがって、連続的に出力される音声信号が同一ではなくとも、同一のインデックスに対応するデータが異なっている音声信号であれば、いずれのタイミングでアプリケーションを起動した場合であっても処理が可能となり、処理時間を短縮化することができる。なお、連続的に出力される音声信号が同一ではない場合、前半部と後半部のいずれか一方における同一のインデックスに対応するデータが異なっていればよい。また、図１５に示すように、同一のインデックスに対応するデータが異なっている音声信号が連続的に出力されている場合であっても、図１１のステップＳ２０５～Ｓ２０８により、１周期分の音声を受信せずとも処理が可能である点は上記実施の形態と同様である。

また、上記実施の形態では、図８（Ｄ）に示すように、Ｕ００～Ｕ１９、次いでＶ００～Ｖ１９のインデックスに対応するデータが、図５のステップＳ１２の処理により音声信号として順次出力され、１パケット分出力される例を示したが、これは一例である。例えば、通信端末１００は、図１６および図１７に示すように、１７．９ｋＨｚ～１９．９ｋＨｚ（ハイバンド）、１５．９ｋＨｚ～１７．９ｋＨｚ（ローバンド）の２つの帯域を使用して音声信号を出力してもよい。

例えば、図１６に示すように、ローバンドでは、送信する１パケットを２分割した後半部から前半部の順に送信し、ハイバンドでは、前半部から後半部といったように順序を変えることなく送信してもよい。なお、図１６に示す送信順序を定義した送信順序定義情報については、予め記憶部１３０に記憶されていればよい。

具体的に、図１７に示すように、ローバンドでは、図８（Ｄ）に示すＶ００～Ｖ１９のインデックスに対応するデータ（後半部）を先に送信し、その後Ｕ００～Ｕ１９のインデックスに対応するデータ（前半部）を送信する。一方、ハイバンドでは、順序を変えることなく、図８（Ｄ）に示すＵ００～Ｕ１９のインデックスに対応するデータ（前半部）を先に送信し、その後Ｖ００～Ｖ１９のインデックスに対応するデータ（後半部）を送信する。

これによれば、受信側の携帯端末２００において、上記実施の形態における１周期分の通信の半分（通信の前半）、すなわち、ローバンドでＶ００～Ｖ１９のインデックスに対応するデータ（後半部）を受信し、ハイバンドでＵ００～Ｕ１９のインデックスに対応するデータ（前半部）を受信した時点で、１周期分のデータ（１パケット）を受信できたことになる。そのため、残りの音声信号の受信・復調などが不用となる。また、通信の前半で、例えば、バースト性のノイズにより、両方の帯域における伝送が不能となった場合でも、例えば、通信の後半に、ハイバンドで受信したＶ００～Ｖ１９のインデックスに対応するデータ（後半部）と、ローバンドにおいて受信したＵ００～Ｕ１９のインデックスに対応するデータ（前半部）と、から正しく受信データを復元することができる。さらに、通信の前半と後半を通して、ローバンドとハイバンドのどちらか一方の帯域における伝送が不能となった場合でも、正常に伝送できるどちらか一方のバンドのみで正しく受信データを復元することができる。

このように、２つの帯域を使用して音声信号を出力する場合、上記実施の形態における１周期分の通信の半分（通信の前半）で１周期分の音声信号を受信することが可能となる。そして、このような２つの帯域を使用して音声信号が出力される場合において、携帯端末２００では、さらに、上記実施の形態における図１１のステップＳ２０５～Ｓ２０８の処理を行うことにより、１周期分の通信の半分（通信の前半）の音声信号を受信するまでもなく、１周期分のデータ（１パケット）の復号および誤り訂正が可能となる。したがって、さらなる処理時間の短縮化が可能となる。

また、上記実施の形態では、図６のステップＳ１０４の処理において、図８に示すように、Ｕ００のパンクチャード符号に対応するインデックスのデータ（Ｕ００のグループのデータ）、Ｕ０２のパンクチャード符号に対応するインデックスのデータ（Ｕ０２のグループのデータ）、Ｕ０１のパンクチャード符号に対応するインデックスのデータ（Ｕ０１のグループのデータ）、Ｕ０３のパンクチャード符号に対応するインデックのデータ（Ｕ０３のグループのデータ）、といったように符号化レートの高い順にインタリーブするとともに、各グループのデータについて、Ｕ００、Ｕ０４、Ｕ０８、Ｕ１２、Ｕ１６やＵ０２、Ｕ０６、Ｕ１０、Ｕ１４、Ｕ１８のようにインデックス値が低い方から高い方へと単調増加するようにインタリーブする例を示した（Ｖ００～Ｖ１９のインデックスに対応するデータについても同様）が、これは一例である（図１８（Ａ）参照）。

図６のステップＳ１０４の処理では、Ｕ００のグループのデータ、Ｕ０２のグループのデータ、Ｕ０１のグループのデータ、Ｕ０３のグループのデータといったように符号化レートの高い順にインタリーブするとともに、各グループのデータについて、例えば、図１８（Ｂ）に示すように、Ｕ００のグループのデータについてＵ００、Ｕ１２、Ｕ０４、Ｕ１６、Ｕ０８、といった順に、Ｕ０２のグループのデータについて、Ｕ０２、Ｕ１４、Ｕ０６、Ｕ１８、Ｕ１０といった順に、１つ飛ばしでインタリーブしてもよい（Ｖ００～Ｖ１９についても同様）。すなわち、各グループ同士でそれぞれのデータが共通した順序で配列されていれば、それぞれのデータの配列順序は任意である。

また、上記実施の形態では、チェックイン操作によりポイントを加算する例を示したが、これは一例である。例えば、上記実施の形態における通信端末１００をバスの車内に配置し、乗客が乗車した際に当該通信端末１００から出力された音声を乗客の携帯端末２００により受信することで、定額の乗車代金の支払いを行うようにしてもよい。この場合、上記実施の形態におけるポイントサーバ３００とは異なる代金支払いサーバを設け、ポイント加算とは逆に、乗車代金を現在の合計金額から減算するようにすればよい。この他にも映画館など料金が定額である場合の支払において、同様に適用可能である。

また、例えば、時間経過とともに異なる料金設定となっている店舗や施設においても適用可能である。具体的に、午前と午後とで利用料金が異なるレンタル会議室（なお、午前は３時間２０００円、午後は３時間３０００円といった固定の時間における料金が設定されており、延長できないものとする）において、午前中は図１５（Ａ）に示す送信データ１に対応する音声信号を出力し、午後になったタイミングで送信データ２に対応する音声信号を出力するといったように、所定のタイミングで出力する音声信号を切り替えることで、時間経過とともに異なる料金設定がなされている場合においても適用可能である。この場合においても、上記実施の形態におけるポイントサーバ３００とは異なる代金支払いサーバを設け、ポイント加算とは逆に、利用料金を現在の合計金額から減算するようにすればよい。なお、出力する音声信号に当該料金の情報を含めて出力してもよい。また、それとは別に、出力する音声信号には午前であるか午後であるかを示す料金種別情報を含めて出力し、代金支払いサーバ側で午前と午後のそれぞれの料金を記憶しておき、受信した料金種別情報に応じて利用料金を現在の合計金額から減算するようにしてもよい。

上記実施の形態では、携帯端末２００がスマートフォンであったが、本発明はこれに限られない。携帯端末２００は、音声を集音するマイクを備える他の機器であってもよく、例えば、ＩＣレコーダ、スマートウォッチのようなウェアラブルデバイスであってもよい。

上記実施の形態では、通信端末１００の記憶部１３０、携帯端末２００の記憶部２４０及びポイントサーバ３００の記憶部３１０が各種データを記憶していたが、本発明はこれに限定されない。例えば、上記の処理で用いる各種データは、その全部又は一部が通信ネットワークを介して外部のサーバやコンピュータ等に記憶されてもよい。

上記実施の形態では、通信端末１００、携帯端末２００及びポイントサーバ３００は、記憶部１３０、２４０、３１０に記憶されたプログラムに基づいて動作していたが、本発明はこれに限定されない。例えば、プログラムにより実現された機能的な構成をハードウェアにより実現してもよい。

上記実施の形態では、通信端末１００、携帯端末２００及びポイントサーバ３００が実行する処理は、上述の物理的な構成を備える装置が記憶部１３０、２４０、３１０に記憶されたプログラムを実行することによって実現されていたが、本発明は、プログラムとして実現されてもよく、そのプログラムが記録された記憶媒体として実現されてもよい。

また、上述の処理動作を実行させるためのプログラムを、フレキシブルディスク、ＣＤ－ＲＯＭ（Compact Disk Read-Only Memory）、ＤＶＤ（Digital Versatile Disk）、ＭＯ（Magneto-Optical Disk）等のコンピュータにより読み取り可能な記録媒体に格納して配布し、そのプログラムをコンピュータにインストールすることにより、上述の処理動作を実行する装置を構成してもよい。

上記実施の形態は例示であり、本発明はこれらに限定されるものではなく、特許請求の範囲に記載した発明の趣旨を逸脱しない範囲でさまざまな実施の形態が可能である。各実施の形態や変形例で記載した構成要素は自由に組み合わせることが可能である。また、特許請求の範囲に記載した発明と均等な発明も本発明に含まれる。

１通信システム
２通信ネットワーク
１００通信端末
１１０，２１０操作部
１２０発音部
１２１スピーカ
１３０，２４０，３１０記憶部
１３１プログラム
１３２ＦＨパターン
１４０変調部
１７０，２６０，３３０通信部
１８０，２７０，３４０制御部
１８１音声信号生成部
２００携帯端末
２２０表示部
２３０集音部
２３１マイク
２４１ユーザＩＤ
２５０復調部
３００ポイントサーバ
３１１ポイント記憶部
３４１ポイント加算部

Claims

送信端末から繰り返し周期的に出力される音声信号を通信データとして、任意のタイミングから順次受信する受信手段と、
前記受信手段で受信した一周期分または一周期の一部分の前記通信データを、前記受信した通信データにおける前記一周期の先頭位置に基づいて、前記一周期の前記音声信号に対応する通信データの対応位置へと配置する配置手段と、を備え、
前記配置手段は、前記受信した音声信号における前記一周期分の通信データにおける前記一周期の先頭位置を特定し、前記送信端末から前記一周期分の前記音声信号の出力が開始されてから前記一周期分の前記音声信号の出力が終了するまでの期間に前記受信手段により前記音声信号の受信を開始した場合、前記受信手段により順次受信した前記通信データを、前記先頭位置が先頭となる前記一周期の通信データの対応位置へと順次配置することにより、前記周期的に出力された音声信号の前記一周期分の前記通信データを生成する、
ことを特徴とする通信端末。
受信手段が、送信端末から繰り返し周期的に出力される音声信号を通信データとして、任意のタイミングから順次受信する受信ステップと、
配置手段が、前記受信ステップで受信した一周期分または一周期の一部分の前記通信データを、前記受信した通信データにおける前記一周期の先頭位置に基づいて、前記一周期の前記音声信号に対応する通信データの対応位置へと配置する配置ステップと、を備え、
前記配置ステップでは、前記受信した音声信号における前記一周期分の通信データにおける前記一周期の先頭位置を特定し、前記送信端末から前記一周期分の前記音声信号の出力が開始されてから前記一周期分の前記音声信号の出力が終了するまでの期間に前記受信ステップにより前記音声信号の受信を開始した場合、前記受信ステップにより順次受信した前記通信データを、前記先頭位置が先頭となる前記一周期の通信データの対応位置へと順次配置することにより、前記周期的に出力された音声信号の前記一周期分の前記通信データを生成する、
ことを特徴とする通信方法。
コンピュータを、
送信端末から繰り返し周期的に出力される音声信号を通信データとして、任意のタイミングから順次受信する受信手段、
前記受信手段で受信した一周期分または一周期の一部分の前記通信データを、前記受信した通信データにおける前記一周期の先頭位置に基づいて、前記一周期の前記音声信号に対応する通信データの対応位置へと配置する配置手段、として機能させ、
前記配置手段は、前記受信した音声信号における前記一周期分の通信データにおける前記一周期の先頭位置を特定し、前記送信端末から前記一周期分の前記音声信号の出力が開始されてから前記一周期分の前記音声信号の出力が終了するまでの期間に前記受信手段により前記音声信号の受信を開始した場合、前記受信手段により順次受信した前記通信データを、前記先頭位置が先頭となる前記一周期の通信データの対応位置へと順次配置することにより、前記周期的に出力された音声信号の前記一周期分の前記通信データを生成する、
ことを特徴とするプログラム。