JP2001308841A - 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法 - Google Patents

送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法

Info

Publication number
JP2001308841A
JP2001308841A JP2000120940A JP2000120940A JP2001308841A JP 2001308841 A JP2001308841 A JP 2001308841A JP 2000120940 A JP2000120940 A JP 2000120940A JP 2000120940 A JP2000120940 A JP 2000120940A JP 2001308841 A JP2001308841 A JP 2001308841A
Authority
JP
Japan
Prior art keywords
information
entry
directory
public key
container
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.)
Pending
Application number
JP2000120940A
Other languages
English (en)
Inventor
Yasuaki Yamagishi
靖明 山岸
Yoshihisa Gonno
善久 権野
Ikuhiko Nishio
郁彦 西尾
Toshihiro Tsunoda
智弘 角田
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.)
Sony Corp
Original Assignee
Sony Corp
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 Sony Corp filed Critical Sony Corp
Priority to JP2000120940A priority Critical patent/JP2001308841A/ja
Priority to EP01303524A priority patent/EP1148676A3/en
Priority to US09/839,872 priority patent/US7136998B2/en
Publication of JP2001308841A publication Critical patent/JP2001308841A/ja
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0464Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/04Masking or blinding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60Digital content management, e.g. content distribution
    • H04L2209/601Broadcast encryption

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

(57)【要約】 (修正有) 【課題】 PKI(公開鍵基盤)ディレクトリサーバか
らPKIディレクトリクライアントへ公開鍵証明書の失
効情報の通知を、効率よく行う。 【解決手段】 認証局構造における認証局CA_0、C
A_1、CA_2がディレクトリツリーにおけるコンテ
ナエントリ100、101および102にそれぞれ対応
付けられる。認証局構造におけるエンドエンティティE
E_1、EE_2およびEE_3がリーフエントリ11
0、111および112にそれぞれ対応付けられる。各
エントリは公開鍵証明書およびシリアル番号を持つ。新
たに発行された証明書とそのシリアル番号とをエントリ
に格納する。所定の時間経過後に、当該証明書をあるU
RLに置くと共に、エントリに格納された証明書をUR
L情報と置換える。送信側から送信されたディレクトリ
構造は、受信側のフィルタリングマスクにより選択的に
受信され、受信側のディレクトリを変更する。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】この発明は、この発明は、階
層構造を有すると共に、ネットワーク上に分散されて配
置されたデータを一方向的に配信する系において、分散
された公開鍵ディレクトリエントリの複製の更新を行う
ような送信装置および送信方法、受信装置および受信方
法、ならびに、送受信システムおよび送受信方法に関す
る。
【0002】
【従来の技術】データの配信方法としては、種々の方法
が提案されており、例えば、現在のインターネット上に
おいては、http(Hyper Text Transfer Protocol)の
ような、TCP/IP(Transmission Control Protocol
/Internet Protocol) を基本とするプロトコルが採用さ
れている。TCP/IPでは、データの配信を受ける受
信側からデータの送信側に対して発呼が行われ、さら
に、データの送受信を行う毎に、送信側と受信側との間
でコネクションが確立されるようになっている。そのた
め、信頼性の高いデータの配信を行うことができる。
【0003】その反面で、送信側やネットワークの負荷
が大きくなり、効率的なデータ配信を行うことが困難に
なる場合があった。すなわち、データの提供を受ける端
末が増加し、データを提供するサーバへのアクセスが集
中すると、サーバやネットワークに多大な負荷がかか
り、データを要求しても、そのデータを得るまでに多大
な時間を要することがあった。
【0004】そこで、データの配信を、例えば、広い地
域にわたって一斉同報が可能な衛星回線やCATV(Cab
le Television)回線、実用化が予定されている地上波デ
ィジタル放送などを用いて行う方法が提案されている。
この場合、端末の増加によって、サーバやネットワーク
に対する負荷が影響を受けることがない。
【0005】一方、近年では、インターネットなどディ
ジタル通信ネットワークの発達により、ネットワーク上
に膨大なデータが蓄積されるようになり、この膨大なデ
ータを効率的に利用することが求められている。そこ
で、ネットワーク上に分散されて存在するデータを階層
的に管理し、ユーザに提供する、ディレクトリサービス
が注目を集めている。ディレクトリサービスを利用する
ことで、ユーザは、ネットワーク上に分散して存在する
情報の中から、自分が必要な情報を素早く見つけ出し、
アクセスすることが可能になる。
【0006】ディレクトリサービスは、例えば、国際標
準であるOSI(Open Systems Interconnection)などに
よって、X.500シリーズとして規定されている。
X.500によれば、ディレクトリについて、開放型シ
ステムの集合体であり、各開放型システムが協調して、
現実世界のオブジェクトの集合に関する情報の、論理的
なデータベースを持つと定義されている。
【0007】X.500によるディレクトリサービスに
よれば、ディレクトリが擁する情報の検索や閲覧を行う
ことができる。また、例えば電話帳に例えられる一覧や
ユーザの認証などもディレクトリサービスで提供され
る。さらに、ディレクトリサービスでは、特に人間のユ
ーザにとって覚え易く、推測ならびに認識し易いよう
に、オブジェクトの名前が付けられる。
【0008】なお、このX.500によるディレクトリ
サービスは、極めて包括的なものであって、プログラム
サイズが非常に大きく、TCP/IPをプロトコルとす
るインターネットでは実現が非常に難しい。そのため、
LDAP(Lightweight Directory Access Protocol) と
いった、TCP/IP向けに軽量化されたディレクトリ
サービスが提案されている。
【0009】ディレクトリサービスをユーザが利用する
場合、ディレクトリに対してフィルタ処理を行うことが
できる。フィルタ処理を行うフィルタリングマスクは、
ユーザの、ディレクトリへのアクセスの傾向や嗜好に応
じて設定される。例えば、ユーザの嗜好に応じて特定の
情報ジャンルに対してフィルタリングマスクが設定され
る。ユーザは、フィルタリングマスクが設定されたディ
レクトリ情報を、選択的にアクセスすることができる。
フィルタ処理を行うことにより、ユーザが不要な情報を
保持する必要が無くなる。
【0010】近年では、上述した一斉同報を行うデータ
伝送手段、すなわち、衛星回線やCATV回線、地上波
ディジタル放送などで、このディレクトリサービスを行
うことが提案されている。この場合には、ディレクトリ
サービスによる情報が一方向的に提供され、ユーザ側か
らの情報の要求ができない。したがって、ディレクトリ
サービスによるディレクトリ情報は、同一の情報が繰り
返し送信される。
【0011】ユーザ側では、送信されてきた情報を、例
えばテレビジョン受像機などに接続して用いられる、デ
ィジタル放送用受信機であるIRD(Integrated Reciev
er Decoder) や、STB(Set Top Box) に蓄積する。こ
のとき、上述したフィルタリングマスクを用いてフィル
タ処理がなされ、ユーザの嗜好に応じたディレクトリ情
報が選択的に蓄積される。フィルタ処理に用いられるフ
ィルタリングマスクは、ユーザ側で設定される。
【0012】ところで、オープンなネットワークである
インターネットは、情報の盗聴、改竄、なりすましとい
った危険が常に伴う。これを防ぐのが認証システムであ
り、この認証システムを運用するための基盤となる環境
を公開鍵基盤(PKI: Public Key Infrastructure)と
呼ぶ。PKIは、インターネット上の暗号化通信や電子
メール、各種決済プロトコルなどを運用するための基盤
環境として注目を集めており、その環境の信頼性が将来
のインターネット上の商取引(EC: ElectronicCommerce)
の成否を左右するものと考えられている。
【0013】PKIで用いられる公開鍵暗号化方式は、
秘密鍵および公開鍵の2つの鍵を用い、暗号化と復号化
をこれら2つの別々の鍵で行う、非対称型の暗号化方式
である。自分で保管する秘密鍵から公開鍵が作成され、
公開鍵は、相手に渡すことができる。公開鍵で暗号化さ
れたものは対応する秘密鍵でしか復号化できず、秘密鍵
で暗号化されたものは対応する公開鍵でしか復号化でき
ない。この特性を利用して、電子署名を行うことができ
る。
【0014】また、公開鍵だけでは上述の「なりすま
し」が可能なので、認証局(CA:Certificate Authori
ty)による公開鍵証明書(ディジタル証明書)の発行を
以て、公開鍵の管理とその認証が行われる。公開鍵証明
書の発行は、例えば以下のようにしてなされる。加入者
が秘密鍵と公開鍵のペアを所定の方法で作成し、その公
開鍵を認証局に提出する。認証局は、加入者の身分など
を確認してから、証明書のシリアル番号、加入者の名
前、公開鍵、有効期間などの情報に認証局の署名をし、
認証局が予め公開している公開鍵を利用して電子署名を
行った、公開鍵証明書を発行する。
【0015】図28を用いて、公開鍵証明書の仕組みに
ついて説明する。図28Aは、公開鍵証明書の作成の手
順を概略的に示す。公開鍵証明書は、シリアル番号、発
行者(認証局)名、有効期限、所有者名などの情報(こ
こでは証明書情報と称する)および所有者の公開鍵と、
証明書情報をダイジェスト関数で変換して得られた「指
紋」を認証局の秘密鍵で暗号化した認証局の署名とから
なる。なお、ダイジェスト関数は、長い文書を短い決ま
った長さに変換する、元の情報が少しでも変われば変換
結果が大きく異なる、という特徴を持つ関数である。こ
のことから、ダイジェスト関数で得られた値は、元の文
書の「指紋」と称される。
【0016】図28Bは、このようにして作成された公
開鍵証明書を確認する手順を概略的に示す。公開鍵証明
書に含まれる証明書情報からダイジェスト関数により
「指紋」が求められる。一方、公開鍵証明書において、
証明書情報に添付される署名が認証局の公開鍵で復号化
される。この復号化された結果と、上述の「指紋」とが
比較され、両者が一致すれば、公開鍵証明書が改竄され
ていない正当なものであると判断することができる。
【0017】
【発明が解決しようとする課題】現在、PKIの重要な
機能と位置付けられる、上述の公開鍵証明書を、広範囲
に分散したユーザに対して配布管理するシステムの完備
が急がれている。しかしながら、従来では、失効した公
開鍵証明書の通知を、広範囲に分散した大多数のユーザ
に効果的に通知する方式が確立されていないという問題
点があった。
【0018】例えば、証明書を盗難された場合や、個人
が退職してその証明書を利用する資格を失った場合な
ど、公開鍵証明書に定められている有効期限を待たず
に、その公開鍵証明書を無効化したいことがある。
【0019】このような場合、無効化された(失効し
た)証明書のシリアル番号や失効した日付などを、公開
鍵証明書を配布・管理するシステムに登録しておき、認
証手続きの際に公開鍵証明書を利用するアプリケーショ
ンに対して、対象の公開鍵証明書が失効していないかを
毎回確認させるようにしなければならない。この公開鍵
証明書の失効情報、さらに公開鍵証明書そのものを配
布、管理および失効照会を提供するシステムとして、オ
ンライン失効情報照会(PKIディレクトリサービス)
サービスが考えられる。
【0020】このPKIディレクトリサービスにおい
て、クライアント(証明書の失効情報を照会するアプリ
ケーション)の数が多数になると、問い合わせの負荷の
増大でシステムが破綻してしまうおそれがある。そのた
め、複数の分散されたPKIディレクトリサーバに大元
のPKIディレクトリサーバの複製を作り、問い合わせ
の負荷の分散を図る方法がとられる。しかしながら、複
製を作った場合には、それらを最新の情報に更新管理す
る必要が生じるが、複製の数の規模が非常に大きくなる
と、その更新管理が難しくなるという問題点があった。
【0021】したがって、この発明の目的は、PKIデ
ィレクトリサーバからPKIディレクトリクライアント
へ公開鍵証明書の失効情報の通知を、効率よく行うこと
ができる送信装置および送信方法、受信装置および受信
方法、ならびに、送受信システムおよび送受信方法を提
供することにある。
【0022】
【課題を解決するための手段】この発明は、上述した課
題を解決するために、公開鍵証明情報を階層的に管理す
るディレクトリの階層構造を送信する送信装置におい
て、自分の配下の情報を格納可能なコンテナエントリに
認証局情報を対応付け、コンテナエントリの配下にあっ
て、自分の配下の情報を格納できないリーフエントリに
エンドエンティティ情報を対応付け、コンテナエントリ
とリーフエントリとからなるディレクトリの階層構造を
管理する管理手段と、管理手段によって管理されるディ
レクトリの階層構造の変化を検出し、検出結果に基づき
ディレクトリの階層構造の変化の差分からなる差分情報
を求める検出手段と、検出手段で検出された差分情報を
送信する送信手段とを有し、コンテナエントリおよび/
またはリーフエントリには、最新の公開鍵証明情報を取
得可能な情報と、最新の公開鍵証明情報の失効情報とを
格納するようにしたことを特徴とする送信装置である。
【0023】また、この発明は、公開鍵証明情報を階層
的に管理するディレクトリの階層構造を送信する送信方
法において、自分の配下の情報を格納可能なコンテナエ
ントリに認証局情報を対応付け、コンテナエントリの配
下にあって、自分の配下の情報を格納できないリーフエ
ントリにエンドエンティティ情報を対応付け、コンテナ
エントリとリーフエントリとからなるディレクトリの階
層構造を管理する管理のステップと、管理のステップに
よって管理されるディレクトリの階層構造の変化を検出
し、検出結果に基づきディレクトリの階層構造の変化の
差分からなる差分情報を求める検出のステップと、検出
のステップで検出された差分情報を送信する送信のステ
ップとを有し、コンテナエントリおよび/またはリーフ
エントリには、最新の公開鍵証明情報を取得可能な情報
と、最新の公開鍵証明情報の失効情報とを格納するよう
にしたことを特徴とする送信方法である。
【0024】また、この発明は、送信された、公開鍵証
明情報を階層的に管理するディレクトリの階層構造を受
信する受信装置において、送信された、自分の配下の情
報を格納可能なコンテナエントリに認証局情報を対応付
け、コンテナエントリの配下にあって、自分の配下の情
報を格納できないリーフエントリにエンドエンティティ
情報を対応付け、コンテナエントリとリーフエントリと
からなるディレクトリの階層構造の変化を検出した検出
結果に基づき求められたディレクトリの階層構造の変化
の差分からなる差分情報を受信する受信手段と、受信手
段により受信された差分情報に基づき構成されるディレ
クトリの階層構造を管理する管理手段と、差分情報を選
択的に取り込み、管理手段で管理されるディレクトリの
階層構造を変更する変更手段とを有し、コンテナエント
リおよび/またはリーフエントリには、最新の公開鍵証
明情報を取得可能な情報と、最新の公開鍵証明情報の失
効情報とが格納されて送信されることを特徴とする受信
装置である。
【0025】また、この発明は、送信された、公開鍵証
明情報を階層的に管理するディレクトリの階層構造を受
信する受信方法において、送信された、自分の配下の情
報を格納可能なコンテナエントリに認証局情報を対応付
け、コンテナエントリの配下にあって、自分の配下の情
報を格納できないリーフエントリにエンドエンティティ
情報を対応付け、コンテナエントリとリーフエントリと
からなるディレクトリの階層構造の変化を検出した検出
結果に基づき求められたディレクトリの階層構造の変化
の差分からなる差分情報を受信する受信のステップと、
受信のステップにより受信された差分情報に基づき構成
されるディレクトリの階層構造を管理する管理のステッ
プと、差分情報を選択的に取り込み、管理のステップで
管理されるディレクトリの階層構造を変更する変更のス
テップとを有し、コンテナエントリおよび/またはリー
フエントリには、最新の公開鍵証明情報を取得可能な情
報と、最新の公開鍵証明情報の失効情報とが格納されて
送信されることを特徴とする受信方法である。
【0026】また、この発明は、公開鍵証明情報を階層
的に管理するディレクトリの階層構造を送信し、送信さ
れたディレクトリの階層構造を受信する送受信システム
において、自分の配下の情報を格納可能なコンテナエン
トリに認証局情報を対応付け、コンテナエントリの配下
にあって、自分の配下の情報を格納できないリーフエン
トリにエンドエンティティ情報を対応付け、コンテナエ
ントリとリーフエントリとからなるディレクトリの階層
構造を管理する第1の管理手段と、第1の管理手段によ
って管理されるディレクトリの階層構造の変化を検出
し、検出結果に基づきディレクトリの階層構造の変化の
差分からなる差分情報を求める検出手段と、検出手段で
検出された差分情報を送信する送信手段と、送信手段に
より送信された、差分情報を受信する受信手段と、受信
手段により受信された差分情報に基づき構成されるディ
レクトリの階層構造を管理する第2の管理手段と、差分
情報を選択的に取り込み、第2の管理手段で管理される
ディレクトリの階層構造を変更する変更手段とを有し、
コンテナエントリおよび/またはリーフエントリには、
最新の公開鍵証明情報を取得可能な情報と、最新の公開
鍵証明情報の失効情報とが格納されるようにしたことを
特徴とする送受信システムである。
【0027】また、この発明は、公開鍵証明情報を階層
的に管理するディレクトリの階層構造を送信し、送信さ
れたディレクトリの階層構造を受信する送受信方法にお
いて、自分の配下の情報を格納可能なコンテナエントリ
に認証局情報を対応付け、コンテナエントリの配下にあ
って、自分の配下の情報を格納できないリーフエントリ
にエンドエンティティ情報を対応付け、コンテナエント
リとリーフエントリとからなるディレクトリの階層構造
を管理する第1の管理のステップと、第1の管理のステ
ップによって管理されるディレクトリの階層構造の変化
を検出し、検出結果に基づきディレクトリの階層構造の
変化の差分からなる差分情報を求める検出のステップ
と、検出のステップで検出された差分情報を送信する送
信のステップと、送信のステップにより送信された、差
分情報を受信する受信のステップと、受信のステップに
より受信された差分情報に基づき構成されるディレクト
リの階層構造を管理する第2の管理のステップと、差分
情報を選択的に取り込み、第2の管理のステップで管理
されるディレクトリの階層構造を変更する変更のステッ
プとを有し、コンテナエントリおよび/またはリーフエ
ントリには、最新の公開鍵証明情報を取得可能な情報
と、最新の公開鍵証明情報の失効情報とが格納されるよ
うにしたことを特徴とする送受信方法である。
【0028】上述したように、請求項1および5に記載
の発明は、自分の配下の情報を格納可能なコンテナエン
トリに認証局情報を対応付け、コンテナエントリの配下
にあって、自分の配下の情報を格納できないリーフエン
トリにエンドエンティティ情報を対応付け、コンテナエ
ントリとリーフエントリとからなるディレクトリの階層
構造が管理され、管理されたディレクトリの階層構造の
変化の検出結果に基づき求められた、ディレクトリの階
層構造の変化の差分からなる差分情報が送信され、コン
テナエントリおよび/またはリーフエントリには、最新
の公開鍵証明情報を取得可能な情報と、最新の公開鍵証
明情報の失効情報とが格納されるため、受信側では、受
信側が有している公開鍵証明情報が最新のものであるか
否かを知ることができると共に、受信側が有している公
開鍵情報が最新のものでないとされた場合には、最新の
公開鍵証明情報を取得することができる。
【0029】また、請求項6および9に記載の発明は、
送信された、自分の配下の情報を格納可能なコンテナエ
ントリに認証局情報を対応付け、コンテナエントリの配
下にあって、自分の配下の情報を格納できないリーフエ
ントリにエンドエンティティ情報を対応付け、コンテナ
エントリとリーフエントリとからなるディレクトリの階
層構造の変化を検出した検出結果に基づき求められたデ
ィレクトリの階層構造の変化の差分からなる差分情報を
受信し、受信された差分情報に基づき構成されるディレ
クトリの階層構造が、選択的に取り込まれた差分情報に
基づき変更されると共に、コンテナエントリおよび/ま
たはリーフエントリには、最新の公開鍵証明情報を取得
可能な情報と、最新の公開鍵証明情報の失効情報とが格
納されて送信されているため、公開鍵証明情報が最新の
ものであるか否かを知ることができると共に、公開鍵情
報が最新のものでないとされた場合には、最新の公開鍵
証明情報を取得することができる。
【0030】また、請求項10および15に記載の発明
は、送信側では、自分の配下の情報を格納可能なコンテ
ナエントリに認証局情報を対応付け、コンテナエントリ
の配下にあって、自分の配下の情報を格納できないリー
フエントリにエンドエンティティ情報を対応付け、コン
テナエントリとリーフエントリとからなるディレクトリ
の階層構造の変化を検出し、検出結果に基づき求められ
た、ディレクトリの階層構造の変化の差分からなる差分
情報を送信し、受信側では、送信された差分情報を受信
し、受信された差分情報に基づき構成されるディレクト
リの階層構造が選択的に取り込まれた差分情報により変
更されると共に、コンテナエントリおよび/またはリー
フエントリには、最新の公開鍵証明情報を取得可能な情
報と、最新の公開鍵証明情報の失効情報とが格納されて
送信されるため、受信側では、受信側が有している公開
鍵証明情報が最新のものであるか否かを知ることができ
ると共に、受信側が有している公開鍵情報が最新のもの
でないとされた場合には、最新の公開鍵証明情報を取得
することができる。
【0031】
【発明の実施の形態】以下、この発明の実施の一形態に
ついて説明する。先ず、理解を容易とするために、この
発明の実施の一形態の説明に先んじて、この発明に適用
できるディレクトリサービスについて説明する。図1
は、この発明に適用できる系の一例を示す。送信側1
は、例えばインターネットや放送ネットワークなどの、
図示されないネットワーク上に存在する多数のコンテン
ツをツリー状の階層構造に整理し、ディレクトリ構造と
して管理している。送信側1では、このディレクトリ構
造を示すディレクトリ情報を放送ネットワーク2に対し
て送信する。受信側3は、図2に一例が示されるよう
に、放送ネットワーク2に対して多数が接続され、放送
ネットワーク2を介してなされた放送をそれぞれが受信
可能とされている。受信側3は、放送ネットワーク2で
放送されたディレクトリ情報を受信し、受信されたディ
レクトリ情報を参照して、放送ネットワーク2や他のネ
ットワーク上に存在する多数の情報の中から必要な情報
を選択し、入手することができる。
【0032】図1に一例が示されるように、送信側1
は、送信側ディレクトリサービスクライアント10(以
下、送信側クライアント10と略す)、送信側ディレク
トリサーバ11(以下、送信側サーバ11と略す)およ
び送信側ディレクトリサーバレプリケータ12(以下、
送信側レプリケータ12と略す)からなる。これら送信
側クライアント10、送信側サーバ11および送信側レ
プリケータ12は、互いに例えばインターネットといっ
たネットワークなどで接続されており、相互に通信が行
われる。
【0033】送信側クライアント10は、例えば図示さ
れないネットワークなどによってコンテンツを提供する
コンテンツプロバイダであって、ディレクトリ構造の変
更や更新を行う。送信側クライアント10は、ネットワ
ーク上の何処に位置していてもよい。送信側サーバ11
は、送信側クライアント10の内容照会や変更などを行
い、ディレクトリ構造を管理する。送信側サーバ11
は、ネットワーク上で分散して構成することができる。
送信側レプリケータ12は、送信側サーバ11で管理さ
れているディレクトリ構造をモニタしてディレクトリ構
造の更新を検出する。そして、送信側レプリケータ12
は、この検出結果に基づき、更新前の構造と更新後の構
造とを比較して差分を抽出し、ディレクトリ構造の差分
更新情報を構成する。差分更新情報は、放送ネットワー
ク2に送信される。差分更新情報の構成については、後
述する。
【0034】受信側3は、受信側ディレクトリサーバレ
プリケータ17(以下、受信側レプリケータ17と略
す)、受信側ディレクトリサーバ16(以下、受信側サ
ーバ16と略す)および受信側ディレクトリサービスク
ライアント15(以下、受信側クライアント15と略
す)からなる。受信側3は、例えばパーソナルコンピュ
ータや従来技術で述べたSTB、IRDなどであり、受
信側クライアント15は、ディレクトリ構造にアクセス
して複数の異なる形式のデータの取得ならびに表示がで
きるようにされた、例えばWWW(World Wide Web)ブラ
ウザなどのアプリケーションソフトウェアである。ま
た、受信側サーバ16は、ローカルなデータベースから
なり、ディレクトリ情報が格納される。
【0035】放送ネットワーク2で送信されたディレク
トリ情報、ディレクトリ構造の更新情報および更新情報
の差分情報などは、受信側レプリケータ17に受信され
る。受信側レプリケータ17では、受信されたこれらの
情報に基づき、受信側サーバ16に格納されたデータベ
ースを更新し、ディレクトリ構造の再構築を行う。受信
側クライアント15は、例えばユーザの指示により、受
信側レプリケータ17に対して必要な情報を要求する。
受信側レプリケータ17は、この要求に基づき受信側サ
ーバ16のデータベースを検索して、受信側クライアン
ト15に対して、例えば要求された情報のアドレスを返
す。受信側クライアント15は、このアドレスに基づ
き、例えば図示されないネットワーク上に存在する情報
にアクセスすることができる。
【0036】図3を用いて、ディレクトリ構造について
説明する。ディレクトリは、図に示されるように、ツリ
ー状の階層構造からなる。ツリーの各節点(ノード)を
エントリと称し、各エントリには、情報が格納される。
エントリには、ルートエントリ、コンテナエントリおよ
びリーフエントリの3種類が定義される。コンテナエン
トリは、さらに配下のエントリを包含することができる
エントリである。コンテナエントリによって構成される
階層を、以下、コンテナ階層と称する。
【0037】コンテナエントリ以外のエントリを、リー
フエントリと称する。リーフエントリは、配下にエント
リを含むことができない、末端の節点である。リーフエ
ントリによる階層を、以下、リーフ階層と称する。リー
フ階層は、コンテナエントリの配下に構成される。
【0038】また、ディレクトリツリーの最上位のエン
トリは、ルートエントリと称され、当該ディレクトリ構
造で完結される世界全体を示すエントリである。なお、
以下では、コンテナエントリは、少なくとも一つのリー
フエントリあるいはコンテナエントリを配下に持つもの
とする。
【0039】エントリは、複数の属性を持つ。エントリ
が持つ属性のうちで、ディレクトリツリーで一意に識別
される名前を、エントリ名と称する。エントリ名によっ
て、そのエントリの、ディレクトリ構造上の位置を特定
することができる。図3の例では、ルートエントリに
は、エントリ名Aが与えられている。ルートエントリの
直接的な配下のエントリには、図の左側に示されるリー
フエントリにはエントリ名A.Bが、右側のコンテナエ
ントリにはエントリ名A.Cがそれぞれ与えられる。以
下、ルートエントリから階層構造を辿った順にピリオド
で区切られて、各エントリに対してエントリ名が与えら
れる。
【0040】図4は、コンテナエントリの構造の一例を
示す。コンテナエントリは、コンテナエントリ自身の属
性と、自分の配下のコンテナエントリおよびリーフエン
トリのリストとを有する。配下のエントリのリストは、
要素を含まないこともできる。また、コンテナエントリ
自身の属性は、図示されるように、複数持つことができ
る。コンテナエントリの属性は、図4Bに示されるよう
に、属性名と属性値とから構成される。
【0041】図5は、リーフエントリの構造の一例を示
す。リーフエントリは、図5Aに示されるように、リー
フエントリの属性を複数、有する。図5Bは、リーフエ
ントリの属性のより具体的な例である。各属性は、属性
名と属性値とからなる。例えばリーフエントリがコンテ
ンツの検索情報である場合には、属性名の一つにアドレ
スがあり、その属性値として、インターネット上の場所
を示すURL(UniformResource Locator)などの、コン
テンツのアドレス情報が記述される。
【0042】ディレクトリ構造は、例えば、そのディレ
クトリ構造で完結する世界全体を表すルートエントリの
下に、コンテナエントリが例えば情報ジャンルに応じて
ツリー状に分類され配されて、構成される。
【0043】送信側1の構成について、より具体的に説
明する。送信側サーバ11には、図3〜図5で既に説明
したような構成に準えて、ディレクトリ構造が管理され
ている。送信側クライアント10は、提供するコンテン
ツに応じて、送信側サーバ11で管理されているディレ
クトリ構造に対して変更などを加える。送信側サーバ1
1に対してなされた変更は、送信側レプリケータ12に
モニタされる。
【0044】図6は、送信側レプリケータ12の機能を
説明するための機能ブロック図である。送信側レプリケ
ータ12は、例えば一般的なコンピュータシステムで構
成することができ、CPU(Central Processing Unit)
、メモリ、ハードディスクといった記録および記憶媒
体、通信手段、タイマ、ユーザインターフェイスなどか
らなる。この図6に示される機能ブロックは、CPU上
で動作するアプリケーションソフトウェアにより実現さ
れ、各モジュールは、アプリケーションソフトウェア上
の機能的な単位であって、それぞれがソフトウェアから
なる。
【0045】送信側レプリケータ12は、更新検知モジ
ュール20、メッセージ生成モジュール21およびメッ
セージ放送モジュール22からなる。これらモジュール
20、21および22のそれぞれは、コンテナ階層に関
する処理を行うモジュールと、リーフ階層に関する処理
を行うモジュールとを有する。
【0046】更新検知モジュール20は、送信側サーバ
11を参照して、サーバ11上に管理されているディレ
クトリ構造に変化があったかどうかを検知するモジュー
ルで、コンテナ階層更新検知モジュール23とリーフ階
層更新検知モジュール24とからなる。コンテナ階層更
新検知モジュール23は、送信側サーバ11をモニタし
て、コンテナ階層の構造の変化を検知する。また、リー
フ階層更新検知モジュール24は、送信側サーバ11を
モニタして、リーフ階層の構造およびリーフエントリの
内容の変化を検知する。
【0047】メッセージ生成モジュール21は、更新検
知モジュール20によるディレクトリ構造の変化の検知
結果に基づく、ディレクトリ構造の差分更新情報が示さ
れたメッセージを生成するモジュールで、コンテナスト
ラクチャアップデートメッセージ生成モジュール25
と、リーフエントリアップデートメッセージ生成モジュ
ール26とからなる。コンテナストラクチャアップデー
トメッセージ生成モジュール25は、コンテナ階層更新
検知モジュール23の検知結果に基づき、コンテナ階層
における構造変化に関する差分更新情報が示されたメッ
セージを生成する。また、リーフエントリアップデート
メッセージ生成モジュール26は、リーフ階層更新検知
モジュール24の検知結果に基づき、リーフ階層におけ
る更新情報が示されたメッセージを生成する。
【0048】メッセージ放送モジュール22は、メッセ
ージ生成モジュール21で生成されたメッセージを放送
ネットワーク2に対して放送するモジュールで、コンテ
ナストラクチャアップデートメッセージ放送モジュール
27とリーフエントリアップデートメッセージ放送モジ
ュール28とからなる。コンテナストラクチャアップデ
ートメッセージ放送モジュール27は、上述した、コン
テナストラクチャアップデートメッセージ生成モジュー
ル25で生成されたメッセージを放送する。また、リー
フエントリアップデートメッセージ放送モジュール28
は、上述した、リーフエントリアップデートメッセージ
生成モジュール26で生成されたメッセージを放送す
る。なお、メッセージ放送モジュール22からの放送ネ
ットワーク2に対するメッセージの放送は、同一のメッ
セージが所定回数だけ、サイクリックに送信されて行わ
れる。
【0049】次に、受信側3の構成について、より具体
的に説明する。図7は、受信側クライアント15の機能
を説明するための機能ブロック図である。受信側クライ
アント15は、例えば一般的なコンピュータシステムで
構成することができ、CPU(Central Processing Uni
t) 、メモリ、ハードディスクといった記録および記憶
媒体、通信手段、ユーザインターフェイスなどからな
る。この図7に示される機能ブロックは、CPU上で動
作するアプリケーションソフトウェアにより実現され、
各モジュールは、アプリケーションソフトウェア上の機
能的な単位であって、それぞれがソフトウェアからな
る。
【0050】受信側クライアント15は、上述したよう
に、例えばWWWブラウザであり、供給されたコンテン
ツ、例えば画像データ、テキストデータ、音声データお
よび動画データを統一的に表示および再生することがで
きるようにされている。また、所定の入力手段を用いて
ユーザによって入力された指示に基づき、上述の表示な
らびに再生を制御することができる。
【0051】受信側クライアント15は、ディレクトリ
検索モジュール30、ユーザ対話管理モジュール31お
よびコンテンツ取得モジュール32とからなる。また、
ユーザ対話管理モジュール31に対して、例えばキーボ
ードなどのテキスト入力手段、マウスなどのポインティ
ングデバイスや表示装置などからなるユーザインターフ
ェイス33が接続される。ユーザの、受信側クライアン
ト15に対するコンテンツ検索要求の入力は、ユーザイ
ンターフェイス33を用いて、ユーザ対話モジュール3
1に対して対話形式で行われる。
【0052】ユーザ対話モジュール31に対してコンテ
ンツ検索要求が入力されると、ユーザ対話管理モジュー
ル31からディレクトリ検索モジュール30に対して、
コンテンツのアドレスを検索するため、コンテンツに対
応するディレクトリエントリを検索するよう依頼が出さ
れる。ディレクトリ検索モジュール30では、この検索
依頼に応じて、受信側サーバ16に対してディレクトリ
エントリ検索要求を送る。
【0053】受信側サーバ16での検索要求に基づくデ
ィレクトリエントリの検索結果がディレクトリ検索モジ
ュール30に返される。検索結果は、ディレクトリ検索
モジュール30からユーザ対話管理モジュール31に返
される。そして、検索結果のディレクトリエントリ情報
から、例えば検索結果がリーフエントリであれば、属性
の一つであるコンテンツのアドレス情報が取り出され
る。ユーザ対話管理モジュール31からコンテンツ取得
モジュール32に対して、取り出されたアドレス情報に
よって示されるコンテンツを取得するよう、コンテンツ
取得依頼が出される。
【0054】コンテンツ取得モジュール32では、受け
取ったコンテンツ取得依頼に基づき、コンテンツサーバ
35に対してコンテンツの取得要求を送る。コンテンツ
サーバ35は、受信側クライアント15と、例えばイン
ターネットといった双方向ネットワーク36を介して接
続されるサーバであり、ユーザに対してコンテンツを提
供する。コンテンツの提供は、双方向ネットワーク36
を介して行ってもいいし、放送ネットワーク2によって
行うこともできる。
【0055】コンテンツ取得要求に基づきコンテンツサ
ーバ35から取得されたコンテンツは、例えば双方向ネ
ットワーク36を介してコンテンツ取得モジュール32
に供給され、コンテンツ取得モジュール32からユーザ
対話管理モジュール31に返される。ユーザ対話管理モ
ジュール31では、受け取ったコンテンツをユーザイン
ターフェイス33に出力する。
【0056】なお、要求するコンテンツが放送ネットワ
ーク2で伝送されるものである場合には、コンテンツ取
得モジュール32は、放送ネットワーク2で放送される
所望のコンテンツを、コンテンツ取得依頼に基づき直接
的に取得するようにしてもよい。
【0057】図8は、受信側サーバ16の機能を説明す
るための機能ブロック図である。この受信側サーバ16
も、説明は省略するが、上述の受信側クライアント15
と同様に、一般的なコンピュータシステムによって構成
される。受信側サーバ16は、ディレクトリ更新要求処
理モジュール40、ディレクトリデータベース41およ
びディレクトリ検索要求処理モジュール42からなる。
【0058】ディレクトリデータベース41は、送信側
サーバ11で管理されるディレクトリ構造に基づくディ
レクトリ情報が格納されている。上述したように、受信
側レプリケータ17は、放送ネットワーク2を介して送
信側1から送信されたディレクトリ構造の差分更新情報
を受信する。詳細は後述するが、受信側レプリケータ1
7からディレクトリ更新要求処理モジュール40に対し
て、差分更新情報に基づきディレクトリデータベース4
1に格納されているディレクトリ情報の更新を行うよ
う、要求が出される。ディレクトリ更新要求処理モジュ
ール40では、この要求に基づき、差分更新情報を用い
てディレクトリデータベース41に格納されているディ
レクトリ情報の更新を行う。
【0059】一方、上述した受信側クライアント15か
らのディレクトリエントリの検索要求は、ディレクトリ
検索要求処理モジュール40に受け取られる。ディレク
トリ検索要求処理モジュール40によって、受け取った
検索要求に基づきディレクトリデータベース41が検索
される。検索した結果得られたディレクトリエントリ、
例えばリーフエントリ中のアドレス情報は、ディレクト
リ検索要求処理モジュール42から受信側クライアント
15に返される。
【0060】上述したように系を構成することで、ユー
ザは、受信側クライアント15によってディレクトリ情
報を検索し、検索結果として、所望のコンテンツが提供
されるアドレス情報を得ることができる。そして、ユー
ザは、得られたアドレス情報に基づき所望のコンテンツ
を取得することができる。また、ディレクトリ構造は、
常に送信側レプリケータ12によってモニタされ、ディ
レクトリ構造に変更が生じたときには、変更に伴うディ
レクトリ構造の差分更新情報が放送ネットワーク2を介
して受信側レプリケータ17に供給される。ユーザ側で
は、供給された差分更新情報に基づき、受信側レプリケ
ータ17によってディレクトリデータベース41に格納
されたディレクトリ情報が変更される。そのため、ユー
ザは、常に実際のディレクトリ構造と同期したディレク
トリ情報を、ディレクトリデータベース41に保持する
ことができる。
【0061】次に、図9および図10を用いて、ディレ
クトリ構造の変化に伴い生成される、ディレクトリ構造
の差分更新情報について説明する。以下では、スキーマ
バージョンSvで特定されるあるコンテナ階層のコンテ
ナエントリXの配下に、コンテナエントリCまたはリー
フエントリlを追加または削除する処理を、 (Sv,X,〔+/−〕〔C/l〕) と記述する。このディレクトリ構造に対する処理を示す
記述は、この記述による処理で変化したディレクトリ構
造の、元の構造との差分を表しており、これを差分更新
情報として用いることができる。
【0062】スキーマバージョンSvは、ディレクトリ
構造の変更に伴い変化する値である。コンテナエントリ
X(またはC)は、コンテナエントリ名であり、ここで
は大文字のアルファベットで表す。リーフエントリl
は、リーフエントリ名であり、ここでは小文字のアルフ
ァベットで表す。エントリの追加は〔+〕で表され、削
除は〔−〕で表される。括弧〔〕中のスラッシュ記号
は、その両側に記された何方かが記述されることを示
す。なお、図9および図10において、二重線の四角
は、コンテナエントリを表し、単線の四角は、リーフエ
ントリを表す。ルートエントリは、接続線だけが示さ
れ、本体は省略されている。
【0063】図9Aにおいて、図示されないルートエン
トリの配下にコンテナエントリAのみが存在している。
この状態をスキーマバージョンSv=1とする。この状
態に、上述の記述に従い(1,A,+B)の処理を行
う。すなわち、コンテナエントリAの配下にコンテナエ
ントリBが加えられる。すると、図9Bのようなディレ
クトリ構造になる。図9Aの状態にコンテナエントリB
が加えられたことで、コンテナエントリの階層イメージ
が変化したとされ、スキーマバージョンSv=2とされ
る。
【0064】図9Bの状態に、さらに(2,A,+a)
の処理を行う。すなわち、コンテナエントリAの配下に
リーフエントリaを加える。すると、図9Cのようなデ
ィレクトリ構造になる。さらにまた、図9Cの状態に
(2,A,−a)の処理を行う。すなわち、リーフエン
トリaを、コンテナエントリAの配下から削除する。す
ると、図9Dのようなディレクトリ構造になる。さら
に、図9Dの状態に(2,A,−B)の処理を行う。す
なわち、コンテナエントリBを、コンテナエントリAの
配下から削除する。すると、図9Eのようなディレクト
リ構造になる。
【0065】図9Eの状態では、コンテナエントリの階
層イメージが図9Dの状態から変化しているため、スキ
ーマバージョンSvが更新され、スキーマバージョンS
v=3になる。したがって、図9Eの状態において、コ
ンテナエントリAの配下にコンテナエントリCを加える
処理は、(3,A,+C)と記述できる。この処理を行
うと、図9Fに示されるディレクトリ構造となる。
【0066】この図9の例では、(1,A,+B)、
(2,A,+a)、(2,A,−a)、(2,A,−
B)および(3,A+C)がそれぞれの段階での差分更
新情報とされる。
【0067】図10は、ディレクトリ構造を変更する別
の例を示す。上述の図9に示される例では、一度に一つ
の処理を行っていたが、図10では、2つずつの処理を
まとめて行っている。図10Aは、図示されないルート
エントリの配下にコンテナエントリAのみが存在してい
る。この状態がスキーマバージョンSv=1とする。こ
の図10Aの状態に対して、(1,A,+B)および
(1,A,+a)の処理を順に行う。すなわち、コンテ
ナエントリAの配下に、コンテナエントリBとリーフエ
ントリaとが追加される。すると、図10Bのようなデ
ィレクトリ構造となる。コンテナエントリの階層イメー
ジが変わり、スキーマバージョンSv=2となる。
【0068】図10Bの状態に、さらに、(2,A,−
a)および(2,B,+b)の処理を順に行う。すなわ
ち、コンテナエントリAの配下からリーフエントリaを
削除し、その後、コンテナエントリBの配下にリーフエ
ントリbを追加する。すると、図10Cのようなディレ
クトリ構造となる。
【0069】図10Cの状態に対して、さらに、(2,
B,+C)および(2,C,+c)の処理を行う。すな
わち、コンテナエントリBの配下にコンテナエントリC
を追加した後に、追加されたコンテナエントリCの配下
にリーフエントリcを追加する。この処理においては、
追加されたコンテナエントリに対してさらにエントリが
追加されるため、処理の前後を入れ換えることができな
い。処理後、図10Dのようなディレクトリ構造とな
り、コンテナエントリの階層イメージが変わったため、
スキーマバージョンSvが更新され、スキーマバージョ
ンSv=3とされる。
【0070】この図10の例では、(1,A,+B)お
よび(1,A,+a)、(2,A,−a)および(2,
B,+b)、ならびに、(2,B,+C)および(2,
C,+c)がそれぞれの段階での差分更新情報とされ
る。上述したように、複数の処理を一つのディレクトリ
構造の更新処理としてまとめて行うときには、処理の順
序を考慮する必要がある。
【0071】なお、ディレクトリ構造の差分更新情報
は、上述の例に限定されず、適用されるシステムに応じ
て様々な形式とすることができる。
【0072】また、リーフエントリに関しては、コンテ
ナエントリの配下からの削除やコンテナエントリの配下
への追加の他に、内容の修正だけが行われることがあ
る。内容の修正だけが行われた場合には、ディレクトリ
構造における変化は、生じない。この場合には、例え
ば、リーフエントリ名と、当該リーフエントリ中で修正
のあった属性名および属性値の列で、差分更新情報が構
成される。一例として、 このように差分更新情報が記述される。
【0073】この発明が適用される系では、上述したよ
うに、差分更新情報は、送信側1から受信側3に対して
放送ネットワーク2を介して一方向的に送信される。ま
た、一つの送信側1に対して複数の受信側3が存在し、
複数の受信側3の稼働状態もそれぞれ異なる。そのた
め、送信側1で管理されているディレクトリ情報と、受
信側3で管理されているディレクトリ情報とを同期させ
る必要がある。
【0074】以下、送信側1の送信側サーバ11に格納
されたディレクトリ情報と、受信側3の受信側サーバ1
6に格納されたディレクトリ情報とを同期させ、ディレ
クトリ構造の同期管理方法について説明する。
【0075】最初に、図11のフローチャートを用いて
コンテナエントリの同期管理方法について説明する。先
ず、ステップS1で、送信側クライアント10によっ
て、送信側サーバ11で管理されているディレクトリ構
造の、コンテナ階層の構成が変更される。例えば、コン
テナエントリの配下に新たなコンテナエントリやリーフ
エントリが追加される処理や、コンテナエントリの配下
のコンテナエントリやリーフエントリが削除される処理
が行われる。
【0076】次のステップS2では、送信側サーバ11
に対してなされた変更が送信側レプリケータ12によっ
て検知され、検知結果に基づき、コンテナ階層構成の変
更によるコンテナ構造更新情報Msg.1が生成され
る。生成されたコンテナ構造更新情報Msg.1は、放
送ネットワーク2に対して放送される。コンテナ構造更
新情報Msg.1の放送は、同一の内容が所定回数、サ
イクリックに繰り返されて行われる。
【0077】放送されたコンテナ構造更新情報Msg.
1は、ステップS3で、受信側レプリケータ17によっ
て受信される。受信側レプリケータ17は、受信側サー
バ16に格納されたディレクトリ情報に管理されるコン
テナ階層構成を、受信したコンテナ構造更新情報Ms
g.1に基づき変更する。これにより、送信側1と受信
側3とで、ディレクトリ情報のコンテナ階層の構造の同
期がとられる。
【0078】コンテナ構造更新情報Msg.1のフォー
マットは、例えば、 このように定義される。「MessageID 」(メッセージI
D)は、このメッセージ(コンテナ構造更新情報Ms
g.1)の識別情報であって、例えば、このメッセージ
が生成される毎に1ずつ増加される整数である。また、
「差分更新情報」は、コンテナ階層構成の変更による、
上述したディレクトリ構造の差分更新情報である。
【0079】図11のフローチャートにおけるステップ
S2の処理を、図12のフローチャートを用いて、より
詳細に説明する。この図12のフローチャートによる処
理は、全て送信側レプリケータ12上で行われる。先
ず、ステップS10で、送信側サーバ11上のコンテナ
エントリの階層構成の情報が全て読み込まれる。読み込
まれたコンテナエントリの階層構成の情報は、送信側レ
プリケータ12が有する、例えばメモリやハードディス
クといった記録または記憶媒体に、コピー1として記憶
される。
【0080】コピー1が記憶されたら、次のステップS
11で、タイマが所定の時間にセットされ、起動され
る。ステップS12によって、タイマにセットされた所
定時間を超過したかどうかが判断され、所定時間を超過
したと判断されたなら、処理はステップS13に移行す
る。ステップS13では、再び送信側サーバ11上のコ
ンテナエントリの階層構成の情報が全て読み込まれる。
読み込まれたコンテナエントリの階層構造は、送信側レ
プリケータ12が有する、例えばメモリやハードディス
クといった記録または記憶媒体に、コピー2として記憶
される。
【0081】次のステップS14では、ステップS10
で記憶されたコピー1と、ステップS13で記憶された
コピー2とが比較される。比較の結果、両者に差分が無
いとされれば(ステップS15)、処理はステップS1
1へ戻され、再びタイマがセットされ、コピー2の記憶
がなされる。
【0082】一方、ステップS14で、コピー1とコピ
ー2との間に差分があるとされれば、処理はステップS
16に移行する。ステップS16では、コピー1とコピ
ー2との差分に基づき、差分更新情報が生成される。そ
して、この差分更新情報が記述されたコンテナ構造更新
情報Msg.1が生成される。生成されたコンテナ構造
更新情報Msg.1は、放送ネットワーク2に対して送
信され、放送される。放送されたコンテナ構造更新情報
Msg.1は、受信側レプリケータ17に受信される。
【0083】ステップS16でコンテナ構造更新情報M
sg.1が放送されると、次のステップS17で、コピ
ー1の内容がコピー2の内容で置き替えられ、処理はス
テップS11に戻される。
【0084】図11のフローチャートにおけるステップ
S3の処理を、図13のフローチャートを用いて、より
詳細に説明する。この図13のフローチャートによる処
理は、全て受信側レプリケータ17上で行われる。最初
のステップS20で、送信側レプリケータ12によって
放送ネットワーク2を介して放送されたコンテナ構造更
新情報Msg.1が、受信側レプリケータ17によって
受信される。
【0085】ステップS21で、ステップS20での受
信がコンテナ構造更新情報Msg.1の初回の受信かど
うかが判断される。そして、この受信が初回の受信では
無いと判断されたら、処理はステップS23に移行し、
受信されたコンテナ構造更新情報Msg.1のメッセー
ジIDが受信側レプリケータ17が有する、例えばメモ
リやハードディスクといった記録または記憶媒体に、コ
ピー3として記憶される。
【0086】次のステップS24では、受信されたコン
テナ構造更新情報Msg.1の内容、すなわち、コンテ
ナ構造更新情報Msg.1に記述された差分更新情報に
基づき、受信側サーバ16で管理されているディレクト
リ情報が更新され、そのディレクトリ情報で示されるコ
ンテナ階層の構成が変更される。ステップS24の処理
の後、処理はステップS20に戻される。
【0087】一方、上述のステップS21で、ステップ
S20でのコンテナ構造更新情報Msg.1の受信が初
回の受信では無いと判断されたら、処理はステップS2
2に移行する。ステップS22では、受信されたコンテ
ナ構造更新情報Msg.1に記述されるメッセージID
と、前回の受信の際のステップS23の処理でコピー3
として記憶されたメッセージIDとが同一であるかどう
かが判断される。若し、同一であるとされれば、処理は
ステップS20に戻される。
【0088】一方、ステップS22で、両者のメッセー
ジIDが同一では無いとされれば、処理はステップS2
3に移行する。ステップS23では、上述したように、
メッセージIDが記憶媒体にコピー3として記憶され
る。この場合には、新たに受信されたメッセージID
で、前回受信され記憶されたメッセージIDが例えば上
書きされることになる。そして、次のステップS24
で、受信されたコンテナ構造更新情報Msg.1に基づ
き、受信側サーバ16上のコンテナエントリ階層の内容
が変更される。
【0089】次に、図14のフローチャートを用いてリ
ーフエントリの同期管理方法について説明する。先ず、
ステップS30で、送信側クライアント10によって、
送信側サーバ11で管理されているディレクトリ構造
の、あるコンテナエントリの配下のリーフエントリが変
更される。例えば、あるコンテナエントリの配下の新た
なリーフエントリの追加や、あるコンテナエントリの配
下のリーフエントリの削除や修正といった処理が行われ
る。
【0090】次のステップS31では、送信側サーバ1
1のあるコンテナエントリの配下のリーフエントリに対
してなされた変更が送信側レプリケータ12によって検
知される。そして、検知結果に基づき、あるコンテナエ
ントリ配下のリーフエントリの変更によるリーフ更新情
報Msg.x1が生成される。生成されたリーフ更新情
報Msg.x1は、放送ネットワーク2を介して複数の
受信側レプリケータ17に対してサイクリックに放送さ
れる。
【0091】放送されたリーフ更新情報Msg.x1
は、ステップS32で、受信側レプリケータ17によっ
て受信される。受信側レプリケータ17は、受信したリ
ーフ更新情報Msg.x1に基づき、受信側サーバ16
に格納されたディレクトリ情報に管理される、対応する
リーフエントリを変更する。これにより、送信側1と受
信側3とで、ディレクトリ情報のリーフエントリの同期
がとられる。
【0092】リーフ更新情報Msg.x1のフォーマッ
トは、例えば、 このように定義される。「MessageID 」(メッセージI
D)は、このメッセージ(リーフ更新情報Msg.x
1)の識別情報であって、例えば、このメッセージが生
成される毎に1ずつ増加される整数である。また、「差
分更新情報」は、上述したディレクトリ構造の差分更新
情報である。
【0093】図14のフローチャートにおけるステップ
S31の処理を、図15のフローチャートを用いて、よ
り詳細に説明する。この図15のフローチャートによる
処理は、全て送信側レプリケータ12上で行われる。先
ず、ステップS40で、送信側サーバ11上の、あるコ
ンテナエントリの配下のリーフエントリ名が全て読み込
まれる。読み込まれたリーフエントリ名は、送信側レプ
リケータ12が有する、例えばメモリやハードディスク
といった記録または記憶媒体に、コピー4として記憶さ
れる。
【0094】コピー1が記憶されたら、次のステップS
41で、タイマが所定の時間にセットされ、起動され
る。ステップS42によって、タイマにセットされた所
定時間を超過したかどうかが判断され、所定時間を超過
したと判断されたなら、処理はステップS43に移行す
る。ステップS43では、再び送信側サーバ11上の、
あるコンテナエントリの配下のリーフエントリ名が全て
読み込まれる。読み込まれたリーフエントリ名は、送信
側レプリケータ12が有する、例えばメモリやハードデ
ィスクといった記録または記憶媒体に、コピー5として
記憶される。
【0095】次のステップS44では、ステップS40
で記憶されたコピー4と、ステップS43で記憶された
コピー5とが比較される。比較の結果、両者の間に差分
が無いとされれば(ステップS45)、処理はステップ
S41へ戻され、再びタイマがセットされ、コピー5の
記憶が行われる。
【0096】一方、ステップS44で、コピー4とコピ
ー5との間に差分があるとされれば、処理はステップS
46に移行する。ステップS46では、コピー4とコピ
ー5との差分に基づき、差分更新情報が生成される。そ
して、この差分更新情報が記述されたリーフ更新情報M
sg.x1が生成される。生成されたリーフ更新情報M
sg.x1は、放送ネットワーク2に対して送信され、
放送される。放送されたリーフ更新情報Msg.x1
は、複数の受信側レプリケータ17に受信される。
【0097】ステップS46でリーフ更新情報Msg.
x1が放送されると、次のステップS47で、コピー4
の内容がコピー5の内容で書き替えられ、処理はステッ
プS41に戻される。
【0098】なお、上述の図15のフローチャートの処
理は、送信側レプリケータ12によって、送信側サーバ
11が管理するディレクトリ構造上の全てのコンテナエ
ントリに対して行われる。
【0099】図14のフローチャートにおけるステップ
S32の処理を、図16のフローチャートを用いて、よ
り詳細に説明する。この図16のフローチャートによる
処理は、全て受信側レプリケータ17上で行われる。最
初のステップS50で、送信側レプリケータ12によっ
て放送ネットワーク2を介して放送されたリーフ更新情
報Msg.x1が、受信側レプリケータ17によって受
信される。
【0100】ステップS51で、ステップS50での受
信がリーフ更新情報Msg.x1の初回の受信であるか
どうかが判断される。若し、この受信が初回の受信で無
いと判断されたら、処理はステップS53に移行し、受
信されたリーフ更新情報Msg.x1のメッセージID
が受信側レプリケータ17が有する、例えばメモリやハ
ードディスクといった記録または記憶媒体に、コピー6
として記憶される。
【0101】次のステップS54では、受信されたリー
フ更新情報Msg.x1の内容、すなわち、リーフ更新
情報Msg.x1に記述された差分更新情報に基づき、
受信側サーバ16で管理されているディレクトリ情報の
うち、対応するリーフエントリの内容が変更される。ス
テップS54の処理の後、処理はステップS50に戻さ
れる。
【0102】一方、上述のステップS51で、ステップ
S50でのリーフ更新情報Msg.x1の受信が初回の
受信では無いと判断されたら、処理はステップS52に
移行する。ステップS52では、受信されたリーフ更新
情報Msg.x1に記述されるメッセージIDと、前回
の受信の際のステップS53の処理でコピー6として記
憶されたメッセージIDとが同一であるかどうかが判断
される。若し、同一であるとされれば、処理はステップ
S50に戻される。
【0103】一方、ステップS52で、両者のメッセー
ジIDが異なるとされれば、処理はステップS53に移
行する。ステップS53では、上述したように、メッセ
ージIDが記憶媒体にコピー6として記憶される。この
場合には、新たに受信されたメッセージIDで、前回受
信され記憶されたメッセージIDが例えば上書きされる
ことになる。そして、次のステップS54で、受信され
たリーフ更新情報Msg.x1に基づき、受信側サーバ
16上の対応するリーフエントリの内容が変更される。
【0104】ところで、上述したように、図14のフロ
ーチャート中のステップS31による、リーフ更新情報
Msg.x1の放送は、送信側1で管理されるディレク
トリ構造中の、全コンテナエントリのそれぞれに関して
行われ、放送されるリーフ更新情報Msg.x1は、膨
大な量になることが予想される。したがって、従来技術
で問題点として既に述べたように、受信側3において全
てのリーフ更新情報Msg.x1を受信し、図16のフ
ローチャートによる処理を行うことは、大きな負担にな
る。そのため、受信側3では、必要とされている、すな
わち、頻繁に照会されるコンテナエントリの配下のリー
フエントリに対するリーフ更新情報Msg.x1のみ
を、放送された多数のリーフ更新情報Msg.x1か
ら、効率よくフィルタ処理する必要がある。
【0105】例えば、受信側レプリケータ17が家庭内
でテレビジョン受像機などに接続して用いられる、セッ
トトップボックス(STB)のような、処理能力や記憶
容量が限定された、すなわち、コンピュータリソースに
制約のある環境に実装される場合を想定する。この場合
には、放送されるリーフ更新情報Msg.x1の取得に
は限度がある。そのため、受信されたリーフ更新情報M
sg.x1を取捨選択して装置内に取り込み、記憶コス
トやメッセージ処理コストの軽減を図る必要がある。す
なわち、受信側レプリケータ17において、不必要な記
憶や処理にかかるコストを制限する必要がある。特に、
ディレクトリサービスが普及し、送信側サーバ11で管
理される対象のディレクトリ構造が巨大になるのに伴
い、上述のリーフ更新情報Msg.x1の取捨選択は、
より重要な事項となってくる。
【0106】以下に、リーフ更新情報Msg.x1に対
してフィルタ処理を行う方法について説明し、さらに、
この発明の主旨に係る、フィルタ処理を効率的に行う方
法について説明する。送信側レプリケータ12は、放送
されるリーフ更新情報Msg.x1に対して、受信側レ
プリケータ17においてフィルタ処理を行うためのフィ
ルタリングマスクを付加する。フィルタリングマスクを
解釈するためのマスクスキーマ構造と、マスクスキーマ
構造を送信側レプリケータ12から受信側レプリケータ
17に通知する方法などについては、後述する。
【0107】リーフ更新情報Msg.x1にフィルタリ
ングマスクを付加したメッセージ(Msg.x1’)の
構造を、次のように定義し、上述のリーフ更新情報Ms
g.x1を全てこのリーフ更新情報Msg.x1’で置
き替える。すなわち、リーフ更新情報Msg.x1’
は、 このように定義される。「MessageID 」(メッセージI
D)は、上述のリーフ更新情報Msg.x1の場合と同
様に、このメッセージ(リーフ更新情報Msg.x
1’)の識別情報であって、例えば、このメッセージが
生成される毎に1ずつ増加される整数である。「差分更
新情報」は、ここに記述されるフィルタリングマスクで
特定されるコンテナエントリ配下のリーフエントリの、
追加、削除および属性変更といった手続の情報である。
【0108】「FilteringMask 」(フィルタリングマス
ク)の構造は、次のように定義される。すなわち、フィ
ルタリングマスクは、 このように定義される。「MaskSchema Version」(マス
クスキーマバージョン)は、例えば上述のコンテナ構造
更新情報Msg.1におけるメッセージIDに相当し、
例えばこのフィルタリングマスクが生成される毎に1、
増加される値である。「Mask Value」(マスク値)は、
例えばビット列あるいはバイト単位で表されるマスクの
値である。
【0109】なお、マスク値の構造は、マスクスキーマ
バージョンによって対応付けられるマスクスキーマ(後
述する)によって規定される。マスクスキーマは、後述
する別のメッセージによって送信側レプリケータ12か
ら受信側レプリケータ17に通知される。
【0110】マスク値の割当方法について説明する。こ
の実施の一形態では、あるコンテナエントリの配下のコ
ンテナエントリのそれぞれを、所定ビット数からなるビ
ット列で識別する。受信側レプリケータ17では、受信
されたリーフ更新情報Msg.x1’中に記述されるマ
スク値を参照することによってフィルタ処理を行い、必
要なリーフ更新情報Msg.x1’を選択的に抽出する
ことができる。
【0111】フィルタリングマスクのマスク値のビット
配列構造は、コンテナエントリの階層構造に対応させて
決定される。例えば図17Aに一例が示されるように、
図3で説明したエントリ名の記述方法に倣い、上位のコ
ンテナエントリXの配下のエントリX.A、X.B、
X.C、X.DおよびX.Eを互いに識別するために、
それぞれ3ビットのマスク値(000)、(001)、
(010)、(011)および(100)が割り当てら
れる。なお、〔... 〕は、より上位のコンテナエントリ
が存在することを示す。
【0112】このようにマスク値が与えられた、コンテ
ナエントリXの配下のコンテナエントリに対して、エン
トリの追加や削除が行われた場合、図18のフローチャ
ートに従って処理が行われ、コンテナエントリの増減に
応じてマスク値の割り当てを行う。なお、以下では、コ
ンテナエントリの追加や削除が行われる前のコンテナ階
層を、更新前コンテナ階層と称する。更新前コンテナ階
層のマスク桁数M’は、送信側レプリケータ12の例え
ばメモリに記憶されているものとする。
【0113】先ず、最初のステップS60で、送信側レ
プリケータ12によって、対象となるコンテナエントリ
の配下のコンテナエントリの数Nが取得される。コンテ
ナエントリ中の、配下のコンテナエントリのリストを参
照することで、コンテナエントリ数Nが求められる。次
のステップS61では、N個の要素を一意に識別可能な
ビット数Mが選ばれ、マスクの桁数がM桁とされる。例
えば、上述した図17Aの例では、コンテナエントリX
は、配下のコンテナエントリを5個有しているので、5
個を一意に識別可能なビット数〔3〕がマスクの桁数と
される。
【0114】次に、ステップS62で、上述のステップ
S61で割り当てられたビット数Mが、対応する更新前
コンテナ階層に割り当てられたマスク桁数M’と同一か
どうかが判断される。若し、マスク桁数Mとマスク桁数
M’とが同一であれば、処理はステップS63に移行す
る。
【0115】ステップS63では、更新後のコンテナ階
層のコンテナエントリのうち、更新前コンテナ階層のコ
ンテナエントリに対応するエントリには、同一のマスク
値を割り当てる。さらに、次のステップS64で、例え
ば更新後のコンテナ階層に新規にコンテナエントリの追
加が起こったなどして、更新後のコンテナ階層に、更新
前コンテナ階層に対応するコンテナエントリが存在しな
いコンテナエントリがあった場合、そのコンテナエント
リに対して、同一のコンテナ階層の他のコンテナエント
リのマスク値と重複しないようなマスク値が与えられ
る。
【0116】一方、上述のステップS62で、マスク桁
数Mとマスク桁数M’とが同一ではないと判断された
ら、処理はステップS65に移行し、当該コンテナ階層
の全コンテナエントリのそれぞれに対して、一意にマス
ク値が与えられる。
【0117】例えば、上述の図17Aの状態に、新たに
コンテナエントリ”... X.F”が追加され、図17B
のようなコンテナ階層になったとする。コンテナエント
リ”... X”の配下のコンテナエントリ数Nは、6であ
り、一意に表現するためには3ビットが必要とされ、更
新後のコンテナエントリ”... X”の配下のコンテナ階
層のマスク桁数M=3でる。更新前コンテナ階層のマス
ク桁数M’=3であって、マスク桁数M’とマスク桁数
Mとは等しい。したがって、図17Bに示される各コン
テナエントリ”... X.A”、”... X.B”、”...
X.C”、”... X.D”および”... X.E”は、更
新前コンテナ階層の対応するエントリのマスク値がそれ
ぞれ割り当てられる(ステップS63)。一方、新規に
追加されたコンテナエントリ”... X.F”は、同じコ
ンテナ階層の他のコンテナエントリと重複しないよう
に、マスク値(101)が割り当てられる(ステップS
64)。
【0118】また例えば、上述の図17Aの状態から、
コンテナエントリ”... X.C”を削除して、図17C
のようなコンテナ階層になったとする。この場合、コン
テナエントリ”... X”配下のコンテナエントリ数N
は、4であり、2ビットのマスク桁数Mで各コンテナエ
ントリを識別可能なので、更新後のコンテナ階層のマス
ク桁数M=2である。一方、更新前コンテナ階層のマス
ク桁数M’=3であって、更新前と更新後とで、マスク
桁数が異なる。したがって、ステップS65の処理によ
って、当該階層の全エントリに、マスク桁数M=2で新
たにマスク値が割り当てられる。
【0119】さらに、図17Cの状態に、新たにコンテ
ナエントリ”... X.G”が追加され、図17Dの状態
になったとする。この場合、コンテナエントリ”...
X”配下のコンテナエントリ数Nは5であり、コンテナ
エントリを互いに識別するためには、マスク桁数M=3
とする必要がある。マスク桁数Mが更新前のマスク桁数
M’=2と異なるため、ステップS65の処理によっ
て、コンテナエントリ”... X”の配下の全コンテナエ
ントリに、新たにマスク値が割り当てられる。
【0120】マスク値のビットアサインは、ディレクト
リ構造の上位側から、コンテナ階層順にシリアルになさ
れる。一方、この実施の一形態では、上述のように、同
一階層に存在するエントリ数によってマスク桁数が異な
る。また、エントリの削除や追加などによって、コンテ
ナ階層中のエントリ数が変化し、それに伴いマスク桁数
が変化する。そのため、マスク値を表すビット列中のど
のビットがどのコンテナエントリ(あるいはコンテナ階
層)に対応するかを判断し、マスク値を解釈するための
情報機構が必要となる。
【0121】この実施の一形態では、マスク値を解釈す
るための情報機構として、次に示すマスクスキーマ(Mas
kSchema)を定義する。マスクスキーマは、 このように定義される。「MaskSchema Version」(マス
クスキーマバージョン)は、例えば上述のコンテナ構造
更新情報Msg.1におけるメッセージIDに相当し、
例えば対応するフィルタリングマスクが生成される毎に
1、増加される値である。「TotalMaskLength 」(全マ
スク長)は、全体のコンテナ階層に対応する、マスク値
全体のビット長を表す。すなわち、全マスク長は、ディ
レクトリ構造の全ての階層を表現するために必要なビッ
ト数に対応する。「Set of ContainerEntryMaskSchema
」(セットオブコンテナエントリマスクスキーマ)
は、後述する「 ContainerEntryMaskSchema 」(コンテ
ナエントリマスクスキーマ)の配列を表す。
【0122】上述のコンテナエントリマスクスキーマ
は、あるコンテナエントリに対応するフィルタリングマ
スクを規定する。すなわち、コンテナエントリマスクス
キーマは、 このように定義される。「ContainerEntryName」(コン
テナエントリ名)は、対象となるコンテナエントリのエ
ントリ名を表す文字列である。「OffsetLength」(オフ
セット長)は、このコンテナエントリに対応するフィル
タリングマスクの、全マスク値の最初のビットからのオ
フセット値であり、「MaskLength」(マスク長)は、マ
スク値の桁数(ビット長)である。「AssignedMaskValu
e 」(割り当てマスク値)は、対象となるコンテナエン
トリに割り当てられたマスク値であり、ビット列で表さ
れる。
【0123】図19を用いて、コンテナエントリマスク
スキーマの符号化について説明する。図19Aは、上述
の図17Aに対応する図であって、上位のコンテナエン
トリ”... X”の配下に、コンテナエントリ名”...
X.A”、”... X.B”、”... X.C”、”...
X.D”および”... X.E”の5つのコンテナエント
リが存在し、それぞれ3桁のマスク長で以てマスク値が
割り当てられている。なお、ここでは説明のため、これ
ら5つのコンテナエントリは、配下に他のエントリを有
しないものとする。
【0124】図19Bは、コンテナエントリ”... X.
C”のマスク値の一例を示す。この例では、オフセット
長が77ビットであることから、コンテナエント
リ”... X.C”に3ビットのマスク長で割り当てられ
た割り当てマスク値が、コンテナエントリ”... X.
C”のマスク値の78ビット目から開始される3ビット
であることが分かる。オフセット長に含まれる77ビッ
トのマスク値は、コンテナエントリ”... X.C”より
上位のコンテナエントリに対応する割り当てマスク値で
ある。
【0125】このように、マスク値における対象コンテ
ナエントリの割り当てマスク値の位置が規定され、コン
テナエントリマスクスキーマが符号化される。
【0126】コンテナエントリマスクスキーマのより具
体的な例を示す。上述したコンテナエントリ”... X.
C”に対応するコンテナエントリマスクスキーマは、例
えば、 このようになる。なお、括弧()内は、説明のためのもの
であって、実際に記述する必要は無い。
【0127】また、図19Aに示されるコンテナエント
リ”... X.Dに対応するコンテナエントリマスクスキ
ーマは、例えば、 このようになる。
【0128】このときのマスクスキーマは、例えばマス
クスキーマバージョンを498、全マスク長を134ビ
ットとした場合、 このようになる。上述の例では、コンテナエント
リ”... X.Cおよび”... X.Dのコンテナエントリ
マスクスキーマがマスクスキーマ中に記述されている
が、〔....〕の部分には、さらに他のコンテナエントリ
マスクスキーマが記述される。この例で分かるように、
マスクスキーマには、一つのディレクトリ構造における
全コンテナエントリに関するコンテナエントリマスクス
キーマが記述される。
【0129】なお、この例で、全マスク長が134ビッ
トとなっているのに対して、コンテナエントリ”...
X.Cおよび”... X.Dについてのコンテナエントリ
マスクスキーマでは、オフセット値が77ビットおよび
マスク長が3ビットの、合計で80ビットである。これ
は、これらコンテナエントリ”... X.Cおよび”...
X.Dの配下にも、さらにコンテナ階層が存在すること
を示している。
【0130】上述したマスクスキーマにおいて、コンテ
ナエントリ”... X.Cに対応するフィルタリングマス
クの符号化は、例えば、 このようになる。なお、マスク値(Mask Value)は、〔0
11〕以外の部分も全て、他の階層のコンテナエントリ
の割り当てマスク値からなるビットで埋められる。
【0131】同様に、コンテナエントリ”... X.Dに
対応するフィルタリングマスクの符号化は、例えば、 このようになる。
【0132】送信側レプリケータ12では、送信側サー
バ11をモニタして、コンテナエントリの階層構造の変
更を検知して、上述したマスクスキーマの変更を行う。
したがって、受信側3において適切なフィルタ処理を行
うためには、送信側レプリケータ12によって、階層構
造の変更に基づく差分更新情報の通知と共に、変更され
たマスクスキーマが受信側レプリケータ17に通知され
る必要がある。
【0133】この発明では、マスクスキーマを送信側レ
プリケータ12から受信側レプリケータ17に通知する
ために、上述したコンテナ構造更新情報Msg.1の構
造に対して、マスクスキーマ構造を追加する。マスクス
キーマ構造を追加されたコンテナ構造更新情報Msg.
1’を、 このように定義する。マスクスキーマは、コンテナ階層
の構成が変更される毎に変更される可能性がある。その
ため、このコンテナ構造更新情報Msg.1’も、コン
テナ階層の構成の変更に応じて生成される。「MessageI
D 」(メッセージID)は、コンテナ構造更新情報Ms
g.1’が生成される毎に1ずつ増加される整数であ
る。以下では、上述したコンテナ構造更新情報Msg.
1を、全てこのコンテナ構造更新情報Msg.1’に置
き替えるものとする。
【0134】送信側レプリケータ12では、上述した図
15のフローチャートにおけるステップS46で、コン
テナ階層に対応させたフィルタリングマスクが付加され
たメッセージである、リーフ更新情報Msg.x1’を
生成し、受信側レプリケータ17に放送している。ここ
で、受信側3では、リーフ更新情報Msg.x1’によ
る受信側レプリケータ17でのフィルタ処理を行う前
に、受信側クライアント15が必要としているコンテナ
階層の対象部分を特定しておく必要がある。
【0135】この実施の一形態では、受信側レプリケー
タ17において、対象となるコンテナ階層をフィルタ処
理するためのマスクをリストにした、ターゲットマスク
リストを作成する。
【0136】図20を用いてターゲットマスクリストに
ついて説明する。先ず、図20Aに示されるようなディ
レクトリ構造を想定する。図20Aのディレクトリ階層
は、最上位のルートエントリ以外は全てコンテナエント
リで構成されているものとする。各四角はコンテナエン
トリを表し、二重線の四角で示されるコンテナエントリ
は、例えばユーザの嗜好に基づき受信側クライアント1
5でフィルタ処理を行うように特定されたエントリであ
る。各エントリ内に表示された数字は、当該エントリ毎
に割り当てられたマスク値である。
【0137】図20Aに示されるように、ユーザの嗜好
に基づきフィルタ処理するように受信側クライアント1
5で特定されたコンテナエントリのそれぞれに対して、
マスク1〜5が割り当てられている。このディレクトリ
構造において、マスク1〜5の全マスク長分のマスク値
は、ディレクトリ構造を上位側から辿り、マスク1が
〔000〕、マスク2が〔0010〕マスク3が〔01
0〕、マスク4が〔10000〕およびマスク5が〔1
0010〕となる。
【0138】図20Bは、このように特定されたマスク
がリストとされたターゲットマスクリストの一例を示
す。ターゲットマスクリストは、ディレクトリの構造を
特定するスキーマバージョンと、ユーザの嗜好などに基
づき受信側クライアント15で特定された上述したマス
ク値のリストとからなる。すなわち、このターゲットマ
スクリストは、スキーマバージョンで記述されたディレ
クトリ構造でのみ有効なリストである。
【0139】図21は、ターゲットマスクリストを作成
する処理のフローチャートである。このフローチャート
は、受信側レプリケータ17で実行される。先ず、最初
のステップS70で、受信側レプリケータ17によっ
て、コンテナ構造更新情報Msg.1’が受信される。
ステップS71で、ステップS70での受信がコンテナ
構造更新情報Msg.1’の初回の受信であるかどうか
が判断され、初回の受信であると判断されれば、処理は
ステップS73に移行する。
【0140】ステップS73では、受信されたコンテナ
構造更新情報Msg.1’のメッセージIDを、受信側
レプリケータ17が有する、例えばメモリやハードディ
スクといった記録または記憶媒体に、コピー7として記
憶される。
【0141】次のステップS74で、受信されたコンテ
ナ構造更新情報Msg.1’の内容に基づき、コンテナ
階層を生成する。生成されたコンテナ階層を示す情報が
受信側レプリケータ17から受信側クライアント15に
提示され、特定すべきコンテナエントリの選択が促され
る。例えば、受信側クライアント15では、所定の表示
手段を用いて、供給されたコンテナ階層を示す情報に基
づく表示を行う。ユーザは、この表示に基づき、所定の
方法で必要なコンテナエントリを選択する。選択された
コンテナエントリの情報は、受信側クライアント15か
ら受信側レプリケータ17に渡される。
【0142】なお、コンテナエントリの特定は、ユーザ
の直接的な選択によってなされるのに限定されない。例
えば、受信側クライアント15によって、ユーザが照会
を行ったコンテナエントリの情報を蓄積し、蓄積された
情報に基づきユーザの嗜好の傾向を学習して自動的に必
要と思われるコンテナエントリを選択するようにもでき
る。さらに、ユーザによる直接的な選択と、学習による
自動的な選択とを併用することもできる。
【0143】このようにして、ステップS74でコンテ
ナエントリが選択されると、ステップS75で、選択さ
れたコンテナ階層に対応するフィルタリングマスクが設
定される。設定されたフィルタリングマスクの一覧は、
ターゲットマスクリストとして、例えば受信側レプリケ
ータ17が有する、例えばメモリやハードディスクとい
った記録または記憶媒体に記憶される。
【0144】一方、上述のステップS71で、コンテナ
構造更新情報Msg.1’の受信が初回ではないと判断
されれば、処理はステップS72に移行する。ステップ
S72では、受信されたコンテナ構造更新情報Msg.
1’のメッセージIDが、前回までのコンテナ構造更新
情報Msg.1’の受信によりステップS73でコピー
7として記憶媒体に記憶されたメッセージIDと同一か
どうかが判断される。
【0145】若し、両者が同一であると判断されたら、
処理はステップS70に戻される。一方、ステップS7
3で両者が同一では無いと判断されたら、処理はステッ
プS74に移行し、今回受信されたコンテナ構造更新情
報Msg.1’のメッセージIDが前回までのメッセー
ジIDの代わりに記憶媒体に記憶され、今回受信された
コンテナ構造更新情報Msg.1’に基づき以降の処理
が行われる。
【0146】図22は、図21のフローチャートに従っ
て作成されたターゲットマスクリストに基づき、放送さ
れたリーフ更新情報Msg.x1’を選択的に受信する
処理を示すフローチャートである。受信側レプリケータ
17は、ターゲットマスクリストに列挙されたフィルタ
リングマスクを有するリーフ更新情報Msg.x1’
を、放送ネットワーク2で放送されたリーフ更新情報M
sg.x1’の中から選択的に受信する。選択的に受信
されたリーフ更新情報Msg.x1’により、上述した
図14のフローチャートにおけるステップS32の処理
が実行される。
【0147】図22において、先ず、最初のステップS
80で、受信側レプリケータ17によって、放送ネット
ワーク2によって放送されたリーフ更新情報Msg.x
1’が受信される。受信側レプリケータ17では、記憶
媒体に記憶されているターゲットマスクリストが参照さ
れ、受信されたリーフ更新情報Msg.x1’に示され
るフィルタリングマスクがターゲットマスクリストに存
在するかどうかが判断される。若し、ターゲットマスク
リスト中に存在しなければ、処理はステップS80に戻
される。
【0148】一方、ステップS81で、当該フィルタリ
ングマスクがターゲットマスクリスト中に存在すると判
断されれば、処理はステップS82に移行し、ステップ
S80での受信がリーフ更新情報Msg.x1’の初回
の受信であるかどうかが判断される。若し、初回の受信
であるとされれば、処理ステップS84へ移行し、受信
されたリーフ更新情報Msg.x1’に示されるメッセ
ージIDが、例えば受信側レプリケータ17が有する、
例えばメモリやハードディスクといった記録または記憶
媒体に、コピー8として記憶される。そして、次のステ
ップS85で、受信されたリーフ更新情報Msg.x
1’が受信側レプリケータ17での処理の対象として選
択される。
【0149】一方、ステップS82で、上述のステップ
S80でのリーフ更新情報Msg.x1’の受信が初回
の受信では無いと判断されたら、処理はステップS83
に移行する。ステップS83では、受信されたリーフ更
新情報Msg.x1’のメッセージIDが、前回までの
リーフ更新情報Msg.x1’の受信によりステップS
84でコピー8として記憶媒体に記憶されたメッセージ
IDと同一かどうかが判断される。
【0150】若し、両者が同一であると判断されたら、
処理はステップS80に戻される。一方、ステップS8
3で両者が同一では無いと判断されたら、処理はステッ
プS84に移行し、今回受信されたコンテナ構造更新情
報Msg.x1’のメッセージIDが前回までのメッセ
ージIDの代わりに記憶媒体に記憶され、今回受信され
たコンテナ構造更新情報Msg.x1’に基づき以降の
処理が行われる。
【0151】上述のようにして、受信側サーバ16で管
理されるディレクトリ構造には、送信側サーバ11で管
理されるディレクトリ構造のうち、受信側サーバ16を
利用するユーザの嗜好を反映した部分のみを蓄積し、更
新することができる。そのため、受信側サーバ16にお
いてディレクトリ構造を蓄積するための蓄積記憶媒体を
有効に利用することができる。また、それと共に、受信
側サーバ16でのディレクトリ構造の格納コストを抑え
ることができる。さらに、受信側クライアント15によ
る受信側サーバ16の内容の検索要求に対する処理効率
を大幅に向上させることが可能となる。
【0152】なお、上述では、各コンテナエントリに割
り当てられた割り当てマスク長を可変長としたが、これ
はこの例に限定されない。割り当てマスク長は、例えば
バイト単位などの固定長とすることもできる。
【0153】次に、この発明の実施の一形態について説
明する。この発明では、上述したディレクトリの放送型
の差分更新方式を、実際の公開鍵証明書ディレクトリの
放送型差分更新方式に適用する。先ず、図23を用い
て、公開鍵証明書ディレクトリについて説明する。図2
3は、ユーザ(加入者)と認証局とからなる階層構造で
ある、認証局構造の一例を概略的に示す。
【0154】図23において、CA_0、CA_1およ
びCA_2が認証局、EE_1、EE_2およびEE_
3がエンドエンティティ(加入者)であるとする。実線
矢印は、矢印の元の認証局が矢印の先の認証局若しくは
エンドエンティティの公開鍵の証明書を発行することを
意味している。
【0155】図23の例では、認証局CA_1およびC
A_2は、それぞれ認証局CA_0により認証され、公
開鍵証明書を発行される。エンドエンティティEE_1
およびEE_2は、認証局CA_1に認証され、公開鍵
証明書を発行される。同様に、エンドエンティティEE
_3は、認証局CA_2により認証され、公開鍵証明書
を発行される。一方、認証局CA_0は、エンドエンテ
ィティEE_1、EE_2およびEE_3を直接的には
認証していない。このように、各認証局およびエンドエ
ンティティの間で階層構造が形成される。
【0156】また、点線矢印は、矢印の元のエンドエン
ティティが矢印の先の認証局と緊密な関係を結び、ルー
ト認証局として信頼していることを意味する。すなわ
ち、点線矢印の元のエンドエンティティは、矢印の先の
認証局の公開鍵をルート公開鍵として利用する。図23
の例では、例えば、エンドエンティティEE_1は、認
証局CA_0と緊密な関係を結び、エンドエンティティ
EE_1は、ルート公開鍵としてCA_0の公開鍵を用
いる。
【0157】ここで、一例として、エンドエンティティ
EE_1がエンドエンティティEE_2の公開鍵を得る
場合について考える。この場合、エンドエンティティE
E_1は、次の2つの証明書の証明書パスを処理するこ
とになる。すなわち、第1の証明書パスは、認証局CA
_0によって発行された認証局CA_1の証明書を得る
ためのパスである。第2の証明書パスは、認証局CA_
1によって発行されたエンドエンティティEE_2の証
明書を得るためのパスである。
【0158】つまり、エンドエンティティEE_1にと
っては、エンドエンティティEE_2の認証を行ってい
る認証局CA_1が信頼できるかどうかが分からないた
め、自分と信頼関係にある認証局CA_0に遡って認証
局CA_1の認証を確認する必要がある。
【0159】また、他の例として、エンドエンティティ
EE_1がエンドエンティティEE_3の公開鍵を得る
場合について考える。この場合、上述と同様に、エンド
エンティティEE_1にとっては、エンドエンティティ
EE_3の認証を行っている認証局CA_2が信頼でき
るかどうか分からないため、エンドエンティティEE_
1は、次の2つの証明書の証明書パスを処理することに
なる。すなわち、第1の証明書パスは、認証局CA_0
によって発行された認証局CA_2の証明書を得るため
のパスであり、第2のパスは、認証局CA_2によって
発行されたエンドエンティティEE_3の証明書を得る
ためのパスである。
【0160】さらに他の例として、エンドエンティティ
EE_2がエンドエンティティEE_1の公開鍵を得る
場合について考える。この場合には、エンドエンティテ
ィEE_1およびEE_2は、共通の認証局CA_1に
よって認証されている。そのため、エンドエンティティ
EE_2は、認証局CA_1によって発行されたエンド
エンティティEE_1の証明書を得るだけで事足りる。
【0161】図23からも分かるように、認証局構造
は、送信側ディレクトリサーバ11で管理されているデ
ィレクトリツリーに対応付けることが可能である。図2
4は、認証局構造とディレクトリツリーとの一例の対応
関係を示す。図24Aに示される認証局構造の各階層
が、図24Bに示されるディレクトリツリーの各階層に
それぞれ対応付けられる。すなわち、認証局構造におけ
る認証局CA_0、CA_1、CA_2がディレクトリ
ツリーにおけるコンテナエントリ100、101および
102にそれぞれ対応付けられる。認証局構造における
エンドエンティティEE_1、EE_2およびEE_3
がリーフエントリ110、111および112にそれぞ
れ対応付けられる。
【0162】ディレクトリツリーの各エントリに対する
エントリ名も、認証局構造に対応して与えることができ
る。例えば、図3を用いて上述した命名法を倣えば、コ
ンテナエントリ100のエントリ名は、対応する認証局
CA_0に基づきエントリ名CA_0とされる。コンテ
ナエントリ101は、認証局構造において認証局CA_
0から階層構造を辿った認証局CA_1に対応してい
る。したがって、コンテナエントリ101には、エント
リ名CA_0.CA_1が与えられる。同様に、リーフ
エントリ110は、認証局構造において、認証局CA_
1からさらに階層構造を辿ったエンドエンティティEE
_1に対応している。したがって、リーフエントリ11
0には、エントリ名CA_0.CA_1.EE_1が与
えられる。他のエントリにも、同様にしてに消極構造に
対応してエントリ名を与えることができる。
【0163】認証局構造における認証局に対応するエン
トリ(以下、CAエントリと称する)には、以下の2つ
の属性を持たせる。1つは、対応する認証局の最新の公
開鍵証明書のシリアル番号を格納する属性である。ここ
では、この属性の属性名を"PublicKeyCertificateSeria
lNumber"とし、属性値をシリアル番号そのものとする。
【0164】もう1つは、対応する認証局の最新の公開
鍵証明書、若しくは、最新の公開鍵証明書を取得する取
得方法を格納する属性である。ここでは、この属性の属
性名を"LatestPublicKeyCertificate"とし、属性値を、
最新の公開鍵証明書そのもの、若しくは、最新の公開鍵
証明書の取得方法とする。最新の公開鍵証明書を取得す
る取得方法は、例えば、その公開鍵証明書が置かれてい
るURLで示される。
【0165】一方、認証局構造におけるエンドエンティ
ティに対応するエントリ(以下、EEエントリと称す
る)には、同様にして、以下の2つの属性を持たせる。
1つは、対応するエンドエンティティの最新の公開鍵証
明書のシリアル番号を格納する属性である。ここでは、
この属性の属性名を"PublicKeyCertificateSerialNumbe
r"とし、属性値を、シリアル番号そのものとする。
【0166】もう1つは、対応するエンドエンティティ
の最新の公開鍵証明書、若しくは、最新の公開鍵証明書
の取得方法を格納する属性である。ここでは、この属性
の属性名を"LatestPublicKeyCertificate"とし、属性値
を、最新の公開鍵証明書そのもの、若しくは、最新の公
開鍵証明書の取得方法とする。最新の公開鍵証明書を取
得する取得方法は、例えば、その公開鍵証明書が置かれ
ているURLで示される。
【0167】上述のように、この実施の一形態では、エ
ントリの属性に対して、最新の公開鍵証明書を直接的に
格納する場合と、最新の公開鍵証明書を取得するための
情報を格納する場合との、2種類の形態が設けられてい
る。このように、エントリ属性に対して2種類の情報を
格納可能としておけば、放送ネットワーク資源を有効的
に活用できる。
【0168】一般に、公開鍵証明書は、その証明書を取
得するための情報(例えばURLなど)に比べてデータ
サイズが非常に大きい。したがって、ディレクトリ構造
が極めて多数のディレクトリエントリを有する場合に
は、それら多数のディレクトリエントリに対応する最新
の公開鍵証明書を周期的に放送すると、帯域を大幅に圧
迫してしまうことになる。しかしながら、帯域を節約す
るために、全て公開鍵証明書の取得情報のみの放送とし
てしまうと、受信側における最新の公開鍵の参照時に、
通信ネットワークを介した公開鍵証明書の取得処理が必
ず行われることになり、通信ネットワークのトラフィッ
クを圧迫してしまう。
【0169】そこで、放送ネットワークを介した即時広
域配布のメリットを生かすために、この発明の実施の一
形態では、以下のような方法を採る。すなわち、例えば
とある公開鍵証明書が失効した場合、新たに発行された
公開鍵証明書を、対応するエントリの属性"LatestPubli
cKeyCertificate"に格納すると共に、その公開鍵証明書
のシリアル番号を"PublicKeyCertificateSerialNumber"
に格納し、更新情報として放送する。所定の時間が経過
したら、当該公開鍵証明書をとあるURLで指定される
アドレスに置き、エントリの属性"LatestPublicKeyCert
ificate"の内容を当該URLに入れ替え、更新情報とし
て放送する。こうすることで、帯域を有効活用すること
が可能となる。
【0170】図25は、この実施の一形態に適用可能な
系の一例を示す。この図25の例は、暗号化電子メール
などの暗号化通信に2つのエンドエンティティが関わる
例である。また、この図では、認証局CA_0およびC
A_1が関わる。なお、図25において、上述した図1
と共通する部分には同一の番号を付し、詳細な説明を省
略する。
【0171】図25において、受信側3’をなす受信側
レプリケータ17’、受信側サーバ16’および受信側
クライアント15’は、受信側3をなす上述した受信側
レプリケータ17、受信側サーバ16および受信側クラ
イアント15と同等なもので、放送ネットワーク2を介
して送信側1の送信側サーバ11で管理されるディレク
トリツリーの複製を管理する。
【0172】ここで、受信側クライアント15および1
5’が図23および図24で上述したエンドエンティテ
ィEE_1およびEE_2にそれぞれ対応するものとす
る。受信側クライアント15および15’は、それぞ
れ、例えばソフトウェアからなる暗号化通信モジュール
50および50’を有する。受信側クライアント15と
15’は、暗号化通信モジュール50および50’を用
いて、通信ネットワーク51を介して互いに暗号化通信
を行う。
【0173】さらに、送信側において、送信側クライア
ント10および10’が存在し、送信側クライアント1
0’は、送信側クライアント10と同様に、送信側サー
バ11で管理されるディレクトリツリーの内容を更新で
きる。これら送信側クライアント10および10’は、
図23および図24で上述した、認証局階層における認
証局CA_0およびCA_1に対応する。
【0174】なお、図25では、受信側は、受信側3お
よび3’の2つが示されているが、実際には、さらに多
数の受信側構成が存在し、これら多数の受信側構成は、
通信ネットワーク51を介して互いに通信が可能とされ
ている。また、送信側クライアントも、ここでは送信側
クライアント10および10’の2つが示されている
が、実際には、さらに多数が存在する。
【0175】図26は、受信側クライアント15および
15’の間で行われる暗号化通信の一例の手順を示すフ
ローチャートである。なお、図26では、受信側レプリ
ケータ17および17’をそれぞれ第1および第2の受
信側レプリケータ、暗号化通信モジュール50および5
0’をそれぞれ第1および第2の暗号化通信モジュール
と称している。
【0176】先ず、このフローチャートの処理に先立
ち、受信側クライアント15および15’は、それぞ
れ、自身の秘密鍵および公開鍵のペアを生成しているも
のとする。また、受信側クライアント15すなわちエン
ドエンティティEE_1は、送信側クライアント10’
すなわち認証局CA_1から、自身の公開鍵について公
開鍵証明書を発行してもらっているものとする。このと
き、図23を用いて上述した証明書パス、すなわち、認
証局CA_0が認証局CA_1に証明書を発行し、認証
局CA_1がエンドエンティティEE_2の証明書を発
行することを考慮に入れ、前提として、認証局CA_1
は、認証局CA_0すなわち送信側クライアント10か
ら予め公開鍵証明書を発行してもらっているものとす
る。
【0177】同様に、受信側クライアント15’すなわ
ちエンドエンティティEE_2は、送信側クライアント
10’すなわち認証局CA_1から、自身の公開鍵につ
いて公開鍵証明書を発行してもらっているものとする。
【0178】これらの、受信側クライアント15および
15’各々の公開鍵についての公開鍵証明書のそれぞれ
は、受信側クライアント15および15’が共にアクセ
ス可能な場所、例えばインターネット上のとあるWeb
サイトに格納するか、予め相互に交換し合うことによ
り、互いに必要なときに利用できるようにしておく。
【0179】先ず、最初のステップS90で、受信側ク
ライアント15において、暗号通信モジュール50が利
用され受信側クライアント15の秘密鍵によってメッセ
ージに署名される。次のステップS91では、受信側ク
ライアント15により受信側クライアント15’の公開
鍵証明書が取得され、取得された公開鍵証明書に格納さ
れている公開鍵が得られる。なお、ステップS91の処
理の前提として、受信側クライアント15により送信側
クライアント10’の公開鍵証明書が取得され、そこに
格納されている公開鍵が既に取得されている。次のステ
ップS92では、受信側クライアント15において、暗
号通信モジュール50が用いられ、ステップS91で得
られた公開鍵によりステップS90で署名されたメッセ
ージが暗号化される。
【0180】ステップS92で暗号化されたメッセージ
は、ステップS93で、通信ネットワーク51を介して
受信側クライアント15’に送信される。受信側クライ
アント15’では、受信側クライアント15から送信さ
れたメッセージを受信し、暗号通信モジュール50’を
用いて受信側クライアント15’の秘密鍵で、受信され
たメッセージを復号化する。復号化されたメッセージに
は、上述のステップS90において、受信側クライアン
ト15の秘密鍵を用いて署名されている。
【0181】次のステップS95では、受信側クライア
ント15’により、受信側クライアント15の公開鍵証
明書が取得され、取得された公開鍵証明書に格納されて
いる公開鍵が得られる。そして、ステップS96で、受
信側クライアント15’により、暗号化モジュール5
0’が用いられ、ステップS95で得られた公開鍵によ
り上述のステップS94で復号化されたメッセージの署
名が確認される。
【0182】上述したフローチャートのうち、ステップ
S91およびステップS95において公開鍵が取得され
る際に、受信側クライアント15および15’は、取得
する公開鍵が失効していない有効な公開鍵証明書に基づ
くものであることを確認しなければならない。この確認
は、これらの公開鍵証明書を発行した認証局に問い合わ
せることで可能である。しかしながら、一般的には、公
開鍵証明書の発行数が多い認証局では、問い合わせの負
荷が増大し、応答性能が極端に低下するという問題によ
り、オンラインによる有効性の確認処理が不可能である
ことが多い。
【0183】そこで、この発明の実施の一形態では、受
信側クライアント15や受信側クライアント15’は、
それぞれ利用する公開鍵の有効性について該当する認証
局に問い合わせる代わりに、各自のローカルな環境に設
置されている受信側サーバ16や受信側サーバ16’で
管理されるディレクトリに問い合わせるようにする。受
信側クライアント15や15’のローカルな環境に設置
されている受信側サーバ16や16’は、例えば、家庭
内LAN(Local Area Network)上、マンション内などに
設置される電話線集線装置、ケーブルテレビネットワー
クのヘッドエンドなどが想定できる。これにより、当該
公開鍵証明書を発行した認証局への問い合わせの集中を
分散化させることができる。
【0184】上述した、認証局への問い合わせをローカ
ルな環境に置き換えて行うには、以下の情報を更新する
必要がある。第1に、受信側サーバ16においては、受
信側クライアント15’すなわちエンドエンティティE
E_2の公開鍵証明書が有効か否かを示す情報が更新さ
れている必要がある。また、この例では、上述した証明
書パスに従い、受信側クライアント15すなわちエンド
エンティティEE_1は、エンドエンティティEE_2
に公開鍵証明書を発行する認証局CA_1とは緊密な関
係にない。したがって、受信側サーバ16においては、
送信側クライアント10’、すなわち、エンドエンティ
ティEE_2に対して公開鍵証明書を発行する認証局C
A_1の公開鍵証明書が有効であるか否かを示す情報
も、最新の情報に更新されている必要がある。
【0185】第2に、受信側サーバ16’においては、
受信側クライアント15すなわちエンドエンティティE
E_1の公開鍵証明書が有効であるか否かの情報が、最
新の情報に更新されている必要がある。
【0186】なお、公開鍵証明書が有効であるかどう
か、すなわち、その公開鍵証明書が失効しているか否か
は、当該公開鍵証明書と、当該公開鍵証明書に対応する
最新の公開鍵証明書とを比較し、シリアル番号が一致し
ているかどうかを調べることで判断できる。この発明で
は、新たに発行された公開鍵証明書のシリアル番号を、
エントリの属性"PublicKeyCertificateSerialNumber"に
格納するようにしているため、このエントリ属性を調べ
ることで、当該公開鍵証明書が有効であるかどうかを知
ることができる。
【0187】上述の図24に示されるように、図23に
示される認証局構造と、受信側クライアント15および
15’のディレクトリエントリとの対応付けがなされて
いる。したがって、受信側サーバ16で管理されるディ
レクトリにおいては、コンテナエントリ101(エント
リ名CA_0.CA_1)およびリーフエントリ111
(エントリ名CA_0.CA_1.EE_2)の更新情
報に注目する必要がある。同様に、受信側サーバ16’
で管理されるディレクトリにおいては、リーフエントリ
110の更新情報を注目しなければいけない。
【0188】受信側サーバ15および15’のそれぞれ
では、上述の注目対象となるエントリの上位のコンテナ
エントリがフィルタリングマスクの対象コンテナエント
リとして選択される。フィルタリングマスクの対象コン
テナエントリの選択は、上述した図21に従い、ステッ
プS74においてなされる。選択されたコンテナエント
リに対応するフィルタリングマスクが、それぞれのター
ゲットマスクリストに格納されることになる。
【0189】図27を用いて、それぞれのターゲットマ
スクリストにどのようなフィルタリングマスクが格納さ
れるかについて、より具体的に説明する。なお、図27
において、斜線が付された四角は、公開鍵証明書を取得
する対象となるエントリを示す。また、点線で示された
四角は、フィルタリングマスクに対応するコンテナエン
トリを示す。図27Aおよび図27Bは、それぞれ受信
側サーバ16および16’におけるフィルタリング対象
のエントリを示す。
【0190】受信側サーバ16におけるフィルタリング
対象のエントリは、図27Aに示されるように、エント
リ名CA_0.CA_1のコンテナエントリ101と、
エントリ名CA_0.CA_1.EE_2のリーフエン
トリ111である。受信側レプリケータ17によって、
これらエントリ101および111をそれぞれ示すフィ
ルタリングマスクがターゲットマスクリストに格納され
る。ターゲットマスクリストは、例えば受信側レプリケ
ータ17が有する記憶媒体に記憶される。
【0191】同様にして、受信側サーバ16’における
フィルタリングフィルタリング対象のエントリは、図2
7Bに示されるように、エントリ名CA_0.CA_
1.EE_1のリーフエントリ110である。受信側レ
プリケータ17’によって、これらエントリ110を示
すフィルタリングマスクがターゲットマスクリストに格
納される。
【0192】なお、送信側サーバ11で管理されている
ディレクトリ情報と、受信側サーバ16および16’で
管理されているディレクトリ情報とは、同期がとれてい
る必要がある。この実施の一形態では、既に述べたよう
に、所定の時間にセットされたタイマによって決められ
るタイミングで以て放送される、ディレクトリ情報の差
分更新情報によって受信側サーバ16および16’で管
理されているディレクトリ情報が更新されることで、送
信側と受信側との同期が取られる。
【0193】このとき、送信側と受信側の同期は、段階
的にとるようにできる。例えば、上述のタイミングで差
分更新情報による更新を行うと共に、より長い周期で全
てのディレクトリ構造の放送を行い、受信側サーバ16
および16’の更新を行うようにできる。さらに、受信
側サーバ16および16’と送信側サーバ11とを双方
向通信が可能な通信回線で接続して、受信側サーバ16
および16’側において、ターゲットマスクリストに格
納されている情報については、随時、送信側サーバ11
に対して最新情報を要求し、送信側サーバ11では、こ
の要求に応じて、対応するディレクトリ構造の送信を行
うようにできる。
【0194】
【発明の効果】以上説明したように、この発明の実施の
一形態では、ターゲットマスクリストを用いることによ
って、上述のようにして、受信側サーバ16および1
6’で管理されるディレクトリツリーの内容には、送信
側サーバ11で管理されるディレクトリツリー構成のう
ち、受信側クライアント15および15’がよくアクセ
スするエントリの情報だけを蓄積および更新することが
できる。これにより、受信側サーバ16および16’に
おけるディレクトリツリーの格納コストを抑えることが
できると共に、蓄積媒体の有効活用が図れる効果があ
る。
【0195】また、この発明によれば、認証局およびエ
ンドエンティティからなる階層構造である認証局構造
と、送信側ディレクトリサーバおよび受信側ディレクト
リサーバで管理されるディレクトリツリーとが対応付け
られ、認証局構造において公開鍵証明書を得るための証
明書パスに対応してターゲットマスクリストが作成され
る。そのため、複数の受信側ディレクトリサーバの内容
に対する複数の受信側ディレクトリサーバからの公開鍵
証明書の失効情報検索用急に対する処理効率を、大幅に
向上させることができる効果がある。
【図面の簡単な説明】
【図1】この発明に適用できる系の一例を示す略線図で
ある。
【図2】複数の受信側が放送ネットワークに接続される
ことを説明するための略線図である。
【図3】ディレクトリ構造を説明するための略線図であ
る。
【図4】コンテナエントリの構造の一例を示す略線図で
ある。
【図5】リーフエントリの構造の一例を示す略線図であ
る。
【図6】送信側レプリケータの機能を説明するための機
能ブロック図である。
【図7】受信側クライアントの機能を説明するための機
能ブロック図である。
【図8】受信側サーバの機能を説明するための機能ブロ
ック図である。
【図9】ディレクトリ構造の差分更新情報について説明
するための略線図である。
【図10】ディレクトリ構造の差分更新情報について説
明するための略線図である。
【図11】コンテナエントリの同期管理方法を説明する
ためのフローチャートである。
【図12】コンテナエントリの同期管理方法をより詳細
に説明するためのフローチャートである。
【図13】コンテナエントリの同期管理方法をより詳細
に説明するためのフローチャートである。
【図14】リーフエントリの同期管理方法を説明するた
めのフローチャートである。
【図15】リーフエントリの同期管理方法をより詳細に
説明するためのフローチャートである。
【図16】リーフエントリの同期管理方法をより詳細に
説明するためのフローチャートである。
【図17】フィルタリングマスクのマスク値のビット配
列構造を説明するための略線図である。
【図18】エントリの追加や削除が行われた場合の、コ
ンテナエントリの増減に応じたマスク値の割り当て処理
のフローチャートである。
【図19】コンテナエントリマスクスキーマの符号化を
説明するための略線図である。
【図20】ターゲットマスクリストを説明するための略
線図である。
【図21】ターゲットマスクリストを作成する処理のフ
ローチャートである。
【図22】ターゲットマスクリストに基づき、放送され
たリーフ更新情報Msg.x1’を選択的に受信する処
理を示すフローチャートである。
【図23】認証局構造を説明するための図である。
【図24】認証局構造とディレクトリツリーとの一例の
対応関係を示す略線図である。
【図25】実施の一形態に適用可能な系の一例を示す略
線図である。
【図26】受信側クライアントの間で行われる暗号化通
信の一例の手順を示すフローチャートである。
【図27】それぞれのターゲットマスクリストにどのよ
うなフィルタリングマスクが格納されるかについて説明
するための図である。
【図28】公開鍵証明書の仕組みについて説明するため
の図である。
【符号の説明】
1・・・送信側、2・・・放送ネットワーク、3・・・
受信側、10,10’・・・送信側ディレクトリサービ
スクライアント、11・・・送信側ディレクトリサー
バ、12・・・送信側ディレクトリサーバレプリケー
タ、15,15’・・・受信側ディレクトリサービスク
ライアント、16,16’・・・受信側ディレクトリサ
ーバ、17,17’・・・受信側ディレクトリサーバレ
プリケータ、50,50’・・・暗号化通信モジュー
ル、51・・・通信ネットワーク、CA_0,CA_
1,CA_2・・・認証局、EE_1,EE_2,EE
_3・・・エンドエンティティ
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 FI テーマコート゛(参考) H04L 9/00 675D (72)発明者 西尾 郁彦 東京都品川区北品川6丁目7番35号 ソニ ー株式会社内 (72)発明者 角田 智弘 東京都品川区北品川6丁目7番35号 ソニ ー株式会社内 Fターム(参考) 5B082 EA01 GA11 5J104 AA16 EA05 MA04 MA08 NA02 PA07 9A001 BB03 BB04 BB06 CC02 DZ15 EE03 JJ25 JJ27 KK56 KK60 LL03

Claims (15)

    【特許請求の範囲】
  1. 【請求項1】 公開鍵証明情報を階層的に管理するディ
    レクトリの階層構造を送信する送信装置において、 自分の配下の情報を格納可能なコンテナエントリに認証
    局情報を対応付け、上記コンテナエントリの配下にあっ
    て、自分の配下の情報を格納できないリーフエントリに
    エンドエンティティ情報を対応付け、上記コンテナエン
    トリと上記リーフエントリとからなるディレクトリの階
    層構造を管理する管理手段と、 上記管理手段によって管理される上記ディレクトリの階
    層構造の変化を検出し、該検出結果に基づき上記ディレ
    クトリの階層構造の変化の差分からなる差分情報を求め
    る検出手段と、 上記検出手段で検出された上記差分情報を送信する送信
    手段とを有し、 上記コンテナエントリおよび/または上記リーフエント
    リには、最新の公開鍵証明情報を取得可能な情報と、該
    最新の公開鍵証明情報の失効情報とを格納するようにし
    たことを特徴とする送信装置。
  2. 【請求項2】 請求項1に記載の送信装置において、 上記失効情報は、上記公開鍵証明情報のシリアル番号で
    あることを特徴とする送信装置。
  3. 【請求項3】 請求項1に記載の送信装置において、 上記コンテナエントリおよび/または上記リーフエント
    リの属性に、上記最新の公開鍵証明情報および上記最新
    の公開鍵証明情報を取得するための情報のうち何れか一
    方を選択して格納可能としたことを特徴とする送信装
    置。
  4. 【請求項4】 請求項3に記載の送信装置において、 上記検出手段により上記差分が検出された更新事象から
    の時間に応じて、上記属性に格納される情報を、上記最
    新の公開鍵証明情報と上記最新の公開鍵証明情報を取得
    するための情報との間で変更可能なようにしたことを特
    徴とする送信装置。
  5. 【請求項5】 公開鍵証明情報を階層的に管理するディ
    レクトリの階層構造を送信する送信方法において、 自分の配下の情報を格納可能なコンテナエントリに認証
    局情報を対応付け、上記コンテナエントリの配下にあっ
    て、自分の配下の情報を格納できないリーフエントリに
    エンドエンティティ情報を対応付け、上記コンテナエン
    トリと上記リーフエントリとからなるディレクトリの階
    層構造を管理する管理のステップと、 上記管理のステップによって管理される上記ディレクト
    リの階層構造の変化を検出し、該検出結果に基づき上記
    ディレクトリの階層構造の変化の差分からなる差分情報
    を求める検出のステップと、 上記検出のステップで検出された上記差分情報を送信す
    る送信のステップとを有し、 上記コンテナエントリおよび/または上記リーフエント
    リには、最新の公開鍵証明情報を取得可能な情報と、該
    最新の公開鍵証明情報の失効情報とを格納するようにし
    たことを特徴とする送信方法。
  6. 【請求項6】 送信された、公開鍵証明情報を階層的に
    管理するディレクトリの階層構造を受信する受信装置に
    おいて、 送信された、自分の配下の情報を格納可能なコンテナエ
    ントリに認証局情報を対応付け、上記コンテナエントリ
    の配下にあって、自分の配下の情報を格納できないリー
    フエントリにエンドエンティティ情報を対応付け、上記
    コンテナエントリと上記リーフエントリとからなるディ
    レクトリの階層構造の変化を検出した検出結果に基づき
    求められた上記ディレクトリの階層構造の変化の差分か
    らなる差分情報を受信する受信手段と、 上記受信手段で受信された上記差分情報に基づき構成さ
    れるディレクトリの階層構造を管理する管理手段と、 上記差分情報を選択的に取り込み、上記管理手段で管理
    される上記ディレクトリの階層構造を変更する変更手段
    とを有し、 上記コンテナエントリおよび/または上記リーフエント
    リには、最新の公開鍵証明情報を取得可能な情報と、該
    最新の公開鍵証明情報の失効情報とが格納されて上記送
    信されることを特徴とする受信装置。
  7. 【請求項7】 請求項6に記載の受信装置において、 上記失効情報は、上記公開鍵証明情報のシリアル番号で
    あることを特徴とする受信装置。
  8. 【請求項8】 請求項6に記載の受信装置において、 上記変更手段は、上記公開鍵証明情報を取得するための
    証明情報パスに対応する上記コンテナエントリおよび/
    または上記リーフエントリの更新情報を上記選択的に取
    り込むことを特徴とする受信装置。
  9. 【請求項9】 送信された、公開鍵証明情報を階層的に
    管理するディレクトリの階層構造を受信する受信方法に
    おいて、 送信された、自分の配下の情報を格納可能なコンテナエ
    ントリに認証局情報を対応付け、上記コンテナエントリ
    の配下にあって、自分の配下の情報を格納できないリー
    フエントリにエンドエンティティ情報を対応付け、上記
    コンテナエントリと上記リーフエントリとからなるディ
    レクトリの階層構造の変化を検出した検出結果に基づき
    求められた上記ディレクトリの階層構造の変化の差分か
    らなる差分情報を受信する受信のステップと、 上記受信のステップで受信された上記差分情報に基づき
    構成されるディレクトリの階層構造を管理する管理のス
    テップと、 上記差分情報を選択的に取り込み、上記管理のステップ
    で管理される上記ディレクトリの階層構造を変更する変
    更のステップとを有し、 上記コンテナエントリおよび/または上記リーフエント
    リには、最新の公開鍵証明情報を取得可能な情報と、該
    最新の公開鍵証明情報の失効情報とが格納されて上記送
    信されることを特徴とする受信方法。
  10. 【請求項10】 公開鍵証明情報を階層的に管理するデ
    ィレクトリの階層構造を送信し、送信されたディレクト
    リの階層構造を受信する送受信システムにおいて、 自分の配下の情報を格納可能なコンテナエントリに認証
    局情報を対応付け、上記コンテナエントリの配下にあっ
    て、自分の配下の情報を格納できないリーフエントリに
    エンドエンティティ情報を対応付け、上記コンテナエン
    トリと上記リーフエントリとからなるディレクトリの階
    層構造を管理する第1の管理手段と、 上記第1の管理手段によって管理される上記ディレクト
    リの階層構造の変化を検出し、該検出結果に基づき上記
    ディレクトリの階層構造の変化の差分からなる差分情報
    を求める検出手段と、 上記検出手段で検出された上記差分情報を送信する送信
    手段と、 上記送信手段により送信された、上記差分情報を受信す
    る受信手段と、 上記受信手段により受信された上記差分情報に基づき構
    成されるディレクトリの階層構造を管理する第2の管理
    手段と、 上記差分情報を選択的に取り込み、上記第2の管理手段
    で管理される上記ディレクトリの階層構造を変更する変
    更手段とを有し、 上記コンテナエントリおよび/または上記リーフエント
    リには、最新の公開鍵証明情報を取得可能な情報と、該
    最新の公開鍵証明情報の失効情報とが格納されるように
    したことを特徴とする送受信システム。
  11. 【請求項11】 請求項10に記載の送受信システムに
    おいて、 上記失効情報は、上記公開鍵証明情報のシリアル番号で
    あることを特徴とする送受信システム。
  12. 【請求項12】 請求項10に記載の送受信システムに
    おいて、 上記コンテナエントリおよび/または上記リーフエント
    リの属性に、上記最新公開鍵証明情報および上記最新の
    公開鍵証明情報を取得するための情報のうち何れか一方
    を選択して格納可能として送信するようにしたことを特
    徴とする送受信システム。
  13. 【請求項13】 請求項12に記載の送受信システムに
    おいて、 上記検出手段により上記差分が検出された更新事象から
    の時間に応じて、上記属性に格納される情報を、上記最
    新の公開鍵証明情報と上記最新の公開鍵証明情報を取得
    するための情報との間で変更可能なようにして送信する
    ことを特徴とする送受信システム。
  14. 【請求項14】 請求項10に記載の送受信システムに
    おいて、 上記変更手段は、上記公開鍵証明情報を取得するための
    証明情報パスに対応する上記コンテナエントリおよび/
    または上記リーフエントリの更新情報を上記選択的に取
    り込むことを特徴とする送受信システム。
  15. 【請求項15】 公開鍵証明情報を階層的に管理するデ
    ィレクトリの階層構造を送信し、送信されたディレクト
    リの階層構造を受信する送受信方法において、 自分の配下の情報を格納可能なコンテナエントリに認証
    局情報を対応付け、上記コンテナエントリの配下にあっ
    て、自分の配下の情報を格納できないリーフエントリに
    エンドエンティティ情報を対応付け、上記コンテナエン
    トリと上記リーフエントリとからなるディレクトリの階
    層構造を管理する第1の管理のステップと、 上記第1の管理のステップによって管理される上記ディ
    レクトリの階層構造の変化を検出し、該検出結果に基づ
    き上記ディレクトリの階層構造の変化の差分からなる差
    分情報を求める検出のステップと、 上記検出のステップで検出された上記差分情報を送信す
    る送信のステップと、 上記送信のステップにより送信された、上記差分情報を
    受信する受信のステップと、 上記受信のステップにより受信された上記差分情報に基
    づき構成されるディレクトリの階層構造を管理する第2
    の管理のステップと、 上記差分情報を選択的に取り込み、上記第2の管理のス
    テップで管理される上記ディレクトリの階層構造を変更
    する変更のステップとを有し、 上記コンテナエントリおよび/または上記リーフエント
    リには、最新の公開鍵証明情報を取得可能な情報と、該
    最新の公開鍵証明情報の失効情報とが格納されるように
    したことを特徴とする送受信方法。
JP2000120940A 2000-04-21 2000-04-21 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法 Pending JP2001308841A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2000120940A JP2001308841A (ja) 2000-04-21 2000-04-21 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法
EP01303524A EP1148676A3 (en) 2000-04-21 2001-04-18 Transmitting and/or receiving apparatus, methods and systems using public key certificates
US09/839,872 US7136998B2 (en) 2000-04-21 2001-04-20 System and method for managing changes in a public key certificate directory

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000120940A JP2001308841A (ja) 2000-04-21 2000-04-21 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法

Publications (1)

Publication Number Publication Date
JP2001308841A true JP2001308841A (ja) 2001-11-02

Family

ID=18631677

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000120940A Pending JP2001308841A (ja) 2000-04-21 2000-04-21 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法

Country Status (3)

Country Link
US (1) US7136998B2 (ja)
EP (1) EP1148676A3 (ja)
JP (1) JP2001308841A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017188774A (ja) * 2016-04-05 2017-10-12 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030074555A1 (en) 2001-10-17 2003-04-17 Fahn Paul Neil URL-based certificate in a PKI
ATE345012T1 (de) * 2002-03-20 2006-11-15 Research In Motion Ltd Mobiler zugriff auf ldap-server
US20040268123A1 (en) * 2003-06-27 2004-12-30 Nokia Corporation Security for protocol traversal
US7315854B2 (en) * 2004-10-25 2008-01-01 International Business Machines Corporation Distributed directory replication
US7730139B2 (en) * 2005-01-10 2010-06-01 I-Fax.Com Inc. Asynchronous tamper-proof tag for routing e-mails and e-mail attachments
US20060206586A1 (en) * 2005-03-09 2006-09-14 Yibei Ling Method, apparatus and system for a location-based uniform resource locator
US7647494B2 (en) * 2005-06-08 2010-01-12 International Business Machines Corporation Name transformation for a public key infrastructure (PKI)
US8274401B2 (en) * 2006-12-22 2012-09-25 Acterna Llc Secure data transfer in a communication system including portable meters
CN104461652B (zh) * 2014-12-26 2017-11-03 珠海迈科智能科技股份有限公司 机顶盒软件更新方法及系统
US10469574B1 (en) * 2016-04-20 2019-11-05 EMC IP Holding Company LLC Incremental container state persistency and replication for containerized stateful applications
CN107508789B (zh) * 2017-06-29 2020-04-07 北京北信源软件股份有限公司 一种异常数据的识别方法和装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4309569A (en) * 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
US5666416A (en) * 1995-10-24 1997-09-09 Micali; Silvio Certificate revocation system
US6097811A (en) * 1995-11-02 2000-08-01 Micali; Silvio Tree-based certificate revocation system
US5903651A (en) * 1996-05-14 1999-05-11 Valicert, Inc. Apparatus and method for demonstrating and confirming the status of a digital certificates and other data
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US6226743B1 (en) * 1998-01-22 2001-05-01 Yeda Research And Development Co., Ltd. Method for authentication item

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017188774A (ja) * 2016-04-05 2017-10-12 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
WO2017175592A1 (ja) * 2016-04-05 2017-10-12 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置

Also Published As

Publication number Publication date
EP1148676A3 (en) 2005-12-21
US20020059519A1 (en) 2002-05-16
EP1148676A2 (en) 2001-10-24
US7136998B2 (en) 2006-11-14

Similar Documents

Publication Publication Date Title
US7383434B2 (en) System and method of looking up and validating a digital certificate in one pass
CN1681238B (zh) 用于加密通信的密钥分配方法及系统
CN110138560B (zh) 一种基于标识密码和联盟链的双代理跨域认证方法
US20070271106A1 (en) System and method for secure internet channeling agent
US20050144439A1 (en) System and method of managing encryption key management system for mobile terminals
JP2000349747A (ja) 公開鍵管理方法
EP1747636A2 (en) Method and system for secure distribution of content over a communications network
KR20040032536A (ko) 컨텐츠 제공 방법 및 시스템
KR20190134696A (ko) 신호 통신 시스템
JP2001308841A (ja) 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法
CN101341691A (zh) 授权与验证
CN111490873A (zh) 基于区块链的证书信息处理方法及系统
CN115189913B (zh) 数据报文的传输方法和装置
WO2013040957A1 (zh) 单点登录的方法、系统和信息处理方法、系统
JP3464172B2 (ja) 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法
CN112132581B (zh) 基于iota的pki身份认证系统及方法
WO2023221591A1 (zh) 一种数据传输的方法、相关装置、设备以及存储介质
JP2010510568A (ja) リソース伝送方法及び情報提供方法
CN114389878B (zh) 一种区块链分片方法及区块链网络系统
JP3215882U (ja) クラウドストレージベースのファイルアクセス制御システム
CN102714653B (zh) 用于访问私人数字内容的系统和方法
JP2009217522A (ja) 個人属性情報提供システムおよび個人属性情報提供方法
JP3429707B2 (ja) 送信装置および送信方法、受信装置および受信方法、ならびに、送受信システムおよび送受信方法
JP2000250832A (ja) 分散ディレクトリ管理システム
JP2008090628A (ja) 内部ネットワーク上の内部端末に外部ネットワーク上の外部サーバからコンテンツを取得して送信する方法、内部サーバ、及び外部サーバ