(57)【要約】【課題】端末内に電話帳データを保持しない相手への発信時にも、発信者の情報を提供できること【解決手段】着信端末１０１は、端末内に電話帳データを持たない発信者からの電話を着信した場合に、前記発信者の識別情報を用いてサーバに問い合わせを行い、問い合わせ結果である前記発信者の電話帳データをユーザに提示する。サーバ１０４は、任意の電話発信者から電話帳データを受け付けて記憶する。また、サーバ１０４は、着信端末１０１からの識別情報を受信し、識別情報に対応する電話発信者の電話帳データを着信端末１０１に送信する。【選択図】図１
2010268178.tif 000002
【特許請求の範囲】
【請求項１】
端末内に電話帳データを持たない発信者からの電話を着信した場合に、前記発信者の識別情報を用いてサーバに問い合わせを行い、問い合わせ結果である前記発信者の電話帳データをユーザに提示する通信端末と、
任意の電話発信者から電話帳データを受け付けて記憶し、前記通信端末からの前記識別情報を受信し、前記識別情報に対応する電話発信者の電話帳データを、前記通信端末に送信するサーバと、
を備えた電話帳管理システム。
【請求項２】
前記サーバは、前記通信端末からの問い合わせ履歴情報を保持し、
前記履歴情報に基づいて、電話発信者に自己の発信端末の電話帳データの登録を要求する請求項１の電話帳管理システム。
【請求項３】
前記履歴情報に基づいて、前記サーバは所定時間経過後に保持する電話帳データを自動的に編集する請求項１又は請求項２記載の電話帳管理システム。 
【請求項４】
前記サーバは、特定のユーザからのみ電話帳データの入力を受け付ける請求項１から請求項３いずれかに記載の電話帳管理システム。
【請求項５】
サーバが任意の電話発信者から電話帳データを受け付けて記憶するステップと、
通信端末において、端末内に電話帳データを持たない発信者からの電話を着信した場合に、前記発信者の識別情報を用いて前記サーバに問い合わせを行うステップと、
前記サーバが前記通信端末からの前記識別情報を受信し、前記識別情報に対応する電話発信者の電話帳データを、前記通信端末に送信するステップと、
前記通信端末が、問い合わせ結果である前記発信者の電話帳データをユーザに提示するステップと、
を備える電話帳管理方法。
【請求項６】
前記サーバにおいて、前記通信端末からの問い合わせ履歴を保持する履歴保持ステップと、
前記履歴情報に基づいて、電話発信者に自己の発信端末の電話帳データの登録を要求するステップとを請求項５の電話帳管理方法。
【請求項７】
前記履歴保持ステップでは、所定時間経過後に保持する電話帳データを自動的に編集する請求項５又は請求項６記載の電話帳管理方法。 
【請求項８】
前記サーバは、特定のユーザからのみ入力を受け付ける請求項５から請求項７いずれかに記載の電話帳管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電話帳管理システム及び電話帳管理方法に関し、特に共有可能な電話帳データの管理に適した電話帳管理システム及び電話帳管理方法に関する。
【背景技術】
【０００２】
携帯電話やスマートフォン（Smartphone）、ＰＨＳ（Personal Handy-phone System）などの携帯端末は、一般的に自己のメモリ内に電話帳機能を備えている。携帯電話の電話帳機能は、固定電話番号、携帯電話番号、メールアドレス、相手の住所、携帯端末保有者が定めたグループの所属情報、通話対象者の顔画像等の情報を保有する。これらの情報は一般的に端末のユーザが、携帯端末にこれらの情報を予め登録する。携帯端末は、携帯端末に着信があった場合、着信のあった電話番号を基に携帯端末内に予め登録された電話帳を自動的に検索することにより、発信者の情報を着信者に提示する。
【０００３】
電話の発信者は、着信端末の電話帳に記録されていない場合には、着信者に不審に思われ、応答してもらえない場面がある。一方で着信者は、携帯端末に電話帳に記録されていない電話番号から着信があった場合に、誰からの電話であるかを把握することが困難であり、安心して電話に出ることができないことがある。また、着信者はそのような着信を応答した後に、その電話番号等を登録するか否かを判断するが、電話帳への登録の手間がかかる。
【０００４】
特許文献１に記載の携帯端末では、携帯端末のユーザが一般的に自身の端末に保存する電話帳データをインターネット網に接続されたサーバ内に登録する。当該携帯端末は、着信時に着信相手の識別子を上記サーバに送信して、対応する電話帳データをダウンロードする。特許文献１に記載の携帯端末では、携帯端末内に電話帳データを保持しないため、携帯端末のメモリ容量を大きくすることなく、着信相手の情報を参照できるようになる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−７９８４５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の携帯端末では、携帯端末のユーザが把握している電話帳データのみを共有サーバから携帯端末にダウンロード可能であり、携帯端末のユーザが把握していない着信者の情報を取得することができない。そのため、特許文献１に記載の携帯端末によっては、発信者が自己の電話帳データを着信者に通知することができず、着信者に不審に思われて応答してもらえないことがある。
【０００７】
本発明は、このような問題点を解決するためになされたものであり、着信者の端末内に発信者の電話帳データを保持しない場合にも、発信者が発信者の電話帳データを着信者に通知できる電話帳管理システム及び電話帳管理方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明にかかる電話帳管理システムの一態様は、端末内に電話帳データを持たない発信者からの電話を着信した場合に、前記発信者の識別情報を用いてサーバに問い合わせを行い、問い合わせ結果である前記発信者の電話帳データをユーザに提示する通信端末と、
任意の電話発信者から電話帳データを受け付けて記憶し、前記通信端末からの前記識別情報を受信し、前記識別情報に対応する電話発信者の電話帳データを、前記通信端末に送信するサーバを備えるものである。
【０００９】
本発明にかかる電話帳管理方法の一態様は、サーバが任意の電話発信者から電話帳データを受け付けて記憶するステップと、通信端末において、端末内に電話帳データを持たない発信者からの電話を着信した場合に、前記発信者の識別情報を用いて前記サーバに問い合わせを行うステップと、前記サーバが前記通信端末からの前記識別情報を受信し、前記識別情報に対応する電話発信者の電話帳データを、前記通信端末に送信するステップと、前記通信端末が、問い合わせ結果である前記発信者の電話帳データをユーザに提示するステップとを備えるものである。
【発明の効果】
【００１０】
本発明により、着信者の端末内に発信者の電話帳データを保持しない場合であっても、発信者は発信者の電話帳データを着信者に通知することができる。
【図面の簡単な説明】
【００１１】
【図１】実施の形態１にかかる電話帳管理システムの構成図である。
【図２】実施の形態１にかかる電話着信時のフローチャート図である。
【図３】実施の形態１にかかる共有サーバより新規登録要求を行う場合の処理を示すフローチャート図である。
【図４】実施の形態１にかかる共有電話帳に登録された電話帳データの削除時のフローチャート図である。
【図５】実施の形態２にかかる端末から共有電話帳に登録を行う際の処理を示すフローチャート図である。
【図６】実施の形態３にかかる共有電話帳のデータ例である。
【発明を実施するための形態】
【００１２】
実施の形態１
以下に、図面を参照して本発明の実施の形態について説明する。まず、図１のシステム構成図を用いて、本発明の実施の形態１にかかる電話帳管理システムの構成について説明する。この電話帳管理システムは、着信端末１０１、発信端末１０２、電話帳データ登録ＰＣ１０３、共有電話帳サーバ１０４を備える。
【００１３】
着信端末１０１は、携帯電話等のユーザが電話を着信するために用いられる。着信端末１０１は、電話回線網１０５上で電話を発着信する機能と、着信時にかかってきた電話番号を基に自己のメモリ内の電話帳データを検索して結果を端末表示部に表示する機能と、インターネット網１０６上で通信を行い、共有サーバ１０４に電話帳データを問い合わせ、共有サーバ１０４から提供された情報を端末の表示部に表示する機能を備える。着信端末１０１の例として、携帯電話やＰＨＳ（Personal Handy phone System）等が挙げられる。
【００１４】
発信端末１０２は、ユーザが電話回線１０５を介して携帯電話や固定電話と通話するために用いられる。発信端末１０２は、電話回線網１０５を介して電話を発信する機能を備える。発信端末１０２は、電話回線網１０５上で発信できるものであれば、固定電話であっても携帯電話等の移動体端末であってもよい。
【００１５】
電話帳データ登録ＰＣ１０３は、発信端末１０２の発信者が自己の電話帳データを登録するために利用される。電話帳データ登録ＰＣ１０３は、インターネット網１０６上で通信を行う機能を備える。発信者は、電話帳データ登録ＰＣ１０３を用いて共有サーバ１０４に自己の電話帳データの登録を行う。電話帳データ登録ＰＣ１０３は、インターネット網１０６上で通信できるものであればよく、ＰＣ(Personal Computer)やＰＤＡ（Personal Digital Assistants）などが該当する。
【００１６】
共有サーバ１０４は、電話帳データを保持する機能、着信端末１０１からの電話帳データの問い合わせを受け付けて、該当する電話帳データを着信端末１０１に送信する機能、電話帳データ登録ＰＣ１０３から電話帳データの登録要求を受け付ける機能、保持している電話帳データを一定期間経過後に自動的に編集する機能を備える。
【００１７】
続いて、図１のシステム構成図及び図２のフローチャートを用いて、着信端末１０１に発信端末１０２から電話着信があった場合の処理について説明する。発信者は発信端末１０２を用いて、着信端末１０１に電話発信を行う。着信端末１０１は、発信端末１０２からの着信を受け付け（図２のＳ１）、着信のあった電話番号を基に着信端末１０１内のメモリに該当する電話帳データが登録されているかを検索する（図２のＳ２）。ここで、図１のＢ社の発信端末１０２から図１のＡさんの着信端末１０１に発信した場合、着信端末１０１は電話番号ｂ（０３−ｂｂｂｂ−ｂｂｂｂ）がメモリ内の電話帳データ内に存在するかを検索する。
【００１８】
着信端末１０１は、メモリ内に着信のあった電話番号に関する電話帳データがある場合、従来の着信処理に移行する（図２のＳ１０）。従来の処理とは、通信端末上のディスプレイに発信者の名前や電話番号、発信者の画像を表示することや、着信者ごとに固有の着信メロディを鳴動することなどが考えられる。本実施の形態では、Ａさんの着信端末１０１にＢ社の電話番号ｂが電話帳データとしてメモリ内に登録されていた場合、着信端末１０１は従来の着信処理を行う。
【００１９】
着信端末１０１は、メモリ内に着信のあった電話番号に関する電話帳データがなかった場合、共有サーバ１０４に電話帳データを問い合わせる（図２のＳ３）。本実施の形態では、Ａさんの着信端末１０１内にＢ社の電話番号ｂが電話帳データとして登録されていない場合、着信端末１０１は電話番号ｂを共有サーバ１０４に送信して、電話帳データを問い合わせる。
【００２０】
着信端末１０１から問い合わせを受けた共有サーバ１０４は、送信された電話番号を基に共有サーバ１０４が保持する共有電話帳を検索し（図２のＳ４）、問い合わせのあった日時や電話番号を検索履歴として保存する（図２のＳ５）。ここで、共有電話帳とは、任意のユーザの電話帳データ（電話番号、名前等）を保存するものであり、データベースのテーブル等の形式で格納される。本実施の形態では、共有サーバ１０４は、送信された電話番号ｂに関する電話帳データが共有電話帳に存在するか検索する。その後、共有サーバ１０４は、電話番号ｂの検索履歴を共有サーバ内に保存する。
【００２１】
共有サーバ１０４は、共有電話帳から検索した電話帳データを着信端末１０１に送信する（図２のＳ６）。本実施の形態では、共有サーバ１０４は、電話番号ｂに対応する電話帳データをＡさんの着信端末１０１に送信する。
【００２２】
共有サーバ１０４から電話帳データを受信した着信端末１０１は、その電話帳データをディスプレイ等に表示する（図２のＳ７、Ｓ８）。本実施の形態では、Ａさんの着信端末１０１は共有サーバ１０４から電話番号ｂに対応する電話帳データを受信し、その電話帳データをディスプレイ上に表示する。
【００２３】
次に、図１のシステム構成図及び図３のフローチャートを用いて、共有サーバ１０４の共有電話帳に電話帳データを新規登録する処理について説明する。図３では、共有電話帳への登録要求を共有サーバ１０４から発信端末１０２に対して行う処理を示す。
【００２４】
共有サーバ１０４は、１日ごとに共有電話帳の検索履歴を参照し、共有電話帳の未登録番号の１日における問い合わせ数を参照する（図３のＳ１）。共有サーバ１０４は、共有電話帳の未登録番号の１日における検索履歴が１００件未満であれば共有電話帳に登録する必要がないとみなし、その未登録番号についての処理を終了する（図３のＳ３）。なお、上記の検索履歴数の閾値は１００件である必要はなく、適宜変更できる。同様に、検索履歴を参照する頻度は１日ごとである必要はなく、システムの運用状況に合わせて適宜変更できる。本実施の形態において、電話番号ｂが共有電話帳に未登録であった場合、共有サーバ１０４は、電話番号ｂの問い合わせ数が１日に１００件未満であれば電話番号ｂを共有電話帳に登録する必要がないとみなし、処理を終了する。
【００２５】
共有サーバ１０４は、未登録番号であって１日の検索履歴が１００件以上である場合、当該番号に該当する発信端末１０２に電話を行い（図３のＳ４）、発信端末１０２に対して登録要求ガイダンスを流す（図３のＳ５）。本実施の形態では、共有サーバ１０４は、電話番号ｂの発信端末１０２のユーザに対して「共通電話帳サービスです。共通電話帳に電話番号ｂの登録を行う場合には０を、登録しない場合は１を押してください」というような電話でのガイダンス通知を行う。
【００２６】
上記のガイダンス通知を受けた発信端末１０２のユーザは、この登録要求に対する応答を行う（図３のＳ６）。発信端末１０２のユーザは、登録を行わない場合には電話を切断する（図３のＳ７）。共有サーバ１０４は、発信端末１０２のユーザが電話帳データの登録を行う場合、電話帳データの登録を行う際に用いるＩＤおよびパスワードを発行する。そののち、共有サーバ１０４は、当該ＩＤと当該パスワードを発信端末１０２の電話番号に関連付けて管理情報として保存する（図３のＳ８）。本実施の形態では、Ｂ社が登録要求を行った場合、共有サーバ１０４は電話番号ｂとＢ社向けに発行したＩＤとパスワードを管理情報として保存する。
【００２７】
共有サーバ１０４は、発行したＩＤとパスワードを発信端末１０２に通知し（図３のＳ９、Ｓ１０）、通知後に電話を切断する（図３のＳ１１）。本実施の形態では、共有サーバ１０４は、Ｂ社の発信端末１０２に電話番号ｂに対応するＩＤとパスワードをガイダンスで通知した後に、電話を切る。
【００２８】
発信者は、電話帳データ登録ＰＣ１０３を用いて、前記のＩＤとパスワードを認証情報として共有サーバ１０４にアクセスし、共有電話帳に発信端末１０２の電話帳データを登録する（図３のＳ１２）。電話帳データ登録ＰＣ１０３は、発信端末１０２と同じユーザが保有すると想定する。本実施の形態では、Ｂ社はＢ社の所有する電話帳データ登録ＰＣ１０３から電話番号ｂ用のＩＤとパスワードを用いて共有サーバ１０４にアクセスし、Ｂ社の発信端末１０２の電話帳データを共有電話帳に登録する。
【００２９】
続いて、図４のフローチャートを用いて、共有電話帳に登録されている電話帳データを削除する場合の動作について説明する。
【００３０】
共有サーバ１０４は、定期的に問い合わせ検索履歴を参照し、その問い合わせ頻度を調査する。共有サーバ１０４は、共有電話帳に登録されている電話帳データ毎に１か月の問い合わせ検索履歴を参照する（図４のＳ１）。問い合わせ検索履歴の数を調査する頻度は１か月でなくてもよく、システムの運用状況に応じて適宜変更可能である。本実施の形態では、共有サーバ１０４は、電話番号ｂに対応する電話帳データの１ヶ月間の問い合わせ数を確認する。
【００３１】
共有サーバ１０４は、前記問い合わせ数が月に１件以上あった場合には、処理を終了する（図４のＳ２）。一方、共有サーバ１０４は、月の問い合わせ数が０件であった場合には当該電話帳データの削除処理を行う（図４のＳ３）。なお、上記の問い合わせ数の閾値は適宜変更できる。本実施の形態では、Ｂ社の電話番号ｂに関する問い合わせが月に０件であった場合、共有サーバ１０４は、電話番号ｂに関する電話帳データを共有電話帳から削除する。
【００３２】
図４を用いて、定期的に問い合わせ数の少ない電話帳データを削除する処理を説明したが、本発明はこれに限られるものではない。例えば、共有電話帳のデータを一切削除しない運用や、共有サーバ１０４のディスク容量が少なくなってきた際には順次問い合わせ数の少ない電話帳データを削除する運用も可能である。
【００３３】
このような一連の処理により、発信者は自己の電話帳データを着信端末１０１内に保持しないユーザに対しても、自己の電話帳データを通知できる。
【００３４】
一方、着信者は、着信端末１０１内に電話帳データを持たない発信端末１０２から電話を受けた場合でも、発信者の電話帳データを参照することができる。また、共有サーバ１０４内に共有可能な電話帳データを持つことにより、着信者は、共有可能な電話番号データを着信端末１０１に登録する作業を行わなくても済む。
【００３５】
実施の形態２
本発明の実施の形態２は、図５に示すように発信端末１０２から共有サーバ１０４に電話帳データの登録要求を行うことを特徴とするものである。以下に、本発明の電話帳管理システムの動作について第１の実施の形態と異なる部分のみを説明する。
【００３６】
発信者は発信端末１０２を用いて、共有サーバ１０４へ電話を行い、電話帳データの登録、編集要求を行う（図５のＳ１、Ｓ２）。登録要求を受け付けた共有サーバ１０４は、発信端末１０２の電話番号を認識し、当該電話番号に関連付けられたＩＤとパスワードを発行する（図５のＳ３、Ｓ４）。本実施の形態において、Ｂ社が電話番号ｂについての電話帳データを登録する場合、Ｂ社は発信端末１０２を用いて共有サーバ１０４に電話を行い、電話帳データの登録要求を行う。電話番号ｂの登録要求を受け付けた共有サーバ１０４は、電話番号ｂを認識した上で、Ｂ社の発信端末１０２にＩＤとパスワードを通知する。
【００３７】
以後の登録処理及びシステムの構成等は実施の形態１と同様であるため、説明を省略する。上記の処理により、発信端末１０２に対する電話帳データの問い合わせが少ない場合であっても、発信者は自己の電話帳データを登録することができる。そのため、共有サーバ１０４に問い合わせへの少ない発信者からの着信を受けた場合でも、着信者は即時に電話帳データを参照することができる。
【００３８】
実施の形態３
本発明の実施の形態３は、一部の電話帳データの属性を、電話帳データを新規登録したユーザ以外のユーザである管理者等が編集できることを特徴とする。図６は、共有サーバに登録されている電話帳データの例を示すものである。以下に、本発明の電話帳管理システムの動作について第１、第２の実施の形態と異なる部分のみを説明する。
【００３９】
発信者は電話帳データ登録ＰＣ１０３を用いて、上記の実施形態１もしくは２と同様に自己の電話帳データを登録する。この場合、共有電話帳のデータの各カラムは電話帳データ登録ＰＣ１０３から受け付けるデータ属性と、管理者ユーザ等の電話帳登録ユーザ以外のユーザから登録を受け付ける管理データ属性を含む。図６の例では、「電話番号」、「名前」といったカラムは電話帳データ登録ＰＣ１０３から登録を受け付けるデータ属性である。一方、「悪質ユーザ」といったデータ属性は共有サーバ１０４の管理者等の権限を持ったユーザから入力を受け付ける管理データ属性である。
【００４０】
共有サーバ１０４の管理者等の権限を持ったユーザは、着信者からの苦情等を受け付けて、適宜各電話帳データのカラムの管理データ属性を編集する。なお、共有サーバ１０４の管理者等の権限を持ったユーザは、全てのデータ属性に関して編集可能とする構成であってもよい。共有サーバ１０４は、発信端末１０２からの問い合わせを受けた場合、上記の管理者データ属性も発信端末１０２に送信する。本実施の形態では、共有サーバ１０４の管理者は、電話番号「０３−ｙｙｙｙ−ｙｙｙｙ」が悪質なユーザである旨を登録する。共有サーバ１０４は、発信端末１０２から電話番号「０３−ｙｙｙｙ−ｙｙｙｙ」の問い合わせを受けた場合、発信端末１０２に対して当該ユーザが悪質ユーザである旨も電話番号等の情報と共に通知する。
【００４１】
このような一連の処理により、共有サーバ１０４は、悪質な電話通知を行う発信者の情報を事前に通知でき、着信者に対して注意を促すことができる。一方、着信者は、振り込め詐欺や悪質なセールス等の被害報告のある電話番号からの着信時に、悪質なユーザからの着信であることを事前に認識できる。
【００４２】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、着信端末１０１は共有サーバ上で問い合わせの多い電話帳データを予め端末内にダウンロードしておくことにより、着信時の通信量を削減することも考えられる。また、共有サーバ１０４の電話帳データ登録にかかるアクセス権限はユーザ毎に変更できるようにしてもよい。さらに、共有電話帳の電話帳データの開示範囲を定めておくものとし、例えば共有サーバ１０４は、同一会社等に所属している着信者にのみ電話帳データを通知するような応用も考えられる。
【符号の説明】
【００４３】
１０１  着信端末
１０２  発信端末
１０３  電話帳データ登録ＰＣ
１０４  共有サーバ
１０５  電話回線網
１０６  インターネット網
【図１】
2010268178.tif 000003
【図２】
2010268178.tif 000004
【図３】
2010268178.tif 000005
【図４】
2010268178.tif 000006
【図５】
2010268178.tif 000007
【図６】
2010268178.tif 000008