JP2001510915A - デバイス間の情報受渡し用フォーマット - Google Patents

Abstract

(57)【要約】 情報処理機器間における通信用のドキュメントの電子表現に対するフォーマットが提供される。ドキュメント部を表現するための基本ユニットは、両面シートとしてである。ドキュメント部に含まれる情報は、その各両面シートの１面または両面に対する関係により定義される。両面ページの各面は、サーフェイスを表す平面(270)として表現される。サーフェイスが定義されて、両面シートである「親」オブジェクトの「子」が、サーフェイス上に配置される。例えば、それらの子がイメージを表す。ｚ軸に沿った子の順序は、子がサーフェイス上で配置または描写される順序を示している。このように、電子ドキュメントに、物理的ドキュメントの特質に相当する電子的な物を与えることができ、従ってユーザのインタラクションをより直感的とすることができる。

Description

【発明の詳細な説明】

【０００１】 本発明は、デバイス間で情報を受渡すためのフォーマットに関する。特に、本
発明は、情報処理機器（information handling appliance）間の電子的手段によ
るドキュメントの受渡しに特に適用可能である。

【０００２】 デバイス間での情報の効率的かつ適切な受渡しに対する要求が広まっている。
これは、特に、電子形態のドキュメントを生成、受信または処理する情報処理デ
バイス（information handling device）に対して当てはまる。このようなドキ ュメントは、ワードプロセシングプログラム、（例えば走査により）電子形態に
変換される紙の書類、または有形の（tangible）形態で描写される（render）よ
う用意されたドキュメント（印刷用のイメージまたはプリンタ言語ファイル）に
よって生成されるものである。

【０００３】 電子機器間通信の大抵の例では、アプリケーション固有のプロトコルが必要で
ある。すなわち、一般に、通信は、パーソナルコンピュータ等の計算装置を介し
て行われるものである。その結果、電子ドキュメントの取扱いおよび振舞いが、
従来の書類に適した取扱いおよび振舞いとはかなり異なったものになる。

【０００４】 本発明は、ユーザによる電子ドキュメントおよび物理的なドキュメントの取扱
いを調和させることを目的とする。このような調和により、ユーザが直観的に電
子ドキュメントをより容易に操作することができるようになる。

【０００５】 従って、本発明は、情報処理機器間における通信用のドキュメントの電子的表
現に対するフォーマットであって、ドキュメント部を表現するための基本ユニッ
トは、両面シートとしてであり、ドキュメント部に含まれる情報は、その各両面
シートの１面または両面に対する関係により定義される。

【０００６】 これにより、電子形態のドキュメントをコンテナとして表現することができる
。この場合、コンテナは、両面シートの形態の１つまたは複数のドキュメント部
を含む。

【０００７】 従って、本発明によって生成される電子ドキュメントは、物理的なドキュメン
トのキーとなる基本的な特徴を有している。すなわち、それは、両面シートから
なる３次元（または、少なくとも２次元を超える）のオブジェクトである。一般
に、電子ドキュメントは、ページの形態で表され、プリンタに提供される場合、
提供されるドキュメントが用紙上にどのように描写されるか（１枚の用紙の両面
にドキュメントが描写される場合を含む）を決定する情報を含むこととなる。し
かしながら、このような従来の構成では、両面ページをドキュメントの基本ユニ
ットとはしていない。すなわち、ドキュメントをページに分離することは、ドキ
ュメントに対して基本事項ではないが、適当な制御コードによって操作される２
次的な特徴であり、また、片面ではなく両面にドキュメントを印刷することは、
ドキュメントに対して基本事項ではないが、プリンタに対する適当な制御命令に
よって操作される。

【０００８】 また、このような３次元の電子ドキュメントは、ドキュメントの両面シートを
３次元でどのように操作することができるかを示す情報を含むことができる。こ
の操作は、例えば、ページが「回転する」ことができる場合にその中心となる軸
を定義することによる。この軸は、本の背等の垂直軸、またはリポータの剥取り
式ノートにあるような水平軸とすることができる。有益なことには、この３次元
情報は、プリンタに渡すことができるものである。そのため、例えば、ドキュメ
ントが本のようなプロパティを有するよう指示されている場合、ページを左手側
縁部に沿って取付けることによって、ドキュメントをこの３次元情報を含む形態
で再現することができる。

【０００９】 このような両面ページのサーフェイス（surface）が、他のそのようなページ とどのように相互に作用する（interact）ことができるかを示す「サーフェイス
プロパティ（surface property）」を有することもまた有利となり得る。特に有
用なプロパティは、取外し可能な接着というプロパティである。これにより、ド
キュメントは、再配置可能な自己接着性のメモ用紙という振舞いを有することが
できる。これは、目下、一般的なユーザの物理的デスクの重要な特徴である。

【００１０】 それは、有用であり、定義される両面ページのいくつかのプロパティに対して
、物理的ケースに更に直接的に類似している。このように定義する適当なプロパ
ティは、逆の面（またはシートの後ろ）にある情報に対する両面シートの不透明
度（不透明度の低いシートは、電子的なトレーシングペーパに類似している）お
よびシートのカラーである。より透明でない素性（antecedents）を有する他の プロパティは、物理的なオブジェクトにおいて価値はあるが、実際的に重要なプ
ロパティである。例えば、それは、ドキュメントを受信して描写するよう試みる
各デバイスに対して固定の、両面シートへの取付けに対する情報の位置のみでな
く、ドキュメントを受信するデバイスの能力に従って変化するかかる情報の位置
に対しても可能であることが望ましい。これら可能性の各々により、場合によっ
ては非常に有用となり得るが場合によっては望ましくない制限が与えられ、その
ため、所定の場合では、選択する可能性を設けることが有益である。

【００１１】 第２の態様において、本発明は、上述したようなフォーマットによる通信をサ
ポートするよう適応された情報処理機器を提供する。このような情報処理機器は
、カメラ、スキャナまたはパーソナルコンピュータ等のドキュメント作成側、ま
たはプリンタ、ファクシミリ機および同じくパーソナルコンピュータ等のドキュ
メント消費側となり得る。

【００１２】 本発明は、Hewlett-PackardのJetSendプロトコルでの使用の文脈において詳細
に説明する。しかしながら、後述するように、本発明はこのプロトコルのみでな
く、ドキュメントの電子的表現が２つの情報処理デバイス間で伝達可能であるあ
らゆる構成に対し適用が可能である。

【００１３】 本発明の特定の実施の形態について、添付図面を参照して例を用いて以下に説
明する。

【００１４】 本発明について、Hewlett-Packard CompanyのJetSendアーキテクチャに具体化
されている方法に関連して、詳細に説明する。このアーキテクチャの概説につい
ては、ワールドワイドウェブ（World Wide Web）においてhttp://www.jetsend.h
p.com/で提供されており、完全な説明は、ＨＰ JetSend通信技術プロトコル仕様
（HP JetSend Communications Technology Protocol Specification）において 提供されており、これはHewlett-Packard Companyから入手可能であって、この 参考により本明細書に包含されている。このアーキテクチャの重要な要素すべて
についての詳細な説明は、１９９８年４月１４日に出願された「Method and App
aratus for Device Interaction by Protocol」と題された米国特許出願第０９ ／０５９，８６７号および１９９８年４月１４日に出願された「Method and App
aratus for Device Interaction by Format」と題された米国特許出願第０９／ ０５９，９０９号において述べられており、これら出願は、参考によりその開示
内容が本明細書に包含されている。本発明では、一般的な用語でこのアーキテク
チャの基本的な要素について説明し、情報を伝達することができるフォーマット
、および特に両面ページの結合（アソシエーション（association））としてド キュメントを伝達するフォーマットについて、より詳細に説明する。

【００１５】 JetSendアーキテクチャの基本的な要素について、以下に説明する。以下の好 ましく必要な特徴に対する言及は、JetSendアーキテクチャの好ましく必要な特 徴に関し、本発明自体の好ましく必要な特徴に関するものではない。

【００１６】 JetSendアーキテクチャには、システムがどのように動作するかを定義する４ つの原則が基本である。これらは以下の通りである。

【００１７】 ピアツーピアインタラクション（interaction） ネットワーク転送によってこれが可能である場合、デバイスは、他のデバイス
に直接アドレス指定することができなければならない。デバイスは、２つの非Ｐ
Ｃデバイス間における情報交換を可能とするＰＣまたは他の仲介デバイスの存在
を必要とするものであってはならない。従って、ユーザは、最低限の構成によっ
て接続することができ、特別な（ad hoc）情報転送を実行することができる。

【００１８】 デバイスおよびデバイスタイプの独立性 いずれのデバイスにも、他のデバイスに関するデバイス特有の情報が予めプロ
グラムされることはない。デバイスは、出会う可能性のある特定のデバイスまた
はデバイスのセットに対し、異なるように振舞うことが要求されてはならない。
JetSendアーキテクチャにおいて、デバイスは、情報の送信またはステータスの 観測等、汎用的な動作を実行することができ、これら動作は、それら自体にいか
なるデバイス固有の態様をも有していない。これにより、２つのJetSend使用可 能デバイスが、デバイスまたはデバイスタイプに固有のドライバを用いることな
く相互に作用することが可能となる。

【００１９】 折衝（negotiation） デバイスは、送信側および受信側がサポートする最も高いレベルの共通の標準
（denominator）に対しデータ符号化の折衝を行う。各データタイプには、その データタイプを使用するすべての送信側および受信側がサポートしなければなら
ないデフォルト符号化が必要である。折衝を行う機能により、デバイスがハイエ
ンドデータタイプおよび独自の（proprietary）データタイプの実現が可能であ るということが保証される。一方で、デフォルト符号化により、意味のあるデー
タ交換が常に発生することが保証される。折衝は、フレキシブルであり拡張可能
でなければならない。

【００２０】 一貫性（consistency） デバイスが制御を交換しているか、データを転送しているか、ステータス情報
を交換しているか、または他の形式の情報を送信しているかに関わらず、同じプ
ロトコルが使用される。

【００２１】 図１０は、JetSendデバイスが動作する環境を示している。プリンタ３４２、 パーソナルコンピュータ３４３およびスキャナ３４４等のデバイス間に、ある種
のネットワーク３４１が存在する。これらデバイスの各々は、ある種のプロセッ
サ３４６、および当然ながらネットワーク３４１とのインタフェースを可能にす
る接続手段３４５を有していなければならない。この実施態様では、各デバイス
は、ある程度の処理能力を有している必要がある。それは、かかる能力が、JetS
endに不可欠な処理に対して必要であるためである。

【００２２】 JetSendにおけるデバイス間通信の基本は、サーフェイス（surface）インタラ
クションモデルである。サーフェイスは、デバイスの有する内部状態のある態様
を表現したものである。この表現は汎用的なものであって、デバイスが実行する
機能によって決定されるものではない。この文脈におけるサーフェイスは、物理
的オブジェクト（電話またはレンガ（brick）等）によって提供されるサーフェ イスに類似している。オブジェクトが動作する方法は、そのオブジェクトの「機
能的な」部分がそのサーフェイスにどのようにつながるかによって決定されるが
、サーフェイス自体は、機能に関係なく単純な汎用的手法によって記述すること
ができ、オブジェクトを他の物理的オブジェクトに世界中で接続可能とする媒体
を提供する。すなわち、物理的オブジェクト間の接続の特徴は、いかなるデバイ
ス機能にも依存しない。JetSendにおいて、サーフェイスは、情報交換の基本的 ユニットであり、イメージ、ドキュメント、ステータスメッセージ、およびデバ
イスラベル等は、すべて１つまたは複数のサーフェイスを使用して転送される。
サーフェイスは、多数のエレメント、すなわち、記述（description）、コンテ ント（内容（content））、プロパティおよびクラス等から構成されており、こ れらについては後に詳述する。

【００２３】 サーフェイスインタラクションモデルは、サーフェイスの生成、共有、修正お
よび削除のメカニズムを定義する。一定数の汎用動作のみが、JetSendインタラ クション・プロトコル（JetSend Interaction Protocol（ＪＩＰ））によって定
義されたメッセージを用いてサーフェイス上で実行することができる。なお、こ
れについては後述する。

【００２４】 サーフェイスのオリジナルコピーを、本明細書ではエクスプレッション（expr
ession）と呼ぶ。いずれのサーフェイスインタラクションにも、１つのエクスプ
レッションが含まれている。他のデバイスと共有する情報を有するデバイスは、
その情報を表現するために１つまたは複数のエクスプレッションを生成する。

【００２５】 サーフェイスエクスプレッションは、他のデバイス上でインプレスする（impr
ess）ことができる。これにより、そのサーフェイスのインプレッション（impre
ssion）が生成される。これはまた、サーフェイスの共有として知られている。 インプレッションは、他のデバイスのエクスプレッションのコピーであり、イン
プレッションがそれらの対応するエクスプレッションに対して最新であることを
保証するために、デバイス間で接続が保持される。一般に、２つのデバイスは所
定時間にいくつかのサーフェイスを共有する。サーフェイスは、ジョブのエレメ
ント、各デバイスからのステータス情報およびセキュリティ情報等を表す。

【００２６】 図１は、あるデバイス（デバイスＡ）のエクスプレッション１１が他のデバイ
ス（デバイスＢ）と共有され、それによって新たなインプレッション１２が生成
される状態を示している。同じエクスプレッションを、多数のデバイスにおいて
多数回インプレスすることができる。これにより、同じサーフェイスエクスプレ
ッションの多数のインプレッションが生成される。エクスプレッションが変更ま
たは削除されると、すべてのインプレッションに通知がなされる。本明細書では
、これを変更伝搬（change propagation）と呼ぶ。

【００２７】 変更伝搬により、ステータス情報等の興味ある動的特徴が、このアーキテクチ
ャにおけるデバイスに対し実現することができるようになる。例えば、ステータ
ス情報を有するデバイスは、多数の接続されたデバイス上にインプレスされてい
るステータスストリングを含むサーフェイスエクスプレッションを生成する。ス
テータスを有するデバイスは、その状態に依存するサーフェイスを変更する。ス
テータスサーフェイスのインプレッションを有するすべてのJetSendデバイスは 、現在のステータスと共に更新メッセージを受信する。この機能は、本アーキテ
クチャ内に組込まれており、デバイスの設計者がそれを使用することは任意であ
る。

【００２８】 実施の見地から、エクスプレッションは、所定のサーフェイスに関して保持さ
れている状態（そのネーム（name）、記述、コンテント、およびリモートデバイ
スにおいて作成されたインプレッションのセット）によって定義される。プロト
コルの見地から、エクスプレッションが、それについてのＪＩＰメッセージの交
換に使用されるサーフェイスハンドル（handle）によって定義されることについ
ては、後述する。

【００２９】 サーフェイスは、サーフェイスの記述、およびそのサーフェイスの中に含まれ
るコンテントを有している。区別（distinction）は、JetSendにおいて基本であ
り、本発明の態様において重要である。これは、それがコンテント折衝のメカニ
ズムを提供するためである。

【００３０】 サーフェイスの記述は、サーフェイスに関連する情報（この情報は、サーフェ
イスコンテントデータとして供給される）を他のデバイスと共有することができ
る可能な形態の全範囲を設定する。この記述は、データフォーマットの階層構造
から構成されており、各々がデータフォーマットの定義可能な態様（属性と言う
が、詳細は後述する）を表す多数のノードを有する木（tree）構造として表すこ
とができる。サーフェイスに関連する情報に対する特定のデータフォーマットは
、この木構造の根（root）ノードから終端ノード（木の葉（leaf）ノード）まで
のパス（path）である。このような特定のパスは、折衝のプロセスによって達成
される。本文脈において、折衝のプロセスは、他のデバイスとサーフェイス記述
またはサーフェイス記述の一部を共有するサーフェイス所有者を有している。そ
して、他のデバイスは、それが優先するオプションを選択し（一般に、そのよう
なオプションは、受信側デバイスが、選択肢が与えられた場合に使用可能な最も
有効な方法でそれ自体の機能を使用することができるように選択されるが、これ
はいかなる所定のデバイスの設計者に対しても本質的に重要なことである）、こ
のプロセスは、特定のパスおよび特定のデータフォーマットが選択されるまで継
続される。

【００３１】 サーフェイスコンテントは、そのサーフェイスに関連する情報であり、上述し
た折衝によって決定されるフォーマットで提供される。このコンテントデータは
、サーフェイス記述によって具体化されるデータフォーマット階層構造によって
示されるすべてのフォーマットで提供することができるが、所定のサーフェイス
インタラクションでは、一般に使用可能なフォーマットのうちの１つのフォーマ
ットのみで提供される。単一のインプレッションについて２つ以上のフォーマッ
トで情報が提供される可能性がある。これは、記憶装置から情報を検索する場合
に、有用性が立証され得る。この場合、例えば、最初にイメージが低解像度のサ
ムネイルとして与えられ、後に、イメージが望ましいものであると確認された後
、インプレッションを変更することなくフルサイズで高解像度のイメージが提供
される。しかしながら、このような状態において、さらなるコンテントに対する
要求が通常行われる。コンテントデータは、折衝が完了する前に存在する必要は
ない。データフォーマット階層構造における選択項目のいくつかまたはすべてに
ついて、データは、フォーマットの選択項目が知らされた後にのみ生成される。
代案として、選択項目によっては、コンテントデータが、データフォーマット階
層構造における特定のポイントを識別する記述と共に、折衝プロセスの一部とし
て直接提供されるようにしてもよい（そのため、このフォーマット選択には、コ
ンテントを提供するという別個のステップは必要でない）。これは、インライン
でのコンテントデータの提供と言われる。

【００３２】 上述したように、記述は、オリジナルのサーフェイスインプレッションと共に
送信されるが、一般的な場合では、コンテントは別個に要求される。例えば、ラ
スタイメージを表すサーフェイスは、イメージの色空間、解像度および圧縮に関
する選択項目と共にサーフェイス記述を定義する。インプレッションの受信側は
、使用可能な選択項目から受信側に対して好ましい符号化を指定して、実際のピ
クセルデータ（コンテント）を要求する。

【００３３】 また、サーフェイス記述は、他のサーフェイスに対する参照（reference）を 含むことができる。これらのサーフェイスは、サブサーフェイス（sub-surface ）（または子サーフェイス（child surface））として知られており、これらは 親サーフェイス（parent surface）の所有者から別々に要求されなければならな
い。各サブサーフェイスは、その親とは無関係の独自の記述およびコンテントを
有している。例えば、ドキュメントは、各々が別々のページを表す多数のサーフ
ェイスとして符号化（encode）することができる。ドキュメント自体は、これら
ページのサーフェイスに対する参照を含むサーフェイスとして表される。

【００３４】 本文脈では、ドキュメントは、単一のユニット内で結合もしくは保持されるペ
ージの集合体よりは広い意味を有している。本明細書では、ドキュメントは、あ
るデバイスが別のデバイスによる処理のために提供することができる形態で保持
される情報の任意の集合体である。JetSendの特定の文脈において、ドキュメン トは１つまたは複数のサーフェイスを有しており、各サーフェイスは、単一の親
子関係によって直接的に、あるいは親子関係または子親関係のチェーンを介して
間接的に他のすべてのサーフェイスに接続されている。

【００３５】 サーフェイスの参照またはサーフェイスネームは単純に、ＵＲＬのようなＡＳ
ＣＩＩストリングである。サーフェイスはすべて、そのネームによって識別され
、特定のクラスに属することができる。すべてのサーフェイスがクラスを有して
いる。クラスは、サーフェイスが使用される目的を示すプロパティである。本実
施態様では、各サーフェイスは、唯一のクラスを有していなければならない。サ
ーフェイスのクラスには、セルフサーフェイス（self-surface）、インサーフェ
イス（in-surface）、ステータスサーフェイス（status-surface）およびアドレ
スサーフェイス（address-surface）が含まれる。特定のクラスのサーフェイス を使用するために、特定のルールが存在し、あるいは考案されることができる。
クラスは、特に特定のポリシー（policy）の文脈において使用される。例えば、
ジョブポリシーは、サーフェイスの１つの特定のクラス、すなわちインサーフェ
イスを、ジョブ処理デバイスに対してジョブを提供する手段として用いる。プリ
ンタは、インサーフェイスを有しており、インサーフェイスにインプレスされて
いるサーフェイスは、新たなジョブとして扱われ印刷されることとなる。ＰＣ、
カメラ、または他の送信側デバイスは、このインサーフェイスに対してサーフェ
イスをインプレスすることができる。サーフェイスの特定のクラスが所定のポリ
シーの実行において基本的な役割を果たす場合、そのクラスのサーフェイスを、
そのポリシーに対する「周知サーフェイス（well-known surface）」と呼ぶ。

【００３６】 ポリシー、またはインタラクションポリシーは、特定のタスクを実行するため
に汎用サーフェイスインタラクションを使用するための規約のセットである。特
定のタスクにポリシーを使用する利点は、それによってすべての適合されたJetS
endデバイスが、その特定のタスクを実行するために他のデバイスと正常にかつ 予測可能な方法で相互に作用するよう、特定のタスクを実行するか、または別の
デバイスに実行するよう要求することができるということである。これによって
、例えば、１対のデバイスが、他のJetSendデバイスに対して開放的でない異な る方法で、サーフェイスの異なるクラスを用いてそのようなタスクを実行するよ
う適合されている、という可能性が排除されるわけではない。しかしながら、か
かるデバイスが、他のJetSendデバイスと共にこのタスクを実行することも可能 であるように、関連するJetSendポリシーを依然としてサポートすることが望ま しい。

【００３７】 ２つのデバイス間のサーフェイスインタラクションは、すべて以下のメッセー
ジを用いて行われる。 ・SurfaceRequestMsg 特定のネームのサーフェイス（およびクラス）を要求する。 ・SurfaceMsg サーフェイスをインプレスする（その記述を送信する）。 ・ContentRequestMsgおよびContentReplyMsg サーフェイスコンテントを転送する。 ・DescriptionRequestMsgおよび（DescriptionReplyMsg） 追加の記述を転送する。 ・SurfaceChangeMsg サーフェイスに対する変更を通知および要求する ・SurfaceReleaseMsg インプレッションとそのエクスプレッションとの間の接続を解除する。

【００３８】 これらのメッセージの使用については後述する。

【００３９】 「電子マテリアル（electronic material）」の省略表記であるＥ−マテリア ルは、情報によって用いられる形態であり、サーフェイスはそれを介して表現お
よび共有される。それは、記述とコンテントとを有している。記述は、フォーマ
ットの選択項目の階層構造を示しており、関連するコンテントデータは、このフ
ォーマットで供給することができる。コンテントは、サーフェイス自体に関連す
るデータである。記述は、データを提示することができる方法を示し、それに対
してコンテントは、情報そのものであって、それを送信するデバイスと受信する
デバイスとに適するように選択された形態で提示される。この選択の存在がＥ−
マテリアルの概念に対して重要であり、この選択がなされるメカニズムについて
は後述する。

【００４０】 サーフェイスインタラクションおよびＥ−マテリアルが、JetSendの中核をな す。この２つの概念は別々のものであるが、密接に関連している。サーフェイス
インタラクションは、Ｅ−マテリアルとして符号化された情報を交換するための
プロトコルである。JetSendデバイスが他のデータタイプと折衝し、デバイス独 立形式で情報を交換することが可能になるのは、サーフェイスとＥ−マテリアル
との組合せによる。

【００４１】 Ｅ−マテリアルは、ファイルフォーマットではない。Ｅ−マテリアルは、デバ
イスが交換するデータのフォーマットを定義するが、デバイスがどのようにして
そのデータを処理または格納するかを定義するものではない。Ｅ−マテリアルを
消費するデバイスが、そのデバイスに特定の方法でそれを実行する。例えば、プ
リンタ等の受信側デバイスは、Ｅ−マテリアルに対し、ＰＣ等の受信側デバイス
と異なる方法で処理を行う。ＰＣは、Ｅ−マテリアルをある種のファイルフォー
マットにし、プリンタは、それをＰＣＬまたはPostScript（商標）に変換し、最
終的にページのドットに変換する。同様に、Ｅ−マテリアルを生成するデバイス
も、そのデバイスに特有の方法で処理を行う。Ｅ−マテリアルタイプの最も基本
的な部分は、符号化である。符号化は、情報を提示することができる基本的な形
態のＥ−マテリアル表現である。「基本的な形態」の概念は、これまでに定義さ
れた各種の符号化によって表すことができる。

【００４２】 vTextは、書かれたテキストの形態での情報の提示に関する。ＡＳＣＩＩス トリング、または長方形の平面を埋める（フォントまたはスペーシング情報を持
たない）ユニコード（Unicode）テキストである。単純なテキスト符号化が主に ステータス情報に用いられるが、それは、ページをマーキングするためにも同様
に用いることができる。この記号セットは折衝可能である。

【００４３】 vImageは、グラフィカルイメージの形態での情報の提示に関する。この符号化
は、ラスタイメージに関しており、それに対し、色空間、ピクセル深度、解像度
、ピクセル符号化および圧縮等の特質を折衝する可能性がある。

【００４４】 vPlaneは、平面オブジェクトに関する情報の提示に対して表現する。その最も
一般的な形態は、１枚の用紙である。すなわち、実際には、vPlaneは、２面を有
する平面オブジェクトに関する。より詳細には、この符号化は、背景色を有する
２次元の長方形平面と、前面および背面の子エレメントの順序付けられた「層」
とを提供する。ページは、イメージまたはテキスト等の他の符号化を含む平面で
ある。JetSendのvPlane符号化は、JetSendにおける本発明の実施を示している。

【００４５】 vFileは、バイナリファイルの形態での情報の提示に関する。バイナリファイ ルは、アプリケーション固有のフォーマットのドキュメント、実行可能（execut
able）ドキュメント等のようなものを含む。ファイルネーム、マイム（mime）タ
イプおよびアイコンは、データに関連付けることが可能である。マイムタイプは
、折衝することが可能である。

【００４６】 vAssociationは、１つまたは複数のフォーマット（各々が独自の符号化によっ
て表される）で提示される情報のアセンブリの形態での情報の提示に関する。本
質的に、アソシエーション（association）は、子エレメントの順序付けされた シーケンスである。従来のドキュメントは、ページのアソシエーションとして表
現することができる。vAssociation符号化は、vPlane符号化と共に、JetSendア ーキテクチャ内の一連の両面ページを含むドキュメントの取扱いを示し、そのた
め本発明の特定の態様を表している。

【００４７】 更なる符号化を容易に考案することが可能であり、それらは、現存のJetSend 仕様では扱われていないデバイスタイプおよび機能に適するようになる。例えば
、より一般的に、情報を人間の音声またはサウンドの形態で表現するために、音
声またはサウンドの符号化を考案することができる。なお、本明細書において使
用される用語「符号化」は、基本的なフォーマットタイプを示すだけでなく、あ
らゆる特定のデータフォーマット階層構造（例えば、特定の折衝プロセスの終端
に到達するもの）をも示すために使用される。しかしながら、このような用語「
符号化」の使用は、文脈により容易に識別が可能である。

【００４８】 各符号化（vImage、vText等）に対し、単一のデフォルト符号化が定義される 。これにより、特定のタイプのデータを交換することができるすべてのデバイス
（例えば、ある形態、すなわちパーソナルコンピュータ、プリンタ、スキャナ（
マイクロフォンは含まれず）でイメージを表すことができるすべてのデバイス）
が、ある形態でデータを交換することができる、ということが保証される。イメ
ージの場合、本実施における基本的な符号化は、vImage.vGray.1.(300,300).vRL
Eであり、イメージ情報を使用することができるすべてのデバイスは、このフォ ーマットで情報を交換することができる。

【００４９】 一般に、データの交換用に使用可能なフォーマットとして、デフォルト符号化
より適切なフォーマットがある。それは、当然のことながら、最低限の機能セッ
トを有するデバイスによって使用することができなければならない。それにも関
わらず、一般により高性能のデバイスによって交換に使用可能な標準フォーマッ
トを有することが望ましい。かかる符号化は、ベース符号化（base encoding） と呼ばれる。ベース符号化は、すべてのデバイスによってサポートされるもので
はないが、交換に関して十分な機能を有するすべてのデバイスがベース符号化に
よるデータの交換をサポートすることが期待される。

【００５０】 属性は、Ｅ−マテリアル記述において定義される一片のＥ−マテリアルの特徴
である（または、折衝プロセスの完了後にその一片のＥ−マテリアルに対して定
義される）。本質的に、Ｅ−マテリアル記述において提供されるデータフォーマ
ット階層構造中の各ノードは、属性を表す。ノードと属性のこの等価性から、「
属性レベル」という概念が引出される。本質的に、属性レベルは、データフォー
マット階層構造の根ノードから等しい距離にあるすべてのノードによって共有さ
れる。属性は、Ｅ−マテリアルのコンテントに対して与えることができる特質、
およびその特質に対する選択または値を有する。これは、イメージが与えられる
サイズ、またはテキストが与えられる言語から、幾分か不明確な特質（エレメン
トが平面上に描写される順序等）まで及ぶことが可能であり、選択または値は、
それ自体がさらなる属性（選択または値を必要とする特質）を表すことが可能で
ある。特質自体は、属性ネーム（本明細書では、「属性」と短縮する場合もある
）によって表され、それに対して選択または値は、「属性値」（本明細書では、
値と短縮する場合もある）によって表される。従って、データフォーマット階層
構造のノードを、特定の特質、およびその特質に対する特定の選択または選択の
範囲を提供するものと考えることができる。属性ネームは、使用可能な値または
選択が予め定義されているキーワードである。そのため、所定のサーフェイス記
述において所定のキーワードに対して与えられたオプションは、これら予め定義
された選択項目から選択されたものでなければならない。異なる符号化に対して
は、いくつかの属性は必要となり、他のいくつかは任意となり、更に他のいくつ
かはまったく使用されない。

【００５１】 このように、Ｅ−マテリアルは、階層構造で構成された多数の属性と値とのペ
アを用いてサーフェイスの符号化選択項目を表現する。サーフェイス記述はすべ
て、属性vEncodingを含む（属性ネームおよび値ネームはすべて、接頭辞として 小文字のｖが付されている）。上述したように、これは、サーフェイスの符号化
全体を決定する。例えば、それがラスタイメージである場合、vEncodingはvImag
eとなる。また、このサーフェイスの所有者が２つ以上の符号化でそのコンテン トを提供することができる場合、それは選択項目のリストとすることも可能であ
る。

【００５２】 各符号化は、それに関連する多数の標準的な属性と値のペアを有している。例
えば、vImageは、解像度、ピクセルサイズ、色空間および圧縮等の属性を定義す
る。これらの属性のいくつかも、選択項目を含むことができる。実際には、サー
フェイスの所有者は、サーフェイス記述における属性の多くにオプションを付加
することにより、非常に複雑な選択項目を表現することができる。

【００５３】 属性は、階層構造で構成されており、それにより、先行する選択により所定の
属性に対して異なる選択が可能となる。例えば、あるサーフェイスに対しイメー
ジの符号化が提案された時、色空間としてＳＲＧＢが選択された場合は、ＪＰＥ
ＧまたはＪＰＥＧ−ＬＳ圧縮という選択が含まれることとなるが、モノクロが色
空間である場合は、ＲＬＥまたはＧｒｏｕｐ３ファックス圧縮が含まれることと
なる。

【００５４】 符号化の選択項目を列挙したサーフェイス記述は、記述テーブルと呼ばれる表
形式で書かれている。記述テーブルの例は、本明細書において後に示す。デバイ
スがサーフェイス記述を受信すると、そのサーフェイスに対しどの符号化が好ま
しいかに関する決定を行わなければならない。その決定が行われると、その選択
結果は、実際のコンテントデータに対する要求と共にサーフェイスの所有者に送
られる。

【００５５】 記述テーブルは、属性を３列、すなわちレベル、属性およびその値を列挙する
。レベルは、所定の属性が与えられる他の属性の値を指定するものである。例え
ば、同じ記述に列挙された先行する属性に対し「vImage.vSRGB.24」が選択され ている場合にのみ、値「（１５０、１５０）」を有する属性「vResolution」が 与えられる。

【００５６】 符号化はすべて、vLanguage属性に関して折衝することが可能である。いずれ のサーフェイスも、局所化の目的のために多数の言語で提供することができる。
各言語に対し、符号化に関する異なる選択が可能である。例えば、ある言語のテ
キストおよび別の言語のイメージを提供することも可能である。

【００５７】 ここで説明するJetSend仕様は、静的な２次元視覚情報をモデル化することに 焦点を当てている。従って、物理的な用紙上に含めることができる情報を表現す
るために有効な符号化が指定される。Ｅ−マテリアルは、このタイプの情報に限
定されず、原則としてデバイス間において交換が可能な情報の形態に適応可能な
新たな符号化を、本発明の文脈において容易に考案することができる。また、所
定のルールに従う限り独自の符号化を創案することも可能である。これにより、
デバイスのペアまたはグループ間での効果的な通信が可能となる。

【００５８】 図２は、２ページのドキュメントを示している。左側には視覚的表現２１、右
側にはそのサーフェイス表現が示されている。この場合、各々が独自の符号化を
有する７つのサーフェイスを用いて表現されている。長方形は、他のサーフェイ
スに対する参照を含むサーフェイスである。トップレベルサーフェイス２２は、
ドキュメントの２ページの各々を参照するアソシエーションである。各ページは
、平面符号化２３、２４として表されている。各平面は、そのページに関する情
報を表すサーフェイスに対する２つの参照を含む。第１の平面２３は、イメージ
サーフェイス２５およびテキストサーフェイス２６を指している。第２の平面２
４は、２つのイメージサーフェイス２７、２８を指している。各イメージサーフ
ェイスは、別々に折衝され、異なる符号化の提供（offering）を含む。

【００５９】 これは、本ドキュメントをサーフェイスおよびＥ−マテリアルを用いて表現す
ることができる１つの方法である。この場合、それは、ページ上で見ることがで
きるエレメント、すなわち３つのイメージとテキストセグメントとに細分化され
る。別の可能性として、各々がページ全体をカバーする１つの大きなイメージ領
域を有する２つの平面として情報を符号化するというものがある。その情報をど
のように符号化するかは、ドキュメントの所有者の設計の選択によって決まる。

【００６０】 上述したように、本アーキテクチャには、デフォルト符号化を提供するという
原則が組込まれている。各符号化に対し、すべてのJetSendデバイスがサポート する必要のある属性のデフォルトのセットがある。このデフォルト符号化により
、同じクラスの情報を交換するデバイスのいかなる組合せも通信が可能となると
いうことが保証される。また、それによって、将来的な互換性も保証される。す
なわち、上記デフォルト符号化をサポートする限り、新たなデバイスはより情報
処理能力のある符号化を実現することが可能となる。

【００６１】 すべてのデバイスが、アソシエーション符号化をサポートすることが要求され
る。これは、単に、他の符号化を有するサーフェイスに対するコンテナである。
また、静的な２次元情報を扱うすべてのデバイスが、平面符号化をサポートする
ことが要求される。

【００６２】 イメージングデバイスに対するデフォルト符号化は、３００×３００ｄｐｉ、
モノクロ、ＲＬＥ圧縮ラスタである。これは、すべてのJetSendイメージデバイ ス（プリンタ、スキャナ、コピー機、カメラ、ホワイトボード等）がこの符号化
の送信および／または受信が可能でなければならないことを意味する。そのよう
なデバイスに対し、テキスト符号化およびファイル符号化は任意である。データ
の他のクラスをサポートするデバイスが実現されているため、それらデータタイ
プに対するデフォルト符号化もまた導入される。これには、音声およびビデオの
ようなデータタイプが含まれる。デフォルトは、所定の符号化に対する最低限の
共通標準として企図されたものである。

【００６３】 更に上述したように、デフォルト符号化に加えて、任意ではあるが有利な特徴
としてベース符号化が提供される。これらは、より高い能力を有するデバイスに
対してより良い結果を保証する推奨されたより高レベルの符号化である。例えば
、カラーイメージングデバイスに対し、これらデバイスがデフォルト符号化に加
えてサポートすべきカラーイメージに対するベース符号化がある。デフォルト符
号化が同様に提供される限り、デバイスは追加の符号化を自由に提供することが
できる。そのデバイスは、その特定のデバイスタイプに最も適したベース符号化
を実現することにより、より優れたレベルの性能または品質を提供することがで
きる。

【００６４】 JetSendプロトコルは、デバイスタイプ、プラットフォームおよび転送には依 存しないように設計されている。JetSend機器（appliance）の基本的なコンポー
ネントの各々の概要について説明する。機器は、本明細書に亙って広く使用され
る用語であり、デバイスより更に特定の意味が与えられている。機器は、専用の
機能を有するデバイスであり、その専用の機能を実行するよう与えられるデータ
を実質的に独立して処理することができるものである。従って、例えばパーソナ
ルコンピュータの純粋な周辺機器よりもより広いユーティリティを有している。
一般に、機器は、再プログラミングが不可能であり、動作するために最低限の構
成のみが必要である。スキャナおよびプリンタ等のデバイスは、望ましくは、本
発明の本実施をサポートするよう適合された場合、機器として機能する。

【００６５】 JetSend機器を構成する機能の３つの主要な領域がある。すなわち、デバイス 内の転送、JetSendプロトコル自体およびデバイス特有コードである。図３は、J
etSendアーキテクチャのコンポーネントおよびそれらの互いの論理的関係を示し
ている。各コンポーネントの概要についてはこの後に述べる。各コンポーネント
の詳細については後述する。なお、図３は、実施の図ではない。プロトコル間の
関係を示すものであって、ソフトウェアコンポーネント間の関係を示すものでは
ない。実際の実施は、同様のコンポーネントを有することができ、または多数の
プロトコルの実施を１つのモジュールに結合することができる。

【００６６】 JetSendアーキテクチャは、転送に依存せずに適用することができる。JetSend
デバイスは、一意のアドレッシングを用いて任意の双方向転送３６を介して互い
に直接にアドレス指定することができる。転送は、信頼性を高くする必要がある
。従って、ＵＤＰ等の信頼性の低い転送形態では、その転送形態による送信をよ
り信頼性の高いものとするためにさらなるプロトコル層を追加しなければならな
い（ここでは、高信頼メッセージ転送プロトコル（Reliable Message Transport Protocol（ＲＭＴＰ））３７と呼ばれる更なるプロトコルが、この目的のため に使用されている）。可能な転送形態には、ＴＣＰ／ＩＰ、ＳＰＸ／ＩＰＸ、Ｉ
ｒＤＡ、ＩＥＥＥ１２８４、ＩＥＥＥ１３９４等が含まれる。デバイスは、１つ
または複数の転送形態を実現することができ、それによってそれら同じ転送形態
を用いて他のデバイスと通信することが可能となる。

【００６７】 JetSend機器間の通信は、図３から分かるように、多数層のプロトコルを用い て実行される。これらの層は、大抵のネットワーキングシステムと同様であり、
各プロトコル層が他のデバイスにおける同じ層と通信する。JetSendプロトコル を含む層は、インタラクションポリシー３５、インタラクションプロトコル３３
、セッションプロトコル３４およびＲＭＴＰプロトコル３７である。

【００６８】 インタラクションポリシーは、デバイスが従う各種の一般的なインタラクショ
ンのシーケンスを定義する。このインタラクションポリシーは、デバイス間のよ
り特定の情報交換を実現するために包括的なビルディングブロックとして使用さ
れる。以下に示すインタラクションポリシーが定義されており、以下、これらに
ついて説明する。 ・ジョブポリシー：送信側と受信側との間のドキュメントの送信方法。 ・セルフポリシー：ラベル、アイコン、パスワード等のデバイスに関する全体的
な情報の交換方法。 ・ステータスポリシー：デバイスおよびジョブに関するステータスの付与方法。
・アドレスポリシー：新たな宛先アドレスを有するデバイスのプログラム方法。

【００６９】 デバイスは、上記ポリシーのいずれをも実現する必要はないが、大抵のデバイ
スは、ジョブポリシーを実現する。JetSendアーキテクチャの範囲内で、通信の 一般的な振舞いを確立することが望ましい異なる領域へアドレス指定するために
更なるポリシーの開発が可能である。

【００７０】 インタラクションプロトコルは、セッションプロトコルを用いてサーフェイス
に関する情報を交換する。JetSendインタラクションプロトコルは、サーフェイ ス記述を要求および転送するメッセージ、サーフェイスに対するコンテントデー
タを転送するメッセージ、およびサーフェイスを更新するメッセージを含む。こ
れは、Ｅ−マテリアルと共に、デバイス間のデータタイプを折衝するメカニズム
を提供する。

【００７１】 セッションプロトコルは、２つのデバイス間のセッションおよびチャネルをセ
ットアップするためのメッセージを定義する。セッションは、２つのJetSendエ ンティティ間のデータ転送の確立および終了を管理する。これは、通信に対する
その文脈内の論理チャネルを生成することができる。これらすべてのインタラク
ションは、下のトランスポート層によっていずれの転送形態が提供されるかによ
って発生する。また、ＪＳＰは、JetSendデバイスと非JetSendデバイスとの間の
ゲートウェイにおいても用いられる。

【００７２】 チャネルがＵＤＰ等の信頼性の低い転送形態を使用する場合、ＲＭＴＰは、そ
のチャネルに対する高信頼性サービスを提供する。ＲＭＴＰは、信頼性の高い順
番付けされた引渡しプロトコルである。ＲＭＴＰは、特定の転送形態用のもので
はないが、その１つの例は、すべての転送スタックを介して同時に接続を保持す
ることができる。

【００７３】 デバイスコードとは、JetSendプロトコルを実際のデバイスに結付けるために 必要なロジックに対して使用される用語である。図３におけるデバイスコード３
１は、情報を生成または消費することができるすべてのデバイスにおいて存在す
ることが可能である。一般的な生成デバイスは、スキャナおよびＰＣアプリケー
ションである。一般的な消費側は、プリンタおよびＰＣビューワである。デバイ
スは、デバイス特有の情報／データのフォーマットとJetSendプロトコルによっ て使用されるＥ−マテリアルとの間で変換が可能でなければならない。

【００７４】 ＪＩＰによって行われる折衝は、データの特定のクラスに特有のものである。
各デバイスは、データ符号化に対して独自の優先権を有しており、そのため、異
なる属性に対して折衝し、異なる選択を行う。すべてのデバイスは、折衝、すな
わち、送信側が提案を行い、受信側がその好ましい符号化を選択して要求を行い
、送信側がその要求を満たすというプロセスのためにJetSendプロトコルを使用 する。デバイスコードは、JetSendプロトコルとデバイスの動作との間で相互作 用するコンポーネントの非常にデバイス特有の実施である。デバイスに対して実
現が残された機能には、以下のものがある。

【００７５】 ユーザインタフェースの実現および制御、 Ｅ−マテリアルの折衝および消費（優先権の順に、および入ってくるＥ−マテ
リアルの処理におけるＥ−マテリアル符号化を提供するという意味で）、 Ｅ−マテリアルの生成、 エラーの通知および回復。

【００７６】 JetSendセッションプロトコルは、ＴＣＰ／ＩＰ、ＩＰＸ／ＳＰＸ、ＩｒＤＡ 、ループバック等の多数のトランスポート層をサポートすることができる。いず
れの転送形態が使用可能であるかは、所定のデバイスの開発者によって決定され
る。JetSendデバイスにおける転送コードにより、転送の実施を互換性のあるも のにする必要がある。JetSend転送コードによる互換性のために実現しなければ ならない２つの特定のコード領域がある。これらは、プロトコルのセッション層
であり、信頼性の高いメッセージングシステムを提供するものである。

【００７７】 転送アーキテクチャは、デバイスがサポートするよう決定する転送形態と共に
JetSendセッションプロトコルを含む。ＴＣＰ／ＩＰを使用してJetSendを実現す
るデバイスは、信頼性の低いデータグラムサービスのためにJetSendセッション プロトコルおよびＲＭＴＰを実現しなければならない。

【００７８】 ここではJetSendで使用される転送プロトコルについては、これ以上詳細には 説明しないが、例えば、上に参照したhttp://www.jetsend.hp.com/および米国特
許出願第０９／０５９，８６７号および米国特許出願第０９／０５９，９０９号
において提供されており、参考によりその開示内容が本明細書に包含されている
。しかしながら、JetSendインタラクションプロトコル（ＪＩＰ）については、 デバイス間で交換される情報を決定するデバイス間のインタラクションのための
メカニズムを示すために説明する。ＪＩＰの基礎となり、本明細書では詳細には
説明しないプロトコルが、本質的に、デバイス間のＪＩＰメッセージの適当な交
換を可能とするためだけに必要である。

【００７９】 ＪＩＰに対し、サーフェイス交換の概念が基本となっている。その概念を描く
１つの方法では、「サーフェイス」を、１ブロックのモデル化したクレイ（clay
）のサーフェイスであるものと考える。このクレイのブロックは、その所有者に
よりあらゆる形状に成形することが可能である。観察者は、このオブジェクトの
サーフェイスをそのサーフェイスによって表されるものと見る。言換えれば、ク
レイの所有者は、そのブロックをある形状に成形し、その形状のサーフェイスは
、そのオブジェクトが何かを表す。

【００８０】 観察者が、別の、成形されていないクレイのブロックを有するものと仮定する
。クレイのオリジナルの成形されたブロックの所有者は、その成形されたブロッ
クをその観察者の成形されていないブロックのサーフェイスにインプレスするこ
とができる。このとき、この観察者は、それ自体のクレイブロックにインプレス
されたオリジナルの成形された形状の正確な複製を有している（厳密には、この
時点で、比喩が崩れる（break down）。すなわちサーフェイスの交換において、
観察者がオリジナルの正確な複製を有するものであって、反転または鏡像を有す
るものではない）。そのため、オリジナルのクレイのブロックの所有者（エクス
プレッシブ（expressive）デバイス）は、観察者のクレイのブロック（インプレ
ッシブ（impressive）デバイス）に対しオリジナルのサーフェイスのコピーをイ
ンプレスする。

【００８１】 ＪＩＰは、いくつもの数のデバイスが、サーフェイスと呼ばれそのサーフェイ
ス交換モデルに従って交換される情報を共有することができるようにする、少し
の数のメッセージから構成されている。いずれのインタラクションにおいても、
１つのデバイスがそのサーフェイスを有している。所有者のコピーは、サーフェ
イスのエクスプレッションと呼ばれ、所有者自身は、エクスプレッシブデバイス
として知られている。サーフェイスの他のコピーはすべて、インプレッションと
呼ばれ、それらを保持するデバイスは、インプレッシブデバイスと呼ばれる。Ｊ
ＩＰによって与えられるメッセージにより、エクスプレッシブデバイスは、エク
スプレッションを生成および破棄することができ、インプレッシブデバイスは、
それらが保持するインプレッションを破棄することができ、いずれのデバイスも
、オリジナルのサーフェイスエクスプレッションを修正することができる。

【００８２】 サーフェイス、エクスプレッションおよびインプレッション等の概念を実現す
るために、メッセージのリストが生成されている。すべての「サーフェイスイン
タラクション」は、これらのメッセージを使用することにより発生する。以下の
メッセージがインタラクションプロトコルを構成している。 ・SurfaceMsg（インプレス） ターゲットデバイス上にサーフェイスの新たなインプレッションを生成し、イ
ンプレッションに対する要求を拒絶するためにも使用される。 ・SurfaceDeleteMsg インプレッシブデバイスに対し、エクスプレッシブデバイスがオリジナルのエ
クスプレッションを削除したことを通知する。 ・SurfaceReleaseMsg（アンインプレス（Unimpress）） エクスプレッシブデバイスに対し、インプレッシブデバイスがインプレッショ
ンを削除したことを通知する。 ・SurfaceRequestMsg（サーフェイス要求） デバイスが指定されたサーフェイスのインプレッションを要求することができ
るようにする。 ・DescriptionRequestMsg（記述要求） デバイスが、それがインプレッションを有するサーフェイスに対する記述を要
求することができるようにする。 ・DescriptionReplyMsg（記述応答） 記述要求に応答してインプレッションに対する記述を送信する。 ・ContentRequestMsg（コンテント要求） インプレッシブデバイスがエクスプレッシブデバイスから、あるコンテントデ
ータを要求することができるようにする。 ・ContentReplyMsg（コンテントデータ） コンテント要求に応答して、エクスプレッシブデバイスからインプレッシブデ
バイスに、あるコンテントデータを送信する。コンテント要求に応答してこれら
メッセージのシーケンスがあり、このメッセージはまた、コンテント要求を拒絶
するためにも使用される。 ・SurfaceChangeMsg（変更） デバイスに、情報が変更されたことを通知する（すなわち、インプレッシブデ
バイスに変更を通知するエクスプレッシブデバイスにより、および、エクスプレ
ッションの変更を要求するインプレッシブデバイスにより、またこれら要求の拒
絶）。

【００８３】 サーフェイスは多数の属性を有している。それらは、ネーム、識別子、クラス
、プロパティのセット、記述、コンテントデータおよびバージョンである。ネー
ムは、ヌル（ＮＵＬＬ）終了ＡＳＣＩＩストリングである。識別子は、各サーフ
ェイスに割当てられており、ＪＩＰにおいて一意にそれを識別する。クラスは、
サーフェイスの目的を決定するために使用される。プロパティのセットは、エク
スプレッシブデバイスがどのＪＩＰメッセージに応答するかを制御する。記述は
、そのデータが入手できるフォーマットの記述、またはエクスプレッシブデバイ
スが提供しようとしているフォーマットの記述を含む。コンテントデータは、情
報自体の実際のバイトを含む。バージョンは、変更メカニズムによって使用され
、それによってエクスプレッシブデバイスおよびインプレッシブデバイスが、い
ずれのサーフェイスのバージョンに変更が関連しているかを知る。

【００８４】 一般的なインタラクションは、以下のように進められる。まず、エクスプレッ
シブデバイスとなる、転送する情報を有するデバイスが、エクスプレッションを
生成する。このために、ネームを生成し、一意の識別子を割当て、プロパティの
セットを生成し、記述を生成する必要がある。この時点でコンテントデータを生
成する必要はないが、サーフェイス記述に記述されているコンテントを生成する
ことができなければならない。次に、エクスプレッシブデバイスが、これら属性
を使用して、ターゲットデバイスまたはデバイスにSurfaceMsgを送信することに
よりこのサーフェイスのインプレッションを生成するよう試みる。なお、このよ
うなSurfaceMsgは、自発的に送信することができ、あるいは、別のデバイスから
受信した先行のSurfaceRequestMsgに応答して送信することができる。また、Sur
faceMsgを用いてインプレッションを生成するために、エクスプレッシブデバイ スは、エクスプレッションを「インプレス」する「ターゲットサーフェイス」を
有していなければならない。SurfaceMsgが先行のSurfaceReqestMsgに応答してい
る場合、ターゲットサーフェイス識別子を、SurfaceRequestMsgに見つけること ができる。しかしながら、エクスプレッシブデバイスが自発的なインプレッショ
ンを生成している場合、ターゲットサーフェイス識別子は、現存するインプレッ
ションの識別子であることが可能であり、この場合、エクスプレッションはすで
に存在していなければならない。あるいは、それは、「デフォルトターゲット」
識別子に設定されていてもよい。

【００８５】 デフォルトターゲット識別子は、「ワークサーフェイス（work surface）」と
呼ばれる場合がある。このようなデフォルトの存在は、ＪＩＰを適当に実現する
ために重要である。そうでなければ、エクスプレッシブデバイスがインプレッシ
ブデバイスに最初にメッセージを送信する時にブートストラップ問題が発生する
。すなわち、エクスプレッシブデバイスは、インプレッシブデバイス上のどこに
インプレッションを生成すべきかを知らず（この時点では知らない）、インプレ
ッシブデバイスは、エクスプレッシブデバイスがインプレッションの生成を希望
しているということに気が付いていないため、エクスプレッシブデバイスに（あ
る種の全体的なメッセージを送信することなく）都合良く知らせることができな
い。解決法は、すべてのデバイスが、デフォルトまたはデフォルトターゲット識
別子を有するワークサーフェイスのインプレッションを受入れるということであ
る（本実施では、デフォルトターゲット識別子は１に設定されている）。これに
より、いずれのエクスプレッシブデバイスも、ターゲット識別子フィールドを１
に設定することにより、インプレッシブデバイス上にインプレッションを生成す
ることができる。そして、インプレッシブデバイスは、（例えば、新たなターゲ
ットサーフェイスに対してインプレッションを要求するSurfaceRequestMsgメッ セージにより）エクスプレッシブデバイスと通信することができるようになる。

【００８６】 ＪＩＰのメッセージの使用を示す一連の例を、図４ａ乃至図４ｆを参照して以
下に示す。図４ａは、本質的に図１と同様であるが、便宜上図４ａとして与えら
れている。

【００８７】 例１：図４ａ エクスプレッシブデバイスが、要求されていないインプレッションの生成を希
望する。まず、サーフェイスエクスプレッション１２１が生成される。そして、
これは、SurfaceMsgを用いてインプレッシブデバイス上にインプレスされ、その
サーフェイスのインプレッション１２２がそのインプレッシブデバイス上に存在
する。

【００８８】 例２：図４ｂ エクスプレッシブデバイスが、他の機器と交換することを希望する情報に対し
、サーフェイスエクスプレッションを生成する。この例では、要求される前にエ
クスプレッションがすでに存在しているが、これは、必ずしも問題ではない（例
えば、子サーフェイスは、実際に要求されるまでは生成されない場合がある）。
そして、エクスプレッシブデバイスは、インプレッシブデバイスからSurfaceReq
uestMsgのサーフェイスインプレッションに対する要求を受信し、応答して、Sur
faceMsgを有するインプレッションを生成しようと試みる。最終的な結果は、例 １と同様であり、インプレッシブデバイスにインプレッション１２２が生成され
る。

【００８９】 例３：図４ｃ エクスプレッシブデバイスが、例１と同様に、サーフェイスエクスプレッショ
ンを生成し、インプレッシブデバイス上に要求されていないインプレッションを
生成しようと試みる。インプレッション１２２が生成されるが、その後即時に、
SurfaceReleaseMsgによりインプレッシブデバイスからエクスプレッシブデバイ スに解放される（１２９）。最終的な状態として、エクスプレッシブデバイスに
サーフェイスのエクスプレッション１２１が存在するが、インプレッシブデバイ
スにはサーフェイスのインプレッションが存在しない。

【００９０】 例４：図４ｄ 例１と同様に、要求されていないインプレッション１２２がインプレッシブデ
バイス上にうまくインプレスされる。そして、インプレッシブデバイスは、イン
プレッション１２２の記述を用いて、次にとるべき動作を決定することができる
。場合によっては、この例におけるそれのように、オリジナルのSurfaceMsgに含
まれるサーフェイス記述は完全なものではない。そして、インプレッシブデバイ
スは、DescriptionRequestMsgメッセージを用いてエクスプレッシブデバイスか らの更なる情報を要求することができる。エクスプレッシブデバイスは、更なる
サーフェイス記述を含むDescriptionReplyMsgを用いて、DescriptonReqestMsgに
応答する。

【００９１】 例５：図４ｅ サーフェイス記述は、トップレベルサーフェイスのサブサーフェイスまたは子
サーフェイスへの参照を含むことができる（例えば、アソシエーションとして符
号化されたＥ−マテリアルは、実際には常に子サーフェイスを含むこととなる）
。例５は、子サーフェイスＡ１を有するサーフェイスＡに関する。各サーフェイ
スのエクスプレッション１２１、１２３が、エクスプレッシブデバイスにおいて
与えられている（代案として、この時点では、サーフェイスＡのエクスプレッシ
ョン１２１のみが与えられる）。そして、SurfaceMsgを用いて、サーフェイスＡ
がインプレッシブデバイスにインプレスされる。次いで、インプレッシブデバイ
スが、SurfaceRequestMsgを用いて、エクスプレッシブデバイスからの子サーフ ェイスＡ１のインプレッションを要求する。この要求は、拒絶または受諾される
ことができ、後者の場合、エクスプレッシブデバイスは更なるSurfaceMsgを送信
する（かかるエクスプレッションが既に存在しない場合は、子サーフェイスＡ１
のエクスプレッションが最初に生成された後）。最終的な状態として、エクスプ
レッシブデバイスには、サーフェイスＡのエクスプレッション１２１および子サ
ーフェイスＡ１のエクスプレッション１２３が存在し、インプレッシブデバイス
には、サーフェイスＡおよび子サーフェイスＡ１の対応するインプレッション１
２２、１２４が存在する。

【００９２】 例６：図４ｆ インプレッシブデバイスにおいてサーフェイスのインプレッションが与えられ
ると、そのインプレッシブデバイスは、ContentRequestMsgによりコンテントを 要求することができる。エクスプレッシブデバイスは、ContentRequestMsgを受 信すると、その要求を拒絶するか、または要求されたフォーマットでコンテント
１２５を提供することができる。このコンテントを、ContentReplyMsgメッセー ジ（この場合のように）として、一連のContentReplyMsgメッセージとして、あ るいはストリーム等の別の手段により、送信することができる。

【００９３】 ＪＩＰは、JetSendセッションプロトコル（ＪＳＰ）により実行する。ＪＳＰ は、２つのデバイス間の、セッションの生成および削除と共にセッションが使用
不可能となった時の判断を含むセッションのすべての態様を管理する。また、Ｊ
ＳＰは、基本的なアドレッシングに対するアクセス、高信頼メッセージ転送プロ
トコルおよびＪＩＰによって使用される他のすべての転送プロトコルを提供する
。

【００９４】 機器は、受動的にセッションを開始することができ、または別の機器のセッシ
ョンを能動的に開始することもできる。ＪＩＰは、受動的にセッションを開始す
るために、まずＪＳＰに対して特定の転送形態においてセッションをリッスン（
listen）（聞き耳を立てる）するよう命令しなければならない。ＪＳＰがその転
送形態でリッスンしていると、別の機器が、ＪＳＰに対してその特定の転送形態
においてそのデバイスを呼出すよう命令することにより、セッションを能動的に
開始することができる。接続が確立されると、リモートＪＳＰおよびローカルＪ
ＳＰは、ＪＳＰのサポートされたバージョンに対して折衝し、その時点で両ＪＩ
Ｐには、セッションが確立したことが通知されなければならない。ＪＳＰは、Ｊ
ＩＰに対し、このセッションにマップするセッションハンドルを供給する。これ
らセッションハンドルは、ＪＩＰがセッションの終了を希望する場合等、ＪＩＰ
がセッションへの参照を特に必要とする時はいつでも使用されなければならない
。

【００９５】 ＪＩＰを実現することは潜在的に、所定のセッションに関係するサーフェイス
についての非常に多くの状態を保持することになる。環境によっては、ＪＳＰは
、デバイスがまだ未処理の（outstanding）インプレッション、要求およびコン テントデータを有している間にセッションを終了する場合もある。これは、例え
ば、デバイスの電源が切れた時、またはＪＳＰにセッションを削除させるネット
ワーク故障が発生した時に起こる可能性がある。ＪＩＰは、予期せずにセッショ
ンの終了が通知された時、セッションの文脈においてのみ意味を有する人工物（
artefact）が残らないように、そのセッションに関連するそのローカル状態をク
リーンアップ（clean up）しなければならない。例えば、ローカルＪＩＰは、そ
の未処理のインプレッションが解放され、それによってその内部状態をクリーン
アップしなければならなくなることを伝えるSurfaceReleaseMsgを受取らない。 未処理のContentRequestMsg、DescriptionRequestMsg等についても同様である。

【００９６】 ＪＩＰは、ＪＳＰによって与えられ保持されるチャネルを介してそのメッセー
ジを交換する。これらメッセージチャネルは、信頼性が高く順序付けられていな
ければならない。ＪＳＰの実現により、ストリームチャネル等の各種の他のタイ
プのチャネルを提供することができる。

【００９７】 セッションが２つの機器間で確立されると、メッセージチャネルを生成するこ
とができる。セッションが確立されると、最初のメッセージチャネルをオープン
するよう要求するのは、能動的なＪＩＰの責任である。従って、チャネルをリッ
スンするのは受動的なＪＩＰの責任である。このため、接続が確立されるとすぐ
、受動的なＪＩＰはＪＳＰに対しチャネルをリッスンするよう命令するというこ
とが考えられる。チャネルの呼出し、クローズおよびリッスンの機能は、ＪＳＰ
によって与えられる。なお、チャネルをオープンするという能動的な呼出しは、
ＪＳＰがリモートデバイスが受動的にチャネルをリッスンしているということを
通知するまでは、ＪＩＰによって出されるべきではない。

【００９８】 ＪＳＰは、メッセージチャネルに対して折衝しそれをオープンすると、このチ
ャネルに対するハンドルをＪＩＰに供給する。そして、ＪＩＰは、このチャネル
を用いてメッセージを送受信することができる。このチャネルは、ネットワーク
故障またはクローズするという明示的な呼出しによってクローズされるまで有効
である。セッションが確立されメッセージチャネルがオープンすると、接続のい
ずれかの側が、追加のチャネルをオープンするよう要求することができる。これ
ら追加のチャネルは、ＪＳＰによってサポートされる伝送の転送形態においてオ
ープンすることができる。

【００９９】 ＪＩＰは、メッセージチャネルをまたがってコンテントデータを送信すること
に加えて、コンテントデータが、２つの機器によってサポートされる特定のチャ
ネルをまたがって送信されることを可能にすることができる。ContentRequestMs
gおよびContentReplyMsgは両方とも、コンテントデータが流れるチャネルの選択
に関連するフィールドを有している。

【０１００】 ここで、JetSendインタラクションプロトコルの各メッセージについて、詳細 に説明する。

【０１０１】 SurfaceMsg（インプレス） このメッセージは、３つの状況において使用される。第１に、エクスプレッシ
ブデバイスから別のデバイスへのサーフェイスの転送を起動する。第２に、別の
デバイスからのSurfaceRequestMsgへの応答として使用される。第３に、エクス プレッシブデバイスからのSurfaceMsgを拒絶するために使用される。どの解釈を
用いるべきかを指示するステータスフィールドが設定されている。

【０１０２】 このメッセージが、サーフェイス転送を起動するためもしくはサーフェイス要
求への応答として使用される場合、送信側デバイスは、そのサーフェイステーブ
ルにエントリを生成し、それによってインプレッシブデバイスに対し、あらゆる
変更を通知することができる。

【０１０３】 メッセージを受信すると、宛先はそのインプレッションの受諾を選択した場合
、そのインプレッションをエクスプレッションに関連付けるサーフェイステーブ
ルにエントリを生成する。これにより、その後エクスプレッシブデバイスに対し
、それがサーフェイスに変更を要求することを望んでいる時、またはそれを終了
した時を通知することができる。宛先は、インプレッションの受諾を選択しなか
った場合、それを拒絶するという解放メッセージを送り返し、テーブルエントリ
を生成すべきでない。そして、その「インプレッション」に関連する後続のメッ
セージは、無視されるべきである。

【０１０４】 送信側デバイスは、インプレッションに対する解放メッセージを受信すると、
そのテーブルから、そのインプレッションに関連するエントリを削除すべきであ
る。これにより、インプレッションを解放したデバイスがそのインプレッション
に関連するいかなるメッセージも受信しなくなることが保証される。

【０１０５】 インプレッションの送信とそれを拒絶する解放メッセージの受信との間には、
短い期間がある。この期間中、エクスプレッシブデバイスは、そのインプレッシ
ョンが存在するとみなす可能性がある。その問題は受信端で解決されることとな
るため、これは、いかなる実際的な問題も生じさせることはない。すなわち「イ
ンプレッシブデバイス」は、受入れなかったインプレッションもしくは、もはや
有していないインプレッションに関連するメッセージを無視することが必要であ
る。

【０１０６】 SurfaceDeleteMsg（削除） このメッセージは、エクスプレッシブデバイスにより、エクスプレッションが
削除されたことをインプレッシブデバイスに通知するために使用される。エクス
プレッシブデバイスは、エクスプレッションを削除すると、インプレッションを
保持するすべてのインプレッションデバイスに対してその削除について通知しな
ければならない。それはまた、そのエクスプレッションおよびそのすべてのイン
プレッションに対するエントリを、そのサーフェイステーブルから削除するべき
である。それは、そのエクスプレッションに関連するすべての後続メッセージま
たはそのインプレッションのすべてを無視しなければならない。

【０１０７】 インプレッシブデバイスは、削除メッセージを受信すると、その削除されたサ
ーフェイスのインプレッションに関連するすべてのエントリをそのサーフェイス
テーブルから削除するべきである。それはもはや、これらインプレッションに関
連するいかなるメッセージも生成すべきではない。

【０１０８】 エクスプレッシブデバイスがこのメッセージを出してからインプレッシブデバ
イスがそのメッセージを受信してそのサーフェイステーブルからインプレッショ
ンを削除するまでの間には、短い期間がある。従って、インプレッシブデバイス
は、この期間中にそのエクスプレッションに関連するメッセージを送信する可能
性があるが、エクスプレッシブデバイスは削除したエクスプレッションに関連す
るいかなるメッセージも無視することとなるため、実際的な問題は結果として生
じない。

【０１０９】 SurfaceReleaseMsg（アンインプレス） このメッセージは、インプレッシブデバイスにより、エクスプレッシブデバイ
スに対してインプレッションがアンインプレスされたことを通知するために使用
される。インプレッシブデバイスは、インプレッションをもはや要求しなくなる
と、そのサーフェイステーブルからそれを削除し、エクスプレッシブデバイスに
SurfaceReleaseMsgメッセージを送信する。そして、インプレッシブデバイスは 、その削除したインプレッションに関連するすべてのメッセージを無視しなけれ
ばならない。デバイスが同じサーフェイスの多数のインプレッションを有するこ
とは可能である。この場合、インプレッシブデバイスは、特にそのアンインプレ
スされたインプレッションに関連するメッセージのみを無視することとなる。

【０１１０】 エクスプレッシブメッセージは、そのようなメッセージを受信すると、そのサ
ーフェイステーブルからその特定のインプレッションに関連するエントリを削除
するべきである。それは、関連したインプレッシブデバイスに対しそのインプレ
ッションに関連するすべてのメッセージをもはや送信すべきではない。

【０１１１】 インプレッシブデバイスがこのメッセージを出してからエクスプレッシブデバ
イスがそれを受信してそのサーフェイステーブルからエントリを削除するまでの
間には短い期間がある。従って、エクスプレッシブデバイスは、この期間中にそ
のインプレッションに関連するメッセージを送信する可能性があるが、インプレ
ッシブデバイスがアンインプレスしたエクスプレッションに関連するいかなるメ
ッセージも無視することとなるため、実際的な問題は結果として生じない。

【０１１２】 SurfaceRequestMsg（サーフェイス要求） このメッセージは、デバイスにより、別のデバイスからインプレッションを要
求するために使用される。このメッセージは、あるデバイスに対し要求側にイン
プレッションを生成するよう要求する。そのネームは、リモートデバイスにおい
て有効なサーフェイスネームである場合とない場合とがある。そのネームが有効
である場合、リモートデバイスは、要求側にインプレッションを生成すべきであ
り、そのネームが有効でない場合、要求は拒絶されるべきである。ターゲットサ
ーフェイス識別子は、リモートデバイスがインプレッションを有するエクスプレ
ッションに対し有効な識別子でなければならない。そうでなければ、要求は拒絶
されることとなる。

【０１１３】 エクスプレッシブデバイスは、サーフェイス要求を受信すると、必要な場合、
要求されたサーフェイスを生成し、そのインプレスメッセージを用いて要求側デ
バイスにそれをインプレスするべきである。代案として、要求が無効である場合
、エクスプレッシブデバイスはその要求を拒絶すべきである。インプレスまたは
拒絶メッセージ中の要求識別子は、オリジナルの要求メッセージにおける要求識
別子と同じでなければならない。

【０１１４】 DescriptionRequestMsg（記述要求） このメッセージは、インプレッシブデバイスにより、そのデバイスがインプレ
ッションを有するサーフェイスに対する記述を要求するために使用される。イン
プレッション識別子は、要求側デバイスによって保持される有効なインプレッシ
ョンでなければならない。エクスプレッシブデバイスは、更なる記述に対する要
求を受信した時、記述応答を使用してその要求された記述を返すべきである。記
述要求は拒絶されない場合があるが、その結果としての応答はデータを含まない
可能性がある。

【０１１５】 DescriptionReplyMsg（記述応答） このメッセージは、DescriptionRequestMsgメッセージに応答してサーフェイ スに対する記述を返すために使用される。不適切な要求の結果、その特定の要求
に対してそれ以上の記述が無いということを示し、まったくデータを含むべきで
はない。サーフェイスのインプレッションを提供するデバイスが、そのサーフェ
イスの完全な記述を提供するよう準備されなければならないため、記述要求を「
拒絶する」可能性は無い。記述応答は、それが応答する記述要求からの要求識別
子を含まなければならない。

【０１１６】 ContentRequestMsg（コンテント要求） このメッセージは、インプレッシブデバイスにより、エクスプレッシブデバイ
スからのあるコンテントデータを要求するために使用される。インプレッション
識別子は、要求側デバイスによって保持される有効なインプレッションでなけれ
ばならない。

【０１１７】 送信側デバイスは、コンテントデータに対しストリーム接続を介して交換され
るよう要求することができる。デバイスは、そのようなコンテント要求を受信す
ると、要求された場合に新たなストリームを生成し、その後そのストリームでコ
ンテントを返送すべきである。受信側デバイスは、ストリームをサポートしてい
ない場合、そのコンテントを一連のコンテント応答メッセージとして返送するこ
とに代わりとして戻ることができる。従って、要求側デバイスは、ストリームを
介する転送を要求すると、ストリームを介するかまたは一連のコンテント応答メ
ッセージとして、そのコンテントを受信するよう準備されなければならない。

【０１１８】 ContentReplyMsg（コンテントデータ） このメッセージは、エクスプレッシブデバイスにより、あるコンテントデータ
をインプレッシブデバイスに送信するために使用される。単一のコンテント要求
に応答してコンテントデータメッセージのシーケンスが存在する。このメッセー
ジはまた、コンテントデータに対する要求を拒絶するためにも用いられる。

【０１１９】 コンテント提供側は、ストリームによってデータを提供している場合、ストリ
ーム識別子に対してストリームフィールドを設定し、そのコンテント長およびデ
ータを空のままにする。コンテント提供側は、ストリームをサポートしておらず
、あるいはこの目的でストリームを使用することができない場合、ストリーム識
別子を０に設定し、そのコンテントデータを一連のコンテント応答メッセージと
して送信する。この場合、コンテント長およびデータを用いて、そのメッセージ
のコンテントが送信される。

【０１２０】 一般に、ContentReplyMsgは、コンテント提供側がもはや内部的な理由のため にその要求を満たすことが出来ない場合、あるいはその要求が無効である場合に
、コンテント要求を拒絶するためにのみ使用される。

【０１２１】 すべての場合において、応答における要求識別子は、オリジナルの要求に含ま
れる要求識別子に設定されなければならない。

【０１２２】 デバイスは、コンテント応答を受信すると、まず、その応答が拒絶であるか否
かを判断しなければならない。拒絶である場合、デバイスは、その次の動作に関
する決定を行わなければならない。その応答が拒絶でない場合、デバイスは、そ
のコンテントがストリームによって供給されているか否かを判断しなければなら
ない。そのコンテントがストリームによって供給されている場合、それはそこか
ら読出されるべきであるが、そうでない場合は、そのコンテントは、この応答お
よび同じ要求識別子を有する後続の応答から読出されるべきである（転送が順序
付けられているため、かかる応答は次々に行われ、そのステータスフィールドは
、その一連における最後の応答を識別することとなる）。

【０１２３】 SurfaceChangeMsg（変更） このメッセージは、３つの目的のために使用される。第１に、エクスプレッシ
ブデバイスによりインプレッシブデバイスに対しサーフェイスの変更を通知する
ことであり、第２に、インプレッシブデバイスにより、エクスプレッションに変
更を要求することであり、第３に、インプレッシブデバイスに対し、エクスプレ
ッションを変更するという要求が失敗したことを通知することである。

【０１２４】 エクスプレッシブデバイスは、そのエクスプレッションのうちの１つに対し変
更を行うと、すべてのインプレッシブデバイスに対しその変更を通知しなければ
ならない。それは、これを、そのサーフェイステーブルにおいてインプレッショ
ンを探索し、各インプレッシブデバイスに変更メッセージを送信することによっ
て行う。デバイスが多数のインプレッションを有している場合、変更メッセージ
は各インプレッションについて送信される必要はない。インプレッシブデバイス
は、エクスプレッションとインプレッションとの間のリンクを保持している。

【０１２５】 インプレッシブデバイスは、変更メッセージを受信すると、変更されたエクス
プレッションのそのインプレッション各々において変更を実行する必要がある。
場合によっては、その変更メッセージは変更自体を含むが、そのメッセージが通
知のみを含みインプレッシブデバイスがその変更されたサーフェイスのためにコ
ンテントを再フェッチしなければならない場合もある。エクスプレッシブデバイ
スは、各インプレッシブデバイスによって必要とされるコンテントの符号化を知
っている場合、エクスプレシッブデバイスは、各々が関連したインプレッシブデ
バイスによって必要とされる形態でコンテントを含む別々の変更メッセージを提
供するよう構成することができる。

【０１２６】 インプレッシブデバイスは、そのインプレッションのうちの１つを変更するこ
とを希望する場合、変更メッセージを用いてその変更に対する要求をエクスプレ
ッシブデバイスに送信しなければならない。インプレッシブデバイスは、そのメ
ッセージ内に、要求された変更が与えられるエクスプレッションのバージョンを
含まなければならない。

【０１２７】 エクスプレッシブデバイスは、変更要求メッセージを受信すると、その変更を
受諾するか拒絶するかを決定しなければならない。この決定は、要求のバージョ
ンおよび特徴に基づいて行うことができる。エクスプレッシブデバイスは、その
変更が受諾されるかまたは拒絶されるかについて、適当なステータスセットを有
する変更メッセージを介して要求側に通知する。エクスプレッシブデバイスはま
た、上述したように、すべてのインプレッシブデバイスに対し変更メッセージを
用いて受諾した変更を通知する。

【０１２８】 従って、正常に変更要求を出したインプレッシブデバイスは、その変更の２つ
の通知を受信する。一方は、変更受諾（特にそれに送信される）であり、他方は
、変更通知であって、そのエクスプレッションのインプレッションを有するすべ
てのデバイスに送信される。これらのメッセージは、要求識別子またはバージョ
ン情報からの同じ変更に関連するものとして識別されることができる。

【０１２９】 ここで、Ｅ−マテリアルの特徴およびフォーマットについて、異なるドキュメ
ントタイプに対するその使用例と共に説明する。

【０１３０】 上述したように、Ｅ−マテリアルは、サーフェイスが表現される形態である。
Ｅ−マテリアルは、記述とコンテントとを含む。記述は、JetSendによってコン テントの交換を折衝するために使用される。記述は、サーフェイスの属性を示す
。これらの属性は概して、多数の属性レベルを包含する選択の階層構造を形成す
る。これらの属性は、どのように情報を送信することができるかを示し、コンテ
ント自体は、転送される感知可能な情報である。

【０１３１】 機器間でのサーフェイスの交換を正常に行うためには、サーフェイスを記述す
る各属性レベルが識別され処理されることが必要である。機器間のこれらレベル
を識別し処理するプロセスは、折衝と呼ばれる。完全なサーフェイス記述が折衝
されると、そのサーフェイスのコンテントが交換される。

【０１３２】 ２つのJetSend機器間のサーフェイスの交換には、ＪＩＰで定義された時にサ ーフェイスインタラクションメッセージが含まれる。サーフェイス記述は、記述
要求および記述応答を用いて完成される。サーフェイスコンテントの交換は、コ
ンテント要求およびコンテント応答を用いて完成される。制限された環境下で、
サーフェイス記述にサーフェイスコンテントが含まれる場合がある。これは、イ
ンラインコンテントと呼ばれる。インラインコンテントおよび小さな記述により
、交換には単一のメッセージのみを必要とすることができる。更に一般に、いく
つかのメッセージが交換される。

【０１３３】 Ｅ−マテリアルは、Ｅ−マテリアルブロックの形態で与えられる。かかるブロ
ックのためのバイトフォーマットについて、上述したドキュメントにおいて説明
されているが、１つのレベルでは、Ｅ−マテリアルブロックは、第１列に属性ネ
ームを有し第２列に属性値を有する２列の表において表すことができる。属性ネ
ームは、vResolutionまたはvCompression等の単一の特定のキーワードである。 属性値は、（３００、３００）ピクセル／インチまたはvRLE（ランレングス符号
化）等の属性に関連する１つまたは複数の値である。属性値は、値のリストとし
て指定されると、値フィールドにおいてスペースで分割された（space-separate
d）リストとして現れる。

【０１３４】 Ｅ−マテリアル・ブロックに現れる属性と値のペアは、JetSendサーフェイス のある部分に対して適用可能である。これら属性と値のペアは、サーフェイス全
体またはサーフェイスの特定部分に対して適用することができる。すべての属性
およびいくつかの値は、予め定義されたキーワードの制限されたセットから引出
される。これらは、本明細書において、vEncoding等の「v」接頭辞によって示さ
れている。いくつかの値は、データタイプのセットから引出される。これらは、
本明細書において、emListType等の「em」接頭辞によって示される。本明細書で
は、JetSendサーフェイスの文法のような構造の説明を簡略化するよう定義され た多数の表現タイプがある。これらは、概して値フィールドにおける適当な識別
子によって示される。

【０１３５】 いくつかの属性が、選択を提供する値のセットに関連付けられている。各値の
セットは、選択リストと呼ばれる。選択リストは、２列の表の値の列においてス
ペースで分割されたリストとして現れる。例えば、vResolution属性は、（３０ ０、３００）ピクセル／インチまたは（１５０、１５０）ピクセル／インチ等の
値を含む選択リストを有する。折衝プロセス中に、各属性は、その選択リストか
ら１つの値を取出す。各値の選択が、サーフェイス記述の各属性レベルの識別お
よび処理に寄与する。表１に示すＥ−マテリアルブロックにおいて、属性vEncod
ing、vColorSpace、vPixelDepth、vResolutionおよびvCompressionは、選択リス
トを値として利用する。属性vSizeはそうではない。この実施において便宜上、 列挙することができる属性データは１つの値のみを有する場合であってもリスト
として符号化されなければならない、という規則が決められている。

【０１３６】 それは、属性「vEncoding=vText」が１つのエレメントすなわちvTextを有する
リストとして符号化されなければならないということを意味する。これは、属性
データの解釈をわずかに容易にするが、その構成をわずかに困難にする。

【０１３７】

【表１】

【０１３８】 表１：Ｅ−マテリアルブロック例。

【０１３９】 レベルが識別され処理されるに従い、選択リストを用いる属性および選択され
た値は、Ｅ−マテリアルブロックに列挙される。選択リストを用いない属性は省
略される。このＥ−マテリアルブロックは、Ｅ−マテリアルの特定の属性に関す
る決定を表すため決定ブロックと呼ばれる。記述要求およびコンテント要求には
、要求されているＥ−マテリアルの属性を表すＥ−マテリアルブロックが含まれ
る。表２は、上述した表から選択される１つの可能な決定ブロックを示す。

【０１４０】

【表２】

【０１４１】 表２：表１のＥ−マテリアルブロックのための決定ブロック例。

【０１４２】 属性ブロックは、サーフェイス記述の特定の属性レベルに属するすべての属性
と値のペアを並べるＥ−マテリアルブロックである。サーフェイス記述ブロック
は、属性ブロックの順序付けられたセットである。サーフェイス記述ブロックは
、３列の表として表すことができ、属性ブロックが最後の２列を占めている。こ
の表の第１列には、各属性ブロックに適用可能な決定パスが含まれている。決定
パスは、決定ブロックからの値を用いて構成されている。これらは、属性ブロッ
クと同じ順序でドット表記法において共に連結されている。このため、イメージ
に適用可能な属性ブロックは、３００×３００ｄｐｉの解像度および８ビット／
ピクセルのグレイスケールを有するランレングス符号化されたイメージであるこ
とを示すvImage.vGray.8.(300,300).vRLE等の決定パスによって修飾される。こ の表記法は、符号化階層構造と呼ばれるサーフェイスの構成を記述する。この階
層構造の根は、ヌル（null）レベルと呼ばれる。

【０１４３】

【表３】

【０１４４】 表３：サーフェイス記述ブロック例。

【０１４５】 例えば、表３に示す場合、符号化階層構造のヌルレベルは、属性vEncodingの 値がvImageであることを示す属性と値のペアである。符号化階層構造は、木のよ
うな構造を形成している。この構造における各ノードは、属性レベルである。次
の属性レベルにおいて、属性ブロックは、このレベルに与えられる属性と値のペ
アとして、vSizeが値（５７６０００，７５６０００）をとらなければならず、v
ColorSpaceが値vGrayをとらなければならないことを示す。それが含む属性のい ずれもが選択リストを用いることなく、または更なる記述を要求することがない
場合、レベルは終端である。vGray自体が属性vPixelDepthを有しているため、こ
のレベルは終端レベルではなく、これは、選択リストの値を用いる。決定パスは
、符号化階層構造フィールドにおいて示されるレベルに向かって木を下る決定の
セットを与える。決定パスにおける各値は、符号化階層構造の木を下る次のレベ
ルへの降下を示し、決定パスの最後の値は、属性レベルのネームである。サーフ
ェイス記述は、符号化階層構造のレベルが終端であると知らされた時に完了した
ものとして知らされる。これらのレベルを超えた更なる記述を用いることは不可
能である。

【０１４６】 ドキュメントは、１つまたは複数のサーフェイスから構成されている。各サー
フェイスには、「mySurface」または「doc/plane3/image2」等のネームを与える
ことができる。ドキュメントは、４列の表を用いて完全に記述することができ、
その最後の３列はサーフェイス記述テーブルによって占められている。最初の列
は、記述されているサーフェイスのネームを有している。そのような表の例を、
表４に示す。

【０１４７】

【表４】

【０１４８】 表４：Ｅ−マテリアルドキュメント記述。

【０１４９】 ドキュメントのサーフェイスは、木のような構造において編成されている。ド
キュメントは複数のページから構成されており、ページはテキストまたはイメー
ジ等のブロックから構成されている。所定のサーフェイスのいくつかの属性は、
下のレベルの子サーフェイスの構成を記述する。これら属性は、サーフェイス階
層構造を生じる。この階層構造の根は、トップレベルサーフェイスと呼ばれる。

【０１５０】 サーフェイス階層構造内のいくつかのサーフェイスは、１つまたは複数の子サ
ーフェイスを有する。これら子サーフェイスは、各親サーフェイスに対して別個
な１つまたは複数の順序付けられた子リストで編成されている。子リストは、１
ページの片面のイメージおよびテキストブロックのリスト等、適切に特徴付けら
れている。しかしながら、それは、いつでも完全に利用できるとは限らない。マ
ルチページスキャナによってページのスタックが走査される場合について考える
。各ページについて、番号、指示およびコンテントが存在するが、そのスタック
の構成を反映する子リストは、いつでもそれほど容易に利用可能ではない。その
ようなサーフェイスは、要求されるまで、または関連したデバイス動作に対して
適当な時間となるまで生成されない。

【０１５１】 子リストは、特徴付けられると、親サーフェイスに関連する子サーフェイスの
ネームを与える。サーフェイス記述テーブルにおいて、これは参照リストと呼ば
れる。

【０１５２】 Ｅ−マテリアルサーフェイス記述のための形式的な構造については、後述する
。Ｅ−マテリアルはテーブルで指定され、各セルのエレメントは、文法のような
形式で属性および値から記述の構成を決定するよう扱われる。予め定義されたキ
ーワードまたはヌル終了ＡＳＣＩＩストリング等の低レベルデータタイプは、文
法上の終端記号となり得る。ここでは、それらはＥ−マテリアルバイトフォーマ
ット（後述する）のデータタイプに関連する。

【０１５３】 Ｅ−マテリアル表記規則について、以下の表５に示す。

【０１５４】

【表５】

【０１５５】 表５：Ｅ−マテリアル表記規則。

【０１５６】 Ｅ−マテリアルデータタイプ（Ｅ−マテリアルバイトフォーマットデータタイ
プに対応するが、これについては後に詳述する）を、表６に示す。

【０１５７】

【表６】

【０１５８】 表６：Ｅ−マテリアルデータタイプ。

【０１５９】 属性ブロックは、表７に示すタイプのものである。

【０１６０】

【表７】

【０１６１】 表７：属性ブロックタイプ。

【０１６２】 Ｅ−マテリアルリストとして、多くの値が表されている。「汎用リスト」は、
最も容易に一緒にして扱われる単純な値である。そのリストの要素の数は可変で
ある。「選択リスト」には、折衝プロセス中に選択される個々の値が含まれる。
「参照リスト」には、一緒にリンクされてページまたはドキュメントを形成する
サーフェイスのネームが含まれる。

【０１６３】 Ｅ−マテリアル汎用リスト仕様タイプを、以下の表８に示す。

【０１６４】

【表８】

【０１６５】 表８：Ｅ−マテリアル汎用リスト仕様タイプ。

【０１６６】 選択リストは、emListTypeによって定義されるような多くのトークンの組合わ
せとなり得る。正当な組合わせは、選択リストが対になる特定の属性によって制
限される。選択リスト中の個々の値は属性に一致しなければならないが、リスト
中の値の数には実際には実用的な制限がない。一般的に発生する仕様のタイプを
図９に示す。

【０１６７】

【表９】

【０１６８】 表９：Ｅ−マテリアル選択リスト仕様タイプ。

【０１６９】 言語および国への参照が望まれる場合、vLanguage属性を符号化階層構造中に 含めることができる。これは、vText符号化に対しては必要であり、他の符号化 に対しては任意である。vLanguage属性は、特定の選択リストを要求する。それ は、言語を識別し、適用可能な特性が使用可能である国を任意に識別する。予測
されるフォーマットは、languageCode[-contryCode]（言語コード［国コード］ ）である。国コードが別個の値として言語コードに続く場合であっても、言語コ
ードが一意の値として識別されることが要件である。国コードがその値に更なる
解明を付加する場合は、国コードに一意の言語コードを付加してもよく、それは
任意である。

【０１７０】 符号化選択リストは概して、vImageまたはvText等の１つまたは複数のemKeyTy
pe値のみを提供する。vEncodingに関連付けられた選択リストにおいてemStringT
ypeを定義することによりおよびそれを一様に使用することにより、特別な符号 化を付加することができる。それは、独立してemKeyTypeとして定義されるキー ワードとみなされるため、そのemKeyTypeのvAssociationは、特別な符号化のemS
tringTypeの「vAssociation」とは同じものではない。

【０１７１】 選択リスト内の組合せの順序は、送信機器の優先権を示している。

【０１７２】 決定パスは、決定ブロックの値から構成される。また、これらの値は、選択リ
ストから得られる。符号化階層構造は、これらの決定パスによって表現される。
決定パスは、各属性ブロックのレベルを識別するために使用される。決定パスの
仕様タイプを以下の表１０に示す。

【０１７３】

【表１０】

【０１７４】 表１０：Ｅ−マテリアル決定パス仕様タイプ。

【０１７５】 ヌルレベルは、JetSendサーフェイスの符号化階層構造に対するエントリポイ ントを提供する。ヌルレベルにおいて、決定パスはヌルである。このヌルレベル
は、状況に応じて３つの異なる形態のうちのどれかの形態をとる。 ・ヌルレベルは、vEncoding属性のみを含む。これは、ヌルレベルの最も一般的 なタイプである。大抵のサーフェイスは、かかるヌルレベルで開始する。 ・ヌルレベルは、vLanguage属性のみを含む。このvLanguage属性には、vTextサ ーフェイスが必要とされる。それは、同様に他のサーフェイス符号化において見
られる場合もある。 ・サーフェイス記述が不完全である場合、記述要求および記述応答が、サーフェ
イス記述の交換を完了するために実行されなければならない。この記述要求およ
び記述応答は、一緒に、サーフェイス記述を完成するために個々の属性レベルに
従って実行されなければならない。既に選択された値と共に選択リストを利用す
るそれら属性は、記述要求の決定ブロックに現れる。アドレス指定されていない
選択リストを利用するそれら属性は、記述応答の決定パスに現れる。選択リスト
を利用する属性の順序付けられたリストにおいて、区切り（break）が動的に確 立されるため、記述応答においていずれのレベルもヌルレベルとなり得る。

【０１７６】 サーフェイス階層構造は、参照リストを用いることから生じる。参照リストは
、この親サーフェイスにリンクされている子リスト中の子サーフェイスの構造を
示す。子リストが使用可能である時、このリストにおける子サーフェイスは、参
照リスト中のchildCount数および子サーフェイスネームに直接対応する。時に、
子リストが使用可能でない場合があり、それによって参照リストは、不完全な絵
を示す。

【０１７７】 参照リストは、単純なＥ−マテリアルリスト、すなわちemListTypeである。多
くの場合、そのリストは、childCount、キーワードvSequentialまたはvArbitrar
y、および子サーフェイスネームのリストの形態をとる。参照リストは、単一の ページ（vPlane符号化の場合）またはドキュメント内の他のページ（vAssociati
on符号化の場合）におけるエレメントを共にリンクすることができる。各サーフ
ェイスは、別々に折衝されたジョブエレメントである。

【０１７８】 参照リストは、vPlaneまたはvAssociationサーフェイス符号化にのみ関連付け
られる。その他の符号化（vImage、vText、vFile）は、サーフェイス階層構造の
終端レベルにのみなり得る。vPlane符号化は、２つ（前面に対するvChildFront および背面に対するvChildBack）の子サーフェイスリストを有してもよく、１つ
（vChildFrontまたはvChildBack）の子サーフェイスリストを有してもよく、ま たはいずれを有していなくてもよい。vAssociation符号化は、１つ（vChild）の
子サーフェイスリストを有していなければならない。Ｅ−マテリアル参照リスト
仕様タイプについて、表１１に示す。

【０１７９】

【表１１】

【０１８０】 表１１：Ｅ−マテリアル参照リスト仕様タイプ。

【０１８１】 childCount値は、負、ゼロまたは正のいずれでもよい。childCountの小さい正
の値は、対応する参照リストを含み、子リストの完全なコンテントを列挙する。
childCountの大きい正の値は、子リストは知られているが参照リストは長すぎて
含めることができないということを示している。他のchildCount値は、子リスト
が知られていないか、またはゼロの長さであることを示している。いずれの場合
も、参照は含まれない。

【０１８２】 vSequentialおよびvArbitraryキーワードは、送信機器がサーフェイスを送信 することができる順序に何らかの制限があるか否かを示すために使用される。こ
れにより、受信機器は、要求されたサーフェイスの順序を完全に制御することが
できる。それによって、受信機器は、情報、すなわちコンテントおよび子サーフ
ェイスの両方がどの順序で要求されるかを知ることができる。子に関するコンテ
ント情報はインラインとしてもよく、あるいは、コンテント情報は１つまたは複
数の子に対して一度に要求されるようにしてもよい。しかしながら、子のサーフ
ェイス記述は、一度に１つ要求されなければならない。

【０１８３】 値vArbitraryは、送信機器が、コンテント情報にアクセスし、それを送信し、
要求されている順序で受信側で子サーフェイスをインプレスすることができる、
ということを示している。値vSequentialは、送信側デバイスが制限されている ために子が予め決められた順序でのみ要求されるということを意味している。

【０１８４】 参照リストの残りは、他のサーフェイスのネームを与える。これらネームは、
完全な子リストが知られており、かつ比較的短い場合に存在する。参照が含まれ
る場合、以下の解釈が適用される。 ・参照ネームは一意でなければならない。 ・＃（井桁記号）は、予約記号である。 ・参照は、平面上で描写されるべき子を示す。 ・子の順序は、それらが描写されるべき順序（ｚ方向であり、vPlaneを参照して
後述する）である。 ・参照が列挙されると、参照の数はchildCount値に基づいて指定される子の数と
一致しなければならない。参照を部分的に列挙することは認められない。すべて
を列挙することができないか、もしくは参照が知られていない場合、それらは、
コンテント要求において使用可能なメカニズムを介して「発見」されなければな
らない。

【０１８５】 いくつかの子に対するコンテント情報をインラインとすることは可能である。
これは、referenceList値にvChildFront、vChildBackまたはvChild属性のものが
含まれる場合においてのみ可能である。インラインでないコンテントについては
、コンテント要求が使用される。

【０１８６】 JetSend機器がすべての環境下で通信することを保証するために、特定の決定 パスが存在することが必要である。これらは、デフォルト符号化（default enco
ding）と呼ばれる。送信機器は、これらデフォルトの決定パスによって記述され
る属性を有するＥ−マテリアルを生成することができなければならない。同様に
、受信機器は、これらの特性を有するＥ−マテリアルを解釈することができなけ
ればならない。例えば、vImage.vGray.1.(300,300).vRLEは、vImageに対するデ フォルト符号化である。

【０１８７】 機器が正常な状態においてＥ−マテリアルを交換することを保証するために、
デフォルト符号化が存在する。これらの符号化は、最低限の共通の特徴である。
ベース符号化は、機器がより高い忠実度でＥ−マテリアルを交換することができ
るようにする推奨された決定パスである。他の属性および値は、任意とみなされ
る。vImageに対するベース符号化の例は、vImage.vGray.8.(150,150).vRLE、vIm
age.vGray.8.(150,150).vNoneおよびvImage.vSRGB.24.(150,150).vNoneである。

【０１８８】 デフォルト符号化は、決定パスであり、その各エレメントは選択リストから生
じる。各選択リストには、属性が関連付けられている。サーフェイス記述には、
値がデフォルト符号化を構成する属性の各々が存在しなければならない。

【０１８９】 ここで、本発明に対して特別に関連のある２つのタイプのサーフェイスに対す
る符号化、すなわちvPlaneおよびvAssociationについて詳細に説明すると共に、
例を示す。ここでこれ以上説明しない他の符号化については、http://www.jetse
nd.hp.com/、「Method and Apparatus for Device Interaction by Protocol」 と題された米国特許出願第０９／０５９，８６７号、および米国特許出願第０９
／０５９，９０９号に詳細に記されており、後者の２つの出願については、上述
したようにこの参考によりその開示内容が本明細書に包含されている。

【０１９０】 vPlane vPlane符号化は、物理的オブジェクトまたは描写（rendering）の空間的態様 に関連する所定のタイプの情報を表すよう設計されている。特に、それは、ペー
ジ（両面ページを含む）、すなわちイメージ、テキストおよび注釈として分類さ
れる領域を含む、ページ上の２次元領域間の関係を表すことができ、更に描写す
べき媒体もまた表すことができる。

【０１９１】 値vPlaneは、トップレベル符号化を示し、複雑な情報タイプを表すために子を
含む。これは、これら種々の子の間の関係を記述するために広く使用される。

【０１９２】 平面は、前面および背面から構成されるページを表すことができる。ページは
サイズおよびカラーを有し、イメージおよびテキストは、平面上で描写される子
を表すことができる。また、平面は、コンピュータスクリーンを表すことも可能
である。この場合、スクリーンレイアウトは、単一面から成る。スクリーンは、
サイズおよびカラーを有する。イメージおよびテキストは、テキスト、スティッ
キー（粘着性）メモおよびアイコンを有するウインドウを表す多数の子を表すこ
とができる。

【０１９３】 vPlane符号化の図式化した図を図６に示す。これは、サーフェイスを表す平面
２７０を示す。サーフェイスが定義されており、イメージを表す子がそのサーフ
ェイス上に配置されている。ｚ軸に沿った子の順序は、子がサーフェイス上で配
置または描写される順序を示している。

【０１９４】 vPlaneのための属性の階層構造を、図５に示す。ここに示す異なる属性各々の
意味を、簡単に説明する。

【０１９５】 vLanguage：vLanguage属性は、言語および国に対する参照が望まれる場合に含
められる。デフォルトの言語値は指定されていない。

【０１９６】 vEncoding：vPlaneは、ページ状のサーフェイスである。これは２つの面を有 し、通常、子として１つまたは複数のサブサーフェイスを有している。その属性
は、この符号化において定義される。

【０１９７】 vChildFront：平面の前面における子サーフェイスにリンクする参照リストを 提供する。childCount値は、周知の子サーフェイスの数を示す。それは、負、ゼ
ロまたは正とすることができる。childCountの小さい正の値は、一致した数の参
照と対をなしている。他の値は、いずれの参照とも対をなさない。送信機器が参
照されたサーフェイスを送信することができる順序に対して制限がある場合、vS
equentialキーワードが使用され、そうでない場合は、vArbitraryが使用される 。これにより、受信機器が、要求されたサーフェイスの順序を完全に制御するこ
とができる。

【０１９８】 vChildBack：vChildFrontと同様であるが、参照リストは、平面の背面上のい ずれの子サーフェイスとリンクする。

【０１９９】 vBackCoord：背面座標系の回転の量を指定する。背面は、前面の次元を反映し
なければならない。vChildBack属性が省略されている場合、この属性は任意であ
る。また、背面座標に変更が無い場合に、省略してもよい。

【０２００】 vSize属性に対するｘ値およびｙ値が等しい場合（正方形平面）、サポートさ れるvBackCoord値は、０、９０、１８０および２７０である。vSize属性に対す るＸおよびＹ値が等しくない場合（長方形平面）、サポートされるvBackCoord値
は、０および１８０である。平面上に配置される子はすべて、この座標変換に関
連して描写されるべきである。

【０２０１】 vBackCoordは、以下のように与えられる。すなわち、背面は、あたかも一時的
なＹ軸（Temporary Y axis）を中心に裏返されるように見ることができる（図７
ａおよび図７ｂ参照）。そして、vBackCoordは、ｘ、ｙ交点を中心とする反時計
回りの回転として与えることができる（図７ｃ参照）。次いで、平面は、デフォ
ルト座標位置に移動する（図７ｄ参照）。

【０２０２】 vSize：属性vSizeは、記述されている平面に対する描写次元を指示する。図６
は、仮定された座標系を示す。また、使用される整数値が、１／７２０００イン
チ（１インチ（２．５４センチメートル）あたり７２０００ユニットあることを
意味する）の実世界の座標にあると仮定される。第１の整数値はｘ軸に沿ってお
り、第２の整数値はｙ軸に沿っている。

【０２０３】 vOpacity：下にある情報に対する平面の不透明度を示す。値は、０〜２５５で
あり、デフォルトは２５５（不透明）である。

【０２０４】 vColor：平面のカラーを示す。０〜２５５の範囲における３つの符号無し整数
値のリストである。第１の値は赤成分、第２の値は緑成分、および第３の値は青
成分である。０値は、輝度の無いことを示す。２５５は、輝度がフルであること
を示す。vOpacity値が０である場合、vColor値は意味を有さない。

【０２０５】 vPosition：親平面に対する子の位置を表す。このペアにおける第１の値はｘ 座標であり、第２の値はｙ座標である。この属性は、vChildFront属性およびvCh
ildBack属性によって参照される子に対して含められる。この属性は、情報が提 供されるべき各子に対して一意に列挙されなければならない。この属性は、あら
ゆる数の参照された子に対して提供することができる。

【０２０６】 vAttachment：親に対して子がどのように操作されるかを記述する。

【０２０７】 値vFixedは、子が、vPosition属性によって指定されるポイントにおいて固定 されたままであるべきであることを示す。値vFloatingは、操作可能な機器によ って、子が親に対して再配置されることを示す。

【０２０８】 vAttachment属性は、vChildFront属性およびvChildBack属性によって参照され
る子に対して含められる。この属性は、情報が提供されるべき各子に対して一意
に列挙されなければならない。この属性は、あらゆる数の参照された子に対して
提供することができる。

【０２０９】 記述要求および応答は、実質的に上述した通りである。コンテント要求および
応答との関連には違いがある。コンテント要求は、受信側デバイスにより２つの
状況において使用される。すなわち、子サーフェイスが含まれていない場合およ
び子参照に関連する記述情報が得られなかった場合に、子サーフェイスに関する
情報を要求する。

【０２１０】 記述ブロックにすべての情報が見つからない場合は、例えば、子のネームの参
照（references）が得られない場合である。それら参照は、間接的な子の参照（
vFirstおよびvLastの値）を用いて子情報が要求されていることを示すために、 コンテント要求を介して要求されることができる。コンテント要求が使用される
第２の例は、平面に関連することを除いて子に関連するコンテント情報を要求す
る場合である。vPlaneに対する符号化に関する子のコンテント情報は、vPositio
n属性およびvAttachment属性と、子と平面との関係を示す値とから構成されてい
る。

【０２１１】 受信側デバイスは、各子に対する参照を必要とする。これら子の参照は一般に
、vChildFront属性またはvChildBack属性に関連するreferenceListの一部である
か、または、上述したように記述要求を介して既に受信されているものである。
（一般に、このレベルでは子に関連する属性はわずかであるため、参照された子
に対する記述情報は「インライン」である。）コンテント情報がインラインでな
い場合、情報を要求するためにコンテント要求が使用される。受信側デバイスは
、送信側デバイスに対し、サーフェイス記述から選択されたものをすべて供給し
、どの選択がなされたかを送信側デバイスに示す。更に、受信側デバイスはまた
、送信側デバイスに対し、可能であれば子の参照の明示的なリストを供給するか
、または子情報に対する要求を示すための間接的な参照（vFirstおよびvLastの 値）が要求される。そして、送信側デバイスは、その子の参照に関連する記述情
報を返すことができる。

【０２１２】 コンテント要求ブロックは、vChild、vChildNextおよびvNumberの任意の属性 を有することとなる。

【０２１３】 vChildは、vFrontFirst、vBackLastまたは参照リスト等の値をとることができ
る。子が先にvFrontFirst、vFrontLast、vBackFirstまたはvBackLastを用いて参
照されている場合、これらのキーワード値は二度と使用することができない。こ
こで単一の参照が行われている場合、それは、１つまたは複数の子に対して返す
べきコンテント情報に対し、開始ポイントを指定する。要求される数および参照
から前方または後方のシーケンスは、vNumber属性に基づいて指定される。refer
enceListが指定された場合、それは、指定された子のコンテントに対して明示的
な要求である。vNumber属性は使用されない。

【０２１４】 キーワードvFrontFirstおよびvBackFirstは、この構造における第１の子に対 する間接的な参照である。これは、ネームの参照が知られていない場合と同様、
ネームの参照が指定された場合に適用される。キーワードvFrontLastおよびvBac
kLastは、同様に最後の子に参照するために使用される。子の数が知られていな いかまたはアクセスが逐次である場合、最後の子に対して子の参照を間接的に設
定した結果、期待された結果が生成されない可能性がある。これは、最後の子が
アクセス可能でない可能性があるためである。

【０２１５】 送信側デバイスが先になされた要求のステータスを保持しないため、vFrontFi
rst、vFrontLast、vBackFirstまたはvBackLastが使用されると、後続する要求は
、先のコンテント応答において返された明示的な参照を使用するか、またはvChi
ldNext属性を使用すべきである。vChild属性は、vChildNext属性と共に使用すべ
きではない。

【０２１６】 vChildNextを、先の子が参照された場合に使用することができる。vChildNext
を、送信側デバイスによって識別されるシーケンスにおいて、次の子に対するコ
ンテントを要求するために使用することができる。この属性は、先の子が参照さ
れていない場合には使用されない。この属性は、vChild属性が参照ネームと共に
用いられている場合には省略されなければならない。

【０２１７】 参照値は、要求されている子情報に先立つ子のネームである。vChildNextを、
次の子のネームが知られていない場合に、使用することができる。要求された数
および参照から前方または後方のシーケンスは、vNumber属性に基づいて指定さ れる。

【０２１８】 vNumberは任意であり、単一の参照がvChild属性に基づいて指定された時、ま たはvChild属性がvFrontFirst、vFrontLast、vBackFirst、vBackLastに設定され
る場合、またはvChildNext属性が使用される場合にのみ、使用される。vNumber は、受信側デバイスがコンテントを要求している参照の数を示す値に関連付けら
れている。vNumberが、vChild属性に関連付けられた参照と共に使用される場合 、返されるアイテムは、参照された子を含むようになる。vNumberがvChildNext 属性に関連付けられた参照と共に使用される場合、返されるアイテムの数は、参
照された子を含まないが、参照の子に続く子を含むようになる。

【０２１９】 「先立つ」および「続く」という用語は、上記のようにvChildNextに関連して
使用されているが、vFrontLastまたはvBackLastが使用される場合、「次の」子 はリストにおける先行する子となり得ることに留意されたい。

【０２２０】 可能であれば、送信側は、要求された順序で要求された子に対するコンテント
情報を送信する。この属性が見つからない場合、または値がゼロである場合は、
送信側は参照から可能な限り多くの子のコンテントを送信する。

【０２２１】 適当なコンテント応答は、比較的簡単である。属性vNumberは、コンテント応 答において子の数を返す。vNamesは、要求された順序で子の参照を返す。vRemai
ningは、コンテント要求が未だなされていない子の数を示す。vPositionおよびv
Attachmentの値は、返される参照の各々に対して提供されるべきである。

【０２２２】 vPlaneの使用に際して、以下の要素を考慮する必要がある。

【０２２３】 １．現実施において、vPlane符号化を、他のサーフェイス（イメージ、テキス
トおよび平面）を配置することができる仮想ページを表すものとして見ることが
できる。この仮想ページを現実化する例として、物理的な用紙、ホワイトボード
および種々のディスプレイが含まれる。最良の類似物は、絵およびテキストが切
取られ貼付けられる白紙の用紙である。物理的な世界において、ページは両面で
あり、そのため、vPlane符号化は、この概念をよりありのままに近い物理的用紙
に与える。物理的ドキュメントは、ドキュメントの基本ユニットとみなすことが
できる多数のvPlane符号化（各ページに１つ）を含むvAssociation符号化（後述
する）によって表される。概して、vPlane符号化は、その子サーフェイス間の空
間的関係を生成する。

【０２２４】 ２．vChildFront、vChildBack、vChild、vChildNextまたはvNames属性に関連 付けられた各参照は、一意でなければならない。単一のサーフェイスが多数回参
照されるメカニズムが提供されている。受信側デバイスは、このメカニズムを実
現することを希望している場合、多数回サーフェイスを要求するか、または参照
データを内部的に保持するオプションを有する。サーフェイス情報が多数回使用
されるが、子コンテント（vPosition、vAttachment）情報が異なる場合、「#ref
erence」（井桁記号）（参照）が含められる。この「#reference」は、インデク
スとして作用し、子および子のコンテントを一意に識別する。

【０２２５】 ３．referenceListが子サーフェイスのネームを含まない場合、ネームはコン テント要求によって取得されなければならない。

【０２２６】 ４．値vSequentialが現れる場合、送信側デバイスが制限されているため、子 は予め決められた順序でのみ要求される。これは、以下の処理シーケンスを含む
。 ・次の子のコンテント情報（アタッチメントを記述する）を要求する。（親サー
フェイスにおいてコンテント要求および応答のペアを用いる） ・その子のサーフェイス記述／インプレッションを要求する。（その子サーフェ
イスにおいて記述要求および応答のペアを用いる） ・その子のコンテントを要求する。（その子サーフェイスにおいてコンテント要
求および応答のペアを用いる） ・その子を描写する。 ・子がそれ以上存在しなくなるまで、次の子等のコンテント（アタッチメント）
情報を要求する。

【０２２７】 ５．子リストが知られているか知られていないかに関わらず、一度に１つまた
は複数、子に対するコンテントデータを要求するには、多数の方法がある。子リ
ストにおいて子サーフェイスにアクセスするために、以下の方法が適用可能であ
る。 ・１または複数の参照ネームと共にvChildを用いて、種々の子サーフェイスにア
クセスする。 ・vFrontFirstまたはvBackFirstを用いて、リスト内の第１の子サーフェイスに アクセスする。 ・適宜、vFrontLastまたはvBackLastを用いて、リスト内の最後の子サーフェイ スにアクセスする。 ・１または複数に等しいvNumberと共にvChildNextを用いて、リスト内の次の１ つまたは複数の子サーフェイスにアクセスする。これは、この子リストにおける
子サーフェイスに対する最初のアクセスにはなり得ない。 ・ゼロまたは定義されていないvNumberと共にvChildNextを用いて、リスト内の 残りの子サーフェイスにアクセスする。これもまた、この子リストにおける子サ
ーフェイスに対する最初のアクセスにはなり得ない。

【０２２８】 ６．以下のシーケンスにより、子リストにおけるサーフェイスに対するランダ
ムアクセスが達成される。 ・コンテント要求におけるvChildFrontまたはvChildBack属性に対する値として サーフェイスネームを使用する。このサーフェイスネームは、コンテント応答に
おいて返される。vPlaneの場合、アタッチメント情報もまた返される。 ・子サーフェイスネームを用いて記述要求を構成する。サーフェイス記述は、記
述応答において返される。 ・コンテント要求を用いて、子サーフェイスのサーフェイスコンテントを取得す
る。この情報は、コンテント応答において返される。 ・コンテント情報を描写する。 ・このプロセスは要求に応じて継続する。

【０２２９】 ７．子リストにおけるサーフェイスに対するシリアルアクセスは、以下により
達成される。 ・親サーフェイスにおけるコンテント要求内のvChildFrontまたはvChildBack属 性に対する値として、vFrontFirstまたはvBackFirstを用いる。（値vFrontLast またはvBackLastは、childCountが正でありvArbitraryキーが与えられている場 合に、これらの属性に対する値として使用される。）子リストにおける指定され
た子サーフェイスのサーフェイスネームは、子リストにおける残りの子サーフェ
イスの数と共にコンテント応答において返される。vPlane符号化の場合、アタッ
チメント情報もまた返される。 ・子サーフェイスネームを用いて、記述要求を構成する。サーフェイス記述は、
記述応答において返される。 ・コンテント要求を用いて、子サーフェイスのサーフェイスコンテントを取得す
る。この情報は、コンテント応答において返される。 ・子サーフェイスコンテント情報を描写する。vPlane符号化の場合、アタッチメ
ント情報を用いる。 ・親サーフェイスにおけるコンテント要求内のvChildNext属性に対する値として
、子サーフェイスネームを使用する。子リストにおける次の子サーフェイスのサ
ーフェイスネームは、子リストにおける残りの子サーフェイスの数と共にコンテ
ント応答において返される。vPlane符号化の場合、アタッチメント情報もまた返
される。 ・このプロセスは、残りの子サーフェイスが無くなるまで継続する。

【０２３０】 ８．childCountおよびvArbitraryまたはvSequentialキーの値は、子リストに おける種々のサーフェイスに対してアクセスする方法を示す。 ・小さい正のchildCount値およびvArbitraryキーは、子サーフェイスがいかなる
方法でも、すなわち、逐次前方に、逐次後方に、またはランダムに、アクセスが
可能であることを示す。ランダムアクセスは、参照リストにおけるサーフェイス
ネームを用いることにより可能になる。更に、ある子サーフェイスのためのイン
ラインコンテントを含めることが可能である。 ・小さい正のchildCount値およびvSequentialキーは、子サーフェイスが逐次前 方にのみアクセスすることが可能であることを示す。サーフェイスネームが含ま
れているが、ランダムアクセスは不可能である。 ・大きい正のchildCount値およびvArbitraryキーは、子サーフェイスが逐次前方
にまたは逐次後方にアクセスが可能であることを示す。 ・大きい正のchildCount値およびvSequentialキーは、子サーフェイスが逐次前 方にのみアクセスが可能であることを示す。 ・負のchildCount値（vArbitraryまたはvSequentialキーの設定に関わらず）は 、子サーフェイスが逐次前方にのみ「発見する」ことが可能であることを示す。
・ゼロのchildCount値は、子リストに子サーフェイスが存在しないことを意味す
る。vPlaneの場合、両方の子リストが空である時、vPlaneサーフェイスは、単に
、vColorおよびvSize等のわずかな属性を有する基本サーフェイスである。vAsso
ciationの場合、子リストが空である時、サーフェイスは無用である。

【０２３１】 ９．リスト内の子サーフェイスへのアクセスは、参照ネームにより直接的に、
または他のメカニズムにより間接的に行うことができる。子リストにおける各子
サーフェイスは、参照ネームとリスト内の順序位置を有している。すべての子サ
ーフェイスリストに対して順序が存在する。それは、送信機器が、その順序でサ
ーフェイスを提供するよう強制される（vSequential）か、または任意の順序で サーフェイスを提供することができる（vArbitrary）かには関係がない。また、
vPlaneサーフェイスにおける各子サーフェイスは、サーフェイス上の位置（vPos
ition）およびアタッチメントの方法（vAttachment）も有している。子サーフェ
イスからの記述またはコンテント情報の直接アクセスは、常に参照ネームによっ
て行われる。子サーフェイスからの記述またはコンテント情報の間接アクセスは
、子のリストにより逐次前方にまたは後方に移動することによって行われる。

【０２３２】 vPlane符号化を使用する例を、以下に示す。

【０２３３】 例１：１ページ平面、８．５インチ（２１．５９センチメートル）×１１イン
チ（２７．９４センチメートル）、２つの子（可能性としてイメージ、しかし含
まれず）。子コンテント情報は、インラインで提供される。

【０２３４】 例２：１ページ、両面、「前面」側には２つの子、「背面」側には１つの子。
子コンテント情報は、インラインで提供されない。

【０２３５】 例３：１つの走査されたページ２９１を有する平面２９０、８．５インチ（２
１．５９センチメートル）×１１インチ（２７．９４センチメートル）、１つの
注釈２９２を有し、テキストと共に黄色のハイライト２９３および赤の「スティ
ッキー」タイプのメモ２９４。最後の３つは、明確に、走査されたイメージに続
いて追加されていなければならないため、イメージは動的に生成されず、子の数
は知られている。図８は、この例を図式化している。

【０２３６】 子の無い平面符号化は、

【０２３７】 第１の子は、１つのイメージ（背景イメージ）を表す。

【０２３８】 第２の子は、テキスト注釈を表す。

【０２３９】 第３の子は、黄色のハイライト領域を表す。これは、２つのカラーモデルで使
用することができる。

【０２４０】 第４の子は、別個の赤のスティキータイプのメモを表す。

【０２４１】 vAssociation 現実現において、vAssociation符号化は、その子サーフェイス間のシーケンシ
ャルな関係を表す。それは、ドキュメントのページ間の関係を記述するために主
として使用される（本発明によれば、ドキュメントとして多数ページを定義して
それら多数ページ間の関係を記述し、個々のページは、ドキュメント部として、
vPlane符号化として描写される）。それはまた、ドキュメントのシーケンシャル
な構成、例えばフォルダまたは他のコンテナを表すために使用することができる
。将来的に、vAssociationは、ビデオクリップ、音声クリップまたはページの混
合のシーケンス、すなわち、ユーザに対して連続に提供するよう意図されたビデ
オおよび音声を表すために使用することが可能となる。また、現実施においてvA
ssociationの基本的なシーケンシャル特性は、ランダムな順序等他の構成を含む
ように有効に拡張されることができる（更なる特徴は後を参照）。

【０２４２】 vAssociationのための属性の階層構造を、図９ａに示す。各異なる属性の意味
は、vPlane符号化の説明から明らかである。vAssociationは単に、子サーフェイ
ス間の連想の関係を提供するものである。それは、この実施ではそれ自体の属性
を有していない。しかしながら、後述するように、特にvPlaneの子を有するvAss
ociationの文脈において、vAssociationに対して任意の属性を追加することによ
り、更なる特徴を提供することができる。

【０２４３】 記述要求および応答は、技術的には可能であるが、実際には要求される可能性
が低い。コンテント要求および応答に対しては、本質的に、子サーフェイスに関
連して、vPlaneに対するのと同様の考慮が適用される。

【０２４４】 平面の子にアクセスするために記述されたメカニズムは概して、アソシエーシ
ョンに対しても適用される。しかしながら、アソシエーションは、入れ子にされ
る可能性がより高い（すなわち、あるアソシエーションが子サーフェイスとして
別のアソシエーションを含むことができる）。例えば、これは、ドキュメントの
フォルダの場合に当てはまる。この場合、ドキュメントはアソシエーションであ
り、同様にアソシエーションによって表されるフォルダの子サーフェイスである
。デバイスは、仕様により、これら入れ子にされた関係を保存することが要求さ
れないが、そうするようには推奨される。デバイスはすべて、少なくとも最小深
さ（現実施では４レベルまで必要である）に入れ子にされたアソシエーションを
処理することができなければならない。仕上げ機能を有するプリンタ等のデバイ
スによっては、フォルダにおいてドキュメントの子を利用して、ステープルで留
めることによりドキュメントを別々にする。この機能を有していない他のプリン
タは、恐らくはページを順次プリントアウトするのみであり、フォルダアソシエ
ーションによって与えられる分離という余分のレベルを破棄するように見える。
なお、平面もまた入れ子にすることができるが、現実施では一般的ではない。

【０２４５】 例４：アソシエーションは３ページのドキュメントを表す。子は、受信側が選
択する任意の順序でインプレスされることができるが、子の論理的な順序付けは
１、２、３として固定されるべきである。

【０２４６】 ２面のページを組込んだドキュメントの機能を増大させるために、上述したよ
うにvPlaneおよびvAssociation符号化を使用することによって、更なる特徴を上
記実施に付加することができる。このような特徴は、ドキュメントに、物理的な
ドキュメントに更に類似する振舞いを提供するために使用することができる。こ
れについて、図９ｂに示す。

【０２４７】 特にvPlaneの子を有するvAssociationによって適応可能な１つの更なる特徴は
、ドキュメントが別々の子のシーケンスを有するかまたはランダムな集合体を有
するかを指定するというものである。これは、vAssociationに対する任意の属性
、vPerspectivesを確立することによって可能となる。これは、連続したドキュ メントの場合（例えば、一連のページまたは恐らくイメージ）はvSequentialに 設定することができ、別々の子の間に、ドキュメント内に含まれるということ以
上の関係が無い場合は、vRandomに設定することができる。

【０２４８】 連続したドキュメントの場合、更なる任意の属性を用いて、ドキュメントの両
面のシートの３次元における操作を決定するための情報を提供することができる
。これは、両面ページのアソシエーションを、一連の両面ページから構成される
実世界のドキュメントを見るために使用されるのと同じ操作が施されるものとし
てみなすことにより、行うことができる。この属性vViewtypeは、例えば、値vFl
ipableをとることができ、この場合、ページが結合され回転の中心とすることが
できる軸が定義される。この軸は本の背に匹敵する。従って、概して、この軸は
、各両面シートの前面の左手端部にある。代案として、vViewtypeは、値vCyclic
をとることも可能であり、これは、軸ではなくリングバインダの連結を定義する
。この場合は概して、リングは、両面シートのすべての上端縁部を連結するよう
設定され、結果としてのドキュメントは、リポータのノートの３次元の振舞いを
有し、一度に１頁が（ビューまたはディスプレイ機器上で）表示され、ページは
、裏返されると、ページのシーケンスの後ろに移動し、次のページが現れる。

【０２４９】 また、vPlaneに対し、物理的振舞いをモデル化する更なる属性を付加すること
ができる。例えば、更なる任意の属性vStickyを使用することができる。vSticky
は、両面シートの一面が取外し可能なアタッチメントという特質を有する、すな
わち、接着と同じ特質であるが、物理的なオフィスで広く使用される接着性のメ
モ用紙において見られる再配置可能性を有するということを示すために使用され
る。この特質は、両面シートの一面に対して設定される場合、機器に対して次の
ことを示す。すなわち、スティッキーであるように設定されるサーフェイスに隣
接していると考えられる別のオブジェクトがそれに接着することになり、「ステ
ィッキー」オブジェクトを別々に移動させるステップが取られない限りは、「ス
ティッキー」サーフェイスを有するオブジェクトは、それが接着するオブジェク
トと共に移動することとなる、ということである。これは、例えば、図１１ａに
示すような２つのvPlaneの子を有するvPlane符号化の場合に考えることができる
。親平面１１１は、ｚ方向に順序付けられた２つの子１１２、１１３を有してい
る。この場合、子平面１１３の後ろ側には、「スティッキー」が設定されている
。ここで、属性vFloatingが子１１２に対して設定されている場合、vPlane符号 化を受信する機器は、親平面１１１に対して子平面１１２を再配置することがで
きる。これは、図１１ｂに示す。しかしながら、子平面１１３の後ろ側が「ステ
ィッキー」であり、子平面１１２に取付けられているため、それは、子平面１１
２に従い、それと共に再配置されるよう適合される。

【０２５０】 ここでは本発明の特定の実施態様が、JetSendアーキテクチャの文脈で説明さ れているが、本発明は、いずれの場合もこのアーキテクチャ内での使用に限定さ
れるものではない。本発明を実現するためには、ある情報処理機器と、１つまた
は複数の両面シートとしてドキュメントを表現することができる別の機器との間
におけるドキュメントの送信手段のみが必要である。これは、例えば、ドキュメ
ントの基本的な要素が両面ページであるような、現存するプリンタ言語の修正ま
たは新たなプリンタ言語の生成において、達成することができる。この方法は、
概して、ドキュメントの生成側が、受信側によってそれがどのように描写される
かを決定することを希望する場合に望ましいものである。そして、基本的な通信
要素として両面ページを使用することは、定義された形態のドキュメントを受信
側に配信する電子メールにおいて、または受信側デバイスまたは描写デバイスに
よって望ましくない「最適化」のための調整を行うことなく、特定の物理的形態
または構成でドキュメントが描画されるべき別の文脈において、特に適用が可能
である。

【図面の簡単な説明】

【図１】 あるデバイスにおけるサーフェイスインプレッション（surface impression）
の、別のデバイスにおけるサーフェイスエクスプレッション（surface expressi
on）からの生成を示す。

【図２】 視覚的なサーフェイス表現における２ページのドキュメントの描写を示す。

【図３】 JetSendアーキテクチャのコンポーネントおよびそれらの各々に対する論理的 関係を示す。

【図４ａ】 機器間の情報と交換するJetSendインタラクションプロトコル（JetSend Inter
action Protocol）のメッセージの使用態様を示す。

【図４ｂ】 機器間の情報と交換するJetSendインタラクションプロトコルのメッセージの 使用態様を示す。

【図４ｃ】 機器間の情報と交換するJetSendインタラクションプロトコルのメッセージの 使用態様を示す。

【図４ｄ】 機器間の情報と交換するJetSendインタラクションプロトコルのメッセージの 使用態様を示す。

【図４ｅ】 機器間の情報と交換するJetSendインタラクションプロトコルのメッセージの 使用態様を示す。

【図４ｆ】 機器間の情報と交換するJetSendインタラクションプロトコルのメッセージの 使用態様を示す。

【図５】 図５は、vPlane符号化のための属性の階層構造を示す。

【図６】 vPlane符号化のためのエレメントのアセンブリを概略的に示す。

【図７ａ】 vPlane符号化におけるvBackCoordのための値の導出を示す。

【図７ｂ】 vPlane符号化におけるvBackCoordのための値の導出を示す。

【図７ｃ】 vPlane符号化におけるvBackCoordのための値の導出を示す。

【図７ｄ】 vPlane符号化におけるvBackCoordのための値の導出を示す。

【図８】 ４つの子（child）エレメントを組込んだvPlaneによる符号化のためのドキュ メントの例を示す。

【図９ａ】 vAssociation符号化のための属性の階層構造を示す。

【図９ｂ】 vAssociation符号化の修正された形態のための修正された階層構造を示す。

【図１０】 本発明が適用可能であるデバイス間の通信を示す。

【図１１ａ】 JetSendの文脈における再配置可能な接着性エレメントの使用を示す。

【図１１ｂ】 JetSendの文脈における再配置可能な接着性エレメントの使用を示す。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ウィリアムズ，ピーター，マイケル イギリス国ノース・サマーセット・ビーエ ス20・８ビーユー，ポーティシェード， メドウズ・クローズ，ザ・ホール・４ (72)発明者 ウィラープ，フレデリック アメリカ合衆国アイダホ州83703，ボイス, ノース・ウィストラー・レーン・3410，ア パートメント・302 (72)発明者 ソウデン，アンソニー イギリス国ブリストル・ビーエス８・４ピ ージー，クリフトン，コーンワリス・グロ ーブ，コーンワリス・ハウス・18 (72)発明者 ウィリアムス，リチャード，デイビッド イギリス国ブリストル・ビーエス32・０デ ィーイー，ブラッドレイ・ストーク，リ ム・クリン・ガーデンズ・13 Ｆターム(参考） 5B009 NA03 NA06 NE01 NE03 RC14 VC03 5B021 AA01 AA02 BB06 LB06

Claims (16)

【特許請求の範囲】
1. 【請求項１】 情報処理機器間の通信用のドキュメントの電子的表現に対するフォーマットで
   あって、ドキュメント部を表現するための基本ユニットは両面シートとしてであ
   り、 そのドキュメント部に含まれる情報は、その各両面シートの１面または両面に
   対する関係により定義されるフォーマット。
2. 【請求項２】 ドキュメントは、コンテナとして表され、コンテナは、両面シートの形態で１
   つまたは複数のドキュメント部を含む、請求項１のフォーマット。
3. 【請求項３】 コンテナの１タイプは、両面シートである、請求項２のフォーマット。
4. 【請求項４】 コンテナの１タイプは、１つまたは複数の両面シートを含む３次元構造である
   、請求項２のフォーマット。
5. 【請求項５】 １つまたは複数の両面シートを含む３次元構造の形態のドキュメントは、その
   ドキュメントの両面シートの３次元での操作を決定する情報を含む、請求項４の
   フォーマット。
6. 【請求項６】 前記操作は、３次元構造の軸を中心とする回転を含む、請求項５のフォーマッ
   ト。
7. 【請求項７】 両面シートの１面は、別の両面シートに対する接着というプロパティを有する
   ことが可能である、請求項１のフォーマット。
8. 【請求項８】 前記接着は、取外し可能な接着である、請求項７のフォーマット。
9. 【請求項９】 両面シートの不透明度は、選択可能な特質である、請求項１のフォーマット。
10. 【請求項１０】 両面シートのカラーは、選択可能な特質である、請求項１のフォーマット。
11. 【請求項１１】 両面シートに取付けられる１個の情報について、取付けの固定位置が決定され
    る、請求項１のフォーマット。
12. 【請求項１２】 両面シートに取付けられる１個の情報に対し、情報を含むドキュメントを受信
    する情報処理機器によって可変の取付け位置が決定される、請求項１のフォーマ
    ット。
13. 【請求項１３】 請求項１から１２のいずれか１項に記載のフォーマットで表されるドキュメン
    トを送信または受信するよう適合されている情報処理デバイス。
14. 【請求項１４】 ドキュメントを印刷するための手段を含む、請求項１３の情報処理デバイス。
15. 【請求項１５】 ドキュメントを表示するよう適合されている、請求項１３の情報処理デバイス
    。
16. 【請求項１６】 ドキュメントを生成または編集するよう適合されている、請求項１３の情報処
    理デバイス。