(57)【要約】      （修正有）【課題】デジタル文書の処理専用のＰ２Ｐローカルアプリケーションを持っているか否かを前もって知る必要なしに、一定の方法で受信者であるクライアントデバイスに通知する方法を提供する。【解決手段】アクセス方法は、次のステップ、すなわち、i)受信側クライアントデバイスが、デジタル文書を処理することができるローカルアプリケーションを備えているかどうかを検出するのに適した、少なくとも１つの実行可能なコマンドを含む、ネットワーク上で利用可能な少なくとも１つのデジタル文書の存在を示す通知を受信するステップと、ii)ローカルアプリケーションを検出するために１つ以上のコマンドを実行するステップと、iii)検出した場合は、ローカルサーバからデジタル文書へアクセスするのに対して、検出しなかった場合は、リモートサーバのアドレスからその文書へアクセスするステップと、を有する。【選択図】図２
2005122693.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアントデバイスを互いにリンクする通信ネットワーク上で利用可能な少なくとも１つのデジタル文書にアクセスするための方法であって、
前記アクセス方法は、受信側クライアントデバイスの上で実行され、該方法は、
i)前記受信側クライアントデバイスが、前記デジタル文書を処理可能なローカルアプリケーションを備えているかどうかを検出するのに適した、少なくとも１つの実行可能なコマンドを含む通知であって、前記ネットワーク上で利用可能な少なくとも１つのデジタル文書が存在することを示す通知を受信するステップと、
ii)前記ローカルアプリケーションを検出するために１つ以上のコマンドを実行するステップと、
iii)検出された場合は、ローカルサーバから前記デジタル文書にアクセスし、検出されなかった場合は、リモートサーバのアドレスから前記デジタル文書にアクセスするステップと
を有することを特徴とする方法。
【請求項２】
前記通知は、更に、前記デジタル文書を指定する識別子及びリモートサーバを指定するリモートアドレスを少なくとも１つ含む、マークアップ言語で記載されたページを少なくとも１ページ有することを特徴とする請求項１に記載の方法。
【請求項３】
ローカルアプリケーションが存在しアクティブではなかった場合、選択された実行可能なコマンドに従って前記ローカルアプリケーションの起動を続けるようにするステップiib)をステップii)の後であってステップiii)の前に更に有することを特徴とする請求項１に記載の方法。
【請求項４】
前記文書が前記ネットワーク上に見つからなかった場合は、ローカルサーバ上の前記文書の存在を確認するようにして、見つかった場合は、それをダウンロードし、提供する前にローカルに保存するステップiv)をステップiii)の後に更に有することを特徴とする請求項１に記載の方法。
【請求項５】
前記ページのアダプテーションは、ローカルサーバのアドレスにマークアップ言語で記述されているリンク変数を設定することを含み、ローカルサーバのアドレスから前記文書にアクセスできるように、マークアップ言語で記述された前記ページがローカルに適応するようにすることを特徴とする請求項２に記載の方法。
【請求項６】
前記ページのアダプテーションは、リモートサーバのアドレスに、マークアップ言語で記述されているリンク変数を設定するということを含み、リモートサーバのアドレスから前記文書にアクセスできるように、マークアップ言語で記述された前記ページがローカルに適応するようにすることを特徴とする請求項２に記載の方法。
【請求項７】
実行可能な１つ以上のコマンドが、通知に従って前記ページに組み込まれており、ステップii)において前記ページが解釈されることを特徴とする請求項２に記載の方法。
【請求項８】
ローカルサーバを指定するローカルアドレスは、前記ローカルサーバの構造パラメータを検索することに適した１つ以上のコマンドによって判断することを特徴とする請求項２に記載の方法。
【請求項９】
ローカルプログラムを必要とするマークアップ言語で記載された前記ページに含まれる、１つ以上のコマンドが、前記ローカルサーバの前記構造パラメータを検出するのと同様に該ローカルサーバの検出に適していることを特徴とする請求項２に記載の方法。
【請求項１０】
前記ページが、電子メールの添付ファイルとして通知されることを特徴とする請求項２に記載の方法。
【請求項１１】
前記ページが、選択されたリモートサーバ上にダウンロードされ、そのページへのレファレンスが、通知されるどのような受信者に送信されることを特徴とする請求項２に記載の方法。
【請求項１２】
複数のクライアントデバイスを互いにリンクする通信ネットワークの上で、利用可能なデジタル文書をシェアする方法であって、
該方法は送信側クライアントデバイス上で実行され、
前記ネットワーク上で利用可能な少なくとも１つのデジタル文書が存在するということを知らせる通知を、少なくとも１つの受信側クライアントデバイスに送信するステップであって、前記通知は、前記受信側クライアントデバイスが、前記デジタル文書を処理可能なローカルアプリケーションを備えているか否かを検出するステップと、
存在が検出された場合は、ローカルサーバのアドレスから前記文書にアクセスし、それ以外の場合はリモートサーバのアドレスから前記文書にアクセスするステップと
を有することを特徴とするシェア方法。
【請求項１３】
前記通知が、前記デジタル文書を指定する少なくとも１つの識別子と、リモートサーバを指定するリモートアドレスを含むマークアップ言語で記述されたページを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
複数のクライアントデバイスを互いにリンクする通信ネットワークの上で利用可能な少なくとも１つのデジタル文書にアクセスする装置であって、
前記アクセス装置は、受信側クライアントデバイスに組み込まれており、
該アクセス装置は、前記ネットワーク上で利用可能な少なくとも１つのデジタル文書の存在を示す通知を受信し、前記通知は前記デジタル文書を処理可能なローカルアプリケーションを備える前記受信側クライアントデバイスが存在するか否かを検出するのに適した、少なくとも１つの実行可能なコマンドを含んでいる受信手段と、
前記ローカルアプリケーションを検出するためにコマンドを実行する実行手段と、
検出した場合は、ローカルサーバから前記デジタル文書へアクセスするのに対して、検出しなかった場合は、リモートサーバから前記文書へアクセスする処理手段と
を備えることを特徴とするアクセス装置。
【請求項１５】
前記通知は、前記デジタル文書を指定する少なくとも１つの識別子及びリモートサーバを指定するリモートアドレスを含む、マークアップ言語で記述されたページを少なくとも１ページ有することを特徴とする請求項１４に記載の装置。
【請求項１６】
前記処理手段は、前記ローカルサーバのアドレスにマークアップ言語で記述されたリンク変数を設定し、該処理手段が、前記ローカルサーバアドレスから前記文書にアクセスできるように、マークアップ言語で記述された前記ページがローカルで適応するのに適していることを特徴とする請求項１５に記載の装置。
【請求項１７】
前記処理手段が、前記リモートサーバのアドレスにマークアップ言語で記述されたリンク変数を設定し、該処理手段が、リモートサーバのアドレスから前記文書にアクセスできるように、マークアップ言語で記述された前記ページがローカルで適合するのに適していることを特徴とする請求項１５に記載の装置。
【請求項１８】
実行可能な１つ以上のコマンドが、通知に従って前記ページに組み込まれており、前記ページが解釈されることを特徴とする請求項１５に記載の装置。
【請求項１９】
電子メールの添付ファイルとして前記ページが通知され、更に電子メール処理アプリケーションを備えていることを特徴とする請求項１５に記載の装置。
【請求項２０】
複数のクライアントデバイスを互いにリンクする通信ネットワーク上でデジタル文書をシェアする装置であって、
該シェア装置は送信側クライアントデバイスに組み込まれており、
該デジタル文書シェア装置は、前記ネットワーク上で利用可能なデジタル文書を少なくとも１つ存在することを示す通知を、少なくとも１つの受信側クライアントデバイスに送信する送信手段を備え、
前記通知は、前記デジタル文書を処理可能なローカルアプリケーションを備えているかどうかを検出するのに適した、少なくとも１つの実行可能なコマンドを含み、存在が検出された場合は、ローカルサーバのアドレスより前記文書へアクセスし、それ以外の場合はリモートサーバのアドレスより前記文書へアクセスすることを特徴とする装置。
【請求項２１】
前記通知が、前記デジタル文書を指定する少なくとも１つの識別子、及びリモートサーバを指定するリモートアドレスを含むマークアップ言語で記述されたページを更に有することを特徴とする請求項２０に記載のデジタル文書シェア装置。
【請求項２２】
コンピュータシステムによって読み取り可能な情報媒体であって、その全部または一部がリムーバブル式の場合であって、特にＣＤ−ＲＯＭ、ハードディスクやディスケットのような磁気媒体、或いは電気信号または光学信号シグナルのような伝送可能な媒体であって、プログラムがコンピュータシステムによりロードされ、また実行された際に、請求項１に記載の方法に従って実行可能なことを特徴とする媒体。
【請求項２３】
情報媒体に組み込まれているコンピュータプログラムであって、前記プログラムはプログラムがコンピュータシステムによりロードされ、また実行された際に、請求項１に記載の処理方法を実行することを可能にすることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のクライアントデバイスを互いにリンクする通信ネットワーク上で利用可能な、少なくとも１つのデジタル文書へのアクセス及びシェア或いはそのどちらかに関するものである。前記方法は、そのネットワーク上で利用可能なデジタル文書の有無を知らせる通知を利用する方法であり、その通知は、デジタル文書を処理可能なローカルアプリケーションの適応及びそのデジタル文書が存在するかどうかということに適している。
【０００２】
通信ネットワーク上で利用可能なデジタル文書の処理では、一般的なアプリケーションが存在する。特に、ピア・ツー・ピアタイプの通信ネットワークは、以下のごとくＰ２Ｐという頭文字で表される。
【０００３】
Ｐ２Ｐ通信システムは、近年、ファイルシェアリングの分野において、従来のクライアント・サーバモデルとに比して明らかな発達を遂げている。Ｐ２Ｐシステムにおいては、通信ネットワークを構成する各マシン（ノード又はピアとも称される）は、サーバデバイスとしてはもとより、クライアントデバイスとしても機能する。したがって、Ｐ２Ｐネットワーク上では、それらのデバイスは全て同等にシェアするという原理にしたがって、すなわち、Ｐ２Ｐネットワークの各マシンはクライアント及びサーバとして機能し、それらに共通な状態でリソースを動かす。そのようなネットワークは、リソースが中央のサーバデバイスに格納される従来のクライアント・サーバネットワークと、このようにして区別される。
【０００４】
現在、データの分配は、安価な設備や、ネットワーク接続されたコンピュータが大変多数存在するため、またブロードバンド接続が発達したために、Ｐ２Ｐネットワークにますます依存している。
【０００５】
しかしながら、Ｐ２Ｐネットワークは不安定である。この原因は、クライアントデバイスが（そして、必然的にサーバデバイスも）定期的にネットワーク接続及び切断を繰り返し、その結果、非常に予測し難いデータの有無をレンダリングするからである。更に、クライアント及びサーバデバイス、或いはそのいずれかのアドレスが予測不能となり、また接続のたびにアドレスが異なってしまう傾向がある。
【０００６】
このような特異性があるため、一般にＰ２Ｐシステムは、併せてＰ２Ｐローカルアプリケーションとも称されるローカルの専用クライアントアプリケーションを利用する。そのようなＰ２Ｐローカルアプリケーションは、Ｐ２Ｐネットワーク上で利用可能なデジタル内容を検索し、アクセスすることと同様にデジタルコンテンツのシェアを確実に行う。
例えば、Ｐ２Ｐローカルアプリケーションは、固有のプロトコルに従い、ネットワーク上の新しいデジタルコンテンツをシェアしたばかりの１人またはそれ以上のクライアントデバイスへ通知することを可能にするために、メッセージの交換に基づく通知メカニズムを提供しうる。
【０００７】
また、Ｐ２Ｐローカルアプリケーションは、通知のための主なメカニズムとして或いは専用通知システムの補助として電子メールを利用しうる。この場合、電子メールには一人または複数の受信者の元にあるＰ２Ｐローカルアプリケーションによって解釈された、１つ以上の固有な添付ファイルが含まれていてもよい。
【０００８】
また、Ｐ２Ｐシステムは、どんなＰ２Ｐローカルアプリケーションも有しない利用者が、ブラウザやインターネットナビゲータ等のような、より従来式で広く知られているインターネットアクセスツールを用いて、ネットワーク上のコンテンツにアクセスすることを可能にするものであるということは周知である。
【０００９】
そのようなシステムでは、ネットワーク上のある特定のサーバデバイスかクライアントデバイスが、インターネットアクセスツール（ブラウザ、エクスプローラ、ナビゲータ）やＰ２Ｐネットワークの間でゲートウェイの役割を果たすサーバデバイスとして機能する。それらのマシンは、インターネットツールのためにＰ２Ｐネットワーク上で求められたリソースを検索するという役割を担うプロキシデバイスとしてみなれる。これらのシステムでは、電子メールは通知メカニズムとして従来どおり利用される。そして、電子メールにはマークアップ言語で書かれたページか、その電子メールの受信者であるユーザ情報にアクセスするためのリンク（”Uniform Resource Locator”の頭文字からＵＲＬとも称される）が含まれる。
【００１０】
したがって、Ｐ２Ｐシステム上で、Ｐ２Ｐローカルアプリケーションを利用して、ユーザはネットワーク上のデジタルコンテンツをシェアし、またＰ２Ｐネットワーク上で利用可能なコンテンツを読んだり、アクセスすることができる。
【００１１】
また、Ｐ２Ｐローカルアプリケーションをもたないユーザ、或いは提供されているインターフェースの利用を望まないユーザは、デジタルコンテンツにアクセスためにマークアップ言語で表示できるツール（マークアップ言語でかかれたページを表示することができるウェブエクスプローラ、電子メールリーダ、あるいは他のアプリケーション）を利用しうる。
【００１２】
例えば、ユーザは、グループ内の人たちとデジタルコンテンツのコレクション（collection）をシェアするかもしれないが、それは、Ｐ２Ｐローカルアプリケーションをもっているか否かに関わらず可能である。
【００１３】
本出願人は、前記受信者が、デジタル文書の処理専用のＰ２Ｐローカルアプリケーションをもっているか否かということを前もって知る必要なしに、一定の方法で受信者であるクライアントデバイスに通知する方法を提供するという問題に取り掛かった。本発明はまさにこの問題の解決するための方法である。
【００１４】
その方法は、複数のクライアントデバイスを互いにリンクする通信ネットワーク上で利用可能な少なくとも１つのデジタル文書にアクセスする方法に関するものであり、当該アクセス方法は、受信側クライアントデバイス上で実行される。本発明の概要によると、前記方法は、以下のステップを有することを特徴とする。すなわち、
i)デジタル文書を処理可能なローカルアプリケーションを受信側クライアントデバイスが有するか否かを検出するのに適した、少なくとも１つの実行可能なコマンドを含む、ネットワーク上で利用可能な少なくとも１つのデジタル文書の存在を示す通知を受信するステップ。
ii)ローカルアプリケーションが存在するか、そしてそれが利用可能な状態であるかを検出するために１つ以上のコマンドを実行するステップ。
iii)ローカルアプリケーションが存在し、またそれがアクティブであった場合は、ローカルサーバからデジタル文書にアクセスするのに対し、ローカルアプリケーションが存在しない、或いは使用可能な状態ではない場合は、リモートサーバからデジタル文書にアクセスするステップ、である。
【００１５】
このように、前記方法は、ネットワーク上のユーザ全員に、誰がローカルアプリケーションを保持しているか否かを通知する。より詳細には、前記方法は、アプリケーションを保持していないユーザも共存しながら、そのローカルアプリケーションが利用可能な状態になるとすぐに、デジタル文書を閲覧するためのローカルアプリケーションを利用可能にしようと検索することにより、通知を通してネットワークの利用を最適化するものである。
【００１６】
従って、ローカルアプリケーションとその受信者の有無に応じて、閲覧時に送られる通知に含まれる情報を修正するようにする。
【００１７】
実際には、通知は、マークアップ言語で記述されている、デジタル文書を指定する少なくとも１つの識別子及びリモートサーバを指定するリモートアドレスを含むページを更に有している。
【００１８】
ある実施形態によると、前記方法は、ステップii）の後、ステップiii）の前に、ローカルアプリケーションは存在しているがアクティブではない場合に、選択された実行可能なコマンドを受けて、受信側クライアントであるユーザの承認に加えて、ローカルアプリケーションをアクティブにするようにする、ステップiia)を有する。
【００１９】
また別の実施形態として、前記方法は、ステップii）の後、ステップiii）の前に、ローカルアプリケーションは存在しているものの、アクティブではない場合に、選択された実行可能なコマンドに従い、ローカルアプリケーションを自動的にアクティブにするようにするステップとして、更にステップiib)を有する。
【００２０】
さらに別の実施形態によると、前記方法は、ステップiii)の後に、ローカルアプリケーションが存在し、またアクティブな場合に、ローカルサーバ上に文書が存在することを確かめるようになっており、そして、前記文書が存在しなかった場合にネットワーク上を探し、またネットワーク上に存在した場合はそれをダウンロードし、アクセス要求に応じてそれを供給する前に、ローカルに保存するステップとして、更にステップiv)を有する。
【００２１】
別の実施形態によると、ローカルアプリケーションが存在しアクティブな場合に、ローカルサーバのアドレスからデジタル文書にアクセスできるように、マークアップ言語で記述されたページがローカルで適応するようにする。実際には、ページのアダプテーション（adaptation）は、ローカルサーバのアドレスをマークアップ言語で記述されているリンク変数に設定するということを含む。
【００２２】
更に、また別の実施形態によると、ローカルアプリケーションが存在しないか或いはアクティブでない場合、リモートサーバのアドレスからデジタル文書にアクセスできるように、マークアップ言語で記述されたページがローカルで適応するようにする。実際には、ページのアダプテーションはリモートサーバのアドレスに、マークアップ言語で記述されたリンク変数の設定をすることを含む。
【００２３】
実際には、通信ネットワークは、集結しているか、分散しているか、或いはその両方が混合しているピア・ツー・ピアタイプのものである。
【００２４】
例えば、そのページは、ＨＴＭＬタイプか、それと同様のマークアップ言語で記述されているか、或いはマークアップ言語で記述されたページにActive Xタイプ、或いはActive Xタイプと同様のローカルプログラムを呼び出すコマンドが含まれており、そのページは、前記ローカルサーバに関する構造パラメータを検索することはもとより、ローカルサーバの存在とそれがアクティブな状態であるかを確かめることに適応している。
【００２５】
例えば、実行可能な１つ以上のコマンドはJavaScriptやVB Scriptなどのスクリプトプログラムタイプの言語で記述されたものかもしれないが、このように通知されたページに前記１つ以上のコマンドはこのようにしてページに組み込まれている。
【００２６】
例えば、ローカルサーバを指定するローカルアドレスは、前記ローカルサーバの構造パラメータを検索するのに適したスクリプト言語プログラムによって確認することもできる。
【００２７】
前記コマンドは、更に、文書にアクセス可能にするローカル或いはリモートアドレスをリンクするのに適した機能を有する。
【００２８】
実際には、そのページは電子メールの添付ファイルとして通知される。
【００２９】
別の方法によると、前記ページは選択されたリモートサーバへダウンロードされ、そしてそのページへのレファレンスは、通知を受けることになっているすべての受信者へ送られ、例えばＵＲＬ形式等によるそのページへのレファレンスは、電子メール記載される。
【００３０】
本発明は、また、複数のクライアントデバイスを互いにリンクする通信ネットワーク上において、デジタル文書をシェアする方法に関するものであり、前記方法はクライアントデバイス上で送信する際に実行される。
【００３１】
本発明の別の態様によると、前記方法は以下のステップを有する。すなわち、
- ネットワーク上で、利用可能な少なくとも１つのデジタル文書が存在するということを知らせる通知を、少なくとも１つの受信クライアントデバイスに送信し、前記通知は、受信クライアントデバイスが、デジタル文書を処理することが可能なローカルアプリケーションを有しているか否かを検出し、そしてローカルアプリケーションが存在し、アクティブな場合は、ローカルサーバのアドレスから前記文書にアクセスし、それ以外の場合はリモートサーバのアドレスから前記文書にアクセスするのに適した少なくとも１つの実行可能なコマンドを有する。
【００３２】
また、本発明は、本発明に関するアクセス方法に従って実行されるのに適した、少なくとも１つのデジタル文書にアクセスするためのデバイスに関する。
【００３３】
同様に、本発明は、前述したシェア方法を実行するのに適したデジタル文書シェア装置に関する。
【００３４】
本発明は、また、コンピュータシステムによって読み取り可能な情報媒体に関するものであり、その全部または一部はリムーバブル式の場合があって、特にＣＤ−ＲＯＭ、ハードディスクやディスケットなどの磁気媒体、或いは電気信号または光学信号などのような伝送可能な媒体であり、プログラムがコンピュータシステムによりロードされ、また実行された際に、本発明に関する方法の実行を可能にする、コンピュータプログラムの指示を有することを特徴とする。
【００３５】
最後に、本発明は、また、情報媒体に組み込まれているコンピュータプログラムに関するものであり、前記プログラムはプログラムがコンピュータシステムによりロードされ、また実行された際に、本発明に従った処理方法の実行を可能にする指示を備える。
【００３６】
本発明の他の特徴及び長所は、以下の詳細な説明及び図面の見解においても現れている。すなわち、
- 図１は、本発明に関するアクセス方法に従い、実行するために適した受信側クライアントデバイスの必須要素を示すダイヤグラムである。
- 図２は、本発明に関する複数のクライアントデバイスを互いにリンクする通信ネットワークを示すダイヤグラムである。
- 図３は、本発明に関するマークアップ言語で記述されたページを閲覧することに関するステップを説明するためのフローチャートである。
- 図４は、本発明に関するローカルアプリケーションが使用可能であるかどうかを検証することに関するステップを説明するためのフローチャートである。
- 図５は、本発明に関するローカルサーバの動作を説明するためのフローチャートである。
【００３７】
図１に関して、本発明を実行する装置は、例えばマイクロコンピュータ１０、或いはデジタルムービングイメージカメラ１１（もしくはスキャナ、他のイメージのようなデジタル文書を取得または記録する装置）のような、様々な周辺機器に接続されたワークステーションのような装置であるが、入出力カード（図示せず）に接続され、当該装置へマルチメディアデータを供給する。
【００３８】
装置１０は、例えば以下のようないくつかの要素に接続された通信バス１０１を備える。それらは、
- 中央処理装置１０２（マイクロプロセッサ、図１に示されたＣＰＵ)、
- 本発明に関するプログラムを含むことのできるリード・オンリー・メモリ１０３、
- 出力後、発明を実行するのに必要な変数やパラメータを記録するのに適したレジスタのみならず、本発明に関する方法の実行可能なコードを含むランダム・アクセス・メモリ１０４、
- キーボード１０６或いはポインティングデバイス、例えばマウス１０７や光学スタイラス（図示せず）のような他の装置を用いて、本発明に関するプログラムを相互に作用することができる、データを表示するため、またはユーザとのグラフィックインターフェイスとして供給するため、或いはその両方のためのスクリーン１０５、
- 本発明が実行される際にデータを使用したり、データを作成したりするのみならず、本発明に関するプログラムを格納することができるハードディスク１０８、
- ディスケット１２を受け、読み込み或いは書き込みをするのに適し、その後、本発明に従って、データが処理されるか或いは処理待ちの状態となるディスクドライブ１０９、及び
- 通信ネットワーク１３に接続されて、そのインターフェースはデータを送受信することに適している通信インターフェース１１０である。
【００３９】
オーディオデータの場合は、装置１０は、さらにマイクロホン１４に接続されている入出力カード（図示せず）を備えていてもよい。
【００４０】
通信バス１０１は、装置１０に含まれている、或いはそれに接続されている異なる要素の間で、通信及び相互運用性を提供する。バスの表示は非制限的であり、そして、特に中央処理をすることは、装置１０のいかなる要素への命令を直接、或いは装置１０の他の要素を媒介して伝達することができる。
【００４１】
ディスケット１２は、再書き込み可能かどうかは問わず、コンパクトディスク（ＣＤ−ＲＯＭ）、ＺＩＰディスク或いはメモリーカードなど、いかなる情報媒体でも置き換えることが可能である。
【００４２】
一般に、マイクロコンピュータやマイクロプロセッサによって読み込み可能な情報蓄積装置は、一体化しているか、或いはデバイスの中にはなく、そしてことによるとリムーバブルであるかもしれないものであるが、本発明に関する方法を実行することを可能にする、１つ以上のプログラムを格納するのに適している。
【００４３】
前記装置が、本発明を実施可能にしている前記実行可能なコードは、同時におそらく、リード・オンリー・メモリ１０３内、ハードディスク１０８上、或いは前述のとおりディスケット１２のようなリームーバブルデジタル媒体上に格納される。
【００４４】
別の方法によると、前記プログラムの実行可能コードは、通信ネットワーク１３の媒介から受信し、インターフェース１１０を通じて、実行する前に、装置１０うちの１つの格納装置（ハードディスク１０８）に格納される。
【００４５】
中央処理装置１０２は、命令或いは本発明に関する１つ以上のプログラムのソフトウェアコードの一部の実行を制御、指示し、これらの命令は前記格納装置の１つに格納されている。
【００４６】
動作が開始されると、１つ以上のプログラムが、例えばハードディスク１０８のような不揮発性のメモリ、或いはリード・オンリー・メモリ１０３に格納され、それらは本発明を実行するために必要な変数及びパラメータを格納するレジスタと同じく、ランダム・アクセス・メモリ１０４（ＲＡＭ）に伝送される。そのプログラムには、本発明に関する１つ以上のプログラムの実行可能なコードが含まれる。
【００４７】
本発明に関するデバイスを備える装置は、プログラムされた装置でもよいことに留意すべきである。そして、この装置は、例えば、１つ以上の特定用途向け集積回路（ＡＳＩＣ）に記憶されているような、コンピュータプログラムのコードを含む。
【００４８】
図２に示すように、通信ネットワーク１３はクライアント１（２１）、クライアント２（２２）、およびクライアント３（２３）として個別化されるいくつかのクライアントデバイスや端末と接続する。それぞれのクライアントデバイスは、ブロードバンドまたはナローバンド通信手段など（ｘＤＳＬモデム、ＰＳＴＮまたはケーブル）の異なった通信手段によってネットワーク１３に接続できる。ネットワーク１３は、ローカル・エリア・ネットワーク（ＬＡＮ）上やその両方の組合せのように、インターネットネットワークの上においても、同様にうまく構成することができる。
【００４９】
クライアントデバイスの端末は、２つの異なったカテゴリに分類される。これらには、専用の”ピア・ツー・ピア”Ｐ２Ｐアプリケーションが提供される端末（クライアント２とクライアント１）或いは、専用の”ピア・ツー・ピア”Ｐ２Ｐアプリケーションを提供されない端末（クライアント３）のいずれかである。
【００５０】
専用の”ピア・ツー・ピア”Ｐ２Ｐアプリケーションが提供される端末は、それらの間において、通信ネットワーク１３を通じて、そしてその技術の分野における通常の知識を有する者に知られているトポロジーの１つ（集結しているか、セントラルサーバ”スーパーピアーズ”の有無に関わらず分散しているか、或いはその両方か）に従って、”ピア・ツー・ピア”Ｐ２Ｐタイプの通信ネットワークを形成する。
【００５１】
”ピア・ツー・ピア”Ｐ２Ｐアプリケーションは、クライアントデバイス２１におけるレファレンス２１８、或いはクライアントデバイス２２におけるレファレンス２２８を有する、少なくとも１つのサーバモジュールを備える。Ｐ２Ｐアプリケーションは、さらに、記憶手段或いはキャッシュ２１７、２２６を備える。
【００５２】
サーバモジュール２１８或いは２２８には、”ピア・ツー・ピア”リソースへのアクセスのためのリクエストに応じるタスクが与えられる。そのリクエストは、サーバと同じ端末上にあるアプリケーションの場合と同じように、リモートアプリケーションからもうまく届くことができる。
【００５３】
インターネットで一般的に利用されるＨＴＴＰ（ハイパー・テキスト・トランスファー・プロトコル）に従った、”ピア・ツー・ピア”アプリケーション固有のプロトコルによって、そのリクエストはおそらく同じようにうまく届く。
【００５４】
記憶手段２１７、２２６は、サーバモジュール２１８、２２８の補助によって、”ピア・ツー・ピア”ネットワーク上でシェアされるデジタルコンテンツを含む。”ピア・ツー・ピア”アプリケーションは、またＰ２Ｐ専用のローカルクライアントローカルアプリケーション（２１９、２２９）の補助を受けて、”ピア・ツー・ピア”ネットワーク上でデジタルコンテンツを検索、アクセス、閲覧そしてシェアすることを可能にする、インターフェースを提供する。
【００５５】
すべての端末は、専用の”ピア・ツー・ピア”アプリケーション提供されるか否かに関わりなく、ＨＴＴＰ通信プロトコルの助けを得て、デジタルコンテンツにアクセスするために、ＨＴＭＬタイプのマークアップ言語を閲覧することを可能にするツール（２２７、２３７）を利用することができる。
【００５６】
１つ以上の特定のプロキシ／ゲートウェイサーバ２４は、ネットワーク１３に接続することができ、これらのサーバは、専用”ピア・ツー・ピア”クライアントを持たず、ＨＴＴＰ通信プロトコルを利用しているクライアントに、”ピア・ツー・ピア”ネットワークへのエントリーポイントを提供する。
【００５７】
”ピア・ツー・ピア”ネットワークのリソースをリクエストされた場合、プロキシサーバ２４は、”ピア・ツー・ピア”ネットワークのマシンのなかで、リソースをリクエストしそうなものを１つ以上割り出す。そして、そのリクエスタ（requester）に前記マシンのうちの１台をリダイレクトするか、或いはリクエスタに代わって前記マシンのうちの１台からリソースを取り戻し、そしてそれをプロキシタイプサーバのようなリクエスタに提供する。
【００５８】
プロキシ／ゲートウェイサーバのこの役割は、それぞれ２１と２２の番号が付されているクライアントデバイス１及び２のような、専用の”ピア・ツー・ピア”アプリケーションを有していれば、クライアントデバイス自身でもまた実行することができることに留意すべきである。
【００５９】
本発明によると、マシン２１に接続されているユーザが、マシン２１のディスク２１７上に存在する、イメージ１、イメージ２、およびイメージ３として個別化されたイメージで構成されたデジタルコンテンツの新しいコレクションを、クライアント２２及び２３と共にシェアすることを希望した場合、前記３つのイメージで構成された新しいコレクションを作成し、シェアするために、Ｐ２Ｐローカルアプリケーション２１９を利用する。
【００６０】
シェア中に、Ｐ２Ｐローカルなアプリケーション２１９は、それぞれのイメージについて、独自の識別子イメージ１ＩＤ、イメージ２ＩＤ、イメージ３ＩＤに関連付ける。その技術の分野における通常の知識を有する者ならばよく知っているツールにより、ほとんど重複する可能性なしに、識別子を作り出すことが可能になる。
【００６１】
”ピア・ツー・ピア”アプリケーション特有の実際のシェア操作の後、Ｐ２Ｐローカルアプリケーション２１９は、新しいコレクションを説明するページ２５を、デジタルデジタルコンテンツの新しいコレクションはネットワーク上で利用可能であるということを、クライアント２２と２３に通知するために、ＨＴＭＬマークアップ言語で生成する。このＨＴＭＬページには、JavaScriptのような少なくともいくつかのスクリプト２５２と、それぞれの新しくシェアされたデジタルコンテンツ２５３の識別子のレファレンスが含まれている。
【００６２】
ＨＴＭＬページ２５がひとたび作り出されると、ユーザが、新しくシェアしたデジタルコンテンツの存在を、知らせたいすべての人へそのページを送ることができる（クライアント２及びクライアント３の例を参照）。
【００６３】
好適な実施形態において、ユーザは、そのＨＴＭＬページ２５を電子メールの添付ファイルとして送信する。
【００６４】
他の実施形態では、ユーザは、そのＨＴＭＬページ２５を、サーバ２４などのサーバにダウンロードする。さらに、ユーザは、前記サーバ上にあるそのＨＴＭＬページを指定するレファレンスを、通知したいと思う全ての人に、例えば電子メールにＵＲＬを含める形式などで送信する。受信者は、サーバ２４から通知として受信したレファレンスを用いて（前述のＵＲＬ）、ＨＴＭＬページ２５をダウンロードする。
【００６５】
ユーザは、受信者へＨＴＭＬページを送信することを可能にするような他のいかなる方法をも、同じようにうまく利用することができる（例えば、”ピア・ツー・ピア”ファイルエクスチェンジシステム、ＨＴＭＬを含むディスケットを物理的に郵送するなど）。
【００６６】
ＨＴＭＬページ２５を受信し、受信者が、アプリケーション２２７及び２３７を用いて表示する場合、そのアプリケーションは、すなわちインターネットナビゲータ、電子メールリーダ、或いはＨＴＭＬページを解釈し、表示を可能にする他のいかなるアプリケーションのことであるが、そのページのコンテンツが解釈され、そして実行可能なコード（スクリプト）は実行されたページに含まれている。
【００６７】
最初のコードには、専用の”ピア・ツー・ピア”Ｐ２Ｐローカルアプリケーションがインストールされているかどうかを判断するというタスクが与えられている。
【００６８】
もしも、専用のアプリケーションがインストールされていた場合は、最初のコードは、ＨＴＭＬページの外部にある２番目のコードを用いて（例えば、active X）、そのアプリケーションによって利用されたネットワークポートに結び付けられている数などの、”ピア・ツー・ピア”アプリケーション上の構造情報を検索する。次に、最初のコードは、その３番目のコード変数を初期化するが、それにはＨＴＭＬページ２５に３番目のコードが埋め込まれており、デジタルコンテンツへアクセスするために利用するＵＲＬアドレスを作成するタスクが与えられている。
【００６９】
３番目のコードは、シェアされたデジタルコンテンツをそれぞれ参照するためのＨＴＭＬページを解釈する際に呼び出される。もしも、１番目のコードにより、”ピア・ツー・ピア”ローカルサーバ２２８が、インストールされておりアクティブであると検知された場合、３番目のコードは、”ピア・ツー・ピア”ローカルサーバへ導くＵＲＬが記載されたＨＴＭＬコードを返す（図２におけるクライアント２のケースＣ１）。前記ＵＲＬは、http://localhost:80/RUIDという形式であり、ここでRUIDとは、シェアされたリソースの独自な識別子を意味する。
【００７０】
もしも、”ピア・ツー・ピア”ローカルサーバ２２８が、マシン２２上に存在しないかアクティブでない場合は、３番目のコードは、ｈｔｔｐウェブリクエストと、”ピア・ツー・ピア”プロキシ／ゲートウェイウェブ／サーバ２４のような”ピア・ツー・ピア”ネットワーク間のゲートウェイを提供する、所定のリモートサーバへ導くＵＲＬのＨＴＭＬコードを送り返す（図２におけるクライアント３のケース及びクライアント２のケースＣ２）。
【００７１】
返送されたＵＲＬの形式は、http://www.server.com/RUIDであり、www.server.comは、サーバ２４のウェブアドレスを意味し、RUIDは、シェアされたリソースの独自の識別子を意味する。
【００７２】
本発明は、従って、受信者が”ピア・ツー・ピア”アプリケーションを有しているか否かによって、通知のコンテンツ（ＨＴＭＬページ２５）を適応させることができる。
【００７３】
この例では、デバイスクライアント３（２３）は、”ピア・ツー・ピア”アプリケーションを有していない。このケースでは、シェアされたデジタルコンテンツへの全てのアクセスは、従ってプロキシサーバ２４に向けられる。
【００７４】
他方では、デバイスクライアント２（２２）に関して、デジタルコンテンツへのアクセスは、”ピア・ツー・ピア”サーバ２２８がアクティブで（ケースＣ１）あった場合は、”ピア・ツー・ピア”サーバ２２８へ直接導かれ、そしてアクティブではない場合（ケースＣ２）は、プロキシサーバ２４ヘ直接へ導かれる。
【００７５】
利用可能であるとすぐに”ピア・ツー・ピア”サーバを利用することの利点は、データが”ピア・ツー・ピア”サーバ上にすでにキャッシュされている場合、特にネットワークへアクセスしないことである。さらに、デジタルコンテンツが”ピア・ツー・ピア”ローカルサーバを通してアクセスされるならば、前記コンテンツは、その結果、サーバ上のキャッシュに存在することになり、従ってその代わりにリモートマシンへ提供されることとなる。”ピア・ツー・ピア”ネットワークにある、特定のデジタルコンテンツを提供することができるマシンの数は、従って増加する。その結果、マシンがいつ何時切断されたときでも、ネットワーク上の特定のデジタルコンテンツを、どんなときでも見つけることができる可能性は増加する。
【００７６】
図３に示すフローチャートは、”ピア・ツー・ピア”ローカルサーバがマシン上で存在しておりアクティブかどうかを判断するタスクが与えられているスクリプトの作用を図解したものである。
【００７７】
このスクリプトは、###が利用する言語を意味する＜SCRIPT LANGUAGE=###＞ と ＜/SCRIPT＞のＨＴＭＬタグによって制限されたスクリプト２５２の形式か、或いは外部ファイルへのレファレンスの形式で、ＨＴＭＬページ２５に組み込まれる。
【００７８】
そのスクリプトは、ＨＴＭＬページが毎回表示されるたびに解釈され、実行される。
【００７９】
ステップＳ３０２では、「ピア・ツー・ピア」アプリケーションが、マシンにインストールされているか否かを確かめることからそのスクリプトが始まる。これに関しては、そのスクリプトは、active Xプログラムか、”ピア・ツー・ピア”アプリケーションの拡張モジュール（プラグイン）形成部分の存在を検知しようとする。
【００８０】
例えば、検出するプログラムがactiveXであるならば、以下のVBscriptプログラムによって定義される関数を呼び出すことができる。すなわち、
＜SCRIPT LANGUAGE="VBscript"＞
＜!--
Function detectActiveXControl(activeXControlName)
on error resume next
detectActiveXControl = False
detectActiveXControl = IsObject(CreateObject(activeXControlName))
End Function
rem --＞
＜/SCRIPT＞
である。
【００８１】
前記関数detectActiveXControlは、パラメータとしてactiveXという名称を解釈し、activeXがマシン上に存在している場合はTrue、さもなければFalseとする。
【００８２】
ステップＳ３０３では、アプリケーションがマシンの上に存在していないとして検出されたならば、アルゴリズムは、Ｓ３０８に進んで、変数が、ＨＴＭＬページ使用の以下の処理におけるそれがリモートサーバ２４に向けられるＵＲＬで作られていなければならないことを示すように設定する。
【００８３】
これに反して、Ｐ２Ｐアプリケーションが検出されたならば、前記スクリプトは、ステップＳ３０４において、”ピア・ツー・ピア”ローカルサーバ２２８が現在アクティブであるかどうか（すなわち、実行中であるか）を判断する。このため、現在の”ピア・ツー・ピア”サーバ２２８の構成を検索するために、レジスタや構成ファイルを調べて、前のステップにおいて検出されたactiveXプログラムを利用する。
【００８４】
例えば、activeXプログラムは、サーバ２２８が受信しているネットワークポートの数を検索する。もしも、後者がアクティブでないならば、ポートの値はゼロである。もしも、その値がゼロでないならば、ステップＳ３０９において、サーバ２２８が受信しているポート番号を含む変数を設定する。
【００８５】
ステップＳ３１０では、ＨＴＭＬページ２５利用の次の処理において、デジタルコンテンツにアクセスするために、ローカルサーバ２２８へ導くＵＲＬアドレスで作られなくてはならないということを意味する変数をスクリプトが設定する。
【００８６】
例えば、GetRegValueがactiveX MpActiveXVBの関数であって、レジスタがアクセスされることを可能にするものであるならば、以下のプログラムは、ローカルサーバがアクティブか否かを判断し、そしてそのポート番号を検索するために利用することができる（ステップＳ３０４及びＳ３０９）。すなわち、
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
var IsLocalServerActive = false;
var LocalServerPort = 80;
function CheckLocalServer()
{
LocalServerPort = MpActiveXVB.GetRegValue("SOFTWARE\\LocalServer\\Config\\ListenPort}");
if(LocalServerPort != 0)
{
return true;
}
return false;
}
IsLocalServerActive=CheckLocalServer();
// --＞
＜/SCRIPT＞
である。
【００８７】
もしも、サーバ２２８が、Ｓ３０４でアクティブでないことを検出した場合、そのプログラムはユーザに対して、activeXの関数を用いてダイアログボックスを開くことにより、”ピア・ツー・ピア”ローカルサーバ２２８を立ち上げるよう勧めることができる。
【００８８】
もしも、ユーザがその提案を受け付ける場合は、ステップＳ３０７で、ローカルサーバを立ち上げるために、activeXの関数が呼び出される。
【００８９】
ステップＳ３１１では、ＨＴＭＬページ２５の解釈が継続される。
【００９０】
図４に示されるように、ＨＴＭＬページ２５が、インターネットナビゲータ或いは電子メールリーダ（２２７、２３７）のようなアプリケーションによって解析されるたびに、そのページに埋め込まれているJavaScript関数が、前記デジタルコンテンツにアクセスするために使用するＵＲＬアドレスを提供するために、デジタルコンテンツを参照するたびに呼び出される。
【００９１】
ＨＴＭＬページにおける、前記関数の呼出しは以下の形式をとる。すなわち、
＜SCRIPT LANGUAGE="JavaScript"＞ GetRessourceAddress('abcde23404-3143492ef-23232', 'blue_mountain.jpg');
＜/SCRIPT＞
である。
【００９２】
タグ＜SCRIPT LANGUAGE= ###＞は、ＨＴＭＬページを実行するコードの始まりを示すが、ここで、###には利用する言語の種類（例えば、JavaScriptかVBScript）を記載する。タグ＜/SCRIPT＞は、実行するコードの終わりを示す。
【００９３】
ここのGetRessourceAddressは、呼び出すJavaScript関数名に対応している。この関数は、関数拡張子”.js”で終わっており、それ自体がＨＴＭＬページで参照されているような名称の外部ファイルか、或いは直接ＨＴＭＬページの冒頭の部分において（すなわち、タグ＜HEAD＞と＜/HEAD＞で、はさまれているヘッダにおいて、タグ＜SCRIPT LANGUAGE="JavaScript"＞と＜/SCRIPT＞で、はさまれたJavaScriptコードの部分において）、予め定義されていなければならない。
【００９４】
最初のケースにおいて、スクリプトを提供するサーバの名称が”www.server.com”であり、そして、その関数の定義を含むファイルが”mp.js”という名称で、そのファイルがサーバ上の”スクリプト”フォルダにおいて検出されたならば、ＨＴＭＬページの”mp.js”ファイルを含むコマンドは以下のとおりである。すなわち、
＜SCRIPT LANGUAGE="JavaScript"
src="http://www.server.com/script/mp.js"＞＜/SCRIPT＞
である。
【００９５】
図４は、ＵＲＬアドレスを提供するタスクが与えられている、JavaScript関数GetRessourceAddressの作用について説明している。
【００９６】
JavaScriptの対応するコードは以下のとおりである。すなわち、
function GetRessourceAddress(resID, title)
{
if(isLocalServerActif == false)
{
document.write("＜A HREF=http://www.server.com/");
document.write(resID);
}
else
{
document.write("＜A HREF=http://localhost:");
document.write(localServerHTTPPort);
document.write("/");
document.write(resID);
}
document.write("＞");
document.write(title);
document.write("＜/A＞");
}
である。
【００９７】
キーワード「function」は、新しい関数を作成することを示す。その名称はGetRessourceAddress hereであり、その関数にはパラメータとしてresIDとtitleの２つの変数がある。JavaScriptには、document.write(#) と名付けられたコマンドがあり、そのコマンドによって、ここに示された情報を細切れに、ＨＴＭＬページを解釈する間にプログラムに送ることを可能にする。従って、送信された情報はインタプリタが理解しやすいように、ＨＴＭＬフォーマットでなくてはならない。
【００９８】
isLocalServerActifとlocalServerHTTPPortは、あらかじめ初期化されたJavaScript変数を表すワードである（図３）。最初の関数は、”ピア・ツー・ピア”ローカルサーバが、マシン上で現在インストールされており、またアクティブであるということを示し、そして２番目の関数は、”ピア・ツー・ピア”ローカルサーバが待機しているポート番号を示す。
【００９９】
本発明によると、そのアルゴリズムは以下のとおりである。
【０１００】
パラメータとしてGetRessourceAddressと示したJavaScript関数は、少なくともリソース独自の識別子を持っており、resIDと示されるそのリソースは、ＨＴＭＬページ２５のリソースを参照するたびに呼び出される（ステップＳ４０１）。
【０１０１】
ステップＳ４０２では、その関数は、”ピア・ツー・ピア”ローカルサーバが、isLocalServerActifによって指示された変数の値を確認することにより、図３のアルゴリズムによって検出されたかどうかを確認する。
【０１０２】
ステップＳ４０３では、もしも現在アクティブな”ピア・ツー・ピア”ローカルサーバが存在しないということを変数が示した場合（変数の値がｆａｌｓｅの場合）、次にステップＳ４０４で、プロキシ／ゲートウェイタイプのサーバ２４に対応している、所定のアドレスを通じて、リソースへのアクセスが可能になるＵＲＬが、その関数によって提供される。そのＵＲＬは、例えば、www.server.comといったものである。
【０１０３】
JavaScript関数のコード及び前記実施形態に基づいて、関数より提供されたＨＴＭＬコードは以下のとおりである。すなわち、
＜A HREF=http://www.server.com/abcde23404-3143492ef-23232＞ 'blue_mountain.jpg'＜/A＞である。
【０１０４】
このコードは、blue_mountain.jpg という名称のハイパーテキストリンクとアドレスhttp://www.server.com/abcde23404-3143492ef-23232へのリンクを意味する。
【０１０５】
ステップＳ４０３では、もしも変数がマシン上で”ピア・ツー・ピア”ローカルサーバが存在しテいることを示し（変数の値がtrueの場合）、次にステップＳ４０５において、その関数は、ここではプロキシの役割を果たすローカルサーバ（図５）を通じてリソースにアクセスできるＵＲＬを提供する。そして、関数によって提供されるＨＴＭＬコードは以下の通りである。すなわち、
＜A HREF=http://localhost:90/abcde23404-3143492ef-23232＞'blue_mountain.jpg'＜/A＞
である。ここで、localServerHTTPPortは、値９０を有すると仮定する。
【０１０６】
別の方法として、デジタルコンテンツを参照するたびにJavaScript関数GetRessourceAddressを呼び出すのではなく、相対ＵＲＬ（relative ＵＲＬ）の形式で記載することもできる。そのとき、レファレンスのためのＨＴＭＬコードの例は、以下の形式をとることができる。すなわち、
＜A HREF=abcde23404-3143492ef-23232＞ 'blue_mountain.jpg'＜/A＞
である。
【０１０７】
従って、デジタルコンテンツを参照するたびにJavaScript関数GetRessourceAddressを繰り返し呼び出すことは、ＨＴＭＬページ２５のヘッダ内に、タグ＜BASE＞を定義をするというタスクが与えられたJavaScriptルーチンを一回呼び出すことに都合よく置き換えられる。このタグは、相対URLを解決（resolve）する基底ＵＲＬ（basic ＵＲＬ） として利用される、絶対ＵＲＬ（absolute ＵＲＬ）を定義する。
【０１０８】
JavaScript関数は、マシン上でアクティブな”ピア・ツー・ピア”ローカルサーバが存在しない場合（変数isLocalServerActifの値がFalseの場合）、プロキシ／ゲートウェイタイプのサーバ２４へリンクされるタグ＜BASE＞を提供する。その場合、関数から提供されるＨＴＭＬコードは以下のとおりである。すなわち、
＜BASE HREF=http://www.server.com/＞
である。
【０１０９】
もしも、マシンの上にアクティブな”ピア・ツー・ピア”ローカルサーバが存在する場合（変数isLocalServerActifの値がtrueの場合）は、JavaScript関数はローカルサーバ２２８へリンクする＜BASE＞タグを提供する。その場合、関数から提供されるＨＴＭＬコードは以下のとおりである。すなわち、
＜BASE HREF=http://localhost:90/＞
であり、変数localServerHTTPPortの値は９０と想定する。
【０１１０】
図５には、ローカルサーバ２２８と２１８の作用が記述されている。
【０１１１】
本発明によると、”ピア・ツー・ピア”ローカルサーバが、デジタルコンテンツＲのリクエストを受信すると（Ｓ５１１）、それは、ステップＳ５１２において、そのリクエストがリモートアプリケーション（通信ネットワーク上の他のマシン上に存在する）からか、或いはローカルアプリケーション（そのサーバと同じマシン上で作動している）から届いたものかどうかを判断する。それは、リクエスタのＩＰアドレスを調べて、それ自身のＩＰアドレスと比較することにより、この情報を判断する。もしも、２つのアドレスが同じであるか、或いはリクエスタのアドレスが127.0.0.1（ループバックアドレス）の場合は、リクエスタがローカルに存在するか、そうでなければ、リモートリクエスタであるということを意味する。
【０１１２】
もしも、リクエスタがローカルに存在するならば、そのサーバはステップＳ５１３へ進み、検索されたデータＲがディスク上においてローカルには存在しないのかどうかを確認する。もしも、データがローカルに存在する場合は、それはリクエスタに送られる（ステップＳ５１７）。もしも、データがローカルに存在しない場合、サーバは、その技術の分野における通常の知識を有する者に知られている技術を使用して、”ピア・ツー・ピア”ネットワーク上のリソースの検索を実行する（ステップＳ５１４）。ステップＳ５１５で、データがネットワーク上で見つかった場合は、サーバは、ステップＳ５１６でデータＲをダウンロードし、ディスク上のキャッシュ内においてそれをローカルにセーブして、ステップＳ５１７でそれをリクエスタに送り返す。反対のケースの場合は、サーバは、データが利用できないであることを示すために、ステップＳ５１８でリクエスタにエラーを返送する。
【０１１３】
もしも、リクエスタがリモートに存在する場合、ステップＳ５１９で、サーバは、リソースがそのディスク上でローカルに利用可能であるかどうかを確認する。
【０１１４】
もしも、そのデータが利用可能であるならば、それはステップＳ５２０でリクエスタに送り返される。反対のケースの場合は、要求が、例えば、インターネットナビゲータ（[x]が、[y]によって確認されるマシンに関するリソースへのアクセスパスであるＵＲＬ http://y/x の形式、またはその要求における、特定のヘッダの形式におけるもの）から来るウェブ要求であるかどうか、或いは独占”ピア・ツー・ピア”プロトコルによって、それが要求であるかどうかがステップＳ５２１で検証される。
【０１１５】
そして、それがウェブ要求であるならば、サーバはステップＳ５２２で、”ピア・ツー・ピア”ネットワークに関するデータの検索を実行する。マシン２４のプロキシ／ゲートウェイ作用は、ここでまた検出することができる。
【０１１６】
ステップＳ５２３では、リソースが”ピア・ツー・ピア”ネットワーク上でローカライズされるならば、そのサーバは、リソースをダウンロードしないが、反対にステップＳ５２４において、以下のようなＨＴＴＰプロトコルを用いた簡単な形式のフォーワーディング・オーダー（forwarding order）を用いて、リソースを検索されたマシンへリクエスタをリダイレクトする。すなわち、
HTTP/1.1 302 See other URI
Location:http://nnn/zzz 
である。
【０１１７】
最初のキーワードhttp/1.1は、プロトコルのタイプとバージョンを示すことを可能にしている。３０２は、リソースがサーバ上で一時的に利用できないことを示す、特定のエラー値である。表示されうるコメントは、そのエラーコードに従う。Location:は、２番目のキーワードであり、それはインターネットナビゲータに対して、それ自体を他のＵＲＩへリダイレクトすることを示すものである。[nnn]は、リソースを取得するためにコンタクトするマシンへのアドレスであり、そして、[zzz]は、マシン[nnn]上のリソースへのアクセスパスである。
【０１１８】
ステップＳ５２３では、もしもリソースが”ピア・ツー・ピア”ネットワーク上に存在しない場合、ステップＳ５２５においてサーバは、前のステップと同様にフォーワーディング・オーダーを用いて所定のマシンへリクエスタをリダイレクトする。所定のマシンは、要求されたリソースを利用できなかったケースについて、例えば、ユーザに後で自分のリクエストを更新するように勧める、所定のレスポンスを送り返すことにより対応するというタスクが与えられている。
【０１１９】
もしも、ステップＳ５２１で、それがインターネットナビゲータから来るウェブリクエストではなく、専用の”ピア・ツー・ピア”アプリケーションから来るリクエストならば、サーバはリクエスタにエラーを返送する。
【０１２０】
例えば、ＨＴＭＬページには、以下のコンテンツがあるかもしれない。すなわち、
＜HTML＞
＜HEAD＞
＜SCRIPT LANGUAGE="VBscript"＞
＜!--
detectableWithVB = False
If ScriptEngineMajorVersion ＞= 2 then
detectableWithVB = True
End If
Function detectActiveXControl(activeXControlName)
on error resume next
detectActiveXControl = False
If detectableWithVB Then
detectActiveXControl = IsObject(CreateObject(activeXControlName))
End If
End Function
rem --＞
＜/SCRIPT＞
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
var pluginFound = false;
pluginFound = detectActiveXControl('MpActiveXVB.MpRegistry');
alert('MpActiveXVB found = ' + pluginFound);
if (pluginFound)
{
// Insert reference to activeX in HTML page
document.write("＜OBJECT ID=");
document.write('\"MpActiveXVB\"');
document.write("CLASSID=");
document.write('\"CLSID:443E61FC-4AC1-49EC-A89A-F99EA5EE72A2\"＞');
document.writeln("＜/OBJECT＞");
} 
// --＞
＜/SCRIPT＞
＜/HEAD＞
＜BODY＞
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
var isLocalServerActif = false;
var localServerHTTPPort = 80;
function CheckServer()
{
if (pluginFound)
{
isLocalServerActif = MpActiveXVB.GetRegValue("SOFTWARE\\Classes\\CLSID\\{443E61FC-4AC1-49EC-A89A-F99EA5EE72A2}");
if(isLocalServerActif == false)
{
alert('Server Not Found');
}
else
{
localServerHTTPPort = MpActiveXVB.GetRegValue("SOFTWARE\\localserver\\config\\port");
alert('Server Port Value: ' + localServerHTTPPort);
}
}
}
function GetRessourceAddress (imageID, title)
{
document.writeln("");
document.writeln("Process the image ID...");
if(isLocalServerActif == false)
{
document.write("＜A HREF=http://www.server.com/");
}
else
{
document.write("＜A HREF=http://localhost:");
document.write(localServerHTTPPort);
document.write("/");
}
document.write(imageID);
document.write("＞＜IMG SRC=");
document.write(title);
document.write("BORDER=0 ALT=");
document.write(title);
document.writeln("＞＜/A＞");
}
CheckServer ();
// --＞
＜/SCRIPT＞
＜NOSCRIPT＞
＜H1＞No JavaScript＜/H1＞
You see this text if JavaScript is disabled or unimplemented.
＜/NOSCRIPT＞
＜SCRIPT LANGUAGE="JavaScript"＞
GetRessourceAddress ('abcde23404-3143492ef-23232', 'blue_mountain.jpg');
GetRessourceAddress ('fffffeeeaa-bbe478999-aaaaa', 'red_mountain.jpg');
＜/SCRIPT＞
＜/BODY＞
＜/HTML＞
である。
【０１２１】
本発明により得ることのできる様々な効果の中で、受信者の能力に応じて、すなわち、専用のＰ２Ｐローカルアプリケーションを有しているかどうかによって、通知のコンテンツを適応させる必要はないということを、強調できる。さらに、ローカルアクセスかリモートアクセスかが、ユーザにとって大変わかりやすい。同様に、ユーザのインターネット設定を変更する必要がない（この場合、プロキシサーバかプロキシのアドレス）。最後に、Ｐ２Ｐアプリケーションを有するクライアントデバイスが、電子メールによって受信する通知のコンテンツを表示するために、そのローカルサーバをアクティブにしておかなくてもよく、ローカルサーバの有無によって、通知の表示が自動的に適応する。
【図面の簡単な説明】
【０１２２】
【図１】
2005122693.tif 000003
【図２】
2005122693.tif 000004
【図３】
2005122693.tif 000005
【図４】
2005122693.tif 000006
【図５】
2005122693.tif 000007
【手続補正書】
【提出日】平成16年10月6日(2004.10.6)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０１２２
【補正方法】変更
【補正の内容】
【０１２２】
【図１】本発明に関するアクセス方法に従い、実行するために適した受信側クライアントデバイスの必須要素を示すダイヤグラムである。
【図２】本発明に関する複数のクライアントデバイスを互いにリンクする通信ネットワークを示すダイヤグラムである。
【図３】本発明に関するマークアップ言語で記述されたページを閲覧することに関するステップを説明するためのフローチャートである。
【図４】本発明に関するローカルアプリケーションが使用可能であるかどうかを検証することに関するステップを説明するためのフローチャートである。
【図５】本発明に関するローカルサーバの動作を説明するためのフローチャートである。
【外国語明細書】
Title of the Invention
Method of accessing and sharing a digital document in a P2P communication network
The present invention relates to accessing and/or sharing a digital document available in a communication network linking client devices together, said method utilizing a notification indicating the presence of a digital document available on the network, the notification being suitable for adaptation and for exploiting the presence or not of a local application able to process the digital document.
It has general application in the processing of digital documents available in a communication network, in particular communication networks of peer-to-peer type, designated hereinafter by the acronym P2P.
P2P communication systems have emerged in recent years constituting a revolution in file sharing in comparison with the conventional client-server model. In P2P systems, each machine (also termed node or peer) constituting the communication network acts as a client device as well as a server device. Thus, in a P2P network, the apparatuses put resources in common according to a philosophy of sharing as coequals, each machine of a P2P network acting both as client and as server. Such networks are thus distinguished from conventional client-server networks in which the resources are archived in a central server device.
Currently, the distribution of data relies increasingly on P2P networks due to their low-cost installation, the presence of very numerous computers connected to the networks, and due to the development of broadband connections.
However, P2P networks are unstable. This is because client devices (and consequently server devices) connect and disconnect periodically to the network, thus rendering the presence of data highly unpredictable. Furthermore, the addresses of client and/or server devices are unpredictable and liable to be different at each connection.
Due to their specificity, P2P systems generally imply the utilization of a local, dedicated client application, also termed a P2P local application. Such a P2P local application ensures the sharing of digital content, as well as searching and accessing the digital content available on P2P networks.
For example, the P2P local application may provide a notification mechanism based on the exchange of messages according to a proprietary protocol in order to enable a client device to notify one or more persons that it has just shared new digital contents on the network.
The P2P local application may also utilize electronic mail as a main mechanism for notification or as a supplement to the proprietary notification system. In this case, the electronic mail may possibly contain one or more specific files as attachments which may be interpreted by the P2P local application at the recipient or recipients.
P2P systems are also known which enable users not having any P2P local application to access the content on the network with the aid of Internet access tools that are more conventional and widespread such as browsers or Internet navigators.
In such systems, certain specific server devices or client devices in the network act as server devices playing the role of gateway between the Internet access tool (browser, explorer, navigator) and the P2P network.  These machines may be viewed as proxy devices which take on the task of retrieving the resource sought on the P2P network for the Internet tool. In these systems, email is utilized conventionally as a notification mechanism. The email may then contain a page in markup language or a link (also termed a URL from "Uniform Resource Locator") to a page enabling the recipient user to access the resources.
Thus, in a P2P system, a user may utilize a P2P local application to share digital content over the network, and to browse and access the content available on the P2P network.
The user not having the P2P local application or the user not wishing to utilize the interface provided may also utilize tools capable of viewing pages in markup language to access the digital content (Web explorer, email reader, or any other application capable of displaying pages in markup language).
For example, the user may share collections of digital content with a group of persons, it being possible for those persons to have the P2P local application or not.
The Applicant set itself the problem of providing a method enabling recipient client devices to be notified in a uniform manner without having to know a priori whether said recipients posses a P2P local application dedicated to the processing of digital documents.
A solution to this problem is precisely what the present invention provides.
It relates to a method of accessing at least one digital document available on a communication network linking client devices together, said accessing method being implemented on a recipient client device.
According to a general definition of the invention, the method comprises the following steps:
i)   receiving a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document;
ii)  executing the command or commands in order to detect the presence and activation of the local application; and
iii) in case a local application is present and active, accessing the digital document from a local server whereas in case of absence or inactivity of the local application, accessing the document from a remote server.
Thus, the method uniformly notifies the users of a network who posses or do not posses the local application. More particularly, the method optimizes the utilization of the network via the notification by seeking to enable the utilization of the local application to view digital documents as soon as that application is available with a user while remaining compatible with those who do not posses that local application.
Thus, provision is made to modify the information contained in the notification at the time of its viewing depending on the presence or not of the local application with the recipient.
In practice, the notification further comprises a page in markup language containing at least one identifier designating the digital document, and a remote address designating a remote server.
According to one embodiment, the method further comprises, at the issue of step ii) and prior to step iii), the step iia) in which, in case a local application is present and inactive, provision is made to proceed with the activation of the local application further to an authorization by the user of the recipient client device granted in response to a chosen executable command.
As a variant, at the issue of step ii) and prior to step iii), the method further comprises the step iib) in which, in case a local application is present and inactive, provision is made to proceed automatically with the activation of the local application in accordance with a chosen executable command.
According to another embodiment, the method further comprises, after step iii), the step iv) in which, in case a local application is present and active, provision is made to verify the presence of the document on a local server, and in case of negative verification to search for said document on the network, to download it in case of positive search, and to save it locally before serving it in response to the request for access.
According to another embodiment, in case a local application is present and active, provision is made to locally adapt the page in markup language so as to access the document from the address of a local server.  In practice, the adaptation of the page comprises the setting of a linking variable in markup language to the address of a local server.
According to still another embodiment, in case a local application is absent or inactive, provision is made to locally adapt the page in markup language so as to access the document from the address of a remote server. In practice, the adaptation of the page comprises the setting of a linking variable in markup language to the address of a remote server.
In practice, the communication network is of peer-to-peer type, centralized, decentralized, or hybrid.
For example the page may be written in markup language of HTML type or similar, or the commands included in the page in markup language calling on a local program of activeX type or similar, adapted to determine the presence and activation of a local server, as well as to retrieve the configuration parameters of said local server.
For example, the executable command or commands may be of Script program type such as Java Script or VB Script, the said command or commands being embedded in the page thus notified.
For example, the local address designating a local server may be determined by the Script program adapted to retrieve the configuration parameters of said local server.
The command further comprises a function adapted to link a local or remote address enabling the document to be accessed.
In practice, the page is notified as an attachment with an email. 
According to a variant form, the page is downloaded onto a chosen remote server and a reference to that page is sent to any recipient to be notified, the reference of the page being, for example, of URL type, included in an email.
The present invention also relates to a method of sharing a digital document in a communication network linking client devices together, said method being implemented on a sending client device.
According to another aspect of the invention, the method comprises the following step:
-  sending to at least one recipient client device a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document, and in case a local application is present and active, to access the document from the address of a local server otherwise to access the document from the address of a remote server.
The present invention also relates to a device for accessing at least one digital document adapted to implement the accessing method according to the invention.
Similarly, the present invention also relates to a device for sharing a digital document adapted to implement the method of sharing mentioned above.
The present invention also relates to an information carrier readable by a computer system, possibly wholly or partly removable, in particular a CD-ROM or magnetic medium, such as a hard disk or a diskette, or a transmissible medium, such as an electrical or optical signal, characterized in that it comprises instructions of a computer program enabling the implementation of the method according to the invention, when the program is loaded and run by a computer system.
Finally, the present invention also relates to a computer program stored on an information carrier, said program comprising instructions enabling the implementation of a processing method in accordance with the invention, when that program is loaded and run by a computer system.
Other features and advantages of the invention will appear in the light of the following detailed description and drawings in which:
-  Figure 1 is a diagram of the essential elements of a recipient client device adapted to implement the accessing method according to the invention;
-  Figure 2 is a diagram of a communication network linking client devices together according to the invention;
-  Figure 3 is a flowchart illustrating the steps relative to the viewing of a page in markup language according to the invention;
-  Figure 4 is a flowchart illustrating the steps relative to the verification of the activation of the local application according to the invention; and
-  Figure 5 is a flowchart illustrating the behavior of a local server according to the invention.
With reference to Figure 1, an apparatus implementing the invention is for example a microcomputer 10 or a workstation connected to different peripherals such as a digital moving image camera 11 (or a scanner, or any other means of acquiring or storing digital documents such as images) connected to an input/output card (not shown) and supplying multimedia data to the apparatus.
The apparatus 10 comprises a communication bus 101 to which there are connected several elements such as:
-  a central processing unit 102 (microprocessor, denoted CPU in Figure 1);
-  a read only memory 103 able to contain programs according to the invention;
-  a random access memory 104, which, after powering up, contains the executable code of the method according to the invention as well as registers adapted to record variables and parameters necessary for the implementation of the invention;
-  a screen 105 for displaying the data and/or serving as a graphical interface with the user, who will be able to interact with the programs according to the invention, using a keyboard 106 or any other means such as a pointing device, for example a mouse 107 or an optical stylus (not shown);
-  a hard disk 108 able to contain the programs according to the invention as well as data utilized or produced when the invention is implemented;
-  a disk drive 109 adapted to receive a diskette 12 and to read or write thereon data processed or to be processed according to the invention; and
-  a communication interface 110 connected to a communication network 13, the interface being adapted to transmit and receive data.
In the case of audio data, the apparatus 10 may further comprise an input/output card (not shown) connected to a microphone 14.
The communication bus 101 affords communication and interoperability between the different elements included in the apparatus 10 or connected to it. The representation of the bus is non-limiting and, in particular, the central processing is capable of communicating instructions to any element of the apparatus 10 directly or by the intermediary of another element of the apparatus 10.
The diskettes 12 can be replaced by any information carrier such as a compact disc (CD-ROM) rewritable or not, a ZIP disk or a memory card.
Generally, an information storage means, which can be read by a micro-computer or microprocessor, integrated or not into the device, and which may possibly be removable, is adapted to store one or more programs whose execution permits the implementation of the method according to the invention.
The executable code enabling the apparatus to implement the invention, may equally well be stored in read only memory 103, on the hard disk 108 or on a removable digital medium such as a diskette 12 as described earlier.
According to a variant, the executable code of the programs may be received by the intermediary of the communication network 13, via the interface 110, to be stored in one of the storage means of the apparatus 10 before being run (such as the hard disk 108).
The central processing unit 102 controls and directs the execution of the instructions or portions of software code of the program or programs according to the invention, those instructions being stored in one of the aforementioned storage means.
On powering up, the program or programs which are stored in a non-volatile memory, for example the hard disk 108 or the read-only memory 103, are transferred into the random-access memory 104 (RAM), which then contains the executable code of the program or programs according to the invention, as well as registers for storing the variables and parameters necessary for implementation of the invention.
It should be noted that the apparatus comprising the device according to the invention can also be a programmed apparatus. This apparatus then contains the code of the computer program or programs for example fixed in an application specific integrated circuit (ASIC).
With reference to Figure 2, a communication network 13 connects together several client devices or terminals, individualized as client1 21, client2 22, and client3 23. Each client device may be connected to the network 13 by different communication means such as broadband or narrow band communication means (xDSL modem, PSTN or cable). The network 13 may be constituted equally well on top of the Internet network as on top of a Local Area Network (LAN) or by a combination of both.
The terminals of the client devices fall into two distinct categories. There are either terminals provided with the dedicated "peer-to-peer" P2P application (client2 and client1) or terminals not provided with that dedicated "peer-to-peer" P2P application (client3). 
The terminals provided with the dedicated "peer-to-peer" P2P application form between them a communication network of "peer-to-peer" P2P type through the communication network 13 and according to one of the topologies known to the person skilled in the art (centralized, decentralized with or without central server "superpeers" or else hybrid). 
The "peer-to-peer" P2P application comprises at least one server module bearing the reference 218 in the client device 21 or the reference 228 in the client device 22. The P2P application further comprises a storage means or cache 217, 226.
The server module 218 or 228 is given the task of responding to the requests for access to the "peer-to-peer" resources. The requests may equally well come from remote applications as applications present on the same machine as the server. 
The requests may equally well be received according to a proprietary protocol of the "peer-to-peer" application as according to the HTTP (the HyperText Transfer Protocol) commonly utilized on the Internet.
The storage means 217, 226 contains digital content shared on the "peer-to-peer" network with the aid of the server module 218, 228. The "peer-to-peer" application may also be supplemented by a P2P dedicated local client local application (219, 229) providing a interface with the user enabling him to search, access, view and share digital content on the "peer-to-peer" network.
All the terminals, whether provided or not with the dedicated "peer-to-peer" application, may also utilize tools (227, 237) capable of viewing pages in HTML type markup language to access digital content with the help of the HTTP communication protocol. 
One or more specific proxy/gateway servers 24 may also be connected to the network 13, these servers offering an entry point to the "peer-to-peer" network for clients not having dedicated "peer-to-peer" clients and utilizing the HTTP communication protocol. 
When they receive a request for a resource of the "peer-to-peer" network, the proxy servers 24 determine one or more machines of the "peer-to-peer" network liable to have the requested resource and take on the task either of redirecting the requester to one of those machines, or of retrieving the resource from one of those machines on behalf of the requester to then serve it to the requester as a proxy type server. 
It should be noted that this role of proxy/gateway server may also be fulfilled by the client devices themselves if they have a dedicated "peer-to-peer" application, such as the client devices 1 and 2 respectively numbered 21 and 22.
According to the invention, if the user connected to machine 21 wishes to share a new collection of digital content composed of images individualized as image1, image2 and image3 present on its disk 217 with clients 22 and 23, he utilizes the P2P local application 219 to create and share a new collection composed of those three images. 
During sharing, the P2P local application 219 associates a unique identifier Image1 ID, Image2 ID, Image3 ID with each image. Tools well known to the person skilled in the art make it possible to generate identifiers with an infinitesimal probability of duplication.
After the actual sharing operation that is specific to the "peer-to-peer" application, the P2P local application 219 generates a page 25 in HTML markup language describing the new collection in order to notify clients 22 and 23 that a new collection of digital content is available on the network. This HTML page contains at least some scripts 252 such as javaScripts and a reference for each of the identifiers of newly shared digital content 253.
Once the HTML page 25 has been generated, the user may send that page to all the persons which he wishes to notify of the existence of new shared digital content (on our example client2 and client3). 
In the preferred embodiment, the user sends the HTML page 25 by making it an attachment to an email.
In another embodiment, the user downloads the HTML page 25 onto a server such as server 24. Furthermore, the user sends a reference designating that HTML page on said server to all the persons he wishes to notify, for example in the form of a URL included in an email. The recipients download the HTML page 25 from the server 24 using the reference (the said URL) received as notification.
The user may equally well use any other means making it possible to transmit the HTML page to recipients (for example using a "peer-to-peer" file exchange system, by physically mailing a diskette containing the HTML, etc.).
When the HTML page 25 is received and displayed by the recipients using applications 227 and 237, that is to say an Internet navigator, an email reader or any other application capable of interpreting and displaying an HTML page, the content of the page is interpreted and the executable codes (scripts) contained in the page are executed. 
A first code is given the task of determining whether the dedicated "peer-to-peer" P2P local application is installed. 
If the dedicated application is installed, the first code retrieves, using a second code external to the HTML page (e.g. activeX), configuration information on the "peer-to-peer" application such as the numbers associated with network ports utilized by the application. Next, the first code initializes variables which are utilized by a third code embedded in the HTML page 25 and given the task of generating the URL addresses to utilize for accessing the digital contents. 
The third code is invoked on interpretation of the HTML page for each of the references to the shared digital contents. If the "peer-to-peer" local server 228 has been detected by the first code as being installed and active, the third code returns HTML code of which the URLs are directed to the "peer-to-peer" local server (case C1 for client 2 in Figure 2). The URLs may be of the form http://localhost:80/RUID where RUID represents the unique identifier of the shared resource. 
If the "peer-to-peer" local server 228 is not present on machine 22 or is not active, the third code sends back HTML code of which the URLs are directed to a predefined remote server providing a gateway between http web requests and the "peer-to-peer" network such as the "peer-to-peer" proxy/gateway web/ server 24 (case of client 3 and case C2 for client 2 in Figure 2). 
The URLs sent back may be of the form http://www.server.com/RUID where www.server.com represents the web address of server 24 and RUID represents the unique identifier of the shared resource.
The invention thus make it possible to adapt the content of the notification (HTML page 25) depending on whether the recipient has the "peer-to-peer" application or not.
In our example, device client3 23 does not have the "peer-to-peer" application. In its case, all the accesses to the shared digital contents are thus directed to the proxy server 24.
On the other hand, for device client2 22 the accesses to digital contents are directed to its "peer-to-peer" server 228 if it is active (case C1) and to the proxy server 24 if it is inactive (case C2).
The advantages of utilizing the "peer-to-peer" server as soon as it is available are in particular the fact of not accessing the network if the data are already present in the cache of the "peer-to-peer" server. In addition, if the digital contents are accessed through the "peer-to-peer" local server, said contents are then present in the cache of the server and thus may be served to remote machines in return. The number of machines in the "peer-to-peer" network able to serve a given digital content is thereby increased. As the machines may be disconnected at any moment, the probability of finding a given digital content on the network at any instant is thereby increased.
With reference to Figure 3, a flowchart has been represented illustrating the behavior of the script given the task of determining whether a "peer-to-peer" local server is present and active on the machine.
This script is integrated into the HTML page 25, either in the form of a script 252 bounded by HTML tags ＜SCRIPT LANGUAGE=###＞ and ＜/SCRIPT＞ where ### indicates the language utilized, or in the form of a reference to an external file.
The script is interpreted and executed at each display of the HTML page.
At step S302, the script commences by verifying whether the "peer-to-peer" application is installed or not on the machine. For this, it seeks to detect the presence of an activeX program or of an extension module (plug-in) forming part of the "peer-to-peer" application. 
For example, if the program to detect is an activeX, it may invoke the function defined by the following VBscript program:
＜SCRIPT LANGUAGE="VBscript"＞
＜!--
Function detectActiveXControl(activeXControlName)
on error resume next
detectActiveXControl = False
detectActiveXControl = IsObject(CreateObject(activeXControlName))
End Function
rem --＞
＜/SCRIPT＞
This function detectActiveXControl takes as parameter the name of the activeX and gives True if the activeX is present on the machine and False otherwise.
At step S303, if the application has been detected as not present on the machine, the algorithm goes to step S308 and sets a variable indicating that in the following processing of the HTML page use must be made of the URLs directed to the remote server 24.
If, on the contrary, the P2P application has been detected, the script determines at step S304 whether the "peer-to-peer" local server 228 is currently active (that is to say in course of execution) or not. For this, it utilizes the activeX program detected at the preceding step to retrieve the current configuration of the "peer-to-peer" server 228 by consulting either the registers or a configuration file.
For example, the activeX program retrieves the number of the network port on which the server 228 is listening. If the latter is inactive, the port has the value zero. If the value is different from zero, at step S309, it sets a variable containing the port number on which the server 228 is listening. 
At step S310, the script sets a variable indicating that in the following processing of the HTML page 25 use must be made of the URL addresses directed to the local server 228 to access the digital contents.
For example if GetRegValue is a function of the activeX MpActiveXVB enabling the register to be accessed, the following program may be utilized to determine whether the local server is active or not and retrieve its port number (step S304 and S309).
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
var IsLocalServerActive = false;
var LocalServerPort = 80;
function CheckLocalServer()
{
LocalServerPort = MpActiveXVB.GetRegValue("SOFTWARE\\LocalServer\\Config\\ListenPort}");
if(LocalServerPort != 0)
{
return true;
}
return false;
}
IsLocalServerActive = CheckLocalServer();
// --＞
＜/SCRIPT＞
If server 228 is detected as inactive at step S304, the program may invite the user to launch the "peer-to-peer" local server 228 by opening a dialog box using a function of the activeX. 
If the user accepts the proposal, a function of the activeX is invoked to launch the local server at step S307.
At step S311 continuation of the interpretation of the HTML page 25 is proceeded with.
With reference to Figure 4, each time the HTML page 25 is analyzed by an application such as an Internet navigator or an email reader (227, 237), a JavaScript function embedded in the page is invoked for each reference to a digital content in order to give the URL address to use to access said digital content.
The invocation of that function in the HTML page may take the following form: 
＜SCRIPT LANGUAGE="JavaScript"＞ GetRessourceAddress('abcde23404-3143492ef-23232', 'blue_mountain.jpg');
＜/SCRIPT＞
The tag ＜SCRIPT LANGUAGE= ###＞ marks the beginning of a code to execute in the HTML page, where the value ### mentions the nature of the language utilized (JavaScript or VBScript for example). The tag ＜/SCRIPT＞ indicates the end of the code to execute. 
GetRessourceAddress here corresponds to the name of the JavaScript function to invoke. This function must be defined beforehand, either in an external file the name of which terminates with the extension " .js" itself referenced in the HTML page, or directly at the beginning of the HTML page (that is to say in the header bounded by the tags ＜HEAD＞ and ＜/HEAD＞ in a section of JavaScript code bounded by the tags ＜SCRIPT LANGUAGE="JavaScript"＞ and ＜/SCRIPT＞).
In the first case, if the name of the server hosting the script is "www.server.com" and the file containing the definition of the function is called "mp.js" and is found in the "script" folder on the server, the command including the "mp.js" file in the HTML page is:
＜SCRIPT LANGUAGE="JavaScript" 
src="http://www.server.com/script/mp.js"＞＜/SCRIPT＞
Figure 4 describes the behavior of the JavaScript function  GetRessourceAddress given the task of giving the URL address.
The corresponding code in JavaScript may be the following:
function GetRessourceAddress(resID, title)
{
if(isLocalServerActif == false)
{
document.write("＜A HREF=http://www.server.com/");
document.write(resID);
}
else
{
document.write("＜A HREF=http://localhost:");
document.write(localServerHTTPPort);
document.write("/");
document.write(resID);
}
document.write("＞");
document.write(title);
document.write("＜/A＞");
}
The keyword function indicates the creation of a new function the name of which is GetRessourceAddress here and which has two variables as parameters, resID and title. JavaScript has a command named document.write(#) making it possible to display information by passing that information denoted here by hash to the program in course of interpreting the HTML page. The information passed must thus be in HTML format to be comprehensible by the interpreter.
The words isLocalServerActif and localServerHTTPPort represent JavaScript variables initialized beforehand (Figure 3) . The first variable indicates a "peer-to-peer" local server is currently installed and active on the machine and the second variable indicates the port number on which the "peer-to-peer" local server awaits.
According to the invention the algorithm is thus the following:
The JavaScript function here denoted GetRessourceAddress having as parameters at least the unique identifier of the resource denoted resID is invoked (step S401) for each of the references to the resources in the HTML page 25.
At step S402, the function verifies whether a "peer-to-peer" local server has been detected by the algorithm of Figure 3 by verifying the value of a variable denoted here by isLocalServerActif.
At step S403, if the variable indicates that there is no "peer-to-peer" local server currently active (the value of the variable is false), then at step S404 the function gives a URL enabling the resource to be accessed via a predefined address corresponding to a server 24 of proxy/gateway type of which the name would for example be www.server.com.
On the basis of the code of the JavaScript function and the example of invocation described earlier, the HTML code given by the function is the following:
＜A HREF=http://www.server.com/abcde23404-3143492ef-23232＞ 'blue_mountain.jpg'＜/A＞
This code represents a hypertext link having the name blue_mountain.jpg and linking to the address http://www.server.com/abcde23404-3143492ef-23232.
At step S403, if the variable indicates that there is a "peer-to-peer" local server active on the machine (the value of the variable is true), then at step S405 the function gives a URL enabling the resource to be accessed via the local server which here has the role of proxy (Figure 5). The HTML code given by the function would then be:
＜A HREF=http://localhost:90/abcde23404-3143492ef-23232＞'blue_mountain.jpg'＜/A＞
assuming the variable localServerHTTPPort has the value 90.
In another variant, rather than invoking the JavaScript function GetRessourceAddress for each of the references to a digital content, these references may be written in the form of a relative URL. An example of HTML code for a reference may then have the following form:
＜A HREF=abcde23404-3143492ef-23232＞ 'blue_mountain.jpg'＜/A＞
Repeated invocation of the JavaScript function GetRessourceAddress for each of the references to a digital content is then advantageously replaced by a single invocation to a JavaScript routine given the task of defining a tag ＜BASE＞ in the header of the HTML page 25. This tag defines an absolute URL utilized as basic URL to resolve the relative URLs. 
The JavaScript function gives a tag ＜BASE＞ linking to a server 24 of proxy/gateway type if there is no "peer-to-peer" local server active on the machine (the variable isLocalServerActif has the value false). The HTML code given by the function is then:
＜BASE HREF=http://www.server.com/＞
The JavaScript function gives a tag ＜BASE＞ linking to a local server 228 if there is an active "peer-to-peer" local server on the machine (the variable isLocalServerActif has the value true). The HTML code given by the function is then:
＜BASE HREF=http://localhost:90/＞
assuming the variable localServerHTTPPort has the value 90.
With reference to Figure 5, the behavior of the local servers 228 and 218 has been described.
According to the invention when the "peer-to-peer" local server receives a request for a digital content R (S511) it determines at step S512 whether the request comes from a remote application (present on another machine of the communication network) or whether the request comes from a local application (running on the same machine as the server). It determines this information by examining the IP address of the requester and by comparing it to each of its own IP addresses. If two addresses are identical or if the address of the requester is 127.0.0.1 (loopback address), this means that the requester is local, otherwise it is a remote requester.
If the requester is local, the server goes to step S513 and verifies whether the data R sought is not locally present on the disk. If the data is present locally, it is sent to the requester (step S517). If the data is not present locally the server performs a search for the resource on the "peer-to-peer" network using techniques known to the person skilled in the art (step S514). At step S515, if the data is found on the network then the server downloads the data R at step S516, saves it locally in its cache on the disk and sends it back to the requester at step S517. In the opposite case, the server sends back an error to the requester at step S518 to indicate to him that the data is not available.
If the requester is remote, at step S519 the server verifies whether the resource is available locally on its disk.
If the data is available, it is sent back to the requester at step S520. In the opposite case, at step S521 it varifies whether the request is a WEB request coming for example from an Internet navigator (in the form of a URL http://y/x where [x] is the access path to the resource on the machine identified by [y], or else in the form of a particular header in the request) or whether it is a request according to a proprietary "peer-to-peer" protocol.
If it is a WEB request, the server then carries out a search for the data on the "peer-to-peer" network at step S522. The proxy/gateway behavior of machine 24 is again found here.
At step S523, if the resource is localized in the "peer-to-peer" network, the server does not download the resource but on the contrary at step S524 re-directs the requester to the machine having the resource sought using a forwarding order of which a simple form with the HTTP protocol would be:
HTTP/1.1 302 See other URI
Location: http://nnn/zzz
The first key word http/1.1 makes it possible to indicate the type and version of the protocol. 302 is a particular error value indicating that the resource is temporarily not available on the server. A comment which may be displayed follows that error code. Location: is the second key word indicating to the Internet navigator to redirect itself to another URI. [nnn] is the address of the machine to contact to obtain the resource and [zzz] is the access path to the resource on the machine [nnn]. 
At step S523, if the resource is not located on the "peer-to-peer" network, at step S525 the server redirects the requester to a predetermined machine using a forwarding order similar to the preceding one. That predetermined machine is given the task of dealing with the case in which the requested resource is not available by sending back for example a predetermined response inviting the user to renew its request later for example.
If at step S521 it is not a WEB request coming from an Internet navigator but a request coming from a dedicated "peer-to-peer" application the server sends back an error to the requester.
For example the HTML page may have the following content:
＜HTML＞
＜HEAD＞
＜SCRIPT LANGUAGE="VBscript"＞
＜!--
detectableWithVB = False
If ScriptEngineMajorVersion ＞= 2 then
detectableWithVB = True
End If
Function detectActiveXControl(activeXControlName)
on error resume next
detectActiveXControl = False
If detectableWithVB Then
detectActiveXControl = IsObject(CreateObject(activeXControlName))
End If
End Function
rem --＞
＜/SCRIPT＞
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
var pluginFound = false;
pluginFound = detectActiveXControl('MpActiveXVB.MpRegistry');
alert('MpActiveXVB found = ' + pluginFound);
if (pluginFound)
{
// Insert reference to activeX in HTML page
document.write("＜OBJECT ID=");
document.write('\"MpActiveXVB\"');
document.write("CLASSID=");
document.write('\"CLSID:443E61FC-4AC1-49EC-A89A-F99EA5EE72A2\"＞');
document.writeln("＜/OBJECT＞");
}
// --＞
＜/SCRIPT＞
＜/HEAD＞
＜BODY＞
＜SCRIPT LANGUAGE="JavaScript"＞
＜!--
var isLocalServerActif = false;
var localServerHTTPPort = 80;
function CheckServer()
{
if (pluginFound)
{
isLocalServerActif = MpActiveXVB.GetRegValue("SOFTWARE\\Classes\\CLSID\\{443E61FC-4AC1-49EC-A89A-F99EA5EE72A2}");
if(isLocalServerActif == false)
{
alert('Server Not Found');
}
else
{
localServerHTTPPort = MpActiveXVB.GetRegValue("SOFTWARE\\localserver\\config\\port");
alert('Server Port Value: ' + localServerHTTPPort);
}
}
}
function GetRessourceAddress (imageID, title)
{
document.writeln("");
document.writeln("Process the image ID...");
if(isLocalServerActif == false)
{
document.write("＜A HREF=http://www.server.com/");
}
else
{
document.write("＜A HREF=http://localhost:");
document.write(localServerHTTPPort);
document.write("/");
}
document.write(imageID);
document.write("＞＜IMG SRC=") ;
document.write(title);
document.write("BORDER=0 ALT=");
document.write(title);
document.writeln("＞＜/A＞");
}
CheckServer ();
// --＞
＜/SCRIPT＞
＜NOSCRIPT＞
＜H1＞No JavaScript＜/H1＞
You see this text if JavaScript is disabled or unimplemented.
＜/NOSCRIPT＞
＜SCRIPT LANGUAGE="JavaScript"＞ 
GetRessourceAddress ('abcde23404-3143492ef-23232', 'blue_mountain.jpg');
GetRessourceAddress ('fffffeeeaa-bbe478999-aaaaa', 'red_mountain.jpg');
＜/SCRIPT＞
＜/BODY＞
＜/HTML＞
Among the numerous advantages conferred by the present invention, it is possible to highlight that it is not necessary to adapt the content of the notification according to the capabilities of the recipients, that is to say according to whether they possess the dedicated P2P local application or not. Furthermore, the local or remote access is totally transparent for the user. Similarly, it is not necessary to modify the Internet configuration of the user (in this case the addresses of the proxy server or proxy. Finally, the client devices possessing the P2P application are not obliged to keep their local server active to be able to display the content of a notification received by email, the display of the notification adapting itself automatically depending on the presence/absence of a local server.
1.  A method of accessing at least one digital document available on a communication network linking client devices together, said accessing method being implemented on a recipient client device said method comprising the following steps.
i)   receiving a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document,
ii)  executing the command or commands in order to detect the local application, and
iii) in case of positive detection, accessing the digital document from a local server whereas in case of negative detection, accessing the document from the address of a remote server.
2.  A method according to claim 1, wherein the notification further comprises at least one page in markup language containing at least one identifier designating the digital document, and a remote address designating a remote server.
3.  A method according to claim 1, further comprising, at the issue of step ii) and prior to step iii), the step iib) in which, in case a local application is present and inactive, provision is made to proceed with the activation of the local application according to a chosen executable command.
4.  A method according to claim 1, further comprising, after step iii), the step iv) in which provision is made to verify the presence of the document on a local server, and in case of negative verification to search for said document on the network, to download it in case of positive search, and to save it locally before serving it.
5.  A method according to claim 2, wherein the adaptation of the page comprises the setting of a linking variable in markup language to the address of a local server, and provision is made to locally adapt the page in markup language so as to access the document from the address of a local server.
6.  A method according to claim 2, wherein the adaptation of the page comprises the setting of a linking variable in markup language to the address of a remote server, and provision is made to locally adapt the page in markup language so as to access the document from the address of a remote server.
7.  A method according to claim 2, wherein the executable command or commands are embedded in the page so notified, and said page being interpreted at step ii).
8.  A method according to claim 2, wherein the local address designating a local server may be determined by the command or commands adapted to retrieve the configuration parameters of said local server.
9.  A method according to claim 2, wherein the command or commands included in the page in markup language call on a local program, adapted to detect the local server, as well as to retrieve the configuration parameters of said local server.
10.  A method according to claim 2, wherein the page is notified as an attachment with an email.
11.  A method according to claim 2, wherein the page is downloaded onto a chosen remote server, and in that a reference to that page is sent to any recipient to be notified,
12.  A method of sharing a digital document available on a communication network linking client devices together, said method being implemented on a sending client device, said method comprising the following step:
-  sending to at least one recipient client device a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document, and in case in case of positive detection, to access the document from the address of a local server otherwise to access the document from the address of a remote server.
13.  A sharing method according to claim 12, wherein the notification further comprises a page in markup language containing at least one identifier designating the digital document, and a remote address designating a remote server.
14.  A device for accessing at least one digital document available on a communication network linking client devices together, said accessing device being integrated into a recipient client device, said accessing device comprises:
-  receiving means adapted to receive a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document,
-  executing means adapted to execute the command in order to detect the local application, and
-  processing means adapted, in case of positive detection, to access the digital document from a local server whereas in case of negative detection, to access the document from a remote server.
15.  A device according to claim 14, wherein the notification further comprises at least one page in markup language containing at least one identifier designating the digital document, and a remote address designating a remote server.
16.  A device according to claim 15, wherein the processing means are adapted to set a linking variable in markup language to the address of the local server, and the processing means are adapted to locally adapt the page in markup language so as to access the document from the address of the local server.
17.  A device according to claim 15, wherein the processing means are adapted to set a linking variable in markup language to the address of the remote server, and the processing means are adapted to locally adapt the page in markup language so as to access the document from the address of the remote server.
18.  A device according to claim 15, wherein the executable command or commands are embedded in the page so notified and said page being interpreted.
19.  A device according to claim 15, wherein the page is notified as an attachment with an email, the device being further equipped with an email processing application.
20.  A digital document sharing device in a communication network linking client devices together, said sharing device being integrated into a sending client device, the digital document sharing device comprises sending means adapted to send to at least one recipient client device a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document, and in case of positive detection, of accessing the document from the address of a local server and otherwise of accessing the document from the address of a remote server.
21.  A sharing device according to claim 20, wherein the notification further comprises a page in markup language containing at least one identifier designating the digital document and a remote address designating a remote server.
22.  An information carrier readable by a computer system, possibly wholly or partly removable, in particular a CD-ROM or magnetic medium, such as a hard disk or a diskette, or a transmissible medium, such as an electrical or optical signal, characterized in that it comprises instructions of a computer program enabling the implementation of the method according to claim 1, when that program is loaded into and run by a computer system.
23.  A computer program stored on an information carrier, said program comprising instructions enabling the implementation of a processing method according to claim 1, when that program is loaded and run by a computer system.
1.  ABSTRACT
The access method comprises the following steps:
i)   receiving a notification indicating the presence of at least one digital document available on the network, said notification comprising at least one executable command adapted to detect whether the recipient client device comprises a local application capable of processing the digital document,
ii)  executing the command or commands in order to detect the local application, and
iii) in case of positive detection, accessing the digital document from a local server whereas in case of negative detection, accessing the document from the address of a remote server.
2.  Selected Drawing
Figure 2
【図１】
2005122693.tif 000008
【図２】
2005122693.tif 000009
【図３】
2005122693.tif 000010
【図４】
2005122693.tif 000011
【図５】
2005122693.tif 000012