(57)【要約】【課題】不完了呼が発生した場合に、発信者及び着信者双方の情報に基づいて、適切な不通理由を発信者に通知すること。【解決手段】不通理由通知装置は、不完了呼が発生した場合に発信者に不通理由を通知する。不通理由通知装置は、ユーザ装置間のセッション情報を管理するセッション管理手段と、属性情報を管理する属性情報管理手段と、発信者、着信者又は着信者周囲の者の属性情報に基づいて、不通理由を通知する不通理由通知手段とを有する。【選択図】図１
2008252286.tif 000002
【特許請求の範囲】
【請求項１】
不完了呼が発生した場合に発信者に不通理由を通知する不通理由通知装置であって、
セッション情報を管理し、不完了呼の発生を検出するセッション管理手段と、
属性情報を管理する属性情報管理手段と、
不完了呼の発生に応じて、前記属性情報管理手段から属性情報を抽出し、前記発信者に不通理由を通知する不通理由通知手段と、
を有し、前記不通理由通知手段は、前記発信者、着信者及び該着信者周囲の者の一人以上の属性情報を、事前に設定されたルールに当てはめることで、前記発信者に通知する不通理由を決定する
ことを特徴とする不通理由通知装置。
【請求項２】
前記不通理由通知手段は、
ユーザによりルールを登録するための登録手段と、
前記ルールを蓄積する蓄積手段と、
前記セッション情報、不完了呼の発信者及び着信者の識別子を受信するセッション情報受信手段と、
前記識別子で特定された前記発信者及び前記着信者の属性情報を前記属性情報管理手段から取得する情報取得手段と、
情報取得手段で取得された属性情報を前記ルールに当てはめることで、前記発信者に通知する不通理由を決定する不通理由決定手段と、
不通理由を前記発信者に通知する通知手段と、
を有する請求項１記載の不通理由通知装置。
【請求項３】
前記不通理由通知手段は、不完了呼の発信者が所定の者に該当するか否かを判定する不通通知ユーザ決定手段を更に有し、判定結果に応じて、前記ルールに従って前記発信者に不通理由が通知されるか否かが決定される請求項１又は２に記載の不通理由通知装置。
【請求項４】
前記セッション管理手段では、着信者が呼出に応答する前に発呼者が切断の意思表示をしたことで、不完了呼の発生が検出され、前記発信者及び前記着信者の識別子が前記不通理由通知手段に通知される請求項１乃至３のいずれか１項に記載の不通理由通知装置。
【請求項５】
前記属性情報は、ユーザの識別子毎に関連付けられる一群の情報項目で表現される請求項１乃至４のいずれか１項に記載の不通理由通知装置。
【請求項６】
複数の情報項目各々には、比較項目種別毎に優先度が割り当てられている請求項５記載の不通理由通知装置。
【請求項７】
前記ルールは、複数の情報項目の優先度の大小関係と不通理由との対応関係を決めている請求項６記載の不通理由通知装置。
【請求項８】
複数のユーザ装置と、基地局装置と、不通理由通知装置とを有する不通理由通知システムであって、前記不通理由通知装置は、
セッション情報を管理し、不完了呼の発生を検出するセッション管理手段と、
属性情報を管理する属性情報管理手段と、
不完了呼の発生に応じて、前記属性情報管理手段から属性情報を抽出し、前記発信者に不通理由を通知する不通理由通知手段と、
を有し、前記不通理由通知手段は、
ユーザによりルールを登録するための登録手段と、
前記ルールを蓄積する蓄積手段と、
前記セッション情報、不完了呼の発信者及び着信者の識別子を受信するセッション情報受信手段と、
前記識別子で特定された前記発信者及び前記着信者の属性情報を前記属性情報管理手段から取得する情報取得手段と、
情報取得手段で取得された属性情報を前記ルールに当てはめることで、前記発信者に通知する不通理由を決定する不通理由決定手段と、
不通理由を前記発信者に通知する通知手段と、
を有する不通理由通知システム。
【請求項９】
不完了呼が発生した場合に発信者に不通理由を通知する不通理由通知方法であって、
セッション情報を管理し、不完了呼の発生を検出するセッション管理ステップと、
不完了呼の発生に応じて、属性情報を管理する属性情報管理手段から属性情報を抽出するステップと、
前記発信者に不通理由を通知する不通理由通知ステップと、
を有し、前記不通理由通知ステップは、前記発信者、着信者及び該着信者の者の一人以上の属性情報を、事前に設定されたルールに当てはめることで、前記発信者に通知する不通理由を決定する
ことを特徴とする不通理由通知方法。
【請求項１０】
前記不通理由通知ステップは、
ユーザによりルールを蓄積手段に登録するステップと、
前記セッション情報、不完了呼の発信者及び着信者の識別子を受信するステップと、
前記識別子で特定された前記発信者及び前記着信者の属性情報を前記属性情報管理手段から取得するステップと、
取得された属性情報を前記ルールに当てはめることで、前記発信者に通知する不通理由を決定するステップと、
不通理由を前記発信者に通知するステップと、
を有する請求項９記載の不通理由通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼接続が適切に設定されなかった場合に、発信者に不通理由を通知するためのシステム、装置及び方法に関連する。
【背景技術】
【０００２】
発信者からの着信信号に対する応答方法を、着信者の位置に応じて自動的に変更する技術がある。例えば、特許文献１では、インターネットを介して音声データの送受信を行うIP電話システムにおいて、ネットワークアドレスに対応した位置と応答方法との対応関係をユーザがデータベースに登録し、ユーザの現在位置をIPアドレスから判断し、その位置に対応する方法で応答を行うことが開示されている。
【特許文献１】特開２００４−３４９８０２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上記の従来方法は着信者の位置にしか依存しておらず、発信者の状況を加味した応答はなされない点で不便である。着信者が予め登録したルールに従って応答方法が自動的に選択されてしまうからである。この点に関し、特許文献１では、信号の緊急度に応じて着信信号に対する応答方法が変更できるようにしている。しかしながらそのような方法では、緊急度を発信者がその都度設定しなければならず、発信者の手間が増えてしまう。
【０００４】
一方、かかって来た電話が真に接続されるべきか否かは着信者が判断すべきである。着信者の意思によらず、発信者が設定した緊急度等で応答方法が自動的に決定されてしまうと、真に接続されるべき重要な電話を見逃してしまったり、あるいは着信者の意に反して接続されてしまうおそれも生じる。
【０００５】
本発明の課題は、不完了呼が発生した場合に、発信者及び着信者双方の情報に基づいて、適切な不通理由を発信者に通知することである。
【課題を解決するための手段】
【０００６】
本発明によれば、不完了呼が発生した場合に発信者に不通理由を通知する不通理由通知装置が使用される。不通理由通知装置は、ユーザ装置間のセッション情報を管理するセッション管理手段と、属性情報を管理する属性情報管理手段と、発信者、着信者又は着信者周囲の者の属性情報に基づいて、不通理由を通知する不通理由通知手段とを有する。
【発明の効果】
【０００７】
本発明によれば、不完了呼が発生した場合に、発信者及び着信者の情報に基づいて、適切な不通理由を発信者に通知することができる。
【発明を実施するための最良の形態】
【０００８】
本発明の第１形態では、不完了呼が発生した場合に発信者に不通理由を通知する不通理由通知装置が使用される。不通理由通知装置は、セッション情報を管理し、不完了呼の発生を検出するセッション管理手段と、属性情報を管理する属性情報管理手段と、不完了呼の発生に応じて、前記属性情報管理手段から属性情報を抽出し、前記発信者に不通理由を通知する不通理由通知手段とを有する。前記不通理由通知手段は、前記発信者、着信者及び該着信者周囲の者の一人以上の属性情報を、事前に設定されたルールに当てはめることで、前記発信者に通知する不通理由を決定する。
【０００９】
これにより、不完了呼が発生した場合に、発信者及び着信者の情報に基づいて、適切な不通理由を発信者に通知することができる。発信者は電話のつながらなかった理由を知ることができるので、例えば電話以外の方法で連絡を取ることを決定してもよい。例えば、着信者が呼出に気付いていなかっただけならば、発信者は再度電話をするよう決定してもよい。
【００１０】
本発明の第２形態では、前記不通理由通知手段は、ユーザによりルールを登録するための登録手段と、前記ルールを蓄積する蓄積手段と、前記セッション情報、不完了呼の発信者及び着信者の識別子を受信するセッション情報受信手段と、前記識別子で特定された前記発信者及び前記着信者の属性情報を前記属性情報管理手段から取得する情報取得手段と、情報取得手段で取得された属性情報を前記ルールに当てはめることで、前記発信者に通知する不通理由を決定する不通理由決定手段と、不通理由を前記発信者に通知する通知手段とを有する。
【００１１】
これにより、発信者、着信者及び着信者周囲の者の属性情報から、不通理由を状況に応じて自動的に適切に変更することができる。
【００１２】
本発明の第３形態では、前記不通理由通知手段は、不完了呼の発信者が所定の者に該当するか否かを判定する不通通知ユーザ決定手段を更に有し、判定結果に応じて、前記ルールに従って前記発信者に不通理由が通知されるか否かが決定される。これにより、例えば所定の者に限定して、電話のつながらなかった理由を詳細に通知することができ、着信者のプライバシを守ることができる。
【００１３】
本発明の第４形態によれば、セッション管理手段にて、着信者が呼出に応答する前に発呼者が切断の意思表示をしたことで、不完了呼の発生が検出され、前記発信者及び前記着信者の識別子が前記不通理由通知手段に通知される。
【００１４】
前記属性情報は、ユーザの識別子毎に関連付けられる一群の情報項目で表現されてもよい。複数の情報項目各々には、比較項目種別毎に優先度が割り当てられてもよい。前記ルールは、複数の情報項目の優先度の大小関係と不通理由との対応関係を決めてもよい。
【００１５】
本発明の第５形態では、不完了呼が発生した場合に発信者に不通理由を通知する不通理由通知方法が使用される。本方法は、セッション情報を管理し、不完了呼の発生を検出するセッション管理ステップと、不完了呼の発生に応じて、属性情報を管理する属性情報管理手段から属性情報を抽出するステップと、前記発信者に不通理由を通知する不通理由通知ステップとを有する。前記不通理由通知ステップは、前記発信者、着信者及び該着信者周囲の者の一人以上の属性情報を、事前に設定されたルールに当てはめることで、前記発信者に通知する不通理由を決定する。
【００１６】
本発明の第６形態では、前記不通理由通知ステップは、ユーザによりルールを蓄積手段に登録するステップと、前記セッション情報、不完了呼の発信者及び着信者の識別子を受信するステップと、前記識別子で特定された前記発信者及び前記着信者の属性情報を前記属性情報管理手段から取得するステップと、取得された属性情報を前記ルールに当てはめることで、前記発信者に通知する不通理由を決定するステップと、不通理由を前記発信者に通知するステップとを有する。
【００１７】
以下、図面を参照しながら本発明の実施例が説明される。図中、同一又は類似する要素には同じ参照番号又は参照記号が付されている。
【００１８】
説明の便宜上、本発明が幾つかの実施例に分けて説明されるが、各実施例の区分けは本発明に本質的ではなく、２以上の実施例が必要に応じて使用されてよい。
【実施例１】
【００１９】
図１は本発明の一実施例による不通理由通知システムを示す。図１には、移動端末１０１，１０２，１０３、基地局２０１，２０２、不通理由通知装置１が示されている。
【００２０】
移動端末１０１−１０３は基地局を介して無線通信を行う装置であり、より一般的には移動端末又は固定端末であるユーザ装置でよい。
【００２１】
基地局２０１，２０２は、移動端末との一般的な無線通信を行い、特に本実施例では不通理由通知装置とデータの送受信を行う中継局としても機能する。
【００２２】
不通理由通知装置１は、不完了呼が発生した場合に、発信者の属性情報、着信者の属性情報、着信者周囲のヒトの属性情報等に基づいて、発信者に不通理由を通知するための処理を行う。不通理由通知装置１はセッション管理部１０、不通理由通知部２０、属性情報管理部３０を備える。不通理由通知装置１は図示のように基地局とは別の通信ノードに用意されてもよいし、いずれかの基地局に設けられてもよいし、基地局より上位の通信ノードに設けられてもよい。図１では不通理由通知装置１は２つの基地局と通信するように描かれているが、２つより多くの基地局と通信がおこなわれてもよい。
【００２３】
セッション管理部１０は、基地局から通知されるセッション制御情報に基づいて、セッションの接続、切断、維持等の処理を行う。発信者側の端末（発信端末）から着信者側の端末（着信端末）へセッションの接続要求がなされると、セッション管理部１０は着信端末を呼び出す。この呼び出しに着信端末が応答すると、発信端末及び着信端末間でセッションが確立される。しかしながら、着信端末が応答する前に、発信端末からセッション切断要求（セッションの切断を求める要求）がなされると、セッションの設定処理は中断され、不通理由通知部２０に対して、不完了呼が発生したこと、発信端末の識別子、着信端末の識別子等が通知される。例えば、かなり長い間呼び出し音を鳴らしたにもかかわらず、相手が応答しなかった場合に、発呼側のユーザが切断の意思表示をすることが考えられる。ここで、識別子は、移動端末を一意に特定できるIDを示し、例えば移動端末毎に割り当てられている電話番号、製造番号、IPアドレス等が識別子に使用されてもよい。
【００２４】
不通理由通知部２０は、セッション管理部１０から所定の情報を受信すると、発信者の属性情報、着信者の属性情報、着信端末周囲のヒトの属性情報等を属性情報管理部３０から抽出し、後述の処理を経て発信端末に不通理由を通知する。所定の情報は、不完了呼が発生したこと、発信端末の識別子、着信端末の識別子等を含んでよい。
【００２５】
図２は不通理由通知部２０の詳細図を示す。図２には、不通理由登録部２１、不通理由蓄積部２２、セッション情報受信部２３、属性情報要求部２４、属性情報受信部２５、不通理由決定部２６、不通理由送信部２７が示されている。
【００２６】
不通理由登録部２１は、ルールに関する情報（ルール情報）をユーザから受信し、ルール情報を不通理由蓄積部２２に転送する。ここで、「ルール」は、不完了呼が発生した場合に、どのような方法で不通理由が通知されるかを少なくとも示す。ルールはユーザ毎に登録されてもよいし、複数のユーザに同じルールが登録されてもよい。
【００２７】
図３に示されるように、何らかの登録者４０が入力機器５０を用いてルールを登録してもよいし、ユーザが直接的に登録を行ってもよい。
【００２８】
図２の不通理由蓄積部２２は、不通理由登録部２１により登録される様々なルールを蓄積する。
【００２９】
図４は比較項目種別毎に登録者(ユーザ)により設定された属性情報の優先度を示す。例えば、登録者Ａさんは、「位置」に関し、「特別会議室」を最優先に、次いで「会議室」、「実験室」、「居室」の順に優先度を設定している。登録者Ｂさんは、「電話」に関し、「外線」を「内線」よりも優先するよう設定している。図示の設定は単なる一例に過ぎず、様々な登録者が様々な比較項目種別毎に様々な属性情報の優先度を設定してよい。
【００３０】
図５は、図４のように登録された優先度に基づいて、どのような不通理由がなされるかを例示する。例えば、登録者Ａさんについては、着信者の位置（例えば、特別会議室）の優先度が、発信者の位置（例えば、居室）の優先度以上であったことに起因して、
「重要な場所にいるため電話に出られませんでした」
とのメッセージが発信者に通知される。また、登録者Ａさんについては、着信者周囲のヒトの役職（例えば、部長）の優先度が、発信者の役職の優先度（例えば、社員）の優先度以上であったことに起因して、
「大切なヒトと一緒にいるため電話に出られませんでした」
とのメッセージが発信者に通知される。登録者Ｂさんについては、着信者の電話（例えば、外線）の優先度が、発信者の電話（例えば、内線）の優先度以上であったことに起因して、
「重要な電話中のため出られませんでした」
というメッセージが発信者に通知される。このように「位置」、「役職」、「氏名」、「電話」等の様々な比較項目種別毎に属性情報の優先度を事前に設定しておくことで、発信者、着信者及び着信者周囲の状況に応じて、適切な不通理由が発信者に通知される。
【００３１】
図２のセッション情報受信部２３は、セッション管理部１０で不完了呼の発生が確認されたことに応じて、不完了呼が発生したことを示す情報、発信端末及び着信端末の識別子を受信する。これらの情報を受信すると、セッション情報受信部２３は、発信端末及び着信端末の識別子を属性情報要求部２４に通知する。
【００３２】
属性情報要求部２４は、受信した発信端末及び着信端末の識別子に基づいて、属性情報管理部３０（図１）に必要な属性情報を要求する。必要な情報は、発信者の属性情報、着信者の属性情報及び着信者周囲のヒトの属性情報等を含んでよい。
【００３３】
属性情報受信部２５は、属性情報管理部３０から上記の必要な情報を受信し、それらを不通理由決定部２６に転送する。
【００３４】
不通理由決定部２６は、属性情報受信部２５から通知された属性情報に関し、優先度比較を行いながら、不通理由蓄積部２２に蓄積済みのルールを参照することで、発信者に通知すべき不通理由を決定する。決定内容は不通理由送信部２７に通知される。
【００３５】
不通理由送信部２７は、発信者の身元又は識別子を用いて、決定された不通理由（メッセージ）を発信者に通知する。発信者の身元等は、例えば電子メールアドレスで表現されてもよい。この場合、不通理由通知部２７は属性情報管理部３０から通知されたメールアドレス宛に不通理由の記載されたメールを送信してもよい。
【００３６】
図１の属性情報管理部３０は、移動端末所有者の様々な属性情報を管理する（記憶、削除、更新等を含む）。
【００３７】
図６は、属性情報管理部３０のデータベースで管理される情報の一例を示す。属性情報の具体例としては、ユーザの氏名又は名称、役職、携帯電話番号、メールアドレス、位置、電話の現状等が識別子毎に互いに関連付けられている。
【００３８】
位置に関する情報(位置情報)は、例えば移動端末が無線ローカルエリアネットワーク(LAN)に含まれる場合には、接続中のアクセスポイント(AP)の情報から導出できる。移動端末に無線タグが付けられている場合には、無線タグの情報を検出した無線タグ情報リーダーの位置から、移動端末の位置情報が導出されてもよい。移動端末がグローバルポジショニングシステム(GPS)用受信機を備えている場合には、GPS用の位置情報が利用されてもよい。移動端末の位置情報を取得するための適切な如何なる技術が使用されてもよい。
【００３９】
電話の現状は、例えばセッション管理部１０が移動端末のセッション全てを管理している場合には、セッション情報管理部１０から通知されてもよい。
【００４０】
属性情報管理部３０は、不通理由通知部２０から特定の移動端末の属性情報の要求を受けた場合に、その移動端末の位置情報を取得し、必要に応じて他の属性情報と共に不通理由通知部２０にそれらを通知してもよい。或いは、属性情報管理部３０は、全ての移動端末の位置情報を定期的に取得及び蓄積し、不通理由通知部２０から特定の移動端末の属性情報の要求を受けた場合に、蓄積済みの位置情報を不通理由通知部２０に通知してもよい。
【００４１】
図７は本発明の一実施例による不通理由通知方法を示すフローチャートである。説明の便宜上、移動端末１０１が移動端末１０２を呼び出そうとし、移動端末１０２の周囲に移動端末１０３があったとする。移動端末１０２の所有者は、不通理由通知部２０に図４及び図５に示されるようなルールを予め登録する（ステップS1）。
【００４２】
次に、移動端末１０１がセッション管理部１０に対して、移動端末１０２への接続を要求する（ステップS2）。
【００４３】
セッション管理部１０は、移動端末１０１から移動端末１０２への接続要求を受信したことに応じて、移動端末１０２を呼び出そうとする（ステップS3）。移動端末１０２が呼出に応答した場合には、移動端末１０１，１０２間のセッションが確立され、通信が行われる。
【００４４】
しかしながら、移動端末１０２が呼出に応答する前に、移動端末１０１からセッションを切断する要求がセッション管理部１０に届いたとする（ステップS4）。例えば、かなり長い間呼び出し音を鳴らしたにもかかわらず、移動端末１０２が応答しなかった場合に、移動端末１０１のユーザが切断の意思表示をすることが考えられる。この場合、セッション管理部１０は、移動端末１０２の呼出を中止する（ステップS5）。
【００４５】
セッション管理部１０は、不完了呼が発生したことを示す情報、移動端末１０１の識別子及び移動端末１０２の識別子を不通理由通知部２０に通知する（ステップS6）。
【００４６】
不通理由通知部２０は、移動端末１０１の識別子に関連する属性情報、移動端末１０２の識別子に関連する属性情報、移動端末１０２周囲の移動端末の識別子に関連する属性情報を、属性情報管理部３０に対して要求する（ステップS7）。
【００４７】
属性情報管理部３０は、移動端末１０１，１０２に現在の位置を通知するよう要求し、各移動端末はそれに応じて現在の位置情報を属性情報管理部３０に通知する（ステップS8,S9）。属性情報管理部３０は、移動端末１０２周囲の移動端末も探索する。例えば移動端末１０３が発見され、その識別子が特定される（ステップS10）。
【００４８】
属性情報管理部３０は、移動端末１０１，１０２，１０３の識別子各々に対する属性情報を不通理由通知部２０に通知する（ステップS11）。
【００４９】
不通理由通知部２０は、移動端末１０２の所有者（ユーザ）の名前から、そのユーザが登録したルールを特定及び参照し、そのルールに移動端末１０１，１０２，１０３の属性情報を当てはめる（ステップS12）。そして、ルールから導出された不通理由（メッセージ）が移動端末１０１に通知される（ステップS13）。
【００５０】
このように本実施例によれば、発信者の属性情報、着信者の属性情報及び着信者周囲のヒトの属性情報を比較判断することで、発信者に的確な不通理由を簡易に通知することができる。上記の説明では、予め決定したルールのいずれかに合致したメッセージが通知されているが、どのルールにも該当しない場合も考えられる。このような場合には、再度の電話を促す何らかのメッセージが発信者に通知されてもよい。例えば、「電話に気がつかなかったため出られませんでした」というメッセージが通知されてもよい。
【００５１】
本実施例によれば、着信者に対して、従来同様の呼出が行われる。電話がつながらなかった場合にのみ、不通理由が本実施例にしたがって発信者に通知される。したがって、電話の重要度に応じて、その電話を不通にするか否かを着信者側の裁量で決定するという原則を崩さずに済む。
【実施例２】
【００５２】
第１実施例では、不完了呼が発生した場合は、発信者に必ず不通理由が通知されていた。本発明の第２実施例では、不通理由の通知を受ける発信者が限定され、着信者のプライバシが保護される。
【００５３】
図８は第２実施例による不通理由通知部２０'の詳細を示す。不通理由通知部２０'は概して図２の不通理由通知部２０と同様であるが、不通通知ユーザ決定部２８及び比較部２６が用意されていること及び不通理由蓄積部２２'の蓄積情報が主に異なる。「２６」は第１実施例と同様に「不通理由決定部」と呼んでもよいが、第２実施例で特徴的な機能に着目して、「比較部」と言及されている。
【００５４】
図９は、不通理由蓄積部２２'に蓄積される情報の一例を示す。図示されているように、本実施例では、不通理由の通知を受ける者が「通知先」として個々に設定されている。例えば、登録者Ａさんは、鈴木さん及び田中さんには本発明による不通理由通知を行うが、他者には不通理由通知を行わない。或いは、他者に不通理由通知を行ったとしても、鈴木さんや田中さんとは異なる不通理由通知が行われる。
【００５５】
不通通知ユーザ決定部２８は、属性情報受信部２５から受信した発信者、着信者及び着信者周囲の者の属性情報を取得し、不通理由蓄積部２２'に蓄積済みのルールを当てはめる。発信者が所定の「通知先」であった場合には、発信者、着信者及び着信者周囲の者の属性情報が比較部２６に通知され、ルールに合わせて不通理由が「通知先」の発信者に通知される。これに対して発信者が所定の「通知先」に該当しなかった場合には、不通理由を通知するための処理は中止される。例えば、鈴木さんからＡさんに発呼があり、Ａさんがその電話に出ることができなかった場合、鈴木さんは「通知先」に登録されているので、鈴木さんには本発明による不通理由通知が行われる。上記の例では、「通知先」が決められていたが、逆に、「非通知先」が明示的に決められていてもよい。この場合、発信者が所定の「非通知先」のいずれかに該当した場合には、本発明による不通理由通知は行われず、該当しなかった場合にのみ本発明による不通理由通知が行われる。
【００５６】
図１０は第２実施例による不通理由通知方法を示すフローチャートである。概して図７と同様であるが、ステップS11'において、発信者が所定の者であるか否かを確認する点が主に異なる。ステップS11'では、不通理由通知部２０'が、属性情報管理部３０から移動端末１０１，１０２，１０３の属性情報を受信し、移動端末１０２が登録している「通知先」に、移動端末１０１が該当するか否かが判定される。該当しなければ本発明による不通理由通知は行われず、フローは終了する。該当していれば、フローはステップS12に進み、説明済みの手順が実行される。
【００５７】
本実施例によれば、第１実施例と同様に不通理由を適切に通知できることに加えて、不通理由の通知を受ける者（通知先）を予め指定できるので、着信者の位置や着信者周囲に存在するヒト等を知り得る者を制限し、着信者のプライバシを保護することができる。
【図面の簡単な説明】
【００５８】
【図１】本発明の一実施例による不通理由通知システムを示す図である。
【図２】第１実施例による不通理由通知部の詳細を示す図である。
【図３】ルールが登録される様子を示す図である。
【図４】比較項目種別毎に登録者により設定された属性情報の優先度を示す図である。
【図５】登録された優先度に基づいて第１実施例で不通理由をどのように通知するかを示す図である。
【図６】識別子毎に様々な属性情報が管理されている様子を示す図である。
【図７】第１実施例による不通理由通知方法を示すフローチャートである。
【図８】第２実施例による不通理由通知部の詳細を示す図である。
【図９】登録された優先度に基づいて第２実施例で不通理由をどのように通知するかを示す図である。
【図１０】第２実施例による不通理由通知方法を示すフローチャートである。
【符号の説明】
【００５９】
１  不通理由通知装置
１０１，１０２，１０３  移動端末
２０１，２０２  基地局
１０  セッション管理部
２０  不通理由通知部
２１  不通理由登録部
２２  不通理由蓄積部
２３  セッション情報受信部
２４  属性情報要求部
２５  属性情報受信部
２６  不通理由決定部
２７  不通理由送信部
２８  不通通知ユーザ決定部
３０  属性情報管理部
４０  登録者
５０  入力機器
【図１】
2008252286.tif 000003
【図２】
2008252286.tif 000004
【図３】
2008252286.tif 000005
【図４】
2008252286.tif 000006
【図５】
2008252286.tif 000007
【図６】
2008252286.tif 000008
【図７】
2008252286.tif 000009
【図８】
2008252286.tif 000010
【図９】
2008252286.tif 000011
【図１０】
2008252286.tif 000012