JP2016066867A - 配信装置、配信システム及び配信プログラム - Google Patents

Abstract

【課題】ＰｏＣ等の技術を利用する場合に、グループ内端末同時通信数を増加させたり、広域でサービスを提供したりする。【解決手段】配信装置が、配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信する。【選択図】図１

Description

本発明は、データの配信を行なうための、配信装置、配信システム及び配信プログラムに関する。

トランシーバや無線機を用いた、プッシュ・ツー・トーク（Push to Talk）通信と呼ばれる通信方式が広く用いられている。かかるプッシュ・ツー・トーク通信は、全二重の音声通信ではなく、半二重の音声通信ではあるが、１対多のグループ一斉音声通信を可能とするものである。

このような、トランシーバや無線機といった機器を用いたプッシュ・ツー・トークは従来から長らく利用されている。そのため、以降の説明においては、トランシーバや無線機を用いたプッシュ・ツー・トークを「トランシーバ等によるプッシュ・ツー・トーク通信」と記載する。

その後、通信事業者が提供する携帯電話網が普及したことに伴い、携帯電話端末を、トランシーバや無線機のように利用することを特徴としたコミュニケーション手段である、ＰｏＣ（Push-to-Talk over Cellular）が登場した。

ＰｏＣは、モバイル関連のＷｅｂアプリケーション技術の標準化を行っている団体であるＯＭＡ（Open Mobile Alliance）によって、ＩＭＳ（IP Multimedia Subsystem）の一部として定義、標準化されている。

このような、ＰｏＣに関連する技術の一例が、例えば特許文献１に記載されている。特許文献１に記載の技術では、プッシュ・ツー・トークに参加する端末装置のグループを決定する場合に、予めグループに参加する端末装置を決定するのではなく、所定の条件に基づいて動的にグループ及びグループに参加する端末装置を決定する。

特開２００７−６７９９５号公報

上述したＰｏＣは、プッシュ・ツー・トーク通信を低コストで利用できるという利点がある。そのため、ＰｏＣは、一時期普及した。

しかしながら、基本的な通信手段としては、ＰｏＣよりも電子メールがより広く普及し、結果としてＰｏＣの需要は、個人用ではなく業務用に限られるようなケースが多くなった。そして、利用者の減少等を理由に、国内の通信事業者は２００９年から２０１１年頃に相次いでＰｏＣを利用するためのサービスの提供を終了した。すなわち、ＰｏＣは、結果として広く普及してはいない。

このようにＰｏＣが広く普及しなかった原因の１つとしては、ＰｏＣを従来型のプッシュ・ツー・トーク通信と同じ用途で使用することが困難であったからと考えられる。

具体的に述べると、従来型のプッシュ・ツー・トーク通信は、自営無線網を構築することにより、１の発信元から多の発信先への一斉通信における「多」の数（以降、「グループ内端末同時通信数」と記載する）を非常に多くしたり、広域で提供したりすることが可能であった。しかしながら、ＰｏＣを、このような従来型のプッシュ・ツー・トーク通信と同じ用途で用いることはこれまでの技術では実現困難である。

その理由について説明する。トランシーバや無線機を用いた無線通信であれば、送信元の無線機が電波を送信し、複数台の無線機が、その電波をそれぞれ受信できれば、音声を再生することが可能である。

しかし、携帯電話機及びＩＰ網を利用する場合には、音声をＲＴＰ（Real-time Transport Protocol）に準拠してパケット化したＲＴＰパケットや、配信制御用のＩＰパケットをそれぞれの携帯電話端末に向けて個々に配信しなければならなくなる。

そのため、理論上はグループ内端末同時通信数を増加させることが可能であっても、実際にはネットワーク帯域等の物理的制約があることから、グループ内端末同時通信数を増加させることが困難となる。

結果として、ＰｏＣの需要が業務用に限られるケースが多いという背景があるにも関わらず、エリアの広さやグループ内端末同時通信数等の規模が、業務用に使用するには十分耐えうるものでなかったことが、ＰｏＣが利用されなくなった原因であると考えられる。

以上まとめると、これまでの技術では、ＰｏＣ等の技術を利用する場合に、グループ内端末同時通信数を増加させたり、より広域でサービスを提供したりする、といったことが困難であった。

そこで、本発明は、ＰｏＣ等の技術を利用する場合に、グループ内端末同時通信数を増加させたり、広域でサービスを提供したりすることが可能な、配信装置、配信システム、配信方法及び配信プログラムを提供することを目的とする。

本発明の第１の観点によれば、配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信することを特徴とする配信装置が提供される。

本発明の第２の観点によれば、上記本発明の第１の観点により提供される配信装置と、端末とを含む配信システムであって、前記配信装置は、前記複製したパケットに、パケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報何れか又は双方を含ませ、前記配信装置からパケットを配信された端末は、パケットに含まれているパケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報の何れか又は双方を出力することを特徴とする配信システムが提供される。

本発明の第３の観点によれば、上記本発明の第１の観点により提供される配信装置と、端末とを含む配信システムであって、前記配信装置は、前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを配信の対象とし、前記送信権を付与された端末は、ユーザの操作に基づいて、送信権開放要求をパケットに含ませて前記配信装置に送信し、前記配信装置及び前記配信装置からパケットの配信を受けた端末は、前記パケットに前記送信権開放要求が含まれている場合に、前記送信権を付与された端末の送信権を剥奪することを特徴とする配信システムが提供される。

本発明の第４の観点によれば、配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信する配信装置としてコンピュータを機能させることを特徴とする配信プログラムが提供される。

本発明によれば、ＰｏＣ等の技術を利用する場合に、グループ内端末同時通信数を増加させたり、広域でサービスを提供したりすることが可能となる。

本発明の実施形態である配信システム全体の基本的構成を表す図である。 本発明の実施形態における配信装置の基本的構成を表す機能ブロック図である。 本発明の実施形態におけるグループ所属端末群情報記憶手段が記憶する情報の例を表す図である。 本発明の実施形態におけるパケットヘッダの書き換え例を表す図（１／２）である。 本発明の実施形態におけるパケットヘッダの書き換え例を表す図（２／２）である。 本発明の実施形態における配信装置の基本的動作を表すフローチャートである。 本発明の実施形態におけるＲＴＰパケットの流れを表す図である。 一般的な技術を使用した場合に、イーサネット・フレームが送信元から宛先に届く流れを表す図である。 本発明の実施例における、端末プッシュオン操作時の動作を説明するシーケンス図である。 本発明の実施例における、ＲＴＰパケット長時間未達時の動作を説明するシーケンス図である。 本発明の実施例における、送話終了フラグ送信時の動作を説明するシーケンス図である。

まず、本発明の実施形態の概略を説明する。本発明の実施形態は、携帯電話端末を、トランシーバや無線機のように利用することを特徴としたコミュニケーション手段であるＰｏＣ（Push-to-Talk over Cellular）等の技術分野に好適な実施形態である。

具体的には、プッシュ・ツー・トーク通信を、従来型のプッシュ・ツー・トーク通信と同程度の大規模かつ広域での利用を可能としつつ、携帯電話端末及び携帯電話事業者網を用いてより低コストで提供可能なＰｏＣグループ一斉音声通信を実現することを目的とする。

そのために、本実施形態における配信装置が、任意の送信元端末からのＲＴＰパケットを、予め設定した端末のグループ情報及び端末の死活情報に従って、それぞれの送信先端末に向けた複数パケットに複製して配信する。

更に、本実施形態における配信装置が、ＲＴＰパケットを複製する際に、ＩＰヘッダの送信元ＩＰアドレス情報を、配信装置のＩＰアドレスに変換して配信するようにしても良い。

更に、送信元端末は、ＲＴＰパケットの送信元ＩＤであるＳＳＲＣ（Synchrozination Source）フィールドに送信元端末ＩＤを付加して配信装置に通知するようにしても良い。あるいは、送信元端末は、ＲＴＰパケットのＲＴＰ拡張ヘッダに、グループＩＤ・端末ＩＤ・特権者情報などの情報を付加して通知するようにしても良い。そして、本実施形態における配信装置は、これらの通知に基づいて送信先端末所属グループやその他の情報を認識して配信制御をするようにしても良い。

以上が本発明の概略である。

次に、本発明の実施の形態について図面を参照して詳細に説明する。
［構成の説明］
まず、本発明の実施形態である、配信システムＳ１００の基本的構成について図１を参照して説明する。

図１を参照すると、配信システムＳ１００は、配信装置Ｅ１、第１の端末Ｔ１乃至第ｎの端末Ｔｎ、ローカルエリアネットワークＮ１、専用線網Ｎ２及び事業者携帯電話用パケット通信網Ｎ３を含む。

ここで、配信装置Ｅ１は、ＰｏＣグループ一斉音声通信を実現するための装置である。配信装置Ｅ１は、例えば本実施形態特有のプログラムを組み込んだサーバ装置により実現される。

また、第１の端末Ｔ１乃至第ｎの端末Ｔｎは、ユーザが利用する通信端末である。第１の端末Ｔ１乃至第ｎの端末Ｔｎは、例えば、携帯電話機により実現される。

また、ローカルエリアネットワークＮ１は、例えば配信装置Ｅ１を利用するユーザが使用するネットワークである。配信装置Ｅ１は、ローカルエリアネットワークＮ１に接続されている。

また、事業者携帯電話用パケット通信網Ｎ３は、例えば携帯電話機のキャリアが提供する通信網である。また、配信装置Ｅ１と事業者携帯電話用パケット通信網Ｎ３は、配信装置Ｅ１を利用するユーザ用に設けられた専用線網Ｎ２を介してネットワーク接続される。そして、このネットワーク接続を利用して配信装置Ｅ１と、第１の端末Ｔ１乃至第ｎの端末Ｔｎとは通信を行なう。

また、本実施形態では、第１の端末Ｔ１乃至第ｎの端末Ｔｎは、それぞれが何れかのグループに所属しているものとする。ここでいう「グループ」とは、トランシーバの周波数や、無線機のチャネルに相当するものであり、通話先とする端末群を選択するために使用する。

グループの設定方法には種々の方法が考えられる。例えば、何れのグループに、何れの端末が所属しているのかを表す情報を予め配信装置Ｅ１に記憶させることにより、グループの設定を行なうようにしても良い。

また、そうではなく、ユーザの操作を端末で受け付けるようにし、この操作に応じてグループの設定を行なうようにしても良い。つまり、通話する端末群をユーザに選択させることにより、動的にグループの設定を行なうようにしても良い。

更に、これらを組み合わせて、予め配信装置Ｅ１に設定した範囲で、通話する端末群をユーザに動的に選択させるようにしても良い。例えば、予め或るユーザの端末を第１のグループと第２のグループに設定しておく。そして、この或るユーザに、通話対象とするグループを、第１のグループと第２のグループの何れかから選択させるようにしてもよい。またそうではなく、例えば第１の端末Ｔ１、第２の端末Ｔ２、第３の端末Ｔ３及び第４の端末Ｔ４が或る１つのグループに所属するとして予め配信装置Ｅ１に設定しておく。そして、通信時に、発信元となる端末（例えば、第１の端末Ｔ１）のユーザにこの４台の端末の中の残りの３台（例えば、第２の端末Ｔ２、第３の端末Ｔ３及び第４の端末Ｔ４）から通話する端末群を選択させるようにしても良い。

また、以下の説明では、第１の端末Ｔ１、第３の端末Ｔ３及び第ｎの端末Ｔｎ等はグループＧ１に所属しており、第２の端末Ｔ２等はグループＧ２に所属しているものとする。なお、上記の文章にて「・・・第ｎの端末Ｔｎ等」、とのように「等」との文言を付加している理由であるが、グループＧ１やグループＧ２に、図示を省略している他の端末が含まれても良いことを想定しているからである。

次に、図２を参照して、特に配信装置Ｅ１に含まれる機能ブロックについて説明する。また、各機能ブロックによる処理又はデータの流れや、ＲＴＰパケットの流れについても説明する。なお、図３にも凡例として記載しているが、図３における実線による矢印は、各機能ブロックによる処理又はデータの流れを表している。また、図３における破線による矢印は、ＲＴＰパケットの流れを表している。また、機能ブロックの説明とは深く関係しない、ローカルエリアネットワークＮ１、専用線網Ｎ２及び事業者携帯電話用パケット通信網Ｎ３については図２での図示を省略する。

図２を参照すると配信システムＳ１００は、配信装置Ｅ１、送信元端末Ｓ１、及び第１の送信先端末Ｒ１乃至第Ｎの送信先端末Ｒｎを含む。

ここで、送信元端末Ｓ１と、第１の送信先端末Ｒ１乃至第Ｎの送信先端末Ｒｎは、それぞれが図１に表される第１の端末Ｔ１乃至第ｎの端末Ｔｎの何れかに相当するものである。また、各端末は、送信先及び送信元の役割が固定されているものではない。つまり、送信元端末Ｓ１は、第１の送信先端末Ｒ１乃至第Ｎの送信先端末Ｒｎになり得る。同様に、第１の送信先端末Ｒ１乃至第Ｎの送信先端末Ｒｎは送信元端末Ｓ１になり得る。なお、以下の説明において、第１の送信先端末Ｒ１乃至第Ｎの送信先端末Ｒｎの何れかの端末を特定することなく指す場合には、単に「端末Ｒ」と記載する。

また、配信装置Ｅ１は、ＲＴＰパケット受信部Ｍ１、受信ＲＴＰパケット記憶部Ｍ２、送信元端末ＩＤ制御部Ｍ３、送信権取得制御部Ｍ４、ＲＴＰパケット複製部Ｍ５、送信ＲＴＰパケット記憶部Ｍ６、ＲＴＰパケット送信部Ｍ７、ＩＰヘッダ制御部Ｍ８−１、ＵＤＰヘッダ制御部Ｍ８−２、ＲＴＰヘッダ制御部Ｍ８−３、ＲＴＰ拡張ヘッダ制御部Ｍ８−４及びグループ所属端末群情報記憶部Ｄ１を含む。

ＲＴＰパケット受信部Ｍ１は、送信元端末Ｓ１が送信したＲＴＰパケットを受信する。

受信ＲＴＰパケット記憶部Ｍ２は、ＲＴＰパケット受信部Ｍ１が受信したＲＴＰパケットを一時的に記憶する。

送信元端末ＩＤ制御部Ｍ３は、ＲＴＰパケットに含まれるＳＳＲＣ（送信元ＩＤ）フィールドから送信元端末ＩＤを抽出して、抽出した送信元端末ＩＤを送信権取得制御部Ｍ４やＲＴＰパケット複製部Ｍ５に出力する。

送信権取得制御部Ｍ４は、送信元端末Ｓ１に送信権を与えるか否かを決定する。

ＲＴＰパケット複製部Ｍ５は、ＲＴＰパケットの複製を作成する。

送信ＲＴＰパケット記憶部Ｍ６は、ＲＴＰパケット複製部Ｍ５が作成したＲＴＰパケットの複製を一時的に記憶する。

ＲＴＰパケット送信部Ｍ７は、送信ＲＴＰパケット記憶部Ｍ６が記憶しているＲＴＰパケットの複製を、第１の送信先端末Ｒ１乃至第Ｎの送信先端末Ｒｎの内の、送信先となる端末に対して送信する。

ＩＰヘッダ制御部Ｍ８−１は、ＲＴＰパケット複製部Ｍ５が作成するＲＴＰパケットの複製のＩＰヘッダに所定の情報を書き込む。また、ＵＤＰヘッダ制御部Ｍ８−２は、ＲＴＰパケット複製部Ｍ５が作成するＲＴＰパケットの複製のＵＤＰヘッダに所定の情報を書き込む。更に、ＲＴＰヘッダ制御部Ｍ８−３は、ＲＴＰパケット複製部Ｍ５が作成するＲＴＰパケットの複製のＲＴＰヘッダに所定の情報を書き込む。更に、ＲＴＰ拡張ヘッダ制御部Ｍ８−４は、ＲＴＰパケット複製部Ｍ５が作成するＲＴＰパケットの複製のＲＴＰ拡張ヘッダに所定の情報を書き込む。

グループ所属端末群情報記憶部Ｄ１は、各グループに所属する各端末の端末ＩＤ等が含まれた情報であるグループ所属端末群情報を記憶する。そして、送信権取得制御部Ｍ４や、ＲＴＰパケット複製部Ｍ５は、このグループ所属端末群情報を参照して処理を行なう。

ここで、グループ所属端末群情報記憶部Ｄ１が記憶するグループ所属端末群情報のより具体的な例について図３を参照して説明する。図３は、グループ所属端末群情報の一例を表す図である。

図３に表されるように、グループ所属端末群情報は、グループ所属端末群情報データベーステーブル及び端末情報テーブルの２つのテーブルを含む。

ここで、グループ所属端末群情報データベーステーブルは、グループＩＤをキーに検索されるテーブルである。グループ所属端末群情報データベーステーブルには、それぞれのグループＩＤに対応したそれぞれのグループに所属している所属端末を識別するための端末ＩＤが格納されている。何れかのグループＩＤをキーとして検索することにより、このグループＩＤに対応するグループに所属している端末の端末ＩＤを抽出することができる。また、各グループに所属している何れの端末が現在送信権を取得しているのかも抽出することができる。なお、送信権とは、ＲＴＰパケットの送信元となる権利である。送信権を取得している端末が、１対多の通信における、１となる。

ここで、送信元端末が所属しているグループに送信権を得ている端末が有るか否かを検索する方法について説明する。

例えば、送信元端末ＩＤを検索キーとして端末情報テーブルを検索することにより、送信元端末Ｓ１が所属するグループのグループＩＤを取得する。そして、取得したグループＩＤで一意に識別されるグループ内に、送信権を取得している端末が有るか否かを確認する。このために、送信権の取得又は現在送信権を得ている端末が有るか否か、有るとすればどの端末であるか、という情報を、送信権の取得及び開放が行われるたびに、グループＩＤと紐付けて図３のように記憶しておく。

また、図３のようにグループＩＤと現在送信権を得ている端末を紐付けて記憶しておくのではなくて、送信権の取得及び開放が行われるたびに、現在送信権を得ている端末であるか否かを表す情報を各端末ＩＤに紐づけておくようにしても良い。この場合には、送信元端末Ｓ１が所属するグループのグループＩＤを検索キーとして所属端末群情報データベーステーブルを検索することにより、送信元端末Ｓ１が所属するグループに所属している端末の端末ＩＤを全て抽出する。そして、抽出した端末ＩＤのそれぞれに紐付いている現在送信権を得ている端末であるか否かを表す情報を参照することにより、現在送信権を得ている端末が有るか否かを判定する。こうすることによっても、送信元端末Ｓ１が所属している所属グループで送信権を取得している端末が有るか否かを確認することができる。

なお、本実施形態では、音声通信を行なうことを想定していることから、送信権ではなく、送話権と表現しても良いが、本実施形態の適用範囲は必ずしも音声通信に限定されないことから、本明細書では、送信権との表現を用いる。また、本実施形態において、１つのグループに含まれる端末の台数に特に制限はない。

他方、端末情報テーブルは、端末ＩＤをキーに検索されるテーブルである。端末情報テーブルには、それぞれの端末ＩＤにより識別される各端末に関しての情報が格納されている。具体的には、端末のＩＰアドレス、特権者情報、選択可能グループ情報、選択グループ情報、死活状態が格納されている。

端末のＩＰアドレスは、各端末に割り当てられているＩＰアドレスである。

また、特権者情報とは、各端末が特権者として設定されているか否かを表す情報である。端末が特権者として設定されている場合には、値をＴｒｕｅとし、端末が特権者として設定されていない場合には、値をｆａｌｓｅとする。特権者が具体的にどのようなものであるのかは、第１の変形例の説明として後述する。

選択可能グループ情報とは、各端末が、ＲＴＰパケットの送信先のグループとして選択できるグループが、どのグループであるかを表す情報である。選択可能グループ情報は、例えばビットマップインデックスにより管理されるようにすると良い。具体的には、配信システム１００に含まれる全てのグループ毎に行を設け、各端末がそのグループを選択できるのであれば、値を「１」とし、各端末がそのグループを選択できるのであれば、値を「０」とするように管理する。送信権取得制御部Ｍ４や、ＲＴＰパケット複製部Ｍ５は、このビットマップインデックスを使用して検索することにより、各端末が選択できるグループであるか否かを判断することができる。

選択グループ情報は、各端末を使用するユーザが、選択したグループである。ここで、選択可能グループが１つしかない端末があったとすれば、その端末は、ユーザによる選択をされるまでもなく、その１つの選択可能グループが、そのまま選択グループとなる。一方で、選択可能グループが複数ある端末であれば、その端末のユーザは、この複数のグループのなかから送信先とするグループを選択する。つまり、この選択されたグループが選択グループとなる。そして、選択グループに含まれる各端末がＲＴＰパケットの送信先となる。

死活状態は、現在その端末が通信可能な状態にあるか否かを表す情報である。端末が通信可能な状態であれば、値をＡｃｔｉｖｅとする。一方で、端末が無線通信可能な範囲の圏外に在圏していたり、端末がバッテリ切れをおこしていたりするような状態であって、端末が通信できない状態であれば値をｎｏｎとする。

これらの情報の内、端末ＩＤ、ＩＰアドレス、特権者情報及び選択可能グループ情報は、例えば予め配信装置Ｅ１を管理する保守者が入力しておくことで静的に設定される。

また、これらの情報の内、選択グループ情報は、例えば端末のグループ選択操作で動的に設定されるものとする。

更に、これらの情報の内、死活状態は、例えば端末と配信装置又は端末とは別途用意する死活監視サーバが各端末の死活監視を行い、この死活監視の結果を配信装置Ｅ１との間でやり取りすることで動的に設定されることとする。

また、これらの情報を他の情報で置き換えたり、これらの情報以外の他の情報を追加したりするようにしても良い。

例えば、ユーザが端末使用時に端末を認証するときに、ユーザにユーザＩＤを入力させるようにする。そして、特権者情報をユーザＩＤに関連付けた情報とするようにしても良い。つまり、端末ＩＤ毎に特権者情報を紐付けるのではなく、ユーザＩＤ毎に特権者情報を紐付けるようにしても良い。これにより、同じ端末であっても、使用するユーザにより、特権者情報の有無を異ならせることができる。

他にも、例えば盗難・亡失対策用に、盗難された端末又は亡失した端末を使用不可とするための盗難・亡失情報を設けてもよい。そして、盗難・亡失情報がｆａｌｓｅであれば、端末を通常通りに使用可能とする。一方で、ユーザから端末の盗難又は亡失の届けを受けた配信装置Ｅ１の保守者が、盗難された又は亡失した端末の盗難・亡失情報をｔｒｕｅと設定した場合には、この盗難された又は亡失した端末を使用不可とするようにしても良い。

次に、送信元端末Ｓ１から送信されるＲＴＰパケットや、ＲＴＰパケット複製部Ｍ５が複製することにより作成するＲＴＰパケットのフォーマットについて図４−１及び図４−２を参照して説明する。かかるフォーマットは基本的にＲＴＰに準拠するものである。

しかしながら、「信号送信時の設定内容」に〈書き換え〉と記載されている項目については、ＲＴＰパケット複製部Ｍ５がＲＴＰパケットを複製する際に書き換えられる。具体的な、書き換え内容については後述する。

また、「信号送信時の設定内容」に［受信したパケットのまま］と記載されている項目については、ＲＴＰパケット複製部Ｍ５がＲＴＰパケットを複製する際に書き換えられることはなく、送信元端末Ｓ１から受信したＲＴＰパケットの値のまま複製される。

更に、「信号送信時の設定内容」に［受信したパケットのまま］及び〈本実施形態特有の情報〉と記載されている項目については、送信元端末Ｓ１から受信したＲＴＰパケットの値のまま複製され、且つ、本実施形態特有の方法で利用される。本実施形態特有の方法で利用としては、例えば、送信元端末Ｓ１は、ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）フィールドに、送信元端末Ｓ１を一意に識別するためのＩＤを格納して送信する、といった利用方法である。

更に、ＲＴＰ拡張ヘッダを利用することも考えられる。そのため、図５では、ＲＴＰ拡張ヘッダも使用する場合の例を記載している。具体的には、ＲＴＰ拡張ヘッダの〈本実施形態特有の情報（例）〉と記載されている項目である。また、図２においてもＲＴＰ拡張ヘッダ制御部Ｍ８−４を記載している。

しかしながら、ＲＴＰ拡張ヘッダを使用することは必須ではない。そこで、本実施形態の説明では、ＲＴＰ拡張ヘッダは使用しないケースについて説明する。そして、ＲＴＰ拡張ヘッダを使用するケースについては、本実施形態の変形例として後述する。なお、ＲＴＰ拡張ヘッダは使用しないケースの場合には、ＲＴＰ拡張ヘッダ制御部Ｍ８−４を省略することができる。
［動作の説明］
次に、図５のフローチャート等を参照して、本実施形態における配信装置Ｅ１の配信時の動作について詳細に説明する。なお、図５は配信装置Ｅ１の基本的動作を表すフローチャートである。

まず、送信元端末Ｓ１が、ユーザからのプッシュオン操作を受け付ける。プッシュオン操作を受け付けた送信元端末Ｓ１は、配信装置Ｅ１に対して、ＲＴＰパケットを送信する。そして、配信装置Ｅ１は、送信元端末Ｓ１が送信したＲＴＰパケットをＲＴＰパケット受信部Ｍ１によって受信する（ステップＳ１１）。

なお、本明細書では、送話を開始するために、送信権取得要求するため操作を上記のように「プッシュオン操作」と表現する。また、これとは逆に送話を終了するために送信権開放要求するための操作を「プッシュオフ操作」と表現する。これは、「押して話す」という本来の「プッシュ・ツー・トーク」の語源に合わせた表現である。

実際の操作の受け付け方としては、例えば送信元端末Ｓ１に接続する外部の送話ボタンを設け、外部の送話ボタンを押した時点で送信権取得要求を意味し（つまり、プッシュオン操作が行われたと判断し）、押したままの間は送話中とし、放した時点で送信権開放要求を意味する（つまり、プッシュオフ操作が行われたと判断する）、というように語源通りにしてもよい。

しかしながら、必ずしも語源通りにする必要はなく、送話中に「押したままとする」という操作を要さないようにしても良い。例えば、端末上のディスプレイ上に表示した「送信権未取得状態」というアイコンに触れたら送信権取得要求を意味し（つまり、プッシュオン操作が行われたと判断し）、その後、何れのアイコンも触れられないのならば、送話中とし、端末上のディスプレイ上に表示した「送信権取得状態」というアイコンに触れたら送信権開放要求を意味する（つまり、プッシュオフ操作が行われたと判断する）、というようにしても良い。

次に、配信装置Ｅ１の受信ＲＴＰパケット記憶部Ｍ２が、ＲＴＰパケット受信部Ｍ１が受信したＲＴＰパケットを記憶する（ステップＳ１２）。

ここで、ＲＴＰパケット受信部Ｍ１が受信したＲＴＰパケットが配信中の（すなわち、現在送話中の）送信元端末が送信したＲＴＰパケットであるか否かを判定する（ステップＳ１３）。例えば、ＲＴＰパケット受信部Ｍ１が送信権取得制御部Ｍ４から、現在送信権を得ている端末のＩＰアドレスを取得しておく。そして、ＲＴＰパケット受信部Ｍ１が受信したＲＴＰパケットの送信元ＩＰアドレスが、現在送話権を得て、配信中の（すなわち、現在送話中の）送信元端末のＩＰアドレスと同一であるか否かに基づいて判定をする。

ＲＴＰパケット受信部Ｍ１が受信したＲＴＰパケットが、配信中の送信元端末が送信したものであれば（ステップＳ１３においてＹｅｓ）ステップＳ１８の処理を行なうために、ＲＴＰパケットをＲＴＰパケット複製部Ｍ５に渡す。なお、一般的な技術であることから詳細な説明は省略するが、ジッタバッファの制御等の、パケット通信における一般的な処理も受信ＲＴＰパケット記憶部Ｍ２で行う。

一方で、ＲＴＰパケット受信部Ｍ１が受信したＲＴＰパケットが、配信中の送信元端末が送信したものでなく、他の端末が送信したものであれば（ステップＳ１３においてＮｏ）送信元端末ＩＤ制御部Ｍ３に処理を渡し、ステップＳ１４に進む。

ステップＳ１４において、送信元端末ＩＤ制御部Ｍ３は、ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）フィールドから送信元端末ＩＤを抽出する。そして、送信元端末ＩＤ制御部Ｍ３は、この抽出した送信元端末ＩＤを送信権取得制御部Ｍ４に出力し、送信権取得制御部Ｍ４に処理を渡し、ステップＳ１５に進む。

ステップＳ１５において、送信権取得制御部Ｍ４は、送信元端末ＩＤ制御部Ｍ３から受信した送信元端末ＩＤを検索キーとしてグループ所属端末群情報記憶部Ｄ１に記憶された端末情報テーブルを検索する。そして、端末情報テーブル内送信元端末Ｓ１の選択グループを参照することにより、送信元端末Ｓ１が所属している所属グループのグループＩＤを求める。

更に、送信権取得制御部Ｍ４は、このグループＩＤを検索キーとしてグループ所属端末群情報記憶部Ｄ１に記憶されたグループ所属端末群情報データベーステーブルを検索する。そして、送信元端末Ｓ１が所属している所属グループで送信権を取得している端末が有るか否かを確認する（ステップＳ１５）。

ステップＳ１５における確認の結果、送信元端末Ｓ１が所属するグループに送信権を取得している端末がなければ（ステップＳ１５においてＮｏ）、送信元端末Ｓ１に送信権を与える。そして、送信元端末Ｓ１に送信権を与えた場合は、ＲＴＰパケットをＲＴＰパケット複製部Ｍ５に渡す（ステップＳ１６）。また、グループ所属端末群情報データベーステーブルの送信権取得端末の項目を更新する。この場合に、送信元端末Ｓ１に送信権が与えられた旨を、送信元端末Ｓ１に対して通知してもよい。

ステップＳ１５における確認の結果、送信元端末Ｓ１以外の端末が送信権を取得している場合には（ステップＳ１５においてＹｅｓ）、送信元端末Ｓ１に送信権を与えず、当該ＲＴＰパケットを破棄する（ステップＳ１７）。また、送信元端末Ｓ１に送信権が与えられなかった旨を、送信元端末Ｓ１に対して通知してもよい。

送信元端末Ｓ１から送信されたＲＴＰパケットが、ＲＴＰパケット複製部Ｍ５に渡された場合は（ステップＳ１３においてＹｅｓ、又はステップＳ１５においてＮｏ及びステップＳ１６）、グループ所属端末群情報記憶部Ｄ１の情報に基づいて送信先送信元端末Ｓ１が所属する所属グループの各端末を特定する。そして、特定した各端末にＲＴＰパケットを配信するために、ＲＴＰパケット複製部Ｍ５は、各端末宛にＲＴＰパケットを複製する。また、ＲＴＰパケット複製部Ｍ５は、複製したＲＴＰパケットを送信ＲＴＰパケット記憶部Ｍ６に渡す（ステップＳ１８）。

ここで、ＲＴＰパケットの送信先について図６を参照して説明する。図６に表される第１の端末Ｔ１がプッシュ操作を受け付けた送信元端末Ｓ１に相当する。よって、第１の端末Ｔ１から配信装置Ｅ１に対してＲＴＰパケットが送信される。

また、第１の端末Ｔ１はグループＧ１に所属する。そのため、第１の端末Ｔ１と同じグループＧ１に所属する第３の端末Ｔ３、第ｎの端末Ｔｎ等にはＲＴＰパケットが配信される。一方で、第１の端末Ｔ１と異なるグループに所属する第３の端末Ｔ３等には配信されない。

このように配信先が決定される理由について説明する。それは、グループ所属端末群情報記憶部Ｄ１に、グループＧ１に所属する端末の情報として、第１の端末Ｔ１、第３の端末Ｔ３及び第ｎの端末Ｔｎ等の端末ＩＤ、並びに、これら端末ＩＤのそれぞれに関連付いたＩＰアドレスの情報が、記憶されているからである。また、グループＧ２に所属する端末の情報として、第２の端末Ｔ２等の端末ＩＤ、並びに、第２の端末Ｔ２等の端末ＩＤのそれぞれに関連付いたＩＰアドレスの情報が記憶されているからである。そして、ＲＴＰパケット複製部Ｍ５が、グループ所属端末群情報記憶部Ｄ１に記憶されているこれらの情報に基づいてＲＴＰの複製及び配信先を決めているからである。

また、ＲＴＰパケット複製部Ｍ５は、送信元端末Ｓ１から受信したＲＴＰパケットを単純に複製するだけではない。この点について、一般的な技術と比較しながら説明をする。

まず、一般的な技術によって、イーサネット（登録商標）上を流れる一般的なＩＰパケットを転送する際の様子について図７を参照して説明する。なお、図中において凡例として説明しているように、イーサネット上を流れるパケットの上段部にはＩＰパケットに関する情報を表す。具体的には、情報として宛先ＩＰアドレス及び送信元ＩＰアドレスを表す。また、下段側にはイーサネット・フレームに関する情報を表す。具体的には、情報として宛先ＭＡＣアドレス及び送信元ＭＡＣアドレスを表す。

イーサネット・フレームはルータで中継されるときに作り換えられる。そのとき、イーサネット・フレームに記載されている送信元のＭＡＣアドレスと宛先のＭＡＣアドレスが変わる。

一方で、ＩＰパケットには送信元ＩＰアドレスと宛先ＩＰアドレスが書いてあるが、これらはルータで中継されたとしても、宛先に届くまで変わらない。この点について、図７の例にあてはめて説明する。

図７の例にあてはめると、パソコンＡからサーバＸにＩＰパケットが送られる場合、宛先ＭＡＣアドレスは、ルータを中継する際に、ルータのネットワークセグメント１側のＭＡＣアドレスＣからサーバＸのＭＡＣアドレスＥに変わる。また、パソコンＡからサーバＸにＩＰパケットが送られる場合、送信元ＭＡＣアドレスは、パソコンＡのＭＡＣアドレスＡからルータのネットワークセグメント２側のＭＡＣアドレスＤに変わる。しかし、ＩＰアドレスは、宛先ＩＰアドレスも送信元ＩＰアドレスも変わらない。

ここで仮に、配信装置Ｅ１が図７に表されるルータと同様の動作をすると考える。そうすると、配信装置Ｅ１は、ＭＡＣアドレスは書き換えるが、ＩＰアドレスは書き換えないことになる。

しかし、配信装置Ｅ１から送信元ＩＰアドレスを第１の端末Ｔ１のＩＰアドレスとして配信してしまうと問題が生じる可能性がある。例えば、第１の端末Ｔ１と第２の端末Ｔ２が同一のネットワークセグメントに存在していたとする。そして、配信装置Ｅ１は、これら２つの端末が存在するネットワークセグメントとは異なるネットワークセグメントに存在していたとする。

この場合、第１の端末Ｔ１のＩＰアドレスが送信元ＩＰアドレスとなったＩＰパケットが、配信装置Ｅ１経由で、配信装置Ｅ１が存在するネットワークセグメントから第２の端末Ｔ２に届く。すると、第２の端末Ｔ２からみると、第１の端末Ｔ１が、第２の端末Ｔ２とは異なるネットワークセグメント（配信装置Ｅ１が存在するネットワークセグメント）に存在するかのように誤認する可能性がある。

このため、ＩＰヘッダ制御部Ｍ８−１は、送信元ＩＰアドレスを送信元端末Ｓ１のＩＰアドレスから配信装置Ｅ１のＩＰアドレスに書き換え、更に、宛先ＩＰアドレスを、配信装置Ｅ１のＩＰアドレスから各送信先端末のＩＰアドレスに書き換えて送信する。そして、ＲＴＰパケット複製部Ｍ５は、この書き換えられたＩＰアドレスを使用してＲＴＰパケットを複製する。複製したＲＴＰパケットは、配信するために、送信ＲＴＰパケット記憶部Ｍ６に渡される（ステップＳ１８）。

送信ＲＴＰパケット記憶部Ｍ６に格納されたＲＴＰパケットは、ＲＴＰパケット送信部Ｍ７に渡され、実際に各送信先端末（第１の送信先端末Ｒ１乃至第ｎの送信先端末Ｒｎ）に配信する（ステップＳ１９）。

以上説明した動作により、配信装置Ｅ１による配信が実現される。

なお、ステップＳ１９でＲＴＰパケット送信する方法として、２種類のＲＴＰパケット送信方法を選択できる。

１つ目のＲＴＰパケット送信方法は、ＲＴＰパケットがＲＴＰパケット記憶部Ｍ６に格納された時点で、直ちにＲＴＰパケットを配信する方法（以降、「即時送信方式」と記載する）である。

もう１つ目の送信方法は、ＲＴＰパケット記憶部Ｍ６に格納されたＲＴＰパケットを、一定周期で配信する方法（以降、「定間隔送信方式」と記載する）である。ここで、一定周期とは、任意の周期であって良いが、例えば、２０ミリ秒とすることが考えられる。

即時送信方式は、ネットワークのゆらぎが十分小さい場合に有利な方式である。即時送信方式では、直ちにＲＴＰパケットが配信されることから通話の遅延をより少なくすることができる。

一方で、定間隔送信方式は、ネットワークのゆらぎが比較的大きい場合に有利な方式である。本実施形態では、端末同士が直接音声通信するのではなく、配信装置Ｅ１を介す。そのため、上りのゆらぎと下りのゆらぎの両方のゆらぎの影響を受ける。そのため、一般的なジッタバッファではゆらぎを吸収しきれず、頻繁な音飛びにつながる可能性がある。そこで、定間隔送信方式を採用することによって配信装置が一旦ゆらぎを吸収し、パケット送信間隔を一定間隔に整形して送信する。

ただし、ゆらぎの大きさに比例して、音声遅延が大きくなるという欠点もある。しかし、本実施形態のグループ一斉音声通信は、音声の片方向通信を前提としたものなので、通常の電話の同時双方向音声通信のようには遅延が問題とならない用途も多い。また、本実施形態のグループ一斉音声通信は、送話者がプッシュ操作をして切り替わるため、それまで蓄積した音声遅延が、送話者が切り替わるタイミングでリセットされる。つまり、本実施形態では、音声遅延がそれほど問題とならないことが多いので、ネットワークのゆらぎが比較的大きい場合には、定間隔送信方式を採用すると有益である。

なお、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。例えば、上記実施形態を、以下に説明する各変形例のように変形することが可能である。

［第１の変形例］
次に、上述した実施形態を変形した例の１つである、第１の変形例について説明する。

上述した実施形態では、送信元端末Ｓ１は、ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）フィールドに、送信元端末Ｓ１を一意に識別するためのＩＤを格納して送信するが、ＲＴＰ拡張ヘッダについては使用しない例について説明した。

第１の変形例ではＲＴＰ拡張ヘッダも使用する例について説明する。具体的には、図４−１及び図４−２を参照して説明したように、ＲＴＰ拡張ヘッダに、送信元端末ＩＤ、グループＩＤ及び特権者情報等を格納するケースについて説明する。

なお、本変形例のように、ＲＴＰ拡張ヘッダを使用すると、ＲＴＰパケットのサイズが増える。よって、ＲＴＰパケットを送受信するために、より多くのネットワーク帯域を必要とするというデメリットが発生する。しかし、このデメリットと引き換えに、ＲＴＰ拡張ヘッダを使用すると、このデメリットと引き換えに、サーバの処理負荷を軽減したり、提供できるサービス機能が増したりするというメリットが発生する。そのため、これらのメリットを享受したい場合に、本変形例を採用すると有益である。

ＲＴＰ拡張ヘッダの利用方法としては、まず、上述の実施形態のように送信元端末ＩＤをＳＳＲＣフィールドに載せるのではなく、ＲＴＰ拡張ヘッダに送信元端末ＩＤを載せることが考えられる。ＲＴＰに準拠した場合には、ＳＳＲＣフィールドのサイズは３２ビット（＝４バイト）となる。そのため、送信元端末ＩＤをＳＳＲＣに載せる場合には、送信元端末ＩＤを４バイトで表さないとならないという制限がある。しかしながら、ＳＳＲＣフィールドではなくＲＴＰ拡張ヘッダに送信元端末ＩＤを載せることによって、この制限を撤廃することができる。

このように４バイトの制限を撤廃することにより、端末ＩＤに柔軟性を持たせることができる。具体例として、例えばＭＳＩＳＤＮ（国番号（８１）＋携帯電話番号から頭の「０」をとったもの）を使用することができる。ＭＳＩＳＤＮは、１２桁であるが、バイナリ値で格納することによって、より少ないバイト数で載せることができる、ＭＳＩＳＤＮを端末ＩＤとして使用することで、独自のＩＤを別途定義して使用する煩わしさや手間がなくなる。

また、ＲＴＰ拡張ヘッダにグループＩＤを載せることも考えられる。このようにＲＴＰ拡張ヘッダにグループＩＤを載せることによって、ＲＴＰ拡張ヘッダを参照すれば送信元端末Ｓ１の所属しているグループを識別することが可能となる。つまり、送信元端末Ｓ１の所属グループを求めるために、端末ＩＤを検索キーとしたグループ所属情報端末群情報の検索を行わなくてもよくなる、というメリットが発生する。そして検索を行わなくてよい分、配信装置Ｅ１が他の処理に割ける処理能力が向上し、結果としてグループ内端末同時通信数等を増やすことができる。

更に、ＲＴＰ拡張ヘッダに特権者情報を載せることも考えられる。このようにＲＴＰ拡張ヘッダに特権者情報を載せることによって、各端末のそれぞれを特権者とするか否かを設定することができる。

ここで、特権者がどのようなものであるかについて説明する。プッシュ・ツー・トークグループ一斉音声通信では、無線での使用を前提としているため、送信者が送信権を取得したまま、無線圏外に移動してしまったり、端末のバッテリの残量がなくなり、端末がバッテリ切れに陥ってしまったりして、送信者が通信をできない状況になってしまうことが想定される。

このような場合、送信権開放要求を配信装置Ｅ１等が受信することはできない。そのため、特定の端末が送信権を持ったままとなってしまう。このような状況の発生を避けるために、送信権開放要求の有無に関わらず、一定時間で送信権を強制解除する、という方法が考えられる。しかし、特定の送話者が長時間、音声情報を一方的に流したい用途も考えられ、この場合には、この一定時間で送信権を強制解除する、という方法では不都合が発生する。

そこで、本変形例では、特権者を設ける。そして、送信権取得制御手順Ｍ４は、特権者からのプッシュ操作（送信権取得要求）を受けた場合は、他の端末が送信権を取得していたとしても、強制的に送信権を取得する。そして、取得した送信権を特権者の端末に与えて、かかる特権者の端末が送信したＲＴＰパケットを配信対象とする。こうすることにより、特権者以外の端末が送信権を取得中に無線圏外に移動してしまったり、端末のバッテリ切れに陥ってしまったりしたような場合であっても他の端末間での通信を継続することが可能となる。

また、特権者の端末が送信権を取得中に無線圏外に移動してしまったり、端末のバッテリ切れに陥ってしまったりすることも想定される。そのため、同一グループの特権者を１台に限定することなく、複数台を特権者として設定してもよい。

更に、ＲＴＰ拡張ヘッダに送話終了フラグを載せることも考えられる。このようにＲＴＰ拡張ヘッダに送話終了フラグを載せることによって、送信権解放要求を明示的に通知することができる。

仮に、送話終了フラグを載せない場合、ＲＴＰパケットが一定時間受信されない場合には送話が終了したとみなし、送信権を開放することが考えられる。こうする場合、ＲＴＰパケットのネットワーク遅延をどこまで許すかによって、送話終了とみなすまでの時間が変わる。例えば、ネットワーク遅延が小さいことが予想されるような環境では、送話終了と判断するまでの時間を短くすることができるため、送話終了後、短時間で送話終了と判断することができる。しかしながら、ネットワーク遅延が大きくなることが予想される環境では、送話終了と判断するまでの時間を長くとる必要がある。なぜならば、一定時間ＲＴＰパケットが受信されない理由が、送信元からのＲＴＰパケットの送信が終了したからなのか、送信元からのＲＴＰパケットが遅延を受けていることから未だＲＴＰパケットが到着していないのか、の何れなのかが区別できないからである。そのため、ネットワーク遅延が大きくなることが予想される環境では、送話終了してからしばらくしないと、送信先端末Ｒで送話終了を認識できなかったり、配信装置Ｅ１で送信権開放が行えなかったりする。

そこで、送信元端末Ｓ１がプッシュオフ操作を行ったタイミングで送信するＲＴＰパケットのＲＴＰ拡張ヘッダに、送話終了を意味する送話終了フラグを載せる。加えて、また、送話終了フラグを含めて配信装置のＲＴＰパケット複製部Ｍ５がＲＴＰパケットを複製して受信端末に通知する。更に、配信装置Ｅ１及び受信端末が送話終了フラグを参照する。

このようにすることによって、配信装置Ｅ１及び受信端末は、送信元端末Ｓ１がプッシュオフ操作を行った後、直ちに送話終了を認識することができる。

［第２の変形例］
次に、上述した実施形態を変形した例の１つである、第２の変形例について説明する。本変形例は、第１の変形例同様に、ＲＴＰ拡張ヘッダを使用するものである。

まず、本変形例では、送信元端末Ｓ１の名称を送信先端末Ｒにて表示可能とする。そのために、配信装置Ｅ１が配信するＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末Ｓ１の端末名称情報を格納する。

具体的には、配信装置Ｅ１の、端末情報テーブルにて送信元端末Ｓ１の端末ＩＤと送信元端末Ｓ１の端末名称情報を紐付けて記憶しておく。

そして、ＲＴＰ拡張ヘッダ制御部Ｍ８−４は、送信元端末Ｓ１から受信したＲＴＰパケットに含まれる送信元端末Ｓ１の端末ＩＤを検索キーにして端末情報テーブルを検索することにより、予め設定しておいた端末ＩＤに関連付けた端末名称情報を取得する。そして、ＲＴＰ拡張ヘッダ制御部Ｍ８−４は、取得した端末名称情報から送信元端末名称を求める。そして、配信装置Ｅ１は、送信者が変わった際の最初のＲＴＰパケットのＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末名称を含めて配信する。

配信を受けた送信先端末Ｒでは、ＲＴＰ拡張ヘッダを参照することにより、送信元端末Ｓ１の名称を知ることができ、この送信元端末Ｓ１の名称を送信先端末Ｒの表示部に表示することが可能となる。

次に、ＲＴＰ拡張ヘッダに、送信者名称情報を格納するケースについて説明する。

予め配信装置Ｅ１にユーザＩＤに関連付けたユーザ名称情報を設定しておく。
配信装置Ｅ１の、端末情報テーブルにてユーザＩＤと、このユーザＩＤに対応するユーザのユーザ名称情報を紐付けて記憶しておく。

また、送信元端末Ｓ１を使用時に、送信元端末Ｓ１に使用者を識別することが可能なユーザＩＤを登録する。

そして、送信元端末Ｓ１は、ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末Ｓ１に登録されたユーザＩＤを付加して配信装置Ｅ１に通知する。

ＲＴＰ拡張ヘッダ制御部Ｍ８−４は、送信元端末Ｓ１から受信したＲＴＰパケットに含まれるユーザＩＤをキー検索キーにして端末情報テーブルを検索することにより、予め設定しておいたユーザＩＤに関連付けたユーザ名称情報取得し、取得したユーザ名称情報から送信者名称情報を求める。そして、送信者が変わった際の最初のＲＴＰパケットのＲＴＰパケットのＲＴＰ拡張ヘッダに、送信者名称を含めて配信する。

これによって、送信先端末Ｒで送信者の名称を表示することが可能となる。

配信を受けた送信先端末Ｒでは、ＲＴＰ拡張ヘッダを参照することにより、送信者の名称を知ることができ、この送信元端末Ｓ１の名称を送信先端末Ｒの表示部に表示することが可能となる。

本変形例では、端末名称情報や送信者名称情報を送信先端末Ｒにて表示することができるのみならず、通信データ量の増加を最低限に抑え、必要音声通信帯域に与える影響を抑えることができる。その理由は、端末名称情報や送信者名称情報といった名称情報を、送信者が変わった際の最初のＲＴＰパケットに限定してＲＴＰパケットのＲＴＰ拡張ヘッダ含めて配信するからである。

［第３の変形例］
次に、上述した実施形態を変形した例の１つである、第３の変形例について説明する。本変形例は、第１の変形例同様に、ＲＴＰ拡張ヘッダを使用するものであり、具体的にはＲＴＰ拡張ヘッダに、送信元端末Ｓ１の位置情報を格納する。位置情報は、送信元端末Ｓ１の位置を特定するための情報であれば良く、特に制限はないが、例えばＧＰＳ（Global Positioning System）により測位された座標を表す情報を位置情報として使用することができる。

まず、送信元端末Ｓ１がプッシュオン操作を受け付けると、送信者が変わって送信元端末Ｓ１が最初に送信するＲＴＰパケットのＲＴＰ拡張ヘッダに送信元端末Ｓ１の位置情報（例えば、ＧＰＳ情報等）を含めて、配信装置Ｅ１に対して送信する。

ＲＴＰ拡張ヘッダ制御部Ｍ８−４は、送信元端末Ｓ１から受信したＲＴＰパケットに含まれる位置情報を抽出し、外部のサーバに通知したりする。これによって、外部サーバに送信元端末Ｓ１の位置（すなわち、送信者の位置）をログとして残したり、地図検索表示システムなどと連携して、送信元端末Ｓ１の位置（すなわち、送信者の位置）を地図上に表示したりするといった応用が可能となる。

また、ＲＴＰパケット複製部Ｍ５が、位置情報を含めたままＲＴＰパケットを複製して配信することにより、受信端末Ｒに送信元端末Ｓ１の位置（すなわち、送信者の位置）を知らせるようにしても良い。これによって、受信端末のディスプレイに送信者の位置を表示したりするといった応用が可能となる。

なお、送信する全てのＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末Ｓ１の位置情報（例えば、ＧＰＳ情報等）を付加して配信装置Ｅ１に通知するようにしても良い。しかし、必ずしも全てのＲＴＰパケットのＲＴＰ拡張ヘッダに位置情報（例えば、ＧＰＳ情報等）を付加する必要はない。

例えば位置情報（例えば、ＧＰＳ情報等）を付加するのは、送信元端末Ｓ１が送信権取得操作を行う毎に最初のＲＴＰパケットのみに限定しても良い。他にも、送信元端末Ｓ１が送信権を得ている状態で予め設定した一定周期のタイミングに限定しても良い。他にも、送信元端末Ｓ１が送信権を得ている状態で、端末の位置が予め設定した距離以上を移動する毎のタイミングに限定しても良い。他にも、送信元端末Ｓ１が送信権を得ている状態で、ユーザから位置情報送信操作を受け付けたタイミングに限定しても良い。

このように、位置情報（例えば、ＧＰＳ情報等）を付加するＲＴＰパケットを限定することによって、通信データ量の増加を最低限に抑え、必要音声通信帯域に与える影響を抑えることが可能となる。

［第４の変形例］
次に、上述した実施形態を変形した例の１つである、第４の変形例について説明する。

本変形例では、ＲＴＰ拡張ヘッダに載せていた送信元端末Ｓ１が所属又は選択したグループの情報を、ＵＤＰの宛先ポート番号及び送信元ポート番号の一方又は他方に置き換えて、送信元端末Ｓ１がＲＴＰパケットを生成する。そして、生成したＲＴＰパケットを、送信元端末Ｓ１が配信装置Ｅ１に対して送信する。

そして、配信装置Ｅ１のＵＤＰヘッダ制御部Ｍ８−２は、受信したＲＴＰパケットのＵＤＰの宛先ポート番号又は送信元ポート番号から送信元端末Ｓ１が所属又は選択したグループ番号を識別する。

また、このような構成にするのではなく、以下のような構成にしても良い。

送信元端末Ｓ１が、送信元端末Ｓ１が所属又は選択したグループの情報を、例えばＲＴＰ拡張ヘッダに載せてＲＴＰパケットを生成する。そして、生成したＲＴＰパケットを、送信元端末Ｓ１が配信装置Ｅ１に対して送信する。

そして、配信装置Ｅ１のＵＤＰヘッダ制御部Ｍ８−２は、受信したグループの情報を、ＲＴＰパケットのＵＤＰの宛先ポート番号及び送信元ポート番号の一方又は他方に置き換える。

送信元端末Ｓ１が所属又は選択したグループの情報によって、ＲＴＰパケットのＵＤＰの宛先ポート番号及び送信元ポート番号の一方又は他方を分ける。これにより、複数グループのＲＴＰパケットを同一の受信端末に複数送ることができるから、受信端末側が複数グループの受話の同時再生に対応するような応用を実現することができる。

以上説明した実施形態及び各変形例をそれぞれ組み合わせるようにしても良い。例えば、変形例１のＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）フィールドに、送信元端末Ｓ１を一意に識別するためのＩＤを格納するという構成と、変形例３の送信元端末Ｓ１の位置情報を格納するという構成の双方を組み合わせるようにしても良い。

次に、上述した実施形態及び各変形例を実現する場合の例である、実施例について説明する。

ここで、実際に上述した実施形態及び各変形例を実現する場合には、配信装置Ｅ１とは別に、グループ音声通信を制御（保守・端末の死活監視など）したり、端末を認証（端末の盗難・亡失対策を含む）したりするためのサーバが必要になるケースが多いと考えられる。この場合に、物理的に配信装置Ｅ１とサーバ装置の２つの装置を必ずしも設ける必要はなく、物理的にサーバ装置を配信装置Ｅ１に含めることも可能である。また、サーバの仮想化技術を利用することにより、単一の装置にてサーバ装置と配信装置Ｅ１を実現することも可能である。

ただし、配信装置Ｅ１の処理能力向上、特に、同時配信端末数を多くするためには、サーバを配信装置とは物理的に分け、配信装置は配信制御に特化させる構成としたほうが有利なケースが多いと考えられる。そして、ローカルエリアネットワークＮ１にこのようなサーバを配置し、配信装置Ｅ１と接続する。

また、サーバを用途に応じて複数設置することも考えられる。このようにサーバ群を設置する場合の配置例としては、保守者がデータを登録する用途のサーバは信頼性の高いローカルエリアネットワークＮ１側に配置し、端末と直接通信が必要な認証サーバ等は不正なアクセスを防止するためにＤＭＺ（DeMilitarized Zone）に配置することなどが考えられる。

ただ、サーバ装置と配信装置Ｅ１を具体的にどのような装置にて実現するのかは、本実施例の要旨ではない。そこで、本実施例では、サーバ装置を制御サーバＥ２として、配信装置Ｅ１とは、別途の装置として実現する場合についてのみ説明し、これら装置の他の実現例や、設置場所については説明を省略する。

なお、以下では、図８乃至１０を参照して説明する。ここで、図８は、携帯端末がプッシュオン操作を受け付けた際の動作を表すシーケンス図である。また、図９は、ＲＴＰパケットが、長時間未達時の動作を表すシーケンスである。更に、図１０は、携帯端末がプッシュオフ操作を受け付けた際の動作を表すシーケンス図である。

ここで、図８乃至１０に表されるように、本実施例は、第１の端末Ｔ１乃至第ｎの端末Ｔｎ、配信装置Ｅ１及び制御サーバＥ２を含む。

第１の端末Ｔ１乃至第ｎの端末Ｔｎは、近年急激に普及しているスマートフォンで実現すること、あるいは、スマートフォンのＯＳ（Operating System）上に搭載する専用アプリケーションで実現することを想定する。

なお、これらの図に表される制御サーバＥ２は、端末情報、ユーザ情報及びグループ所属端末群情報の管理更新をする。そして、制御サーバＥ２は、配信装置Ｅ１に更新したデータを通知する、という役割も果たす。これにより、配信装置Ｅ１が記憶する端末情報、ユーザ情報及びグループ所属端末群情報は最新の状態に保たれる。

また他にも、制御サーバＥ２は、各携帯端末の死活情報を監視及び管理する役割や、各携帯端末の位置情報を管理する役割などを持つものとする。

まず、図８を参照して端末がプッシュオフ操作を受け付けた場合の、各機器の動作について説明する。

制御サーバＥ２は、所定の周期で第１の端末Ｔ１〜第ｎの端末Ｔｎの死活監視を行なう（Ａ１０１）。死活監視は、任意の方法で行なうことができるが、例えばＩＣＭＰ（Internet Control Message Protocol）に準拠したｐｉｎｇにより行なう。

具体的には、制御サーバＥ２は、監視対象とする、第１の端末Ｔ１乃至第ｎの端末Ｔｎに対して「ｅｃｈｏ ｒｅｑｕｅｓｔ」パケットを送信する。第１の端末Ｔ１〜第ｎの端末Ｔｎは、「ｅｃｈｏ ｒｅｑｕｅｓｔ」パケットを受信すると、これの返信として「ｅｃｈｏ ｒｅｐｌｙ」を制御サーバＥ２に対して送信する。制御サーバＥ２は、「ｅｃｈｏ ｒｅｐｌｙ」が返信されてきた端末については、通信可能な状態にあると判断し、「ｅｃｈｏ ｒｅｐｌｙ」が返信されてこなかった端末については、通信不可能な状態にあると判断する。死活監視の結果は、配信装置Ｅ１に送信される。配信装置Ｅ１は、受信した死活監視の結果に応じて端末情報テーブル内の死活監視の項目を更新する。

次に、第１の端末Ｔ１乃至第ｎの端末Ｔｎの何れかがユーザからプッシュオン操作を受け付ける。今回は、第１の端末Ｔ１が、ユーザからのプッシュオン操作を受け付けたと想定する。第１の端末Ｔ１は、ユーザからのプッシュオン操作を受け付けると、ＲＴＰパケットを配信装置Ｅ１に対して通知する（Ａ１０２）。

ＲＴＰパケットを受信した端末は、配信装置Ｅ１は、これまでに説明したように、送信元端末、送信元端末の所属するグループ又は送信元端末のユーザが選択したグループを識別することより配信対象とするグループを特定する。そして、配信装置Ｅ１は、配信対象とするグループ内の各端末の死活状態を把握するため、グループ所属端末群情報記憶部Ｄ１を参照して、各端末についての死活監視情報（図中では「アクティブ端末情報」と表現）を取得する（Ａ１０３）。

また、配信装置Ｅ１は、グループ所属端末群情報記憶部Ｄ１を参照して、配信対象とする端末が所属するグループのグループ所属端末群情報や送信権情報（図では「送話者情報」と表現）も取得する（Ａ１０４）。そして、配信装置Ｅ１は、これら取得した情報に基づいて、送信元端末である第１の端末Ｔ１に送信権を付与するか否かを判断する。

判断の結果、第１の端末Ｔ１に送信権を付与した場合、配信装置Ｅ１は、送話者を特定する情報である送話者情報を更新する（Ａ１０５）。また、配信装置Ｅ１は、第１の端末Ｔ１に送信権を付与した場合、制御サーバＥ２に対して、送信権を取得した端末の情報を送話開始情報として通知する（Ａ１０６）。ここで、送話開始情報には、例えば、送信権を取得した第１の端末Ｔ１のＩＰアドレスと端末ＩＤ、第１の端末Ｔ１のユーザのユーザＩＤ、第１の端末Ｔ１からの送信先となるグループのグループＩＤ、及び第１の端末Ｔ１の位置を表す位置情報が含まれる。

送話開始情報通知を受けとった、制御サーバＥ２は、送話開始情報の内容をログに残す。また、制御サーバＥ２は、制御サーバＥ２の管理者等が参照するために、送話開始情報の内容を含んだログを出力する（Ａ１０７）。なお、ログには送信端末の位置情報を含めても良い。

また、送話開始情報通知を受けとった、制御サーバＥ２は、送話開始情報の通知を受けとったことの応答として、送話開始情報応答を配信装置Ｅ１に返信する（Ａ１０８）。送話開始情報応答が、どの送話開始情報通知に関しての応答であるのかが分かるように、送話開始情報応答には送話開始情報通知に含まれている端末ＩＤ等の情報を含ませるようにすると良い。

そして、配信装置Ｅ１は、第１の端末Ｔ１から受信したＲＴＰパケットを複製し、複製されたＲＴＰパケットを、配信先となる各端末（第２の端末Ｔ２乃至第ｎの端末Ｔｎ）に対して配信する（Ａ１０９−１、Ａ１０９−２及びＡ１０９−３）。なお、複製に際して、ＩＰアドレスの書き換え等の加工が伴うことについては、実施形態の説明として上述した通りである。

また、複製されたＲＴＰパケットを受信した配信先の端末では、ＲＴＰパケットを参照することにより、送話者の情報を取得し、取得した送話者の情報を端末の表示部に表示することが可能となる。また、併せて、配信先の端末は現在送信権を取得していないことも端末の表示部に表示することが可能となる。更に、複製されたＲＴＰパケットを送信元端末（第１の端末Ｔ１）に送信することにより、送信元端末の表示部に、現在送信元端末が送信権を取得していることや、送話者が自端末であることを表示することが可能となる。

次に、図８の動作を行って、送信権を得て配信元端末となった第１の端末Ｔ１からのＲＴＰパケットの配信が途切れた場合の動作について説明する。

ここで、第１の端末Ｔ１からのＲＴＰパケットの送信が何らかの理由で途切れる理由としては、いくつかの場合が考えられる。例えば、第１の端末Ｔ１がプッシュオフ操作を受け付けた場合や、第１の端末Ｔ１が無線圏外へ移動した場合や、第１の端末Ｔ１がバッテリ切れとなった場合である。

まず、前提として制御サーバＥ２は、第１の端末Ｔ１〜第ｎの端末Ｔｎの死活監視を行なう（Ａ１１１）。これについては、図８を参照して説明しているので、ここでは説明を省略する。

次に、上述したような何らかの理由により、第１の端末Ｔ１からのＲＴＰパケットの送信が途切れる（Ａ１１２）。

ここで、配信装置Ｅ１は、送信権を得た第１の端末Ｔ１からのＲＴＰパケットが一定時間途切れるか否かを監視する。ここで、一定時間は、想定されるネットワーク遅延等の環境に応じて任意に定めることが可能であるが、例えば、１０秒とする。そして、第１の端末Ｔ１からのＲＴＰパケットが一定時間途切れた場合には、第１の端末Ｔ１の送信権の強制解除を行なう（Ａ１１３）。

また、配信先の各端末に第１の端末Ｔ１の送信権の強制解除が行われた旨を配信するために、図８を参照して説明したＡ１０３と同様に、グループ所属端末群情報記憶部Ｄ１を参照して、アクティブ端末情報を取得する（Ａ１１４）。また、グループ所属端末群情報記憶部Ｄ１に格納されている送話者情報を書き換えることによって、第１の端末Ｔ１から送信権を剥奪し、第１の端末Ｔ１が所属しているグループで送信権を得ている端末がいない状態とする（Ａ１１５）。つまり送信権を開放する。

また、配信装置Ｅ１は、第１の端末Ｔ１から送信権を剥奪した場合、制御サーバＥ２に対して、送信権を剥奪した端末の情報を送話終了情報として通知する（Ａ１１６）。ここで、送話終了情報には、送話開始情報と同じように、第１の端末Ｔ１の端末ＩＤ等を含ませる。

送話終了情報通知を受けとった、制御サーバＥ２は、送話終了情報の内容をログに残す。また、制御サーバＥ２は、制御サーバＥ２の管理者等が参照するために、送話終了情報の内容を含んだログを出力する（Ａ１１７）。なお、ログには送信端末の位置情報を含めても良い。

また、送話終了情報通知を受けとった、制御サーバＥ２は、送話終了情報の通知を受けとったことの応答として、送話終了情報応答を配信装置Ｅ１に返信する（Ａ１１８）。送話終了情報応答が、どの送話終了情報通知に関しての応答であるのかが分かるように、送話終了情報応答には送話終了情報通知に含まれている端末ＩＤ等の情報を含ませるようにすると良い。

その後、各端末も送信権の強制解除を行なうが、これは、送信権の強制解除が行われた旨を配信装置Ｅ１が配信することにより行なわれても良いが、各端末が判断をすることにより行われても良い。

まず前者の場合について説明する。制御サーバＥ２は、第１の端末Ｔ１の送信権の強制解除が行われた旨を、配信先端末であった各端末（第２の端末Ｔ２乃至第ｎの端末Ｔｎ）及び送信元端末であった第１の端末Ｔ１に対して通知する（Ａ１１９−１、Ａ１１９−２及びＡ１１９−３）。かかる通知を受けた各端末は、送話者がいなくなった旨を端末の表示部に表示することが可能となる。また、第１の端末Ｔ１は、自端末が送信権を未取得の状態となったことを表示することが可能となる。

次に後者の場合について説明する。上述したように、Ａ１１９−１、Ａ１１９−２及びＡ１１９−３において、第１の端末Ｔ１の送信権の強制解除が行われた旨を送信するという処理を行わないようにしても良い。そして、各端末が、第１の端末Ｔ１の送信権の強制解除が行われたか否かを判定するようにしても良い。

つまり、配信先端末であった各端末（第２の端末Ｔ２乃至第ｎの端末Ｔｎ）の、それぞれが、送信権を得た第１の端末Ｔ１から送信され、配信装置Ｅ１により配信されるＲＴＰパケットが一定時間途切れるか否かを監視する。そして、ＲＴＰパケットが一定時間途切れた場合には、第１の端末Ｔ１の送信権の強制解除が行われたと判断しても良い。これにより、各端末は、送話者がいなくなった旨を端末の表示部に表示することが可能となる。

また、更に第１の端末Ｔ１は、受信したＲＴＰに含まれる端末ＩＤが、第１の端末Ｔ１自身の端末ＩＤでなくなった場合に、送信権の強制解除が行われたと判断しても良い。これによっても、第１の端末Ｔ１、送話者がいなくなった旨を端末の表示部に表示することが可能となる。

なお、第１の端末Ｔ１がＲＴＰパケットを送信していても、特権者が送信権を強制的に取得したような場合にも、受信したＲＴＰに含まれる端末ＩＤが、第１の端末Ｔ１自身の端末ＩＤでなくなる。第１の端末Ｔ１はこのような場合にも、送信権の強制解除が行われたと判断すると良い。

以上説明した動作により、送信元端末である第１の端末Ｔ１から配信装置へのＲＴＰパケットや、配信装置Ｅ１から配信先端末へのＲＴＰパケットが一定時間途絶えた場合、配信装置Ｅ１や、各端末は送信権の解放を行う。

なお、ＲＴＰパケットが一定時間途絶えてから送信権を解放すると判断するまでの時間を長くしてしまうと、送信元端末が送信権を持ったまま、無線圏外へ移動した場合やバッテリ切れとなった場合に、送信権を解放するまでの時間が長くなってしまう。そのため、他の端末が送信権を得るまでの時間も長くなってしまう。しかしながら、第１の変形例として説明したように、ＲＴＰパケットのＲＴＰ拡張ヘッダに特権者情報を含めることにより、ＲＴＰパケットが一定時間途絶える前であっても、特権者の端末が送信権を得ることができる。従って、他の端末が送信権を得るまでの時間も長くなってしまう、という問題を解決することができる。

次に、図８の動作を行って配信元端末となった第１の端末Ｔ１がプッシュオフ操作を受け付けた場合であって、ＲＴＰパケットのＲＴＰ拡張ヘッダに送話終了フラグを含める場合について図１０を参照して説明する。送話終了フラグは第１の変形例の説明時に述べたように送信権解放要求を明示的に通知するためのものである。

まず、制御サーバＥ２は、第１の端末Ｔ１〜第ｎの端末Ｔｎの死活監視を行なう（Ａ１３１）。これについては、図８を参照して説明しているので、ここでは説明を省略する。

次に、現在配信元端末である第１の端末Ｔ１がプッシュオフ操作を受け付ける。すると、第１の端末Ｔ１は、プッシュオフ操作を受け付けたタイミングで送信するＲＴＰパケットのＲＴＰ拡張ヘッダに、送話終了を意味する送話終了フラグを載せる。そして、第１の端末Ｔ１によるＲＴＰパケットの送信が止まる。

ここで、図９を参照して説明した動作では、ＲＴＰパケットの送信が止まってから、一定期間の監視を行ってから送信権の開放を行っていた。しかし、本例では、一定期間の経過を待つ必要はない。配信装置Ｅ１は、受信したＲＴＰパケットに含まれる送話終了フラグを確認すると、一定期間の経過を待つことなく送信権の開放を速やかに行なう。

そのために、配信装置Ｅ１は、送話終了フラグを含んだＲＴＰパケットを各端末装置に対して送信する。まず、配信装置Ｅ１は、送話終了フラグを含んだＲＴＰパケットを配信するために、図８を参照して説明したＡ１０３と同様に、グループ所属端末群情報記憶部Ｄ１を参照して、アクティブ端末情報を取得する（Ａ１３３）。また、グループ所属端末群情報記憶部Ｄ１に格納されている送話者情報を書き換えることによって、第１の端末Ｔ１から送信権を剥奪し、第１の端末Ｔ１が所属しているグループで送信権を得ている端末がいない状態とする（Ａ１３４）。つまり送信権を開放する。

また、配信装置Ｅ１は、第１の端末Ｔ１から送信権を剥奪し場合、制御サーバＥ２に対して、送信権を剥奪し端末の情報を送話終了情報として通知する（Ａ１３５）。ここで、送話終了情報には、送話開始情報と同じように、第１の端末Ｔ１の端末ＩＤ等を含ませる。

送話終了情報通知を受けとった、制御サーバＥ２は、送話終了情報の内容をログに残す。また、制御サーバＥ２は、制御サーバＥ２の管理者等が参照するために、送話終了情報の内容を含んだログを出力する（Ａ１３６）。なお、ログには送信端末の位置情報を含めても良い。

また、送話終了情報通知を受けとった、制御サーバＥ２は、送話終了情報の通知を受けとったことの応答として、送話終了情報応答を配信装置Ｅ１に返信する（Ａ１３７）。送話終了情報応答が、どの送話終了情報通知に関しての応答であるのかが分かるように、送話終了情報応答には送話終了情報通知に含まれている端末ＩＤ等の情報を含ませるようにすると良い。

その後、制御サーバＥ２は、送話終了フラグを含んだＲＴＰパケットを、配信先端末であった各端末（第２の端末Ｔ２乃至第ｎの端末Ｔｎ）及び送信元端末であった第１の端末Ｔ１に対して配信する（Ａ１１９−１、Ａ１１９−２及びＡ１１９−３）。かかる送話終了フラグを含んだＲＴＰパケットを受信した各端末は、送話終了フラグを参照することにより、送話者がいなくなったことを把握できる。そして、その旨を端末の表示部に表示することが可能となる。また、第１の端末Ｔ１は、自端末が送信権を未取得の状態となったことを表示することが可能となる。

以上説明したように、ＲＴＰパケットに送話終了フラグを含めれば、一定時間の経過を待つ必要がなくなり、即座に送信権の開放を行なうことができる。これに伴い、配信先端末の表示を、送信権未取得及び送話者なしの表示に変更することが瞬時にできるようになる。また、制御サーバＥ２に送信権を解放した端末の情報を通知し、制御サーバはこれをログに残すことも瞬時にできる。

以上説明した本発明の実施形態及び各変形例は、以下に示すような多くの効果を奏する。

第１の効果は、ＰｏＣグループ一斉音声通信で、大規模かつ広域で提供したりする用途に適用できることである。

ここで、大規模とは、現在通信事業者が提供しているサービスを利用した場合であれば、例えば、端末にＬＴＥ（Long Term Evolution）に対応したスマートフォンを利用する状況を想定する。また、端末と配信装置間の回線は、バックボーンにＮＧＮ（Next Generation Network）を持つ高品質、高信頼の広域イーサネットサービスを利用して１Ｇｂｉｔ／ｓ程度の帯域を確保した状況を想定する。そして、大規模とは、このような状況において、グループ内端末同時通信数を、１０，０００端末程度までの規模に対応できる効果が期待できることを意味する。

このような第１の効果を奏する理由は、配信装置のＲＴＰパケット複製部を、ＲＴＰパケットのペイロードの複製及びヘッダの加工のみを行なう、シンプルな構成としたことで、配信装置の必要なパケット複製能力（単位時間当たりの複製数）を確保することができるからである。ここで、シンプルな構成とは、複雑なソフトウェアロジックを必要とせず、ハードウェア、又は、ＯＳレスレベルのソフトウェアの制御で実現可能なレベルの制御を指す。

また、第１の効果を奏する更なる理由は、ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）フィールドに、送信元端末ＩＤを含めるからである。又は、ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末ＩＤ・グループＩＤ・端末ＩＤ・特権者情報などのＰｏＣグループ一斉音声通信を制御するための情報を付加して送受信するからである。そしてこのようにすることにより、ＰｏＣグループ一斉音声通信を制御するための必要最低限の情報を、送信元端末から配信装置との間、配信装置から受信端末との間で、ＲＴＰパケットのみで送受信することが可能となるからである。そして、結果として、別の制御パケットで送受信する必要がなくなり、必要パケット数を減らすことで必要帯域を削減できるからである。

また、第２の効果は、ＰｏＣグループ一斉音声通信で、プッシュオン操作を行って送信権を取得し、送話を開始できるようになるまでの送話者切り替え時間を短縮できることである。そして、結果として、通話の頭切れを防止できることである。

このような第２の効果を奏する理由は、ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）フィールド、又は、ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末ＩＤを含めることで、送信権制御用の別のパケットの送受信が不要となるからである。そしてこれにより、送信権制御用のパケットの到達遅延や処理遅延によって、送話者切り替えタイミングが遅れることがなくなるからである。

また、第２の効果を奏する更なる音声情報を含んだＲＴＰパケットが到達した時点で、送信元ＩＤが識別できるので、送信元端末の所属グループＩＤを識別することができ、所属グループＩＤから配信すべき受信端末群の情報を求めることや送信権取得制御を行なうことができるからである。

また、第２の効果を奏する更なるＲＴＰパケットのＲＴＰ拡張ヘッダに、グループＩＤなどのＰｏＣグループ一斉音声通信を制御するための情報を付加して送受信することで、送信元端末の所属グループＩＤの識別にかかる処理時間を更に短縮することができるからである。ここで、送信元端末の所属グループＩＤの識別にかかる処理時間とは、送信元端末ＩＤをキーに送信元端末の所属又は選択グループＩＤのデータベース検索にかかる処理時間等のことである。

更に、第３の効果は、ＰｏＣグループ一斉音声通信で、送信端末のバッテリ切れや無線通信圏外への移動、送信者の送信終了操作忘れ時の対策が強化されることである。この効果は、同時片方向通信が前提のグループ一斉音声通信の、「送信端末が送信中に、受信端末は送信端末に対して音声で連絡できない」というデメリットを補うメリットも併せ持つ。

このような第３の効果を奏する理由は、ＲＴＰパケットのＲＴＰ拡張ヘッダに、特権者情報を含めたことで、送信権制御用の別のパケットの送受信が不要となるからである。また、先の送信端末が送信権を取得したままバッテリ切れや無線通信圏外への移動、送信者の送信終了操作忘れ時で、送信権を保有したままの状態になったときに、特権者の権限を持つ後の送信端末が強制的に送信権を得ることができるからである。

更に、第４の効果は、ＰｏＣグループ一斉音声通信で、提供できるサービス機能を拡張することができることである。

このような第４の効果を奏する理由について説明する。

仮に、一般的な技術によって送信者の情報を受信端末にリアルタイムに表示しようとすると、音声パケットとは別の制御パケットを用いて、グループに含まれる端末の一覧情報をサーバから端末にダウンロードしておいたり、一斉配信したりする必要がある。そのため、一般的な技術では、制御パケットの必要帯域や、端末情報を管理しているサーバの処理負荷等の物理的制約で、実際には実現が困難である。また、他の一般的な技術として、サーバから受信端末にダウンロードしておくことも考えられる。しかし、このような方法では、端末側からのダウンロード要求が送られてくるタイミングが、多くの複数端末から集中する可能性がある。そのため、必要となるサーバの処理能力やネットワーク帯域の算出や制御が困難になるという問題点もある。

しかしながら、本発明の実施形態では、配信装置が送信する、送信者が変わった際の最初に配信するＲＴＰパケットのＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末名称又は送信端末のユーザ名称等を含める。そして、本発明の実施形態では、こうすることによって、送信先端末で送信元端末の端末名称やユーザ名称を表示することが可能となり、送信者がいちいち音声で名乗らなくても、受信者が送信者を認識することができる。このようにして、本発明の実施形態では、上記の第４の効果を奏することができる。

なお、上記の配信システムに含まれる、配信装置、各端末及び制御サーバの各々は、それぞれ、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。また、上記の配信システムに含まれる、配信装置、各端末及び制御サーバの各々より行なわれる配信方法も、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory）)を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１） 配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、
前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信することを特徴とする配信装置。

（付記２） 各端末それぞれの第２のプロトコルに準拠したアドレスと前記識別情報とを紐付けておき、前記パケットを受信したときに、該パケットに含まれている前記識別情報と前記紐付けられている前記アドレスを前記配信先の端末のアドレスとして取得することを特徴とする付記１に記載の配信装置。

（付記３） 前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを、配信の対象とすることを特徴とする付記１又は２に記載の配信装置。

（付記４） 何れかの端末を特権者端末として扱い、前記特権者端末が送信したパケットを受信したならば、前記送信権を付与した端末から前記送信権を剥奪し、該剥奪した送信権を前記特権者端末に付与することによって、前記特権者端末が送信したパケットを配信の対象とすることを特徴とする付記３に記載の配信装置。

（付記５） 端末がパケットを受信可能な状態に有るか否かを所定の周期で監視し、該監視の結果に基づいて、配信先の端末群に含まれる端末であってパケットを受信可能な状態にある端末を、パケットを配信する対象とすることを特徴とする付記１乃至４の何れか１に記載の配信装置。

（付記６） 前記第１のプロトコルとはＲＴＰ（Real-time Transport Protocol）であり、前記識別情報は、ＲＴＰペイロードではなく、ＲＴＰヘッダのＳＳＲＣ（Synchrozination Source）フィールド又はＲＴＰ拡張ヘッダに格納されることを特徴とする付記１乃至５の何れか１に記載の配信装置。

（付記７） 前記第２のプロトコルとは、ＩＰ（Internet Protocol）であり、前記受信したパケットを複製するときに、パケットの送信元ＩＰアドレスをパケットの送信元の端末のＩＰアドレスから自配信装置のＩＰアドレスに書き換え、更に、パケットの宛先ＩＰアドレスを、自配信装置のＩＰアドレスから配信先の端末のＩＰアドレスに書き換えることを特徴とする付記１乃至６の何れか１に記載の配信装置。

（付記８） 付記１乃至７の何れか１に記載の配信装置と、端末とを含む配信システムであって、
前記配信装置は、前記複製したパケットに、パケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報何れか又は双方を含ませ、
前記配信装置からパケットを配信された端末は、パケットに含まれているパケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報の何れか又は双方を出力する
ことを特徴とする配信システム。

（付記９） 付記１乃至７の何れか１に記載の配信装置と、端末とを含む配信システムであって、
前記配信装置は、前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを配信の対象とし、
前記送信権を付与された端末は、ユーザの操作に基づいて、送信権開放要求をパケットに含ませて前記配信装置に送信し、
前記配信装置及び前記配信装置からパケットの配信を受けた端末は、前記パケットに前記送信権開放要求が含まれている場合に、前記送信権を付与された端末の送信権を剥奪することを特徴とする配信システム。

（付記１０） 配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、
前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信する配信装置としてコンピュータを機能させることを特徴とする配信プログラム。

（付記１１） 任意の送信元端末からのＲＴＰパケットを受信するＲＴＰパケット受信手段と、
グループに所属する端末群がどれかを識別するための情報を記憶するグループ所属端末群情報記憶手段と、
受信したＲＴＰパケットを一時的に記憶するＲＴＰパケット記憶手段と、
当該ＲＴＰパケットを送信してきた送信元端末に送信権を与えてよいかを判断する送信権取得制御手段と、
当該送信元端末に送信権を与えた場合に、受信したＲＴＰパケットをグループ所属端末群情報に従って、当該グループに所属するそれぞれの送信先端末に向けたパケットに複製するＲＴＰパケット複製手段と、
ＲＴＰパケット複製手段がＲＴＰパケットを複製する際に、ＩＰヘッダの送信元ＩＰアドレスを自装置のＩＰアドレスに、ＩＰヘッダの宛先ＩＰアドレスを各送信先端末のＩＰアドレスに書き換えるＩＰヘッダ制御手段と、
ＲＴＰパケット複製手段が複製したＲＴＰパケットを一時的に記憶する送信ＲＴＰパケット記憶手段と、
送信ＲＴＰパケット記憶手段が記憶しているＲＴＰパケットを各送信先端末に送信するＲＴＰパケット送信手段を具備する配信装置。

（付記１２） グループ所属端末群情報に加えて、各端末の死活情報も加味してＲＴＰパケットを送信すべき端末群を識別するＲＴＰパケット複製手段を具備する、付記１１記載の配信装置。

（付記１３） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末が送話終了操作を行ったことを示す、送話終了フラグを付加して配信装置に通知する送信元端末と、受信したＲＴＰパケットのＲＴＰ拡張ヘッダに含まれた送話終了フラグを元に送信元端末ＩＤを認識するＲＴＰ拡張ヘッダ制御手段と、送話終了を検知すると、ＲＴＰパケットの配信を終了するＲＴＰパケット複製手段を具備する、付記１１又は１２記載の配信装置。

（付記１４） ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）情報に、送信元端末を一意に識別するための送信元端末ＩＤを付加して配信装置に通知する送信元端末と、当該送信元端末ＩＤをキーに送信元端末に送信権を与えてよいかを判断する送信権取得制御手段を具備する、付記１１乃至１３記載の配信装置。

（付記１５） ＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）情報に、送信元端末を一意に識別するための送信元端末ＩＤを付加して配信装置に通知する送信元端末と、受信したＲＴＰパケットのＳＳＲＣ（送信元ＩＤ）情報を元に送信元端末ＩＤを認識するＲＴＰヘッダ制御手段と、当該送信元端末ＩＤをキーに送信先端末グループを求める送信元端末ＩＤ制御手段を具備する、付記１１乃至１４記載の配信装置。

（付記１６） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末を一意に識別するための送信元端末ＩＤを付加して配信装置に通知する送信元端末と、受信したＲＴＰパケットのＲＴＰ拡張ヘッダに含まれた送信元端末ＩＤ情報を元に送信元端末ＩＤを認識するＲＴＰ拡張ヘッダ制御手段と、当該送信元端末ＩＤをキーに送信先端末グループを求める送信元端末ＩＤ制御手段を具備する、付記１１乃至１５記載の配信装置。

（付記１７） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末が所属又は選択したグループを識別するためのグループＩＤの情報を付加して配信装置に通知する送信元端末と、受信したＲＴＰパケットのＲＴＰ拡張ヘッダに含まれたグループＩＤ情報を元に送信元端末ＩＤを認識するＲＴＰ拡張ヘッダ制御手段と、当該グループＩＤをキーに送信先端末グループを求めるＲＴＰ拡張ヘッダ制御手段を具備する、付記１１乃至１６記載の配信装置。

（付記１８） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末の特権者情報を付加して配信装置に通知する送信元端末と、受信したＲＴＰパケットのＲＴＰ拡張ヘッダに含まれた特権者情報を元に特権者かどうかを認識するＲＴＰ拡張ヘッダ制御手段と、特権者として通知された場合に、他の端末が送信権を有している場合でも、強制的に特権者の送信元端末に送信権を与える送信権取得制御手段を具備する、付記１１乃至１７記載の配信装置。

（付記１９） ＲＴＰパケット複製手段がＲＴＰパケットを複製する際に、送信元端末の情報をキーに、予め設定しておいた端末ＩＤに関連付けた端末名称情報から送信元端末名称情報を求め、送信者が変わった際の最初のＲＴＰパケットのＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末名称を含めるＲＴＰ拡張ヘッダ制御手段を具備し、送信先端末で送信元端末の名称を表示することが可能なようにした、付記１１乃至１８記載の配信装置。

（付記２０） 送信元端末を使用する際に、送信元端末に使用者を一意に識別することが可能なユーザＩＤを登録するようにしておいて、ＲＴＰパケットのＲＴＰ拡張ヘッダに、当該ユーザＩＤの情報を付加して配信装置に通知する送信元端末と、ＲＴＰパケット複製手段がＲＴＰパケットを複製する際に、ユーザＩＤの情報をキーに、予め設定しておいたユーザ端末ＩＤに関連付けたユーザ名称情報から送信元端末の使用者のユーザ名称（送信者名称）情報を求め、送信者が変わった際の最初のＲＴＰパケットのＲＴＰパケットのＲＴＰ拡張ヘッダに送信者名称を含めるＲＴＰ拡張ヘッダ制御手段を具備し、送信先端末で送信者の名称を表示することが可能なようにした、付記１１乃至１９記載の配信装置。

（付記２１） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末の位置情報（ＧＰＳ情報等）を付加して配信装置に通知する送信元端末と、受信したＲＴＰパケットのＲＴＰ拡張ヘッダに含まれた位置情報を元に送信元端末の位置情報を認識するＲＴＰ拡張ヘッダ制御手段を具備する、付記１１乃至２０記載の配信装置。

（付記２２） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末の位置情報（ＧＰＳ情報等）を付加して配信装置に通知するのは、送信元端末が送信権取得操作を行う毎に最初のＲＴＰパケットのみに限定した付記２１記載の配信装置。

（付記２３） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末の位置情報（ＧＰＳ情報等）を付加して配信装置に通知するのは、送信元端末が送信権を得ている状態で、予め設定した一定周期のタイミングに限定した付記２１乃至２２記載の配信装置。

（付記２４） ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末の位置情報（ＧＰＳ情報等）を付加して配信装置に通知するのは、送信元端末が送信権を得ている状態で、端末の位置があらかじめ設定した距離以上を移動する毎のタイミングに限定した付記２１乃至２３記載の配信装置。

（付記２５）ＲＴＰパケットのＲＴＰ拡張ヘッダに、送信元端末の位置情報（ＧＰＳ情報等）を付加して配信装置に通知するのは、送信元端末が送信権を得ている状態で、位置情報送信操作を行ったタイミングに限定した付記２１乃至２４記載の配信装置。

（付記２６） 送信元端末が所属又は選択したグループの情報を、ＵＤＰの宛先ポート番号又は送信元ポート番号の片方又は両方に置き換えてＲＴＰパケットを送信する送信元端末と、受信したＲＴＰパケットのＵＤＰの宛先ポート番号から送信元端末が所属又は選択したグループ番号を識別することが可能なＵＤＰヘッダ制御手段を具備する、付記１１乃至２５記載の配信装置。

（付記２７） 送信元端末が所属又は選択したグループの情報を送信する送信元端末と、受信したグループの情報を、ＲＴＰパケットのＵＤＰの宛先ポート番号又は送信元ポート番号の片方又は両方に置き換えることが可能なＵＤＰヘッダ制御手段を具備する、付記１１乃至２６記載の配信装置。

（付記２８） 送信元端末又は送信先端末に、携帯電話、スマートフォン又はスマートフォン上に搭載するアプリケーションソフトを使用し、これらと組み合わせて動作する付記１乃至７記載の配信装置又は付記１１乃至２７記載の配信装置を利用したグループ一斉音声通信システム又はその制御方法。

（付記２９） 送信元端末又は送信先端末と配信装置との間の通信網に、通信事業者が提供する携帯電話用パケット通信網を使用し、又は更に専用線網と組み合わせて動作する付記２１記載の配信装置又は付記２８記載の配信装置を利用したグループ一斉音声通信システム又はその制御方法。

本発明は、グループ一斉通信を利用する場合であれば、その用途を問うこと無く、広く好適である。

例えば、防災、治安、消防などの、広域かつ大規模に指令、情報伝達することが求められる、グループ一斉音声通信に本発明を適用することが可能である。また、より小規模な、地域、工場等でも、自営の無線基地局を設置することなく、通信事業者が提供する携帯電話用パケット通信網を活用して、グループ一斉音声通信する用途にも本発明を適用することが可能である。

Ｅ１ 配信装置
Ｅ２ 制御サーバ
Ｔ１ 第１の端末
Ｔ２ 第２の端末
Ｔ３ 第３の端末
Ｔｎ 第ｎの端末
Ｎ１ ローカルエリアネットワーク
Ｎ２ 専用線網
Ｎ３ 事業者携帯電話用パケット通信網
Ｓ１ 第１の送信元端末
Ｒ１ 第１の送信先端末
Ｒ２ 第２の送信先端末
Ｒ３ 第３の送信先端末
Ｒｎ 第ｎの送信先端末
Ｍ１ ＲＴＰパケット受信部
Ｍ２ 受信ＲＴＰパケット記憶部
Ｍ３ 送信元端末ＩＤ制御部
Ｍ４ 送信権取得制御部
Ｍ５ ＲＴＰパケット複製部
Ｍ６ 送信ＲＴＰパケット記憶部
Ｍ７ ＲＴＰパケット送信部
Ｍ８−１ ＩＰヘッダ制御部
Ｍ８−２ ＵＤＰヘッダ制御部
Ｍ８−３ ＲＴＰヘッダ制御部
Ｍ８−４ ＲＴＰ拡張ヘッダ制御部
Ｄ１ グループ所属端末群情報記憶部

Claims (10)

1. 配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、
   前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信することを特徴とする配信装置。
2. 各端末それぞれの第２のプロトコルに準拠したアドレスと前記識別情報とを紐付けておき、前記パケットを受信したときに、該パケットに含まれている前記識別情報と前記紐付けられている前記アドレスを前記配信先の端末のアドレスとして取得することを特徴とする請求項１に記載の配信装置。
3. 前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを、配信の対象とすることを特徴とする請求項１又は２に記載の配信装置。
4. 何れかの端末を特権者端末として扱い、前記特権者端末が送信したパケットを受信したならば、前記送信権を付与した端末から前記送信権を剥奪し、該剥奪した送信権を前記特権者端末に付与することによって、前記特権者端末が送信したパケットを配信の対象とすることを特徴とする請求項３に記載の配信装置。
5. 端末がパケットを受信可能な状態に有るか否かを所定の周期で監視し、該監視の結果に基づいて、配信先の端末群に含まれる端末であってパケットを受信可能な状態にある端末を、パケットを配信する対象とすることを特徴とする請求項１乃至４の何れか１項に記載の配信装置。
6. 前記第１のプロトコルとはＲＴＰ（Real-time Transport Protocol）であり、前記識別情報は、ＲＴＰペイロードではなく、ＲＴＰヘッダのＳＳＲＣ（Synchrozination Source）フィールド又はＲＴＰ拡張ヘッダに格納されることを特徴とする請求項１乃至５の何れか１項に記載の配信装置。
7. 前記第２のプロトコルとは、ＩＰ（Internet Protocol）であり、前記受信したパケットを複製するときに、パケットの送信元ＩＰアドレスをパケットの送信元の端末のＩＰアドレスから自配信装置のＩＰアドレスに書き換え、更に、パケットの宛先ＩＰアドレスを、自配信装置のＩＰアドレスから配信先の端末のＩＰアドレスに書き換えることを特徴とする請求項１乃至６の何れか１項に記載の配信装置。
8. 請求項１乃至７の何れか１項に記載の配信装置と、端末とを含む配信システムであって、
   前記配信装置は、前記複製したパケットに、パケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報何れか又は双方を含ませ、
   前記配信装置からパケットを配信された端末は、パケットに含まれているパケットの送信元の端末を表す情報又はパケットの送信元の端末のユーザを表す情報の何れか又は双方を出力する
   ことを特徴とする配信システム。
9. 請求項１乃至７の何れか１項に記載の配信装置と、端末とを含む配信システムであって、
   前記配信装置は、前記配信先の端末群に含まれる各端末の何れにも送信権を付与していない場合に、前記パケットの送信元の端末に送信権を付与し、前記送信権を付与した端末が送信したパケットを配信の対象とし、
   前記送信権を付与された端末は、ユーザの操作に基づいて、送信権開放要求をパケットに含ませて前記配信装置に送信し、
   前記配信装置及び前記配信装置からパケットの配信を受けた端末は、前記パケットに前記送信権開放要求が含まれている場合に、前記送信権を付与された端末の送信権を剥奪することを特徴とする配信システム。
10. 配信先の端末群を特定するための識別情報を、第１のプロトコルに準拠したヘッダに格納したパケットを受信し、
    前記識別情報に基づいて、配信先の端末群に含まれる各端末それぞれの第２のプロトコルに準拠したアドレスを取得し、前記受信したパケットを複製し、該複製したパケットを、前記取得した各アドレス宛に送信する配信装置としてコンピュータを機能させることを特徴とする配信プログラム。

Images