まず、この実施の形態に係る通信システム1について、図1を参照して説明する。この実施の形態における通信システム1は、携帯端末200を所有するユーザが当該店舗(図示する例では所定の空間S)に来店した際(チェックインした際)に、当該ユーザがアプリケーション(携帯端末200に予めインストールされているものとする)を起動することにより、通信端末100から出力される音声信号を受信して当該ユーザにポイントを加算するシステムである。なお、この実施の形態における通信システム1は、ユーザがアプリケーションを起動したタイミング、すなわち通信端末100から出力されている音声信号の受信開始タイミングによって生じる解析時間のばらつきを防止することができるとともに、出力された音声信号(通信データ)の先頭から末尾までといった1周期分のデータを受信せずとも(例えば80%分の受信であっても)、当該音声信号(通信データ)を解析することができるものとなっている。以下、このような通信システム1について説明する。なお、この実施の形態では、通信方式として高速周波数ホッピング方式(Fast Frequency Hopping;以下、FFH方式と言う)を採用しているが、あくまでも一例であり、その他の通信方式を採用してもよい。
図1に示すように、通信システム1は、通信端末100と、携帯端末200と、ポイントサーバ300と、を備えている。通信端末100は、所定の空間S、例えば、店舗内部に配置され、通信端末100と携帯端末200とは、所定の空間S内で音声を伝送媒体として通信を行う。携帯端末200とポイントサーバ300とは、インターネット等の通信ネットワーク2を介してデータを送受信する。
図2は、通信端末100の構成を示すブロック図である。通信端末100は、当該来店客にポイントを加算するための音声信号の出力を行う端末であり、例えば、商品の決済処理を行う店舗端末や、リーダライタなどである。リーダライタは、ユーザがIC(Integrated Circuit)チップを有するICカード、通信端末等の物体を近接させると当該ICチップに記憶されたデータを読み取り、書き込み(読み書き処理)を行う装置である。なお、当該通信端末100は、店舗端末やリーダライタなどの、決済処理やデータの読み書き処理を行う機能を有する端末とは別の、来店客にポイントを加算するための音声信号を出力する機能を備えた専用端末であってもよく、以下では、理解を容易にするため、当該通信端末100が当該専用端末である場合を例に説明する。
通信端末100は、操作部110と、発音部120と、記憶部130と、変調部140と、通信部170と、制御部180と、を備えている。通信端末100の各部は、内部バスを介して相互に通信可能に接続されている。なお、図示は省略しているが、通信端末100は、マイクを含む集音部を備えていてもよい(後述する携帯端末200が備える集音部230及びマイク231と同一又は同等の構成であればよい)。なお、当該通信端末100は、操作部110を備えていなくてもよい。
操作部110は、ユーザの操作を受け付け、受け付けた操作に対応する操作信号を制御部180に供給する。操作部110は、例えば、音量調節スイッチ、タッチパネル等を含む。また、操作部110は、例えば、USB(Universal Serial Bus)ケーブルにより通信端末100の本体に接続された外付けのテンキー(図示省略)であってもよい。
発音部120は、スピーカ121を含み、変調部140から供給された音声信号をD/A(デジタル/アナログ)変換し、スピーカ121に供給する。これにより、デジタル音声信号が、空気振動(音)に変換され、出力される。なお、この実施の形態では、非可聴帯域の音声信号を出力することにより、人間にはほぼ聞こえないものとなっている。これは、可聴帯域の音声信号が出力されることによりユーザに不快感を与えることを防止するためである。
記憶部130は、例えば、RAM(Random ACCESS Memory)、ROM(Read Only Memory)、フラッシュメモリ、ハードディスク等を含む。記憶部140は、制御部180にて実行されるプログラム131や周波数ホッピングのホッピングパターンを示すFHパターン132、各種の情報(図示省略)を記憶する。また、記憶部130は、制御部180が動作するためのワークメモリとして機能する。
変調部140は、制御部180の制御に従って、当該制御部180により生成された、送信対象のデータであるビット列データを音声信号に変換する。より詳細に説明すると、変調部140は、制御部180から供給されたビット列データで搬送波を変調し、変調された搬送波(音声信号)を発音部120に出力する。なお、変調部140にて実行される音声信号の変調の処理は、有線通信や無線通信で用いられている一般的な処理と同様の処理であればよい。この実施の形態では、通信方式としてFFH方式を採用しているため、変調部140は、制御部180から供給されたビット列データを狭帯域変調によって変調(一次変調)してから(中間周波数信号としてから)、1パケット区間を複数のシンボルに分け、シンボル毎に異なる周波数に拡散する変調(二次変調)を行う処理が行われればよい。なお、1パケット区間に何個の周波数をどの順で順次出力するか(ホッピングパターン)については、FHパターン132に基づいて行われる。
通信部170は、制御部180の制御に従って、携帯端末200との間で無線信号を送受信することが可能なインターフェースである。
制御部180は、CPU(Central Processing Unit)等を備え、記憶部130に記憶されているプログラム131を実行することにより、図5に示す音声信号出力処理や、図6に示す音声信号生成処理を実行する。制御部180は、音声信号を生成する機能としての音声信号生成部181を備えている。
音声信号生成部181は、来店客にポイントを加算するための音声信号を生成するための機能部である。この実施の形態における音声信号生成部181は、送信対象のデータに基づいて、音声通信により携帯端末200に出力する送信情報をビット列データとして生成し、変調部140へ出力する。送信対象のデータは、来店客に対してポイントの加算を許可する情報である。なお、音声信号生成部181は、送信対象のデータに対し、例えばCRC(Cyclic Redundancy Check)の付与、畳み込み符号化、インタリーブなどの処理を行う。
以上が、通信端末100の構成である。なお、この他にも現在時刻を計測する計時部を備えていてもよく、計時部は、現在時刻を計測するRTC(Real Time Clock)を備えていればよい。RTCは、例えば、電池を内蔵し、通信端末100の電源がオフの間も計時を継続すればよい。そして、当該計時部により計測された現在時刻であるRTC時刻を示す情報についても、送信対象のデータとして携帯端末200へ音声信号として出力されてもよい。
図3は、携帯端末200の構成を示すブロック図である。携帯端末200は、例えば、スマートフォンであり、通信端末100から出力された音声信号を受信してポイントサーバ300へポイントの加算を要求する端末である。携帯端末200は、操作部210と、表示部220と、集音部230と、記憶部240と、復調部250と、通信部260と、制御部270と、を備えている。携帯端末200の各部は、内部バスを介して相互に通信可能に接続されている。なお、図示は省略しているが、携帯端末200は、スピーカを含む発音部を備えていてもよい(通信端末100が備える発音部120及びスピーカ121と同一又は同等の構成であればよい)。
操作部210は、ユーザの操作を受け付け、受け付けた操作に対応する操作信号を制御部270に供給する。表示部220は、制御部270から供給されるデータに基づいて各種の画像、画面等を表示する。操作部210と表示部220とは、タッチパネルによって一体に構成されている。タッチパネルは、ユーザによる所定の操作を受け付ける操作画面を表示すると共に、操作画面においてユーザが接触操作を行った位置に対応する操作信号を制御部270に供給する。
集音部230は、マイク231を含み、当該通信端末100から出力された音声信号を受信し、受信した音声信号をA/D(アナログ/デジタル)変換し、復調部250へ供給する。
記憶部240は、例えば、RAM、ROM、フラッシュメモリ、ハードディスク等を含む。記憶部250は、記憶部140は、制御部270に実行されるプログラム(図示省略)やユーザ毎に割り振られたユーザID241、通信端末100に記憶されているものと同一のFHパターン132、各種の情報(図示省略)を記憶する。を含む。また、記憶部240は、制御部270が動作するためのワークメモリとしても機能する。
復調部250は、集音部230から供給された音声信号を復調する。なお、復調部250にて実行される音声信号の復調の処理は、有線通信や無線通信で用いられている一般的な処理と同様の処理であればよい。上述したように、この実施の形態では、通信方式としてFFH方式を採用しているため、復調部250は、集音部230から供給された音声信号から、送信側と同じホッピングパターンに基づいて、一次変調出力の中間周波数信号を取り出し、これをさらに復調してビット列データへと戻す処理が行われればよい。
通信部260は、制御部270の制御に従って、例えば、通信端末100、ポイントサーバ300との間で無線信号を送受信することが可能なインターフェースである。
制御部270は、CPU等を備え、携帯端末200の各部の制御を行う。制御部270は、記憶部240に記憶されているプログラムを実行することにより、図10の携帯端末の処理を実行する。具体的に、制御部270は、通信端末100から出力された音声信号を解析し、ポイントサーバ300に対してポイントの加算を要求する処理(ポイント加算要求を送信する処理)を行う。ポイント加算要求には、当該携帯端末200のユーザを特定するユーザID241を示す情報と、ポイントの加算を許可することを示す情報(通信端末100から出力された音声信号に含まれる情報)が含まれていればよい。なお、当該通信端末100から出力された音声信号にRTC時刻が含まれている場合には、当該RTC時刻をポイント加算要求に含めてポイントサーバ300に対して送信すればよい。
以上が、携帯端末200の構成である。
図4(a)は、ポイントサーバ300の構成を示すブロック図である。ポイントサーバ300は、例えば、サーバ等の汎用コンピュータである。ポイントサーバ300は、携帯端末200からの要求に応じてポイントを加算する処理を行うサーバである。当該ポイントサーバ300は、図示するように、記憶部310と、通信部330と、制御部340と、を備えている。ポイントサーバ300の各部は、内部バスを介して相互に通信可能に接続されている。
記憶部310は、例えば、RAM、ROM、フラッシュメモリ、ハードディスク等を含む。記憶部310は、制御部340に実行されるプログラムや各種のデータ、加算ポイントの値等を記憶する。加算ポイントは、チェックイン毎にユーザの合計ポイントに加算されるポイントであり、当該加算ポイントの値は、管理者によって予め設定されている。また、記憶部310は、制御部340が動作するためのワークメモリとしても機能する。さらに、記憶部310は、ポイント記憶部311を有する。
図4(b)は、ポイント記憶部311のデータテーブルの一例を示す図である。ポイント記憶部311は、ユーザID、加算ポイント及び合計ポイントに関する情報を記憶する。なお、例えば、通信端末100から出力された音声信号にRTC時刻が含まれている場合、すなわち音声信号出力時の時刻が含まれている場合には、携帯端末200から送信されるポイント加算要求に当該RTC時刻が含まれているため、ポイント加算時において当該RTC時刻(音声信号出力時の時刻)を、ポイント記憶部311のデータテーブルに登録するようにしてもよい。これによれば、いつ出力された音信号声によりポイントが加算されたかといったことの解析が可能となる。これに加え、ポイントサーバ300自体が計時部(通信端末100の計時部と同様の構成であればよい)を備え、ポイント加算時において当該ポイントサーバ300の計時部にて計測したRTC時刻(ポイント加算時の時刻)を、ポイント記憶部311のデータテーブルにさらに登録するようにしてもよい。これによれば、音声信号出力時の時刻に加え、ポイント加算時の時刻が登録されることから、これらの差が予め定められた閾値以上の場合にはポイントを加算しないなど、不正なポイント加算要求を防止することができる。
通信部330は、制御部340の制御に従って、例えば携帯端末200との間で無線信号を送受信することが可能なインターフェースである。
制御部340は、CPU等を備え、ポイントサーバ300の各部の制御を行う。制御部340は、記憶部310に記憶されているプログラムを実行することにより図10に示すポイントサーバの処理を実行する。制御部340は、機能的に、ポイント加算部341を備えている。
ポイント加算部341は、携帯端末200から送信されたポイント加算要求に含まれるユーザIDに対応する合計ポイントをポイント記憶部311から読み取り、読み取られた合計ポイントに、ポイント記憶部311に記憶された加算ポイントを加算して、当該記憶部310のデータテーブルを更新する。なお、この実施の形態では、通信端末100から出力される音声信号にはポイントの加算を許可する情報が含まれ、当該情報により、ポイントサーバ300に記憶された加算ポイントが加算される例を示したが、通信端末100から出力される音声信号に、加算するポイント数の情報(加算ポイント数情報)を含めるようにしてもよい。そして、携帯端末200にて、ポイント加算要求に当該加算ポイント数情報を含め、ポイントサーバ300において当該ポイント加算要求に含まれる加算ポイント数のポイントを加算するようにしてもよい。これによれば、店舗側で加算するポイントを独自に変更可能となる。したがって、例えば、店舗独自のキャンペーンを行う場合など、店舗独自のサービスの提供が容易になる。
以上が、ポイントサーバ300の構成である。
次に、通信システム1の動作について説明する。
まず、通信端末100の動作について、図5~図9を参照して説明する。図5は、通信端末100が実行する音声信号出力処理の一例を示すフローチャートである。この実施の形態では、例えば、開店時において店員などの店舗側ユーザの操作部110への操作が行われることにより、記憶部130に記憶されているプログラム131が実行され、当該音声信号出力処理の実行が開始される。また、当該音声信号出力処理は、閉店時において店舗側ユーザの操作部110への操作が行われることで終了する。なお、例えばタイマ設定により開始と終了が自動で制御されてもよい。すなわち、この実施の形態では、音声信号出力処理が一旦実行された後は、店舗側ユーザによる終了操作が行われるまで、当該音声信号出力処理(より具体的にはステップS12の音声信号の出力の処理)が継続して行われる。
音声信号出力処理の実行を開始すると、まず、制御部180は、音声信号生成部181の機能により、音声信号生成処理を行う(ステップS11)。図6は、図5のステップS11の処理にて実行される音声信号生成処理の一例を示すフローチャートである。図6に示す音声信号生成処理において、制御部180は、まず、送信対象データを生成する(ステップS101)。ステップS101では、来店客に対してポイントの加算を許可する情報を送信対象のデータとして、ビット列データを生成する。
ステップS101の処理を実行した後、制御部180は、当該ビット列データに対し、CRCの付与や暗号化などといった暗号化等前処理を行う(ステップS102)。
続いて制御部180は、暗号化等前処理を行った後のビット列データに対し、畳み込み符号化処理を施す(ステップS103)。この実施の形態におけるステップS103では、図7に示す拘束長7の畳み込み符号器による演算を行うことにより当該ビット列データを畳み込み符号化すればよい。なお、ステップS103における符号化は、畳み込み符号による符号化に限定されず、例えば、BCH(Bose-Chaudhuri-Hocquenghem)符号、RS(Reed-Solomon)符号、ターボ符号、LDPC(Low Density Parity Check)などの符号化方式であってもよい。
図6のステップS103の処理を実行した後、制御部180は、符号化レートの高いパンクチャード符号に対応するデータが先に出力されるよう、当該符号化レートの高い順にデータをインタリーブし(ステップS104)、変調部140に当該インタリーブ後のデータを供給する。
当該インタリーブ後のデータが供給されると、変調部140では、当該インタリーブ後のデータを変調する処理や、ウィンドウの追加などの変調等後処理を行い(ステップS105)、変調後のデータを発音部120へと供給し、音声信号生成処理を終了する。
続いて、図8を参照して、当該音声信号生成処理の具体例を説明する。図示するように、図6のステップS101及びステップS102の処理が実行された後のビット列データが図8(A)に示すデータである場合を例に説明する。なお、この例では、理解を容易にするため、図示するようにビット列データにはG00~G13といったインデックス値を付加している。
図6のステップS103の処理において、まず、畳み込み符号におけるシフトレジスタの最終値を「0」に戻すため、拘束長-1に対応するダミーデータを付加する。具体的に、拘束長は7であることから、図8(B)に示すようにダミーデータとして6個の「0」を付加する(図示するG14~G19のインデックスに対応するデータ)。続いて図6のステップS103の処理において、図8(B)に示すデータを畳み込み符号化して、図8(C)に示すようにU00~U19のインデックスに対応するデータとV00~V19のインデックスに対応するデータとを生成する。
次に、図6のステップS104の処理を実行することで、図8(C)に示すデータを図8(D)に示すようにインタリーブする。上述したように、ステップS104の処理では、符号化レートの高いパンクチャード符号に対応するグループのデータが先に出力されるよう、当該符号化レートの高い順にインタリーブされる。図示する例では、U00、U04、U08、U12、U16といったU00のパンクチャード符号に対応するグループのデータが最も符号化レートが高く、次いでU02、U06、U10、U14、U18といったU02のパンクチャード符号に対応するグループのデータが高く、続いてU01、U05、U09、U13、U17といったU01のパンクチャード符号に対応するグループのデータと、U03、U07、U11、U15、U19といったU03のパンクチャード符号に対応するグループのデータとなっている。そのため、図8(D)に示すように、U00のインデックスに対応するグループのデータを先頭に配置し、次いでU02のインデックスに対応するグループのデータ、その次にU01のインデックスに対応するグループのデータ、その後U03のインデックスに対応するグループのデータ、といった順にインタリーブしている。なお、図8(D)に示すように、V00~V19のインデックスに対応するデータも、U00~U19と同様の順にインタリーブされればよい。具体的に、U00~U03、V00~V03のビットデータを例に説明すると、符号化レート4/4(当該符号化レート4/4の例は、訂正能力が低いため、一般に知られた符号化レートの名称ではないが、この実施の形態ではパンクチャード符号の一つとして扱うものとしている)の場合には、パンクチャード処理によりV00~V04のビットデータが間引かれ、符号化レート4/5の場合には、パンクチャード処理によりV01~V03のビットデータが間引かれ、符号化レート2/3の場合には、パンクチャード処理によりV01とV03のビットデータが間引かれ、符号化レート1/2の場合には、いずれのビットデータも間引かれないこととなる。すなわち、符号化レートが下がるに従って、間引かれるビットデータが少なくなる。なお、符号化レート3/4の場合には、U00~U02、V00~V02のビットデータについて、パンクチャード処理によりV01とU02のビットデータが間引かれることとなる。この実施の形態では、符号化レート3/4の場合、他の符号化レートの場合と比較して周期が変わってしまうため、符号化レート4/4、4/5、2/3、および1/2におけるU00~U03、V00~V03のビットデータを用いて説明する。U00~U03、V00~V03のビットデータを、符号化レートの高い順に並べると、U00~U03(符号化レート4/4)、V00(符号化レート4/5)、V02(符号化レート2/3)、V01、V03(符号化レート1/2)となる。そして、UとVとの対称性を考慮し、U0~U3を、V0~V3と同様の順(V00、V02、V01、V03の順)に並べると、U00、U02、U01、U03となる。すなわち、符号化率が高く、間引かれる割合が高い符号のビットが先に送信され、符号化率が低く、間引かれる割合が低い符号のビットのうち、未送信のビットが続けて送信されるよう並べられる。そして、U04~U07、V04~V07についてもU00~U03、V00~V03と同様であり、U00やV00に対応するビットデータの集まりを、それぞれU00のパンクチャード符号に対応するグループのデータ、V00のパンクチャード符号に対応するグループのデータと呼ぶ(U01~U03、V01~V03についても同様)。このことから、図8(D)に示すように、U00、U04、U08、U12、U16といったU00のパンクチャード符号に対応するグループのデータ、次いでU02、U06、U10、U14といったU02のパンクチャード符号に対応するグループのデータ、続いてU01、U05、U09、U13といったU01のパンクチャード符号に対応するグループのデータ、U03、U07、U11、U15、U19といったU03のパンクチャード符号に対応するグループのデータ、の順に出力されるようインタリーブされることとなる。
そして、図8(D)に示すように、U00~U19、次いでV00~V19のインデックスに対応するデータが、図5のステップS12の処理により音声信号として順次出力され、1パケット分出力されることとなる。
図5に戻り、ステップS11における音声信号生成処理を実行した後、制御部180は、ステップS11により発音部120へと供給された変調後のデータをD/A変換してスピーカ121に供給することにより、音声信号を出力する(ステップS12)。
上述したように、この実施の形態では、店舗側ユーザによる終了操作が行われるまで、当該音声信号出力処理は終了しない。そのため、一旦ステップS11の処理が行われた後は、図示するように、当該終了操作が行われるまで、ステップS12の処理が繰り返し実行され、ステップS11にて生成された音声信号が繰り返し出力される。なお、ステップS12の処理が実行され音声信号が出力された後、再度ステップS12の処理が実行され再び音声信号が出力されるまでの期間は、1パケット区間よりも十分に短い時間となっている。すなわち、1パケットの音声信号が出力されてから、再度1パケットの音声信号が出力されるまでのインターバル期間が1パケット区間よりも十分に短い時間となっており、1パケットの音声信号が出力されてから連続的に次の1パケットの音声信号が出力される。なお、この実施の形態では、理解を容易にするため、1パケットの音声信号の出力が完了した後に、次の1パケットの音声信号が出力される例を示しているが、例えば、1パケットの音声信号の出力中に、次の1パケットの音声信号を重ねて出力してもよい。具体的に、1周期(1パケット)の音声信号を出力する場合において、当該出力中の1パケットの音声信号における最後の部分のシンボルの出力に重ねて、次の1パケットの最初の部分のシンボルを出力してもよい。すなわち、パケット周期の誤差が1シンボル長に比べて十分小さければよく、連続的の概念には、1パケットの音声信号の出力が完了した後に次の1パケットの音声信号が連続して出力されることに加え、1パケットの出力に重ねて次の1パケットの音声信号が出力されることも含まれる。
このように、図5のステップS12の処理が繰り返し実行されることで、図8に示すU00~V19のインデックスに対応するデータが、音声信号として図9に示すように繰り返し出力されることとなる。なお、この実施の形態では、図示するように、1周期、すなわち1パケットの音声信号出力期間が2.4秒間となっている。店舗に来店した顧客側ユーザは、来店に伴い携帯端末200にインストールされているアプリケーションを起動させることで、当該繰り返し出力される音声信号を受信して、ポイントを加算する。また、この実施の形態では、理解を容易にするため、出力される音声は固定のデータ長であり、当該データ長が送信側と受信側とにおいて予め設定されているものとする。そのため、受信側では、未受信部分がどの程度の長さであるかが特定できるものとなっている。また、出力される音声は可変長のデータ長であってもよく、その場合には、例えばヘッダを作成し、当該ヘッダ部分にデータ長を示す情報を含めて出力すればよい。受信側では、当該ヘッダ部分に含まれるデータ長により当該出力される音声のデータ長を特定し、未受信部分がどの程度の長さであるかを特定すればよい。
次に、携帯端末200の動作(ポイントサーバ300の動作も含む)について、図10~図14を参照して説明する。図10は、携帯端末200が実行する携帯端末の処理の一例(ポイントサーバ300が実行するポイントサーバの処理の一例も含む)を示すフローチャートである。当該携帯端末の処理は、顧客側ユーザによる操作部210への操作によりアプリケーションが起動することで実行を開始する。
携帯端末の処理の実行を開始すると、まず、制御部270は、顧客側ユーザによる操作部210の操作を受け付ける(ステップS21)。具体的に、ステップS21では、例えば、顧客側ユーザによる来店ポイント加算操作(チェックイン操作)を受け付ける。当該来店ポイント加算操作は、例えば、起動したアプリケーションにより表示された来店ポイント加算の項目を選択する操作であればよい。
ステップS21の処理が行われると、制御部270は、集音部230に含まれるマイク231を起動して(ステップS22)、通信端末100からの音声信号の受信を開始する(ステップS23)。通信端末100から音声信号の受信を開始すると、制御部270は、受信した音声信号を復号する受信音声復号処理を実行する(ステップS24)。
図11は、図10のステップS24にて行われる受信音声復号処理の一例を示すフローチャートである。図11に示す受信音声復号処理において、制御部270は集音部230を制御して、通信端末100から音声信号を受信する(ステップS201)。ステップS201では、例えば、記憶部240に記憶されているFHパターン132に従って受信周波数を有効化し音声信号を受信する。なお、受信した音声信号は、当該集音部230によりA/D変換され、復調部250へ供給される。
ステップS201の処理を実行した後、制御部270は、復調部205の機能により、受信した音声信号を復調する処理や、不要な情報を削除することにより必要な情報を取得する処理を行う復調等前処理を行い(ステップS202)、受信データとしてのビット列データ(図13参照)を制御部270へ供給する。
ステップS202の処理を実行した後、制御部270は、音声信号における先頭位置を特定する(ステップS203)。具体的に、ステップS203の処理では、例えば、受信した音声信号のホッピングパターンと記憶部240に記憶されているFHパターン132とを照合し、受信した音声信号が当該1パケットにおけるいずれのシンボルに対応する音声信号であるかを判定することで、当該1周期の音声信号における先頭(1パケット中の先頭)の位置を特定する(1周期の音声信号における後半部を受信した場合には、末尾の位置を先頭の位置とする)。なお、ステップS203の処理では、例えば、受信した音声信号のシンボルから当該1周期の音声信号の先頭までの距離と、当該シンボルから末尾までの距離のうち、距離の短い方を先頭の位置として特定すればよい。すなわち、前半部を受信した場合には当該受信した音声信号に対応する先頭部分を先頭位置として特定し、後半部を受信した場合には当該受信した音声信号に対応する末尾部分を、1周期の音声信号の先頭位置として特定すればよい。なお、ステップS202の処理により1周期の音声信号における先頭(1パケット中の先頭)の位置が一旦特定された後は、当該受信音声復号処理が終了するまで、ステップS203の処理をスキップすればよい。
ステップS203の処理を実行した後、制御部270は、当該ステップS203の処理で特定した先頭位置に基づいて、ステップS201の処理で受信した音声信号を、当該1周期の音声信号における対応位置へ配置する(ステップS204)。具体的に、ステップS204の処理では、ステップS203の処理で特定した先頭位置を基準とした1周期の音声信号(1パケットのビット列データ)のうちの対応するシンボルへ、当該ステップS202にて取得したビット列データを配置する(図12参照)。すなわち、ステップS204の処理では、後半部、前半部、後半部といった順に受信した場合には、ステップS203の処理において、最初に受信される後半部と、次に受信される前半部との間が先頭位置であると特定されるため、最初に受信した後半部が最後に受信した後半部の後に付加されるように、また、前半部、後半部、前半部といった順に受信した場合には、ステップS203の処理において、最初に受信される前半部より前の位置が先頭位置であると特定されるため、最後に受信した前半部が最初に受信した前半部の前に付加されるように、受信した音声信号の並び替えを行う。したがって、ステップS204の処理が繰り返し実行されることで、受信した音声信号が1周期の音声信号(1パケットのビット列データ)のうちの対応するシンボルへと順次配置されることから、いずれのタイミングで音声信号を受信した場合であっても(当該出力中の音声信号を途中から受信した場合であっても)、少なくとも1周期分の音声信号を受信することで、当該1周期分の音声信号を生成することができる。
続いて制御部270は、1周期の音声信号のうち、未だ受信していない未受信部分に中間値としての「0.5」をセットする(ステップS205)。具体的に、ステップS205の処理では、ステップS203の処理で特定した先頭位置を基準とした1周期の音声信号(1パケットのビット列データ)のうち、未だ受信していないシンボルに対応する部分に中間値として「0.5」を挿入する。なお、中間値に限られず、ダミーデータを挿入してもよい。なお、1シンボルが2ビットで構成される場合には、それぞれに中間値としての「0.5」を挿入すればよい。
ステップS205の処理を実行した後、制御部270は、当該中間値を挿入したビット列データに対し、図6のステップS104の処理におけるインタリーブとは逆の動作であるデインタリーブを行うことで(ステップS206)、データの並びを元に戻す。ステップS206の処理を実行した後、制御部270は、デインタリーブ後のデータについて、ビダビアルゴリズムにより、復号および誤り訂正処理を行い(ステップS207)、誤り訂正後のデータに含まれるCRCついてCRC判定を行う(ステップS208)。そして、CRC判定結果が正常であれば当該ステップS209においてYesと判定し、当該CRC判定結果が正常であるビット列データを正常なビット列データとして記憶し、全てのCRC判定結果が正常でない場合には、Noと判定すればよい。なお、ステップS207の処理では、図6のステップS103にて符号化されたビット列データを復号および誤り訂正処理できれば、ビダビアルゴリズムに限られない。
ステップS209においてCRC判定の判定結果が正常である場合には(ステップS209;Yes)、受信音声復号処理を終了する。一方、正常でない場合には(ステップS209;No)、ステップS201の処理に戻り、ステップS201~S209の処理を繰り返し実行する。
続いて、図12~図14を参照して、当該受信音声復号処理の具体例を説明する。この例では、図12(A)に示すタイミング(図示するアプリ起動のタイミング)で携帯端末200のアプリケーションが起動され、当該受信音声復号処理が開始されたものとする。また、理解を容易にするためこの例では、1周期の80%に対応する音声信号を受信した際に当該受信音声復号処理におけるステップS208にて正常と判定され、当該受信音声復号処理が終了する場合を例に以下説明する。
まず、図12を参照して当該受信音声復号処理の概要について説明する。まず、受信音声復号処理が開始されると、図11のステップS201の処理にて音声信号が受信される。例えば、現在の状況が図12(B)に示すように、出力された音声信号の後半部の音声信号のみを受信したような状況の場合、図11のステップS203の処理により、当該受信した後半部の末尾の位置を、1周期の音声信号における先頭位置として特定し、ステップS204の処理において、図12(C)に示すように、当該受信した後半部の音声信号が、1周期の音声信号における対応位置へと配置される。
そして、図11のステップS205の処理により、図12(C)に示す未受信部のシンボルに対応する部分に中間値として「0.5」が挿入される。その後、ステップS207およびステップS208の処理が実行されるものの、図12(B)および図12(C)に示す例の場合、受信した音声信号が少ないことから、エラー訂正に失敗し、CRCが不一致となり、図11のステップS209にてNoと判定されるため、ステップS201の処理が再度実行され、音声信号を再度受信することとなる。
続いて図12(D)に示すように、図12(B)に示す状態からさらに音声信号を受信し、1周期の80%に対応する音声信号を受信した場合、図11のステップS204の処理において、図12(B)に示す状態の後に受信した前半部の音声信号と、その後に受信した後半部の音声信号とが、図12(E)に示すように、それぞれ1周期の音声信号における対応位置へ配置される。このように、図11のステップS204の処理が繰り返し実行されることで、受信した音声信号が1周期の音声信号(1パケットのビット列データ)のうちの対応するシンボルへと順次配置されることから、いずれのタイミングで音声信号を受信した場合であっても(当該出力中の音声信号を途中から受信した場合であっても)、少なくとも1周期分の音声信号を受信すれば(図示する未受信部分も受信すれば)、当該ステップS204の処理により、当該1周期分の音声信号を生成することができることとなる。
そして、図11のステップS205の処理により、図12(E)に示す未受信部のシンボルに対応する部分に中間値として「0.5」が挿入され、ステップS207およびステップS208の処理が実行される。上述したように、この例では、1周期の80%に対応する音声信号を受信した際に当該受信音声復号処理におけるステップS209にてYesと判定されることから、これにより、当該受信音声復号処理が終了することとなる。
次に、図13~図14を参照して、当該受信音声復号処理におけるビット列データの具体例について説明する。なお、図示する例は、図12(D)に示すように図12(B)に示す状態からさらに音声信号を受信し、1周期の80%に対応する音声信号を受信した場合の例を示している。
まず、図11のステップS201の処理により、通信端末100から音声信号が順次受信され、図11のステップS202の処理が行われることで、図13(B)に示す受信データとしてのビット列データが順次制御部270へ供給される。なお、図13(A)は送信データを示しており、図8(D)に示すU00~V19のインデックスに対応するビット列データとなっている。また、図13に示す例では、図13(A)に示すビット列データを受信した際、エラーにより、図13(B)に示す2つのビットが反転しているものとする。
具体的に、図13(B)に示す例では、図8(D)に示すU00~V19のインデックスに対応するビット列データの後半部におけるV01~V19のインデックスに対応するデータを受信し、その後前半部におけるU00~U19のインデックスに対応するデータ、そして後半部におけるV00とV04のインデックスに対応するデータを受信し、V08~V18のインデックスに対応するデータは未受信である場合の例を示している。
そして、図11のステップS204の処理が行われることで、図13(C)に示すように、受信した前半部のビット列データと後半部のビット列データとが、それぞれ1周期のビット列データにおける対応位置へ配置され、図11のステップS205の処理が行われることで、図13(D)に示すように、未受信部分であるV08~V18のインデックスに対応するデータ部分に、中間値である「0.5」が挿入される。
続いて図11のステップS206の処理が行われることで、図13(D)に示すビット列データが、図13(E)に示すようにU00~U19のインデックスに対応するデータとV00~V19のインデックスに対応するデータとの並びに戻ることとなる。なお、図示する例では、理解を容易にするため、ビット列データにインデックス値を付与している。
そして、図11のステップS207の処理が行われることで、復号および誤り訂正が行われ、図14(G)に示すように、図8(A)と同様のビット列データとなる。なお、図14(F)における点線部分に示すように、符号化レートが2/3である場合と同様の符号パターンであることから、誤り訂正能力が高く、図11のステップS207の処理において行われた復号および誤り訂正処理の結果に含まれるCRCの判定結果が、図11のステップS208の処理にて正常と判定されることとなる。その結果として、図14(G)に示すように、図8(A)に示す1周期のビット列データに対応する送信データと同様のビット列データが取得されることとなる。
このように、この実施の形態によれば、図11のステップS203およびS204の処理により、アプリケーションを起動したタイミングが出力中の音声の中盤であった場合であっても、当該出力中の音声の次に出力される音声の先頭を待つことなく処理が可能となる。すなわち、いずれのタイミングでアプリケーションを起動した場合であっても処理が可能となり、処理時間を短縮化することができる。さらに、1周期分の音声を受信しなくとも(1周期分の受信を待つことなく)、図11のステップS205~S208により、1周期分の音声に復号および誤り訂正可能である。したがって、1周期分の音声を受信せずとも処理が可能となり、さらなる処理時間の短縮化が可能となる。
図10に戻り、ステップS24における受信音声復号処理を実行した後、制御部270は、ポイントサーバ300に対してポイントの加算を要求するポイント加算要求を送信する(ステップS25)。ステップS25では、記憶部240に記憶されているユーザID241を示す情報と、ポイントの加算を許可することを示す情報(通信端末100から出力された音声信号に含まれる情報)とを対応付けた情報を、ポイント加算要求としてポイントサーバ300に送信する。なお、ポイントの加算を許可することを示す情報は、ステップS24にて取得したビット列データから予め定められたビット列を抽出することにより取得すればよい。
ポイントサーバ300の側では、携帯端末200から送信されたポイント加算要求を受信すると、ポイントサーバの処理を開始する。なお、携帯端末200の側では、当該ポイントサーバ300へポイント加算要求を送信した後は、当該ポイントサーバ300からポイント加算処理の処理結果を受信するまで待機する。
ポイントサーバ300の制御部340は、ポイントサーバの処理を開始すると、まず、受信したポイント加算要求からユーザID241を特定する(ステップS31)とともに、ポイントの加算を許可することを示す情報が正常な情報であることを特定する(図示省略)。
ステップS31の処理を実行した後、制御部340は、ポイント加算部341の機能により、ステップS31の処理で特定したユーザIDのユーザのポイントを加算するポイント加算処理を実行し(ステップS32)、当該ポイント加算処理の処理結果を携帯端末200へ送信してから(図示省略)、ポイントサーバの処理を終了する。具体的に、ステップS31の処理では、ポイント記憶部311のデータテーブルに登録されている加算ポイントの値を合計ポイントの値に加算することで当該データテーブルを更新する処理を行う。そして、当該処理が正常に行われた場合には、その旨を示す成功結果を、合計ポイント値とともに携帯端末200へ送信する一方、エラーが生じた場合には、その旨を示す失敗結果を携帯端末200へ送信する。
携帯端末200の側では、ポイントサーバ300から送信されたポイント加算処理の処理結果を受信すると、表示部220に当該ポイント加算処理の処理結果を表示することで顧客側ユーザへチェックイン操作の終了を報知し(ステップS26)、携帯端末の処理を終了する。具体的に、ステップS26の処理では、例えば成功結果と合計ポイント値を受信した場合、当該チェックイン操作によりポイント値が加算されたことを示す成功表示を行うとともに、受信した合計ポイント値を表示する。一方、失敗結果を受信した場合には、当該チェックイン操作においてエラーが発生してポイント値が加算されていないことを示す失敗表示を行う。なお、当該失敗表示を行う場合には、再度チェックイン操作を行うことを促す促進表示を行うようにしてもよい。また、失敗結果を受信した場合、特に処理を行わなくてもよい。
以上が携帯端末200の動作(ポイントサーバ300の動作も含む)である。このように、この実施の形態における携帯端末200は、アプリケーションを起動したタイミングが出力中の音声の中盤であった場合であっても、当該出力中の音声の次に出力される音声の先頭を待つことなく、ポイントサーバ300へポイント加算要求を送信する。これにより、ポイントが加算されるまでの処理時間を短縮することができる。また、1周期分の音声を受信しなくとも(1周期分の受信を待つことなく)、ポイントサーバ300へポイント加算要求を送信することができるため、ポイントが加算されるまでの処理時間をさらに短縮することができる。
(変形例)
この発明は、上記の実施の形態に限定されず、種々の変形及び応用が可能である。上記実施の形態で示した全ての技術的特徴を備えるものでなくてもよく、従来技術における少なくとも1つの課題を解決できるように、上記実施の形態で説明した一部の構成を備えたものであってもよい。また、下記の変形例で示す構成をそれぞれ組み合わせてもよい。
上記実施の形態では、通信方式として高速周波数ホッピング方式(FFH方式)を採用した例を示したが、上述したように、その他の通信方式を採用してもよい。また、上記実施の形態では、通信端末100を送信側の端末、携帯端末200を受信側の端末として説明したが、これは一例である。例えば、携帯端末200を送信側の端末とし、通信端末100を受信側の端末としてもよい。また、通信端末100と携帯端末200が双方向に通信可能であり、通信端末100と携帯端末200のそれぞれが、送信側の端末としての機能と受信側の端末としての機能の両方を備えており、状況に応じて送信側と受信側とを切り替え可能としてもよい。さらに、上記実施の形態では、理解を容易にするため、通信端末100と携帯端末200との通信を例に説明したが、通信端末100同士、携帯端末200同士の通信であってもよい。すなわち、送信側の端末としての機能と受信側の端末としての機能を備えている端末同士における双方向の通信であってもよい。
上記実施の形態では、図11のステップS203の処理において、受信した音声信号のホッピングパターンと記憶部240に記憶されているFHパターン132とを照合し、受信した音声信号が当該1パケットにおけるいずれのシンボルに対応する音声信号であるかを判定することで、当該1周期の音声信号における先頭(1パケット中の先頭)の位置を特定する(1周期の音声信号における後半部を受信した場合には、末尾の位置を先頭位置とする)例を示したが、これは一例である。通信方式として高速周波数ホッピング方式(FFH方式)以外の通信方式を採用している場合には、例えば、プリアンブルにより先頭位置を特定してもよい。また、送信データに位置情報(例えばインデックス)を含めた音声信号を送信することで、受信側において当該位置情報(インデックス値)により先頭の位置を特定するようにしてもよい。先頭の位置を基準とした1周期の音声信号(1パケットのビット列データ)のうちの対応するシンボルへと受信した音声信号を配置できれば、先頭の位置を特定する方法は任意である。
また、上記実施の形態では、後半部、前半部、後半部といった順に受信した場合には、図11のステップS203の処理において、最初に受信される後半部と、次に受信される前半部との間を先頭位置であると特定し、前半部、後半部、前半部といった順に受信した場合には、ステップS203の処理において、最初に受信される前半部より前の位置を先頭位置であると特定する例を示したが、これは一例である。いずれの場合であっても、先に受信される後半部と、次に受信される前半部との間を先頭位置であると特定するようにしてもよい。そして、図11のステップS204の処理において、当該先頭位置以前に受信した音声信号と、当該先頭位置より後に受信した音声信号とが入れ替わるように受信した音声信号を順次配置することで、当該1周期分の音声信号を生成するようにしてもよい。
また、上記実施の形態では、図9に示すように、同一の音声信号が繰り返し出力される例について説明したが、必ずしも同一の音声信号でなくてもよく、異なる音声信号が連続的に出力されてもよい(なお、音声信号の長さについては共通であるものとする)。この場合には、例えば、図15(A)に示す送信データ1と送信データ2におけるG03のインデックスに対応するデータといったように、同一のインデックスに対応するデータが異なっていればよい。なお、図15に示す例では、理解を容易にするため、誤り訂正符号を使用しない例を示している。また、図示する例では、同一のインデックスに対応するデータとして1ビットのデータが異なる例を示しているが、1ビットに限られず、例えば、同一のインデックスに対応する1バイトのデータが異なるなど、同一のインデックスに対応するデータであれば、複数ビット異なっていてもよい。
図15(A)に示すように、U03のインデックスに対応するデータが異なる送信データ1と送信データ2とが連続的に出力される場合、携帯端末200において1周期分の音声信号を受信すると、図15(A)に示すように、(1)送信データ1のU03のインデックスに対応するデータを含む音声信号を受信するときと、(2)送信データ2のU03のインデックスに対応するデータを含む音声信号を受信するとき、といったように、送信データ1のU03に対応するデータと送信データ2のU03に対応するデータとのいずれかを含む音声信号を受信することとなる。
そのため、(1)送信データ1のU03のインデックスに対応するデータを含む音声信号を受信した場合は、図11のステップS204の処理により、図15(B)に示すように、送信データ1として処理が可能となる。また、(2)送信データ2のU03のインデックスに対応するデータを含む音声信号を受信した場合は、図11のステップS204の処理により、図15(C)に示すように、送信データ2として処理が可能となる。したがって、連続的に出力される音声信号が同一ではなくとも、同一のインデックスに対応するデータが異なっている音声信号であれば、いずれのタイミングでアプリケーションを起動した場合であっても処理が可能となり、処理時間を短縮化することができる。なお、連続的に出力される音声信号が同一ではない場合、前半部と後半部のいずれか一方における同一のインデックスに対応するデータが異なっていればよい。また、図15に示すように、同一のインデックスに対応するデータが異なっている音声信号が連続的に出力されている場合であっても、図11のステップS205~S208により、1周期分の音声を受信せずとも処理が可能である点は上記実施の形態と同様である。
また、上記実施の形態では、図8(D)に示すように、U00~U19、次いでV00~V19のインデックスに対応するデータが、図5のステップS12の処理により音声信号として順次出力され、1パケット分出力される例を示したが、これは一例である。例えば、通信端末100は、図16および図17に示すように、17.9kHz~19.9kHz(ハイバンド)、15.9kHz~17.9kHz(ローバンド)の2つの帯域を使用して音声信号を出力してもよい。
例えば、図16に示すように、ローバンドでは、送信する1パケットを2分割した後半部から前半部の順に送信し、ハイバンドでは、前半部から後半部といったように順序を変えることなく送信してもよい。なお、図16に示す送信順序を定義した送信順序定義情報については、予め記憶部130に記憶されていればよい。
具体的に、図17に示すように、ローバンドでは、図8(D)に示すV00~V19のインデックスに対応するデータ(後半部)を先に送信し、その後U00~U19のインデックスに対応するデータ(前半部)を送信する。一方、ハイバンドでは、順序を変えることなく、図8(D)に示すU00~U19のインデックスに対応するデータ(前半部)を先に送信し、その後V00~V19のインデックスに対応するデータ(後半部)を送信する。
これによれば、受信側の携帯端末200において、上記実施の形態における1周期分の通信の半分(通信の前半)、すなわち、ローバンドでV00~V19のインデックスに対応するデータ(後半部)を受信し、ハイバンドでU00~U19のインデックスに対応するデータ(前半部)を受信した時点で、1周期分のデータ(1パケット)を受信できたことになる。そのため、残りの音声信号の受信・復調などが不用となる。また、通信の前半で、例えば、バースト性のノイズにより、両方の帯域における伝送が不能となった場合でも、例えば、通信の後半に、ハイバンドで受信したV00~V19のインデックスに対応するデータ(後半部)と、ローバンドにおいて受信したU00~U19のインデックスに対応するデータ(前半部)と、から正しく受信データを復元することができる。さらに、通信の前半と後半を通して、ローバンドとハイバンドのどちらか一方の帯域における伝送が不能となった場合でも、正常に伝送できるどちらか一方のバンドのみで正しく受信データを復元することができる。
このように、2つの帯域を使用して音声信号を出力する場合、上記実施の形態における1周期分の通信の半分(通信の前半)で1周期分の音声信号を受信することが可能となる。そして、このような2つの帯域を使用して音声信号が出力される場合において、携帯端末200では、さらに、上記実施の形態における図11のステップS205~S208の処理を行うことにより、1周期分の通信の半分(通信の前半)の音声信号を受信するまでもなく、1周期分のデータ(1パケット)の復号および誤り訂正が可能となる。したがって、さらなる処理時間の短縮化が可能となる。
また、上記実施の形態では、図6のステップS104の処理において、図8に示すように、U00のパンクチャード符号に対応するインデックスのデータ(U00のグループのデータ)、U02のパンクチャード符号に対応するインデックスのデータ(U02のグループのデータ)、U01のパンクチャード符号に対応するインデックスのデータ(U01のグループのデータ)、U03のパンクチャード符号に対応するインデックのデータ(U03のグループのデータ)、といったように符号化レートの高い順にインタリーブするとともに、各グループのデータについて、U00、U04、U08、U12、U16やU02、U06、U10、U14、U18のようにインデックス値が低い方から高い方へと単調増加するようにインタリーブする例を示した(V00~V19のインデックスに対応するデータについても同様)が、これは一例である(図18(A)参照)。
図6のステップS104の処理では、U00のグループのデータ、U02のグループのデータ、U01のグループのデータ、U03のグループのデータといったように符号化レートの高い順にインタリーブするとともに、各グループのデータについて、例えば、図18(B)に示すように、U00のグループのデータについてU00、U12、U04、U16、U08、といった順に、U02のグループのデータについて、U02、U14、U06、U18、U10といった順に、1つ飛ばしでインタリーブしてもよい(V00~V19についても同様)。すなわち、各グループ同士でそれぞれのデータが共通した順序で配列されていれば、それぞれのデータの配列順序は任意である。
また、上記実施の形態では、チェックイン操作によりポイントを加算する例を示したが、これは一例である。例えば、上記実施の形態における通信端末100をバスの車内に配置し、乗客が乗車した際に当該通信端末100から出力された音声を乗客の携帯端末200により受信することで、定額の乗車代金の支払いを行うようにしてもよい。この場合、上記実施の形態におけるポイントサーバ300とは異なる代金支払いサーバを設け、ポイント加算とは逆に、乗車代金を現在の合計金額から減算するようにすればよい。この他にも映画館など料金が定額である場合の支払において、同様に適用可能である。
また、例えば、時間経過とともに異なる料金設定となっている店舗や施設においても適用可能である。具体的に、午前と午後とで利用料金が異なるレンタル会議室(なお、午前は3時間2000円、午後は3時間3000円といった固定の時間における料金が設定されており、延長できないものとする)において、午前中は図15(A)に示す送信データ1に対応する音声信号を出力し、午後になったタイミングで送信データ2に対応する音声信号を出力するといったように、所定のタイミングで出力する音声信号を切り替えることで、時間経過とともに異なる料金設定がなされている場合においても適用可能である。この場合においても、上記実施の形態におけるポイントサーバ300とは異なる代金支払いサーバを設け、ポイント加算とは逆に、利用料金を現在の合計金額から減算するようにすればよい。なお、出力する音声信号に当該料金の情報を含めて出力してもよい。また、それとは別に、出力する音声信号には午前であるか午後であるかを示す料金種別情報を含めて出力し、代金支払いサーバ側で午前と午後のそれぞれの料金を記憶しておき、受信した料金種別情報に応じて利用料金を現在の合計金額から減算するようにしてもよい。
上記実施の形態では、携帯端末200がスマートフォンであったが、本発明はこれに限られない。携帯端末200は、音声を集音するマイクを備える他の機器であってもよく、例えば、ICレコーダ、スマートウォッチのようなウェアラブルデバイスであってもよい。
上記実施の形態では、通信端末100の記憶部130、携帯端末200の記憶部240及びポイントサーバ300の記憶部310が各種データを記憶していたが、本発明はこれに限定されない。例えば、上記の処理で用いる各種データは、その全部又は一部が通信ネットワークを介して外部のサーバやコンピュータ等に記憶されてもよい。
上記実施の形態では、通信端末100、携帯端末200及びポイントサーバ300は、記憶部130、240、310に記憶されたプログラムに基づいて動作していたが、本発明はこれに限定されない。例えば、プログラムにより実現された機能的な構成をハードウェアにより実現してもよい。
上記実施の形態では、通信端末100、携帯端末200及びポイントサーバ300が実行する処理は、上述の物理的な構成を備える装置が記憶部130、240、310に記憶されたプログラムを実行することによって実現されていたが、本発明は、プログラムとして実現されてもよく、そのプログラムが記録された記憶媒体として実現されてもよい。
また、上述の処理動作を実行させるためのプログラムを、フレキシブルディスク、CD-ROM(Compact Disk Read-Only Memory)、DVD(Digital Versatile Disk)、MO(Magneto-Optical Disk)等のコンピュータにより読み取り可能な記録媒体に格納して配布し、そのプログラムをコンピュータにインストールすることにより、上述の処理動作を実行する装置を構成してもよい。
上記実施の形態は例示であり、本発明はこれらに限定されるものではなく、特許請求の範囲に記載した発明の趣旨を逸脱しない範囲でさまざまな実施の形態が可能である。各実施の形態や変形例で記載した構成要素は自由に組み合わせることが可能である。また、特許請求の範囲に記載した発明と均等な発明も本発明に含まれる。