JP2005346494A - コンテンツ共有システム及びコンテンツ重要度判定方法 - Google Patents

Abstract

【課題】 コンテンツ共有システムにおいて、個々のユーザに対して任意のコンテンツの重要度を判定し、ユーザにとって価値のある通知メッセージを、適切にクライアント又は外部ツールへ通知することを目的とする。さらには、ユーザのコンテンツへのアクセス履歴の開示レベルを、アクセスユーザが設定できるようにする。
【解決手段】 サーバ上のマルチメディアデータのコンテンツを複数ユーザのクライアントで共有するコンテンツの重要度を判定するものであって、既存のデータ又はユーザの環境を解釈して個々のユーザに対するコンテンツの重要度を算出し、クライアントの状態を判断し、クライアント状態又はクライアントからの指示に応じて通知ルール設定を変更し、算出されたコンテンツの重要度と通知ルールに基づき適切な宛先へ通知メッセージを発行する。
【選択図】 図９

Description

本発明は、コンテンツ共有システム及びコンテンツ重要度判定方法に関し、特に、個々のユーザに対してあるコンテンツの重要度を判別し、ユーザに価値ある通知メッセージを送るコンテンツ共有システム及びそのコンテンツ重要度判定方法に関する。

従来、インターネット等のサーバにアップロードされたマルチメディアデータのコンテンツを複数のユーザ間で共有するコンテンツ共有システムが提供されている。一方、コミュニケーションシステム及びマルチメデイア技術の発達により、従来にまして、多くのユーザ、コミュニティとの関係を保つために、様々なツールやマルチメディアデータを利用できるようになった。それ故に、コンテンツ共有システム上に出回るコンテンツの量が膨大なものとなっている。しかし、自分に関係のないコンテンツはいわばノイズであり、自分に必要なコンテンツの確認をより困難にする要因となっている。現在、これらの状況に対して、多くのコンテンツの中から重要度の高いものだけを取り出す方法が求められている。

また、上記に関連して、コンテンツ共有システム上にユーザにとって重要度の高いコンテンツが存在する場合や、そのコンテンツに変更があったことなどを通知してくれるシステムも望まれている。通知メッセージが発行された場合、その通知メッセージをもらったユーザはそのメッセージに記録された内容から所定のコンテンツにアクセスして閲覧することができる。

重要度の高いデータを取り出すものとしては、例えば電子メールなどのテキストベースの文書に対し、テキストクラシファイアを使って優先順位付けし、その優先順位に基づいて、警報の生成及び伝達を行うものが提案されている（例えば、特許文献１参照）。

また、ユーザに通知するシステムとしては、例えばユーザに対応付けられたコンテンツに変更があったときにそのユーザへメールで知らせるシステムが提案されている（例えば、特許文献２参照。）。
特表２００３−５２７６５６号公報 特開２００４−５５００号公報

しかしながら、特許文献１に記載のシステムではテキストベースの文書に限られており、また過去のコミュニケーションの履歴が優先順位に反映されないという問題があった。

また、特許文献２に記載のものは、通知メールに重要度という概念がなく、コンテンツ変更に関するすべての通知が登録されたメールアドレスに送られてしまう。また、ユーザの状態に応じて、通知の内容や頻度を容易に変更することができない。またクライアントが複数ある場合に通知メッセージを適切に振り分けることはできない。またメールによって通知の開始／停止を制御することはできないなどの問題があった。

一方、インスタントメッセンジャーでは、ログインしているクライアントに通知が送出される。クライアント毎にメンバーのログイン、メッセージ／メールの受信などの通知のオン／オフを変更できる。しかし通知するかしないかは受信者側のオン／オフの設定でしか判別できない上、メールなどの他のメディアに通知を送信することはできない

またこれらのシステムはすべて通知の受け取り側の判断のみによって通知するかしないかを設定するが、コンテンツ投稿者のお勧め度と通知受信者の興味度とを考慮して通知するかしないかを判断するシステムはない。

現在広く用いられるコンテンツ共有のシステムとしては、ＷＷＷ（World Wide Web）が存在し、ＷＷＷにおいては、ユーザは所定のディレクトリにＨＴＭＬ等のファイルを置くことにより、それらのファイルを公開することができる。ＷＷＷでは、閲覧ユーザは、ウェブブラウザを用いてコンテンツを閲覧する。このとき、閲覧ユーザのアクセス情報は、ＨＴＴＰサーバ(Apache、IIS（Internet Information Server:マイクロソフト社製）等)によって、ログに記録される。

コンテンツ作成者は、サーバにアクセスする権限がある場合には、これらのログを直接見ることもできるし、適当なツールを用いてビジュアライズすることでもできる。また、アクセスカウンターなどをもちいて、そのコンテンツへのアクセスしたユーザの数を表示することもできる。

これらのシステムの問題は、ユーザがアクセス履歴のパーミッションを設定できないというものである。閲覧ユーザにとって、自分がアクセスしたことを誰が知ることができるかが明らかでなく、また、コントロールもできない。すなわち、ウェブページの作成者がサーバのアクセスログの閲覧許可を持っているか持っていないかは、閲覧ユーザにとって明らかでない。

また、ウェブページによっては、ＣＧＩ（Common Gateway Interface）等を利用して、ユーザがコメントを残したり、そのページの有用度をボタンで送信したりすることができる。このようなシステムでは、閲覧ユーザはある種のアクセス情報を送信しているとみなすこともできるが、そのページの所有者がＣＧＩ等を設置する必要があり、また、閲覧ユーザは明示的にコメントを書いたりボタンを押したりする必要がある。ユーザが手軽に自分の訪問を伝える手段とは必ずしも言えないという不都合があった。

斯かる点に鑑み、本発明は、コンテンツ共有システムにおいて、個々のユーザに対して任意のコンテンツの重要度を判定し、ユーザにとって価値のある通知メッセージを、適切にクライアント又は外部ツールへ通知することを目的とする。さらには、ユーザのコンテンツへのアクセス履歴の開示レベルを、アクセスユーザが設定できるようにすることを目的とする。

上記課題を解決し、目的を達成するため、本発明は、サーバ上のマルチメディアデータのコンテンツを複数ユーザのクライアントで共有するコンテンツの重要度を判定するものであって、既存のデータ又はユーザの環境を解釈して個々のユーザに対するコンテンツの重要度を算出し、クライアントの状態を判断し、クライアント状態又はクライアントからの指示に応じて通知ルール設定を変更し、算出されたコンテンツの重要度と通知ルールに基づき適切な宛先へ通知メッセージを発行する。

上述の発明における一実施の形態として、上記既存のデータを、例えばコンテンツ自体に記録された情報を利用することが好適である。

さらに、上述の発明における他の実施の形態として、上記既存のデータを、例えばユーザのコンテンツ投稿履歴及びコンテンツ閲覧履歴からなるコミュニケーションの履歴情報を利用することが好適である。

斯かる本発明によれば、コンテンツ共有システムにおいて、例えばユーザの利用履歴や設定情報、環境情報などを用いてコンテンツの重要度を決めることによって、テキストデータや各種メディアデータの境界なくユーザの興味、状況、環境等に合わせたコンテンツの提示が容易に実現可能である。そして、ユーザが複数のデバイス又はクライアントを使い分けている状況において、ユーザにとって重要度の高い価値のある通知メッセージを、適切にクライアント又は外部ツールへ通知することができる。

本発明によれば、コンテンツ共有システムにおいて、例えばユーザの利用履歴や設定情報、環境情報などを用いてコンテンツの重要度を決めることによって、テキストデータや各種メディアデータの境界なくユーザの興味、状況、環境等に合わせたコンテンツの提示が容易に実現可能となる。そして、ユーザが複数のデバイス又はクライアントを使い分けている状況において、ユーザにとって重要度の高い価値のある通知メッセージを、適切にクライアント又は外部ツールへ通知することができるという効果がある。

また、クライアントに応じて、又はユーザの状態に応じて必要な通知のみを受け取るようにすることができる。また、コンテンツ投稿者のお勧め度と通知の受信者の興味度に応じて、他の関係も加味して、通知受信者にとって価値のある通知を検出できるという効果がある。

以下、図１〜図２４を参照して、本発明の一実施の形態の例について説明する。本例は、マルチメディアデータを複数のユーザ間で共有するシステムにおいて、個々のユーザに対してあるコンテンツの重要度を判定できるようにしたものである。

最初に、コンテンツ共有システムの概要について、図１〜図８を用いて説明する。コンテンツ共有システムは、複数のユーザが、静止画像、動画、音声、テキストを例とするマルチメディアデータをインターネット等の通信網を介して記録、読み出すことができるシステムである。このシステムの基本的な構成は、インターネット等の通信網上のサーバと、各ユーザが操作する複数のクライアントからなる。

図１は、コンテンツ共有システムの概略構成を示す図である。図１において、コンテンツ管理部２００は、後述するメディアデータとメタデータからなるコンテンツ（図４参照）を管理するモジュールであり、コンテンツの保存、修正、コメント追加、閲覧等を制御する。また、適切な認証手段により、許可されたクライアントのみが各種操作を実行することができるようになっている。

またクライアント１００及び１０１は、ユーザが直接操作を行うアプリケーションプログラムであり、メディアのキャプチャ、テキスト入力などのユーザインターフェース、位置情報などのメタデータの取得、コンテンツ管理部２００へのコンテンツの登録、コンテンツの表示等の機能を提供するものである。ユーザはクライアントを介して、システム上に公開されたコンテンツの閲覧、登録、取得、削除、変更等の操作を行うことができる。

また表示構成部３００は、コンテンツ管理部２００からコンテンツデータを取得し、適切な形にレイアウトするものであり、サーバ上又はクライアント端末のいずれかに格納されていればよい。レイアウト方法は、例えば複数ユーザのコンテンツを最新順に表示したり、特定ユーザのコンテンツのみを表示する等、種々の方法が適用できる。

図１に示されるコンテンツ共有システムの具体的な構成方法の一例は、例えばコンテンツ管理部をJava（登録商標）Servletとし、表示構成部及びクライアントを携帯電話上で動作するJavaアプリケーションプログラムとするものである。

また、コンテンツ共有システムの異なる構成方法の一例は、例えばコンテンツ管理部と表示構成部をJava Servletとし、クライアントをＰＣ（パーソナルコンピュータ）上などのウェブブラウザとするものである。

クライアント、サーバ、いずれもコンピュータ上のプログラムとして動作し、データはそれらの図示しない不揮発性の記録媒体に記録される。

以下、コンテンツ共有システムについてより具体的な例を用いて説明する。図２は、例えばコンテンツ共有システムを用いた電子掲示板システムのユーザ利用画面である、コンテンツコンテナ表示画面の一例である。ここでは６人のユーザ（山田、佐藤、加藤、佐々木、木村、飯島）が互いにコンテンツを共有している。本システムでは、特定のコンテンツの集合を、コンテンツコンテナ（単にコンテナともいう。）と呼ぶ。

コンテンツコンテナには複数のユーザが複数のコンテンツを書き込み、また読み出すことができる。更に、コンテンツコンテナにはユーザごとのアクセス権を設定することができる。この例では説明の簡略化のため、コンテンツの書き込み方法を２つに定義している。１つは、画像投稿であり、画像データとそのタイトルを書き込みの単位とする。もう１つは、コメント投稿であり、テキストデータによる文章を書き込みの単位とするものである。

図２においては、「９０年度３年Ｂ組の部屋」というコンテナ名称１１のコンテンツコンテナに、ユーザが画像やコメントを投稿した例を表している。例えば、画像データ表示１３は、山田というユーザによって投稿された画像であり、投稿者・タイトル表示１４において、投稿者名と投稿者が設定したタイトルが表示されている。投稿者・コメント表示１６は、この山田の投稿に対して、他のユーザがコメントを投稿した結果の表示である。図では１つのコメントは１行に表示されているがこの限りではない。

また、図２において、１２はこのコンテンツコンテナに画像を投稿する際に押下する画像投稿ボタン、１５はコメントを投稿する際に使用するコメントボタン、１７はコンテンツコンテナを作成する際に使用するコンテナ作成ボタンである。

次に、本システムにおいて、投稿、コメント、閲覧がどのような方法によって実現されているかを説明する。まず、図２〜図６を参照して、画像投稿時の動作について述べる。

図３は、コンテンツ管理部２００の内部構成を示したものである。コンテンツ管理部２００は、制御部２０１、コンテンツデータ部（コンテンツ保存部）２０２、アクションデータ部２０３、認証データ部２０４から構成されている。

図３において、コンテンツ管理部２００内の制御部２０１は、外部からの各種コマンドの受付、内部のデータの管理、表示構成部３００への表示指示などを行う。またコンテンツデータ部２０２は、コンテンツ及びコンテンツコンテナのデータを保存する。またアクションデータ部２０３は、何らかの処理を行うコードが保存されている。さらに認証データ部２０４は、ユーザデータ、パスワードなどの認証に必要なデータが保存される。この認証データは外部に保存されていてもよい。

図４は、コンテンツデータ部２０２のデータ構成を図示したものであり、Ａはコンテンツコンテナ部２０２の構成、Ｂはコンテンツコンテナの構成、Ｃはコンテンツの構成を示す。コンテンツデータ部２０２は、複数の例えばコンテンツコンテナ２１１，２１２…を保存、管理している。さらに、ひとつのコンテンツコンテナ２１１の内部は、アクセス定義データ２２１と、複数のコンテンツ２３１，２３２…からなるコンテンツリスト２２２で構成される。なお、コンテンツコンテナは、新規作成時にはコンテンツを含まない場合もある。

また、コンテンツ２３１は、メディアデータ２４１とメタデータ２５１から構成され、メディアデータ２４１はマルチメディアデータが格納され、メタデータ２５１にはメディアデータに関する情報が格納される。本実施例の場合、画像も、コメントも、１つのコンテンツとしてここに格納される。

図５は、図２に対するコンテンツコンテナの具体的なデータの格納構造を示すものであり、コンテナのタイトルを表すコンテナメタデータ２１０、アクセス定義データ２２１、コンテンツリスト２２２を格納する。

図５に示されるように、アクセス定義データ２２１には、各ユーザ毎の投稿及び閲覧許可情報（アクセス権）が登録されている。本実施例においては、ＩＤがＵ００１は山田、Ｕ００２は佐藤、Ｕ００３は加藤、Ｕ００４は佐々木、Ｕ００５は木村、Ｕ００６は飯島としている。なお、アクセス権の設定については、投稿許可、閲覧許可を個別に設定することもできる。

また、例えば、コンテンツリスト２２２内の画像コンテンツ２３１には、メディアデータ２４１に画像データが格納され、メタデータ２５１には、投稿者ＩＤ（ＩＤentification）、タイトル、子コンテンツＩＤ（０個以上）が格納される。一方、画像コンテンツ２３１の投稿コメントであるコメントコンテンツ２３２には、メディアデータ２４２にコメント文が格納され、メタデータ２５２には、投稿者ＩＤ、親コンテンツＩＤが格納される。なお、２１１ａはコンテンツコンテナを識別するためのコンテンツコンテナＩＤ、２３１ａはコンテンツを識別するためのコンテンツＩＤである。

具体的な投稿作業について、一例として図２に示した画像データ１３を投稿するときの流れを解説する。ユーザ（山田）が投稿を行う際、まず、図２の画像投稿ボタン１２を選択し、画像とタイトルを指定する。この結果、図３において、クライアント１００はコンテンツ管理部２００の制御部２０１に対して、画像投稿コマンドを送信する。画像投稿コマンドの内容は、投稿対象コンテンツコンテナＩＤ、投稿者ＩＤ、タイトル、画像データから構成される。

画像投稿コマンドを受信した制御部２０１は、図６に示すフローチャートに従って、投稿コマンド処理を実行する。まず、制御部２０１は投稿先のコンテンツコンテナをコンテンツデータ部２０２から検索する（ステップＳ１）。指定のコンテンツコンテナが有るかどうかを判断し（ステップＳ２）、指定のコンテナが見つかった場合、その内部のアクセス定義データ２２１を確認してアクセス許可判定を行う（ステップＳ３）。制御部２０１は、アクセス定義データ２２１を参照し、投稿者である山田（ＩＤ Ｕ００１）が、投稿を許可されていること（アクセス権）を確認し（ステップＳ４）、投稿コンテンツを作成し、データを格納し、コンテンツＩＤ(Ｃ００１)を生成してコンテンツリスト２２２に格納する（ステップＳ５）。コンテンツリスト２２２への格納処理が終了したら、投稿コマンド処理が終了した旨を画面に表示し（ステップＳ６）、投稿コマンド処理を終了する。

上述判断ステップＳ２及びステップＳ４において、投稿先コンテナが無い場合、又はユーザがアクセス権を持たない場合、それぞれエラーである旨のメッセージを表示し（ステップＳ７）、投稿コマンド処理を終了する。

なお、図５では、コンテンツ２３１のメタデータ２５１に子コンテンツが２つ格納された表現となっているが、この段階では、コンテンツ２３１に子コンテンツはないので、この項目は存在しない。

次に、ユーザがコンテンツコンテナの内容を閲覧する場合の処理について、図２、図３、図７を用いて説明する。ユーザが、クライアント１００（図３参照）に対し入力操作を行いこのコンテンツコンテナ２１１を閲覧することを指示すると、クライアント１００は、制御部２０１に対して、閲覧コマンドを送信する。このときの閲覧コマンドの中身は、閲覧対象コンテンツコンテナＩＤ、要求者のユーザＩＤである。

制御部２０１は、閲覧コマンドを受信すると、図７に示すフローチャートに従って、閲覧コマンド処理を実行する。まず、制御部２０１は閲覧対象となるコンテンツコンテナを検索し（ステップＳ１１）、閲覧対象のコンテンツコンテナが有るかどうかを判断する（ステップＳ１２）。閲覧対象コンテンツコンテナが見つかった場合、投稿時と同様に、その内部のアクセス定義データ２２１を確認してアクセス許可判定を行う（ステップＳ１３）。制御部２０１は、アクセス定義データ２２１を参照し、要求者が閲覧を許可されていること（アクセス権）を確認し（ステップＳ１４）、要求者が閲覧を許可（閲覧ＯＫ）されていれば、表示構成部３００に画面構成用コンテンツデータを送信して（ステップＳ１５）、閲覧コマンド処理を終了する。

上述判断ステップＳ１２及びステップＳ１４において、閲覧先コンテナが無い場合、又はユーザがアクセス権を持たない場合、それぞれエラーである旨のメッセージを表示し（ステップＳ１６）、閲覧コマンド処理を終了する。

表示構成部３００では、コンテンツデータを解析し、画面構成データを作成する。表示構成部３００は、コンテンツデータから、タイトル、投稿コンテンツ、コメントコンテンツを抽出し、図２に示されるように配置する。また、１つの画像投稿ボタンと、投稿(画像データ)ごとのコメントボタン１５をレイアウトする。画面構成データは、例えばＨＴＭＬなどを利用して構成する。

次に、ユーザが閲覧したコンテンツに対してコメントを行う場合について、図２、図３、図８を用いて説明する。図２において、画像データ表示１３に対してユーザ（佐藤）がコメントをする場合について述べる。ユーザ（佐藤）がコメントボタン１５を選択すると、クライアント１００（図３参照）から、制御部２０１に対して、コメント投稿コマンドが発行される。コメント投稿コマンドの内容は、要求者ＩＤ、コンテンツコンテナＩＤ、コンテンツＩＤ、コメントテキスト、となっている。

制御部２０１は、コメント投稿コマンドを受信すると、図８に示すフローチャートに従って、コメント投稿処理を実行する。まず、制御部２０１は、投稿時と同様に、コメント先コンテナの検索（ステップＳ２１）を行い、コメント先コンテナが有るかどうかを判断する（ステップＳ２２）。コメント先コンテナが見つかった場合、投稿時と同様に、その内部のアクセス定義データ２２１を確認してアクセス許可判定を行う（ステップＳ２３）。制御部２０１は、アクセス定義データ２２１を参照し、要求者が閲覧を許可されていること（アクセス権）を確認し（ステップＳ２４）、要求者が閲覧を許可（閲覧ＯＫ）されていれば、次に、コメント先となる、画像コンテンツを検索し（ステップＳ２５）、コンテンツを格納する（ステップＳ２６）。そして、コマンド実行処理が終了した旨のメッセージを表示し（ステップＳ２７）、処理を終了する。

コンテンツ格納のステップＳ２６では、図５に示すように、コメントをコンテンツとして格納する。その際に、例えばコメントコンテンツ２３２のメタデータ２５２の親コンテンツの項目に、画像コンテンツのコンテンツＩＤ（Ｃ００１）を格納し、かつ、コメント先となるコンテンツ２３１のメタデータ２５１の子コンテンツの項目に、格納されたコメントコンテンツのＩＤ（Ｃ００２）を格納する。閲覧時において、表示構成部３００が画像コンテンツのメタデータを解析し、子コンテンツを、その画像のコメントとして抽出していて、画面構成データを作成する。

なお、上述判断ステップＳ２２及びステップＳ２４において、コメント先コンテナが無い場合、又はユーザがアクセス権を持たない場合、それぞれエラーである旨のメッセージを表示し（ステップＳ２８）、コメントコマンド処理を終了する。

以上が、コンテンツ共有システムの基本的な説明である。本例では、各ユーザに対応してコンテンツデータの重要度を算出し、重要度に応じて表示データを選定する表示内容決定部を設ける。以下の実施の形態の例では、この重要度判定部において、どのようにコンテンツの重要度を決定し、クライアントに対して表示するコンテンツをどのように選定するかについて述べる。

図９は、本発明の一実施の形態の例のシステム構成を示す図である。この図９においては、図１と比較して、重要度判定部２１０、キーワード抽出部２２０、表示内容決定部２３０、ユーザ情報管理部２４０、ユーザ設定情報管理部２６０、履歴情報管理部２５０を追設している。

図９に示される、重要度判定部２１０は、後述するユーザ環境情報やユーザ設定情報などを用いてコンテンツの重要度を判定する。重要度判定部２１０は、各機能を制御する制御部２１４と各種判定部２１０ａ，２１０ｂ，２１０ｃによって構成される。さらに、各判定部は必要に応じて、特定の文字列を抽出するキーワード抽出部２２０を用いて、取得したデータからキーワードを抽出する。その他、重要度判定部２１０の詳しい動作などは後述する。

また表示内容決定部２３０は、コンテンツ管理部２００からコンテンツデータを取得し、重要度判定部２１０にデータを送信、得られた各コンテンツの重要度を用いて、クライアント１００（１０１）にどのコンテンツデータを表示させるのかを決定する。

またユーザ情報管理部２４０は、履歴情報保存部２５１に保存されるユーザによる投稿履歴情報及び閲覧履歴情報や、ユーザ設定情報保存部２６１に保存されるユーザ設定情報などのユーザに関する各種情報を扱い、投稿履歴情報や閲覧履歴情報に関するデータは履歴情報管理部２５０と、ユーザ設定情報に関するデータはユーザ設定情報管理部２６０とやり取りを行う。

履歴情報管理部２５０は、履歴情報保存部２５１への投稿履歴情報や閲覧履歴情報といった履歴情報の登録、取得、削除、変更等の操作を行うことができる。履歴情報の詳細については後述する。

ユーザ設定情報管理部２６０は、ユーザ設定情報部２５１へのユーザ設定情報の登録、取得、削除、変更等の操作を行うことができる。ユーザ設定情報の詳細については後述する。

以下に述べる本発明の実施の形態の例において説明するクライアント以外のブロックは、基本的にすべてサーバで動作するが、各ブロックがネットワーク上に分散していたり、クライアントを操作するユーザに依存する情報や、一部の機能が、クライアントに含まれていてもよい。また、各ブロックは、異なるサーバ上で動作するネットワーク上のサービスでもよいし、同一サーバで動作する異なるプログラムでもよいし、同一プログラム内のライブラリでもよい。

クライアント、サーバ、いずれもコンピュータ上のプログラムとして動作し、データはそれらの図示しない不揮発性の記録媒体に記録される。

図１に示された重要度判定部２１０でのコンテンツコンテンツデータの重要度の指標として、コミュニケーション履歴を用いた重要度判定手法について例を挙げる。つまり、重要度判定部２１０において、過去のユーザ間のコミュニケーション履歴を用いてユーザに対する各コンテンツの重要度を算出する。ここでは、コミュニケーション履歴として、ユーザによるコンテンツの投稿履歴情報と閲覧履歴情報を用いる。勿論、それ以外の履歴情報、例えばメールやインスタントメッセンジャー、電話等を用いても構わない。

以下に投稿履歴情報及び閲覧履歴情報を用いた具体的な例を示しながらコミュニケーション履歴に基づく重要度判定部２１０の処理を説明する。

まず、図１に示すコンテンツ共有システムにコンテンツが投稿されると、その投稿情報がコンテンツ管理部２００からユーザ情報管理部２４０を通して履歴情報管理部２５０に登録する。投稿履歴情報保存部２５１には投稿者のユーザＩＤ、投稿したコンテンツのコンテンツＩＤ、また、その投稿が別の投稿に対する返信である場合その返信先のコンテンツＩＤ、投稿した日時などの情報が蓄積される。

ここでいうユーザＩＤとは、ユーザに対して一意に定められる文字列であり、本システムが割り振る。また、コンテンツＩＤとは、投稿されたコンテンツデータに一意に定められた文字列であり、新規投稿時に本システムが割り振る。

投稿履歴情報の具体例を図１０に示す。ユーザＩＤ、コンテンツＩＤ及び返信先のコンテンツＩＤ、投稿日時が存在する。図１０はあくまでも一例であり、例えば投稿場所などの他の情報が含まれるようにしてもよい。

また、ユーザがあるコンテンツの閲覧を求めた場合、その閲覧情報が表示構成部３００からユーザ情報管理部２４０を通して履歴情報管理部２５０に登録される。閲覧履歴情報には閲覧者のユーザＩＤ、閲覧したコンテンツのコンテンツＩＤ、閲覧した時刻などが蓄積される。

閲覧履歴情報の具体例を図１１に示す。こちらは、ユーザＩＤ、閲覧したコンテンツのＩＤ、閲覧した日時が存在する。投稿履歴情報の例と同様に図１１はあくまでも一例であり、例えば閲覧場所などの他の情報も含まれていてもよい。

本実施例で用いている投稿履歴及び閲覧履歴は、上記のように本システムの利用履歴でも良いし、例えば電子メール、インスタントメッセンジャー（チャット）のような外部アプリケーションを用いて本システムのコンテンツを利用した履歴でもよい。

コミュニケーション履歴による重要度判定処理では、過去に蓄積された投稿履歴情報や閲覧履歴情報に基づいて各コンテンツの重要度を算出する。重要度の算出方法は、いかなる方法でもよく、例えば閲覧しようとしたユーザに対しては、コンテンツに登録されているメタデータの中で同じユーザＩＤが含まれるコンテンツの重要度を高くなるように計算するなどが考えられる。具体的な重要度の算出に関する詳細は後述する。

ユーザに対するコンテンツの重要度を算出することによって、例えば重要度の高い（もしくは低い）順に扱うことにより、ユーザにとってさまざまな用途にコンテンツを活用できるようになる。

その一例として、本システムに対しあるコンテンツが新規投稿された際にユーザに対して通知が行われるようなサービスを考える。このようなサービスでは、ユーザにとって興味があるコンテンツの新規投稿はすぐにでも知らせてほしいと思うが、あまり重要でないコンテンツの新規投稿が通知されるのが煩わしいと思うことが多々ある。しかし、重要度に応じて通知方法を変更することができれば、ユーザにとってはメリットとなる。以下に過去の履歴に基づいて通知方法を変更する手順を、図１２に示すフローチャートを参照しながら説明する。

まず、あるユーザが新たなコンテンツを、図９に示すコンテンツ共有システムに投稿する。投稿されたコンテンツはコンテンツ管理部２００に蓄積される（ステップＳ１２０１）。

コンテンツ管理部２００は、新たなコンテンツが投稿されたことをコンテンツデータとともに表示内容決定部２３０に送信する（Ｓ１２０２）。表示内容決定部２３０は、通知対象のユーザごとにあっても良いし、ひとつの表示内容決定部がすべての対象となるユーザに対する処理を行っても良い。

表示内容決定部２３０は、通知対象ユーザのユーザＩＤと新規投稿されたコンテンツをパラメータとして重要度判定部２１０へ重要度を問い合わせる（ステップＳ１２０３）。

重要度判定部２１０は、通知対象ユーザのユーザＩＤを用いて、履歴情報管理部２５０から過去の投稿履歴情報、閲覧履歴情報を取得し、新規投稿コンテンツの重要度を算出する（ステップＳ１２０４）。具体的な重要度の算出方法としては、例えば、該当コンテンツの投稿者が過去に投稿したコンテンツのうちの何％を、通知対象ユーザが閲覧したか算出し、それを重要度とする方法がある。また、該当コンテンツの投稿者が過去に投稿したコンテンツのうち全コンテンツの何％対して通知するユーザが返信したかを算出し、それを重要度とする方法も考えられる。もちろん、閲覧確率や返信確率だけでなく、その他、例えば投稿履歴情報や閲覧履歴情報を用いた算出方法でも構わないし、それらの組み合わせを用いても構わない。

なお、重要度判定部２１０は、上記のような重要である理由の異なる判定部を複数内部に持っており、その中から最適な判定結果を判定した理由とともに返してもよい。つまり、重要度の算出のために用いた情報が、１つもしくは複数であってもよい。さらに、重要度判定部２１０において、複数の情報から得られた重要度情報から最適なものを選択して、その選択した重要度情報をそのコンテンツの重要度として用いるというように、選択式にすることもできる。そして、どのような情報からそのコンテンツが重要だと判定されたかという、重要度算出に用いられた情報を、理由としてユーザへ通知するようにすることも考えられる。

表示内容決定部２３０は重要度判定部２１０から得た重要度に応じて通知方法を選択する（ステップＳ２１０５）。例えば重要度が高いコンテンツの場合は、コンテンツが画像データであれば画像のサムネイル表示とともに音声を伴った通知を行い（Ｓ１２０６）、重要度の低いコンテンツの場合は、単に新規コンテンツの存在を簡易な表示のみで知らせる（Ｓ１２０７）などである。通知方法はこの限りではない。

このように、コミュニケーション履歴を用いてコンテンツの重要度を決定し、それに基づいてユーザへ提示するコンテンツを選択することによって、上記の例では、コンテンツの新規投稿に対する通知方法として用いることができることを示した。

その他、コミュニケーション履歴を用いた重要度の判定によって、例えばユーザ間の「仲のよさ」や「共通の興味」といったことを知ることが可能になるなど、ユーザ間のコミュニケーション促進にも役立たせることが可能となる。

次に、ユーザ自身による設定情報を用いて重要度を判定してユーザに提示する場合について述べる。

本システムの重要度判定部２１０では、使用しているユーザ同士の関係をユーザの設定情報から抽出し、設定情報に基づいて重要度を判定することもできる。その結果、例えば、コミュニケーション中のユーザ同士のお互いの設定情報に類似するコンテンツデータを両方に提示することでコミュニケーションの活性化を促すことができる。以下、具体的な例を挙げながらユーザの設定情報を用いた重要度判定部２１０の処理を説明する。

まず、ユーザ設定情報の登録について説明する。各ユーザは自分に関する情報をユーザ設定情報として登録しなければならない。登録されているユーザ設定情報の例を図１３に示す。この図１３に示すようにユーザ設定情報は大きく、（Ａ）プロフィール情報、（Ｂ）グループ情報、（Ｃ）嗜好情報に分類される。

プロフィール情報（図１３Ａ参照）には、ユーザＩＤ、名前、性別、年齢などが蓄積される。ここでユーザＩＤはユーザ設定情報管理部２６０が管理をしやすくするためのもので、各ユーザに対しユニークな数字や文字列で定義される。

グループ情報（図１３Ｂ参照）には、グループＩＤ、グループ名、グループに属するユーザのユーザＩＤリストなどが蓄積される。ここでグループとは「テニスが好きな友達の集まり」や「スキー好きの同僚」などといった複数のユーザをまとめるための概念であり、ユーザ設定情報として管理される。これらはユーザが明示的に登録してもいいし、自分のコンテンツの閲覧(共有)を許可したユーザをグループとして登録してもよい。さらにメールソフトなどのアドレス帳から自動的に登録してもよい。また、各ユーザはグループに属さなくてもいいし、複数のグループに属してもよい。

嗜好情報（図１３Ｃ参照）には、ユーザＩＤ、対象、興味度などが蓄積される。対象とはユーザが興味を持っているものであり、他のユーザやグループ、キーワードなどである。興味度は興味の強さを定義するもので例えば0〜100などの数値で表される。また、各ユーザは嗜好情報を持たなくてもいいし、複数の嗜好情報を持っても良い。

これらユーザ設定情報は、例えばコンテンツ共有サービスに加入したときにアンケートを実施することで取得することができる。あるいは他サービスですでに登録されているユーザ情報を利用してユーザ設定情報を登録してもよい。また、一度設定したユーザ設定情報をそのときの状況に合わせてユーザが編集してもよいし、嗜好情報などはユーザがシステムを使う度にシステムが学習して修正されてもよい。

次に、類似した嗜好を持つユーザの抽出について説明する。予め登録されたユーザ設定情報を利用することで、例えば似たような嗜好を持つユーザを抽出し、そのユーザの持つコンテンツ情報を閲覧することができる。以下、類似した嗜好を持つユーザのコンテンツを表示する処理を、図１４に示すフローチャートを参照して説明する。

まず、誰の嗜好と類似したユーザを検索するか重要度判定部２１０に入力する。ユーザ本人の場合にはユーザ設定情報管理部２６０からユーザＩＤを取得する（ステップＳ１４０１）。他のユーザの場合には、ユーザの選択(もしくは入力)したユーザ名を用いてユーザ設定情報管理部２６０からユーザＩＤを取得する。

次いで重要度判定部２１０は、上記ステップＳ１４０１で取得されたユーザＩＤを用いてユーザ設定情報管理部２６０からユーザの嗜好情報を取得する（ステップＳ１４０２）。

続いて重要度判定部２１０は、上記ステップＳ１４０２で取得されたユーザの嗜好情報に対し、ユーザ設定情報管理部２６０で管理されている他のユーザの嗜好情報と参照し類似度を計算する（ステップＳ１４０３）。ここでいう類似度とは、コンテンツの重要度と等しい。以下、情報の類似度はコンテンツの重要度として扱う。類似度の計算は嗜好の対象と興味度から計算することができる。例えば、ユーザ設定情報管理部２６０に蓄積されている嗜好情報において、全ユーザの対象がｘ種類ある場合、各対象の興味度を要素とするｘ次元の配列を作成し、対象ユーザの配列との余弦を類似度とすることができる。

上記ステップＳ１４０３で計算された類似度に基づき、類似度の高いユーザを選択する（ステップＳ１４０４）。ユーザは複数選択されてもよいし、類似度に基づき候補をユーザに提示し、ユーザからの入力に従って選択してもよい。本実施例では、類似度の高いユーザを選択する方が重要度が高いと判定するが、対象によっては類似度の低いユーザを選択してもよい。

上記ステップＳ１４０４で選択されたユーザ情報を表示内容決定部２３０に渡すことで、表示内容決定部２３０はコンテンツ管理部３００から指定されたユーザのコンテンツを取得する（ステップＳ１４０５）。もしくは重要度判定部２１０が直接コンテンツ管理部から指定されたユーザのコンテンツを取得し、表示内容決定部にコンテンツを渡す構造にしてもよい。

表示内容決定部２３０により上記ステップＳ１３０５にて取得されたユーザのコンテンツは、表示構成部３００において適切な表示構成データが生成され、クライアントに送信される（ステップＳ１４０６）。これにより、ユーザは自分の嗜好と類似しているユーザが何をコンテンツとして蓄積しているのかがわかる。例えば、音楽の趣味が同じユーザが蓄積しているコンテンツを見て、他にどんな音楽を聴いているのかわかったり、旅行好きな他のユーザが蓄積した旅行の写真を見て、最近どこへ行ったのか知ることができる。

図１５は、類似した嗜好を持つユーザのコンテンツの表示例（その１）を示す図である。図１５では旅行好きなユーザとして「Taro」が検索され、「Taro」のコンテンツを表示している。また、「Taro」のコンテンツと同時にどんな嗜好がどの程度類似していたのか、嗜好の対象(この場合、旅行)と類似度(この場合、８９)を同時に表示してもよい。ユーザは「Taro」のコンテンツを見ることで、最近旅行に行ったことや、旅行以外に他に何に関心があるのかわかる。例えば、図14では旅行先の写真と同時にゴルフやサッカー、釣りの写真もあり、「Taro」は旅行以外にスポーツにも関心があることがわかる。

また、表示するコンテンツを嗜好の類似しているコンテンツに限定して表示してもよい。例えば、ユーザが「旅行」という嗜好を持つ場合、類似した嗜好を持つユーザのコンテンツの中で「旅行」以外に関するコンテンツは嗜好が同じでないため、興味がないと判断し、表示するコンテンツから削除する。図１６にその表示例（その２）を示す。このように図１５に示された「Taro」のコンテンツから「旅行」に関するコンテンツのみを表示し、それ以外のサッカー、釣り、ゴルフなどに関するコンテンツを削除して表示する。このとき、表示するかしないかの判断は、類似度の適当な閾値を決めて判断すればよい。

どのコンテンツがユーザの嗜好に一致しているかは、各コンテンツの持つメタデータから判断することができる。メタデータは、ユーザがコンテンツを蓄積するときにコンテンツの種類(例えば、「旅行」「音楽」「食事」・・・)を指定することで、付け加えることができる。もしくは画像を撮影した場所や時間など、ＧＰＳ（Global Positioning System）や時計を使うことでシステムが自動的に付加してもよい。さらに画像認識技術を用いて、何が写っているか(人、モノ、風景、・・・)、どんな感じの画像か(暖かい、冷たい、躍動感のある、・・・)といった情報をメタデータとして付加してもよい。

また、コンテンツを保有するユーザ自身が他のユーザへ見てもらいたいという意志をメタデータとして付加することもできる。例えば、他のユーザに見てもらいたいコンテンツを保有するとき、そのコンテンツにメタデータとして「おすすめ度」を設定する。他のユーザはメタデータとしての「おすすめ度」をチェックし、「おすすめ度」が高いもの程、優先的に表示される。「おすすめ度」はユーザが対象コンテンツを登録する際に手動で設定してもよいし、何らかの手段によって自動的に付加されてもよく、いかなる方法でもかまわない。

あるいは、ユーザがコンテンツを蓄積する際にコンテンツに対しタイトルやコメントなどを付け加えている場合、キーワード抽出部２２０によりタイトルやコメントからキーワードを抽出しユーザの嗜好に一致しているか判断してもよい。また抽出するのはテキストデータであるキーワードだけではなく、画像データを抽出して画像のマッチングなどを行って例えば好みの色などの嗜好の類似度を判定してもよいし、音声データを抽出して音声信号処理によるマッチングなどを行い、例えば好みの曲調などの嗜好の類似度を判定してもよい。本例では、テキストデータを用いた類似度のみを判定材料とする。

ユーザ設定情報管理部２６０で管理されている嗜好情報はユーザのコンテンツ情報から設定されてもよい。つまり、「旅行」に関するコンテンツを蓄積するユーザは「旅行」に興味があると判断し、「旅行」の興味度を高く設定されるようにする。これにより、ユーザがサービスに加入した時点での嗜好情報だけでなく、今現在の嗜好情報を維持することが可能である。

次に、本例のシステムを利用することでユーザの人脈関係を抽出する方法について説明する。例えば、あるグループに属するユーザの人脈関係を抽出することで、そのグループがどういうつながりで形成されているのか、現状の関係はどうなっているのかがわかる。つまり、人と人との関係を重要度として判定する。以下、グループ内の人脈関係を表示する処理を、図１７に示すフローチャートを参照して説明する。

まず、ユーザがどのグループの人脈関係を抽出するか選択する（ステップＳ１７０１）。グループ名で指定された場合にはユーザ設定情報管理部２６０からグループＩＤを取得する。指定方法は、予めユーザ設定情報管理部２６０に登録されているグループから選択するようにしてもよいし、手動で入力するようにしてもよい。また、例えばユーザが新たにグループに加入したときにはグループ内の人脈関係をユーザに提示するようにしてもよい。

次に上記ステップＳ１７０１にて入力されたグループＩＤに基づき、ユーザ設定情報管理部２６０で管理されているグループ情報からグループに属する全ユーザのユーザＩＤを取得する（ステップＳ１７０２）。

続いて上記ステップＳ１７０２にて取得した各ユーザＩＤに対し、ユーザ設定情報管理部２６０で管理されているプロフィール及び嗜好情報を取得する（ステップＳ１７０３）。この学歴や職歴などのプロフィールは客観的な人脈関係を抽出するために利用することができる。つまり、プロフィールから大学の先輩後輩や会社の同期といった客観的な情報を抽出することによって、グループ内の人脈関係を理解できる。

図１８は、プロフィール情報だけを利用して人脈関係を表現した例を示す図である。このようにユーザＡ、ユーザＢ、ユーザＣは同じＡ大学出身であり、ユーザＢとユーザＤは同じＡ会社に勤務、ユーザＤとユーザＥはＢ大学で一緒であり、ユーザＥとユーザＦは同じＢ会社に勤務していることがわかり、プロフィール情報を利用することは人脈関係を把握するために役立つことがわかる。

また、プロフィール情報の代わりに嗜好情報を用いれば、誰と誰の仲が良く誰と誰の仲が悪いとか、誰と誰の嗜好が似ているという主観的な人脈関係を把握するために利用できる。

そして、上述のステップＳ１７０３の処理にて取得されたプロフィール及び嗜好情報を利用してユーザ間の関係を抽出する（ステップＳ１７０４）。例えば、プロフィール情報として図１３Ａに示した情報とは別に、ユーザ設定情報管理部２６０には図１９に示すような所属情報が管理されている。

図１９において、所属情報とは住所や学歴、職歴など今までに属していた団体、地域に関するプロフィールである。所属情報には、ユーザＩＤ、情報ＩＤ、タイプ、階層的データ、開始日、終了日などが含まれる。ユーザＩＤは図１３のプロフィール情報と同じでユーザを特定するためのＩＤである。情報ＩＤは各ユーザが所有している所属情報を管理しやすくするためのＩＤである。タイプは所属情報のタイプを表し、「住所」「学歴」「職歴」「趣味」などがある。階層的データ(データ１〜データ４)は所属情報をより詳細に管理するためのデータ構造であり、下位に行くほど詳細な所属情報となる。一般に住所や学歴、職歴などの所属情報は階層構造を取ることが多いが、階層構造ではない所属情報においても一階層のデータ(図１９の場合データ１だけ)として管理することができる。具体的な所属情報からユーザの関係を抽出する処理については後述する。

また、図１３Ｃに示した嗜好情報の興味度を用いてユーザ間の関係を抽出することもできる。つまり、誰が誰に対し興味を持っているか、誰と誰が同じような興味を持っているかという視点で人脈関係を抽出してもよい。もしくはユーザのプロフィール情報及び嗜好情報の両方を用いてユーザ関係を抽出してもよい。

上述のステップＳ１６０４にて抽出されたユーザ関係は、表示内容決定部２３０を経て表示構成部３００において適切な表示構成データに加工される（ステップＳ１７０５）。表示は図１８に示されるようなグラフィカルな表示でもいいし、テキストデータで誰と誰がどのような関係であるか表示してもよい。

ここで、上述のグループ内の人脈関係の表示処理フローチャートのステップＳ１７０４（図１７参照）における、ユーザ間の関係を抽出する処理、特にユーザ設定情報管理部２６０に蓄積された所属情報から関係を導き出す処理について、図２９に示すフローチャートを参照して説明する。本例ではユーザＡとユーザＢと２人の関係を抽出するが、３人以上のユーザ間の関係についても同様に抽出できる。また、ここではユーザ間の関係をユーザ間の類似度として定量的に算出するものとする。

まず、ユーザＡとユーザＢの２人のユーザの所属情報をそれぞれユーザ設定情報管理部から取得する（ステップＳ２００１）。

次に２人のユーザの類似度を初期化する（ステップＳ２００２）。例えば類似度を０とする。

続いて取得した所属情報が同じタイプに属するか判定する（ステップＳ２００３）。同じタイプであるならステップＳ２００４へ進み、同じタイプでないなら処理は終了となる。

さらに現在参照している２人のデータに対し、下位データが存在するか判定する（ステップＳ２００４）。初期の場合は参照データがないため、上位データがあるか判定する。例えば、図１９のＵ０２３(ユーザＩＤ)、１０(情報ＩＤ)のデータでは、データ１の「Ａ大学」が上位データとなり、「Ａ大学」に対し「Ａテニスクラブ」が下位データとなる。また、データ３以降はデータが存在しないため、「Ａテニスクラブ」の下位データは存在しない。下位データが存在しなければ処理は終了となる。

上記ステップＳ２００４にて判定された２人の下位データを取得し（ステップＳ２００５）、２人の下位データの類似度を計算する（ステップＳ２００６）。類似度は０か１の離散的な値でもいいし、アナログ的な値でもいい。例えば、「Ａ大学」と「Ａ大学」の類似度は１、「Ａ大学」と「Ｂ大学」の類似度は０というように、一致するかしないかで評価する。あるいは「Ａ大学」と「Ａ短期大学」は同じ系列だが異なる大学である場合、類似度を０．５としてもよい。また、データが地理情報の場合、地理的な距離を類似度としてもよい。

そして、２人の類似度に上記ステップＳ２００６にて計算された類似度を加算する（ステップＳ２００７）。このとき、下位のデータほど加算の割合を高くする。例えば、２人の類似度をsum、ステップＳ２００６で算出された類似度をvalue、ステップＳ２００６で計算した階層のレベルをlevel、下位レベルの優位度をratioとすると、下記のように２人の類似度を更新することができる。

sum = sum + level * ratio * value

例えば、ratio ＝１０、上位から１番目及び２番目の階層の類似度が１で同じである場合、１番目の階層の類似度は１０加算され、２番目の階層の類似度は２０加算される。これにより、下位のデータが類似している程、つまり詳細な所属情報が一致するほど類似度が高く評価される。

最後にステップＳ２００６で計算された２人のデータが同じか判定する（ステップＳ２００８）。同じ場合にはさらに下位データの類似度を計算するため、ステップＳ２００４へ進む。異なる場合には処理は終了となる。

図２０に示されるフローチャートでは、２つの所属情報の類似度の計算について説明したが、この処理を２人のユーザが持つすべての所属情報の組み合わせについて行う。最終的に算出される類似度はこれら組み合わせの中で最も類似度が高かった値でもいいし、すべての類似度を加算した値でもよい。

また、類似度（コンテンツの重要度）の計算方法は上記の方法だけにとどまらず、いかなる方法によってもかまわない。また、コンテンツの選択方法も類似度が高いコンテンツを選択するというものではなく、類似度が小さいコンテンツを選択した方がユーザによってよい効果が得られる場合もある。例えば、地理情報の距離を類似度として扱った場合は、距離が短いすなわち類似度が小さいコンテンツの方が一般に利用価値が高いことが多い。

次に、コミュニケーションを行っているユーザの置かれている環境の情報を用いてユーザに対するコンテンツの重要度を判定する方法について述べる。例えばコミュニケーションを行っている相手ユーザの情報を用いて、相手ユーザの興味のあるコンテンツなどが重要度を高くしユーザに提示することにより、コミュニケーションをより活性化させる。以下、ユーザの環境情報を用いた重要度判定部２１０の処理について具体的な例を挙げて説明する。

ユーザ環境情報を用いた重要度の判定を行い、重要度の高いコンテンツをユーザに提示する方法について、図２１に示すフローチャートに沿って説明する。

まず、重要度判定部２１０は、本システムを使用しているユーザの環境情報を取得する（ステップＳ２１０１）。ユーザ環境情報の具体的な内容は後述する。ユーザ環境情報の取得方法は、いかなる方法でもよく、取得対象の環境情報の種類に依存する。例えばクライアント１００から何らかの通信手段を用いて取得してもよいし、ユーザが同時に使用している他のアプリケーションなどから取得してもよい。

次に重要度判定部２１０は、表示内容決定部２３０を通して、コンテンツ管理部３００の管理しているデータベース（コンテンツ保存部２０２）からコンテンツを取得する（ステップＳ２１０２）。このとき、コンテンツ取得のキー情報として、ステップＳ２１０１で取得したユーザの環境情報を用い、キー情報と同じタイプのメタデータが登録されているコンテンツを取得する。但しコンテンツに付加されているメタデータは必ずしも重要度の判定の対象とするデータが含まれているとは限らない。さらに、コンテンツ取得の条件として、例えばユーザが以前投稿したコンテンツのみを対象にするなどといった絞込みを行っても構わない。

また、本実施例では、重要度判定部２１０は表示内容決定部２３０を通してコンテンツデータを受け取っているが、コンテンツデータを直接コンテンツ管理部３００から取得するような構成にしてもよい。

続いて上記ステップＳ２１０２で取得したコンテンツ情報及びコンテンツ情報が持つメタデータと、ステップＳ２１０１で取得したユーザ環境情報を用いて、類似度を計算する（ステップＳ２１０３）。類似度の計算方法は後述する。

また表示内容決定部２３０において、上記ステップＳ２１０３にて求められた類似度からコンテンツの重要度を判定して選択する（ステップＳ２１０４）。つまり、本実施例における重要度とは、コンテンツが持つ環境情報に関するメタデータと、入力されたユーザの環境情報との類似度を意味する。また、類似度が高い（つまり似ている）ほど重要度が高いという判定方法もあれば、類似度が低い（つまりまったく似ていない）ほど重要度が高いという判定方法も可能である。

そして上記ステップＳ２１０４において表示内容決定部２３０で選択されたコンテンツデータは、表示構成部３００にて適切なレイアウトに配置されクライアントに表示される（ステップＳ２１０５）。

以上の手順により、ユーザの環境情報をもとに各コンテンツの重要度を判定し、ユーザにとって有益と思われるコンテンツを提示することができるようになる。

次に、ユーザの環境情報にはどんなものがあるか具体的に例を挙げて述べる。

例えば、ユーザの環境情報としてユーザの現在位置情報を用いることができる。この場合の重要度判定処理について、図２１に示したフローチャートに沿って説明する。

まず、ステップＳ２１０１において、ＧＰＳなどの位置情報取得装置を用いることで、ユーザの現在の位置情報を取得する。また、位置情報の取得方法はいかなる方法でもよく、例えばユーザが何らかの方法で位置情報を調べ、手動で入力してもよい。

上記ステップＳ２１０２において、位置情報をキーとしてコンテンツ管理部２００が持つコンテンツデータベース２０２から、位置情報をメタデータとして持つコンテンツを取得する。

次にステップＳ２１０３では、取得されたコンテンツの位置情報と、ステップＳ２１０１で取得された位置情報との類似度を計算する。この例では、ユーザの現在位置とコンテンツ情報の位置情報の距離を類似度とする。

最後にステップＳ２１０４において、算出した距離を重要度として扱い、距離の近い（もしくは遠い）コンテンツを選択し、ステップＳ２１０５の処理で表示する。もちろん、選択するコンテンツ情報の数は複数であってもかまわない。

位置情報を用いた具体的なデータとしては、例えば図２２、図２３のようになる。図２２は、クライアントから受けるユーザの現在位置情報であり、ユーザＩＤと現在の位置情報が含まれる。図２３は位置情報がメタデータとして付加されたコンテンツデータであり、このようなデータであれば、位置情報を用いた重要度の判定の対象のコンテンツとなりうる。

図２２の位置情報と図２３の各コンテンツの位置情報から距離を計算して、図２４に示すような結果が導かれる。図２４に示すような類似度の計算結果が得られた場合、コンテンツＩＤがＣ００１である画像Ａのコンテンツの重要度が高く判定される。この例では、小さい値の方が重要度を高く判定する例であるが、もちろん距離が離れている方が重要度を高くするという判定方法も可能である。重要度をどのように判定するかは、対象のデータの内容に依存する。

このように位置情報をユーザ環境情報としてコンテンツの重要度を判定する方法を用いた場合は、例えば、ユーザの現在位置に近い位置に存在する施設のコンテンツや、昔その場所で自分や友人などが撮影した写真などを提示するなどが容易にできるようになる。もっと単純な例としては、地図データが蓄積されたコンテンツデータベースから、位置情報に基づいて現在位置付近の地図データを表示するということももちろん可能である。

上述した例のようにユーザの現在の位置情報ではなく、例えば地図アプリケーションなどを用いた際に位置情報を指定するといった、ユーザの実際の位置ではなく指定した位置情報に応じたコンテンツの重要度判定方法ももちろん可能である。つまり、例えばある地図アプリケーションを用いて、表示された地図の位置情報をキー情報として指定し、表示されている範囲内の位置をメタデータとしてもつコンテンツ情報の重要度を高く設定することで、地図の範囲内のコンテンツをユーザに提示する。

このように、ユーザが同時に使用している他のアプリケーションの情報（ここでは地図アプリケーションの位置情報）もユーザ環境情報として扱い、コンテンツの重要度判定のキー情報として用いることができる。

他のアプリケーションとの連携及び位置情報を用いる他の例として、仮想世界の位置情報を用いる方法も挙げられる。例えば、仮想世界を自由に動き回るオンラインゲームを対象として考える。仮想世界中のある位置情報をユーザ環境情報として重要度判定を行うと、例えば、コンテンツデータベース２０２に保存されている、近辺で取得したスクリーンショット画像のコンテンツデータの重要度が高く設定され、オンラインゲーム画面上などに表示するといったこともできる。

他のアプリケーションとの連携では、例えばユーザが他のユーザとあるコミュニケーションツール（例えば、チャットやインスタントメッセンジャーなど）を用いて、コミュニケーションを行っているという情報も、ユーザ環境情報として重要度の判定に使うことができる。つまり、コミュニケーション相手の情報を重要度判定に加味することによって、コミュニケーションをしながら相手ユーザに関連するコンテンツを同時に表示させることなどが可能になり、コミュニケーションがより活性化される効果が期待できる。

以下、図２１に示したフローチャートに沿って、コミュニケーション相手の情報をユーザ環境情報として扱った重要度判定方法を示す。ここでは、１対１のコミュニケーションを対象にしている。

まず、ステップＳ２１０１において、ユーザの環境情報としてユーザがコミュニケーションを行っている相手ユーザの情報を取得する。取得する手段はいかなる方法でもよく、例えばユーザが手動で相手の情報を明示的に入力してもよいし、コミュニケーションを行っているアプリケーションから接続情報を取得してもよい。

次にステップＳ２１０２において、接続相手のユーザ情報をキー情報として、コンテンツを取得する。このとき、例えばユーザＩＤなどのユーザ情報がメタデータとして付加されているコンテンツが対象となる。ユーザＩＤなどの接続相手に関する一意の情報ではなく、前記嗜好情報や前記所属情報のメタデータを用いてコンテンツ情報を取得してもよい。

ステップＳ２１０３では、ステップＳ２１０２で取得したコンテンツ情報と、ステップＳ２１０１で取得した相手のユーザ情報を用いて、類似度を求める。類似度の計算方法は、上述の嗜好情報や所属情報などを用いた場合と同じ方法でも構わない。例えば、接続相手のユーザＩＤが含まれているコンテンツの類似度が高くなるとか、接続相手の嗜好情報が含まれるコンテンツの類似度が高くなるとか、又は自分の嗜好情報と接続相手の嗜好情報の両方が含まれるコンテンツの類似度が高くなるなどさまざまな方法を用いることができる。もちろん、類似度の計算方法はここに挙げた方法にとどまらず、いかなる方法でも構わない。

そして、ステップＳ２１０４において類似度からコンテンツを選択し、ステップＳ２１０５において表示構成データを作成してユーザに提示される。

このような重要度の判定を行うと、例えば、接続相手と一緒に写っている写真データや接続相手からもらったコメント（テキストデータ）といったコンテンツの重要度を高くする判定が可能となり、接続相手との関連の深いコンテンツを優先してユーザに提示するといったことが可能になる。

上記の例では、接続相手ユーザの予め登録されている情報を用いてコンテンツの重要度を求めている。それだけではなく、現在コミュニケーションを行っているデータそのものの中から、キーとなる情報を取得して、重要度判定の材料とすることもできる。

例えば、ユーザがインスタントメッセンジャーやチャットなどのコミュニケーションツールを用いてある相手と接続しコミュニケーションを行っているとすると、キーワード抽出部２２０により、入力されたテキストデータの中からキーワードを抽出し、そのキーワードもしくはキーワードと接続相手のユーザの情報などをキー情報として、コンテンツの重要度の判定に用いることもできる。

ここでキー情報は、キーワードつまりテキストデータを用いているが、画像データや音声データをキー情報として扱ってもよい。つまり、キー情報として画像データが与えられた際には、重要度判定部２１０は、コンテンツデータベース２０２の中から画像データをもつコンテンツを抽出して、画像のマッチングなどを行って類似度を求めることができる。音声データをキー情報とした場合も同様に、音声データをもつコンテンツを抽出して、音声信号処理によって類似度を求めることができる。画像データ及び音声データを用いた場合でも類似度の算出方法は、いかなる方法でも構わない。

以上の方法により、ユーザの置かれている状況、ユーザの接続状況などの情報を用いて、コンテンツデータベースに蓄積されたコンテンツの重要度を決定することにより、ユーザの状況などに合わせたコンテンツの提示が可能になる。

例えば、コンテンツデータベースに多数の写真が投稿されているような場合に、あるグループで行ったイベント（例えば旅行）の写真だけをまとめてアルバムにしたり、プリントしたり、スライドショーなどの見せ方をするなどの応用サービスを容易に行うことができる。

ここまでで提示した実施例では、コンテンツの投稿履歴情報及び閲覧履歴情報、ユーザの設定情報、ユーザの環境情報を用いてコンテンツの重要度を求める方法について述べたが、コンテンツの重要度の判定においては、それらのいくつかもしくはすべてを組み合わせてもよい。

すなわち、例えば図９において、重要度判定部２１０内部の第１判定部２１０ａにおいてはコンテンツの投稿履歴や閲覧履歴を用いて判定し、第２判定部２１０ｂにおいてはユーザの設定情報を用いて判定し、第３判定部２１０ｃにおいてはユーザの環境情報を用いたり、キーワード抽出部２２０を用いてキーワードによって重要度を求めて判定し、それらすべてを加味してコンテンツの重要度として扱うということもできる。

以上述べた本実施の形態の例により、コンテンツ共有システムにおいてユーザの利用履歴や設定情報、環境情報を用いてコンテンツの重要度を決めることによって、テキストデータや各種メディアデータの境界なくユーザの興味、状況、環境等に合わせたコンテンツの提示が容易に実現可能である。

次に、本発明の他の実施の形態の例について説明する。本例は、コンテンツ共有システムにおいて、ユーザが複数のデバイス又はクライアントを使い分けている状況において、ユーザにとって価値のある通知メッセージを、適切にクライアント又は外部ツールへ通知するようにしたものである。

図２５に、本発明の他の実施の形態の例のシステム構成について説明する。図２５は、図１に示したシステムに、通知発行部４００、コンテンツ重要度判定部５００を追設することで実現する。図９に示したシステムに、通知発行部４００を追加してもよいし、あるいは表示内容決定部２３０に、通知発行部４００の機能を内蔵することでも実現できる。なお、図２５において、図１に示した表示構成部３００については記載を省略している。

図２５に示す通知発行部４００は、各機能を制御し通知ルールに従って適切な宛先へ通知メッセージを発行する通知制御部４１０、通知ルールが保存される通知ルール保存部４２０、クライアントの状態を判定するクライアント状態判定部４３０、クライアント状態又はクライアントからの指示に応じて通知ルール設定を変更する通知ルール設定部４４０から構成される。

また、外部アプリケーション連携部６００は、通知制御部４１０と外部のアプリケーションソフトウェア（以下、アプリケーションという。）との対応をとるものであり、通知制御部４１０からの指示により、例えばメール６１０、インスタントマネージャー（チャット）６２０や電話６３０などに通知メッセージを通知する。

本例で処理される通知メッセージの一例を図２６に示す。通知メッセージは、タイプ、重要度、発行日、有効期限、タイプ依存データから構成されている。

ここでタイプとは、コンテンツ共有システム内で、どの出来事を通知するかを表すものである。通知の種類としては、
・自分の、もしくは気になるコンテンツコンテナへの画像やコメントの投稿
・自分がコメントした後のコメント
・盛り上がっているコンテンツ
・久しぶりに投稿した人の投稿
・グループの動向
・他ユーザとの関係性（最近、コミュニケーションしていないなど）
などが考えられるが、これに限らない。

また重要度は、すべての通知メッセージに設定され、通知を受け取るユーザにとってどれぐらい価値のある通知かを表す指標である。通知の重要度はコンテンツ重要度判定部４００やその他のモジュールによって計算される値であり、０又は１の２値評価や、０〜２５５の２５６段階評価であってもよい。本実施例では説明を簡単にするために、０〜５の６段階評価とし、５が最も重要で、０は通知する必要がないものと定義する。

また有効期限は、例えば更新間隔内で通知されなかったり、一時的にクライアントへもメールへも通知されないなど、何らかの理由で有効期限内に通知が発行されなければ、破棄されるような構成としてもよい。

実際の通知メッセージは、その通知のタイプに応じて、通知内容に関するデータ（タイプ依存データ）が含まれており、その内容は例えば、コンテンツを指定するＩＤやハイパーリンク、コンテンツのメタデータやメディアデータが含まれていてもよい。

次に、本例の通知ルールについて説明する。通知ルールはすべてのユーザに対して設定されるものであり、クライアント又は外部ツールに対して個別に又はクライアントすべてに共通に設定された通知に関する設定情報である。すべての通知はこの通知ルールに基づいてクライアント又は外部ツールに発行される。例えば通知ルールがクライアントや外部ツール毎に設定される場合、図２７に示されるようなものが考えられる。

図２７Ａ，Ｂ，Ｃはクライアント毎に持つ場合の各通知ルールの一例であり、（Ａ）はクライアントＡ、（Ｂ）はクライアントＢ、（Ｃ）はメールシステムへの通知ルールである。

ここで、通知先とは通知を発行するクライアント又は外部ツールである。またアクティブ状態とは、クライアントへ通知を発行するか否かを示す状態であり、ＯＮ（オフ）又はＯｆｆ（オフ）で表される。このアクティブ状態は他の通知ルールと排他的な構成としてもよいし、重複してもよい。また、重要度閾値とは、どの重要度以上の通知を発行するかを決定するための閾値で、例えば重要度３以上の通知を発行するといったように使う。

さらに通知間隔は通知を発行する間隔である。例えば、メールでの通知は一定の間隔でまとめて通知するといったことが可能になる。Pull（プル）型や擬似push（プッシュ）型のクライアントの場合はそのpolling（ポーリング）間隔となりなりうる。通知間隔はクライアントがpull型又は擬似push型の場合、クライアントに保存されることもある。

これら通知ルールのタイプや重要度閾値、通知間隔はすべてのクライアントで共通でもよい。

また、ひとつのクライアントや外部ツールへの通知が複数の通知ルールによって構成されてもよい。例えば、図２８Ａ，Ｂに示されるようなものが考えられる。この例では、通知ルー２（図２８Ｂ）では重要なもの（重要度閾値５以上）は即時通知され、通知ルール１（図２８Ａ）では１時間に１回、通知先に指定されたメールアドレスにメール通知される。

通知発行部４００の通知制御部４１０では、実際に通知ルールに従って適切なクライアントへ通知を発行する。通知制御部４１０により行われる基本的処理のフローチャートを図２９に示し、以下で説明する。

図２９において、まず、上記で述べたような通知を取得する（ステップＳ２９０１）。これは画像やコメントの投稿などのアクションをトリガーとして通知を検出してもよいし、一定の間隔で通知すべきものをポーリングしてもよい。重要度を持った通知を検出する方法の一例として、ユーザ嗜好データに基づく方法が挙げられるが、これについては後述する。

次に、アクティブな通知ルールを取得し、通知先を決定する（ステップＳ２９０２）。これは通知ルールのアクティブ状態を見ればよい。アクティブ状態を変更する方法として以下のようのものが考えられる。

まず、クライアントのログイン情報をクライアント状態判定部４３０で取得し、ログインしているクライアントすべてに対応する通知ルールをアクティブとする方法がある。あるいは最後にログインしたクライアントのみの通知ルールをアクティブとする方法もある。

またログインしているクライアントがなければ、外部アプリケーション連携部６００と連携してメールで通知を発行する。ユーザはどのメールアドレスへ通知するかを予め通知ルールとして設定しておける。ユーザ一人が複数のメールアドレスをそれぞれ通知ルールとして設定できてもよい。その場合、すべてのメールアドレスに通知を発信してもよいし、予めどれかひとつを選択できるような構成でもよい。

メールを利用した他の手段として、例えばインスタントメッセンジャー６２０などの外部アプリケーションに通知を発行してもよい。また、電話６３０を（例えば、いわゆる”ワン切り”で）通知の代わりとする方法も考えられる。この場合、重要度に応じて発信元を変えてもよい。

さらに、クライアント上のユーザ操作（手動操作）によって動的に通知先を決定してもよい。例えば、もっとも最近に操作したクライアントに対応する通知ルールを自動的にアクティブにする。または通知先変更ボタンを押すと、そこへ通知する。あるいは通知先リストから選択する。などのようなことが考えられる。

またさらに、外部ツールによって通知先を変更するような構成としてもよい。例えば、ユーザ毎のある特定のメールアドレス(例えば、[ユーザ名]-start@lifechannel.net)へメールを送信することによって、そのメールの送信元(From:)への通知を開始するようにする。

図３０は、メールで通知先（アクティブ状態）を設定する場合のフローチャートである。図２５に示すシステムはメールを受け取るとまず、取得したメールの送信元(From:)を解析する（ステップＳ３００１）。送信元にマッチする通知ルールを検索し（ステップＳ３００２）、送信元にマッチする通知ルールがあるかどうかを判別する（ステップＳ３００３）。

この送信元がそのユーザの通知ルールとして登録されていれば、その通知ルールをアクティブにして（ステップＳ３００４）、処理を終了する。送信元が登録されていなければ、例えばメールのbody（本文）に書かれたパスワードを取得し（ステップＳ３２０５）、認証を行なう（ステップＳ３２０６）。認証に成功すればその送信元をユーザ名で示されたユーザの通知先として登録し（ステップＳ３２０７）、ステップＳ３００４へ進んでその通知ルールをアクティブ状態にする。

通知ルールはデフォルトの通知ルールを利用してもよいし、既存の通知ルールをコピーしてもよい。認証に失敗したら認証エラーメッセージを送信する（ステップＳ３２０８）。この際、パスワードの記述方法を含める。

ユーザ毎のある特定のメールアドレス（例えば[ユーザ名]-stop@lifechannel.ne.jp）へメールを送信することによって、そのメールの送信元(From:)に対応する通知ルールを非アクティブ状態にする。

通知メールを受信したときに、そのメールへ返信することによって、そのメールアドレスに対応する通知ルールを非アクティブにする、又はしばらく非アクティブにする。

またアクティブ状態の変更をサブジェクトや本文に埋め込まれたコマンドで制御してもよい。さらにメールの送信先が全ユーザ共通で、サブジェクトや本文にユーザ名を含めるような構成としてもよい。

上記ステップＳ２９０２にてアクティブな通知ルールを特定できたら、それぞれの通知ルールに対して以下の処理を行う（ステップＳ２９０３）。通知メッセージの重要度（図２６参照）と通知ルールの重要度閾値を比較して、通知の重要度が通知ルールの重要度閾値以上であれば、その通知先に実際に通知する（ステップＳ２９０４）。

実際の通知メッセージの通知にあっては、通知メッセージをいったん所定の通知スプールにためて、そこから通知するような構成としてもよい。スプールは通知ルール固有であってもよいし、すべての通知ルールで共通であってもよい。スプールが通知ルール固有の場合は通知ルールに基づいて通知を判別した後、スプールにためられる。共通の場合、すべての通知はいったんスプールにためられてから、通知ルールに基づいて実際に通知される。

例えば通知間隔が即時でない場合、通知メッセージをいったんスプールしておくと、次の通知のタイミングのときに実際に通知する。また、例えば一人のユーザが複数のクライアント（デバイス）を使用している場合など、いずれかのクライアントへ通知メッセージが発行されたら、その通知メッセージは他のクライアントへ発行されないような構成としてもよい。

次に、通知ルールの変更について説明する。まず、通知に対するユーザからのフィードバックによる通知ルールデータの自動修正が考えられる。上述の通知メールのアクティブ度の変更でも述べたように、例えば、通知メールを受信したときに、ユーザがそのメールへ返信することによって、そのメールアドレスに対応する通知ルールを非アクティブにする、又はしばらく非アクティブとする方法である。またアクティブ状態の変更をサブジェクトや本文に埋め込まれたコマンドで制御してもよい。さらにメールの送信先が全ユーザ共通で、サブジェクトや本文にユーザ名を含めるような構成としてもよい。

続いてコミュニケーション履歴に基づいて、すなわちユーザの活動に応じて通知ルールを自動設定する方法について述べる。この方法は、画像投稿やコメント活動が少なくなると、活動を促進するために、よく使用するクライアントの通知ルールの重要度閾値、又はすべての通知ルールの重要度閾値を一時的に下げるというものである。

また、他の方法としては、クライアント状態に基づいて通知ルールの重要度閾値を自動修正する方法も考えられる。一例としては、クライアント上の操作を検出して、重要度閾値を変更する。例えば、クライアント上で頻繁にアクセスしているときは重要度閾値を低く、ほとんど操作されていないときは重要度閾値を高くする。これによって、バックグラウンドにあるときは重要なものだけしか通知されないようになる。またＰＣのロードアベレージ（Load Average）を見て、ロードアベレージが低いときは重要度閾値を下げる。あるいは、立ち上がっているＰＣの種類を見て、重要度閾値を変更する、などの設定が考えられる。

これらの通知ルールにより、クライアントの活動状態によって、ユーザに対しあるコンテンツを見るよう促したり、逆に通知メッセージを控えたりすることができる。例えば、ロードアベレージの値が大きいとき、そのＰＣは数多くのプログラムを実行中、すなわちユーザも忙しいと予想され、よほど重要な通知以外は受けたくない状態であろう、といったような判断を行うことができる。

一方、通知ルールの重要度閾値を手動修正する方法としては以下のようなものが考えられる。第１に、クライアントのユーザインターフェース上に重要度閾値変更用のスライドバーを設けるというものである。この重要度閾値変更スライドバーの例を図３１に示す。図３１において、１２０はクライアントのユーザインターフェースであり、重要度閾値変更スライドバー１２１のポインタを移動させることにより、この例では重要度を０〜５の６段階で変更できるようになっている。

また第２の方法として、携帯電話などの携帯端末に、重要度閾値変更用のジョグダイアルを設ける。図３２は、重要度閾値変更ジョグダイアルの例を示す。携帯端末１３０の筐体の所定部位に重要度閾値変更ジョグダイアル１３１を設け、ジョグダイアル１３１を操作することにより重要度閾値表示１３２を上述同様変更することができる。

また第３の方法として、テンキーを利用する。図３３は、テンキーによる重要度閾値変更を説明するための図である。例えば、携帯電話１３０上であれば、テンキー１３３の番号のボタンをそのまま重要度閾値にマッピングする。例えば、「０」を押すと通知ルールが非アクティブ化され、「１」を押すと重要度閾値１、「５」を押すと重要度閾値５へと重要度閾値表示１３２が変化する。勿論、キーボードのテンキーなどでもよい。

あるいは物理ボタンのボタン長押しという方法が考えられる。図３４は、ボタンの長押しよる重要度閾値変更を説明する図である。例えば、携帯電話１３０上のある特定ボタンなどの物理的なスイッチを押す時間によって重要度閾値を設定する。例えば、重要度閾値設定ボタン１３４を長く押すと重要度閾値が高くなり、短いと通知なしなどとする。また通知停止ボタン１３５を設けて通知停止設定してもよい。

また、通知ルールを「仕事モード」や「家モード」などのテンプレートに登録し、リストから選択するようにしてもよい。この場合も上述のような方法でテンプレートを変更できる。

さらに、外部ツールによって通知ルールを変更できる方法も考えられる。これは、メールの本文に重要度閾値や上記通知ルールテンプレートを変更するためのコマンドを埋め込み、その送信元に対する通知ルールを変更するというものである。

また、あるクライアントでの通知ルールデータの変更が他のクライアントの通知ルールデータへ影響してもよい。例えば、あるクライアントで重要度閾値を下げると、他のクライアントでは上がるなどが考えられる。

また、通知ルールが変更されたとき、新しい通知ルールにマッチする通知がないかどうかを再検出するような構成としてもよい。

次に、クライアントや外部ツールの種類に応じて通知メッセージの内容を変更する方法について説明する。これは、通知先のクライアントやメールなどの外部ツールに応じて通知メッセージを変更するようにする。例えば、メールではタイトルや本文などのテキストのみとしたり、あるいは一定の間隔でメールする場合、サマライズ（要約）して送る。例えばメールのデータ容量が所定値（例：数KB）以下となるようにサマライズする。

また、重要度に応じて通知方法を変更する方法について説明する。クライアント側では重要度に応じて通知が来たことを知らせるアクション（手段）を変更してもよい。例えば、以下のようなものが挙げられる。
・例えば、振動の強度を重要度に応じて変化する。
・音の大きさやテンポ、音程、曲などが重要度に応じて変化する。
・ＬＥＤ（Light-Emitting Diode）などの光の強度や色、点滅パターンなどが重要度に
応じて変化する。
・ポップアップしている時間やそのサイズ、透明度、色、アニメーションなどが重要度
に応じて変化する。
・電気刺激、その他。

また、別のユーザを通知先として設定する方法について説明する。通知先は、コンテンツを投稿したユーザとは別のユーザでもよい。例えば、あるユーザが投稿したコンテンツに対し、別のユーザがコメントを付けた時、元のコンテンツを投稿したユーザに通知するだけでなく、コメントを付けたユーザにも通知メッセージを送ることができる。あるいは、更に第三者にも通知し、アンケート集計等に利用することも考えられる。

図３５は、別のユーザを通知先として設定できるようにしたコンテンツコンテナ表示画面の例を示すものである。コンテンツ毎に、グループを作成する通知設定ボタン１１１，１１１ａが配置され、コンテンツ作成者がこのボタンを押して通知設定と表示させることで、コメントを投稿したユーザに対しても通知メッセージが送られる。この場合、コメント投稿者は、通知メッセージが送られてくることを予め認識できる。なお、通知設定ボタンを押す代わりに、コンテンツに対する右クリックでもよい。

次に、通知対象イベントの内容に応じて通知メッセージの内容を変更する場合について説明する。これは、通知が起こる原因となったイベントの内容に応じて、通知の内容や方法を変化させる。例えば、コンテンツに対するコメントに、特定の文字列が含まれているかどうかに応じて、予め準備したメッセージと通知方法で通知を行うようにする。

上述の別ユーザへの通知方法と組み合わせると、例えば以下のようなことが実現できる。
・あるユーザがコンテンツを投稿することでクイズを出題する。
・別のユーザがコメントを投稿することで回答する。
・正解あるいは不正解という通知が、出題者及び回答者に届く。
・同じ通知が、集計を行うために設定された第三者にも届く。

次に、コンテンツ情報とユーザ嗜好データ（コンテンツコンテナ、コンテンツ、他のユーザ）に基づいてコンテンツ重要度を判別する方法について説明する。

図３６は、本発明のさらに他の実施の形態の例のシステム構成であり、図２５に示すコンテンツ重要度判定部５００内部の詳細なブロック構成を表している。コンテンツ重要度判定部５００は、重要度判定部５１０、ユーザ嗜好データ５２０、ユーザ嗜好データ設定部５３０から構成される。

コンテンツ重要度判定部５００を構成する重要度判定部５１０は、ユーザ嗜好データ保存部５２０に蓄積されているユーザ嗜好データと通知制御部４１０から送信されるコンテンツ情報から、コンテンツの重要度を判別して、判別結果を通知制御部４１０に送信する。

ユーザ嗜好データ保存部５２０は、コンテンツコンテナ、コンテンツ、及び他のユーザに対するユーザの嗜好データを保持することができる。

またユーザ嗜好データ設定部５３０は、後述する各種の情報に基づきユーザ嗜好データを設定、変更する。

以下、ユーザ嗜好データを設定する方法について説明する。図３７はユーザ嗜好データの例を示し、（Ａ）はコンテンツコンテナ、（Ｂ）はコンテンツ、（Ｃ）はユーザに対する嗜好ポイントをそれぞれ表している。この例では、コンテンツコンテナＣＳ１に対する嗜好ポイントは３である。同様に、コンテンツＣ１に対する嗜好ポイントは５であり、ユーザＵ１に対する嗜好ポイントは２である。嗜好ポイントは、ユーザがその対象に興味を持つほど大きな数値となる。

これらユーザ嗜好データは、例えば図３８に示すようなユーザインターフェース画面を用いて、ユーザが手動で設定することができる。この例では、コンテンツコンテナ全体に対する嗜好ポイントを設定する興味度スライダー１４０と、個別のコンテンツに対する嗜好ポイントを設定する興味度スライダー１４１，１４１ａがそれぞれ用いられており、各スライドバーのポインタを左右にスライドさせることにより、それぞれの嗜好ポイントを設定することができる。なお、数値を設定する方法であれば、これ以外にもダイヤルやボタンなど様々な方法が利用できる。

また、ユーザ嗜好データを設定する方法として、クライアントの状態によって一時的にユーザ嗜好データを変更することも考えられる。例えば、ＧＰＳ等によってクライアントの現在位置情報が取得できる場合、クライアントの現在位置と近い位置情報を持つコンテンツに対する嗜好ポイントを、ユーザ嗜好データ設定部５３０が一時的に高く変更することなどが考えられる。

次に、コミュニケーション履歴に基づいてユーザ嗜好データを自動修正する方法について説明する。これは、ユーザの過去の操作内容に基づいて、ユーザ嗜好データを修正するものである。まず、ユーザ嗜好データ設定部５３０が、コミュニケーション履歴データから、ユーザの過去の操作情報を取り出す。過去の操作情報からは、例えば以下のような情報が得られる。

１．ユーザが新たにコンテンツを投稿した場合
・そのコンテンツ
・そのコンテンツが属するコンテンツコンテナ
・そのコンテンツを投稿した日時
２．ユーザが既にあるコンテンツにコメントを付けた場合
・そのコンテンツ
・そのコンテンツが属するコンテンツコンテナ
・そのコンテンツを最初に投稿したユーザ
・そのコンテンツにコメントを付けた日時
３．ユーザがコンテンツ、コンテンツコンテナ、あるいはそのユーザを「お気に入り」と
マークした場合

例えば、ユーザが新たにコンテンツを投稿した場合、ユーザ嗜好データ設定部５３０は、自動的にそのコンテンツ、コンテンツコンテナに対する嗜好データのポイントを高く設定する。こうすることにより、ユーザは自分が投稿したコンテンツ、コンテンツコンテナに対する関心を高く保つことができる。

また、ユーザ嗜好データ設定部５３０は、コンテンツを投稿した日時からの経過時間によって、自動的にそのコンテンツ、コンテンツコンテナに対する嗜好データのポイントを次第に低く変更することもできる。こうすることにより、ユーザは自分が投稿したコンテンツ及びコンテンツコンテナに対し、投稿した直後は関心を高く、次第に関心を低く変化させることができる。

次に、ユーザが既にあるコンテンツにコメントを付けた場合、ユーザ嗜好データ設定部５３０は、自動的にそのコンテンツ、コンテンツコンテナ、及びコンテンツを投稿したユーザに対する嗜好データのポイントを増加させる。こうすることにより、ユーザは自分がコメントを付けたコンテンツ、コンテンツコンテナ及びそのユーザに対する関心を高く保つことができる。

また、ユーザ嗜好データ設定部５３０は、コンテンツを投稿した日時からの経過時間によって、自動的にそのコンテンツ及びコンテンツコンテナ、コンテンツを投稿したユーザに対する嗜好データのポイントを次第に低く変更することもできる。こうすることにより、ユーザは自分が投稿したコンテンツ、コンテンツコンテナ、及びそのユーザに対し、投稿した直後は関心を高く、次第に関心を低く変化させることができる。

ユーザは、あるコンテンツやコンテンツコンテナ、あるいは特定のユーザを、自分の「お気に入り」として登録することができる。お気に入りに登録したコンテンツやコンテンツコンテナ、あるいは特定のユーザは、後で容易に参照することが可能になる。ユーザ嗜好データ設定部５３０は、ユーザがコンテンツやコンテンツコンテナ、あるいは特定のユーザをお気に入り登録したことを検出したら、自動的にそのコンテンツ、コンテンツコンテナ、あるいは特定のユーザに対する嗜好データのポイントを増加させる。

ユーザ嗜好データ設定部５３０は、ユーザ嗜好データのポイントを自動的に変更する際に、ユーザに対して確認を求めることができる。こうすることで、意図しないユーザ嗜好データの変更を防ぐことができる。

次に、通知に対するユーザのフィードバックに基づいて、ユーザ嗜好データを自動修正する方法に付いて説明する。これは、ユーザが通知を受けたとき、実際にコンテンツを閲覧する前に、その通知に関する応答を行う。さらに、ユーザ嗜好データ設定部５３０は、そのユーザの応答に基づいて、ユーザ嗜好データを自動的に修正する。その流れは以下のようになる。

まず、通知発行部４００の通知制御部４１０からクライアントに対し通知が行われる。この時、通知には少なくとも次の情報が含まれる。すなわち、コンテンツ、コンテンツコンテナ、コンテンツを投稿したユーザの情報である。

ユーザは、受け取った通知を見て、実際にコンテンツを閲覧する前に、その通知が有用であったかどうかの評価を行う。もし、今後同様の通知を受け取りたくないと思った場合は、通知が不要であることを示す応答を行う。また、今後も積極的に同様の通知を受け取りたいと思った場合は、通知を歓迎することを示す応答を行う。どちらでもない場合は、特に応答を行う必要はない。

ユーザの応答は、ユーザ嗜好データ設定部５３０に届けられる。ユーザ嗜好データ設定部５３０は、ユーザからの応答の内容に応じてユーザ嗜好データの嗜好ポイントを増減させる。

次に、コンテンツ情報にコンテンツ作成者がお勧め度を設定する方法について説明する。この方法の場合、各々のコンテンツあるいはコンテンツコンテナに対して、個々のユーザの嗜好データとは別に、ユーザへのお勧め度を設定することができる。コンテンツお勧め度やコンテンツコンテナお勧め度は、特定のユーザに対して設定することもできるし、不特定のユーザに対して設定することもできる。

図３９は、ユーザお勧め度のデータ形式の例を示し、（Ａ）はコンテンツコンテナお勧め度、（Ｂ）はコンテンツお勧め度をそれぞれ表している。図３９Ａ、図３９Ｂに示されるように、ユーザお勧め度データはそれぞれの嗜好ポイントと対象ユーザから構成される。

この例では、例えば図３９ＡのコンテンツコンテナＣＳ1はユーザＵ３に対してお勧め度が３であり、またコンテンツコンテナＣＳ２はすべてのユーザに対してお勧め度が１であるというような情報が含まれている。図３９Ｂのコンテンツについても同様に、例えばコンテンツＣ1はすべてのユーザに対してお勧め度が２で、コンテンツＣ２はユーザＵ２に対してお勧め度が３であるという情報が含まれている。

コンテンツお勧め度やコンテンツコンテナお勧め度は、例えば以下のような方法で指定することができる。
・ユーザがコンテンツを投稿する時に、同時に対象ユーザやお勧め度を指定する。
・既にあるコンテンツに対して、ユーザが後から対象ユーザやお勧め度を指定する。
・コンテンツに付加されたコメントの数やコンテンツが閲覧された回数を基に、コンテンツ管理部２００が自動的に対象ユーザやお勧め度を設定する。

図４０は、お勧め度設定を行うユーザインターフェースの一例を示す。この例では、投稿する画像１１３付きコンテンツに対して、お勧め度を設定できるスライダー１５１が設けられ、ユーザはスライダーのポインタを左右にスライドさせて、自由にお勧め度を設定することができる。このお勧め度設定スライダーは、投稿先のコンテンツコンテナでも確認することができる。

図４１は、図４０に示すようなコンテンツが投稿されるコンテンツコンテナの表示画面の例を示す。この例では、コンテンツコンテナ全体に対するお勧め度を設定するスライダー１６０と、個別のコンテンツに対するお勧め度を設定するスライダー１６１，１６１ａが用いられているが、数値を設定する方法であれば、これ以外にもダイヤルやボタンなど様々な方法が利用できる。

次に、コンテンツ作成時に通知ルールを設定する方法について説明する。これは、ユーザはコンテンツを投稿する際に、そのコンテンツに対してコメントが付けられた時のアクションを設定することができる。アクションには、例えば以下のようなものが考えられる。

・コメントされたことを自分に通知する／しないを選択する。
・コメントされたときに、コメントしたユーザにメッセージを送る。
・コメントされたときに、コメントしたユーザに、コメントの内容に応じて異なるメッセージを送る。

図４２は、アクション設定のユーザインターフェースの一例である。この例では、投稿する画像１１３付きコンテンツに対して、コメントが付けられた時に通知を受け取るかどうかのアクション定義１７１と、コメントしたユーザに指定したメッセージを送るかどうかの設定１７２ができる。

次に、コンテンツお勧め度及びユーザ嗜好データに基づいてコンテンツ重要度を算出する方法について説明する。これは、ユーザの嗜好データ、及びコンテンツあるいはコンテンツコンテナのお勧め度を基に、あるコンテンツがユーザにとってどれぐらい重要であるかを示す重要度を算出することができる。

重要度は、例えば次のようにして算出する。まず、通知発行部４００の通知制御部４１０（図２５参照）は、重要度を知りたいコンテンツを指定して、重要度判定部５１０に重要度の判定を依頼する。重要度判定部５１０は、ユーザ嗜好データから、指定されたコンテンツに関する嗜好ポイントを検索する。もし見つかったら、その嗜好ポイントを重要度の初期値とする。見つからなかった場合は、重要度を０に設定する。

そして重要度判定部５１０は、指定されたコンテンツに関するお勧め度を、コンテンツ管理部２００に問い合わせる。もし見つかった場合は、そのコンテンツお勧め度を重要度に加算する。最後に、必要に応じて重要度が０〜５の間に収まるように正規化を行う。以上の計算によって算出された重要度を、指定されたコンテンツの重要度として通知制御部４１０に渡す。

例えば、コンテンツＣ1を指定した場合、重要度判定部５１０は、以下のようにして重要度を計算する。
１．まず、ユーザ嗜好データ（図３７Ｂ）から嗜好ポイント５を取り出し重要度の初期とする。
２．もしもコンテンツＣ１がコンテンツコンテナＣＳ３に属している場合は、コンテンツコンテナＣＳ３の嗜好ポイント１を更に重要度に加算する。
３．もしもコンテンツコンテナＣＳ３を作成したユーザがU2である場合は、ユーザＵ２の嗜好ポイント５を更に重要度に加算する。
４．コンテンツ管理部からコンテンツお勧め度2を取得して、更に重要度に加算する。
５．もしもユーザ自身がＵ１である場合は、コンテンツ管理部からコンテンツコンテナＣＳ３のお勧め度２を取得して、更に重要度に加算する。
６．重要度を０〜５の範囲に収めるために、加算結果の９を計算に用いたポイントの種類（コンテンツ嗜好ポイント、コンテンツコンテナ嗜好ポイント、ユーザ嗜好ポイント、コンテンツお勧め度、コンテンツコンテナお勧め度）の数５で割って、最終的な重要度１．８を得る。

また、通知制御部５１０は、コンテンツを指定せずに、重要度の高いコンテンツの検索を重要度判定部５１０に依頼することもできる。その場合、重要度判定部５１０はまず、ユーザ嗜好データに登録されているすべてのコンテンツについて、コンテンツ管理部２００からコンテンツお勧め度を取得する。それを各々のコンテンツ嗜好ポイントと加算することで、各々の重要度を求める。そして、重要度が高い順に、コンテンツと重要度を通知制御部４１０に返す。

別の方法では、重要度判定部５１０はまず、コンテンツ管理部２００に対して、お勧め度が高いコンテンツを問い合わせる。コンテンツ管理部２００は、お勧め度が高い順に、いくつかのコンテンツとそのお勧め度を返す。重要度判定部５１０は、返って来た各々のコンテンツについて、ユーザ嗜好データに嗜好ポイントが登録されているかどうか調べ、もし見つかったらその嗜好ポイントをコンテンツお勧め度に加え、それをコンテンツ重要度とする。そして、重要度が高い順に、コンテンツと重要度を通知制御部４１０に返す。

なお、ここでは重要度の計算方法をユーザ嗜好データとコンテンツお勧め度の平均値とする例を示したが、これ以外の計算方法も自由に利用できる。また、複数の計算方法を用意し、必要に応じて切り替えて利用するような構成とすることも可能である。

以上図２５〜４２を用いて説明した構成によれば、ユーザにとって価値のある通知メッセージを、適切なクライアントへ発行することができる。またクライアントに応じて、又はユーザの状態に応じて必要な通知のみを受け取るようにすることができる。また、コンテンツ投稿者のお勧め度と通知の受信者の興味度に応じて、他の関係も加味して、通知受信者にとって価値のある通知を検出できる。

次に、本発明のさらに他の実施の形態の例について説明する。本例は、例えば上述した実施の形態のコンテンツ共有システムにより通知されたメッセージを見たユーザが、そのコンテンツを閲覧したときに、コンテンツへのユーザのアクセス履歴の開示レベルを、アクセスユーザ自身が設定できるようにしている。

図４３は、本発明のさらに他の実施の形態の例のシステム構成を示す図である。本例のシステムはコンテンツ共有部７００とクライアント１００から構成され、例えば、コンテンツ共有部７００は、ネットワーク上で動作するウェブサーバであり、クライアントはウェブブラウザである。

コンテンツ共有部７００は制御部７１０、コンテンツ保存部７２０、アクセス履歴保存部７３０、及び外部インターフェース７４０から構成される。

制御部７１０は、コンテンツ保存部７２０のコンテンツについて登録、変更、削除、取得などの操作を行い、それらのコマンドの履歴をアクセス履歴保存部７３０に保存する。外部インターフェース７４０は、外部からのコンテンツの登録要求、取得要求などのコマンドを受け付け制御部７１０に渡すとともに、制御部７１０から送られる結果を外部に返す。また、コンテンツ保存部７２０には、コンテンツ自体、そのメタデータ、各コンテンツに関するアクセス権限データが保存されている。制御部７１０はコンテンツのアクセス権限データを利用して、許可・不許可を判定する。

アクセス履歴保存部７３０のデータベース構造について、図４４〜図４７を参照して説明する。

図４４は、アクセス履歴データを示すテーブルである。クライアントからの要求コマンドの履歴のテーブルとなっている。例えば、ｉＤ＝１のデータは、アクセスしたユーザはＩＤが「1001」であり、その要求コマンドは「GET(1343)」、コマンド受付時間は「2003-12-01 10:31」、アクセス元のホスト名は「foo.example.com」となっている。さらに、このデータ自体のパーミッション（permission）のＩＤが1となっている。

図４５は、パーミッションテーブルを示す。このテーブルには、誰に対して、どのレベルのアクセスを許可するかを保存している。例えば、ＩＤ＝１のパーミッション情報は、ＩＤが1001,1003,1134で表されるユーザ又はユーザグループに対しては、アクセスレベル０（access_level_0）を許可し、ＩＤが2321で表されるユーザ又はユーザグループに対してはアクセスレベル１（access_level_1）を許可し、「*」で表されるその他のユーザ又はユーザグループに対してはアクセスレベル２（access_level_2）を許可する。なお、NULLは設定が存在していないことを表す。

ここでアクセスレベル（access_level）とはアクセス履歴情報に対するパーミッション情報である。例えばアクセスレベル０では、アクセスしたユーザの名前、時間、回数、他にアクセスしたコンテンツ(履歴)など全情報が公開されることによって、誰がいつどのようにアクセスしたかがわかる。アクセスレベル１では、例えばアクセスしたユーザのＩＤのみが公開されることにより、ユーザ名はわからないが、何人のユーザがアクセスしているか判断できる。また、アクセスレベル２では、ユーザのＩＤも公開されず、単にアクセスしたことのみが公開されるため、アクセスしたユーザを識別することはできないが、少なくとも一人のユーザがアクセスしたかどうかわかる。さらに、アクセスレベル３（access_level_3）ではすべての情報が非公開であり、アクセスしていること自体わからない。

図４６は、ユーザデータのテーブルであり、各ユーザのＩＤとそのユーザの属性情報を保存している。本例の属性情報は、ユーザの名前、メールアドレス、電話から構成される。

図４７は、ユーザグループデータのテーブルである。本テーブルには各ユーザグループの情報が保存されており、例えば、この例ではＩＤ＝2001のグループは、グループ名がskiで、グループのオーナーがＩＤ＝1001のユーザで、メンバーはＩＤ＝1001,1003,1025のユーザである。ここで、オーナーとは、グループ名やメンバーなどのグループ情報を変更できる権限を持ったユーザのことである。

以上のようなデータ構造により、あるアクセス履歴を誰に対してどのレベルまで開示するかを設定することができる。

次に、クライアント、サーバ間の実際のインターフェースの例を示す。クライアントは、上述したアクセス履歴保存部７３０のデータ構造を、適当なネットワークインターフェースを利用して設定する。例えば、ＨＴＴＰのヘッダ(エンティティヘッダ)にアクセス履歴のパーミッション情報を含めることができる。具体的な例を、図４８に示す。図４８のＨＴＴＰヘッダ拡張例に示すように、ヘッダ部にアクセスコントロール情報が、X-Access-Level-#という形で送信される。また、ＨＴＴＰヘッダを利用した場合には、GETなど他のメソッドについても同様にそのリクエストのアクセスコントロールを同様に設定することができる。

次に、ＣＧＩ（Common Gateway Interface）のパラメータとして、アクセス履歴のパーミッション情報を設定する方法について説明する。図４９は、ＨＴＴＰマルチパートポスト（multipart post）の例を示す。この図４９に示されるように、multipart/form-dataを用いて、ファイルをアップロードしている場合には、マルチーパートデータの１つにパーミッション情報を加えることができる。

さらに、他の例としては、一般的なＲＰＣ（remote procedure call）の枠組みである、ＳＯＡＰ（Simple Object Access Protocol）やＸＭＬ−ＲＰＣ（eXtensible Markup Language−RPC）などに適当なインターフェースを作成してもよい(例えば、BloggerAPIに対する拡張例など。)。

次に、図４３のクライアント１００及びコンテンツ共有部７００間の処理の流れを、図５０及び図５１を参照して説明する。

図５０はアクセス履歴登録に関する処理の流れを示すシーケンスである。まずクライアント１００はコンテンツ共有部７００に対し、アクセス履歴登録を依頼する。このとき、アクセスのタイプを示す、GETやPUT等のコマンド（command）、クライアントを特定するユーザＩＤ（user_id）、どのコンテンツに対するアクセスかを示すコンテンツＩＤ（content_id）、アクセス履歴情報へのパーミッション情報であるアクセスレベル（access_level）などをコンテンツ共有部７００へ送信する。実際には図４８や図４９で説明したような形でコンテンツ共有部７００へ依頼する。

コンテンツ共有部７００では、受信したアクセス履歴登録依頼からアクセス履歴情報を抽出する。つまり、図４８や図４９の情報からアクセス履歴に関する情報のみを抜き出す。次に抽出したアクセス履歴情報を保存し、保存完了もしくは失敗をクライアント１００へ送信する。このとき保存先や保存失敗理由(例えば保存拒否、アクセス履歴情報の欠落、コンテンツ共有部７００のメモリフルなど)を同時に送信してもよい。もしくはクライアント１００へ結果を返さなくてもよい。

図５１は、アクセス履歴閲覧に関する処理の流れを示すシーケンスである。まずクライアント１００はコンテンツ共有部７００へアクセス履歴取得依頼を通知する。このとき、ユーザＩＤ（user_id）及びコンテンツＩＤ（content_id）、を同時に送信する。ここで、アクセス履歴取得依頼はコンテンツ情報の取得依頼と同時に通知してもよい。

コンテンツ共有部７００では、受信したアクセス履歴取得依頼に対し、ユーザＩＤのユーザがコンテンツＩＤのコンテンツのアクセス履歴情報を取得可能かどうかチェックする。つまり、パーミッションテーブルに保存されたアクセスレベルをチェックする。アクセスが許可されている場合、アクセスレベルに合ったアクセス履歴情報を取得しクライアント１００へ送信する。一方、アクセスが許可されない場合はその趣旨を送信する。

以上のような処理により、アクセス履歴を登録し、設定されたアクセス履歴を閲覧することが可能である。

次に、クライアント１００がアクセス履歴を設定する場合のユーザインタフェースについて、図５２〜図５６を参照して説明する。

図５２は、アクセス履歴へのパーミッション情報(アクセスレベル)を特定のボタンによって簡単に設定する例である。このようにパーミッション情報を複数のカテゴリーに分類し、各パーミッションに対しボタンを割り当てることで簡単にパーミッション情報の設定ができる。例えば、ボタン８０１ａの開示レベルを公開設定、ボタン８０１ｂをＩＤ付き匿名設定、ボタン８０１ｃは匿名設定として機能させる。このアクセス履歴パーミッション設定ボタン８０１の操作とアクセス履歴登録依頼を同時に行ってもよい。つまり、ボタンが押されると同時にアクセス履歴情報を含む登録依頼をコンテンツ共有部７００へ送信する。なお、８０２はアクセス履歴パーミッションの詳細を設定するボタンである。

また、アクセス履歴パーミッション設定をアクセス先(コンテンツ)によって指定するインターフェースの例を図５３に示す。図５３では、コンテンツアドレス入力欄が設けられ、アクセス履歴はコンテンツ毎に設定することが可能である。ここで、コンテンツとはＷＷＷにおけるＨＴＭＬファイルでもいいし、ＨＴＭＬファイル内の画像やテキストなどＨＴＭＬファイルの一部でもいい。また、ＨＴＭＬファイル内の位置や領域で指定された一部分でもいい。あるいは蓄積されているデータが画像やテキストである場合、画像やテキストそのものでもいいし、位置や領域で指定された画像及びテキストの一部でもいい。あるいはアルバムのように画像やテキストをまとめたものでもいい。

このようにコンテンツ毎にアクセス履歴のパーミッションを設定することが可能である。しかし、アクセス履歴を残したいコンテンツ毎に、どのユーザには履歴を公開してどのユーザには履歴を公開しないか、アクセス履歴のパーミッションを設定するのは面倒である。そこでモード(テンプレート)を作ってパーミッション設定を一括設定することができる。図５４にモードの作成例を、図５５にモードを選択してアクセス履歴パーミッションを設定する例を示す。

図５４は、アクセス履歴パーミッションモード設定のユーザインターフェースである。例えば、追加ボタンを押すことによってコンテンツのＵＲＬ及び公開レベルを入力するためのフィールドが追加される。例えば、姉（sister）と母親(mom)の持つコンテンツに対するアクセス履歴は「公開」、それ以外(others)のコンテンツに対するアクセス履歴は「匿名」に設定されている。そして、これらの設定をモード（モード名「家族公開」）として登録することが可能である。つまり、この登録されたモードを使うことによって、コンテンツ毎に一つ一つアクセス履歴パーミッションを設定するという手間を省くことが可能である。

図５５は、アクセス履歴パーミッションモード選択のユーザインターフェースである。図５４で作成されたアクセス履歴パーミッションモード設定が選択枝一覧として表示されるので、所望のモードを選択して確定ボタンを押す。この例では、家族公開モードが選択されているので、確定ボタンを押すことで、例えば図５４でモード設定した家族公開モードのアクセス履歴パーミッション設定とすることができる。

こうして、ユーザ毎に異なるパーミッション情報をモードとして登録することで簡単にアクセス履歴パーミッションを設定することが可能である。

また、ある特定の操作をアクセス履歴パーミッション設定に対応させてもよい。図５６は、アクセス履歴パーミッション設定（マウスジャスチャ）の例を示すものであり、８００はコンテンツ表示部、８１０はアクセス履歴パーミッション設定が表示されるアクセス履歴パーミッション表示部、８１１はマウスポインタである。

また、図５６ではマウスのジェスチャをアクセス履歴パーミッション設定に対応させている。つまり、マウスで何らかの操作(例えば右→左→右)を行うと、それに対応したアクセス履歴パーミッション設定が行われる。さらにマウスのクリックをアクセス履歴パーミッション設定に対応させてもよい。例えば、クリックやダブルクリック、左クリック→右クリック→左クリック、同時クリックなどを対応付けることが可能である。これらは図５４や図５５で説明したモードを用いて設定してもよいし、前回設定したアクセス履歴パーミッションを適用してもよい。

同様に、画面のスクロールをアクセス履歴パーミッション設定に対応させてもよい。図５７は、アクセス履歴パーミッション設定（スクロールジャスチャ）の例を示し、図５７に示された８１２はスクロールキーを表す。例えばスクロールキー８１２を上→下→上と画面のスクロールを行うと、それに対応したアクセス履歴パーミッション設定が実行される。

また、キーボードや携帯電話等のキーボタンなど物理的なボタンにアクセス履歴パーミッション設定を対応させてもよい。図５８は、アクセス履歴パーミッション設定（ハードウェア）の例であり、（Ａ）は通常のコンテンツ表示部、（Ｂ）はキーボード、（Ｃ）は携帯電話を表している。図５８Ｂでは、キーボード８２０上に、アクセス履歴パーミッション設定ボタンとして、匿名設定用ボタン８２１、ＩＤ付き匿名設定用ボタン８２２、公開設定用ボタン８２３を備える。また、図５８Ｃに示す携帯電話８３０では、主面の操作ボタン群の所定のボタンをそれぞれ、アクセス履歴パーミッション設定ボタンの匿名設定用ボタン８３１、ＩＤ付き匿名設定用８３２、公開設定用８３３としている。

次にクライアントがアクセス履歴を閲覧する場合のユーザインターフェースについて、図５９〜図６７を参照して説明する。これらはすでに設定されたアクセス履歴を閲覧する場合だけでなく、自分が設定する(あるいは設定した)アクセス履歴を確認する場合にも適用することができる。

図５９は、アクセス履歴に応じてカーソル８４０の形状が、履歴公開モード８４１と匿名モード８４２に変化する例を示す。このようにアクセス履歴に応じてカーソル８４０の形状が変化するだけでなく、色やサイズを変化させてもいい。また、誰がいつアクセスしたかといった付加的な情報をカーソルの近辺に配置してもよい。また、図５９の例ではアクセス履歴パーミッション情報に応じてカーソルを変化させているが、ユーザ毎に変化させてもよい(例えばＡさんのアクセス履歴は犬の足跡、Ｂさんのアクセス履歴は鳥の足跡など)。

図６０及び図６１は、それぞれコンテンツ表示部８００以外の場所へアクセス履歴を表示する例を示している。図６０においてはコンテンツ表示部８００のフレーム中にアクセス履歴表示部８５０を設けて公開レベル、この例では匿名を表示している。また図６１は、フレーム自体をアクセス履歴表示部８５１とし、フレームの色によってアクセス履歴を確認できるようにしている。このようにコンテンツとは別の場所へ表示することによって、もしくはコンテンツ以外の外観を変更することによって、コンテンツ自体のデザインや見易さを損なうことなくアクセス履歴を閲覧することができる。

一方、図６２はアクセス履歴をコンテンツ表示部８００に重ねて表示する例を示す。アクセス履歴表示マーク８５２をコンテンツ表示部８００と重畳させることによってコンテンツのどの部分にアクセスしたか閲覧できるという利点がある。

また、図６３は〜図６５に示すように、コンテンツの文字のフォントや修飾、背景、画像などコンテンツ自体を変化させてアクセス履歴を表示してもよい。これらはコンテンツ全体を変化させてもいいし、一部を変化させてもよい。

図６３は、コンテンツの文字変化によるアクセス履歴表示の例を示し、（Ａ）は匿名モード、（Ｂ）は履歴公開モードである。コンテンツ表示部８００に表示された文字のフォントが変化している。

図６４は、コンテンツの背景の変化によるアクセス履歴表示の例を示し、（Ａ）は匿名モード、（Ｂ）は履歴公開モードである。図６４Ｂに斜線で示されるように、コンテンツ背景が変化している。

図６５は、コンテンツ自体の変化によるアクセス履歴表示の例を示し、（Ａ）は匿名モード、（Ｂ）は履歴公開モードである。図６４Ａに斜線で示されるように、この例では写真８５３のコンテンツの色が変化している。

また、図６６は、閲覧しているコンテンツ自体ではなく、コンテンツ内のリンクに対するアクセス履歴を表示する例を示すものである。図６６Ａはリンク先の履歴を公開した例であり、公開しているリンク先へのリンク部８６０にカーソル８４１ａを移動させると猫の足跡になる。また、図６６Ｂはリンク先の履歴を非公開とした例であり、非公開のリンク先へのリンク部８６１にカーソル８４２ａを移動させると矢印表示となる。このようにリンク先のアクセス履歴が予めわかることによって、複数のユーザが閲覧したコンテンツを簡単に見つけることができる。

また、時間によりアクセス履歴の表示を変更してもよい。例えば、アクセスした時間から経過するにつれ、図６７Ａに示したアクセス履歴表示マーク８５２ａが図６７Ｂに示すアクセス履歴マーク８５２ｂとなるように、表示の大きさを小さくし不必要になったアクセス履歴を表示しなくする。あるいは、表示アイコンの透明度を変更してもよい。さらにアクセス履歴保存部に蓄積された情報自体、時間で消去してもよい。

以上、説明してきた表示方法はクライアントが閲覧するときにどの表示方法を用いるか設定することができる。もしくはアクセスしたユーザ毎に表示方法を設定してもよい。例えば、自分が残したアクセス履歴に関してはマウスの形状を変更して表示し、友達や家族の残したアクセス履歴はコンテンツ上に、他人の残したアクセス履歴はコンテンツ外に表示する。

あるいは、逆にアクセス履歴を残すクライアントが自分の履歴がどう表示されるか設定してもよい。例えば、コンテンツ上に自分の顔写真をアクセス履歴として残すように設定することができる。

以上、図４３〜図６７を用いて説明した実施の形態によれば、コンテンツへのアクセス履歴をコンテンツ所有者や他の閲覧者へ通知することができる。更には、アクセス履歴の開示レベルを設定することによって、実名を公開したり、匿名性を維持したりでき、コミュニケーションの密度を変更することが可能となる。

なお、上述した図２５及び図３６のシステムにおける重要度判定機能において、図９に示した重要度判定機能を適用してもよいし、あるいは併用するようにしてもよい。

また、本発明は上述した実施の形態の例に限られるものではなく、本発明の要旨を逸脱することなくその他種々の構成を取り得ることは勿論である。

コンテンツ共有システムの概要を説明するための図である。 コンテンツコンテナ表示画面の一例を示す図である。 図１のコンテンツ管理部の構成を示す図である。 図1のコンテンツデータ部のデータ構成を示す図である。 コンテンツコンテナのデータ格納構造の一例を示す図である。 投稿コマンド処理を示すフローチャートである。 閲覧コマンド処理を示すフローチャートである。 コメントコマンド処理を示すフローチャートである。 本発明の一実施の形態の例のシステム構成を示す図である。 本発明の一実施の形態の投稿履歴を示す図である。 本発明の一実施の形態の閲覧履歴を示す図である。 本発明の一実施の形態の新規投稿コンテンツに対するユーザへの通知処理を示すフローチャートである 本発明の一実施の形態のユーザ設定情報を示す図である。 本発明の一実施の形態の類似した嗜好を持つユーザのコンテンツ処理を示すフローチャートである。 本発明の一実施の形態の類似した嗜好を持つユーザのコンテンツ表示例（その１）を示す図である。 本発明の一実施の形態の類似した嗜好を持つユーザのコンテンツ表示例（その２）を示す図である。 本発明の一実施の形態のグループ内の人脈関係の表示処理を示すフローチャートである。 本発明の一実施の形態の客観的人脈関係の例を示す図である。 本発明の一実施の形態のプロフィール情報（所属情報）の例を示す図である。 本発明の一実施の形態のユーザ間（ユーザＡとユーザＢ）の関係抽出処理を示すフローチャートである。 本発明の一実施の形態のユーザの環境情報を用いた重要度判定処理を示すフローチャートである。 本発明の一実施の形態のユーザの現在位置情報を示す図である。 本発明の一実施の形態の位置情報が含まれたコンテンツデータを示す図である。 本発明の一実施の形態の位置情報を用いた重要度の計算結果を示す図である。 本発明の他の実施の形態のシステム構成を示す図である。 本発明の他の実施の形態の通知メッセージ例を示す図である。 本発明の他の実施の形態の通知ルール（クライアント毎に持つ場合）を示す図である。 本発明の他の実施の形態の通知ルール（一つのクライアントに複数の通知ルールがある場合）を示す図である。 本発明の他の実施の形態の通知発行部の基本処理を示すフローチャートである。 本発明の他の実施の形態のメールでアクティブ状態変更処理を示すフローチャートである。 本発明の他の実施の形態の重要度閾値変更スライドバーの例を示す図である。 本発明の他の実施の形態の重要度閾値変更ジョグダイアルの例を示す図である。 本発明の他の実施の形態のテンキーによる重要度閾値変更の説明図である。 本発明の他の実施の形態のボタンの長押しによる重要度閾値変更の説明図である。 本発明の他の実施の形態のコンテンツコンテナ表示画面の一例を示す図である。 本発明のさらに他の実施の形態のシステム構成を示す図である。 本発明のさらに他の実施の形態のユーザ嗜好データ例を示す図である。 本発明のさらに他の実施の形態のユーザお勧め度データ例を示す図である。 本発明のさらに他の実施の形態の興味度スライダーの例を示す図である。 本発明のさらに他の実施の形態のお勧め度設定例を示す図である。 本発明のさらに他の実施の形態のお勧め度スライダーの例を示す図である。 本発明のさらに他の実施の形態のアクション設定の例を示す図である。 本発明のさらに他の実施の形態のシステム構成を示す図である。 本発明のさらに他の実施の形態のアクセス履歴データを示す図である。 本発明のさらに他の実施の形態のパーミッションテーブルを示す図である。 本発明のさらに他の実施の形態のユーザテーブルを示す図である。 本発明のさらに他の実施の形態のユーザグループテーブルを示す図である。 本発明のさらに他の実施の形態のＨＴＴＰヘッダ拡張例を示す図である。 本発明のさらに他の実施の形態のＨＴＴＰマルチパートポストの例を示す図である。 本発明のさらに他の実施の形態のアクセス履歴登録シーケンスを示す図である。 本発明のさらに他の実施の形態のアクセス履歴閲覧シーケンスを示す図である。 本発明のさらに他の実施の形態のクライアントユーザインターフェースの例を示す図である。 本発明のさらに他の実施の形態のアクセス履歴パーミッション設定を示す図である。 本発明のさらに他の実施の形態のアクセス履歴パーミッションモード設定を示す図である。 本発明のさらに他の実施の形態のアクセス履歴パーミッションモード選択を示す図である。 本発明のさらに他の実施の形態のアクセス履歴パーミッション設定（マウスジェスチャ）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴パーミッション設定（スクロールジェスチャ）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴パーミッション設定（ハードウェア）を示す図である 本発明のさらに他の実施の形態のアクセス履歴表示（カーソル）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（コンテンツ表示部以外−１）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（コンテンツ表示部以外−１）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（コンテンツ表示部に重畳表示）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（コンテンツの文字を変化）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（コンテンツの背景）を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（コンテンツ自体）を示す図である。 本発明のさらに他の実施の形態のリンク先のアクセス履歴表示を示す図である。 本発明のさらに他の実施の形態のアクセス履歴表示（時間で変化）を示す図である。

符号の説明

１００，１０１…クライアント、 ２００…コンテンツ管理部、２０２…コンテンツ保存部（コンテンツデータ部）、２１０…重要度判定部、２１０ａ…第１判定部、２１０ｂ…第２判定部、２１０ｃ…第３判定部、２１４…制御部、２２０…キーワード抽出部、２３０…表示内容決定部、２４０…ユーザ情報管理部、２６０…ユーザ設定情報管理部、２６１…ユーザ設定情報保存部、２５０…履歴情報管理部、２５１…履歴情報保存部、３００…表示構成部、４００…通知発行部、４１０…通知制御部、４２０…通知ルール保存部、４３０…クライアント状態判定部、４４０…通知ルール設定部、５００…コンテンツ重要度判定部、６００…外部アプリケーション連携部、６１０…メール、６２０…インスタントメッセンジャー、６３０…電話、６５０…コミュニケーション履歴データ保存部、７００…コンテンツ共有部、７１０…制御部、７２０…コンテンツ保存部、７３０…アクセス履歴保存部、７４０…外部インターフェース、８００…表示部、８０１…アクセス履歴パーミッション設定ボタン、８０２…アクセス履歴パーミッション詳細設定ボタン、８１０…アクセス履歴パーミッション表示部、８１１，８４１，８４１ａ，８４２…マウスポインタ、８１２…スクロールキー、８２１，８３１…匿名ボタン、８２２，８３２…ＩＤ付き匿名ボタン、８２３，８３３…公開ボタン、８３０…携帯電話、８５０，８５１…アクセス履歴表示部

Claims (86)

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. あるクライアントへ一度通知した後は、他のクライアントへは通知しないように通知ルールを変更する
    ことを特徴とする請求項６７記載のコンテンツ重要度判定方法。
82. 前記通知メッセージには有効期限が設定されており、前記有効期限内に通知されない場合、通知準備していた通知メッセージを無効とする
    ことを特徴とする請求項６７記載のコンテンツ重要度判定方法。
83. 前記クライアントの種類や外部アプリケーションの種類に応じて、通知メッセージの内容を変更する
    ことを特徴とする請求項６７記載のコンテンツ重要度判定方法。
84. 前記コンテンツの重要度に応じて前記クライアントでの通知方式を変更する
    ことを特徴とする請求項６７記載のコンテンツ重要度判定方法。
85. コンテンツデータ及び各コンテンツに関するアクセス権限データを保存し、
    前記クライアントからの要求コマンドの履歴が記録されたアクセス履歴テーブルと、開示対象ユーザと開示レベルからなるパーミッション情報が記録されたパーミッションテーブルと、ユーザデータテーブルと、ユーザグループデータテーブルとを保存し、
    前記コンテンツについて所定の処理を行うとともに、そのコマンドの履歴をアクセス履歴保存部に保存し、
    前記クライアントがコンテンツアクセス履歴のパーミッション情報を設定する
    ことを特徴とする請求項４４記載のコンテンツ重要度判定方法。
86. 前記パーミッション情報に、アクセス履歴を読むことができる対象を含む
    ことを特徴とする請求項８５記載のコンテンツ重要度判定方法。

Images