JP2005341010A - 呼制御サーバ装置 - Google Patents

Abstract

【課題】着信先の電話が、通話中や呼出しに応答しない場合に、発信元のユーザに代わって、自動的に着信先電話に対して呼出しを行い、着信先電話が応答すれば、着信先ユーザに発信元ユーザの情報とメッセージを伝える呼制御サーバを提供する。
【解決手段】呼制御サーバ７は、着信先のインターネット電話１あるいは一般加入者電話６が、呼出しに対して応答しなかった場合、発信元ユーザの要求があれば、自動的に着信先のインターネット電話１あるいは一般加入者電話６に対して呼出しを繰り返し行い、応答があれば、発信元ユーザの氏名、電話番号などと、メッセージを音声で伝える。もし、着信先のインターネット電話１あるいは一般加入者電話６が、応答しなかった場合、発信元ユーザに対して、未通知の連絡を音声で伝える。
【選択図】図１

Description

本発明は、インターネット電話、または一般電話である電話端末間の呼を制御する装置（呼制御サーバ）に関し、特に被呼端末が、ビジー状態または呼出しに応答しない場合、被呼端末に対して再発呼を繰り返す装置に関するものである。

近年、ＩＳＰ（インターネットサービスプロバイダ）によるインターネット電話（ＩＰ電話）サービスが徐々に普及しつつある。同じＩＳＰによるインターネット電話サービスを利用しているユーザとは通常通話料金なしで通話ができ、公衆電話交換網（ＰＳＴＮ：Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）に接続された一般加入者電話への電話も安価な料金で通話可能であることから、一般加入者電話に替えてインターネット電話サービスを利用するユーザも、増えてきている。

インターネット電話サービスで使用されているプロトコルは、Ｈ．３２３あるいはＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）であり、現在、ＩＳＰが提供するインターネット電話サービスでは、プロトコルとしてＳＩＰが採用されることが多くなっている。このＳＩＰを使用したインターネット電話サービスは、普通の通話においては、一般加入者電話と同じように利用できる。

インターネット電話、一般電話を問わず、相手方が不在または通話中の場合の対応技術が提案されてきた。相手方が不在の場合に対応する方法としては、いわゆる「留守番電話」が実施されており、相手方が通話中の場合に対応する方法としては、いわゆる「キャッチホン」が実施されている。さらに、インターネット電話において、インターネット電話通話中にかかってきた他のインターネット電話をユーザに報知するとともに、通話が終了すれば、通話中にかかってきた相手先に自動的に発呼処理を行う技術が開示されている（例えば、特許文献１参照）。
特開２０００−１７４９０４号公報

しかしながら、「キャッチホン」では、通話中に電話がかかってきた場合、元の通話の相手方は保留の状態に保たれているので、キャッチの通話が終了するまで待たされることを余儀なくされる。また、「留守番電話」では、伝言メッセージを相手方が確認したかどうかを、相手が積極的に連絡してこない限り、確かめるすべはない。

さらに、前述した特許文献１に開示されている技術によっても、発呼者は、相手が通話終了して相手からの呼がある時点で、電話に出ることができる状態にいなければならないという課題がある。

本発明は、上記従来の課題に鑑みなされたもので、相手方が不在または話し中の場合、発呼者、相手先とも電話に出ることができる状態での待機を強いることなく、発呼者のメッセージを迅速・確実に伝える呼制御サーバを提供することを目的とする。

前記従来の課題を解決するために、本発明の呼制御サーバ装置は、電話機能を有する通信端末間の呼を制御する呼制御サーバであって、発呼に対して被呼端末が、ビジー状態または呼び出しに応答しない場合、発呼端末から、メッセージを受け付けるメッセージ受付部と、前記メッセージを、再発呼先を識別する再発呼先識別子とともに記憶する再発呼先記憶部と、前記被呼端末に再発呼を行い、応答の有無を検出し応答があった場合、前記メッセージを前記再発呼先記憶部から読み出して前記被呼端末に通知する再発呼部を具備したことを特徴としている。この構成により、相手方が通話中または不在であっても、再発呼が繰り返され、再発呼に対して相手方が応答すれば、発呼者にメッセージが通知されるので、入力されたメッセージを通知することができる。

また、本発明の呼制御サーバ装置は、再発呼の回数、再発呼の時間間隔、再発呼を継続する時間を指定する情報のうち少なくとも一つを含む再発呼指定情報を発呼端末から受け付ける再発呼情報指定部を具備し、前記再発呼先記憶部は、再発呼先を識別する識別子とともに前記再発呼指定情報を記憶し、前記再発呼部は、前記再発呼指定情報の指定に従って再発呼を行うことを特徴としている。この構成により、発呼者は、自己の都合によりどのように再発呼を行うかを指定することができる。特に、再発呼に対して、従量制課金（回数に応じた課金）がなされるときは、メッセージを伝える緊急度と料金を勘案して、どのように再発呼を行うかを指定することができるので便利である。

また、本発明の呼制御サーバ装置は、前記被呼端末が再発呼に対して応答がなかった場合、前記メッセージが未通知であることを前記発呼端末に通知する未通知連絡部を具備することを特徴としている。この構成により、メッセージが未通知の場合は、発呼者にその旨が通知されるので、発呼者は自己のメッセージが未だ未通知である旨を知ることができる。さらに、相手が使用している電話端末が複数ある場合には、他の使用している端末に対し再発呼することができる。

また、本発明の呼制御サーバ装置の前記再発呼先記憶部は、前記再発呼先識別子を複数記憶し、前記再発呼部は前記再発呼先識別子で特定される複数の端末に対して再発呼を行うことを特徴としている。この構成により、被呼者は、自己が使用している端末が複数ある場合、特定の端末について再呼を許す発呼元識別子を登録しておくことで、再呼を許された発呼元からの再呼のみ受けることができる。

また、本発明の呼制御サーバ装置の前記再発呼先記憶部は、前記再発呼先識別子とそれにより特定される端末に対する再呼を許す発呼元を特定する発呼元識別子を記憶し、前記再発呼部は、前記再発呼先識別子で特定される複数の端末のうち、再呼を許された端末に対してのみ再呼を行うことを特徴としている。この構成により被呼者は、再呼を許す又は禁止する暦上の日区分または時間帯を登録しておくことで、再呼されることを所望する端末に対してのみ再呼を受けることができる。

また、本発明の呼制御サーバ装置の前記再発呼先記憶部は、前記再発呼先識別子とそれにより特定される端末に対する再呼を許す又は禁止する日区分または時間帯を記憶し、前記再発呼部は、前記再発呼先識別子で特定される複数の端末のうち、再呼を許された端末に対してのみ再呼を行うことを特徴としている。この構成により相手が応答する可能性が高い端末に対し優先的に再発呼を行うことができる。

また、本発明の呼制御サーバ装置は、特定の再発呼先に対し再発呼が行なわれた時刻と前記再発呼に対する応答の存否を示す履歴データを記憶する再発呼履歴記憶部を具備し、前記再発呼先記憶部は、前記履歴データを参照して、優先順位を変更することを特徴としている。この構成により、相手方の端末毎、時間帯毎の応答状況に応じて、再発呼を行うことができる。

本発明の呼制御サーバ装置によると、インターネット電話または一般電話などの電話機能を有する通信端末間である電話端末間で、着信側が、ビジー状態または呼び出しに応答しない場合、自動的に着信側端末に対して、再発呼を繰り返し、着信側が応答したときに、あらかじめ生成された発信者のメッセージ等を着信側に通知することができる。

また、着信側利用者が複数の端末を使用している場合であっても、どの端末でどの時間帯で応答したかという応答履歴や着信側利用者が再呼を希望しない端末かどうかを考慮して再呼が行なわれるので、再呼の回数をなるべく少なくしつつメッセージを通知したいという発信側利用者のニーズと再呼を希望しない端末には再呼してほしくないという着信側利用者のニーズに答えることができる。

以下、本発明の実施の形態について、図面を参照しながら説明する。

図１は、本発明の実施の形態における呼制御サーバを用いた電話システムのシステム構成図である。図１に示す本実施の形態は、インターネット電話１と、インターネット電話１とＩＰ網３を結ぶルータ２と、ＩＰ網３と公衆電話交換網５を結ぶゲートウェイ４と、一般加入者電話６と、インターネット電話１または一般加入者電話６である電話端末間の呼を制御する呼制御サーバ７とから構成されている。

図２は、呼制御サーバ７の構成を示す機能ブロック図である。呼制御サーバ７は、ネットワークインターフェース部８、発呼情報通知部９、再発呼部１２、未通知連絡部１５、及びデータベース部１６から構成されており、具体的には、コンピュータをコンピュータ・プログラムで稼動させることにより実現されている。

ネットワークインターフェース部８は、ＩＰ網３と、発呼情報通知部９、再発呼部１２、未通知連絡部１５とのＩＰパケットデータの交換を行う。

発呼情報通知部９は、発呼端末から、着信者相手に対するメッセージを受け付けるメッセージ受付部１０と、被呼端末に対して、発呼情報（発呼者の氏名、電話番号等）とメッセージ受付部１０で受け付けたメッセージを音声で通知する発呼情報音声通知部１１から構成されている。

再発呼部１２は、再発呼の回数、再発呼の時間間隔、再発呼を継続する時間を指定する情報を発呼端末から受け付ける再発呼情報指定部１３と、再発呼情報指定部１３で指定された情報を基に被呼端末に対して、自動的に再発呼を繰り返す再発呼実行部１４から構成されている。

未通知連絡部１５は、被呼端末が、再発呼に対して応答がなかった場合、発呼端末に発呼情報が未通知であることを示す未通知情報（被呼者の氏名、電話番号等）を音声で通知する。

データベース部１６は、呼制御サーバ７の利用者の情報と利用者端末の情報を記憶する利用者情報記憶部１７と、再発呼部１２の再発呼情報指定部１３で受け付けた情報と発呼情報通知部９のメッセージ受付部１０で受け付けたメッセージと再発呼先の情報を記憶する再発呼先記憶部２０と、再発呼先の応答履歴を記憶する再発呼履歴記憶部２４とから構成される。利用者情報記憶部１７には、利用者情報テーブル１８と、利用者端末情報テーブル１９のテーブルが設けられる。再発呼先記憶部２０には、再発呼情報テーブル２１と、発信者音声メッセージテーブル２２と、再発呼先情報テーブル２３のテーブルが設けられる。再発呼履歴記憶部２４には、再発呼応答履歴テーブル２５のテーブルが設けられる。

図３は、図２に示された利用者情報テーブル１８、利用者端末情報テーブル１９、再発呼情報テーブル２１、発信者音声メッセージテーブル２２、再発呼先情報テーブル２３、再発呼応答履歴テーブル２５の６つのテーブルの詳細な構造と各テーブルの関係の一例を示す図である。

図３の利用者情報テーブル１８は、図１に示された呼制御サーバ７の利用者として登録されたユーザに関する情報を保持するテーブルであり、ユーザＩＤ３０、電話番号３１、利用者氏名漢字３２、利用者氏名カナ３３、呼状態３４の各フィールドから構成され、呼制御サーバ７の利用者１名につき１レコード生成される。ユーザＩＤ３０は、ユーザが図１に示された呼制御サーバ７の利用者登録を行った際に、呼制御サーバ７が自動的に付与するＩＤで、呼制御サーバ７の利用者を識別するためのＩＤである。電話番号３１は、図１に示されたインターネット電話１に割り当てられた電話番号である。利用者氏名漢字３２、利用者氏名カナ３３は、ユーザＩＤ３０に対応する利用者の氏名漢字と氏名カナである。呼状態３４は、呼制御サーバ７の利用者が、空き、呼出し中、あるいは話し中のいずれかの状態を示す。

図３の再発呼情報テーブル２１は、被呼端末が、ビジー状態または呼び出しに応答しない場合の再発呼時に、再発呼の条件を保持するテーブルであり、発信者ＩＤ４０、被呼端末電話番号４１、再発呼回数４２、再発呼時間間隔４３、再発呼継続時間４４の各フィールドから構成され、発信者から要求のあった再発呼先１件につき１レコード生成される。発信者ＩＤ４０は、発信者を識別するためのＩＤで、利用者情報テーブル１８に登録されているユーザＩＤ３０である。被呼端末電話番号４１は、被呼端末の電話番号である。再発呼回数４２は、被呼端末に再発呼を繰り返す回数である。再発呼時間間隔４３は、再発呼から次の再発呼までの時間間隔である。再発呼継続時間４４は、再発呼時に被呼端末に対して、継続して呼び出す時間（呼出し音を継続して鳴らす時間）である。

図３の発信者音声メッセージテーブル２２は、発信者からの音声メッセージを保持するテーブルであり、発信者ＩＤ５０、被呼端末電話番号５１、音声メッセージ５２の各フィールドから構成され、発信者から要求のあった再発呼先１件につき１レコード生成される。発信者ＩＤ５０、被呼端末電話番号５１は、再発呼情報テーブル２１の発信者ＩＤ４０、被呼端末電話番号４１と同じである。音声メッセージ５２は、発信者からの音声メッセージである。

図３の再発呼先情報テーブル２３は、再発呼先の情報を保持するテーブルであり、被呼端末電話番号６０、再発呼先端末識別子６１、再発呼優先順位６２の各フィールドから構成され、再発呼先電話番号１件につき、１レコードまたは複数レコード生成される。被呼端末電話番号６０は、再発呼情報テーブル２１の被呼端末電話番号４０と同じである。再発呼先端末識別子６１は、再発呼先のＩＰアドレス、あるいは電話番号である。再発呼優先順位６２は、再発呼をする時の再発呼先端末の優先順位である。

図３の利用者端末情報テーブル１９は、電話番号に対応する端末の識別子（ＩＰアドレスあるいは、電話番号）を保持するテーブルであり、電話番号７０、端末識別子７１、優先順位７２の各フィールドから構成され、利用者情報テーブル１８の１レコードにつき、１レコードまたは複数レコード生成される。電話番号７０は、利用者情報テーブル１８の電話番号３０と同じである。端末識別子７１は、電話番号に対応する端末の識別子（ＩＰアドレスあるいは、電話番号）である。優先順位７２は、一つの電話番号に対応する接続先端末の優先順位である。なお、利用者端末情報テーブル１９は、他の情報を含んでいてもよく、他の具体例を後で説明する。

図３の再発呼応答履歴テーブル２５は、再発呼時に応答があった端末の応答履歴を時間帯別に保持するテーブルであり、再発呼先端末識別子８０、時間帯８１、応答回数８２の各フィールドから構成され、再発呼先端末識別子１件につき、時間帯別に午前（８：００〜１２：００）、午後（１２：００〜１７：００）、夜間（１７：００〜２２：００）の最大３レコード生成される。なお、時間帯は必ずしも三つに区分する必要はなく、昼間、夜間の二区分でもよく、あるいは細かく区分してもよい。

発呼先端末識別子８０は、再発呼先の端末を識別子である。時間帯８１は、再発呼先端末が応答した時間帯を示す。応答回数８２は、再発呼先端末が応答した回数である。

以上説明したテーブルの構成は、一例であってこれと異なるテーブル構成を取ることも可能である。

図４は、被呼端末（着信側端末）が、通話中または呼び出しに応答しなかった場合に呼制御サーバが、再発呼処理を行うまでの処理を示すシーケンス図であり、ステップＳ１１０からステップＳ１１９までで構成されている。図５は、再発呼処理（ステップＳ１１９）の詳細を示すフローチャートであり、ステップＳ５０１からステップＳ５０７までで構成されている。

図４を参照しながら、再発呼処理が行なわれるまでの流れについて詳細に説明する。

まず、呼制御サーバ７を利用するために利用者は、呼制御サーバ７に利用者登録を行なければならない。利用者登録は、呼制御サーバ７のサービスを提供している会社が、インターネット上のウェッブサイトで開設したホームページ（利用者登録ページ）上で、必要事項を記入して送信するか、サービス提供会社宛てに利用申請の電子メールを送信して行うか、サービス提供会社の電話サポートセンターに電話をかけるなどして、利用申請を行う。

利用者登録すると、利用者情報テーブル１８に利用者の情報が保持され、また、登録時に割り当てられる一つの電話番号に対して、利用者は着信、発信可能な端末を複数登録することができ、その登録内容は、利用者端末情報テーブル１９に保持される。利用者登録を済ませた利用者が、インターネット電話１（発信側）を用いて電話をかけた場合、図４に示された呼制御サーバ７への通話要求（ステップＳ１１０）が行われる。

通話要求（ステップＳ１１０）を受けた呼制御サーバ７は、被呼端末の電話番号をもとに、呼制御サーバ７上の利用者情報テーブル１８の電話番号３１と、その電話番号が合致するものが登録されているかを検索し、登録されていれば、呼状態を確認し、空きであれば、利用者端末情報テーブル１９の優先順位７２が最も高い端末識別子７１を持った被呼端末（着信側）に対して、図４に示された接続要求（ステップＳ１１１）を行う。呼制御サーバ上の利用者情報テーブル１８の電話番号３１に被呼端末の電話番号が登録されていなければ、図１に示されたゲートウェイ４を介して、公衆電話交換網５に接続された一般加入者電話６（着信側）に対して、接続要求（ステップＳ１１１）を行う。

接続要求（ステップＳ１１１）を受けた被呼端末は、呼制御サーバ７に対して、図４に示された呼出し音、あるいは通話中音（ステップＳ１１２）を呼制御サーバ７に返し、呼制御サーバ７は、呼出し音、あるいは通話中音を発信端末に返す（ステップＳ１１３）。

呼制御サーバ７が、接続要求（ステップＳ１１１）を被呼端末に対し一定時間接続要求（ステップＳ１１４）を行っても、被呼端末が応答しなければ、呼制御サーバ７は図４に示された切断（ステップＳ１１５）を被呼端末に対して行う。その後、呼制御サーバ７は、発信側に対して、被呼端末に対して一定時間接続要求（ステップＳ１１４）を行ったが、着信者が、通話中か不在のために応答がなかった旨を音声メッセージで通知し、自動で被呼端末に対して、音声メッセージで再発呼確認（ステップＳ１１６）を行う。発信側が、再発呼確認（ステップＳ１１６）に対して、再発呼を希望するなら、呼制御サーバ７に対して、図４に示された再発呼要求（ステップＳ１１７）を行う。この再発呼要求（ステップＳ１１７）は、再発呼確認（ステップＳ１１６の）音声メッセージに従って、発信側が、インターネット電話１をボタン操作することにより、再発呼の条件（再発呼回数４２、再発呼時間間隔４３、再発呼継続時間４４）を指定し、着信側に伝えたいメッセージがあれば、インターネット電話１から音声メッセージ３２の入力も行う。なお、再発呼のサービスに対する課金方法としては、たとえば、再発呼回数、再発呼継続時間に応じた従量性課金とすることが考えられる。この場合、発信側利用者は、メッセージを伝える緊急度と料金を勘案して再発呼回数等を決定すればよい。なお、再発呼の条件を「緊急」、「急用」、「普通」等とランク分けしておき、発信側ユーザが、どのパターンかを指定すれば、あとは呼制御サーバが、自動的に再発呼回数を設定する構成としてもよい。また、再発呼を実行する時刻を指定する構成としてもよい。

このようにして再発呼の条件とメッセージの入力が完了すれば、次のステップＳ１１８の再発呼情報生成が行なわれる。すなわち、再発呼の条件指定受付は、図２に示された再発呼部１２の再発呼情報指定部１３が行い、データベース部１６の再発呼先記憶部２０に記憶される。再発呼先記憶部２０は、指定された再発呼の条件を図３に示された再発呼情報テーブル２１に保持する。着信側へのメッセージ登録受付は、図２に示された発呼情報通知部９のメッセージ受付部１０が行って音声をバイナリ−形式に変換し、データベース部１６の再発呼先記憶部２０に記憶される。再発呼先記憶部２０は、受け付けたメッセージをバイナリ−形式に変換したものを図３に示された発信者音声メッセージテーブル２２に保持する。

次に、再発呼情報テーブル２３の生成が行なわれる。まず、まず利用者端末情報テーブル１９を検索して、被呼端末電話番号と同一の電話番号７０を持つレコードの端末識別子７１すなわち被呼側の端末識別子をすべて抽出する。そして、再発呼応答履歴テーブル２５を検索して、被呼側の端末識別子を再発呼先端末識別子８０のフィールドに持つ、レコードをすべて抽出する。次に、再呼を行う時間帯における応答回数が最も多い端末識別子を時間帯８１と応答回数８２のフィールドを見て抽出し、これを、再発呼優先順位１位の端末として、再発呼先情報テーブル２３に登録する。引き続き、２位、３位の端末を調べて登録し、すべての再発呼先端末識別子が再発呼先情報テーブル２３に登録されるまで同様の処理を行う。

応答回数が同一の端末については、利用者端末情報テーブル１９の優先順位７２を参照して、優先順位が高いほうを高い順位とする。

以上で、ステップＳ１１８の再発呼情報生成の処理が完了し、再発呼に必要なデータが揃ったことになる。なお、時間の経過により、現在時刻の属する時間帯が異なる時間帯に移行すれば、上記の処理は再度行なわれ、再呼を行う時間帯における応答回数を反映した再発呼情報テーブル２３が再度生成される。

次に、呼制御サーバ７は、再発呼処理（ステップＳ１１９）を行い、応答があった場合は、着信側にメッセージを通知する。（ステップＳ１２０）指定された回数繰り返しても、応答がなかった場合には、発信側に未通知メッセージを通知する（ステップＳ１２１）。

次に、再発呼処理（ステップＳ１１９）の処理について、図５を参照して詳細に説明する。

呼制御サーバは、着信側に対して最初の通話要求を行った時点から、発信側利用者が指定した再発呼時間間隔を経過すると、最初の再発呼処理を行い、応答がない限り、指定の回数に達するまで、再発呼を繰り返す。１回の再発呼処理は、再発呼先情報テーブル２３により特定される端末全てに対して優先順位に従って、接続要求を行う処理から構成されている（以下、特定の端末に再発呼を行うことを、単に再発呼と呼び、端末全てに対して再発呼を行うことを再発呼処理と呼んで区別する。）。

例えば、再発呼先端末識別子として、優先順位の高いほうから＃１００１、＃１００２、＃１００３があったとすると、１回の再発呼処理は、＃１００１に対する接続要求、＃１００２に対する接続要求及び＃１００３に対する再発呼から成る。まず、ステップＳ５０１において、呼制御サーバ７の再発呼実行部１４は、再発呼先情報テーブル２３を参照し、優先順位が１位の再発呼先端末識別子で特定される端末を再接続先端末として特定する。次のステップＳ５０２においては、特定された端末に対して、再接続を、指定の継続時間繰り返す。

応答があった場合は（ステップＳ５０３がＹｅｓ）、発信者音声メッセージテーブル２２に蓄えられていたバイナリ−形式の音声メッセージが、発呼情報音声通知部１１により読み出され、音声に変換されて、着信側に通知される（ステップＳ５０４）。さらに、ステップＳ５０５において、応答履歴が更新されて、再呼の処理が終了する。応答履歴の更新は、再発呼応答履歴テーブル２５から、再発呼を行った端末の識別子を再発呼先端末識別子８０として持ち、再発呼を行った時点に対応する時間帯８１を持つレコードの応答回数が１加算される。

応答がなかった場合は（ステップＳ５０３がＮｏ）、ステップＳ５０６では、すべての再発呼先端末に対して接続要求がなされたかがチェックされ、すべての再発呼先端末に対して、接続要求がなされている場合は（ステップＳ５０６がＹｅｓ）、再発呼処理は終了する、一方、まだ、再接続要求すべき端末が残っている場合は（ステップＳ５０６がＮｏ）、ステップＳ５０７に進む、ステップＳ５０７では、再発呼先情報テーブル２３を参照して次の優先順位を持つ端末が再接続の対象として特定される。その後は、ステップＳ５０２に戻り、同様の処理が繰り返される。

メッセージ通知の処理（ステップＳ５０４）の詳細は、以下の通りである。

呼制御サーバ７は、利用者情報テーブル１８から発信者の利用者氏名カナ３３を取得し、その利用者氏名カナ３３を図２の発呼情報通知部９の発呼情報音声通知部１１が音声変換し、図３に示された発信者音声メッセージテーブル２２に発信者からの音声メッセージ３２があれば、その音声メッセージ３２と共に、発信者情報を音声メッセージで通知する。その結果、例えば「やまだ かずお様から、メッセージが届いています。『明日の待ち合わせ時刻は、１１時にしてください。』」という音声メッセージが通知される。通知後、呼制御サーバ７は、切断を被呼端末に対して行う。

また、未通知連絡（ステップＳ１２１）の処理の詳細は、以下の通りである。

呼制御サーバ７は、利用者情報テーブル１８から、着信者の利用者氏名カナ３３を取得し、その利用者氏名カナ３３を図２の未通知連絡部１５が音声変換し、被呼端末電話番号４１と共に、未通知であることを音声メッセージで連絡する。なお、呼制御サーバ７から連絡するのではなく、発信者からの問い合わせに対して、呼制御サーバが自動的に応答する構成としてもよい。

前述した利用者端末情報テーブル１９は、電話番号７０と端末識別子７１と優先順位７２から構成されている場合を説明したが、他の具体例について図６〜図９を用いて説明する。

図６に示す利用者端末情報テーブル１９は、電話番号７０、端末識別子７１、優先順位７２、再呼許可ユーザＩＤ７３のフィールドをもっている。図３と異なるのは、再呼許可ユーザＩＤ７３のフィールドが付加されていることである。再呼許可ユーザＩＤ７３は、特定の端末識別子７１に再呼を許すユーザＩＤを登録するフィールドである。例えば、親しい友人が発呼した場合のみ、自宅への再呼を許したいときは、自宅の端末の端末識別子とともにその友人のユーザＩＤを登録しておけばよい。また、すべての発呼に対して、再呼されてもよい端末については、その旨を示す符号（例えば「００００」）を登録しておく。

そして、通話要求からメッセージ通知または未通知連絡までの処理の流れ及び再発呼の処理の流れは、それぞれ図４及び図５に示す通りであり、再発呼先情報生成（ステップＳ１１８）の処理が異なる。すなわち、再発呼応答履歴テーブル２５を参照して、応答回数の多いものを高順位として、応答回数が同じの場合は、利用者端末情報テーブル１９の優先順位によって再発呼先優先順位６２を決定するが、発信者がその端末に再呼することが許されているかを利用者情報テーブル１９の再呼許可ユーザＩＤ７３を参照して確認し許されていないのであれば応答回数８２及び優先順位７２いかんに関わらず、再呼の対象から除外して再発呼先情報テーブル２３を生成する。その結果、その発呼者について、再呼が許された端末に対してのみ、再呼が行なわれるので、その端末には呼がなされることを許容する発呼者の再呼のみがなされることが可能となる。

図７に示す利用者端末情報テーブル１９は、電話番号７０、端末識別子７１、優先順位７２、再呼禁止曜日７４のフィールドをもっている。図３と異なるのは、再呼禁止曜日７４フィールドを持つことである。このフィールドは、特定の端末について、再呼を禁止する曜日を登録するフィールドである。たとえば、日曜日には、家庭にある端末への再呼を禁止したいのであれば、当該端末について、再呼禁止曜日を日曜日として登録しておけばよい。また、すべての曜日について再呼を許す端末については、その旨を許すコード（たとえば、「００００」）を登録しておく。

そして、通話要求からメッセージ通知または未通知連絡までの処理の流れ及び再発呼の処理の流れは、それぞれ図４及び図５に示す通りであり、再発呼先情報生成（ステップＳ１１８）の処理が異なる。すなわち、再発呼応答履歴テーブル２５を参照して、応答回数の多いものを高順位として、応答回数が同じの場合は、利用者端末情報テーブル１９の優先順位によって再発呼先優先順位６２を決定するが、再呼する時点が属する曜日において、特定の端末に対して許されているかを利用者端末情報テーブル１９の再呼許可ユーザＩＤ７４を参照して確認し許されていないのであれば応答回数８２及び優先順位７２いかんに関わらず、再呼の対象から除外して再発呼先情報テーブル２３を生成する。その結果、再呼の時点で再呼が許された端末に対してのみ、再呼が行なわれるので、本実施の形態においては、特定の曜日（たとえば日曜日）に特定の端末（たとえば自宅の端末）への再呼・メッセージ通知を希望しないというニーズに対応することができる。

図８に示す利用者端末情報テーブル１９は、電話番号７０、端末識別子７１、優先順位７２、曜日・時間帯コード７５のフィールドを持っている。図３と異なるのは、曜日・時間帯コード７５のフィールドを持つことである。曜日・時間帯コードは、曜日（たとえば、月曜日）、時間帯（たとえば、９：００〜１２：００）を特定するコードである。つまり、利用者端末情報テーブル１９は、曜日時間帯別に再発呼先の端末識別子を記憶するものである。

図９は、本実施の形態における曜日・時間帯コードテーブルの構成を示す図である。図９に示すように、曜日・時間帯コードテーブルは、曜日時間帯コード９１、曜日９２、時間帯９３の各フィールドをもっている。つまり、曜日・時間帯コードテーブルは、曜日・時間帯コードと曜日・時間帯の対応を示すテーブルである。

そして、通話要求からメッセージ通知または未通知連絡までの処理の流れ及び再発呼の処理の流れは、それぞれ図４及び図５に示すとおりであり、再発呼先情報生成（ステップＳ１１８）と再発呼処理（ステップＳ１１９）の処理が異なる。ステップＳ１１８では、再発呼情報指定部は、利用者情報テーブルと曜日時間帯コードテーブル、再発呼情報テーブル２１を参照して、現在時刻が属する曜日・時間帯における再発呼先情報テーブル２３を生成する。この処理は、現在時刻が、異なる曜日・時間帯に移行する毎に行なわれる。すなわち、再発呼情報指定部１３は、定期的に現在時刻をチェックして、異なる曜日・時間帯に移行する毎に、再発呼先情報テーブル２３を生成する。そして、再発呼は、再発呼情報テーブル２１に従って行なわれるので、再発呼を実行する曜日・時間帯における曜日時間帯における再発呼先の優先順位に従って、ステップＳ１１９において再呼が行なわれる。その結果、特定の曜日・時間帯において、応答できる端末の優先順位を高く設定することにより、再呼において応答があるまでの再接続要求の回数を低く抑えることができ、再接続要求の回数に応じて課金されるときは、料金を低く抑えることができる。

なお、本実施の形態においては、発信側端末はインターネット電話であるとしたが、着信側端末が本発明の呼制御サーバのサービスを受けることが可能なインターネット電話であれば、発信側端末は、一般加入者電話であってもよい。また、着信側端末は、本実施の形態に示したインターネット電話、あるいは一般電話以外に、携帯電話であってもよい。

また、本実施の形態に示した着信側へのメッセージ通知時に、着信側端末に表示機能を持つディスプレイがあれば、音声メッセージの代わりに、着信側端末のディスプレイにメッセージを表示してもよい。また、発信者の電話番号を通知して着信側端末に保存する構成とすれば、着信側端末では、簡単なボタン操作のみで、発信者に電話をかけることも可能となる。さらに、音声メッセージとディスプレイへの表示を併用してもよいし、メッセージを音声メッセージの形式で通知するか、ディスプレイへ表示するかを、発信側利用者に選択させる構成としてもよい。

また、応答履歴を反映せずに、固定の優先順位で再発呼を行う構成としてもよい。この場合は再発呼応答履歴テーブル２５は不要である。

また、着信側端末は複数でなく、一つの電話番号について１台のみであってもよい。

また、再発呼に対して、応答があった場合、メッセージが通知されたことを、発信側利用者に通知する構成としてもよい。

本発明にかかる呼制御サーバは、電話端末間特にインターネット電話等の呼を制御するサーバ等に有用である。また、電話端末だけでなく、通信機能を備える情報端末等に接続を制御する通信サーバ等の用途にも応用できる。

本発明の実施の形態における呼制御サーバを用いた電話システムのシステム構成図 本発明の実施の形態における呼制御サーバの機能ブロック図 本発明の実施の形態におけるデータベース部が保持するテーブルの構成図 本発明の実施の形態における通話要求から未通知連絡処理までシーケンス図 本発明の実施の形態における再発呼処理を示すフローチャート 本発明の実施の形態における利用者情報端末テーブルの構成図 本発明の実施の形態における利用者情報端末テーブルの構成図 本発明の実施の形態における利用者情報端末テーブルの構成図 本発明の実施の形態における曜日・時間帯コードテーブルの構成図

符号の説明

１ インターネット電話
２ ルータ
３ ＩＰ網
４ ゲートウェイ
５ ＰＳＴＮ
６ 一般加入者電話
７ 呼制御サーバ
８ ネットワークインターフェース部
９ 発呼情報通知部
１０ メッセージ受付部
１１ 発呼情報音声通知部
１２ 再発呼部
１３ 再発呼情報指定部
１４ 再発呼実行部
１５ 未通知連絡部
１６ データベース部
１７ 利用者情報記憶部
１８ 利用者情報テーブル
１９ 利用者端末情報テーブル
２０ 再発呼先記憶部
２１ 再発呼情報テーブル
２２ 発信者音声メッセージテーブル
２３ 再発呼先情報テーブル
２４ 再発呼履歴記憶部
２５ 再発呼応答履歴テーブル

Claims (8)

1. 電話機能を有する通信端末間の呼を制御する呼制御サーバであって、
   発呼に対して被呼端末が、ビジー状態または呼び出しに応答しない場合、発呼端末から、メッセージを受け付けるメッセージ受付部と、
   前記メッセージを、再発呼先を識別する再発呼先識別子とともに記憶する再発呼先記憶部と、
   前記被呼端末に再発呼を行い、応答の有無を検出し応答があった場合、前記メッセージを前記再発呼先記憶部から読み出して前記被呼端末に通知する再発呼部を具備したことを特徴とする呼制御サーバ装置。
2. 再発呼の回数、再発呼の時間間隔、再発呼を継続する時間を指定する情報のうち少なくとも一つを含む再発呼指定情報を発呼端末から受け付ける再発呼情報指定部を具備し、
   前記再発呼先記憶部は、再発呼先を識別する識別子とともに前記再発呼指定情報を記憶し、
   前記再発呼部は、前記再発呼指定情報の指定に従って再発呼を行うことを特徴とする請求項１記載の呼制御サーバ装置。
3. 前記被呼端末が再発呼に対して応答がなかった場合、前記メッセージが未通知であることを前記発呼端末に通知する未通知連絡部を具備することを特徴とする請求項１記載の呼制御サーバ装置。
4. 前記再発呼先記憶部は、前記再発呼先識別子を複数記憶し、前記再発呼部は前記再発呼先識別子で特定される複数の端末に対して再発呼を行うことを特徴とする請求項１記載の呼制御サーバ装置。
5. 前記再発呼先記憶部は、前記再発呼先識別子とそれにより特定される端末に対する再呼を許す発呼元を特定する発呼元識別子を記憶し、前記再発呼部は、前記再発呼先識別子で特定される複数の端末のうち、再呼を許された端末に対してのみ再呼を行うことを特徴とする請求項１記載の呼制御サーバ装置。
6. 前記再発呼先記憶部は、前記再発呼先識別子とそれにより特定される端末に対する再呼を許す又は禁止する日区分または時間帯を記憶し、前記再発呼部は、前記再発呼先識別子で特定される複数の端末のうち、再呼を許された端末に対してのみ再呼を行うことを特徴とする請求項１記載の呼制御サーバ装置。
7. 前記再発呼先記憶部は、再発呼先識別子とともに前記再発呼先識別子が再発呼に用いられる際の優先順位を示す再発呼優先順位を記憶し、前記再発呼部は、前記再発呼優先順位に基づいて再発呼を行うことを特徴とした請求項４記載の呼制御サーバ装置。
8. 特定の再発呼先に対し再発呼が行なわれた時刻と前記再発呼に対する応答の存否を示す履歴データを記憶する再発呼履歴記憶部を具備し、前記再発呼先記憶部は、前記履歴データを参照して、優先順位を変更することを特徴とする請求項７記載の呼制御サーバ装置。

Images