JP2005301449A - コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム - Google Patents

コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム Download PDF

Info

Publication number
JP2005301449A
JP2005301449A JP2004113459A JP2004113459A JP2005301449A JP 2005301449 A JP2005301449 A JP 2005301449A JP 2004113459 A JP2004113459 A JP 2004113459A JP 2004113459 A JP2004113459 A JP 2004113459A JP 2005301449 A JP2005301449 A JP 2005301449A
Authority
JP
Japan
Prior art keywords
content
authentication
keyword
content transmission
http
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.)
Granted
Application number
JP2004113459A
Other languages
English (en)
Other versions
JP4264650B2 (ja
Inventor
Takao Morita
隆雄 森田
Yukihiko Aoki
幸彦 青木
Shinichi Kono
真一 河野
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 JP2004113459A priority Critical patent/JP4264650B2/ja
Priority to US11/092,897 priority patent/US7627905B2/en
Publication of JP2005301449A publication Critical patent/JP2005301449A/ja
Application granted granted Critical
Publication of JP4264650B2 publication Critical patent/JP4264650B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

【課題】 ＤＴＣＰの規定に従ってサーバから複数のクライアントへコンテンツを効率的に伝送する。
【解決手段】 コンテンツ受信装置は、自身が認証済みであることを示すために、認証手続きで得られた認証情報を構成する少なくとも一部の情報を、認証済みであることを示すキーワードとして、コンテンツ要求に含めるようにする。これに対し、コンテンツ送信装置は、コンテンツ受信装置からのコンテンツ要求にかかるキーワードが含まれていることを確認した上で、暗号化コンテンツの伝送処理を行なうようにする。
【選択図】 図１

Description

本発明は、送信機器が複数の受信機器にコンテンツを伝送するコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムに係り、特に、映像や音響などのコンテンツを蓄積するサーバがクライアントからの要求に従ってコンテンツを効率的に伝送するコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムに関する。
さらに詳しくは、本発明は、コンテンツの利用を私的使用の範囲に制限しながらサーバから複数のクライアントへコンテンツを効率的に伝送するコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）の規定に従ってサーバから複数のクライアントへコンテンツを効率的に伝送するコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム関する。
複数のコンピュータ同士をネットワークで相互接続することにより、情報資源の共有や、ハードウェア資源の共有、複数のユーザ間でのコラボレーションが実現することが知られている。コンピュータ間の接続メディアとして、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどさまざまである。
最近では、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要としないこと、メディアの購入に相当するコンテンツ配信要求もネットワークを経由して遠隔で行なえることなど、物流を伴わず、簡易な手続きによりコンテンツの取得を実現することができ、低コストでしかも即時性に優れている。
一方、ネットワーク経由で取り扱われるコンテンツはデジタル・データであり、コピーや改竄などの不正な操作が比較的容易に行なわれてしまう、という問題がある。現在、コンテンツのコピーや改竄などの不正行為は頻繁に行なわれており、これがデジタル・コンテンツ・ベンダの利益を阻害する主要な要因となっている。この結果、コンテンツの値段も高くしなければならなくなり、普及の障壁となるという悪循環が起こっている。
著作権法の下、デジタル・コンテンツは著作物の１つとして、無断の複製や改竄などの不正使用から保護を受ける。著作権法第３０条では、著作物の種類や複製の態様を限定することなく、個人的に又は家庭内などで使用する目的であれば、使用する者本人が複製することができることとされている。また、同法第４９条第１項においては、私的使用のために作成した複製物をその目的以外のために使用した場合には著作権者の複製権が動く旨を規定し、いわゆる目的外使用を禁止している。
デジタル・コンテンツの利用が盛んな今日においては、その著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定し、例えばコンテンツを伝送する通信範囲とコンテンツを受信する機器の台数に制限を課している（例えば、非特許文献１を参照のこと）。
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定している。ホーム・ネットワーク経由でのコンテンツ伝送は、著作権法で言うところの個人的又は家庭の範囲内での使用であると推定される。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決めている。すなわち、コンテンツ提供元であるサーバは、コンテンツ提供先であるクライアントと認証を行ない、この認証手続きを経て共有化される鍵を用いて伝送路を暗号化し、コンテンツの伝送を行なう。したがって、ＤＴＣＰによればコンテンツを保護しながら伝送することができる。また、クライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。
また、最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークより柔軟で効率的なコンテンツの利用が図られる。
ＤＴＣＰ−ＩＰは、ＤＴＣＰをＩＰネットワークに移植した同様の技術であり、ＤＴＣＰ規格に含まれるものであるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定されたものとは相違する（前述）。ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続されており、データの盗聴、改竄が簡単に行なわれてしまうことから、ＤＴＣＰ−ＩＰではコンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。
ここで、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順ついて説明する。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。
ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや鍵が埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している鍵をＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。
そして、ＤＴＣＰ準拠の機器間で認証手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（Ｃｏｎｔｅｎｔｓ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＤＴＣＰ＿Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用することができる。ＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。また、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。なお、これらの通信手続き以外にもＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。
ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。但し、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。暗号化されたデータを受信したクライアント（ＤＴＣＰ＿Ｓｉｎｋ）は同様に、先の認証後に共有した鍵によりデータを復号し、再生若しくは記録を行なうことができる。
上述したように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴、改竄を防ぐという、安全なコンテンツ伝送手法を提供している。
ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．３ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．０ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ￥
ＤＴＣＰでは、基本的に、コンテンツ伝送時における機器間の認証プロトコルと、コンテンツの伝送プロトコルについて取り決めている。ＤＴＣＰ−ＩＰでは、認証プロトコルには、ＡＫＥを利用した認証技術と鍵共有技術をまとめたプロトコルが適用される。また、コンテンツ伝送プロトコルとして、ＩＰネットワーク上におけるコンテンツ伝送に適用可能なＨＴＴＰやＲＴＰなどが適用される
ところで、ＤＴＣＰ−ＩＰによりコンテンツを保護し伝送を行なうシステムでは、コンテンツ場所へのアクセスがＨＴＴＰで指定される場合、任意の機器がＤＴＣＰ認証をしていない状態でコンテンツ場所にＨＴＴＰを用いて直接アクセスし、暗号化されたコンテンツを取得することが可能である。何故ならば、ＤＴＣＰ−ＩＰでは、認証手続きとコンテンツ伝送手続きとをそれぞれ別個に規定しており、これらの手続きは独立した個別のＴＣＰ／ＩＰコネクションにより実行されるからである。
まずクライアントがＣＤＳやユーザからの入力により与えられたＨＴＴＰでアクセス可能なコンテンツ場所に対し、ＨＴＴＰを用いてコンテンツ取得要求を出す。サーバは、要求されたコンテンツをＤＴＣＰ−ＩＰで規定されたステップに従い暗号化してクライアントに返す。そして、ＤＴＣＰに準拠したクライアントは、ＤＴＣＰ−ＩＰで規定されたステップに従い、コンテンツを復号し再生若しくは記録などを行なう。
ここで、クライアントがＤＴＣＰに準拠していない機器である場合には、クライアントはサーバから返された暗号化済みコンテンツを受信することはできるものの、暗号鍵を共有していないため、復号して再生／記録することはできない。この場合、コンテンツは暗号化して伝送されてしまうが、伝送先のクライアントではコンテンツを利用できないので、コンテンツ自体は保護されていると言える。
しかしながら、サーバがＤＴＣＰに準拠していない機器からの多くの要求を受け付け、それに応じコンテンツを暗号化して逐次伝送することは、計算機能力と伝送に使用するネットワークの帯域を無駄に消費してしまうことになる。ＤＴＣＰ−ＩＰでは認証手続きとコンテンツ伝送手続きを別個に実行可能であり、ＤＴＣＰに準拠していない機器であってもコンテンツの要求を行なうことができる。このため、上記のコンテンツ要求がサーバに対する攻撃の一手段ともなりかねない。
このような事態は、サーバがＤＴＣＰ認証を行なった正規の機器からの要求に応じることを妨げるとともに、正規の機器に対するコンテンツ伝送の品質を低下させる要因となる。また、ＤＴＣＰに準拠していない機器への暗号化コンテンツの伝送は、結局のところ使用される当てのないデータ伝送に帰するので、帯域の無駄な利用に他ならない。
本発明は、上述したような技術的課題を鑑みたものであり、その主な目的は、映像や音響などのコンテンツを蓄積するサーバがクライアントからの要求に従ってコンテンツを効率的に伝送することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、コンテンツの利用を私的使用の範囲に制限しながらサーバから複数のクライアントへコンテンツを効率的に伝送することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、ＤＴＣＰの規定に従ってサーバから複数のクライアントへコンテンツを効率的に伝送することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することにある。
本発明のさらなる目的は、ＤＴＣＰ非準拠のクライアントからのコンテンツ要求に応じてサーバがコンテンツを暗号化し伝送することに起因する計算機能力やネットワーク帯域の浪費を排除し、コンテンツ伝送処理を効率化することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することにある。
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、コンテンツの保護を考慮しながらコンテンツ送信装置からコンテンツ受信装置へコンテンツをネットワーク経由で伝送するコンテンツ伝送システムであって、
前記コンテンツ送信装置と前記コンテンツ受信装置間で認証手続きを実行して前記の両装置間で認証情報を共有する認証手続き実行手段と、
前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ送信装置から前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行手段とを備え、
前記コンテンツ伝送手続き実行手段は、コンテンツ受信装置が認証済みであることを示すキーワードがコンテンツ要求に含まれていることを確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
ことを特徴とするコンテンツ伝送システムである。
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
ここで、前記コンテンツ送信装置及び前記コンテンツ受信装置はＤＴＣＰに準拠した装置であり、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）によりユニークな機器ＩＤや鍵が埋め込まれている。
前記認証手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間でコネクションを確立した後、ＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）により前記の両装置間の認証を行なう。
また、前記コンテンツ伝送手続き実行手段は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）、又はＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）のうちいずれかのプロトコルを用いてコンテンツ伝送を行なう。
そして、ＤＴＣＰ−ＩＰでは、前記認証手続き実行手段と前記コンテンツ伝送手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間で個別のコネクションを確立し、それぞれの手続きを互いに独立して実行するこができる。前記コンテンツ送信装置及び前記コンテンツ受信装置間では、例えばＴＣＰ／ＩＰを利用してコネクションを作成する。
このように認証手続きとコンテンツ伝送手続きを、独立した個別のＴＣＰ／ＩＰコネクションにより実行する場合、認証手続きを経ていないクライアントからもコンテンツが要求され、伝送されてしまうという問題がある。コンテンツは暗号化して伝送されるため、コンテンツ自体は保護される。ところが、コンテンツ送信装置が認証手続きを経ていない多くのコンテンツ受信装置から要求を受け、それに応じてコンテンツを暗号化し伝送することは、コンテンツ送信装置の計算機能力とネットワークの帯域の無駄となる。このため、ＤＴＣＰ認証を行なった正規のコンテンツ受信装置に対するコンテンツ伝送の品質を低下する恐れもある。例えば、認証を得ることができない不正なコンテンツ受信装置が多数のコンテンツ要求を発行することにより、計算機負荷とネットワークの帯域を浪費させるという攻撃を被りかねない。
これに対し、本発明によれば、コンテンツ受信装置は、自身が認証済みであることを示すキーワードをコンテンツ要求に含めるようにする。これに対し、コンテンツ送信装置は、コンテンツ受信装置からのコンテンツ要求にこのようなキーワードが含まれていることを確認した上で、暗号化コンテンツの伝送処理を行なうようにした。
すなわち、本発明によれば、サーバは、認証を正しく行なっていない機器からのコンテンツ要求を拒否することができるので、計算機能力とネットワークの帯域の無駄となるような暗号化コンテンツの伝送を未然に防止することができる。
ここで、認証チェックの正確さ（若しくは堅牢性又は認証処理の負荷）を表すチェック・レベルの異なる複数種類のキーワードを定義し、サーバ側の処理能力などに応じてサポートできるチェック・レベルを変更できるようにしてもよい。
例えば、キーワードを、チェック・レベルを表す識別子と、該チェック・レベルに対応したキーワード値で構成することができる。
チェック・レベルの最も低いキーワード値、すなわち堅牢性に欠けるが認証処理の負荷が軽くて済むキーワード値として、例えば、認証したかどうかを示すフラグ、又は前記コンテンツ送信装置及び前記コンテンツ受信装置において既知である任意の文字列を用いることができる。この種のキーワードの認証処理は演算負荷が軽くて済む。
次にチェック・レベルが高いキーワード値として、前記認証手続き実行手段により得られた前記認証情報を構成する少なくとも一部の情報に基づいて作成されるものが使用される。
ＤＴＣＰ−ＩＰに基づく認証手続きでは、認証情報は、ネットワーク上を伝送して共有される公開情報と、ネットワーク上を伝送しないで共有される秘匿情報を含む。コンテンツ要求に含めるキーワード値を前記認証情報に含まれる公開情報に基づいて作成することができる。
あるいは、キーワード値を、前記認証情報に含まれる秘匿情報に基づいて作成するようにしてもよい。但し、元の情報の秘匿性を確保するために、秘匿情報をメッセージ・ダイジェストに変換してからキーワードの作成に使用することが好ましい。この場合、コンテンツ受信装置が認証済みであるかどうかを確認するための処理負荷は重くなるが、認証チェックの正確さ、すなわち堅牢性は向上する。
また、キーワード値を、前記認証情報に含まれる公開情報及び秘匿情報を組み合わせたデータ、又は公開情報及び秘匿情報を加工したデータで構成するようにしてもよい。
また、本発明に係るコンテンツ伝送システムは、例えば、ＨＴＴＰベースで構築することができる。すなわち、前記コンテンツ受信装置はＨＴＴＰを用いてコンテンツを要求するクライアント装置であり、前記コンテンツ送信装置はＨＴＴＰを用いてコンテンツを送信するサーバ装置である。
このような場合、前記コンテンツ受信装置は、ＨＴＴＰリクエスト中にキーワードを組み込み、前記コンテンツ送信装置は、ＨＴＴＰリクエスト中からキーワードを抽出して、キーワードの正否により前記コンテンツ受信装置が認証済みであるかどうかを判別することができる。
また、前記の認証済みであることを示すキーワードは、前記コンテンツ送信装置と前記コンテンツ受信装置が共有する前記認証情報、ＨＴＴＰのダイジェスト認証情報、及びその他の属性を持つ情報から生成することができる。そして、前記コンテンツ送信装置と前記コンテンツ受信装置において同じ属性を持つ情報を用いてそれぞれ生成された値が同一であるかどうかを基にコンテンツ受信装置が認証済みであるかどうかを確認することができる。
また、前記コンテンツ受信装置は、ＨＴＴＰリクエストのリクエストＵＲＩのクエリ文字列部分、あるいはヘッダ部分などにキーワードを組み込むことができる。
また、前記認証手続き実行手段により得られる認証情報を用いて作成されるデータをＨＴＴＰダイジェスト認証時のＡｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表したものを、認証済みであることを示すキーワードとして使用することができる。この場合、キーワードの識別子をＡｕｔｈｅｎｔｉｃａｔｉｏｎ、キーワードの値をＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダ・フィールド値とみなす。ＨＴＴＰダイジェスト認証の枠組みにおいて、Ａｕｔｈｅｎｔｉｃａｔｉｏｎヘッダに含まれるユーザ名とレスポンス値により既に認証したクライアントかどうかを判別することができる。ユーザ名にはクライアントの機器ＩＤなどのＤＴＣＰ認証で使用される公開された値を指定し、レスポンス値にはパスワードとして認証後にサーバと共有している秘匿情報を使用して生成した値を指定する。このようにして生成されたレスポンス値はサーバでも同様に生成することができ、クライアントから送られた値をサーバで生成した値と比較することでキーワードの有効性を確認することができる。
また、前記コンテンツ受信装置は、キーワードの値がバイナリ形式である場合には、該値を文字列データに変換してＨＴＴＰリクエストのヘッダ部分に組み込むようにしてもよい。
また、前記コンテンツ受信装置は、ＨＴＴＰリクエスト中に複数のキーワードを同時に組み込むようにしてもよい。例えば、認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義されているが、サーバとしてのコンテンツ送信装置側でサポートしているチェック・レベルが不明な場合には、各チェック・レベルに応じた複数のキーワードを作成し、ＨＴＴＰリクエストに組み込んでコンテンツ要求を行なうようにしてもよい。
また、前記コンテンツ送信装置は、受信したＨＴＴＰリクエスト中に自分がサポートするチェック・レベルのキーワードが含まれていない場合には、該チェック・レベルを埋め込んだＨＴＴＰエラー・レスポンスを返すようにしてもよい。
これに対し、前記コンテンツ受信装置は、ＨＴＴＰエラー・レスポンスで指定されているチェック・レベルのキーワードを組み込んだコンテンツ要求をまだ行なっていない場合には、コンテンツ要求を再試行するようにしてもよい。
また、前記コンテンツ送信装置は、ＨＴＴＰリクエスト中に複数のキーワードが組み込まれている場合には、自分がサポートするチェック・レベルに合致するもののうち最も高いチェック・レベルのキーワードを用いてその有効性の確認を行なうようにしてもよい。
また、前記コンテンツ送信装置は、ＨＴＴＰリクエストによりコンテンツを要求してきたコンテンツ受信装置のＩＰアドレスが前記認証手続き実行手段により得られた認証情報に含まれるか否かをチェックするようにしてもよい。
また、本発明の第２の側面は、コンテンツの保護を考慮しながらコンテンツ受信装置へコンテンツをネットワーク経由で伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
前記コンテンツ受信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行ステップと、
前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行ステップとを備え、
前記コンテンツ伝送手続き実行ステップでは、コンテンツ要求に含まれているコンテンツ受信装置が認証済みであることを示すキーワードの有効性を確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
ことを特徴とするコンピュータ・プログラムである。
また、本発明の第３の側面は、コンテンツの保護を考慮しながらネットワーク経由で伝送されるコンテンツを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
前記コンテンツ送信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行ステップと、
前記コンテンツ受信装置が認証済みであることを示すキーワードを含んだコンテンツ要求を発行するとともに、該コンテンツ要求に応答して伝送される暗号化コンテンツを受信処理するコンテンツ伝送手続き実行ステップと、
ことを特徴とするコンピュータ・プログラムである。
本発明の第２及び第３の各側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２及び第３の各側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、それぞれコンテンツ送信装置及びコンテンツ受信装置として動作し、両装置間の協働的動作によりコンテンツ伝送が行なわれることにより、本発明の第１の側面に係るコンテンツ伝送システムと同様の作用効果を得ることができる。
本発明によれば、コンテンツの利用を私的使用の範囲に制限しながらサーバから複数のクライアントへコンテンツを効率的に伝送することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することができる。
また、本発明によれば、ＤＴＣＰの規定に従ってサーバから複数のクライアントへコンテンツを効率的に伝送することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することができる。
また、本発明によれば、ＤＴＣＰ非準拠のクライアントからのコンテンツ要求に応じてサーバがコンテンツを暗号化し伝送することによる計算機能力やネットワーク帯域の浪費を排除し、コンテンツ伝送処理を効率化することができる、優れたコンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラムを提供することができる。
本発明では、ＤＴＣＰ認証を完了したクライアントか否かを示すためにキーワードと呼ばれる情報を使用する。
ここで、キーワードには、認証したかどうかを示すフラグであるだけのものから、認証時に交換した公開パラメータから作成するもの、さらには認証時に共有した秘匿パラメータから作成するものまである。また、秘匿パラメータからキーワードを作成する場合、この秘匿パラメータをメッセージ・ダイジェストに変換してから使用することにより、元のパラメータの秘匿性は確保される。
いずれをキーワードとして使用するかによって、改竄などの不正な操作に対する堅牢性と、認証処理に要する能力が変わる。本発明では、堅牢性及び処理負荷に応じて、複数のチェック・レベルからなるキーワードを定義している。チェック・レベルの高い複雑なキーワードを生成するには、サーバの性能がより高く要求される。
本発明では、サーバ側の処理能力などに応じてサポートできるチェック・レベルを変更できるようにした。すなわち、低い性能のサーバから高い性能のサーバまで対応できるようにキーワードを幾つかの段階に分けているので、サーバの仕様若しくはサーバの負荷状況に応じて、キーワードのチェック・レベルを変更するだけでサーバの能力に見合った適切な効果を期待することができる。
また、本発明に係るコンテンツ伝送システムは、ＤＴＣＰ−ＩＰ及びＨＴＴＰに準拠している。したがって、規格の拡張や変更がないため、本発明を実現するに際し開発コストを低く見積もることが可能である。また、本発明に対応していない機器との運用でも規格に準じた処理を行なうことが可能である。
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
以下では、図面を適宜参照しながら、ＤＴＣＰに準拠したサーバ機器がＤＴＣＰに準拠したクライアント機器に暗号化コンテンツを伝送する場合を例にとって、本発明に係るコンテンツ伝送システムの実施形態について詳解する。
ＤＴＣＰに準拠したサーバ機器は、任意のクライアントからのＨＴＴＰによるコンテンツ伝送要求を受理するに際し、ＨＴＴＰのリクエストを解析する。本実施形態では、クライアントからの伝送要求にＤＴＣＰ認証時に生成されるパラメータを含めて、伝送要求を発行する。このようにすると、伝送要求を受理したサーバが伝送要求元のクライアントが既にＤＴＣＰ認証をした相手であるかどうかを判別し、ＤＴＣＰ認証済みのクライアントにはＤＴＣＰ−ＩＰのステップにより暗号化されたコンテンツを返し、ＤＴＣＰ認証をしていないクライアントにはＨＴＴＰエラー・レスポンスを返す。
本実施形態では、サーバ機器は、認証を行なっていない機器からのコンテンツ要求を拒否することができるので、処理負荷とネットワーク帯域負荷の不要な増大を防止することができる。
具体的には、クライアントはＨＴＴＰでコンテンツを要求する際にＨＴＴＰリクエストにキーワードを入れてコンテンツを要求し、サーバはそのキーワードをチェックするという機構を提供する。この機構によれは、サーバは、コンテンツを要求してきたクライアントが既にＤＴＣＰ認証をした機器であるかどうかを、コンテンツ要求の処理時に判断することができる
ここで、クライアントが認証済みであるかどうかの判断に使用されるキーワードは、例えば、認証チェックの正確さが異なる５種類のレベルに分類されている。認証チェックの正確さが高ければ、キーワードの堅牢性は高くなるが、その分だけ認証チェックの処理負荷が増大する。逆に、認証チェックの正確さが低ければ、認証チェックの処理負荷は軽減されるが、その分だけキーワードの堅牢性が低くなる。どのレベルのキーワードを取り扱うかはサーバ機器がその能力に従い指定することができる。
正しくＤＴＣＰ認証をしたクライアントは、サーバが対応するレベルのキーワードを含めてコンテンツを要求する。クライアントがＤＴＣＰ認証は完了しているが送出したキーワードが合致しなかった場合、若しくは、クライアントがＤＴＣＰ認証は完了しているがサーバの対応するキーワードのレベルが判らず実験的にいずれかのキーワードを送るかキーワードを付けずに送りサーバのキーワードと合致できなかった場合には、サーバからはＨＴＴＰエラー・レスポンスが返される。このとき、ＨＴＴＰエラー・レスポンスにはサーバが対応するキーワードレベルが示される。したがって、クライアントは該当するレベルのキーワードを送り直すことでコンテンツの要求を再試行することができる。
このように、本発明によれば、サーバはＤＴＣＰに準拠した機器に対してのみコンテンツの暗号化と伝送を行なえばよいようになることから、暗号化と伝送に関わるサーバの処理負荷及び伝送に使用する通信帯域の総和を低減することができる。また、ＤＴＣＰ認証の有効性を確認するためのチェック・レベルは段階的に分かれているので、使用するサーバ機器の能力により指定することが可能である。
図１及び図２には、本発明に係るコンテンツ伝送システムにおいて動作するクライアント機器及びサーバ機器の機能構成をそれぞれ模式的に示している。クライアント機器とサーバ機器は、インターネットなどの図示しないＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
これらクライアント機器及びサーバ機器は、専用のハードウェア装置として設計・製作することもできるが、例えばパーソナル・コンピュータなどの一般的なコンピュータ・システム上に所定のクライアント・アプリケーション及びサーバ・アプリケーションをインストールし起動するという形態でも実現することができる。
図１に示すクライアント機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｉｎｋとして動作する。図示のクライアント機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。
ＤＴＣＰ−ＩＰ認証ブロックは、認証手続き実行手段に相当し、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。
メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。
メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵を用いて復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。
コンテンツ再生／記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。
ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、コンテンツ伝送手続き実行手段に相当し、ＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。
ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックへ分かれる。
ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりサーバへ送信される。
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをコンテンツ復号ブロックへ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
図２に示すサーバ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｏｕｒｃｅとして動作する。サーバ機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。
ＤＴＣＰ−ＩＰ認証ブロックは、認証手続き実行手段に相当し、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＤＴＣＰ＿Ｓｉｎｋ機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。
表１には、ＡＫＥブロックにおいて認証された機器に関して保持される情報すなわち認証情報の一部を示している。認証情報は、当該サーバ機器と、ＡＫＥブロックを介して認証が行なわれたそれぞれのクライアント機器（ＤＴＣＰ＿Ｓｉｎｋ）との間で共有される。同表中で示す公開性フィールドでは、各パラメータが取得可能かどうかを示している。すなわち、認証情報は、公開情報と秘匿情報とに大別される。公開情報は、ＴＣＰ／ＩＰネットワークを往来することでクライアント機器との間で共有が果たされる情報である。また、秘匿情報は、ＴＣＰ／ＩＰネットワークを往来することなく、公開情報や機器に埋め込まれている固有の情報に対して所定の演算処理を施すことでクライアント機器との共有が果たされる情報である。例えば、認証鍵Ｋauthや、伝送コンテンツを暗号化するコンテンツ鍵Ｋxは秘匿情報に相当する。
Figure 2005301449
メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。
メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じて、コンテンツ管理ブロックより読み出したコンテンツ・データをＡＫＥで交換した鍵を用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。
コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、コンテンツ伝送手続き実行手段に相当し、ＨＴＴＰサーバ・ブロックを持ち、ＨＴＴＰサーバとしてクライアントからのリクエストを受理し要求に応じた処理を実行する。
ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。
ＨＴＴＰリクエスト受信ブロックは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。
ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。
ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、暗号化コンテンツを送信する。
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、クライアント機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
本実施形態に係るコンテンツ伝送システムでは、ＤＴＣＰ認証を完了したクライアントがＨＴＴＰにてコンテンツを要求する際に、要求時に発行するＨＴＴＰリクエストに特別なキーワードを挿入する。
ここで言うキーワードは、クライアント自身がＤＴＣＰ認証を完了したことを示す認証したかどうかを示すフラグ、又は特別な文字列などで構成される。キーワードは、例えば、ＤＴＣＰ認証手続きによりサーバとクライアント間で共有される認証情報（表１）に含まれる公開情報及び秘匿情報を組み合わせたデータ、又は公開情報及び秘匿情報を加工したデータからなる。ここで言う加工とは、例えばＭＤ５やＳＨＡ−１などのアルゴリズムを用いて元の情報をメッセージ・ダイジェストに変換することを指す。例えば、秘匿情報をメッセージ・ダイジェストに変換することにより、公開情報として扱い、キーワードの作成に使用することができる。
また、本実施形態では、キーワードに、認証チェックの正確さが異なるチェック・レベルを定義している。チェック・レベルが高ければ、キーワードの堅牢性は高まり認識チェックがより正確となるが、その分だけ認識チェックの処理負荷が増大する。これに対し、チェック・レベルが低ければ、認識チェックの処理負荷は軽減されるが、堅牢性が失われ、認識チェックの正確さが低くなる。
クライアントは、コンテンツを要求するＨＴＴＰリクエストに、同時に複数個のキーワードを挿入しても構わない。キーワードはキーワードの種類を表す識別子とそれに対応する値からなり、ＨＴＴＰのリクエストＵＲＩのクエリ文字列若しくはＨＴＴＰリクエスト・ヘッダとして挿入する（後述）。
サーバ側では、ＨＴＴＰリクエストに挿入されているキーワードを受理した場合、その比較照合を行なうことにより、キーワードの有効性を確認する。例えば、元データに加工（メッセージ・ダイジェストへの変換など）が施されている複数のキーワードが挿入されている場合には、このうちサーバが対応可能なキーワードがあれば、サーバ側でも同じ属性を持つデータを用いて同様にキーワードを作成し、比較照合することでその有効性を確認する。また、チェック・レベルの相違する複数個のキーワードがリクエストに含まれていた場合には、サーバはサーバが対応する最も高いチェック・レベルのキーワードを選択し、サーバで生成したキーワードと比較照合することで、より正確な認証チェックを行なうようにする。
キーワードの比較照合によりキーワードの有効性が確認されたならば、サーバは、コンテンツの伝送を開始する。一方、リクエストに挿入されているキーワードが、サーバが対応していないキーワードであったり、キーワードが合致していなかったりした場合、あるいはリクエスト中にキーワードが挿入されていない場合には、サーバはコンテンツの伝送をせず、代わりにＨＴＴＰエラーを返す。このＨＴＴＰエラー・レスポンスの中に、サーバが対応するキーワードの種類を記述するようにする。サーバが対応するキーワードの種類をクライアントに通知することで、クライアントは適切なキーワードを生成し、再度コンテンツを要求することができる。
クライアントが生成しＨＴＴＰリクエストに挿入するキーワードは、ステップの容易さ及びその元となるデータを保護する目的のためにより、５つのチェック・レベルが定義されている。
最も低いチェック・レベルのキーワードをレベル１と定義し、それは既にＤＴＣＰ認証を完了していることを直接的に記述したキーワードで、クライアントが認証をした後のコンテンツ要求中に挿入される。このキーワードは、値として空文字列を含む任意の文字列を指定する。図３及び図４には、レベル１のキーワードをＨＴＴＰリクエストのクエリ文字列及びオプション・ヘッダとして挿入した例をそれぞれ示している。図示の例では、レベル１のキーワードの識別子はＸ−ＤＴＣＰ−ＡＵＴＨ−ＥＮＤＥＤという文字列で示されている。また、このキーワードの値をｔｒｕｅという文字列にしている。このキーワードがＨＴＴＰリクエスト中に存在すれば認証が完了していることを示し、キーワードがサーバになければ認証が完了していないことを示す。
次に高いチェック・レベルのキーワードをレベル２と定義する。レベル２のキーワードは、識別子がＸ−ＤＴＣＰ−ＡＵＴＨ−ＩＮＦＯという文字列で示され、値としてＤＴＣＰ認証で使用される情報を使用する。図５及び図６には、レベル２のキーワードをＨＴＴＰリクエストのクエリ文字列若しくはオプション・ヘッダに挿入した例をそれぞれ示している。但し、図中の文字列ＸＸＸはＤＴＣＰ認証時に共有された公開情報を基に作成された値を示し、認証時の公開情報そのものであったり、又はそれらを連結させたり組み合わせたり、その他加工したりしたデータで、サーバとクライアントで値の比較が一致させることができる値である。例えば、レベル２のキーワードは、図７に示すように、認証情報に含まれるＡＫＥ＿ｌａｂｅｌとＤＴＣＰ＿Ｓｉｎｋ機器ＩＤのメッセージ・ダイジェストを連結したもので構成することができる。但し、本明細書では実際の値の具体的な生成方法については言及せず、ＤＴＣＰ認証時に交わされる公開された値を用いてデータを作成し、その値をコンテンツ伝送の要求に使用することに関して説明するものとする。
チェック・レベル２のキーワード値の生成に使用されるパラメータは、ＤＴＣＰ認証時に交換され、クライアントとサーバ認識できる公開パラメータとする。
なお、本明細書で言う「メッセージ・ダイジェスト」の定義は、「ハッシュ値」とほぼ同意であり、あるデータを元に不可逆な一方向関数を用いて生成されたデータを意味する。すなわち、メッセージ・ダイジェスト変換により生成されたデータからは元のデータを推測することはできないが、元のデータと生成されたデータは１対１の関係を持つ（以下同様）。
次に高いチェック・レベルのキーワードをレベル３と定義する。レベル３のキーワードは、識別子がＸ−ＤＴＣＰ−ＤＩＧＥＳＴ−ＭＤ５という文字列で示され、値としてＤＴＣＰ認証で交わされた秘匿パラメータを使用する。ここで言う秘匿情報若しくは秘匿パラメータとは、認証コネクション上に生の形式で通信されることがなく、ＤＴＣＰ＿Ｓｉｎｋ機器とＤＴＣＰ＿Ｓｏｕｒｃｅ機器において認証後に値を共有しているパラメータである。例えば、ＫauthやＫxなどのパラメータが挙げられる。図８及び図９には、レベル３のキーワードをＨＴＴＰリクエストのクエリ文字列若しくはオプション・ヘッダに挿入した例をそれぞれ示している。図中で示す文字列ＹＹＹは、前記の秘匿パラメータを表す文字列データで、秘匿パラメータそのもの若しくはそれらを組み合わせ加工したものに対してＭＤ５と呼ばれるハッシュ・アルゴリズムにて作成したメッセージ・ダイジェスト・データである。秘匿パラメータは公開してはならないパラメータなので、メッセージ・ダイジェストに変換して公開（すなわちネットワーク伝送）可能とする。そして、これらに関するメッセージ・ダイジェストをサーバに送り、サーバでも同様のメッセージ・ダイジェストを生成することで秘匿パラメータの一致によりキーワードの有効性を確認することができる。但し、本明細書では、実際の値を生成するための秘匿パラメータの選択や加工には言及せず、ＤＴＣＰ認証時に交わされた秘匿パラメータをＭＤ５アルゴリズムに適用しメッセージ・ダイジェストを求め、その値をコンテンツ伝送の要求に使用することに関して説明するものとする。
次に高いチェック・レベルのキーワードをレベル４と定義する。レベル４のキーワードは、識別子がＸ−ＤＴＣＰ−ＤＩＧＥＳＴ−ＳＨＡ−１という文字列で示され、値としてＤＴＣＰ認証で交わされた秘匿パラメータを使用する。図１０及び図１１にはレベル４のキーワードをＨＴＴＰリクエストのクエリ文字列若しくはオプション・ヘッダに挿入した例をそれぞれ示している。図中で示す文字列ＺＺＺは秘匿パラメータを表す文字列データで、秘匿パラメータそのもの若しくはそれらを組み合わせ加工したものに対してＳＨＡ−１と呼ばれるハッシュ・アルゴリズムにて作成したメッセージ・ダイジェスト・データである。但し、本明細書では、実際の値を生成するための秘匿パラメータの選択や加工には言及せず、ＤＴＣＰ認証時に交わされた秘匿パラメータをＳＨＡ−１アルゴリズムに適用しメッセージ・ダイジェストを求め、その値をコンテンツ伝送の要求に使用することに関して説明するものとする。
次に高いチェック・レベルのキーワードをレベル５と定義する。レベル５のキーワードは、ＨＴＴＰダイジェスト認証を利用することで実現され、ＨＴＴＰダイジェスト認証に使用されるＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダとして送信される。この場合、キーワードの識別子をＡｕｔｈｅｎｔｉｃａｔｉｏｎ、キーワードの値をＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダ・フィールド値とみなす。ＨＴＴＰのダイジェスト認証では、クライアントからの要求に対し、サーバからのチャレンジ値がクライアントへ送られる。クライアントでは受理したチャレンジ値とクライアントのユーザ名、そのユーザのパスワードなどを基に作成したレスポンスを伴いＨＴＴＰリクエストを発行すると、サーバでも同様にレスポンスを作成し、２つのレスポンスを比較することで認証の成否を決定することができる。レベル５のキーワードを用いる手法では、ＨＴＴＰダイジェスト認証の枠組みにおいて、Ａｕｔｈｅｎｔｉｃａｔｉｏｎヘッダに含まれるユーザ名とレスポンス値により既に認証したクライアントかどうかを判別する。ユーザ名にはクライアントの機器ＩＤなどのＤＴＣＰ認証で使用される公開された値を指定し、レスポンス値にはパスワードとして認証後にサーバと共有している秘匿パラメータ（Ｋauth若しくはＫxなど）を使用して生成した値を指定する。このようにして生成されたレスポンス値はサーバでも同様に生成することができ、クライアントから送られた値をサーバで生成した値と比較することができる。
図１２には、ＨＴＴＰダイジェスト認証を利用してレベル５のキーワードをサーバへ転送している例を示している。図示の例では、ユーザ・ネームとして認証時に交換したクライアントの機器ＩＤ“ＤＥＶＩＣＥ＿ＩＤ”を指定している。また、レスポンス値として“ＳＥＣＲＥＴ＿ＰＡＲＡＭ＿ＩＮＣＬＵＤＥＤ＿ＡＳ＿ＰＡＳＳＷＯＲＤ”を指定している。ＳＥＣＲＥＴ＿ＰＡＲＡＭ＿ＩＮＣＬＵＤＥＤ＿ＡＳ＿ＰＡＳＳＷＯＲＤは、認証終了後に共有されている秘匿パラメータをユーザ・ネームＤＥＶＩＣＥ＿ＩＤに対応するパスワードを用いて生成されたＨＴＴＰダイジェスト認証のメッセージ・ダイジェストｒｅｓｐｏｎｓｅ−ｄｉｇｅｓｔである。その他の“…”となっている項目は、通常のＨＴＴＰダイジェスト認証で使用される値が挿入される。チェック・レベル５のキーワード比較は、ＨＴＴＰダイジェスト認証を利用して行なっているので、通常のＨＴＴＰダイジェスト認証と明示的に区別したい場合はＸ−ＤＴＣＰ−ＡＵＴＨ−ＨＴＴＰというオプション・ヘッダを付ける、あるいはＸ−ＤＴＣＰ−ＡＵＴＨ−ＨＴＴＰというクエリ文字列をリクエストＵＲＩに付与することも可能である。
但し、本明細書では、実際のｒｅｓｐｏｎｓｅ−ｄｉｇｅｓｔ値を生成するための認証に使用したパラメータの選択や加工には言及せず、ＤＴＣＰ認証時に交わされた公のパラメータをユーザ・ネームとし、秘匿パラメータをユーザ・ネームに対応するパスワードとし、ＨＴＴＰダイジェスト認証を行なうことに関して説明するものである。
チェック・レベル３、４、及び５でキーワードの値の元として使用されるパラメータは、ＤＴＣＰ認証時に共有されている秘匿情報とする。チェックをより強固なものにするために、公開情報を組み合わせても構わない。
なお、図４、図６、図９、図１１に示したように、ＨＴＴＰヘッダにキーワードを挿入する実施形態においては、キーワードの値データがバイナリデータである場合は、例えば１６進数のアスキー文字列表現など元のデータに戻すことのできる文字列形式に変換して送信する。
ここで、各チェック・レベルにおける性能面及び安全性面について、以下で考察する。
チェック・レベル１のキーワードは、クライアントがコンテンツを要求するときに自分がＤＴＣＰ認証を完了しているクライアントだと表示するだけのものである。チェック・レベル１をサポートするサーバはクライアントからの要求内にキーワードがあるかないかをチェックをする。非常に簡潔な処理であるが、どのクライアントでもＨＴＴＰリクエスト・ヘッダに同様のオプションを付加すればこのチェックをクリアできるので安全性面は低い。但し、クライアントがＨＴＴＰリクエスト・ヘッダを任意に付けることができない、例えば、ウェブ・ブラウザやサーチ・エンジン・ロボットからの無駄なアクセスを拒否することに対して、十分な効果がある。また、認証情報を保持することができないサーバに適している。
チェック・レベル２のキーワードは、公開された認証情報をリクエスト中に含めることでチェック・レベル１よりも詳細なチェックが可能となる。例えば、キーワードに認証セッションを識別する情報（例えばＡＫＥ＿ｌａｂｅｌ）を加えた場合、サーバは、クライアントのＩＰアドレスと認証セッションの組み合わせを調べることで、本当にそのクライアントが認証を完了しているかどうかを判断することができる。
チェック・レベル３のキーワードは、ＤＴＣＰ認証が終了しないと共有できない秘匿情報のメッセージ・ダイジェストで構成される。メッセージ・ダイジェストを生成するのに、チェック・レベル３では、ＭＤ５アルゴリズムを使用する。サーバ側では、正しい値が送られてくれば、認証も正しく行なわれているとみなすことができる。使用する秘匿情報が認証セッションに依存する場合、すなわち認証セッション毎に秘密情報が異なる場合には、その秘匿情報を送るときは認証セッションを伴う公開情報を組み合わせても良い。また、さらに認証セッションを識別する情報（例えばＡＫＥ＿ｌａｂｅｌ）を加えてキーワードを構成するようにした場合には、サーバは、クライアントのＩＰアドレスと認証セッションの組み合わせを調べることで、本当にそのクライアントが認証を完了しているかどうかを何段することができる。
チェック・レベル４のキーワードは、使用するものとのデータの属性はチェック・レベル３と同様でよいが、メッセージ・ダイジェストを作成するアルゴリズムとしてＳＨＡ−１を使用する。ＳＨＡ−１は、ＭＤ５アルゴリズムよりも情報量が多く強固なアルゴリズムである（周知）。したがって、チェック・レベル４の方がチェック・レベル3よりも堅牢である。
チェック・レベル５のキーワードは、ＨＴＴＰのダイジェスト認証として実現される。チェック・レベル１〜４では、コンテンツの要求をしたＨＴＴＰリクエストに追加したキーワードが盗聴され、他人に同じキーワードが使用された場合、サーバは正しいキーワードとして判断してしまう可能性がある。クライアントがコンテンツを要求してきたときのＩＰアドレス及び認証情報から、接続してきた端末かどうかを識別することが可能であるが、同じＩＰアドレスの装置上からの不正アクセス、若しくはＩＰアドレスを偽ってのアクセスに対して、その正当性を識別することができない。これに対し、ＨＴＴＰのダイジェスト認証で行なわれるチャレンジ・レスポンス方式を取り入れることにより、リプレイ攻撃を回避することが可能となる。この場合、クライアントは、サーバから受理したチャレンジ値と自らのユーザ・ネームとパスワードで、正しいサーバとクライアントでしか生成できない情報を共有する。ユーザ・ネームにはＤＴＣＰ認証時の公開情報、例えばＡＫＥ＿ｌａｂｅｌや機器ＩＤなどを使用する。また、パスワードにはＤＴＣＰ認証時の秘匿情報と場合によっては公開情報との組み合わせ、及びサーバから送られてくるチャレンジ値などでメッセージ・ダイジェストを作成した値が代入される。サーバからのチャレンジ値は毎回の要求時に変化するので、作成されるメッセージ・ダイジェスト値も毎回変化し、結果としてリプレイ攻撃への耐性があり、また、パスワードから元の秘密情報を特定することが困難になる。チェック・レベル５は、ＨＴＴＰのフレームワークとＤＴＣＰ認証のパラメータを組み合わせることで実現される。
各チェック・レベルにおけるキーワードの生成素材と生成方法について、以下の表にまとめておく。
Figure 2005301449
クライアントは、コンテンツを要求するときに、一度の要求で複数のキーワードを送ることができる。図１３には、レベル３とレベル４の２つのキーワードを指定してコンテンツを要求している例を示している。図示の例では、ＭＤ５により生成されたメッセージ・ダイジェストからなるレベル３のキーワードＹＹＹと、ＳＨＡ−１により生成されたメッセージ・ダイジェストからなるレベル４のキーワードＺＺＺがともにＨＴＴＰリクエストのヘッダ部に挿入されている。
チェック・レベル３、４、５で生成されるメッセージ・ダイジェストは、ＤＴＣＰ−ＩＰ準拠クライアント及びＤＴＣＰ−ＩＰ準拠サーバにおけるＤＴＣＰ−ＩＰ認証ブロック内のメッセージ・ダイジェスト生成ブロックで生成される。メッセージ・ダイジェスト生成ブロックでは、ＡＫＥで交わされた秘匿パラメータをＡＫＥブロックから取得することができ、そのパラメータからメッセージ・ダイジェストを生成する。
本実施形態では、チェック・レベル３、４のメッセージ・ダイジェスト・アルゴリズムとしてＭＤ５及びＳＨＡ−１を使用しているが、本発明の要旨はこれに限定されるものではなく、これら以外のメッセージ・ダイジェスト・アルゴリズムを適用してもキーワードを新しく定義することで対応することができる。
また、チェック・レベル５におけるＨＴＴＰのダイジェスト認証で指定されたメッセージ・ダイジェスト・アルゴリズムとメッセージ・ダイジェスト生成ブロックで使用可能なメッセージ・ダイジェスト・アルゴリズムが異なる場合には、メッセージ・ダイジェスト生成ブロックにて生成したメッセージ・ダイジェストをＨＴＴＰクライアント・ブロック又はＨＴＴＰサーバ・ブロックに渡し、その後ＨＴＴＰのダイジェスト認証で指定されたメッセージ・ダイジェスト・アルゴリズムに適用することで、同様の効果を得ることができる。
認証が完了していないクライアントがコンテンツを要求した場合、認証を完了したクライアントが認証済みを表すキーワードを付けずにコンテンツを要求した、若しくは不正なキーワードを付けてコンテンツを要求した場合、あるいはクライアントが送ってきたキーワードをサーバがサポートしていなかった場合などでは、要求を受理したサーバは、このような要求を却下し、エラー・レスポンスを返す。このとき、サーバは、自分がサポートしているキーワードのチェック・レベルを返すようにする。
図１４及び図１５には、チェック・レベル１〜４のいずれかのキーワードをサポートしているサーバが返すＨＴＴＰレスポンスの構成例を示している。
図１４に示す例では、コンテンツ要求を拒否するＨＴＴＰレスポンスのＸ−ＤＴＣＰ−ＡＵＴＨ−ＬＥＶＥＬヘッダにてサポートしているキーワードのチェック・レベルを示している。
また、図１５に示す例では、コンテンツ要求を拒否するＨＴＴＰレスポンスにおいて、キーワードの識別子をＨＴＴＰオプション・ヘッダとし、空の値を伴って含め、サポートしているキーワードのチェック・レベルを示している。
また、図１６及び図１７には、チェック・レベル５をサポートするサーバがサポートするレベルを通知するＨＴＴＰレスポンスの構成例を示している。チェック・レベル５をサポートする場合はＨＴＴＰダイジェスト認証に基づくため、ステータス・コードが４０１となり、ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダをクライアントに返す必要がある。ＷＷＷ−Ａｕｔｈｅｎｔｉｃａｔｅヘッダの内容は、通常のＨＴＴＰダイジェスト認証と同じである。
ＨＴＴＰレスポンスを受け取ったクライアントは、ステータス・コード４０１を参照して、ダイジェスト認証が要求されていることを検出する。そして、要求されているチェック・レベルのキーワードを生成し、ＨＴＴＰレスポンスで指定されているダイジェスト認証パラメータを使用して、Ａｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表して、改めてＨＴＴＰリクエストを送信しコンテンツ要求を再試行することができる。
次に、ＤＴＣＰ−ＩＰ準拠クライアント（ＤＴＣＰ＿Ｓｉｎｋ／ＨＴＴＰクライアント）とＤＴＣＰ−ＩＰ準拠サーバ（ＤＴＣＰ＿Ｓｏｕｒｃｅ／ＨＴＴＰサーバ）の動作について詳解する。
ここでは、ＤＴＣＰ−ＩＰ準拠クライアントとＤＴＣＰ−ＩＰ準拠サーバは既に認証を完了していることを前提とし、コンテンツを伝送するステップから説明する。但し、ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信・受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行することから、コンテンツ伝送ステップの開始時にＤＴＣＰ認証手続きが完了していることは必須ではなく、コンテンツ伝送ステップと並行して、あるいはその途上で認証手続きを行なうようにしてもよい。
図１８には、クライアントが認証を完了した後にコンテンツを要求するための処理手順をフローチャートの形式で示している。この処理手順は、クライアント内のＤＴＣＰ−ＩＰ受信ブロックが主体となって実行される。以下、同図を参照しながら、この処理手順について詳解する。
まず、クライアントは、サーバがサポートしているチェック・レベルを未知にセットする（ステップＳ１）。但し、サーバがサポートしているチェック・レベルをあらかじめ知っている場合には、その値にセットしても構わない。
次いで、クライアントは、サーバに対しコンテンツを要求するためのＨＴＴＰリクエストを作成する（ステップＳ２）。
次いで、先行ステップＳ２により作成されたＨＴＴＰリクエストにキーワードを付与するかどうかを判断する（ステップＳ３）。ここで、キーワードを追加する場合は次ステップＳ４へ状態が遷移し、キーワードを追加しない場合にはステップＳ６へ状態が遷移する。
ステップＳ４では、クライアントが生成可能なキーワードのチェック・レベル群とサーバがサポートしているキーワードのチェック・レベル群の重複しているレベルのキーワードを生成する。ここで、重複しているレベルが複数あれば、複数個のキーワードを生成する。また、サーバがサポートしているキーワードのレベルが未知の場合には、クライアントが生成可能なキーワードをすべて生成する。
ここで、クライアントが生成可能なキーワードのチェック・レベル群とは、例えばクライアントがサポートするメッセージ・ダイジェストのアルゴリズムの種類などによるクライアントの能力、若しくはユーザにより制限されたクライアントの能力により、生成可能なキーワードのチェック・レベル群のことである。
次いで、ステップＳ２で作成したＨＴＴＰリクエストにステップＳ４で作成したキーワードを挿入する（ステップＳ５）。ステップＳ４で生成したキーワードが複数あるならば、そのすべてをＨＴＴＰリクエストに挿入する。
次いで、作成されたＨＴＴＰリクエストをサーバに向けて送信する（ステップＳ６）。
そして、クライアントは、ステップＳ６において送信したＨＴＴＰリクエストに対するサーバからのＨＴＴＰレスポンス・ヘッダを受信すると（ステップＳ７）、ＨＴＴＰレスポンス・ヘッダが正常なレスポンスかどうかを調べる（ステップＳ８）。ここで、正常なレスポンスとはステータス・コードが２００のレスポンスのことである。
サーバからのＨＴＴＰレスポンスが正常であれば、ステップＳ９へ状態を遷移する。また、ＨＴＴＰレスポンスが正常でない場合には、ステップＳ１０へ状態を遷移する。
ステップＳ９では、ステップＳ７で受信したレスポンスに続いてエンティティ・ボディを読み込む。エンティティ・ボディは、暗号化されたコンテンツのデータになっています。コンテンツ復号ブロックはこの暗号化コンテンツを復号する。そして、コンテンツ再生／記録ブロックは、復号したコンテンツの再生若しくは記録を行なう。すべてのデータの受信と再生／記録が終了し、あるいは途中でエラーが生じたら、本処理ルーチン全体を終了する。
一方、サーバからのＨＴＴＰレスポンスが正常でなく、ステップＳ１０に進んだ場合、ステップＳ７で受信したレスポンス・ヘッダに、サーバがサポートするチェック・レベルを示す情報があるかどうかをチェックする。その情報とは、例えばＨＴＴＰレスポンス中のＸ−ＤＴＣＰ−ＡＵＴＨ−ＬＥＶＥＬヘッダである（前述）。チェック・レベルを示す情報がレスポンス・ヘッダに存在すればステップＳ１１へ状態を遷移し、存在しなければステップＳ１３へ状態を遷移する。
ステップＳ１１では、ステップＳ７で受信したＨＴＴＰレスポンス・ヘッダからサーバがサポートするチェック・レベルを抽出し、保持している（すなわち既に送信済みのキーワードの）チェック・レベルと一致するかどうかを判別する。ここで、チェック・レベル５のキーワードが要求されている場合には、ＨＴＴＰダイジェスト認証を行なう必要があるために、ステップＳ５において必要なＨＴＴＰダイジェスト認証のデータを保持しておく。そして、現在保持しているチェック・レベルと同じものをサーバが要求している場合には、ステップＳ１３へ状態を遷移し、異なっていた場合にはステップＳ１２へ状態を遷移する。
ここで、現在保持しているチェック・レベルがサーバが要求しているものと相違するケースとして、クライアントがまだＤＴＣＰ−ＩＰ手続きを完了しておらず、いずれのキーワードもまだ保持していない状態を含めるように構成してもよい。この場合、ステップＳ１２に状態遷移する間に、クライアントはＤＴＣＰ認証手続きを実行することが好ましい。
ステップＳ１２では、現在保持しているサーバがサポートするチェック・レベルを、ステップＳ１１で抽出した情報に更新する。この更新が終了したら、ステップＳ２に復帰して、再びコンテンツの要求を試みる。
一方、ステップＳ１３では、コンテンツの要求が不可能であるため、本処理ルーチン全体を終了する。
図１９には、サーバがクライアントからのコンテンツの要求を受理し、その要求の中のキーワードによりＤＴＣＰ認証が完了しているクライアントかどうかを確認し、認証済みのクライアントに対してコンテンツを送信するための処理手順をフローチャートの形式で示している。この処理手順は、サーバ内のＤＴＣＰ−ＩＰ送信ブロックが主体となって実行される。以下、どう図を参照しながら、この処理手順について詳解する。
サーバは、クライアントからのコンテンツ要求を受信する（ステップＳ２１）。クライアントからの要求を受け付けた場合、そのＨＴＴＰリクエストを受信する。なお、これより後の処理に時間がかかる場合には、スループットを高めるために、要求を受け付けたときから処理を分岐（フォーク）し、別の処理単位として次のリクエストを待機できるようにすることも可能である。
次いで、サーバは、受信したＨＴＴＰリクエストからキーワードの抽出を試み、サーバがサポートするチェック・レベルに該当するキーワードが存在するかどうかをチェックする（ステップＳ２２）。ここで、該当するチェック・レベルのキーワードがＨＴＴＰリクエスト中に存在する場合には次ステップＳ２３へ状態が遷移し、存在しなければステップＳ２８へ状態が遷移する。
ステップＳ２３では、ＨＴＴＰリクエスト中のキーワード群から、サーバがサポートするキーワードのチェック・レベルと合致する、最も高いレベルのキーワードを抽出する。
次いで、ステップＳ２３において抽出したキーワードと同じチェック・レベルのキーワードを、サーバ側でも、同じ属性を持つデータを用いて作成（例えば、メッセージ・ダイジェストへ変換）する（ステップＳ２４）。
ここで、キーワードの作成にはＤＴＣＰ認証時のパラメータなどが必要になる場合もあるので、ＤＴＣＰ−ＩＰ認証ブロックと連携してキーワードを作成する。但し、チェック・レベル１のキーワードに関しては、フラグ又は認証済みであることを直接表す文字列で構成されているので、サーバ側でキーワードを作成する必要はない。
次いで、ステップＳ２３で抽出されたクライアントからのキーワードと、ステップＳ２４でサーバが自ら作成したキーワードを比較照合し、その有効性を確認する（ステップＳ２５）。キーワードが一致すなわち有効である場合にはステップＳ２６へ状態が遷移し、一致しなかった場合にはステップＳ２８へ状態が遷移する。但し、キーワードのチェック・レベルが１である場合は、そのキーワードの識別子が存在すればステップＳ２６へ状態が遷移し、存在しなかった場合はステップＳ２８へ状態が遷移する。
ステップＳ２６では、ＤＴＣＰ認証済みのクライアントから要求されたコンテンツが伝送可能か動作を調査する。そして、伝送可能であればステップＳ２７へ状態が遷移し、伝送不可能であればステップＳ２８へ状態が遷移する。ここで、コンテンツが伝送不可能である場合とは、要求されたコンテンツがサーバ側に存在しなかったり、コンテンツがサーバからアクセス不可能であったりする場合などである。
ステップＳ２７では、クライアントから要求されたコンテンツを伝送するために、要求されたコンテンツに関する正常応答のＨＴＴＰのレスポンスを作成し、要求元クライアントに返信する。その後、ＤＴＣＰ認証済みのクライアントが要求しているコンテンツを取得し、順次クライアントに送信する。
一方、ステップＳ２８では、ＨＴＴＰエラー・レスポンスを作成し、要求元クライアントに対し返信する。このエラー・レスポンスには、サーバがサポートするチェック・レベルの情報を埋め込む。
ここで、ステップＳ２２又はステップＳ２５からの状態遷移を経ていて、サーバがチェック・レベル５のキーワードに対応している場合には、ＨＴＴＰレスポンスのステータス・コードは４０１となる（前述）。また、ステップＳ２２又はＳ２５からの状態遷移を経ていて、その他の場合には、ＨＴＴＰエラー・レスポンスのステータス・コードは４０１以外の適切な値となる。また、ステップＳ２６からの状態遷移を経ている場合は、ＨＴＴＰの仕様に基づいて適切なステータス・コードが設定される。例えば、コンテンツが存在しなかった場合は ４０４（Ｎｏｔ Ｆｏｕｎｄ）が、コンテンツへのアクセスが拒否された場合は ４０３（Ｆｏｒｂｉｄｄｅｎ）が設定される。但し、いずれのステータス・コードを記載するかはＨＴＴＰプロトコルの規定に依るものであり、本発明の要旨に直接関連しない。
ステップＳ２９では、すべてのＨＴＴＰレスポンスを送信し、次のＨＴＴＰリクエストを受信する場合はステップＳ２１へ状態が遷移し、それ以外の場合は本処理ルーチン全体を終了する。
最後に、本実施形態に係るコンテンツ伝送システムにおいて、ＤＴＣＰ−ＩＰクライアントとＤＴＣＰ−ＩＰサーバとの間で、ＨＴＴＰプロトコルに従ってコンテンツの要求及び要求に対する応答を行なった具体例を挙げておく。
図２０には、クライアントから送信されるコンテンツ要求を示している。図示の例では、通常のＨＴＴＰリクエストの形式でコンテンツ要求が記述されており、いずれのチェック・レベルのキーワードも挿入されていない。
サーバ側では、図２０に示すようなＨＴＴＰリクエストを受信すると、クライアントがＤＴＣＰ認証済みであることを示すキーワードが含まれていないので、ＨＴＴＰエラー・レスポンスを返すことになる。図２１には、ＨＴＴＰエラー・レスポンスの記述例を示している。サーバは、ＨＴＴＰエラー・レスポンスに、サーバ側で対応するキーワードのチェック・レベルを記載し、クライアント側に該当するキーワードの挿入を促す。図２１に示す例では、ＨＴＴＰエラー・レスポンス中で、チェック・レベル５に相当するＨＴＴＰダイジェスト認証が要求され、使用するダイジェスト認証パラメータが指定されている。また、図示の例では、ＨＴＴＰエラー・レスポンスに続いて、クライアント側で当該エラー・レスポンスをクライアント側のブラウザ画面で表示するためのメッセージ画面の構成情報が記載されている。
クライアント側では、図２１に示したＨＴＴＰエラー・レスポンスを受信すると、ステータス・コード４０１を参照して、ダイジェスト認証が要求されていることを検出する。そして、要求されているチェック・レベルのキーワードを生成し、ＨＴＴＰレスポンスで指定されているダイジェスト認証パラメータを使用して、Ａｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表して、改めてＨＴＴＰリクエストを送信しコンテンツ要求を再試行する。図２２には、この場合のＨＴＴＰリクエストの記述例を示している。この場合、図２０に示した例とは相違し、認証済みであることを示すキーワードがＨＴＴＰダイジェスト認証時のＡｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表されている。
サーバは、図２２に示すようなＨＴＴＰリクエストを受信すると、サーバ側で要求するチェック・レベルのキーワードが挿入されているので、そのキーワードの有効性を確認する。すなわち、サーバ側でも同じ属性を持つデータを用いてキーワードを作成（例えば、メッセージ・ダイジェストへ変換）し、ＨＴＴＰリクエストに埋め込まれているキーワードと比較照合する。そして、キーワードの有効性が確認されたならば、サーバは、ダイジェスト認証が成功したことを示す正常なＨＴＴＰレスポンスを要求元クライアントへ返信する。図２３には、この場合の正常なＨＴＴＰレスポンスの記述例を示している。
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
本明細書中では、ＤＴＣＰ−ＩＰ及びＨＴＴＰに準拠する実施形態を用いて本発明に係るコンテンツ伝送システムの構成並びにその作用効果について説明してきたが、本発明の要旨は必ずしもこれに限定されるものではなく、例えば伝送コンテンツの保護を規定する他の規格やコンテンツ伝送手続きを利用したコンテンツ伝送システムに対しても、同様に本発明を適用することができる。
また、本明細書で用いたＨＴＴＰオプション・ヘッダ名などの固有の文字列は他の文字列で構成することも可能である。
また、本明細書で説明した実施形態では、キーワードに複数のチェック・レベルを定義しているが、いずれのチェック・レベルのキーワードを生成する元となる値は、実際にＤＴＣＰ−ＩＰシステムを運用する際に規定する必要がある。但し、本発明の要旨は、いずれの値を元にキーワードを生成するかに限定されるものではない。
また、複数のＤＴＣＰ認証を同時に行なうことができるＤＴＣＰ＿ＳｏｕｒｃｅデバイスであるＨＴＴＰサーバにクライアントがコンテンツ要求をする際には、キーワード比較のためのパラメータを使用するときにいずれのＤＴＣＰ認証セッションのパラメータを使うべきかを判断しなければならない。このようなときのために、ＤＴＣＰ＿ＳｏｕｒｃｅデバイスとしてのＨＴＴＰサーバは、ＤＴＣＰ認証セッションにクライアント・デバイスのＩＰアドレスをキーとして関連付けて保持するようにしても良い。
また、本明細書では、ＨＴＴＰのリクエスト及びレスポンスにキーワードを入れて認証の成否を確認することを例にして本発明の実施形態について説明してきたが、本発明の要旨はこれに限定されるものではない。例えば、同様の手法を用いて、ＲＴＳＰやＲＴＰを用いてコンテンツ伝送を行なう場合であっても、本発明を好適に適用することができる。ここで、ＲＴＳＰはＨＴＴＰの上位互換であり、チェック・レベル１〜５のすべてのキーワードを適用することが可能である。また、ＲＴＰではＲＴＣＰ（ＲＴＰ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）のヘッダのオプションとしてチェック・レベル１〜４を適用することが可能である。
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、冒頭に記載した特許請求の範囲の欄を参酌すべきである。
なお、ＤＴＣＰ−ＩＰでは、コンテンツ伝送に ＨＴＴＰ及びＲＴＰを使用することが定義されている。但し、ＨＴＴＰは伝送開始制御を含む要求から始まるコンテンツ伝送プロトコルで、一方のＲＴＰは伝送開始や終了などの制御を含まないプロトコルである。また厳密には、ＨＴＴＰはコネクション型であり、ＲＴＰはコネクションレス型である。これらはそれぞれのプロトコルの性格及び下位層レイヤネットワークに依存する。ＨＴＴＰはコンテンツを要求するプロトコルであり若干の制御も含み、下位層は一般にＴＣＰ／ＩＰであるコネクション型プロトコルである。一方、ＲＴＰはストリームの制御を行なう他のプロトコルに従い伝送を行なう制御なしのプロトコルであり、一般に下位層にＵＤＰ／ＩＰを使用するコネクションレス型プロトコルである。ＲＴＰは通常ＳｅｎｄｅｒからＲｅｃｅｉｖｅｒへの一方通行のデータの流れになる。但し、ＲＴＰにはＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）と呼ばれる送受信状況をレポートするプロトコルも定義されており（ＲＴＰと同じＲＦＣ１８８９で定義）、それを用いて互いの状況を共有することができる。また、ＲＴＰの制御には、例えばＲＴＳＰなどのプロトコルが使用される。ＲＴＳＰにより、送信先アドレスやポート、再生／ストップ／早送り／巻き戻し／スロー再生などのきめ細かな制御が可能である（ＨＴＴＰでは通常不可能）。ＲＴＳＰはＨＴＴＰベースのプロトコルで、ＨＴＴＰ１．１のメッセージとフォーマットに互換性がありる。また、ＲＴＳＰはインターリーブというモードがあり、ＲＴＳＰでＲＴＰを転送することができる。したがって、ＲＴＳＰでコンテンツを伝送することも可能である。
図１は、本発明に係るコンテンツ伝送システムにおいて動作するクライアント機器の機能構成を模式的に示した図である。 図２は、本発明に係るコンテンツ伝送システムにおいて動作するサーバ機器の機能構成を模式的に示した図である。 図３は、レベル１のキーワードをＨＴＴＰリクエストのクエリ文字列として挿入した例を示した図である。 図４は、レベル１のキーワードをＨＴＴＰリクエストのオプション・ヘッダとして挿入した例を示した図である。 図５は、レベル２のキーワードをＨＴＴＰリクエストのクエリ文字列として挿入した例を示した図である。 図６は、レベル２のキーワードをＨＴＴＰリクエストのオプション・ヘッダとして挿入した例を示した図である。 図７は、レベル２のキーワードの構成例を示した図である。 図８は、レベル３のキーワードをＨＴＴＰリクエストのクエリ文字列として挿入した例を示した図である。 図９は、レベル３のキーワードをＨＴＴＰリクエストのオプション・ヘッダとして挿入した例を示した図である。 図１０は、レベル４のキーワードをＨＴＴＰリクエストのクエリ文字列として挿入した例を示した図である。 図１１は、レベル４のキーワードをＨＴＴＰリクエストのオプション・ヘッダとして挿入した例を示した図である。 図１２は、ＨＴＴＰダイジェスト認証を利用してレベル５のキーワードをサーバへ転送している例を示した図である。 図１３は、レベル３とレベル４の２つのキーワードを指定してコンテンツを要求している例を示した図である。 図１４は、チェック・レベル１〜４のいずれかのキーワードをサポートしているサーバが返すＨＴＴＰレスポンスの構成例を示した図である。 図１５は、チェック・レベル１〜４のいずれかのキーワードをサポートしているサーバが返すＨＴＴＰレスポンスの構成例を示した図である。 図１６は、チェック・レベル５をサポートするサーバがサポートするレベルを通知するＨＴＴＰレスポンスの構成例を示した図である。 図１７は、チェック・レベル５をサポートするサーバがサポートするレベルを通知するＨＴＴＰレスポンスの構成例を示した図である。 図１８は、クライアントが認証を完了した後にコンテンツを要求するための処理手順を示したフローチャートである。 図１９は、サーバがクライアントからのコンテンツの要求を受理し、その要求の中のキーワードによりＤＴＣＰ認証が完了しているクライアントかどうかを確認し、認証済みのクライアントに対してコンテンツを送信するための処理手順を示したフローチャートである。 図２０は、ＤＴＣＰ−ＩＰクライアントとＤＴＣＰ−ＩＰサーバとの間で、ＨＴＴＰプロトコルに従ってコンテンツの要求及び要求に対する応答を行なった具体例を示している。 図２１は、ＤＴＣＰ−ＩＰクライアントとＤＴＣＰ−ＩＰサーバとの間で、ＨＴＴＰプロトコルに従ってコンテンツの要求及び要求に対する応答を行なった具体例を示している。 図２２は、ＤＴＣＰ−ＩＰクライアントとＤＴＣＰ−ＩＰサーバとの間で、ＨＴＴＰプロトコルに従ってコンテンツの要求及び要求に対する応答を行なった具体例を示している。 図２３は、ＤＴＣＰ−ＩＰクライアントとＤＴＣＰ−ＩＰサーバとの間で、ＨＴＴＰプロトコルに従ってコンテンツの要求及び要求に対する応答を行なった具体例を示している。

Claims (81)

  1. コンテンツの保護を考慮しながらコンテンツ送信装置からコンテンツ受信装置へコンテンツをネットワーク経由で伝送するコンテンツ伝送システムであって、
    前記コンテンツ送信装置と前記コンテンツ受信装置間で認証手続きを実行して前記の両装置間で認証情報を共有する認証手続き実行手段と、
    前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ送信装置から前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行手段とを備え、
    前記コンテンツ伝送手続き実行手段は、コンテンツ受信装置が認証済みであることを示すキーワードがコンテンツ要求に含まれていることを確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
    ことを特徴とするコンテンツ伝送システム。
  2. 前記コンテンツ送信装置及び前記コンテンツ受信装置はＤＴＣＰに準拠した装置であり、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）によりユニークな機器ＩＤや鍵が埋め込まれている、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  3. 前記認証手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間でコネクションを確立した後、ＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）により前記の両装置間の認証を行なう、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  4. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）、又はＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）のうちいずれかのプロトコルを用いてコンテンツ伝送を行なう、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  5. 前記認証手続き実行手段と前記コンテンツ伝送手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間で個別のコネクションを確立してそれぞれの手続きを互いに独立して実行する、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  6. 認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義され、前記コンテンツ送信装置はどのチェック・レベルのキーワードをサポートするかを設定する、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  7. キーワードは、チェック・レベルを表す識別子と、該チェック・レベルに対応したキーワード値で構成される、
    ことを特徴とする請求項６に記載のコンテンツ伝送システム。
  8. 前記の認証済みであることを示すキーワードは、認証したかどうかを示すフラグ、又は前記コンテンツ送信装置及び前記コンテンツ受信装置において既知である任意の文字列のいずれかで構成される、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  9. 前記の認証済みであることを示すキーワードは、前記認証手続き実行手段により得られた前記認証情報を構成する少なくとも一部の情報に基づいて作成される、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  10. 前記コンテンツ送信装置及び前記コンテンツ受信装置間で共有する認証情報は、ネットワーク上を伝送して共有される公開情報と、ネットワーク上を伝送しないで共有される秘匿情報を含む、
    ことを特徴とする請求項９に記載のコンテンツ伝送システム。
  11. 前記の認証済みであることを示すキーワードは、前記認証情報に含まれる公開情報に基づいて作成される、
    ことを特徴とする請求項１０に記載のコンテンツ伝送システム。
  12. 前記の認証済みであることを示すキーワードは、前記認証情報に含まれる秘匿情報に基づいて作成される、
    ことを特徴とする請求項１０に記載のコンテンツ伝送システム。
  13. 秘匿情報をメッセージ・ダイジェストに変換してからキーワードの作成に使用する、
    ことを特徴とする請求項１２に記載のコンテンツ伝送システム。
  14. 前記の認証済みであることを示すキーワードは、前記認証情報に含まれる公開情報及び秘匿情報を組み合わせたデータ、又は公開情報及び秘匿情報を加工したデータからなる、
    ことを特徴とする請求項１０に記載のコンテンツ伝送システム。
  15. 前記コンテンツ受信装置はＨＴＴＰを用いてコンテンツを要求するクライアント装置で、前記コンテンツ送信装置はＨＴＴＰを用いてコンテンツを送信するサーバ装置であり、
    前記コンテンツ受信装置は、ＨＴＴＰリクエスト中にキーワードを組み込み、
    前記コンテンツ送信装置は、ＨＴＴＰリクエスト中からキーワードを抽出する、
    ことを特徴とする請求項１に記載のコンテンツ伝送システム。
  16. 前記の認証済みであることを示すキーワードは、前記コンテンツ送信装置と前記コンテンツ受信装置が共有する前記認証情報、ＨＴＴＰのダイジェスト認証情報、及びその他の属性を持つ情報から生成され、
    前記コンテンツ伝送手続き実行手段は、前記コンテンツ送信装置と前記コンテンツ受信装置において同じ属性を持つ情報を用いてそれぞれ生成された値が同一であるかどうかを基にコンテンツ受信装置が認証済みであるかどうかを確認する、
    ことを特徴とする請求項１５に記載のコンテンツ伝送システム。
  17. 前記コンテンツ受信装置は、ＨＴＴＰリクエストのリクエストＵＲＩのクエリ文字列部分にキーワードを組み込む、
    ことを特徴とする請求項１５に記載のコンテンツ伝送システム。
  18. 前記コンテンツ受信装置は、ＨＴＴＰリクエストのヘッダ部分にキーワードを組み込む、
    ことを特徴とする請求項１５に記載のコンテンツ伝送システム。
  19. 前記の認証済みであることを示すキーワードは、前記認証手続き実行手段により得られる認証情報を用いて作成されるデータがＨＴＴＰダイジェスト認証時のＡｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表されたものである、
    ことを特徴とする請求項１５に記載のコンテンツ伝送システム。
  20. 前記コンテンツ受信装置は、キーワードの値がバイナリ形式である場合には、該値を文字列データに変換してＨＴＴＰリクエストのヘッダ部分に組み込む、
    ことを特徴とする請求項１５に記載のコンテンツ伝送システム。
  21. 前記コンテンツ受信装置は、ＨＴＴＰリクエスト中に複数のキーワードを同時に組み込むことができる、
    ことを特徴とする請求項１５に記載のコンテンツ伝送システム。
  22. 認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義され、前記コンテンツ送信装置はどのチェック・レベルのキーワードをサポートするかを設定する、
    ことを特徴とする請求項２１に記載のコンテンツ伝送システム。
  23. 前記コンテンツ送信装置は、受信したＨＴＴＰリクエスト中に自分がサポートするチェック・レベルのキーワードが含まれていない場合又は有効なキーワードを確認することができない場合には、コンテンツの伝送を拒否する旨のＨＴＴＰエラー・レスポンスを返す、
    ことを特徴とする請求項２２に記載のコンテンツ伝送システム。
  24. 前記コンテンツ送信装置は、自分がサポートするチェック・レベルを埋め込んだＨＴＴＰエラー・レスポンスを返す、
    ことを特徴とする請求項２３に記載のコンテンツ伝送システム。
  25. 前記コンテンツ受信装置は、ＨＴＴＰエラー・レスポンスで指定されているチェック・レベルのキーワードを組み込んだコンテンツ要求をまだ行なっていない場合には、コンテンツ要求を再試行する、
    ことを特徴とする請求項２４に記載のコンテンツ伝送システム。
  26. 前記コンテンツ送信装置は、ＨＴＴＰリクエスト中に複数のキーワードが組み込まれている場合には、自分がサポートするチェック・レベルに合致するもののうち最も高いチェック・レベルのキーワードを用いてその有効性の確認を行なう、
    ことを特徴とする請求項２２に記載のコンテンツ伝送システム。
  27. 前記コンテンツ送信装置は、ＨＴＴＰリクエストによりコンテンツを要求してきたコンテンツ受信装置のＩＰアドレスが前記認証手続き実行手段により得られた認証情報に含まれるか否かをチェックする、
    ことを特徴とする請求項２６に記載のコンテンツ伝送システム。
  28. コンテンツの保護を考慮しながらコンテンツ送信装置からコンテンツ受信装置へコンテンツをネットワーク経由で伝送するコンテンツ伝送方法であって、
    前記コンテンツ送信装置と前記コンテンツ受信装置間で認証手続きを実行して前記の両装置間で認証情報を共有する認証手続き実行ステップと、
    前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ送信装置から前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行ステップとを備え、
    前記コンテンツ伝送手続き実行ステップでは、コンテンツ受信装置が認証済みであることを示すキーワードがコンテンツ要求に含まれていることを確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
    ことを特徴とするコンテンツ伝送方法。
  29. コンテンツの保護を考慮しながらコンテンツ受信装置へコンテンツをネットワーク経由で伝送するコンテンツ送信装置であって、
    前記コンテンツ受信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行手段と、
    前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行手段とを備え、
    前記コンテンツ伝送手続き実行手段は、コンテンツ要求に含まれているコンテンツ受信装置が認証済みであることを示すキーワードの有効性を確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
    ことを特徴とするコンテンツ送信装置。
  30. ＤＴＣＰに準拠した装置であり、ＤＴＬＡによりユニークな機器ＩＤや鍵が埋め込まれている、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  31. 前記認証手続き実行手段は、前記コンテンツ受信装置との間でコネクションを確立した後、ＤＴＣＰ認証、若しくはＡＫＥにより前記コンテンツ受信装置との認証を行なう、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  32. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰ、ＲＴＰ、又はＲＴＳＰのうちいずれかのプロトコルを用いてコンテンツ伝送を行なう、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  33. 前記認証手続き実行手段と前記コンテンツ伝送手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間で個別のコネクションを確立してそれぞれの手続きを互いに独立して実行する、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  34. 認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義され、
    前記コンテンツ伝送手続き実行手段はどのチェック・レベルのキーワードをサポートするかを設定する、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  35. キーワードは、チェック・レベルを表す識別子と、該チェック・レベルに対応したキーワード値で構成される、
    ことを特徴とする請求項３４に記載のコンテンツ送信装置。
  36. 前記の認証済みであることを示すキーワードは、認証したかどうかを示すフラグ、又は前記コンテンツ送信装置及び前記コンテンツ受信装置において既知である任意の文字列のいずれかで構成される、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  37. 前記の認証済みであることを示すキーワードは、前記認証手続き実行手段により得られた前記認証情報を構成する少なくとも一部の情報に基づいて作成される、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  38. 前記コンテンツ受信装置との間で共有する認証情報は、ネットワーク上を伝送して共有される公開情報と、ネットワーク上を伝送しないで共有される秘匿情報を含む、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  39. 前記の認証済みであることを示すキーワードは、前記認証情報に含まれる公開情報に基づいて作成される、
    ことを特徴とする請求項３８に記載のコンテンツ送信装置。
  40. 前記の認証済みであることを示すキーワードは、前記認証情報に含まれる秘匿情報に基づいて作成される、
    ことを特徴とする請求項３８に記載のコンテンツ送信装置。
  41. 秘匿情報をメッセージ・ダイジェストに変換してからキーワードの作成に使用する、
    ことを特徴とする請求項４０に記載のコンテンツ送信装置。
  42. 前記の認証済みであることを示すキーワードは、前記認証情報に含まれる公開情報及び秘匿情報を組み合わせたデータ、又は公開情報及び秘匿情報を加工したデータからなる、
    ことを特徴とする請求項３８に記載のコンテンツ送信装置。
  43. ＨＴＴＰを用いてコンテンツを送信するサーバ装置として動作し、
    前記コンテンツ伝送手続き実行手段は、コンテンツを要求するＨＴＴＰリクエスト中からキーワードを抽出し、その有効性を確認する、
    ことを特徴とする請求項２９に記載のコンテンツ送信装置。
  44. 前記の認証済みであることを示すキーワードは、前記コンテンツ送信装置と前記コンテンツ受信装置が共有する前記認証情報、ＨＴＴＰのダイジェスト認証情報、及びその他の属性を持つ情報から生成され、
    前記コンテンツ伝送手続き実行手段は、前記コンテンツ受信装置と同じ属性を持つ情報を用いて同一のキーワードを生成することができたかどうかを基にコンテンツ受信装置が認証済みであるかどうかを確認する、
    ことを特徴とする請求項４３に記載のコンテンツ送信装置。
  45. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエストのリクエストＵＲＩのクエリ文字列部分に組み込まれているキーワードを抽出する、
    ことを特徴とする請求項４３に記載のコンテンツ送信装置。
  46. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエストのヘッダ部分に組み込まれているキーワードを抽出する、
    ことを特徴とする請求項４３に記載のコンテンツ送信装置。
  47. 前記の認証済みであることを示すキーワードは、前記認証手続き実行手段により得られる認証情報を用いて作成されるデータがＨＴＴＰダイジェスト認証時のＡｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表されたものである、
    ことを特徴とする請求項４３に記載のコンテンツ送信装置。
  48. バイナリ形式のキーワードの値が文字列データに変換されてＨＴＴＰリクエストのヘッダに組み込まれている、
    ことを特徴とする請求項４３に記載のコンテンツ送信装置。
  49. ＨＴＴＰリクエスト中に複数のキーワードを同時に組み込まれている、
    ことを特徴とする請求項４３に記載のコンテンツ送信装置。
  50. 認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義され、
    前記コンテンツ伝送手続き実行手段はどのチェック・レベルのキーワードをサポートするかを設定する、
    ことを特徴とする請求項４９に記載のコンテンツ送信装置。
  51. 前記コンテンツ伝送手続き実行手段は、受信したＨＴＴＰリクエスト中に自分がサポートするチェック・レベルのキーワードが含まれていない場合又は有効なキーワードを確認することができない場合には、コンテンツの伝送を拒否する旨のＨＴＴＰエラー・レスポンスを返す、
    ことを特徴とする請求項５０に記載のコンテンツ送信装置。
  52. 前記コンテンツ伝送手続き実行手段は、自分がサポートするチェック・レベルを埋め込んだＨＴＴＰエラー・レスポンスを返す、
    ことを特徴とする請求項５１に記載のコンテンツ送信装置。
  53. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエスト中に複数のキーワードが組み込まれている場合には、自分がサポートするチェック・レベルに合致するもののうち最も高いチェック・レベルのキーワードを用いてその有効性の確認を行なう、
    ことを特徴とする請求項５０に記載のコンテンツ送信装置。
  54. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエストによりコンテンツを要求してきたコンテンツ受信装置のＩＰアドレスが前記認証手続き実行手段により得られた認証情報に含まれるか否かをチェックする、
    ことを特徴とする請求項５３に記載のコンテンツ送信装置。
  55. コンテンツの保護を考慮しながらコンテンツ受信装置へコンテンツをネットワーク経由で伝送するコンテンツ送信方法であって、
    前記コンテンツ受信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行ステップと、
    前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行ステップとを備え、
    前記コンテンツ伝送手続き実行ステップでは、コンテンツ要求に含まれているコンテンツ受信装置が認証済みであることを示すキーワードの有効性を確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
    ことを特徴とするコンテンツ送信方法。
  56. コンテンツの保護を考慮しながらネットワーク経由で伝送されるコンテンツを受信するコンテンツ受信装置であって、
    前記コンテンツ送信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行手段と、
    前記コンテンツ受信装置が認証済みであることを示すキーワードを含んだコンテンツ要求を発行するとともに、該コンテンツ要求に応答して伝送される暗号化コンテンツを受信処理するコンテンツ伝送手続き実行手段と、
    を具備することを特徴とするコンテンツ受信装置。
  57. ＤＴＣＰに準拠した装置であり、ＤＴＬＡによりユニークな機器ＩＤや鍵が埋め込まれている、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  58. 前記認証手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間でコネクションを確立した後、ＤＴＣＰ認証、若しくはＡＫＥにより前記コンテンツ送信装置との認証を行なう、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  59. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰ、ＲＴＰ、又はＲＴＳＰのうちいずれかのプロトコルを用いてコンテンツ伝送を行なう、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  60. 前記認証手続き実行手段と前記コンテンツ伝送手続き実行手段は、前記コンテンツ送信装置及び前記コンテンツ受信装置間で個別のコネクションを確立してそれぞれの手続きを互いに独立して実行する、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  61. 認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義され、前記コンテンツ送信装置はどのチェック・レベルのキーワードをサポートするかを設定する、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  62. キーワードは、チェック・レベルを表す識別子と、該チェック・レベルに対応したキーワード値で構成される、
    ことを特徴とする請求項６１に記載のコンテンツ受信装置。
  63. 前記の認証済みであることを示すキーワードは、認証したかどうかを示すフラグ、又は前記コンテンツ送信装置及び前記コンテンツ受信装置において既知である任意の文字列のいずれかで構成される、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  64. 前記コンテンツ伝送手続き実行手段は、前記認証手続き実行手段により得られた前記認証情報を構成する少なくとも一部の情報に基づいて前記の認証済みであることを示すキーワードを作成する、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  65. 前記コンテンツ送信装置及び前記コンテンツ受信装置間で共有する認証情報は、ネットワーク上を伝送して共有される公開情報と、ネットワーク上を伝送しないで共有される秘匿情報を含む、
    ことを特徴とする請求項６４に記載のコンテンツ受信装置。
  66. 前記コンテンツ伝送手続き実行手段は、前記認証情報に含まれる公開情報に基づいて前記の認証済みであることを示すキーワードを作成する、
    ことを特徴とする請求項６５に記載のコンテンツ受信装置。
  67. 前記コンテンツ伝送手続き実行手段は、前記認証情報に含まれる秘匿情報に基づいて前記の認証済みであることを示すキーワードを作成する、
    ことを特徴とする請求項６５に記載のコンテンツ受信装置。
  68. 前記コンテンツ伝送手続き実行手段は、秘匿情報をメッセージ・ダイジェストに変換してからキーワードの作成に使用する、
    ことを特徴とする請求項６７に記載のコンテンツ受信装置。
  69. 前記コンテンツ伝送手続き実行手段は、前記認証情報に含まれる公開情報及び秘匿情報を組み合わせたデータ、又は公開情報及び秘匿情報を加工したデータからなるキーワードを生成する、
    ことを特徴とする請求項６５に記載のコンテンツ受信装置。
  70. 前記コンテンツ受信装置はＨＴＴＰを用いてコンテンツを要求するクライアント装置として動作し、
    前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエスト中にキーワードを組み込む、
    ことを特徴とする請求項５６に記載のコンテンツ受信装置。
  71. 前記コンテンツ伝送手続き実行手段は、前記の認証済みであることを示すキーワードを、前記コンテンツ送信装置と前記コンテンツ受信装置が共有する前記認証情報、ＨＴＴＰのダイジェスト認証情報、及びその他の属性を持つ情報から生成する、
    ことを特徴とする請求項７０に記載のコンテンツ受信装置。
  72. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエストのリクエストＵＲＩのクエリ文字列部分にキーワードを組み込む、
    ことを特徴とする請求項７０に記載のコンテンツ受信装置。
  73. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエストのヘッダ部分にキーワードを組み込む、
    ことを特徴とする請求項７０に記載のコンテンツ受信装置。
  74. 前記コンテンツ伝送手続き実行手段は、前記の認証済みであることを示すキーワードを、前記認証手続き実行手段により得られる認証情報を用いて作成されるデータがＨＴＴＰダイジェスト認証時のＡｕｔｈｅｎｔｉｃａｔｅヘッダ・フィールド値の形態で表す、
    ことを特徴とする請求項７０に記載のコンテンツ受信装置。
  75. 前記コンテンツ伝送手続き実行手段は、キーワードの値がバイナリ形式である場合には、該値を文字列データに変換してＨＴＴＰリクエストのヘッダ部分に組み込む、
    ことを特徴とする請求項７０に記載のコンテンツ受信装置。
  76. 前記コンテンツ伝送手続き実行手段は、ＨＴＴＰリクエスト中に複数のキーワードを同時に組み込むことができる、
    ことを特徴とする請求項７０に記載のコンテンツ受信装置。
  77. 認証チェックの正確さを表すチェック・レベルの異なる複数種類のキーワードが定義され、前記コンテンツ送信装置はどのチェック・レベルのキーワードをサポートするかを設定する、
    ことを特徴とする請求項７６に記載のコンテンツ受信装置。
  78. 前記コンテンツ送信装置がサポートするチェック・レベルを埋め込んだＨＴＴＰエラー・レスポンスを前記コンテンツ送信装置から受信し、
    前記コンテンツ伝送手続き実行手段は、ＨＴＴＰエラー・レスポンスで指定されているチェック・レベルのキーワードを組み込んだコンテンツ要求をまだ行なっていない場合には、コンテンツ要求を再試行する、
    ことを特徴とする請求項７７に記載のコンテンツ受信装置。
  79. コンテンツの保護を考慮しながらネットワーク経由で伝送されるコンテンツを受信するコンテンツ受信方法であって、
    前記コンテンツ送信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行ステップと、
    前記コンテンツ受信装置が認証済みであることを示すキーワードを含んだコンテンツ要求を発行するとともに、該コンテンツ要求に応答して伝送される暗号化コンテンツを受信処理するコンテンツ伝送手続き実行ステップと、
    を具備することを特徴とするコンテンツ受信方法。
  80. コンテンツの保護を考慮しながらコンテンツ受信装置へコンテンツをネットワーク経由で伝送するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
    前記コンテンツ受信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行ステップと、
    前記コンテンツ受信装置からのコンテンツ要求に応じて伝送するコンテンツを暗号化し、前記コンテンツ受信装置へ暗号化コンテンツを伝送するコンテンツ伝送手続き実行ステップとを備え、
    前記コンテンツ伝送手続き実行ステップでは、コンテンツ要求に含まれているコンテンツ受信装置が認証済みであることを示すキーワードの有効性を確認したことに応答して、暗号化コンテンツの伝送処理を開始する、
    ことを特徴とするコンピュータ・プログラム。
  81. コンテンツの保護を考慮しながらネットワーク経由で伝送されるコンテンツを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、
    前記コンテンツ送信装置との間で認証手続きを実行して認証情報を共有する認証手続き実行ステップと、
    前記コンテンツ受信装置が認証済みであることを示すキーワードを含んだコンテンツ要求を発行するとともに、該コンテンツ要求に応答して伝送される暗号化コンテンツを受信処理するコンテンツ伝送手続き実行ステップと、
    ことを特徴とするコンピュータ・プログラム。
JP2004113459A 2004-04-07 2004-04-07 コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム Expired - Fee Related JP4264650B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004113459A JP4264650B2 (ja) 2004-04-07 2004-04-07 コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム
US11/092,897 US7627905B2 (en) 2004-04-07 2005-03-30 Content transfer system, content transfer method, content transmitting apparatus, content transmission method, content receiving apparatus, content reception method, and computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004113459A JP4264650B2 (ja) 2004-04-07 2004-04-07 コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム

Publications (2)

Publication Number Publication Date
JP2005301449A true JP2005301449A (ja) 2005-10-27
JP4264650B2 JP4264650B2 (ja) 2009-05-20

Family

ID=35310710

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004113459A Expired - Fee Related JP4264650B2 (ja) 2004-04-07 2004-04-07 コンテンツ伝送システム及びコンテンツ伝送方法、コンテンツ送信装置及びコンテンツ送信方法、コンテンツ受信装置及びコンテンツ受信方法、並びにコンピュータ・プログラム

Country Status (2)

Country Link
US (1) US7627905B2 (ja)
JP (1) JP4264650B2 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006339900A (ja) * 2005-05-31 2006-12-14 Toshiba Corp データ送信装置、データ受信装置、データ送信方法およびデータ受信方法
KR20070078065A (ko) * 2006-01-25 2007-07-30 소니 가부시끼 가이샤 컨텐츠 전송 시스템, 컨텐츠 전송 장치 및 컨텐츠 전송방법, 및 컴퓨터 프로그램
WO2007105460A1 (ja) * 2006-03-07 2007-09-20 Sony Corporation 情報処理装置、情報通信システム、および情報処理方法、並びにコンピュータ・プログラム
JP2007272471A (ja) * 2006-03-30 2007-10-18 Nomura Research Institute Ltd セッション管理システム
JP2008028497A (ja) * 2006-07-19 2008-02-07 Hitachi Ltd コンテンツ記録再生装置
JP2008077664A (ja) * 2006-09-21 2008-04-03 Irdeto Access Bv サーバとクライアント・システムとの間の通信セッションにおける状態追跡機構を履行する方法
CN101438256B (zh) * 2006-03-07 2011-12-21 索尼株式会社 信息处理设备、信息通信系统、信息处理方法

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040203589A1 (en) * 2002-07-11 2004-10-14 Wang Jiwei R. Method and system for controlling messages in a communication network
US7665147B2 (en) * 2004-02-05 2010-02-16 At&T Mobility Ii Llc Authentication of HTTP applications
KR100755690B1 (ko) * 2005-05-10 2007-09-05 삼성전자주식회사 컨텐츠 관리 방법 및 장치
JP2006339898A (ja) * 2005-05-31 2006-12-14 Toshiba Corp データ送信装置およびデータ受信装置
JP4518058B2 (ja) * 2006-01-11 2010-08-04 ソニー株式会社 コンテンツ伝送システム、コンテンツ伝送装置及びコンテンツ伝送方法、並びにコンピュータ・プログラム
US7552127B2 (en) 2006-12-19 2009-06-23 International Business Machines Corporation System and method for providing platform-independent content services for users for content from content applications leveraging Atom, XLink, XML Query content management systems
CA2688604A1 (en) * 2007-06-04 2008-12-11 Tomtom International B.V. Location data processing apparatus and method of importing location information
JP5903783B2 (ja) * 2011-06-30 2016-04-13 ソニー株式会社 サーバ装置および情報処理装置
US9032494B2 (en) * 2011-11-10 2015-05-12 Sony Corporation Network-based revocation, compliance and keying of copy protection systems
CN103166931A (zh) * 2011-12-15 2013-06-19 华为技术有限公司 一种安全传输数据方法，装置和系统
JP6323811B2 (ja) * 2013-03-15 2018-05-16 パナソニックＩｐマネジメント株式会社 コンテンツ配信方法及びソース機器
US10084797B2 (en) * 2016-10-03 2018-09-25 Extreme Networks, Inc. Enhanced access security gateway

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1278112B1 (en) 2001-07-12 2003-05-28 Castify Networks SA A process for providing access of a client to a content provider server under control of a resource locator server
JP4934923B2 (ja) * 2001-08-09 2012-05-23 ソニー株式会社 情報記録装置、情報再生装置、および情報記録方法、情報再生方法、並びにコンピュータ・プログラム
US8301884B2 (en) * 2002-09-16 2012-10-30 Samsung Electronics Co., Ltd. Method of managing metadata
EP1553735A1 (en) * 2002-10-17 2005-07-13 Matsushita Electric Industrial Co., Ltd. Packet transmission/reception device

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7688860B2 (en) 2005-05-31 2010-03-30 Kabushiki Kaisha Toshiba Data transmission apparatus, data reception apparatus, data transmission method, and data reception method
JP4709583B2 (ja) * 2005-05-31 2011-06-22 株式会社東芝 データ送信装置およびデータ送信方法
JP2006339900A (ja) * 2005-05-31 2006-12-14 Toshiba Corp データ送信装置、データ受信装置、データ送信方法およびデータ受信方法
KR20070078065A (ko) * 2006-01-25 2007-07-30 소니 가부시끼 가이샤 컨텐츠 전송 시스템, 컨텐츠 전송 장치 및 컨텐츠 전송방법, 및 컴퓨터 프로그램
JP2007272868A (ja) * 2006-03-07 2007-10-18 Sony Corp 情報処理装置、情報通信システム、および情報処理方法、並びにコンピュータ・プログラム
WO2007105460A1 (ja) * 2006-03-07 2007-09-20 Sony Corporation 情報処理装置、情報通信システム、および情報処理方法、並びにコンピュータ・プログラム
CN101438256B (zh) * 2006-03-07 2011-12-21 索尼株式会社 信息处理设备、信息通信系统、信息处理方法
US8230004B2 (en) 2006-03-07 2012-07-24 Sony Corporation Information processing apparatus, information communication system, information processing method, and computer program
US8316082B2 (en) 2006-03-07 2012-11-20 Sony Corporation Content providing system, information processing apparatus, information processing method, and computer program
JP2007272471A (ja) * 2006-03-30 2007-10-18 Nomura Research Institute Ltd セッション管理システム
JP2008028497A (ja) * 2006-07-19 2008-02-07 Hitachi Ltd コンテンツ記録再生装置
JP4548393B2 (ja) * 2006-07-19 2010-09-22 株式会社日立製作所 コンテンツ記録再生装置
JP2008077664A (ja) * 2006-09-21 2008-04-03 Irdeto Access Bv サーバとクライアント・システムとの間の通信セッションにおける状態追跡機構を履行する方法

Also Published As

Publication number Publication date
US7627905B2 (en) 2009-12-01
US20050257056A1 (en) 2005-11-17
JP4264650B2 (ja) 2009-05-20

Similar Documents

Publication Publication Date Title
US7627905B2 (en) Content transfer system, content transfer method, content transmitting apparatus, content transmission method, content receiving apparatus, content reception method, and computer program
JP4366037B2 (ja) 暗号化された媒体へのアクセス権を制御・行使するシステム及び方法
CN102422593B (zh) 基于http的认证
US7987359B2 (en) Information communication system, information communication apparatus and method, and computer program
JP4866342B2 (ja) 権利管理エンティティ間メッセージポリシーおよび実施
US7039713B1 (en) System and method of user authentication for network communication through a policy agent
US7900247B2 (en) Trusted third party authentication for web services
US8196186B2 (en) Security architecture for peer-to-peer storage system
JP4748774B2 (ja) 暗号化通信方式及びシステム
JP5181094B2 (ja) 信頼される処理技術を使用したデジタル権利管理
JP4560051B2 (ja) 権利管理保護されたコンテンツのプレライセンス供与
EP1817687B1 (en) Apparatus and method for supporting content exchange between different drm domains
US20100017599A1 (en) Secure digital content management using mutating identifiers
US20100257370A1 (en) Apparatus And Method for Supporting Content Exchange Between Different DRM Domains
US20100100736A1 (en) Method and system for secure communication
WO2007048335A1 (fr) Méthode et système d’équipement de transmission codée empêchant la copie de ressources de données
Neuman et al. RFC 4120: The Kerberos network authentication service (V5)
KR100978906B1 (ko) 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을구현하는 프로그램이 저장된 기록매체
WO2007073623A1 (fr) Procede de telechargement d'une certification et d'une cle numeriques
WO2022033350A1 (zh) 注册服务的方法及设备
JP4068877B2 (ja) ディジタル・コンテンツ・システム
JP3725020B2 (ja) 電子データの内容証明方法及びそのシステム
JP3621657B2 (ja) ファイル送信サーバ、ファイル送受信システム、方法、およびプログラム
JP2008198190A (ja) 電子メールメッセージを安全に交換する方法及びシステム
JP4774667B2 (ja) サーバ、公開鍵の情報の提供方法、およびコンピュータプログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080722

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080916

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20081125

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081219

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: 20090120

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: 20090202

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

Free format text: PAYMENT UNTIL: 20120227

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees