(57)【特許請求の範囲】
【請求項１】
ユーザが使用するクライアント・コンピュータが接続され、該ユーザの嗜好をマッチングするシステムであって、
記憶手段と、
嗜好情報を含む複数のユーザのプロファイルを前記記憶手段に保存する手段と、
前記嗜好情報を公開を許可するかどうかのポリシー情報を、前記複数のユーザ毎に、前記記憶手段に保存する手段と、
前記保存されている第１のユーザのプロファイルの嗜好情報を、前記保存されている第２のユーザのプロファイルの嗜好情報と比較する手段と、
前記第２のユーザのプロファイルに、前記第１のユーザのプロファイルがもつ嗜好情報と合致する嗜好情報が含まれており、且つ、前記ポリシー情報が、該合致する嗜好情報の公開を許可することに応答して、前記第１のユーザのプロファイルをもつユーザの前記クライアント・コンピュータに対して、前記合致する嗜好情報を公開する手段とを有し、
前記嗜好情報が、特定の対象を好き、または嫌いの情報を含み、前記嗜好情報の合致は、対象の合致且つ好き嫌いの合致であり、
対象の語の上位概念の語を含むシソーラスをもち、該シソーラスの上位概念の語の情報を用いて前記嗜好の合致を判断する手段と、
複数のユーザからなるグループを指定する手段と、
前記ポリシーが前記第１ユーザのプロファイルの嗜好情報の公開を許可することに応答して該嗜好情報を、前記グループにおける各ユーザのプロファイルの嗜好情報に比較し、合致する嗜好情報をもつユーザが、所定比率以上であることに応答して、前記第１のユーザのプロファイルの嗜好情報を前記グループにおける各ユーザに公開する手段をさらに有する、
嗜好マッチング・システム。
【請求項２】
コンピュータにより、記憶手段に記憶されたユーザの嗜好情報をマッチングする方法であって、該コンピュータには、ユーザが使用するクライアント・コンピュータが接続され、
嗜好情報を含む複数のユーザのプロファイルを前記記憶手段に保存するステップと、
前記嗜好情報を公開を許可するかどうかのポリシー情報を、前記複数のユーザ毎に、前記記憶手段に保存するステップと、
前記保存されている第１のユーザのプロファイルの嗜好情報を、前記保存されている第２のユーザのプロファイルの嗜好情報と比較するステップと、
前記第２のユーザのプロファイルに、前記第１のユーザのプロファイルと合致する嗜好情報が含まれており、且つ、前記ポリシーが、該合致する嗜好情報の公開を許可することに応答して、前記第１のユーザのプロファイルをもつユーザの前記クライアント・コンピュータに対して、前記合致する嗜好情報を公開するステップとを有し、
前記嗜好情報が、特定の対象を好き、または嫌いの情報を含み、前記嗜好情報の合致は、対象の合致且つ好き嫌いの合致であり、
対象の語の上位概念の語を含むシソーラスを用いて、該シソーラスの上位概念の語を用いて前記嗜好の合致を判断するステップと、
複数のユーザからなるグループを指定するステップと、
前記ポリシー情報が前記第１のユーザのプロファイルの嗜好情報の公開を許可することに応答して該嗜好情報を、前記グループにおける各ユーザのプロファイルの嗜好情報と比較し、合致する嗜好情報をもつユーザが、所定比率以上であることに応答して、前記第１のユーザのプロファイルの嗜好情報を前記グループにおける各ユーザに公開するステップをさらに有する、
嗜好マッチング方法。
【請求項３】
コンピュータにより、記憶手段に記憶されたユーザの嗜好をマッチングするシステムにおいて、該コンピュータには、ユーザが使用するクライアント・コンピュータが接続され、
前記コンピュータに、
嗜好情報を含む複数のユーザのプロファイルを前記記憶手段に保存するステップと、
前記嗜好情報を公開を許可するかどうかのポリシー情報を、前記複数のユーザ毎に、前記記憶手段に設定するステップと、
前記保存されている第１のユーザのプロファイルの嗜好情報を、前記保存されているプロファイルのうちの第２のユーザのプロファイルの嗜好情報と比較するステップと、
前記第２のユーザのプロファイルに、前記第１のユーザのプロファイルと合致する嗜好情報が含まれており、且つ、前記ポリシーが、該合致する嗜好情報の公開を許可することに応答して、前記第１のユーザのプロファイルをもつユーザの前記クライアント・コンピュータに対して、前記合致する嗜好情報を公開するステップを実行させ、
前記嗜好情報が、特定の対象を好き、または嫌いの情報を含み、前記嗜好情報の合致は、対象の合致且つ好き嫌いの合致であり、
対象の語の上位概念の語を含むシソーラスを用いて、該シソーラスの上位概念の語を用いて前記嗜好の合致を判断するステップと、
複数のユーザからなるグループを指定するステップと、
前記ポリシーが前記第１のユーザのプロファイルの嗜好情報の公開を許可することに応答して該嗜好情報を、前記グループにおける各ユーザのプロファイルの嗜好情報に比較し、合致する嗜好情報をもつユーザが、所定比率以上であることに応答して、前記第１のユーザのプロファイルの嗜好情報を前記グループにおける各ユーザに公開するステップをさらに実行させる、
プログラム。
【請求項４】
ネットワークを介して、複数のクライアント・コンピュータが接続された、サーバ・システムにおいて、
前記クライアント・コンピュータのユーザの嗜好情報を格納する手段と、
前記ユーザ毎の、嗜好情報の公開に関する条件を含むプライバシー・ポリシー情報を格納する手段と、
前記ユーザのうちの第１のユーザからの、第２のユーザに対する嗜好情報問合せに応答して前記第１のユーザの嗜好情報と前記第２のユーザの嗜好情報とを比較し、前記第１のユーザの嗜好情報に、前記第２のユーザの嗜好情報と合致する嗜好情報が含まれ且つ、前記第１のユーザのプライバシー・ポリシー情報に前記合致する嗜好情報が公開されることが指定されていることに応答して、前記第２のユーザの前記クライアントコンピュータに、前記合致する嗜好情報を公開する手段とを有し、
前記嗜好情報が、特定の対象を好き、または嫌いの情報を含み、前記嗜好情報の合致は、対象の合致且つ好き嫌いの合致であり、
対象の語の上位概念の語を含むシソーラスをもち、該シソーラスの上位概念の語を用いて前記嗜好の合致を判断する手段と、
複数のユーザからなるグループを指定する手段と、
前記ポリシーが前記第１のユーザのプロファイルの嗜好情報の公開を許可することに応答して該嗜好情報を、前記グループにおける各ユーザのプロファイルの嗜好情報に比較し、合致する嗜好情報をもつユーザが、所定比率以上であることに応答して、前記第１のユーザのプロファイルの嗜好情報を前記グループにおける各ユーザに公開する手段とをさらに有する、
サーバ・システム。
【請求項５】
前記サーバ・システムが、仮想空間サーバ・システムであり、前記ユーザは、該仮想空間サーバにおいて、アバタを操作する、請求項４のサーバ・システム。
【請求項６】
前記サーバ・システムが、インスタント・メッセージング・サーバ・システムであり、前記嗜好情報は、前記クライアント・コンピュータのインスタント・メッセージング・システムのメッセージング・ウインドウ上で提示される、請求項４のサーバ・システム。
【請求項７】
前記サーバ・システムが、ソーシャル・ネットワーキング・サービス・サーバシステムであり、前記グループが、該ソーシャル・ネットワーキング・サービスにおけるコミュニティを構成する、請求項４のサーバ・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ソーシャル・ネットワーキング・サービス（ＳＮＳ）、仮想空間など、オンライン・ネットワーク上で、複数のユーザが対話したり、交信したりする環境において、ユーザの嗜好を公開するためのシステム、方法及びプログラムに関するものである。
【０００２】
この発明は、より具体的には、ユーザの指定した態様で、他のユーザに趣味または嗜好を公開する技法に関するものである。
【背景技術】
【０００３】
オンライン上でのコミュニケーション手段が発達するにつれて、プライバシーの保護が重要な問題になってきている。その際、趣味や嗜好は、プライバシーの重要な要素を占める。従って、人は、自分の趣味や嗜好を無防備に他人に公開してよいとは、普通思わない。
【０００４】
一方で、趣味や嗜好などはプライバシーとして個人に属していることと同時に、人同士のコミュニケーションにおいて嗜好を共有することは重要である。すなわち、初めて会った人と話をする場面において、その相手の嗜好と自分の嗜好の一致しているところ、一致していないところがわかれば、話のきっかけを得やすい。
【０００５】
従来技術では、このようなことを解決するために、プロファイルなどに自分で趣味や嗜好を記述しておき、それをシステム的に参照しあうという方法や、検索やマッチングに利用するという手法をとってきた。また、ユーザーの行動履歴（発言履歴、ブログへの書き込み、メール）などから、嗜好情報を抽出し付与する方法も知られている。これには、単純に対象となる名詞を抜き出す方法と、対象物とともにその対象物に対する評価などを一緒に抽出する方法がある。しかし、ユーザーは一般に公開している文章や公共の場で行った発言（チャットなど）であっても、それを読む対象の相手によって発言を変えているため、その対象から外れた人に情報を知られたくない。そのため、嗜好を抽出するもとの内容自体は公開されていたとしても、自動で抽出される嗜好情報をすべて公開することには心理的抵抗がある。
【０００６】
そのような心理的抵抗がある人のために、情報の公開ポリシーを決めるという方法が知られている。この方法によれば、公開ポリシーの記述により、他人に対する嗜好情報の公開・非公開を決めることができるが、開示する相手としてを一人一人（あるはそのグループ）を指定するなどの方法をとるしかなく、今まで存在を知らないユーザーに対しては非公開とするか公開とするか２値の判断しかできない。このような方法では、未知の第三者との交流の際に嗜好情報を利用したいという状況に適切に対応できない。
【０００７】
特開平１１−３４５２４８号公報は、ユーザの嗜好にマッチする情報を選択する際に必要となるユーザのプロフィール情報が不測に公開されてプライバシーが損なわれることを防止することを課題とするものであって、ＩＣカードに記録されているユーザのプロフィール情報を、端末機によって読取って、ホストコンピュータへ伝送し、ホストコンピュータは、伝送されてきたプロフィール情報に基づいて伝送されてきた提供情報（商品情報）を選択してユーザの嗜好にマッチする提供情報をユーザの端末機へ伝送して提供する技術を開示する。この際、ＩＣカードに記録されているプロフィール情報は、秘密の度合に従ってＡ、Ｂ、Ｃのランク分けがなされており、当該ユーザの操作に従ってどのランクまでのプロフィール情報の公表を許容するかを入力設定可能である。
【０００８】
特開２００２−１０８９２０号公報は、利用者のプライバシーを守りつつ、該利用者の好みに適応したサービスを受けることが可能な情報提供方法を提供することを目的とするものであって、利用者の個人情報は、ポータルサイトサーバにおける利用者情報管理部において管理し、利用者端末から、情報サイトサーバに対して情報の要求が行われた際には、ポータルサイトサーバから情報サイトサーバに向けて、該当利用者の趣味や嗜好などの内容を含んだ個人情報が送信され、情報サイトサーバは、受信した個人情報に適応した内容の情報を利用者端末に対して送信するようにすることを開示する。
【０００９】
特開２００７−１０２６３５号公報は、コミュニティ属性と、エンドユーザのコミュニティ属性に関わる嗜好のマッチングに基づき、コミュニケーションの場として各エンドユーザ毎に適切なブログ・コミュニティを推薦することを目的とするものであって、ブログ・コミュニティ分析装置において、コミュニティ定義情報に基づいてコミュニティを構成する各ブログのコンテンツを分析して、規模、活発度、開放度のいずれか１つ以上のコミュニティの属性情報を算出して、コミュニティ推薦条件に合致するブログ・コミュニティ情報を検索し、検索結果として得られたコミュニティ情報を、コミュニティ情報をエンドユーザ端末からのリクエストに応じて画面表示させることを開示する。
【００１０】
これらの従来技術によれば、嗜好情報などのプロファイル情報が他人に漏れることを防止することができるが、未知の第三者に対して、嗜好情報の公開または非公開を適切にコントロールすることは依然として不可能である。
【特許文献１】特開平１１−３４５２４８号公報
【特許文献２】特開２００２−１０８９２０号公報
【特許文献３】特開２００７−１０２６３５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、ユーザが自分の嗜好情報の個々の要素につき、公開・非公開を設定できるようにする技術を提供することにある。
【００１２】
本発明の他の目的は、他のユーザまたはユーザのグループのもつ嗜好情報に依存して、ユーザが自分の嗜好情報の公開・非公開を設定できるようにする技術を提供することにある。
【課題を解決するための手段】
【００１３】
上記目的は、本発明に従い、ユーザーの行動履歴（発言履歴や文書の書き込み履歴、行動など）から抜き出した嗜好情報を、ポリシー文書によってプライバシーの公開する範囲をユーザーが自分で設定し、公開することで実現される。
【００１４】
本発明は、典型的には、次の２つのシステムを有する。第１のシステムは、文書またはユーザーの自分の公開した情報から嗜好情報を抽出しそれを管理するシステム、すなわち、プロファイル管理システムである。このシステムは嗜好情報抽出部、嗜好情報蓄積部からなる。このシステムにより、ユーザーは自分の履歴から取り出した嗜好情報をどのレベルまで外部に公開するかを、プライバシーポリシーによって決定することができる。
【００１５】
第２のシステムは、あるユーザーの嗜好情報と他のユーザーの嗜好情報をマッチングして、他のユーザー情報を取得するシステムである。このシステムは、コミュニケーション空間を管理するコミュニケーション空間管理部、個人のプライバシーを管理するプライバシーポリシー蓄積部、そしてこのプライバシーポリシーを適用するポリシー適用部からなる。このシステムでは、自分の履歴から取り出した嗜好情報のうち、上記プライバシーポリシーに基づき、何を誰に公開するかを決定する。このシステムにより、特定の人物の嗜好を知ったり、自分の嗜好に合った人物を検索したりすることが可能となる。
【００１６】
本発明において、ユーザーの嗜好情報とは、対象物とそれに対する嗜好（および「好き」「気に入っている」というポジティブな嗜好感情とだけではなく、ネガティブ（「嫌い」「苦手」というネガティブな嗜好）も含み得る。これらの嗜好情報は、既存の評判分析などの手法を用いて抽出することも可能であるし、またユーザー本人がプロファイルを作成することもできる。
【００１７】
本発明によれば、嗜好情報に対して、嗜好情報を公開のポリシーを記述した管理するプライバシーポリシーを適応することによっては、マッチングシステムによってマッチした結果による分類で、、その情報を第三者に対して公開・非公開するかどうかが決定される。このプライバシーポリシーの例としては、以下のようなものが考えられる。
１． 問い合わせのあったユーザに対して、そのユーザの嗜好と一致する嗜好情報のみ公開する。
２． ある部屋にいる複数のユーザに対して、その中で自分と共通して持つ嗜好情報のみ公開する。
【００１８】
このようなプライバシーポリシーを設定することによって、他のユーザと一致した嗜好の嗜好情報のみ公開することを許し、そうでない人には非公開とすることより、第三者で、その嗜好には一致しない人にその嗜好情報が公開されることはない。
【００１９】
また、プライバシーポリシーを自分で記述することにより、一致していなくても公開する、あるいは一致していても公開しないなど公開のレベルを自分で設定することも可能である。また、自分の行動履歴から作られたプロファイルは参照可能であり、どのような嗜好情報が存在するか、嗜好情報の対象物はなにか、を参照することもできる。それらの情報を用い、プライバシーポリシーの記述には対象物の情報も用いることができる。例えば、既存のシソーラスを用いて、その同義語のグループの一部分が対象物となっているときは公開しないようにすることができる。また、例えば、シソーラスが木構造であるなら、あるノード以下にある単語が対象物となっているときは公開しない、という指定方法も実施可能である。
【発明の効果】
【００２０】
この発明によれば、プライバシーポリシーの記述によって、相手ユーザと一致する嗜好の嗜好情報のみ公開したり、あるユーザのグループ内にいるとき、その中で共通して持つ嗜好情報のみ公開するなど、公開したくない嗜好情報は非公開のまま維持しつつ、意図する限定した、きめ細かい範囲で相手に嗜好情報を公開して、有意義なコミュニケーションを図ることが可能となる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を参照して、本発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。また、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことを理解されたい。
【００２２】
この発明は、ＳＮＳ、仮想空間、通常のチャット・システムなど、ネットワーク上でユーザ同士が対話する任意のシステムに適用可能であるが、一例として、仮想空間サーバの例により説明する。図１は、この実施例の前提となる、仮想空間サーバの概要構成の全体を示す図である。図１において、仮想空間サーバ１０２には、インターネット１０４を介して、複数のクライアント・コンピュータ１０６ａ、１０６ｂ・・・１０６ｚが接続されている。
【００２３】
図１のシステムにおいては、クライアント・コンピュータのユーザは、Ｗｅｂブラウザまたは、仮想空間サーバ１０２からダウンロードした専用の仮想空間ブラウザを通じて、インターネット１０４の回線を介して、仮想空間サーバ１０２に、ログインする。
【００２４】
ログインに当たっては、クライアント・コンピュータのユーザは、与えられたユーザＩＤと、それに関連付けられたパスワードを用いる。クライアント・コンピュータのユーザは、一旦ログインすると、予め自分で決めておいたアバタ（図１には示さない）を使って、仮想空間内を移動して、さまざまな施設を訪れたり、他のアバタと、チャットしてコミュニケーションをはかったりすることができる。
【００２５】
次に、図２を参照して、図１で参照番号１０６ａ、１０６ｂ・・・１０６ｚのように示されているクライアント・コンピュータのハードウェア・ブロック図について、説明する。
【００２６】
図２において、クライアント・コンピュータは、メイン・メモリ２０６、ＣＰＵ２０４、ＩＤＥコントローラ２０８をもち、これらは、バス２０２に接続されている。バス２０２には更に、ディスプレイ・コントローラ２１４と、通信インターフェース２１８と、ＵＳＢインターフェース２２０と、オーディオ・インターフェース２２２と、キーボード・マウス・コントローラ２２８が接続されている。ＩＤＥコントローラ２０８には、ハードディスク２１０と、ＤＶＤドライブ２１２が接続されている。ＤＶＤドライブ２１２は、必要に応じて、ＣＤ−ＲＯＭやＤＶＤから、プログラムを導入するために使用する。ディスプレイ・コントローラ２１４には、好適には、ＬＣＤ画面をもつディスプレイ装置２１６が接続されている。ディスプレイ装置２１６には、接続されている仮想空間サーバから送られているアバタやオブジェクトなどが、レンダリング表示される。この実施例では、レンダリングは、サーバ側でなく、クライアント側で行われる。
【００２７】
ＵＳＢインターフェース２２０には、必要に応じて、特殊なボタンをもつ専用コントローラ、加速度センサ・デバイスなどが接続され、仮想空間内でアバタを便利に操作するために使用される。
【００２８】
オーディオ・インターフェース２２２には、スピーカ２２４と、マイク２２６が接続されている。このクライアント・コンピュータに、音声合成機能を備えることにより、仮想空間内で、相手のアバタのチャット内容を、スピーカ２２４から音声化して出力することができる。また、さらに、音声認識機能を備えることにより、仮想空間内で、ユーザがマイク２２６に向かってしゃべった内容を、音声認識機能によってテキスト化し、相手のアバタに対して、チャットの内容として送出するようにすることができる。
【００２９】
キーボード・マウス・コントローラ２２８には、キーボード２３０と、マウス２３２が接続されている。キーボード２３０は、典型的には、仮想空間内で、チャットのメッセージを書くために使用される。また、キーボード２３０は、専用コントローラを使わない場合、アバタをジャンプさせたり、進めたりするためにも使用される。マウス２３２は、仮想空間内で、メニューから動作を選択し実行したり、仮想空間内のオブジェクトの属性を確認したりセットするために使用される。
【００３０】
ＣＰＵ２０４は、例えば、３２ビット・アーキテクチャまたは６４ビット・アーキテクチャに基づく任意のものでよく、インテル社のＰｅｎｔｉｕｍ（商標）４、ＡＭＤ社のＡｔｈｌｏｎ（商標）などを使用することができる。
【００３１】
ハードディスク２１０には、少なくとも、オペレーティング・システムと、オペレーティング・システム上で動作する仮想空間ブラウザ（図示しない）が格納されており、システムの起動時に、オペレーティング・システムは、メインメモリ２０６にロードされる。オペレーティング・システムは、Ｗｉｎｄｏｗｓ  ＸＰ（商標）、Ｗｉｎｄｏｗｓ  Ｖｉｓｔａ（商標）、Ｌｉｎｕｘ（商標）などを使用することができる。
【００３２】
通信インターフェース２１８は、オペレーティング・システムが提供するＴＣＰ／ＩＰ通信機能を利用して、イーサネット（商標）・プロトコルなどにより、仮想空間サーバと、通信する。
【００３３】
図３は、仮想空間サービス・プロバイダ側のハードウェア構成の概要ブロック図である。図３に示すように、通信回線３０２には、クライアント・コンピュータ１０６が、インターネットを経由として、接続される。尚、ここで、クライアント・コンピュータ１０６は、図１のクライアント・コンピュータ１０６ａ、１０６ｂ・・１０６ｚの総称的な表示であり、実際は、クライアント・コンピュータ１０６ａ、１０６ｂ・・１０６ｚのうちのどれかである。
【００３４】
図３に示す仮想空間サーバ１０２は、島サーバ３０４ａ、３０４ｂ・・・３０４ｚと、管理サーバ３０６からなり、それぞれは、通信回線３０２に接続されて、互いに通信可能である。これらのサーバ間の通信は、好適には、１０００Ｍｂｐｓの１０００ＢＡＳＥ−Ｔイーサネット（商標）である。
【００３５】
管理サーバ３０６は、システム・バス３０８をもち、そのバス３０８には、ＣＰＵ３１０、主記憶３１２、ハードディスク３１４、及び通信インターフェース３１６が接続されている。図示しないが、管理サーバ３０６にはさらに、キーボード、マウス、及びディスプレイが接続され、これらによって、仮想空間サーバ１０２全体の管理やメンテナンス作業をしてもよく、あるいは、これも図示しないが、通信回線３０２に接続されたコンピュータによって、仮想空間サーバ１０２全体の管理を行うようにしてもよい。
【００３６】
管理サーバ３０６のハードディスク３１４には、オペレーティング・システム、クライアント・コンピュータ１０６のログイン管理のための、ユーザＩＤとパスワードの対応テーブル、及び後で詳しく説明するが、嗜好情報を含むユーザ毎のプロファイル、プライバシーポリシー、更には、プライバシーポリシーに基づく、嗜好情報の管理用モジュール等が格納されている。
【００３７】
島サーバ３０４ａ、３０４ｂ・・・３０４ｚは、それぞれ、仮想空間内で、例えば２５６ｍ×２５６ｍの島（ＳＩＭ、あるいはシムとも呼ばれる）を管理するサーバである。個々の島は、特定のユーザが、仮想空間の管理者から購入し、あるいは、賃借し、専用の島サーバにより、オーナとしてのユーザが、独自のオブジェクトとアクセス管理を実現している。このように、個々の島を個別のサーバで管理することは、仮想空間の拡張が、島サーバの追加だけで行えるので、スケーラビリティの点で好ましい。しかし、本発明は、特に、このような複数の島からなる仮想空間に限定される訳ではなく、複数のユーザがコミュニケーションを図ることのできる任意の形態の仮想空間に適用可能である。
【００３８】
また、後述するが、仮想空間だけではなく、インターネット上のソーシャル・ネットワーキング・サービス、通常のチャットなど、ネットワーク上で複数のユーザがメッセージを取り交わす任意のシステムに適用可能である。
【００３９】
尚、上記の管理サーバ及び島サーバとして、これらに限定されないが、インターナョナル・ビジネス・マシーンズ・コーポレーションから購入可能な、ＩＢＭ（商標）Ｓｙｓｔｅｍ  Ｘ、Ｓｙｓｔｅｍ  ｉ、Ｓｙｓｔｅｍ  ｐなどのサーバを使うことができる。
【００４０】
次に、図４を参照して、本発明に関する主要な処理を行うサブシステム（モジュールとも呼ぶ）の機能と、それらの間の関係について、説明する。そのサブシステムは、嗜好情報抽出部４０２、嗜好情報蓄積部４０４、プライバシーポリシー蓄積部４０６、コミュニケーション空間情報管理部４０８、及びポリシー適用部４１０からなる。これらのサブシステムは、好適には、管理サーバ３０６（図３）のハードディスク３１４に格納され複数のユーザによってアクセス可能であり、必要に応じて、オペレーティング・システムの作用によって、主記憶３１２にロードされ、ＣＰＵ３１０によって実行される。
【００４１】
嗜好情報抽出部４０２は、文書やユーザの行動履歴などから取得した嗜好情報を取得し、嗜好情報蓄積部４０４に入力する。嗜好情報蓄積部４０４は、それらの嗜好情報を時間などのパラメーターとともにユーザごとに管理する。プライバシーポリシー蓄積部４０６には、ユーザが各々のプライバシーの公開のポリシーを記述し、入力・管理する。コミュニケーション空間情報管理部４０８は、ユーザが操作するアバタが存在するコミュニケーション空間情報（例えば、仮想空間内のある建物の部屋など）を動的に保持し、どのようなユーザが、その空間内にいるのかの情報を提供する。嗜好情報マッチングポリシー適用部４１０は、コミュニケーション空間情報管理部４０８から取得したコミュニケーション空間情報に基づき、２人あるいは複数人のユーザーの嗜好情報とプライバシーポリシーをそれぞれのシステムから取得し、適用マッチングする。結果として、ユーザーあるいは第三者に対して、嗜好情報を返す。
【００４２】
次に、上記各サブシステムの詳細について、説明する。
【００４３】
［嗜好情報抽出部］
嗜好情報抽出部４０２には、嗜好情報をどのように抽出するか、またその嗜好情報をどのように利用するかが、記述される。嗜好情報とは、嗜好の対象となる対象物と、それに対する好き・嫌いなどの嗜好をペアとして持つ情報である。
【００４４】
嗜好情報抽出部４０２は、公開されている情報からある人物Ｘに対する嗜好情報を抽出する。この公開されている情報とは、嗜好情報の抽出となる情報源であり、ブログなど公開されている情報源、あるいは、個人のメールボックス、パーソナル・コンピュータ中のファイルなど非公開の情報も、許諾があれば、対象とすることが可能である。また、行動履歴（ログ）ファイルなども対象にすることが可能である。ただ、この場合、誰の嗜好情報なのかを特定するために、誰の行動履歴・発言なのか特定できる必要がある。
【００４５】
嗜好情報抽出部４０２は、サブシステムとして、例えば、本出願人に係る特表２００５−５３０２２４に開示されているような、文書クローラと、行動履歴取得システムと、例えば、本出願人に係る特開２００６−１４６５６７に開示されているような嗜好表現解析・抽出システムを含み、あるいは呼び出して利用する。さらに、発言記録などの文書から嗜好情報を抽出する技術が、本出願人に係る特開２００５−２３５０１４に記述されており、嗜好情報抽出部４０２は、この技術を利用するようにしてもよい。特開２００５−２３５０１４に記述されている技術は、評判分析と呼ばれ、構文解析された文書に対し、好き・嫌いなどの属性のついた用言辞書を用いて評判に関する表現が書かれた箇所を探し出し、構文解析結果を元に、対象物を得る、というものである。
【００４６】
行動履歴からの嗜好情報抽出のための行動履歴取得システムとして、行動履歴管理システムなどによる実際の世界での行動を携帯発信機などで取得・管理したデータを利用する、特開２００６−２５２２０７に記述されている技術がある。
【００４７】
特に、この実施例に係る、仮想空間あるいは３Ｄインターネットにおいては、オブジェクトまたはアバタと、それに対する振る舞いを基に、嗜好情報を抽出することができる。例えば、あるオブジェクト（洋服、帽子など）を身に着けている期間が長い人物がいた場合を考える。この例においては、そのオブジェクトを対象物とみなし、かつ「ある一定の期間以上身につける」という行動からその人物が、そのオブジェクトを「気に入っている」という嗜好を持つと想定することもできる。
【００４８】
嗜好情報抽出部４０２により抽出される嗜好情報（Prefernce Information Object、あるいはそのアクロニムとして、PIOとも記す）は、対象物と、嗜好情報述部対象物に対するユーザーの嗜好を表現している述部を含む。PIOのXML表現としては、例えば、対象物をTargetObject、嗜好情報述部をpredicateとして、表記する。
【００４９】
<PIO>
<targetObject>animation</targetObject>
<predicate>like</predicate> 
</PIO>
【００５０】
ここで、targetObjectは、animationと、英語で表記されているが、「アニメーション」、あるいは「アニメ」と、日本語表記してもよい。また、嗜好情報述部であるpredicateのlikeも、「好き」と日本語表記してよい。
【００５１】
［嗜好情報蓄積部］
嗜好情報蓄積部４０４は、シソーラスと個人嗜好ＤＢを含み、または呼び出す。図示しないが、シソーラスと個人嗜好ＤＢは、管理サーバ３０６のハードディスク３１４に保存されている。シソーラスには、嗜好及び対象物のカテゴリ間の上位下位関係が記述されている。嗜好情報蓄積部４０４内では、PIOに、シソーラスによって与えられた対象物のカテゴリと、嗜好が付与される。PIOのXML表現としては、例えば、シソーラスによって与えられた対象物のカテゴリをtargetObjectCategory、嗜好をpreferenceとして、表記する。preferenceの値は、PositiveとNegativeのどちらかである。個人嗜好ＤＢには、個人の嗜好情報が格納され、外部からの個人の嗜好情報の問い合わせを受付可能である。その問い合わせに応答して、個人嗜好ＤＢは、PIOのリストを返す。
【００５２】
［コミュニケーション空間情報管理部］
コミュニケーション空間情報管理部４０８では、ユーザが、コミュニケーションをする空間の情報を設定し、管理するこができる。ここでいう空間とは、拡張された概念であって、いつ（時間情報）、どこで（空間情報）、誰が（ユーザ情報）存在しているか、ということを示す情報である。この情報が保持されている空間を、コミュニケーション空間と呼ぶことにする。
【００５３】
コミュニケーション空間情報管理部４０８では、嗜好情報開示要求があったときのために、嗜好情報の開示要求の種類と、嗜好情報の対象となるユーザー以外で空間を共有しているユーザーのリストを、保持する。XMLのタグとして、嗜好情報の開示要求の種類にはtype、嗜好情報の対象となるユーザー以外で空間を共有しているユーザーのリストとしては、personInfoを用いるものとする。
【００５４】
typeとは、嗜好情報の開示要求の種類であり、personとcommunicationSpaceの2種類ある。personとはあるユーザーによる別のユーザに関しての嗜好情報の公開要求を示し、communicationSpaceとは第三者あるいはそのコミュニケーション空間内のユーザによる、ある集合全体の嗜好情報の公開要求を示す。
【００５５】
このある集合とは、開示要求を出す人が決めることも可能である（ユーザーIDなどの集合を渡すことで可能である）し、コミュニケーション空間情報管理部が保持する位置情報により動的に決めることも可能である（例：あるオブジェクトの半径何メートル以内にいるユーザー）。また同時に、personInfoとして、それぞれのtypeに対し嗜好情報を比較するユーザーの情報（personの時には一人、communicationSpaceの時には複数人）を保持する。
【００５６】
［プライバシーポリシー蓄積部］
プライバシーポリシー蓄積部４０６には、個人が自分のPIOを許可、あるいは拒絶するプライバシーポリシーを記述し、蓄積することができる。privacy_policyのXMLタグは、以下の４つの基本タグからなる。
すなわち、先ず、permissionタグで、これは、プライバシー情報の開示を許可(allow) するか、拒否(deny)するかを指定する。
targetタグは、情報の開示の対象(誰・どこに対して許可・拒否するか)とその開示方法を指定する。
PIOタグは、開示する嗜好情報(何を許可・拒否するか)を指定する。
condition_listタグは、許可あるいは、拒否の条件を指定する。
【００５７】
これらのタグは、以下のようなXMLで用いられる。なお、下記で、<!- ... ->あるいは、//以下に示すのは、この実施例の説明のためのコメントで、実際の処理には、関係ない。
【００５８】
<?xml version="1.0" encoding="utf-8"?>
<!-
同じコミュニケーション空間にいる人で、嗜好が一致している人に対して
情報の開示を許可するポリシー
->
<privacy_policy_definitions> //プライバシーポリシーを定義
<pivacy_policy>//プライバシーポリシーの単位
<permission>allow</permission> //permission allow（許可）またはdeny（拒否）が入る
<target> //嗜好情報を開示する対象を指定する
<person inCommunicationSpace="yes"/> //同じコミュニケーション空間にいる人が対象であることを示す
</target>
<condition_list> //条件を表すリスト  条件にはand, or, notがある
<or> //or条件の記載
<condition>
<preference_matching type="matching affinity"/>
</condition>
<condition>
<preference_matching type="matching antipathy"/>
</condition>
</or>//or条件の記載終わり
</concition_list>
</privacy_policy>
<!-
同じコミュニケーション空間にいる人で、嗜好が一致しない人に対して
情報の開示を拒否するするポリシー
->
<pivacy_policy>
<permission>deny</permission>
<target>
<person inCommunicationSpace="yes"/>
</target>
<condition_list>
<or>
<condition><preference_matching type="opposing affinity"/></condition>
<condition><preference_matching type=" opposing antipathy"/></condition>
</or>
</condition_list>
</privacy_policy>
</privacy_policy_definitions>
<?xml version="1.0" encoding="utf-8"?>
<!-
同じCommunity Space にいる人で、嗜好が一致している人に対して
情報の開示を許可するポリシー
->
<privacy_policy_definitions>
<pivacy_policy>
<permission>allow</permission>
<target>
<person inComminitySpace="yes"/>
</target>
<condition_list>
<or>
<condition>
<preferenceMatching type="matching affinity"/>
</condition>
<condition><preferenceMatching type="matching antipathy"/></condition>
</or>
</condition_list>
</privacy_policy>
<!-
同じCommunity Space にいる人で、嗜好が一致しない人に対して
情報の開示を拒否するするポリシー
->
<pivacy_policy>
<permission>deny</permission>
<target>
<person inComminitySpace="yes"/>
</target>
<condition_list>
<or>
<condition><preferenceMatching type="opposing affinity"/></condition>
<condition><preferenceMatching type=" opposing antipathy"/></condition>
</or>
</condition_list>
</privacy_policy>
</privacy_policy_definitions>
【００５９】
上記のXMLを参考にしながら、タグについて、さらに詳しく説明する。
【００６０】
先ず、permissionタグは、許可する (allow) か、あるいは、拒否する(deny)かの２つの値のどちらかを取る。同じPIOに対して複数のポリシーが一致した場合、denyを優先するものとする。このため基本的には deny は絶対情報を開示しない場合にのみ記述する（例えば、ある特定の人には一切の情報を開示しないなど）。
【００６１】
targetタグの下に入れるタグとして、人(person) とコミュニケーション空間(communication space) の２つがある。personタグの場合は、以下の属性を保持する。
inComminucationSpaceは、同じコミュニケーション空間を共有しているかどうかを意味し、"yes" or "no"を入れる。
groupは、事前に定義されたグループのメンバーであるかどうかを示す。
roleは、事前に定義された role を持っている人かどうか。例えば、管理者(administrator) などを示す。
idは、個人を識別するIDを示す。
【００６２】
communication_spaceタグの場合は、以下の属性を保持する。
roleは、事前に定義された role を持っている人かどうかを示す。例えば、管理者(administrator) などである。
idは、コミュニケーション空間を識別するIDを示す。
【００６３】
PIOタグは、どの情報を開示するかを記述する。現在プライバシーポリシーの評価の対象となっている PIO は、変数 $currentPIO で表現されるものとする。
PIO の一致条件は、category属性に記述される。このとき、以下の関数を用いることができる。
Category(PIO o): PIO o のカテゴリを返す。
upperCategory(Category c): Category x の上位カテゴリを返す。
lowerCategory(Category c): Category c の下位カテゴリの一覧を返す。
このとき、カテゴリの階層的な構造が想定されている。
【００６４】
また、PIO タグを記述しないことにより、現在評価の対象となっている PIOを開示の対象とすることができる。
【００６５】
例として、現在評価中の PIO のカテゴリの上位カテゴリの PIO で、すべての preference_matching に対して開示の許可を行うには以下のように記述する。
<PIO category="upperCategory(category($currentPIO))" preference_matching="all"/>
【００６６】
また、PIO の公開のモードの指定として、mode属性を記述する。その値として以下が用いられる。
anonymous: ユーザーID を公開しない
named: ユーザーID を公開する（省略値）
【００６７】
condition_listタグは、以下の3つの演算子を用いたブール代数で複数の条件を組み合わせて記述する。
and: 論理輪
or:  論理積
not: 否定
【００６８】
個々の条件は、conditionタグで記述される。condition 内で記述できるタグを以下に示す。
preference_matching:タグ 嗜好情報の一致のタイプを指定する。一致のタイプは属性 type で指定され以下の４つの値を取りうる。
matching affinity: 好きであることが一致している
matching antipathy: 嫌いであることが一致している
opposing affinity: 自分が好きなものを相手が嫌い
opposing antipathy: 自分が嫌いなものを相手が好き
all: 上記のすべての場合。
【００６９】
具体的に示すために、いくつかの例を示す。
［例１］
以下の例は、カテゴリ「アニメ」の preference_matching が matching affinity である場合の条件の指定を示す。
<preference_matching type="matching affinity">
<category id="アニメ"/>
</preference_matching>
【００７０】
［例２］
"大魔神ゼット" が共通に一致していればその上位カテゴリ（「アニメ」）の嗜好情報をすべて開示することを記述したポリシーの例を以下に示す。
<pivacy_policy>
<permission>allow</permission>
<target>
<person inComminitySpace="yes"/>
</target>
<PIO category="upperCategory(category($currentPIO))" matchingPreference="all"/>
<condition_list>
<and>
<condition>
<preference_matching type="matching affinity"/>
</condition>
<condition>
<category id="大魔神ゼット"/>
</condition>
</and>
</condition_list>
</privacy_policy>
【００７１】
［例３］
コミュニケーション空間の中で、半分以上の人が「アニメ」が好きならば、「アニメ」が好きだということを コミュニケーション空間に対して開示することを記述したポリシーの例を以下に示す。
<pivacy_policy>
<permission>allow</permission>
<target>
<communication_space/>
</target>
<condition_list>
<and>
<condition>
<preference_matching type="matching affinity"/>
</condition>
<condition>
<category id="アニメ"/>
</condition>
<condition>
<minimumMatchingRatio value="0.5"/>
</condition>
</and>
</condition_list>
</privacy_policy>
外部からある個人に対するプライバシーポリシーを要求されると、このプライバシーポリシーを返す。
【００７２】
［ポリシー適用部］
ポリシー適用部４１０は、嗜好情報蓄積部４０４から取得した嗜好情報リストに対してプライバシーポリシー蓄積部から取得したプライバシーポリシーリストを適用して、公開すると判断された嗜好情報をコミュニケーション空間情報管理部に返すものである。プライバシーポリシーの適応における処理の流れを、図５のフローチャートを参照して、説明する。最初に説明する例は、個人対個人の嗜好開示要求である。
【００７３】
図５において、ステップ５０２では、ユーザ（例えば、ユーザＰ１とする）が、同じコミュニケーション空間にいる別のユーザ（例えば、ユーザＰ２とする）に対する情報を、コミュニケーション空間情報管理部４０８に要求する。コミュニケーション空間情報管理部４０８は、その要求を、ポリシー適用部４１０に送る。
【００７４】
ステップ５０４で、ポリシー適用部４１０は、ユーザＰ１とユーザＰ２の嗜好情報リスト（ＰＩＯリスト）を、嗜好情報蓄積部４０４から取得する。もし、ユーザＰ２のＰＩＯに、アクセス可能ユーザリストが設定されているなら、そのアクセス可能ユーザリストにＰ１が含まれているもののみが、収集されることになる。
【００７５】
ステップ５０６では、ユーザＰ２のプライバシーポリシーが、プライバシーポリシー蓄積部４０６から取得され、得られたユーザＰ２の個々のＰＩＯに対して、そのプライバシーポリシーが適用され、これによって、ユーザＰ１に対して公開が許されたユーザＰ２のＰＩＯのリストが求められる。この処理の詳細を、図６のフローチャートを使用して説明する。
【００７６】
図６のステップ６０２において、収集したＰＩＯリストの最初のＰＩＯに、プライバシー・ポリシーが適用される。ステップ６０２のより詳細な処理は、図７のフローチャートを参照して、後で詳細に説明する。
【００７７】
ステップ６０４では、プライバシー・ポリシーを適用済みのＰＩＯが、ＰＩＯリストから除去される。
【００７８】
ステップ６０６では、ＰＩＯリストが空かどうか判断され、空でなければ、ステップ６０２に戻る。
【００７９】
ステップ６０６で、ＰＩＯリストが空であると判断されると、拒否リストが完成しており、すると、ステップ６０８に進んで、ＰＩＯリストから、拒否リストにあるＰＩＯが除去される。
【００８０】
ステップ６１０では、こうして得られた許可ＰＩＯリストが返される。
【００８１】
そこで、図５のステップ５０８に戻って、ユーザＰ１に対して、許可されたＰＩＯが返される。ここで、好適には、ユーザＰ１のクライアント・コンピュータ上の画面に、許可されたＰＩＯが表示される。
【００８２】
ステップ５１０では、仮想空間サーバのシステムが、コミュニケーション・コンテキストの変更を待つ。例えば、ユーザＰ２が、ユーザＰ１に対して、あるメッセージをチャットで送ったとする。すると、コミュニケーション空間情報管理部４０８は、そのメッセージを、プライバシー・ポリシー蓄積部４０６に送り、プライバシー・ポリシー蓄積部４０６は、メッセージ中に、ユーザＰ２のＰＩＯに該当する単語があるかどうかを確認する。そして、もしあるなら、その単語のＰＩＯの公開／非公開の属性をユーザＰ１に対して公開にする。なぜなら、そのメッセージを、ユーザＰ１に対して送った、ということは、そのメッセージをユーザＰ１に対して公開する、という意図と解釈することができるからである。これが、コミュニケーション・コンテキストの変更の一例である。
【００８３】
コミュニケーション・コンテキストの変更があると、ステップ５０６に戻って、Ｐ１のすべてのＰＩＯに対して、変更されたプライバシー・ポリシーが適用される。
【００８４】
こうして、ステップ５０８で、メッセージで公開された単語に関連するＰＩＯが、ユーザＰ１に示される。
【００８５】
次に、図７のフローチャートを参照して、ＰＩＯにプライバシー・ポリシーを適用する処理を説明する。この処理は、図６のフローチャートのステップ６０２を詳細に示すものである。
【００８６】
ステップ７０２では、現在のＰＩＯに、プライバシー・ポリシーの適用が試みられる。ステップ７０４では、プライバシー・ポリシーが適用可能かどうかが判断される。ここで、適用可能とは、次のようなことである。
すなわち、<PIO>〜</PIO>中の、<target>〜</target>で指定される部分が、要求されている<target>〜</target>で指定される部分と一致するかどうか判断し、それらが異なる場合は、適用外として、ステップ７１８に進む。尚、ここの一致は、プライバシー・ポリシーに、category($currentPIO)のように書かれている場合は、targetの単語の一致でなく、その単語のカテゴリの一致が判断される。
【００８７】
ステップ７０４で、プライバシー・ポリシーが適用可能であると判断されると、ステップ７０６で、condition_listが適合するかどうかが、判断される。
condition_listは、例えば、下記のとおりである。下記の例では、１つだけ条件（condition）が記述されているが、<condition_list>と</condition_list>の間に、<condition>と</condition>で挟んで、複数の条件を指定することができる。
もし、condition_listに何も記述されていない場合は、一致したものとする。また preference_matching タグが指定されている場合は、評価しているユーザＰ２のＰＩＯが、ユーザＰ１のＰＩＯに対して嗜好が一致しているかどうかが判断される。
<condition_list>
<condition>
<preference_matching type="matching affinity"/>
</condition>
</condition_list>
例えば、評価中のユーザＰ２のＰＩＯが次のようだとする。すると、評価中のプライバシーポリシーの confition_listが上記のような場合は、ユーザＰ１のＰＩＯの中に一致するＰＩＯが存在するかどうかを調べ、一致するものが見つかれば condition_list が適合したものとする。
<PIO><target>アニメ</target><predicate>like</predicate></PIO>
【００８８】
condition_listが適合しない場合は、処理はステップ７１８に進む。condition_listが適合した場合は、ステップ７０８で、公開、あるいは、非公開の対象となるＰＩＯを求める。プライバシー・ポリシーのPIOタグに記述がない場合は、現在評価中のものが対象ＰＩＯとなる。PIOタグに記述がある場合は、それに一致するユーザＰ２の、１つ乃至複数のＰＩＯを求め、対象ＰＩＯとする。
【００８９】
対象ＰＩＯが得られると、ステップ７１０で、現在のＰＩＯは拒否されているかどうかが、判断される。この判断は、プライバシー・ポリシーのpermissionタグを調べることによって、なされる。permissionタグの値が、denyである場合は、ステップ７１２で、得られたＰＩＯが、拒否リストに追加される。
【００９０】
ステップ７１０での判断がＮＯならば、ステップ７１４で、現在のＰＩＯが許可されているかどうかが判断される。この判断も、プライバシー・ポリシーのpermissionタグを調べることによって、なされる。permissionタグの値が、allowである場合は、ステップ７１６で、得られたＰＩＯが、許可リストに追加される。
【００９１】
こうして、ステップ７１８では、次のプライバシー・ポリシーが取得され、ステップ７２０では、まだ適用していないプライバシー・ポリシーが残っているかが、判断される。そして、まだ適用していないプライバシー・ポリシーが残っていると、ステップ７０２に戻って、現在のＰＩＯにそのプライバシー・ポリシーが適用される。
【００９２】
すべてのプライバシー・ポリシーが適用され尽くしたなら、ステップ７２０での判断が否定的になり、図７のフローチャートの処理は完了する。
【００９３】
こうして、図７のフローチャートの処理は、ＰＩＯと許可リストと、拒否リストを返す。
【００９４】
前述のように、これらの許可リストと拒否リストは、図６のステップ６０８で使用される。ステップ６０８で、改めて許可リストから拒否リストが差し引かれるのは、許可リストと拒否リストに重複するＰＩＯが含まれている可能性があるからである。すなわち、あるＰＩＯが許可リストにあるからといって直ちに公開される訳ではなく、そのＰＩＯが拒否リストにもある場合に、公開しないようにすることにより、拒否リストを優先して、意図しない公開が防止される。
【００９５】
図８は、人の集合の嗜好を取得する場合の処理のフローチャートを示す。
【００９６】
図８のステップにおいて、ステップ８０２で、ユーザＵは、コミュニケーション空間情報管理部４０８に、例えば、ユーザＵと同じ仮想空間内の部屋にいるユーザ（アバタ）Ｐ１．．．Ｐｎのプロファイルを、要求する。コミュニケーション空間情報管理部４０８は、その要求を、ポリシー適用部４１０に渡す。
【００９７】
ステップ８０４で、これをもとに、ポリシー適用部４１０は、ユーザＰ１．．．Ｐｎのプロファイル中の嗜好情報のリスト（ＰＩＯリスト）を、嗜好情報蓄積部４０４から、取得する。Ｐｉ（ｉ＝１．．．ｎ）のＰＩＯの中で、アクセス可能ユーザ・リストが設定されている場合、第三者に公開されているＰＩＯだけを取得する。
【００９８】
ステップ８０６では、ユーザＰｉ（ｉ＝１．．．ｎ）のプロファイル中の個々のＰＩＯに対して、ユーザＰｉのプライバシー・ポリシーが適用され、個々のＰＩＯに対して、第三者への公開が許可されているかどうかの判断がなされる。ここでは、具体的には、図６及び図７のフローチャートに示すような処理が行われるが、図６及び図７のフローチャートに関連して説明したのとほとんど同じ処理であるので、説明を省略する。ただ、ここで異なるのは、ユーザＰｉのプロファイルに含まれている全てのＰＩＯの中で、全体にどれくらいの割合でpositive/negativeとして存在しているのかを求める処理が行われることである。この割合は、もしプライバシー・ポリシーに記述されているなら、上述の［例３］に示すような、下記の条件との比較に使用される。
<condition>
<minimumMatchingRatio value="0.5"/>
</condition>
【００９９】
こうして、ステップ８０６で、許可ＰＩＯが得られると、ステップ８０８では、そうして得られた許可ＰＩＯが、コミュニケーション空間情報管理部４０８に返され、それを以って、コミュニケーション空間情報管理部４０８は、ユーザＵのクライアント・コンピュータに送ることによって、ユーザＵに、許可されたＰＩＯを提示する。
【０１００】
ステップ８１０では、コミュニケーション空間情報管理部４０８は、コミュニケーション・コンテキストの変更を待ち、もし、コミュニケーション・コンテキストの変更があると、処理はステップ８０６に戻り、プライバシー・ポリシーの再度の適用が行われる。
【０１０１】
次に、図９は、嗜好情報をユーザが編集するための画面を示すものである。前述のように、ユーザの嗜好情報は、好適から、そのユーザのブログ、インターネット・サイトの閲覧履歴、行動情報などから、自動的に抽出されるが、図９に示す画面は、ユーザが、取得した嗜好情報を編集したり、あるいは新規追加したりすることを可能とする。
【０１０２】
図９のメニューは、好適には、サーバ１０２上で、JavaScript（商標）と、Perl、Rubyなどを使ったＣＧＩにより、実現することができる。そして、ユーザは、JavaScriptを解釈可能なウェブ・ブラウザで、このメニューに入ることになる。あるいは、PHP、Java（商標）Servlet、JSPなどの技法でも記述できるが、これらの技術は周知であるので、ここでは詳述しない。また、ウェブ・ブラウザやJavaScript経由ではなく、専用クライアント・プログラムで、図９のメニューに入るようにしてもよい。
【０１０３】
図示しないが、この画面に入るには、ユーザは、自分専用のユーザＩＤとパスワードを入力して、一旦、ログインする必要がある。
【０１０４】
図９において、ボタン９０２をクリックすると、ターゲットの語句を入れる画面（図示しない）があらわれ、そこに語句を入れてＯＫボタン（図示しない）をクリックすると、下方に、エントリ９０４が表示され、テキスト・フィールド９０６には、先ほど入れた語句が表示される。述部９０８は、「好き」と「嫌い」の択一的なラジオ・ボタンであって、例えば、デフォールトで、「好き」が選ばれていてもよい。なお、「好き」と「嫌い」以外にも、「大好き」、「大嫌い」などの述語を選べるようにしてもよい。
【０１０５】
「シソーラス表示」というボタン９１０をクリックすると、テキスト・フィールド９０６に書かれている語句に関連して、ハードディスク３１４に格納されているシソーラス辞書が検索され、語句のシソーラスが表示される。この段階で、必要に応じて、テキスト・フィールド９０６の語句を、シソーラス内の語句で置き換えることができる。
【０１０６】
エントリ９０４のどこかを変更した場合、「更新」ボタン９１２をクリックすることにより、この変更されたエントリが、ハードディスク３１４に反映・保存される。好適には、嗜好エントリは、ハードディスク３１４に、コンテンツ管理データベース（ＣＭＤＢ）として保存される。また、削除ボタン９１４をクリックすることによって、そのエントリを、コンテンツ管理データベースから削除することができる。
【０１０７】
一方、フィールド９１６に語句を入れて、検索ボタン９１８をクリックすることによって、その語句に部分一致する語句のエントリをリストして、適宜、編集・削除することができる。
【０１０８】
図１０は、ユーザがプライパシー・ポリシーを作成し、あるいは編集する画面を示すものである。図９のメニューと同様に、図１０のメニューも好適には、サーバ１０２上で、JavaScript（商標）と、Perl、Rubyなどを使ったＣＧＩにより、実現することができる。そして、ユーザは、JavaScriptを解釈可能なウェブ・ブラウザで、このメニューに入ることになる。あるいは、PHP、Java（商標）Servlet、JSPなどの技法でも記述できる。あるいは、専用クライアント・プログラムで、図１０のメニューに入るようにしてもよい。
【０１０９】
図示しないが、この画面に入るには、ユーザは、自分専用のユーザＩＤとパスワードを入力して、一旦、ログインする必要がある。
【０１１０】
なお、ユーザ毎のプライパシー・ポリシーも、嗜好情報と同様に、管理サーバ３０６のハードディスク３１４のコンテンツ管理データベースに格納される。
【０１１１】
図１０の画面は、大きく分けて、基本設定部と、追加設定部とからなる。基本設定部は、ラジオボタン１０１０と、それに関連付けられた文字の組み合わせからなる。最初のラジオボタンには、「好みが一致する場合に、嗜好情報を公開（省略時設定）」という語句が関連付けられ、このラジオボタンをクリックすることにより、誰かが、嗜好情報の公開をリクエストしてきたときに、その人と嗜好情報が一致する場合にのみ、一致する嗜好情報を公開することになる。これが本発明の１つの典型的な処理であって、省略時設定となっている。これは、下記のプライパシー・ポリシーに対応する。
<pivacy_policy>
<permission>allow</permission>
<condition_list>
<condition>
<preference_matching type="matching affinity" />
</condition>
</condition_list>
</pivacy_policy>
【０１１２】
「すべての嗜好情報を公開」のラジオボタンをクリックすることにより、誰に対しても、すべての嗜好情報が公開される。これは、下記のプライパシー・ポリシーに対応する。
<pivacy_policy>
<permission>allow</permission>
</pivacy_policy>
【０１１３】
また、「どの嗜好情報も公開しない」のラジオボタンをクリックすることにより、誰に対しても、一切の嗜好情報が公開されない。これは、下記のプライパシー・ポリシーに対応する。
<pivacy_policy>
<permission>deny</permission>
</pivacy_policy>
【０１１４】
さらに、「基本設定を使用しない」のラジオボタンをクリックすることにより、設定は、追加設定部に記述された内容に委ねられる。
【０１１５】
追加設定されるプライパシー・ポリシーの設定画面は、図示されているように表形式になっていて、操作カラム１０２０、許可カラム１０２２、ターゲット・カラム１０２４、ＰＩＯカラム１０２６及び条件カラム１０２８からなる。
【０１１６】
操作カラム１０２０には、「削除」ボタン１０２０ａと、「更新」ボタン１０２０ｂがある。「削除」ボタン１０２０ａをクリックすると、好適には、ＯＫボタンをもつ適当な確認メッセージがあらわれ、そこでＯＫボタンをクリックすると、該当の行に対応するプライパシー・ポリシーが、ハードディスク３１４のコンテンツ管理データベースから削除される。「更新」ボタン１０２０ｂをクリックすると、この画面で設定した内容が、ハードディスク３１４のコンテンツ管理データベースに保存され、その後そのユーザ用に反映される。
【０１１７】
許可カラム１０２２は、許可(allow)または、拒否(deny)のどちらかのラジオボタンをクリックするようになっている。
【０１１８】
ターゲット・カラム１０２４では、ユーザが自分の嗜好情報を公開する相手、すなわちターゲットを指定する。ラジオボタンには、個人（person）と、コミュニケーション空間（Communication space)があり、「個人」を選ぶと、個人ユーザ向けの嗜好情報の開示ポリシーとなり、「コミュニケーション空間」を選ぶと、コミュニケーション空間にいる、一般的には複数のユーザに対して、ユーザが自分の嗜好情報を公開するポリシーを設定することになる。ターゲット・カラム１０２４のAttributeメモ・フィールド１０２４ａには、例えば個人向け嗜好情報公開の場合の、特定の相手ユーザのＩＤなども設定することができる。
【０１１９】
ＰＩＯカラム１０２６は、図１０ではブランクになっているが、例えば、<PIO category="upperCategory(category($currentPIO))" matchingPreference="all"/>のような、開示するＰＩＯの条件を、１つまたは複数記述することができる。
【０１２０】
条件カラム１０２８には、<condition_list>〜</condition_list>で指定される条件指定を、ＸＭＬタグ付きで記述する。
【０１２１】
ボタン１０３０をクリックすると、新しいプライバシー・ポリシーのエントリが作成され、その後、適宜編集して、管理サーバ３０６（図３）のハードディスク３１４のコンテンツ管理データベースに保存することが可能である。
【０１２２】
次に、図１１以下を参照して、仮想空間内で、ユーザが嗜好情報の公開の様子を説明する。
【０１２３】
図１１は、仮想空間ブラウザ１１００内で、ユーザＡと、ユーザＢが体面して対話する様子を示す。ここでは、ユーザＡのアバタ１１０２と、ユーザＢのアバタ１１０４が表示されている。
【０１２４】
ユーザＡは、次のようなプライバシー・ポリシーをもつとする。
<privacy_policy_definitions>
<privacy_policy>
<permission>allow</permission>
<target>
<person />
</target>
<PIO category="アニメ"/>
</privacy_policy>
<privacy_policy>
<permission>allow</permission>
<target>
<person />
</target>
<PIO category="仮面ドライバー" matchingPreference="matching  affinity"/>
</privacy_policy>
</privacy_policy_definitions>
【０１２５】
ユーザＡは、少なくとも「アニメ」と「仮面ドライバー」を、「好き」としてＰＩＯに含んでいるとする。一方、ユーザＡの上記プライバシー・ポリシーによれば、「アニメ」は、無条件で誰にでも公開になっているので、ユーザＡのチャット画面１１０６に関連して、その嗜好公開部１１０８に「アニメ」と表示されている。
【０１２６】
一方、ユーザＢのＰＩＯ及びそのプライバシー・ポリシーは、詳述しないが、少なくとも、無条件公開する嗜好は設定されておらず、且つ、少なくとも「仮面ドライバー」は、ユーザＢのＰＩＯに含まれていないとする。すると、<PIO category="仮面ドライバー" matchingPreference="matching  affinity"/>の条件に合致しないので、「仮面ドライバー」は、その嗜好公開部１１０８に表示されない。
【０１２７】
そこで、嗜好公開部１１０８に「アニメ」と表示された状態で、ユーザＡが、ユーザＢに、チャットで、「やあ、初めまして」と話しかける。それに対して、ユーザＢは、チャットで、「こんにちは」と答えるとする。
【０１２８】
ここで、図５のフローチャートを参照されたい。そのステップ５１０では、コミュニケーション空間情報管理部４０８（図４）が、コミュニケーション・コンテキストの変更を待つ、すなわち、チャット・メッセージを監視している。しかし、この時点では、チャット・メッセージには、単なる挨拶文しか含まれていないので、コミュニケーション・コンテキストの変更は生じない。
【０１２９】
そこで、図１２に移行して、ユーザＢが、「アニメが好きなの？  私も。今、仮面ドライバーにはまっているの！」とチャットで発言したとする。すると、コミュニケーション空間情報管理部４０８は、このメッセージを解析し、ユーザＢが、仮面ドライバーが好きとみなして、嗜好情報蓄積部４０４において、「仮面ドライバー」が「好き」というＰＩＯをユーザＢ用に蓄積する。ユーザＡは、それに対して、「えっ、本当？」と答える。
【０１３０】
このコミュニケーション・コンテキストの変更に応答して、図５のフローチャートで、ステップ５０６で、プライバシー・ポリシーが再適用され、<PIO category="仮面ドライバー" matchingPreference="matching  affinity"/>の条件に合致するようになる。このことで、嗜好公開部１１０８に「仮面ドライバー」が表示される。
【０１３１】
これによって、ユーザＢは、実はユーザＡも仮面ドライバーが好きだったことを知り、その後、会話を弾ませることができる。
【０１３２】
次に、図１３以下を参照して、グループに対する嗜好情報の開示の例を説明する。図１３では、アバタ１３０２に扮するユーザＣが、それぞれアバタ１３０４、１３０６及び１３０８に扮するユーザに、話しかけるものとする。このとき、コミュニケーション空間情報管理部４０８は、アバタ１３０２と、アバタ１３０４、１３０６及び１３０８が、閉じられた、あるいは閉じられていなくてもよいが他の空間領域から区画されている識別可能な仮想空間内の部屋にいると認識している。
【０１３３】
ここで、ユーザＣは、次のようなプライバシー・ポリシーをもつとする。
<pivacy_policy>
<permission>allow</permission>
<target>
<communication_space/>
</target>
<condition_list>
<and>
<condition>
<preference_matching type="matching affinity"/>
</condition>
<condition>
<category id="テニス"/>
</condition>
<condition>
<minimumMatchingRatio value="0.5"/>
</condition>
</and>
</condition_list>
</privacy_policy>
【０１３４】
ユーザＣが、この部屋に来た段階では、ユーザＣは、そこの部屋にいる他のアバタ１３０４、１３０６及び１３０８の嗜好情報は知らない。よって、図１３に示すように、ユーザＣが「やあ、皆さん」とチャットで話しかけたときも、そのチャット・メッセージ１３１０には、ユーザＣの嗜好情報は、表示されない。
【０１３５】
そこで、ユーザＣが、コミュニケーション空間情報管理部４０８に、その部屋にいるアバタ１３０４、１３０６及び１３０８の嗜好情報の問い合わせをする。このことは例えば、ユーザＣが、自分が使っているクライアント・コンピュータで、仮想空間ブラウザ１１００の表示画面の任意の箇所を、マウスの右ボタンでクリックし、そこでポップアップするメニュー（図示しない）から、「空間嗜好情報問い合わせ」を選んで、マウスの左ボタンをクリックすると、コミュニケーション空間情報管理部４０８が、嗜好情報蓄積部４０４（図４）に問い合わせを出して、アバタ１３０４、１３０６及び１３０８のそれぞれのユーザの嗜好情報を検索し、その情報を確認する。その結果、アバタ１３０４、１３０６のユーザがテニスが好きで、また、ユーザＣもテニスが好きで、アバタ１３０８のユーザは、テニスに関する嗜好情報は何も含んでいないとする。
【０１３６】
すると、コミュニケーション空間情報管理部４０８は、図８のフローチャートで示す処理により、その部屋で、テニスが好きなユーザが３人で、テニスが好きかどうか分からないユーザが１人であることから、その部屋のテニスが好きなユーザの割合は、3/4 = 0.75である、という情報を返す。これに応答して、上記ユーザＣのプライバシー・ポリシーに基づき、<minimumMatchingRatio value="0.5"/>の条件を満たすので、ユーザＣの嗜好情報表示部１４０２に、「テニス」という嗜好情報が表示され、これによって、アバタ１３０４、１３０６及び１３０８は、ユーザＣがテニスが好きであることを知る。この後、その部屋にいるユーザの大多数がテニスが好きである、という情報に基づき、その関連の話題で盛り上がることができる。
【０１３７】
そこで、この部屋に新たなアバタが三人、入ってきたとする。ユーザＣが再び、空間嗜好情報問い合わせを行った結果、その新たなアバタのうちの一人はテニスが嫌いであり、他の二人はテニスに関する嗜好情報をもたないと分かったとする。すると、その結果、コミュニケーション空間情報管理部４０８が返す、その部屋のテニスが好きなユーザの割合は、3/7 = 0.43となって、最早、<minimumMatchingRatio value="0.5"/>の条件を満たさなくなるので、図１４のユーザＣの嗜好情報がシステム的に消去される。
【０１３８】
なお、上記実施例では、ユーザが明示的な操作により、その空間に滞在するユーザ（アバタ）の集合的な嗜好情報を問い合わせるようになっているが、一定時間以上アバタがその空間に滞在することにより、コミュニケーション空間情報管理部４０８が、その空間に滞在するユーザ（アバタ）の嗜好情報を読み取り、プライバシー・ポリシー中に空間的ポリシーすなわち、<target><communication_space/></target>が含まれるユーザに、取得した情報を自動的に通知するようにしてもよい。
【０１３９】
また、複数のユーザ（アバタ）が、ある部屋（空間）に滞在する状況において、任意のユーザ（第１のユーザとする）は、別のアバタ（第２のユーザとする）の個人の嗜好情報を問い合わせることができる。すなわち、第２のユーザのアバタを、第１のユーザがマウスの右ボタンでクリックし、そこでポップアップするメニュー（図示しない）から、「個人嗜好情報問い合わせ」を選んで、マウスの左ボタンをクリックすると、コミュニケーション空間情報管理部４０８が、嗜好情報蓄積部４０４（図４）に問い合わせを出して、別のアバタの嗜好情報の問い合わせを行うことができる。この場合、コミュニケーション空間情報管理部４０８は、図５のフローチャートに示す処理に基づき、第１のユーザの嗜好情報（ＰＩＯ）と第２のユーザのＰＩＯを収集し、それらに対して、第２のユーザのプライバシー・ポリシーを適用する。その結果返されたＰＩＯは、第１のユーザのクライアント・コンピュータにだけ送られ、第１のユーザは、第２のユーザのプライバシー・ポリシーに基づき許された範囲で、自分のクライアント・コンピュータの画面に表示されている仮想空間ブラウザ１１００上で、第２のユーザのＰＩＯを眺めることができる。好適には、そのＰＩＯは、仮想空間ブラウザ１１００上で、第２のユーザのアバタに関連付けられた吹き出しのような形で表示される。なお、この情報は、その部屋にいる他のユーザのクライアント・コンピュータには送られないので、ＰＩＯの情報公開範囲は、きちんと限定される。
【０１４０】
図１３及び図１４で示す処理は、催し物の主催者が、広告を提供するためにも応用できる。
【０１４１】
すなわち、例えば、仮想空間上で、歌手のコンサートが行われるため、仮想空間内に用意されたシアターに多数のユーザーが集まってきており、コンサートが始まるまでの時間にＣＭを流し、そのＣＭのスポンサーのウェブサイト（あるいは仮想空間に用意された店など）に誘導し、コンサートが始まるまでの時間をすごしてもらいたいと仮定する。
広告を提供したい人（シアターの持ち主あるいは広告主）は、まずそのシアターに存在しているユーザーのＩＤを、コミュニケーション空間情報管理部４０８から取得する。そして、そのユーザーＩＤの集合を、嗜好情報のユーザーの集合として指定する。そして、そのユーザーの集合の嗜好の統計情報を取得する。
【０１４２】
得られた情報は以下のようであったとする。
・嗜好対象が趣味（シソーラスで「趣味」に属するもの）
音楽が好き  ７５％
映画が好き  ２０％
スポーツが好き  １０％
【０１４３】
・嗜好対象が人物名（シソーラスで「人名」に属するもの）
ロック歌手Ｄ（男性）が好き  ６０％
タレントＥ（男性）が好き  ３０％
アイドルＦ（男性）が好き  ２５％
アイドルＧ（女性）２％など
【０１４４】
これらの情報が得られたとき、ユーザーの嗜好に合わせた広告の出し方には、２種類ある。
１）広告対象の候補を複数持っている場合
広告配信の会社と契約していてその広告の中身を動的に替えることができる場合を考える。すなわち、得られた嗜好情報より、ここに集まっているユーザーは映画やスポーツよりも、音楽に興味があるユーザーのほうが多いことがわかる。そこで、映画関連やスポーツ関連の広告より、音楽の楽曲の宣伝や、あるいは携帯音楽プレーヤーの宣伝を見せる。
【０１４５】
２）広告対象は一つだが、広告の種類が複数ある場合
すでに広告の対象となる商品は決まっているが、複数の広告がある場合を考える。複数の広告とは、タレントＡ（女性アイドル）、タレントＢ（男性アイドル俳優）、タレントＣ（女優）によって同じ商品の特徴を語らせたストーリーのＣＭであるとする。得られた嗜好情報より、女性のタレントよりも、男性タレントのほうがこの集合に対し広告効果があると推察でき、男性タレントの出演しているＣＭをユーザーに示す。
【０１４６】
仮想空間上で、人（アバタ）が複数人集まったときに、その人々のプロファイルに適した広告（画像、映像、オブジェクトなど）を提供したいという状況を考える。人々のプロファイルはサーバーで管理されており、広告の提供者にはその情報はプライバシーの観点から提供されない。しかし、コミュニケーション空間情報管理部４０８によってその場の嗜好情報が管理されていれば、広告の提供者はその集まった人々の嗜好情報を手に入れることができ、一番適した広告を提供することができる。
【０１４７】
図１５は、インスタント・メッセージング・システムに本発明を適用した例を示す。このシステムのサーバ・コンピュータは、図示しないが、図４で既に説明したのと同等の機能モジュールを含むものとする。すなわち、嗜好情報蓄積部４０４には、インスタント・メッセージング・システムの登録されたユーザの嗜好情報が格納されている。また、プライバシー・ポリシー蓄積部４０６には、登録されたユーザのプライバシー・ポリシーが蓄積されている。図１５において、Aoki、Betty、Chris、Suzuki、Yamada、Zhangの６人のユーザが、インスタント・メッセージング・システムにログインしており、特に、Aokiのログイン画面を今見ている、とする。
【０１４８】
そこで、表示されているユーザのＩＤ（ここでは、Bettyとする）に、Aokiが、カーソルをあわせて、マウスの右ボタンをクリックすると、嗜好情報問い合わせを含むメニュー１６０４がホップアップする。そこで、メニュー１６０４において、Aokiが、嗜好情報問い合わせをクリックすると、図５のフローチャートに相当する機能が働き、先ずAokiとBettyの嗜好情報が収集され、それにBettyのプライバシー・ポリシーが適用されて、図１７に示すように、Aokiに提示可能なBettyの嗜好情報１７０２が表示される。
【０１４９】
図１８は、Aokiが、このインスタント・メッセージング・システムでメッセージを送る画面１８０２を示す。この画面では、Aokiのプライバシー・ポリシーに従い、Aokiの嗜好情報のうち、Animationと、Movieが嗜好情報表示部に表示されており、これは、どのチャット相手に対しても公開される。
【０１５０】
図１９は、３人以上でチャットする画面１９０２を示す。このとき、３人以上のメンバーがチャット画面に含まれていることに応答して、図８のフローチャートに示す処理により、このチャットに参加しているグループの嗜好情報が、コミュニケーション空間情報部４０８によって取得される。として、例えば、Aokiは、グループの半数以上がサッカーが好きならサッカーが好きであることを公開する、というプライバシー・ポリシーをもっていたとして、コミュニケーション空間情報部４０８が、ChrisとZuzukiがサッカーが好きであると検出したことに応答して、インスタント・メッセージング・システムによって、嗜好情報表示部１９０４に、"Soccer"が表示される。
【０１５１】
この発明のさらに有効な適用対象は、ソーシャル・ネットワーキング・サービス（ＳＮＳ）である。ソーシャル・ネットワーキング・サービス自体が、ネットワーク上で、信頼できる仲間の間でプロフィールや関心事を公開する仕組みであるが、この発明に従い、各ユーザが、プライバシー・ポリシーを適切に設定することにより、趣味が似ている仲間にだけ、自分の特定の趣味を開示したり、特定のコミニュニティのメンバーに対して、そのコミュニティで多数を占める趣味だけを開示するような、きめ細かい嗜好情報の開示が可能となる。
【０１５２】
以上、本発明の実施例を、仮想空間内でのコミュニケーション、インスタント・メッセージング・システム及びソーシャル・ネットワーキング・サービスの例に従って説明して来たが、本発明は、これらに限定されるものではなく、ネットワーク上で複数のユーザが対話する任意のシステムに適用可能であることを理解されたい。  
【図面の簡単な説明】
【０１５３】
【図１】仮想空間サーバとクライアント・コンピュータの接続状態を示す概要図である。
【図２】クライアント・コンピュータのハードウェアの概要ブロック図である。
【図３】仮想空間サーバのハードウェアの概要ブロック図である。
【図４】嗜好マッチング処理を行うための機能の論理ブロック図である。
【図５】個人間の嗜好マッチング処理のフローチャートである。
【図６】公開可能な嗜好情報を得るための処理のフローチャートである。
【図７】プライバシー・ポリシー適用処理のフローチャートである。
【図８】コミュニケーション空間における嗜好マッチング処理のフローチャートである。
【図９】嗜好情報登録及び編集画面の図である。
【図１０】プライバシー・ポリシー登録及び編集画面の図である。
【図１１】仮想空間内で、個人間で嗜好情報を公開する例を示す図である。
【図１２】仮想空間内で、個人間で嗜好情報を公開する例を示す図である。
【図１３】仮想空間内で、グループに対して嗜好情報を公開する例を示す図である。
【図１４】仮想空間内で、グループに対して嗜好情報を公開する例を示す図である。
【図１５】インスタント・メッセージング・システムにおいて嗜好情報を公開する例を示す図である。
【図１６】インスタント・メッセージング・システムにおいて嗜好情報を公開する例を示す図である。
【図１７】インスタント・メッセージング・システムにおいて嗜好情報を公開する例を示す図である。
【図１８】インスタント・メッセージング・システムにおいて嗜好情報を公開する例を示す図である。
【図１９】インスタント・メッセージング・システムにおいて嗜好情報を公開する例を示す図である。
【図１】
0005190252.tif 000002
【図２】
0005190252.tif 000003
【図３】
0005190252.tif 000004
【図４】
0005190252.tif 000005
【図５】
0005190252.tif 000006
【図６】
0005190252.tif 000007
【図７】
0005190252.tif 000008
【図８】
0005190252.tif 000009
【図９】
0005190252.tif 000010
【図１０】
0005190252.tif 000011
【図１１】
0005190252.tif 000012
【図１２】
0005190252.tif 000013
【図１３】
0005190252.tif 000014
【図１４】
0005190252.tif 000015
【図１５】
0005190252.tif 000016
【図１６】
0005190252.tif 000017
【図１７】
0005190252.tif 000018
【図１８】
0005190252.tif 000019
【図１９】
0005190252.tif 000020