JP2004518218A - マルチメディア・コンテンツを動的に最適化してネットワーク配信する方法及び装置 - Google Patents

Abstract

本発明は、適切な特性を備えた画像又はその他のマルチメディア・データを、ネットワークを介して効率的に伝送することに関する。ネットワーク化されたサーバに存在するオリジナル・ソースの画像データ又はその他のマルチメディア・データは、最適な伝送に適した特性を備えていないこともある。本発明は、オリジナル・ソースの画像データ又はその他のマルチメディア・データを、適切に特徴付けされたデータに「急いで」変換する方法について説明する。伝送するのに望ましい画像又はその他のマルチメディア・データを含むネットワーク化されたシステムの管理者は、効率的に伝送するにはその画像又はその他のマルチメディア・データがどのような特性を所有しなければならないかということに関して、ルールを適用することができる。本発明は、その画像又はその他のマルチメディア・データ要求に伴う条件を分析し、その画像データ又はその他のマルチメディア・データが含むべき特性を決定し（４６）、それらの特性を所有する画像又はその他のマルチメディア・データが既にレンダリングされてメモリキャッシュ（５０）に格納されているかどうかを確認し、格納されていない場合には、オリジナル・ソースの画像又はオリジナル・ソースのマルチメディア・データを変換エンジンに送信する。この変換エンジンにおいて、このソース画像又はその他のマルチメディア・データは、正しい特性を所有する画像又はその他のマルチメディア・データに変換されて（５２）、効果的に伝送される。本発明は、マルチメディア・データ要求において遭遇する条件の多くを処理することのできる、予め決定されたセットのデフォルト・ルールを、ネットワーク管理者に使用可能とする。

Description

【０００１】
【発明の属する技術分野】
本出願は、米国特許法第１１９条（ｅ）項に基づいて、２００１年１月２６日に出願された「イメージングサービスのためのネットワーク・サーバ・アプライアンス（ＮＥＴＷＯＲＫ ＳＥＲＶＥＲ ＡＰＰＬＩＡＮＣＥ ＦＯＲ ＩＭＡＧＩＮＧ ＳＥＲＶＩＣＥＳ）」という名称の米国仮特許出願番号第６０／２６４，３３９号の優先権を主張する。この仮特許出願は、参照によりその全体が本明細書中に組み込まれる。
【０００２】
本発明は、デジタル・マルチメディア・コンテンツ処理システムに関する。マルチメディア・コンテンツ・レンダリングサーバ方法及びその装置について説明する。
【０００３】
【従来の技術及び発明が解決しようとする課題】
インターネット又はその他のネットワークにアクセスするのにどのようなデバイスを用いるかに関係なく、マルチメディア・コンテンツを効率的且つ確実に配信することは、感覚（ｅｘｐｅｒｉｅｎｃｅ）に対し極めて重要なものである。しかしながら、Ｗｅｂ又はその他のネットワークに対して視覚的に魅力のあるコンテンツを配信することは、フォーマット、言語、ネットワーク制約、及びデバイス性能の種類が多くなるのに伴い、ますます困難になってきている。企業の中には、各目的デバイスに対して特別にデザインした複数のＷｅｂサイトを作成する企業もある。各Ｗｅｂサイトは、出力を完全に制御しつつ、変更が生じた際には個別に更新されなければならない。テキストが変更を必要とするだけでなく、何千もの画像及びその他のマルチメディア・コンテンツが、特定サイズ及びフォーマットに対する編集を必要とする。さらに、同じ画像又はその他のマルチメディア・コンテンツの複数コピーが蓄積されると、費用のかかる記憶空間が急速に消費されてしまう。これにより、結果として、コストと時間のかかる方法となる。
【０００４】
本発明は、企業、コンテンツ作成者、及びサービス提供者が、画像又はその他のマルチメディア・コンテンツを、インターネット又はその他のネットワークを介して、動的に最適化して配信することのできる、強固で、スケーラブルで、確実なインフラストラクチャ・ソリューションを提供する。この技法を用いることによって、企業は、ネットワーク性能を向上させつつ、最適化された画像又はその他のマルチメディア・コンテンツを、あらゆるデバイスに配信することができる。
【０００５】
進歩したワイヤレス・ネットワーク技術が公開されることによって、携帯電話及び携帯情報端末のようなＷｅｂ対応機器への配信が促進されてきた。しかしながら、この技術自体が障壁ともなり得る。フォーマット、マークアップ言語、デバイス性能、及びネットワーク制約が異なると、モバイル・コンピューティングの展望が制限されてしまう恐れがある。多くの場合、デバイスが処理しにくかったり、接続が悪かったり、ワイヤレス・フォーマットが異なったりすると、ユーザ感覚の質が低下することとなった。これにより、幅広い利用が妨げられてきた。しかしながら、携帯電話が圧倒的に有力なインターネット接続機器である国もある。現在では、３３００万人を超えるモバイル・インターネット・ユーザがいる。このようなモバイル・インターネット・アクセスの急増によって、Ｗｅｂサイトのデザイン及び配信が、著しく複雑となってきた。好適な選択肢としては、本来ＰＣに対してデザインされたＷｅｂページを、モバイル機器に対して必要とされる異なるマークアップ言語に変換する、コンテンツ管理又は専用コード変換システムを利用するのがよい。これらのソリューションは、一般的には、以下の変換のうちの１種類以上を行う。
・ＨＴＭＬからコンパクトＨＴＭＬ（ｃＨＴＭＬ）への変換
・ＨＴＭＬからワイヤレス・マークアップ言語（ＷＭＬ）への変換
・ＨＴＭＬから携帯機器・マークアップ言語（ＨＤＭＬ）への変換
【０００６】
コンテンツ管理又はコード変換システムを利用すれば、市場に出すまでにかかる時間を改善することができ、分離した接続されていないサイトを最初から構築するよりもコスト効率がよいであろう。更新及び変更は、複数のサイトにわたって自動的に伝播する。しかしながら、ヒューリスティックス法に基づいた自動変換は、許容可能な結果をもたらすことがほとんどなく、変換が不十分な箇所では、プログラミングが必要とされる。さらに、これらのソリューションは、Ｗｅｂサイトのテキストに焦点を当てており、画像又はその他のマルチメディア・コンテンツには焦点を当てていない。テキスト部分のみが変換されるため、Ｗｅｂ製作スタッフには、依然として、非常に多数の画像又はその他のマルチメディア・コンテンツを、場合によってはデバイスタイプごとに、手動で編集して格納する負担がかかる。
【０００７】
サービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）とは、高品質のユーザ感覚を意味し、ネットワーク・コンテンツ配信における待ち時間の短さで判定される。例えば、Ｗｅｂサイト製作者及びＩＴ専門家は、興奮するような視覚的コンテンツと許容可能なＷｅｂ性能とのトレードオフに常に取り組んでいる。最も視覚的に素晴らしいＷｅｂサイトであっても、きちんと機能しなければ、サイト訪問者を追い払うことになってしまう。もし全てのユーザの接続速度と表示性能が同じであれば、Ｗｅｂサイトははるかに容易にデザインされたであろう。しかしながら、ワイヤレス、ＤＳＬ、ケーブル、ＬＡＮ、及びダイアルアップ接続は全て、異なる速度及び信頼性レベルで作動する。ほとんどのワイヤレス接続のデータ伝送速度は限定されたバンド幅のものであり、その性能は非常に予測不可能なものである。従って、様々なタイプのネットワーク接続のニーズを満たすように動的に適応することのできる、コード変換システムが必要とされている。これにより、高バンド幅接続に対しては、より高品質で豊富なコンテンツを生成することができる一方で、より低速のモデム又はワイヤレス・ネットワーク接続に対しては、より小さくより低品質のコンテンツを生成することができる。
【０００８】
現在のサーバシステムは、主に、ＩＩＰ（インターネット・イメージング・プロトコル（Ｉｎｔｅｒｎｅｔ Ｉｍａｇｉｎｇ Ｐｒｏｔｏｃｏｌ））に基づいている。クライアント（一般的には、Ｗｅｂブラウザ）は、ＩＩＰを用いて、特定解像度の画像を要求する。サーバは、その所望の解像度でピクセルを生成して、クライアントに戻す（ＪＰＥＧ又はＦｌａｓｈＰｉｘ（登録商標）としてパッケージ化）。また、クライアントは、ＩＩＰを用いて、１セクション（又はタイル）の画像を特定の解像度で要求することもできる。これにより、ユーザは、Ｗｅｂブラウザを介して、その写真をパンするか又は拡大縮小することができる。（拡大縮小／パン／解像度処理された）画像の特定部分は、ＵＲＬ要求内にコード化されたコマンドを介して要求される。これには、画像のセクション（タイル）及び特定の解像度が含まれる。クライアント・ブラウザは、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ／ＤＨＴＭＬ又はＪａｖａ（登録商標）を用いて、必要な画像データを要求するコードを（コード化されたＵＲＬストリングを介して）実行する。
【０００９】
ＩＩＰと本発明は両方とも、Ｗｅｂ上において画像を見る際のユーザ感覚を向上させるが、これらは、それぞれ異なる方法で問題に対処し、２つの異なる問題を解決する。ＩＩＰは、主に、ユーザがＷｅｂページ上の画像と交信できるようにするのに用いられる。本発明は、画像データ又はその他のマルチメディア・コンテンツの生成及び配信を動的に（且つ自動的に）最適化するのに用いられる。あまりにも多くのネットワーク・リソースが要求されるので、Ｗｅｂサイト上の全ての画像に対しＩＩＰを用いるのは困難であろう。ＩＩＰは、ユーザが画像と交信できるようにすることにおいては適切な処理を行うが、これは複雑なソリューションである。この機能性を可能にするには、さらにＨＴＭＬ／Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ／Ｊａｖａ（登録商標）コードを開発して、Ｗｅｂページに追加しなければならない。さらに、この追加コードは、クライアントにおいて実行されなければならない。
【００１０】
ＩＩＰは、ＪＰＥＧ又はＦｌａｓｈＰｉｘ（登録商標）画像の一部をクライアントに提供することに焦点が当てられている。一般的には、何らかのマスタＪＰＥＧ又はＦｌａｓｈＰｉｘ（登録商標）画像が常に使用可能な状態であり、これが画像のより小さな部分を提供する方法である。これは、本発明のいくつかの点に関しても同様である。しかしながら、恐らくＪＰＥＧ及びＦｌａｓｈＰｉｘ（登録商標）（これらは、内面的に非常に似ており、ＤＣＴベースで圧縮されている）間を除いては、コード変換は行われない。
【００１１】
本発明に関する別の利点は、ユーザのネットワーク／システムに容易に組み込むことができる点である。例としてインターネットを用いた場合、ユーザのＷｅｂサイトに対しては、小さな変更のみが要求される。さらに、本発明によれば、画像又はその他のマルチメディア・コンテンツの生成方法を指示するルール及び条件を変更することによって、ユーザのＷｅｂサイトを変更することなく、将来的な変更が容易に可能となる。
【００１２】
Ｗｅｂは、商業（コマース）、通信、及びリサーチの重要なチャネルとして認識されている。Ｗｅｂサイトは、事業効率をもたらすのに加えて、企業がその顧客、求職者、共同経営者、及び投資者と行うことの多い、最も緊密な交信をしばしば提示することができる。これにより、画像の使用による肯定的な印象は、Ｗｅｂサイトのデザイン及びコンテンツの作成を支援する重要な力となってきた。
【００１３】
ニュース又はメディア部門におけるような多数のＷｅｂサイトは、競争力を保ち、ニュースが起き次第それを提供するために、１日に数回、新しい画像又はその他のマルチメディア・コンテンツを提供しなければならない。ｅコマース・サイトは、日常的に新製品画像を追加し、何百又は何千もの写真及び画像を用いた製品カタログを維持する。
【００１４】
特に、画像は、一般的には、ニュース電信、データ・フィード、ＣＤ−ＲＯＭ、デジタルカメラ、又は、スクラッチから作成されたデジタル・スキャン若しくは画像から取得される。これにより、オリジナル画像は、様々なファイル・フォーマット、サイズ、及び解像度で届く。Ｗｅｂ又はその他のネットワーク製作スタッフは、Ａｄｏｂｅ（登録商標）やＰｈｏｔｏＳｈｏｐ（登録商標）のようなツールを用いて、これらの写真をそれぞれ、公開する前に手動で編集しなければならない。最低限、画像のコピーは、オリジナル画像と公開画像の２つ、格納しなければならない。画像の「サムネイル」及び「拡大」バージョンを提供するサイトによって、この数は増え、異なるデバイス及び接続タイプに対処しようとするＷｅｂサイトによって、この数はさらに一層増える。
【００１５】
【課題を解決するための手段】
本発明は、コンピュータ・ネットワークを介して、最適化されたマルチメディア・コンテンツを配信することに関する。このタスクを行う方法は、マルチメディア・コンテンツ・サーバシステムと呼ばれるコンピュータ・システムを用い、このシステムは、マルチメディア・コンテンツ要求に伴ういくつかの条件を分析することができる。これらの条件が分類されると、このマルチメディア・コンテンツ・サーバシステムは、オリジナル・ソースのマルチメディア・コンテンツ（「マスタ」・コンテンツ）特性（特に、サイズ、及び必要とされる内容量）を変更して、オリジナル・ソースのマルチメディア・コンテンツの代わりに、この変更したマルチメディア・コンテンツを要求者に送信することができる。処理することのできるマルチメディア・コンテンツのタイプの例として画像を用いると、要求者のＰＣへの配信が要求された画像は、要求者の携帯電話によって要求された画像よりも、かなり大きくなり、より多くの画像内容を含むことができる。本発明は、どのようなタイプのデバイスがその画像を要求しているかを判定し、その画像を適切に変更することができる。配信される必要のある画像の特性は、要求時にネットワークがどのぐらい混雑しているかによって決定することもできる。より大きく内容のより多い画像は、より小さく内容のより少ない画像よりも、配信するのに時間がかかる。ネットワーク負荷が高い時間には、より小さく内容のより少ない画像を送信するのが、恐らくより効率的であろう。また、このイメージング・サーバシステムは、特定の画像を複数の位置に格納することもでき、これらの位置それぞれにはその特定の画像が含まれているが、各画像は異なる特性を備えている。画像要求が受信され、この要求に伴う条件が、その画像が伝送前に所有するべき特定セットの特性を要求する場合、これらの格納されている画像を探索することによって、その特性を備えた画像が既に存在するかどうかを判定することができ、存在する場合には、その画像が伝送される。正しい特性を所有する画像がない場合には、イメージングエンジンに、オリジナル・ソース画像を用い、それを適切な特性を備えた画像に変換し、その画像を要求者に伝送するように要求することができる。次に、この伝送された画像は、（キャッシュに格納された）メモリに格納（記憶）されて、その特性を備えた画像を要求する他のいずれの要求に対しても使用可能とされる。このイメージング・サーバシステムは、要求時にどのような条件が効果を有しているか（これは、用いられるユーザ・インタフェースによって決まる）によって、どのような特性を画像が所有するべきかということに関するルールを有することができる。条件に基づいた特性が一旦設定されると、これらの特性は、使用可能とされた同じユーザ・インタフェースを用いて、後で変更することができる。
【００１６】
多くの実施例は、ワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）（Ｗｅｂ）に基づいたインターネットを用いるが、このシステムは、いずれのタイプのネットワークを介して配置されてもよい、ということは明らかである。このサーバシステムを利用することのできるマルチメディアのタイプは、画像だけではない。本発明は、音声、映像、及び複合メディアの配信要求にも適用される。本発明のこれらの及びその他の利点は、以下の詳細な説明を読み、図面の様々な形態を検討すれば、明らかとなるであろう。
【００１７】
【発明の実施の形態】
本発明は、強力なプラグ・アンド・プレイ型のマルチメディア・コンテンツ・サーバシステムを用い、このサーバシステムは、画像又はその他のマルチメディア・コンテンツを動的に作製して最適化し、あらゆるＷｅｂ対応機器又はその他のネットワーク対応機器へ配信する。本発明は、既存のネットワーク・インフラストラクチャとシームレスに（継ぎ目なしに）統合するスケーラブルなサーバ・アプライアンス（装置）において、画像又はその他のマルチメディア・コンテンツのワークフローを合理化し、コストを削減し、サイト性能を最適化する。例として画像を用いる、本発明を実施するための最良の形態では、各画像を綿密にサイズ変更又はフォーマットしてネットワーク製作要件を満たす必要がない。本発明の好適な実施形態は、オリジナル画像を所望の解像度、サイズ、及びフォーマットに自動的に変換することによって、ネットワーク・サイト製作コストを大幅に削減する。デバイスが画像を要求すると、そのオリジナル画像がアクセスされて、要求元のクライアントのページ、デバイス、及び関連データ伝送速度要件を満たすように動的に変換される。
【００１８】
事実上、本発明は、ネットワーク上のＷｅｂサーバに備わり、一般的にはサーバ・アプライアンスとしてパッケージ化される、サーバシステムである。一般的なネットワーク構造では、サーバが、ネットワーク・サイトに対する画像又はその他のマルチメディア・コンテンツ要求のほとんどを処理する。本発明の画期的な態様のうちの１つは、マルチメディア・コンテンツが、ネットワークの作成者によって定義されたルールに基づいて「オンデマンド」で作成される、というものである。
【００１９】
マルチメディア・コンテンツのあらゆるデバイスへの配信
企業の主な課題のうちの１つに、あらゆるデバイスに対してマルチメディア・コンテンツを作成して配信するというものがある。本発明は、例えば、オリジナル画像を所望のサイズ及びフォーマットに変換することのできる変換エンジンを提供することによって、この課題に応えている。画像は、ＩＴ又はＷｅｂスタッフによって作成された１セットのルールに基づいて変換される。例えば、本発明のイメージング・サーバシステムの一実施形態は、オリジナルの高解像度ＴＩＦＦ画像を、以下のようなデバイスに合わせて変換することができる。
・ＰＤＡ：２５６色、１６０×１６０、５ｋ最適化ＪＰＥＧ
・携帯電話：２５６色、８０×１００、５ｋ最適化ＧＩＦ
・ブロードバンド接続ＰＣ：２４ビット色、８００×６００、７５ｋ最適化ＰＮＧ
【００２０】
このイメージング・サーバシステムは、コンテンツ管理又はコード変換ソリューションと共に用いることによって、ネットワークテキストと画像の両方をあらゆるデバイスに配信することができる。このような構造によれば、新しいインターネット又はその他のネットワークアクセス方法のニーズを満たすようにデザインされたコンテンツを迅速に公開することができる。本質的には、本発明は、「将来保証型の」Ｗｅｂサイト又はその他のネットワーク化システムを支援する。このイメージング・サーバの実施形態を用いるＷｅｂサイトに関しては、次のような手順が行われる。
１．クライアント・ブラウザがＷｅｂページを要求すると、画像要求は全て、イメージング・サーバシステムに送られる一方で、Ｗｅｂサーバが、テキストの要求とサーバ側ビジネス論理の実行とを処理する。
２．イメージング・サーバシステムは、要求がその画像に対して初めてのものであるか、或いは、その画像が以前に要求されたことがあるかを判定する。
３．その画像が既に要求されたことがある場合、キャッシュが、その画像をクライアント・ブラウザに配信する。
４．その画像が以前に要求されたことがない場合、イメージング・サーバシステムは、オリジナル・ソース画像とシステムのレンダリングエンジンとを読み出して、その画像を適切なフォーマットに動的に変換する。
５．変換されると、その画像は、イメージング・サーバ・キャッシュに配置され、要求元のクライアントに配信される。
【００２１】
マルチメディア・コンテンツの作成は、時間と労力のかかる処理であり、市場に出すまでにかかる時間に悪影響を与え得ることは、明らかである。
【００２２】
本発明のイメージング・サーバの実施形態は、オリジナル画像をサムネイル・ビュー、ミディアム・ビュー、及びラージ・ビューに動的に変換することができると共に、その画像をＰＣダイアルアップ接続及び３つの携帯電話上に表示するためにサイズ変更することができる。サイトは、コアＷｅｂ又はその他のネットワーク・アプリケーション・サーバから画像を提供する代わりに、この責務をコスト効率よくイメージング・サーバにオフロードして、そのスケーラビリティを著しく高めることができる。より高いトラフィック・ニーズを処理するために、画像サーバのクラスタは、互いにシームレスに通信するように構成することによって、作製した画像のキャッシュを分散し、フェイルオーバー及び高アベイラビリティをもたらすことができる。サーバ・デマンド・ルールは、画像提供処理をＷｅｂサイトからオフロードすることができるのに加えて、ピーク負荷時間にはより小さい画像を提供することによって、バンド幅の使用を最適化することができる。
【００２３】
このイメージング・サーバシステムによって、Ｗｅｂ又はその他のネットワーク製作スタッフは、オリジナル画像を使用可能とすることだけを必要とする。このイメージング・サーバシステムの実施形態は、オリジナル画像をサムネイル・ビュー、ミディアム・ビュー、及びラージ・ビューに動的に変換すると共に、その画像をＰＣダイアルアップ接続及び３つの携帯電話上に表示するためにサイズ変更する。従って、サイトは、コアＷｅｂ又はその他のネットワーク・アプリケーション・サーバから画像を提供する代わりに、この責務を効率的にイメージング・サーバシステムにオフロードして、そのスケーラビリティを著しく高めることができる。より高いトラフィック・ニーズを処理するために、イメージング・サーバシステムのクラスタは、互いに通信するように構成することによって、作製した画像のキャッシュを分散し、フェイルオーバー及び高アベイラビリティをもたらすことができる。例えば、サイト管理者は、トラフィック・レート（通信速度）が特定の閾値を超えた場合、サイトの一部に対して高圧縮画像を提供する、というルールを作成することができる。サイト利用者は、「要求不履行」メッセージの代わりに、正常なページ・ビューを取得することができる。さらに、バンド幅コスト（一般的には、ピーク使用の９０％において測定）を、コスト効率のよいレベルに保つことができる。
【００２４】
本発明は、Ｗｅｂ又はその他のタイプのネットワーク・サーバと共に、データ・センタに配置されてもよい。サーバシステムのクラスタは、互いにシームレスに通信するように構成することによって、作製したマルチメディア・コンテンツ・データのキャッシュを分散し、フェイルオーバー及び高アベイラビリティをもたらすことができる。さらに、このマルチメディア・コンテンツ・サーバシステムは、万一故障が生じた場合に「最大キャッシュ収容力」或いは「キャッシュデータの最小損失」のいずれかを優先するように構成することもできる。このマルチメディア・コンテンツ・サーバシステムは、既存のＷｅｂサイト配置と容易に統合するようにデザインされている。行わなければならない唯一の変更は、ＨＴＭＬコンテンツ・タグを、現在コンテンツが検出されているサーバ向けではなく、このマルチメディア・コンテンツ・サーバシステム向けにすることである。このコンテンツ・タグは、既存のページ及び新しいページに関して変更することができる。作成された新しいページはいずれも、「マルチメディア・コンテンツ・サーバシステム・アウェア」というコンテンツ・タグを含む。既存のページは、最も都合のよい時に変更することができる。画像に関し、現在のほとんどのサイトがそのコンテンツをファイルして格納するには、ファイル名による方法又はディレクトリによる方法の２つの方法がある。例えば、このイメージング・サーバシステムの実施形態は、両方の格納スタイルを容易に受け入れる。
【００２５】
ファイル名ベースのサイトの例としては、次のようなものがある。
・ｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ１．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｗｏｍｅｎ／１２３０２／ｉｍａｇｅｓ／１２３０２ｔ．ｊｐｇ
これは、サムネイル・サイズの画像を表している。
・ｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ１．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｗｏｍｅｎ／１２３０２／ｉｍａｇｅｓ／１２３０２ｍ．ｊｐｇ
これは、ミディアム（中）・サイズの画像を表している。
・ｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ１．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｗｏｍｅｎ／１２３０２／ｉｍａｇｅｓ／１２３０２ｌ．ｊｐｇ
これは、ラージ（大）・サイズの画像を表している。
各ファイル名は、異なる画像サイズを表すように付けられている。
このシナリオを処理するには、「ファイル名・ルール（Ｆｉｌｅｎａｍｅ Ｒｕｌｅｓ）」を用いることによって、「ｔ」で終わるファイルが要求されている場合にはサムネイル・サイズの画像を配信し、「ｍ」の場合にはミディアム・サイズの画像を配信し、「ｌ」の場合にはラージ・サイズの画像を配信しなければならないということを、イメージング・サーバに教える。
【００２６】
ディレクトリベースのサイトの例としては、次のようなものがある。
・ｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ２．ｃｏｍ／１１／３９／９７／Ｔｈｕｍｂ／１１３９９７７６．ｊｐｇ
・ｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ２．ｃｏｍ／１１／３９／９７／Ｍｅｄｉｕｍ／１１３９９７７６．ｊｐｇ
・ｈｔｔｐ：／／ｗｗｗ．ｃｏｍｐａｎｙ２．ｃｏｍ／１１／３９／９７／Ｌａｒｇｅ／１１３９９７７６．ｊｐｇ
各ディレクトリは、異なる画像サイズを表すように付けられている。
このシナリオでは、「パス・ルール（Ｐａｔｈ Ｒｕｌｅｓ）」を用いることによって、「Ｔｈｕｍｂ」で終わるパスが要求されている場合にはサムネイル・サイズの画像を配信し、「Ｍｅｄｉｕｍ」の場合にはミディアム・サイズの画像を配信し、「Ｌａｒｇｅ」の場合にはラージ・サイズの画像を配信しなければならないということを、イメージング・サーバに教える。
【００２７】
マルチメディア・コンテンツ・サーバシステム・コンポーネント
ネットワーク・アプライアンスとは、限定された数の専用機能を提供するため、それらの機能を多目的デバイスよりもコスト効率よく配信することのできるデバイスである。アプライアンスは、１つの特定領域に特化することによって、配置及び構造の点から、より豊富な特徴セット、より優れた安定性、及びより広い柔軟性を提供することが多い。本発明の好適な実施形態は、マルチメディア・コンテンツを配信するように最適化された、ネットワーク対応のシールドシステムである。このシステムには、互換性の問題に対してインストールする又は対処するソフトウェアはない。このシステムは、あらゆるデバイスに対してマルチメディア・コンテンツを高性能に配信することに焦点が当てられている。このマルチメディア・コンテンツ・サーバは、ラック取り付け可能ユニットとして、例えば、Ｗｅｂサーバ、データベース、ファイアウォール、ロード・バランサ、及びキャッシュ・サーバのような、他のＷｅｂインフラストラクチャと共に都合よく配置される。
【００２８】
このマルチメディア・コンテンツ・サーバシステムは、あらゆるＷｅｂ対応機器に対してマルチメディア・コンテンツを動的に適合させる「ノー・コード（ｎｏ−ｃｏｄｅ）」ソリューションである。ルール及び特性は、ＩＴ専門家及びＷｅｂ製作スタッフによって利用することのできる、ポイント・アンド・クリック・ユーザ・インタフェースを介して作成される。ルールは、ＵＲＬパス、ファイル名、サーバ・デマンド、ブラウザ・タイプ、及びクッキー・コンテンツを含む、様々な基準に基づくようにすることができる。
【００２９】
また、このマルチメディア・コンテンツ・サーバシステムは、より一般的なマルチメディア・コンテンツ変換要求に対する、１セットの予め定義されたルールも備える。この予め定義されたルールは、細かい設定なしに、マルチメディア・コンテンツ配信ニーズを満たしてもよい。そうでなければ、これらのルールを容易に変更する又は新しいルールを容易に作成することによって、システム要求を満たしてもよい。最新の携帯電話モデルの内容を調べ、これらのモデルをサポートするような更新ルールを作成することによって、これらのルールを既存のマルチメディア・コンテンツ・サーバシステム配置に分散させることができ、これにより、これらのルールは常に技術に追いついている状態となる。ルールの単純な例としては、「ブラウザ・タイプ・ルール（Ｂｒｏｗｓｅｒ Ｔｙｐｅ Ｒｕｌｅ）」がある。このタイプのルールは、要求元のブラウザのタイプに基づいて画像を適合させる方法を、マルチメディア・コンテンツ・サーバシステムに教える。画像に関し、このルールは、組み合わせることによってカスタマイズされた画像を作成する特性（例えば、画像ソース、高さ、幅、及び圧縮）を有する。ルールの特性は、いつでも且ついずれの環境からも変更することができ、個々のＷｅｂページに対する変更は必要とされない。
【００３０】
「サーバ・デマンド・ルール」を用いることによって、ピーク負荷時間中、バンド幅をより適切に管理することができる。より多くのＷｅｂサーバを追加したり、サイト全体に対するマルチメディア・コンテンツの質及び量を低減させる代わりに、このマルチメディア・コンテンツ・サーバシステムを用いれば、高トラフィック時間中は、より低品質のコンテンツが自動的に提供される。「クッキー（ｃｏｏｋｉｅ）」・ルール（クッキーとは、サーバによってユーザのデバイスに記録される小さなデータファイルであって、そのサーバによって後でアクセスされてもよい）を用いることによって、マルチメディア・コンテンツ特性をさらにカスタマイズして、そのユーザのデバイスに配信するのに最も適した特性とすることができる。
【００３１】
以下の説明は、画像の配信を含む本発明の実施形態を詳述している。図１は、ＴＣＰ／ＩＰ上のＨＴＴＰプロトコルを用いるインターネット４を介してＷｅｂページを要求する、クライアント・デバイス２を示している。ルータ６、ファイアウォール８、ロード・バランサ１０、及びイーサネット（登録商標）接続１２、２０が、標準のネットワーク・コンポーネントである。通信渋滞を引き起こすＷｅｂサイトは、一般的には、アプリケーション・サーバ１６とＷｅｂサーバ１４との両方を用いる。画像の効率的な転送を容易にすることによって、いくつかの有効な条件を満たすために、本発明の画像レンダリング実施形態に基づいたイメージング・サーバシステム１８が追加されている。このイメージング・サーバシステムの作用には、以下のような３つの基本領域がある。
・ラスタ画像の作製−オリジナル解像度のラスタ画像データ（一般的には、オリジナル解像度のＪＰＥＧ）を取り出し、（例えば、画像のサイズ及び圧縮品質を調整したり、「プログレッシブ」ＪＰＥＧを生成したりすることによって、）それらのデータをウェブ使用のために処理する。
・画像のコード変換−上記と同様であるが、画像の作製に加えて、その画像を様々な出力デバイスに対して適合させる（例えば、一般的には、ｉモード（登録商標）対応電話がその画像を要求したということを自動的に検出することによって、ＪＰＥＧ画像を、ｉモード（登録商標）に対するＧＩＦ画像に変換する）。
・画像の自動作成−上記に、ウェブに対するマルチソース複合体を作成する能力を追加。例えば、ベクトルテキスト及びアートを画像に追加する能力を提供することによって、急いで（オンザフライで）バナー広告を作成することができる。
【００３２】
この好適な実施形態に説明する、イメージング・サーバシステムの使用法は、概ね、これらのドメインのうちの１番目に焦点を当てる。その理由は、このドメインが、本発明によってカバーされる領域を実証するのに十分であるからである。以下は、このイメージング・サーバシステムのユーザが、どのようにしてオリジナル解像度のラスタ画像データと交信して、必要とされていることを行うか、ということを分析したものである。ここに説明する技法は、画像コード変換タスク及び画像作成タスクにも同様に適用される。
【００３３】
まず、このドメインの基本ユーザ指向パラメータのレイアウトについて説明し、次に、ワークフローについて、その次に、このイメージング・サーバシステムの性能を用いるワークフローについて説明する。最後に、実際の配置モデルにマッピングする、いくつかのサンプル構造について説明する。
【００３４】
ラスタ画像作製パラメータ
下の表は、ウェブサイト製作者が、従来のウェブに対する画像データを作製する際に調整を望む、パラメータについて説明している。
【００３５】
【表１】

【００３６】
これは、指定され得るパラメータのタイプの代表的なものである。平均的な当業者によれば、他のパラメータを追加することによって、容易に異なる機能を行うことができる。しかしながら、このリストは、ユーザが引くことによって、イメージング・サーバシステムが「適切な役割を果たす」ような「レバー」が多数ある、ということを示している。
【００３７】
上記のような性能であるとすると、以下がこれらのパラメータを設定するメカニズムである。この問題を分析する方法としては、最も基本的な方法、つまり、「ＱＵＥＲＹ（照会）」ＵＲＬの一部としてパラメータをコード化する方法を思い出されたい。
【００３８】
この例に関し、ドメイン・カンパニー（Ｄｏｍａｉｎ Ｃｏｍｐａｎｙ）は、ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍにウェブ・サーバを有し、「ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ」にイメージング・サーバシステムを有する、と仮定する。本発明の性能のうちのいくつかを利用するウェブページのフラグメントとして、以下のようなものがある。
＜ＨＴＭＬ＞
．．．
＜ＩＭＧ ＳＲＣ＝ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／？ＳＲＣ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｗｉｄｇｅｔ．ｊｐｇ＆Ｈ＝３２０＆Ｗ＝２４０＆ＣＲＯＰ＝ＭＡＸ＞
．．．
＜／ＨＴＭＬ＞
【００３９】
この例は、イメージング・サーバシステムが、ソース画像のアスペクト比を保存し、ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍにおけるディレクトリからそのソース画像を取得して、（入力と同じフォーマットにデフォルトした）３２０×２４０のＪＰＥＧを作成することを示している。
【００４０】
この特定の場合では、ＩＭＧタグに対してＳＲＣとして用いられているＵＲＬは、それほど複雑ではない。しかし、より多くのパラメータを設定したい場合、ＵＲＬは、より複雑となり、エラーを起こしやすくなるであろう。さらに、ますます多くの性能が用いられるようになると、正しいＵＲＬを作成するのがさらに一層複雑となる。
【００４１】
本発明のこの実施形態は、画像を処理するサーバシステムの開発に伴って必要とされる複雑な変換に応えている。
【００４２】
明らかに、ＵＲＬコード化のみに依存する方法は処理しにくい。提供するものに関してサーバをよりスマートにすることによって、ＵＲＬに指定される必要のあるものをより少なくする方法が必要とされている。
【００４３】
最も単純な場合では、イメージング・サーバシステムに、いくつかのデフォルト設定値（圧縮、アスペクト比動作など）を教えるだけでよい。これらの単純な場合に関しては、これで十分であろう。この技法を用いることにより、恐らくほとんどのイメージング・サーバシステムＵＲＬを削減して、ＳＲＣのＷ及びＨパラメータのみを追加することができるであろう。ソース画像の全てが１つの場所に位置している場合には、さらに単純化することが可能である。１セットの設定値（「特性」）を画像の集合に付与する、何らかの方法が必要とされている。これらの特性は、できるだけ容易に付与できることが重要である。さらに、このような特性を用いることによって、イメージング・サーバから画像にアクセスするのに用いられるＵＲＬが、何らかの方法で単純化されなくてはならない。最も自然な収集メカニズムは、ほとんどのＵＲＬによって暗示されるディレクトリ構造である。例えば、次のようなＵＲＬを考えたい。
ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｒｏｕｔｅｒ．ｊｐｇ
【００４４】
従来のウェブ・サーバでは、このＵＲＬは、サーバｗｗｗ．ｄｏｍａｉｎ．ｃｏｍが「ｐｒｏｄｕｃｔｓ」と呼ばれるディレクトリを有しており、このディレクトリが「ｉｍａｇｅｓ」というサブディレクトリを有しており、このサブディレクトリで「ｒｏｕｔｅｒ．ｊｐｇ」というＪＰＥＧファイルを見つけることができる、ということを暗示していた。最新のウェブ・アプリケーション・サーバに関しては、これらのＵＲＬコンポーネントが、サーバにおける実際のディレクトリ構造にマッピングしている、という確実性はより低い（その代わりに、例えば、これらのＵＲＬコンポーネントは、キーとしてデータベースに用いられてもよい）。一般的には、これらのＵＲＬコンポーネントは、ものの関連付けされた集合に対するリポジトリである、と考えられる（例えば、「ｓｗｉｔｃｈ．ｊｐｇ」は「ｒｏｕｔｅｒ．ｊｐｇ」と同じディレクトリにあると推測される）。この概念は、イメージング・サーバシステムにおいて「仮想ディレクトリ（Ｖｉｒｔｕａｌ Ｄｉｒｅｃｔｏｒｙ）」を使用することによって構築することができる。「仮想」とは、イメージング・サーバシステムは、これらのＵＲＬコンポーネントを理解し、特性をこれらと関連付けるが、これらのＵＲＬコンポーネントは、実際にはサーバに存在しない、ということを意味している。イメージング・サーバシステムには、次のような仮想ディレクトリを作成することが可能である。
ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／
【００４５】
この仮想ディレクトリが作成されたら、次のような特性を関連付けてもよい。
ＳＲＣ＝ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／＄｛ＦＩＬＥ｝．ｔｉｆ
ＣＯＭＰＲＥＳＳ＝５０％
Ｗ＝６４０
Ｈ＝４８０
【００４６】
ここで、次のような単純なＵＲＬを、ＨＴＭＬページに組み込むことが可能である。
＜ＩＭＧ ＳＲＣ＝ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｒｏｕｔｅｒ．ｊｐｇ＞
【００４７】
ＨＴＭＬページにこのＵＲＬが示されると、イメージング・サーバシステムは、次のように動作する。イメージング・サーバシステムは、ＨＴＭＬページに示されたＵＲＬの「ＦＩＬＥ」部分（この場合は「ｒｏｕｔｅｒ」）を取り出し、それをＳＲＣ特性に代入することによって、実際のＳＲＣ特性ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｒｏｕｔｅｒ．ｔｉｆを作成する。イメージング・サーバシステムにおける仮想ディレクトリ・パスとウェブ・サーバにおける「実」ディレクトリ・パスとは互いに一致する、ということには注意されたい。当然ながら、このことは利便性を図るものであり、必須のものではない。イメージング・サーバシステムは、そのソースＴＩＦＦファイル（ＳＲＣファイル拡張機構から導出される入力タイプ）を読み込んで、６４０×４８０の５０％圧縮ＪＰＥＧ（入力ＵＲＬ拡張機構から導出される出力タイプ）を生成する。別の方法としては、Ｗｅｂサイト開発者が、必要とされる圧縮されていないＴＩＦＦファイルを全てサーバ・ディレクトリに充填することができ、適切に構成されたイメージング・サーバシステム仮想ディレクトリを単に作成して用いることにより、Ｗｅｂブラウザ使用に自動的に生成されたＪＰＥＧを取得することができる。さらに、将来的にバンド幅が問題となった場合には、この仮想ディレクトリを変更することによって、全ての画像に８０％圧縮を用いることができる。これにより、バンド幅の使用率は低下するが、サイト上の画像を全て回って再生成する必要はなくなる。
【００４８】
階層的特性
上記の方式は、いくつかの有用な性能を適切に提供すると共に、適切に構成されたイメージング・サーバシステムを用いることによって容易に実施される。しかしながら、他の実施形態も可能である。
【００４９】
上述したように、ＵＲＬによって表される暗示ディレクトリ構造は、階層構造を形成している。つまり、仮想ディレクトリ間には、「〜に含有される」又は「〜の子である」という関係がある。新しい性能は、この関係に基づいて構築することができる。前の例に続き、次のような新しいイメージング・サーバシステム仮想ディレクトリを作成してもよい。
ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｔｈｕｍｂｎａｉｌｓ／
ここで、次のような特性を設定する。
Ｗ＝１６０
Ｈ＝１２０
【００５０】
いずれの仮想ディレクトリも、その親の特性がオーバーライドされない限り、親の特性を継承することができるような構造にすることによって、非常に有用な性能が作成される。この場合、ウェブ・サーバ自体には何も変更は行われないが、ウェブ・サーバに格納されている各画像のサムネイルが自動的に「作成」される。これらのサムネイルは、ＨＴＭＬページにおいて単に次のように表される。
＜ＩＭＧ ＳＲＣ＝ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｔｈｕｍｂｎａｉｌｓ／
ｒｏｕｔｅｒ．ｊｐｇ＞
【００５１】
従来の「サムネイルをクリックしてフルサイズ画像を見る」は、ここでは容易に次のようにコード化することができる。
＜Ａ ＨＲＥＦ＝ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｒｏｕｔｅｒ．ｊｐｇ＞＜ＩＭＧ ＳＲＣ＝ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｉｍａｇｅｓ／ｔｈｕｍｂｎａｉｌｓ／ｒｏｕｔｅｒ．ｊｐｇ＞＜／Ａ＞
【００５２】
これは全て、主ウェブ・サーバを何も変更することなく行われる。
【００５３】
浮動ディレクトリ
このパワーは、さらに一層拡張することができる。仮想ディレクトリを以下のように指定できる可能性を考えたい。
ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ ^＊ ／ｔｈｕｍｂｎａｉｌｓ／
ここで、ＳＲＣを次のようなものに設定する。
ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／＄｛ＤＩＲＳ｝／．．／＄｛ＦＩＬＥ｝．＄｛ＥＸＴ｝
【００５４】
これは、「ｔｈｕｍｂｎａｉｌｓ」で終わるＵＲＬがイメージング・サーバシステムに示された場合はいつでも、サーバは、指定入力ファイルに対し、そのディレクトリの仮想の「親」（「^＊」で表記）を見る、ということを意味するであろう。例えば、イメージング・サーバシステムが、次のようなＵＲＬを受信した場合、
ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｃａｔａｌｏｇ／ｐｈｏｔｏｓ／ｔｈｕｍｂｎａｉｌｓ／ｈｕｂ．ｊｐｇ
そのソースデータを次のようなＵＲＬから取得し、
ｈｔｔｐ：／／ｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／ｃａｔａｌｏｇ／ｐｈｏｔｏｓ／ｈｕｂ．ｊｐｇ
再度、「サムネイル」画像を作成する。これは、ウェブサイトにおける全ての画像に対してサムネイルを作成するという効果をもたらす。
【００５５】
特殊設定値
仮想ディレクトリの設定値が、特定の画像に対して完全には正しくない場合がある。その場合、ＵＲＬ自体に特性を設定する能力は、依然として有益である。ｈｔｔｐ：／／ｃｌｉｐｐｅｒ．ｄｏｍａｉｎ．ｃｏｍ／ｃａｔａｌｏｇ／ｐｈｏｔｏｓ／ｔｈｕｍｂｎａｉｌｓ／ｈｕｂ．ｊｐｇ？Ｗ＝１７５＆Ｈ＝１７５は、「サムネイル」設定値の全てを用いるが、この特定の画像に対し、幅１７５及び高さ１７５を用いるであろう。
【００５６】
その他の使用法
上に示した例は、主に、画像サイズ（より狭く言えば、出力フォーマット）の調整に焦点を当てているが、その他の使用法も可能である。例えば、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）のＷｉｎｄｏｗｓ（登録商標）ＣＥブラウザに適した１セットの特性を自動的に付与する、「ＰｏｃｋｅｔＥｘｐｌｏｒｅｒ」と呼ばれる（浮動又は絶対）仮想ディレクトリの作成が推測できるであろう。同様に、「ｉモード（登録商標）」ディレクトリは、日本のｉモード対応電話に対するコード変換を処理することができるであろう。この例は、拡張することができる。「ＢＲＯＷＳＥＲＤＥＴＥＣＴ」と呼ばれる特性を考えたい。これはブール式であることにより、ＴＲＵＥ（真）の場合、クリッパー（Ｃｌｉｐｐｅｒ）が、ブラウザＩＤストリングを調べて、そのストリングに関連した１セットの特性を検索する。これらの特性は、最終セットの仮想ディレクトリ特性の後で、且ついずれのＵＲＬ特性よりも前に、恐らく付与されるであろう。あらゆる製品の一部として、このような「予め調理された」特性設定値を一般的なシナリオに提供することは有益であろう、ということは容易に推測される。また、ユーザに能力読み込み及び書き出し特性を提供することと、特性を１つのエンティティから他のエンティティにコピーすることも重要である。
【００５７】
その他の条件及び特性ルール設定値
前述した、例えば、ブラウザ・タイプ、デバイス・タイプ、接続のバンド幅（デバイスのバンド幅とデバイス関連ネットワークのバンド幅との両方）、ネットワーク負荷、要求者ブラウザに記録されたクッキー、並びに、ＵＲＬパス及びファイル名のような、基本セットの条件を用いれば、ネットワーク管理者は、ポイント・アンド・クリック・ユーザ・インタフェースを用いることによって、画像が所有すべき特性を指定することができる。要求マネージャに存在し得られたルールは、画像要求に伴う特定セットの条件に基づいており、階層的リストにおいて見られる。これらの特性は、ルールセットの後の方のルールに現れる特性と対立して効果を有するであろう。また、上記ルールセットによって設定されたいずれの特性もオーバーライドすることのできる、「照会ＵＲＬ（Ｑｕｅｒｙ ＵＲＬ）」ストリングルールを用いることも可能である。
【００５８】
この実施形態において現在変更可能な特性としては、画像サイズ及び幅、アスペクト比、ＪＰＥＧ品質及びタイプ、ＧＩＦパレットタイプ及び色の数、透明度、背景色があり、即ち、編集モードにおいて、自動固定コマンド、フリップコマンド、回転コマンド、及びグレースケールコマンドのいずれかが従事するべきである。当然のことながら、事実上、いずれのイメージング動作も、特性として含めることができる。本実施形態において、出力画像フォーマットは、現在のところ、ＰＮＧ、ＷＢＭＰ、ＪＰＥＧ、及びＧＩＦを含む。他の実施形態では、当業者によって容易に追加されるフォーマットのほぼ全てが、出力となり得る。
【００５９】
画像レンダリングエンジン
画像レンダリングの方法としては、多数の使用可能な方法があり、一般的には、画像を異なるサイズ及びフォーマットに変換可能な画像レンダリングエンジンを含む。これらのレンダリングエンジンは、画像を、例えば、ＪＰＥＧ、ＧＩＦ、ＢＭＰ、ＴＩＦＦ、ＰＮＧ、及びＰＳＤのような、ファイルフォーマットに変換することができる。ＧＩＦに関し、論議中のこのイメージング・サーバシステムは、パレット（最適化、固定、カスタム、及びハイブリッド）、インタレース、透明度、無光沢、並びにディザをサポートする。ＪＰＥＧに関し、このイメージング・サーバシステムは、品質、プログレッシブ、色空間（ＲＧＢ及びグレースケール）、並びに無光沢をサポートする。また、このイメージング・サーバシステムは、例えば、回転、自動固定、フリップ、及びグレースケールのような、画像処理機能も実行する。画像レンダリングエンジンは、ＩＴ又はＷｅｂスタッフによって作成されたルールに基づいて、指定の画像を処理する。このレンダリングエンジンは、適切な位置からオリジナル画像を要求する。キャッシュにより、画像が確実に迅速に配信され、Ｗｅｂサーバが画像提供タスクから解放され、既存のキャッシュシステムの性能が向上する。また、このイメージング・サーバシステムは、「エッジ」キャッシュのような第三者キャッシュシステムもサポートする。この「エッジ」という語は、主要なインターネット・バックボーンの「エッジ」におけるネットワーク・アクセスポイント又は存在点を示すのに用いられている。キャッシュのような「エッジ・サービス」を利用することによって、Ｗｅｂコンテンツはユーザのより近くに配置され、これにより、コンテンツを読み出すのに必要とされるルーティング及びスイッチング・ホップの数が少なくなる。
【００６０】
プロセスフロー
図２は、プロセスフローを示している。画像要求が受信され（４０）、次に、その画像は以前に要求されたことがあるかどうかが判定される（４２）。「要求されたことがない」場合には、オリジナル・ソース画像が読み出され（４４）、イメージング・ルールセットが決定されて（４８）、推測エンジン（５２）がこれらのルールを用いてその画像をレンダリングする。次に、この適切な画像が、キャッシュ（５０）に配信されて、伝送される（５４）。イメージング・サーバシステムが画像を一旦配信すると、その画像はキャッシュシステム（５０）に存在し、その画像に対するそれ以降の要求はいずれも、このキャッシュ（５０）によって処理される。正しい特性を備えた画像が以前に要求されたことがある場合には、その画像が依然としてキャッシュ（５０）に存在するかどうかに関する判定（４６）が行われる。「存在する」場合には、キャッシュに格納されているその画像が配信される。適切な特性を備えた画像がキャッシュにない場合には、オリジナル・ソース画像が読み出され（４４）、ルールが決定され（４８）、イメージングエンジンによって処理が行われ（５２）、得られた画像がキャッシュ（５０）に送信されて、配信される（５４）。
【００６１】
サンプルデバイス
図３は、ネットワーク化されたサーバから画像を要求するのに用いてもよい、デバイスのサンプルを示している。イメージング・サーバシステム６２は、オリジナル画像６０の特性を、特別にＰＤＡ６４に適した画像に変更するか、或いは、別のセットの特性を用いて、特別にＰＣに適した画像を配信するか、或いは、第３のセットの特性を用いて、特別に携帯電話６８に適した画像を配信することができる。
【００６２】
このイメージング・サーバシステムから成る好適な実施形態は、管理者が、いずれのＷｅｂブラウザからも、確実にイメージング・サーバシステムを制御し、構成し、監視することのできる、管理コンソールも提供する。以下に挙げるものは、提供される管理機能のうちのいくつかの例である。
・ユーザ／許容エラーログ比Ｃａｃｈｅ／Ｎｅｗの定義
・リンク無効パスワードの管理 １日あたりの画像
・ネットワーク構成キャッシュ・アクセス・ログ １時間あたりの画像
・ルールセット構成ＨＴＴＰサーバ・アクセス・ログ
・最も要求される画像
・サーバ・スタートアップ／シャットダウン・ルールの使用ログ
・最も一般的なブラウザ
・サーバ／キャッシュ構成
・最も頻繁に用いられるルール
・サーバ・デマンド履歴
・優先順位におけるルール設定値
【００６３】
【発明の効果】
マルチメディア・コンテンツを作成し、処理し、管理するプロセスは、費用と時間のかかるものである。許容可能なサイト性能を維持すること、様々なデバイスへコンテンツを配信すること、及び接続速度は、ＩＴ及びＷｅｂ製作スタッフに重要な課題を与えてきた。本発明は、マルチメディア製作コストを削減し、ネットワークサイト性能を向上させ、マルチメディアをあらゆるデバイスに動的に配信する、確実で強固なサーバシステムを提供することによって、従来のものを変えている。
【００６４】
本明細書中の実施例及び説明は、本発明を例示するものであって、限定するものではない。本発明は、本明細書中に示した内容に限定されないが、上記特許請求の範囲及びその等価物の全範囲において変更してもよい。
【図面の簡単な説明】
【図１】
インターネットを介してＷｅｂページを要求する一般的なクライアント・デバイスを示す図である。
【図２】
画像要求が行われた場合に用いられるステップを示すフローチャートである。
【図３】
画像がそれに合わせて変更されたデバイスのサンプルを示す図である。

Claims (21)

1. ネットワーク化された環境においてマルチメディア・コンテンツを伝送する方法であって、
   ａ）マルチメディア・コンテンツ要求を受信するステップを含み、
   ｂ）前記要求されたマルチメディア・コンテンツを伝送するための、適切なセットのマルチメディア特性を決定するステップを含み、
   ｃ）前記適切なセットのマルチメディア特性を含む、前記要求されたマルチメディア・コンテンツを伝送するステップを含む、
   前記方法。
2. 前記適切なセットの特性が、前記マルチメディア・コンテンツ要求に関連する１つ以上の条件によって決定される、請求項１に記載の方法。
3. 前記マルチメディア・コンテンツ要求に関連する前記１つ以上の条件が、前記マルチメディア・コンテンツを要求するユーザ・デバイスのタイプを含む、請求項２に記載の方法。
4. 前記マルチメディア・コンテンツ要求に関連する前記１つ以上の条件が、実質的に決定された前記デバイスのデータ伝送速度及び前記デバイスの関連ネットワークのデータ伝送速度である、請求項２に記載の方法。
5. 前記マルチメディア・コンテンツ要求に関連する前記１つ以上の条件が、前記マルチメディア・コンテンツが要求された時点でのネットワーク負荷を含む、請求項２に記載の方法。
6. 前記マルチメディア・コンテンツ要求に関連する前記１つ以上の条件が比較される、ルールセットを予め決定するステップをさらに含む、請求項２に記載の方法。
7. 前記適切なセットの特性が既に付与されたマルチメディア・コンテンツのキャッシュを予め決定するステップと、前記マルチメディア・コンテンツのキャッシュを伝送に使用可能にするステップとをさらに含む、請求項２に記載の方法。
8. 前記適切なセットの特性を備えたマルチメディア・コンテンツが前記キャッシュにおいて使用可能でない場合、条件付けされていないマルチメディア・コンテンツを読み出し、前記条件付けされていないマルチメディア・コンテンツに前記適切なセットの特性を付与し、続いて、前記適切なセットの特性を備えるようになったこのマルチメディア・コンテンツを伝送する、請求項７に記載の方法。
9. ネットワーク化された環境において適切な特性を備えたマルチメディア・コンテンツを伝送するシステムであって、
   前記特性が、前記マルチメディア・コンテンツが要求された時点で効果を有していた条件によって決定され、
   ａ）前記要求を受信するサーバを備え、
   ｂ）前記サーバが、どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための、予め決定されたルールセットを用い、
   ｃ）条件付けされていないマルチメディア・コンテンツを取り出して、前記条件付けされていないマルチメディア・コンテンツを、前記適切な特性を備えた条件付けされたマルチメディア・コンテンツにレンダリングすることのできる、マルチメディア・コンテンツ・レンダリングエンジンを備え、
   ｄ）前記サーバが、次に、前記条件付けされたマルチメディア・コンテンツを配信する、
   前記システム。
10. 伝送するのに適切な前記特性を既に備えた予め決定されたマルチメディア・コンテンツのキャッシュをさらに含み、これによって、前記サーバが、適切なマルチメディア・コンテンツが前記キャッシュにおいて既に使用可能であると判定すると、伝送するのに適切な前記マルチメディア・コンテンツを読み出す、請求項９に記載のシステム。
11. どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための前記ルールセットが、要素の１つとして、前記マルチメディア・コンテンツを要求するクライアント・デバイスのタイプを用いる、請求項９に記載のシステム。
12. どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための前記ルールセットが、前記判定のための要素の１つとして、前記要求元デバイスのデータ伝送速度及び前記要求元デバイスの関連ネットワークのデータ伝送速度を用いる、請求項９に記載のシステム。
13. どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための前記ルールセットが、前記判定のための要素の１つとして、前記マルチメディア・コンテンツが要求された時点での現在のネットワーク負荷を用いる、請求項９に記載のシステム。
14. ネットワーク化された環境において適切な特性を備えたマルチメディア・コンテンツを伝送するシステムであって、
    前記特性が、前記マルチメディア・コンテンツが要求された時点で効果を有していた条件によって決定され、
    ａ）前記要求を受信する手段を備え、
    ｂ）どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための、予め決定されたルールセットを用いる手段を備え、
    ｃ）条件付けされていないマルチメディア・コンテンツを取り出して、前記条件付けされていないマルチメディア・コンテンツを、前記適切な特性を備えた条件付けされたマルチメディア・コンテンツにレンダリングする手段を備え、
    ｄ）前記条件付けされたマルチメディア・コンテンツを要求元デバイスに伝送する手段を備える、
    前記システム。
15. 伝送するのに適切な前記特性を既に備えた予め決定されたマルチメディア・コンテンツをキャッシュに格納する手段をさらに含み、これによって、前記サーバが、適切なマルチメディア・コンテンツが前記キャッシュにおいて既に使用可能であると判定すると、伝送するのに適切な前記マルチメディア・コンテンツを読み出す、請求項１４に記載のシステム。
16. どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための前記ルールセットを生成する手段が、要素の１つとして、前記マルチメディア・コンテンツを要求するクライアント・デバイスのタイプを用いる、請求項１４に記載のシステム。
17. どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための前記ルールセットを生成する手段が、前記判定のための実質的な要素の１つとして、前記クライアント・デバイスのデータ伝送速度及び前記クライアント・デバイスの関連ネットワークのデータ伝送速度を用いる、請求項１４に記載のシステム。
18. どのようなマルチメディア・コンテンツ特性が伝送に適しているかを判定するための前記ルールセットを生成する手段が、前記判定のための要素の１つとして、前記マルチメディア・コンテンツが要求された時点での現在のネットワーク負荷を用いる、請求項１４に記載のシステム。
19. ネットワーク化された環境において画像を伝送する方法であって、
    ａ．画像要求を受信するステップを含み、
    ｂ．前記要求された画像を伝送するための、適切なセットの画像特性を決定するステップを含み、前記適切なセットの画像特性が、前記画像を要求するデバイスのタイプ、前記画像が要求された時点でのネットワーク負荷、前記要求元デバイスから読み出されたクッキーのコンテンツ、及び前記画像を前記要求元デバイスに配信するのに使用可能なバンド幅から選択され、
    ｃ．前記適切なセットの特性を備えた画像が画像のキャッシュにおいて使用可能であるかどうかを判定するステップを含み、
    ｄ．前記適切なセットの特性を備えたような画像が使用可能でない場合、オリジナル画像を画像レンダリングエンジンに送信することによって、前記適切なセットの特性を備えた画像を生成するステップを含み、
    ｅ．前記適切なセットの特性を備えた前記画像を前記要求元デバイスに配信するステップを含む、
    前記方法。
20. ネットワーク化された環境において画像を伝送する方法であって、
    ａ．画像要求を受信するステップを含み、
    ｂ．前記要求された画像を伝送するための、適切なセットの画像特性を決定するステップを含み、前記決定が、前記要求された画像のＵＲＬの照会ストリングに組み込まれた画像特性パラメータによってオーバーライドされ、
    ｃ．前記適切なセットの特性を備えた画像が画像のキャッシュにおいて使用可能であるかどうかを判定するステップを含み、
    ｄ．前記適切なセットの特性を備えたような画像が使用可能でない場合、オリジナル画像を画像レンダリングエンジンに送信することによって、前記適切なセットの特性を備えた画像を生成するステップを含み、
    前記適切なセットの特性を備えた前記画像を要求元デバイスに配信するステップを含む、
    前記方法。
21. 伝送されるマルチメディア・コンテンツ特性を制御する指示を含むコンピュータ可読媒体であって、
    ａ）マルチメディア・コンテンツ要求を受信するステップを含み、
    ｂ）前記要求されたマルチメディア・コンテンツを伝送するための、適切なセットのマルチメディア・コンテンツ特性を決定するステップを含み、
    ｃ）前記適切なセットのマルチメディア・コンテンツ特性を含む、前記要求されたマルチメディア・コンテンツを伝送するステップを含む、
    前記コンピュータ可読媒体。

Images