JPH10304013A - 情報伝送方法 - Google Patents

情報伝送方法

Info

Publication number
JPH10304013A
JPH10304013A JP10115918A JP11591898A JPH10304013A JP H10304013 A JPH10304013 A JP H10304013A JP 10115918 A JP10115918 A JP 10115918A JP 11591898 A JP11591898 A JP 11591898A JP H10304013 A JPH10304013 A JP H10304013A
Authority
JP
Japan
Prior art keywords
message
interface
request
information
child
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP10115918A
Other languages
English (en)
Inventor
Peter Michael Williams
ペーター・マイケル・ウィリアムズ
Patrick Simon Arnold
パトリック・サイモン・アーノルド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
HP Inc
Original Assignee
Hewlett Packard Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GBGB9707551.9A external-priority patent/GB9707551D0/en
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Publication of JPH10304013A publication Critical patent/JPH10304013A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management

Abstract

(57)【要約】 【課題】 情報処理デバイス間での柔軟な情報伝送を簡
単かつ効率的に行うことを可能とする情報伝送方法を提
供する。 【解決手段】 プリンタ、ＰＣ、スキャナ等の情報処理
デバイスをネットワーク、ネットワーク接続手段によっ
て接続した構成における情報伝送において、各デバイス
間で送信される情報伝送が命令セット中の１または複数
の対話を含む。対話はデバイスにおいて実行される情報
の処理機能に依存しない構成を有する。伝送は第１のデ
バイスの内的状態を表す界面を第１デバイスおよび第２
デバイス間で共有するものであり、界面にはデータおよ
びフォーマット・セットが含まれ、さらに命令セット中
のどの対話に第１のデバイスが適応するかを定義するプ
ロパティ・セットが含まれる。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】この発明は、デバイス間の対
話(インタラクション：通信、対話、情報授受)に関する
方法および装置に関する。さらに詳細には、デバイス間
での情報の受け渡しに関するものである。
【０００２】
【従来の技術】デバイス間での情報の効率的かつ正確な
受け渡しに対する要請はより高まっている。電子機器間
における通信、例えばスキャナとプリンタ、記憶装置と
表示装置、カムコーダーとテレビジョンセット等の通信
においてはアプリケーション固有のプロトコルが必要と
なっている。最初の２つのケースでは、パーソナル・コ
ンピュータ等の計算機装置が通信を調停するのが一般的
であろう。パーソナル・コンピュータはこれらの通信を
実行するために各電子機器（一般的にはパーソナルコン
ピュータの周辺機器である）に固有のドライバを必要と
する。
【０００３】物理的な環境において、物理的デバイスと
の対話は、特別のプロトコルを必要としない。小さいセ
ットの包括的命令が使用され、これらの対話の効果は対
話を行ったデバイスによって判断される。例えば、ユー
ザと電話あるいはコピー装置との対話は、典型的には基
本的に同じであり、所定のボタンを押すことによる対話
である。電話の場合、これは遠隔の電話および開放型の
通信チャンネルとの接続を確立する。一方、コピー装置
の場合は、イメージの再生をもたらす。いずれの場合も
基本的な対話（ボタンを押す）は同一であるが、もたら
す結果はまったく異なる。
【０００４】
【発明が解決しようとする課題】この発明は、デバイス
間での情報の受け渡しを物理的世界と同様に簡単にかつ
効率的に行うことを目的とする。特に、この発明は包括
的命令（generic instruction）によって豊富かつ効率
的な情報伝達を達成することを目的とする。
【０００５】
【課題を解決するための手段】従って、この発明の第１
の側面においては、情報取り扱い装置（デバイス）間で
の情報通信のための手段を有し、２つまたはそれ以上の
情報取り扱い装置において情報を伝達する方法を提供す
る。情報の各伝送は対話セット中の１つまたは複数の対
話によって構成され、対話セット中のいずれの対話も、
情報取り扱い装置によって情報に対して実行される機能
に依存するものではないように構成される。
【０００６】この発明は情報のそれぞれの伝送が第１デ
バイスおよび１つまたは複数の第２デバイス間の界面
（ｓｕｒｆａｃｅ）の共有に関係する場合に特に有効と
なる。ここで界面とは、第１のデバイスの内的状態を表
す。好ましくは、各界面はデータおよびフォーマットセ
ットを含む。データは、第１デバイスによって供給され
るデータである。さらに、プロパティセットを含む。プ
ロパティセットは、対話セット中のいずれの対話に対し
て第１のデバイスが適応するかを定義するものである。
【０００７】好ましくは、対話セットは、第１デバイス
の界面と、１以上の第２デバイスの対応界面との間の内
容転送に関する対話、および第１デバイスの界面に対応
する１以上の第２デバイス中の界面の削除および変更に
関する対話を含む。
【０００８】本発明の１つの有用な特徴は、各デバイス
が識別界面（identity surface）として認識される界
面を持つことであり、識別界面は、そのデバイスに関す
る情報を有し、デバイス間での情報交換セッションが確
立された場合に、この界面の交換を可能とする手段が提
供される。特定のデバイスにおけるこの構成の有用な特
徴は、他のデバイスの識別界面からの情報記憶手段のデ
ィレクトリ手段を有することである。
【０００９】さらに、デバイス機能に従った情報処理の
可能なジョブ受領デバイスがジョブ送出デバイスからの
情報を受領し処理するように構成されたジョブ受領界面
を持つようにすることも有益である。さらに、デバイス
機能に従った情報処理の可能なジョブ受領デバイスが状
況指示界面を有し、そのジョブ受領デバイスに対してジ
ョブを送出する可能性のある他のデバイスと状況指示界
面を共有するように構成することも有益である。
【００１０】第２の側面として、この発明は情報取り扱
い装置（デバイス）間の通信のためのプロトコルを提供
する。このプロトコルは、対話セット中の対話を含
み、、対話セット中のいずれの対話も、情報取り扱い装
置によって情報に対して実行される機能に依存するもの
ではない。
【００１１】この発明の構成は、デバイスに依存しない
情報交換を可能とする。プロトコルは、２つのデバイス
の接続、情報交換、データタイプの交渉、オペレーショ
ンについての状況の提供等を可能とする。この発明は、
プロトコル非依存のプラットフォームの提供を可能とす
るものであり、従って、機能に無関係に他のデバイスと
の接続を必要とするどのようなデバイス中にも構成可能
である。この発明は、通信機器および描写機器（例えば
ファックス、プリンタ、ホワイトボード）から、サーモ
スタット、洗濯機、トースターのような家庭用機器に至
るまで適用可能である。この発明は、アプリケーション
に対応する転送タイプに依存しないプロトコルを提供
し、どのような双方向転送にも適用できる。この発明の
実施例は、各機器間の通信用に単一のプロトコルの適用
が可能であり、同様の情報タイプを取り扱い可能なデバ
イスがいくつかのフォームで情報を伝達することを保証
する。
【００１２】この発明の適切な使用は、現存するデバイ
スおよび将来のデバイスで情報の交換を保証する。お互
いについての知識がなくても複数のデバイスが通信する
ことができ、この場合、ホスト対周辺装置の環境の場合
と同様に予めプログラムする要素は必要とされない。さ
らなる長所は、システム機器が独自に（例えば、プリン
タをパーソナル・コンピュータのドライバの創作を考慮
せずに開発できる）開発可能である。さらに、この発明
の好ましい態様においては、製品特性は開発者によって
規定されプロトコルによって規定されるのではない。プ
ロトコルは、情報が交換されるパイプにすぎず、デバイ
スあるいは処理についての知識を持たない。
【００１３】
【発明の実施の形態】この発明の具体的な実施例につい
て以下、添付した図面を参照しながら説明する。
【００１４】この発明は、ヒューレット−パッカード
（Hewlett-Packard Company）のジェットセンド（JetSe
nd）アーキテクチャとして具体化されている。このアー
キテクチャの紹介についてはhttp://www.jetsend.hp.co
m/のワールド・ワイド・ウエブ（World Wide Web）に提
供されており、全ての開示は、ＨＰジェットセンド通信
技術プロトコル・スペシフィケーション（HP JetSend C
ommunication Technology Protocol Specification）に
提供されており、ヒューレットパッカードから取得可能
である。
【００１５】以下、ジェットセンド・アーキテクチャの
基本的な要素について説明する。個々の要素については
この発明の説明および効果の説明に必要な度合いに応じ
て、後段で個々に詳細に説明する。以下の説明における
最適なおよび望まれる特性という表現は、ジェットセン
ドアーキテクチャにおける最適なおよび望まれる特性を
意味し、この発明における最適なおよび望まれる特性を
意味するものではない。
【００１６】ジェットセンド・アーキテクチャの基本に
は、どのようにシステムが動作するかを定義する４つの
原則があり、これらを以下説明する。
【００１７】ピア・トゥ・ピア対話 ネットワーク転送がこれを許容する場合は、デバイスは
他のデバイスを直接アドレスすることが可能でなければ
ならない。デバイスは２つの非ＰＣデバイス間の情報交
換を可能とするＰＣまたは他の中間デバイスの存在を要
求するものであってはならない。ユーザは最低限の構成
によって接続し、特別な（ad hoc）情報転送を実行する
ことができる。
【００１８】デバイスおよびデバイスの型のタイプ独立
性 他のデバイスに関するデバイス特性情報がいずれのデバ
イスにも予めプログラムされることはない。デバイス
は、対応する特定のデバイスまたはそのセットに応じた
異なる動作を必要としない。ジェットセンド・アーキテ
クチャにおいては、デバイスは情報伝達あるいは状況観
察等の共通処理を実行し、これらはデバイス特性とは無
関係に行われる。この構成によって、２つのジェットセ
ンド許容デバイスは、デバイスまたはデバイスの型に特
有のドライバを用いずに対話可能となる。
【００１９】交渉(negotiation) デバイスは、送信側および受信側がサポートする最上級
共通項（デノミネータ）へのデータ・エンコーディング
の交渉を行う。すべての送信者、受信者が使用する各デ
ータタイプには、データタイプがサポートするデフォル
ト（省略時）エンコーディングが必要である。交渉能力
は、デバイスがハイエンドおよび知的財産権（機密）が
らみのデータタイプをも実行可能とすることを保証す
る。また、デフォルト・エンコーディングは、意味ある
データ交換が常に発生することを保証する。交渉は、柔
軟性がありかつ開放的であるべきである。
【００２０】コンシステンシイ(一貫性) デバイスが制御、転送データを交換するか、ステータス
情報を交換するか、他の形式の情報を転送するかに関わ
らず同じプロトコルが使用される。
【００２１】図４８は、ジェットセンド・デバイスが動
作する環境を示した図である。プリンタ３４２、パーソ
ナルコンピュータ３４３、およびスキャナ３４４のよう
なデバイスを接続するある種のネットワーク３４１が存
在する。各デバイスはある種のプロセッサ３４６を有
し、接続手段３４５によって、ネットワーク３４１とイ
ンタフェース可能となっている。各デバイスは、所定の
処理能力すなわち、ジェットセンドの処理に必要な能力
を備えていなければならない。
【００２２】ジェットセンド中のデバイス間通信の基本
は、界面対話モデルである。界面はデバイスの有する内
的状況の所定の特徴表現である。この表現は統一された
ものであって、デバイスの実行する機能によって決定さ
れるものではない。この構成における界面は物理的オブ
ジェクト（例えば電話またはブリックのような）によっ
て提供される界面に類似するものである。オブジェクト
の処理の手法は、オブジェクトの機能部がどのように界
面と接続しているかによって決定されるが、界面そのも
のは機能に関わらず単純な統一的手法によって表現可能
であり、オブジェクトが他の物理的オブジェクトに接続
可能な媒体を供給する。物理的オブジェクト間の接続形
態はいずれのデバイス機能にも依存しない。ジェットセ
ンドにおいては、界面は、情報交換における基本的ユニ
ットであり、イメージ、ドキュメント、ステータス・メ
ッセージ、デバイス・ラベル等、すべてが１つまたは１
つ以上の界面を介して転送される。界面は、いくつかの
要素、すなわちデスクリプション（記述）、コンテント
（内容）、プロパティ（特性）、クラス等を有する。こ
れらについては後段で詳述する。
【００２３】界面対話モデルは、界面の生成、共有、変
更、削除のメカニズムを定義する。共通処理の限定され
た数の処理が、ジェットセンド対話プロトコル（ＪＩ
Ｐ）によって定義されるメッセージを用いて界面におい
て実行可能である。これらについては、さらに詳述す
る。
【００２４】界面のオリジナル・コピーはここでは表現
（expression）と呼ぶ。どの界面対話も１つの表現を有
する。他のデバイスト共有する情報を持つデバイスは、
情報を表現する１つまたは複数の表現を生成する。
【００２５】界面表現は、他のデバイスにインプレスさ
れる。これは、界面の共有として知られる界面のインプ
レッション（impression）を形成する。インプレッショ
ンは、他のデバイスの表現のコピーであり、デバイス間
での接続が維持され、インプレッションが対応表現にお
ける最新のものに維持される。典型的には、２つのデバ
イスは、いくつかの界面を所定時間シェアする。界面
は、ジョブ・エレメント、各デバイスからのステータス
情報、セキュリティ情報等を示す。
【００２６】図１は、あるデバイス（デバイスＡ）の表
現１１が他のデバイス（デバイスＢ）に共有され、新た
なインプレッション１２が生成される様子を示した図で
ある。同じ表現が複数回複数のデバイスにインプレス
（刻印）される。同じ界面表現の多数のインプレッショ
ンが生成される。表現が変更、削除されると、すべての
インプレッションに通知がなされる。これをここでは、
変更伝播（change propagation）と呼ぶ。
【００２７】変更伝播はステータス情報のごときアーキ
テクチャ中のデバイスにおいて実行される動的特性への
関与を可能とする。例えば、ステータス情報を持つデバ
イスが複数の接続デバイスに刻印されたステータス・ス
トリングを含む界面表現を生成する。ステータスを有す
るデバイスは、ステータスに依存する界面を変更する。
ステータス界面のインプレッションを有するすべてのジ
ェットセンド・デバイスは現在のステータスに関する更
新メッセージを受領する。この機能はアーキテクチャ中
に構築可能であり、その使用はデバイス設計者によるオ
プションである。
【００２８】処理実行の見地からは、表現は所定の界面
（そのネーム、記述、内容、遠隔のデバイスに生成され
たインプレッションのセット）を保持したステートによ
って定義される。これについては後でプロトコルの見地
から説明され、表現は、ＪＩＰメッセージの交換に使用
される界面によって定義されることが説明される。
【００２９】界面は、界面の表現、および界面に含まれ
る内容（content）を有する。識別はジェットセンドの
基本であり、本発明の特質の重要な点である。これは、
内容交渉のメカニズムを提供するからである。
【００３０】界面記述は、界面に関連する情報（この情
報は界面内容データとして供給される）が他のデバイス
とシェア可能な形態のフルレンジを確立する。記述は、
データフォーマット階層構造を有し、各々がデータフォ
ーマット特性（属性として定義され、詳細は後述する）
を定義する複数のノードによって構成されるツリー(木
構造)によって表現される。界面に関連する情報の特定
のデータ・フォーマットは、このツリー構造の根（ｒｏ
ｏｔ）ノードからターミナル・ノード（ツリーのリーフ
(葉)・ノード）へたどる経路である。このような特定の
パスは、交渉・プロセスによってたどられる。交渉・プ
ロセスは、他のデバイスとの界面記述の共有（シェア）
または界面記述の一部の共有を含むプロセスである。他
のデバイスは、さらに所望のオプションを選択（一般的
にこのオプションは、受信デバイスが自らの機能をもっ
とも有効に実施可能となるように選択されるものである
が、各デバイスの設計者において必要となる事項であ
る）し、特定のパス、および特定のデータフォーマット
が選択されるまで続行される。
【００３１】界面内容は界面に関する情報であり、上述
した交渉によって決定されるフォーマットで提供され
る。内容データは界面記述によって具体化されるデータ
・フォーマット階層構造によって示されるすべてのフォ
ーマットで提供され得るが、特定の界面対話には一般的
に１つのフォーマットのみが使用可能なフォーマットと
して提供される。１つのインプレッションに対して１つ
以上のフォーマットでの情報提供の可能性を有してい
る。これは記憶装置からの情報の引き出しにおいてその
有用性が立証される。たとえば最初、低解像度のわずか
な情報としてイメージが提供され、その後、イメージが
所望のものである確認の後、インプレッションの変更な
しに高解像度のフルサイズイメージが提供される。しか
しながらこの状況において、さらなる内容の要求が頻繁
に行われる。内容データは交渉の完了以前に存在する必
要はない。データフォーマット階層構造のいくつかのあ
るいはすべての選択において、データはフォーマット選
択が判明した後に生成される。あるいは、いくつかの選
択において、内容データは、データフォーマット階層構
造の特定のポイントを指示する記述とともに、交渉プロ
セスの一部として直接供給される（このフォーマット選
択では独立した内容の提供ステップは存在しない）。こ
れはインラインにおける内容データ提供と称される。
【００３２】上述したように、記述は、オリジナル界面
インプレッションに沿って送付される。しかし、一般的
な場合、内容は分離して要求される。たとえば、ラスタ
イメージを表現している界面は、イメージのカラースペ
ース、解像度、圧縮に関する選択の界面記述を定義して
いる場合がある。インプレッションの受信側は利用可能
な選択から受信側の望ましいエンコーディングを特定す
る実際のピクセルデータ（内容）を要求する。
【００３３】界面記述は、他の界面に対する参照（refe
rence:リフェランス）情報を有する。これらの界面はサ
ブ界面（またはチャイルド(子)界面）として知られる。
これらはペアレント(親)界面の所有者から別々に要求さ
れなければならない。各サブ界面は、ペアレントとは無
関係の独自の記述および内容を有する。たとえば、ドキ
ュメントは、各々が各ページを表す多重界面としてエン
コードされる。ドキュメントそれ自体は、これらのペー
ジ界面に対する参照を含む界面として示される。
【００３４】ドキュメントは、単一ユニット中に保持さ
れるページの集合体等よりも広い意味を有する。ここで
は、ドキュメントは１つのデバイスから他のデバイスで
の処理のために供給される形態の情報の集合体を意味す
る。ジェットセンドの特定の形態では、ドキュメントは
１つまたは１つ以上の界面を有し、各界面は他のすべて
の界面個々と直接単一のペアレント−チャイルド関係に
よって、または間接的にペアレント―チャイルド、ある
いはチャイルド―ペアレント関係のチェインを介して接
続されている。
【００３５】界面リフェランスまたは界面ネームはＵＲ
ＬのごときＡＳＣＩＩストリングである。すべての界面
は、そのネームによって識別され、特定のクラスに属す
る。すべての界面はクラスを有する。クラスは界面が使
用される目的を示す。ここでの例においては、各界面は
１つの、１つだけのクラスを有する。界面のクラスはセ
ルフ界面、イン界面、状況・界面、およびアドレス・界
面を含む。特定のクラスの界面の使用に関しては、特別
なルールが存在、あるいは案出される。クラスは特定の
ポリシーのコンテキストで使用される。たとえば、ジョ
ブ・ポリシーは、特定の界面クラスを利用する。これは
イン界面であり、ジョブ処理デバイスにジョブを供給す
る手段である。プリンタはイン界面を有しており、イン
界面上にインプレスされた界面は新規なジョブとして扱
われプリントされる。ＰＣ、カメラ、あるいは他の伝送
デバイスは、このイン界面に対して界面をインプレスす
る。特定の界面クラスが所定のポリシーの実行において
基本的な役割を果たす場合、そのクラスの界面はそのポ
リシーにおける周知界面（well known surface）と称さ
れる。
【００３６】ポリシー、または対話ポリシーは特定のタ
スクを実行する汎用界面対話の使用のための協定セット
である。特定のタスクにおけるポリシー使用の利点は、
その特定のタスクを実行するすべてのジェットセンド・
デバイス、あるいは実行する他の必要なデバイスにおい
て対話を成功させ、その特定のタスクを実行するための
他のデバイスとの予測可能な形態で対話を実行可能とす
ることである。これは、異なる界面クラスを使用して実
行する他のジェットセンド・デバイスに対してオープン
ではない異なるやり方でタスクを実行する２つのデバイ
スの可能性を排除するものではない。しかし、このよう
なデバイスが関連ジェットセンド・ポリシーをサポート
し、他のジェットセンド・デバイスとともにこのタスク
を実行することが可能なように構成することが好まし
い。
【００３７】２つのデバイス間におけるすべての界面対
話は、以下のメッセージとともに行われる。
【００３８】＊界面要求メッセージ（SurfaceRequestMs
g）：特定の名前（ネーム）（およびクラス）を有する
界面の要求 ＊界面メッセージ（SurfaceMsg）：界面のインプレス
（記述の送付） ＊内容要求メッセージ及び内容応答メッセージ（Conten
tRequestMsg and ContentReplyMsg）：界面内容の転送 ＊デスクリプション(記述)要求メッセージ及びデスクリ
プション応答メッセージ（DescriptionRequestMsg and
DescriptionRplyMsg）：追加記述の転送 ＊界面変更メッセージ（SurfaceChangeMsg）：界面変更
の通知および要求 ＊界面開放メッセージ（SurfaceReleaseMsg）：インプ
レッションおよび表現間の接続関係を解除
【００３９】これらのメッセージのフォーマットおよび
実行については後段で説明する。
【００４０】電気マテリアルの省略表記であるｅ−マテ
リアルは、それを介して界面が表記され共有される情報
によって形成されるフォームである。これは記述（デス
クリプション）および内容（content）を有する。記述
は、フォーマット選択の階層構造を示し、これに基づい
て関連内容データが供給される。内容は、界面自体に関
連するデータである。記述は、データの形態を示すもの
であり、内容は情報そのものであり、送信デバイスおよ
び受信デバイスにとって最適な形態が選択され供給され
る。この選択の存在がｅ−マテリアルのキーであり、こ
の選択メカニズムついて以下で説明する。
【００４１】界面対話およびｅ−マテリアルはジェット
センド・アーキテクチュアの心臓部であり、この発明の
特徴は界面対話とｅ−マテリアルの協業において、より
明確になる。２つのコンセプトは別々のものであるが密
接な関係がある。界面対話は、ｅ−マテリアルとしてコ
ード化された情報の交換のためのプロトコルである。ジ
ェットセンド・デバイスにおいて、データ・タイプの交
渉を行い、デバイス非依存型の情報交換を可能とするの
は界面とｅ−マテリアルの組み合わせによるものであ
る。
【００４２】Ｅ−マテリアルはファイル・フォーマット
ではない。Ｅ−マテリアルはデバイスが交換するデータ
のフォーマットを定義するが、デバイスのデータ処理形
態や記憶形態を定義するものではない。ｅ−マテリアル
を使用するデバイスは、そのデバイス特定の方法で実行
する。例えば、受信デバイスがプリンタである場合は、
受信デバイスがＰＣである場合とは異なる処理を行う。
ＰＣはｅ−マテリアルをある種のファイルフォーマット
とするかもしれないが、プリンタはそれをＰＣＬあるい
はポストスクリプト（商標）、またはページにおけるド
ット表現に変換するであろう。同様に、ｅ−マテリアル
を生成するデバイスにおいてもそのデバイスに特有の手
法を実行する。
【００４３】ｅ−マテリアル・タイプのもっとも基本的
な部分はエンコーディングである。エンコーディング
は、情報が存在し得る形態を表現する基本フォーム（fu
ndamental form）である。“基本フォーム”の概念は各
種のエンコーディング定義によって表現可能である。
【００４４】ｖテキストは書かれたテキスト形態におけ
る情報表現に関する。ＡＳＣＩＩストリングあるいは、
矩形平面を埋める（フォントあるいはスペース情報は持
たない）ユニコード（Unicode）テキストである。シン
プル・テキスト・エンコーディングがステータス情報に
主に用いられるがページのマークにも用いられる。シン
ボル（記号）セットは交渉可能である。
【００４５】ｖイメージは、グラフィック・イメージ形
態における表現に関する。エンコーディングは、ラスタ
・イメージに関し、カラースペース、ピクセル深度、解
像度、ピクセル・エンコーディング、圧縮等の質に関し
ては交渉の可能性を有している。
【００４６】ｖ平面は、平面オブジェクトに関する情報
の表現を示す。１枚の紙シートの概念であり、２つの側
面を有する平面オブジェクトに関する。詳細には、この
エンコーディングは背景色、前面および背面のチャイル
ド・エレメントの順序づけられた層を持つ２次元矩形平
面（プレーン）を供給する。ページはイメージやページ
のような他のエンコーディングを伴う平面である。
【００４７】ｖファイルは、バイナリ・ファイル形態に
おける情報表記に関する。バイナリ・ファイルはアプリ
ケーション・スペシフィック・フオーマット、エグゼキ
ュータブル等の文書を含む。ファイル・ネーム、マイム
・タイプ、アイコンはデータと関連（アソシエート）づ
けられる。マイム・タイプは交渉可能である。
【００４８】ｖアソシエイションは、１つあるいはそれ
以上のフォーマット（各々は独自の踏み合化により表現
される）で表現される情報アセンブリの形態における情
報表記に関する。基本的に、アソシエーションはチャイ
ルド・エレメントの整列された列である。いわゆる文書
はページのアソシエーションとして表現可能であろう。
【００４９】さらなるエンコーディングがこの発明に関
連して案出可能であり、現存のジェットセンド・スペッ
クには示されないデバイス・タイプや機能に適用するこ
とが可能であろう。例えば、ボイスあるいはサウンド・
エンコーディングが人間の声やその他一般的な音の形態
の情報の表現として可能であろう。ここで使用される
“エンコーディング”は基本フォーマット・タイプを意
味するのみではなく、あらゆる特定のデータフォーマッ
ト階層構造（例えば、特定の交渉プロセスの終端におい
て到達するもの）も意味する。このような“エンコーデ
ィング”の区別的使用は文脈において識別可能と思われ
る。
【００５０】各エンコーディング（ｖイメージ、ｖテキ
スト他）において、デフォルトのエンコーディングが存
在する。このことは、特定のタイプ（例えば、イメージ
を表現可能なデバイスとしてパーソナル・コンピュー
タ、プリンタ、スキャナがあるがマイクロフォンは含ま
れない）のデータ交換が可能なすべてのデバイスはある
フォームにおいてデータ交換の可能性を保証する。イメ
ージの場合、１つの実施形態における処理の基本的なエ
ンコーディングはｖＩｍａｇｅ．ｖＧｒａｙ．１．（３
００，３００）．ｖＲＬＥであり、イメージを扱うこと
の可能なすべてのデバイスはこのフォーマットにおいて
データ交換が可能である。
【００５１】デフォルトのエンコーディングはデバイス
において最小限不可欠な機能セットの使用を可能とする
が、一般的にはデータ交換フォーマットとしてさらに適
切なフォーマットが存在するであろう。したがって、デ
バイスにおける機能をより高めることが可能なデータ交
換スタンダード・フォーマットを持つことが好ましい。
このエンコーディングはベース・エンコーディングと呼
ばれる。ベース・エンコーディングは、すべてのデバイ
スにおいてサポートされるものではないが、十分な機能
を有するすべてのデバイスにおいて、ベース・エンコー
ディングによるデータ交換が可能となることが期待され
る。
【００５２】属性は、ｅ−マテリアルの記述中に定義さ
れるｅ−マテリアルの一部の特徴である（または交渉・
プロセスの完了の後にｅ−マテリアルの一部に定義され
る）。基本的に、ｅ−マテリアル記述中に示されるデー
タフォーマット階層構造中の各ノードが属性を示す。ノ
ードおよび属性の等価な性質から、“属性レベル”の概
念が引き出される。基本的に、属性レベルは、データ・
フォーマット階層構造のルート・ノードから等しい距離
にあるすべてのノードにおいて共有される。属性は、ｅ
−マテリアル・内容に与えられる品質（quality）を含
む。またその品質に対する選択および値（バリュー（va
lue））を有する。これは、イメージが供給されるサイ
ズとか、テキストが提供される言語から（平面上に描写
（レンダー：render）されるエレメントの順のような）
より不明確な品質まであり、選択あるいは値自体がさら
に属性（選択あるいは値を必要にとする品質）を示して
もよい。品質それ自体は、属性ネーム（“属性”と記述
される場合もある）によって示される。また、選択、値
は属性・値（単に値と表記される場合もある)によって
示される。したがって、データ・フォーマット階層構造
のノードは特定の品質または、特定の品質における特定
の選択、または選択レンジを提供するものと考えること
ができる。属性ネームはキーワードであり、選択または
値として使用可能なものが予め決定される。したがっ
て、所定のキーワードに対して与えられた界面記述にお
けるオプションは、この予め決定された範囲から選択し
なければならない。異なるエンコーディングにおいて、
所定の属性が必要となり、他はオプションとなり、さら
に他のものは全く使用されない。
【００５３】このようにｅ−マテリアルは、界面のエン
コーディング選択を階層構造に構成されたいくつかの属
性・値（バリュー）の対によって示す。すべての界面記
述は、属性、ｖＥｎｃｏｄｉｎｇ（ｖエンコーディン
グ）を含む（すべての属性および値のネームには小文字
“ｖ”が付されている）。上述のように、これは界面の
全体的エンコーディングを決定する。例えば、ラスタイ
メージの場合、ｖエンコーディングは、ｖイメージであ
る。また、これは、界面の所有者が１つ以上のエンコー
ディングにおける内容を供給する選択リストとすること
もできる。
【００５４】各エンコーディングは、これに関連するい
くつかの標準属性・値の対を有する。例えば、ｖイメー
ジは解像度、ピクセルサイズ、カラースペース、圧縮等
の属性を定義する。これらの属性のいくつかはさらに選
択（choice）を含むことができる。実際、界面の所有者
は界面記述の属性にオプションを加えることによって複
雑な選択を表現できる。
【００５５】属性は階層構造中にアレンジされ、先行す
る選択に依存してある属性に対して異なる選択が可能で
ある。例えば、界面においてイメージ・エンコーディン
グが要請されると、カラースペースとしてＳＲＧＢが選
択された場合は、ＪＰＥＧまたはＪＰＥＧ−ＬＳの選択
を含み、モノクロムがカラースペースである場合は、Ｒ
ＬＥまたはグループ３（Ｇｒｏｕｐ３）ファックス圧縮
となる。
【００５６】エンコーディング選択をリストした界面記
述は記述テーブルと呼ばれる表形式に記録される。記述
テーブルのサンプルは、明細書の後段に示す。デバイス
が界面記述を受け取ると、その界面におけるエンコーデ
ィングの選択を決定する。その決定がなされると、選択
は、界面の所有者に実際の内容データの要求とともに転
送される。
【００５７】記述テーブルは、属性を３つの欄、レベ
ル、属性、値（バリュー）としてリストする。レベルは
属性が与えられる他の属性の値を特定するものである。
例えば、値（１５０，１５０）を有する属性、ｖ解像度
（ｖＲｅｓｏｌｕｔｉｏｎ）は、その同じ記述中にリス
トされた先行する属性としてｖイメージ（ｖＩｍａｇ
ｅ．ｖＳＲＧＢ．２４）が選択されている場合に付与さ
れる。
【００５８】すべてのエンコーディングは、ｖ言語（ｖ
Ｌａｎｇｕａｇｅ）属性との交渉が可能である。どの界
面もローカリゼーションの目的のため、多言語において
提供される。各言語において、エンコーディングにおけ
る異なる選択が設定される。例えば、ある言語にはテキ
ストを、他言語にはイメージを提供することが可能であ
る。
【００５９】ここで述べるジェットセンド・スペック
は、静止２次元ビジュアル情報をモデルとしている。し
たがって実際の用紙上に出力可能な情報表現に有効なエ
ンコーディングが示される。Ｅ−マテリアルはこの形式
の情報に限定されず、この発明に基づいて、デバイス間
で交換されるどのような情報形式にも対応可能な新しい
エンコーディングが実現可能である。所定のルールが守
られれば占有的なエンコーディングを創案することも可
能である。このことは、デバイスのグループ間での効率
的対話を可能とする。
【００６０】図２は２ページの文書を示している。視覚
的表現２１を左側に、またその界面表現を右側に示して
いる。このケースでは、各々がエンコーディングを有す
る７つの界面によって示される。矩形は他の界面への参
照を有する界面である。トップ・レベル界面２２は、ド
キュメントの２ページの各々を参照する結合（associat
ion）である。各ページは平面（プレーン）エンコーデ
ィング２３，２４として示される。各平面は、ページに
ついての情報を表す界面への２つの参照をもつ。第１平
面２３は、イメージ界面（Ｉｍｇ）２５およびテキスト
界面（Ｔｅｘｔ）２６をポイントしている。第２平面２
４は、２つのイメージ界面（Ｉｍｇ）２７、２８をポイ
ントする。
【００６１】各イメージ界面は、各々独自に交渉し、異
なるエンコーディング要請を有する。これは、このドキ
ュメントを界面およびｅ−マテリアルを使用して表現す
る１つの例である。さらに、ページ上の各要素を分割す
ることも可能である。例えば３つのイメージとテキスト
・セグメント等である。さらに別の可能性は、１つがす
べてのページをカバーする大きなイメージ領域によって
構成される２つの平面として把握することもできる。情
報をどのようにエンコードするかはドキュメントの所有
者の選択に依存する。
【００６２】上述したように、このアーキテクチュアに
導入されているのはデフォルト・エンコーディングを基
本とするものである。各エンコーディングにおいて、す
べてのジェットセンド・デバイスがサポートする属性の
デフォルトのセットが用意されている。デフォルト・エ
ンコーディングは、同一クラスの情報を交換するデバイ
スのどのような組み合わせにおいても情報交換を可能と
する。また、これは互換性も保証する。デフォルト形式
をサポートする限り、新しいデバイスによってより効果
的なエンコーディングが可能となる。
【００６３】すべてのデバイスはアソシエーション・エ
ンコーディングをサポートすることが要求される。これ
は他のエンコーディングの界面のコンテナである。ま
た、２次元静止情報を扱うすべてのデバイスは、平面エ
ンコーディングをサポートすることが要請される。
【００６４】イメージ・デバイスのデフォルトエンコー
ディングは３００×３００ｄｐｉ、モノクロム、ＲＬＥ
圧縮ラスタである。これは、すべてのジェットセンドイ
メージ・デバイス（プリンタ、スキャナ、コピー、カメ
ラ、ホワイトボード他）がこのエンコーディングの送信
受信が可能でなければならないことを意味する。テキス
トおよびファイル・エンコーディングは、これらのデバ
イスにおけるオプショナル事項となる。他のクラスのデ
ータをサポートするデバイスが導入されても、このデー
タタイプのデフォルトエンコーディングが導入される。
これらにはオーディオ、ビデオのようなデータタイプが
ある。デフォルトは所定のエンコーディングにおける最
低限の共通項をもつ最大公約数的なものである。
【００６５】上述したように、デフォルト・エンコーデ
ィングに加えて、ベース・エンコーディングはオプショ
ナルであるが有益な特徴を持つものである。これらは高
機能のデバイスにおいて良好な結果をもたらすハイレベ
ルのエンコーディングを可能とする。例えば、カラー・
イメージ・デバイスには、デフォルト・エンコーディン
グに加えて、これらのデバイスがサポートするカラーイ
メージのためのベース・エンコーディングがある。デフ
ォルト・エンコーディングが提供される限り、他の付加
的エンコーディングを提供することはデバイスの自由で
ある。特定のデバイスにおいて最も適したベース・エン
コーディングを実行することにより高レベルのパフォー
マンスおよび品質が提供可能となる。
【００６６】ジェットセンド・プロトコルはデバイスの
型、プラットフォーム、および転送には依存しないよう
にデザインされている。ジェットセンド機器の基本コン
ポーネントの概要について説明する。この明細書中で多
く使用される機器という表現はデバイスという表現より
特定の意味をもって使用される。機器は、与えられたデ
ータを基本的に独自に取り扱い(処理)してその専用機能
を達成する専用の機能を有するデバイスである。従っ
て、例えば、パーソナル・コンピュータの純粋な周辺機
器よりもより広いユーティリテイを有する。機器は、一
般に再プログラミングできず、処理に必要な最低限の構
成を有する。スキャナやプリンタのようなデバイスは、
この発明の実施をサポートするように構成された場合は
機器としての機能も果たすことが望ましい。
【００６７】ジェットセンド機器を構成する３つの主要
な機能がある。デバイス中の転送、ジェットセンド・プ
ロトコル、そしてデバイスの特定のコードである。図３
は、ジェットセンド・アーキテクチュアのコンポーネン
トおよび、それらの互いの論理的な関係を示したもので
ある。各コンポーネントの概要は以下の通りである。各
コンポーネントの詳細は後段で述べる。なお、図３は、
実行ダイアグラムではない。また、プロトコルの関係を
示すもので、ソフトウェア・コンポーネントの関係を示
すものではない。実際の実行手段は同様のコンポーネン
ト、または多重プロトコルを１つのモジュール化した合
成された手段である。
【００６８】ジェットセンド・アーキテクチュアは転送
に依存せず導入可能である。ジェットセンド・デバイス
は、双方向通信構成３６を介する特徴的なアドレッシン
グによって互いに直接アドレスが可能である。転送は信
頼性が重要となる。従って、ＵＤＰのような低信頼性の
転送においては、転送信頼性のためにさらなる転送プロ
トコル層を付加すべきである。ここでは、使用するさら
なるプロトコルをリライアブル・メッセージ・トランス
ポート・プロトコル（ＲＭＴＰ）３７とする。可能な転
送形態は、ＴＣＰ／ＩＰ，ＳＰＸ／ＩＰＸ，ＩｒＤＡ，
ＩＥＥＥ１２８４，ＩＥＥＥ１３９４他である。デバイ
スは１つ以上の転送が可能であり、同じ転送形態による
他のデバイスとの通信が可能である。
【００６９】ジェットセンド機器間の通信は、図３に示
すように多層形態のプロトコルを使用して実行される。
これらは、各プロトコルが他のデバイスにおける等しい
層と通信を実行するネットワーク・システムと同様のも
のである。ジェットセンド・プロトコルを含む層は対話
（インタラクション）ポリシー３５、対話（インタラク
ション）プロトコル３３、セッション・プロトコル３
４、およびＲＭＴＰプロトコル３７である。
【００７０】対話ポリシーは、デバイスが従う各種の典
型的な対話シーケンスを定義する。対話ポリシーは、デ
バイス間のより具体的な情報交換を達成するブロックの
形成に使用される。以下に示す対話ポリシーが定義さ
れ、以下これらについて説明する。
【００７１】・ジョブ・ポリシー：送信側と受信側との
間の文書の送信形態 ・セルフ・ポリシー：ラベル、アイコン、パスワード等
の総括的情報の交換形態 ・ステータス・ポリシー：デバイス及びジョブに関する
状況の付与形態 ・アドレス・ポリシー：新規宛先アドレスをデバイスに
プログラムする形態
【００７２】デバイスは、これらポリシーのいずれかを
実行することを要求されないが、ほとんどのデバイスは
ジョブ・ポリシーを実行する。さらにジェットセンド・
アーキテクチュアにおいて通信における一般的動作を実
現するような他のポリシーも開発可能である。
【００７３】対話プロトコルは、界面に関する情報交換
においてセッション・プロトコルを使用する。ジェット
センド対話プロトコルは、界面記述を要求、転送するメ
ッセージ、界面の内容データを転送するメッセージ、界
面の更新メッセージを含む。Ｅ−マテリアルに関して
は、これは、デバイス間でのデータ・タイプ交渉に関す
るメカニズムを提供する。
【００７４】セッション・プロトコルは、２つのデバイ
ス間のセッション及びチャネル確立のためのメッセージ
を定義する。セッションは、２つのジェットセンド間の
データ転送の確立および終了を管理する。これは、通信
コンテクストの範囲で論理チャネルを生成する。これら
すべての対話は、トランスポート層による転送において
発生する。ＪＳＰはジェットセンドおよび非ジェットセ
ンドデバイス間のゲートウェイで用いられる。
【００７５】チャネルがＵＤＰのような低信頼性の転送
を使用する場合は、ＲＭＴＰがそのチャネルのための信
頼性サービスを提供する。ＲＭＴＰは、信頼の高いシー
ケンスのデリバリ・プロトコルである。ＲＭＴＰは同時
に多くの転送に関する接続を維持することが可能であ
る。
【００７６】デバイス・コードは、ジェットセンド・プ
ロトコルを実際のデバイスに結び付けるに必要なロジッ
クにおいて使用される。図３におけるデバイス・コード
３１はどのデバイスにも存在可能であり、情報の生成お
よび消費の能力を有する。典型的生成デバイスはスキャ
ナ、ＰＣであり、典型的な消費デバイスはプリンタやＰ
Ｃ表示器である。デバイスは、デバイス特有の情報／デ
ータと、ジェットセンド・プロトコルによって使用され
るｅ−マテリアル間の変換能力を有する必要がある。
【００７７】ＪＩＰによって実行される交渉はデータの
特定のクラスに特有のものである。各デバイスは、独自
の最適なデータ・エンコーディングがあり、異なる属性
に関する交渉、異なる選択を行い得る。すべてのデバイ
スは交渉のためにジェットセンド・プロトコルを使用す
る。そのプロセスは、送信側がオファーを行い、受信側
が好ましいエンコーディングを選択し要求する、さらに
送信側が要求を受諾する。デバイス・コードは、ジェッ
トセンド・プロトコルとデバイス動作間の相互作用を行
うコンポーネントのデバイス特有の実行形態を有する。
デバイスが実行する機能には以下のものが含まれる。
【００７８】ユーザインタフェースの実行および制御 ｅ−マテリアル交渉および消費 （好みに応じたｅ−マテリアルエンコーディングの供給
および受け入れｅ−マテリアルの処理） ｅ−マテリアルの生成 エラー通知及び回復
【００７９】図４は、２つのデバイス間でセッションを
確立し、イメージの転送を実行し、セッションを終了す
るまでに２つのデバイス間で交換されるメッセージの変
遷を示した図である。図４に示すメッセージは完全なも
のではなく、主要なもののみを示してある。完全な例は
明細書の後段で示す。すべてのメッセージにはＪＳＰヘ
ッダーがあり、各メッセージは、データチャネルの信頼
性の要請から送信順に受信される。各ＪＳＰヘッダー
は、ＪＳＰメッセージ・タイプ（ＳＹＮ，ＡＳＹＮ，Ｃ
ＳＹＮ，ＣＨＮ等、これらメッセージ・タイプについて
は後述する）を含む。ＣＨＮメッセージは、ＪＩＰヘッ
ダー、および潜在的にＥ−マテリアル・データを含む。
ＪＩＰヘッダーは、界面メッセージ、内容要求メッセー
ジ、内容応答メッセージを有するメッセージ・タイプを
含んでいる。界面メッセージは界面用のｅ−マテリアル
エンコーディング要求を含む。
【００８０】ジェットセンド・セッション・プロトコル
は、ＴＣＰ／ＩＰ，ＩＰＸ／ＳＰＸ，／ＩｒＤＡ，ｌｏ
ｏｐ−ｂａｃｋ等のマルチプル・トランスポート層をサ
ポート可能である。デバイスにおいて、どのトランスポ
ートが利用可能かについては、設計者の意図による。転
送実行はジェットセンド・デバイスにおけるトランスポ
ート・コードと適応しなければならない。ジェットセン
ド転送コードとの適応性を実現する２つの特定のコード
領域がある。これらはプロトコルのセッション層及び各
種の信頼メッセージシステムの規定である。
【００８１】転送アーキテクチュアは、デバイスがサポ
ートする転送と関係するジェットセンド・セッション・
プロトコルを含む。ＴＣＰ／ＩＰを使用するジェットセ
ンド・デバイスは、ジェットセンド・プロトコルを実行
する必要があり、低信頼性のデータサービスのためにＲ
ＭＴＰを実行する必要がある。ジェットセンドのネット
ワークの実施形態について簡単に説明する。
【００８２】ジェットセンド・セッション・プロトコル
（ＪＳＰ）は、デバイスが他のジェットセンド・デバイ
スと多重同時セッションを確立することを可能とするセ
ッション層である。各オープン・セッションにおいて、
多重データ・チャネルは、データ転送およびＪＩＰメッ
セージの送出にオープンである。図５は、２つのジェッ
トセンド・デバイス５１，５２間の多重チャネルによる
セッションを示したものである。２つのメッセージ・チ
ャネル５３、２つのストリーム・チャネル５４が提供さ
れている。
【００８３】ジェットセンド・セッションは、いずれか
のデバイスが他に対してチャネルをオープンすることを
許可する２つのジェットセンド・デバイス間の合意であ
る。２つのジェットセンド・デバイスが通信するために
は、両者間でのセッションを確立する必要がある。セッ
ション確立には、デバイス間のメッセージ（ＭＥＳＳＡ
ＧＥ）接続のオープン、およびその接続を介したＪＳＰ
セッション確立プロトコルの使用によるセッション存在
の交渉が含まれる。ＪＳＰアーキテクチュアは、すべて
のジェットセンド・デバイスにおいて能動的および受動
的なセッションの確立を許容する。いずれかの側から発
生するセッション確立は、セッションの受動的な傾聴
（リッスン）から開始され、他方は、受動側に対して能
動的にセッションの確立を働きかけなければならない。
ＪＳＰは２つのデバイス間にすでにセッションが存在す
る場合は、デバイスがジェットセンド・ケートウェイで
ない限り、セッションの確立を拒否する。（ジェットセ
ンド・ケートウェイはＩＰゲートウェイとは異なる。：
ジェットセンド・ゲートウェイは、ジェットセンド・プ
ロトコルを使うデバイスと使わない(例えばリモート・
ファックス装置)デバイス間の変換を実行するデバイス
である。ネットワークを介して到達する要求のターゲッ
トであるＪＩＰがセッション確立要求を聴かないとき
は、ＪＳＰは要求を拒否する。これは、ユーザがデバイ
スをオフしている場合等に発生し得る。
【００８４】ＪＳＰアーキテクチュアは、いずれのジェ
ットセンド・デバイスも他の複数のジェットセンド・デ
バイスと同時にセッションを確立することを許容する。
どのジェットセンド・デバイスも同時に受動的に確立さ
れたセッションと能動的に確立されたセッションとを並
列に共有することができる。
【００８５】セッションのいずれのサイドもセッション
の終了要求を開始することができる。要求サイドは、終
了要求をする前に、バッファデータが無くなるまで待つ
必要はないが、もしできるならそのようにすべきであ
る。終了が要求されたときは、両サイドはすべてのオー
プンチャネルでのデータ送信を停止し、即座にそれらの
接続完了を行う。
【００８６】ＪＩＰはＳＴＲＥＡＭ（ストリーム）及び
ＭＥＳＳＡＧＥ（メッセージ）の２つのタイプのチャネ
ルをＪＳＰを介して開くすることができる。これら両タ
イプのチャネルは、高信頼の整列配送サービスを提供す
る。ＳＴＲＥＡＭ（ストリーム）チャネルは、ＴＣＰの
ような接続指向型転送プロトコルを使用して実行される
ので、その維持にはＭＥＳＳＡＧＥ（メッセージ）チャ
ネルよりもより多くのオーバーヘッドが要求される。Ｍ
ＥＳＳＡＧＥ（メッセージ）チャネルは、ＲＭＴＰを使
用して実行される。ＳＴＲＥＡＭ（ストリーム）チャネ
ルは、多量データの転送に使用され、メッセージ・チャ
ネルよりも高いパフォーマンスを有する。ＪＩＰは、メ
ッセージ・チャネルをサポートすることを要請される
が、どのチャネル・タイプを使用するかは任意である。
あるものはごく限られたストリーム・チャネルのみをサ
ポートし、またはストリーム・チャネルはまったくサポ
ートしない場合もある。
【００８７】ジェットセンド・セッションそのものは、
ＪＩＰデータの送信および受信をするものではない。Ｊ
ＩＰはセッション確立によりＪＩＰ端末間の通信ができ
るようにＪＳＰのチャネルオープンを要求する。１つの
ＪＩＰのペアは、セッションを介してオープンしたチャ
ネル無しに両者間のオープン・セッションを保有し得
る。セッションのいずれかの側のＪＩＰは、チャネルの
オープン及びクローズを始めることができる。両ＪＩＰ
は任意にセッションを介してのチャネルのオープン及び
クローズが可能である。セッション中のストリーム・チ
ャネル及びメッセージ・チャネルの数、混在等に制限は
ない。もし、あるジェットセンドの実行手段が新規チャ
ネルのオープン要求を許容できない場合は、そのタイプ
のチャネルのオープンはできない旨の応答を行う。
【００８８】ＲＭＴＰは高信頼性シーケンス配送プロト
コルである。これは、ＵＤＰやＩＰＸのようなデータグ
ラム転送プロトコルに最小限の高信頼メカニズム及びシ
ーケンス番号ーを付加して実行される。ＲＭＴＰは、Ｔ
ＣＰやＳＰＸが行うようなストリーム・プロトコルのパ
フォーマンスや信頼性と同等のレベルを約束するもので
はない。ジェットセンドがサポートするネットワークの
実行形態に応じて、ＲＭＴＰはＵＤＰ，ＩＰＸ等の１つ
以上の低信頼性転送を総括する。その機能は各転送接続
における２つのポート間の全二重伝送を提供し、またす
べてのユーザ・メッセージを転送し、メッセージ転送が
できない場合は失敗をレポートする。ＲＭＴＰは、ＵＤ
Ｐ（および／または他のデータグラム・プロトコル）デ
ータグラム・サービスの高信頼性の配送を可能とするよ
うに拡張したものである。これは、ダメージあるいは２
重のメッセージを検出、破棄し、ユーザ・メッセージの
順序づけられた配送を提供する。
【００８９】ＲＭＴＰは、転送プロトコルである。これ
は、ＵＤＰやＩＰＸのようなデータグラム転送プロトコ
ルに高信頼性および整列配送を可能とするようにエンド
・ツー・エンド・サービスを拡張するものである。ＲＭ
ＴＰは、メッセージ・ユニット中においてＪＳＰからメ
ッセージを受け取る。ＲＭＴＰは、各発生ＪＳＰメッセ
ージを単一ＲＭＴＰセグメントとしてパッケージし、デ
ータグラム（datagram）転送を介して転送する。ＪＳＰ
メッセージをＲＭＴＰセグメントにパッケージするため
に、ＲＭＴＰはヘッダをＪＳＰメッセージにつける。各
ＲＭＴＰセグメントは、ＲＭＴＰヘッダと１または複数
のオクテット（octets：８個１組）のデータにパッケー
ジされる。ＲＭＴＰは、大きなＪＳＰメッセージを小さ
なセグメントに分断したり、受信側でメッセージの再構
築はしない。これは、ポート間で不等長のデータ・スト
リーム転送を許容し、受信側からの要求があるまでデー
タ・バッファを行うＴＣＰのようなバイト・ストリーム
・プロトコルとは異なる。
【００９０】ＲＭＴＰは、低信頼性転送を高信頼性転送
にすることが要求される。ＲＭＴＰはジェットセンド・
アーキテクチュアの基本ではなく、この発明はＲＭＴＰ
でなくても実行可能である。しかしながら、ＲＭＴＰは
転送レンジ拡張に有効である。
【００９１】上述したように、ジェットセンド・ゲート
ウェイは一方のエンドがジェットセンド・デバイスで他
方が異なる場合に対話を可能とするデバイスである。ゲ
ートウェイは、ジェットセンド・プロトコルと非ジェッ
トセンド・プロトコルの変換を行う。これは、ｅ−マテ
リアル・データ・タイプをそのゲートウェイに適したデ
ータ・タイプへ変換することを含む。ゲートウェイは独
自のジェットセンド・アドレスを有し、これはジェット
センド・デバイスがセッションを確立するために使用さ
れる。送信側はゲートウェイに対して最終アドレスの送
付も行う必要がある。これはエイリアス（ａｌｉａｓ）
アドレスとして知られるものでゲートウェイに特有のも
のである。例えば、ファックス・ゲートウェイは、エイ
リアス・アドレスとして転送先としての電話番号を要求
する。ゲートウェイのアドレスは送信デバイスに予め組
み込むことが可能である。ゲートウェイはそのローカル
・サブネットにおけるデバイスにその存在を知らせるこ
とが可能である。
【００９２】ジェットセンド・アーキテクチュアの詳細
について、以下さらに説明する。説明はプロトコルの低
位層から高位層に向かって行う。まずＲＭＴＰについて
簡単に説明し、次にジェットセンド・セッション・プロ
トコル、ジェットセンド対話・プロトコル、ジェットセ
ンド対話ポリシー、そしてｅ−マテリアルについて説明
する。
【００９３】高信頼メッセージ転送プロトコル（ＲＭＴ
Ｐ） 高信頼メッセージ転送プロトコル（ＲＭＴＰ）は、ジェ
ットセンドの本質ではないが、高信頼の転送を実行す
る。従って、ＲＭＴＰは現存の低信頼転送の信頼度を高
める軽量のプロトコル層として有益である。
【００９４】ＲＭＴＰは、２つのプロセス間の全二重通
信チャネルとして各接続が動作する接続指向プロトコル
である。送信側からのセグメントは目的ホストのポート
に向かう。ＲＭＴＰは各種の転送プロトコルを使用して
実行し得る。これは、ＵＤＰやＩＰＸのようなデータグ
ラム転送によって供給されるサービスを使用して実行す
ることを意図したものである。信頼性や整列配送の実行
によりデータグラム転送に価値を付加する。
【００９５】ＲＭＴＰは、接続確立のために共通インタ
ーネット・３−ウェイ・ハンドシェイクを使用する。Ｒ
ＭＴＰはこの接続ハンドシェイク手続きにより、最大セ
グメント・サイズ、同期シーケンス数の交渉、接続確認
の交換を行う。さらに、ホスト間のＲＭＴＰバージョン
の確認に関する交渉手続きも実行される。
【００９６】ＲＭＴＰレベルにおいて、送出されるセグ
メントは、生成されるにつれてデータグラム層における
入力として行列（キュー）化される。各セグメントは、
他のホストによって認識されるまで送信ＲＭＴＰに維持
される。入力セグメントはユーザ・プロセスの入力とし
て行列化される。セグメントはユーザ・プロセスの入力
として行列化されたとき、あるいは受信側で容認された
場合に認識されたとみなされる
【００９７】各接続における受信エンドは、許容可能な
最大セグメントサイズを特定する。送信側からの大きな
セグメントの転送の試みはエラーとなる。送信要求に伴
うバッファが接続に許容された最大セグメントサイズを
超えるときは、ＲＭＴＰはユーザに対してエラー応答を
する。さらに、ＲＭＴＰは入力セグメントが許容セグメ
ント・サイズを超えるときは接続を中止する。このエラ
ー・コンディションを回復する動作は行われない。高信
頼のメッセージ交換は以下に示すようないくつかのメカ
ニズムによって実行される。
【００９８】セグメント・シーケンス番号 データ転送の各セグメントは、同一接続における他のす
べてのセグメントと区別可能な独自のシーケンス番号を
有する。最初のシーケンス番号は接続がオープンされた
ときに選択される。データを有するセグメントが転送さ
れるごとにシーケンス番号は増加する。
【００９９】チェックサム チェックサムは、転送間に発生するエラーの発見のため
にパケット中に含まれる。ＵＤＰのようなインターネッ
ト・プロトコルにおいては、パケットが破壊される可能
性のあるパケット・ラジオ・ネットワークや大西洋衛星
ネットワークのような無線ネットワークを通過するため
に、これが重要となる。
【０１００】セグメントの肯定応答 ＲＭＴＰはセグメントの配送を行う１つの低信頼データ
グラム・サービスの存在を仮定している。この環境にお
けるセグメント転送を保証するには、ＲＭＴＰはセグメ
ントの肯定応答および再転送を使用する。独自のシーケ
ンス番号を有する各セグメントは、ホストによって正し
く受信され、許容されたとき肯定応答がなされる。肯定
応答のみからなるセグメントには肯定応答は発行されな
い。ダメージを受けたセグメントは破棄され、肯定応答
がなされない。宛先ホストからのタイムリーな肯定応答
セグメントがない場合にはセグメントの再転送が実行さ
れる。
【０１０１】リトランスミッション・タイムアウト（再
送タイムアウト） セグメントは転送において２つの理由で消失する。ロス
の多い転送媒体によって消失あるいはダメージを受け、
あるいは、受信ＲＭＴＰによって捨てられる。肯定応答
ポリシーは、セグメントが正しく受信され、許容された
場合にのみ受信側に肯定応答セグメントを要求する。消
失セグメントを発見するには、伝送ＲＭＴＰは各セグメ
ントが伝送されるごとに再送タイマを使用しなければな
らない。タイマは、ネットワークにおけるセグメント伝
送時間にほぼ等しく設定される。セグメントに対する肯
定応答が受信された場合は、タイマはキャンセルされ
る。セグメントに対する肯定応答が受信される前にタイ
マが時間切れとなった場合は、セグメントは再送され、
タイマが再スタートする。
【０１０２】ジェットセンド・セッション・プロトコル ジェットセンド・セッション・プロトコル（ＪＳＰ）
は、２つのプロセス両者間で多重前二重通信チャネルを
オープンするセッション指向プロトコルである。送信側
からのメッセージは目的ホストのＪＳＰポートに向か
う。ＪＳＰは、多重同時セッションも実行する。もっと
もこれは必須ではない。
【０１０３】ＪＳＰセッション・マネージメントは特定
の伝送において実行される。この伝送は、実際のＪＳＰ
メッセージの伝送および受信機能の提供を保証する。こ
の伝送は、正しいメッセージ交換のための高信頼整列配
送メカニズムをサポートしなければならない。例えばＩ
Ｐネットワークにおいては、必要となるメッセージ・チ
ャネルを提供するために、ＪＳＰは高信頼メッセージ転
送プロトコル（ＲＭＴＰ）を使用する。
【０１０４】さらに、必要なメッセージ・チャネルに加
えて、ＪＳＰは、ストリーム・チャネルを提供可能であ
る。これらは、ＴＣＰ，ＴＴＰまたはＳＰＸのような各
種の高信頼整列転送プロトコルを使用して実行できる。
ストリーム・チャネルのサポートはオプションであり、
プロトコルの一部として要求されるものではない。
【０１０５】各ＪＳＰセッションはそのライフタイムの
間、状態を変化させるシリーズをもって進行する。状態
を図６に示すとともに、それぞれについて、以下説明す
る。図６において、各楕円はＪＳＰ有限状態マシンの状
態を示し、各弧は、状態の変化を示す。各弧は注釈によ
り状態変化における発生事象および結果出力が記載され
ている。
【０１０６】［ＣＬＯＳＥＤ］ＣＬＯＳＥＤ（クロー
ズ）状態６１はセッションが無い状態において存在す
る。 ［ＬＩＳＴＥＮ］ＬＩＳＴＥＮ（リッスン）状態６２
は、受動オープン要求６７ａの後に発生する。ＪＳＰは
リモート・ホストからのトランスポート接続の確立を求
める能動的要求を待つ。 ［ＣＯＮＮＥＣＴＩＮＧ］ＣＯＮＮＥＣＴＩＮＧ（接
続）状態６３は、能動的オープン要求６７bの後に発生
する。ＪＳＰは、リモート・ホストへのトランスポート
接続の能動的オープンを行う。 ［ＳＹＮ−ＷＡＩＴ］ＳＹＮ−ＷＡＩＴ（ＳＹＮ待機）
状態６４は、トランスポート接続の受動的オープンの後
に発生する。ＪＳＰは、ＳＹＮ−ＷＡＩＴ状態でリモー
ト・ホストからのＳＹＮメッセージが到着するのを待
つ。 ［ＳＹＮ−ＳＥＮＴ］ＳＹＮ−ＳＥＮＴ（ＳＹＮ送信）
状態６５は、トランスポート接続の能動的オープンの後
に発生する。ＳＹＮメッセージ６８ｂはリモート・ホス
トに送られる。ＪＳＰは、ＳＹＮ−ＳＥＮＴ状態６５に
おいて、オープン要求に対する肯定応答メント（ＡＳＹ
Ｎメッセージ６９ｂ）を待つ。 ［ＯＰＥＮ］ＯＰＥＮ（オープン）状態６６は、ＳＹＮ
−ＷＡＩＴ状態６４またはＳＹＮ−ＳＥＮＴ状態６５の
いずれかから到達し得る。ＳＹＮメッセージがリモート
ホストから届いた場合（６９ａ）にはＳＹＮ−ＷＡＩＴ
状態６４から到達する。リモート・ホストからＳＹＮに
対するＡＳＹＮが届いた場合（６９ｂ）にはＳＹＮ−Ｓ
ＥＮＴ状態６５から到達する。ＯＰＥＮ状態６６におい
て、チャネルはオープンされ、セッションの２つのパー
ティ間でデータが送信される。
【０１０７】セッションは能動的あるいは受動的なオー
プン要求によってオープンされる。受動オープン要求６
７ａは、ＪＳＰをＬＩＳＴＥＮ状態６２とし、リモート
・ホストからのセッションのオープン要求を受動的に聴
く。能動的オープン要求６７ｂは、リモート・ホストの
特定のＪＳＰとのセッション確立を試みる。基本的に、
ＪＳＰは接続を聴いて（listen）いるときは受動的であ
り、他のＪＳＰとの接続オープンを開始するときは、能
動的である。
【０１０８】特定のケースにおいて、ＪＳＰは、受動的
接続のみ、能動的接続のみ、あるいは両タイプの接続を
サポートすることがある。しかしながら、これらの実行
形態はジェットセンド・プロトコルの高位層の利用可能
な機能に影響を与え得る。
【０１０９】ＪＳＰは、能動的にトランスポート接続を
オープンしたサイドに能動的にセッションをオープンす
ることを要請する。セッション・オープン交渉は、セッ
ション識別子を交換し、非ジェットセンド・ネットワー
ク機器がたまたまジェットセンド機器とのトランスポー
ト接続をオープンした場合にセッションを確立するのを
防止するために行われる。図７にセッションのスタート
時の概略説明図を示す。
【０１１０】まず、始めに受動的セッション・オープニ
ングについて説明する。ジェットセンド対話プロトコル
は、それ自身の識別がアサインされたＪＳＰポート番号
によってなされ（ジェットセンド・デバイス番号、ジェ
ットセンド・サブアドレス、ＪＩＰハンドル等としてさ
まざまに言及される）、ＪＳＰに対してセッションのリ
ッスン（ｌｉｓｔｅｎ）の要求を行う(受動オープン・
リクエスト)。ＪＳＰは自らのリッスン・コールを下層
のメッセージ転送サービスに行うことにより応答する。
ＪＳＰは、リッスン・コールとともに送付されたＪＳＰ
ポート番号を覚えており、下層トランスポートが受動的
接続応答を与えるのを待つ。各受動的接続応答（passiv
e connect reply）は、割り当てられた独自の接続ハン
ドル（ｃｏｎｎＨａｎｄｌｅ）を持つ。また、各結果の
受動的接続において、ＪＳＰは新しいセッション・コン
トロール・ブロック（ＳＣＢ）を生成し、ＪＳＰポート
番号およびその接続ハンドル（ｃｏｎｎＨａｎｄｌｅ）
を記憶する。
【０１１１】接続の確立およびＳＣＢセットアップに伴
い、ＪＳＰは、能動サイドのＳＹＮメッセージ送付を待
つ。もし、最初の到着メッセージがＳＹＮメッセージで
ないか、またはＳＹＮ規定された時間内（例えば２分）
に到着しない場合は、ＪＳＰは接続をクローズし、ＳＣ
Ｂを解消する。最初のメッセージがＳＹＮメッセージで
あり、規定時間内に到着した場合は、ＪＳＰはＡＳＹＮ
またはＮＳＹＮを接続を介してリモート・ホストに送
る。ＳＹＮメッセージが特定するＪＳＰポート番号がＳ
ＣＢに記憶されたものと同一であると確認されると、Ｊ
ＳＰはＡＳＹＮを送付してセッションを容認する。ま
た、セッションを拒絶する場合は、ＮＳＹＮを送付す
る。
【０１１２】もし、ＪＳＰがセッションを拒絶（ＮＳＹ
Ｎ）した場合は、ＮＳＹＮがリモートホストに到着する
まで待機し、接続をクローズしてＳＣＢを解消する。Ｊ
ＳＰが多重ＪＩＰｓをサポートし、同一ネットワークに
やおいてセッションのＪＳＰリッスンを複数のＪＩＰが
要求している場合は、ＪＳＰはネットワークに一度だけ
リッスンのコールを行う。ネットワーク上においてリッ
スンを行っている対象となるＪＳＰポート番号のリスト
は保持されている。リッスンおよびＳＹＮの受信によっ
てトランスポート接続が生成された場合、ＪＳＰはＳＹ
Ｎ中のＪＳＰポート番号がリスト中のいずれとも異なる
場合はセッション要求を拒絶する。
【０１１３】ＪＳＰがセッションを容認（ＡＳＹＮ）し
た場合、接続をオープンに保持して周回タイム（Ｒｏｕ
ｎｄＴｒｉｐＴｉｍｅ）を４回待機し、セッション・ハ
ンドルをＪＩＰに返す。周回タイムとはＳＹＮが送られ
てからＡＳＹＮが受信されるまでの時間である。この待
機は、ＪＩＰに新しいセッションのハンドルを通知する
前にＪＳＰプロトコル・バージョンの再交渉が行われな
いことを確認するためである。ＪＳＰに対しては、同一
バージョンの元で通信が行われるようにハンドシェイク
手続きの間にバージョンの交渉が行われるように設定さ
れる。
【０１１４】次に能動的セッション・オープニングにつ
いて説明する。ＪＩＰはそれ自身の識別がＪＳＰポート
番号及びアドレス・ストリングを有するターゲットによ
ってなされ、ＪＳＰにセッションのオープンを要求する
（能動的オープン要求）。
【０１１５】ＪＳＰは下層のメッセージ・サービスに対
して能動的コール（ＡｃｔｉｖｅＣａｌｌ）を行って応
答する。ＪＳＰは能動的コールとともに送出したＪＳＰ
ポート番号を覚えており、能動的コールに対しての下層
トランスポートからの能動的コール応答を待機する。各
能動的接続は独自の接続ハンドルを割り当てられてお
り、結果としての能動的接続において、ＪＳＰは新規の
セッション・コントロール・ブロック（ＳＣＢ）を生成
し、ＪＳＰポート番号、及びその接続ハンドルを記憶す
る。
【０１１６】接続の確立およびＳＣＢセットアップに伴
い、ＪＳＰは、受動サイドへＳＹＮメッセージを送付す
る。ＳＹＮメッセージは、ＪＳＰが宛先ＪＭＮからアド
レスによって引出した受動ＪＳＰポート番号を含んでい
る。ＪＳＰは下層のメッセージ転送がＳＹＮメッセージ
の送付確認を行うのにかかる時間(周回タイム)を計測す
る。その後、受動側がＡＳＹＮまたはＮＳＹＮメッセー
ジを送付するのを待機する。もし、最初の到着メッセー
ジがＡＳＹＮ、またはＮＳＹＮメッセージでない場合、
ＪＳＰは接続をクローズし、ＳＣＢを解消する。ＡＳＹ
ＮまたはＮＳＹＮが１分または周回タイムの４回分のい
ずれか大きいほうの範囲内に到着しない場合は、ＪＳＰ
は接続をクローズしＳＣＢを解消する。
【０１１７】４周回タイムの待機は、応答側が低速リン
クを介して応答するのに十分な時間を確保するためであ
る。１分の待ち時間は、応答側が比較的低速のマシンで
あり、高速リンクを介して通信を行っている場合に応答
側に十分な時間を確保することを保証するものである。
【０１１８】リモート・ホストがセッション（ＡＳＹ
Ｎ）を認めた場合、ＪＳＰは接続をオープンとして維持
し、ＪＩＰに対してセッション・ハンドルを返す。リモ
ート・ホストがセッションを拒絶した場合（ＮＳＹＮ）
は、ＪＳＰは接続をクローズし、ＳＣＢを解消する。
【０１１９】いずれの１つのセッションにおいても、Ｊ
ＳＰはリモートホストとの１つの転送メッセージ接続、
および１以上の（ＴＣＰ，ＳＰＸ他）転送ストリーム接
続を維持する。ＪＳＰは単一のメッセージ接続を介して
すべての付加的メッセージ・チャネルの多重化を行う。
すべての付加的ストリーム・チャネルは、付加的転送ス
トリーム接続に対応する。
【０１２０】セッションが確立された後、すでにメッセ
ージ接続は存在することとなる。これは、セッション確
立の手続きの間に生成される。ＪＩＰがＪＳＰにメッセ
ージ・チャネルのオープンを要求すると、ＪＳＰはこの
メッセージ接続を介してチャネルの交渉を行う。
【０１２１】ＪＩＰがストリーム・チャネルの受動的リ
ッスンを要求すると、ＪＳＰはまず周知のローカルのス
トリーム転送ポートに対して通知する。その後、リモー
トＪＩＰがストリーム・チャネルのオープンを要求する
と、ＪＳＰ新しく生成されたトランスポート接続を利用
してチャネルを生成する。
【０１２２】ＪＩＰがストリーム・チャネルの能動的オ
ープンを要求すると、ＪＳＰはリモート・ホストの周知
のストリーム転送ポートに対する新規のストリームトラ
ンスポート接続を生成する。リモート・ホストがポート
上の接続をリッスンしている場合、新規のトランスポー
ト接続を利用して接続が生成される。チャネルがクロー
ズされると、ＪＳＰは転送ストリーム接続をクローズす
る。
【０１２３】物理的メッセージ接続は、セッション中は
クローズされることはない。
【０１２４】ＪＳＰがセッションをクローズすると、セ
ッション中にオープンされたトランスポート接続をクロ
ーズし、アクティブな転送リッスンをキャンセルする。
ＪＳＰは、３つの状態、すなわち上層からのクローズ要
求の受領、リモート・ホストからのＲＳＴメッセージの
受領、転送メッセージ接続フェイルにおいてセッション
のクローズを行う。
【０１２５】ＪＳＰがセッション・クローズを言い渡さ
れたとき、メッセージ接続を利用してＲＳＴメッセージ
を送付し、すべてのトランスポート接続をクローズし、
すべてのリッスンをキヤンセルし、ＳＣＢの解消を行
う。このセッション・クローズ機能は、ジェットセンド
・プロトコルにおける上層セッションのクローズの要求
以前にすべてのデータが正しく配送されたことを確認す
ることを要求する。
【０１２６】ＪＳＰがメッセージ接続を介してＲＳＴメ
ッセージを受領したときには、すべてのトランスポート
接続をクローズし、すべてのリッスンをキャンセルし、
ＳＣＢを解消する。
【０１２７】ＪＳＰメッセージ接続がフェイルした場合
は、すべてのトランスポート接続をクローズし、すべて
のリッスンをキャンセルし、ＳＣＢを解消する。ストリ
ームトランスポート接続がフェイルの場合には、ＪＳＰ
はセッションをクローズしない。これは、ストリーム接
続がデータ送受信の唯一のオプショナルであるときは、
メッセージ接続が必要となるからである。
【０１２８】セッションの一方がクラッシュした場合、
セッションは一方サイドのみが生きた状態に放置される
場合がある。この場合は、ハーフ・オープン・セッショ
ンとして収束する。
【０１２９】ハーフ・オープン・セッションおよび接続
が、オープンの状態で維持されてリソースを消費するこ
とのないように、ＪＳＰは、セッションの長時間の非動
作状態において、キープ・アライブ・メッセージを送付
する。セッションにおいて１０分以上、いずれのチャネ
ルにおいても動作がない場合は、ＪＳＰはメッセージ接
続を介して他方のサイドにキープ・アライブ・メッセー
ジ（ＮＵＬメッセージ）を送付する。メッセージ接続が
フェイルした場合（ＪＳＰは下層トランスポートから非
接続通知を受領する）は、セッションは終了する。キー
プ・アライブ・メッセージがメッセージ転送中に集積す
ることを避けるためにＪＳＰは最後に送付したものに対
する通知を下層トランスポートから受領するまで、他の
キープ・アライブ・メッセージの送付を行わない。
【０１３０】ＪＳＰはセッションを介するチャネル概要
を提供する。セッション・プロトコルがオープン状態に
あるとき、ＪＳＰは利用可能なタイプのチャネルをオー
プンする。各ＪＳＰチャネルは、２つのジェットセンド
・デバイス間で全二重通信チヤネルとして働く。送信側
からのメッセージは宛先ホストのチャネル終点に向か
う。
【０１３１】チャネルは能動的あるいは受動的オープン
要求を発行してオープンされる。受動的オープン要求
は、ＪＳＰに対してリモートホストからのチャネルのオ
ープン要求の受動的なリッスンを実行させる。能動的オ
ープン要求は、リモートホストに対してチャネルのオー
プン要求を送信する。
【０１３２】ＪＳＰがチャネルの能動的オープンを実行
可能となるには、オープン可能なチャネルの存在、及び
どのチャネルがオープン可能かを知ることが必要とな
る。ＣＥＸＴＬＳＮメッセージが、この目的のためにＪ
ＳＰによって使用される。上述のハンドシェイキング手
続きによってセッションが確立されると、セッション中
のＪＳＰは各々オープニングに適用可能なチャネルタイ
プ情報を含むＣＥＸＴＬＳＮメッセージを送出する。Ｊ
ＳＰはこのメッセージを受信するまで他のＪＳＰとのチ
ャネルの能動的オープンを実行しない。
【０１３３】ＣＥＸＴＬＳＮが受信されると、ＪＳＰは
チャネルのオープンを開始することができる。チャネル
・オープン要求はＣＨＮビットがセットされたＳＹＮメ
ッセージ（ＣＳＹＮメッセージ）中において転送され
る。ここには送信側からのチャネル番号が含まれる。Ｃ
ＳＹＮメッセージに対する応答は、ＳＹＮメッセージで
あり、ＣＨＮ及びＡＣＫビットがセットされている（Ｃ
ＡＳＹＮメッセージ）。ここには応答側からのチャネル
番号を含んでいる。チャネル・オープンにおける受動側
は、能動側からのＣＳＹＮメッセージを受け取る。受動
側は、能動側のチャネル番号をチヤネル・コントロール
・ブロック（ＣＣＢ）中に記録する。さらに、能動側に
ＣＡＳＹＮを送信する。これは、ＣＡＳＹＮ中に自分の
チャネル番号（ＣＣＢに対するハンドル）を含む。受動
側から能動側に対して送付されるすべてのメッセージに
は、宛先チャネル・フィールド中に能動側のチャネル番
号を含んでいる。
【０１３４】チャネル・オープンに係る能動側は、ＣＣ
Ｂを生成し、受動側にＣＳＹＮメッセージを送信する。
ここには、ＣＳＹＮ中の自分のチャネル番号（ＣＣＢに
対するハンドル）を含んでいる。その後、受動側からの
ＣＡＳＹＮを受領する。能動側は受動側のチャネル番号
をＣＣＢ中に記録する。能動側から受動側に対して送付
されるすべてのメッセージには、宛先チャネル・フィー
ルド中に受動側のチャネル番号を含んでいる。
【０１３５】受動側は、ＳＹＮメッセージと、ＣＨＮ及
びＮＡＫビットとがセットされたＣＳＹＮメッセージ
（ＣＮＳＹＮメッセージ）を送付する。これはチャネル
・オープンの拒絶を示し、チヤネルは生成されない。
【０１３６】チャネルのクローズはＪＩＰ側からのクロ
ーズ要求によって、またはチャネルの他方からのＣＲＳ
Ｔメッセージの受領によって行われる。クローズ要求の
場合、ＪＳＰは、チャネルの他方にＣＲＳＴメッセージ
を送付し、チャネルの端部をクローズする。ＪＳＰはク
ローズされたチャネルに対するメッセージを破棄する。
このチャネルのクローズにおいては、ユーザがチャネル
のクローズ以前にすべてのデータが配送されたことを確
認することが要求される。
【０１３７】図８にチャネルのオープン及びクローズを
説明する図を示す。ＪＳＰチャネルを流れるデータ形態
はＣＨＮメッセージである。すべてのＣＨＮメッセージ
は、非ターミナル・フラグメントを除いてラスト・フラ
グメント・ビット（ＬＦ）がセットされている。ＪＳＰ
レベルにおいて、出力メッセージは生成ごとにトランス
ポート層に対する入力として配列される。各メッセージ
は下層トランスポートによって確実に転送される。この
転送ができない場合は、トランスポートはその接続上に
非接続を送出し、結果としてＪＳＰはその接続上のすべ
てのチャネルをクローズする。すべてのオープン・チャ
ネルのクローズに加えて、ＪＳＰはセッションをクロー
ズする。
【０１３８】２つのデバイス間で授受される情報は、こ
の実施形態ではデータは４バイト境界を有して送信また
は受信される。これらのデータ・ブロックは、ドキュメ
ント残部全般においてタスク・バッファ・コントロール
バッファ（ＴＢＣＢ）として識別される。ＴＢＣＢが検
出されない場合は、ＮＵＬＬパッディングを付加するこ
とが必要となる。ＪＳＰがＴＢＣＢからのデータを外部
の端末に送付する場合はパッディングを含む。
【０１３９】ＪＳＰが接続をオープンする際、下層トラ
ンスポートから受信する必要のある情報アイテムの１つ
がその接続における最大メッセージ・サイズである。こ
の最大転送バフ（ｂｕｆ）は、トランスポートがその接
続におけるＪＳＰからの送信において許容できる最大メ
ッセージ・サイズである。ＪＳＰがＪＩＰから最大メッ
セージ・サイズよりも大きなデータ・バッファの送信要
求を受領した場合は、ＪＳＰはデータをデータを多重Ｊ
ＳＰメッセージに分断する。各多重メッセージにはヘッ
ダが付加され、ＬＦビットが最後のものを除いて１にセ
ットされ、最後のものは１にセットされ、転送のために
下層のトランスポートに送られる。受信側は、メッセー
ジをＪＩＰへの配送のために１つのデータに再構築す
る。
【０１４０】ＪＳＰプロトコルの一部として、ＣＳＹＮ
及びＣＡＳＹＮパケットは各ＪＩＰが処理可能な最大バ
フ・サイズ（max_buf_size）である最大バッファサイズ
に関する情報を交換する。ＪＳＰは、２つのサイズが異
なることを大きな理由として、リモート最大バッファ・
サイズ（remote_max_buf_size）を、バッファの分割の
前に考慮しなければならない。ＪＳＰは、リモート・デ
バイスに対してremote_max_buf_sizeよりも大きなバッ
ファを送ってはならない。ローカルＪＩＰのmax_buf_si
zeがremote_max_buf_sizeよりも大きい場合は、ＪＳＰ
はmax_buf_size（this_buf_size）のバッファを受信
し、リモート・デバイスに送る。ＪＳＰは、このthis_b
uf_sizeのバッファについて、バッファ（これは分割さ
れることが必要であろう）をリモート・デバイスに対し
てremote_max_buf_sizeまで送ることが必要である。リ
モートＪＩＰは、正しいデータ量（this_buf_size）を
１つのバッファにおいてではなく、this_buf_sizeまで
追加された部分メッセージにおいて受領する。さらに、
４ＫがＪＩＰによって解釈される最小レコード・サイズ
であり、ＪＳＰは部分メッセージがこのレコード・サイ
ズの多重化されたものであることを確認する必要があ
る。さもなければ、リモートＪＩＰは、部分メッセージ
として受領したデータの解釈が不可能となることがあ
る。このようなメッセージ分割の例を図９に示す。
【０１４１】ＪＳＰは、メッセージ・チャネルを介して
メッセージが転送されるときにのみメッセージにヘッダ
を付加する。データ・ブロックが送信側で記録されたよ
うに正確に接続先に配送されることが必ずしも必要では
ないのがストリーム・チャネルのプロパティである。例
えば、６４キロバイト２ブロックとして記録されたもの
は、１２８キロバイトの１ブロックとして配送されるか
もしれない。しかし、ストリーム中のバイト列は維持さ
れている。
【０１４２】ジェットセンド・デバイスは、一般的に単
一ネットワーク・タイプ（ＩＰまたはＩＰＸのみ）を介
したピア・トゥ・ピア・インタラクトを行う。これは、
１つのネットワーク・タイプにおけるジェットセンド・
デバイスは、物理的に同一のネットワークに接続された
同一ネットワーク・タイプのジェットセンド・デバイス
とのみ通信可能であることを意味する。ジェットセンド
メデバイスが他のデバイスとの接続を必要とし、ネット
ワークが第１のデバイスによってサポートされていない
場合、またはプロトコルが第１のデバイスによってサポ
ートされていない場合に問題が発生する。この問題を解
決するには２つのアプローチがある。
【０１４３】１つのアプローチは、単一ジェットセンド
・デバイスに多重通信スタックを持たせることである。
これにより、適当な通信スタックを持ちさえすれば、各
種のタイプのジェットセンド・デバイスと対話すること
が可能となる。このアプローチは、下層のトランスポー
トが異なりデバイスがすべてのジェットセンド・プロト
コル（例えばＩＰまたはＩＰＸ）を理解する環境におい
て有効に作用する。
【０１４４】マルチプル・ネットワーク問題に対する第
２の解決策はゲートウェイの使用である。ゲートウェイ
はネットワーク中に隠れた存在として配置され、１つの
ネットワーク・タイプから他のタイプへの変換を行う。
ゲートウェイは、宛先デバイスがジェットセンド機器で
はない場合に最適であり、各ソース・デバイスは、通信
を行うために宛先のモデリングを行うことが必要とな
る。これはファックスやｅ−メイルのような場合であ
る。この機能は、ネットワークに対する対話能力をデバ
イスへ与えてデバイスを過負荷とするより、ゲートウェ
イに対して与えてプログラマブル装置によって管理され
る。
【０１４５】ジェットセンド・ゲートウェイを必要とす
るリモート・デバイスとのセッション確立をＪＩＰが望
む場合は、ＪＳＰはゲートウェイの存在をＪＩＰから隠
す。ＪＳＰは代わりにゲートウェイとのセッションを確
立し、ゲートウェイに対するＳＹＮメッセージ中にリモ
ート・デバイス・アドレスを含ませる。ゲートウェイが
セッション中のチャネルのいずれかにおいてＪＩＰデー
タを受領した場合は、ゲートウェイは、ゲートウェイリ
ンクを介したリモート・デバイスへのデータがあるとみ
なす。
【０１４６】同じゲートウェイを介してアクセスされる
第２のリモート・デバイスとのセッション確立をＪＩＰ
が望む場合、ＪＳＰは上述したようにゲートウェイと第
２セッションをオープンする。
【０１４７】ＪＳＰの実行形態において、ゲートウェイ
タイプとゲートウェイ・アドレスとのマッピング可能な
内部テーブルを保持し、デバイスがアドレスによってゲ
ートウェイとの接続可能となるように構成する必要があ
る。
【０１４８】ＪＳＰは、データグラム・ポートを介して
ＧＷＹメッセージを送信することにより、ゲートウェイ
要求を一斉通知（ブロードキャスト）する（ＪＳＰがＩ
Ｐネットワークを介して動作している場合は、ゲートウ
ェイ・メッセージを送受信するＵＤＰポートをオープン
することによって実行される）。ＧＷＹメッセージの一
斉通知の後、通知を行ったと同じローカル・アドレス
（またはＵＤＰポート）において応答のリッスンを行
う。ジェットセンド・ゲートウェイは、周知のデータグ
ラム転送ポート上における一斉通知のリッスンを行う。
ゲートウェイ一斉通知（ＧＷＹパケット）を受け取る
と、そのバージョン・フィールドにおけるバージョン・
サポートが可能であることが確認できる。バージョンの
サポートがなされると、宛先がすべてのゲートウェイ
（０ｘＦＦ）か、この特定のゲートウェイであるかを調
べる。適合（ｍａｔｃｈ）が有れば、ゲートウェイのタ
イプが要求のものであるかをチェックする。タイプ要求
がＮＵＬＬの場合、すべてのタイプのゲートウェイが応
答しなければならない。もし、ＮＵＬＬでない場合は、
そのタイプのゲートウェイが応答する。ゲートウェイが
応答すべきと判断すると、ＧＡＣＫメッセージを使用し
て一斉通知する。このＧＡＣＫはＧＷＹメッセージと同
様にデータグラム・ポートを介して送付される。
【０１４９】ＪＳＰがＧＷＹメッセージに対するＧＡＣ
Ｋを受け取ると、そのバーージョン・フィールドにおけ
るバージョンのサポートが可能であることが確認され
る。否定的である場合は、パケットを無視する。ＪＳＰ
がそのバージョンをサポートできる場合は、内部テーブ
ルにゲートウェイ情報をキャッシュし、新しいゲートウ
ェイをＪＩＰに通知する。ＪＩＰは新しいゲートウェイ
によってセッションがオープンできる。
【０１５０】ＪＳＰがＧＷＹを通知した後、所定時間に
ＧＡＣＫが到着しない場合、ＪＳＰは図１０に示すよう
にＧＷＹの再送にタイマを用いる。ＪＳＰが第１ＧＷＹ
を送るとき、タイマを６秒にセットする。６秒経過して
もＪＳＰがＧＡＣＫを受領しない場合は、タイマを倍の
１２秒として再送する。各再送においてタイマは倍にセ
ットされる。トータルの経過時間が９０秒を超えると、
ＪＳＰはギブアップする。この時にＪＩＰに対してリモ
ート・デバイスとのセッション確立が不調に終わったと
の応答をする。
【０１５１】典型的には、ゲートウェイの一斉通知は、
ＪＩＰからの要求に応答する形で実行される。しかし、
ゲートウェイにはその存在を知らせる手段はない。すな
わち、この実施形態においては、自発的なＧＡＣＫメッ
セージの送付はプロトコルによって認められていない。
【０１５２】ＪＳＰヘッダ・フォーマットについて、い
くつかの特定のＪＳＰメッセージにおける概略とともに
説明する。各ＪＳＰメッセージは２０バイトＪＳＰメッ
セージに前置きされる。ヘッダの汎用フォーマットは、
図１１の下部に示すようなものであり、各フィールドが
それに続く。いくつかのフィールドは各ＪＳＰメッセー
ジにおいて用いられるが、あるものはたまにしか用いら
れない。メッセージの開始からオクテット（バイト）オ
フセットが頭から最後までナンバリングされる。ビット
位置は、右から左に向かって、最下位ビットから始ま
り、最上位ビットで終わるようにナンバリングされる。
セット・ビットの数値は、ビット位置に応じた２の乗数
となる。セグメント中のすべてのマルチ・バイト言語
は、ビッグ・エンディアン・フォームのネットワーク・
バイト・オーダーにおいて、ネットワークを介して転送
される。
【０１５３】ＪＳＰヘッダ・フィールドについて説明す
る。１６ビット制御ビット・フィールドがヘッダのバイ
ト０及び１を占有する。これは、以下に示すような定義
ビットによる符号化ビットである。
【０１５４】１．ＳＹＮ セッションまたはチャネルの
確立 ２．ＡＣＫ セッションまたはチャネルの容認 ３．ＮＡＫ セッションまたはチャネルの拒絶 ４．ＲＳＴ セッションまたはチャネルのクローズ ５．ＮＵＬ 動作状態維持（キープ・アライブ） ６．ＣＨＮ メッセージか特定のチャネルに向けられて
いる。 ７．ＧＷＹ メッセージがゲートウェイ一斉通知または
応答 ８．ＥＸＴ 外部ヘッダ、バイト８が付加制御ビットを
含む（ＣＥＸＴＬＳＮを参照） ９．ＬＦ フラグメント・ビット、０の場合これはラス
トのフラグメントではない、１の場合、ラスト・フラグ
メントである。 １０．未使用−０にセット １１．未使用−０にセット １２．未使用−０にセット １３．未使用−０にセット １４．未使用−０にセット １５．未使用−０にセット １６．未使用−０にセット
【０１５５】制御ビットは以下の表１に示すようにメッ
セージタイプの生成に組み合わされて使用される（ＥＸ
Ｔビットはこれらにおいてすべて０である）。
【０１５６】
【表１】
【０１５７】
【表２】
【０１５８】１６ビット・バージョン番号・フィールド
は、ヘッダのバイト２，３を占有する。これは、交渉さ
れたまたは交渉されるＪＳＰプロトコルのバージョンを
含む。バージョンは１６ビット符号付き整数である。
【０１５９】１６ビットソース・フィールドは、ヘッダ
のバイト４，５を占める。これは、パケットのソース識
別子を含み、ＪＳＰメッセージ・タイプに依存してＪＳ
Ｐポート番号、接続識別子、チャネル識別子のいずれか
となる。ソースは、１６ビット符号付き整数である。
【０１６０】１６ビット宛先フィールドは、ヘッダのバ
イト６，７である。これはＪＳＰパケットにおける宛先
識別子を含む。ＪＳＰメッセージ・タイプに依存してＪ
ＳＰポート番号、接続識別子、チャネル識別子のいずれ
かである。宛先は、１６ビット符号付き整数である。Ｇ
ＷＹパケットの場合、すべてのゲートウェイの応答に対
応して０ｘＦＦにセットされる。
【０１６１】３２ビット付加データ・フィールドは、ヘ
ッダのバイト８から１１である。これは、ＪＳＰがある
ＪＳＰパケットに要求される付加データを保持するのに
使用される。さらにこのフィールドはヘッダのバイト１
２から１５を占める。例えば、ＣＥＸＴＬＳＮでは、最
初の８バイトは、メッセージ及び／またはストリーム・
チャネルのリッスンの開始または終了を示す特別コード
として使用される。
【０１６２】１６ビット長フィールドはヘッダのバイト
１６，１７を占める。これはＪＳＰヘッダに続くデータ
の長さ（バイト）を示す。この長さは、１６ビット符号
なし整数である。
【０１６３】最終１６ビット・フィールド、すなわちパ
ッディング・フィールドは、ヘッダのバイト１８，１９
を占める。これはＪＳＰヘッダが４バイト境界に納まる
ことを保証するために使用される。これはＪＳＰヘッダ
の終端である。
【０１６４】ジェットセンド対話プロトコル（ＪＩ
Ｐ）、及びプロトコルを形成するメッセージについて説
明する。情報の交換及び共有をＪＩＰが行うためのＪＳ
Ｐの使用についても説明する。
【０１６５】ＪＩＰに基本的なコンセプトは、界面交換
である。この概念の表現の１つの方法は、界面を模型粘
土のブロックの界面（表面）としてとらえることであ
る。粘土ブロックは、所有者の意図するどのような形に
もなり得る。オブザーバは、この物体の表面をその表面
の表現する通りに観察する。すなわち、粘土の所有者
は、物体が示す形状を有する表面をもつ形を粘土によっ
て形成することができる。
【０１６６】オブザーバが形づけられていない別の粘土
ブロックを有していると想定する。オリジナルの形づけ
られた粘土ブロックを有する所有者は、そのブロックを
オブザーバの無形のブロックに押し付けることができ
る。オブザーバは、自分の粘土ブロックに押し付けられ
た形状によりオリジナルの形状のレプリカを手に入れる
ことがてきる(界面交換において、オブザーバはオリジ
ナルの性格なコピーを得るのであり、逆のまたは鏡の関
係のものではない)。オリジナル粘土ブロックの所有者
（表現デバイス：エクスプレッシブ・デバイス）は、オ
ブザーバの粘土ブロック（インプレッション・デバイ
ス）上にオリジナル・コピーを形成する。
【０１６７】ＪＩＰは界面に収束する情報や、界面（サ
ーフェイス）交換モデルに従って交換される情報の各部
をいくつものデバイスで共有することを可能とする少な
いメッセージ数によって構成される。どの対話において
も、１つのデバイスは、自分の界面を有する。所有者の
コピーは、界面の表現（エクスプレッション）として示
され、所有者自身は表現デバイス（エクスプレッシブ・
デバイス）である。界面のコピーは、インプレッション
であり、これらを所有するデバイスは、インプレッシブ
・デバイスである。ＪＩＰによって供給されるメッセー
ジは、表現デバイスが表現を生成または解消することを
許容し、インプレッシブ・デバイスが自己で所有するイ
ンプレッションを解消することを許容し、すべてのデバ
イスがオリジナル界面の表現を変形することを許容す
る。
【０１６８】界面、表現、インプレッションの概念を実
行するために、メッセージリストが形成される。これ
は、界面対話ガ発生するメッセージの使用に関連する。
以下に示すメッセージが対話プロトコルを形成する。
【０１６９】SurfaceMSG(impress)（界面メッセージ
（インプレス）） ターゲット・デバイスに対して新しいインプレッション
を形成する。また、インプレッションの要求の拒否にも
使用される。
【０１７０】SurfaceDeleteMsg(Delete)（界面消去メッ
セージ（デリート）） 表現デバイスがオリジナル表現を消去したことをインプ
レッシブ・デバイスに通知する。
【０１７１】SurfaceReleaseMsg(Unimpress)（界面開放
メッセージ（アンインプレス） インプレッシブ・デバイスがインプレッションを消去し
たことを表現デバイスに通知する。
【０１７２】SurfaceRequestMsg(Surface Request)（界
面要求メッセージ（界面要求）） 名付けられた界面のインプレッション要求をデバイスに
許可する。
【０１７３】DescriptionRequestMsg(Description Requ
est)（記述要求メッセージ（記述要求）） インプレッションを有する界面の記述要求をデバイスに
許可する。
【０１７４】DescriptionReplyMsg(Description Reply)
（記述応答メッセージ（記述応答）） 記述要求に応答してインプレッションの記述を転送す
る。
【０１７５】ContentRequestMsg(Content Request)（内
容要求メッセージ（内容要求）） 表現デバイスからの内容データの要求をインプレッシブ
デバイスに許可する。
【０１７６】ContentReplyMsg(Content Data)（内容応
答メッセージ（内容データ） 内容要求に応答して、表現デバイスからインプレッシブ
・デバイスに対する内容データの転送。内容要求に応答
するメッセージ列である場合もある。このメッセージは
内容要求の拒否にも使用される。
【０１７７】SurfaceChangeMsg(Change)） 情報の変化をデバイスに通知する（例えば、表現デバイ
スによってインプレッシブ・デバイスに変化が通知さ
れ、インプレッシブ・デバイスによって表現の変更が要
求され、またこれらの要求の拒否がなされる）。
【０１７８】界面はいくつもの属性を有する。ネーム、
識別子、クラス、プロパティ・セット、記述、内容デー
タ、バージョンである。ネームは、ＡＳＣＩＩストリン
グに収束するＮＵＬＬである。識別子は、各界面に割り
当てられ、ＪＩＰ中での識別を可能とする。クラスは界
面の目的を決定する。プロパティ・セットは、表現デバ
イス（エクスプレッシブ・デバイス）が応答するＪＩＰ
メッセージを制御する。記述は、利用可能なデータ・フ
ォーマット記述、または表現デバイスが供給しようとす
る記述を含む。内容データは、情報自体の実際のバイト
を有するバージョンは、。変化の関係する界面バージョ
ンを表現及びインプレッシブ・デバイスが知ることがで
きるチェンジ・メカニズムによって使用される。
【０１７９】典型的な対話は、以下のように実行され
る。まず、転送情報を有するデバイス、これは表現デバ
イスであるが、表現を生成する。このためには、ネーム
を生成し、識別子を割り当て、プロパティ・セットを生
成し、記述を生成する。この時点では、内容データは生
成する必要はない。しかし、界面記述における表現内容
は生成可能でなければならない。次に、表現デバイスが
これらの属性を用いて、界面メッセージを宛先デバイス
に送付して界面のインプレッションの生成を試みる。こ
の界面メッセージは、自発的か、あるいは、他のデバイ
スから受領した先の界面要求メッセージに対する応答と
して送られる。界面メッセージを使用してインプレッシ
ョンを生成するために、表現デバイスは、表現を形付け
るターゲット界面を有することが必要である。界面メッ
セージが先の界面要求メッセージに対する応答である場
合は、このターゲット界面識別子は、界面要求メッセー
ジ中に発見される。しかし、表現デバイスが自発的イン
プレッションを生成した場合は、ターゲット界面はその
存在するインプレッションのものとなる。この場合、表
現は、すでに存在しなければならない、または、デフォ
ルト・ターゲット識別子としてセットされなければなら
ない。
【０１８０】デフォルト・ターゲット識別子は、時に
“ワーク界面”として解釈される。このようなデフォル
トの存在は、ＪＩＰの正しい実行のために重要である。
さもなければ、表現デバイスがインプレッシブ・デバイ
スに最初にメッセージを送付する場合に大きな問題が発
生する。表現デバイスは、インプレッシブデバイスのイ
ンプレッション生成位置を知らない（この時点では情報
がない）。また、インプレッシブ・デバイスは、表現デ
バイスがインプレッション生成を望んでいることを知ら
ないので、表現デバイスに知らせることができない（例
えばある種のグローバル・メッセージを送付して）。解
決策は、すべてのデバイスが許容できるデフォルト・イ
ンプレッションやデフォルト・ターゲット識別子を有す
るワーク界面の存在である（この実施例においてデフォ
ルト・ターゲット識別子は１にセットされている）。こ
れによって、どの表現デバイスもターゲット識別子フィ
ールドを１にセットすることでインプレッシブ・デバイ
スにインプレッションを形成可能となる。インプレッシ
ブ・デバイスは、表現デバイスとの通信が可能となる
（例えば、新しいターゲット界面に対するインプレッシ
ョンを要求する界面要求メッセージを伴って行われ
る）。
【０１８１】ＪＩＰメッセージの使用を示した例につい
て図１２から図２２を用いて以下に説明する。図１２
は、図１と基本的に類似しているが、他との比較を容易
とするために図１２を用いる。
【０１８２】例１、図１２ 表現デバイス（エクスプレッシブ・デバイス）は、非要
求（要求されていない）インプレッションの生成を試み
る。第１に、界面表現（サーフェイス・エクスプレッシ
ョン）１２１が生成される。次に、これが界面メッセー
ジ（SurfaceMsg）とともにインプレッシブ・デバイスに
インプレス(刻印)され、界面のインプレッション１２２
がインプレッシブ・デバイスに存在することになる。
【０１８３】例２、図１３ 表現デバイス（エクスプレッシブ・デバイス）は、他の
機器との交換を望む旨の情報に関する界面表現を生成す
る。この例においては、表現はその要求がある以前にす
でに存在するが、これは必ずしもこのような場合に限ら
ない（例えばチャイルド界面が実際にその要求があるま
で生成されない場合もある）。次に、表現デバイスが、
界面要求メッセージ（SurfaceRequestMsg）中において
界面インプレッションの要求を受領し、応答として界面
メッセージとともにインプレッションの生成を行う。結
果は、例１と同様、インプレッション１２２がインプレ
ッシブ・デバイスに生成される。
【０１８４】例３、図１４ 例１と同様、表現デバイスは、界面表現を生成し、イン
プレッシブ・デバイス上に非要求インプレッションの生
成を行う。インプレッション１２２が生成されるが、こ
れは即座にインプレッシブ・デバイスから表現デバイス
に界面リリース・メッセージ（SurfaceReleaseMsg）に
より開放される１２９。最終状態は、表現デバイスに界
面表現１２１があり、インプレッシブ・デバイス上には
界面インプレッションがない状態である。
【０１８５】例４、図１５ 例１と同様、非要求インプレッション１２２がインプレ
ッシブ・デバイスにインプレス(刻印)される。インプレ
ッシブ・デバイスは、インプレッション１２２の記述に
より、次の動作を決定する。例えば、この例のようにオ
リジナルの界面メッセージ中の界面記述は完全ではな
い。インプレッシブ・デバイスは、記述要求メッセージ
（DescriptionRequestMsg）により、表現デバイスから
の情報を要求する。表現デバイスは、記述要求メッセー
ジに対して記述応答メッセージ（DescriptionReplyMs
g）により応答する。これには、さらなる記述が含まれ
る。
【０１８６】例５、図１６ 界面記述は、トップレベル界面のサブ界面、チャイルド
界面への参照を含む。例えば、アソシエーションとして
のｅマテリアル・エンコーディングは、チャイルド界面
を含む。例５はチャイルド界面Ａ１を有する界面Ａに関
する。各界面の表現１２１、１２３は、表現デバイスに
おいて提供される（または、この時点では界面の表現１
２１のみが供給される）。ついで、界面Ａは界面メッセ
ージにより、インプレッシブ・デバイスにインプレスさ
れる。インプレッシブ・デバイスは、界面要求メッセー
ジ（SurfaceRequestMsg）により、表現デバイスからの
チャイルド界面Ａ１のインプレッション要求を行う。こ
の要求は拒否または容認される。容認の場合、表現デバ
イスはさらなる界面メッセージ（SurfaceMsg）を送る
（表現が存在していない場合は、チャイルド界面Ａ１の
表現が生成された後）。最終状態は、表現デバイスに
は、界面Ａの表現１２１と、チャイルド界面Ａ１の表現
１２３、インプレッシブ・デバイスには、界面Ａおよび
チャイルド界面Ａ１の対応インプレッション１２２およ
び１２４である。
【０１８７】例６、図１７ インプレッシブ・デバイス上に界面インプレッションが
供給されると、インプレッシブ・デバイスは内容要求メ
ッセージ（ContentRequestMsg）により、内容要求を行
う。内容要求メッセージを受領すると、表現デバイス
は、要求を拒否するか、または要求されたフォーマット
にしたがって内容１２５を供給する。この内容は内容応
答メッセージ（ContentReplyMsg）により(この例で
は)、あるいは連続する内容応答メッセージ・シリーズ
により、あるいはストリームのような他の手段によって
送付される。
【０１８８】例７、図１８ インプレッシブ・デバイスがもはやインプレッションが
必要でないと決定した時（例えば、プリンタにおいてす
べてプリントされたドキュメントを表現する界面である
と確認された場合）、界面開放メッセージ（SurfaceRel
easeMsg）を表現デバイスに送付することによりインプ
レッションを開放する。この状態を図１８に示す。これ
は例６の状態に続くものである。内容がインプレッシブ
ロ・デバイスから要求され、受領されると、界面開放メ
ッセージ（SurfaceReleaseMsg）が表現デバイスに返さ
れ、インプレッションが非インプレスになったことを表
現デバイスに通知する。表現デバイスは、非インプレス
界面に関する相次ぐメッセージを無視する。
【０１８９】例８、図１９ 表現デバイスはそれ自体で表現１２８を消去できる。こ
れは、界面消去メッセージ（SurfaceDeleteMsg）をオリ
ジナル表現１２１のインプレッションを有するすべての
インプレッシブ・デバイスに送付することによって達成
される。メッセージは、表現が消去されたこと、表現デ
バイスが消去表現界面に関するすべてのメッセージを無
視することを含む。
【０１９０】例９、図２０ 表現界面のプロパティは、インプレッシブ・デバイスが
表現界面を変更することもしないことも可能なようにセ
ットすることができる（表現デバイスは常にこうするこ
とができる）。図２０は、表現デバイスによる表現界面
１２６の変更について示す。表現界面の変更は、オリジ
ナル表現に変更があったことを示す表現デバイスからす
べてのインプレッシブ・デバイスに対する界面変更メッ
セージ（SurfaceChangeMsg）を送付することによって反
映される。一般的にこれには新規な内容要求が続き、あ
るいは新規な記述要求を伴う場合もある。
【０１９１】例１０、図２１ この例では、インプレッシブ・デバイスがオリジナル表
現の変更を要求する。また、これは界面変更メッセージ
（SurfaceChangeMsg）によって実行される。これは表現
デバイスによって許可あるいは拒絶され得る。変更が許
可された場合、表現デバイスは、要求を発しているイン
プレッシブ・デバイスに対する確認と、残りのインプレ
ッシブ・デバイスに対する通知のためにすべてのインプ
レッシブ・デバイスに対して界面変更メッセージ（Surf
aceChangeMsg）をさらに送付する。変更が拒絶された場
合は、表現デバイスは、要求が拒絶された旨を要求を発
しているインプレッシブ・デバイスに通知する。
【０１９２】要求インプレッシブ・デバイスは、表現変
更の要求に成功したとき、一般的に更新された内容の要
求をする必要はない（他のインプレッシブ・デバイスは
必要となることが多いが）。これは、インプレッシブ・
デバイスは、表現デバイスに要求した記述に基づいて自
分の内容を更新することが可能であるからである。
【０１９３】例１１、図２２ 図２２は表現のインプレッションが２つあり、１つのイ
ンプレッシブ・デバイスによって変更要求が出力され、
これを表現デバイスが許可する状態を示す。同じ界面変
更メッセージ（SurfaceChangeMsg）が２つのインプレッ
シブ・デバイスに対して表現デバイスから送付される
（但し、表現デバイスがインプレッシブ・デバイスの機
器について十分知っている場合は、各インプレッシブ・
デバイスの要求を満足する形で界面変更メッセージを供
給することが可能である）。最終状態は、すべての界面
が変更を反映したものである。第２インプレッシブ・デ
バイス（変更要求をしていない）は、新しい内容を獲得
するために表現デバイスに対して内容要求メッセージ
（ContentRequestMsg）を送付することになるであろ
う。
【０１９４】ＪＩＰは、ジェットセンド・セッション・
プロトコル（ＪＳＰ）を利用する。上述したようにＪＳ
Ｐは、２つのデバイス間のセッションについて、その生
成及び消去、使用停止時についても管理する。ＪＳＰは
さらに基本アドレッシングに対するアクセス、高信頼メ
ッセージ転送プロトコル、さらにＪＩＰによって使用さ
れる他のタイプの転送プロトコルも提供する。
【０１９５】機器は、受動的に開始されたセッションを
有することも、また能動的に他とのセッションを開始す
ることもできる。ＪＩＰが受動的に開始されたセッショ
ンを保持するために、ＪＩＰは、ＪＳＰに特定の転送の
セッションをリッスンするように指示することが必要で
ある。ＪＳＰが転送のリッスンをすると、他の機器はＪ
ＳＰに対してその特定の転送上のデバイスをコールする
ように指示することで能動的にセッションを開始するこ
とができる。接続が確立すると、リモートおよびローカ
ルＪＳＰはＪＳＰのサポートするバージョンの交渉を
し、両ＪＩＰにセッションの確立が通知される。ＪＳＰ
はＪＩＰにこのセッションをマップするハンドルを供給
する。これらのセッション・ハンドルは、ＪＩＰがセッ
ション終了を望む場合等、ＪＩＰがセッションへの参照
を必要とするときにはいつでも使用される。
【０１９６】ＪＩＰの実行において、所与のセッション
に関連する界面についてのたくさんの状態（ｓｔａｔ
ｅ）を潜在的に保持する。ある環境においては、ＪＳＰ
は、デバイスがインプレッションや要求、内容データを
有している場合においてもセッションを終了することが
ある。例えば、デバイスのパワーダウン、あるいはＪＳ
Ｐにセッション消去を発生させるネットワーク・フェイ
ルが発生した場合等に起こる。ＪＩＰがセッション終了
を予期せずに通知されたときは、ＪＩＰはそのセッショ
ンが存在することによって意味のある生成物が残らない
ようにそのセッションに関連するローカル状態を解除し
なければならない。例えば、ローカルＪＩＰは発行済み
のインプレッションが開放され、内部状態を解除しなけ
ればならないことを伝える界面開放メッセージ（Surfac
eReleaseMsg）をもはや受け取らない。内容要求メッセ
ージ（ContentRequestMsg）、記述要求メッセージ（Des
criptionRequestMsg）においても同様である。
【０１９７】ＪＩＰは、ＪＳＰによって提供され維持さ
れるチャネルを介してメッセージを交換する。これらの
メッセージメチャネルは信頼できかつ整備されたもので
あることが必要である。ＪＳＰの実行形態では、各種の
タイプのチャネル、例えばストリーム・チャネルが提供
される。
【０１９８】２つの機器間においてセッションが確立す
ると、メッセージ・チャネルが生成可能となる。セッシ
ョンが確立すると、能動（ａｃｔｉｖｅ）ＪＩＰは第１
メッセージ・チャネルのオープンを要求する責務を持
つ。受動（ｐａｓｓｉｖｅ）ＪＩＰは、チャネルのリッ
スンを行う責務を有する。このように、受動ＪＩＰは接
続が確立するとすぐにチャネルのリッスンを行うように
ＪＳＰに指示する。チャネルのコール、クローズ、リッ
スンの機能はＪＳＰによって提供される。チャネルのオ
ープンのコールは、ＪＳＰがリモート・デバイスがチャ
ネルの受動的リッスンを行っていることの通知を与える
までは、ＪＩＰによって発行されることはない。
【０１９９】ＪＳＰが交渉を実行し、メッセージ・チャ
ネルをオープンすると、ＪＳＰはこのチャネルのハンド
ルをＪＩＰに付与する。ＪＩＰはこのチャネルによって
メッセージの送信及び受信を実行する。チャネルはネッ
トワーク・フェイルまたはクローズすべきコールによっ
てクローズされるまで有効である。セッションが確立
し、メッセージ・チャネルがオープンすると、接続のい
ずれかの側が追加チャネルのオープンを要求できる。こ
れら追加チャネルはＪＳＰにサポートされた任意のトラ
ンスポートでオープンされる。
【０２００】メッセージ・チャネルを介する内容データ
の送信に加え、ＪＩＰは２つの機器によってサポートさ
れたいかなる特定のチャネルを介する内容データの転送
も許容する。内容要求メッセージ（ContentRequestMs
g）及び内容応答メッセージ（ContentReplyMsg）のいず
れも内容データが転送されるチャネルの選択に関するフ
ィールドを有する。ＪＳＰのＣＥＸＴＬＳＮメッセージ
はどのタイプのチャネルがオープン可能かを示す情報を
含む。
【０２０１】ＩＰネットワークにおけるＪＳＰ／ＪＩＰ
の実行態様について説明する。ここでは、ＪＳＰによっ
て２つのタイプのチヤネル、すなわちＲＭＴＰを使用し
たメッセージ・チャネル、ＴＣＰを使用したストリーム
・チャネルがサポートされる。セッションが確立し、メ
ッセージ・チャネルが生成されると、各種のＪＩＰメッ
セージが行き来する。内容要求メッセージは、特定の存
在チャネル、メッセージ・チャネル、またあらゆるタイ
プのチャネルでの内容データ送付を指定することが可能
である。
【０２０２】手続きを以下に示す。まず第１に受信機器
は、内容要求メッセージ（ContentRequestMsg）をソー
ス機器に対して発行する。受信デバイスがソース・デバ
イスとの間にすでに存在するチャネル上のデータの受領
を希望する場合はその特定のチャネルをマップするソー
ス・デバイスのチャネル識別子を含むことによって要求
中で特定する。この識別子はチャネルの生成に関するＪ
ＳＰのＣＡＳＹＮメッセージ中に発見される。メッセー
ジ・チヤネル上の内容を受領することを希望する場合
は、チャネル識別子として０を用いる。チャネル及びチ
ャネル・タイプを特定しない場合は、チャネル識別子と
して１を用いる。
【０２０３】ＪＳＰストリーム・チャネルを介する内容
のＪＩＰによる送付形態はメッセージ・チャネルを介す
る内容の送付の方法とは異なる。メッセージ・チャネル
を介するＪＳＰによる内容データの送付は、ＣＨＮメッ
セージの形態による。メッセージとして内容が送付され
るとき、ＪＩＰは実際の内容データを含む内容応答メッ
セージ（ContentReplyMsg）を使用する。この内容応答
メッセージはＪＳＰに転送される。ＪＳＰはこれに対し
てＣＨＮメッセージ形態で変換する。内容の全体サイズ
に応じて、ＪＩＰは要求された内容の配送を達成するた
めに１つまたはそれ以上の内容応答メッセージを送付す
る。
【０２０４】しかし、ＪＩＰがストリーム・チャネルを
介して内容を送付する場合は内容応答メッセージは使用
されない。ＪＩＰはその送付のためにＪＳＰに生の内容
を渡す。
【０２０５】この特定チャネルの選択の機構は、デバイ
スが例えばストリーム・チャネルのような特定のチャネ
ルが使用され、セットアップされるように制御すること
を可能とする。デバイスは内容転送のためにいかなるオ
ープン・チャネルの使用、再使用も可能である。また、
要求、ページ、ジョブのために独立のチャネルをオープ
ンすることを強制されない。
【０２０６】機器間の最適なデータ交換を許容するた
め、すべてのＪＩＰメッセージは４バイト境界において
送信、受信されることが要請される。この要請はＪＩＰ
メッセージ・ヘッダの末尾にヌル（NULL）の埋め込みを
付加することを強制する。例えば界面メッセージ（Surf
aceMsg）のようなある有効長ＪＩＰメッセージ・ヘッダ
において、この埋め込みサイズは変化する。しかし、Ｊ
ＩＰメッセージ・フィールド自体はヘッダにおいて４バ
イトまたは偶数バイトの境界を強制されない。これは、
半端な列が存在することのないようにＪＩＰのメッセー
ジのパッキング及びアンパッキングを行なわせるもので
ある。
【０２０７】あるメッセージ・ヘッダは、可変長ＡＳＣ
ＩＩ−ストリング値を有する。これらのフィールドを定
義する最大値があり、この値は、以下の適当なメッセー
ジ記述に中に与えられる。数値を有する各メッセージ・
フィールドについては、値はネットワーク・バイトのオ
ーダー(すなわち、ビッグ・エンディアン：big-endian)
である。各メッセージ・フィールドには、プロトコル・
バージョンのフィールドがある。
【０２０８】ジェットセンド対話プロトコル中の各メッ
セージについて以下説明する。
【０２０９】［界面メッセージ：SurfaceMsg（インプレ
ス）］このメッセージは３つの状態において使用され
る。第１に、表現デバイスから他デバイスに界面転送を
開始するとき、第２に他デバイスからの界面要求メッセ
ージ（SurfaceRequestMsg）に対する応答として、第３
に、表現デバイスからの界面メッセージ（SurfaceMsg）
を拒否するのに使用される。状況フィールドはどの解釈
（インタープリテーション）が使用されるかを示すよう
にセットされる。
【０２１０】このメッセージが、界面転送の開始、また
は界面要求の応答として使用されるときは、送付デバイ
スはその界面テーブル中にエントリを生成するのでイン
プレッシブ・デバイスはその変更を知ることができる。
【０２１１】メッセージの受領において、宛先がインプ
レッションの受領を選択すると、界面テーブル中にイン
プレッションを表現に関連させてエントリを生成する。
これは表現デバイスに対して、界面の変更要求を望んで
いるタイミング、あるいはその終了時期を通知すること
を可能とする。もし、宛先がインプレッションの受領を
拒否した場合は、その拒否のために開放メッセージを返
し、テーブルのエントリの生成は行わない。後続のイン
プレッション関連のメッセージは無視される。
【０２１２】送信デバイスがインプレッションの開放メ
ッセージを受領したとき、テーブルからそのインプレッ
ションに関するエントリを削除する。これは、インプレ
ッションを開放したデバイスがそのインプレッション関
連のメッセージを受領しないことを保証する。
【０２１３】インプレッションの送信及びその拒否の開
放メッセージの受領の間には短い時間が存在する。この
期間に、表現デバイスはインプレッションが存在すると
判断する可能性がある。しかし、これは実際的な問題を
発生させない。これは発行が受信エンドで処理されるか
らである。インプレッシブ・デバイスは受領していな
い、あるいは保有していないインプレッションに関する
メッセージを無視することが要請される。
【０２１４】メッセージ・フィールドは以下に示す通り
である。
【０２１５】
【表３】
【０２１６】これらのフィールドについてまだ説明がな
されていない不明確な部分について簡潔に述べる。 メッセージ・タイプ：メッセージ・タイプはプロトコル
中においてそのメッセージを他のメッセージと固有に識
別する。インプレス・メッセージにおけるこのメッセー
ジ・タイプ・フィールドは０ｘ００にセットされる。
【０２１７】ソース界面識別子：表現デバイスによって
界面に割り当てられる識別子であり、最初のインプレッ
ションが生成されてから最後のインプレッションがアン
インプレスされるまでの期間において固有のものであ
る。この識別子はプロトコルによって界面をそれぞれ識
別するのに用いられる。値０、１がリザーブされる。０
はＮＵＬＬ界面を意味し、１はデフォルト・ターゲット
界面を指定するのに用いられる(前述したようにワーク
界面に用いられる)。
【０２１８】ソース界面クラス：これは、ソース界面の
クラスである。クラスは界面の使用を決定するのに用い
られる。リーガル・クラスの値は以下の表４に示され
る。
【０２１９】
【表４】
【０２２０】各クラスの使用については、さらに対話ポ
リシーの議論において示される。プロトコルの将来的な
バージョンでは、このフィールドに新たな値が加わるか
もしれない。デバイスが界面の特定のクラスのハンドル
ができないとすることも可能である。このようなデバイ
スはこれらの界面をすべて無視するか、そのクラスのす
べての界面をデバイスがハンドルするクラスとは異なる
ものとして取り扱う。
【０２２１】ソース界面バージョン：これは界面の現在
のバージョンである。プロトコルは使用される各界面の
バージョン番号を保持する。これは表現デバイスが界面
の変更を実施するごとに更新される。
【０２２２】ソース界面プロパティ：これはインプレス
される界面のプロパティである。このフィールドの値、
および意味は以下の表５に示す通りである。
【０２２３】
【表５】
【０２２４】これは、表現デバイスが界面メッセージに
応答し、界面変更メッセージの受領を行うことを示す値
３を加えることによって他の実行形態に拡張することが
可能である。
【０２２５】ターゲット界面識別子：このフィールドは
ターゲット界面の界面識別子を含む。この値が１のと
き、ターゲットは目的地におけるデフォルト・ターゲッ
ト界面または作業（work）界面となる。あるいは、この
フィールドはターゲット界面の先のインプレッションか
らの界面識別子を含まなければならない。
【０２２６】リザーブ：後の使用のために留保され、Ｎ
ＵＬＬにセットされている。ステータス界面メッセージ
の状態を識別する。以下に示す値の定義がなされてい
る。
【０２２７】
【表６】
【０２２８】要求識別子：先の界面要求メッセージの結
果としての界面メッセージに関し、このフィールドは対
応界面の界面要求メッセージ中に含まれる要求識別子に
セットされる。他の状態ではこのフィールドは０にセッ
トされる。
【０２２９】インプレス識別子：表現デバイスによって
割り当てられた固有の識別子である。これは同じ界面に
おける異なるインプレッションの識別を行う。この識別
子は界面の各インプレッションについてユニークであり
さえすればよい。他の界面のインプレッションが同じ識
別子を持つこともある。表現識別子がすべてのローカル
界面に渡って固有のものであるので、インプレス識別子
は特定のローカル界面に関連するインプレッションのセ
ット中において固有のものであればよい。
【０２３０】ソース界面ネーム長：これはＮｕｌｌター
ミネート・ＡＳＣＩＩストリング・ソース界面ネームの
バイト長（Ｎｕｌｌバイトを含む）である。このフィー
ルドの最大値は６４である。
【０２３１】ソース界面ネーム：これはインプレスされ
る界面の界面ネームである。ネームはＡＳＣＩＩ文字の
ＮＵＬＬターミネート・シーケンスである。
【０２３２】ターゲット・アドレス長：これはＮｕｌｌ
ターミネート・ターゲット・アドレス・ストリングのバ
イト長（Ｎｕｌｌバイトを含む）である。このフィール
ドの最大値は２５６である。
【０２３３】ターゲット・アドレス：ターゲット・アド
レスはターゲット・デバイスのセッション・プロトコル
・アドレスである。インプレス(刻印)処理は、常にター
ゲット・デバイス及びターゲット界面を有している。多
くの処理において、１つのソースおよびターゲットが含
まれる。しかし、プロトコルは、１つのデバイスに第２
デバイスからのインプレッションのインプレス(刻印)
を、第３デバイスのインプレッション上に行うことを許
容する。この場合、第３デバイスは、そのジェットセン
ド・セッション・プロトコル・アドレスによってのみ識
別できる。従って、プロトコルはターゲット・デバイス
・セッション・プロトコルの明示スペックを許容する。
ターゲット・アドレスが界面メッセージの宛先と同じで
ある場合、アドレス長フィールドは０にセットされ、タ
ーゲット・アドレスは持たない。
【０２３４】他のメッセージに対する応答としての界面
メッセージの使用についてまとめた表を以下の表７に示
す。
【０２３５】
【表７】
【０２３６】界面消去メッセージ（SurfaceDeleteMsg）
（Delete） このメッセージは表現デバイスからインプレッシブ・デ
バイスに対して表現が消去されたことを通知するのに使
用される。表現デバイスが表現を消去する場合、その消
去されるインプレッションを保有するすべてのインプレ
ッシブ・デバイスに通知することが必要である。また、
表現及びそのインプレッションのエントリを界面テーブ
ルから消去しなければならない。また、その後のその表
現及びインプレッション関連のメッセージは無視するこ
とになる。
【０２３７】インプレッシブ・デバイスは、消去メッセ
ージを受け取ると、その消去界面のインプレッションに
関するすべてのエントリを界面テーブルから消去する。
また、以降はこのインプレッションに関するいかなるメ
ッセージも生成しない。
【０２３８】表現デバイスがメッセージを発してからイ
ンプレッシブ・デバイスがそれを受領し界面テーブルか
らインプレッションを消去するまでには短い時間間隔が
ある。従って、インプレッシブ・デバイスはこの期間に
表現関連のメッセージを送付する可能性があるが、これ
は、表現デバイスが消去した表現関連メッセージを無視
するので実際的な問題にはならない。メッセージ・フィ
ールドは以下の表8に示すようにセットされる。
【０２３９】
【表８】
【０２４０】メッセージ・タイプ：界面消去メッセージ
のメッセージ・タイプ・フィールドは０ｘ０１にセット
される。
【０２４１】消去表現識別子：これは表現デバイスが消
去する界面の界面識別子である。表現デバイスはこの界
面識別子を有する後続のメッセージを無視する。プロト
コルは非同期であるので、ネットワーク上の界面に関す
るメッセージ存在する場合がある。
【０２４２】界面開放メッセージ（SurfaceReleaseMs
g）（Unimpress） このメッセージはインプレッシブ・デバイスから表現デ
バイスに、インプレッションがアンインプレス（インプ
レス解除）されたことを通知するメッセージである。イ
ンプレッシブ・デバイスがインプレッションを必要とし
なくなると、界面テーブルからこれを消去し、表現デバ
イスに界面開放メッセージを送付する。インプレッシブ
・デバイスは、さらにこの消去インプレッションに関す
るすべてのメッセージを無視する。デバイスは同じ界面
の複数のインプレッションを保持することができる。こ
の場合、インプレッシブ・デバイスはアンインプレスさ
れたインプレッションに限定して関連するメッセージの
みを無視する。
【０２４３】表現デバイスがこのメッセージを受領する
と、その界面テーブルからそのインプレッション関連の
エントリを削除する。表現デバイスは、このインプレッ
ションに関するいかなるメッセージもその関連インプレ
ッシブ・デバイスに送付しない。
【０２４４】インプレッシブ・デバイスがメッセージを
発してから表現デバイスがそれを受領し界面テーブルか
らエントリを消去するまでには短い時間間隔がある。従
って、表現デバイスはこの期間にインプレッション関連
のメッセージを送付する可能性があるが、これは、イン
プレッシブ・デバイスがアンインプレスされた表現関連
メッセージを無視するので実際的な問題にはならない。
【０２４５】
【表９】
【０２４６】メッセージ・タイプ：界面開放メッセージ
のメッセージ・タイプのフィールドは０ｘ０２にセット
される。
【０２４７】アンインプレス表現識別子：これはインプ
レッシブ・デバイスによってアンインプレスされたイン
プレッションに対応する表現の界面識別子である。これ
がインプレッシブ・デバイス上のその表現の最後のイン
プレッションである場合は、そのデバイスはこの界面識
別子を含む後続のメッセージを無視する。
【０２４８】アンインプレス・インプレス識別子：各界
面メッセージは表現デバイスによって固有の識別しが割
り当てられる。これはデバイスが同じ界面の複数のイン
プレッションを区別することを可能とする。インプレッ
ションがアンインプレスされると、界面開放メッセージ
のインプレス識別子により、表現デバイスは、どのイン
プレッションがアンインプレスされたかを知ることがで
きる。
【０２４９】他のメッセージに対する界面開放メッセー
ジの使用についてまとめた表を以下の表１０に示す。
【０２５０】
【表１０】
【０２５１】界面要求メッセージ（SurfaceRequestMs
g） このメッセージは他のデバイスからのインプレッション
を要求するデバイスによって使用される。メッセージは
あるデバイスに対して要求者上にインプレッションを生
成するように要求する。ネームはリモート・デバイス上
で有効な界面ネームである場合とない場合がある。ネー
ムが有効である場合は、リモート・デバイスはその要求
者にインプレッションを生成する。ネームが有効でない
場合、要求は拒絶される。ターゲット界面識別子は、リ
モート・デバイスがそのインプレッションを有する表現
の有効な識別子であることが必要である。さもなけれ
ば、要求は拒絶される。
【０２５２】表現デバイスは界面要求を受領すると、必
要に応じて要求界面を生成し、要求デバイスにこれをイ
ンプレスするのに必要なインプレス・メッセージを使用
する。また、要求が無効である場合は、表現デバイスは
要求を拒否する。インプレスまたは拒否メッセージ中の
要求識別子は基の要求メッセージの要求識別子と同じで
なければならない。
【０２５３】
【表１１】
【０２５４】メッセージ・タイプ：界面要求メッセージ
のメッセージ・タイプのフィールドは０ｘ０３にセット
される。
【０２５５】ソース界面ネーム長：これはＮｕｌｌター
ミネート・ＡＳＣＩＩストリング・ソース界面ネームの
バイト長（Ｎｕｌｌバイトを含む）である。このフィー
ルドの最大値は６４である。
【０２５６】ソース界面ネーム：これはデバイスがその
インプレッションを望んでいる界面のネームである。ネ
ームはＮｕｌｌターミネート・ＡＳＣＩＩストリングで
ある。
【０２５７】ソース界面クラス：これはデバイスがその
インプレッションを望んでいる界面のクラスである。２
つの表現は同じネームを持つことがあるが、このクラス
によって区別される。
【０２５８】ターゲット界面識別子：これは要求される
界面メッセージあるいはインプレッションのターゲット
として使用される界面の識別子である。表現デバイスは
要求界面のインプレスを確実に行うためにこの界面のイ
ンプレッションを保有する必要がある。このターゲット
界面識別子は、全てのデバイスが暗黙にインプレッショ
ンを保有する場合は、デフォルト・ターゲット界面
（１）をセットする。
【０２５９】要求識別子：この識別子はプロトコルによ
って割り当てられ、界面要求メッセージを同じ界面に対
応する他の要求と識別する。
【０２６０】他のＪＩＰメッセージとの関連についてま
とめた表を以下の表１２に示す。
【０２６１】
【表１２】
【０２６２】記述要求メッセージ（DescriptionRequest
Msg） このメッセージはインプレッシブ・デバイスが保有する
インプレッションの界面記述を要求するために使用され
る。インプレッション識別子は要求デバイスによって保
持される有効なインプレッションでなければならない。
表現デバイスがさらなる記述要求を受領したときは、要
求された記述を返す応答を行う記述を使用する。記述要
求は応答がデータを含んでいなくても拒絶されたものと
は限らない。
【０２６３】
【表１３】
【０２６４】メッセージ・タイプ：記述要求メッセージ
のメッセージ・タイプのフィールドは０ｘ０４にセット
される。
【０２６５】インプレッション界面識別子：これは記述
が要求された界面のインプレッション識別子である。
【０２６６】要求識別子：これは要求デバイスによって
割り当てられた固有の識別しであり、記述要求メッセー
ジを他の発行される記述要求と区別するものである。
【０２６７】
【表１４】
【０２６８】記述応答メッセージ（DescriptionReplyMs
g） このメッセージは、記述要求メッセージに応答して界面
の記述を返すために使用される。不良な要求に対する結
果はデータを含まず、その要求に対する記述はこれ以上
ないことを示す。界面のインプレッションを提供したデ
バイスは、その界面の完全な記述を提供する用意をする
べきであるので、記述要求に対する拒否の可能性はな
い。記述応答はその応答に対応する記述要求の要求識別
子を含む。
【０２６９】
【表１５】
【０２７０】メッセージ・タイプ：界面要求メッセージ
のメッセージ・タイプのフィールドは０ｘ０５にセット
される。
【０２７１】インプレッション界面識別子：これは記述
が返された界面のインプレッション識別子である。
【０２７２】要求識別子：これは、このメッセージが応
答となる記述要求メッセージからの要求識別子である。
【０２７３】
【表１６】
【０２７４】内容要求メッセージ（ContentRequestMs
g） このメッセージはインプレッシブ・デバイスが表現デバ
イスに対してある内容データを要求する場合に使用され
る。インプレッション識別子は要求デバイスの保持する
有効なインプレッションでなければならない。
【０２７５】送付デバイスはストリーム接続を介して交
換される内容データを要求する。デバイスはこの内容要
求を受領すると、要求に応じて新しいストリームを生成
してストリームに内容を送信する。受信デバイスがスト
リームをサポートしない場合は、内容応答メッセージの
列として内容を送り返す。従って、要求デバイスがスト
リームを介する転送要求をする場合は、ストリームある
いは内容応答メッセージ列、いずれかの内容受領を準備
することが必要である。
【０２７６】
【表１７】
【０２７７】メッセージ・タイプ：内容要求メッセージ
のメッセーシ・タイプのフィールドは０ｘ０６にセット
される。
【０２７８】ソース界面識別子：内容が要求される界面
の表現識別子である。
【０２７９】要求識別子：要求デバイスによって割り当
てられ、内容要求メッセージを他の内容要求と区別する
固有の識別子である。
【０２８０】チャネル要求識別子：これはリモート・デ
バイス上での例えばストリーム・チャネル等の内容要求
に対する応答の書込みに使用される特定のチャネルを識
別する。正の数は存在する有効チャネルを示す。この番
号はリモート・デバイスの実際のチャネル識別子である
べきである。０は、実在するメッセージチャネル上で内
容メッセージを介して内容データが送信されることを示
す。負の数は受信側が新しいストリームによって内容デ
ータの送信を望んでいることを示す。
【０２８１】他のＪＩＰメッセージに対する応答におけ
るこのメッセージの使用についてのまとめを以下の表１
８に示す。
【０２８２】
【表１８】
【０２８３】内容応答メッセージ（ContentReplyMsg） このメッセージは表現デバイスがインプレッシブ・デバ
イスに対してある内容メデータを送付する際に使用され
る。単一の内容要求に対して内容データ・メッセージの
シーケンスとなる場合もある。このメッセージは内容−
タの要求に対する拒否にも使用される。
【０２８４】内容の提供者はデータをストリームを介し
て提供する場合、ストリーム・フィールドをストリーム
識別子にセットし、内容長およびデータを空のままとす
る。内容提供者がストリームをサポートしない場合、ま
たはこの目的ではストリーム使用ができない場合は、ス
トリーム識別子を０にセットし、内容応答メッセージ列
として内容データを転送する。この場合、内容長及びデ
ータはメッセージの内容を運ぶのに使用される。
【０２８５】一般的に、内容応答メッセージは内容提供
者が内的理由により要求に応じない場合や、要求が無効
である場合の内容要求の拒否に用いられる。
【０２８６】すべての場合において、応答における要求
識別子は元の要求中に含まれる要求識別子にセットされ
る。
【０２８７】デバイスは内容応答を受領すると、応答が
拒否されたかを確認する。その場合、デバイスは、次の
アクションについて決定しなければならない。応答が拒
否でない場合、デバイスは内容がストリームによって供
給されているか否かについて判定する。内容がストリー
ムで供給されている場合、そこから読み出しを実行す
る。そうでなければ、内容はそれと後続の応答から読み
出す（転送は応答の列に形成され、状況フィールドは列
の最終応答を識別する）。
【０２８８】
【表１９】
【０２８９】メッセージ・タイプ：内容応答メッセージ
のメッセージタイプは０ｘ０７にセットされる。
【０２９０】ソース界面識別子：この内容データの界面
の表現界面である。
【０２９１】要求識別子：これが応答となる元の内容要
求メッセージからの要求識別子である。
【０２９２】状況（ステータス）：これはメッセージの
状況を示す。リーガル値は以下の表２０のようにセット
される。
【０２９３】
【表２０】
【０２９４】チャネル識別子：内容データが送られる受
信器のチャネル識別子である。正の数は特定のチャネル
を示し、０または負の数は任意に選択されたメッセージ
・チャネルを介したメッセージとして内容が送付される
ことを示す。
【０２９５】他のＪＩＰメッセージに対する応答中の内
容応答メッセージの使用は表２１のようにまとめられ
る。
【０２９６】
【表２１】
【０２９７】ＪＩＰがＪＳＰストリーム・チャネルを介
して内容を送付する場合、内容応答メッセージは内容送
付に用いられない。ＪＩＰは特定のストリーム・チャネ
ルを介して送付するために生内容をＪＳＰに渡す。
【０２９８】内容転送のストリームにおいて、内容要求
に対応するデータの最終ブロックをＪＩＰが送付すると
き、ＪＩＰはその要求に対する内容転送の終了を示して
ストリームをクローズする。
【０２９９】メッセージ・チャネルにおける内容提供を
説明する図を図２３に示す。メッセージ・チャネル上で
の内容提供は受信デバイスによって要求され、内容応答
メッセージ列として供給される。その最後の１つの状況
フィールドは１にセットされている。ストリーム・チャ
ネル上の内容提供について説明する図が図２４である。
ストリーム・チャネル上での内容提供は受信デバイスに
よって要求され、ストリーム・チャネルを介した生内容
として供給される。その最後の内容には送信側によって
ストリームのクローズの信号が付加されている。
【０３００】界面変更メッセージ（SurfaceChangeMsg） このメッセージは３つの目的において使用される。第1
は、表現デバイスからインプレッシブ・デバイスに対す
る界面変更の通知である。第２は、インプレッシブ・デ
バイスによる表現の変更要求である。第３は、インプレ
ッシブ・デバイスに対する表現変更要求の失敗を通知す
ることである。
【０３０１】表現デバイスはその表現の１つの変更を行
うとき、すべてのインプレッシブ・デバイスに変更の通
知を行わなければならない。これは界面テーブルのイン
プレッションを検出し、各インプレッシブ・デバイスに
変更メッセージを送付することで行われる。デバイスが
多重インプレッションを有するときは、各インプレッシ
ョンに対して変更メッセージを送付する必要はない。イ
ンプレッシブ・デバイスは表現とインプレッションのリ
ンクを保持している。
【０３０２】インプレッシブ・デバイスは変更メッセー
ジを受領すると、変更表現に係るインプレッションの変
更を実行する。ある場合においては、変更メッセージは
変更自体を含み、ある場合は、メッセージは通知のみを
行い、インプレッシブ・デバイスはその変更界面の内容
の再フェッチを行うことが必要となる。表現デバイスが
各インプレッシブ・デバイスに必要な内容のエンコーデ
ィングについて知っている場合は、表現デバイスはその
インプレッシブ・デバイスに必要なフォームの内容をそ
れぞれ含むそれぞれに分離された変更メッセージを提供
するように構成することが可能である。
【０３０３】インプレッシブ・デバイスはインプレッシ
ョン中の１つの変更を望む場合、表現デバイスに対する
変更要求のために変更メッセージを用いる。インプレッ
シブ・デバイスは変更が適用される表現のバージョンを
メッセージ中に含ませなければならない。
【０３０４】変更要求メッセージを受け取ると、表現デ
バイスは変更を許可するか拒否するかを決定する。その
決定は、バージョンおよび要求の質に基づく。表現デバ
イスは要求者に対して適当な状況セットを伴う変更メッ
セージにより、変更が許可されたか拒否されたかを通知
する。表現デバイスは、さらにすべてのインプレッシブ
・デバイスに対して、前述したように変更メッセージを
用いて許可された変更の通知を行う。
【０３０５】正常に変更要求を発行したインプレッシブ
・デバイスは変更に関する２つの通知を受領する。１つ
は変更許可に関する通知（その特定のデバイスに送付さ
れる）であり、もう１つは変更通知である、これは、表
現のインプレッションを有するすべてのデバイスに送付
される。これらのメッセージは要求識別子またはバージ
ョン情報のいずれかから、同じ変更に関して識別可能で
ある。
【０３０６】
【表２２】
【０３０７】メッセージ・タイプ：界面変更メッセージ
のメッセージ・タイプのフィールドは０ｘ０８にセット
される。
【０３０８】変更界面識別子：これは変更される界面の
表現識別子である。
【０３０９】オリジナル界面バージョン：表現デバイス
が界面のいずれのバージョンが変更されたか、及び界面
のどの状態のインプレッションが含まれるかを判別する
ために各界面はバージョン番号を有する。このフィール
ドは変更が適用される以前の界面のバージョン番号を含
んでいる。
【０３１０】新界面メバージョン：表現デバイスがイン
プレッシブ・デバイスに界面の変更を通知するために界
面変更メッセージを発行したとき、このフィールドは変
更が適用された後の新バージョン番号を含む。これは表
現デバイスがバージョン番号のスキップを行うことを可
能とする。あるいは、このフィールドは０にセットされ
る。
【０３１１】ステータス(状況)：このフィールドはこの
本校メッセージの状況を特定する。リーガル値及び意味
についてまとめた表を以下の表２３に示す。
【０３１２】
【表２３】
【０３１３】他のＪＩＰメッセージに対する応答中の界
面変更メッセージの使用についてまとめた表を以下の表
２４に示す。
【０３１４】
【表２４】
【０３１５】対話ポリシーは、ある共通のＪＩＰの使用
に対応して定義される。これらの対話ポリシーはＪＩＰ
の機能に不可欠ではないが、ＪＩＰによって行われる情
報交換の有用な適用ににおける鍵となる多くのプロセス
の一貫した取り扱い、を理解するのに有効である。
【０３１６】以下のポリシーが、この実行形態において
定義される。 ＊セッション・ポリシー：デバイス間のセッションの確
立及び解消時期 ＊ジョブ・ポリシー：送信、受信間でのドキュメントの
送信方法 ＊セルフ・ポリシー：ラベル、アイコン、パスワード等
のデバイスに関する包括的情報の交換方法 ＊ステータス・ポリシー：デバイス及びジョブに関する
状況の付与方法 ＊アドレス・ポリシー：新しいアドレスでのデバイスの
プログラム方法
【０３１７】すべてのデバイスにおいて、すべてのポリ
シーが意味を有するわけではない。各ポリシーの議論に
おいて、適用されるデバイス・タイプが明らかになるで
あろう。ポリシーは一般的にオプション（２つのデバイ
スが接続され、情報交換をするのに必要なセッション・
ポリシーのあるフォームを例外として）である。もし、
２つのデバイスが特定のポリシーをサポートする場合、
そのポリシを実行して情報交換を行う。もし、セッショ
ン中の１つのデバイスのみがポリシーをサポートする場
合は、そのポリシーは無視される。
【０３１８】好ましい最小のデバイス実行形態はジョブ
・ポリシーをサポートするデバイスを含んだものであ
る。セルフ・ポリシー、ステータス・ポリシーのデバイ
ス状況部分をサポートすることがデバイスにとってはさ
らに有効である。
【０３１９】一般に、各ポリシーは付与クラスの界面の
グループに関連する（例えば、セルフポリシー中に表現
された界面はＳＥＬＦ（値：２）のクラスである）。付
与ポリシーの範囲において、付与クラスの界面は、ネー
ムあるいはそれらが出現する文脈、前後関係によって識
別される。ここではこのような界面を周知界面（well-k
nown surface）と呼ぶ。これは、これらがデバイスによ
く知られた意味を有するからである。
【０３２０】所与の周知界面において、ポリシーは、そ
れが保持しなければならないエンコーディングについて
定義する（例えば、セルフポリシーのラベル界面はｖ−
テキスト・エンコーディングを含む）。このようなエン
コーディングの詳細は以下のｅ−マテリアルの議論にお
いて説明する。各周知界面は、サマリー・フォームにお
いて図式的に表現される。セルフ界面のこのような表現
を図２５に示す。この図において、界面ネーム（ｎａｍ
ｅ）は“ｓｅｌｆ”、クラス（ｃｌａｓｓ）がＳＥＬ
Ｆ、界面エンコーディング（ｅｎｃｏｄｉｎｇ）がｖＰ
ｌａｎｅである。これはキーとなる属性の概要であり、
インプレスに使用される界面メッセージには更にデータ
が含まれる。個々の対話ポリシーを以下に説明する。
【０３２１】セッション・ポリシー デバイスは、ジェットセンド・セッション・プロトコル
を用いてセッションのオープン、クローズを行う。セッ
ション・ポリシーはデバイスのセッシヨンのオープン及
びクローズ時期を特定する。基本的ポリシーはセッショ
ンを開いた（オープンした）デバイスがこれを閉じる
（クローズする）。一般に、セッションは、転送を始め
たデバイスによって開かれる。
【０３２２】ジェットセンドは、各種の転送プロトコル
を介するセッションの確立において使用される。適用さ
れるセッション・ポリシーは下層のトランスポート層及
びプロトコルの性質に大きく依存する。直接接続プロト
コル（例えば、ＩｒＤＡやＩＥＥＥ１２８４）は、セッ
ションが、自動的に近接あるいは物理的接続により確立
され、デバイスが近接状態でなくなると閉じるものなの
で明解である。同様の考え方が小さなネットワークある
いはバス（例えばＩＥＥＥ１３９４、ＳＣＳＩ）に適用
できる。バス上のすべてのデバイスは自動的にお互いに
セッションを確立し、明示的セッションのオープン及び
クローズは必要としない。転送プロトコルとしてＩＰを
用いるＬＡＮまたはＷＡＮのような大きなネットワーク
では、その要求に応じて明示的にセッションを開き、閉
じることが必要である。以下に議論する考察は主にこの
ようなネットワークに関する。
【０３２３】送信側 一般に、情報の送信側（例えばスキャナは情報送信をプ
リンタに対して行う）が受信側へのセッションを開く。
これはユーザのアクションまたは他の理由によって達成
される。一般的に送信側が受信側とのセッションを確立
し、開始情報を交換し、ジョブを開始し、データ転送が
終了するとセッションが閉じられる。このように送信側
がセッションのオープン及びクローズを制御する。これ
は一般にユーザによって制御される。デフォルトのセッ
ションは送信側がジョブを開始する直前にセッションを
開くように動作する。セッションは、ジョブの終了、ま
たは受信側から供給されるジョブ・ステータスの観察を
終了した時点で閉じられる。いくつかの場合、セッショ
ンは、送信側がリモート・デバイスの状況をモニタする
ことができるように開かれたままに維持されることもあ
る。
【０３２４】多くの送信側はセッションのリッスンを行
い、リモート・デバイスからのセッションを受け入れ
る。例えば、リモート・デバイスが送信側の状況（ステ
ータス）を知るために接続を望むことがある。プル・オ
ペレーション（ジョブ・ポリシーの項でさらに詳細に述
べる）の場合、受信側は、セッションを開き、ドキュメ
ントを要求し、セッションを閉じる。続いて、デバイス
に情報引き出しを認める送信側は、これを可能とするた
めにセッションを聴く。
【０３２５】受信側 一般的に、受信側は送信側デバイスによって開始される
セッションのリッスンを行う。セッションが確立すると
送信側との情報交換を行い、リモート・デバイスのジョ
ブ開始を待ち、さらにセッションを終了する。ある場合
は、ジョブは開始されない（例えば、送信側が端に受信
デバイス状況のモニタを行う場合）、このときは、受信
側は送信側がジョブを送信するか、セッションを閉じる
のを待つ。情報引き出しを行う受信側は、上述のように
必要に応じてセッションのオープン、クローズを行う。
【０３２６】リモート・デバイスからのセッションの許
容においてはリソース管理の問題がある。受信側は許容
できるセッション数に限界を持つかもしれない。受信側
は一般に他の送信側とのアクセスがブロックされないよ
うに確認することが必要である。例えばオープン・セッ
ション数には限界がある。リソース管理に問題がある
と、新しいデバイスがセッションのオープンを要求し、
接続中のデバイスがジョブ送信を行っていないときに、
受信側は接続セッションを閉じて新しいものを開始する
かもしれない。しかし、現在接続されているデバイスが
ジョブを送付すれば、受信側は新しいデバイスからのセ
ッション要求を拒否する。
【０３２７】いくつかのデバイスは、送信側、受信側の
双方の動作を行い、上述のようにセッションのリッスン
及びセッションの開始を行う。あるデバイスは送受信を
行わず、状況の提供または観察、あるいはアドレスの交
換等のみを行うものもある。このようなデバイスはその
処理要求に従ってセッションのオープン及びクローズ行
う。
【０３２８】ジョブ・ポリシー ジョブ・ポリシーはデバイス間でのドキュメントの効果
的送付を可能とする。ジョブ・ポリシーは送信側と受信
側間でのジョブ開始を２つの方法でサポートする。送信
側がジョブ開始する“プッシュ”、受信側がジョブ開始
する“プル”である。ジョブの開始とは離れて、いずれ
の場合も、受信側が基本的に転送のその後の手続きを制
御し、送信側は受信側の要求を満足するように動作す
る。
【０３２９】セッションはジョブ・ポリシーが使用可能
となる前に確立されなければならない。ジョブ・ポリシ
ーは受信側が送信側に提供するイン界面と呼ばれる周知
界面と関わっている。ジョブがプッシュまたはプルによ
って開始されると、すべての受信側はある時点で、それ
らに接続されたデバイス上にイン界面をインプレスす
る。これは、ドキュメントの受信が可能であることを示
す。受信側にドキュメント送付を望むデバイスはイン界
面を受信するまで待機しなければならない。イン界面を
受信すると、送付するドキュメントのトップ・レベル界
面のターゲットとしてイン界面の界面ハンドルを用い
る。この処理はジョブ・スタートとしても知られてい
る。ジョブは、送信側あるいは受信側がトップ・レベル
界面を開放したとき、あるいは両者間のセッションがク
ローズしたときに終了したとみなされる。
【０３３０】図２７にイン界面の図式的表現を示す。イ
ン界面のクラス（ｃｌａｓｓ）はＩＮ（３）となる。ネ
ーム（ｎａｍｅ）及びエンコーディング（ｅｎｃｏｄｉ
ｎｇ）はイン界面のトランスミッタによって決定される
(イン界面のトランスミッタはドキュメントの受信者と
なる)。イン界面は界面メッセージによって送付され
る。界面メッセージを受領したデバイスはその中の界面
ＩＤをジョブ開始時のターゲットＩＤとして用いる。イ
ン界面をサポートするデバイスは界面要求メッセージを
サポートしなければならない。デバイスはイン界面を要
求したとき、要求中で、ネームを特定する必要はない
が、特定している場合は、イン界面の所有者はネームが
認識された場合にその要求を認める。イン界面の界面記
述はどのようなものでもよいが一般にＮＵＬＬである。
【０３３１】ジョブ・ポリシーに従ったドキュメント転
送のサンプル例を図２６に示す。そのステップを以下に
説明する。
【０３３２】１．受信側はイン界面を界面メッセージ
（SurfaceMsg）により送信側にインプレスする。界面は
界面ＩＤ：ｉｄ１、ネーム：イン（ｉｎ）界面クラス：
ＩＮ（０ｘ０３）を有する。界面プロパティ・フィール
ドは１、ターゲットは“ＮｏＴａｒｇｅｔ”である。送
信側は界面クラスに基づいて、これがイン界面であると
認識する。 ２．これは“プル”モードについてのみ適用される。受
信側は対象の界面の要求を行う。界面要求メッセージ
（SurfaceRequestMsg）中のターゲット界面ＩＤはイン
界面にセットしなければならない。また、ソース界面の
ネーム（及び／またはクラス）を何を受信するかに基づ
いてセットする。要求界面のネーム及び／またはクラス
は予め知られている。ネームがエンプティの場合は、受
信側がデフォルト・データを送付する。 ３．“プッシュ”においては、このステップはジョブ開
始に際し送信側によって、ジョブのトップ・ラベル界面
を受信側のイン界面にインプレスすることで行われる。
“プル”においては、ジョブ開始時に同様に行われる
が、この場合は、受信側からの界面要求に応答する形態
である。界面ターゲットは受信側のイン界面の界面ＩＤ
にセットされる。 ４．この例では、トップ・レベル界面は他の界面への参
照を含み、受信側はネームによってこれらの参照の１つ
を要求しはじめる。受信側は要求ＩＤ（ｒｅｑ１）を持
つので、その要求に合わせることができる。 ５．送信側は要求界面をインプレスする。界面ＩＤはｉ
ｄ３である。 ６．受信側は界面の内容を要求（ContentRequestMsg）
する。 ７．送信側から１つまたはそれ以上の内容応答（Conten
tReplyMsg）が送付される。 ８．受信側は要求界面を開放（SurfaceReleaseMsg）す
る（これは新たな内容が不要であることを示す）。 ９．受信側はトップレベル界面の開放を行いジョブの終
了を示す。受信側はこの時点では受領データの処理を行
っていないかもしれないが、送信側は界面を任意に開放
できる。
【０３３３】上述の例は、単一ジョブの転送である。ジ
ョブ・ポリシーは所定の送信側から所定の受信側への多
数のジョブの実行も可能とする。これはジョブ・エレメ
ントがその界面ＩＤによって区別できるからである。送
信側は受信側に接続されたイン界面上にマルチプル界面
をインプレスする。。
【０３３４】どのようにマルチプル・ジョブを扱うかは
デバイスの選択による。ある送信デバイスは一度に１つ
のジョブの送信が可能であり、ある受信デバイスは単一
ジョブまたは限られた数のジョブの処理が可能である。
ジョブが処理中であるときに新しいジョブが入力された
場合の扱いは受信デバイスの選択による。選択は、以下
のものがある。 ＊現在のジョブと並行に新規ジョブを処理する。 ＊行列（キュー）に新しいジョブを位置づけ、リソース
が許せば処理を開始する（例えばジョブ・ステータスを
ジョブ・ペンデイング（JobPending）にセットする）。 ＊新規ジョブを拒否する（トップレベル界面を開放し、
ジョブ・ステータスをジョブ・フェイル（JobFailed）
にしてセットする）。
【０３３５】ジョブ状態（ステータス）について、ステ
ータス・ポリシーに基づき、さらに以下で説明する。
【０３３６】デバイスは受信機、送信機、あるいはその
両者となり得る。いずれにも該当しないデバイスはジョ
ブ・ポリシーを実行しない。スキャナ、ＰＤ、カメラ等
の送信デバイスは受信機からのイン界面を待ち、新規ジ
ョブの開始のターゲットとしてこれを用いる。プリン
タ、ＰＣ、ＴＶ等の受信デバイスは接続されたデバイス
にイン界面を送付し、リモート・デバイスの新規ジョブ
開始を待つ。あるデバイスはプッシュ・デバイスとして
動作する。例えば、転送を開始する送信側の送信あるい
は受信端としてである。他のデバイスはプル・デバイス
として動作する。あるデバイスは両者として動作する。
【０３３７】セルフ・ポリシー セルフ・ポリシーはデバイス自身の一般的情報の交換に
用いられる。デバイスのセルフ界面の全体構成を図２８
に示す。
【０３３８】図２８には５つの界面が示されている。ト
ップ・レベル界面（セルフ界面１８１、及びチャイルド
界面１８２，１８３，１８４，１８５である。セルフ界
面はサブ界面を参照してのｖＰｌｑｎｅエンコーディン
グである。各サブ界面は以下に説明するように情報の特
定の部分を有している。デバイスは適当にサポート可能
なサブ界面を含むことができ、少なくともラベル界面を
サポートすることが望ましい。ピン（ｐｉｎ）サブ界面
１８５はここではセルフ界面のチャイルドであるが、こ
のような構成である必要はない。以下にさらに詳細を述
べる。
【０３３９】セルフ界面は、いわゆるデバイスの“ビジ
ネス・カード”として動作するものである。２つのデバ
イスが出会うと、所定のトップ・レベル情報を含むセル
フ界面を交換する。これは人がビジネス・カードを交換
するのと同様である。デバイスは自己のセルフ界面を他
のデバイス（表示、記憶装置、プリンタ等）のイン界面
に送付することもできる。デバイスにとってトップレベ
ル界面の交換をし、必要なチャイルド界面の要求が可能
であることは有利な実行形態である。
【０３４０】多くのデバイスにおいて、セルフ・ポリシ
ーをサポートすることが適切である。セルフ界面コンポ
ーネントを記憶またはこれと通信するリソースが限定さ
れるデバイスはこれを実行しないかもしれない。しか
し、リソースがあれば、すべてのデバイスはアドレス、
ラベル、アイコンの各コンポーネントを実装すべきであ
る。デバイスのユーザ・インタフェースによって、ある
デバイスはリモート・デバイスからの０、いくつか、あ
るいはすべてのコンポーネントを要求する。例えばテキ
スト・ディスプレイを持つデバイスはリモート・デバイ
スからラベルを要求し、アイコンは要求しない。高価な
リソースを有する受信デバイスはリモート・デバイスの
ピン・コンポーネントを要求するサポートを実行するこ
とができる。ＰＩＮ番号入力の可能なユーザ・インタフ
ェースを有する送信デバイスはそのセルフ界面上でピン
界面を実行する。さらに重要な特徴は、デバイスが理解
できないセルフ界面のサブ界面は無視することができる
ということである。これは、将来的に新たなフィールド
を追加してセルフ・ポリシーを開発する可能性を許容す
る。
【０３４１】コンポーネント界面についてさらに以下に
おいて説明する。
【０３４２】セルフ界面１８１ これは図２９（ａ）に模式的に示されている。これはデ
バイスについての包括的情報を含むサブ界面への参照を
含む。界面のネームは“ｓｅｌｆ”であり、クラスはＳ
ＥＬＦである。セルフ界面の所有者は受信側と新たなセ
ッションがスタートするときにこれをインプレスしなけ
ればならない。また、チャイルド界面の提供が可能とな
るように受信側からの界面開放メッセージ及び界面要求
メッセージの受領準備をする。受信側がネーム：ＮＵＬ
Ｌ、クラス：ＳＥＬＦのセルフ界面要求をすると、送信
側はセルフ界面（これがＮＵＬＬネームでなくても）に
よる応答をする。これが、セルフ・ポリシーの適用され
た通信プロセスの初期に実行される望ましい形態であ
る。
【０３４３】界面はｖＰＬＡＮＥエンコーディングでな
ければならない。セルフ・コンポーネントは平面の前面
のチャイルドであり、任意アクセスが可能でなければな
らない（これはｅ−マテリアルの項で詳細に述べる）。
これはネームを有する多くの界面（ここではラベル、ア
イコン、ピン、アドレスであるが、例えば個別所有の情
報を交換する他のものを含めることが可能である）を含
み、サブ界面は個別に要求される。デバイスはチャイル
ドとしてサブ界面にリストされたものである場合は、要
求の受け入れが期待される。
【０３４４】セルフ界面の適切なｅ−マテリアルエンコ
ーディングは以下のように説明される。このエンコーデ
ィングの意味はｅ−マテリアルについての議論、ｖＰｌ
ａｎｅエンコーディングにおいて示されている。この情
報（界面メッセージ）の受信側はいずれのセルフ界面コ
ンポーネントが要求されているかを判断可能である。
【０３４５】
【表２５】
【０３４６】ラベル界面１８３ ラベル界面は図２９（ｂ）のように表現できる。ネー
ム：ラベル（ｌａｂｅｌ）、クラス：ＳＥＬＦ、エンコ
ーディング：ｖＴｅｘｔである。ラベルはデバイスが望
む要求されたサブ界面であるので、この界面を供給する
デバイスは界面要求メッセージ及び界面開放メッセージ
に応答しなければならない。テキスト・ストリングがイ
ンラインである場合は、記述要求メッセージ、記述応答
メッセージ、内容要求メッセージ、内容応答メッセージ
に応答する必要はない。これは後のｅ−マテリアルの記
述において説明する。界面変更メッセージはラベル変更
(完全に更新された界面記述を含まなければならない)を
リモート・デバイスに通知するのに使用される。ラベル
の表現及びユーザの構築可能性はデバイスに依存する。
以下に、ｅ−マテリアルのエンコーディングについて示
す。
【０３４７】
【表２６】
【０３４８】アイコン界面１８４ 図２９（ｃ）に示すアイコン界面は、デバイスの模式的
表現である。ネーム：アイコン、クラス：ＳＥＬＦ、エ
ンコーディング：ｖイメージである。これはサブ界面で
あるので、メッセージにおけるラベル界面と同様の考え
方が適用できる。ここでの実行形態ではｅ−マテリアル
・エンコーディングは３２ｘ３２ビット、インライン・
非圧縮カラー・イメージである。他の形態においても可
能である。
【０３４９】ピン（ＰＩＮ）界面１８５ デバイスがパスワード機能を有する場合、デバイスはピ
ン界面を有する。ピン界面はＰＩＮ番号（パーソナル識
別番号またはパスワード）を有する。ロックされたデバ
イスは、アクセスしようとするリモート・デバイスのピ
ン界面を要求する。ロックされたデバイスはそのリソー
スに対するアクセスを許可する前にリモート・ピン界面
の内容を有効化する。図２９（ｄ）は、ピン界面の表現
を示すものである。ネームはピン、クラスはＳＥＬＦ、
エンコーディングはｖＴｅｘｔである。
【０３５０】ピンが送付され、要求デバイスがそれを無
効化した場合は、要求デバイスはピンが無効となったこ
とを示すために他の界面要求メッセージに続いて界面開
放メッセージを送付する必要がある。ピン界面の所有者
は、繰り返し同じピン送らないように注意が必要であ
る。新しい１つのピンの提供が完了しない間は、第2の
ピン要求は拒否すべきである。ピンが界面メッセージに
おけるインライン形式であれば、記述要求、応答メッセ
ージ、内容要求、応答メッセージがサポートされること
は必要ではない。
【０３５１】ピン界面はＡＳＣＩＩ記号セットのテキス
ト・エンコーディングを含む。特定の実行形態では、テ
キスト・データは数値（０から９までの文字）によって
構成される。これは、シンプル・デバイスではユーザが
アルファベット数字文字の力を許容しないからである。
ＰＩＮ番号を有効化したデバイスは数値の有効限界を設
定する。すべてのデバイスが最長の利用可能なＰＩＮを
入力できるように、特定の実行形態では、ストリングは
最大１０桁に制限される。
【０３５２】ＰＩＮ有効化に関する基本事項を以下の表
２７に示す。
【０３５３】
【表２７】
【０３５４】ＰＩＮが有効または無効である場合の対応
は受信側の選択による。有効である場合、イン界面やス
テータス界面のようなリソースの送信側に対するオープ
ンを開始できる。所定のタイムアウトまでに正しいＰＩ
Ｎを提供しない送信側とのセッションは閉じられる。送
信側が無効なＰＩＮを提供したときに２回、3回と送信
側にパスワードを要求するのは受信側の自由である。Ｐ
ＩＮ要求の他の機会もある。例えば、デバイスはすべて
のジョブ、あるいは特定のジョブの開始の際にＰＩＮの
要求ができる。ここで説明されるＰＩＮの機構は、リモ
ート・ジェットセンド・デバイスを有効化する唯一の手
段ではない。受信（または送信）側デバイスはそのアド
レスによってリモート・デバイスを有効化できる。例え
ば、ジェットセンド・インターネット・デバイスは、特
定のＩＰアドレスを有するデバイスのみが接続できるよ
うなＩＰフィルタリングが実行できる。
【０３５５】アドレス界面１８２ この界面は図２９（ｅ）に示され、デバイスのアドレス
を含む。これは、後述するようにアドレス・ポリシーを
使用して第３パーティにパスするのに有効である。メッ
セージにおける適用についてはラベル界面やアイコン界
面と同様の考え方である。この界面はアドレス・ポリシ
ーにおいて最も有用である（接続され、アドレス界面の
要求可能なデバイスは接続に使用したトランスポート層
からこの情報を知ることができるからである）。
【０３５６】ステータス・ポリシー クラスがＳＴＡＴＵＳの界面は状態情報の交換に使用さ
れる。２つのタイプのステータス、デバイス・ステータ
ス、ジョブ・ステータスがある。いずれのデバイスに対
してもデバイス・ステータスは１つのみであるが、ジョ
ブ・ステータスは複数あってもよい。各ジョブ・ステー
タスはジョブ・ポリシーを使用して開始されたジョブに
関連する。
【０３５７】ステータス提供者は、ここではステータス
界面を有するデバイスとして定義される。ステータス・
オブザーバは他のデバイスのステータス界面コンポーネ
ントの1つ以上のインプレッションを有するデバイスで
ある。デバイスはステータス提供者、ステータス・オブ
ザーバのいずれにもなり得る。
【０３５８】図３０はステータス界面の全体構成図であ
る。トップ・レーベル界面２０１はテキスト・フォーム
の実際の状況情報を含むステータスサブ界面を参照する
平面である。デバイスあるいはジョブ・ステータスに
は、“ｔ”及び“ｎ”（例えばｄｅｖｔ、ｄｅｖｎ）界
面がある。“ｔ”はテキスト・ステータスを、“ｎ”は
数値ステータスを意味し、いずれもテキスト・エンコー
ディングである。テキスト・ステータスは以下に説明す
るようにローカライズ可能な、人の読み取り可能なスト
リングである。数値ステータスは数字であり、成功、進
行、失敗の各状態を示す。
【０３５９】テキスト・ステータスはステータス提供者
によって定義され、デバイスの機能に特有のものであ
る。数値ステータスの値はデバイス非依存のデバイス共
有の固定セットである。数値デバイス、ジョブ・ステー
タス界面は以下のように定義される。
【０３６０】ステータス界面を受領したデバイスは、ユ
ーザに対してテキスト・ステータス・ストリングを表示
する。数値ステータスについては解釈を行いユーザに対
して通知するか、自動的に適切なアクションを実行す
る。例えば、ジョブの処理に失敗した場合、デバイス
は、ジョブを再送するか、ブザーをならすか、赤のライ
トを点滅させるか、あるいはさらに詳細なエラーメッセ
ージをユーザに送って通知する。
【０３６１】テキスト・ステータス・メッセージはユー
ザの言語に特定できる。これは、出願日１９９７年７月
１８日、米国特許出願番号０８／８９６，２３６に記載
されているローカリゼーション機構によって達成でき
る。この内容を参照されたい。ローカリゼーションはオ
プションであり、通信の２つのデバイスが所定の言語及
び記号セットをサポートする場合に有効である。ＡＳＣ
ＩＩ記号セットの英語のサポートが必要となる。
【０３６２】デバイス・ステータスを多くのデバイスが
実行することが理想的であるが、必ずしも必要ではな
い。ステータスをサポートするすべてのデバイスは数値
デバイス・ステータスを実行し、その多くがテキスト・
デバイス・ステータスも実行する。受信デバイスのみが
ジョブ・ステータスを実行し、送信デバイスが受信デバ
イスからのジョブ・ステータスを観察する。
【０３６３】個々のステータス界面コンポーネントにつ
いて以下に説明する。
【０３６４】ステータス界面 この界面を図３１（ａ）に示す。これはデバイス・ステ
ータスまたはジョブ・ステータスの全体を示すステータ
ス・メッセージへの言及を含む。ネームがステータス
（ｓｔａｔｕｓ）、クラスがＳＴＡＴ（４）、エンコー
ディングがｖＰｌａｎｅである。
【０３６５】ステータス・プロバイダ（ジョブ・ステー
タスまたはデバイス・ステータスの提供者）は、他の接
続デバイスに界面メッセージを送付することによってた
のデバイス上にトップレベル・ステータス界面をインプ
レスする。リモート・デバイス（ステータス・オブザー
バ）が対象のステータス界面のコンポーネント要求をす
る。ステータス提供者がステータス界面中にチャイルド
としてリストされたサブ界面（例えばｄｅｖｔ）を持つ
ときには、その界面のデータ要求が認められることが期
待される。ステータス提供者は新しいコンポーネントが
追加されたり削除された場合は、トップレベル・ステー
タス界面の界面変更メッセージを送付する。例えば、新
規ジョブがスタートし、ジョブ・ステータスが生成され
ると、ステータス界面はコンポーネントのリスト中の新
しいコンポーネントによって更新される。ステータス変
更メッセージは界面開放メッセージによって界面を開放
していないステータス・オブザーバにのみ送付される。
【０３６６】界面エンコーディングは、平面エンコーデ
ィングであり、セルフ界面と同様の考え方が適用でき
る。しかし、ステータス・プロバイダはレンダリングに
適するコンポーネント配置を有し、読みやすさを改善す
る非ステータス・エレメント（ヘッディング、ロゴ等）
を付加することが好ましい。エンコーディングのサンプ
ルを以下に示す。
【０３６７】
【表２８】
【０３６８】Ｄｅｖｔ界面２０２ この界面を図３１（ｂ）に示す。テキスト・ストリング
のローカリゼーションがサポートされる場合、内容要求
及び応答がサポートされなければならない。さもなけれ
ば、情報がインラインで提供される。テキスト・ストリ
ングは新しいラインまたは他の制御文字を含んではなら
ない。
【０３６９】多くのデバイスは、デバイスのステータス
が変更するとステータス・フィールドを更新することを
必要とする。これは、先にその界面の界面メッセージを
受領したデバイスに界面変更メッセージを送付すること
によって達成される。デバイスが界面の更新受領に興味
が無い場合は、界面開放メッセージを送付する。
【０３７０】Ｄｅｖｎ界面２０３ この界面は図３１（ｃ）に示す通りである。ｄｅｖｔ界
面と同様のメッセージングにおける条件が適用される。
界面はテキストにエンコードされ、ＡＳＣＩＩ記号セッ
トにおいて提供される。これは以下の値のいずれかを与
えられる。
【０３７１】１：デバイスはｏｋ状態である（ジョブの
送信／受信が可能） ２：デバイスがビジー（現在ジョブ処理中） ３：デバイスの注意必要（過渡的に非動作状態、また
は、消費資源の再ロードが必要） ４：デバイスの機能が有効でない（内的エラー、機能実
行不可）
【０３７２】Ｊｏｂｔ界面２０５，２０７ この界面は図３１（ｄ）に示される。この界面の条件は
ｄｅｖｎ界面と基本的に同様である。最も大きな違いは
ネームである。ネーム中の＃はジョブを開始した界面メ
ッセージからのインプレスＩＤによって置き換えられ
る。これはジョブを受領したデバイスのイン界面上に最
初にインプレスされたトップレベル界面のインプレスＩ
Ｄである。送信デバイスは、ジョブ・ステータスを適当
なジョブとリンクするためにこの数値を使用する。受信
デバイスは異なるデバイスと同時にいくつかのジョブを
実行することがある。インプレスＩＤはジョブ及びジョ
ブ・ステータスを区別するのに用いられる。
【０３７３】Ｊｏｂｎ・ステータス２０４，２０６ この界面は図３１ｅに示す通りである。条件はｊｏｂｔ
界面と同様であるが、界面はテキストとしてエンコード
され、ＡＳＣＩＩ記号セットとして提供される。界面は
以下の値のいずれかを含む。
【０３７４】１：ジョブが実行され、処理が成功した ２：ジョブが実行されたが処理が失敗した。 ３：ジョブがホールドされ、後ステージで実行予定 ４：ジョブ処理中 ５：ジョブ処理中であり、0％処理済み ６：ジョブ処理中であり、１％処理済み ： ： １０５：ジョブ処理中であり、１００％処理済み
【０３７５】値４は、ジョブの進行状況の情報を持たな
い以外は値５から値１０５と同等である。これらのステ
ータスの値を受領したデバイスは、これを認識可能な状
態で表示可能である。
【０３７６】アドレス・ポリシー アドレス・ポリシーは、デバイスが第三者デバイスのア
ドレスを交換することを可能とする。ポリシーは２つの
タイプの界面、すなわちアドレス・プログラミング界面
（あるいはアドレス・イン界面）及びアドレス・カード
界面を採用する。リモート・デバイスからのアドレスを
受け入れるデバイスは、アドレス・イン界面を有する。
ここで、他のデバイスにアドレスを送付するデバイス
は、リモート・アドレス・イン界面上にインプレスする
アドレス・カード界面を有する。
【０３７７】一般的に、セッションを開始したデバイス
のみがリモート・デバイスからのアドレスによってプロ
グラムされることに関心を持つ。アドレス入力の十分な
ユーザ・インタフェース能力を持たないセッションの開
始者は、意味のあるオプションを持たないが、アドレス
・ポリシーを実行するために高度なデバイスにアドレス
を付加することを許容する。これらはアドレス・イン界
面を実行する。
【０３７８】基本的にアドレス・カードを受領するデバ
イスは、それらを好きなように扱う。典型的には入力さ
れるカードをアドレスブックに追加する。簡易なデバイ
スは、他から受領したアドレスをパスする。他のデバイ
スのアドレスによるプログラムを望むデバイスはアドレ
スカード界面を実行する。
【０３７９】アドレス・イン界面２２６を、図３２に示
す。リモート・デバイスからのアドレスを受け入れたデ
バイスは、接続された他のデバイスにアドレス・イン界
面をインプレスする。アドレスを送付したいデバイス
は、インプレスのターゲットをリモート・デバイスのア
ドレス・イン界面の界面識別子にセットする。アドレス
・イン界面は、インプレスされる界面の処理が異なる点
以外はジョブ・ポリシー中で使用されるイン界面に極め
て似ている。この界面の界面プロパティは１にセットさ
れ、新しいインプレッションのターゲットとして使用さ
れる。
【０３８０】アドレス・カード界面を図３３に示す。界
面２２１は基本的にセルフ界面のフォーマットと同じで
ある。また各サブ界面２２２，２２３，２２４，２２５
のフォーマット及び必要条件もセルフポリシーにおける
のと同様のものである。唯一の違いはアドレス・カード
界面及びサブ界面のクラス・フィールドはＳＥＬＦにセ
ットする必要がなく、他のいかなるクラス（ＳＥＬＦ、
ＯＴＨＥＲも可能）にもセット可能であることである。
アドレス・カード界面はアドレス・イン界面にインプレ
スされる。アドレス・カード界面はチャイルド界面とし
て少なくとも“ａｄｄｒ”界面を有し、他はオプション
となる。
【０３８１】さらに、特定の対話ポリシーに属するもの
ではないいくつかの手法がある。これらについて以下に
説明する。
【０３８２】予期しない界面メッセージ デバイスは予期しない界面メッセージを受領する。例え
ば、デバイスがセルフ界面をサポートしない場合におい
て、他のデバイスがセッション確立の後、トップレベル
界面に伴い界面メッセージを送付することがある。さら
に、デバイスは提供できない界面に関する要求を受ける
ことがある。
【０３８３】予期しない界面メッセージに対する応答は
単純である。すなわち拒否される。拒否のメッセージは
元のメッセージに依存する。 ＊界面要求メッセージ：ステータスが３(要求拒否)にセ
ットされた界面メッセージによって拒否される。 ＊界面メッセージ：界面開放メッセージによって開放さ
れる。 ＊内容要求メッセージ：ステータスが２(要求拒否)、デ
ータ・フィールドがＮＵＬＬにセットされた内容応答メ
ッセージによって拒否される。 ＊界面変更メッセージ：ステータス値１（変更要求）の
メッセージは、ステータスが２(変更拒否)にセットされ
た界面変更メッセージで拒否する。 ＊記述要求メッセージ：データ・フィールドかＮＵＬＬ
にセットされた記述応答メッセージで拒否する。
【０３８４】これらのメッセージが予期しない要求に対
する応答としてではなく送られる場合、送信側は予期さ
れる応答のタイムアウトまで待機する。受信側が上記の
拒否機構において応答がもはや無いことを明示するよう
にすればさらに効果的である。
【０３８５】空の界面ネームを持つ界面要求 これは各ポリシーにおいて部分的に説明される。界面要
求がなされると、要求者はネーム及びクラスを特定す
る。ネームがＮＵＬＬ(長さフィールド＝０)であるとき
は、ネーム無しの界面要求であることを示す。また、デ
バイスが特定のクラスのデフォルト界面を提供すること
を意味する。例えば、クラスＳＥＬＦ、ネーム無しの界
面要求を行った要求者は、トップレベル・デフォルト界
面を含む応答を得る。
【０３８６】デバイス固有ポリシーの創作（Inventing
Device-specific Policies） デバイスは、クラスがＮＯＣＬＡＳＳ（１）の界面を用
いて自己のポリシーを生成することができる。デバイス
は界面ネームを調べて特別の界面を区別することができ
る。この特別のポリシーを知らないデバイスは、界面メ
ッセージ、及びこれらの特別のネームを持つ界面要求を
拒否する。
【０３８７】ｅ−マテリアルの性質及びフォーマットに
ついて、異なるドキュメント・タイプにおける使用例を
用いて説明する。
【０３８８】先に説明したように、ｅ−マテリアルは、
界面の表現に用いられるフォームである。Ｅ−マテリア
ルは記述及び内容を含む。記述はジェットセンドによる
内容の交換交渉に用いられる。記述は界面の属性を示
す。これら属性は、複数の属性レベルを包含する選択階
層を形成する。これら属性は、情報の搭載手法を示す。
内容自体は転送される認識可能な情報である。
【０３８９】機器間の界面の良好な交換には、界面を記
述する各属性レベルが識別及び処理されることが必要と
なる。機器間のこれらのレベルの識別及び処理は交渉と
呼ばれる。完全に界面記述が交渉されると、界面内容が
交換される。
【０３９０】ジェットセンド機器間の界面交換は、ＪＩ
Ｐによって定義されるような界面対話メッセージを含
む。界面記述は記述要求及び記述応答を用いて完成され
る。界面内容の交換は、内容要求及び内容応答を用いて
完成される。一定の環境では、界面内容は界面記述に含
まれる。これをインライン内容と呼ぶ。インライン内容
及び少量の記述があれば、交換は単一メッセージのみを
必要とするだけである。一般には複数のメッセージが交
換される。
【０３９１】Ｅ−マテリアルはｅ−マテリアル・ブロッ
クのフォームで提供される。このブロックのバイト・フ
ォーマットについては、さらに以下で詳述する。１レベ
ルのｅ−マテリアル・ブロックは第１列に属性ネーム、
第２列に属性値を持つ２列のテーブルによって表現され
る。属性ネームはｖＲｅｓｏｌｕｔｉｏｎ、またはｖＣ
ｏｍｐｒｅｓｓｉｏｎのような特定の単一キーワードで
ある。属性値は例えば、（３００，３００）ピクセル／
インチ、またはＲＬＥ（ランレングス・エンコーディン
グ）のような属性関連の１つまたは複数の値である。属
性値が値のリストとして特定されると、値フィールドに
おける離間（スペース・セパレート）リストとして示さ
れる。
【０３９２】ｅ−マテリアル・ブロック中に現れる属性
ー値（バリュー）の対（ペア）は、ジェットセンド界面
のある位置に対して適用される。これらの属性ー値（バ
リュー）の対はすべての界面または界面の特定の位置に
適用される。すべての属性およびいくつかの値は予め定
義されたキーワードの限定セットから導かれる。本明細
書中で、これは例えばｖエンコーディングの接頭辞
“ｖ”によって示される。ある値はデータ・タイプのセ
ットから導かれる。本明細書中で、これは例えばｅｍリ
スト・タイプの接頭辞“ｅｍ”によって示される。本明
細書中では、ジェットセンド界面の文法に似た構成の議
論を単純化するために定義される象徴的要素がいくつか
使用されている。これらは一般に値フィールドにおいて
特定の識別子によって示される。
【０３９３】ある属性は、選択を提供する値のセットと
関連する。値の各セットは、選択リスト（セレクション
・リスト）と呼ばれる。選択リストは、2列テーブルの
値の列中の離間（スペース・セパレート）リストとして
示される。例えばｖ解像度属性は、（３００，３００）
ピクセル／インチ、または（１５０，１５０）ピクセル
／インチのような値を含む選択リストを有する。各値の
選択は、界面記述の各属性レベルの識別及び処理に寄与
する。表２９に示すｅ−マテリアル・ブロックにおい
て、ｖエンコーディング、ｖカラー・スペース、ｖピク
セル深度、ｖ解像度、ｖ圧縮は値として選択リストを用
いる。属性：ｖサイズは、そうではない。この実施形態
を簡易化するために、たとえ１つの値しか持たない場合
でもリスト化される属性データはリストとしてエンコー
ドされるというルールを用いる。
【０３９４】これは、属性“ｖエンコーディング＝ｖテ
キスト”が１つのエレメントｖテキストのリストとして
エンコードされることを意味する。これは属性データの
解釈を容易にするが、その組み立てをやや困難にする。
【０３９５】
【表２９】
【０３９６】レベルが識別され処理されるに従い、選択
リストを得た属性及び選択値はｅ−マテリアル・ブロッ
クに列挙される。選択リストを持たない属性は省かれ
る。このｅ−マテリアル・ブロックは決定ブロックと呼
ばれる。これはｅ−マテリアルの特定属性について決定
するものだからである。記述要求及び内容要求は要求さ
れるｅ−マテリアルの属性を示すｅ−マテリアル・ブロ
ックを含む。以下の表３０は上記の表から選択される決
定ブロックの例である。
【０３９７】
【表３０】
【０３９８】属性ブロックは、界面記述の特定の属性レ
ベルに関連するすべての属性−値（バリュー）の対を示
すｅ−マテリアル・ブロックである。界面記述ブロック
は、属性ブロックの整列セットである。界面記述ブロッ
クは最後の２列を持つ属性ブロックを持つ３列のテーブ
ルとしても示される。テーブルの最初の列は各属性ブロ
ックに適用可能な決定パスを含む。決定パスは決定ブロ
ックからの値を用いて形成される。これらは属性ブロッ
クと同様、ドット表記において結合される。従って、イ
メージに適用可能な属性ブロックは、例えば３００ｘ３
００ｄｐｉの解像度で、８ビット／ピクセルの階調（グ
レイスケール）のランレングス・エンコーディング・イ
メージであることを示すｖＩｍａｇｅ．ｖＧｒａｙ．
８．（３００，００）．ｖＲＬＥ、のような決定パスに
よって採用を決定することができる。この表記はエンコ
ーディング階層と呼ばれる界面の構成を記述する。この
階層の根（ルート）はヌル（ｎｕｌｌ）レベルと呼ばれ
る。
【０３９９】
【表３１】
【０４００】たとえば、表３１に示される例では、エン
コーディング階層のヌル・レベルは属性、ｖエンコーデ
ィングとｖイメージの値を示す属性値である。エンコー
ディング階層は、木のような構成を形成する。この構成
の各ノードは属性レベルである。次の属性レベルにおい
て、属性ブロックはそのレベルに適用される属性−値
（バリュー）の対が、ｖカラースペースがｖグレイであ
り、ｖサイズが値（５７６０００，７５６０００）であ
ることを示しているこのレベルは最終のものではない。
ｖグレイがｖピクセル深度という属性を有し、これが選
択リストを用いるからである。決定パスはエンコーディ
ング階層フィールド中に示されるレベルまで木を下がる
決定セットを与える。決定パスの各値はエンコーディン
グ階層ツリー（木）の下層レベルへの降下を示す。決定
パスの最後の値は属性レベルのネームである。界面記述
は、エンコーディング階層のレベルが最終となったとき
に、完全であることが判明する。この階層構造のフォー
ムを図４７に示す。Ｘ．Ａ、Ｘ．Ｂ．Ｍ、及びＹのよう
なレベルは、最終であるように判断される。これらを超
えるさらなる記述はない。
【０４０１】ドキュメントは１つまたは複数の界面によ
って構成される。各界面は“ｍｙＳｕｒｆａｃｅ”、
“ｄｏｃ／ｐｌａｎｅ３／ｉｍａｇｅ２”のようなネー
ムが付与される。ドキュメントは最後の3列が界面記述
テーブルによって占有される4列のテーブルとして表現
される。最初の列は界面のネームを含む。このテーブル
の例を以下の表３２に示す。
【０４０２】
【表３２】
【０４０３】ドキュメント中の界面は木構造として構成
される。ドキュメントは、ページによって構成され、ペ
ージはテキストまたはイメージ等によって構成される。
ある界面の属性は、下にあるチャイルド界面の構成を記
述する。これらの属性は界面階層の上昇を示す。この階
層のルート(根)はトップレベル界面と呼ばれる。
【０４０４】界面階層のある界面は、１つまたは複数の
チャイルド界面を持つ。これらチャイルド界面は、各ペ
アレント界面を区別可能な整理されたチャイルド・リス
ト中に構成されている。チャイルド・リストは、１つの
ページのイメージ及びテキストブロックのリストのよう
に特徴付けられている。しかし、これらが常に利用でき
るとは限らない。複数ページのスキャナによってひとか
たまりページが走査されている場合を考える。各ページ
について、それぞれの番号、指示、内容が存在するが、
ひとかたまりの構成を反映するチャイルド・リストはい
つでも利用できるものとはならない。このような界面は
要求によって生成されるか、あるいは特定のデバイス処
理に必要な所定時に生成されることもある。チャイルド
・リストが特徴づけられると、ペアレント界面に関連す
るチャイルド界面のネームを付与する。界面記述テーブ
ルにおいてこれは参照リストと呼ばれる。
【０４０５】ｅ−マテリアル界面記述のフォーマル構成
を以下に示す。Ｅ−マテリアルはテーブル中で特定さ
れ、属性及び値から記述の構成を決定する文法的形態に
従って扱われるセルによって構成される要素を伴ってい
る。予め定められたキーワードのような低レベル・デー
タ・タイプ、あるいはｎｕｌｌターミネート・ＡＳＣＩ
Ｉストリングは文法的なターミナル・シンボルである。
ここではそれらはｅ−マテリアル・バイト・フォーマッ
トにおけるデータ・タイプに関連する（以下に詳細を説
明する）。
【０４０６】Ｅ−マテリアル表記についてまとめた表
を、以下の表３３に示す。
【０４０７】
【表３３】
【０４０８】Ｅ−マテリアル・データ・タイプ（以下で
説明するｅ−マテリアル・バイト・フォーマット・デー
タ・タイプに対応する）を表３４に示す。
【０４０９】
【表３４】
【０４１０】タイプの属性ブロックを表３５に示す。
【０４１１】
【表３５】
【０４１２】ｅ−マテリアル・リストとして各種の値が
表現される。汎用リスト（Generallist）は、リスト中
の要素の数値が有効となる最も簡単に扱える値である。
選択リスト（Selection list）は、交渉プロセスにおい
て選択された固有の値を含む。参照リスト（Reference
list）は、ページまたはドキュメントを形成するために
リンクされた界面ネームを含む。
【０４１３】Ｅ−マテリアル汎用リストの構成タイプを
以下の表３６に示す。
【０４１４】
【表３６】
【０４１５】選択リストは、ｅｍリストタイプによって
定義されるような多くのトークン・コンビネーションに
なり得る。リーガル・コンビネーションは選択リストが
対になる特定の属性によって制限される。選択リスト中
のこの値は属性に一致しなければならず、リスト中の値
の数には制限はない。一般的なタイプを表３７に示す。
【０４１６】
【表３７】
【０４１７】言語及び国への参照が望まれる場合は、ｖ
言語（ｖＬａｎｇｕａｇｅ）属性がエンコーディング階
層中に含まれていてもよい。これはｖテキストも同様で
あり、他のエンコーディングとってはオプションとな
る。ｖ言語属性は特別な選択リストを要求する。これ
は、言語を識別し、使用可能な文字を持つ国をオプショ
ンとして識別する。このフォーマットとしては言語−コ
ード［国コード］等である。国コードが言語コードに続
く識別値として設定される場合であっても識別される言
語コードは固有の値を有することが要請される。国コー
ドがさらに値として明示するものを付加する場合は、国
コードに固有の言語コードを付加するようにしてもよ
い。
【０４１８】エンコーディング選択リストは、一般にｖ
イメージやｖテキストのようなｅｍキータイプの値を1
つ以上提供する。ｖエンコーディングに関する選択リス
トにおいてｅｍストリングタイプを定義することによっ
て特定のエンコーディングを付加し、統一的に使用する
ように構成してもよい。ｅｍキータイプのような定義キ
ーワードは独立に解釈される。従って、ｅｍキータイプ
ｖアソシエーションは、特別のエンコーディングｅｍス
トリングタイプｖアソシエーションとは同じではない。
【０４１９】選択リストにおける組み合わせ順は送信機
器の好みを示す。
【０４２０】決定パスは決定ブロックの値から形成され
る。一方、これらの値は選択リストから得られる。エン
コーディング階層は、これらの決定パスによって表現さ
れる。決定パスは各属性ブロックのレベルを識別するの
に用いられる。決定パス構成を以下の表３８に示す。
【０４２１】
【表３８】
【０４２２】ヌル（ｎｕｌｌ）レベルはジェットセンド
界面のエンコーディング階層におけるエントリ・ポイン
トを提供する。ヌル・レベルにおいて決定パスはヌル
(空白)である。ヌル・レベルは状況に応じて３つの態様
をとる。 ＊ヌル・レベルはｖエンコーディング属性のみを含む。
これはヌル・レベルの最も一般的な形態である。多くの
界面はこのヌル・レベルによって開始される。 ＊ヌル・レベルはｖ言語属性のみを含む。ｖ言語属性は
ｖテキスト界面に必要である。他の界面エンコーディン
グにおいても時々みられる。 ＊界面記述が不完全であるとき、記述要求及び記述応答
が界面記述の交換を完了するために実行されなければな
らない。記述要求及び記述応答は界面記述の完成のため
に各属性レベルで実行される。すでに選択された値を持
つ選択リストを持つ属性は、記述要求の決定ブロック中
に検出される。アドレスされていない選択リストを持つ
属性は、記述応答中の決定パスに現れる。選択リストを
持つ属性の整列リスト中において区切り（ｂｒｅａｋ）
が動的に確立されるので、記述応答ではどのレベルもヌ
ル・レベルとなり得る。
【０４２３】界面階層構造は参照リストの使用によって
生成される。参照リストは、ペアレント界面にリンクす
るチャイルド・リスト中のチャイルド界面の構成を示
す。チャイルド・リストが使用できるとき、このリスト
中のチャイルド界面は参照リスト中のチャイルド・カウ
ント数、チャイルド界面ネームに直接対応する。チャイ
ルド・リストが使えないとき、参照リストは不完全な表
現を示す。
【０４２４】参照リストは単純なマテリアル・リスト、
ｅｍリストタイプである。多くの場合、リストはチャイ
ルド・カウント、ｖシーケンシャルまたはｖアービトラ
リーのキーワード、及びチャイルド界面ネームのリスト
の構成を持つ。参照リストは単一ページ（ｖ平面・エン
コーディングの場合）あるいはドキュメントの他のペー
ジ（ｖアソシエーション・エンコーディングの場合）の
要素とリンクしていることがある。各界面は各々交渉さ
れたジョブ・エレメントである。
【０４２５】参照リストはｖ平面、またはｖアソシエー
ション界面エンコーディングとのみ関連する。他のエン
コーディング（ｖイメージ、ｖテキスト、ｖファイル）
は界面階層の最終レベルである。ｖ平面エンコーディン
グは２つ（ｖチャイルド・フロント、及びｖチャイルド
・バック）、１つ（ｖチャイルド・フロント、またはｖ
チャイルド・バック）または０のチャイルド界面リスト
を持つ。ｖアソシエーション・エンコーディングは1つ
(ｖチャイルド)のチャイルド界面リストを持つ。Ｅ−マ
テリアル参照リストの構成を以下の表３９に示す。
【０４２６】
【表３９】
【０４２７】チャイルド・カウントの値は負、ゼロ、正
であることがある。チャイルド・カウントの小さな正数
は対応する参照リストを含み、チャイルド・リストの完
全な内容を明示する。チャイルド・カウントの大きな正
数は、チャイルド・リストは判明しているが、参照リス
トが大きすぎて含められないことを示す。他のチャイル
ド・カウントの値は、チャイルド・リストが判明しない
か、ゼロの長さであることを示す、いずれにおいても参
照は含まれない。
【０４２８】ｖシーケンシャル、ｖアービトラリーのキ
ーワードは、送信機器が送信する界面の順序に何らかの
制限があるかを示す。これは受信側が要求した界面の順
を制御することを許容する。これは受信機器が内容及び
チャイルド界面の両者がどのような順に要求されたかを
知らせる。チャイルドに関する内容情報はインラインで
あるかもしれない、また内容情報は１つまたは複数のチ
ャイルドに一度に要求されたかもしれない。しかし、チ
ャイルドの界面記述は一度に要求されなければならな
い。
【０４２９】ｖアービトラリーの値は送信機器が受信機
に対して要求のあった順にアクセス、内容情報の送信、
チャイルド界面のインプレスが可能であることを示す。
ｖシーケンシャルの値は、送信デバイスの限定によって
予め定められた順でチャイルドが要求をしたことを示
す。
【０４３０】参照リストのリマインダは、他の界面のネ
ームを与える。これらのネームは完全なチャイルド・リ
ストが判明し、比較的短い場合に存在する。参照が含ま
れる場合、以下の解釈が適用される。 ＊参照ネームは固有のものでなければならない。 ＊＃（パウンド・サイン）は予約を示す記号である。 ＊参照は、平面上で示されるチャイルドを意味する。 ＊チャイルドの順序は、それらが示される順序である
（以下のｖ平面の欄で説明するようにｚ方向におい
て）。 ＊参照がリストされると参照の番号はチャイルド・カウ
ントの値によって特定されるチャイルドの数に一致しな
ければならない。参照の一部のリストはゆるされない。
すべてがリストされない場合、または参照が判明してい
ない場合は、内容要求中の使用可能な機構を介して発見
されなければならない。
【０４３１】あるいくつかのチャイルドの内容情報をイ
ンラインとすることは可能である。これは参照リスト
（ｒｅｆｅｒｅｎｃｅＬｉｓｔ）値がｖチャイルド・フ
ロント、ｖチャイルド・バック、あるいはｖチャイルド
属性に含まれる場合に許容される。インラインでない内
容においては、内容要求が使用される。
【０４３２】すべての環境下でのジェットセンド機器の
対話を確実にするためには、特別の決定パスが存在する
ことが必要である。これらはデフォルト・エンコーディ
ング（default encoding）と呼ばれる。送信機器はこれ
らのデフォルト決定パスによって表現される属性を持つ
ｅ−マテリアルの生成が可能でなければならない。同様
に、受信機器はこれらの特徴を持つｅ−マテリアルを解
釈可能である必要がある。例えば、ｖＩｍａｇｅ．ｖＧ
ｒａｙ．１．（３００，３００）．ｖＲＬＥであり、こ
れらがｖイメージのデフォルト・エンコーディングであ
る。
【０４３３】通常の環境下で機器間のｅ−マテリアル交
換を可能とするようにデフォルト・エンコーディングが
存在する。これらのエンコーディングは最低限の共通の
性質である。ベース・エンコーディング（Ｂａｓｅ ｅ
ｎｃｏｄｉｎｇ）は機器間の正確なｅ−マテリアル交換
を達成するために推奨される決定パスである。他の属性
及び値はオプションであるとみなされる。ｖイメージの
ベース・エンコーディングはｖイメージ．ｖグレイ．
８．（152,150）．ｖRLE、ｖイメージ．ｖグレイ．８．
（150,150）．ｖＮｏｎｅ、及びｖイメージ．ｖＳＲＧ
Ｂ．２４．（150,150）．ｖＮｏｎｅである。
【０４３４】デフォルト・エンコーディングは、その各
要素が選択リストからのものによって構成される決定パ
スである。各選択リストへの関連は属性である。各値が
デフォルトエンコーディングを形成する属性は界面記述
中に存在することが必要である。
【０４３５】異なるタイプの界面におけるエンコーディ
ングについて、いくつかの例を示して以下で説明する。
【０４３６】ｖイメージ（ｖＩｍａｇｅ） 静止イメージは、描写時に画像として表現されるラスタ
情報、ビットマップとして一般的に解釈される。イメー
ジはページ上のドット表現として表示される。これらの
ドットは視覚的にはテキスト、テーブル、ピクチャ、文
字等として示される。またイメージはコンピュータ・ス
クリーン上のピクセルとして表現される。イメージはカ
メラ、スキャナ、他の同様な装置からのピクセルとなり
得る。一般に、イメージはカラースペース、ピクセル深
度、解像度、圧縮法によって分類される。エンコーディ
ング階層における決定パスは情報の操作に用いられる。
【０４３７】ｖイメージにおける属性階層について図３
４に示す。それぞれの異なる属性の意味について以下に
説明する。
【０４３８】ｖ言語（ｖＬａｎｇｕａｇｅ）：ｖ言語属
性は、言語及び国が参照情報として希望される場合に含
まれる。デフォルトの言語の値は特定されていない。
【０４３９】ｖエンコーディング（ｖＥｎｃｏｄｉｎ
ｇ）：このセクションはｖイメージ・エンコーディング
を定義する。他のエンコーディング、例えばｖテキス
ト、ｖファイル、ｖ平面、ｖアソシエーション、他の固
有なｅｍストリンク・タイプも存在する場合がある。ｖ
イメージはラスタ化された静止イメージを表現するビッ
ト集合として定義される。イメージ構成は、このエンコ
ーディングの属性によって定義される。
【０４４０】ｖサイズ（ｖＳｉｚｅ）：デイスプレイ界
面に対するイメージのサイズを指示する。第1の値は７
２０００ユニット／インチにおけるｘ軸方向の値、第２
の値はｙ軸方向の値である。受信デバイスはイメージを
表現するデイスプレイ領域、対応する情報サイズ、自己
の能力に関して知ることが必要である。属性はイメージ
・サイズ、表示に必要なリソースを知り、イメージデー
タの最適な受領方法を決定するのに必要な情報を受信デ
バイスに与える。
【０４４１】ｖオパシティ（ｖＯｐａｃｉｔｙ）：レン
ジ０−２５５中の符号無し整数によって指示される。０
は完全トランスペアレント、２５５は完全不透明を意味
する。ｖオパシティが省略される場合、デフォルト値は
２５５となる。
【０４４２】ｖカラースペース（ｖＣｏｌｏｒＳｐａｃ
ｅ）：界面記述に関連するイメージに使用可能なカラー
・スペースを提供するのに用いられる。デフォルトはｖ
グレィ（ｖＧｒａｙ：グレィスケール）、ベースが、ｖ
ＳＲＧＢ、オプションはｖＲＧＢ、ｖＣＩＥＬＡＢ、ｖ
ＣＭＹ、ｖＹＣＣ、ｖＹＵＶ、ｖＸＹＺであり、各場合
において、各エンコーディングのネームが特定のカラー
・スペースを表す。オプション・エンコーディングとし
てはさらに他のカラースペースも提供可能である。
【０４４３】ｖピクセル深度（ｖＰｉｘｅｌＤｅｐｔ
ｈ）：選択されたカラー・スペースにおけるピクセル深
度エンコーディングを提供するのに用いられる。ピクセ
ルの色値を決定するピクセルごとの複数ビットが使用さ
れる。適当なデフォルト及び基本エンコーディングがそ
れぞれのカラースペースにおいて決定される（例えば、
ｖＧｒａｙのデフォルトとして１、ベースとして８）。
【０４４４】ｖ解像度（ｖＲｅｓｏｌｕｔｉｏｎ）：関
連イメージ・ピクセルメデータのエンコーディングに使
用可能な１つまたは複数の実世界（ｒｅａｌ−ｗｏｒｌ
ｄ）解像度を提供する。
【０４４５】ｖピクセル（ｖＰｉｘｅｌ）：ｖ解像度
（Ｒｅｓｏｌｕｔｉｏｎ）の値によって指示される解像
度の基で特定されるイメージ幅、及びイメージ高を示
す。
【０４４６】ｖ圧縮（ｖＣｏｍｐｒｅｓｓｉｏｎ）：選
択された各種のカラースペースにおいて利用可能な圧縮
技法を示す。各場合において、ｖＮｏｎｅが圧縮無しを
示すオプションとなる。圧縮はオプションであるが、オ
プションとして標準圧縮技法を用いることは有利である
(例えばｖＲＬＥ、ｖＴＩＦＦ、ｖＪＰＥＧ)。圧縮技法
として各種の実行オプションが可能であり、ｅ−マテリ
アル・フォーマットを用いた実行構成も採用できる。所
望の圧縮技法における標準参照ソース（standaard refe
rence source）について当業者の知るところであろう
（例えばＩＳＯ１０９１８−１ＪＰＥＧドラフト国際規
格及びＪＰＥＧにおけるＣＣＩＴＴリコメンデーション
Ｔ．８１）。
【０４４７】ｖエンディアン（ｖＥｎｄｉａｎ）：これ
はオプションである。エンディアンについての参照が望
まれる場合は含まれる（デフォルトはビッグ・エンディ
アンである）。
【０４４８】界面表現に使用可能なオプション数が使用
可能な記述サイズを超える可能性はある。この場合は、
記述を（初期）界面記述ブロックと後続界面記述応答に
分割する必要がある。記述要求は交換開始を行うために
受信機器によって発行される。
【０４４９】選択リスト（ｓｅｌｅｃｔｉｏｎＬｉｓ
ｔ）からの１つまたは複数の選択が後続の決定パス中に
記述されていない場合はさらに利用可能な記述があると
いうことを受信機器は知る。記述プロックからの情報抽
出において、決定ツリー（木構造）のある点以下にはも
はや情報が存在しないことが判断される。さらなる記述
が存在しないことの確認に基づいて（また利用可能なイ
ンライン・データの不存在−インライン・データについ
ては後に説明する）、受信機器がさらに記述を受領する
準備がある場合は記述要求が送信機器に送られる。要求
に対する応答は後続の選択、及びデータを提供する記述
ブロックの連なりとなるであろう。
【０４５０】記述要求はすでに受領した記述から属性
を、各選択リストからの選択とともにリストすることに
よって構成される。エンコーディング階層は使用されな
い。このように受信機は界面記述の処理の間に、受信機
によってなされた選択を識別する。記述要求及び対応す
る記述応答の構成は密接に結びつけられている。これ
は、記述応答のエンコーディング階層からの決定パスが
記述要求中の属性に依存したものであるからである。ｖ
イメージの汎用記述要求ブロックを以下の表４０に示
す。
【０４５１】
【表４０】
【０４５２】記述応答は要求の処理において、選択を認
識し、部分的な決定パスを認識し、選択レベルの下部の
階層に基づいて応答を構築することによって形成され
る。エンコーディング階層を形成する決定パスは記述要
求ブロック中に含まれる属性に依存する。記述要求中の
各レベルは記述応答から省かれる。しかし、記述応答ブ
ロックの構成は元の記述ブロックの構成と同一である。
ｖイメージの汎用記述応答ブロックの構成を以下の表４
１に示す。
【０４５３】
【表４１】
【０４５４】さらに以下で詳述するように、イメージ・
内容データは、界面記述に含まれる。多くの場合、内容
データは記述によって供給されない。この場合、別の内
容要求によって要求される。
【０４５５】受信機器は、送信機器に対して、どのよう
な選択がなされたかを送信デバイスに示すために界面記
述からなされたすべての選択を提供する。さらに、受信
機器は、イメージ・データの参照開始位置を送信機器に
提供する。送信機器は、これによって要求に関するイメ
ージ・データを返すことができる。内容応答はいくつか
のイメージ・データ項目と同様に受信機に送るいくつか
の項目によって構成される。
【０４５６】内容要求は、記述要求の構成と似ている。
内容要求は記述要求におけるのと同様の態様で属性及び
値によって構成される。さらに、受信機器がフル内容の
どの部分が必要かを特定する情報が附加される。テーブ
ルのエンコーディング階層位置は内容要求においては用
いられない。
【０４５７】界面記述処理において、受信機によってな
される選択を識別するために第1セクションが使用され
る。目的は、返却データが選択と一致することである。
第２セクションは要求情報を特定するために使用され
る。内容要求の第1番目の属性−値（バリュー）の対
は、エンコーディング、決定された選択、及びペアレン
ト記述からの値に基づいて定義される。例えば、定義さ
れた属性−値の追加された対がない場合は、要求は決定
された選択を識別し、インラインで提供されていない場
合は描写に必要なデータを要求するのみに使用される。
第1セクションにおける属性−値（バリュー）の対は、
各エンコーデイングにおける内容要求の一部として定義
される。汎用内容要求ブロックの例を以下の表４２に示
す。
【０４５８】
【表４２】
【０４５９】内容応答は受信機器に対する描写可能なデ
ータの配信に使用される。ｖイメージにおいて、内容応
答は生内容データである。データは、１つまたは複数の
データ・ブロックによって形成される。
【０４６０】このデータ・フォーマットの内容応答の一
般的記述は２つのパートによって構成される。第1パー
トは、内容データの第1ブロック（第1ブロックのみ）の
部分として存在する可変長ヘッダである。第２パート
は、各種の適用属性に従ってフォーマットされた実デー
タである。ヘッダ情報は、送信デバイスが応答する各内
容要求に対するデータの第1ブロック中に含まれてい
る。
【０４６１】ヘッダのフォーマットは以下の通りであ
る。バイト０，１はヘッダの長さを示す。バイト２はバ
ージョン（最初は０）、バイト３は保留で０に初期化さ
れている、バイト４−７（４バイト）は、イメージの総
バイト数を示す。これは、ブロック中のバイト数によっ
て（または転送バイト数によって）異なる場合がある。
もし、イメージ・サイズのバイト数がブロック中のバイ
ト数を超える場合は、イメージを完成させるためにはさ
らに別の転送が必要であるということになる。ヘッダ情
報はビッグ・エンディアンにある。データ部分は、ｖエ
ンディアンにおいて示したようにリトル・エンディアン
（Little Endian）にあってもよい。
【０４６２】しかし、内容データは、別の内容要求及び
応答の必要のない記述の一部としてのインラインで送付
されることがある。これは、各種のエンコーディングに
おいて使用可能な大きなイメージには適さないかもしれ
ないが、内容データ量が小さい場合には効果的である。
インラインで提供されるデータは属性ｖデータとともに
提供される。ｖデータと、属性−値（バリュー）の対を
形成する値はデータそれ自体である。この形態におい
て、インライン内容は、記述ブロック中に完全に収まら
なければならない。従って、部分的インライン・データ
は提供されえない。
【０４６３】ｖイメージ、ｅ−マテリアル及び交渉の例
を以下に説明する。なお、以下の各表において示す各記
号の対応は以下に示す通りである。 ｖＩｍａｇｅ：ｖイメージ、 ｖＧｒａｙ：ｖグレィ、
ｖＥｎｃｏｄｉｎｇ：ｖエンコーディング、 ｖＳｉｚ
ｅ：ｖサイズ、ｖＣｏｌｏｒＳｐａｃｅ：ｖカラースペ
ース、ｖＰｉｘｅｌＤｅｐｔｈ：ｖピクセル深度、ｖＲ
ｅｓｏｌｕｔｉｏｎ：ｖ解像度、 ｖＰｉｘｅｌｓ：ｖ
ピクセル、ｖＣｏｍｐｒｅｓｓｉｏｎ:v圧縮、 ｖＤａ
ｔａ：ｖデータ、ｖＳｔａｒｔＢｙｔｅ：ｖスタートバ
イト、ｖＴｅｘｔ：ｖテキスト、 ｖＬａｎｇｕａｇ
ｅ：ｖ言語、ｖＳｙｍｂｏｌＳｅｔ：ｖシンボル・セッ
ト、ｖＣｏｄｅＳｅｔ：ｖコードセット、 ｖＦｉｌ
ｅ：ｖファイル、ｖＣｈｉｌｄｒｅｎ：ｖチャイルド、
ｖＳｔｒｉｎｇ：ｖストリング、ｖＤａｔａＳｉｚ
ｅ：ｖデータサイズ、ｖＦｉｌｅｎａｍｅ：ｖファイル
ネーム、ｖＡｓｓｏｃｉｚｔｉｏｎ：ｖアソシエーショ
ン、ａｔｔｒｉｂｕｔｅ：属性
【０４６４】例１：２インチ四方のイメージが白黒イメ
ージ、非圧縮またはＲＬＥ圧縮、インラインでのデータ
なしで可能な限りデフォルトを用いた形態で提供され
る。
【０４６５】
【表４３】 ｖイメージ・ｅ−マテリアル vEncoding vImage vImage vSize (144000,144000) vImage vColorSpace vGray vImage.vGray vPixelDepth 1 vImage.vGray.1 vResolution (300,300)(150,150) vImage.vGray.1.(300,300) vPixels (600,600) vImage.vGray.1.(300,300) vCompression vRLE vNone vImage.vGray.1.(150,150) vPixels (300,300) vImage.vGray.1.(150,150) vCompression vNone
【０４６６】例２：１インチ四方のイメージが、ｉ）白
黒、２解像度、圧縮またはＲＬＥ圧縮なし、ii）４ビッ
トのグレィスケール、１解像度、２圧縮、及びiii）３
解像度で８ビット／チャネルのｖＳＲＧＢ（ｖＳＲＧＢ
は３チャネルを持つので、これは２４ビット／ピクセ
ル）、非圧縮、で提供される。インラインにおいて、10
0x100解像度でＲＬＥ圧縮された４ビットのグレィスケ
ールが使用できる。
【０４６７】
【表４４】 ｖイメージ・ｅ−マテリアル vEncoding vImage vImage vSize (72000,72000) vImage vColorSpace vGray vSRGB vImage.vGray vPixelDepth 1 4 vImage.vGray.1 vResolution (200,100)(300,300) vImage.vGray.1.(200,100) vCompression vNone vRLE vImage.vGray.1.(300,300) vCompression vNone vRLE vImage.vGray.4 vResolution (100,100) vImage.vGray.4.(100,100) vPixels (100,100) vImage.vGray.4.(100,100) vCompression vNone vRLE vImage.vGray.4.(100,100) vRLE vData (the data...) vImage.vSRGB vPixelDepth 24 vImage.vSRGB.24 vResolution (150,150)(300,300)(600,600) vImage.vSRGB.24.(150,150) vPixels (150,150) vImage.vSRGB.24.(150,150) vCompression vNone vImage.vSRGB.24.(300,300) vPixels (300,300) vImage.vSRGB.24.(300,300) vCompression vNone vImage.vSRGB.24.(600,600) vPixels (600,600) vImage.vSRGB.24.(600,600) vCompression vNone
【０４６８】例３：必須エンコーディング及び２４ビッ
トｓＲＧＢで申し込まれるイメージに対する交渉。ｓＲ
ＧＢは、各種フォーマットにおいて利用可能であり、そ
のうち、ピクセル深度２４ビット、解像度（１５０，１
５０）、ＪＰＥＧ圧縮がインラインにおいて適用可能で
ある。
【０４６９】
【表４５】
【０４７０】この場合、ＪＰＥＧを伴うｖＳＲＧＢ２４
ビットが選択される。デフォルトの解像度は選択されな
いが、提供されるレンジ内の解像度は選択される。レン
ジ内の提供は、インライン・データとしては提供されな
い（従って、この場合ではない）。従って、内容要求が
なされなければならない。要求データ量は未知である。
よって要求データ量は特定されない。デフォルトが可能
な限り送られる。内容要求は以下の表４６に示すｅ−マ
テリアルを含む。
【０４７１】
【表４６】
【０４７２】内容応答は５５００バイト・データであ
る。ここでｅ−マテリアルは以下のフォームを有する。
【０４７３】
【表４７】
【０４７４】受信デバイスは、これがすべてのデータで
あるかは知らない。従って、最初の５５００バイトの後
のデータを要求する以下のような内容要求を送る。
【０４７５】
【表４８】
【０４７６】内容応答は、送付すべきデータはもうない
ことを示す。
【０４７７】
【表４９】
【０４７８】ここでイメージが描写可能である。
【０４７９】例４：例３に似ているが、部分的記述のみ
が初期送信において利用できる。追加記述要求及び記述
応答が、例３における初期送信と同じメッセージを運ぶ
ために必要とされる。メッセージのオープニング・シー
ケンスは以下に示す通りである。
【０４８０】
【表５０】
【０４８１】解像度（ｒｅｓｏｌｕｔｉｏｎ）レベル以
下では情報の提供はなされない。受信デバイスが、この
界面に関する記述の受領を続けたいときは、選択リスト
からの選択に沿って供給される属性に基づいて記述要求
を提供する。これはレンジ内の解像度の提供を含む。
【０４８２】
【表５１】
【０４８３】記述応答は、例３に見られる記述のリマイ
ンダである（あるいはこの記述の関連部分）。エンコー
ディング階層中に示される決定パスの端は切り捨てられ
る。
【０４８４】
【表５２】
【０４８５】ｖイメージ（ｖＩｍａｇｅ）の使用に際し
ては以下の事項が考慮されなければならない。
【０４８６】１．ｖ言語（ｖＬａｎｇｕａｇｅ）属性
は、そのデフォルト値が特定されないオプションの属性
である。受信デバイスは選択リストから値の選択をしな
いことを決定するかもしれない。この場合、ライブラリ
はｅｍリストタイプ中ではなく、レベル中に表記された
第1の値を選択する。 ２．すべてのイメージ・エンコーディングにおいて、階
層において特定したものを除き、データフォーマット
は、ワードパック（４バイト）されており、各走査線が
４バイト境界に詰められている。圧縮機構は、パックさ
れ詰められたデータに対して実行される。これは白黒、
グレィ、カラーデータに適用される。 ３．イメージ・データは、一般に各種のタイプの媒体に
描写される。ｖ平面エンコーディングのガイドラインを
参照されたい。デバイスがｖイメージにｖ平面のチャイ
ルドのエンコーディングをさせることは強制ではない
が、そうすることが望まれる。 ４．イメージはデバイス媒体の物理的境界の外にあるこ
ともある。このような場合、デバイスはデバイスの束縛
状態に基づいてデータの描写を実行しなければならな
い。ある場合は、デバイスはイメージ・データの再フォ
ーマット、サイズ変更が可能であろう。またある場合
は、デバイスは別のサイズの媒体を選択する。また、あ
るデバイスは、データのクリップを実行することになる
であろう。デバイスは、デバイス及びイメージにとって
最適なアクションを選択しなければならない。
【０４８７】ｖテキスト（ｖＴｅｘｔ） ｖテキスト・エンコーディングはテキスト・内容に関連
する属性−値（バリュー）の対を含む。基本属性はテキ
スト・ストリームに関する文字セット及び言語を含む。
一般に、文字表現（シンボル・セット）、表示可能なフ
ォーマット（フォント）、テキストからの構成がペー
ジ、スクリーン、ディスプレイ（平面）上に視覚的表示
される。テキストはそれが存在する領域として表現され
るサイズを有する。サイズまたは領域は、テキストのサ
イズ（高さ及び幅）として解釈される。これらの基本属
性は各種のテキスト表現に使用される。テキストの表示
にさらに他の属性が追加可能である。
【０４８８】ｖテキストの属性階層は図３５に示され
る。図に示される個々の属性の意味について以下に説明
する。
【０４８９】ｖ言語（ｖＬａｎｇｕａｇｅ）：ｖ言語属
性はこの実施形態に含まれる必要がある。
【０４９０】ｖエンコーディング（ｖＬａｎｇｕａｇ
ｅ）：ｖテキスト界面は、テキスト情報の通信において
使用される。ｖテキストの属性はこのエンコーディング
において定義される。
【０４９１】ｖサイズ（ｖＳｉｚｅ）：ディスプレイ界
面に対するテキストサイズを指示する。第1の値は、７
２０００ユニット／インチにおけるｘ軸方向の値、第２
の値はｙ軸方向の値である。受信デバイスはデータを表
現するデイスプレイ領域、対応する情報サイズ、自己の
能力に関して知ることが必要である。属性はテキストデ
ータの最適な表示方法を決定するのに必要な情報を受信
デバイスに与える。
【０４９２】ｖシンボルセット（ｖＳｙｍｂｏｌＳｅ
ｔ）：テキスト値と読解可能なシンボル及び記号間の適
当なマッピングを決定するのに使用される。ｖＡｓｃｉ
ｉシンボル・セットは必須値である。このキーワード値
は、８ビット・テキスト値を解釈、表示するのに使用さ
れるシンボル・セットはデフォルトｖＡｓｃｉｉシンボ
ルセットであることを意味する。ｖユニコード（ｖＵｎ
ｉｃｏｄｅ）がさらに推奨できる。
【０４９３】ｖコードセット（ｖＣｏｄｅＳｅｔ）：ｖ
ユニコード値がｖシンボルセット属性と関連する場合に
要請される。属性ｖコードセットは、ｖシンボルセット
がｖユニコードの値をとるときに適用される。さもなけ
れば、これは用いられない。emレンジタイプ値デバイス
がサポートするユニコード定義からのコードセットを定
義する。
【０４９４】ｖデータ（ｖＤａｔａ）：インライン内容
を提供する。
【０４９５】記述要求及び応答、内容要求及び応答、イ
ンライン・データの提供は、ｖイメージの場合と同様に
構成される。インライン・データは、１つの機器から他
へ読解可能なメッセージが送付されるとき、ｖテキスト
のも最適なオプションとなる。ｖテキストの使用におい
て考慮すべき要素を以下に列挙する。
【０４９６】１．vエンコーディング（ｖＥｎｃｏｄｉ
ｎｇ）属性のｖテキスト（ｖＴｅｘｔ）値が特定される
とき、v言語（ｖＬａｎｇｕａｇｅ）属性もまた“ｅ
ｎ”値によって特定されなければならない。ｖテキスト
（ｖＴｅｘｔ）のエンコーディングは、ｖＡｓｃｉｉシ
ンボル・セットが使われるｖシンボルセット（ｖＳｙｍ
ｂｏｌＳｅｔ）属性である。これは、デバイス間の通信
を可能とする。テキスト及び言語は、すべての環境下で
の確実な通信メカニズムを特定することの困難な通信フ
ォームである。すべてのデバイス（さらに表示データを
見る人々）が同じ言葉を話すわけではない。特定の言語
及びシンボル・セットを特定することがこのゴールを達
成する唯一の方法である。 ２．ｖコードセット（ｖＣｏｄｅＳｅｔ）に関連するｅ
ｍレンジタイプ値がデバイスがサポートするユニコード
・セットを定義するのに使用される。デバイスはこれら
のレンジを特定の固有キャラクタ・コードとしてではな
く、ブロックの一般セットしとして特定すべきである。 ３．テキスト・データは各種のタイプの媒体上に示され
る。一般的に、これはｖテキスト・エンコーディングが
ｖ平面エンコーディングのチャイルド界面であることを
意味する。デバイスがｖテキスト・エンコーディングを
ｖ平面のチャイルドとすることの要請はないが、多くの
場合そうすることが望ましい。
【０４９７】ｖテキストの例を以下に説明する。
【０４９８】例５：ｖ言語属性が挿入され、インライン
データを持つ１以上のエンコーディング・シンプル・テ
キスト(英語ｅｎ、米語ｅｎ−ｕｓ、フランス語ｆｒが
使用可)。
【０４９９】
【表５３】 ｖテキスト vLanguage en en-us fr en vEncoding vText en.vText vSize (7200,108000) en.vText vSymbolset vAscii vUnicode en.vText.vAscii vData This□is□the□text. en.vText.vUnicode vCodeset (0000,007F) en.vText.vUnicode vData This□is□the□text. en-us vEncoding vText en-us.vText vSize (7200,108000) en-us.vText vSymbolset vAscii vUnicode en-us.vText.vAscii vData This□is□the□text. en-us.vText.vUnicode vCodeset (0000,007F) en-us.vText.vUnicode vData This□is□the□text. fr vEncoding vText fr.vText vSize (7200,108000) fr.vText vSymbolset vAscii vUnicode fr.vText.vAscii vData Ceci□est□le□texte. fr.vText.vUnicode vCodeset (0000,007F) fr.vText.vUnicode vData Ceci□est□le□texte.
【０５００】ｖファイル（ｖＦｉｌｅ） これはファイル・フォーマットで情報を転送する規定で
ある。ｖファイルは関連アイコン及びネーミング情報と
同様データの転送を実行するメカニズムを提供する。フ
ァイルは通常、記憶媒体と関連し、ビット及びバイトの
抽象フォーマットであると考えられる。基本的にファイ
ルの内容は知られ得る場合と知られ得ない場合がある。
記憶媒体はさらにファイルのネーミングの取り決めも提
供する。もっともこれはファイルの内容に重要な意味を
与えるものではないかもしれない。さらに、コンピュー
タ化された環境ではアイコンがファイルと関連付けられ
る。ファイルの内容の性質に起因して、ｖファイル（ｖ
Ｆｉｌｅ）・エンコーディングが１つのデバイスから他
のデバイスへファイルのネーム、アイコン、内容情報を
維持したビットの転送のメカニズムとして使用される。
【０５０１】ｖファイルの属性の階層構造を図３６に示
す。各属性の意味（これまでの議論からは明確でない部
分）について、以下で説明する。
【０５０２】ｖ言語（ｖＬａｎｇｕａｇｅ）：オプショ
ンである。
【０５０３】ｖエンコーディング（ｖＥｎｃｏｄｉｎ
ｇ）：ｖファィルは何らかの把握可能な情報のビット集
合として定義される。ファイルの属性はこのエンコーデ
ィングにおいて定義される。
【０５０４】ｖマイムタイプ（ｖＭｉｍｅＴｙｐｅ）：
ｖファイル・タイプの性質を定義する。マイム・タイプ
構成のノーマル・ガイドラインに対してラベルが付与さ
れる。例えば、ａｐｐｌｉｃａｔｉｏｎ／ｍｓｗｏｒ
ｄ，ａｕｄｉｏ／ｂａｓｉｃ，ｉｍａｇｅ／ｔｉｆｆで
ある。
【０５０５】ｖデータサイズ（ｖＤａｔａＳｉｚｅ）：
バイナリ・データのサイズを示す符号無し整数である。
【０５０６】ｖチャイルドアイコン（ｖＣｈｉｌｄＩｃ
ｏｎ）：アイコンとファイルとをリンクする。アイコン
は、チャイルド界面の参照によって示される別の界面上
にある。多くの場合、アイコンチャイルド界面は、ｖイ
メージとしてエンコードされる。
【０５０７】ｖファイル・ネーム（ｖＦｉｌｅｎａｍ
ｅ）：ＡＳＣＩＩシンボル・セットにおいてエンコード
されたヌル（ｎｕｌｌ）ターミネート・テキスト・スト
リングとしてのファイル・ネームを提供する。
【０５０８】記述要求及び応答、内容要求及び応答、イ
ンライン・データの供給は、他のエンコーディングによ
る。例を以下に示す。
【０５０９】例６：最も簡易なファイル・エンコーディ
ング
【０５１０】
【表５４】
【０５１１】データ全体は一般に（ここでは）インライ
ンとするには大きすぎる。従って、内容要求列として要
求される。
【０５１２】例７：ファイルがドキュメントを示す場
合、ｖアソシエーション・ドキュメント・エンコーディ
ングとしても供給される可能性を有する（以下の説明参
照）。この例は６ページ・ドキュメントの場合ついて示
している。
【０５１３】
【表５５】 ｖファイル vEncoding vFile vAssociation vFile vChildIcon 12 vFile vDataSize 12345543 vFile vFilename "myfile" vAssociation child 6 vArbitrary 1 2 3 4 5
【０５１４】ｖ平面（ｖＰｌａｎｅ） ｖ平面エンコーディングは、物理的オブジェクトあるい
は表示の空間的特徴に関するある情報タイプを示すよう
に構成される。特に、これはページ（両面ページを含
む）、ページの２次元領域間の関係、イメージ、テキス
ト、注釈として区分される領域を示し、さらに表示すべ
きメディアについても示す。
【０５１５】ｖ平面の値はトップレベル・エンコーディ
ングを指示し、様々な情報タイプを示すチャイルドを含
む。また、これらのチャイルドの関係を示すためにも用
いられる。
【０５１６】平面は表面及び裏面からなるページを示す
ことができる。ページはサイズ及びカラーを持ち、イメ
ージ及びテキストは平面上に示されるチャイルドを表
す。平面はコンピュータ・スクリーンを示す場合もあ
る。この場合におけるスクリーン・レイアウトは単一面
によって構成される。スクリーンはサイズ及びカラーを
有する。イメージ及びテキストはテキストを伴うウィン
ドウ、スティッキー・ノート、アイコンを示す複数のチ
ャイルドを表す。
【０５１７】ｖ平面エンコーディングを図式化した図を
図３８に示す。ここで平面２７０は界面を示す。界面は
定義され、イメージを示すチャイルドは界面上に置かれ
る。ｚ軸に沿ったチャイルドの順はチャイルドが界面上
に置かれた順序、あるいは描かれた順を示す。
【０５１８】ｖ平面の属性の階層構造を図３７に示す。
各属性の意味（これまでの説明で明確でない部分）につ
いて以下で説明する。
【０５１９】ｖエンコーディング（ｖＥｎｃｏｄｉｎ
ｇ）：ｖ平面はページに似た界面である。これは２つの
サイドをもち、また1つ以上のサブ界面をチャイルドと
して有する。属性はこのエンコーディングにおいて定義
される。
【０５２０】ｖチャイルド・フロント（ｖＣｈｉｌｄＦ
ｒｏｎｔ）：平面の表のチャイルド界面にリンクする参
照リストを提供する。これは負、ゼロ、正である場合が
ある。チャイルド・カウント（ｃｈｉｌｄＣｏｕｎｔ）
の小さい正数は、参照番号との対となっている。他の値
は参照との対はない。送信機器が参照された界面を送信
することができる順に制限がある場合、ｖシーケンシャ
ル（ｖＳｅｑｕｅｎｔｉａｌ）というキーワードが使用
される。さもなければキーワードはｖアービトラリー
（vArbitrary:任意）である。これは受信機器が要求さ
れた界面の順序を完全に制御することを可能とする。
【０５２１】ｖチャイルド・バック（ｖＣｈｉｌｄＢａ
ｃｋ）：ｖフロントと同様であるが、参照リストは平面
の裏面のチャイルド界面にリンクする。
【０５２２】ｖバッククールド（ｖＢａｃｋＣｏｏｒ
ｄ）：バック平面コーディネート・システムの回転数を
定義する。バック平面はフロントの次元を反映すること
が必要である。この属性はｖチャイルド・バック属性が
省略されている場合はオプションである。バック平面コ
ーデイネートに変化がない場合は省略され得る。
【０５２３】ｖサイズ属性に関するｘ及びｙの値が等し
いとき（正四角形平面）、サポートされるｖバッククー
ルド（ｖＢａｃｋＣｏｏｒｄ）値は０，９０，１８０，
２７０である。ｖサイズ属性に関するＸ及びＹの値が等
しくないとき（長方形平面）、サポートされるｖバック
クールド（ｖＢａｃｋＣｏｏｒｄ）値は０，１８０であ
る。平面上のいかなるチャイルドもこのコーディネート
変換に対応して表示される。
【０５２４】ｖバッククールド（ｖＢａｃｋＣｏｏｒ
ｄ）は、以下のように適用される。バック平面（Ｂａｃ
ｋ Ｐｌａｎｅ）はあたかもテンポラリなＹ軸に関して
回転するように見える（図３９及び図４０参照）。ｖバ
ッククールド（ｖＢａｃｋＣｏｏｒｄ）はｘ，ｙ交点周
りの回転、時計周りのカウンタとして適用される（図４
１参照）。次に、平面はデフォルト調整位置に移動され
る（図４２参照）。
【０５２５】ｖサイズ（ｖＳｉｚｅ）：ｖサイズ属性
は、表示される平面の表示次元を指示する。図３８にコ
ーデイネート・システムについて示す。これはまた、使
用される整数値が１／７２０００（１インチあたり７２
０００ユニットを有することを意味する）の実世界コー
ディネートにおいて使用されることを意味する。第1番
目の整数値がｘ軸に沿った値、第2番目の値がｙ軸に沿
った値である。
【０５２６】ｖオパシティ（ｖＯｐａｃｉｔｙ）：下に
ある情報に対する平面の不透明性（オパシティ）を示
す。値は０−２５５であり、デフォルトは２５５(不透
明)である。
【０５２７】ｖカラー（ｖＣｏｌｏｒ）：平面のカラー
を示す。０−２５５のレンジ内の３つの符号無し整数値
リストである。最初の値はレッド要素、第2の値はグリ
ーン要素、第3はブルー要素である。０は強度なしを示
す。２２５はフル強度を示す。ｖオパシティ（ｖＯｐａ
ｃｉｔｙ）が０の場合、ｖカラーは意味を持たない。
【０５２８】ｖポジション（ｖＰｏｓｉｔｉｏｎ）：ペ
アレント界面に対するチャイルドの位置を示す。ペア値
の最初の値はｘ、第２の値はｙに関する。この属性はｖ
チャイルド・フロント及びｖチャイルド・バック属性に
よって参照されるチャイルドのために含まれる。この属
性は情報の提供される各チャイルドに応じて固有のリス
トとして構成される。この属性はどのような数の参照さ
れたチャイルドに対しても提供され得る。
【０５２９】ｖアタッチメント（ｖＡｔｔａｃｈｍｅｎ
ｔ）：ペアレントに関してチャイルドがどのように操作
されたかを示す。
【０５３０】ｖフィックス（ｖＦｉｘｅｄ）の値は、ｖ
ポジション属性によって特定される位置にチャイルドを
固定すべきであることを示す。ｖフローティング（ｖＦ
ｌｏａｔｉｎｇ）の値は、操作可能な機器によって、チ
ャイルドがペアレントに関して再配置されうることを示
す。
【０５３１】ｖアタッチメント（ｖＡｔｔａｃｈｍｅｎ
ｔ）属性は、ｖチャイルド・フロント及びｖチャイルド
・バック属性によって参照されるチャイルドのために含
められる。この属性は、情報が提供される各チャイルド
において固有にリストされる。この属性は、参照される
チャイルドの数がいくつであっても供給される。
【０５３２】記述要求及び応答は実質的に他のエンコー
ディングによる。内容要求及び応答とに関して異なる点
がある。内容要求は受信デバイスによって２つの場合に
チャイルド界面についての情報を要求するのに使用され
る。チャイルド界面についての情報が含まれていない場
合、およびチャイルド参照に関連する情報記述が得られ
なかった場合である。
【０５３３】記述ブロック中にすべての情報が見つから
ない場合は、例えばチャイルド・ネーム参照が使用でき
ない場合である。これらの参照は、間接チャイルド参照
（ｖファースト（ｖＦｉｒｓｔ）及びｖラスト（ｖＬａ
ｓｔ）の値）を使用してチャイルド情報が要求中である
ことを示す内容要求によって要求できる。内容要求が使
用されるもう1つの例は平面に特有でチャイルドに関連
する内容情報を要求する場合である。ｖ平面のエンコー
ディングに関するチャイルド内容情報は、チャイルドと
ペアレントとの関係を示すｖポジション（ｖＰｏｓｉｔ
ｉｏｎ）及びｖアタッチメント（ｖＡｔｔａｃｈｍｅｎ
ｔ）からなる。
【０５３４】受信デバイスは各チャイルドへの参照が必
要である。チャイルド参照は、一般にｖチャイルド・フ
ロントまたはｖチャイルド・バックに関連する参照リス
トの一部であるか、または前述のように記述要求によっ
てすでに受領しているものである。（一般に、参照され
るチャイルドの記述情報は、このレベルではチャイルド
に関する属性は少ないのでインラインである）内容情報
がインラインでない場合、内容要求が情報要求に使用さ
れる。受領デバイスは送信デバイスに対して、どのよう
な選択がなされたかを送信デバイスに示すために、界面
記述からなされたすべての選択を供給する。さらに、受
信デバイスは送信デバイスに対して、もし利用可能なら
チャイルド参照を、あるいは間接参照（ｖファースト及
びｖラストの値）をチャイルド情報の要求がなされてい
ることを示すために供給する。送信デバイスはチャイル
ド参照に関する記述情報を返す。
【０５３５】内容要求ブロックはｖチャイルド（ｖＣｈ
ｉｌｄ）、ｖチャイルド・ネクスト（ｖＣｈｉｌｄＮｅ
ｘｔ）、ｖナンバ（ｖＮｕｍｂｅｒ）のオプション属性
を有する。
【０５３６】ｖチャイルドは、ｖフロント・ファースト
（ｖＦｒｏｎｔＦｉｒｓｔ）、ｖバック・ラスト（ｖＢ
ａｃｋＬａｓｔ）等、あるいは参照リストとしての値を
とり得る。チャイルドが先にｖフロント・ファースト、
ｖフロント・ラスト、ｖバック・ファーストまたはｖバ
ック・ラストを用いて参照されている場合は、これらの
キーワード値は再び使用されない。ここでは1度の参照
が行われ、１つまたは複数のチャイルドのために返され
る内容情報の開始位置が特定される。要求及びシーケン
スの数、参照から前方あるいは後方等の情報はｖナンバ
（ｖＮｕｍｂｅｒ）属性に基づいて決定される。参照リ
ストが特定されると、特定されたの内容の明確な要求と
なる。ｖナンバ属性は使用されない。
【０５３７】キーワード、ｖフロント・ファースト及び
ｖバック・ファーストは、構成中の第1のチャイルドの
間接参照である。これはネーム参照が未知の時と同様、
ネーム参照が特定された時に適用される。キーワード、
ｖフロント・ラスト及びｖバック・ラストは最後のチャ
イルドの参照に用いられる。チャイルドの数が未知の場
合、あるいはアクセスがシーケンシャルである場合は、
チャイルド界面間接参照の最後の１つまでのセッティン
グの結果は、最後がアクセスできないかもしれないので
期待通りにはならない可能性がある。
【０５３８】送信デバイスは、先になされた要求のステ
ータスを保持しない。従って一旦ｖフロント・ファース
ト、ｖフロント・ラスト、ｖバック・ファースト、ｖバ
ック・ラストが使用されると、後続の要求は先の内容要
求中において返された明示された参照を使用するか、ｖ
チャイルド・ネクスト属性を使用する。ｖチャイルド属
性は、ｖチャイルド・ネクスト属性とともに使用すべき
ではない。
【０５３９】ｖチャイルド・ネクストは、先のチャイル
ドが参照された場合に使用される。ｖチャイルド・ネク
ストは、送信デバイスによって識別されるシーケンス中
の次のチャイルドの内容要求に使用される。この属性
は、先のチャイルドが参照されていない場合は用いられ
ない。この属性は、ｖチャイルド属性が参照ネームとと
もに用いられた場合には省略される。
【０５４０】参照値は、要求されるチャイルド情報の前
にあるチャイルドネームである。ｖチャイルド・ネクス
トは、次のチャイルドのネームが未知の場合に用いられ
る。要求及びシーケンス数、参照からの前方または後方
かはｖナンバ属性によって特定される。
【０５４１】ｖナンバはオプションであり、ｖチャイル
ド属性の基で単一の参照が特定された場合、またはｖチ
ャイルド属性がｖフロント・ファースト、ｖフロント・
ラスト、ｖバック・ファースト、ｖバック・ラストにセ
ットされた場合、またはｖチャイルド・ネクスト属性が
使用される場合に用いられる。ｖナンバは、受信デバイ
スが内容要求している参照の数を示す値と関連する。ｖ
ナンバがｖチャイルド属性と関連する参照とともに用い
られる場合は、返還されるアイテムには参照されたチャ
イルドは含まないが、参照のチャイルドに続くチャイル
ドが含まれる。
【０５４２】もし可能であれば、送信側は要求されたチ
ャイルドの内容情報を、その要求順に送信する。属性が
見つからない場合、あるいは値がゼロの場合は、送信側
は参照からできるだけ多くのチャイルド内容を送信す
る。
【０５４３】最適な内容応答は比較的単調である。内容
応答において、属性ｖナンバがチャイルドの数を返す。
ｖネームが要求順にチャイルド参照を返す。ｖ残留（リ
メイニング（ｖＲｅｍａｉｎｉｎｇ））が内容要求の無
いチャイルドの数を示す。ｖポジション及びｖアタッチ
メントの値は返される参照各々に対して提供されるべき
である。
【０５４４】以下に、ｖ平面の使用に際して考慮すべき
事項を列挙する。
【０５４５】１．多くの場合、ｖ平面エンコーディング
はイメージ及びテキストが描かれる媒体として観察され
得る。ページ、コンピュータ・ディスプレイ、ステータ
ス・ディスプレイ、ホワイト・ボード、プロジェクショ
ン等は、これら媒体の例である。イメージやテキストの
ような描写可能なデータエンコーディングはｖ平面とし
て媒体に適用される。明確な記述（ルールではない）と
してはｖイメージ、ｖテキストはｖ平面のチャイルドで
あるということがある。 ２．ｖチャイルド・フロント、ｖチャイルド・バック、
ｖチャイルド、ｖチャイルド・ネクスト、ｖネーム属性
と関連する各参照は固有のものでなければならない。単
一界面か複数回参照されるような機構が提供される。受
信デバイスがこの機構を実行する場合、受信デバイスは
界面要求を複数回行うオプションを有するか、参照デー
タを内的に保持することが必要である。“＃（パウンド
・サイン）参照”は、界面情報が複数回用いられ、かつ
チャイルド内容（ｖポジション、ｖアタッチメント）が
異なる場合に含められる。“＃参照”は、チャイルド及
びチャイルド内容を固有に識別するインデックスとして
作用する。 ３．参照リストがチャイルド界面のネームを含まない場
合は、問い合わせによって獲得することが必要となる。
【０５４６】４．ｖシーケンシャルの値が現れたとき、
チャイルドは、送信側デバイスの制限に従って所定の順
序でのみ要求されることがある。これは以下の処理順を
意味する。 ＊次のチャイルドの内容情報（アタッチメントを記述）
の要求（ペアレント界面上での内容要求及び内容応答を
使用） ＊そのチャイルドの界面記述／インプレッションを要求
（チャイルド界面の記述要求及び応答を使用） ＊そのチャイルドの内容を要求（チャイルド界面の内容
要求及び応答を使用） ＊チャイルドの書込み ＊次のチャイルドの内容（アタッチメント）要求、新た
なチャイルドがいなくなるまで続ける。
【０５４７】５．チャイルド・リストの既知、未知に関
わらず、チャイルドの内容データの要求方法はいくつか
存在する。以下にチャイルド・リスト中のチャイルド界
面のアクセスに適用可能な方法を列挙する。 ＊1以上の参照ネームを伴いｖチャイルドを用いて多数
のチャイルド界面をアクセスする。 ＊リスト中の最初のチャイルド界面をｖフロント・ファ
ーストまたはｖバックファーストを用いてアクセスす
る。 ＊適宜、リスト中の最後のチャイルド界面をｖフロント
・ラストまたはｖバックラストを用いてアクセスする。 ＊リスト中の次の1以上のチャイルド界面の数に等しい
ｖナンバを伴いｖチャイルド・ネクストを用いる。これ
はチャイルド・リスト中のチャイルド界面の最初のアク
セスには使用できない。 ＊リスト中の残りのチャイルド界面のアクセスにｖナン
バがゼロまたは未定義のものを伴ってｖチャイルド・ネ
クストを使用する。これもチャイルド・リスト中のチャ
イルド界面の最初のアクセスには使用できない。
【０５４８】６．チャイルド・リスト中の界面に対する
ランダム・アクセスが以下の手続きに従って実行され
る。 ＊内容要求中で、ｖチャイルド・フロント及びｖチャイ
ルド・バック属性の値として界面ネームを用いる。界面
ネームが内容応答で返される。ｖ平面の場合、アタッチ
メント時用法も併せて返される。 ＊記述要求を構成するためチャイルド界面を用いる。界
面記述が記述応答で返される。新規ジョフが対話ポリシ
ーの欄で説明したように界面要求メッセージ（Ｓｕｒｆ
ａｃｅＲｅｑｕｅｓｔＭｓｇ）の発行により開始され
る。 ＊チャイルド界面の界面内容を獲得するために内容要求
を用いる。内容応答で情報が返される。 ＊内容情報を書き込む ＊必要に応じてこのプロセスを続行する
【０５４９】７．チャイルド・リスト中の界面に対する
シリアル・アクセスは以下の手続きで実行される。 ＊ペアレント界面上の内容要求におけるｖチャイルド・
フロント及びｖチャイルド・バックの値としてｖフロン
ト・ファースト及びｖバック・ファーストが用いられる
（チャイルド・カウント（ＣｈｉｌｄＣｏｕｎｔ）が正
数で、かつｖアービトラリーというキーが与えられてい
るときは、ｖフロント・ラスト及びｖバック・ラストの
値がこれらの属性値として用いられる）。チャイルド・
リスト中の特定されたチャイルド界面の界面ネームがチ
ャイルド・リスト中の残りのチャイルド界面の数ととも
に内容応答で返される。ｖ平面エンコーディングの場合
は、アタッチメント情報も返される。 ＊記述要求を形成するためにチャイルド界面ネームが用
いられる。界面記述が記述応答中において返される。新
規ジョフが対話ポリシーの欄で説明したように界面要求
メッセージ（ＳｕｒｆａｃｅＲｅｑｕｅｓｔＭｓｇ）の
発行により開始される。 ＊チャイルド界面の界面内容を獲得するために内容要求
を用いる。内容応答で情報が返される。 ＊チャイルド界面情報を書き込む。ｖ平面エンコーディ
ングの場合はアタッチメント情報を使用する。 ＊ペアレント界面上の内容要求中におけるｖチャイルド
・ネクスト属性の値としてチャイルド界面ネームを用い
る。チャイルド・リスト中の次のチャイルド界面の界面
ネームがチャイルド・リスト中の残りのチャイルド界面
の数とともに内容応答で返される。ｖ平面エンコーディ
ングの場合は、アタッチメント情報も返される。 ＊この手続きが残りのチャイルド界面が無くなるまで続
けられる。
【０５５０】８．チャイルド・カウント（ｃｈｉｌｄＣ
ｏｕｎｔ）およびｖアービトラリー（ｖＡｒｂｉｔｒａ
ｒｙ）またはｖシーケンシャル（ｖＳｅｑｕｅｎｔｉａ
ｌ）のキーの値がチャイルド・リスト中の各種の界面に
対するアクセス方法を示す。 ＊小さく正のチャイルド・カウント値及びｖアービトラ
リーというキーが、チャイルド界面がいくつかの方法、
例えばシリアル前方に、シリアル後方に、あるいはラン
ダム等の方法でアクセス可能であることを示す。ランダ
ム・アクセスは、参照リスト中の界面ネームを使用する
ことで可能となる。さらに、いくつかのチャイルド界面
のインライン・内容が含まれる。 ＊小さく正のチャイルド値及びｖシーケンシャルという
キーが、チャイルド界面がシリアル前方にアクセス可能
であることを示す。界面ネームは含まれるが、ランダム
・アクセスは許容しない。 ＊大きく正のチャイルド・カウント値及びｖアービトラ
リーというキーが、チャイルド界面がシリアル前方に、
またはシリアル後方にアクセス可能であることを示す。 ＊大きく正のチャイルド・カウント値及びｖシーケンシ
ャルというキーが、チャイルド界面がシリアル前方にの
みアクセス可能であることを示す。 ＊負のチャイルド・カウント値（ｖシーケンシャルまた
はｖアービトラリーといいうキーの設定に無関係に）
が、チャイルド界面がシリアル前方にのみ検出されるこ
とを示す。 ＊ゼロというチャイルド・カウント値は、チャイルド・
リストにチャイルド界面が存在しないことを示す。ｖ平
面の場合は、両チャイルド・リストが空の場合、ｖ平面
界面はｖカラー、ｖサイズ等のわずかな界面を伴う基本
界面である。ｖアソシエーションの場合、チャイルド・
リストが空である場合、界面は無意味である。
【０５５１】９．リスト中のチャイルド界面に対するア
クセスは、参照ネームを介して直接あるいは他の機構を
介して間接になされる。チャイルド・リスト中の各チャ
イルド界面は参照ネーム及びリスト中の位置順を持つ。
順序はすべてのチャイルド・リストに存在し、送信機器
がその順に界面を提供する（ｖシーケンシャル）、また
は界面を任意の順に提供する（ｖアービトラリー）があ
る。ｖ平面中の各チャイルド界面は、界面中の位置（ｖ
ポジション）及び、アタッチメント方法（ｖアタッチメ
ント）を有する。チャイルド界面からの記述あるいは内
容情報の直接アクセスは、常に参照ネームを介する。チ
ャイルド界面からの記述あるいは内容情報の間接アクセ
スは、チャイルド・リストを前方または後方に移動する
ことで行われる。
【０５５２】ｖ平面エンコーディングの使用例について
以下で説明する。
【０５５３】例８：１ページ平面、８．５インチｘ１１
インチ、２つのチャイルド（おそらくはイメージである
が含まれない）。チャイルド・内容情報はインラインで
提供される。
【０５５４】
【表５６】 ｖプレーン vEncoding vPlane vPlane vChildFront 2 vArbitrary 4 5 vPlane vSize (612000,792000) vPlane.4 vPosition (72000,360000) vPlane.4 vAttachment vFixed vPlane.5 vPosition (612000,612000) vPlane.5 vAttachment vFixed
【０５５５】例９：１ページ、２面、前面は２つのチャ
イルド、背面は１つのチャイルド。チャイルド内容情報
は、インラインで提供される。
【０５５６】
【表５７】
【０５５７】例１０：図４３参照、平面２９０は、８．
５インチｘ１１インチの１つの走査されたページ２９１
を持ち、１つの注釈２９２、黄色のハイライト２９３、
赤のスティッキー型のノート２９４、をテキストととも
に有する。１つの注釈２９２、黄色のハイライト２９
３、赤色のスティッキー型のノート２９４は、走査され
たイメージに追加されなければならないものであるの
で、イメージは動的に生成されず、チャイルドの数は知
られている。図４３はこの例を図式化したものである。
【０５５８】チャイルドのない平面エンコーディング
は、以下の表により示される。
【０５５９】
【表５８】 ｖプレーン vEncoding vPlane vPlane vChildFront 4 vSequential 1 2 3 4 vPlane vSize (612000,792000) vPlane.1 vPosition (90000,90000) vPlane.1 vAttachment vFixed vPlane.2 vPosition (288000,72000) vPlane.2 vAttachment vFixed vPlane.3 vPosition (900000,360000) vPlane.3 vAttachment vFixed vPlane.4 vPosition (360000,540000) vPlane.4 vAttachment vFloating
【０５６０】第1のチャイルドは１つのイメージ（バッ
クグラウンド・イメージ）を示す。
【０５６１】
【表５９】
【０５６２】第２のチャイルドはテキスト注釈を示す。
【０５６３】
【表６０】
【０５６４】第３のチャイルドは、黄色のハイライト領
域を示す。これは２つのカラー・モデルで利用される。
【０５６５】
【表６１】
【０５６６】第４のチャイルドは、分離した赤色のステ
ィッキー型のノートを示す。
【０５６７】
【表６２】
【０５６８】ｖアソシエーション（ｖＡｓｓｏｃｉａｔ
ｉｏｎ） ｖアソシエーションは主にドキュメントと、類似および
非類似のエンコーディング・タイプの間の相関とを表し
記述するためのものである。ｖアソシエーションは別の
トップレベル・エンコーディングであり、そのチャイル
ドにおいて複雑な情報タイプを示すために構成される。
これは主にトップレベル・エンコーディングにあるチャ
イルド同士の関係を記述するのに使用される。複数ペー
ジ（ドキュメント）間の関係を記述するのにアソシエー
ションが使用される。これはまたドキュメント間の関係
を付与するフォルダを示すために用いられる。
【０５６９】ｖアソシエーションの属性階層構造を図４
４に示す。各属性の意味は他のトップレベル・エンコー
ディングの説明において明らかであろう。ｖアソシエー
ションはチャイルド界面間の関係を提供するのみであ
る。これは自己の属性を持たない。
【０５７０】記述要求及び応答は技術的には可能である
が、実際上必要とならない。内容要求及び応答について
は、チャイルド界面に関するｖ平面の提供と同様の考え
方である。
【０５７１】ｖ平面に関してと同様の考え方が多くの場
合適用される。注意を要する主な追加考慮点はアソシエ
ーションのネスティングにある。アソシエーションはさ
まざまな異なる事項を示す。これらアソシエーション
は、エンコーディング数が増加するにつれて増加する。
いくつかのデバイスはｖアソシエーションのいくつかの
レベルをｖアソシエーション・エンコーディングのチャ
イルドとして解釈する。ドキュメントがドキュメントの
ページ間の関係を付与し、アソシエーションがドキュメ
ント間の関係を付与するフォルダを示す場合、これはあ
るデバイスによっては理解可能であるが、他のものには
理解不可能であろう。このタイプのネスティングの制限
をデバイスにおいて実行すべきであるが、さらにその使
用の際に理解すべきである。描写不可能(non rendarabl
e)なレベルのネスティングの提供をできないデバイス
は、これらを破棄し、最後の描写可能な部分の描写を行
うことを選択できる。デバイスは、さらにエンコーディ
ングを判読不可能なものであると判断することもある。
描写不可能なデータのネストレベルは、メモリを必要と
し、デバイスはその作用が及ぶ深さを判断しなければな
らない。サポートすべき所定のネスティング・レベルの
設定が望ましい。好適な実施形態では、平面あるいはア
ソシエーション・ネスティングの４レベルまでサポート
されることが要請される。
【０５７２】例１１：アソシエーションは３ページのド
キュメントを示す。チャイルドは受信機の選択するどの
ような順でもインプレスされ得る。しかし、チャイルド
の論理順序は１，２，３として固定される。
【０５７３】
【表６３】 ｖアソシエーション vEncoding vAssociation vAssociation child 3 vArbitrary 1 2 3
【０５７４】ｅ−マテリアル・ブロックのバイトとして
のエンコーディング手法の記述を以下に示す。
【０５７５】各ブロックは属性の順序付けられたシーケ
ンスからなる。属性はネーム及びそのデータからなる。
属性ネーム及び属性レベル・ネームは単純値（simple v
alue）である。しかし、属性データは複雑値（complex
value：例えば単純値のリスト）である。単純値はキー
ワード（短い１バイトキーワード、またはバリュー・タ
イプ識別子を有する長い２バイトキーワード）、ストリ
ング、整数、対（2つの値の集合）整数レンジであり得
る。
【０５７６】エンコーディングのバイト・フォーマット
は表形式に似ている。主な相違点はレベルのエンコーデ
ィングにある。属性レベルにおいて各属性ごとに繰り返
される必要がないので、これらはより効率的に記憶され
る。その代わり、レベルは属性及びレベルの順序付けら
れたシーケンスによって構成されるデータ・タイプ・レ
ベル（複雑値：complex value）とともに属性と同様に
エンコードされる。ｅ−マテリアル・ブロックはブロッ
ク及び１つの属性、ヌル（ｎｕｌｌ）・レベルを持つヘ
ッダを有する。ヌル・レベルは、ブロックの属性及びサ
ブレベルを有する。
【０５７７】ｅ−マテリアルブロック３１０の構成図を
図４５に示す。ラベルのついたいくつかの要素について
以下で説明する。
【０５７８】ヘッダ（Ｈｅａｄｅｒ）３１１はブロック
全体の情報を有する。これはバージョン情報及びサイズ
情報を有する。潜在的にはさらにフィールドを追加する
ことが可能である。ヘッダのトータル・サイズ・フィー
ルドはそのヌル・レベルのサイズよりも大きくもするこ
とができる。これはｅ−マテリアル・ブロックがローカ
ルに生成される際の使用に適している。プログラムが、
メモリ・ブロックを割り当て、そこにヘッダ、ヌル（ｎ
ｕｌｌ）・レベルを書き込み、メモリ・ブロック中で利
用可能なトータル・サイズをトータル・サイズとして設
定する。この値は、ブロックが生成される場合の利用可
能なスペースを見失わないために使用することができ
る。しかし、ブロックがネットワークを介して送付され
る場合は、トータル・サイズは遊び（スラック：ｓｌａ
ｃｋ）のないブロックに一致させることが望ましい。
【０５７９】ｅ−マテリアル・ブロック中の第1エント
リ３１２は、ヌル・レベルとなる。ヌル・レベルはｅ−
マテリアルのすべての属性とサブレベルを含むトップ・
レベルである。ヌル・レベルの外には何も存在しない。
このレベルは実際その生成レベルとしてエンコードされ
る。しかし、そのネームは不変のｖＮＵＬＬ（０ｘ４
０）にセットされなければならない。レベルのヘッダは
レベルのサイズ及びネームを含む。続いて、バリュー・
タイプ（ＬＥＶＥＬ）が、データが例えば他の属性とレ
ベルの集合であるレベルであることを示す。さらにヌル
・レベルの一部としての属性がシーケンス中に続く。
【０５８０】属性は、サイズ、属性のネーム、さらにあ
るデータを含む。ネーム及び値は、あるデータが続くバ
リュー・タイプとしてエンコードされる。サイズはネー
ム及びデータ全体の占めるバイト数である。サブレベル
３１３はデータ・タイプがＬＥＶＥＬに設定された属性
である。サブレベルはレベルデータ、ネーム、レベルタ
イプ識別子、レベル中の属性列によって構成される。
【０５８１】以下の表に示すｅ−マテリアル・ブロック
の構成を図４６に示す。
【０５８２】
【表６４】 ｅ−マテリアル・ブロック Level Attribute Name Attribute Value vEncoding [vText] vText vSize (1000,5000) vText vSymbolset [vAscii vUnicode] vText. vAscii vData "halloejsa" vText.vUnicode vCodeset [0000..00FF] vText.vUnicode vData "hallφjsa"
【０５８３】これは以下に示す１６進ダンプとして示さ
れる。
【０５８４】
【表６５】
【０５８５】ｅ−マテリアルの使用は、エンコーディン
グにおいて極めて高い柔軟性を許容することが理解され
るであろう。しかし、実際上の汎用通信を許容するため
に標準エンコーディングをできるだけ多く用いるべきで
ある。
【０５８６】デバイスは適当な方法によりｅ−マテリア
ル・エンコーディングを分解することが可能である。
【０５８７】オプションである属性は、決定パスが形成
される選択リスト（ＳｅｌｅｃｔｉｏｎＬｉｓｔ）の値
を含むことができる。選択リストの１つの値は、デフォ
ルト値として設定できる。送信デバイスが形成するレベ
ル順はデフォルトで決定できる。デフォルト値は選択リ
ストの最初の値でなければならない。これらのレベルは
受信デバイスがデフォルトを選択する場合には、正しく
形成されている必要がある。
【０５８８】属性−値（バリュー）の対の順序は、送信
デバイスの好み、優先度を示している。どの値を選択す
るかは送信デバイスの好みに関わらず、受信デバイスの
裁量である。選択リスト中の第1エレメントが送信側の
最も好ましい選択であるという構成をとることが好まし
い。
【０５８９】チャイルド界面には明示的な順序がある。
１つのｖアソシエーションにおいて、1度に１つのチャ
イルド界面を完成させることが望まれる。順序は一般に
物理的媒体における順序と密接に関連する。ｖ平面で
は、ｖポジションが物理的順序を示す重要な役割を果た
す。いずれの場合も、順序づけによりチャイルド界面に
対するアクセスの強制を発生させることが多い。
【０５９０】すべての階層レベルは、単一記述または応
答中に含まれ、応答間に渡っては存在しない。この発明
は、例として次の実施形態を含む。
【０５９１】１．情報通信手段を介して実行される複数
の情報処理装置間の情報伝送方法であり、各情報伝送
は、対話セット中の1以上の対話を含み、対話セット中
に含まれるすべての対話は、前記情報処理装置のいずれ
かにおいて実行される情報の処理機能に依存しない構成
である。 ２．ここで各情報伝送は第1デバイスと1以上の第2デバ
イス間の界面の共有に関するものであり、界面は第1デ
バイスの内的状態を示すものである。
【０５９２】３．上記２において、各界面はデータ及び
第1デバイスによって提供され得るデータのフォーマッ
ト・セットを含んでいる。 ４．上記２または３において、各界面は、対話セット中
のどの対話に第1デバイスが応答において適応するかを
示すプロパティ・セットを含む。 ５．上記２から４において、対話セットは、第1デバイ
スの界面であって、1以上の第2デバイスが持たない界面
の共有に関する対話を含む。
【０５９３】６．上記５の情報伝送方法において、すべ
てのデバイスはルート界面を含み、上述の1以上の第２
デバイスのルート界面は、第1デバイスによってシェア
された界面の受領に常に適用可能な構成である。 ７．上記２から６の情報伝送方法において、対話セット
は第1デバイスの界面と１つまたは複数の第2デバイスの
対応界面間の内容転送に関する対話を含む。 ８．上記２から７において、対話セットは第1デバイス
の界面に対応する1以上の第2デバイスの界面の消去ある
いは変更に関する対話を含む。
【０５９４】９．上記２において、各界面は、界面の機
能を示すクラスを含んでいる。 １０．上記９において、デバイスによってサポートされ
る界面の各クラスにおいて、デバイスはデフォルト界面
の提供が可能である。 １１．上記９において、対話セットは、デバイスのサブ
セットにのみ適用可能な新規な界面機能に関する新規な
界面クラスの生成をサポートする。 １２．上記２において、対話セットは第2デバイスによ
る第1デバイスからの界面要求を含む。
【０５９５】１３．上記２から１２において、対話セッ
トは第2デバイスによる第1デバイスからの界面要求を含
み、界面の記述は界面に関連するデータ提供のための選
択階層を含む。 １４．上記１３において、対話セットは界面記述要求に
対する応答を含み、該応答は選択階層からの追加的選択
を含んでいる。 １５．上記２または１２から１４において、対話セット
は界面に関連するデータ提供の要求を含む。 １６．上記１５において、対話セットは界面に関連する
データ要求に対する応答を含む。
【０５９６】１７．上記２または１２から１６におい
て、対話セットは界面変更を要求するメッセージを含
む。 １８．上記１７において、界面変更要求メッセージは界
面変更の実行または拒否に使用可能である。 １９．上記２において、受信デバイスによって理解され
ない対話セット中のすべてのメッセージは拒否される。
【０５９７】２０．上記２から１９において、各デバイ
スは固有界面を有し、固有界面はそのデバイスに関する
情報を含み、デバイス間での情報交換セッションが確立
した場合にこの界面を他のデバイスと交換する手段を持
つ。 ２１．上記２０において、特定のデバイスは他のデバイ
スの識別界面からの情報を記憶するために用いるディレ
クトリ手段を有する。
【０５９８】２２．上記２から２１において、デバイス
機能に従って情報処理可能なジョブ受領デバイスはジョ
ブ送信デバイスからの処理情報を受領するジョブ受領界
面を有する。 ２３．上記２２において、ジョブ受領デバイスによる情
報処理ステップは、ジョブ受領デバイスのジョブ受領界
面をジョブ送信デバイスと共有するステップ、ジョブ送
信デバイスのジョブ情報を含む第1界面をジョブ受領デ
バイスと共有するステップ、ジョブ情報を含む1以上の
界面、ジョブ情報を含む1以上の界面に関連する選択階
層、ジョブ情報を含むデータの界面に関するデータ規則
の選択階層、及びジョブ情報を含むデータについてのジ
ョブ受領デバイスによる要求及びジョブ送信デバイスか
らの供給するステップ、及びジョブ受領デバイスによる
ジョブ情報の処理するステップ、の各ステップを有す
る。
【０５９９】２４．上記２３において、ジョブ受領界面
のシェアの後、ジョブ情報を含む第1界面のシェアの前
に、ジョブ受領デバイスによるジョブ送信デバイスから
のジョブ情報を含む界面の要求ステップを有する。 ２５．上記２から２４において、デバイス機能に従って
情報処理を実行するジョブ受領デバイスはステータス指
示界面を有し、ジョブ受領デバイスはこのステータス指
示界面を、ジョブ受領デバイスに対してジョブを送信す
る他のデバイスとシェアすることが可能である。
【０６００】２６．情報処理デバイス間の通信プロトコ
ルであり、このプロトコルは、対話セットからの対話を
含み、対話セット中に含まれるすべての対話は、情報処
理装置のいずれかにおいて実行される情報の処理機能に
依存しない。
【０６０１】２７．上記２６の通信プロトコルにおい
て、各対話は第1デバイスと1または複数の第2デバイス
間の界面の共有に関するものであり、界面は第1デバイ
スの内的状態を示すものである。 ２８．上記２７の通信プロトコルにおいて、各界面はデ
ータ及び第1デバイスによって提供され得るデータのフ
ォーマット・セットを含んでいる。 ２９．上記２７または２８の通信プロトコルにおいて、
各界面は、対話セット中のどの対話に第1デバイスが応
答において適応するかを示すプロパティ・セットを含
む。
【０６０２】３０．上記２７から２９の通信プロトコル
において、対話セットは、第1デバイスの界面であっ
て、1以上の第2デバイスが持たない界面の共有に関する
対話を含む。 ３１．上記２７から３０の通信プロトコルにおいて、対
話セットは第1デバイスの界面と1以上の第2デバイスの
対応界面間の内容転送に関する対話を含む。 ３２．上記２７から３１の通信プロトコルにおいて、対
話セットは第1デバイスの界面に対応する1以上の第2デ
バイスの界面の消去あるいは変更に関する対話を含む。
【０６０３】３３．上記２７の通信プロトコルにおい
て、対話セットは第2デバイスによる第1デバイスからの
界面要求を含む。 ３４．上記２７から３３の通信プロトコルにおいて、対
話セットは第2デバイスによる第1デバイスからの界面要
求を含み、界面記述は界面に関連するデータ要求に関す
るの選択階層を含む。 ３５．上記３４の通信プロトコルにおいて、対話セット
は界面記述要求に対する応答を含み、該応答は選択階層
からのさらなる追加的選択を含んでいる。
【０６０４】３６．上記２７または３３から３５の通信
プロトコルにおいて、対話セットは界面に関連するデー
タ提供の要求を含む。 ３７．上記３６の通信プロトコルにおいて、対話セット
は界面に関連するデータ要求に対する応答を含む。 ３８．上記２７またｈ３３から３７の通信プロトコルに
おいて、対話セットは界面変更を要求するメッセージを
含む。 ３９．上記３８において、界面変更要求メッセージは界
面変更の実行または拒否に使用可能である。
【０６０５】４０．上記２７の通信プロトコルにおい
て、受信デバイスによって理解されない対話セット中の
すべてのメッセージは拒否される。 ４１．上記２７から４０の通信プロトコルにおいて、デ
バイス機能に従って、情報処理可能なジョブ受領デバイ
スはジョブ送信デバイスからの処理情報を受領するジョ
ブ受領界面を有する。
【０６０６】４２．上記４１の通信プロトコルにおい
て、ジョブ受領デバイスによる情報処理ステップは、ジ
ョブ受領デバイスのジョブ受領界面をジョブ送信デバイ
スとシェアするステップ、ジョブ送信デバイスのジョブ
情報を含む第1界面をジョブ受領デバイスとシェアする
ステップ、ジョブ情報を含む1以上の界面、ジョブ情報
を含む1以上の界面に関連する選択階層、ジョブ情報を
含むデータの界面に関するデータ規則の選択階層、及び
ジョブ情報を含むデータについてのジョブ受領デバイス
による要求及びジョブ送信デバイスからの供給するステ
ップ、及びジョブ受領デバイスによるジョブ情報の処理
ステップ、の各ステップを有する。
【０６０７】４３．上記４２の通信プロトコルにおい
て、ジョブ受領界面のシェアの後、ジョブ情報を含む第
1界面のシェアの前に、ジョブ受領デバイスによるジョ
ブ送信デバイスからのジョブ情報を含む界面の要求ステ
ップを有する。 ４４．上記２７から４３の通信プロトコルにおいて、デ
バイス機能に従って情報処理を実行するジョブ受領デバ
イスはステータス指示界面を有し、ジョブ受領デバイス
はこのステータス指示界面を、ジョブ受領デバイスに対
してジョブを送信する他のデバイスとシェアすることが
可能である。
【０６０８】４５．本発明は、上記１から２５の情報伝
送方法に従って情報の送信または受信を実行する情報処
理デバイスも含むものである。 ４６．本発明は、上記２６から４４の通信プロトコルに
従って情報の送信または受信を実行する情報処理デバイ
スも含むものである。
【０６０９】
【発明の効果】以上詳述したように、本発明によれば、
デバイスに依存しない情報交換が可能となり、デバイス
の接続、情報交換、データタイプの交渉、オペレーショ
ンについての状況交換等が柔軟に実行可能となり、極め
て高い柔軟性を有する情報通信が実現される。
【図面の簡単な説明】
【図１】１つのデバイス上に他のデバイスの界面表現か
ら界面インプレッションを生成する構成を説明する図。
【図２】視覚的及び界面表現によって２ページのドキュ
メントを示した図。
【図３】ジェットセンド機構及びその相互の論理関係を
示した図。
【図４】セッションを確立した場合の２つのデバイス間
でのメッセージ交換を説明する図。
【図５】２つのジェットセンド・デバイス間におけるセ
ッション構成を示す図。
【図６】ジェットセンド・プロトコル・セッションにお
ける状態構成を示す図。
【図７】ジェットセンド・プロトコル・セッションの開
始を説明する図。
【図８】ジェットセンド・セッション・プロトコルにお
けるチャネルのオープン及びクローズを説明する図。
【図９】ジェットセンド・セッション・プロトコルにお
ける部分的メッセージ・フラグメンテーションを説明す
る図。
【図１０】ジェットセンド・セッション・プロトコルを
用いたゲートウェイ・ブロードキャスト・メッセージの
タイマによるスケジューリングを説明する図。
【図１１】ジェットセンド・セッション・プロトコル・
メッセージ・ヘッダの汎用フォーマットを示す図。
【図１２】機器間の情報交換におけるジェットセンド国
際プロトコル（ＪＳプロトコル）のメッセージの使用を
説明する図。
【図１３】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図１４】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図１５】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図１６】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図１７】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図１８】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図１９】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図２０】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図２１】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図２２】機器間の情報交換におけるＪＳプロトコルの
使用を説明する図。
【図２３】メッセージ・チャネルにおける内容提供を説
明する図。
【図２４】ストリーム・チャネルにおける内容提供を説
明する図。
【図２５】周知界面を例としてセルフ界面の構成図を示
した図。
【図２６】ジョブ・ポリシーに従ったドキュメント転送
の例を示す図。
【図２７】周知界面の構成を示す図。
【図２８】一般的セルフ界面の構成を示す図。
【図２９】セルフ界面及びそのサブ界面の構成を示す
図。
【図３０】ステータス界面の構成を示す図。
【図３１】ステータス界面及びそのサブ界面の構成を示
す図。
【図３２】アドレス・イン界面の構成を示す図。
【図３３】アドレス・イン界面と通信するアドレス・カ
ード界面を示す図。
【図３４】ｖイメージ・エンコーディングの属性階層を
示す図。
【図３５】ｖテキスト・エンコーディングの属性階層を
示す図。
【図３６】ｖファイル・エンコーディングの属性階層を
示す図。
【図３７】ｖ平面エンコーディングの属性階層を示す
図。
【図３８】ｖ平面エンコーディングにおける要素構成を
示す図。
【図３９】ｖ平面エンコーディングにおけるｖバック・
クールド値の誘導について説明する図。
【図４０】ｖ平面エンコーディングにおけるｖバック・
クールド値の誘導について説明する図。
【図４１】ｖ平面エンコーディングにおけるｖバック・
クールド値の誘導について説明する図。
【図４２】ｖ平面エンコーディングにおけるｖバック・
クールド値の誘導について説明する図。
【図４３】４つのチャイルド・エレメントと関連するｖ
平面エンコーディングにおけるドキュメントの例を示す
図。
【図４４】ｖアソシエーション・エンコーディングの属
性階層を示す図。
【図４５】一般的ｅ−マテリアル・ブロックの構成を示
す図。
【図４６】特定のｅ−マテリアル・ブロックの構成を示
す図。
【図４７】界面記述エンコーディング階層の構成を示す
図。
【図４８】この発明が適用されるデバイス間の通信を説
明する図。
【符号の説明】
１１ 表現（エクスプレッション） １２ インプ
レッション ２１ 視覚的表現 ２２トップ・レベル界面 ２３ 平面エンコーディング第1平面 ２４ 平面エンコーディング第２平面 ２５ イメージ界面 ２６テキスト界面２６ ３１ デバイス・コード ３２ ｅ−マテリアル ３３ 対話プロトコル ３４ セッション・プロ
トコル ３５ 対話ポリシー ３６ 双方向通信構成 ３７ ＲＭＴＰプロトコル ５１，５２ ジェッ
トセンド・デバイス ５３ メッセージ・チャネル ５４ ストリーム
・チャネル

Claims (1)

    【特許請求の範囲】
  1. 【請求項１】 情報通信手段を介する複数の情報取り扱
    い装置間における情報伝送方法であって、 情報のそれぞれの伝送は、対話セットからの１つまたは
    複数の対話を含み、 前記対話セット中に含まれる対話は、前記情報取り扱い
    装置のいずれが情報に対して実行する機能に対しても依
    存しないことを特徴とする情報伝送方法。
JP10115918A 1997-04-15 1998-04-13 情報伝送方法 Pending JPH10304013A (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GBGB9707551.9A GB9707551D0 (en) 1997-04-15 1997-04-15 Method of passing information
US5404797P 1997-07-18 1997-07-18
US60/054,047 1997-07-18
US9707551.9 1997-07-18

Publications (1)

Publication Number Publication Date
JPH10304013A true JPH10304013A (ja) 1998-11-13

Family

ID=26311377

Family Applications (3)

Application Number Title Priority Date Filing Date
JP10115918A Pending JPH10304013A (ja) 1997-04-15 1998-04-13 情報伝送方法
JP10115919A Withdrawn JPH10320310A (ja) 1997-04-15 1998-04-13 情報伝送方法
JP54363098A Withdrawn JP2001524231A (ja) 1997-04-15 1998-04-15 装置制御の方法および装置

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP10115919A Withdrawn JPH10320310A (ja) 1997-04-15 1998-04-13 情報伝送方法
JP54363098A Withdrawn JP2001524231A (ja) 1997-04-15 1998-04-15 装置制御の方法および装置

Country Status (5)

Country Link
US (3) US6721286B1 (ja)
EP (3) EP0872991B1 (ja)
JP (3) JPH10304013A (ja)
DE (2) DE69835314T2 (ja)
WO (1) WO1998047076A1 (ja)

Families Citing this family (250)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001345854A (ja) * 2000-03-27 2001-12-14 Matsushita Electric Ind Co Ltd ネットワーク間のパケット通信方法及びシステム並びに装置
US8352400B2 (en) 1991-12-23 2013-01-08 Hoffberg Steven M Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore
EP0872991B1 (en) * 1997-04-15 2006-07-26 Hewlett-Packard Company, A Delaware Corporation Method and apparatus for device interaction by format
US6453356B1 (en) * 1998-04-15 2002-09-17 Adc Telecommunications, Inc. Data exchange system and method
US6311222B1 (en) * 1998-10-07 2001-10-30 Nortel Networks Corporation Translator memory management system
US6434574B1 (en) * 1998-12-17 2002-08-13 Apple Computer, Inc. System and method for storing and retrieving filenames and files in computer memory using multiple encodings
US7966078B2 (en) 1999-02-01 2011-06-21 Steven Hoffberg Network media appliance system and method
US6947994B1 (en) 1999-04-09 2005-09-20 Canon Kabushiki Kaisha Negotiating an exchange of image processing functionality
EP1069500A1 (en) * 1999-07-12 2001-01-17 International Business Machines Corporation Downloadable user-interface
US7610559B1 (en) * 1999-07-27 2009-10-27 Samsung Electronics Co., Ltd. Device customized home network top-level information architecture
US6804211B1 (en) * 1999-08-03 2004-10-12 Wi-Lan Inc. Frame structure for an adaptive modulation wireless communication system
US7010607B1 (en) * 1999-09-15 2006-03-07 Hewlett-Packard Development Company, L.P. Method for training a communication link between ports to correct for errors
US7191236B2 (en) * 2000-05-02 2007-03-13 Canon Kabushiki Kaisha Transparent telecommunications system and apparatus
US7191242B1 (en) * 2000-06-22 2007-03-13 Apple, Inc. Methods and apparatuses for transferring data
DE10038562B4 (de) * 2000-08-03 2005-12-15 Siemens Ag System und Verfahren zur Übertragung von Daten über Datennetze mit Datenumsetzung durch einen COM Automarschaller
US7251695B2 (en) * 2000-08-17 2007-07-31 Aspen Technology, Inc. Computer network communication method and apparatus
US7376897B1 (en) * 2000-09-30 2008-05-20 Intel Corporation Method, apparatus, and system for determining information representations and modalities based on user preferences and resource consumption
US8817045B2 (en) 2000-11-06 2014-08-26 Nant Holdings Ip, Llc Interactivity via mobile image recognition
WO2002041520A2 (en) * 2000-11-15 2002-05-23 Ensemble Communications, Inc. Improved frame structure for a communication system using adaptive modulation
US6807561B2 (en) * 2000-12-21 2004-10-19 Gemplus Generic communication filters for distributed applications
JP4586268B2 (ja) * 2000-12-25 2010-11-24 ヤマハ株式会社 ネットワークにおけるデータ送受信管理方法及び同データ送受信管理装置
US8009667B1 (en) * 2001-01-16 2011-08-30 Wi—LAN, Inc. Packing source data packets into transporting packets with fragmentation
US7165107B2 (en) * 2001-01-22 2007-01-16 Sun Microsystems, Inc. System and method for dynamic, transparent migration of services
US7197565B2 (en) * 2001-01-22 2007-03-27 Sun Microsystems, Inc. System and method of using a pipe advertisement for a peer-to-peer network entity in peer-to-peer presence detection
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
US7653701B2 (en) * 2001-02-23 2010-01-26 Hewlett-Packard Development Company, L.P. Network system and method for automatically transferring data in a plurality of input and output formats to a computer network
US7433942B2 (en) * 2001-02-27 2008-10-07 Intel Corporation Network management
US20040133745A1 (en) 2002-10-28 2004-07-08 Quicksilver Technology, Inc. Adaptable datapath for a digital processing system
US7752419B1 (en) 2001-03-22 2010-07-06 Qst Holdings, Llc Method and system for managing hardware resources to implement system functions using an adaptive computing architecture
US7653710B2 (en) 2002-06-25 2010-01-26 Qst Holdings, Llc. Hardware task manager
US7962716B2 (en) 2001-03-22 2011-06-14 Qst Holdings, Inc. Adaptive integrated circuitry with heterogeneous and reconfigurable matrices of diverse and adaptive computational units having fixed, application specific computational elements
US6836839B2 (en) 2001-03-22 2004-12-28 Quicksilver Technology, Inc. Adaptive integrated circuitry with heterogeneous and reconfigurable matrices of diverse and adaptive computational units having fixed, application specific computational elements
EP1381965B1 (en) * 2001-03-23 2018-05-09 BlackBerry Limited Systems and methods for content delivery over a wireless communication medium to a portable computing device
US7552216B2 (en) * 2001-03-27 2009-06-23 Lexmark International, Inc. Method of sharing a printer
US20020156941A1 (en) * 2001-04-18 2002-10-24 David Boll Scanner having passthrough input control
US7747764B2 (en) * 2001-04-20 2010-06-29 Rockwell Automation Technologies, Inc. Web access for non-TCP/IP control devices of an industrial control system
US7272636B2 (en) * 2001-04-24 2007-09-18 Sun Microsystems, Inc. Peer group name server
US6577678B2 (en) 2001-05-08 2003-06-10 Quicksilver Technology Method and system for reconfigurable channel coding
US6517266B2 (en) * 2001-05-15 2003-02-11 Xerox Corporation Systems and methods for hand-held printing on a surface or medium
US7383321B2 (en) 2002-07-09 2008-06-03 Moyer Alan L Method and system for communicating between a remote printer and a server
US20020198947A1 (en) * 2001-06-21 2002-12-26 Robert Sesek Electronic document sender system and method with external address access
US7441007B1 (en) * 2001-07-30 2008-10-21 At&T Intellectual Property I, L.P. System and method for allowing applications to retrieve properties and configuration information from a persistent store
US7191209B1 (en) 2001-07-30 2007-03-13 Bellsouth Intellectual Property Corp. Application server and method to perform hierarchical configurable data manipulation
US7353248B1 (en) 2001-07-30 2008-04-01 At&T Delaware Intellectual Property, Inc. Application server and method to perform hierarchical configurable data validation
US7249193B1 (en) * 2001-08-28 2007-07-24 Emc Corporation SRDF assist
US7062503B1 (en) * 2001-08-28 2006-06-13 Emc Corporation Shuttle-based mechanism for numbering concurrent chains of independent data transfers
JP2003085086A (ja) * 2001-09-12 2003-03-20 Sony Corp サービス提供システム、サービス提供方法
US20030069987A1 (en) * 2001-10-05 2003-04-10 Finnur Sigurdsson Communication method
US20030076813A1 (en) * 2001-10-23 2003-04-24 Markus Isomaki Method and packet switched communication network with enhanced session establishment
US20030086122A1 (en) * 2001-11-06 2003-05-08 Parry Travis J. Imaging device communication via email
US20030088852A1 (en) * 2001-11-07 2003-05-08 Lone Wolf Technologies Corporation. Visual network operating system and methods
US20030093555A1 (en) * 2001-11-09 2003-05-15 Harding-Jones William Paul Method, apparatus and system for routing messages within a packet operating system
US20030097494A1 (en) * 2001-11-21 2003-05-22 Parry Travis J. Imaging device list storage
US20030097426A1 (en) * 2001-11-21 2003-05-22 Parry Travis J. Imaging device configuration and upgrade
US20030097427A1 (en) * 2001-11-21 2003-05-22 Parry Travis J. Multiple device configuration and upgrade for imaging devices
US7046635B2 (en) 2001-11-28 2006-05-16 Quicksilver Technology, Inc. System for authorizing functionality in adaptable hardware devices
US8412915B2 (en) 2001-11-30 2013-04-02 Altera Corporation Apparatus, system and method for configuration of adaptive integrated circuitry having heterogeneous computational elements
US6986021B2 (en) 2001-11-30 2006-01-10 Quick Silver Technology, Inc. Apparatus, method, system and executable module for configuration and operation of adaptive integrated circuitry having fixed, application specific computational elements
US7215701B2 (en) 2001-12-12 2007-05-08 Sharad Sambhwani Low I/O bandwidth method and system for implementing detection and identification of scrambling codes
US7403981B2 (en) 2002-01-04 2008-07-22 Quicksilver Technology, Inc. Apparatus and method for adaptive multimedia reception and transmission in communication environments
US7916322B2 (en) * 2002-03-14 2011-03-29 Senshin Capital, Llc Method and apparatus for uploading content from a device to a remote network location
KR100424318B1 (ko) * 2002-03-20 2004-03-25 엘지전자 주식회사 가전기기 네트워크 시스템 및 그 제어방법
US7328414B1 (en) 2003-05-13 2008-02-05 Qst Holdings, Llc Method and system for creating and programming an adaptive computing engine
US7660984B1 (en) 2003-05-13 2010-02-09 Quicksilver Technology Method and system for achieving individualized protected space in an operating system
US7620678B1 (en) 2002-06-12 2009-11-17 Nvidia Corporation Method and system for reducing the time-to-market concerns for embedded system design
US20040003349A1 (en) * 2002-06-28 2004-01-01 Microsoft Corporation Content segments
US20040010540A1 (en) * 2002-07-09 2004-01-15 Puri Anish N. Method and system for streamlining data transfer between a content provider server and an output server
US7355609B1 (en) * 2002-08-06 2008-04-08 Apple Inc. Computing visible regions for a hierarchical view
JP2004078268A (ja) 2002-08-09 2004-03-11 Fujitsu Ltd 情報処理装置、情報処理方法、およびプログラム
US8108656B2 (en) 2002-08-29 2012-01-31 Qst Holdings, Llc Task definition for specifying resource requirements
US7849140B2 (en) * 2002-08-29 2010-12-07 Oracle America, Inc. Peer-to-peer email messaging
US7263560B2 (en) * 2002-08-30 2007-08-28 Sun Microsystems, Inc. Decentralized peer-to-peer advertisement
WO2004025407A2 (en) * 2002-09-10 2004-03-25 Quicksilver Technology, Inc. Method and system for an interconnection network to support communications among a plurality of heterogeneous processing elements
US7937591B1 (en) 2002-10-25 2011-05-03 Qst Holdings, Llc Method and system for providing a device which can be adapted on an ongoing basis
US8276135B2 (en) 2002-11-07 2012-09-25 Qst Holdings Llc Profiling of software and circuit designs utilizing data operation analyses
CA2505630C (en) * 2002-11-15 2010-02-23 International Business Machines Corporation Network traffic control in peer-to-peer environments
US7225301B2 (en) 2002-11-22 2007-05-29 Quicksilver Technologies External memory controller node
US8561069B2 (en) 2002-12-19 2013-10-15 Fujitsu Limited Task computing
JP5583310B2 (ja) * 2002-12-20 2014-09-03 チャクシュ・リサーチ・インコーポレーテッド 眼球の症状の予防及び治療のための眼科用製剤
US7289995B2 (en) * 2002-12-26 2007-10-30 Ricoh Company, Ltd. Method and system for using internal data structures for storing information related to remotely monitored devices
KR100645428B1 (ko) * 2003-05-05 2006-11-15 삼성전자주식회사 개인 통신무선 네트워크에서 라우팅 경로 설정 장치 및 방법
US7383335B2 (en) * 2003-05-29 2008-06-03 Hewlett-Packard Development Company, L.P. Method and apparatus for securing a print job
US20050022686A1 (en) * 2003-07-28 2005-02-03 Dreampatch, Llc Apparatus, method, and computer program product for animation pad transfer
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
KR20050043429A (ko) * 2003-11-06 2005-05-11 삼성전자주식회사 채널 자원 관리 방법 및 장치
US8117280B2 (en) * 2003-12-12 2012-02-14 Fujitsu Limited Task computing
US20050166215A1 (en) * 2004-01-27 2005-07-28 International Business Machines Corporation Common user interface for interacting with various interfaces
US7774834B1 (en) 2004-02-18 2010-08-10 Citrix Systems, Inc. Rule generalization for web application entry point modeling
US7890996B1 (en) * 2004-02-18 2011-02-15 Teros, Inc. Using statistical analysis to generate exception rules that allow legitimate messages to pass through application proxies and gateways
US7228396B2 (en) * 2004-03-08 2007-06-05 Emc Corporation Switching between virtual ordered writes mode and synchronous or semi-synchronous RDF transfer mode
US7519714B2 (en) * 2004-03-18 2009-04-14 The Johns Hopkins University Adaptive image format translation in an ad-hoc network
US8239868B2 (en) * 2004-03-19 2012-08-07 International Business Machines Corporation Computer system, servers constituting the same, and job execution control method and program
US7742606B2 (en) * 2004-03-26 2010-06-22 Harman International Industries, Incorporated System for audio related equipment management
US7096142B2 (en) * 2004-04-02 2006-08-22 Agilent Technologies, Inc. Report format editor for circuit test
US20050256923A1 (en) * 2004-05-14 2005-11-17 Citrix Systems, Inc. Methods and apparatus for displaying application output on devices having constrained system resources
US7593991B2 (en) * 2004-08-05 2009-09-22 At&T Intellectual Property I, L.P. Systems and methods for processing attachments associated with electronic messages
US7634721B1 (en) * 2004-08-23 2009-12-15 Sun Microsystems Inc. Composite component architecture using javaserver pages (JSP) tags
US7574503B2 (en) * 2004-08-27 2009-08-11 Ricoh Company Ltd. Method and system for using abstract classes to extract status information from networked devices
US7493327B1 (en) * 2004-09-23 2009-02-17 Microsoft Corporation Schema-facilitated device capability discovery
US7519307B2 (en) * 2004-10-08 2009-04-14 Sharp Laboratories Of America, Inc. Methods and systems for configuration-based imaging device accounting
US8051125B2 (en) * 2004-10-08 2011-11-01 Sharp Laboratories Of America, Inc. Methods and systems for obtaining imaging device event notification subscription
US8120797B2 (en) 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for transmitting content to an imaging device
US8115946B2 (en) * 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and sytems for imaging device job definition
US8001586B2 (en) 2004-10-08 2011-08-16 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential management and authentication
US8006293B2 (en) 2004-10-08 2011-08-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential acceptance
US8115947B2 (en) * 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and systems for providing remote, descriptor-related data to an imaging device
US7826081B2 (en) 2004-10-08 2010-11-02 Sharp Laboratories Of America, Inc. Methods and systems for receiving localized display elements at an imaging device
US7873553B2 (en) 2004-10-08 2011-01-18 Sharp Laboratories Of America, Inc. Methods and systems for authorizing imaging device concurrent account use
US7970813B2 (en) 2004-10-08 2011-06-28 Sharp Laboratories Of America, Inc. Methods and systems for imaging device event notification administration and subscription
US8384925B2 (en) 2004-10-08 2013-02-26 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting data management
US8001183B2 (en) * 2004-10-08 2011-08-16 Sharp Laboratories Of America, Inc. Methods and systems for imaging device related event notification
US8001587B2 (en) * 2004-10-08 2011-08-16 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential management
US7738808B2 (en) 2004-10-08 2010-06-15 Sharp Laboratories Of America, Inc. Methods and systems for imaging device concurrent account use with remote authorization
US7870185B2 (en) * 2004-10-08 2011-01-11 Sharp Laboratories Of America, Inc. Methods and systems for imaging device event notification administration
US8018610B2 (en) 2004-10-08 2011-09-13 Sharp Laboratories Of America, Inc. Methods and systems for imaging device remote application interaction
US7966396B2 (en) * 2004-10-08 2011-06-21 Sharp Laboratories Of America, Inc. Methods and systems for administrating imaging device event notification
US7920101B2 (en) 2004-10-08 2011-04-05 Sharp Laboratories Of America, Inc. Methods and systems for imaging device display standardization
US7633644B2 (en) 2004-10-08 2009-12-15 Sharp Laboratories Of America, Inc. Methods and systems for imaging device job management
US8065384B2 (en) * 2004-10-08 2011-11-22 Sharp Laboratories Of America, Inc. Methods and systems for imaging device event notification subscription
US8171404B2 (en) * 2004-10-08 2012-05-01 Sharp Laboratories Of America, Inc. Methods and systems for disassembly and reassembly of examination documents
US8237946B2 (en) 2004-10-08 2012-08-07 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting server redundancy
US8006176B2 (en) * 2004-10-08 2011-08-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging-device-based form field management
US8006292B2 (en) * 2004-10-08 2011-08-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential submission and consolidation
US7969596B2 (en) 2004-10-08 2011-06-28 Sharp Laboratories Of America, Inc. Methods and systems for imaging device document translation
US8024792B2 (en) * 2004-10-08 2011-09-20 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential submission
US7934217B2 (en) 2004-10-08 2011-04-26 Sharp Laboratories Of America, Inc. Methods and systems for providing remote file structure access to an imaging device
US8120799B2 (en) 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for accessing remote, descriptor-related data at an imaging device
US8060930B2 (en) * 2004-10-08 2011-11-15 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential receipt and authentication
US7978618B2 (en) 2004-10-08 2011-07-12 Sharp Laboratories Of America, Inc. Methods and systems for user interface customization
US8060921B2 (en) * 2004-10-08 2011-11-15 Sharp Laboratories Of America, Inc. Methods and systems for imaging device credential authentication and communication
US8120798B2 (en) 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for providing access to remote, descriptor-related data at an imaging device
US8125666B2 (en) 2004-10-08 2012-02-28 Sharp Laboratories Of America, Inc. Methods and systems for imaging device document management
US8115945B2 (en) * 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and systems for imaging device job configuration management
US8120793B2 (en) 2004-10-08 2012-02-21 Sharp Laboratories Of America, Inc. Methods and systems for displaying content on an imaging device
US8015234B2 (en) 2004-10-08 2011-09-06 Sharp Laboratories Of America, Inc. Methods and systems for administering imaging device notification access control
US8230328B2 (en) 2004-10-08 2012-07-24 Sharp Laboratories Of America, Inc. Methods and systems for distributing localized display elements to an imaging device
US8049677B2 (en) 2004-10-08 2011-11-01 Sharp Laboratories Of America, Inc. Methods and systems for imaging device display element localization
US8156424B2 (en) 2004-10-08 2012-04-10 Sharp Laboratories Of America, Inc. Methods and systems for imaging device dynamic document creation and organization
US8035831B2 (en) 2004-10-08 2011-10-11 Sharp Laboratories Of America, Inc. Methods and systems for imaging device remote form management
US8115944B2 (en) 2004-10-08 2012-02-14 Sharp Laboratories Of America, Inc. Methods and systems for local configuration-based imaging device accounting
US7532835B2 (en) * 2004-10-08 2009-05-12 Sharp Laboratories Of America, Inc. Methods and systems for remote configuration-based imaging device accounting
US8023130B2 (en) 2004-10-08 2011-09-20 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting data maintenance
US7684074B2 (en) * 2004-10-08 2010-03-23 Sharp Laboratories Of America, Inc. Methods and systems for imaging device metadata management
US8032608B2 (en) * 2004-10-08 2011-10-04 Sharp Laboratories Of America, Inc. Methods and systems for imaging device notification access control
US7873718B2 (en) * 2004-10-08 2011-01-18 Sharp Laboratories Of America, Inc. Methods and systems for imaging device accounting server recovery
US8051140B2 (en) * 2004-10-08 2011-11-01 Sharp Laboratories Of America, Inc. Methods and systems for imaging device control
US8032579B2 (en) * 2004-10-08 2011-10-04 Sharp Laboratories Of America, Inc. Methods and systems for obtaining imaging device notification access control
US8213034B2 (en) 2004-10-08 2012-07-03 Sharp Laboratories Of America, Inc. Methods and systems for providing remote file structure access on an imaging device
US8775650B2 (en) * 2004-10-29 2014-07-08 Core Wireless Licensing S.A.R.L. Memory association to folder information
US7489698B2 (en) * 2004-12-16 2009-02-10 International Business Machines Corporation Mediator based architecture for first responder interoperability systems (FRIS)
US8065336B2 (en) * 2004-12-20 2011-11-22 Fujitsu Limited Data semanticizer
US20060200548A1 (en) * 2005-03-02 2006-09-07 N-Able Technologies International, Inc. Automation engine and method for providing an abstraction layer
US8428484B2 (en) 2005-03-04 2013-04-23 Sharp Laboratories Of America, Inc. Methods and systems for peripheral accounting
US8788687B2 (en) 2006-10-04 2014-07-22 Welch Allyn, Inc. Dynamic medical object information base
KR20070116893A (ko) * 2005-03-30 2007-12-11 웰치알린인코포레이티드 복수의 네트워크 엘리먼트 사이의 정보 통신
US20060248145A1 (en) * 2005-04-18 2006-11-02 Srimantee Karmakar System and method for providing various levels of reliable messaging between a client and a server
US7466659B1 (en) * 2005-04-29 2008-12-16 Network Appliance, Inc. System and method for performing version negotiation of a network protocol and associated interfaces
US7443872B1 (en) 2005-04-29 2008-10-28 Network Appliance, Inc. System and method for multiplexing channels over multiple connections in a storage system cluster
US7657537B1 (en) 2005-04-29 2010-02-02 Netapp, Inc. System and method for specifying batch execution ordering of requests in a storage system cluster
US7870265B2 (en) * 2005-06-30 2011-01-11 Oracle International Corporation System and method for managing communications sessions in a network
US20070024332A1 (en) * 2005-07-28 2007-02-01 Standard Microsystems Corporation All MOS power-on-reset circuit
KR101019569B1 (ko) 2005-08-29 2011-03-08 에브릭스 테크놀로지스, 인코포레이티드 모바일 이미지 인식을 통한 상호작용
US20070061394A1 (en) * 2005-09-09 2007-03-15 Soonr Virtual publication data, adapter for mobile devices
US7779069B2 (en) * 2005-09-09 2010-08-17 Soonr Corporation Network adapted for mobile devices
US8116288B2 (en) * 2005-09-09 2012-02-14 Soonr Corporation Method for distributing data, adapted for mobile devices
CN101346634B (zh) * 2005-11-04 2012-10-24 甲骨文国际公司 用于通信网络中的网守的系统和方法
US7924884B2 (en) 2005-12-20 2011-04-12 Citrix Systems, Inc. Performance logging using relative differentials and skip recording
US8972872B2 (en) 2006-03-27 2015-03-03 Fujitsu Limited Building computing applications based upon metadata
US8151323B2 (en) 2006-04-12 2012-04-03 Citrix Systems, Inc. Systems and methods for providing levels of access and action control via an SSL VPN appliance
WO2007134339A2 (en) * 2006-05-16 2007-11-22 Bea Systems, Inc. Engine near cache for reducing latency in a telecommunications environment
US8112525B2 (en) * 2006-05-16 2012-02-07 Oracle International Corporation Engine near cache for reducing latency in a telecommunications environment
US8001250B2 (en) * 2006-05-16 2011-08-16 Oracle International Corporation SIP and HTTP convergence in network computing environments
US8171466B2 (en) 2006-05-16 2012-05-01 Oracle International Corporation Hitless application upgrade for SIP server architecture
US8219697B2 (en) 2006-05-17 2012-07-10 Oracle International Corporation Diameter protocol and SH interface support for SIP server architecture
US7953889B2 (en) * 2006-08-03 2011-05-31 Citrix Systems, Inc. Systems and methods for routing VPN traffic around network disruption
US8244883B2 (en) 2006-08-03 2012-08-14 Citrix Systems, Inc. Systems and methods of for providing multi-mode transport layer compression
US8677007B2 (en) * 2006-08-03 2014-03-18 Citrix Systems, Inc. Systems and methods for bypassing an appliance
US8345272B2 (en) 2006-09-28 2013-01-01 Sharp Laboratories Of America, Inc. Methods and systems for third-party control of remote imaging jobs
EP2092470A2 (en) 2006-10-16 2009-08-26 Hospira, Inc. System and method for comparing and utilizing activity information and configuration information from mulitple device management systems
US7853679B2 (en) * 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring handling of undefined policy events
US7865589B2 (en) 2007-03-12 2011-01-04 Citrix Systems, Inc. Systems and methods for providing structured policy expressions to represent unstructured data in a network appliance
US8490148B2 (en) 2007-03-12 2013-07-16 Citrix Systems, Inc Systems and methods for managing application security profiles
US8631147B2 (en) 2007-03-12 2014-01-14 Citrix Systems, Inc. Systems and methods for configuring policy bank invocations
US7853678B2 (en) 2007-03-12 2010-12-14 Citrix Systems, Inc. Systems and methods for configuring flow control of policy expressions
US7870277B2 (en) * 2007-03-12 2011-01-11 Citrix Systems, Inc. Systems and methods for using object oriented expressions to configure application security policies
JP2008257478A (ja) * 2007-04-04 2008-10-23 Internatl Business Mach Corp <Ibm> 検証対象文字列の格納位置出力装置、方法、及びコンピュータ・プログラム
US8255335B1 (en) 2007-04-11 2012-08-28 United Services Automobile Association (Usaa) System and method to establish a PIN
WO2008146197A1 (en) * 2007-05-25 2008-12-04 Koninklijke Philips Electronics N.V. Easy to use universal remote control
US20090189892A1 (en) * 2008-01-27 2009-07-30 Nitin Desai Methods and systems for detecting a dirty region within a frame encompassing three dimensional graphics
US20100053468A1 (en) * 2008-08-30 2010-03-04 Mike Harvill Device ir setup using ir detector
US8179912B2 (en) * 2008-09-26 2012-05-15 Oracle International Corporation System and method for providing timer affinity through engine polling within a session-based server deployment
US9723048B2 (en) * 2008-10-29 2017-08-01 Oracle International Corporation System and method for providing timer affinity through notifications within a session-based server deployment
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
KR20100138700A (ko) * 2009-06-25 2010-12-31 삼성전자주식회사 가상 세계 처리 장치 및 방법
WO2011011718A2 (en) * 2009-07-24 2011-01-27 Welch Allyn, Inc. Configurable health-care equipment apparatus
JP5990466B2 (ja) 2010-01-21 2016-09-14 スビラル・インコーポレーテッド ストリームに基づく演算を実装するための汎用複数コアシステムのための方法および装置
US9091851B2 (en) 2010-02-28 2015-07-28 Microsoft Technology Licensing, Llc Light control in head mounted displays
WO2011106797A1 (en) 2010-02-28 2011-09-01 Osterhout Group, Inc. Projection triggering through an external marker in an augmented reality eyepiece
US9128281B2 (en) 2010-09-14 2015-09-08 Microsoft Technology Licensing, Llc Eyepiece with uniformly illuminated reflective display
US9341843B2 (en) 2010-02-28 2016-05-17 Microsoft Technology Licensing, Llc See-through near-eye display glasses with a small scale image source
US9229227B2 (en) 2010-02-28 2016-01-05 Microsoft Technology Licensing, Llc See-through near-eye display glasses with a light transmissive wedge shaped illumination system
US9223134B2 (en) 2010-02-28 2015-12-29 Microsoft Technology Licensing, Llc Optical imperfections in a light transmissive illumination system for see-through near-eye display glasses
US20150309316A1 (en) 2011-04-06 2015-10-29 Microsoft Technology Licensing, Llc Ar glasses with predictive control of external device based on event input
US20120249797A1 (en) 2010-02-28 2012-10-04 Osterhout Group, Inc. Head-worn adaptive display
US9097890B2 (en) 2010-02-28 2015-08-04 Microsoft Technology Licensing, Llc Grating in a light transmissive illumination system for see-through near-eye display glasses
US10180572B2 (en) 2010-02-28 2019-01-15 Microsoft Technology Licensing, Llc AR glasses with event and user action control of external applications
US9129295B2 (en) 2010-02-28 2015-09-08 Microsoft Technology Licensing, Llc See-through near-eye display glasses with a fast response photochromic film system for quick transition from dark to clear
US9134534B2 (en) 2010-02-28 2015-09-15 Microsoft Technology Licensing, Llc See-through near-eye display glasses including a modular image source
US9759917B2 (en) 2010-02-28 2017-09-12 Microsoft Technology Licensing, Llc AR glasses with event and sensor triggered AR eyepiece interface to external devices
US9097891B2 (en) 2010-02-28 2015-08-04 Microsoft Technology Licensing, Llc See-through near-eye display glasses including an auto-brightness control for the display brightness based on the brightness in the environment
US9182596B2 (en) 2010-02-28 2015-11-10 Microsoft Technology Licensing, Llc See-through near-eye display glasses with the optical assembly including absorptive polarizers or anti-reflective coatings to reduce stray light
US9366862B2 (en) 2010-02-28 2016-06-14 Microsoft Technology Licensing, Llc System and method for delivering content to a group of see-through near eye display eyepieces
US20120194549A1 (en) * 2010-02-28 2012-08-02 Osterhout Group, Inc. Ar glasses specific user interface based on a connected external device type
US9285589B2 (en) 2010-02-28 2016-03-15 Microsoft Technology Licensing, Llc AR glasses with event and sensor triggered control of AR eyepiece applications
US8621365B2 (en) * 2010-04-06 2013-12-31 Asustek Computer Inc. File sharing method and system
USD635681S1 (en) 2010-07-22 2011-04-05 Welch Allyn, Inc. Patient-monitor housing
USD632397S1 (en) 2010-07-22 2011-02-08 Welch Allyn, Inc. Portions of a patient-monitor housing
USD671222S1 (en) 2010-07-22 2012-11-20 Welch Allyn, Inc. Module for a patient-monitor or the like
EP2423831A1 (en) * 2010-08-27 2012-02-29 Axel Springer Digital TV Guide GmbH Recommender system with consistent profile application
US20120089923A1 (en) * 2010-10-08 2012-04-12 Microsoft Corporation Dynamic companion device user interface
US20120300628A1 (en) * 2011-05-26 2012-11-29 Dan Prescott Method and apparatus to passively determine the state of a flow including determining flow state in the event of missing data on one or both sides of the flow
WO2013059615A1 (en) 2011-10-21 2013-04-25 Hospira, Inc. Medical device update system
US10360565B2 (en) 2012-05-18 2019-07-23 Kofax, Inc. System and method for providing a universal endpoint address schema to route documents and manage document workflows
US9400622B2 (en) 2012-06-29 2016-07-26 Hewlett-Packard Development Company, L.P. Path independent print queues
JP6102323B2 (ja) * 2012-07-10 2017-03-29 株式会社リコー 印刷処理システム
DE102012216489A1 (de) * 2012-09-17 2014-03-20 Terex Cranes Germany Gmbh Verfahren zum Bedienen eines Fernsteuerungssystems sowie derartiges Fernsteuerungssystem
US9066323B2 (en) 2012-11-15 2015-06-23 Hewlett-Packard Development Company, L.P. Ad Hoc network connection
EP2964079B1 (en) 2013-03-06 2022-02-16 ICU Medical, Inc. Medical device communication method
US9134937B2 (en) 2013-04-01 2015-09-15 Hewlett-Packard Development Company, L.P. Secure printing
EP3039596A4 (en) 2013-08-30 2017-04-12 Hospira, Inc. System and method of monitoring and managing a remote infusion regimen
US10545657B2 (en) 2013-09-03 2020-01-28 Apple Inc. User interface for manipulating user interface objects
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
US10042986B2 (en) 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
JP6853669B2 (ja) 2014-04-30 2021-03-31 アイシーユー・メディカル・インコーポレーテッド 条件付きの警報転送を用いた患者治療システム
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
CN116243841A (zh) 2014-06-27 2023-06-09 苹果公司 尺寸减小的用户界面
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
AU2015337826A1 (en) * 2014-10-27 2017-05-18 Rideshark Corporation Methods and systems for notifications in communications networks
CA2988094A1 (en) 2015-05-26 2016-12-01 Icu Medical, Inc. Infusion pump system and method with multiple drug library editor source capability
DK201670595A1 (en) 2016-06-11 2018-01-22 Apple Inc Configuring context-specific user interfaces
AU2017295722B2 (en) 2016-07-14 2022-08-11 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
AU2019306490A1 (en) 2018-07-17 2021-02-04 Icu Medical, Inc. Updating infusion pump drug libraries and operational software in a networked environment
US11139058B2 (en) 2018-07-17 2021-10-05 Icu Medical, Inc. Reducing file transfer between cloud environment and infusion pumps
US10964428B2 (en) 2018-07-17 2021-03-30 Icu Medical, Inc. Merging messages into cache and generating user interface using the cache
ES2962660T3 (es) 2018-07-17 2024-03-20 Icu Medical Inc Sistemas y métodos para facilitar la mensajería clínica en un entorno de red
AU2019309766A1 (en) 2018-07-26 2021-03-18 Icu Medical, Inc. Drug library management system
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
US11768483B2 (en) 2019-05-22 2023-09-26 Illinois Tool Works Inc. Distributed weld monitoring system with job tracking

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3381881D1 (de) * 1983-02-22 1990-10-18 Ibm Verfahren zur dynamischen rekonfiguration eines datenverarbeitungssystems bei hinzufuegung von einrichtungen.
US5818603A (en) 1996-03-29 1998-10-06 Ricoh Company, Ltd. Method and system for controlling and communicating with machines using multiple communication formats
US5123063A (en) * 1990-10-10 1992-06-16 Fuji Xero Co., Ltd. Image processor utilizing and controlling a plurality of scanners
US5317693A (en) 1991-04-04 1994-05-31 Digital Equipment Corporation Computer peripheral device network with peripheral address resetting capabilities
US5933580A (en) 1991-09-04 1999-08-03 Canon Kabushiki Kaisha Scanner printer server
GB2268816B (en) * 1992-07-14 1996-01-17 Sony Broadcast & Communication Controlling equipment
US5611024A (en) * 1992-08-28 1997-03-11 Compaq Computer Corporation Data compression of bit map images
US5647056A (en) 1992-11-18 1997-07-08 Canon Information Systems, Inc. Method and apparatus for managing access to a networked peripheral
US5784622A (en) 1992-11-18 1998-07-21 Canon Kabushiki Kaisha Method and apparatus for multiprotocol operation of a networked peripheral
JP3332443B2 (ja) 1993-01-18 2002-10-07 キヤノン株式会社 情報処理装置および情報処理方法
US5537417A (en) 1993-01-29 1996-07-16 International Business Machines Corporation Kernel socket structure for concurrent multiple protocol access
US5634074A (en) 1993-05-07 1997-05-27 Apple Computer, Inc. Serial I/O device identifies itself to a computer through a serial interface during power on reset then it is being configured by the computer
EP0626635B1 (en) * 1993-05-24 2003-03-05 Sun Microsystems, Inc. Improved graphical user interface with method for interfacing to remote devices
US5577172A (en) 1994-07-01 1996-11-19 Lasermaster Corporation High-capacity protocol for packet-based networks
US5485460A (en) * 1994-08-19 1996-01-16 Microsoft Corporation System and method for running multiple incompatible network protocol stacks
US5657221A (en) * 1994-09-16 1997-08-12 Medialink Technologies Corporation Method and apparatus for controlling non-computer system devices by manipulating a graphical representation
US5636333A (en) * 1994-12-20 1997-06-03 Lexmark International, Inc. Multi-protocol network interface
US5674003A (en) * 1995-04-28 1997-10-07 Andersen; David B. Mechanisms for accessing unique features of telephony networks from a protocol-Independent data transport interface
US5787237A (en) * 1995-06-06 1998-07-28 Apple Computer, Inc. Uniform interface for conducting communications in a heterogeneous computing network
US5710908A (en) 1995-06-27 1998-01-20 Canon Kabushiki Kaisha Adaptive network protocol independent interface
US6199082B1 (en) * 1995-07-17 2001-03-06 Microsoft Corporation Method for delivering separate design and content in a multimedia publishing system
US5907837A (en) * 1995-07-17 1999-05-25 Microsoft Corporation Information retrieval system in an on-line network including separate content and layout of published titles
JPH0991102A (ja) * 1995-09-26 1997-04-04 Ricoh Co Ltd ネットワーク・システムにおけるプリント・ジョブ実行結果の通知方法，ネットワーク・システムにおけるスキャン条件の設定方法およびネットワーク・プリンティング／スキャニング・システム
US5826027A (en) * 1995-10-11 1998-10-20 Citrix Systems, Inc. Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process system
US5760775A (en) * 1995-10-30 1998-06-02 Xerox Corporation Apparatus and method for programming a job ticket in a document processing system
US5909183A (en) 1996-12-26 1999-06-01 Motorola, Inc. Interactive appliance remote controller, system and method
EP0872991B1 (en) * 1997-04-15 2006-07-26 Hewlett-Packard Company, A Delaware Corporation Method and apparatus for device interaction by format
US6229810B1 (en) * 1997-12-31 2001-05-08 At&T Corp Network server platform for a hybrid fiber twisted pair local loop network service architecture

Also Published As

Publication number Publication date
EP0886411A2 (en) 1998-12-23
EP0872991A3 (en) 2004-01-07
US6502000B1 (en) 2002-12-31
WO1998047076A1 (en) 1998-10-22
EP0872991B1 (en) 2006-07-26
US6721286B1 (en) 2004-04-13
EP0872991A2 (en) 1998-10-21
EP0976058A1 (en) 2000-02-02
DE69835314D1 (de) 2006-09-07
JPH10320310A (ja) 1998-12-04
DE69802792T2 (de) 2002-05-23
EP0976058B1 (en) 2001-12-05
JP2001524231A (ja) 2001-11-27
US6202096B1 (en) 2001-03-13
DE69802792D1 (de) 2002-01-17
DE69835314T2 (de) 2007-05-10
EP0886411A3 (en) 2004-01-21

Similar Documents

Publication Publication Date Title
JPH10304013A (ja) 情報伝送方法
JP2751693B2 (ja) マルチメディアメール装置及びマルチメディア情報転送方法
EP1152582B1 (en) Transparent telecommunications system and apparatus
US7289245B2 (en) Color facsimile device capable of transmitting color image information represented in appropriate color space through multiple communication channels
US7933261B2 (en) Communication method, communication system, communication device, and program using multiple communication modes
US20010030766A1 (en) Image input/output system, image input/output control device, and control method therefor
JP2006345560A (ja) スキャナからネットワークを介してクライアント・コンピュータに画像情報を伝送するための画像伝送方法、画像伝送システム、コンピュータにより利用可能な媒体、および、メモリ
JPH0723057A (ja) 媒体変換装置及びその方法
CN1951086A (zh) 选择并向终端传输文件
EP1684495A1 (en) Communication apparatus, transmission program, computer readable medium storing a transmission program, transmission method and communication system for reliably transmitting image data
US20120206768A1 (en) Image processing system, image processor and image processing program
US7576884B2 (en) Image output system, client terminal device, image output device, and image output method using e-mail to inform client of output status
JPH10150464A (ja) 周辺装置
CN107634974A (zh) 一种数据传输方法及装置
AU764551B2 (en) System and method for secure transmission of data clients
JP2000347954A (ja) 電子メールシステムの通信制御方法
EP0995153B1 (en) Format for passing information between devices
JP4067461B2 (ja) ファクシミリ通信システム、通信端末装置および通信システム
JPH118728A (ja) 原稿読取装置および原稿読取システム
JP3508060B2 (ja) 赤外線通信方式
JP2001136337A (ja) データ通信装置及び方法
JP2001111763A (ja) ファクシミリ装置
JP2002125081A (ja) ファクシミリサーバ
Dujonc RFC1921: TNVIP Protocol
Dujonc TNVIP Protocol

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040517

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20040517

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20050808

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060704

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20061206