(57)【要約】特定のプロトコルおよび装置に対するプロトコルまたは装置とは関係なく作成されたアプリケーションを適合する処理およびシステムである。アプリケーション開発者は、システムによって提供されるアプリケーションプログラミングインターフェイス（ＡＰＩ）を用いて、オブジェクト指向方法により、コンテンツを作成してもよい。できあがったコンテンツはプロトコル独立装置独立型であるかもしれない。システムによって処理する場合、システムは最初にプロトコル独立装置独立型コンテンツを取り込み、システムによって提供されるエンジンを用いて、該コンテンツをプロトコル依存装置独立型にする。システムは次に、プロトコル依存装置独立型コンテンツを取り込み、装置に対するリソース記述フレームワーク（ＲＤＦ）に基づいて、該コンテンツをプロトコル依存装置依存型にしてもよい。
2004506977.tif 000002
【特許請求の範囲】
【請求項１】
プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成する方法であって、
プロトコル独立装置独立型コンテンツオブジェクトを受信し、
装置に対するリソース記述フレームワーク（ＲＤＦ）に基づいて、前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更し、
前記装置に対するＲＤＦに基づいて、前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する、
ことを含む方法。
【請求項２】
前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツにするステップは、前記プロトコル独立装置独立型コンテンツを、プロトコルを保存するコンテナにマッピングすることを更に含む、請求項１に記載の方法。
【請求項３】
前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更するステップは、前記プロトコル依存装置独立型コンテンツを、装置性能を保存するハンドラに登録することを更に含む、請求項２に記載の方法。
【請求項４】
コンテンツ開発者から、拡張したアクションを受信することを更に含む、請求項１に記載の方法。
【請求項５】
前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更するステップは、前記装置に対するＲＤＦに基づいて、装置オブジェクトを実例化することを更に含む、請求項１に記載の方法。
【請求項６】
プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成するシステムであって、
クラスファイルと、
前記クラスファイルを利用して、プロトコル独立装置独立型コンテンツオブジェクトを作成するためのアプリケーションプログラミングインターフェイスと、
前記プロトコル独立装置独立型コンテンツオブジェクトをプロトコル依存装置独立型コンテンツオブジェクトに変更するためのエンジンと、
前記プロトコル依存装置独立型コンテンツオブジェクトをプロトコル依存装置依存型コンテンツオブジェクトに変更するためのエンジンと、
を有するシステム。
【請求項７】
前記プロトコル独立装置独立型コンテンツオブジェクトをプロトコル依存型コンテナにマッピングする、請求項６に記載のシステム。
【請求項８】
前記プロトコル依存装置独立型コンテンツをハンドラに登録する、請求項６に記載のシステム。
【請求項９】
前記プロトコル独立装置独立型コンテンツオブジェクトをオブジェクト指向プログラミングを用いて作成する、請求項６に記載のシステム。
【請求項１０】
前記プロトコル独立装置独立型コンテンツを、第１のアクションを拡張する実行方法で作成する、請求項６に記載のシステム。
【請求項１１】
前記エンジンは、装置オブジェクトを実例化し、特定の装置に対してコンテンツを適合させる、請求項６に記載のシステム。
【請求項１２】
前記プロトコル依存装置独立型コンテンツを複数のハンドラに登録する、請求項６に記載のシステム。
【請求項１３】
プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成する方法であって、
プロトコル独立装置独立型コンテンツオブジェクトを作成し、
前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更し、
前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する方法。
【請求項１４】
前記プロトコル独立装置独立型コンテンツを作成するステップは、オブジェクト指向プログラミングを利用することを含む、請求項１３に記載の方法。
【請求項１５】
前記プロトコル独立装置独立型コンテンツを作成するステップは、アプリケーションプログラミングインターフェイスを利用することを更に含む、請求項１３に記載の方法。
【請求項１６】
前記アプリケーションプログラミングインターフェイスを使うステップは、アクションを実行することを更に含む、請求項１５に記載の方法。
【請求項１７】
多数のプロトコルを走らせる多数の装置において使用してもよいアプリケーションを一旦構築する方法であって、
プロトコル独立装置独立型コンテンツを作成し、
前記コンテンツを多数のプロトコルに適合させ、
前記アプリケーションを多数の装置に適合させる、
ことを含む方法。
【請求項１８】
前記コンテンツを複数のプロトコルに適合させるステップは、
前記多数のプロトコルの１個を選択し、
前記コンテンツを、選択したプロトコルに適合させる
ことを更に有する、請求項１７に記載の方法。
【請求項１９】
前記アプリケーションを多数の装置に適合させるステップは、
前記多数の装置の１個を選択し、
前記アプリケーションを、選択した装置に適合させる、
ことを更に含む、請求項１７に記載の方法。
【請求項２０】
多数のプロトコルを走らせる装置において使用してもよいアプリケーションを一旦構築する方法であって、
プロトコル独立装置独立型コンテンツを作成し、
前記コンテンツを多数のプロトコルに適合させ、
前記コンテンツを多数の装置に適合させる、
ことを含む方法。
【請求項２１】
プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成するシステムであって、
プロトコル独立装置独立型コンテンツオブジェクトを作成する手段と、
前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更する手段と、
前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する手段と、
を有するシステム。
【請求項２２】
前記プロトコル独立装置独立型コンテンツを作成する手段は、オブジェクト指向プログラミングを使用する手段を更に含む、請求項２１に記載のシステム。
【請求項２３】
前記プロトコル独立装置独立型コンテンツを作成する手段は、アプリケーションプログラミングインターフェイスを使用する手段を更に含む、請求項２１に記載のシステム。
【請求項２４】
前記アプリケーションプログラミングインターフェイスを使用する手段は、アクションを実行する手段を更に含む、請求項２３に記載のシステム。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、情報技術の分野に関する。本発明の特定の実施形態は、特定の任意の装置またはプロトコルに関係なく、多数の装置およびプロトコル標準のためのコンテンツやアプリケーションを開発するシステムおよび方法に関する。
【０００２】
（背景技術）
現在、情報を転送、伝達するために装置が使用するプロトコルや標準は様々である。セットトップボックス、携帯電話、デスクトップＰＣ、個人情報形態端末、スマートフォン、ページャ、電子ブック、ラップトップＰＣ、その他の装置の各々は異なる性能を有し、異なる方法を採用している。これらによって情報の送信、受信、表示、解釈を行う。更に、これらの装置を用いてプレゼンテーションをする場合に使用するマークアップ言語もまた様々であって、中には所有物さえある。このような多様さのために、携帯性が欠如することがある。また、ある装置やプロトコルに対して作成されたコンテンツが別の装置またはプロトコルでは使用できないこともある。
【０００３】
装置間およびプロトコル間で一貫性を持たせようという多様な試みがなされてきた。業界全体の標準を採用する手始めとして斯かる試みを行った場合もある。例えば、無線業界では、現在、無線通信アプリケーションプロトコル（ＷＡＰ）がある。これは、無線装置において動作するアプリケーションを開発するための一組の仕様である。ＷＡＰは多様なインターネット標準に基づいている。例えば、拡張可能マーク付け言語（ＸＭＬ）やインターネットプロトコル（ＩＰ）である。しかし、ＷＡＰは、ナローバンドネットワークや表示性能に制限がある装置にとって最適であり、ＷＡＰを介して送信された情報は通常、短くされ、モバイルリンクを介する伝達を容易にし、小型スクリーンで見られるようにしている。これは主に携帯電話や無線通信業界の参加者が設計したので、ＷＡＰは主にこれらの業界で使用されている。これは事実上の標準であって、必須の標準ではなく、ＷＡＰ以外のプロトコルも携帯電話業界において使用されている。したがって、携帯電話業界や、あえて言及するまでもなく無線業界全体においても、サーバと装置との間、または複数の装置同士の間で情報を転送、伝達する標準的なプロトコルはない。
【０００４】
驚くことではないが、インターネット業界にも多数のプロトコルや標準が溢れている。例えば、テキストや図表の画像が一杯の何百万ものページが世界中のインターネットユーザによって毎日ＷＷＷを介して見られている。しかし、現在、これらの文書を作成するための標準は１つも存在しない。ウェブページを作成する最も人気がある方法は、ユビキタスＨＴＭＬつまりハイパーテキストマークアップ言語を使うことである。ＨＴＭＬは、通常のテキストをウェブページを作るインストラクションに変換できる１組のコード（「タグ」と呼ばれる）である。これは比較的簡単に使用でき、多くの人々が自分のウェブページを作成できる手段を提供してきた。しかし、ＨＴＭＬには欠点もある。その簡単さが限界の１つでもあるのだ。ＨＴＭＬを使って印刷できないキャラクタが幾つかある。ＨＴＭＬコードの数が限られているので、ＨＴＭＬを使って設計されたウェブページが、どのコンピュータまたはウェブブラウザを用いた場合にも全く同じように一貫して表示されるという保障はない。これはウェブページの設計者にとっては明かに問題である。この問題を軽減するために、改良されたコード特徴を有するより新しいＨＴＭＬが常に開発されている。しかし、これはＨＴＭＬのバーションを多様化することになり、ＨＴＭＬの古いバージョンを陳腐化する。その結果、ウェブページに一貫性がない状況が続いている。
【０００５】
ウェブページの一貫性の問題やＨＴＭＬに関連する他の問題に対処するために、ポータブルドキュメント形式（ＰＤＦ）等の文書形式が作られた。ＰＤＦを使って設計されたウェブページは、表示に必要な全ての情報を非制限に含んでいる。これにはフォントタイプ、レイアウト、図表のスペーシング、色も含まれる。したがって、ＰＤＦで作られたウェブページは、使用するシステムに関係なく、見る人全てに同一に、少なくとも非常に類似して、見える。しかし、ＰＤＦもウェブページを見るための完璧な解決方法ではない。ＰＤＦファイルは、それが表すデータの構成に関して何も確認できない。その結果、データ構成を確認する性能を有するＨＴＭＬを使ってＰＤＦページの配信を管理することが多々ある。さらに、ＰＤＦは事実上の標準になってはいるが、ＡＤＯＢＥ　ＳＹＳＴＥＭＳ，ＩＮＣ．の所有物であり、ＰＤＦページを閲覧するためにユーザは、ＡＤＯＢＥ（登録商標）ＡＣＲＯＢＡＴ（登録商標）ソフトウェアが必要である。
【０００６】
ＨＴＭＬやＰＤＦの他にも、インターネット上のコンテンツを表示するために多くのプロトコルがある。無線装置の場合やＰＤＦと同様、多くの形式は所有物である。問題に折り合いをつけて、現在インターネット用に存在する多様なプロトコルの１種類を用いるか、コンテンツの転送や表示のための所有権が設定されたシステムを用いるかして、インターネット「アプライアンス」と呼ばれる、インターネットに直接接続する新規の装置が常に開発され、市場に投入されている。いずれの場合も、インターネットアプライアンスの開発者は、新規の装置のために選択、開発したプロトコルが存続し、広く市場で受け入れられることを願って、プロトコルに関して難しい決断を迫られる。しかし、これは常のことではなく、インターネットの歴史は、単に情報の転送や表示の方法の選択が悪いために最終的に市場で失敗する製品の積み重ねである。
【０００７】
現在使用されているプロトコルや装置が多様であることは、コンテンツやアプリケーションを作成する人々にとって、これらが多数の異なる装置にサポートされるために克服しなければならない大きな問題である。多数の装置やプロトコルがあるためにアプリケーションやコンテンツの設計者は、特定の装置やプロトコルに対して設計することを余儀なくされている。また、コンテンツやアプリケーションの設計者は、コンテンツやアプリケーションのみに注目するよりも、該アプリケーションのために利用したり該コンテンツを表示できそうな特定の装置のためのコンテンツやアプリケーション、またはその装置の特定のプロトコルのためのコンテンツやアプリケーションを修正するために、貴重な時間と費用を使わねばならない。例えば、現在、ユーザの装置に搭載されているウェブブラウザの種類を検出するシステムがある。ユーザの装置にＮＥＴＳＣＡＰＥブラウザが搭載されていれば、ＮＥＴＳＣＡＰＥ環境用に設計されたコンテンツを有する、事前に規定されたＮＥＴＳＣＡＰＥウェブページをユーザに送信する。また、別のウェブブラウザ、例えばＭＩＣＲＯＳＯＦＴウェブブラウザがユーザの装置に搭載されていれば、ＭＩＣＲＯＳＯＦＴ環境用に設計されたコンテンツを有する、事前に規定されたＭＩＣＲＯＳＯＦＴウェブページをユーザの装置に送信する。本来、ある１の環境に基づいて作成されたコンテンツの多くは基本的に他の環境とは両立しないので、このような方法に関連する時間や費用は膨大になるだろう。プロトコルおよび／または装置は、特定のアプリケーションに対する需要を満たすべく、本来意図された通りにコンテンツを表示、通信しようとするかもしれないが、その目的にそぐわない結果となる場合が多い。
【０００８】
したがって、プロトコルや装置に依存しないアプリケーションやコンテンツを作成し、そのコンテンツを任意のプロトコルや装置に適合させて使用可能にするシステムが必要とされている。
【０００９】
（発明の開示）
本発明は、業界における上述の必要性を解決する方法およびシステムに関する。
【００１０】
本発明の１実施形態によると、プロトコル独立装置独立型アプリケーションからプロトコル依存装置依存型アプリケーションを作成する方法を提供する。該方法は、プロトコル独立装置独立型コンテンツオブジェクトを受信し、前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更し、前記装置に対するＲＤＦに基づいて、前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更することを含む。
【００１１】
別の実施形態によると、前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツにするステップは、前記プロトコル独立装置独立型コンテンツを、プロトコルを保存するコンテナにマッピングすることを更に含んでもよい。前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更するステップは、前記プロトコル依存装置独立型コンテンツを、装置性能つまりＲＤＦを保存するハンドラに登録することを更に含んでもよい。
【００１２】
更に別の実施形態によると、プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成する方法は、コンテンツ開発者にアクションを提供し、アクションを拡張するためにＡＰＩをコンテンツ開発者に提供することを更に含んでもよい。この方法は、コンテンツ開発者から、拡張されたアクションを受信することを更に含んでもよい。
【００１３】
更に別の実施形態によると、プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更する方法は、各々が装置の１特徴に対応し、該装置用のＲＤＦに基づいて該装置のためのアプリケーションを制御するハンドラ（オブジェクト）からなる装置オブジェクトを実例化することを更に含んでもよい。
【００１４】
更に別の実施形態によると、プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成するシステムを提供する。該システムは、クラスファイルと、前記クラスファイルを利用して、プロトコル独立装置独立型コンテンツオブジェクトを作成するためのアプリケーションプログラミングインターフェイスと、前該装置のＲＤＦに基づいて、記プロトコル独立装置独立型コンテンツオブジェクトをプロトコル依存装置独立型コンテンツオブジェクトに適合するためのエンジンと、前記プロトコル依存装置独立型コンテンツオブジェクトをプロトコル依存装置依存型コンテンツオブジェクトに適合するためのエンジンとを有する。
【００１５】
更に別の実施形態によると、前記プロトコル独立装置独立型コンテンツオブジェクトをコンテナにマッピングしてもよい。プロトコル依存装置独立型コンテンツを、ＲＤＦに含まれる情報に基づいて実例化したハンドラに登録してもよい。プロトコル独立装置独立型コンテンツオブジェクトは、オブジェクト指向プログラミングを用いて作成してもよく、プロトコル独立装置独立型コンテンツオブジェクトは、第１のアクションを拡張する。更に、エンジンは装置オブジェクトを実例化してもよい。
【００１６】
更に別の実施形態によると、プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成する方法を提供する。該方法は、プロトコル独立装置独立型コンテンツオブジェクトを作成し、前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更し、前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する。更に、前記プロトコル独立装置独立型コンテンツを作成するステップは、オブジェクト指向プログラミングを利用することを含んでもよい。
【００１７】
更に別の実施形態によると、前記プロトコル独立装置独立型コンテンツを作成するステップは、アプリケーションプログラミングインターフェイスを利用することを更に含む。前記アプリケーションプログラミングインターフェイスを使うステップは、アクションを拡張することを更に含む。
【００１８】
更に別の実施形態によると、多数のプロトコルを走らせる多数の装置において使用してもよいアプリケーションを一旦構築する方法を提供する。該方法は、プロトコル独立装置独立型コンテンツを作成し、前記アプリケーションを多数のプロトコルに適合させ、前記アプリケーションを多数の装置に適合させる。更に、前記アプリケーションを複数のプロトコルに適合させるステップは、前記多数のプロトコルの１個を選択し、前記アプリケーションを、選択したプロトコルに変更することを更に有してもよい。更に、前記アプリケーションを多数の装置に適合させるステップは、前記多数の装置１個を選択し、前記アプリケーションを、選択した装置に適合することを更に含んでもよい。
【００１９】
更に別の実施形態によると、多数のプロトコルを走らせる装置において使用してもよいアプリケーションを一旦構築する方法を提供する。該方法は、プロトコル独立装置独立型コンテンツを作成し、前記コンテンツを多数のプロトコルに適合させ、前記コンテンツを多数の装置に適合させることを含む。
【００２０】
更に別の実施形態によると、プロトコル独立装置独立型コンテンツからプロトコル依存装置依存型コンテンツを作成するシステムを提供する。該システムは、プロトコル独立装置独立型コンテンツオブジェクトを作成する手段と、前記プロトコル独立装置独立型コンテンツをプロトコル依存装置独立型コンテンツに変更する手段と、前記プロトコル依存装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する手段とを有する。更に、前記プロトコル独立装置独立型コンテンツを作成する手段は、オブジェクト指向プログラミングを使用する手段を更に含んでもよい。更に、前記プロトコル独立装置独立型コンテンツを作成する手段は、アプリケーションプログラミングインターフェイスを使用する手段を更に含んでも良い。更に、前記アプリケーションプログラミングインターフェイスを使用する手段は、アクションを拡張する手段を更に含む。
【００２１】
本発明の、上記およびそれ以外の特徴、態様、効果は、添付の図面を参照すると、より良好に理解されるであろう。
【００２２】
（発明を実施するための最良の形態）
本発明の実施形態は、概念的には、オブジェクト指向プログラミングに基づいて実行してもよい。したがって、オブジェクト指向プログラミングの原理について限定的に説明することが適切であろう。
【００２３】
従来のプログラミング技術は概して、ある種の構造化プログラミング方法に従たがっている。構造化プログラミング方法によって作成されたプログラムでは通常、プログラムモジュールが階層になっている。各モジュールは１個のエントリポイントと１個のイグジットポイントとを有し、制御は、プログラム構造内の高いレベルへ無条件に分岐することなく、該構造の上から下に向かって行われる。構造化プログラミング方法を用いるプログラムの殆どは３個の基本的な制御構成要素を用いている。つまり、１）順番（プログラムインストラクションが一次的、つまり次々に実行される制御構成）、２）選択（条件テストに基づいてインストラクションパスを選択する制御構成）、３）反復（インストラクションを繰り返す制御構成）である。構造化プログラミング環境では、データ構成とプログラミング機能とは分離されている。
【００２４】
構造化プログラミング方法は、理論的なフローであって読み易いプログラムを設計するが、大きなソフトウェアシステムや複雑なデータ構成の設計を容易にするわけではない。したがって、構造化プログラミング方法を用いる大きなソフトウェアシステムは、急速に扱い難い厄介物になっている。プログラムやシステムが大きくなるとデータ構造も複雑になるので、より大きなソフトウェアシステムを「構成要素」として扱えるように、オブジェクト指向プログラミング等の技術が開発された。また、実際の世界では全ての物がオブジェクト（物）なので、オブジェクト指向プログラミングは、実際の世界を非常に綿密にモデル化している。
【００２５】
オブジェクト指向プログラミングは、構造化プログラミングや他のプログラミング技術からは、「オブジェクト」を使用するという点によって区別される。オブジェクトは、その中身をユーザに知らされていない（また知らせる必要がない）、コード（つまり、コンピュータインストラクション）とデータ（つまり、コンピュータインストラクションの動作が基づく情報）とを含む「ブラックボックス」と考えることができる。個別の対象物として、オブジェクトは自律的であって、特定のタスクを行なう。オブジェクトのユーザは、該オブジェクトが実行する特定のタスクと、該オブジェクトと通信する方法だけを知っていればよい。
【００２６】
オブジェクトとの通信は「メッセージ」を介して行なわれる。メッセージが送信されるオブジェクトはメッセージのレシーバと呼ばれる。メッセージを送信する対象物はメッセージのセンダと呼ばれる。センダは通常、レシーバが用いる方法を考慮することでメッセージに含まれる要求に準拠するということはなく、レシーバのみがメッセージに含まれる要求に準拠する。
【００２７】
オブジェクトへのアクセスはメッセージを介した通信に限定されるので、オブジェクトに関する情報（オブジェクトの機能が如何に実行されるか、オブジェクトがどんなデータを必要とするか等に関する詳細だが、これらに限定されない）の殆どが本質的に隠されている。通常これは問題ではない。オブジェクトの内部動作は通常、ユーザには重要でないからだ。オブジェクトのユーザは、オブジェクトが何を行ない、オブジェクトと如何に通信するかだけを知っていればよい。オブジェクトの内部動作や操作は、ユーザとのンターフェイスが同じである限り、変更できる。オブジェクトに関する情報を隠しておくという概念は「カプセル化」と呼ばれる場合がある。つまり、オブジェクトをカプセルに包むわけである。
【００２８】
オブジェクトは、その「クラス」によって規定される。クラスは、オブジェクトに関するあらゆる事柄を決定する。クラスを、オブジェクトを規定する青写真になぞらえてもよい。オブジェクトはクラスの個々の例である。したがって、クラスを具体化する（ｉｎｓｔａｎｔｉａｔｅ）ことはオブジェクトを作ることであり、１クラスの一部であって該クラスによって規定される特徴を有してもよい多数のオブジェクト、つまりあるクラスの多数の実例がある。例えば「犬」と呼ばれるクラスがある。「犬」クラスから、該クラスの個々の例（例えば「ビーグル」、「プードル」、「ダルメシアン」等）、つまりオブジェクトを作成してもよい。したがって、犬クラスは、犬オブジェクトであることがどんなことであるかを理解するために必要なあらゆる事柄を規定する。例えば、犬オブジェクトが理解するメッセージ（この場合は「待て」、「お座り」、「来い」であろうが）を規定することを含む（が、これに限定されない）。
【００２９】
「基礎要素」はスーパークラスであって、これを元にして全てのクラスを拡張してもよい。したがって、基礎要素またはスーパークラスを拡張するとは、基礎要素またはスーパークラスの機能に追加することである。
【００３０】
コンピュータプログラマまたはソフトウェアエンジニアが既存のクラスに似たクラスをオブジェクト指向プログラミング技術を用いて規定したい場合、新規のクラスを全て再規定する必要はない。必要なことは、既存のクラスのサブクラスを作るだけである。新規のサブクラスは既存のクラスの性質や特徴を全て引き継いでもよい。この特質は「継承」として知られている。継承によって、あるクラスは、そのクラスが関連する任意の他のクラスの特性や特徴を呈することができる。したがって、新規のクラスは、ソースコードつまりプログラムインストラクションを書き直す必要なく規定されてもよい。これはコンピュータプログラマやソフトウェアエンジニアにとって非常に多くの時間の節約になり、通常、大型ソフトウェアシステムや複雑なデータ構造において有益である。通常、新規のクラスの元になった既存のクラスを「親」クラスと呼ぶ。親クラスから形成された新規のクラスを「子」クラスと呼ぶ。したがって、オブジェクト指向プログラミングクラスの識別において、「親」は「子」を有するかもしれない。
【００３１】
「リソース」は、要求された特定のデータまたはコンテンツでもよい。例えば、ビデオ、音声、テキスト、プログラム、ファイル、ＨＴＭＬページ、ＷＭＬページは全てリソースであってもよい。「文書」はリソースの集合体である。
【００３２】
「ハンドラ」は、リソースを特定の装置の特定の性質に適合させるためのオブジェクトである。装置の特性や性質は、その装置のリソース記述フレームワーク（ＲＤＦ）に記述されている。換言すれば、ハンドラは、リソースつまりコンテンツを取り込んで、特定の装置（キーパッド、カラーディスプレイ等）に適合させてもよく、該装置の特定の特性（例えば、バンド幅、計算力、メモリ、画像サポート、音声サポート、言語、等）を考慮する。例えば、カラーディスプレイの場合、ハンドラは適切なコンテンツをディスプレイのスクリーンの大きさに合うように適合させてもよい。また、画像を適合させてスクリーンに相応させたり、画像を適切な形式に変換してもよい。さらに、ある言語のファイルを他の言語に適合させてもよいし、装置のバンド幅やメモリの限界に基づいて音声ファイルの品質を適合させてもよい。
【００３３】
「エンジン」は、処理およびアーキテクチャである。本発明の実施形態の場合、エンジンは、要求されたオブジェクト、リソース、または文書を、これを受信するであろうディスプレイその他の装置での使用に適するように、装置の種類やその装置が実行するプロトコルとは無関係に、変更（ｒｅｎｄｅｒ）する。つまり、エンジンは、コンテンツを受信する装置のＲＤＦに記述されているような性能に基づいて、該コンテンツを変更する。
【００３４】
現在、市場では、オブジェクト指向プログラミング用のコンピュータ言語が幾種類かある。最も人気がある言語はＣ＋＋であって、ＢＥＬＬ　ＬＡＢＯＲＡＴＯＲＩＥＳによって１９８０年代初頭に開発された。さらに、ＪＡＶＡ（登録商標）も人気の言語の一つであって、ＳＵＮ　ＭＩＣＲＯＳＹＳＴＥＭＳ，ＩＮＣ．によって１９９０年代半ばに開発された。ＪＡＶＡ（登録商標）は特にインターネットアプリケーションの開発に非常に適しており、実際、こうした環境を想定して開発された。しかし、オブジェクト指向プログラミング技術は、殆どどんなプログラミング言語またはシステムにおいて使用してもよい。
【００３５】
オブジェクト指向プログラミング技術を用いれば、システム開発を早め、システムの柔軟性を改良できるかもしれない。さらに、開発コストや維持コストを軽減できるかもしれない。
【００３６】
本発明の実施形態に係るシステムが使用されるであろう一般的な環境を図１Ａに示す。コンテンツを変更するための本発明の実施形態に係るソフトウェアが常駐するシステムサーバ２を、ネットワーク４に接続してもよい。システムサーバ２は、メモリと、１台以上のプロセッサと、入力／出力装置と、ネットワークハードウェアと、係るシステムや当業におけるユビキタスのための一般的であるその他のハードウェアやソフトウェアとを有する１台以上のコンピュータでもよい。ローカルでもリモートでもよい１個以上の端子が、システムサーバ２に対するインターフェイスとなってもよい。
【００３７】
ネットワーク４は、構内ネットワーク（ＬＡＮ）でも、広域ネットワーク（ＷＡＮ）でも、インターネットでも、複数のコンピュータが相互に接続されて相互にインターフェイスとなって通信できるきるその他の構成でもよい。例えば、ネットワーク４は、そこに設けられた装置の幾つかまたは全てが無線接続を介して相互に通信できる無線ネットワークでもよい。
【００３８】
システムによって適合されるアプリケーションが開発されるサーバ６も、ネットワーク４に接続されてもよい。この開発サーバ６も、当業において一般的であるハードウェアやソフトウェアを有するコンピュータでもよい。開発サーバ６は、ネットワーク４を介して他のシステムサーバ２と通信してもよい。
【００３９】
ユーザ装置８もネットワーク４に接続してもよい。ユーザ装置８はコンピュータ（パソコンやサーバ等）でも、可搬型無線装置（携帯電話、携帯個人情報端末（ＰＤＡ）、ページャ等）でもよい。あるいは、現在、市場に出回っている複数のインターネットアプライアンスの中の任意のものでも、コンテンツや情報を取得して利用するその他の任意の装置でもよい。
【００４０】
図１Ａを参照して説明した環境においてシステムは、通常、以下のように使用される。つまり、アプリケーション開発者がアプリケーションサーバ６においてコンテンツを開発してもよい。アプリケーションは、例えばウェブサイト用でもよく、音声、ビデオ、テキスト、ＪＰＥＧ画像、ＨＴＭＬページ、その他の情報を含んでもよい。コンテンツは他の種類のアプリケーション（例えば、携帯電話のディスプレイに表示される情報等）用かもしれないが、アプリケーション開発者は、そのシステムが提供するＡＰＩを用いて、特定のプロトコルや装置とは無関係に、アプリケーションを開発してもよい。
【００４１】
アプリケーション開発者がアプリケーションを開発し使用可能になると、そのアプリケーションをシステムサーバ２に装填して展開し、ユーザ装置８がそのアプリケーションを要求できるように入手可能な状態にしてもよい。アプリケーションは、システムサーバ２や、ネットワーク４に接続された他のシステムに常駐してもよい。例えば、開発サーバ６において開発者によって開発されたアプリケーションがウェブサイト用である場合、そのコンテンツは、そのコンテンツ開発者が契約するかその他の方法で関係する第三者のウェブ提供サービスが所有および運営するウェブサーバに常駐してもよい。
【００４２】
要求がユーザ装置８からシステムサーバ２に送られると、システムサーバ２およびこれに常駐するソフトウェアが該アプリケーションを、要求したユーザ装置８が使用する、ＲＤＦで記述されたプロトコルや該装置８の性能に適合する形式に変更する。変更後、プロトコル依存装置依存型コンテンツをウェブサーバに送信するか、ユーザ装置８に直接送信するかして、ユーザ装置８が使用できるようにする。
【００４３】
本発明の実施形態を、オブジェクト指向プログラミング技術を用いて実行してもよい。例えば、図１Ｂは、任意の特定のプロトコルや装置とは無関係に開発されたコンテンツを多様なプロトコルや装置に適合させる方法を示す基本的なフローチャートである。アプリケーション開発者は、ステップ１０において、ＡＰＩや、本発明の実施形態に係る処理を用いて、任意の装置やプロトコルから独立したコンテンツオブジェクトを作成する。アプリケーション開発者は、作成したコンテンツが特定の装置において特定のプロトコルを用いて如何に表示されるかについては考慮する必要がない。アプリケーション開発者が考慮しなけばならない事は、コンテンツ自身と、コンテンツ開発者がそのコンテンツを、装置やプロトコルとは無関係に、如何に表示したいかということだけである。アプリケーションを、アプリケーション開発者のコンピュータまたは他の場所に保存してもよい。例えば、アプリケーションは、ウェブ提供会社が運営するウェブサーバ上に保存されてもよいし、コンテンツは、システムサーバによって保存されてもよい。
【００４４】
コンテンツオブジェクトの作成後、ステップ１２において、複数のユーザ装置の中の任意の装置がそのコンテンツに対する要求を送る。コンテンツを要求するユーザ装置は、パソコン、個人情報携帯端末、ページャ、携帯電話、コンテンツを要求できるその他の任意のユーザ装置でもよい（ただし、これらに限定されない）。
【００４５】
しかし、コンテンツは、本発明の実施形態にしたがって変更または適合される前は、オブジェクト指向のＡＰＩを用いて特定の任意のプロトコルや装置とは無関係に作成されているので、通常、該コンテンツを要求したユーザ装置が使用するには不向きである。したがって、要求されたコンテンツと同様、コンテンツに対する要求も、ステップ１３において、システムサーバに送られて変更する。
【００４６】
ステップ１５において、システムサーバは、コンテンツを要求したユーザ装置の種類を検出し、該ユーザ装置が使用するプロトコルや該装置の性能を記述した該装置のためのＲＤＦを取り出す。このプロトコルおよびユーザ装置は、作成されたコンテンツを使用したい任意のプロトコルまたはユーザ装置でもよい。コンテンツを要求したユーザ装置に関連するプロトコルやユーザ装置の情報を要求の一部として含めてもよい。ユーザ装置の種類を検出した後システムは、システムが維持しシステム保存装置に保存された、複数のプロトコルや装置性能を含むデータベースからＲＤＦを選択してもよい。
【００４７】
要求したユーザ装置の種類、そのユーザ装置が使用するプロトコル、および該ユーザ装置の性能を検出したら本発明の実施形態に係るエンジンは、ステップ１７において、オリジナルのコンテンツオブジェクトから、装置独立型ではあるが要求したユーザ装置のプロトコルには依存するオブジェクトを作成する。この場合のエンジンとは、要求を送ったユーザ装置が使用する特定のプロトコルに基づいて、要求されたコンテンツを変更または適合させる処理およびアーキテクチャのことである。
【００４８】
その後、ステップ１８において、本発明の実施形態に係るエンジンは、変更されたオブジェクトから、ユーザ装置のプロトコルおよび該ユーザ装置の性能に依存するコンテンツを作成する。つまり、ステップ１８の後では、コンテンツ開発者が作成したコンテンツは、プロトコルおよび装置に依存している。
【００４９】
ステップ１９では、プロトコルおよび装置に依存することになった作成されたアプリケーションを、要求したユーザ装置のプロトコルおよび性能に適合する形式で、該ユーザ装置に送信する。あるいは、プロトコル依存装置依存型コンテンツを、コンテンツ開発者またはコンテンツ開発者と関連する会社やサービス（ウェブ配信会社等）に送信してもよい。
【００５０】
プロトコル独立装置独立型コンテンツを、プロトコル依存装置独立型コンテンツに変更するソフトウェアとして、本発明の実施形態に係る一般的なシステムを、図２Ａに示す。このシステムは、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実現してもよい。サーブレット２２はシステムサーバ２１に常駐してもよい。サーブレット２２は通常、アプリケーション全体に対してシステム管理機能を提供するソフトウェアである。サーブレット２２は、システムエンジン２５、セッションマネージャ２７、統一メッセージマネージャ２９、デーバベースアクセスマネージャ３１のそれぞれに対するアプリケーションプログラミングインターフェイス（ＡＰＩ）を使用してもよい。しかし、本発明の実施形態はいずれかのサーブレットアーキテクチャに依存する必要はなく、任意のソフトウェアによってシステムエンジンを使用してもよい。
【００５１】
サーブレット２２の詳細を図２Ｂに示す。サーブレットは、ウェブサーバまたはその他のコンピュータ（図示せず）や装置から、プロトコル独立装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更するセッションを求める要求２０を受信してもよい。サーブレット要求２０を受信したサーブレット２２はセッション環境を設定し、適切なデータベース接続および統一メッセージ接続を確立し、このセッションを行うために必要なこれら以外のシステム管理機能を行ってもよい。サーブレット２２はまた、アクション２４を識別してもよい。アクションは、ソフトウェアまたは、アプリケーション開発者が書いた、コンテンツを表すコードでもよい。オブジェクト指向プログラミング言語（例えばＪＡＶＡ（登録商標）であるが、これに限定されるわけではない）の中には、アクションを「抽象クラス」と呼ぶ言語もあって、ＪＡＶＡ（登録商標）の場合、抽象クラスとは、方法（即ち、サーブレット２２が使用してもよい機能）と抽象的な方法（即ち、サーブレット２２が使用してもよいインターフェイス）とを有するクラス（即ち、ファイルまたはコード）である。アクションは、アプリケーション開発者が、プレゼンテーションエンジン２６、セッションマネージャ２７、統一メッセージングシステムマネージャ２９、データアクセスマネージャ３１に対するＡＰＩを用いて、書いてもよい。開発者は、システムのＡＰＩを用いて「実行」方法を実行してもよい。実行方法によってプロトコル独立装置独立型コンテンツオブジェクトをサーブレット２２に送ると、サーブレット２２は、このオブジェクトを通してプレゼンテーションエンジン２６に送り、プレゼンテーションエンジン２６はプロトコル依存装置依存型コンテンツを送る。
【００５２】
認識したアクション２４（または抽象クラス）を具体化してプロトコル独立装置独立型オブジェクトにする。該オブジェクトはサーブレット２２に送られ、更にプレゼンテーションエンジン２６に送られる。アクション２４つまり抽象クラスの具体化後、開発者が作成したコンテンツは、プレゼンテーションエンジン２６に対するＡＰＩによって、装置独立プロトコル依存型オブジェクトになっている。次にサーブレット２２は、ウェブサーバ、またはコンテンツに対する要求を送った装置に、レスポンス６２を送る。
【００５３】
本発明の実施形態において、サーブレット２２は任意のアプリケーションに共通（ｇｅｎｅｒｉｃ）でもよい。通常サーブレットはアプリケーションに依存するが、共通のサーブレットを用いる本発明の実施形態は、アプリケーション開発者がサーブレットのカスタマイズや操作することなくコードを開発するように、構成されている。つまり、本発明の実施形態によれば、アプリケーション開発者は、サーブレットのカスタマイズや操作ではなく、アクションの構築に集中できる。
【００５４】
上述のように、サーブレット２２はＡＰＩを使用してもよい。データベースアクセスマネージャ４０に対するＡＰＩは、図２Ｂに示すように、データアクセス要求４２、データアクセスレスポンス４４、拡張可能マークアップ言語（ＸＭＬ）生成要求４６、ＸＭＬ生成４８、排出データ５０へのアクセス、接続プーリング５２、ＸＭＬ−ＡＰＩ５４のそれぞれに対するインターフェイスを有する（が、これらに限定されない）。
【００５５】
サーブレット２２が使用する、統一メッセージングマネージャ３８に対するＡＰＩは、ショートメッセージサービス（ＳＭＳ）５６、ファックス５８、電子メール６０、その他の通信モードに対するインターフェイスを有してもよい（が、これらに限定されない）。サーブレット２２が使用する、セッションマネージャ３６に対するＡＰＩは、ユーザ管理３０とセッション管理２８とを含んでもよい（が、これらに限定されない）。サーブレット２２が使用する、プレゼンテーションエンジン２６に対するＡＰＩは、コンテンツ開発者が作成したクラスを装置独立プロトコル独立型コンテンツオブジェクトに具体化するために必要なインターフェイスを提供してもよい。
【００５６】
システムは複数のアクション２４を提供してもよい。アクションは、コンテンツ開発者が、プレゼンテーションエンジン２６へのＡＰＩ、セッションマネージャＡＰＩ２７、メッセージングシステムマネージャＡＰＩ２９、データアクセスマネージャＡＰＩ３１を用いて所望のコンテンツを作成するために利用するクラスでもよい。システム開発者は、システムが提供するアクションを、該システムの処理に適する形式に拡張してもよい。システムが提供する通常のアクションは、ログイン、ページ、パラグラフ、トランザクション要求、形式等である（が、これらに限定されない）。
【００５７】
アプリケーション開発者が、本発明の実施形態に係る装置独立プロトコル独立型コンテンツオブジェクトを作成する処理を、図３に示す。アプリケーション開発者は、ステップ７０において、本発明の実施形態に係るＡＰＩを用いて所望のアプリケーションを表すコードを書くことでコンテンツを作成する。クラスファイル（つまりコード）と同様ＡＰＩや、全体のプラットフォームを含むその他のファイルは、「ｊａｒ」、つまりジップアップされて圧縮されたファイルシステムとして、コンテンツ開発者に提示されてもよい。
【００５８】
アクションを構築するにあたって開発者は、プレゼンテーションエンジン２６に対するＡＰＩを用いて、装置独立プロトコル独立型コンテンツオブジェクトを構築してもよい。開発者は、図４に示すように、オブジェクトに子、データ、属性を付加してもよい。例えば、コンテンツ開発者がインターネット上のウェブサイト用のＨＴＭＬページを作成したい場合、システムが提供するＡＰＩを使い、オブジェクト指向法によって所望のコンテンツを表すコードを書く。これは、コードが完成した場合に、システムが提供する第１のアクションを拡張して第２のアクションにする、つまり抽象クラスと解釈されるように、行う。尚、システムが提供するＡＰＩは、例えばプレゼンテーションエンジン２６（に対するＡＰＩ）、セッションマネージャＡＰＩ２７、メッセージングシステムマネージャＡＰＩ２９、データアクセスマネージャＡＰＩ３１を含んでもよく、アクション２４を構築することでサーブレット２２を介してアクセスされる（が、これは必須ではない）。第１のアクションは、既存のコードを使った通常の方法を含んでもよい。例えば、通常の「アクション実行」や「無効処理」である（が、これに限定されない）。一方、第２のアクションつまり抽象クラスは、第１のアクションの延長であって、そのためのコードをアプリケーション開発者が書いた２個の抽象的な方法を含んでもよい。これら２個の方法とは、抽象的な方法の「アクション実行」や「無効処理」であって（しかし、これに限定されない）、これらは共に、コンテンツ開発者がシステムが提供するＡＰＩを用いて書いたものである。したがって、実例化後、抽象クラス、つまり第２のアクションは、２個の方法「実行」と「無効処理」を含んでもよい。
【００５９】
装置から要求があると、ステップ７２において、サーブレット要求を開始し、アプリケーション開発者が開発したコンテンツクラスを実例化してコンテンツオブジェクトにする、サーブレットによるセッションを要求する。サーブレット要求を受信して要求を有効化すると、ステップ７４において、サーブレットが第２のアクションを呼び出し、その後、ステップ７６において、システムエンジンが第２のアクションを実例化して装置独立プロトコル独立型コンテンツオブジェクトにする。続いて、ステップ７８において、サーブレットは装置にレスポンスを送り、該装置に装置独立プロトコル独立型コンテンツオブジェクトを提供する。ＨＴＭＬページは文書であると考えられ、文書はタイトルが必要なので、コンテンツ開発者は、システムが提供するクラスを利用して文書オブジェクト８０を実例化した後に文書に名前８２をつける。例えば、コンテンツ開発者はこの文書を「マイドキュメント」と呼んでもよい。
【００６０】
開発者は文書にタイトルをつけてもよい。例えば、コンテンツ開発者は、本発明の実施形態が提供するＡＰＩを用いて、「マイドキュメント」というタイトルを「タイトル」に設定してもよい。これによって、タイトル「タイトル」は、この文書に設定された属性となった。次に、コンテンツ開発者は属性に値を与えてもよい。例えば、コンテンツ開発者はタイトル属性「タイトル」を「文書Ｘ」に対して設定してもよい。次に、コンテンツ開発者は、文書オブジェクトに子８４（例えば、ページ）を与え、更に、ページに属性８６（「２ページ」等）を与えてもよい。
【００６１】
上記の例を拡張し、コンテンツ開発者が文書オブジェクトを作成したい場合、コンテンツ開発者はこの文書オブジェクトに属性「タイトル」を与えてもよい。更に、文書オブジェクトに子「ページ」を与えてもよい。「ページ」をオブジェクトと見なしてもよく、属性（「ページ番号」、「パラグラフ」等）を与えてもよい。子「パラグラフ」もオブジェクトと見なしてもよく、子「文章」を有してもよい。子「文章」もオブジェクトと見なしてもよく、属性（「太字」、「斜体」等）や子（「単語」）を有してもよい。子「単語」もオブジェクトと見なしても良く、属性（「太字」、「斜体」等）を有してもよい。このように、オブジェクトや属性や子の規定を、アプリケーション開発者の随意に継続してもよい。
【００６２】
オブジェクトデータはリソースの一部にすぎない。例えば、ビデオ等のリソースを用いる場合、そのリソースの１オブジェクトはデータとして音声を有するかもしれず、そのリソースの他のオブジェクトはデータとして、音声はなくて、ビデオを有するかもしれず、そのリソースの更に別のオブジェクトは、データとして音声とビデオの両方を有するかもしれない。したがって、装置からのリソース要求は、あるオブジェクトの中のデータに対する要求だけでなく、あるオブジェクトの子である複数のオブジェクトに含まれるデータに対する要求かもしれない。
【００６３】
本発明の実施形態に係る処理をインターネットにおいて実行する場合、以下のように進めてもよい。コンテンツ開発者は、図３を参照して上述したオブジェクト指向法によってコードを書くことで、アプリケーションを作成する。次に装置は、システムサーバに常駐するサーブレットからの特定のアクションを要求する。これは、システムサーバのアドレスを識別する全域資源位置指示子（ＵＲＬ）を用いてＨＴＴＰ要求を行うことによって行う。ＵＲＬは要求された特定のアクションに関する情報を含んでもよい。例えば、装置がログインアクションを要求する場合、サーブレットからのレスポンスは「名前とパスワードを入力してください」であるかもしれない。他の例では、コンテンツ開発者がアカウント情報を要求する場合、サーブレットからのレンスポンスは「アカウント情報が欲しいですか？」であろう。
【００６４】
次にサーブレットは、第２のアクション、つまり抽象クラスを呼び出してもよい。これは「アクション実行」と呼ばれてもよく、コンテンツ開発者がこれらのアクションを実行すると、「実行」と呼ばれる方法や「入力有効化」と呼ばれる方法（であるが、これに限定されない）を含む方法を呼び出してもよい（が、これらに限定されない）。サーブレットは、コンテンツ開発者が、システムが提供するＡＰＩを用いて作成したこれらの方法が何を含むかを知らない。実際、これらの方法が、システムが提供するＡＰＩを用いて開発された方法である限り、サーブレットはその中身を知る必要がない。
【００６５】
「入力有効化」方法は、コンテンツ開発者によって要求されたセッションが有効か否かを検出する。これは、コンテンツ開発者によって供給されたコンテンツが該システムの処理に適した形式であるか否かを検出することによって行ってもよい。「入力有効化」方法によって、エンドユーザによって供給されたコンテンツが有効、つまりそのシステムの処理に適していると判断された場合、該アクションに対する「実行方法」が呼び出され、コンテンツオブジェクトを作成し、システムエンジンに供給してもよい。
【００６６】
一方、開発者によって供給されたコンテンツがシステムの処理に不適であると判断された場合、そのセッションを無効とし、「無効化処理」方法を呼び出してもよい。「無効化処理」によって例外処理文書を生成し、システムエンジンに供給してもよい。
【００６７】
装置独立プロトコル独立型ログインアクションを構築するために、システムが提供するＡＰＩを用いて書かれたコードの例を次に挙げる。
2004506977.tif 000003
【００６８】
本発明の実施形態にしたがってプロトコル独立装置独立型コンテンツオブジェクトを特定の装置用に変更する一般的な処理を、図５に示す。上述した通り、コンテンツオブジェクトは、システムの「実行方法」（「実行」というタイトルが付いているかもしれない）を呼び出した後で作成してもよい。作成または提供されたコンテンツオブジェクトを、図５に示すようになシステムエンジン９０（図２Ｂに示すプレゼンテーションエンジン２６と類似している）に供給し、要求を行った装置用に変更する。
【００６９】
サーブレット（図２Ａおよび図２Ｂに示すようなサーブレット２２等）は、要求を行った特定の装置を識別し、特に該装置に関する情報を識別してもよい。システムは、その装置の種類とＲＤＦとをセッションマネージャメモリ、またはシステムに内蔵されるその他の保存媒体に保存してもよい。装置ＲＤＦに関連する情報はＨＴＴＰ要求から得てもよいし、システムが維持しシステムメモリやその他の保存媒体に保存されるデータベースから取り出してもよい。ＨＴＴＰ要求、内部データベース、その他の情報源のいずれからも、要求を行った装置に関する情報を確認できない場合、システムは総括的な装置プロファイル（ＲＤＦ）を想定してもよい。これも、システムメモリまたはその他の保存媒体に保存されていてもよい。
【００７０】
セッション要求を含む文書オブジェクト９４を受信したエンジン９０は、セッションデータ９２を調査し、要求を行った装置用の装置オブジェクト９４（つまり、装置特性のハンドラ表現（以下で説明する））がシステム内に既に存在するか否かを検出する。要求を行った装置用の文書オブジェクト９４がシステム内に既に存在する場合、エンジン９０は、この装置オブジェクト９４とコンテンツオブジェクト９６をプロセッサ９８に供給する。プロセッサ９８とは、装置独立プロトコル独立型コンテンツオブジェクト９６を装置依存プロトコル依存型コンテンツオブジェクト１００に変更する仕組みである。プロセッサ９８を通過した後、コンテンツオブジェクト９６はプロトコル依存装置依存型の形式で、要求を行った装置に送信されてもよい。
【００７１】
一方、要求を行った装置用の装置オブジェクト９４がシステム内に存在しない場合、エンジン９０は、その装置用のオブジェクト表現１０２（つまり、該装置用の１組のハンドラであって、例えば、表示ハンドラ、メモリハンドラ、ソフトキーハンドラ等（以下で説明する））を実例化する。その後、プロセッサ９８は、プロトコル依存装置依存型コンテンツオブジェクトを該装置に送る。
【００７２】
本発明の実施形態に係るプロセッサ（図５に示すプロセッサ９８等）が装置独立プロトコル独立型コンテンツオブジェクトを装置独立プロトコル依存型コンテンツオブジェクトに変更する方法を、図６に示す。図６に示す処理は、帰納的な呼称で「マッピング」と呼ばれるかもしれない。プロセッサは、ステップ１１０において、プロトコル独立装置独立型オブジェクを受信する。受信したオブジェクトは文書オブジェクト等の大きなオブジェクトかもしれないし、文書オブジェクトの場合であれば、ページオブジェクトといった大きなオブジェクトの子かもしれない。例えば、ステップ１１０において、プロトコル独立装置独立型ページオブジェクトが受信されるかもしれない。ステップ１１２の処理では、要求を行った装置が使用するプロトコルを確認することで、該ページオブジェクトがどのプロトコル依存型オブジェクトを有するかを検出してもよい。換言すれば、ステップ１１２の処理によって、プロトコル独立型オブジェクトを如何にしてプロトコル依存型オプジェクトにマッピングするかを検出してもよい。
【００７３】
別の例として、ページオブジェクトを無線マークアップ言語（ＷＭＬ）装置用に変更することを要求したとする。ステップ１１２の処理は、ページオブジェクトが有するＷＭＬのプロトコル依存型オブジェトがどれであるかを検出してもよい。ページオブジェクトが有するプロトコル依存型オブジェクトを決定する規則は、ＷＭＬページコンテナに常駐してもよい。コンテナクラスとは、データを保存し、特定のプロトコルを規定してもよいクラスである。換言すると、コンテナとは、プロトコル独立型オブジェクトをプロトコル依存型オブジェクトにマッピングする仕組みと言ってもよい。したがって、ステップ１１２の処理は、ページオブジェクトについてプロトコル依存型コンテナ（この例ではＷＭＬページコンテナ）を選択することで、プロトコル独立型ページオブジェクトが有するプロトコル依存型オブジェクトを指定する。指定後、プロトコル独立型オブジェクトをプロトコル依存型コンテナにマップしてもよい。
【００７４】
ステップ１１４、１１６は、ステップ１１２におけるコンテナクラスの選択とほぼ同時に行われ、これらのステップでの処理によって、オブジェクトの属性と、オブジェクトの子を取得する。例えば、ステップ１１０において、プロトコル独立装置独立型ページオブジェクトを受信した場合、このページオブジェクトは「タイトル」属性を有するかもしれず、ステップ１１４において、「タイトル」属性を取得してもよい。さらに、このページオブジェクトはオブジェクトの子（「パラグラフ」オブジェクト等）を有するかもしれず、ステップ１１６において「パラグラフ」オブジェクトを取得してもよい。
【００７５】
ステップ１１６においてオブジェクトの子があれば、これらの子を適切なコンテナ内にマップしてもよい。つまり、図６に示すように、この処理はステップ１１６からステップ１１０に戻って帰納的に進行してもよい。このようにして、要求された親オブジェクトに関連する子オブジェクトの全てを適切なプロトコルに変更してもよい。
【００７６】
コンテナクラスを選択し、装置独立プロトコル独立型オブジェクトをその中にマップ（することで、該オブジェクト用のプロトコル依存型コンテナを作成）し、親オブジェクトの属性と子の全てを取得した後、ステップ１１８において、コンテナクラスを実例化してプロトコル依存型オブジェクトを作成する。コンテナクラスは、各親オブジェクトおよび、各親に関連する子オブジェクトの各々に対して実例化する。
【００７７】
ステップ１２０において、ステップ１１４で取得したプロトコル独立装置独立型オブジェクトの各々に対する属性を、ステップ１１８で生成したプロトコル依存型オブジェクトに対して設定する。プロトコル依存型オブジェクトの全てに対して属性を設定した後、ステップ１２２において、親オブジェクトおよびその子オブジェクトの全てを含む、該要求に関連するプロトコル独立型オブジェクトを全て合算してもよい。この結果、プロトコル依存装置独立型オブジェクトができる。
【００７８】
プロトコル依存および装置独立型コンテンツオブジェクトを形成する方法の代表的な例として、上述のように、コンテンツ開発者がシステムが提供するＡＰＩを用いてプロトコル独立装置独立型ページオブジェクトを作成したい場合を想定する。図６のステップ１１０において、プロトコル独立装置独立型ページオブジェクトが受信されるかもしれない。
【００７９】
ステップ１１２では、該ページオブジェクトのためにプロトコル依存型コンテナクラスを選択（し、ページオブジェクトをこのコンテナ内にマップ）してもよい。例えば、ＷＭＬプロトコルを用いる装置において該ページオブジェクトを表示する場合、選択されたプロトコル依存型コンテナクラスはＷＭＬページコンテナでもよい。
【００８０】
ステップ１１４において、ページオブジェクトの属性（例えば、タイトル等）を取得してもよい。ステップ１１６では、ページオブジェクトの子オブジェクト（例えば、形式オブジェクト等）を取得してもよい。その場合、該子オブジェクトのために、ステップ１１０から始まる処理を帰納的に呼び出してもよい。
【００８１】
ステップ１１８では、プロトコル独立装置独立型ページオブジェクトのマップ先であるプロトコル依存型コンテナクラスを実例化し、プロトコル依存装置独立型ページオブジェクトを作成してもよい。例えば、ＷＭＬページコンテナクラスを実例化してＷＭＬデッキオブジェクトを作成してもよい。
【００８２】
ステップ１２０では、プロトコル依存型オブジェクトの属性を設定してもよい。ステップ１２２において、該親オブジェクトに関連し上記の処理を経たプロトコル依存型オブジェクト子の全てを該親オブジェクトに付加すると、ステップ１２４において、プロトコル依存型オブジェクトができる。ステップ１２４では、コンテナはなく、プロトコル依存型オブジェクトのみがある。
【００８３】
例示的なコンテナは、以下のようにコードされてもよい。
【００８４】
2004506977.tif 000004
【００８５】
コンテナ構造のオブジェクト表現の一例を図７に示す。この例では、ＷＭＬ文書コンテナ１３０は、ＷＭＬデッキオブジェクト１３２を含む。ＷＭＬデッキオブジェクト１３２は、ＷＭＬヘッドオブジェクト１３４と、ＷＭＬカードオブジェクト１３６とを含む。ＷＭＬヘッドオブジェクト１３４は、ＷＭＬメタオブジェクト１４２を含む。ＷＭＬカードオブジェクト１３６は、ＷＭＬ形式コンテナ１４０と、ＷＭＬテーブルコンテナ１３８とを含む。この例では、親オブジェクトの子オブジェクト自身が如何にしてコンテナとなるのかを、ＷＭＬカードオブジェクト１３６がＷＭＬ形式コンテナ１４０とＷＭＬテーブルコンテナ１３８とを含む様子を示すことで、説明する。
【００８６】
プロトコル独立装置独立型コンテンツオブジェクトをプロトコル依存装置独立型コンテンツオブジェクトに変更した後、本発明の実施形態に係る処理は、該プロトコル依存装置独立型コンテンツオブジェクトをプロトコル依存装置依存型コンテンツオブジェクトに変更する。これは、プロトコル依存装置独立型コンテンツオブジェクトを装置ハンドラに登録することで行う。ハンドラとは、装置および該装置の性能のオブジェクト表現である。したがって、プロトコル依存装置独立型コンテンツオブジェクトをハンドラに登録すると、該プロトコル依存装置独立型コンテンツオブジェクトは、少なくとも部分的には、装置の特徴や限界を解する形式に変更される。換言すれば、ハンドラは、コンテンツオブジェクトをフォーマッティングし、装置が有する特定の属性を以て使用できるように「処理（ハンドル）する」。
【００８７】
プロトコル依存装置独立型コンテンツオブジェクトをハンドラに登録することのオブジェクト表現を、図８に示す。データと、属性と、（データと、自身の子とを有してもよい）子１５８とを有してもよいプロトコル依存型オブジェクト１５０を、ハンドラ１５２、１５４、１５６に登録する。これらのハンドラの各々は装置の１特性を制御し、ＲＤＦで書かれたような該特性の性能を周知している。オブジェクトは、フォーマッティング要求を各ハンドラに通し、相当する特性に対する特定の制御を行うハンドラに該要求を受信させる。
【００８８】
装置は複数の特性を有してもよく、これらの装置特性の各々にハンドラが設けられてもよい。例えば、装置は、テキスト−音声性能、表示、ソフトキー、キーボード、特定の容量のメモリ、音声、その他の特性を含む（が、これらに限定されない）特性を有してもよい。装置が要求を行うと、該装置はその性能をＲＤＦを介してハンドラに伝達する。あるいは、本発明の実施形態に係るシステムは、複数の装置の性能（ＲＤＦ）をデータベースまたはルックアップテーブルに保存していてもよい。装置の性能を伝達されたハンドラは、自身が担当する特定の装置特性を以て実例化を行う。つまり、ハンドラは、該装置の性能に基づいて、ソースを該装置の特定の特性に適合するように制御してもよい。
【００８９】
さらに、個別のオブジェクトを同一のハンドラ組に登録してもよいが、各オブジェクトはハンドラの異なるバージョンを実例化してもよい。つまり、本発明の実施形態は１個以上のハンドラクラスを提供してもよいが、各オブジェクトは各自のハンドラを実例化してもよい。例えば、本発明の実施形態が、オブジェクとして表示ハンドラを提供する場合、本発明の実施形態に係るシステムにおいて処理されてもよいあらゆるコンテンツオブジェクトを、表示ハンドラのコピー、つまり表示ハンドラの別々の１実例に登録してもよい。
【００９０】
あるいは、特定の装置が要求された性能を有さない場合は、オブジェクトをハンドラに登録しなくてもよい。例えば、コンテンツ開発者が音声を含むコンテンツを作成し、音声セグメントに対する要求が親オブジェクトによって受信された場合、特定の装置が音声セグメントをサポートしていなければ、親オブジェクトを、音声をサポートするハンドラに登録しなくてもよい。
【００９１】
例えば、図９のステップ１６０において、ある装置が、親オブジェクト（例えば、文書オブジェクト）に対して５行の表示を要求すると、ステップ１６２において、親オブジェクトは該要求を１ハンドラ組に通し、表示フォーマッティングを担当するハンドラに受信させる。この要求は、ステップ１６４において、親オブジェクト（例えば文書オブジェクト）のハンドラに最初に受信されるかもしれない。このハンドラは１表示行だけをフォーマットできる表示ハンドラである。つまり、この表示ハンドラは要求の全体を処理できないので、該要求を親オブジェクトの子である表示ハンドラに送る。するとこのハンドラは、要求の残り部分を処理しようとするかもしれない。該表示ハンドラが要求の残り部分を処理できなければ、子オブジェクトは、該要求の全てを処理する（この例では、表示の５行が全てフォーマットされる）まで、帰納的に次の子オブジェクトを呼び続ける。要求の全てが表示ハンドラの各々によって処理されると、ステップ１６６において、結果を添付し、文書は（この例では５行）フォーマットされたことになる。
【００９２】
コンテンツを特定の装置用に変更することを求める要求のオブジェクト表現を、図１０に示す。コンテンツのフォーマットを求める要求１７０が親オブジェクト１７２に受信される。親オブジェクト１７２はこの要求を１装置ハンドラ組１７４、１７６、１７８に送り、該要求の担当ハンドラに要求１７０を受信させる。関連のハンドラが要求１７０を満たせない場合、要求１７０を子オブジェクトに送り、この処理を帰納的に呼び出して、要求１７０が満たされるまで繰り返してもよい。要求１７０が満たされると、レスポンスが添付されて親オブジェクト１７２に送られる。要求１７０を行った装置に総計レスポンス１８０を送ってもよい。
【００９３】
したがって、本発明の実施形態に係るにシステムおよび方法によれば、アプリケーション開発者は、特定のプロトコルや装置を気にすることなく、コンテンツを作成できる。アプリケーション開発者は、プレセンテーションエンジンのＡＰＩによってプロトコル独立装置独立型コンテンツオブジェクトを作成できる。このオブジェクトは、本発明の実施形態に係る方法およびシステムを用いて作成されている限り、任意の装置またはプロトコルによって利用されるかもしれない。本発明の実施形態に係る方法およびシステムによって提供されるプラットフォームは、本発明の実施形態に係る方法およびシステムによって作成されたコンテンツオブジェクト（セッション管理、接続プーリング、統一メッセージングへのアクセス、メッセージキューイング、多数の装置やプロトコルに対する動的コンテンツの表現を含むが、これらに限定されない）を変更するために必要な全てのステップを自動化する。
【００９４】
アプリケーション開発者が特定の装置またはプロトコルに対するコンテンツを作成したい場合、本発明の実施形態に係る方法および装置は、コンテンツ開発者にその能力を提供する。
【００９５】
アプリケーション開発者は、システムによって提供される二次的なＡＰＩを利用してもよい。二次的なＡＰＩの使用は２ステップからなるかもしれない。第１に、二次的なＡＰＩを用いてプロトコル独立オブジェクトを拡張し、プロトコルおよび装置が特定された属性を含めてもよい。以下のコードは、その一例である。
【００９６】
2004506977.tif 000005
【００９７】
上記の１行目において、ヘディングと呼ばれるテキストオブジェクトが作成される。上記の２行目で、プロトコル独立装置独立型オブジェクトのテキスト属性を「量」に設定する。３行目で、ＷＭＬ特定オブジェクトに対するテキストを「Ｑｔｙ」に設定する。４行目で、ＶｏｉｃｅＸＭＬインタープリタが音声プロントとして使用するオブジェクトに音声ファイルを付加する。
【００９８】
本発明の実施形態に係る二次的なＡＰＩを使用する場合の第２のステップとして、プロトコル特定オブジェクトを保持するコンテナの構成を開発してもよい。この構成は、プロパティファイル設定、または親子オブジェクトと属性との関係を記述するＸＭＬ記述によって規定されてもよい。
【００９９】
コンテンツ開発者が、本発明の実施形態によって提供される二次的なＡＰＩを用いて、ＷＭＬ用のコンテナをＸＭＬで如何に規定するかの１例を以下に示す。
【０１００】
2004506977.tif 000006
【０１０１】
プロトコル独立装置依存型オブジェクトの作成方法を示すオブジェクト表現を図１１に示す。二次的なＡＰＩ１９０を用いて、データ１９４と、（属性１９８と子２００とを有するかもしれない）子１９６とを有するプロトコル独立型オブジェクト１９２を生成する。システムが提供するコンテナではなくユーザが規定するコンテナを用いて、プロトコル独立型オブジェクト１９２をプロトコル依存装置依存型オブジェクト２０２にマップしてもよい。
【０１０２】
本発明の特定の実施形態を説明したが、当業者においては、本発明は説明した特定の実施形態に限定されるわけではなく、請求の範囲の要旨を超えることなく変更や変形を加えられることが分かるであろう。
【図面の簡単な説明】
【図１Ａ】本発明の実施形態が使用されるネットワーク環境のブロック図である。
【図１Ｂ】プロトコル独立装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する、本発明の実施形態に係る方法を示すフルーチャートである。
【図２Ａ】プロトコル独立装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更するソフトウェアが常駐してもよい本発明の実施形態に係る総括的なシステムを示す図である。
【図２Ｂ】本発明の実施形態に係るサーブレットの詳細を示すブロック図である。
【図３】本発明の実施形態に係るコンテンツオブジェクトを作成する方法を示すフローチャートである。
【図４】本発明の実施形態に係るコンテンツオブジェクトを示すオブジェクト図である。
【図５】プロトコル独立装置独立型コンテンツをプロトコル依存装置依存型コンテンツに変更する、本発明の実施形態に係る方法を示すフローチャートである。
【図６】コンテンツ独立び装置独立型コンテンツオブジェクトをプロトコル依存装置独立型コンテンツに変更する本発明の実施形態に係る方法を示すフローチャートである。
【図７】装置プロトコルをコンテンツオブジェクトにマッピングする、本発明の実施形態に係るコンテナのオブジェクト図である。
【図８】本発明の実施形態に係るコンテンツオブジェクトのハンドラへの登録のオブジェクト表現を示す図である。
【図９】本発明の実施形態に係る、コンテンツオブジェクトをハンドラに登録する方法を示すフローチャーチである。
【図１０】本発明の実施形態に係る、コンテンツを特定の装置用に変更することを求める要求のオブジェクト表現を示す図である。
【図１１】本発明の実施形態に係る、プロトコル依存装置依存型コンテンツをプロトコル依存装置独立型コンテンツに変更する方法のオブジェクト表現を示す図である。
【図１Ａ】
2004506977.tif 000007
【図１Ｂ】
2004506977.tif 000008
【図２Ａ】
2004506977.tif 000009
【図２Ｂ】
2004506977.tif 000010
【図３】
2004506977.tif 000011
【図５】
2004506977.tif 000012
【図６】
2004506977.tif 000013
【図７】
2004506977.tif 000014
【図８】
2004506977.tif 000015
【図９】
2004506977.tif 000016
【図１０】
2004506977.tif 000017
【図１１】
2004506977.tif 000018
【国際公開パンフレット】
2004506977.tif 000019
2004506977.tif 000020
2004506977.tif 000021
2004506977.tif 000022
2004506977.tif 000023
2004506977.tif 000024
2004506977.tif 000025
2004506977.tif 000026
2004506977.tif 000027
2004506977.tif 000028
2004506977.tif 000029
2004506977.tif 000030
2004506977.tif 000031
2004506977.tif 000032
2004506977.tif 000033
2004506977.tif 000034
2004506977.tif 000035
2004506977.tif 000036
2004506977.tif 000037
2004506977.tif 000038
2004506977.tif 000039
2004506977.tif 000040
2004506977.tif 000041
2004506977.tif 000042
2004506977.tif 000043
2004506977.tif 000044
2004506977.tif 000045
2004506977.tif 000046
2004506977.tif 000047
2004506977.tif 000048
2004506977.tif 000049
2004506977.tif 000050
2004506977.tif 000051
2004506977.tif 000052
2004506977.tif 000053
2004506977.tif 000054
2004506977.tif 000055
2004506977.tif 000056
2004506977.tif 000057
2004506977.tif 000058
2004506977.tif 000059
2004506977.tif 000060
2004506977.tif 000061
2004506977.tif 000062
2004506977.tif 000063
【国際公開パンフレット（コレクトバージョン）】
2004506977.tif 000064
2004506977.tif 000065
【国際調査報告】
2004506977.tif 000066
2004506977.tif 000067
2004506977.tif 000068