JP2008287407A - コンテンツ配信装置およびコンテンツ配信方法 - Google Patents

Abstract

【課題】選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うこと。
【解決手段】コンテンツＤＢ２０５は、閲覧者に対応付けて閲覧可能なコンテンツのコンテンツ情報を記憶している。閲覧要求受付部２０６は、閲覧要求をユーザ端末１００−１〜１００−ｍから受け付ける。ユーザ別ページ生成部２０７は、閲覧要求に含まれる閲覧者の識別情報をコンテンツＤＢ２０５から検索し、閲覧者が閲覧可能なコンテンツのコンテンツ情報を一覧できるユーザ別ページを生成する。変更要求受付部２０８は、変更要求をユーザ端末１００−１〜１００−ｍから受け付ける。ＤＢ更新部２１０は、変更要求に含まれる変更内容をコンテンツＤＢ２０５および公開先管理ＤＢ２０３に反映する。
【選択図】 図２

Description

本発明は、各々公開対象が設定されたコンテンツを保持する複数のコンテンツサーバに接続されたコンテンツ配信装置およびコンテンツ配信方法に関し、特に、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うことができるコンテンツ配信装置およびコンテンツ配信方法に関する。

近年、インターネット上ではソーシャルネットワーキングサービス（以下「ＳＮＳ」と略記する）と呼ばれるサービスが提供されている。ＳＮＳは、コミュニティ型の会員制サービスであり、登録制や招待制によって形成されたコミュニティ内でのコミュニケーションを支援するサービスである。すなわち、例えばブログと呼ばれる日記形式のコンテンツを投稿したユーザが、そのコンテンツを特定の他ユーザにのみ公開するなどという機能をＳＮＳにより実現することができる。このとき、コンテンツを投稿する投稿者ユーザは、他ユーザをあらかじめグループ分けしておき、特定のグループに所属するユーザにのみコンテンツを公開することも可能である。

ＳＮＳなどにおいて公開されるコンテンツには、例えば特許文献１に記載されたように、ユーザの閲覧時に付加情報が付加されることがある。特許文献１に記載された技術では、付加情報によって例えば公開期限などの公開に関する設定の変更が行われる。これにより、コンテンツの公開に関する設定を効率良くかつ容易に管理することができる。

特開２００５−２９３１５５号公報

ところで、最近ではＳＮＳにおいて公開されるコンテンツの種類は、上述したブログ以外にも例えば映画などに関するレビューや掲示板など多岐に渡るようになってきた。このため、コンテンツの種類別に設けられたコンテンツサーバにそれぞれのコンテンツのデータ（以下「コンテンツデータ」という）を記憶しておくシステム構成が採られることがある。このシステム構成によれば、コンテンツの種類の増加に対してコンテンツサーバを増設することで容易に対応することができる。

また、ＳＮＳにおいては、コンテンツの公開先として設定されたユーザに対して当該コンテンツが公開されるが、それぞれのユーザに対して公開されるコンテンツの一覧を提供する機能もＳＮＳには備えられている。

しかしながら、コンテンツサーバに記憶されるコンテンツが増加すると、コンテンツサーバ内からユーザが閲覧可能なコンテンツを検索するための処理負荷が大きくなるという問題がある。すなわち、ユーザが閲覧可能なコンテンツの一覧を要求した場合、このユーザが公開先として設定されているコンテンツデータを膨大なデータベースから検索するという処理が必要となる。特に、コンテンツデータが増加すれば必然的に各コンテンツデータの公開先として設定されるユーザの総数も増加すると考えられるため、条件に一致するコンテンツデータをデータベースから検索するコンテンツサーバの処理負荷は増大してしまう。

同時に、コンテンツおよびユーザの総数が増加すれば、コンテンツデータと公開先のユーザとの組み合わせが膨大な量になり、コンテンツの公開の対象となるユーザの管理が煩雑になるという問題がある。

本発明はかかる点に鑑みてなされたものであり、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うことができるコンテンツ配信装置およびコンテンツ配信方法を提供することを目的とする。

上記課題を解決するために、本発明は、各々公開先のユーザが設定されたコンテンツデータを保持する複数のコンテンツサーバに接続されたコンテンツ配信装置であって、前記複数のコンテンツサーバに記憶されたコンテンツデータの公開先となるユーザのユーザ情報と当該ユーザが公開先として設定されたコンテンツデータのコンテンツ情報とを対応付けるとともに、各ユーザ情報をコンテンツ情報の索引として記憶する記憶手段と、コンテンツデータの閲覧を要求する閲覧要求をユーザ端末から受信する受信手段と、前記受信手段によって受信された閲覧要求に含まれるユーザ情報に対応付けられたコンテンツ情報を前記記憶手段から検索し、検索されたコンテンツ情報の一覧を表示するためのユーザ別ページを生成する生成手段と、前記生成手段によって生成されたユーザ別ページを前記受信手段によって受信された閲覧要求の送信元のユーザ端末へ送信する送信手段とを有する構成を採る。

この構成によれば、閲覧者を索引として閲覧可能なコンテンツのコンテンツ情報が管理されるため、閲覧の要求があった場合に、閲覧者が閲覧可能なコンテンツを容易に検索することができる。結果として、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うことができる。

また、本発明は、上記構成において、コンテンツデータの投稿者のユーザ情報と当該投稿者が投稿したコンテンツデータの公開先に設定される閲覧者のユーザ情報とを対応付けて記憶する公開先管理手段をさらに有し、前記記憶手段は、前記公開先管理手段によって記憶された閲覧者のユーザ情報を索引として、投稿者が投稿したコンテンツデータのコンテンツ情報を記憶する構成を採る。

この構成によれば、投稿者が設定するコンテンツの公開先の閲覧者を投稿者別に管理することで、投稿者ごとのコンテンツの公開に関する設定を効率的に管理することができる。また、閲覧者のユーザ情報がコンテンツ情報の索引となるため、閲覧者ごとの閲覧可能なコンテンツの検索が容易に実行可能となる。

また、本発明は、上記構成において、前記記憶手段は、コンテンツデータの投稿者がコンテンツデータごとの公開先として設定するグループ情報と当該投稿者のユーザ情報とをコンテンツ情報にさらに対応付けて記憶する構成を採る。

この構成によれば、コンテンツの公開先となるユーザが投稿者によってグループ分けされる場合に、ユーザごとに閲覧可能なコンテンツに関する所属グループと投稿者のユーザ情報とを併せて管理することができる。

また、本発明は、上記構成において、投稿者がコンテンツデータの公開先のユーザを追加する際、追加されるユーザが所属するグループのグループ情報と投稿者のユーザ情報とに対応付けられたコンテンツ情報を前記記憶手段から検索し、検索されたコンテンツ情報のコピーを生成する複製手段と、前記複製手段によって生成されたコンテンツ情報のコピーと前記追加されるユーザのユーザ情報とを対応付けて前記記憶手段に追加記憶する追加手段とをさらに有する構成を採る。

この構成によれば、コンテンツデータの公開先のユーザを追加する際に、コンテンツサーバからコンテンツ情報を取得する必要がなく、コンテンツサーバへのアクセスが生じないため、コンテンツサーバにおける処理負荷を軽減することができる。

また、本発明は、上記構成において、コンテンツデータの投稿者のユーザ情報を当該コンテンツデータの公開先となるユーザのユーザ情報としてコンテンツ情報に対応付けて前記記憶手段に登録するマスターレコード登録手段をさらに有する構成を採る。

この構成によれば、コンテンツサーバに投稿されたコンテンツデータに関してコンテンツ情報を投稿者のユーザ情報に対応付けて登録するため、公開先の管理において投稿者が閲覧者のユーザ情報を削除したとしても、投稿者のユーザ情報に対応付けられたコンテンツ情報は削除されない。このため、公開先となるユーザを追加する際に、コピー元となるコンテンツ情報がすべて削除されてしまうことを防止することができる。

また、本発明は、各々公開先のユーザが設定されたコンテンツデータを保持する複数のコンテンツサーバに接続されたコンテンツ配信装置におけるコンテンツ配信方法であって、前記複数のコンテンツサーバに記憶されたコンテンツデータの閲覧を要求する閲覧要求をユーザ端末から受信する受信工程と、コンテンツデータの公開先となるユーザのユーザ情報と当該ユーザが公開先として設定されたコンテンツデータのコンテンツ情報とを対応付けるとともに、各ユーザ情報をコンテンツ情報の索引として記憶するデータベースから、前記受信工程にて受信された閲覧要求に含まれるユーザ情報に対応付けられたコンテンツ情報を検索する検索工程と、前記検索工程にて検索されたコンテンツ情報の一覧を表示するためのユーザ別ページを生成する生成工程と、前記生成工程にて生成されたユーザ別ページを前記受信工程にて受信された閲覧要求の送信元のユーザ端末へ送信する送信工程とを有するようにした。

この方法によれば、閲覧者を索引として閲覧可能なコンテンツのコンテンツ情報が管理されるため、閲覧の要求があった場合に、閲覧者が閲覧可能なコンテンツを容易に検索することができる。結果として、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うことができる。

本発明によれば、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うことができる。

本発明の骨子は、コンテンツを閲覧する閲覧者のユーザ情報を索引として、閲覧者が閲覧可能なコンテンツのインデックスとなるコンテンツ情報を専用のサーバにおいて管理するとともに、閲覧者からコンテンツの閲覧要求があった場合に、閲覧可能なコンテンツ情報の一覧を閲覧者へ提供することである。以下、本発明の一実施の形態について、図面を参照して詳細に説明する。

図１は、本発明の一実施の形態に係る通信ネットワークの概略構成を示す図である。同図に示す通信ネットワークにおいては、複数のユーザ端末１００−１〜１００−ｍ（ｍは１以上の整数）がネットワークＮを介して配信サーバ２００に接続されている。そして、配信サーバ２００は、複数のコンテンツサーバ３００−１〜３００−ｎ（ｎは１以上の整数）に接続されている。なお、ここでは説明の便宜上、コンテンツサーバ３００−１〜３００−ｎが配信サーバ２００に接続されるものとしたが、実際のネットワーク構成においては、ユーザ端末１００−１〜１００−ｍ、配信サーバ２００、およびコンテンツサーバ３００−１〜３００−ｎがそれぞれ互いにネットワークＮを介して接続されていても良い。

ユーザ端末１００−１〜１００−ｍは、コンテンツを投稿する投稿者やコンテンツを閲覧する閲覧者が操作する端末であり、投稿者がコンテンツを投稿する際には、コンテンツデータをコンテンツサーバ３００−１〜３００−ｎへ送信する。また、ユーザ端末１００−１〜１００−ｍは、閲覧者がコンテンツを閲覧する際には、閲覧要求を配信サーバ２００へ送信する。さらに、ユーザ端末１００−１〜１００−ｍは、投稿者がコンテンツの公開対象とする閲覧者を変更する際には、変更要求を配信サーバ２００へ送信する。

配信サーバ２００は、コンテンツサーバ３００−１〜３００−ｎに記憶されたそれぞれのコンテンツデータの公開対象となる閲覧者に関する情報をデータベース管理するとともに、それぞれの閲覧者に対して閲覧が許可されているコンテンツデータのコンテンツ情報を記憶している。すなわち、配信サーバ２００は、閲覧者を索引としてコンテンツサーバ３００−１〜３００−ｎに記憶されたコンテンツのコンテンツ情報を保持している。なお、コンテンツ情報は、コンテンツデータと１対１で対応するデータであり、コンテンツデータの一部分でも良いし、当該コンテンツデータの内容を指し示すタイトルのような情報であっても良い。

そして、配信サーバ２００は、ユーザ端末１００−１〜１００−ｍからコンテンツの閲覧要求を受信すると、閲覧者が閲覧可能なコンテンツのコンテンツ情報を含むユーザ別ページを生成し、ユーザ端末１００−１〜１００−ｍへ返信する。また、配信サーバ２００は、ユーザ端末１００−１〜１００−ｍから公開に関する設定の変更要求を受信すると、データベースの更新を実行する。なお、配信サーバ２００の構成および動作については、後に詳述する。

コンテンツサーバ３００−１〜３００−ｎは、コンテンツの種類に応じて設けられ、それぞれ種類が異なるコンテンツデータを記憶する。すなわち、コンテンツサーバ３００−１〜３００−ｎは、ユーザ端末１００−１〜１００−ｍから投稿される例えばブログ、レビュー、および掲示板などの異なる種類のコンテンツデータをそれぞれ記憶する。そして、コンテンツサーバ３００−１〜３００−ｎは、ユーザ端末１００−１〜１００−ｍから特定のコンテンツに対する閲覧要求を受信した場合には、このコンテンツデータをユーザ端末１００−１〜１００−ｍへ返信する。なお、コンテンツデータの量が多い場合には、２つ以上のコンテンツサーバ３００−１〜３００−ｎが同じ種類のコンテンツを記憶していても良い。

図２は、本実施の形態に係る配信サーバ２００の要部構成を示すブロック図である。図２に示す配信サーバ２００は、通信インタフェース部（以下「通信Ｉ／Ｆ部」と略記する）２０１、投稿情報取得部２０２、公開先管理データベース（以下「公開先管理ＤＢ」と略記する）２０３、レコード登録部２０４、コンテンツデータベース（以下「コンテンツＤＢ」と略記する）２０５、閲覧要求受付部２０６、ユーザ別ページ生成部２０７、変更要求受付部２０８、設定ページ生成部２０９、およびデータベース更新部（以下「ＤＢ更新部」と略記する）２１０を有している。

通信Ｉ／Ｆ部２０１は、ユーザ端末１００−１〜１００−ｍおよびコンテンツサーバ３００−１〜３００−ｎと通信するインタフェースであり、コンテンツサーバ３００−１〜３００−ｎにコンテンツが投稿されて記憶された場合に、このコンテンツのコンテンツ情報を含む投稿情報を受信する。また、通信Ｉ／Ｆ部２０１は、コンテンツの閲覧を要求する閲覧要求やコンテンツの公開に関する設定の変更を要求する変更要求をユーザ端末１００−１〜１００−ｍから受信する。さらに、通信Ｉ／Ｆ部２０１は、閲覧者ごとに閲覧可能なコンテンツを示すユーザ別ページやコンテンツの公開に関する設定の変更のための設定ページをユーザ端末１００−１〜１００−ｍへ送信する。

投稿情報取得部２０２は、コンテンツサーバ３００−１〜３００−ｎにコンテンツデータが投稿されて記憶された際に、このコンテンツの投稿者を識別可能なユーザ情報（以下「投稿者情報」という）、公開対象となるグループの情報（グループ情報）、およびコンテンツ情報を含む投稿情報を取得する。なお、投稿情報には、コンテンツの投稿者情報として、ユーザのログイン名やユーザ端末１００−１〜１００−ｍのＭＡＣ（Media Access Control）アドレスなどが含まれる。また、公開対象となるグループの情報としては、コンテンツを投稿するユーザがあらかじめ他ユーザをグループ分けしておいた場合に、投稿したコンテンツの公開を許可するグループ名の情報などがある。さらに、投稿情報には、コンテンツ情報として、投稿されたコンテンツデータの先頭の一部分など、コンテンツの内容を示す情報が含まれる。

また、投稿情報取得部２０２は、投稿情報中のグループに所属するユーザのユーザ情報を公開先管理ＤＢ２０３から検索し、該当するユーザのユーザ情報を投稿情報とともにレコード登録部２０４へ出力する。ここで、投稿情報取得部２０２が出力するユーザ情報は、投稿情報に対応するコンテンツの閲覧者となり得るユーザのユーザ情報である。

公開先管理ＤＢ２０３は、コンテンツデータの投稿者による閲覧側のユーザのグループ分けに関する情報を記憶しており、それぞれの投稿者（ユーザ）があらかじめ決定したグループごとの所属ユーザの情報を記憶している。具体的には、例えば図３に示すように、公開先管理ＤＢ２０３は、コンテンツの投稿者が設けた公開グループごとに、所属するユーザ（閲覧者）の情報が対応付けて記憶されている。すなわち、図３において、例えば投稿者「Ｘ」の公開グループ「友達」には、閲覧者となり得るユーザ「Ｂ」「Ｃ」が対応付けて記憶されている。これは、ユーザ「Ｘ」が投稿したコンテンツであって公開対象となるグループが「友達」のコンテンツであれば、ユーザ「Ｂ」「Ｃ」によって閲覧可能であることを意味する。

レコード登録部２０４は、投稿情報取得部２０２によって取得された投稿情報から閲覧者を識別可能なユーザ情報（以下「閲覧者情報」という）を索引としたレコードを生成し、コンテンツＤＢ２０５に登録する。具体的には、レコード登録部２０４は、投稿情報取得部２０２から出力される閲覧者情報ごとに、閲覧者が所属するグループ、投稿情報に含まれる投稿者情報、および投稿情報に含まれるコンテンツ情報を対応付けて一組のレコードを生成し、コンテンツＤＢ２０５に登録する。

また、レコード登録部２０４は、投稿情報取得部２０２から出力されたすべての閲覧者情報に関するレコードを登録した後、コンテンツの投稿者情報を閲覧者情報と一致させたマスターレコードを生成し、コンテンツＤＢ２０５に登録する。すなわち、マスターレコードとは、コンテンツの投稿者本人には、当然コンテンツの閲覧が許可されることから、コンテンツの投稿者が閲覧者となる場合のレコードである。

コンテンツＤＢ２０５は、閲覧者に対応付けて閲覧可能なコンテンツのコンテンツ情報を記憶している。具体的には、例えば図４に示すように、コンテンツＤＢ２０５は、コンテンツの投稿時にレコード登録部２０４によって生成されたレコードを記憶しており、閲覧者情報を索引として、閲覧者が属するグループの情報、コンテンツの投稿者情報、およびコンテンツ情報を記憶している。すなわち、図４において、例えば閲覧者「Ａ」には、投稿者「Ｙ」が設定したグループ「会社」と、投稿者「Ｙ」が投稿したコンテンツのコンテンツ情報「ブログｙ」とが対応付けられている。また、図４において、閲覧者「Ｙ」に投稿者「Ｙ」が対応付けられているレコードは、閲覧者と投稿者が一致するマスターレコードである。

閲覧要求受付部２０６は、ユーザがコンテンツの閲覧を希望する旨の閲覧要求をユーザ端末１００−１〜１００−ｍから受け付ける。閲覧要求には、閲覧者となるユーザの識別情報が含まれている。

ユーザ別ページ生成部２０７は、閲覧要求に含まれる閲覧者の識別情報をコンテンツＤＢ２０５から検索し、閲覧者が閲覧可能なコンテンツのコンテンツ情報を一覧できるユーザ別ページを生成する。すなわち、ユーザ別ページ生成部２０７は、閲覧者情報を索引としたコンテンツＤＢ２０５を参照し、閲覧要求を送信した閲覧者が閲覧可能なコンテンツ情報をすべてコンテンツＤＢ２０５から取得する。そして、ユーザ別ページ生成部２０７は、取得されたコンテンツ情報を配置したユーザ別ページを生成し、通信Ｉ／Ｆ部２０１を介して閲覧要求送信元のユーザ端末１００−１〜１００−ｍへ返信する。

変更要求受付部２０８は、投稿者（ユーザ）がコンテンツの公開に関する設定の変更を希望する旨の変更要求をユーザ端末１００−１〜１００−ｍから受け付ける。具体的には、変更要求受付部２０８は、単に変更を希望する旨の変更要求と、実際の変更内容を含む変更要求との２種類の変更要求を受け付ける。そして、変更要求受付部２０８は、単に変更を希望する旨の変更要求を設定ページ生成部２０９へ出力し、実際の変更内容を含む変更要求をＤＢ更新部２１０へ出力する。

設定ページ生成部２０９は、変更要求受付部２０８から変更要求が出力されると、変更要求に含まれるコンテンツの投稿者を公開先管理ＤＢ２０３から検索し、この投稿者がコンテンツの公開対象として設定しているグループの情報と各グループに所属する閲覧者情報とを取得して設定ページを生成する。すなわち、設定ページ生成部２０９は、コンテンツの公開に関する設定の変更を希望する投稿者に対応付けられたグループの情報と閲覧者情報を一覧できる設定ページを生成し、通信Ｉ／Ｆ部２０１を介して変更要求送信元のユーザ端末１００−１〜１００−ｍへ返信する。

ＤＢ更新部２１０は、変更要求受付部２０８から変更要求が出力されると、変更要求に含まれる変更内容をコンテンツＤＢ２０５および公開先管理ＤＢ２０３に反映する。具体的には、ＤＢ更新部２１０は、グループに所属する閲覧者が増減する場合には、コンテンツＤＢ２０５および公開先管理ＤＢ２０３において、該当する閲覧者情報を追加したり削除したりする。閲覧者情報を追加する際には、ＤＢ更新部２１０は、コンテンツＤＢ２０５から公開グループの情報と投稿者情報が共通するレコードを検索し、このレコード中のコンテンツ情報を新たに追加する閲覧者のレコードにコピーする。

次いで、上記のように構成された配信サーバ２００を含む通信ネットワークにおいて、投稿者（ユーザ）がコンテンツを投稿する際の処理について、図５に示すシーケンス図を参照しながら説明する。なお、図５においては、ユーザ端末１００−１〜１００−ｍを代表してユーザ端末１００と表記し、コンテンツサーバ３００−１〜３００−ｎを代表してコンテンツサーバ３００と表記する。

コンテンツの投稿者となるユーザは、ユーザ端末１００からコンテンツをコンテンツサーバ３００へ送信する（ステップＳ１０１）。このとき、ユーザ端末１００からは、コンテンツデータとともに投稿者情報およびコンテンツの公開対象のグループの情報が送信される。コンテンツデータがコンテンツサーバ３００によって受信されると、コンテンツサーバ３００によってコンテンツデータが記憶される（ステップＳ１０２）。同時に、コンテンツデータの一部分であるコンテンツ情報と投稿者情報とコンテンツの公開対象のグループの情報とを含む投稿情報がコンテンツサーバ３００から配信サーバ２００へ送信される（ステップＳ１０３）。

送信された投稿情報は、配信サーバ２００の通信Ｉ／Ｆ部２０１によって受信され、投稿情報取得部２０２によって取得される。そして、投稿情報取得部２０２によって、投稿者が投稿したコンテンツの閲覧が許可される閲覧者が検索される（ステップＳ１０４）。すなわち、投稿情報取得部２０２によって、公開先管理ＤＢ２０３が参照され、投稿情報に含まれる投稿者情報および公開対象のグループの情報に対応するすべての閲覧者情報が取得される。取得された閲覧者情報は、投稿情報とともにレコード登録部２０４へ出力される。

そして、レコード登録部２０４によって、それぞれの閲覧者情報にグループの情報、投稿者情報、およびコンテンツ情報が対応付けられ、閲覧者ごとのレコードが生成される。生成されたレコードは、レコード登録部２０４によって、コンテンツＤＢ２０５に登録される（ステップＳ１０５）。これにより、コンテンツＤＢ２０５には、閲覧者情報を索引として、閲覧可能なコンテンツのコンテンツ情報が記憶されていることになる。

また、レコード登録部２０４によって、閲覧者情報を投稿者情報としたマスターレコードが生成され、他のレコードと同様にコンテンツＤＢ２０５に登録される（ステップＳ１０６）。マスターレコードにおいては、閲覧者情報と投稿者情報とが一致しており、投稿者がコンテンツを削除しない限りは、コンテンツＤＢ２０５に必ず記憶され続ける。つまり、たとえコンテンツの投稿者が誰も所属していないグループをコンテンツの公開対象のグループに設定しても、コンテンツＤＢ２０５には、このコンテンツのコンテンツ情報がマスターレコード中に記憶されていることになる。

次に、本実施の形態に係る通信ネットワークにおいて、閲覧者（ユーザ）がコンテンツを閲覧する際の処理について、図６に示すシーケンス図を参照しながら説明する。なお、図６においては、ユーザ端末１００−１〜１００−ｍを代表してユーザ端末１００と表記し、コンテンツサーバ３００−１〜３００−ｎを代表してコンテンツサーバ３００と表記する。

コンテンツの閲覧者となるユーザは、ユーザ端末１００からコンテンツの閲覧を希望する旨の閲覧要求を配信サーバ２００へ送信する（ステップＳ２０１）。閲覧要求には、閲覧者の識別情報が含まれている。送信された閲覧要求は、配信サーバ２００の通信Ｉ／Ｆ部２０１によって受信され、閲覧要求受付部２０６によって受け付けられ、ユーザ別ページ生成部２０７へ出力される。そして、ユーザ別ページ生成部２０７によって、閲覧者に対して公開可能なコンテンツのコンテンツ情報が検索される（ステップＳ２０２）。すなわち、ユーザ別ページ生成部２０７によって、コンテンツＤＢ２０５が参照され、閲覧者情報が閲覧要求に含まれる閲覧者の識別情報に一致するすべてのコンテンツ情報が取得される。

このとき、コンテンツＤＢ２０５が閲覧者情報を索引として構成されているため、閲覧要求に含まれる閲覧者の識別情報からこの閲覧者が閲覧可能なコンテンツのコンテンツ情報を取得する処理の処理量は比較的小さい。すなわち、閲覧者が閲覧可能なコンテンツを検索する際の配信サーバ２００の処理負荷が小さくて済む。そして、一般に、コンテンツを投稿する投稿者の数よりもコンテンツを閲覧する閲覧者の数のほうが多いため、閲覧者を検索のキーとすることにより、目的のコンテンツ情報の絞り込みが迅速に行われ、所望のコンテンツ情報を早期に取得することができる。

また、この検索の際には、コンテンツサーバ３００へのアクセスが発生することはなく、コンテンツサーバ３００における処理が生じることはない。さらに、コンテンツＤＢ２０５において、閲覧者ごとおよびコンテンツごとのレコードが記憶されていることから、各コンテンツの閲覧の可否に関する種々の管理を簡便に行うことができる。

取得されたコンテンツ情報は、ユーザ別ページ生成部２０７によって、所定のウェブページのフォーマットに配置され、閲覧者が閲覧可能なコンテンツを一覧することができるユーザ別ページが生成される（ステップＳ２０３）。具体的には、例えば閲覧者が図４に示した「Ａ」である場合、図７に示すようなユーザ別ページが生成される。このユーザ別ページには、閲覧者「Ａ」が設定したグループに所属するメンバーと、閲覧者「Ａ」を公開対象としているコンテンツのコンテンツ情報とが表示されている。したがって、閲覧者「Ａ」は、自分が閲覧可能なすべてのコンテンツの更新状況などを容易に確認することができる。

このようなユーザ別ページは、ユーザ別ページ生成部２０７から通信Ｉ／Ｆ部２０１を介してユーザ端末１００へ送信される（ステップＳ２０４）。そして、閲覧者は、ユーザ端末１００においてユーザ別ページを閲覧し、自分が閲覧可能なコンテンツを確認する。ユーザ別ページには、コンテンツ情報として、コンテンツデータの一部分が表示されるため、閲覧者は、ユーザ別ページからそれぞれのコンテンツの内容も把握することができる。また、ユーザ別ページには、閲覧者が公開対象とされているコンテンツのみのコンテンツ情報が表示されるため、閲覧者は、自分が閲覧可能なコンテンツを手間をかけることなく把握することができる。

そして、閲覧者は、例えばユーザ別ページ上のコンテンツ情報を指定するなどの操作により、全体の閲覧を希望するコンテンツを選択し、このコンテンツの閲覧をコンテンツサーバ３００へ要求する（ステップＳ２０５）。コンテンツサーバ３００では、この要求を受け、要求されたコンテンツデータをユーザ端末１００へ送信する（ステップＳ２０６）。

次に、本実施の形態に係る通信ネットワークにおいて、投稿者（ユーザ）がコンテンツの公開に関する設定を変更する際の処理について、図８に示すシーケンス図を参照しながら説明する。なお、図８においては、ユーザ端末１００−１〜１００−ｍを代表してユーザ端末１００と表記し、コンテンツサーバ３００−１〜３００−ｎを代表してコンテンツサーバ３００と表記する。

コンテンツの投稿者であるユーザは、ユーザ端末１００からコンテンツの公開に関する設定の変更を希望する旨の変更要求を配信サーバ２００へ送信する（ステップＳ３０１）。ここでの変更要求には、投稿者の識別情報のみが含まれている。送信された変更要求は、配信サーバ２００の通信Ｉ／Ｆ部２０１によって受信され、変更要求受付部２０８によって受け付けられる。そして、変更要求が単に変更を希望する旨の通知であるため、変更要求受付部２０８によって、当該変更要求が設定ページ生成部２０９へ出力される。

設定ページ生成部２０９へ変更要求が出力されると、設定ページ生成部２０９によって、投稿者が設定したグループおよび各グループに所属する閲覧者を含む公開先情報が検索される（ステップＳ３０２）。すなわち、設定ページ生成部２０９によって、公開先管理ＤＢ２０３が参照され、変更要求に含まれる投稿者の識別情報に対応するすべてのグループの情報および各グループに所属する閲覧者情報が公開先情報として取得される。

そして、設定ページ生成部２０９によって、取得された公開先情報が所定のウェブページのフォーマットに配置されることによって、投稿者が設定したグループ分けを一覧することができる設定ページが生成される（ステップＳ３０３）。この設定ページにおいては、投稿者は、閲覧者の追加や削除および各閲覧者が所属するグループの変更などが実行できるようになっている。

設定ページは、設定ページ生成部２０９から通信Ｉ／Ｆ部２０１を介してユーザ端末１００へ送信される（ステップＳ３０４）。そして、投稿者は、ユーザ端末１００において設定ページを閲覧し、所望の変更を設定ページ上に入力する。投稿者が設定ページ上で入力した変更内容は、再び変更要求として配信サーバ２００へ送信される（ステップＳ３０５）。

送信された変更要求は、配信サーバ２００の通信Ｉ／Ｆ部２０１によって受信され、変更要求受付部２０８によって受け付けられる。そして、変更要求が実際の変更内容を含むため、変更要求受付部２０８によって、当該変更要求がＤＢ更新部２１０へ出力される。

ＤＢ更新部２１０へ変更要求が出力されると、ＤＢ更新部２１０によって、投稿者が希望する変更内容が判別される（ステップＳ３０６）。具体的には、ＤＢ更新部２１０によって、変更内容が各グループにおける閲覧者の追加、閲覧者の削除、および所属グループの変更のいずれであるかが判別される。

この結果、変更内容が閲覧者の追加である場合には、ＤＢ更新部２１０によって、コンテンツＤＢ２０５に新たな閲覧者のレコードが追加され（ステップＳ３０７）、公開先管理ＤＢ２０３において新たな閲覧者が所属するグループに追加される（ステップＳ３０８）。このとき、コンテンツＤＢ２０５においては、グループおよび投稿者が新たな閲覧者と同一のレコードが検索され、この閲覧者情報に対応付けられたコンテンツ情報が新たな閲覧者のレコードにコピーされる。本実施の形態においては、閲覧者と投稿者が一致するマスターレコードがコンテンツＤＢ２０５に記憶されているため、グループおよび投稿者が新たな閲覧者と同一のレコードは必ずコンテンツＤＢ２０５に記憶されている。そして、閲覧者の追加の際に、コンテンツ情報をコンテンツサーバ３００から取得する必要がないため、配信サーバ２００からコンテンツサーバ３００へのアクセスが発生することはなく、コンテンツサーバ３００における処理が生じることはない。したがって、コンテンツサーバ３００の処理負荷を削減することができる。

また、変更内容が閲覧者の削除である場合には、ＤＢ更新部２１０によって、変更要求によって指定された閲覧者のレコードがコンテンツＤＢ２０５から削除され（ステップＳ３０７）、公開先管理ＤＢ２０３において該当する閲覧者がグループから削除される（ステップＳ３０８）。

さらに、変更内容が所属グループの変更である場合には、ＤＢ更新部２１０によって、変更要求によって指定された閲覧者に対応するグループがコンテンツＤＢ２０５において変更され（ステップＳ３０７）、公開先管理ＤＢ２０３において該当する閲覧者のグループが変更される（ステップＳ３０８）。

本実施の形態においては、図８からも明らかなように、ユーザがコンテンツの公開に関する設定を変更する際には、ユーザ端末１００と配信サーバ２００のみが動作し、コンテンツサーバ３００は動作しない。そして、新たな閲覧者のレコードをコンテンツＤＢ２０５に追加する場合には、コンテンツ情報をコンテンツサーバ３００から取得するのではなく、既に登録されているレコードからコピーする。このため、コンテンツサーバ３００の処理負荷を確実に削減することができる。また、設定の変更に関する処理負荷が削減されるため、コンテンツサーバ３００は、ユーザ端末１００からコンテンツ全体の閲覧要求があった場合に、要求されたコンテンツの検索などを迅速に実行することができる。

ここで、コンテンツの公開に関する設定変更時の配信サーバ２００の動作について、図９に示すフロー図を参照しながら説明する。

まず、ユーザ端末１００から送信された変更要求が配信サーバ２００の通信Ｉ／Ｆ部２０１を介して変更要求受付部２０８によって受け付けられる（ステップＳ４０１）。そして、変更要求受付部２０８によって、変更要求が単に変更を希望する旨の通知であるか実際の変更種別（すなわち閲覧者の追加、閲覧者の削除、または所属グループの変更）を含むものであるかが判断される（ステップＳ４０２）。

この結果、変更要求が単に変更を希望する旨のみを含むものである場合（ステップＳ４０２Ｎｏ）、変更要求は、変更要求受付部２０８から設定ページ生成部２０９へ出力される。そして、設定ページ生成部２０９によって、変更要求に含まれる投稿者の識別情報に対応するコンテンツの公開先の情報が公開先管理ＤＢ２０３から取得される（ステップＳ４０３）。すなわち、設定ページ生成部２０９によって、変更要求に含まれる投稿者の識別情報に対応付けて公開先管理ＤＢ２０３に記憶されている公開グループの情報と閲覧者情報とが取得される。その後、設定ページ生成部２０９によって、公開グループの情報と閲覧者情報の一覧がウェブページに配置されて投稿者に固有の設定ページが生成され（ステップＳ４０４）、通信Ｉ／Ｆ部２０１からユーザ端末１００へ送信される（ステップＳ４０５）。

送信された設定ページは、ユーザ端末１００によって受信され、コンテンツの投稿者が設定ページを閲覧しながら公開に関する設定の変更を入力する。すなわち、コンテンツの投稿者は、ユーザ端末１００に表示される設定ページにおいて、公開グループに所属する閲覧者を追加・削除したり、閲覧者が所属する公開グループを変更したりする。その後、設定ページにおいて入力された変更の内容が含まれる変更要求が投稿者の操作によりユーザ端末１００から送信される。

送信された変更要求は、配信サーバ２００の変更要求受付部２０８によって受け付けられ（ステップＳ４０１）、実際の変更種別を含むものであるか否かが判断される（ステップＳ４０２）。ここでは、変更要求が実際の変更の内容を含んでいるため（ステップＳ４０２Ｙｅｓ）、変更要求は、変更要求受付部２０８からＤＢ更新部２１０へ出力される。そして、ＤＢ更新部２１０によって、変更種別が閲覧者の追加であるか否かが判定される（ステップＳ４０６）。

この判定の結果、コンテンツの投稿者が閲覧者の追加を希望している場合（ステップＳ４０６Ｙｅｓ）、ＤＢ更新部２１０によってコンテンツＤＢ２０５が参照され、所属する公開グループの情報および投稿者情報が新たに追加される閲覧者と同一のレコードが検索される（ステップＳ４０７）。そして、ＤＢ更新部２１０によって、検索されたレコードのコンテンツ情報が新たに追加される閲覧者のレコードにコピーされる（ステップＳ４０８）。具体的に例を挙げると、例えば図４に示したコンテンツＤＢ２０５において、投稿者「Ｙ」が閲覧者「Ｄ」を新たに公開グループ「会社」に追加する場合、図１０に示すように、公開グループおよび投稿者が同一の閲覧者「Ａ」に関するレコードからコンテンツ情報「ブログｙ」がコピーされ、新たに閲覧者「Ｄ」を索引としたレコードがコンテンツＤＢ２０５に追加される。

ここでは、閲覧者「Ａ」のレコードからコンテンツ情報がコピーされるものとしたが、公開グループの情報および投稿者情報が新たに追加される閲覧者と同一であれば良いため、閲覧者「Ｂ」のレコードや閲覧者が「Ｙ」となっているマスターレコードなどからコンテンツ情報をコピーしても良い。そして、コンテンツがコンテンツサーバ３００に記憶されている限り、投稿者と閲覧者が同一のマスターレコードがコンテンツＤＢ２０５に記憶されているため、閲覧者を追加する際にコンテンツ情報のコピー元となるレコードがコンテンツＤＢ２０５に必ず存在する。

このため、閲覧者情報を索引としてコンテンツ情報を対応付けたコンテンツＤＢ２０５によってコンテンツの公開に関する管理を行う場合でも、配信サーバ２００内の処理で閲覧者の追加を実現することができ、コンテンツサーバ３００の処理負荷を軽減することができる。

コンテンツＤＢ２０５に新たな閲覧者のレコードが追加された後、ＤＢ更新部２１０によって、公開先管理ＤＢ２０３において新たな閲覧者情報が該当する公開グループに追加され（ステップＳ４１４）、閲覧者を追加する処理が完了する。

また、コンテンツの投稿者が閲覧者の追加を希望していない場合（ステップＳ４０６Ｎｏ）、ＤＢ更新部２１０によって、変更種別が所属する公開グループの変更であるか否かが判定される（ステップＳ４０９）。この判定の結果、コンテンツの投稿者が閲覧者の所属グループの変更を希望している場合（ステップＳ４０９Ｙｅｓ）、ＤＢ更新部２１０によって対象となる閲覧者のレコードがコンテンツＤＢ２０５から検索される（ステップＳ４１０）。そして、ＤＢ更新部２１０によって、検索されたレコードの公開グループの情報が投稿者が希望するグループの情報に変更される（ステップＳ４１１）。コンテンツＤＢ２０５においてレコードが更新された後、ＤＢ更新部２１０によって、公開先管理ＤＢ２０３において該当する閲覧者情報が変更後のグループへ移動され（ステップＳ４１４）、閲覧者の所属グループを変更する処理が完了する。

また、コンテンツの投稿者が閲覧者の所属グループの変更を希望していない場合（ステップＳ４０９Ｎｏ）、ＤＢ更新部２１０によって、変更種別が閲覧者の削除であるか否かが判定される（ステップＳ４１２）。この判定の結果、コンテンツの投稿者が閲覧者の削除を希望している場合（ステップＳ４１２Ｙｅｓ）、ＤＢ更新部２１０によって対象となる閲覧者のレコードがコンテンツＤＢ２０５から削除される（ステップＳ４１３）。コンテンツＤＢ２０５においてレコードが削除された後、ＤＢ更新部２１０によって、公開先管理ＤＢ２０３において該当する閲覧者情報が削除され（ステップＳ４１４）、閲覧者を削除する処理が完了する。

以上のように、本実施の形態によれば、配信サーバが閲覧者情報を索引として閲覧可能なコンテンツの管理をするとともに、閲覧者によるコンテンツの閲覧時には、閲覧可能なコンテンツの一覧を閲覧者に提供する。このため、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行うことができる。また、コンテンツの投稿者によって公開に関する設定が変更される際に、必要に応じてレコード間でコンテンツ情報のコピーがされるなど、配信サーバ内でのみ処理が行われ、コンテンツ全体を記憶するコンテンツサーバに処理負荷がかかることがない。結果として、コンテンツの公開に関する管理を効率的に行うとともに、コンテンツサーバの処理負荷を軽減することができる。

なお、上記一実施の形態においては、ユーザ端末１００−１〜１００−ｍがユーザ別ページを受信した後、直接コンテンツサーバ３００−１〜３００−ｎへ所望のコンテンツ全体の閲覧を要求するものとしたが、コンテンツ全体の閲覧時にも配信サーバ２００を介した処理を行うものとしても良い。すなわち、所望のコンテンツ全体の閲覧要求がユーザ端末１００−１〜１００−ｍから配信サーバ２００へ送信されると、配信サーバ２００は、コンテンツサーバ３００−１〜３００−ｎからコンテンツデータ全体を取得してユーザ端末１００−１〜１００−ｍへ返信するようにしても良い。

同様に、コンテンツの投稿時にも、ユーザ端末１００−１〜１００−ｍから送信されたコンテンツデータが配信サーバ２００を介して所定のコンテンツサーバ３００−１〜３００−ｎに記憶されるようにしても良い。この場合には、配信サーバ２００がユーザ端末１００−１〜１００−ｍからコンテンツデータを受信した時点で、投稿情報取得部２０２によって投稿情報が取得される。したがって、コンテンツサーバ３００−１〜３００−ｎは、コンテンツデータを記憶した際に配信サーバ２００へ投稿情報を送信する必要がなくなり、コンテンツサーバ３００−１〜３００−ｎの処理負荷をさらに軽減することができる。

また、上記一実施の形態においては、コンテンツの投稿時に投稿者と閲覧者が一致するマスターレコードをコンテンツＤＢ２０５に登録するものとしたが、マスターレコードを登録するタイミングは、コンテンツの投稿時に限定されない。すなわち、例えばＤＢ更新部２１０がコンテンツＤＢ２０５から閲覧者を削除する際に、コンテンツＤＢ２０５から削除されるレコードがコンテンツに関する最後のレコードであるか否かを判定し、最後のレコードである場合には、レコードの削除と同時にコンテンツの投稿者を閲覧者としたマスターレコードをコンテンツＤＢ２０５に登録するようにしても良い。

この場合には、投稿者以外の閲覧者がコンテンツの公開対象となっている間はコンテンツＤＢ２０５にマスターレコードが記憶されておらず、公開対象の閲覧者がいなくなるときにマスターレコードがコンテンツＤＢ２０５に記憶されることになる。したがって、コンテンツＤＢ２０５の記憶容量を削減しつつ、再度閲覧者のレコードを追加する際には、マスターレコードをコンテンツ情報のコピー元とすることができる。

本発明は、選択的にユーザへ公開されるコンテンツが複数のコンテンツサーバに記憶されている場合でも、コンテンツの公開に関する管理を効率的に行う場合に適用することができる。

一実施の形態に係る通信ネットワークの概略構成を示す図である。 一実施の形態に係る配信サーバの要部構成を示すブロック図である。 一実施の形態に係る公開先管理ＤＢの一例を示す図である。 一実施の形態に係るコンテンツＤＢの一例を示す図である。 一実施の形態に係るコンテンツ投稿時の処理を示すシーケンス図である。 一実施の形態に係るコンテンツ閲覧時の処理を示すシーケンス図である。 一実施の形態に係るユーザ別ページの一例を示す図である。 一実施の形態に係る設定変更時の処理を示すシーケンス図である。 一実施の形態に係る配信サーバの設定変更動作を示すフロー図である。 一実施の形態に係る配信サーバにおける閲覧者追加時の動作を説明する図である。

符号の説明

２０１ 通信Ｉ／Ｆ部
２０２ 投稿情報取得部
２０３ 公開先管理ＤＢ
２０４ レコード登録部
２０５ コンテンツＤＢ
２０６ 閲覧要求受付部
２０７ ユーザ別ページ生成部
２０８ 変更要求受付部
２０９ 設定ページ生成部
２１０ ＤＢ更新部

Claims (6)

1. 各々公開先のユーザが設定されたコンテンツデータを保持する複数のコンテンツサーバに接続されたコンテンツ配信装置であって、
   前記複数のコンテンツサーバに記憶されたコンテンツデータの公開先となるユーザのユーザ情報と当該ユーザが公開先として設定されたコンテンツデータのコンテンツ情報とを対応付けるとともに、各ユーザ情報をコンテンツ情報の索引として記憶する記憶手段と、
   コンテンツデータの閲覧を要求する閲覧要求をユーザ端末から受信する受信手段と、
   前記受信手段によって受信された閲覧要求に含まれるユーザ情報に対応付けられたコンテンツ情報を前記記憶手段から検索し、検索されたコンテンツ情報の一覧を表示するためのユーザ別ページを生成する生成手段と、
   前記生成手段によって生成されたユーザ別ページを前記受信手段によって受信された閲覧要求の送信元のユーザ端末へ送信する送信手段と
   を有することを特徴とするコンテンツ配信装置。
2. コンテンツデータの投稿者のユーザ情報と当該投稿者が投稿したコンテンツデータの公開先に設定される閲覧者のユーザ情報とを対応付けて記憶する公開先管理手段をさらに有し、
   前記記憶手段は、
   前記公開先管理手段によって記憶された閲覧者のユーザ情報を索引として、投稿者が投稿したコンテンツデータのコンテンツ情報を記憶することを特徴とする請求項１記載のコンテンツ配信装置。
3. 前記記憶手段は、
   コンテンツデータの投稿者がコンテンツデータごとの公開先として設定するグループ情報と当該投稿者のユーザ情報とをコンテンツ情報にさらに対応付けて記憶することを特徴とする請求項１または２に記載のコンテンツ配信装置。
4. 投稿者がコンテンツデータの公開先のユーザを追加する際、追加されるユーザが所属するグループのグループ情報と投稿者のユーザ情報とに対応付けられたコンテンツ情報を前記記憶手段から検索し、検索されたコンテンツ情報のコピーを生成する複製手段と、
   前記複製手段によって生成されたコンテンツ情報のコピーと前記追加されるユーザのユーザ情報とを対応付けて前記記憶手段に追加記憶する追加手段と
   をさらに有することを特徴とする請求項３記載のコンテンツ配信装置。
5. コンテンツデータの投稿者のユーザ情報を当該コンテンツデータの公開先となるユーザのユーザ情報としてコンテンツ情報に対応付けて前記記憶手段に登録するマスターレコード登録手段をさらに有することを特徴とする請求項１〜４のいずれかに記載のコンテンツ配信装置。
6. 各々公開先のユーザが設定されたコンテンツデータを保持する複数のコンテンツサーバに接続されたコンテンツ配信装置におけるコンテンツ配信方法であって、
   前記複数のコンテンツサーバに記憶されたコンテンツデータの閲覧を要求する閲覧要求をユーザ端末から受信する受信工程と、
   コンテンツデータの公開先となるユーザのユーザ情報と当該ユーザが公開先として設定されたコンテンツデータのコンテンツ情報とを対応付けるとともに、各ユーザ情報をコンテンツ情報の索引として記憶するデータベースから、前記受信工程にて受信された閲覧要求に含まれるユーザ情報に対応付けられたコンテンツ情報を検索する検索工程と、
   前記検索工程にて検索されたコンテンツ情報の一覧を表示するためのユーザ別ページを生成する生成工程と、
   前記生成工程にて生成されたユーザ別ページを前記受信工程にて受信された閲覧要求の送信元のユーザ端末へ送信する送信工程と
   を有することを特徴とするコンテンツ配信方法。

Images