JP6879373B2 - ネットワーク通信システム - Google Patents

ネットワーク通信システム Download PDF

Info

Publication number
JP6879373B2
JP6879373B2 JP2019537433A JP2019537433A JP6879373B2 JP 6879373 B2 JP6879373 B2 JP 6879373B2 JP 2019537433 A JP2019537433 A JP 2019537433A JP 2019537433 A JP2019537433 A JP 2019537433A JP 6879373 B2 JP6879373 B2 JP 6879373B2
Authority
JP
Japan
Prior art keywords
communication
address
terminal device
unit
detour
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
Application number
JP2019537433A
Other languages
English (en)
Other versions
JPWO2019038802A1 (ja
Inventor
正 大木
正 大木
矢野　義博
義博 矢野
小川　隆
隆 小川
伸乃助 仲谷
伸乃助 仲谷
大樹 加藤
大樹 加藤
和樹 太治
和樹 太治
卓矢 岡野
卓矢 岡野
中井　俊之
俊之 中井
茂男 蜂木
茂男 蜂木
憲朗 伊藤
憲朗 伊藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dai Nippon Printing Co Ltd
Original Assignee
Dai Nippon Printing Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Dai Nippon Printing Co Ltd filed Critical Dai Nippon Printing Co Ltd
Publication of JPWO2019038802A1 publication Critical patent/JPWO2019038802A1/ja
Application granted granted Critical
Publication of JP6879373B2 publication Critical patent/JP6879373B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、ネットワークを介した端末間通信を行うためのネットワーク通信システムに関する。
今日、パソコンやスマートフォンをはじめとする様々な端末装置がインターネットに接続されるようになってきており、ネットワークを介した端末間通信も広く普及している。ただ、インターネットのような公衆ネットワークを利用して端末間通信を行う上では、セキュリティを確保する上で何らかの工夫を施す必要がある。また、モバイル端末の場合、ネットワーク上での所在が時間的に変化するため、通信先となる端末の現時点での所在アドレスを何らかの方法で認識する必要がある。
このような観点から、従来の一般的なネットワーク通信システムでは、端末装置間の通信を取り継ぐ役割を果たす中継装置が設けられている。たとえば、下記の特許文献１には、第１の端末装置と中継装置との間にセキュアな第１の通信チャネルを確保し、第２の端末装置と中継装置との間にセキュアな第２の通信チャネルを確保して、中継装置を介して両端末装置間で通信を行うネットワーク通信システムが開示されている。ただ、このような中継装置を利用したシステムでは、両端末間の通信データがすべて中継装置を経由することになるため、中継装置に多大な処理負荷がかかるという問題がある。
そこで、最近は、ＳＩＰ（Session Initiation Protocol）と呼ばれるプロトコルを利用して、ネットワーク上に設けられた接続仲介装置により、両端末間での通信セッション確立の取り継ぎを行い、通信セッション確立後は、両端末間で直接通信を行う方式が提案されている。たとえば、下記の特許文献２，３には、このＳＩＰを利用して端末間におけるＶＰＮ通信を実現するネットワーク通信システムが開示されている。このシステムにおける接続仲介装置は、通信データのすべてを中継する必要はなく、両端末間に通信セッションが確立されるまでの手助けを行えばよいので、従来の中継装置に比べて処理負荷が大幅に軽減される。
特開２００５−２２９４３６号公報 特開２０１０−２３３１６７号公報 特開２０１３−０３８６８４号公報
上述したとおり、特許文献２，３に開示されているネットワーク通信システムに用いられる接続仲介装置は、ＳＩＰを利用して両端末間の接続仲介処理を行うことになる。この接続仲介処理は、両端末間に通信セッションが確立されるまでの一時的な処理であるため、特許文献１に開示されている従来型の中継処理に比べれば、その処理負荷は軽減されることになる。しかしながら、両端末間に通信セッションが確立するまで関与する必要があるため、多数の端末装置から同時に仲介依頼があると、その処理負荷は無視できないものになる。このため、仲介依頼が集中すると、通信セッション確立までの一時的な仲介処理であっても、システムの処理能力を超えてしまうおそれがある。
また、近年は、セキュリティを確保するため、端末間通信に様々な制限を設ける措置がとられることがある。たとえば、ルータを介してインターネットに接続されている端末装置の場合、ルータにおいて、ＮＡＴ（Network Address Translation）と呼ばれるアドレス変換が行われる。このＮＡＴにはいくつかのタイプがあり、たとえば、「Symmetric NAT」（対称型ＮＡＴ）や「Port restricted cone NAT」と呼ばれるタイプのＮＡＴ（本願では、便宜上、関所型ＮＡＴと呼ぶ）が採用されていた場合、過去に内部ホストからのパケットを受け取った外部ホストのみがパケットを送り返すことができるという制約が課される。
あるいは、端末間通信のトランスポート層のプロトコルとして、ＵＤＰ（User Datagram Protocol）を採用して端末間での直接通信を行うことを前提とするシステムの場合、端末間にＵＤＰのパケットをブロックするファイアウォールが存在すると、両端末間のパケット通信は阻害されてしまう。したがって、実用上は、上述したような様々な要因により、端末間の直接通信に何らかの制限が設けられている場合にも、両者間での通信を支障なく行うことが可能となるような対策を講じる必要がある。
そこで本発明は、一対の端末装置間の接続を仲介する際の処理負荷を、より軽減することができ、しかも端末装置間の直接通信に問題がある場合にも、両者間での通信を支障なく行うことが可能なネットワーク通信システムを提供することを目的とする。
(1) 本発明の第１の態様は、ネットワークを介して相互に接続可能な複数の端末装置と、これら複数の端末装置間の接続を仲介する接続仲介装置と、を備えたネットワーク通信システムにおいて、
複数の端末装置には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置は、端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行し、
複数の端末装置のそれぞれは、
自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置に対して通知する自己アドレス通知部と、
自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける通信要求受付部と、
通信要求受付部によって通信要求が受け付けられたときに、接続仲介装置に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する接続仲介依頼部と、
接続仲介依頼に応じて、接続仲介装置から、通信先の別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてきたときに、ネットワークを介して、通信先アドレスにアクセスして通信開始要求を行う通信開始要求部と、
通信開始要求に応じて、通信先の別な端末装置から、通信開始受諾確認が返信されてきたら、通信先の別な端末装置との間に通信セッションを確立して通信を開始する通信元セッション確立部と、
通信元の別な端末装置から、自己を通信先とする通信開始要求がなされたら、通信元の別な端末装置に対して通信開始受諾確認を送信し、通信元の別な端末装置との間に通信セッションを確立して通信を開始する通信先セッション確立部と、
通信元セッション確立部と通信先セッション確立部との間に通信セッションを確立して相手方に対する直接的な情報送受を行う通常通信に失敗したとき、もしくは失敗が予想されるときに、接続仲介装置を介して相手方に対する間接的な情報送受を行う迂回通信を実行する迂回通信処理部と、
を有し、
接続仲介装置は、
端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルを格納するアドレステーブル格納部と、
端末装置の自己アドレス通知部からの通知に基づいて、アドレステーブルの内容を更新するアドレステーブル更新部と、
端末装置の接続仲介依頼部から、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する通信先アドレス返信部と、
第１の端末装置の迂回通信処理部と第２の端末装置の迂回通信処理部との間での迂回通信の中継依頼があったときに、第１の端末装置の迂回通信処理部と第２の端末装置の迂回通信処理部との間で受け渡しする情報を取り次いで迂回通信の中継を行う迂回通信中継部と、
を有するようにしたものである。
(2) 本発明の第２の態様は、上述した第１の態様に係るネットワーク通信システムにおいて、
通信開始要求部が通信開始要求を行った後、これに応じた通信開始受諾確認が所定のタイムアウト設定時間内に返信されてこなかった場合に、迂回通信処理部が、迂回通信中継部に対して迂回通信の中継依頼を行い、迂回通信中継部を介して、相手方の迂回通信処理部との間での迂回通信を実行するようにしたものである。
(3) 本発明の第３の態様は、上述した第１の態様に係るネットワーク通信システムにおいて、
通信開始要求部が行った通信開始要求に対してアクノレッジが得られなかった場合に、迂回通信処理部が、迂回通信中継部に対して迂回通信の中継依頼を行い、迂回通信中継部を介して、相手方の迂回通信処理部との間での迂回通信を実行するようにしたものである。
(4) 本発明の第４の態様は、上述した第１の態様に係るネットワーク通信システムにおいて、
複数の端末装置のそれぞれが、ネットワークを介してＮＡＴタイプ判別装置に対して自己のＮＡＴタイプを照会し、ＮＡＴタイプ判別装置からの回答を得るＮＡＴタイプ確認部を更に備え、
自己アドレス通知部が、接続仲介装置に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部が得た回答を併せて通知し、
接続仲介装置内のアドレステーブル格納部が、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけたアドレステーブルを格納する機能を有し、
接続仲介装置内のアドレステーブル更新部が、自己アドレス通知部からの通知に含まれる回答に基づいて、アドレステーブル内のＮＡＴタイプの更新を行う機能を有し、
接続仲介装置内の通信先アドレス返信部が、接続仲介依頼の送信を受けたときに、アドレステーブルを参照して通信先の端末装置のＮＡＴタイプが「外部から当該通信先の端末装置宛に送信されてきたパケットについては、当該通信先の端末装置からのパケットを受け取ったことがある外部ホストからのパケットのみを通すという制限の下でアドレス変換を行う関所型ＮＡＴ」であるか否かを確認し、通信先の端末装置のＮＡＴタイプが関所型ＮＡＴではなかった場合には、通信方法として通常通信を選択し、通信先の端末装置のＮＡＴタイプが関所型ＮＡＴであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
通信開始要求部が、接続仲介装置から通信先アドレスと共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、ネットワークを介して、通信先アドレスにアクセスして通信開始要求を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部に対して迂回通信指示を行うようにしたものである。
(5) 本発明の第５の態様は、上述した第４の態様に係るネットワーク通信システムにおいて、
自己アドレス通知部が、接続仲介装置に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部に対してＮＡＴタイプ確認指示を出し、
ＮＡＴタイプ確認部が、ＮＡＴタイプ確認指示を受けたときに、ＮＡＴタイプ判別装置に対して自己のＮＡＴタイプを照会し、得られた回答を自己アドレス通知部に報告し、
自己アドレス通知部が、この報告に基づいて上記回答を接続仲介装置に対して通知するようにしたものである。
(6) 本発明の第６の態様は、上述した第１の態様に係るネットワーク通信システムにおいて、
自己アドレス通知部が、接続仲介装置に対して自己の所在アドレスを通知する際に、まず、通信プロトコルとしてＵＤＰを用いた第１回通知を行い、当該第１回通知に失敗した場合には、続いて、通信プロトコルとしてＴＣＰを用いた第２回通知を行い、
接続仲介装置内のアドレステーブル格納部が、端末ＩＤと所在アドレスに加えて、更に、通信プロトコルを対応づけたアドレステーブルを格納する機能を有し、
接続仲介装置内のアドレステーブル更新部が更新を行う際に、第１回通知に基づいて更新を行う場合には、通信プロトコルとしてＵＤＰを対応づけ、第２回通知に基づいて更新を行う場合には、通信プロトコルとしてＴＣＰを対応づけ、
接続仲介装置内の通信先アドレス返信部が、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、通信元の端末装置および通信先の端末装置の通信プロトコルを確認し、両端末装置の通信プロトコルがいずれもＵＤＰであった場合には、通信方法として通常通信を選択し、少なくとも一方の通信プロトコルがＴＣＰであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
通信開始要求部が、接続仲介装置から通信先アドレスと共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、通信先アドレスに対して通信プロトコルＵＤＰを用いたアクセスにより通信開始要求を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部に対して迂回通信指示を行い、
通信方法として通常通信が選択されていた場合には、通信元セッション確立部と通信先セッション確立部との間で、通信プロトコルＵＤＰを用いた通常通信を実行し、通信方法として迂回通信が選択されていた場合には、通信元の迂回通信処理部と通信先の迂回通信処理部との間で、通信プロトコルＴＣＰを用いて、接続仲介装置を介した迂回通信を実行するようにしたものである。
(7) 本発明の第７の態様は、ネットワークを介して相互に接続可能な複数の端末装置と、これら複数の端末装置間の接続を仲介する接続仲介装置と、を備えたネットワーク通信システムにおいて、
複数の端末装置には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置は、端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行し、
複数の端末装置のそれぞれは、
自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置に対して通知する自己アドレス通知部と、
自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける通信要求受付部と、
通信要求受付部によって通信要求が受け付けられたときに、接続仲介装置に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する接続仲介依頼部と、
接続仲介装置から、通信元の別な端末装置のネットワーク上での所在を示す通信元アドレスが送信されてきたときに、ネットワークを介して、通信元アドレスにアクセスして通信開始要求を行う通信開始要求部と、
通信開始要求に応じて、通信元の別な端末装置から、通信開始受諾確認が返信されてきたら、通信元の別な端末装置との間に通信セッションを確立して通信を開始する通信先セッション確立部と、
通信先の別な端末装置から、自己を通信元とする通信開始要求がなされたら、通信先の別な端末装置に対して通信開始受諾確認を送信し、通信先の別な端末装置との間に通信セッションを確立して通信を開始する通信元セッション確立部と、
通信元セッション確立部と通信先セッション確立部との間に通信セッションを確立して相手方に対する直接的な情報送受を行う通常通信に失敗したとき、もしくは失敗が予想されるときに、接続仲介装置を介して相手方に対する間接的な情報送受を行う迂回通信を実行する迂回通信処理部と、
を有し、
接続仲介装置は、
端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルを格納するアドレステーブル格納部と、
端末装置の自己アドレス通知部からの通知に基づいて、アドレステーブルの内容を更新するアドレステーブル更新部と、
端末装置の接続仲介依頼部から、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスに対して、接続仲介依頼を送信した通信元の端末装置の端末ＩＤに対応づけられている所在アドレスを通信元アドレスとして送信する通信元アドレス送信部と、
第１の端末装置の迂回通信処理部と第２の端末装置の迂回通信処理部との間での迂回通信の中継依頼があったときに、第１の端末装置の迂回通信処理部と第２の端末装置の迂回通信処理部との間で受け渡しする情報を取り次いで迂回通信の中継を行う迂回通信中継部と、
を有するようにしたものである。
(8) 本発明の第８の態様は、上述した第７の態様に係るネットワーク通信システムにおいて、
通信開始要求部が通信開始要求を行った後、これに応じた通信開始受諾確認が所定のタイムアウト設定時間内に返信されてこなかった場合に、迂回通信処理部が、迂回通信中継部に対して迂回通信の中継依頼を行い、迂回通信中継部を介して、相手方の迂回通信処理部との間での迂回通信を実行するようにしたものである。
(9) 本発明の第９の態様は、上述した第７の態様に係るネットワーク通信システムにおいて、
通信開始要求部が行った通信開始要求に対してアクノレッジが得られなかった場合に、迂回通信処理部が、迂回通信中継部に対して迂回通信の中継依頼を行い、迂回通信中継部を介して、相手方の迂回通信処理部との間での迂回通信を実行するようにしたものである。
(10) 本発明の第１０の態様は、上述した第７の態様に係るネットワーク通信システムにおいて、
複数の端末装置のそれぞれが、ネットワークを介してＮＡＴタイプ判別装置に対して自己のＮＡＴタイプを照会し、ＮＡＴタイプ判別装置からの回答を得るＮＡＴタイプ確認部を更に備え、
自己アドレス通知部が、接続仲介装置に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部が得た回答を併せて通知し、
接続仲介装置内のアドレステーブル格納部が、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけたアドレステーブルを格納する機能を有し、
接続仲介装置内のアドレステーブル更新部が、自己アドレス通知部からの通知に含まれる回答に基づいて、アドレステーブル内のＮＡＴタイプの更新を行う機能を有し、
接続仲介装置内の通信元アドレス送信部が、接続仲介依頼の送信を受けたときに、アドレステーブルを参照して通信元の端末装置のＮＡＴタイプが「外部から当該通信元の端末装置宛に送信されてきたパケットについては、当該通信元の端末装置からのパケットを受け取ったことがある外部ホストからのパケットのみを通すという制限の下でアドレス変換を行う関所型ＮＡＴ」であるか否かを確認し、通信元の端末装置のＮＡＴタイプが関所型ＮＡＴではなかった場合には、通信方法として通常通信を選択し、通信元の端末装置のＮＡＴタイプが関所型ＮＡＴであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
通信開始要求部が、接続仲介装置から通信元アドレスと共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、ネットワークを介して、通信元アドレスにアクセスして通信開始要求を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部に対して迂回通信指示を行うようにしたものである。
(11) 本発明の第１１の態様は、上述した第１０の態様に係るネットワーク通信システムにおいて、
自己アドレス通知部が、接続仲介装置に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部に対してＮＡＴタイプ確認指示を出し、
ＮＡＴタイプ確認部が、ＮＡＴタイプ確認指示を受けたときに、ＮＡＴタイプ判別装置に対して自己のＮＡＴタイプを照会し、得られた回答を自己アドレス通知部に報告し、
自己アドレス通知部が、この報告に基づいて上記回答を接続仲介装置に対して通知するようにしたものである。
(12) 本発明の第１２の態様は、上述した第７の態様に係るネットワーク通信システムにおいて、
自己アドレス通知部が、接続仲介装置に対して自己の所在アドレスを通知する際に、まず、通信プロトコルとしてＵＤＰを用いた第１回通知を行い、当該第１回通知に失敗した場合には、続いて、通信プロトコルとしてＴＣＰを用いた第２回通知を行い、
接続仲介装置内のアドレステーブル格納部が、端末ＩＤと所在アドレスに加えて、更に、通信プロトコルを対応づけたアドレステーブルを格納する機能を有し、
接続仲介装置内のアドレステーブル更新部が更新を行う際に、第１回通知に基づいて更新を行う場合には、通信プロトコルとしてＵＤＰを対応づけ、第２回通知に基づいて更新を行う場合には、通信プロトコルとしてＴＣＰを対応づけ、
接続仲介装置内の通信元アドレス送信部が、接続仲介依頼が送信されてきたときに、アドレステーブルを参照して、通信元の端末装置および通信先の端末装置の通信プロトコルを確認し、両端末装置の通信プロトコルがいずれもＵＤＰであった場合には、通信方法として通常通信を選択し、少なくとも一方の通信プロトコルがＴＣＰであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
通信開始要求部が、接続仲介装置から通信元アドレスと共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、通信元アドレスに対して通信プロトコルＵＤＰを用いたアクセスにより通信開始要求を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部に対して迂回通信指示を行い、
通信方法として通常通信が選択されていた場合には、通信先セッション確立部と通信元セッション確立部との間で、通信プロトコルＵＤＰを用いた通常通信を実行し、通信方法として迂回通信が選択されていた場合には、通信先の迂回通信処理部と通信元の迂回通信処理部との間で、通信プロトコルＴＣＰを用いて、接続仲介装置を介した迂回通信を実行するようにしたものである。
(13) 本発明の第１３の態様は、上述した第４、５、１０、１１の態様に係るネットワーク通信システムにおいて、
端末装置のＮＡＴタイプ確認部からネットワークを介してＮＡＴタイプの照会があったときに、当該照会に係る通信を利用して、照会元の端末装置のＮＡＴタイプを判別し、判別したＮＡＴタイプを照会元の端末装置のＮＡＴタイプ確認部に回答する処理を行うＮＡＴタイプ判別装置を更に設けるようにしたものである。
(14) 本発明の第１４の態様は、上述した第１３の態様に係るネットワーク通信システムにおいて、
ＮＡＴタイプ判別装置として、ＳＴＵＮサーバを用いるようにしたものである。
(15) 本発明の第１５の態様は、上述した第１〜第１２の態様に係るネットワーク通信システムにおける複数の端末装置を構成する１台の端末装置に係るものである。
(16) 本発明の第１６の態様は、上述した第１５の態様に係る１台の端末装置を、コンピュータにプログラムを組み込むことにより構成したものである。
(17) 本発明の第１７の態様は、上述した第１〜第１２の態様に係るネットワーク通信システムにおける接続仲介装置に係るものである。
(18) 本発明の第１８の態様は、上述した第１７の態様に係る接続仲介装置を、コンピュータにプログラムを組み込むことにより構成したものである。
本発明のネットワーク通信システムによれば、接続仲介装置は、両端末間に通信セッションが確立する最終段階まで関与する必要はなく、通信元の端末装置に対して通信先アドレスを伝達する段階（第１の実施形態の場合）、あるいは、通信先の端末装置に対して通信元アドレスを伝達する段階（第２の実施形態の場合）まで行えば足りる。したがって、従来のＳＩＰを利用して両端末間の接続仲介処理を行うシステムに比べて、一対の端末装置間の接続を仲介する際の処理負荷を、より軽減することが可能になる。
また、本発明のネットワーク通信システムでは、通信方法として、端末装置間の直接的な通信を行う通常通信と、接続仲介装置を介して間接的に通信を行う迂回通信と、の２通りの通信方法が用意されているため、端末装置間の直接通信に問題がある場合にも、迂回通信を利用することにより、両者間での通信を支障なく行うことが可能になる。
先願基本発明の第１の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。 図１に示すネットワーク通信システムの端末装置の詳細構成を示すブロック図である。 図２に示す端末装置における自己アドレス通知部２５０の機能を示すブロック図である。 図１に示すネットワーク通信システムにおいて、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の通信セッション確立の手順を示すブロック図である。 図４のブロック図に示されている通信セッション確立手順を時系列で説明する流れ図である。 先願基本発明の第２の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。 図６に示すネットワーク通信システムの端末装置の詳細構成を示すブロック図である。 図６に示すネットワーク通信システムにおいて、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間の通信セッション確立の手順を示すブロック図である。 図８のブロック図に示されている通信セッション確立手順を時系列で説明する流れ図である。 図１もしくは図６に示すアドレステーブルの第１の変形例を示す図である。 図１もしくは図６に示すアドレステーブルの第２の変形例を示す図である。 図１もしくは図６に示すアドレステーブルの第３の変形例を示す図である。 図１に示すネットワーク通信システムにおいて、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の通信セッション確立の手順の変形例を示すブロック図である。 図６に示すネットワーク通信システムにおいて、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間の通信セッション確立の手順の変形例を示すブロック図である。 ルータを介して端末装置をネットワークＮに接続する場合の先願基本発明の実施形態を示すブロック図である。 図１５に示す実施形態において、ＩＰアドレスにポート番号を付加した情報を所在アドレスとして用いる場合のアドレステーブルの例を示す図である。 先願基本発明に係る端末装置を通信アプリケーションプログラムを用いて構成する場合における自己アドレスの通知タイミングを示す表である。 先願基本発明に係るネットワーク通信システムにおいて、ＶＰＮを利用した実施形態の全体構成を示すブロック図である。 図１８に示す実施形態におけるＶＰＮ通信の原理を示す図である。 図１８に示す実施形態に用いるために、ＶＩＰアドレスを追加したアドレステーブルの例を示す図である。 先願基本発明において通信障害が生じる具体例を示すブロック図である。 本発明の実施例１に係るネットワーク通信システムにおける端末装置２０１の詳細構成を示すブロック図である。 本発明の実施例１に係るネットワーク通信システムにおいて、通信元端末装置２０１Ａと通信先端末装置２０１Ｂとの間の通信セッション確立の手順を示すブロック図である。 図２３のブロック図に示されている実施例１における通信セッション確立手順を時系列で説明する流れ図である。 本発明の実施例２に係るネットワーク通信システムにおける端末装置４０２の詳細構成を示すブロック図である。 本発明の実施例２に係るネットワーク通信システムにおいて、通信元端末装置４０２Ｂと通信先端末装置４０２Ａとの間の通信セッション確立の手順を示すブロック図である。 図２６のブロック図に示されている実施例２における通信セッション確立手順を時系列で説明する流れ図である。 本発明の実施例３に係るネットワーク通信システムにおける端末装置２０３の詳細構成を示すブロック図である。 本発明の実施例３に係るネットワーク通信システムにおける通信手順の事前処理を時系列で説明する流れ図である。 図２９に示す事前処理によって作成されるアドレステーブルの一例を示す図である。 本発明の実施例３に係るネットワーク通信システムにおいて、通信元端末装置２０３Ａと通信先端末装置２０３Ｂとの間の通信セッション確立の手順を示すブロック図である。 図３１のブロック図に示されている実施例３における通信セッション確立手順を時系列で説明する流れ図である。 本発明の実施例４に係るネットワーク通信システムにおける端末装置４０４の詳細構成を示すブロック図である。 本発明の実施例４に係るネットワーク通信システムにおいて、通信元端末装置４０４Ｂと通信先端末装置４０４Ａとの間の通信セッション確立の手順を示すブロック図である。 図３４のブロック図に示されている実施例４における通信セッション確立手順を時系列で説明する流れ図である。 本発明の実施例５に係るネットワーク通信システムにおける端末装置２０５の詳細構成を示すブロック図である。 本発明の実施例５に係るネットワーク通信システムにおける通信手順の事前処理を時系列で説明する流れ図である。 図３７に示す事前処理によって作成されるアドレステーブルの一例を示す図である。 本発明の実施例５に係るネットワーク通信システムにおいて、通信元端末装置２０５Ａと通信先端末装置２０５Ｂとの間の通信セッション確立の手順を示すブロック図である。 図３９のブロック図に示されている実施例５における通信セッション確立手順を時系列で説明する流れ図である。 本発明の実施例６に係るネットワーク通信システムにおける端末装置４０６の詳細構成を示すブロック図である。 本発明の実施例６に係るネットワーク通信システムにおいて、通信元端末装置４０６Ｂと通信先端末装置４０６Ａとの間の通信セッション確立の手順を示すブロック図である。 図４２のブロック図に示されている実施例６における通信セッション確立手順を時系列で説明する流れ図である。
以下、本発明を図示する実施形態に基づいて説明する。なお、ここで述べる実施形態は、ＰＣＴ／ＪＰ２０１６／０５５９６０に基づく優先権主張を伴う国際出願ＰＣＴ／ＪＰ２０１７／００６１３１（以下、先願となる国際出願と呼ぶ）に記載された発明（以下、先願基本発明と呼ぶ）を基礎として、この先願基本発明に接続仲介装置を介した迂回通信の機能を付加することにより、「端末装置間の直接通信に支障がある場合にも、両者間での通信を支障なく行うことが可能になる」という固有の付加的な作用効果が得られるようにしたものである。
このような事情から、ここでは、先願基本発明を基礎とした本発明の実施形態を、本発明の好ましい一実施形態として述べることにする。そこで、以下の§１〜§４において、まず、先願基本発明の説明を行い、§５以降において、本発明に固有の特徴について述べることにする。したがって、以下の§１〜§４で述べる内容（図１〜図２０に示す内容）は、実質的に先願となる国際出願ＰＣＴ／ＪＰ２０１７／００６１３１に記載された実施形態と同じものである。
＜＜＜ §１． 先願基本発明の第１の実施形態 ＞＞＞
＜１−１． 先願基本発明の第１の実施形態の構成＞
図１は、先願基本発明の第１の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。図示のとおり、このネットワーク通信システムは、接続仲介装置１００と複数の端末装置２００Ａ〜２００Ｄによって構成されており、これらの各装置はいずれもネットワークＮ（この例では、インターネット）を介して相互に接続することが可能である。
図では、説明の便宜上、４台の端末装置２００Ａ〜２００Ｄを用いた例を示すことにするが、実用上は、より多数の端末装置を利用するのが一般的である。各端末装置２００Ａ〜２００Ｄは、共通の構成を有する同一の装置である。そこで、ここでは、この共通の端末装置について言及する場合は符号２００を用いて示し、相互に区別する必要がある場合には、符号末尾にＡ〜Ｄを付して示すことにする。端末装置２００の内部構成要素を示す各符号についても同様である。
結局、このネットワーク通信システムは、ネットワークＮを介して相互に接続可能な複数の端末装置２００Ａ〜２００Ｄと、これら複数の端末装置間の接続を仲介する接続仲介装置１００と、を備えたシステムということになる。端末装置２００としては、パソコン、携帯電話、タブレット型端末など、ネットワークＮに接続して通信を行う機能を有する様々な電子機器を利用することができる。一方、接続仲介装置１００は、これら各端末装置２００Ａ〜２００ＤからネットワークＮを介してアクセスを受けるサーバコンピュータによって構成されている。
各端末装置２００Ａ〜２００Ｄには、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置１００は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。ここでは、図示のとおり、端末装置２００Ａ，２００Ｂ，２００Ｃ，２００Ｄには、それぞれ「００１０」，「００２０」，「００３０」，「００４０」なる端末ＩＤが付与されているものとする。
なお、先願基本発明を実施する上で、端末ＩＤは、個々の端末装置を相互に識別することができる情報であれば、どのような情報であってもかまわない。図示の例では、４台の端末装置しか用いられていないため、「００１０」のような４桁の数字を端末ＩＤとして用いれば十分であるが、各端末装置を相互に識別するためには、ユニークなＩＤを用いる必要があるので、実用上は、より桁数の多い数字もしくは数字とアルファベットの組み合わせを用いるのが好ましい。具体的には、個々の端末装置に内蔵されているＣＰＵのシリアル番号、通信インターフェイスに付与されたＭＡＣアドレス、携帯電話を端末装置として用いる場合は電話番号やＳＩＭカードのシリアル番号、などを端末ＩＤとして用いることが可能である。
各端末装置２００Ａ〜２００Ｄには、それぞれ自己のネットワーク上での所在を示す所在アドレスが付与されている。図示の例の場合、端末装置２００Ａ，２００Ｂ，２００Ｃ，２００Ｄには、それぞれＡＤ１，ＡＤ２，ＡＤ３，ＡＤ４なる所在アドレスが付与されている。所在アドレスとしては、ネットワーク上で当該端末装置の所在を一義的に決定できるアドレスであれば、どのようなアドレスを用いてもよい。図示の例のように、ネットワークＮとしてインターネットを用い、通信プロトコルとしてＩＰを利用する場合は、個々の端末装置２００のネットワークＮ上での所在を示す所在アドレスとして、グローバルＩＰアドレスもしくはＮＡＴ−ＩＤを用いるのが好ましい。
端末ＩＤが、個々の端末装置を相互に識別するために必要な情報であるのに対して、所在アドレスは、ネットワークＮを介して個々の端末装置をアクセスするために必要な情報である。しかも多くの端末装置の場合、所在アドレスは常に一定ではなく、時事刻々と変化する。たとえば、携帯電話やモバイルパソコンなどの携帯型端末装置の場合、移動とともに交信相手となる基地局が変化するため、所在アドレスも時間的に変化する。また、デスクトップ型パソコンのような定点設置型の端末装置の場合も、プロバイダから付与されるＩＰアドレスなどが更新されるため、やはり所在アドレスが時間的に変化するのが一般的である。
後述するように、先願基本発明に用いる端末装置２００は、自己のネットワーク上での所在を示す所在アドレスを、ネットワークＮを介して接続仲介装置１００に通知する機能を有している。このため、接続仲介装置１００は、各端末装置２００Ａ〜２００Ｄの最新アドレスを常に把握することができ、必要に応じて、各端末装置２００Ａ〜２００Ｄにアクセスすることが可能である。
図示のとおり、接続仲介装置１００には、アドレステーブル格納部１１０、アドレステーブル更新部１２０、通信先アドレス返信部１３０が設けられている。前述したとおり、この接続仲介装置１００は、実際には、サーバコンピュータなどのコンピュータによって構成される。したがって、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築されることになる。
アドレステーブル格納部１１０には、各端末装置２００Ａ〜２００Ｄのそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルＴが格納されており、アドレステーブル更新部１２０は、各端末装置２００Ａ〜２００Ｄからの通知に基づいて、このアドレステーブルＴの内容を更新する処理を行う。また、通信先アドレス返信部１３０は、各端末装置２００Ａ〜２００Ｄから接続仲介依頼があると、アドレステーブルＴを参照することにより、通信先アドレスを返信する処理を行う。
図には、アドレステーブルＴとして、４台の端末装置２００Ａ〜２００Ｄのそれぞれについて、端末ＩＤと所在アドレスとの対応関係を示す情報が格納されている。具体的には、端末装置２００Ａについては端末ＩＤ「００１０」と所在アドレス「ＡＤ１」とが対応づけられ、端末装置２００Ｂについては端末ＩＤ「００２０」と所在アドレス「ＡＤ２」とが対応づけられ、端末装置２００Ｃについては端末ＩＤ「００３０」と所在アドレス「ＡＤ３」とが対応づけられ、端末装置２００Ｄについては端末ＩＤ「００４０」と所在アドレス「ＡＤ４」とが対応づけられている。
続いて、図２を参照しながら、端末装置２００の詳細構成および個々の構成要素の具体的な処理動作を説明する。図示のとおり、端末装置２００には、接続仲介依頼部２１０、通信要求受付部２２０、通信先セッション確立部２３０、通信開始要求部２４０、自己アドレス通知部２５０、通信元セッション確立部２６０が設けられている。
この端末装置２００も、実際には、種々のコンピュータ（携帯電話などの機器も含む）によって構成され、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築される。なお、実際の端末装置２００には、この他にも種々の構成要素が組み込まれている。たとえば、端末装置２００がスマートフォンであれば、様々なアプリケーションプログラムを組み込むことにより、様々な処理機能をもった構成要素が付加されることになるが、ここでは、先願基本発明に直接関係する構成要素のみを図にブロックとして示すことにし、その他の構成要素についての説明は省略する。もちろん、端末装置２００には、ユーザからの指示入力や文字入力を行う入力インターフェイスや、ユーザに情報を提示するためのディスプレイなどの構成要素も備わっているが、これらの構成要素についての説明も省略する。
結局、図２において、端末装置２００内に６つのブロックとして描かれている構成要素は、先願基本発明に係る端末装置２００において必須の機能要素ということになる。このブロック図には、各ブロック間の信号の流れを示す矢印として、太線矢印、細線矢印、白抜矢印の３通りの矢印が用いられている。ここで、太線矢印は、端末装置２００と接続仲介装置１００との間でやりとりされる、通信セッション確立前の信号の流れを示しており、細線矢印は、一対の端末装置２００の間でやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置２００の間でやりとりされる、通信セッション確立後の信号の流れを示している。
また、図２では、端末装置２００内の６つの構成要素が、楕円、矩形、二重矩形という３通りのブロックを用いて描かれているが、これは、各構成要素の役割分担を示すための便宜である。具体的には、楕円ブロックで示されている構成要素は、端末装置２００が「アドレス通知」の処理を実行するための構成要素であり、矩形ブロックで示されている構成要素は、端末装置２００が「通信元」として機能する場合に必要な処理を実行する構成要素であり、二重矩形ブロックで示されている構成要素は、端末装置２００が「通信先」として機能する場合に必要な処理を実行する構成要素である。
本願において、「通信元」および「通信先」という用語は、２台の端末装置が相互に通信を行う場合に、これら２台を区別するために用いる用語であり、自発的に通信を開始するための処理を行う側を「通信元」と呼び、この「通信元」からの働きかけに応じて、当該「通信元」と通信を行うために必要な処理を行う側を「通信先」と呼んでいる。たとえば，２台の端末装置を電話として使う場合、発呼側の装置が「通信元」であり、着呼側の装置が「通信先」になる。「通信元」の端末装置は、特定の「通信先」を指定して、自発的に通信を開始するための処理を行うことになる。
もちろん、端末装置２００は、「通信元」になったり「通信先」になったりする。「通信元」になったときには、図２に矩形ブロックで示されている構成要素による処理が行われ、「通信先」になったときには、図２に二重矩形ブロックで示されている構成要素による処理が行われる。以下、端末装置２００の６つの構成要素の各機能を順に説明する。
上述したように、楕円ブロックで示されている自己アドレス通知部２５０は、「アドレス通知」の処理を実行するための構成要素であり、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１００に対して通知する処理を実行する。所在アドレスとしてＩＰアドレスを用いるのであれば、自己アドレス通知部２５０は、現時点で自己に付与されたＩＰアドレスをネットワークＮを介して接続仲介装置１００に通知する処理を行うことになる。
通常、インターネットに接続可能な端末装置２００には、インターネットプロバイダから所定のグローバルＩＰアドレスが付与されるので、自己アドレス通知部２５０は、端末装置２００に付与されたグローバルＩＰアドレスを、所在アドレスとして接続仲介装置１００に対して通知すればよい。また、ルータのＮＡＴ機能を利用して、プライベートＩＰアドレスが付与されている場合には、ＮＡＴ−ＩＤを所在アドレスとして接続仲介装置１００に対して通知すればよい。所在アドレスを通知する際には、端末ＩＤを同時に送信するようにする。
図１に示すアドレステーブル更新部１２０は、このような通知を受けて、アドレステーブルＴの更新を行う。たとえば、端末装置２００Ａから接続仲介装置１００に対して、端末ＩＤ「００１０」と所在アドレス「ＡＤ１」とが通知された場合、アドレステーブル更新部１２０は、端末ＩＤ「００１０」と所在アドレス「ＡＤ１」とを対応づけてアドレステーブルＴに格納する処理を行う。
前述したとおり、一般的な端末装置２００の場合、所在アドレスが時間的に変化する。したがって、実用上は、自己アドレス通知部２５０には、所定周期で繰り返して、現時点の自己（端末装置２００）の所在アドレスを通知する機能をもたせておくのが好ましい。たとえば、自己アドレス通知部２５０が１分おきに繰り返し通知を行うようにすれば、アドレステーブルＴは１分おきに最新の情報に更新されることになる。
あるいは、自己アドレス通知部２５０には、自己（端末装置２００）の所在アドレスが変更になったときに、現時点の所在アドレスを通知する機能をもたせておくようにしてもよい。すなわち、初めて所在アドレスが付与された段階で、当該所在アドレスを初期状態のアドレスとして通知させ、その後は、所在アドレスが変更になるたびに新たな所在アドレスを通知させるようにすればよい。もちろん、所定周期で繰り返し通知する運用と、所在アドレスが変更になったときに通知する運用とを組み合わせてもかまわない。
次に、図２に矩形ブロックで示されている４つの構成要素について説明する。上述したように、これら４つの構成要素は、端末装置２００が「通信元」として機能する場合に必要な処理を実行する。
まず、通信要求受付部２２０は、自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける処理を行う。たとえば、端末装置２００（通信元）のユーザが、特定の相手に電話をかけたい場合、当該相手が所持する別な端末装置（通信先）に対して通信を行いたい旨の通信要求を行うことになる。この通信要求は、たとえば、図示されていない入力インターフェイスを介したユーザの操作入力（たとえば、タッチパネル上での操作）として与えられ、相手先の端末装置を特定するための何らかの情報を含むものになる。
接続仲介依頼部２１０は、通信要求受付部２２０によって通信要求が受け付けられたときに、接続仲介装置１００に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する。ここで、接続仲介依頼に含まれる通信先特定情報は、通信先の別な端末装置の端末ＩＤであってもよいし、当該端末ＩＤを特定することが可能な別な情報であってもかまわない（詳細は、§３−１で述べる）。
こうして、接続仲介依頼部２１０から送信された接続仲介依頼は、ネットワークＮを介して接続仲介装置１００へと伝達される（前述したように、図における太線矢印は、端末装置２００と接続仲介装置１００との間でやりとりされる、通信セッション確立前の信号の流れを示している）。すると、接続仲介装置１００からは、図に太線矢印で示すように、通信先となる別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてくる。これは、図１に示す通信先アドレス返信部１３０の機能によるものである。
すなわち、通信先アドレス返信部１３０は、端末装置２００の接続仲介依頼部２１０から、接続仲介依頼が送信されてきたときに、アドレステーブルＴを参照して、接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスを通信先アドレスとして返信する処理を行う。もちろん、返信の相手先は、接続仲介依頼を行った端末装置２００である。要するに、通信先アドレス返信部１３０は、通信元の端末装置から通信先を特定した接続仲介依頼があると、アドレステーブルＴを用いて、当該通信先の現時点での所在アドレスを検索し、これを通信元の端末装置に返信する処理を行うことになる。
このように、接続仲介依頼部２１０によって接続仲介依頼を行うと、接続仲介装置１００からは、通信先の別な端末装置のネットワーク上での所在を示す通信先アドレスが返信されてくる。こうして返信されてきた通信先アドレスは、通信開始要求部２４０によって受信される。通信開始要求部２４０は、この通信先アドレスにネットワークＮを介してアクセスして通信開始要求を行う。図に細線矢印で示すとおり、この通信開始要求は、１台の端末装置２００（通信元）から別な１台の端末装置２００（通信先）に宛てた信号ということになる。
このように、通信開始要求部２４０によって、通信先の別な端末装置に対して通信開始要求を送信すると、当該通信先の別な端末装置からは、この通信開始要求に応じて、通信開始受諾確認が返信されてくる（図の右側の細線矢印：この返信処理については、通信先の別な端末装置の通信先セッション確立部２３０の処理として後述する）。こうして返信されてきた通信開始受諾確認は、通信元セッション確立部２６０によって受信される。通信元セッション確立部２６０は、この通信開始受諾確認を受信したら、当該通信先の別な端末装置との間に通信セッションを確立して通信を開始する。図２の右端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
以上、図２に矩形ブロックで示されている４つの構成要素、すなわち、端末装置２００が「通信元」として機能する場合に処理を実行する構成要素について説明したが、続いて、図２に二重矩形ブロックで示されている構成要素、すなわち、端末装置２００が「通信先」として機能する場合に処理を実行する構成要素について説明する。
図２において、二重矩形ブロックで示されている構成要素は、通信先セッション確立部２３０である。この通信先セッション確立部２３０は、通信元の別な端末装置から、自己を通信先とする通信開始要求がなされたら（図の左側の下向き細線矢印）、当該通信元の別な端末装置に対して通信開始受諾確認を送信し（図の左側の上向き細線矢印）、当該通信元の別な端末装置との間に通信セッションを確立して通信を開始する。図２の左端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
結局、通信元端末装置と通信先端末装置との間の通信セッション確立後の通信は、通信元端末装置の通信元セッション確立部２６０と通信先端末装置の通信先セッション確立部２３０との間で行われることになる。別言すれば、図２の右端の白抜矢印は、ネットワークＮを介して、図２の左端の白抜矢印に連なることになる。
＜１−２． 第１の実施形態における具体的な通信手順＞
これまで、図１および図２を参照しながら、先願基本発明の第１の実施形態に係るネットワーク通信システムの構成要素である接続仲介装置１００および端末装置２００の各構成要素およびその機能を説明した。ここでは、この第１の実施形態に係るネットワーク通信システムにおける通信手順を、具体例に即して説明することにする。
図３は、図２に示す端末装置における自己アドレス通知部２５０の機能を示すブロック図である。図の上段には接続仲介装置１００が示され、図の下段には２組の端末装置２００Ａ，２００Ｂが示されている。ここでは、端末装置２００Ｃ，２００Ｄの図示は省略するが、自己アドレス通知部２５０の機能は同じである。なお、前述したとおり、接続仲介装置１００と各端末装置２００Ａ，２００Ｂとの間の情報のやりとり（太線矢印で示す）は、実際にはネットワークＮを介して行われるが、ここでは説明の便宜上、ネットワークＮの図示は省略する。
図３に示す端末装置２００Ａ，２００Ｂは、図２に示す端末装置２００と同様に６つの構成要素を有している。すなわち、端末装置２００Ａは、構成要素２１０Ａ〜２６０Ａを有し、端末装置２００Ｂは、構成要素２１０Ｂ〜２６０Ｂを有しており、これら各構成要素は、図２に示す構成要素２１０〜２６０と同一のものである（符号末尾のＡ，Ｂは、いずれの端末装置の構成要素であるかを区別するために付したものである）。なお、この図３は、端末装置２００Ａ，２００Ｂの自己アドレス通知機能を説明するための図であるので、自己アドレス通知部２５０Ａ，２５０Ｂ以外の構成要素のブロックは破線で示してある。
自己アドレス通知部２５０Ａ，２５０Ｂは、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１００内のアドレステーブル更新部１２０に対して通知する処理を行う。図３には、自己アドレス通知部２５０Ａからアドレステーブル更新部１２０への通知として、「００１０：ＡＤ１」なるデータが送信されている例が示されているが、これは、自己の端末ＩＤ「００１０」とともに自己の現時点での所在アドレス「ＡＤ１」を送信していることを示している。同様に、自己アドレス通知部２５０Ｂからアドレステーブル更新部１２０への通知として、「００２０：ＡＤ２」なるデータが送信されている例が示されているが、これは、自己の端末ＩＤ「００２０」とともに自己の現時点での所在アドレス「ＡＤ２」を送信していることを示している。
各端末装置２００Ａ，２００Ｂの自己アドレス通知部２５０Ａ，２５０Ｂから、このような通知を受けたアドレステーブル更新部１２０が、当該通知に基づいて、アドレステーブルＴの内容を更新する処理を行う点は、既に§１−１で述べたとおりである。また、自己アドレス通知部２５０Ａ，２５０Ｂが、所定周期で繰り返して、もしくは、所在アドレスが変更になったときに、現時点の所在アドレスを通知する処理を行う点も§１−１で述べたとおりである。
このように、自己アドレス通知部２５０が行う所在アドレスの通知処理は、端末装置間の通信を開始するための直接的な処理ではないが、いつでも通信を開始できるようにするための準備処理ということができる。この通知処理を行うことにより、接続仲介装置１００内のアドレステーブルＴを最新の状態に保つことができ、実際に、特定の端末装置間で通信を行う必要が生じたときに、接続仲介装置１００による正しい仲介処理が実現できるのである。
続いて、特定の端末装置間で実際に通信を開始する際の処理手順を説明する。図４は、図１に示すネットワーク通信システムにおいて、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間の通信セッション確立の手順を示すブロック図である。この図４においても、図の上段には接続仲介装置１００が示され、図の下段には２組の端末装置２００Ａ，２００Ｂが示されている。ここでも、接続仲介装置１００と端末装置２００Ａとの間の情報のやりとり（太線矢印で示す）や、端末装置２００Ａ，２００Ｂ間の情報のやりとり（細線矢印で示す）は、実際にはネットワークＮを介して行われるが、説明の便宜上、ネットワークＮの図示は省略する。
また、ここでは、説明の便宜上、端末装置２００Ａを通信元、端末装置２００Ｂを通信先とした場合の手順を説明する。このため、図４では、通信元端末装置２００Ａ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）のみを実線で示し、通信先端末装置２００Ｂ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）のみを実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。
一方、図５は、図４のブロック図に示されている通信セッション確立手順を時系列で説明する流れ図である。以下、図４のブロック図を参照しながら、図５の流れ図に従って、第１の実施形態における具体的な通信手順を説明する。なお、図４のブロック図において、各矢印に付された符号Ｓ１〜Ｓ７は、図５の流れ図における各ステップＳ１〜Ｓ７に対応するものである。逆に、図５の流れ図の各ステップにおいて、括弧書きで示された符号は、図４のブロック図における特定のブロックに対応するものであり、当該ステップの内容に関連する特定の構成要素を示すものである。
まず、ステップＳ１において、通信要求受付処理が行われる。これは、図４に示す通信要求受付部２２０Ａによって行われる処理であり、たとえば、通信元端末装置２００ＡのユーザＡが、通信先端末装置２００ＢのユーザＢに対して電話をしたい、という場合に、ユーザＡの操作入力に基づいて行われる処理である。たとえば、各端末装置２００Ａ，２００Ｂが携帯電話であり、端末ＩＤとして、それぞれの電話番号を用いている場合は、ユーザＡは端末装置２００Ａに対して、端末装置２００Ｂの端末ＩＤ（電話番号）を入力する操作を伴う通信要求Ｓ１を行えばよい。すなわち、端末装置２００Ａの通信要求受付部２２０Ａは、自己を通信元として、通信先の別な端末装置２００Ｂに対する通信要求Ｓ１を受け付ける処理を行うことになる。
なお、通信要求受付部２２０Ａが通信要求Ｓ１を受け付けるのは、必ずしもユーザＡが電話をかけるための操作入力を行った場合に限られるわけではない。たとえば、ユーザＡ，Ｂが通信対戦型のゲームをプレイしている場合は、当該ゲーム用のアプリケーションプログラムから通信要求受付部２２０Ａに対して通信要求Ｓ１が与えられることになる。あるいは、端末装置２００Ａ，２００Ｂが何らかのビジネス処理を行うパソコンであり、パソコン２００Ａに組み込まれたビジネス処理用のアプリケーションプログラムが、パソコン２００Ｂに対して自動的に定時報告を行うような場合、当該アプリケーションプログラムから通信要求受付部２２０Ａに対して通信要求Ｓ１が与えられることになる。このように、先願基本発明における通信要求は、必ずしもユーザによって与えられるものではなく、端末装置に組み込まれているプログラムによって与えられる場合もある。
こうして、ステップＳ１において通信要求受付が行われると、続くステップＳ２において、接続仲介依頼が行われる。これは、図４に示す接続仲介依頼部２１０Ａによって行われる処理であり、既に述べたとおり、接続仲介装置１００に対して、通信先の別な端末装置２００Ｂの端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼Ｓ２を送信する処理である。
なお、一般に、ネットワークを介して接続された二者間で情報の送受を行う場合、情報の送信側は自分のアドレスを受信側に伝達し、受信側は当該送信側アドレス宛にアクノレッジ信号を返信する処理を行う。したがって、接続仲介依頼部２１０Ａから接続仲介依頼Ｓ２を送信する際には、自己の所在アドレス「ＡＤ１」が接続仲介装置１００側に伝達されることになる。後述するステップＳ４における返信処理は、この所在アドレス「ＡＤ１」宛に行われる。
こうして、通信元端末装置２００Ａの接続仲介依頼部２１０Ａから、接続仲介装置１００へ接続仲介依頼が送信されてくると、ステップＳ３において、この接続仲介依頼を受けた通信先アドレス返信部１３０が、アドレステーブル格納部１１０に格納されているアドレステーブルを参照して、当該接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤ（この例では、「００２０」）に対応づけられている所在アドレスを通信先アドレスとして認識する。たとえば、その時点におけるアドレステーブルＴが、図１に示すようなものであったとすると、端末ＩＤ「００２０」に対応づけられているアドレス「ＡＤ２」が通信先アドレスとして認識される。
そこで、ステップＳ４において、通信先アドレス返信部１３０が、ステップＳ３で認識した通信先アドレス「ＡＤ２」を返信する処理を行う。もちろん、返信相手は、ステップＳ２において接続仲介依頼を行った通信元端末装置２００Ａである。前述したとおり、接続仲介依頼Ｓ２には通信元端末装置２００Ａの所在アドレス「ＡＤ１」の情報が含まれているので、通信先アドレス返信部１３０は、当該所在アドレス「ＡＤ１」宛に、通信先アドレス「ＡＤ２」を返信することができる。
こうして、通信先アドレス返信部１３０から通信先アドレス返信Ｓ４（通信先アドレス「ＡＤ２」を伝達する情報）が送信されてくると、当該通信先アドレス返信Ｓ４は、通信開始要求部２４０Ａによって受信される。結局、通信元端末装置２００Ａが、接続仲介装置１００に対して接続仲介依頼Ｓ２を行うと、この接続仲介依頼Ｓ２に応じて、接続仲介装置１００から、通信先端末装置２００Ｂのネットワーク上での所在を示す通信先アドレス「ＡＤ２」が返信されてくることになる。接続仲介装置１００に用意されているアドレステーブルＴは、常に最新の状態に更新されているので、返信されてきた通信先アドレス「ＡＤ２」は、通信先端末装置２００Ｂの最新の所在アドレスということになる。
そこで、この通信先アドレス返信Ｓ４により、通信先アドレス「ＡＤ２」を取得した通信開始要求部２４０Ａは、ステップＳ５において、通信先端末装置２００Ｂに対して通信開始要求Ｓ５を行う。すなわち、ネットワークＮを介して、通信先アドレス「ＡＤ２」宛にアクセスを行い、相手方に通信開始の要求を伝える。このとき、自己の所在アドレス（通信元アドレス「ＡＤ１」）も併せて伝達されることになる。
通信先アドレス「ＡＤ２」宛に行われた通信開始要求Ｓ５は、通信先端末装置２００Ｂの通信先セッション確立部２３０Ｂによって受信される。通信先セッション確立部２３０Ｂは、通信元端末装置２００Ａから、自己（端末装置２００Ｂ）を通信先とする通信開始要求Ｓ５がなされたら、まず、ステップＳ６において、ネットワークＮを介して通信元端末装置２００Ａに対して通信開始受諾確認Ｓ６を送信する。そして、続くステップＳ７において、通信元端末装置２００Ａとの間に通信セッションを確立して通信Ｓ７を開始する。
一方、通信元端末装置２００Ａ宛に送信されてきた通信開始受諾確認Ｓ６は、通信元セッション確立部２６０Ａによって受信される。そして、ステップＳ７では、この通信開始受諾確認Ｓ６を受信した通信元セッション確立部２６０Ａが、通信先端末装置２００Ｂとの間に通信セッションを確立して通信Ｓ７を開始する処理も行われる。要するに、通信元端末装置２００Ａ側では、通信開始要求Ｓ５に応じて、通信先端末装置２００Ｂから通信開始受諾確認Ｓ６が返信されてきたら、当該通信先端末装置２００Ｂとの間に通信セッションを確立して通信を開始する処理を行うことになる。
かくして、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間に通信セッションが確立され、両者間での通信Ｓ７が行われることになる。この図５に示す流れ図において、接続仲介装置１００が行った処理は、ステップＳ３のアドレステーブル参照処理とステップＳ４の通信先アドレス返信処理だけである。すなわち、接続仲介装置１００が行う仲介処理は、通信元端末装置２００Ａからの接続仲介依頼Ｓ２を受けて、アドレステーブルＴを参照し（ステップＳ３）、得られた通信先アドレスを通信元端末装置２００Ａに対して返信する（ステップＳ４）だけである。接続仲介装置１００がこのような仲介処理を行うだけで、通信元端末装置２００Ａと通信先端末装置２００Ｂとの間に通信セッションが確立され、両者間での通信が開始することになる。
このように、先願基本発明の第１の実施形態に係るネットワーク通信システムでは、接続仲介装置１００の処理負荷は極めて軽くなる。前述したように、ＳＩＰを利用して両端末間の接続仲介処理を行うシステムでは、従来型の中継処理に比べれば、その処理負荷は軽減されることになるが、両端末間にセッションが確立するまで関与する必要があり、多数の端末装置からの仲介依頼が集中すると、その処理負荷はかなり重くなってくる。これに対して、先願基本発明の第１の実施形態に係るシステムの場合、接続仲介装置１００は、両端末間に通信セッションが確立するまで関与する必要はなく、通信元端末装置に対して通信先アドレスを伝達する処理を行えば足りる。このため、一対の端末装置間の接続を仲介する際の処理負荷を、より軽減することが可能になる。
このように、先願基本発明の第１の実施形態に係るネットワーク通信システムでは、接続仲介装置１００が通信セッション確立まで関与しないため、接続仲介装置１００は、両端末装置間に通信セッションが確立し、支障なく通信が行われているか否かを把握することはできない。そこで、もし必要があれば、通信セッション確立後に、通信元セッション確立部２６０Ａもしくは通信先セッション確立部２３０Ｂから接続仲介装置１００に対して、支障なく通信セッションが確立した旨の報告を行うようにしてもよい。
なお、上述の実施例では、通信先セッション確立部２３０Ｂが、通信元端末装置２００Ａから、自己を通信先とする通信開始要求Ｓ５がなされた時に、ステップＳ６において、当該通信元端末装置２００Ａに対して通信開始受諾確認を送信する、という説明を行ったが、場合によっては、通信開始要求Ｓ５を受諾せずに拒絶し、通信開始受諾確認を送信しないようにしてもよい（あるいは、通信開始受諾確認の代わりに、通信開始拒絶通知を送信するようにしてもよい）。すなわち、通信先セッション確立部２３０Ｂに何らかの条件判断機能をもたせておき、通信開始要求Ｓ５がなされた場合、所定の条件を満たしている場合に限り、通信開始受諾確認を送信する処理を行わせるようにすればよい。
たとえば、通信先端末装置２００ＢのユーザＢが、通信先セッション確立部２３０に対して、着信拒否の設定を行えるようにし、「着信拒否の設定がなされていない」という条件を満たす場合にのみ、通信開始受諾確認を送信する処理が行われるようにすればよい。また、通信開始要求Ｓ５に、通信元端末装置２００Ａを特定するための何らかの通信元特定情報（たとえば、端末ＩＤ）を含ませるようにしておけば、通信先セッション確立部２３０Ｂは、通信開始要求Ｓ５を行った通信元に応じて、当該要求を受諾したり拒絶したりする処理が可能になる。
たとえば、通信先セッション確立部２３０Ｂに、通信開始要求Ｓ５を常に拒絶する通信元リスト（いわゆるブラックリスト）や通信開始要求Ｓ５を常に受諾する通信元リスト（いわゆるホワイトリスト）を用意しておけば、通信先セッション確立部２３０Ｂは、当該リストを参照することにより、通信開始要求Ｓ５を受諾するか拒絶するかの判断を行うことができる。
また、§３−３で述べるように、セキュリティを向上させる変形例を採用する場合は、通信開始要求Ｓ５に何らかのセキュリティ上の問題が存在する場合には、これを拒絶する運用を採用することも可能である。
＜＜＜ §２．先願基本発明の第２の実施形態 ＞＞＞
＜２−１． 先願基本発明の第２の実施形態の構成＞
続いて、先願基本発明の第２の実施形態を説明する。図６は、この第２の実施形態に係るネットワーク通信システムの全体構成を示すブロック図である。図示のとおり、このネットワーク通信システムは、接続仲介装置３００と複数の端末装置４００Ａ〜４００Ｄによって構成されており、これらの各装置はいずれもネットワークＮ（この例では、インターネット）を介して相互に接続することが可能である。
ここでも、説明の便宜上、４台の端末装置４００Ａ〜４００Ｄを用いた例を示すことにするが、実用上は、より多数の端末装置を利用するのが一般的である。各端末装置４００Ａ〜４００Ｄは、共通の構成を有する同一の装置であり、この共通の端末装置について言及する場合は符号４００を用いて示し、相互に区別する必要がある場合には、符号末尾にＡ〜Ｄを付して示すことにする。端末装置４００の内部構成要素を示す各符号についても同様である。
この図６に示すネットワーク通信システムは、ネットワークＮを介して相互に接続可能な複数の端末装置４００Ａ〜４００Ｄと、これら複数の端末装置間の接続を仲介する接続仲介装置３００と、を備えたシステムということになる。やはり端末装置４００としては、パソコン、携帯電話、タブレット型端末など、ネットワークＮに接続して通信を行う機能を有する様々な電子機器を利用することができる。また、接続仲介装置３００は、これら各端末装置４００Ａ〜４００ＤからネットワークＮを介してアクセスを受けるサーバコンピュータによって構成されている。
各端末装置４００Ａ〜４００Ｄには、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置３００は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。端末ＩＤとしては、前述したとおり、個々の端末装置を相互に識別することができる情報であれば、どのような情報を利用してもかまわない。ここでは、前述した第１の実施形態の場合と同様に、端末装置４００Ａ，４００Ｂ，４００Ｃ，４００Ｄには、それぞれ「００１０」，「００２０」，「００３０」，「００４０」なる端末ＩＤが付与されているものとする。
また、各端末装置４００Ａ〜４００Ｄには、それぞれ自己のネットワーク上での所在を示す所在アドレスが付与されている。ここでも、前述した第１の実施形態の場合と同様に、端末装置４００Ａ，４００Ｂ，４００Ｃ，４００Ｄに、それぞれＡＤ１，ＡＤ２，ＡＤ３，ＡＤ４なる所在アドレスが付与されているものとする。この所在アドレスは、ネットワーク上で当該端末装置の所在を一義的に決定できるアドレスであれば、どのようなアドレスを用いてもよいが、実用上は、グローバルＩＰアドレスもしくはＮＡＴ−ＩＤを用いればよい。前述したとおり、この所在アドレスは、時間的に変化する。
図示のとおり、接続仲介装置３００には、アドレステーブル格納部３１０、アドレステーブル更新部３２０、通信元アドレス送信部３３０が設けられている。この接続仲介装置３００は、実際には、サーバコンピュータなどのコンピュータによって構成される。したがって、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築されることになる。
アドレステーブル格納部３１０は、図１に示すアドレステーブル格納部１１０と同じ構成要素であり、各端末装置４００Ａ〜４００Ｄのそれぞれについて、端末ＩＤと所在アドレスとを対応づけたアドレステーブルＴを格納する機能を有する。図６に示すアドレステーブルＴは、図１に示すアドレステーブルＴと全く同じものである。アドレステーブル更新部３２０は、図１に示すアドレステーブル更新部１２０と同じ構成要素であり、各端末装置４００Ａ〜４００Ｄからの通知に基づいて、アドレステーブルＴの内容を更新する処理を行う。このように、図６に示す構成要素３１０，３２０は、実質的に図１に示す構成要素１１０，１２０と同じものであるため、ここでは詳細な説明は省略する。
一方、通信元アドレス送信部３３０は、図１に示す通信先アドレス返信部１３０に類似した機能を有する構成要素であるが、若干異なる動作を行う。すなわち、通信元アドレス送信部３３０は、各端末装置４００Ａ〜４００Ｄから接続仲介依頼があると、アドレステーブルＴを参照することにより通信先アドレスを認識し、当該通信先アドレス宛に、通信元アドレスを送信する処理を行う。この処理のより詳細な説明は後述する。
続いて、図７を参照しながら、端末装置４００の詳細構成および個々の構成要素の具体的な処理動作を説明する。図示のとおり、端末装置４００には、接続仲介依頼部４１０、通信要求受付部４２０、通信元セッション確立部４３０、通信開始要求部４４０、自己アドレス通知部４５０、通信先セッション確立部４６０が設けられている。
この端末装置４００も、実際には、種々のコンピュータ（携帯電話などの機器も含む）によって構成され、図に個々のブロックとして示されている各構成要素は、実際には、コンピュータに専用のプログラムを組み込むことにより構築される。もちろん、この端末装置４００にも、必要に応じて、図示されていない種々の構成要素や入出力インターフェイスが組み込まれているが、ここでは、先願基本発明に直接関係する構成要素のみを図にブロックとして示すことにし、その他の構成要素についての説明は省略する。
この図７においても、図２と同様に、各ブロック間の信号の流れを示す太線矢印は、端末装置４００と接続仲介装置３００との間でやりとりされる、通信セッション確立前の信号の流れを示しており、細線矢印は、一対の端末装置４００の間でやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置４００の間でやりとりされる、通信セッション確立後の信号の流れを示している。
また、図２と同様に、図７に楕円ブロックで示されている構成要素は、端末装置４００が「アドレス通知」の処理を実行するための構成要素であり、矩形ブロックで示されている構成要素は、端末装置４００が「通信元」として機能する場合に必要な処理を実行する構成要素であり、二重矩形ブロックで示されている構成要素は、端末装置４００が「通信先」として機能する場合に必要な処理を実行する構成要素である。端末装置４００が、「通信元」になったときには、図７に矩形ブロックで示されている構成要素による処理が行われ、「通信先」になったときには、図７に二重矩形ブロックで示されている構成要素による処理が行われる。以下、図７に示す端末装置４００の６つの構成要素の各機能を順に説明する。
まず、楕円ブロックで示されている自己アドレス通知部４５０は、「アドレス通知」の処理を実行するための構成要素であり、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置３００に対して通知する処理を実行する。この自己アドレス通知部４５０の機能は、図２に示す自己アドレス通知部２５０の機能と全く同じであるため、ここでは詳しい説明は省略する。図６に示すアドレステーブル更新部３２０は、この通知を受けて、アドレステーブルＴの更新を行う。
次に、図７に矩形ブロックもしくは二重矩形ブロックで示されている５つの構成要素について説明する。上述したように、矩形ブロックで示されている３つの構成要素は、端末装置４００が「通信元」として機能する場合に必要な処理を実行し、二重矩形ブロックで示されている２つの構成要素は、端末装置４００が「通信先」として機能する場合に必要な処理を実行する。
まず、通信要求受付部４２０は、自己を通信元として、通信先の別な端末装置に対する通信要求を受け付ける処理を行う構成要素であり、図２に示す通信要求受付部２２０と全く同じ機能をもつ構成要素である。また、接続仲介依頼部４１０は、通信要求受付部４２０によって通信要求が受け付けられたときに、接続仲介装置３００に対して、通信先の別な端末装置の端末ＩＤを特定するための通信先特定情報を含む接続仲介依頼を送信する構成要素であり、図２に示す接続仲介依頼部２１０と全く同じ機能をもつ構成要素である。
こうして、接続仲介依頼部４１０から送信された接続仲介依頼は、ネットワークＮを介して接続仲介装置３００へと伝達される（図における太線矢印は、端末装置４００と接続仲介装置３００との間でやりとりされる、通信セッション確立前の信号の流れを示している）。すると、接続仲介装置３００からは、図に太線矢印で示すように、通信元アドレスが送信されてくる。この通信元アドレスは、通信開始要求部４４０によって受信される。
ここで留意すべき点は、接続仲介装置３００からの通信元アドレスの送信先は、接続仲介依頼を行った通信元の端末装置ではなく、通信先となる別な端末装置である点である。すなわち、図７に示す例において、矩形ブロックで示す接続仲介依頼部４１０は、通信元端末装置内の構成要素であるのに対して、二重矩形ブロックで示す通信開始要求部４４０は、別な通信先端末装置内の構成要素ということになる。したがって、上述の説明において、接続仲介依頼を発する接続仲介依頼部４１０と、これに応じて接続仲介装置３００から送信されてくる通信元アドレスを受信する通信開始要求部４４０とは、それぞれ異なる端末装置４００に所属していることになる。
要するに、図６に示されている通信元アドレス送信部３３０は、ある端末装置４００の接続仲介依頼部から接続仲介依頼が送信されてきたときに、アドレステーブルＴを参照して、当該接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤに対応づけられている所在アドレスに対して、当該接続仲介依頼を送信した通信元の端末装置の端末ＩＤに対応づけられている所在アドレスを通信元アドレスとして送信する処理を行うことになる。
この通信元アドレス送信部３３０の処理機能をより明確にするため、ここでは、図６に示す端末装置４００Ｂを通信元、端末装置４００Ａを通信先とした具体例（たとえば、端末装置４００ＢのユーザＢが発呼側となり、端末装置４００ＡのユーザＡを着呼側として電話をかけたような場合）について、上記手順を説明しよう。
この場合、通信元端末装置４００Ｂから接続仲介装置３００に対して、端末装置４００Ａを通信先として指定する接続仲介依頼が送信されることになる。当該接続仲介依頼を受けた通信元アドレス送信部３３０は、アドレステーブルＴを参照することにより、通信先として指定された端末装置４００Ａの所在アドレス「ＡＤ１」を認識する。前述した第１の実施形態における通信先アドレス返信部１３０は、こうして認識した通信先の所在アドレスを通信元（接続仲介依頼の送信元）に返信する処理を行っていた。これに対して、図６に示す第２の実施形態における通信元アドレス送信部３３０は、認識した通信先の所在アドレス「ＡＤ１」に宛てて、通信元端末装置４００Ｂの所在を示す通信元アドレス「ＡＤ２」（これは、接続仲介依頼の送信元のアドレスとして認識できる）を送信する。
結局、上例の場合、通信元端末装置４００Ｂから接続仲介装置３００に対して接続仲介依頼を行うと、接続仲介装置３００から通信先端末装置４００Ａに対して通信元アドレス（通信元端末装置４００Ｂの所在アドレス「ＡＤ２」）が送信されることになる。ここが、前述した第１の実施形態と大きく異なる点である。
こうして送信されてきた通信元アドレスは、図７に示すとおり、通信先端末装置４００Ａ内の通信開始要求部４４０によって受信される。通信開始要求部４４０は、この通信元アドレス（通信元端末装置４００Ｂのアドレス）に対して通信開始要求を行う。すなわち、通信開始要求部４４０は、接続仲介装置３００から、通信元の別な端末装置のネットワーク上での所在を示す通信元アドレスが送信されてきたときに、ネットワークＮを介して、当該通信元アドレスにアクセスして通信開始要求を行うことになる。図に細線矢印で示すとおり、この通信開始要求は、１台の端末装置４００（通信先）から別な１台の端末装置４００（通信元）に宛てた信号ということになる。
一方、通信先の別な端末装置（上例の場合、端末装置４００Ａ）から通信開始要求がなされた端末装置（上例の場合、端末装置４００Ｂ）は、当該通信開始要求を通信元セッション確立部４３０で受信する（図の左側の下向き細線矢印）。そして、この通信元セッション確立部４３０は、通信先の別な端末装置（上例の場合、端末装置４００Ａ）に対して通信開始受諾確認を返信し（図の左側の上向き細線矢印）、当該通信先の別な端末装置との間に通信セッションを確立して通信を開始する。図７の左端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
こうして、通信元端末装置４００Ｂから通信先端末装置４００Ａに対して返信された通信開始受諾確認は、通信先端末装置４００Ａの通信先セッション確立部４６０によって受信される（図の右側の細線矢印）。通信先セッション確立部４６０は、この通信開始受諾確認を受信したら、通信元の別な端末装置４００Ｂとの間に通信セッションを確立して通信を開始する。図７の右端に描かれた白抜矢印は、このようにして通信セッションが確立した後の両端末間の信号（通信パケット）の流れを示している。
かくして、通信元端末装置と通信先端末装置との間の通信セッション確立後の通信は、通信元端末装置の通信元セッション確立部４３０と通信先端末装置の通信先セッション確立部４６０との間で行われることになる。別言すれば、図７の左端の白抜矢印は、ネットワークＮを介して、図７の右端の白抜矢印に連なることになる。
＜２−２． 第２の実施形態における具体的な通信手順＞
これまで、図６および図７を参照しながら、先願基本発明の第２の実施形態に係るネットワーク通信システムの構成要素である接続仲介装置３００および端末装置４００の各構成要素およびその機能を説明した。ここでは、この第２の実施形態に係るネットワーク通信システムにおける通信手順を、具体例に即して説明することにする。
まず、図７に示す端末装置における自己アドレス通知部４５０の機能であるが、これは図３を用いて説明した自己アドレス通知部２５０Ａ，２５０Ｂの機能と全く同じであるため、ここでは説明を省略する。
そこで以下、特定の端末装置間で実際に通信を開始する際の処理手順を説明する。図８は、図６に示すネットワーク通信システムにおいて、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間の通信セッション確立の手順を示すブロック図である。この図８では、図の上段に接続仲介装置３００が示され、図の下段に２組の端末装置４００Ａ，４００Ｂが示されている。ここでも、接続仲介装置３００と各端末装置４００Ａ，４００Ｂとの間の情報のやりとり（太線矢印で示す）や、端末装置４００Ａ，４００Ｂ間の情報のやりとり（細線矢印で示す）は、実際にはネットワークＮを介して行われるが、説明の便宜上、ネットワークＮの図示は省略する。
また、ここでは、説明の便宜上、端末装置４００Ｂを通信元、端末装置４００Ａを通信先とした場合の手順を説明する。このため、図８では、通信元端末装置４００Ｂ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）のみを実線で示し、通信先端末装置４００Ａ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）のみを実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。
一方、図９は、図８のブロック図に示されている通信セッション確立手順を時系列で説明する流れ図である。以下、図８のブロック図を参照しながら、図９の流れ図に従って、第２の実施形態における具体的な通信手順を説明する。なお、図８のブロック図において、各矢印に付された符号Ｓ１１〜Ｓ１７は、図９の流れ図における各ステップＳ１１〜Ｓ１７に対応するものである。逆に、図９の流れ図の各ステップにおいて、括弧書きで示された符号は、図８のブロック図における特定のブロックに対応するものであり、当該ステップの内容に関連する特定の構成要素を示すものである。
まず、ステップＳ１１において、通信要求受付処理が行われる。これは、図８に示す通信要求受付部４２０Ｂによって通信要求を受け付ける処理であり、図５のステップＳ１で述べた処理と同様であるため説明は省略する。続くステップＳ１２では、この通信要求に基づいて、接続仲介依頼Ｓ１２が行われる。これは、図８に示す接続仲介依頼部４１０Ｂによって行われる処理であり、図５のステップＳ２で述べた処理と同様であるため説明は省略する。
こうして、通信元端末装置４００Ｂの接続仲介依頼部４１０Ｂから、接続仲介装置３００へ接続仲介依頼Ｓ１２（図示の例では、通信先特定情報として、通信先端末装置４００Ａの端末ＩＤ「００１０」が含まれている）が送信されてくると、ステップＳ１３において、この接続仲介依頼Ｓ１２を受けた通信元アドレス送信部３３０が、アドレステーブル格納部３１０に格納されているアドレステーブルを参照して、当該接続仲介依頼に含まれている通信先特定情報によって特定される端末ＩＤ（この例では、「００１０」）に対応づけられている所在アドレスを通信先アドレスとして認識する（Ｓ１３）。たとえば、その時点におけるアドレステーブルＴが、図６に示すようなものであったとすると、端末ＩＤ「００１０」に対応づけられているアドレス「ＡＤ１」が通信先アドレスとして認識される。
そこで、ステップＳ１４において、通信元アドレス返信部３３０が、ステップＳ１３で認識した通信先アドレス「ＡＤ１」宛に、接続仲介依頼Ｓ１２を送信した通信元端末装置４００Ｂの端末ＩＤ「００２０」に対応づけられている所在アドレス「ＡＤ２」を通信元アドレスとして送信する（Ｓ１４）。
前述したとおり、一般に、ネットワークを介して接続された二者間で情報の送受を行う場合、情報の送信側は自分のアドレスを受信側に伝達し、受信側は当該送信側のアドレス宛にアクノレッジ信号を返信する処理を行う。したがって、通信元アドレス送信部３３０は、接続仲介依頼Ｓ１２を受信した時点で、その送信元である端末装置４００Ｂの所在アドレス「ＡＤ２」を認識することができるので、通信元アドレス送信Ｓ１４を行う際には、この認識した所在アドレス「ＡＤ２」をデータとして送信すればよい。
このように、通信元端末装置４００Ｂが、接続仲介装置３００に対して接続仲介依頼Ｓ１２を行うと、この接続仲介依頼Ｓ１２に応じて、接続仲介装置３００から、通信先端末装置４００Ａ宛に（アドレステーブルＴで検索した所在アドレス「ＡＤ１」宛に）、通信元端末装置４００Ｂの所在を示す通信元アドレス「ＡＤ２」が送信されることになる。接続仲介装置３００に用意されているアドレステーブルＴは、常に最新の状態に更新されているので、通信元アドレス送信Ｓ１４は、常に通信先端末装置４００Ａの最新の所在アドレスに対して行われることになる。
こうして、通信元アドレス送信部３３０から通信元アドレス送信Ｓ１４（通信元アドレス「ＡＤ２」を伝達する情報）が送信されてくると、当該通信元アドレス送信Ｓ１４は、通信先端末装置４００Ａの通信開始要求部４４０Ａによって受信される。
この通信元アドレス送信Ｓ１４により、通信元アドレス「ＡＤ２」を取得した通信開始要求部４４０Ａは、ステップＳ１５において、通信元端末装置４００Ｂに対して通信開始要求Ｓ１５を行う。すなわち、ネットワークＮを介して、通信元アドレス「ＡＤ２」宛にアクセスを行い、相手方に通信開始の要求を伝える。このとき、自己の所在アドレス（通信元アドレス「ＡＤ１」）も併せて伝達されることになる。
通信元アドレス「ＡＤ２」宛に行われた通信開始要求Ｓ１５は、通信元端末装置４００Ｂの通信元セッション確立部４３０Ｂによって受信される。通信元セッション確立部４３０Ｂは、通信先端末装置４００Ａから、自己（端末装置４００Ｂ）を通信元とする通信開始要求Ｓ１５がなされたら、まず、ステップＳ１６において、ネットワークＮを介して通信先端末装置４００Ａに対して通信開始受諾確認Ｓ１６を送信する。そして、続くステップＳ１７において、通信先端末装置４００Ａとの間に通信セッションを確立して通信Ｓ１７を開始する。
一方、通信先端末装置４００Ａ宛に送信されてきた通信開始受諾確認Ｓ１６は、通信先セッション確立部４６０Ａによって受信される。そして、ステップＳ１７では、この通信開始受諾確認Ｓ１６を受信した通信先セッション確立部４６０Ａが、通信元端末装置４００Ｂとの間に通信セッションを確立して通信Ｓ１７を開始する処理も行われる。要するに、通信先端末装置４００Ａ側では、通信開始要求Ｓ１５に応じて、通信元端末装置４００Ｂから通信開始受諾確認Ｓ１６が返信されてきたら、当該通信元端末装置４００Ｂとの間に通信セッションを確立して通信を開始する処理を行うことになる。
かくして、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間に通信セッションが確立され、両者間での通信Ｓ１７が行われることになる。この図９に示す流れ図において、接続仲介装置３００が行った処理は、ステップＳ１３のアドレステーブル参照処理とステップＳ１４の通信元アドレス送信処理だけである。すなわち、接続仲介装置３００が行う仲介処理は、通信元端末装置４００Ｂからの接続仲介依頼Ｓ１２を受けて、アドレステーブルＴを参照し（ステップＳ１３）、得られた通信先アドレスに宛てて、通信元アドレスのデータを送信する（ステップＳ１４）だけである。接続仲介装置３００がこのような仲介処理を行うだけで、通信元端末装置４００Ｂと通信先端末装置４００Ａとの間に通信セッションが確立され、両者間での通信が開始することになる。
このように、先願基本発明の第２の実施形態に係るネットワーク通信システムでは、第１の実施形態に係るネットワーク通信システムと同様に、接続仲介装置３００の処理負荷は極めて軽くなる。前述したように、ＳＩＰを利用して両端末間の接続仲介処理を行うシステムでは、従来型の中継処理に比べれば、その処理負荷は軽減されることになるが、両端末間にセッションが確立するまで関与する必要があり、多数の端末装置からの仲介依頼が集中すると、その処理負荷はかなり重くなってくる。これに対して、先願基本発明の第２の実施形態に係るシステムの場合、接続仲介装置３００は、両端末間に通信セッションが確立するまで関与する必要はなく、通信先端末装置に対して通信元アドレスを伝達する処理を行えば足りる。このため、一対の端末装置間の接続を仲介する際の処理負荷を、より軽減することが可能になる。
このように、先願基本発明の第２の実施形態に係るネットワーク通信システムでは、接続仲介装置３００が通信セッション確立まで関与しないため、接続仲介装置３００は、両端末装置間に通信セッションが確立し、支障なく通信が行われているか否かを把握することはできない。そこで、もし必要があれば、通信セッション確立後に、通信元セッション確立部４３０Ｂもしくは通信先セッション確立部４６０Ａから接続仲介装置３００に対して、支障なく通信セッションが確立した旨の報告を行うようにしてもよい。
なお、上述の実施例では、通信先端末装置４００Ａの通信開始要求部４４０Ａが、接続仲介装置３００からの通信元アドレス送信Ｓ１４を受信したときに、ステップＳ１５において、自動的に通信開始要求Ｓ１５を送信しているが、場合によっては、通信開始要求部４４０Ａに何らかの条件判断機能をもたせておき、通信元アドレス送信Ｓ１４を受信したときに、所定の条件を満たしている場合に限り、通信開始要求Ｓ１５を送信するようにしてもよい。あるいは、所定の条件を満たしていない場合には、通信開始要求Ｓ１５の代わりに、通信開始拒絶通知を送信するようにしてもよい。
たとえば、通信開始要求部４４０Ａに、通信開始を常に拒絶する通信元リスト（いわゆるブラックリスト）や通信開始を常に許可する通信元リスト（いわゆるホワイトリスト）を用意しておけば、通信開始要求部４４０Ａは、当該リストを参照することにより、通信元アドレス送信Ｓ１４によって送信されてきた通信元アドレスが、ブラックリストに掲載されていた場合には、通信開始要求Ｓ１５の送信を行わない処理をするか、通信開始拒絶通知を送信する運用を行うことができる。あるいは、通信元アドレスが、ホワイトリストに掲載されていた場合にのみ、通信開始要求Ｓ１５を送信するような運用を行うことも可能である。
また、上述の実施例では、通信元セッション確立部４３０Ｂが、通信先端末装置４００Ａから、自己を通信元とする通信開始要求Ｓ１５がなされた時に、ステップＳ１６において、当該通信先端末装置４００Ａに対して通信開始受諾確認を送信する、という説明を行ったが、場合によっては、通信開始要求Ｓ１５を受諾せずに拒絶し、通信開始受諾確認を送信しないようにしてもよい（あるいは、通信開始受諾確認の代わりに、通信開始拒絶通知を送信するようにしてもよい）。
たとえば、§３−４で述べるように、セキュリティを向上させる変形例を採用する場合は、通信開始要求Ｓ１５に何らかのセキュリティ上の問題が存在する場合には、これを拒絶する運用を採用することも可能である。
＜＜＜ §３． 先願基本発明の第１および第２の実施形態の変形例 ＞＞＞
ここでは、§１で述べた先願基本発明の第１の実施形態および§２で述べた先願基本発明の第２の実施形態について、いくつかの変形例を述べる。
＜３−１． 端末ＩＤに関する変形例＞
これまで述べてきたように、図１の接続仲介装置１００内のアドレステーブル格納部１１０には、アドレステーブルＴが格納されている。図６の接続仲介装置３００内のアドレステーブル格納部３１０も同様である。このアドレステーブルＴは、個々の端末装置のそれぞれについて、端末ＩＤと所在アドレスとを対応づけたテーブルであり、通信先アドレス返信部１３０もしくは通信元アドレス送信部３３０は、受信した接続仲介依頼に含まれている通信先特定情報に基づいてアドレステーブルＴを参照し、通信先の所在アドレスを取得する。
たとえば、図４に示す第１の実施形態の場合、接続仲介依頼Ｓ２には、通信先端末装置２００Ｂの端末ＩＤ「００２０」が通信先特定情報として含まれており、通信先アドレス返信部１３０は、アドレステーブルＴを参照することにより、端末ＩＤ「００２０」に対応する所在アドレス「ＡＤ２」を取得することができる。同様に、図８に示す第２の実施形態の場合、接続仲介依頼Ｓ１２には、通信先端末装置４００Ａの端末ＩＤ「００１０」が通信先特定情報として含まれており、通信元アドレス送信部３３０は、アドレステーブルＴを参照することにより、端末ＩＤ「００１０」に対応する所在アドレス「ＡＤ１」を取得することができる。
このように、これまで述べてきた実施形態では、接続仲介依頼に含ませる通信先特定情報として、通信先端末装置の端末ＩＤを用いていた。この端末ＩＤは、個々の端末装置を相互に識別するための情報であり、具体的には、個々の端末装置に内蔵されているＣＰＵのシリアル番号、通信インターフェイスに付与されたＭＡＣアドレス、携帯電話として機能する端末装置の場合は電話番号やＳＩＭカードのシリアル番号、などを端末ＩＤとして用いることができる。
ただ、一般に、ユーザが、他のユーザの端末装置についての端末ＩＤを記憶することは困難である。したがって、通信要求を行う際に、これらの端末ＩＤを、ユーザ自身に直接入力させることは好ましくない。そこで、実用上は、通信要求を行う際に、端末ＩＤで通信先を指定する代わりに、ユーザＩＤで通信先を指定させるようにするのが好ましい。端末ＩＤが個々の端末装置を識別するためのＩＤであるのに対して、ユーザＩＤは個々のユーザを識別するためのＩＤである。一般的には、ユーザ名やニックネームをユーザＩＤとして用いることができる。
端末ＩＤの代わりにユーザＩＤを用いて通信要求を行うことができるようにするには、通信要求受付部２２０，４２０内に、ユーザＩＤと端末ＩＤとの対応表を用意しておけばよい。そして、ユーザが特定のユーザＩＤ（たとえば、ユーザ名）を指定して通信要求を行ったときに、通信要求受付部２２０，４２０が、用意されている対応表を利用してユーザＩＤを端末ＩＤに変換して接続仲介依頼部２１０，４１０へ引き渡すようにすればよい。そうすれば、接続仲介依頼部２１０，４１０は、端末ＩＤを含む接続仲介依頼を送信することができる。このようなユーザＩＤ（たとえば、ユーザ名）から端末ＩＤ（たとえば、電話番号）への変換処理機能は、一般的な携帯電話に「電話番号登録機能」として備わっている公知の機能であるため、ここでは詳しい説明は省略する。
端末ＩＤの代わりにユーザＩＤを利用できるようにする別な方法として、ユーザＩＤと端末ＩＤとの対応表を接続仲介装置１００，３００側に用意する方法を採ることもできる。たとえば、アドレステーブル格納部１１０，３１０内に、図１や図６に示すアドレステーブルＴの代わりに、図１０に示すようなアドレステーブルＴ１を格納しておくようにする。このアドレステーブルＴ１は、個々の端末装置のそれぞれについて、当該端末装置のユーザを特定するユーザＩＤと、当該端末装置の端末ＩＤと、を対応づける情報を含むテーブルである。
図１０では、説明の便宜上、ユーザＩＤとして、「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」なるネットワーク部で始まるプライベートＩＰアドレスが付与されている。このようなプライベートネットワークを、インターネットＮなどの公衆ネットワークを跨いで拡張する方法として、ＶＰＮの技術が普及している。
図１８は、先願基本発明に係るネットワーク通信システムにおいて、ＶＰＮを利用した実施形態の全体構成を示すブロック図である。ここでは、説明の便宜上、ある企業の東京本社に設定された３台の端末装置２００Ｈ，２００Ｉ，２００Ｊ（端末ＩＤは、それぞれ００８１，００８２，００８３）と、パリ支社に設置された１台の端末装置２００Ｋ（端末ＩＤは、００９１）という合計４台の端末装置によって、ＶＰＮを構築した単純な例を示すことにする。また、東京本社に設置された３台の端末装置２００Ｈ，２００Ｉ，２００Ｊを第１グループに所属する第１の端末装置と呼び、パリ支社に設置された１台の端末装置２００Ｋを第２グループに所属する第２の端末装置と呼ぶことにする。
図示のとおり、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊは、第１のルータＲ１を介してネットワーク（インターネット）Ｎに接続されており、第２の端末装置２００Ｋは、第２のルータＲ２を介してネットワーク（インターネット）Ｎに接続されている。したがって、基本的には、図において第１のルータＲ１より上方に配置されている第１の端末装置２００Ｈ，２００Ｉ，２００Ｊは、第１のルータＲ１が管理する第１のＬＡＮ内のホストということになり、図において第２のルータＲ２より下方に配置されている第２の端末装置２００Ｋは、第２のルータＲ２が管理する第２のＬＡＮ内のホストということになる。
このため、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊには、第１のルータＲ１が管理する第１のＬＡＮ内のプライベートＩＰアドレスが付与され、第２の端末装置２００Ｋには、第２のルータＲ２が管理する第２のＬＡＮ内のプライベートＩＰアドレスが付与されている。また、図１５に示す例と同様に、ＩＰアドレスとともにポート番号も付与されている。
図示の例の場合、第１のＬＡＮについては、クラスＢのプライベートＩＰアドレスが付与されており、第１の端末装置２００Ｈ，２００Ｉ，２００Ｊには、それぞれ「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) に示すアドレステーブルＴ５１の端末ＩＤ「００９１」については、更に、ＶＩＰ欄に「ＶＩＰ（２００Ｋ）」なるＶＩＰアドレスが格納されている。
図２０(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）」なる情報を用いて、特定のポート番号の指定を含む接続仲介依頼を行うことができる。
以上、図１に示す先願基本発明の第１の実施形態（接続仲介装置１００と端末装置２００を用いる実施形態）においてＶＰＮの設定を行い、プライベートネットワークの範囲を仮想的に拡張する例を述べたが、図７に示す先願基本発明の第２の実施形態（接続仲介装置３００と端末装置４００を用いる実施形態）においてＶＰＮの設定を行う場合も同様である。
＜＜＜ §５． 本発明により解決される技術的な問題 ＞＞＞
これまで、国際出願ＰＣＴ／ＪＰ２０１７／００６１３１に記載されている先願基本発明に係るネットワーク通信システムを説明してきた。しかしながら、この先願基本発明に係るシステムには、ネットワーク環境によっては、端末間通信に支障が生じる可能性がある。以下、そのような支障が生じる具体的な事例を説明する。
図２１は、先願基本発明に係るネットワーク通信システムにおいて、通信障害が生じる具体例を示すブロック図である。図には、２組の端末装置２００Ａ，２００Ｂが、それぞれルータＲＡ，ＲＢを介してネットワークＮ（インターネット）に接続されている状態が示されている。このように、ルータを用いて端末装置をネットワークに接続する実施形態の詳細は、§４で述べたとおりである。実用上、多くの端末装置は、図示のようにルータを介してネットワークＮに接続されることになる。
§１で述べた先願基本発明の第１の実施形態の場合、接続仲介装置１００によって両端末間の接続仲介が行われる。図に示す太線矢印、細線矢印、白抜矢印の３通りの矢印は、§１，§２でも用いたように、各ブロック間の信号の流れを示す矢印である。すなわち、太線矢印Ｌ１，Ｌ２は、端末装置２００Ａもしくは２００Ｂと接続仲介装置１００との間でやりとりされる信号を示し、細線矢印Ｌ３は、一対の端末装置２００Ａ，２００Ｂの間で通信セッション確立前にやりとりされる信号の流れを示し、白抜矢印Ｌ４は、一対の端末装置２００Ａ，２００Ｂの間で通信セッション確立後にやりとりされる信号の流れを示している。
実際には、この３種類の矢印Ｌ１〜Ｌ４で示される信号の流れは、いずれもルータおよびネットワークＮを通ることになる。たとえば、太線矢印Ｌ１は、ルータＲＡおよびネットワークＮを通る信号の流れになり、太線矢印Ｌ２は、ルータＲＢおよびネットワークＮを通る信号の流れになる。また、細線矢印Ｌ３および白抜矢印Ｌ４は、ルータＲＡ，ネットワークＮ，ルータＲＢを通る信号の流れになる。
§４で述べたとおり、ルータに接続された端末装置にはプライベートＩＰアドレスＰＩＰが付与されるが、信号がルータを通ってインターネットＮへ向かう際に、グローバルＩＰアドレスＧＩＰに変換される。図示の例の場合、端末装置２００Ａには、ＰＩＰ＝「192.168.2.1」が付与されているが、信号がルータＲＡを通る際に、ＰＩＰ＝「192.168.2.1」は、グローバルＩＰアドレスＧＩＰ＝「xx.5.1.1」に変換されている。同様に、端末装置２００Ｂには、ＰＩＰ＝「192.168.10.1」が付与されているが、信号がルータＲＢを通る際に、ＰＩＰ＝「192.168.10.1」は、グローバルＩＰアドレスＧＩＰ＝「xx.5.7.1」に変換されている。なお、実際には、§４で述べたとおり、ポート番号についても変換が行われるが、ここではポート番号についての説明は省略する。
このように、ルータＲＡ，ＲＢは、ネットワークアドレス変換機能（ＮＡＴ（Network Address Translation）機能）を有しており、内側（図におけるルータＲＡ，ＲＢの下側）に接続された通信路について付与されたプライベートＩＰアドレスを、外側（図におけるルータＲＡ，ＲＢの上側）に接続された通信路について付与されたグローバルＩＰアドレスに変換するとともに、その逆の変換も行う。このＮＡＴにはいくつかのタイプがあり、具体的には、「Full cone NAT」，「Restricted cone NAT」，「Port restricted cone NAT」，「Symmetric NAT（対称型ＮＡＴ）」等のタイプが実用されている。
個々のＮＡＴタイプは、それぞれ固有の仕様でアドレス変換を行うことを定めており、ルータの設置者は、セキュリティ上の問題や利用上の便宜などを考慮した上で、各ルータに適切なＮＡＴタイプを設定することになる。ここで、先願基本発明に係るネットワーク通信システムを実施する上で留意すべきＮＡＴタイプは、「Symmetric NAT（対称型ＮＡＴ）」および「Port restricted cone NAT」である。本願では、この「Symmetric NAT（対称型ＮＡＴ）」および「Port restricted cone NAT」を、便宜上、「関所型ＮＡＴ」と呼ぶことにする。この「関所型ＮＡＴ」が設定されているルータは、「外部ホストから内部ホスト（内側の端末装置）宛に送信されてきたパケットについては、過去に内部ホストからのパケットを受け取ったことがある外部ホストからのパケットのみを通す」という制限の下でアドレス変換を行う。このため、先願基本発明に係るネットワーク通信システムを利用した場合、関所型ＮＡＴが設定されているルータの内側の端末装置に対する通信に支障が生じることになる。
たとえば、図２１の例において、ルータＲＢに関所型ＮＡＴの設定がなされていたものとしよう。この場合、ルータＲＢを介して内側から外側へ信号を送り出す際には、特に制約なしにアドレス変換が行われる。このため、端末装置２００ＢからインターネットＮに向かうパケットはルータＲＢを自由に通り抜けることができる。ところが、ルータＲＢを介して外側から内側へ信号を送り込む際には、ルータＲＢが関所の役割を果たすことになる。すなわち、インターネットＮから端末装置２００Ｂ宛にパケットが送られてきた場合、その送り主が過去に端末装置２００Ｂからのパケットを受け取ったことがある外部ホストである場合には、ルータＲＢは当該パケットを取り込んで端末装置２００Ｂ（内部ホスト）へ届けるが、それ以外の外部ホストである場合には、これをブロックする。
このため、ルータＲＢが関所型ＮＡＴのルータであった場合、接続仲介装置１００を送り主として、太線矢印Ｌ２に沿って端末装置２００Ｂ宛に送信されてきたパケットは、ルータＲＢを通って支障なく端末装置２００Ｂに届くが、端末装置２００Ａを送り主として、細線矢印Ｌ３に沿って端末装置２００Ｂ宛に送信されてきたパケットは、ルータＲＢによってブロックされてしまう可能性がある。その理由は、次のとおりである。
§１，§２で述べたとおり、先願基本発明に係るネットワーク通信システムにおける各端末装置２００Ａ，２００Ｂは、現時点の自己の所在アドレスを、所定のタイミングで繰り返して接続仲介装置１００に通知している。このため、接続仲介装置１００は、「過去に内部ホスト（端末装置２００Ｂ）からのパケットを受け取ったことがある外部ホスト」ということになり、接続仲介装置１００から端末装置２００Ｂ宛のパケットはルータＲＢを通り抜けることができる。ところが、端末装置２００Ａは、必ずしも「過去に内部ホスト（端末装置２００Ｂ）からのパケットを受け取ったことがある外部ホスト」に該当するわけではないので、端末装置２００Ａから端末装置２００Ｂ宛のパケットはルータＲＢによってブロックされてしまう可能性がある。
このように、端末間の直接的な通信がブロックされてしまうと、先願基本発明に係るネットワーク通信システムによる接続仲介処理は正常に機能しなくなる。たとえば、図４に示す例の場合、通信元端末装置２００Ａの通信開始要求部２４０Ａからの通信開始要求Ｓ５が、ルータによってブロックされ、通信先端末装置２００Ｂに届かなかった場合、通信先セッション確立部２３０Ｂは通信セッションを確立することができず、両端末間の通信（Ｓ７）は実現しなくなる。このような事情は、§２で述べた先願基本発明の第２の実施形態の場合も同様である。
以上、関所型ＮＡＴが設定されているルータによって端末間通信がブロックされることに起因した通信障害の例を述べたが、端末間通信がブロックされる要因は、他にも存在する。たとえば、インターネットを介した端末間通信のトランスポート層のプロトコルとしては、ＴＣＰ（Transmission Control Protocol），ＵＤＰ（User Datagram Protocol）等、いくつかのプロトコルが利用されている。ＴＣＰでは、通信速度よりも正確さに重点がおかれているため、パケットが確実に相手方に届くための工夫がなされているが、通信負荷は増大する。これに対して、ＵＤＰでは、正確さよりも通信速度に重点がおかれているため、パケットが喪失する可能性があるが、通信負荷は低減する。このため、Ｗｅｂ画面の閲覧などにはＴＣＰが用いられ、電話などの音声通話などにはＵＤＰが用いられる。
もちろん、先願基本発明に係るネットワーク通信システムでは、通信プロトコルとしてＴＣＰを採用することもできるし、ＵＤＰを採用することもできる。したがって、たとえば、音声通話を主としたシステムを構築するのであれば、ＵＤＰを採用してシステムを構築し、全体の通信負荷を低減させるのが好ましい。ただ、ＵＤＰのパケットは、途中でブロックされる可能性もある。たとえば、端末間に設置されているファイアウォールが、ＵＤＰパケットをブロックする仕様になっていると、ＵＤＰパケットは当該ファイアウォールを通り抜けることができず、相手方に届かなくなってしまう。
このように、先願基本発明に係るシステムには、ネットワーク環境によって、端末間通信に支障が生じる可能性がある。本発明は、このような問題を解決するためになされたものであり、上述したような様々な要因により、端末間の直接通信に何らかの制限が設けられている場合にも、両者間での通信を支障なく行うことが可能となるような対策を講じる方法を提供するものである。
本発明に係るネットワーク通信システムでは、先願基本発明に係るシステムのように端末装置間で直接的な通信（ここでは「通常通信」と呼ぶ）を行うことを前提としつつ、もう１つの通信方法として、接続仲介装置を介して間接的に通信を行う「迂回通信」と呼ぶ方法が用意される。そして、通常通信に失敗した場合、もしくは、通常通信での失敗が予想される場合、通常通信に代えて、迂回通信を行うことにより、両端末間での通信を支障なく行うことができるようにしている。
この迂回通信では、両端末間の情報パケットは、すべて接続仲介装置を介してやりとりされることになる。§１，§２で述べたとおり、各端末装置は、現時点の自己アドレスを所定タイミングで接続仲介装置に通知する機能を有しているため、接続仲介装置は、関所型ＮＡＴのルータ下にある端末装置に対しても「過去にパケットを受け取ったことがある外部ホスト」ということになる。したがって、端末装置間の直接的な通信がルータによってブロックされたとしても、端末装置と接続仲介装置との間の通信はブロックされることはなく、迂回通信は支障なく行われることになる。
また、通常通信をＵＤＰで行うことを前提としてシステムを構築した場合、迂回通信をＴＣＰで行うようにしておけば、ＵＤＰブロックにより通常通信を行うことができない場合でも、代わりに迂回通信を用いることにより、両者間での通信を支障なく行うことが可能になる。
もちろん、通常通信の代わりに迂回通信を行った場合、接続仲介装置は、両端末装置間でやりとりされるすべての情報パケットを中継する必要があり、その処理負荷は増大することになる。したがって、迂回通信を行った場合は、先願基本発明の特徴である「一対の端末装置間の接続を仲介する際の処理負荷を軽減する」という作用効果は得られなくなる。しかしながら、本発明に係るネットワーク通信システムでも、基本的には先願基本発明と同様に通常通信を前提とした運用が行われ、ネットワーク環境によって、端末間通信に支障が生じる特殊なケースについてのみ迂回通信が行われることになるので、全体としてみれば、先願基本発明と同様に、「一対の端末装置間の接続を仲介する際の処理負荷を軽減する」という作用効果は得られ、更に、端末装置間の直接通信に問題がある場合にも、両者間での通信を支障なく行うことが可能になるという固有の作用効果も得られることになる。
本発明では、通常通信に代えて迂回通信を行うアプローチとして、次の３通りのアプローチを用意している。
(1) 失敗時に迂回通信
通常通信に失敗したことが判明した時点で、迂回通信に切り替える方法であり、具体的な内容は、§６において詳述する。
(2) 関所型ＮＡＴの場合に迂回通信
予め各端末装置が利用するルータのＮＡＴタイプを調べておき、関所型ＮＡＴの設定がなされたルータが介在するために通常通信の失敗が予想される場合に、通常通信に代えて迂回通信を行う方法であり、具体的な内容は、§７において詳述する。
(3) ＵＤＰブロックの場合に迂回通信
ＵＤＰによる通常通信を前提としたシステムを構築しておき、通信経路上にＵＤＰをブロックする要素が存在するために通常通信の失敗が予想される場合に、通常通信に代えてＴＣＰによる迂回通信を行う方法であり、具体的な内容は、§８において詳述する。
＜＜＜ §６． 失敗時に迂回通信を行うアプローチ ＞＞＞
この§６で述べる実施形態は、先願基本発明に係るシステムにおいて、図５や図９に示す手順に基づく通常通信が失敗した場合に、この失敗を検知して迂回通信に切り替える方法を採用する実施形態である。以下、このような方法を、§１に示す先願基本発明の第１の実施形態（図２）に適用した例を実施例１として説明し、§２に示す先願基本発明の第２の実施形態（図７）に適用した例を実施例２として説明する。もちろん、以下に述べる実施例１，２については、§３や§４で述べた各種変形例を適用することも可能である。なお、各実施例１，２にブロックとして示されている各構成要素は、これまで述べた先願基本発明に係るシステムと同様に、実際には、コンピュータに組み込まれた専用のプログラムによって実現されることになる。
＜６−１． 実施例１＞
図２２は、本発明の実施例１に係るネットワーク通信システムにおける端末装置２０１の詳細構成を示すブロック図である。ここに示す端末装置２０１は、図２に示す先願基本発明の第１の実施形態に係る端末装置２００における通信開始要求部２４０および通信元セッション確立部２６０に、若干の修正を加えてそれぞれ通信開始要求部２４１および通信元セッション確立部２６１とし、更に、新たな構成要素として、迂回通信処理部２７１（図では新たな構成要素を太線枠ブロックで示す）を付加したものである。その他の構成要素である接続仲介依頼部２１０、通信要求受付部２２０、通信先セッション確立部２３０、自己アドレス通知部２５０は、図２に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§１で述べたとおりである。
また、この図２２に示す実施例１では、図２に示す接続仲介装置１００の代わりに、接続仲介装置１０１が用いられている。この接続仲介装置１０１は、図２に示す接続仲介装置１００の機能に、迂回通信を中継する機能を付加したものであり、その構成の詳細は後述する。結局、図２２に示す実施例１において、３桁の数字からなる符号における１の位が「１」となっているブロックで示される構成要素が、実施例１に固有の構成要素ということになる。
この実施例１に係るシステムは、図２に示す先願発明のシステムと同様に、ネットワークＮを介して相互に接続可能な複数の端末装置（図には、便宜上、１台の端末装置２０１のみが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置１０１と、を備えたネットワーク通信システムである。ここで、各端末装置２０１には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置１０１は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。
この図において、太線矢印は、端末装置２０１と接続仲介装置１０１との間でやりとりされる信号の流れを示しており、細線矢印（ブロック２０１内部の矢印を除く）は、一対の端末装置２０１の間で直接的にやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置２０１の間で直接的にやりとりされる、通信セッション確立後の信号の流れを示している。この白抜矢印には、「通常通信」なる表記がなされているが、これはこのシステムが想定する本来の通信、すなわち、端末装置２０１間で直接的に行われる通信を示している。これに対して、迂回通信処理部２７１から伸びる太線矢印には、「迂回通信」なる表記がなされているが、これは、上述した「通常通信」に失敗したときに、端末装置２０１が接続仲介装置１０１を介して間接的に相手方への通信を行うことを示している。
図２２に示す自己アドレス通知部２５０は、図２に示す自己アドレス通知部２５０と全く同じ構成要素であり、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１０１に対して通知する機能を果たす。当該機能については、既に§１で詳述したため、ここでは説明を省略する。
その他の構成要素の機能も、ほぼ図２に示す対応する構成要素の機能と同じである。ただ、通信開始要求部２４１は、通信開始要求を行う際に、その旨を迂回通信処理部２７１に通知する付加機能を有しており、通信元セッション確立部２６１は、通信開始受諾確認を受領した際に、その旨を迂回通信処理部２７１に通知する付加機能を有している。
このような付加機能により、迂回通信処理部２７１は、通信元端末装置の通信元セッション確立部２６１と通信先端末装置の通信先セッション確立部２３０との間に通信セッションを確立して相手方に対する直接的な情報送受を行う通常通信（図の白抜矢印で示された通信）に失敗したときに、接続仲介装置１０１を介して相手方に対する間接的な情報送受を行う迂回通信を実行することができる。具体的には、通信元端末装置の通信開始要求部２４１が通信先端末装置宛に通信開始要求を行った後、これに応じた通信開始受諾確認が所定のタイムアウト設定時間内に返信されてこなかった場合に、迂回通信処理部２７１による迂回通信処理が行われる。
上述のとおり、迂回通信処理部２７１は、通信開始要求部２４１から通信開始要求を行った旨の通知を受けることができるので、その時点から経過時間の測定を開始し、所定のタイムアウト設定時間内に、通信元セッション確立部２６１から通信開始受諾確認を受領した旨の通知が来なかった場合には、通常通信に失敗したと判断し、迂回通信処理を開始する。具体的には、迂回通信処理部２７１は、接続仲介装置１０１（後述するように、その中の迂回通信中継部１４１）に対して迂回通信の中継依頼を行い、接続仲介装置１０１を介して、相手方の迂回通信処理部２７１との間での迂回通信を実行することになる。
図２３は、図２２に示す本発明の実施例１に係るネットワーク通信システムにおいて、通信元端末装置２０１Ａと通信先端末装置２０１Ｂとの間の通信セッション確立の手順を示すブロック図である。図示する端末装置２０１Ａ，２０１Ｂは、図２２に示す端末装置２０１と同一の構成を有する装置であり、図４と同様に、通信元端末装置２０１Ａ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）を実線で示し、通信先端末装置２００Ｂ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）を実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。また、実施例１に固有の構成要素である迂回通信処理部２７１Ａ，２７１Ｂについては太線枠ブロックで示してある。
図２３に示す接続仲介装置１０１（図２２に示すもの）は、図４に示す接続仲介装置１００に、迂回通信中継部１４１を追加したものである。その他の構成要素であるアドレステーブル格納部１１０、アドレステーブル更新部１２０、通信先アドレス返信部１３０については、図４に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§１で述べたとおりである。迂回通信中継部１４１は、第１の端末装置２０１Ａの迂回通信処理部２７１Ａと第２の端末装置２０１Ｂの迂回通信処理部２７１Ｂとの間での迂回通信の中継依頼があったときに、第１の端末装置２０１Ａの迂回通信処理部２７１Ａと第２の端末装置２０１Ｂの迂回通信処理部２７１Ｂとの間で受け渡しする情報を取り次いで迂回通信の中継を行う構成要素である。
このシステムにおける通常の通信セッション確立の手順は、図４および図５を用いて§１で説明した手順と同じである。すなわち、通信元端末装置２０１Ａの通信要求受付部２２０Ａが自己を通信元として、通信先の別な端末装置２０１Ｂに対する通信要求Ｓ１を受け付けると、接続仲介依頼部２１０Ａが、接続仲介装置１０１に対して、通信先の別な端末装置２０１Ｂの端末ＩＤ「００２０」を特定するための通信先特定情報を含む接続仲介依頼Ｓ２を送信する。
すると、接続仲介装置１０１の通信先アドレス返信部１３０は、アドレステーブルを参照して、接続仲介依頼Ｓ２に含まれている通信先特定情報によって特定される端末ＩＤ「００２０」に対応づけられている所在アドレスＡＤ２を通信先アドレスとして返信（Ｓ４）する。この返信（Ｓ４）を受けた通信開始要求部２４１Ａは、通信先アドレスＡＤ２にアクセスして通信開始要求Ｓ５を行う。このとき、前述したとおり、通信開始要求部２４１Ａから迂回通信処理部２７１Ａに対して、通信開始要求Ｓ５を行った旨の通知が出され、迂回通信処理部２７１Ａはその時点から経過時間の測定を開始する。なお、§５で説明したとおり、端末間通信である通信開始要求Ｓ５は、ネットワーク環境によってブロックされ、通信先端末装置２０１Ｂに届かない可能性がある。図に「Ｓ５？」と記したのは、このような可能性を示すものである。
この通信開始要求Ｓ５が、通信先端末装置２０１Ｂ側の通信先セッション確立部２３０Ｂに無事届いた場合は、通信元端末装置２０１Ａに対して通信開始受諾確認Ｓ６が送信される。通信元端末装置２０１Ａ側の通信元セッション確立部２６１Ａは、この通信開始受諾確認Ｓ６を受領すると、その旨を迂回通信処理部２７１Ａに通知する。そして、通信元セッション確立部２６１Ａと通信先セッション確立部２３０Ｂとの間に通信セッションが確立する。
しかしながら、通信開始要求Ｓ５が、ネットワーク環境によってブロックされた場合、当然ながら、通信先セッション確立部２３０Ｂからの通信開始受諾確認Ｓ６は送信されない。あるいは、通信開始要求Ｓ５が無事届いたのに、通信開始受諾確認Ｓ６がネットワーク環境によってブロックされる可能性もある。図に「Ｓ６？」と記したのは、このような可能性を示すものである。このような場合、通信元端末装置２０１Ａと通信先端末装置２０１Ｂとの間における通常通信は失敗に終わる。
このように、通信開始要求Ｓ５や通信開始受諾確認Ｓ６がブロックされて通常通信が失敗した場合、通信元セッション確立部２６１Ａは、所定のタイムアウト設定時間内に通信開始受諾確認Ｓ６を受領することができない。このため、迂回通信処理部２７１Ａには、通信開始受諾確認Ｓ６の受領報告が所定のタイムアウト設定時間内になされないことになる。そうすると、迂回通信処理部２７１Ａは通常通信に失敗したことを認識し、迂回通信処理を実行する。
すなわち、迂回通信処理部２７１Ａは、通常通信の失敗を検知すると、迂回通信中継部１４１に対して迂回通信の中継依頼を行い、迂回通信中継部１４１を介して、相手方の迂回通信処理部２７１Ｂとの間での迂回通信Ｓ８ａを実行する。迂回通信処理部２７１Ａは、通信開始要求部２４１Ａから通信先アドレスＡＤ２を取得し、これを迂回通信中継部１４１に伝達して中継依頼を行う。迂回通信中継部１４１は、この中継依頼に応じて、通信先アドレスＡＤ２にアクセスし、通信先端末装置２０１Ｂの迂回通信処理部２７１Ｂに迂回通信の開始を要求する。迂回通信処理部２７１Ｂは、これを受諾する旨の返信を迂回通信中継部１４１に対して行い、迂回通信Ｓ８ｂを実行する。以後、迂回通信中継部１４１による中継により、両端末装置２０１Ａ，２０１Ｂ間での迂回通信が行われる。
この迂回通信では、両端末装置２０１Ａ，２０１Ｂ間の情報パケットは、すべて接続仲介装置１０１を介してやりとりされることになる。この場合、端末装置２０１Ａ，２０１Ｂから接続仲介装置１０１に対しては、自己アドレス通知部２５０Ａ，２５０Ｂの機能により、現時点の自己アドレスが通知されるため、接続仲介装置１０１は、関所型ＮＡＴのルータ下にある端末装置に対しても「過去にパケットを受け取ったことがある外部ホスト」ということになり、接続仲介装置１０１と端末装置２０１Ａもしくは２０１Ｂとの間の通信は、関所型ＮＡＴのルータによって拒絶されることはない。したがって、両端末装置２０１Ａ，２０１Ｂ間の直接的な通信が関所型ＮＡＴのルータによってブロックされたとしても、両端末装置２０１Ａ，２０１Ｂ間の通信は、接続仲介装置１０１を中継して支障なく行われることになる。
また、両端末装置２０１Ａ，２０１Ｂ間の通常通信がＵＤＰを前提としていた場合でも、迂回通信Ｓ８ａ，Ｓ８ｂをＴＣＰで行うようにすれば、ＵＤＰブロックにより通常通信を行うことができない場合でも、迂回通信Ｓ８ａ，Ｓ８ｂを支障なく行うことができる。迂回通信は、接続仲介装置１０１に多大な処理負荷をかける通信形態であるが、通常通信に失敗した場合の緊急時の対応策であるため、接続仲介装置１０１の全体的な処理負荷に重大な影響を与えることはない。
図２４は、図２３のブロック図に示されている実施例１における通信セッション確立手順を時系列で説明する流れ図である。この流れ図は、§１で述べた先願発明の第１の実施形態における通信セッション確立手順を示す図５の流れ図とほぼ同じである。ただ、図２３に示す通信開始要求「Ｓ５？」および通信開始受諾確認「Ｓ６？」は、ネットワーク環境の諸条件に関する要因により、相手方に届かない可能性がある。図２４におけるステップＳ５？，Ｓ６？は、図５におけるステップＳ５，Ｓ６と基本的には同じ手順を示しているが、ネットワーク環境の要因により信号が相手方に届かないケースを想定し、全体を括弧の中に入れて示してある。
ステップＳ６′は、通常通信の準備が成功したか失敗したかを判定する処理である。前述したとおり、通信開始要求部２４１ＡがステップＳ５？の通信開始要求を行う際に、その旨が迂回通信処理部２７１Ａに通知され、迂回通信処理部２７１Ａはその時点から経過時間の測定を開始する。ここで、通信元セッション確立部２６１Ａからの通信開始受諾確認の受領報告が、所定のタイムアウト設定時間内にあった場合には、ステップＳ７へと進み、通信先セッション確立部２３０Ｂと通信元セッション確立部２６１Ａによって、通信セッション確立の処理を経て通常通信が行われる（図５のステップＳ７と同様の処理）。一方、通信開始受諾確認の受領報告が、所定のタイムアウト設定時間内になされなかった場合には、通常通信が失敗したものと判断され、ステップＳ８へと進む。このステップＳ８では、迂回通信処理部２７１Ａ，２７１Ｂと迂回通信中継部１４１によって、迂回通信処理が行われる（図２３のＳ８ａ，Ｓ８ｂ）。
＜６−２． 実施例２＞
図２５は、本発明の実施例２に係るネットワーク通信システムにおける端末装置４０２の詳細構成を示すブロック図である。ここに示す端末装置４０２は、図７に示す先願基本発明の第２の実施形態に係る端末装置４００における通信開始要求部４４０および通信先セッション確立部４６０に、若干の修正を加えてそれぞれ通信開始要求部４４２および通信先セッション確立部４６２とし、更に、新たな構成要素として、迂回通信処理部４７２（図では新たな構成要素を太線枠ブロックで示す）を付加したものである。その他の構成要素である接続仲介依頼部４１０、通信要求受付部４２０、通信元セッション確立部４３０、自己アドレス通知部４５０は、図７に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§２で述べたとおりである。
また、この図２５に示す実施例２では、図７に示す接続仲介装置３００の代わりに、接続仲介装置３０２が用いられている。この接続仲介装置３０２は、図２に示す接続仲介装置３００の機能に、迂回通信を中継する機能を付加したものであり、その構成の詳細は後述する。結局、図２５に示す実施例２において、３桁の数字からなる符号における１の位が「２」となっているブロックで示される構成要素が、実施例２に固有の構成要素ということになる。
この実施例２に係るシステムは、図７に示す先願発明のシステムと同様に、ネットワークＮを介して相互に接続可能な複数の端末装置（図には、便宜上、１台の端末装置４０２のみが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置３０２と、を備えたネットワーク通信システムである。ここで、各端末装置４０２には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置３０２は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。
この図においても、前述した実施例１と同様に、太線矢印、細線矢印、白抜矢印の３種類の矢印が用いられている。白抜矢印は「通常通信」を示し、迂回通信処理部４７２から伸びる太線矢印は「迂回通信」を示している。また、自己アドレス通知部４５０は、図７に示す自己アドレス通知部４５０と全く同じ構成要素であり、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置３０２に対して通知する機能を果たす。当該機能については、既に§２で詳述したため、ここでは説明を省略する。
その他の構成要素の機能も、ほぼ図７に示す対応する構成要素の機能と同じである。ただ、通信開始要求部４４２は、通信開始要求を行う際に、その旨を迂回通信処理部４７２に通知する付加機能を有しており、通信先セッション確立部４６２は、通信開始受諾確認を受領した際に、その旨を迂回通信処理部４７２に通知する付加機能を有している。
このような付加機能により、迂回通信処理部４７２は、通信元端末装置の通信元セッション確立部４３０と通信先端末装置の通信先セッション確立部４６２との間に通信セッションを確立して相手方に対する直接的な情報送受を行う通常通信（図の白抜矢印で示された通信）に失敗したときに、接続仲介装置３０２を介して相手方に対する間接的な情報送受を行う迂回通信を実行することができる。具体的には、通信先端末装置の通信開始要求部４４２が通信元端末装置宛に通信開始要求を行った後、これに応じた通信開始受諾確認が所定のタイムアウト設定時間内に返信されてこなかった場合に、迂回通信処理部４７２による迂回通信処理が行われる。
上述のとおり、迂回通信処理部４７２は、通信開始要求部４４２から通信開始要求を行った旨の通知を受けることができるので、その時点から経過時間の測定を開始し、所定のタイムアウト設定時間内に、通信先セッション確立部４６２から通信開始受諾確認を受領した旨の通知が来なかった場合には、通常通信に失敗したと判断し、迂回通信処理を開始する。具体的には、迂回通信処理部４７２は、接続仲介装置３０２（後述するように、その中の迂回通信中継部３４２）に対して迂回通信の中継依頼を行い、接続仲介装置３０２を介して、相手方の迂回通信処理部４７２との間での迂回通信を実行することになる。
図２６は、図２５に示す本発明の実施例２に係るネットワーク通信システムにおいて、通信元端末装置４０２Ｂと通信先端末装置４０２Ａとの間の通信セッション確立の手順を示すブロック図である。図示する端末装置４０２Ａ，４０２Ｂは、図２５に示す端末装置４０２と同一の構成を有する装置であり、図８と同様に、通信元端末装置４０２Ｂ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）を実線で示し、通信先端末装置４０２Ａ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）を実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。また、実施例２に固有の構成要素である迂回通信処理部４７２Ａ，４７２Ｂについては太線枠ブロックで示してある。
図２６に示す接続仲介装置３０２（図２５に示すもの）は、図８に示す接続仲介装置３００に、迂回通信中継部３４２を追加したものである。その他の構成要素であるアドレステーブル格納部３１０、アドレステーブル更新部３２０、通信先アドレス返信部３３０については、図８に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§２で述べたとおりである。迂回通信中継部３４２は、第１の端末装置４０２Ａの迂回通信処理部４７２Ａと第２の端末装置４０２Ｂの迂回通信処理部４７２Ｂとの間での迂回通信の中継依頼があったときに、第１の端末装置４０２Ａの迂回通信処理部４７２Ａと第２の端末装置４０２Ｂの迂回通信処理部４７２Ｂとの間で受け渡しする情報を取り次いで迂回通信の中継を行う構成要素である。
このシステムにおける通常の通信セッション確立の手順は、図８および図９を用いて§２で説明した手順と同じである。すなわち、通信元端末装置４０２Ｂの通信要求受付部４２０Ｂが自己を通信元として、通信先の別な端末装置４０２Ａに対する通信要求Ｓ１１を受け付けると、接続仲介依頼部４１０Ｂが、接続仲介装置３０２に対して、通信先の別な端末装置４０２Ａの端末ＩＤ「００１０」を特定するための通信先特定情報を含む接続仲介依頼Ｓ１２を送信する。
すると、接続仲介装置３０２の通信元アドレス送信部３３０は、アドレステーブルを参照して、接続仲介依頼Ｓ１２に含まれている通信先特定情報によって特定される端末ＩＤ「００１０」に対応づけられている所在アドレスＡＤ１を通信先アドレスとして認識し、この通信先アドレスＡＤ１に対して、接続仲介依頼Ｓ１２を送信した通信元の端末装置４０２Ｂの端末ＩＤ「００２０」に対応づけられている所在アドレスＡＤ２を、通信元アドレスとして送信（Ｓ１４）する。
こうして、通信元アドレスＡＤ２の送信（Ｓ１４）を受けた通信先端末装置４０２Ａ内の通信開始要求部４４２Ａは、通信元アドレスＡＤ２にアクセスして通信開始要求Ｓ１５を行う。このとき、前述したとおり、通信開始要求部４４２Ａから迂回通信処理部４７２Ａに対して、通信開始要求Ｓ１５を行った旨の通知が出され、迂回通信処理部４７２Ａはその時点から経過時間の測定を開始する。なお、§５で説明したとおり、端末間通信である通信開始要求Ｓ１５は、ネットワーク環境によってブロックされ、通信元端末装置４０２Ｂに届かない可能性がある。図に「Ｓ１５？」と記したのは、このような可能性を示すものである。
この通信開始要求Ｓ１５が、通信元端末装置４０２Ｂ側の通信元セッション確立部４３０Ｂに無事届いた場合は、通信先端末装置４０２Ａに対して通信開始受諾確認Ｓ１６が送信される。通信先端末装置４０２Ａ側の通信先セッション確立部４６２Ａは、この通信開始受諾確認Ｓ１６を受領すると、その旨を迂回通信処理部４７２Ａに通知する。そして、通信先セッション確立部４６２Ａと通信元セッション確立部４３０Ｂとの間に通信セッションが確立する。
しかしながら、通信開始要求Ｓ１５が、ネットワーク環境によってブロックされた場合、当然ながら、通信元セッション確立部４３０Ｂからの通信開始受諾確認Ｓ１６は送信されない。あるいは、通信開始要求Ｓ１５が無事届いたのに、通信開始受諾確認Ｓ１６がネットワーク環境によってブロックされる可能性もある。図に「Ｓ１６？」と記したのは、このような可能性を示すものである。このような場合、通信元端末装置４０２Ｂと通信先端末装置４０２Ａとの間における通常通信は失敗に終わる。
このように、通信開始要求Ｓ１５や通信開始受諾確認Ｓ１６がブロックされて通常通信が失敗した場合、通信先セッション確立部４６２Ａは、所定のタイムアウト設定時間内に通信開始受諾確認Ｓ１６を受領することができない。このため、迂回通信処理部４７２Ａには、通信開始受諾確認Ｓ１６の受領報告が所定のタイムアウト設定時間内になされないことになる。そうすると、迂回通信処理部４７２Ａは通常通信に失敗したことを認識し、迂回通信処理を実行する。
すなわち、迂回通信処理部４７２Ａは、通常通信の失敗を検知すると、迂回通信中継部３４２に対して迂回通信の中継依頼を行い、迂回通信中継部３４２を介して、相手方の迂回通信処理部４７２Ｂとの間での迂回通信Ｓ１８ａを実行する。迂回通信処理部４７２Ａは、通信開始要求部４４２Ａから通信元アドレスＡＤ２を取得し、これを迂回通信中継部３４２に伝達して中継依頼を行う。迂回通信中継部３４２は、この中継依頼に応じて、通信元アドレスＡＤ２にアクセスし、通信元端末装置４０２Ｂの迂回通信処理部４７２Ｂに迂回通信の開始を要求する。迂回通信処理部４７２Ｂは、これを受諾する旨の返信を迂回通信中継部３４２に対して行い、迂回通信Ｓ１８ｂを実行する。以後、迂回通信中継部３４２による中継により、両端末装置４０２Ａ，４０２Ｂ間での迂回通信が行われる。
この迂回通信では、両端末装置４０２Ａ，４０２Ｂ間の情報パケットは、すべて接続仲介装置３０２を介してやりとりされることになる。この場合、端末装置４０２Ａ，４０２Ｂから接続仲介装置３０２に対しては、自己アドレス通知部４５０Ａ，４５０Ｂの機能により、現時点の自己アドレスが通知されるため、接続仲介装置３０２は、関所型ＮＡＴのルータ下にある端末装置に対しても「過去にパケットを受け取ったことがある外部ホスト」ということになる。したがって、両端末装置４０２Ａ，４０２Ｂ間の直接的な通信が関所型ＮＡＴのルータによってブロックされたとしても、両端末装置４０２Ａ，４０２Ｂ間の通信は、接続仲介装置３０２を中継して支障なく行われることになる。
また、両端末装置４０２Ａ，４０２Ｂ間の通常通信がＵＤＰを前提としていた場合でも、迂回通信Ｓ１８ａ，Ｓ１８ｂをＴＣＰで行うようにすれば、ＵＤＰブロックにより通常通信を行うことができない場合でも、迂回通信Ｓ１８ａ，Ｓ１８ｂを支障なく行うことができる。迂回通信は、接続仲介装置３０２に多大な処理負荷をかける通信形態であるが、通常通信に失敗した場合の緊急時の対応策であるため、接続仲介装置３０２の全体的な処理負荷に重大な影響を与えることはない。
図２７は、図２６のブロック図に示されている実施例２における通信セッション確立手順を時系列で説明する流れ図である。この流れ図は、§２で述べた先願発明の第２の実施形態における通信セッション確立手順を示す図９の流れ図とほぼ同じである。ただ、図２６に示す通信開始要求「Ｓ１５？」および通信開始受諾確認「Ｓ１６？」は、ネットワーク環境の諸条件に関する要因により、相手方に届かない可能性がある。図２７におけるステップＳ１５？，Ｓ１６？は、図９におけるステップＳ１５，Ｓ１６と基本的には同じ手順を示しているが、ネットワーク環境の要因により信号が相手方に届かないケースを想定し、全体を括弧の中に入れて示してある。
ステップＳ１６′は、通常通信の準備が成功したか失敗したかを判定する処理である。前述したとおり、通信開始要求部４４２ＡがステップＳ１５？の通信開始要求を行う際に、その旨が迂回通信処理部４７２Ａに通知され、迂回通信処理部４７２Ａはその時点から経過時間の測定を開始する。ここで、通信先セッション確立部４６２Ａからの通信開始受諾確認の受領報告が、所定のタイムアウト設定時間内にあった場合には、ステップＳ１７へと進み、通信元セッション確立部４３０Ｂと通信先セッション確立部４６２Ａによって、通信セッション確立の処理を経て通常通信が行われる（図９のステップＳ１７と同様の処理）。一方、通信開始受諾確認の受領報告が、所定のタイムアウト設定時間内になされなかった場合には、通常通信が失敗したものと判断され、ステップＳ１８へと進む。このステップＳ１８では、迂回通信処理部４７２Ａ，４７２Ｂと迂回通信中継部３４２によって、迂回通信処理が行われる（図２６のＳ１８ａ，Ｓ１８ｂ）。
＜６−３． 実施例１および実施例２の変形例＞
これまで述べた実施例１および実施例２では、迂回通信処理部２７１，４７２が、通信開始要求部２４１，４４２が通信開始要求Ｓ５，Ｓ１５を行った後、これに応じた通信開始受諾確認Ｓ６，Ｓ１６が所定のタイムアウト設定時間内に返信されてこなかった場合に、通常通信に失敗したと判断して迂回通信を実行する構成をとっている。ここで述べる変形例は、通常通信に失敗したと判断する方法を若干変更したものである。
この変形例では、通信開始要求部２４１，４４２から迂回通信処理部２７１，４７２に対する通信開始要求の通知や、セッション確立部２６１，４６２から迂回通信処理部２７１，４７２に対する通信開始受諾確認の受領通知は不要である。その代わりに、通信開始要求Ｓ５，Ｓ１５に対する相手方からのアクノレッジを受け取るようにし、当該アクノレッジが得られなかった場合に、通常通信に失敗したと判断する方法を採る。
具体的には、図２３に示す実施例１の変形例の場合、通信元端末装置２０１Ａの通信開始要求部２４１Ａが、通信先端末装置２０１Ｂに対して通信開始要求Ｓ５を行う際に、通信先端末装置２０１Ｂ側の通信先セッション確立部２３０Ｂから、当該通信開始要求Ｓ５に対するアクノレッジが返信されるような仕様にしておく。すなわち、通信先セッション確立部２３０Ｂが、通信開始要求Ｓ５を受け取ったときに、通信開始要求部２４１Ａに対してアクノレッジの信号を返信するようにし、通信開始要求部２４１Ａは、このアクノレッジ信号を受信することにより、通信開始要求Ｓ５が相手先に届いたことを認識できるようにしておく。
このような仕様では、通信開始要求部２４１Ａは、アクノレッジが返信されて来なかった場合に、通常通信に失敗したと判断することができる。そこで、通信開始要求部２４１Ａは、アクノレッジが返信されて来なかった場合に、迂回通信処理部２７１Ａに対して迂回通信を指示するようにする。このような指示を受けた迂回通信処理部２７１Ａは、迂回通信中継部１４１に対して迂回通信の中継依頼を行い、迂回通信中継部１４１を介して、相手方の迂回通信処理部２７１Ｂとの間での迂回通信を実行すればよい。
同様に、図２６に示す実施例２の変形例の場合、通信先端末装置４０２Ａの通信開始要求部４４２Ａが、通信先端末装置４０２Ｂに対して通信開始要求Ｓ１５を行う際に、通信先端末装置４０２Ｂ側の通信元セッション確立部４３０Ｂから、当該通信開始要求Ｓ１５に対するアクノレッジが返信されるような仕様にしておく。すなわち、通信元セッション確立部４３０Ｂが、通信開始要求Ｓ１５を受け取ったときに、通信開始要求部４４２Ａに対してアクノレッジの信号を返信するようにし、通信開始要求部４４２Ａは、このアクノレッジ信号を受信することにより、通信開始要求Ｓ１５が相手先に届いたことを認識できるようにしておく。
このような仕様では、通信開始要求部４４２Ａは、アクノレッジが返信されて来なかった場合に、通常通信に失敗したと判断することができる。そこで、通信開始要求部４４２Ａは、アクノレッジが返信されて来なかった場合に、迂回通信処理部４７２Ａに対して迂回通信を指示するようにする。このような指示を受けた迂回通信処理部４７２Ａは、迂回通信中継部３４２に対して迂回通信の中継依頼を行い、迂回通信中継部３４２を介して、相手方の迂回通信処理部４７２Ｂとの間での迂回通信を実行すればよい。
＜＜＜ §７． 関所型ＮＡＴの場合に迂回通信を行うアプローチ ＞＞＞
§６で述べた実施例１，２は、先願基本発明に係るシステムにおいて通常通信が失敗した場合に、この失敗を検知して迂回通信に切り替える方法を採用するものである。これに対して、この§７で述べる実施形態は、通常通信を行うと失敗が予想されるときに、これを事前に検知して、通常通信の代わりに迂回通信を行う方法を採用するものである。より具体的には、通常通信が関所型ＮＡＴのルータにより妨げられる可能性がある場合には、事前にこれを検知して、通常通信ではなく、迂回通信に切り替える方法を採る。
図２１を用いて説明したとおり、実用上、各端末装置２００Ａ，２００ＢはルータＲＡ，ＲＢを介してインターネットＮに接続されるのが一般的である。この場合、§５で述べたとおり、ルータのタイプが関所型ＮＡＴに設定されていると、その下に接続されている端末装置は、「過去に自分が送信したパケットを受け取ったことがある外部ホストからのパケット」しか受け取ることができず、それ以外の外部ホストからのパケットは、当該関所型ＮＡＴのルータによって拒絶されてしまう。
もっとも、個々の端末装置は、自己が接続されているルータのタイプを直接認識することはできない。そこで、個々の端末装置が、自己が接続されているルータのタイプを照会することができるように、インターネットＮ上には、ＮＡＴタイプ判別装置が設定されている。このＮＡＴタイプ判別装置は、端末装置からネットワークＮを介してＮＡＴタイプの照会があったときに、当該照会に係る通信を利用して、照会元の端末装置が接続されているルータのＮＡＴタイプを判別し、判別したＮＡＴタイプを照会元の端末装置に回答する処理を行う。
たとえば、図２１に示す例において、ネットワークＮにこのようなＮＡＴタイプ判別装置を接続しておけば、端末装置２００Ａは、このＮＡＴタイプ判別装置に対して照会を行うことにより、自己が接続されているルータＲＡのＮＡＴタイプを知ることができる。すなわち、端末装置２００ＡからルータＲＡを介して、ネットワークＮに接続されているＮＡＴタイプ判別装置に対してＮＡＴタイプの照会を行うと、ＮＡＴタイプ判別装置は、当該照会に係る通信を利用して（ルータＲＡから送信されてくるパケットから得られる様々な情報を利用して）、ルータＲＡのＮＡＴタイプを判別することができる。
ＮＡＴタイプ判別装置は、こうして判別されたルータＲＡのＮＡＴタイプを、ルータＲＡを介して、照会元の端末装置２００Ａに回答する。かくして、端末装置２００Ａは、自己が接続されているルータＲＡのＮＡＴタイプを知ることができる。同様に、端末装置２００Ｂは、同様の方法でＮＡＴタイプ判別装置に対して照会を行うことにより、自己が接続されているルータＲＢのＮＡＴタイプを知ることができる。
このように、端末装置からの照会に基づいて、当該端末装置自身が接続されているルータのＮＡＴタイプ（本願では、自己のＮＡＴタイプと呼ぶ）を判別し、これを照会元の端末装置に回答する処理を行うＮＡＴタイプ判別装置としては、ＳＴＵＮ（Session Traversal Utilities for NATs）サーバと呼ばれている公知の装置を利用することができる。本来、このＳＴＵＮサーバは、ＳＴＵＮプロトコルを用いた通信を可能にするために設置されるサーバであるが、本発明におけるＮＡＴタイプ判別装置として用いることができる。このＳＴＵＮサーバは、既に広く利用されている公知の装置であるので、その構成や具体的な処理内容についての説明は、ここでは省略する。
このように、図２１に示す例において、ネットワークＮにＮＡＴタイプ判別装置（ＳＴＵＮサーバ）を接続しておけば、各端末装置２００Ａ，２００Ｂは、自己が接続されているルータＲＡ，ＲＢのＮＡＴタイプを知ることができる。そこで、各端末装置２００Ａ，２００Ｂが、自己アドレスを接続仲介装置１００に通知する際に、自己が接続されているルータＲＡ，ＲＢのＮＡＴタイプを併せて通知するようにすれば、接続仲介装置１００は、個々の端末装置のアドレスとともに、当該端末装置自身が接続されているルータのＮＡＴタイプ（自己のＮＡＴタイプ）を知ることができる。
したがって、接続仲介装置１００は、通信元の端末装置から通信先の端末装置への接続仲介依頼があったときに、両端末装置が接続されているルータについてのＮＡＴタイプを調べることにより、両端末間に関所型ＮＡＴのルータが存在しているか否かを把握することができ、両端末間でこのまま通常通信を行ったとすると、両端末間に存在する関所型ＮＡＴのルータによって当該通常通信が失敗することを予想することができる。そこで、接続仲介装置１００は、関所型ＮＡＴのルータの存在によって、通常通信の失敗が予測されるときには、端末装置に対して、通常通信の代わりに迂回通信を行う旨の指示を与えることができる。このような指示を受けた端末装置は、§６で述べた方法と同様の方法で迂回通信を行うことになる。
このように、この§７で述べる実施形態では、個々の端末装置が、接続仲介装置に対して自己アドレスの通知を行う際に、自己が接続されたルータのＮＡＴタイプ（自己のＮＡＴタイプ）も併せて通知しておく。そして、接続仲介装置が通信元の端末装置から通信先の端末装置への接続仲介依頼を受けたときに、両端末間における関所型ＮＡＴのルータの存在によって通常通信の失敗が予想される場合には、迂回通信を指示するようにし、この指示に基づいて両端末間で迂回通信を行うようにする。
以下、このような通信方法を、§１に示す先願基本発明の第１の実施形態（図２）に適用した例を実施例３として説明し、§２に示す先願基本発明の第２の実施形態（図７）に適用した例を実施例４として説明する。もちろん、以下に述べる実施例３，４については、§３や§４で述べた各種変形例を適用することも可能である。なお、各実施例３，４にブロックとして示されている各構成要素は、これまで述べた先願基本発明に係るシステムと同様に、実際には、コンピュータに組み込まれた専用のプログラムによって実現されることになる。
＜７−１． 実施例３＞
図２８は、本発明の実施例３に係るネットワーク通信システムにおける端末装置２０３の詳細構成を示すブロック図である。ここに示す端末装置２０３は、図２に示す先願基本発明の第１の実施形態に係る端末装置２００における通信開始要求部２４０および自己アドレス通知部２５０に、若干の修正を加えてそれぞれ通信開始要求部２４３および自己アドレス通知部２５３とし、更に、新たな構成要素として、迂回通信処理部２７３およびＮＡＴタイプ確認部２８３（図では新たな構成要素を太線枠ブロックで示す）を付加したものである。その他の構成要素である接続仲介依頼部２１０、通信要求受付部２２０、通信先セッション確立部２３０、通信元セッション確立部２６０は、図２に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§１で述べたとおりである。
また、この図２８に示す実施例３では、図２に示す接続仲介装置１００の代わりに、接続仲介装置１０３が用いられている。この接続仲介装置１０３は、図２に示す接続仲介装置１００の機能に、通信方法（通常通信か迂回通信か）を指示する機能と、迂回通信を中継する機能とを付加したものであり、その構成の詳細は後述する。結局、図２８に示す実施例３において、３桁の数字からなる符号における１の位が「３」となっているブロックで示される構成要素が、実施例３に固有の構成要素ということになる。
なお、図２８には、ＮＡＴタイプ判別装置５００が記載されている。このＮＡＴタイプ判別装置５００は、前述したとおり、端末装置２０３からネットワークＮを介してＮＡＴタイプの照会があったときに、当該照会に係る通信を利用して、照会元の端末装置２０３のＮＡＴタイプを判別し、判別したＮＡＴタイプを照会元の端末装置に回答する処理を行う。実際には、ＳＴＵＮサーバをＮＡＴタイプ判別装置５００として利用できる点は、既に述べたとおりである。
図示する実施例３は、本発明に係るネットワーク通信システムとは別個に利用されているＳＴＵＮサーバを、本発明に係るＮＡＴタイプ判別装置５００として流用した例である。もちろん、接続仲介装置１０３を構成するサーバ装置内に、本発明のための専用のＳＴＵＮサーバを用意してもかまわない。この場合、同一サーバ装置内に、接続仲介装置１０３とＮＡＴタイプ判別装置５００（本発明のための専用のＳＴＵＮサーバ）が組み込まれることになり、ＮＡＴタイプ判別装置５００は、本発明に係るネットワーク通信システムの構成要素の１つになる。
この実施例３に係るシステムは、図２に示す先願発明のシステムと同様に、ネットワークＮを介して相互に接続可能な複数の端末装置（図には、便宜上、１台の端末装置２０３のみが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置１０３と、を備えたネットワーク通信システムである。ここで、各端末装置２０３には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置１０３は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。
この図における太線矢印は、端末装置２０３と接続仲介装置１０３との間でやりとりされる信号の流れを示しており、細線矢印（ブロック２０３内部の矢印を除く）は、一対の端末装置２０３の間で直接的にやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置２０３の間で直接的にやりとりされる、通信セッション確立後の信号の流れを示している。この白抜矢印には、「通常通信」なる表記がなされているが、これはこのシステムが想定する本来の通信、すなわち、端末装置２０３間で直接的に行われる通信を示している。これに対して、迂回通信処理部２７３から伸びる太線矢印には、「迂回通信」なる表記がなされているが、これは、上述した「通常通信」の失敗が予想されるときに、端末装置２０３が接続仲介装置１０３を介して間接的に相手方への通信を行うことを示している。
図２８に示す自己アドレス通知部２５３は、図２に示す自己アドレス通知部２５０と同様に、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１０３に対して通知する機能を果たす。この自己アドレス通知機能については、既に§１で詳述したとおりである。ただ、自己アドレス通知部２５３は、この自己アドレス通知機能に加えて、自己が接続されているルータ（図２８には示されていない）のＮＡＴタイプを接続仲介装置１０３に対して併せて通知する付加的な機能を有している。
この付加機能は、新たな構成要素であるＮＡＴタイプ確認部２８３の助けを借りて行われる。ＮＡＴタイプ確認部２８３は、ネットワークＮを介してＮＡＴタイプ判別装置５００に対して自己のＮＡＴタイプを照会し、ＮＡＴタイプ判別装置５００からの回答を得る機能をもった構成要素である。図における太い一点鎖線の矢印は、ＮＡＴタイプ確認部２８３とＮＡＴタイプ判別装置５００との間でやりとりされる照会および回答の信号の流れを示している。もちろん、この信号は、図示されていないルータおよびネットワークＮを介してやりとりされることになる。
この実施例３に係る端末装置２０３が相手方に対する通信を行う前に、図２９の流れ図に示されている事前処理が実行される。まず、自己アドレス通知部２５３が、接続仲介装置１０３に対して自己の所在アドレスを通知する際（前述したとおり、自己アドレスの通知は、予め定められた所定のタイミングで実行される）に、ステップＳ３１において、ＮＡＴタイプ確認部２８３に対してＮＡＴタイプ確認指示を出す。ＮＡＴタイプ確認部２８３は、このＮＡＴタイプ確認指示を受けると、ステップＳ３２において、ＮＡＴタイプ判別装置５００に対して自己のＮＡＴタイプを照会する（図２８の太い一点鎖線の矢印）。
ＮＡＴタイプ判別装置５００は、端末装置２０３のＮＡＴタイプ確認部２８３からネットワークＮを介してＮＡＴタイプの照会があったときに、当該照会に係る通信を利用して、照会元の端末装置２０３のＮＡＴタイプ（端末装置２０３が接続されているルータのＮＡＴタイプ）を判別し、ステップＳ３３において、判別したＮＡＴタイプを照会元の端末装置２０３のＮＡＴタイプ確認部２０３に回答する処理を行う。具体的な処理方法は、ＳＴＵＮサーバの処理として公知であるため、ここでは詳細な説明は省略する。
ＮＡＴタイプ確認部２８３は、続くステップＳ３４において、ステップＳ３３で得られた回答（ＮＡＴタイプ）を自己アドレス通知部２５３に報告する。当該報告を受けた自己アドレス通知部２５３は、当該報告に基づいて、ステップＳ３５において、ステップＳ３３で得られた回答（ＮＡＴタイプ）を接続仲介装置１０３に対して、自己アドレスとともに通知する。
このように、実施例３では、自己アドレス通知部２５３が、接続仲介装置１０３に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部２８３が得た回答を併せて通知することになる。したがって、図２８において、自己アドレス通知部２５３からネットワークＮに向かう太線矢印は、端末装置２０３の所在アドレスの情報とともに、端末装置２０３が接続されているルータ（図示されていない）のＮＡＴタイプの情報を含む信号になる。
こうして、接続仲介装置１０３には、各端末装置２０３から、所在アドレスの情報とＮＡＴタイプの情報とが通知されるので、接続仲介装置１０３内のアドレステーブルには、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけた情報が格納される。すなわち、図２９の流れ図のステップＳ３６において、接続仲介装置１０３内のアドレステーブル更新部１２３によって、ＮＡＴタイプを含めたアドレステーブルの更新が行われる。図３０は、このような更新によって作成されたアドレステーブルＴ６０を示す図である。このアドレステーブルＴ６０は、図６に示すアドレステーブルＴと同様に、４組の端末装置から通知された所在アドレスを示すものであるが、所在アドレスに加えて、ＮＡＴタイプの情報（右欄）も記録されている。
前述したように、ＮＡＴタイプには、「Full cone NAT」，「Restricted cone NAT」，「Port restricted cone NAT」，「Symmetric NAT」等のタイプが実用されているが、§５で述べたとおり、通常通信の妨げになるのは「関所型ＮＡＴ」（「Symmetric NAT」および「Port restricted cone NAT」）であるので、図３０に示すアドレステーブルＴ６０では、接続されているルータのＮＡＴタイプが「関所型ＮＡＴ」である端末装置については「関所型」なるデータを記録し、それ以外の端末装置については「非関所型」なるデータを記録している。もちろん、「Full cone NAT」などの実際のＮＡＴタイプを示すデータを記録するようにしてもかまわない。
図２９の流れ図に示されている事前処理が済めば、図２８に示す実施例３に係るネットワーク通信システムにおける通信準備は完了である。自己アドレス通知部２５３による所在アドレスおよびＮＡＴタイプの通知は、所定タイミングで繰り返し実行されるので、接続仲介装置１０３内のアドレステーブルＴ６０には、各端末装置について、常に最新の所在アドレスおよびＮＡＴタイプが格納されることになる。そこで、接続仲介装置１０３は、特定の通信元端末装置から特定の通信先端末装置への接続仲介依頼が来たときに、アドレステーブルＴ６０を参照して、両端末間で通常通信を行った場合に、「関所型ＮＡＴ」が設定されたルータにより当該通常通信に支障が生じるか否かを判断し、支障なしと判断される場合には通常通信を選択し、支障ありと判断される場合には迂回通信を選択する。
そして、接続仲介装置１０３から通信元端末装置２０３の通信開始要求部２４３に対して、通信先アドレスを返信する際に、選択した通信方法を示す情報（通常通信か、迂回通信かを示す情報）を併せて返信する。したがって、図２８において、ネットワークＮから通信開始要求部２４３に向かう太線矢印は、通信先アドレスの情報とともに通信方法の情報を含む信号になる。
通信開始要求部２４３は、接続仲介装置１０３から通信先アドレスと共に通信方法が返信されてきたとき、通信方法として通常通信が選択されていた場合には、先願基本発明の第１の実施形態と同様に、ネットワークＮを介して、通信先アドレスにアクセスして通信開始要求を行う。以後の通信手順は、§１で述べたとおりである。一方、通信方法として迂回通信が選択されていた場合には、迂回通信処理部２７３に対して迂回通信指示を行う。
迂回通信処理部２７３は、§６で述べた実施例１における迂回通信処理部２７１と同様に、接続仲介装置１０３を介した迂回通信を行う構成要素である。すなわち、迂回通信処理部２７３は、通常通信（図の白抜矢印で示された通信）の失敗が予想されるときに、接続仲介装置１０３を介して相手方に対する間接的な情報送受を行う迂回通信を実行する。上述したとおり、失敗予想は、接続仲介装置１０３において行われる。通信開始要求部２４３が接続仲介装置１０３から迂回通信を選択する通信方法を受け取った場合、接続仲介装置１０３が失敗予想を行ったケースにあたる。この場合、通信開始要求部２４３から迂回通信処理部２７３に対して迂回通信指示が行われ、迂回通信処理部２７３による迂回通信が実行される。具体的には、迂回通信処理部２７３は、接続仲介装置１０３（後述するように、その中の迂回通信中継部１４３）に対して迂回通信の中継依頼を行い、接続仲介装置１０３を介して、相手方の迂回通信処理部２７３との間での迂回通信を実行することになる。
図３１は、図２８に示す本発明の実施例３に係るネットワーク通信システムにおいて、通信元端末装置２０３Ａと通信先端末装置２０３Ｂとの間の通信セッション確立の手順を示すブロック図である。図示する端末装置２０３Ａ，２０３Ｂは、図２８に示す端末装置２０３と同一の構成を有する装置であり、図４と同様に、通信元端末装置２０３Ａ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）を実線で示し、通信先端末装置２０３Ｂ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）を実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。また、実施例３に固有の構成要素である迂回通信処理部２７３Ａ，２７３ＢおよびＮＡＴタイプ確認部２８３Ａ，２８３Ｂについては太線枠ブロックで示してある。
図３１に示す接続仲介装置１０３（図２８に示すもの）は、図４に示す接続仲介装置１００に、迂回通信中継部１４３を追加するとともに、その他の構成要素であるアドレステーブル格納部１１０、アドレステーブル更新部１２０、通信先アドレス返信部１３０については、若干の付加機能を設けることにより、アドレステーブル格納部１１３、アドレステーブル更新部１２３、通信先アドレス返信部１３３としたものである。
接続仲介装置１０３内の迂回通信中継部１４３は、第１の端末装置２０３Ａの迂回通信処理部２７３Ａと第２の端末装置２０３Ｂの迂回通信処理部２７３Ｂとの間での迂回通信の中継依頼があったときに、第１の端末装置２０３Ａの迂回通信処理部２７３Ａと第２の端末装置２０３Ｂの迂回通信処理部２７３Ｂとの間で受け渡しする情報を取り次いで迂回通信の中継を行う構成要素である。
また、接続仲介装置１０３内のアドレステーブル格納部１１３は、図３０に例示したように、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけたアドレステーブルＴ６０を格納する機能を有する。そして、接続仲介装置１０３内のアドレステーブル更新部１２３は、自己アドレス通知部２５３からの通知に含まれるＮＡＴタイプを示す情報に基づいて、アドレステーブルＴ６０内のＮＡＴタイプの更新を行う付加機能を有する。
一方、接続仲介装置１０３内の通信先アドレス返信部１３３は、通信元端末装置２０３Ａ内の接続仲介依頼部２１０Ａから接続仲介依頼Ｓ２が送信されてきたときに、アドレステーブルＴ６０を参照して、接続仲介依頼Ｓ２に含まれている通信先特定情報によって特定される端末ＩＤ「００２０」に対応づけられている所在アドレスＡＤ２を通信先アドレスとして返信するとともに、通信先の端末装置２０３ＢのＮＡＴタイプを確認し、通信先の端末装置２０３ＢのＮＡＴタイプが関所型ＮＡＴではなかった場合には、通信方法として通常通信を選択し、通信先の端末装置２０３ＢのＮＡＴタイプが関所型ＮＡＴであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有する。
この図３１に示す例において、アドレステーブル格納部１１３内に図３０のようなアドレステーブルＴ６０が格納されていた場合、通信先の端末装置２０３Ｂ（端末ＩＤ：００２０）のＮＡＴタイプは「関所型」になっているので、通信先アドレス返信部１３３は、通信方法として迂回通信を選択する。通信先端末装置２０３Ｂが関所型ＮＡＴということは、§５で述べたとおり、通信元端末装置２０３Ａから通信先端末装置２０３Ｂへ、直接的に通信開始要求Ｓ５を行った場合、通信先端末装置２０３ＢのルータＲＢによって、当該通信開始要求Ｓ５がブロックされてしまう可能性がある。この場合、通信先アドレス返信部１３３は、通信方法として迂回通信を選択することになる。図３１には、通信先アドレス返信部１３３から通信開始要求部２４３Ａに対して、通信先アドレス「ＡＤ２」および通信方法「迂回通信」を示す情報が返信された例（図３１の太線矢印Ｓ４ａ）が示されている。これに対して、通信先の端末装置２０３ＢのＮＡＴタイプが「非関所型」になっていれば、通信先アドレス返信部１３３は、通信方法として通常通信を選択することになる。
通信元端末装置２０３Ａ内の通信開始要求部２４３Ａは、通信先アドレス返信部１３３から「通常通信」を選択する返信が戻ってきた場合、通常通信の処理を行う。具体的には、通信開始要求部２４３Ａが、通信先アドレスＡＤ２にアクセスして通信開始要求Ｓ５を行うと、相手方の通信先セッション確立部２３０Ｂから通信元セッション確立部２６０Ａに対して通信開始受諾確認Ｓ６が送信される。こうして、通信元セッション確立部２６０Ａと通信先セッション確立部２３０Ａとの間に通信セッションが確立する。
一方、通信先アドレス返信部１３３から「迂回通信」を選択する返信が戻ってきた場合、通信開始要求部２４３Ａは、迂回通信の処理を行う。すなわち、通信開始要求部２４３Ａは、通信開始要求Ｓ５を行う代わりに、迂回通信処理部２７３Ａに対して、迂回通信指示Ｓ５′を行う。迂回通信処理部２７３Ａは、この迂回通信指示Ｓ５′を受けると、迂回通信中継部１４３に対して迂回通信の中継依頼を行い、迂回通信中継部１４３を介して、相手方の迂回通信処理部２７３Ｂとの間での迂回通信Ｓ８ａを実行する。迂回通信処理部２７３Ａは、通信開始要求部２４３Ａから通信先アドレスＡＤ２を取得し、これを迂回通信中継部１４３に伝達して中継依頼を行う。迂回通信中継部１４３は、この中継依頼に応じて、通信先アドレスＡＤ２にアクセスし、通信先端末装置２０３Ｂの迂回通信処理部２７３Ｂに迂回通信の開始を要求する。迂回通信処理部２７３Ｂは、これを受諾する旨の返信を迂回通信中継部１４３に対して行い、迂回通信Ｓ８ｂを実行する。以後、迂回通信中継部１４３による中継により、両端末装置２０３Ａ，２０３Ｂ間での迂回通信が行われる。
この迂回通信では、両端末装置２０３Ａ，２０３Ｂ間の情報パケットは、すべて接続仲介装置１０３を介してやりとりされることになる。§５で述べたように、両端末装置２０３Ａ，２０３Ｂ間の直接的な通信が関所型ＮＡＴのルータによってブロックされるとしても、両端末装置２０３Ａ，２０３Ｂ間の迂回通信は、接続仲介装置１０３を中継する通信になるため、支障なく行われる。
図３２は、図３１のブロック図に示されている実施例３における通信セッション確立手順を時系列で説明する流れ図である。この流れ図における通常通信の手順は、§１で述べた先願発明の第１の実施形態における通信セッション確立手順を示す図５の流れ図とほぼ同じである。
まず、ステップＳ１において、通信要求受付部２２０Ａによる通信要求受付処理が行われ、続くステップＳ２において、接続仲介依頼部２１０Ａによる接続仲介依頼が行われる。そしてステップＳ３において、通信先アドレス返信部１３３によりアドレステーブル格納部１１３に格納されているアドレステーブルＴ６０の参照が行われ、ステップＳ４ａにおいて、通信先アドレス返信部１３３から通信開始要求部２４３Ａに対して、通信先アドレスおよび通信方法が返信される。この返信を受けた通信開始要求部２４３Ａは、ステップＳ４ｂにおいて、２通りの処理プロセスのいずれかを選択する。
まず、通信先アドレス返信部１３３によって、通信方法として「通常通信」が指示されていた場合には、ステップＳ５へ進む。図３２の流れ図におけるステップＳ５〜Ｓ７の手順は、図５の流れ図におけるステップＳ５〜Ｓ７の手順と全く同じである。すなわち、通信開始要求部２４３Ａは、ステップＳ５において、通信先端末装置２０３Ｂに対して通信開始要求Ｓ５を行う。通信先セッション確立部２３０Ｂは、この通信開始要求Ｓ５を受け、ステップＳ６において、通信元端末装置２０３Ａに対して通信開始受諾確認Ｓ６を送信する。そして、続くステップＳ７において、通信先セッション確立部２３０Ｂと通信元セッション確立部２６０Ａとの間の通信セッションが確立され、通常通信Ｓ７が行われる。
一方、通信方法として「迂回通信」が指示されていた場合には、ステップＳ５′へ進み、通信開始要求部２４３Ａから迂回通信処理部２７３Ａに対して迂回通信指示が与えられる。そして続くステップＳ８において、迂回通信処理が実行される。すなわち、迂回通信処理部２７３Ａ，２７３Ｂと迂回通信中継部１４３によって、迂回通信処理が行われる（図３１のＳ８ａ，Ｓ８ｂ）。
＜７−２． 実施例４＞
図３３は、本発明の実施例４に係るネットワーク通信システムにおける端末装置４０４の詳細構成を示すブロック図である。ここに示す端末装置４０４は、図７に示す先願基本発明の第２の実施形態に係る端末装置４００における通信開始要求部４４０および自己アドレス通知部４５０に、若干の修正を加えてそれぞれ通信開始要求部４４４および自己アドレス通知部４５４とし、更に、新たな構成要素として、迂回通信処理部４７４およびＮＡＴタイプ確認部４８４（図では新たな構成要素を太線枠ブロックで示す）を付加したものである。その他の構成要素である接続仲介依頼部４１０、通信要求受付部４２０、通信元セッション確立部４３０、通信先セッション確立部４６０は、図７に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§２で述べたとおりである。
また、この図３３に示す実施例４では、図７に示す接続仲介装置３００の代わりに、接続仲介装置３０４が用いられている。この接続仲介装置３０４は、図７に示す接続仲介装置３００の機能に、通信方法（通常通信か迂回通信か）を指示する機能と、迂回通信を中継する機能とを付加したものであり、その構成の詳細は後述する。結局、図３３に示す実施例４において、３桁の数字からなる符号における１の位が「４」となっているブロックで示される構成要素が、実施例４に固有の構成要素ということになる。
なお、図３３には、ＮＡＴタイプ判別装置５００が記載されている。このＮＡＴタイプ判別装置５００は、図２８に示す装置５００と同じ装置であり、端末装置４０４からネットワークＮを介してＮＡＴタイプの照会があったときに、当該照会に係る通信を利用して、照会元の端末装置４０４のＮＡＴタイプを判別し、判別したＮＡＴタイプを照会元の端末装置に回答する処理を行う。前述のとおり、実際には、ＳＴＵＮサーバをＮＡＴタイプ判別装置５００として利用でき、本発明に係るネットワーク通信システムとは別個に利用されているＳＴＵＮサーバを、本発明に係るＮＡＴタイプ判別装置５００として流用することもできるし、接続仲介装置３０４を構成するサーバ装置内に、本発明のための専用のＳＴＵＮサーバを用意してもかまわない。後者の場合、同一サーバ装置内に、接続仲介装置３０４とＮＡＴタイプ判別装置５００（本発明のための専用のＳＴＵＮサーバ）が組み込まれることになり、ＮＡＴタイプ判別装置５００は、本発明に係るネットワーク通信システムの構成要素の１つになる。
この実施例４に係るシステムは、図７に示す先願発明のシステムと同様に、ネットワークＮを介して相互に接続可能な複数の端末装置（図には、便宜上、１台の端末装置４０２のみが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置３０４と、を備えたネットワーク通信システムである。ここで、各端末装置４０４には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置３０４は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。
この図においても、これまで述べてきた各実施例と同様に、太線矢印、細線矢印、白抜矢印の３種類の矢印が用いられている。白抜矢印は「通常通信」を示し、迂回通信処理部４７４から伸びる太線矢印は「迂回通信」を示している。実施例３と同様に、この実施例４でも、本来は「通常通信」を行うことが意図されているが、「通常通信」の失敗が予想されるときには、端末装置４０４が接続仲介装置３０４を介して間接的に相手方への通信を行うことになる。
図３３に示す自己アドレス通知部４５４は、図２８に示す実施例３の自己アドレス通知部２５３と同様の機能を有している。すなわち、自己アドレス通知部４５４は、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置３０４に対して通知するとともに、自己が接続されているルータ（図２８には示されていない）のＮＡＴタイプを接続仲介装置３０４に対して併せて通知する付加的な機能を有している。
この付加機能は、新たな構成要素であるＮＡＴタイプ確認部４８４の助けを借りて行われる。このＮＡＴタイプ確認部４８４は、図２８に示す実施例３のＮＡＴタイプ確認部２８３と同様に、ネットワークＮを介してＮＡＴタイプ判別装置５００に対して自己のＮＡＴタイプを照会し、ＮＡＴタイプ判別装置５００からの回答を得る機能をもった構成要素である。図における太い一点鎖線の矢印は、ＮＡＴタイプ確認部４８４とＮＡＴタイプ判別装置５００との間でやりとりされる照会および回答の信号の流れを示している。もちろん、この信号は、図示されていないルータおよびネットワークＮを介してやりとりされることになる。
この実施例４に係る端末装置４０４が相手方に対する通信を行う前には、実施例３と同様に、図２９の流れ図に示されている事前処理が実行される。この事前処理については、既に§７−１で述べたため、ここでは説明を省略する。
図２９の流れ図に示されている事前処理が済めば、図３３に示す実施例４に係るネットワーク通信システムにおける通信準備は完了である。事前処理により、接続仲介装置３０４内のアドレステーブルＴ６０には、各端末装置について、最新の所在アドレスおよびＮＡＴタイプが格納されているので、接続仲介装置３０４は、特定の通信元端末装置から特定の通信先端末装置への接続仲介依頼が来たときに、アドレステーブルＴ６０を参照して、両端末間で通常通信を行った場合に、「関所型ＮＡＴ」が設定されたルータにより当該通常通信に支障が生じるか否かを判断し、支障なしと判断される場合には通常通信を選択し、支障ありと判断される場合には迂回通信を選択する。
前述した実施例３の場合、通信元端末装置２０３が接続仲介装置１０３に対して接続仲介依頼Ｓ２を行うと、当該通信元端末装置２０３に対して、通信先アドレスおよび通信方法が返信される。これに対して、ここで述べる実施例４の場合、通信元端末装置４０４が接続仲介装置３０４に対して接続仲介依頼Ｓ１２を行うと、当該通信元端末装置４０４ではなく、通信先の別な端末装置４０４に対して、「通信元アドレス」および「通信方法」が送信されることになる。ここで、「通信方法」とは、既に述べたとおり、通常通信か、迂回通信かを示す情報である。したがって、図３３において、ネットワークＮから通信先の通信開始要求部４４４（図３３では、通信先の構成要素であるため、二重枠のブロックで示されている）に向かう太線矢印は、通信元アドレスの情報とともに通信方法の情報を含む信号になる。
通信開始要求部４４４は、接続仲介装置３０４から通信元アドレスと共に通信方法が返信されてきたとき、通信方法として通常通信が選択されていた場合には、先願基本発明の第２の実施形態と同様に、ネットワークＮを介して、通信元アドレスにアクセスして通信開始要求を行う。以後の通信手順は、§２で述べたとおりである。一方、通信方法として迂回通信が選択されていた場合には、迂回通信処理部４７４に対して迂回通信指示を行う。
迂回通信処理部４７４は、§７−１で述べた実施例３における迂回通信処理部２７３と同様に、接続仲介装置３０４を介した迂回通信を行う構成要素である。すなわち、迂回通信処理部４７４は、通常通信（図の白抜矢印で示された通信）の失敗が予想されるときに、接続仲介装置３０４を介して相手方に対する間接的な情報送受を行う迂回通信を実行する。上述したとおり、失敗予想は、接続仲介装置３０４において行われる。通信開始要求部４４４が接続仲介装置３０４から迂回通信を選択する通信方法を受け取った場合、接続仲介装置３０４が失敗予想を行ったケースにあたる。この場合、通信開始要求部４４４から迂回通信処理部４７４に対して迂回通信指示が行われ、迂回通信処理部４７４による迂回通信が実行される。具体的には、迂回通信処理部４７４は、接続仲介装置３０４（後述するように、その中の迂回通信中継部３４４）に対して迂回通信の中継依頼を行い、接続仲介装置３０４を介して、相手方の迂回通信処理部４７４との間での迂回通信を実行することになる。
図３４は、図３３に示す本発明の実施例４に係るネットワーク通信システムにおいて、通信元端末装置４０４Ａと通信先端末装置４０４Ｂとの間の通信セッション確立の手順を示すブロック図である。図示する端末装置４０４Ａ，４０４Ｂは、図３３に示す端末装置４０４と同一の構成を有する装置であり、図８と同様に、通信元端末装置４０４Ｂ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）を実線で示し、通信先端末装置４０４Ａ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）を実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。また、実施例４に固有の構成要素である迂回通信処理部４７４Ａ，４７４ＢおよびＮＡＴタイプ確認部４８４Ａ，４８４Ｂについては太線枠ブロックで示してある。
図３４に示す接続仲介装置３０４（図３３に示すもの）は、図８に示す接続仲介装置３００に、迂回通信中継部３４４を追加するとともに、その他の構成要素であるアドレステーブル格納部３１０、アドレステーブル更新部３２０、通信元アドレス送信部３３０については、若干の付加機能を設けることにより、アドレステーブル格納部３１４、アドレステーブル更新部３２４、通信元アドレス送信部３３４としたものである。
接続仲介装置３０４内の迂回通信中継部３４４は、第１の端末装置４０４Ａの迂回通信処理部４７４Ａと第２の端末装置４０４Ｂの迂回通信処理部４７４Ｂとの間での迂回通信の中継依頼があったときに、第１の端末装置４０４Ａの迂回通信処理部４７４Ａと第２の端末装置４０４Ｂの迂回通信処理部４７４Ｂとの間で受け渡しする情報を取り次いで迂回通信の中継を行う構成要素である。
また、接続仲介装置３０４内のアドレステーブル格納部３１４は、図３０に例示したように、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけたアドレステーブルＴ６０を格納する機能を有する。そして、接続仲介装置３０４内のアドレステーブル更新部３２４は、自己アドレス通知部４５４からの通知に含まれるＮＡＴタイプを示す情報に基づいて、アドレステーブルＴ６０内のＮＡＴタイプの更新を行う付加機能を有する。
一方、接続仲介装置３０４内の通信元アドレス送信部３３４は、通信元端末装置４０４Ｂ内の接続仲介依頼部４１０Ｂから接続仲介依頼Ｓ１２が送信されてきたときに、アドレステーブルＴ６０を参照して、接続仲介依頼Ｓ１２に含まれている通信先特定情報によって特定される端末ＩＤ「００１０」に対応づけられている所在アドレスＡＤ１を通信先アドレスとして認識し、この通信先アドレスＡＤ１に対して、接続仲介依頼Ｓ１２を送信した通信元の端末装置４０４Ｂの端末ＩＤ「００２０」に対応づけられている所在アドレスＡＤ２を、通信元アドレスとして送信する（Ｓ１４ａ）。
このとき、通信元アドレス送信部３３４は、アドレステーブルＴ６０を参照して、通信元の端末装置４０４ＢのＮＡＴタイプを確認し、通信元の端末装置４０４ＢのＮＡＴタイプが関所型ＮＡＴではなかった場合には、通信方法として通常通信を選択し、通信元の端末装置４０４ＢのＮＡＴタイプが関所型ＮＡＴであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信元アドレスと共に返信する。
この図３４に示す例において、アドレステーブル格納部３１４内に図３０のようなアドレステーブルＴ６０が格納されていた場合、通信元の端末装置４０４Ｂ（端末ＩＤ：００２０）のＮＡＴタイプは「関所型」になっているので、通信元アドレス送信部３３４は、通信方法として迂回通信を選択する。通信元端末装置４０４Ｂが関所型ＮＡＴということは、§５で述べたとおり、通信先端末装置４０４Ａから通信元端末装置４０４Ｂへ、直接的に通信開始要求Ｓ１５を行った場合、通信元端末装置４０４ＢのルータＲＢによって、当該通信開始要求Ｓ１５がブロックされてしまう可能性がある。この場合、通信元アドレス送信部３３４は、通信方法として迂回通信を選択することになる。図３４には、通信元アドレス送信部３３４から通信開始要求部４４４Ａに対して、通信元アドレス「ＡＤ２」および通信方法「迂回通信」を示す情報が送信された例（図３４の太線矢印Ｓ１４ａ）が示されている。これに対して、通信元の端末装置４０４ＢのＮＡＴタイプが「非関所型」になっていれば、通信元アドレス送信部３３４は、通信方法として通常通信を選択することになる。
通信先端末装置４０４Ａ内の通信開始要求部４４４Ａは、通信元アドレス送信部３３４から「通常通信」を選択する送信があった場合、通常通信の処理を行う。具体的には、通信開始要求部４４４Ａが、通信元アドレスＡＤ２にアクセスして通信開始要求Ｓ１５を行うと、相手方の通信元セッション確立部４３０Ｂから通信先セッション確立部４６０Ａに対して通信開始受諾確認Ｓ１６が送信される。こうして、通信元セッション確立部４３０Ｂと通信先セッション確立部４６０Ａとの間に通信セッションが確立する。
一方、通信元アドレス送信部３３４から「迂回通信」を選択する送信があった場合、通信開始要求部４４４Ａは、迂回通信の処理を行う。すなわち、通信開始要求部４４４Ａは、通信開始要求Ｓ１５を行う代わりに、迂回通信処理部４７４Ａに対して、迂回通信指示Ｓ１５′を行う。迂回通信処理部４７４Ａは、この迂回通信指示Ｓ１５′を受けると、迂回通信中継部３４４に対して迂回通信の中継依頼を行い、迂回通信中継部３４４を介して、相手方の迂回通信処理部４７４Ｂとの間での迂回通信Ｓ１８ａを実行する。迂回通信処理部４７４Ａは、通信開始要求部４４４Ａから通信元アドレスＡＤ２を取得し、これを迂回通信中継部３４４に伝達して中継依頼を行う。迂回通信中継部３４４は、この中継依頼に応じて、通信元アドレスＡＤ２にアクセスし、通信元端末装置４０４Ｂの迂回通信処理部４７４Ｂに迂回通信の開始を要求する。迂回通信処理部４７４Ｂは、これを受諾する旨の返信を迂回通信中継部３４４に対して行い、迂回通信Ｓ１８ｂを実行する。以後、迂回通信中継部３４４による中継により、両端末装置４０４Ａ，４０４Ｂ間での迂回通信が行われる。
この迂回通信では、両端末装置４０４Ａ，４０４Ｂ間の情報パケットは、すべて接続仲介装置３０４を介してやりとりされることになる。§５で述べたように、両端末装置４０４Ａ，４０４Ｂ間の直接的な通信が関所型ＮＡＴのルータによってブロックされるとしても、両端末装置４０４Ａ，４０４Ｂ間の迂回通信は、接続仲介装置３０４を中継する通信になるため、支障なく行われる。
図３５は、図３４のブロック図に示されている実施例４における通信セッション確立手順を時系列で説明する流れ図である。この流れ図における通常通信の手順は、§２で述べた先願発明の第２の実施形態における通信セッション確立手順を示す図９の流れ図とほぼ同じである。
まず、ステップＳ１１において、通信要求受付部４２０Ｂによる通信要求受付処理が行われ、続くステップＳ１２において、接続仲介依頼部４１０Ｂによる接続仲介依頼が行われる。そしてステップＳ１３において、通信元アドレス送信部３３４によりアドレステーブル格納部３１４に格納されているアドレステーブルＴ６０の参照が行われ、ステップＳ１４ａにおいて、通信元アドレス送信部３３４から通信先端末装置４０４Ａの通信開始要求部４４４Ａに対して、通信元アドレスおよび通信方法が送信される。この送信を受けた通信開始要求部４４４Ａは、ステップＳ１４ｂにおいて、２通りの処理プロセスのいずれかを選択する。
まず、通信元アドレス送信部３３４によって、通信方法として「通常通信」が指示されていた場合には、ステップＳ１５へ進む。図３５の流れ図におけるステップＳ１５〜Ｓ１７の手順は、図９の流れ図におけるステップＳ１５〜Ｓ１７の手順と全く同じである。すなわち、通信開始要求部４４４Ａは、ステップＳ１５において、通信元端末装置４０４Ｂに対して通信開始要求Ｓ１５を行う。通信元セッション確立部４３０Ｂは、この通信開始要求Ｓ１５を受け、ステップＳ１６において、通信先端末装置４０４Ａに対して通信開始受諾確認Ｓ１６を送信する。そして、続くステップＳ１７において、通信元セッション確立部４３０Ｂと通信先セッション確立部４６０Ａとの間の通信セッションが確立され、通常通信Ｓ１７が行われる。
一方、通信方法として「迂回通信」が指示されていた場合には、ステップＳ１５′へ進み、通信開始要求部４４４Ａから迂回通信処理部４７４Ａに対して迂回通信指示が与えられる。そして続くステップＳ１８において、迂回通信処理が実行される。すなわち、迂回通信処理部４７４Ａ，４７４Ｂと迂回通信中継部３４４によって、迂回通信処理が行われる（図３４のＳ１８ａ，Ｓ１８ｂ）。
＜＜＜ §８． ＵＤＰブロックの場合に迂回通信を行うアプローチ ＞＞＞
この§８で述べる実施例５，６は、先願基本発明に係るシステムにおいて、通常通信が失敗すると予想されるときに、これを事前に検知して迂回通信に切り替える方法を採るものであり、失敗の事前検知というアプローチを採る点において、§７で述べた実施例３，４と共通する。ただ、§７で述べた実施例３，４では、通常通信が関所型ＮＡＴのルータによりブロックされると予想される場合に迂回通信に切り替える方法を採るのに対して、§８で述べる実施例５，６では、通常通信のプロトコルとしてＵＤＰを用いることを前提としたシステムにおいて、ＵＤＰパケットがブロックされる可能性があると予想される場合に迂回通信に切り替える方法を採る。
§５で説明したとおり、通信プロトコルとしてのＴＣＰとＵＤＰは、それぞれ一長一短があり、ＴＣＰでは、通信速度よりも正確さに重点が置かれるのに対して、ＵＤＰでは、正確さよりも通信速度に重点が置かれる。このため、電話などの音声通話を主とするネットワーク通信システムを構築する際には、通常通信のプロトコルとしてＵＤＰを採用して全体の通信負荷を低減させるのが好ましい。ただ、端末間に設置されているファイアウォールが、ＵＤＰパケットをブロックする仕様になっていたりすると、通常通信によってＵＤＰパケットを相手方に届けることができない。一方、ＴＣＰは、Ｗｅｂ閲覧に広く利用されているプロトコルであるため、ＴＣＰパケットをブロックする要素は、実用上、端末装置へのルート上には存在しないと考えてよい。
この§８で述べる実施例５，６は、通常通信のプロトコルとしてＵＤＰを採用することを前提とするシステムに係るものであるが、ＵＤＰブロックにより通常通信を行うことができないことが予想される場合には、ＵＤＰによる通常通信に代えて、ＴＣＰなどのプロトコルを用いた迂回通信を行うことによって、両者間での通信を行うようにしたものである。
ここで、個々の端末装置に至るルート上に、ＵＤＰパケットをブロックする要素が有るか否かを判定する際には、自己アドレス通知部によって行われる自己の所在アドレスの通知処理を利用する。§１，§２で述べたように、自己アドレス通知部は、所定のタイミングで、自己アドレスを接続仲介装置に通知する働きをする。そこで、以下に述べる実施例５，６では、自己アドレス通知部が、自己アドレスを通知する際に、まず、通信プロトコルとしてＵＤＰを用いた第１回通知を行い、当該第１回通知に失敗した場合には、続いて、通信プロトコルとしてＴＣＰを用いた第２回通知を行うようにする。
このような方法で自己アドレスの通知を行うようにすれば、接続仲介装置は、アドレステーブルを作成する際に、個々の端末装置からの自己アドレス通知が、ＵＤＰを用いた通信プロトコルで行われたか、ＴＣＰを用いた通信プロトコルで行われたか、を認識することができ、アドレステーブルに当該通信プロトコルを記録することができる。当該通信プロトコルの記録は、個々の端末装置がＵＤＰを用いた通常通信を行うことができるか否かを示す情報になる。
すなわち、通信プロトコルの記録が「ＵＤＰ」となっている端末装置は、通信プロトコルとしてＵＤＰを用いた第１回通知により自己アドレスの通知を行うことに成功した端末装置であるため、少なくとも当該端末装置と接続仲介装置との間の通信ルート上には、ＵＤＰパケットをブロックする要素が存在しないと判断できるので、当該端末装置と接続仲介装置との間に係る限りにおいて、ＵＤＰを用いた通常通信に支障は生じないことになる。これに対して、通信プロトコルの記録が「ＴＣＰ」となっている端末装置は、通信プロトコルとしてＵＤＰを用いた第１回通知による自己アドレスの通知に失敗した端末装置であるため、当該端末装置と接続仲介装置との間の通信ルート上には、ＵＤＰパケットをブロックする要素が存在すると判断できる。もちろん、端末装置と接続仲介装置との間の通信ルートと、端末装置と別な端末装置との間の通信ルートとは、同一ではないので、前者のルートでＵＤＰ通信が失敗もしくは成功したからと言って、必ずしも後者のルートでＵＤＰ通信が失敗もしくは成功するとは限らない。ただ、特定の端末装置と接続仲介装置との間でＵＤＰ通信が失敗した場合は、当該特定の端末装置と別な端末装置との間でのＵＤＰ通信も失敗する可能性が高い。
したがって、接続仲介装置１００は、通信元の端末装置から通信先の端末装置への接続仲介依頼があったときに、両端末装置についてアドレステーブルに記録されている通信プロトコルを調べることにより、両端末間にＵＤＰパケットをブロックする要素が存在する可能性を把握することができ、両端末間での通常通信に支障が生じるかどうかを予想することができる。すなわち、通信元の端末装置と通信先の端末装置とのうち、少なくともいずれか一方についてアドレステーブルに記録されている通信プロトコルが「ＵＤＰ」であった場合には、両端末間でやりとりされるＵＤＰパケットはブロックされる可能性があり、両端末間でのＵＤＰを用いた通常通信は失敗する可能性があることが予想される。そこで、接続仲介装置は、ＵＤＰを用いた通常通信の失敗が予測されるときには、端末装置に対して、通常通信の代わりに迂回通信を行う旨の指示を与えることができる。このような指示を受けた端末装置は、§６や§７で述べた方法と同様の方法で迂回通信を行うことになる。
以下、このような通信方法を、§１に示す先願基本発明の第１の実施形態（図２）に適用した例を実施例５として説明し、§２に示す先願基本発明の第２の実施形態（図７）に適用した例を実施例６として説明する。もちろん、以下に述べる実施例５，６については、§３や§４で述べた各種変形例を適用することも可能である。なお、各実施例５，６にブロックとして示されている各構成要素は、これまで述べた先願基本発明に係るシステムと同様に、実際には、コンピュータに組み込まれた専用のプログラムによって実現されることになる。
＜８−１． 実施例５＞
図３６は、本発明の実施例５に係るネットワーク通信システムにおける端末装置２０５の詳細構成を示すブロック図である。ここに示す端末装置２０５は、図２に示す先願基本発明の第１の実施形態に係る端末装置２００における通信開始要求部２４０および自己アドレス通知部２５０に、若干の修正を加えてそれぞれ通信開始要求部２４５および自己アドレス通知部２５５とし、更に、新たな構成要素として、迂回通信処理部２７５（図では新たな構成要素を太線枠ブロックで示す）を付加したものである。
また、通信先セッション確立部２３０および通信元セッション確立部２６０は、それぞれ通信先セッション確立部２３５および通信元セッション確立部２６５に置き換えられている。通信先セッション確立部２３５および通信元セッション確立部２６５の基本機能は、図２に示す通信先セッション確立部２３０および通信元セッション確立部２６０と同様であるが、通信プロトコルがＵＤＰに限定されている点が異なっている。すなわち、この実施例５に示すネットワーク通信システムでは、通常通信のプロトコルはＵＤＰに固定されていることになる。その他の構成要素である接続仲介依頼部２１０および通信要求受付部２２０は、図２に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§１で述べたとおりである。
また、この図３６に示す実施例５では、図２に示す接続仲介装置１００の代わりに、接続仲介装置１０５が用いられている。この接続仲介装置１０５は、図２に示す接続仲介装置１００の機能に、通信方法（通常通信か迂回通信か）を指示する機能と、迂回通信を中継する機能とを付加したものであり、その構成の詳細は後述する。結局、図３６に示す実施例５において、３桁の数字からなる符号における１の位が「５」となっているブロックで示される構成要素が、実施例５に固有の構成要素ということになる。
この実施例５に係るシステムは、図２に示す先願発明のシステムと同様に、ネットワークＮを介して相互に接続可能な複数の端末装置（図には、便宜上、１台の端末装置２０５のみが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置１０５と、を備えたネットワーク通信システムである。ここで、各端末装置２０５には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置１０５は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。
この図における太線矢印は、端末装置２０５と接続仲介装置１０５との間でやりとりされる信号の流れを示しており、細線矢印（ブロック２０５内部の矢印を除く）は、一対の端末装置２０５の間で直接的にやりとりされる、通信セッション確立前の信号の流れを示している。そして、白抜矢印は、一対の端末装置２０５の間で直接的にやりとりされる、通信セッション確立後の信号の流れを示している。この白抜矢印には、「通常通信」なる表記がなされているが、これはこのシステムが想定する本来の通信、すなわち、端末装置２０５間で直接的に行われる通信を示している。これに対して、迂回通信処理部２７５から伸びる太線矢印には、「迂回通信」なる表記がなされているが、これは、上述した「通常通信」の失敗が予想されるときに、端末装置２０５が接続仲介装置１０５を介して間接的に相手方への通信を行うことを示している。
図３６に示す自己アドレス通知部２５５は、図２に示す自己アドレス通知部２５０と同様に、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置１０５に対して通知する機能を果たす。この自己アドレス通知処理は、実施例５に係るネットワーク通信システムにおける通信手順の事前処理ということになり、基本的な処理内容は、既に§１で詳述したとおりである。ただ、自己アドレス通知部２５５は、接続仲介装置１０５に対して自己の所在アドレスを通知する際に、特有の手順を採用する。
図３７は、この実施例５に係るネットワーク通信システムにおける通信手順の事前処理（自己アドレスの通知処理）を時系列で説明する流れ図である。自己アドレス通知部２５５は、まず、ステップＳ５１において、通信プロトコルとしてＵＤＰを用いた第１回通知を行う。すなわち、自己アドレス通知部２５５から接続仲介装置１０５に対して、自己アドレスを通知するためのＵＤＰパケットが送信される。続くステップＳ５２では、この第１回通知に成功したか否かが判断される。ＵＤＰパケットによる自己アドレス通知に対して、接続仲介装置１０５から受領確認のためのアクノレッジ信号を返信する仕様にしておけば、自己アドレス通知部２５５は、アクノレッジが得られたか否かによって、第１回通知に成功したか否かを判断することができる。
第１回通知に成功したら、自己アドレス通知部２５５による自己アドレス通知処理はそれで完了であるが、第１回通知に失敗した場合には、続いて、ステップＳ５３において、通信プロトコルとしてＴＣＰを用いた第２回通知が行われる。前述したとおり、ＴＣＰはＷｅｂ閲覧に広く利用されているプロトコルであるため、実用上、第２回通知は失敗しないものと考えて支障はない。もし、第２回通知に対するアクノレッジも得られなかった場合は、何度か繰り返して同じ通知を行うようにすればよい。
このように、自己アドレス通知部２５５から接続仲介装置１０５に対しては、ＵＤＰパケットもしくはＴＣＰパケットにより、自己の所在アドレスの通知がなされる。したがって、図３６において、自己アドレス通知部２５５からネットワークＮに向かう太線矢印は、端末装置２０５の所在アドレスの情報をもった信号であり、その通信プロトコルは、ＵＤＰまたはＴＣＰということになる。
こうして、接続仲介装置１０５には、各端末装置２０５から、所在アドレスの情報がＵＤＰまたはＴＣＰの通信プロトコルによって通知されるので、接続仲介装置１０５内のアドレステーブルには、端末ＩＤと所在アドレスに加えて、更に、自己アドレス通知に用いられた通信プロトコル（ＵＤＰかＴＣＰか）を対応づけた情報が格納される。すなわち、図３７の流れ図のステップＳ５４において、接続仲介装置１０５内のアドレステーブル更新部１２５によって通信プロトコルを含めたアドレステーブルの更新が行われる。図３８は、このような更新によって作成されたアドレステーブルＴ７０を示す図である。このアドレステーブルＴ７０は、図６に示すアドレステーブルＴと同様に、４組の端末装置から通知された所在アドレスを示すものであるが、所在アドレスに加えて、通信プロトコルの情報（右欄）も記録されている。
図３７の流れ図に示されている事前処理が済めば、図３６に示す実施例５に係るネットワーク通信システムにおける通信準備は完了である。自己アドレス通知部２５５による所在アドレスの通知は、所定タイミングで繰り返し実行されるので、接続仲介装置１０５内のアドレステーブルＴ７０には、各端末装置について、常に最新の所在アドレスおよび通信プロトコルが格納されることになる。そこで、接続仲介装置１０５は、特定の通信元端末装置から特定の通信先端末装置への接続仲介依頼が来たときに、アドレステーブルＴ７０を参照して、両端末間で通常通信を行った場合に、ＵＤＰブロック要素により当該通常通信に支障が生じるか否かを判断し、支障なしと判断される場合には通常通信を選択し、支障ありと判断される場合には迂回通信を選択する。
具体的には、接続仲介装置１０５は、通信元端末装置および通信先端末装置のうち、双方について、アドレステーブルＴ７０に記録されている通信プロトコルがＵＤＰであった場合には、通常通信に支障なしと判断して通常通信を選択する。これに対して、少なくとも一方について、アドレステーブルＴ７０に記録されている通信プロトコルがＴＣＰであった場合には、通常通信に支障ありと判断して迂回通信を選択する。
そして、接続仲介装置１０５から通信元端末装置２０５の通信開始要求部２４５に対して、通信先アドレスを返信する際に、選択した通信方法を示す情報（通常通信か、迂回通信かを示す情報）を併せて返信する。したがって、図３６において、ネットワークＮから通信開始要求部２４５に向かう太線矢印は、通信先アドレスの情報とともに通信方法の情報を含む信号になる。
通信開始要求部２４５は、接続仲介装置１０５から通信先アドレスと共に通信方法が返信されてきたとき、通信方法として通常通信が選択されていた場合には、先願基本発明の第１の実施形態と同様に、ネットワークＮを介して、通信先アドレスにアクセスして通信開始要求を行う。以後の通信手順は、§１で述べたとおりである。一方、通信方法として迂回通信が選択されていた場合には、迂回通信処理部２７５に対して迂回通信指示を行う。
迂回通信処理部２７５は、§７で述べた実施例３における迂回通信処理部２７３と同様に、接続仲介装置１０５を介した迂回通信を行う構成要素である。すなわち、迂回通信処理部２７５は、通常通信（図の白抜矢印で示された通信）の失敗が予想されるときに、接続仲介装置１０５を介して相手方に対する間接的な情報送受を行う迂回通信を実行する。上述したとおり、失敗予想は、接続仲介装置１０５において行われる。通信開始要求部２４５が接続仲介装置１０５から迂回通信を選択する通信方法を受け取った場合、接続仲介装置１０５が失敗予想を行ったケースにあたる。この場合、通信開始要求部２４５から迂回通信処理部２７５に対して迂回通信指示が行われ、迂回通信処理部２７５による迂回通信が実行される。
具体的には、迂回通信処理部２７５は、接続仲介装置１０５（後述するように、その中の迂回通信中継部１４５）に対して迂回通信の中継依頼を行い、接続仲介装置１０５を介して、相手方の迂回通信処理部２７５との間での迂回通信を実行することになる。この迂回通信のための情報パケットのやりとりは、ＴＣＰプロトロルによって行われるため、ルートの途中にＵＤＰブロック要素が存在していても、迂回通信に支障は生じない。なお、変形例として、迂回通信を最初はＵＤＰプロトロルで実行し、失敗した場合にＴＣＰプロトコルに切り替える方法を採ることも可能である。
図３９は、図３６に示す本発明の実施例５に係るネットワーク通信システムにおいて、通信元端末装置２０５Ａと通信先端末装置２０５Ｂとの間の通信セッション確立の手順を示すブロック図である。図示する端末装置２０５Ａ，２０５Ｂは、図３６に示す端末装置２０５と同一の構成を有する装置であり、図４と同様に、通信元端末装置２０５Ａ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）を実線で示し、通信先端末装置２０５Ｂ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）を実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。また、実施例５に固有の構成要素である迂回通信処理部２７５Ａ，２７５Ｂについては太線枠ブロックで示してある。
図３９に示す接続仲介装置１０５（図３６に示すもの）は、図４に示す接続仲介装置１００に、迂回通信中継部１４５を追加するとともに、その他の構成要素であるアドレステーブル格納部１１０、アドレステーブル更新部１２０、通信先アドレス返信部１３０については、若干の付加機能を設けることにより、アドレステーブル格納部１１５、アドレステーブル更新部１２５、通信先アドレス返信部１３５としたものである。
接続仲介装置１０５内の迂回通信中継部１４５は、第１の端末装置２０５Ａの迂回通信処理部２７５Ａと第２の端末装置２０５Ｂの迂回通信処理部２７５Ｂとの間での迂回通信の中継依頼があったときに、第１の端末装置２０５Ａの迂回通信処理部２７５Ａと第２の端末装置２０５Ｂの迂回通信処理部２７５Ｂとの間で受け渡しする情報を取り次いで迂回通信の中継を行う構成要素である。
また、接続仲介装置１０５内のアドレステーブル格納部１１５は、図３８に例示したように、端末ＩＤと所在アドレスに加えて、更に、通信プロトコルを対応づけたアドレステーブルＴ７０を格納する機能を有する。そして、接続仲介装置１０５内のアドレステーブル更新部１２５は、アドレステーブルＴ７０の更新を行う際に、ＵＤＰによって受信した第１回通知に基づいて更新を行う場合には、通信プロトコルとしてＵＤＰを対応づけ、ＴＣＰによって受信した第２回通知に基づいて更新を行う場合には、通信プロトコルとしてＴＣＰを対応づける更新を行う。
一方、接続仲介装置１０５内の通信先アドレス返信部１３５は、接続仲介依頼Ｓ２が送信されてきたときに、アドレステーブルＴ７０を参照して、通信元の端末装置および通信先の端末装置の通信プロトコルを確認し、両端末装置の通信プロトコルがいずれもＵＤＰであった場合には、通信方法として通常通信を選択し、少なくとも一方の通信プロトコルがＴＣＰであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有する。
この図３９に示す例において、アドレステーブル格納部１１５内に図３８のようなアドレステーブルＴ７０が格納されていた場合、通信先の端末装置２０５Ｂ（端末ＩＤ：００２０）の通信プロトコルは「ＴＣＰ」になっているので、通信先アドレス返信部１３５は、通信方法として迂回通信を選択する。通信先端末装置２０５Ｂの通信プロトコルが「ＴＣＰ」ということは、通信先端末装置２０５ＢからのＵＤＰによる第１回自己アドレス通知がどこかでブロックされてしまったことを示している。よって、通信元端末装置２０５Ａから通信先端末装置２０５Ｂへ、ＵＤＰによる通信開始要求Ｓ５を行った場合、通信先端末装置２０５Ｂへのルートの途中で、当該通信開始要求Ｓ５はブロックされてしまう可能性がある。
この場合、通信先アドレス返信部１３５は、通信方法として迂回通信を選択することになる。図３９には、通信先アドレス返信部１３５から通信開始要求部２４５Ａに対して、通信先アドレス「ＡＤ２」および通信方法「迂回通信」を示す情報が返信された例（図３９の太線矢印Ｓ４ａ）が示されている。これに対して、通信元の端末装置２０５Ａと通信先の端末装置２０５Ｂの双方についての通信プロトコルが「ＵＤＰ」になっていれば、通信先アドレス返信部１３５は、通信方法として通常通信を選択することになる。
通信元端末装置２０５Ａ内の通信開始要求部２４５Ａは、通信先アドレス返信部１３５から「通常通信」を選択する返信が戻ってきた場合、通常通信の処理を行う。具体的には、通信開始要求部２４５Ａが、通信先アドレスＡＤ２にアクセスしてＵＤＰによる通信開始要求Ｓ５を行うと、相手方の通信先セッション確立部２３５Ｂから通信元セッション確立部２６５Ａに対してＵＤＰによる通信開始受諾確認Ｓ６が送信される。こうして、通信元セッション確立部２６５Ａと通信先セッション確立部２３５Ａとの間にＵＤＰによる通信セッションが確立する。
一方、通信先アドレス返信部１３５から「迂回通信」を選択する返信が戻ってきた場合、通信開始要求部２４５Ａは、迂回通信の処理を行う。すなわち、通信開始要求部２４５Ａは、通信開始要求Ｓ５を行う代わりに、迂回通信処理部２７５Ａに対して、迂回通信指示Ｓ５′を行う。迂回通信処理部２７５Ａは、この迂回通信指示Ｓ５′を受けると、迂回通信中継部１４５に対してＴＣＰにより迂回通信の中継依頼を行い、迂回通信中継部１４５を介して、相手方の迂回通信処理部２７５Ｂとの間でのＴＣＰによる迂回通信Ｓ８ａを実行する。迂回通信処理部２７５Ａは、通信開始要求部２４５Ａから通信先アドレスＡＤ２を取得し、これを迂回通信中継部１４５にＴＣＰにより伝達して中継依頼を行う。迂回通信中継部１４５は、この中継依頼に応じて、通信先アドレスＡＤ２にＴＣＰによりアクセスし、通信先端末装置２０５Ｂの迂回通信処理部２７５Ｂに迂回通信の開始を要求する。迂回通信処理部２７５Ｂは、これを受諾する旨の返信をＴＣＰにより迂回通信中継部１４５に対して行い、ＴＣＰによる迂回通信Ｓ８ｂを実行する。以後、迂回通信中継部１４５による中継により、両端末装置２０５Ａ，２０５Ｂ間でのＴＣＰによる迂回通信が行われる。
この迂回通信では、両端末装置２０５Ａ，２０５Ｂ間の情報パケットは、すべて接続仲介装置１０５を介したＴＣＰパケットとしてやりとりされることになる。したがって、両端末装置２０５Ａ，２０５Ｂ間のルートに、ＵＤＰブロック要素が存在したとしても、両端末装置２０５Ａ，２０５Ｂ間の迂回通信は支障なく行われる。なお、前述したように、変形例として、迂回通信を最初はＵＤＰプロトロルで実行し、失敗した場合にＴＣＰプロトコルに切り替える方法を採ることも可能である。
図４０は、図３９のブロック図に示されている実施例５における通信セッション確立手順を時系列で説明する流れ図である。この流れ図における通常通信の手順は、§１で述べた先願発明の第１の実施形態における通信セッション確立手順を示す図５の流れ図とほぼ同じである。
まず、ステップＳ１において、通信要求受付部２２０Ａによる通信要求受付処理が行われ、続くステップＳ２において、接続仲介依頼部２１０Ａによる接続仲介依頼が行われる。この接続仲介依頼は、ＵＤＰでもＴＣＰでもよい（最初からＴＣＰで行ってもよいし、まずＵＤＰによって行い、ＵＤＰによる接続仲介依頼が失敗したら、ＴＣＰによる接続仲介依頼を再度行うようにしてもよい）。そしてステップＳ３において、通信先アドレス返信部１３５によりアドレステーブル格納部１１５に格納されているアドレステーブルＴ７０の参照が行われ、ステップＳ４ａにおいて、通信先アドレス返信部１３５から通信開始要求部２４５Ａに対して、通信先アドレスおよび通信方法が返信される。この返信も、ＵＤＰで行ってもよいし、ＴＣＰで行ってもよい。当該返信を受けた通信開始要求部２４５Ａは、ステップＳ４ｂにおいて、２通りの処理プロセスのいずれかを選択する。
まず、通信方法として「通常通信」が指示されていた場合には、ＵＤＰ通信を行うためにステップＳ５へ進む。図４０の流れ図におけるステップＳ５〜Ｓ７の手順は、図５の流れ図におけるステップＳ５〜Ｓ７の手順と全く同じである。ただ、通常通信の通信プロトコルはＵＤＰになる。すなわち、通信開始要求部２４５Ａは、ステップＳ５において、通信先端末装置２０５Ｂに対してＵＤＰにより通信開始要求Ｓ５を行う。通信先セッション確立部２３５Ｂは、この通信開始要求Ｓ５を受け、ステップＳ６において、通信元端末装置２０５Ａに対してＵＤＰにより通信開始受諾確認Ｓ６を送信する。そして、続くステップＳ７において、通信先セッション確立部２３５Ｂと通信元セッション確立部２６５Ａとの間の通信セッションが確立され、ＵＤＰにより通常通信Ｓ７が行われる。
一方、通信方法として「迂回通信」が指示されていた場合には、ステップＳ５′へ進み、通信開始要求部２４５Ａから迂回通信処理部２７５Ａに対して迂回通信指示が与えられる。そして続くステップＳ８において、迂回通信処理が実行される。すなわち、迂回通信処理部２７５Ａ，２７５Ｂと迂回通信中継部１４５によって、ＴＣＰによる迂回通信処理が行われる（図３９のＳ８ａ，Ｓ８ｂ）。
＜８−２． 実施例６＞
図４１は、本発明の実施例６に係るネットワーク通信システムにおける端末装置４０６の詳細構成を示すブロック図である。ここに示す端末装置４０６は、図７に示す先願基本発明の第２の実施形態に係る端末装置４００における通信開始要求部４４０および自己アドレス通知部４５０に、若干の修正を加えてそれぞれ通信開始要求部４４６および自己アドレス通知部４５６とし、更に、新たな構成要素として、迂回通信処理部４７６（図では新たな構成要素を太線枠ブロックで示す）を付加したものである。
また、通信元セッション確立部４３０および通信先セッション確立部４６０は、それぞれ通信元セッション確立部４３６および通信先セッション確立部４６６に置き換えられている。通信元セッション確立部４３６および通信先セッション確立部４６６の基本機能は、図７に示す通信元セッション確立部４３０および通信先セッション確立部４６０と同様であるが、通信プロトコルがＵＤＰに限定されている点が異なっている。すなわち、この実施例６に示すネットワーク通信システムでは、通常通信のプロトコルはＵＤＰに固定されていることになる。その他の構成要素である接続仲介依頼部４１０および通信要求受付部４２０は、図７に示す同符号の各構成要素と同じものであり、その機能の詳細は、既に§２で述べたとおりである。
また、この図４１に示す実施例６では、図７に示す接続仲介装置３００の代わりに、接続仲介装置３０６が用いられている。この接続仲介装置３０６は、図７に示す接続仲介装置３００の機能に、通信方法（通常通信か迂回通信か）を指示する機能と、迂回通信を中継する機能とを付加したものであり、その構成の詳細は後述する。結局、図４１に示す実施例６において、３桁の数字からなる符号における１の位が「６」となっているブロックで示される構成要素が、実施例６に固有の構成要素ということになる。
この実施例６に係るシステムは、図７に示す先願発明のシステムと同様に、ネットワークＮを介して相互に接続可能な複数の端末装置（図には、便宜上、１台の端末装置４０６のみが示されている）と、これら複数の端末装置間の接続を仲介する接続仲介装置３０６と、を備えたネットワーク通信システムである。ここで、各端末装置４０６には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、接続仲介装置３０６は、この端末ＩＤを利用して通信元となる端末装置と通信先となる端末装置との間の接続を仲介する処理を実行する。
この図においても、これまで述べてきた各実施例と同様に、太線矢印、細線矢印、白抜矢印の３種類の矢印が用いられている。白抜矢印は「通常通信」を示し、迂回通信処理部４７６から伸びる太線矢印は「迂回通信」を示している。実施例５と同様に、この実施例６でも、本来は「通常通信」を行うことが意図されているが、「通常通信」の失敗が予想されるときには、端末装置４０６が接続仲介装置３０６を介して間接的に相手方への通信を行うことになる。
図４１に示す自己アドレス通知部４５６は、図７に示す自己アドレス通知部４５０と同様に、自己のネットワーク上での所在を示す所在アドレスを、接続仲介装置３０６に対して通知する機能を果たす。この自己アドレス通知処理は、実施例６に係るネットワーク通信システムにおける通信手順の事前処理ということになり、基本的な処理内容は、既に§２で詳述したとおりである。ただ、自己アドレス通知部４５６は、前述した実施例５における自己アドレス通知部２５５と同様に、接続仲介装置３０６に対して自己の所在アドレスを通知する際に、特有の手順を採用する。
この自己アドレス通知部４５６が行う特有の手順は、実施例５における自己アドレス通知部２５５が行う手順と同様であり、図３７の流れ図に示すものになる。すなわち、自己アドレス通知部４５６は、接続仲介装置３０６に対して自己の所在アドレスを通知する際に、まず、通信プロトコルとしてＵＤＰを用いた第１回通知（図３７のＳ５１に対応）を行い、当該第１回通知に失敗した場合には、続いて、通信プロトコルとしてＴＣＰを用いた第２回通知（図３７のＳ５３に対応）を行うことになる。
このように、自己アドレス通知部４５６から接続仲介装置３０６に対しては、ＵＤＰパケットもしくはＴＣＰパケットにより、自己の所在アドレスの通知がなされる。したがって、図４１において、自己アドレス通知部４５６からネットワークＮに向かう太線矢印は、端末装置４０６の所在アドレスの情報をもった信号であり、その通信プロトコルは、ＵＤＰまたはＴＣＰということになる。
こうして、接続仲介装置３０６には、各端末装置４０６から、所在アドレスの情報がＵＤＰまたはＴＣＰの通信プロトコルによって通知されるので、接続仲介装置３０６内のアドレステーブルには、端末ＩＤと所在アドレスに加えて、更に、自己アドレス通知に用いられた通信プロトコル（ＵＤＰかＴＣＰか）を対応づけた情報が格納される。すなわち、図３７の流れ図のステップＳ５４の処理と同様に、接続仲介装置３０６内のアドレステーブル更新部３２６によって通信プロトコルを含めたアドレステーブルの更新が行われ、たとえば、図３８に示すようなアドレステーブルＴ７０が得られる。
こうして図３７の流れ図に準じた事前処理が済めば、図４１に示す実施例６に係るネットワーク通信システムにおける通信準備は完了である。自己アドレス通知部４５６による所在アドレスの通知は、所定タイミングで繰り返し実行されるので、接続仲介装置３０６内のアドレステーブルＴ７０には、各端末装置について、常に最新の所在アドレスおよび通信プロトコルが格納されることになる。そこで、接続仲介装置３０６は、特定の通信元端末装置から特定の通信先端末装置への接続仲介依頼が来たときに、アドレステーブルＴ７０を参照して、両端末間で通常通信を行った場合に、ＵＤＰブロック要素により当該通常通信に支障が生じるか否かを判断し、支障なしと判断される場合には通常通信を選択し、支障ありと判断される場合には迂回通信を選択する。
具体的には、接続仲介装置３０６は、通信元端末装置および通信先端末装置のうち、双方について、アドレステーブルＴ７０に記録されている通信プロトコルがＵＤＰであった場合には、通常通信に支障なしと判断して通常通信を選択する。これに対して、少なくとも一方について、アドレステーブルＴ７０に記録されている通信プロトコルがＴＣＰであった場合には、通常通信に支障ありと判断して迂回通信を選択する。
前述した実施例５の場合、通信元端末装置２０５が接続仲介装置１０５に対して接続仲介依頼Ｓ２を行うと、当該通信元端末装置２０５に対して、通信先アドレスおよび通信方法が返信される。これに対して、ここで述べる実施例６の場合、通信元端末装置４０６が接続仲介装置３０６に対して接続仲介依頼Ｓ１２を行うと、当該通信元端末装置４０６ではなく、通信先の別な端末装置４０６に対して、「通信元アドレス」および「通信方法」が送信されることになる。ここで、「通信方法」とは、既に述べたとおり、通常通信か、迂回通信かを示す情報である。したがって、図４１において、ネットワークＮから通信先の通信開始要求部４４６（図４１では、通信先の構成要素であるため、二重枠のブロックで示されている）に向かう太線矢印は、通信元アドレスの情報とともに通信方法の情報を含む信号になる。
通信開始要求部４４６は、接続仲介装置３０６から通信元アドレスと共に通信方法が返信されてきたとき、通信方法として通常通信が選択されていた場合には、先願基本発明の第２の実施形態と同様に、ネットワークＮを介して、通信元アドレスにアクセスして通信開始要求を行う。以後の通信手順は、§２で述べたとおりである。一方、通信方法として迂回通信が選択されていた場合には、迂回通信処理部４７６に対して迂回通信指示を行う。
迂回通信処理部４７６は、§８−１で述べた実施例５における迂回通信処理部２７５と同様に、接続仲介装置３０６を介した迂回通信を行う構成要素である。すなわち、迂回通信処理部４７６は、通常通信（図の白抜矢印で示された通信）の失敗が予想されるときに、接続仲介装置３０６を介して相手方に対する間接的な情報送受を行う迂回通信を実行する。上述したとおり、失敗予想は、接続仲介装置３０６において行われる。通信開始要求部４４６が接続仲介装置３０６から迂回通信を選択する通信方法を受け取った場合、接続仲介装置３０６が失敗予想を行ったケースにあたる。この場合、通信開始要求部４４６から迂回通信処理部４７６に対して迂回通信指示が行われ、迂回通信処理部４７６がＴＣＰによる迂回通信を実行する。具体的には、迂回通信処理部４７６は、接続仲介装置３０６（後述するように、その中の迂回通信中継部３４６）に対してＴＣＰによる迂回通信の中継依頼を行い、接続仲介装置３０６を介して、相手方の迂回通信処理部４７６との間でのＴＣＰによる迂回通信を実行することになる。なお、前述したように、変形例として、迂回通信を最初はＵＤＰプロトロルで実行し、失敗した場合にＴＣＰプロトコルに切り替える方法を採ることも可能である。
図４２は、図４１に示す本発明の実施例６に係るネットワーク通信システムにおいて、通信先端末装置４０６Ａと通信元端末装置４０６Ｂとの間の通信セッション確立の手順を示すブロック図である。図示する端末装置４０６Ａ，４０６Ｂは、図４１に示す端末装置４０６と同一の構成を有する装置であり、図８と同様に、通信元端末装置４０６Ｂ内の構成要素については、通信元として必要な処理を実行する構成要素（矩形ブロックの構成要素）を実線で示し、通信先端末装置４０６Ａ内の構成要素については、通信先として必要な処理を実行する構成要素（二重矩形ブロックの構成要素）を実線で示すことにし、それ以外の構成要素のブロックは破線で示してある。また、実施例６に固有の構成要素である迂回通信処理部４７６Ａ，４７６Ｂについては太線枠ブロックで示してある。
図４２に示す接続仲介装置３０６（図４１に示すもの）は、図８に示す接続仲介装置３００に、迂回通信中継部３４６を追加するとともに、その他の構成要素であるアドレステーブル格納部３１０、アドレステーブル更新部３２０、通信先アドレス返信部３３０については、若干の付加機能を設けることにより、アドレステーブル格納部３１６、アドレステーブル更新部３２６、通信元アドレス送信部３３６としたものである。
接続仲介装置３０６内の迂回通信中継部３４６は、第１の端末装置４０６Ａの迂回通信処理部４７６Ａと第２の端末装置４０６Ｂの迂回通信処理部４７６Ｂとの間での迂回通信の中継依頼があったときに、第１の端末装置４０６Ａの迂回通信処理部４７６Ａと第２の端末装置４０６Ｂの迂回通信処理部４７６Ｂとの間で受け渡しする情報を取り次いで迂回通信の中継を行う構成要素である。
また、接続仲介装置３０６内のアドレステーブル格納部３１６は、図３８に例示したように、端末ＩＤと所在アドレスに加えて、更に、通信プロトコルを対応づけたアドレステーブルＴ７０を格納する機能を有する。そして、接続仲介装置３０６内のアドレステーブル更新部３２６は、アドレステーブルＴ７０の更新を行う際に、ＵＤＰによって受信した第１回通知に基づいて更新を行う場合には、通信プロトコルとしてＵＤＰを対応づけ、ＴＣＰによって受信した第２回通知に基づいて更新を行う場合には、通信プロトコルとしてＴＣＰを対応づける更新を行う。
一方、接続仲介装置３０６内の通信元アドレス送信部３３６は、通信元端末装置４０６Ｂ内の接続仲介依頼部４１０Ｂから接続仲介依頼Ｓ１２が送信されてきたときに、アドレステーブルＴ７０を参照して、接続仲介依頼Ｓ１２に含まれている通信先特定情報によって特定される端末ＩＤ「００１０」に対応づけられている所在アドレスＡＤ１を通信先アドレスとして認識し、この通信先アドレスＡＤ１に対して、接続仲介依頼Ｓ１２を送信した通信元の端末装置４０６Ｂの端末ＩＤ「００２０」に対応づけられている所在アドレスＡＤ２を、通信元アドレスとして送信する（Ｓ１４ａ）する。
このとき、通信元アドレス送信部３３６は、アドレステーブルＴ７０を参照して、通信元の端末装置および通信先の端末装置の通信プロトコルを確認し、両端末装置の通信プロトコルがいずれもＵＤＰであった場合には、通信方法として通常通信を選択し、少なくとも一方の通信プロトコルがＴＣＰであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信元アドレスと共に送信する機能を有する。
通信先端末装置４０６Ａ内の通信開始要求部４４６Ａは、通信元アドレス送信部３３６から「通常通信」を選択する送信があった場合、通常通信の処理を行う。具体的には、通信開始要求部４４６Ａが、通信元アドレスＡＤ２にアクセスしてＵＤＰによる通信開始要求Ｓ１５を行うと、相手方の通信元セッション確立部４３６Ｂから通信先セッション確立部４６６Ａに対してＵＤＰによる通信開始受諾確認Ｓ１６が送信される。こうして、通信元セッション確立部４３６Ｂと通信先セッション確立部４６６Ａとの間にＵＤＰによる通信セッションが確立する。
一方、通信元アドレス返信部３３６から「迂回通信」を選択する送信があった場合、通信開始要求部４４６Ａは、迂回通信の処理を行う。すなわち、通信開始要求部４４６Ａは、通信開始要求Ｓ１５を行う代わりに、迂回通信処理部４７６Ａに対して、迂回通信指示Ｓ１５′を行う。迂回通信処理部４７６Ａは、この迂回通信指示Ｓ１５′を受けると、迂回通信中継部３４６に対してＴＣＰにより迂回通信の中継依頼を行い、迂回通信中継部３４６を介して、相手方の迂回通信処理部４７６Ｂとの間でのＴＣＰによる迂回通信Ｓ１８ａを実行する。迂回通信処理部４７６Ａは、通信開始要求部４４６Ａから通信元アドレスＡＤ２を取得し、これを迂回通信中継部３４６に伝達して中継依頼を行う。迂回通信中継部３４６は、この中継依頼に応じて、ＴＣＰにより通信元アドレスＡＤ２にアクセスし、通信元端末装置４０６Ｂの迂回通信処理部４７６ＢにＴＣＰにより迂回通信の開始を要求する。迂回通信処理部４７６Ｂは、これを受諾する旨のＴＣＰによる返信を迂回通信中継部３４６に対して行い、ＴＣＰにより迂回通信Ｓ１８ｂを実行する。以後、迂回通信中継部３４６による中継により、両端末装置４０６Ａ，４０６Ｂ間でのＴＣＰにより迂回通信が行われる。
この迂回通信では、両端末装置４０６Ａ，４０６Ｂ間の情報パケットは、すべて接続仲介装置３０６を介したＴＣＰパケットとしてやりとりされることになる。したがって、両端末装置４０６Ａ，４０６Ｂ間のルートに、ＵＤＰブロック要素が存在したとしても、両端末装置４０６Ａ，４０６Ｂ間の迂回通信は支障なく行われる。なお、前述したように、変形例として、迂回通信を最初はＵＤＰプロトロルで実行し、失敗した場合にＴＣＰプロトコルに切り替える方法を採ることも可能である。
図４３は、図４２のブロック図に示されている実施例６における通信セッション確立手順を時系列で説明する流れ図である。この流れ図における通常通信の手順は、§２で述べた先願発明の第２の実施形態における通信セッション確立手順を示す図９の流れ図とほぼ同じである。
まず、ステップＳ１１において、通信要求受付部４２０Ｂによる通信要求受付処理が行われ、続くステップＳ１２において、接続仲介依頼部４１０Ｂによる接続仲介依頼が行われる。そしてステップＳ１３において、通信元アドレス送信部３３６によりアドレステーブル格納部３１６に格納されているアドレステーブルＴ７０の参照が行われ、ステップＳ１４ａにおいて、通信元アドレス送信部３３６から通信先端末装置４０６Ａの通信開始要求部４４６Ａに対して、通信元アドレスおよび通信方法が送信される。この送信を受けた通信開始要求部４４６Ａは、ステップＳ１４ｂにおいて、２通りの処理プロセスのいずれかを選択する。
まず、通信方法として「通常通信」が指示されていた場合には、ステップＳ１５へ進む。図４３の流れ図におけるステップＳ１５〜Ｓ１７の手順は、図９の流れ図におけるステップＳ１５〜Ｓ１７の手順と全く同じである。ただ、通常通信の通信プロトコルはＵＤＰになる。すなわち、通信開始要求部４４６Ａは、ステップＳ１５において、通信元端末装置４０６Ｂに対してＵＤＰにより通信開始要求Ｓ１５を行う。通信元セッション確立部４３６Ｂは、この通信開始要求Ｓ１５を受け、ステップＳ１６において、通信先端末装置４０６Ａに対してＵＤＰにより通信開始受諾確認Ｓ１６を送信する。そして、続くステップＳ１７において、通信元セッション確立部４３６Ｂと通信先セッション確立部４６６Ａとの間の通信セッションが確立され、ＵＤＰにより通常通信Ｓ１７が行われる。
一方、通信方法として「迂回通信」が指示されていた場合には、ステップＳ１５′へ進み、通信開始要求部４４６Ａから迂回通信処理部４７６Ａに対して迂回通信指示が与えられる。そして続くステップＳ１８において、迂回通信処理が実行される。すなわち、迂回通信処理部４７６Ａ，４７６Ｂと迂回通信中継部３４６によって、ＴＣＰによる迂回通信処理が行われる（図４２のＳ１８ａ，Ｓ１８ｂ）。
本発明に係るネットワーク通信システムは、パソコン、携帯電話、タブレット型端末など、インターネットに接続可能な様々な端末装置が利用されている状態において、任意の端末装置間での安定した通信を可能にする技術を提供するものであり、産業上、十分な利用可能性を有している。
１００：接続仲介装置
１０１：実施例１の接続仲介装置
１０３：実施例３の接続仲介装置
１０５：実施例５の接続仲介装置
１１０：アドレステーブル格納部
１１３：実施例３のアドレステーブル格納部
１１５：実施例５のアドレステーブル格納部
１２０：アドレステーブル更新部
１２３：実施例３のアドレステーブル更新部
１２５：実施例５のアドレステーブル更新部
１３０：通信先アドレス返信部
１３３：実施例３の通信先アドレス返信部
１３５：実施例５の通信先アドレス返信部
１４１：実施例１の迂回通信中継部
１４３：実施例３の迂回通信中継部
１４５：実施例５の迂回通信中継部
２００，２００Ａ〜２００Ｋ：端末装置
２０１Ｈ，２０１Ｋ：ＶＰＮ通信部
２０１，２０１Ａ，２０１Ｂ：実施例１の端末装置
２０３，２０３Ａ，２０３Ｂ：実施例３の端末装置
２０５，２０５Ａ，２０５Ｂ：実施例５の端末装置
２１０，２１０Ａ，２１０Ｂ：接続仲介依頼部
２２０，２２０Ａ，２２０Ｂ：通信要求受付部
２３０，２３０Ａ，２３０Ｂ：通信先セッション確立部
２３５，２３５Ａ，２３５Ｂ：実施例５の通信先セッション確立部
２４０，２４０Ａ，２４０Ｂ：通信開始要求部
２４１，２４１Ａ，２４１Ｂ：実施例１の通信開始要求部
２４３，２４３Ａ，２４３Ｂ：実施例３の通信開始要求部
２４５，２４５Ａ，２４５Ｂ：実施例５の通信開始要求部
２５０，２５０Ａ，２５０Ｂ：自己アドレス通知部
２５３，２５３Ａ，２５３Ｂ：実施例３の自己アドレス通知部
２５５，２５５Ａ，２５５Ｂ：実施例５の自己アドレス通知部
２６０，２６０Ａ，２６０Ｂ：通信元セッション確立部
２６１，２６１Ａ，２６１Ｂ：実施例１の通信元セッション確立部
２６５，２６５Ａ，２６５Ｂ：実施例５の通信元セッション確立部
２７１，２７１Ａ，２７１Ｂ：実施例１の迂回通信処理部
２７３，２７３Ａ，２７３Ｂ：実施例３の迂回通信処理部
２７５，２７５Ａ，２７５Ｂ：実施例５の迂回通信処理部
２８３，２８３Ａ，２８３Ｂ：実施例３のＮＡＴタイプ確認部
３００：接続仲介装置
３０２：実施例２の接続仲介装置
３０４：実施例４の接続仲介装置
３０６：実施例６の接続仲介装置
３１０：アドレステーブル格納部
３１４：実施例４のアドレステーブル格納部
３１６：実施例６のアドレステーブル格納部
３２０：アドレステーブル更新部
３２４：実施例４のアドレステーブル更新部
３２６：実施例６のアドレステーブル更新部
３３０：通信元アドレス送信部
３３４：実施例４の通信元アドレス送信部
３３６：実施例６の通信元アドレス送信部
３４２：実施例２の迂回通信中継部
３４４：実施例４の迂回通信中継部
３４６：実施例６の迂回通信中継部
４００，４００Ａ〜４００Ｄ：端末装置
４０２，４０２Ａ，４０２Ｂ：実施例２の端末装置
４０４，４０４Ａ，４０４Ｂ：実施例４の端末装置
４０６，４０６Ａ，４０６Ｂ：実施例６の端末装置
４１０，４１０Ａ，４１０Ｂ：接続仲介依頼部
４２０，４２０Ａ，４２０Ｂ：通信要求受付部
４３０，４３０Ａ，４３０Ｂ：通信元セッション確立部
４３６，４３６Ａ，４３６Ｂ：実施例６の通信元セッション確立部
４４０，４４０Ａ，４４０Ｂ：通信開始要求部
４４２，４４２Ａ，４４２Ｂ：実施例２の通信開始要求部
４４４，４４４Ａ，４４４Ｂ：実施例４の通信開始要求部
４４６，４４６Ａ，４４６Ｂ：実施例６の通信開始要求部
４５０，４５０Ａ，４５０Ｂ：自己アドレス通知部
４５４，４５４Ａ，４５４Ｂ：実施例４の自己アドレス通知部
４５６，４５６Ａ，４５６Ｂ：実施例６の自己アドレス通知部
４６０，４６０Ａ，４６０Ｂ：通信先セッション確立部
４６２，４６２Ａ，４６２Ｂ：実施例２の通信先セッション確立部
４６６，４６６Ａ，４６６Ｂ：実施例６の通信先セッション確立部
４７２，４７２Ａ，４７２Ｂ：実施例２の迂回通信処理部
４７４，４７４Ａ，４７４Ｂ：実施例４の迂回通信処理部
４７６，４７６Ａ，４７６Ｂ：実施例６の迂回通信処理部
４８４，４８４Ａ，４８４Ｂ：実施例４のＮＡＴタイプ確認部
５００：ＮＡＴタイプ判別装置
ＡＤ１〜ＡＤ７：所在アドレス
ＡＤｘ，ＡＤｙ，ＡＤｚ：グローバルＩＰアドレス
ＡＰＰ１，ＡＰＰ２：アプリケーションプログラム
ＧＩＰ：グローバルＩＰアドレス
Ｌ１〜Ｌ４：ブロック間の信号の流れを示す矢印
Ｎ：ネットワーク（インターネット）
Ｐ１〜Ｐ２１：ポート番号
ＰＩＰ：プライベートＩＰアドレス
Ｒ，Ｒ１，Ｒ２，ＲＡ，ＲＢ：ルータ
Ｓ１〜Ｓ５４：流れ図の各ステップ
Ｔ，Ｔ１〜Ｔ３，Ｔ４１，Ｔ４２，Ｔ５１，Ｔ５２，Ｔ６０，Ｔ７０：アドレステーブル

Claims (18)

  1. ネットワーク（Ｎ）を介して相互に接続可能な複数の端末装置（２０１，２０３，２０５）と、前記複数の端末装置間の接続を仲介する接続仲介装置（１０１，１０３，１０５）と、を備えたネットワーク通信システムであって、
    前記複数の端末装置（２０１，２０３，２０５）には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、前記接続仲介装置（１０１，１０３，１０５）は、前記端末ＩＤを利用して通信元となる端末装置（２０１Ａ，２０３Ａ，２０５Ａ）と通信先となる端末装置（２０１Ｂ，２０３Ｂ，２０５Ｂ）との間の接続を仲介する処理を実行し、
    前記複数の端末装置（２０１，２０３，２０５）のそれぞれは、
    自己のネットワーク上での所在を示す所在アドレスを、前記接続仲介装置（１０１，１０３，１０５）に対して通知する自己アドレス通知部（２５０，２５３，２５５）と、
    自己（２０１Ａ，２０３Ａ，２０５Ａ）を通信元として、通信先の別な端末装置（２０１Ｂ，２０３Ｂ，２０５Ｂ）に対する通信要求（Ｓ１）を受け付ける通信要求受付部（２２０Ａ）と、
    前記通信要求受付部（２２０Ａ）によって前記通信要求（Ｓ１）が受け付けられたときに、前記接続仲介装置（１０１，１０３，１０５）に対して、前記通信先の別な端末装置（２０１Ｂ，２０３Ｂ，２０５Ｂ）の端末ＩＤ（００２０）を特定するための通信先特定情報を含む接続仲介依頼（Ｓ２）を送信する接続仲介依頼部（２１０Ａ）と、
    前記接続仲介依頼（Ｓ２）に応じて、前記接続仲介装置（１０１，１０３，１０５）から、前記通信先の別な端末装置（２０１Ｂ，２０３Ｂ，２０５Ｂ）のネットワーク上での所在を示す通信先アドレス（ＡＤ２）が返信されてきたときに、ネットワーク（Ｎ）を介して、前記通信先アドレス（ＡＤ２）にアクセスして通信開始要求（Ｓ５）を行う通信開始要求部（２４１Ａ，２４３Ａ，２４５Ａ）と、
    前記通信開始要求（Ｓ５）に応じて、前記通信先の別な端末装置（２０１Ｂ，２０３Ｂ，２０５Ｂ）から、通信開始受諾確認（Ｓ６）が返信されてきたら、前記通信先の別な端末装置（２０１Ｂ，２０３Ｂ，２０５Ｂ）との間に通信セッションを確立して通信（Ｓ７）を開始する通信元セッション確立部（２６０Ａ，２６１Ａ，２６５Ａ）と、
    通信元の別な端末装置（２０１Ａ，２０３Ａ，２０５Ａ）から、自己を通信先とする通信開始要求（Ｓ５）がなされたら、前記通信元の別な端末装置（２０１Ａ，２０３Ａ，２０５Ａ）に対して通信開始受諾確認（Ｓ６）を送信し、前記通信元の別な端末装置（２０１Ａ，２０３Ａ，２０５Ａ）との間に通信セッションを確立して通信（Ｓ７）を開始する通信先セッション確立部（２３０Ｂ，２３５Ｂ）と、
    前記通信元セッション確立部（２６０Ａ，２６１Ａ，２６５Ａ）と前記通信先セッション確立部（２３０Ｂ，２３５Ｂ）との間に通信セッションを確立して相手方に対する直接的な情報送受を行う通常通信に失敗したとき、もしくは失敗が予想されるときに、前記接続仲介装置（１０１，１０３，１０５）を介して相手方に対する間接的な情報送受を行う迂回通信を実行する迂回通信処理部（２７１，２７３，２７５）と、
    を有し、
    前記接続仲介装置（１０１，１０３，１０５）は、
    前記端末装置（２０１，２０３，２０５）のそれぞれについて、前記端末ＩＤと前記所在アドレスとを対応づけたアドレステーブル（Ｔ，Ｔ６０，Ｔ７０）を格納するアドレステーブル格納部（１１０，１１３，１１５）と、
    前記端末装置（２０１，２０３，２０５）の前記自己アドレス通知部（２５０，２５３，２５５）からの通知に基づいて、前記アドレステーブル（Ｔ，Ｔ６０，Ｔ７０）の内容を更新するアドレステーブル更新部（１２０，１２３，１２５）と、
    前記端末装置（２０１Ａ，２０３Ａ，２０５Ａ）の前記接続仲介依頼部（２１０Ａ）から、前記接続仲介依頼（Ｓ２）が送信されてきたときに、前記アドレステーブル（Ｔ，Ｔ６０，Ｔ７０）を参照して、前記接続仲介依頼（Ｓ２）に含まれている通信先特定情報によって特定される端末ＩＤ（００２０）に対応づけられている所在アドレス（ＡＤ２）を通信先アドレスとして返信する通信先アドレス返信部（１３０，１３３，１３５）と、
    第１の端末装置の迂回通信処理部（２７１，２７３，２７５）と第２の端末装置の迂回通信処理部（２７１，２７３，２７５）との間での迂回通信の中継依頼があったときに、前記第１の端末装置の迂回通信処理部と第２の端末装置の迂回通信処理部との間で受け渡しする情報を取り次いで迂回通信の中継を行う迂回通信中継部（１４１，１４３，１４５）と、
    を有することを特徴とするネットワーク通信システム。
  2. 請求項１に記載のネットワーク通信システムにおいて、
    通信開始要求部（２４１Ａ）が通信開始要求（Ｓ５）を行った後、これに応じた通信開始受諾確認（Ｓ６）が所定のタイムアウト設定時間内に返信されてこなかった場合に、迂回通信処理部（２７１Ａ）が、迂回通信中継部（１４１）に対して迂回通信の中継依頼を行い、前記迂回通信中継部（１４１）を介して、相手方の迂回通信処理部（２７１Ｂ）との間での迂回通信を実行することを特徴とするネットワーク通信システム。
  3. 請求項１に記載のネットワーク通信システムにおいて、
    通信開始要求部（２４１Ａ）が行った通信開始要求（Ｓ５）に対してアクノレッジが得られなかった場合に、迂回通信処理部（２７１Ａ）が、迂回通信中継部（１４１）に対して迂回通信の中継依頼を行い、前記迂回通信中継部（１４１）を介して、相手方の迂回通信処理部（２７１Ｂ）との間での迂回通信を実行することを特徴とするネットワーク通信システム。
  4. 請求項１に記載のネットワーク通信システムにおいて、
    複数の端末装置（２０３）のそれぞれが、ネットワーク（Ｎ）を介してＮＡＴタイプ判別装置（５００）に対して自己のＮＡＴタイプを照会し、前記ＮＡＴタイプ判別装置からの回答を得るＮＡＴタイプ確認部（２８３）を更に備え、
    自己アドレス通知部（２５３）が、接続仲介装置（１０３）に対して自己の所在アドレスを通知する際に、前記ＮＡＴタイプ確認部（２８３）が得た回答を併せて通知し、
    接続仲介装置（１０３）内のアドレステーブル格納部（１１３）が、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけたアドレステーブル（Ｔ６０）を格納する機能を有し、
    接続仲介装置（１０３）内のアドレステーブル更新部（１２３）が、前記自己アドレス通知部（２５３）からの通知に含まれる前記回答に基づいて、前記アドレステーブル（Ｔ６０）内のＮＡＴタイプの更新を行う機能を有し、
    接続仲介装置（１０３）内の通信先アドレス返信部（１３３）が、接続仲介依頼（Ｓ２）の送信を受けたときに、前記アドレステーブル（Ｔ６０）を参照して通信先の端末装置のＮＡＴタイプが「外部から当該通信先の端末装置宛に送信されてきたパケットについては、当該通信先の端末装置からのパケットを受け取ったことがある外部ホストからのパケットのみを通すという制限の下でアドレス変換を行う関所型ＮＡＴ」であるか否かを確認し、通信先の端末装置のＮＡＴタイプが関所型ＮＡＴではなかった場合には、通信方法として通常通信を選択し、通信先の端末装置のＮＡＴタイプが関所型ＮＡＴであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
    通信開始要求部（２４３Ａ）が、前記接続仲介装置（１０３）から通信先アドレス（ＡＤ２）と共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、ネットワーク（Ｎ）を介して、前記通信先アドレス（ＡＤ２）にアクセスして通信開始要求（Ｓ５）を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部（２７３Ａ）に対して迂回通信指示（Ｓ５′）を行うことを特徴とするネットワーク通信システム。
  5. 請求項４に記載のネットワーク通信システムにおいて、
    自己アドレス通知部（２５３）が、接続仲介装置（１０３）に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部（２８３）に対してＮＡＴタイプ確認指示（Ｓ３１）を出し、
    前記ＮＡＴタイプ確認部（２８３）が、前記ＮＡＴタイプ確認指示を受けたときに、ＮＡＴタイプ判別装置（５００）に対して自己のＮＡＴタイプを照会（Ｓ３２）し、得られた回答（Ｓ３３）を前記自己アドレス通知部（２５３）に報告（Ｓ３４）し、
    前記自己アドレス通知部（２５３）が、前記報告に基づいて前記回答を接続仲介装置（１０３）に対して通知（Ｓ３５）することを特徴とするネットワーク通信システム。
  6. 請求項１に記載のネットワーク通信システムにおいて、
    自己アドレス通知部（２５５）が、接続仲介装置（１０５）に対して自己の所在アドレスを通知する際に、まず、通信プロトコルとしてＵＤＰを用いた第１回通知（Ｓ５１）を行い、当該第１回通知に失敗した場合には、続いて、通信プロトコルとしてＴＣＰを用いた第２回通知（Ｓ５３）を行い、
    接続仲介装置（１０５）内のアドレステーブル格納部（１１５）が、端末ＩＤと所在アドレスに加えて、更に、通信プロトコルを対応づけたアドレステーブル（Ｔ７０）を格納する機能を有し、
    接続仲介装置（１０５）内のアドレステーブル更新部（１２５）が更新を行う際（Ｓ５４）に、前記第１回通知に基づいて更新を行う場合には、通信プロトコルとしてＵＤＰを対応づけ、前記第２回通知に基づいて更新を行う場合には、通信プロトコルとしてＴＣＰを対応づけ、
    接続仲介装置（１０５）内の通信先アドレス返信部（１３５）が、接続仲介依頼（Ｓ２）が送信されてきたときに、前記アドレステーブル（Ｔ７０）を参照して、通信元の端末装置および通信先の端末装置の通信プロトコルを確認し、両端末装置の通信プロトコルがいずれもＵＤＰであった場合には、通信方法として通常通信を選択し、少なくとも一方の通信プロトコルがＴＣＰであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
    通信開始要求部（２４５Ａ）が、前記接続仲介装置（１０５）から通信先アドレス（ＡＤ２）と共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、前記通信先アドレス（ＡＤ２）に対して通信プロトコルＵＤＰを用いたアクセスにより通信開始要求（Ｓ５）を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部（２７５Ａ）に対して迂回通信指示（Ｓ５′）を行い、
    通信方法として通常通信が選択されていた場合には、通信元セッション確立部（２６５Ａ）と通信先セッション確立部（２３５Ｂ）との間で、通信プロトコルＵＤＰを用いた通常通信（Ｓ７）を実行し、通信方法として迂回通信が選択されていた場合には、通信元の迂回通信処理部（２７５Ａ）と通信先の迂回通信処理部（２７５Ｂ）との間で、通信プロトコルＴＣＰを用いて、接続仲介装置（１０５）を介した迂回通信を実行することを特徴とするネットワーク通信システム。
  7. ネットワーク（Ｎ）を介して相互に接続可能な複数の端末装置（４０２，４０４，４０６）と、前記複数の端末装置間の接続を仲介する接続仲介装置（３０２，３０４，３０６）と、を備えたネットワーク通信システムであって、
    前記複数の端末装置（４０２，４０４，４０６）には、個々の端末装置を相互に識別するための端末ＩＤがそれぞれ付与されており、前記接続仲介装置（３０２，３０４，３０６）は、前記端末ＩＤを利用して通信元となる端末装置（４０２Ｂ，４０４Ｂ，４０６Ｂ）と通信先となる端末装置（４０２Ａ，４０４Ａ，４０６Ａ）との間の接続を仲介する処理を実行し、
    前記複数の端末装置（４０２，４０４，４０６）のそれぞれは、
    自己のネットワーク上での所在を示す所在アドレスを、前記接続仲介装置（３０２，３０４，３０６）に対して通知する自己アドレス通知部（４５０，４５４，４５６）と、
    自己（４０２Ｂ，４０４Ｂ，４０６Ｂ）を通信元として、通信先の別な端末装置（４０２Ａ，４０４Ａ，４０６Ａ）に対する通信要求（Ｓ１１）を受け付ける通信要求受付部（４２０Ｂ）と、
    前記通信要求受付部（４２０Ｂ）によって前記通信要求（Ｓ１１）が受け付けられたときに、前記接続仲介装置（３０２，３０４，３０６）に対して、前記通信先の別な端末装置（４０２Ａ，４０４Ａ，４０６Ａ）の端末ＩＤ（００１０）を特定するための通信先特定情報を含む接続仲介依頼（Ｓ１２）を送信する接続仲介依頼部（４１０Ｂ）と、
    前記接続仲介装置（３０２，３０４，３０６）から、通信元の別な端末装置（４０２Ｂ，４０４Ｂ，４０６Ｂ）のネットワーク上での所在を示す通信元アドレス（ＡＤ２）が送信されてきたときに、ネットワーク（Ｎ）を介して、前記通信元アドレス（ＡＤ２）にアクセスして通信開始要求（Ｓ１５）を行う通信開始要求部（４４２Ａ，４４４Ａ，４４６Ａ）と、
    前記通信開始要求（Ｓ１５）に応じて、前記通信元の別な端末装置（４０２Ｂ，４０４Ｂ，４０６Ｂ）から、通信開始受諾確認（Ｓ１６）が返信されてきたら、前記通信元の別な端末装置（４０２Ｂ，４０４Ｂ，４０６Ｂ）との間に通信セッションを確立して通信（Ｓ１７）を開始する通信先セッション確立部（４６０Ａ，４６２Ａ，４６６Ａ）と、
    前記通信先の別な端末装置（４０２Ａ，４０４Ａ，４０６Ａ）から、自己（４０２Ｂ，４０４Ｂ，４０６Ｂ）を通信元とする通信開始要求（Ｓ１５）がなされたら、前記通信先の別な端末装置（４０２Ａ，４０４Ａ，４０６Ａ）に対して通信開始受諾確認（Ｓ１６）を送信し、前記通信先の別な端末装置（４０２Ａ，４０４Ａ，４０６Ａ）との間に通信セッションを確立して通信（Ｓ１７）を開始する通信元セッション確立部（４３０Ｂ，４３６Ｂ）と、
    前記通信元セッション確立部（４３０Ｂ，４３６Ｂ）と前記通信先セッション確立部（４６０Ａ，４６２Ａ，４６６Ａ）との間に通信セッションを確立して相手方に対する直接的な情報送受を行う通常通信に失敗したとき、もしくは失敗が予想されるときに、前記接続仲介装置（３０２，３０４，３０６）を介して相手方に対する間接的な情報送受を行う迂回通信を実行する迂回通信処理部（４７２，４７４，４７６）と、
    を有し、
    前記接続仲介装置（３０２，３０４，３０６）は、
    前記端末装置（４０２，４０４，４０６）のそれぞれについて、前記端末ＩＤと前記所在アドレスとを対応づけたアドレステーブル（Ｔ，Ｔ６０，Ｔ７０）を格納するアドレステーブル格納部（３１０，３１４，３１６）と、
    前記端末装置（４０２，４０４，４０６）の前記自己アドレス通知部（４５０，４５４，４５６）からの通知に基づいて、前記アドレステーブル（Ｔ，Ｔ６０，Ｔ７０）の内容を更新するアドレステーブル更新部（３２０，３２４，３２６）と、
    前記端末装置（４０２Ｂ，４０４Ｂ，４０６Ｂ）の前記接続仲介依頼部（４１０Ｂ）から、前記接続仲介依頼（Ｓ１２）が送信されてきたときに、前記アドレステーブル（Ｔ，Ｔ６０，Ｔ７０）を参照して、前記接続仲介依頼（Ｓ１２）に含まれている通信先特定情報によって特定される端末ＩＤ（００１０）に対応づけられている所在アドレス（ＡＤ１）に対して、前記接続仲介依頼（Ｓ１２）を送信した通信元の端末装置（４０２Ｂ，４０４Ｂ，４０６Ｂ）の端末ＩＤ（００２０）に対応づけられている所在アドレス（ＡＤ２）を通信元アドレスとして送信する通信元アドレス送信部（３３０，３３４，３３６）と、
    第１の端末装置の迂回通信処理部（４７２，４７４，４７６）と第２の端末装置の迂回通信処理部（４７２，４７４，４７６）との間での迂回通信の中継依頼があったときに、前記第１の端末装置の迂回通信処理部と第２の端末装置の迂回通信処理部との間で受け渡しする情報を取り次いで迂回通信の中継を行う迂回通信中継部（３４２，３４４，３４６）と、
    を有することを特徴とするネットワーク通信システム。
  8. 請求項７に記載のネットワーク通信システムにおいて、
    通信開始要求部（４４２Ａ）が通信開始要求（Ｓ１５）を行った後、これに応じた通信開始受諾確認（Ｓ１６）が所定のタイムアウト設定時間内に返信されてこなかった場合に、迂回通信処理部（４７２Ａ）が、迂回通信中継部（３４２）に対して迂回通信の中継依頼を行い、前記迂回通信中継部（３４２）を介して、相手方の迂回通信処理部（４７２Ｂ）との間での迂回通信を実行することを特徴とするネットワーク通信システム。
  9. 請求項７に記載のネットワーク通信システムにおいて、
    通信開始要求部（４４２Ａ）が行った通信開始要求（Ｓ１５）に対してアクノレッジが得られなかった場合に、迂回通信処理部（４７２Ａ）が、迂回通信中継部（３４２）に対して迂回通信の中継依頼を行い、前記迂回通信中継部（３４２）を介して、相手方の迂回通信処理部（４７２Ｂ）との間での迂回通信を実行することを特徴とするネットワーク通信システム。
  10. 請求項７に記載のネットワーク通信システムにおいて、
    複数の端末装置（４０４）のそれぞれが、ネットワーク（Ｎ）を介してＮＡＴタイプ判別装置（５００）に対して自己のＮＡＴタイプを照会し、前記ＮＡＴタイプ判別装置からの回答を得るＮＡＴタイプ確認部（４８４）を更に備え、
    自己アドレス通知部（４５４）が、接続仲介装置（３０４）に対して自己の所在アドレスを通知する際に、前記ＮＡＴタイプ確認部（４８４）が得た回答を併せて通知し、
    接続仲介装置（３０４）内のアドレステーブル格納部（３１４）が、端末ＩＤと所在アドレスに加えて、更に、ＮＡＴタイプを対応づけたアドレステーブル（Ｔ６０）を格納する機能を有し、
    接続仲介装置（３０４）内のアドレステーブル更新部（３２４）が、前記自己アドレス通知部（４５４）からの通知に含まれる前記回答に基づいて、前記アドレステーブル（Ｔ６０）内のＮＡＴタイプの更新を行う機能を有し、
    接続仲介装置（３０４）内の通信元アドレス送信部（３３４）が、接続仲介依頼（Ｓ１２）の送信を受けたときに、前記アドレステーブル（Ｔ６０）を参照して通信元の端末装置のＮＡＴタイプが「外部から当該通信元の端末装置宛に送信されてきたパケットについては、当該通信元の端末装置からのパケットを受け取ったことがある外部ホストからのパケットのみを通すという制限の下でアドレス変換を行う関所型ＮＡＴ」であるか否かを確認し、通信元の端末装置のＮＡＴタイプが関所型ＮＡＴではなかった場合には、通信方法として通常通信を選択し、通信元の端末装置のＮＡＴタイプが関所型ＮＡＴであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
    通信開始要求部（４４４Ａ）が、前記接続仲介装置（３０４）から通信元アドレス（ＡＤ２）と共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、ネットワーク（Ｎ）を介して、前記通信元アドレス（ＡＤ２）にアクセスして通信開始要求（Ｓ１５）を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部（４７４Ａ）に対して迂回通信指示（Ｓ１５′）を行うことを特徴とするネットワーク通信システム。
  11. 請求項１０に記載のネットワーク通信システムにおいて、
    自己アドレス通知部（４５４）が、接続仲介装置（３０４）に対して自己の所在アドレスを通知する際に、ＮＡＴタイプ確認部（４８４）に対してＮＡＴタイプ確認指示（Ｓ３１）を出し、
    前記ＮＡＴタイプ確認部（４８４）が、前記ＮＡＴタイプ確認指示を受けたときに、ＮＡＴタイプ判別装置（５００）に対して自己のＮＡＴタイプを照会（Ｓ３２）し、得られた回答（Ｓ３３）を前記自己アドレス通知部（４５４）に報告（Ｓ３４）し、
    前記自己アドレス通知部（４５４）が、前記報告に基づいて前記回答を接続仲介装置（３０４）に対して通知（Ｓ３５）することを特徴とするネットワーク通信システム。
  12. 請求項７に記載のネットワーク通信システムにおいて、
    自己アドレス通知部（４５６）が、接続仲介装置（３０６）に対して自己の所在アドレスを通知する際に、まず、通信プロトコルとしてＵＤＰを用いた第１回通知（Ｓ５１）を行い、当該第１回通知に失敗した場合には、続いて、通信プロトコルとしてＴＣＰを用いた第２回通知（Ｓ５３）を行い、
    接続仲介装置（３０６）内のアドレステーブル格納部（３１６）が、端末ＩＤと所在アドレスに加えて、更に、通信プロトコルを対応づけたアドレステーブル（Ｔ７０）を格納する機能を有し、
    接続仲介装置（３０６）内のアドレステーブル更新部（３２６）が更新を行う際（Ｓ５４）に、前記第１回通知に基づいて更新を行う場合には、通信プロトコルとしてＵＤＰを対応づけ、前記第２回通知に基づいて更新を行う場合には、通信プロトコルとしてＴＣＰを対応づけ、
    接続仲介装置（３０６）内の通信元アドレス送信部（３３６）が、接続仲介依頼（Ｓ１２）が送信されてきたときに、前記アドレステーブル（Ｔ７０）を参照して、通信元の端末装置および通信先の端末装置の通信プロトコルを確認し、両端末装置の通信プロトコルがいずれもＵＤＰであった場合には、通信方法として通常通信を選択し、少なくとも一方の通信プロトコルがＴＣＰであった場合には、通信方法として迂回通信を選択し、選択した通信方法を通信先アドレスと共に返信する機能を有し、
    通信開始要求部（４４６Ａ）が、前記接続仲介装置（３０６）から通信元アドレス（ＡＤ２）と共に通信方法が返信されてきたときに、通信方法として通常通信が選択されていた場合には、前記通信元アドレス（ＡＤ２）に対して通信プロトコルＵＤＰを用いたアクセスにより通信開始要求（Ｓ１５）を行い、通信方法として迂回通信が選択されていた場合には、迂回通信処理部（４７６Ａ）に対して迂回通信指示（Ｓ５′）を行い、
    通信方法として通常通信が選択されていた場合には、通信先セッション確立部（４６６Ａ）と通信元セッション確立部（４３６Ｂ）との間で、通信プロトコルＵＤＰを用いた通常通信（Ｓ１７）を実行し、通信方法として迂回通信が選択されていた場合には、通信先の迂回通信処理部（４７６Ａ）と通信元の迂回通信処理部（４７６Ｂ）との間で、通信プロトコルＴＣＰを用いて、接続仲介装置（３０６）を介した迂回通信を実行することを特徴とするネットワーク通信システム。
  13. 請求項４、５、１０、１１のいずれかに記載のネットワーク通信システムにおいて、
    端末装置（２０３，４０４）のＮＡＴタイプ確認部（２８３，４８４）からネットワーク（Ｎ）を介してＮＡＴタイプの照会があったときに、当該照会に係る通信を利用して、照会元の端末装置のＮＡＴタイプを判別し、判別したＮＡＴタイプを照会元の端末装置のＮＡＴタイプ確認部に回答する処理を行うＮＡＴタイプ判別装置（５００）を更に備えることを特徴とするネットワーク通信システム。
  14. 請求項１３に記載のネットワーク通信システムにおいて、
    ＮＡＴタイプ判別装置（５００）として、ＳＴＵＮサーバを用いることを特徴とするネットワーク通信システム。
  15. 請求項１〜１２のいずれかに記載のネットワーク通信システムにおける複数の端末装置を構成する１台の端末装置（２０１，２０３，２０５，４０２，４０４，４０６）。
  16. 請求項１５に記載の１台の端末装置（２０１，２０３，２０５，４０２，４０４，４０６）としてコンピュータを機能させるプログラム。
  17. 請求項１〜１２のいずれかに記載のネットワーク通信システムにおける接続仲介装置（１０１，１０３，１０５，３０２，３０４，３０６）。
  18. 請求項１７に記載の接続仲介装置（１０１，１０３，１０５，３０２，３０４，３０６）としてコンピュータを機能させるプログラム。
JP2019537433A 2017-08-21 2017-08-21 ネットワーク通信システム Active JP6879373B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2017/029765 WO2019038802A1 (ja) 2017-08-21 2017-08-21 ネットワーク通信システム

Publications (2)

Publication Number Publication Date
JPWO2019038802A1 JPWO2019038802A1 (ja) 2020-10-29
JP6879373B2 true JP6879373B2 (ja) 2021-06-02

Family

ID=65439435

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019537433A Active JP6879373B2 (ja) 2017-08-21 2017-08-21 ネットワーク通信システム

Country Status (2)

Country Link
JP (1) JP6879373B2 (ja)
WO (1) WO2019038802A1 (ja)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3964266B2 (ja) * 2001-09-21 2007-08-22 株式会社いいじゃんネット 接続支援サーバ、端末、接続支援システム、接続支援方法、通信プログラム、および接続支援プログラム
JP2009206601A (ja) * 2008-02-26 2009-09-10 Funai Electric Co Ltd 情報配信システム
JP5887507B2 (ja) * 2011-11-28 2016-03-16 パナソニックＩｐマネジメント株式会社 通信機器間の接続確立方法、通信機器、及びサーバ装置

Also Published As

Publication number Publication date
WO2019038802A1 (ja) 2019-02-28
JPWO2019038802A1 (ja) 2020-10-29

Similar Documents

Publication Publication Date Title
BRPI0613848A2 (pt) método para estabelecer comunicação entre um primeiro dispositivo e um segundo dispositivo, sistema para estabelecer comunicação entre um primeiro dispositivo e um segundo dispositivo, sistema de sinalização e aparelho para comunicação através de uma rede
US8457144B2 (en) Communication system
JP2003046533A (ja) ネットワークシステム、その認証方法及びそのプログラム
JP5212071B2 (ja) 通信装置および移動端末
JP6787390B2 (ja) ネットワーク通信システム
JP6879373B2 (ja) ネットワーク通信システム
JP6879370B2 (ja) ネットワーク通信システム
JP3856427B2 (ja) 端末間の接続方法
US8510822B2 (en) Communication system, reliable communication mechanism, and communication method used for the same
JP6879372B2 (ja) ネットワーク通信システム
JP7056663B2 (ja) ネットワーク通信システム
JP2002281151A (ja) コンピュータ通信網を基盤とする通信システム及び方法
JP6879371B2 (ja) ネットワーク通信システム
JP2006333220A (ja) ネットワーク電話システム及びこのネットワーク電話システムのサーバ装置
JP6988545B2 (ja) ネットワーク通信システム
JPH10233808A (ja) ゲートウェイ選択方法及び装置
JP7173271B2 (ja) ネットワーク通信システム
JP5423659B2 (ja) 管理サーバ、およびその制御方法とプログラム。
JP4047736B2 (ja) 情報管理サービス方法およびシステム
JP2002290472A (ja) 通信接続先管理システム
JP3606445B2 (ja) コンピュータ通信網とコンピュータ通信方法
JP3520904B2 (ja) アドレス解決機能付き通信インタフェース装置
JP5454707B2 (ja) 通信装置
JP4936412B2 (ja) 電話番号処理装置
JP2001352411A (ja) ダイヤルアップ接続システム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200207

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200520

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: 20210330

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210412

R150 Certificate of patent or registration of utility model

Ref document number: 6879373

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150