(57)【要約】  ウェブブラウザにおいてドメイン間通信を実施するコンピュータ実装される方法は、第１のドメインから、第１のドメイン以外の１つまたは複数のドメインに対応付けられたルータにおいて第１のデータを受信すること、受信したデータに対応付けられたデータを受信する１つまたは複数のドメインを、ルータにおいて識別すること、および受信したデータに対応付けられた第２のデータを１つまたは複数のドメインに送信することを含む。
2010530570.tif 000002
【特許請求の範囲】
【請求項１】
第１のドメインから、前記第１のドメイン以外の１つまたは複数のドメインに対応付けられたルータにおいて第１のデータを受信するステップと、
前記受信したデータに対応付けられたデータを受信する前記１つまたは複数のドメインを、前記ルータにおいて識別するステップと、
前記受信したデータに対応付けられた第２のデータを前記１つまたは複数のドメインに送信するステップと、
を含む、ウェブブラウザにおいてドメイン間通信を実行するコンピュータ実装される方法。
【請求項２】
前記第２のデータが前記第１のデータを含む、請求項１に記載のコンピュータ実装される方法。
【請求項３】
前記第２のデータが、前記ルータから前記１つまたは複数のドメインに送信される、請求項１に記載のコンピュータ実装される方法。
【請求項４】
前記第１のドメインおよび前記第１のドメイン以外の前記１つまたは複数のドメインがそれぞれ、フレームによって定義される、請求項１に記載のコンピュータ実装される方法。
【請求項５】
前記ルータがフレームによって定義される、請求項４に記載のコンピュータ実装される方法。
【請求項６】
前記フレームがiframe要素を含む、請求項５に記載のコンピュータ実装される方法。
【請求項７】
前記１つまたは複数のドメインがそれぞれ、移植可能プログラムモジュールを実装する、請求項１に記載のコンピュータ実装される方法。
【請求項８】
前記移植可能プログラムモジュールがガジェットを含む、請求項７に記載のコンピュータ実装される方法。
【請求項９】
前記ルータにおいて、前記１つまたは複数のドメインの１つから第３のデータを受信するステップと、前記第３のデータを前記第１のドメインに提供するステップとをさらに含む、請求項１に記載のコンピュータ実装される方法。
【請求項１０】
前記第３のデータを、前記１つまたは複数のドメインの少なくとも一部に提供するステップをさらに含む、請求項９に記載のコンピュータ実装される方法。
【請求項１１】
前記第１のドメインに対応付けられたルータから、前記第１のドメイン以外の前記１つまたは複数のドメインに対応付けられた前記ルータに前記第１のデータを送信するステップをさらに含む、請求項１に記載のコンピュータ実装される方法。
【請求項１２】
前記第１のドメインに対応付けられた前記ルータにおいて多数のデータグループを受信するステップと、前記１つまたは複数のドメインに対応付けられた前記ルータに前記多数のデータグループを送信する前に、前記多数のデータグループを単一パケットに合成するステップとをさらに含む、請求項１１に記載のコンピュータ実装される方法。
【請求項１３】
前記パケットを送信する前に前記多数のデータグループを順序づけるステップをさらに含む、請求項１２に記載のコンピュータ実装される方法。
【請求項１４】
ウェブページ上に表示され、ウェブアプリケーションに対応付けられた第１のドメイン内で動作する第１のアプリケーションと、
前記ウェブページ上に表示され、前記ウェブアプリケーションに対応付けられた他の１つまたは複数のドメイン内で動作する他の１つまたは複数のアプリケーションと、
前記第１のアプリケーションからデータを受信し、前記受信したデータを、前記他の１つまたは複数のアプリケーションによる受信のために分配するように動作可能な、前記第１のアプリケーションに対応する第１のリレーと、
を備えるコンピュータ実装されるシステム。
【請求項１５】
前記第１のリレーからデータを受信し、前記１つまたは複数のアプリケーションに前記データを分配するための、前記他の１つまたは複数のアプリケーションに対応する第２のリレーをさらに備える、請求項１４に記載のコンピュータ実装されるシステム。
【請求項１６】
前記第１のリレーが、前記第２のリレーからデータを受信し、前記受信したデータを前記第１のアプリケーションに提供するように構成される、請求項１５に記載のコンピュータ実装されるシステム。
【請求項１７】
前記第１のアプリケーションおよび前記他の１つまたは複数のアプリケーションが、共通ウェブページ上に表示されるように構成される、請求項１４に記載のコンピュータ実装されるシステム。
【請求項１８】
前記第１のリレーが、多数のデータグループを単一パッケージにパッケージ化してから、前記第２のリレーに前記単一パッケージを送信する、請求項１４に記載のコンピュータ実装されるシステム。
【請求項１９】
複数のフレームをさらに備え、前記複数のフレームのうち１つのフレームが前記第１のアプリケーションの表示を定義し、前記複数のフレームのうちその他のフレームが、前記他の１つまたは複数のアプリケーションの表示を定義する、請求項１４に記載のコンピュータ実装されるシステム。
【請求項２０】
前記第１のアプリケーションが地図アプリケーションを含み、前記他の１つまたは複数のアプリケーションがガジェットを含む、請求項１４に記載のコンピュータ実装されるシステム。
【請求項２１】
ウェブページ上に表示され、ウェブアプリケーションに対応付けられた第１のドメイン内で動作する第１のアプリケーション、
前記ウェブページ上に表示され、前記ウェブアプリケーションに対応付けられた他の１つまたは複数のドメイン内で動作する他の１つまたは複数のアプリケーション、ならびに
前記第１のアプリケーションと前記他の１つまたは複数のアプリケーションとの間でデータ通信する手段を備えるコンピュータ実装されるシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、異なるドメインに対応付けられたiframeなど、ウェブページにおいて通信を行う機構および技術について説明する。
【背景技術】
【０００２】
インターネットユーザによって行われる多くの検索には、いくつかの地理的な構成要素が関わる。検索自体が、地図および車での行き方が探索される対象である住所などの地理情報を含み得る。検索は、物理的な場所を有する店舗の名称を検索が含むときなどに、地理的結果を暗黙に要求する場合がある。Googleマップなどの情報プロバイダサービスによって、このような検索を受信し、かつ／またはその結果を配布することができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
アプリケーションプログラミングインタフェース(API)により、サードパーティは、地理情報プロバイダサービスの機能を拡張することができるようになる。例えば、あるAPIを使って、プログラマは、アパートおよび家屋一覧にあるデータを受け取っており、そうした一覧を表示するアプリケーションを、Googleマップ(例えば、http://www.housingmaps.com/)などで地図上に作成してきた。
【課題を解決するための手段】
【０００４】
本願は、Googleマップなどのサービスからの対話型地図の準備など、異なるドメインにある構成要素を伴い得るウェブアプリケーションとの対話を可能にするために利用することができる機構および技術について記載する。例えば、ガジェット(gadget)の形の移植可能プログラムモジュールは、メインのウェブアプリケーションページと統合することができ、メインのページと通信することができ、この場合ガジェットは、あるドメインから運営され、メインのアプリケーションは、異なるドメインから運営される。通信は、ウェブブラウザがドメイン間通信を制限しようと努力している場合であっても起こり得る。
【０００５】
一実装形態では、ウェブブラウザにおいてドメイン間通信を実現するコンピュータ実現方法が開示される。この方法は、第１のドメインから、第１のドメイン以外の１つまたは複数のドメインに対応付けられたルータにおいて第１のデータを受信すること、受信したデータに対応付けられたデータを受信する１つまたは複数のドメインを、ルータにおいて識別すること、および受信したデータに対応付けられた第２のデータを１つまたは複数のドメインに送信することを含む。第２のデータは、第１のデータを含んでよく、第２のデータは、ルータから１つまたは複数のドメインに送信することができる。さらに、第１のドメインおよび第１のドメイン以外の１つまたは複数のドメインはそれぞれ、フレームによって定義することができ、ルータは、フレームによって定義することができる。フレームは、iframe要素を含み得る。
【０００６】
一態様では、１つまたは複数のドメインはそれぞれ、ガジェットなどの移植可能プログラムモジュールを実装することができる。この方法は、ルータにおいて、１つまたは複数のドメインの１つから第３のデータを受信すること、および第３のデータを第１のドメインに提供することも含み得る。さらに、この方法は、第３のデータを、１つまたは複数のドメインの少なくとも一部に提供することを含み得る。この方法は、第１のドメインに対応付けられたルータから、第１のドメイン以外の１つまたは複数のドメインに対応付けられたルータに第１のデータを送信することも含み得る。さらに、この方法は、第１のドメインに対応付けられたルータにおいて多数のデータグループを受信すること、１つまたは複数のドメインに対応付けられたルータに多数のデータグループを送信する前に、多数のデータグループを単一パケットに合成することを含み得る。この方法は、パケットを送信する前に多数のデータグループを順序づけることも含み得る。
【０００７】
別の実装形態では、コンピュータ実施システムが開示される。このシステムは、ウェブページ上に表示され、ウェブアプリケーションに対応付けられた第１のドメイン内で動作する第１のアプリケーションと、ウェブページ上に表示され、ウェブアプリケーションに対応付けられた他の１つまたは複数のドメイン内で動作する他の１つまたは複数のアプリケーションと、第１のアプリケーションからデータを受信し、受信したデータを、他の１つまたは複数のアプリケーションによる受信のために分配するように動作可能な、第１のアプリケーションに対応する第１のリレーとを備える。このシステムは、第１のリレーからデータを受信し、１つまたは複数のアプリケーションにデータを分配するための、他の１つまたは複数のアプリケーションに対応する第２のリレーも含み得る。第１のリレーは、第２のリレーからデータを受信し、受信したデータを第１のアプリケーションに提供するように構成することができる。
【０００８】
一態様では、第１のアプリケーションおよび他の１つまたは複数のアプリケーションは、共通ウェブページ上に表示されるように構成される。また、第１のリレーは、多数のデータグループを単一パッケージにパッケージ化してから、第２のリレーに単一パッケージを送信することができる。このシステムは、複数のフレームも含んでよく、複数のフレームのうち１つのフレームが第１のアプリケーションの表示を定義し、複数のフレームのうちその他のフレームが、他の１つまたは複数のアプリケーションの表示を定義する。第１のアプリケーションは地図アプリケーションを含んでよく、他の１つまたは複数のアプリケーションはガジェットを含んでよい。
【０００９】
さらに別の実装形態では、コンピュータ実施システムが開示される。このシステムは、ウェブページ上に表示され、ウェブアプリケーションに対応付けられた第１のドメイン内で動作する第１のアプリケーション、ウェブページ上に表示され、ウェブアプリケーションに対応付けられた他の１つまたは複数のドメイン内で動作する他の１つまたは複数のアプリケーション、ならびに第１のアプリケーションと他の１つまたは複数のアプリケーションとの間でデータ通信する手段を含む。
【００１０】
１つまたは複数の実施形態の詳細については、添付の図面および以下の説明において記載する。他の特徴、目的、および利点が、こうした説明および図面から、ならびに請求項から明らかになるであろう。
【図面の簡単な説明】
【００１１】
【図１Ａ】２つの移植可能プログラムモジュールと対話する地図表示アプリケーションの表示例を示す図である。
【図１Ｂ】図1Aの表示にある項目を示す図である。
【図２】地図表示アプリケーションを２つの移植可能プログラムモジュールと連携させるシステムおよび処理を示す概念図である。
【図３】移植可能プログラムモジュールを地図表示システムと統合するシステム例を示す概略図である。
【図４Ａ】マッピングを基にした移植可能プログラムモジュールを動作させる処理を示すフローチャートである。
【図４Ｂ】マッピングを基にした移植可能プログラムモジュールを動作させる処理を示すフローチャートである。
【図５Ａ】移植可能プログラムモジュールおよび地図表示アプリケーションの動作を連携させる処理を示すスイムレーン図である。
【図５Ｂ】移植可能プログラムモジュールおよび地図表示アプリケーションの動作を連携させる処理を示すスイムレーン図である。
【図６】ウェブブラウザによって表示されるドメインの間の通信を連携させる処理を示すフローチャートである。
【図７】ブラウザが表示したウェブページ上のドメインの間でデータを送る処理を示すスイムレーン図である。
【図８】２つの移植可能プログラムモジュールと連携して動作する地図アプリケーションの例を示すスクリーンショットである。
【図９】いくつかの移植可能プログラムモジュールおよび地図表示アプリケーションを含むコンテナドキュメントのレイアウト例を示す図である。
【図１０】地図、広告、および他の項目を動的に生成するシステム例を示す概略図である。
【図１１】本明細書に記載する技術を実装するのに使うことができるコンピュータ装置およびモバイルコンピュータ装置の例を示す図である。
【発明を実施するための形態】
【００１２】
様々な図面中の同じ参照符号は、同じ要素を示す。
【００１３】
図１Ａは、２つの移植可能プログラムモジュールと対話する地図表示アプリケーションの表示例100である。概して、表示100は、様々なスキー場に関する予想最高気温および積雪(snow base)を組み合わせて示す。この例では、地図表示アプリケーションと対話するのでここでは「マプレット(mapplet)」と呼ばれる、予報図を示すための公開気象データにアクセスするガジェットを、あるサードパーティが開発している。別のサードパーティは、他の公開の情報源にある積雪情報にアクセスするマプレットを開発している。この例では、このような統合表示がない状態で、ユーザは、例えば、十分な積雪のある多数のロッジを識別し、次いでこうしたロッジを記憶し、こうしたロッジの気温を検索するために、２つのアプリケーションを別々に操作することを要求されている場合がある。この例では、対照的に、Googleマップなどの地図表示アプリケーションにアクセスするマッシュアップ(mash up(組み合わせ))によって提供されうる各情報は、組み合わされて提供される。さらに、組合せ情報は、地図ページ自体の上に表示され、従ってそのページによって管理される。
【００１４】
いくつかの実装形態では、このような手法は、以下の利点の１つまたは複数を有し得る。様々なモジュールは、地図表示アプリケーションに対応付けることができ、地図表示アプリケーションに対応付けられたウェブページを訪問するユーザによってアクセスすることができる。このようなユーザは、Google個人用ホームページ、すなわちiGoogleのユーザが、個人用ページ上で使用するための一般モジュールを識別することができるように、モジュールを検索し、ユーザが特に欲求していることに対処するモジュールを選択することができる。地図表示モジュールは、地図に関連しない他のモジュールとともに、個人用ホームページに埋め込むこともできる。さらに、このような地図表示モジュールは、検索クエリに対する結果として自動的に提供することができ、その場合、検索結果中に示されるコントロールを選択することにより、検索結果に適したデータを含む地図が表示される。
【００１５】
さらに、このようなモジュールは、トランザクション処理能力を含み得る。例えば、ホテル検索は、地図上に適切なホテル検索結果を表示するモジュールに向けられた検索結果を生じ得る。ある特定のホテルを地図上で選択することにより、ホテルについての情報(例えば、部屋代および空き状況)をモジュールに渡すことができ、その結果ユーザはモジュールを介して部屋を予約することができる。
【００１６】
多数のモジュールの出力を、ユーザによって選択された様々なやり方で１つの地図上に合成することもできる。このようにして、ユーザは、自分にとって重要な多数のデータセットを単一グラフィック表現に合成することができる。このような合成では、店舗検索、行き方、個人アドレス帳、KML(キーホールマークアップ言語)ファイル、乗換え情報など、地理関連コンテンツの様々なソース、および他のこのような情報ソースを利用することができる。このような合成は、マッシュアップのマッシュアップと呼ぶことができる。
【００１７】
図１Ａを参照すると、表示100は、地図表示アプリケーションの地図112の表示に影響するガジェットまたはマプレットとして実装される２つの移植可能プログラムモジュール106、108の形をした、マッシュアップのマッシュアップを示す。表示100は、概して、地理関連の検索クエリをユーザが入力することができる検索コントロール102によって制御することができる。「地図を検索」タブ102aは、コントロール102に関して選択されたものとして示してあり、その結果、検索クエリが、全体の地理的場所情報のコーパス(corpus)に加えられることになる。「お店を探す」タブ102bを選択してもよく、このケースでは、送信されたクエリは、店舗名のコーパスと突き合わされることになり、結果は、地図112上の店舗と合致する特定の場所を含むことになる。「行き方を調べる」タブ102cは、選択されると、よく知られたやり方で、ある場所から別の場所までの、例えばユーザプロファイルに格納されたデフォルトの場所から入力した場所までの行き方を生成する。
【００１８】
地図表示コントロールエリアは、タブエリア104、「最高気温」マプレットの形のモジュール106、「ベースライン」マプレットの形のモジュール108、および「距離測定」ガジェットの形の畳まれたモジュール110を含む。タブエリア104は、選択されると、検索クエリに対する地理的結果を表示させる検索結果タブを含む。さらに、タブエリア104は、選択されると、いくつかのユーザ関連地図を表示させるマイマップタブを含む。例えば、ユーザが、自分の出身地周辺のエリアを示す地図をもっている場合がある。さらに、ユーザは、あるエリア内のすべてのWhite Castleというレストランを示す地図を保存している場合があり、この場合、適切なエリアを識別する郵便番号または他の類似情報を受け取るために、テキスト入力ボックス(図示せず)を設ければよい(または、エリアは、検索コントロール102に入力された情報から受け取ることができる)。マイマップ表示は、結果として、ユーザによって、地図とともに地図に対応付けられているマプレットの表示を生じ得る。
【００１９】
マプレットタブは、現在選択されているものとしてタブエリア104内に示されている。マプレットタブは、移植可能プログラムモジュールを、例えばマプレットの形で実装する１つまたは複数のiframeを含み得るフレームを提示する。モジュール106は、対象となるあるエリアに渡る、例えば米国全土に渡る予想最高気温を含む気象情報のデータベースにアクセスする拡張モジュールである。気温は地理に相関するので、地図112などの地図上に表示してよい。モジュール106によって生成されている２つのコントロールが示されており、こうしたコントロールを選択すると、当日または翌日の気温を取得させる。コントロールを選択することにより、後でより詳しく説明するように、データソースから気温データを取得させ、次いで地図112用のコードを生成する地図サーバに送信させることができる。
【００２０】
モジュール108は、「ベースライン」ガジェットを示し、このガジェットは、様々なスキー場での雪の「ベース」の厚さについての情報を取得する。モジュール108は次いで、この情報を、地図112に対応付けられたエンジンに渡し、そうすることによって、ベース情報は、地図112上の適切な地理的場所に図示される。さらに、モジュール110を圧縮された形で示してあり、このモジュールは、もしユーザがモジュールを使いたいときには拡張することができる。モジュール110は、「距離測定」と名付けられ、呼び出されると、地図112上でのユーザの地点選択を検知するように、地図112と対話することができ、次いで、選択された２地点の間の距離を計算することができる。他のモジュールを提供してもよく、こうしたモジュールは、ユーザがiGoogleから標準ガジェットにアクセスすることができるように、モジュールの中央の情報集配機能からユーザによってアクセスすることができる。
【００２１】
地図112は、他の画像構成要素を使用することによって生成された結果を示す。地図112は、ユーザ選択に従って位置決めされ、サイズが決められた標準地図を含み、例えばユーザによって検索コントロール102に入力された郵便番号が中心とされる。地図112の一部として重ねられるのは、気温114およびベースインジケータ116である。気温114は、モジュール106によってmaps.google.comなどの地図表示アプリケーションに渡される多数の異なる地理に相関した気温の１つでよい。同様に、ベースインジケータ116は、モジュール108によって地図表示アプリケーションに渡される多数の異なる地理に相関したインジケータの１つでよい。地図表示アプリケーションを、モジュール106およびモジュール108の両方からの送信に同時に応答させることによって、ユーザには、それ以外の方法では単一簡易表示では利用可能でなかった可能性のある２通りの情報を提示することができる。
【００２２】
図１Ｂは、図１Ａの表示にある項目を、図１Ａの実際の表示の下にある汎用オブジェクトとして示す。モジュールおよび地図出力を示す、ウェブページのある特定の実装形態用の様々な要素を、分かりやすくするためにここに示してあるが、特定の要素の選択は、限定的であることを意味しているわけではない。モジュールは、地図HTMLページ120に埋め込まれたiframe内部の、ここではマプレットスタブとして参照されるコードとして実装される。例えば、マプレットスタブ122は、図１Ａのコントロール106を実装するコードを表し得る。同様に、マプレットスタブ123は、図１Ａのコントロール108を実装するコードを表し得る。マプレットを収容するのに使われるiframe内部のHTMLドキュメントは、マプレットページと呼ばれ、例えば、HTML、CSS(スタイルシート)、およびスクリプトコードを含み得る。マプレットスタブ122、123は、地図120を生成するアプリケーションを動作させるサーバと通信するマプレットAPI(および関連ライブラリ)も含み得る。
【００２３】
移植可能プログラムモジュール(すなわち、定義された関数を実行し、様々なウェブページ上の様々なiframeなどの様々な環境に挿入することができるプログラム)のある特定の形態である各マプレットは、メタデータプロパティ、デフォルト値でのユーザ環境設定、HTMLテキスト、およびスクリプトコードを含み得る。スクリプトにより、マプレットは、動作および機能を実装することができる。コードは、地図アプリケーション用のドメインとは異なるドメイン上で収容されるiframeの中で動作し、クロスフレームまたはドメイン間の呼び出しを用いて地図アプリケーションと通信する。このような、フレームによるコードの分離により、一定レベルのセキュリティが課される。というのは、マプレットコードは、DOM APIの最大限度ではなく、提供されるAPIの限度まで、地図を操作することを制限されるからである。このような制限は概して、コードを実行中のブラウザによって課される。
【００２４】
マプレットコードには、後でより詳しく説明するように、外部のデータ供給へのアクセスを与えてもよい。HTTPプロキシサービスがこのようなアクセスを与えることができ、プロキシは、一定の状況において、データをキャッシュすることも、バックエンドとのトランザクションを実行することもできる。この状況においてプロキシを実装する標準機構を用いればよい。いくつかの実装形態では、マプレットコードは、ローカルクライアント上または中央データベースで格納されたユーザのアドレス帳など、ユーザ固有データへのアクセスも有し得る。このような情報にアクセスするためのセキュリティを、例えばユーザがこのようなサービスへのアクセスを明示的に可能にした後にのみ認められるベアラトークンを要求することによって提供してもよい。このような実装は、例えば、地図上で(例えば、ユーザの住所から友人の自宅までの)行き方を生成する際に、住所情報への自動または半自動アクセスを許可することができよう。さらに、マプレットコードは、Google Baseデータストアなど、他の外部のデータプロバイダにアクセスすることができる。
【００２５】
iframeの外で動作するHTMLページ120の部分は、マプレットホスト126として知られる。地図アプリケーションのこのエリア内にあるオブジェクトは、ホストオブジェクトとして知られ、マプレットスタブ中のこうしたオブジェクトのプロキシは、スタブプロキシとして知られている場合がある。ホストオブジェクトは、マプレットスタブによって提供された情報から生成することができ、マプレットスタブによって追跡することができる動作を有し得る。この図では、例えば、ホストオブジェクト128、130は各々、マプレットスタブ122によってホスト126に供給された地理的に相関した情報を有する気温を表し得る。スタブおよびホストの機能は、適切に準備されたライブラリによってサポートすることができる。
【００２６】
いくつかの実装形態では、例えばマプレットコードが信頼できるソースからのものであるとき、そのマプレットコードは、地図表示アプリケーション自体と同じドメインから実行することができる。このような実装形態により、より速い、同期した、より効率的な動作が可能になる。このような実装形態における地図表示アプリケーションとの対話は、Google Maps APIなど、地図表示アプリケーション用の標準APIを介して起こり得る。
【００２７】
図２は、地図表示アプリケーションを２つの移植可能プログラムモジュールと連携させるシステム200および処理の概念図を示す。図示した例において、システム200は、クライアント装置202と、クライアント装置202の動作用データを提供するいくつかのサーバ204、210、212、214とを備える。概して、システム200は、地図表示アプリケーションと対話するための移植可能プログラムモジュール(例えば、ガジェット／マプレット)を使用して、図１Ａに提示されるような機能を提供するように構成される。その結果、クライアント装置202のユーザは、地図に対応付けられた、カスタマイズされた結果を与える一定のモジュールを選ぶことができ、次いで、地図または多数の地図上での表示用にフォーマットされたデータを見ることができる。
【００２８】
クライアント装置202には、ウェブブラウザまたは他のインターネット関連のアプリケーションを設けてよい。ウェブブラウザは、マークアップコードおよびそれに対してリクエストを行うことができる様々なサーバから取得するJava(登録商標)スクリプトコードなど、他の同様のコードを実行することができる。例えば、移植可能コードサーバ210は、クライアント装置202のユーザに対応付けられたモジュール用コードを含むマークアップコードをブラウザに提供することができる。例えば、ユーザは、移植可能コードサーバ210に対応付けられたアカウントをもつことができ、コードサーバ210によって(例えば、サーバ側情報により、またはクッキーなどのクライアント側情報により)識別することができ、ユーザが予め構成しておいたマイマップのリストを与えられ得る。ユーザは次いで、地図の１つを選択してよく、自身のブラウザ上での実行用に配布された地図にコードを対応付けさせればよい。
【００２９】
例えば、クライアント装置202の表示において移植可能プログラムモジュール(例えば、マプレット)を生成するコードなど、様々な形のHTMLコードを含み得るマークアップコードを配布することができる。移植可能プログラムモジュールは、コンテナドキュメントによって表されるウェブページ上のiframeの一部でよい。概して、iframeとは、iframe要素を使って、別のHTMLドキュメントに埋め込むことができるHTMLドキュメントである。iframeが埋め込まれたドキュメント、すなわちこの例ではコンテナドキュメントは、iframe自体がまだ生成中の間にiframe周辺に生成することができる。コンテナドキュメント用およびiframe用のコードは、移植可能コードサーバ210によっても、他のソースからも提供することができる。
【００３０】
ウェブページ中にiframeを提供するHTMLコード例は、以下のものを含む。
<html>...
<iframe src="http://portablecode.com" height="100"
width="200" frameborder="0" scrolling="no">
</iframe>
...
</html>
【００３１】
このコードが示すように、iframe要素は、iframeに挿入されるべきドキュメント、iframeの寸法、およびiframe内部でスクロールが許されるべきかどうかを示すことができる。iframeの中のドキュメントは、別のドキュメントと置き換えることもでき、HTMLアンカーの「ターゲット」属性を用いることによって、またはAJAX(Asynchronous Java(登録商標)Script + XML)の実装形態においてJava(登録商標)スクリプトを用いることによって、修正し、またはコンテナドキュメント(例えば、周辺ページ)をリフレッシュすることなくリフレッシュすることもできる。例えば、ドキュメントのDOM(Document Object Model)ツリーの編集により、同様の表示を生成することができる。
【００３２】
クライアント装置202によって取得された移植可能プログラムモジュールは、コンテナドキュメント、移植可能コードサーバ、および他のサーバ204、212、214と通信することができる。地図サーバ204は、クライアント装置202からリクエストを受信し、図表による地理情報を、概して、２Ｄ地図、３Ｄ地図、または他の形の地図でありうる地図の形で提供する。さらに、地図サーバ204は、クライアント装置202から、または他のソースから地理関連データを受信することができ、この情報を地図上の場所と相関させ、クライアント装置202が地図の上にデータを表示できるように情報を返送することができる。クライアント装置202上で実行する(例えば、移植可能コードサーバ210によって提供される)コードと地図サーバ204との間の通信は、後でより詳しく説明するように、公開されたアプリケーションプログラミングインタフェース(API)に従って起こり得る。
【００３３】
広告サーバ214は、クライアント装置202上で動作するコードからリクエストを受信することもでき、こうしたリクエストに向けられた広告を生成することもできる。例えば、ある特定のエリア内の情報を求めるリクエストは、そのエリアの地図の生成に加えて、そのエリアに対応付けられた広告を広告サーバ214に生成させることができる。こうした広告は、リクエストに関する単なる地理以上のものを対象としてもよい。例えば、リクエストが「ドーナツ02128」を求めるものである場合、広告は、「ドーナツ」、「朝食」、または「食べ物」のような概念を対象としてよく、地理は、ボストンエリアを対象とし得る。
【００３４】
生成された広告は、画面の端付近にテキスト広告として提示してもよく、ユーザに提示される地図に埋め込んでもよい。広告が地図の中に提示される場合、その結果は、広告サーバ214によって地図サーバ204に、または適切な形式でクライアント202に直接送ることができる。その結果、ダンキンドーナツがシステムを通して広告することを選んだ場合、様々なダンキンドーナツ店のロゴを、検索結果の一部として地図上に示すことができる。
【００３５】
広告サーバ214、移植可能コードサーバ210、および地図サーバ204は、インターネットなどの中央のネットワーク206とは別個の共通ネットワーク208に付加されたものとして図２に示してある。ネットワーク208は、サーバ204、210、214がGoogleなどの単一情報プロバイダによって運営されることを示し得る。分かりやすくするために別々の個々のサーバとして示してあるが、ここで論じる様々なサービスは、色々なやり方で提供することができ、ただし地図表示サービスは概して、効率のために、広告サービスとは別個のサブシステムによって提供されることになり、移植可能コードの提供は、効率およびセキュリティ両方の目的のために(例えば、サードパーティによって送信される移植可能プログラムモジュールが標準API経由以外の地図表示アプリケーションに容易に影響を与えることができないように)、地図サービス用のドメインとは別個のドメイン上で行われ得る。
【００３６】
広告および地図と同じ組織からコードを提供するための移植可能コードサーバ210を示してある。ただし、様々な実装形態において、クライアント装置202は、コード、特に移植可能プログラムモジュール用のコードを、サードパーティ供給元から取得することができる。このような状況において、地図情報は、地図サーバ204から受信することができ、ユーザのウェブページの一部であるコードは、(例えば、上記で示したiframeの定義を用いて)移植可能プログラムモジュール中で実行されるべきコード向けの他の場所を指すことができる。コードの整合性をより容易に検証し保つことができるように、システム200は、地図表示アプリケーション(異なるドメインにあるものであったとしても)を供給する組織のみからの移植可能プログラムモジュールコードの使用を許可するように実装してもよい。
【００３７】
図２の文字つき矢印は、システム200内の構成要素によって実行される一連の動作の例を示す。矢印Aで示すように、クライアント装置202は最初に、例えばmaps.google.comにHTTPリクエストを向けることによって、地図サーバ204に対してウェブページを(例えば、ユーザがマイマップリンクを選択することによって)リクエストする。ターゲット組織(この例では、Google社)は、このリクエストを地図サーバおよび他の１つまたは複数のサーバに与えればよい。例えば、組織は、クライアント装置202上に格納されたクッキーを照会し、またはセッションIDをログインしているユーザと突き合わせるなどして、クライアント装置202のユーザを、組織の登録メンバとして識別することができる。組織は次いで、ユーザのリクエストを移植可能コードサーバ210にルーティングすればよく、サーバ210は、ユーザが１つまたは複数の移植可能プログラムモジュールを自身の個人用マップページまたは個人用ウェブページに対応付けさせていると判定することができる。地図サーバ204はまた、最初にメインのページ用のコードを配布してもよく、このコードは、例えばページ上のiframeの定義中で移植可能コードサーバ210を参照することができる。サーバ204、210は次いで、矢印B1(地図データ用)、B2(移植可能プログラムモジュールのコード用)で示すように、マップページコードおよびマップページコード中のiframeによって参照される移植可能プログラムモジュールのコードを配布することができる。
【００３８】
クライアント装置202は次いで、地図上に表示されるデフォルト値を含み得るマップページを、ユーザに対応付けられた「自宅」の場所を中心とした白地図を表示することなどによって表示することができる。移植可能プログラムモジュールは、後で論じるドメイン間通信などによって、メインのマップページに初期化値を渡すことができる。マップページ上の移植可能プログラムモジュールは次いで、ユーザによって、地図上での表示用に集められるべきデータを識別するように操作することができる。例えば、不動産モジュールでは、ユーザは、表示するべき家屋の種類(例えば、連続住宅や一戸建て)を選択すればよく、ドロップダウンボックスなどから、価格範囲を選択してもよい。適切なパラメータを選択した後、ユーザは、パラメータを送信することを選択すればよく、こうすることによって、適切な移植可能プログラムモジュール中のコードによってリクエストを生成させ、ここでリクエストは、地理関連データサーバ212に向けられる(矢印C)。地理関連データサーバ212は、あらゆる種類のデータを含んでよく、データが地理識別子に対応付けられている場合に特に適し得る。例えば、不動産一覧が探索される場合、データベース中の自宅の住所は、一覧に関する地理関連情報を表し得る。
【００３９】
一覧に関するデータは次いで、データをリクエストしたモジュールに戻せばよく(矢印D)、次いで、翻訳およびユーザに表示される地図への追加のために地図サーバ204に送信すればよい(矢印E)。データは、いくつかの実装形態では、クライアント装置202上の移植可能プログラムモジュールを通過することなく、地理関連データサーバ212から地図サーバ204または同様のサーバに直接提供することもできる。
【００４０】
地図サーバ204で受信されると、情報は、適切に地理的コード生成することができる。例えば、情報は、番地を記述するようにフォーマットすることができる。このように、地図サーバ204は最初に、番地を緯度／経度のペアに変換するなどして、受信した情報を、地理的コード生成された情報に変換する。地理的コード生成された情報は次いで、地図に関して配置することができ、各情報は、それに従ってフォーマットすればよい。情報は次いで、地図とともに表示するためにクライアント装置202に渡し、かつ地図の上に重ねてよい(矢印F1)。
【００４１】
いくつかの実装形態では、ターゲット広告は、システム200によって提供することもできる。こうした広告は、地理関連データに含まれる単語または概念に基づいて選択することができ、このデータはまず、地図上でユーザに対して表示されるべき地理的エリアの指示とともに、広告サーバ214に送ればよい。広告サーバ214は次いで、特定の概念および地理的エリアを対象とした適切な広告を選択すればよく、広告を地図上で適切な場所に配置することができるように、地理的コード生成されたデータを広告に提供することなどによって、こうした広告を提供することができる。例えば、広告サーバ214は、ある特定のレストランチェーンを、ユーザに適したものとして識別することができ、レストランチェーンのうち様々な店舗の住所を、地理的コード生成された形式(例えば、緯度／経度)に変換することができ、広告をクライアント装置202に直接、または地図サーバ204経由で間接的に配布することができ、そうすることによって広告は、クライアント装置202によって受信され地図上に表示されるようにフォーマットされる。
【００４２】
広告選択用キーワードは、情報を求める呼び出しを行う特定のモジュールに対応付けてもよい。例えば、リクエストに伴うある特定のキーワードを含むようにモジュールをプログラミングしてよく、そうすることによってキーワードは、選択されたターゲット広告に対して使うことができる。例えば、売却用家屋を閲覧するモジュール例は、その送信に伴って、「住宅供給」などの用語を含んでよく、そうすることによって建築機材および改築サービス用の広告をユーザに提供することができる。また、モジュール向けのキーワードは、広告サーバ214などのサーバにおいて格納することができ、そうすることによって特定のモジュール用識別子を広告サーバに提供するだけでよく、広告サーバは次いで、そのモジュール用の対応する用語(群)を探索することができる。
【００４３】
クライアント装置上のコンテナドキュメントからの情報の収集、地図サーバ204および地理関連データサーバ212へのその情報の送信、ならびに広告の送信はすべて、適切な実装形態において、少なくとも部分的には、コンテナドキュメントに対応付けられたページがロードされている間に起こり得る。したがって、移植可能プログラムモジュールに対応付けられたデータを示す特定の地図など、移植可能プログラムモジュールによって作成される表示は、関連ウェブページにアクセスしロードするとほぼ直ちにユーザによって閲覧可能になり得る。
【００４４】
移植可能プログラムモジュールには、クライアント装置202上でウェブページとともに表示するための情報にアクセスする追加機能が備えられてもよい。例えば、移植可能プログラムモジュールによって行われる呼び出しは、条件つきであっても反復してもよい。条件つき呼び出しの一例として、モジュールによって生成されたコントロールがある特定のやり方で設定されている場合にのみ、リクエストを地理関連データサーバ212に送信することができる。Java(登録商標)スクリプトおよびJava(登録商標)FXなどの言語によって提供される様々な関数は、移植可能プログラムモジュールによって実装することもでき、したがって豊富な対話を可能にすることを理解されたい。
【００４５】
移植可能プログラムモジュールによって生成される表示は、ユーザが結果と対話することを可能にする、ハイパーリンクなどのメタデータを含み得る。例えば、地図上に一定の情報を表示するテキストは、それを選択すると項目に対応付けられたウェブページにユーザを導くハイパーリンクに対応付けることができる。さらに、地図の上に提供される項目の上に(ポインティングデバイスを)移動させると、結果として、従来のやり方で項目に関する付加情報の表示を生じ得る。
【００４６】
図３は、移植可能プログラムモジュールを地図表示システムと統合するシステム例300の概略図である。概して、システム300は、インターネットなどのネットワーク304を経由して、クライアント装置302上での地図の生成用データを提供するいくつかのサーバと通信するクライアント装置302を含む。ウェブブラウザによって生成されるウェブページの部分に対応付けられた異なるドメインの一部である、クライアント装置302における特定の構造について、より詳しく示してある。図示した例は、ブラウザにおける様々なドメインの間の通信を可能にする構成を示す。概して、このような通信は、あるソフトウェアによって他のソフトウェアに侵入し、または引き継ぐのに用いることができるドメイン間通信を防止するための様々な機能をブラウザが含むので、推奨されず、困難である。
【００４７】
図３を参照すると、クライアント装置302は、緯度／経度の位置を導き出すための情報に対応付けられたデータなど、地図表示アプリケーションに適用されるデータを取得するためのリクエストをデータサーバ310に送信することができる。さらに、クライアント装置302は、地図サーバ308にリクエストを送信することができ、クライアント装置302からのリクエストは、図２に関して示すようにして、広告サーバ306にルーティングしてもよい。
【００４８】
地図表示関連ウェブページを生成するいくつかのソフトウェア構成要素を、クライアント装置302内に概念的に示す。こうした構成要素は、様々なページ部分、またはページを実装するコード部分である。こうした構成要素は、この例では、コンテナドキュメントを生成している構成要素と、コンテナドキュメントとともに表示される移植可能プログラムモジュールを含む構成要素との間のドメイン間通信を許可するように実装される。この特定の例では、コンテナドキュメントは、www.google.comなどの地図ページであり、移植可能プログラムモジュールは、ここでは、地図ページ上に生成され、表示される地図とともに対話するマプレットとして知られるガジェットである。
【００４９】
概して、通信は、アプリケーションからモジュールの１つまたは複数に、およびその逆方向に送られる情報用のリレーとしての役割を果たす、見えないiframeの使用により起こる。クライアント装置302内の各々の実線のボックスは、メインの地図ページ上のiframeを表し、破線のボックスは、地図アプリケーション324の状態を表す。モジュールの間の通信は概して、一時的接続を有するリモートプロシージャコール(RPC)を使用し、ここで応答を期待するリクエストは、それによって応答を受信することを期待する詳細(例えば、ソースiframe、用いるべきリレーurl)を提供する。
【００５０】
地図ルータ322は、地図アプリケーション324との通信を管理し、モジュールルータ318は、様々なモジュールとの通信を管理する。メインのウィンドウは、各ルータごとに１つのiframeを作成する。１つのルータiframeが、互いと通信することになるページ上のiframeの各ドメインに対応付けられる。各ルータiframeには、名前およびIDが割り当てられ、そのsrc属性は、そのルータがそのために作用するホスト上のルータhtmlファイルの場所に設定される。IDは、ルータを位置決めするための識別子であり、この例では、ルータのホスト名から一意に導き出される。例えば、ドメインgmodules.com上のマプレットホストは、以下のようにしてiframeを受け取ることができる。
<iframe id="gmodules.com"
name="gmodules.com"
src="http://gmodules.com/router.html">
</iframe>
【００５１】
ルータは、DOM操作により、ページへのルータ挿入を、ルータが必要とされることになるのが分かる(例えば、ユーザが「マプレット」タブを選択するとき)まで遅らせることによって作成することができる。各ルータの作成が概して他のルータの作成から独立しているという点で、ルータの作成は概して非同期でもある。その結果、ルータを作成する様々な処理は、一定の事例において、競合状態に入る可能性があり、この場合あるルータが別のルータより前に通信準備が整っていてよい。協調ルータ対話を助けるために、メインページは、各ドメインごとにルータを作成し、各ルータがロードし終えたときを観察するためのオンロードハンドラ(Java(登録商標)スクリプト関数)を付加し、すべてのルータがロードを完了するまで待ってから、マプレットiframeをロードする。
【００５２】
ルータが作成されると、各iframeは次いで、ルータがiframeにパケットを適切に転送することができるように、それ自体をルータに登録する。メインページがマプレットiframe(または通信システムを使うことを求め得る別のフレーム)を作成すると、そのフレームは、そのドメインに対応するルータを位置決めし、そのマプレットiframeと通信することになる各ルータにマプレットiframeのIDを登録する。そうする際、フレームは、(1)マプレットiframeのホスト名をそのiframeのsrcから計算し、(2)一意のルータ／id名を形成し、(3)“window.top.frames[nameOfRouter]”を呼び出すことによってそのルータを位置決めし、(4)“router.registerIframe(iframeID, relayUrl)”を呼び出すことによってマプレットiframeを登録することができる。この例では、iframeIDは、マプレットiframeのIDであり、relayUrlは、マプレットのドメイン用のリレーiframeのurlである。リレーiframeは、データパケットが他のiframeからそのターゲットマプレットiframeまで、そのマプレットのドメイン用ルータを介して送られるための機構である。
【００５３】
各ルータ318、322にはそれぞれ、共通ドメインに送られる小型パケットをターゲットルータにおいてマージし、パケットを分割するための対応付けられたパケタイザ(packetizer)318a、322aを設けることができる。パケットは、様々なiframeによるリクエストにあるデータグループを含んでよく、どの特定の形をとる必要もない。ルータ318、322は、関連地図アプリケーション324からであっても、あるいは関連マプレット312〜316の１つまたは複数からであっても、パケットが届いたら受信する。受信したパケットは、多数のソースにある、またはそうしたソースに関するデータグループを含み得る。例えば、モジュールルータ318は、モジュール312〜316にあるデータを受信することができ、地図ルータ322は、モジュール312〜316に関するデータを地図アプリケーションから受信することができる。このような多数のパケット状況は、特定の実装形態において共通でよい。例えば、地図上でマーカを作成し、地図に追加するためのコードは、あるパケットがマーカをつけ、別のパケットが地図に追加することを要求し得る。このような実装形態において、地図への10個のマーカの追加(例えば、10個の検索結果を表すため)には、20個のパケットが必要となるであろう。別の例として、モジュールは、同時に移動イベントの終わりなどの地図イベントを待つことが一般的であり得る。このような状況において、地図によって送られるパケットは、地図ルータ322によってマージされ、モジュールルータ318によってモジュール312〜316にブロードキャストされることになる。
【００５４】
地図ルータ322からモジュールルータ318への送信のために、パケタイザ322aは、受信したパケットを合成し、ルータ322は、こうしたパケットをドメイン境界を越えて送る。マーカを作成するための直列化コマンドは、以下の通りとすることが可能である。
101&-33.86,151.20&http://some.domain.com/marker.png
この例で、101は、「新規マーカを作成する」メソッドのidであり、-33.86,151.20は、マーカの場所を示す直列化緯度／経度のペアであり、http://.../marker.pngは、そのマーカを描画するときに使うべきアイコンである。
【００５５】
そのマーカの、地図への追加は従って、以下のような別の直列化コマンドになるであろう。
15&1&17
ここで、15は、「地図にオーバーレイを追加」メソッドのidであり、1は、オーバーレイが追加されるべきである地図のidであり、17は、地図に追加されるべきマーカのidである。
【００５６】
第２の(id 18をもつ)マーカの作成および同じ(id 1をもつ)地図への追加はしたがって、さらに２つの直列化コマンド
101&33.87,153.05&http://some.domain.com/marker2.png
および
15&1&18
を伴うことになる。効率のために、パケタイザは、こうした４つのコマンドが立て続けに単一ドメインに入っていくことを観察することができる。その結果、パケタイザは、以下のような単一パケットを形成することができる。
101&33.86,151.20&http://some.domain.com/marker.png;15&1&17;101&33.87,153.05&http://some.domain.com/marker2.png;15&1&18
【００５７】
この例では、パケット中の個々のコマンドを区切るのに、セミコロンを使っているが、実際には、コマンドを連結するどの置換可能な方式も、パケットを形成するのに用いることができる。概して、パケットの具体的なフォーマットは、適切などの形もとり得るが、ここに示す具体的な形は、例示的目的のためである。
【００５８】
パケタイザは、送信用の、かつ、許容可能なパケットサイズ向けの、所定の許容可能な待ち時間に従って、パケットのグループを送るまで待機するように構成される。例えば、Internet Explorerは、パケットを、url+ハッシュフラグメントに関しては4096バイトに、GET url用には約2048バイトに制限する。ルータは、第１の現格納パケットが届いてからの経過時間と、現格納パケットグループのサイズとを追跡することができ、いずれかのパラメータにおいて所定の値を超えたときにパケットグループの送付をトリガすることができる。
【００５９】
ルータは、いくつかの実装形態では、メッセージの順序づけが確実に保持されるようにすることもでき、例えば、そうすることによって、マーカを作成するためのリクエストが、地図にマーカを追加するためのリクエストの前に処理される。見えないリレーiframe(ルータの間でパケットを送るのに使われる)は、document.body.appendChildを呼び出すJava(登録商標)スクリプトDOMを使ってHTMLドキュメントの本文に挿入することができ、順序づけを強制するのに用いることができる。また、順序づけは、各パケットをカウンタで明示的にタグ付けし、受信機において、パケットをカウンタ昇順で並べ替えることによって、(iframeがロードされる順序の入れ換えを許可することによって)パケット順の入れ換えを許可するブラウザにおいて保持することができる。
【００６０】
その動作に関して、iframeは、iframeの適切なアクションを定義するライブラリに依存し得る。例えば、ルータは、応答確認、大型および小型パケットのマージおよび分割、ならびに他の同様のタスクを含む、ドメインの間の通信を扱うルータライブラリに依存し得る。他のiframeは、APIを定義しコールバックおよびサービスハンドラなどのコンテキストを格納するクライアントライブラリに依存し得る。
【００６１】
クライアントライブラリは、呼び出しサービス、登録サービス、および初期化サービスを含む様々なサービスを提供し得る。呼び出しサービスは、ルータを介して別のiframeにメッセージを送る。呼び出しリクエストは、ターゲットiframe ID、呼び出すべきサービスのサービスID(例えば、地図へのオーバーレイ(例えば、マーカ)の追加、地図上のある地点での情報ウィンドウのオープン、地図によるマプレットへのマウスクリックなどのイベントの報告、地理的コード生成(住所文字列の緯度および経度への変換)、地図上の２つ以上の地点の間の行き方のリクエストなどのより高度なサービス)用のパラメータ、サービスによって要求されるあらゆる引数、ならびにリプライに対するコールバックが起こるべきかどうかというインジケータを含み得る。
【００６２】
マプレットAPI中のJava(登録商標)スクリプト呼び出しの一例は、以下の通りとすることが可能である。
map.getCenterAsync();
この呼び出しは、現在の表示域(地図上の表示エリア)の中心の緯度および経度を地図が返送することをリクエストする。この呼び出しは、マプレットiframeによって、地図を含むメインページに対して行われる。この呼び出しに対応する直列化コマンドは、以下の通りとすることが可能である。
4&1&callback5
この例で、4は「地図の現在の中心を入手する」サービスのidであり、1は照会されている地図のidであり、callback5は、マプレットによって応答に割り当てられるidである。このリクエストに対する直列化応答は、以下の通りとすることが可能である。
callbackService&callback5&33.5,-27.3
ここで、callbackServiceは、照会に対する応答であることを示す特定サービス用のidである。callback5は、コールバックに割り当てられたidであり(したがって、マプレットJava(登録商標)スクリプトは、どこに結果を向けるべきか分かっている)、33.5,-27.3は、地図の中心の緯度および経度(コールバックに対して渡される応答)である。
【００６３】
登録サービス呼び出しは、新規サービスを登録し、ある特定のハンドラに対応付ける。ハンドラとして割り当てられるフレームに対する後続の呼び出しが次いで、そのサービスを利用することができる。サービスを登録するための呼び出しは、サービス用ID(そのサービスを利用することを後で求めるiframeによって使われる)およびサービスハンドラを含み得る。例えば、マプレットに地図の中心点を照会させるサービスにおいて、地図は、サービスid(上では4)およびサービスハンドラを含み得るサービスを、通信システムに登録することができる。サービスハンドラは、以下の通りでありうる。
GMap.prototype.getCenter() {return this.center;}
このサービスは、地図の中心を呼び出し側に返送することになる。地図に対して呼び出しが行われると、サービスidが、どのサービスハンドラを呼び出すべきか判定するのに使われる。このサービスハンドラが呼び出され、結果(この場合、地図の現在の中心)が、通信システムを経由して呼び出し側に返送される。
【００６４】
初期化呼び出しは、(親フレームから見て)呼び出し側フレームのIDをクライアントに知らせることによって、ドメイン間クライアントを初期化する。このような呼び出しは、ソースフレームIDを識別するパラメータを含み得る。ある特定のフレーム用のIDを知らされると、システムは、フレームへの情報のルーティングを行うことができる。
【００６５】
iframe「A」(名前／id「A」をもつiframe)からiframe「B」(名前／id「B」をもつiframe)に送られるメッセージについて検討する。最初に、iframe Aは、そのドメインについてルータと交信し、送るべきメッセージ、ターゲットidのiframe、および応答が期待される場合はコールバックハンドラ(関数)を与える。次に、ソースiframe A用のルータは、ターゲットiframe B用のルータと交信する必要がある。どのルータと交信するべきか知るためには、iframe idからルータドメインへのマッピングを既に与えられているべきである。このマッピングは、初期化呼び出し中に与えられる。メインのページは、新規マプレットiframe(または通信システムを使う予定の任意のiframe)を作成すると、そのiframe idおよびそのドメインを他の各ルータにも提供する。こうすることにより、外部iframeは、この新規マプレットiframeに、そのiframeの名前／idのみを知っている状態で交信することができる。
【００６６】
ルータライブラリは概して、多くのiframeを作成し破棄しなければならない状態を避けるように、通信用に使うことができるiframeプールのパケット化および維持を行う。プールに対応付けられたクラスは、iframeが作成されたとき、またはそのsrcがある特定のパケットに設定されたとき、iframeにロック済みの印をつけることなどによって、特定のルータに対応付けられた各iframeの現在の状態を追跡する。iframeがロードされると、プールクラスは、パケットが配布済みであると仮定し、iframeにロック解除(または再利用自由)の印をつける。異なるマプレットが異なるドメインに関する場合、ルータは、各ドメインごとに作成し、そのドメイン用のマプレットに対応付けることができる。
【００６７】
地図表示アプリケーションを有するこのような通信構造および技術の使用の一例は、地図アプリケーション324中の地図に、釣り関係のウェブページ上で識別された「最新の」釣り場スポットに対応付けられたマーカを付加するための、モジュールA312などのマプレットからの送信を含み得る。マプレットは、まずロードすることができ、次いで、ユーザによって、例えば、オオクチバスなど、一定のタイプの魚を識別するように操作することができる。ユーザは次いで、選択を送信することを選ぶことができ、そうすることにより、マプレットコードはデータサーバ310にアクセスする。サーバ310は、湖名ならびに最も直近の週末に湖で釣り上げられた魚の種類、数、および大きさを含む、地域のフィッシングレポートを格納するサーバでよい。
【００６８】
モジュールA312中のマプレットは、このようなデータサーバ310といくつかのやり方で交信することができる。第１に、クロスドメイン通信技術(クロスサイトスクリプティングリクエストなど)を用いて、このようなサーバ310にリクエストを直接行うことができる。第２に、Google Gadgets APIの一部としてiGoogleによって提供されるGoogleプロキシサーバなどのプロキシサーバを使用することができる。第３に、一部の事例(地図の地理的コード生成のAPIを使うときなど)では、包含ページ(地図アプリケーション)が、それ自体の代わりにサービス(Googleサービスなど)へのリクエストを行うことをリクエストすることができる。
【００６９】
データサーバ310は次いで、このようなすべての湖の一覧を、各湖で釣り上げられたオオクチバスについての情報とともに返送することができる。この情報を受信すると、地図アプリケーション324は、情報を地図サーバ308に転送させることができ、サーバ308は、湖名の形態の場所に関する情報を分析し、その情報を緯度／経度のペアまたは他の具体的場所データに変換することを試みればよい。サーバ308は次いで、湖の場所に関する情報をクライアント装置302に返送することができる。上記第１の方法では、マプレットは、サーバからデータを直接受信する。上記第２の方法では、リクエストおよび応答は、Google Gadgets APIの一部としてGoogleによって提供されるhttp://gmodules.com/ig/proxyサービスなどのサービスを通る。Googleプロキシサーバなどのプロキシサーバは、リクエストをリモートサーバに転送し、リモートサーバはGoogleプロキシサーバに応答し、プロキシサーバは、マプレットに応答を転送する。上記第３の方法では、ホストページ(地図アプリケーション)は、リモートサーバにリクエストを行い、リモートサーバから応答を受信し、次いでこの応答を、ドメイン間通信システムを経由してマプレットに送る。
【００７０】
モジュールA312は次いで、各湖ごとにマーカを付け、識別された各湖の所にマーカを置くコマンドを生成することができる。例えば、10個の湖がデータサーバ310によって返送された場合、20個のコマンドが生成可能であり、モジュールルータ318に与えることができる。パケタイザは、こうしたパケットをすべて合わせて、より大きなパケットにマージすることができ、パケットの配布のためにシステム内で許容可能な想定待ち時間に対応付けられた期間だけ待機すればよい。その期間に達すると、モジュールルータ318は、ドメインを越えて地図ルータ322にパケットを送り、ルータ322のパケタイザが次いで、(ある特定のモジュールによって送られたデータグループである)内部パケットを分析し、内部パケットを実行用に地図アプリケーション324に供給し、そうすることによって、マーカは、地図の上に適切に置かれる。同様にして、他のオブジェクトを地図に追加してもよい。
【００７１】
処理の一部として、地図アプリケーション324は、地図の上または周辺に広告を配置させることもできる。例えば、地図サーバ308によって生成された場所情報およびデータサーバ310に対するリクエスト中の他の情報(例えば、「オオクチバス」)を用いて、広告サーバは、特定の場所および集められた他の情報に適した広告を照会することができる。その結果、広告サーバ306は、場所特有ではなく、受信すると地図アプリケーションによって、表示地図の上に表示される広告専用のエリアなどに表示することができる１つまたは複数の広告を返送することができる。広告サーバ306は、広告主のために地図上にマーカおよび他の詳細な情報を地図アプリケーション324に生成させる、１つまたは複数の場所特有の広告を返送することもできる。
【００７２】
ドメイン間通信などにおける、記載したこうした特定の通信技術は、例示目的で挙げてある。適切な他の技術を用いてもよい。いくつかの実装形態では、記載した技術は、異なるドメインからのオブジェクトが、誠意のない当事者から的確に定義され保護されるやり方で互いと通信することを許可するための効率的であり好都合な機構を可能にし得る。
【００７３】
図４Ａ、４Ｂは、マッピングを基にした移植可能プログラムモジュールを動作させる処理のフローチャートである。図４Ａは概して、地図アプリケーションと対話する１つまたは複数のサーバによって実行することができる動作を示す。ボックス402で、サーバは最初に、ある特定のURLに向けられたGETコマンドを受信することができ、マプレット用の１つまたは複数のiframeを形成するコードを含み、iframe中でマプレットを動作させる、そのURLに対応付けられたマークアップコードを提供することができる。リクエストされたコードは最初は、コードが別のドメインを形成することを要求するiframeを生成するコードを含み得る、第１のドメインなどにある、メインのページ用のコードでよい。このコードは、実行される際、そのデフォルトのパラメータを使って、ユーザのデフォルトまたは自宅の場所周辺を中心とした地図の広域ビューを示すなど、デフォルトのパラメータに対応付けられた地図データをリクエストすることができる。
【００７４】
一定時間経過後、ユーザが、マプレットに新規パラメータを与えた場合があり、新規パラメータがクライアントによって送信されることをリクエストした場合がある。このようなリクエストにより、メッセージは、ある地理的エリアにおける賃貸不動産の価格を追跡するサーバなどのサードパーティサーバ(図示せず)に送られる。サードパーティサーバからの応答は、クライアント装置によって処理し、かつ／または地図サーバ用のAPIと互換性のある形式で地図サーバにルーティングすることができる(ボックス406)。地図サーバは次いで、受信した住所を緯度／経度の座標に変換することなどによって、受信した情報を地理的に相関させることができ、リクエストに関する地図データを提供することができる。例えば、地図サーバは、適切なエリア内で適切なズームレベルで地図用のタイル(tile)を送信することができ、地図の上に表示されるべきオブジェクトに関する緯度／経度の情報を返送することもできる。
【００７５】
図４Ｂは、図４Ａの処理と同様の処理420を示すが、クライアント装置の視点から示す。ボックス422で、クライアント装置は最初に、地図を指す結果を返送する(かつ結果を選択する)検索エンジンによって、または他の適切な機構によって、ユーザがmaps.google.com用のurlを選択することなどによって、地図ページをリクエストする。地図サーバは次いで、リクエストに応答してコードを送信することになり、さらに、コードのリクエスト側がサービスの登録ユーザであると判定した場合は、(例えば、特定のユーザにパーソナライズされたコードにマプレットを追加することによって、)コードの配布方法に影響を与え得る。ボックス424で、クライアント装置は、コードを受信しており、コードを実行して、米国の地図を示す表示などの一般の表示、およびマプレット中に提供される最小限の情報を有する１つまたは複数のマプレットを生成することができる。マプレット用コードは、例えば、iframe中に実装されると、付加情報またはコードを他のサーバからページに取り出させる。
【００７６】
ボックス426で、ユーザは、ドロップダウンリストから値を選択したり、空白フィールドに特定の値を入力したりすることによって、マプレットの１つに対してパラメータを与える。ユーザがパラメータを送信することを選ぶと、クライアント装置は、サードパーティのデータプロバイダに対してマプレットに関するデータ(例えば、クレイグスリスト(Craigslist)(地域情報コミュニティサイト)一覧)をリクエストすることができる。サードパーティのデータが配布されると、クライアント装置は次いで、結果用の地理的に相関したデータを生成するための解釈のために地図サーバに(おそらく編集し、かつ／またはフォーマットし直した後で)データを送信する(ボックス430)ことができる。地図サーバがリクエストを処理した後、クライアント装置は、地図データを受信し(ボックス432)、地図アプリケーションを使って地図上に地図データ(地図の別のエリア用の新規タイルも含み得る)を表示する(ボックス434)ことができる。
【００７７】
図５Ａ、５Ｂは、移植可能プログラムモジュールおよび地図表示アプリケーションの動作を連携させる処理のスイムレーン(swim lane)図である。概して、図５Ａに示す処理500は、ある特定の地図アプリケーションに対応付けられた２通りのマプレットへのユーザからの送信に応答して地図データを提供する簡易処理を示し、図５Ｂに示す処理530は、マプレットの選択およびユーザの個人用ページへの追加を示す。
【００７８】
図５Ａを参照すると、ボックス502で、ユーザは最初に、地図関連ページにアクセスし、マークアップコードを含むサーバがコードを送信し(ボックス504)、特定の地図データを含むサーバが、地図関連ライブラリおよびアプリケーションにおける初期表示用の一般地図を含み得るそのデータを配布する(ボックス506)。コードおよび地図情報の準備は、単一サーバによって生成することができる。コードサーバおよび／または地図サーバによって提供される一般情報は、ユーザによって使われる可能性のあるマプレットのリストを含み得る。
【００７９】
一定の状況において、識別されたマプレットは、コンテキスト依存でよい。例えば、地図アプリケーションの準備は、検索リクエストに応答して起きている場合があり、検索リクエスト中の用語の分析は、地図に関して一定のタイプの機能が所望されることを示す場合があり、その結果、その機能に対処するマプレットが、一般地図とともに表示される。マプレットはしたがって、このような状況において地図とともに提供すればよい。また、このような状況において、地図は、検索リクエストに適したやり方で(例えば、リクエスト中の郵便番号の周辺に)位置決めすることができ、かつ／またはマプレットに関するデフォルト値は、検索リクエストに基づいて選択することができる。あるいは、ユーザデータベースは、ある特定のユーザによって予め選択されているマプレットを判定するために照会することができ、個人用地図ページの一部として再度表示することができる。
【００８０】
ボックス510で、ユーザは、第１のガジェット用の特定のパラメータを選択し、データサーバに送信し、データサーバは次いで、送信されたリクエストに適し得るデータを返送する(ボックス512)。返送される情報は、場所を示す住所などの情報を含み得る。データを受信すると、クライアントは、データに対応付けられた地図情報をリクエストすることができ(ボックス514)、地図サーバは、リクエストを解釈し地図情報を提供することができる(ボックス516)。地図サーバから情報を受信すると、クライアントは、その情報を表現したものを地図アプリケーション中の地図に追加することができる(ボックス518)。
【００８１】
一定時間経過後、ユーザは次いで、実質的には、マッシュアップのマッシュアップを作成するために、別のマプレットにパラメータを与えることを選ぶことができる(ボックス520)。第１のマプレットに関して起きたのと同様の処理が、データを求めるリクエストおよびデータの提供(ボックス522)、提供されるデータに対応付けられた地図情報の後続リクエスト(ボックス524)、地図サーバからの地図情報の準備(ボックス526)、および地図サーバによって与えられる情報の表示(ボックス528)で起こり得る。このような表示は、第１のマプレットとの対話から、事前表示とともに起こり得る。その結果、ユーザは、特定の２つのマプレットアプリケーションを選択し、マプレットアプリケーションの両方からの情報を合成する表示を生成することが可能である。
【００８２】
図５Ｂは、概してユーザによる、マップページとともに表示されるべきマプレットの選択、およびマプレットの後続使用を示すが、この図を参照すると、ユーザは(クライアント経由で)最初に、地図ページにアクセスし(ボックス532)、コードおよび一般地図情報を受信することができる(ボックス534、536)。ただし、この事例では、どのマプレットもガジェットも予め選択されていない。そうではなく、ユーザには、Google個人用ホームページ、すなわちiGoogleにおけるガジェット選択のように実装することができる、いくつかの利用可能マプレットの表示が与えられる(ボックス540)。マプレットは、カテゴリにまとめて並べることができ、ユーザは、カテゴリの１つを選択し(ボックス542)、次いで、選択されたカテゴリ中にある特定のガジェットを選択するコントロールをさらに提供され得る(ボックス544)。
【００８３】
ユーザは次いで、ある特定のマプレットまたはガジェットを選択することができ(ボックス546)、こうすることにより、今後、ユーザがシステムにアクセスするときに、選択されたマプレットがロードされるべきであることを示すように、コードサーバにユーザのプロファイルをアップデートさせることができる(ボックス548)。サーバは、マプレット用のコードを送信することもでき、その結果マプレットは、地図ページ上で、新規に作成されたiframe中に表示される。マプレットコードは、配布されると、データサーバに対してデータをリクエストし(ボックス552)、受信したデータを使って地図サーバに対して(ボックス556)地図情報をリクエストし(ボックス554)、地図上にデータを表示する(ボックス558)ように動作することができる(ボックス550)。
【００８４】
図６は、ウェブブラウザによって表示されるドメインの間の通信を連携させる処理のフローチャートである。概して、この処理およびこのような他の処理は、図３に示す構成要素によって実行することができる。図６は概して、パケット化されたいくつかのパケットの、ドメイン境界を越えた転送を示す。最初に、データグループ(パケットでも、ページによって送信される他の特定のデータグループでもよい)が、リレーまたはルータにおいて受信される。ルータは、１つのデータグループまたは複数のデータグループを受信することができ、そのパケット化規則を調べて、受信したグループをパケット化する順序を判定し、それ以上のパケット保持が保証されるかどうか判定する(すなわち、より大きくより効率的な送信用合成パケットを構築するため)こともできる。合成パケットの送信が規則によってトリガされない場合(ボックス606)、受信したデータグループは、パケットバッファに追加され(ボックス608)、送信がトリガされた場合、ルータは、保持しているデータグループおよび他のデータグループをパッケージ化し送信する(ボックス610)。
【００８５】
送信はドメイン境界を超え、ボックス612で、対応するルータが合成パケットを受信する。そのルータは次いで、所定の規則に従って、合成パケットを逆アセンブルして、送られるデータグループをパケットから抽出することができる(ボックス614)。最後に、受信用ルータは、その特定のドメイン内のフレームに個々のデータグループをルーティングすることができる(ボックス616)。
【００８６】
図７は、ブラウザが表示したウェブページ上のドメインの間でデータを送る処理のスイムレーン図である。ボックス702〜712で、３通りのデータグループが、ページ上のある特定のドメインに対応付けられた地図アプリケーションから受信される。例えば、ユーザは、地図を動かすか、あるいは地図に対応付けられた３通りのマプレットに適したように地図に影響を与えていてよく、地図アプリケーションは、このようなアクションを報告している最中であってよい。地図ルータは、最初の２つのデータグループを保持し、第３のグループを受信すると、合成パケットの待ち時間またはサイズにより、ドメイン境界を超える合成パケットの送信が必要かどうか判定する。ボックス714で、ルータは、ターゲットドメインを判定し、そのドメインにパケットを送る。
【００８７】
モジュールルータは、マプレットの形のいくつかの移植可能プログラムモジュールが存在するドメインに対応付けられたルータであり、合成パッケージを受信し(ボックス716)、パッケージを分解して、その中に配置されたデータグループを抽出する(ボックス718)。合成パッケージからデータグループを抽出すると、モジュールルータは、各データグループのアドレスを判定し、そのグループを、適切なマプレットに従ってルーティングする(ボックス720、724、728)ことができ、この場合、ページ上の地図アプリケーションに対応付けられた多数のマプレットがある。データは次いで、各マプレット中で実行し得る(ボックス722、726、730)。
【００８８】
図８は、２つの移植可能プログラムモジュールと連携して動作する地図アプリケーションの例を示すスクリーンショットである。第１のモジュールは、表示に追加されるべき追加モジュールを選択する機会をユーザに与える。例えば、モジュールに対応付けられたサーバは、シカゴにおける犯罪、地図に加えられる天気(例えば、気温および日照／雨／雪の状態)のマッピングに関するモジュール、および他の様々なモジュール用のコードを格納することができる。自分のページに追加したいモジュールを選択するために、チェックボックスコントロールがユーザに提供される(ページは、個人用地図ページとして保存することができる)。さらに、マプレットがその範囲内であるマプレットタイプやサブグループなど(例えば、測定ツール、生活ツール、ビジネスツール、地図表示ツールなど)、選択用の値を示すために、色つきドットを各選択の隣に示すことができる。
【００８９】
距離測定ツールモジュールが、ユーザによって予め選択されており、拡大された形で表示される。距離測定ツールは、メインの地図アプリケーションと対話して、ユーザが地図上の２つ以上の地点を選択し(または、州、町、および番地などで、２つ以上の場所を識別し)、次いでその地点を結ぶ距離を計算し、ユーザに対して距離を表示させる。
【００９０】
こうしたモジュールのうちそれ以外のものは、選択された場合、その出力を距離測定ツールと合成することができる。例えば、ユーザがシカゴ犯罪モジュールを選択した場合、地図は、シカゴにズームインするように、かつシカゴにおいて犯罪が起きたエリア用のインジケータを示すように変形することができる。ユーザは次いで、距離測定ツールを使って、犯罪現場の間の距離または他の情報を判定することができる。このようにして、表示されるアプリケーションは、多数のアプリケーションを、表示アプリケーション用にカスタマイズされ、Googleマップなどの地図表示サービスに直接アクセスするようにユーザがマッシュすることを可能にし得る。
【００９１】
図９は、いくつかの移植可能プログラムモジュールを含むコンテナドキュメント900のレイアウト例を示す。iframeおよびインラインHTML技術の使用を含む、いくつかの結合方法が可能である。図９は、株式モジュール905、eメールモジュール906、リアルタイム広告モジュール908、広告モジュール910、912、マプレットモジュール916、および地図モジュール914を含む複数のモジュールを示す。モジュールの作成者によって提供される仕様に応じて、様々なモジュール用の異なる形式が存在し得る。一部のモジュールはスクロールバーを提供することができ、それ以外のモジュールは提供することができないことがある。一部のモジュールは、他のモジュールとは異なるサイズまたは形状でよい。さらに、一部のモジュールは、モジュールに対応付けられた表示環境設定および／または使用ごとのデータを編集する機会をユーザにもたらし得る。
【００９２】
一実装形態では、インラインモジュールが、コンテナドキュメントによって自動的にサイズを決められ得るので、スクロール、高さ、またはスケーリング情報は与えなくてよい。モジュール開発者が、こうしたプロパティをモジュールにもたせたい場合、インラインモジュールを、固定サイズ<DIV>タグおよびタグ中に配置される内容でラップすればよい。次いで、スクロールバー、高さ、および他の特性をインライン内容に対して指定すればよい。属性の１つは、スケーリング=「...」と指定させて、コンテナドキュメント中の異なる配置サイズに合わせてモジュールをどのように拡大または縮小すればよいかを開発者に示させる。
【００９３】
このコンテナドキュメント例900で与えられる関数の１つは、ガジェット追加要素903の選択によりコンテナページにコンテンツを追加する機会である。「ガジェット追加」要素903を選択すると、システムは、コンテナページに含まれるべき追加要素を対話形式で示す機会をユーザにもたらすことができる。その入力を受信するためのインタフェースの様々な形を提供することができる。
【００９４】
さらに、モジュールを追加し、編集し、または消去する際、こうした活動を、コンテナドキュメントのリフレッシュなしで起こさせることが望ましい場合がある。これを達成する例示的な一技術は、モジュールをコンテナドキュメントページのリフレッシュなしで(おそらく、新規コンテナが提示されるiframeのリフレッシュのみで)コンテナドキュメントに追加するようなAJAXプログラミング技術の使用、あるいは、コンテナドキュメントがリフレッシュされることなくモジュールを削除するためのAJAXの使用、あるいは、開発者がモジュールを開発中である場合には、変更モジュールを組み込むために、モジュールが付加されるコンテナドキュメントがページリフレッシュを行う必要もなくモジュールを変更可能とすること、を伴い得る。
【００９５】
特定のモジュールを参照すると、マプレットモジュール916は、上で論じたような、移植可能プログラムモジュール用のコードを参照するiframe中に表示することができる。マプレットモジュール916は、maps.google.comなどの地図サーバ用ドメインに対応付けることができ、地図用タイルを受信し表示し、マプレットモジュール916によって提供されるオブジェクトを表示し、マプレットモジュール916にフィードバックを与えるように構成することができる、地図モジュール914などの他のモジュールと対話することができる。
【００９６】
他のモジュールも、システム内で通信を行うことができる。例えば、eメールモジュール906は、ユーザ向けの予定に関する情報を有するカレンダ機能も含み得る。eメールモジュール906は、ユーザ向けの今後の予定に関する時間、場所、および他の情報を求めるリクエストをマプレットモジュール916から受信することができ、このような情報をマプレットモジュール916に返送することができる。マプレットモジュール916は次いで、予定に関する地理的に相関したデータを取得するために、地図サーバに住所情報を転送することができる。マプレットモジュール916は次いで、地図モジュール914によって表示される地図に掲示させるべき各予定にオブジェクトを対応付けさせることができる。同様にして、広告モジュール910、912は、例えばマプレットモジュール916や地図モジュール914から地理情報を受信することができ、情報の中にある特定の選択肢および／または場所を対象としたターゲット広告を取り出すことができる。
【００９７】
図１０は、広告および他の項目を動的に生成するシステム例1000の概略図である。システム1000は、様々な動作のために、ガジェットなどの移植可能プログラムモジュールを利用するシステムの全体的な表現である。本明細書に記載する全体的な動作は、適切な場合、図１Ａ、１Ｂ、２、３に示すシステムに適用可能である。
【００９８】
システム1000は、システムに関係しうる複数のモジュールを有するホストサーバシステム1010を含み得る。このようなモジュールは、コンテナサーバ1012、モジュールサーバ1014、仕様サーバ1016、バックエンドサーバ1018、分析モジュール1028、モジュール作成サーバ1032、配信サーバ1034、および広告サーバ1036を備え得る。図に示すように、ホストサーバシステム1010は、ネットワーク1026を介して他の複数のシステムまたはサブシステムに接続することができる。
【００９９】
ネットワークに接続される他のシステムは、１つまたは複数のユーザシステム1022、１つまたは複数の遠隔項目サーバ1024、１つまたは複数のモジュール開発者システム1030および１つまたは複数の記事受信(syndication recipient)サーバ1038を備え得る。さらに、１つまたは複数のデータベースシステム1020が、ホストサーバシステム1010の様々なモジュールと連動して動作することができる。
【０１００】
特に、別個の１つのサーバは、ある特定のAPIに合致するリクエストに応答して地理的データを提供することができる地図サーバ1031でよい。あるいは、地図サーバは、ホストサーバシステム1010の一部でもよいが、ここでは、システム1000を使用するアプリケーションが多数のシステムを越えて通信できることを例示する目的のために別々に示してある。地図サーバは、例えば、マプレットまたは他の移植可能プログラムモジュールを生成するなどのために、ホストサーバシステム1010内の構成要素によって提供されるコードを動作させるユーザシステム1022からリクエストを受信することができる。
【０１０１】
ホストサーバシステム1010の構成要素を再度参照すると、コンテナサーバ1012は、ネットワーク1026を介してユーザシステム1022にコンテナドキュメントを提供することができる。コンテナサーバ1012は、データおよび／または命令を受信し、ネットワークを介したユーザシステム1022への送信用にコンテナを形成するウェブサーバまたは関連サーバシステムを使うことができる。ただし、このコンテナサーバ1012は、ネットワーク接続を用いることができるように、ユーザシステム1022にあってもよい。コンテナドキュメントが文書処理ドキュメントを含むこの例では、例えば、コンテナサーバ1012は、文書処理モジュールを備え得る。
【０１０２】
モジュールサーバ1014は、モジュールにあるデータを、コンテナドキュメントに結合するためにコンテナサーバ1012に提供することができる。一実施形態では、コンテナサーバ1012およびモジュールサーバ1014は、本明細書に記載する他のサーバおよびモジュールが備え得るように、両方の関数を実施する単一ユニットを備え得る。モジュールサーバ1014は、モジュールに関するモジュール仕様における命令を解釈し、かつ／または解析することによって、コンテナドキュメントにデータを提供することができる。一実施形態によると、モジュールサーバ1014は、ブラウザiframeの使用により、コンテナドキュメントにモジュールの内容を提供することができる。
【０１０３】
コンテナドキュメントの表示を手早くするために、モジュールは、コンテナドキュメント内部にインラインで表示すればよい。インライン表示は、他のドキュメント要素をもつ表示を参照するものと理解することができよう。一例が、HTML標準に従った本文中のHTML用コードから生成される表示である。一実施形態では、モジュールサーバ1014または他の一部の構成要素は、インラインモジュールが生じ得るであろう様々なセキュリティ問題の危険性により、コンテナドキュメントにモジュールを含める前に、モジュールが信頼されるとみなされるかどうか判定することができる。一実装形態によると、モジュールは、コンテナモジュールまたはコンテナモジュールに対応付けられたエンティティによって発行される承認の印(例えば、デジタル証明書)を埋め込むことができる。承認の印が存在する場合、モジュールサーバ1014は、モジュールにあるデータを、コンテナドキュメント中でのインライン提示用に描画することができる。
【０１０４】
仕様サーバ1016は、モジュールサーバ1014にモジュール仕様ファイルを提供する。モジュール仕様は、モジュールサーバ1014および／または仕様サーバ1016にとってアクセス可能なデータベースにキャッシュし格納することもでき、後で詳述するように、仕様に対応付けられた場所から取り出すこともできる。例えば、仕様サーバ1016は、遠隔項目サーバ1024上に存在し得る。さらに、仕様サーバ1016は、仕様サーバ1016にとってアクセス可能なネットワーク上の別の場所に置かれたモジュール仕様を有するモジュールサーバ1014に、ネットワークを介して接続することができる。
【０１０５】
１つまたは複数のデータベース(例えば、大規模または動的情報データベース)と対話するバックエンドサーバ1018を提供することができる。(例えば、RSS(Rich Site Summary/RDF Site Summary)の供給から、) 例えば、頻繁に更新を取得し、データフローを必要とするニュースモジュールに対して、バックエンドサーバ1018は、データをコンテナ用のHTMLにフォーマットすることができる。
【０１０６】
具体的な一例では、ある人が、カリフォルニア州マウンテンビュー中心部の地図を表示するためのモジュールを作成するのに、既存の地図表示プログラムへのアプリケーションプログラムインタフェース(API)を使うようなモジュール(例えば、地図モジュール)を作成することができる。このモジュールは、仕様サーバ上に格納されたXML仕様ファイルまたはモジュール仕様ファイルを含み得る。仕様サーバは、コンテナページを運営するためのサイト上のサーバを含む、適切などのサーバも含み得る。ユーザまたは別の人が次いで、この新規モジュールを、個人用ホームページまたは別の形のウェブページ(コンテナドキュメント)上に含めることができる。コンテナドキュメントを提供するサーバは、モジュールサーバとして動作することができ、そのAPIからの照会により地図表示データを生成するサーバは、バックエンドサーバであるとみなすことができる。
【０１０７】
一実装形態では、分析モジュール1028は、様々なとき(例えば、モジュールがユーザによって最初に選択されるとき、包含するためにコンテナによってモジュールが呼び出される度、または安全性およびセキュリティのために有利であると判断される他の任意のとき、および他のとき)にモジュールを分析することができる。分析モジュール1028は、モジュールと、許可しないまたは危険なモジュールのリストあるいは承認されたモジュールのリストとの比較を含むいくつかのアクションを実施することができる。この比較は、名前または場所(例えば、URL)、仕様の内容、仕様が存在する場所の内容、あるいはモジュールについて確認可能であり得る情報による完全または部分文字列(例えば、プレフィックス、サフィックスおよび正規表現)の一致を伴い得る。
【０１０８】
分析モジュール1028は、モジュールが許可しないまたは危険であるという判定に応答して、例えば、リクエストを黙殺して遮断すること(すなわち一般のエラーを出すこと)、遮断された理由を説明するエラーでリクエストを遮断すること、あるいは安全であるとともに許可しないモジュールに関係すると判定された異なるモジュール仕様(例えば、第１のモジュールが許可しない地図表示サイトだった場合は、地図に関する別のモジュール、または許可しないモジュールがバスケットボールモジュールだった場合は「バスケットボール」というキーワードを含むモジュール)にリクエストをリダイレクトすることを含む、１つまたは複数のアクションをとり得る。
【０１０９】
例えば、リダイレクションにより、オリジナルモジュールのURLは、「安全」モジュールに渡してよい。安全モジュールは次いで、プロキシサーバを使って、後で説明するようにオリジナルURLの内容を取り出すことができる。開発者は次いで、オリジナルモジュール中の小さなバグを、オリジナルモジュールの内容を表示することができるように直すためのエラーハンドラを置き換えることができる。別の実施形態では、分析モジュール1028は、モジュールに含まれるJava(登録商標)スクリプトまたは他のスクリプトをコンパイルすることなどによって、安全かどうか判定するためにモジュールの内容を解析して、モジュールが実施し得る安全でない、または望まれないアクションの識別を試みることができる。
【０１１０】
１つまたは複数のモジュール作成サーバ1032を提供することができる。こうしたサーバは、モジュール作成者が対話処理によりモジュールを作成することを可能にするための「ウィザード」として動作し得る。例えば、モジュール作成サーバ1032は、モジュールを作成するある人が、モジュール仕様を自動的に生成するのに使われる入力を与えることを可能にする一連のユーザインタフェースを提供することができる。例えば、様々なモジュール仕様テンプレートに、対応する入力を与えてよい。モジュール作成サーバ1032は次いで、ユーザによって供給された入力を受け取り、テンプレートに挿入し、モジュール用のモジュール仕様を生成することができる。プレビュー、テスト、およびデバッグ機能を、「ウィザード」の一部として提供することもできる。このモジュールは、クライアントにダウンロード可能であってもよい。
【０１１１】
配信サーバ1034は、モジュールに関する、１つまたは複数の記事受信サーバ1038への送信用のデータを用意することができる。配信サーバ1034は、モジュールおよび／またはモジュールの内容を求めるリクエストを受信し、そのモジュールまたは内容を、ネットワーク1026を介して記事受信サーバ1038に配布することができる。配信サーバ1034は、ホストサーバシステム1010またはネットワーク上の別の場所に存在し得る。
【０１１２】
例えば、スポーツウェブサイトのオペレータ(記事受信システム1038の例)は、遠隔ソースシステム1024によって作成された広告用モジュールを含めることを望む場合、配信サーバ1034へのリクエストにより含めることができる。配信サーバ1034は次いで、モジュールサーバ1014と協働して、コンテナドキュメント(ここでは、記事受信システム1038用のスポーツウェブサイトページ)用のデータを生成することができる。この生成は、遠隔ソースシステム1024からモジュール仕様を取り出すこと、記事受信サーバ1038から受信された環境設定(例えば、表示されるページのスポーツチームの本拠地情報)を供給すること、および／またはコンテナ用データを生成することを伴い得る。記事受信サーバ1038において、そのコンテナドキュメントにiframe中に、またはインラインにデータを描画できることも可能である。配信サーバ1034はしたがって、それにとってアクセス可能なモジュールを配信することができる。配信サーバ1034は、具体的モジュールを求めるリクエストまたはサーバ1034が判定した他の基準(例えば、内容一致、キーワード一致、モジュールおよび／または配信リクエスト側に対応付けられた金銭的価値など)に基づいて配信を行うことができる。
【０１１３】
広告サーバ1036は、モジュールに対応付けられた広告を、このようなモジュール用の表示を作成するコンテナおよび／またはデータに提供することができる。例えば、データがコンテナドキュメントに配布されるとき、広告は、モジュールデータとともに埋め込むことができる。広告サーバ1036は、モジュールを求める配信リクエストに基づいて、記事受信サーバ1038に広告を配布するように、配信サーバ1034とともに動作することができる。広告は、コンテナ、モジュール、コンテナ中の他のモジュールの内容または情報、記事受信サーバ情報の間の関係、上記のいずれかおよび／またはその合成に関する金銭的要素／関係を含むが、それに限定されない、非常に様々な基準に基づいて、広告サーバ1036によって選択することができる。
【０１１４】
広告サーバ1036は、一実装形態によるGoogle AdSenseシステムを備え得る。具体的には、広告サーバ1036は、モジュールに関する２つ以上の概念を広告に対応付け、１つの勧誘を、まとめて、２つ以上のキーワードに対応付けることによって、オンライン広告を管理することができる。さらに、配信サーバ1034または広告サーバ1036は、モジュールに対応付けられたコンテナページを記述する情報を求めるリクエストを送る広告関連モジュールなど、配信されるモジュールに対するリクエストに応答することができる。
【０１１５】
適切な任意の数のやり方で、コンテナ情報、モジュール仕様および／または関連情報、フォーマット用データ、ユーザごとおよびモジュールごとの環境設定データ、遠隔モジュールIDデータ、遠隔モジュール場所参照データ、広告データ、広告主データ、コンテンツ／金銭データ、記事受信データ、モジュール用テンプレート、モジュール向け入力、信頼できる、および信頼できないモジュールのリスト、承認基準および関連情報ならびに／あるいはモジュールによって本明細書に記載するように動作するのに用いられる他のどの情報も格納する１つまたは複数のデータベースシステム1020を提供することができる。単一データベース構造を示してあるが、データは、いくつかの場所、および１つまたは複数のシステムに格納することができる。
【０１１６】
一実装形態では、モジュールをコンテナドキュメントに埋め込むためのシステムおよび方法が提供される。コンテナドキュメントの一例は、インターネット上のGoogleサービスのユーザにとって現在利用可能である、Google個人用ホームページ、すなわちiGoogleなどの個人用ホームページであろう。ユーザが個人用ホームページなどのコンテナドキュメントに含めることができるコンテンツのタイプを制限するのではなく、１つまたは複数の実装形態が、コンテナドキュメントのソース以外のソースからユーザがモジュールを選択することを可能にし得る。したがって、例えばユーザは、Googleに対応付けられていないソースから、自身の個人用Googleホームページにモジュールを含めることを選ぶことができる。
【０１１７】
図１１は、本明細書に記載する技術を実装するのに使うことができるコンピュータ機器1100および携帯コンピュータ機器1150の例を示す。コンピュータ機器1100は、ラップトップ、デスクトップ、ワークステーション、携帯情報端末、サーバ、ブレードサーバ、メインフレーム、および他の適切なコンピュータなど、様々な形のデジタルコンピュータを表すことを意図している。コンピュータ機器1150は、携帯情報端末、携帯電話、スマートフォン、および他の同様のコンピュータ機器など、様々な形の携帯機器を表すことを意図している。ここに示してある構成要素、その接続および関係、ならびにその機能は、例示的であることを意味するに過ぎず、本明細書において記載し、かつ／または特許請求される本発明の実施形態を限定することは意味していない。
【０１１８】
コンピュータ機器1100は、プロセッサ1102、メモリ1104、記憶装置1106、メモリ1104および高速拡張ポート1110に接続する高速インタフェース1108、ならびに低速バス1114および記憶装置1106に接続する低速インタフェース1112を含む。構成要素1102、1104、1106、1108、1110、1112はそれぞれ、様々なバスを使って相互接続され、または必要に応じて他のやり方で共通のマザーボード上に搭載することができる。プロセッサ1102は、高速インタフェース1108に結合されたディスプレイ1116など、外部の入力／出力装置上にGUI用のグラフィック情報を表示するための、メモリ1104内または記憶装置1106上に格納された命令を含む、コンピュータ機器1100内で実行するための命令を処理することができる。他の実装形態では、多数のプロセッサおよび／または多数のバスを、必要に応じて、複数のメモリおよび複数の種類のメモリとともに使うことができる。また、複数のコンピュータ機器1100を接続してよく、各々の機器は、(例えば、サーババンク、ブレードサーバのグループ、またはマルチプロセッサシステムとしての)必要な演算部分を提供する。
【０１１９】
メモリ1104は、コンピュータ機器1100内に情報を格納する。一実装形態では、メモリ1104は、１つの揮発性メモリユニットまたは複数のユニットである。別の実装形態では、メモリ1104は、１つの不揮発性メモリユニットまたは複数のユニットである。メモリ1104は、磁気または光ディスク、別の形のコンピュータ読み取り可能な媒体でもよい。
【０１２０】
記憶装置1106は、コンピュータ機器1100用の大容量記憶を提供することが可能である。一実装形態では、記憶装置1106は、フロッピー(登録商標)ディスク装置、ハードディスク装置、光ディスク装置、またはテープ装置、フラッシュメモリもしくは他の同様の固体メモリ装置、あるいは、ストレージエリアネットワーク内の装置または他の構成を含む装置アレイなどのコンピュータ読み取り可能な媒体でもよく、その媒体を含んでもよい。コンピュータプログラム製品は、情報担体として有形に実現することができる。コンピュータプログラム製品は、実行されると、上述したような１つまたは複数の方法を実行する命令も含み得る。情報担体は、コンピュータ、またはメモリ1104、記憶装置1106、プロセッサ1102上のメモリ、もしくは伝播信号などのマシン読み取り可能な媒体である。
【０１２１】
高速コントローラ1108は、コンピュータ機器1100用の帯域消費型演算を管理し、低速コントローラ1112は、より低い帯域消費型演算を管理する。このような機能割振りは、例示に過ぎない。一実装形態では、高速コントローラ1108は、メモリ1104、ディスプレイ1116(例えば、グラフィックスプロセッサまたはアクセラレータを経由して)、および様々な拡張カード(図示せず)を受け入れ得る高速拡張ポート1110に結合される。この実装形態において、低速コントローラ1112は、記憶装置1106および低速拡張ポート1114に結合される。低速拡張ポートは、様々な通信ポート(例えば、USB、ブルートゥース(登録商標)、イーサネット(登録商標)、無線イーサネット(登録商標))を含み得るが、キーボード、ポインティングデバイス、スキャナ、またはスイッチやルータなどのネットワーク装置など、１つまたは複数の入力／出力装置に、例えばネットワークアダプタを経由して結合することができる。
【０１２２】
コンピュータ機器1100は、図に示すように、いく通りかの形で実装することができる。例えば、標準サーバ1120として、またはこのようなサーバのグループの形でいくつも実装することができる。ラックサーバシステム1124の一部として実装することもできる。さらに、ラップトップコンピュータ1122などのパーソナルコンピュータの形で実装することもできる。あるいは、コンピュータ機器1100にある構成要素を、機器1150などの携帯機器内の他の構成要素(図示せず)と組み合わせてもよい。このような機器はそれぞれ、コンピュータ機器1100、1150の１つまたは複数を含んでよく、システム全体は、互いと通信する多数のコンピュータ機器1100、1150から構成することができる。
【０１２３】
コンピュータ機器1150は、他の構成要素の中でも特に、プロセッサ1152、メモリ1164、ディスプレイ1154などの入力／出力装置、通信インタフェース1166、および送受信器1168を含む。機器1150には、追加記憶を提供するために、マイクロドライブや他の装置などの記憶装置を設けてもよい。構成要素1150、1152、1164、1154、1166、1168はそれぞれ、様々なバスを用いて相互接続され、構成要素のいくつかは、共通のマザーボード上に、または必要に応じて他のやり方で搭載することができる。
【０１２４】
プロセッサ1152は、メモリ1164に格納された命令を含む命令をコンピュータ機器1150内部で実行することができる。プロセッサは、別個の多数のアナログおよびデジタルプロセッサを含むチップからなるチップセットとして実装することができる。プロセッサは、例えば、ユーザインタフェース、機器1150によって動作されるアプリケーション、および装置1150によるワイヤレス通信の制御など、機器1150の他の構成要素の連携をもたらし得る。
【０１２５】
プロセッサ1152は、制御インタフェース1158およびディスプレイ1154に結合されたディスプレイインタフェース1156によりユーザと通信することができる。ディスプレイ1154は、例えば、TFT(薄膜トランジスタ液晶ディスプレイ)ディスプレイまたはOLED(有機発光ダイオード)ディスプレイ、あるいは他の適切なディスプレイ技術でよい。ディスプレイインタフェース1156は、ユーザにグラフィックおよび他の情報を提示するようにディスプレイ1154を駆動する適切な回路構成を備え得る。制御インタフェース1158は、ユーザからコマンドを受信し、プロセッサ1152への送信用に変換することができる。さらに、他の装置との機器1150の近隣エリアの通信を可能にするように、プロセッサ1152と通信する外部インタフェース1162を提供することができる。外部インタフェース1162は、例えば、一部の実装形態では有線通信を、または他の実装形態では無線通信を提供することができ、多数のインタフェースを用いることもできる。
【０１２６】
メモリ1164は、コンピュータ機器1150内で情報を格納する。メモリ1164は、１つのコンピュータ読み取り可能な媒体または複数の媒体、１つの揮発性メモリユニットまたは複数のユニット、あるいは１つの不揮発性メモリユニットまたは複数のユニットのうちの１つまたは複数として実装することができる。拡張メモリ1174を提供し、例えば、SIMM(シングルインラインメモリモジュール)カードインタフェースを含み得る拡張インタフェース1172を介して機器1150に接続することもできる。このような拡張メモリ1174は、機器1150に拡張記憶空間を提供することができ、機器1150用のアプリケーションまたは他の情報を格納することもできる。具体的には、拡張メモリ1174は、上述した処理を遂行し、または補うための命令を含んでよく、安全な情報も含んでよい。したがって、例えば、拡張メモリ1174は、機器1150用のセキュリティモジュールとして提供することができ、機器1150の安全な使用を許可する命令を備えてプログラミングすることができる。さらに、SIMMカードを介して、付加情報とともに、ハッキング不可能なやり方でSIMMカード上に識別情報を置くなど、安全なアプリケーションを提供することができる。
【０１２７】
メモリは、例えば、後で論じるようにフラッシュメモリおよび／またはNVRAMメモリを含み得る。一実装形態では、コンピュータプログラム製品が、情報担体として有形に実現される。コンピュータプログラム製品は、実行されると上述したような１つまたは複数の方法を実行する命令を含む。情報担体は、メモリ1164、拡張メモリ1174、プロセッサ1152上のメモリなどのコンピュータまたはマシン読み取り可能な媒体、あるいは、例えば送受信器1168または外部インタフェース1162を介して受信することができる伝播信号である。
【０１２８】
機器1150は、必要な場合はデジタル信号処理回路を含み得る通信インタフェース1166を介して無線で通信することができる。通信インタフェース1166は、それ以外のものの中でも特に、GSM(Global System for Mobile Communications)音声コール、SMS(Short Message Service)、EMS(Electronic Message System)、またはMMS(Multimedia Messaging Service)メッセージ通信、CDMA(Code Division Multiple Access)、TDMA(Time Division Multiple Access)、PDC(Personal Digital Cellular)、WCDMA(Wideband Code Division Multiple Access)、CDMA2000、またはGPRS(General Packet Radio Service)など、様々なモードまたはプロトコルでの通信を可能にし得る。このような通信は、例えば、無線周波数送受信器1168を介して起こり得る。さらに、近距離通信は、ブルートゥース(登録商標)、WiFi、または他のこのようなトランシーバ(図示せず)を用いるなどして起こり得る。さらに、GPS(全地球測位システム)受信機モジュール1170は、機器1150上で動作するアプリケーションによって必要に応じて使うことができる追加ナビゲーションおよび位置関連の無線データを機器1150に提供することができる。
【０１２９】
機器1150は、ユーザから発話情報を受信し使用可能なデジタル情報に変換することができるオーディオコーデック1160を使って、音声によって通信することもできる。オーディオコーデック1160はまた、例えば機器1150のハンドセット内のスピーカなどにより、ユーザ向けに可聴音を生成することができる。このような音は、音声通話からの音を含んでよく、録音された音(例えば、音声メッセージ、音楽ファイルなど)を含んでよく、機器1150上で動作するアプリケーションによって生成された音も含んでよい。
【０１３０】
コンピュータ機器1150は、図に示すように、いく通りかの形で実装することができる。例えば、携帯電話1180として実装することができる。スマートフォン1182、携帯情報端末、または他の同様の携帯機器の一部として実装することもできる。
【０１３１】
本明細書に記載したシステムおよび技術の様々な実装形態は、デジタル電子回路、集積回路、特殊設計された広告サーバのASIC(特定用途向け集積回路)、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはその組合せにおいて実現することができる。こうした様々な実装形態は、記憶システム、少なくとも１つの入力装置、および少なくとも１つの出力装置との間でデータおよび命令を受信し、データおよび命令を送信するように結合された、特殊でも汎用でもよい少なくとも１つのプログラム可能プロセッサを含むプログラム可能システム上で実行可能および／または解釈可能な１つまたは複数のコンピュータプログラムでの実装を含み得る。
【０１３２】
こうしたコンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーションまたはコードとしても知られる)は、プログラム可能プロセッサ用のマシン命令を含み、高レベルの手続き型プログラミング言語および／またはオブジェクト指向プログラミング言語で、ならびに／あるいはアセンブリ言語／マシン言語で実装することができる。本明細書で使用する「マシン読み取り可能な媒体」「コンピュータ読み取り可能な媒体」という用語は、マシン読み取り可能な信号としてマシン命令を受信するマシン読み取り可能な媒体を含む、プログラム可能プロセッサにマシン命令および／またはデータを提供するのに使われるどのコンピュータプログラム製品、機器および／または装置(例えば、磁気ディスク、光ディスク、メモリ、プログラマブル論理デバイス(PLD))も指す。「マシン読み取り可能な信号」という用語は、プログラム可能プロセッサにマシン命令および／またはデータを提供するのに使われるどの信号も指す。
【０１３３】
ユーザとの対話を可能にするために、本明細書に記載したシステムおよび技術は、ユーザに情報を表示する表示装置(例えば、CRT(陰極線管)またはLCD(液晶ディスプレイ)モニタ)と、ユーザがコンピュータに入力を与えるためのキーボードおよびポインティングデバイス(例えば、マウスやトラックボール)とを有するコンピュータ上に実装することができる。ユーザとの対話を可能にするために、他の種類の装置も同様に使うことができる。例えば、ユーザに提供されるフィードバックは、どの形の感覚フィードバック(例えば、視覚フィードバック、聴覚フィードバック、および触覚フィードバック)でもよく、ユーザからの入力は、音響、発話、または触覚入力を含む、どの形でも受信することができる。
【０１３４】
本明細書に記載したシステムおよび技術は、バックエンド構成要素(例えば、データサーバとして)を含む、またはミドルウェア構成要素(例えば、アプリケーションサーバ)を含む、またはフロントエンド構成要素(例えば、本明細書に記載したシステムおよび技術の実装形態とユーザが対話できるためのグラフィカルユーザインタフェースまたはウェブブラウザを有するクライアントコンピュータ)を含むコンピュータシステム、あるいはこのようなバックエンド、ミドルウェア、またはフロントエンド構成要素のどの組合せにおいても実装することができる。システムの構成要素は、どの形または媒体のデジタルデータ通信(例えば、通信ネットワーク)によっても相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)、広域ネットワーク(「WAN」)、およびインターネットを含む。
【０１３５】
コンピュータシステムは、クライアントおよびサーバを含み得る。クライアントおよびサーバは概して、互いとは遠隔にあり、通常、通信ネットワークを介して対話する。クライアントとサーバの関係は、それぞれのコンピュータ上で動作し互いとのクライアント-サーバ関係を有するコンピュータプログラムにより起こる。
【０１３６】
いくつかの実施形態について記載した。それにも関わらず、様々な変更を行うことができることが理解されよう。例えば、上述したフローの様々な形は、ステップを並べ替えて、追加して、または省いて用いることができる。また、コンテンツ配布システムおよび方法のいくつかのアプリケーションを記載したが、他の多数のアプリケーションが企図されることを理解されたい。さらに、実施形態の多くは、リアルタイムで動的に作成された広告との関係で記載したが、他のコンテンツ配布を他の様々な形で提供することもできる。したがって、他の実施形態は、添付の請求項の範囲内である。
【符号の説明】
【０１３７】
200  ・・・  システム
202  ・・・  クライアント装置
204  ・・・  サーバ
206、208  ・・・  ネットワーク
210  ・・・  移植可能コードサーバ
212  ・・・  地理関連データサーバ
214  ・・・  サーバ
300  ・・・  システム
304  ・・・  ネットワーク
302  ・・・  クライアント装置
306  ・・・  広告サーバ
308  ・・・  地図サーバ
310  ・・・  データサーバ
312、314、316  ・・・  モジュール
318  ・・・  モジュールルータ
318a、322a  ・・・  パケタイザ
322  ・・・  地図ルータ
324  ・・・  地図アプリケーション
1000  ・・・  システム
1010  ・・・  ホストサーバシステム
1012  ・・・  コンテナサーバ
1014  ・・・  モジュールサーバ
1016  ・・・  仕様サーバ
1018  ・・・  バックエンドサーバ
1020  ・・・  データベースシステム
1022  ・・・  ユーザシステム
1024  ・・・  遠隔項目サーバ
1026  ・・・  ネットワーク
1028  ・・・  分析モジュール
1030  ・・・  モジュール開発者システム
1031  ・・・  地図サーバ
1032  ・・・  モジュール作成サーバ
1034  ・・・  配信サーバ
1036  ・・・  広告サーバ
1038  ・・・  記事受信サーバ
【図１Ｂ】
2010530570.tif 000003
【図２】
2010530570.tif 000004
【図３】
2010530570.tif 000005
【図４Ａ】
2010530570.tif 000006
【図４Ｂ】
2010530570.tif 000007
【図５Ａ】
2010530570.tif 000008
【図５Ｂ】
2010530570.tif 000009
【図６】
2010530570.tif 000010
【図７】
2010530570.tif 000011
【図８】
2010530570.tif 000012
【図９】
2010530570.tif 000013
【図１０】
2010530570.tif 000014
【図１１】
2010530570.tif 000015
【図１Ａ】
2010530570.tif 000016
【国際調査報告】
2010530570.tif 000017
2010530570.tif 000018