特許 7371849 ネットワークシステム、配信サーバ、配信方法、配信プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-10-23

(45)【発行日】2023-10-31

(54)【発明の名称】ネットワークシステム、配信サーバ、配信方法、配信プログラム

(51)【国際特許分類】

   H04L 67/02 20220101AFI20231024BHJP

【ＦＩ】

H04L67/02

【請求項の数】 6

(21)【出願番号】P 2019106561

(22)【出願日】2019-06-06

(65)【公開番号】P2020201605

(43)【公開日】2020-12-17

【審査請求日】2022-05-19

(73)【特許権者】

【識別番号】514020389

【氏名又は名称】ＴＩＳ株式会社

(73)【特許権者】

【識別番号】301022471

【氏名又は名称】国立研究開発法人情報通信研究機構

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】吉見 真聡

(72)【発明者】

【氏名】中島 拓真

(72)【発明者】

【氏名】江村 恵太

(72)【発明者】

【氏名】盛合 志帆

【審査官】岩田 玲彦

(56)【参考文献】

【文献】特開平１１－１７５４７５（ＪＰ，Ａ）

【文献】特開２０１０－１０９７９１（ＪＰ，Ａ）

【文献】国際公開第２０１３／１４０７７４（ＷＯ，Ａ１）

【文献】国際公開第２０１８／０９２６７９（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ６７／０２

(57)【特許請求の範囲】

【請求項1】

データファイルを配信する配信サーバと、前記データファイルをキャッシュするキャッシュサーバと、前記データファイルを受信する端末とを含むネットワークシステムであって、
前記配信サーバは、
前記端末からデータファイルの送信要求を受けた場合、要求されたデータファイルに対して対応付けられた識別情報を前記端末に送信する配信制御部と、
暗号化されたデータファイルを復号するための鍵を前記端末に送信する鍵管理部と
を備え、
前記キャッシュサーバは、
前記端末から前記識別情報を含むデータファイルの送信要求を受けた場合、要求された識別情報と対応付けてデータファイルを記憶装置にキャッシュしているときは、当該データファイルを前記端末に送信し、要求された識別情報と対応付けてデータファイルを記憶装置にキャッシュしていないときは、暗号化された当該データファイルを前記配信サーバから受信し、前記記憶装置に格納するキャッシュ管理部を備え、
前記配信サーバと前記端末とは、前記配信制御部が行う処理において暗号化通信を行うためのセッションを確立し、前記鍵管理部が行う処理において前記セッションを再開する
ネットワークシステム。

【請求項2】

前記識別情報は、当該識別情報と対応付けられるデータファイル、又は当該データファイルのネットワーク上のアドレスから所定の一方向性関数を用いて求められる値である
請求項１に記載のネットワークシステム。

【請求項3】

前記配信サーバ、前記キャッシュサーバ、及び前記端末は、互いに暗号化通信を行う
請求項１又は２に記載のネットワークシステム。

【請求項4】

データファイルを配信し、前記データファイルをキャッシュするキャッシュサーバ、及び前記データファイルを受信する端末と通信する配信サーバであって、
データファイルの送信要求を前記端末から受けた場合、要求されたデータファイルに対して対応付けられた識別情報を前記端末に送信し、当該識別情報を含むデータファイルの送信要求を前記キャッシュサーバから受けた場合、暗号化された当該データファイルを前記キャッシュサーバに送信する配信制御部と、
暗号化されたデータファイルを復号するための鍵を前記端末に送信する鍵管理部と
を備え、
前記端末との間で、前記配信制御部が行う処理において暗号化通信を行うためのセッションを確立し、前記鍵管理部が行う処理において前記セッションを再開する
配信サーバ。

【請求項5】

データファイルを配信し、前記データファイルをキャッシュするキャッシュサーバ、及び前記データファイルを受信する端末と通信する配信サーバが実行する配信方法であって、
データファイルの送信要求を前記端末から受けた場合、要求されたデータファイルに対して対応付けられた識別情報を前記端末に送信し、当該識別情報を含むデータファイルの送信要求を前記キャッシュサーバから受けた場合、暗号化された当該データファイルを前記キャッシュサーバに送信する第１ステップと、
暗号化されたデータファイルを復号するための鍵を前記端末に送信する第２ステップと、
を含み、
前記端末との間で、前記第１ステップにおいて、暗号化通信を行うためのセッションを確立し、前記第２ステップにおいて前記セッションを再開する
配信方法。

【請求項6】

データファイルを配信し、前記データファイルをキャッシュするキャッシュサーバ、及び前記データファイルを受信する端末と通信する配信サーバによって実行される配信プログラムであって、
データファイルの送信要求を前記端末から受けた場合、要求されたデータファイルに対して対応付けられた識別情報を前記端末に送信し、当該識別情報を含むデータファイルの送信要求を前記キャッシュサーバから受けた場合、暗号化された当該データファイルを前記キャッシュサーバに送信する第１ステップと、
暗号化されたデータファイルを復号するための鍵を前記端末に送信する第２ステップと、
を配信サーバに実行させると共に
前記配信サーバに、前記端末との間で、前記第１ステップにおいて、暗号化通信を行うためのセッションを確立させ、前記第２ステップにおいて前記セッションを再開させる
配信プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークシステム、配信サーバ、配信方法、配信プログラム、キャッシュサーバ、キャッシュ方法及びキャッシュプログラムに関する。

【背景技術】

【0002】

従来、ネットワークに接続されたコンピュータ間で伝送されるファイルを中間的にキャッシュするための様々な技術が提案されている。しかしながら、配信元のサーバと配信先の端末との間で暗号化通信を行う場合、キャッシュサーバは配信される情報を読み取ることができず、一般的にはキャッシュが困難である。また、暗号化された通信の内容をキャッシュするための技術も提案されている（例えば、非特許文献１、２）。

【先行技術文献】

【非特許文献】

【0003】

【文献】Jeremie Leguay, Georgios S. Paschos, Elizabeth A. Quaglia, Ben Smyth, “CryptoCache: Network Caching with Confidentiality” IEEE ICC, 2017年5月21-25日, DOI: 10.1109/ICC.2017.7996866

【文献】Shujie Cui, Muhammad Rizwan Asghar, and Giovanni Russello, “Multi-CDN: Towards Privacy in Content Delivery Networks”IEEE TDSC, 2018年5月4日, DOI: 10.1109/TDSC.2018.2833110

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、キャッシュサーバが保持し端末から要求される情報の内容についてはキャッシュサーバに対し秘匿し、情報を要求する端末に対しては情報を適切に利用させることは困難であった。そこで、本発明は、情報を暗号化した状態でキャッシュサーバが保持し、且つ情報を要求する端末に対しては適切に復号させるための技術を提供することを目的とする。

【課題を解決するための手段】

【0005】

ネットワークシステムは、データファイルを配信する配信サーバと、データファイルをキャッシュするキャッシュサーバと、データファイルを受信する端末とを含む。配信サーバは、端末からデータファイルの送信要求を受けた場合、要求されたデータファイルに対して対応付けられた識別情報を端末に送信する配信制御部と、暗号化されたデータファイルを復号するための鍵を端末に送信する鍵管理部とを備える。また、キャッシュサーバは、端末から識別情報を含むデータファイルの送信要求を受けた場合、要求された識別情報と対応付けてデータファイルを記憶装置にキャッシュしているときは、当該データファイルを端末に送信し、要求された識別情報と対応付けてデータファイルを記憶装置にキャッシュしていないときは、暗号化された当該データファイルを配信サーバから受信し、記憶装置に格納するキャッシュ管理部を備える。

【0006】

配信サーバ、キャッシュサーバ、及び端末が、識別情報を用いてデータファイルを特定するため、データファイル自体は暗号化された状態でもネットワークシステム上にキャッシュし、配信サーバにかかる負荷を低減させることができる。また、キャッシュサーバに対しては、例えばＵＲＩ（Uniform Resource Identifier）のようなオリジナルのデータ
ファイルを特定するための情報を秘匿することができる。

【0007】

また、識別情報は、当該識別情報と対応付けられるデータファイル、又は当該データファイルのネットワーク上のアドレスから所定の一方向性関数を用いて求められる値であってもよい。このようにすれば、配信サーバは、識別情報を容易に生成することができ、また、キャッシュサーバにおいてもサイズの大きなテーブルに識別情報を記憶させておく必要がなくなる。

【0008】

また、配信サーバと端末とは、配信制御部が行う処理において暗号化通信を行うためのセッションを確立し、鍵管理部が行う処理においてセッションを再開するようにしてもよい。このようにすれば、端末に対し、データファイルを復号するための情報を、適切なタイミングで送信することができる。

【0009】

また、本発明の他の側面に係る配信サーバは、データファイルを配信し、データファイルをキャッシュするキャッシュサーバ、及びデータファイルを受信する端末と通信する。そして、配信サーバは、データファイルの送信要求を端末から受けた場合、要求されたデータファイルに対して対応付けられた識別情報を端末に送信し、当該識別情報を含むデータファイルの送信要求をキャッシュサーバから受けた場合、暗号化された当該データファイルをキャッシュサーバに送信する配信制御部と、暗号化されたデータファイルを復号するための鍵を端末に送信する鍵管理部とを備える。

【0010】

このようにすれば、識別情報を用いてデータファイルを特定するため、データファイル自体は暗号化された状態でも、ネットワークシステム上にキャッシュし配信サーバにかかる負荷を低減させることができる。

【0011】

また、キャッシュサーバは、データファイルを配信する配信サーバ、及びデータファイルを受信する端末と通信を行い、データファイルをキャッシュする。そして、端末から、要求するデータファイルの識別情報を含むデータファイルの送信要求を受けた場合、要求された識別情報と対応付けて暗号化されたデータファイルを記憶装置にキャッシュしているときは、当該暗号化されたデータファイルを端末に送信し、要求された識別情報と対応付けて暗号化されたデータファイルを記憶装置にキャッシュしていないときは、暗号化された当該データファイルを配信サーバから受信し、記憶装置に格納する。

【0012】

このようにすれば、識別情報を用いてデータファイルを特定するため、データファイル自体は暗号化された状態でもネットワークシステム上にキャッシュし、配信サーバにかかる負荷を低減させることができる。

【0013】

なお、課題を解決するための手段に記載の内容は、本発明の課題や技術的思想を逸脱しない範囲で可能な限り組み合わせることができる。また、課題を解決するための手段の内容は、コンピュータ等の装置若しくは複数の装置を含むシステム、コンピュータが実行する方法、又はコンピュータに実行させるプログラムとして提供することができる。なお、プログラムを保持する記録媒体を提供するようにしてもよい。

【発明の効果】

【0014】

本発明によれば、情報を暗号化した状態でキャッシュサーバが保持し、且つ情報を要求する端末に対しては適切に復号させるための技術を提供することができる。

【図面の簡単な説明】

【0015】

【図1】図１は、実施形態に係るネットワークシステムの構成の一例を示す図である。

【図2】図２は、配信サーバ、キャッシュサーバ、及び端末の構成の一例を示すブロック図である。

【図3】図３は、配信処理の一例を示す処理フロー図である。

【図4】図４は、配信サーバが記憶装置に記憶しているテーブルの一例を示す図である。

【図5】図５は、キャッシュサーバが記憶装置に記憶しているテーブルの一例を示す図である。

【図6】図６は、配信処理の一例を示す処理フロー図である。

【図7】図７は、配信処理の一例を示す処理フロー図である。

【図8】図８は、変形例に係るネットワークシステムの構成及び処理の一例を示す図である。

【発明を実施するための形態】

【0016】

以下、図面を参照して本発明を実施するための形態について説明する。

【0017】

＜システム構成＞
図１は、実施形態に係るネットワークシステムの構成の一例を示す図である。図１のネットワークシステム１は、例えば動画コンテンツ等のデータファイルを配信する配信サーバ２と、データファイルをキャッシュし、要求に応じてキャッシュしているデータファイルを送信するキャッシュサーバ３と、ユーザの操作に応じてデータファイルを要求する端末４（４Ａ～４Ｃ）とを含む。配信サーバ２、キャッシュサーバ３、端末４はいわゆるコンピュータであり、他のコンピュータと通信可能に接続され、データファイルを送受信する。本実施形態においては、配信サーバ２、キャッシュサーバ３、端末４の間でそれぞれＳＳＬ／ＴＬＳプロトコル等に従って暗号化通信を行う。通信路の暗号化に用いる鍵は、既存の技術を利用して生成することができる。例えば、データ本文を暗号化する共通鍵は、セッションごとに独立したものが使用され毎回異なる。また、通信経路の暗号化とは別に、データファイル自体も暗号化され、暗号化されたデータファイルがキャッシュサーバ３に保持されるものとする。図１のＣｏｎｔｅｎｔは、平文のデータファイルを表している。また、ｋは、コンテンツデータの暗号化及び復号に用いる共通鍵である。すなわち、コンテンツデータの暗号化には、通信路の暗号化とは独立した鍵が利用される。なお、共通鍵kは、コンテンツごとに異なるものが使用されるものとする。Ｅｎｃ_ｋ（Ｃｏｎｔｅ
ｎｔ）は、共通鍵ｋを用いて暗号化されたデータファイルである。また、Ｄｅｃｋ（Ｅｎｃｋ（Ｃｏｎｔｅｎｔ））は、共通鍵ｋを用いて復号されたデータファイルである。なお、ネットワークシステム１に含まれる、配信サーバ２、キャッシュサーバ３、端末４の数は、図１に示したものには限定されず、例えば複数の配信サーバ２やキャッシュサーバ３を含んでいてもよい。

【0018】

＜装置の構成＞
図２は、配信サーバ２、キャッシュサーバ３、及び端末４の構成の一例を示すブロック図である。

【0019】

＜配信サーバ＞
配信サーバ２は、通信インターフェース（Ｉ／Ｆ）２１と、記憶装置２２と、入出力装置２３と、プロセッサ２４と、バス２５とを備えている。通信Ｉ／Ｆ２１は、例えば通信モジュールやネットワークカードであり、所定のプロトコルに基づき、キャッシュサーバ３や端末４等のコンピュータと通信を行う。

【0020】

記憶装置２２は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等の主記憶装置（一次記憶装置）及びＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置（二次記憶装置）である。主記憶装置は、プロセッサが読み出したプログラムやデータを一時的に記憶したり、プロセッサの作業領域を確保したりする。補助記憶装置は、プロセッサが実行するプログラムや、配信するデータ
ファイル等を記憶する。入出力装置２３は、例えばキーボード、マウス等の入力装置や、モニタ等の出力装置、タッチパネル等のユーザインターフェースである。

【0021】

プロセッサ２４は、ＣＰＵ（Central Processing Unit）等の演算処理装置であり、ア
プリケーションを実行することにより本実施の形態に係る各処理を行う。配信サーバ２は、プロセッサ２４内に機能ブロックを示している。すなわち、プロセッサ２４は、配信制御部２４１、及び鍵管理部２４２として機能する。配信制御部２４１は、キャッシュサーバ３や端末４からの要求に応じて、データファイルや、当該データファイルと対応付けられた識別情報を送信する。なお、データファイルを対応付けられた識別情報を、本実施形態では「タグ」と呼ぶものとする。タグは、データファイル、又は当該データファイルのネットワーク上のアドレスから所定のハッシュ関数を用いて求められるハッシュであってもよいし、データファイルとは無関係に付与されるランダムな文字列であってもよい。また、本実施形態では、データファイルに対し所定の方式で暗号化を施しておき、端末４においてデータファイルを読み出すためには復号鍵が必要になるものとする。鍵管理部２４２は、所定のタイミングで、データファイルを復号するための復号鍵を端末４へ送信する。例えば、キャッシュサーバ３から端末４へ暗号化されたデータファイルが送信された後に、鍵管理部２４２は、端末４へ復号鍵を送信する。

【0022】

以上のような構成要素が、バス２５を介して接続されている。

【0023】

＜キャッシュサーバ＞
図２に示すように、キャッシュサーバ３も、通信Ｉ／Ｆ３１と、記憶装置３２と、入出力装置３３と、プロセッサ３４と、バス３５とを備えている。

【0024】

通信Ｉ／Ｆ３１は、例えば通信モジュールやネットワークカードであり、所定のプロトコルに基づき、他のコンピュータと通信を行う。例えば、端末４及び配信サーバ５との間においてデータファイルを送受信する。記憶装置３２は、ＲＡＭやＲＯＭ等の主記憶装置及びＨＤＤやＳＳＤ、フラッシュメモリ等の補助記憶装置である。主記憶装置は、プロセッサが読み出したプログラムやデータを一時的に記憶したり、プロセッサの作業領域を確保したりする。補助記憶装置は、プロセッサが実行するプログラムや、暗号化されたデータファイルを上述したタグと対応付けて記憶する。入出力装置３３は、例えばキーボード、マウス等の入力装置や、モニタ等の出力装置、タッチパネル等のユーザインターフェースである。

【0025】

プロセッサ３４は、ＣＰＵ等の演算処理装置であり、アプリケーションを実行することにより本実施の形態に係る各処理を行う。キャッシュサーバ３においても、プロセッサ３４内に機能ブロックを示している。すなわち、プロセッサ３４は、キャッシュ管理部３４１及び配信管理部３４２として機能する。キャッシュ管理部３４１は、タグを含むデータファイルの送信要求を端末４から受け、キャッシュヒットしたか否か表すデータを配信サーバ２へ送信する。配信管理部３４２は、端末４へ暗号化されたデータファイルを送信したり、キャッシュヒットしなかった場合に配信サーバ２から暗号化されたデータファイルを受信してキャッシュしたりする。

【0026】

以上のような構成要素が、バス３５を介して接続されている。

【0027】

＜端末＞
端末４は、ＰＣ（Personal Computer）、スマートフォン、タブレット等のコンピュー
タであり、通信Ｉ／Ｆ４１と、記憶装置４２と、入出力装置４３と、プロセッサ４４と、バス４５とを備えている。通信Ｉ／Ｆ４１は、例えば有線のネットワークカード又は無線の通信モジュールであり、所定のプロトコルに基づき、他のコンピュータと通信を行う。
例えば、キャッシュサーバ３から暗号化されたデータファイルを受信する。記憶装置４２は、ＲＡＭやＲＯＭ等の主記憶装置及びＨＤＤやＳＳＤ、フラッシュメモリ等の補助記憶装置である。主記憶装置は、プロセッサが読み出したプログラムやデータファイルを一時的に記憶したり、プロセッサの作業領域を確保したりする。補助記憶装置は、プロセッサが実行するプログラムやデータファイル等を記憶する。入出力装置４３は、例えばキーボード、マウス等の入力装置や、モニタ等の出力装置、タッチパネル等のユーザインターフェースである。例えば、ユーザは、入出力装置４３を介して配信サーバ２に対しデータファイルの送信を要求したり、受信したデータファイルを読み出して表示させたりする。

【0028】

プロセッサ４４は、ＣＰＵ等の演算処理装置であり、プログラムを実行することにより本実施の形態に係る各処理を行う。端末４についても、プロセッサ４４内に機能ブロックを示している。すなわち、プロセッサ４４は、要求処理部４４１及び復号処理部４４２として機能する。要求処理部４４１は、配信サーバ２に対し、データファイルの送信を要求するとともに、配信サーバ２からデータファイルに対応付けられたタグを受信し、タグを用いてキャッシュサーバ３へデータファイルの送信を要求する。また、要求処理部４４１は、キャッシュサーバ３から、タグに対応する、暗号化されたデータファイルを受信する。復号処理部４４２は、配信サーバ２から復号鍵を受信し、暗号化されたデータファイルを復号して再生する。

【0029】

以上のような構成要素が、バス４５を介して接続されている。

【0030】

このように、本実施形態に係るネットワークシステム１は、タグを用いてデータファイルを特定することにより、キャッシュサーバ３に暗号化されたデータファイルを保持させることができる。そして、当該データファイルに対する送信要求に対し、キャッシュサーバ３から配信を行うことにより、ネットワーク上のトラフィックを削減することができる。また、上述した通り、タグは、例えば原像計算困難性（一方向性）を有するハッシュのように、データファイルの平文データやアドレスとは無関係に付与される値である。そして、データファイルの復号鍵は、配信サーバ２と端末４との間の暗号化通信において送受信される。したがって、キャッシュサーバ３は端末４から要求されたデータファイルの内容を復号することはできず、端末４のユーザのプライバシーが守られる。

【0031】

＜配信処理＞
図３は、配信処理の一例を示す処理フロー図である。端末４のユーザが、例えばコンテンツのデータファイルの配信を要求する操作を行うと、図３以降に示すような配信処理が開始される。また、図３においては、２つの装置間に確立されるＨＴＴＰＳのセッションを、二点鎖線の角丸長方形で示している。ＨＴＴＰＳのセッションにおいては、２つの装置間で共有される共通鍵を利用して、例えばＡＥＳ方式等の暗号化方式により通信の内容が暗号化される。

【0032】

まず、端末４の要求処理部４４１は、通信Ｉ／Ｆ４１を介して配信サーバ２に対し、データファイルを要求する旨のデータが送信される（図３：Ｓ１）。本ステップにおいては、例えばＵＲＩのようなデータファイルのＩＤ（「コンテンツＩＤ」とも呼ぶ）を含む、データファイルの送信要求が送信される。また、本ステップの実行に際し、上述したＨＴＴＰＳのセッションが開始されているものとする。

【0033】

一方、配信サーバ２は、データファイルのＩＤと、タグと、データファイルの暗号化に用いる鍵とを対応付けて、予め記憶装置２２に保持しているものとする。図４は、配信サーバ２が記憶装置２２に記憶しているテーブルの一例を示す図である。図４に示すテーブルは、「コンテンツ」、「タグ」、「鍵」の各属性を含む。「コンテンツ」のフィールドには、配信サーバ２が配信するコンテンツＩＤが登録される。「タグ」のフィールドには
、データファイルから所定の関数に基づいて又は所定のテーブルを参照して求めることができる一方向性を有し、データファイルの識別情報として利用されるタグが登録される。タグは、例えばＵＲＩやデータファイルの平文からＨＭＡＣ（Hash-based Message Authentication Code）を利用して作成されるハッシュ値であってもよいし、配信サーバ２がデータファイルに対してランダムに作成した値であってもよい。なお、本実施形態においては、タグはデータファイルの識別情報として利用されるため、例えば２５６ビット程度のように、データファイルの数に応じて衝突を避けるために十分な大きさを有することが好ましい。「鍵」のフィールドには、データファイルを暗号化及び復号するための共通鍵が登録される。鍵のサイズは暗号化方式に従い、例えば１２８ビット等の大きさを有することが好ましい。

【0034】

配信サーバ２の配信制御部２４１は、通信Ｉ／Ｆ２１を介して端末４からデータファイルの要求を受けた場合、要求に含まれるコンテンツＩＤに対応付けられたタグをテーブルから読み出し、通信Ｉ／Ｆ２１を介して端末４へ送信する（図３：Ｓ２）。本ステップでは、配信制御部２４１は、要求されたコンテンツに対応するタグを、例えば図４に示したテーブルから抽出して端末４へ送信する。

【0035】

一方、端末４の要求処理部４４１は、配信サーバ２からタグを受信すると（図３：Ｓ３）、タグを用いてキャッシュサーバ３に対しキャッシュファイルの送信を要求する（図３：Ｓ４）。本ステップでは、要求処理部４４１は、Ｓ３で受信したタグを含む要求を、通信Ｉ／Ｆ４１を介してキャッシュサーバ３へ送信する。また、要求は、端末４又は当該端末を使用するユーザのＩＤや、配信サーバ２のＩＤをさらに含むものであってもよい。なお、端末４とキャッシュサーバ３との間でもＨＴＴＰＳのセッションが開始され、暗号化通信が行われるものとする。

【0036】

キャッシュサーバ３は、上述の通り暗号化されたデータファイルをキャッシュする機能を有するが、配信サーバ２が配信するデータファイルをすべてキャッシュしているとは限らない。図５は、キャッシュサーバ３が記憶装置３２に記憶しているテーブルの一例を示す図である。図５に示すテーブルは、「暗号化コンテンツ」、「タグ」の各属性を含む。「暗号化コンテンツ」のフィールドには、キャッシュサーバ３がキャッシュしている、暗号化されたデータファイルのＩＤが登録される。暗号化されたデータファイルのＩＤは、記憶装置３２上のデータファイルの所在を表すファイルパスであってもよいし、ファイルパスを一意に特定するための識別情報であってもよい。「タグ」のフィールドには、当該データファイルに対して配信サーバ２によって対応付けられたタグが登録される。このように、キャッシュサーバ３が保持する情報からは、データファイルの内容を復号することができず、また、データファイルのオリジナルの所在を特定することもできない。

【0037】

キャッシュサーバ３のキャッシュ管理部３４１は、通信Ｉ／Ｆ３１を介して端末４からキャッシュファイルの要求を受けた場合、要求されたファイルをキャッシュしているか判断する（図３：Ｓ５）。本ステップでは、例えば、要求されたタグが、図５に示したテーブルに登録されている場合にキャッシュがヒットしたと判断し、登録されていない場合にキャッシュがヒットしなかったと判断する。

【0038】

キャッシュがヒットしなかった場合（Ｓ５：ＮＯ）、接続子「Ａ」を介して図６の処理に遷移する。図６は、配信処理の一例を示す処理フロー図である。そして、キャッシュサーバ３の配信管理部３４２は、通信Ｉ／Ｆ３１を介して配信サーバ２へ、キャッシュミスを通知する（図６：Ｓ６）。本ステップにおいては、例えば端末４から要求されたデータファイルのタグと、端末４又は当該端末を使用するユーザのＩＤと、キャッシュヒットしなかった旨を示す情報とが通知される。なお、キャッシュサーバ３と配信サーバ２との間でもＨＴＴＰＳのセッションが開始され、暗号化通信が行われるものとする。

【0039】

一方、配信サーバ２の配信制御部２４１は、通信Ｉ／Ｆ２１を介してキャッシュサーバ３からキャッシュミスの通知を受けた場合、通信Ｉ／Ｆ２１を介してキャッシュサーバ３へ、暗号化されたデータファイル（「暗号化コンテンツ」とも呼ぶ）を送信する（図６：Ｓ７）。本ステップでは、図４の「コンテンツ」のフィールドに登録されているデータファイル（コンテンツ）が、当該データファイルに対応付けられて「鍵」のフィールドに登録されている共通鍵によって暗号化され、配信制御部２４１によって送信される。なお、配信サーバ２においては、あらかじめ暗号化コンテンツを記憶部２２に保持させておき、送信時のコンテンツ暗号化処理を省略してもよい。

【0040】

また、キャッシュサーバ３のキャッシュ管理部３４１は、通信Ｉ／Ｆ３１を介して配信サーバ２から暗号化コンテンツを受信すると、受信した暗号化コンテンツを記憶装置３２に記憶させると共に、図５に示したテーブルに暗号化コンテンツとタグとを対応付けて記憶させる（図６：Ｓ８）。

【0041】

また、キャッシュ管理部３４１は、通信Ｉ／Ｆ３１を介して端末４に、暗号化コンテンツを送信する（図６：Ｓ９）。本ステップは、Ｓ４において開始されたＨＴＴＰＳのセッションが再開され、キャッシュサーバ３と端末４との間で暗号化通信が行われるものとする。セッションの再開は、例えば既存のセッションリサンプション手法により行うことができる。一方、端末４の要求処理部４４１は、通信Ｉ／Ｆ４１を介して暗号化コンテンツを受信し、記憶装置４２に記憶させる。

【0042】

また、配信サーバ２の鍵管理部２４２は、Ｓ６においてキャッシュミスの通知を受け、キャッシュサーバ３へ暗号化コンテンツを送信した後に、通信Ｉ／Ｆ２１を介して、暗号化コンテンツを復号するための共通鍵を端末４へ送信する（図６：Ｓ１０）。本ステップは、Ｓ１において開始されたＨＴＴＰＳのセッションが再開され、配信サーバ２と端末４との間で暗号化通信が行われるものとする。

【0043】

そして、端末４の復号処理部４４２は、通信Ｉ／Ｆ４１を介して共通鍵を受信し、当該共通鍵を用いて、Ｓ９で受信した暗号化コンテンツを復号する（図６：Ｓ１１）。このようにして、端末４は所望のデータファイルを配信サーバ２から取得し、その内容を読み出すことができる。

【0044】

なお、キャッシュミスの場合は、配信サーバ２から端末４へ、直接暗号化コンテンツを送信するようにしてもよい。また、キャッシュサーバ３は、所定の規則に基づいて暗号化コンテンツをキャッシュするか否か判断するようにしてもよいし、配信サーバ２等によっていずれの暗号化コンテンツをキャッシュすべきか制御されるようにしてもよい。

【0045】

また、図３のＳ５においてキャッシュヒットしたと判断され場合（Ｓ５：ＹＥＳ）、接続子「Ｂ」を介して図７の処理に遷移する。図７は、配信処理の一例を示す処理フロー図である。そして、キャッシュサーバ３の配信管理部３４２は、通信Ｉ／Ｆ３１を介して配信サーバ２に対し、キャッシュヒットを通知する（図７：Ｓ１２）。本ステップにおいては、例えば端末４を一意に特定するための識別情報と、端末４から要求されたデータファイルのタグと、キャッシュヒットした旨を示す情報とが通知される。これにより、配信サーバ２もキャッシュヒットしたことを把握することができ、キャッシュヒットした場合は、配信サーバ２からキャッシュサーバ３への暗号化コンテンツの送信は行われない。なお、本ステップにおいても、キャッシュサーバ３と配信サーバ２との間でＨＴＴＰＳのセッションが開始され、暗号化通信が行われる。

【0046】

そして、キャッシュサーバ３のキャッシュ管理部３４１は、通信Ｉ／Ｆ３１を介して端
末４に、暗号化コンテンツを送信する（図７：Ｓ１３）。本ステップは、図６のＳ９と同様である。

【0047】

また、配信サーバ２の鍵管理部２４２は、Ｓ１２においてキャッシュヒットの通知を受けた後に、通信Ｉ／Ｆ２１を介して、暗号化コンテンツを復号するための共通鍵を端末４へ送信する（図７：Ｓ１４）。キャッシュヒットの通知は、端末４への鍵の送信要求を含むものであってもよい。本ステップは、図６のＳ１０と同様である。

【0048】

そして、端末４の復号処理部４４２は、通信Ｉ／Ｆ４１を介して共通鍵を受信し、当該共通鍵を用いて、Ｓ１３で受信した暗号化コンテンツを復号する（図７：Ｓ１５）。本ステップは、図６のＳ１１と同様である。このようにして、端末４は所望のデータファイルを配信サーバ２から取得し、その内容を読み出すことができる。

【0049】

＜効果＞
キャッシュヒットした場合に、キャッシュサーバ３から暗号化コンテンツを端末４へ送信することで、配信サーバ２へのアクセスの集中を抑制し、ネットワーク１上のトラフィックを削減することができる。また、上述のタグを利用することで、ＨＴＴＰＳ等による暗号化通信を行う場合であっても、データファイルをネットワーク上にキャッシュすることができると共に、キャッシュサーバ３においてはキャッシュしているデータファイルの内容を特定したり、読み出したりすることができないようになっている。暗号化コンテンツを復号するための鍵は、暗号化コンテンツとは別のホストから、また、キャッシュサーバにおいてキャッシュヒットしたか否かを配信サーバが把握した後のタイミングで、端末へ送信される。このとき、暗号化通信のセッションを再開して鍵を送信することにより鍵を適切に管理することができる。

【0050】

＜変形例＞
上述の実施形態に係るネットワークシステムは、暗号化コンテンツを送信する通信路と暗号化コンテンツの復号鍵を送信する通信路とが独立している。そこで、配信サーバ２は、端末４に対し利用可能な通信路を限定するようにしてもよい。例えば、図３のＳ２において配信サーバ２が端末４へタグを送信した後に、さらにキャッシュサーバ３を指定すると共に指定されたキャッシュサーバ３にアクセスからのみ暗号化コンテンツを取得できるようにする。また、配信サーバ２は、さらにタグの有効期限を設定し、一定時間以内に端末４がキャッシュサーバ３から暗号化コンテンツを取得しなければタグを無効にしてもよい。有効期限を適切に設定することで、仮に第三者が不正に鍵及びタグを取得しても、キャッシュサーバからの暗号化コンテンツの取得を制限できるようになる。

【0051】

図８は、変形例に係るネットワークシステムの構成及び処理の一例を示す図である。本変形例では、正規のユーザが使用する端末４Ｃからコンテンツへのリクエストが送信されると（図８（１））、配信サーバ２は本変形例に係る代替タグと、アクセス先のキャッシュサーバ３の識別情報とを端末４Ｃへ送信する（図８（２））。

【0052】

代替タグは、タグ、ユーザＩＤ及び時刻を含むものとする。タグは、上述の通り例えば一方向性関数により又はランダムに生成されるコンテンツの識別情報である。ユーザＩＤは、端末４Ｃのユーザの識別情報であり、Ｃｏｏｋｉｅの一部であってもよいし、アクセス元のＩＰアドレス等であってもよい。時刻は、有効期限の始期又は終期を示す情報であり、例えば代替タグを生成した日時や代替タグを失効させる日時であってもよい。また、代替タグは所定の鍵（便宜上「タグ鍵」と呼ぶ）で暗号化されており、端末４Ｃは復号することができないものとする。なお、配信サーバ２は、端末４Ｃがキャッシュの送信を要求すべき（すなわち、アクセス先の）キャッシュサーバ３を決定し、決定されたキャッシュサーバ３Ａとの間で共有された共通鍵を用いて代替タグを暗号化して端末４Ｃへ送信す
る。したがって、配信サーバ２が決定したアクセス先のキャッシュサーバ３Ａのみが、代替タグを復号できる。

【0053】

また、端末４Ｃは、指定されたアクセス先のキャッシュサーバ３Ａへ代替タグを含むリクエストを送信する（図８（３））。キャッシュサーバ３Ａは、予め保持しているタグ鍵で代替タグを復号する（図８（４））。そして、キャッシュサーバ３Ａは、代替タグに含まれていたタグ及びユーザＩＤを含むコンテンツのリクエストを、配信サーバ２へ送信する（図８（５））。このとき、キャッシュサーバ３Ａは、復号が成功したか判断し、予め保持しているタグ鍵で代替タグの復号に失敗した場合は処理を中断してもよい。また、キャッシュサーバ３Ａは、代替タグに含まれていた時刻に基づいて所定の有効期限内であるか判断し、有効期限内でない場合は処理を中断してもよい。また、キャッシュサーバ３Ａは、代替タグに含まれていたユーザＩＤに基づいて要求元の端末４ＣとユーザＩＤとが予め定められた適切な組み合わせであるか判断し、適切な組み合わせでない場合は処理を中断してもよい。

【0054】

一方、コンテンツのリクエストを受信した配信サーバ２は、タグに対応付けられた暗号化コンテンツを読み出し、キャッシュサーバ３Ａへ送信する（図８（６））。本ステップは、図６のＳ７と同様である。そして、キャッシュサーバ３Ａは端末４Ｃへ暗号化コンテンツを送信する（図８（７））。本ステップは、図６のＳ９と同様である。また、配信サーバ２は、コンテンツの暗号化に使用した共通鍵を端末４Ｃへ送信する（図８（８））。本ステップは、図６のＳ１０と同様である。このようにして、端末４Ｃにおいて暗号化コンテンツを復号して再生できるようになる。

【0055】

また、不正なユーザが使用する端末４Ｄが、仮に暗号化された代替タグを入手したとしても、適切なアクセス先でないキャッシュサーバ３Ｂにおいては代替タグを復号できず処理が中断される。また、適切なアクセス先であるキャッシュサーバ３Ａにおいても、端末４Ｄからのリクエストに対しては、有効期限内でないことや、ユーザＩＤと端末４Ｄとの組み合わせの適切性により、処理が中断される。このように、本変形例によれば、鍵及びタグを不正なユーザが取得したとしても、コンテンツの閲覧を制限できる。

【0056】

＜その他＞
実施形態及び変形例の構成は例示であり、本発明は上述した構成に限定されない。また、実施形態及び変形例に示した構成は、本発明の課題や技術的思想を逸脱しない範囲で可能な限り組み合わせることができる。

【0057】

なお、キャッシュされるデータファイルは、動画や音楽等のコンテンツに限らず、文書やアプリケーションの実行ファイル等、コンピュータによって生成、読み出し、書き込み、記憶等される様々な電子データであってもよい。また、配信サーバ２は、端末４のユーザがデータファイルにアクセスする権限を有するか、例えばユーザに対して発行されたＩＤやパスワード等に基づいてさらに判断するようにしてもよい。

【0058】

また、キャッシュされるコンテンツの暗号化には、例えばＡＥＳ１２８－ＧＣＭのように、ＭＡＣを付加して改ざんを検知できる暗号化方式を採用してもよい。また、キャッシュされていた暗号化コンテンツを端末４で復号できなかった場合、再度暗号化コンテンツをキャッシュサーバ３にキャッシュし直すようにしてもよい。

【0059】

本発明は上述の処理を実行するコンピュータプログラムを含む。さらに、当該プログラムを記録した、コンピュータ読み取り可能な記録媒体も、本発明の範疇に属する。当該プログラムが記録された記録媒体については、コンピュータに、この記録媒体のプログラムを読み込ませて実行させることにより、上述の処理が可能となる。

【0060】

ここで、コンピュータ読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータから取り外し可能なものとしては、フレキシブルディスク、光磁気ディスク、光ディスク、磁気テープ、メモリカード等がある。また、コンピュータに固定された記録媒体としては、ハードディスクドライブやＲＯＭ等がある。

【符号の説明】

【0061】

１ ：ネットワークシステム
２ ：配信サーバ
２１ ：通信Ｉ／Ｆ
２２ ：記憶装置
２３ ：入出力装置
２４ ：プロセッサ
２４１ ：配信制御部
２４２ ：鍵管理部
２５ ：バス
３ ：配信サーバ
３１ ：通信Ｉ／Ｆ
３２ ：記憶装置
３３ ：入出力装置
３４ ：プロセッサ
３４１ ：キャッシュ管理部
３４２ ：配信管理部
３５ ：バス
４ ：端末
４１ ：通信Ｉ／Ｆ
４２ ：記憶装置
４３ ：入出力装置
４４ ：プロセッサ
４４１ ：要求処理部
４４２ ：復号処理部
４５ ：バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】