(57)【要約】【課題】高速プロトコル上のセキュアなプロトコルに従うパケットの通信効率の低下を低減する。【解決手段】高速プロトコル上のセキュアなプロトコルに従うパケットが、小サイズヘッダを有する。受信システムが、小サイズヘッダを有するパケットの処理に用いられるパケット番号を、受信されたパケットのパケット番号を示す情報を基に推定する。Ｎ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである小サイズヘッダである。小サイズヘッダが第１のヘッダの場合、Ｎ個のパケットの各々におけるヘッダが第１のヘッダである。小サイズヘッダが第２のヘッダの場合、Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが第２のヘッダである。【選択図】  図１
2020137093.tif 000002
【特許請求の範囲】
【請求項１】
高速プロトコル上のセキュアなプロトコルに従うパケットを送信する送信システムから当該パケットを受信する受信システムであって、
前記送信元システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報を基に、小サイズヘッダを有する受信したパケットについてのパケット番号を推定するパケット番号制御部と、
前記推定されたパケット番号を用いて当該パケットの処理を行うパケット処理部と
を備え、
前記送信元システムにより送信されるＮ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである前記小サイズヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第１のヘッダの場合、前記Ｎ個のパケットの各々におけるヘッダが前記第１のヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第２のヘッダの場合、前記Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが前記第２のヘッダである、
受信システム。
【請求項２】
前記小サイズヘッダが、前記第１のヘッダであり、
当該第１のヘッダにおける前記部分パケット番号は、前記パケット番号を構成するＰビットのうちの最下位ｎビット（ｎ＜Ｐ）を含む、
請求項１に記載の受信システム。
【請求項３】
前記パケット番号は、セッションの更新に応じて更新される番号である第１種の番号と、同一のセッションにおいて送信の都度に更新される番号である第２種の番号とを含み、
前記部分パケット番号は、前記第１種の番号を構成するＶビットのうちの最下位ｍビット（ｍ＜Ｖ）を更に含み、
前記最下位ｎビットは、前記第２種の番号を構成するＷビットのうちの最下位ｎビットである（ｎ＜Ｗ＜Ｐ）、
請求項２に記載の受信システム。
【請求項４】
前記パケット番号制御部は、
前記受信パケット情報に記録されているパケット番号を取得し、
前記第１のヘッダにおける前記最下位ｎビットと当該取得されたパケット番号のうちの最下位ｎビットとの関係から、前記第１のヘッダを有するパケットについてのパケット番号を推定する、
請求項２に記載の受信システム。
【請求項５】
ｎの値は、前記送信システムとのハンドシェークにおいて特定される通信品質と、許容された同期ずれとに基づいて決定された値であり、
同期ずれは、最近受信したパケットのパケット番号とその直前に受信したパケットのパケット番号との差分である、
請求項２に記載の受信システム。
【請求項６】
前記小サイズヘッダが、前記第２のヘッダであり、
前記Ｎ個のパケットのうちの１個のパケットが有するヘッダは、当該パケットのパケット番号を有する第３のヘッダであり、
前記第２のヘッダ及び前記第３のヘッダの各々は、当該ヘッダがパケット番号を有するか否かを示すフラグを有し、
前記パケット番号制御部が、前記受信したパケットが有するヘッダにおけるフラグが、当該ヘッダがパケット番号を有することを示しているか否かを判断し、
前記判断の結果が真の場合、前記推定されたパケット番号は、前記ヘッダにおけるパケット番号であり、
前記判断の結果が偽の場合、前記推定されたパケット番号は、前記受信パケット情報に記録されているパケット番号である、
請求項１に記載の受信システム。
【請求項７】
Ｎの値は、前記送信システムとのハンドシェークにおいて特定される通信品質と、許容された同期ずれとに基づいて決定された値であり、
同期ずれは、最近受信したパケットのパケット番号とその直前に受信したパケットのパケット番号との差分である、
請求項６に記載の受信システム。
【請求項８】
受信システムにパケットを送信する送信システムとしてコンピュータを動作させるコンピュータプログラムであって、
（ａ）高速プロトコル上のセキュアなプロトコルに従うパケットを生成し、
（ｂ）当該生成されたパケットを前記受信システムに送信し、
を前記コンピュータに実行させ、
Ｎ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである小サイズヘッダであり、
前記生成されたパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第１のヘッダの場合、前記Ｎ個のパケットの各々におけるヘッダが前記第１のヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第２のヘッダの場合、前記Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが前記第２のヘッダである、
コンピュータプログラム。
【請求項９】
パケットを送信する送信システムに実現される送信処理部と、
当該パケットを受信する受信システムに実現される受信処理部と
を有し、
前記送信処理部は、高速プロトコル上のセキュアなプロトコルに従うパケットを前記受信システムに送信し、
前記受信処理部は、前記送信システムから前記受信システムが受信し小サイズヘッダを有するパケットについてのパケット番号を、前記送信元システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報を基に推定し、当該推定されたパケット番号を用いて当該パケットの処理を行い、
前記送信処理部により送信されるＮ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである前記小サイズヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第１のヘッダの場合、前記Ｎ個のパケットの各々におけるヘッダが前記第１のヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第２のヘッダの場合、前記Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが前記第２のヘッダである、
パケット通信システム。
【請求項１０】
送信システムにより、高速プロトコル上のセキュアなプロトコルに従うパケットを受信システムに送信し、
前記受信システムにより、小サイズヘッダを有するパケットを受信し、
前記受信システムにより、当該受信したパケットについてのパケット番号を、前記送信元システムから受信されたパケットについてのパケット番号を示す情報である受信パケット情報を基に推定し、
前記受信システムにより、当該推定されたパケット番号を用いて当該パケットの処理を行い、
前記送信元システムにより送信されるＮ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分である部分パケット番号を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである前記小サイズヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第１のヘッダの場合、前記Ｎ個のパケットの各々におけるヘッダが前記第１のヘッダであり、
前記送信元システムが送信するパケットのヘッダが前記小サイズヘッダであって当該小サイズヘッダが前記第２のヘッダの場合、前記Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが前記第２のヘッダである、
パケット通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、パケット通信に関する。
【背景技術】
【０００２】
パケット通信の一例として、ＩｏＴ（Internet of things）サーバとＩｏＴ機器間で行われるパケット通信がある。ＩｏＴサーバが、パケット通信におけるサーバの一例であり、ＩｏＴ機器が、パケット通信におけるクライアントの一例である。ＩｏＴでは、センサー機器等の多くのＩｏＴ機器がクライアントとなり得る。
【０００３】
あらゆるモノがインターネットに繋がるＩｏＴ化が進む中、ＩｏＴ機器のセキュリティを担保することが重要な社会課題の一つとなっている。ＩｏＴは例えば以下の特徴を持つため、それに合わせたセキュリティ技術が求められている。
（１）低スペック。ＩｏＴ機器のプロセッサ速度、メモリ容量及びバッテリ容量等は一般に低い。故に、少ないリソースでセキュリティを実現できることが求められる。
（２）多数のＩｏＴ機器。ＩｏＴ機器は２０２０年には数百億台に達するともいわれており、それに伴いネットワークを流れる通信データ量も増大する。通信インフラを効率的に利用するためには、少ない通信データ量でセキュリティを実現することが求められる。
（３）リアルタイム性。ＩｏＴ機器が典型的に利用されるユースケースの一例として、センサデータやプローブデータの送信がある。このようなデータは、リアルタイム性が重視される。このため、ＩｏＴに関するパケット通信では、パケット到達保証のあるプロトコルである高信頼プロトコル（例えばＴＣＰ（Transmission Control Protocol））ではなく、パケット到達保証が無いが故に信頼性は低いが高信頼プロトコルに比して高速なパケット通信が可能なプロトコルである高速プロトコル、例えばＵＤＰ（User Datagram Protocol）が採用される。
【０００４】
このような特徴によれば、高速プロトコル上でセキュアなパケット通信を実現することが望まれる。
【０００５】
セキュアなパケット通信を実現する方法の一例として、暗号化を挙げることができる。暗号化に関する技術として、例えば特許文献１に開示の技術が知られている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2014-147099号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＵＤＰ上でセキュアなパケット通信を可能にするプロトコルとして、ＤＴＬＳ（Datagram Transport Layer Security）がある。ＤＴＬＳは、ＵＤＰ上で動作するＴＬＳであると言うことができる。具体的には、ＵＤＰを用いて送信されるデータが暗号化される場合、暗号化されたデータを含んだパケットの欠落が発生すると、同期ずれが起こり、故に、パケット内のデータを復号できなくなるが、ＤＴＬＳでは、ＤＴＬＳヘッダにパケット番号が記述されるようになっており、当該パケット番号を用いて同期ずれからの復帰が可能である。ＤＴＬＳでは、パケット番号は、典型的には、セッションの更新の都度に更新されるepochと、セッションにおける通し番号であるsequence_numberとから構成されており、故に、一つのセッションでは、パケット番号は、シーケンス番号に相当する。
【０００８】
ＤＴＬＳには次の課題がある。すなわち、本来ＵＤＰは、ＴＣＰよりも処理負荷の軽いプロトコルであるが、ＤＴＬＳ／ＵＤＰ（DTLS over UDP）は、ＴＬＳ／ＴＣＰ（TLS over TCP）には無かったパケット番号がヘッダに付加される。このため、ＤＴＬＳ／ＵＤＰに従うパケットは、ＴＬＳに従うパケットよりも通信負荷の重いパケットとなってしまう。結果として、パケット通信効率が低下する。上述のような逆転現象を解消することが望まれる。このような課題は、ＤＴＬＳ／ＵＤＰに限らず、高速プロトコル（具体的には、パケット番号が付加されずパケット到達保証の無いプロトコル）上でセキュアなプロトコル（具体的には、パケット番号をヘッダに記述しセキュアなパケット通信を可能にするプロトコル）を用いたパケット通信についてもあり得る。
【０００９】
特許文献１には、フルシーケンス番号から導かれる部分シーケンス番号を出力パケットが含むこと、及び、パケットのオーバヘッドの低減といった記述がある。
【００１０】
しかし、特許文献１の技術は、「ここでは、暗号化及び再配列のために単一のフルシーケンス番号を用いる技術が、記述される。これら技術は、各パケットのオーバヘッドを低減し、ハンドオーバの間、ＲＬＣについて同期化されたシーケンス番号を提供しうる。」及び「受信パケットの再配列、欠落したパケットの検出、誤って受信された又は欠落した受信パケットの再送信のような様々なパケットのためにラジオリンク制御（ＲＬＣ）を利用しうる。」とあるように、送達確認機能（言い換えればパケット到達保証機能）のあるＲＬＣに関する技術である。特許文献１は、上述の課題を開示も示唆もしていない。このため、特許文献１の技術を利用して、上述の課題を解決することはできない。
【課題を解決するための手段】
【００１１】
高速プロトコル上のセキュアなプロトコルに従うパケットが、小サイズヘッダを有する。受信システムにおいて、小サイズヘッダを有するパケットの処理に用いられるパケット番号が、受信されたパケットについてのパケット番号を示す情報を基に推定される。Ｎ個のパケット（Ｎは２以上の整数）のうちの１個以上のパケットの各々におけるヘッダが、当該パケットのパケット番号の一部分を有する第１のヘッダと、当該パケットのパケット番号を有さない第２のヘッダとのいずれかである小サイズヘッダである。小サイズヘッダが第１のヘッダの場合、Ｎ個のパケットの各々におけるヘッダが第１のヘッダである。小サイズヘッダが第２のヘッダの場合、Ｎ個のパケットのうち１個のパケット以外のパケットの各々におけるヘッダが第２のヘッダである。
【発明の効果】
【００１２】
高速プロトコル上のセキュアなプロトコルに従うパケットの通信効率の低下を低減することができる。
【図面の簡単な説明】
【００１３】
【図１】実施例１に係るクライアントサーバシステムの構成を示す。
【図２】ＩｏＴサーバの構成を示す。
【図３】ＩｏＴ機器の構成を示す。
【図４】ＩｏＴサーバが有するサーバパケットＤＢの構成を示す。
【図５】ＩｏＴ機器が有するサーバパケットＤＢの構成を示す。
【図６】ＩｏＴサーバが有するクライアントパケットＤＢの構成を示す。
【図７】ＩｏＴ機器が有するクライアントパケットＤＢの構成を示す。
【図８】比較例に従うパケットの構成を示す。
【図９】実施例１に係るパケットの構成を示す。
【図１０】実施例１に係るパケット送受信処理の流れを示す。
【図１１】実施例２に係るＩｏＴサーバ及びＩｏＴ機器の機能を示す。
【図１２】大サイズパケットの構成を示す。
【図１３】小サイズパケットの構成を示す。
【図１４】実施例２に係るパケット送受信処理の流れを示す。
【発明を実施するための形態】
【００１４】
以下の説明では、「インターフェース部」は、１以上のインターフェースでよい。当該１以上のインターフェースは、１以上の同種の通信インターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
【００１５】
また、以下の説明では、「メモリ部」は、１以上のメモリであり、典型的には主記憶デバイスでよい。メモリ部における少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。
【００１６】
また、以下の説明では、「ＰＤＥＶ部」は、１以上のＰＤＥＶであり、典型的には補助記憶デバイスでよい。「ＰＤＥＶ」は、物理的な記憶デバイス（Physical storage DEVice）を意味し、典型的には、不揮発性の記憶デバイス、例えばＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。
【００１７】
また、以下の説明では、「記憶部」は、メモリ部とＰＤＥＶ部の少なくとも一部とのうちの少なくとも１つ（典型的には少なくともメモリ部）である。
【００１８】
また、以下の説明では、「演算部」は、１以上の演算モジュールである。少なくとも１つの演算モジュールは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種の演算モジュールでもよい。少なくとも１つの演算モジュールとしてのプロセッサは、シングルコアでもよいしマルチコアでもよい。少なくとも１つの演算モジュールは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義の演算モジュールでもよい。
【００１９】
また、以下の説明では、「ｘｘｘＤＢ」といった表現にて（「ＤＢ」はデータベースの略）、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし、入力に対する出力を発生するニューラルネットワークのような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。
【００２０】
また、以下の説明では、「ｋｋｋ部」（インターフェース部、記憶部及び演算部を除く）の表現にて機能を説明することがあるが、機能は、１以上のコンピュータプログラムが演算部によって実行されることで実現されてもよいし、１以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよい。プログラムが演算部によって実行されることで機能が実現される場合、定められた処理が、適宜に記憶部及び／又はインターフェース部等を用いながら行われるため、機能は演算部の少なくとも一部とされてもよい。機能を主語として説明された処理は、演算部あるいはその演算部を有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が１つの機能にまとめられたり、１つの機能が複数の機能に分割されたりしてもよい。
【００２１】
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通部分を使用し、同種の要素を区別する場合は、参照符号を使用することがある。例えば、受信処理部を区別しない場合には、「受信処理部１３０」と言い、受信処理部を区別する場合には、「受信処理部１３０Ｓ」、「受信処理部１３０Ｃ」のように言うことがある。
【００２２】
以下、図面を参照して、本発明の幾つかの実施例を説明する。なお、以下の実施例では、ＤＴＬＳ／ＵＤＰが採用される。すなわち、高速プロトコルとしてＵＤＰが採用され、高速プロトコル上のセキュアなプロトコルとしてＤＴＬＳが採用される。従って、以下の実施例で送受信されるパケットは、ＤＴＬＳ／ＵＤＰに従うパケットである。しかし、本発明は、ＤＴＬＳ／ＵＤＰ以外にも適用可能である。
【実施例１】
【００２３】
図１は、実施例１に係るクライアントサーバシステムの構成を示す。
【００２４】
複数のＩｏＴ機器１０１の各々がクライアントの一例として存在し、ＩｏＴサーバ１０３が、サーバの一例として存在する。複数のＩｏＴ機器１０１の各々とＩｏＴサーバ１０３との間で、無線通信ネットワークのような通信ネットワーク１０２を介して、通信が行われる。
【００２５】
ＩｏＴ機器１０１として、種々の機器を採用し得る。例えば、各ＩｏＴ機器１０１は、工場に設置されているセンサー機器（及び他種の機器）でよく、ＩｏＴサーバ１０３は、当該工場内の各ＩｏＴ機器１０１からデータを収集するサーバでよい。
【００２６】
本実施例では、ＩｏＴ機器１０１とＩｏＴサーバ１０３のいずれも、パケットを送信することとパケットを受信することのいずれも可能である。すなわち、ＩｏＴ機器１０１は、送信システムの一例としても受信システムの一例としても動作可能であり、同様に、ＩｏＴサーバ１０３は、受信システムの一例としても送信システムの一例としても動作可能である。しかし、それに限らず、ＩｏＴ機器１０１は、送信システムの一例として動作可能であるが受信システムの一例としては動作不可能であってもよい。また、ＩｏＴサーバ１０３は、受信システムの一例として動作可能であるが送信システムの一例としては動作不可能でもよい。
【００２７】
また、「受信システム」及び「送信システム」のうちの少なくとも一つは、インターフェース部、記憶部及びそれらに接続された演算部を有する計算機システム（例えば、一つ以上の物理的な計算機）でもよいし、クラウド基盤のような計算機システム上に実現されるシステム（例えばクラウドコンピューティングサービス）でもよい。なお、本発明は、ＩｏＴが有する上述した特徴と同様の特徴（低スペック、多数の送信システム、リアルタイム性）を有するパケット通信システムに特に有用である。
【００２８】
図２は、ＩｏＴサーバ１０３の構成を示す。
【００２９】
ＩｏＴサーバ１０３は、典型的には計算機システム（１以上の計算機）であり、インターフェース部２０１、記憶部２０２及びそれらに接続された演算部２０３を有する。
【００３０】
インターフェース部２０１経由で、各ＩｏＴ機器１０１と通信が行われる。
【００３１】
記憶部２０２は、演算部２０３により実行される１以上のコンピュータプログラムや演算部２０３により参照又は更新される情報を格納する。そのような情報の一例として、サーバパケットＤＢ２１１Ｃ、及び、クライアントパケットＤＢ２１２Ｓがある。ＩｏＴサーバ１０３にとっては、サーバパケットＤＢ２１１Ｃが、送信時のパケット番号が記録される送信パケット情報の一例であり、クライアントパケットＤＢ２１２Ｓが、受信したパケットについてのパケット番号が記録される受信パケット情報の一例である。
【００３２】
演算部２０３が１以上のコンピュータプログラムを実行することにより、送信処理部１１０Ｓ及び受信処理部１３０Ｓといった機能が実現される。
【００３３】
送信処理部１１０Ｓは、パケットの送信を行う。具体的には、例えば、送信処理部１１０Ｓは、パケット生成部２２１Ｓと、パケット送信部２２２Ｓとを有する。パケット生成部２２１Ｓは、ＤＴＬＳ／ＵＤＰに従うパケットを生成する。パケット送信部２２２Ｓは、当該生成されたパケットを送信する。
【００３４】
受信処理部１３０Ｓは、パケットを受信し、当該パケットを処理する。具体的には、例えば、受信処理部１３０Ｓは、パケット番号制御部２３１Ｓと、パケット処理部２３２Ｓとを有する。パケット番号制御部２３１Ｓは、クライアントパケットＤＢ２１２Ｓを基に、小サイズヘッダを有する受信したパケットについてのパケット番号を推定する。パケット処理部２３２Ｓは、当該推定されたパケット番号を用いて、受信されたパケットの処理を行う。
【００３５】
図３は、ＩｏＴ機器１０１の構成を示す。
【００３６】
ＩｏＴ機器１０１は、典型的にはセンサー機器のように少なくともＩｏＴ機器１０１に比べて低スペックの機器であり、インターフェース部３０１、記憶部３０２及びそれらに接続された演算部３０３を有する。
【００３７】
インターフェース部３０１経由で、ＩｏＴサーバ１０３と通信が行われる。
【００３８】
記憶部３０２は、演算部３０３により実行される１以上のコンピュータプログラムや演算部３０３により参照又は更新される情報を格納する。そのような情報の一例として、クライアントパケットＤＢ２１１Ｃ、及び、サーバパケットＤＢ２１２Ｃがある。ＩｏＴ機器１０１にとって、クライアントパケットＤＢ２１１Ｃが、送信時のパケット番号が記録される送信パケット情報の一例であり、サーバパケットＤＢ２１２Ｃが、受信したパケットについてのパケット番号が記録される受信パケット情報の一例である。
【００３９】
演算部３０３が１以上のコンピュータプログラムを実行することにより、送信処理部１１０Ｃ及び受信処理部１３０Ｃといった機能が実現される。送信処理部１１０Ｃ及び受信処理部１３０Ｃは、上述の送信処理部１１０Ｓ及び受信処理部１３０Ｓと同様である。すなわち、送信処理部１１０Ｃは、パケット生成部２２１Ｃと、パケット送信部２２２Ｃとを有する。受信処理部１３０Ｃは、パケット番号制御部２３１Ｃと、パケット処理部２３２Ｃとを有する。
【００４０】
図４は、ＩｏＴサーバ１０３が有するサーバパケットＤＢ２１１Ｓの構成を示す。図５は、ＩｏＴ機器１０１が有するサーバパケットＤＢ２１１Ｃの構成を示す。
【００４１】
サーバパケットＤＢ２１１は、例えばセッション毎にエントリを有する。各エントリは、例えば、セッション＃４０１、パケット＃４０２及びＯＴＨＥＲＳ４０３といった情報を保持する。セッション＃４０１は、セッションの番号を示す。パケット＃４０２は、パケットのパケット番号を示す。ＯＴＨＥＲＳ４０３は、セッションの番号とパケットの番号以外の情報である。少なくともＯＴＨＥＲＳ４０３は、無くてもよい。サーバパケットＤＢ２１１は、セッション毎にエントリを有するものに限られず、例えば、セッションとパケット番号の一部毎にエントリを有するものであってもよい。
【００４２】
ＤＴＬＳ／ＵＤＰでは、パケット番号は、epochと、sequence_numberで構成される番号である。epochは、セッションにおけるコネクションの生成に応じて更新される番号であり、第１種の番号の一例である。sequence_numberは、同一のコネクションにおいて送信の都度に更新される番号であり、第２種の番号の一理である。epochは、例えば２バイト（１６ビット）であり、sequence_numberは、例えば６バイト（４８ビット）である。
【００４３】
ＩｏＴサーバ１０３が有するサーバパケットＤＢ２１１Ｓに記録されるパケット＃４０２Ｓは、ＩｏＴサーバ１０３から送信されるパケットについてのパケット番号を示す。ＩｏＴ機器１０１が有するサーバパケットＤＢ２１１Ｃに記録されるパケット＃４０２Ｃは、ＩｏＴサーバ１０３から送信されるパケットについてのパケット番号を示す。
【００４４】
図６は、ＩｏＴサーバ１０３が有するクライアントパケットＤＢ２１２Ｓの構成を示す。図７は、ＩｏＴ機器１０１が有するクライアントパケットＤＢ２１２Ｃの構成を示す。
【００４５】
クライアントパケットＤＢ２１２は、例えばセッション毎にエントリを有する。各エントリは、例えば、セッション＃６０１、パケット＃６０２及びＯＴＨＥＲＳ６０３といった情報を保持する。情報６０１〜６０３は、情報４０１〜４０３と同様である。クライアントパケットＤＢ２１１は、セッション毎にエントリを有するものに限られず、例えば、セッションとパケット番号の一部毎にエントリを有するものであってもよい。
【００４６】
ＩｏＴサーバ１０３が有するクライアントパケットＤＢ２１１Ｓに記録されるパケット＃４０２Ｓは、ＩｏＴクライアント１０３から送信されるパケットについてのパケット番号を示す。ＩｏＴ機器１０１が有するクライアントパケットＤＢ２１１Ｃに記録されるパケット＃４０２Ｃは、ＩｏＴクライアント１０３から送信されるパケットについてのパケット番号を示す。
【００４７】
本実施例では、説明を簡単にするために、ＩｏＴ機器１０１とセッションＩＤは１：１であるが（１つのＩｏＴ機器１０１とＩｏＴサーバ１０３との間では１つのセッションが行われるが）、ＩｏＴ機器１０１とセッションＩＤは１：多でもよい。
【００４８】
図８は、比較例に従うパケットの構成を示す。
【００４９】
図８に例示するように、比較例に従うパケット８００は、ヘッダ１５とopaque８０６とを有する。opaque８０６は、パケットの本体に相当し、典型的には暗号化データである。暗号化データが復号されたデータを「メッセージ」と言うことができる。
【００５０】
ヘッダ１５は、例えば、ContentType８０１、ProtocolVersion８０２、パケット番号８１０（epoch８０３及びsequence_number８０４）、及びlength８０５を有する。
【００５１】
ContentType８０１は、メッセージのコンテンツのタイプを示し、例えば１バイトの情報である。ProtocolVersion８０２は、ＤＴＬＳのバージョンを示し、例えば２バイトの情報である。epoch８０３は、例えば２バイトの情報である。sequence_number８０４は、例えば６バイトの情報である。従って、パケット番号８１０は、例えば８バイトの情報である。length８０５は、パケット全体の長さを示す。
【００５２】
図９は、実施例１に係るパケットの構成を示す。
【００５３】
実施例１に係るパケット９００は、ヘッダ２５とopaque８０６とを有する。ヘッダ２５は、第１のヘッダの一例である。第１のヘッダは、小サイズヘッダの一例である。「小サイズヘッダ」は、ヘッダ１５よりも小サイズのヘッダである。
【００５４】
ヘッダ２５は、パケット番号８１０に代えて、パケット番号８１０の一部分である部分パケット番号９１０を有する。部分パケット番号９１０は、パケット番号８１０を構成するＰビット（ここではＰ＝６４）のうちの最下位ｎビット（ｎ＜Ｐ）を含む（ここではｎ＝６）。ｎの値は、許容される同期ずれを基に決定されればよい。すなわち、この構成は、本願発明者が鋭意検討した結果によれば、同期ずれが生じたとしても当該同期ずれが許容される同期ずれを超えなければ、パケット番号の一部分を用いて、許容される同期ずれを超える同期ずれを防ぐことができるという知見に至る。そして、パケット番号の一部分は、パケット番号の最下位ｎビットである。これにより、パケットのヘッダのサイズを小さくすることができるため、高効率なパケット通信を実現すること、具体的には、許容される同期ずれを超える同期ずれの防止を高効率に実現することができる。また、本実施例では、高効率且つセキュアなパケット通信を実現することができるが、本実施例でいう「セキュア」は、特に、機密性及び完全性に相当する。
【００５５】
本実施例では、部分パケット番号９１０は、lsb_epoch９０３、及び、lsb_sequence_number９０４で構成される。lsb_epoch９０３は、epochを構成するＶビット（ここではＶ＝１６）のうちの最下位ｍビット（ｍ＜Ｖ）である（ここではｍ＝２）。lsb_sequence_number９０４は、上述の最下位ｎビットは、sequence_numberを構成するＷビット（ここではＷ＝４８ビット）のうちの最下位ｎビットである（ｎ＜Ｗ＜Ｐ）。これにより、後述するように、部分パケット９１０から、セッションを推定し、推定されたセッションにおいて、高効率なパケット通信を実現することができる。なお、上記ｎ、ｍ、Ｐ、Ｖ及びＷの各々は自然数である。特に、少なくともＰは、２以上の整数である。また、ｎ及びｍのうちの少なくとも一つの値は、ＩｏＴ機器１０１毎に異なってもよいしセッション毎に異なってもよい。
【００５６】
図１０は、実施例１に係るパケット送受信処理の流れを示す。
【００５７】
ＩｏＴ機器１０１の送信処理部１１０ＣとＩｏＴサーバ１０３の受信処理部１３０Ｓとの間でセッションｘ（セッション番号ｘのセッション）の確立のためのハンドシェークが行われる。当該ハンドシェークにおいて、例えば下記が行われる（図示せず）。
・送信処理部１１０Ｃ（例えばパケット生成部２２１Ｃ）は、クライアントパケットＤＢ２１２Ｃのエントリに、セッションｘの番号を示すセッション＃６０１Ｃと、初期値（例えば全ビットが“０”）を示すパケット＃６０２Ｃとを記述する。例えば、送信処理部１１０Ｃは、確立前のセッション（ｘ−１）に対応したパケット＃６０２Ｃを初期値（例えば全ビットが“０”）に更新し、且つ、当該確立前のセッション（ｘ−１）に対応したセッション＃６０１Ｃを、セッションｘに対応したセッション＃６０１Ｃに更新する。
・受信処理部１１０Ｓ（例えばパケット番号制御部２３１Ｓ）は、クライアントパケットＤＢ２１２Ｓのエントリに、セッションｘの番号を示すセッション＃６０１Ｓと、初期値（例えば全ビットが“０”）を示すパケット＃６０２Ｓとを記述する。例えば、受信処理部１１０Ｓは、確立前のセッション（ｘ−１）に対応したパケット＃６０２Ｓを初期値（例えば全ビットが“０”）に更新し、且つ、当該確立前のセッション（ｘ−１）に対応したセッション＃６０１Ｓを、セッションｘに対応したセッション＃６０１Ｓに更新する。
【００５８】
その後、パケットの送受信の都度に、下記が行われる。
【００５９】
ＩｏＴ機器１０１において、パケット生成部２２１Ｃが、パケット＃６０２Ｃをインクリメントする、言い換えれば、パケット＃６０２Ｃが示す番号を次の番号に更新する（Ｓ１００１）。パケット生成部２２１Ｃが、パケット＃６０２Ｃから部分パケット番号９１０（epochのうちの最下位ｍビットとsequence_numberのうちの最下位ｎビットで構成された情報）を取得する（Ｓ１００２）。パケット生成部２２１Ｃが、取得した部分パケット番号９１０を含んだヘッダ２５と、opaque８０６（メッセージの暗号化データ）とを含んだパケット９００を生成する（Ｓ１００３）。パケット送信部２２２Ｃが、生成されたパケット９００をＩｏＴサーバ１０３に送信する（Ｓ１００４）。
【００６０】
なお、メッセージは、例えば、パケット＃６０２Ｃ（フルサイズのパケット番号）を用いて暗号化される。また、パケットには、パケット＃６０２Ｃ（フルサイズのパケット番号）とメッセージとの連結を含む連結データのＭＡＣ（例えば、ＨＭＡＣ（Hash-based MAC（Message Authentication Code））が含まれてよい。
【００６１】
ＩｏＴサーバ１０３において、受信処理部１３０Ｓが、パケット９００を受信する（Ｓ１０１１）。
【００６２】
パケット番号制御部２３１Ｓが、受信したパケット９００のヘッダ２５から部分パケット番号９１０を取得する（Ｓ１０１２）。また、パケット番号制御部２３１Ｓが、パケット＃６０２Ｓから部分パケット番号１０１０を取得する（Ｓ１０１３）。
【００６３】
パケット番号制御部２３１Ｓが、部分パケット番号９１０における上記最下位ｎビットが示す値が、部分パケット番号１０１０における上記最下位ｎビットが示す値より大きいか否かを判断する（Ｓ１０１４）。
【００６４】
Ｓ１０１４の判断結果が偽の場合（Ｓ１０１４：Ｎｏ）、すなわち、部分パケット番号９１０における上記最下位ｎビットが示す値が、部分パケット番号１０１０における上記最下位ｎビットよりも小さい場合、パケット番号制御部２３１Ｓは、パケット＃６０２Ｓのsequence_numberのうち、最下位ｎビットの上位（Ｗ−ｎ）ビット（ここでは上位４２ビット）をインクリメントする（Ｓ１０１５）。つまり、最下位ｎビットが示す最大値を超えていわゆる桁上がりが生じたと推定される。
【００６５】
Ｓ１０１４の判断結果が真の場合（Ｓ１０１４：Ｙｅｓ）、パケット番号制御部２３１Ｓが、受信したパケット９００についてのパケット番号が、パケット＃６０２Ｓの上位（Ｗ−ｎ）ビットと、取得された部分パケット番号９１０における上記最下位ｎビットとの結合であると推定する。一方、Ｓ１０１４の判断結果が偽の場合（Ｓ１０１４：Ｎｏ）、Ｓ１０１５が行われたため、パケット番号制御部２３１Ｓは、受信したパケット９００についてのパケット番号が、パケット＃６０２Ｓのインクリメント後の上位（Ｗ−ｎ）ビットと、取得された部分パケット番号９１０における上記最下位ｎビットとの結合であると推定する。
【００６６】
パケット処理部２３２Ｓは、推定されたパケット番号を用いてパケット９００の処理を行う。具体的には、例えば、以下の通りである。
【００６７】
すなわち、パケット処理部２３２Ｓは、推定されたパケット番号がＯＫか否かを判断する（Ｓ１０１６）。具体的には、例えば、下記が行われる。
・パケット処理部２３２Ｓは、推定されたパケット番号を用いてopaque８０６（暗号化データ）を復号する。
・パケット処理部２３２Ｓは、当該復号により得られたメッセージと、推定されたパケット番号を用いて、ＭＡＣを算出する。
・パケット処理部２３２Ｓは、算出されたＭＡＣと、受信したパケット９００が含むＭＡＣとが一致するか否かを判断する。ＭＡＣが一致すれば、推定されたパケット番号がＯＫである。別の言い方をすれば、許容される同期ずれを超えた同期ずれが生じている場合、ＭＡＣは不一致である。
【００６８】
Ｓ１０１６の判断結果が真の場合（Ｓ１０１６：Ｙｅｓ）、パケット処理部２３２Ｓが、パケット＃６０２Ｓを、推定されたパケット番号に更新する（Ｓ１０１７）。
【００６９】
Ｓ１０１６の判断結果が偽の場合（Ｓ１０１６：Ｎｏ）、パケット処理部２３２Ｓが、同期ずれ用処理を行う（Ｓ１０１８）。同期ずれ用処理は、例えば下記うちのいずれかを含んだ処理でよい。
・パケット＃６０２Ｓを元に戻す（ロールバック）。
・パケット＃６０２Ｓを、Ｓ１０１６の判断結果が偽のケースにおける推定されたパケット番号に更新する。
【００７０】
以上が、実施例１の説明である。
【００７１】
なお、実施例１では、同期ずれが生じていない状況では、パケット送信前には、パケット＃６０２Ｃとパケット＃６０２Ｓは一致している。しかし、本発明はそのような例に限らず、同期ずれが生じていない状況で、パケット送信前には、パケット＃６０２Ｃはパケット＃６０２Ｓよりも１だけ大きくてもよい。例えば、ＩｏＴ機器１０１において、パケット生成部２２１Ｃは、パケットの生成前にパケット＃６０２Ｃを更新せず、更新前のパケット＃６０２Ｃから部分パケット番号を取得し、当該取得した部分パケット番号９１０を含んだヘッダ９１０を有するパケット９００を生成し、その後パケット＃６０２Ｃを更新してもよい。
【００７２】
また、上記ｍ及びｎのうちの少なくとも一つの値は可変でよい。例えば、ＩｏＴ機器１０１とＩｏＴサーバ１０３とのハンドシェークにおいて、送信処理部１１０Ｃ及び受信処理部１３０Ｓは、ＩｏＴ機器１０１とＩｏＴサーバ１０３間の通信品質を特定することができる。そこで、上記ｍ及びｎのうちの少なくとも一つの値（例えば、sequence_numberのうちの最下位ｎビットにおけるｎの値）が、当該ハンドシェークにおいて、送信処理部１１０Ｃ及び受信処理部１３０Ｓの少なくとも一方により（例えば受信処理部１３０Ｓ内のパケット番号制御部２３１Ｓにより）、特定された通信品質と、許容された同期ずれとに基づいて、決定されてよい。
【００７３】
また、詳細な説明は省略されているが、ＩｏＴ機器においては、Ｓ１００１の前に、パケット生成部２２１Ｃは、セッション番号とepochをキーにクライアントパケットＤＢ２１２Ｃを検索し、パケット＃６０２Ｃを取得してもよい。ＩｏＴサーバにおいては、Ｓ１０１３の前に、セッション番号とepoch最下位ｍビットをキーにクライアントパケットＤＢ２１２Ｓを検索し、検索結果のうち最も大きな＃６０２Ｓを取得してもよい。
【実施例２】
【００７４】
実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略又は簡略する。
【００７５】
図１１は、実施例２に係るＩｏＴサーバ及びＩｏＴ機器の機能を示す。
【００７６】
ＩｏＴサーバ１１０３の送信処理部１１１０Ｓ（パケット生成部１２２１Ｓ及びパケット送信部１２２２Ｓ）及び受信処理部１１３０Ｓ（パケット番号制御部１２３１Ｓ及びパケット処理部１２３２Ｓ）が、実施例１での送信処理部１１０Ｓ及び受信処理部１３０Ｓと異なる。
【００７７】
同様に、ＩｏＴ機器１１０１の送信処理部１１１０Ｃ（パケット生成部１２２１Ｃ及びパケット送信部１２２２Ｃ）及び受信処理部１１３０Ｃ（パケット番号制御部１２３１Ｃ及びパケット処理部１２３２Ｃ）が、実施例１での送信処理部１１０Ｃ及び受信処理部１３０Ｃと異なる。
【００７８】
実施例２では、小サイズヘッダとして、パケット番号に代えて部分パケット番号を有するヘッダに代えて、パケット番号及び部分パケット番号のいずれも有しないヘッダが採用される。具体的には、実施例２では、Ｎ回のパケット送信のうちの１回のパケット送信では、図１２に示す大サイズパケット１２００が送信され、Ｎ回のパケット送信のうちの残りのパケット送信の各々では、図１３に示す小サイズパケット１３００が送信される。
【００７９】
図１２は、大サイズパケット１２００の構成を示す。
【００８０】
大サイズパケット１２００は、大サイズヘッダ３５（第３のヘッダの一例）とopaque８０６とを有する。大サイズヘッダ３５は、パケット番号８１０（具体的には、図８に示した比較例に従う情報８０１〜８０６）と、パケット番号８１０を有するか否かを示すflag１２とを有する。パケット番号８１０がある場合、flag１２の値は“０”である。パケット番号８１０が無い場合、flag１２の値は“１”である。
【００８１】
図１３は、小サイズパケット１３００の構成を示す。
【００８２】
小サイズパケット１２００は、小サイズヘッダ４５（第２のヘッダの一例）とopaque８０６とを有する。小サイズヘッダ４５は、大サイズヘッダ３５が有する情報のうち、パケット番号８１０以外を有する。言い換えれば、小サイズヘッダ４５は、パケット番号８１０のサイズ分（パケット番号８１０を有さない分）、大サイズヘッダ３５よりもサイズが小さい。
【００８３】
上述したように、Ｎ回のパケット送信のうち１回のパケット送信でのみ、大サイズパケット１２００が送信され、それ以外のパケット送信では小サイズパケット１３００が送信される。これにより、Ｎ回のパケット送信全体について、ヘッダのデータ量を削減することができ、故に、ＤＴＬＳ／ＵＤＰの効率的なパケット通信が可能である。なお、Ｎの値は、例えば記憶部３０２（及び２０２）に設定される。Ｎの値は、ＩｏＴ機器１０１毎に異なってもよいしセッション毎に異なってもよい。
【００８４】
図１４は、実施例２に係るパケット送受信処理の流れを示す。
【００８５】
ＩｏＴ機器１１０１の送信処理部１１１０ＣとＩｏＴサーバ１１０３の受信処理部１１３０Ｓとの間で実施例１と同様のハンドシェークが行われた後、パケットの送受信の都度に、下記が行われる。
【００８６】
ＩｏＴ機器１１０１において、パケット生成部１２２１Ｃが、パケット＃６０２Ｃをインクリメントする（Ｓ１４０１）。パケット生成部１２２１Ｃが、パケット＃６０２Ｃを取得する（Ｓ１４０２）。パケット生成部１２２１Ｃが、パケット送信回数ＸがＮに達しているか否かを判断する（Ｓ１４０３）。パケット送信回数Ｘは、例えば記憶部３０２に格納されている。
【００８７】
Ｓ１４０３の判断結果が真の場合（Ｓ１４０３：Ｙｅｓ）、パケット生成部１２２１Ｃが、Ｘを０（初期値）に戻し（Ｓ１４０４）、大サイズパケット１２００を生成する（Ｓ１４０５）。パケット送信部１２２２Ｃが、生成された大サイズパケット１２００をＩｏＴサーバ１１０３に送信する（Ｓ１４０６）。
【００８８】
Ｓ１４０３の判断結果が偽の場合（Ｓ１４０３：Ｎｏ）、パケット生成部１２２１Ｃが、Ｘをインクリメントし（Ｓ１４０７）、小サイズパケット１３００を生成する（Ｓ１４０８）。パケット送信部１２２２Ｃが、生成された小サイズパケット１３００をＩｏＴサーバ１１０３に送信する（Ｓ１４０９）。
【００８９】
ＩｏＴサーバ１１０３において、受信処理部１１３０Ｓが、パケット１２００又は１３００を受信する（Ｓ１４１１）。パケット番号制御部１２３１Ｓが、flag１２が“０”か否かを判断する（Ｓ１４１２）。
【００９０】
Ｓ１４１２の判断結果が偽の場合（Ｓ１４１２：Ｎｏ）、Ｓ１４１３が行われる。すなわち、パケット番号制御部１２３１Ｓが、セッションＩＤをキーにパケット＃６０２Ｓを取得する。この取得されたパケット＃６０２Ｓが、受信されたパケット１３００についての推定されたパケット番号に相当する。パケット処理部１２３２Ｓは、当該推定されたパケット番号を用いて、opaque８０６（暗号化データ）を復号する。
【００９１】
Ｓ１４１２の判断結果が真の場合（Ｓ１４１２：Ｙｅｓ）、Ｓ１４１４が行われる。すなわち、パケット番号制御部１２３１Ｓが、大サイズヘッダ３５からパケット番号８１０を取得する。パケット番号制御部１２３１Ｓが、パケット＃６０２Ｓを取得し、パケット番頭のsequence number（Ｃ）とパケット＃６０２Ｓのsequence number（Ｄ）を比較する（Ｓ１４１５）。
【００９２】
Ｓ１４１５の判断結果が真の場合（Ｓ１４１５：Ｙｅｓ）、Ｓ１４１６が行われる。すなわち、パケット処理部１２３２Ｓは、当該パケット番号８１０を用いて、opaque８０６（暗号化データ）を復号する。
【００９３】
Ｓ１４１５の判断結果が偽の場合（Ｓ１４１５：Ｎｏ）、パケット処理部１２３２Ｓが、同期ずれ用処理を行う（Ｓ１４１８）。同期ずれ用処理は、例えば下記うちのいずれかを含んだ処理でよい。
・パケット＃６０２Ｓを変更しない（パケット＃６０２Ｓを維持する）。
・パケット＃６０２Ｓをインクリメントする。
【００９４】
Ｓ１４１３又はＳ１４１５の後、パケット処理部１２３２Ｓは、推定されたパケット番号がＯＫか否かを判断する（Ｓ１４１６）。具体的には、例えば、下記が行われる。
・パケット処理部１２３２Ｓは、Ｓ１４１３又はＳ１４１５の復号により得られたメッセージと、推定されたパケット番号を用いて、ＭＡＣを算出する。
・パケット処理部１２３２Ｓは、算出されたＭＡＣと、受信したパケット１２００又は１３００が含むＭＡＣとが一致するか否かを判断する。ＭＡＣが一致すれば、推定されたパケット番号がＯＫである。別の言い方をすれば、許容される同期ずれを超えた同期ずれが生じている場合、ＭＡＣは不一致である。
【００９５】
Ｓ１４１６の判断結果が真の場合（Ｓ１４１６：Ｙｅｓ）、パケット処理部１２３２Ｓが、パケット＃６０２Ｓをインクリメントする（Ｓ１４１７）。
【００９６】
Ｓ１４１６の判断結果が偽の場合（Ｓ１４１６：Ｎｏ）、パケット処理部１２３２Ｓが、同期ずれ用処理を行う（Ｓ１４１８）。同期ずれ用処理は、例えば下記うちのいずれかを含んだ処理でよい。
・パケット＃６０２Ｓを変更しない（パケット＃６０２Ｓを維持する）。
・パケット＃６０２Ｓをインクリメントする。
【００９７】
以上が、実施例２の説明である。
【００９８】
また、Ｎの値（言い換えれば、flag１２の値が“０”となる頻度）は可変でよい。例えば、ＩｏＴ機器１１０１とＩｏＴサーバ１１０３とのハンドシェークにおいて、送信処理部１１１０Ｃ及び受信処理部１１３０Ｓは、ＩｏＴ機器１１０１とＩｏＴサーバ１１０３間の通信品質を特定することができる。そこで、Ｎの値が、当該ハンドシェークにおいて、送信処理部１１１０Ｃ及び受信処理部１１３０Ｓの少なくとも一方により（例えば受信処理部１１３０Ｓ内のパケット番号制御部１２３１Ｓにより）、特定された通信品質と、許容された同期ずれとに基づいて、決定されてよい。
【００９９】
以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。例えば、上述の実施例では、ＩｏＴでのクライアントサーバ間の通信が例として採用されているが、本発明は、他のクライアントサーバ間通信にも適用可能であるし、クライアントサーバ間通信以外のデータ通信（例えばＰ２Ｐのデータ通信）にも適用可能である。
【符号の説明】
【０１００】
１０３…ＩｏＴサーバ
【図１】
2020137093.tif 000003
【図２】
2020137093.tif 000004
【図３】
2020137093.tif 000005
【図４】
2020137093.tif 000006
【図５】
2020137093.tif 000007
【図６】
2020137093.tif 000008
【図７】
2020137093.tif 000009
【図８】
2020137093.tif 000010
【図９】
2020137093.tif 000011
【図１０】
2020137093.tif 000012
【図１１】
2020137093.tif 000013
【図１２】
2020137093.tif 000014
【図１３】
2020137093.tif 000015
【図１４】
2020137093.tif 000016