JP5449146B2 - 地図ガジェット（ｍａｐｇａｄｇｅｔｓ） - Google Patents

Description

本文書は、ガジェット(gadgets)などの移植可能プログラムモジュール(Portable program modules)を、地図表示システムなどの地理情報システムに組み込む機構および技術について論じる。

インターネットユーザによって行われる多くの検索には、いくつかの地理的な構成要素が関わる。検索自体が、地図および車での行き方が探索される対象である住所などの地理情報を含み得る。検索は、物理的な場所を有する店舗の名称を検索が含むときなどに、地理的結果を暗黙に要求する場合がある。Googleマップなどの情報プロバイダサービスによって、このような検索を受信し、かつ/またはその結果を配布することができる。

アプリケーションプログラミングインタフェース(API)により、サードパーティは、地理情報プロバイダサービスの機能性を拡張することができるようになる。たとえば、あるAPIを使って、プログラマは、アパートおよび家屋一覧にあるデータを受け取っており、そうした一覧を表示するアプリケーションを、Googleマップ(たとえば、http://www.housingmaps.com/)などで地図上に作成してある。

本文書は、Googleマップによって提供されるような地図との対話を可能にするのに利用することができる機構および技術について記載する。たとえば、ガジェットの形をした移植可能プログラムモジュールは、地図ページと統合することができ、多数の異なるモジュールにあるデータを表示する地図の展開を許可することができ、本質的に、マッシュアップのマッシュアップを可能にする。本文書は、異なるモジュールの間で通信を行う機構および技術についても記載するが、これらは、各モジュールが普通は他のモジュールと自由に通信するとは想定されないiframe（インラインフレーム）または他の構造内で実装することができる。たとえば、多数のガジェットは、地図に関連づけることができ、こうした技術を用いて地図および互いと通信することができる。

一実装形態では、コンピュータ実施方法が開示される。この方法は、第1のドメイン上の地図表示アプリケーションにある情報をウェブページ上に表示すること、第2のドメインにある1つまたは複数の移植可能プログラムモジュールをウェブページ上に表示すること、および1つまたは複数の移植可能プログラムモジュールからのアクションに基づいて地図表示アプリケーション上に表示を生じることを含む。移植可能プログラムモジュールは、1つまたは複数のiframe中に生成することができる。本方法は、地図表示アプリケーションで入力を受信すること、および入力に関する情報を移植可能プログラムモジュールの1つまたは複数に伝達することも含み得る。地図表示アプリケーション上での表示は、地図上に置かれた1つまたは複数のオブジェクトを含み得る。

一態様では、本方法は、検索リクエストに応答してウェブページ上に表示するべきマップデータを識別することも含み得る。本方法は、検索リクエストに応答して、1つまたは複数の移植可能プログラムモジュールを識別することも含み得る。さらに、本方法は、個人用ページ情報を格納するユーザアカウントを参照することによって、1つまたは複数の移植可能プログラムモジュールを識別することをさらに含み得る。さらに別の態様では、本方法は、地理的関連情報用データサーバを照会すること、および地理的関連情報に関連づけられたデータを、データサーバとは別個の地図サーバに提出することをさらに含む。さらに、本方法は、異なるドメインに関連づけられた2つの地図表示関連移植可能プログラムモジュールを表示すること、および移植可能プログラムモジュールそれぞれから地図表示アプリケーションにデータを伝達することを含み得る。

別の実装形態では、実行されるとコンピュータ上でアクションを起こす命令を、有形に記録してある1つまたは複数のコンピュータ可読媒体が開示される。アクションは、第1のドメイン上の地図表示アプリケーションにある情報をウェブページ上に表示すること、第2のドメインにある1つまたは複数の移植可能プログラムモジュールをウェブページ上に表示すること、および1つまたは複数の移植可能プログラムモジュールからのアクションに基づいて、地図表示アプリケーション上に表示を生じることを含む。アクションは、地図表示アプリケーションで入力を受信すること、および入力に関する情報を移植可能プログラムモジュールの1つまたは複数に伝達することをさらに含み得る。さらに、アクションは、検索リクエストに応答してウェブページ上に表示するべきマップデータを識別すること、および検索リクエストに応答して1つまたは複数の移植可能プログラムモジュールを識別することを含み得る。

一態様では、移植可能プログラムモジュールは、サードパーティサーバにある地理関連データにアクセスし、地理関連データに関連づけられた情報を、ジオコーディング(geo-coding)のために地図サーバに供給する。さらに、アクションは、ユーザにとって利用可能な移植可能プログラムモジュールのリストを表示すること、移植可能プログラムモジュールのうち1つまたは複数の選択を受信すること、および受信した選択に応答して、選択された移植可能プログラムモジュールを表示することをさらに含み得る。

別の実装形態では、コンピュータ実施システムが開示される。このシステムは、地図ドメインにある地図アプリケーション、地図ドメインとは異なるドメインにある第1の移植可能プログラムモジュール、ならびに地図アプリケーションと移植可能プログラムモジュールとの間の通信を許可するように構成された通信モジュールを含み、地図アプリケーションおよび移植可能プログラムモジュールは、共通ウェブページ上にコンテンツを表示するように構成される。本システムは、第1の移植可能プログラムモジュールとは独立に選択可能であり、地図アプリケーションと通信するように、かつ第1の移植可能プログラムモジュールにあるコンテンツとともに、地図上でのコンテンツの表示を提供するように構成された第2の移植可能プログラムモジュールも備え得る。第2の移植可能プログラムモジュールは、第1の移植可能プログラムモジュールのドメインとは異なるドメインにあるものでよい。

一態様では、通信モジュールは、地図アプリケーションとの間で送られる多数のデータパケットを単一パッケージにパッケージ化するように構成される。さらに、第1の移植可能プログラムモジュールは、データサーバと通信して地理関連データを取得するように、かつ地図サーバまたは地図アプリケーションと通信して地理関連データを地理相関データに変換するように構成することができる。

さらに別の実装形態では、コンピュータ実施システムは、地図ドメインにある地図アプリケーション、地図ドメインとは異なるドメインにある第1の移植可能プログラムモジュール、ならびに地図アプリケーションと第1の移植可能プログラムモジュールとの間で通信を行う手段を含み、地図アプリケーションおよび移植可能プログラムモジュールは、共通ウェブページ上にコンテンツを表示するように構成される。

1つまたは複数の実施形態の詳細については、添付の図面および以下の説明において記載する。他の特徴、目的、および利点が、こうした説明および図面から、ならびに請求項から明らかになるであろう。

2つの移植可能プログラムモジュールと対話する地図表示アプリケーションの表示例を示す図である。 図1Aの表示にある項目を示す図である。 地図表示アプリケーションを2つの移植可能プログラムモジュールと連携させるシステムおよびプロセスを示す概念図である。 移植可能プログラムモジュールを地図表示システムと統合するシステム例を示す概略図である。 マッピングベースの移植可能プログラムモジュールを動作させるプロセスを示すフローチャートである。 マッピングベースの移植可能プログラムモジュールを動作させるプロセスを示すフローチャートである。 移植可能プログラムモジュールおよび地図表示アプリケーションの動作を連携させるプロセスを示すスイムレーン図である。 移植可能プログラムモジュールおよび地図表示アプリケーションの動作を連携させるプロセスを示すスイムレーン図である。 ウェブブラウザによって表示されるドメインの間の通信を連携させるプロセスを示すフローチャートである。 ブラウザが表示したウェブページ上のドメインの間でデータを送るプロセスを示すスイムレーン図である。 2つの移植可能プログラムモジュールと連携して動作する地図アプリケーションの例を示すスクリーンショットである。 いくつかの移植可能プログラムモジュールおよび地図表示アプリケーションを含むコンテナドキュメントのレイアウト例を示す図である。 地図、広告、および他の項目を動的に生成するシステム例を示す概略図である。 本明細書に記載する技術を実装するのに使うことができるコンピュータ装置およびモバイルコンピュータ装置の例を示す図である。

様々な図面中の同じ参照記号は、同じ要素を示す。

図1Aは、2つの移植可能プログラムモジュールと対話する地図表示アプリケーションの表示例100である。概して、表示100は、様々なスキー場に関する予想最高気温および積雪(snow base)を組み合わせて示す。この例では、地図表示アプリケーションと対話するのでここでは「マプレット」と呼ばれる、予報図を示すための公開気象データにアクセスするガジェットを、あるサードパーティが開発している。別のサードパーティは、他の公開ソースにある積雪情報にアクセスするマプレットを開発している。この例では、このような統合表示がない状態で、ユーザは、たとえば、十分な積雪のある多数のロッジを識別し、次いでこうしたロッジを記憶し、こうしたロッジの気温を検索するために、2つのアプリケーションを別々に操作することを要求されている場合がある。この例では、対照的に、Googleマップなどの地図表示アプリケーションにアクセスするマッシュアップによって提供されている可能性がある各情報は、組み合わされて提供される。さらに、組合せ情報は、地図ページ自体の上に表示され、従ってそのページによって管理される。

いくつかの実装形態では、このような手法は、以下の利点の1つまたは複数を有し得る。様々なモジュールは、地図表示アプリケーションに関連づけることができ、地図表示アプリケーションに関連づけられたウェブページを訪問するユーザによってアクセスすることができる。このようなユーザは、Google個人用ホームページ、すなわちiGoogleのユーザが、個人用ページ上で使用するための一般モジュールを識別することができるように、モジュールを検索し、ユーザが特に欲求していることに対処するモジュールを選択することができる。地図表示モジュールは、地図に関連しない他のモジュールとともに、個人用ホームページに埋め込むこともできる。さらに、このような地図表示モジュールは、検索クエリに対する結果として自動的に提供することができ、その場合、検索結果中に示されるコントロールを選択することにより、検索結果に適したデータを含む地図が表示される。

さらに、このようなモジュールは、トランザクション処理能力を含み得る。たとえば、ホテル検索は、地図上に適切なホテル検索結果を表示するモジュールに向けられた検索結果を生じ得る。ある特定のホテルを地図上で選択することにより、ホテルについての情報(たとえば、部屋代および空き状況)をモジュールに渡すことができ、その結果ユーザはモジュールを介して部屋を予約することができる。

多数のモジュールの出力を、ユーザによって選択された様々なやり方で1つの地図上に合成することもできる。このようにして、ユーザは、自分にとって重要な多数のデータセットを単一グラフィック表現に合成することができる。このような合成では、店舗検索、行き方、個人アドレス帳、KML(キーホールマークアップ言語)ファイル、乗換え情報など、地理関連コンテンツの様々なソース、および他のこのような情報ソースを利用することができる。このような合成は、マッシュアップのマッシュアップと呼ぶことができる。

図1Aを参照すると、表示100は、地図表示アプリケーションにある地図112の表示に影響するガジェットまたはマプレットとして実装される2つの移植可能プログラムモジュール106、108の形をした、マッシュアップのマッシュアップを示す。表示100は、地理関連の検索クエリをユーザが記入することができる検索コントロール102によって概括的に制御することができる。「地図を検索」タブ102aは、コントロール102に関して選択されたものとして示してあり、その結果、検索クエリが、一般的な地理的場所情報のコーパスに加えられることになる。「お店を探す」タブ102bを選択してもよく、このケースでは、提出されたクエリは、店舗名のコーパスと突き合わされることになり、結果は、地図112上の店舗と合致する特定の場所を含むことになる。「行き方を調べる」タブ102cは、選択されると、よく知られたやり方で、ある場所から別の場所までの、たとえばユーザプロファイルに格納されたデフォルトの場所から記入した場所までの行き方を生じさせる。

地図表示コントロールエリアは、タブエリア104、「最高気温」マプレットの形のモジュール106、「ベースライン」マプレットの形のモジュール108、および「距離測定」ガジェットの形の折りたたみモジュール110を含む。タブエリア104は、選択されると、検索クエリに対する地理的結果を表示させる検索結果タブを含む。さらに、タブエリア104は、選択されると、いくつかのユーザ関連地図を表示させるマイマップタブを含む。たとえば、ユーザが、自分の出身地周辺のエリアを示す地図をもっている場合がある。さらに、ユーザは、あるエリア内のすべてのWhite Castleというレストランを示す地図を保存している場合があり、この場合、適切なエリアを識別する郵便番号または他の類似情報を受け取るために、テキスト記入ボックス(図示せず)を設ければよい(または、エリアは、検索コントロール102に記入された情報から受け取ることができる)。マイマップ表示は、結果として、ユーザによって、地図とともに地図に関連づけられているマプレットの表示を生じ得る。

マプレットタブは、現在選択されているものとしてタブエリア104内に示してある。マプレットタブは、移植可能プログラムモジュールを、たとえばマプレットの形で実装する1つまたは複数のiframe（inline frame; インラインフレーム）を含み得るフレームを提示する。モジュール106は、対象となるあるエリアに渡る、たとえば米国全土に渡る予想最高気温を含む気象情報のデータベースにアクセスする拡張モジュールである。気温は地理相関なので、地図112などの地図上に表示してよい。モジュール106によって生成されている2つのコントロールを示してあり、こうしたコントロールを選択すると、当日または翌日の気温を取り出させる。コントロールを選択することにより、後でより詳しく説明するように、データソースから気温データを取り出させ、次いで地図112用のコードを生成する地図サーバに提出させることができる。

モジュール108は、「ベースライン」ガジェットを示し、このガジェットは、様々なスキー場での雪の「ベース」の厚さについての情報を取得する。モジュール108は次いで、この情報を、地図112に関連づけられたエンジンに渡し、そうすることによって、ベース情報は、地図112上の適切な地理的場所に図示される。さらに、モジュール110を圧縮された形で示してあり、このモジュールは、もしユーザがモジュールを使いたいときには拡張することができる。モジュール110は、「距離測定」と名付けられ、呼び出されると、地図112上でのユーザの地点選択を検知するように、地図112と対話することができ、次いで、選択された2地点の間の距離を計算することができる。他のモジュールを提供してもよく、こうしたモジュールは、ユーザがiGoogleから標準ガジェットにアクセスすることができるように、モジュールの中心情報局からユーザによってアクセスすることができる。

地図112は、他の画像構成要素を使用することによって生成された結果を示す。地図112は、ユーザ選択に従って位置決めされ、サイズが決められる標準地図を含み、たとえばユーザによって検索コントロール102に記入された郵便番号を中心とする。地図112の一部として重ねられるのは、気温114およびベースインジケータ116である。気温114は、モジュール106によってmaps.google.comなどの地図表示アプリケーションに渡される多数の異なる地理相関気温の1つでよい。同様に、ベースインジケータ116は、モジュール108によって地図表示アプリケーションに渡される多数の異なる地理相関インジケータの1つでよい。地図表示アプリケーションを、モジュール106およびモジュール108両方からの提出に協力して応答させることによって、ユーザには、それ以外の方法では単一簡易表示では利用可能でなかった可能性のある2通りの情報を提示することができる。

図1Bは、図1Aの表示にある項目を、図1Aの実際の表示の下にある汎用オブジェクトとして示す。モジュールおよび地図出力を示す、ウェブページのある特定の実装形態用の様々な要素を、分かりやすくするためにここに示してあるが、ひと揃いの特定の要素は、限定的であることを意味しているわけではない。モジュールは、地図HTMLページ120に埋め込まれたiframe内部の、ここではマプレットスタブとして参照されるコードとして実装される。たとえば、マプレットスタブ122は、図1Aのコントロール106を実装するコードを表し得る。同様に、マプレットスタブ123は、図1Aのコントロール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を介して起こり得る。

図2は、地図表示アプリケーションを2つの移植可能プログラムモジュールと連携させるシステム200およびプロセスの概念図を示す。図示した例において、システム200は、クライアント装置202と、クライアント装置202の動作用データを提供するいくつかのサーバ204、210、212、214とを備える。概して、システム200は、地図表示アプリケーションと対話するための移植可能プログラムモジュール(たとえば、ガジェット/マプレット)を使用して、図1Aに提示されるような機能性を提供するように構成される。その結果、クライアント装置202のユーザは、地図に関連づけられたカスタム結果を与える一定のモジュールを選ぶことができ、次いで、地図または多数の地図上での表示用にフォーマットされたデータを見ることができる。

クライアント装置202には、ウェブブラウザまたは他のインターネット関連のアプリケーションを設けてよい。ウェブブラウザは、マークアップコードおよびそれに対してリクエストを行うことができる様々なサーバから取得するJava（登録商標）スクリプトコードなど、他の同様のコードを実行することができる。たとえば、移植可能コードサーバ210は、クライアント装置202のユーザに関連づけられたモジュール用コードを含むマークアップコードをブラウザに提供することができる。たとえば、ユーザは、移植可能コードサーバ210に関連づけられたアカウントをもつことができ、コードサーバ210によって(たとえば、サーバ側情報により、またはクッキーなどのクライアント側情報により)識別することができ、ユーザが予め構成しておいたマイマップのリストを与えられ得る。ユーザは次いで、地図の1つを選択してよく、自身のブラウザ上での実行用に配布された地図にコードを関連づけさせればよい。

たとえば、クライアント装置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実装形態においてJava（登録商標）スクリプトを用いることによって、修正し、またはコンテナドキュメント(たとえば、周辺ページ)をリフレッシュすることなくリフレッシュすることもできる。たとえば、ドキュメントのDOMツリーの編集により、同様の表示を生じることができる。

クライアント装置202によって取得された移植可能プログラムモジュールは、コンテナドキュメント、移植可能コードサーバ、および他のサーバ204、212、214と通信することができる。地図サーバ204は、クライアント装置202からリクエストを受信し、図表による地理情報を、概して、2D地図、3D地図、または他の形の地図でよい地図の形で提供する。さらに、地図サーバ204は、クライアント装置202から、または他のソースから地理関連データを受信することができ、この情報を地図上の場所と相関させ、クライアント装置202が地図の上にデータを表示できるように情報を戻すことができる。クライアント装置202上で実行する(たとえば、移植可能コードサーバ210によって提供される)コードと地図サーバ204との間の通信は、後でより詳しく説明するように、公表されたアプリケーションプログラミングインタフェース(API)に従って起こる得る。

広告サーバ214は、クライアント装置202上で動作するコードからリクエストを受信することもでき、こうしたリクエストに向けられた広告を生成することもできる。たとえば、ある特定のエリア内の情報を求めるリクエストは、そのエリアの地図の生成に加えて、そのエリアに関連づけられた広告を広告サーバ214に生成させることができる。こうした広告は、リクエストに関する単なる地理以上のものを対象としてもよい。たとえば、リクエストが「ドーナツ02128」を求めるものである場合、広告は、「ドーナツ」、「朝食」、または「食べ物」のような概念を対象としてよく、地理は、ボストンエリアを対象とし得る。

生成された広告は、スクリーンのエッジ周辺にテキスト広告として提示してもよく、ユーザに提示される地図に埋め込んでもよい。広告が地図の中に提示される場合、その結果は、広告サーバ214によって地図サーバ204に、または適切な形式でクライアント202に直接送ることができる。その結果、ダンキンドーナツがシステムを通して広告することを選んだ場合、様々なダンキンドーナツ店のロゴを、検索結果の一部として地図上に示すことができる。

広告サーバ214、移植可能コードサーバ210、および地図サーバ204は、インターネットなどの中央ネットワーク206とは別個の共通ネットワーク208に付加されたものとして図2に示してある。ネットワーク208は、サーバ204、210、214がGoogleなどの単一情報プロバイダによって運営されることを示し得る。分かりやすくするために別々の個々のサーバとして示してあるが、ここで論じる様々なサービスは、色々なやり方で提供することができ、ただし地図表示サービスは概して、効率のために、広告サービスとは別個のサブシステムによって提供されることになり、移植可能コードの供与は、効率およびセキュリティ両方の目的のために(たとえば、サードパーティによって提出される移植可能プログラムモジュールが標準API経由以外の地図表示アプリケーションに容易に影響を与え得るように)、地図サービス用のドメインとは別個のドメイン上で行われ得る。

広告および地図と同じ組織からコードを供与するための移植可能コードサーバ210を示してある。ただし、様々な実装形態において、クライアント装置202は、コード、特に移植可能プログラムモジュール用のコードを、サードパーティ供給元から取得することができる。このような状況において、地図情報は、地図サーバ204から受信することができ、ユーザのウェブページの一部であるコードは、(たとえば、上で提示したiframe定義を用いて)移植可能プログラムモジュール中で実行されるべきコード向けの他の場所を指すことができる。コードの整合性をより容易に検証し保つことができるように、システム200は、地図表示アプリケーション(異なるドメインにあるものであったとしても)を供給する組織のみからの移植可能プログラムモジュールコードの使用を許可するように実装してもよい。

図2の文字つき矢印は、システム200内の構成要素によって実施される動作セットの例を示す。矢印Aで示すように、クライアント装置202は最初に、たとえばmaps.google.comにHTTPリクエストを向けることによって、地図サーバ204に対してウェブページを(たとえば、ユーザがマイマップリンクを選択することによって)リクエストする。ターゲット組織(この例では、Google社)は、このリクエストを地図サーバおよび他の1つまたは複数のサーバに与えればよい。たとえば、組織は、クライアント装置202上に格納されたクッキーを照会し、またはセッションIDをログインしているユーザと突き合わせるなどして、クライアント装置202のユーザを、組織の登録メンバとして識別することができる。組織は次いで、ユーザのリクエストを移植可能コードサーバ210に経路指定すればよく、サーバ210は、ユーザが1つまたは複数の移植可能プログラムモジュールを自身の個人用マップページまたは個人用ウェブページに関連づけさせていると判定することができる。地図サーバ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などの言語によって提供される様々な関数は、移植可能プログラムモジュールによって実装することもでき、したがって豊富な対話を可能にすることを理解されたい。

移植可能プログラムモジュールによって生じられる表示は、ユーザが結果と対話することを可能にする、ハイパーリンクなどのメタデータを含み得る。たとえば、地図上に一定の情報を表示するテキストは、それを選択すると項目に関連づけられたウェブページにユーザを導くハイパーリンクに関連づけることができる。さらに、地図の上に提供される項目を「浮かべる」と、結果として、従来のやり方で項目に関する付加情報の表示を生じ得る。

図3は、移植可能プログラムモジュールを地図表示システムと統合するシステム例300の概略図である。概して、システム300は、インターネットなどのネットワーク304を経由して、クライアント装置302上での地図の生成用データを提供するいくつかのサーバと通信するクライアント装置302を含む。ウェブブラウザによって生成されるウェブページの部分に関連づけられた異なるドメインの一部である、クライアント装置302における特定の構造について、より詳しく示してある。図示した例は、ブラウザにおける様々なドメインの間の通信を可能にする配置を示す。概して、このような通信は、あるソフトウェアによって他のソフトウェアに侵入し、または引き継ぐのに用いることができるドメイン間通信を防止するための様々な特徴をブラウザが含むので、推奨されず、困難である。

図3を参照すると、クライアント装置302は、緯度/経度の場所を推論するための情報に関連づけられたデータなど、地図表示アプリケーションに適用されるデータを取得するためのリクエストをデータサーバ310に提出することができる。さらに、クライアント装置302は、地図サーバ308にリクエストを提出することができ、クライアント装置302からのリクエストは、図2に関して示すようにして、広告サーバ306に経路指定してもよい。

地図表示関連ウェブページを生成するいくつかのソフトウェア構成要素を、クライアント装置302内に概念的に示す。こうした構成要素は、様々なページ部分、またはページを実装するコード部分である。こうした構成要素は、この例では、コンテナドキュメントを生成している構成要素と、コンテナドキュメントとともに表示される移植可能プログラムモジュールを含む構成要素との間のドメイン間通信を許可するように実装される。この特定の例では、コンテナドキュメントは、www.google.comなどの地図ページであり、移植可能プログラムモジュールは、ここでは、地図ページ上に生成され、表示される地図とともに対話するマプレットとして知られるガジェットである。

概して、通信は、アプリケーションからモジュールの1つまたは複数に、およびその逆方向に送られる情報用のリレーとして働く隠れiframeの使用により起こる。クライアント装置302内の各実線ボックスは、メインの地図ページ上のiframeを表し、破線ボックスは、地図アプリケーション324の状態を表す。モジュールの間の通信は概して、一時的接続を有しているリモートプロシージャコール(RPC)を使用し、ここで応答を期待するリクエストは、応答をそれによって受信することを期待する詳細(たとえば、ソースiframe、用いるべきリレーurl)を供給する。

地図ルータ322は、地図アプリケーション324との通信を管理し、モジュールルータ318は、様々なモジュールとの通信を管理する。メインウィンドウは、各ルータごとに1つのiframeを作成する。1つのルータ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にはそれぞれ、共通ドメインに送られる小型パケットを目標ルータの所でマージし、パケットを分割するための関連パケタイザ318a、322aを設けることができる。パケットは、様々なiframeによるリクエストにあるデータグループを含んでよく、どの特定の形をとる必要もない。ルータ318、322は、関連地図アプリケーション324からであっても、あるいは関連マプレット312〜316の1つまたは複数からであっても、パケットが届いたら受信する。受信したパケットは、多数のソースにある、またはそうしたソースに関するデータグループを含み得る。たとえば、モジュールルータ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である。

第2の(id 18をもつ)マーカの作成および同じ(id 1をもつ)地図への追加はしたがって、さらに2つの直列コマンド
101&33.87,153.05&http://some.domain.com/marker2.png
および
15&1&18
を伴うことになる。効率のために、パケタイザは、こうした4つのコマンドが立て続けに単一ドメインに入っていくことを観察することができる。その結果、パケタイザは、以下のような単一パケットを形成することができる。
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バイトに制限する。ルータは、第1の現格納パケットが届いてからの経過時間と、現格納パケットグループのサイズとを追跡することができ、いずれかのパラメータにおいて所定の値を超えたときにパケットグループの送付をトリガすることができる。

ルータは、いくつかの実装形態では、メッセージの順序づけが確実に保持されるようにすることもでき、たとえば、そうすることによって、マーカを作成するためのリクエストが、地図にマーカを追加するためのリクエストの前に処理される。隠れリレーiframe(ルータの間でパケットを送るのに使われる)は、document.body.appendChildをコールするJava（登録商標）スクリプトDOMを使ってHTMLドキュメントの本文に挿入することができ、順序づけを強制するのに用いることができる。また、順序づけは、各パケットをカウンタで明示的にタグ付けし、受信機の所で、パケットをカウンタ昇順で並べ替えることによって、(iframeがロードされる順序の入換えを許可することによって)パケット順の入換えを許可するブラウザ中で保持することができる。

その動作に関して、iframeは、iframeの適切なアクションを定義するライブラリに依拠し得る。たとえば、ルータは、応答確認、大型および小型パケットのマージおよび分割、ならびに他の同様のタスクを含む、ドメインの間の通信を扱うルータライブラリに依拠し得る。他のiframeは、APIを定義しコールバックおよびサービスハンドラなどのコンテキストを格納するクライアントライブラリに依拠し得る。

クライアントライブラリは、コールサービス、登録サービス、および初期化サービスを含む様々なサービスを提供し得る。コールサービスは、ルータを介して別のiframeにメッセージを送る。コールリクエストは、目標iframe ID、コールするべきサービスのサービスID(たとえば、地図へのオーバーレイ(たとえば、マーカ)の追加、地図上のある地点での情報ウィンドウのオープン、地図によるマプレットへのマウスクリックなどのイベントの報告、ジオコーディング(住所文字列の緯度および経度への変換)、地図上の2つ以上の地点の間の行き方のリクエストなどのより高度なサービス)用のパラメータ、サービスによって要求されるあらゆる引数、ならびにリプライに対するコールバックが起こるべきかどうかというインジケータを含み得る。

マプレット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にいくつかのやり方で連絡することができる。第1に、クロスドメイン通信技術(クロスサイトスクリプティングリクエストなど)を用いて、このようなサーバ310にリクエストを直接行うことができる。第2に、Google Gadgets APIの一部としてiGoogleによって提供されるGoogleプロキシサーバなどのプロキシサーバを使用することができる。第3に、一部の事例(地図ジオコーディングAPIを使うときなど)では、包含ページ(地図アプリケーション)が、それ自体の代わりにサービス(Googleサービスなど)へのリクエストを行うことをリクエストすることができる。

データサーバ310は次いで、このようなすべての湖の一覧を、各湖で釣り上げられたオオクチバスについての情報とともに戻すことができる。この情報を受信すると、地図アプリケーション324は、情報を地図サーバ308にフォワードさせることができ、サーバ308は、湖名の形をした場所に関する情報を分析し、その情報を緯度/経度ペアまたは他の具体的場所データに変換することを試みればよい。サーバ308は次いで、湖の場所に関する情報をクライアント装置302に戻すことができる。上記第1の方法では、マプレットは、サーバからデータを直接受信する。上記第2の方法では、リクエストおよび応答は、Google Gadgets APIの一部としてGoogleによって提供されるhttp://gmodules.com/ig/proxyサービスなどのサービスを通る。Googleプロキシサーバなどのプロキシサーバは、リクエストをリモートサーバにフォワードし、リモートサーバはGoogleプロキシサーバに応答し、プロキシサーバは、マプレットに応答をフォワードする。上記第3の方法では、ホストページ(地図アプリケーション)は、リモートサーバにリクエストを行い、リモートサーバから応答を受信し、次いでこの応答を、ドメイン間通信システムを経由してマプレットに送る。

モジュールA312は次いで、各湖ごとにマーカをつけ、識別された各湖の所にマーカを置くコマンドを生成することができる。たとえば、10個の湖がデータサーバ310によって戻された場合、20個のコマンドが生成可能であり、モジュールルータ318に与えることができる。パケタイザは、こうしたパケットをすべて合わせて、より大きなパケットにマージすることができ、パケットの配布のためにシステム内で容認可能な想定待ち時間に関連づけられた期間だけ待機すればよい。その期間に達すると、モジュールルータ318は、ドメインを越えて地図ルータ322にパケットを送り、ルータ322のパケタイザが次いで、(ある特定のモジュールによって送られたデータグループである)内部パケットを分析し、内部パケットを実行用に地図アプリケーション324に供給し、そうすることによって、マーカは、地図の上に適切に置かれる。同様にして、他のオブジェクトを地図に追加してもよい。

プロセスの一部として、地図アプリケーション324は、地図の上または周辺に広告を配置させることもできる。たとえば、地図サーバ308によって生成された場所情報およびデータサーバ310に対するリクエスト中の他の情報(たとえば、「オオクチバス」)を用いて、広告サーバは、特定の場所および集められた他の情報に適した広告を照会することができる。その結果、広告サーバ306は、場所特有ではなく、受信すると地図アプリケーションによって、表示地図の上に表示される広告専用のエリアなどに表示することができる1つまたは複数の広告を戻すことができる。広告サーバ306は、広告主のために地図上にマーカおよび他の詳細な情報を地図アプリケーション324に生成させる、1つまたは複数の場所特有の広告を戻すこともできる。

ドメイン間通信などにおける、記載したこうした特定の通信技術は、例示目的で挙げてある。適切な他の技術を用いてもよい。いくつかの実装形態では、記載した技術は、異なるドメインからのオブジェクトが、誠意のない当事者から的確に定義され保護されるやり方で互いと通信することを許可するための効率的であり好都合な機構を可能にし得る。

図4A、4Bは、マッピングベースの移植可能プログラムモジュールを動作させるプロセスのフローチャートである。図4Aは概して、地図アプリケーションと対話する1つまたは複数のサーバによって実施することができる動作を示す。ボックス402で、サーバは最初に、ある特定のURLに向けられたGETコマンドを受信することができ、マプレット用の1つまたは複数のiframeを形成するコードを含み、iframe中でマプレットを動作させる、そのURLに関連づけられたマークアップコードを提供することができる。リクエストされたコードは最初は、コードが別のドメインを形成することを要求するiframeを生成するコードを含み得る、第1のドメインなどにある、メインページ用のコードでよい。このコードは、実行される際、そのデフォルトのパラメータを使って、ユーザのデフォルトまたは自宅の場所周辺を中心とした地図の広域ビューを示すなど、デフォルトのパラメータに関連づけられた地図データをリクエストすることができる。

一定時間経過後、ユーザは、マプレットに新規パラメータを与えている場合があり、新規パラメータがクライアントによって提出されることをリクエストしている場合がある。このようなリクエストにより、メッセージは、ある地理的エリアにおける賃貸不動産の価格を追跡するサーバなどのサードパーティサーバ(図示せず)に送られる。サードパーティサーバからの応答は、クライアント装置によって処理し、かつ/または地図サーバ用のAPIと互換性のある形式で地図サーバに経路指定することができる(ボックス406)。地図サーバは次いで、受信した住所を緯度/経度座標に変換することなどによって、受信した情報を地理的に相関させることができ、リクエストに関する地図データを供与することができる。たとえば、地図サーバは、適切なエリア内で適切なズームレベルで地図用のタイルを送信することができ、地図の上に表示されるべきオブジェクトに関する緯度/経度情報を戻すこともできる。

図4Bは、図4Aのプロセスと同様のプロセス420を示すが、クライアント装置の視点から示す。ボックス422で、クライアント装置は最初に、地図を指す結果を戻す(かつ結果を選択する)検索エンジンによって、または他の適切な機構によって、ユーザがmaps.google.com用のurlを選択することなどによって、地図ページをリクエストする。地図サーバは次いで、リクエストに応答してコードを送信することになり、さらに、(たとえば、特定のユーザに対して個人用設定されたコードにマプレットを追加することによって)コードのリクエスト側がサービスの登録ユーザであると判定した場合は、コードの配布法に影響を与え得る。ボックス424で、クライアント装置は、コードを受信しており、コードを実行して、米国の地図を示す表示などの一般表示、およびマプレット中に提供される最小限の情報を有する1つまたは複数のマプレットを生成することができる。マプレット用コードは、たとえば、iframe中に実装されると、付加情報またはコードを他のサーバからページに取り出させる。

ボックス426で、ユーザは、ドロップダウンリストから値を選択したり、空白フィールドに特定の値を記入したりすることによって、マプレットの1つに対してパラメータを与える。ユーザがパラメータを提出することを選ぶと、クライアント装置は、サードパーティデータプロバイダに対してマプレットに関するデータ(たとえば、クレイグスリスト一覧)をリクエストすることができる。サードパーティデータが配布されると、クライアント装置は次いで、結果用の地理相関データを生成するための翻訳用に地図サーバに(おそらく編集し、かつ/またはフォーマットし直した後で)データを提出する(ボックス430)ことができる。地図サーバがリクエストを処理した後、クライアント装置は、地図データを受信し(ボックス432)、地図アプリケーションを使って地図上に地図データ(地図の別のエリア用の新規タイルも含み得る)を表示する(ボックス434)ことができる。

図5A、5Bは、移植可能プログラムモジュールおよび地図表示アプリケーションの動作を連携させるプロセスのスイムレーン図である。概して、図5Aに示すプロセス500は、ある特定の地図アプリケーションに関連づけられた2通りのマプレットへのユーザからの提出に応答して地図データを提供する簡易プロセスを示し、図5Bに示すプロセス530は、マプレットの選択およびユーザの個人用ページへの追加を示す。

図5Aを参照すると、ボックス502で、ユーザは最初に、地図関連ページにアクセスし、マークアップコードを含むサーバがコードを送信し(ボックス504)、特定の地図データを含むサーバが、地図関連ライブラリおよびアプリケーションにおける初期表示用の一般地図を含み得るそのデータを配布する(ボックス506)。コードおよび地図情報の準備は、単一サーバによって生成することができる。コードサーバおよび/または地図サーバによって提供される一般情報は、ユーザによって使われる可能性のあるマプレットのリストを含み得る。

一定の状況において、識別されたマプレットは、コンテキスト依存でよい。たとえば、地図アプリケーションの準備は、検索リクエストに応答して起きている場合があり、検索リクエスト中の用語の分析は、地図に関して一定のタイプの機能性が所望されることを示す場合があり、その結果、その機能性に対処するマプレットが、一般地図とともに表示される。マプレットはしたがって、このような状況において地図とともに提供すればよい。また、このような状況において、地図は、検索リクエストに適したやり方で(たとえば、リクエスト中の郵便番号の周辺に)位置決めすることができ、かつ/またはマプレットに関するデフォルト値は、検索リクエストに基づいて選択することができる。あるいは、ユーザデータベースは、ある特定のユーザによって予め選択されているマプレットを判定するために照会することができ、個人用地図ページの一部として再度表示することができる。

ボックス510で、ユーザは、第1のガジェット用の特定のパラメータを選択し、データサーバに提出し、データサーバは次いで、提出されたリクエストに適し得るデータを戻す(ボックス512)。戻される情報は、場所を示す住所などの情報を含み得る。データを受信すると、クライアントは、データに関連づけられた地図情報をリクエストすることができ(ボックス514)、地図サーバは、リクエストを翻訳し地図情報を供与することができる(ボックス516)。地図サーバから情報を受信すると、クライアントは、その情報を表現したものを地図アプリケーション中の地図に追加することができる(ボックス518)。

一定時間経過後、ユーザは次いで、実質的には、マッシュアップのマッシュアップを作成するために、別のマプレットにパラメータを与えることを選ぶことができる(ボックス520)。第1のマプレットに関して起きたのと同様のプロセスが、データを求めるリクエストおよびデータの供与(ボックス522)、供与されるデータに関連づけられた地図情報の後続リクエスト(ボックス524)、地図サーバからの地図情報の準備(ボックス526)、および地図サーバによって与えられる情報の表示(ボックス528)で起こり得る。このような表示は、第1のマプレットとの対話から、事前表示とともに起こり得る。その結果、ユーザは、特定の2つのマプレットアプリケーションを選択し、マプレットアプリケーションの両方からの情報を合成する表示を生じることができ得る。

図5Bは、概してユーザによる、マップページとともに表示されるべきマプレットの選択、およびマプレットの後続使用を示すが、この図を参照すると、ユーザは(クライアント経由で)最初に、地図ページにアクセスし(ボックス532)、コードおよび一般地図情報を受信することができる(ボックス534、536)。ただし、この事例では、どのマプレットもガジェットも予め選択されていない。そうではなく、ユーザには、Google個人用ホームページ、すなわちiGoogleにおけるガジェット選択のように実装することができる、いくつかの利用可能マプレットの表示が与えられる(ボックス540)。マプレットは、カテゴリにまとめて並べることができ、ユーザは、カテゴリの1つを選択し(ボックス542)、次いで、選択されたカテゴリ中にある特定のガジェットを選択するコントロールをさらに提供され得る(ボックス544)。

ユーザは次いで、ある特定のマプレットまたはガジェットを選択することができ(ボックス546)、こうすることにより、今後、ユーザがシステムにアクセスするときに、選択されたマプレットがロードされるべきであることを示すように、コードサーバにユーザのプロファイルをアップデートさせることができる(ボックス548)。サーバは、マプレット用のコードを送信することもでき、その結果マプレットは、地図ページ上で、新規に作成されたiframe中に表示される。マプレットコードは、配布されると、データサーバに対してデータをリクエストし(ボックス552)、受信したデータを使って地図サーバに対して(ボックス556)地図情報をリクエストし(ボックス554)、地図上にデータを表示する(ボックス558)ように稼動することができる(ボックス550)。

図6は、ウェブブラウザによって表示されるドメインの間の通信を連携させるプロセスのフローチャートである。概して、このプロセスおよびこのような他のプロセスは、図3に示す構成要素によって実行することができる。図6は概して、パケット化されたいくつかのパケットの、ドメイン境界を越えた転送を示す。最初に、データグループ(パケットでも、ページによって送信される他の特定のデータグループでもよい)が、リレーまたはルータの所で受信される。ルータは、1つのデータグループまたは複数のデータグループを受信することができ、そのパケット化規則を調べて、受信したグループをパケット化する順序を判定し、それ以上のパケット保持が保証される(すなわち、より大きくより効率的な送信用合成パケットを構築するため)かどうか判定することもできる。合成パケットの送信が規則によってトリガされない場合(ボックス606)、受信したデータグループは、パケットバッファに追加され(ボックス608)、送信がトリガされる場合、ルータは、保持しているデータグループおよび他のデータグループをパッケージ化し送信する(ボックス610)。

送信はドメイン境界を超え、ボックス612で、対応するルータが合成パケットを受信する。そのルータは次いで、所定の規則に従って、合成パケットを逆アセンブルして、送られるデータグループをパケットから抽出することができる(ボックス614)。最後に、受信用ルータは、その特定のドメイン内のフレームに個々のデータグループを経路指定することができる(ボックス616)。

図7は、ブラウザが表示したウェブページ上のドメインの間でデータを送るプロセスのスイムレーン図である。ボックス702〜712で、3通りのデータグループが、ページ上のある特定のドメインに関連づけられた地図アプリケーションから受信される。たとえば、ユーザは、地図を動かすか、あるいは地図に関連づけられた3通りのマプレットに適したように地図に影響を与えていてよく、地図アプリケーションは、このようなアクションを報告している最中であってよい。地図ルータは、最初の2つのデータグループを保持し、第3のグループを受信すると、合成パケットの待ち時間またはサイズにより、ドメイン境界を超える合成パケットの送信が必要かどうか判定する。ボックス714で、ルータは、目標ドメインを判定し、そのドメインにパケットを送る。

モジュールルータは、マプレットの形のいくつかの移植可能プログラムモジュールが存在するドメインに関連づけられたルータであり、合成パッケージを受信し(ボックス716)、パッケージを分解して、その中に配置されたデータグループを抽出する(ボックス718)。合成パッケージからデータグループを抽出すると、モジュールルータは、各データグループのアドレスを判定し、そのグループを、適切なマプレットに従って経路指定する(ボックス720、724、728)ことができ、この場合、ページ上の地図アプリケーションに関連づけられた多数のマプレットがある。データは次いで、各マプレット中で実行し得る(ボックス722、726、730)。

図8は、2つの移植可能プログラムモジュールと連携して動作する地図アプリケーションの例を示すスクリーンショットである。第1のモジュールは、表示に追加されるべき追加モジュールを選択する機会をユーザに与える。たとえば、モジュールに関連づけられたサーバは、シカゴにおける犯罪、地図に加えられる天気(たとえば、気温および日照/雨/雪の状態)のマッピングに関するモジュール、および他の様々なモジュール用のコードを格納することができる。自分のページに追加したいモジュールを選択するために、チェックボックスコントロールがユーザに提供される(ページは、個人用地図ページとして保存することができる)。さらに、マプレットがその範囲内であるマプレットタイプやサブグループなど(たとえば、測定ツール、ソーシャルツール、ビジネスツール、地図表示ツールなど)、選択用の値を示すために、色つきドットを各選択の隣に示すことができる。

距離測定ツールモジュールが、ユーザによって予め選択されており、拡大された形で表示される。距離測定ツールは、メインの地図アプリケーションと対話して、ユーザが地図上の2つ以上の地点を選択し(または、州、町、および番地などで、2つ以上の場所を識別し)、次いでその地点を結ぶ距離を計算し、ユーザに対して距離を表示させる。

こうしたモジュールのうちそれ以外のものは、選択された場合、その出力を距離測定ツールと合成することができる。たとえば、ユーザがシカゴ犯罪モジュールを選択した場合、地図は、シカゴにズームインするように、かつシカゴにおいて犯罪が起きたエリア用のインジケータを示すように変形することができる。ユーザは次いで、距離測定ツールを使って、犯罪現場の間の距離または他の情報を判定することができる。このようにして、表示されるアプリケーションは、多数のアプリケーションを、表示アプリケーション用にカスタマイズされ、Googleマップなどの地図表示サービスに直接アクセスするようにユーザがマッシュすることを可能にし得る。

図9は、いくつかの移植可能プログラムモジュールを含むコンテナドキュメント900のレイアウト例を示す。iframeおよびインラインHTML技術の使用を含む、いくつかの結合方法が可能である。図9は、ストックモジュール905、eメールモジュール906、リアルタイム広告モジュール908、広告モジュール910、912、マプレットモジュール916、および地図モジュール914を含む複数のモジュールを示す。モジュールの作成者によって提供される仕様に応じて、様々なモジュール用の異なる形式が存在し得る。一部のモジュールはスクロールバーを提供することができ、それ以外のモジュールは提供することができない。一部のモジュールは、他のモジュールとは異なるサイズまたは形状でよい。さらに、一部のモジュールは、モジュールに関連づけられた表示環境設定および/または使用ごとのデータを編集する機会をユーザにもたらし得る。

一実装形態では、インラインモジュールが、コンテナドキュメントによって自動的にサイズを決められ得るので、スクロール、高さ、またはスケーリング情報は与えなくてよい。モジュール開発者が、こうしたプロパティをモジュールにもたせたい場合、インラインモジュールを、固定サイズ<DIV>タグおよびタグ中に配置される内容でラップすればよい。次いで、スクロールバー、高さ、および他の特性をインライン内容に対して指定すればよい。属性の1つは、スケーリング=「...」と指定させて、コンテナドキュメント中の異なる配置サイズに合わせてモジュールをどのように拡大または縮小すればよいかを開発者に示させる。

このコンテナドキュメント例900で与えられる関数の1つは、ガジェット追加要素903の選択によりコンテナページにコンテンツを追加する機会である。「ガジェット追加」要素903を選択すると、システムは、コンテナページに含まれるべき追加要素を対話形式で示す機会をユーザにもたらすことができる。その入力を受信するためのインタフェースの様々な形を提供することができる。

さらに、モジュールを追加し、編集し、または消去する際、こうした活動を、コンテナドキュメントのリフレッシュなしで起こさせることが望ましい場合がある。これを達成する例示的な一技術は、AJAXプログラミング技術の使用を伴い得るので、モジュールをコンテナドキュメントページのリフレッシュなしで(おそらく、新規コンテナが提示されるiframeのリフレッシュのみで)コンテナドキュメントに追加することができる。あるいは、コンテナドキュメントがリフレッシュされることもなく、開発者がモジュールを開発中である場合には変更モジュールを組み込むためにモジュールが投入されるコンテナドキュメントがページリフレッシュを行う必要もなくモジュールを変更することができる、モジュールを削除するためのAJAXの使用も伴い得る。

特定のモジュールを参照すると、マプレットモジュール916は、上で論じたような、移植可能プログラムモジュール用のコードを参照するiframe中に表示することができる。マプレットモジュール916は、maps.google.comなどの地図サーバ用ドメインに関連づけることができ、地図用タイルを受信し表示し、マプレットモジュール916によって提供されるオブジェクトを表示し、マプレットモジュール916にフィードバックを与えるように構成することができる、地図モジュール914などの他のモジュールと対話することができる。

他のモジュールも、システム内で通信を行うことができる。たとえば、eメールモジュール906は、ユーザ向けの予定に関する情報を有するカレンダ特徴も含み得る。eメールモジュール906は、ユーザ向けの今後の予定に関する時間、場所、および他の情報を求めるリクエストをマプレットモジュール916から受信することができ、このような情報をマプレットモジュール916に戻すことができる。マプレットモジュール916は次いで、予定に関する地理相関データを取得するために、地図サーバに住所情報をフォワードすることができる。マプレットモジュール916は次いで、地図モジュール914によって表示される地図に掲示させるべき各予定にオブジェクトを関連づけさせることができる。同様にして、広告モジュール910、912は、たとえばマプレットモジュール916や地図モジュール914から地理情報を受信することができ、特定の光学効果および/または情報の中にある場所を対象としたターゲット広告を取り出すことができる。

図10は、広告および他の項目を動的に生成するシステム例1000の概略図である。システム1000は、様々な動作のために、ガジェットなどの移植可能プログラムモジュールを利用するシステムの一般表現である。本明細書に記載する一般動作は、適切な場合、図1A、1B、2、3に示すシステムに適用可能である。

システム1000は、システムに関連づけることができる複数のモジュールを有するホストサーバシステム1010を含み得る。このようなモジュールは、コンテナサーバ1012、モジュールサーバ1014、仕様サーバ1016、バックエンドサーバ1018、分析モジュール1028、モジュール作成サーバ1032、配信サーバ1034、および広告サーバ1036を備え得る。図に示すように、ホストサーバシステム1010は、ネットワーク1026を介して他の複数のシステムまたはサブシステムに接続することができる。

ネットワークに接続される他のシステムは、1つまたは複数のユーザシステム1022、1つまたは複数の遠隔項目サーバ1024、1つまたは複数のモジュール開発者システム1030および1つまたは複数の配信受信者サーバ1038を備え得る。さらに、1つまたは複数のデータベースシステム1020が、ホストサーバシステム1010の様々なモジュールと連動して動作することができる。

特に、別個の1つのサーバは、ある特定の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に、ネットワークを介して接続することができる。

1つまたは複数のデータベース(たとえば、大規模または動的情報データベース)と対話するバックエンドサーバ1018を提供することができる。たとえば、頻繁な更新を取得し、(たとえば、RSSフィードからの)データフローを必要とするニュースモジュールに対して、バックエンドサーバ1018は、データをコンテナ用のHTMLにフォーマットすることができる。

具体的な一例では、ある人が、カリフォルニア州マウンテンビュー中心部の地図を表示するためのモジュールを作成するのに、既存の地図表示プログラムへのアプリケーションプログラムインタフェース(API)を使うようなモジュール(たとえば、地図モジュール)を作成することができる。このモジュールは、仕様サーバ上に格納されたXML仕様ファイルまたはモジュール仕様ファイルを含み得る。仕様サーバは、コンテナページを運営するためのサイト上のサーバを含む、適切などのサーバも含み得る。ユーザまたは別の人が次いで、この新規モジュールを、個人用ホームページまたは別の形のウェブページ(コンテナドキュメント)上に含めることができる。コンテナドキュメントを供与するサーバは、モジュールサーバとして動作することができ、そのAPIからの照会により地図表示データを生成するサーバは、バックエンドサーバであるとみなすことができる。

一実装形態では、分析モジュール1028は、様々なとき(たとえば、モジュールがユーザによって最初に選択されるとき、モジュールがコンテナによって包含のためにコールされる度、または安全性およびセキュリティのために有利であると判断される他の任意のとき、および他のとき)にモジュールを分析することができる。分析モジュール1028は、モジュールと、不認可または危険モジュールのリストあるいは承認されたモジュールのリストとの比較を含むいくつかのアクションを実施することができる。この比較は、名前または場所(たとえば、URL)、仕様の内容、仕様が存在する場所の内容、あるいはモジュールについて確認可能であり得る情報による完全または部分文字列(たとえば、プレフィックス、サフィックスおよび正規表現)一致を伴い得る。

分析モジュール1028は、モジュールが不認可または危険であるという判定に応答して、たとえば、リクエストを黙って遮断すること(すなわち一般エラーを出すこと)、遮断された理由を説明するエラーのあるリクエストを遮断すること、あるいは安全であるとともに不認可モジュール(たとえば、第1のものが不認可地図表示サイトだった場合は、地図に関する別のモジュール、または不認可モジュールがバスケットボールモジュールだった場合は「バスケットボール」というキーワードを含むモジュール)に関すると判定されている異なるモジュール仕様にリクエストをリダイレクトすることを含む、1つまたは複数のアクションをとり得る。

たとえば、リダイレクションにより、オリジナルモジュールのURLは、「安全」モジュールに渡してよい。安全モジュールは次いで、プロキシサーバを使って、後で説明するようにオリジナルURLの内容を取り出すことができる。開発者は次いで、オリジナルモジュール中の小さなバグを、オリジナルモジュールの内容を表示することができるように直すためのエラーハンドラを置き換えることができる。別の実施形態では、分析モジュール1028は、モジュールに含まれるJava（登録商標）スクリプトまたは他のスクリプトをコンパイルすることなどによって、安全かどうか判定するためにモジュール内容を解析して、モジュールが実施し得る安全でない、または望まれないアクションの識別を試みることができる。

1つまたは複数のモジュール作成サーバ1032を提供することができる。こうしたサーバは、モジュール作成者が対話プロセスによりモジュールを作成することを可能にするための「ウィザード」として動作し得る。たとえば、モジュール作成サーバ1032は、モジュールを作成するある人が、モジュール仕様を自動的に生成するのに使われる入力を与えることを可能にする一連のユーザインタフェースを提供することができる。たとえば、様々なモジュール仕様テンプレートに、対応する入力を与えてよい。モジュール作成サーバ1032は次いで、ユーザによって供給された入力を受け取り、テンプレートに挿入し、モジュール用のモジュール仕様を生成することができる。プレビュー、テスト、およびデバッグ機能を、「ウィザード」の一部として提供することもできる。このモジュールは、クライアントにダウンロード可能であってもよい。

配信サーバ1034は、モジュールに関する、1つまたは複数の配信受信者サーバ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は、モジュールに関する2つ以上の概念を広告に関連づけ、1つのビッドを、まとめて、2つ以上のキーワードに関連づけることによって、オンライン広告を管理することができる。さらに、配信サーバ1034または広告サーバ1036は、モジュールに関連づけられたコンテナページを記述する情報を求めるリクエストを送る広告関連モジュールなど、配信されるモジュールに対するリクエストに応答することができる。

適切な任意の数のやり方で、コンテナ情報、モジュール仕様および/または関連情報、フォーマット用データ、ユーザごとおよびモジュールごとの環境設定データ、遠隔モジュールIDデータ、遠隔モジュール場所参照データ、広告データ、広告主データ、コンテンツ/金銭データ、配信受信者データ、モジュール用テンプレート、モジュール向け入力、信頼できる、および信頼できないモジュールのリスト、承認基準および関連情報ならびに/あるいはモジュールによって本明細書に記載するように動作するのに用いられる他のどの情報も格納する1つまたは複数のデータベースシステム1020を提供することができる。単一データベース構造を示してあるが、データは、いくつかの場所、および1つまたは複数のシステムに格納することができる。

一実装形態では、モジュールをコンテナドキュメントに埋め込むためのシステムおよび方法が提供される。コンテナドキュメントの一例は、インターネット上のGoogleサービスのユーザにとって現在利用可能である、Google個人用ホームページ、すなわちiGoogleなどの個人用ホームページであろう。ユーザが個人用ホームページなどのコンテナドキュメントに含めることができるコンテンツのタイプを制限するのではなく、1つまたは複数の実装形態が、コンテナドキュメントのソース以外のソースからユーザがモジュールを選択することを可能にし得る。したがって、たとえばユーザは、Googleに関連づけられていないソースから、自身の個人用Googleホームページにモジュールを含めることを選ぶことができる。

図11は、本明細書に記載する技術を実装するのに使うことができるコンピュータ装置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は、1つの揮発性メモリユニットまたは複数のユニットである。別の実装形態では、メモリ1104は、1つの不揮発性メモリユニットまたは複数のユニットである。メモリ1104は、磁気または光ディスク、別の形のコンピュータ可読媒体でもよい。

記憶装置1106は、コンピューティング装置1100用の大容量記憶を提供することが可能である。一実装形態では、記憶装置1106は、フロッピー（登録商標）ディスク装置、ハードディスク装置、光ディスク装置、またはテープ装置、フラッシュメモリもしくは他の同様の固体メモリ装置、あるいは、ストレージエリアネットワーク内の装置または他の構成を含む装置アレイなどのコンピュータ可読媒体でもよく、その媒体を含んでもよい。コンピュータプログラム製品は、情報担体として有形に実施することができる。コンピュータプログラム製品は、実行されると、上述したような1つまたは複数の方法を実施する命令も含み得る。情報担体は、コンピュータ、またはメモリ1104、記憶装置1106、プロセッサ1102上のメモリ、もしくは伝播信号などのマシン可読媒体である。

高速コントローラ1108は、コンピューティング装置1100用の帯域消費型演算を管理し、低速コントローラ1112は、より低い帯域消費型演算を管理する。このような機能割振りは、例示に過ぎない。一実装形態では、高速コントローラ1108は、メモリ1104、ディスプレイ1116(たとえば、グラフィックスプロセッサまたはアクセラレータを経由して)、および様々な拡張カード(図示せず)を受け入れ得る高速拡張ポート1110に結合される。この実装形態において、低速コントローラ1112は、記憶装置1106および低速拡張ポート1114に結合される。低速拡張ポートは、様々な通信ポート（たとえば、USB、ブルートゥース、イーサネット（登録商標）、ワイヤレス・イーサネット（登録商標））を含み得るが、キーボード、指示装置、スキャナ、またはスイッチやルータなどのネットワーク装置など、1つまたは複数の入力/出力装置に、たとえばネットワークアダプタを経由して結合することができる。

コンピューティング装置1100は、図に示すように、いく通りかの形で実装することができる。たとえば、標準サーバ1120として、またはこのようなサーバのグループの形で何度も実装することができる。ラックサーバシステム1124の一部として実装することもできる。さらに、ラップトップコンピュータ1122などのパーソナルコンピュータの形で実装することもできる。あるいは、コンピューティング装置1100にある構成要素を、装置1150などのモバイル装置内の他の構成要素(図示せず)と組み合わせてもよい。このような装置はそれぞれ、コンピューティング装置1100、1150の1つまたは複数を含んでよく、システム全体は、互いと通信する多数のコンピューティング装置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は、1つのコンピュータ可読媒体または複数の媒体、1つの揮発性メモリユニットまたは複数のユニット、あるいは1つの不揮発性メモリユニットまたは複数のユニットのうちの1つまたは複数として実装することができる。拡張メモリ1174を提供し、たとえば、SIMM(シングルインラインメモリモジュール)カードインタフェースを含み得る拡張インタフェース1172を介して装置1150に接続することもできる。このような拡張メモリ1174は、装置1150に予備記憶空間を提供することができ、装置1150用のアプリケーションまたは他の情報を格納することもできる。具体的には、拡張メモリ1174は、上述したプロセスを遂行し、または補うための命令を含んでよく、安全な情報も含んでよい。したがって、たとえば、拡張メモリ1174は、装置1150用のセキュリティモジュールとして提供することができ、装置1150の安全な使用を許可する命令を備えてプログラミングすることができる。さらに、SIMMカードを介して、付加情報とともに、ハッキング不可能なやり方でSIMMカード上に識別情報を置くなど、安全なアプリケーションを提供することができる。

メモリは、たとえば、後で論じるようにフラッシュメモリおよび/またはNVRAMメモリを含み得る。一実装形態では、コンピュータプログラム製品が、情報担体として有形に実施される。コンピュータプログラム製品は、実行されると上述したような1つまたは複数の方法を実施する命令を含む。情報担体は、メモリ1164、拡張メモリ1174、プロセッサ1152上のメモリなどのコンピュータまたはマシン可読媒体、あるいは、たとえばトランシーバ1168または外部インタフェース1162を介して受信することができる伝播信号である。

装置1150は、必要な場合はデジタル信号処理回路構成を含み得る通信インタフェース1166を介してワイヤレスに通信することができる。通信インタフェース1166は、それ以外のものの中でも特に、GSM音声コール、SMS、EMS、またはMMSメッセージ通信、CDMA、TDMA、PDC、WCDMA、コンテナドキュメント102MA2000、またはGPRSなど、様々なモードまたはプロトコルでの通信を可能にし得る。このような通信は、たとえば、無線周波数トランシーバ1168を介して起こり得る。さらに、近距離通信は、ブルートゥース、WiFi、または他のこのようなトランシーバ(図示せず)を用いるなどして起こり得る。さらに、GPS(全地球位置発見システム)受信機モジュール1170は、装置1150上で稼動するアプリケーションによって必要に応じて使うことができる追加ナビゲーションおよび場所関連ワイヤレスデータを装置1150に提供することができる。

装置1150は、ユーザから発話情報を受信し使用可能なデジタル情報に変換することができるオーディオコーデック1160を使って、音声によって通信することもできる。オーディオコーデック1160はまた、たとえば装置1150のハンドセット内のスピーカなどにより、ユーザ向けに可聴音を生成することができる。このような音は、音声通話からの音を含んでよく、録音された音(たとえば、音声メッセージ、音楽ファイルなど)を含んでよく、装置1150上で動作するアプリケーションによって生成された音も含んでよい。

コンピューティング装置1150は、図に示すように、いく通りかの形で実装することができる。たとえば、セルラー電話1180として実装することができる。スマートフォン1182、携帯情報端末、または他の同様のモバイル装置の一部として実装することもできる。

本明細書に記載したシステムおよび技術の様々な実装形態は、デジタル電子回路構成、集積回路構成、特殊設計広告サーバASIC(特定用途向け集積回路)、コンピュータハードウェア、ファームウェア、ソフトウェア、および/またはその組合せにおいて実現することができる。こうした様々な実装形態は、記憶システム、少なくとも1つの入力装置、および少なくとも1つの出力装置との間でデータおよび命令を受信し、データおよび命令を送信するように結合された、特殊でも汎用でもよい少なくとも1つのプログラム可能プロセッサを含むプログラム可能システム上で実行可能および/または翻訳可能な1つまたは複数のコンピュータプログラムでの実装を含み得る。

こうしたコンピュータプログラム(プログラム、ソフトウェア、ソフトウェアアプリケーションまたはコードとしても知られる)は、プログラム可能プロセッサ用のマシン命令を含み、高度手続き型および/またはオブジェクト指向プログラミング言語で、ならびに/あるいはアセンブリ/マシン言語で実装することができる。本明細書で使用する「マシン可読媒体」「コンピュータ可読媒体」という用語は、マシン可読信号としてマシン命令を受信するマシン可読媒体を含む、プログラム可能プロセッサにマシン命令および/またはデータを提供するのに使われるどのコンピュータプログラム製品、機器および/または装置(たとえば、磁気ディスク、光ディスク、メモリ、プログラム可能論理素子(PLD))も指す。「マシン可読信号」という用語は、プログラム可能プロセッサにマシン命令および/またはデータを提供するのに使われるどの信号も指す。

ユーザとの対話を可能にするために、本明細書に記載したシステムおよび技術は、ユーザに情報を表示する表示装置(たとえば、CRT(陰極線チューブ)またはLCD(液晶ディスプレイ)モニタ)と、ユーザがコンピュータに入力を与えるためのキーボードおよび指示装置(たとえば、マウスやトラックボール)とを有するコンピュータ上に実装することができる。ユーザとの対話を可能にするために、他の種類の装置も同様に使うことができる。たとえば、ユーザに提供されるフィードバックは、どの形の感覚フィードバック(たとえば、視覚フィードバック、聴覚フィードバック、および触覚フィードバック)でもよく、ユーザからの入力は、音響、発話、または触覚入力を含む、どの形でも受信することができる。

本明細書に記載したシステムおよび技術は、バックエンド構成要素(たとえば、データサーバとして)を含む、またはミドルウェア構成要素(たとえば、アプリケーションサーバ)を含む、またはフロントエンド構成要素(たとえば、本明細書に記載したシステムおよび技術の実装形態とユーザが対話できるためのグラフィカルユーザインタフェースまたはウェブブラウザを有するクライアントコンピュータ)を含むコンピューティングシステム、あるいはこのようなバックエンド、ミドルウェア、またはフロントエンド構成要素のどの組合せにおいても実装することができる。システムの構成要素は、どの形または媒体のデジタルデータ通信(たとえば、通信ネットワーク)によっても相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)、ワイドエリアネットワーク(「WAN」)、およびインターネットを含む。

コンピューティングシステムは、クライアントおよびサーバを含み得る。クライアントおよびサーバは概して、互いとは遠隔にあり、通常、通信ネットワークを介して対話する。クライアントとサーバの関係は、それぞれのコンピュータ上で稼動し互いとのクライアント-サーバ関係を有するコンピュータプログラムにより起こる。

いくつかの実施形態について記載した。それにも関わらず、様々な変更を行うことができることが理解されよう。たとえば、上で示したフローの様々な形は、ステップを並べ替えて、追加して、または省いて用いることができる。また、コンテンツ配布システムおよび方法のいくつかのアプリケーションを記載したが、他の多数のアプリケーションが企図されることを理解されたい。さらに、実施形態の多くは、リアルタイムで動的に作成された広告との関係で記載したが、他のコンテンツ配布を他の様々な形で提供することもできる。したがって、他の実施形態は、添付の請求項の範囲内である。

100 表示
102 検索コントロール
102a 「地図を検索」タブ
102b 「お店を探す」タブ
102c 「行き方を調べる」タブ
104 タブエリア
106 移植可能プログラムモジュール
108 移植可能プログラムモジュール
110 折りたたみモジュール
112 地図
114 気温
116 ベースインジケータ
120 地図HTMLページ
122 マプレットスタブ
123 マプレットスタブ
126 マプレットホスト
128 ホストオブジェクト
130 ホストオブジェクト
200 システム
202 クライアント装置
204 サーバ
206 中央ネットワーク
208 共通ネットワーク
210 移植可能コードサーバ
212 地理関連データサーバ
214 サーバ
300 システム
304 ネットワーク
302 クライアント装置
306 広告サーバ
308 地図サーバ
310 データサーバ
312 マプレット、モジュール
314 マプレット、モジュール
316 マプレット、モジュール
318 モジュールルータ
318a パケタイザ
322 地図ルータ
322a パケタイザ
324 地図アプリケーション
900 コンテナドキュメント
905 ストックモジュール
906 eメールモジュール
908 リアルタイム広告モジュール
910 広告モジュール
912 広告モジュール
914 地図モジュール
916 マプレットモジュール
1000 システム
1010 ホストサーバシステム
1012 コンテナサーバ
1014 モジュールサーバ
1016 仕様サーバ
1018 バックエンドサーバ
1020 データベースシステム
1022 ユーザシステム
1024 遠隔項目サーバ
1026 ネットワーク
1028 分析モジュール
1030 モジュール開発者システム
1031 地図サーバ
1032 モジュール作成サーバ
1034 配信サーバ
1036 広告サーバ
1038 配信受信者サーバ
1100 コンピュータ装置
1102 プロセッサ
1104 メモリ
1106 記憶装置
1108 高速インタフェース、高速コントローラ
1110 高速拡張ポート
1112 低速インタフェース、低速コントローラ
1114 低速バス、低速拡張ポート
1116 ディスプレイ
1120 標準サーバ
1122 ラップトップコンピュータ
1124 ラックサーバシステム
1150 携帯型コンピュータ装置
1152 プロセッサ
1154 ディスプレイ
1156 ディスプレイインタフェース
1158 制御インタフェース
1160 オーディオコーデック
1162 外部インタフェース
1164 メモリ
1166 通信インタフェース
1168 トランシーバ
1170 GPS(全地球位置発見システム)受信機モジュール
1172 拡張インタフェース
1174 拡張メモリ
1180 セルラー電話
1182 スマートフォン

Claims (18)

1. 地図に関するドメイン間通信を提供するためのコンピュータ実施方法であって、
   地図表示サーバのドメイン上の地図表示アプリケーションが提供する情報をウェブページ上に表示するステップと、
   1つまたは複数の移植可能プログラムモジュールを前記ウェブページ上に表示するステップと、
   前記1つまたは複数の移植可能プログラムモジュールが、クロスフレームコールを用いて、前記地図表示アプリケーションと通信するステップと、
   前記1つまたは複数の移植可能プログラムモジュールからのアクションに基づいて、前記地図表示アプリケーション上に表示を生成するステップとを含み、
   前記1つまたは複数の移植可能プログラムモジュールが、前記地図表示サーバの前記ドメインとは異なるドメインに関連付けられた1つまたは複数のインラインフレーム中に生成されると共に、
   前記移植可能プログラムモジュールが、定義関数を実施し、そして前記ウェブページ上の前記1つまたは複数のインラインフレーム中に挿入されるプログラムであり、
   前記方法が、
   地図ルータ及びモジュールルータ用のルータインラインフレームを生成するステップと、
   前記ルータインラインフレームを、前記ウェブページ上の前記1つまたは複数の移植可能プログラムモジュールに関連付けられた前記1つまたは複数のインラインフレームの前記ドメインに関連付けるステップと、
   前記1つまたは複数のインラインフレームのそれぞれを前記ルータに登録するステップとをさらに含み、
   前記地図ルータが、前記地図表示アプリケーションとの通信を管理すると共に、
   前記モジュールルータが、前記1つまたは複数の移植可能プログラムモジュールとの通信を管理する、コンピュータ実施方法。
2. 前記移植可能プログラムモジュールの前記プログラムが、前記地図表示アプリケーション用のドメインとは異なる前記ドメイン上で収容される前記インラインフレーム中で稼動する、請求項1に記載の方法。
3. 前記クロスフレームコールが、一時的接続を有しているリモートプロシージャコールを使用することを含み、応答を期待するリクエストが、応答が受信されることが期待されるソースインラインフレームまたはユニフォームリソースロケータを供給する、請求項1に記載の方法。
4. 前記ルータのそれぞれが、関連するパケタイザを有し、
   前記方法が、
   前記地図表示アプリケーションから、または前記1つまたは複数の移植可能プログラムモジュールから受信されたデータパケットを前記パケタイザにおいてマージするステップと、前記データパケットを前記異なるドメインの境界を越えて送信するステップとをさらに含む、請求項1に記載の方法。
5. 前記登録するステップが、
   各ルータインラインフレームに名前および識別子を割り当てるステップと、そのソース属性を、そのルータが作用するホスト上のルータハイパーテキストマークアップ言語ファイルの場所に設定するステップとを含み、
   前記識別子が、前記ルータが位置決めされる識別子であると共に、前記ルータのホスト名から一意に導出される、請求項1に記載の方法。
6. 周辺の前記ウェブページをリフレッシュすることなく、前記1つまたは複数の移植可能プログラムモジュールのうちの1つを修正するステップをさらに含む、請求項1に記載の方法。
7. 前記地図表示アプリケーションにおいて入力を受信するステップと、前記入力に関する情報を前記移植可能プログラムモジュールの1つまたは複数に伝達するステップとをさらに含む、請求項1に記載の方法。
8. 検索リクエストに応答して前記ウェブページ上に表示するべきマップデータを識別するステップと、
   前記検索リクエストに応答して前記1つまたは複数の移植可能プログラムモジュールを識別するステップとをさらに含み、
   前記識別するステップが、前記地図表示アプリケーションの所望される機能性を示す検索リクエスト中の用語を分析するステップを含む、請求項1に記載の方法。
9. 異なるドメインに関連づけられた2つの地図表示関連移植可能プログラムモジュールを表示するステップと、前記移植可能プログラムモジュールのそれぞれから前記地図表示アプリケーションにデータを伝達するステップとをさらに含む、請求項1に記載の方法。
10. 前記地図表示アプリケーション上での前記表示が、前記地図上に置かれた1つまたは複数のオブジェクトを含む、請求項1に記載の方法。
11. 個人用ページ情報を格納するユーザアカウントを参照することによって、前記1つまたは複数の移植可能プログラムモジュールを識別するステップをさらに含む、請求項1に記載の方法。
12. 地理的関連情報を求めてデータサーバを照会するステップと、前記地理的関連情報に関連づけられたデータを、前記データサーバとは別個の地図サーバに提出するステップとをさらに含む、請求項1に記載の方法。
13. 実行されると、地図に関するドメイン間通信を提供するためのアクションを、コンピュータ上で生じさせる命令を有形に記録した1つまたは複数のコンピュータ可読媒体であって、前記アクションが、
    地図表示サーバのドメイン上の地図表示アプリケーションが提供する情報をウェブページ上に表示すること、
    1つまたは複数の移植可能プログラムモジュールを前記ウェブページ上に表示すること、
    前記1つまたは複数の移植可能プログラムモジュールが、クロスフレームコールを用いて、前記地図表示アプリケーションと通信すること、および
    前記1つまたは複数の移植可能プログラムモジュールからのアクションに基づいて、前記地図表示アプリケーション上に表示を生成することを含み、
    前記1つまたは複数の移植可能プログラムモジュールが、前記地図表示サーバの前記ドメインとは異なるドメインに関連付けられた1つまたは複数のインラインフレーム中に生成されると共に、
    前記移植可能プログラムモジュールが、定義関数を実施し、そして前記ウェブページ上の前記1つまたは複数のインラインフレーム中に挿入されるプログラムであり、
    前記アクションが、
    地図ルータ及びモジュールルータ用のルータインラインフレームを生成すること、
    前記ルータインラインフレームを、前記ウェブページ上の前記1つまたは複数の移植可能プログラムモジュールに関連付けられた前記1つまたは複数のインラインフレームの前記ドメインに関連付けること、および
    前記1つまたは複数のインラインフレームのそれぞれを前記ルータに登録することをさらに含み、
    前記地図ルータが、前記地図表示アプリケーションとの通信を管理すると共に、
    前記モジュールルータが、前記1つまたは複数の移植可能プログラムモジュールとの通信を管理する、コンピュータ可読媒体。
14. 前記アクションが、前記地図表示アプリケーションにおいて入力を受信すること、および前記入力に関する情報を前記移植可能プログラムモジュールの1つまたは複数に伝達することをさらに含む、請求項13に記載のコンピュータ可読媒体。
15. 前記アクションが、検索リクエストに応答して前記ウェブページ上に表示するべきマップデータを識別することをさらに含み、
    前記アクションが、前記検索リクエストに応答して前記1つまたは複数の移植可能プログラムモジュールを識別することをさらに含み、
    前記識別することが、前記地図表示アプリケーションの所望される機能性を示す検索リクエスト中の用語を分析することを含む、請求項13に記載のコンピュータ可読媒体。
16. 前記アクションが、ユーザにとって利用可能な移植可能プログラムモジュールのリストを表示すること、前記移植可能プログラムモジュールの1つまたは複数の選択を受信すること、および前記受信した選択に応答して、前記選択された移植可能プログラムモジュールを表示することをさらに含む、請求項13に記載のコンピュータ可読媒体。
17. 前記移植可能プログラムモジュールが、サードパーティサーバにある地理関連データにアクセスし、前記地理関連データに関連づけられた情報を、ジオコーディングのために地図サーバに供給する、請求項13に記載のコンピュータ可読媒体。
18. 請求項13から請求項17のいずれか一項に記載のコンピュータ可読媒体に記録された命令を実行する、コンピュータ実施システム。