(57)【要約】アクセス制限されたリソース共有システムにおいて、２以上のプライベート・リソース・レポジトリにわたってリソースのサーチを実行する方法を開示する。システムは、ネットワークに接続された、少なくとも１つのサーバノード（１２）と、多数のピア・ノード（１６ａ−１６ｄ）とを含んでいる。デジタル画像データを始めとするリソースは、リソースに関連するメタデータとマッチするタームを含むクエリの発行に基づいて、ノードから検索され得る。方法は、リソース及び関連メタデータのストレージを、各ピア・ノードに維持する工程を含む。関連メタデータは、少なくとも１つのメタデータ・ボキャブラリに基づいている。各ピア・ノードは、サーバに、リソースに関連するメタデータ・ボキャブラリがプライベートのものとして指定されていることを示し、それによって、アクセス制限されたピア・ノードになる。第１のアクセス制限されたピア・ノードが、第１のアクセス制限されたピア・ノードがどのメタデータをサポートするかをサーバに指定する場合、第１のレベルのプライバシーが提供され、それによって、サーバによって受け取られ、且つ指定されたメタデータ・ボキャブラリを使用するサーチ・クエリが、処理のために第１のアクセス制限されたピア・ノードの各々に渡され、指定されたメタデータ・ボキャブラリを使用しないサーチはサーバによって処理される。第１のアクセス制限されたピア・ノードが、第１のアクセス制限されたピア・ノードがどのメタデータ・ボキャブラリをサポートするかをサーバに指定しない場合、第２レベルのプライバシーが提供され、それによって、サーバによって受け取られたサーチ・クエリが処理のために第１のアクセス制限されたピア・ノードの各々に渡される。
2005522786.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された少なくとも１つのサーバと多数のピア・ノードとを含むアクセス制限されたリソース共有システムにおいて、２以上のプライベート・リソース・レポジトリにわたってリソースのサーチを実行する方法であって、該リソースは、データデジタル画像を始めとするリソースを記憶し、且つ該リソースに関連するメタデータに基づいて該リソースをサーチするためのネットワークを共有し、
（ａ）リソース及び関連メタデータのストレージを各々のピア・ノードで維持する工程と、関連メタデータは、少なくとも１つのメタデータ・ボキャブラリに基づいていることと；
（ｂ）ピア・ノードの各々が、サーバに、リソースに関連するメタデータ・ボキャブラリがプライベートのものとして指定されていることを示し、それによってアクセス制限されたピア・ノードになる工程と；
（ｃ）第１のアクセス制限されたピア・ノードが、第１のアクセス制限されたピア・ノードがどのメタデータ・ボキャブラリをサポートするかをサーバに指定する場合に、第１レベルのプライバシーを提供する工程であって、それによって、サーバによって受け取られ、且つ指定されたメタデータ・ボキャブラリを使用するサーチ・クエリが、処理のために第１のアクセス制限されたピア・ノードの各々に渡され、指定されたメタデータ・ボキャブラリを使用しないサーチはサーバによって処理される工程と；
（ｄ）第１のアクセス制限されたピア・ノードが、第１のアクセス制限されたピア・ノードがどのメタデータ・ボキャブラリをサポートするかをサーバに指定しない場合に、第２レベルのプライバシーを提供する工程であって、それによって、サーバによって受け取られたサーチ・クエリが、処理のために第１のアクセス制限されたピア・ノードの各々に渡される工程と；
から成る方法。
【請求項２】
特定のサーチ・クエリに応答して第１のアクセス制限されたピア・ノードによって生成された応答を、サーバを通じて、要求中のピア・ノードへ経路指定する工程からさらに成る、請求項１に記載の方法。
【請求項３】
特定のサーチ・クエリに応答して第１のアクセス制限されたピア・ノードによって生成された応答を、サーバを通さずに、要求中のピア・ノードへ直接経路指定する工程からさらに成る、請求項１に記載の方法。
【請求項４】
工程（ｃ）が、
（ｉ）第１のアクセス制限されたピア・ノードに対するロケータに、サーチ・クエリを埋め込むこと；
（ｉｉ）要求中のピア・ノードに前記ロケータを送ること；
（ｉｉｉ）前記ロケータを使用して、第１のアクセス制限されたピア・ノードに前記クエリを送ること；
（ｉｖ）第１のアクセス制限されたピア・ノード上での前記クエリの受け取りに応じて、マッチを求めて第１のアクセス制限されたピア・ノード上の記憶されたメタデータをサーチすること；及び
（ｖ）前記クエリにマッチするメタデータを有するリソースに対するリソース・ロケータを、要求中のピア・ノードに返すこと；
からさらに成る、請求項３に記載の方法。
【請求項５】
工程（ｃ）が、
（ｉ）第１のアクセス制限されたピア・ノードが要求中のピア・ノードにサーチ結果を直接送れるように、要求中のピア・ノードに対するロケータを備えた第１のアクセス制限
されたピア・ノードにサーチ・クエリを送ること
からさらに成る、請求項３に記載の方法。
【請求項６】
第１のアクセス制限されたピア・ノードから送られた応答を暗号化する工程からさらに成る、請求項１に記載の方法。
【請求項７】
要求中のピア・ノードに関連する公開鍵を使用して、応答を暗号化する工程からさらに成る、請求項６に記載の方法。
【請求項８】
ネットワークに接続された少なくとも１つのサーバと多数のピア・ノードとを含むアクセス制限されたリソース共有システムにおいて、２以上のプライベート・リソース・レポジトリにわたってリソースのサーチを実行する方法であって、該リソースは、データデジタル画像を始めとするリソースを記憶し、該リソースに関連するメタデータに基づいて該リソースをサーチするためのネットワークを共有し、
（ａ）リソース及び関連メタデータのストレージを各々のピア・ノードで維持する工程と、関連メタデータは、少なくとも１つのメタデータ・ボキャブラリに基づいていることと；
（ｂ）ピア・ノードの各々が、サーバに、リソースに関連するメタデータ・ボキャブラリがプライベートのものとして指定されていることを示し、それによってアクセス制限されたピア・ノードになる工程と；
（ｃ）要求中のピア・ノードからのリソースに対するサーチ・クエリをサーバ上で受け取る工程と、サーチ・クエリは１又は複数のメタデータ・ボキャブラリをその中で使用していることと；
（ｄ）アクセス制限されたピア・ノードの各々がどのメタデータ・ボキャブラリをサポートするかをサーバに指定するのが、どのアクセス制限されたピア・ノードであるかを、サーバにより判定する工程と；
（ｅ）どのメタデータ・ボキャブラリがサポートされるかをサーバに指定し、且つどこでその指定されたメタデータ・ボキャブラリがサーチ・クエリ中で使用されるメタデータ・ボキャブラリとマッチするかをサーバに指定する、アクセス制限されたピア・ノードの各々の上で、サーチ・クエリを実行する工程であって、サーチ・クエリの実行後、アクセス制限されたピア・ノードは、サーチ・クエリとマッチするリソースに対するリソース・ロケータのリストを要求中のノードに送ることと；
（ｆ）どのメタデータ・ボキャブラリがサポートされるかをサーバに指定するが、どこでその指定されたメタデータ・ボキャブラリが、サーチ・クエリ中で使用されるメタデータ・ボキャブラリとマッチしないかをサーバに指定する、アクセス制限されたピア・ノードの各々に対するサーバ上で、サーチ・クエリを実行する工程であって、サーチ・クエリの実行後、サーバは、サーチ・クエリとマッチするリソースに対するリソース・ロケータのリストを要求中のノードに送ることと；
（ｇ）どのメタデータ・ボキャブラリがサポートされるかをサーバに指定しない、アクセス制限されたピア・ノードの各々の上で、サーチ・クエリを実行する工程であって、サーチ・クエリの実行後、それらのピア・ノードの各々は、サーチ・クエリとマッチするリソースに対するリソース・ロケータのリストを要求中のノードに返すことと；
から成る方法。
【請求項９】
アクセス制限されたピア・ノードから送られた応答を暗号化する工程からさらに成る、請求項８に記載の方法。
【請求項１０】
要求中のピア・ノードに関連する公開鍵を使用して、応答を暗号化する工程からさらに成る、請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
本発明は、２００１年１０月１日に出願された、発明の名称「ネットワーク上のフォト・シェアリング・アーキテクチャ（ＮＥＴＷＯＲＫ−ＢＡＳＥＤ  ＰＨＯＴＯＳＨＡＲＩＮＧ  ＡＲＣＨＩＴＥＣＴＵＲＥ）」（２２１５Ｐ／Ｐ２１４）である米国特許出願出願番号第０９／９６８，３９３号の一部継続出願である。この出願は、本願の譲受人に譲渡されており、引用により本願に組み込まれるものとする。
（発明の属する技術分野）
本発明はデジタル画像の電子記憶と共有に関し、より詳細には、フォト・シェアリングアーキテクチャの改良に関する。
【背景技術】
【０００２】
過去数年にわたって、フォト・シェアリング技術は、フォト愛好家によって広く受け入れられるようになっている。デジタル画像をサーバ上に記憶したり、他人がインターネットを介してそれを閲覧したりするために、ユーザが特定のサイトにデジタル画像をアップロードすることを可能にするウェブサイトが現在数多く存在する。メタデータは、通常は１つの画像又は複数の画像のグループに関連付けられるものであり、一般に、フォト・シェアリング・サイトによってサポートされている。しかしながら、今日のウェブ上でのフォト・シェアリングを阻害している最重要項目の１つは、画像とそれに関連するメタデータに利用可能なプライバシーが欠如していることである。
【０００３】
ウェブ上で画像を共有するために利用可能な選択肢は、現在いくつか存在する。１つの選択肢は、１人のユーザ又は複数ユーザのグループが、自身の共有のためのサイトを構築し、従来の利用可能なアクセス制御機構を通じてそのサイトへのアクセスを制限することである。しかしながら、これにはコストがかかり、技術的にほとんどの人の手に負えないものとなりかねない。さらには、ユーザが２つ以上のそのような「プライベート」（private,  非公開）サイトにわたって画像をサーチすることを可能にする有効な機構は現在存在しない。
【０００４】
もう１つの選択肢は、個人及びグループが、YagaTMを始めとする現在のピアツーピアネットワークのいくつかに、多くのコストを負担せず、セットアップの際に非常に高い技術的専門知識を必要とせず、且つウェブサイトを維持する必要なく、自身の所有する画像をホストすることである。これらのピアツーピアシステムのうちの一部は、固定メタデータフィールドの小セットを使用してサーチするための限定的なサポートを提供するが、現在のピアツーピアネットワーク上で発見できる画像は、それらのメタデータと同様にパブリック（public、公開）なものであるため、システム上のすべてのユーザにアクセスが利用可能である。
【０００５】
さらなる選択肢は、ユーザ及び小さなユーザーグループが、従来のウェブ上のフォト・シェアリング・サービスを使用して、自身の画像を共有することである。このようなサービスは、限られた量のプライバシーしか提供しない。従来のアクセス制御機構により、ユーザ又はグループは、誰が画像とその関連メタデータを見てよいかを指定することができ、それらのサイトの一部は、そのサイトがサポートする限定された量のメタデータでのサーチを可能にするサーチ設備を提供する。しかしながら、現在のフォト・シェアリング・サービスは、画像とメタデータ（少なくともそのコピー）の両方の所有権を有している。この意味で、画像とメタデータはプライベートなものではない。実際、それらのサイトの
大半に関する利用者規定は、画像とメタデータをプライベートにしておく責任を負わず、ほとんどの場合では、一旦画像がフォト・シェアリング・サイトにアップロードされると、画像とメタデータはいずれもフォト・シェアリング・サイトの所有物となることを規定している。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、ユーザとグループが画像を共有し、且つ画像とメタデータへのアクセスを制限することを可能にするシステムが要求されている。さらに、そのようなシステムは、画像の所有者の意思に従って画像及びデータへのアクセスを制限するような様式で、ユーザが２以上のプライベート画像保存サイトにわたってサーチを実行することを可能にするようなものであるべきである。本発明はそのような要求を取り扱っている。
【課題を解決するための手段】
【０００７】
本発明は、アクセス制限されたリソース共有システムにおいて、２以上のプライベート・リソース・レポジトリにわたってリソースのサーチを実行する方法である。システムは、ネットワークに接続された、少なくとも１つのサーバノードと多数のピア・ノードとを含んでいる。データデジタル画像を始めとするリソースが、リソースに関連するメタデータとマッチするタームを含むクエリの発行により基づいて、ノードからサーチされる。方法は、リソース及び関連メタデータのストレージを、各々のピア・ノードに維持する工程を含む。関連メタデータは少なくとも１つのメタデータ・ボキャブラリに基づいている。各ピア・ノードは、サーバに、リソースに関連するメタデータ・ボキャブラリがプライベートのものとして指定されていることを示し、それによってアクセス制限されたピア・ノードになる。第１のアクセス制限されたピア・ノードが、第１のアクセス制限されたピア・ノードがどのメタデータ・ボキャブラリをサポートするかをサーバに指定する場合、第１レベルのプライバシーが提供され、それによって、サーバによって受け取られ、且つ指定されたメタデータ・ボキャブラリを使用するサーチ・クエリが、処理のために第１のアクセス制限されたピア・ノードの各々に渡され、指定されたメタデータ・ボキャブラリを使用しないサーチはサーバによって処理される。第１のアクセス制限されたピア・ノードが、第１のアクセス制限されたピア・ノードがどのメタデータ・ボキャブラリをサポートするかをサーバに指定しない場合、第２のレベルのプライバシーが提供され、それによって、サーバによって受け取られたサーチ・クエリが、処理のために第１のアクセス制限されたピア・ノードの各々に渡される。
【０００８】
本明細書に開示した方法及びシステムに従って、本発明はユーザに、ユーザのメタデータのプライバシーを維持しつつ、そのメタデータに基づく画像のサーチをシステムのすべてのノードにわたって実行可能にする方法を提供する。
【発明を実施するための最良の形態】
【０００９】
本発明は、ウェブ・ベースのピアツーピアフォト・シェアリング・サービスを提供する方法及びシステムに関する。以下の説明は、当業者が発明を製造及び使用することを可能にするために示すものであって、特許出願とその要件に即して提供される。好ましい実施形態に関する種々の改変や、本明細書で説明している総括的な原理及び特徴は、当業者に容易に理解されるだろう。したがって、本発明は、示した実施形態に限定されることは意図しておらず、本明細書で説明している原理及び特徴に適合する最も広い範囲に一致することを意図している。
【００１０】
本発明を、メタデータを適用するターゲットがデジタル画像である、好ましい実施形態に関して説明するが、メタデータは任意のタイプのデジタルリソースに適用し得る。
同時係属出願出願番号第０９／９６８，３９３号は、ネットワーク中のすべてのワーク
ステーションとコンピュータが、自身の画像を記憶すると共に、ネットワーク上の他のユーザに対するサーバとして機能する、ウェブ上のピア・ツー・ピアフォト・シェアリング・サービスを提供する。このフォト・シェアリング・サービスは、ピア・サーバとして知られる少なくとも１つの中心サーバを含んでいる。ピア・サーバは、クライアント・コンピュータ又はピア・ノードを通じてユーザに利用可能である。フォト・シェアリング・サービスは、ユーザが、自分のコンピュータ上で画像ストレージを維持することを可能にし、ユーザとゲストが、システムにサポートされた広範なメタデータに基づいて、別のユーザのピア・ノードにわたって画像をサーチすることを可能にする。フォト・シェアリング・サービスの利点は、ユーザが自分の独立したフォト・シェアリング・サイトをセットアップする必要性をなくし、サービス・プロバイダのフォト・シェアリングにより遭遇するストレージの問題を解決し、さらにはサービスのユーザにより遭遇するフォト・シェアリングの使い勝手の問題をも解決する。
【００１１】
図１は、本発明の好ましい実施形態による、ピアツーピア（Ｐ２Ｐ）フォト・シェアリングシステムを示すブロック図である。本発明によれば、システム１０は、ピア・サーバ１４を含む中心フォト・シェアリングウェブサイト１２と、多数のピア・ノード１６とを含んでいる。ピア・サーバ１４と、ピア・ノード１６の各々とは、インターネットを始めとするネットワーク上で互いに通信することができる。好ましい実施形態では、ユーザ１８は、標準ウェブブラウザの使用により、ピア・ノード１６でない装置又はクライアント（図示しない）からも、中心サイト１２にアクセスすることが可能である。
【００１２】
好ましい実施形態では、ピア・ノード１６はウェブサイトかコンピュータのいずれかを表わし、通常、特定のユーザ１８のデジタル画像２０を記憶している。ピア・ノード１６に対するユーザインタフェースは多くの異なる方法で実装することが可能ではあるが、好ましい実施形態では、ピアユーザインタフェースはウェブブラウザとして実装され、代わりに、システム１０のために特に設計されたアプリケーションであってもよい。各ピア・ノード１６は、２以上のユーザの画像２０を記憶し得る。例えば、家庭用ＰＣを共有してはいるが自身の画像を別々に取り扱っている２人の家族のメンバーが、その共有ＰＣ上でシステム１０に関する別々のアカウントを保持してもよい。デジタル画像２０は、画像データを含む画像ファイルとして記憶される。各画像は、画像について記述且つ分類する、該画像に関連するメタデータ２２をさらに有する。メタデータ２２は、以下に説明するように、ユーザ１８によって、又はピア・ノード１６によって自動的に、画像２０に関連付けられ得る。さらに、メタデータ２２の一部又は全部は、画像の捕捉時にデジタルカメラによって画像２０に関連付けられ得る。各画像２０はさらに、サムネイル画像２４と呼ばれる画像データのより小さな表示である特定のタイプのメタデータと関連付けられ得る。
【００１３】
フォト・シェアリング・サービス１０は、ユーザ１８が静止アルバム中に記憶するために自身のコンピュータからウェブサーバまで画像をアップロードすることによりデジタル画像をポストするという従来のフォト・シェアリングモデルとは対照的である。代わりに、上述の実施形態では、フォト・シェアリング・サービス１０、ピア・ノード１６が、実際の画像データのストレージを維持し、各画像のメタデータ２２（及び、特にサムネイル画像２４）のみがピア・サーバ１４にアップロードされる。これにより、ユーザが、問題の画像２０（又は画像のグループ、アルバム、サウンドクリップ、映画、メタデータを有するものなら何でも）を見つけるためにピア・サーバ１４に記憶されたメタデータ２２をサーチするクエリを構築することが可能となる。
【００１４】
例えば、ユーザ１８は、メタデータ２２に基づくサーチ基準の提示（submit）によって、画像２０を閲覧するための画像アルバム２６を動的に作成することができる。例えば図１で、ピア・サーバ１４にメタデータ２２をアップロードすることにより、ユーザ１８ａが中心サイト１２上に共有画像２０を有していると仮定する。その後、サーチ基準とマッ
チするメタデータを有する画像２０を閲覧するために、ユーザ１８ｂはピア・サーバ１４にサーチを提示し得る。これに応答して、ピア・サーバ１４は、サーチ基準とマッチする画像２０に対する画像ロケータ（例えばＵＲＬ）のリストをピア・ノード１６ｂに返し、ピア・ノード１６ｂは、必要に応じて、その画像ロケータを使用して、マッチしている画像を検索する要求を送る。
【００１５】
サーチが行なわれる場所であるサーバ１４にメタデータ２２をキャッシュすることの欠点の１つは、ユーザ１８が自身のメタデータ２２に対する制御を失うことである。本発明は、ピア・ノード１６又はピア・ノード１６のグループが、ピア・サーバ１４でサムネイルを始めとするいかなるメタデータ２２をもキャッシュすることなく、画像２０及びメタデータ２２を記憶することを可能にする拡張機能を、フォト・シェアリングシステム１０に供給することにより、この問題点を解決する。また、この拡張機能により、ユーザは、さらに以下に説明するように、自身のプライベート画像に関連するメタデータ・ボキャブラリを使用して、自身の１又は複数のピア・ノード１６上の画像２０をサーチすることもできる。
【００１６】
本発明によれば、ピア・ノードの所有者は、自身のメタデータ２２と画像２０のプライバシーを守るために使用できる、２つのレベルのプライバシーを有する。いずれのレベルのプライバシーでも、画像２０とメタデータ２２はピア・サーバ１４上でキャッシュされず、ピア・ノード１６は、ピア・ノード１６がプライベートメタデータ２２及び画像２０を含むことをサーバ１４に示す。第１のレベルのプライバシーでは、ピア・ノード１６は、どのメタデータ２２のボキャブラリを、ピア・ノード１６が記憶している画像２０が使用するかを、ピア・サーバ１４に示す。第２のレベルのプライバシーでは、ピア・サーバ１４はどのメタデータ２２のボキャブラリをピア・ノード上の画像２０が使用するかを知らず、ピア・ノードにより高いセキュリティレベルを提供する。
【００１７】
図２は、中心サイトのピア・サーバ１４のコンテンツを示すブロック図である。好ましい実施形態では、ピア・サーバ１４はウェブサーバ・アプリケーション５０、メタデータ・ボキャブラリ・ライブラリ５２、ユーザ・グループ・アカウント・データベース５４、及びキャッシュ５６を含む。
【００１８】
ウェブサーバ・アプリケーション５０は、ピア・ノード１６の能力に適合するようにフォーマットされたページを与える。ウェブサーバ・アプリケーション５０はフォーム駆動型のユーザインタフェース６６を含むが、これはユーザ１８に、根底にあるスキーマ言語を知るためのシンタックスを指定せずにカスタムのメタデータ・ボキャブラリ８４を定義する、容易で直観的な方法を提供する。
【００１９】
メタデータ・ボキャブラリ・ライブラリ５２は、メタデータ・ボキャブラリ８４又はスキーマを記憶及び管理するためのものである。ボキャブラリ・ライブラリ５２は、ユーザ１８によって作成されたカスタムのメタデータ・ボキャブラリ８４と、特定の画像２２に関連しクライアントコンピュータ１６からアップロードされた実際のメタデータ値との両方を記憶する。
【００２０】
好ましい実施形態では、ボキャブラリ・ライブラリ５２は、ユニバーサル・スキーマ、共有スキーマ及びプライベート・スキーマを含み、これらは好ましい実施形態ではＲＤＦとＸＭＬを使用して定義される。システム１０中の画像２０はすべて、ユニバーサル・スキーマによって指定されたメタデータ２２と関連付けられていることが要求される。各メタデータ・ボキャブラリ８４は、そのボキャブラリ中でメタデータ・プロパティを指定し、そのボキャブラリと適合するために遵守されなければならない制約を指定する。ユーザ１８及びグループは、自身のスキーマを定義してもよく、それはユニバーサル・スキーマ
を含んでもよいし、他のボキャブラリ８４から借用してもよい。
【００２１】
キャッシュ５６は、より頻繁にアクセスされる画像２０に関連するメタデータ２２を記憶するために使用され、より迅速なサーチを提供する。メタデータ２２は、キャッシュ５６において、ピア・サーバに構成されたキャッシュポリシーに基づいて、他の画像２０由来のメタデータ２２と自動的に取り替えられ得る。
【００２２】
ユーザ・グループ・アカウント・データベース５４は、各登録ユーザ１８のユーザアカウント及び対応する連絡情報並びにプリファランスを記憶する。ユーザ・グループは、共通のポリシーをさらに共有してもよく、そのようなポリシーには、許可設定、ＵＩオプション、必要な及び任意選択のメタデータ・ボキャブラリ、予約リスト、イベント／通知ポリシー、及びキャッシュポリシーが含まれ得る。
【００２３】
ユーザ・アカウント・データベース５４により、必須の（mandatory ）ボキャブラリ８４が、特定のターゲットリソースに関連づけられる。例えば、ある特定ユーザ１８は、特定のメタデータ２２のセットを有する自身のプライベート・フォトの全部を常に供給されることを望むとする。その人のアカウントは、適切なメタデータ・ボキャブラリ８４をサポートするメタデータの割り当てが、画像２０がシステム１０上に記憶される前に要求されることを示すように構成されるだろう。要求されるメタデータの例として、アカウントの所有者についてのデータ（例えば名前、住所など）のボキャブラリ８４がある。所与のターゲットタイプのためには、多数のボキャブラリ８４が必要となり得る。
【００２４】
デジタル静止画像２０は、ただ一つのターゲットリソースのタイプである必要はない。必要なボキャブラリが指定され得る他のタイプの画像ファイルの例には、低速度撮影（time-lapse) 画像、バースト画像、パノラマ画像のような複数画像のファイルが含まれる。音声ファイル、映画及びテキストドキュメントのような非画像のターゲットリソースもサポートされ得る。本発明は、考えられる限りメタデータが関連付けられたすべてのリソースに適用される。
【００２５】
留意すべきは、ボキャブラリ・ライブラリ５２の使用は、本発明の実施に必要なわけではなく、好ましいということである。この場合、各ユーザ・アカウント・レコードは、２つのレベルのプライバシーをサポートするために必要とされる必要な情報を含んでいる。
【００２６】
本発明の好ましい実施形態によれば、ピア・サーバ１４によって管理される各ユーザ・アカウント・レコードは、プライベート・データ・ボキャブラリ・リスト９０及びプライベート・サーチ・インジケータ９２を含んでいる。プライベート・データ・ボキャブラリ・リスト９０は、どのメタデータ・ボキャブラリ８４をピア・ノード１６が使用するかを識別する。列挙された各メタデータ・ボキャブラリ８４について、ユーザアカウントは、対応するプロパティのリスト（図示しない）も含むだろう。
【００２７】
プライベート・サーチ・インジケータ９２は、ユーザのピア・ノード１６上に記憶された画像によってどのメタデータ・ボキャブラリ８４が使用されるかを、ユーザが明らかにしたいか否かを示すために使用される。好ましい実施形態では、プライベート・サーチ・インジケータ９２は、ピア・ノード１６がプライベートのメタデータ２２を維持している場合には（ＴＲＵＥ）（真）に設定され、ピア・ノードのメタデータ２２がパブリックである場合には（ＦＡＬＳＥ）（偽）に設定される、ブール（Boolean ）型論理である。プライベート・サーチ・インジケータ９２がＴＲＵＥで、プライベートのメタデータ２２を示している場合、ピア・ノードのユーザは、そのプライベート・メタデータ２２を保護するために２つのレベルのプライバシーのうちの１つを使用するという選択肢を有する。
【００２８】
第１のレベルのプライバシーでは、どのメタデータ・ボキャブラリ８４をピア・ノードがサポートするか（即ちどのボキャブラリ８４がピア・ノード１６上の画像２０によって使用されるか）を、ピア・ノード１６がピア・サーバ１４に指定する。その後、ピア・サーバ１４によって受け取られ、且つそのようなボキャブラリ８４を使用するサーチ・クエリが、ピア・ノード１６に送られ、ピア・ノード１６はサーチを取り扱う。その一方で、ピア・ノード１６によってサポートされたボキャブラリ８４からのプロパティを含まないサーチは、サーバ１４によって処理される。この第１のレベルではプライバシーが幾分失われるが、ピア・ノード１６によってサポートされたボキャブラリからのプロパティを含まないサーチが、処理のためにピア・ノード１６に送られることがないので、実行が改善されるという利点がある。
【００２９】
第２レベル（より高いレベル）のプライバシーでは、どのメタデータ・ボキャブラリ８４をピア・ノード１６がサポートするかを、ピア・ノード１６はピア・サーバ１４に指定しない。この場合、ピア・ノード１６のユーザのためにサーバ上に維持されたプライベート・データ・ボキャブラリリスト９０は、空になり、サーバ１４は、従来のアクセス制御フィルタを通るすべてのサーチを、処理のためにピア・ノード１６に渡すだろう。
【００３０】
図３−５は、メタデータを使用してシステム１０中に位置するリソースをサーチしつつ、ピア・ノード１６上のプライベート・メタデータのプライバシーを保証する、３つの異なる技術を示すフローチャートである。図３は、要求中のピア・ノード１６及びサーチされている最中のピア・ノード１６が、いずれも、ファイアウォールによって保護されていてもよいし保護されていなくてもよい、一般的なプライベート・メタデータのサーチ・検索プロセスの第１実施形態を示す。この実施形態では、要求中のピア・ノード１６は、ウェブブラウザ又はクライアントアプリケーションを有する任意の電子機器であってよい。図４及び５は、図３に示したのと同じ機能を提供するが、特定のファイアウォール条件に適合した時に最適化（optimization）を提供する、プライベート・メタデータのサーチ・検索プロセスの代替実施形態を示す。これらのプロセスは、図３に示した一般的方法よりも優れたパフォーマンスを生じ得る。
【００３１】
ここで図３を参照すると、プライベート・メタデータ・サーチを可能にするプロセスは、ステップ１０２で、ユーザがシステム１０における所望の画像又は他のリソースの位置を決定するようサーチ・クエリを構築することを可能にするスクリーンを、ピア・サーバ１４がピア・ノード１６に提示することから始まる。好ましくは、ピア・サーバ１４は、システム１０にサポートされたユーザ選択用のメタデータ・ボキャブラリ８４のリストを表示する。ステップ１０４において、ユーザは、どのメタデータ・ボキャブラリ８４をサーチに使用するかを選択し、そのボキャブラリに対応する問題のプロパティを選択し、システム１０がマッチを見つけようと試みる当該選択されたプロパティに対する値を供給することにより、サーチ・クエリを構築する。
【００３２】
ユーザがクエリの構築を終了したのに応じて、ピア・ノード１６は、ステップ１０６で、ピア・サーバ１４にそのクエリを提示する。その後、図３に示されるように、ピア・サーバはステップ１０８，１１４及び１２０で３つの別個のアクティビティ（任意の順番で、又は並行して）を実行する。それらのステップは、各々の３つのアクティビティの各々における最初のステップである。
【００３３】
第１のアクティビティはステップ１０８で始まる。ステップ１０８で、ピア・サーバ１４はピア・ノード１６によってピア・サーバ１４に送信されたメタデータ２２を含むメタデータ・キャッシュ５６をサーチする。クエリ・ストリングとマッチし、且つ問い合わせ中のユーザがアクセス権限を有する各リソースについて、ステップ１１０で、ピア・サーバ１４は、リソースにアクセスするために要求中のピア・ノード１６が使用するリソース
・ロケータを作成する。ステップ１１２で、ピア・サーバ１４は、ステップ１０８、１１４及び１２０で始まった３つのアクティビティが完了するのを待つ。
【００３４】
第２のアクティビティはステップ１１４で始まる。ステップ１１４で、ピア・サーバ１４はユーザ・アカウント・レコード５４をサーチし、プライベート・メタデータ２２を維持し、且つどのメタデータ・ボキャブラリ８４をピア・ノード１６のリソース（例えば画像）が使用するかを指定する、ピア・ノード１６を見つける。ステップ１１６で、ピア・サーバ１４はリストされたボキャブラリ８４とサーチ・クエリをマッチさせる。ピア・サーバ１４がマッチのあるユーザ・アカウント・レコードを見つけた場合、ステップ１１８で、最終処理のために、ピア・サーバはクエリを対応するピア・ノード１６に送る。
【００３５】
第３のアクティビティはステップ１２０で始まる。ステップ１２０で、ピア・サーバ１４は、プライベート・メタデータ２２がサポートされているがメタデータ・ボキャブラリ８４がピア・サーバ１４に識別されていないことを示す、すべてのユーザ・アカウント・レコード５４の位置を特定する。各マッチするユーザアカウント５４について、ピア・サーバ１４は、ステップ１１８で、処理のためにクエリを対応するピア・ノード１６に送る。
【００３６】
各ピア・ノード１６は、サーチ・クエリを受け取り、ステップ１２２で、リソースをマッチさせるために、そのプライベート・メタデータ２２のデータベースをサーチする。各マッチするリソースについて、ステップ１２４でピア・ノード１６はリソース・ロケータを作成し、ステップ１２６でそれをピア・サーバ１４に返す。ピア・サーバ１４はステップ１１２でそれらの応答を待つ。別の実施形態では、サーチ・クエリを処理したピア・ノード１６は、ピア・サーバ１４がサーチ・クエリを渡す場合にピア・サーバ１４が他のピア・ノード１６に要求中のピア・ノード１６のＵＲＬを送ると仮定して、サーチを要求したピア・ノード１６にいかなるリソース・ロケータをも直接返すこともできる。
【００３７】
ステップ１１２で、ピア・サーバ１４がピア・ノード１６からのクエリに対する応答（又はタイムアウト要求）をすべて受け取る場合、ピア・サーバ１４は、ステップ１２８で、要求中のピア・ノード１６に、すべてのマッチするリソースに対するリソース・ロケータを送る。その後、要求中のピア・ノード１６は、受け取ったリソース・ロケータを使用して、所望のデータをサーチする。
【００３８】
注意：ピア・ノード１６から返された情報を完璧に隠すために、ピア・ノード１６はそれらの応答を暗号化しなければならない。好ましい実施形態では、これは、要求中のピア・ノード１６に関連する公開鍵を使用して行われる。そのような鍵はピア・ノード１６より多くの方法で得ることができる。好ましい実施形態では、要求中のピア・ノード１６は、サーチ・クエリと共にピア・サーバ１４へ鍵を送る。その後、ピア・サーバ１４は、クエリを送る各ピア・ノード１６に鍵を送る。別の実施形態では、公開鍵を、ピア・ノード１６が検索できる既知の位置に記憶しておいてもよい。そのような既知のレポジトリの例は、ＬＤＡＰディレクトリ、Ｖｅｒｓｉｇｎを始めとする認証機関、及びピア・サーバ１４自体である。各ピア・ノード１６は、応答を、クエリ要求に暗号化するだろう。そのような要求は要求中のピア・ノードの秘密鍵でのみ解読することができる。
【００３９】
図４は、ファイアウォールによって保護されていないピア・ノード１６のために最適化された、プライベート・メタデータ・サーチ・検索プロセスの第２実施形態を示すフローチャートである。図３に示したプロセスと同様に、このプロセスは、ピア・ノード１６を保護するファイアウォールの存在にかかわらず機能する。しかしながら、このプロセスは、ほとんどの場合、図３で示した方法よりも、ファイアウォールの背後にないピア・ノード１６の場合に、より優れたパフォーマンスを提供する。要求中のピア・ノード１６はフ
ァイアウォールの背後にあってもよいし、なくてもよい。サーチ・検索プロセスは、クエリ応答がピア・サーバ１４を通るように経路指定されず、むしろ、応答が要求中のピア・ノード１６に直接送られるという点で、追加のプライバシーを提供する。また、ピア・サーバ１４が多くの要求及び応答を処理している場合に、図３のプロセスによって処理されるクエリよりも、より優れたパフォーマンスを提供し得る。この方法のデータの暗号化は、今日最も一般に使用される方法（例えばＳＳＬ接続）により提供することができる。
【００４０】
図４のサーチ・検索プロセスは、ステップ２０２で、システム１０が、ユーザ１８によるクエリの構築を可能にするスクリーンをユーザ１８に提示することから始まる。ステップ２０４で、ユーザ１８は、使用するメタデータ・ボキャブラリ８４を選択し、問題のプロパティを選択し、システム１０がマッチを見つけることを試みる当該プロパティに対する値を供給するにより、サーチ・クエリを構築する。ユーザがクエリの構築を終了したのに応じて、ピア・ノード１６は、ステップ２０６で、ピア・サーバ１４にクエリを提示する。次に、ピア・サーバ１４は、ステップ２０８、２１４及び２２０で３つの別個のアクティビティ（任意の順序で、又は並行に）を実行する。これらのステップは、各々の３つのアクティビティの最初のステップである。
【００４１】
第１のアクティビティは、ステップ２０８で始まる。ステップ２０８で、ピア・サーバ１４はピア・ノード１６によってピア・サーバ１４に送信されたメタデータ２２を含むメタデータキャッシュ５６をサーチする。クエリ・ストリングとマッチし、且つ問い合わせ中のユーザがアクセス権限を有する各リソースについて、ステップ２１０で、ピア・サーバ１４は、リソースにアクセスするために要求中のピア・ノード１６が使用するリソース・ロケータを作成する。ステップ２１２で、ピア・サーバ１４は、ステップ２０８、２１４及び２２０で始まった３つのアクティビティを完了するのを待つ。
【００４２】
第２のアクティビティはステップ２１４で始まる。ステップ２１４で、ピア・サーバ１４がユーザ・アカウント・レコード５４をサーチし、プライベート・メタデータ２２を維持し、且つどのメタデータ・ボキャブラリ８４をピア・ノード１６のリソース（例えば画像）が使用するかを指定する、ピア・ノード１６を見つける。ステップ２１６で、ピア・サーバ１４はリストされたボキャブラリとサーチ・クエリをマッチさせる。ピア・サーバ１４がマッチのあるレコードを見つけた場合、ステップ２１８で、ピア・サーバ１４は要求中のクライアントによって送られたクエリを含むピア・ノード・ロケータを構築する。
【００４３】
ステップ２２０で、ピア・サーバ１４は、プライベート・メタデータ２２をサポートし、且つどこでボキャブラリ８４がピア・サーバ１４に識別されていないかを示す、すべてのピア・ノード・レコードの位置を特定する。ピア・サーバ１４は、サーチ・クエリ中にあるプロパティとマッチするプロパティを含むボキャブラリ８４を有するピア・ノード１６に対するレコードを見つけた場合、ステップ２１８で、ピア・サーバ１４はそれらのピア・ノード１６の各々をポイントする各ピア・ノード・ロケータを作成し、クエリをそのピア・ノード・ロケータ中に埋め込む。
【００４４】
ステップ２１８で、埋込まれたクエリを有するピア・ノード・ロケータをすべて構築し終えた後、ピア・サーバ１４はステップ２１２の待機プロセスに、そのピア・ノード・ロケータを供給する。
【００４５】
ピア・サーバ１４が、ステップ２１２で、ピア・ノード・ロケータ（又はタイムアウト要求）をすべて受け取る場合、ステップ２２２で、ピア・サーバ１４は、要求中のピア・ノード１６に、ピア・ノード・ロケータを送る。その後、ステップ２２４で、要求中のピア・ノード１６は、返されたピア・ノード・ロケータを使用して、リソース・ロケータで識別されたピア・ノード１６にクエリを送る。（注意：ファイアウォールの背後にあるピ
ア・ノード１６は、クエリがピア・プロキシを通じて経路指定されるべきであることを各ピア・ノード・ロケータに示すことにより、サポートされ得る）。
【００４６】
リソース・ロケータのうちの１つの受け取りに応じて、各ピア・ノード１６は、ステップ２２６で、そのメタデータデータベースをサーチし、クエリとマッチするリソースを見つける。見つかったマッチするリソースの各々について、ステップ２２８で、ピア・ノード１６はピア・ノード・ロケータを作成する。ステップ２３０で、ピア・ノードは任意の作成されたピア・ノード・ロケータを、要求中のピア・ノード１６に返す。最後に、ステップ２３２で、要求中のピア・ノード１６は、ピア・ノード・ロケータを使用してリソースをサーチし、クエリの結果をユーザに提示する。
【００４７】
図５は、ファイアウォールによって保護されているピア・ノードのために最適化された、プライベート・メタデータ・サーチ・検索プロセスの第３実施形態を示すフローチャートである。この図５のプロセスは、ファイアウォールによって保護されているピアノード１６とファイアウォールによって保護されていないピア・ノード１６の両方に対して機能するが、ファイアウォールによって保護されていないピア・ノード１６に対する図４のプロセスに対しては実益がない。要求中のピア・ノード１６はファイアウォールで保護されてもよいし、保護されなくてもよい。図４のプロセスと同様に、このプロセスは、クエリ応答がピア・サーバ１４を通るように経路指定されないという点で、図３で示されるプロセスに対して、追加のプライバシーを提供する。また、ピア・サーバ１４が多くの要求及び応答を処理している場合に、図３の方法によって処理されるクエリよりも、より優れたパフォーマンスを提供し得る。この方法のデータの暗号化は、今日最も一般に使用される方法（例えばＳＳＬ接続）により提供することができる。
【００４８】
先の２つの実施形態と同様、サーチ・検索プロセスは、スクリーンをユーザ１８に提示し（ステップ３０２）、ユーザ１８がサーチ・クエリを構築する（ステップ３０４）ことから始める。一旦要求中のピア・ノード１６がピア・サーバ１４にクエリを提出すると（ステップ３０６）、ピア・サーバ１４はステップ３０８，３１６，３２２で最初に開始された３つのアクティビティを実行する。
【００４９】
第１のアクティビティは、ステップ３０８で始まる。ステップ３０８で、ピア・サーバ１４はピア・ノード１６によってピア・サーバ１４に送信されたメタデータ２２を含むメタデータキャッシュ５６をサーチする。クエリ・ストリングとマッチし、且つ問い合わせ中のユーザがアクセス権限を有する各リソースについて、ステップ３１０で、ピア・サーバ１４は、リソースにアクセスするために要求中のピア・ノード１６が使用するリソース・ロケータを作成する。ステップ３１２で、ピア・サーバ１４は、要求中のピア・ノード１６にすべてのリソース・ロケータを送る。
【００５０】
第２のアクティビティはステップ３１６で始まる。ステップ３１６で、ピア・サーバ１４がユーザ・アカウント・レコード５４をサーチし、プライベート・メタデータ２２を維持し、どのメタデータ・ボキャブラリ８４がピア・ノード１６のリソース（例えば画像）を使用するかを指定する、ピア・ノード１６を見つける。ステップ３１８では、ピア・サーバ１４はリストされたボキャブラリとサーチ・クエリをマッチさせる。ピア・サーバ１４がマッチのあるユーザ・アカウント・レコードを見つけた場合、ステップ３２０で、ピア・サーバ１４は対応するピア・ノード１６に、要求中のピア・ノード１６に対するリソース・ロケータと共に、クエリを送る。
【００５１】
第３のアクティビティはステップ３２２で始まる。ステップ３２２で、ピア・サーバ１４は、プライベート・メタデータ２２がサポートされ、且つメタデータ・ボキャブラリ８４がピア・サーバ１４に識別されていないことを示す、すべてのユーザ・アカウント・レ
コード５４の位置を特定する。各マッチするユーザ・アカウント５４について、ステップ３２０で、ピア・サーバ１４は対応するピア・ノード１６に、要求中のピア・ノード１６に対するリソース・ロケータと共に、クエリを送る。
【００５２】
各ピア・ノード１６は、サーチ・クエリを受け取り、ステップ３２４で、リソースをマッチさせるために、そのプライベート・メタデータ２２のデータベースをサーチする。各マッチするリソースについて、ステップ３２６で、ピア・ノード１６はリソース・ロケータを作成する。ステップ３２８で、各ピア・ノード１６は、ピア・サーバ１４から受け取った要求中のピア・ノード１６のリソース・ロケータを使用して、要求中のピア・ノード１６とのネットワーク接続を確立する。各ピア・ノード１６はこの接続を使用して、要求中のピア・ノード１６に対して作成したリソース・ロケータを送る。この接続は、必要な場合に、要求中のピア・ノード１６が要求することを可能にするために、オープンにされる。
【００５３】
ステップ３１４で、要求中のピア・ノード１６は、ピア・サーバ１４及びピア・ノード１６からすべてのリソース・ロケータを集める。要求中のピア・ノード１６がすべてのリソース・ロケータを受け取るか、又は、タイムアウト期間が満了した後で、要求中のピア・ノード１６はリソース・ロケータを使用して、クエリの結果をユーザに提示するために必要とされるデータをサーチする。
【００５４】
ユーザのメタデータ及び画像のプライバシーを守るピアツーピアフォト・シェアリング・サービスについて開示した。本発明は、示した実施形態に従って説明したが、当業者には実施形態に対するバリエーションがあり、任意のバリエーションが本発明の精神及び範囲にあることが容易に認識されるだろう。従って、当業者には、特許請求の範囲の精神及び範囲から逸脱することなく、多くの改変をなし得るであろう。
【図面の簡単な説明】
【００５５】
【図１】本発明の好ましい実施形態によるネットワーク上のフォト・シェアリングシステムを示すブロック図。
【図２】中心サイトのピア・サーバのコンテンツを示すブロック図。
【図３】メタデータを使用してシステム中に位置するリソースをサーチしつつ、ピア・ノード上のプライベートメタデータのプライバシーを保証する、３つのプロセスを示すフローチャート。
【図４】メタデータを使用してシステム中に位置するリソースをサーチしつつ、ピア・ノード上のプライベートメタデータのプライバシーを保証する、３つのプロセスを示すフローチャート。
【図５】メタデータを使用してシステム中に位置するリソースをサーチしつつ、ピア・ノード上のプライベートメタデータのプライバシーを保証する、３つのプロセスを示すフローチャート。
【図１】
2005522786.tif 000003
【図２】
2005522786.tif 000004
【図３】
2005522786.tif 000005
【図４】
2005522786.tif 000006
【図５】
2005522786.tif 000007
【国際調査報告】
2005522786.tif 000008