(57)【要約】【課題】公共電話ディレクトリサービスを提供及び管理するための方法及びシステム【解決手段】    ディレクトリサービスにおいて用いるための装置が開示される。前記装置は、ローカルディレクトリを格納するように構成されたメモリと、前記ローカルディレクトリを管理するように構成されたプロセッサと、を含むことができ、前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる。【選択図】    図１
2008543132.tif 000002
【特許請求の範囲】
【請求項１】
ディレクトリサービスにおいて用いるための装置であって、
ローカルディレクトリを格納するように構成されたメモリと、
前記ローカルメモリを管理するための手段と、を具備し、前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる、装置。
【請求項２】
特定のユーザーの連絡先情報を要求するための手段であって、前記要求は、前記特定のユーザーに関する別名を含む手段と、
前記要求に従った応答を受け取るための手段と、をさらに具備し、前記応答は、前記特定のユーザーの前記連絡先情報を含み、前記応答は、前記要求及び前記特定のユーザーと関連づけられた追加情報に基づいて個別適合化される請求項１に記載の装置。
【請求項３】
前記要求は、ユーザーに関連する情報又は前記装置に関連する情報のうちの１つ又は両方をさらに含む請求項２に記載の装置。
【請求項４】
前記ローカルディレクトリを前記連絡先情報によって更新するための手段をさらに具備する請求項２に記載の装置。
【請求項５】
前記追加情報は、前記特定のユーザーのアクセス方針を含む請求項２に記載の装置。
【請求項６】
前記複数のディレクトリエントリは、ドメイン名システム（ＤＮＳ）プロトコルに基づいて実装される請求項１に記載の装置。
【請求項７】
前記ローカルディレクトリを遠隔データベースに格納されている前記ローカルディレクトリのコピーと同期化するための手段をさらに具備する請求項１に記載の装置。
【請求項８】
ディレクトリサービスにおいて用いるための方法であって、前記方法は、
ローカルディレクトリを生成することと、
前記ローカルディレクトリを管理することと、を具備し、
前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる、方法。
【請求項９】
ディレクトリサービスにおいて用いるためのプロセッサであって、前記プロセッサは、
ローカルディレクトリを生成することと、
前記ローカルディレクトリを管理することと、を制御するように構成され、
前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる、プロセッサ。
【請求項１０】
特定のユーザーの連絡先情報を要求すること及び前記要求に従った応答を受け取ることを制御するようにさらに構成され、前記要求は、前記特定のユーザーに関する別名を含み、前記応答は、前記特定のユーザーの前記連絡先情報を含み、前記応答は、前記要求及び前記特定のユーザーと関連づけられた追加情報に基づいて個別適合化される請求項９に記載のプロセッサ。
【請求項１１】
前記ローカルディレクトリを前記連絡先情報によって更新することを制御するようにさらに構成された請求項１０に記載のプロセッサ。
【請求項１２】
前記追加情報は、前記特定のユーザーのアクセス方針を含む請求項１０に記載のプロセッサ。
【請求項１３】
前記複数のディレクトリエントリは、ドメイン名システム（ＤＮＳ）プロトコルに基づいて実装される請求項９に記載のプロセッサ。
【請求項１４】
前記ローカルディレクトリを遠隔データベースに格納されている前記ローカルディレクトリのコピーと同期化することを制御するようにさらに構成された請求項９に記載のプロセッサ。
【請求項１５】
ディレクトリサービスにおいて用いるためのサーバーであって、前記サーバーは、
複数のユーザーに対応する複数のディレクトリを格納するように構成されたデータベースであって、各ディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、対応するユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記対応するユーザーに関する連絡先情報を含むレコードにリンクされるデータベースと、
前記データベースを管理するように構成されたプロセッサと、を具備するサーバー。
【請求項１６】
前記プロセッサは、前記複数のディレクトリ間における前記複数のディレクトリエントリの系統立てを前記サブドメイン階層情報を用いて最適化するようにさらに構成される請求項１５に記載のサーバー。
【請求項１７】
前記プロセッサは、前記複数のディレクトリ間における前記複数のディレクトリエントリを前記サブドメイン階層情報を用いて評価するように及び前記ユーザー間における複数の関係を特定するようにさらに構成される請求項１５に記載のサーバー。
【請求項１８】
前記複数の関係は、２人のユーザー間における分離度を含む請求項１７に記載のサーバー。
【請求項１９】
前記複数のディレクトリエントリは、ドメイン名システム（ＤＮＳ）プロトコルに基づいて実装される請求項１５に記載のサーバー。
【請求項２０】
ディレクトリサービスにおいて用いるための方法であって、前記方法は、
複数のユーザーに属する複数のディレクトリを格納するようにデータベースを構成することであって、各ディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、対応するユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記対応するユーザーに関する連絡先情報を含むレコードにリンクされることと、
前記データベースを管理することと、を具備する方法。
【請求項２１】
ディレクトリサービスにおいて用いるためのプロセッサであって、前記プロセッサは、
複数のユーザーに属する複数のディレクトリを格納することであって、各ディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、対応するユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記対応するユーザーに関する連絡先情報を含むレコードにリンクされることと、
前記複数のディレクトリを管理することと、
を具備する方法を制御するように構成されたプロセッサ。
【請求項２２】
前記方法は、前記複数のディレクトリ間における前記複数のディレクトリエントリの系統立てを前記サブドメイン階層情報を用いて最適化することをさらに具備する請求項２１に記載のプロセッサ。
【請求項２３】
前記方法は、前記複数のディレクトリ間における前記複数のディレクトリエントリを前記サブドメイン階層情報を用いて評価することと、
前記ユーザー間における複数の関係を特定することと、をさらに具備する請求項２１の記載のプロセッサ。
【請求項２４】
前記複数の関係は、２人のユーザー間における分離度を含む請求項２３に記載のプロセッサ。
【請求項２５】
前記方法は、前記２人のユーザー間における前記分離度関係に関する情報を求める要求を受け取ることと、
前記要求を評価することと、
前記２人のユーザー間における前記分離度関係に関する前記情報を転送すること、とをさらに具備する請求項２４に記載のプロセッサ。
【請求項２６】
前記複数のディレクトリエントリは、ドメイン名システム（ＤＮＳ）プロトコルに基づいて実装される請求項２１に記載のプロセッサ。
【請求項２７】
ディレクトリサービスにおいて用いるための機械読み取り可能媒体であって、前記機械読み取り可能媒体は、
サブドメイン階層構造において系統立てられた複数のディレクトリエントリを具備し、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる、機械読み取り可能媒体。
【請求項２８】
プロセッサによって実行可能な制御論理を具備する機械読み取り可能媒体であって、前記制御論理は、複数の命令を含み、前記複数の命令は、
前記ローカルディレクトリを管理するための一組の命令を具備し、
前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層構造情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる、機械読み取り可能媒体。
【請求項２９】
前記複数の命令はさらに、
特定のユーザーの連絡先情報を要求するための一組の命令であって、前記要求は、前記特定のユーザーに関する別名を含む一組の命令と、
前記要求に従った応答を受け取るための一組の命令であって、前記応答は、前記特定のユーザーに関する前記連絡先情報を含み、前記応答は、前記要求及び前記特定のユーザーと関連づけられた追加情報に基づいて個別適合化される一組の命令と、
を具備する請求項２８に記載の機械読み取り可能媒体。
【請求項３０】
前記複数の命令は、前記応答に含まれている前記連絡先情報を用いて前記ローカルディレクトリを更新するための一組の命令をさらに具備する請求項２８に記載の機械読み取り可能媒体。
【請求項３１】
ディレクトリサービスにおいて用いるためのサーバーであって、
複数のディレクトリエントリを格納するように構成されたメモリと、
プロセッサと、を具備し、
前記プロセッサは、
特定のユーザーに対する要求を受け取ることと、
前記特定のユーザーに関する対応するディレクトリエントリを前記要求に従って前記複数のディレクトリエントリから検索することであって、前記複数のディレクトリエントリのうちの少なくとも１つは、前記エントリと関連づけられた１つ以上の電話番号及び追加情報を含むことと、
前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報に基づいて応答を個別適合化することと、を制御するように構成されたサーバー。
【請求項３２】
前記要求は、前記要求を行っているユーザーに関連する情報又はクライアントに関連する情報のうちの１つ又は両方をさらに含む請求項３１に記載のサーバー。
【請求項３３】
前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報は、前記特定のユーザーのアクセス方針を含み、前記アクセス方針は、前記応答を個別適合化する方法を決定するために用いられる請求項３１に記載のサーバー。
【請求項３４】
前記プロセッサは、前記応答を状態情報に基づいて個別適合化するようにさらに構成される請求項３１に記載のサーバー。
【請求項３５】
前記状態情報は、ネットワーク上における前記特定のユーザーの存在を含む請求項３４に記載のサーバー。
【請求項３６】
前記プロセッサは、ドメイン名システム（ＤＮＳ）プロトコルを用いて前記要求を受け取るようにさらに構成される請求項３１に記載のサーバー。
【請求項３７】
前記プロセッサは、前記複数のディレクトリエントリにおけるディレクトリエントリを更新するようにさらに構成される請求項３１に記載のサーバー。
【請求項３８】
前記プロセッサは、クライアントに格納されたローカルディレクトリのコピーを維持するようにさらに構成される請求項３１に記載のサーバー。
【請求項３９】
前記プロセッサは、前記クライアントに格納された前記ローカルディレクトリを前記ローカルディレクトリの前記コピーと同期化するようにさらに構成される請求項３８に記載のサーバー。
【請求項４０】
ディレクトリサービスにおいて用いるための方法であって、前記方法は、
複数のユーザーに属する複数のディレクトリエントリを格納するようにデータベースを構成することであって、前記複数のディレクトリエントリのうちの少なくとも１つは、前記エントリと関連づけられた１つ以上の電話番号及び追加情報を含むことと、
特定のユーザーの情報要求を受け取ることと、
前記特定のユーザーに関する前記対応するディレクトリエントリを前記データベースから検索することと、
前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報に基づいて応答を個別適合化すること、とを具備する、方法。
【請求項４１】
ディレクトリサービスにおいて用いるためのプロセッサであって、前記プロセッサは、
複数のユーザーに属する複数のディレクトリエントリを格納することであって、前記複数のディレクトリエントリのうちの少なくとも１つは、前記エントリと関連づけられた１つ以上の電話番号及び追加情報を含むことと、
特定のユーザーの情報要求を受け取ることと、
前記特定のユーザーに関する前記対応するディレクトリエントリを前記データベースから検索することと、
前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報に基づいて応答を個別適合化することと、
を制御するように構成されたプロセッサ。
【請求項４２】
前記要求は、ユーザーに関連する情報又はクライアントに関連する情報のうちの１つ又は両方を含む請求項４１に記載のプロセッサ。
【請求項４３】
前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報は、前記特定のユーザーのアクセス方針を含み、前記アクセス方針は、前記応答を個別適合化する方法を決定するために用いられる請求項４１に記載のプロセッサ。
【請求項４４】
前記データベース内のディレクトリエントリを更新することを制御するようにさらに構成された請求項４１に記載のプロセッサ。
【請求項４５】
ローカルディレクトリを維持すること及び保存を目的として前記ローカルディレクトリのコピーを前記データベースに転送することを制御するようにさらに構成された請求項４１に記載のプロセッサ。
【請求項４６】
前記ローカルディレクトリを前記データベースに格納された前記ローカルディレクトリの前記コピーと同期化することを制御するようにさらに構成された請求項４５に記載のプロセッサ。
【請求項４７】
ディレクトリサービスにおいて用いるためのプロセッサであって、前記プロセッサは、
特定のユーザーに対して連絡先情報を求めるユーザー入力を受け取ることと、
前記入力に基づいて要求を生成することであって、前記要求は、前記特定のユーザーに関する対応するディレクトリエントリを複数のディレクトリエントリから検索するために用いられ、前記複数のディレクトリエントリのうちの少なくとも１つは、前記エントリと関連づけられた１つ以上の電話番号及び追加情報を含むことと、
前記要求に従った応答を受け取ることであって、前記応答は、前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報に基づいて個別適合化されることと、を制御するように構成されたプロセッサ。
【請求項４８】
前記要求は、ユーザーに関連する情報又はクライアントに関連する情報うちの１つ又は両方を含む請求項４７に記載のプロセッサ。
【請求項４９】
前記要求及び前記応答は、ドメイン名システム（ＤＮＳ）プロトコルを用いて実装される請求項４７に記載のプロセッサ。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般的には、公共電話ディレクトリに関するものである。本開示は、より具体的には、ネットワークに基づく公共電話ディレクトリサービスを提供及び管理するための方法及びシステムに関するものである。
【背景技術】
【０００２】
発呼者が電話で他の個人に連絡する必要があるときには、発呼者は、その個人の電話番号を知っていることが要求される。要求される電話番号を入手できない場合は、電話をかけることができない。人々は、様々な手段を利用してそれぞれの個人の電話ディレクトリを維持している。依然として伝統的な紙の個人のディレクトリを用いて電話番号を維持している人もいる。しかしながら、電子デバイスの能力の向上および爆発的な普及に伴い、個人的な電話ディレクトリを携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）及びコンピュータ等の自分自身の電子デバイスにおいて電子的に維持する人がますます増えてきている。
【０００３】
個人の電話ディレクトリを維持するために電子デバイスを用いるのは普通のことになっているが、これらのディレクトリは非常に個人的で局在化している。例えば、個人のディレクトリを携帯電話に保存していることがある。このようなディレクトリは、特定の携帯電話に常駐しており、その携帯電話が物理的に利用可能でなければユーザーはアクセスできない。従って、ユーザーが自分の携帯電話を忘れてしまった場合は、携帯電話に常駐するディレクトリから情報を取り出す方法がない。さらに、携帯電話のディレクトリは、その他のユーザーは簡単にアクセスできない。一部の携帯電話又はＰＤＡは、情報交換を容易にするための短距離無線アプリケーションを備えているが、情報交換は、一般的には、両方のデバイスが相対的に互いに接近しているその場の状況に限定される。
【０００４】
公共電子電話ディレクトリは、インターネット上でも利用可能である。しかしながら、これらのディレクトリは、異なる事業体によって独立して編集される傾向がある。その結果、ディレクトリ間での同期化がほとんどなく、電話番号の変更が常に有効な形ですべてのディレクトリに行き渡るわけではない。さらに、これらのディレクトリは異なる事業体によって編集されるため、所有者は、自分の電話番号の問い合わせ及び配信に対してほとんど又はまったく管理権を行使していない。
【０００５】
従って、とりわけ上記の問題の少なくとも一部を解決するために用いることができるネットワーク型の公共電話ディレクトリサービスを提供することができる方法及びシステムを提供するのが望ましい。
【発明の開示】
【発明の概要】
【０００６】
本明細書において開示される技術は、ローカルディレクトリを格納するように構成されたメモリ及び前記ローカルメモリを管理するための手段を具備するディレクトリサービス用の装置を提供することによって上記のニーズに対処するものであり、前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名（ａｌｉａｓ）と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる。前記装置は、特定のユーザーの連絡先情報を要求するための手段と、前記要求に従った応答を受け取るための手段と、をさらに含むことができ、前記要求は、前記特定のユーザーに関する別名を含み、前記応答は、前記特定のユーザーの前記連絡先情報を含み、前記応答は、前記要求及び前記特定のユーザーと関連づけられた追加情報に基づいて個別に適合化される。
【０００７】
他の側面においては、ローカルディレクトリを作成するために及び前記ローカルディレクトリを管理するためにディレクトリサービスにおいて用いるための方法及びプロセッサが開示され、前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる。前記方法及びプロセッサは、特定のユーザーの連絡先情報を要求すること及び前記要求に従った応答を受け取ることをさらに具備することができ、前記要求は、前記特定のユーザーに関する別名を含み、前記応答は、前記特定のユーザーの前記連絡先情報を含み、前記応答は、前記要求及び前記特定のユーザーと関連づけられた追加情報に基づいて個別に適合化される。
【０００８】
さらなる側面においては、ディレクトリサービスにおいて用いるためのサーバーは、複数のユーザーに対応する複数のディレクトリを格納するように構成されたデータベースと、前記データベースを管理するように構成されたプロセッサと、を具備し、各ディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、対応するユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記対応するユーザーに関する連絡先情報を含むレコードにリンクされる。
【０００９】
さらに他の側面においては、複数のユーザーに属する複数のディレクトリを格納するために及び前記データベースを管理するためにディレクトリサービスにおいて用いるための方法及びプロセッサが開示され、各ディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、対応するユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記対応するユーザーに関する連絡先情報を含むレコードにリンクされる。
【００１０】
上記のサーバー及びプロセッサにおいては、前記プロセッサは、前記サブドメイン階層情報を用いて前記複数のディレクトリ間における前記複数のディレクトリエントリの系統立てを最適化すること、前記サブドメイン階層情報を用いて前記複数のディレクトリ間において前記複数のディレクトリエントリを評価して前記ユーザー間における複数の関係を特定すること、及び２人のユーザー間の分離度関係に関する情報を求める要求を受け取り、前記要求を評価して前記２人のユーザー間の前記分離度関係に関する情報を転送すること、のうちの１つ又はその組合せ制御するように構成することができる。
【００１１】
さらに他の側面においては、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを具備する、ディレクトリサービスにおいて用いるための機械読み取り可能媒体が開示され、各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる。その他の側面においては、前記機械読み取り可能媒体は、プロセッサによって実行可能な制御論理を含むことができ、前記制御論理は、複数の命令を含み、前記複数の命令は、前記ローカルディレクトリを管理するための一組の命令を具備し、前記ローカルディレクトリは、サブドメイン階層構造において系統立てられた複数のディレクトリエントリを含み、各ディレクトリエントリは、サブドメイン階層構造を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされ、前記ユーザードメインは、前記ユーザーに関する連絡先情報を含むレコードにリンクされる。
【００１２】
依然としてさらなる側面においては、複数のディレクトリエントリを格納するように構成されたメモリと、特定のユーザーに関する要求を受け取ること、前記特定のユーザーに関する対応するディレクトリエントリを前記要求に従って前記複数のディレクトリエントリから検索すること、及び前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報に基づいて応答を個別適合化することを制御するように構成されたプロセッサと、を具備し、前記複数のディレクトリエントリのうちの少なくとも１つは、前記エントリと関連づけられた１つ以上の電話番号及び追加情報を含む、ディレクトリサービスにおいて用いるためのサーバーが開示される。
【００１３】
依然としてさらなる側面においては、複数のユーザーに属する複数のディレクトリエントリを格納するため、特定のユーザーの情報要求を受け取るため、前記特定のユーザーに関する前記対応するディレクトリエントリを前記データベースから検索するため、及び前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた追加情報に基づいて応答を個別適合化するためにディレクトリサービスにおいて用いるための方法及びプロセッサが開示され、前記複数のディレクトリのうちの少なくとも１つのは、前記エントリと関連づけられた１つ以上の電話番号及び追加情報を含む。
【００１４】
上記のサーバー及びプロセッサにおいて、前記プロセッサは、前記データベース内のディレクトリエントリを更新すること、ローカルディレクトリを維持して前記ローカルディレクトリのコピーを保存目的で前記データベースに転送すること、前記ローカルディレクトリを前記データベースに格納された前記ローカルディレクトリの前記コピーと同期化させること、及び、特定のユーザーに関する連絡先情報を求めるユーザー入力要求を受け取り、前記入力に基づいて要求を生成し、前記要求に従った応答を受け取ることのうちの１つ又は組合せを制御するようにさらに構成することができ、前記要求は、前記特定のユーザーに関する対応するディレクトリエントリを複数のディレクトリエントリから検索するために用いられ、前記応答は、前記要求及び前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報に基づいて個別適合化される。
【００１５】
さらに、上記の説明において、前記要求は、前記要求を行っているユーザーに関連する情報又はクライアントに関連する情報のうちの１つ又は両方をさらに含むことができる。前記特定のユーザーに対応する前記ディレクトリエントリと関連づけられた前記追加情報は、前記特定のユーザーのアクセス方針を含むことができ、前記アクセス方針は、前記応答を個別適合化する方法を決定するために用いられる。前記プロセッサは、状態情報に基づいて前記応答を個別適合化するようにさらに構成することができる。前記状態情報は、ネットワーク上における前記特定のユーザーの存在を含むことができる。さらに、前記要求は、ドメイン名システム（ＤＮＳ）プロトコルを用いて受け取ることができる。
【００１６】
以下の発明を実施するための最良の形態から本発明のその他の実施形態が当業者に容易に明確になることが理解され、以下の発明を実施するための最良の形態では、本発明の様々な実施形態が示されており、例を用いて説明される。理解されることになるように、本発明は、その他の異なる実施形態又は実施形態の組合せが可能であり、その幾つかの詳細は、その他の様々な側面において変更可能である。従って、図面及び発明を実施するための最良の形態は、本質的に例示することを目的とするとみなすべきであって、制限するものであるとはみなすべきでない。
【００１７】
本発明の側面は、添付図面においては、限定することではなく例示することを目的として説明されている。
【発明を実施するための最良の形態】
【００１８】
以下において添付図と関連させて説明されている発明を実施するための最良の形態は、本発明の様々な実施形態について説明することが意図されており、本発明を実践することができる実施形態のみを表すことは意図されていない。発明を実施するための最良の形態は、本発明を徹底的に理解できるようにすることを目的とする特定の詳細を含む。しかしながら、本発明はこれらの特定の詳細なしで実践可能であることが当業者にとって明確になるであろう。幾つの例においては、本発明の概念を不明瞭にすることを回避するために、よく知られた構造及び構成要素がブロック図の形で示されている。
【００１９】
図１は、ディレクトリサービスを実装するために用いることができる１つのシステム構成である。様々な型のディレクトリサービスを用いることが可能である一方で、ネットワークに基づく公共電話帳サービス（ＰＰＢＳ）を、説明を目的とする一例として用いることができる。一実施形態においては、システム１００は、ドメイン名システム（ＤＮＳ）インフラを利用して実装することができる。ＤＮＳに関するプロトコルは、ＲＦC(コメント要求)１０３４及び１０３５において定義されている。ＤＮＳの主機能は、インターネットドメイン又はホスト名とその対応するインターネットプロトコル（ＩＰ）アドレスとの間のマッピングを取り扱うことである。ドメイン名／ＩＰアドレス通信の中央リストを維持するのは非実際的になるため、ドメイン名及びＩＰアドレスのリストが権限階層においてインターネット全体に配信される。システム１００はＤＮＳインフラを用いて実装できる一方で、当業者は、本明細書において提供される開示及び教義に基づいてその他の型のプロトコル及びアーキテクチャを用いてシステム１００を実装する方法を理解するであろうという点に注目すべきである。
【００２０】
ＤＮＳのアーキテクチャは、クライアント−サーバーモデルを用いる。簡単に説明すると、ＤＮＳの使用方法は次のとおりである。すなわち、ドメイン名をＩＰアドレスにマッピングするため、アプリケーションプログラムがリゾルバーと呼ばれるライブラリ手順を呼び出す。ドメイン名がパラメータとして渡される。リゾルバーがローカルＤＮＳサーバーにパケットを送る。ローカルＤＮＳサーバーがドメインを検索してＩＰアドレスをリゾルバーに戻す。リゾルバーがＩＰアドレスをアプリケーションプログラムに戻す。これでＩＰアドレスを入手できたため、アプリケーションプログラムは、ドメイン名によって表される行先との接続を確立させることができる。
【００２１】
既存のＤＮＳインフラは、ネットワークに基づくＰＰＢＳを実装するように改修することが可能である。システム１００は、ルートサーバー１０２、権威ＤＮＳサーバー（ａｕｔｈｏｒｉｔａｔｉｖｅ  ＤＮＳ  ｓｅｒｖｅｒ）１０４、サービスプロバイダＤＮＳサーバー１０６、ＰＰＢＳデータベース１０８、関連する管理インタフェース１１０、標準的ＤＮＳクライアント１１２，ＰＰＢＳイネーブルドクライアント（ＰＰＢＳ−ｅｎａｂｌｅｄ  ｃｌｉｅｎｔ）１１４、コンピュータネットワーク１１６（インターネット等）、及び無線ネットワーク１１８を含む幾つかのサーバーを含むことができる。ルートサーバー１０２、サービスプロバイダＤＮＳサーバー１０６、権威ＤＮＳサーバー１０４、ＰＰＢＳデータベース及び管理インタフェース１１０は、別個の要素として示されているが、すべての要素又はその組合せを１つにまとめて実装することができる。
【００２２】
標準的ＤＮＳクライアント１１２は、ＤＮＳプロトコルをサポートできるあらゆるデバイスを含むことができる。例えば、標準的ＤＮＳクライアント１１２は、ＰＰＢＳデータベース１０８からの情報を要求するための標準的なＤＤＳ問い合わせを出すことができる。
【００２３】
ＰＰＢＳイネーブルドクライアント１１４は、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）及びその他の型の移動体通信デバイス等のモバイルデバイスを含む。ＰＰＢＳイネーブルドクライアント１１４は、ＰＰＢＳアプリケーションに加えてＤＮＳプロトコルをサポートするように構成することができる。ＰＰＢＳイネーブルドクライアント１１４はモバイルデバイスである必要はなく、ＤＮＳプロトコル及びＰＰＢＳアプリケーションをサポートするように構成することができるあらゆるデバイスを用いることができる。
【００２４】
図２は、ＰＰＢＳイネーブルドクライアント１１４として用いることができる携帯電話２００等のモバイルデバイス例を示す。携帯電話２００は、トランシーバ２０２と、ＰＰＢＳアプリケーション論理２０４と、ユーザーインタフェース２０６と、メモリ２０８と、プロセッサ２１６と、を含むことができる。
【００２５】
トランシーバ２０２は、携帯電話２００に信号を送信するように及び携帯電話２００から信号を受信するように構成することができる。トランシーバ２０２は、携帯電話による無線ネットワーク１１８との通信を容易にすることができる。トランシーバ２０２と関連づけられた制御論理は、符号化及び変調等の様々な信号処理機能をさらに提供することができる。ＣＤＭＡ（符号分割多重接続）電話の場合は、前記制御論理は、拡散スペクトル処理を含むこともできる。
【００２６】
ユーザーインタフェース２０６は、例えば、携帯電話２００のユーザーが一定の情報を閲覧して携帯電話２００に入力を提供するのを可能にする画面、キーパッド又はその他の入力／出力デバイスを含むことができる。例えば、ユーザーインタフェース２０６は、ＰＰＢＳデータベース１０８内の電話帳エントリの要求を構成するために用いられる検索情報を提供するためにユーザーによって用いることができる。
【００２７】
ＰＰＢＳアプリケーション論理２０４は、対応するＰＰＢＳアプリケーションをサポートするように構成される様々な型の制御論理を含むことができる。前記アプリケーションは、例えば、エントリ生成、検索、更新、バックアップ及びダウンロードアプリケーションを含むことができる。例えば、一アプリケーションは、ＤＮＳサブドメイン概念及びＤＮＳ別名に基づいて電話帳を構築するためにユーザーによって用いることができる。このアプリケーション及びその他のアプリケーションが以下においてさらに説明される。電話帳はディレクトリの１つの型であることに注目すべきである。
【００２８】
従って、電話帳以外のディレクトリ、例えば、ただし限定することなしに、住所録、照会録又は連絡先リスト等を、ディレクトリサービスを提供することを目的として実装することができる。しかしながら、ディレクトリサービスはＰＰＢＳに関して説明されているため、電話帳は、同じく説明を目的とする一例として用いられる。
【００２９】
メモリ２０８は、例えばユーザー情報２１０、デバイス情報２１２及びローカル電話帳２１４を含む様々な型の情報を格納するために用いることができる。ユーザー情報２１０は、ＰＰＢＳデータベース１０８内の電話帳エントリのユーザーと所有者との間の関係情報を含むことができる。ローカル電話帳２１４は、ＰＰＢＳデータベース１０８から取り出されたエントリに加えてユーザーによって生成された電話帳エントリを格納するために用いることができる。
【００３０】
プロセッサ２１６は、上述される様々な構成要素間での調整を提供することによって携帯電話２００の動作を制御するように構成することができる。
【００３１】
サービスプロバイダＤＮＳサーバー１０６は、ＰＰＢＳイネーブルクライアント１１４から要求または問い合わせを受け取って前記要求への応答を提供するように構成することができる。要求は、ＰＰＢＳデータベース１０８内に格納されている特定の電話帳エントリの要求であることができる。サービスプロバイダＤＮＳサーバー１０６は、ＰＰＢＳデータベース１０８からの該当情報の取り出しを行うためにルートサーバー１０２及び権威ＤＮＳサーバー１０４と協力することができる。サービスプロバイダＤＮＳサーバー１０６は、ＰＰＢＳイネーブルドクライアント１１８に関する無線通信サービスを提供する遠距離通信事業者によって運用されるサーバーであることができる。
【００３２】
ルートサーバー１０２は、権威ＤＮＳサーバー１０４に関するディレクトリ情報を維持するサーバーであることができる。ルートサーバー１０２は、問い合わせ者が権威ＤＮＳサーバー１０４に接触するのを可能にする情報を問い合わせ者に提供することができる。
【００３３】
権威ＤＮＳサーバー１０４は、特定のドメインと関連づけられた情報、例えば、ＰＰＢＳデータベース１０８内に格納されているＰＰＢＳと関連づけられた電話帳エントリ等を維持及び管理する当局であることができる。従って、権威ＤＮＳサーバー１０４を介してＰＰＢＳデータベース１０８から入手された電話帳エントリはすべて常に正確である。
【００３４】
サービスプロバイダＤＮＳサーバー１０６、ルートサーバー１０２及び権威ＤＮＳサーバー１０４は、本明細書において説明される各々の機能を実行するように構成される制御論理及びメモリを有するプロセッサをさらに含むことができる。図８は、サービスプロバイダＤＮＳサーバー１０６、ルートサーバー１０２及び権威ＤＮＳサーバー１０４によって引き受けることができるサーバー８００の一構成を示す単純化された概略図である。サーバー８００は、制御論理８０４及びメモリ８０６を有するプロセッサ８０２を含むことができる。
【００３５】
ＰＰＢＳデータベース１０８は、対応するＰＰＢＳユーザーに関する電話情報及びその他の関連情報を含む電話帳エントリを格納するように構成することができる。ＰＰＢＳデータベース１０８は、ＰＰＢＳユーザーが各々の電話帳を格納するのを可能にするように構成することも可能である。ＰＰＢＳデータベース１０８内の情報は、ユーザーが自分にとって最も合理的である方法で電話帳内のエントリを系統立てて名前を付けるのを可能にするためにＤＮＳサブドメイン概念及びＤＮＳ別名に基づいて系統立てられる。ＤＮＳ別名は、ＤＮＳプロトコルに基づくＣＮＡＭＥリソースレコードと呼ぶことも可能である。適用可能なＤＮＳプロトコルを用いて系統立てるときには、各電話帳エントリは、問い合わせ、更新等の数多くのＤＮＳ機能において用いることができるＤＮＳ名にまとめることができる。管理インタフェース１１０は、管理者がPPBSデータベース１０８内に格納された電話帳エントリを維持するために用いることができる。上記の構成要素の相互接続及び相互の動作に関する詳細が以下においてさらに説明される。
【００３６】
図３は、ＰＰＢＳサービスに適用されるＤＮＳサブドメイン概念及びＤＮＳ別名を示す。指定文字“ｃｏｍ”３００は、最上位のドメインを指す。ＰＰＢＳサービスは、最上位の“ｃｏｍ”ドメインの下位ドメイン、例えば“ｐｐｂｓ”３０２として処理される。各ＰＰＢＳユーザーは、“ｐｐｂｓ”ドメインの下位の対応するサブドメインが割り当てられる。割り当てられたサブドメインは、そのユーザーの電話帳に関するデフォルトドメインとして用いられる。例えば、ユーザーＡに関する割り当てられたサブドメインは、「ユーザーＡ」３０４であることができる。ＤＮＳサブドメイン概念は、サブドメインの下位においてさらなるサブドメインを生成することを可能にする。このようにしてサブドメインを用いることは、ユーザーが自己の電話ディレクトリをカスタム化された形で系統立てるためのサブドメインを生成することを可能にする。例えば、ユーザーは、サブドメイン「ユーザーＡ」３０４の下位において、ユーザーＡの家族及び友人及び会社の同僚に関する電話番号及び連絡先情報をそれぞれ格納するための「家族及び友人」３０８及び「仕事」３１０のサブドメインをさらに生成することができる。同様に、「家族及び友人」３０８及び「仕事」３１０の各々のサブドメインの下位において追加のサブドメインを生成することが可能である。例えば、サブドメイン「子供」３１２をサブドメイン「家族及び友人」３０８の下位において生成することができる。
【００３７】
図３に示されるように、サブドメインは、ＤＮＳ別名を用いて名前を付けることができる。ユーザーは、自己の電話帳又はディレクトリにおいて希望するユーザーサブドメイン又はレコードを有意であるニックネーム（すなわち、ＤＮＳ別名）と関連づけることができる。各ＤＮＳ別名は、真のレコードを参照しており、同じレコードを参照するために異なる別名を用いることができる。この方法により、異なるユーザーが自分にとって意味のある形で名前が付けられた別名を生成することができる。例えば、両方の別名が同じ“johndoe.ppbs.com”を指しているにもかかわらず、１人のユーザーは、レコードを別名「上司」と関連づけるのを選択することができ、他のユーザーは、レコードを別名「お父さん」と関連づけるのを選択することができる。
【００３８】
電話帳内のエントリは、次の方法で構築して正規のＤＮＳ名にすることができる。すなわち、前記エントリに対応する別名又は名前の最後にピリオド“．”が添付される。次に、サブドメイン名構造が逆方向に横断される。次に、サブドメイン名が別名の最後に添付される。より具体的には、各サブドメイン名は、ピリオド“．”が最後に順次添付される。図３を一例として用いると、電話帳エントリ「息子A」は、ＤＮＳ名“sonA.kids.family&friends.userA.ppbs.com”にすることができる。構築されたＤＮＳ名は、ＤＮＳ問い合わせ又はＤＮＳプロトコルに基づくその他のトランザクションにおいて用いることができる。
【００３９】
ＤＮＳサブドメイン概念及びＤＮＳ別名を用いて上記の方法で系統立てられた電話帳エントリは、インターネット上の標準的ＤＮＳクライアント１１２等のあらゆるＤＮＳイネーブルドクライアントがアクセスできるようにすることができる。この理由は、ＤＮＳプロトコルの下では、ＤＮＳ名は、一定の型のＤＮＳリソースレコードに関するＤＮＳ問い合わせにおいて用いることができるためである。さらに、ＰＰＢＳを取り扱うことが可能になっているＰＰＢＳイネーブルドクライアント１１４も、ＤＮＳインフラへのアクセスが適切に確立されておりさらにあらゆる場所から可能であることに起因してインターネット全体を通じて簡単にＤＮＳ名にアクセスすることも可能である。
【００４０】
以下は、ＤＮＳサブドメイン及び別名の使用を説明する他の例である。この例では名前“Fred Individual”（フレッド・インディビジュアル）及び“Barney Person”（バーニー・パーソン）が用いられる。フレッド及びバーニーは両者ともＰＰＢＳユーザーである。両者とも、ＰＰＢＳユーザーとして、ＰＰＢＳに登録されさらにＰＰＢＳシステムにおけるサブドメインが割り当てられる。より具体的には、フレッド及びバーニーは、（ＤＮＳ用語で表された）サブドメイン“fredindividual.ppbs.com”及び“barneyperson.ppbs.com”がそれぞれ割り当てられる。これらのサブドメインは、ＰＰＢＳシステムにおけるデフォルトドメイン名でもある。これらのデフォルトドメイン名は、各々の電話番号も割り当てられている。バーニーは、自分自身のサブドメインの下位において“友人”と呼ばれるＤＮＳ別名を用いてサブドメインを生成する。次に、バーニーは、自己の「友人」サブドメインの下位において「フレッド」と呼ばれるＤＮＳ別名をさらに生成する。図４は、フレッドに関するバーニーの電話帳がどのようにしてフレッドのレコードと関連づけられるかを示す。（ＤＮＳ名として構築された）フレッドに関するパーニーの電話帳エントリ“fred.friends.barneyperson.ppbs.com”４００は、フレッドのデフォルトドメイン“fredindividual.ppbs.com”４０２に指向され、“fredindividual.ppbs.com”４０２は、フレッドの電話番号“111−555−1212”を含むフレッドのレコード４０４にリンクされる。バーニーがフレッドの電話番号を検索することを希望時には、検索のために“fred.friends.barneyperson.ppbs.com”の問い合わせを構築してＰＰＢＳシステムに渡すことができる。フレッドが自己の電話番号を変更した場合は、新しい電話番号はＰＰＢＳシステムに基づいてフレッドのデフォルトドメインを通じて参照されるため、バーニーは新しい電話番号を検索することができる。
【００４１】
図５は、ＰＰＢＳシステム１００に基づくユーザー（ユーザー１）の電話帳をさらに示す。ユーザー１の電話帳は、ＰＰＢＳデータベース１０８に格納することができる。ユーザー１は、２つのサブドメイン「友人」５００及び「同僚」５０２を生成している。ユーザー１は、３人の友人（友人１  ５０４、友人２  ５０６及び友人３  ５０８）を自己の「友人」サブドメイン５００内に有する。友人１  ５０４及び友人２  ５０６は、両者ともＰＰＢＳシステム１００におけるユーザーである。その結果、これらのユーザーの対応するＰＰＢＳエントリ又はデフォルトドメイン（“user2.ppbs.com”５１４及び“user3.ppbs.com５１６）”を指し示すための別名がユーザー１の電話帳において用いられる。より具体的には、友人１  ５０４及び友人２  ５０６は、ユーザー２及びユーザー３にそれぞれ対応する。ユーザー２及びユーザー３に関するデフォルトドメイン５１４及び５１６は、ユーザー２及びユーザー３のレコード５２２及び５２４にそれぞれリンクされる。友人３  ５０８はＰＰＢＳユーザーではなく、従って、友人３  ５０８に対応する電話番号は、別名を利用せずに別個のレコード５２６として直接ユーザー１に関する電話帳に記入される。
【００４２】
「同僚」サブドメイン５０２においては、ユーザー１は、同僚１  ５１０及び同僚２  ５１２に関する２つのエントリをそれぞれ有する。同僚２  ５１２は、ユーザー４のデフォルトドメイン“user4.ppbs.com”５２０によって表される他のＰＰＢＳユーザーであるユーザー４を参照し、ユーザー４のデフォルトドメイン“user4.ppbs.com”５２０は、ユーザー４のレコード５２８にリンクされる。同僚１  ５１０は、「友人」サブドメイン５００において友人１  ５０４にリンクされたユーザー２のデフォルトドメイン５１４と同一であるユーザー２のデフォルトドメイン“user2.ppbs.com”５１８にリンクされた別名を有する。従って、両別名  友人１  ５０４及び同僚１  ５１０は、ユーザー２のデフォルトドメイン“user2.ppbs.com”を介して、同じＰＰＢＳユーザーであるユーザー２を指し示す。上記のように、ユーザー２のデフォルトドメイン“user2.ppbs.com”は、ユーザー２のレコード５２２にリンクされる。従って、ユーザー２が自己の電話番号を変更した場合は（ユーザー２のレコード５２２の変更を通じて行われる）、「友人」及び「同僚」の両方のサブドメイン５００及び５０２におけるユーザー２に関するユーザー１の別名がユーザー２のデフォルトドメイン“user2.ppbs.com”を介して（ユーザー２のレコード５２２に反映されている）新しい電話番号に自動的にリンクされ、それによってユーザー１がユーザー２の新しい電話番号を検索することを可能にする。
【００４３】
ＰＰＢＳシステム１００は、ＤＮＳにおける「閲覧」の概念も利用及び拡大させる。ＤＮＳにおける閲覧は、一般的には、典型的には組織内部の人及び組織外部の人を含む２つの異なるグループの人が２つの異なる組の名前−ＩＰアドレスマッピングを閲覧可能にするために用いられる。ＰＰＢＳシステム１００は、電話帳データに関する閲覧を拡大させて様々な情報に基づくようにする。該情報は、例えば、ＰＰＢＳシステム状態情報、ネットワークにおけるレコード所有者の存在、時刻、要求者に関連する情報、要求者とレコード所有者の関係、レコード所有者によって提供された情報等を含むことができる。前記情報の一部は、レコード所有者によって指定されたアクセス条件又は方針を含むことができる。情報は、電話帳のデータのどのような閲覧を電話帳エントリの要求者が利用できるようにするかを決定するために用いられる。例えば、レコード所有者が現在外出していることをネットワーク存在情報が示す場合は、（要求者が前記情報を受け取ることが認められていると仮定した場合）ＰＰＢＳシステム１００は、レコード所有者の携帯電話の番号を要求者に転送することを選択することができる。
【００４４】
ＰＰＢＳシステム１００は、異なる閲覧を標準的ＤＮＳクライアント１１２及びＰＰＢＳイネーブルドクライアント１１４に提供することができる。例えば、標準的ＤＮＳクライアント１１２に関しては、該クライアント１１２は、要求が行われた時刻に依存して異なる検索要求結果を受け取る可能性があり、代替として、要求中のクライアントのＩＰアドレス又はドメイン名に基づいた結果である可能性がある。ＰＰＢＳイネーブルドクライアント１１４に関しては、該クライアント１１４は、ＰＰＢＳシステム１００が標準的ＤＮＳクライアント１１２にとって入手可能な閲覧とは異なる閲覧を提供することを可能にする追加情報を提供することができる。例えば、ＰＰＢＳイネーブルドクライアント１１４は、要求者を、要求中であるレコードの所有者の友人として識別することができる。従って、要求者は友人であるため要求は携帯電話の番号を戻すことができる。他の要求者は、同僚であることができ、従って、職場の電話番号を受け取ることしか許容されない。同様に、所有者によって指定されたアクセス条件等のその他の情報を用いていずれの型のデータを要求者に提供すべきかを決定することができる。
【００４５】
上述されるように構築されたＰＰＢＳデータベース１０８は、ユーザーに関連する情報をまとめて統合してリンクさせることを可能にする。該統合及びリンク付けは、データアクセスに関するユーザー方針の変更及び実行の効果的かつ効率的な伝搬を可能にする。例えば、ＰＰＢＳシステムがない状態においては、ユーザーが自己の電話番号を変更した場合は、すべての友人、家族及び仕事上の連絡先に連絡する必要がある。この場合には、連絡漏れが生じて連絡がとれなくなるおそれが非常にしばしばある。他方、ＰＰＢＳシステムは、ユーザーが自分自身のレコードを更新することを可能にし、その後に連絡先全員が実質的にリアルタイムで前記変更を受け取ることになる。ＰＰＢＳシステムは、ユーザーのレコードを入手することを意図している人のみが許容されるようにユーザーが伝搬又はアクセス方針を定義することも可能にする。
【００４６】
図６は、ＰＰＢＳデータベース１０８内の電話帳をどのようにすれば統合してリンクさせることができるかを示す。図６に示されるように、２人の登録されたユーザーであるユーザー１及びユーザー４が電話帳６００及び６０２をそれぞれＰＰＢＳデータベース１０８にアップロードした。電話帳６００及び６０２からの各レコードがＰＰＢＳデータベース１０８内にローディングされるのに応じて、権威ＤＮＳサーバー１０４は、ＰＰＢＳデータベース１０８に既に格納されているレコードを用いてフォーマット検査及びデータ検証を行う。この例においては、ユーザー１からの電話帳エントリ６０４及びユーザー４からの電話帳エントリ６０６は、両方とも、電話番号“１１１−２２２−５５５５”を有する（ユーザー１及びユーザー４の両者によって「友人３」として指定された）同じユーザーを指し示している。権威ＤＮＳサーバー１０４は、ユーザー１、ユーザー４及び友人３の間におけるこの結び付きに注目する。友人３が既にＰＰＢＳの登録ユーザーである場合は、友人３は、自己のレコードに関する一定の配信及びアクセス方針を既に提供している可能性がある。配信及びアクセス方針は、自己のレコードのいずれの部分をいずれのユーザーがアクセス可能にするかを管理することができる。友人３が、その他のユーザーが自分を指し示して自己のレコードにアクセスするのを可能にすることを選択した場合は、権威ＤＮＳサーバー１０４は、ユーザー１及びユーザー４からＥ．１６４レコードを取り除き、ＣＮＡＭＥレコードを用いて（すなわちＤＮＳ別名を用いて）友人３を指し示す。友人３が自己の修正の配信を可能にすると仮定した場合、次回に友人３が自己の電話番号を更新したときに、ユーザー１及びユーザー４が更新事項を入手する。
【００４７】
友人３が現在ＰＰＢＳの登録ユーザーでない場合は、権威ＤＮＳサーバー１０４は、ユーザー１とユーザー４との間の友人３の共有レコードを選択し、友人３を表す１つのレコードを自動的に作成し、ユーザー１及びユーザー４からの電話帳エントリがそのレコードを指し示すようにする。次回にユーザー１及びユーザー４のうちのいずれか１人が友人３に関する自己のエントリを修正したときに、権威ＤＮＳサーバー１０４は、前記エントリの変更をその他のユーザーのために配信するための許可を与えるように前記ユーザーにプロンプトする。ＰＰＢＳシステム１００におけるユーザー間の結び付き又は関係は、一定のプロフィール属性、例えば電話番号、住所、氏名、又は複数の属性の組合せの一意性に基づいて各々のレコードから特定することができる。
【００４８】
ＰＰＢＳシステム１００は、ユーザー間の関係を特定する能力を有することによって、複数の電話帳に基づいて複雑な関係を構築することができる。例えば、ＤＮＳサブドメイン階層を拡大させて「友人の友人」リストを表す連絡先リストを生成することが可能である。これで、ＰＰＢＳのユーザーは、ユーザーと他の個人との間の「疎遠度」又は「分離度」を示すパラメータを含む問い合わせを提供することができる。ＰＰＢＳデータベース１０８内の統合及びリンクされたデータを用いていくつかのコミュニティに基づくユーザーアプリケーションを開発してそれによってユーザーグループ間でのより多くのコミュニケーション方法を提供することができる。
【００４９】
ＰＰＢＳシステム１００は、以下においてさらに詳細に説明される、例えば検索、更新、バックアップ及びダウンロードサービスを含む幾つかの電話帳関連のサービスを提供するように構成することができる。
【００５０】
ＰＰＢＳは、電話帳検索サービスを含むことができる。図７は、システム１００を用いた検索サービスの動作を示す論理流れ図である。ブロック７００において、ユーザーは、ＰＰＢＳイネーブルドクライアント１１４としての携帯電話２００を用いて既存のＰＰＢＳユーザーである「フレッド」の連絡先情報を要求する。ユーザーは、検索サービスを管理し及び名前「フレッド」を提供するように構成されたＰＰＢＳアプリケーション論理２０４を起動させるためにユーザーインタフェース２０６を用いることができる。代替として、ユーザーは、携帯電話２００に常駐するディレクトリリストから名前「フレッド」を選択することができる。ＰＰＢＳイネーブルドクライアント１１４は、名前「フレッド」を適当なＤＮＳ別名“fred.ppbs.com”に変換して要求の一部として組み入れることができる。適切なＤＮＳ別名への名前「フレッド」の変換は、携帯電話２００に常駐する電話帳の階層構造に依存し、変換プロセスが以下において説明される。
【００５１】
ブロック７０２において、要求は、携帯電話２００によってサービスプロバイダＤＮＳサーバー１０６に転送される。
【００５２】
ブロック７０４において、サービスプロバイダＤＮＳサーバー１０６は、誰かがこの特定のレコードを検索することを希望した要求は今回が最初であるかどうかを決定する。最初である場合は、ブロック７０６において、サービスプロバイダＤＮＳサーバー１０６は、ルートサーバー１０２と接触し、ルートサーバー１０２は、ＰＰＢＳドメイン“ppbs.com”をホスト及び管理する責任を有する権威ＤＮＳサーバー１０４を特定する。
【００５３】
ブロック７０８において、サービスプロバイダＤＮＳサーバー１０６は、権威ＤＮＳサーバー１０４に関する情報を入手後に、処理を目的として権威DＮＳサーバー１０４に要求を転送する。
【００５４】
ブロック７１０において、サービスプロバイダＤＮＳサーバー１０６から要求を受け取った時点で、権威ＤＮＳサーバー１０４は、要求を検討して該当する応答を生成する。上述されるように、応答は、例えばＰＰＢＳシステム状態情報、ネットワーク上におけるレコード所有者の存在、時刻、要求者関連情報、要求者とレコード所有者の関係及びレコード所有者によって提供された情報を含む様々な情報に基づいて個別適合化することができる。代替として、権威ＤＮＳサーバー１０４は関連情報をサービスプロバイダＤＮＳサーバー１０６に転送できることに注目すべきである。これで、サービスプロバイダDＮＳサーバー１０６は、応答を個別適合化することができる。他の代替においては、サービスプロバイダDＮＳサーバー１０６は、関連情報をＰＰＢＳイネーブルドクライアント１１４に転送することができる。これで、ＰＰＢＳイネーブルドクライアント１１４は、応答を個別適合化することができる。
【００５５】
ブロック７１２において、応答は、権威ＤＮＳサーバー１０４によってサービスプロバイダＤＮＳサーバー１０６に転送される。
【００５６】
ブロック７１４において、サービスプロバイダＤＮＳサーバー１０６は、ＰＰＢＳイネーブルドクライアント１１４に応答を引き渡す。サービスプロバイダＤＮＳサーバー１０６は、応答をさらにキャッシュに格納し、それによって、のちに同じレコードが同じ又はその他のクライアントによって要求された場合により良い性能及び向上されたサービスの利用可能性を提供することができる。例えば、ブロック７０４において、要求されたレコードがサービスプロバイダＤＮＳサーバー１０６において入手可能である場合は、サービスプロバイダＤＮＳサーバー１０６は、要求されたレコードからの情報を組み入れて応答を系統化してＰＰＢＳイネーブルドクライアント１１４に応答を転送する。
【００５７】
ブロック７１６において、応答を受け取った時点で、ＰＰＢＳイネーブルドクライアント１１４は、関連情報を応答から抽出し、ユーザーインタフェース２０６を介してユーザーに表示する。さらに、ＰＰＢＳイネーブルドクライアント１１４は、のちに取り出すためにメモリ２０８に常駐する電話帳２１４に関連情報を格納することもできる。
【００５８】
ＰＰＢＳは、電話帳更新サービスをさらに含むことができる。上記されるように、権威ＤＮＳサーバー１０４は、様々なユーザーに関するＰＰＢＳドメイン“ppbs.com”のホストになりさらに管理する責任を有する。管理者は、管理インタフェース１１０を介してＰＰＢＳデータベース１０８を修正又は更新することができる。同様に、ＰＰＢＳの登録ユーザーは、ＰＰＢＳデータベース１０８の自己の電話帳エントリ及び関連づけられた情報を、ＰＰＢＳイネーブルドクライアント１１４を用いてその場で暫定的に更新することも可能である。例えば、ＰＰＢＳアプリケーション論理２０４は、標準的なダイナミックＤＮＳ（ＤＤＮＳ）プロトコル（ＲＦＣ２１３６）を用いて電話帳エントリに関する更新情報を送信するように構成されるアプリケーションを含むことができる。次に、すべての更新がＰＰＢＳデータベース１０８における変更に変換される。その後、更新されたＰＰＢＳデータベース１０８のコピーをデーモンプロセスを通じて定期的に生成し、ＤＮＳゾーン転送と呼ばれるプロセスを介してサービスプロバイダＤＮＳサーバー１０６等のその他の関連づけられたサーバーに配信することができる。更新されたＰＰＢＳデータベース１０８のコピーをその他の関連づけられたサーバーに配信する目的の１つは、データをより効率的に取り出すことができるように権威ＤＮＳサーバー１０４の仕事量を均衡化させることである。デーモンプロセス及びＤＮＳゾーン−転送は、当業においてよく知られている。ゾーン−転送は、ＤＮＳプロセスに基づいた標準的な組み込みメカニズムであり、一組のＤＮＳサーバーがそれぞれのデータベースを自動的に及び効率的に同期化することを可能にする。
【００５９】
ＰＰＢＳデータベース１０８に対する更新は、その場で暫定的に配信することもできる。サービスプロバイダＤＮＳサーバー１０６によってキャッシュに格納されたレコードは、ＰＰＢＳドメインの管理者によって設定される対応する生存時間（ＴＴＬ）エントリタグを付けることができる。キャッシュに格納されたコピーの期限が経過していることをＴＴＬが示すレコードに関する要求を誰かがサーバープロバイダＤＮＳサーバー１０６に出した場合は、サービスプロバイダＤＮＳサーバー１０６は、権威ＤＮＳサーバー１０４に接触して要求されたレコードの最新のコピーを入手し、それによって、特定のレコードが要求されたときにＰＰＢＳデータベース１０８に対して行われた変更をその場で配信することを可能にする。
【００６０】
さらに、ＰＰＢＳイネーブルドクライアント１１４と関連づけられたローカル電話帳２１４の更新は、例えば、時刻、ユーザー所在位置、及びネットワーク上での存在を含む一定のトリガーイベントによって開始させることができる。例えば、ＰＰＢＳイネーブルドクライアント１１４がサービスプロバイダＤＮＳサーバー１０６に接触した時点で、サービスプロバイダＤＮＳサーバー１０６は、ローカル電話帳２１４を更新可能にするためにＰＰＢＳイネーブルドクライアント１１４への更新の提供について権威ＤＮＳサーバー１０４と調整することができる。
【００６１】
ＰＰＢＳは、電話帳のバックアップサービス及びダウンロードサービスを含むこともできる。登録ユーザーは、ＰＰＢＳイネーブルドクライアント１１４を用いて、セットアップ中またはその他のユーザーによって開始されたタスク中に自己のローカル電話帳２１４をバックアップするか又は権威ＤＮＳサーバー１０４にアップロードすることができる。登録ユーザーは、ＰＰＢＳイネーブルドクライアント１１４に常駐する自己のローカル電話帳２１４を再同期化する必要がある場合に自己の電話帳全体をＰＰＢＳデータベース１０８からダウンロードすることも可能である。ＰＰＢＳデータベース１０８とＰＰＢＳイネーブルドクライアント１１４との間におけるユーザーの電話帳のアップロード及びダウンロードは、上記のＤＮＳゾーン転送プロセスを用いて容易化することができる。標準的ＤＮＳゾーン−転送は、「マスター」サーバーから「スレーブ」サーバーへの１方向の情報転送を可能にするだけである。しかしながら、ＤＮＳゾーン−転送は、双方向転送を受け入れるように修正することができる。ダウンロード目的のため、ＰＰＢＳイネーブルドクライアント１１４は、自己のローカル電話帳２１４に関する電話帳エントリの最新コピーを表す「ゾーン」を（サービスプロバイダＤＮＳサーバー１０６を介して）権威ＤＮＳサーバー１０４から要求することができる。アップロード目的のため、ＰＰＢＳイネーブルドクライアント１１４は、ローカル電話帳２１４のコピーを表す新しいゾーンを権威ＤＮＳサーバー１０４に送信すること及びＰＰＢＳデータベース１０８内の対応する電話帳を新しいゾーンと交換するように権威ＤＮＳサーバー１０４に要求することができる。
【００６２】
上述されるように、メモリ２０８及び／又は８０６等の機械によって読み取り可能なデバイスは、サブドメイン階層構造において系統立てられたディレクトリエントリを格納するように構成することができる。各ディレクトリエントリは、サブドメイン階層情報を用いて構築された別名と関連づけられ、各別名は、ユーザーと関連づけられたユーザードメインにリンクされる。ユーザードメインは、ユーザーに関する連絡先情報を含むレコードにリンクされる。説明されるようにディレクトリを系統立てる、構成する及び／又は管理することによって、より有効で、好都合で及び／又はユーザーにやさしいネットワークに基づく公共電話ディレクトリサービスが提供される。
【００６３】
本明細書において開示された実施形態に関連して説明されている様々な例示的な論理ブロック、モジュール、回路、要素、及び／又は構成要素は、本明細書において説明されている機能を果たすように設計された汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、その他のプログラミング可能な論理コンポーネント、ディスクリートゲートロジック、ディスクリートトランジスタロジック、ディスクリートハードウェア構成品、又はそのあらゆる組合せ、とともに実装又は実行することができる。汎用プロセッサはマイクロプロセッサであることができるが、代替として、従来のどのようなプロセッサ、コントローラ、マイクロコントローラ、又はステートマシンであってもよい。さらに、プロセッサは、計算コンポーネントの組合せ、例えば、ＤＳＰと、１つのマイクロプロセッサとの組合せ、複数のマイクロプロセッサとの組合せ、ＤＳＰコアと関連する1つ以上のマイクロプロセッサとの組合せ、又はその他のあらゆる該コンフィギュレーションとの組合せ、として実装することもできる。
【００６４】
本明細書において開示された実施形態に関して説明されている方法又はアルゴリズムは、制御論理、プログラミング命令、又はその他の指示の形態で、ハードウェア内において直接具体化させること、プロセッサによって実行されるソフトウェアモジュール内において具体化させること、又はその両方の組合せにおいて具体化させることができ、又は単一のデバイスに内蔵すること又は複数のデバイスにわたって分散することができる。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、取り外し可能なディスク、ＣＤ−ＲＯＭ、又は当業において既知であるその他のあらゆる形態の記憶媒体に常駐することができる。記憶媒体をプロセッサに結合させ、プロセッサが該記憶媒体から情報を読み出すようにすること及び該記憶媒体に情報を書き込むようにすることができる。代替として、記憶媒体は、プロセッサと一体化させることができる。
【００６５】
開示された実施形態に関する上記の説明は、当業者が本発明を製造又は使用できるようにすることを目的とするものである。これらの実施形態に対する様々な修正は、当業者にとって容易に明確になるであろう。さらに、本明細書において定められている一般原理は、本発明の精神及び適用範囲を逸脱しない形でその他の実施形態に対しても適用することができる。以上のように、本発明は、本明細書において示されている実施形態に限定されることを意図するものではなく、請求項に一致する完全な適用範囲が認められるべきである。本明細書において単数形でいずれかの要素に言及している場合は、その旨が特記されないかぎり「１つ及び１つだけ」ではなく「１つ以上」を意味することが意図されている。本開示全体を通じて説明されており、当業者に知られているか又はのちに知られることになる様々な実施形態の要素と同等のすべての構造上および機能上の要素は、本明細書において参照されることによって本明細書に組み入れられており、請求項によって包含されることが意図されている。さらに、本明細書において開示されたいずれのことも、該開示が請求項において明示されているかどうかにかかわらず、一般人専用であることは意図されていない。いずれの請求要素も、「〜のための手段」という表現を用いて明示されていない限り、３５Ｕ．Ｓ．Ｃ．§１１２第6項に基づいて解釈すべきではなく、方法に関する請求の場合は、請求要素は、「〜のためのステップ」という表現を用いて示されている。
【図面の簡単な説明】
【００６６】
【図１】ネットワークに基づく公共電話帳サービスの一実施形態を示す単純化された概略図である。
【図２】公共電話帳サービスによってイネーブルにされるクライアントとして用いることができる携帯電話を示す単純化された概略図である。
【図３】ネットワークに基づく公共電話帳サービスに適用されるＤＮＳサブドメイン概念及び別名の１つの使用例を示す単純化された概略図である。
【図４】ネットワークに基づく公共電話帳サービスに適用されるＤＮＳサブドメイン概念及び別名の他の使用例を示す単純化された概略図である。
【図５】ネットワークに基づく公共電話帳サービス下にあるユーザーの電話帳を示す単純化された概略図である。
【図６】ネットワークに基づく公共電話帳サービス下にある電話帳内における情報の統合及びリンク付けを示す単純化された概略図である。
【図７】電話番号検索サービスの動作を示す論理流れ図である。
【図８】ネットワークに基づく公共電話帳サービス下において用いるためのサーバー構成を示す単純化された概略図である。
【図１】
2008543132.tif 000003
【図２】
2008543132.tif 000004
【図３】
2008543132.tif 000005
【図４】
2008543132.tif 000006
【図５】
2008543132.tif 000007
【図６】
2008543132.tif 000008
【図７】
2008543132.tif 000009
【図８】
2008543132.tif 000010
【国際調査報告】
2008543132.tif 000011