JP4554295B2 - 端末、通話方法及び通話プログラム - Google Patents

Description

本発明は、ソフトスイッチ等の集中システム（中継交換機）を用いずに、複数のＩＰ電話端末等の端末間で通話ネットワークを構成して通話を行う端末、通話方法及び通話プログラムに関する。

従来、共有メモリ上に格納されたデータの整合性を保証するための技術が知られている。例えば、特許文献１には、複数の端末装置における処理の負荷の軽減を図りながら、各端末装置に格納されている共有情報の整合性を保持するデータ共有方法が開示されている。
この発明によれば、まずネットワークを介して相互に接続された複数の端末装置によってデータを共有するグループを構成する。
そして、グループ内で共有する基本データおよびグループ内の各端末装置に関するメンバーデータを含んだ共有データに対して更新が発生した場合、予め定められた所定の決定方法にしたがって、複数の端末装置の中から、更新に関する更新情報をグループ内の各端末装置に対して同報送信するいずれか一つの端末装置である同報送信端末装置を、各端末装置において決定する。

各端末装置は、この同報送信端末装置に更新情報を送信し、同報送信端末装置により、当該更新情報をメンバーデータに対応する端末装置に対して同報送信する。
ここで、各端末装置は、更新情報とともに、更新情報に対応する判別用番号を同報送信端末装置に送信する。一方、更新情報とともに、判別用番号を受信すると、同報送信端末装置は、受信する判別用番号よりも大きな判別用番号を新たな判別用番号とし、更新情報を同報送信する。ただし、このとき、同報送信端末装置は、受信した判別用番号と記憶している判別用番号とを比較し、受信した判別用番号の方が大きい場合に、同報送信する。
一方、各端末装置は、更新情報および新たな判別用番号を受信し、新たな判別用番号と記憶している判別用番号とを比較し、新たに受信した判別用番号が記憶している判別用番号よりも大きい場合、更新情報を共有データに更新する
したがって、各端末装置に格納されている共有情報の整合性を保持しつつ、各端末装置の処理負荷を軽減することができる。
特開２００１−３３１４６９号公報

一方、近年、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）を利用したＩＰ電話端末が普及しつつある。ＩＰ電話端末間のルーティング処理は、ソフトスイッチによって仲介される。
ソフトスイッチは、管理するＩＰ電話端末のＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＵＲＬ（アドレスデータベース）を保有し、各ＩＰ電話端末は、起動時にソフトスイッチにアクセスすることで、自ＩＰアドレスを登録する。
ＩＰアドレスの登録後、相手のＩＰ電話端末（着信側）をコールする場合、発信側のＩＰ電話端末は、ソフトスイッチにアクセスすることで相手のＩＰ電話端末のＩＰアドレスをＳＩＰ ＵＲＬから取得し、リクエストを送信する。
相手のＩＰ電話端末がこのリクエストに対して応答すると、それ以後は、ソフトスイッチを介さずに発呼側、着呼側のＩＰ電話端末間で直接データストリーミングを開始することで音声通話を実現する。
すなわち、ソフトスイッチにおいては、ＩＰ電話端末の起動／終了時のＳＩＰ ＵＲＬへのアドレス登録処理、通話の際のコネクション接続制御処理、転送電話の際の相手のＩＰ電話端末の応答状態監視処理等の処理が実施される。また、アドレス登録や端末監視処理については、各要求ごとにソフトウェアによる並列処理が実施される。

このように、現状ではＶｏＩＰを実現するにあたり、ソフトスイッチのような集中システムを採用している。なぜ集中システムを使用するかというと、通信サービスは発呼側のＩＰ電話端末と着呼側のＩＰ電話端末とが連動して制御される必要があるためである。
すなわち、集中システムは、発呼側及び着呼側のＩＰ電話端末の状態を管理し、これに連動した呼処理（相手が話中である場合はこの着信電話を転送する等）を発呼側及び着呼側のＩＰ電話端末において実現するためには不可欠なものとなっている。
しかし、集中システムにおいて、実現すべきサービスが高度化（会議電話、留守番電話、保留転送機能）すると、発呼側及び着呼側のＩＰ電話端末が連動して実行すべき呼処理の内容がより複雑になる。
すると、一つ一つのサービスを同時に集中して実現するためには、ソフトウェア構成が非常に複雑なものになってしまうという問題点がある。
すなわち、集中システムが一つのサービスを新たに実装するには、システム全体の大幅な性能劣化や運用上起こり得る問題などを引き起こし、開発から設備を含め多大なコストが発生する。このため、ネットワークの利用効率を上げることによるＩＰ電話端末１の低コストメリットよりも、開発コストや運用コストのデメリットが大きくなってしまうという問題点があった。

一方、既存の電話交換機等においては、この集中システムをサービス利用者数によって分割することで問題の解決を図っているが、この場合においては、新たに分割したシステム間の連動をどのようにして実現するかが問題となり、前述の問題を解決するには至っていない。

本発明は、このような事情を考慮してなされたものであり、その目的は、ソフトスイッチ等の集中システム（中継交換機）を用いずに、複数のＩＰ電話端末等の端末間で通話ネットワークを構成して通話を行うことができる端末、通信方法及び通信プログラムを提供することにある。

この発明は上記の課題を解決すべくなされてもので、本発明は、ネットワークを介して接続された通話先端末の第１の識別情報を入力して前記通話先端末と通話処理を実行する端末であって、自端末又は前記通話先端末を含む端末の第１の識別情報と、前記ネットワークに接続された前記端末を分割した複数のグループにおいて当該端末の属しているグループとの対応関係を示すテーブルが記憶された第１の記憶手段であって、前記自端末のグループに属する前記端末により共有される第１の記憶手段の前記テーブルに基づき、前記通話先端末の前記第１の識別情報により、当該通話先端末が参加しているグループを識別し、前記通話先端末が前記自端末とは異なるグループに参加している場合には、自端末を前記通話先端末が参加しているグループに参加させるグループ参加管理手段と、前記通話先端末の第１の識別情報、及び、前記通話先端末の状態を記憶する、前記グループに属する端末により共有される第２の記憶手段から読み込んだ前記通話先端末の状態に基づいて、前記通話先端末の第１の識別情報から変換された前記通話先端末の第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行する通話処理手段とを有することを特徴とする。

また、本発明は、前記通話処理手段は、前記第２の記憶手段に記憶された前記通話先端末の状態を通話準備状態に変更するとともに、前記第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行することを特徴とする。

また、本発明は、前記第２の記憶手段は、自端末の状態をさらに記憶し、前記通話処理手段は、所定の時点で前記自端末の状態を通話準備状態に変更することを特徴とする。

また、本発明は、前記第１または第２の記憶手段は、自端末、前記通話先端末、又は、前記ネットワークを介して接続された他の端末内のいずれかに共有記憶領域として構築されることを特徴とする。

また、本発明は、前記第１または第２の記憶手段は、自端末、前記通話先端末、又は、前記ネットワークを介して接続された他の端末内に分散された共有記憶領域として構築されることを特徴とする。

また、本発明は、前記通話処理手段は、さらに、前記通話先端末と自端末との間の通話処理の実行結果に基づいて、所定の転送先端末と自端末との間で通話処理を実行することを特徴とする。

また、本発明は、前記通話処理手段は、さらに、前記通話先端末と自端末との間の通話処理の実行結果に基づいて、所定の転送先端末への電子メール送信処理を実行することを特徴とする。

また、本発明は、ネットワークを介して接続された通話先端末の第１の識別情報を入力して前記通話先端末と通話処理を実行する通話方法であって、グループ参加管理手段が、自端末又は前記通話先端末を含む端末の第１の識別情報と、前記ネットワークに接続された前記端末を分割した複数のグループにおいて当該端末の属しているグループとの対応関係を示すテーブルが記憶された第１の記憶手段であって、前記自端末のグループに属する前記端末により共有される第１の記憶手段の前記テーブルに基づき、前記通話先端末の前記第１の識別情報により、当該通話先端末が参加しているグループを識別し、前記通話先端末が前記自端末とは異なるグループに参加している場合には、自端末を前記通話先端末が参加しているグループに参加させ、通話処理手段が、前記通話先端末の第１の識別情報、及び、前記通話先端末の状態を記憶する、前記グループに属する端末により共有される第２の記憶手段から読み込んだ前記通話先端末の状態に基づいて、前記通話先端末の第１の識別情報から変換された前記通話先端末の第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行することを特徴とする。

また、本発明は、ネットワークを介して接続された通話先端末の第１の識別情報を入力して前記通話先端末と通話処理を実行する処理をコンピュータに実行させるためのプログラムであって、グループ参加管理手段が、自端末又は前記通話先端末を含む端末の第１の識別情報と、前記ネットワークに接続された前記端末を分割した複数のグループにおいて当該端末の属しているグループとの対応関係を示すテーブルが記憶された第１の記憶手段であって、前記自端末のグループに属する前記端末により共有される第１の記憶手段の前記テーブルに基づき、前記通話先端末の前記第１の識別情報により、当該通話先端末が参加しているグループを識別し、前記通話先端末が前記自端末とは異なるグループに参加している場合には、自端末を前記通話先端末が参加しているグループに参加させるグループ参加管理処理と、通話処理手段が、前記通話先端末の第１の識別情報、及び、前記通話先端末の状態を記憶する、前記グループに属する端末により共有される第２の記憶手段から読み込んだ前記通話先端末の状態に基づいて、前記通話先端末の第１の識別情報から変換された前記通話先端末の第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行する通話処理とをコンピュータに実行させるための通話プログラムである。

以上説明したように、本発明によれば、ネットワーク（例えば実施の形態におけるインターネット）を介して接続された通話先端末（例えば、実施の形態におけるＩＰ電話端末）の第１の識別情報（例えば、実施の形態における電話番号）及び通話先端末の状態を記憶する記憶手段（例えば、実施の形態における分散共有メモリ）と接続され、通話先端末の第１の識別情報を入力して通話先端末と通話処理を実行する端末（例えば、実施の形態におけるＩＰ電話端末）において、通話先端末の第１の識別情報を入力して、記憶手段より通話先端末の状態を読み込み、読み込んだ通話先端末の状態に基づいて、通話先端末の第１の識別情報から変換された通話先端末の第２の識別情報（例えば、実施の形態におけるＩＰアドレス）を用いて通話先端末を識別して、通話先端末と自端末との間で通話処理を実行する。
したがって、自端末と通話先端末の間にソフトスイッチ等の中継交換機を介することなく、（インターネット等の通信網を利用した）通話を実現することができる効果が得られる。

また、本発明によれば、通話処理を実行すると判定した場合、記憶手段に記憶された通話先端末の状態を通話準備状態に変更するとともに、第２の識別情報を用いて通話先端末を識別して、通話先端末と自端末との間で通話処理を実行する。
したがって、他の端末から通話先端末への通話を一時的にロックするため、２重に通話処理が実行されてしまうことを防止することができる効果が得られる。

また、本発明によれば、記憶手段は、自端末の状態をさらに記憶し、所定の時点で自端末の状態を通話準備状態に変更する。
したがって、他の端末から自端末及び通話先端末への通話を一時的にロックするため、２重に通話処理が実行されてしまうことを防止することができる効果が得られる。

以下、本発明を実施するための最良の形態について説明する。
まず本発明の基本的な考え方について説明する。
本発明においては、発呼側のＩＰ電話端末が中継交換機を介さずに着呼側の（通話先の）ＩＰ電話端末の状態を取得する。発呼側のＩＰ電話端末は、通話先のＩＰ電話端末に限定された情報のみを制御すればよいため、前述の集中システムのように複雑な処理を実現する必要がなくなる。
一方、各ＩＰ電話端末で通話先のＩＰ電話端末の情報を扱う性能を保証することで、通信サービス全体に参加するＩＰ電話端末の総量が変動した場合であっても、常に一定のサービス、品質、性能等を保証することができる。
以下、集中システムを用いない通信ネットワークシステムをより強度に実現するため、各ＩＰ電話端末の情報をどのようにネットワーク上において共有するかについて説明し、情報を共有することで、より高度な通話サービスを実現する方法について述べる。

以下、図面を参照して、本発明の端末の一実施形態について説明する。図１は、本実施形態の端末１を複数接続した通信ネットワークシステムの構成図である。
本実施形態において、通信ネットワークシステムは、ネットワーク上でユニークな識別情報で各端末１を識別する。この識別情報としては、インターネットを利用する場合であれば、ＩＰアドレスを利用することが考えられる。各端末１は、通話先の電話番号を入力することで、この電話番号と紐付けられているＩＰアドレスを特定し、このＩＰアドレスを用いて通話先の端末１（以下、ＩＰ電話端末１とする）を特定する。そして、特定した通話先のＩＰ電話端末１に対して、データストリーミングを開始して、データや音声を送信する。
通話先のＩＰ電話端末１の情報（ＩＰアドレス、状態）は、各ＩＰ電話端末１と接続されたメモリ上に記憶されている。具体的には、このメモリは、ネットワーク上のＩＰ電話端末１（自端末、通話先端末）、または、他のコンピュータ端末上に構築されるか（共有メモリ方式）、ネットワーク上の複数のＩＰ電話端末１に各ＩＰ電話端末１の情報単位に分散されて構築される（分散共有メモリ（ＤＳＭ）方式）。すなわち、各ＩＰ電話端末１の情報は、所定の共有メモリ上に格納される。

この共有メモリにリアルタイムにアクセス可能なＩＰ電話端末１の範囲に応じて、各ＩＰ電話端末１は複数のグループに分割される。すなわち、共有メモリは、ＩＰ電話端末１の情報を共有する範囲を限定するために、複数のセグメントグループに分割される。この各セグメントが各ＩＰ電話端末１のグループに対応し、対応するグループに属する複数のＩＰ電話端末１の情報がデータ項目として定義される。
このように共有メモリ等を用いて、リアルタイムに各ＩＰ電話端末１の情報を共有することで、通話先のＩＰ電話端末１と連動する際に問題となるネットワーク遅延に対処するとともに、グループ内のいずれかのＩＰ電話端末１が故障した場合、これを他のＩＰ電話端末１が検知して、同一グループに属する他のＩＰ電話端末１が故障したＩＰ電話端末１の処理を代行する。
すなわち、各ＩＰ電話端末間で連動しやすい範囲にグループを分割し、頻繁に行われるサービスについては、ネットワーク負荷を考慮して連動範囲を限定する。

各ＩＰ電話端末１は、常にグループ参加する、つまり、複数のＩＰ電話端末１によって構成される通信ネットワークシステムに常時接続するか、必要なときにグループ参加する、つまり、サービス利用時にのみ通信ネットワークシステムに接続し、サービス終了後は切断する。この場合、前者においては、ＩＰ電話端末間１の連動が発生する確率が高く、後者においては、ＩＰ電話端末間の連動が発生する確率が低くなる。各ＩＰ電話端末１は、参加するグループの位置について、所定のグループ情報を管理するサーバにアクセスすることで検索する。

このように各グループに参加することで、各ＩＰ電話端末１は、常時、自グループ内のＩＰ電話端末１の情報を格納する共有メモリへのアクセスが許可され、自グループの情報、あるいは、情報の変更差分をリアルタイムに取得する。情報取得のタイミングとしては、グループに参加する際に共有メモリからダウンロードを行う。一度ダウンロードした情報は、各ＩＰ電話端末１内のメモリに保持する。
また、各グループに参加することで、通信先のＩＰ電話端末１が応答不能な状態であれば、グループの他のＩＰ電話端末１がこれを代替することでサービスの継続を保証する。

次に、上述した共有メモリグループと各ＩＰ電話端末１の電話番号とをどのように管理するかについて説明する。
発呼側のＩＰ電話端末１が着呼側のＩＰ電話端末１に電話をする場合において、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１の電話番号を入力して、着呼側のＩＰ電話端末１が参加する共有メモリグループを識別する。
電話番号から共有メモリグループを識別する方法としては、図２に示すように、電話番号のワイルドカードの箇所を共有メモリグループと紐付けるように電話番号と共有メモリグループの対応関係テーブルを構築することが考えられる。具体的には、例えば、電話番号の下数桁をワイルドカードの箇所として、これに含まれる電話番号に共有メモリグループを割り当てる（図２に示す例では、下２桁１００件分の電話番号を１の共有メモリグループに割り当てる）。
また、他の実装例としては、図３に示すように、所定の開始電話番号から終了電話番号までに含まれる複数の電話番号を共有メモリグループと紐付けるように電話番号と共有メモリグループの対応関係テーブルを構築するようにしてもよい。具体的には、例えば、電話番号の下数桁で開始番号と終了番号を設定し、これに含まれる電話番号に共有メモリグループを割り当てる（図３に示す例では、下２桁１１〜２０まで１０件分、２１〜３０まで１０件分の電話番号をそれぞれ１つの共有メモリグループに割り当てる）。

このようにして設定された電話番号と共有メモリグループの対応関係テーブルは、各ＩＰ電話端末１において、まずローカルで設定されることが考えられる。すなわち、各ＩＰ電話端末に電話番号と共有メモリグループの設定情報をダウンロードする。ここで、電話番号と共有メモリグループの対応関係を示す設定情報のテーブルが図４に示すダウンロードサーバ２に格納されている。このダウンロードサーバ２は、各ＩＰ電話端末１からアクセス可能となっている。各ＩＰ電話端末１は、ダウンロードサーバ２から設定情報をダウンロードするダウンロードタイミングをダウンロードサーバ２の負荷が集中しないように調整、例えば、共有メモリグループ内のＩＰ電話端末１でダウンロードする順番を決めて、順次ダウンロード処理を行う。
また、電話番号と共有メモリグループの対応関係テーブルは、共有メモリグループ数、共有メモリグループ１つあたりの電話番号数等の変更により更新される。この更新後の新情報は、図５に示すように、共有メモリグループ単位でダウンロードサーバ２により順にダウンロードされることで、それぞれのグループ内のＩＰ電話端末１に通知される。

一方、このようにグループ単位でダウンロードを行う場合、各ＩＰ電話端末１は、電話番号と共有メモリグループとの対応関係を示すテーブルのバージョンを自端末内のメモリにおいて管理する。そして、図６に示すように、バージョン管理端末が図２あるいは図３に示すようなテーブルの変更を検知すると、各共有メモリグループの制御領域にもテーブルのバージョンと、これを格納するダウンロードサーバ２のＩＰアドレスとを書き込む。また、ＩＰ電話端末１は、自己の管理するテーブルのバージョンと共有メモリグループの制御領域に書き込まれたバージョンとを、所定の時間周期毎に比較し、異なる場合には、制御域領域に書き込まれたバージョンのテーブルをダウンロードサーバよりダウンロードする。
また、各ＩＰ電話端末１は、図７に示すように、電源投入時（グループ参加時）にも自己の管理するテーブルのバージョンと共有メモリグループの制御領域に書き込まれたバージョンとを比較し、異なる場合には、制御域領域に書き込まれたバージョンのテーブルをダウンロードする。
このように構成することで、ダウンロードタイミング時にグループに参加していないＩＰ電話端末についても、確実に更新後の新情報がダウンロードされる。
なお、この場合のダウンロード負荷の集中を低減させるためには、多数のＩＰ電話端末１において電源断が発生している場合には、各共有メモリグループの制御領域に対するバージョン書き込みを実行しないように設定することが考えられる。また、書き込み時においても、各ＩＰ電話端末１への書き込みタイミングをずらし、グループごとにダウンロードサーバへの負荷を調整する。

ところで、電話番号と共有メモリグループとの対応関係を管理するテーブル（またはデータベース）については、同じ時間において、できるだけ各ＩＰ電話端末１すべてが同じ正確な情報（最新バージョンのテーブルの情報）を持っている必要がある。したがって、各ＩＰ電話端末１は、この電話番号と共有メモリグループの関係を管理するテーブルを共有メモリ上に格納する。
ここで、共有メモリ上で管理する電話番号数（メンバ数）が増えるに従って、テーブル更新を通知（同報）する負荷が大きくなる。したがって、共有メモリ上で管理する電話番号数を一定数以下に制限し、図８に示すように、同じ共有メモリの内容を持つグループを階層的に配置し、下位のグループに対しては上位と下位双方のグループに所属するＩＰ電話端末がデータの変更を通知するように構成する。すなわち、情報のメンテナンスは、任意のＩＰ電話端末で実施し、二重にグループを保持しているＩＰ電話端末１が情報の複製を行う。
このように、テーブル更新を通知（同報）する範囲を階層単位に区切ることにより、同じデータが多くのＩＰ電話端末で共通に使用することが可能となる。

この場合、上下グループに所属するＩＰ電話端末１が故障等により消滅した場合、通信ネットワークが切断されてしまう。したがって、上下グループに所属するＩＰ電話端末１を多重化し、故障したＩＰ電話端末１を他のＩＰ電話端末１で代替する。
具体的には、互いに各ＩＰ電話端末１の状態を監視し、故障検出時には、共有メモリ上に状態「故障」を書き込む。一方、同一グループ内において代替可能なＩＰ電話端末１を特定し、当該予備のＩＰ電話端末１において故障状態のＩＰ電話端末１の処理を代替する。また、複数の予備ＩＰ電話端末が同時に書き込みをした場合には、調停により１のＩＰ電話端末を決定する。

一方、共有メモリ上ですべてのＩＰ電話端末１が同時に同じデータを保有する方式においては、通信ネットワークシステムを構成するＩＰ電話端末１が増えるほど、ネットワーク遅延が問題となる。
したがって、通信ネットワークシステムを構成するＩＰ電話端末１が増えた場合、頻繁に使用しない情報は必要な都度取得し、情報共有のためのネットワーク負荷を減らす。
具体的には、情報利用の頻度（トラヒック）に応じて、共有メモリを階層的に配置し、各グループは階層間のルーティング情報を管理する。
具体的には、今、ここで情報利用の頻度を地域と仮定し、遠い地域ほど使用する頻度は低いものとする。そして、頻度の低いデータを取得する場合、頻度の低さに応じてネットワーク負荷、時間に対する条件をゆるくしても良いように条件を設定する。

すなわち、図９に示すように、まず地域を階層構造状に配置する。そして、末端のグループに実データであるテーブルを設定し、中間層は末端の各グループのルーティング情報を記述する。これは、中間層に実データを設定するとグループの配置が複雑化するためである。
次に、情報利用頻度が高い地域をなるべく隣接するように配置する。こうすることにより”近い地域＝情報利用頻度が高い”条件をクリアする。
そして、地域Ａの代表者となるＩＰ電話端末１が地域Ａ〜Ｃからなる集合Ａをルーティング情報により管理し、地域ＡのＩＰ電話端末１は、電話番号と共有メモリグループ（セグメント）との対応関係を示すテーブルにより、地域Ｃのグループの共有メモリを参照して、電話番号に対応したＩＰアドレスにより地域ＣのＩＰ電話端末１に電話する。
同様に、集合Ａの代表者となるＩＰ電話端末１が集合Ａ〜Ｃからなる大集合Ａをルーティング情報により管理し、地域ＡのＩＰ電話端末１は、電話番号と共有メモリグループとの対応関係を示すテーブルにより、集合Ｂ内の地域Ｄのグループの共有メモリを参照して、電話番号に対応したＩＰアドレスにより地域ＤのＩＰ電話端末１に電話する。
以上のように、電話番号と共有メモリのセグメントとを対応付けて管理する。

以下、各ＩＰ電話端末１による共有メモリへの初期登録処理について説明する。
各ＩＰ電話端末１は、参加している共有メモリグループに自身の情報（自情報、例えば、図１０に示す自電話番号、自電話ＩＤ、自ＩＰアドレス、自状態、相手電話番号、相手アドレス）を常に登録する。具体的には、図１１に示すように、各ＩＰ電話端末１は、まず起動時に設定されている共有メモリのセグメントグループに参加し、自電話ＩＤと自アドレス（ＩＰアドレス）、自状態（アイドル状態）を登録する。共有メモリ上における自情報の書き込み先フィールドは、例えば、初期値（例えば０）によって識別される。すなわち、各ＩＰ電話端末１は、共有メモリ上のフィールドが初期値であれば空きと認識し、その初期値に自分の電話番号を設定して使用中として、その書き込みフィールドに自情報を書き込む。なお、複数のＩＰ電話端末１の間で同時に空きを認識して、同一の書き込みフィールドに対する書き込みが発生しないように、グループ内の任意のＩＰ電話端末１が予め定められてシーケンサとなり、順序制御を行う。
以上のように、各ＩＰ電話端末１は、共有メモリに対する初期登録を行う。

次に、図面を参照して、本実施形態の端末の動作について説明する。図１２は、本実施形態の同一の共有メモリグループ内における通話処理の過程を示すフローチャートである。
通話先が同一共有メモリグループの場合（基本通話（内線））、発呼側のＩＰ電話端末１は、通話先の共有メモリグループに新たに参加する処理の必要が無く、着呼側のＩＰ電話端末１のＩＰアドレスを取得して通話を行う。
具体的には、発呼側のＩＰ電話端末１において、受話器が上げられ、着呼側のＩＰ電話端末１の電話番号が入力されると（図１２のステップＳ１）、発呼側のＩＰ電話端末１は、共有メモリ上に書き込まれた自端末の状態を読み込んで、「終了中（通話が出来ない状態）」であるか否かを確認する（ステップＳ２）。終了中の場合は、アイドルになるまで、通話開始処理を保留する。具体的には、自端末の状態が「終了中」であれば、発呼側のＩＰ電話端末１は、自端末の状態が「終了中」から変更されるまで、アイドルループ処理を実行する。一方、自端末の状態が「終了中」でなければ、発呼側のＩＰ電話端末１は、相手とのコネクション接続中に他から通話されないように、共有メモリを使って自状態を管理する。すなわち、発呼側のＩＰ電話端末１は、共有メモリ上の自端末の状態を「通話準備中」に変更する（ステップＳ３）。この自状態の管理は、通話中を検出した場合のロールバック処理の削減を考慮して出来るだけ早急に行われる。

次に、発呼側のＩＰ電話端末１は、入力された着呼側のＩＰ電話端末１の電話番号をキーとして、この共有メモリグループの共有する共有メモリ上に書き込まれた着呼側のＩＰ電話端末１の状態を読み出す（ステップＳ４）。
読み出した着呼側のＩＰ電話端末１の状態が「アイドル（着呼待ちの状態）」でない場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、読み出した着呼側のＩＰ電話端末１の状態が「アイドル」であれば、発呼側のＩＰ電話端末１は、共有メモリ上における自端末情報の相手先に通話情報（電話番号、ＩＰアドレス）を設定する（ステップＳ５）。
そして、発呼側のＩＰ電話端末１は、自端末における通話断念の確認を行う（ステップＳ６）。具体的な上記確認として、発呼側のＩＰ電話端末１は、自端末の受話器が下げられているか否かを確認する。自端末の受話器が下げられている場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、自端末の受話器が上げられたまま下げられていない場合、発呼側のＩＰ電話端末１は、共有メモリ上において着呼側のＩＰ電話端末１の状態が「通話中」に変更されるのを監視する（ステップＳ７）。
着呼側のＩＰ電話端末１において受話器が上げられて、共有メモリ上の着呼側のＩＰ電話端末１の状態が「通話中」に変更されると、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１と通話処理を開始する（ステップＳ８）。

以下、図１３を用いて、同一の共有メモリグループ内における発呼側及び着呼側のＩＰ電話端末１の間における詳細な通話処理について説明する（以下、発呼側（発信側）をＡとし、着呼側（着信側）をＢとする）。図１３（ａ）は、呼処理を開始する前の初期状態における共有メモリ上の通話管理テーブルの構成図である。
図１３（ａ）に示すように、共有メモリ上の通話管理テーブルにおいて、Ａ（発信側）及びＢ（着信側）それぞれについて、自電話番号、自アドレス、自状態、相手電話番号、相手アドレスが書き込まれる。以下、このテーブル上のフィールド位置を列番号、行番号で示す。

今、図１３の（ｂ）に示すように、Ａ（発信側）において、受話器が上げられると、共有メモリ上の３．（１）に書き込まれた自状態を「通話準備中」に更新する（図１３のステップＳ１１）。なお、通話準備状態においては、他のＩＰ電話端末１は、共有メモリ上の発呼側のＩＰ電話端末１の状態が「通話準備中」であることを検出すると、このＡ（発呼側）のＩＰ電話端末１に対する状態更新の書き込みを実行しない（または、書き込みを受付けない）ものとする。
次に、受話器が上げられた状態において、Ｂ（着信側）の電話番号が入力されると、Ａ（発信側）は、入力されたＢ（着信側）の電話番号で共有メモリ上の４．（１）に書き込まれた相手電話番号を更新する（ステップＳ１２）。そして、Ａ（発信側）は、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態を読み出して、Ｂ（着信側）の状態が「アイドル」であることを確認する（ステップＳ１３）。この場合、Ｂ（着信側）の状態が「アイドル」であるため、Ａ（発信側）は、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態を「通話準備中」に更新する（ステップＳ１４）。なお、このロック処理については、すれ違いを防止するため、また、通話中を検出した場合のロールバック処理の削減を考慮して、できるだけ早く行うものとする。
なお、ステップＳ１３でＢ（着信側）の状態が「アイドル」でなかった場合、図１４に示すように、Ａ（発信側）は、共有メモリ上の４．（１）に書き込まれた相手電話番号と、共有メモリ上の３．（１）に書き込まれた自状態とを順に初期化、アイドル状態に設定する（ステップＳ３１、３２）。

一方、Ｂ（着信側）は、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態を監視しており（ステップＳ２１）、これが「通話準備中」に更新されると、さらに、共有メモリ上の５．（２）に書き込まれた相手アドレスが初期値以外になることを監視する（ステップＳ２２）。
Ａ（発信側）は、Ｂ（着信側）の状態を「通話準備中」に更新後、入力されたＢ（着信側）の電話番号と紐付けて、共有メモリ上の２．（２）に書き込まれたＢ（着信側）の自アドレス（ＩＰアドレス、図１３（ａ）ではｘｘｘ２）を読み出して、共有メモリ上の５．（１）に書き込まれたＡ（発信側）の相手アドレス（ＩＰアドレス）を更新する（ステップＳ１５）。また、Ａ（発信側）は、共有メモリ上の１．（１）に書き込まれたＡ（発信側）の電話番号（図１３（ａ）ではｘｘ−ｙｙｙ−ｚｚ８）を読み出して、共有メモリ上の４．（２）に書き込まれたＢ（着信側）の相手電話番号を更新する（ステップＳ１６）。そして、Ａ（発信側）は、発ＩＤ通知機能のため、共有メモリ上の２．（１）に書き込まれたＡ（発信側）の自アドレス（図１３（ａ）ではｘｘｘ１）を読み出して、共有メモリ上の５．（２）に書き込まれたＢ（着信側）の相手アドレスを更新する（ステップＳ１７）。
以上の通話情報が設定されると、Ａ（発信側）は、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態が「通話中」に更新されることを監視する（ステップＳ１８）。

Ｂ（着信側）は、共有メモリ上の５．（２）に書き込まれた相手アドレスがＡ（発信側）の自アドレスで更新されたことを検出すると、鳴動処理を開始する（ステップＳ２３）。
そして、鳴動処理中において、受話器が上げられると、Ｂ（着信側）は、これをトリガとして、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態を「通話中」に更新する。
Ａ（発信側）は、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態が「通話中」に更新されたことを検出すると、共有メモリ上の３．（１）に書き込まれたＡ（発信側）の状態を「通話中」に更新する。
そして、Ａ（発信側）は、状態更新後、Ｂ（着信側）へ音声データのストリーミングを開始する（ステップＳ２０、Ｓ２５）。

なお、ステップＳ２４において、Ｂ（着信側）で受話器が上げられなかった場合、終了処理については、受話器を下ろした後、すぐに受話器を上げられることを考慮して、自状態に終了中を設定する。すなわち、図１５に示すように、Ａ（発信側）は、自端末の受話器が下ろされて、通話を中止する（ステップＳ４０）。一方、Ｂ（着信側）は、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態を監視しており（ステップＳ５０）、Ａ（発信側）が、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の状態を「終了中」に更新すると（ステップＳ４１）、Ｂ（着信側）は、これを検出して、鳴動を停止する（ステップＳ５１）。

一方、Ａ（発信側）は、共有メモリ上の３．（１）に書き込まれた自状態を「終了中」に設定し、さらに、共有メモリ上の５．（１）に書き込まれたＡ（発信側）の相手アドレス、共有メモリ上の５．（２）に書き込まれたＢ（着信側）の相手アドレスをそれぞれ順に初期化する（ステップＳ４３、Ｓ４４）。
次に、Ａ（発信側）は、共有メモリ上の４．（２）に書き込まれたＢ（着信側）の相手電話番号と、共有メモリ上の３．（２）に書き込まれたＢ（着信側）の自状態とを順に初期化、アイドル状態に設定し（ステップＳ４５、Ｓ４６）、さらに、共有メモリ上の４．（１）に書き込まれた相手電話番号と、共有メモリ上の３．（１）に書き込まれた自状態とを順に初期化、アイドル状態に設定する（ステップＳ４７、４８）。
以上説明したように、本実施形態のＩＰ電話端末１によれば、発呼側と着呼側との間にソフトスイッチ等の中継交換機を介することなく、インターネットを利用した通話を実現することができる。

次に、図面を参照して、第２の実施形態の端末の動作について説明する。図１６は、本実施形態の通話処理の過程を示すフローチャートである。
通話先が別共有メモリグループの場合（基本通話（外線））、発呼側のＩＰ電話端末１は、中継交換機を介さずに、着呼側のＩＰ電話端末１のＩＰアドレスを取得して通話を行う。
本実施形態の端末の動作が第１の実施形態と異なる点は、着呼側のＩＰ電話端末１の情報を読み書きするために着呼側のＩＰ電話端末１が属する共有メモリグループに参加する点である。以下、第２の実施形態の端末の動作のうち、第１の実施形態と同一の部分については説明を省略し、異なる点についてのみ説明する。
第１の実施形態と同様に、発呼側のＩＰ電話端末１において、着呼側のＩＰ電話端末１の電話番号が入力され（図１６のステップＳ１）、自端末の状態確認（ステップＳ２）、自端末の状態変更（ステップＳ３）が実行されると、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１が属する共有メモリグループに参加する（ステップＳ６０）。すなわち、発呼側のＩＰ電話端末１は、すでに述べた初期登録処理により、着呼側のＩＰ電話端末１の属する共有メモリグループＢの共有メモリに自情報を登録し、必要な情報をダウンロードすることで、共有メモリグループＡ及び共有メモリグループＢの双方に属することになる。

図１７（ａ）は、図１３（ａ）と同様に、呼処理を開始する前の初期状態における共有メモリ上の通話管理テーブルの構成図である。
図１３（ａ）と同様に、発呼側及び着呼側それぞれの共有メモリ上の通話管理テーブルにおいて、Ａ（発信側）及びＢ（着信側）それぞれについて、自電話番号、自アドレス、自状態、相手電話番号、相手アドレスが書き込まれる。

今、図１７の（ｂ）に示すように、Ａ（発信側）の自状態が「通話準備中」に更新され（図１７のステップＳ１１）、相手電話番号が設定されると（ステップＳ１２）、Ａ（発信側）は、Ｂ（着信側）が属する共有メモリグループに参加する（ステップＳ７０）。
そして、以下、ステップＳ１３〜１９、Ｓ２１〜２４と同様に通話情報設定を行い、Ａ（発信側）からＢ（着信側）へ音声データのストリーミングを開始する（ステップＳ２０、Ｓ２５）。
なお、ステップＳ１３でＢ（着信側）の状態が「アイドル」でなかった場合、図１８に示すように、Ａ（発信側）は、Ｂ（着信側）が属する共有メモリグループから退出して（ステップＳ８０）、ステップＳ３１、３２と同様に、初期化等の設定を行う。

また、ステップＳ２４において、Ｂ（着信側）で受話器が上げられなかった場合、図１９２示すように、ステップＳ４０〜４６の初期化等の設定後、Ｂ（着信側）が属する共有メモリグループから退出して（ステップＳ９０）、さらに、ステップＳ４７、４８と同様に、さらに初期化等の設定を行う。
以上説明したように、本実施形態のＩＰ電話端末１によれば、発呼側と着呼側とが別の共有メモリグループに属している場合であっても、発呼側と着呼側との間にソフトスイッチ等の中継交換機を介することなく、インターネットを利用した通話を実現することができる。

次に、図面を参照して、第３の実施形態の端末の動作について説明する。図２０は、本実施形態の通話処理の過程を示すフローチャートである。
通話先が複数の場合（会議電話）、発呼側のＩＰ電話端末１は、中継交換機を介さずに、複数の着呼側のＩＰ電話端末１のＩＰアドレスを取得して通話を行う。
本実施形態の端末の動作が第１の実施形態と異なる点は、着呼側のＩＰ電話端末１の情報を読み書きするために複数の着呼側のＩＰ電話端末１の共有メモリグループに参加する点である。以下、第３の実施形態の端末の動作のうち、第１、２の実施形態と同一の部分については説明を省略し、異なる点についてのみ説明する。

発呼側のＩＰ電話端末１において、受話器が上げられ、会議メンバ数（自端末と複数の着呼側のＩＰ電話端末１の合計値）、複数の着呼側のＩＰ電話端末１の電話番号が入力されると（図２０のステップＳ１００）、発呼側のＩＰ電話端末１は、共有メモリ上に書き込まれた自端末の状態を読み込んで、「終了中」であるか否かを確認する（ステップＳ１０１）。終了中の場合は、アイドルになるまで、通話開始処理を保留する。具体的には、自端末の状態が「終了中」であれば、発呼側のＩＰ電話端末１は、自端末の状態が「終了中」から変更されるまで、アイドルループ処理を実行する。一方、自端末の状態が「終了中」でなければ、発呼側のＩＰ電話端末１は、相手とのコネクション接続中に他から通話されないように、共有メモリを使って自状態を管理する。すなわち、発呼側のＩＰ電話端末１は、共有メモリ上の自端末の状態を「会議準備中」に変更する（ステップＳ１０２）。

次に、発呼側のＩＰ電話端末１は、会議参加者の共有メモリグループに参加する（ステップＳ１０３）。そして、発呼側のＩＰ電話端末１は、入力された複数の着呼側のＩＰ電話端末１の電話番号それぞれをキーとして、それぞれの着呼側のＩＰ電話端末１が属する共有メモリ上に書き込まれた着呼側のＩＰ電話端末１の状態を読み出す（ステップＳ１０４）。
読み出した着呼側のＩＰ電話端末１の状態が「アイドル」でない場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、読み出した着呼側のＩＰ電話端末１の状態が「アイドル」であれば、発呼側のＩＰ電話端末１は、それぞれの共有メモリ上に通話情報（電話番号、ＩＰアドレス）を設定する（ステップＳ１０５）。
そして、発呼側のＩＰ電話端末１は、自端末における通話断念の確認を行う（ステップＳ１０６）。具体的な上記確認として、発呼側のＩＰ電話端末１は、自端末の受話器が下げられているか否かを確認する。自端末の受話器が下げられている場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、自端末の受話器が上げられたまま下げられていない場合、発呼側のＩＰ電話端末１は、共有メモリ上において着呼側のＩＰ電話端末１の状態が「通話中」に変更されるのを監視する（ステップＳ１０７）。

着呼側のＩＰ電話端末１において受話器が上げられて、それぞれ共有メモリ上の着呼側のＩＰ電話端末１の状態が「通話中」に変更されると、発呼側のＩＰ電話端末１は、当該状態が「通話中」に変更された着呼側のＩＰ電話端末１の数が入力されたメンバ数に等しいかを確認する（ステップ１０８）。
状態が「通話中」に変更された着呼側のＩＰ電話端末１の数が入力されたメンバ数に等しい場合、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１と通話処理を開始する（ステップＳ１０９）。
一方、状態が「通話中」に変更された着呼側のＩＰ電話端末１の数が入力されたメンバ数より少ない場合は、ステップＳ１０３〜１０９を繰り返し実行し、状態が「通話中」に変更された着呼側のＩＰ電話端末１の数が入力されたメンバ数に等しくなった後、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１と通話処理を開始する（ステップＳ１０９）。

以下、図２１を用いて、発呼側（会議主催者）及び着呼側（参加者１、２）のＩＰ電話端末１の間における詳細な通話処理について説明する（以下、発呼側（会議主催者）をＡとし、着呼側（参加者１、２）をＢ、Ｃとする）。図２１（ａ）は、呼処理を開始する前の初期状態におけるＡ〜Ｃが属する共有メモリグループＡ〜Ｃ上の通話管理テーブルの構成図である。
図２１（ａ）に示すように、Ａ〜Ｃが属する共有メモリグループＡ〜Ｃ上の通話管理テーブルにおいて、Ａ（会議主催者）及びＢ、Ｃ（参加者１、２）それぞれについて、自電話番号、自アドレス、自状態、複数の相手電話番号、複数の相手アドレスが書き込まれる。

今、図２１の（ｂ）に示すように、Ａ（主催者）において、受話器が上げられ、会議参加者数（メンバ数）と、Ｂ（参加者１）、Ｃ（参加者２）の電話番号とが入力されると、入力されたＢ（参加者１）、Ｃ（参加者２）の電話番号で共有メモリ上の４．（１）、６．（１）に書き込まれた相手電話番号１、２を更新する（ステップＳ１２０）。
次に、Ａ（主催者）は、共有メモリ上の３．（１）に書き込まれた自状態を「会議準備中」に更新し（ステップＳ１２１）、共有メモリグループＢに参加する（ステップＳ１２２）。そして、Ａ（主催者）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態を読み出して、Ｂ（参加者１）の状態が「アイドル」であることを確認する（ステップＳ１２３）。この場合、Ｂ（参加者１）の状態が「アイドル」であるため、Ａ（主催者）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態を「会議準備中１」に更新する（ステップＳ１２４）。
一方、Ｂ（参加者１）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態を監視する（ステップＳ１５０）。そして、Ｂ（参加者１）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態が「会議準備中１」に更新されたことを検出すると、鳴動処理を開始する（ステップＳ１５１）。

Ａ（主催者）は、Ｂ（参加者１）の状態を「会議準備中１」に更新後、入力されたＢ（参加者１）の電話番号と紐付けて、共有メモリ上の２．（２）に書き込まれたＢ（参加者１）の自アドレスを読み出して、共有メモリ上の５．（１）に書き込まれたＡ（主催者）の相手アドレスを更新する（ステップＳ１２５）。また、Ａ（主催者）は、共有メモリ上の１．（１）、６．（１）に書き込まれたＡ（主催者）及びＣ（参加者２）の電話番号を読み出して、共有メモリ上の４．（２）、６．（２）に書き込まれたＢ（参加者１）の相手電話番号１，２を更新する（ステップＳ１２６）。そして、Ａ（主催者）は、発ＩＤ通知機能のため、共有メモリ上の２．（１）に書き込まれたＡ（主催者）の自アドレスを読み出して、共有メモリ上の５．（２）に書き込まれたＢ（参加者１）の相手アドレスを更新する（ステップＳ１２７）。
以上の通話情報が設定されると、Ａ（主催者）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態が「会議準備中２」に更新されることを監視する（ステップＳ１２８）。

一方、鳴動処理中において、受話器が上げられ、共有メモリ上の５．（２）に書き込まれた相手アドレスが初期値以外になると、Ｂ（参加者１）は、これをトリガとして、共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態を「会議準備中２」に更新する（ステップＳ１５２）。
共有メモリ上の３．（２）に書き込まれたＢ（参加者１）の状態が「会議準備中２」に更新されたことを検出すると、次に、Ａ（主催者）は、共有メモリグループＣに参加する（ステップＳ１２９）。そして、Ａ（主催者）は、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態を読み出して、Ｃ（参加者２）の状態が「アイドル」であることを確認する（図２２のステップＳ１３０）。この場合、Ｃ（参加者２）の状態が「アイドル」であるため、Ａ（主催者）は、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態を「会議準備中１」に更新する（ステップＳ１３１）。
一方、Ｃ（参加者２）は、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態を監視する（図２２のステップＳ１６０）。そして、Ｃ（参加者２）は、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態が「会議準備中１」に更新されたことを検出すると、鳴動処理を開始する（ステップＳ１６１）。

Ａ（主催者）は、Ｃ（参加者２）の状態を「会議準備中１」に更新後、入力されたＣ（参加者２）の電話番号と紐付けて、共有メモリ上の２．（３）に書き込まれたＣ（参加者２）の自アドレスを読み出して、共有メモリ上の７．（１）、７．（２）に書き込まれたＡ（主催者）の相手アドレスを更新する（ステップＳ１３２、Ｓ１３３）。また、Ａ（主催者）は、共有メモリ上の１．（１）、４．（１）に書き込まれたＡ（主催者）及びＢ（参加者１）の電話番号を読み出して、共有メモリ上の４．（３）、６．（３）に書き込まれたＣ（参加者２）の相手電話番号１，２を更新する（ステップＳ１３４）。そして、Ａ（主催者）は、発ＩＤ通知機能のため、共有メモリ上の５．（１）、２．（１）に書き込まれたＢ（参加者１）及びＡ（主催者）の自アドレスを読み出して、共有メモリ上の７．（３）、５．（３）に書き込まれたＣ（参加者２）の相手アドレス１，２を更新する（ステップＳ１３５、Ｓ１３６）。
以上の通話情報が設定されると、Ａ（主催者）は、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態が「会議準備中２」に更新されることを監視する（ステップＳ１３７）。

一方、鳴動処理中において、受話器が上げられ、共有メモリ上の５．（３）に書き込まれた相手アドレスが初期値以外になると、Ｃ（参加者２）は、これをトリガとして、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態を「会議準備中２」に更新する（ステップＳ１６２）。Ａ（主催者）は、共有メモリ上の３．（３）に書き込まれたＣ（参加者２）の状態が「会議準備中２」に更新されたことを検出すると、共有メモリ上の３．（３）、３．（２）、３．（１）に書き込まれたＣ（参加者２）、Ｂ（参加者１）及びＡ（主催者）の状態を「会議中」に更新する（ステップＳ１３８、Ｓ１３９、Ｓ１４０）。
そして、Ｃ（参加者２）、Ｂ（参加者１）は、状態更新後、Ａ（発信側）へ音声データのストリーミングを開始する（ステップＳ１４１、Ｓ１４２、Ｓ１５３、Ｓ１６３）。

以上説明したように、本実施形態のＩＰ電話端末によれば、会議人数分のアドレス領域を共有メモリに準備し、複数の端末間で会議電話を行うことができる。
また、本実施形態のＩＰ電話端末によれば、主催者のみが全メンバ分の共有メモリにアクセスするため、ネットワーク負荷が低く抑えられる。また、本実施形態のＩＰ電話端末によれば、参加者を順に参加させていくため、途中メンバが話中の場合だった場合、ロールバック処理が少なくてすむ。さらに、本実施形態のＩＰ電話端末によれば、参加メンバ数分の領域を用意すれば、参加メンバ数のＩＰ電話端末１が会議に参加することができるため、会議参加人数制限が無くなる。さらに、本実施形態のＩＰ電話端末によれば、会議メンバ情報を設定するとき、相手アドレス１を必ず最後に設定することにより、参加者は参加人数を意識することなく情報の設定が完了したか判断できる。

次に、図面を参照して、第４の実施形態の端末の動作について説明する。図２３は、本実施形態の通話処理の過程を示すフローチャートである。
複数のＩＰ電話端末１が会議電話中において、新規参加（発呼側）のＩＰ電話端末１は、中継交換機を介さずに、会議電話中のＩＰ電話端末１のＩＰアドレスを取得して、通話中に割り込み可能な電話会議に参加（以下、パージイン）する。
本実施形態の端末の動作が第３の実施形態と異なる点は、会議電話中のＩＰ電話端末１の情報を読み書きするために複数の着呼側のＩＰ電話端末１の共有メモリグループに参加する点である（パージイン）。以下、第４の実施形態の端末の動作のうち、第１〜３の実施形態と同一の部分については説明を省略し、異なる点についてのみ説明する。
新規参加のＩＰ電話端末１において、受話器が上げられ、参加したい電話会議に参加中のＩＰ電話端末１の電話番号が入力されると（図２３のステップＳ１７１）、新規参加のＩＰ電話端末１は、共有メモリ上に書き込まれた自端末の状態を読み込んで、「終了中」であるか否かを確認する（ステップＳ１７２）。終了中の場合は、アイドルになるまで、通話開始処理を保留する。具体的には、自端末の状態が「終了中」であれば、新規参加のＩＰ電話端末１は、自端末の状態が「終了中」から変更されるまで、アイドルループ処理を実行する。一方、自端末の状態が「終了中」でなければ、新規参加のＩＰ電話端末１は、相手とのコネクション接続中に他から通話されないように、共有メモリを使って自状態を管理する。すなわち、新規参加のＩＰ電話端末１は、共有メモリ上の自端末の状態を、通話準備の一種である「パージ準備中」に変更する（ステップＳ１７３）。

次に、新規参加のＩＰ電話端末１は、参加中のＩＰ電話端末１が属する共有メモリグループに参加する（ステップＳ１７４）。そして、新規参加のＩＰ電話端末１は、入力された参加中のＩＰ電話端末１の電話番号をキーとして、共有メモリ上に書き込まれた参加中のＩＰ電話端末１の状態を読み出す（ステップＳ１７５）。
読み出した参加中のＩＰ電話端末１の状態が「通話中／会議中」でない場合、新規参加のＩＰ電話端末１は、発呼処理を終了する。一方、読み出した参加中のＩＰ電話端末１の状態が「通話中／会議中」であれば、新規参加のＩＰ電話端末１は、共有メモリ上の通話情報（電話番号、ＩＰアドレス）を取得する（ステップＳ１７６）。

そして、新規参加のＩＰ電話端末１は、取得した通話情報から通話メンバ（会議に参加しているＩＰ電話端末１）の共有メモリグループすべてに参加する（ステップＳ１７７）。すべての共有メモリグループに参加が完了すると、新規参加のＩＰ電話端末１は、これらの共有メモリグループに参加中のＩＰ電話端末１の電話番号をキーとして、共有メモリ上に書き込まれた参加中のＩＰ電話端末１の状態を読み出す（図２４のステップＳ１７８）。
読み出した参加中のＩＰ電話端末１の状態が「通話中／会議中」でない場合、該当する端末の情報は削除する（ステップＳ１８３）。一方、読み出した参加中のＩＰ電話端末１の状態が「通話中／会議中」であれば、新規参加のＩＰ電話端末１は、自アドレス情報をこれらの共有メモリグループに参加中のＩＰ電話端末１に設定する（ステップＳ１７９）。そして、新規参加のＩＰ電話端末１は、これらの共有メモリグループに参加中のＩＰ電話端末１の状態にパージｘを設定する（ステップＳ１８０ ただし、パージｘは、自アドレス情報の格納場所を示す）。ここで、上記ＩＰ電話端末１に対し、パージしてくる他の共有グループにおけるＩＰ電話端末が複数同時に存在する場合、共有メモリへの書き込みが競合してしまうため、この競合を解消する必要がある。具体的には、例えば、パージ状態とする端末において最も小さい電話番号のＩＰ電話端末を最優先端末し、この共有メモリへの書き込みが成功した割り込み端末（すなわち新規参加のＩＰ電話端末１）が、割り込み記述をした位置への優先書き込み権を得るように構成する。このように構成することで、共有メモリへの書き込みの競合が解消できるとともに、会議参加端末それぞれで書き込み結果の確認をする必要がなくなる。

次に、新規参加のＩＰ電話端末１は、状態を読み出した参加中のＩＰ電話端末１が最優先端末であれば、この端末に対し、すでにパージの設定がされているか否か（割り込みの有無）を確認する（ステップＳ１８４）。また、状態を読み出した参加中のＩＰ電話端末１が最優先端末でないか、または、パージが設定されていない場合、他にパージ状態とする端末として設定されている参加中のＩＰ電話端末１があるか否かを確認し、なければ全端末の情報を確認する（ステップＳ１８１）。そして、電話会議に参加中のＩＰ電話端末１すべての状態が「会議中」であれば、自端末の状態を「会議中」に設定する（ステップＳ１８２）。
一方、最優先端末の状態がすでにパージに設定されている場合、割り込みが終了しているか否かを確認する（ステップＳ１８５）。そして、割り込みが終了するまでアイドルループ処理を実行し、割り込みが終了した後、自アドレス情報を最優先端末（参加中のＩＰ電話端末１）に設定し（ステップＳ１８６）、参加中のＩＰ電話端末１の状態にパージｘを設定する（ステップＳ１８７）。

以下、図２５を用いて、着呼側（参加者１、２）及び発呼側（新規参加者）のＩＰ電話端末１の間における詳細な通話処理について説明する（以下、着呼側（参加者１、２）をＡ、Ｂとし、発呼側（新規参加者）をＣとする）。図２５（ａ）は、呼処理を開始する前の初期状態におけるＡ〜Ｃが属する共有メモリグループＡ〜Ｃ上の通話管理テーブルの構成図である。
図２５（ａ）に示すように、Ａ〜Ｃが属する共有メモリグループＡ〜Ｃ上の通話管理テーブルにおいて、Ａ、Ｂ（参加者１、２）及びＣ（新規参加者）それぞれについて、自電話番号、自アドレス、自状態、複数の相手電話番号、複数の相手アドレスが書き込まれる。

今、図２５の（ｂ）に示すように、Ｃ（新規参加者）において、受話器が上げられ、Ｂ（参加者２）の電話番号が入力されると（ステップＳ１９１）、Ｃ（新規参加者）は、共有メモリ上の３．（１）に書き込まれた自状態を「パージ準備中」に更新し（ステップＳ１９２）、共有メモリグループＢに参加する（ステップＳ１９３）。そして、Ｃ（新規参加者）は、共有メモリ上の１．（２）、２．（２）、４．（２）、５．（２）に書き込まれたＢ（参加者２）の自電話番号、自アドレス、相手電話番号１、相手アドレス１を読み出して、共有メモリ上の４．（３）、５．（３）、６．（３）、７．（３）に書き込まれたＣ（新規参加者）の相手電話番号１、相手アドレス１、相手電話番号２、相手アドレス２を更新する（ステップ１９４）。
これにより、Ｃ（新規参加者）は、会議参加者Ａを特定し、さらに、特定したすべての参加者の共有メモリグループ（この場合は、メモリグループＡのみ）に参加する（ステップＳ１９５）。そして、Ｃ（新規参加者）は、Ｂ（参加者２）の空いている相手電話番号２、相手アドレス２に自情報を設定する。具体的には、Ｃ（新規参加者）は、共有メモリ上の１．（３）、２．（３）に書き込まれたＣ（新規参加者）の自電話番号、自アドレスを読み出して、共有メモリ上の６．（２）、７．（２）に書き込まれたＢ（参加者２）の相手電話番号２、相手アドレス２を更新する（ステップ１９６）。

次に、Ｃ（新規参加者）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者２）の状態を「パージ２」に更新する（ステップＳ１９７）。
一方、Ｂ（参加者２）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者２）の状態を監視する（ステップＳ２１１）。そして、Ｂ（参加者２）は、共有メモリ上の３．（２）に書き込まれたＢ（参加者２）の状態が「パージ２」に更新されたことを検出すると、共有メモリ上の３．（２）に書き込まれた自状態を「会議中」に変更する（ステップＳ２１２）。以上により、Ｃ（新規参加者）は、Ｂ（参加者２）との間に通信路を確立し、ストリーミングを開始する（ステップＳ２１３、Ｓ１９８）。

次に、Ｃ（新規参加者）は、Ａ（参加者１）との間で通信路を確立する。すなわち、Ｃ（新規参加者）は、Ａ（参加者１）の空いている相手電話番号２、相手アドレス２に自情報を設定する。具体的には、Ｃ（新規参加者）は、共有メモリ上の１．（３）、２．（３）に書き込まれたＣ（新規参加者）の自電話番号、自アドレスを読み出して、共有メモリ上の６．（１）、７．（１）に書き込まれたＡ（参加者１）の相手電話番号２、相手アドレス２を更新する（ステップ１９９）。

次に、Ｃ（新規参加者）は、共有メモリ上の３．（１）に書き込まれたＡ（参加者１）の状態を「パージ２」に更新する（ステップＳ２００）。
一方、Ａ（参加者１）は、共有メモリ上の３．（１）に書き込まれたＡ（参加者１）の状態を監視する（図２６のステップＳ２２１）。そして、Ａ（参加者１）は、共有メモリ上の３．（１）に書き込まれたＡ（参加者１）の状態が「パージ２」に更新されたことを検出すると、共有メモリ上の３．（１）に書き込まれた自状態を「会議中」に変更する（ステップＳ２２２）。
Ｃ（新規参加者）は、共有メモリグループに参加中のＩＰ電話端末１すべての自状態が「会議中」に変更されると、自状態を「会議中」に変更して会議を開始する。
以上により、Ｃ（新規参加者）は、Ａ（参加者１）との間に通信路を確立し、ストリーミングを開始する（ステップＳ２２３、Ｓ２０３）。

以上説明したように、本実施形態のＩＰ電話端末によれば、通話中のメンバ情報の電話番号およびアドレスを共有メモリで管理するため、パージインするＩＰ電話端末が通話中のメンバ一人の電話番号がわかれば、そのメンバが通話している全相手の情報を取得して、通信路を確立することにより会議に参加することができる。
また、本実施形態のＩＰ電話端末によれば、共有メモリの領域で保持する限界まで、何人会議中であっても通話中のメンバのうち一人のグループ参加することで、全ＩＰ電話端末の情報を取得でき、パージインすることができる。
さらに、本実施形態のＩＰ電話端末によれば、新規参加時に必要な共有メモリグループに全て参加するため、参加処理を即時に行うことができる。

さらに、本実施形態のＩＰ電話端末によれば、各ＩＰ電話端末ごとに自アドレス情報を書き込み、最後に自状態をパージ中として、相手に新規メンバを認識させる。このように構成することで、相手が認識した際にすでに情報が記述されている。したがって、認識処理が容易になる効果が得られる。
また、本実施形態のＩＰ電話端末によれば、最初にパージ状態にするＩＰ電話端末を一定の法則で決定し、そこから始めることで同時アクセスの制御を行う。具体的には、アドレスが最小のものから開始する等の方法で最初にパージ状態にするＩＰ電話端末を決定する。この用に構成することで、新規参加メンバが複数同時にアクセスする場合において、自状態のパージ情報位置が合わなくなることを防止する。また、パージ位置について自書き込みが正常に行われたか確認し、異なる書き込みが発生した場合には、一定期間待ち合わせをおこない、パージ状態が解除されてから再度行う。

次に、図面を参照して、第５の実施形態の端末の動作について説明する。図２７は、本実施形態の通話処理の過程を示すフローチャートである。
本実施形態の端末の動作が、第１〜４の実施形態と異なる点は、着呼側のＩＰ電話端末１が通話できない場合の付加サービス（転送電話、留守電メール）を実行する点である。
ここで、転送電話は、通信不可となった場合に登録されている転送先を通話先として通信するサービスである。また、留守電メールとは、通信不可となった場合に登録されているメールアドレスに対して音声を添付したメールを送信するサービスである。メール送信は、送信元ＩＰ電話端末で行う。

以下、第５の実施形態の端末の動作のうち、第１〜４の実施形態と同一の部分については説明を省略し、異なる点についてのみ説明する。
第２の実施形態におけると同様に（図１６のステップＳ１〜５を参照）、発呼側のＩＰ電話端末１において、着呼側のＩＰ電話端末１の電話番号が入力され、自端末の状態確認、自端末の状態変更が実行されると、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１が属する共有メモリグループに参加する。
そして、発呼側のＩＰ電話端末１は、入力された着呼側のＩＰ電話端末１の電話番号をキーとして、参加した共有メモリ上に書き込まれた着呼側のＩＰ電話端末１の状態を読み出す。
読み出した着呼側のＩＰ電話端末１の状態が「アイドル」でない場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、読み出した着呼側のＩＰ電話端末１の状態が「アイドル」であれば、発呼側のＩＰ電話端末１は、共有メモリ上に通話情報（電話番号、ＩＰアドレス）を設定する（以上、ステップＳ２３１）。

次に、発呼側のＩＰ電話端末１は、通話確認タイマをセットし（ステップＳ２３２）、自端末の受話器が下げられた状態において、着呼側のＩＰ電話端末１において受話器が上げられずにタイムアウトするまで、自端末における通話断念を確認する（ステップＳ２３３）。具体的には、発呼側のＩＰ電話端末１は、自端末の受話器が下げられているか否かを確認する。自端末の受話器が下げられている（受話器断である）場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、自端末の受話器が上げられたままである場合、発呼側のＩＰ電話端末１は、共有メモリ上における着呼側のＩＰ電話端末１の状態が「通話中」に変更されるのを監視する（ステップＳ２３４）。
着呼側のＩＰ電話端末１において受話器が上げられて、共有メモリ上の着呼側のＩＰ電話端末１の状態が「通話中」に変更された場合、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１と通話処理を開始する（ステップＳ２３５）。

一方、着呼側のＩＰ電話端末１において受話器が上げられずに、セットした通話確認タイマがタイムアウトした場合、通信不可時（不在対応時）のサービスとして設定されている転送電話サービス、留守電メールサービスが実行される。
転送電話サービスが通信不可時のサービスとして設定されている場合、共有メモリ上の通話先を予め設定された転送先に変更し（ステップＳ２３６）、共有メモリに格納された旧通話先の情報をクリアして（ステップＳ２３７）、転送先の通話処理を実行する（ステップＳ２３８ 図１６のＳ６０〜Ｓ８と同様）。なお、転送先がループになって、無限リトライとならないように転送は１度しか行わない条件を電話機側で設定する。
また、留守電メールサービスが通信不可時のサービスとして設定されている場合、予め設定された送信先アドレスへ音声を添付して電子メールを送信する（ステップＳ２３９）

以下、図２８を用いて、Ａ（通話者）、Ｂ（着信者）、Ｃ（転送先）のＩＰ電話端末１の間における詳細な付加サービス処理について説明する。図２８（ａ）は、転送電話及び留守電メールの付加サービスを行なう場合の共有メモリ上の通話管理テーブルの構成図である。
図２８（ａ）に示すように、Ａ〜Ｃが属する共有メモリグループＡ〜Ｃ上の通話管理テーブルにおいて、Ａ（通話者）、Ｂ（着信者）、Ｃ（転送先）それぞれについて、自電話番号、自アドレス、自状態、相手電話番号、相手アドレス、確認コール数、不在対応、転送先、メールアドレスが書き込まれる。

今、図２８の（ｂ）に示すように、Ａ（通話者）の自状態が「アイドル」から「通話準備中」に更新され、相手電話番号が設定されると、Ａ（通話者）は、Ｂ（着信者）が属する共有メモリグループに参加する。そして、通話情報設定後、Ａ（通話者）は、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態及び６．（２）に書き込まれた通話確認タイマの設定確認コール数を超えていないか否かを監視する（ステップＳ２４１）。
セットした通話確認タイマがタイムアウトした場合、Ａ（通話者）は、共有メモリ上の８．（２）に書き込まれたＢ（着信者）の転送先を読み出して、共有メモリ上の４．（１）に書き込まれたＡ（通話者）の相手電話番号を更新する（ステップＳ２４２）。
そして、Ａ（通話者）は、Ｂ（着信者）の共有メモリをクリアした後（ステップＳ２４３ 図１９のＳ４１〜Ｓ４８）、Ｃ（転送先）の共有メモリグループに参加する（ステップＳ２４４）。そして、通常の基本通話処理と同様にＣ（転送先）との通話を行う（ステップＳ２４５ 図１７のステップＳ１３〜１９を参照）。

以上説明したように、本実施形態のＩＰ電話端末によれば、共有メモリ上に通話不可時のサービス内容を設定し、不在時のサービス種別を設定しておくことにより、フレキシブルに不在時サービスを選択することができる。また、本実施形態のＩＰ電話端末によれば、共有メモリ上に何度コールしたら通話不可か設定しておくことにより、不在モード等による切り替え処理が不要となる。

次に、図面を参照して、第６の実施形態の端末の動作について説明する。図２９は、本実施形態の通話処理の過程を示すフローチャートである。
本実施形態の端末の動作が、第１〜５の実施形態と異なる点は、着呼側のＩＰ電話端末１が通話できない場合の付加サービス（オートリピート）を実行する点である。
ここで、オートリピートとは、相手が通話中だった場合に、通話が終わるまで待つサービスである。

以下、第６の実施形態の端末の動作のうち、第１〜５の実施形態と同一の部分については説明を省略し、異なる点についてのみ説明する。
第２の実施形態と同様に（図１６のステップＳ１〜６０を参照）、発呼側のＩＰ電話端末１において、着呼側のＩＰ電話端末１の電話番号が入力され、自端末の状態確認、自端末の状態変更が実行されると、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１が属する共有メモリグループに参加する（ステップＳ２５１）。
そして、発呼側のＩＰ電話端末１は、入力された着呼側のＩＰ電話端末１の電話番号をキーとして、参加した共有メモリ上に書き込まれた着呼側のＩＰ電話端末１の状態を読み出す（ステップＳ２５２）。
読み出した着呼側のＩＰ電話端末１の状態が「アイドル」であれば、第２の実施形態と同様に（図１６のステップＳ５〜８を参照）、発呼側のＩＰ電話端末１は、共有メモリ上に通話情報（電話番号、ＩＰアドレス）を設定して、通常通話処理を実行する（ステップＳ２５３）。一方、読み出した着呼側のＩＰ電話端末１の状態が「アイドル」でない場合、発呼側のＩＰ電話端末１は、発呼処理を終了せずに、着呼側のＩＰ電話端末１の次情報（次電話番号、次アドレス）に自情報（自電話番号、自アドレス）を設定する（ステップＳ２５５）。

そして、発呼側のＩＰ電話端末１は、自端末における通話断念を確認する（ステップＳ２５５）。具体的には、発呼側のＩＰ電話端末１は、自端末の受話器が下げられていないか否かを確認する。自端末の受話器が下げられている場合、発呼側のＩＰ電話端末１は、発呼処理を終了する。一方、自端末の受話器が上げられたままであれば、発呼側のＩＰ電話端末１は、共有メモリ上において着呼側のＩＰ電話端末１の状態が「通話中」に変更されるのを監視する（ステップＳ２５６）。
着呼側のＩＰ電話端末１において受話器が上げられて、共有メモリ上の着呼側のＩＰ電話端末１の状態が「通話中」に変更されると、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１と通話処理を開始する（ステップＳ２５７）。

以下、図３０を用いて、Ａ（通話者）、Ｂ（着信者）のＩＰ電話端末１の間における詳細な付加サービス処理について説明する。図２８（ａ）は、オートリピートの付加サービスを行なう場合の共有メモリ上の通話管理テーブルの構成図である。以下、簡単のため、通話者のＩＰ電話端末１をＡ（通話者）とし、着信者のＩＰ電話端末１をＢ（着信者）として記述して説明を行う。
図３０（ａ）に示すように、Ａ、Ｂが属する共有メモリグループＡ、Ｂ上の通話管理テーブルにおいて、Ａ（通話者）、Ｂ（着信者）それぞれについて、自電話番号、自アドレス、自状態、相手電話番号、相手アドレス、次電話番号、次アドレスが書き込まれる。

今、Ａ（通話者）において、Ｂ（着信者）の電話番号が入力され、自状態が「通話準備中」に更新されると、Ｂ（着信者）の電話番号で共有メモリ上の４．（１）に書き込まれた相手電話番号を更新する。
そして、Ａ（通話者）は、共有メモリグループＢに参加した後、図３０の（ｂ）に示すように、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態を読み出して、Ｂ（着信者）の状態が「通話中」であることを確認する（ステップＳ２６１）。
この場合、Ｂ（着信者）の状態が「通話中」であるため、Ａ（通話者）は、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態を「リピート中」に更新する。

次に、Ａ（通話者）は、通話が終わるまで他から割り込まれないように、待っている電話番号を共有メモリに保存する。具体的には、Ａ（通話者）は、共有メモリ上の１．（１）に書き込まれたＡ（通話者）の自電話番号を読み出して、共有メモリ上の６．（２）に書き込まれたＢ（着信者）の次電話番号を更新する（ステップＳ２６２）。また、Ａ（通話者）は、共有メモリ上の２．（１）に書き込まれたＡ（通話者）の自アドレスを読み出して、共有メモリ上の７．（２）に書き込まれたＢ（着信者）の次アドレスを更新する（ステップＳ２６３）。すなわち、Ａ（通話者）は、次に通信を行うＩＰ電話端末の電話番号とアドレスとを共有メモリ上のＢ（着信者）領域に書き込む。
そして、Ａ（通話者）は、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態が「通話中」に更新されることを監視する（ステップＳ２６４）。

一方、Ｂ（着信者）において、受話器が下げられると、通常の通話シーケンスに合流し、再接続処理が開始される（ステップＳ２７１）。すなわち、Ｂ（着信者）は、自状態が「リピート中」に設定されていることから、共有メモリ上の６．（２）に書き込まれたＢ（着信者）の次電話番号を読み出して、共有メモリ上の４．（２）に書き込まれたＢ（着信者）の相手電話番号を更新する（ステップＳ２７２）。なお、このとき、Ｂ（着信者）は、共有メモリ上の６．（２）に書き込まれたＢ（着信者）の次電話番号を初期化しておく。
次に、Ｂ（着信者）は、共有メモリ上の７．（２）に書き込まれたＢ（着信者）の次アドレスを読み出して、共有メモリ上の５．（２）に書き込まれたＢ（着信者）の相手アドレスを更新する（ステップＳ２７３）。
そして、Ｂ（着信者）は、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態を「通話準備中」に更新する（ステップＳ２７４）。

Ｂ（着信者）は、自状態更新後、鳴動処理を開始する（ステップＳ２７５）。そして、鳴動処理中において、受話器が上げられると、Ｂ（着信者）は、これをトリガとして、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態を「通話中」に更新する（ステップＳ２７６）。
Ａ（通話者）は、共有メモリ上の３．（２）に書き込まれたＢ（着信者）の状態が「通話中」に更新されたことを検出すると、共有メモリ上の３．（１）に書き込まれたＡ（通話者）の状態を「通話中」に更新する（ステップＳ２６５）。
そして、Ａ（通話者）は、状態更新後、Ｂ（着信者）へ音声データのストリーミングを開始する（ステップＳ２６６、Ｓ２７７）。

以上説明したように、本実施形態のＩＰ電話端末によれば、オートリピートの付加サービスを中継交換機を介さずに実現することができる。なお、割り込みサービス（キャッチホン相当）も本方式と同様の仕組みで可能である。

次に、図面を参照して、第７の実施形態の端末の動作について説明する。図３１は、本実施形態の通話処理の過程を示すフローチャートである。
本実施形態の端末の動作が、第１〜６の実施形態と異なる点は、着呼側のＩＰ電話端末１が通話できない場合の付加サービス（保留転送）を実行する点である。

以下、第６の実施形態の端末の動作のうち、第１〜５の実施形態と同一の部分については説明を省略し、異なる点についてのみ説明する。
発呼側のＩＰ電話端末１において、基本通話を行っている際に、通話先のＩＰ電話端末１を保留中に設定し（ステップＳ２８１，Ｓ２８２）、転送先である着呼側のＩＰ電話端末１の電話番号が入力されると（ステップＳ２８３）、基本通話中であった発呼側のＩＰ電話端末１は、入力された着呼側のＩＰ電話端末１の電話番号をキーとして、当該転送先である着呼側のＩＰ電話端末１の状態を読み出す（ステップＳ２８４）。
読み出した着呼側のＩＰ電話端末１の状態が「アイドル」であれば、発呼側のＩＰ電話端末１は、共有メモリ上に転送先情報（電話番号、ＩＰアドレス）を設定する（ステップＳ２８５）。

そして、発呼側のＩＰ電話端末１は、転送先の応答を確認する（ステップＳ２８６）。具体的には、発呼側のＩＰ電話端末１は、着呼側のＩＰ電話端末１において受話器が上げられて、共有メモリ上の着呼側のＩＰ電話端末１の状態が「通話中」に変更されると、自状態を「通話保留中」に更新する。
通話先のＩＰ電話端末１は、発呼側のＩＰ電話端末１の状態が「通話保留中」に更新されると、共有メモリ上に転送情報を設定する。具体的には、通話先のＩＰ電話端末１は、共有メモリ上の着呼側のＩＰ電話端末１の相手電話番号、相手アドレスに自電話番号、自アドレスを設定する（ステップＳ２８７）。
一方、発呼側のＩＰ電話端末１は、転送先である着呼側のＩＰ電話端末１において受話器が下げられたことを確認し（ステップＳ２８８）、再度受話器が上げられると、転送先である着呼側のＩＰ電話端末１の通話状態を共有メモリ上で設定し（ステップＳ２８９）、かつ、送信元である通話先のＩＰ電話端末１の通話状態を共有メモリ上で設定する（ステップＳ２９０）。
以上により、通話先のＩＰ電話端末１は、共有メモリ上の着呼側のＩＰ電話端末１の状態が「通話中」に変更されると、着呼側のＩＰ電話端末１と通話処理を開始する（ステップＳ２９１）。

以下、図３２を用いて、Ａ（通話者）、Ｂ（通話者）、Ｃ（転送先）のＩＰ電話端末１の間における詳細な付加サービス処理について説明する。図３２（ａ）は、保留転送の付加サービスを行う場合の共有メモリ上の通話管理テーブルの構成図である。
図３２（ａ）に示すように、Ａ〜Ｃが属する共有メモリグループＡ、Ｂ上の通話管理テーブルにおいて、Ａ（通話者）、Ｂ（通話者）、Ｃ（転送先）それぞれについて、自電話番号、自アドレス、自状態、相手電話番号、相手アドレス、仮電話番号、仮アドレスが書き込まれる。

今、Ａ（通話者）とＢ（通話者）とが通話中に、Ｂ（通話者）において、保留ボタンが押下されることをトリガとして、Ｂ（通話者）は、共有メモリ上の３．（１）に書き込まれたＡ（通話者）の状態を「保留中」に更新する（ステップＳ３０１）。また、Ｂ（通話者）は、同様に、共有メモリ上の３．（２）に書き込まれたＢ（通話者）の状態を「保留転送」に更新する（ステップＳ３０２）。
そして、Ｂ（通話者）は、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態を読み出して、Ｃ（転送先）の状態が「アイドル」であることを確認する（ステップＳ３０３）。
この場合、Ｃ（転送先）の状態が「アイドル」であるため、Ｂ（通話者）は、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態を、「アイドル」から「保留転送」に更新する（ステップＳ３０４）。

一方、Ｃ（転送先）は、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態が「保留転送」に更新されているか否かを監視し（ステップＳ３２１）、Ｃ（転送先）の状態が「保留転送」に更新された場合、さらに、共有メモリ上の７．（３）に書き込まれたＣ（転送先）の仮アドレスが初期値以外になることを監視する（ステップＳ３２２）。
Ｂ（通話者）は、共有メモリ上の１．（３）に書き込まれたＣ（転送先）の自電話番号を読み出し、これを共有メモリ上の６．（２）に書き込むことにより、Ｂ（通話者）の仮電話番号を更新するとともに、共有メモリ２．（３）に書き込まれたＣ（転送先）の自アドレスを読み出して、これを共有メモリ７．（２）に書き込むことにより、Ｂ（通話者）の仮アドレスを更新する（ステップＳ３０５）。また、Ｂ（通話者）は、共有メモリ上の４．（２）に書き込まれたＡ（通話者）の自電話番号を読み出して、共有メモリ上の６．（３）に書き込まれたＣ（転送先）の仮電話番号を更新する（ステップＳ３０６）。さらに、Ｂ（通話者）は、共有メモリ上の５．（２）に書き込まれたＡ（通話者）の自アドレスを読み出して、共有メモリ上の７．（３）に書き込まれたＣ（転送先）の仮アドレスを更新する（ステップＳ３０７）。
そして、Ｂ（通話者）は、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態が「保留通話」に更新されることを監視する（ステップＳ３０８）。

Ｃ（転送先）は、共有メモリ上の７．（３）に書き込まれたＣ（転送先）の仮アドレスが初期値以外となったことを検出し、鳴動処理を開始する（ステップＳ３２３）。そして、鳴動処理中において、受話器が上げられると、Ｃ（転送先）は、これをトリガとして、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態を「保留通話」に更新する（ステップＳ３２４）。
一方、Ｂ（通話者）は、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態が「保留通話」に更新されたことを検出し、共有メモリ上の３．（２）に書き込まれたＢ（通話者）の状態を「保留通話中」に更新する（ステップＳ３０９）。そして、Ｂ（通話者）とＣ（転送先）との間で、データのストリーミングが行われる（ステップＳ３１０，Ｓ３２５）。

一方、Ａ（通話者）は、共有メモリ上の３．（２）に書き込まれたＢ（通話者）の状態が「保留通話中」に更新されることを監視しており（ステップＳ３３１）、Ｂ（通話者）の状態が「保留通話中」に更新されたことを検出して、以下の処理を行う（ステップＳ３３２）。すなわち、Ａ（通話者）は、共有メモリ上の６．（２）に書き込まれたＢ（通話者）の仮電話番号を読み出して、共有メモリ上の４．（１）に書き込まれたＡ（通話者）の相手電話番号を更新、すなわちＣ（転送先）の自電話番号へ書き替える（図３３のステップＳ３３３）。また、Ａ（通話者）は、共有メモリ上の７．（２）に書き込まれたＢ（通話者）の仮アドレスを読み出して、共有メモリ上の５．（１）に書き込まれたＡ（通話者）の相手アドレスを更新、すなわちＣ（転送先）の自アドレスへ書き替える（ステップＳ３３３）。

一方、Ｂ（通話者）は、自端末の受話器が下ろされたことをトリガとして、以下の処理を行う（ステップＳ３１１）。すなわち、Ｂ（通話者）は、まず共有メモリ上の６．（３）に書き込まれているＡ（通話者）の自電話番号を読み出し、これを共有メモリ上の４．（３）に書き込み、７．（３）に書き込まれているＡ（通話者）の自アドレスを書き込み、共有メモリ上の３．（３）に書き込まれたＣ（転送先）の状態を「通話中」に更新する（ステップＳ３１２）。次に、Ｂ（通話者）は、共有メモリ上の３．（１）に書き込まれたＡ（通話者）の状態を「通話中」に更新する（ステップＳ３１３）。
そして、Ａ（通話者）は、状態更新後、Ｃ（転送先）へ音声データのストリーミングを開始する（ステップＳ３３５、Ｓ３２６）。

以上説明したように、本実施形態のＩＰ電話端末によれば、保留転送の付加サービスを中継交換機を介さずに実現することができる。

以上説明したようなサービス機能を各ＩＰ電話端末に追加する場合、例えば、図３４に示すように、全ＩＰ電話端末を一度オフサービス状態にして、ＰＣ端末などから追加アプリケーションをダウンロードするように構成する。このようにすれば、一度オフサービスにすることにより、サービス変更時のすれ違いによる不具合を考慮しなくて良いため、作業の簡略化が期待できる。

また、この変形例としては、図３５に示すように、アプリケーション更新用サーバを設定して、共有メモリにバージョン設定領域を作成することが考えられる。この場合、各ＩＰ電話端末が、動作の前にアプリケーションのバージョンをチェックし、サービス中にアプリケーションのバージョンを更新する。
このようにすれば、グループ毎にバージョンアップを行えるため、アプリケーション更新用サーバの負荷制御が可能である。ただし、グループ間通話で影響があるような変更の場合は、該当サービスを抑止する必要がある。したがって、この場合には、最初に全グループに該当サービスの規制フラグを設定しておく。

また、以上説明したＩＰ電話端末が故障した場合、これを検出する方法について説明する。まずＤＳＭもしくは、データ同期用サーバが、メンバ数が減少したことを検出することで故障を検出することが考えられる。
すなわち、ＤＳＭもしくは、データ同期用サーバが、ヘルスチェックやパケットの応答監視などによりメンバの消滅を検出した場合、アプリケーションにその旨を通知する。アプリケーションは、共有メモリから該当するＩＰ電話端末のクリア処理を行う。
なお、ＤＳＭの場合においては、メンバ消滅を通知されるアプリケーションが複数だった場合、共有メモリに対する無駄なクリア処理が発生する。したがって、グループ参加者内で最小のＩＰ電話端末識別子を選択する等によりメンバ内の代表者を一意に設定し、メンバ内の代表者にメンバ消滅を通知するようにして、共有メモリに対する無駄なクリア処理を防止する。

また、この変形例としては、共有メモリにカウンタ領域を設定して、そのカウンタを共有メモリにカウンタを用意して、定間隔で書き込みをおこない、一定期間変更がない場合は、故障と認識して該当データをクリアすることも考えられる。

上述の各ＩＰ電話端末は、内部に、コンピュータシステムを有している。
そして、上述した各呼処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。
すなわち、各ＩＰ電話端末における、各処理手段、処理部は、ＣＰＵ等の中央演算処理装置がＲＯＭやＲＡＭ等の主記憶装置に上記プログラムを読み出して、情報の加工・演算処理を実行することにより、実現されるものである。
ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。

本実施形態のＩＰ電話端末１による通話ネットワークシステムの構成図。 電話番号と共有メモリグループとの対応関係を示すテーブル。 電話番号と共有メモリグループとの対応関係を示すテーブル。 ダウンロードサーバへの負荷分散方式の説明図。 ダウンロードサーバへの負荷分散方式の説明図。 サービス中におけるダウンロードの説明図。 起動時チェックによるダウンロードの説明図。 起動時チェックによるダウンロードの説明図。 共有メモリグループの構成図。 共有メモリの構成図。 共有メモリへの初期登録シーケンス図。 基本通話（内線）のフローチャート。 基本通信正常シーケンス図。 相手が話中時のシーケンス図。 通話キャンセル（相手が未応答時）のシーケンス図。 基本通話（外線）のフローチャート。 基本通信正常シーケンス図。 相手が話中時のシーケンス図。 通話キャンセル（相手が未応答時）のシーケンス図。 会議電話のフローチャート。 会議電話正常シーケンス図。 会議電話正常シーケンス図。 通話割り込み可能な会議電話のフローチャート。 会議電話正常シーケンス図。 会議電話正常シーケンス図。 転送電話、留守電メールのフローチャート。 転送電話、留守電メールの正常シーケンス図。 転送電話、留守電メールの正常シーケンス図。 オートリピートのフローチャート。 オートリピート正常シーケンス図。 保留転送のフローチャート。 保留転送シーケンス図。 保留転送シーケンス図。 機能追加の説明図。 機能追加の説明図。

符号の説明

１…ＩＰ電話端末
２…ダウンロードサーバ

Claims (9)

1. ネットワークを介して接続された通話先端末の第１の識別情報を入力して前記通話先端末と通話処理を実行する端末であって、
   自端末又は前記通話先端末を含む端末の第１の識別情報と、前記ネットワークに接続された前記端末を分割した複数のグループにおいて当該端末の属しているグループとの対応関係を示すテーブルが記憶された第１の記憶手段であって、前記自端末のグループに属する前記端末により共有される第１の記憶手段の前記テーブルに基づき、前記通話先端末の前記第１の識別情報により、当該通話先端末が参加しているグループを識別し、前記通話先端末が前記自端末とは異なるグループに参加している場合には、自端末を前記通話先端末が参加しているグループに参加させるグループ参加管理手段と、
   前記通話先端末の第１の識別情報、及び、前記通話先端末の状態を記憶する、前記グループに属する端末により共有される第２の記憶手段から読み込んだ前記通話先端末の状態に基づいて、前記通話先端末の第１の識別情報から変換された前記通話先端末の第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行する通話処理手段と
   を具備することを特徴とする端末。
2. 前記通話処理手段は、前記第２の記憶手段に記憶された前記通話先端末の状態を通話準備状態に変更するとともに、前記第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行する
   ことを特徴とする請求項１に記載の端末。
3. 前記第２の記憶手段は、自端末の状態をさらに記憶し、
   前記通話処理手段は、所定の時点で前記自端末の状態を通話準備状態に変更する
   ことを特徴とする請求項２に記載の端末。
4. 前記第１または第２の記憶手段は、自端末、前記通話先端末、又は、前記ネットワークを介して接続された他の端末内のいずれかに共有記憶領域として構築される
   ことを特徴とする請求項１から請求項３のいずれかの項に記載の端末。
5. 前記第１または第２の記憶手段は、自端末、前記通話先端末、又は、前記ネットワークを介して接続された他の端末内に分散された共有記憶領域として構築される
   ことを特徴とする請求項１から請求項３のいずれかの項に記載の端末。
6. 前記通話処理手段は、さらに、前記通話先端末と自端末との間の通話処理の実行結果に基づいて、所定の転送先端末と自端末との間で通話処理を実行する
   ことを特徴とする請求項１に記載の端末。
7. 前記通話処理手段は、さらに、前記通話先端末と自端末との間の通話処理の実行結果に基づいて、所定の転送先端末への電子メール送信処理を実行する
   ことを特徴とする請求項１に記載の端末。
8. ネットワークを介して接続された通話先端末の第１の識別情報を入力して前記通話先端末と通話処理を実行する通話方法であって、
   グループ参加管理手段が、自端末又は前記通話先端末を含む端末の第１の識別情報と、前記ネットワークに接続された前記端末を分割した複数のグループにおいて当該端末の属しているグループとの対応関係を示すテーブルが記憶された第１の記憶手段であって、前記自端末のグループに属する前記端末により共有される第１の記憶手段の前記テーブルに基づき、前記通話先端末の前記第１の識別情報により、当該通話先端末が参加しているグループを識別し、前記通話先端末が前記自端末とは異なるグループに参加している場合には、自端末を前記通話先端末が参加しているグループに参加させ、
   通話処理手段が、前記通話先端末の第１の識別情報、及び、前記通話先端末の状態を記憶する、前記グループに属する端末により共有される第２の記憶手段から読み込んだ前記通話先端末の状態に基づいて、前記通話先端末の第１の識別情報から変換された前記通話先端末の第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行する
   ことを特徴とする通話方法。
9. ネットワークを介して接続された通話先端末の第１の識別情報を入力して前記通話先端末と通話処理を実行する処理をコンピュータに実行させるためのプログラムであって、
   グループ参加管理手段が、自端末又は前記通話先端末を含む端末の第１の識別情報と、前記ネットワークに接続された前記端末を分割した複数のグループにおいて当該端末の属しているグループとの対応関係を示すテーブルが記憶された第１の記憶手段であって、前記自端末のグループに属する前記端末により共有される第１の記憶手段の前記テーブルに基づき、前記通話先端末の前記第１の識別情報により、当該通話先端末が参加しているグループを識別し、前記通話先端末が前記自端末とは異なるグループに参加している場合には、自端末を前記通話先端末が参加しているグループに参加させるグループ参加管理処理と、
   通話処理手段が、前記通話先端末の第１の識別情報、及び、前記通話先端末の状態を記憶する、前記グループに属する端末により共有される第２の記憶手段から読み込んだ前記通話先端末の状態に基づいて、前記通話先端末の第１の識別情報から変換された前記通話先端末の第２の識別情報を用いて前記通話先端末を識別して、前記通話先端末と自端末との間で通話処理を実行する通話処理と
   をコンピュータに実行させるための通話プログラム。

Images