JP2007184672A - 通信制御装置 - Google Patents

Abstract

【課題】 一般電話回線を利用する内線電話とIPネットワークで接続された情報端末間で連携を取る事ができない。また，一般電話回線を利用する内線電話には，IP電話が持つ，PC上での発着信情報管理，電話帳管理の様な便利な機能がない。
【解決手段】 IPネットワーク上の情報の送受信と電話信号の送受信が可能な電話アダプタを用いて，IPネットワーク上の情報をトリガにした電話信号発信，電話信号内容のIPネットワーク上への反映等を行なうことで，一般電話回線上の電話端末と，IPネットワーク上の情報端末との橋渡しをさせる。
【効果】 一般の電話システムを利用するユーザでも容易に電話と情報端末の連携を実現でき，情報システムと電話システムの刷新タイムラグが発生した場合，IP電話システムが段階的に導入された場合においても，ユーザ全員が情報システムと電話システムの連携を最大限活用できる環境を構築できる。
【選択図】 図１

Description

本発明は電話状態の取得，及び電話設定方式に関する。

“プレゼンス”と呼ばれる概念を利用したユーザ間の状態把握技術の研究，開発が近年盛んに行われている。“プレゼンス”とはその名の如く，他ユーザに通知するための各ユーザの“存在”であり，具体的には各ユーザ又は通信装置の現在位置や現在状態，その他様々な自分の存在を示す情報である。この“プレゼンス”を他のユーザに対してリアルタイムに通知することで，お互いの現在状態を把握し，例えば，「今は相手が多忙だから連絡するのは控えよう」や「今は相手が外出しているから相手の携帯電話に連絡を入れよう」等と判断する事が可能になる。これらプレゼンスの概念と通信技術はIM(Instant Messaging)技術から発展した。IM，及びプレゼンスの概念についてはIETF(Internet Engineering Task Force)のimpp(Instant Messaging and Presence Protocol)ワーキンググループを中心に標準化が行われている（非特許文献１、２参照）。また，具体的なプレゼンス通信技術についてはimppで規定された概念を元に様々なIETFのワーキンググループで議論，標準化が行われている。例えばIETFのSIMPLE(SIP for Instant Messaging and Presence Leveraging Extensions)ではSIP(Session Initiation Protocol)を用いてプレゼンス情報の送受信を行う為の方式を検討している。

一方，企業内線網では電話信号の交換と，代理応答機能，保留機能等，各電話機能を持つPBX(Private Branch eXchange)と内線電話本体を用いて電話システムを構築している。PBXと電話端末の間の信号は通信の標準化を行う国際機関であるITU-T(International Telecommunication Union Telecommunication Standardization Sector)やその前身であるCCITT(Consultative Committee for International Telegraph and Telephone)が規定したISDN(Integrated Service Digital Network)や，アナログ信号，または各PBXベンダがこれら規格を参考にして独自拡張した信号方式でやりとりされる。また，各ユーザはコールピッキング(代理応答)やコールパーク(保留)等PBXが持つ様々な機能を電話端末から設定や利用指示をすることで利用する事が可能となる。

一般的な企業オフィスでは，各社員は机上に前記プレゼンス機能を実現する為にパソコンなどの情報端末を配置し，前記内線機能を実現する為に，内線電話を配置している。情報端末はRJ-45形式のコネクタによるイーサネット（登録商標）等でIP(Internet Protocol)ネットワークに接続し，内線電話はRJ-11形式のコネクタによる電話回線網に接続されており，これらの接続先，接続経路は全く異なる。図２０にこの様な一般的なオフィスのネットワーク接続形態例を示す。図２０では41に示すUserAと42に示すUserBがそれぞれの机上46，50の上に自分の情報端末43，47と電話端末44，48を置いている。情報端末は構内LAN等のIPネットワーク51を経由してデータセンタ53のプレゼンス送受信サーバ52と接続し，プレゼンス送受信機能を実現する。一方で電話端末は電話内線網54を経由してデータセンタ53に設置されたPBX55に接続し，電話機能を実現する。

また，近年電話回線網をIPネットワークで置き換えるVoIP(Voice over IP)の技術についての研究，開発が進み，通信キャリアやISP(Internet Service Provider)からはコンシューマ向けのIP電話サービスが，各PBXベンダからIP-PBX開発による企業向けの内線IP電話システムが展開されつつある。これらIP電話の通信技術の一つはIETFのSIPワーキンググループを中心にSIPと呼ばれるプロトコルとして標準化が行われている。また，IP電話でもIP-PBXで旧式の企業内線網が持っていた各機能を実現する事が可能であるが，それら機能の設定，及び利用指示はIP電話端末からだけではなくパソコン等の情報端末からでも可能となる。これは情報端末とIP電話端末，IP-PBXが同じIPネットワーク上に接続あされるからである。

企業向けのIP電話システムを構築する時，上記で述べた内線IP電話の技術とプレゼンス技術は同時に検討されることが多い。これは各ユーザが「IP電話で電話をしている状態」を一つのプレゼンス情報として捉え，他のユーザにその状態を通知することで，相手に今電話できるかどうかを判断することが可能になるからである。IP電話はプレゼンス技術と同様に情報の伝達経路にIPネットを利用しており，2つの技術の親和性は高い。

内線IP電話を導入した一般的な企業オフィスのネットワーク接続形態例を図１９を用いて説明する。図１９では図２０で示した電話端末44,48がそれぞれIP電話端末301，302に置き換えられており，それらIP電話端末はIPネットワーク51に接続されている。つまり情報端末もIP電話端末もRJ-45形式のコネクタによるイーサネット（登録商標）等で同じIPネットワークに接続されている。一方，PBXもIPネットワークに対応したIP-PBX 303に置き換えられており，IP電話端末同様IPネットワーク51に接続されている。この様なネットワーク形態上ではプレゼンス機能とIP内線電話機能が連携することは比較的容易である。IP-PBXは各IP内線電話端末の通話状態を管理しているので，例えばUserAの机上にあるIP電話端末301が「通話中」であるか「待機中」であるかは判断できる。そこでIP-PBXはIPネットワーク51を経由してプレゼンス送受信サーバ52にその事を通知すれば，情報端末は同じIPネットワーク51を経由してプレゼンス送受信サーバ52からそのプレゼンス情報の通知を受ける事が可能となる。具体的な方式については，特許文献１に詳細の記述がある。また，通話中であるかどうかをIP-PBX 303ではなく，301や302の様な各IP電話端末が送信することも可能である。IP電話端末もまた，IPネットワーク51に接続しているので，そこを経由してプレゼンス送受信サーバ52に自分の状態を登録すればよい。さらにIP電話端末がプレゼンス送受信サーバ52にアクセスして他ユーザのプレゼンス情報を確認することも可能である。

特開２００３−１８６１０２号公報

IETF RFC 2778 IETF RFC 2779

上記従来技術の図２０を用いて説明した企業オフィスのネットワーク接続形態では，情報端末を電話端末は物理的に全く異なるネットワークに接続され，両者は連携できない。IP電話は一般的には段階的に導入される。その時，IP電話を導入したユーザと未導入のユーザの間でサービスレベルのギャップが発生する。また，プレゼンス機能の様な先進的な情報システムとIP電話システムを同時に導入するとは限らない。その様な場合，情報システムは先進的であるにも関わらず，電話システムが旧式である為に，先端的な連携システムを利用することが出来ない。

一般電話にアダプタを適用することで，IP電話化した時と同様の連携システムを旧式の内線電話システムで実現する。このアダプタは電話をIP電話化しなくても，電話システムと情報システムの連携を実現する機能を有する。本アダプタはPBXと電話本体間を接続する電話線に接続して設置する。殆どの場合，具体的には電話端末を設置した机上，電話端末のすぐそばに設置する。また，本装置は電話線との接続口以外に，USB(Universal Serial Bus)の様なデータ伝送路を用いてパソコン等の情報端末と接続する。本アダプタは電話線から取得した電話信号と解析し，その信号内容に従い情報端末に対してプレゼンスサーバの様な情報サーバに対する動作を指示する。逆に情報端末からの指示により，電話信号を発生させ，PBXに対する設定を行う，電話端末のベルを鳴らす，等の動作を行う。また，電話線を接続して電話信号を確認するかわりに，受話器の上下を感知するセンサで受話器の動きを監視して，通話状態を確認する等，別の方法を用いて机上の電話端末の状態を確認することもある。さらにアダプタが情報端末を接続せず，直接IPネットワークに接続し，プレゼンスサーバの様な情報サーバとのデータ送受信を行う場合もある。

IP電話システムを導入していないユーザでもプレゼンス機能等の情報システムとの連携や，パソコン等の情報端末経由での電話機能設定を行う事が可能となる。企業が段階的にIP電話導入した場合，情報システムとIP電話システムの導入のタイミングにギャップが生じた場合でも，各ユーザはIP電話と同レベルの情報システム連携機能を利用する事が可能となる。

本実施例では，まず，本願発明の電話アダプタの物理的構造，論理的構造，動作概要，及びそのアダプタを適用した企業オフィスの実際のネットワーク接続形態例について説明する。その後，シーケンス図，及びPC上のディスプレイ表示例，メッセージ例を用いて，本願発明の電話アダプタの具体的な活用例を説明する。

図１には本願発明の電話アダプタの物理的構成例を示した。また，図２には本願発明の電話アダプタの機能ブロック図を示した。図２の機能ブロック図は，論理的な機能構成を示した図であるが，各機能ブロックについてはソフトウェア，ハードウェアどちらで構成しても構わない。

図２で示した機能ブロックがもしソフトウェアで実現される場合，その処理内容については，図１のメモリ４内にある処理モジュール群６に格納され，機能実行時にはCPU３がこれらデータをデータバス７経由で呼び出し，その処理手順に従い処理を進める。また，各処理に必要なデータはメモリ４の設定記憶テーブル５に格納されており，必要に応じてデータバス７を経由してテーブルの読み出し，書き込みを行う。本実施例では電話信号の処理については電話信号処理部２でハードウェア処理を行い，IPネットワークに対する信号処理についてはソフトウェア処理を行うこととして動作例を説明する。

図５，６は本願発明の電話アダプタの動作フローチャート図である。これらの図と図１，２のブロック図を用いてアダプタの動作概要を説明する。本願発明の電話アダプタは2パターンの動作を行う。一つは電話信号を受信し，その内容に応じて情報端末へのインターフェース，もしくはIPネットワーク側に信号を発信するパターンであり，もう一つは情報端末へのインターフェース，もしくはIPネットワーク側から信号を受信して，その内容に応じて電話信号を発信するパターンである。図５は前者の動作を説明し，図６は後者の動作を説明している。

まずは図５の処理について説明する。本願発明の電話アダプタは，図５のステップ７１で，図１の電話信号IF(PBX側)８，もしくは電話信号IF(端末側)９から電話信号処理部２内部にある，図２の電話信号情報送受信機能２２の電話信号受信部３０で電話信号を受信すると，ステップ７２で処理を開始する。その後，電話信号処理部２の電話信号解析部２５はステップ７３で受信した電話信号が電話アダプタの動作トリガとなる内容であるかを確認する。

もし，動作トリガとなる信号内容でないと判断した場合，ステップ７７に処理をすすめ処理を終了する。その際，受信した電話信号は電話信号処理部２の内部にある電話信号送受信機能２２の電話信号送信部２９から電話信号IF(PBX側)８，もしくは電話信号IF(端末側)９を経由して電話信号をそのままの形で送信する。もし電話信号を８からPBX側の電話信号IF８から受信した場合は端末側の電話信号IF９から電話信号を送信する。逆の場合は送受信IFが逆になる。尚，電話信号が電話アダプタの動作トリガとなり，電話アダプタが動作した後にステップ７７で処理を終了した場合でも電話信号は上記と同様にそのままの形で送信する。

もしステップ７３で電話信号が電話アダプタの動作トリガとなる内容であると判断した場合，電話信号処理部２の内部にある電話信号解析部２５は図１のデータバス７を経由して，その信号内容をメモリ４の設定記憶テーブル５に格納して，処理はステップ７４に進む。

ステップ７４では図１の情報処理部２１にある相互通知判断部２４がさらに信号解析を進める。相互通知処理部２４はメモリ４の設定記憶テーブル５から先ほど格納された電話信号を取り出し，その信号内容を解析することにより，他のIFにそれを通知する必要があるかどうかを判断する。もし必要で無いと判断した場合，処理はステップ７７に進み処理が終了する。必要だと判断した場合，ステップ７５に進む。

ステップ７５では信号生成部２８が通知するメッセージを作成する。その後ステップ７６において，情報システム信号送受信部２３の送信部３２が外部へメッセージを通知する。そしてステップ７７で処理が終了する。

次に図６の処理について説明する。本願発明の電話アダプタは図６のステップ８１で図１のIF１０から図２の情報システム信号送受信機能２３の受信部３１でパソコン等の情報端末やIPネットワークからの信号を受信すると，ステップ８２で処理を開始する。その後，ステップ８３において図２の情報処理部２１の信号解析部２７は受信した信号が電話アダプタの動作トリガとなる内容であるかを確認する。もし，動作トリガとなる信号内容でないと判断した場合，ステップ８７に処理を進め処理を終了する。もし，動作トリガとなる信号内容であると判断した場合，信号内容を図１のメモリ４，設定記憶テーブル５の内部に格納し，ステップ８４へ処理を進める。

ステップ８４では図２の情報処理部２１内にある相互通知判断部２７が先ほど設定記憶テーブル５に格納した信号内容を読み出し，さらに信号解析を進める。相互通知処理部２４は電話信号のIFに受信した信号を通知する必要があるかどうかを判断し，もし必要が無いと判断した場合，ステップ８７に進み処理を終了する。もし必要があると判断した場合はステップ８５に進む。

ステップ８５では図２の情報処理部２１内にある電話信号生成部２６が通知する電話信号を作成する。その後，ステップ８６で図１の電話信号情報送受信機能２２内にある電話信号送信部２９が図１の電話信号IF(PBX側)８，もしくは電話信号IF(端末側)９から電話信号を発信し，ステップ８７で処理が終了する。

この様に，本願発明の電話アダプタは外部からの信号受信時に，「信号受信」，「内容解析」，「通知要不要判断」「通知」の４つのサイクルで動作する。受信，送信する信号の種別や解析の方法，通知要不要判断の内容については特に限定しない。

図３は本願発明の電話アダプタを実際の企業オフィスに設置した時のネットワーク接続形態例を示した図である。本例の４１に示すUserAと４２に示すUserBは情報システムは最先端のシステムを利用し，電話システムについては電話網とPBXを利用したものを利用している。例えば，UserA４１が利用する電話アダプタはUserAの机４６上にある電話端末４４のすぐそばに４５の様な形で配置される。また電話アダプタ４５は電話端末４４のほかに電話線で電話内線網５４を経由してデータセンタ５３にあるPBX５５と接続されており，さらに，USB等の信号線により情報端末４３とも接続されている。情報端末４３はRJ-45形式等のイーサネット（登録商標）によりIPネットワーク５１に接続されている。UserB４２の机についても同様である。この様な形態で本願発明の電話アダプタは設置される。

図４は電話アダプタ設置の別の例である。この図の設置例で図３と異なる部分は，例えばUserA４１の電話アダプタ６１が情報端末４３とは接続していない点である。電話アダプタ６１はRJ-45形式のイーサネット（登録商標）の接続口を持っており，直接IPネットワーク５１に接続する事が可能となっている。UserB４２についても同様である。この様に，電話アダプタは本願発明の動作内容を満たすことが出来れば，情報システムへの接続形態を問わない。

図７は本願発明の電話アダプタの動作例を示したシーケンス図である。本例は図４に示す様なネットワーク接続形態での動作例である。図７の例ではUserBがUserAのプレゼンス情報を見ている時，UserAがUserB以外の他のユーザに対して電話発信を行い，通話を開始する。その時，電話アダプタがプレゼンス送受信サーバ５２にその旨を通知することにより，UserBはUserAが電話中になった通知を受ける例である。また，UserAが通話を終了した場合も同様であり，その情報がプレゼンス情報としてプレゼンス送受信サーバ５２からUserBに通知される。本例の詳細な動作についてシーケンス図を順に追いながら説明する。

図７ではまず，UserAの情報端末４３，UserBの情報端末４４がステップ９１，及び９２でプレゼンス送受信サーバ５２にログインする。その後，UserBの情報端末４７はステップ９３で，UserAの現在のプレゼンス情報，及びその後のプレゼンス情報の変化の通知を受ける為にプレゼンス情報送受信サーバ５２に対してUserAにサブスクライブしたいことを示すメッセージを送信する。ステップ９４ではUserAのサブスクライブが認められて現在のUserAのプレゼンス情報がプレゼンス送受信サーバ５２からUserBの情報端末４７に送信されている。この様にして各ユーザは他のユーザのプレゼンス情報を見るために，サブスクライブ希望のメッセージをプレゼンス送受信サーバ５２に送信する。

その後，ステップ９５でUserAが自分の電話端末４４からある他のユーザに電話を送信したとする。その時，UserAの机上にある電話アダプタ61はステップ９６でその電話発信の信号を受信する。電話アダプタはこの電話信号受信により，図５に示すフローチャートに沿った処理を開始する。本例では電話アダプタの動作トリガとなる電話信号を「通話が始まった時」，「通話が終った時」と設定する。よって図５のステップ７３，動作トリガとなる電話信号か？の部分では”N”と判断され，ステップ７７で処理が終了される。その際に送信した電話信号は図７のステップ９７でPBX５５に送信されている。その後，その信号はステップ９８でPBXから発信先ユーザの電話端末に送信され，ステップ９９で発信先ユーザが受話器を取る事により，それに対する応答がPBX５５に対して送信される。その信号がPBX５５を経由してステップ100でUserAの電話アダプタ61に送信される。すると，電話アダプタ61はステップ101でその信号を受信し，再度，図５に示すフローチャートに従い動作する。但し，この時は本信号が電話アダプタの動作トリガとなる信号である為，図５のステップ７３で次のステップに進みさらにステップ７４で通知することを判断する。その後，ステップ７５，７６でメッセージを作成，送信することで，図７のステップ１０３の様にプレゼンス送受信サーバ５２に対してメッセージを送信する。

但し，本例は図４のネットワーク接続形態の場合の動作であり，図３の様な接続形態の場合，電話アダプタがプレゼンス情報送受信サーバ52に直接メッセージを送信するのではなく，電話アダプタ45はまず，UserAの情報端末43にメッセージ送信をUSB等の情報信号線経由で指示し，実際にはUserAの情報端末43がプレゼンス情報送受信サーバ52にプレゼンス情報を登録する形になる。

図７のステップ95電話発信から102までの通話開始までの具体的なシーケンス例を図８のステップ１２５からステップ１３８までに示した。図８のシーケンス図はISDN加入者信号方式である。図８を説明しながら電話アダプタ61が取得し，動作トリガとする具体的な電話信号を説明する。

図８ではまず発側ISDN端末121が着側ISDN端末124に対して電話発信する為に発側交換機１２２に向かってステップ１２５で”SETUP”信号を送信する。すると発側交換機１２２は着側交換機１２３に向かってその事を通知する為に”INITIAL ADDRESS MESSAGE(以後IAMと略す)”信号を送信する。その際，ステップ１２６で発側ISDN端末１２１には”SETUP”信号を受信したことを示す”CALL PROCEEDING(以後CALL PROCと略す)”信号を送信する。その後，着側交換機１２３は”IAM”信号を受信，着信を着側ISDN端末１２４に通知する為に”SETUP”信号をステップ１２９で送信し，それと同時に”ACM”信号を発側交換機122に送信する。着側ISDN端末１２４は”SETUP”信号を受信し，”SETUP”受信を通知する”CALL PROC”信号をステップ１３０で着側交換機１２３に返信する。その後，着側ISDN端末のベルが鳴り，着信が在る事がユーザに伝えられる。それと同時にベルを鳴らしたことをステップ１３１の”ALERTING”信号，ステップ１３２の”CALL PROGRESS MESSAGE(以後CPGと略す)”信号，ステップ１３３の”ALERTING”信号により，発側ISDN端末１２１に告げられる。その後，着側ISDN端末１２４が受話器を取るとステップ１３４で”CONNECT”信号が着側交換機１２３に送信され，着側交換機はそれをステップ１３６で”ANSWER MESSAGE(以後ANMと略す)”信号として発側交換機１２２に転送，同時に”CONNECT”信号を受信したことを示す”CONNECT ACK”信号を着側ISDN端末１２４に返信する。さらに発側交換機１２２は”ANM”信号をステップ１３７で”CONNECT”信号として発側ISDN端末１２１に転送，発側ISDN端末がそれを受けたことを告げる”CONNECT ACK”信号を発側交換機１２２に返信し，ステップ139で通話が始まる。

図８の発側ISDN端末１２１は図７でのUserAの電話端末４４，図８の発側交換機１２２は図７でのPBX５５と考える事ができる。つまり，電話アダプタ61は図８での発側ISDN端末１２１と発側交換機１２２の間に設置し，その間の電話信号を受信する形となる。図８で通話が始まることを示す信号はステップ１３７の”CONNECT”信号である。よって，図７の動作例では，電話アダプタ61はこの”CONNECT”信号の受信を動作トリガと判断し，処理を進める。本明細書ではISDN加入者信号を例にトリガとなる信号を説明したが，「通話が始まる」事を示す信号であれば，特にその信号の種類は問わない。また，電話アダプタ61はUserAの電話端末44とPBX55の間で送受信される電話信号，図８の例でのステップ125，ステップ126，ステップ133，ステップ137，ステップ138，全ての信号を受信しているが，動作トリガ以外の信号については図５のフローチャートのステップ73で”動作トリガの信号ではない”と判断し，処理を終了し，電話信号をスルーさせている。

また，図９には図７のステップ１０３でUserAの電話アダプタ61がプレゼンス送受信サーバ５２に対して送信するUserAが通話中であることを示すメッセージの例を示した。この図では例としてIETFのSIP WG，及びSIMPLE WGで標準化が議論されているSIPのPUBLISHメッセージ，及びPIDFのプレゼンス情報記述を挙げている。図９の１５１がSIPメッセージ例であり，１５２がプレゼンス情報の記述例である。本メッセージに例えば１５３の様に”phoneStatus”が”通話中”であることを記述し，メッセージを送信する。本例ではSIP/SIMPLEの場合を例にして説明をしたが，送信するメッセージについて，そのプロトコル，フォーマットは問わない。

図７のシーケンスの説明に戻る。ステップ１０３でUserAの状態を受取ったプレゼンス送受信サーバ５２はその事をステップ１０４でUserBの情報端末４７に通知する。それにより，UserBはUserAが電話で通話中になった事が分かる。

その後，UserAの電話端末44はステップ105での通話を終了し，ステップ106で通話終了の電話信号をPBX55に対して送信する。電話アダプタ61はその信号をステップ107で受信する。ステップ107の信号は「通話が終った時」を示す信号なので，図５のフローチャートで処理を行い，その事をプレゼンス情報としてステップ110でプレゼンス送受信サーバ52に送信する。また，電話信号はそのままの形でステップ108でPBX55に転送し，PBX55はステップ109でその信号を発信先の電話端末に転送，さらにステップ110でUserAのプレゼンス情報に変化が合ったことが分かったプレゼンス送受信サーバ52はステップ111でその事をUserBの情報端末47に送信する。それにより，UserBはUserAの電話が終ったことをが分かり，例えば，UserBがUserAに電話したいが，UserAが電話中だったので待っていた場合には，そのタイミングでUserAに電話をかける事ができる。

図８のISDN加入者信号のシーケンス図を用いて，図７のステップ106からステップ109までの信号の具体的な説明をする。図８ではステップ139の通話が終了する時，発側ISDN端末121はステップ140で”DISCONNECT(以後DISCと略す)”信号を発側交換機122に送信する。発側交換機はその信号を着側交換機123にステップ143の”RELEASE(以後RELと略す)”信号で転送する。また，それと同時に発側ISDN端末に対しても”REL”信号を返信し，発側ISDN端末はさらに”RELEASE COMPLETE(以後REL COMPと略す)”信号を発側交換機に返信する。着側交換機は発側交換機の”REL”信号を受信すると，着側ISDN端末124にその信号をステップ144の”DISC”信号で転送する。その時着側交換機はステップ144で”RELEASE COMPLETE MESSAGE(以後RLCと略す)”信号を返信する。着側ISDN端末124は”DISC”信号を受信するとステップ146で”REL”信号を着側交換機に返信，着側交換機はさらにステップ147で”REL COMP”信号を着側ISDN端末に返信する。図7のUserAの電話端末44を図8の発側ISDN端末121と見ると，電話アダプタ61はステップ140，ステップ141，ステップ142の信号を受信しているが，その中で「通話が終った時」を示す信号はステップ140の”DISC”信号である。よって電話アダプタ61はこの”DISC”信号受信を動作トリガとして図５のフローチャートの処理を進める。本明細書ではISDN加入者信号を例にトリガとなる信号を説明したが，通話開始時と同様「通話が終わる」事を示す信号であれば，特にその信号の種類は問わない。

また，通話終了時にステップ110で電話アダプタ61がプレゼンス送受信サーバ52に送信するメッセージは図９の153の部分を例えば”待機中”と記述したメッセージとなる。本メッセージについてもそのプロトコル，フォーマットは問わない。

実施例１では電話信号を解析するので，解析パターンを増やすことで様々な電話端末の状態を把握することが可能となり，設計によっては本例の通話状態以外の状態についても把握することが可能となる。

図１０，図１１は図７の動作例を異なる形式の電話アダプタで実現した場合の例である。本例では電話アダプタは電話信号の受信により，動作トリガを発するのではなく，図１０の下図の様に電話機のフック902のそばに受話器センサ901を配置し，受話器903によりフックが上下するのと同時にセンサもそれを感知するような仕組みを持ち，受話器の上下により，動作トリガを発する仕組みとなっている。また，その仕組みに合わせて電話アダプタの物理的構造も図１０の上図の様な形になっている。図１との違いは図１の電話信号処理部２，電話信号IF(PBX側)８，電話信号IF(端末側)９の代わりに，受話器センサ151は配置され，信号処理相当の機能を担当している。

図１１は本例のシーケンス図である。本例の動作をこのシーケンスを追いながら説明する。ステップ161からステップ164までは図７の例と同様である。その後UserAは他ユーザに電話発信する為に，ステップ165でUserAの電話端末44の受話器を上げる。するとフックのそばについている受話器センサ901がそれを感知し，それをトリガとして，電話アダプタ180の処理が始まる。電話アダプタ180は，受話器が上がったことをステップ167でプレゼンス送受信サーバ52に通知する。その後，プレゼンス送受信サーバ52はステップ168でその事をUserBの情報端末47に通知する。

受話器を上げた後，UserAはステップ169で他ユーザに対して電話発信を行うが，本例ではその信号は電話アダプタ180を経由しない。

通話終了時の動作も同様であり，ステップ174でUserAが電話端末44の受話器を置くと，その事をステップ175で電話アダプタ180が感知，その事をステップ176でプレゼンス送受信サーバ52に送信し，ステップ177でUserBの情報端末47に通知される。ステップ176から177までのメッセージについては図７の例と同様である。

この様に本願発明の電話アダプタは電話信号からのみではなく他の手段によって，各ユーザの電話端末の状態を監視しても良い。他の手段を用いることで電話信号を解析する機能を実装せずに電話端末の状態を監視できる。

図１２は本願発明の第2の活用例を示すシーケンス図である。図１２では各電話アダプタが自分が担当する電話端末に呼び出しがあった際，その事をプレゼンス送受信サーバに送信し，周りのユーザが，今どの電話端末のベルが鳴っているかを判断できる例である。本例についてシーケンスを追いながら説明する。尚，本例は図４の様なネットワーク接続形態上での例とする。本例では電話アダプタは，動作トリガを図５の様な形で電話信号側から発生させ，「電話の呼び出しがあった時」を条件として動作する。

本例ではまず，ステップ181でUserBの情報端末がプレゼンス送受信サーバ52にログインする。その後自分のフロアIDにサブスクライブを行う。例えば自分の居室が3F 301号室であればそのIDに対してサブスクライブを行う。これにより，電話がどの部分で鳴っているかについてのプレゼンス情報を受信する事が可能になる。その後，そのサブスクライブがプレゼンス送受信サーバ52で認められると，ステップ183で現在の該当フロアの状態がUserBの情報端末47に送信される。その後，ステップ184で外部からUserAの電話端末44に呼び出しがかかったとする。その信号はPBX55を経由してステップ185でUserAの電話アダプタ61にその信号が送信される。ステップ186で電話アダプタ61は呼び出し信号を検知，図５のフローチャートのステップ73で動作トリガとなる電話信号と判断し，次のステップに進み，結果，ステップ188で呼び出しがかかっていることをプレゼンス送受信サーバ52に送信する。また，ステップ187で受信した電話信号をそのままUserAの電話端末44に転送する。その後プレゼンス送受信サーバ52は，ステップ189でUserBの情報端末187に電話が鳴っていることを通知し，その結果，UserBの情報端末のディスプレイ190には191の様にどの部分の電話が現在鳴っているかが表示される。

図８のISDN加入者信号の例では電話の呼び出しがかかっていることを示す信号は電話発信先のUserAの電話端末44を着側ISDN端末124と考えると，ステップ129の”SETUP”信号である。但し，これも図７の例と同様，相手の呼び出しに相当する信号なら信号の種類は問わない。

実施例３により，代理応答などを行った時の元の発信先の特定が容易となるが，本例ではPBXに特殊な機能を入れることなく，コールが発生している電話機を特定することが可能であることが特徴である。

図１３は本願発明の第3の活用例を示すシーケンス図である。図１３では各ユーザが自分の電話端末でPBXに対して不在設定(対象電話に発信した時，PBXから不在の旨が通知される設定)や転送設定(対象電話に発信した時，設定された番号の他電話端末に発信が転送される設定)等の設定を行った時，電話アダプタが信号を受信し，プレゼンス送受信サーバに送信することで，電話への設定をプレゼンス情報として他ユーザに公開する例である。本例についてシーケンスを追いながら説明する。尚，本例は図４の様なネットワーク接続形態上での例とする。また，本例は図３の様なネットワーク接続形態の場合でも実現可能であり，その場合，図７の場合と同様，電話アダプタは情報端末にUSB等の情報信号線経由で設定の要求を出し，実際にプレゼンス送受信サーバとのメッセージ送受信を行うのは情報端末となる。本例では電話アダプタは，動作トリガを図５の様な形で電話信号側から発生させ，「電話端末がPBXに対して何かを設定した時」を条件として動作する。

本例ではまず，ステップ202からステップ204までの動作でUserBの情報端末47がプレゼンス送受信サーバ52にログインする。本シーケンスは図7のステップ92から94までと同様である。その後，ステップ205でUserAが電話端末44からPBX55に対して電話の設定を行う。UserAの電話アダプタ61はその信号をステップ206で感知する。その後，図５のステップ72で動作トリガとなる電話信号であると判断して，ステップ208で電話端末44がPBX55に対して設定した内容に応じたプレゼンス情報をプレゼンス送受信サーバ52に登録する。例えば，電話の不在設定を行った場合，UserAの現在状態を”不在”とするプレゼンス情報を登録するし，UserAが電話の不在設定を解く設定をした場合，UserAの現在状態を”在席”とするプレゼンス情報を登録する。プレゼンス送受信サーバ52はその後，ステップ209でUserAの現在状態が変わった事をUserBの情報端末47に通知する。その結果，UserBの情報端末のディスプレイ210にはUserAの状態が表示される。例えば，UserAが電話の転送設定を行った場合は図１３の様にUserAが不在であり，電話をかけると”090-2341-2343”に転送される事が表示される。

実施例４により，各ユーザが電話端末を用いて電話交換機の設定を行なうだけで，無意識的に情報システムの設定も更新することが可能となる。

図１４は本願発明の第4の活用例を示すシーケンス図である。図１４では各ユーザが自分の情報端末でプレゼンス送受信サーバに対してプレゼンス情報を登録した時，情報端末が電話アダプタに信号を発信し，その結果，電話アダプタが情報端末で設定したプレゼンス情報に応じた電話設定を電話信号によりPBXに対して行う例である。本例についてシーケンスを追いながら説明する。尚，本例は図３の様なネットワーク接続形態上での例とする。本例では電話アダプタは，動作トリガを図６の様な形で情報端末側から発生させ，「情報端末が電話信号による設定を要求してきた時」を条件として動作する。

本例ではまず，ステップ221からステップ224まででUserAの情報端末43とUserBの情報端末47がプレゼンス送受信サーバ52にログインしUserBの情報端末47はさらにUserAのプレゼンス情報を取得する。本シーケンスの動作については図７のステップ91からステップ94までのシーケンスと同様である。その後，ステップ225でUserAがUserAの情報端末43からプレゼンス送受信サーバ52に対してプレゼンス情報を登録したとする。もちろん，その情報はステップ226でプレゼンス送受信サーバ52からUserBの情報端末47に通知され，結果UserBの情報端末のディスプレイは231の様に表示されるが，さらにステップ227でUserAの情報端末43はUserAの電話アダプタ45に対してPBXに対して同様の設定をするように要求を出す。電話アダプタ45は図６のフローチャートを実行し，ステップ83で動作トリガとなる外部メッセージであると判断し，その後の処理を進め，図１４のステップ228で電話端末44の代わりにPBX55に対して電話信号を発信し，PBX55はUserAの電話端末44の設定を変更する。例えば，UserAが現在状態を”不在(転送)”とプレゼンス送受信サーバ52に設定した場合，それに応じて電話アダプタ45はPBX55に対して電話の転送設定を行う。その結果，UserBがステップ229でUserAに対して電話発信した場合，PBX55はステップ230の様にUserAの転送先番号に発信信号を転送する。

実施例５により，各ユーザが情報端末を用いてプレゼンスサーバ等に対して情報設定を行なうだけで，無意識的にPBXの設定も更新することが可能となる。

図１５は本願発明の第5の活用例を示すシーケンス図である。図１５ではUserAの電話アダプタがUserA自身のプレゼンス状態を監視している。その後，例えば，UserAが自分の居室から退室し，その事をセンサ等別のデバイスから感知した時，それがUserAの電話アダプタにプレゼンス情報として通知され，その結果電話アダプタがPBXに対して電話の不在設定や転送設定を行う例である。尚，本例は図４の様なネットワーク接続形態上での例とする。本例では電話アダプタは，動作トリガを図６の様な形でIPネットワーク側から発生させ，「対象ユーザの状態がある状態に変化した時」を条件として動作する。

本例ではまず，ステップ241からステップ243まででUserAの情報端末43がプレゼンス送受信サーバ52にログインしUserAのプレゼンス情報を取得する。本シーケンスの動作については図７のステップ91からステップ94までのシーケンスと同様である。その後，ステップ244で各社員の居室入退室を管理する様なサーバがUserAの退室を検知して，その事をステップ245でプレゼンス送受信サーバ52に通知したとする。プレゼンス送受信サーバ52はUserAが退室したことをUserAにサブスクライブしているUserAの電話アダプタ61に通知する。そこで電話アダプタ61は図６のフローチャートを実行し，ステップ83で動作トリガとなる外部メッセージであると判断し，その後の処理を進め，図１５のステップ247で電話端末44の代わりにPBX55に対して電話信号を発信し，PBX55はUserAの電話端末44の設定を変更する。例えば，UserAが退室したことをプレゼンス送受信サーバ52から通知された場合，それに応じて電話アダプタ61はPBX55に対して電話の転送設定を行う。その結果，UserBがステップ248でUserAに対して電話発信した場合，PBX55はステップ249の様にUserAの転送先番号に発信信号を転送する。

実施例6では，プレゼンス送受信サーバの状態を監視することで，例えば，センサ等から自動的に登録されたプレゼンス情報により電話設定を変更できる。センサは各ユーザが意識することなく，情報を取得し，プレゼンス送受信サーバにその状態を送信する。よって，各ユーザは自らが意識的に設定を行なうことなく，PBXに電話の設定を行なうことが可能となる。

図１６は本願発明の第6の活用例を示すシーケンス図である。図１６ではUserAがUserBに電話発信したが，相手が電話中だった時，その事を情報端末に通知し，情報端末がUserBのプレゼンス状態を取得し，UserBの通話が終了して，その通知を受けた時に電話アダプタに対して擬似コールをする要求を発信，これらの処理によりUserBの通話が終了したことを電話端末を利用して通知する例である。尚，本例は図３の様なネットワーク接続形態上での例とする。但し，図４の様なネットワーク接続形態上でも実現可能であり，その場合，UserBのプレゼンス状態を電話アダプタ自身が取得し，UserBの通話が終了した時に自身が擬似コールすることを判断する形で実現する。本例では電話アダプタは，動作トリガを図５の様な形で電話信号側から発生させ，「話中の信号を受けた時」を条件として動作する。さらに，動作トリガを図６の様な形で情報端末側からも発生させ，「擬似コール要求を受けた時」を条件して動作する。

本例ではまず，ステップ251からステップ252でUserA，UserBの電話アダプタがそれぞれプレゼンス送受信サーバ52にログインする。ログインについては図７の例と同様である。その後，ステップ253でUserAが電話端末44を利用してUserBに電話発信する。ところが，UserBは現在話し中で中継したPBX55からはステップ254でUserBが話中であることを示す信号が返信されてきたとする。電話アダプタ45はその信号をステップ255で受信し，図５のフローチャートを実行，ステップ73で動作トリガとなる電話信号と判断し，処理を進め，結果，ステップ257でUserAの情報端末43にUserAがUserBに電話したが話中であったことを通知する。情報端末43はその通知を受け，ステップ258でUserBの通話終了を監視するために，プレゼンス送受信サーバ52に対してUserBのプレゼンス情報を取得したいことを示すサブスクライブメッセージを送信する。その後，UserBはステップ259で通話を終了したとする。その時，ステップ259の信号をUserBの電話アダプタ48がステップ260で受信し，図５のフローチャートの処理を開始し，結果ステップ262で通話が終了したことをプレゼンス送受信サーバ52に通知する。その際，通話終了の電話信号は，ステップ261の様にそのままの形で電話アダプタ48からUserBの電話端末49に転送される。プレゼンス送受信サーバ52は電話アダプタ48からの通知を受け，その事をステップ263でUserAの情報端末43に通知する。通知を受けた情報端末43はステップ264でUserAの電話アダプタ45に対して擬似コールをするように要求を出す。その結果，電話アダプタ45はUserAの電話端末44に対して擬似コールを行うことにより，UserBの通話が終了したことをUserAに音で通知する。

本例のように電話アダプタをプレゼンス情報が更新された時の通知手段として利用する事も可能である。プレゼンス情報が変化した瞬間にその事を知りたい場合，情報端末のディスプレイ上でいくらそれを通知しても本人がディスプレイを見ていない限りその事が伝わらない。しかし，電話を鳴らして聴覚に訴えることで，より確実にプレゼンスの変化を通知することが可能となる。

図１７は本願発明の第7の活用例を示すシーケンス図である。図１７ではUserAがUserBに電話発信した時に，UserAの電話アダプタがその事をプレゼンス送受信サーバに通知し，それをUserBの情報端末に通知することで，UserBの電話コールが誰からかをUserBが判断できる，いわゆる「ナンバーディスプレイ」の機能を電話アダプタで実現する例である。電話アダプタと情報端末の組み合わせにより，ナンバーディスプレイ機能の無い電話でもナンバーディスプレイ相当の機能を持つ事が可能となる。尚，本例は図４の様なネットワーク接続形態上での例とする。但し，図３の様なネットワーク接続形態上でも実現可能であり，その場合，図７の場合と同様，電話アダプタは情報端末にUSB等の情報信号線経由で設定の要求を出し，実際にプレゼンス送受信サーバにメッセージ送信を行うのは情報端末となる。本例では電話アダプタは，動作トリガを図５の様な形で電話信号側から発生させ，「電話発信を受けた時」を条件として動作する。

本例ではまず，ステップ272でUserBの情報端末がプレゼンス送受信サーバにログインする。その時のシーケンスは図７と同様である。その後，ステップ273でUserAが電話端末44がUserBに対して電話発信した時，UserAの電話アダプタ61はステップ274でその信号を受信し，図５のフローチャートの処理を開始し，ステップ73で動作トリガとなる電話信号であると判断する。そして，その後の処理により，UserAがUserBに電話呼び出しをしていることをステップ276でプレゼンス送受信サーバ52に通知する。プレゼンス送受信サーバ52はその事をステップ277でUserBの情報端末に通知し，その結果，UserBの情報端末のディスプレイ278にはUserAから電話が発信されていることを表示する。

本実施例の最大の特徴はPBXにナンバーディスプレイの機能を導入せずに，その機能を実現するところにある。

図１８は本願発明の第8の活用例を示すシーケンス図である。図１８ではUserAに対して電話発信した他ユーザの電話アダプタがその事をプレゼンス送受信サーバに登録し，その情報をUserAが確認することで着信履歴表示を実現する例である。尚，本例は図４の様なネットワーク接続形態上での例とする。但し，図３の様なネットワーク接続形態上でも実現可能であり，その場合，各電話アダプタが情報端末に対して発信履歴登録要求をUSB等の情報信号線等で発信し，実際にプレゼンス送受信サーバと通信するのは情報端末となる。また，本例ではプレゼンス送受信サーバを用いて履歴の送受信を行っているが，他のサーバでも本例と同じ機能を満たせば特に問題ない。本例では電話アダプタは，動作トリガを図５の様な形で電話信号側から発生させ，「電話発信を受けた時」を条件として動作する。

本例では，まず，ステップ281でUserAの情報端末43がプレゼンス送受信サーバ52にログインする。本動作は図７の例のログインと同様である。その後，ステップ282でUserBの電話端末49がUserAに電話発信したとする。すると，UserBの電話アダプタ62はステップ283でその電話信号を受信し，図５のフローチャートの処理を開始し，ステップ73で動作トリガとなる電話信号であると判断する。そして，その後の処理により，UserBがUserAに電話発信したことをプレゼンス送受信サーバ52に登録する。また，それと同時にステップ284で電話アダプタ62は受信した電話信号をそのままの形でPBX55に転送する。その後，ステップ286でさらにUserCが電話端末293を利用してUserAに電話発信したとする。すると，UserBの場合と同様に，ステップ287でUserCの電話アダプタ292がその電話信号を受信し，ステップ289でUserCがUserAに電話発信したことをプレゼンス送受信サーバ52に登録し，ステップ288で電話信号をそのまま転送する。その後UserAがステップ290で情報端末43を使いプレゼンス送受信サーバ52にアクセスし，自分に対する着信履歴を取得しようとすると，その応答がステップ291で返信され，情報端末のディスプレイに294の様に表示される。

また，本例ではUserB，UserCの電話発信者側に設置された電話アダプタがUserAへの発信記録を登録しているが，逆にUserAの電話アダプタがUserB，UserCからの着信履歴を登録する形式でも本例は実現可能である。

本実施例の最大の特徴は従来型のPBXと一般的な電話を利用している場合でも，IP電話(ソフトフォン)が実現している様な，PC上で発着信履歴確認を実現できるところにある。

本願発明における電話アダプタの装置図である。 本願発明における電話アダプタの機能ブロック図である。 本願発明装置のネットワーク接続形態例である。 本願発明装置のネットワーク接続形態例である。 本願発明装置のフローチャート図である。 本願発明装置のフローチャート図である。 本願発明装置の活用例を示すシーケンス図である。 本願発明装置が利用する電話信号例を示すシーケンス図である。 本願発明装置が発信するメッセージ例である。 本願発明における電話アダプタの装置図である。 本願発明装置の活用例を示すシーケンス図である。 本願発明装置の活用例を示すシーケンス図と表示例である。 本願発明装置の活用例を示すシーケンス図と表示例である。 本願発明装置の活用例を示すシーケンス図と表示例である。 本願発明装置の活用例を示すシーケンス図である。 本願発明装置の活用例を示すシーケンス図である。 本願発明装置の活用例を示すシーケンス図と表示例である。 本願発明装置の活用例を示すシーケンス図と表示例である。 一般的な情報端末とIP電話端末のネットワーク接続形態例である。 一般的な情報端末と電話端末のネットワーク接続形態例である。

符号の説明

１・・・電話アダプタ
２・・・電話信号処理部
３・・・CPU
４・・・メモリ
５・・・設定記憶テーブル
６・・・処理モジュール群
７・・・データバス
８・・・電話信号インターフェース（PBX側）
９・・・電話信号インターフェース（端末側）
１０・・・インターフェース。

Claims (18)

1. 電話端末及び呼制御装置と接続された通信制御装置であって、
   上記電話端末と上記呼制御装置の間の通信データを受信する受信部と、
   該通信データを解析し、上記電話端末の状態を取得し、該状態を他の通信装置に通知する制御部とを有する通信制御装置。
2. 請求項１記載の通信制御装置であって、
   上記通信データを解析する代わりに、上記電話端末の受話器の上げ、下げ、またはボタンの押し下げのうち少なくともいずれか一つの物理的な動作を検知することにより、上記電話端末の状態を取得することを特徴とする通信制御装置。
3. 請求項１記載の通信制御装置であって、
   上記他の通信装置は、情報端末であり、
   上記情報端末と該通信制御装置とを接続する信号線を経由して上記通知を行うことを特徴とする通信制御装置。
4. 請求項１記載の通信制御装置であって、
   上記他の通信装置は、サーバ装置であり、
   上記サーバ装置と該通信制御装置とを接続する信号線を経由して上記通知を行うことを特徴とする通信制御装置。
5. 請求項１記載の通信制御装置であって、
   上記電話端末の状態とは、該電話端末の通話状況のことであることを特徴とする通信制御装置。
6. 請求項１記載の通信制御装置であって、
   上記電話端末の状態とは、該電話端末のフックの上下の状態であることを特徴とする通信制御装置。
7. 請求項１記載の通信制御装置であって、
   上記電話端末の状態とは、該電話端末からの発信状態、該発信の発信先の情報、該発信の発信元の情報、該電話端末の着信状態、該着信の発信先の情報、該着信の発信元の情報のうち少なくともいずれか一つであることを特徴とする通信制御装置。
8. 請求項１記載の通信制御装置であって、
   上記電話端末の状態とは、該電話端末が上記呼制御装置に対して行った設定の状態および内容であることを特徴とする通信制御装置。
9. 請求項１記載の通信制御装置であって、
   上記電話端末の状態とは、該電話端末の発信に対する電話中応答を受信した状態であることを特徴とする通信制御装置。
10. 電話端末に接続された通信制御装置であって、
    該電話端末以外の装置からの信号を受信する受信部と、
    該信号に基づき電話信号を発信する制御部を有する通信制御装置。
11. 請求項１０記載の通信制御装置であって、
    上記電話端末以外の装置とは、該通信制御装置と信号線で接続された情報端末であることを特徴とする通信制御装置。
12. 請求項１１記載の通信制御装置であって、
    上記電話端末以外の装置とは、該通信制御装置とネットワーク信号線で接続されたサーバであることを特徴とする通信制御装置。
13. 請求項１２記載の通信制御装置であって、
    上記サーバから受信した信号に基づき、自ら動作内容を判断して、上記電話信号を発信することを特徴とする通信制御装置。
14. 請求項１０記載の通信制御装置であって、
    上記電話信号の発信先が呼制御装置であることを特徴とする通信制御装置。
15. 請求項１０記載の通信制御装置であって、
    上記電話信号の発信先が上記電話端末であることを特徴とする通信制御装置。
16. 請求項１０記載の通信制御装置であって、
    上記電話信号の発信先が上記電話端末及び上記呼制御装置の両方であることを特徴とする通信制御装置。
17. 請求項１０記載の通信制御装置であって、
    上記電話端末以外の装置からの信号とは、上記呼制御装置に対する電話設定要求であることを特徴とする通信制御装置
18. 請求項１０記載の通信制御装置であって、
    上記電話端末以外の装置からの信号とは、サーバから送信されたプレゼンス情報であることを特徴とする通信制御装置。
    

Images