アウトオブバンドの無線チャネルを用いた高速ミリ波リンクの制御とモニタリング
【課題】ミリ波の無線通信と従来の無線通信（WiFi、Bluetooth、3Gなど）との両方を用い、サーバ（アクセスポイント）からユーザのクライアント（携帯機器）へと大容量ファイルのデータのダウンロードを高速にかつ効率的に行うこと。
【解決手段】サーバからファイルデータをパケット化しクライアントへ送る。ファイルデータはデータパケットとしてミリ波で送る。並行して、データパケットに対応したチェックアウトパケット（点呼パケット）を送る。リンク設立時にテストとして、各通信回線のレイテンシを測定しておく。受信側では、チェックアウトパケットの受信が完了したときに、それに対応するミリ波パケットが届いているかどうかをチェックする（点呼をとる）。対応するミリ波パケットが届いていなければ、ロスしたものと判断し、直ちに再送信のリクエストをWiFi経由でサーバへ返す。
【解決手段】サーバからファイルデータをパケット化しクライアントへ送る。ファイルデータはデータパケットとしてミリ波で送る。並行して、データパケットに対応したチェックアウトパケット（点呼パケット）を送る。リンク設立時にテストとして、各通信回線のレイテンシを測定しておく。受信側では、チェックアウトパケットの受信が完了したときに、それに対応するミリ波パケットが届いているかどうかをチェックする（点呼をとる）。対応するミリ波パケットが届いていなければ、ロスしたものと判断し、直ちに再送信のリクエストをWiFi経由でサーバへ返す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信におけるデータのダウンロードを高速にかつ効率的に行うことに関する。
【背景技術】
【０００２】
ミリ波の無線通信と従来の無線通信（WiFi、Bluetooth、3Gなど）との両方を用い、サーバ（アクセスポイント）からクライアント（携帯機器）へと、大容量ファイルのデータを高速にダウンロードする技術がある。
【０００３】
日常生活に身近に応用されている例として、Kioskサービスにおけるダウンロードがある。これは、日本の鉄道の駅構内に設置されたサーバ（アクセスポイント）からサービスを受けるユーザのクライアント（携帯機器）へと、旅先や通勤途上のモバイルユーザからリクエストされた情報等を含むデータ転送を提供するオンデマンドなサービスである。
【０００４】
ミリ波を用いた通信回線は、高速なデータ伝送ができるものの、従来の無線に比べてロバスト性が低いという性質がある。逆に、従来の無線は、ロバスト性が高いものの、データ伝送速度（通信速度）はミリ波に比較すると相対的に遅いという性質がある。
【０００５】
これらの性質を表にまとめると、次のようになる。
インバンド アウトオブバンド
ミリ波（mmWave） 従来の無線リンク（WiFi、3G、Bluetooth等）
データ伝送速度 高 低
ロバスト性 低 高
【０００６】
２つの性質の異なる無線を相互補完的に使って、高速かつ高効率なファイル転送を実現することができれば理想的である。
【０００７】
つまり、ミリ波の高速性を活かすためには、ロバスト性の高い制御が必要である。ここで制御とは、リンクの接続と切断、パケットロスの検出と再送を含む。効率よい転送を行うためには、パケットロスをすばやく検出し、間断なく再送を行わなければならない。
【０００８】
特許文献１は、高速回線と低速回線の両方を用いて、パケットの再送を行う技術を開示している。しかし、検査によってデータ誤りがあったものと判断されたことに基づいた、データの再送であり、パケットがロスした場合については記述がない。
【０００９】
この他の周知技術として、TCP/IPプロトコルなどで使われるところの、タイムアウトによるパケットロス検出がある。しかし、Kioskサービスにおけるダウンロードに利用しようとすると、タイムアウトまで待つ必要性などがあり、効率が良いものであるとは言えない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許第３３５１６５３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ミリ波の無線通信と従来の無線通信（WiFi、Bluetooth、3Gなど）との両方を用い、サーバ（アクセスポイント）からクライアント（携帯機器）へと大容量ファイルデータを高速かつ効率的にダウンロードすることにある。
【課題を解決するための手段】
【００１２】
サーバからクライアントに対して、ファイルデータはデータパケットとしてミリ波で送る。並行して、データパケットに対応したチェックアウトパケット（点呼パケット）をチェックアウトジェネレータ（Check-out generator）で生成し、WiFi（または、Bluetooth、3Gなど従来の無線リンク）を使って送る。
【００１３】
ミリ波パケットとそれに対応するチェックアウトパケットの送信タイミングは、リンク設立時にテストとして、ミリ波とWiFi（または、Bluetooth、3Gなど従来の無線リンク）のレイテンシを測定し、モニタリングしながら調整を行う。
【００１４】
受信側では、チェックアウトパケットの受信が完了したときに、それに対応するミリ波パケットが届いているかどうかをチェックする（点呼をとる）。対応するミリ波パケットが届いていなければ、ロスしたものと判断し、再送信のリクエストをWiFi経由でサーバへ返す。既に届いているのであれば、届いているという確認をWiFi経由でサーバへ返すこともできる。
【００１５】
オーバヘッドを少なくするため、ミリ波パケットN（N≧1）個に対し、チェックアウトパケット1個を送るという設定も可能である。
【００１６】
ファイルシステムとして、制御等に関わってくるディレクトリ情報は、WiFi経由でサーバ、クライアント間で共有し、サーバからクライアントへの大きなデータ転送はミリ波を使う。
【発明の効果】
【００１７】
タイムアウトを使わず、素早いミリ波パケットのロス検出、再送処理が可能になる。
【００１８】
ミリ波データパケットと従来無線（WiFi、Bluetooth、3Gなど）制御パケットとのタイミング調整によりオーバヘッドを低減することができる。
【００１９】
携帯機器側では、最初のダウンロードリクエストを除き、すべてサーバからのコマンドに応答する形で動作するようにすることが可能であるため、制御プログラムが簡単になる。
【００２０】
ミリ波受信機の電力制御（オン・オフ）がより正確に制御できるようになるため、省電力につなげることができる。
【図面の簡単な説明】
【００２１】
【図１】図１は、本発明が適用される状況の概要を模式的に示す図である。
【図２】図２は、本発明のデータ転送手順を示す図である。
【図３】図３は、ミリ波パケットとWiFiパケットの到着タイミングによる転送効率を示したものである。
【図４】図４はタイミングの調整の概念図である
【発明を実施するための形態】
【００２２】
図１は、本発明が適用される状況の概要を模式的に示す図である。サーバ（アクセスポイント）からクライアント（携帯機器）へ、データのダウンロードとして、例えば、ファイルデータを送る。２つの性質の異なった無線リンク、ここではミリ波（Millimeter wave、略して mmWave とも表現する）と従来無線（WiFi、Bluetooth、３G など）を使う。基本的な制御は従来無線リンクの通信回線を通じて行い、データの送信はミリ波の通信回線を通じて行う。
【００２３】
サーバ（アクセスポイント）からは、データパケット(data packet)とチェックアウトパケット(check-outpacket)とが送信される。チェックアウトパケットは、チェックアウトジェネレータ(Check-out generator)において生成され、点呼パケットとも呼ばれる。
【００２４】
パケットは、典型的にはヘッダ(Header)とペイロード(Payload)とから構成される。ヘッダには、ペイロードの識別情報等が含まれており、ペイロードにはデータとしての基本的な内容が含まれている。本願発明の適用は、このような構成に限られるものではない。ヘッダはまた、従来無線リンクの通信回線とミリ波の通信回線との両方に並行して送信されるが、受信側でそれら複数のパケット（データパケットとチェックアウトパケット）の対応する関係を識別して、モニタリングしたり制御したりするために利用される。
【００２５】
大容量ファイルのデータを高速にダウンロードすることを想定して、データパケットの長さは模式的には長めに表現しているが、所定の長さであってよい。サーバとクライアントとは、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）では、双方向の通信を想定している。一方で、相対的に通信速度の速い第２の通信回線（ミリ波 mmWave）では、サーバからクライアントへの、一方向の通信を想定している。チェックアウトパケットの長さは模式的には短かめに表現しているが、チェックアウト（点呼）の機能を果たすことができれば、所定の長さであってよい。オーバヘッドを少なくするため、ミリ波パケットN（N≧1）個に対し、チェックアウトパケット1個を送信するという設定も可能である
【００２６】
クライアント側のシンクロナイザー(Synchronizer)は、第１の通信回線と第２の通信回線とを通じて並行して別々に受信される複数のパケットに関する時間（タイミング）を測定し、それらの相対的関係をモニタリングすることができる。例えば、受信の開始から完了までの期間を測定することができ、データパケットとチェックアウトパケットとの受信について、チェックアウトパケットの受信が完了した時点において、データパケットの受信が完了しているか、あるいは、未だ完了していないものかという判断をすることができる。
【００２７】
シンクロナイザーは、データパケットの受信が未だ完了していないものであるという判断をした場合には、第１の通信回線（WiFi等の従来無線リンク）を通じて、データパケットの再送信等を、サーバに対してリクエストすることができる。データパケットの受信が完了しているという判断をした場合には、受信が完了している（届いている）という確認をサーバへ返すように構成することも可能である。
【００２８】
図２は、本発明のデータ転送手順を示す図である。クライアント（携帯機器）からサーバ（アクセスポイント）に対して、データのダウンロードをリクエストする。すると、サーバからクライアントに対して、コマンドのような形で、クライアントに属している認証情報をリクエストする。サーバにおいて認証情報を受信して記録されている（または通信によって取得できる）認証情報を参照することで、クライアントに対してデータのダウンロードを認めてもよいかどうかを判断し、認めてもよい場合には、サーバからクライアントに対して、データのダウンロードが開始される。ここまでは、ミリ波の受信機の電源をオフにしても進めることができる。
【００２９】
ミリ波リンク初期設定は、ビーム設定、QoS、タイミング測定を含む。サーバ側からコマンドの形を通じて、サーバ側の主導で進めることができる。クライアント側のミリ波受信機の電源は、この初期設定を開始した時点から待機的にオン（ＯＮ）しておけばよい。ミリ波受信機の電源を受信が必要なときだけオンにできるので、クライアント側の消費電力を削減することができる。
【００３０】
ミリ波リンク初期設定としては、サーバからクライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信する。
【００３１】
クライアント側では、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定する。クライアントからサーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信する。サーバにおいて、第１の期間と第２の期間とを受信する。
【００３２】
図３は、ミリ波パケットとWiFiパケットの到着タイミングによる転送効率を示したものである。サーバの送信側は、ミリ波でデータパケットを送り、並行して別に、WiFiでチェックアウトパケットを送る。クライアントの受信側は、データパケットとチェックアウトパケットを受信するが、チェックアウトパケットの受信が完了した時点で、データパケットの受信が完了しているかどうか（届いているかどうか）の点呼をとって判断を行う。
【００３３】
図３の（Ａ）は、データパケットがすべて到着して、少し間をおいてからチェックアウトパケットが届いたケースを示している。チェックアウトパケットが届いてから点呼をとることになるため、確認待ちの時間ロスが生ずる。
【００３４】
図３の（Ｂ）は、図３の（Ａ）とは逆のケースになり、データパケットがすべて到着する前に、チェックアウトパケットが到着してしまい、点呼を行ったケースである。点呼をとってから後に到着したデータパケットはロスしたものとみなされて、再送要求が送信側へ送られることになる。同じパケットが複数回送られても、１つだけ受け取って残りを破棄すれば、データの一貫性は保つことができるものの、転送効率としては悪化することになる。
【００３５】
図３（Ｃ）はチェックアウトパケットが到着し、点呼を開始する直前にすべてのデータパケットが到着しているケースを示している。理論的には、サーバからクライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始し、サーバからクライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信することを開始すれば、待ち時間の無駄もなく、素早く再送信のリクエストを出せるという点で、最も効率がよいことになる。
【００３６】
すなわち、「レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）」という用語の意義の解釈は、時間の一点に限定して狭く解釈されるべきでなく、このように（Ａ）や（Ｂ）に比較して効率を追求している、（Ｃ）に近づける最適化をしているという本発明の技術的思想の範囲内において、広く解釈されるべきである。
【００３７】
また、（Ａ）（Ｂ）（Ｃ）のパターンにおいては、データパケットを先に送信することを開始して、チェックアウトパケットは後に送信することを開始するとして例示した。データパケットが大容量ファイルのデータである場合には、このようなパターンに該当する場合が多いことであろうが、チェックアウトパケットの送信がかなり遅い場合には、チェックアウトパケットを先に送信することを開始する必要が生じる場合もある。そのような場合には、「レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）」は、「レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）」に変更したものを選択すればよい。
【００３８】
送信したデータが受信されるまでの時間、すなわちレイテンシは、ハードウェア的、ソフトウェア的な要因等で発生する。そのため、サーバの種類、クライアント側の携帯機器の種類、サーバとクライアントとの距離、使用環境（外的ノイズの多い状況、遮蔽物の介在、人通りによる一時的な遮断）によって異なってくる。そのような意味でも、第１のテストパケットおよび第２のテストパケットによって、事前に送信および受信してリンクの状況を確認しておくこと（図２参照）には重要な意義がある。
【００３９】
図４はタイミングの調整の概念図である。図４（Ａ）に示すように、ミリ波リンク初期設定の段階で、ミリ波とWiFiのレイテンシ差を測定する。ファイル転送時には、図４（Ｂ）に示すとおり、ミリ波とWiFiにおいて、データパケットとチェックアウトパケットとに時間差（レイテンシの差）をつけて送り出す。
【００４０】
第１のテストパケットの所定の長さと第２のテストパケットの所定の長さとを、相対的な通信速度の違いを考慮して正規化しておくと、次のステップにおいて送信するところの、データパケットの長さとチェックアウトパケットの長さとを算出するにあたって好都合となる。すなわち、第１のテストパケットの「所定の長さに相当する」チェックアウトパケットの長さと、第２のテストパケットの「所定の長さに相当する」データパケットの長さとは、各々が前のステップにおいて送信されたテストパケットと同じ長さになっているという意味ではなく、正規化されたテストパケットの所定の長さを基準にして算出されたものになっているという意味であることに注意されたい。
【００４１】
ミリ波では毎秒数ギガビットの速度で転送を行うことができる。データパケットとチェックアウトパケットの組の転送で１ミリ秒の待ちが入っても、数メガビットの遅れとなってしまう。実際のファイル転送では、ファイルサイズによって、データパケットとチェックアウトパケットの組が繰り返し転送されるため、累積する遅れは大きくなる。たとえば、データパケットとチェックアウトパケットの組が1000回繰り返されるようなファイル転送では、遅れは1秒間（数ギガビット相当）となってしまう。
【００４２】
再び図２に戻ると、クライアントからダウンロードの完了がＯＫとして通知された時点で、クライアント側は消費電力を削減するべく、それ以降は、クライアント側のミリ波受信機の電源をにオフ（ＯＦＦ）してしまってよい。サーバからクライアントに対して、終了処理のクライアントに属している認証情報を参照することで、クライアントに対してダウンロードのサービスをしたことに対して、ダウンロードサービスの対価としての課金などの処理をすればよい。終了処理は、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）において行えばよい。
【００４３】
本発明の方法の実施は、（プログラム）コードとして具現化された（コンピュータ）プログラムとすることができる。また、サーバとクライアントという関係での役割分担において本発明が実施されるため、部分的な役割を担うサーバ、部分的な役割を担うクライアント、または、サーバまたはクライアントに（部分的な役割を）実行させるためのプログラムとして具現化することができる。
【技術分野】
【０００１】
本発明は、無線通信におけるデータのダウンロードを高速にかつ効率的に行うことに関する。
【背景技術】
【０００２】
ミリ波の無線通信と従来の無線通信（WiFi、Bluetooth、3Gなど）との両方を用い、サーバ（アクセスポイント）からクライアント（携帯機器）へと、大容量ファイルのデータを高速にダウンロードする技術がある。
【０００３】
日常生活に身近に応用されている例として、Kioskサービスにおけるダウンロードがある。これは、日本の鉄道の駅構内に設置されたサーバ（アクセスポイント）からサービスを受けるユーザのクライアント（携帯機器）へと、旅先や通勤途上のモバイルユーザからリクエストされた情報等を含むデータ転送を提供するオンデマンドなサービスである。
【０００４】
ミリ波を用いた通信回線は、高速なデータ伝送ができるものの、従来の無線に比べてロバスト性が低いという性質がある。逆に、従来の無線は、ロバスト性が高いものの、データ伝送速度（通信速度）はミリ波に比較すると相対的に遅いという性質がある。
【０００５】
これらの性質を表にまとめると、次のようになる。
インバンド アウトオブバンド
ミリ波（mmWave） 従来の無線リンク（WiFi、3G、Bluetooth等）
データ伝送速度 高 低
ロバスト性 低 高
【０００６】
２つの性質の異なる無線を相互補完的に使って、高速かつ高効率なファイル転送を実現することができれば理想的である。
【０００７】
つまり、ミリ波の高速性を活かすためには、ロバスト性の高い制御が必要である。ここで制御とは、リンクの接続と切断、パケットロスの検出と再送を含む。効率よい転送を行うためには、パケットロスをすばやく検出し、間断なく再送を行わなければならない。
【０００８】
特許文献１は、高速回線と低速回線の両方を用いて、パケットの再送を行う技術を開示している。しかし、検査によってデータ誤りがあったものと判断されたことに基づいた、データの再送であり、パケットがロスした場合については記述がない。
【０００９】
この他の周知技術として、TCP/IPプロトコルなどで使われるところの、タイムアウトによるパケットロス検出がある。しかし、Kioskサービスにおけるダウンロードに利用しようとすると、タイムアウトまで待つ必要性などがあり、効率が良いものであるとは言えない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許第３３５１６５３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ミリ波の無線通信と従来の無線通信（WiFi、Bluetooth、3Gなど）との両方を用い、サーバ（アクセスポイント）からクライアント（携帯機器）へと大容量ファイルデータを高速かつ効率的にダウンロードすることにある。
【課題を解決するための手段】
【００１２】
サーバからクライアントに対して、ファイルデータはデータパケットとしてミリ波で送る。並行して、データパケットに対応したチェックアウトパケット（点呼パケット）をチェックアウトジェネレータ（Check-out generator）で生成し、WiFi（または、Bluetooth、3Gなど従来の無線リンク）を使って送る。
【００１３】
ミリ波パケットとそれに対応するチェックアウトパケットの送信タイミングは、リンク設立時にテストとして、ミリ波とWiFi（または、Bluetooth、3Gなど従来の無線リンク）のレイテンシを測定し、モニタリングしながら調整を行う。
【００１４】
受信側では、チェックアウトパケットの受信が完了したときに、それに対応するミリ波パケットが届いているかどうかをチェックする（点呼をとる）。対応するミリ波パケットが届いていなければ、ロスしたものと判断し、再送信のリクエストをWiFi経由でサーバへ返す。既に届いているのであれば、届いているという確認をWiFi経由でサーバへ返すこともできる。
【００１５】
オーバヘッドを少なくするため、ミリ波パケットN（N≧1）個に対し、チェックアウトパケット1個を送るという設定も可能である。
【００１６】
ファイルシステムとして、制御等に関わってくるディレクトリ情報は、WiFi経由でサーバ、クライアント間で共有し、サーバからクライアントへの大きなデータ転送はミリ波を使う。
【発明の効果】
【００１７】
タイムアウトを使わず、素早いミリ波パケットのロス検出、再送処理が可能になる。
【００１８】
ミリ波データパケットと従来無線（WiFi、Bluetooth、3Gなど）制御パケットとのタイミング調整によりオーバヘッドを低減することができる。
【００１９】
携帯機器側では、最初のダウンロードリクエストを除き、すべてサーバからのコマンドに応答する形で動作するようにすることが可能であるため、制御プログラムが簡単になる。
【００２０】
ミリ波受信機の電力制御（オン・オフ）がより正確に制御できるようになるため、省電力につなげることができる。
【図面の簡単な説明】
【００２１】
【図１】図１は、本発明が適用される状況の概要を模式的に示す図である。
【図２】図２は、本発明のデータ転送手順を示す図である。
【図３】図３は、ミリ波パケットとWiFiパケットの到着タイミングによる転送効率を示したものである。
【図４】図４はタイミングの調整の概念図である
【発明を実施するための形態】
【００２２】
図１は、本発明が適用される状況の概要を模式的に示す図である。サーバ（アクセスポイント）からクライアント（携帯機器）へ、データのダウンロードとして、例えば、ファイルデータを送る。２つの性質の異なった無線リンク、ここではミリ波（Millimeter wave、略して mmWave とも表現する）と従来無線（WiFi、Bluetooth、３G など）を使う。基本的な制御は従来無線リンクの通信回線を通じて行い、データの送信はミリ波の通信回線を通じて行う。
【００２３】
サーバ（アクセスポイント）からは、データパケット(data packet)とチェックアウトパケット(check-outpacket)とが送信される。チェックアウトパケットは、チェックアウトジェネレータ(Check-out generator)において生成され、点呼パケットとも呼ばれる。
【００２４】
パケットは、典型的にはヘッダ(Header)とペイロード(Payload)とから構成される。ヘッダには、ペイロードの識別情報等が含まれており、ペイロードにはデータとしての基本的な内容が含まれている。本願発明の適用は、このような構成に限られるものではない。ヘッダはまた、従来無線リンクの通信回線とミリ波の通信回線との両方に並行して送信されるが、受信側でそれら複数のパケット（データパケットとチェックアウトパケット）の対応する関係を識別して、モニタリングしたり制御したりするために利用される。
【００２５】
大容量ファイルのデータを高速にダウンロードすることを想定して、データパケットの長さは模式的には長めに表現しているが、所定の長さであってよい。サーバとクライアントとは、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）では、双方向の通信を想定している。一方で、相対的に通信速度の速い第２の通信回線（ミリ波 mmWave）では、サーバからクライアントへの、一方向の通信を想定している。チェックアウトパケットの長さは模式的には短かめに表現しているが、チェックアウト（点呼）の機能を果たすことができれば、所定の長さであってよい。オーバヘッドを少なくするため、ミリ波パケットN（N≧1）個に対し、チェックアウトパケット1個を送信するという設定も可能である
【００２６】
クライアント側のシンクロナイザー(Synchronizer)は、第１の通信回線と第２の通信回線とを通じて並行して別々に受信される複数のパケットに関する時間（タイミング）を測定し、それらの相対的関係をモニタリングすることができる。例えば、受信の開始から完了までの期間を測定することができ、データパケットとチェックアウトパケットとの受信について、チェックアウトパケットの受信が完了した時点において、データパケットの受信が完了しているか、あるいは、未だ完了していないものかという判断をすることができる。
【００２７】
シンクロナイザーは、データパケットの受信が未だ完了していないものであるという判断をした場合には、第１の通信回線（WiFi等の従来無線リンク）を通じて、データパケットの再送信等を、サーバに対してリクエストすることができる。データパケットの受信が完了しているという判断をした場合には、受信が完了している（届いている）という確認をサーバへ返すように構成することも可能である。
【００２８】
図２は、本発明のデータ転送手順を示す図である。クライアント（携帯機器）からサーバ（アクセスポイント）に対して、データのダウンロードをリクエストする。すると、サーバからクライアントに対して、コマンドのような形で、クライアントに属している認証情報をリクエストする。サーバにおいて認証情報を受信して記録されている（または通信によって取得できる）認証情報を参照することで、クライアントに対してデータのダウンロードを認めてもよいかどうかを判断し、認めてもよい場合には、サーバからクライアントに対して、データのダウンロードが開始される。ここまでは、ミリ波の受信機の電源をオフにしても進めることができる。
【００２９】
ミリ波リンク初期設定は、ビーム設定、QoS、タイミング測定を含む。サーバ側からコマンドの形を通じて、サーバ側の主導で進めることができる。クライアント側のミリ波受信機の電源は、この初期設定を開始した時点から待機的にオン（ＯＮ）しておけばよい。ミリ波受信機の電源を受信が必要なときだけオンにできるので、クライアント側の消費電力を削減することができる。
【００３０】
ミリ波リンク初期設定としては、サーバからクライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信する。
【００３１】
クライアント側では、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定する。クライアントからサーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信する。サーバにおいて、第１の期間と第２の期間とを受信する。
【００３２】
図３は、ミリ波パケットとWiFiパケットの到着タイミングによる転送効率を示したものである。サーバの送信側は、ミリ波でデータパケットを送り、並行して別に、WiFiでチェックアウトパケットを送る。クライアントの受信側は、データパケットとチェックアウトパケットを受信するが、チェックアウトパケットの受信が完了した時点で、データパケットの受信が完了しているかどうか（届いているかどうか）の点呼をとって判断を行う。
【００３３】
図３の（Ａ）は、データパケットがすべて到着して、少し間をおいてからチェックアウトパケットが届いたケースを示している。チェックアウトパケットが届いてから点呼をとることになるため、確認待ちの時間ロスが生ずる。
【００３４】
図３の（Ｂ）は、図３の（Ａ）とは逆のケースになり、データパケットがすべて到着する前に、チェックアウトパケットが到着してしまい、点呼を行ったケースである。点呼をとってから後に到着したデータパケットはロスしたものとみなされて、再送要求が送信側へ送られることになる。同じパケットが複数回送られても、１つだけ受け取って残りを破棄すれば、データの一貫性は保つことができるものの、転送効率としては悪化することになる。
【００３５】
図３（Ｃ）はチェックアウトパケットが到着し、点呼を開始する直前にすべてのデータパケットが到着しているケースを示している。理論的には、サーバからクライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始し、サーバからクライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信することを開始すれば、待ち時間の無駄もなく、素早く再送信のリクエストを出せるという点で、最も効率がよいことになる。
【００３６】
すなわち、「レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）」という用語の意義の解釈は、時間の一点に限定して狭く解釈されるべきでなく、このように（Ａ）や（Ｂ）に比較して効率を追求している、（Ｃ）に近づける最適化をしているという本発明の技術的思想の範囲内において、広く解釈されるべきである。
【００３７】
また、（Ａ）（Ｂ）（Ｃ）のパターンにおいては、データパケットを先に送信することを開始して、チェックアウトパケットは後に送信することを開始するとして例示した。データパケットが大容量ファイルのデータである場合には、このようなパターンに該当する場合が多いことであろうが、チェックアウトパケットの送信がかなり遅い場合には、チェックアウトパケットを先に送信することを開始する必要が生じる場合もある。そのような場合には、「レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）」は、「レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）」に変更したものを選択すればよい。
【００３８】
送信したデータが受信されるまでの時間、すなわちレイテンシは、ハードウェア的、ソフトウェア的な要因等で発生する。そのため、サーバの種類、クライアント側の携帯機器の種類、サーバとクライアントとの距離、使用環境（外的ノイズの多い状況、遮蔽物の介在、人通りによる一時的な遮断）によって異なってくる。そのような意味でも、第１のテストパケットおよび第２のテストパケットによって、事前に送信および受信してリンクの状況を確認しておくこと（図２参照）には重要な意義がある。
【００３９】
図４はタイミングの調整の概念図である。図４（Ａ）に示すように、ミリ波リンク初期設定の段階で、ミリ波とWiFiのレイテンシ差を測定する。ファイル転送時には、図４（Ｂ）に示すとおり、ミリ波とWiFiにおいて、データパケットとチェックアウトパケットとに時間差（レイテンシの差）をつけて送り出す。
【００４０】
第１のテストパケットの所定の長さと第２のテストパケットの所定の長さとを、相対的な通信速度の違いを考慮して正規化しておくと、次のステップにおいて送信するところの、データパケットの長さとチェックアウトパケットの長さとを算出するにあたって好都合となる。すなわち、第１のテストパケットの「所定の長さに相当する」チェックアウトパケットの長さと、第２のテストパケットの「所定の長さに相当する」データパケットの長さとは、各々が前のステップにおいて送信されたテストパケットと同じ長さになっているという意味ではなく、正規化されたテストパケットの所定の長さを基準にして算出されたものになっているという意味であることに注意されたい。
【００４１】
ミリ波では毎秒数ギガビットの速度で転送を行うことができる。データパケットとチェックアウトパケットの組の転送で１ミリ秒の待ちが入っても、数メガビットの遅れとなってしまう。実際のファイル転送では、ファイルサイズによって、データパケットとチェックアウトパケットの組が繰り返し転送されるため、累積する遅れは大きくなる。たとえば、データパケットとチェックアウトパケットの組が1000回繰り返されるようなファイル転送では、遅れは1秒間（数ギガビット相当）となってしまう。
【００４２】
再び図２に戻ると、クライアントからダウンロードの完了がＯＫとして通知された時点で、クライアント側は消費電力を削減するべく、それ以降は、クライアント側のミリ波受信機の電源をにオフ（ＯＦＦ）してしまってよい。サーバからクライアントに対して、終了処理のクライアントに属している認証情報を参照することで、クライアントに対してダウンロードのサービスをしたことに対して、ダウンロードサービスの対価としての課金などの処理をすればよい。終了処理は、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）において行えばよい。
【００４３】
本発明の方法の実施は、（プログラム）コードとして具現化された（コンピュータ）プログラムとすることができる。また、サーバとクライアントという関係での役割分担において本発明が実施されるため、部分的な役割を担うサーバ、部分的な役割を担うクライアント、または、サーバまたはクライアントに（部分的な役割を）実行させるためのプログラムとして具現化することができる。
【特許請求の範囲】
【請求項１】
サーバ（アクセスポイント）からクライアント（携帯機器）に対して、データのダウンロードをより効率的に行う方法であって、
サーバからクライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するステップと、
クライアントにおいて、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定するステップと、
クライアントからサーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信するステップと、
サーバにおいて、第１の期間と第２の期間とを、受信するステップと、
サーバからクライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始するステップと、
サーバからクライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信することを開始するステップと
クライアントにおいて、チェックアウト（点呼）パケットの受信が完了した時点において、もしデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストするステップと、
を有する、
方法。
【請求項２】
複数のテストパケットを送信するステップの前に、さらに、
クライアントからサーバに対して、データのダウンロードをリクエストするステップと、
サーバからクライアントに対して、クライアントに属している認証情報をリクエストするステップと、
クライアントからサーバに対して、クライアントに属している認証情報を送信するステップと、
サーバにおいて認証情報を受信して認証情報を参照することで、データのダウンロードを認めてもよいかどうかを判断するステップと、
を有する、請求項１に記載の方法。
【請求項３】
サーバ（アクセスポイント）からクライアント（携帯機器）に対して、データのダウンロードをより効率的に行う方法であって、
サーバからクライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するステップと、
クライアントにおいて、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定するステップと、
クライアントからサーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信するステップと、
サーバにおいて、第１の期間と第２の期間とを、受信するステップと、
サーバからクライアントに対して、第１のテストパケットの長さに相当するチェックアウト（点呼）パケットの送信を第１の通信回線において開始するステップと、
サーバからクライアントに対して、第１の通信回線においてチェックアウトパケットの送信を開始した時点から、レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）において、第２の通信回線において第２のテストパケットの長さに相当するデータパケットを送信することを開始するステップと
クライアントにおいて、チェックアウト（点呼）パケットの受信が完了した時点において、もしデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストするステップと、
を有する、
方法。
【請求項４】
サーバ（アクセスポイント）からのデータのダウンロードをより効率的に行う、クライアント（携帯機器）であって、
サーバから送信されてくるところの、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを受信し、
第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定し、
サーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信し、
サーバから送信されてくるところの、第１の通信回線においてチェックアウト（点呼）パケットの受信が完了した時点において、もし第２の通信回線においてデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストする、
クライアント（携帯機器）。
【請求項５】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）であって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信し、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信し、
クライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始し、
クライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信する、
サーバ（アクセスポイント）。
【請求項６】
さらに、
クライアントから第１の通信回線を通じてリクエストされる、データパケットの再送信に応答して、
クライアントに対して、リクエストされたデータパケットを再送信する、
請求項５に記載のサーバ（アクセスポイント）。
【請求項７】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）であって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信し、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信し、
クライアントに対して、第１のテストパケットの長さに相当するチェックアウト（点呼）パケットの送信を第１の通信回線において開始し、
クライアントに対して、第１の通信回線においてチェックアウト（点呼）パケットの送信を開始した時点から、レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）において、第２の通信回線において第２のテストパケットの長さに相当するデータパケットを送信する、
サーバ（アクセスポイント）。
【請求項８】
サーバ（アクセスポイント）からのデータのダウンロードをより効率的に行う、クライアント（携帯機器）に実行させるためのプログラムであって、
サーバから送信されてくるところの、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを受信するコードと、
第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定するコードと、
サーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信するコードと、
第１の通信回線においてチェックアウト（点呼）パケットの受信が完了した時点において、もし第２の通信回線においてデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストするコードとを、
クライアント（携帯機器）に実行させるためのプログラム。
【請求項９】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）に実行させるためのプログラムであって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するコードと、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信するコードと、
クライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始するコードと、
クライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信するコードとを、
サーバ（アクセスポイント）に実行させるためのプログラム。
【請求項１０】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）に実行させるためのプログラムであって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するコードと、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信するコードと、
クライアントに対して、第１のテストパケットの長さに相当するチェックアウト（点呼）パケットの送信を第１の通信回線において開始するコードと、
クライアントに対して、第１の通信回線においてチェックアウト（点呼）パケットの送信を開始した時点から、レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）において、第２の通信回線において第２のテストパケットの長さに相当するデータパケットを送信するコードとを、
サーバ（アクセスポイント）に実行させるためのプログラム。
【請求項１】
サーバ（アクセスポイント）からクライアント（携帯機器）に対して、データのダウンロードをより効率的に行う方法であって、
サーバからクライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するステップと、
クライアントにおいて、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定するステップと、
クライアントからサーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信するステップと、
サーバにおいて、第１の期間と第２の期間とを、受信するステップと、
サーバからクライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始するステップと、
サーバからクライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信することを開始するステップと
クライアントにおいて、チェックアウト（点呼）パケットの受信が完了した時点において、もしデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストするステップと、
を有する、
方法。
【請求項２】
複数のテストパケットを送信するステップの前に、さらに、
クライアントからサーバに対して、データのダウンロードをリクエストするステップと、
サーバからクライアントに対して、クライアントに属している認証情報をリクエストするステップと、
クライアントからサーバに対して、クライアントに属している認証情報を送信するステップと、
サーバにおいて認証情報を受信して認証情報を参照することで、データのダウンロードを認めてもよいかどうかを判断するステップと、
を有する、請求項１に記載の方法。
【請求項３】
サーバ（アクセスポイント）からクライアント（携帯機器）に対して、データのダウンロードをより効率的に行う方法であって、
サーバからクライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するステップと、
クライアントにおいて、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定するステップと、
クライアントからサーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信するステップと、
サーバにおいて、第１の期間と第２の期間とを、受信するステップと、
サーバからクライアントに対して、第１のテストパケットの長さに相当するチェックアウト（点呼）パケットの送信を第１の通信回線において開始するステップと、
サーバからクライアントに対して、第１の通信回線においてチェックアウトパケットの送信を開始した時点から、レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）において、第２の通信回線において第２のテストパケットの長さに相当するデータパケットを送信することを開始するステップと
クライアントにおいて、チェックアウト（点呼）パケットの受信が完了した時点において、もしデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストするステップと、
を有する、
方法。
【請求項４】
サーバ（アクセスポイント）からのデータのダウンロードをより効率的に行う、クライアント（携帯機器）であって、
サーバから送信されてくるところの、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを受信し、
第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定し、
サーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信し、
サーバから送信されてくるところの、第１の通信回線においてチェックアウト（点呼）パケットの受信が完了した時点において、もし第２の通信回線においてデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストする、
クライアント（携帯機器）。
【請求項５】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）であって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信し、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信し、
クライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始し、
クライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信する、
サーバ（アクセスポイント）。
【請求項６】
さらに、
クライアントから第１の通信回線を通じてリクエストされる、データパケットの再送信に応答して、
クライアントに対して、リクエストされたデータパケットを再送信する、
請求項５に記載のサーバ（アクセスポイント）。
【請求項７】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）であって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信し、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信し、
クライアントに対して、第１のテストパケットの長さに相当するチェックアウト（点呼）パケットの送信を第１の通信回線において開始し、
クライアントに対して、第１の通信回線においてチェックアウト（点呼）パケットの送信を開始した時点から、レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）において、第２の通信回線において第２のテストパケットの長さに相当するデータパケットを送信する、
サーバ（アクセスポイント）。
【請求項８】
サーバ（アクセスポイント）からのデータのダウンロードをより効率的に行う、クライアント（携帯機器）に実行させるためのプログラムであって、
サーバから送信されてくるところの、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを受信するコードと、
第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを測定するコードと、
サーバに対して、第１の期間と第２の期間とを、テスト結果の情報として送信するコードと、
第１の通信回線においてチェックアウト（点呼）パケットの受信が完了した時点において、もし第２の通信回線においてデータパケットの受信が未だ完了していないものと判断された場合には、サーバに対して、第１の通信回線を通じて、その受信が完了しているべきであったところのデータパケットの再送信をリクエストするコードとを、
クライアント（携帯機器）に実行させるためのプログラム。
【請求項９】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）に実行させるためのプログラムであって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するコードと、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信するコードと、
クライアントに対して、第２のテストパケットの長さに相当するデータパケットの送信を第２の通信回線において開始するコードと、
クライアントに対して、第２の通信回線においてデータパケットの送信を開始した時点から、レイテンシの差（第２の期間−第１の期間）だけ経過した時点（タイミング）において、第１の通信回線において第１のテストパケットの長さに相当するチェックアウト（点呼）パケットを送信するコードとを、
サーバ（アクセスポイント）に実行させるためのプログラム。
【請求項１０】
クライアント（携帯機器）に対して、データのダウンロードをより効率的に行わせる、サーバ（アクセスポイント）に実行させるためのプログラムであって、
クライアントに対して、相対的に通信速度の遅い第１の通信回線（WiFi等の従来無線リンク）における所定の長さ（例：１個から成るパケット）の第１のテストパケットと、相対的に通信速度の速い第２の通信回線（ミリ波）における所定の長さ（例：N（N≧１）個から成るパケット）の第２のテストパケットという、複数のテストパケットを送信するコードと、
クライアントから送信されてくるところの、第１のテストパケットの受信の開始から受信の完了までの第１の期間と、第２のテストパケットの受信の開始から受信の完了までの第２の期間とを、テスト結果の情報として受信するコードと、
クライアントに対して、第１のテストパケットの長さに相当するチェックアウト（点呼）パケットの送信を第１の通信回線において開始するコードと、
クライアントに対して、第１の通信回線においてチェックアウト（点呼）パケットの送信を開始した時点から、レイテンシの差（第１の期間−第２の期間）だけ経過した時点（タイミング）において、第２の通信回線において第２のテストパケットの長さに相当するデータパケットを送信するコードとを、
サーバ（アクセスポイント）に実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−１７００１４（Ｐ２０１２−１７００１４Ａ）
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願番号】特願２０１１−３１２３１（Ｐ２０１１−３１２３１）
【出願日】平成２３年２月１６日（２０１１．２．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願日】平成２３年２月１６日（２０１１．２．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]