JP2008009744A - コンテンツ管理システム - Google Patents

Abstract

【課題】 存在すべきでない認証処理を不要とするコンテンツ管理システムを提供する。
【解決手段】 ネットワーク上のサーバー装置に対しブラウズリクエストを行う手段と、サーバー装置からの前記リクエストに応答するブラウズレスポンスを受信する手段と、前記レスポンス受信時にユーザーへこのレスポンス内容を通知する手段と、前記リクエストにユーザー設定による非公開コンテンツへのアクセスキーを付加する手段とを具備することを特徴とするクライアント装置と、ネットワーク上のクライアント装置からのブラウズリクエストを受信する手段と、前記リクエスト受信時に非公開コンテンツへのユーザー設定によるアクセスキーに関するリクエスト内容に対応したコンテンツ処理を行いブラウズレスポンスとして送信する手段とを具備することを特徴とするサーバー装置とから構成されることを特徴とするコンテンツ管理システム。
【選択図】 図５

Description

本発明は、コンテンツサーバーとクライアントからなるコンテンツ管理システムに関する。

周知のように、近年では家電機器のデジタル化が進展している。例えば日本国内では、衛星ＢＳ（broadcasting satellite）デジタル放送、地上デジタル放送を受信、再生する機能を持った液晶等の薄型デジタルＴＶ（television）や、アナログ放送番組を受信し、内蔵したＨＤＤ（hard disk drive）にデジタル記録するＨＤＤ−ＤＶＤ（digital versatile disk）レコーダ等が、急速に家庭内に普及してきている。

これらのデジタル家電機器の中には、ＰＣ（personal computer）を含めてネットワーク接続機能を持つ機器も多く存在する。このため、例えば、デジタルＴＶのようなコンテンツ表示装置がクライアント機器として動作し、別の部屋にあるサーバー機能を持つＰＣやＨＤＤ−ＤＶＤレコーダに保存されたコンテンツに家庭内ネットワークを介してアクセスすることで、コンテンツが物理的に存在する場所に移動することなくコンテンツを楽しむことが簡単にできるようになる。

ところで、上記のような家庭内ネットワークにおいては、ネットワーク上のサーバー機器に複数のユーザーが各自個別にコンテンツを保存することがある。また、前記コンテンツについては他のユーザーに公開したいもの、非公開としたいものの２つに分類されることが多い。

このような分類を行う際に非公開としたいものはパスワードを求める処理を行う方法が提案されている。例えば特許文献１によるものは、クライアント機器側においてサーバー機器に対して処理要求をした後に、ユーザーがパスワードを入力しクライアント機器が送信することが記されている。この方式においては、問題点として以下の２点があり総称すれば存在すべきでない認証処理が必要という問題があった。

１．ブラウズリクエスト時にパスワード認証等を行うことにより、少なくともそこにアクセス制限のかけられたコンテンツがあることが分かる。
２．ブラウズリクエストの後に、さらにパスワード認証フェーズがあり、余計な処理が必要になる。
特開２００４−３４１６５７号公報（第４５頁、図１６）

本発明は、存在すべきでない認証処理を不要とするコンテンツ管理システムを提供することを目的とする。

上記課題を解決するために、本発明のコンテンツ管理システムは、ネットワーク上のサーバー装置に対しブラウズリクエストを行う手段と、サーバー装置からの前記リクエストに応答するブラウズレスポンスを受信する手段と、前記レスポンス受信時にユーザーへこのレスポンス内容を通知する手段と、前記リクエストにユーザー設定による非公開コンテンツへのアクセスキーを付加する手段とを具備することを特徴とするクライアント装置と、ネットワーク上のクライアント装置からのブラウズリクエストを受信する手段と、前記リクエスト受信時に非公開コンテンツへのユーザー設定によるアクセスキーに関するリクエスト内容に対応したコンテンツ処理を行いブラウズレスポンスとして送信する手段とを具備することを特徴とするサーバー装置とから構成されることを特徴とする。

本発明によれば、存在すべきでない認証処理を不要とするコンテンツ管理システムが得られる。

以下、本発明の実施例を説明する。

本発明による実施例１を図１乃至図７を参照して説明する。
図１は、この発明の一実施例を示すコンテンツサーバーとクライアントの接続構成図である。図１では、色々な記録コンテンツを保有するサーバー装置１と、デジタルＴＶであるクライアント装置２とがＬＡＮなどのインタフェースを用いて場合によりルーター３等の制御のもとにネットワーク接続されている。

図２は、コンテンツサーバーにおけるコンテンツ管理テーブルの一例である。ＨＤＤ−ＤＶＤレコーダに関するコンテンツの例である。
コンテンツの種別としてはここではフォルダとファイル（例えば録画プログラム、他に配信番組や市販のＤＶＤ）がある。各コンテンツには題名があり、アクセスキーが付加されているものがある。ここでアクセスとは特にフォルダの操作やファイル内容の視聴とそのための関連対象の表示、操作を意味する。

ＨＤＤ−ＤＶＤレコーダでユーザーが用意した４つのフォルダと２つのコンテンツの中身や参照情報をサーバー１に取り込んだ状態を表している。図１では図示せぬＨＤＤ−ＤＶＤレコーダ自身がコンテンツサーバーとなってもよい。うち１つのフォルダと１つのコンテンツには同じ”20060220”というアクセスキーが付与されている。ユーザーがサーバー機器にコンテンツを登録する際、非公開に分類したいコンテンツについては個別にアクセスキーも登録できるようにする。ＨＤＤ−ＤＶＤレコーダにおいて例えばそのＲＧＢビデオ出力に接続されているモニタをユーザーが見て対話的にレコーダのリモコンの数字キー等を用いて予めアクセスキーを入力しておく等ができる機能を設けるといった方法による。フォルダの場合は作成時以後、ファイルの場合は録画予約時以後、利用までに入力しておけばよい。アクセスキーは数字でなくてもよく、ユーザーが記憶しておくか別途ひかえる等しておけばよい。

図３は、クライアントにおけるＧＵＩ(Graphical User Interface)配置例である。コンテンツのタイトル一覧の表示領域３１、コンテンツに対するアクセスキー設定箇所３２、選択されたコンテンツのプレビュー画面領域３３がある。以下、動作を説明する。

図４は、アクセスキーを入力しない場合のＧＵＩブラウズ結果例である。図２におけるアクセスキーが付与されていない３つのフォルダと１つのファイルが表示されている。クライアント装置２からブラウズリクエストを行いサーバー装置１からブラウズレスポンスが来た結果を表示している。ユーザーがクライアント装置２においてアクセスキーの入力を行わずにリモコン等を用いてブラウズリクエストを指示した結果である。

図５は、この表示を得るためのコンテンツ管理の処理フローチャートである。通常のアクセスの場合すなわちアクセスキー設定箇所３２においてアクセスキーを設定しない場合は図５のフローチャートにおいて、クライアント装置２はブラウズリクエストを行うためのブラウズリクエストメッセージを作成し（ステップＳＣ０１）、次にアクセスキーの設定無しと判定し（ステップＳＣ０２）、ブラウズリクエストメッセージをそのままで送信し（ステップＳＣ０３）、サーバー装置１はこのブラウズリクエストメッセージを受信し（ステップＳＳ０１）、通常のブラウズレスポンスを行うためのブラウズレスポンスメッセージを作成し（ステップＳＳ０２）、ブラウズリクエストメッセージにアクセスキー情報が含まれていないのでステップＳＳ０３の処理は素通りし、クライアント側に送信（ステップＳＳ０４）した結果、図３のようなGUIでは、図４のようなアクセスキーの設定されていない公開コンテンツのみが表示される。

ブラウズリクエストを行うための具体的なブラウズリクエストメッセージの作成に関しては、例えばＵＰｎＰ(Universal Plug and Play)プロトコルの一つであるＳＯＡＰ(Simple Object Access Protocol)を用いて、ブラウズリクエストは次のように記述できる（以下、説明の不要な部分は省略してある）。ＨＴＴＰのＰＯＳＴメソッドを用いるリクエストメッセージのヘッダの一部分は、次のようになる。

POST /upnp/control/cds1 HTTP/1.1
SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Browse"

またこれに対するブラウズレスポンスは次のように記述できる。レスポンスメッセージのエンベロープの一部分は、3つのフォルダと１つのプログラムの題名に関して、次のようになる。

<dc:title>2006/02/11</dc:title>
<dc:title>2006/02/12</dc:title>
<dc:title>2006/02/13</dc:title>
<dc:title>ドラマ『××○○』</dc:title>
前記のようにコンテンツリストとしてブラウズできるレスポンス内容の通知後は、ユーザーはクライアント装置でリモコン等によりリスト中よりコンテンツを指定しその視聴を、ブラウズとは別のリクエストとレスポンスのサーバー装置との交換によって行うことができる。また、同様にリスト中よりコンテンツを指定しそのプレビューを、ブラウズや視聴とは別のリクエストとレスポンスの交換によって行うことができる。

また、非公開コンテンツにアクセスしたい場合には、ユーザーはクライアント装置２においてアクセスキーの入力をキーボード、リモコン等から行いアクセスキー設定箇所３２における入力内容表示を確認した後にブラウズリクエストを指示すればよい。その結果は図５のフローチャートにおいて、クライアント装置２はブラウズリクエストを行うためのブラウズリクエストメッセージを作成し（ステップＳＣ０１）、次にアクセスキーの設定有りと判定し（ステップＳＣ０２）、ブラウズリクエストメッセージにアクセスキー情報を付与し（ステップＳＣ０２Ａ）、このブラウズリクエストメッセージを送信し（ステップＳＣ０３）、サーバー装置１はこのブラウズリクエストメッセージを受信し（ステップＳＳ０１）、通常のブラウズレスポンスを行うためのブラウズレスポンスメッセージを作成し（ステップＳＳ０２）、ブラウズリクエストメッセージのアクセスキー情報に基づいて対応コンテンツがあるか判定し（ステップＳＳ０３）、対応コンテンツがある場合のみそのコンテンツ情報をブラウズレスポンスメッセージに付与し（ステップＳＳ０３Ａ）、クライアント側に送信（ステップＳＳ０４）しクライアント装置２でこれを受信した結果、図３のようなGUIでは、図６のようなアクセスキーが登録された非公開コンテンツを含むコンテンツのタイトル一覧が表示される。

上記の非公開コンテンツにアクセスする処理では非公開コンテンツにアクセスしない処理と比べＨＴＴＰのＰＯＳＴメソッドを用いるリクエストメッセージのヘッダ部分には、次のようなアクセスキー設定情報が更に付与になっている。

setkey.rd.toshiba.co.jp: 20060220
またこれに対するブラウズレスポンスは次のように記述できる。レスポンスメッセージのエンベロープ部分は、１つのフォルダと１つのプログラムの題名に関して、次のような対応コンテンツ情報が付与されている。

<dc:title>2006/02/20</dc:title>
<dc:title>映画『○○××』</dc:title>
ＳＯＡＰでは、レスポンスメッセージにはアクセスキー情報が含まれていないように記述できる。リクエストメッセージ情報がクライアント装置２に残らないか又は他のユーザーに知られないようにすればアクセスキーを秘密に管理することができる。また、リクエストメッセージのアクセスキー情報を暗号化してもよい。

なお上記のアクセスキー設定情報例はＳＯＡＰにおいて、ＨＴＴＰヘッダーフィールドの拡張フレームワークとして平文で記述されている（上記題名の記述例のようなＸＭＬ構造化テキストのようにより扱いの面倒な構文ではない）ことが特徴である。

図７は、フォルダ階層を示す説明図である。樹の夫々の分岐の最下層は録画プログラムのファイルあるいはより一般のコンテンツの場合もある。従来よりのＨＤＤ−ＤＶＤレコーダではフォルダを階層にできない型のものもあるが、他の機器によるコンテンツも想定した管理方法を説明する。

例えば、「2006/02/20」の題名のフォルダのＩＤ情報として次のものがある。
<container id="root/video/RD_00020000/RD_00020004/" parentID="root/video-

/RD_00020000/" childCount="2">
即ち、サーバーのrootディレクトリの下にvideoという映像コンテンツ関連をまとめて収容するためのフォルダがあり、その下にRD_00020000というＩＤが割り当てられたあるＨＤＤ−ＤＶＤレコーダ用のフォルダがある。これが図７の樹のトップのノードである。

その下のＡ１キーが設定されたノードがRD_00020004というＩＤが割り当てられた「2006/02/20」の題名のフォルダである。その下層には２つのコンテンツがある。

ここでＡ１はキー20060220を表し、Ａ２は他のキーを表すものとする。図７では「2006/02/20」の下層のコンテンツの一つへ「2006/02/20」と同じＡ１キーを設定している。図７（ａ）では、（ｂ）とは異なりキーがあるノードは上層とは破線で接続されていてクライアントからはブラウズできていないことを表す。（ｂ）のように皆ブラウズするためにはキーとしてＡ１とＡ２とをユーザーは入力する必要がある。

ユーザが指定するフォルダの位置、深さに対応してサーバー装置１において樹のポインタを設定することができる。例えばＡ２のみを入力しても通常は上層のＡ１キーが設定されたフォルダに遮蔽されて、サーバーでは樹のポインタがrootなど例えばＡ１キーが設定されたフォルダ以上の位置にあるときなどは、Ａ２キーが設定されたコンテンツまで樹を辿ることができない。クライアントからのブラウズリクエストのシーケンスに応じてカレントポインタまたはrootから適宜辿れるようにしてもよい。

なお、「ドラマ『××○○』」の題名のコンテンツのＩＤ情報は次のようである。
<item id="root/video/RD_00020000/RD_000101f5/" parentID="root/video-

/RD_00020000/" >
以上のようにユーザーによりアクセスキーが設定されたかどうかをサーバーが判定し、当該アクセスキーに対応したコンテンツをクライアントが表示させることにより、個別のコンテンツの公開・非公開を管理することができる。

本発明では、設定されたアクセスキーに応じて公開するコンテンツを変更することにより、コンテンツへのアクセスルートとアクセスキーを知らないユーザーに対してアクセス制限コンテンツの存在そのものを隠蔽できる。またブラウズと認証フェーズが一体化しており、処理が軽い。

なお、この発明は上記実施例に限定されるものではなく、この外その要旨を逸脱しない範囲で種々変形して実施することができる。
また、上記した実施の形態に開示されている複数の構成要素を適宜に組み合わせることにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除しても良いものである。さらに、異なる実施の形態に係る構成要素を適宜組み合わせても良いものである。

この発明の一実施例を示すコンテンツサーバーとクライアントの接続構成図。 同実施例のコンテンツ管理テーブルの一例を示す図。 同実施例のＧＵＩ配置例。 同実施例のアクセスキーを入力しない場合のブラウズ結果を示す図。 同実施例の処理フローチャート。 同実施例のアクセスキーを入力した場合のブラウズ結果を示す図。 同実施例のフォルダ階層を示す説明図。

符号の説明

１ サーバー装置
２ クライアント装置
３ ルーター
３１ コンテンツのタイトル一覧表示領域
３２ アクセスキー設定箇所（入力表示領域）
３３ プレビュー領域

Claims (6)

1. ネットワーク上のサーバー装置に対しブラウズリクエストを行う手段と、サーバー装置からの前記リクエストに応答するブラウズレスポンスを受信する手段と、前記レスポンス受信時にユーザーへこのレスポンス内容を通知する手段と、前記リクエストにユーザー設定による非公開コンテンツへのアクセスキーを付加する手段とを具備することを特徴とするクライアント装置と、
   ネットワーク上のクライアント装置からのブラウズリクエストを受信する手段と、前記リクエスト受信時に非公開コンテンツへのユーザー設定によるアクセスキーに関するリクエスト内容に対応したコンテンツ処理を行いブラウズレスポンスとして送信する手段とを具備し前記アクセスキーが付加されていない場合にはこのアクセスキーに相当する非公開コンテンツの存在をユーザーに察知されないようブラウズレスポンスを構成することを特徴とするサーバー装置とから
   構成されることを特徴とするコンテンツ管理システム。
2. ネットワーク上のサーバー装置に対しブラウズリクエストを行う手段と、
   サーバー装置からの前記リクエストに応答するブラウズレスポンスを受信する手段と、
   前記レスポンス受信時にユーザーへこのレスポンス内容を通知する手段と、
   前記リクエストにユーザー設定による非公開コンテンツへのアクセスキーを付加する手段とを
   具備することを特徴とするクライアント装置。
3. ネットワーク上のクライアント装置からのブラウズリクエストを受信する手段と、
   前記リクエスト受信時に非公開コンテンツへのユーザー設定によるアクセスキーに関するリクエスト内容に対応したコンテンツ処理を行いブラウズレスポンスとして送信する手段とを
   具備し前記アクセスキーが付加されていない場合にはこのアクセスキーに相当する非公開コンテンツの存在をユーザーに察知されないようブラウズレスポンスを構成することを特徴とするサーバー装置。
4. サーバー装置とクライアント装置とがSimple Object Access Protocolを用いて前記リクエストと前記レスポンスのためのメッセージを交換してサーバー装置からのレスポンスメッセージにはアクセスキー情報が含まれないようにアクセスキーを管理することを特徴とする請求項１記載のコンテンツ管理システム。
5. 前記リクエストにおけるアクセスキー情報をＳＯＡＰのＨＴＴＰヘッダーフィールドの拡張フレームワークとして構造化テキストによらず平文でサーバー装置にクライアント装置が送信することを特徴とする請求項４記載のコンテンツ管理システム。
6. ネットワーク上のサーバー装置に対しブラウズリクエストを行う手段と、
   サーバー装置からの前記リクエストに応答するブラウズレスポンスを受信する手段と、
   前記レスポンス受信時にユーザーへこのレスポンス内容を通知する手段と、
   前記リクエストにユーザー設定による非公開コンテンツへのアクセスキーを付加する手段とを
   具備し特定ユーザーのみにアクセスキー設定箇所を示すことを特徴とするクライアント装置。

Images