JP2009021669A - 電話システム、サーバおよび代理応答電話機 - Google Patents

Abstract

【課題】ソフトフォン利用者やフリーアドレス制の職場でも適切に代理応答サービスが提供でき、かつ利用者の状況に応じた柔軟性の高い代理応答機能の実現方法およびそのシステムを提供すること
【解決手段】宛先確認部を代理応答電話機に設け、代理応答電話機宛に掛かってきた呼が、自番号宛の呼なのか、不在転送による呼なのかを判別する。不在転送による呼の判別に於いてさらに何番宛の呼なのかを識別して受信操作を行うことで、複数ユーザ環境での利用が可能となる。
【選択図】図５

Description

本発明は、インターネットプロトコル（ＩＰ）に基づいて動作する電話システム、サーバおよび代理応答電話機に係り、特に、ソフトフォン利用が多いＩＰ電話環境に対する利便性の高い電話システム、サーバおよび代理応答電話機に関する。

近年、ＩＰ電話が急速に普及している。また、それに伴い付帯する様々なサービスを提供するシステムや仕組みが発明されている。その中に着信側が不在の時にメッセージを自動的に録音する機能を提供する留守録システムがある。

留守録システムの基本的な構成と仕組みについて、特許文献１に従来技術として記載された図２を参照して説明する。この図において、集中制御装置は、いわゆる電話交換機の役割を果たし電話端末同士の呼制御を行う。通信ネットワークの端末Ａから発信者ａが送信先端末Ｂを呼出す場合、端末Ａは、（１）端末Ｂ呼出信号を発信し集中制御装置の交換機または呼制御サーバにアクセスし、（２）集中制御装置は、端末Ｂを検出・接続して端末Ｂ呼出信号を送信、（３）端末Ｂが呼出信号に一定時間応答しない場合、前記集中制御装置は端末Ｂ無応答を確認し、前記集中制御装置は、（４）端末Ｂ無応答に呼応して集中的にボイス情報を記憶するボイスメールサーバに端末Ａを接続、（５）端末Ａとボイスメールサーバとの間を通信可能に通信ルートを設定、（６）端末Ａの発信者ａからのボイス情報は、ボイスメールサーバに送信・記録され、（７）中央制御装置は端末Ｂにボイス情報が記録された事を通知し（８）ボイスメールサーバに前記ボイス情報記録済の端末Ｂ表示を受信者は確認すると、端末Ｂから前記集中制御装置に接続しボイスメールサーバを呼出して記録されたボイス情報を要求し、（９）端末Ｂ宛のボイス情報が検出されて、（１０）ボイス情報は、前記集中制御装置を介し端末Ｂに送信・再生されて受信者はボイス情報を確認する。

なお、ここではボイスメールサーバとして説明しているが同様の機能を提供するものに留守録サーバあり、ほぼ同じ手法のシステムである。
以上のような一般的なボイスメールサーバシステムにおいて一辺倒な留守録処理だけでなく、より利便性を高めたものに、特許文献２に記載の手法がある。この手法は、前述の説明でのボイスメールサーバにあたるＷｅｂサーバにおいて、サーバ利用者が細かい設定を登録することにより、ユーザが不在の場合に電話を取る前に発信者の伝言メッセージを録音することなどが出来る。

一方で、特許文献３のように、ＩＰアドレスに基づいて管理されるＩＰ電話端末に内蔵されるＲＡＭ部のボイスメール記録領域に、発信者のボイスデータ（メッセージ情報）を記録し保存することにより、利便性を改善するボイスメールシステムが知られている。つまり、発信者からのメッセージ情報を、集中的にメッセージ情報を記憶するサーバ側ではなく、電話端末側に保存させる手法である。

また一方で、ネットワークシステムの進化やＩＰ電話に代表されるコミュニケーション機器の進化により、企業のワークスタイルにも変革がおきている。従業員に固定の席を用意せず、従業員は毎日違う机で仕事が行えるフリーアドレス制と言われるワークスタイルである。フリーアドレスによれば、従業員は、その日の気分や、業務プロジェクトに応じて自由に席を変更するといった、レイアウトフリーなオフィススタイルが可能となる。フリーアドレスでは、パーソナルコンピュータ（以下、ＰＣと略す）にインストールして利用するソフトフォンが利用される。ＰＣとソフトフォンを使うためのハンドセットとネットワークに接続できる環境さえあれば、どこの席であってもパソコンを繋いだ場所が自席環境となるからであり、ソフトフォンであれば固定電話機の位置による束縛を解消することができる。フリーアドレス制が導入された先進的なオフィスでは、従業員全員にノート型ＰＣとソフトフォンが支給され、オフィス内には各グループの机の島に補助的に固定電話機が１〜数台設置することが一般的である。

特許文献４には、呼制御情報にある何れかの識別情報を判定して、判定結果に応じて着信パターンを変える発明が記載されている。
特許文献５には、アナログのＰＢＸに接続するタイプのセンタ収容方留守録装置が記載されている。
特許文献６および特許文献７には、１台の電話機に複数の電話番号を設け、番号ごとに異なる着信音を設ける発明が記載されている。
特許文献８には、着呼を受けて該当者のスケジュールをスケジュール管理部に確認し、その情報に基づいて、着信、留守録または転送する判定動作をする発明が記載されている。

特開２００６−０８１０８８号公報 特開２００６−０５０２７０号公報 特開２００３−１１０７４２号公報 特開昭６３−２４５０４６号公報 特開平０５−０９５４２２号公報 特開平１１−２３４４１０号公報 特開２００４−０９６１９４号公報 特開２００６−２１７１４８号公報

ソフトフォン利用環境での留守録システムの動作について、図１を参照して説明する。ここで、図１はソフトフォン利用者が不在のときの電話システムの動作を説明するブロック図である。図１は、受信者ｂが利用するＩＰ電話はソフトフォンで、受信者ｂが不在のために端末Ｂは起動していない状態を表している。この状態で端末Ａから端末Ｂへの発呼を説明すると以下の通りとなる。まず（１）端末Ａは、端末Ｂ呼出信号をテレフォニーサーバへ発信する。（２）テレフォニーサーバは、端末Ｂに接続するためのＩＰアドレスを自信に格納されるテーブルから解決しようとする。しかし、（３）テレフォニーサーバは、端末Ｂが起動していないため接続先のＩＰアドレスが解決できない。そこで、（４）テレフォニーサーバは、端末Ｂの不在転送先として登録されている宛先を確認し、（５）端末Ａとの呼接続を設定し、（６）留守録サーバとの呼接続を設定する。（７）留守録サーバは、メッセージ情報を保存する。

ソフトフォン利用者の多い職場環境で留守録システムの利用を考えた場合、留守録サーバの導入による不在時の転送処理では、起動していないソフトフォン宛にかけられた電話は不在転送先に指定された留守録サーバへ転送されることになる。ソフトフォン利用者が緊急な都合で出社が１時間遅れる事になった場合、特許文献１の図２の環境であったならば、端末Ｂが鳴動するので、職場に連絡してその旨を伝えておけば、その人の電話端末宛に電話が掛かってきた場合、状況に応じて代理応答を行い都合で１時間遅れてくる旨の伝言を職場の者が代理で伝えられる。しかし、ソフトフォン利用者の職場で、留守録サーバを導入してしまうと、着信できない通話は無条件に留守録サーバへ転送されることになる。この結果、不在者宛てに電話があったことすら、職場の他の人には判別できなくなってしまう。

この様な問題に対処するには、ソフトフォンが起動していない場合は、一端職場にある別の電話機に転送して、一定時間応答がない場合に、さらに留守録サーバへ転送して留守録処理を行わせるという手法が考えられる。この様な運用では、職場単位での電話の取りこぼし問題には効果的だが、留守録サーバを設置することによる無駄な電話の取り次ぎや代理応答を減らしたいという本来の目的からはずれてしまう。また電話を掛けている方は、その間呼出し待ち時間が長くなってしまう問題もある。

また、前述の様な場合に、ソフトフォン利用者が一時的に留守録サーバへ転送するか職場の別の電話機に転送するのかをテレフォニーサーバ宛へ設定変更して対応する手法も考えられる。しかし、いちいち手動による設定変更をしなくてはならず、柔軟性に欠け、設定変更の戻し忘れなどの新たな課題も発生する。

特許文献２に記載の手法では、ソフトフォンが多数を占めるような環境は想定されておらず、発呼先の電話機が起動していない場合については考えられていない。
特許文献３に記載の電話端末にボイスメールデータを保存しておく方式での対応を考えた場合、まず根本的な課題として、ソフトフォンでは端末の電源が入っていなければそもそもメッセージを受けることが出来ない。また、不在転送先として職場の補助的に設置されている固定電話を指定し、その固定電話に特許文献３に記載の手法を採用すれば、確かにメッセージ情報を保存することが可能となる。しかし、このときソフトフォンと固定電話機が１対１で対応していないので、複数の電話端末に対するメッセージ情報が１台の固定電話に保存されることになり、誰宛のメッセージかが判らない。

更に、大規模ＩＰ電話システムにおいて代理応答／留守録機能を提供するには、規模に見合ったサーバの構築や設置などが必要なため経済的なハードルが高い。オフィスのフロアやグループ単位での簡易的な代理応答機能の提供が望まれている。

本発明の課題は、このような問題点を解決し、ソフトフォン利用者やフリーアドレス制の職場でも適切に代理応答サービスが提供でき、かつ利用者の状況に応じた柔軟性の高い代理応答機能の実現方法およびそのシステムを提供することである。

上述した課題は、ＩＰ電話機と、ＩＰ代理応答電話機と、ＩＰ電話機とＩＰ代理応答電話機との発着信を制御するサーバとからなり、サーバは、ＩＰ電話機宛ての着呼があったとき、ＩＰ電話機の状態を判定し、ＩＰ電話機が着呼できないと判定したとき、ＩＰ電話機の識別子を付与してＩＰ代理応答電話機に着呼を転送する電話システムにより、解決できる。

また、ＩＰ電話機とＩＰ代理応答電話機と接続され、ＩＰ電話機とＩＰ代理応答電話機との発着信を制御し、ＩＰ電話機宛ての着呼があったとき、ＩＰ電話機の状態を判定し、ＩＰ電話機が着呼できないと判定したとき、ＩＰ電話機の識別子を付与してＩＰ代理応答電話機に着呼を転送するサーバにより、解決できる。

さらに、ネットワークを介して、ＩＰ電話機とテレフォニーサーバと接続され、テレフォニーサーバからＩＮＶＩＴＥメッセージを受信したとき、ＩＮＶＩＴＥメッセージを解析して、転送された着呼かＩＰ代理応答電話機宛ての着呼かを判定し、判定結果に基づいて鳴動音を出力するＩＰ代理応答電話機により、解決できる。

本発明によれば、ソフトフォンが起動していない番号宛に電話が発信され予めテレフォニーサーバに登録されている不在転送先に着信転送されたとき、電話機の着信パターンによって、電話機の利用者が転送か否か判別ができる。

以下、この発明の実施の形態について、実施例を用い図面を参照しながら説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。

図２は、留守録システムが適用されたネットワークを示すブロック図である。図２において、ＩＰ電話端末などがＬＡＮ（Local Area Network）１７、ＷＡＮ（Wide Area Network）１８などのＩＰネットワークを介して接続されている。ＩＰ電話端末にはさまざまなタイプがあり、ＬＡＮに直接接続できる固定型ＩＰ電話機（図示せず）や、ＰＣ１３、１４上にソフトフォンと呼ばれる電話アプリケーションプログラム１５（以下、ソフトフォンと記す）にスピーカ・マイクがついたハンドセット１６を接続したＩＰ電話端末や、留守録サービスを提供する固定ＩＰ電話機型の留守録電話機１０などがある。テレフォニーサーバ１１は、ＩＰ電話システム内のＩＰ電話端末（留守録電話機１０、ＰＣ１３、１４）を管理し、これら電話端末間の通話のための呼制御を行うものである。ＩＰ電話システム構築時には、すべてのＩＰ電話端末（留守録電話機１０、ＰＣ１３、１４）にＩＰアドレスと電話番号を割当てる必要がある。ここでは、留守録電話機１０にＩＰアドレス１０．１．２０．１０と電話番号２０１０が、ＰＣ１３にＩＰアドレス１０．１．２０．６と電話番号２００６が、ＰＣ１４にＩＰアドレス１０．１．３０．１と電話番号３００１が割り当てられている。また、テレフォニーサーバ１１にはＩＰアドレス１０．２．１．１０が割り当てられている。また、テレフォニーサーバ１１にもこれら端末の設定情報（ＩＰアドレス、電話番号等）を管理情報として登録しておく必要がある（図３にて説明）。これらの設定内容の整合性が取られることによりＩＰ電話システムとして機能するようになる。

図３は、テレフォニーサーバに登録された管理情報テーブルを説明する図である。図３において、管理情報テーブル５０には各ＩＰ電話端末を識別する電話番号５１、テレフォニーサーバ１１へ接続登録するときにその端末の正当性を判断するためのパスワード５２、ＩＰネットワーク上での端末位置を特定するためのＩＰアドレス５３、ＩＰ電話端末の状態を記録するためのステータス５４、電話番号に紐付けされたＩＰ電話端末が接続されていないときや話中などで接続できないときの転送先を指定する不在転送先５５という情報が登録されている。なお、ステータス５４のUn-Resistは不在、Busyは話中、Resistは在席で非話中である。すなわち、ステータス５４が、Un-ResistまたはBusyのとき、テレフォニーサーバ１１は、電話番号２０１０の留守録電話機１０に呼を転送する。

図４は、留守録電話機のハードウェアブロック図である。図４において、留守録電話機１０は、バス２８を介して、装置全体の制御を行うＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、音声ＣＯＤＥＣ２４、不揮発性記憶装置２５、入出力デバイス・インターフェース（以下、Ｉ／Ｆと略す）２６、ネットワークＩ／Ｆ２７が接続されている。また入出力デバイスＩ／Ｆには、スピーカ３１とマイク３２から構成される受話器３０、ディスプレイ３３、操作ボタン３４が接続されている。

図５は、留守録電話機の機能ブロック図である。図５において、デバイス制御部４１は、入出力デバイスＩ／Ｆ２６を介して、受話器３０等の各デバイスを制御する。音声処理部４２は、音声ＣＯＤＥＣ２４を介して音声情報の符号化処理と符号化されたビットデータの復号化処理などを制御する。通信処理部４３は、ネットワークＩ／Ｆ２７を介してネットワークの通信処理を制御する。宛先確認部４４は、ＳＩＰ（Session Initiation Protocol）（以下、ＳＩＰと記す）により受信したＩＮＶＩＴＥメッセージに記述された宛先情報を読み取り、その情報に従った処理の実行を制御する。留守録処理部４５は、宛先確認部４４での処理結果に基づき不在メッセージの送信、メッセージ録音処理やメッセージ確認処理などの制御を行う。なお、宛先確認部４４が関係する処理は、図１０などで更に詳細な説明を行う。

図６は、留守録電話機の斜視図である。留守録電話機１０は、受話器３０、ディスプレイ３３、操作ボタン３４、代理応答機能が割り当てられた操作ボタン３５、着信時などに光で知らせるランプ３６、ＬＡＮケーブルを繋ぐためのＬＡＮコネクタ３７などにより構成されるものである。

ここで、ＳＩＰプロトコルについて説明する。ＳＩＰプロトコルは、ＩＰ電話に代表される通話制御プロトコルの一つで、インターネットの標準化団体であるＩＥＴＦ（Internet Engineering Task Force）で標準化が行われ、２００２年に発行されたＲＦＣ３２６１においてスタンダードトラックとして規定されたプロトコルであり、その後も様々な拡張がＲＦＣとして規定されている。ＳＩＰプロトコルにおけるメッセージは、テキストで記述されシンプルで拡張性が高い。

図７を参照して、ＳＩＰメッセージにおける基本フォーマットを説明する。ここで、図７はＳＩＰメッセージにおける基本フォーマットである。基本フォーマット１００は、３段に分かれており、リクエストを表すＲｅｑｕｅｓｔ−ｌｉｎｅ１１０、宛先や発信元などの情報が記されるＨｅａｄｅｒ−Ｌｉｎｅ１２０、処理できる機能などを記述するＭｅｓｓａｇｅ−Ｂｏｄｙ１３０からなる。また、Ｈｅａｄｅｒ−Ｌｉｎｅ１２０、Ｍｅｓｓａｇｅ−Ｂｏｄｙ１３０は、必要に応じて省略や拡張ができる。

Ｒｅｑｕｅｓｔ−ｌｉｎｅ１１０は、Ｍｅｔｈｏｄ１１１と、Ｒｅｑｅｓｔ−ＵＲＩ１１２と、ＳＩＰ−Ｖｅｒｓｉｏｎ１１３とから構成される。Ｈｅａｄｅｒ−Ｌｉｎｅ１２０は、Ｆｒｏｍヘッダ１２１と、Ｔｏヘッダ１２２、Ｖｉａヘッダ１２３と、Ｃａｌｌ−ＩＤヘッダ１２４等から構成される。

図８および図９を参照して、ＳＩＰプロトコルにおいてＩＰ電話端末などから送出されるＩＮＶＩＴＥメッセージを説明する。ここで、図８はＩＮＶＩＴＥメッセージを説明する図である。図９はＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダを用いたＩＮＶＩＴＥメッセージを説明する図である。

図８において、ＩＮＶＩＴＥメッセージ６０の１行目にはリクエスト文が記述され、２００５番への呼接続を要求する１文が記載されている。以下、Ｆｒｏｍヘッダには発信元情報が、Ｔｏヘッダには宛先情報が示されている。このＩＮＶＩＴＥメッセージ６０では、３００３番から２００５番への呼接続要求を意味している。

次に、ＳＩＰメッセージにおける発信元情報と宛先情報の特定方法について説明する。図８において、発信元情報と宛先情報をＦｒｏｍヘッダとＴｏヘッダから判断したが、例えば電話の転送処理や代理受信などを行った場合、それでは必ずしも正しい情報が得られない場合がある。具体的には、呼接続に対して、２００５番が応答せず図３に示す登録情報に従い２０１０番に不在転送された場合、Ｔｏヘッダの情報が２０１０番に書き換えられてしまい、受信した２０１０番側では元の宛先情報が判断できないという問題が起きる場合がある。しかしこの様な問題に対しては、本来の宛先情報を知らせるため手順がＳＩＰプロトコルの拡張などで幾つか規定されており、その手法は数通りが存在している。ここでは、その幾つかの手法の中からＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダを用いた宛先情報の特定方法を用いて説明する。

図９を参照して、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダを用いたＩＮＶＩＴＥメッセージを説明する。図９において、ＩＮＶＩＴＥメッセージ６０Ａの１行目にはリクエスト文が記述され、２０１０番への呼接続を要求する１文が記載されている。以下、Ｆｒｏｍヘッダには発信元情報が、Ｔｏヘッダには宛先情報が示されている。このＩＮＶＩＴＥメッセージ６０Ａでは、３００３番から２０１０番への呼接続要求に見えるが、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダを参照すると、宛先情報の遷移が記録されているので、電話番号２００５から電話番号２０１０に転送されていることが分かる。

次に、処理手順等を以下、図１０から図１３を用いて説明する。ここで、図１０は、留守録電話機における着信時の処理フローチャートである。図１１は留守録データ情報テーブルを説明する図である。図１２は留守録電話機のディスプレイ表示である。図１３は発呼電話機とテレフォニーサーバと留守録電話機との間の不在転送処理のシーケンス図である。

図１０のフローは、留守録電話機１０に電源が入り、ＩＰアドレスや電話番号などの設定が正しく行われ、ＩＰ電話端末としての機能を始めた際に開始される。留守録電話機１０は、ステップ１０１において、着信を示すＩＮＶＩＴＥメッセージを受信したかを判定し、受信していない場合（Ｓ１０１；Ｎｏ）は受信するまでその判定を繰り返す。留守録電話機１０は、ステップ１０１で受信した場合は、ＩＮＶＩＴＥメッセージ中にＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダがあるかの判定を行う（Ｓ１０２）。Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダがあった場合（Ｓ１０２；Ｙｅｓ）、留守録電話機１０は、Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダに記される最初の宛先番号を取り出す（Ｓ１０３）。Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダがなかった場合（Ｓ１０２；Ｎｏ）、留守録電話機１０は、Ｔｏヘッダに記される宛先番号を取り出す（Ｓ１０４）。

次に、留守録電話機１０は、前処理で取り出した宛先番号が自端末の電話番号と同じかを判定し（Ｓ１０５）、同じだった場合（Ｓ１０５；Ｙｅｓ）、通常通りの着信音を鳴らし着呼を知らせる（Ｓ１０６）。一方、取り出した宛先番号が自端末の電話番号と違った場合（Ｓ１０５；Ｎｏ）、留守録電話機１０は、不在転送による着信であることを知らせる通常着信音とは違うパターンの着信音を鳴らす（Ｓ１０７）。留守録電話機１０は、ステップ１０６での呼出しに対してオフフックになったかの判定を行い（Ｓ１０８）、オフフックになった場合（Ｓ１０８；Ｙｅｓ）、相手との通話処理を開始する（Ｓ１０９）。一方、ステップ１０７での呼出しに対して、留守録電話機１０は、事前に設定されている時間の間にオフフックになったかの判定を行い（Ｓ１１０）、もしもオフフックになった場合（Ｓ１０８；Ｙｅｓ）、留守録電話機１０は、ステップ１０９に遷移する。

オフフックにならずに設定の時間が経過した場合（Ｓ１１０；Ｎｏ）、留守録電話機１０は、自動オフフックを行い（Ｓ１１１）、ステップ１０３またはステップ１０４で取り出した宛先情報を留守録データ情報テーブルに記録する（Ｓ１１２）。また、留守録電話機１０は、相手へ不在メッセージを送信し（Ｓ１１３）、相手からのメッセージを受け付けて録音処理を行う（Ｓ１１４）。メッセージの録音処理が終わったら、留守録電話機１０は、録音したファイルの情報や発信者情報などを留守録データ情報テーブルに紐付けして記録し（Ｓ１１５）、電話を切る（Ｓ１１７）。またステップ１０８にて事前に設定されている時間の間にオフフックにならない場合（Ｓ１０８；Ｎｏ）、留守録データ情報テーブルステップ１１１に移り留守録処理のフローに入る。

また、ステップ１０９にて相手との通話の後、ステップ１１６においてオンフックの判定をＹｅｓの判定がでるまで行い、オンフックになった場合（Ｓ１１６；Ｙｅｓ）、ステップ１１７にて電話を切りフローを終える。
なお本フローにおけるステップ１０２から１０５までのステップが、図５の宛先確認部４４が実施する処理となる。

図１１を参照して、図１０のステップ１１２とステップ１１５にて、留守録電話機１０の不揮発性記憶装置２５に保存される留守録データ情報テーブルを説明する。留守録データ情報テーブル７０は、図１０のステップ１１２にて宛先番号７１と、発番号通知情報から発番号７２と、着信時刻７３と記録される。また図１０のステップ１１４にて、発信者からのメッセージ録音があったとき、メッセージ保存がある旨の情報をメッセージ保存７４に書き込み、ステップ１１５にて保存されたファイル名を保存ファイル名７５を記録する。これによって、ファイル名と留守録データ情報テーブル７０の紐付けができる。最後の確認７６の欄は、不在着信数やメッセージを利用者が確認したかどうかを記録する情報欄である。なお、この確認７６の詳細利用方法や意味については、図１４および図１５にて記載する。

また図１２は、留守録電話機１０のディスプレイ３３における表示であり、図１０のステップ１１３の時点の表示を表したものである。ディスプレイ表示の最上部には、留守録着信中であることを表すメッセージが表示され、続いてステップ１１２にて記録された宛先情報と、発信者番号通知機能による発信者番号を表示する。これによって、複数の電話端末の留守録処理を留守録電話機１０が１台で受け持っても、誰宛の不在者転送の着信で、誰から掛かってきたのかが一目で判る。このため、代理応答の必要有無が瞬時に判断できる。

図１３を参照して、電話機Ｂ（３００１番）から電話機Ａ（２００５番）へ電話を掛けるが、電話機Ａが起動しておらず、留守録電話機（２０１０番）に不在転送されて留守録処理が行われる動作を説明する。

まず、電話機Ｂの利用者が電話機Ａの利用者宛へ連絡するため２００５番をダイヤルすると、電話機Ｂはテレフォニーサーバに電話番号を送信する（Ｓ２０１）。テレフォニーサーバは、３００１番からの呼接続要求を受け、情報管理テーブル５０から、２００５番のアドレス解決を行うが、電話番号２００５のステータス５４が、Ｕｎ−Ｒｅｇｉｓｔ（起動していない）状態であったため、不在転送先５５の宛先を確認し（Ｓ２０３）、「Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダに２００５番への呼接続処理履歴を記載して、２０１０番宛へ呼接続要求を送る（Ｓ２０４）。呼接続要求を受け取った２０１０番の留守録電話機１０は、呼接続要求のＩＮＶＩＴＥメッセージから宛先判定を行い（Ｓ２０６）、その判定結果から代理応答としてオフフックする（Ｓ２０７）。テレフォニーサーバ１１は、留守録電話機１０のオフフックを受け、留守録電話機１０と電話機Ｂ１４とを接続する（Ｓ２０８）。この状態で呼接続における通話が成立する。

しかし、留守録電話機１０は、留守録処理のために自動で代理応答したため、呼び出し相手が不在である旨のメッセージを送信する（Ｓ２１０）。留守録電話機１０は、相手の伝言メッセージを受け付けて録音する（Ｓ２１１）。その後、発呼者の操作により、電話機Ｂ１４が切断要求をテレフォニーサーバ１１に切断要求を送信する（Ｓ２１２）。テレフォニーサーバ１１は、切断要求を留守録電話機１０に送信する（Ｓ２１３）。留守録電話機１０は、電話を切る（オンフック：Ｓ２１４）。テレフォニーサーバ１１は、オフフックを電話機Ｂ１４に転送し（Ｓ２１５）、一連の呼制御処理が完了する。

上述した実施例に拠れば、テレフォニーサーバ１１の情報管理テーブルの不在転送先として留守録電話機１０を指定しておくだけで、適切に留守録処理が行え、さらに起動していないソフトフォン宛の電話の場合も職場の者が柔軟に代理応答することが可能となる留守録システムを提供することが出来る。

最後に、留守録電話機１１に記録された録音メッセージの確認方法を図１４と図１５を用いて説明する。ここで、図１４は電話機Ａと留守番電話機１０との間の留守録メッセージ確認時のシーケンス図である。また、図１５は留守録メッセージ確認時の留守録電話機１１の処理フローチャートである。

図１４において、留守録電話機１０は、ここでは、電話機ボタンの「＊」ボタンのＰＢ音を受信すると以降に受信した入力されたキーをコマンドとして解釈する仕様の留守録電話機であるとする。また、図示の簡便のため、テレフォニーサーバの記載を省くが、呼接続と呼切断にはテレフォニーサーバが介在する。

２０１０番の留守録電話機を不在転送先として登録している利用者が自身宛の録音メッセージを確認するために、電話機Ａを操作して、２０１０番に電話を掛ける。この時に電話番号に続いて「＊」ボタンを押して予め決められた録音メッセージの確認コマンド（ここでは「１３１」とする）を押す。電話機Ａは、２０１０＊１３１を留守録電話機１０に送信する（Ｓ３０１）。留守録電話機１０は、コマンドを判定して録音メッセージ確認処理に入る（Ｓ３０２）。コマンドを受け取った留守録電話機１０は、操作ユーザを確認するためにＩＤ番号（ここでは利用者の「電話番号＝ＩＤ」とする）を要求する（Ｓ３０３。操作ユーザが自身のＩＤをダイヤルすると、電話機Ａは、＊２００５を留守録電話機１０に送信する（Ｓ３０４）。留守録電話機１０は、ＩＤを受信しＩＤの正当性を確認するためにパスワード（以下、ＰＡＳＳと略す）を要求する（Ｓ３０５）。操作ユーザがＰＡＳＳをダイヤルすると、電話機Ａは、パスワードである＊１３９７８６を留守録電話機１０に送信する（Ｓ３０６）。留守録電話機１０は、ＰＡＳＳを受信し登録情報と照会する（Ｓ３０７）。ここでは、ＩＤとＰＡＳＳが合致しているので、留守録電話機１０は、操作ユーザが確認していない不在着信件数と録音メッセージ件数を読みだして、電話機Ａに送信する（Ｓ３０９）。ここで、操作ユーザがメッセージの再生要求をするコマンドを押すことにより、電話機Ａは、再生要求を留守録電話機１０に送信する（Ｓ３１０）。留守録電話機１０は、再生要求コマンドを受信し、メッセージを再生する（Ｓ３１２）。操作ユーザはメッセージを確認し、受話器と置くのを受けて、電話機Ａは、終了通知を留守録電話機１０に送信する（Ｓ３１３）。終了通知を受信した留守録電話機１０は、留守録データ情報テーブル７０に確認済みを示す情報を書き込んで処理を終える。

図１５を参照して、留守録メッセージ確認時の留守録電話機１１の処理フローを説明する。具体的には、図４の留守録処理部４５の処理フローである。留守録電話機１０が着信した際に本フローが開始される。まず、留守録処理部４５は、図１４で説明したコマンドを受信したかを判定し（Ｓ４０１）、コマンドの受信がない場合（Ｓ４０１；Ｎｏ）は本フローを終える。コマンドを受信した場合（Ｓ４０１；Ｙｅｓ）、留守録処理部４５は、相手側の操作ユーザにＩＤの入力を要求し（Ｓ４０２）、その受信を判定する（Ｓ４０３）。ＩＤの受信がない場合（Ｓ４０３；Ｎｏ）、留守録処理部４５は、その受信を待つ。ＩＤを受信した場合（Ｓ４０３；Ｙｅｓ）、留守録処理部４５は、ＰＡＳＳの入力を要求し（Ｓ４０４）、その受信を判定する（Ｓ４０５）。ＰＡＳＳの受信がない場合（Ｓ４０５；Ｎｏ）、留守録処理部４５は、その受信を待つ。ＰＡＳＳを受信した場合（Ｓ４０５；Ｙｅｓ）、留守録処理部４５は、ＩＤとＰＡＳＳの照会を行う（Ｓ４０６）。留守録処理部４５は、ＰＡＳＳが正しいか判定し（Ｓ４０７）、照会の結果が正しければ（Ｓ４０７；Ｙｅｓ）、該当ユーザの不在着信件数と録音メッセージ件数を通知する（Ｓ４０８）。照会の結果が正しくなければ（Ｓ４０７；Ｎｏ）、留守録処理部４５は、本フローを終える。

留守録処理部４５は、未確認の録音メッセージがあるかを判定する（Ｓ４１０）。メッセージがある場合（Ｓ４１０；Ｙｅｓ）、留守録処理部４５は、未確認メッセージの再生処理を行い（Ｓ４１１）、再生したメッセージに確認ビットを立てて（Ｓ４１２）、そのメッセージを削除するか確認する（Ｓ４１３）。ステップ４１３でＹｅｓなら、留守録処理部４５は、メッセージファイルを消去し、Ｎｏ（Ｓ４１３；Ｎｏ）なら削除せず、ステップ４１０に戻る。未確認メッセージがなくなったら（ステップ４１０；Ｎｏ）、留守録処理部４５は、未確認メッセージがない旨を通知し（Ｓ４１５）、電話を切り（Ｓ４１６）、処理を終了する。

なお、ここまでの実施例の説明では、留守録電話機は１つの呼に対して着呼処理、宛先確認の処理、留守録の処理などを説明してきたが、ＩＰ電話に於いては、音声通話中であっても、アナログ電話と違い物理回線を占有することはなく、ＩＰネットワーク上でパケットと呼ばれる可変長のデータ単位で物理回線をシェアしながら通信を行うため、留守録電話機がマルチタスクに処理を実行することが出来れば、音声通話中に不在転送による着信が来た場合でも、留守録処理部４５が自動的にその着信を受けて留守録サービスを提供したり、たまたま不在転送における着信が同時に複数呼発生した場合でも、本実施例をマルチタスクに処理させればそれぞれの呼に対して留守録サービスを提供することが可能である。

また、上述した実施例に、宛先確認部４４にて宛先が判明した後、通常呼出し音や代理応答呼出し音を鳴らす際に、特定の番号だけを別途指定した呼出し音を鳴らすこと、留守録処理時に相手側に不在の旨を伝える不在メッセージについて、それぞれの本留守録電話機設定者が自身の声で好きなメッセージ登録しておき、そのメッセージを相手側に再生する不在メッセージに指定することなどの応用を追加することは容易に実現可能である。

図１６を参照して、上述した実施例以外のＩＮＶＩＴＥメッセージを説明する。ここで、図１６はＵｓｅｒ−Ａｇｅｎｔヘッダを用いたＩＮＶＩＴＥメッセージを説明する図である。図１６において、ＩＮＶＩＴＥメッセージ６０Ｂの１行目にはリクエスト文が記述され、２０１０番への呼接続を要求する１文が記載されている。以下、Ｆｒｏｍヘッダには発信元情報が、Ｔｏヘッダには宛先情報が示されている。このＩＮＶＩＴＥメッセージ６０Ｂでは、３００１番から２０１０番への呼接続要求に見えるが、Ｕｓｅｒ−Ａｇｅｎｔヘッダを参照すると、当初の宛先情報が電話番号２００５であったことが分かる。

Ｕｓｅｒ−Ａｇｅｎｔヘッダは、本来、リクエストを開始するＵＡＣ（ユーザ・エージェント・クライアント）についての情報を示すヘッダである。しかし、セキュリティの観点からＳＩＰにおいてはほとんど使われていない。

図１６において、不在転送を行う場合、テレフォニーサーバ１１は、Ｕｓｅｒ−Ａｇｅｎｔヘッダに不在転送する前の宛先番号情報を書き込み、留守録電話機がこのフィールドを読み取ることにより、不在転送先に元の宛先番号情報を伝える事が出来る。図によれば、Ｕｓｅｒ−Ａｇｅｎｔヘッダには、不在転送される前の宛先番号情報が記録されている。なお、Ｕｓｅｒ−Ａｇｅｎｔヘッダ・フィールドの構文規則は、このヘッダが定義されているＲＦＣ２６１６に従った上で、テレフォニーサーバとテレフォニーサーバが管理するクライアント（電話端末）間で予め定義する。

他にもＳＩＰプロトコルの大きな特徴である、“目的に応じて拡張部分を追加できる”という仕様を用いて、独自のオプションヘッダを定義してそこを利用する方法なども考えられる。

ソフトフォン利用者が不在のときの電話システムの動作を説明するブロック図である。 留守録システムが適用されたネットワークを示すブロック図である。 テレフォニーサーバに登録された管理情報テーブルを説明する図である。 留守録電話機のハードウェアブロック図である。 留守録電話機の機能ブロック図である。 留守録電話機の斜視図である。 ＳＩＰメッセージにおける基本フォーマットである。 ＩＮＶＩＴＥメッセージを説明する図である。 Ｈｉｓｔｏｒｙ−Ｉｎｆｏヘッダを用いたＩＮＶＩＴＥメッセージを説明する図である。 留守録電話機における着信時の処理フローチャートである。 留守録データ情報テーブルを説明する図である。 留守録電話機のディスプレイ表示である。 発呼電話機とテレフォニーサーバと留守録電話機との間の不在転送処理のシーケンス図である。 留守録メッセージ確認時のシーケンス図である。 留守録メッセージ確認時の流れを説明するフロー図である。 Ｕｓｅｒ−Ａｇｅｎｔヘッダを用いたＩＮＶＩＴＥメッセージを説明する図である。

符号の説明

１０…留守録電話機、１１…テレフォニーサーバ、１３…ＰＣ、１４…ＰＣ、１５…ソフトフォン、１６…ハンドセット、１７…ＬＡＮ、１８…ＷＡＮ、２１…ＣＰＵ、２２…ＲＯＭ、２３…ＲＡＭ、２４…音声ＣＯＤＥＣ、２５…不揮発性記憶装置、２６…入出力デバイスＩ／Ｆ、２７…ネットワークＩ／Ｆ、２８…バス、３０…受話器、３３…ディスプレイ、３４…操作ボタン、３５…操作ボタン、３６…ランプ、３７…ＬＡＮコネクタ、４１…デバイス制御部、４２…音声処理部、４３…通信処理部、４４…宛先確認部、４５…留守録処理部、５０…情報管理テーブル、６０…ＩＮＶＩＴＥメッセージ、７０…留守録データ情報テーブル、１００…ＳＩＰ基本フォーマット。

Claims (10)

1. ＩＰ電話機と、ＩＰ代理応答電話機と、前記ＩＰ電話機と前記ＩＰ代理応答電話機との発着信を制御するサーバとからなる電話システムであって、
   前記サーバは、前記ＩＰ電話機宛ての着呼があったとき、前記ＩＰ電話機の状態を判定し、前記ＩＰ電話機が着呼できないと判定したとき、前記ＩＰ電話機の識別子を付与して前記ＩＰ代理応答電話機に前記着呼を転送することを特徴とする電話システム。
2. 請求項１に記載の電話システムであって、
   前記ＩＰ代理応答電話機は、着呼があったとき、転送された着呼か前記ＩＰ代理応答電話機宛ての着呼かを判定し、判定結果に基づいて鳴動音を出力することを特徴とする電話システム。
3. 請求項１または請求項２に記載の電話システムであって、
   前記ＩＰ代理応答電話機は、録音機能を有することを特徴とする電話システム。
4. 請求項１ないし請求項３のいずれかに記載の電話システムであって、
   前記ＩＰ電話機は、コンピュータにハンドセットを接続してなることを特徴とする電話システム。
5. ＩＰ電話機とＩＰ代理応答電話機と接続され、前記ＩＰ電話機と前記ＩＰ代理応答電話機との発着信を制御するサーバであって、
   前記ＩＰ電話機宛ての着呼があったとき、前記ＩＰ電話機の状態を判定し、前記ＩＰ電話機が着呼できないと判定したとき、前記ＩＰ電話機の識別子を付与して前記ＩＰ代理応答電話機に前記着呼を転送することを特徴とするサーバ。
6. 請求項５に記載のサーバであって、
   前記識別子は、ＩＮＶＩＴＥメッセージのＨｉｓｔｏｒｙ−Ｉｎｆｏヘッダにより、前記ＩＰ代理応答電話機に送達することを特徴とするサーバ。
7. 請求項５に記載のサーバであって、
   前記識別子は、ＩＮＶＩＴＥメッセージのＵｓｅｒ−Ａｇｅｎｔヘッダにより、前記ＩＰ代理応答電話機に送達することを特徴とするサーバ。
8. ネットワークを介して、電話機とテレフォニーサーバと接続された代理応答電話機であって、
   前記テレフォニーサーバからＩＮＶＩＴＥメッセージを受信したとき、前記ＩＮＶＩＴＥメッセージを解析して、転送された着呼か前記ＩＰ代理応答電話機宛ての着呼かを判定し、判定結果に基づいて鳴動音を出力することを特徴とする代理応答電話機。
9. 請求項８に記載の代理応答電話機であって、
   前記判定結果に基づいてディスプレイ表示を出力することを特徴とする代理応答電話機。
10. 請求項８または請求項９に記載の代理応答電話機であって、
    一定期間前記鳴動音を出力した後、応答メッセージを送出し、録音モードに切替えることを特徴とする代理応答電話機。

Images