JP5707036B2 - 開示制御機能提供装置、システム、方法及びプログラム - Google Patents

Description

本発明は、各ユーザに応じたリソースの開示範囲を決定する開示制御機能を提供する技術に関する。

近年、インターネットにおいては、例えばソーシャルネットワーキングサービス（以下、ＳＮＳ）などのように、ユーザ個人が記事や写真や動画といったコンテンツを投稿し、他ユーザに開示することができる場を提供するサービスが普及している。

これらのサービスは、一般にＣＧＭ（Consumer Generated Media）とも呼ばれ、コンテンツを作成したユーザから他ユーザへの情報発信のツールとしてだけでなく、ユーザ間のコミュニケーションのツールとしても利用されている。例えば、或るユーザが投稿した写真や記事に対して、その写真や記事を閲覧したユーザが個々にコメントを付記することで、その写真や記事を媒介としてユーザ間で意見交換が行われる、というものである。

そして、上記のようなサービスでは、コミュニケーションのツールとしての利便を向上させるため、サービスを利用するユーザのプロフィールを管理して、コンテンツを投稿したユーザやコンテンツを閲覧するユーザがどのような人物であるかを表示する機能や、投稿したコンテンツや自己のプロフィールの開示を許可する範囲を制限する機能を備えたものが提案されている（例えば、特許文献１を参照。）。

特開２００８−２４２７７８号公報

しかしながら、上記のような機能は、それを実現する仕組みを各サービスにおいて独自に構築する必要があるため、サービス提供側にとって、システム開発や維持管理の負担が大きいと、容易に導入や運用に踏み込めない、という問題があった。また、各サービスにおいて設定されたユーザのプロフィールやユーザ間のリンク関係を横断的に管理可能な仕組みではないため、ユーザが複数のサービスを利用している場合には、各サービスにおいてプロフィールやリンク関係を設定し、別個に管理する負担がかかっていた。

そこで、本発明は、各サービスに対して、ユーザに応じたリソースの開示範囲を決定する開示制御機能を提供することを目的とする。

上記の課題を解決するため、本発明は以下のような態様を要旨とする。

（１） ユーザ端末からのリクエストに応じて各種リソースを提供する複数のサービス提供サーバとネットワークを介して接続され、
各サービス提供サーバに共通するユーザ間の友だち関係を示すグラフデータを記憶している友だち関係記憶手段と、
ユーザが友だち関係を設定した他ユーザの属性データを記憶している友だち属性記憶手段と、
前記グラフデータと前記属性データとに基づいて、各サービス提供サーバ毎に、各ユーザに応じたリソースの開示範囲を決定する開示制御手段と、を備えたことを特徴とする開示制御機能提供装置。

（１）の態様によれば、各サービス提供サーバに共通するユーザ間の友だち関係と、友だち関係にある他ユーザの属性とに基づいて、サービス提供サーバ毎に、各ユーザに応じたリソースの開示範囲を決定する。つまり、各サービス提供サーバのそれぞれに対して、リソースの開示範囲を制御する機能を提供することができるようになる。

したがって、サービス提供側にとっては、上記機能を実現する仕組みを各サービスにおいて独自に構築する必要がなく、システム開発や維持管理を意識せずとも、上記機能を実装したサービスをユーザ側に提供することができるようになる。また、各サービス提供サーバに共通するユーザ間の友だち関係を利用するので、ユーザ側からすれば、利用しているサービス間の相違を意識することなく、自らの友だち関係を管理することができるうえ、さらに、友だち関係にある他ユーザの属性を考慮して、サービス毎にリソースの開示制御を行うことができる。

（２） 各サービス提供サーバ毎に、各リソースについて開示を許可する他ユーザの属性を指定する開示条件を、ユーザに関連付けて記憶している開示条件記憶手段を備え、
前記開示制御手段は、
各サービス提供サーバから送信された、開示要求ユーザ及び開示対象ユーザの指定を含むリクエストに応じて、前記グラフデータを参照し、前記開示要求ユーザと前記開示対象ユーザとの友だち関係の判定を行い、
前記判定の結果と、前記開示要求ユーザに関連付けられた属性データと、前記開示対象ユーザに関連付けられた前記開示条件とに基づいて、前記開示要求ユーザに開示を許可するリソースを決定することを特徴とする（１）に記載の開示制御機能提供装置。

（２）の態様によれば、リソースの開示範囲の制御に、サービス提供サーバ毎に各リソースについて開示を許可する他ユーザの属性を指定する開示条件を用いるので、ユーザ側からすれば、リソースの開示範囲の制御をサービスに応じて任意に使い分けることができるようになる。

（３） 相互にネットワークを介して接続された、ユーザ端末からのリクエストに応じて各種リソースを提供する複数のサービス提供サーバと、各ユーザに応じたリソースの開示範囲を決定する開示制御機能提供装置と、を備え、
前記開示制御機能提供装置は、
各サービス提供サーバに共通するユーザ間の友だち関係を示すグラフデータを記憶している友だち関係記憶手段と、
各サービス提供サーバ毎にユーザが友だち関係を設定した他ユーザの属性データを記憶している友だち属性記憶手段と、
各サービス提供サーバから送信された開示制御リクエストに応じて、前記グラフデータと、前記属性データとに基づいて、各ユーザに応じたリソースの開示範囲を決定する開示制御手段と、を備え、
前記サービス提供サーバは、
ユーザ端末からのリソース閲覧リクエストに応じて、開示要求ユーザ及び開示対象ユーザの指定を含む開示制御リクエストを開示制御機能提供装置に対して送信し、当該開示制御機能提供装置が決定したリソースの開示範囲を取得する開示範囲取得手段と、
前記開示範囲取得手段が取得した開示範囲に基づいて、リソース閲覧用ページのページデータを生成するページデータ生成手段と、
前記ページデータ生成手段が生成した前記ページデータをユーザ端末に送信するページデータ送信手段と、を備えたことを特徴とする閲覧制御機能提供システム。

（４） 複数のサービス提供サーバとネットワークを介して接続された開示制御機能提供装置が実行する方法であって、
各サービス提供サーバに共通するユーザ間の友だち関係を示すグラフデータを設定するステップ、
各サービス提供サーバ毎にユーザが友だち関係を設定した他ユーザの属性データを設定するステップ、及び
前記グラフデータと前記属性データとに基づいて、各ユーザに応じたリソースの開示範囲を決定するステップ、を含むことを特徴とする開示制御機能提供方法。

（５） コンピュータを、
各サービス提供サーバに共通するユーザ間の友だち関係を示すグラフデータを記憶している友だち関係記憶手段と、
各サービス提供サーバ毎にユーザが友だち関係を設定した他ユーザの属性データを記憶している友だち属性記憶手段と、
前記グラフデータと前記属性データとに基づいて、各ユーザに応じたリソースの開示範囲を決定する開示制御手段として機能させることを特徴とするプログラム。

本発明によれば、各サービスに対して、ユーザに応じたリソースの開示範囲を決定する開示制御機能を提供することができる。

実施形態にかかる開示制御機能提供装置を含むシステムの構成例を示す図である。 実施形態にかかる開示制御機能提供装置のサーバ構成例を示す図である。 プロフィールデータベースのデータ構成例を示す図である。 友だちデータベースのデータ構成例を示す図である。 コンテンツデータベースのデータ構成例を示す図である。 ユーザグラフデータのデータ構成例を示す図である。 実施形態の処理例を示すシーケンス図（各種設定）である。 実施形態の処理例を示すシーケンス図（開示制御：プロフィール開示要求時）である。 プロフィール閲覧用ページの表示例を示す図である。 実施形態の処理例を示すシーケンス図（開示制御：コンテンツ開示要求時）である。 コンテンツ閲覧用ページの表示例を示す図である。 コンテンツ閲覧用ページの表示例を示す図である。

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

＜構成＞
図１を参照し、本実施形態にかかる開示制御機能提供装置（プラットフォーム）１を含むシステム全体の構成について説明する。

開示制御機能提供装置１（以下、本装置１）は、複数のサービス提供サーバ５（５ａ、…、５ｘ）とネットワークＮを介して接続されている。また、サービス提供サーバ５は、複数のユーザ端末７（７ａ、…、７ｘ）とネットワークＮを介して接続されている。

本装置１、サービス提供サーバ５及びユーザ端末７は、ＣＰＵ等の制御装置、メモリやＨＤＤ等の記憶装置、通信Ｉ／Ｆ等の通信装置といったハードウェア資源を有するコンピュータ（単一或いは複数）により構成される。

（ユーザ端末７）
ユーザ端末７は、ユーザが使用するＰＣ（Personal Computer）や携帯通信端末装置（携帯電話機やスマートフォン）等であり、上記本装置１が有するハードウェア資源に加えて、キーボタンやタッチパネル等の入力装置、液晶ディスプレイ等の出力装置、一般的なブラウザを備える。ブラウザは、インターネットの標準プロトコルであるＨＴＴＰ（Hyper Text Transfer Protocol）等に従い、ＨＴＭＬ（Hyper Text Markup Language）等の言語で記述されたページデータの要求、取得及び表示、フォームデータの送信等を行う機能を有している。ユーザは、ユーザ端末７のブラウザを通じて、サービス提供サーバ５により提供されるサービスを利用する。

（サービス提供サーバ５）
各サービス提供サーバ５は、ユーザ端末７のブラウザからのリクエストに応じて、各種サービスの実施に関するウェブページをユーザ端末７に対して提供する。ウェブページには、ユーザ端末７側からリクエストされたリソースが組み込まれてユーザ端末７に提供される。本実施形態では、リソースの例として、各ユーザのプロフィール（どのような人物かを特定する情報）や、各ユーザにより投稿されたコンテンツ（画像、音声、テキスト等を用いた創作物）を採用している。

また、サービスの例としては、ユーザがコンテンツを閲覧したり、ユーザ自身がコンテンツを投稿して他のユーザに開示したり、商取引を行う場を提供するサービスであり、ＳＮＳ（ソーシャルネットワーキングサービス）、動画サービス、地図サービス、オークションサービス等が該当する。

サービス提供サーバ５は、入力処理手段５１と、コンテンツ管理手段５２と、設定手段５３と、開示範囲取得手段５４と、ページデータ生成手段５５と、ページデータ送信手段５６と、を備えている。

入力処理手段５１は、ユーザ端末７から送信された各種情報を処理する機能を有する。例えば、ユーザによる操作入力（マウスクリックやキーボードタッチ等）に基づいてユーザ端末７のブラウザから送信された、各種リクエスト及び入力情報を受信し、各種リクエストに応じて、入力情報を他の手段に受け渡す等の処理を行う。

コンテンツ管理手段５２は、コンテンツを管理する機能を有する。例えば、コンテンツが蓄積されているデータベースに対し、登録、更新、検索、取得等の各種処理を行う。設定手段５３は、ユーザの「プロフィール」とこれに紐付く「友だち」や「友だち属性」、「開示条件」等の情報を設定する機能をユーザ端末７に提供し、ユーザ端末７を介して設定された各種情報を、本装置１に対して送信する機能を有する。

「プロフィール」は、表示名、表示画像、生年月日、性別、血液型、所在地、自己紹介、所属（住所、学校、会社等）、嗜好（音楽、映画、本等）といった項目から構成され、ユーザがどういう人物であるかを特定するデータである。「友だち」は、ユーザ端末７を介した申請及び承認の入力に基づいて、ユーザ間で相互にリンクが設定された関係を示すデータである。また、このような関係にある一方のユーザから見た他方のユーザを「友だちユーザ」という。

また、「友だち属性」は、友だちユーザが所属する集団や分類を特定するデータであり、識別するためのタグにより特定される。例えば、友だちユーザＡには「会社」が設定され、友だちユーザＢには「学校」が設定されている、といった具合である。また、「開示条件」は、リソースの管理者であるユーザが、リソースの開示を許可する他ユーザを指定するデータである。開示条件は、サービス提供サーバ毎に設定することができる。

開示範囲取得手段５４は、本装置１に対して送信したリクエストに応じて、本装置１から送信された開示範囲に関する情報（開示情報）を受信する機能を有する。開示情報は、リソース（プロフィールや投稿コンテンツ等）に対して開示要求をしたユーザ（以下、開示要求ユーザ）にその対象を開示する範囲を定めた情報である。より具体的な態様では、開示対象とするプロフィールの各項目やコンテンツといった情報である。

ページデータ生成手段５５は、ユーザ端末７に対して提供するウェブページのページデータを生成する機能を有する。例えば、開示要求ユーザに対して、開示対象のプロフィールやコンテンツを掲載したウェブページのページデータを生成する。ページデータ送信手段５６は、ページデータ生成手段５５が生成したページデータをユーザ端末７に対して提供する機能を有する。

ここで、サービス提供サーバ５が備える各手段（設定手段５３、開示範囲取得手段５４、ページデータ生成手段５５等）は、本装置１の管理者側から提供されたＡＰＩ（Application Program Interface）を、各サービス提供サーバ５のプログラムに組み込むことで実現される機能である。また、各サービス提供サーバ５と本装置１との間の通信は任意の形式とすることができる。

（開示制御機能提供装置１）
本装置１は、各ユーザに応じたリソースの開示範囲を決定する開示制御機能を、各サービス提供サーバ５に対して提供することを特徴としている。つまり、どのユーザにどのリソースに対する開示を許可するか、という開示範囲を決定する機能を提供するものである。

本装置１が上記機能を各サービス提供サーバ５に利用させることにより、各サービス提供サーバ５は、独自に上記機能を構築する必要がなく、各ユーザの友だち関係及び友だち属性を反映させたリソースの提供を容易に実現することができるようになる。

本装置１は、上記機能を実現するため、要求処理手段３１と、プロフィール設定手段３２と、友だち属性設定手段３３と、友だち関係設定手段３４と、開示条件設定手段３５と、開示制御手段３６と、開示範囲送信手段３７と、を備えている。

要求処理手段３１は、各サービス提供サーバ５から送信された各種リクエスト及び情報を受信する機能を有する。例えば、各種リクエストに応じて、リクエストに含まれる情報を他の手段に受け渡す等の処理を行う。プロフィール設定手段３２は、各ユーザにより入力されたプロフィールを設定する機能を有する。例えば、各サービス提供サーバに共通する各ユーザのプロフィールを記憶しているプロフィール記憶手段４１に対し、登録、更新、検索、取得等の各種処理を行う。

友だち属性設定手段３３は、各ユーザにより入力されるか或いはサービス提供サーバ５により動的に生成された、友だちユーザ及びその友だち属性を設定する機能を有する。例えば、各ユーザの友だちユーザに関する友だち属性を記憶している友だち属性記憶手段４２に対し、登録、更新、検索、取得等の各種処理を行う。

友だち関係設定手段３４は、ユーザ間の友だち関係を設定する機能を有する。例えば、各サービス提供サーバに共通する友だち関係を示すグラフデータを記憶している友だち関係記憶手段４３に対し、登録、更新、検索、取得等の各種処理を行う。

開示条件設定手段３５は、各リソース（ユーザのプロフィールや投稿コンテンツ）に対して、各ユーザにより入力されるか或いはサービス提供サーバ５により動的に生成された開示条件を設定する機能を有する。例えば、各リソースに応じて開示条件を記憶している開示条件記憶手段４４に対し、登録、更新、検索、取得等の各種処理を行う。

開示制御手段３６は、サービス提供サーバ５がユーザ端末７に対して提供するリソース（ユーザのプロフィールや投稿コンテンツ）に関して、各ユーザに応じた開示範囲を決定する機能を有する。例えば、開示要求ユーザと、リソースが開示要求の対象となったユーザ（以下、開示対象ユーザ）との間の友だち関係及び友だち属性に応じて、開示対象とするプロフィールやコンテンツの指定を行う。開示範囲送信手段３７は、サービス提供サーバ５に対して、開示制御手段３６が決定した開示範囲に関する情報を送信する機能を有する。

（本装置１のサーバ構成）
次に、図２を参照して、本実施形態にかかる本装置１のサーバ構成について説明する。

本装置１は、アプリケーションサーバ（以下、ＡＰサーバ）１１と、データベースサーバ（以下、ＤＢサーバ）１２と、グラフサーバ１３と、を備え、これらの各サーバ１１〜１３が相互に通信可能に接続されて構成されている。

各サーバ１１〜１３は、ＣＰＵ等の制御装置、メモリやＨＤＤ等の記憶装置、通信Ｉ／Ｆ等の通信装置といったハードウェア資源を有するコンピュータにより構成される。各サーバ１１〜１３間の通信は、本装置１におけるデータの保存形式に応じて任意の形式とすることができる。

ＡＰサーバ１１は、サービス提供サーバ５と、バックエンドとなるＤＢサーバ１２及びグラフサーバ１３との橋渡しを担う。ＡＰサーバ１１は、サービス提供サーバ５からのリクエストに応じて、しかるべきデータの設定や取得等の処理を行い、処理結果をレスポンスとしてサービス提供サーバ５に対して送信する機能を有する。また、ＡＰサーバ１１は、サービス提供サーバ５との間での通信を、本装置１におけるデータの保存形式に依存しない形式に変換する。

ＤＢサーバ１２は、各種データベース（図３〜図５）を有し、ＡＰサーバ１１から受け渡される各種リクエスト及び情報を受信し、各種データベースに対し、登録、更新、検索、取得等の各種処理を行う。グラフサーバ１３は、友だち関係を示すグラフデータを管理する。グラフサーバ１３は、キャッシュサーバであり、ＤＢサーバ１２に記憶されている、ユーザ毎に設定される「友だちユーザ」が更新される都度、友だち関係を示すグラフデータを再構築し、オンメモリにキャッシュする機能を有する。

ここで、図１との関係において、ＡＰサーバ１１は、要求処理手段３１、開示制御手段３６及び開示範囲送信手段３７に対応している。また、ＤＢサーバ１２は、プロフィール設定手段３２、プロフィール記憶手段４１、友だち属性設定手段３３、友だち属性記憶手段４２、開示条件設定手段３５及び開示条件記憶手段４４に対応している。また、グラフサーバ１３は、友だち関係設定手段３４及び友だち関係記憶手段４３に対応している。

（ＤＢサーバ１２のデータ構成）
次に、図３〜図５を参照して、ＤＢサーバ１２が有するデータベースのデータ構成例について説明する。

図３は、プロフィールＤＢを示す。プロフィールＤＢには、ユーザを識別する「ユーザＩＤ」に、「表示名」、「表示画像」、「生年月日」、「性別」、「血液型」、「所在地」、「自己紹介」、「所属（住所、学校、会社等）」、「嗜好（音楽、映画、本等）」といったユーザのアイデンティティを示す各項目と、各項目に対する「開示条件」とが関連付けられている。

「開示条件」は、ユーザが所有するリソース（この場合はプロフィールの各項目）の開示を許可する他ユーザを指定するデータである。例えば、プロフィールＤＢでは、他ユーザとの友だち関係が指定されており、「全体に開示」、「友だちまで」、「友だちの友だちまで」及び「開示しない」の何れかが設定されている。

「全体に開示」は、ユーザと他ユーザとの友だち関係の有無を問わず開示を許可する。「友だちまで」は、ユーザが友だちとしてリンクを設定した他ユーザ（つまり友だちユーザ）のみを対象とする。「友だちの友だちまで」は、友だちユーザに加えて、友だちユーザとの間で相互にリンクが設定された他ユーザ（以下、友だちの友だちユーザ）を対象とする。「開示しない」は、ユーザと他ユーザとの友だち関係の有無を問わず開示を許可しない。

図３に例示したように、ユーザＩＤ「User001」には、「表示名」及び「表示画像」に、「全体に開示」が設定されている。また、「生年月日」、「性別」、「血液型」、「所在地」及び「自己紹介」に、「友だちまで」が設定されている。さらに、「所属（住所、学校、会社等）」及び「嗜好（音楽、映画、本等）」に、「友だちの友だちまで」が設定されている。

図４は、友だちＤＢを示す。友だちＤＢには、各ユーザの「ユーザＩＤ」に、友だちユーザのユーザＩＤを示す「友だちユーザＩＤ」、その友だちユーザに対して設定された「友だち属性」、友だちユーザや友だち属性が設定されたサービス提供サーバ５（サービス元）を識別する「サービスＩＤ」が関連付けられている。

例えば、図４に例示するように、ユーザＩＤ「User001」には、友だちユーザＩＤとして、「User011」、「User021」及び「User31」が設定されている。また、友だちユーザＩＤ「User011」には、サービスＩＤ「Src001」では友だち属性「会社」が設定され、サービスＩＤ「Src002」では友だち属性「音楽」が設定されている。友だちユーザＩＤ「User021」には、サービスＩＤ「Src002」では友だち属性「会社」が設定され、サービスＩＤ「Src002」では友だち属性「映画」が設定されている。友だちユーザＩＤ「User031」には、サービスＩＤ「Src001」について友だち属性「学校」が設定されている。

なお、友だち属性の設定は、前述のプロフィールに含まれる「所属」や「嗜好」に挙げられる項目から任意に選択されるようにしても良いし、各サービス提供サーバ５において任意に定義することもできる。例えば、音楽配信サービスでは、音楽のジャンルに応じた友だち属性を定義し、グルメ情報サービスでは、料理のジャンルに応じた友だち属性を定義する、といった具合である。

図５は、コンテンツＤＢを示す。コンテンツＤＢには、各ユーザ（ここでは、コンテンツを投稿した投稿ユーザ）の「ユーザＩＤ」に、「サービスＩＤ」、サービス提供サーバ５において投稿されたコンテンツを識別する「コンテンツＩＤ」、「開示条件」が関連付けられている。

「コンテンツＩＤ」は、例えば、各サービス提供サーバ５が各自のデータベース上で管理するコンテンツを識別するために割り当てるＩＤである。例えば、本装置１からサービス提供サーバ５に対して、開示情報としてコンテンツＩＤが送信することにより、サービス提供サーバ５において開示を許可するコンテンツを指定することが可能となる。

「開示条件」は、ユーザが所有するリソース（この場合は各コンテンツ）の開示を許可する他ユーザを指定するデータである。例えば、コンテンツＤＢでは、投稿ユーザと他ユーザとの友だち関係と友だち属性とが指定されている。

例えば、図５に例示するように、ユーザＩＤ「User001」には、サービスＩＤ「Src001」について、コンテンツＩＤとして「Pic001（写真Ａ）」、「Pic002（写真Ｂ）」、「Pic003（写真Ｃ）」及び「Pic004（写真Ｄ）」が設定されている。また、「Pic001（写真Ａ）」及び「Pic002（写真Ｂ）」には、友だち関係として「友だちまで」が設定され、「Pic003（写真Ｃ）」及び「Pic004（写真Ｄ）」には、友だち関係として「友だちの友だちまで」が設定されている。さらに、「Pic001（写真Ａ）」には、友だち属性として「会社」タグが設定され、「Pic002（写真Ｂ）」には、友だち属性として「学校」タグが設定されている。つまり、「Pic001（写真Ａ）」であれば、「会社」に所属する友だちユーザに開示を許可する、という具合である。

他方、サービスＩＤ「Src002」について、コンテンツＩＤとして「Dia001（日記Ａ）」、「日記002（日記Ｂ）」、「Dia003（日記Ｃ）」及び「Dia004（日記Ｄ）」が設定されている。また、各コンテンツＩＤには、友だち関係として「友だちまで」が設定されている。さらに、「Dia001（日記Ａ）」には友だち属性として「音楽」タグが設定され、「Dia003（日記Ｃ）」には友だち属性として「本」タグが設定され、「Dia002（日記Ｂ）」及び「Dia004（日記Ｄ）」には、友だち属性として「映画」タグが設定されている。つまり、「Dia001（日記Ａ）」であれば、「音楽」に所属する友だちユーザに開示を許可する、という具合である。

（グラフサーバ１３のデータ構成）
次に、図６を参照して、グラフサーバ１３が有するデータ構成例について説明する。

図６は、ユーザグラフデータを示す。ユーザグラフデータには、「ユーザＩＤ」に、「友だちユーザＩＤ」と、友だちの友だちユーザのユーザＩＤを示す「友だちの友だちユーザＩＤ」とが関連付けられている。ユーザグラフデータは、各ユーザをノードに見立てて、ユーザの友だちや、そのユーザの友だちの友だち、といったユーザ間のリンク関係を示す情報である。

例えば、図６に例示するように、ユーザＩＤ「User001」には、友だちユーザＩＤとして「User011」、「User021」及び「User31」が設定されている。グラフ内において、友だちユーザは、任意のユーザを基点として、直接的なリンクが設定されたユーザ（隣接ノード）を特定する第１の範囲を示す。また、友だちの友だちユーザＩＤとして「User011」について「User012」が、「User021」について「User022」及び「User023」が、「User031」について「User032」が、それぞれ設定されている。グラフ内において、友だちの友だちユーザは、任意のユーザを基点として、友達ユーザを介してリンクが設定されたユーザを特定する第２の範囲を示す。

＜動作＞
次に、図７、図８及び図１０を参照して、本装置１を含むシステムの動作について説明する。

（各種設定処理）
図７は、本実施形態の処理例を示すシーケンス図であり、プロフィール、友だち・友だち属性、開示条件等の設定に関する処理例を示す。

まず、図示を省略したが、設定用ページがユーザ端末７に表示されるまでの処理を説明する。ユーザ端末７は、ブラウザからサービス提供サーバ５に対して設定用ページリクエストを送信する。なお、ログイン済みであるかどうかの確認は、例えばセッションＩＤ等を示すクッキーを読み込むことで行う。未だログインされていないものとすると、サービス提供サーバ５は、ユーザ端末７のブラウザにログインページを送信し、ログイン処理を行う。つまり、ユーザ端末７のブラウザは、ログインページを介してユーザにより入力されたユーザＩＤとパスワードをサービス提供サーバ５に送信し、サービス提供サーバ５は、ユーザＩＤとパスワードの照合を行う。

サービス提供サーバ５は、設定用ページのページデータを生成し、ページデータをユーザ端末７に対して送信する。ページデータはＨＴＴＰのレスポンス等に従ってブラウザに送信される。ユーザ端末７は、受信したページデータに基づいて、ブラウザにより設定用ページを表示する。例えば、プロフィールの設定に関する設定用ページには、プロフィールを構成する各項目（表示名等）及び各項目に対する開示条件をそれぞれ入力する領域が表示される。また、友だち及び友だち属性の設定に関する設定用ページには、他ユーザに対して相互リンクを設定する依頼（友だち依頼）を行うための領域や、他ユーザから送られた友だち依頼を承認するための領域や、友だちユーザに対して友だち属性を設定するための領域が表示される。さらに、投稿コンテンツの開示条件の設定に関する設定用ページには、投稿コンテンツと投稿コンテンツに対する開示条件をそれぞれ入力する領域が表示される。

（プロフィール設定）
続いて、図７を参照して、以降の処理例について説明する。前述の設定用ページを介してプロフィール及び開示条件がユーザにより入力されると、ユーザ端末７は、入力されたプロフィール及び開示条件をサービス提供サーバ５ａに対して送信する（ステップＳ１１）。

サービス提供サーバ５ａは、プロフィール及び開示条件を受信すると、設定リクエストを、本装置１のＡＰサーバ１１に対して送信する（ステップＳ１２）。設定リクエストには、ユーザＩＤ、プロフィール及び開示条件が含まれている。

ＡＰサーバ１１は、サービス提供サーバ５ａから設定リクエストを受信すると、ユーザＩＤ、プロフィール及び開示条件をＤＢサーバ１２に対して送信する（ステップＳ１３）。

これを受信したＤＢサーバ１２は、プロフィールＤＢ（図３）に対して、ユーザＩＤをキーに、プロフィールの各項目及び開示条件を関連付けて登録又は更新し、設定を行う（ステップＳ１４）。なお、ＤＢサーバ１２の各データベースにおける登録や参照や更新にはＳＱＬ（Structured Query Language）等のコマンドが用いられる。

続いて、ＤＢサーバ１２は、プロフィールの設定完了をＡＰサーバ１１に対して送信する（ステップＳ１５）。これを受信したＡＰサーバ１１は、プロフィールの設定について処理完了のレスポンスを、リクエスト元のサービス提供サーバ５ａに対して送信する（ステップＳ１６）。これを受けたサービス提供サーバ５ａは、ユーザ端末７に対して設定通知を行う。

（友だち・友だち属性設定）
一方で、前述の設定用ページを介して、友だち及び友だち属性がユーザにより入力されると、ユーザ端末７は、入力された友だち及び友だち属性をサービス提供サーバ５ｂに対して送信する（ステップＳ２１）。例えば、友だちユーザに対して友だち属性が入力された場合、友だちユーザＩＤに紐づけて友だち属性が送信される。

サービス提供サーバ５ｂは、友だち及び友だち属性を受信すると、設定リクエストを、本装置１のＡＰサーバ１１に対して送信する（ステップＳ２２）。設定リクエストには、リクエスト元のユーザＩＤ、友だちユーザＩＤ及び友だち属性が含まれている。

ＡＰサーバ１１は、サービス提供サーバ５ｂから設定リクエストを受信すると、サービス提供サーバ５ｂに割り当てられたサービスＩＤを特定し、ユーザＩＤ、友だちユーザＩＤ及び友だち属性ともに、ＤＢサーバ１２に対して送信する（ステップＳ２３）。

これを受信したＤＢサーバ１２は、友だちＤＢ（図４）に対して、ユーザＩＤをキーに、友だちユーザＩＤ、友だち属性及びサービスＩＤを関連付けて登録又は更新し、設定を行う（ステップＳ２４）。

なお、図示は省略しているが、友だちユーザＩＤの設定（つまり、友だち依頼とその承認）に関する処理については本装置１が管理するものである。例えば、友だち依頼を入力したユーザＩＤと依頼先のユーザＩＤとを記憶しておく。依頼先のユーザＩＤのログインがあったときに、そのユーザ端末７に対して友だち依頼通知を行う。そこで、友だち依頼の承認の入力があると、上記両ユーザＩＤについて一方にとって他方を、友だちユーザＩＤとして友だちＤＢに設定する、という具合である。

続いて、ＤＢサーバ１２は、設定完了をＡＰサーバ１１に対して送信する（ステップＳ２５）。これを受信したＡＰサーバ１１は、グラフサーバ１３に対して、ユーザグラフ更新リクエストを送信する（ステップＳ２６）。これを受信したグラフサーバ１３は、ＤＢサーバ１２が有する友だちＤＢ（図４）を参照し（ステップＳ２７）、ユーザグラフデータ（図６）を更新する（ステップＳ２８）。続いて、グラフサーバ１３は、ユーザグラフデータの更新完了をＡＰサーバ１１に対して送信する（ステップＳ２９）。

ＡＰサーバ１１は、友だち及び友だち属性の設定について処理完了のレスポンスを、リクエスト元のサービス提供サーバ５ｂに対して送信する（ステップＳ３０）。これを受けたサービス提供サーバ５ｂは、ユーザ端末７に対して設定通知を行う。

（コンテンツの開示条件設定）
また、一方で、前述の設定用ページを介して、コンテンツに対する開示条件がユーザにより入力されると、ユーザ端末７は、入力された開示条件をサービス提供サーバ５ｂに対して送信する（ステップＳ４１）。

サービス提供サーバ５ｂは、開示条件を受信すると、設定リクエストを、本装置１のＡＰサーバ１１に対して送信する（ステップＳ４２）。設定リクエストには、リクエスト元のユーザＩＤ、開示条件が設定されたコンテンツＩＤ及び開示条件が含まれている。

ＡＰサーバ１１は、サービス提供サーバ５ｂから設定リクエストを受信すると、サービス提供サーバ５ｂに割り当てられたサービスＩＤを特定し、ユーザＩＤ、コンテンツＩＤ及び開示条件とともに、ＤＢサーバ１２に対して送信する（ステップＳ４３）。

これを受信したＤＢサーバ１２は、コンテンツＤＢ（図５）に対して、ユーザＩＤをキーに、サービスＩＤ、コンテンツＩＤ及び開示条件を関連付けて登録又は更新し、設定を行う（ステップＳ４４）。

続いて、ＤＢサーバ１２は、設定完了をＡＰサーバ１１に対して送信する（ステップＳ４５）。これを受信したＡＰサーバ１１は、コンテンツの開示条件の設定について処理完了のレスポンスを、リクエスト元のサービス提供サーバ５ｂに対して送信する（ステップＳ４６）。これを受けたサービス提供サーバ５ｂは、ユーザ端末７に対して設定通知を行う。

（開示制御：プロフィール開示要求時）
図８は、本実施形態の処理例を示すシーケンス図であり、ユーザが他ユーザのプロフィールの開示を要求した場合の開示制御に関する処理例である。

ユーザ端末７は、ブラウザからサービス提供サーバ５ｃに対してプロフィール開示リクエストを送信する（ステップＳ６１）。この処理例では、既にユーザがログイン済みであるとする。

サービス提供サーバ５ｃは、プロフィール開示リクエストを受信すると、開示要求ユーザのユーザＩＤ（以下、開示要求ユーザＩＤ）及び開示対象ユーザのユーザＩＤ（以下、開示対象ユーザＩＤ）を特定し（ステップＳ６２）、本装置１のＡＰサーバ１１に対して、開示リクエストを送信する（ステップＳ６３）。開示リクエストには、開示対象ユーザＩＤ及び開示要求ユーザＩＤが含まれている。

ＡＰサーバ１１は、サービス提供サーバ５ｃから開示リクエストを受信すると、グラフサーバ１３に対して、友だち関係判定リクエストを送信する（ステップＳ６４）。友だち関係判定リクエストには、開示対象ユーザＩＤ及び開示要求ユーザＩＤが含まれている。

グラフサーバ１３は、ＡＰサーバ１１から友だち関係判定リクエストを受信すると、友だち関係を判定する（ステップＳ６５）。つまり、グラフサーバ１３は、開示対象ユーザＩＤをキーにして、ユーザグラフデータ（図６）を参照し、キーにしたユーザＩＤに関連付けられて記憶されている「友だちユーザＩＤ」及び「友だちの友だちユーザＩＤ」の中に、開示要求ユーザＩＤが含まれているか否かを判定する。

続いて、グラフサーバ１３は、判定結果をＡＰサーバ１１に対して送信する（ステップＳ６６）。つまり、グラフサーバ１３は、開示要求ユーザＩＤが「友だちユーザＩＤ」に含まれている場合であれば、「友だち」を示す値をＡＰサーバ１１に対して送信する。一方、グラフサーバ１３は、開示要求ユーザＩＤが「友だちの友だちユーザＩＤ」に含まれている場合であれば、「友だちの友だち」を示す値をＡＰサーバ１１に対して送信する。なお、グラフサーバ１３は、開示要求ユーザＩＤが何れにも含まれていない場合であれば、「友だち関係なし」を示す値をＡＰサーバ１１に対して送信する。

ＡＰサーバ１１は、判定結果を受信すると、プロフィール取得リクエストをＤＢサーバ１２に対して送信する（ステップＳ６７）。プロフィール取得リクエストには、開示対象ユーザＩＤと、判定結果の友だち関係が含まれている。

ＤＢサーバ１２は、プロフィール取得リクエストを受信すると、開示範囲を決定する（ステップＳ６８）。つまり、ＤＢサーバ１２は、判定結果が「友だち関係なし」であれば、これを満たす開示条件を、「全体に開示」のみとする。また、判定結果が「友だちの友だち」であれば、これを満たす開示条件を、「全体に開示」に加えて、「友だちの友だちまで」とする。さらに、判定結果が「友だち」であれば、これを満たす開示条件として、「全体に開示」及び「友だちの友だち」に加えて、「友だちまで」とする。そして、ＤＢサーバ１２は、開示対象ユーザＩＤをキーにして、プロフィールＤＢ（図３）を参照し、キーにしたユーザＩＤに関連付けられているプロフィールから、開示条件を満たす項目を取得する。例えば、図３に示す例を引用すると、開示対象ユーザＩＤが「User001」であり、判定結果の友だち関係が「友だち」であれば、プロフィールを構成する項目の全てが取得されることになる。

続いて、ＤＢサーバ１２は、開示範囲として決定したプロフィールをＡＰサーバ１１に対して送信する（ステップＳ６９）。ＡＰサーバ１１は、受信したプロフィールを開示情報として、サービス提供サーバ５ｃに対して送信する（ステップＳ７０）。

サービス提供サーバ５ｃは、開示情報としてプロフィールを受信すると、受信したプロフィールに基づいて、プロフィール閲覧用ページのページデータを生成し（ステップＳ７１）、プロフィール開示リクエストのあったユーザ端末７のブラウザに対して送信する（ステップＳ７２）。ページデータを受信したユーザ端末７のブラウザは、プロフィール閲覧用ページを表示する（ステップＳ７３）。

図９は、プロフィール閲覧用ページの表示例を示している。プロフィール閲覧用ページ１０１には、カード形状に構成されたプロフィール表示領域１０２及び表示画像領域１０３が設けられている。

ここで、図３及び図６に示す例を引用して、開示要求ユーザと開示対象ユーザとの間の友だち関係の相違に応じた、プロフィールの表示分けについて説明する。開示対象ユーザが「User001」である場合に、開示要求ユーザが「User011」であれば、両者は友だち同士であるので（図６を参照）、図９の（１）に示すように、「User001」のプロフィールを構成する全ての項目（図３を参照）がプロフィール表示領域１０２に表示される。これに対して、開示要求ユーザが「User022」であるとき、両者は友だちの友だち同士であるので（図６を参照）、図９の（２）に示すように、「User001」のプロフィールの中で、「嗜好（音楽、映画、本等）」及び「所属（住所、学校、会社等）」という一部の項目の開示が制限され、「表示名」、「表示画像」、「生年月日」、「性別」、「血液型」、「所在地」及び「自己紹介」といった項目（図３を参照）がプロフィール表示領域１０２に表示される。

なお、前述した例では、プロフィールＤＢ（図３）は、開示条件として友だち関係のみを設定しているが、これに限らず、コンテンツＤＢ（図５）と同様に、友だち関係に加えて友だち属性を設定するようにしても良い。これにより、プロフィールについても開示要求ユーザの友だち属性を考慮して開示制御を行うことができる。また、プロフィールＤＢ（図３）は、プロフィールを構成する各項目及び開示条件をサービス毎に設定するようにしても良い。

（開示制御：コンテンツ開示要求時）
図１０は、本実施形態の処理例を示すシーケンス図であり、ユーザが他ユーザにより投稿されたコンテンツの開示を要求した場合の開示制御に関する処理例である。

ユーザ端末７は、ブラウザからサービス提供サーバ５ｃに対して、コンテンツ開示リクエストを送信する（ステップＳ９１）。例えば、写真投稿サービスを例にすると、あるユーザに割り当てられたページであって、投稿写真や記事が掲載されたページのリクエストである。なお、この処理例では、ユーザが既にログイン済みであるとする。

サービス提供サーバ５ｃは、コンテンツ開示リクエストを受信すると、開示対象ユーザＩＤ及び開示要求ユーザＩＤを特定し（ステップＳ９２）、本装置１のＡＰサーバ１１に対して、開示リクエストを送信する（ステップＳ９３）。開示リクエストには、開示対象ユーザＩＤ及び開示要求ユーザＩＤが含まれている。

ＡＰサーバ１１は、サービス提供サーバ５ｃから開示リクエストを受信すると、サービス提供サーバ５ｃに割り当てられたサービスＩＤを特定し、グラフサーバ１３に対して、友だち関係判定リクエストを送信する（ステップＳ９４）。友だち関係判定リクエストにはサービスＩＤ、開示対象ユーザＩＤ及び開示要求ユーザＩＤが含まれている。

グラフサーバ１３は、ＡＰサーバ１１から友だち関係判定リクエストを受信すると、友だち関係を判定する（ステップＳ９５）。つまり、グラフサーバ１３は、開示対象ユーザＩＤをキーにして、ユーザグラフデータ（図６）を参照し、キーにしたユーザＩＤに関連付けられて記憶されている「友だちユーザＩＤ」及び「友だちの友だちユーザＩＤ」の中に、開示要求ユーザＩＤが含まれているか否かを判定する。続いて、グラフサーバ１３は、判定結果をＡＰサーバ１１に対して送信する（ステップＳ９６）。

続いて、ＡＰサーバ１１は、ステップＳ９６で受信した判定結果が友だち関係である場合に、友だち属性判定リクエストをＤＢサーバ１２に対して送信する（ステップＳ９７）。友だち属性判定リクエストには、サービスＩＤ、開示対象ユーザＩＤと開示要求ユーザＩＤが含まれている。

ＤＢサーバ１２は、友だち属性判定リクエストを受信すると、友だち属性の判定を行う（ステップＳ９８）。つまり、ＤＢサーバ１２は、開示対象ユーザＩＤをキーにして、友だちＤＢ（図４）を参照し、開示要求ユーザＩＤ及びサービスＩＤに関連付けて「友だち属性」が記憶されているか否かを判定し、記憶されている場合に「友だち属性」を取得する。例えば、図４に示す例を引用すると、開示対象ユーザＩＤが「User001」であり、開示要求ユーザＩＤが「User011」であれば、友だち属性「会社」が取得されることになる。続いて、ＤＢサーバ１２は、判定結果をＡＰサーバ１１に対して送信する（ステップＳ９９）。

なお、前述の例では、友だちＤＢ（図４）は、友だち属性をサービスＩＤに関連付けて記憶しているが、本発明はこれに限らず、各サービスで設定された友だち属性を、サービスＩＤに紐付けることなく複数設定するようにし、コンテンツＤＢ（図５）におけるサービス毎の開示条件に含まれる属性と合致するものがあるか否かを判定することによって、開示範囲を決定するようにしても良い。上記のような態様によっても、サービス毎にリソースの開示制御を行うことができる場合がある。

続いて、ＡＰサーバ１１は、ステップＳ９６及びステップＳ９９において、判定結果を受信すると、コンテンツ取得リクエストをＤＢサーバ１２に対して送信する（ステップＳ１００）。コンテンツ取得リクエストには、サービスＩＤ、開示対象ユーザＩＤ、判定結果の友だち関係及び友だち属性が含まれている。

ＤＢサーバ１２は、コンテンツ取得リクエストを受信すると、開示範囲を決定する（ステップＳ１０１）。つまり、ＤＢサーバ１２は、開示対象ユーザＩＤ及びサービスＩＤをキーにして、コンテンツＤＢ（図５）を参照し、開示対象ユーザＩＤ及びサービスＩＤに関連付けられているコンテンツＩＤから、開示条件を満たすものを取得する。例えば、図４に示す例を引用すると、開示対象ユーザＩＤが「User001」であり、判定結果の友だち関係が「友だち」であり、かつ判定結果の友だち属性が「会社」であれば、コンテンツＩＤ「Pic001（写真Ａ）」、「Pic003（写真Ｃ）」及び「Pic004（写真Ｄ）」が取得される。なお、判定結果の友だち関係が「友だち」であり、判定結果の友だち属性が記憶されていなければ、コンテンツＩＤ「Pic002（写真Ｂ）」が併せて取得される。

続いて、ＤＢサーバ１２は、開示範囲として決定したコンテンツＩＤをＡＰサーバ１１に対して送信する（ステップＳ１０２）。ＡＰサーバ１１は、受信したコンテンツＩＤを開示情報として、サービス提供サーバ５ｃに対して送信する（ステップＳ１０３）。

サービス提供サーバ５ｃは、開示情報としてコンテンツＩＤを受信すると、受信したコンテンツＩＤに基づいて、コンテンツが蓄積されているデータベースからコンテンツを取得する（ステップＳ１０４）。続いて、サービス提供サーバ５ｃは、取得したコンテンツを表示するコンテンツ閲覧用ページのページデータを生成し（ステップＳ１０５）、開示リクエストのあったユーザ端末７のブラウザに対して送信する（ステップＳ１０６）。ページデータを受信したユーザ端末７のブラウザは、コンテンツ閲覧用ページを表示する（ステップＳ１０７）。

図１１及び図１２は、コンテンツ閲覧用ページの表示例を示している。コンテンツ閲覧用ページ１１１には、コンテンツ表示領域１１２が設けられている。

ここで、図３〜図６に示す例を引用して、サービス毎に、開示要求ユーザと開示対象ユーザとの友だち関係の相違に応じた、コンテンツの表示分けについて説明する。開示対象ユーザが「User001」である場合に、サービスＩＤが「Src001（例えば写真投稿サービス）」であり、開示要求ユーザが「User011」であれば、開示要求ユーザ「User011」は友だちユーザであり（図６を参照）、かつそのサービスでの友だち属性が「会社」である（図４を参照）ので、図１１の（１）に示すように、「User001」が有するコンテンツの中で、「Pic001（写真Ａ）」、「Pic003（写真Ｃ）」及び「Pic004（写真Ｄ）」が（図５を参照）コンテンツ表示領域１１２に表示される。これに対して、開示要求ユーザが「User022」であれば、開示要求ユーザ「User022」は友だちの友だちユーザである（図６を参照）ので、図１１の（２）に示すように、「User001」が有するコンテンツの中で、「Pic003（写真Ｃ）」及び「Pic004（写真Ｄ）」が（図５を参照）コンテンツ表示領域１１２に表示される。

また、開示対象ユーザが「User001」である場合に、サービスＩＤが上記と異なる「Src002（例えば日記投稿サービス）」であり、開示要求ユーザが「User011」であれば、開示要求ユーザ「User011」は友だちユーザであり（図６を参照）、かつそのサービスでの友だち属性が「音楽」である（図４を参照）ので、図１２の（１）に示すように、「User001」が有するコンテンツの中で、「Dia001（日記Ａ）」が（図５を参照）コンテンツ表示領域１１２に表示される。他方、開示要求ユーザが「User021」であるとき、開示要求ユーザ「User021」は友だちユーザであり（図６を参照）、かつそのサービスでの友だち属性が「映画」である（図４を参照）ので、図１２の（２）に示すように、「User001」が有するコンテンツの中で、「Dia002（日記Ｂ）」及び「Dia004（日記Ｄ）」が（図５を参照）コンテンツ表示領域１１２に表示される。

以上説明したように、本装置１は、各サービス提供サーバのそれぞれに対して、リソースの開示範囲を制御する機能を提供する。つまり、本装置１は、各サービス提供サーバ５に共通するユーザ間の友だち関係（グラフサーバ１３が有する図６のユーザグラフデータを参照）と、友だちユーザの友だち属性（ＤＢサーバ１２が有する図４の友だちＤＢを参照）とに基づいて、サービス提供サーバ５毎に、各ユーザに応じたリソースの開示範囲を決定する。より具体的には、各リソースについて開示を許可する友だち関係及び友だち属性を指定する開示条件（ＤＢサーバ１２が有する図３のプロフィールＤＢと図５のコンテンツＤＢを参照）を、サービス提供サーバ５に応じて管理し、各サービス提供サーバから送信された、開示要求ユーザ及び開示対象ユーザの指定を含むリクエストに応じて、開示要求ユーザと開示対象ユーザとの友だち関係の判定を行い、この判定結果と、開示要求ユーザに関連付けられた友だち属性とを加味して、開示要求ユーザに開示を許可するリソースを決定するようにした。

したがって、サービス提供側にとっては、上記機能を実現する仕組みを各サービスにおいて独自に構築する必要がなく、システム開発や維持管理を意識せずとも、上記機能を実装したサービスをユーザ側に提供することができるようになる。また、各サービス提供サーバに共通するユーザ間の友だち関係を利用するので、ユーザ側からすれば、利用しているサービス間の相違を意識することなく、自らの友だち関係を管理することができるうえ、さらに、友だち関係にある他ユーザの属性を考慮して、サービス毎にリソースの開示制御を行うことができる。また、サービス毎に開示条件を設定することで、リソースの開示範囲の制御をサービスに応じて任意に使い分けることができるようになる。

以上、本発明の好適な実施形態により本発明を説明した。ここでは、特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨及び範囲から逸脱することなく、これら具体例に様々な修正及び変更を加えることができることは明らかである。すなわち、具体例の詳細及び添付の図面により本発明が限定されるものと解釈してはならない。

１ 開示制御機能提供装置
３ システム
５ サービス提供サーバ
７ ユーザ端末
１１ アプリケーションサーバ
１２ データベースサーバ
１３ グラフサーバ
３１ 要求処理手段
３２ プロフィール設定手段
３３ 友だち属性設定手段
３４ 友だち関係設定手段
３５ 開示条件設定手段
３６ 開示制御手段
３７ 開示範囲送信手段
５１ 入力処理手段
５２ コンテンツ管理手段
５３ 設定手段
５４ 開示範囲取得手段
５５ ページデータ生成手段
５６ ページデータ送信手段
１０１ プロフィール閲覧用ページ
１０２ プロフィール表示領域
１０３ 表示画像領域
１１１ コンテンツ閲覧用ページ
１１２ コンテンツ表示領域

Claims (4)

1. ユーザ端末からのリクエストに応じて各種リソースを当該ユーザ端末に対して送信する複数のサービス提供サーバとネットワークを介して接続され、
   各サービス提供サーバに共通するユーザ間の関係について、各ユーザに関する友だちユーザの設定内容から構築した少なくとも友だちと友だちの友だちとを区別するリンク関係を示すグラフデータを記憶する関係記憶手段と、
   前記ユーザにより前記リンク関係が設定された他ユーザの属性データを各サービス提供サーバに対応付けて記憶する属性記憶手段と、
   前記ユーザにより設定された各リソースについて、当該リソースの開示を許可する開示条件として、当該ユーザと開示を許可する他ユーザとの間の関係について少なくとも友だちと友だちの友だちとを区別するリンク関係および前記他ユーザの属性データからなる開示条件を、前記各サービス提供サーバに対応付けて記憶する開示条件記憶手段と、
   前記ユーザ端末からのリクエストに応じて前記サービス提供サーバから送信された開示リクエストに応じて、当該開示リクエストで指定された開示要求ユーザと開示対象ユーザとの間の前記リンク関係を前記関係記憶手段から取得するとともに、当該開示要求ユーザに関する前記属性データを前記属性記憶手段から取得し、当該サービス提供サーバと当該開示対象ユーザに対応する前記リソースのうち、当該リンク関係及び当該属性データが当該リソースの前記開示条件を満たすリソースを、前記開示条件記憶手段から、当該開示要求ユーザへの開示を許可する開示許可リソースとして決定する開示制御手段と、
   前記開示制御手段により決定された前記開示許可リソースを示す開示範囲を当該サービス提供サーバに対して送信する送信手段と、を備えたことを特徴とする開示制御機能提供装置。
2. 相互にネットワークを介して接続された、ユーザ端末からのリクエストに応じて各種リソースを当該ユーザ端末に対して送信する複数のサービス提供サーバと、各ユーザに応じたリソースの開示範囲を決定する開示制御機能提供装置と、を備え、
   前記開示制御機能提供装置は、
   各サービス提供サーバに共通するユーザ間の関係について、各ユーザに関する友だちユーザの設定内容から構築した少なくとも友だちと友だちの友だちとを区別するリンク関係を示すグラフデータを記憶する関係記憶手段と、
   前記ユーザにより前記リンク関係が設定された他ユーザの属性データを各サービス提供サーバに対応付けて記憶する属性記憶手段と、
   前記ユーザにより設定された各リソースについて、当該リソースの開示を許可する開示条件として、当該ユーザと開示を許可する他ユーザとの間の関係について少なくとも友だちと友だちの友だちとを区別するリンク関係および前記他ユーザの属性データからなる開示条件を、前記各サービス提供サーバに対応付けて記憶する開示条件記憶手段と、
   前記ユーザ端末からのリクエストに応じて前記サービス提供サーバから送信された開示リクエストに応じて、当該開示リクエストで指定された開示要求ユーザと開示対象ユーザとの間の前記リンク関係を前記関係記憶手段から取得するとともに、当該開示要求ユーザに関する前記属性データを前記属性記憶手段から取得し、当該サービス提供サーバと当該開示対象ユーザに対応する前記リソースのうち、当該リンク関係及び当該属性データが当該リソースの前記開示条件を満たすリソースを、前記開示条件記憶手段から、当該開示要求ユーザへの開示を許可する開示許可リソースとして決定する開示制御手段と、
   前記開示制御手段により決定された前記開示許可リソースを示す開示範囲を当該サービス提供サーバに対して送信する送信手段と、を備え、
   前記サービス提供サーバは、
   前記ユーザ端末からのリソース閲覧リクエストに応じて、開示要求ユーザ及び開示対象ユーザの指定を含む前記開示リクエストを前記開示制御機能提供装置に対して送信し、当該開示制御機能提供装置が決定した前記開示許可リソースを示す前記開示範囲を取得する開示範囲取得手段と、
   前記開示範囲取得手段が取得した前記開示範囲に基づいて、前記開示許可リソースからリソース閲覧用ページのページデータを生成するページデータ生成手段と、
   前記ページデータ生成手段が生成した前記ページデータをユーザ端末に送信するページデータ送信手段と、を備えたことを特徴とする閲覧制御機能提供システム。
3. 複数のサービス提供サーバとネットワークを介して接続された開示制御機能提供装置が実行する方法であって、
   各サービス提供サーバに共通するユーザ間の関係について、各ユーザに関する友だちユーザの設定内容から構築した少なくとも友だちと友だちの友だちとを区別するリンク関係を示すグラフデータを記憶する関係記憶ステップ、
   前記ユーザによりリンク関係が設定された他ユーザの属性データを各サービス提供サーバに対応付けて記憶する属性記憶ステップ、
   ユーザにより設定された各リソースについて、開示を許可する開示条件として、当該ユーザと開示を許可する他ユーザとの間の関係について少なくとも友だちと友だちの友だちとを区別するリンク関係及び前記他ユーザの属性データからなる開示条件を、各サービス提供サーバに対応付けて記憶する開示条件記憶ステップ、
   ユーザ端末からのリクエストに応じて前記サービス提供サーバから送信された、リソースの開示要求をした開示要求ユーザの指定を含むリクエストに応じて、前記開示要求ユーザと前記開示要求がされたリソースを設定したユーザとのリンク関係及び前記開示要求ユーザの属性データが、前記開示要求がされたリソースに対して記憶されている前記開示条件を満たす場合に、当該リソースの開示許可を決定する開示制御ステップ、及び
   前記開示制御手段により決定された前記リソースの開示許可を、前記リクエストを送信したサービス提供サーバに対して送信する送信ステップ、を含むことを特徴とする開示制御機能提供方法。
4. コンピュータを、請求項１に記載の開示制御機能提供装置を構成する各部として機能させるためのプログラム。

Images