(57)【要約】  データ処理方法は、電子的ドキュメントを受信し、電子的ドキュメントの少なくとも一部をレンダリングし、電子的ドキュメントのレンダリングされない部分を検出し、電子的ドキュメントの一部を有するフィードバックドキュメントを生成し、及びフィードバックドキュメントを送信する。好ましくは、フィードバックドキュメントは、電子的ドキュメントのレンダリングされた部分を有する。
2008547260.tif 000002
【特許請求の範囲】
【請求項１】
電子的ドキュメントを受信するステップ、
前記電子的ドキュメントの少なくとも一部をレンダリングするステップ、
前記電子的ドキュメントのレンダリングされない部分を検出するステップ、
前記電子的ドキュメントの一部を有するフィードバックドキュメントを生成するステップ、及び
前記フィードバックドキュメントを送信するステップ、
を有するデータ処理方法。
【請求項２】
さらに、前記電子的ドキュメントの発信元を検出するステップ、及び前記フィードバックドキュメントを前記電子的ドキュメントの当該発信元に送信するステップをさらに有する請求項１に記載の方法。
【請求項３】
前記フィードバックドキュメントが前記電子的ドキュメントのレンダリングされた部分を有する請求項１又は請求項２に記載の方法。
【請求項４】
前記電子的ドキュメントの少なくとも一部をレンダリングするステップが、前記電子的ドキュメントに従って一組の装置を動作させるステップを有する請求項１から請求項３のいずれか一項に記載の方法。
【請求項５】
前記フィードバックドキュメントを送信するステップが、当該フィードバックドキュメントをローカルデータ記憶装置に記憶するステップを有する請求項１から請求項４のいずれか一項に記載の方法。
【請求項６】
前記電子的ドキュメントの少なくとも一部をレンダリングするステップが、動的変数に従って前記電子的ドキュメントから要素を選択するステップを含む請求項１から請求項５のいずれか一項に記載の方法。
【請求項７】
電子的ドキュメントを受信する受信装置、
前記電子的ドキュメントの少なくとも一部をレンダリングする一組の装置を有し、
前記受信装置が、前記電子的ドキュメントのレンダリングされない部分を検出し、前記電子的ドキュメントの一部を有するフィードバックドキュメントを生成し、及び当該フィードバックドキュメントを送信するデータ処理システム。
【請求項８】
前記受信装置がさらに、前記電子的ドキュメントの発信元を検出し、及び前記フィードバックドキュメントを前記電子的ドキュメントの前記発信元に送信する請求項７に記載のシステム。
【請求項９】
前記フィードバックドキュメントが前記電子的ドキュメントのレンダリングされた部分を有する請求項７又は請求項８に記載のシステム。
【請求項１０】
ローカル記憶装置をさらに有し、
前記受信装置は、前記フィードバックドキュメントを送信する際、当該フィードバックドキュメントを前記ローカルデータ記憶装置に記憶する請求項７から請求項９のいずれか一項に記載のシステム。
【請求項１１】
前記受信装置が動的変数に従って前記電子的ドキュメントからレンダリングするための要素を選択する請求項７から請求項１０のいずれか一項に記載のシステム。
【請求項１２】
電子的ドキュメントを受信するステップ、前記電子的ドキュメントの少なくとも一部をレンダリングするステップ、前記電子的ドキュメントのレンダリングされない部分を検出するステップ、前記電子的ドキュメントの一部を有するフィードバックドキュメントを生成するステップ、及び前記フィードバックドキュメントを送信するステップのための命令を有するコンピュータ読取可能媒体上のデータ処理システム動作用コンピュータプログラム。
【請求項１３】
前記電子的ドキュメントの発信元を検出するステップ、及び前記フィードバックドキュメントを前記電子的ドキュメントの当該発信元に送信するステップのための命令をさらに有する請求項１２に記載のコンピュータプログラム。
【請求項１４】
前記フィードバックドキュメントが前記電子的ドキュメントのレンダリングされた部分を有する請求項１２又は請求項１３に記載のコンピュータプログラム。
【請求項１５】
前記電子的ドキュメントの少なくとも一部をレンダリングするステップが、前記電子的ドキュメントに従って一組の装置を動作させるステップを有する請求項１２から請求項１４のいずれか一項に記載のコンピュータプログラム。
【請求項１６】
前記フィードバックドキュメントを送信するステップが、当該フィードバックドキュメントをローカルデータ記憶装置に記憶するステップを有する請求項１２から請求項１５のいずれか一項に記載のコンピュータプログラム。
【請求項１７】
前記電子的ドキュメントの少なくとも一部をレンダリングするための命令が、動的変数に従って前記電子的ドキュメントから要素を選択するための命令を含む請求項１２から請求項１６のいずれか一項に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ処理方法及びシステム、並びにデータ処理システムを制御するためのコンピュータ読取可能媒体上のコンピュータプログラム製品に関する。
【背景技術】
【０００２】
HTML（Hyper Text Markup Language）のようなマーク付け言語を用いてデータを送信することは、多くのネットワーク（例えばインターネット）において一般的である。（一般的にブラウザを実行している）受信コンピュータは一般的に、オリジナルの"マーク付け"記述を取得してHTMLを作成者が意図するように再現するためにできる限りの最善を尽くす。ウィンドウズＰＣ上のウェブブラウザのようなとても制御された状況において、結果はその意図に非常に近く、確かに容易に再現可能であり、分析できる。
【０００３】
しかしいくつかの状況において、その結果の確かさは低い。例えば、送信されたHTMLがテキスト中のある場所であるカラーを指定し、そして、受信装置がモノクロモニタ上にそのテキストをレンダリングする場合、それはオリジナルの作成者の要望を実行することができない。カラーでなければならないテキストを受信装置がどのように処理するのかは、受信装置が構成される態様に依存する。テキストは色に依存せずに強調されることができ、又はテキストは、それが正常な色であったかのようにレンダリングされることができる。一般に、受信装置は、できるだけレンダリング装置の機能を用いる。HTMLドキュメントを提供した原作成者又は装置は、ネットワークの受信端で何が実際に発生したかについて知る方法がない。
【０００４】
さらに複雑な状況において、マーク付け言語ドキュメントをレンダリングしているブラウザの結果は、通常、原作者の意図の完全なレンダリングではない。これは多くの場合、ホストシステムが記述された体験を再現するいくつかの能力を欠いているからである。これは、高度に動的な及びモジュール式のシステムにおいて特に真実である。
【０００５】
特許文献１は、クライアントに提供される動的なコンテンツカスタマイゼーションのための方法及び装置を開示する。プロファイルリポジトリがさまざまなクライアントのための典型的な装置特性を示すプロファイルを記憶するために用いられる場合、クライアントにその記憶されたプロファイルに対する動的に決定された変更及び／又は追加を問い合わせることが可能であることを示すフラグを記憶されたプロファイルに立てることを可能にするように、リポジトリは構成される。コンテンツプロバイダ（例えば１つ以上のサーバー）とクライアントとの間の通信は、クライアントが特定の動的な特性又は（もしあれば）デフォルトプロファイルからの偏差について問い合わせられることができることを示すための最小限の数の通知がクライアントによってサーバーに行われる必要があるように構成されることができる。
【特許文献１】米国特許出願公開第2004/0267900号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
この方法論は、送信装置が、前記受信装置の能力を含む受信装置上のプロファイルにアクセスすることを効果的に可能にする。これは、送信データを受信装置の能力に合わせて調整することを可能にする。これは、受信装置によって可能な限り最良にレンダリングされるようにドキュメントを単純に送信する既知のシステム等の改善であるが、それは複数の弱点があり、インターネットのようなネットワークに非常に不向きである。この特許文献１中に開示されるシステムは、データが送信される装置の能力について、一定の問い合わせをする必要がある。データは、送信の前に受信装置に合わせて調整されなければならない。これは送信装置に不相応な負荷をかけ、多くの状況において送信側の非常に高い処理コスト、又はドキュメントを送信する際の比較的低下した応答時間につながる。
【課題を解決するための手段】
【０００７】
そのため、本発明の目的は既知の技術の改善である。
【０００８】
本発明の第１の態様によると、電子的ドキュメントを受信し、前記電子的ドキュメントの少なくとも一部をレンダリングし、電子的ドキュメントのレンダリングされない部分を検出し、電子的ドキュメントの一部を有するフィードバックドキュメントを生成し、及びフィードバックドキュメントを送信するデータ処理方法が提供される。
【０００９】
本発明の第２の態様によれば、電子的ドキュメントを受信する受信装置と、電子的ドキュメントの少なくとも一部をレンダリングするように配される一組の装置とを有し、前記受信装置が、電子的ドキュメントのレンダリングされない部分を検出し、電子的ドキュメントの一部を有するフィードバックドキュメントを生成し、及びフィードバックドキュメントを送信するように配されるデータ処理システムが提供される。
【００１０】
本発明の第３の態様によれば、電子的ドキュメントを受信し、電子的ドキュメントの少なくとも一部をレンダリングし、電子的ドキュメントのレンダリングされない部分を検出し、電子的ドキュメントの一部を有するフィードバックドキュメントを生成し、及びフィードバックドキュメントを送信するための命令を有する、コンピュータ読取可能媒質上のデータ処理システム動作用コンピュータプログラム製品が提供される。
【００１１】
本発明により、受信されたドキュメントが成功のうちにレンダリングされた程度に関する情報を含むフィードバックドキュメントを提供することが可能である。この場合、エンドユーザが実際に何を体験しているかについて知ることは発信元アプリケーション又は作成者に極めて有用であり、コンテンツを適応し、インタラクションを修正することを可能にする。マークアップ表記を生成したオリジナルのアプリケーション又は作成者は、結果として生じたユーザ体験のフィードバックから恩恵をうける。
【００１２】
この最終的にレンダリングされるもののマークアップ表記の生成は、発信元アプリケーション又は作成者によって問い合わせられることができる。このアプローチは、発信元アプリケーションがエンドユーザ体験の結果として生じる情報によって、その動作を適応させることができる場合があるシステムに用いられるような動的マーク付け言語において特に有利である。動的なシステムにおいて、レンダリングのための最終的なマークアップ用語の作成は静的ドキュメントにおけるよりも流動的である。時間及びコンテクストのような動的変数に対する参照は、電子的ドキュメントの及びドキュメント内の個々の要素の厳密な内容を決定する。
【００１３】
加えて、このアプローチは、オーサリング及びデバッグ体験において真の効果を与え、ツール及び作成者に意味がある形でのフィードバックを提供する。オーサリングツールは、また、それらが生み出している最終結果が意図に整合しているかどうかについてのフィードバックを必要とする。オリジナルの内容と同じ用語において生成される体験を見ることができることは、より手早いデバッグを可能にする。
【００１４】
有利に、データ処理方法は、電子的ドキュメントの発信元を検出し、及び電子的ドキュメントの発信元にフィードバックドキュメントを送信することをさらに有する。レンダリングされるドキュメントの発信元を認識することによって、フィードバックドキュメントは、送信装置又は電子的ドキュメントのオリジナルの作成者による処理のために、効率的にオリジナルの発信元に送信されることができる。
【００１５】
好ましくは、フィードバックドキュメントは、レンダリングされる電子的ドキュメントの部分を有する。成功のうちにレンダリングされた要素を含むようにフィードバックドキュメントを生成することによって、送信装置又はオリジナルの作成者は、送信されたオリジナルのドキュメントに対する受信装置の体験にアクセスすることができる。
【００１６】
他の実施の形態において、フィードバックドキュメントを送信するステップは、ローカルデータ記憶装置中にフィードバックドキュメントを記憶することを有する。送信装置にフィードバックドキュメントを送り返すよりはむしろ、受信装置のレンダリング体験の結果を判断するために後日アクセスするために、フィードバックドキュメントはローカルに記憶されることができる。
【００１７】
理想的には、電子的ドキュメントの少なくとも一部をレンダリングするステップは、動的変数に従って電子的ドキュメントから要素を選択することを含む。動的変数は、例えば、システムクロック又は任意の開始時刻に基づくことができる時間であることができる。それらの特定された時間成分が実行時間のそれに合致するどうかによって、要素がレンダリングするために選択される。そのような動的なシステムにおいては、したがって、いくつかの要素は、それらが要素を選択するために用いられる動的変数のパラメータの外側なので、レンダリングされない。
【００１８】
本発明の実施の形態が以下に添付の図面を参照して単なる例として記載される。
【発明を実施するための最良の形態】
【００１９】
図1のデータ処理システム10は、HTMLドキュメント又は別のXML対応言語を用いて設計されたドキュメントのような電子的ドキュメント14を受信するための受信装置12を有する。システムは、また、電子的ドキュメント14の少なくとも一部をレンダリングするように配される一組の装置16を含む。（標準のデスクトップＰＣ、又はデジタルテレビジョンのようなメディア装置であることができる）受信装置12は、電子的ドキュメント14をレンダリングする装置のセットの一部を形成することができる。
【００２０】
装置のセット中の装置16は、ディスプレイ装置、照明装置などのような装置を構成することができ、電子的であることができるが、ファン又はヒータ等のような機械的な装置であることもできる。そのようなシステムについての更なる詳細のために、WO02/092183の内容を本明細書に引用したものとする。本質的に、セット中の装置16は、ロケーションの周囲環境を提供するために電子的ドキュメント中の情報をレンダリングする。
【００２１】
受信装置12は、電子的ドキュメント14のレンダリングされない部分を検出する（この過程は図2を参照して以下で更に詳細に記載される）ように配される。一旦ドキュメント14のレンダリングされない部分が識別されると、受信装置12は、オリジナルの電子的ドキュメント14の一部を有するフィードバックドキュメント18を生成する。
【００２２】
それからフィードバックドキュメント18は送信され、オリジナルのドキュメント14の発信元へ戻るか、又はローカル記憶装置20に送られることができる。受信装置12は、電子的ドキュメント14の発信元を検出し、それが要求される場合、電子的ドキュメント14の発信元にフィードバックドキュメント18を送信するように配される。
【００２３】
フィードバックドキュメント18は、電子的ドキュメント14のレンダリングされた部分を有する。そのため、オリジナルの電子的ドキュメント14の全てがレンダリングされたわけではない場合、フィードバックドキュメント18の内容はオリジナルのドキュメント14のサブセットである。レンダリングされるドキュメント14に存在するのと全く同じ用語が、フィードバックドキュメント18中に用いられる。装置16のセットがドキュメント14中のレンダリングできる用語の全てをレンダリングすることができる場合、それでもフィードバックドキュメント18は生成される。
【００２４】
HTMLより複雑な言語の場合、フィードバックは、特にアプリケーションによってオンザフライ(on-the-fly)で電子的ドキュメントが生成されている場合には、特に有用である。オーサリングプロセスがエンドユーザ位置における装置のレンダリング能力から分離されているので、体験の重要な要素がレンダリングされないことが大いにありえる。多くのアプリケーションにおいて、リアクション/インタラクションの予想を調整するため、又はレンダリングシステムの能力により良く適合するように伝達されるデータを調整するために、これが起こったことを知ることは有用である。
【００２５】
同様に、内容をオーサリングするとき、デバッグのプロセスは主に意図が結果によって満たされないところを理解することである。オリジナルと同じ用語における結果の表示を返すことができることによって、どこで問題が発生している可能性があるかを知ることが容易になる。これらの複雑な体験システムにおいて、問題は多くの場合、純粋な構文法の又は論理的なエラーよりも繊細なものであり、これはこれらの分析において有用なツールになるはずである。
【００２６】
図2は、電子的ドキュメント14の受信に続いて受信装置12によって利用されるステップを更に詳細に示す。この図に示されるエンジンは、動的マーク付け言語システムの中で動作している。エンジンは、（"フラグメント"として知られる）生の記述として取り込まれる作成者の意図とそのロケーションにおいて使用可能な装置の種類及びロケーションによって規定されるエンドユーザ"ブラウザ"の能力との間を調停するソフトウェアモジュールのセットである。
【００２７】
モジュールは以下の通り。
【００２８】
-構文解析部−XMLフォーマットのドキュメントを受けて、現在の体験のプールにフラグメントを加える。
【００２９】
-スナップショット−現在の時点においてアクティブな部分を選択する。
【００３０】
-Can Do−現在のブラウザが体験を記述するために行うことができる全ての可能な動作のリストを生成する。
【００３１】
-UN−Can Do List中の競合を解決して、複数のオプションを調停して、そして最高の結果の達成を試みる。Will Do Listを生成する。
【００３２】
-Make-it-so−解決されたリストを受け、使用可能な装置に指示する。
【００３３】
動的なマーク付け言語は、マーク付け言語のフラグメントをさまざまな発信元から『プール』に受け入れるアプローチである。この生のマーク付け言語は、時間及び論理的条件文の両方に対する参照を含む。フラグメントのこの『プール』はそれから、それ自体従来のマーク付け言語に非常に似ており完全に宣言型である現在のコンテクストに基づいてスナップショットを生成するために処理される。そして、これはエンジンによって実現されるものである。時間が経過してコンテクストが変化する度に、新たなスナップショットを生成するために必要なようにスナップショットプロセスは繰り返される。これは、いつ新たなフラグメントを加えるのか、古いデータの除去の際か、時限式の変更かを含む。
【００３４】
Will-Do-Listは装置16のための一組の命令を含むが、この中に、これがスナップショットのどの部分を参照するのかを示すのに十分な情報も含まれる。そのために、これからレンダリングされた結果の表示であって、エンドユーザによって実際に体験されるものを達成するスナップショットのサブセットを構成することが可能である。理想的な世界（又は明確なシステム）では、サブセット及びスナップショットは同一であり、作成者の意図が完全に実現されたことを示す。
【００３５】
多くの状況において、このサブセットはスナップショットと同一でなく、そしてこの表示（フィードバックドキュメント18）は、作成者により又は発信元アプリケーションから問い合わせられるように、エンジンにより（APIを介して）利用可能にされることができる。作成者はそれらの意図を知っているので、比較が行われることができ、そして適切な場合は、発信元はより良い一致を試みて達成するように調整される。
【００３６】
このアイデアは特に、オリジナルのゲーム作成者がエンドユーザのブラウザ能力を確信できないゲームのような非常に動的なコンテンツにおいて応用できる。スコアリング又は体験配信が、多くの場合、エンドユーザが見て、行っているものに対する反応に非常に依存しているので、これがどれくらい密接に発信元が伝えていたものに合致するかについて理解することは非常に有用である。そして例えば、ゲーマーがモンスターを撃たなかった場合、これはユーザがモンスターを取り逃がしたからなのか、又はモンスターがそもそもレンダリングされなかったからなのかを知ることは重要である。
【００３７】
より広いアプリケーションにとって、例えば空間ムード照明において、ユーザ体験を理解することは、照明デザイナー（又は将来の自動ツール）が特定の状況のためのデザインを改善することを可能にするはずである。これは、例えば店又はオフィス環境において、このフィードバックに基づいて遠隔操作で行われることもできる。コンテンツオーサリングにおいて、フィードバックはデバッグに用いられることもでき、現実が作成者の予想に合致しない場合を明らかにする。
【００３８】
図3は上記から示されるロケーション22の例を示す。ロケーションが、コンパスの場所によって、北、北東、東、南東、南、南西、西、北西及び中央ゾーンCの9つの論理的サブロケーションに分割されている。ロケーション22は、論理的サブロケーションNW中のLamp 1と論理的サブロケーションNE中のLamp 2の２つのランプを含む。ロケーション22は、データ処理システム10の動作の2つの異なる例を示すために用いられ、受信された電子的ドキュメント14のコンテンツに依存する。
【００３９】
例1
この例では、電子的ドキュメント14内の要素は次の通りである。
<object> A 
<location> NW </location> 
<state> fire </state> 
<start_time> 0:00 </start_time> 
<end_time> forever </end_time> 
</object> 
<object> B 
<location> NE </location> 
<state> water </state> 
<start_time> 0:00 </start_time> 
<end_time> forever </end_time> 
</object> 
<asset> flames 
<state> fire </state> 
<type> light </type> 
<value> 90, 20, 0 </value> 
</asset> 
<asset> wet 
<state> water </state> 
<type> light </light> 
<value> 0, 20, 90 </value> 
</asset> 
<asset> purple_hit 
<state> hit </state> 
<type> light </light> 
<value> 100, 0, 100 </value> 
</asset> 
<device> lamp1 
<location> NW </location> 
<capability> light </capability> 
</device> 
<device> lamp2 
<location> NE </location> 
<capability> light </light> 
</device>
【００４０】
ドキュメント14内の要素は、object A及びB、asset flames, wet及びpurple_hit、並びにdevice lamp1及びlamp2である。この場合、lamp1はflame assetを用いてオブジェクトobject Aをレンダリングし、object Bはwet assetを用いてlamp2にレンダリングされる。そして、返送されるフィードバックドキュメント18のコンテンツは以下の通りである。
<object> A 
<location> NW </location> 
<state> fire </state> 
</object> 
<object> B 
<location> NE </location> 
<state> water </state> 
</object>
【００４１】
フィードバックドキュメント18はレンダリングの時点におけるオブジェクトのステータスであるので、時間成分はこの表示に重要でないことに注意せよ。
【００４２】
例2
この例では、システム時間が2:00であると仮定される。受信されたドキュメント14のコンテンツは、次の通りである。
<object> A 
<location> NW </location> 
<state> fire </state> 
<start_time> 0:00 </start_time> 
<end_time> forever </end_time> 
</object> 
<object> B 
<location> NE </location> 
<state> water, smoke </state> 
<start_time> 0:00 </start_time> 
<end_time> forever </end_time> 
</object> 
<object> C 
<location> NE </location> 
<state> hit </state> 
<start_time> 0:00 </start_time> 
<end_time> forever </end_time> 
</object> 
<object> D 
<location> NW </location> 
<state> hit </state> 
<start_time> 5:00 </start_time> 
<end_time> forever </end_time> 
</object> 
<asset> flames 
<state> fire </state> 
<type> light </type> 
<value> 90, 20, 0 </value> 
</asset> 
<asset> wet 
<state> water </state> 
<type> light </light> 
<value> 0, 20, 90 </value> 
</asset> 
<asset> purple_hit 
<state> hit </state> 
<type> light </light> 
<value> 100, 0, 100 </value> 
</asset> 
<device> lamp1 
<location> NW </location> 
<capability> light </capability> 
</device> 
<device> lamp2 
<location> NE </location> 
<capability> light </light> 
</device>
【００４３】
この例では（例1と比較して）、新たなobject C及びD、並びにobject B中に追加のstateであるsmokeがある。例1のように、lamp1はflame assetを用いてオブジェクトobject Aをレンダリングし、object Bはwet assetを用いてlamp2にレンダリングされる。この例２において、返送されるフィードバックドキュメント18は以下の通りである。
<object> A 
<location> NW </location> 
<state> fire </state> 
</object> 
<object> B 
<location> NE </location> 
<state> water </state> 
</object>
【００４４】
A及びBは共に（lightに）レンダリングされるが、object Bのsmoke stateをレンダリングする手段がないので、そのstateはレンダリングされたとしてそのobjectの表示中に返送されない。object Cは、エンジンがobject BをNE上のlightにレンダリングするように選択し、それをレンダリングするものがないので、返送されない。object Dは、時刻がそのstart及びend timeの範囲内ではなくレンダリングされないので、返送されない。
【００４５】
フィードバックドキュメント18のコンテンツは、オリジナルのドキュメント14のレンダリングを反映していることが分かる。電子的ドキュメント14を受信する装置又は装置達は、そのドキュメント14のコンテンツをできる限り最良にレンダリングし、フィードバックドキュメント18のコンテンツは、装置16によるレンダリングを反映する。
【図面の簡単な説明】
【００４６】
【図１】データ処理システムの概略図。
【図２】図1のデータ処理システムの受信装置の動作のフローチャート。
【図３】ロケーションの概略平面図。
【図１】
2008547260.tif 000003
【図２】
2008547260.tif 000004
【図３】
2008547260.tif 000005
【国際調査報告】
2008547260.tif 000006
2008547260.tif 000007
2008547260.tif 000008