JP4214212B2 - 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法 - Google Patents

送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法 Download PDF

Info

Publication number
JP4214212B2
JP4214212B2 JP2006259904A JP2006259904A JP4214212B2 JP 4214212 B2 JP4214212 B2 JP 4214212B2 JP 2006259904 A JP2006259904 A JP 2006259904A JP 2006259904 A JP2006259904 A JP 2006259904A JP 4214212 B2 JP4214212 B2 JP 4214212B2
Authority
JP
Japan
Prior art keywords
data
update
ldap
broadcast
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2006259904A
Other languages
English (en)
Other versions
JP2006351044A (ja
Inventor
靖明 山岸
善久 権野
和生 原岡
郁彦 西尾
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2006259904A priority Critical patent/JP4214212B2/ja
Publication of JP2006351044A publication Critical patent/JP2006351044A/ja
Application granted granted Critical
Publication of JP4214212B2 publication Critical patent/JP4214212B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法に関し、特に、例えば、ディレクトリサービスを提供するディレクトリサービスシステムなどに用いて好適な送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法に関する。
近年におけるインターネット、イントラネットなどのネットワークの普及に伴い、多くの企業や大学などでは、電子メール（いわゆるE-mail）などを中心とするメッセージング・インフラ（インフラストラクチャ）が構築され、さらに、現在に至っては、その再構築や拡張が行われている状況である。そして、このような状況の中で、電子メールアドレスの管理が問題となっている。
また、電子メールアドレスに限らず、近年、従業員や、学生、ユーザなどの姓名を始めとする顔写真その他のプロファイル、内線番号、携帯電話の電話番号、ＩＰ（Internet Protocol）アドレス、セキュリティ権限といった個人属性から、組織名、ドメイン名、メイリングリストといったグループ属性まで、多くの情報が、ディレクトリサービスとして統合されることが期待されている。
即ち、例えば、企業における各部署の内線番号が印刷された内線番号簿などは、その印刷、製本等が終了した後、従業員に配布されるが、その配布時には、次の部署の異動が行われているようなことが起こりうる。このように、内線番号簿などの印刷物を配布するのでは、その配布がなされる前に、情報が陳腐化することがある。このため、近年では、内線番号簿に限らず、企業内等のあらゆる共有情報の管理に適用することができるオンラインのディレクトリサービスの品質（速さや正確さ）が、そのまま企業のコスト競争力に反映されるとの認識の下、オンラインで提供されるディレクトリサービスの必要性が叫ばれている。
さらに、ディレクトリサービスは、今後、企業内における内線番号管理その他の情報管理にとどまらず、あらゆるマルチメディアコンテンツやサービスの属性を格納した一般大衆向けのサービスナビゲーションシステムの基板環境として発展していくことが予想されるが、このようなディレクトリサービスの規格としては、現在、例えば、Ｘ．５００や、ＬＤＡＰ（Lightweight Directory Access Protocol）などがある。
Ｘ．５００は、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication Standardization Sector）で勧告されているディレクトリサービスの国際標準であり、ディレクトリの概念や、階層構造、サービス、オブジェクトの定義などが規定されている。例えば、NetWare 4.xのＮＤＳ（NetWare Directory Service）は、このＸ．５００に準拠している。
Ｘ．５００は、汎用性の非常に高いディレクトリサービスプロトコルである反面、実装が非常に重くなる仕様となっており、その実装コスト（ソフトウェアの規模や開発コストなど）も高い。このため、これを、インターネット上のＷＷＷ（World Wide Web）ブラウザや、電子メールソフトウェアなどからも簡単に利用することができるように、軽量、簡素化したサービスプロトコルとして、ＬＤＡＰが開発された。なお、ＬＤＡＰは、ＲＦＣ（Request For Comments）１７７７，ＲＦＣ１７７８で規定されている。
石井著，「SuiteSpot 3.5におけるサーバの構築 第５章Directory Server」、OPEN DESIGN、第５巻第５号、ＣＱ出版株式会社、1998-10-01，pp72-91 鈴木著、"ＥＣ・情報流通技術の現状と実際 第５回：パーソナル化情報提供サービス"、ビジネスコミュニケーション、（株）ビジネスコミュニケーション社、１９９８年３月１日、第３５巻、第３号、第９２−９８頁
ＬＤＡＰは、サーバ／クライアント型のモデルで構成されており、ディレクトリ情報を格納するサーバ（ディレクトリサーバ）と、それにアクセスするクライアントとの間のリクエスト／レスポンス型のメッセージ転送プロトコルを定義している。
ところで、ディレクトリサーバで集中管理されるディレクトリ情報の規模が大きくなると、そこにクライアントからのアクセスが集中し、サービスの質（特に、速度）が低下するため、複数のディレクトリサーバによって、ディレクトリ情報を分散管理することが行われる。
この場合、あるディレクトリサーバが管理しているエントリ（ディレクトリ情報の最小管理単位）の複製が、他の１以上のディレクトリサーバに存在することになる。従って、あるディレクトリサーバのエントリの更新（新規に追加される場合、削除される場合、変更される場合を含む）があったときには、他のディレクトリサーバにおいても、その複製を更新する必要がある。そして、同一のエントリを管理している複数のディレクトリサーバにおいて、その同一のエントリの内容が異なるものとならないように、複製の更新は、同期（１のディレクトリサーバが管理しているエントリが更新された場合に、他のディレクトリサーバが管理している、そのエントリの複製の更新を即座に行うこと）をとって行う必要がある。
いまのところ、ＬＤＡＰを採用しているディレクトリサーバ（ＬＤＡＰサーバ）が多地点に分散している場合には、それらの間における複製の更新を、同期をとって行うために、Ｘ．５００のフレームワークが応用されようとしているが、コネクションオリエンテッドな双方向のネットワークを利用することを前提としているため、規模の拡張性に制限が生じることが予想される。
本発明は、このような状況に鑑みてなされたものであり、多数のクライアントに対して、ＬＤＡＰによる、質の良いディレクトリサービスを提供することができるようにするものである。
本発明の一側面の送信装置は、データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置であって、前記報知データを構成する構成手段と、前記報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、前記更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信する送信手段とを備え、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であることを特徴とする。
前記報知データに含まれる前記選択基準情報は、アクセス頻度の高いディレクトリ以外をマスクするためのマスク値であるようにすることができる。
前記データベースの更新を検出する検出手段をさらに備え、前記構成手段は、データベースの更新が検出された場合に、前記報知データを構成するようにすることができる。
前記検出手段は、データベースの更新を指示した装置から、その更新を行った旨のメッセージを受信することにより、データベースの更新を検出するようにすることができる。
前記検出手段は、データベースを周期的に参照することにより、データベースの更新を検出するようにすることができる。
前記検出手段は、データベースの更新を指示した装置との間のやりとりをモニタすることにより、データベースの更新を検出するようにすることができる。
前記送信手段は、前記ＬＤＩＦファイルとされた前記更新データも、前記同報ネットワークを介して送信するようにすることができる。
本発明の一側面の送信方法は、データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信方法であって、前記報知データを構成し、前記報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、前記更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信し、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であることを特徴とする。
本発明の一側面の送信装置および方法においては、データベースの更新を行うための更新データを取得するための取得情報及び取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データが構成され、一斉同報が可能な同報ネットワークを介して送信され、更新データが、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信され、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であることを特徴とする。
本発明の一側面の受信装置は、データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを受信する受信装置であって、一斉同報が可能な同報ネットワークを介して送信されてくる前記報知データを受信する受信手段と、前記報知データに含まれる前記選択基準情報に基づいて、その報知データを取捨選択する取捨選択手段と、前記報知データに含まれる前記取得情報に基づいて、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにされた前記更新データを取得する取得手段と、前記更新データに基づいて、データベースを更新する更新手段とを備え、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であることを特徴とする。
前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するため情報であるようにすることができる。
本発明の一側面の受信方法は、データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを受信する受信方法であって、一斉同報が可能な同報ネットワークを介して送信されてくる前記報知データを受信し、前記報知データに含まれる前記選択基準情報に基づいて、その報知データを取捨選択し、前記報知データに含まれる前記取得情報に基づいて、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにされた前記更新データを取得し、前記更新データに基づいて、データベースを更新し、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であることを特徴とする。
本発明の一側面の受信装置および方法は、データベースの更新を行うための更新データを取得するための取得情報及び取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データであり、一斉同報が可能な同報ネットワークを介して送信されてくる報知データが受信され、報知データに含まれる選択基準情報に基づいて、その報知データが取捨選択され、報知データに含まれる取得情報に基づいて、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにされた更新データが取得され、更新データに基づいて、データベースが更新され、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であることを特徴とする。
本発明の一側面の送受信装置は、データベースの更新を行うための更新データを取得するための取得情報及び取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置と、報知データを受信する受信装置とを備える送受信装置であって、送信装置は、報知データを構成する構成手段と、報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信する送信手段とを有し、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であり、受信装置は、報知データを受信する受信手段と、報知データに含まれる選択基準情報に基づいて、その報知データを取捨選択する取捨選択手段と、報知データに含まれる取得情報に基づいて、ＬＤＡＰのＬＤＩＦファイルにされた更新データを取得する取得手段と、更新データに基づいて、データベースを更新する更新手段とを有することを特徴とする。
本発明の一側面の送受信方法は、データベースの更新を行うための更新データを取得するための取得情報及び取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置と、報知データを受信する受信装置とを備える送受信装置の送受信方法であって、送信装置において、報知データを構成し、報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信し、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であり、受信装置において、報知データを受信し、報知データに含まれる選択基準情報に基づいて、その報知データを取捨選択し、報知データに含まれる取得情報に基づいて、ＬＤＡＰのＬＤＩＦファイルにされた更新データを取得し、更新データに基づいて、データベースを更新することを特徴とする。
本発明の一側面の送受信装置および方法においては、データベースの更新を行うための更新データを取得するための取得情報及び取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置と、報知データを受信する受信装置とが備えられ、報知データに含まれる選択基準情報は、その報知データが有する取得情報によって取得される更新データを識別するための情報であって、更新データを識別するための情報は、ビット列であり、送信装置は、報知データを構成し、報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信し、受信装置において、報知データを受信し、報知データに含まれる選択基準情報に基づいて、その報知データを取捨選択し、報知データに含まれる取得情報に基づいて、ＬＤＡＰのＬＤＩＦファイルにされた更新データを取得し、更新データに基づいて、データベースを更新する。
本発明の送信装置および送信方法によれば、多数のクライアントに対して、ＬＤＡＰによる、質の良いディレクトリサービスを提供することが可能となる。
また、本発明の受信装置および受信方法によれば、多数のクライアントに対して、ＬＤＡＰによる、質の良いディレクトリサービスを提供することが可能となる。
さらに、本発明の送受信装置および送受信方法によれば、多数のクライアントに対して、ＬＤＡＰによる、質の良いディレクトリサービスを提供することが可能となる。
図１は、本発明を適用したディレクトリサービスシステムの一実施の形態の構成例を示している。
このディレクトリサービスシステムでは、ＬＤＡＰによるディレクトリサービスが提供されるようになされている。
即ち、ディレクトリサービスの提供を受ける複数のＬＤＡＰクライアント端末（ＬＤＡＰクライアントとして機能する端末）１は、例えば、ＰＳＴＮ（Public Switched Telephone Network）や、ＩＳＤＮ（Integrated Services Digital Network）、インターネット、ＣＡＴＶ（Cable Television）網などの双方向通信が可能な双方向ネットワーク３を介して、複数のＬＤＡＰサーバ（ＬＤＡＰサーバとして機能するサーバ）２と接続されている。複数のＬＤＡＰサーバ２は、ディレクトリ情報を分散管理しており、従って、複数のＬＤＡＰクライアント端末１それぞれは、双方向ネットワーク３を介して、複数のＬＤＡＰサーバ２のいずれにアクセスしても、基本的に、同一のディレクトリ情報の提供を受けることができるようになされている。
複数のＬＤＡＰサーバ２それぞれは、上述したように、双方向ネットワーク３を介して、複数のＬＤＡＰクライアント端末１に接続されている他、例えば、地上波や衛星回線などの一斉同報が可能な放送ネットワーク４を介して、相互に接続されている。なお、放送ネットワーク４は、ここでは、複数のＬＤＡＰサーバ２のうちの１のＬＤＡＰサーバから、他のＬＤＡＰサーバへの一方向の通信が可能なネットワークとしているが、放送ネットワーク４は、多地点に存在する複数のＬＤＡＰサーバ２に対して、データの一斉同報が可能なものであれば良く、従って、放送ネットワーク４としては、例えば、ＣＡＴＶ網などの一斉同報が可能な双方向のネットワークを採用することも可能である。
次に、以上のように構成されるディレクトリサービスシステムの処理について説明するが、ここでは、説明を簡単にするために、図２に示すように、複数のＬＤＡＰクライアント端末１のうちの２つだけに注目し、その２つのＬＤＡＰクライアント端末を、それぞれ、送信側ＬＤＡＰクライアント端末１１、受信側ＬＤＡＰクライアント端末１２と呼ぶ。さらに、複数のＬＤＡＰサーバ２についても、同様に、そのうちの２つにだけ注目し、その２つのＬＤＡＰサーバを、それぞれ、送信側ＬＤＡＰサーバ２１、受信側ＬＤＡＰサーバ２２と呼ぶ。
以上のように構成されるディレクトリサービスシステムでは、図３に示すように、まず最初に、送信側ＬＤＡＰクライアント端末１１が、双方向ネットワーク３を介して、送信側ＬＤＡＰサーバ２１が管理するディレクトリエントリの更新を要求する（１）。
送信側ＬＤＡＰサーバ２１は、ディレクトリエントリの更新処理その他を行う更新処理部３１、ディレクトリエントリを記憶しているデータベース３２、およびディレクトリエントリの複製についての同期管理を行う送信側複製同期管理モジュール３３（構成手段）（送信手段）（検出手段）を有している。ここで、送信側複製同期管理モジュール３３は、ソフトウェアであり、図示せぬプロセッサによって実行されるようになされている。
送信側ＬＤＡＰサーバ２１では、送信側ＬＤＡＰクライアント端末１１から送信されてくるエントリの更新の要求が、更新処理部３１で受信される。更新処理部３１は、その要求にしたがって、データベース３２のディレクトリエントリを更新する（２）。この更新は、送信側複製同期管理モジュール３３で検出される（３）。
送信側複製同期管理モジュール３３は、ディレクトリエントリの更新を検出すると、その更新を行うためのデータ（更新データ）（以下、適宜、サブジェクトという）を、ＬＤＡＰのＬＤＩＦ（LDAP Data Interchange Format）ファイルの形で生成する。ここで、サブジェクトとしては、更新後のディレクトリエントリそのものを用いることは勿論、その他、例えば、更新後のディレクトリエントリと更新前のディレクトリエントリとの差分などを用いることも可能である。
なお、ＬＤＩＦは、アプリケーションやＯＳ（Operating System）の各種のプラットフォームをまたがってディレクトリ情報を表現するための、テキストで記述されたディレクトリ情報であり、ＬＤＩＦには、標準ＬＤＩＦ（フォーマット）と、修正ＬＤＩＦ（フォーマット）とがある。標準ＬＤＩＦでは、エントリの識別名（ＤＮ（Distinguished Name））、およびエントリの属性名と属性値との組み合わせが列挙される。一方、修正ＬＤＩＦでは、修正オペレーションの種類、それに対応したフォーマット、およびどのエントリのどの部分を修正するかといった情報が列挙される。ＬＤＩＦファイルは、ＬＤＡＰサーバ（ここでは、送信側ＬＤＡＰサーバ２１）に対するコマンドラインツールを用いて生成することができる。
ここで、ＬＤＡＰやＬＤＩＦについては、例えば、「ＬＤＡＰインターネットディレクトリプログラミング」、プレンティスホール（以下、適宜、文献１という）などに、その詳細が記載されている。
さらに、送信側複製同期管理モジュール３３は、生成したサブジェクトを取得するための取得情報を含む、データベース３２（ディレクトリエントリ）の更新を報知するデータ（報知データ）（以下、適宜、イベントという）を生成する。ここで、サブジェクトは、後述するように、放送ネットワーク４を介して送信されるので、そのサブジェクトを取得するための取得情報としては、そのサブジェクトの放送チャンネルや、放送開始時刻、放送時間などを採用することができる。
送信側複製同期管理モジュール３３は、サブジェクトと、そのサブジェクトについての取得情報を含むイベントとを生成（構成）すると、それらを、放送ネットワーク４を介して送信する（４）。
受信側ＬＤＡＰサーバ２２は、送信側ＬＤＡＰサーバ２１が有するディレクトリ情報の複製を有しており、送信側複製同期管理モジュール３３から、放送ネットワーク４を介して送信されてくるイベントおよびサブジェクトを受信し、ディレクトリエントリの更新を行う。
即ち、受信側ＬＤＡＰサーバ２２は、ディレクトリエントリの複製についての同期管理を行う受信側複製同期管理モジュール４１（受信手段）（取得手段）（更新手段）（取捨選択手段）、ディレクトリエントリ（の複製）を記憶しているデータベース４２、および受信側ＬＤＡＰクライアント端末１２からのディレクトリ情報（ディレクトリエントリ）の要求に関する処理を行う照会処理部４３を有している。ここで、受信側複製同期管理モジュール４１も、送信側複製同期管理モジュール３３と同様に、ソフトウェアであり、図示せぬプロセッサによって実行されるようになされている。
送信側ＬＤＡＰサーバ２１からのイベントは、受信側複製同期管理モジュール４１で受信される。受信側複製同期管理モジュール４１は、その受信したイベントから、ディレクトリエントリの更新があったことを認識し、さらに、そこに含まれる取得情報から、その更新を行うためのサブジェクトの取得方法としての、その放送チャンネルや放送開始時刻などを認識する。そして、受信側複製同期管理モジュール４１は、その認識した放送チャンネルで、その放送開始時刻から放送が開始されるサブジェクトとしてのＬＤＩＦファイルを受信（取得）する。
受信側複製同期管理モジュール４１は、以上のようにして、イベントを受信し、さらに、そのイベントに基づいて、サブジェクトを受信すると、そのサブジェクトによって、データベース４２のディレクトリエントリを更新する（５）。
なお、サブジェクトは、上述したように、ＬＤＩＦファイルであるが、このＬＤＩＦファイルを用いてのディレクトリエントリの更新は、ＬＤＡＰサーバ（ここでは、受信側ＬＤＡＰサーバ２２）のコマンドラインツールを利用して行うことができる（この点についての詳細は、例えば、上述の文献１に記載されている）。
その後、受信側ＬＤＡＰクライアント端末１２が、双方向ネットワーク３を介して、受信側ＬＤＡＰサーバ２２にアクセスし、所定のディレクトリエントリの照会を要求すると（６）、その要求は、照会処理部４３で受信される。照会処理部４３は、受信側ＬＤＡＰクライアント端末１２からの要求に応じたディレクトリエントリを、データベース４２から読み出し（７）、受信側ＬＤＡＰクライアント端末１２に対し、双方向ネットワーク３を介して送信する。なお、受信側ＬＤＡＰクライアント端末１２が、双方向ネットワーク３を介して、受信側ＬＤＡＰサーバ２２にアクセスし、所定のディレクトリエントリの照会を要求するためのアプリケーションとしては、例えば、Internat ExpolrerやNetscape Navigator（いずれも商標）等の、いわゆるディレクトリブラウザを用いることができる
。
以上のように、送信側ＬＤＡＰサーバ２１では、送信側複製同期管理モジュール３３から、放送ネットワーク４を介して、イベントと、ＬＤＩＦファイルとされたサブジェクトが送信され、一方、受信側ＬＤＡＰサーバ２２では、受信側複製同期管理モジュール４１において、イベントが受信され、そのイベントに基づき、サブジェクトが取得される。そして、そのサブジェクトに基づいて、ディレクトリエントリが更新される。
即ち、図４に示すように、送信側複製同期管理モジュール３３は、放送ネットワーク４を介して、イベントおよびサブジェクトを送信する。この場合において、イベントは、サブジェクトが放送されるチャンネルや放送開始時刻などの取得情報を含んでおり、従って、イベントは、そのイベントによって更新が報知されるディレクトリエントリを更新するためのサブジェクトを、いわばポインティングしている（サブジェクトの、いわばポインタとしての役割を果たす）。その結果、受信側複製同期管理モジュール４１では、イベントを受信した後、そのイベントに対応するサブジェクトが放送されるチャンネルや放送開始時刻などを認識し、そのサブジェクトを容易に取得することができる。
従って、イベントおよびサブジェクトが、一斉同報可能な放送ネットワーク４を介して送信されるので、受信側ＬＤＡＰクライアント端末１２が増加した場合において、ディレクトリサービスの質を低下させないために、多くの受信側ＬＤＡＰサーバ２２を設けて、大規模な分散データベースの形をとったとしても、ディレクトリエントリの複製の更新を、同期をとって効率的に行うことが可能となる。その結果、多数のユーザに対して、ＬＤＡＰによる、質の良い（特に、レスポンスの速い）ディレクトリサービスを提供することが可能となる。
また、既存のＬＤＡＰディレクトリサービスシステムのアーキテクチャを、分散データベースの基盤として利用し、ディレクトリサーバに、送信側複製同期管理モジュール３３、受信側複製同期管理モジュール４１を実装することで、各ディレクトリサーバにおけるディレクトリエントリの複製の更新を、同期をとって行うことが可能となる。
さらに、ディレクトリエントリの更新を行うためのサブジェクトを、ＬＤＩＦファイルとすることにより、既存のＬＤＡＰディレクトリサービスで蓄積された（あるいは、蓄積されつつある）データをそのまま活用することができる。
なお、サブジェクトは、図３や図４で説明したように、放送ネットワーク４を介して送信する他、図４に示すように、所定のデータベースに記憶させておくようにすることも可能である。この場合、イベントには、サブジェクトが記憶されたデータベースにアクセスするための、例えば、ＵＲＬ（Uniform Resource Locator）などを取得情報として配置し、受信側複製同期管理モジュール４１には、そのようなＵＲＬに基づいて、サブジェクトを取得させるようにすることができる。
次に、イベントのフォーマットとしては、例えば、本件発明者が先に提案した特願平１０−１１４７３０号に開示されているものなどを採用することができる。
即ち、イベントは、それを、変数eventMessegeで表すものとして、例えば、次のようなフォーマットとすることができる。
eventMessage{
formatVersion,
filteringMasks,
timeToLive,
objectIdentifier,
objectVersion,
subjectLinks
}
イベントeventMessageにおいて、フォーマットバージョンformatVersionは、そのイベントeventMessageのフォーマットのバージョンを表す。即ち、イベントeventMessageのフォーマットを、将来拡張することを考えると、受信側複製同期管理モジュール４１において、イベントeventMessageを処理するには、そのフォーマットを認識する必要がある。フォーマットバージョンformatVersionは、イベントeventMessageのフォーマットを特定するための情報（フォーマット情報）で、受信側複製同期管理モジュール４１では、このフォーマットバージョンformatVersionによって、受信したイベントeventMessageのフォーマットが認識されて処理される。
フィルタマスクfilteringMasksは、受信側複製同期管理モジュール４１において、そのイベントeventMessageを取捨選択するための基準として用いることのできる情報（選択基準情報）で、そこには、例えば、イベントeventMessageが更新を報知するディレクトリエントリの親ディレクトリを識別する識別名として用いられるＤＮ（Distinguished Name）を表す、後述するようなビット列が配置される。ここで、ＤＮは、ディレクトリエントリの階層の位置を特定するための識別名で、その構成要素は、相対識別名（ＲＤＮ（Relative Distinguished Name））と呼ばれる。なお、ＤＮの詳細については、例えば、上述の文献１に記載されている。
受信側複製同期管理モジュール４１では、受信したイベントeventMessageが、そこに配置されているフィルタマスクfilteringMasksに基づいて取捨選択される。即ち、受信側複製同期管理モジュール４１には、イベントeventMessageの取捨選択に用いるＤＮがあらかじめ設定されており（このＤＮを、以下、適宜、設定ＤＮという）、受信側複製同期管理モジュール４１は、その設定ＤＮに一致するフィルタマスクfilteringMasksを有するイベントeventMessageのみを選択し、他のイベントeventMessageは破棄する。そして、受信側複製同期管理モジュール４１は、選択したイベントeventMessageに基づいて、サブジェクトを取得し、ディレクトリエントリを更新する。
ここで、設定ＤＮとしては、例えば、受信側ＬＤＡＰクライアント端末１２を操作することにより、受信側ＬＤＡＰクライアント端末１２のユーザが希望する値を設定することができる。また、受信側ＬＤＡＰサーバ２２において、受信側ＬＤＡＰクライアント端末１２からのアクセス履歴を管理しておき、そのアクセス履歴に基づいて、受信側ＬＤＡＰクライアント端末１２のユーザの嗜好を判定し、その嗜好に合致するような値を、設定ＤＮとして設定することができる。この場合、受信側ＬＤＡＰサーバ２２では、送信側ＬＤＡＰサーバ２１において更新のあったディレクトリエントリのうち、受信側ＬＤＡＰクライアント端末１２のユーザの嗜好にあったもののみの更新が反映されるので、受信側ＬＤＡＰサーバ２２におけるディレクトリエントリの格納コストを低減することが可能となり、その結果、データベース４２の有効活用を図ることが可能となる。
次に、イベントeventMessageにおける生存時間（期限情報）timeToLiveは、イベントeventMessageの有効期限を表す。即ち、受信側複製同期管理モジュール４１においては、放送ネットワーク４を介して送信されてくるイベントeventMessageが受信されるが、その受信されたイベントeventMessageが、即座に処理されるとは限らない。このため、イベントeventMessageを用いて、サブジェクトを取得しようとするときには、そのイベントeventMessageが、既に、使用不能の状態になっていることがある。
即ち、例えば、イベントeventMessageに、サブジェクトの放送開始時刻などが配置されている場合において、その放送開始時刻を過ぎてから、そのサブジェクトの受信を行おうとしても、そのサブジェクトの放送が、既に終了していることがある。この場合、受信側複製同期管理モジュール４１において、そのサブジェクトを受信することはできないから、そのような使用不能のイベントeventMessageを保持しておくのは効率的でない。
そこで、生存時間timeToLiveには、いわば、イベントeventMessageの鮮度を表す指標として、そのイベントeventMessageを廃棄すべき時刻が配置される。
この場合、受信側複製同期管理モジュール４１では、イベントに基づいてサブジェクトを取得しようとしている時刻が、生存時間timeToLiveに配置された時刻を経過しているときには、そのイベントは使用不能であるとして廃棄される。
次に、イベントeventMessageにおけるオブジェクト識別子objectIdentifierは、そのイベントeventMessageが更新を報知するディレクトリエントリ（オブジェクト）が存在する位置に関する情報（位置情報）で、受信側複製同期管理モジュール４１では、このオブジェクト識別子objectIdentifierに基づいて、更新されたディレクトリエントリが特定、認識される。なお、オブジェクト識別子objectIdentifierには、例えば、更新されたディレクトリエントリのＤＮなどが配置される。
イベントeventMessageにおけるオブジェクトバージョンobjectVersionは、そのイベントeventMessageに基づいて取得されるサブジェクトによって更新されるディレクトリエントリの、その更新後のバージョンを表す。オブジェクトバージョンobjectVersionとしては、例えば、ディレクトリエントリが更新される度にインクリメントされる整数値などを用いることができる。
イベントeventMessageにおけるサブジェクトリンクsubjectLinksは、そのイベントeventMessageに基づいて取得されるサブジェクト（オブジェクト識別子objectIdentifierによって特定されるディレクトリエントリを更新するためのサブジェクト）を取得する取得情報に相当するもので、そこには、例えば、サブジェクトとしてのＬＤＩＦファイルが格納されるオブジェクトカルーセルの名前などが配置される。ここで、オブジェクトカルーセルとは、オンエアのストリーム上のデータに対して、あたかも、あるファイルシステム上のファイルにアクセスしているかのように見せるデータの伝送方式を意味する。
次に、上述のように、イベントeventMessageにおけるフィルタマスクfilteringMasksとして、ＤＮを表すビット列を採用することで、送信側ＬＤＡＰサーバ２１において更新のあったディレクトリエントリのうち、例えば、受信側ＬＤＡＰクライアント端末１２によって頻繁にアクセスされるものについての更新を、受信側ＬＤＡＰサーバ２２において優先的に行うことが可能となる。
即ち、例えば、いま、送信側ＬＤＡＰサーバ２１において、図５（Ａ）に示すようなディレクトリ情報が記憶されているとする。ここで、図５（Ａ）では、ルートディレクトリが、２つの下位（子）ディレクトリＤ1およびＤ2を有しており、ディレクトリＤ1は、下位ディレクトリＤ11を有している。そして、ディレクトリＤ11は、３つのディレクトリエントリを有している。また、ディレクトリＤ2は、下位ディレクトリＤ21を有しており、下位ディレクトリＤ21は、２つの下位ディレクトリＤ211およびＤ212を有している。そして、ディレクトリＤ211またはＤ212は、それぞれ２つのディレクトリエントリを有している。なお、図５においては（後述する図６においても同様）、ディレクトリ（ディレクトリノード）は、○印で、ディレクトリエントリは●印で、それぞれ示してある。
この場合、受信側ＬＤＡＰクライアント端末１２によって、ディレクトリＤ11が有する３つのディレクトリエントリへのアクセスが頻繁に行われていれば、受信側ＬＤＡＰサーバ２１では、図５（Ｂ）に示すように、図５（Ａ）のディレクトリ情報のうち、ルートディレクトリ、ディレクトリＤ1，Ｄ11、およびディレクトリＤ11が有するディレクトリエントリの部分が優先的に更新される。一方、受信側ＬＤＡＰクライアント端末１２によって、ディレクトリＤ211が有する２つのディレクトリエントリ、およびディレクトリエントリＤ212が有する２つのディレクトリエントリへのアクセスが頻繁に行われていれば、受信側ＬＤＡＰサーバ２１では、図５（Ｃ）に示すように、図５（Ａ）のディレクトリ情報のうち、ルートディレクトリ、ディレクトリＤ2，Ｄ21，Ｄ211，Ｄ212、並びにディレクトリＤ211が有する２つのディレクトリエントリ、およびディレクトリエントリＤ212が有する２つのディレクトリエントリの部分が優先的に更新される。
このような優先的な更新は、ディレクトリに、例えば、次のようなビットアサインを行うことで実現することが可能である。
即ち、例えば、いま、図６に示すようなディレクトリ情報（構造）を考える。ここで、図６においては、ルートディレクトリ（root）は、２つの下位ディレクトリａおよびｂを有し、ディレクトリａは、３つの下位ディレクトリａａ，ａｂ，ａｃを有している。そして、ディレクトリａａは、２つのディレクトリエントリを、ディレクトリａｂは、１のディレクトリエントリを、ディレクトリａｃは、１のディレクトリエントリを、それぞれ有している。また、ディレクトリｂは、２つの下位ディレクトリｂａおよびｂｂを有しており、ディレクトリｂａは、２のディレクトリエントリを、ディレクトリｂｂは、３のディレクトリエントリを、それぞれ有している。
そして、図６においては、ルートディレクトリが有する２つのディレクトリａまたはｂそれぞれに、例えば、０または１が割り当てられている。また、ディレクトリａが有する３つのディレクトリａａ，ａｂ，ａｃそれぞれに、例えば、００，０１，１０が割り当てられている。さらに、ディレクトリｂが有する２つのディレクトリｂａまたはｂｂそれぞれに、例えば、０または１が割り当てられている。
この場合、図６のディレクトリ構造において、各ディレクトリは、ルートディレクトリから下位階層への最短のパスを考えたときに通るディレクトリに割り当てられたビット（またはビット列）を、上位ビットから順次配置した、例えば、１バイト（８ビット）のビット列で表される。
即ち、ルートディレクトリの下位階層のディレクトリａは、「0*******」で、ディレクトリａの下位階層のディレクトリａａ（以下、適宜、ａ．ａａと記述する）は、「000*****」で、ディレクトリａの下位階層のディレクトリａｂ（以下、適宜、ａ．ａｂと記述する）は、「001*****」で、ディレクトリａの下位階層のディレクトリａｃ（以下、適宜、ａ．ａｃと記述する）は、「010*****」で、それぞれ表される。また、ルートディレクトリの下位階層のディレクトリｂは、「1*******」で、ディレクトリｂの下位階層のディレクトリｂａ（以下、適宜、ｂ．ｂａと記述する）は、「10******」で、ディレクトリｂの下位階層のディレクトリｂｂ（以下、適宜、ｂ．ｂｂと記述する）は、「11******」で、それぞれ表される。なお、*印は、ドントケア（don't care）を表す。
フィルタマスクfilteringMasksには、それが配置されているイベントが更新を報知するディレクトリエントリが属しているディレクトリを表すビット列が配置される。従って、ここでは、フィルタマスクfilteringMasksは、１バイトのワードである。
一方、受信側複製同期管理モジュール４１では、フィルタマスクfilteringMasksによってイベントをフィルタリングするためのマスク値が、設定ＤＮとして設定される。即ち、例えば、ディレクトリｂ．ｂｂが有する３つのディレクトリエントリに対する、受信側ＬＤＡＰクライアント端末１２からのアクセス頻度が高い場合には、そのディレクトリｂ．ｂｂ以外をマスクするためのマスク値「11xxxxxx」が、設定ＤＮとして設定される。
この場合、受信側複製同期管理モジュール４１では、設定ＤＮのうちのｘの部分は無視され、１または０となっている部分が一致するフィルタマスクfilteringMasksを有するイベントだけが選択される。従って、設定ＤＮが、上述のように「11xxxxxx」である場合には、上位２ビットがいずれも１のフィルタマスクfilteringMasksが配置されたイベントだけ、即ち、ここでは、ディレクトリｂ．ｂｂを表すビット列がフィルタマスクfilteringMasks配置されているイベントだけが選択される。その結果、アクセス頻度の高い、ディレクトリｂ．ｂｂが有する３つのディレクトリエントリが、優先的に更新される。
また、例えば、ディレクトリａ．ａｂが有する１のディレクトリエントリに対するアクセス頻度が高い場合には、そのディレクトリａ．ａｂ以外をマスクするためのマスク値「001xxxxx」が、設定ＤＮとして設定される。
この場合、受信側複製同期管理モジュール４１では、上位３ビットそれぞれが０，０，１となっているフィルタマスクfilteringMasksが配置されたイベントだけ、即ち、ここでは、ディレクトリａ．ａｂを表すビット列がフィルタマスクfilteringMasks配置されているイベントだけが選択される。その結果、アクセス頻度の高い、ディレクトリａ．ａｂが有するディレクトリエントリが、優先的に更新される。
また、例えば、ディレクトリａ．ａａが有するディレクトリエントリ、ディレクトリａ．ａｂが有するディレクトリエントリ、およびディレクトリａ．ａｃが有するディレクトリエントリ、即ち、ディレクトリａを共通のディレクトリとして有するディレクトリエントリに対するアクセス頻度が高い場合には、そのディレクトリａ以外をマスクするためのマスク値「0xxxxxxx」が、設定ＤＮとして設定される。
この場合、受信側複製同期管理モジュール４１では、最上位ビットが０となっているフィルタマスクfilteringMasksが配置されたイベントだけ、即ち、ここでは、ディレクトリａ，ａ．ａａ，ａ．ａｂ，ａ．ａｃのうちのいずれかを表すビット列がフィルタマスクfilteringMasks配置されているイベントだけが選択される。その結果、やはり、アクセス頻度の高い部分が、優先的に更新される。
次に、図３において、送信側複製同期管理モジュール３３には、ディレクトリエントリの更新がなされたことを検出させるようにしたが、この検出は、例えば、次のような第１乃至第３の検出方法のうちのいずれかによって行うことが可能である。
第１の検出方法では、図７に示すように、送信側ＬＤＡＰクライアント端末１１から、送信側複製同期管理モジュール２１に対して、更新トランザクションか完了したことを通知してもらうようにする。
即ち、送信側ＬＤＡＰクライアント端末１１は、上述したように、送信側ＬＤＡＰサーバ２１の更新処理部３１に対して、ディレクトリエントリの更新を要求するが、この要求によって、送信側ＬＤＡＰクライアント端末１１と更新処理部３１との間では、ディレクトリエントリの更新のためのトランザクション（更新トランザクション）が行われる。第１の検出方法では、この更新トランザクションの完了後に、その完了を、送信側ＬＤＡＰクライアント端末１１から通知（送信）してもらうことにより、送信側複製同期管理モジュール３３において、ディレクトリエントリの更新を検出する。
ここで、第１の検出方法によれば、送信側複製同期管理モジュール３３への実装は容易であるが、送信側ＬＤＡＰクライアント端末１１の実装を、更新トランザクションの完了を知らせるようにしなければならないため、送信側ＬＤＡＰクライアント端末１１において、上述したような既存のディレクトリブラウザを使用することは困難となる。従って、専用のブラウザを作成し、送信側ＬＤＡＰクライアント端末１１に実装する必要がある。
次に、第２の検出方法では、図８に示すように、送信側複製同期管理モジュール３３に、例えば、周期的に、データベース３３に対してアクセスさせ、そのディレクトリエントリの階層構造（ディレクトリの構造）を取得させる。そして、送信側複製同期管理モジュール３３に、今回取得したディレクトリエントリの階層構造と、前回取得したディレクトリエントリの階層構造とを比較させ、その比較結果に基づいて、ディレクトリエントリの更新があったかどうかを検出させる。
ここで、第２の検出方法は、送信側ＬＤＡＰクライアント端末１１の実装に関係なく実現可能であるため、送信側ＬＤＡＰクライアント端末１１としては、既存の（普及している）ＬＤＡＰクライアントを利用することができる。
次に、第３の検出方法では、図９に示すように、送信側複製同期管理モジュール３３に、更新処理部３１から送信側ＬＤＡＰクライアント端末１１に送信される更新トランザクションの終結のメッセージを検出させるようにする。
即ち、送信側ＬＤＡＰクライアント端末１１と、更新処理部３１との間において、更新トランザクションは、ここでは、ＬＤＡＰのプロトコルデータユニットをやりとりすることで行われる。そこで、送信側複製同期管理モジュール３３に、このやりとりをトレース（モニタ）させ、更新トランザクションの終結のメッセージを検出させることによって、ディレクトリエントリの更新があったことを検出させることができる。
ここで、第３の検出方法は、検出精度が高く、さらに、第２の検出方法と同様に、送信側ＬＤＡＰクライアント端末１１の実装に関係なく行うことができるので、送信側ＬＤＡＰクライアント端末１１としては、既存のＬＤＡＰクライアントを利用することができる。しかしながら、ＬＤＡＰのプロトコルデータユニットをトレースするために、ポートを介してのメッセージトレーサ／ネットワークインターフェイスでのパケットモニタ等のＬＤＡＰサーバが稼働するマシンにおけるプロセスとして実装する必要があるので、この制約により、一般的な更新の検出のためのモニタリング（例えば、あらゆるＬＤＡＰサーバにおける更新の検出をリモートでモニタするようなこと）の実装には不向きである。
なお、ディレクトリエントリが更新されたかどうかは、上述の３つの検出方法以外の方法によって検出することも可能である。但し、上述の第１乃至第３の検出方法については、基本的に、既存のＬＤＡＰサーバの実装部分は変更することなく実装することが可能である。
以上、本発明を適用したディレクトリサービスシステムについて説明したが、本発明は、その他、分散データベースにおける多数のデータベースへのデータの配信を行う場合や、ＩＰ（Internet Protocol）マルチキャストによりデータを配信する場合、データを不特定多数に配信する場合に用いることが可能である。
本発明を適用したディレクトリサービスシステムの一実施の形態の構成例を示す図である。 図１のディレクトリサービスシステムの処理を説明するための図である。 図１のディレクトリサービスシステムの処理を説明するための図である。 イベントおよびサブジェクトの送信を説明するための図である。 ディレクトリエントリの優先的な更新について説明するための図である。 ディレクトリに対するビットアサインを説明するための図である。 ディレクトリの更新を検出する第１の検出方法を説明するための図である。 ディレクトリの更新を検出する第２の検出方法を説明するための図である。 ディレクトリの更新を検出する第３の検出方法を説明するための図である。
符号の説明
１ ＬＤＡＰクライアント端末， ２ ＬＤＡＰサーバ， ３ 双方向ネットワーク， ４ 放送ネットワーク， １１ 送信側ＬＤＡＰクライアント端末， １２ 受信側ＬＤＡＰクライアント端末， ２１ 送信側ＬＤＡＰサーバ， ２２ 受信側ＬＤＡＰサーバ， ３１ 更新処理部， ３２ データベース， ３３ 送信側複製同期管理モジュール， ４１ 受信側複製同期管理モジュール， ４２ データベース， ４３ 照会処理部

Claims (13)

  1. データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置であって、
    前記報知データを構成する構成手段と、
    前記報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、前記更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信する送信手段と
    を備え、
    前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するための情報であって、
    前記更新データを識別するための情報は、ビット列である
    ことを特徴とする送信装置。
  2. 前記報知データに含まれる前記選択基準情報は、アクセス頻度の高いディレクトリ以外をマスクするためのマスク値である
    ことを特徴とする請求項１に記載の送信装置。
  3. データベースの更新を検出する検出手段をさらに備え、
    前記構成手段は、データベースの更新が検出された場合に、前記報知データを構成する
    ことを特徴とする請求項１に記載の送信装置。
  4. 前記検出手段は、データベースの更新を指示した装置から、その更新を行った旨のメッセージを受信することにより、データベースの更新を検出する
    ことを特徴とする請求項３に記載の送信装置。
  5. 前記検出手段は、データベースを周期的に参照することにより、データベースの更新を検出する
    ことを特徴とする請求項３に記載の送信装置。
  6. 前記検出手段は、データベースの更新を指示した装置との間のやりとりをモニタすることにより、データベースの更新を検出する
    ことを特徴とする請求項３に記載の送信装置。
  7. 前記送信手段は、前記ＬＤＩＦファイルとされた前記更新データも、前記同報ネットワークを介して送信する
    ことを特徴とする請求項１に記載の送信装置。
  8. データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信方法であって、
    前記報知データを構成し、
    前記報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、前記更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信し、
    前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するための情報であって、
    前記更新データを識別するための情報は、ビット列である
    ことを特徴とする送信方法。
  9. データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを受信する受信装置であって、
    一斉同報が可能な同報ネットワークを介して送信されてくる前記報知データを受信する受信手段と、
    前記報知データに含まれる前記選択基準情報に基づいて、その報知データを取捨選択する取捨選択手段と、
    前記報知データに含まれる前記取得情報に基づいて、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにされた前記更新データを取得する取得手段と、
    前記更新データに基づいて、データベースを更新する更新手段と
    を備え、
    前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するための情報であって、
    前記更新データを識別するための情報は、ビット列である
    ことを特徴とする受信装置。
  10. 前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するため情報である
    ことを特徴とする請求項９に記載の受信装置。
  11. データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを受信する受信方法であって、
    一斉同報が可能な同報ネットワークを介して送信されてくる前記報知データを受信し、
    前記報知データに含まれる前記選択基準情報に基づいて、その報知データを取捨選択し、
    前記報知データに含まれる前記取得情報に基づいて、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにされた前記更新データを取得し、
    前記更新データに基づいて、データベースを更新し、
    前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するための情報であって、
    前記更新データを識別するための情報は、ビット列である
    ことを特徴とする受信方法。
  12. データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置と、
    前記報知データを受信する受信装置と
    を備える送受信装置であって、
    前記送信装置は、
    前記報知データを構成する構成手段と、
    前記報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、前記更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信する送信手段と
    を有し、
    前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するための情報であって、
    前記更新データを識別するための情報は、ビット列であり、
    前記受信装置は、
    前記報知データを受信する受信手段と、
    前記報知データに含まれる前記選択基準情報に基づいて、その報知データを取捨選択する取捨選択手段と、
    前記報知データに含まれる前記取得情報に基づいて、ＬＤＡＰのＬＤＩＦファイルにされた前記更新データを取得する取得手段と、
    前記更新データに基づいて、データベースを更新する更新手段と
    を有する
    ことを特徴とする送受信装置。
  13. データベースの更新を行うための更新データを取得するための取得情報及び前記取得情報を取捨選択するための基準として用いることのできる選択基準情報を含む、データベースの更新を報知する報知データを送信する送信装置と、
    前記報知データを受信する受信装置と
    を備える送受信装置の送受信方法であって、
    前記送信装置において、
    前記報知データを構成し、
    前記報知データを、一斉同報が可能な同報ネットワークを介して送信するとともに、前記更新データを、ＬＤＡＰ（Lightweight Directory Access Protocol）のＬＤＩＦ（LDAP Data Interchange Format）ファイルにして送信し
    前記報知データに含まれる前記選択基準情報は、その報知データが有する取得情報によって取得される前記更新データを識別するための情報であって、
    前記更新データを識別するための情報は、ビット列であり、
    前記受信装置において、
    前記報知データを受信し、
    前記報知データに含まれる前記選択基準情報に基づいて、その報知データを取捨選択し、
    前記報知データに含まれる前記取得情報に基づいて、ＬＤＡＰのＬＤＩＦファイルにされた前記更新データを取得し、
    前記更新データに基づいて、データベースを更新する
    ことを特徴とする送受信方法。
JP2006259904A 2006-09-26 2006-09-26 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法 Expired - Lifetime JP4214212B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006259904A JP4214212B2 (ja) 2006-09-26 2006-09-26 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006259904A JP4214212B2 (ja) 2006-09-26 2006-09-26 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP10277353A Division JP2000112802A (ja) 1998-09-30 1998-09-30 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法

Publications (2)

Publication Number Publication Date
JP2006351044A JP2006351044A (ja) 2006-12-28
JP4214212B2 true JP4214212B2 (ja) 2009-01-28

Family

ID=37646737

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006259904A Expired - Lifetime JP4214212B2 (ja) 2006-09-26 2006-09-26 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法

Country Status (1)

Country Link
JP (1) JP4214212B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5121234B2 (ja) * 2007-01-12 2013-01-16 キヤノン株式会社 データ管理装置および方法、ならびにプログラム
WO2009121417A1 (en) 2008-04-04 2009-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Method and device for access to a directory

Also Published As

Publication number Publication date
JP2006351044A (ja) 2006-12-28

Similar Documents

Publication Publication Date Title
US7975043B2 (en) Method and apparatus for monitoring a network
EP1517508B1 (en) Method and apparatus for representing and applying network topological data
US6253243B1 (en) Automated trap control for a distributed network management system
TW435029B (en) Method and system for optimizing routing of data packets
US6915309B1 (en) Automatically generating replication topology information for use by a directory service
KR100716167B1 (ko) 네트워크 관리 시스템 및 방법
CN101222550B (zh) 通过高速缓冲存储和对等查找确定电话号码和ip地址的配对
US20110295989A1 (en) Network system, network management device and gateway device
US20070247669A1 (en) Fax server, method for managing fax servers, and computer program product
JP2011096045A (ja) 計算機、計算機システム、及び、アプリケーション実行方法
JPH1063598A (ja) マルチキャスト通信方法及びマルチキャスト通信システムと、マルチキャスト通信用サーバ
JP4571937B2 (ja) アクセスシステム及びアクセス方法
CN101282249B (zh) 分布式互联网测量服务器自动注册与管理方法
JP4214212B2 (ja) 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法
CN101159597A (zh) 获取软件配置信息的方法、系统及相关设备
WO2016191180A1 (en) Local object instance discovery for metric collection on network elements
US20080320015A1 (en) Network Search System and Components Thereof
EP1148676A2 (en) Transmitting and/or receiving apparatus, methods and systems using public key certificates
JP2000112802A (ja) 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法
JP2001216184A (ja) 送信装置、受信装置、送受信システム、送信方法、および受信方法
JP3490642B2 (ja) 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法
JP2004072796A (ja) 送信装置および送信方法、受信装置および受信方法、並びに送受信装置および送受信方法
JP4398042B2 (ja) 送信装置、受信装置、送受信装置、送信方法および受信方法
CN1520120A (zh) 通信设备
JP3559471B2 (ja) 設定情報サーバ装置、利用者計算機及び設定情報配送方法

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20061013

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080603

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080729

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20081002

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20081008

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111114

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121114

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121114

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131114

Year of fee payment: 5

EXPY Cancellation because of completion of term