JP2005507516A - サービスによって提供されるコンテンツのカスタマイズ - Google Patents

Abstract

モバイルクライアント用のネットワークに基づくオペレーティングシステムを提供するための方法および装置が開示される。能力が異なるさまざまなクライアント装置をサポートするために使用可能なサービスを開発することができる。サービスはさまざまな装置に基づいて複数の変形を出力に与え、媒介物が要求を行なう装置に最も好適な変形を選択する。オンラインソフトウェア開発システムが提供されるため、サービスは、クライアント側のブラウザのみを使用して、媒介物において、アプリケーションを作成、編集、テストおよび実装することができる。他のサービスがアクセスおよび参照できるサービスも提供し得るため、異なるサービスの組合せが容易になる。サービスは、変数と、記憶されるデータの変数に対するマッピングとを使用して、媒介物にデータを記憶し、媒介物でデータにアクセスすることができる。媒介物に記憶されるデータを使用して、以前アクセスしたサービスにエンドユーザを戻らせることができる。

Description

【０００１】
【関連出願】
この出願は、２０００年９月６日に出願された先行の米国仮出願連続番号第６０／２３０，４８９号から国内優先権を主張し、その仮出願の開示全体が、その全文がここに記載されているかのごとく引用により援用される。
【０００２】
【発明の分野】
この発明はクライアントにサービスを提供することに関し、特にサービスによって提供されたコンテンツをカスタマイズすることに関する。
【０００３】
【発明の背景】
ワールドワイドウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）は、インターネット上のサーバのネットワークを含み、サーバの各々は、１つ以上のＨＴＭＬ（ハイパーテキストマークアップ言語（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ ｌａｎｇｕａｇｅ））のページに関連する。サーバに関連するＨＴＭＬページは、そのサーバおよび（通常）他のサーバ上の他の文書に情報およびハイパーテキストリンクを提供する。サーバは、ハイパーテキストトランスファープロトコル（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）（ＨＴＴＰ）を使用することによってクライアントと通信する。サーバは、ＨＴＭＬページの要求をクライアントから聞くことから、しばしば「リスナ」と称される。
【０００４】
ワールドワイドウェブのユーザは、ブラウザと称されるクライアントプログラムを使用して、リスナから情報を要求し、それをデコードおよび表示する。ブラウザのユーザが、ＨＴＭＬページ上のリンクを選択すると、そのページを表示しているブラウザは、インターネット上で、そのリンクで指定されたユニバーサルリソースロケータ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ，ＵＲＬ）に関連するリスナに要求を送る。この要求に応答して、リスナは要求された情報を、要求を発行したブラウザに伝送する。ブラウザは、その情報を受取り、受取った情報をユーザに提示し、ユーザからの次の要求を待つ。
【０００５】
伝統的に、リスナに記憶されている情報は静的なＨＴＭＬページの形である。ウェブブラウザからの要求に先立って、静的なＨＴＭＬページが作成され、リスナに記憶される。要求に応答して、静的なＨＴＭＬページが単に記憶装置から読出され、要求を行なっているブラウザに伝送される。現在では、動的な動作によってブラウザの要求に応答するリスナを開発しようとする傾向がある。たとえば、リスナは、データベースに問合せを行ない、問合せの結果を含むウェブページを動的に構築し、動的に構築されたＨＴＭＬページを、要求を行なうブラウザに伝送することによって、要求に応答することができる。
【０００６】
さらに、通常のコンピュータシステム以外の装置にもインターネットへのアクセスを拡張しようとする傾向がある。たとえば、内蔵のブラウザを含む、無線電話などのモバイルクライアント（またはモバイル装置）などが多く開発されている。サイズやコストの制約のため、これらの装置に含まれる「マイクロブラウザ」は、フル装備のコンピュータシステム用に開発されたブラウザに比べて機能が限られている。しかしながら、マイクロブラウザを内蔵した装置は、従来のコンピュータシステムが非実用的である状況で使用することができる。
【０００７】
どのような形にせよ、ウェブのコンテンツを表示することができる装置の種類の数は増え続けている。たとえば、デスクトップコンピュータ、ラップトップコンピュータ、ポケットコンピュータ、携帯電話、ページャおよび形態情報端末（ＰＤＡ）などがあり、これらは「ウェブ対応」と称されるが、それはこれらの装置がウェブのコンテンツを表示することができるからである。ウェブを利用可能な装置の種類の数が増加するにつれ、装置の能力のばらつきも増加している。たとえば、汎用コンピュータシステムは、大型のカラースクリーン、洗練された音声出力、大きな処理能力、人間工学的なキーボード入力、およびマウス、トラックボールまたはトラックパッドなどの使用しやすい選択装置を提供することによって、移動できないことを補償している。反対に、小型のモバイル装置は、スクリーンのサイズおよびユーザが入力する際の利用しやすさを犠牲にして、持ち運びやすさを実現している。
【０００８】
さらに、ネットワーク上のサーバを介してクライアントにサービスを提供しようとする傾向がある。通常、ネットワークはインターネットであり、クライアントはユーザ、サービスはウェブサイトを介してサーバから利用可能である。サービスは、情報、たとえばレストランについての批評、気象情報、株式相場または最新ニュースなどの情報を提供してもよい。またサービスを双方向的に行なって、ユーザが、たとえば、書籍または音楽等の品物、または旅行手配の予約などのサービスを購入できるようにしてもよい。ここで使用する「サービス」という用語は、情報、機能または能力をクライアントに提供することを指す。
【０００９】
ユーザがサービスにアクセスするプロセスは、ユーザが有するクライアントの種類に依存する。たとえば、デスクトップコンピュータは、ダイヤルアップ回線、デジタル加入者回線（ＤＳＬ）、ケーブルモデム、統合サービスデジタルネットワーク（ＩＳＤＮ）接続、または他の多くの利用可能な方法を通じて、インターネットに接続することが可能である。無線アプリケーションプロトコル（ＷＡＰ）電話は、ＷＡＰ−ＨＴＴＰゲートウェイを通じて、無線接続でインターネットに接続することができる。クライアントがウェブサイトにログインし、利用可能なサービスの一覧を提示され、そこからクライアントが所望のサービスを選択するのが一般的である。
【００１０】
一般的に、サービスは２つの方法のどちらか、すなわちホストアプリケーションとしてか、またはポータルアプリケーションとして提供される。典型的なホストアプリケーションでは、開発者がアプリケーションを作成するが、ホストがアプリケーションのインストールおよび維持を行ない、顧客またはエンドユーザがサーバのホストネットワーク上でアクセスできるようにする。これに対して、典型的なポータルアプリケーションでは、開発者がアプリケーションの開発および実装を行ない、顧客またはエンドユーザが開発者が制御する１つ以上のサーバを介してアクセスできるようにする。ここで言う「開発者」は、サービスを提供する個人、企業またはその他の実体（サービスプロバイダとも称される）であってもよいし、または開発者は、別の実体であって、サービスプロバイダにソフトウェア開発サービスを提供してもよい。
【００１１】
ホストアプリケーションであれ、ポータルアプリケーションであれ、アプリケーションを介してサービスを提供する上での共通の問題は、すべての装置で作動するようにアプリケーションを設計しなければならないことである。しかしながら、装置の種類および、同じ種類またはクラスの装置の異なるモデルの特定の能力の両方に基づいて、装置の能力は大きく異なる。たとえば、デスクトップコンピュータは十分な機能を持つウェブブラウザを有することが一般的であるが、個人用コンピューティング装置のマイクロブラウザは、機能が限られている。さらに、携帯電話の中にはディスプレイが限られていて、ディスプレイの各行に１語しか表示できないものもあれば、ディスプレイが大きく、各行に数語を表示できるものもある。
【００１２】
能力のばらつきのため、アプリケーション開発者がすべてのあり得る装置をサポートすることが難しくなり得る。たとえば、サービスには、たとえば販売製品のグラフィック画像などの表示を伴うことがある。グラフィック画像の表示は、デスクトップコンピュータの十分な機能を持つウェブブラウザでは容易に表示することができるが、携帯電話のディスプレイでは表示できないことがあり得る。さらに、開発者が、ある種類またはクラスの装置だけを考えている場合でも、能力の差は大きくなり得る。たとえば、アプリケーションプログラマが、いくつかの情報アイテムを示す複数の言葉を含む出力を送る場合、ディスプレイのスクリーンが限られている携帯電話では、ディスプレイのスクリーンの各行に各情報アイテムの最初の言葉しか表示できないことがあり得る。または、単一の情報アイテムのための出力が電話のディスプレイの複数の行を埋め、他の情報アイテムが同時に表示されなくなることがあり得る。
【００１３】
能力が異なる装置のために設計を行なう上での問題を解決する１つのアプローチには、「最小単位の共通の要素」に合わせて設計することがある。最小単位の共通の要素アプローチは、利用可能な装置のうちの最も限られたもので作動するようにアプリケーションを設計することである。たとえば、選択肢のメニューを、たとえば携帯電話などのクライアント装置に表示する場合、アプリケーションプログラマは、各選択肢について、短い、１語のラベルを選択することができる。なぜなら、そのアプリケーションを使用するであろう装置はすべて、１語のラベルをサポートすることができるからである。たとえば、アプリケーション開発者は、地図アプリケーションで「戻る」という１語のメニューアイテムを用いて、ある選択された目的地からの戻り方を生成する選択肢を表示することができる。
【００１４】
しかしながら、最小単位の共通の要素アプローチの欠点は、他の装置の優れた能力が出力に活かされないことである。たとえば、クライアント装置が長いラベル、たとえば「戻り方の生成」というラベルを表示できる場合、長いラベルが好ましいであろう。なぜなら「戻る」は曖昧であり、ユーザが「前のメニューに戻る」の意味に誤解する可能性があるからである。さらに、すべてのアプリケーションが古い装置の最低限の能力を目標にした場合、新しい装置に組込まれた機能は大半が使用されないままになるであろう。
【００１５】
能力が異なるクライアントまたは装置のために設計を行なう上での課題を解決する別なアプローチには、何らかの中間レベルの能力のために、たとえば最も一般的な種類の携帯電話のために設計するアプローチがある。しかしながら、この中間アプローチを使用したアプリケーションは、機能が低い装置では適切に機能しないことがあり、さらに、他の装置の強化された能力を利用することもできない。
【００１６】
アプリケーションを介してサービスを提供する上での別の課題に、アプリケーションの開発後に利用可能となった付加的な装置をどのようにサポートするかということがある。たとえば、サービスプロバイダによるアプリケーションのリリースの数ヵ月後に、装置の製造業者が新しい装置をリリースすることがあり得る。新しい装置は、既存の特徴が改良されて、現在の装置から進化的に前進しているかもしれない。または、新しい装置は、重要な新しい特徴が追加されて、そのクラスの装置で大きく前進しているかもしれない。または、新しい装置は、新しい種類の装置であって、新しい能力が追加されているか、または能力の新しい組合せを有するかもしれない。
【００１７】
最小単位の共通の要素アプローチを使用することによって、能力が改良された新しい装置を対応させることができるが、新しい装置の強化された特徴および能力、たとえば、より大きなディスプレイなどは、大半が使用されないままになり得る。たとえば、アプリケーションが１語のメニュー選択肢しか提供しない場合、アプリケーションは、複数語の選択肢を表示できる改良された装置を利用しないことになる。さらに、後にリリースされた装置の場合、最小単位の共通の要素アプローチでは、新しい能力、たとえば、音声データまたはグラフィックを処理できるなどの能力が、全く使用されないことがあり得る。アプリケーションが中間レベルの能力用に設計されている場合でも、今後作られ得る装置の進歩および改良点を、すべて十分には利用できないことがあり得る。
【００１８】
アプリケーション開発のもう１つの課題に、アプリケーションを作成する開発者がツールをツールにアクセスしやすくすることがある。典型的に、特定のプラットホーム（ハードウェア、オペレーティングシステムおよび／またはプロトコルの組合せ）用にアプリケーションを設計する開発者は、ソフトウェア開発キット（ＳＤＫ）を利用する。ＳＤＫは、一般的に、アプリケーションプログラミング環境、さまざまな特徴について共通で使用されるライブラリ、アプリケーションプログラミングインターフェイス、ユーティリティ、ドキュメンテーション、ソースコードから実行可能なコードを生成するためのコンパイラ、およびプログラミングの問題を診断するためのデバッガを含む。これらのツールを使用するため、開発者は、ＳＤＫプロバイダからソフトウェア、ドキュメンテーションおよび他の材料を入手し、そのソフトウェアおよび他のツールを、ローカルコンピュータまたはネットワークにインストールする。後にＳＤＫプロバイダが更新および改良を行なうと、開発者は、ＳＤＫパッケージをローカルでインストールしたものにそれらの変更を組込む。このため、アプリケーション開発者は、ＳＤＫのインストールおよび維持にかなりのリソースを費やしなければならないことがあり得る。さらに、従来のＳＤＫは、通常、ＳＤＫ自身のためにかなりのリソースを必要とするだけでなく、アプリケーション開発およびセットアップ、テストおよびランタイムアプリケーションの実装のためのインフラのためにもかなりのリソースを必要とする。
【００１９】
個々のサービスプロバイダは、その中核となるサービスに関係する他のサービスを提供して、サービスを受ける顧客の体験全体を強化したいと考えるかもしれない。たとえば、ユーザがある目的地への道案内を１つのサービスプロバイダから要求している場合、道案内のプロバイダは、その特定の目的地での気象、または食事の選択肢についての付加的な情報をユーザに提供したいと考えるかもしれない。道案内のプロバイダがそのような付加的な情報を提供する方法の１つに、必要な付加的なサービスを作成する方法があるが、これは、かなりの付加的な開発リソースが必要とすることがある。サービスプロバイダが別のサービスプロバイダと調整を行なって、所望の機能性を入手するというアプローチもある。しかしながら、他のサービスプロバイダと調整を行なうには、２つのプロバイダのサービスを接続するための技術的なインフラを確立するという点、および第１のプロバイダの顧客による使用のレベルを測定して、請求を行なうための手段を確立するという点の両方において、かなりの準備が必要となり得る。
【００２０】
さらに、アプリケーションを介してサービスを提供する上での懸念としては、さらに、サービスプロバイダが恒久的に記憶されたデータをアプリケーションに組込んで、アプリケーションが実行された際にアプリケーションがそのデータを利用できるようにしたいと考えるかもしれないことがある。すると、サービスプロバイダは、アプリケーションが要求した場合に、データが利用可能になるように、記憶されたデータを確立および維持する負担を負わなければならないことがあり得る。
【００２１】
上述のことに基づいて、より効果的にすべての装置で作動するアプリケーションを設計するための改良された技術を提供することが望ましい。また、アプリケーションを作成するための改良された技術を有することが望ましい。さらに、サービスプロバイダが付加的なサービスを提供できるようにする改良された技術を有することが望ましい。記憶されたデータをアプリケーションに組込むための改良された技術を有することも望ましい。
【００２２】
【発明の概要】
サービスによって提供されるコンテンツをカスタマイズするための技術が提供される。一局面によると、サービスによって提供される出力は、媒介物によってカスタマイズされる。要求に応答して、サービスからデータを媒介物で受取る。データはいくつかの出力セグメントまたは変形を含み、その各々が要求を満たす。ある特定の出力セグメントは、その要求に関連するパラメータ、たとえば要求が送られてくるクライアント装置またはネットワークの条件などに基づいて、識別される。要求に対する、パラメータに基づいて最も合致する出力セグメントを含む返答が生成され、その返答がその要求に応答して送られる。
【００２３】
別の局面では、パラメータを条件と比較することによって、各出力セグメントに含まれる１つ以上の条件を満たすかどうかに基づいて、特定の出力セグメントの識別を行なってもよい。特定の出力セグメントの識別は、パラメータを条件の階層の中で条件と比較し、サービスからの出力の中の出力セグメントに対応し、満たされる条件のうち条件の階層の中で最も下にある条件に基づいて、特定の出力セグメントを選択することに基づいて行なってもよい。パラメータおよび条件は、特定のモデルのクライアント装置、クライアント装置のクラスまたは種類、クライアント装置の能力（たとえば、グラフィックを表示する能力）、または要求されたサービスの提供に関連する環境的な条件、たとえば返答が送られるネットワーク上の混雑などを指定してもよい。
【００２４】
以下にこの発明を、同じ参照番号が同じ要素を示す添付の図面によって、限定ではなく、例によって示す。
【００２５】
【好ましい実施例の詳細な説明】
モバイル装置のためのネットワークに基づくオペレーティングシステムが記載される。以下の説明では、説明のため、多くの具体的な詳細を挙げて、この発明を完全に理解できるようにしている。しかしながら、当業者にとっては、個の発明は、これらの具体的な詳細なしに実現可能であることが理解されるであろう。場合によっては、周知の構造および装置をブロック図の形で示して、この発明を不必要にわかりにくくするのを避けた。
【００２６】
以下の説明では、以下の順に現れる表題のもとにさまざまな機能を論じる。
Ｉ．構造的および機能的な概要
Ａ．アプリケーションのホスティング
Ｂ．サービスによって提供されるコンテンツのカスタマイズ
Ｃ．複数のサービスからのコンテンツの提供
Ｄ．媒介物に記憶されるデータへのサービスからのアクセス
Ｅ．オンラインでのアプリケーション開発
ＩＩ．オンラインでのアプリケーション開発
Ａ．アプリケーションおよびサービスの作成−総論
Ｂ．ホストアプリケーションの実装
Ｃ．共有ホストアプリケーションの実装
Ｄ．新しいアプリケーションまたはサービスへのアクセス
ＩＩＩ．装置に特有のマークアップコードの生成
Ａ．装置に特有のフォーマットの生成
Ｂ．要求条件を考慮した出力の生成
Ｃ．ヒントが埋込まれた条件独立出力
Ｄ．埋込まれたヒントを使用して装置の種類を識別する例
Ｅ．条件の階層に基づく出力の生成
Ｆ．要求条件を合致させることによる出力の生成
Ｇ．クライアント装置によってサポートされる言語に基づく出力の選択
Ｈ．条件独立出力の変形のためのミドルウェアトランスフォーマの使用
Ｉ．共有ホストアプリケーションを使用しての出力の生成例
ＩＶ．他のアプリケーションおよびサービスへのアクセス
Ａ．モバイルモジュール
Ｂ．媒介物でのデータの記憶
Ｖ．ハードウェア概要
Ｉ．構造的および機能的な概要
モバイルクライアントなどの装置によってアクセスするためのサービスを提供するのに使用するアプリケーションの作成および実装を容易にする技術を提供する。これらの技術は、エンドユーザによるアプリケーションの使用の特定の状況、たとえば、モバイルクライアントの能力、または顧客がアプリケーションからサービスを要求した際に存在するネットワーク条件などに基づいて、アプリケーションによる出力の生成後に出力を調整することによって、さまざまな装置上で実行することができるアプリケーションを開発することを含む。さらに、これら技術は、サービスの出力、能力および特徴を組合せることを含み、エンドユーザが以前にアクセスしたサービスに戻ることを可能にする技術も含む。さらに、これらの技術は、媒介物にデータを記憶して、サービスに関連するアプリケーションが、変数およびそれら変数の、記憶されるデータに対するマッピングを使用してしてアクセスできるようにすることも含む。
【００２７】
さらに、これら技術は、オンラインソフトウェア開発キット（ＳＤＫ）を提供して、アプリケーション開発者が、特別なクライアント側ソフトウェアを有することなく、アプリケーションを作成、テスト、変更および実装することができるようにすることを含む。開発者は、インターネット上でＳＤＫのウェブサイトによって提供されるインターフェイスを通じて、コードを入力する。ＳＤＫのウェブサイトは、ＸＭＬおよびＨＴＴＰ規格に基づいているため、開発者は、既存のコードを再使用することができる。たとえば、開発者が、「．ａｓｐ」ページにサービスを提供するマイクロソフト（Ｍｉｃｒｏｓｏｆｔ）インターネットインフォメーションサービス（Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅ，ＩＩＳ）サーバを有する場合、オンラインＳＤＫは、開発者の既存のサーバおよびページにアクセスすることができる。
【００２８】
ここで使用する「エンドユーザ」という用語は、装置を使用してサービスまたはアプリケーションにアクセスし得る、いかなる人、組織または他の実体を指す。「エンドユーザ」という用語は、「顧客」という用語を含むが、「顧客」は、必ずしもサービスプロバイダとの商業的な関係を暗示しない。さらに、「エンドユーザ」という用語は、「ユーザ」という用語から区別される。「ユーザ」は、後に説明するように、エンドユーザにサービスを提供するアプリケーションまたはコンピュータプログラムを作成および維持する、開発者およびサービスプロバイダを指す。
【００２９】
Ａ．アプリケーションのホスティング
図１Ａは、この発明の一実施例による、媒介物を通じてアクセスするアプリケーションを介してサービスを提供するためのシステムの高レベルの概要を示すブロック図である。図１は、ホストサーバ１１０を含むネットワーク１００を示す。ネットワーク１００は、イントラネットなどの私的なネットワーク、インターネットなどの公共のネットワーク、または異なるネットワークおよびネットワークの種類の組合せを含むがこれらに限らない、どのような種類のネットワークであってもよい。
【００３０】
ホストサーバ１１０は、たとえばホスティングサービスプロバイダなど、ホストプロバイダまたは単にホストとして知られる媒介物において、１台以上のサーバで実現することができる。ホストの機能は、ホストプロバイダまたは他のアプリケーション開発者のどちからによって開発されたアプリケーションを、ホストサーバ１１０などにインストールし、かつ維持することである。アプリケーションは、通常、たとえばウェブサイト、ページングサービスまたは通信サービスなどのサービスの一部である。ホストは、アプリケーションの「部分的」または「共有」ホスティングを提供してもよく、この場合、アプリケーションは、アプリケーション開発者またはサービスプロバイダに関連するサーバに記憶されるが、ホストを介してアプリケーションにアクセスすることができる。アプリケーションの部分的または共有ホスティングは、ポータルアプリケーションとは区別される。ポータルアプリケーションは、アプリケーション開発者またはサービスプロバイダに関連するサーバに記憶されるが、ホストを介してアクセスされない。エンドユーザは、ホストアプリケーションおよび部分的ホストアプリケーションと対話することによって、ホストを介して他の当事者または他企業によって提供されるサービスにアクセスする。
【００３１】
図示のように、ネットワーク１００は、ユーザ１２０、１２２、１２４も含み、これらは、サーバ１１０および互いにネットワーク１００上で相互に接続される。図１Ａでは、ユーザ１２０、１２２、１２４はサービスプロバイダであって、エンドユーザが使用するサービスを提供してもよい。ユーザ１２０、１２２、１２４は、アプリケーション開発者であって、サービスプロバイダの一部またはサービスプロバイダに関連していてもよい。サービスプロバイダ、アプリケーション開発者および他の当事者は、エンドユーザに提供されるサービスの一部であるアプリケーションを作成および維持する。
【００３２】
サービスの一部であるアプリケーションを、ホスティングプロバイダが、たとえば、ホストサーバ１１０などでホストしてもよい。ユーザ１２４に含まれるアプリケーション１２６によって示されるように、アプリケーションをユーザに関連するサーバに記憶し、ホスティングプロバイダ、たとえばホストサーバ１１０を介してアクセスすることによって、部分的にホストしてもよい。
【００３３】
Ｂ．サービスによって提供されるコンテンツのカスタマイズ
図１Ａは、接続１４０、１４２、１４４によってホストサーバ１１０に接続される、エンドユーザ１３０、１３２、１３４を示す。エンドユーザ１３０、１３２、１３４は、図１のネットワーク１００外に示されるが、エンドユーザ１３０、１３２、１３４または図示されない他のエンドユーザは、ネットワーク１００の一部であってもよい。エンドユーザおよび接続にはさまざまな種類がある。たとえば、エンドユーザ１３０は、たとえば、インターネット、ＤＳＬ接続またはＩＳＤＮを介してなど、さまざまな方法でホストサーバ１１０に接続するデスクトップコンピュータであってもよい。また、エンドユーザ１３２は、セルラーモデム接続を介して、ホストサーバ１１０に接続するＰＤＡであってもよい。さらに、エンドユーザ１３４は、インターネットに接続し、それによってＷＡＰ−ＨＴＴＰゲートウェイを介してホストサーバ１１０に接続する携帯電話であってもよい。
【００３４】
図１Ａは、エンドユーザ１３０とユーザ１２０との間の接続１５０、およびエンドユーザ１３４とユーザ１２４との間の接続１５２も示す。接続１５０および１５２によって、エンドユーザとユーザとの間での直接通信が可能であるため、エンドユーザとユーザとの間の通信がすべてポートサーバ１１０を通じて行なわれるわけではないことが示される。たとえば、エンドユーザ１３０は、デスクトップコンピュータであってもよく、このため、サービスを要求する場合、ユーザ１２０と直接対話することができる。しかしながら、エンドユーザ１３０がユーザ１２０から要求したサービスを、ホストサーバ１１０上に位置するホストアプリケーションによって供給してもよい。エンドユーザ１３０からのサービス要求に応答して、ユーザ１２０は、要求をホストサーバ１１０に送り、接続を介して、要求を満たす出力をホストアプリケーションからエンドユーザ１３０に供給してもよい。ユーザ１２０からの要求に応答して、ホストサーバ１１０は、適切なホストアプリケーションを実行して、接続１４０上で、結果としての出力をエンドユーザ１３０に送ってもよい。
【００３５】
別の例として、エンドユーザ１３４は、ホストサーバ１１０と対話している携帯電話であってもよい。エンドユーザ１３４は、ホストサーバ１１０を介して、たとえばユーザ１２４からサービスを受けるアプリケーション１２６などの共有ホストアプリケーションによって供給されるサービスを要求してもよい。ホストサーバ１１０は、エンドユーザ１３４からのサービスの要求をユーザ１２４に伝える。ユーザ１２４は、たとえばアプリケーション１２６などの適切なアプリケーションを実行し、接続１５２上で、結果としての出力をエンドユーザ１３４に送る。
【００３６】
図１Ａは、モバイル装置のためのネットワークに基づくオペレーティングシステムを提供するためのシステムの代表的な実施例を示すが、実際には、図１Ａに示される構成を何通りにも変形した、はるかに大きくかつ複雑なネットワークを使用してもよい。たとえば、モバイル装置のためのネットワークに基づくオペレーティングシステムは、ホストに関連する２台以上のサーバおよび実質的に無限の数のユーザとエンドユーザとかかわってもよい。さらに、すべてのユーザが、たとえば、ネットワーク１００などの単一のネットワークに含まれることはあり得ない。エンドユーザは、インターネットおよびイントラネットを含む多数のネットワークに位置付けられ得る。同様に、エンドユーザは、ホストサーバおよび１台以上のユーザを含むネットワーク内に位置付けられてもよい。これに加え、ホストプロバイダは、他者によるアプリケーションをホスティングするだけでなく、エンドユーザに直接サービスを提供してもよい。さらに、上述のエンドユーザ、ユーザおよび接続の種類は、単なる例示的な例である。
【００３７】
図１Ｂは、この発明の一実施例による、ホストサーバ１１０の概要を示すブロック図である。ホストサーバ１１０は、アプリケーション１６０、１６２を含み、これらはホストサーバ１１０に記憶されるホストアプリケーションであってもよく、または、アプリケーション１２６と同様に、他のサーバに記憶される共有ホストアプリケーションへのリンクであってもよい。
【００３８】
ホストサーバ１１０は、ミドルウェアトランスフォーマ１１２を含み、サービス要求に関連するパラメータまたは条件に基づいて、アプリケーションの出力を、調整またはカスタマイズされた出力に変換させる。たとえば、エンドユーザが使用するクライアント装置の能力は大きく異なり得る。一実施例によると、アプリケーション開発者は、アプリケーションが出力セグメントとも称される、いくつかの出力を変形したものを含む一般的な出力を生成するように設計して、その出力をクライアント装置に提示または表示する。ミドルウェアトランスフォーマ１１２が一般的な出力を受取る。ミドルウェアトランスフォーマ１１２は、サービス要求に関連するパラメータまたは条件を受取るか、もしくは検知する。次に、ミドルウェアトランスフォーマ１１２は、サービス要求のパラメータまたは条件に基づいて、特定の出力を変形したものまたは選択肢を選択する。
【００３９】
たとえば、クライアントまたはエンドユーザは、地図サービスプロバイダから道案内を要求している携帯電話であってもよい。携帯電話は、グラフィックを表示することができない可能性があるため、地図サービスプロバイダは、その要求に対し、テキストは含むがグラフィックは含まない返答を供給して、所望の経路を示す必要がある。しかしながら、地図サービスプロバイダの顧客の中には、ラップトップコンピュータなど、テキストだけでなくグラフィックを表示できる他の装置を使用する顧客もいるかもしれない。
【００４０】
このため、地図サービスプロバイダが使用するアプリケーションは、要求された道案内についていくつかの変形、たとえば、テキストだけを備えた出力セグメント、ならびにテキストおよびグラフィックを備えた出力セグメントのようないくつかの変形を含む、一般的な出力を生成してもよい。アプリケーションは、一般的な出力をミドルウェアトランスフォーマ１１２に提供し、ミドルウェアトランスフォーマは、たとえばクライアント装置が携帯電話であることを示すデータなど、要求からのパラメータまたは情報を受取る。次に、ミドルウェアトランスフォーマ１１２は、テキストだけを備える出力セグメントを一般的な出力から選択して、カスタマイズされた出力、つまりアプリケーションからのテキストのみの出力セグメントを含む出力を生成し、そのカスタマイズした出力をエンドユーザに送る。別の実施例では、アプリケーションは、出力の包括的なセットを生成し、これをミドルウェアトランスフォーマ１１２が、クライアント装置に基づいて選択されたスタイルシートに基づいて、カスタマイズまたはフォーマットする。
【００４１】
ホストを使用して、一般的な出力を受取り、カスタマイズした出力を生成するアプローチにはいくつか利点がある。たとえば、アプリケーション開発者は、出力を変更するに値し得る特有の条件の各々について、異なるアプリケーションまたは異なる出力ルーチンを書く必要がない。実際、アプリケーション開発者は、それらの条件についてテストを行なうことができる必要すらない。アプリケーション開発者は、特別な条件の各々についての出力の変形を備える１つのアプリケーションを書くことができる。特別な条件は、クライアント装置の特有のモデル、クライアント装置の種類、およびクライアント装置の広いまたは狭いクラス、ネットワークの条件等を含んでもよい。新しい装置および能力が導入されると、ミドルウェアトランスフォーマは、新しいクライアント装置の能力に最も合致する出力の変形を選択することができる。
【００４２】
別の例として、出力セグメントは、要求時に存在する条件、たとえばネットワークの混雑、リクエストの時間またはユーザの位置などに依存してもよく、このことによって、ミドルウェアトランスフォーマは、そのような条件を考慮することにより出力の変形を選択または出力をフォーマットすることが可能になる。したがって、アプリケーション開発者は、さまざまな条件の各々についての出力セグメントを含む一般的な出力を提供するアプリケーションを設計し、要求についての特定の条件に基づいて、ホストがエンドユーザに提供すべき特定の出力を選択できるようにしてもよい。
【００４３】
Ｃ．複数のサービスからのコンテンツの提供
ホストサーバ１１０は、サービスリンカ１１４も含み、エンドユーザからのサービス要求を処理させ、その要求を適切なサービスまたはアプリケーションに送らせて応答を得る。さらに、サービスリンカ１１４は、他のサービスのセッション（またはトランザクション）を活性化させたままにすることができる。たとえば、エンドユーザは、ホストと通信している携帯電話であってもよい。ホストはエンドユーザにサービスの選択肢のリストを提供するが、これは、地図サービスを含んでもよい。エンドユーザが携帯電話を使用して地図サービスを選択する場合、サービスリンカ１１４は、エンドユーザから要求を受取り、その要求を適切なサービスのプロバイダに送る。たとえば、サービスが共有ホストアプリケーションを使用して提供される場合、ワールドワイドウェブ上で、要求を地図サービスプロバイダに関連するサーバに送ってもよい。共有ホストアプリケーションからの要求に対する応答を、一般的な出力の形でホストで受け取り、この一般的な出力を、上述のようにミドルウェアトランスフォーマを使用するなどして、携帯電話用にカスタマイズしてもよい。
【００４４】
別の実施例では、アプリケーションは他のアプリケーションの特徴および出力を組込む。これらのアプリケーションは、モバイルモジュールまたは単にモジュールと称され得る。たとえば、図１Ｂのアプリケーション１６０が道案内を提供する場合、地図サービスプロバイダは、エンドユーザによって指定された目的地での気象に関する情報も含めたいと考えることがあり得る。別の気象アプリケーションを開発する代わりに、この地図サービスプロバイダは、ホストサーバ１１０に関連する気象情報サービスプロバイダによって提供されるホストアプリケーションまたは共有ホストアプリケーションにリンクすることができる。たとえば、アプリケーション１６２は、地図サービスを提供する企業とは異なる企業によって提供される気象アプリケーションまたはモジュールであってよい。しかしながら、両企業ともそのホストサーバに関連するモジュールを有するため、両企業は、各企業のアプリケーションの出力に他方の企業のモジュールへのリンクを含むことができる。それらリンクに基づいて、ミドルウェアトランスフォーマは、一方のアプリケーションからの出力を他方に組込むことができる。またはリンクをエンドユーザに提示して、別のサービスの機能にアクセスできるようにすることもできる。
【００４５】
これに加え、ホストサーバは、２つのサービス間の対話を処理するため、ホストは、どのモジュールがどちらによってコールされたかを追跡して、サービス間の請求を容易にすることができる。さらに、この追跡機能により、１つのモジュールは、別のモジュールの識別を知ることなく、それをコールバックすることができる。たとえば、第１のモジュールが第２のモジュールをコールする場合、追跡機能により、第２のモジュールは、第１のモジュールをコールバックすることができる。結果として、どのサービスもモジュールとして使用することができ、このことは、再使用可能なウェブサービスの他のサービスへの提供とも表現することができる。
【００４６】
Ｄ．媒介物に記憶されるデータへのサービスからのアクセス
ホストサーバ１１０は、データベース１７０も含んで、サービスがホストでデータを記憶するのを支援し、サービスのアプリケーションが使用できるようにする。データベース１７０は、ホストサーバ１１０の一部として示されるが、データベース１７０を、データベース機能を提供するのに好適な別のサーバまたは他の装置によってサポートしてもよい。データベース１７０は、データ構造を含んで、データを記憶し、さらに、変数または識別子の、特有のデータまたは情報アイテムに対するマッピングを記憶してもよい。サービスは、データベース１７０を使用してホストサーバで情報を恒久的に記憶および維持することができるため、サービスは、そのようなデータベースを自分自身でサポートする義務から解放される。たとえば、アプリケーションは識別子「％ｘｙｚロゴ」を備える出力を生成することができるが、この識別子は、マッピングの中で、データベース１７０に記憶されるＸＹＺ企業の特定のグラフィック画像に対応するものとして識別される。別の例として、アプリケーションの出力は変数「％日付」を含んで、エンドユーザからの要求に応答してアプリケーションがアクセスされた際の現在の日付を示してもよい。ミドルウェアトランスフォーマで出力を受取ると、出力の中で、現在の日付が変数％日付にとって代わる。
【００４７】
Ｅ．オンラインでのアプリケーション開発
ホストサーバ１１０は、さらにオンラインソフトウェア開発キット１１６も含むが、これは、開発者がホストサービスに関連するアプリケーションまたはモジュールを作成、編集、テスト、実装および他の管理をするために使用することができるサービスおよびアプリケーションである。一実施例によると、アプリケーション開発者は、ブラウザを使用してホスティングサービスに関連するオンライン開発ウェブサイトにログインし、オンラインソフトウェア開発キット１１６にアクセスする。ログイン後、オンラインソフトウェア開発キット１１６は、開発者のウェブブラウザ上で表示するためのユーザインターフェイスを提供する。このユーザインターフェイスは、ユーザに、たとえば新しいアプリケーションの作成、既存のアプリケーションの変更、アプリケーションのテストまたは既存のアプリケーションの削除などのさまざまな選択肢を提示する。たとえば、ホストアプリケーションを作成には、開発者は、開発者のウェブブラウザを介しユーザインターフェイスを使用してプログラムコードを入力または変更し、その後、モジュールまたはアプリケーション名、もしくは識別子で、そのコードをホストサーバでセーブする。開発者が共有ホストアプリケーションを確立したい場合、開発者は、オンライン開発ウェブサイトにログインし、アプリケーションのＵＲＬを提供する。すると、ホストアプリケーションおよび共有ホストアプリケーションは、すぐに利用可能になる。たとえば、エンドユーザは、ウェブサイトを介してサービスプロバイダにログインして、利用可能なサービスのリストにアクセスすることができる。
【００４８】
ＩＩ．オンラインでのアプリケーション開発
Ａ．アプリケーションおよびサービスの作成−総論
一実施例によると、開発者はクライアント上で稼動するブラウザを使用してウェブサイトにログインし、そのウェブサイトを通じて、開発者は、特別なクライアント側ＳＤＫソフトウェアなしにアプリケーションを開発するために必要なツールにアクセスすることができる。このウェブサイトは、たとえば、オンラインソフトウェア開発キット（ＳＤＫ）を提供またはホストしている場合に、開発ウェブサイト、また「ＳＤＫウェブサイト」と称され得る。
【００４９】
ここで使用する「開発者」は、「サービスプロバイダ」および「ユーザ」（開発者はオンライン開発ウェブサイトを使用するため）と同義である。さらに、「ユーザ」は、開発者によって提供されるサービスを使用するエンドユーザまたは顧客から区別される。
【００５０】
アプリケーション開発ツールのプロバイダおよびオンライン開発ウェブサイトのホストは、開発プロバイダ、ＳＤＫプロバイダ、または単にホストと称され得る。開発プロバイダは、通常１台以上のサーバを使用して、開発ウェブサイトおよびそこで提供されるツールをサポートする。
【００５１】
開発ウェブサイトへのアクセスは、ユーザに名前およびパスワードを有することを要求することによって制御することができる。ユーザがウェブサイトへのアクセスを得ると、ユーザは、モバイルアプリケーション（ここではサービスとも称される）のリストを提示されるが、これは開発者またはユーザが以前に作成したものである。ユーザは、たとえば開発ウェブサイトプロバイダによって提供されるサンプルなどの他のサービスへのアクセスを有してもよい。開発ウェブサイトは、ユーザに、たとえば新しいサービスの追加、既存のサービスの変更または既存のサービスの削除などのいくつかの選択肢を提示してもよい。たとえば、ユーザが「サービスの追加」選択肢を選択した場合、ユーザは、ユーザインターフェイスを提示され、それによって、サービスを追加することができる。
【００５２】
一実施例によると、サービスは、ホストアプリケーションか、またはポータルアプリケーションのどちらかであってもよい。ホストアプリケーションは、そのコードが、ホストウェブサイトとも称される開発ウェブサイトで維持されているアプリケーションである。ポータルアプリケーションは、そのコードがポータルアプリケーションの開発者に関連する別のウェブサイトで維持されているアプリケーションであり、通常、顧客またはエンドユーザは、開発者のウェブサイトを介してアクセスする。しかしながら、別の実施例によると、開発ウェブサイトを通じて、ポータルアプリケーションにアクセスするか、または、クライアントにサービスを提供してもよく、この場合、ポータルアプリケーションは、「共有ホストアプリケーション」または「部分的ホストアプリケーション」と称することができる。
【００５３】
Ｂ．ホストアプリケーションの実装
ホストアプリケーションの実装には、たとえば、まずアプリケーションを作成し、次にアプリケーションを編集、アプリケーションをテストするなどのいくつかのステップがかかわり得る。一実施例では、ホストアプリケーションを作成するために、開発ウェブサイトは、アプリケーション用にコードを書き編集するためのインターフェイスを開発者またはユーザに提供する。インターフェイスは、編集ウインドウまたは編集フィールドを含んでもよく、ユーザはこれを使用してアプリケーションのコードを打ち込むことができる。同様に、既存のアプリケーションを編集するために、インターフェイスがユーザに提示され、これが既存のアプリケーションコードを編集ウインドウでユーザに表示するため、ユーザは、選択したアプリケーションのコードを編集することができる。
【００５４】
アプリケーションコードは、適切なマークアップ言語（ＭＬ）、たとえばエクステンシブルマークアップ言語（ＸＭＬ）などで書くことができる。一実施例によると、コードは、ここで「ポータル・ツー・ゴー（Ｐｏｒｔａｌ−ｔｏ−ｇｏ）ＸＭＬ」と称されるマークアップ言語で書かれる。「ポータル・ツー・ゴー」および「ポータル・ツー・ゴーＸＭＬ」は、それぞれ、Ｏｒａｃｌｅ９ｉＡＳＷｉｒｅｌｅｓｓおよびＯｒａｃｌｅ９ｉＡＳＷｉｒｅｌｅｓｓＸＭＬ（または単にＩＡＳＷｉｒｅｌｅｓｓＸＭＬ）と称してもよい。
【００５５】
ポータル・ツー・ゴーＸＭＬは、ＸＭＬタグのセットからなり、これを使用して代替の出力セグメント間の境界を示すことができる。出力セグメントのセットの中の各出力セグメントは、たとえば通常スクリーンが小さいモバイル装置、および音声機能を持つ他の装置などの、ある装置の専用に設計してもよい。
【００５６】
ポータル・ツー・ゴーＸＭＬは、たとえばジャバ（Ｊａｖａ）（Ｒ）サーバページ（Ｓｅｒｖｅｒ Ｐａｇｅｓ）、ＣＧＩ、またはアクティブサーバページ（Ａｃｔｉｖｅ Ｓｅｒｖｅｒ Ｐａｇｅｓ）などのダイナミックＨＴＭＬを生成する従来の手段のどれを使用しても生成することができ、コードまたはスクリプトは、ＨＴＭＬを生成する代わりに、ポータル・ツー・ゴーＸＭＬを生成する。ポータル・ツー・ゴーＸＭＬなどの、このようなマークアップ言語の詳細は、文書タイプ規定（Ｄｏｃｕｍｅｎｔ Ｔｙｐｅ Ｄｅｆｉｎｉｔｉｏｎ，ＤＴＤ）で規定することができる。たとえば、一実施例で実現されるポータル・ツー・ゴーＸＭＬのＤＴＤは、２０００年９月６日に出願された米国仮出願連続番号第６０／２３０，４８９号に記載される。
【００５７】
別の実施例によると、ホストアプリケーションのアプリケーションコード、およびコードを入力および編集するために使用するユーザインターフェイスを生成させるコードは、ともに開発プロバイダに関連する１台以上のサーバに記憶される。結果として、モバイルアプリケーションを開発および実装するために必要なクライアント側ソフトウェアは、ネットスケープナビゲータ（Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ）などのウェブブラウザのみである。
【００５８】
ユーザが新しいアプリケーションのコードの入力を完了、または既存のアプリケーションのコードの編集を完了した場合、ユーザは、インターフェイスに示されるコードをセーブすることができる。コードを「セーブ」する機能は、インターフェイスに含まれる、たとえばボタンなどのオブジェクトであってもよい。オブジェクトの上をクリックすることにより、コードはクライアントから遠隔にあるサーバ、たとえば開発プロバイダに関連するサーバなどに提出されるか、または送られる。新しいアプリケーションを作成している場合、ユーザは、サービス名を指定し、コードはそのサービス名に関連してセーブされる。新しいコードがセーブされると、ユーザおよびエンドユーザが開発ウェブサイトにログインした際、その新しいサービス名が、示される既存のサービスのリストの中に表示される。既存のアプリケーションを変更している場合、ユーザは、既存のサービス名でコードをセーブするか、または新しいサービス名でコードをセーブするかを選択することができる。
【００５９】
アプリケーションをテストするには、ユーザは、モバイル装置またはモバイル装置シミュレータを使用し、開発ウェブサイトを介してアプリケーションまたはサービスにアクセスすることができる。これについては、「新しいアプリケーションまたはサービスへのアクセス」のところで詳細に述べる。開発ウェブサイトを介して実装されるホストアプリケーションは、ユーザがテストをするために、およびエンドユーザがホストウェブサイトを介して使用するために、すぐに利用可能である。
【００６０】
Ｃ．共有ホストアプリケーションの実装
別の実施例では、共有ホストアプリケーションを作成するには、ユーザは、ポータル・ツー・ゴーＸＭＬ文書、または、ポータル・ツー・ゴーＸＭＬ文書を出力として生成するアプリケーションプログラムを書く。「部分的ホストアプリケーション」または「共有ホストアプリケーション」という用語を使用して、ＸＭＬ文書、または、ＸＭＬ文書を出力として生成するアプリケーションを指してもよい。共有ホストアプリケーションは、たとえば、アプリケーションの開発者自身のウェブサイトにセーブすることができる。次にユーザは、たとえば、アプリケーション開発者のウェブサイトにサービスを提供するＨＴＴＰリスナー／ウェブサーバなどを使用して、あるＵＲＬをその共有ホストアプリケーションに関連付ける。その後、開発ウェブサイトまたはＳＤＫウェブにログインし、サービス名およびその共有ホストアプリケーションに関連するＵＲＬを提供することによって、その共有ホストアプリケーションは「サービス」として追加される。
【００６１】
Ｄ．新しいアプリケーションまたはサービスへのアクセス
サービスが作成および／または改訂されると、サーバが存在するネットワーク（たとえばインターネット）に接続することができるエンドユーザまたは顧客は、そのサービスにアクセスすることができる。サービスにアクセスするプロセスは、エンドユーザの種類に基づいて異なり得る。たとえば、デスクトップコンピュータは、ダイヤルアップ回線、ＤＳＬ接続、ケーブルモデム、ＩＳＤＮ接続または他の利用可能な多くの方法を通じてインターネットに接続し得る。ＷＡＰ電話は、たとえば、ＷＡＰ−ＨＴＴＰゲートウェイなどを通じるなどして同期プロトコルを使用して、またはシンプルメールトランスファープロトコル（ＳＭＴＰ）またはショートメッセージサービス（ＳＭＳ）プロトコルなどの非同期プロトコルを使用して、無線接続でインターネットに接続可能である。
【００６２】
一般的に、エンドユーザが開発ウェブサイトにログインすると、利用可能なサービスのリストを提示される。エンドユーザは、作成および／または変更されたばかりのサービスを選択してもよい。サービスの選択に応答して、そのサービスに関連するアプリケーションが入手される。アプリケーションは、ポータル・ツー・ゴーＸＭＬ文書または好適なマークアップ言語で書かれた別の文書に関連してもよい。たとえば、ホストアプリケーションの場合、媒介物に関連するサーバ（たとえばホスト）にセーブされたポータル・ツー・ゴーＸＭＬを検索することによって、ＸＭＬを入手してもよい。ポータルアプリケーションの場合、開発者がそのサービスについて指定したＵＲＬに要求を送ってもよい。ＵＲＬを管理するウェブサーバは、ポータルアプリケーションを呼出し、そのポータルアプリケーションに関連するポータル・ツー・ゴーＸＭＬを、媒介物に関連するサーバに送り返してもよい。一旦サービスのポータル・ツー・ゴーＸＭＬがホストアプリケーションまたはポータルアプリケーションのどちらかについて入手されると、媒介物に関連するサーバは、そのポータル・ツー・ゴーＸＭＬを使用して、選択されたサービスを、エンドユーザに関連するクライアントに提供する。
【００６３】
ＩＩＩ．装置特有のマークアップコードの生成
Ａ．装置特有のフォーマットの生成
一実施例によると、サービスを呼出すクライアント装置の種類にかかわりなく、ポータル・ツー・ゴーＸＭＬなどの、マークアップ言語の出力がサービスによって生成される。一実施例によると、出力をクライアントに提供する前に、クライアントの装置の種類に基づいて１つ以上のエクステンシブルスタイルシート言語（ＸＳＬ）スタイルシートが選択される。ＸＳＬスタイルシートは、２０００年８月４日に出願された、米国出願連続番号第０９／６３１，８８４号の中でさらに詳細に記載され、その出願の開示全体が、その全文がここに記載されているかのごとく、引用により援用される。
【００６４】
選択されたスタイルシートを、サービスからのＸＭＬ出力に適用して、カスタマイズした出力を生成するが、これは、サービスを要求したクライアント専用にフォーマットされている。たとえば、モバイルアプリケーションによる同じＸＭＬ出力を、サービスを要求したクライアントの種類に依存して、次の３つの方法、すなわち（１）携帯電話のディスプレイ上の選択肢のリスト、（２）ブラウザ上のプルダウンメニュー、（３）電話の音声インタフェースで音声で提示される選択肢のリストによって、最終的に操作することができる。アプリケーション開発者は、何ら特別なプログラミングをする必要なく、どの装置もサポートすることができる。なぜならアプリケーションは、サービスの要求に使用される装置に関係なく、同じＸＭＬ出力を生成するように設計され、装置に特有のフォーマットは、たとえば媒介物が装置専用のＸＳＬスタイルシートを適用するなどによって、アプリケーション外で行なわれるためである。
【００６５】
さらに、コードの実行およびその出力へのＸＳＬスタイルシートの適用は、ホストを介して行なわれるため、すべてのホストアプリケーションおよびポータルアプリケーションは、ホストが新しい装置のためのＸＳＬスタイルシートをインストールするたびに、自動的に新しい装置に対する装置に特有のサポートをできるようになる。アプリケーション開発者は、付加的または新たに開発されたクライアント装置をサポートするために、アプリケーションコードを変更する必要はない。もちろん、開発者が改良されたまたは付加された能力を利用したいと考える場合、開発者は、アプリケーションを更新して、そのような能力について付加的な出力セグメントまたは変形を提供してもよい。
【００６６】
Ｂ．要求条件を考慮した出力の生成
アプリケーションを介してサービスを提供する上でのもう１つの問題は、アプリケーションが使用されるときに存在する特有の状況にかかわりなく、アプリケーションが同じように機能することである。たとえば、ユーザがアプリケーションにアクセスしたときのネットワークの混雑に基づいて、アプリケーションの出力を変更することが望ましい場合があり得る。ネットワークがひどく混雑している場合、そのように混雑がひどい間は、出力で提供される詳細の量を制限する方がよい場合があり得る。繰返しになるが、アプリケーションプログラマは、最小高分母アプローチをとって、最悪の場合の条件用にアプリケーションを設計することができる。しかしながら、このアプローチは、条件が改善された場合に、改善された条件を利用することができない。プログラマがより高レベルの詳細を選んだ場合、アプリケーションがクライアント装置に出力を届ける能力は、ネットワークのひどい混雑時には低下するであろう。
【００６７】
サービス要求に関連する、条件、パラメータおよび特徴（「要求条件」とも称される）を考慮した出力を生成するための技術が提供される。要求条件は、たとえば、たとえば装置の種類など、サービスを要求しているクライアントの種類についての情報、サービス要求が行なわれたかまたはサービスへの応答が行なわれた時間などの環境的な条件、またはサービスが要求または供給されるネットワークの混雑などの情報を含む。
【００６８】
一実施例によると、アプリケーションは、要求条件にかかわりなく同じ出力を生成し続ける。アプリケーションの出力は、要求条件にかかわりなく同じであるため、これは「条件独立出力」と称される。
【００６９】
別の実施例によると、アプリケーションによって生成される条件独立出力は、ある要求条件でどのように出力を処理するべきかについての「ヒント」（または基準、条件または他の手引き）を含む。ミドルウェアトランスフォーマが提供され、これが条件独立出力を受取り、そこに含まれるヒントを、クライアントおよび要求条件についての知識とともに使用して、条件独立出力を「条件に特有の出力」に変換する。この出力は、「条件従属出力」とも称され得る。条件に特有の出力は、その出力を生成したサービスを要求したクライアントに提供される。ミドルウェアトランスフォーマは、通常ホストに関連し、ホストに関連するサーバによって提供され得るが、ミドルウェアトランスフォーマは、ホストに関連する実現例に限定されない。
【００７０】
Ｃ．ヒントが埋込まれた条件独立出力
一実施例によると、アプリケーションプログラマは、要求の条件に基づいて出力をどのように変換するべきかについての「ヒント」を含む出力を生成するようにアプリケーションの設計を行なう。一実現例によると、アプリケーションプログラマは、アプリケーションに対する要求、つまり出力の生成につながった要求を満たす出力のいくつかの変形を指し示す出力を生成するようにアプリケーションを設計する。出力の変形は、代替の出力セグメントとも称され得る。
【００７１】
アプリケーションからの出力は、１つ以上の特定の基準または条件を含み、これらは、代替の出力セグメントの各々に関連する。ミドルウェアトランスフォーマを使用して、要求の条件を、各代替の出力セグメントに関連する基準または条件に最も合致させる代替の出力セグメントを選択する。特定の代替出力セグメントに関連する条件が満たされるか否か（または条件が当てはまるか当てはまらないか）に基づいて、合致を判定してもよい。
【００７２】
たとえば、アプリケーションの出力が、ＸＭＬなどのマークアップ言語の形である場合、出力は以下のような形を有するコードのセクションを含んでもよい。
【００７３】
＜ｓｅｃｔｉｏｎ＞
＜ｃｏｎｄｉｔｉｏｎ １＞
条件１が当てはまる場合にこれを使用する
＜／ｃｏｎｄｉｔｉｏｎ １＞
＜ｃｏｎｄｉｔｉｏｎ ２＞
条件２が当てはまり、条件３が当てはまらない場合にこれを使用する
＜ｃｏｎｄｉｔｉｏｎ ３＞
条件３が当てはまる場合にこれを使用する
＜／ｃｏｎｄｉｔｉｏｎ ３＞
＜／ｃｏｎｄｉｔｉｏｎ ２＞
その他の条件すべてについてこれを使用する
＜／ｓｅｃｔｉｏｎ＞
アプリケーションは、エンドユーザがサービスの要求を行なうときに存在するであろう要求の条件に関わりなく上述の出力を生成する。ミドルウェアトランスフォーマは、アプリケーションから条件独立出力を受取った後、条件１、２および３のいずれかが当てはまるかどうかを判定する。たとえば、条件１が当てはまる場合、ミドルウェアトランスフォーマは、条件独立出力を変形して、以下のような条件従属出力を生成する。
【００７４】
＜ｓｅｃｔｉｏｎ＞
条件１が当てはまる場合にこれを使用する
＜／ｓｅｃｔｉｏｎ＞
条件２は当てはまるが、条件３は当てはまらない場合、ミドルウェアトランスフォーマは、条件独立出力を変形して、以下のような条件従属出力を生成する。
【００７５】
＜ｓｅｃｔｉｏｎ＞
条件２が当てはまり、条件３が当てはまらない場合にこれを使用する
＜／ｓｅｃｔｉｏｎ＞
条件２および３が当てはまる場合、ミドルウェアトランスフォーマは、条件独立出力を変形して、以下の条件従属出力を生成する。
【００７６】
＜ｓｅｃｔｉｏｎ＞
条件３が当てはまる場合にこれを使用する
＜／ｓｅｃｔｉｏｎ＞
条件１および２が当てはまらない場合、ミドルウェアトランスフォーマは、条件独立出力を変形して、以下の条件従属出力を生成する。
【００７７】
＜ｓｅｃｔｉｏｎ＞
その他の条件すべてについてこれを使用する
＜／ｓｅｃｔｉｏｎ＞
この例の場合、条件２および３は互いに関連する。つまり、条件３に関連する出力セグメントは、条件２および３の両方が当てはまらない限り実行されない。
【００７８】
たとえば１つの条件が別の条件のサブセットである場合に、条件間で階層を指定する技術を使用することができる。たとえば、条件２は、しきい値量と比較してネットワークのトラフィック量が異常である（たとえばネットワークの混雑）ということであってもよく、条件３は、指定された限界を超えることによって明らかであるように、ネットワークのトラフィックが極度に重いということであってもよい。したがって、ネットワークの混雑が普通であり、条件２は当てはまるが条件３は当てはまらない場合、「条件２が当てはまり、条件３が当てはまらない場合にこれを使用する」に対応する実際の命令またはステートメントは、異常に詳細なグラフィックは伝送すべきでないと指定してもよい。極度にネットワークが混雑している場合など、条件３が当てはまる場合、「条件３が当てはまる場合にこれを使用する」に対応する実際の命令またはステートメントは、グラフィックは伝送すべきでないと指定してもよい。
【００７９】
ヒントが埋込まれた条件独立出力を使用することによって、アプリケーション開発者は、サービスアプリケーションに柔軟性を持たせて、クライアントがアプリケーションからサービスを要求するときにのみ知り得る変数を処理するができる。アプリケーションの出力に柔軟性を組込むことによって、クライアントがアプリケーションに対して要求を行なったときに存在する状況に基づいて、アプリケーションは、出力を調整して最適な性能を発揮することができ、最小単位の共通の要素アプローチの欠点が回避される。さらに、アプリケーション自身は、代替の出力セグメント選択する基礎となる条件を検知する能力を持つ必要はない。なぜならホストがその機能を処理するためである。
【００８０】
Ｄ．埋込まれたヒントを使用して装置の種類を識別する例
説明のため、代替の出力セグメントに関連する条件が、要求を行なうクライアントの装置の種類である、一実施例を記載する。そのような実現例では、アプリケーションによって生成される条件独立出力は、以下のような形を有してもよい。
【００８１】
＜ｓｅｃｔｉｏｎ＞
＜ｄｅｓｋｔｏｐ＞
クライアントがデスクトップコンピュータである場合にこれを使用する
＜／ｄｅｓｋｔｏｐ＞
＜ｐｈｏｎｅ＞
クライアントが電話である場合にこれを使用する
＜ＷＡＰ＞
クライアントがＷＡＰ電話である場合にこれを使用する
＜／ＷＡＰ＞
＜／ｐｈｏｎｅ＞
その他の装置すべてについてこれを使用する
＜／ｓｅｃｔｉｏｎ＞
要求条件に関係なく、アプリケーションは、この出力を生成する。アプリケーションから条件独立出力を受取ると、ミドルウェアトランスフォーマは、クライアントが代替のセグメントタグのどれかに対応するかどうかを判定する。たとえば、上述のＸＭＬ出力を使用すると、クライアントがデスクトップコンピュータである場合、クライアントは＜ｄｅｓｋｔｏｐ＞タグに合致し、ミドルウェアトランスフォーマは、条件独立出力を変形して、以下の条件従属出力を生成する。
【００８２】
＜ｓｅｃｔｉｏｎ＞
クライアントがデスクトップコンピュータである場合にこれを使用する
＜／ｓｅｃｔｉｏｎ＞
クライアントが電話であるが、ＷＡＰ電話でない場合、クライアントは、＜ｐｈｏｎｅ＞タグに合致し、ミドルウェアトランスフォーマは、条件独立出力を変形して以下の条件従属出力を生成する。
【００８３】
＜ｓｅｃｔｉｏｎ＞
クライアントが電話である場合にこれを使用する
＜／ｓｅｃｔｉｏｎ＞
クライアントがＷＡＰ電話である場合、クライアントは＜ｐｈｏｎｅ＞タグおよび＜ＷＡＰ＞タグの両方に合致する。＜ＷＡＰ＞タグは、＜ｐｈｏｎｅ＞タグより特有であるため、ミドルウェアトランスフォーマは、条件独立出力を変形して、以下の条件従属出力を生成する。
【００８４】
＜ｓｅｃｔｉｏｎ＞
クライアントがＷＡＰ電話である場合にこれを使用する
＜／ｓｅｃｔｉｏｎ＞
クライアントがデスクトップコンピュータでも電話でもない場合、クライアントは、代替のセグメントタグのどれにも合致せず、ミドルウェアトランスフォーマは、条件独立出力を変換して、以下の条件従属出力を生成する。
【００８５】
＜ｓｅｃｔｉｏｎ＞
その他の装置すべてについてこれを使用する
＜／ｓｅｃｔｉｏｎ＞
埋込まれたヒントを使用して装置の種類を識別するアプローチによって、アプリケーション開発者は、すべての装置に使用することができる１セットのコードを書くことができるが、アプリケーションコードが代替セグメントタグを含んで、能力が異なるさまざまな装置のためにアプリケーションの出力をカスタマイズしてもよい。上述の例で、クライアントがデスクトップコンピュータである場合、フルテキスト、グラフィックおよび音声のコンテンツを送ることができる。なぜなら、デスクトップコンピュータは、３つの種類のコンテンツすべてを容易に処理することができるためである。クライアントが携帯電話である場合、携帯電話はそのようなグラフィックをディスプレイに表示できない可能性が高いため、グラフィックは送ることができないであろう。さらに、上述の例で電話がＷＡＰ電話である場合、アプリケーションは、ＷＡＰプロトコルに特有の出力を生成することができる。
【００８６】
さらに、クライアント装置が、列挙されたものでない場合、出力についてのデフォルトの構成を使用することができる（たとえば、上述の「その他の装置のすべてについてこれを使用する」代替のセグメントタグ）。デフォルトの条件は、最小単位の共通の要素アプローチに基づいて出力を指定し得るため、どのクライアントもその出力を処理することができる。しかしながら、装置が、たとえばデスクトップ装置、電話またはＷＡＰ電話など、具体的に挙げられている種類である場合、アプリケーション開発者は、そのようなデフォルトの構成に依存する必要はない。最後に、アプリケーション完成後に作られたクライアント装置であっても、それら装置が、指定された装置の種類の１つである場合、たとえば上述の例でデスクトップコンピュータまたは電話などである場合、それらの改良された能力を生かした出力を受取ることができる。したがって、未来の装置は、アプリケーション開発者がそのサービスにコードを書いたときに未知であったという理由だけで、最も基本的またはデフォルトの出力を使用することを余儀なくされる必要はない。
【００８７】
Ｅ．条件の階層の基づいた出力の生成
一実施例によると、条件の階層の中のノードに対応する代替セグメントのタグをサポートするプログラミング言語が提供される。条件の階層の中で最も一般的（「最も上にある」）ノードは、デフォルトのノードである。その他のノードは、特有の条件に対応する。条件の階層の中で最も特有のノードは、たとえば装置の特有のモデル、または特有のモデルの特有のバージョンに対応してもよい。他の中間のノードは、装置のクラスまたは種類、たとえば携帯電話またはページャなどに対応してもよい。
【００８８】
一実施例によると、条件の階層の中のノードは、親子関係に従って、互いに関連付けられる。所与の親のすべての子ノードは、親に関連するカテゴリのサブカテゴリに対応する。
【００８９】
図２は、そのような条件の階層の１つを示す。図２の中で、示される階層の「すべての装置」ノード２００は、最も上にある、またはデフォルトのノードである。すべての装置ノード２００は、その下にいくつかの子ノード、たとえば、「音声」ノード２１０、「デスクトップ」ノード２１２、「ＰＤＡ」ノード２１４、「ページャ」ノード２１６および「電話」ノード２１８を有し、これらは、サービスにアクセスし得る装置の種類の幅広い分類に対応する。
【００９０】
デスクトップノード２１２も、それ自身の子ノード、つまり、「ユニックス（Ｕｎｉｘ）（Ｒ）」ノード２２０および「ウインドウズ（ｗｉｎｄｏｗｓ）（Ｒ）」ノードを有し、これらは、デスクトップオペレーティングシステムの２つの例に対応する。同様に、ユニックスノード２２０は、２つの子ノード、「ソラリス（Ｓｏｌａｒｉｓ）」ノード２２４および「リナックス（Ｌｉｎｕｘ）（Ｒ）」ノード２２６を有し、これらはユニックス（Ｒ）オペレーティングシステムの２つのバージョンに対応する。同じように、電話ノード２１８は、いくつかの子ノード、つまり、「ＷＭＬ」ノード２３０、「ＨＤＭＬ」ノード２３２および「ＣＨＴＭＬ」ノード２３４を有し、これらはそれぞれ無線マークアップ言語（ＷＭＬ）、ハンドヘルド装置マークアップ言語（ＨＤＭＬ）およびコンパクトハイパーテキストマークアップ言語（ＣＨＴＭＬ）を使用する電話に対応する。同様に、ＷＭＬノード２３０は３つの子ノード、「ノキア（Ｎｏｋｉａ）７１１０」ノード２４０、「ＴＣ ４４１１ Ｖ１」ノード２４２およびＴＣ ４４１１ Ｖ２ノード２４４を有し、これらはそれぞれ、ノキアモデル７１１０携帯電話、およびＴＣモデル４４１１電話のバージョン１および２に対応する。
【００９１】
図２に示される条件の階層を例にとると、アプリケーションプログラマは、メニューアイテムに以下の出力を生成するプログラムを設計することができる。
【００９２】
＜ｍｅｎｕ ｉｔｅｍ＞
戻る
＜ｄｅｓｋｔｏｐ＞
戻り方を生成
＜／ｄｅｓｋｔｏｐ＞
＜ｖｏｉｃｅ＞
戻り方を生成
＜／ｖｏｉｃｅ＞
＜ｐｈｏｎｅ＞
戻り方
＜ＴＣ ４４１１ Ｖ２＞
戻り方を生成
＜／ＴＣ ４４１ Ｖ２＞
＜／ｐｈｏｎｅ＞
＜／ｍｅｎｕ ｉｔｅｍ＞
ミドルウェアトランスフォーマが条件独立出力を受取ると、トランスフォーマは、出力を送るべきクライアントの種類を判定し、条件に特有の出力を生成する。つまり、デスクトップクライアント、音声クライアントおよび電話クライアント以外のすべてのクライアントに対しては、メニューアイテムは「戻る」である。デスクトップクライアント、音声クライアントおよび具体的な電話モデルＴＣ ４４１ Ｖ２に対しては、メニューアイテムは「戻り方を生成」である。最後に、ＴＣ ４４１ Ｖ２以外の電話モデルに対しては、メニューアイテムは「戻り方」である。たとえば、ＴＣ ４４１ Ｖ２が従来の携帯電話より長いメニューアイテムを表示できる場合、モデルＴＣ ４４１ Ｖ２を特別に扱うことが望ましい。
【００９３】
一実施例では、条件に特有の出力が作成された後、ＸＳＬスタイルシートを適用して、出力を送るべきクライアントのニーズに従い出力をフォーマットすることができる。代替の実施例では、上述の出力の処理に加え、ミドルウェアトランスフォーマは、１つ以上のＸＳＬスタイルシートを適用することによって、または他の手段によって、特有の装置について出力をフォーマットする。
【００９４】
ミドルウェアトランスフォーマが適切な出力の変形を行なうために、「ミドルウェアホスト」としても知られる、ミドルウェアトランスフォーマを制御する当事者が、（１）条件の階層、（２）条件の階層のノードに関連したタグおよび（３）条件の階層のノードと要求の条件との間の相互関係を示すデータを維持する。
【００９５】
たとえば、ミドルウェアトランスフォーマが、図２に示される条件の階層をサポートすると仮定する。ミドルウェアホストは、さまざまな種類の情報、たとえばＸＭＬのタグの、条件の階層のノードに対する関連、およびノードの互いに対する関係などの情報を示すデータを維持してもよい。以下は、ミドルウェアホストによって維持され得るデータの代表的な例である。
【００９６】
（ａ） 電話ノード２１８は、すべての装置ノード２００の子である
（ｂ） タグ＜ｐｈｏｎｅ＞および＜／ｐｈｏｎｅ＞は電話ノード２１８に関連する
（ｃ） ＷＭＬノード２３０は電話ノード２１８の子である
（ｄ） タグ＜ＷＭＬ＞および＜／ＷＭＬ＞はＷＭＬノード２３０に関連する
（ｅ） ＴＣ ４４１ Ｖ１ノード２４２はＷＭＬノード２３０の子である
（ｆ） タグ＜ＴＣ ４４１ Ｖ１＞および＜／ＴＣ ４４１ Ｖ１＞は、ＴＣ ４４１ Ｖ１ノード２４２に関連する
（ｇ） 要求条件「クライアント装置＝ＴＣ ４４１ Ｖ１」はＴＣ ４４１ Ｖ１ノード２４２に関連する
サービスプロバイダまたは開発プロバイダが条件の階層を作ってもよい。条件の階層の使用をアプリケーションに組込むことで、サービスプロバイダは、ＰＤＡなどの幅広いクラスの装置、ユニックス（Ｒ）デスクトップコンピュータなどのより狭いクラスの装置、またはノキアモデル７１１０電話などの特有の装置をサポートすることができる。アプリケーション開発者は、幅広いクラス、狭いクラスまたは特有の装置に基づいた装置の能力に基づいて、サービスについて出力をカスタマイズすることができる。
【００９７】
Ｆ．要求条件を合致させることによる出力の生成
ミドルウェアトランスフォーマがクライアントに送るべき条件独立出力を受取り、条件独立出力が代替の出力セグメントのセットを含む場合、ミドルウェアトランスフォーマは関連する要求条件を検査する。たとえば、代替の出力セグメントがさまざまな種類のクライアント装置に関連する場合、ミドルウェアトランスフォーマは、出力を送るべきクライアントの装置の種類を判定する。適用可能な要求の条件に基づいて、ミドルウェアトランスフォーマは、最も具体的に要求条件に合致する出力セグメントを選択する。
【００９８】
一実施例によると、ミドルウェアトランスフォーマが代替の出力セグメントを含む出力を受取ると、ミドルウェアトランスフォーマは、図３のフローチャートに概要が示されるプロセスを介して、要求条件に最も具体的に合致する出力セグメントを選択する。ステップ３００において、条件の階層の中で最も上にあるノード（たとえば図２の「すべての装置」ノード２００）が現在のノードとして設定される。
【００９９】
次にステップ３１０において、現在のノードの子に対応する代替の出力セグメントが識別される。再び図２を参照すると、現在のノードが「すべての装置」ノード２００である場合、ミドルウェアトランスフォーマは、子、すなわち音声ノード２１０、デスクトップノード２１２、ＰＤＡノード２１４、ページャノード２１６および電話ノード２１８を識別する。
【０１００】
ステップ３２０において、現在のノードの識別された子に関連する条件のいずれかが当てはまるかどうかが判定される。たとえば、サービス要求を行なう装置がページャである場合、ページャノード２１６に関連する条件が当てはまるであろうが、電話ノード２１８に関連する条件、および「すべての装置」ノード２００の他の子ノードに関連する条件は当てはまらないであろう。これに対し、装置が電話である場合、電話ノード２１８に関連する条件は当てはまり、「すべての装置」ノード２００の残りの子ノードに関連する残りの条件は当てはまらないであろう。
【０１０１】
現在のノードの子に関連する条件が当てはまる場合、ステップ３３０はその子ノードを新しい現在のノードとして設定し、プロセスはステップ３１０に戻る。たとえば、現在のノードが「すべての装置」ノード２００であり、装置がページャである場合、ページャノード２１６に関連する条件が当てはまる。ステップ３３０によると、ページャノード２１６が現在のノードとして設定され、プロセスはステップ３１０に戻る。
【０１０２】
現在のノードの子のいずれかに関連する条件がどれも当てはまらない場合、ステップ３４０は現在のノードに関連する出力セグメントを選択する。たとえば、現在のノードが「すべての装置」ノード２００であり、サービスを要求する装置が、条件の階層が作成されたときに未知であった全く新しい種類の未来の装置である場合、恐らく「すべての装置」ノード２００の子ノードのいずれかに関する条件は、どれも当てはまらないであろう。したがって、ステップ３４０によると、現在のノード、この例では「すべての装置」ノード２００である現在のノードに関連する出力セグメントが選択される。たとえば、「すべての装置」ノード２００に関連する出力は、どの装置でも表示することができるか（たとえば最小単位の共通の要素アプローチ）、またはより高い最低限の能力レベルを備えた装置で表示することができる。
【０１０３】
たとえば、アプリケーションの条件独立出力が以下のようであり、代替のセグメントのタグが図２に示されるノードに対応すると仮定する。
【０１０４】
＜ｍｅｎｕ ｉｔｅｍ＞
戻る
＜ｄｅｓｋｔｏｐ＞
戻り方を生成
＜／ｄｅｓｋｔｏｐ＞
＜ｖｏｉｃｅ＞
戻り方を生成
＜／ｖｏｉｃｅ＞
＜ｐｈｏｎｅ＞
戻り
＜ＷＭＬ＞
戻り方
＜ＴＣ ４４１ Ｖ２＞
戻り方を生成
＜／ＴＣ ４４１ Ｖ２＞
＜／ＷＭＬ＞
＜／ｐｈｏｎｅ＞
＜／ｍｅｎｕ ｉｔｅｍ＞
さらに、出力を送るべきクライアントが標準名称「ＴＣ ４４１ Ｖ１」によって識別される装置であると仮定する。図２のＴＣ ４４１ Ｖ１ノード２４２に関連する条件、およびＴＣ ４４１ Ｖ１ノードが由来するすべてのノード（すなわち電話ノード２１８およびＷＭＬノード２３０）に関連する条件が当てはまる。
【０１０５】
上述のＸＭＬの中の代替の出力セグメントのどれを使用すべきかを判定するため、ミドルウェアトランスフォーマは、図３のステップ３００に従って、まず、「すべての装置」ノード２００を現在のノードとして確立する。
【０１０６】
次に、ミドルウェアトランスフォーマは、現在のノードの子に対応する代替の出力セグメントを識別する。この例では、「すべての装置」ノード２００の子に対応する代替の出力セグメントは、音声ノード２１０、デスクトップノード２１２および電話ノード２１８に関連する出力セグメントである。上述の条件独立出力に示されるように、「すべての装置」ノード２０００について図２で示される子ノードのすべてが対応する代替の出力セグメントを有するわけではない。したがって、アプリケーション開発者は、条件の階層に含まれるクラス、種類または特有の装置のいくつかのみをサポートしてもよい。
【０１０７】
ステップ３１０に示されるように、次にミドルウェアトランスフォーマは、現在のノードの識別された子に関連する条件のいずれかが当てはまるかどうかを判定する。装置がＴＣ ４４１ Ｖ１であると仮定される現在の例では、電話ノード２１８に関連する条件が当てはまる。結果として、ステップ３３０で、電話ノード２１８が新しい現在のノードとして確立される。
【０１０８】
電話ノード２１８を現在のノードに設定してステップ３１０に戻ると、ミドルウェアトランスフォーマは、電話ノード２１８の子、つまりＷＭＬノード２３０に対応する代替の出力セグメントを識別する。これは上述のＸＭＬで提供された代替の出力セグメントの中に図２に示される電話ノード２１８の他の子ノードに対応するものがないためである。
【０１０９】
ステップ３２０で、ミドルウェアトランスフォーマは、識別された子ノードに関連する条件のいずれかが当てはまるかどうかを判定する。この例では、当てはまる条件を備える代替の出力セグメントは、ＷＭＬノード２３０に関連する代替の出力セグメントのみである。結果として、ＷＭＬノード２３０がステップ３３０で新しい現在のノードとして確立される。
【０１１０】
ＷＭＬノード２３０を現在のノードとして設定してステップ３１０に戻ると、ミドルウェアトランスフォーマは、ＷＭＬノード２３０の子に対応する代替の出力セグメントを識別する。この例では、ＷＭＬノード２３−の子に対応する代替の出力セグメントは、ＴＣ ４４１ Ｖ２ノード２４４に関連する出力セグメントのみである。図２に示されるＷＭＬノード２３０の他の子ノード（すなわちノキア７１１０ノード２４０およびＴＣ ４４１ Ｖ１ノード２４２）についての代替の出力セグメントは上述のＸＭＬの中で提供されていない。
【０１１１】
ステップ３２０で、ミドルウェアトランスフォーマは、現在のノードの識別された子に関連する条件のいずれかが当てはまるかどうかを判定する。この例では、ＴＣ ４４１ Ｖ２ノード２４４に関連する条件は当てはまらない。なぜなら出力を送るべきクライアントは、ＴＣ ４４１ Ｖ１であって、ＴＣ ４４１ Ｖ２ではないと仮定されたからである。結果として、ＷＭＬノード２３０に関連する出力セグメントが選択される。そして条件独立出力は、次のように変形され得る。
【０１１２】
＜ｍｅｎｕ ｉｔｅｍ＞
戻り方
＜／ｍｅｎｕ ｉｔｅｍ＞
上述の例は、たとえ完全に合致するものがない場合でも、ある特有の装置について最もよく合致するものを識別する方法を示す。完全に合致するものがないということは、たとえば装置に特有の出力が必要および／または望まれていないなどのいくつかの理由よることがあり得る。また完全に合致するものがないということは、装置が新しいものであって、開発者がアプリケーションを設計する際に、その新しい装置について何も知らず、その能力についても何も知らなかったということによっても起こり得る。それでもこの新しい装置は、上の例では、たとえば、デスクトップコンピュータなどの別のクラスの装置用のデフォルトの出力または出力を受取る代わりに、電話に好適な出力を受取ることができる。
【０１１３】
上述の例は、要求の条件に最も具体的に合致する出力セグメントを選択するために、ミドルウェアトランスフォーマが使用できる技術の１つにすぎない。さまざまな代替の技術を使用することができる。たとえば、１つの代替の技術では、各タグに、対応するノードの、条件の階層内でのレベルに対応する番号を割り当ててもよい。＜ＷＭＬ＞には３を、＜ｐｈｏｎｅ＞には２を割当てることができる。したがって、代替の出力セグメントのセットの中の適切な出力セグメントを、（１）条件独立出力内で、当てはまる条件に対応するタグを識別することによって、および（２）それらのタグの中から、最も高い値を割当てられたタグを選択することによって、選ぶことができる。
【０１１４】
上述の説明の中では、適切な出力セグメントを選択するために使用する要求条件は、出力を供給すべきクライアントの装置の種類である。しかしながら、代替の出力セグメントから選択するために使用する要求条件は、実現例によって変わり得る。たとえば、一実現例では、セットの中の代替の出力セグメントは、各々ネットワークの異なる混雑レベルに関連してもよい。別の実現例では、あるセットの代替の出力セグメントは、各々エンドユーザの異なるクラスに関連してもよい。さらに別の実現例では、代替の出力セグメントは、要因の組合せに関連してもよい。たとえば、（１）ある特定のクラスのユーザが、（２）ある特定の種類のクライアント装置を使用し、（３）ある特定の伝送速度をサポートする接続を有する場合に、ある特定の出力セグメントを特定して使用してもよい。
【０１１５】
さらに、上述の説明では、出力がマークアップ言語、たとえばＸＭＬの形である例を挙げている。しかしながら、出力の本質は、実現例毎に異なり得る。ここに記載される技術は、（１）代替の出力セグメントを含み、（２）何らかのヒントを含み、これを使用して要求の条件に基き、代替の出力セグメントから選択することができる、どのような形の条件独立出力にも使用することができる。
【０１１６】
Ｇ．クライアント装置によってサポートされる言語に基づく出力の選択
上述の例における＜ＷＭＬ＞タグの使用は、代替の出力セグメントを選択するために使用する要求条件が、出力を送るべきクライアント装置がサポートするマークアップ言語またはプログラミング言語に関係する状況を示す。一実施例によると、「サポートされるプログラミング言語」要求条件に関連する出力セグメントは、部分的または全体的に、サポートされるプログラミング言語で書かれたコードを含み得る。
【０１１７】
たとえば、＜ＷＭＬ＞および＜／ＷＭＬ＞タグの間に位置付けられる出力セグメントは、全体的がＷＭＬコードからなってもよい。結果として、クライアント装置がＷＭＬ言語をサポートする場合、クライアント装置に送られる出力は、ＷＭＬ言語によるものである。この例ではＷＭＬ言語が使用されるが、この技術は、「Ｃ＋＋」、ＨＴＭＬ、ビジュアルベーシック（Ｖｉｓｕａｌ Ｂａｓｉｃ）、またはジャバ（Ｊａｖａ）（Ｒ）などを含むがこれらに限定されない、どのようなプログラミング言語にも使用することができる。
【０１１８】
Ｈ．ミドルウェアトランスフォーマを使用しての条件独立出力の変形
ミドルウェアホストによってホストされるミドルウェアトランスフォーマを使用して、クライアントに出力を提供する前に条件独立出力を変形することによって、多くの利点が実現する。たとえば、この技術によって、モバイルアプリケーションはどの装置もサポートすることができる。これは新しい装置が開発されると、ミドルウェアホストが、新しい装置について装置に特有のフォーマットおよびプロトコルの変形を提供するお陰である。さらに、モバイルアプリケーションが上述の代替の出力セグメントの技術を使用する場合、モバイルアプリケーション開発者は、そのような条件を検知できるアプリケーションを設計する必要なく、コンテンツが要求に関連する条件に基づいた出力をユーザに提供することができ、。
【０１１９】
一実施例では、モバイルアプリケーションが、出力が送られるクライアント装置の種類を知ることなく、クライアントが受取る出力のコンテンツをクライアントの装置の種類に合わせて調整することができる。たとえば、クライアント装置はページャであってもよい。上述のＸＳＬスタイルシートを使用してアプリケーションの出力を変形することによって、たとえば、ポータル・ツー・ゴーＸＭＬの出力を変形することによって、ミドルウェアトランスフォーマは、ページャのための装置に特有のフォーマットを生成することができる。
【０１２０】
さらに、新しいクライアントが割当てられたカテゴリに基づいて、クライアントが受取る出力のコンテンツを、新しい種類のクライアントに合わせて自動的に調整することができるが、アプリケーション開発者は、新しい種類のクライアントを知るすることすらない。たとえば、新しい種類のＷＡＰ電話が開発された場合、ミドルウェアホストは、新しいＷＡＰ電話を、条件の階層の中の適切な場所に分類する。結果として、新しいＷＡＰ電話は、サービスアプリケーションからの出力の中で何らかのセグメントが指定されている場合に、ＷＡＰ電話に関連する代替の出力セグメントを自動的に受取る。
【０１２１】
特定のセットの代替の出力セグメントがＷＡＰ電話に関連する出力セグメントを有しないが、携帯電話に関連する出力セグメントを有する場合、新しい電話は、携帯電話に関連する代替の出力セグメントを自動的に受取る。このようにして、新しい装置に届けられる出力のコンテンツは、アプリケーション開発者がアプリケーションを作成した際に全く知らなかった、新たに開発された装置についても、装置に特有であり、アプリケーション開発者によって決定される特有性のレベルを備える。
【０１２２】
Ｉ．共有ホストアプリケーションを使用しての出力の生成例
図４は、この発明の一実施例による、共有ホストアプリケーションを使用して出力を選択する例を示す。図４は、たとえばラップトップコンピュータまたは携帯電話などのクライアント装置４１０を示し、これは、要求に応答してウェブページを提供する、たとえば、ウェブブラウザなどのＨＴＴＰリスナ４２０に接続される。ＨＴＴＰリスナ４２０は、ホスティングサービス４３０に関連するサービスのリストを含むウェブページをクライアント装置４１０に提供してもよい。クライアント装置４１０が特定のサービスを選択すると、ＨＴＴＰリスナ４２０はその特定のサービスの要求を、ホスティングサービス４３０の一部であるサービスリンカ４３２に送る。サービスリンカ４３２は、ホスティングサービス４３０に関連する１つ以上のサーバで実現してもよい。要求を受取ると、サービスリンカ４３２は、要求の主題であるサービスまたはアプリケーションを識別し、クライアント装置４１０からの要求をサービスプロバイダ４４０に送る。
【０１２３】
サービスプロバイダ４４０は、ＨＴＴＰサーバ４４２を含み、サービスプロバイダ４４０と他のサーバ、たとえばサービスリンカ４３２またはインターネットの一部として共にリンクするサーバとの間の通信を処理する。サービスプロバイダ４４０は、アプリケーションサーバ４４６も含み、ＨＴＴＰサーバ４４２が受取った要求を適切なアプリケーションに案内する。
【０１２４】
サービスプロバイダ４４２０は、この例では、クライアント装置４１０からの要求の主題であるアプリケーション４５０も含む。たとえば、アプリケーション４５０は、食事場所案内モジュールであって、たとえば、クライアント装置４１０などのクライアントを介してエンドユーザが指定した都市のレストランの一覧を提供してもよい。アプリケーション４５０は、要求に依存して、出力４５２および出力４５４などの出力のいくつかのセットを生成することが可能であってもよい。たとえば、出力４５２は、エンドユーザがレストランの一覧を所望する都市の名前を与えるためのプロンプトであってもよい。
【０１２５】
サービスプロバイダ４４０はデータベース４７０も含む。たとえば、アプリケーション４５０が食事場所案内モジュールである場合、データベース４７０は、いくつかの都市のレストランについての情報を含んでもよい。エンドユーザが特定の都市を選択すると、アプリケーション４５０は、選ばれた都市のレストランの一覧を含む出力４５４を生成してもよい。
【０１２６】
サービスプロバイダ４４０は、サービスリンカ４３２を介してクライアント装置４１０から受取った要求に、一般的な出力４８０で応答する。たとえば、一般的な出力は、ポータル・ツー・ゴーＸＭＬを含む電子文書であってもよい。
【０１２７】
一般的な出力４８０はサービスプロバイダ４４０からホスティングサービス４３０に送られ、ここで、一般的な出力を、装置トランスフォーマ４３６によって処理する。装置トランスフォーマ４３６は、サーバであって、上述のようにスタイルシートを一般的なＸＭＬ出力に適用してカスタマイズした出力４９０にすることによって、ミドルウェアトランスフォーマとして機能してもよい。カスタマイズした出力は、クライアント装置４１０に送られ、エンドユーザに表示される。
【０１２８】
ＩＶ．他のアプリケーションおよびサービスへのアクセス
Ａ．モバイルモジュール
サービスプロバイダおよびアプリケーション開発者は、ホストアプリケーションまたはポータルアプリケーションを構築することができ、これらアプリケーションに、ミドルウェアトランスフォーマを管理する、たとえばホストなどの媒介物に送られるサービス要求がアクセスする。一実施例によると、「モバイルモジュール」とも称される、サービスまたはアプリケーションは、他のモバイルモジュールへのコールに繋がる出力を生成し得る。この出力は、たとえば、＜ｓｕｂｓｔｉｔｕｔｅ＞＜／ｓｕｂｓｔｉｔｕｔｅ＞などの特定のセットのタグを使用して、別のモバイルモジュールを参照する置換コマンドを示し、そのタグ内にモバイルモジュールの識別子を含んでもよい。
【０１２９】
たとえば、第１の当事者（当事者１）のモバイルモジュールが生成する出力は、以下のステートメントのセットを含むことによって、第２の当事者（当事者２）の別のモバイルモジュールを参照してもよい。
【０１３０】
＜ｓｕｂｓｔｉｔｕｔｅ＞
当事者２−モジュール−識別子
＜／ｓｕｂｓｔｉｔｕｔｅ＞
この出力を受取ると、ミドルウェアトランスフォーマは、「当事者２−モジュール−識別子」によって識別子された第２の当事者のモバイルモジュールを呼出し、そのモジュールの出力を第１の当事者のモバイルモジュールからの出力に埋込み、組合せた出力をクライアントに届ける。この機能によって、１つのモバイルモジュールの設計者は、媒介物（たとえばホスト）で利用可能である他のすべてのモバイルモジュールの機能性を利用することができる。この機能によって、以前のサービスを活性化したままトランザクションを行なうことが可能であり、誰がサービスを使用しているかを知る必要なく、サービスを使用することが可能となる。
【０１３１】
さらに、この機能は、クライアント上でブラウザが稼動するウェブページの間でオブジェクトをリンクすることとは異なる。たとえば、ブラウザがあるオブジェクトへのリンクを有するウェブページを受取ると、ブラウザはリンクによって指定されるアドレスに要求を送り、応答としてオブジェクトを受取り、そのオブジェクトをウェブページに組み込んで、そのウェブページをブラウザによって表示する。したがって、オブジェクトを要求して受取り、それをウェブページに組込むのはクライアント上で稼動するブラウザである。
【０１３２】
これに対して、上述の実施例では、媒介物が１つのモジュールから出力を（たとえばミドルウェアトランスフォーマで）受取り、別のモジュールに要求を行ない、その別のモジュールから出力を受取り、２つのモジュールの出力を組込んで、組合せた出力をクライアントに送る。したがって、第２のサービスの出力を要求し、受取り、それを第１のサービスの出力に組込むのは、クライアントではなく、媒介物である。
【０１３３】
別の実施例によると、「コールする」モバイルモジュールと称される、１つのモバイルモジュールの出力は、「コールされる」モバイルモジュールと称される、別のモバイルモジュールを呼出すだけではなく、コールするモバイルモジュールは、コールされるモバイルモジュールにパラメータを渡すこともできる。たとえば、コールするモバイルモジュールの出力は以下の形のコードを含んでもよい。
【０１３４】
＜ｌｉｎｋ＞
コールされる−モジュール−識別子 ｐａｒａｍ１ ｐａｒａｍ２ ｐａｒａｍ３
＜／ｌｉｎｋ＞
直上の例では、パラメータ「ｐａｒａｍ１」、「ｐａｒａｍ２」および「ｐａｒａｍ３」を、コールするモバイルモジュールから、「コールされる−モジュール−識別子」によって識別される、コールされるモバイルモジュールに渡す。
【０１３５】
別の実施例によると、コールされるモバイルモジュールからの出力を出力に自動的に埋込むのではなく、コールするモジュールの設計者は、選択されると、コールされるモバイルモジュールのプログラミングルーチンを呼出すリンクをユーザに単に提示したいかも知れない。リンクが所望されることを示すため、異なるセットのタグ、たとえば＜ａｃｔｉｏｎ＞＜／ａｃｔｉｏｎ＞を使用して、＜ａｃｔｉｏｎ＞および＜／ａｃｔｉｏｎ＞タグの間のステートメントに基づき、アクションコマンドを実行すべきであることを示すことができる。
【０１３６】
媒介物には、いつ第１の当事者の第１のモバイルモジュールが第２の当事者の第２のモバイルモジュールによってコールされているかがわかる。なぜなら、置換コマンドによって要求される呼出、または、たとえばリンクの選択などのアクションコマンドによって要求される呼出を行なうのは媒介物の責任であるためである。
【０１３７】
一実施例によると、媒介物は、どのモジュールがどの別のモジュールを呼出したかに関する情報を記憶する。モバイルモジュール設計者の間の業務関係の基礎として、この情報を使用することができる。たとえば、コールするモジュールの設計者は、コールするモジュールがコールされるモジュールを呼出す度に、コールされるモジュールの設計者にある金額を払うように交渉することがあり得る。媒介物を提供する当事者（たとえばホスティングサービス）は、モジュール間のコールを記録し、それらをさまざまなモジュール所有者に提供する。
【０１３８】
アプリケーションプロバイダ間またはモジュール所有者間の業務関係の追跡および管理は、ここに記載されるホスティングフレームワーク外では容易には実現できない。たとえば、ワールドワイドウェブ上で、第１の当事者は第２の当事者によって提供される第２のウェブページに関連するＵＲＬへのリンクを含む第１のウェブページを設計することができる。ユーザが第１のウェブページ上のリンクを選択することに応答して第２のウェブページが要求されたのか、または他の手段によって第２のページが要求されたのかを第２の当事者が判定することは、（不可能でないとしても）極めて難しい。結果として、第２の当事者が第１の当事者と従量制の契約を交渉することは難しい。
【０１３９】
さらに別の実施例によると、ホストは、エンドユーザがアクセスしたサービスについての状態情報を媒介物に維持する。たとえば、媒介物は、エンドユーザによる各セッションについての情報スタックを記憶してもよい。情報スタックは、セッション中にサービスまたはモバイルモジュールが他のモバイルモジュールを呼出したシーケンス、およびモバイルモジュールの識別を示す。
【０１４０】
一実施例によると、サービスに関連するモバイルモジュールは、コールバック機構を使用して、媒介物に記憶される状態情報を利用することができる。たとえば、コールするモジュールは、コールされるモジュールを呼出すリンクと共に、コールバック情報を含み得る。リンクの選択に応答して、ホストがコールされるモジュールを呼出すと、コールバック情報が媒介物の記録に記憶される。これは、たとえばセッションに関連するスタックにコールバック情報を位置付けるなどして行なう。コールされるモジュールは、コールされるモジュールが提供するコンテンツ上で、「完了」または「終了」選択、制御またはオブジェクトを提供してもよい。エンドユーザは、コールされるモジュールが提供するサービスを使い終わると、「完了」または「終了」選択肢を選択することができる。コールされるモジュールは、コールするモジュールの識別についての情報や知識を持つ必要はない。その代わり、コールされるモジュールは、「以前に」アクセスされたサービス（すなわち以前に使用されたモバイルモジュール）を識別しさえすればよく、媒介物は、スタック情報に基づいて、以前にアクセスされたサービスを識別する。
【０１４１】
「完了」選択肢の選択に応答して、ホストにメッセージが送られ、これが情報スタックの上部で指定されるアクションをホストに行なわせる。上述の例では、情報スタックの上部で指定されるアクションは、コールされるモジュールがコールされたときにそこに位置付けられたコールバック情報である。通常、コールバック情報によって、コールするモジュールが再び呼出され、コールされるモジュールからのコンテンツまたは出力がエンドユーザに届けられる。エンドユーザの側から見ると、エンドユーザがコールされるモジュールを使い終わったときに、コールするモジュールに戻るように見える。
【０１４２】
Ｂ．媒介物でのデータの記憶
一実施例によると、データを媒介物に記憶して、媒介物を介してアクセスされるサービスが使用できるようにしてもよい。サービスについてのアプリケーションまたはモバイルモジュールが実行されると、媒介物は、変数を出力に含める代わりに、それら変数の、記憶されたデータに対するマッピングに基づいて、記憶されたデータをアプリケーション出力に含める。媒介物は、ホストであってもよく、データまたは値もしくは情報アイテム、および情報アイテムと変数または識別子との間のマッピングを記憶する。サービスは、既存の変数についてデータを記憶または更新してもよく、または新しい変数についてデータを記憶して、マッピングに追加してもよい。
【０１４３】
モバイルモジュールによって生成されるコンテンツまたは出力は、１つ以上の識別子を含んでもよい。識別子の１つを参照する出力に遭遇することに応答して、媒介物は、出力を要求するクライアントに出力を提供する前に、対応する情報アイテムを与える。
【０１４４】
たとえば、特定のセッションについて、ホストは識別子「名前」にマップされるデータアイテム「マイク」を記憶してもよい。モジュールは次のような出力を生成し得る。
【０１４５】
＜ＳｉｍｐｌｅＴｅｘｔ＞
こんにちは ％名前
＜／ＳｉｍｐｌｅＴｅｘｔ＞
ホストがセッションの中でそのような出力に遭遇すると、ホストは「％名前」参照を対応するデータアイテム「マイク」で置換し、出力は次のようになる。
【０１４６】
＜ＳｉｍｐｌｅＴｅｘｔ＞
こんにちは マイク
＜／ＳｉｍｐｌｅＴｅｘｔ＞
一実施例によると、サービスプロバイダ、およびモバイルモジュールの開発者は、データおよび識別子をホストに登録して、それらをホストに維持してもらうことができる。それらモジュールの設計者は、そうすることによって、恒久的に情報を維持する負担から解放されつつも、単に適切な識別子をその出力に含めることによって、恒久的に情報が維持されるという恩恵を受けることができる。
【０１４７】
別の実施例では、コールするモバイルモジュールは、データアイテムまたは参照を設定して、エンドユーザがコールされるモジュールを使い終わったときにコールするモジュールに戻れるようにすることができる。たとえば、ある特定のセッションについて、ホストは、コールするモジュール識別子にデータアイテム「ｈｒｅｆ」を関連付けてもよい。以下のように、モジュールはこのデータアイテムを第１のパラメータとして使用して、出力を生成し、コールされるモバイルモジュールへのリンクを作成することができる。
【０１４８】
＜ａｃｔｉｏｎ＞
コールされる−モジュール−識別子 ％ｈｒｅｆ
＜／ａｃｔｉｏｎ＞
ホストが特定のセッションの中でこの出力に遭遇すると、ホストは「％ｈｒｅｆ」参照をコールするモジュール識別子と置換し、以下の出力につながる。
【０１４９】
＜ａｃｔｉｏｎ＞
コールされる−モジュール−識別子 コールする−モジュール−識別子
＜／ａｃｔｉｏｎ＞
結果として、クライアントがコールされるモジュールへのリンクを使用すると、コールするモジュール識別子はパラメータとしてコールするモジュールに渡される。コールされるモジュールは、コールするモジュール識別子を使用して、クライアントがコールされるモジュールを完了した場合に、クライアントをコールするモジュールに戻らせることができる。
【０１５０】
別の実施例では、別のサービスまたはコールされるモバイルモジュールへのリンクを実行する前に、以前のサービスまたはコールするモバイルモジュールへの参照を含むデータアイテムを媒介物に記憶することができる。他のサービスまたはコールされるモバイルモジュールは、ウェブページ上の「完了」または「終了」コントロールまたはボタンなどのオブジェクトであって、「％以前」などのラベルまたは変数を含むオブジェクトを提供してもよい。媒介物が、他のサービスからの出力の中で「％以前」変数に遭遇すると、媒介物は、以前のサービスまたはコールするモバイルモジュールへの参照で置換するため、エンドユーザは、ウェブページ上のオブジェクトを選択することによって、コールされるモジュールから以前のサービスに戻ることができる。
【０１５１】
上述の例では変数または識別子、たとえば「％名前」を使用してエンドユーザの名前を示し、「％ｈｒｅｆ」を使用してコールするモジュールの識別子をコールされるモジュールに渡すが、他の変数を使用して、アプリケーションが実行されるときに初めて設定されるか、または知ることができるであろう他のデータを参照してもよい。たとえば、ラベルを使用して、アプリケーションが稼動する、またはクライアントによって特有の要求が行なわれるときの日付または時間を得ることができる。
【０１５２】
Ｖ．ハードウェア概要
図５は、この発明の実施例を実現することのできるコンピュータシステム５００を示すブロック図である。コンピュータシステム５００はバス５０２または他の通信機構を含んで情報を通信し、バス５０２に結合されたプロセッサ５０４を含んで情報を処理する。コンピュータシステム５００は、バス５０２に結合された、ランダムアクセスメモリ（ＲＡＭ）または他の動的な記憶装置などのメインメモリ５０６も含み、情報およびプロセッサ５０４によって実行されるべき命令を記憶する。メインメモリ５０６は、プロセッサ５０４によって実行されるべき命令が実行される間、一時的な変数または他の中間情報を記憶するために使用することができる。コンピュータシステム５００は、さらにバス５０２に結合される読出専用メモリ（ＲＯＭ）５０８または他の静的な記憶装置を含み、プロセッサ５０４のために静的な情報および命令を記憶する。磁気ディスクまたは光ディスクなどの記憶装置５１０が設けられ、バス５０２に結合されて、情報および命令を記憶する。
【０１５３】
コンピュータシステム５００を、バス５０２を介して、陰極線管（ＣＲＴ）などのディスプレイ５１２に結合して、情報をコンピュータユーザに表示してもよい。英数字キーおよび他のキーを含む入力装置５１４をバス５０２に結合し、情報およびコマンドの選択をプロセッサ５０４に通信する。別の種類のユーザ入力装置は、マウス、トラックボールまたはカーソル方向キーなどのカーソル制御５１６であり、方向情報およびコマンド選択をプロセッサ５０４に通信し、ディスプレイ５１２上でカーソルの動きを制御する。この入力装置は通常、第１の軸（たとえばｘ）および第２の軸（たとえばｙ）の２つの軸において２つ自由度を有するため、入力装置は平面で位置を指定することができる。
【０１５４】
この発明は、ここに記載される技術を実現するためにコンピュータシステム５００を使用することに関する。この発明の一実施例によると、プロセッサ５０４が、メインメモリ５０６に含まれる１つ以上の命令の１つ以上のシーケンスを実行することに応答して、コンピュータシステム５００がこれら技術を実行する。そのような命令は、別のコンピュータ読取可能な媒体、たとえば記憶装置５１０などからメインメモリ５０６に読込むことができる。メインメモリ５０６に含まれる命令のシーケンスの実行が、プロセッサ５０４に、ここに記載されるプロセスステップを行なわせる。別の実施例では、配線された回路を、ソフトウェア命令の代わりに、またはそれと組合せて使用して、この発明を実現することができる。したがって、この発明の実施例は配線された回路およびソフトウェアの特定の組合せに限定されない。
【０１５５】
ここで使用する「コンピュータ読取可能な媒体」という用語は、命令をプロセッサ５０４に提供して実行させることに参加する、どのような媒体も指す。そのような媒体は、不揮発性媒体、揮発性媒体および伝送媒体などを含むがこれに限定されない、多くの形をとり得る。不揮発性媒体は、たとえば記憶装置５１０などの光ディスクまたは磁気ディスクを含む。揮発性媒体は、メインメモリ５０６などの動的メモリを含む。伝送媒体は、同軸ケーブル、銅線および光ファイバを含み、バス５０２を含む配線を含む。伝送媒体は、無線通信および赤外線通信の間に生成されるもののような、音波または光波の形もとり得る。
【０１５６】
コンピュータ読取可能な媒体の一般的な形は、たとえば、フロッピー（Ｒ）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、その他のいかなる磁気媒体、ＣＤ−ＲＯＭ、その他のいかなる光媒体、パンチカード、紙テープ、穴のパターンを備えるその他の物理的な媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、その他いかなるメモリチップまたはカートリッジ、後に述べる搬送波、またはコンピュータがそこから読取ることができるその他いかなる媒体を含む。
【０１５７】
さまざまな形のコンピュータ読取可能な媒体が、１つ以上の命令の１つ以上のシーケンスをプロセッサ５０４に運んで実行させることに関わり得る。たとえば、まず命令をリモートコンピュータの磁気ディスクで運ぶことができる。リモートコンピュータは、動的メモリに命令をロードし、モデムを使用して、その命令を電話線上で送ることができる。コンピュータシステム５００のローカルモデムは、電話線上でそのデータを受取り、赤外線送信機を使用して、そのデータを赤外線信号に変換することができる。赤外線検出器は、赤外線信号で運ばれるデータを受取り、適切な回路は、そのデータをバス５０２に位置付けることができる。バス５０２はそのデータをメインメモリ５０６に運び、そこからプロセッサ５０４が命令を実行および検索する。メインメモリが受取る命令を、プロセッサ５０４による実行の前または後に、任意で記憶装置５１０に記憶することができる。
【０１５８】
コンピュータシステム５００は、バス５０２に結合される通信インターフェイス５１８も含む。通信インターフェイス５１８は、ネットワークリンク５２０に結合する２方向のデータ通信を提供し、ネットワークリンク５２０は、ローカルネットワーク５２２に接続する。たとえば、通信インターフェイス５１８は統合サービスデジタルネットワーク（ＩＳＤＮ）カードまたはモデムであって、対応する種類の電話線にデータ通信接続を提供してもよい。別の例として、通信インターフェイス５１８は、ローカルエリアネットワーク（ＬＡＮ）カードであって、互換性ＬＡＮにデータ通信接続を提供してもよい。無線リンクも実現可能である。そのような実現例のいずれにおいても、通信インターフェイス５１８は、さまざまな種類の情報を表わすデジタルデータストリームを運ぶ、電気信号、電磁気信号または光信号を送受信する。
【０１５９】
ネットワークリンク５２０は、通常１つ以上のネットワーク経由で、他のデータ装置にデータ通信を提供する。たとえば、ネットワークリンク５２０は、ローカルネットワーク５２２を経由して、ホストコンピュータ５２４またはインターネットサービスプロバイダ（ＩＳＰ）５２６によって運営されるデータ装置への接続を提供してもよい。ＩＳＰ５２６は、現在一般的に「インターネット」５２８と呼ばれる、世界規模のパケットデータ通信ネットワークを経由して、データ通信サービスを提供する。ローカルネットワーク５２２およびインターネット５２８は、共にデジタルデータストリームを運ぶ、電気信号、電磁気信号または光信号を使用する。コンピュータシステム５００とデジタルデータをやり取りする、さまざまなネットワーク経由の信号およびネットワークリンク５２０上の信号ならびに通信インターフェイス５１８経由の信号は、情報を伝送する搬送波の形の例である。
【０１６０】
コンピュータシステム５００は、プログラムコードを含め、ネットワーク、ネットワークリンク５２０および通信インターフェイス５１８を経由して、メッセージを送り、データを受け取ることができる。インターネットの例では、サーバ５３０は、アプリケーションプログラムについて要求されたコードを、インターネット５２８、ＩＳＰ５２６、ローカルネットワーク５２２および通信インターフェイス５１８を経由して伝送し得る。
【０１６１】
受取られるコードは、受取られるときにプロセッサ５０４によって実行してもよいし、および／または記憶装置５１０または他の不揮発性記憶装置に記憶して後に実行してもよい。このようにして、コンピュータシステム５００は、搬送波の形でアプリケーションコードを入手することができる。
【０１６２】
上述の明細書では、具体的な実施例を参照して、この発明を記載してきた。しかしながら、この発明の幅広い精神および範囲から離れることなく、さまざまな修正および変形を行ない得ることは明白である。したがって、明細書および図面は、限定的なものではなく、例示的なものとしてみなされるべきである。
【図面の簡単な説明】
【図１Ａ】この発明の一実施例による、媒介物を通じてアクセスされるアプリケーションを介してサービスを提供するためのシステムの高レベルの概要を示すブロック図である。
【図１Ｂ】この発明の一実施例によるホストサービスの概要を示すブロック図である。
【図２】この発明の一実施例による条件の階層を示すブロック図である。
【図３】この発明の一実施例による、代替の出力セグメントを選択するためのアプローチを示すフロー図である。
【図４】この発明の一実施例による、共有ホストアプリケーションを使用して出力を生成する例を示すブロック図である。
【図５】実施例を実現することのできるコンピュータシステムを示すブロック図である。

Claims (33)

1. 要求に応答して、サービスによって提供されるコンテンツをカスタマイズするための方法であって、前記方法は、
   前記サービスからデータを受取る、コンピュータによって実現されるステップを含み、前記データは、複数の出力セグメントを含み、
   前記複数の出力セグメントの各出力セグメントは、前記複数の出力セグメントの中の他の出力セグメントに対して、前記要求の少なくとも一部分に対する相互に排他的な応答であり、前記方法は、さらに、
   １つ以上のパラメータに基づいて、前記複数の出力セグメントからある特定の出力セグメントを識別して、前記要求に対する返答に含める、コンピュータによって実現されるステップと、
   前記要求に対する前記返答を生成する、コンピュータによって実現されるステップとを含み、前記返答は、前記特定の出力セグメントを含み、前記方法は、さらに、
   前記要求に応答して前記返答を送る、コンピュータによって実現されるステップを含む、方法。
2. 前記複数の出力セグメントの各出力セグメントは、１つ以上の条件に関連し、前記特定の出力セグメントを識別する前記ステップは、
   １つ以上のパラメータを前記１つ以上の条件と比較する、コンピュータによって実現されるステップと、
   前記比較するステップの結果に基づいて、前記特定の出力セグメントを選択する、コンピュータによって実現されるステップとを含む、請求項１に記載の方法。
3. 前記複数の出力セグメントの各出力セグメントには、前記１つ以上の条件を指定するデータが付随し、前記１つ以上のパラメータを前記１つ以上の条件と比較する前記ステップは、
   前記１つ以上のパラメータを前記１つ以上の条件を指定する前記データと比較する、コンピュータによって実現されるステップを含む、請求項２に記載の方法。
4. 前記１つ以上の条件の各々は、満たされるかまたは満たされないかのどちらかであり、前記１つ以上のパラメータを前記１つ以上の条件と比較する前記ステップは、
   前記１つ以上の条件が満たされる１つ以上の出力セグメントを識別する、コンピュータによって実現されるステップと、
   前記１つ以上の出力セグメントから前記特定の出力セグメントを選択する、コンピュータによって実現されるステップとをさらに含む、請求項３に記載の方法。
5. 前記複数の出力セグメントの各出力セグメントは、条件の階層の中のある条件に関連し、前記特定の出力セグメントを識別する前記ステップは、
   前記１つ以上のパラメータを前記条件の階層の中の条件と比較することに基づいて、前記特定の出力セグメントを判定する、コンピュータによって実現されるステップを含む、請求項１に記載の方法。
6. 各条件は、前記条件の階層の中で、特定の位置を有し、各条件は、満たされるかまたは満たされないかのどちらかであり、前記特定の出力セグメントを識別する前記ステップは、
   前記条件の階層の中で、満たされ、かつ前記複数の出力セグメントの１つに対応する複数の条件を識別する、コンピュータによって実現されるステップと、
   前記複数の条件から、少なくとも前記複数の条件の中の前記複数の条件の他のどれかと前記条件の階層の中で同じぐらい下にある特定の条件を選択する、コンピュータによって実現されるステップと、
   前記特定の出力セグメントに関連する前記特定の条件に基づいて、前記特定の出力セグメントを識別する、コンピュータによって実現されるステップとをさらに含む、請求項５に記載の方法。
7. 前記条件の階層は、親子関係に基づいて組織され、各子条件は、各親条件に関連するカテゴリのサブカテゴリに対応する、請求項５に記載の方法。
8. 前記１つ以上のパラメータは、前記返答を送るべき装置に関連する装置の種類に対応する、請求項１に記載の方法。
9. 前記装置の種類は、１つのモデルに対応する、請求項８に記載の方法。
10. 前記装置の種類は、少なくとも２つのモデルを含むカテゴリに対応する、請求項８に記載の方法。
11. 前記１つ以上のパラメータは、前記返答を送るべき装置の能力を示す、請求項１に記載の方法。
12. 前記１つ以上のパラメータは、現在の環境的な条件に関連する特性を示す、請求項１に記載の方法。
13. 前記特性は、前記返答がその上で運ばれるべきネットワーク上のネットワークの混雑の測定値である、請求項１２に記載の方法。
14. 前記特性は、現在の時間である、請求項１２に記載の方法。
15. 前記返答を生成する前記ステップは、
    前記返答を送るべき装置に関連する装置の種類に基づいて、前記特定の出力セグメントをフォーマットする、コンピュータによって実現されるステップを含む、請求項１に記載の方法。
16. 前記特定の出力セグメントをフォーマットする前記ステップは、
    前記装置の種類に対応するスタイルシートを適用する、コンピュータによって実現されるステップを含む、請求項１５に記載の方法。
17. コンピュータ読取可能な媒体であって、
    複数の代替の出力セグメント保持し、前記複数の代替の出力セグメントの各々は、データのセットの変形を示し、前記データのセットの各変形は、サービスに送られる要求を満たし、前記コンピュータ読取可能な媒体は、さらに、
    複数の条件識別子を保持し、前記複数の条件識別子の１つ以上は、前記複数の代替の出力セグメントの各々に関連し、
    前記複数の代替の出力セグメントの各々に関連する前記複数の条件識別子の前記１つ以上は、前記複数の代替の出力セグメントの前記各々を前記要求に対する応答に含めるべきかを示す、コンピュータ読取可能な媒体。
18. 要求に応答して、サービスよって提供されるコンテンツをカスタマイズするための命令の１つ以上のシーケンスを保持するコンピュータ読取可能な媒体であって、１つ以上のプロセッサによって命令の前記１つ以上のシーケンスが実行されると、前記１つ以上のプロセッサは、
    前記サービスからデータを受取るステップを行ない、前記データは、複数の出力セグメントを含み、
    前記複数の出力セグメントの各出力セグメントは、前記複数の出力セグメントの中の他の出力セグメントに対して、前記要求の少なくとも一部分に対する相互に排他的な応答であり、さらに、前記１つ以上のプロセッサは、
    １つ以上のパラメータに基づいて、前記複数の出力セグメントから特定の出力セグメントを識別して、前記要求に対する返答に含めるステップと、
    前記要求に対する前記返答を生成するステップとを行ない、前記返答は、前記特定の出力セグメントを含み、さらに、前記１つ以上のプロセッサは、
    前記要求に応答して、前記返答を送るステップを行なう、コンピュータ読取可能な媒体。
19. 前記複数の出力セグメントの各出力セグメントは、１つ以上の条件に関連し、前記特定の出力セグメントを識別するための前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記１つ以上のパラメータを前記１つ以上の条件と比較するステップと、
    前記比較するステップの結果に基づいて、前記特定の出力セグメントを選択するステップとを実行させる命令をさらに含む、請求項１８に記載のコンピュータ読取可能な媒体。
20. 前記複数の出力セグメントの各出力セグメントには、前記１つ以上の条件を指定するデータが付随し、前記１つ以上のパラメータを前記１つ以上の条件と比較するための前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記１つ以上のパラメータを、前記１つ以上の条件を指定する前記データと比較するステップを実行させる命令をさらに含む、請求項１９に記載のコンピュータ読取可能な媒体。
21. 前記１つ以上の条件の各々は満足されるかまたは満足されないかのどちらかであり、前記１つ以上のパラメータを前記１つ以上の条件と比較するための命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記１つ以上の条件が満足される１つ以上の出力セグメントを識別するステップと、
    前記１つ以上の出力セグメントから前記特定の出力セグメントを選択するステップとを実行させる命令をさらに含む、請求項２０に記載のコンピュータ読取可能な媒体。
22. 前記複数の出力セグメントの各出力セグメントは、条件の階層の中である条件に関連し、前記特定の出力セグメントを識別するための前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記１つ以上のパラメータを前記条件の階層の中の条件と比較することに基づいて、前記特定の出力セグメントを判定するステップを実行させる命令をさらに含む、請求項１８に記載のコンピュータ読取可能な媒体。
23. 各条件は、前記条件の階層の中である特定の位置を有し、各条件は、満たされるかまたは満たされないかのどちらかであり、前記特定の出力セグメントを識別するための前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    満たされ、かつ前記複数の出力セグメントの１つに対応する複数の条件を、前記条件の階層の中で識別するステップと、
    少なくとも前記複数の条件の中の前記複数の条件の他のどれかと前記条件の階層の中で同じぐらい下にある特定の条件を、前記複数の条件から選択するステップと、
    前記特定の出力セグメントに関連する前記特定の条件に基づいて、前記特定の出力セグメントを識別するステップとをさらに含む、請求項２２に記載のコンピュータ読取可能な媒体。
24. 前記条件の階層は、親子関係に基づいて組織され、各子条件は、各親条件に関連するカテゴリのサブカテゴリに対応する、請求項２２に記載のコンピュータ読取可能な媒体。
25. 前記１つ以上のパラメータは、前記返答を送るべき装置に関連する装置の種類に対応する、請求項１８に記載のコンピュータ読取可能な媒体。
26. 前記装置の種類は、１つのモデルに対応する、請求項２５に記載のコンピュータ読取可能な媒体。
27. 前記装置の種類は、少なくとも２つのモデルを含むカテゴリに対応する、請求項２５に記載のコンピュータ読取可能な媒体。
28. 前記１つ以上のパラメータは、前記返答を送るべき装置の能力を示す、請求項１８に記載のコンピュータ読取可能な媒体。
29. 前記１つ以上のパラメータは、現在の環境的な条件に関連するある特性を示す、請求項１８に記載のコンピュータ読取可能な媒体。
30. 前記特性は、前記返答がその上で運ばれるべきネットワーク上のネットワークの混雑の尺度である、請求項２９に記載のコンピュータ読取可能な媒体。
31. 前記特性は、現在の時間である、請求項２９に記載のコンピュータ読取可能な媒体。
32. 前記返答を生成するための前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記返答を送るべき装置に関連する装置の種類に基づいて、前記特定の出力セグメントをフォーマットするステップを実行させる命令をさらに含む、請求項１８に記載のコンピュータ読取可能な媒体。
33. 前記特定の出力セグメントをフォーマットするための前記命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
    前記装置の種類に対応するスタイルシートを適用するステップを実行させる命令をさらに含む、請求項３２に記載のコンピュータ読取可能な媒体。

Images