JP2010124304A - 通話制御システム、通信制御方法および通信制御プログラム - Google Patents

Abstract

【課題】発信の内容および着信側の端末の状態に応じた適切な発信制御を可能にする。
【解決手段】通話制御システムは、発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、資料データ記録部３１にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得部２１と、前記着信側の端末を特定する情報を基に、状態データ記録部１１にアクセスして、着信側の端末の状態を示す状態データを取得する着信側状態取得部２２と、資料特性取得部２１が取得した特性データと、着信側状態取得部２２が取得した状態データとを用いて、発信をするか否かを判定する発信判定部２３と、発信判定部２３の判定に従って発信処理を実行する発信処理部２４とを備える。
【選択図】図１

Description

本発明は、電話の発信要求を受信して発信処理を実行する通話制御技術に関する。

近年、端末の画面に表示された電話番号やＵＲＬ等をクリックすると自動的に電話を発信することが可能となるクリックツーコール(Ｃｌｉｃｋ−ｔｏ−ｃａｌｌ)システムが開発されている。このようなシステムにより、例えば、現在閲覧中のＷｅｂページ（資料の一例）に関する問合せを簡単にできるようになった。

しかし、簡単に問合せできるようになったために、以下のような事態が発生している。例えば、ある社員が、社外秘資料について問合せをクリックツーコールで行った場合、社外にいる担当者に電話が繋がる場合がある。このような場合、担当者は社外にいるため社外秘資料の内容については詳細を説明することができないため、うまく意思疎通が行えない事態が発生する。このような場合、問い合わせた側も問い合わせられた側も困る。

また、逆に、問い合わせを受けた担当者は、社外にいるにもかかわらず、その場で社外秘資料の内容について話してしまう事態も発生し得る。この場合は、秘密情報の漏えいにつながり、ビジネスに重大なダメージを与える可能性もある。なお、これらの事態は、クリックツーコールに限らず、その他、あらゆる電話発信でも発生しうる。

このような事態を防ぐために、例えば、社内から社外への発信、すなわち、内線から外線への転送を抑止することが考えられる。しかし、この方法では、社外秘情報とは関係のない連絡事項も連絡できなくなり、携帯電話の利便性を損なうことになる。

そこで、ユーザにとって有用な通信のみ接続するために、通信の相手先となる発信側と着信側との相互のユーザの状態を反映した情報に基づいて通信路の接続を制御するためのシステムが提案されている（例えば、特許文献１参照）。
特開２００６−２７９２１８号公報

しかしながら、上記従来技術では、発信の内容および着信側の端末の状態に応じて適切な発信制御を行うことができなかった。ゆえに、本発明は、発信の内容および着信側の端末の状態に応じた適切な発信制御を可能にすることを目的とする。

本願に開示する通話制御システムは、着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理を実行する通話制御システムであって、前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得部と、前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得部と、前記資料特性取得部が取得した前記特性データと、前記着信側状態取得部が取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定部と、前記発信判定部の判定に従って発信処理を実行する発信処理部とを備える。

上記通話制御システムが発信要求を受信した場合、資料特性取得部が、発信要求に関係する資料の特性を示す特性データを取得し、着信側状態取得部が、着信側の端末の状態を示す状態データを取得する。そのため、発信判定部は、当該発信に関係する資料の特性と、着信側の端末の状態とに応じて発信の可否が判定することができる。この判定結果にしたがって、発信処理部が発信処理を実行する。これにより、発信の内容に関係する資料の特性および着信側の端末の状態を考慮した適切な発信制御が可能になる。すなわち、発信の内容および着信側の端末の状態に応じた適切な発信制御が可能になる。例えば、着信端末側のユーザが、資料に関連する用件について話すのに適切でない状態である場合等に発信を抑止することが可能になる。

なお、ここで、「資料」とは、電話を発信するユーザがコンピュータを用いてアクセスすることができるデータであって、その内容は特に限定されない。

また、「発信要求に関係する資料に関する情報」とは、当該資料そのものまたは資料の特性を示すデータにアクセスするための情報である。この情報は、例えば、ＵＲＬやその他のアドレスのように、資料またはその特性データの位置を直接示す情報の他、資料を特定するための情報のように、資料またはその特性データへアクセスするために間接的に用いられる情報も含まれる。

本発明の実施形態における通話制御システムにおいて、前記資料特性取得部は、前記発信要求に関係する資料に関する情報として、前記資料のアドレスを受け取り、前記アドレスを用いて資料にアクセスし、資料に含まれるテキストデータに所定のキーワードが含まれるか否かにより、当該資料の特性データを取得することができる。これにより、資料特性取得部は、発信要求に関係する資料に含まれるテキストデータに基づいて資料の特性データを取得することができる。

本発明の実施形態における通話制御システムにおいて、前記資料特性取得部は、前記発信要求に関係する資料に関する情報として、前記発信要求の発信ユーザを識別するデータを受け取り、前記発信ユーザがアクセス可能な資料群を提供するサーバにおけるアクセス履歴を記録するアクセス履歴記録部にアクセスし、前記発信ユーザのアクセス履歴に基づいて前記発信要求に関係する資料を特定し、当該特定した資料の特性データを取得することができる。

上記構成において、資料特性取得部は、発信ユーザのアクセス履歴により発信要求に関連する資料を特定することができ、そのために、資料の特性データを取得することができる。例えば、資料特性取得部は、発信ユーザが最後にアクセスした資料を、関係する資料と特定してもよい。あるいは、発信ユーザがアクセスした資料であって発信要求の着信側の端末を表すデータが含まれる資料を、関係する資料と特定することもできる。

本発明の実施形態における通話制御システムにおいて、前記資料特性取得部は、前記資料の公開可能な範囲を示すデータを前記特性データとして取得し、前記着信側状態取得部は、前記着信側の端末の場所を示すデータを前記状態データとして取得し、前記発信判定部は、前記特性データが示す公開可能な範囲と、前記状態データが示す着信側の端末の場所に応じて、前記発信要求にかかる発信をするか否かを判定することができる。

これにより、発信要求に関係する資料の公開可能な範囲と、着信側の端末の場所に応じた適切な発信制御が可能になる。例えば、資料公開可能な範囲外にいる端末のユーザに対して、当該資料に関して問い合わせる発信を自動的に抑止するといった、発信制御が可能になる。

本発明の実施形態における通話制御システムにおいて、前記資料特性取得部は、前記資料の提供元を示すデータを前記特性データとして取得し、前記着信側状態取得部は、前記着信側の端末のユーザの所属を示すデータを前記状態データとして取得し、前記発信判定部は、前記特性データが示す前記資料の提供元と、前記状態データが示す前記着信側の端末のユーザの所属に応じて、前記発信要求にかかる発信をするか否かを判定することができる。

これにより、発信要求に関係する資料の提供元と、着信側の端末のユーザの所属に応じた適切な発信制御が可能になる。例えば、資料の提供元に所属しないユーザに対して、その資料に関して問い合わせる発信を自動的に抑止するといった発信制御が可能になる。

本発明の実施形態における通話制御システムは、前記発信判定部が前記発信要求にかかる発信をしないと判定した場合に、前記発信要求に関係する資料に関する情報を表す音声データを生成し、前記発信要求の前記着信側の端末からアクセス可能な状態で記録する処理を開始する録音制御部をさらに備える構成であってもよい。

録音制御部により、前記発信要求にかかる発信をしない場合にも、着信側の端末のユーザは、その発信要求に関係する資料に関する音声データにアクセスすることができ、その資料に関係する要件で電話発信があったことを知ることができる。

本発明の実施形態における通話制御システムは、前記発信要求に特定の番号が付加されているか否かを判定し、前記特定の番号が付加されている場合は、前記発信判定部に前記判定をさせずに、前記発信処理部に前記発信処理を実行させる特番判定部をさらに備える構成であってもよい。

上記構成により、例えば、ユーザが発信する際に発信要求に特定の番号を付加した場合は、発信処理部による判定はされずに発信される。すなわち、ユーザは、電話発信の際に発信処理の有無を制御することができる。

コンピュータを上記通話制御システムとして動作させる通話制御プログラムおよび通話制御プログラムを記録した記録媒体、並びに、上記通話制御システムにより実行される通話制御方法も、本発明の実施形態に含まれる。

本願の開示によれば、発信の内容および着信側の端末の状態に応じた適切な発信制御が可能になる。

（第１の実施形態）
［システム構成］
図１は、第１の実施形態にかかる通話制御システムを含むシステム全体の構成を示す機能ブロック図である。図１に示すシステムは、ネットワーク４を介して互いに接続された呼制御サーバ１、通話制御システム２、資料管理サーバ３、ユーザ端末５を含んでいる。呼制御サーバ１は、通話端末７ａ、７ｂを含む電話網６に接続されている。

［資料管理サーバ３］
図１に示すシステムにおいて、資料管理サーバ３は、ユーザ端末５からアクセス可能なデータである資料を格納する資料データ記録部３１を備える。資料の内容は特に限定されないが、本実施形態では、一例として、資料の中に、その内容についての問い合わせ先である電話番号等の連絡先を示す情報が含まれる場合について説明する。資料管理サーバ３は、例えば、ＨＴＴＰプロトコルを用いて、資料をページごとに提供するＨＴＴＰサーバで構成することができる。

［ユーザ端末５］
ユーザ端末５は、ユーザＡからの入力に基づいて資料管理サーバ３から資料を取得して表示する機能、および通話制御システム２に対して、ユーザＡからの入力に基づく電話の発信要求を送信する機能を備える。例えば、ユーザ端末５は、ブラウザがインストールされたコンピュータで構成することができる。この場合、ユーザ端末５は、ユーザＡから資料取得を指示する入力を受け付けると、資料データ記録部３１に格納された資料を取得して表示する。また、ユーザ端末５は、表示した資料中の連絡先（例えば、電話番号とする）の指定および当該連絡先への発信要求を、ユーザＡから受け付ける。例えば、ユーザＡは、資料中の電話番号または所定のボタンをクリックすることで、電話番号の指定および発信要求をすることができる。ユーザ端末５は、発信要求を受けると、通話制御システム２に対して、発信要求を送信する。発信要求には、ユーザＡが指定した電話番号（着信側の電話番号）が含まれる。

一例として、ユーザ端末５、資料管理サーバ３および通話制御システム２の間の通信にＨＴＴＰプロトコルを用いることができる。この場合、資料中の電話番号がクリックされると、ユーザ端末５のブラウザは、ＨＴＴＰリクエストを、通話制御システム２に対して送信する。ＨＴＴＰリクエストには、ユーザＡのユーザＩＤ、クリックされた電話番号、およびその電話番号を表示していた資料のＵＲＬを含めることができる。これにより、発信要求とともに、発信ユーザを識別する情報、着信側の電話番号、および関連する資料にアクセスするための情報を通話制御システム２に送信することができる。本実施形態では、ユーザ端末５の画面に表示された電話番号やボタンをクリックすることにより電話発信が可能となるクリックツーコールが実現される場合を例に挙げて説明する。

なお、ユーザ端末５における処理は、上記のＨＴＴＰプロトコルを用いるブラウザに限られない。また、ブラウザで表示した資料の電話番号が指定されると、自動的に通信ソフトウエアが起動され、当該通信ソフトウエアにより発信処理が実行される構成であってもよい。

［通話制御システム２］
通話制御システム２は、発信要求を受け付けて、発信に関係する資料と着信側の端末の状況とに応じて発信の要否を判定し、必要と判定した場合に、発信処理を呼制御サーバ１へ依頼する。そのため、通話制御システム２は、資料特性取得部２１、着信側状態取得部２２、発信判定部２３、発信処理部２４、判定表記録部２５および番号記録部２６を有する。

資料特性取得部２１は、例えば、通話制御システムがユーザ端末５から電話の発信要求を受信した際に、当該発信要求に関係する資料に関する情報（例えば、資料のＵＲＬ）も受け付ける。そして、資料特性取得部２１は、資料管理サーバ３の資料データ記録部３１にアクセスして、この資料のＵＲＬを基に、当該資料の特性を示す特性データを取得する。

資料特性取得部２１は、例えば、資料データ記録部３１に資料のＵＲＬと対応付けて記録された資料の特性を示すデータから特性データを取得してもよいし、資料自体にアクセスして、資料の内容から特性データを生成してもよい。特性データは、資料の特性（性質）を表すものであれば、その内容は特に限定されない。本実施形態では、一例として、資料の公開可能範囲を示す公開レベルが特性データとして取得される場合について説明する。

図２Ａは、資料データ記録部３１に、資料のＵＲＬと対応付けて記録された資料の特性を示すデータの一例を示す図である。図２Ａに示す例では、資料のＵＲＬごとに、公開レベルを示す情報（「社外秘」または「公開」）が記録されている。

着信側状態取得部２２は、通話制御システム２が受信した発信要求の着信側の端末の状態を示す状態データを、呼制御サーバ１の状態データ記録部にアクセスして取得する。呼制御サーバ１は、例えば、電話網６を介して通信可能な通話端末７ａ、７ｂそれぞれから状態を示すデータを取得し、状態データ記録部１１に記録しておくことができる。

ここで、状態を示すデータの内容は、端末の状態を表すものであれば、特に限定されない。本実施形態では、一例として、通話端末のプレゼンスが状態データとして取得される場合について説明する。通話端末がＩＰ電話の場合、例えば、ＳＩＭＰＬＥ（SIP for Instant Messaging Presence Leveraging Extensions）規格を用いて、プレゼンス機能を実現することができる。この場合、呼制御サーバがプレゼンスサーバとなり、各通話端末７ａ、７ｂがＰＵＡ（Presence User Agent）となる。

図２Ｂは、状態データ記録部１１に記録される状態データの一例を示す図である。図２Ｂに示す例では、各通話端末の電話番号と、各通話端末のプレゼンスが対応付けられて記録されている。

発信判定部２３は、資料特性取得部２１が取得した特性データと、着信側状態取得部２２が取得した状態データとを用いて、通話制御システムが受信した発信要求にかかる発信をするか否かを判定する。判定表記録部２５には、発信処理を実行する条件を表すデータである判定表が記録されている。発信判定部２３は、この判定表を参照し、前記取得した特性データと状態データの組み合わせと、判定表の示す条件とを比較することによって、発信の要否を判定する。

図２Ｃは、判定表記録部２５に記録される判定表の一例を示す図である。図２Ｃに示す例では、判定表には、複数パターンの、特性データ（資料特性）と状態データ（着信側状態）との組み合わせと、各組み合わせに対応する処理（「発信」あるいは「抑止」）とが対応付けられて記録されている。この場合、発信判定部２３は、取得した特性データと状態データの組み合わせに対応する処理が「許可」であれば、発信すると判定し、「抑止」であれば、発信しないと判定する。

なお、発信判定部２３の判定処理は、上記の判定表を用いる処理に限られない。例えば、特性データと、状態データを引数とし、判定結果を戻り値とする関数（メソッド）を実行してもよい。

発信処理部２４は、発信判定部２３の判定結果に従って発信処理を実行する。例えば、発信判定部２３が、発信すると判定した場合には、発信処理部２４が、呼制御サーバ１に、発信ユーザの通話端末の電話番号と、着信側の通話端末の電話番号を通知し、これらの電話番号間の呼接続を要求する。発信判定部２３が、発信しない（抑止する）と判定した場合、発信処理部２４は、発信要求にかかる発信処理を抑止する。

通話制御システム２が、発信要求の受信時に発信ユーザの識別子を受け取った場合、発信処理部２４は、番号記録部２６を参照して、発信ユーザの識別子を発信ユーザの電話番号に変換する。変換された電話番号は、呼制御サーバ１への呼接続要求に着信側の通話端末の電話番号とともに含められる。そのため、番号記録部２６には、発信ユーザの識別子と電話番号とを対応付ける対応番号データが記録されている。図２Ｄは、対応番号データの一例を示す図である。図２Ｄに示す例では、ユーザの識別子ごとに電話番号が対応付けられて記録されている。

[呼制御サーバ１]
呼制御サーバ１は、電話網６における通話端末７ａ、７ｂ間の呼の接続を制御する。また、呼制御サーバ１は、通話制御システム２の発信処理部２４から、発信側および着信側双方の通話端末の電話番号と、呼接続要求とを受信し、通話端末間の呼接続を開始する機能を備える。例えば、電話網６がＩＰ電話網である場合は、呼制御サーバ１はＳＩＰサーバとして機能してもよいし、電話網６が交換網であれば交換機として構成されてもよい。

呼制御サーバ１、通話制御システム２、資料管理サーバ３およびユーザ端末５、は、例えば、コンピュータを内蔵する専用装置、もしくはパーソナルコンピュータやサーバマシン等の汎用コンピュータにより構成することができる。通話制御システム２における着信側状態取得部２２、資料特性取得部２１、発信判定部２３および発信処理部２４の各機能部の機能は、コンピュータが備えるプロセッサが所定のプログラムを実行することにより実現される。従って、コンピュータを前記各機能部として機能させるためのプログラムおよびそれを記録した記録媒体も本発明の実施形態に含まれる。このことは、後述する図４および図８における各機能部についても同様である。また、判定表記録部２５および番号記録部２６は、コンピュータに内蔵された記録媒体または、コンピュータからアクセス可能な外部記録装置により具現化される。

なお、上記の機能を実現するためのシステム構成は、図１に示す構成に限られない。例えば、通話制御システム２は、呼制御サーバ１、資料管理サーバ３またはユーザ端末５いずれかと同じコンピュータに、上記機能部を実現するためのプログラムをインストールすることにより構成されてもよい。一例として、図１に示す例では、資料管理サーバ３と通話制御システム２を別サーバで構築しているが、これらは同じサーバ上に構築されてもよい。また、ユーザ端末５と通話端末７ａは、同じ端末で構成されていてもよい。

［システムの動作例］
＜ユーザ端末５の動作例＞
次に、図１に示すシステムにおいて、ユーザ端末５が通話制御システム２に対して発信要求を送信する動作の一例について説明する。まず、ユーザＡは、ユーザ端末５を用いて、資料管理サーバ３にログインする。ここでは、ユーザＡのユーザＩＤを“ｔａｋｅ”とする。

一例として、ユーザＡは、資料管理サーバ３の資料データ記録部３１に記録されている「新型PC発表」（ＵＲＬ＝ｈｔｔｐ:／／ｓａｌｅｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｈｉｍｉｔｓｕ．ｈｔｍｌ）に関するページ（資料）をユーザ端末５のブラウザで閲覧する。この資料には、電話を使って簡単に問合せができるように、「担当：営業山下（１００１）」と書かれたクリックツーコール用のリンクが含まれる。このリンクのＵＲＬは、ここでは例として、ｈｔｔｐ：／／ｃｌｉｃｋ２ｃａｌｌ．ｅｘａｍｐｌｅ．ｃｏｍ／ｃｌｉｃｋ２ｃａｌｌ？ｕｓｅｒｉｄ＝ｔａｋｅ＆ｄｅｓｔ＝１００１とする。このＵＲＬにおける“ｃｌｉｃｋ２ｃａｌｌ．ｅｘａｍｐｌｅ．ｃｏｍ”は、クリックツーコールシステムを提供する通話制御システム２を意味している。また、前述したリンクのｕｓｅｒｉｄ＝ｔａｋｅの部分は、ログイン時に入力されたユーザＡのユーザＩＤ“ｔａｋｅ”を使って、資料管理サーバ３が自動的に付加した部分である。これにより、通話制御システム２に発信元（発信者）を識別する情報を伝えることができる。なお、通話制御システム２に発信者を伝える方法は、この方法に限られない。例えば、公知のシングルサインオンシステムとの連携により、ユーザ情報を資料管理サーバ３から通話制御システム２に渡すようにしてもよい。

ユーザＡが、ユーザ端末５の画面に表示された上記リンクをクリックすると、通話制御システム２（ｃｌｉｃｋ２ｃａｌｌ．ｅｘａｍｐｌｅ．ｃｏｍ）に対して、以下のようなＨＴＴＰリクエストが発行される。
ＧＥＴ ／ｃｌｉｃｋｃａｌｌ?ｕｓｅｒｉｄ＝ｔａｋｅ＆ｄｅｓｔ＝１００１
Ｒｅｆｅｒｒｅｒ: ｈｔｔｐ：／／ｓａｌｅｓ．ｅｘａｍｐｌｅ．ｃｏｍ／ｈｉｍｉｔｓｕ．ｈｔｍｌ
Ｒｅｆｅｒｒｅｒ： ヘッダは、ＨＴＴＰ標準に含まれるものであり、リンクが存在していたページをリンク先に伝えるためのヘッダである。ユーザ端末５のブラウザが、このようなヘッダを自動的に付加して、上記ＨＴＴＰリクエストを送信する。これにより、発信要求が通話制御システム２へ送信される。

＜通話制御システム２の動作例＞
図３は、図１に示すシステムにおける通話制御システム２の動作の一例を示すフローチャートである。図３に示すように、通話制御システム２は、例えば、ユーザ端末５からクリックツーコールによる発信要求を受信すると（Ｏｐ１でｙｅｓ）、発信要求に関係する資料（参照元）があるか否かを判断する（Ｏｐ２）。関係する資料があるか否かは、例えば、発信要求に、資料に関する情報（例えば、資料のＵＲＬ等）が含まれているか否かにより判断することができる。

一例として、資料管理サーバ３のページ（資料）がユーザ端末５で表示された場合について説明する。ユーザ端末５に表示されたページ中の電話番号がクリックされると、クリックツーコールの発信要求が、ＨＴＴＰリクエストとして通話制御サーバ２へ通知される。その際、Ｒｅｆｅｒｒｅｒ： ヘッダには、そのページのＵＲＬが含まれたリクエストが通知される。通話制御システム２では、受け取ったＨＴＴＰリクエストのＲｅｆｅｒｒｅｒ： ヘッダにＵＲＬが含まれている場合には、関係する資料（参照元）があると判断することができる。

このように、発信要求に、発信元を識別する情報および着信先を識別する情報に加えて、発信要求時に参照していたページ（資料）を示す情報が含まれているか否かにより、発信要求に関係する資料の有無を判断することができる。

発信要求に関係する資料がない場合（Ｏｐ２でｎｏ）、発信処理部２４が発信処理（Ｏｐ７）を実行する。発信要求に関係する資料がある場合（Ｏｐ２でｙｅｓ）、資料特性取得部２１が、その資料（参照元）の特性データ（ここでは、一例として公開レベル）を、資料管理サーバ３に問い合わせることにより、取得する（Ｏｐ３）。

Ｏｐ３において、資料特性取得部２１は、Ｒｅｆｅｒｒｅｒ：ヘッダに含まれていたＵＲＬを基に、資料管理サーバ３の資料データ記録部３１にアクセスすることができる。一例として、ＲｅｆｅｒｒｅｒのＵＲＬが“ｈｔｔｐ：／／ｅｘａｍｐｌｅ／ｈｉｍｉｔｕ．ｈｔｍｌ”であり、資料データ記録部３１に、図２Ａに示す資料の特性を示すデータが記録されていた場合、資料特性取得部２１は、図２Ａに示すデータからＵＲＬの“ｈｉｍｉｔｕ．ｈｔｍｌ”の部分に対応する “社外秘”という情報を、特性データとして取得する。

着信側状態取得部２２は、発信要求に含まれる着信側の電話番号を基に、呼制御サーバ１の状態データ記録部１１から着信側の通話端末の状態データを取得する（Ｏｐ４）。例えば、着信側状態取得部２２は、ＨＴＴＰリクエストのパラメータｄｅｓｔ＝１００１から、着信者の電話番号“１００１”を取得し、この電話番号“１００１”のユーザが今社内にいるのか社外にいるのかを、呼制御サーバ１に問い合わせる。呼制御サーバ１は、例えば、おっかけ転送（社内から内線番号で発信があったときに、社外に転送する機能）のために、このような社内社外情報を、状態データ記録部１１で管理している。

一例として、状態データ記録部１１に、図２Ｂに示す状態データが記録されていた場合、着信側状態取得部２１は、電話番号“１００１”に対応するプレゼンス“社外”を状態データとして取得する。なお、呼制御サーバ１以外に、社内・社外情報を提供するプレゼンスサーバが存在するような環境であれば、プレゼンスサーバに問い合わせてもよい。

次に、発信判定部２３は、判定表記録部２５の判定表にアクセスし、Ｏｐ３で取得された資料の特性データ“社外秘”とＯｐ４で取得された状態データ“社外”の組み合わせに対応するデータを検索する。（Ｏｐ５）。

一例として、判定表が図２Ｃに示すデータの場合、発信判定部２３は、資料特性（特性データ）＝“社外秘”、着信側状態（状態データ）＝“社外”の組み合わせに対応する処理“抑止”を、検索結果として取得する。すなわち、本例では、判定表には、あらかじめ、公開レベルが“社外秘”で、着信側プレゼンスが“社外”の場合は、発信を“抑止”という情報が記録されているので、“抑止”という処理が検索されることになる。もし、Ｏｐ３で取得された資料の特性データが“社外秘”、Ｏｐ４で取得された着信側の状態データが“社内”であった場合は、処理“許可”が検索結果となる。

発信判定部２３は、検索結果に基づいて発信処理を許可するか否かを決定する（Ｏｐ６）。例えば、検索結果が“抑止”の場合（Ｏｐ６でｎｏ）、発信処理部２４に発信処理を許可せず、発信拒否処理を実行させる（Ｏｐ８）。検索結果が“許可”の場合（Ｏｐ６でｙｅｓ）、発信判定部２３は、発信処理部２４に発信処理を実行させる（Ｏｐ７）。

発信処理部２４は、Ｏｐ７の発信処理では、呼制御サーバ１に対して、呼接続要求を送信する。呼接続要求には、発信側の電話番号と着信側の電話番号が含まれる。ここで、発信処理部２４は、番号記録部２６の対応番号データを参照して、発信ユーザの電話番号を取得することができる。例えば、発信要求受信時に通話制御システム２が受け取った発信元をユーザＩＤが“ｔａｋｅ”である場合、発信処理部２４は、図２Ｄに示す対応番号データの“ｔａｋｅ”に対応する電話番号“３３３３”を発信側の電話番号として取得する。

Ｏｐ８の発信拒否処理においては、発信処理部２４は、例えば、発信元のユーザ端末５に、発信を抑止する旨のメッセージを含むページを返信する。例えば、発信処理部２４は、ＨＴＴＰリクエストに対して、「先方は、現在この件ではお話できない状況にあります」というメッセージを含んだページを返却することができる。

なお、Ｏｐ８における発信拒否処理では、発信ユーザから音声メッセージの入力を受け付けて、着信側の通話端末からアクセス可能な状態で記録する、いわゆる留守番電話サービスが実行されてもよい。

上記の動作により、例えば、資料特性が社外秘であり、着信側状態が社外の場合には、発信を抑止するといった発信制御が可能になる。すなわち、問合せ内容に応じて、通話を接続するかどうかを自動的に判定する仕組みが提供される。その結果、通話内容に応じて不適切な通話が開始されるのを排除できるようになる。具体的な効果として、次のような例が挙げられる。

例えば、着信者側は、社外秘の情報を話せない状況で社外秘資料について問い合わせを受ける心配がなくなる。また、発信者側も着信者側の状況を見て判断する必要がなくなり、気軽に社外秘について問い合わせを行えるようになり、コミュニケーションの円滑化が実現される。さらに、情報管理の観点では、社外にいる社員が、社外秘について電話で聞かれたために、社外にいるにも関わらず、ついうっかり口に出してしまう、といった事態を防ぐことができるようになる。

＜Ｏｐ３：資料特性取得処理の変形例＞
Ｏｐ３において、資料特性取得部２１は、資料特性データにアクセスする代わりに、資料そのものにアクセスし、その資料の内容から特性データを生成してもよい。上記の例においては、資料特性取得部２１は、発信要求のＲｅｆｅｒｒｅｒ：ヘッダのＵＲＬが示す資料管理サーバ３のページ（資料）に、ＨＴＴＰプロトコルを使ってアクセスし、社外秘という文字列がその資料に含まれるか否かにより、公開レベルを判定してもよい。例えば、その資料の特性が社外秘であるか否かは、資料中に「社外秘」または「ｃｏｎｆｉｄｅｎｔｉａｌ」などの公開レベルを制限する言葉が現れるか否かで判断することができる。

また、資料特性取得部２１は、ＵＲＬで示されるページだけでなく、そのページからたどれるリンクで示されるページの特性データを取得してもよい。例えば、ＰＤＦなどの資料の場合は、ＰＤＦにクリックツーコールのリンクが含まれるのではなく、ＰＤＦにアクセスするためのページにクリックツーコールのリンクがある場合がある。そのような場合、ＰＤＦが実質的に関係する資料となる。そのため、クリックツーコールのリンクのあるページだけでなく、そのページに含まれるリンクで辿ることができるページも関係する資料に含めてもよい。例えば、資料特性取得部２１は、クリックツーコールのリンクのあるページに含まれるリンクのＵＲＬで示されるページの特性データも取得することができる。

＜判定表の変形例＞
上記実施形態では、判定表が予め記録される場合を例示したが、通話制御システム２は、通話状態を監視することにより、判定表を生成または更新してもよい。例えば、接続された通話ごとに、関係する資料の特性データ、着信側の状態データ、および通話状態（例えば、通話時間等）を記録しておき、記録したデータを基に判定表を生成することができる。すなわち、特性データおよび状態データの組み合わせと通話の不適切さとの関係を学習して、判定表に反映させることもできる。

具体例を挙げると、特性データおよび状態データの特定の組み合わせ（例えば、資料特性＝「社外秘」および着信側状態＝「社外」の組み合わせ）の通話が、開始から５秒以内で終了するケースの数が閾値を超えた場合に、当該組み合わせの通話は、不適切であると判断することできる。この場合、通話制御システム２は、資料特性＝「社外秘」かつ着信側状態＝「社外」の場合は通話を「抑止」する旨を判定表に記録する。

これにより、通話状態に応じて、自動的に判定表を生成、更新することができる。その結果、状況に応じた適切な判定が可能になる。

＜データ内容の他の例＞
資料特性取得部２１は、資料の特性データとして、資料の提供元の部署を示すデータを取得し、着信側状態取得部２２は、着信側の状態データとして、着信者の現在の所属部署を示すデータを取得してもよい。そして、発信判定部２３は、資料特性取得部２１が取得したデータが示す資料の提供先の部署と、着信側状態取得部２２が取得したデータが示す着信者の現在の所属部署とが一致しない場合に、発信を抑止すると判定することができる。

これにより、ある資料の担当していた者が部署を移動して、すでに担当でなくなったにも関わらず、その資料について問い合わせの電話がかかってくるといった事態を防ぐことができる。この効果は、部署が変わっても電話番号は変更されないシステムにおいて、特に有効となる。

（第２の実施形態）
図４は、第２の実施形態にかかる通話制御システム２ａを含むシステム全体の構成を示す機能ブロック図である。図４において、図１と同じ機能ブロックには同じ番号を付している。

[システムの構成]
図４に示すシステムでは、資料管理サーバ３ａが、アクセス履歴記録部３２を備える。アクセス履歴記録部３２は、ユーザによる資料データ記録部３１へのアクセスの履歴を示すアクセスログを記録する。図５は、アクセスログの一例を示す図である。図５に示す例では、アクセスしたユーザのＩＤ、ＵＲＬおよびアクセス時刻がアクセス順に記録されている。

資料特性取得部２１ａは、発信要求として、ユーザ端末５から発信ユーザのＩＤと、着信側の電話番号を受け取る。資料特性取得部２１ａは、発信要求を受けると、資料管理サーバ３ａのアクセス履歴記録部３２のアクセスログを参照し、発信ユーザが最後にアクセスした資料を特定する。そして、資料特性取得部２１aは、特定した資料の特性データを資料データ記録部３１から取得する。取得する特性データは、上記第１の実施形態と同様である。このように、本実施形態における資料特性取得部２１ａは、資料管理サーバ３ａが管理する履歴情報を利用して、発信ユーザが最後に見たページを資料特性取得の対象にすることができる。

[動作例]
図６は、第２の実施形態の通話制御システム２ａの動作例を示すフローチャートである。図６に示す例では、通話制御システム２ａは、例えば、ユーザ端末５からクリックツーコールによる発信要求を受信すると（Ｏｐ１でｙｅｓ）、発信要求にユーザＩＤが含まれているか否かを判断する（Ｏｐ２１）。

ここでは、一例として、通話制御システム２ａへの発信要求はＨＴＴＰリクエストであり、ＨＴＴＰリクエスト中にＲｅｆｅｒｒｅｒ：ヘッダが存在しない場合の動作例を説明する。ブラウザやＯＳのファイアウォール設定によっては、セキュリティ上の理由からＲｅｆｅｒｒｅｒ：ヘッダを送信しないことがある。

この場合、ユーザＡは、ユーザ端末５に表示された資料中のリンクをクリックすると、クリックツーコールシステム（ＵＲＬは、ｃｌｉｃｋ２ｃａｌｌ．ｅｘａｍｐｌｅ．ｃｏｍ）として機能する通話制御システム２ａに対して、以下のようなＨＴＴＰリクエストが発行される。下記のＨＴＴＰリクエストには、Ｒｅｆｅｒｒｅｒ：ヘッダは存在しない。
ＧＥＴ ／ｃｌｉｃｋｃａｌｌ?ｕｓｅｒｉｄ＝ｔａｋｅ＆ｄｅｓｔ＝１００１
上記ＨＴＴＰリクエストには、発信ユーザのＩＤ“ｔａｋｅ”、および着信側の電話番号 “１００１”が含まれる。通話制御システム２ａは、上記ＨＴＴＰリクエストにはユーザＩＤが含まれると判断する（Ｏｐ２１でｙｅｓ）。

Ｏｐ２１でｙｅｓの場合、資料特性取得部２１ａは、資料管理サーバ３ａに対して、ユーザＩＤが“ｔａｋｅ”であるユーザのページ閲覧履歴を要求する（Ｏｐ２２）。そして、ページ閲覧履歴から、発信要求に関係する資料、すなわち特性取得対象となるページを特定する。例えば、アクセス履歴記録部３２のアクセスログにおいて、“ｔａｋｅ”が最後（最近）にアクセスしたページが特性取得対象となる。一例として、図５に示すアクセスログが記録されている場合、ユーザＩＤ“ｔａｋｅ”に対応するＵＲＬ“ｈｉｍｉｔｓｕ．ｈｔｍｌ”のページが特性取得対象となる。

このように、特性取得対象のページが存在する場合（Ｏｐ２３でｙｅｓ）、資料特性取得部２１ａは、そのページの特性データを、発信要求に関係する資料の特性データとして取得する（Ｏｐ３）。Ｏｐ３〜Ｏｐ８の処理は、図３に示したＯｐ３〜Ｏｐ８と同様である。

（第３の実施形態）
第３の実施形態は、第２の実施形態において図４に示したシステムの動作の変形例である。上記第２の実施形態では、ユーザＡがクリックツーコールによりユーザ端末５から発信要求を送信する場合を示した。これに対して、本実施形態では、ユーザＡが通話端末７ａから呼制御サーバ１に対して、電話の発信（発信要求）をする。図７は、本実施形態にかかる呼制御サーバ１と通話制御システム２ａの動作例を示すフローチャートである。以下では、一例として、ユーザ端末５に表示されたページ（資料）に、担当の電話番号が記述されており、ユーザＡが、それを見て、通話端末７ａにその担当の電話番号を入力して発信を行う場合について説明する。

図７において、呼制御サーバ１は、ユーザＡから発信要求（発信通知）を受けると（Ｏｐ０１でｙｅｓ）、発信要求に含まれる着信側の電話番号に、特番が付加されているか判断する（Ｏｐ０２）。

特番は、特定用途の識別番号であり、例えば、ユーザが発信する際に通話端末を操作することによって送信される。ユーザは、相手先の電話番号「１１１１」に電話をかける際に、特番として、例えば「１９９」を付加して、「１９９１１１１」の番号を通話端末に入力して発信する。本動作例では、「１９９」を電話番号に付加して発信された場合は発信可否の判断を行わないことが、予め電話網６における通話のルールとして決められるとする。なお、この特番により発信可否判定を実行するか否かを決定する処理は必須ではない。

呼制御サーバ１は、特番が付加されていない場合（Ｏｐ０２でｎｏ）、通話制御システム２ａに、発信側および着信側の電話番号を通知して、発信の可否判断を依頼する。特番が付加されている場合（Ｏｐ０２でｙｅｓ）、呼制御サーバ１にて発信処理（呼接続）が実行される（Ｏｐ７）。

Ｏｐ０２でｎｏの場合、通話制御システム２ａは、発信側の電話番号をユーザＩＤに変換する（Ｏｐ１１）。このとき、通話制御システム２ａは、番号記録部２６の対応番号データを参照する。例えば、発信側の電話番号が“３３３３”の場合、通話制御システム２ａは、図２Ｄに示す対応番号データを参照して、電話番号“３３３３”に対応するユーザＩＤ“ｔａｋｅ”を取得する。

このように、電話番号をユーザＩＤに変換できた場合（Ｏｐ１１でｙｅｓ）、資料特性取得部２１ａは、資料管理サーバ３ａのアクセス履歴記録部３２から、ユーザＩＤ“ｔａｋｅ”のユーザが最後にアクセスしたページのＵＲＬを取得する（Ｏｐ１２）。例えば、図５に示すアクセスログから、ユーザＩＤ“ｔａｋｅ”による最近のアクセスＵＲＬ“ｈｉｉｔｓｕ．ｈｔｍｌ”が取得される。

このとき、資料特性取得部２１ａは、ユーザＩＤの“ｔａｋｅ”のアクセス時刻と現在時刻を比較して、一定時間内にアクセスしたものではない場合は、ＵＲＬ取得の対象外としてもよい。このように、一定時間より前にユーザによってアクセスされた資料は、特性取得対象の資料（発信要求に関係する資料）から除外することで、より正確に発信要求に関係する資料を選ぶことができる。その結果、例えば、何日も前にページにアクセスしたために発信が抑止されてしまう、という事態の発生を防ぐことができる。

そして、資料特性取得部２１ａは、取得したＵＲＬで示されるページに、着信側の電話番号が含まれているか判断する（Ｏｐ１３）。ページに着信側の電話番号が含まれている場合（Ｏｐ１３でｙｅｓ）、資料特性取得部２１ａは、そのページの特性データを取得する（Ｏｐ３）。

このように、資料特性取得部２１ａは、発信ユーザがアクセスしたページ（資料）であって、着信側の連絡先情報（電話番号）を含むページ（資料）を、発信要求に関係する資料として特定することができる。これにより、資料に表示された電話番号を指定して発信した場合（クリックツーコールの場合）でなくても、発信要求に関連する資料を特定することが可能になる。

Ｏｐ３〜Ｏｐ８の処理は、図１に示したＯｐ３〜Ｏｐ８の処理と同様に実行することができる。以上、第３の実施形態によれば、クリックツーコールによる発信でない場合でも、関係する資料を特定し、資料の特性および着信側の状態を考慮した発信判定が可能になる。

（第４の実施形態）
図８は、本実施形態にかかる通話制御システムを含むシステム全体の構成を示す機能ブロック図である。図８において、図１と同様の機能ブロックには同じ番号を付している。本実施形態は、発信を抑止すると判定された場合に、留守番電話転送処理を行うことで、発信ユーザが伝言を残せるようにするものである。

[システムの構成]
電話網６およびネットワーク４には、留守電サーバ８および音声合成サーバ９が接続されている。そして、通話制御サーバ２ｂは、録音制御部２７をさらに備える。

留守電サーバ８は、発信ユーザから音声メッセージの入力を受け付けて、着信側の通話端末からアクセス可能な状態で記録する、いわゆる留守番電話サービスの機能を提供するサーバである。

音声合成サーバ９は、入力されたテキストから音声データを合成して出力するサーバである。

通話制御サーバ２ｂの発信処理部２４ｂは、発信判定部２３が発信を抑止すると判定した場合に、発信要求を留守電サーバ８に転送する。これにより、留守電サーバ８は、発信ユーザの入力した音声メッセージを、着信ユーザに利用可能な状態で記録する。

録音制御部２７は、発信判定部２３が発信を抑止すると判定した場合に、発信要求に関係する資料の情報を含むテキストを音声合成するよう音声合成サーバに依頼する。これにより、資料の情報を含む音声データが生成される。例えば、録音制御部２７は、資料特性取得部２１が取得した特性データを使って資料の特性を説明するテキストを生成し、音声合成サーバ９に送信する。

録音制御部２７が音声合成サーバ９に音声合成を依頼した場合、発信処理部２４ｂは、音声合成サーバ９と留守電サーバ８とを接続する。これにより、留守電サーバ８は、音声合成サーバ９で合成された資料の情報を含む音声データを、着信ユーザに利用可能な状態で記録することができる。

[動作例]
次に、本実施形態におけるシステムの動作例を説明する。通話制御システム２ｂが発信要求を受信して、発信判定部２３により判定処理が実行されるまで動作は、上記実施形態１〜３と同様である。

発信判定部２３が、発信を抑止すると判定した場合、発信処理部２４ｂは、送信されたＨＴＴＰリクエストに対して、例えば、「先方は、現在この件ではお話できない状況にあります。留守番電話に転送します。」というメッセージを含んだページを応答する。発信ユーザ（ユーザＡ）は、このページに含まれる「転送」ボタンをクリックすると、発信処理部２４ｂは、留守番電話への転送処理を行う。

なお、本動作例では、ユーザを驚かせないようにするために、転送処理の確認を行っているが、留守番電話に転送される可能性があることをユーザが十分に理解しているような環境では、確認処理を行わずに留守番電話に転送してもよい。

留守番電話への転送処理において、発信処理部２４ｂは、呼制御サーバ１に対して接続指示を行い、発信ユーザの通話端末７ａと留守電サーバ８の提供する留守番電話を接続させる。発信ユーザは、資料に対する質問等を伝言として残すことができる
発信ユーザによる留守番電話への伝言が完了し、発信ユーザの通話端末７ａと留守番電話との接続が切断すると、呼制御サーバ１から発信処理部２４ｂに対して切断通知がされる。発信処理部２４ｂが切断通知を受信すると、録音制御部２７は、資料特性取得部２１が取得した資料の特性データを使って、音声合成サーバ９に対して資料の特性を説明する文面を設定する。

例えば、録音制御部２７は、資料特性取得部２１で特定された資料のＵＲＬのページから、タイトル、ＵＲＬまたはその他のページの内容を示すキーワードを抽出する。なお、抽出処理は、資料特性取得部２１が行ってもよい。抽出されたキーワードを使って伝言のテキストデータが生成される。キーワードとして、「新型ＰＣ発表」、「営業通達」が抽出された場合、「この伝言は、『新型ＰＣ発表』の『営業通達』を見て電話してきたものです。」といったテキストデータが生成される。録音制御部２７は、生成したテキストデータを音声合成サーバ９に登録する。

音声合成サーバ９で伝言の音声データが登録されると、発信処理部２４ｂは、呼制御サーバ１に、留守電サーバ８と音声合成サーバ９を接続するように、転送指示を送信する。留守電サーバ８と音声合成サーバ９とが接続されると、音声合成サーバ９は登録されたテキストデータから音声メッセージを合成して留守電サーバ８へ送信する。音声メッセージの送信が終了すると接続を切断する。

以上の実施形態に関し、さらに以下の付記を開示する。

（付記１）
着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理を実行する通話制御システムであって、
前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得部と、
前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得部と、
前記資料特性取得部が取得した前記特性データと、前記着信側状態取得部が取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定部と、
前記発信判定部の判定に従って発信処理を実行する発信処理部とを備える通話制御システム。

（付記２）
前記資料特性取得部は、前記発信要求に関係する資料に関する情報として、前記資料のアドレスを受け取り、前記アドレスを用いて資料にアクセスし、資料に含まれるテキストデータに所定のキーワードが含まれるか否かにより、当該資料の特性データを取得する、付記１に記載の通話制御システム。

（付記３）
前記資料特性取得部は、前記発信要求に関係する資料に関する情報として、前記発信要求の発信ユーザを識別するデータを受け取り、前記発信ユーザがアクセス可能な資料群を提供するサーバにおけるアクセス履歴を記録するアクセス履歴記録部にアクセスし、前記発信ユーザのアクセス履歴に基づいて前記発信要求に関係する資料を特定し、当該特定した資料の特性データを取得する、付記１に記載の通話制御システム。

（付記４）
前記資料特性取得部は、前記資料の公開可能な範囲を示すデータを前記特性データとして取得し、
前記着信側状態取得部は、前記着信側の端末の場所を示すデータを前記状態データとして取得し、
前記発信判定部は、前記特性データが示す公開可能な範囲と、前記状態データが示す着信側の端末の場所に応じて、前記発信要求にかかる発信をするか否かを判定する、付記１〜３のいずれか１項に記載の通話制御システム。

（付記５）
前記資料特性取得部は、前記資料の提供元を示すデータを前記特性データとして取得し、
前記着信側状態取得部は、前記着信側の端末のユーザの所属を示すデータを前記状態データとして取得し、
前記発信判定部は、前記特性データが示す前記資料の提供元と、前記状態データが示す前記着信側の端末のユーザの所属に応じて、前記発信要求にかかる発信をするか否かを判定する、付記１〜３のいずれか１項に記載の通話制御システム。

（付記６）
前記発信判定部が前記発信要求にかかる発信をしないと判定した場合に、前記発信要求に関係する資料に関する情報を表す音声データを生成し、前記発信要求の前記着信側の端末からアクセス可能な状態で記録する処理を開始する録音制御部をさらに備える、付記１〜５のいずれか１項に記載の通話制御システム。

（付記７）
前記発信要求に特定の番号が付加されているか否かを判定し、前記特定の番号が付加されている場合は、前記発信判定部に前記判定をさせずに、前記発信処理部に前記発信処理を実行させる特番判定部をさらに備える、付記１〜６のいずれか１項に記載の通話制御システム。

（付記８）
着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理をコンピュータに実行させる通話制御プログラムであって、
前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得処理と、
前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得処理と、
前記資料特性取得処理で取得した前記特性データと、前記着信側状態取得処理で取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定処理と、
前記発信判定処理の判定に従った発信処理とを、コンピュータに実行させる通話制御プログラム。

（付記９）
コンピュータが、着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理を実行する通話制御方法であって、
コンピュータの資料特性取得部が、前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得工程と、
前記コンピュータの着信側状態取得部が、前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得工程と、
前記コンピュータの発信判定部が、前記資料特性取得処理で取得した前記特性データと、前記着信側状態取得処理で取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定工程と、
前記コンピュータの発信処理部が、前記発信判定工程の判定に従った発信処理を実行する発信工程とを含む通話制御方法。

第１の実施形態にかかる通話制御システムを含むシステム全体の構成を示す機能ブロック図 資料データ記録部に記録される資料の特性を示すデータの一例を示す図 状態データ記録部に記録される状態データの一例を示す図 判定表記録部に記録される判定表の一例を示す図 対応番号データの一例を示す図 通話制御システムの動作の一例を示すフローチャート 第２の実施形態にかかる通話制御システムを含むシステム全体の構成を示す機能ブロック図 アクセスログの一例を示す図 第２の実施形態の通話制御システム２ａの動作例を示すフローチャート 第３の実施形態にかかる呼制御サーバと通話制御システムの動作例を示すフローチャート 第４の実施形態にかかる通話制御システムを含むシステム全体の構成を示す機能ブロック図

符号の説明

１ 呼制御サーバ
２ 通話制御システム
２ａ 通話制御システム
２ｂ 通話制御システム
３ 資料管理サーバ
３ａ 資料管理サーバ
４ ネットワーク
５ ユーザ端末
６ 電話網
７ａ 通話端末
７ｂ 通話端末
８ 留守電サーバ
９ 音声合成サーバ
１１ 状態データ記録部
２１ 資料特性取得部
２２ 着信側状態取得部
２３ 発信判定部
２４ 発信処理部
２４ｂ 発信処理部
２５ 判定表記録部
２６ 番号記録部
２７ 録音制御部
３１ 資料データ記録部
３２ アクセス履歴記録部

Claims (7)

1. 着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理を実行する通話制御システムであって、
   前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得部と、
   前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得部と、
   前記資料特性取得部が取得した前記特性データと、前記着信側状態取得部が取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定部と、
   前記発信判定部の判定に従って発信処理を実行する発信処理部とを備える通話制御システム。
2. 前記資料特性取得部は、前記発信要求に関係する資料に関する情報として、前記資料のアドレスを受け取り、前記アドレスを用いて資料にアクセスし、資料に含まれるテキストデータに所定のキーワードが含まれるか否かにより、当該資料の特性データを取得する、請求項１に記載の通話制御システム。
3. 前記資料特性取得部は、前記発信要求に関係する資料に関する情報として、前記発信要求の発信ユーザを識別するデータを受け取り、前記発信ユーザがアクセス可能な資料群を提供するサーバにおけるアクセス履歴を記録するアクセス履歴記録部にアクセスし、前記発信ユーザのアクセス履歴に基づいて前記発信要求に関係する資料を特定し、当該特定した資料の特性データを取得する、請求項１に記載の通話制御システム。
4. 前記資料特性取得部は、前記資料の公開可能な範囲を示すデータを前記特性データとして取得し、
   前記着信側状態取得部は、前記着信側の端末の場所を示すデータを前記状態データとして取得し、
   前記発信判定部は、前記特性データが示す公開可能な範囲と、前記状態データが示す着信側の端末の場所に応じて、前記発信要求にかかる発信をするか否かを判定する、請求項１〜３のいずれか１項に記載の通話制御システム。
5. 前記資料特性取得部は、前記資料の提供元を示すデータを前記特性データとして取得し、
   前記着信側状態取得部は、前記着信側の端末のユーザの所属を示すデータを前記状態データとして取得し、
   前記発信判定部は、前記特性データが示す前記資料の提供元と、前記状態データが示す前記着信側の端末のユーザの所属に応じて、前記発信要求にかかる発信をするか否かを判定する、請求項１〜３のいずれか１項に記載の通話制御システム。
6. 着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理をコンピュータに実行させる通話制御プログラムであって、
   前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得処理と、
   前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得処理と、
   前記資料特性取得処理で取得した前記特性データと、前記着信側状態取得処理で取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定処理と、
   前記発信判定処理の判定に従った発信処理とを、コンピュータに実行させる通話制御プログラム。
7. コンピュータが、着信側の端末を特定する情報を少なくとも含む電話の発信要求を受信し、発信要求の可否を判定した上で発信処理を実行する通話制御方法であって、
   コンピュータの資料特性取得部が、前記発信要求を受信した際に、当該発信要求に関係する資料に関する情報も受け付け、当該資料に関する情報を基に、前記資料または資料の特性を示すデータを記録した資料データ記録部にアクセスして、当該資料の特性を示す特性データを取得する資料特性取得工程と、
   前記コンピュータの着信側状態取得部が、前記発信要求に含まれる前記着信側の端末を特定する情報を基に、着信側となり得る端末の状態を記録した状態データ記録部にアクセスして、前記発信要求の前記着信側の端末の状態を示す状態データを取得する着信側状態取得工程と、
   前記コンピュータの発信判定部が、前記資料特性取得処理で取得した前記特性データと、前記着信側状態取得処理で取得した前記状態データとを用いて、前記発信要求にかかる発信をするか否かを判定する発信判定工程と、
   前記コンピュータの発信処理部が、前記発信判定工程の判定に従った発信処理を実行する発信工程とを含む通話制御方法。

Images