JP4669790B2 - 着信通知システム、着信通知方法およびプログラム - Google Patents

Description

本発明は、電話の着信を対象のユーザに通知する技術に関する。

企業のコールセンタのように電話の着信が頻繁に発生する機関では、その着信処理に、例えば、CTI（Computer Telephony Integration）技術に基づくコンピュータ制御が導入される。CTI技術を用いることにより、業務の効率化を図ることができる。

また、従来、電話の着信を通知する技術に関し、例えば後述の特許文献１に記載のものが提案されている。特許文献１の技術は、着信電話番号通知装置に接続された受信側電話機が着信に応答しなかった場合、着信電話番号通知装置が、発信元の電話番号を記述した電子メールを受信側のユーザ端末に送信するというものである。
特開２０００−１９６７８０号公報

上記特許文献１に記載の技術によれば、電話機のユーザが、不在中に着信があったことを外出先等にて把握することができる。しかしながら、上記技術にあっては、着信の都度、その旨がメールにより通知されることから、例えば迷惑電話のように、応答の必要がない着信についてもメールが送信される。そうすると、ユーザにとって不要なメールが頻繁に届けられるおそれがあり、結果、ユーザには煩わしい事態となる。

一方、上述のCTI技術を利用すれば、多数の着信を適切に制御できるが、企業等にCTIシステムを導入するには多額のコストが必要とされる。よって、より簡易に導入し得るシステムが求められている。

本発明は、上記課題に鑑みてなされたものであり、電話の着信を通知するシステムの利便性を高めると共に、そのシステムをより簡便に構築する技術を提供することを目的とする。

本発明に係る着信通知システムは、電話網に接続された主装置と、前記主装置に接続され且つ着信履歴に関する更新データを前記主装置への定期的なアクセスにより取得する手段を具備する電話端末とを備え、前記主装置は、前記電話端末への着信が発生したとき、該電話端末が当該着信の発信元への接続を要求するためのアドレス情報を作成する手段と、前記アドレス情報および当該着信履歴を含む更新データを形成し該更新データを前記電話端末に関連付けられた電子文書へ記述する手段と、前記電話端末に関連付けられた電子文書の更新データを該電話端末からのアクセスに応じて供給する手段と、前記電話端末へ供給した更新データのアドレス情報に基づき該電話端末から要求された接続処理を実行する手段と、前記発信元からの新たな着信を転送するための設定を前記電話端末が前記主装置へ要求するための第２のアドレス情報を前記更新データとして前記電子文書へ記述し、前記電話端末から前記第２のアドレス情報を用いて要求された転送設定を実行し、前記転送設定後に前記発信元から前記電話端末への着信が発生したとき当該着信を前記転送設定に従い転送する手段とを有する。

本発明の基本構想は、電子文書を電話端末に関連付けて主装置に保持させておき、主装置が、電話網から電話端末への着信を検知するごとに、その着信履歴を当該電子文書に記述するというものである。電話端末は、電子文書に記述された着信履歴を表す更新データを主装置から定期的に取得する。主装置は、電話端末から更新データのアドレス情報に基づき発せられた接続要求を処理する。これにより、着信履歴の発信元と電話端末とが通話可能に接続される。

主装置が保持する電子文書としては、例えば、RSS（Rich Site Summary あるいはRDF Site Summary）形式の文書とすることができる。その場合、電話端末に、いわゆるRSSリーダを設定し、RSS文書の更新データを定期的に取得する。

本発明によれば、電話端末の着信履歴に関する情報が主装置にて電子文書に記録される。よって、その電子文書から更新データを取得するソフトウェアを電話端末に設定すれば、ユーザは自己への着信を簡易に把握することができる。また、電話端末へ供給される更新データには、発信元への接続要求を行うためのアドレス情報が含まれることから、着信に対するシステム端末からの応答が簡便となる。

図１に、本発明の第１の実施形態の構成を示す。本実施形態のシステムは、電話の公衆網40に接続された構内電話システムの主装置10と、携帯電話機や通話機能を具備するパーソナルコンピュータのようなシステムユーザ端末50とがインターネット60に接続された形態を成す。

主装置10は、図１に示すように、システムユーザ端末50および外部ユーザ端末30間の呼制御をSIP（Session Initiation Protocol）あるいはMEGACO（Media Gateway Control Protocol／H.248）等に基づき実行する通信制御部2と、インターネット60を介したシステムユーザ端末50との通信を制御するWebサーバ制御部3と、通信制御部2及びWebサーバ制御部3間を中継するメイン制御部1とを備える。これらは、主装置10が具備する機能的な構成であり、主装置10のCPU（図示略）が、記憶装置（図示略）にインストールされているプログラムを実行することによる作用に対応するものである。

また、図１に示すように、主装置10は、Webサーバ制御部3が使用するWebページデータ11、システムユーザ認証データ12及び電話帳データ13を有する。Webページデータ11は、従来知られたRSS形式で記述された電子文書であり、システムユーザ端末50を使用するユーザに関連付けられている。ここで、RSSとは、XML（extensible markup language）準拠のマークアップ言語であり、インターネット60上に公開されるWebサイトの見出しや要約などを表すメタデータを構造化して記述するための言語である。

システムユーザ認証データ12は、Webページデータ11にアクセスしようとするシステムユーザ端末50の認証処理に用いるデータである。具体的には、システムユーザ端末50を使用するユーザのID及びパスワードなどである。電話帳データ13は、外部ユーザ端末30の電話番号および端末のユーザ名などを表すデータである。

Webサーバ制御部3は、上記データを用いて、Webページデータ11を更新する処理、及び、Webページデータ11に対するシステムユーザ端末50からのアクセスを制御する処理を行う。これらの処理については、後に詳細に説明する。

システムユーザ端末50は、主装置10からRSS文書であるWebページデータ11の更新データを取得するためのRSSリーダ51を具備する。RSSリーダ51は、定期的に主装置10へアクセスし、対象のWebページデータ11に関する更新データを取得して表示する機能を果たすソフトウェアある。RSSリーダ51は、RSS文書の更新データを取得する手段として広く一般に普及しており、インターネット上にて無料で提供される、いわゆるフリーソフトウェアも存在する。よって、RSSリーダ51の入手およびシステムユーザ端末50への設定は比較的容易である。

図２に示すシーケンスを参照して、外部ユーザ端末30からシステムユーザ端末50に対する着信に関し、主装置10がWebページデータ11を更新するまでの手順について説明する。まず、外部のユーザが外部ユーザ端末30を使用してシステムユーザ端末50に発信すると（S1）、その着信信号が主装置10に届けられる。

主装置10の通信制御部2は、着信信号を受信すると、外部ユーザ端末30の発信者電話番号と着信先のシステムユーザ端末50の電話番号とを検出する。そして、それら発着信電話番号を含む着信通知信号S201をメイン制御部1へ通知する（S2）。これにより、外部ユーザ端末30からシステムユーザ端末50に着信があったことがメイン制御部1へ通知される。

着信通知信号S201を認識したメイン制御部1は、システムユーザ端末50に着信が発生したことを対象のWebページデータ11に掲載すべく、発着信の電話番号を含むWebページ更新要求S101をWebサーバ制御部3へ通知する（S3）。

Webページ更新要求S101を認識したWebサーバ制御部3は、まず、着信先となるシステムユーザ端末50の電話番号を基にシステムユーザ認証データ12から当該ユーザのIDを取得し、このユーザIDおよび発信元の電話番号を用いてコールバック要求URLを作成する（S4）。コールバック要求URLは、外部ユーザ端末30からの着信に対し、システムユーザ端末50が主装置10に接続処理を要求するためのアドレス情報である。

図３に、コールバック要求URLの一例を示す。図示のコールバック要求URLは、Webサーバ制御部3が提供するWebサーバ機能のアドレスである「www.aaa.com」と、システムユーザ端末50からの接続要求を処理するアプリケーションプログラムを表す「callback.asp」と、システムユーザ認証データ12から取得したユーザIDを表す「id=1」と、発信元となる外部ユーザ端末30の電話番号を表す「num=0312345678」とから構成される。

上記のようなコールバック要求URLを作成すると、Webサーバ制御部3は、着信先のシステムユーザ端末50を使用するユーザのWebページデータ11を更新する。より具体的には、今回の着信に関する情報にコールバック要求URLをリンクさせることにより更新データを形成し、この更新データをWebページデータ11に記述する（S5）。着信情報としては、例えば、着信の日時、発信元の電話番号を基に電話帳データ13から取得した外部ユーザの氏名、及び、着信の接続状態等を含む情報とする。

主装置10は、外部ユーザ端末30からの着信信号を受信するごとに、上記処理（S2〜S5）を実行し、Webページデータ11を最新のものに維持する。なお、Webページデータ11に更新データを記述するにあたっては、掲載する着信件数の最大値を予め定義しておくことが望ましい。そして、件数が最大値を超える場合は、より古い記録に最新の情報を上書きすればよい。

次に、図４に示すシーケンスを参照して、主装置10およびシステムユーザ端末50間の交信について説明する。ここでは、主装置10のWebサーバ制御部3にアクセスするためのアドレスが、予めRSSリーダ51に設定されているものとする。

システムユーザ端末50のRSSリーダ51は、主装置10に対し、定期的にWebページデータ11の更新チェック要求S501を送信する。この要求を受けたWebサーバ制御部3は、対象のWebページデータ11を読み出して更新データを抽出し（S6）、これを更新チェック結果S301としてシステムユーザ端末50へ送信する。更新チェック結果S301を受信したシステムユーザ端末50のRSSリーダ51は、それをブラウザ機能により画面表示する（S7）。

図５に、RSSリーダ51により画面表示される更新データの例を示す。図示のリストには、インデックス5a、着信時刻5b、発信元番号5c、発信元5d、着信の接続状態5e、及び、その着信に対する応答の有無を示す応答5fが設定されている。

図５のリストにおいて、例えばインデックス「1」のデータは、「2005/7/25 13:28」に、電話番号「09012345678」の外部ユーザ端末30を使用する「営業部 田中」から着信があり、現在も「着信中」として保留されているが、システムユーザ端末50からは未だ応答されていない状態であることを表す。また、インデックス「2」は、「（株）あいう 鈴木」からの着信は既に切断されているが、その外部ユーザ端末30に対するシステムユーザ端末50からの応答は済ませていることを表す。

ところで、前述したように、主装置10にて作成される更新データとは、着信情報にコールバック要求URLをリンクさせたデータであるが、その着信情報は、RSSリーダ51が表示する上記の項目（5b〜5e）に対応する。また、図５の例では、コールバック要求URLはインデックス5aにリンク付けされているため、各インデックスがアンカー表示されている。

図示のリストにおいて、例えば、インデックス「1」をマウス等でクリックすることにより、図３に示すコールバック要求URLに基づくHTTPリクエストが送信される。なお、アンカー表示を施す箇所は、インデックス5aのみに限らず、例えば全ての項目を対象とする等、適宜変更してよい。

上記のような更新データのアンカー表示箇所がクリックされると（S8）、RSSリーダ51は、リンクされているコールバック要求URLに基づいて、外部ユーザ端末30との接続を要求するためのHTTPリクエストS502を作成し、それを主装置10へ送信する。このHTTPリクエストS502は、主装置10に外部ユーザ端末30及びシステムユーザ端末50間の接続処理を開始させるトリガとしての信号であり、接続の呼制御自体は、通信制御部2による後述の手順により実行される。

主装置10のWebサーバ制御部3は、システムユーザ端末50から上記のHTTPリクエストを受信すると、リクエストの正当性を判定すべく、HTTPに基づくBASIC認証のような認証処理S302により、システムユーザ端末50からユーザのパスワードを取得する。

システムユーザ端末50からパスワードを取得すると、Webサーバ制御部3は、前述のHTTPリクエストに含まれていたユーザIDに対応するパスワードをシステムユーザ認証データ12から読み出す。そして、読み出したパスワードと、今回システムユーザ端末50から取得したパスワードとを照合する（S9）。照合の結果、両者が一致しない場合は（S10：NG）、認証に失敗した旨のHTTPレスポンスS303をシステムユーザ端末50へ送信する。

一方、パスワードの認証に成功した場合（S10：OK）、Webサーバ制御部3は、前述のHTTPリクエストに含まれていた外部ユーザ端末30の電話番号と、システムユーザ端末50のユーザIDとを取り出し、これらを含むコールバック要求S304をメイン制御部1へ通知する（S11）。

ここで、図５のインデックス「1」のように、現時点で外部ユーザ端末30からの着信が保留されているケース、および、同図インデックス「2」のように既に切断されているケースに分けて、以降の主装置10の処理を説明する。

まず、図６のシーケンスを参照して、外部ユーザ端末30からの着信が保留されているケースを説明する。Webサーバ制御部3からのコールバック要求S304を認識したメイン制御部1は、通信制御部2に対し、一時応答要求S102を通知する（S12）。

通信制御部2は、一時応答要求S102を認識すると、外部ユーザ端末30に一時応答を行う。一時応答は、外部ユーザ端末30をシステムユーザ端末50に接続する間のセッションを継続するための応答であり、例えば、「只今おつなぎしています。しばらくお待ちください。」等の音声メッセージの送信でもよい。

続いて、メイン制御部1は、システムユーザ端末50を外部ユーザ端末30に接続するよう要求するコールバック発信要求S103を通信制御部2へ通知する（S13）。コールバック発信要求S103を認識した通信制御部2は、システムユーザ端末50を呼び出す（S14）。この呼び出しにシステムユーザ端末50が応答すると（S15）、通信制御部2は、外部ユーザ端末30に対する前述の一時応答を解除し、外部ユーザ端末30とシステムユーザ端末50との間を通話可能に接続する（S16）。

次に、図７のシーケンスを参照して、外部ユーザ端末30とのセッションが既に切断されているケースについて説明する。メイン制御部1は、Webサーバ制御部3からのコールバック要求S304を認識すると、通信制御部2に対し、外部ユーザ端末30及びシステムユーザ端末50の電話番号と共にコールバック発信要求S103を通知する。

コールバック発信要求S103を認識した通信制御部2は、システムユーザ端末50を呼び出す（S21）。この呼び出しにシステムユーザ端末50が応答すると（S15）、通信制御部2は、外部ユーザ端末30に発信する（S23）。そして、外部ユーザ端末30が応答すると（S24）、この外部ユーザ端末30とシステムユーザ端末50との間を通話可能に接続する（S25）。

以上説明した第１の実施形態によれば、ユーザが外出先等にて自己への着信を把握するにあたり、システムユーザ端末50に、広く普及しているRSSリーダ51を設定すればよいことから、システムの導入が容易となる。また、RSSリーダ51が表示する着信情報にはコールバック要求URLがリンクされているので、ユーザのワンクリック操作により、自動的に外部ユーザ端末30へ接続される。よって、ユーザの利便性が高められる。

図８に、本発明の第２の実施形態の構成を示す。本実施形態は、システムユーザ端末50に対する着信の転送を可能とするものである。なお、図８のシステム構成は、主装置10に転送先データ14を保持させる以外は、図１に示す第１の実施形態の構成と同様であり、説明を省略する。

図９に示すシーケンスを参照して、主装置10がWebページデータ11を更新するまでの手順について説明する。外部ユーザ端末30がシステムユーザ端末50に発信し（S30）、その着信信号を主装置10が受信すると、通信制御部2が、外部ユーザ端末30の発信者電話番号と着信先のシステムユーザ端末50の電話番号とを検出する。通信制御部2は、それらの電話番号を含む着信通知信号S201をメイン制御部1へ通知する（S31）。

メイン制御部1は、着信の転送先を示す転送先データ14を参照し、外部ユーザ端末30の電話番号に転送先が設定されているか否かを判定する。その結果、外部ユーザ端末30に転送先が設定されてる場合は（S32：Yes）、後述の転送処理を行う。また、転送先の設定が無い場合（S32：No）、メイン制御部1は、Webサーバ制御部3に対し、今回の発着信電話番号を通知すると共に、Webページデータ11の更新を要求する（S33）。

Webサーバ制御部3は、Webページ更新要求S101を認識すると、コールバック要求URLおよび転送先設定要求URLを作成する（S34）。コールバック要求URLは、前述の実施形態にて説明したものと同様のものである。

一方の転送先設定要求URLは、対象の外部ユーザ端末30からの新たな着信を、他のシステムユーザ端末50へ転送することを登録するための情報であり、本発明における第２のアドレス情報に対応するものである。Webサーバ制御部3は、図３により説明したコールバック要求URLの構成に準じた構成の転送先設定要求URLを形成する。より具体的には、転送先設定要求URLの場合、図３より、コールバック要求を処理するアプリケーションに替えて、転送先の設定要求を処理するアプリケーションとすると共に、転送先の電話番号を追加した構成とすればよい。

続いて、Webサーバ制御部3は、対象のユーザのWebページデータ11を更新する。すなわち、作成したコールバック要求URLおよび転送先設定要求URLを着信情報にリンクさせることにより更新データを形成し、これをWebページデータ11に記述する（S35）。上記の両URLをリンクさせた状態の更新データについては、後に説明する。

次に、図１０に示すシーケンスを参照して、着信の転送先の登録手順について説明する。システムユーザ端末50がRSSリーダ51によりWebページデータ11の更新チェック要求S501を送ると、主装置10のWebサーバ制御部3が、対象のWebページデータ11を読み出し、更新データを抽出する（S36）。そして、その更新データを更新チェック結果S301としてシステムユーザ端末50へ送信する。

上記の一連の処理は、前述の実施形態と同様であるが、本実施形態においてシステムユーザ端末50に提供される更新データには、コールバック要求URLにリンクされた項目に加え、転送先設定要求URLにリンクされた項目が設定されている。

図１１に、本実施形態の更新データの例を示す。図示の更新データのリストには、オプション11aの項目が設けられており、本実施形態では、この項目に、転送先設定要求URLをリンク付けした「転送設定」がセットされる。なお、転送先設定要求URLをさせる項目は、図示の例に限らず、例えば「（株）あいう 鈴木」のような発信元の項目としてもよい。

システムユーザ端末50では、RSSリーダ51が主装置10からの更新チェック結果S301を画面表示することにより、図１１に示すような前述の更新データリストが表示される（S37）。ここで、図示のリストにおいて、例えば、インデックス「2」の発信元について、着信の転送先を登録する場面を想定する。

図１１のインデックス「2」のオプション11aにアンカー表示されている「転送設定」がマウス等によりクリックされると（S38）、RSSリーダ51は、そこにリンクされている転送先設定要求URLに基づいて、転送先の登録を要求するためのHTTPリクエストS503を作成し、それを主装置10へ送信する。このHTTPリクエストS503は、主装置10に転送先の登録処理を開始させるトリガとしての信号である。

主装置10のWebサーバ制御部3は、システムユーザ端末50から上記のHTTPリクエストを受信すると、前述の実施形態と同様な認証処理S302およびパスワードの照合（S39）により、リクエストの正当性を判定する。その結果、パスワードが一致しない場合は（S40：NG）、認証に失敗した旨のHTTPレスポンスS303をシステムユーザ端末50へ送信する。

次に、図１２のシーケンスを参照して、上記認証に成功した場合（S40：OK）の処理について説明する。HTTPリクエストの正当性が認められた場合、Webサーバ制御部3は、ユーザに着信の転送先を設定させるためのWebページを読み出し、それをHTTPレスポンスS305としてシステムユーザ端末50へ送信する（S41）。このWebページは、予め主装置10に保存しておいたものを利用すればよい。

システムユーザ端末50は、受信したWebページをWebブラウザで表示する。そして、このページに転送先のデータが入力され、入力が確定すると、転送先のデータが記述されたWebページを供給するHTTPリクエストS504を作成し、これを主装置10へ送信する（S42）。

上記のHTTPリクエストS504を受けたWebサーバ制御部3は、リクエストから転送先の電話番号、外部ユーザ端末30の電話番号、および、システムユーザのID等を取り出し、これらと共に転送先設定要求S306をメイン制御部1へ通知する（S43）。

メイン制御部1は、転送先に関し通知されたデータを転送先データ14における対象のレコードに記述する（S44）。図１３に、転送先データ14の例を示す。図示の転送先データ14には、転送先の登録を要求したシステムユーザのユーザID13aと、対象となる発信元電話番号13bおよび発信元13cと、転送先13dの電話番号とが設定されている。

図１３に示す一覧において、例えばユーザID「1」の転送データは、図１１のインデックス「2」に掲載されている発信元「（株）あいう 鈴木」について登録されたレコードである。これにより以降、電話番号「0398765432」の「（株）あいう 鈴木」から着信があった場合、その着信は、ユーザID「1」に対応するシステムユーザ端末50でなく、自動的に「09033334444」の端末へ転送されることになる。

図１４のシーケンスを参照して、外部ユーザ端末30に転送先が設定されている場合の処理（図９・S32：Yes）について説明する。着信の発信元となる外部ユーザ端末30に転送先が設定されている場合、メイン制御部1は、転送先の電話番号と着信先変更要求S104とを通信制御部2へ通知する（S45）。着信先変更要求S104を認識した通信制御部2は、着信先をシステムユーザ端末50から転送先へ変更し、その転送先に対し着信処理を行う（S46）。

以上説明した第２の実施形態によれば、RSSリーダ51が収集する更新データを利用して、外部ユーザ端末30からの着信の転送先を登録することができる。これにより、転送先の設定を簡易に行うことができる。

図１５に、本発明の第３の実施形態の構成を示す。本実施形態は、外部ユーザ端末30からの着信を複数のシステムユーザ端末50へ通知するものである。なお、図１５のシステム構成は、主装置10に着信通知先データ15を保持させる以外は、図１に示す第１の実施形態の構成と同様であり、説明を省略する。

着信通知先データ15は、外部ユーザ端末30からの着信の通知先をシステムユーザ端末50ごとに設定したものであり、例えば、システムユーザ端末50から主装置10に対し予め所定のWebページにて登録しておく。

図１６に、着信通知先データ15の例を示す。着信通知先データ15には、システムユーザのユーザID16aと、ユーザごとに登録された着信通知先16bとが設定されている。図示の例において、例えば、ユーザID「1」にはユーザID「2」、「3」、「4」及び「5」が設定されている。これは、ユーザID「1」に対応するシステムユーザ端末50に対し着信があった場合、その着信の旨がユーザID「2」〜「5」のWebページデータ11に記載されることを意味する。

図１７のシーケンスを参照して、外部ユーザ端末30からの着信に関し主装置10がWebページデータ11を更新するまでの手順について説明する。なお、前述の実施形態と同様な部分については簡略的に説明する。

外部ユーザ端末30がシステムユーザ端末50に発信し（S50）、その着信信号を主装置10が受信すると、通信制御部2が、着信通知信号S201をメイン制御部1へ通知する。着信通知信号S201を認識したメイン制御部1は、Webサーバ制御部3にWebページ更新要求S101を通知する。

Webサーバ制御部3は、Webページ更新要求S101を認識すると、着信先となるシステムユーザ端末50に関し設定されている着信通知先を、図１６に示すような着信通知先データ15から取得する（S51）。そして、本来の着信先と、着信通知先データ15に設定されている全ての通知先とについて、前述のコールバック要求URLを作成する（S52）。すなわち、図３に示す例を用いれば、「id=1」のようなユーザIDの値を、対象の通知先に応じて設定したものを作成すればよい。

Webサーバ制御部3は、作成したコールバック要求URLを着信情報にリンクさせた更新データを、対象の着信先のWebページデータ11にそれぞれ記述する（S53）。これにより、例えば、図１６のユーザID「1」に対する着信については、このID「1」のWebページデータ11のほか、ユーザID「2」〜「5」に対応する複数のWebページデータ11に更新データが掲載される。

次に、図１８のシーケンスを参照して、主装置10及びシステムユーザ端末50間の交信について説明する。ユーザAおよびユーザBの各システムユーザ端末（50）は、主装置10に対し、定期的にWebページデータ11の更新チェック要求S501A／S501Bを送信する。

Webサーバ制御部3は、各システムユーザ端末（50）からの更新チェック要求を受信すると、それぞれのWebページデータ11を読み出して更新データを抽出し（S56）、これを更新チェック結果S301A／S301Bとして対象のシステムユーザ端末（50）へ送信する。

各システムユーザ端末（50）は、主装置10から受信した更新チェック結果をブラウザ機能により画面表示し（S57）、表示した更新データのアンカー表示箇所がクリックされると、外部ユーザ端末30との通話接続を要求するHTTPリクエストを送信する。以降の処理手順は、前述の実施形態と同様であり、説明を省略する。

以上説明した第３の実施形態によれば、RSSリーダ51を利用して、あるシステムユーザ端末50への着信を他のシステムユーザ端末50により把握することができる。これにより、例えばコールセンタなどにおいて、本来の着信先となるユーザが応答できない場合であっても、他のユーザにより応答することができ、結果、迅速な対応が可能となる。

上記実施形態では、本発明における電子文書の形式がRSSであったが、本発明の適用範囲は、RSSに限らず他の形式であってもよい。例えば、XML以外のマークアップ言語、あるいは、その言語に準拠したものでもよい。また、例えば、主装置（10）および電話端末（50）間において、更新データを表す構造体を予め定義しておき、その構造体を主装置から電話端末に供給するという形態であってもよい。

本発明は、複数の電話端末の呼制御を主装置により制御する種々のシステムに好適である。例えば、多くの社員がオフィスに常駐しない企業にあっては、各社員が外出先等にて、自己への着信をリアルタイムで知ることができ、顧客などへの迅速な対応が可能となる。また、個人利用にあっては、例えば、あるユーザに対し頻繁に発生する迷惑電話を自動的に他の登録メンバに知らせることができる。この場合、予め警備会社等をメンバに登録しておくことにより、迷惑電話の早急な解決を図ることができる。

本発明の第１の実施形態の構成を示すブロック図である。 第１の実施形態の処理手順を示すシーケンス図である。 実施形態のコールバック要求URLを説明するための説明図である。 第１の実施形態の処理手順を示すシーケンス図である。 第１の実施形態における更新データを説明するための説明図である。 第１の実施形態の処理手順を示すシーケンス図である。 第１の実施形態の処理手順を示すシーケンス図である。 本発明の第２の実施形態の構成を示すブロック図である。 第２の実施形態の処理手順を示すシーケンス図である。 第２の実施形態の処理手順を示すシーケンス図である。 第２の実施形態における更新データを説明するための説明図である。 第２の実施形態の処理手順を示すシーケンス図である。 第２の実施形態における転送先データを説明するための説明図である。 第２の実施形態の処理手順を示すシーケンス図である。 本発明の第３の実施形態の構成を示すブロック図である。 第３の実施形態における着信通知先データの説明図である。 第３の実施形態の処理手順を示すシーケンス図である。 第３の実施形態の処理手順を示すシーケンス図である。

符号の説明

１０ 主装置
１：メイン制御部、２：通信制御部、３：Webサーバ制御部、１１：Webページデータ、１２：システムユーザ認証データ、１３：電話帳データ
３０ 外部ユーザ端末
４０ 公衆網
５０ システムユーザ端末
５１ RSSリーダ
６０ インターネット

Claims (11)

1. 電話網に接続された主装置と、前記主装置に接続され且つ着信履歴に関する更新データを前記主装置への定期的なアクセスにより取得する手段を具備する電話端末とを備え、
   前記主装置は、
   前記電話端末への着信が発生したとき、該電話端末が当該着信の発信元への接続を要求するためのアドレス情報を作成する手段と、
   前記アドレス情報および当該着信履歴を含む更新データを形成し該更新データを前記電話端末に関連付けられた電子文書へ記述する手段と、
   前記電話端末に関連付けられた電子文書の更新データを該電話端末からのアクセスに応じて供給する手段と、
   前記電話端末へ供給した更新データのアドレス情報に基づき該電話端末から要求された接続処理を実行する手段と、
   前記発信元からの新たな着信を転送するための設定を前記電話端末が前記主装置へ要求するための第２のアドレス情報を前記更新データとして前記電子文書へ記述し、前記電話端末から前記第２のアドレス情報を用いて要求された転送設定を実行し、前記転送設定後に前記発信元から前記電話端末への着信が発生したとき当該着信を前記転送設定に従い転送する手段とを有することを特徴とする着信通知システム。
2. 前記主装置は、前記電話端末へ供給した更新データに関し該電話端末から要求された処理の諾否を判定する手段を有することを特徴とする請求項１記載の着信通知システム。
3. 前記主装置は、前記電話端末に関し形成した更新データを該電話端末を含む複数の電話端末に対応する電子文書へ記述することを特徴とする請求項１又は２記載の着信通知システム。
4. 前記主装置は、電子文書に記述すべき更新データとして、前記電話端末の着信履歴を表す情報に当該アドレス情報をリンクさせたデータを形成することを特徴とする請求項１乃至３のいずれか１項に記載の着信通知システム。
5. 前記電子文書がRSS形式の電子文書であることを特徴とする請求項１乃至４のいずれか１項に記載の着信通知システム。
6. 電話網に接続された主装置と該主装置に接続され且つ着信履歴に関する更新データを前記主装置への定期的なアクセスにより取得する手段を具備する電話端末とを備えるシステムの前記主装置が、
   前記電話端末への着信が発生したとき、該電話端末が当該着信の発信元への接続を要求するためのアドレス情報を作成するステップと、
   前記アドレス情報および当該着信履歴を含む更新データを形成し該更新データを前記電話端末に関連付けられた電子文書へ記述するステップと、
   前記電話端末に関連付けられた電子文書の更新データを該電話端末からのアクセスに応じて供給するステップと、
   前記電話端末へ供給した更新データのアドレス情報に基づき該電話端末から要求された接続処理を実行するステップと、
   前記発信元からの新たな着信を転送するための設定を前記電話端末が前記主装置へ要求するための第２のアドレス情報を前記更新データとして前記電子文書へ記述するステップと、
   前記電話端末から前記第２のアドレス情報を用いて要求された転送設定を実行するステップと、
   前記転送設定後に前記発信元から前記電話端末への着信が発生したとき当該着信を前記転送設定に従い転送するステップとを実行することを特徴とする着信通知方法。
7. 前記主装置が、前記電話端末へ供給した更新データに関し該電話端末から要求された処理の諾否を判定するステップを実行することを特徴とする請求項６記載の着信通知方法。
8. 前記主装置が、更新データを電子文書へ記述する前記ステップにおいて、前記電話端末に関し形成した更新データを該電話端末を含む複数の電話端末に対応する各電子文書へ記述することを特徴とする請求項６又は７記載の着信通知方法。
9. 前記主装置が、更新データを電子文書へ記述する前記ステップにおいて、電子文書に記述すべき更新データとして、前記電話端末の着信履歴を表す情報に当該アドレス情報をリンクさせたデータを形成することを特徴とする請求項６乃至８のいずれか１項に記載の着信通知方法。
10. 前記電子文書がRSS形式の電子文書であることを特徴とする請求項６乃至９のいずれか１項に記載の着信通知方法。
11. 請求項６乃至１０のいずれか１項に記載の着信通知方法を、電話網に接続された主装置と該主装置に接続され且つ電子文書の更新データを前記主装置への定期的なアクセスにより取得する手段を具備する電話端末とを備えるシステムの前記主装置に実行させることを特徴とするプログラム。

Images