JP7173271B2 - ネットワーク通信システム - Google Patents
ネットワーク通信システム Download PDFInfo
- Publication number
- JP7173271B2 JP7173271B2 JP2021195508A JP2021195508A JP7173271B2 JP 7173271 B2 JP7173271 B2 JP 7173271B2 JP 2021195508 A JP2021195508 A JP 2021195508A JP 2021195508 A JP2021195508 A JP 2021195508A JP 7173271 B2 JP7173271 B2 JP 7173271B2
- Authority
- JP
- Japan
- Prior art keywords
- communication
- terminal device
- address
- data
- terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Description
本発明は、ネットワークを介した通信システムに関し、特に、家電製品などの様々なＩｏＴ機器について、インターネットを介して通信を行うネットワーク通信システムに関する。
近年、パソコンやスマートフォンをはじめとする様々な機器がインターネットに接続されるようになってきており、ネットワークを介した機器間通信の技術も広く普及している。特に、最近では、ＩｏＴ（Internet of Things）という考え方の下に、家電製品から自動車の電装品に至るまで、様々な電化製品をインターネットに接続して利用する技術が普及し始めており、外出中に、スマートフォンなどの端末装置から、インターネットを介して自宅の家電製品や自動車の電装品などのＩｏＴ機器を制御することができるようになってきている。
スマートフォンなどのモバイル端末の場合、ネットワーク上での所在が所在地により変化するため、通信相手の現時点の所在アドレスを何らかの方法で認識する必要がある。このような観点から、二者間の通信を取り継ぐ役割を果たす中継装置を設けたネットワーク通信システムが提案されている。たとえば、下記の特許文献１には、第１の端末装置と中継装置との間にセキュアな第１の通信チャネルを確保し、第２の端末装置と中継装置との間にセキュアな第２の通信チャネルを確保して、中継装置を介して両者間で通信を行うネットワーク通信システムが開示されている。ただ、このような中継装置を利用したシステムでは、両者間の通信データがすべて中継装置を経由することになるため、中継装置に多大な処理負荷がかかるという問題がある。
そこで、最近は、ＳＩＰ（Session Initiation Protocol）と呼ばれるプロトコルを利用して、ネットワーク上に設けられた接続仲介装置により、両者間での通信セッション確立の取り継ぎを行い、通信セッション確立後は、両者間で直接通信を行う方式が提案されている。たとえば、下記の特許文献２，３には、このＳＩＰを利用したＶＰＮ通信を実現するネットワーク通信システムが開示されている。また、下記の特許文献４には、上記ＳＩＰを利用した方法を改善して、接続仲介装置の処理負担を更に軽減したネットワーク通信システムが開示されている。
上述したとおり、最近は、家電製品や自動車の電装品など、様々なＩｏＴ機器がインターネットに接続されるようになってきている。このように、ＩｏＴ機器をインターネットに接続して利用すれば、外出先からスマートフォンなどを用いて制御を行ったり、内蔵ファームウェアをインターネットを介してアップデートしたりすることができ、様々なメリットが得られるようになる。その一方で、インターネットに接続すると、外部からのハッキングを受ける危険性を孕む要因になるというデメリットも生じる。
パソコンなどのコンピュータ機器では、通常、ルータやファイアウォールを介してインターネットへの接続を行う方法が採られており、また、十分なセキュリティを確保するために、ウィルス対策ソフトなどをインストールして用いるのが一般的である。しかしながら、家電製品や自動車の電装品などのＩｏＴ機器の場合、一般的なコンピュータ機器に比べて、ＣＰＵやメモリの構成が貧弱であり、十分なセキュリティ対策が施されていないのが現状である。また、このようなＩｏＴ機器は、コンピュータの知識のない一般利用者が容易に利用できるように、複雑な手順を踏まずに簡便な方法で導入できるように設計されていることが多い。
たとえば、パーソナルユースを想定した監視カメラなどのＩｏＴ機器の場合、グローバルＩＰアドレスを付与して、インターネットに直接接続して利用するタイプのものも少なくない。このようなＩｏＴ機器は、セキュリティ対策が極めて不十分であり、外部からのハッキング攻撃に対して無防備と言わざるを得ない。ＩｏＴ機器が、サイバー攻撃によってマルウェアに感染し、ボット化されると、被害は更に広がることになる。もちろん、ＩｏＴ機器についても、一般のコンピュータと同様に十分なセキュリティ対策を施すことが好ましいが、そのためには、ＣＰＵ性能やメモリ容量の拡充が必要になり、コストの増大が避けられなくなる。
そこで本発明は、パーソナルユースを想定した安価なＩｏＴ機器を、十分なセキュリティを確保しながらインターネットに接続することができるネットワーク通信システムを提供することを目的とする。
(1)本発明の第１の態様は、ネットワーク通信システムにおいて、ネットワークを介して相互に接続可能な複数の端末装置と、複数の端末装置間の接続を仲介する接続仲介装置と、端末装置のうちの１台を包含するゲートウェイ装置と、を設け、
複数の端末装置には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置は、端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行し、
複数の端末装置のそれぞれは、
自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置に対して通知する自己アドレス通知部と、
自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける通信要求受付部と、
通信要求受付部によって通信要求が受け付けられたときに、接続仲介装置に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する接続仲介依頼部と、
接続仲介依頼に応じて、接続仲介装置から、通信先の別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてきたときに、ネットワークを介して、通信先アドレスにアクセスして通信開始要求を行う通信開始要求部と、
通信開始要求に応じて、通信先の別な端末装置から、通信開始受諾確認が返信されてきたら、通信先の別な端末装置との間に通信セッションを確立して通信を開始する通信元セッション確立部と、
通信元の別な端末装置から、自己を通信先とする通信開始要求がなされたら、通信元の別な端末装置に対して通信開始受諾確認を送信し、通信元の別な端末装置との間に通信セッションを確立して通信を開始する通信先セッション確立部と、
を有し、
接続仲介装置は、
端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルを格納するアドレステーブル格納部と、
端末装置の自己アドレス通知部からの通知に基づいて、アドレステーブルの内容を更新するアドレステーブル更新部と、
端末装置の接続仲介依頼部から、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する通信先アドレス返信部と、
を有し、
ゲートウェイ装置は、下流側に接続された１台もしくは複数台のＩｏＴ機器を、上流側に接続されたネットワークに接続する役割を果たし、
ゲートウェイ装置には包含されていない外部端末装置が、ゲートウェイ装置の下流側に接続されている特定のＩｏＴ機器に対する通信を行う際に、
外部端末装置の接続仲介依頼部が、ゲートウェイ装置に包含されている内部端末装置を特定するための通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
外部端末装置の通信開始要求部が、接続仲介依頼に応じて返信されてきた通信先アドレスにアクセスして通信開始要求を行い、
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、内部端末装置に対して、特定のＩｏＴ機器に送信すべきＩｏＴ機器宛データと特定のＩｏＴ機器を特定する機器特定情報とが含まれた通信データを送信し、ゲートウェイ装置は、上記通信データを受信したときに、通信データから機器特定情報およびＩｏＴ機器宛データを抽出し、ＩｏＴ機器宛データを、機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
複数の端末装置には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置は、端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行し、
複数の端末装置のそれぞれは、
自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置に対して通知する自己アドレス通知部と、
自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける通信要求受付部と、
通信要求受付部によって通信要求が受け付けられたときに、接続仲介装置に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する接続仲介依頼部と、
接続仲介依頼に応じて、接続仲介装置から、通信先の別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてきたときに、ネットワークを介して、通信先アドレスにアクセスして通信開始要求を行う通信開始要求部と、
通信開始要求に応じて、通信先の別な端末装置から、通信開始受諾確認が返信されてきたら、通信先の別な端末装置との間に通信セッションを確立して通信を開始する通信元セッション確立部と、
通信元の別な端末装置から、自己を通信先とする通信開始要求がなされたら、通信元の別な端末装置に対して通信開始受諾確認を送信し、通信元の別な端末装置との間に通信セッションを確立して通信を開始する通信先セッション確立部と、
を有し、
接続仲介装置は、
端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルを格納するアドレステーブル格納部と、
端末装置の自己アドレス通知部からの通知に基づいて、アドレステーブルの内容を更新するアドレステーブル更新部と、
端末装置の接続仲介依頼部から、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する通信先アドレス返信部と、
を有し、
ゲートウェイ装置は、下流側に接続された１台もしくは複数台のＩｏＴ機器を、上流側に接続されたネットワークに接続する役割を果たし、
ゲートウェイ装置には包含されていない外部端末装置が、ゲートウェイ装置の下流側に接続されている特定のＩｏＴ機器に対する通信を行う際に、
外部端末装置の接続仲介依頼部が、ゲートウェイ装置に包含されている内部端末装置を特定するための通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
外部端末装置の通信開始要求部が、接続仲介依頼に応じて返信されてきた通信先アドレスにアクセスして通信開始要求を行い、
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、内部端末装置に対して、特定のＩｏＴ機器に送信すべきＩｏＴ機器宛データと特定のＩｏＴ機器を特定する機器特定情報とが含まれた通信データを送信し、ゲートウェイ装置は、上記通信データを受信したときに、通信データから機器特定情報およびＩｏＴ機器宛データを抽出し、ＩｏＴ機器宛データを、機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
(2)本発明の第２の態様は、上述した第１の態様に係るネットワーク通信システムにおいて、
特定のＩｏＴ機器が、特定の外部端末装置に対する通信を行う際に、
特定のＩｏＴ機器が、内部端末装置の通信要求受付部に対して、特定の外部端末装置を特定するための端末装置特定情報と、上記特定のＩｏＴ機器を特定する機器特定情報と、特定の外部端末装置に送信すべき端末装置宛データと、を通信要求として送信し、
内部端末装置の接続仲介依頼部が、端末装置特定情報で特定される端末装置を通信先とする通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
内部端末装置の通信開始要求部が、接続仲介依頼に応じて返信されてきた通信先アドレスにアクセスして通信開始要求を行い、
内部端末装置の通信元セッション確立部と、特定の外部端末装置の通信先セッション確立部との間で通信を行う際に、内部端末装置から特定の外部端末装置に対して、機器特定情報と端末装置宛データとが含まれた通信データを送信するようにしたものである。
特定のＩｏＴ機器が、特定の外部端末装置に対する通信を行う際に、
特定のＩｏＴ機器が、内部端末装置の通信要求受付部に対して、特定の外部端末装置を特定するための端末装置特定情報と、上記特定のＩｏＴ機器を特定する機器特定情報と、特定の外部端末装置に送信すべき端末装置宛データと、を通信要求として送信し、
内部端末装置の接続仲介依頼部が、端末装置特定情報で特定される端末装置を通信先とする通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
内部端末装置の通信開始要求部が、接続仲介依頼に応じて返信されてきた通信先アドレスにアクセスして通信開始要求を行い、
内部端末装置の通信元セッション確立部と、特定の外部端末装置の通信先セッション確立部との間で通信を行う際に、内部端末装置から特定の外部端末装置に対して、機器特定情報と端末装置宛データとが含まれた通信データを送信するようにしたものである。
(3)本発明の第３の態様は、ネットワーク通信システムにおいて、ネットワークを介して相互に接続可能な複数の端末装置と、複数の端末装置間の接続を仲介する接続仲介装置と、端末装置のうちの１台を包含するゲートウェイ装置と、を設け、
複数の端末装置には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置は、端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行し、
複数の端末装置のそれぞれは、
自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置に対して通知する自己アドレス通知部と、
自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける通信要求受付部と、
通信要求受付部によって通信要求が受け付けられたときに、接続仲介装置に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する接続仲介依頼部と、
接続仲介装置から、通信元の別な端末装置のネットワーク上での所在を示す通信元アドレスが送信されてきたときに、ネットワークを介して、通信元アドレスにアクセスして通信開始要求を行う通信開始要求部と、
通信開始要求に応じて、通信元の別な端末装置から、通信開始受諾確認が返信されてきたら、通信元の別な端末装置との間に通信セッションを確立して通信を開始する通信先セッション確立部と、
通信先の別な端末装置から、自己を通信元とする通信開始要求がなされたら、通信先の別な端末装置に対して通信開始受諾確認を送信し、通信先の別な端末装置との間に通信セッションを確立して通信を開始する通信元セッション確立部と、
を有し、
接続仲介装置は、
端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルを格納するアドレステーブル格納部と、
端末装置の自己アドレス通知部からの通知に基づいて、アドレステーブルの内容を更新するアドレステーブル更新部と、
端末装置の接続仲介依頼部から、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスに対して、接続仲介依頼を送信した通信元の端末装置の端末ＩＤに対応づけられている所在アドレスを通信元アドレスとして送信する通信元アドレス送信部と、
を有し、
ゲートウェイ装置は、下流側に接続された１台もしくは複数台のＩｏＴ機器を、上流側に接続されたネットワークに接続する役割を果たし、
ゲートウェイ装置には包含されていない外部端末装置が、ゲートウェイ装置の下流側に接続されている特定のＩｏＴ機器に対する通信を行う際に、
外部端末装置の接続仲介依頼部が、ゲートウェイ装置に包含されている内部端末装置を特定するための通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
内部端末装置の通信開始要求部が、接続仲介依頼に応じて送信されてきた通信元アドレスにアクセスして通信開始要求を行い、
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、内部端末装置に対して、特定のＩｏＴ機器に送信すべきＩｏＴ機器宛データと特定のＩｏＴ機器を特定する機器特定情報とが含まれた通信データを送信し、
ゲートウェイ装置は、上記通信データを受信したときに、通信データから機器特定情報およびＩｏＴ機器宛データを抽出し、ＩｏＴ機器宛データを、機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
複数の端末装置には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置は、端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行し、
複数の端末装置のそれぞれは、
自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置に対して通知する自己アドレス通知部と、
自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける通信要求受付部と、
通信要求受付部によって通信要求が受け付けられたときに、接続仲介装置に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する接続仲介依頼部と、
接続仲介装置から、通信元の別な端末装置のネットワーク上での所在を示す通信元アドレスが送信されてきたときに、ネットワークを介して、通信元アドレスにアクセスして通信開始要求を行う通信開始要求部と、
通信開始要求に応じて、通信元の別な端末装置から、通信開始受諾確認が返信されてきたら、通信元の別な端末装置との間に通信セッションを確立して通信を開始する通信先セッション確立部と、
通信先の別な端末装置から、自己を通信元とする通信開始要求がなされたら、通信先の別な端末装置に対して通信開始受諾確認を送信し、通信先の別な端末装置との間に通信セッションを確立して通信を開始する通信元セッション確立部と、
を有し、
接続仲介装置は、
端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルを格納するアドレステーブル格納部と、
端末装置の自己アドレス通知部からの通知に基づいて、アドレステーブルの内容を更新するアドレステーブル更新部と、
端末装置の接続仲介依頼部から、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスに対して、接続仲介依頼を送信した通信元の端末装置の端末ＩＤに対応づけられている所在アドレスを通信元アドレスとして送信する通信元アドレス送信部と、
を有し、
ゲートウェイ装置は、下流側に接続された１台もしくは複数台のＩｏＴ機器を、上流側に接続されたネットワークに接続する役割を果たし、
ゲートウェイ装置には包含されていない外部端末装置が、ゲートウェイ装置の下流側に接続されている特定のＩｏＴ機器に対する通信を行う際に、
外部端末装置の接続仲介依頼部が、ゲートウェイ装置に包含されている内部端末装置を特定するための通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
内部端末装置の通信開始要求部が、接続仲介依頼に応じて送信されてきた通信元アドレスにアクセスして通信開始要求を行い、
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、内部端末装置に対して、特定のＩｏＴ機器に送信すべきＩｏＴ機器宛データと特定のＩｏＴ機器を特定する機器特定情報とが含まれた通信データを送信し、
ゲートウェイ装置は、上記通信データを受信したときに、通信データから機器特定情報およびＩｏＴ機器宛データを抽出し、ＩｏＴ機器宛データを、機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
(4)本発明の第４の態様は、上述した第３の態様に係るネットワーク通信システムにおいて、
特定のＩｏＴ機器が、特定の外部端末装置に対する通信を行う際に、
特定のＩｏＴ機器が、内部端末装置の通信要求受付部に対して、特定の外部端末装置を特定するための端末装置特定情報と、上記特定のＩｏＴ機器を特定する機器特定情報と、特定の外部端末装置に送信すべき端末装置宛データと、を通信要求として送信し、
内部端末装置の接続仲介依頼部が、端末装置特定情報で特定される端末装置を通信先とする通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
特定の外部端末装置の通信開始要求部が、接続仲介依頼に応じて送信されてきた通信元アドレスにアクセスして通信開始要求を行い、
内部端末装置の通信元セッション確立部と、特定の外部端末装置の通信先セッション確立部との間で通信を行う際に、内部端末装置から特定の外部端末装置に対して、機器特定情報と端末装置宛データとが含まれた通信データを送信するようにしたものである。
特定のＩｏＴ機器が、特定の外部端末装置に対する通信を行う際に、
特定のＩｏＴ機器が、内部端末装置の通信要求受付部に対して、特定の外部端末装置を特定するための端末装置特定情報と、上記特定のＩｏＴ機器を特定する機器特定情報と、特定の外部端末装置に送信すべき端末装置宛データと、を通信要求として送信し、
内部端末装置の接続仲介依頼部が、端末装置特定情報で特定される端末装置を通信先とする通信先特定情報を含む接続仲介依頼を接続仲介装置に対して送信し、
特定の外部端末装置の通信開始要求部が、接続仲介依頼に応じて送信されてきた通信元アドレスにアクセスして通信開始要求を行い、
内部端末装置の通信元セッション確立部と、特定の外部端末装置の通信先セッション確立部との間で通信を行う際に、内部端末装置から特定の外部端末装置に対して、機器特定情報と端末装置宛データとが含まれた通信データを送信するようにしたものである。
(5)本発明の第５の態様は、上述した第１～第４の態様に係るネットワーク通信システムにおいて、
ゲートウェイ装置が、受信した通信データに含まれている機器特定情報およびＩｏＴ機器宛データに基づいて、ＩｏＴ機器宛データを、機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
ゲートウェイ装置が、受信した通信データに含まれている機器特定情報およびＩｏＴ機器宛データに基づいて、ＩｏＴ機器宛データを、機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
(6)本発明の第６の態様は、上述した第５の態様に係るネットワーク通信システムにおいて、
ゲートウェイ装置内に、下流側に接続されている個々のＩｏＴ機器についての機器特定情報と、当該ＩｏＴ機器へのアクセス方法を示すアクセス方法情報と、を直接もしくは間接的に対応づけたＩｏＴ機器登録テーブルを格納しておき、
ゲートウェイ装置が、通信データを受信したときに、ＩｏＴ機器登録テーブルを参照することにより、受信した通信データから抽出した機器特定情報に対応するアクセス方法情報によって示されるアクセス方法を用いて配信先のＩｏＴ機器をアクセスし、受信した通信データから抽出したＩｏＴ機器宛データを、配信先のＩｏＴ機器に配信するようにしたものである。
ゲートウェイ装置内に、下流側に接続されている個々のＩｏＴ機器についての機器特定情報と、当該ＩｏＴ機器へのアクセス方法を示すアクセス方法情報と、を直接もしくは間接的に対応づけたＩｏＴ機器登録テーブルを格納しておき、
ゲートウェイ装置が、通信データを受信したときに、ＩｏＴ機器登録テーブルを参照することにより、受信した通信データから抽出した機器特定情報に対応するアクセス方法情報によって示されるアクセス方法を用いて配信先のＩｏＴ機器をアクセスし、受信した通信データから抽出したＩｏＴ機器宛データを、配信先のＩｏＴ機器に配信するようにしたものである。
(7)本発明の第７の態様は、上述した第６の態様に係るネットワーク通信システムにおいて、
ＩｏＴ機器登録テーブルに格納されている機器特定情報が、ＩｏＴ機器のメーカ名、製品型番および製品番号を含み、
ＩｏＴ機器登録テーブルに格納されているアクセス方法情報が、ＩｏＴ機器に対する通信を行う上での通信規格および当該通信規格に応じたアクセスを行う際の固有アドレスを含むようにしたものである。
ＩｏＴ機器登録テーブルに格納されている機器特定情報が、ＩｏＴ機器のメーカ名、製品型番および製品番号を含み、
ＩｏＴ機器登録テーブルに格納されているアクセス方法情報が、ＩｏＴ機器に対する通信を行う上での通信規格および当該通信規格に応じたアクセスを行う際の固有アドレスを含むようにしたものである。
(8)本発明の第８の態様は、上述した第１～第７の態様に係るネットワーク通信システムにおいて、
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、
ＩｏＴ機器宛データに対して、その宛先となる特定のＩｏＴ機器に格納されているユニークなデータもしくは当該データから一義的に求められる派生データを暗号鍵として用いた暗号化処理を施すことによりＩｏＴ機器宛暗号データを作成し、ＩｏＴ機器宛暗号データと機器特定情報とが含まれた暗号化通信データを送信し、
ゲートウェイ装置は、暗号化通信データを受信したときに、暗号化通信データから、機器特定情報およびＩｏＴ機器宛暗号データを抽出し、抽出した機器特定情報で特定されるＩｏＴ機器に格納されているユニークなデータもしくは当該データから一義的に求められる派生データを復号鍵として用いた復号処理を施すことによりＩｏＴ機器宛データを復元し、復元されたＩｏＴ機器宛データを、抽出した機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、
ＩｏＴ機器宛データに対して、その宛先となる特定のＩｏＴ機器に格納されているユニークなデータもしくは当該データから一義的に求められる派生データを暗号鍵として用いた暗号化処理を施すことによりＩｏＴ機器宛暗号データを作成し、ＩｏＴ機器宛暗号データと機器特定情報とが含まれた暗号化通信データを送信し、
ゲートウェイ装置は、暗号化通信データを受信したときに、暗号化通信データから、機器特定情報およびＩｏＴ機器宛暗号データを抽出し、抽出した機器特定情報で特定されるＩｏＴ機器に格納されているユニークなデータもしくは当該データから一義的に求められる派生データを復号鍵として用いた復号処理を施すことによりＩｏＴ機器宛データを復元し、復元されたＩｏＴ機器宛データを、抽出した機器特定情報によって特定されるＩｏＴ機器に配信するようにしたものである。
(9)本発明の第９の態様は、上述した第１～第８の態様に係るネットワーク通信システムにおいて、
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、
外部端末装置のＩＰアドレスを送信元アドレスとして含み、内部端末装置のＩＰアドレスを送信先アドレスとして含むＩＰヘッダ部と、ＩｏＴ機器宛データもしくはＩｏＴ機器宛暗号データと機器特定情報とを含むＩＰデータ部と、を有するＩＰパケットを作成することにより、ＩｏＴ機器宛データもしくはＩｏＴ機器宛暗号データをＩＰパケット内にカプセル化する処理を行い、このＩＰパケットを通信データもしくは暗号化通信データとして送信するようにしたものである。
外部端末装置の通信元セッション確立部が、内部端末装置の通信先セッション確立部に対して通信を行う際に、
外部端末装置のＩＰアドレスを送信元アドレスとして含み、内部端末装置のＩＰアドレスを送信先アドレスとして含むＩＰヘッダ部と、ＩｏＴ機器宛データもしくはＩｏＴ機器宛暗号データと機器特定情報とを含むＩＰデータ部と、を有するＩＰパケットを作成することにより、ＩｏＴ機器宛データもしくはＩｏＴ機器宛暗号データをＩＰパケット内にカプセル化する処理を行い、このＩＰパケットを通信データもしくは暗号化通信データとして送信するようにしたものである。
(10)本発明の第１０の態様は、上述した第９の態様に係るネットワーク通信システムにおいて、
内部端末装置が、特定のポートを有効ポートに設定し、所定の周期で、もしくは、有効ポートの設定に変更があったときに、現時点の有効ポートを接続仲介装置に対して通知し、ネットワークを介して送信されてきたＩＰパケットのうち、有効ポートに対応するポート番号が指定されているものだけを受信し、それ以外のＩＰパケットを拒絶する処理を行い、
接続仲介装置が、通信先アドレスとして、有効ポートのポート番号を含むアドレスを用いた仲介処理を行うようにしたものである。
内部端末装置が、特定のポートを有効ポートに設定し、所定の周期で、もしくは、有効ポートの設定に変更があったときに、現時点の有効ポートを接続仲介装置に対して通知し、ネットワークを介して送信されてきたＩＰパケットのうち、有効ポートに対応するポート番号が指定されているものだけを受信し、それ以外のＩＰパケットを拒絶する処理を行い、
接続仲介装置が、通信先アドレスとして、有効ポートのポート番号を含むアドレスを用いた仲介処理を行うようにしたものである。
(11)本発明の第１１の態様は、上述した第１０の態様に係るネットワーク通信システムにおいて、
内部端末装置が、常に、１つのポートのみを有効ポートとして設定するようにしたものである。
内部端末装置が、常に、１つのポートのみを有効ポートとして設定するようにしたものである。
(12)本発明の第１２の態様は、上述した第２または第４の態様に係るネットワーク通信システムにおいて、
内部端末装置の通信元セッション確立部が、外部端末装置の通信先セッション確立部に対して通信を行う際に、ゲートウェイ装置が、端末装置宛データに対して、その送信源となる特定のＩｏＴ機器に格納されているユニークなデータもしくは当該データから一義的に求められる派生データを暗号鍵として用いた暗号化処理を施すことにより端末装置宛暗号データを作成し、端末装置宛暗号データと機器特定情報とが含まれた暗号化通信データを送信し、
外部端末装置が、暗号化通信データを受信したときに、暗号化通信データに含まれている端末装置宛暗号データに対して、上記ユニークなデータもしくは当該データから一義的に求められる派生データを復号鍵として用いた復号処理を施すことにより端末装置宛データを復元するようにしたものである。
内部端末装置の通信元セッション確立部が、外部端末装置の通信先セッション確立部に対して通信を行う際に、ゲートウェイ装置が、端末装置宛データに対して、その送信源となる特定のＩｏＴ機器に格納されているユニークなデータもしくは当該データから一義的に求められる派生データを暗号鍵として用いた暗号化処理を施すことにより端末装置宛暗号データを作成し、端末装置宛暗号データと機器特定情報とが含まれた暗号化通信データを送信し、
外部端末装置が、暗号化通信データを受信したときに、暗号化通信データに含まれている端末装置宛暗号データに対して、上記ユニークなデータもしくは当該データから一義的に求められる派生データを復号鍵として用いた復号処理を施すことにより端末装置宛データを復元するようにしたものである。
(13)本発明の第１３の態様は、上述した第２、第４または第１２の態様に係るネットワーク通信システムにおいて、
内部端末装置の通信元セッション確立部が、外部端末装置の通信先セッション確立部に対して通信を行う際に、
内部端末装置のＩＰアドレスを送信元アドレスとして含み、外部端末装置のＩＰアドレスを送信先アドレスとして含むＩＰヘッダ部と、端末装置宛データもしくは端末装置宛暗号データと機器特定情報とを含むＩＰデータ部と、を有するＩＰパケットを作成することにより、端末装置宛データもしくは端末装置宛暗号データをＩＰパケット内にカプセル化する処理を行い、このＩＰパケットを通信データもしくは暗号化通信データとして送信するようにしたものである。
内部端末装置の通信元セッション確立部が、外部端末装置の通信先セッション確立部に対して通信を行う際に、
内部端末装置のＩＰアドレスを送信元アドレスとして含み、外部端末装置のＩＰアドレスを送信先アドレスとして含むＩＰヘッダ部と、端末装置宛データもしくは端末装置宛暗号データと機器特定情報とを含むＩＰデータ部と、を有するＩＰパケットを作成することにより、端末装置宛データもしくは端末装置宛暗号データをＩＰパケット内にカプセル化する処理を行い、このＩＰパケットを通信データもしくは暗号化通信データとして送信するようにしたものである。
(14)本発明の第１４の態様は、上述した第１～第１３の態様に係るネットワーク通信システムにおいて、
ゲートウェイ装置が、内部端末装置と、内部端末用仲介部と、下流側に接続されたＮ台（Ｎは自然数）のＩｏＴ機器に１対１に対応するＮ台の個別通信部と、を有しており、
個別通信部が、それぞれ対応するＩｏＴ機器との間で、所定の通信規格に基づいて相互通信する機能を有し、
内部端末用仲介部には、個々のＩｏＴ機器についての機器特定情報と、当該ＩｏＴ機器に対応する個別通信部と、を対応づけたＩｏＴ機器登録テーブルが格納されており、
内部端末用仲介部が、内部端末装置が受信した通信データもしくは暗号化通信データから、機器特定情報と、ＩｏＴ機器宛データもしくはＩｏＴ機器宛暗号データと、を抽出し、ＩｏＴ機器登録テーブルを参照することにより、抽出した機器特定情報に対応する個別通信部を選択し、選択された個別通信部に対して、抽出したＩｏＴ機器宛データもしくは抽出したＩｏＴ機器宛暗号データを復号して得られるＩｏＴ機器宛データを与える処理を行うようにしたものである。
ゲートウェイ装置が、内部端末装置と、内部端末用仲介部と、下流側に接続されたＮ台（Ｎは自然数）のＩｏＴ機器に１対１に対応するＮ台の個別通信部と、を有しており、
個別通信部が、それぞれ対応するＩｏＴ機器との間で、所定の通信規格に基づいて相互通信する機能を有し、
内部端末用仲介部には、個々のＩｏＴ機器についての機器特定情報と、当該ＩｏＴ機器に対応する個別通信部と、を対応づけたＩｏＴ機器登録テーブルが格納されており、
内部端末用仲介部が、内部端末装置が受信した通信データもしくは暗号化通信データから、機器特定情報と、ＩｏＴ機器宛データもしくはＩｏＴ機器宛暗号データと、を抽出し、ＩｏＴ機器登録テーブルを参照することにより、抽出した機器特定情報に対応する個別通信部を選択し、選択された個別通信部に対して、抽出したＩｏＴ機器宛データもしくは抽出したＩｏＴ機器宛暗号データを復号して得られるＩｏＴ機器宛データを与える処理を行うようにしたものである。
(15)本発明の第１５の態様は、上述した第１４の態様に係るネットワーク通信システムにおいて、
ゲートウェイ装置が、更に、通常ルータ部を有し、
通常ルータ部は、下流側に接続されたＩｏＴ機器を上流側に接続されたネットワークに接続するルーティング機能を有し、
内部端末装置が、接続仲介装置による仲介を経た通信のみを実行し、
通常ルータ部が、
(a) ＩｏＴ機器からネットワークへ向かう昇流通信、
(b) ネットワークからＩｏＴ機器へ向かう降流通信のうち、上記昇流通信に対する応答として戻ってきた降流通信、
(c) ネットワークからＩｏＴ機器へ向かう降流通信のうち、上記(b) 以外の降流通信、なる３形態の通信のうち、(a) および(b) の通信は実行し、(c) の通信は拒絶するようにしたものである。
ゲートウェイ装置が、更に、通常ルータ部を有し、
通常ルータ部は、下流側に接続されたＩｏＴ機器を上流側に接続されたネットワークに接続するルーティング機能を有し、
内部端末装置が、接続仲介装置による仲介を経た通信のみを実行し、
通常ルータ部が、
(a) ＩｏＴ機器からネットワークへ向かう昇流通信、
(b) ネットワークからＩｏＴ機器へ向かう降流通信のうち、上記昇流通信に対する応答として戻ってきた降流通信、
(c) ネットワークからＩｏＴ機器へ向かう降流通信のうち、上記(b) 以外の降流通信、なる３形態の通信のうち、(a) および(b) の通信は実行し、(c) の通信は拒絶するようにしたものである。
(16)本発明の第１６の態様は、上述した第１～第１５の態様に係るネットワーク通信システムにおけるゲートウェイ装置に係るものである。
(17)本発明の第１７の態様は、上述した第１～第１５の態様に係るネットワーク通信システムを、コンピュータにプログラムを組み込むことにより構成したものである。
本発明に係るネットワーク通信システムでは、接続仲介装置によって、両端末装置間の通信セッション確立までの仲介処理が行われる。しかも、１台の端末装置はゲートウェイ装置に組み込まれ、このゲートウェイ装置の下流側に個々のＩｏＴ機器が接続される。そして、特定のＩｏＴ機器に対してデータを送信する際には、まず、接続仲介装置による仲介を経て、ゲートウェイ装置まで当該データを送信し、その後、当該データを、ゲートウェイ装置から特定のＩｏＴ機器に対して配信する処理が行われる。このように、ＩｏＴ機器宛データは、接続仲介装置およびゲートウェイ装置による仲介を経て送信されるため、ＩｏＴ機器が外部からハッキングされる事態を抑止することが可能になり、個々のＩｏＴ機器自身に十分なセキュリティ対策が施されていなかったとしても、個々のＩｏＴ機器を、十分なセキュリティを確保しながらインターネットに接続することができるようになる。
以下、本発明を図示する実施形態に基づいて説明する。なお、ここで述べる実施形態は、ＰＣＴ／ＪＰ２０１６／０５５９６０に基づく優先権主張を伴う国際出願ＰＣＴ／ＪＰ２０１７／００６１３１（国際公開第ＷＯ２０１７/１４５９８４号：以下、先願となる国際出願と呼ぶ）に記載された発明（以下、先願基本発明と呼ぶ）を利用した発明に係るものである。そこで、以下の§１～§４において、まず、先願基本発明の説明を行い、§５以降において、この先願基本発明を利用した本発明の実施形態について述べることにする。したがって、以下の§１～§４で述べる内容（図１～図２０に示す内容）は、先願基本発明に係る国際公開第ＷＯ２０１７/１４５９８４号公報に記載された実施形態と実質的に同じものである。
＜＜＜§１．先願基本発明の第１の実施形態＞＞＞
＜１－１．先願基本発明の第１の実施形態の構成＞
図１は、先願基本発明の第１の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。図示のとおり、このネットワーク通信システムは、接続仲介装置１００と複数の端末装置２００Ａ～２００Ｄによって構成されており、これらの各装置はいずれもネットワークＮ（この例では、インターネット）を介して相互に接続することが可能である。
＜１－１．先願基本発明の第１の実施形態の構成＞
図１は、先願基本発明の第１の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。図示のとおり、このネットワーク通信システムは、接続仲介装置１００と複数の端末装置２００Ａ～２００Ｄによって構成されており、これらの各装置はいずれもネットワークＮ（この例では、インターネット）を介して相互に接続することが可能である。
図では、説明の便宜上、４台の端末装置２００Ａ～２００Ｄを用いた例を示すことにするが、実用上は、より多数の端末装置を利用するのが一般的である。各端末装置２００Ａ～２００Ｄは、共通の構成を有する同一の装置である。そこで、ここでは、この共通の端末装置について言及する場合は符号２００を用いて示し、相互に区別する必要がある場合には、符号末尾にＡ～Ｄを付して示すことにする。端末装置２００の内部構成要素を示す各符号についても同様である。
結局、このネットワーク通信システムは、ネットワークＮを介して相互に接続可能な複数の端末装置２００Ａ～２００Ｄと、これら複数の端末装置間の接続を仲介する接続仲介装置１００と、を備えたシステムということになる。端末装置２００としては、パソコン、携帯電話、タブレット型端末など、ネットワークＮに接続して通信を行う機能を有する様々な電子機器を利用することができる。一方、接続仲介装置１００は、これら各端末装置２００Ａ～２００ＤからネットワークＮを介してアクセスを受けるサーバコンピュータによって構成されている。
各端末装置２００Ａ～２００Ｄには、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置１００は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。ここでは、図示のとおり、端末装置２００Ａ，２００Ｂ，２００Ｃ，２００Ｄには、それぞれ「００１０」，「００２０」，「００３０」，「００４０」なる端末ＩＤが付与されているものとする。
なお、先願基本発明を実施する上で、端末ＩＤは、個々の端末装置を相互に識別することができる情報であれば、どのような情報であってもかまわない。図示の例では、４台の端末装置しか用いられていないため、「００１０」のような４桁の数字を端末ＩＤとして用いれば十分であるが、各端末装置を相互に識別するためには、ユニークなＩＤを用いる必要があるので、実用上は、より桁数の多い数字もしくは数字とアルファベットの組み合わせを用いるのが好ましい。具体的には、個々の端末装置に内蔵されているＣＰＵのシリアル番号、通信インターフェイスに付与されたＭＡＣアドレス、携帯電話を端末装置として用いる場合は電話番号やＳＩＭカードのシリアル番号、などを端末ＩＤとして用いることが可能である。
各端末装置２００Ａ～２００Ｄには、それぞれ自己のネットワーク上での所在を示す所在アドレスが付与されている。図示の例の場合、端末装置２００Ａ，２００Ｂ，２００Ｃ，２００Ｄには、それぞれＡＤ１，ＡＤ２，ＡＤ３，ＡＤ４なる所在アドレスが付与されている。所在アドレスとしては、ネットワーク上で当該端末装置の所在を一義的に決定できるアドレスであれば、どのようなアドレスを用いてもよい。図示の例のように、ネットワークＮとしてインターネットを用い、通信プロトコルとしてＩＰを利用する場合は、個々の端末装置２００のネットワークＮ上での所在を示す所在アドレスとして、グローバルＩＰアドレスもしくはＮＡＴ－ＩＤを用いるのが好ましい。
端末ＩＤが、個々の端末装置を相互に識別するために必要な情報であるのに対して、所在アドレスは、ネットワークＮを介して個々の端末装置をアクセスするために必要な情報である。しかも多くの端末装置の場合、所在アドレスは常に一定ではなく、時事刻々と変化する。たとえば、携帯電話やモバイルパソコンなどの携帯型端末装置の場合、移動とともに交信相手となる基地局が変化するため、所在アドレスも時間的に変化する。また、デスクトップ型パソコンのような定点設置型の端末装置の場合も、プロバイダから付与されるＩＰアドレスなどが更新されるため、やはり所在アドレスが時間的に変化するのが一般的である。
後述するように、先願基本発明に用いる端末装置２００は、自己のネットワーク上での所在を示す所在アドレスを、ネットワークＮを介して接続仲介装置１００に通知する機能を有している。このため、接続仲介装置１００は、各端末装置２００Ａ～２００Ｄの最新アドレスを常に把握することができ、必要に応じて、各端末装置２００Ａ～２００Ｄにアクセスすることが可能である。
図示のとおり、接続仲介装置１００には、アドレステーブル格納部１１０、アドレステーブル更新部１２０、通信先アドレス返信部１３０が設けられている。前述したとおり、この接続仲介装置１００は、実際には、サーバコンピュータなどのコンピュータによって構成される。したがって、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築されることになる。
アドレステーブル格納部１１０には、各端末装置２００Ａ～２００Ｄのそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルＴが格納されており、アドレステーブル更新部１２０は、各端末装置２００Ａ～２００Ｄからの通知に基づいて、このアドレステーブルＴの内容を更新する処理を行う。また、通信先アドレス返信部１３０は、各端末装置２００Ａ～２００Ｄから接続仲介依頼があると、アドレステーブルＴを参照することにより、通信先アドレスを返信する処理を行う。
図には、アドレステーブルＴとして、４台の端末装置２００Ａ～２００Ｄのそれぞれについて、端末ＩＤと所在アドレスとの対応関係を示す情報が格納されている。具体的には、端末装置２００Ａについては端末ＩＤ「００１０」と所在アドレス「ＡＤ１」とが対応づけられ、端末装置２００Ｂについては端末ＩＤ「００２０」と所在アドレス「ＡＤ２」とが対応づけられ、端末装置２００Ｃについては端末ＩＤ「００３０」と所在アドレス「ＡＤ３」とが対応づけられ、端末装置２００Ｄについては端末ＩＤ「００４０」と所在アドレス「ＡＤ４」とが対応づけられている。
続いて、図２を参照しながら、端末装置２００の詳細構成および個々の構成要素の具体的な処理動作を説明する。図示のとおり、端末装置２００には、接続仲介依頼部２１０、通信要求受付部２２０、通信先セッション確立部２３０、通信開始要求部２４０、自己アドレス通知部２５０、通信元セッション確立部２６０が設けられている。
この端末装置２００も、実際には、種々のコンピュータ（携帯電話などの機器も含む）によって構成され、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築される。なお、実際の端末装置２００には、この他にも種々の構成要素が組み込まれている。たとえば、端末装置２００がスマートフォンであれば、様々なアプリケーションプログラムを組み込むことにより、様々な処理機能をもった構成要素が付加されることになるが、ここでは、先願基本発明に直接関係する構成要素のみを図にブロックとして示すことにし、その他の構成要素についての説明は省略する。もちろん、端末装置２００には、ユーザからの指示入力や文字入力を行う入力インターフェイスや、ユーザに情報を提示するためのディスプレイなどの構成要素も備わっているが、これらの構成要素についての説明も省略する。
結局、図２において、端末装置２００内に６つのブロックとして描かれている構成要素は、先願基本発明に係る端末装置２００において必須の機能要素ということになる。このブロック図には、各ブロック間の信号の流れを示す矢印として、太線矢印、細線矢印、白抜矢印の３通りの矢印が用いられている。ここで、太線矢印は、端末装置２００と接続仲介装置１００との間でやりとりされる、通信セッション確立前の信号の流れを示しており、細線矢印は、一対の端末装置２００の間でやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置２００の間でやりとりされる、通信セッション確立後の信号の流れを示している。
また、図２では、端末装置２００内の６つの構成要素が、楕円、矩形、二重矩形という３通りのブロックを用いて描かれているが、これは、各構成要素の役割分担を示すための便宜である。具体的には、楕円ブロックで示されている構成要素は、端末装置２００が「アドレス通知」の処理を実行するための構成要素であり、矩形ブロックで示されている構成要素は、端末装置２００が「通信元」として機能する場合に必要な処理を実行する構成要素であり、二重矩形ブロックで示されている構成要素は、端末装置２００が「通信先」として機能する場合に必要な処理を実行する構成要素である。
本願において、「通信元」および「通信先」という用語は、２台の端末装置が相互に通信を行う場合に、これら２台を区別するために用いる用語であり、自発的に通信を開始するための処理を行う側を「通信元」と呼び、この「通信元」からの働きかけに応じて、当該「通信元」と通信を行うために必要な処理を行う側を「通信先」と呼んでいる。たとえば，２台の端末装置を電話として使う場合、発呼側の装置が「通信元」であり、着呼側の装置が「通信先」になる。「通信元」の端末装置は、特定の「通信先」を指定して、自発的に通信を開始するための処理を行うことになる。
もちろん、端末装置２００は、「通信元」になったり「通信先」になったりする。「通信元」になったときには、図２に矩形ブロックで示されている構成要素による処理が行われ、「通信先」になったときには、図２に二重矩形ブロックで示されている構成要素による処理が行われる。以下、端末装置２００の６つの構成要素の各機能を順に説明する。
上述したように、楕円ブロックで示されている自己アドレス通知部２５０は、「アドレス通知」の処理を実行するための構成要素であり、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１００に対して通知する処理を実行する。所在アドレスとしてＩＰアドレスを用いるのであれば、自己アドレス通知部２５０は、現時点で自己に付与されたＩＰアドレスをネットワークＮを介して接続仲介装置１００に通知する処理を行うことになる。
通常、インターネットに接続可能な端末装置２００には、インターネットプロバイダから所定のグローバルＩＰアドレスが付与されるので、自己アドレス通知部２５０は、端末装置２００に付与されたグローバルＩＰアドレスを、所在アドレスとして接続仲介装置１００に対して通知すればよい。また、ルータのＮＡＴ機能を利用して、プライベートＩＰアドレスが付与されている場合には、ＮＡＴ－ＩＤを所在アドレスとして接続仲介装置１００に対して通知すればよい。所在アドレスを通知する際には、端末ＩＤを同時に送信するようにする。
図１に示すアドレステーブル更新部１２０は、このような通知を受けて、アドレステーブルＴの更新を行う。たとえば、端末装置２００Ａから接続仲介装置１００に対して、端末ＩＤ「００１０」と所在アドレス「ＡＤ１」とが通知された場合、アドレステーブル更新部１２０は、端末ＩＤ「００１０」と所在アドレス「ＡＤ１」とを対応づけてアドレステーブルＴに格納する処理を行う。
前述したとおり、一般的な端末装置２００の場合、所在アドレスが時間的に変化する。したがって、実用上は、自己アドレス通知部２５０には、所定周期で繰り返して、現時点の自己（端末装置２００）の所在アドレスを通知する機能をもたせておくのが好ましい。たとえば、自己アドレス通知部２５０が１分おきに繰り返し通知を行うようにすれば、アドレステーブルＴは１分おきに最新の情報に更新されることになる。
あるいは、自己アドレス通知部２５０には、自己（端末装置２００）の所在アドレスが変更になったときに、現時点の所在アドレスを通知する機能をもたせておくようにしてもよい。すなわち、初めて所在アドレスが付与された段階で、当該所在アドレスを初期状態のアドレスとして通知させ、その後は、所在アドレスが変更になるたびに新たな所在アドレスを通知させるようにすればよい。もちろん、所定周期で繰り返し通知する運用と、所在アドレスが変更になったときに通知する運用とを組み合わせてもかまわない。
次に、図２に矩形ブロックで示されている４つの構成要素について説明する。上述したように、これら４つの構成要素は、端末装置２００が「通信元」として機能する場合に必要な処理を実行する。
まず、通信要求受付部２２０は、自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける処理を行う。たとえば、端末装置２００（通信元）のユーザが、特定の相手に電話をかけたい場合、当該相手が所持する別な端末装置（通信先）に対して通信を行いたい旨の通信要求を行うことになる。この通信要求は、たとえば、図示されていない入力インターフェイスを介したユーザの操作入力（たとえば、タッチパネル上での操作）として与えられ、相手先の端末装置を特定するための何らかの情報を含むものになる。
接続仲介依頼部２１０は、通信要求受付部２２０によって通信要求が受け付けられたときに、接続仲介装置１００に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する。ここで、接続仲介依頼に含まれる通信先特定情報は、通信先の別な端末装置の端末ＩＤであってもよいし、当該端末ＩＤを特定することが可能な別な情報であってもかまわない（詳細は、§３－１で述べる）。
こうして、接続仲介依頼部２１０から送信された接続仲介依頼は、ネットワークＮを介して接続仲介装置１００へと伝達される（前述したように、図における太線矢印は、端末装置２００と接続仲介装置１００との間でやりとりされる、通信セッション確立前の信号の流れを示している）。すると、接続仲介装置１００からは、図に太線矢印で示すように、通信先となる別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてくる。これは、図１に示す通信先アドレス返信部１３０の機能によるものである。
すなわち、通信先アドレス返信部１３０は、端末装置２００の接続仲介依頼部２１０から、接続仲介依頼が送信されてきたときに、アドレステーブルＴを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する処理を行う。もちろん、返信の相手先は、接続仲介依頼を行った端末装置２００である。要するに、通信先アドレス返信部１３０は、通信元の端末装置から通信先を特定した接続仲介依頼があると、アドレステーブルＴを用いて、当該通信先の現時点での所在アドレスを検索し、これを通信元の端末装置に返信する処理を行うことになる。
このように、接続仲介依頼部２１０によって接続仲介依頼を行うと、接続仲介装置１００からは、通信先の別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてくる。こうして返信されてきた通信先アドレスは、通信開始要求部２４０によって受信される。通信開始要求部２４０は、この通信先アドレスにネットワークＮを介してアクセスして通信開始要求を行う。図に細線矢印で示すとおり、この通信開始要求は、１台の端末装置２００（通信元）から別な１台の端末装置２００（通信先）に宛てた信号ということになる。
このように、通信開始要求部２４０によって、通信先の別な端末装置に対して通信開始要求を送信すると、当該通信先の別な端末装置からは、この通信開始要求に応じて、通信開始受諾確認が返信されてくる（図の右側の細線矢印：この返信処理については、通信先の別な端末装置の通信先セッション確立部２３０の処理として後述する）。こうして返信されてきた通信開始受諾確認は、通信元セッション確立部２６０によって受信される。通信元セッション確立部２６０は、この通信開始受諾確認を受信したら、当該通信先の別な端末装置との間に通信セッションを確立して通信を開始する。図２の右端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
以上、図２に矩形ブロックで示されている４つの構成要素、すなわち、端末装置２００が「通信元」として機能する場合に処理を実行する構成要素について説明したが、続いて、図２に二重矩形ブロックで示されている構成要素、すなわち、端末装置２００が「通信先」として機能する場合に処理を実行する構成要素について説明する。
図２において、二重矩形ブロックで示されている構成要素は、通信先セッション確立部２３０である。この通信先セッション確立部２３０は、通信元の別な端末装置から、自己を通信先とする通信開始要求がなされたら（図の左側の下向き細線矢印）、当該通信元の別な端末装置に対して通信開始受諾確認を送信し（図の左側の上向き細線矢印）、当該通信元の別な端末装置との間に通信セッションを確立して通信を開始する。図２の左端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
結局、通信元端末装置と通信先端末装置との間の通信セッション確立後の通信は、通信元端末装置の通信元セッション確立部２６０と通信先端末装置の通信先セッション確立部２３０との間で行われることになる。別言すれば、図２の右端の白抜矢印は、ネットワークＮを介して、図２の左端の白抜矢印に連なることになる。
＜１－２．第１の実施形態における具体的な通信手順＞
これまで、図１および図２を参照しながら、先願基本発明の第１の実施形態に係るネットワーク通信システムの構成要素である接続仲介装置１００および端末装置２００の各構成要素およびその機能を説明した。ここでは、この第１の実施形態に係るネットワーク通信システムにおける通信手順を、具体例に即して説明することにする。
これまで、図１および図２を参照しながら、先願基本発明の第１の実施形態に係るネットワーク通信システムの構成要素である接続仲介装置１００および端末装置２００の各構成要素およびその機能を説明した。ここでは、この第１の実施形態に係るネットワーク通信システムにおける通信手順を、具体例に即して説明することにする。
図３は、図２に示す端末装置における自己アドレス通知部２５０の機能を示すブロック図である。図の上段には接続仲介装置１００が示され、図の下段には２組の端末装置２００Ａ，２００Ｂが示されている。ここでは、端末装置２００Ｃ，２００Ｄの図示は省略するが、自己アドレス通知部２５０の機能は同じである。なお、前述したとおり、接続仲介装置１００と各端末装置２００Ａ，２００Ｂとの間の情報のやりとり（太線矢印で示す）は、実際にはネットワークＮを介して行われるが、ここでは説明の便宜上、ネットワークＮの図示は省略する。
図３に示す端末装置２００Ａ，２００Ｂは、図２に示す端末装置２００と同様に６つの構成要素を有している。すなわち、端末装置２００Ａは、構成要素２１０Ａ～２６０Ａを有し、端末装置２００Ｂは、構成要素２１０Ｂ～２６０Ｂを有しており、これら各構成要素は、図２に示す構成要素２１０～２６０と同一のものである（符号末尾のＡ，Ｂは、いずれの端末装置の構成要素であるかを区別するために付したものである）。なお、この図３は、端末装置２００Ａ，２００Ｂの自己アドレス通知機能を説明するための図であるので、自己アドレス通知部２５０Ａ，２５０Ｂ以外の構成要素のブロックは破線で示してある。
自己アドレス通知部２５０Ａ，２５０Ｂは、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１００内のアドレステーブル更新部１２０に対して通知する処理を行う。図３には、自己アドレス通知部２５０Ａからアドレステーブル更新部１２０への通知として、「００１０：ＡＤ１」なるデータが送信されている例が示されているが、これは、自己の端末ＩＤ「００１０」とともに自己の現時点での所在アドレス「ＡＤ１」を送信していることを示している。同様に、自己アドレス通知部２５０Ｂからアドレステーブル更新部１２０への通知として、「００２０：ＡＤ２」なるデータが送信されている例が示されているが、これは、自己の端末ＩＤ「００２０」とともに自己の現時点での所在アドレス「ＡＤ２」を送信していることを示している。
各端末装置２００Ａ，２００Ｂの自己アドレス通知部２５０Ａ，２５０Ｂから、このような通知を受けたアドレステーブル更新部１２０が、当該通知に基づいて、アドレステーブルＴの内容を更新する処理を行う点は、既に§１－１で述べたとおりである。また、自己アドレス通知部２５０Ａ，２５０Ｂが、所定周期で繰り返して、もしくは、所在アドレスが変更になったときに、現時点の所在アドレスを通知する処理を行う点も§１－１で述べたとおりである。
このように、自己アドレス通知部２５０が行う所在アドレスの通知処理は、端末装置間の通信を開始するための直接的な処理ではないが、いつでも通信を開始できるようにするための準備処理ということができる。この通知処理を行うことにより、接続仲介装置１００内のアドレステーブルＴを最新の状態に保つことができ、実際に、特定の端末装置間で通信を行う必要が生じたときに、接続仲介装置１００による正しい仲介処理が実現できるのである。
続いて、特定の端末装置間で実際に通信を開始する際の処理手順を説明する。図４は、図１に示すネットワーク通信システムにおいて、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の通信セッション確立の手順を示すブロック図である。この図４においても、図の上段には接続仲介装置１００が示され、図の下段には２組の端末装置２００Ａ，２００Ｂが示されている。ここでも、接続仲介装置１００と端末装置２００Ａとの間の情報のやりとり（太線矢印で示す）や、端末装置２００Ａ，２００Ｂ間の情報のやりとり（細線矢印で示す）は、実際にはネットワークＮを介して行われるが、説明の便宜上、ネットワークＮの図示は省略する。
また、ここでは、説明の便宜上、端末装置２００Ａを通信元、端末装置２００Ｂを通信先とした場合の手順を説明する。このため、図４では、通信元端末装置２００Ａ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）のみを実線で示し、通信先端末装置２００Ｂ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）のみを実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。
一方、図５は、図４のブロック図に示されている通信セッション確立手順を時系列で説明する流れ図である。以下、図４のブロック図を参照しながら、図５の流れ図に従って、第１の実施形態における具体的な通信手順を説明する。なお、図４のブロック図において、各矢印に付された符号Ｓ１～Ｓ７は、図５の流れ図における各ステップＳ１～Ｓ７に対応するものである。逆に、図５の流れ図の各ステップにおいて、括弧書きで示された符号は、図４のブロック図における特定のブロックに対応するものであり、当該ステップの内容に関連する特定の構成要素を示すものである。
まず、ステップＳ１において、通信要求受付処理が行われる。これは、図４に示す通信要求受付部２２０Ａによって行われる処理であり、たとえば、通信元端末装置２００ＡのユーザＡが、通信先端末装置２００ＢのユーザＢに対して電話をしたい、という場合に、ユーザＡの操作入力に基づいて行われる処理である。たとえば、各端末装置２００Ａ，２００Ｂが携帯電話であり、端末ＩＤとして、それぞれの電話番号を用いている場合は、ユーザＡは端末装置２００Ａに対して、端末装置２００Ｂの端末ＩＤ（電話番号）を入力する操作を伴う通信要求Ｓ１を行えばよい。すなわち、端末装置２００Ａの通信要求受付部２２０Ａは、自己を通信元として、通信先の別な端末装置２００Ｂに対する通信要求Ｓ１を受け付ける処理を行うことになる。
なお、通信要求受付部２２０Ａが通信要求Ｓ１を受け付けるのは、必ずしもユーザＡが電話をかけるための操作入力を行った場合に限られるわけではない。たとえば、ユーザＡ，Ｂが通信対戦型のゲームをプレイしている場合は、当該ゲーム用のアプリケーションプログラムから通信要求受付部２２０Ａに対して通信要求Ｓ１が与えられることになる。あるいは、端末装置２００Ａ，２００Ｂが何らかのビジネス処理を行うパソコンであり、パソコン２００Ａに組み込まれたビジネス処理用のアプリケーションプログラムが、パソコン２００Ｂに対して自動的に定時報告を行うような場合、当該アプリケーションプログラムから通信要求受付部２２０Ａに対して通信要求Ｓ１が与えられることになる。このように、先願基本発明における通信要求は、必ずしもユーザによって与えられるものではなく、端末装置に組み込まれているプログラムによって与えられる場合もある。
こうして、ステップＳ１において通信要求受付が行われると、続くステップＳ２において、接続仲介依頼が行われる。これは、図４に示す接続仲介依頼部２１０Ａによって行われる処理であり、既に述べたとおり、接続仲介装置１００に対して、通信先の別な端末装置２００Ｂの端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼Ｓ２を送信する処理である。
なお、一般に、ネットワークを介して接続された二者間で情報の送受を行う場合、情報の送信側は自分のアドレスを受信側に伝達し、受信側は当該送信側アドレス宛にアクノレッジ信号を返信する処理を行う。したがって、接続仲介依頼部２１０Ａから接続仲介依頼Ｓ２を送信する際には、自己の所在アドレス「ＡＤ１」が接続仲介装置１００側に伝達されることになる。後述するステップＳ４における返信処理は、この所在アドレス「ＡＤ１」宛に行われる。
こうして、通信元端末装置２００Ａの接続仲介依頼部２１０Ａから、接続仲介装置１００へ接続仲介依頼が送信されてくると、ステップＳ３において、この接続仲介依頼を受けた通信先アドレス返信部１３０が、アドレステーブル格納部１１０に格納されているアドレステーブルを参照して、当該接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤ（この例では、「００２０」）に対応づけられている所在アドレスを通信先アドレスとして認識する。たとえば、その時点におけるアドレステーブルＴが、図１に示すようなものであったとすると、端末ＩＤ「００２０」に対応づけられているアドレス「ＡＤ２」が通信先アドレスとして認識される。
そこで、ステップＳ４において、通信先アドレス返信部１３０が、ステップＳ３で認識した通信先アドレス「ＡＤ２」を返信する処理を行う。もちろん、返信相手は、ステップＳ２において接続仲介依頼を行った通信元端末装置２００Ａである。前述したとおり、接続仲介依頼Ｓ２には通信元端末装置２００Ａの所在アドレス「ＡＤ１」の情報が含まれているので、通信先アドレス返信部１３０は、当該所在アドレス「ＡＤ１」宛に、通信先アドレス「ＡＤ２」を返信することができる。
こうして、通信先アドレス返信部１３０から通信先アドレス返信Ｓ４（通信先アドレス「ＡＤ２」を伝達する情報）が送信されてくると、当該通信先アドレス返信Ｓ４は、通信開始要求部２４０Ａによって受信される。結局、通信元端末装置２００Ａが、接続仲介装置１００に対して接続仲介依頼Ｓ２を行うと、この接続仲介依頼Ｓ２に応じて、接続仲介装置１００から、通信先端末装置２００Ｂのネットワーク上での所在を示す通信先アドレス「ＡＤ２」が返信されてくることになる。接続仲介装置１００に用意されているアドレステーブルＴは、常に最新の状態に更新されているので、返信されてきた通信先アドレス「ＡＤ２」は、通信先端末装置２００Ｂの最新の所在アドレスということになる。
そこで、この通信先アドレス返信Ｓ４により、通信先アドレス「ＡＤ２」を取得した通信開始要求部２４０Ａは、ステップＳ５において、通信先端末装置２００Ｂに対して通信開始要求Ｓ５を行う。すなわち、ネットワークＮを介して、通信先アドレス「ＡＤ２」宛にアクセスを行い、相手方に通信開始の要求を伝える。このとき、自己の所在アドレス（通信元アドレス「ＡＤ１」）も併せて伝達されることになる。
通信先アドレス「ＡＤ２」宛に行われた通信開始要求Ｓ５は、通信先端末装置２００Ｂの通信先セッション確立部２３０Ｂによって受信される。通信先セッション確立部２３０Ｂは、通信元端末装置２００Ａから、自己（端末装置２００Ｂ）を通信先とする通信開始要求Ｓ５がなされたら、まず、ステップＳ６において、ネットワークＮを介して通信元端末装置２００Ａに対して通信開始受諾確認Ｓ６を送信する。そして、続くステップＳ７において、通信元端末装置２００Ａとの間に通信セッションを確立して通信Ｓ７を開始する。
一方、通信元端末装置２００Ａ宛に送信されてきた通信開始受諾確認Ｓ６は、通信元セッション確立部２６０Ａによって受信される。そして、ステップＳ７では、この通信開始受諾確認Ｓ６を受信した通信元セッション確立部２６０Ａが、通信先端末装置２００Ｂとの間に通信セッションを確立して通信Ｓ７を開始する処理も行われる。要するに、通信元端末装置２００Ａ側では、通信開始要求Ｓ５に応じて、通信先端末装置２００Ｂから通信開始受諾確認Ｓ６が返信されてきたら、当該通信先端末装置２００Ｂとの間に通信セッションを確立して通信を開始する処理を行うことになる。
かくして、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間に通信セッションが確立され、両者間での通信Ｓ７が行われることになる。この図５に示す流れ図において、接続仲介装置１００が行った処理は、ステップＳ３のアドレステーブル参照処理とステップＳ４の通信先アドレス返信処理だけである。すなわち、接続仲介装置１００が行う仲介処理は、通信元端末装置２００Ａからの接続仲介依頼Ｓ２を受けて、アドレステーブルＴを参照し（ステップＳ３）、得られた通信先アドレスを通信元端末装置２００Ａに対して返信する（ステップＳ４）だけである。接続仲介装置１００がこのような仲介処理を行うだけで、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間に通信セッションが確立され、両者間での通信が開始することになる。
このように、先願基本発明の第１の実施形態に係るネットワーク通信システムでは、接続仲介装置１００の処理負荷は極めて軽くなる。前述したように、ＳＩＰを利用して両端末間の接続仲介処理を行うシステムでは、従来型の中継処理に比べれば、その処理負荷は軽減されることになるが、両端末間にセッションが確立するまで関与する必要があり、多数の端末装置からの仲介依頼が集中すると、その処理負荷はかなり重くなってくる。これに対して、先願基本発明の第１の実施形態に係るシステムの場合、接続仲介装置１００は、両端末間に通信セッションが確立するまで関与する必要はなく、通信元端末装置に対して通信先アドレスを伝達する処理を行えば足りる。このため、一対の端末装置間の接続を仲介する際の処理負荷を、より軽減することが可能になる。
このように、先願基本発明の第１の実施形態に係るネットワーク通信システムでは、接続仲介装置１００が通信セッション確立まで関与しないため、接続仲介装置１００は、両端末装置間に通信セッションが確立し、支障なく通信が行われているか否かを把握することはできない。そこで、もし必要があれば、通信セッション確立後に、通信元セッション確立部２６０Ａもしくは通信先セッション確立部２３０Ｂから接続仲介装置１００に対して、支障なく通信セッションが確立した旨の報告を行うようにしてもよい。
なお、上述の実施例では、通信先セッション確立部２３０Ｂが、通信元端末装置２００Ａから、自己を通信先とする通信開始要求Ｓ５がなされた時に、ステップＳ６において、当該通信元端末装置２００Ａに対して通信開始受諾確認を送信する、という説明を行ったが、場合によっては、通信開始要求Ｓ５を受諾せずに拒絶し、通信開始受諾確認を送信しないようにしてもよい（あるいは、通信開始受諾確認の代わりに、通信開始拒絶通知を送信するようにしてもよい）。すなわち、通信先セッション確立部２３０Ｂに何らかの条件判断機能をもたせておき、通信開始要求Ｓ５がなされた場合、所定の条件を満たしている場合に限り、通信開始受諾確認を送信する処理を行わせるようにすればよい。
たとえば、通信先端末装置２００ＢのユーザＢが、通信先セッション確立部２３０に対して、着信拒否の設定を行えるようにし、「着信拒否の設定がなされていない」という条件を満たす場合にのみ、通信開始受諾確認を送信する処理が行われるようにすればよい。また、通信開始要求Ｓ５に、通信元端末装置２００Ａを特定するための何らかの通信元特定情報（たとえば、端末ＩＤ）を含ませるようにしておけば、通信先セッション確立部２３０Ｂは、通信開始要求Ｓ５を行った通信元に応じて、当該要求を受諾したり拒絶したりする処理が可能になる。
たとえば、通信先セッション確立部２３０Ｂに、通信開始要求Ｓ５を常に拒絶する通信元リスト（いわゆるブラックリスト）や通信開始要求Ｓ５を常に受諾する通信元リスト（いわゆるホワイトリスト）を用意しておけば、通信先セッション確立部２３０Ｂは、当該リストを参照することにより、通信開始要求Ｓ５を受諾するか拒絶するかの判断を行うことができる。
また、§３－３で述べるように、セキュリティを向上させる変形例を採用する場合は、通信開始要求Ｓ５に何らかのセキュリティ上の問題が存在する場合には、これを拒絶する運用を採用することも可能である。
＜＜＜§２．先願基本発明の第２の実施形態＞＞＞
＜２－１．先願基本発明の第２の実施形態の構成＞
続いて、先願基本発明の第２の実施形態を説明する。図６は、この第２の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。図示のとおり、このネットワーク通信システムは、接続仲介装置３００と複数の端末装置４００Ａ～４００Ｄによって構成されており、これらの各装置はいずれもネットワークＮ（この例では、インターネット）を介して相互に接続することが可能である。
＜２－１．先願基本発明の第２の実施形態の構成＞
続いて、先願基本発明の第２の実施形態を説明する。図６は、この第２の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。図示のとおり、このネットワーク通信システムは、接続仲介装置３００と複数の端末装置４００Ａ～４００Ｄによって構成されており、これらの各装置はいずれもネットワークＮ（この例では、インターネット）を介して相互に接続することが可能である。
ここでも、説明の便宜上、４台の端末装置４００Ａ～４００Ｄを用いた例を示すことにするが、実用上は、より多数の端末装置を利用するのが一般的である。各端末装置４００Ａ～４００Ｄは、共通の構成を有する同一の装置であり、この共通の端末装置について言及する場合は符号４００を用いて示し、相互に区別する必要がある場合には、符号末尾にＡ～Ｄを付して示すことにする。端末装置４００の内部構成要素を示す各符号についても同様である。
この図６に示すネットワーク通信システムは、ネットワークＮを介して相互に接続可能な複数の端末装置４００Ａ～４００Ｄと、これら複数の端末装置間の接続を仲介する接続仲介装置３００と、を備えたシステムということになる。やはり端末装置４００としては、パソコン、携帯電話、タブレット型端末など、ネットワークＮに接続して通信を行う機能を有する様々な電子機器を利用することができる。また、接続仲介装置３００は、これら各端末装置４００Ａ～４００ＤからネットワークＮを介してアクセスを受けるサーバコンピュータによって構成されている。
各端末装置４００Ａ～４００Ｄには、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置３００は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。端末ＩＤとしては、前述したとおり、個々の端末装置を相互に識別することができる情報であれば、どのような情報を利用してもかまわない。ここでは、前述した第１の実施形態の場合と同様に、端末装置４００Ａ，４００Ｂ，４００Ｃ，４００Ｄには、それぞれ「００１０」，「００２０」，「００３０」，「００４０」なる端末ＩＤが付与されているものとする。
また、各端末装置４００Ａ～４００Ｄには、それぞれ自己のネットワーク上での所在を示す所在アドレスが付与されている。ここでも、前述した第１の実施形態の場合と同様に、端末装置４００Ａ，４００Ｂ，４００Ｃ，４００Ｄに、それぞれＡＤ１，ＡＤ２，ＡＤ３，ＡＤ４なる所在アドレスが付与されているものとする。この所在アドレスは、ネットワーク上で当該端末装置の所在を一義的に決定できるアドレスであれば、どのようなアドレスを用いてもよいが、実用上は、グローバルＩＰアドレスもしくはＮＡＴ－ＩＤを用いればよい。前述したとおり、この所在アドレスは、時間的に変化する。
図示のとおり、接続仲介装置３００には、アドレステーブル格納部３１０、アドレステーブル更新部３２０、通信元アドレス送信部３３０が設けられている。この接続仲介装置３００は、実際には、サーバコンピュータなどのコンピュータによって構成される。したがって、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築されることになる。
アドレステーブル格納部３１０は、図１に示すアドレステーブル格納部１１０と同じ構成要素であり、各端末装置４００Ａ～４００Ｄのそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルＴを格納する機能を有する。図６に示すアドレステーブルＴは、図１に示すアドレステーブルＴと全く同じものである。アドレステーブル更新部３２０は、図１に示すアドレステーブル更新部１２０と同じ構成要素であり、各端末装置４００Ａ～４００Ｄからの通知に基づいて、アドレステーブルＴの内容を更新する処理を行う。このように、図６に示す構成要素３１０，３２０は、実質的に図１に示す構成要素１１０，１２０と同じものであるため、ここでは詳細な説明は省略する。
一方、通信元アドレス送信部３３０は、図１に示す通信先アドレス返信部１３０に類似した機能を有する構成要素であるが、若干異なる動作を行う。すなわち、通信元アドレス送信部３３０は、各端末装置４００Ａ～４００Ｄから接続仲介依頼があると、アドレステーブルＴを参照することにより通信先アドレスを認識し、当該通信先アドレス宛に、通信元アドレスを送信する処理を行う。この処理のより詳細な説明は後述する。
続いて、図７を参照しながら、端末装置４００の詳細構成および個々の構成要素の具体的な処理動作を説明する。図示のとおり、端末装置４００には、接続仲介依頼部４１０、通信要求受付部４２０、通信元セッション確立部４３０、通信開始要求部４４０、自己アドレス通知部４５０、通信先セッション確立部４６０が設けられている。
この端末装置４００も、実際には、種々のコンピュータ（携帯電話などの機器も含む）によって構成され、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築される。もちろん、この端末装置４００にも、必要に応じて、図示されていない種々の構成要素や入出力インターフェイスが組み込まれているが、ここでは、先願基本発明に直接関係する構成要素のみを図にブロックとして示すことにし、その他の構成要素についての説明は省略する。
この図７においても、図２と同様に、各ブロック間の信号の流れを示す太線矢印は、端末装置４００と接続仲介装置３００との間でやりとりされる、通信セッション確立前の信号の流れを示しており、細線矢印は、一対の端末装置４００の間でやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置４００の間でやりとりされる、通信セッション確立後の信号の流れを示している。
また、図２と同様に、図７に楕円ブロックで示されている構成要素は、端末装置４００が「アドレス通知」の処理を実行するための構成要素であり、矩形ブロックで示されている構成要素は、端末装置４００が「通信元」として機能する場合に必要な処理を実行する構成要素であり、二重矩形ブロックで示されている構成要素は、端末装置４００が「通信先」として機能する場合に必要な処理を実行する構成要素である。端末装置４００が、「通信元」になったときには、図７に矩形ブロックで示されている構成要素による処理が行われ、「通信先」になったときには、図７に二重矩形ブロックで示されている構成要素による処理が行われる。以下、図７に示す端末装置４００の６つの構成要素の各機能を順に説明する。
まず、楕円ブロックで示されている自己アドレス通知部４５０は、「アドレス通知」の処理を実行するための構成要素であり、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置３００に対して通知する処理を実行する。この自己アドレス通知部４５０の機能は、図２に示す自己アドレス通知部２５０の機能と全く同じであるため、ここでは詳しい説明は省略する。図６に示すアドレステーブル更新部３２０は、この通知を受けて、アドレステーブルＴの更新を行う。
次に、図７に矩形ブロックもしくは二重矩形ブロックで示されている５つの構成要素について説明する。上述したように、矩形ブロックで示されている３つの構成要素は、端末装置４００が「通信元」として機能する場合に必要な処理を実行し、二重矩形ブロックで示されている２つの構成要素は、端末装置４００が「通信先」として機能する場合に必要な処理を実行する。
まず、通信要求受付部４２０は、自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける処理を行う構成要素であり、図２に示す通信要求受付部２２０と全く同じ機能をもつ構成要素である。また、接続仲介依頼部４１０は、通信要求受付部４２０によって通信要求が受け付けられたときに、接続仲介装置３００に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する構成要素であり、図２に示す接続仲介依頼部２１０と全く同じ機能をもつ構成要素である。
こうして、接続仲介依頼部４１０から送信された接続仲介依頼は、ネットワークＮを介して接続仲介装置３００へと伝達される（図における太線矢印は、端末装置４００と接続仲介装置３００との間でやりとりされる、通信セッション確立前の信号の流れを示している）。すると、接続仲介装置３００からは、図に太線矢印で示すように、通信元アドレスが送信されてくる。この通信元アドレスは、通信開始要求部４４０によって受信される。
ここで留意すべき点は、接続仲介装置３００からの通信元アドレスの送信先は、接続仲介依頼を行った通信元の端末装置ではなく、通信先となる別な端末装置である点である。すなわち、図７に示す例において、矩形ブロックで示す接続仲介依頼部４１０は、通信元端末装置内の構成要素であるのに対して、二重矩形ブロックで示す通信開始要求部４４０は、別な通信先端末装置内の構成要素ということになる。したがって、上述の説明において、接続仲介依頼を発する接続仲介依頼部４１０と、これに応じて接続仲介装置３００から送信されてくる通信元アドレスを受信する通信開始要求部４４０とは、それぞれ異なる端末装置４００に所属していることになる。
要するに、図６に示されている通信元アドレス送信部３３０は、ある端末装置４００の接続仲介依頼部から接続仲介依頼が送信されてきたときに、アドレステーブルＴを参照して、当該接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスに対して、当該接続仲介依頼を送信した通信元の端末装置の端末ＩＤに対応づけられている所在アドレスを通信元アドレスとして送信する処理を行うことになる。
この通信元アドレス送信部３３０の処理機能をより明確にするため、ここでは、図６に示す端末装置４００Ｂを通信元、端末装置４００Ａを通信先とした具体例（たとえば、端末装置４００ＢのユーザＢが発呼側となり、端末装置４００ＡのユーザＡを着呼側として電話をかけたような場合）について、上記手順を説明しよう。
この場合、通信元端末装置４００Ｂから接続仲介装置３００に対して、端末装置４００Ａを通信先として指定する接続仲介依頼が送信されることになる。当該接続仲介依頼を受けた通信元アドレス送信部３３０は、アドレステーブルＴを参照することにより、通信先として指定された端末装置４００Ａの所在アドレス「ＡＤ１」を認識する。前述した第１の実施形態における通信先アドレス返信部１３０は、こうして認識した通信先の所在アドレスを通信元（接続仲介依頼の送信元）に返信する処理を行っていた。これに対して、図６に示す第２の実施形態における通信元アドレス送信部３３０は、認識した通信先の所在アドレス「ＡＤ１」に宛てて、通信元端末装置４００Ｂの所在を示す通信元アドレス「ＡＤ２」（これは、接続仲介依頼の送信元のアドレスとして認識できる）を送信する。
結局、上例の場合、通信元端末装置４００Ｂから接続仲介装置３００に対して接続仲介依頼を行うと、接続仲介装置３００から通信先端末装置４００Ａに対して通信元アドレス（通信元端末装置４００Ｂの所在アドレス「ＡＤ２」）が送信されることになる。ここが、前述した第１の実施形態と大きく異なる点である。
こうして送信されてきた通信元アドレスは、図７に示すとおり、通信先端末装置４００Ａ内の通信開始要求部４４０によって受信される。通信開始要求部４４０は、この通信元アドレス（通信元端末装置４００Ｂのアドレス）に対して通信開始要求を行う。すなわち、通信開始要求部４４０は、接続仲介装置３００から、通信元の別な端末装置のネットワーク上での所在を示す通信元アドレスが送信されてきたときに、ネットワークＮを介して、当該通信元アドレスにアクセスして通信開始要求を行うことになる。図に細線矢印で示すとおり、この通信開始要求は、１台の端末装置４００（通信先）から別な１台の端末装置４００（通信元）に宛てた信号ということになる。
一方、通信先の別な端末装置（上例の場合、端末装置４００Ａ）から通信開始要求がなされた端末装置（上例の場合、端末装置４００Ｂ）は、当該通信開始要求を通信元セッション確立部４３０で受信する（図の左側の下向き細線矢印）。そして、この通信元セッション確立部４３０は、通信先の別な端末装置（上例の場合、端末装置４００Ａ）に対して通信開始受諾確認を返信し（図の左側の上向き細線矢印）、当該通信先の別な端末装置との間に通信セッションを確立して通信を開始する。図７の左端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
こうして、通信元端末装置４００Ｂから通信先端末装置４００Ａに対して返信された通信開始受諾確認は、通信先端末装置４００Ａの通信先セッション確立部４６０によって受信される（図の右側の細線矢印）。通信先セッション確立部４６０は、この通信開始受諾確認を受信したら、通信元の別な端末装置４００Ｂとの間に通信セッションを確立して通信を開始する。図７の右端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
かくして、通信元端末装置と通信先端末装置との間の通信セッション確立後の通信は、通信元端末装置の通信元セッション確立部４３０と通信先端末装置の通信先セッション確立部４６０との間で行われることになる。別言すれば、図７の左端の白抜矢印は、ネットワークＮを介して、図７の右端の白抜矢印に連なることになる。
＜２－２．第２の実施形態における具体的な通信手順＞
これまで、図６および図７を参照しながら、先願基本発明の第２の実施形態に係るネットワーク通信システムの構成要素である接続仲介装置３００および端末装置４００の各構成要素およびその機能を説明した。ここでは、この第２の実施形態に係るネットワーク通信システムにおける通信手順を、具体例に即して説明することにする。
これまで、図６および図７を参照しながら、先願基本発明の第２の実施形態に係るネットワーク通信システムの構成要素である接続仲介装置３００および端末装置４００の各構成要素およびその機能を説明した。ここでは、この第２の実施形態に係るネットワーク通信システムにおける通信手順を、具体例に即して説明することにする。
まず、図７に示す端末装置における自己アドレス通知部４５０の機能であるが、これは図３を用いて説明した自己アドレス通知部２５０Ａ，２５０Ｂの機能と全く同じであるため、ここでは説明を省略する。
そこで以下、特定の端末装置間で実際に通信を開始する際の処理手順を説明する。図８は、図６に示すネットワーク通信システムにおいて、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間の通信セッション確立の手順を示すブロック図である。この図８では、図の上段に接続仲介装置３００が示され、図の下段に２組の端末装置４００Ａ，４００Ｂが示されている。ここでも、接続仲介装置３００と各端末装置４００Ａ，４００Ｂとの間の情報のやりとり（太線矢印で示す）や、端末装置４００Ａ，４００Ｂ間の情報のやりとり（細線矢印で示す）は、実際にはネットワークＮを介して行われるが、説明の便宜上、ネットワークＮの図示は省略する。
また、ここでは、説明の便宜上、端末装置４００Ｂを通信元、端末装置４００Ａを通信先とした場合の手順を説明する。このため、図８では、通信元端末装置４００Ｂ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）のみを実線で示し、通信先端末装置４００Ａ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）のみを実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。
一方、図９は、図８のブロック図に示されている通信セッション確立手順を時系列で説明する流れ図である。以下、図８のブロック図を参照しながら、図９の流れ図に従って、第２の実施形態における具体的な通信手順を説明する。なお、図８のブロック図において、各矢印に付された符号Ｓ１１～Ｓ１７は、図９の流れ図における各ステップＳ１１～Ｓ１７に対応するものである。逆に、図９の流れ図の各ステップにおいて、括弧書きで示された符号は、図８のブロック図における特定のブロックに対応するものであり、当該ステップの内容に関連する特定の構成要素を示すものである。
まず、ステップＳ１１において、通信要求受付処理が行われる。これは、図８に示す通信要求受付部４２０Ｂによって通信要求を受け付ける処理であり、図５のステップＳ１で述べた処理と同様であるため説明は省略する。続くステップＳ１２では、この通信要求に基づいて、接続仲介依頼Ｓ１２が行われる。これは、図８に示す接続仲介依頼部４１０Ｂによって行われる処理であり、図５のステップＳ２で述べた処理と同様であるため説明は省略する。
こうして、通信元端末装置４００Ｂの接続仲介依頼部４１０Ｂから、接続仲介装置３００へ接続仲介依頼Ｓ１２（図示の例では、通信先特定情報として、通信先端末装置４００Ａの端末ＩＤ「００１０」が含まれている）が送信されてくると、ステップＳ１３において、この接続仲介依頼Ｓ１２を受けた通信元アドレス送信部３３０が、アドレステーブル格納部３１０に格納されているアドレステーブルを参照して、当該接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤ（この例では、「００１０」）に対応づけられている所在アドレスを通信先アドレスとして認識する（Ｓ１３）。たとえば、その時点におけるアドレステーブルＴが、図６に示すようなものであったとすると、端末ＩＤ「００１０」に対応づけられているアドレス「ＡＤ１」が通信先アドレスとして認識される。
そこで、ステップＳ１４において、通信元アドレス返信部３３０が、ステップＳ１３で認識した通信先アドレス「ＡＤ１」宛に、接続仲介依頼Ｓ１２を送信した通信元端末装置４００Ｂの端末ＩＤ「００２０」に対応づけられている所在アドレス「ＡＤ２」を通信元アドレスとして送信する（Ｓ１４）。
前述したとおり、一般に、ネットワークを介して接続された二者間で情報の送受を行う場合、情報の送信側は自分のアドレスを受信側に伝達し、受信側は当該送信側のアドレス宛にアクノレッジ信号を返信する処理を行う。したがって、通信元アドレス送信部３３０は、接続仲介依頼Ｓ１２を受信した時点で、その送信元である端末装置４００Ｂの所在アドレス「ＡＤ２」を認識することができるので、通信元アドレス送信Ｓ１４を行う際には、この認識した所在アドレス「ＡＤ２」をデータとして送信すればよい。
このように、通信元端末装置４００Ｂが、接続仲介装置３００に対して接続仲介依頼Ｓ１２を行うと、この接続仲介依頼Ｓ１２に応じて、接続仲介装置３００から、通信先端末装置４００Ａ宛に（アドレステーブルＴで検索した所在アドレス「ＡＤ１」宛に）、通信元端末装置４００Ｂの所在を示す通信元アドレス「ＡＤ２」が送信されることになる。接続仲介装置３００に用意されているアドレステーブルＴは、常に最新の状態に更新されているので、通信元アドレス送信Ｓ１４は、常に通信先端末装置４００Ａの最新の所在アドレスに対して行われることになる。
こうして、通信元アドレス送信部３３０から通信元アドレス送信Ｓ１４（通信元アドレス「ＡＤ２」を伝達する情報）が送信されてくると、当該通信元アドレス送信Ｓ１４は、通信先端末装置４００Ａの通信開始要求部４４０Ａによって受信される。
この通信元アドレス送信Ｓ１４により、通信元アドレス「ＡＤ２」を取得した通信開始要求部４４０Ａは、ステップＳ１５において、通信元端末装置４００Ｂに対して通信開始要求Ｓ１５を行う。すなわち、ネットワークＮを介して、通信元アドレス「ＡＤ２」宛にアクセスを行い、相手方に通信開始の要求を伝える。このとき、自己の所在アドレス（通信元アドレス「ＡＤ１」）も併せて伝達されることになる。
通信元アドレス「ＡＤ２」宛に行われた通信開始要求Ｓ１５は、通信元端末装置４００Ｂの通信元セッション確立部４３０Ｂによって受信される。通信元セッション確立部４３０Ｂは、通信先端末装置４００Ａから、自己（端末装置４００Ｂ）を通信元とする通信開始要求Ｓ１５がなされたら、まず、ステップＳ１６において、ネットワークＮを介して通信先端末装置４００Ａに対して通信開始受諾確認Ｓ１６を送信する。そして、続くステップＳ１７において、通信先端末装置４００Ａとの間に通信セッションを確立して通信Ｓ１７を開始する。
一方、通信先端末装置４００Ａ宛に送信されてきた通信開始受諾確認Ｓ１６は、通信先セッション確立部４６０Ａによって受信される。そして、ステップＳ１７では、この通信開始受諾確認Ｓ１６を受信した通信先セッション確立部４６０Ａが、通信元端末装置４００Ｂとの間に通信セッションを確立して通信Ｓ１７を開始する処理も行われる。要するに、通信先端末装置４００Ａ側では、通信開始要求Ｓ１５に応じて、通信元端末装置４００Ｂから通信開始受諾確認Ｓ１６が返信されてきたら、当該通信元端末装置４００Ｂとの間に通信セッションを確立して通信を開始する処理を行うことになる。
かくして、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間に通信セッションが確立され、両者間での通信Ｓ１７が行われることになる。この図９に示す流れ図において、接続仲介装置３００が行った処理は、ステップＳ１３のアドレステーブル参照処理とステップＳ１４の通信元アドレス送信処理だけである。すなわち、接続仲介装置３００が行う仲介処理は、通信元端末装置４００Ｂからの接続仲介依頼Ｓ１２を受けて、アドレステーブルＴを参照し（ステップＳ１３）、得られた通信先アドレスに宛てて、通信元アドレスのデータを送信する（ステップＳ１４）だけである。接続仲介装置３００がこのような仲介処理を行うだけで、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間に通信セッションが確立され、両者間での通信が開始することになる。
このように、先願基本発明の第２の実施形態に係るネットワーク通信システムでは、第１の実施形態に係るネットワーク通信システムと同様に、接続仲介装置３００の処理負荷は極めて軽くなる。前述したように、ＳＩＰを利用して両端末間の接続仲介処理を行うシステムでは、従来型の中継処理に比べれば、その処理負荷は軽減されることになるが、両端末間にセッションが確立するまで関与する必要があり、多数の端末装置からの仲介依頼が集中すると、その処理負荷はかなり重くなってくる。これに対して、先願基本発明の第２の実施形態に係るシステムの場合、接続仲介装置３００は、両端末間に通信セッションが確立するまで関与する必要はなく、通信先端末装置に対して通信元アドレスを伝達する処理を行えば足りる。このため、一対の端末装置間の接続を仲介する際の処理負荷を、より軽減することが可能になる。
このように、先願基本発明の第２の実施形態に係るネットワーク通信システムでは、接続仲介装置３００が通信セッション確立まで関与しないため、接続仲介装置３００は、両端末装置間に通信セッションが確立し、支障なく通信が行われているか否かを把握することはできない。そこで、もし必要があれば、通信セッション確立後に、通信元セッション確立部４３０Ｂもしくは通信先セッション確立部４６０Ａから接続仲介装置３００に対して、支障なく通信セッションが確立した旨の報告を行うようにしてもよい。
なお、上述の実施例では、通信先端末装置４００Ａの通信開始要求部４４０Ａが、接続仲介装置３００からの通信元アドレス送信Ｓ１４を受信したときに、ステップＳ１５において、自動的に通信開始要求Ｓ１５を送信しているが、場合によっては、通信開始要求部４４０Ａに何らかの条件判断機能をもたせておき、通信元アドレス送信Ｓ１４を受信したときに、所定の条件を満たしている場合に限り、通信開始要求Ｓ１５を送信するようにしてもよい。あるいは、所定の条件を満たしていない場合には、通信開始要求Ｓ１５の代わりに、通信開始拒絶通知を送信するようにしてもよい。
たとえば、通信開始要求部４４０Ａに、通信開始を常に拒絶する通信元リスト（いわゆるブラックリスト）や通信開始を常に許可する通信元リスト（いわゆるホワイトリスト）を用意しておけば、通信開始要求部４４０Ａは、当該リストを参照することにより、通信元アドレス送信Ｓ１４によって送信されてきた通信元アドレスが、ブラックリストに掲載されていた場合には、通信開始要求Ｓ１５の送信を行わない処理をするか、通信開始拒絶通知を送信する運用を行うことができる。あるいは、通信元アドレスが、ホワイトリストに掲載されていた場合にのみ、通信開始要求Ｓ１５を送信するような運用を行うことも可能である。
また、上述の実施例では、通信元セッション確立部４３０Ｂが、通信先端末装置４００Ａから、自己を通信元とする通信開始要求Ｓ１５がなされた時に、ステップＳ１６において、当該通信先端末装置４００Ａに対して通信開始受諾確認を送信する、という説明を行ったが、場合によっては、通信開始要求Ｓ１５を受諾せずに拒絶し、通信開始受諾確認を送信しないようにしてもよい（あるいは、通信開始受諾確認の代わりに、通信開始拒絶通知を送信するようにしてもよい）。
たとえば、§３－４で述べるように、セキュリティを向上させる変形例を採用する場合は、通信開始要求Ｓ１５に何らかのセキュリティ上の問題が存在する場合には、これを拒絶する運用を採用することも可能である。
＜＜＜§３．先願基本発明の第１および第２の実施形態の変形例＞＞＞
ここでは、§１で述べた先願基本発明の第１の実施形態および§２で述べた先願基本発明の第２の実施形態について、いくつかの変形例を述べる。
ここでは、§１で述べた先願基本発明の第１の実施形態および§２で述べた先願基本発明の第２の実施形態について、いくつかの変形例を述べる。
＜３－１．端末ＩＤに関する変形例＞
これまで述べてきたように、図１の接続仲介装置１００内のアドレステーブル格納部１１０には、アドレステーブルＴが格納されている。図６の接続仲介装置３００内のアドレステーブル格納部３１０も同様である。このアドレステーブルＴは、個々の端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたテーブルであり、通信先アドレス返信部１３０もしくは通信元アドレス送信部３３０は、受信した接続仲介依頼に含まれている通信先特定情報に基づいてアドレステーブルＴを参照し、通信先の所在アドレスを取得する。
これまで述べてきたように、図１の接続仲介装置１００内のアドレステーブル格納部１１０には、アドレステーブルＴが格納されている。図６の接続仲介装置３００内のアドレステーブル格納部３１０も同様である。このアドレステーブルＴは、個々の端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたテーブルであり、通信先アドレス返信部１３０もしくは通信元アドレス送信部３３０は、受信した接続仲介依頼に含まれている通信先特定情報に基づいてアドレステーブルＴを参照し、通信先の所在アドレスを取得する。
たとえば、図４に示す第１の実施形態の場合、接続仲介依頼Ｓ２には、通信先端末装置２００Ｂの端末ＩＤ「００２０」が通信先特定情報として含まれており、通信先アドレス返信部１３０は、アドレステーブルＴを参照することにより、端末ＩＤ「００２０」に対応する所在アドレス「ＡＤ２」を取得することができる。同様に、図８に示す第２の実施形態の場合、接続仲介依頼Ｓ１２には、通信先端末装置４００Ａの端末ＩＤ「００１０」が通信先特定情報として含まれており、通信元アドレス送信部３３０は、アドレステーブルＴを参照することにより、端末ＩＤ「００１０」に対応する所在アドレス「ＡＤ１」を取得することができる。
このように、これまで述べてきた実施形態では、接続仲介依頼に含ませる通信先特定情報として、通信先端末装置の端末ＩＤを用いていた。この端末ＩＤは、個々の端末装置を相互に識別するための情報であり、具体的には、個々の端末装置に内蔵されているＣＰＵのシリアル番号、通信インターフェイスに付与されたＭＡＣアドレス、携帯電話として機能する端末装置の場合は電話番号やＳＩＭカードのシリアル番号、などを端末ＩＤとして用いることができる。
ただ、一般に、ユーザが、他のユーザの端末装置についての端末ＩＤを記憶することは困難である。したがって、通信要求を行う際に、これらの端末ＩＤを、ユーザ自身に直接入力させることは好ましくない。そこで、実用上は、通信要求を行う際に、端末ＩＤで通信先を指定する代わりに、ユーザＩＤで通信先を指定させるようにするのが好ましい。端末ＩＤが個々の端末装置を識別するためのＩＤであるのに対して、ユーザＩＤは個々のユーザを識別するためのＩＤである。一般的には、ユーザ名やニックネームをユーザＩＤとして用いることができる。
端末ＩＤの代わりにユーザＩＤを用いて通信要求を行うことができるようにするには、通信要求受付部２２０，４２０内に、ユーザＩＤと端末ＩＤとの対応表を用意しておけばよい。そして、ユーザが特定のユーザＩＤ（たとえば、ユーザ名）を指定して通信要求を行ったときに、通信要求受付部２２０，４２０が、用意されている対応表を利用してユーザＩＤを端末ＩＤに変換して接続仲介依頼部２１０，４１０へ引き渡すようにすればよい。そうすれば、接続仲介依頼部２１０，４１０は、端末ＩＤを含む接続仲介依頼を送信することができる。このようなユーザＩＤ（たとえば、ユーザ名）から端末ＩＤ（たとえば、電話番号）への変換処理機能は、一般的な携帯電話に「電話番号登録機能」として備わっている公知の機能であるため、ここでは詳しい説明は省略する。
端末ＩＤの代わりにユーザＩＤを利用できるようにする別な方法として、ユーザＩＤと端末ＩＤとの対応表を接続仲介装置１００，３００側に用意する方法を採ることもできる。たとえば、アドレステーブル格納部１１０，３１０内に、図１や図６に示すアドレステーブルＴの代わりに、図１０に示すようなアドレステーブルＴ１を格納しておくようにする。このアドレステーブルＴ１は、個々の端末装置のそれぞれについて、当該端末装置のユーザを特定するユーザＩＤと、当該端末装置の端末ＩＤと、を対応づける情報を含むテーブルである。
図１０では、説明の便宜上、ユーザＩＤとして、「John」，「Mary」のようなユーザ名を用いた例を示すが、実際には、テーブルに収録されている個々のユーザを相互に識別できるように、各ユーザのフルネームをユーザＩＤとして登録しておくようにし、もし同姓同名のユーザがいた場合には、相互に区別できるようなユーザＩＤを登録するようにする。実際には、端末装置２００，４００の自己アドレス通知部２５０，４５０に、このようなユーザＩＤを接続仲介装置１００，３００側に申告する機能を設けておき、アドレステーブル更新部１２０，３２０に、申告を受けたユーザＩＤをアドレステーブルＴ１に登録する機能を設けておけば、図１０に示すようなアドレステーブルＴ１を用意することが可能になる。
アドレステーブルＴ１を用意しておけば、通信元となる端末装置側では、通信先となる端末装置の端末ＩＤを認識する必要はない。たとえば、図４に示す例において、通信元端末装置２００Ａから通信先端末装置２００Ｂに対して発呼する場合、通信元端末装置２００ＡのユーザＡ（John）は、通信先端末装置２００ＢのユーザＢのユーザ名「Mary」（ユーザＩＤ）を通信先として指定した通信要求を行えばよい。この場合、端末ＩＤ「００２０」の代わりに、「Mary」なるユーザＩＤを通信先特定情報として含む接続仲介依頼Ｓ２が、接続仲介依頼部２１０Ａから接続仲介装置１００へ送信されることになる。
このような接続仲介依頼Ｓ２を受信した通信先アドレス返信部１３０は、図１０に示すアドレステーブルＴ１を参照することにより、通信先特定情報として含まれていたユーザ名「Mary」に対応する端末ＩＤ「００２０」を認識することができ、更に、この端末ＩＤ「００２０」をもつ通信先端末装置２００Ｂの所在アドレス「ＡＤ２」を認識することができる。
図１１は、ユーザＩＤの代わりにアカウントＩＤを用いたアドレステーブルＴ２を示す図である。ユーザＩＤが、個々のユーザを特定する情報であるのに対して、アカウントＩＤは、個々のユーザが開設したユーザアカウントを特定する情報である。たとえば、図示の例における「U11111」なるアカウントＩＤは、ユーザ「John」が開設したユーザアカウントを示すＩＤであり、「U22222」なるアカウントＩＤは、ユーザ「Mary」が開設したユーザアカウントを示すＩＤである。もちろん、個々のユーザは、必要があれば複数のアカウントを開設することが可能である。
端末装置２００，４００の自己アドレス通知部２５０，４５０に、このようなアカウントを開設するための申込機能を設けておき、アドレステーブル更新部１２０，３２０に、当該申込に応じて、所定のユーザアカウントを設定し、アカウントＩＤをアドレステーブルＴ２に登録する機能を設けておけば、図１１に示すようなアドレステーブルＴ２を用意することが可能になる。
図４に示す例において、アドレステーブル格納部１１０内に図１１に示すようなアドレステーブルＴ２を用意しておけば、接続仲介依頼部２１０Ａは、端末ＩＤ「００２０」の代わりに、「U22222」なるアカウントＩＤを通信先特定情報として含む接続仲介依頼Ｓ２を接続仲介装置１００へ送信すればよい。
このように、先願基本発明において、接続仲介依頼部から送信される接続仲介依頼には、通信先となる別な端末装置の端末ＩＤを特定する役割を果たす何らかの「通信先特定情報」が含まれていれば足りる。この「通信先特定情報」は、端末ＩＤ自身であってもよいし、上例のように、ユーザＩＤやアカウントＩＤであってもかまわない。
結局、この§３－１で述べた変形例を§１で述べた第１の実施形態に適用する場合は、図４に示す構成において、アドレステーブル格納部１１０に、個々の端末装置のそれぞれについて、当該端末装置のユーザを特定するユーザＩＤもしくはユーザアカウントを特定するアカウントＩＤと、当該端末装置の端末ＩＤと、を対応づける情報を含むアドレステーブルＴ１（図１０）もしくはＴ２（図１１）を格納しておくようにする。また、接続仲介依頼部２１０Ａは、通信先特定情報として、通信先の端末装置のユーザを特定するユーザＩＤもしくはユーザアカウントを特定するアカウントＩＤを用いた接続仲介依頼Ｓ２を送信するようにする。そして、通信先アドレス返信部１３０は、接続仲介依頼部２１０Ａから接続仲介依頼Ｓ２が送信されてきたときに、アドレステーブルＴ１もしくはＴ２を参照して、接続仲介依頼Ｓ２に含まれていたユーザＩＤもしくはアカウントＩＤに対応づけられている端末ＩＤを決定し、決定された端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する処理を行うようにすればよい。
一方、この§３－１で述べた変形例を§２で述べた第２の実施形態に適用する場合は、図８に示す構成において、アドレステーブル格納部３１０に、個々の端末装置のそれぞれについて、当該端末装置のユーザを特定するユーザＩＤもしくはユーザアカウントを特定するアカウントＩＤと、当該端末装置の端末ＩＤと、を対応づける情報を含むアドレステーブルＴ１（図１０）もしくはＴ２（図１１）を格納しておくようにする。また、接続仲介依頼部４１０Ｂは、通信先特定情報として、通信先の端末装置のユーザを特定するユーザＩＤもしくはユーザアカウントを特定するアカウントＩＤを用いた接続仲介依頼Ｓ１２を送信するようにする。そして、通信元アドレス送信部３３０は、接続仲介依頼部４１０Ｂから接続仲介依頼Ｓ１２が送信されてきたときに、アドレステーブルＴ１もしくはＴ２を参照して、接続仲介依頼Ｓ１２に含まれていたユーザＩＤもしくはアカウントＩＤに対応づけられている端末ＩＤを決定し、決定された端末ＩＤに対応づけられている所在アドレス宛に、通信元アドレスを送信する処理を行うようにすればよい。
＜３－２．代替端末を利用する変形例＞
前述したとおり、先願基本発明に利用可能な端末装置は、パソコン、携帯電話、タブレット型端末など多岐にわたり、最近は、同一のユーザが複数の端末装置を使い分けることも珍しくなくなってきている。ここでは、そのような状況を考慮して、特定の端末装置に対する着呼があったときに、当該着呼を同一ユーザの別な端末装置へ誘導する仕組をもった変形例を述べることにする。
前述したとおり、先願基本発明に利用可能な端末装置は、パソコン、携帯電話、タブレット型端末など多岐にわたり、最近は、同一のユーザが複数の端末装置を使い分けることも珍しくなくなってきている。ここでは、そのような状況を考慮して、特定の端末装置に対する着呼があったときに、当該着呼を同一ユーザの別な端末装置へ誘導する仕組をもった変形例を述べることにする。
ここで述べる変形例を実施する際には、予め、図１２に示すようなアドレステーブルＴ３を用意しておく。このアドレステーブルＴ３の場合、４組のユーザＩＤ「John」，「Mary」，「Frank」，「Susie」について、それぞれ端末ＩＤおよび所在アドレスが登録されているが、ユーザＩＤ「John」については２つの端末ＩＤ「００１０」，「００１１」が登録され、ユーザＩＤ「Frank」については３つの端末ＩＤ「００３０」，「００３１」，「００３２」が登録されている。これは、ユーザJohnが、このネットワーク通信システムに利用可能な２台の端末装置を所有し、ユーザFrankが、３台の端末装置を所有しているためである。
ここで、同一のユーザＩＤに対応づけられて登録されている複数の端末ＩＤを、１つのグループに所属する端末ＩＤとして把握し、同じグループに所属する１つの端末ＩＤを別な１つの端末ＩＤについての代替端末ＩＤと呼ぶことにすれば、図１２に示すアドレステーブルＴ３は、特定の端末ＩＤについて、１つもしくは複数の代替端末ＩＤを登録したアドレステーブルということができる。要するに、同一のユーザ名で複数の端末ＩＤの登録があった場合には、これらの端末ＩＤを同一のグループに所属するものとして把握し、相互に代替端末ＩＤとして認識する取り扱いを行うようにすればよい。
たとえば、図１２に示す例の場合、端末ＩＤ「００１０」については１つの代替端末ＩＤ「００１１」が登録されており、逆に、端末ＩＤ「００１１」については１つの代替端末ＩＤ「００１０」が登録されていることになる。一方、端末ＩＤ「００３０」については２つの代替端末ＩＤ「００３１」，「００３２」が登録されており、端末ＩＤ「００３１」については２つの代替端末ＩＤ「００３０」，「００３２」が登録されており、端末ＩＤ「００３２」については２つの代替端末ＩＤ「００３０」，「００３１」が登録されていることになる。
ここで述べる変形例に係るシステムでは、このような代替端末ＩＤを登録しておくことにより、利用不都合な状態にある端末装置宛に発呼があったときに、当該発呼を代替となる別な端末装置宛に転送させることができる。
たとえば、ユーザJohnが、スマートフォンからなる第１の端末装置（端末ＩＤ「００１０」）とパソコンからなる第２の端末装置（端末ＩＤ「００１１」）とを所有しており、通常は、いずれの端末装置も利用可能な状態になっているものとしよう。ところが、ある日、スマートフォンからなる第１の端末装置について、バッテリ切れで一時的に利用できない状態になったとする。この場合、もし、ユーザMaryが、自己の端末装置を通信元として、ユーザJohnのスマートフォンを通信先とする通信要求を行ったとしても、ユーザJohnのスマートフォンに対する正常な接続を行うことはできない。
ここで述べる変形例に係るシステムでは、このような場合、接続仲介装置が、ユーザJohnのスマートフォンの代わりに、その代替となるユーザJohnのパソコンに代替接続する処理を実行することができる。
この§３－２で述べる変形例を§１で述べた先願基本発明の第１の実施形態に適用する場合は、図４に示す構成に対して、次のような変更を施せばよい。
まず、アドレステーブル格納部１１０には、特定の端末ＩＤについて、１つもしくは複数の代替端末ＩＤを登録したアドレステーブル（たとえば、図１２に示すアドレステーブルＴ３）を格納しておく。そして、通信先アドレス返信部１３０には、個々の端末装置について利用不都合な状態にあるか否かを判定する機能を付加しておく。具体的には、たとえば、判定対象となる端末装置に対して試験アクセスを行い、正常な返信があった場合には問題なしと判断するが、正常な返信が得られなかった場合には利用不都合な状態にあるとの判断を行うようにすればよい。
通信先アドレス返信部１３０は、接続仲介依頼Ｓ２が送信されてきたときに、通信先特定情報で特定される本来の端末ＩＤが付与された端末装置について、利用不都合な状態にあるか否かを判定する処理を行う。そして、もし、本来の端末ＩＤが付与された端末装置が利用不都合な状態にある場合には、当該本来の端末ＩＤに代えて代替端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する処理を行うようにする。
たとえば、図１２に示すアドレステーブルＴ３が用意されている状態において、通信先特定情報として本来の端末ＩＤ「００１０」（ユーザJohnのスマートフォン）を含む接続仲介依頼が送信されてきた場合、通信先アドレス返信部１３０は、まず、端末ＩＤ「００１０」に対応する所在アドレス「ＡＤ１」に試験アクセスを行い、正常な返信があった場合には問題なしと判断し、通常の手順に従って、所在アドレス「ＡＤ１」を通信先アドレスとして返信する処理を行えばよい。この場合、通信元端末装置は、本来の端末ＩＤ「００１０」が付与されたユーザJohnのスマートフォンを通信先として通信を行うことができる。
ところが、試験アクセスに対して正常な返信が得られなかった場合には、本来の端末ＩＤ「００１０」が付与された端末装置（ユーザJohnのスマートフォン）が利用不都合な状態にあると判断し、本来の端末ＩＤ「００１０」に代えて、アドレステーブルＴ３において端末ＩＤ「００１０」についての代替端末ＩＤとして登録されている端末ＩＤ「００１１」に対応づけられている所在アドレス「ＡＤ５」を通信先アドレスとして返信する処理を行うようにする。この場合、通信元端末装置は、本来の端末ＩＤ「００１０」が付与されたユーザJohnのスマートフォンではなく、代替端末ＩＤ「００１１」が付与されたユーザJohnのパソコンを通信先として通信を行うことができる。
一方、この§３－２で述べる変形例を§２で述べた先願基本発明の第２の実施形態に適用する場合は、図８に示す構成に対して、次のような変更を施せばよい。
まず、アドレステーブル格納部３１０には、特定の端末ＩＤについて、１つもしくは複数の代替端末ＩＤを登録したアドレステーブル（たとえば、図１２に示すアドレステーブルＴ３）を格納しておく。そして、通信元アドレス送信部３３０には、個々の端末装置について利用不都合な状態にあるか否かを判定する機能を付加しておく。具体的には、上述したように、判定対象となる端末装置に対して試験アクセスを行い、正常な返信があった場合には問題なしと判断するが、正常な返信が得られなかった場合には利用不都合な状態にあるとの判断を行うようにすればよい。
通信元アドレス送信部３３０は、接続仲介依頼Ｓ１２が送信されてきたときに、通信先特定情報で特定される本来の端末ＩＤが付与された端末装置について、利用不都合な状態にあるか否かを判定する処理を行う。そして、もし、本来の端末ＩＤが付与された端末装置が利用不都合な状態にある場合には、当該本来の端末ＩＤに代えて代替端末ＩＤに対応づけられている所在アドレスに対して、接続仲介依頼Ｓ１２を送信した通信元端末装置の所在アドレスを通信元アドレスとして送信する処理を行うようにする。
たとえば、図１２に示すアドレステーブルＴ３が用意されている状態において、通信先特定情報として本来の端末ＩＤ「００１０」（ユーザJohnのスマートフォン）を含む接続仲介依頼が送信されてきた場合、通信元アドレス送信部３３０は、まず、端末ＩＤ「００１０」に対応する所在アドレス「ＡＤ１」に試験アクセスを行い、正常な返信があった場合には問題なしと判断し、通常の手順に従って、所在アドレス「ＡＤ１」宛に通信元アドレスの送信を行えばよい。この場合、通信元端末装置は、本来の端末ＩＤ「００１０」が付与されたユーザJohnのスマートフォンを通信先として通信を行うことができる。
ところが、試験アクセスに対して正常な返信が得られなかった場合には、本来の端末ＩＤ「００１０」が付与された端末装置（ユーザJohnのスマートフォン）が利用不都合な状態にあると判断し、本来の端末ＩＤ「００１０」に代えて、アドレステーブルＴ３において端末ＩＤ「００１０」についての代替端末ＩＤとして登録されている端末ＩＤ「００１１」に対応づけられている所在アドレス「ＡＤ５」宛に通信元アドレスの送信を行うようにする。この場合、通信元端末装置は、本来の端末ＩＤ「００１０」が付与されたユーザJohnのスマートフォンではなく、代替端末ＩＤ「００１１」が付与されたユーザJohnのパソコンを通信先として通信を行うことができる。なお、図１２に示すユーザFrankのように、複数の代替端末ＩＤが登録されている場合は、予め優先順位を定めておき、優先順位の高い順に実際に利用する代替端末ＩＤを決定すればよい。
なお、上述の実施例では、通信先アドレス返信部１３０や通信元アドレス送信部３３０は、接続仲介依頼を受信した時点で、本来の通信先に対する試験アクセスを行い、利用不都合な状態にあるか否かを判定する処理を行っているが、その代わりに、個々の端末装置に対して定期的な試験アクセスを行うようにし、利用不都合な状態にある端末装置については、その時点でアドレステーブルにその旨の記録を行うようにしてもよい。この場合、各端末装置は、接続仲介依頼の有無にかかわらず、定期的に試験アクセスを受け、利用不都合な状態にあるか否かのチェックを受けることになり、チェック結果がアドレステーブルに記録されることになる。したがって、実際に接続仲介依頼があった場合は、このアドレステーブルの記録に基づいて利用不都合な状態にあるか否かを判定することができる。
なお、この変形例にいう「利用不都合な状態」とは、バッテリ切れの状態やネットワークへの接続障害が生じた状態のように「利用不能な状態」のみを意味するものではない。たとえば、端末装置の機能としては正常に利用可能な状態ではあるが、ユーザが恣意的に利用したくないと考え、そのような設定を行った状態も含むものである。たとえば、ユーザが自分の意思で「着信拒否」を設定した場合、当該端末装置は「利用不都合な状態」になる。したがって、上例の場合、ユーザJohnが所持するスマートフォンおよびパソコンがいずれも正常動作可能な状態であっても、もしユーザJohnが、スマートフォンに対して「着信拒否」を設定した場合、当該スマートフォンは「利用不都合な状態」になる。
この「着信拒否」の設定（「利用不都合な状態」の設定）は、個々の端末装置内にのみ記録しておいてもよいが、接続仲介装置内のアドレステーブルに記録するようにしてもよい。アドレステーブルに記録しておけば、各端末装置への試験アクセスを行うことなしに、「利用不都合な状態」にあることを認識できる。
＜３－３．セキュリティを向上させる変形例（その１）＞
ここでは、よりセキュリティを向上させたネットワーク通信システムを構築するための変形例を述べる。一般に、電子機器間でネットワークを介して情報のやりとりを行う場合、相手方の真正性を担保することは重要である。真正性が担保されない相手との交信は、クラッカーの攻撃を招くおそれがあり、セキュリティ上問題である。先願基本発明に係るネットワーク通信システムの場合、個々の端末装置と接続仲介装置との間の交信や、通信元端末装置と通信先端末装置との間の交信が不可欠であり、実用上、これら装置間通信におけるセキュリティ確保は重要である。
ここでは、よりセキュリティを向上させたネットワーク通信システムを構築するための変形例を述べる。一般に、電子機器間でネットワークを介して情報のやりとりを行う場合、相手方の真正性を担保することは重要である。真正性が担保されない相手との交信は、クラッカーの攻撃を招くおそれがあり、セキュリティ上問題である。先願基本発明に係るネットワーク通信システムの場合、個々の端末装置と接続仲介装置との間の交信や、通信元端末装置と通信先端末装置との間の交信が不可欠であり、実用上、これら装置間通信におけるセキュリティ確保は重要である。
図１３は、図４に示す第１の実施形態に係るネットワーク通信システムについて、セキュリティを向上させた変形例を示すブロック図である。この変形例では、第１の実施形態に係るネットワーク通信システムに対して、セキュリティを向上させるための２つの対策が施されている。
第１の対策は、相互認証処理の付加であり、図に破線の矢印で示されている情報を送受する際に、両者間で相手方の真正性を確認するための相互認証処理が行われる。具体的には、まず、通信元端末装置２００Ａから接続仲介装置１００に対して接続仲介依頼Ｓ２を送信するときに、通信元端末装置２００Ａと接続仲介装置１００との間で、相互に相手方の装置の真正性を確認するための相互認証処理が行われる。接続仲介依頼Ｓ２を示す矢印が破線になっているのは、この相互認証処理が行われることを示している。したがって、各端末装置２００および接続仲介装置１００には、このような認証処理機能が備わっていることになる。
なお、図示の例の場合、接続仲介装置１００から通信元端末装置２００Ａに対して通信先アドレス返信Ｓ４を行う際の相互認証処理は省略されている（通信先アドレス返信Ｓ４を示す矢印は実線で描かれている）。これは、接続仲介依頼Ｓ２を送信するときに、通信元端末装置２００Ａと接続仲介装置１００との間の相互認証処理が既に完了しており、相手方の装置の真正性が確認済みとなっているためである。もちろん、通信先アドレス返信Ｓ４を行う際にも、再び相互認証処理を実行するようにしてもかまわない。
また、図１３に示すシステムの場合、通信元端末装置２００Ａから通信先端末装置２００Ｂに対して通信開始要求Ｓ５を送信するときにも、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間で、相互に相手方の装置の真正性を確認するための相互認証処理が行われる。通信開始要求Ｓ５を示す矢印が破線になっているのは、この相互認証処理が行われることを示している。したがって、各端末装置２００には、このような認証処理機能が備わっていることになる。
なお、図示の例の場合、通信先端末装置２００Ｂから通信元端末装置２００Ａに対して通信開始受諾確認Ｓ６を行う際の相互認証処理は省略されている（通信開始受諾確認Ｓ６を示す矢印は実線で描かれている）。これは、通信開始要求Ｓ５を送信するときに、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の相互認証処理が既に完了しており、相手方の装置の真正性が確認済みとなっているためである。もちろん、通信開始受諾確認Ｓ６を行う際にも、再び相互認証処理を実行するようにしてもかまわない。
ネットワークを介して接続された一対の装置間において、相手方の真正性を確認するための相互認証処理としては、既に種々の方法が知られているため、ここでは詳しい説明は省略する。一般的には、相手方の暗号鍵を利用した相互認証処理が利用されることが多い。たとえば、公開鍵暗号方式を利用した相互認証処理では、一方の装置で特定の平文データを相手方装置の公開鍵を用いて暗号化し、得られた暗号文データを相手方に送信し、これを受信した他方の装置では、当該暗号文データを自己の暗号鍵を用いて復号し、元の平文データが復元できることを確認する、といった処理手順を採ることができる。この処理手順を双方で行えば、相互に相手方の真正性を確認することができる。
なお、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の相互認証処理を、それぞれの暗号鍵を用いて行った場合は、当該暗号鍵を利用して、通信セッション確立後の両者間の通信Ｓ７を暗号化通信によって行うようにすれば、セキュリティを更に向上させることができる。具体的には、通信開始要求Ｓ５を送信するときの相互認証処理を、通信元端末装置２００Ａについての暗号鍵および通信先端末装置２００Ｂについての暗号鍵を用いた処理によって行うようにし、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間における通信セッション確立後の通信Ｓ７が、上記相互認証処理で用いた暗号鍵を用いて暗号化されたパケットを送受するパケット通信によって行われるようにすればよい。
図１３に示すシステムにおいて、セキュリティを向上させるために施された第２の対策は、接続仲介装置１００による仲介証明書の発行である。図示の例の場合、接続仲介装置１００は、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の接続を仲介する役割を果たす。仲介証明書は「そのような仲介を確かに行った」という事実を証明するために接続仲介装置１００が発行する証明書である。通信先端末装置２００Ｂは、この仲介証明書により、接続仲介装置１００による仲介が正しく行われていることを確認することができる。以下、その仕組を順に説明する。
まず、接続仲介依頼部２１０Ａから通信先アドレス返信部１３０に対して、接続仲介依頼Ｓ２があると、通信先アドレス返信部１３０は、この接続仲介依頼Ｓ２の送信を受けて、通信元となる特定の端末装置２００Ａから通信先となる特定の端末装置２００Ｂへの仲
介処理を実行したことを示す仲介証明書を発行する。そして、通信先アドレス返信Ｓ４を行う際に、通信先アドレス「ＡＤ２」とともにこの仲介証明書を、通信元端末装置２００Ａに返信する。
介処理を実行したことを示す仲介証明書を発行する。そして、通信先アドレス返信Ｓ４を行う際に、通信先アドレス「ＡＤ２」とともにこの仲介証明書を、通信元端末装置２００Ａに返信する。
したがって、通信開始要求部２４０Ａは、通信先アドレス「ＡＤ２」とともに、この仲介証明書を受信することになる。そこで、通信開始要求部２４０Ａは、当該通信先アドレス「ＡＤ２」に対して通信開始要求Ｓ５を行う際に、この仲介証明書を併せて送信する。そうすると、通信先セッション確立部２３０Ｂは、通信開始要求Ｓ５とともに仲介証明書を受信することになる。
通信先セッション確立部２３０Ｂは、通信元の別な端末装置２００Ａから、自己を通信先とする通信開始要求Ｓ５とともに仲介証明書が送信されてきたら、この仲介証明書の正当性が確認されることを条件として、当該通信元の別な端末装置２００Ａに対して通信開始受諾確認Ｓ６を送信し、当該通信元の別な端末装置２００Ａとの間に通信セッションを確立して通信Ｓ７を開始するようにする。もちろん、仲介証明書の正当性が確認されない場合は、通信開始受諾確認Ｓ６の送信を行わず、通信Ｓ７も開始しない。
前述したとおり、上例の場合の仲介証明書は、接続仲介装置１００が「端末装置２００Ａから端末装置２００Ｂへの仲介処理を実行した」ことを証明するものであるから、通信先セッション確立部２３０Ｂは、通信開始要求Ｓ５の内容が、当該仲介証明書の証明内容に合致しているか否かを判定することにより、当該仲介証明書の正当性確認を行うことができる。上例の場合、通信開始要求Ｓ５は端末装置２００Ａから送信されてきており、自分自身は端末装置２００Ｂであるから、「端末装置２００Ａから端末装置２００Ｂへの仲介処理を実行した」との仲介証明書は正しいと判断することができる。
通信先端末装置２００Ｂ内の通信先セッション確立部２３０Ｂは、通信元端末装置２００Ａからの通信開始要求Ｓ５を受信して、通信元端末装置２００Ａに対して通信開始受諾確認Ｓ６を送信し、通信セッションを確立して通信Ｓ７を行う。このとき、受信した通信開始要求Ｓ５が正規の信号であれば問題ないが、クラッカーによる偽装信号であった場合、不正行為の被害に遭うおそれがある。また、通信元端末装置２００Ａがマルウェアに感染していた場合、クラッカーに乗っ取られた状態になり、接続仲介装置１００を経由した正規の手順を踏まずに、不正な方法により通信開始要求Ｓ５がなされる可能性もある。上述した仲介証明書を発行する対策を講じておけば、このようなクラッカーによる不正行為を防止する上で効果的である。
仲介証明書のこのような役割を考慮すると、通信先アドレス返信部１３０は、たとえば次のような方法で仲介証明書を作成すればよい。まず、接続仲介依頼Ｓ２に基づいて、通信元となる特定の端末装置２００Ａの所在アドレス（図示の例では「ＡＤ１」）および通信先となる特定の端末装置２００Ｂの所在アドレス（図示の例では「ＡＤ２」）を認識する。そして、これら両所在アドレスを含む仲介証明用データを作成する。たとえば、両所在アドレスの文字列をそのまま連結して「ＡＤ１」＋「ＡＤ２」のような文字列を仲介証明用データとしてもよいし、更に、別な秘密文字列「ＨＡＰＰＹ」を付加して、「ＡＤ１」＋「ＡＤ２」＋「ＨＡＰＰＹ」のような文字列を仲介証明用データとしてもよい。
続いて、こうして作成した仲介証明用データに対して、所定の暗号鍵を利用した一方向性関数を作用させることにより得られたデータを仲介証明書とすればよい。たとえば、一方向性関数としては、通信元端末装置２００Ａについての暗号鍵もしくは通信先端末装置２００Ｂについての暗号鍵、または、これら双方の暗号鍵を利用したハッシュ関数を用いることができる。
たとえば、仲介証明用データが、「ＡＤ１」＋「ＡＤ２」＋「ＨＡＰＰＹ」という文字列によって構成され、当該文字列に、通信先端末装置２００Ｂの公開鍵を利用したハッシュ関数を作用させることにより仲介証明書を作成した場合を例にとってみよう。こうして作成された仲介証明書は、仲介証明用データのハッシュ値ということになる。
一方、通信開始要求Ｓ５とともに、上記仲介証明書を受信した通信先セッション確立部２３０Ｂは、次のような手順で、当該仲介証明書の正当性を確認することができる。まず、通信開始要求Ｓ５の送信元のアドレスとして、通信元端末装置２００Ａの所在アドレス「ＡＤ１」を認識することができる。また、自分自身の所在アドレス「ＡＤ２」も認識することができる。そして、予め取り決めがなされていた上記秘密文字列「ＨＡＰＰＹ」（この秘密文字列は、当該ネットワーク通信システムの各構成装置のみが知り得るように管理されている）を用いることにより、「ＡＤ１」＋「ＡＤ２」＋「ＨＡＰＰＹ」という文字列からなる仲介証明用データを作成する。
続いて、この仲介証明用データに対して自分自身の公開鍵を用いたハッシュ関数を作用させることにより仲介証明書を作成する。そして最後に、こうして作成した仲介証明書が通信開始要求Ｓ５とともに送信されてきた仲介証明書と一致することを確認すればよい。両者が一致すれば、仲介証明書の正当性が確認されたことになる。もちろん、不一致であれば、正当性は確認できないので、何らかの不正が行われている可能性があると判断できる。すなわち、仲介証明書の正当性が確認できない場合は、通信先セッション確立部２３０Ｂが受信した通信開始要求Ｓ５は、接続仲介装置１００による正規の仲介処理に基づいてなされたものではない、と判断することができる。そのような場合、通信先セッション確立部２３０Ｂは、通信開始受諾確認Ｓ６の送信を行わず、通信セッションの確立を拒絶することになる。
なお、上例では、「ＡＤ１」＋「ＡＤ２」＋「ＨＡＰＰＹ」なる仲介証明用データについてのハッシュ値を仲介証明書として用いているが、もちろん、上記仲介証明用データそのものを仲介証明書として用いることも可能である。ただ、十分なセキュリティを確保する上では、仲介証明用データそのものではなく、そのハッシュ値を仲介証明書として用いるのが好ましい。仲介証明用データには、「ＡＤ１」や「ＡＤ２」といった所在アドレスが含まれているので、クラッカーによる改竄を受けやすい。したがって、実用上は、上例のように、何らかの暗号鍵を利用した一方向性関数を作用させて仲介証明書を作成するのが好ましい。
ハッシュ関数などの一方向性関数を用いて仲介証明書を作成すれば、元の仲介証明用データを復元することはできないので、仲介証明書がクラッカーの手に渡ったとしても、不正な改竄を受ける可能性を低減することができる。不正な改竄を防止するという点では、上例の「ＨＡＰＰＹ」のような秘密文字列を付加して仲介証明用データを作成することは有効である。もちろん、仲介証明書を発行した日付、時間、曜日などの変動要素を秘密文字列として用いることも可能である。
＜３－４．セキュリティを向上させる変形例（その２）＞
上述した§３－３では、§１で述べた先願基本発明の第１の実施形態についてセキュリティを向上させた変形例を述べた。ここでは、§２で述べた先願基本発明の第２の実施形態について、同様の方法でセキュリティを向上させた変形例を述べることにする。
上述した§３－３では、§１で述べた先願基本発明の第１の実施形態についてセキュリティを向上させた変形例を述べた。ここでは、§２で述べた先願基本発明の第２の実施形態について、同様の方法でセキュリティを向上させた変形例を述べることにする。
図１４は、図８に示す第２の実施形態に係るネットワーク通信システムについて、セキュリティを向上させた変形例を示すブロック図である。この変形例では、第２の実施形態に係るネットワーク通信システムに対して、セキュリティを向上させるための２つの対策が施されている。
第１の対策は、相互認証処理の付加であり、図に破線の矢印で示されている情報を送受する際に、両者間で相手方の真正性を確認するための相互認証処理が行われる。具体的には、まず、通信元端末装置４００Ｂから接続仲介装置３００に対して接続仲介依頼Ｓ１２を送信するときに、通信元端末装置４００Ｂと接続仲介装置３００との間で、相互に相手方の装置の真正性を確認するための相互認証処理が行われる。接続仲介依頼Ｓ１２を示す矢印が破線になっているのは、この相互認証処理が行われることを示している。
同様に、接続仲介装置３００から通信先端末装置４００Ａに対して通信元アドレス送信Ｓ１４を行うときにも、接続仲介装置３００と通信先端末装置４００Ａとの間で、相互に相手方の装置の真正性を確認するための相互認証処理が行われる。接続仲介依頼Ｓ１４を示す矢印が破線になっているのは、この相互認証処理が行われることを示している。したがって、各端末装置４００および接続仲介装置３００には、上述した認証処理機能が備わっていることになる。
また、図１４に示すシステムの場合、通信先端末装置４００Ａから通信元端末装置４００Ｂに対して通信開始要求Ｓ１５を送信するときにも、通信先端末装置４００Ａと通信元端末装置４００Ｂとの間で、相互に相手方の装置の真正性を確認するための相互認証処理が行われる。通信開始要求Ｓ１５を示す矢印が破線になっているのは、この相互認証処理が行われることを示している。したがって、各端末装置４００には、このような認証処理機能が備わっていることになる。
なお、図示の例の場合、通信元端末装置４００Ｂから通信先端末装置４００Ａに対して通信開始受諾確認Ｓ１６を行う際の相互認証処理は省略されている（通信開始受諾確認Ｓ１６を示す矢印は実線で描かれている）。これは、通信開始要求Ｓ１５を送信するときに、通信先端末装置４００Ａと通信元端末装置４００Ｂとの間の相互認証処理が既に完了しており、相手方の装置の真正性が確認済みとなっているためである。もちろん、通信開始受諾確認Ｓ１６を行う際にも、再び相互認証処理を実行するようにしてもかまわない。
相互認証処理の具体的な方法は、既に§３－３で述べたとおりである。また、この図１４に示す変形例の場合も、相互認証処理に用いた暗号鍵を利用して、通信セッション確立後の両端末装置間の通信Ｓ１７を暗号化通信によって行うようにしてもよい。
図１４に示すシステムにおいて、セキュリティを向上させるために施された第２の対策は、接続仲介装置３００による仲介証明書の発行である。図示の例の場合、接続仲介装置３００は、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間の接続を仲介する役割を果たす。仲介証明書は「そのような仲介を確かに行った」という事実を証明するために接続仲介装置３００が発行する証明書である。通信元端末装置４００Ｂは、この仲介証明書により、接続仲介装置３００による仲介が正しく行われていることを確認することができる。以下、その仕組を順に説明する。
まず、接続仲介依頼部４１０Ｂから通信元アドレス送信部３３０に対して、接続仲介依頼Ｓ１２があると、通信元アドレス送信部３３０は、この接続仲介依頼Ｓ１２の送信を受けて、通信元となる特定の端末装置４００Ｂから通信先となる特定の端末装置４００Ａへの仲介処理を実行したことを示す仲介証明書を発行する。そして、通信元アドレス返信Ｓ１４を行う際に、通信元アドレス「ＡＤ２」とともにこの仲介証明書を、通信先端末装置４００Ａに返信する。
したがって、通信開始要求部４４０Ａは、通信元アドレス「ＡＤ２」とともに、この仲介証明書を受信することになる。そこで、通信開始要求部４４０Ａは、当該通信元アドレス「ＡＤ２」に対して通信開始要求Ｓ１５を行う際に、この仲介証明書を併せて送信する。そうすると、通信元セッション確立部４３０Ｂは、通信開始要求Ｓ１５とともに仲介証明書を受信することになる。
通信元セッション確立部４３０Ｂは、通信先の別な端末装置４００Ａから、自己を通信元とする通信開始要求Ｓ１５とともに仲介証明書が送信されてきたら、この仲介証明書の正当性が確認されることを条件として、当該通信先の別な端末装置４００Ａに対して通信開始受諾確認Ｓ１６を送信し、当該通信先の別な端末装置４００Ａとの間に通信セッションを確立して通信Ｓ１７を開始するようにする。もちろん、仲介証明書の正当性が確認されない場合は、通信開始受諾確認Ｓ１６の送信を行わず、通信Ｓ１７も開始しない。
前述したとおり、上例の場合の仲介証明書は、接続仲介装置３００が「端末装置４００Ｂから端末装置４００Ａへの仲介処理を実行した」ことを証明するものであるから、通信元セッション確立部４３０Ｂは、通信開始要求Ｓ１５の内容が、当該仲介証明書の証明内容に合致しているか否かを判定することにより、当該仲介証明書の正当性確認を行うことができる。上例の場合、通信開始要求Ｓ１５は端末装置４００Ａから送信されてきており、自分自信は端末装置４００Ｂであるから、「端末装置４００Ｂから端末装置４００Ａへの仲介処理を実行した」との仲介証明書は正しいと判断することができる。
通信元端末装置４００Ｂ内の通信元セッション確立部４３０Ｂは、通信先端末装置４００Ａからの通信開始要求Ｓ１５を受信して、通信先端末装置４００Ａに対して通信開始受諾確認Ｓ１６を送信し、通信セッションを確立して通信Ｓ１７を行う。このとき、受信した通信開始要求Ｓ１５が正規の信号であれば問題ないが、クラッカーによる偽装信号であった場合、不正行為の被害に遭うおそれがある。また、通信先端末装置４００Ａがマルウェアに感染していた場合、クラッカーに乗っ取られた状態になり、接続仲介装置３００を経由した正規の手順を踏まずに、不正な方法により通信開始要求Ｓ１５がなされる可能性もある。上述した仲介証明書を発行する対策を講じておけば、このようなクラッカーによる不正行為を防止する上で効果的である。
仲介証明書の具体的な作成方法は、§３－３で述べたとおりである。すなわち、この図１４に示す変形例の場合も、通信元アドレス送信部３３０は、通信元となる特定の端末装置４００Ｂの所在アドレス「ＡＤ２」および通信先となる特定の端末装置４００Ａの所在アドレス「ＡＤ１」を含む仲介証明用データ（必要に応じて、その他の秘密文字列を付加してもよい）に対して、所定の暗号鍵を利用した一方向性関数を作用させることにより仲介証明書を作成すればよい。一方向性関数としては、通信元についての暗号鍵もしくは通信先についての暗号鍵、または、これら双方の暗号鍵を利用したハッシュ関数を用いることができる。このような仲介証明書を用いた正当性確認の具体的な手順は、既に§３－３で述べたとおりであり、ここでは説明を省略する。
＜＜＜§４．ルータを用いた実用的な実施形態＞＞＞
これまで述べてきた先願基本発明の第１の実施形態や第２の実施形態では、各発明の基本原理を示す便宜上、各端末装置２００Ａ～２００Ｄ，４００Ａ～４００ＤがネットワークＮ（インターネット）に直接接続されている状態を示す図（図１，図６参照）を用いて説明を行ってきた。しかしながら、通常、各端末装置は、ルータを介してネットワークＮ（インターネット）に接続される。そこで、ここでは、先願基本発明について、端末装置をルータを介してネットワークに接続した実用的な実施形態を説明する。
これまで述べてきた先願基本発明の第１の実施形態や第２の実施形態では、各発明の基本原理を示す便宜上、各端末装置２００Ａ～２００Ｄ，４００Ａ～４００ＤがネットワークＮ（インターネット）に直接接続されている状態を示す図（図１，図６参照）を用いて説明を行ってきた。しかしながら、通常、各端末装置は、ルータを介してネットワークＮ（インターネット）に接続される。そこで、ここでは、先願基本発明について、端末装置をルータを介してネットワークに接続した実用的な実施形態を説明する。
＜４－１．ルータを用いた基本的な実施例＞
図１５は、端末装置をルータを介してネットワークＮに接続した先願基本発明の一実施形態を示すブロック図である。具体的には、この図１５には、３台の端末装置２００Ｅ，２００Ｆ，２００Ｇが、同一のルータＲを介してネットワークＮ（インターネット）に接続された状態が示されている。
図１５は、端末装置をルータを介してネットワークＮに接続した先願基本発明の一実施形態を示すブロック図である。具体的には、この図１５には、３台の端末装置２００Ｅ，２００Ｆ，２００Ｇが、同一のルータＲを介してネットワークＮ（インターネット）に接続された状態が示されている。
既に述べたとおり、先願基本発明における端末装置２００は、パソコン、携帯電話、タブレット型端末など、ネットワークＮに接続して通信を行う機能を有する電子機器であれば、どのような装置であってもかまわない。最近は、企業内ＬＡＮや家庭内ＬＡＮが普及し、パソコンやタブレット型端末は、通常、企業や家庭に設置されたルータ経由でインターネットへ接続される。また、最近の携帯電話通信網では、ルータの機能を有する基地局システムが利用されてきており、携帯電話は、このルータ機能を有する基地局システム経由でインターネットに接続することができる。
したがって、先願基本発明に利用される各端末装置は、実用上は、図１５に例示するように、ルータＲを介してインターネットに接続されることになる。ルータＲは、ＬＡＮを構築する機能を有し、図示の例の場合、ルータＲより左側に描かれた部分が１つのサブネットを構成しており、クラスＣのプライベートＩＰアドレスが付与されている。具体的には、各端末装置には、「192.168」なるネットワーク部と「0.11」，「0.12」，「0.13」なるホスト部とを有するＩＰアドレスが付与されている。このサブネット内の装置同士の交信は、ルータＲを介さずに行うことができるが、サブネット外の装置にアクセスする場合は、ルータＲを介した交信が必要になる。
図示の例の場合、端末装置２００Ｅ（端末ＩＤ：００５０）には、「192.168.0.11」なるプライベートＩＰアドレスが付与され、端末装置２００Ｆ（端末ＩＤ：００６０）には、「192.168.0.12」なるプライベートＩＰアドレスが付与され、端末装置２００Ｇ（端末ＩＤ：００７０）には、「192.168.0.13」なるプライベートＩＰアドレスが付与されている。また、実際の通信には、これらのＩＰアドレスとともにポート番号が利用される。図には、端末装置２００Ｅの１本の通信路にポート番号Ｐ１、端末装置２００Ｆの２本の通信路にポート番号Ｐ２，Ｐ３、端末装置２００Ｇの４本の通信路にポート番号Ｐ４～Ｐ７が付与された例が示されている。
ポート番号は、２バイトのデータからなり、通信のエンドポイントを特定するために利用される。たとえば、図に示す端末装置２００Ｆには、所定のＯＳプログラムの下で動作する２組のアプリケーションプログラムＡＰＰ１，ＡＰＰ２がインストールされており、ＡＰＰ１についての通信路にはポート番号Ｐ２が割り当てられ、ＡＰＰ２についての通信路にはポート番号Ｐ３が割り当てられている。したがって、同じＩＰアドレス「192.168.0.12」を用いた通信であっても、ポート番号Ｐ２／Ｐ３の違いにより、ＡＰＰ１についての通信か、ＡＰＰ２についての通信かを区別することができる。
一方、図に示す端末装置２００Ｇには、やはり２組のアプリケーションプログラムＡＰＰ１，ＡＰＰ２がインストールされているが、ＡＰＰ１については２組のポート番号Ｐ４，Ｐ５が割り当てられ、ＡＰＰ２については２組のポート番号Ｐ６，Ｐ７が割り当てられている。このように、同一のアプリケーションプログラムに複数のポート番号を割り当てて、複数の通信路を相互に区別することも可能である。たとえば、アプリケーションプログラムＡＰＰ１がＷｅｂブラウザプログラムであった場合、第１のＷｅｂページについての通信にはポート番号Ｐ４を割り当て、第２のＷｅｂページについての通信にはポート番号Ｐ５を割り当てる、という運用を行えば、それぞれ別のＷｅｂサーバに対して別個独立した通信が可能になる。このように、ポート番号は、個々のアプリケーションプログラムに対して任意に割り当てることができる。
ここでは、図示されているアプリケーションプログラムＡＰＰ２が、先願基本発明に係るネットワーク通信システムとしての機能を果たすための専用の通信アプリケーションプログラムであるものとして以下の説明を続ける。別言すれば、図示の端末装置２００Ｆ，２００Ｇは、所定のＯＳプログラムの管理下で動作する汎用のパソコン、スマートフォン、タブレット型端末などの装置であり、当該装置に専用の通信アプリケーションプログラムＡＰＰ２をインストールすることにより、これらの装置が先願基本発明に係る端末装置として機能することになる。
この場合、図２に示す端末装置２００の構成要素である自己アドレス通知部２５０、通信要求受付部２２０、接続仲介依頼部２１０、通信開始要求部２４０、通信元セッション確立部２６０、通信先セッション確立部２３０による処理機能は、この通信アプリケーションプログラムＡＰＰ２を実行することにより実現される（一部の処理機能は、ＯＳプログラムの実行により実現されるようにしてもよい）。同様に、図７に示す端末装置４００の構成要素である自己アドレス通知部４５０、通信要求受付部４２０、接続仲介依頼部４１０、通信開始要求部４４０、通信元セッション確立部４３０、通信先セッション確立部４６０による処理機能は、この通信アプリケーションプログラムＡＰＰ２を実行することにより実現される（一部の処理機能は、ＯＳプログラムの実行により実現されるようにしてもよい）。
図１５には、このアプリケーションプログラムＡＰＰ２を示すブロックおよびその通信路を太線で示してある。各端末装置２００Ｅ，２００Ｆ，２００Ｇとサブネット外の装置との間の通信は、ルータＲを介して行われる。ルータＲは、ネットワークアドレス変換機能（ＮＡＴ（Network Address Translation）機能）を有しており、内側（図におけるルータＲの左側）に接続された通信路について付与されたプライベートＩＰアドレスを、外側（図におけるルータＲの右側）に接続された通信路について付与されたグローバルＩＰアドレスに変換するとともに、その逆の変換も行う。
図示の例の場合、ルータＲの内側について付与された「192.168.0.11」～「192.168.0.13」なるプライベートＩＰアドレスと、ルータＲの外側について付与された「xx.73.5.111」なるグローバルＩＰアドレス（以下、ＡＤｘと記す）との間のアドレス変換が行われている。なお、上記グローバルＩＰアドレス内のxxは、任意の１バイトデータを示す（本願では、固有のグローバルＩＰアドレスの特定を避けるため、グローバルＩＰアドレスについては、その一部をxx，yy，zz等の記号で示すことにする）。また、上記アドレス変換の際には、一般にＮＡＰＴ（Network Address Port Translation）と呼ばれている機能により、ポート番号についての変換も行われる。
たとえば、端末装置２００Ｆの通信アプリケーションプログラムＡＰＰ２からの通信路に付与されたプライベートＩＰアドレスとポート番号との組み合わせ「192.168.0.12(P3)」は、グローバルＩＰアドレスＡＤｘとポート番号との組み合わせ「xx.73.5.111(P13)」に変換されている。したがって、ネットワーク（インターネット）Ｎを介して接続された外部装置に対して、端末装置２００ＦのＡＰＰ２は、「xx.73.5.111(P13)」なる所在アドレス（ＩＰアドレスにポート番号を付加した情報）で特定されることになる。同様に、端末装置２００ＧのＡＰＰ２は、「xx.73.5.111(P16)」もしくは「xx.73.5.111(P17)」なる所在アドレスで特定されることになる。
図示の例の場合、ルータＲの外側の複数の通信路には、いずれも同じグローバルＩＰアドレスＡＤｘ（具体的には、「xx.73.5.111」）が付与されているが、ポート番号がそれぞれ異なるため、相互に区別することができる。ルータＲの外側の装置から内側の装置に対するアクセスがあった場合には、逆に、グローバルＩＰアドレスＡＤｘをプライベートＩＰアドレスに変換する処理が行われる。たとえば、外部装置から「xx.73.5.111(P16)」なる所在アドレス宛のアクセスがあった場合、当該所在アドレスは、「192.168.0.13(P6)」に変換され、端末装置２００Ｇの通信アプリケーションプログラムＡＰＰ２の第１番目の通信路宛のアクセスとして処理される。このようなＮＡＰＴ機能は、広く利用されている既存の技術であるため、ここでは詳しい説明は省略する。
さて、先願基本発明に係るネットワーク通信システムの構成要素となる端末装置２００には、図２に示すとおり、自己アドレス通知部２５０が含まれており、この自己アドレス通知部２５０により、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１００に対して通知する処理が行われる。前述したとおり、この通知処理は、実際には端末装置２００にインストールされている通信アプリケーションプログラムＡＰＰ２によって実行される。
したがって、図１５に示す実施例の場合も、通信アプリケーションプログラムＡＰＰ２によって、接続仲介装置１００宛に所在アドレスの通知が行われ、これを受けて、接続仲介装置１００内のアドレステーブル更新部１２０が、各端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけた情報を、アドレステーブル格納部１１０内のアドレステーブルＴに書き込む処理を実行する。
図１５に示す実施例の場合、端末装置２００Ｆ，２００Ｇは、ルータＲを介してネットワークＮに接続されているため、自己アドレス通知部２５０は、ルータＲが管理するＬＡＮ（サブネット）内のプライベートＩＰアドレスを所在アドレスとして通知する処理を行う。ただ、このプライベートＩＰアドレスは、ルータＲによるＮＡＴ機能によりグローバルＩＰアドレスＡＤｘに変換されてネットワークＮに送信される。したがって、接続仲介装置１００に届くアドレスは、プライベートＩＰアドレスではなく、グローバルＩＰアドレスＡＤｘということになり、アドレステーブル更新部１２０は、このグローバルＩＰアドレスＡＤｘを、所在アドレスとしてアドレステーブルＴに格納する処理を行う。
また、図１５に示す実施例の場合、各端末装置のネットワーク上での所在を示す所在アドレスとして、ＩＰアドレスにポート番号を付加した情報が用いられている。このため、自己アドレス通知部２５０は、プライベートＩＰアドレスにポート番号を付加した情報を所在アドレスとして通知する処理を行い、当該情報がルータＲによって、グローバルＩＰアドレスにポート番号を付加した情報に変換され、接続仲介装置１００に届くことになる。したがって、アドレステーブルＴには、グローバルＩＰアドレスにポート番号を付加した情報が所在アドレスとして書き込まれることになる。
図１６は、図１５に示す実施形態において、ＩＰアドレスにポート番号を付加した情報を所在アドレスとして用いる場合のアドレステーブルの例を示す図である。図１６(a) に示すアドレステーブルＴ４１は、図１５に示す端末装置２００Ｆ（端末ＩＤ：００６０）内の自己アドレス通知部２５０（通信アプリケーションプログラムＡＰＰ２）からの通知に基づいて、「端末ＩＤ：００６０」に対応する所在アドレス（ＩＰアドレスＡＤｘとポート番号Ｐ１３との組み合わせ）の書き込みを行うとともに、端末装置２００Ｇ（端末ＩＤ：００７０）内の自己アドレス通知部２５０（通信アプリケーションプログラムＡＰＰ２）からの通知に基づいて、「端末ＩＤ：００７０」に対応する所在アドレス（ＩＰアドレスＡＤｘとポート番号Ｐ１６との組み合わせ、及びＩＰアドレスＡＤｘとポート番号Ｐ１７との組み合わせ）の書き込みを行った例である。
図１５に示す例の場合、各端末装置２００Ｆ，２００Ｇ内の自己アドレス通知部２５０（通信アプリケーションプログラムＡＰＰ２）は、プライベートＩＰアドレスにポート番号を付加した情報を所在アドレスとして送信する処理を行うが、ルータＲによって、グローバルＩＰアドレスにポート番号を付加した情報に変換されるため、実際にアドレステーブルＴ４１に格納される所在アドレスは、図示のとおり、グローバルＩＰアドレスＡＤｘと変換後のポート番号との組み合わせになる。
たとえば、端末装置２００Ｆの自己アドレス通知部２５０からは、送信元である自己の所在を示す所在アドレスとして「192.168.0.12」なるプライベートＩＰアドレスにポート番号「Ｐ３」を付加した情報が、端末ＩＤ「００６０」を示す情報とともに送信されてくるが、ルータＲを通過する際に、送信元である自己の所在を示す所在アドレスが、「xx.73.5.111」なるグローバルＩＰアドレスにポート番号「Ｐ１３」を付加した情報に変換されることになる。したがって、アドレステーブルＴ４１には、端末ＩＤ「００６０」に対応する所属アドレスとして、「xx.73.5.111」なるグローバルＩＰアドレスＡＤｘと「Ｐ１３」なるポート番号との組み合わせが書き込まれることになる。
図１６(b) に示すアドレステーブルＴ４２は、図１６(a) に示すアドレステーブルＴ４１の所在アドレス欄の情報を具体的なデータとして例示したものである。前述したとおり、図１５に示す例の場合、ルータＲの外側の通信路には、「xx.73.5.111」なるグローバルＩＰアドレスが付与されているため、図１６(b) に示すアドレステーブルＴ４２のＩＰアドレス欄には、いずれも「xx.73.5.111」なるデータが格納されている。一方、ルータＲの外側の通信路に付与されるポート番号は、ルータＲによって相互に重複しないように発生された２バイトの番号であり、図１６(b) に示す例では、６２８０１～６２８０３なるデータが格納されている。
結局、図１５に示す接続仲介装置１００には、端末装置２００Ｆ，２００Ｇについて、図１６(b) に示すようなアドレステーブルＴ４２が格納されることになる。そこで、図示されていない外部の通信元から、通信先特定情報として端末ＩＤ「００６０」を含む接続仲介依頼があると、接続仲介装置１００内の通信先アドレス返信部１３０は、アドレステーブルＴ４２を参照することにより、端末ＩＤ「００６０」に対応した所在アドレス（ＩＰアドレス「xx.73.5.111」にポート番号「６２８０１」を付加した情報）を通信先アドレスとして返信する。そこで、通信元となる端末装置は、ＩＰアドレス「xx.73.5.111」およびポート番号「６２８０１」で特定される通信先に対して、通信開始要求を行うことができる。
以上、主として図１に示す第１の実施形態（接続仲介装置１００と端末装置２００を用いる実施形態）においてルータＲを用いた例を述べたが、図７に示す第２の実施形態（接続仲介装置３００と端末装置４００を用いる実施形態）においてルータＲを用いた場合も同様である。
なお、接続仲介装置１００，３００内のアドレステーブル更新部１２０，３２０は、各端末装置の自己アドレス通知部２５０，４５０から所在アドレスの通知を受けるたびに、図１６に例示したアドレステーブルを更新する処理を行う。前述したとおり、図１５に示す実施例の場合、端末装置２００Ｆ，２００Ｇの自己アドレス通知部の処理機能は、所定のＯＳプログラムの管理下で動作する通信アプリケーションプログラムＡＰＰ２を実行することにより実現される。
そこで、実用上は、自己アドレス通知部２５０，４５０による自己アドレスの通知処理は、図１７の表に示すタイミングで行うのが好ましい。図示の表におけるタイミング(1) は、通信アプリケーションプログラムＡＰＰ２に対するユーザによる操作入力時である。たとえば、通信アプリケーションプログラムＡＰＰ２を起動した後、「通信準備を行いますか（Yes／No）？」のようなメッセージを表示し、ユーザが「Yes」を指示する操作入力を行った時点で、自己アドレスの通知処理を行うようにすればよい。通常、通信アプリケーションプログラムＡＰＰ２が起動された時点では、既に端末装置のプライベートＩＰアドレスや、これに対応するグローバルＩＰアドレスが定まっており、自己アドレスの通知処理を行う環境が整っている。
図示の表におけるタイミング(2) は、通信アプリケーションプログラムＡＰＰ２の起動時である。このタイミング(2) を採用した場合、上述したメッセージの表示やユーザによる操作入力を待たずして、自動的に自己アドレスの通知処理が実行されることになる。実際には、プログラムＡＰＰ２の起動ルーチンに自己アドレス通知部２５０，４５０としての処理機能を組み込んでおけばよい。
図示の表におけるタイミング(3) は、ＯＳプログラムの起動時であり、実質的には、端末装置の起動時ということになる。このタイミング(3) を採用する場合、ＯＳプログラムの起動ルーチンに自己アドレス通知部２５０，４５０としての処理機能を組み込んでおけばよい。通常、ＯＳプログラムの起動ルーチンにおいて、端末装置のプライベートＩＰアドレスや、これに対応するグローバルＩＰアドレスを決定する処理が行われるため、その後に、自己アドレス通知処理を自動的に行うようにしておけばよい。
＜４－２．ＶＰＮを利用した実施例＞
続いて、先願基本発明に係るネットワーク通信システムにおいて、ＶＰＮ（Virtual Private Network）を利用した実施例を述べる。図１５には、ルータＲを介して端末装置をネットワークＮに接続した実施例を例示した。この例の場合、ルータＲの内側（図の左側）に構築されたローカルネットワークが１つのプライベートネットワークを構成しており、各端末装置２００Ｅ，２００Ｆ，２００Ｇには、いずれも「192.168」なるネットワーク部で始まるプライベートＩＰアドレスが付与されている。このようなプライベートネットワークを、インターネットＮなどの公衆ネットワークを跨いでセキュアに拡張する方法として、ＶＰＮの技術が普及している。
続いて、先願基本発明に係るネットワーク通信システムにおいて、ＶＰＮ（Virtual Private Network）を利用した実施例を述べる。図１５には、ルータＲを介して端末装置をネットワークＮに接続した実施例を例示した。この例の場合、ルータＲの内側（図の左側）に構築されたローカルネットワークが１つのプライベートネットワークを構成しており、各端末装置２００Ｅ，２００Ｆ，２００Ｇには、いずれも「192.168」なるネットワーク部で始まるプライベートＩＰアドレスが付与されている。このようなプライベートネットワークを、インターネットＮなどの公衆ネットワークを跨いでセキュアに拡張する方法として、ＶＰＮの技術が普及している。
図１８は、先願基本発明に係るネットワーク通信システムにおいて、ＶＰＮを利用した実施形態の全体構成を示すブロック図である。ここでは、説明の便宜上、ある企業の東京本社に設定された３台の端末装置２００Ｈ，２００Ｉ，２００Ｊ（端末ＩＤは、それぞれ００８１，００８２，００８３）と、パリ支社に設置された１台の端末装置２００Ｋ（端末ＩＤは、００９１）という合計４台の端末装置によって、ＶＰＮを構築した単純な例を示すことにする。また、東京本社に設置された３台の端末装置２００Ｈ，２００Ｉ，２００Ｊを第１グループに所属する第１の端末装置と呼び、パリ支社に設置された１台の端末装置２００Ｋを第２グループに所属する第２の端末装置と呼ぶことにする。
図示のとおり、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊは、第１のルータＲ１を介してネットワーク（インターネット）Ｎに接続されており、第２の端末装置２００Ｋは、第２のルータＲ２を介してネットワーク（インターネット）Ｎに接続されている。したがって、基本的には、図において第１のルータＲ１より上方に配置されている第１の端末装置２００Ｈ，２００Ｉ，２００Ｊは、第１のルータＲ１が管理する第１のＬＡＮ内のホストということになり、図において第２のルータＲ２より下方に配置されている第２の端末装置２００Ｋは、第２のルータＲ２が管理する第２のＬＡＮ内のホストということになる。
このため、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊには、第１のルータＲ１が管理する第１のＬＡＮ内のプライベートＩＰアドレスが付与され、第２の端末装置２００Ｋには、第２のルータＲ２が管理する第２のＬＡＮ内のプライベートＩＰアドレスが付与されている。また、図１５に示す例と同様に、ＩＰアドレスとともにポート番号も付与されている。
図示の例の場合、第１のＬＡＮについては、クラスＢのプライベートＩＰアドレスが付与されており、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊには、それぞれ「172.16.6.11(P1)」，「172.16.6.12(P2)」，「172.16.6.13(P3)」なるＩＰアドレスおよびポート番号が付与されている（ポート番号Ｐ１，Ｐ２，Ｐ３等は、実際には２バイトのデータである）。これらの情報は、第１のルータＲ１によって、それぞれ「yy.88.105.19(P11)」，「yy.88.105.19(P12)」，「yy.88.105.19(P13)」なるグローバルＩＰアドレスＡＤｙとポート番号との組み合わせに変換された後、インターネットＮへ接続される。一方、図示の例の場合、第２のＬＡＮについては、クラスＣのプライベートＩＰアドレスが付与されており、第２の端末装置２００Ｋには、「192.168.99.11(P4)」なるＩＰアドレスおよびポート番号が付与されている。この情報は、第２のルータＲ２によって、「zz.99.214.28(P21)」なるグローバルＩＰアドレスＡＤｚとポート番号との組み合わせに変換された後、インターネットＮへ接続される。
このままの状態では、第１グループに所属する第１の端末装置２００Ｈ，２００Ｉ，２００Ｊが所属する第１のＬＡＮと、第２グループに所属する第２の端末装置２００Ｋが所属する第２のＬＡＮとは、それぞれ別個独立したプライベートネットワークになるが、図示する実施例の場合、第１のＬＡＮの範囲をインターネットＮを跨いで拡張するためのＶＰＮが構築されている。すなわち、第２の端末装置２００Ｋには、第２のルータＲ２が管理する第２のＬＡＮ内のプライベートＩＰアドレスおよびポート番号「192.168.99.11(P4)」が付与されるとともに、第１のルータＲ１が管理する第１のＬＡＮ内のプライベートＩＰアドレスおよびポート番号「172.16.6.14(P5)」が、ＶＩＰアドレスとして仮想的に付与されており、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊと第２の端末装置２００Ｋとの間には、このＶＩＰアドレスを用いて相互に交信することが可能となるようにＶＰＮの設定がなされている。
したがって、図に破線で示すように、パリ支社に設置された端末装置２００Ｋは、東京本社に設置された端末装置２００Ｈ，２００Ｉ，２００Ｊと同様に、第１のルータＲ１が管理する第１のＬＡＮ内の端末装置として取り扱うことができる。図１９は、図１８に示す実施形態におけるＶＮＰ通信の原理を示す図である。図示の例は、東京本社に設置された端末装置２００Ｈとパリ支社に設置された端末装置２００Ｋとの間のＶＰＮ通信を示している。
図１９に示すように、端末装置２００ＨにはＶＰＮ通信部２０１Ｈが、端末装置２００ＫにはＶＰＮ通信部２０１Ｋが、それぞれ設けられており、両者間にＶＰＮ暗号通信路が開設される。両者間でやりとりされるデータは暗号化されるため、実際には、インターネットＮなどの公衆ネットワークを介して情報が伝達されるにもかかわらず、あたかもプライベートネットワークを介した利便性・安全性をもった情報の送受が可能になる。ＶＰＮ通信部２０１Ｈ，２０１Ｋは、実際には、各端末装置にインストールされた専用のＶＰＮ用アプリケーションプログラムによって構築される。このようなＶＰＮの具体的な仕組は公知の技術であるため、ここでは詳しい説明は省略する。
さて、このようなＶＰＮの仕組を先願基本発明に係るネットワーク通信システムにおいて利用する場合は、接続仲介装置１００内に格納されるアドレステーブルＴに、ＶＩＰアドレスを格納しておくようにすると便利である。図２０は、図１８に示す実施形態に用いるために、ＶＩＰアドレスを追加したアドレステーブルの例を示す図である。図２０(a) に示すアドレステーブルＴ５１は、ＶＰＮの構成メンバーである端末装置２００Ｈ～２００Ｋ内の自己アドレス通知部２５０からの通知に基づいて、各端末ＩＤに対応する所在アドレス（ＩＰアドレスとポート番号）を格納したものである。
ここで、端末装置２００Ｈ～２００Ｊ（端末ＩＤ：００８１～００８３）は、東京本社に構築された第１のＬＡＮに所属する装置であるが、端末装置２００Ｋ（端末ＩＤ：００９１）は、パリ支社に構築された第２のＬＡＮに所属する装置である。ただ、上述したＶ
ＰＮの仕組により、第１のＬＡＮは端末装置２００Ｋまで仮想的に拡張されており、端末装置２００Ｋには、「ＶＩＰ（２００Ｋ）」なるＶＩＰアドレスが付与されている。このため、図２０(a) に示すアドレステーブルＴ５１の端末ＩＤ「００９１」については、更に、ＶＩＰ欄に「ＶＩＰ（２００Ｋ）」なるＶＩＰアドレスが格納されている。
ＰＮの仕組により、第１のＬＡＮは端末装置２００Ｋまで仮想的に拡張されており、端末装置２００Ｋには、「ＶＩＰ（２００Ｋ）」なるＶＩＰアドレスが付与されている。このため、図２０(a) に示すアドレステーブルＴ５１の端末ＩＤ「００９１」については、更に、ＶＩＰ欄に「ＶＩＰ（２００Ｋ）」なるＶＩＰアドレスが格納されている。
図２０(b) に示すアドレステーブルＴ５２は、図２０(a) に示すアドレステーブルＴ５１の所在アドレス欄およびＶＩＰ欄の情報を具体的なデータとして例示したものである。図１８に示す例の場合、第１のルータＲ１の外側の各通信路には、「yy.88.105.19」なるグローバルＩＰアドレスＡＤｙに、ポート番号Ｐ１１～Ｐ１３を付加した情報が所在アドレスとして付与されているため、図２０(b) に示すアドレステーブルＴ５２の端末ＩＤ「００８１～００８３」のＩＰアドレス欄には、いずれも「yy.88.105.19」なるデータが格納されており、ポート番号欄には、第１のルータＲ１によって発生された２バイトの番号「５４７０１～５４７０３」が格納されている。
一方、第２のルータＲ２の外側の各通信路には、「zz.99.214.28」なるグローバルＩＰアドレスＡＤｚに、ポート番号Ｐ２１を付加した情報が所在アドレスとして付与されているため、図２０(b) に示すアドレステーブルＴ５２の端末ＩＤ「００９１」のＩＰアドレス欄には、「zz.99.214.28」なるデータが格納されており、ポート番号欄には、第２のルータＲ２によって発生された２バイトの番号「６１９９９」が格納されている。そして、更に、端末ＩＤ「００９１」のＶＩＰ欄には、「172.16.6.14」なるＶＩＰアドレス（ＶＰＮの設定により、端末装置２００Ｋに対して付与された第１のＬＡＮについての仮想的なプライベートアドレス）が格納されている。
このように、アドレステーブルＴ５２のＶＩＰ欄に「172.16.6.14」なるＶＩＰアドレスを格納するには、第２の端末装置２００Ｋの自己アドレス通知部２５０に、接続仲介装置１００に対して、ＶＰＮの設定により付与されたＶＩＰアドレスを通知する機能をもたせておき、アドレステーブル更新部１２０に、このＶＩＰアドレスを第２の端末装置２００Ｋの所在アドレスと対応づけてアドレステーブルＴ５２に格納する機能をもたせておけばよい。
このように、アドレステーブルＴ５２に第２の端末装置２００ＫのＶＩＰアドレスを格納しておくようにすれば、たとえば、第１の端末装置２００Ｈが第２の端末装置２００Ｋを通信先として通信を行う際に、第１の端末装置２００Ｈの接続仲介依頼部２１０が、第２の端末装置２００ＫのＶＩＰアドレス「ＶＩＰ（２００Ｋ）」を通信先特定情報として用いて通信先の特定を行うことができる。
具体的には、端末装置２００Ｈの接続仲介依頼部２１０が、通信先特定情報として「172.16.6.14」なるＶＩＰアドレスを含む接続仲介依頼を行うようにすれば、接続仲介装置１００内の通信先アドレス返信部１３０は、図２０(b) に示すアドレステーブルＴ５２を参照することにより、ＶＩＰアドレス「172.16.6.14」に対応する所在アドレス「zz.99.214.28（61999）」を通信先アドレスとして返信することができる。通常、ＶＰＮの設定を行った場合、アプリケーションプログラムのレイヤーでは、端末装置２００Ｋは、「172.16.6.14」なるＶＩＰアドレスをもった装置として認識されているので、このＶＩＰアドレスを用いて接続仲介依頼を行うことができれば便利である。
もちろん、必要があれば、ＶＩＰアドレス「172.16.6.14」とともに、ポート番号「Ｐ５」を格納しておくようにしてもよい。そうすれば、「172.16.6.14（P5）」なる情報を用いて、特定のポート番号の指定を含む接続仲介依頼を行うことができる。
以上、図１に示す先願基本発明の第１の実施形態（接続仲介装置１００と端末装置２００を用いる実施形態）においてＶＰＮの設定を行い、プライベートネットワークの範囲を仮想的に拡張する例を述べたが、図７に示す先願基本発明の第２の実施形態（接続仲介装置３００と端末装置４００を用いる実施形態）においてＶＰＮの設定を行う場合も同様である。
＜＜＜§５．本発明により解決すべき技術的な課題＞＞＞
これまで、国際公開第ＷＯ２０１７/１４５９８４号公報に記載されている先願基本発明に係るネットワーク通信システムを説明してきた。本発明は、この先願基本発明を利用して、パーソナルユースを想定した安価なＩｏＴ機器を、十分なセキュリティを確保しながらインターネットに接続する新たな方法を提案するものである。
これまで、国際公開第ＷＯ２０１７/１４５９８４号公報に記載されている先願基本発明に係るネットワーク通信システムを説明してきた。本発明は、この先願基本発明を利用して、パーソナルユースを想定した安価なＩｏＴ機器を、十分なセキュリティを確保しながらインターネットに接続する新たな方法を提案するものである。
そこで、まず、ＩｏＴ機器を、従来の一般的な方法でインターネットに接続した場合の問題点を簡単に説明しておく。図２１は、パーソナルユースを想定したＩｏＴ機器をインターネットに接続した具体例を示すブロック図である。この図には、家庭Ｈ内に設置された様々な家電製品や、自動車Ｃに組み込まれた様々な電装品が、ネットワーク（インターネット）Ｎに接続されている例が示されている。具体的には、家庭Ｈ内には、監視カメラＨ１，エアコンＨ２，冷蔵庫Ｈ３，ビデオデッキＨ４，スマート鍵Ｈ５，健康器具Ｈ６（スマート体重計など），ＡＩスピーカＨ７が設置されており、自動車Ｃ内には、スマート鍵Ｃ１，エアコンＣ２，ナビシステムＣ３，オーディオＣ４が組み込まれている。
これらの家電製品Ｈ１～Ｈ７および電装品Ｃ１～Ｃ４は、いずれもＩｏＴ機器（インターネットに接続する機能をもった機器）であり、図示のとおりインターネットＮに接続されている。一方、図示の例の場合、インターネットＮには、スマートフォン１１，パソコン１２，アップデートサーバ１３といった端末装置も接続されており、これらの端末装置１１～１３は、いずれもインターネットＮを介して、任意のＩｏＴ機器Ｈ１～Ｈ７，Ｃ１～Ｃ４と通信を行うことができる。
したがって、家庭Ｈに居住し、自動車Ｃを所有するユーザは、勤務先などから、スマートフォン１１やパソコン１２を操作して、所望のＩｏＴ機器を操作することができるので、利便性は格段に向上する。また、必要に応じて、各ＩｏＴ機器は、アップデートサーバ１３から所定のアップデータをダウンロードして、内蔵するファームウェアをアップデートすることができるので、常に最新のプログラムを用いた動作が可能になる。
なお、図２１には、ＩｏＴ機器Ｈ１～Ｈ７，Ｃ１～Ｃ４や各端末装置１１～１３を、インターネットＮに直接接続した例が示されているが、ルータを介してネットワークＮに接続する形態も一般に利用されている。もちろん、外部からのハッキング攻撃に備える上では、ＩｏＴ機器も各端末装置も、ルータを介してネットワークに接続するようにするのが好ましい。ただ、監視カメラなどでは、ルータを介してインターネットＮに接続すると、取り扱い手順が複雑になるため、直接インターネットＮに接続して利用する形態も少なくない。
もっとも、各ＩｏＴ機器がインターネットＮに接続されている以上、常にセキュリティ上の問題が生じることになる。図示されているとおり、インターネットＮには不正な端末装置１９も接続可能であり、クラッカーがこの端末装置１９を用いて各ＩｏＴ機器に対するハッキングを試みる可能性がある。特に、図示の例のように、インターネットＮに直接接続されているＩｏＴ機器に対しては、不正な端末装置１９によるアクセスが非常に容易であり、ハッキングを受ける危険性は非常に高くなる。
これに対して、各ＩｏＴ機器がルータを介してインターネットＮに接続されている場合は、セキュリティ対策の効果は若干向上する。インターネットＮとＩｏＴ機器との間にルータが設けられていると、不正な端末装置１９は、ルータに対しては、そのグローバルＩＰアドレスを用いてアクセス可能であるが、ルータの配下にあるＩｏＴ機器に付与されているプライベートＩＰアドレスは不明であるため、通常の方法では、特定のＩｏＴ機器にはアクセスできない。しかしながら、図１５で例示したように、ポート番号を指定すれば、ルータのＮＡＰＴ機能により、特定のＩｏＴ機器のプライベートＩＰアドレスへのアクセスが可能になる。別言すれば、一般的なルータは、外部から特定のポート番号を指定したアクセスがあり、当該ポート番号が有効なものであれば、これを受け入れざるを得ない。したがって、ルータを介した接続を行ったとしても、依然として、ハッキングを受ける危険性は残ることになる。
しかも、パーソナルユースを想定した家電製品や自動車の電装品などのＩｏＴ機器の場合、一般的なコンピュータ機器に比べて、ＣＰＵやメモリの構成が貧弱であり、十分なセキュリティ対策が施されていないのが現状である。たとえば、図２１に示すＩｏＴ機器Ｈ１～Ｈ７，Ｃ１～Ｃ４の場合も、ウィルス対策ソフトなどを組み込むことなしに運用されるのが一般的である。このため、これらのＩｏＴ機器が、不正な端末装置１９からハッキングを受けると、これに対する防御手段を欠いているため、マルウェアに感染してボット化する可能性が極めて高い。
また、一般的なＩｏＴ機器では、定期的に内蔵ファームウェアのアップデートを行う必要が生じる。本来であれば、このアップデートは、インターネットＮを介して専用のアップデートサーバ１３に接続して行うことになるが、クラッカーによる攻撃を受けると、正規のアップデートサーバ１３ではなく、不正な端末装置１９に接続されてしまい、マルウェアを含んだ偽のアップデータがインストールされる事態に陥る。
通常、アップデート処理は、アップデートサーバ１３側から自発的にＩｏＴ機器側にアップデータを配信するPush型の配信を行う形態と、ＩｏＴ機器側からアップデートサーバ１３へアップデートの要求を送信することにより、当該要求に応じて、アップデータのダウンロードが開始されるPull型の配信を行う形態と、が利用されているが、いずれの形態を採る場合も、ハッキングを受ける可能性がある。
すなわち、Push型の配信形態を採る場合は、不正な端末装置１９が、正規のアップデートサーバ１３を偽装してアップデータを配信してくると、これを受け入れたＩｏＴ機器は、マルウェアに感染してしまうことになる。一方、Pull型の配信形態を採る場合、一応、ＩｏＴ機器側から正規のアップデートサーバ１３宛にアップデートの要求が送信されることになるが、クラッカーによって仕組まれたＤＮＳ詐称攻撃を受けると、アップデートの要求は、正規のアップデートサーバ１３ではなく、不正な端末装置１９へと誘導され、やはり偽のアップデータの配信を受けることになる。
このように、パーソナルユースを想定した家電製品や自動車の電装品などのＩｏＴ機器は、一般的なコンピュータ機器に比べて、セキュリティ上の脆弱性を有していると言わざるを得ない。本発明は、このような問題を解決するための新たな提案を行うものであり、その目的は、パーソナルユースを想定した安価なＩｏＴ機器を、十分なセキュリティを確保しながらインターネットに接続することができるネットワーク通信システムを提供することにある。
＜＜＜§６．本発明の基本的な実施形態＞＞＞
続いて、本発明を図示する基本的な実施形態に基づいて説明する。図２２は、本発明の基本的な実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。このネットワーク通信システムは、図示のとおり、ネットワークＮ（インターネット）を介して相互に接続可能な複数の端末装置（図には、４台の端末装置６００Ａ～６００Ｄが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置５００と、端末装置のうちの１台（図示の例の場合、６００Ａ）を包含するゲートウェイ装置ＧＷ（図では、太枠のブロックで示す）と、を備えている。
続いて、本発明を図示する基本的な実施形態に基づいて説明する。図２２は、本発明の基本的な実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。このネットワーク通信システムは、図示のとおり、ネットワークＮ（インターネット）を介して相互に接続可能な複数の端末装置（図には、４台の端末装置６００Ａ～６００Ｄが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置５００と、端末装置のうちの１台（図示の例の場合、６００Ａ）を包含するゲートウェイ装置ＧＷ（図では、太枠のブロックで示す）と、を備えている。
図示の例の場合、端末装置６００Ａは、ゲートウェイ装置ＧＷに包含されている端末装置であり、端末装置６００Ｂ，６００Ｃ，６００Ｄは、ゲートウェイ装置ＧＷの外部に位置する端末装置である。そこで、ここでは説明の便宜上、端末装置６００Ａを「内部端末装置」と呼び、端末装置６００Ｂ，６００Ｃ，６００Ｄを「外部端末装置」と呼ぶことにする。
ゲートウェイ装置ＧＷは、本発明の特徴的な構成要素であり、下流側に接続された１台もしくは複数台のＩｏＴ機器を、上流側に接続されたネットワークＮ（インターネット）に接続する役割を果たす。このゲートウェイ装置ＧＷは、内部端末装置６００Ａを包含し、更に、ＩｏＴ機器登録テーブルＴＴ等の付加的な構成要素を有している。図示の例の場合、ゲートウェイ装置ＧＷの下流側には、家庭Ｈに設置された５台のＩｏＴ機器７０１～７０５が接続されている。具体的には、ＩｏＴ機器７０１は監視カメラ、ＩｏＴ機器７０２はエアコン、ＩｏＴ機器７０３は冷蔵庫、ＩｏＴ機器７０４はビデオデッキ、ＩｏＴ機器７０５はスマート鍵である。
実際には、ゲートウェイ装置ＧＷは、家庭Ｈ内に設置するのが好ましい。もちろん、ゲートウェイ装置ＧＷの下流側に接続するＩｏＴ機器は、家庭内で用いる家電製品に限定されるものではなく、たとえば、図２１に示す自動車Ｃに用いる種々の電装品であってもかまわない。この場合、ゲートウェイ装置ＧＷは、自動車Ｃ内に組み込むようにするのが好ましい。
ゲートウェイ装置ＧＷは、ルータと同等の機能を果たす装置であり、家庭Ｈに設置された５台のＩｏＴ機器７０１～７０５は、このゲートウェイ装置ＧＷを介してインターネットＮに接続されていることになる。ただ、一般的なルータは、下流側に接続された配下の装置に対してプライベートＩＰアドレスを付与して、この配下の装置との間でＩＰパケットをやりとりして通信を行うことになるが、本発明の場合、各ＩｏＴ機器７０１～７０５には、必ずしもプライベートＩＰアドレスを付与する必要はなく、ゲートウェイ装置ＧＷと配下のＩｏＴ機器７０１～７０５との間の通信は、必ずしもＩＰパケットをやりとりする通信にする必要はない。
本発明に係るゲートウェイ装置ＧＷと一般的なルータとの大きな違いは、ネットワークＮ（インターネット）に対する通信が、内部端末装置６００Ａによって行われる点である。この図２２に示すネットワーク通信システムは、先願基本発明の第１の実施形態（図１参照）もしくは第２の実施形態（図６参照）を利用して構成されており、各端末装置６００Ａ～６００Ｄには、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されている。接続仲介装置５００は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。したがって、外部端末装置６００Ｂ～６００Ｄとゲートウェイ装置ＧＷ（内部端末装置６００Ａ）との間のネットワークＮを介した通信は、接続仲介装置５００による仲介によって開始することになる。
ここで、内部端末装置６００Ａも外部端末装置６００Ｂ～６００Ｄも、先願基本発明の第１の実施形態で述べた端末装置２００の各構成要素（図２参照）もしくは第２の実施形態で述べた端末装置４００の各構成要素（図７参照）を有している。また、接続仲介装置５００は、先願基本発明の第１の実施形態で述べた接続仲介装置１００の各構成要素（図１参照）もしくは第２の実施形態で述べた接続仲介装置３００の各構成要素（図６参照）を有している。
より具体的に説明すれば、先願基本発明の第１の実施形態を利用して本発明に係るネットワーク通信システムを構成する場合、図２２に示す各端末装置６００Ａ～６００Ｄは、いずれも、図２に示す端末装置２００の構成要素である、接続仲介依頼部２１０，通信要求受付部２２０，通信先セッション確立部２３０，通信開始要求部２４０，自己アドレス通知部２５０，通信元セッション確立部２６０と同等の構成要素を備えていることになる。そして、図２２に示す接続仲介装置５００は、図１に示す端末装置１００の構成要素である、アドレステーブル格納部１１０，アドレステーブル更新部１２０，通信先アドレス返信部１３０と同等の構成要素を備えていることになる。
一方、先願基本発明の第２の実施形態を利用して本発明に係るネットワーク通信システムを構成する場合、図２２に示す各端末装置６００Ａ～６００Ｄは、いずれも、図７に示す端末装置４００の構成要素である、接続仲介依頼部４１０，通信要求受付部４２０，通信元セッション確立部４３０，通信開始要求部４４０，自己アドレス通知部４５０，通信先セッション確立部４６０と同等の構成要素を備えていることになる。そして、図２２に示す接続仲介装置５００は、図６に示す端末装置３００の構成要素である、アドレステーブル格納部３１０，アドレステーブル更新部３２０，通信元アドレス送信部３３０と同等の構成要素を備えていることになる。
したがって、図２２に示す各端末装置６００Ａ～６００Ｄ間の相互通信は、接続仲介装置５００による仲介によって開始することになる。図示の例の場合、ゲートウェイ装置ＧＷに組み込まれている内部端末装置６００Ａには、端末ＩＤ「０１１０」が付与されている。また、図示の実施例の場合、外部端末装置６００Ｂは、端末ＩＤ「０１２０」が付与されたスマートフォンであり、外部端末装置６００Ｃは、端末ＩＤ「０１３０」が付与されたパソコンである。ここでは、外部端末装置６００Ｂ，６００Ｃが、家庭Ｈの居住者が所有するスマートフォンや携帯型パソコンであるものとして、以下の説明を行う。一方、外部端末装置６００Ｄは、端末ＩＤ「０１４０」が付与されたアップデートサーバであり、このアップデートサーバにより、家庭Ｈ内に設置された各ＩｏＴ機器７０１～７０５に対するアップデート処理が実行されるものとして、以下の説明を行う。
接続仲介装置５００内のアドレステーブルＴには、各端末装置６００Ａ～６００Ｄについて、端末ＩＤ「０１１０」，「０１２０」，「０１３０」，「０１４０」と、現時点の所在アドレス「ＡＤ１１」，「ＡＤ１２」，「ＡＤ１３」，「ＡＤ１４」との対応関係が記録されている。このため、各端末装置６００Ａ～６００Ｄのアドレスが変更されても、アドレステーブルＴを参照することにより、常に通信先のアドレスを把握することができ、接続仲介装置５００による適切な仲介処理が実行される点は、既に、§１，§２で説明したとおりである。
実際、内部端末装置６００Ａと外部端末装置６００Ｂ～６００Ｄとの間の通信は、§１もしくは§２で述べた手順によって実行されることになる。したがって、ここでは、端末装置６００Ａ～６００Ｄを構成する各構成要素の処理機能や、具体的な仲介処理の手順についての説明は省略する。もちろん、この図２２に示すネットワーク通信システムにおいても、§３で述べた変形例や、§４で述べた実用的な実施形態を適用することが可能である。
続いて、ゲートウェイ装置ＧＷには包含されていない外部端末装置６００Ｂ～６００Ｄが、ゲートウェイ装置ＧＷの下流側に接続されている特定のＩｏＴ機器に対する通信を開始する際の処理を説明する。ここでは、外部端末装置６００Ｂ（スマートフォン）を用いて、家庭Ｈの居住者であるユーザが、外出先から、家庭Ｈ内に設置されたＩｏＴ機器７０１～７０５に対して通信を行い、所望の動作制御を行う場合について、その具体的な処理
手順を述べることにする。
手順を述べることにする。
はじめに、図２２に示すネットワーク通信システムが、§１で述べた先願基本発明の第１の実施形態を利用したシステムであった場合を説明する。この場合、端末装置６００Ａ～６００Ｄは、図２に示す端末装置２００と同等の構成を有し、接続仲介装置５００は、図１に示す接続仲介装置１００と同等の構成を有し、図４および図５に示す手順に従って、端末装置相互間の通信セッションが確立されることになる。
たとえば、ユーザが、外出先から外部端末装置６００Ｂ（スマートフォン）を用いて、家庭Ｈ内に設置されたＩｏＴ機器７０２（エアコン）に対する動作指示を与える場合の手順を考えてみる。この場合、ユーザは、外部端末装置６００Ｂに組み込まれた遠隔操作用アプリケーションプログラム（エアコンを遠隔制御するためのプログラム）を起動して、エアコンに対する所望の動作指示を入力する。すると、当該アプリケーションプログラムは、外部端末装置６００Ｂ内の通信要求受付部（図４の２２０Ａに相当）に対して、外部端末装置６００Ｂを通信元、内部端末装置６００Ａを通信先とする通信要求Ｓ１を与える。
すると、当該通信要求Ｓ１に基づいて、外部端末装置６００Ｂ内の接続仲介依頼部（図４の２１０Ａに相当）が、ゲートウェイ装置ＧＷに包含されている内部端末装置６００Ａを通信先として特定するための通信先特定情報（端末ＩＤ「０１１０」を示す情報）を含む接続仲介依頼Ｓ２を、接続仲介装置５００に対して送信する。接続仲介装置５００は、アドレステーブルＴを参照することにより、接続仲介依頼Ｓ２に含まれている通信先特定情報によって特定される端末ＩＤ「０１１０」に対応づけられている所在アドレス「ＡＤ１１」を、通信先アドレスとして、外部端末装置６００Ｂ内の通信開始要求部（図４の２４０Ａに相当）に対して返信する（図４のＳ４に相当）。
続いて、外部端末装置６００Ｂ内の通信開始要求部（図４の２４０Ａに相当）は、接続仲介依頼Ｓ２に応じて返信されてきた通信先アドレス「ＡＤ１１」（内部端末装置６００Ａ）にアクセスして通信開始要求Ｓ５を行う。すると、内部端末装置６００Ａ内の通信先セッション確立部（図４の２３０Ｂに対応）は、この通信開始要求Ｓ５に応じて、通信元の外部端末装置６００Ｂに対して通信開始受諾確認Ｓ６を送信し、通信元の外部端末装置６００Ｂとの間に通信セッションを確立して通信（図４のＳ７に相当）を開始する。
一方、通信元となる外部端末装置６００Ｂの通信元セッション確立部（図４の２６０Ａに相当）は、内部端末装置６００Ａの通信先セッション確立部（図４の２３０Ｂに対応）に対して通信（図４のＳ７）を行う。具体的には、通信元となる外部端末装置６００Ｂの通信元セッション確立部（図４の２６０Ａに相当）は、内部端末装置６００Ａに対して、最終的な通信先となる特定のＩｏＴ機器（ここに示す例の場合、ＩｏＴ機器７０２のエアコン）に送信すべきＩｏＴ機器宛データ（ここに示す例の場合、エアコンに対する動作指示データ）と当該特定のＩｏＴ機器を特定する機器特定情報とが含まれた通信データを送信する。
こうして、外部端末装置６００Ｂから内部端末装置６００Ａに対して送信された通信データは、エアコンに対する所望の動作指示を示すデータである。このようなデータ送信の手順は、既に§１で述べたとおりである。このように、外部端末装置６００Ｂから内部端末装置６００Ａに対するデータ送信は、接続仲介装置５００による仲介処理を経て行われることになる。もちろん、このような仲介処理を行うためには、事前に、接続仲介装置５００内のアドレステーブルＴに、内部端末装置６００Ａおよび外部端末装置６００Ｂについての端末ＩＤおよび所在アドレスが登録されている必要がある。
結局、エアコンに対する所望の動作指示を示すデータは、通信データとして、ゲートウェイ装置ＧＷ内の内部端末装置６００Ａまで到達したことになる。ゲートウェイ装置ＧＷは、このような通信データを受信したときに、この通信データから機器特定情報（ここに示す例の場合、ＩｏＴ機器７０２のエアコンを特定する情報）およびＩｏＴ機器宛データ（ここに示す例の場合、エアコンに対する動作指示データ）を抽出し、抽出したＩｏＴ機器宛データを、抽出した機器特定情報によって特定されるＩｏＴ機器７０２（エアコン）に配信する処理を行う。かくして、ユーザが、外出先から送信した動作指示が、最終的な目的地であるＩｏＴ機器７０２（エアコン）まで到達する。そして、エアコンが当該動作指示を実行することにより、エアコンに対する遠隔制御が行われることになる。
続いて、図２２に示すネットワーク通信システムが、§２で述べた先願基本発明の第２の実施形態を利用したシステムであった場合を説明する。この場合、端末装置６００Ａ～６００Ｄは、図７に示す端末装置４００と同等の構成を有し、接続仲介装置５００は、図６に示す接続仲介装置３００と同等の構成を有し、図８および図９に示す手順に従って、端末装置相互間の通信セッションが確立されることになる。
ここでも、ユーザが、外出先から外部端末装置６００Ｂ（スマートフォン）を用いて、家庭Ｈ内に設置されたＩｏＴ機器７０２（エアコン）に対する動作指示を与える場合の手順を考えてみる。この場合、ユーザは、外部端末装置６００Ｂに組み込まれた遠隔操作用アプリケーションプログラム（エアコンを遠隔制御するためのプログラム）を起動して、エアコンに対する所望の動作指示を入力する。すると、当該アプリケーションプログラムは、外部端末装置６００Ｂ内の通信要求受付部（図８の４２０Ｂに相当）に対して、外部端末装置６００Ｂを通信元、内部端末装置６００Ａを通信先とする通信要求Ｓ１１を与える。
すると、当該通信要求Ｓ１１に基づいて、外部端末装置６００Ｂ内の接続仲介依頼部（図８の４１０Ｂに相当）が、ゲートウェイ装置ＧＷに包含されている内部端末装置６００Ａを通信先として特定するための通信先特定情報（端末ＩＤ「０１１０」を示す情報）を含む接続仲介依頼Ｓ１２を、接続仲介装置５００に対して送信する。接続仲介装置５００は、アドレステーブルＴを参照することにより、接続仲介依頼Ｓ１２に含まれている通信先特定情報によって特定される端末ＩＤ「０１１０」に対応づけられている所在アドレス「ＡＤ１１」（内部端末装置６００Ａのアドレス）に対して、接続仲介依頼Ｓ１２を送信した通信元の外部端末装置６００Ｂ内の端末ＩＤ「０１２０」に対応づけられている所在アドレス「ＡＤ１２」を通信元アドレスとして送信する（図８のＳ１４に相当）。
続いて、内部端末装置６００Ａ内の通信開始要求部（図８の４４０Ａに相当）は、接続仲介依頼Ｓ１２に応じて送信されてきた通信元アドレス「ＡＤ１２」（外部端末装置６００Ｂ）にアクセスして通信開始要求Ｓ１５を行う。すると、外部端末装置６００Ｂ内の通信元セッション確立部（図８の４３０Ｂに対応）は、この通信開始要求Ｓ１５に応じて、通信先の内部端末装置６００Ａに対して通信開始受諾確認Ｓ１６を送信し、通信先の内部端末装置６００Ａとの間に通信セッションを確立して通信（図８のＳ１７に相当）を開始する。
具体的には、通信元となる外部端末装置６００Ｂの通信元セッション確立部（図８の４３０Ｂに相当）は、内部端末装置６００Ａに対して、最終的な通信先となる特定のＩｏＴ機器（ここに示す例の場合、ＩｏＴ機器７０２のエアコン）に送信すべきＩｏＴ機器宛データ（ここに示す例の場合、エアコンに対する動作指示データ）と当該特定のＩｏＴ機器を特定する機器特定情報とが含まれた通信データを送信する。
一方、通信先となる内部端末装置６００Ａの通信先セッション確立部（図８の４６０Ａに相当）は、外部端末装置６００Ｂの通信元セッション確立部（図８の４３０Ｂに対応）に対して通信（図８のＳ１７）を行う。かくして相互間の通信が開始される。
ここで、外部端末装置６００Ｂから内部端末装置６００Ａに対して送信される通信データは、エアコンに対する所望の動作指示を示すデータである。このようなデータ送信の手順は、既に§２で述べたとおりである。このように、外部端末装置６００Ｂから内部端末装置６００Ａに対するデータ送信は、接続仲介装置５００による仲介処理を経て行われることになる。もちろん、このような仲介処理を行うためには、事前に、接続仲介装置５００内のアドレステーブルＴに、内部端末装置６００Ａおよび外部端末装置６００Ｂについての端末ＩＤおよび所在アドレスが登録されている必要がある。
結局、エアコンに対する所望の動作指示を示すデータは、通信データとして、ゲートウェイ装置ＧＷ内の内部端末装置６００Ａまで到達したことになる。ゲートウェイ装置ＧＷは、このような通信データを受信したときに、この通信データから機器特定情報（ここに示す例の場合、ＩｏＴ機器７０２のエアコンを特定する情報）およびＩｏＴ機器宛データ（ここに示す例の場合、エアコンに対する動作指示データ）を抽出し、抽出したＩｏＴ機器宛データを、抽出した機器特定情報によって特定されるＩｏＴ機器７０２（エアコン）に配信する処理を行う。かくして、ユーザが、外出先から送信した動作指示が、最終的な目的地であるＩｏＴ機器７０２（エアコン）まで到達する。そして、エアコンが当該動作指示を実行することにより、エアコンに対する遠隔制御が行われることになる。
以上、外部端末装置６００Ｂ（スマートフォン）からＩｏＴ機器７０２（エアコン）に対して、動作指示を送信する手順を説明したが、他のＩｏＴ機器７０１，７０３～７０５に対して動作指示を送信する手順も同様である。もちろん、外部端末装置６００Ｃ（パソコン）から特定のＩｏＴ機器に動作指示を送信する手順も同様である。また、外部端末装置６００Ｄ（アップデートサーバ）から特定のＩｏＴ機器に対して、自発的にアップデータをPush型配信する手順やＩｏＴ機器からの要求に応じてPull型配信する手順も同様である。
このように、図２２に示すネットワーク通信システムでは、外部端末装置６００Ｂから内部端末装置６００Ａに対する通信が、§１もしくは§２で述べた先願基本発明を利用して行われる。このため、端末間通信を開始する際には、必ず接続仲介装置５００による仲介処理が必要になるので、このネットワーク通信システムによって通信が可能になるのは、予めアドレステーブルＴに登録された端末装置間に限定されることになる。
したがって、アドレステーブルＴへの登録がなされていない不正な端末装置から内部端末装置６００Ａ（ゲートウェイ装置ＧＷ）へのアクセスは排除され、各ＩｏＴ機器に対する不正なアクセスも排除されることになる。たとえば、Pull型の配信形態によりアップデータをダウンロードする場合に、クラッカーがＤＮＳ詐称攻撃を画策し、正規のアップデートサーバ１３ではなく、不正な端末装置１９へと誘導する罠を仕掛けていたとしても、接続仲介装置５００は、当該不正な端末装置１９への接続仲介を行わないため、偽のアップデータの配信を受けるような事態を未然に防ぐことができる。かくして、このネットワーク通信システムによれば、特に、インターネット側からＩｏＴ機器側への通信を制限することができるので、たとえパーソナルユースを想定した安価なＩｏＴ機器であっても、十分なセキュリティを確保しながらインターネットに接続することが可能になる。
＜＜＜§７．本発明における通信データの具体的構造＞＞＞
§６では、図２２を参照しながら、本発明の基本的な実施形態の構成を示し、更に、外部端末装置６００Ｂ（スマートフォン）から特定のＩｏＴ機器７０２（エアコン）に対して、動作指示を送信する具体的な手順を説明した。ここでは、外部端末装置から内部端末装置に対して送信される通信データの具体的な構造を詳述するとともに、ゲートウェイ装置ＧＷによるＩｏＴ機器宛データの具体的な配信方法を説明する。
§６では、図２２を参照しながら、本発明の基本的な実施形態の構成を示し、更に、外部端末装置６００Ｂ（スマートフォン）から特定のＩｏＴ機器７０２（エアコン）に対して、動作指示を送信する具体的な手順を説明した。ここでは、外部端末装置から内部端末装置に対して送信される通信データの具体的な構造を詳述するとともに、ゲートウェイ装置ＧＷによるＩｏＴ機器宛データの具体的な配信方法を説明する。
＜７．１基本的な通信データの構造＞
図２３は、図２２に示すネットワーク通信システムにおいて、外部端末装置６００Ｂ～６００Ｄから内部端末装置６００Ａ宛に送信する通信データＱ１０の基本的な構成例を示す図である。ここに示す例の場合、通信データＱ１０は、ＩＰプロトコルに従ったデータ構造を有するＩＰパケットの形態をとっている。インターネットを介した通信では、ＩＰパケットを用いたパケット通信を行うのが一般的であり、本発明を実施する場合も、通信データＱ１０としてＩＰパケットを用いるのが好ましい。実用上は、このＩＰパケットからなる通信データＱ１０を、ＵＤＩやＴＣＰといったトランスポート層上のプロトコルに基づいて送信すればよい。
図２３は、図２２に示すネットワーク通信システムにおいて、外部端末装置６００Ｂ～６００Ｄから内部端末装置６００Ａ宛に送信する通信データＱ１０の基本的な構成例を示す図である。ここに示す例の場合、通信データＱ１０は、ＩＰプロトコルに従ったデータ構造を有するＩＰパケットの形態をとっている。インターネットを介した通信では、ＩＰパケットを用いたパケット通信を行うのが一般的であり、本発明を実施する場合も、通信データＱ１０としてＩＰパケットを用いるのが好ましい。実用上は、このＩＰパケットからなる通信データＱ１０を、ＵＤＩやＴＣＰといったトランスポート層上のプロトコルに基づいて送信すればよい。
図２３に示すように、この通信データＱ１０（ＩＰパケット）は、ＩＰヘッダ部Ｑ１１とＩＰデータ部Ｑ１２とによって構成される。ＩＰヘッダ部Ｑ１１には、送信元アドレスＱ１１１と送信先アドレスＱ１１２とが含まれ、このＩＰパケットは、送信元アドレスＱ１１１で示される外部端末装置６００Ｂ～６００Ｄから、送信先アドレスＱ１１２で示される内部端末装置６００Ａに向けて送信される。たとえば、図２２に示す例において、外部端末装置６００Ｂ（スマートフォン）から内部端末装置６００Ａ（ゲートウェイ装置ＧＷ）宛に送信する通信データＱ１０の場合、ＩＰヘッダ部Ｑ１１には、送信元アドレスＱ１１１として外部端末装置６００Ｂの所在アドレス「ＡＤ１２」が記録され、送信先アドレスＱ１１２として内部端末装置６００Ａの所在アドレス「ＡＤ１１」が記録されることになる。
一方、ＩＰデータ部Ｑ１２には、ＩｏＴ機器を特定する機器特定情報Ｑ１２１と、このＩｏＴ機器に送信すべきＩｏＴ機器宛データＱ１２２とが含まれている。ＩｏＴ機器宛データＱ１２２は、特定のＩｏＴ機器に対して与える動作指示データやアップデータなどのデータであり、機器特定情報Ｑ１２１は、当該データの最終的な目的地となるＩｏＴ機器を特定する情報である。
通信データＱ１０は、前述したとおり、ゲートウェイ装置ＧＷ内の内部端末装置６００Ａによって受信される。ゲートウェイ装置ＧＷは、受信した通信データＱ１０のＩＰデータ部Ｑ１２に含まれている機器特定情報Ｑ１２１およびＩｏＴ機器宛データＱ１２２に基づいて、ＩｏＴ機器宛データＱ１２２を、機器特定情報Ｑ１２１によって特定されるＩｏＴ機器に配信する処理を行う。
図２２に示す基本的な実施形態の場合、ゲートウェイ装置ＧＷ内には、ＩｏＴ機器宛データＱ１２２を配信するために、ＩｏＴ機器登録テーブルＴＴが格納されている。このＩｏＴ機器登録テーブルＴＴは、図２４に例示するとおり、ゲートウェイ装置ＧＷの下流側に接続されている個々のＩｏＴ機器７０１～７０５についての機器特定情報Ｑ１２１と、当該ＩｏＴ機器へのアクセス方法を示すアクセス方法情報と、を対応づけたテーブルである。
ゲートウェイ装置ＧＷは、通信データＱ１０を受信したときに、ＩｏＴ機器登録テーブルＴＴを参照することにより、受信した通信データＱ１０から抽出した機器特定情報Ｑ１２１に対応するアクセス方法情報によって示されるアクセス方法を用いて、配信先のＩｏＴ機器７０１～７０５をアクセスし、受信した通信データＱ１０から抽出したＩｏＴ機器宛データＱ１２２を、配信先のＩｏＴ機器７０１～７０５に配信する。
図２４に例示するＩｏＴ機器登録テーブルＴＴでは、機器特定情報Ｑ１２１として、ＩｏＴ機器のメーカ名、製品型番、製品番号を含む情報が登録されている。ここで、メーカ名は、当該ＩｏＴ機器の製造もしくは販売を行う事業者名であり、略号や事業者コードを用いてもかまわない。製品型番は、当該ＩｏＴ機器に対して事業者が付与した型番であり、製品番号は、当該ＩｏＴ機器に対して事業者が付与した個々の製品ごとの番号である。この３つの情報の組み合わせを用いることにより、ＩｏＴ機器ごとにユニークな機器特定情報Ｑ１２１を定義することができる。
もちろん、機器特定情報Ｑ１２１の構成は、この実施例に限定されるものではなく、少なくとも、同一のゲートウェイ装置ＧＷの下流側に接続された複数のＩｏＴ機器を相互に区別できるような情報であれば、当該情報を機器特定情報Ｑ１２１として用いることが可能である。ただ、図示の実施例のような３つの情報の組み合わせによって機器特定情報Ｑ１２１を構成しておけば、世界中のＩｏＴ機器について、それぞれユニークな機器特定情報を定義することができ、また、どのメーカの、どの製品の、どの個別機器であるかを認識することもできるので、実用上は、このような３つの情報の組み合わせによって機器特定情報Ｑ１２１を構成するのが好ましい。
一方、図２４に例示するＩｏＴ機器登録テーブルＴＴでは、アクセス方法情報として、ＩｏＴ機器に対する通信を行う上での通信規格および当該通信規格に応じたアクセスを行う際の固有アドレスを含む情報が登録されている。図２２に示すネットワーク通信システムにおいて、外部端末装置６００Ｂ～６００Ｄと内部端末装置６００Ａ（ゲートウェイ装置ＧＷ）との間の通信は、上述したとおり、ＩＰプロトコルに従って行われ、通信データＱ１０はＩＰパケットを構成することになる。これに対して、ゲートウェイ装置ＧＷとその下流側に接続された各ＩｏＴ機器７０１～７０５との間の通信は、必ずしもＩＰプロトコルに従って行う必要はなく、様々な通信規格に基づく通信を行うことが可能である。
図２４に示すＩｏＴ機器登録テーブルＴＴでは、通信規格として、ＷｉＦｉ，イーサネット（登録商標），近距離無線通信（たとえば、Bluetooth（登録商標）など）の３種類が例示されているが、この他にも、たとえば赤外線を用いた通信などを利用してもかまわない。通信規格として、ＷｉＦｉやイーサネット（登録商標）を用いる場合、通常は、ＩＰプロトコルに従った通信が利用されるが、もちろん、それ以外のプロトコルを用いてもかまわない。
実際、個々のＩｏＴ機器を遠隔操作するための動作指示信号の通信規格や通信プロトコルは、当該ＩｏＴ機器の製造メーカが任意に定めるものである。したがって、ゲートウェイ装置ＧＷ内に、これら個々のＩｏＴ機器が採用している特定の通信規格や特定の通信プロトコルに基づく通信手段（ハードウェアおよびソフトウェア）を設けておくようにすれば、あらゆるＩｏＴ機器に対する個別通信が可能になる。
なお、個々のＩｏＴ機器について、通信規格とともに登録される固有アドレスは、当該通信規格によって当該ＩｏＴ機器にアクセスする際に必要となるアドレスである。たとえば、ＷｉＦｉやイーサネット（登録商標）を用いてＩＰプロトコルによるアクセスを行う場合であれば、アクセス対象となるＩｏＴ機器に付与されたＩＰアドレスを固有アドレスとして登録することができ、Bluetooth（登録商標）などの近距離無線通信を用いたアクセスを行う場合であれば、ＩｏＴ機器とゲートウェイ装置ＧＷとの間で予め行われたペアリング処理で定められたアドレスを固有アドレスとして登録することができる。もちろん、ＩｏＴ機器のＭＡＣアドレスなどを固有アドレスとして登録してもかまわない。
ユーザは、家庭Ｈ内に、新たなＩｏＴ機器を設置したときに、当該ＩｏＴ機器についての機器特定情報Ｑ１２１およびアクセス方法情報を、ゲートウェイ装置ＧＷ内のＩｏＴ機器登録テーブルＴＴに登録する作業を行うようにする。たとえば、図２４に示すＩｏＴ機器登録テーブルＴＴの２行目には、Ｙ社のエアコン７０２をＩｏＴ機器として登録した場合の例が示されている。具体的には、エアコン７０２について、機器特定情報Ｑ１２１として、メーカ名「Ｙ社」、製品型番「ＹＡ－４５６」、製品番号「４５６７８９」なる情報が登録され、アクセス方法情報として、通信規格「ＷｉＦｉ」、固有アドレス「ＡＤ７０２」なる情報が登録された例が示されている。
なお、ユーザがこれらの情報を手入力で登録することは繁雑であるので、実用上は、専用の登録用プログラムを、個々のＩｏＴ機器内もしくはゲートウェイ装置ＧＷ内、またはその双方に用意しておき、この登録用プログラムを起動することにより、ＩｏＴ機器登録テーブルＴＴへの登録が自動的に行われるようにするのが好ましい。
また、外出先から外部端末装置６００Ｂ（スマートフォン）や６００Ｃ（パソコン）を用いて、このエアコン７０２を制御するためには、外部端末装置６００Ｂ，６００Ｃ内に、ゲートウェイ装置ＧＷに組み込まれた内部端末装置６００Ａの端末ＩＤ「０１１０」と、エアコン７０２を特定するための機器特定情報Ｑ１２１を登録しておく必要がある。したがって、ユーザは、Ｙ社のエアコン７０２を新たなＩｏＴ機器として設置した場合、機器特定情報Ｑ１２１を、ゲートウェイ装置ＧＷ内のＩｏＴ機器登録テーブルＴＴに登録するとともに、外部端末装置６００Ｂ，６００Ｃ内に対して、内部端末装置６００Ａの端末ＩＤ「０１１０」とエアコン７０２の機器特定情報Ｑ１２１とを登録する作業を行う必要がある。
この外部端末装置に対する登録作業も、実用上は、専用の登録用プログラムを用いて自動的に行うようにするのが好ましい。実際には、外部端末装置６００Ｂ，６００Ｃによって、エアコン７０２などのＩｏＴ機器を遠隔操作するためには、専用の遠隔操作用プログラムを外部端末装置６００Ｂ，６００Ｃに組み込むことになるので、この遠隔操作用プログラムのインストール処理の一環として、内部端末装置６００Ａの端末ＩＤ「０１１０」とエアコン７０２の機器特定情報Ｑ１２１とを併せて組み込むようにしておけばよい。
そうすれば、たとえば、エアコン７０２を遠隔操作するための遠隔操作プログラムを外部端末装置６００Ｂ（スマートフォン）にインストールする際に、内部端末装置６００Ａの端末ＩＤ「０１１０」と、エアコン７０２についてのメーカ名「Ｙ社」、製品型番「ＹＡ－４５６」、製品番号「４５６７８９」なる機器特定情報Ｑ１２１が外部端末装置６００Ｂに組み込まれることになる。
ユーザが、外出先から外部端末装置６００Ｂを操作して、家庭Ｈ内のエアコン７０２を制御する際には、インストールされた遠隔操作プログラムを起動して、所望の動作指示（たとえば、室温を２８°Ｃに維持するように冷房機能をＯＮにする動作指示）を入力すればよい。そうすると、当該遠隔操作プログラムから、外部端末装置６００Ｂ内の通信要求受付部２２０，４２０に対して、内部端末装置６００Ａを通信先とする通信要求Ｓ１，Ｓ１１がなされ（図４，図８参照）、接続仲介依頼部２１０，４１０から接続仲介装置５００に対して、内部端末装置６００Ａの端末ＩＤ「０１１０」を含む接続仲介依頼Ｓ２，Ｓ１２がなされる。
この接続仲介依頼Ｓ２，Ｓ１２に基づく仲介処理により、外部端末装置６００Ｂの通信元セッション確立部２６０，４３０と、内部端末装置６００Ａの通信先セッション確立部２３０，４６０との間で、通信Ｓ７，Ｓ１７が開始されることは、既に述べたとおりである。
この通信Ｓ７，Ｓ１７では、図２３に示すような通信データＱ１０が送信される。この通信データＱ１０は、外部端末装置６００Ｂの通信元セッション確立部２６０，４３０によって作成される。そのためには、図示するようなＩＰヘッダ部Ｑ１１とＩＰデータ部Ｑ１２とを作成すればよい。ここで、ＩＰヘッダ部Ｑ１１は、外部端末装置６００ＢのＩＰアドレス「ＡＤ１２」を送信元アドレスＱ１１１として含み、内部端末装置６００ＡのＩＰアドレス「ＡＤ１１」を送信先アドレスＱ１１２として含むデータとして作成すればよい。また、ＩＰデータ部Ｑ１２は、上記エアコン７０２用の遠隔操作プログラムから通知されたＩｏＴ機器宛データＱ１２２（エアコン７０２に対する動作指示データ）と機器特定情報Ｑ１２１（エアコン７０２についてのメーカ名、製品型番、製品番号）とを含むデータとして作成すればよい。
結局、図２３に示す通信データＱ１０は、ＩｏＴ機器宛データＱ１２２をＩＰパケット内にカプセル化する処理を行うことにより作成される。こうして作成されたＩＰパケットは、ＩＰヘッダ部Ｑ１１内の送信先アドレスＱ１１２（内部端末装置６００Ａの所在アドレス）に向けて送信されることになる。ＩｏＴ機器宛データＱ１２２は、カプセル化されて通信データＱ１０内に組み込まれるため、ＩｏＴ機器宛データＱ１２２がどのような構造のデータであっても、通信データＱ１０自身はＩＰパケットとして振る舞うことになり、このＩＰパケットの状態のまま、内部端末装置６００Ａに届くことになる。
もちろん、ＩｏＴ機器宛データＱ１２２自身がＩＰパケットを構成しているケースもありうる（ＩｏＴ機器がＩＰパケットの形式で動作指示を要求している場合など）。この場合、ＩｏＴ機器宛データＱ１２２を構成するＩＰパケットが、通信データを構成するＩＰパケット内にカプセル化されることになる。前者が、ゲートウェイ装置ＧＷを送信元、ＩｏＴ機器（エアコン７０２）を送信先とするＩＰパケットであるのに対して、後者は、外部端末装置６００Ｂを送信元、内部端末装置６００Ａを送信先とするＩＰパケットになる。
このような通信データＱ１０が内部端末装置６００Ａに届いたら、ゲートウェイ装置ＧＷによって、ＩＰデータ部Ｑ１２から、機器特定情報Ｑ１２１とＩｏＴ機器宛データＱ１２２とが抽出される。このＩｏＴ機器宛データＱ１２２は、特定のＩｏＴ機器（ここに示す例の場合は、エアコン７０２）に対する動作指示データであるので、当該特定のＩｏＴ機器に対して直接送信することができる。ゲートウェイ装置ＧＷは、図２４に例示するＩｏＴ機器登録テーブルＴＴを参照することにより、抽出した機器特定情報Ｑ１２１によって特定されるＩｏＴ機器（エアコン７０２）についてのアクセス方法情報を認識し、当該アクセス方法情報に従って当該ＩｏＴ機器をアクセスして、ＩｏＴ機器宛データＱ１２２を送信する。図示の例の場合、ＷｉＦｉによって、固有アドレスＡＤ７０２で示されるエアコン７０２に対して、ＩｏＴ機器宛データＱ１２２が送信されることになる。
以上、外部端末装置６００Ｂ（スマートフォン）によってエアコン７０２を遠隔制御する際に用いる通信データＱ１０の具体的な構造と、ゲートウェイ装置ＧＷによるＩｏＴ機器宛データＱ１２２の配信方法を説明したが、外部端末装置６００Ｃ（パソコン）によってエアコン７０２を遠隔制御する際も全く同様である。また、外部端末装置６００Ｄ（アップデートサーバ）は、エアコン７０２等のＩｏＴ機器を遠隔制御するための動作指示を送信するわけではなく、ＩｏＴ機器に組み込まれたファームウェアをアップデートするアップデータを送信する役割を果たすことになるので、外部端末装置６００Ｄから内部端末装置６００Ａ宛への通信データＱ１０にカプセル化されるＩｏＴ機器宛データは、アップデータもしくはアップデート用プログラムということになる。
＜７．２暗号化した通信データの構造＞
ここでは、インターネットを介した通信のセキュリティを更に向上させるために、通信データを暗号化する変形例を述べる。前述したとおり、図２３に示す通信データＱ１０は、インターネットを介して外部端末装置６００Ｂから内部端末装置６００Ａに送信されることになるが、送信途中においてクラッカーの手元に渡ると、ハッキングの準備材料として利用される可能性がある。特に、ＩｏＴ機器宛データは、宛先となるＩｏＴ機器に与える動作指示データやアップデータであるので、クラッカーによる解析が行われることは、セキュリティ上の脅威となる。ここで述べる変形例は、ＩｏＴ機器宛データを暗号化することにより、通信のセキュリティをより向上させるものである。
ここでは、インターネットを介した通信のセキュリティを更に向上させるために、通信データを暗号化する変形例を述べる。前述したとおり、図２３に示す通信データＱ１０は、インターネットを介して外部端末装置６００Ｂから内部端末装置６００Ａに送信されることになるが、送信途中においてクラッカーの手元に渡ると、ハッキングの準備材料として利用される可能性がある。特に、ＩｏＴ機器宛データは、宛先となるＩｏＴ機器に与える動作指示データやアップデータであるので、クラッカーによる解析が行われることは、セキュリティ上の脅威となる。ここで述べる変形例は、ＩｏＴ機器宛データを暗号化することにより、通信のセキュリティをより向上させるものである。
図２５は、図２２に示すネットワーク通信システムにおいて、外部端末装置６００Ｂ～６００Ｄと内部端末装置６００Ａとの間の通信を暗号化する基本原理を示すブロック図である。図の上段は、外部端末装置６００Ｂ～６００Ｄ側で行う暗号化処理を示し、図の下段は、ゲートウェイ装置ＧＷ側で行う復号処理を示している。ここで行う暗号化処理および復号処理の特徴は、暗号鍵および復号鍵として、宛先のＩｏＴ機器に格納されているユニークなデータＵを用いる点である。
たとえば、図２２に示す実施例において、外部端末装置６００Ｂからエアコン７０２に対してＩｏＴ機器宛データＱ１２２（エアコンに対する動作指示データ）を送信する場合、まず、外部端末装置６００Ｂにおいて、図２５の上段に示すように、ＩｏＴ機器宛データＱ１２２に対して、エアコン７０２に格納されているユニークなデータＵを暗号鍵として用いた暗号化処理を実行し、ＩｏＴ機器宛暗号データＱ１２２Ｃを作成する。そして、このＩｏＴ機器宛暗号データＱ１２２Ｃを内部端末装置６００Ａ（ゲートウェイ装置ＧＷ）に送信すればよい。
一方、ＩｏＴ機器宛暗号データＱ１２２Ｃを受信したゲートウェイ装置ＧＷでは、図２５の下段に示すように、ＩｏＴ機器宛暗号データＱ１２２Ｃに対して、エアコン７０２に格納されているユニークな上記データＵを復号鍵として用いた復号処理を実行し、ＩｏＴ機器宛データＱ１２２を復元すればよい。こうして復元されたＩｏＴ機器宛データＱ１２２は、これまで述べてきた基本的な実施形態と同様の方法で、ゲートウェイ装置ＧＷからエアコン７０２へと配信される。
図２６は、図２５に示す基本原理に基づいて、外部端末装置６００Ｂから内部端末装置６００Ａ宛に送信する暗号化通信データＱ２０の基本的な構成例を示す図である。この図２６に示す暗号化通信データＱ１０Ｃは、図２３に示す通信データＱ１０と同様に、ＩＰプロトコルに従ったデータ構造を有するＩＰパケットの形態をとっており、ＩＰヘッダ部Ｑ１１とＩＰデータ部Ｑ１２Ｃとによって構成される。ここで、ＩＰヘッダ部Ｑ１１には、送信元アドレスＱ１１１（この例の場合、外部端末装置６００Ｂの所在アドレス「ＡＤ１２」）と、送信先アドレスＱ１１２（この例の場合、内部端末装置６００Ａの所在アドレス「ＡＤ１１」）とが含まれる。この点は、図２３に示す通信データＱ１０と同様である。
一方、図２６に示す暗号化通信データＱ１０ＣのＩＰデータ部Ｑ１２Ｃには、ＩｏＴ機器を特定する機器特定情報Ｑ１２１と、このＩｏＴ機器に送信すべきＩｏＴ機器宛暗号データＱ１２２Ｃとが含まれている。結局、図２３に示す通信データＱ１０と図２６に示す暗号化通信データＱ１０Ｃとの相違は、前者のＩＰデータ部Ｑ１２にはＩｏＴ機器宛データＱ１２２が含まれていたのに対し、後者のＩＰデータ部Ｑ１２Ｃには、ＩｏＴ機器宛暗号データＱ１２２Ｃが含まれている点だけである。要するに、図２６に示す暗号化通信データＱ１０Ｃでは、ＩｏＴ機器宛暗号データＱ１２２ＣがＩＰパケット内にカプセル化されていることになる。
前述したとおり、このＩｏＴ機器宛暗号データＱ１２２Ｃは、ＩｏＴ機器宛データＱ１２２に対して、宛先のＩｏＴ機器に格納されているユニークなデータＵを暗号鍵として用いた暗号化処理により作成されたものであり、この暗号化通信データＱ１０Ｃが内部端末装置６００Ａに届いた後は、ゲートウェイ装置ＧＷによる復号処理を経て、もとのＩｏＴ機器宛データＱ１２２に復元される。復号処理には、暗号化処理時に暗号鍵として用いた同じデータＵが、復号鍵として用いられることになる。
ここで、暗号鍵および復号鍵として用いられるデータＵは、宛先となるＩｏＴ機器に格納されているユニークなデータであれば、どのようなデータでもかまわないが、外部端末装置６００Ｂで行われる暗号化処理およびゲートウェイ装置ＧＷで行われる復号処理に利用されるため、外部端末装置６００Ｂおよびゲートウェイ装置ＧＷが利用可能なデータとなっている必要がある。
具体的には、たとえば、ＩｏＴ機器のＣＰＵシリアル番号やＭＡＣアドレスを、ユニークなデータＵとして利用することができるが、当該データＵは、外部端末装置６００Ｂおよびゲートウェイ装置ＧＷの双方から利用できるようにしておく必要がある。外部端末装置６００Ｂから利用可能とするためには、外部端末装置６００Ｂ内に機器特定情報Ｑ１２１を登録する際に、ユニークなデータＵも併せて登録しておくようにすればよい。また、ゲートウェイ装置ＧＷから利用可能とするためには、たとえば、図２４に示すＩｏＴ機器登録テーブルＴＴに、機器特定情報Ｑ１２１およびアクセス方法情報ともに、ユニークなデータＵも登録しておくようにすればよい。ゲートウェイ装置ＧＷが復号処理を行う際には、暗号化通信データＱ１０ＣのＩＰデータ部Ｑ１２Ｃに含まれている機器特定情報Ｑ１２１により、復号鍵として用いるデータＵを特定することができる。
このように、宛先となるＩｏＴ機器に格納されているユニークなデータＵを暗号鍵および復号鍵として用いると、暗号化により得られるセキュリティ上のメリットの他、正しい相手先に到達したことを確認できるという副次的なメリットも得られる。たとえば、上述した例の場合、暗号化通信データＱ１０Ｃは、外部端末装置６００Ｂから内部端末装置６００Ａ宛に送信されることになるので、正しい相手先は内部端末装置６００Ａということになる。ところが、何らかの事情で、誤った相手先である内部端末装置６００Ｅ（別なゲートウェイ装置に組み込まれている端末装置）に送信されてしまった場合、内部端末装置６００Ｅは、受信した暗号化通信データＱ１０Ｃが誤送信されたものであることを認識することができる。
これは、内部端末装置６００Ｅには、正しい復号鍵が格納されていないので、誤送信された暗号化通信データＱ１０Ｃを正しい状態に復号することができないためである。別言すれば、正しい相手先である内部端末装置６００Ａは、受信した暗号化通信データＱ１０Ｃに含まれている暗号化通信データＱ１０Ｃを正しく復号できたことをもって、受信した暗号化通信データＱ１０Ｃが、自分自身を宛先とする通信データであることを確認することができる。
なお、暗号鍵および復号鍵として用いるデータは、必ずしも宛先となるＩｏＴ機器に格納されているユニークなデータＵそれ自身である必要はなく、当該データＵから一義的に求められる派生データであってもかまわない。たとえば、ＩｏＴ機器のＣＰＵシリアル番号やＭＡＣアドレスを、ユニークなデータＵとして利用する場合、暗号鍵および復号鍵は、これらＣＰＵシリアル番号やＭＡＣアドレス自身である必要はなく、たとえばそのハッシュ値など、これらＣＰＵシリアル番号やＭＡＣアドレスに基づいて一義的に求められる派生データであってもよい。
要するに、図２５に示す基本原理に基づいて暗号化通信データＱ１０Ｃを送信する変形例を実施するのであれば外部端末装置６００Ｂの通信元セッション確立部２６０，４３０が、内部端末装置６００Ａの通信先セッション確立部２３０，４６０に対して通信Ｓ７，Ｓ１７を行う際に、次のような処理を行えばよい。
まず、外部端末装置６００Ｂの通信元セッション確立部２６０，４３０は、宛先となる特定のＩｏＴ機器７０２に所定のＩｏＴ機器宛データＱ１２２を送信する場合、当該ＩｏＴ機器宛データＱ１２２に対して、当該特定のＩｏＴ機器７０２に格納されているユニークなデータＵもしくは当該データＵから一義的に求められる派生データを暗号鍵として用いた暗号化処理を施すことにより、ＩｏＴ機器宛暗号データＱ１２２Ｃを作成する。そして、作成したＩｏＴ機器宛暗号データＱ１２２Ｃと当該特定のＩｏＴ機器７０２を特定するための機器特定情報Ｑ１２１とが含まれた暗号化通信データＱ１０Ｃ（図２６参照）を、内部端末装置６００Ａに対して送信すればよい。
一方、内部端末装置６００Ａを含むゲートウェイ装置ＧＷは、暗号化通信データＱ１０Ｃを受信したときに、この暗号化通信データＱ１０Ｃから、機器特定情報Ｑ１２１およびＩｏＴ機器宛暗号データＱ１２２Ｃを抽出する。そして、抽出した機器特定情報Ｑ１２１で特定されるＩｏＴ機器７０２に格納されているユニークなデータＵもしくは当該データＵから一義的に求められる派生データを復号鍵として用いた復号処理を施すことによりＩｏＴ機器宛データＱ１２２を復元する。そして、復元されたＩｏＴ機器宛データＱ１２２を、抽出した機器特定情報Ｑ１２１によって特定されるＩｏＴ機器７０２に配信すればよい。
＜＜＜§８．有効ポートの制限＞＞＞
ここでは、§６で述べた本発明の基本的な実施形態の変形例として、内部端末装置６００Ａについての有効ポートを制限することにより、セキュリティを更に向上させる方法を説明する。
ここでは、§６で述べた本発明の基本的な実施形態の変形例として、内部端末装置６００Ａについての有効ポートを制限することにより、セキュリティを更に向上させる方法を説明する。
図１５には、端末装置２００Ｅ，２００Ｆ，２００Ｇを、ルータＲを介してネットワークＮに接続した実施例が示されている。このように、本発明に用いる端末装置に対しては、ルータＲの有無にかかわらず、ＩＰアドレスにポート番号を付加してアクセスすることが可能である。通常、端末装置に付与されたポート番号は、当該端末装置内で動作するアプリケーションプログラムを区別するために利用され、受信したデータは、指定されたポート番号に対応するアプリケーションプログラムに引き渡される。
ここで述べる本発明の変形例は、図２２に示す基本的な実施形態における内部端末装置６００Ａに対して、ＩＰアドレスにポート番号を付加してアクセスする運用を採りつつ、有効なポートを制限することにより、セキュリティの更なる向上を図るものである。既に§６で述べたとおり、本発明における内部端末装置６００Ａは、専ら、ゲートウェイ装置ＧＷの一構成要素として機能するものであり、その役割は、ゲートウェイ装置ＧＷの下流側に接続された各ＩｏＴ機器７０１～７０５を、上流側のインターネットＮに接続することにある。このため、内部端末装置６００Ａが受信した通信データＱ１０もしくは暗号化通信データＱ１０Ｃは、常に、ゲートウェイ装置ＧＷ内に組み込まれた専用のアプリケーションプログラムに引き渡される。
したがって、内部端末装置６００Ａを上流側からアクセスする際に、ＩＰアドレスにポート番号を付加してアクセスする運用を採る場合、当該ポート番号は、ゲートウェイ装置ＧＷとしての機能を果たす専用のアプリケーションプログラムを示す番号ということになる。そこで、ここで述べる変形例では、内部端末装置６００Ａが、特定のポートを有効ポートに設定し、所定の周期で、もしくは、有効ポートの設定に変更があったときに、現時点の有効ポートを接続仲介装置５００に対して通知し、ネットワークＮを介して送信されてきたＩＰパケットのうち、有効ポートに対応するポート番号が指定されているものだけを受信し、それ以外のＩＰパケットを拒絶する処理を行うようにする。
ある時点での有効ポートは、複数設定するようにしてもかまわないが、実用上は、常に、１つのポートのみを有効ポートとして設定するようにするのが好ましい。上述したとおり、内部端末装置６００Ａが受信したデータは、すべてゲートウェイ装置ＧＷとしての機能を果たす単一のアプリケーションプログラムに引き渡すようにすれば足りるので、当該単一のアプリケーションプログラムに対応する１つのポートのみを有効ポートとして設定すれば十分である。有効ポートの番号は、必要に応じて、適宜変更するようにしてもかまわない。たとえば、ある時点では、ポート番号Ｐ１３で示されるポートを有効ポートに設定するが、次の時点では、ポート番号Ｐ１４で示されるポートを有効ポートに設定する、という運用を行うことができる。
現時点での有効ポートは、所定の周期で、もしくは、有効ポートの設定に変更があったときに、内部端末装置６００Ａから接続仲介装置５００に対して通知される。接続仲介装置５００は、この通知を受けて、アドレステーブルＴに有効ポートのポート番号を記録するようにする。所在アドレスとして、ＩＰアドレスとともにポート番号を記録したアドレステーブルは、たとえば、図１６に例示したアドレステーブルＴ４１，Ｔ４２のような形態になる。
接続仲介装置５００は、外部端末装置６００Ｂ～６００Ｄから内部端末装置６００Ａを通信先とする接続仲介依頼を受けたとき、通信先もしくは通信元アドレスとして、有効ポートのポート番号を含むアドレスを用いた仲介処理を行う。すなわち、通信先もしくは通信元アドレスとして、内部端末装置６００ＡのＩＰアドレスとともに有効ポートのポート番号を知らせる。したがって、外部端末装置６００Ｂ～６００Ｄは、ＩＰアドレスと有効ポートのポート番号とを用いて、内部端末装置６００Ａにアクセスを行うことになる。具体的には、ＩＰアドレスとポート番号を指定したＩＰパケットを送信することになる。
内部端末装置６００Ａは、ネットワークＮを介してＩＰパケットが送信されてきた場合、当該ＩＰパケットが、有効ポートに対応するポート番号を指定するものであった場合にはこれを受信し、それ以外のポート番号を指定するものであった場合にはこれを拒絶する処理を行う。このように、内部端末装置６００Ａにおいて有効ポートの制限を行うようにすれば、接続仲介装置５００から通知された正しい有効ポートのポート番号を指定したＩＰパケット以外は拒絶されるため、不正な端末装置から送信されてきたＩＰパケットが届くことを防止することができる。特に、単一のポートのみを有効ポートに設定するようにすれば、不正な端末装置からのＩＰパケットが届くことを効果的に排除することができる。
＜＜＜§９．ＩｏＴ機器から外部端末装置宛の送信＞＞＞
これまで、図２２に示す本発明の基本的な実施形態に係るネットワーク通信システムについて、任意の外部端末装置６００Ｂ～６００Ｄから家庭Ｈ内の任意のＩｏＴ機器７０１～７０５宛にＩｏＴ機器宛データＱ１２２を送信する手順を述べてきたが、もちろん、任意のＩｏＴ機器７０１～７０５（以下、送信源と呼ぶ）から任意の外部端末装置６００Ｂ～６００Ｄ宛にデータ（以下、端末装置宛データＱ２２２と呼ぶ）を送信することも可能である。
これまで、図２２に示す本発明の基本的な実施形態に係るネットワーク通信システムについて、任意の外部端末装置６００Ｂ～６００Ｄから家庭Ｈ内の任意のＩｏＴ機器７０１～７０５宛にＩｏＴ機器宛データＱ１２２を送信する手順を述べてきたが、もちろん、任意のＩｏＴ機器７０１～７０５（以下、送信源と呼ぶ）から任意の外部端末装置６００Ｂ～６００Ｄ宛にデータ（以下、端末装置宛データＱ２２２と呼ぶ）を送信することも可能である。
以下、家庭Ｈ内の特定のＩｏＴ機器が、特定の外部端末装置に対して通信を行う際の手順を説明する。ここでは、具体的に、ＩｏＴ機器７０２（エアコン）が外部端末装置６００Ｂ（スマートフォン）に、所定の端末装置宛データＱ２２２（たとえば、エアコン周囲の現在の温度を通知するデータ）を送信する場合を考えてみよう。
この場合、まず、ＩｏＴ機器７０２が、内部端末装置６００Ａの通信要求受付部（図４の２２０Ａもしくは図８の４２０Ｂに対応）に対して、送信先となる外部端末装置６００Ｂを特定するための端末装置特定情報Ｑ２２０と、自分自身（ＩｏＴ機器７０２）を特定する機器特定情報Ｑ２２１と、外部端末装置６００Ｂに対して送信すべき端末装置宛データＱ２２２と、を通信要求Ｓ１，Ｓ１１として送信する。ここで、端末装置特定情報Ｑ２２０としては、たとえば、外部端末装置６００Ｂの端末ＩＤ「０１２０」を用いればよい。また、自分自身を特定する機器特定情報Ｑ２２１としては、たとえば、図２４に示すＩｏＴ機器登録テーブルＴＴに登録されている機器特定情報Ｑ１２１（メーカ名，製品型番，製品番号）を用いればよい。
内部端末装置６００Ａの通信要求受付部が、この通信要求Ｓ１，Ｓ１１を受け付けたら、続いて、内部端末装置６００Ａの接続仲介依頼部（図４の２１０Ａもしくは図８の４１０Ｂに対応）が、端末装置特定情報Ｑ２２０で特定される外部端末装置６００Ｂを通信先とする通信先特定情報（外部端末装置６００Ｂの端末ＩＤ「０１２０」）を含む接続仲介依頼Ｓ２，Ｓ１２を接続仲介装置５００に対して送信する。端末装置特定情報Ｑ２２０として、外部端末装置６００Ｂの端末ＩＤ「０１２０」を用いていた場合は、これをそのまま通信先特定情報として用いればよい。
ここで、このネットワーク通信システムが、図４に示す先願基本発明の第１の実施形態を利用して構築されている場合、接続仲介装置５００は、接続仲介依頼Ｓ２に応じて、内部端末装置６００Ａの通信開始要求部（図４の２４０Ａに相当）に対して、通信先アドレス「ＡＤ１２」を返信する。そこで、内部端末装置６００Ａの通信開始要求部が、返信されてきた通信先アドレス「ＡＤ１２」にアクセスして通信開始要求Ｓ５を行うと、外部端末装置６００Ｂの通信先セッション確立部（図４の２３０Ｂに相当）から通信開始受諾確認Ｓ６が送信されてくる。こうして、内部端末装置６００Ａの通信元セッション確立部（図４の２６０Ａに相当）と、外部端末装置６００Ｂの通信先セッション確立部（図４の２３０Ｂに相当）との間で、通信Ｓ７が開始される。
一方、このネットワーク通信システムが、図８に示す先願基本発明の第２の実施形態を利用して構築されている場合、接続仲介装置５００は、接続仲介依頼Ｓ１２に応じて、外部端末装置６００Ｂの通信開始要求部（図８の４４０Ａに相当）に対して、通信元アドレス「ＡＤ１１」を返信する。そこで、外部端末装置６００Ｂの通信開始要求部が、送信されてきた通信元アドレス「ＡＤ１１」にアクセスして通信開始要求Ｓ１５を行うと、内部端末装置６００Ａの通信元セッション確立部（図８の４３０Ｂに相当）から通信開始受諾確認Ｓ１６が送信されてくる。こうして、内部端末装置６００Ａの通信元セッション確立部（図８の４３０Ｂに相当）と、外部端末装置６００Ｂの通信先セッション確立部（図８の４６０Ａに相当）との間で、通信Ｓ１７が開始される。
こうして、両者間での通信セッションが確立して、両者間で通信Ｓ７もしくは通信Ｓ１７を行う際に、内部端末装置６００Ａから外部端末装置６００Ｂに対して、機器特定情報Ｑ２２１と端末装置宛データＱ２２２とが含まれた通信データＱ２０を送信すればよい。
通信データＱ２０の形態としては、やはりＩＰプロトコルに従ったデータ構造を有するＩＰパケットの形態を採用するのが好ましい。図２７は、ＩＰパケットの形態をもつ通信データＱ２０の構成例を示す図である。実用上は、このＩＰパケットからなる通信データＱ２０を、ＵＤＩやＴＣＰといったトランスポート層上のプロトコルに基づいて送信すればよい。
図２７に示す通信データＱ２０（ＩＰパケット）のデータ構造は、図２３に示す通信データＱ１０（ＩＰパケット）のデータ構造とほぼ同じである。すなわち、通信データＱ２０は、ＩＰヘッダ部Ｑ２１とＩＰデータ部Ｑ２２とによって構成される。ＩＰヘッダ部Ｑ２１には、送信元アドレスＱ２１１と送信先アドレスＱ２１２とが含まれ、このＩＰパケットは、送信元アドレスＱ２１１（所在アドレス「ＡＤ１１」）で示される内部端末装置６００Ａから、送信先アドレスＱ２１２（所在アドレス「ＡＤ１２」）で示される外部端末装置６００Ｂに向けて送信される。
ここで、送信先アドレスＱ２１２となる外部端末装置６００Ｂの所在アドレス「ＡＤ１２」は、ＩｏＴ機器７０２（エアコン）から送信されてきた端末装置特定情報Ｑ２２０（端末ＩＤ「０１２０」）を用いて接続仲介装置５００に対して行った接続仲介依頼によって得られたものである。
一方、ＩＰデータ部Ｑ２２には、もともとの送信源であるＩｏＴ機器７０２を特定する機器特定情報Ｑ２２１と、外部端末装置６００Ｂに対して送信すべき端末装置宛データＱ２２２（たとえば、エアコン周囲の現在の温度を通知するデータ）とが含まれている。これらの情報は、いずれもＩｏＴ機器７０２で作成され、内部端末装置６００Ａに送信されてきたものである。内部端末装置６００Ａは、これらの情報に基づいて、通信データＱ２０を作成することになる。
要するに、内部端末装置６００Ａは、自分自身のＩＰアドレスを送信元アドレスＱ２１１として含み、外部端末装置６００ＢのＩＰアドレスを送信先アドレスＱ２１２として含むＩＰヘッダ部Ｑ２１と、端末装置宛データＱ２２２と機器特定情報Ｑ２２１とを含むＩＰデータ部Ｑ２２と、を有するＩＰパケットＱ２０を作成することにより、端末装置宛データＱ２２２をＩＰパケットＱ２０内にカプセル化する処理を行い、このＩＰパケットを通信データＱ２０として、外部端末装置６００Ｂ宛に送信する処理を行う。
このような通信データＱ２０が外部端末装置６００Ｂに届くと、外部端末装置６００Ｂにおいて、ＩＰデータ部Ｑ２２から機器特定情報Ｑ２２１と端末装置宛データＱ２２２とが抽出される。送信元アドレスＱ２１１には、内部端末装置６００Ａの所在アドレスが含まれているため、端末装置宛データＱ２２２が内部端末装置６００Ａから送信されてきたことは確認できる。しかしながら、送信元アドレスＱ２１１には、もともとの送信源がどのＩｏＴ機器であるのかを示す情報は含まれていない。そこで、外部端末装置６００Ｂは、抽出した機器特定情報Ｑ２２１を参照することにより、端末装置宛データＱ２２２のもともとの送信源が、ＩｏＴ機器７０２（エアコン）であることを確認することができる。
かくして、端末装置宛データＱ２２２は、外部端末装置６００Ｂ内にインストールされているＩｏＴ機器７０２（エアコン）用の専用アプリケーションプログラムに引き渡され、所定の処理が実行される。たとえば、端末装置宛データＱ２２２が、エアコン周囲の現在の温度を通知するデータであった場合、専用アプリケーションプログラムによって、外部端末装置６００Ｂ（スマートフォン）のディスプレイ画面に、温度が通知された旨の表示が行われる。
以上、ＩｏＴ機器７０２（エアコン）から外部端末装置６００Ｂ（スマートフォン）宛に情報を送信する例を述べたが、任意のＩｏＴ機器から任意の外部端末装置に情報を送信する場合も全く同様である。たとえば、外部端末装置６００Ｄは、ＩｏＴ機器に対してアップデータを提供する役割を果たすアップデートサーバであるが、アップデータをPush型の配信で提供する場合は、外部端末装置６００ＤからＩｏＴ機器への送信が行われるだけで足りる。一方、アップデータをPull型の配信で提供する場合は、まず、ＩｏＴ機器から外部端末装置６００Ｄへ、アップデータの要求を行う必要があるので、このアップデータ要求を端末装置宛データＱ２２２として、上述した手順で外部端末装置６００Ｄへ送信することになる。
なお、§７．２では、図２５に示す原理に基づいて、図２３に示す通信データＱ１０の代わりに、図２６に示す暗号化通信データＱ１０Ｃを送信する変形例を述べた。この暗号化の手法は、ＩｏＴ機器から外部端末装置宛に送信する通信データＱ２０についても同様に適用可能である。
図２８は、このような暗号化の手法を適用して、特定のＩｏＴ機器から特定の外部端末装置宛に情報を送信する際に用いる暗号化通信データの構成例を示す図である。この図２８に示す暗号化通信データＱ２０Ｃは、図２７に示す通信データＱ２０と同様に、ＩＰプロトコルに従ったデータ構造を有するＩＰパケットの形態をとっており、ＩＰヘッダ部Ｑ２１とＩＰデータ部Ｑ２２Ｃとによって構成される。ここで、ＩＰヘッダ部Ｑ２１には、送信元アドレスＱ２１１（上例の場合、内部端末装置６００Ａの所在アドレス「ＡＤ１１」）と、送信先アドレスＱ２１２（上例の場合、外部端末装置６００Ｂの所在アドレス「ＡＤ１２」）とが含まれる。この点は、図２７に示す通信データＱ２０と同様である。
一方、図２８に示す暗号化通信データＱ２０ＣのＩＰデータ部Ｑ２２Ｃには、ＩｏＴ機器を特定する機器特定情報Ｑ２２１と、外部端末装置に送信すべき端末装置宛暗号データＱ２２２Ｃとが含まれている。結局、図２７に示す通信データＱ２０と図２８に示す暗号化通信データＱ２０Ｃとの相違は、前者のＩＰデータ部Ｑ２２には端末装置宛データＱ２２２が含まれていたのに対し、後者のＩＰデータ部Ｑ２２Ｃには、端末装置宛暗号データＱ２２２Ｃが含まれている点だけである。要するに、図２８に示す暗号化通信データＱ２０Ｃでは、端末装置宛暗号データＱ２２２ＣがＩＰパケット内にカプセル化されていることになる。
この端末装置宛暗号データＱ２２２Ｃは、端末装置宛データＱ２２２に対して、もともとの送信源であるＩｏＴ機器に格納されているユニークなデータＵを暗号鍵として用いた暗号化処理を施したものであり、ゲートウェイ装置ＧＷで作成されることになる。この端末装置宛暗号データＱ２２２Ｃが外部端末装置６００Ｂに届いた後は、当該外部端末装置６００Ｂにおける復号処理を経て、もとの端末装置宛データＱ２２２に復元される。復号処理には、暗号化処理時に暗号鍵として用いた同じデータＵが、復号鍵として用いられることになる。
ここで、暗号鍵および復号鍵として用いられるデータＵは、送信源となるＩｏＴ機器に格納されているユニークなデータであれば、どのようなデータでもかまわないが、ゲートウェイ装置ＧＷで行われる暗号化処理および外部端末装置６００Ｂで行われる復号処理に利用されるため、ゲートウェイ装置ＧＷおよび外部端末装置６００Ｂが利用可能なデータとなっている必要がある。
具体的には、たとえば、ＩｏＴ機器のＣＰＵシリアル番号やＭＡＣアドレスを、ユニークなデータＵとして利用することができるが、当該データＵは、外部端末装置６００Ｂおよびゲートウェイ装置ＧＷの双方から利用できるようにしておく必要がある。そうするための具体的な方法は、§７．２で述べたとおりである。また、暗号鍵および復号鍵として用いるデータは、必ずしも送信源となるＩｏＴ機器に格納されているユニークなデータＵそれ自身である必要はなく、当該データＵから一義的に求められる派生データであってもかまわない。この点も、既に§７．２で説明したとおりである。
結局、ＩｏＴ機器７０２から外部端末装置６００Ｂ宛の送信を暗号化して行う変形例を実施するのであれば、内部端末装置６００Ａの通信元セッション確立部２６０，４３０が、外部端末装置６００Ｂの通信先セッション確立部２３０，４６０に対して通信Ｓ７，Ｓ１７を行う際に、次のような処理を行えばよい。
まず、内部端末装置６００Ａを含むゲートウェイ装置ＧＷは、端末装置宛データＱ２２２に対して、その送信源となるＩｏＴ機器７０２に格納されているユニークなデータＵもしくは当該データＵから一義的に求められる派生データを暗号鍵として用いた暗号化処理を施すことにより、端末装置宛暗号データＱ２２２Ｃを作成する。そして、作成した端末装置宛暗号データＱ２２２Ｃと機器特定情報Ｑ２２１とが含まれた暗号化通信データＱ２０Ｃ（図２８参照）を、外部端末装置６００Ｂに対して送信すればよい。
より具体的には、ゲートウェイ装置ＧＷは、内部端末装置６００ＡのＩＰアドレスを送信元アドレスＱ２１１として含み、外部端末装置６００ＢのＩＰアドレスを送信先アドレスＱ２１２として含むＩＰヘッダ部Ｑ２１と、端末装置宛暗号データＱ２２２Ｃと機器特定情報Ｑ２２１とを含むＩＰデータ部Ｑ２２Ｃと、を有するＩＰパケットＱ２０Ｃを作成することにより、端末装置宛暗号データＱ２２２ＣをＩＰパケットＱ２０Ｃ内にカプセル化する処理を行い、このＩＰパケットを暗号化通信データＱ２０Ｃとして、外部端末装置６００Ｂに対して送信すればよい。
一方、外部端末装置６００Ｂは、暗号化通信データＱ２０Ｃを受信したときに、この暗号化通信データＱ２０Ｃから、機器特定情報Ｑ２２１および端末装置宛暗号データＱ２２２Ｃを抽出する。そして、抽出した端末装置宛暗号データＱ２２２Ｃに対して、抽出した機器特定情報Ｑ２２１で特定されるＩｏＴ機器７０２に格納されているユニークなデータＵもしくは当該データＵから一義的に求められる派生データを復号鍵として用いた復号処理を施すことにより端末装置宛データＱ２２２を復元すればよい。
＜＜＜§１０．本発明におけるゲートウェイ装置の具体的構成＞＞＞
§６で述べたように、図２２に示すゲートウェイ装置ＧＷは、内部端末装置６００Ａを含み、ＩｏＴ機器登録テーブルＴＴを参照して、受信したＩｏＴ機器宛データＱ１２２を、宛先となるＩｏＴ機器に配信する処理を行う。ここでは、このゲートウェイ装置ＧＷのより具体的な構成例を説明する。なお、以下に説明するゲートウェイ装置ＧＷ，ＧＷ′は、いずれもコンピュータに専用のプログラムを組み込むことによって構成することができる。
§６で述べたように、図２２に示すゲートウェイ装置ＧＷは、内部端末装置６００Ａを含み、ＩｏＴ機器登録テーブルＴＴを参照して、受信したＩｏＴ機器宛データＱ１２２を、宛先となるＩｏＴ機器に配信する処理を行う。ここでは、このゲートウェイ装置ＧＷのより具体的な構成例を説明する。なお、以下に説明するゲートウェイ装置ＧＷ，ＧＷ′は、いずれもコンピュータに専用のプログラムを組み込むことによって構成することができる。
＜１０．１基本的なゲートウェイ装置の構成例＞
図２９は、図２２に示すゲートウェイ装置ＧＷの具体的構成例を示すブロック図である。図示のとおり、このゲートウェイ装置ＧＷは、内部端末装置６００Ａと、内部端末用仲介部６１０と、下流側に接続されたＮ台（Ｎは自然数：図示の例は、図２２に示すように、Ｎ＝５の例）のＩｏＴ機器７０１～７０５に１対１に対応するＮ台の個別通信部６１１～６１５と、を有している。
図２９は、図２２に示すゲートウェイ装置ＧＷの具体的構成例を示すブロック図である。図示のとおり、このゲートウェイ装置ＧＷは、内部端末装置６００Ａと、内部端末用仲介部６１０と、下流側に接続されたＮ台（Ｎは自然数：図示の例は、図２２に示すように、Ｎ＝５の例）のＩｏＴ機器７０１～７０５に１対１に対応するＮ台の個別通信部６１１～６１５と、を有している。
個別通信部６１１～６１５は、それぞれ対応するＩｏＴ機器７０１～７０５との間で、所定の通信規格に基づいて相互通信する機能を有している。たとえば、個別通信部６１１は、ＩｏＴ機器７０１（監視カメラ）と相互通信するための専用の構成要素であり、個別通信部６１２は、ＩｏＴ機器７０２（エアコン）と相互通信するための専用の構成要素である。もっとも、これらＮ台個別通信部６１１～６１５は、必ずしもそれぞれ独立したハードウェアをもった個別の装置である必要はなく、複数の個別通信部が同一のハードウェア装置を共有し、ソフトウェア的にそれぞれ別個の構成要素として機能するようにしてもよい。
たとえば、図２４に示すＩｏＴ機器登録テーブルＴＴの例の場合、ＩｏＴ機器７０１（監視カメラ）もＩｏＴ機器７０２（エアコン）も、通信規格は同じＷｉＦｉを用いているため、個別通信部６１１，６１２は、同一のＷｉＦｉ通信機器を用いて構成することができる。ただ、個別通信部６１１は、ＩｏＴ機器７０１（監視カメラ）の固有アドレスを用いてＩｏＴ機器７０１との間で相互通信を行うソフトウェアによって動作し、個別通信部６１２は、ＩｏＴ機器７０２（エアコン）の固有アドレスを用いてＩｏＴ機器７０２との間で相互通信を行うソフトウェアによって動作することになる。
結局、図２４に示すＩｏＴ機器登録テーブルＴＴに応じた個別通信部を用意する場合、ハードウェア的には、個別通信部６１１，６１２をＷｉＦｉ通信機器によって構成し、個別通信部６１３，６１４をイーサネット（登録商標）通信機器によって構成し、個別通信部６１５を近距離無線通信機器によって構成すればよい。一方、ソフトウェア的には、それぞれが対応するＩｏＴ機器の固有アドレス宛に通信を行うようにすればよい。
一方、内部端末用仲介部６１０には、個々のＩｏＴ機器７０１～７０５についての機器特定情報Ｑ１２１と、当該ＩｏＴ機器に対応する個別通信部６１１～６１５と、を対応づけたＩｏＴ機器登録テーブルＴＴ′が格納されている。このＩｏＴ機器登録テーブルＴＴ′の実態は、図２４に示すＩｏＴ機器登録テーブルＴＴの実態とは若干異なっている。すなわち、図２４に示すＩｏＴ機器登録テーブルＴＴには、機器特定情報Ｑ１２１（メーカ名，製品型番，製品番号）とアクセス方法情報（通信規格，固有アドレス）との対応関係が記録されているのに対して、図２９の内部端末用仲介部６１０に格納されているＩｏＴ機器登録テーブルＴＴ′には、機器特定情報Ｑ１２１（メーカ名，製品型番，製品番号）と対応する個別通信部６１１～６１５との対応関係が記録されている。別言すれば、図２４に示すＩｏＴ機器登録テーブルＴＴにおける「アクセス方法情報」の欄を、「対応する個別通信部」の欄に変更したものが、ＩｏＴ機器登録テーブルＴＴ′ということになる。
もっとも、図２４に示すＩｏＴ機器登録テーブルＴＴと、図２９の内部端末用仲介部６１０に格納されているＩｏＴ機器登録テーブルＴＴ′とは、実質的に同一の機能を果たしている。すなわち、前者は、ＩｏＴ機器の機器特定情報Ｑ１２１と、当該ＩｏＴ機器へのアクセス方法を示すアクセス方法情報と、を直接的に対応づけたテーブルであるのに対して、後者は、これらを間接的に対応づけたテーブルになっている。このように、本発明においてゲートウェイ装置ＧＷに格納されるＩｏＴ機器登録テーブルＴＴ，ＴＴ′は、下流側に接続されている個々のＩｏＴ機器７０１～７０５についての機器特定情報Ｑ１２１と、当該ＩｏＴ機器へのアクセス方法を示すアクセス方法情報と、を直接もしくは間接的に対応づけたテーブルであればよい。
たとえば、ＩｏＴ機器登録テーブルＴＴ′の場合、ＩｏＴ機器７０２（エアコン）の機器特定情報Ｑ１２１について、そのアクセス方法情報を直接的に記録する代わりに、対応する個別通信部が個別通信部６１２であることを示す情報が記録されている。しかしながら、個別通信部６１２は、ＩｏＴ機器７０２（エアコン）に対する相互通信を専用に行う構成要素であり、通信規格ＷｉＦｉを前提として、ＩｏＴ機器７０２（エアコン）の固有アドレス「ＡＤ７０２」宛に通信を行う機能を有している。したがって、ＩｏＴ機器登録テーブルＴＴ′に記録されている「個別通信部６１２」を示す情報は、間接的に、通信規格ＷｉＦｉおよび固有アドレスＡＤ７０２を示すアクセス方法情報を対応づけた情報になる。
したがって、内部端末装置６００Ａは、ネットワークＮから通信データＱ１０もしくは暗号化通信データＱ１０Ｃを受信すると、内部端末用仲介部６１０は、ＩｏＴ機器登録テーブルＴＴ′を参照することにより、受信した情報を適切な個別通信部６１１～６１５に振り分ける処理を行うことができる。
具体的には、内部端末用仲介部６１０は、内部端末装置６００Ａが受信した通信データＱ１０もしくは暗号化通信データＱ１０Ｃから、機器特定情報Ｑ１２１と、ＩｏＴ機器宛データＱ１２２もしくはＩｏＴ機器宛暗号データＱ１２２Ｃと、を抽出し、ＩｏＴ機器登録テーブルＴＴ′を参照することにより、抽出した機器特定情報Ｑ１２１に対応する個別通信部６１１～６１５を選択し、選択された個別通信部６１１～６１５に対して、抽出したＩｏＴ機器宛データＱ１２２もしくは抽出したＩｏＴ機器宛暗号データＱ１２２Ｃを復号して得られるＩｏＴ機器宛データＱ１２２を与える処理を行う。
各個別通信部６１１～６１５は、内部端末用仲介部６１０からＩｏＴ機器宛データＱ１２２が与えられたら、このＩｏＴ機器宛データＱ１２２を、対応するＩｏＴ機器７０１～７０５宛に、所定の通信規格を用いた通信によって送信する。
一方、ＩｏＴ機器７０１～７０５から外部端末装置６００Ｂ～６００Ｄ宛の送信を行う場合は、上述とは逆の手順が実行される。たとえば、ＩｏＴ機器７０２（エアコン）から外部端末装置６００Ｂ（スマートフォン）に対して、端末装置宛データＱ２２２を送信する場合、まず、ＩｏＴ機器７０２（エアコン）から個別通信部６１２に対して、端末装置宛データＱ２２２が送信される。その後、端末装置宛データＱ２２２は、個別通信部６１２から内部端末用仲介部６１０に引き渡され、ここで図２７に示すような通信データＱ２０もしくは図２８に示すような暗号化通信データＱ２０Ｃが作成される。こうして作成された通信データＱ２０もしくは暗号化通信データＱ２０Ｃが、内部端末装置６００Ａから外部端末装置６００Ｂへと送信される手順は、既に§９で述べたとおりである。
＜１０．２ゲートウェイ装置の構成の変形例＞
次に、図２９に示すゲートウェイ装置ＧＷの構成例についての変形例を図３０を参照しながら説明する。図３０に示す変形例に係るゲートウェイ装置ＧＷ′は、図２９に示すゲートウェイ装置ＧＷに、更に、通常ルータ部６２０を追加したものである。この通常ルータ部６２０は、下流側に接続されたＩｏＴ機器７０１～７０５を上流側に接続されたネットワークＮに接続するルーティング機能を有する一般的なルータ装置である。
次に、図２９に示すゲートウェイ装置ＧＷの構成例についての変形例を図３０を参照しながら説明する。図３０に示す変形例に係るゲートウェイ装置ＧＷ′は、図２９に示すゲートウェイ装置ＧＷに、更に、通常ルータ部６２０を追加したものである。この通常ルータ部６２０は、下流側に接続されたＩｏＴ機器７０１～７０５を上流側に接続されたネットワークＮに接続するルーティング機能を有する一般的なルータ装置である。
したがって、この変形例の場合、各ＩｏＴ機器７０１～７０５は、以下に述べる２通りの接続経路によって、ネットワークＮ（インターネット）を介して外部端末装置に接続されることになる。
まず、第１の接続経路は、これまで述べてきたように、接続仲介装置５００の仲介を経た接続経路であり、内部端末装置６００Ａを介して、接続仲介装置５００内のアドレステーブルＴに登録されている外部端末装置に対してのみ接続が可能になる接続経路である。図２２に示す例の場合、この第１の接続経路による接続では、ＩｏＴ機器７０１～７０５は、外部端末装置６００Ｂ～６００Ｄに対してのみ接続が可能になる。
一方、第２の接続経路は、通常ルータ部６２０を介した接続経路である。通常ルータ部６２０は、図１５に示すルータＲと同様に、一般的なルータ機能を用いて各ＩｏＴ機器７０１～７０５をインターネットＮに接続する役割を果たす。したがって、各ＩｏＴ機器７０１～７０５には、通常ルータ部６２０が構築したネットワーク内においてプライベートＩＰアドレスが付与される。通常ルータ部６２０は、ＮＡＰＴ機能により、このプライベートＩＰアドレスをグローバルＩＰアドレスおよびポート番号の形式に変換して、インターネットＮへの接続を行うことになる。
上述した第１の接続経路を利用した通信は、接続仲介装置５００による仲介を必須とするため、予めアドレステーブルＴに登録されている端末装置間についてのみ行われる通信になる。別言すれば、この第１の接続経路を利用した通信を司る内部端末装置６００Ａは、接続仲介装置５００による仲介を経た通信のみを実行することになる。したがって、図２１に示すような不正な端末装置１９が、この第１の接続経路を利用して各ＩｏＴ機器にアクセスすることを防止することができ、十分なセキュリティを確保することができる。しかしながら、各ＩｏＴ機器と通信できる端末装置が、アドレステーブルＴに登録されて
いる端末装置に限定されるため、通信の自由度は大幅に制限されることになる。
いる端末装置に限定されるため、通信の自由度は大幅に制限されることになる。
これに対して、上述した第２の接続経路を利用した通信では、通信相手となる端末装置は特に限定されず、アドレステーブルＴに登録されていない任意の端末装置に対する通信が可能になる。このため、通信の自由度は格段に向上することになるが、不正な端末装置１９も通信相手に含まれるため、セキュリティは低下せざるを得ない。そこで、実用上は、通常ルータ部６２０によって行われる通信について、以下に説明するような制限を課するようにするのが好ましい。
ここでは、通常ルータ部６２０が実行可能な通信を、次の３つに分類してみる。なお、以下の説明における「昇流通信」とは、通常ルータ部６２０の下流側から上流側に向けて情報が流れる通信を指し、「降流通信」とは、通常ルータ部６２０の上流側から下流側に向けて情報が流れる通信を指している。
(a) ＩｏＴ機器７０１～７０５からネットワークＮへ向かう昇流通信、
(b) ネットワークＮからＩｏＴ機器７０１～７０５へ向かう降流通信のうち、上記昇流通信に対する応答として戻ってきた降流通信、
(c) ネットワークＮからＩｏＴ機器７０１～７０５へ向かう降流通信のうち、上記(b) 以外の降流通信。
(a) ＩｏＴ機器７０１～７０５からネットワークＮへ向かう昇流通信、
(b) ネットワークＮからＩｏＴ機器７０１～７０５へ向かう降流通信のうち、上記昇流通信に対する応答として戻ってきた降流通信、
(c) ネットワークＮからＩｏＴ機器７０１～７０５へ向かう降流通信のうち、上記(b) 以外の降流通信。
通信(a) は、ＩｏＴ機器側からネットワークＮに何らかの情報を送信する場合に対応しており、たとえば、ＩｏＴ機器７０１（監視カメラ）が、ネットワークＮを介して所定の端末装置に対して撮影画像を送信する場合には、この通信(a) にいう昇流通信が実行される。その他、たとえば、Ｗｅｂサーバとして機能している端末装置に対して、ＩｏＴ機器がＨＴＴＰリクエストを送信する場合も、この通信(a) にいう昇流通信に相当する。具体的には、ＩｏＴ機器７０３（冷蔵庫）が、様々な食材に関する献立表をＷｅｂサーバに要求したり、ＩｏＴ機器７０４（ビデオデッキ）が、テレビ番組の番組表をＷｅｂサーバに要求したりする際に、このようなＨＴＴＰリクエストの送信が行われる。
このような昇流通信を実行する場合、通信先の端末装置が、アドレステーブルＴに登録されている外部端末装置であれば、内部端末装置６００Ａを介した第１の接続経路による通信を行うことができるが、そうでない場合は、通常ルータ部６２０を介した第２の接続経路による通信を行わざるを得ない。
一方、通信(b) ，(c) は、いずれも、ネットワークＮを介して送信されてきた何らかの情報が、ＩｏＴ機器側に届けられる場合に対応している。ただ、通信(b) は、送信されてきた情報が、通信(a) の昇流通信に対する応答として戻ってきた情報である場合を示し、通信(c) は、それ以外の情報である場合を示している。たとえば、上述したように、ＩｏＴ機器が所定のＷｅｂサーバに対して、ＨＴＴＰリクエストを送信すると（通信(a) にいう昇流通信が行われたことになる）、当該Ｗｅｂサーバからは、当該ＨＴＴＰリクエストに応じたＨＴＴＰレスポンスが返されることになる。こうして返されたＨＴＴＰレスポンスは、通信(a) の昇流通信に対する応答として戻ってきた情報であるので、通信(b) にいう降流通信に相当する。
また、図２２に示す外部端末装置６００Ｄ（アップデートサーバ）が、通常ルータ部６２０宛にアップデータのPush型配信を行った場合、当該アップデータは、ＩｏＴ機器側から送信された通信(a) の昇流通信に対する応答として戻ってきた情報ではないので、通信(c) にいう降流通信ということになる。これに対して、外部端末装置６００Ｄ（アップデートサーバ）が、ＩｏＴ機器側から送信されたアップデート要求（通信(a) の昇流通信）に対する応答として、通常ルータ部６２０宛にアップデータのPull型配信を行った場合は、当該アップデータは、通信(b) にいう降流通信ということになる。
このように、通常ルータ部６２０が実行可能な通信を、(a) ，(b) ，(c) の３つの形態に分類した場合に、(a) および(b) の通信は実行し、(c) の通信は拒絶するように設定しておくと、ＩｏＴ機器についてのセキュリティを向上させる上で好ましい。まず、通信(a) は、ＩｏＴ機器からネットワークＮへ出て行く通信であるため、当該ＩｏＴ機器のセキュリティを脅かす通信にはならないので、特に制限する必要はなく、常に実行するようにしてかまわない。
これに対して、通信(b) ，(c) は、ネットワークＮからＩｏＴ機器に入ってくる通信であるため、これを実行して、通信データを受け入れてしまうと、ＩｏＴ機器がハッキングを受ける可能性がある。ただ、通信(b) に関しては、もともとＩｏＴ機器から行った通信(a) に対する応答として戻ってきた通信であるため、通信(c) に比べると、セキュリティ上の脅威となる可能性は低い。これに対して、通信(c) は、外部の端末装置から一方的になされたものであるため、セキュリティ上の脅威となる可能性は高くなる。このような観点から、実用上は、通信(a) および通信(b) は実行し、通信(c) は拒絶するような運用を行うのが好ましい。
そうすれば、上例のように、ＩｏＴ機器が所定のＷｅｂサーバに対して、ＨＴＴＰリクエストを送信し（通信(a) を行い）、当該Ｗｅｂサーバから、当該ＨＴＴＰリクエストに応じたＨＴＴＰレスポンスが返されてきた場合、当該ＨＴＴＰレスポンスは、通信(b) に相当するため受け入れられ、ＩｏＴ機器へ届けられる。これに対して、不正な端末装置１９から何らかの情報送信があった場合、当該情報送信は、通信(c) に相当するため拒絶されることになる。
もちろん、上記運用を行うことにすると、図２２に示す外部端末装置６００Ｄ（アップデートサーバ）から、第２の接続経路を利用して通常ルータ部６２０に対して、Push型配信によるアップデータが送信されてきた場合、通信(c) に該当するため拒絶されてしまう。しかしながら、外部端末装置６００Ｄは、前述したように、第１の接続経路を利用して内部端末装置６００Ａに対して、Push型配信によるアップデータの送信を行えばよいので支障は生じない。
なお、通常ルータ部６２０に、通信(a) および通信(b) は実行し、通信(c) は拒絶する処理を実行させるには、下流側から上流側へ向かう通信（通信(a) ）については、これを無条件に実行するとともに、通信先となる端末装置のアドレスと送信源となるＩｏＴ機器に対応するポート番号との組み合わせを一定時間だけ保存しておくようにし、上流側から下流側へ向かう通信（通信(b) ,(c) ）については、通信元となる端末装置のアドレスと宛先となるＩｏＴ機器に対応するポート番号との組み合わせが、保存されている組み合わせのいずれかと一致した場合（通信(b) の場合）、これを実行するようにし、一致しなかった場合（通信(c) の場合）、これを拒絶するようにすればよい。
１１：端末装置（スマートフォン）
１２：端末装置（パソコン）
１３：端末装置（アップデートサーバ）
１９：不正な端末装置
１００：接続仲介装置
１１０：アドレステーブル格納部
１２０：アドレステーブル更新部
１３０：通信先アドレス返信部
２００，２００Ａ～２００Ｋ：端末装置
２０１Ｈ，２０１Ｋ：ＶＰＮ通信部
２１０，２１０Ａ，２１０Ｂ：接続仲介依頼部
２２０，２２０Ａ，２２０Ｂ：通信要求受付部
２３０，２３０Ａ，２３０Ｂ：通信先セッション確立部
２４０，２４０Ａ，２４０Ｂ：通信開始要求部
２５０，２５０Ａ，２５０Ｂ：自己アドレス通知部
２６０，２６０Ａ，２６０Ｂ：通信元セッション確立部
３００：接続仲介装置
３１０：アドレステーブル格納部
３２０：アドレステーブル更新部
３３０：通信元アドレス送信部
４００，４００Ａ～４００Ｄ：端末装置
４１０，４１０Ａ，４１０Ｂ：接続仲介依頼部
４２０，４２０Ａ，４２０Ｂ：通信要求受付部
４３０，４３０Ａ，４３０Ｂ：通信元セッション確立部
４４０，４４０Ａ，４４０Ｂ：通信開始要求部
４５０，４５０Ａ，４５０Ｂ：自己アドレス通知部
４６０，４６０Ａ，４６０Ｂ：通信先セッション確立部
５００：接続仲介装置
６００Ａ：内部端末装置（ゲートウェイ装置ＧＷに組み込まれた端末装置）
６００Ｂ：外部端末装置（スマートフォン）
６００Ｃ：外部端末装置（パソコン）
６００Ｄ：外部端末装置（アップデートサーバ）
６１０：内部端末用仲介部
６１１～６１５：個別通信部
６２０：通常ルータ部
７０１～７０５：ＩｏＴ機器
ＡＤ１～ＡＤ４，ＡＤ１１～ＡＤ１４：所在アドレス
ＡＤ７０１～ＡＤ７０５：固有アドレス
ＡＤｘ，ＡＤｙ，ＡＤｚ：グローバルＩＰアドレス
ＡＰＰ１，ＡＰＰ２：アプリケーションプログラム
Ｃ：自動車
Ｃ１～Ｃ４：車載用ＩｏＴ機器
ＧＷ，ＧＷ′：ゲートウェイ装置
Ｈ：家庭
Ｈ１～Ｈ７：パーソナルユースを想定したＩｏＴ機器
Ｎ：ネットワーク（インターネット）
Ｐ１～Ｐ２１：ポート番号
Ｑ１０：通信データ（ＩＰパケット）
Ｑ１０Ｃ：暗号化通信データ（ＩＰパケット）
Ｑ１１：ＩＰヘッダ部
Ｑ１２，Ｑ１２Ｃ：ＩＰデータ部
Ｑ２０：通信データ（ＩＰパケット）
Ｑ２０Ｃ：暗号化通信データ（ＩＰパケット）
Ｑ２１：ＩＰヘッダ部
Ｑ２２，Ｑ２２Ｃ：ＩＰデータ部
Ｑ１１１：送信元アドレス
Ｑ１１２：送信先アドレス
Ｑ１２１：機器特定情報
Ｑ１２２：ＩｏＴ機器宛データ
Ｑ１２２Ｃ：ＩｏＴ機器宛暗号データ
Ｑ２１１：送信元アドレス
Ｑ２１２：送信先アドレス
Ｑ２２０：端末装置特定情報
Ｑ２２１：機器特定情報
Ｑ２２２：ＩｏＴ機器宛データ
Ｑ２２２Ｃ：ＩｏＴ機器宛暗号データ
Ｒ，Ｒ１，Ｒ２：ルータ
Ｓ１～Ｓ７，Ｓ１１～Ｓ１７：流れ図の各ステップ
Ｔ，Ｔ１～Ｔ３，Ｔ４１，Ｔ４２，Ｔ５１，Ｔ５２：アドレステーブル
ＴＴ，ＴＴ′：ＩｏＴ機器テーブル
Ｕ：ＩｏＴ機器に格納されているユニークなデータ
１２：端末装置（パソコン）
１３：端末装置（アップデートサーバ）
１９：不正な端末装置
１００：接続仲介装置
１１０：アドレステーブル格納部
１２０：アドレステーブル更新部
１３０：通信先アドレス返信部
２００，２００Ａ～２００Ｋ：端末装置
２０１Ｈ，２０１Ｋ：ＶＰＮ通信部
２１０，２１０Ａ，２１０Ｂ：接続仲介依頼部
２２０，２２０Ａ，２２０Ｂ：通信要求受付部
２３０，２３０Ａ，２３０Ｂ：通信先セッション確立部
２４０，２４０Ａ，２４０Ｂ：通信開始要求部
２５０，２５０Ａ，２５０Ｂ：自己アドレス通知部
２６０，２６０Ａ，２６０Ｂ：通信元セッション確立部
３００：接続仲介装置
３１０：アドレステーブル格納部
３２０：アドレステーブル更新部
３３０：通信元アドレス送信部
４００，４００Ａ～４００Ｄ：端末装置
４１０，４１０Ａ，４１０Ｂ：接続仲介依頼部
４２０，４２０Ａ，４２０Ｂ：通信要求受付部
４３０，４３０Ａ，４３０Ｂ：通信元セッション確立部
４４０，４４０Ａ，４４０Ｂ：通信開始要求部
４５０，４５０Ａ，４５０Ｂ：自己アドレス通知部
４６０，４６０Ａ，４６０Ｂ：通信先セッション確立部
５００：接続仲介装置
６００Ａ：内部端末装置（ゲートウェイ装置ＧＷに組み込まれた端末装置）
６００Ｂ：外部端末装置（スマートフォン）
６００Ｃ：外部端末装置（パソコン）
６００Ｄ：外部端末装置（アップデートサーバ）
６１０：内部端末用仲介部
６１１～６１５：個別通信部
６２０：通常ルータ部
７０１～７０５：ＩｏＴ機器
ＡＤ１～ＡＤ４，ＡＤ１１～ＡＤ１４：所在アドレス
ＡＤ７０１～ＡＤ７０５：固有アドレス
ＡＤｘ，ＡＤｙ，ＡＤｚ：グローバルＩＰアドレス
ＡＰＰ１，ＡＰＰ２：アプリケーションプログラム
Ｃ：自動車
Ｃ１～Ｃ４：車載用ＩｏＴ機器
ＧＷ，ＧＷ′：ゲートウェイ装置
Ｈ：家庭
Ｈ１～Ｈ７：パーソナルユースを想定したＩｏＴ機器
Ｎ：ネットワーク（インターネット）
Ｐ１～Ｐ２１：ポート番号
Ｑ１０：通信データ（ＩＰパケット）
Ｑ１０Ｃ：暗号化通信データ（ＩＰパケット）
Ｑ１１：ＩＰヘッダ部
Ｑ１２，Ｑ１２Ｃ：ＩＰデータ部
Ｑ２０：通信データ（ＩＰパケット）
Ｑ２０Ｃ：暗号化通信データ（ＩＰパケット）
Ｑ２１：ＩＰヘッダ部
Ｑ２２，Ｑ２２Ｃ：ＩＰデータ部
Ｑ１１１：送信元アドレス
Ｑ１１２：送信先アドレス
Ｑ１２１：機器特定情報
Ｑ１２２：ＩｏＴ機器宛データ
Ｑ１２２Ｃ：ＩｏＴ機器宛暗号データ
Ｑ２１１：送信元アドレス
Ｑ２１２：送信先アドレス
Ｑ２２０：端末装置特定情報
Ｑ２２１：機器特定情報
Ｑ２２２：ＩｏＴ機器宛データ
Ｑ２２２Ｃ：ＩｏＴ機器宛暗号データ
Ｒ，Ｒ１，Ｒ２：ルータ
Ｓ１～Ｓ７，Ｓ１１～Ｓ１７：流れ図の各ステップ
Ｔ，Ｔ１～Ｔ３，Ｔ４１，Ｔ４２，Ｔ５１，Ｔ５２：アドレステーブル
ＴＴ，ＴＴ′：ＩｏＴ機器テーブル
Ｕ：ＩｏＴ機器に格納されているユニークなデータ
Claims (5)
- ゲートウェイ装置と、
ネットワークを介して相互に接続可能な複数の端末装置と、
前記複数の端末装置間の接続を、アドレステーブルを使用して仲介する接続仲介装置と
を備えたネットワーク通信システムであって、
前記複数の端末装置のうちの1つは、アップデートサーバであり、
前記複数の端末装置のうちの1つは、ゲートウェイ装置に内包されている内部端末装置であり、
前記アップデートサーバは、
前記接続仲介装置に接続仲介依頼を行い、
接続仲介依頼を受けた前記接続仲介装置は、
前記アドレステーブルを参照し、前記アップデートサーバと前記内部端末装置との接続を仲介し、
前記アップデートサーバは、
前記内部端末装置に、通信データを送信する、
ネットワーク通信システム。 - ゲートウェイ装置と、
ネットワークを介して相互に接続可能な複数の端末装置と、
前記複数の端末装置間の接続を、アドレステーブルを使用して仲介する接続仲介装置と
を備えたネットワーク通信システムであって、
前記複数の端末装置のうちの1つは、アップデートサーバであり、
前記複数の端末装置のうちの1つは、ゲートウェイ装置に内包されている内部端末装置であり、
前記内部端末装置は、
前記接続仲介装置に接続仲介依頼を行い、
接続仲介依頼を受けた前記接続仲介装置は、
前記アドレステーブルを参照し、前記アップデートサーバと前記内部端末装置との接続を仲介し、
前記アップデートサーバは、
前記内部端末装置に、通信データを送信する、
ネットワーク通信システム。 - 前記ゲートウェイ装置は、
１又は複数のＩｏＴ機器と接続されている、
請求項１又は請求項２に記載のネットワーク通信システム。 - 前記通信データは、前記ＩｏＴ機器宛データを含む、
請求項３に記載のネットワーク通信システム。 - 前記ＩｏＴ機器宛データは、所定のアップデータを含む、
請求項４に記載のネットワーク通信システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2021195508A JP7173271B2 (ja) | 2018-02-19 | 2021-12-01 | ネットワーク通信システム |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2018026786A JP6988545B2 (ja) | 2018-02-19 | 2018-02-19 | ネットワーク通信システム |
| JP2021195508A JP7173271B2 (ja) | 2018-02-19 | 2021-12-01 | ネットワーク通信システム |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2018026786A Division JP6988545B2 (ja) | 2018-02-19 | 2018-02-19 | ネットワーク通信システム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2022025152A JP2022025152A (ja) | 2022-02-09 |
| JP2022025152A5 JP2022025152A5 (ja) | 2022-03-09 |
| JP7173271B2 true JP7173271B2 (ja) | 2022-11-16 |
Family
ID=87852964
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2021195508A Active JP7173271B2 (ja) | 2018-02-19 | 2021-12-01 | ネットワーク通信システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP7173271B2 (ja) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090043854A1 (en) | 2007-08-08 | 2009-02-12 | International Business Machines Corporation | Instant Messaging Session Initiation Using a Proxy Session Request |
| JP2009081852A (ja) | 2007-09-04 | 2009-04-16 | Seiko Epson Corp | ファイル転送システムおよびその方法 |
| JP2017059211A (ja) | 2015-09-14 | 2017-03-23 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法 |
| JP2017105309A (ja) | 2015-12-09 | 2017-06-15 | 株式会社オートネットワーク技術研究所 | 車載通信装置、車載通信システム及び車両特定処理禁止方法 |
| WO2017145984A1 (ja) | 2016-02-22 | 2017-08-31 | 大日本印刷株式会社 | ネットワーク通信システム |
-
2021
- 2021-12-01 JP JP2021195508A patent/JP7173271B2/ja active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090043854A1 (en) | 2007-08-08 | 2009-02-12 | International Business Machines Corporation | Instant Messaging Session Initiation Using a Proxy Session Request |
| JP2009081852A (ja) | 2007-09-04 | 2009-04-16 | Seiko Epson Corp | ファイル転送システムおよびその方法 |
| JP2017059211A (ja) | 2015-09-14 | 2017-03-23 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ | ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法 |
| JP2017105309A (ja) | 2015-12-09 | 2017-06-15 | 株式会社オートネットワーク技術研究所 | 車載通信装置、車載通信システム及び車両特定処理禁止方法 |
| WO2017145984A1 (ja) | 2016-02-22 | 2017-08-31 | 大日本印刷株式会社 | ネットワーク通信システム |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2022025152A (ja) | 2022-02-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10038779B2 (en) | Intercepting voice over IP communications and other data communications | |
| US8295285B2 (en) | Method and apparatus for communication of data packets between local networks | |
| JP4260116B2 (ja) | 安全な仮想プライベート・ネットワーク | |
| US11838269B2 (en) | Securing access to network devices utilizing authentication and dynamically generated temporary firewall rules | |
| US8437254B2 (en) | Dynamic configuration of VoIP trunks | |
| US20200084633A1 (en) | Method for establishing a secure connection | |
| JP7173271B2 (ja) | ネットワーク通信システム | |
| JP6787390B2 (ja) | ネットワーク通信システム | |
| JP6988545B2 (ja) | ネットワーク通信システム | |
| JP6879370B2 (ja) | ネットワーク通信システム | |
| JP2006229265A (ja) | ゲートウェイシステム | |
| JP7056663B2 (ja) | ネットワーク通信システム | |
| JP6879372B2 (ja) | ネットワーク通信システム | |
| JP6879373B2 (ja) | ネットワーク通信システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20211221 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20220222 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20220905 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20221004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20221017 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7173271 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |