JP5222997B2 - 動的な画像合成 - Google Patents

Description

本発明は、動的な画像合成に関する。

ますます多くの情報が、例えば、インターネットを経由するなど電子的に利用可能であるので、多くのユーザに対していつでも表示できるコンテンツの量や種類も増加する。例えば、ユーザがキーワードや問い合わせに基づいてコンテンツを検索する例では、非常に多くのアイテムが検索結果ページに返される。検索エンジンによる画像検索など、それぞれの結果が対応する画像を有する場合には、ページを表示する装置に転送される必要のあるデータが多量にあるために、全体のロード時間はかなり遅れる可能性がある。サーバがこのようなコンテンツを提供する際のロードを低減するために、多くのブラウザまたは他のクライアント側のＧＵＩ（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ：グラフィカル・ユーザ・インタフェース）アプリケーションが任意の時点で所与のサーバまたはホスト名への接続数を制限する。例えば、多くのこのようなインタフェースは、現在のところ、ユーザをホストへの２つの同時接続に制限している。接続数を制限するということは、共通のホストから画像を取り出すための各々の接続時に、１００個の画像のページに対して、平均５０個の要求が必要になるということである。電子環境の一例では、時間の５％だけがＨＴＭＬ文書のダウンロードに費やされ、９５％がＨＴＭＬ文書内の要素（例えば、画像およびスクリプト）をフェッチするためのＨＴＴＰ要求をするのに費やされる。したがって、ページの要素を要求しダウンロードするのに必要な時間を低減するのが望ましい。

１つの従来の手法は、複数のサーバ（実サーバまたは仮想サーバ）または異なるホスト名（例えば、ｉｍａｇｅｓ１．ｈｏｓｔｎａｍｅ．ｃｏｍ、ｉｍａｇｅｓ２．ｈｏｓｔｎａｍｅ．ｃｏｍ）を利用することである。このように、１つのブラウザからの同時接続の数は増加する。例えば、５０のサーバがあり、ブラウザが各々のサーバに対する２つの接続を有する場合、例となるページ上の１００の画像の全てが平行してダウンロードされる。別の方法では、２つの接続がある場合、各々の接続に対して、潜在的に平均で５０個の画像が順にダウンロードされる（速度や画像サイズに応じて、実際の数はおそらく２つの接続間で時間とともに均一に分割されなくなる）。しかし、明らかなように、所与のページ上で示される画像の数を処理するのに十分な数のサーバを持つこと、および種々のサーバまたはホスト名の画像へのリンク、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ：ユニフォーム・リソース・ロケータ）または他のマッピングを生成し維持しようとするのは実用的でない場合もある。これは、特に、コンテンツがしばしば変化する場合に問題になる可能性がある。また、さらに別の１００の要求がある場合、平行して行われても、性能は最適でなく、このことでサーバ上のロードを著しく増加させ、ネットワークトラフィックやシステムトラフィックを増大させる。さらに、各画像は別個に記憶および／または転送され、このことが画像の共通の特徴に基づいた画像の圧縮をさらに妨げることになる。

したがって、いくつかの改善点の中でも、特に、コンテンツが動的に決定され、および／またはコンテンツが複数のソースからのものである場合に、電子環境でコンテンツを要求および／または配信するプロセスを改善することが望ましい。

本開示の種々の実施形態は、図面を参照して説明する。

一実施形態に従って使用可能なシステム構成を示す図である。 一実施形態に従って使用可能なユーザインタフェースの一例を示す図である。 図２のインタフェースの例の一部を生成するのに使用可能な合成画像を示す図である。 図２のインタフェースの例の一部を生成するのに使用可能な合成画像を示す図である。 一実施形態に従って使用可能な画像を決定および合成する方法を示す図である。 一実施形態に従って使用可能な合成画像から個々の画像を抽出する方法を示す図である。

本開示の種々の実施形態に従うシステムおよび方法は、電子環境でコンテンツを転送するための従来の手法に見られた１つまたは複数の上述の欠点および他の欠点を克服することができる。さまざまな手法では、コンテンツを取得するのに必要な接続数を低減するためにコンテンツの複数のインスタンスが合成されうる。また、それとは別に、個々のインスタンスを別々に要求するのに必要な時間およびリソースの量を低減するためにコンテンツの複数のインスタンスが合成されうる。

図１は、種々の実施形態に従う態様を実装する環境１００の一例を示す図である。理解されるであろうが、必要に応じて、種々の実施形態を実装するのに異なる環境が使用される場合もある。図示されている環境１００は、クライアント電子装置１０２を含む。クライアント電子装置１０２は、適切なネットワーク１０４を介して要求、メッセージ、または情報を送受信して、情報を装置のユーザに返すように動作可能な適切な装置を含むことができる。このようなクライアント装置の例として、パーソナル・コンピュータ、携帯電話、ハンドヘルド型メッセージング装置、ラップトップ・コンピュータ、セットトップ・ボックス、携帯情報端末、電子書籍リーダなどが挙げられる。ネットワークは、イントラネット、インターネット、セルラー・ネットワーク、ローカル・エリア・ネットワーク、任意の他のこのようなネットワーク、またはこれらの組み合わせなど、任意の適切なネットワークを含むことができる。このようなネットワークを経由して通信するためのプロトコルおよびコンポーネントは周知であり、本明細書では詳細に説明しない。ネットワーク経由の通信は、有線接続または無線接続、またはこれらの組み合わせにより可能になる。この例では、ネットワークは、インターネットを含み、環境として、要求を受信してその要求に応答してコンテンツを供給するウェブサーバ１０６を含むが、他のネットワークでは、当業者に明らかであるように、同様の目的を供給するための代替の装置が使用される場合もある。

一実施形態の環境は、１つまたは複数のコンピュータネットワークまたは直接接続を使用して通信リンク経由で相互接続される複数のコンピュータシステムおよびコンポーネントを利用する分散コンピューティング環境である。しかし、システムは図１に示されたコンポーネントより少ない、またはそれより多いコンポーネントを有するシステムでも同様に十分に動作可能であることは当業者には明らかであろう。したがって、図１のシステム１００は、当然な実例として、本開示の範囲を制限するものでないと解釈されるべきである。

図示されている環境はさらに、少なくとも１つのアプリケーションサーバ１０８とデータストア１１０とを含む。本明細書で使用される時、用語「データストア」はデータの記憶、アクセス、取り出し可能な任意の装置または装置の組み合わせを指し、任意の標準的な、分散環境、クラスタ化環境において、任意の組み合わせおよび任意の数のデータサーバ、データベース、データ記憶装置、およびデータ記憶媒体を含んでもよい。アプリケーションサーバは、クライアント装置に対して１つまたは複数のアプリケーションのアスペクトを実行するのに必要とされるデータストアと統合するための任意の適切なハードウェアおよびソフトウェアを含み、データアクセスやアプリケーションのビジネスロジックの大部分を処理することができる。アプリケーションサーバは、データストアと協働して、アクセス制御サービスを行い、ユーザに転送されるテキスト、グラフィック、オーディオ、および／またはビデオなどのコンテンツを生成することができ、これらのコンテンツはウェブサーバによって、ハイパーテキスト転送プロトコルを使用して、少なくとも１つのウェブページに対してＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ：ハイパーテキストマークアップ言語）の形式でユーザに供給される。クライアント装置１０２とアプリケーションサーバ１０８との間での全ての要求や応答、およびコンテンツの配信は、ウェブサーバによって処理される。

各サーバは、そのサーバの一般管理および動作のための実行可能プログラム命令を提供するオペレーティングシステムを含むことができ、サーバのプロセッサによって実行される時にサーバに対象の機能を実行させる命令を記憶するコンピュータ可読媒体を含むことができる。特に、本明細書内の開示内容を踏まえると、オペレーティングシステムの適切な実装およびサーバの汎用機能は周知であり、または市販されており、当業者によって容易に実装される。

データストア１１０は、特定のアスペクトに関するデータを記憶するための複数の別個のデータテーブル、データベース、または他のデータ記憶機構および媒体を含むことができる。例えば、図示されているデータストアは、カタログの明細データ１１２、コミュニティデータ１１４、ユーザ情報１１６、発注書データ１１８を記憶する機構を含む。例えば、ページ画像情報やアクセス権情報などのデータストアに記憶される必要のある多くの他のアスペクトも可能であることは理解されたい。これらは、必要に応じて上述の機構のいずれかに記憶されるか、またはデータストア１１０内の追加の機構に記憶される。データストア１１０は、それとともに関連付けられたロジックによって、アプリケーションサーバ１０８からの命令を受信し、その命令に応答してデータを取得、更新、またはそれ以外の処理を行うように動作可能である。一例では、ユーザは特定の種類のアイテムの検索要求を提出する場合がある。この場合、データストアはユーザ情報にアクセスしてユーザのＩＤを確認し、カタログ明細情報にアクセスしてその種類のアイテムに関する情報を取得することができる。その後、その情報は、例えば、ブラウザを介してユーザ装置１０２上でユーザが見ることができるウェブページ上に結果リストとしてユーザに返される。対象となる特定のアイテムに関する情報は、ブラウザの専用ページまたはウィンドウで見ることができる。

１つの特定の実施形態では、マーケットプレイスを実装するシステムは、１つまたは複数のアイテムの消費を提供する複数の第一および第三者の売り手によって買い手に提出されるオファーリストを管理する。この例では、マーケットプレイスシステムは、小売サーバと、オファー・リスティング・エンジンと、バック・エンド・インタフェースと、オファーリスト管理エンジンとを含む。これらのエンジンおよびインタフェースは、別々のコンピュータシステム（例えば、別々のサーバ）を使用して実装されるか、または１つのコンピュータシステム上でプロセスとして実装されてもよい。さらにまた、各エンジンまたはインタフェースは、複数の分散システムを使用して実装されてもよい。小売サーバは、マーケットプレイスを使用して、例えば、ウェブベースのインタフェースを使用して、取引を望む買い手および売り手にフロントエンド・インタフェースを提供するように構成される。ウェブベースのインタフェースは、買い手および売り手が、口座の開設および管理、販売または他の消費用のアイテムの提示、販売アイテムに関する情報の提供、販売用に提示されたアイテムの閲覧、販売用に提示されたアイテムの購入などを行うことができるように構成されている。さらに、小売サーバは、これらの取引に関する支援機能、例えば、セキュリティ機能、金融取引機能、ユーザ識別機能などを実装するように構成される。小売サーバは、第三者の売り手によって販売用に提示されたアイテムを表示する複数のウェブページを含むことができるオファー・リスティング・ウェブサイトを提供するように構成される場合がある。

本例では、このオファー・リスティング・エンジンは、第一および第三者の売り手によって提出されたアイテムを販売するためのオファーリストを受信、記憶、および提供するように構成されたコンピュータシステムである。リスト内の各オファーは、アイテムおよびアイテムの販売に関するさまざまな情報、例えば、アイテム説明、アイテム価格、アイテムの状態、出荷情報、売り手情報などを含む場合がある。さらに、オファー・リスティング・エンジンは、オファーリスティングに関する１つまたは複数の機能、例えば、小売サーバによって実装されたユーザインタフェースを介して受信された入力に基づいて小売サーバによって呼び出し可能な検索機能を実装するように構成されてもよい。例えば、買い手は、小売サーバから検索インタフェースを取り出して、「ラップトップコンピュータ」などのユーザインタフェースの入力フィールドに検索用語を提供することができる。小売サーバは、オファー・リスティング・エンジンに、この検索用語を伝えるように構成されてもよい。オファー・リスティング・エンジンは、オファー・リスティング・データベースを使用して検索する検索機能を実装して、オファーデータベース内の提出された検索用語に関連する全てのアイテムを含むオファーリストを生成することができる。したがって、オファー・リスティング・エンジンは、マーケットプレイスシステムにおける第三者の売り手によってその時点で販売用に提示されているラップトップコンピュータ用のオファーの完全リストを生成するように構成されてもよい。

図２は、本明細書に記載されている種々の実施形態によって生成できるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ：グラフィカル・ユーザ・インタフェース）に表示されたページ２００の一例を示す図である。この特定の例では、説明のために商業サイトの結果ページが使用される。しかし、特に、複数の別個の画像などのコンテンツのインスタンスをある点から別の点に電子的に送信しなければならない場合に、種々の実施形態の範囲および目的の範囲内で、任意の適切なページ、文書、または他の電子オブジェクトが使用可能であることは理解されたい。

図２の例は、本明細書では、一般に「静的」および「動的」タイプと呼ばれる２つのタイプのオブジェクトを含むが、静的部分は本明細書で示すように変化する可能性があり、文字通りに解釈されるべきでないことは理解されたい。図示された商業ウェブページの例では、「静的」部分は、ページ上に他のコンテンツがあっても通常表示される標準的なナビゲーションアスペクト、情報アスペクト、または他のアスペクトを示すページの要素を指す。このような静的要素は、ページ２００用のタイトル、キャプションまたはロゴ２０２、およびナビゲーションアスペクト２０４、ユーザ選択可能なアスペクト２０６を含むことができる。ページのこのバージョンがユーザに対して表示される度に、これらの静的要素、ここでは、ウェブページで使用するのに一般的なＪＰＥＧ画像などの画像が表示される（異なるバージョンは、異なるソフトウェアリリース、異なるユーザ選択またはカスタマイズなどに相当する）。これらの要素は、ウェブサイトの静的部分と見なされ、単一ソースからのものとすることができ、典型的には、ページのロードする速度を改善するためにクライアントマシンのキャッシュ内に記憶される。

この例のページの「動的」部分は、結果セクション内に含まれる要素に相当する。例えば、ユーザは、上述のユーザ選択可能アスペクト２０６の使用といった、電子マーケットプレイスから以前購入した、またはそれ以外の形で消費したアイテムを検索したいと思うかもしれない。その結果、画像やテキストなどのオブジェクトは要求に応答して返されるが、この場合、これらの画像やテキストはユーザによって以前購入された、または別の形で消費された（すなわち、借りられた、またはリースされた）アイテムに相当する。電子環境において要求する方法および結果を返す方法は周知であるので、本明細書では詳細に示さない。この例では、少なくとも４つのアイテムが、ユーザ選択またはクエリに応答して返される。アイテムに相当する結果に含まれるのは、４つの画像２０８、２１０、２１２、２１４であり、各画像は各々のアイテムに対する結果が提示される。スクリーンの解像度やインタフェースのウィンドウサイズなどのインタフェースの制約のために４つの画像のみが示されているが、検索結果の数が増えれば（その数はインタフェースの機能的能力などによって制限されるが）、返される画像は数百、さらには数千も可能である。上述したように、ウェブブラウザのようなインタフェースが、一度に特定のウェブサーバまたはホストに対して２つまたは４つの接続のみが可能であるとする。各々が異なる画像を有する１００個の結果がある場合、同時に４つの接続が確立されても、１つの接続に対して平均で２５個の要求があることになり、これらは順々に処理されなければならず、ひいては、ページ全体のロード時間にかなりの遅延が生じることになる。上述したように複数のホストを使用するような方法が使用されるが、これらの方法は欠点を伴う。

このようなページのロード時間を改善する１つの方法は、インタフェースを実行する装置とコンテンツサーバとの間（またはそれらの間の要素間）で、１つの接続を介して１つの要求を使用してロードされる静的部分の１つの大型画像を作成することである。サイトの基本的な静的要素は長時間にわたってほぼ変化しないので、例えば、標準的な画像編集または画像作成ソフトウェアパッケージを使用して、大型画像を簡単に作成することが可能であり、この画像はインタフェースによって利用されるクライアント装置に送信される。一例では、当業者に周知の簡単なイメージマップを使用して、ユーザ選択の相対座標に基づいてさまざまなアクションを大型画像上に取り込むことができる。このような方法は、大型画像を作成された通りに使用するのに限定され、転送される画像のサイズを小さくするために画像のスペース的な圧縮を可能にするものではない。ページの上部および下部に静的要素がある場合もあるので、画像はページ全体を占めるほど大きいものにしなければならなくなり、画像の「上」に配置される物を制限してしまう場合がある。

別の例では、ＣＳＳ（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）のような技術が使用され、大型画像が複数の小さな画像に「分割」されうる。当業者に周知のように、ＣＳＳスプライト技術は、マスタ画像上でビューポートを使用して、その画像の一部を小さな別個の画像として抽出するものである。本明細書内で使用されるビューポートは仮想ウィンドウまたは選択可能領域を指し、抽出で使用されるビューポートのプロパティを指定することによって画像の一部を抽出するのに使用されうる。一例では、ビューポートの高さおよび幅と共に上方座標と左手座標とが指定され、画像の矩形部分を規定する。マスタ画像の領域を規定するのと同様の方法が、種々の実施形態の範囲内でも使用可能である。ビューポートがマスタ画像の一部で規定されると、ＣＳＳスプライト技術がビューポートの下の画像の一部を有効に抽出し、クライアント装置上で新しい画像を作成する。これらの画像はページ、フレーム、ウィンドウなどの中に要求に応じて位置決めされる。これは、マスタ画像をコピーして、コピー画像の所望の部分にクロッピングすることに類似している。この方法により、サーバ側でナビゲーション要素と他の静的要素とを１つの画像３００に組み合わせてパックして、図３（ａ）に示されるようにマスタ画像のサイズを小さくすることができる。この１つの静的マスタ画像の生成は、例えば、サイトの設計者または他の適切なユーザによって行われる。さらに、この単一画像はユーザ装置のキャッシュに記憶され、ユーザがページを返す時にそのページの画像を再ロードする必要がなくなる。いくつかの実施形態では、マスタ画像はサイトの複数のページまたは全てのページの静的情報を含むことができ、サイトにおけるユーザの位置に関係なく、いずれの静的要素も再要求せずに、単一画像だけがクライアント装置に送信されてクライアント装置でキャッシュされればよいことになる。

ウェブサイトなどのページセットの静止画像の合成はいくつかの利点を有するが、その要素は、典型的には、一定の時間で一度ダウンロードされるだけで、キャッシュに残り、サイトの要求およびロード時間は、全体として少し低減されるだけである。また、この方法は、ユーザが各々のマスタ画像を合成する必要があり、これにはかなりの時間がかかり、さらに、サイトの各ページが適切な画像および座標情報と共に符号化される必要がある。マスタ画像から最も有効である特定のサイトまたはページは、例えば、アイテム説明ページ、検索結果ページ、または多くのコンテンツがほぼ要求時に動的に決定され、クライアントアプリケーションがコンテンツを取得するのに複数の連続した要求を使用する他のページである。

図２に関する上述の例では、ユーザは、サイトを使用してユーザが購入した、またはそれ以外の形で消費した全てのアイテムが表示されているページを選択している。ユーザが例えば、１００個のアイテムを購入した場合、１００個の画像がそのページに別々にダウンロードされなければならない。例えば、ユーザが追加のアイテムを購入する場合のように、ユーザがこのページに数回訪問する間に結果が変わる場合もあるので、ユーザがページに訪問する度に表示されるべき画像は、実際には開発者によって作成されるのは不可能である。また、非常に多くの訪問者があるサイトでは、この方法は大規模なものとなる。

この方法の別の問題は、画像は複数のソースからのものである可能性があることである。いくつかの実施形態は１つの画像サービスまたは画像ソースを利用するが、大型のマーケットプレイス、サイト、または他のコンテンツプロバイダは第三者のソースを含む複数のソースからのコンテンツを使用する場合があり、これらのソースは常に変化する可能性もある。したがって、従来の画像合成方法は、このような環境では役に立たない。

一方、一実施形態のシステムおよび方法は、コンテンツの要求に応答して、画像の動的な合成および抽出を行う。この場合、結果ページまたは他の表示機構に含まれる画像は、要求に応答して決定され、分解および表示のためにクライアントまたは他の装置に送信される前に動的に合成される。例えば、図２は、ユーザ要求に応答してユーザに表示されるべきアイテムに相当する４つの画像２０８、２１０、２１２、および２１４を示す。ウェブサーバまたは他のこのような装置が要求を受信すると、例えば、画像サービスに対する呼び出しにより、これらの４つの画像はウェブサーバに返され、クライアントに送信される。しかし、別々の要求によってこれらの画像を送信するのではなく、画像は図３（ｂ）に示されたような１つのマスタ画像３５０に動的に合成される。画像の記憶サイズを低減するために、個々の画像はマスタ画像の使用されないスペースの量を最小限に抑えるように配置、またはパックされる。

図３（ｂ）の例に見られるように、４つの画像は隙間なくパックされ、１つの「マスタ」画像３５０に合成される。しかし、これらの画像を抽出または分解するために、いくつかの位置情報および／または識別情報も提供しなければならない。例えば、上述したように、ＣＳＳスプライトなどの方法は個々の画像を抽出するのにビューポートを使用する。ページをレンダリングする際に、ページが第３の画像２１２を使用したい場合、ページは、位置情報（例えば、上方および左手の座標）および／またはビューポート寸法情報（dimensional information）（例えば、ビューポートの高さおよび幅）を示す情報（例えば、ページのＸＭＬ文書内に記憶される）にアクセスすることができる。ビューポートの寸法と位置とを規定する２つの対向する座標を使用するといった、画像の位置決めまたは配置に対する他の方法も使用できる。表示される画像が全て同じサイズである場合、寸法情報を決定および／または送信する必要がない。それは、ビューポートのサイズが変わらないので、１つの座標が各画像を抽出するのに十分な情報であるためである。他の実施形態では、画像は共通のサイズに変更され、クロッピングされ、またはそれ以外に修正されるので、同様に寸法情報は必要でない。画像がマスタ画像に合成される前に画像のサイズが変更される場合、寸法情報はマスタ画像から画像を抽出するために、かつ画像を元のサイズに戻すために必要となる。

図３（ｂ）に示されるように、座標情報およびビューポート寸法情報が決定されると、個々の画像が「抽出され」、別々の画像として機能的に処理されるように、ビューポート３５２はマスタ画像３５０内の対象画像２１２に対して位置決めされる。抽出された画像を使用するために、さらに必要に応じて、その後の使用のために画像をキャッシュするために、少なくとも１つの実施形態では、画像用の画像識別子を付与することも望ましい。このことは、特に、共通の画像が１つのページ上で２回以上使用される場合に、画像を正確に配置するのに役立つ。このように、１つのページ上の画像が、例えば、ホストまたはサーバへの接続最大数に相当する１つ、２つ、または４つの画像を使用して送信されて、全ての画像が１つまたは複数の同時要求と平行して有効にダウンロードできることになる。

上述したように、この方法は、ページをロードする際の全体のパフォーマンスを改善することができる。ウェブ環境では、例えば、サーバに対する各々のＨＴＴＰまたは他のクライアント要求は、あるレベルの関連オーバーヘッドを有する。約２ＫＢまたは３ＫＢのサイズの画像を要求する場合、サーバに送信される要求は、画像を取得するのに約１ＫＢの情報を含む場合がある。ダウンロードされる１００個の画像がある場合、この方法は９９ＫＢのアップロードを保存することができる。これは、さらに、クライアントからのアップロードスピードがサーバからのダウンロードスピードより遅い状況で利点がある。また、単に１つの要求または１組の同時要求に対する応答を待てばよいので、先行技術のシステムに見られるような待機順序がなくなる。

少なくともいくつかの場合において、合成される時に、１つの無限定のカラーマップまたは全体がより小さいカラーマップがページ上の全ての画像に使用でき、このことがさらにページに送信されなければならない情報を低減することができるという点で、別の潜在的利点が得られる。全ての画像におけるカラーマップと共に、両方向のＨＴＴＰヘッダを考慮すると、このページを提供するためのネットワーク量をかなり低減できる。

一実施形態では、画像は、まず画像の仮想キャンバスを作成し、その後、個々の画像のビットマップ（または他の非圧縮）バージョンを要求および／または作成することで合成される。次に、画像は適切な順序でキャンバス上に配置され、本明細書で説明したように、パックされてキャンバスのサイズを最小にすることができる。画像が作成されると、カラーマップに対して任意の望ましい変更が実行される、または新しいカラーマップが生成されて、画像はＪＰＥＧまたはＧＩＦ形式などの標準形式に圧縮される。個々の画像の各々に対する座標も記憶される。本明細書内に含まれる教示や提案を踏まえて当業者に明らかなように、使用される画像を解凍、合成、圧縮できる種々のメディアライブラリが存在する。このプロセスは、一例では、この画像を手動で作成するのにかかる時間の代わりに、約数十または数百ミリ秒かかる可能性がある。

いくつかの実施形態では、合成画像を利用するのが有利であるか否かを判断するために、計算が行われる、または閾値が使用される。例えば、１０個以下の画像がある場合、大型画像をダウンロードするために合成プロセスを通して行うのはあまり利点がない。また、個々の画像のサイズや形状が異なるためにキャンバス全体がかなりの量の「デッドスペース」を含む場合には、画像は合成できない場合がある。別の閾値が合成画像の最大のサイズを設定する場合があり、この場合、ページの個々の画像の一部を含む追加のマスタ画像が使用される。

上述したように、コンテンツ配信の方法のための多くのアプリケーションがある。例えば、複数のソースからの結果を返すが、実際にはどのコンテンツも所有またはホストしない検索エンジンは、有利にこの方法を使用する場合がある。広告キャンペーン、交代式バナー広告および多くの他のこのようなアプリケーションもこの方法を利用することができる。さらに、画像が一例として使用されているが、必要に応じて他のタイプの電子コンテンツも使用可能である。

図４は、一実施形態で使用される、配信用コンテンツを合成する例示的方法４００のステップを示す図である。この方法では、ユーザ要求は、クライアント装置４０２から、例えば、パーソナルコンピュータ上のウェブブラウザから受信される。ユーザ要求は、ユーザクエリを生成するのに使用される検索クエリまたはキーワード、用語、または属性などのクエリ情報を含むことができる。明らかであるように、検索クエリは、クライアントが要求を送信することによって、または装置、アプリケーション、もしくは要求を受信するサービス、用語、キーワード、属性などを使用するサービスによって生成される。例えば、ユーザは、電子マーケットプレイスを使用して靴を買おうとする時に、キーワードに「男」と「靴」と入力すると、その用語に一致する検索結果を取得する要求は、これらのキーワードを使用して形成されたクエリを含むか、またはサーバ側の検索クエリに形成される実際のキーワードを含む可能性がある。したがって、クエリは、ユーザが提出したキーワードに限定されないが、例えば、属性ベースのアイテム検索を定義するチェックボックスまたは他の選択機構による選択属性に基づくことができる。例えば、ユーザは、追加のフリー形式のキーワードを提出するかしないかに関わらず、いくつかある属性のうち、特定のブランド、価格範囲、色、種類などの属性に基づいて絞ることによって、アイテムの電子カタログを閲覧することができる。

クエリの受信に応答して、クエリに対して複数の画像を含む結果が決定される（４０４）。画像サービスまたは少なくとも１つの画像データストアから、要求にこたえるのに必要とされる画像が取得される（４０６）。次に、画像は、本明細書で説明または提案された任意の方法を使用して、１つの画像に合成される（４０８）。一例では、画像を解凍し、画像を空白のキャンバスに貼り付けて、得られるマスタ画像を再び圧縮するのに画像ライブラリが使用される。別の実施形態では、合成サービスが使用される場合、種々の画像のパラメータは、例えば、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ：ユニフォーム・リソース・ロケータ）クエリ文字列を使用して渡される。ＵＲＬクエリ文字列は、合成される必要のある画像Ａ、Ｂ、およびＣを指定するために、「？ｐａｒａｍｓ＝ａｂｃ」のような部分を含むことができる。上述したように、画像は、例えば、列、行または矩形状の任意の適切な形でパックされ、デッドスペースを最小にし、または合成されたマスタ画像の全体の記憶サイズを低減するように配置が調節される。当業者に周知のように、多数のパッキングアルゴリズムのうちいずれかが使用される。一実施形態に従って画像を合成するのに使用される１つのサービスは、ＩｍａｇｅＭａｇｉｃｋグラフィック操作ライブラリ（オープンソース）を利用するＲｕｂｙプログラミング言語用のＲＭａｇｉｃｋである。

合成プロセスの時またはその前後で、マスタ画像内の各画像の位置が記憶される（４１０）。これらの位置は、必要となるまでキャッシュまたは他のメモリに記憶される。種々の画像のＩＤも記憶できる。画像がマスタ画像に合成されると、マスタ画像がクライアント装置に送信される（４１２）。さらに、画像の各々の位置情報が、例えば、ＸＭＬ文書のデータの形式または結果ページが画像を表示するための他のデータ構造でクライアント装置に送信される（４１４）。マスタ画像および位置情報はクライアント装置によって受信されると、例えば、ＣＳＳを使用して、個々の画像が抽出されページがレンダリングされる（４１６）。上述したように、さらにマスタ画像を使用してレンダリングされる画像マップを生成するために、位置情報および寸法情報が使用される。他の実施形態は、本明細書内に含まれる技術や提案を踏まえ当業者に明らかなさまざまな技術を使用して、ＸＭＬ文書または画像情報をレンダリングするため他のデータ構造の情報を利用する。

図５は、一実施形態に従って使用できる、マスタ画像を分解しページを作成するための方法５００のステップを示す図である。上述したように。コンテンツの要求が提出される（５０２）。要求に応答して、マスタ画像が受信され（５０４）、それと共にレンダリングされるページのための情報が受信される（５０６）。ページのための情報は、例えば、マスタ画像から個々の画像を抽出するのに必要な情報を含むＸＭＬ文書またはＨＴＭＬ文書を含むことができる。ページ情報を使用して、マスタ画像内の各々の画像に対して位置データが決定される（５０８）。上述したように、位置データは、個々の画像に対応するマスタ画像の領域を決定するのに必要な座標情報および／またはビューポート寸法情報を含むことができる。次に、各々の画像は、位置情報を使用して抽出される（５１０）。上述したように、これには、クライアント装置上に個々の画像を生成するために、ビューポートを使用してマスタ画像の一部を抽出するためのＣＳＳスプライト技術をが含まれる。抽出された画像は、対応する画像識別子に関連付けられ（５１２）、その後、ページをレンダリングするのに使用される（５１４）。大型画像がキャッシュされる場合には、ページが再ロードされる場合に画像を再抽出できるように位置情報も記憶される。

いくつかの実施形態では、合成画像が記憶されている場所のＵＲＬを含むＸＭＬ文書が返されて、必要に応じて合成画像が取り出される。これは、例えば、結果ページを提供するために選択されたウェブサーバ上で行われる。ウェブサーバは、ＸＭＬデータを解析して、新しい合成フォーマットから元の画像へのマッピングを利用する。ページ内の全ての画像タグは、クライアント装置にダウンロードされる合成画像を簡単に参照することができる。マスタ画像は、必要に応じて個々の画像を取得するのにＣＳＳまたは別のこのような技術から呼び出すことができるようにキャッシュに記憶され、サーバに対する次の要求の必要性または合成画像を再び生成する必要性を省くことができる。上述したように、マスタ画像はさらに、例えば、追加ページ、フレーム、またはサイトの一部の画像または要素を記憶することもできる。この場合のトレードオフは、特に、マスタ画像のほんの小さな一部が再利用される場合に、マスタ画像をダウンロードするのに必要な時間およびマスタ画像を記憶するのに必要なメモリに対する画像に入れる情報量である。例えば、複数のページに対してマスタ画像を使用する場合、プログラマまたは他の開発者は、使用される画像の一部の識別子などを認識し、維持しなければならなくなる。

ＣＳＳスプライト技術を利用する一実施形態では、画像は、ＤＩＶ要素などの任意の要素がＣＳＳを参照するクラスセットを有することができるように、バックグランドとして使用できる。この場合、ＣＳＳ.ｉｍａｇｅｃｌａｓｓのようなクラスは、ソースとしてマスタ画像を有することができる。この時、呼び出しは、ＤＩＶビューポートをマスタ画像に対する適切な位置に移動させるために上方および左手のオフセットを指定する。クラスに対する呼び出しは、さらにビューポートを囲む高さと幅を指定する。この方法により、ＣＳＳが組み込まれたＨＴＭＬでページを開発することができるが、画像タグを使用して画像を表示する従来の方法は、画像タグが固有の画像やソース情報を必要とするので、有効でない。

一例では、表示される最も幅の広い画像と同じ幅で、画像が列内にパックされる場合、全ての画像をはめ込むのに十分な高さのキャンバスが作成される。いくつかの実施形態では、分割するために画像間に１つのピクセル空間を設けて、各画像は左寄せされる。この例では、１つのバックグラウンドの画像がアンカー要素に貼り付けられ、新しいＣＳＳクラスがｙ座標だけでバックグラウンド位置をシフトさせる。
#nav Ii a {background-image:url{'../img/image_example.jpg')}
#nav Ii a.first_element {background-position:Opx Opx}
#nav Ii a:viewport.first_element {background-position:Opx -100px}
#nav Ii a.second_element {background-position:Opx -150px;}
#nav Ii a:viewport.second_element {background-position:Opx -175px;}
この例では、２つの画像が「ｆｉｒｓｔ＿ｅｌｅｍｅｎｔ」、「ｓｅｃｏｎｄ＿ｅｌｅｍｅｎｔ」で表わされ、その位置は（ｘ、ｙ）座標で確立され、ビューポートは「ｖｉｅｗｐｏｒｔ」状態のｙ値を適切な高さ（および列の全幅）に調節することによって確立される。バックグラウンドの画像をオフセットするための別の例では、ピクセル位置が既知であるので、状態のみが表示される。
#panel1b a:viewport{background:transparent url(example.gif)0px Opx no-repeat;}
#panel2b a:viewport{background:transparent url(example.gif)-96px Opx no-repeat;}
#panel3b a:viewport{background:transparent url(example.gif)-172px Opx no-repeat;}
#panel4b a:viewport{background:transparent url(exampte.gif)-283px Opx no-repeat;}
第１の値は、左端からの水平オフセット値であり、第２の値は、（上端からの）垂直オフセット値である。この場合、マスタ画像は列ではなく、行に貼り付けされる画像を有するので、各々の垂直オフセット値は等しい。

いくつかの実施形態では、画像の動的合成は、さまざまなユーザ、アプリケーションなどに対するサービスとして提供される。例えば、ネットワークを介して多数の画像を送信するためのアプリケーションはいずれも、動的合成サービスを使用することができる。動的合成サービスは、送信される画像を受信して、画像をマスタ画像に合成し、マスタ画像およびその位置情報を返す（または対象とする受信者に送信する）ことができる。例えば、画像がアプリケーションに返されていない場合、または画像が異なるサイズを有する場合、マスタ画像と共に寸法情報も送信される。いくつかの実施形態では、画像はサービス要求と共に送信されるが、他の実施形態では、ＵＲＬまたは他の位置情報が送信されて、それによりサービスが画像情報を取り出すことができる。この時、サービスは、このサービスと共に使用されるさまざまな方法、例えば、使用回数制料金システム、購買料金システムなどを使用して決済し請求することができる。

動的合成はさらに、多数の領域で行われるのが有利である。それは、複数の画像がネットワークまたは他の接続を介して送信されるアプリケーションまたは実装には動的な画像合成のアスペクトが有効であるためである。本明細書で説明されている例は、電子マーケットプレイスを使用して購入されたアイテムまたは情報を求めるユーザクエリに応答して得られた検索結果などの結果セットと共に多数の画像が表示される時の画像合成の使用について言及している。ユーザが任意の数の画像をアップロード、編集、削除、閲覧できる画像ホスティングサービスのような多くの他のこのようなアプリケーションにも有効である。アイテム検索結果、アイテム提案、個人向けコンテンツ、アイテムアクセサリ、または表示される画像がユーザ要求または閲覧のほぼその時点で決定される任意の他のアスペクトのような商業サイトの種々の他のアスペクトにも有効であり、画像は実際に事前に合成されず、転送は１つまたは少ない数の接続の利点を得られる。特に、多数のサムネイル画像が表示されるインスタンスには、この方法が有効である。

上述したように、いろいろなオペレーティング環境で種々の実施形態を実装することができる。オペレーティング環境の一部の例では、１つまたは複数のユーザコンピュータ、コンピューティング装置、または多数のアプリケーションのうちのいずれかを操作するのに使用される処理装置を含むことができる。ユーザ装置またはクライアント装置は、例えば、標準的なオペレーティングシステムを実行するデスクトップまたはラップトップコンピュータ、またモバイルソフトウェアを実行し、多数のネットワークプロトコルおよびメッセージングプロトコルをサポート可能なセルラー、無線、およびハンドヘルド装置などの多数の汎用パーソナルコンピュータのうちのいずれかを含むことができる。このシステムはさらに、さまざまな市販のオペレーティングシステムのうちのいずれかを実行する多数のワークステーションと、開発およびデータベース管理などのための他の既知のアプリケーションを含むことができる。これらの装置はさらに、ダミー端末、シンクライアント、ゲームシステム、およびネットワーク経由で通信可能な他の装置などの他の電子装置を含むことができる。

ほとんどの実施形態は、ＴＣＰ／ＩＰ、ＯＳＩ、ＦＴＰ、ＵＰｎＰ、ＮＦＳ、ＣＩＦＳ、およびＡｐｐｌｅＴａｌｋなどのさまざまな市販のプロトコルを使用して通信をサポートするために、当業者に周知の少なくとも１つのネットワークを使用する。ネットワークは、例えば、ローカル・エリア・ネットワーク、高域ネットワーク、仮想プライベートネットワーク、インターネット、イントラネット、エクストラネット、公衆交換電話網、赤外線ネットワーク、無線ネットワーク、およびこれらの組み合わせとすることができる。

ウェブサーバを使用する実施形態では、ウェブサーバは、ＨＴＴＰサーバ、ＦＴＰサーバ、ＣＧＩサーバ、データサーバ、Ｊａｖａ（登録商標）サーバ、およびビジネス・アプリケーション・サーバなどのさまざまなサーバまたはｍｉｄ−ｔｉｅｒアプリケーションのうちのいずれかを実行することができる。サーバ（複数可）はさらに、ユーザ装置からの要求に応答して、例えば、Ｊａｖａ（登録商標）、Ｃ、Ｃ♯、Ｃ＋＋、またはＰｅｒｌ、Ｐｙｔｈｏｎ、もしくはＴＣＬなどの任意のスクリプト言語、およびこれらの組み合わせなどのプログラミング言語で書かれた１つまたは複数のスクリプトまたはプログラムとして実装されている１つまたは複数のウェブアプリケーションを実行することによって、プログラムまたはスクリプトを実行することができる。サーバ（複数可）はさらに、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、およびＩＢＭ（登録商標）から市販されているデータベースサーバなどのデータベースサーバを含むことができるが、これらに限定されない。一実施形態では、システムは、開発者が自身のアプリケーション内に商業的に信頼性および利用可能性のある、迅速、拡張可能、トランザクションのデータベースエンジンを組み込むことができる、オープンソースの組み込み可能なデータベースの一種であるＢｅｒｋｅｌｅｙ ＤＢを使用する。

環境は、上述したように、さまざまなデータストア、他のメモリ、記憶媒体を含むことができる。これらはさまざまな場所に位置することができ、例えば、ローカルな（および／または常駐する）、１つまたは複数のコンピュータはネットワークを介して任意のまたは全てのコンピュータからリモート位置にある。特定の組の実施形態では、情報は、当業者に周知の「ＳＡＮ」（ｓｔｏｒａｇｅ−ａｒｅａ ｎｅｔｗｏｒｋ：記憶領域ネットワーク）に位置することができる。同様に、コンピュータ、サーバ、または他のネットワーク装置による機能を実行するための任意の必要なファイルは、必要に応じて、ローカルにおよび／またはリモートに記憶されてもよい。システムは、コンピュータ装置を含み、各々の装置は、バスを介して電子的に結合されたハードウェア要素、例えば、少なくとも１つのＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：中央処理ユニット）、少なくとも１つの入力装置（例えば、マウス、キーボード、コントローラ、またはキーパッド）、少なくとも１つの出力装置（例えば、表示装置、プリンタ、またはスピーカ）などの要素を含むことができる。また、このシステムは、ディスクドライブ、光学式記憶装置、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ：ランダム・アクセス・メモリ）またはＲＯＭ（ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ：リード・オンリ・メモリ）などの固体記憶装置、取り外し可能な媒体装置、メモリカード、フラッシュカードなどの１つまたは複数の記憶装置を含んでもよい。

この装置はさらに、コンピュータ可読記憶媒体リーダ、通信装置（例えば、モデム、ネットワークカード（無線または有線）、赤外線通信装置など）、上述したようなワーキングメモリを含むことができる。コンピュータ可読記憶媒体リーダは、リモート、ローカル、固定、および／または取り外し可能な記憶装置、さらに、コンピュータ可読情報を一時的に、および／またはより永続的に含み、記憶し、送信し、取り出すための記憶媒体であるコンピュータ可読記憶媒体に接続される、またはそれを受信するように構成される。また、システムおよび種々の装置は、典型的には、多数のソフトウェアアプリケーション、モジュール、サービス、または少なくとも１つのワーキングメモリ装置内に位置する他の要素、例えば、オペレーティングシステム、およびクライアントアプリケーションまたはウェブブラウザなどのアプリケーションプログラムを含むことができる。代替の実施形態は、上述した内容によると非常に多くの変形形態を有することを理解されたい。例えば、カスタマイズハードウェアが使用される場合もあるし、および／または特定の要素がハードウェア、ソフトウェア（アプレットのような携帯型ソフトウェアなど）、またはその両方に実装される場合もある。さらに、ネットワーク入出力装置などの他のコンピューティング装置への接続がなされてもよい。

記憶媒体およびコードまたはコードの一部を含むコンピュータ可読媒体は、当分野で周知または使用されている適切な媒体を含むことができる。これには、例えば、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶および／または送信するための方法または技術で実装された揮発性および不揮発性、取り出し可能および取り出し不可能な媒体などの記憶媒体および通信媒体であり、例えば、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ：デジタル多用途ディスク）もしくは他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または所望の情報を記憶し、システム装置によってアクセス可能な任意の他の媒体が挙げられるが、これらに限定されない。本明細書で示された開示および教示に基づいて、当業者は種々の実施形態を実装する他の手段および／または方法を理解するだろう。

したがって、明細書および図面は、限定的ではなく例示的なものとする。しかし、請求項で説明されるような本発明の広範な精神および範囲から逸脱せずに、これらに種々の修正や変更が加えられてもよいことは明らかであろう。

Claims (23)

1. 実行可能命令とともに構成された１つまたは複数のコンピュータシステムの制御下で、ウェブページを作成する際に使用する画像を配信するためのコンピュータで実装された方法であって、
   ホストにより、クライアント装置上のウェブブラウザからの要求を受信するステップと、
   前記要求の受信に応答して、少なくとも、前記ウェブブラウザを介して表示されるウェブページを作成する際に使用される複数の画像を決定するステップと、
   前記複数の画像の第１の部分を第１のマスタ画像に合成し、前記複数の画像の少なくとも１つの更なる部分を少なくとも１つの更なるマスタ画像に合成するステップであって、前記マスタ画像の合計数は、前記クライアント装置と前記ホストとの間の許容された同時接続の最大数に少なくとも部分的に制限されるステップと、
   前記マスタ画像の各々について、前記マスタ画像に関連する前記複数の画像の前記組み合わされた部分内の各々の画像のための位置情報および寸法情報を少なくとも記憶するステップと、
   前記マスタ画像と、前記位置情報と、前記寸法情報とを、前記クライアント装置に、少なくとも部分的に同時に提供することにより、コンテンツ配信時間を減少させるステップであって、前記クライアント装置上のＣＳＳ（ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）スプライトモジュールは、前記要求に応答して前記ウェブブラウザ内に表示される前記ウェブページを作成するために、前記位置情報および前記寸法情報を利用して、各々のマスタ画像内の前記複数の画像の各々を配置および抽出することが可能であることを特徴とするステップと
   を特徴とするコンピュータで実装された方法。
2. 各々のマスタ画像について、前記ＣＳＳスプライトアプリケーションは、前記マスタ画像に対して少なくとも１つのビューポートを形成するために前記位置情報および前記寸法情報を利用し、それに従って、前記少なくとも１つのビューポートが移動およびサイズ変更されて、前記マスタ画像内の前記複数の画像のいずれかを表示のために抽出することができることを特徴とする、請求項１に記載のコンピュータで実装された方法。
3. 前記複数の画像の部分集合を合成する前に、前記決定された複数の画像を複数のソースから取り出すステップをさらに含むことを特徴とする、請求項１に記載のコンピュータで実装された方法。
4. 実行可能命令とともに構成された１つまたは複数のコンピュータシステムの制御下の電子環境において、画像を送信するためのコンピュータで実装された方法であって、
   クライアント装置からのコンテンツに対する要求のホストによる受信に応答して、少なくとも、前記コンテンツに関連付けられた複数の画像を決定するステップと、
   前記複数の画像の第１の部分を第１のマスタ画像に合成し、前記複数の画像の少なくとも１つの更なる部分を少なくとも１つの更なるマスタ画像に合成するステップであって、前記マスタ画像の合計数は、前記クライアント装置と前記ホストとの間の許容された同時接続の最大数により少なくとも部分的に制限されるステップと、
   前記マスタ画像の各々について、前記マスタ画像に関連する前記複数の画像の組み合わされた部分内の各々の画像の位置情報を少なくとも記憶するステップと、
   コンテンツのための前記要求に応答して前記合成されたマスタ画像と前記記憶された位置情報とを少なくとも部分的に同時に提供することにより、コンテンツ配信時間を減少させるステップであって、前記複数の画像の各々は前記提供された位置情報を使用して抽出可能であることを特徴とするコンピュータで実装された方法。
5. 各々のマスタ画像について、位置情報を記憶するステップは、前記マスタ画像内の前記画像の位置に対応する前記マスタ画像の前記複数の画像の各々の座標で決定するステップを含むことを特徴とする請求項４に記載のコンピュータで実装された方法。
6. 前記複数の画像の各々の寸法情報を記憶するステップをさらに含み、前記寸法情報は、前記複数の画像の各々を抽出する際に使用するために前記位置情報と共に提供できることを特徴とする請求項４に記載のコンピュータで実装された方法。
7. 前記複数の画像の各々は、前記マスタ画像の１つの中で、提供されることを特徴とする請求項４に記載のコンピュータで実装された方法。
8. 前記要求されたコンテンツを表示するために使用されるインタフェースの一部に関する別個の複数の画像を決定するステップと、
   前記別個の複数の画像を別個のマスタ画像に合成し、前記要求に応答して前記別個のマスタ画像を提供するステップであって、それにより、前記別個の複数の画像を抽出及び使用し、前記インタフェースの少なくとも一部を生成することができる、ステップと
   をさらに含むことを特徴とする請求項４に記載のコンピュータで実装された方法。
9. 前記マスタ画像の少なくとも１つのために、前記マスタ画像と前記位置情報とを使用して画像マップを生成するステップをさらに含み、前記位置情報は、前記マスタ画像内の前記複数の画像の各々に対するマッピングを決定するのに使用されることを特徴とする請求項４に記載のコンピュータで実装された方法。
10. 前記複数の画像を合成する前に、複数のソースから決定された前記複数の画像を取り出すステップをさらに含むことを特徴とする請求項４に記載のコンピュータで実装された方法。
11. 前記コンテンツは、電子マーケットプレイスを介して消費されるアイテムに関することを特徴とする請求項４に記載のコンピュータで実装された方法。
12. 前記マスタ画像の少なくとも１つは、前記コンテンツに関する複数のページを作成する際に使用するための１つ又は複数の画像を含むことを特徴とする請求項４に記載のコンピュータで実装された方法。
13. 前記マスタ画像のキャンバスサイズを最適化するために、前記マスタ画像の少なくとも１つ内の前記複数の画像の各々の位置を決定するステップをさらに含むことを特徴とする請求項４に記載のコンピュータで実装された方法。
14. 前記マスタ画像の少なくとも１つについて、前記マスタ画像の記憶サイズを低減するために、前記マスタ画像の新しいカラーマップを生成するステップをさらに含むことを特徴とする請求項４に記載のコンピュータで実装された方法。
15. 前記マスタ画像と前記位置情報とをキャッシュするステップをさらに含み、それにより前記複数の画像がほぼ同じコンテンツに対する後続の要求に応答して再合成される必要がないことを特徴とする請求項４に記載のコンピュータで実装された方法。
16. 実行可能命令とともに構成された１つまたは複数のコンピュータシステムの制御下で、検索結果を提供するためのコンピュータで実装された方法であって、
    ホストにより、クエリ情報を含む要求をクライアント装置から受信するステップと、
    前記クエリ情報に対応する検索結果セットであって、複数の画像を含む前記結果セットを決定するステップと、
    前記複数の画像の第１の部分を第１のマスタ画像に合成し、前記複数の画像の少なくとも１つの更なる部分を少なくとも１つの更なるマスタ画像に合成するステップであって、前記マスタ画像の合計数は、前記クライアント装置と前記ホストとの間の許容された同時接続の最大数に少なくとも部分的に制限されるステップと、
    前記マスタ画像の少なくとも１つに関連する前記複数の画像の各々の位置情報を記憶するステップと、
    前記要求に応答して、前記マスタ画像、前記位置情報および前記検索結果セットに関する情報とを少なくとも部分的に同時に提供することにより、コンテンツ配信時間を減少させるステップであって、それにより前記複数の画像の少なくとも一部を含む検索結果ページを作成するために、前記位置情報を使用して、前記複数の画像の各々を抽出できる、ステップと
    を含むことを特徴とするコンピュータで実装された方法。
17. 前記マスタ画像、前記位置情報、および前記検索結果セットに関する情報のキャッシュを提供するステップであって、それにより検索結果の複数の別個のページを介して前記複数の画像を抽出できる、ステップをさらに含むことを特徴とする請求項１６に記載のコンピュータで実装された方法。
18. 前記マスタ画像のキャンバスサイズを最適化するために、前記マスタ画像の少なくとも１つ内の前記複数の画像の各々の位置を決定するステップをさらに含むことを特徴とする請求項１６に記載のコンピュータで実装された方法。
19. 電子環境で画像を配信するためのシステムであって、
    プロセッサと、
    前記プロセッサによって実行される時に、前記プロセッサに、少なくとも
    ホストによるコンテンツに対する要求の受信に応答して、前記要求されたコンテンツに関連付けられた複数の画像を決定させ、
    前記複数の画像の第１の部分を第１のマスタ画像に合成し、前記複数の画像の少なくとも１つの更なる部分を少なくとも１つの更なるマスタ画像に合成するステップであって、前記マスタ画像の合計数は、前記ホストとの許容された同時接続の最大数に少なくとも部分的に制限されるステップと、
    前記マスタ画像の少なくとも１つに関連する前記複数の画像の各々の位置情報を記憶させ、
    コンテンツについての前記要求に応答して、前記マスタ画像と前記位置情報とを少なくとも部分的に同時に提供することにより、コンテンツ配信時間を減少させるステップであって、それにより前記位置情報を使用して前記複数の画像の各々を抽出できるようにする
    命令を含むメモリ装置と
    を備えることを特徴とするシステム。
20. 前記メモリ装置は、前記プロセッサによって実行される時に、前記プロセッサに、少なくとも、
    前記マスタ画像のキャンバスサイズを最適化するために、前記マスタ画像の少なくとも１つ内の前記複数の画像の各々の位置を決定させる命令をさらに含むことを特徴とする請求項１９に記載のシステム。
21. 前記メモリ装置は、前記プロセッサによって実行される時に、前記プロセッサに、
    前記マスタ画像の記憶サイズを低減するために、前記マスタ画像の少なくとも１つの新しいカラーマップを生成させる命令をさらに含むことを特徴とする請求項２０に記載のシステム。
22. 電子環境において、画像を配信するための、コンピュータ可読記録媒体であって、
    コンテンツに対する要求の受信に応答して、前記要求されたコンテンツに関連付けられた複数の画像を決定するためのプログラムコードと、
    前記複数の画像の第１の部分を第１のマスタ画像に合成し、前記複数の画像の少なくとも１つの更なる部分を少なくとも１つの更なるマスタ画像に合成するプログラムコードであって、前記マスタ画像の合計数は、許容された同時接続の最大数に少なくとも部分的に制限されるプログラムコードと、
    前記マスタ画像の少なくとも１つに関連する前記複数の画像の各々の位置情報を記憶するためのプログラムコードと、
    前記要求に応答して、前記マスタ画像と前記位置情報とを少なくとも部分的に同時に提供することにより、コンテンツ配信時間を減少させるプログラムコードであって、それにより前記位置情報を使用して前記複数の画像の各々を抽出できるようにするためのプログラムコードとを含むことを特徴とするコンピュータ可読記録媒体。
23. 前記マスタ画像のキャンバスサイズを最適化するために、前記マスタ画像の少なくとも１つ内の前記複数の画像の各々の位置を決定するためのプログラムコードをさらに含むことを特徴とする請求項２２に記載のコンピュータ可読記録媒体。

Images