JP2006277758A - 通信方法 - Google Patents

Abstract

【課題】リモート・サービス・アプリケーションにオブジェクト指向を導入することにより、開発サイクル期間の低減を図り、システムの修正等の柔軟性を高めることがでる通信方法を提供する。
【解決手段】メモリ５０を有するコンピュータ・システム１を使用し、複数のマシーン・タイプの複数のリモート・マシーン９０と通信する方法において、メモリ５０内に、複数のリモート・マシーン９０の１つにサービスを記述する第１の複数のソフトウェア・オブジェクトを構成するステップと、コンピュータシステム１がオブジェクトに記述された実行される機能に応じて１つのリモート・マシーン９０と交信するステップと，コンピュータシステム１が第１の複数のオブジェクトに記述された実行される機能に応じて交信したリモート・マシーン９０のオペレーションを呼び出すステップと，を含んでいる。
【選択図】 図１

Description

本発明は、通信方法に関するものであり、特に、通信を介して情報処理を行う際の通信方法に関する。

近年，プログラムの開発・分析や，システムの設計において，オブジェクト指向の考え方が広く用いられるようになっており，様々なオブジェクト指向分析およびオブジェクト指向設計の手法が提案されている。

従来技術または背景技術として，オブジェクト指向プログラミングおよびオブジェクト指向アプリケーション・フレームワークを理解することは，本発明を完全に理解する上で役立つであろう。当業者ならすぐ分かるように，『オブジェクト』とは，現実世界に存在するものの抽象であり，データ構造（そのフィールドは『属性』あるいは『データ・メンバー』と呼ばれる）と，その上で実行できる一連の操作（『メソッド』または『メンバー機能』と呼ばれる）の組み合わせとして実現（インプリメント）されているものである。

『クラス』とは，それぞれ同じデータ構造および同じ操作を有する一連のオブジェクトに関するデータ・タイプである。クラスの１つの『インスタンス』は，実行中のアプリケーション・プログラムのメモリ内で実際に具体化されるような，そのデータ・タイプがそのクラスであるような１つのオブジェクトである。

複数のクラスは，『形質』（inheritance)に基づく１つまたは複数の（コンパイル時間）階層にグループ化され，それによって『サブクラス』のインタフェース（つまり，属性およびメソッドのタイプと名称）を１つまたは複数の『スーパークラス』との違いで指定することが可能になる。インスタンスは，『コンテインメント』（containment)によって１つまたは複数の（ラン時間）階層にグループ化することができ，複数の他のオブジェクトを含んでいる１つのオブジェクトは『コンテナー』または『集合』（collection) と呼ばれる。

なお，オブジェクト指向プログラミングの概念に関するさらに詳しい情報は，ＭａｒｇａｒｅｔＡ．ＥｌｌｉｓおよびＢｊａｒｎｅ ＳｔｒｏｕｓｔｒｕｐによるＴｈｅ Ａｎｎｏｔａｔｅｄ Ｃ＋＋ Ｒｅｆｅｒｅｎｃｅ Ｍａｎｕａｌ，Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ社，１９９０に紹介されている。

『オブジェクト指向アプリケーション・フレームワーク』は，アプリケーション・プログラマによって拡張，細分化が可能なように設計され，さらにこれらのクラスを用い，アプリケーション・プログラマによって修正が可能なように設計されたいくつかの実例的な（illustrative) サンプル・アプリケーションと共にパッケージ化された複数のクラスのライブラリで構成されている。

このサンプル・アプリケーションは，全体として，それ自体が有益な１つのシステムを構成している。一般的に，フレームワークの基本的な概念は当業者にはよく知られている。いくつかのサンプル・フレームワークは，Ｘ Ｔｏｏｌｋｉｔ，Ｍｏｔｉｆ Ｔｏｏｌｋｉｔ，Ｓｍａｌｌｔａｌｋ Ｍｏｄｅｌ−Ｖｉｅｗ−Ｃｏｎｔｒｏｌｌｅｒ ＧＵＩおよびＭａｃＡｐｐを含んでいる。

また，『アプリケーション』とは，コンピュータ・ユーザーがあるタスクまたは一連のタスクを達成することができるようにするプログラム，または一連の共働プログラムを意味する。

さらに，リモート・サービス・アプリケーションとは，コンピュータ・ユーザーが，そのユーザーのコンピュータ・システムとは別個の，多くの場合は離れた場所，つまり，オフサイトのマシーン（リモート・マシーン）と交信し，その上でサービス（オペレーション）を実行できるようにするアプリケーションのことである。リモート・マシーンのいくつかの例としては，コピー機，ファクシミリ装置，それに電話機等のオフィス機器，それにファイル・サーバーやデータベース・サーバー等一定のリモート・コンピュータ・システムのメモリにおけるソフトウェア・エンティティを含んでいる。

リモート・サービス・アプリケーションで行われる典型的な操作としては，リモート・マシーンの問題点のリモート診断，リモート・マシーンの使用のモニタリング，リモート・マシーンの特徴を実行可能にしたり不可にしたりすること，データ検索，パラメータの変更等がある。

なお，以下で『リモート・マシーン』という用語を用いる際，それはユーザー・マシーン内に保存されているが，リモート・サービス・アプリケーションによってコントロールされるメモリおよびプロセスに対しては外部的なものであるプロセスおよびファイル等も含むという理解に基づいている。

リモート・マシーンにアクセスするためには，そのリモート・サービス・アプリケーションは，モデム等の特定のインタフェース装置と関連した『装置ドライバー』と，そのリモート・マシーンとの間で送受信されるデータをフォーマットする『プロトコル・ドライバー』とを用いる。これらのドライバーはオペレーティング・システムの一部であっても良く，またはアプリケーション・プログラム内のモジュールであっても良い。

過去において，リモート・サービス・アプリケーションは，各タイプのリモート・マシーンに対してそれぞれ個別的にカスタマイズされていた。例えば，第１のリモート・サービス・アプリケーションは特定のプロトコルを有するマシーンとだけ交信したが，第２のリモート・サービス・アプリケーションは異なったプロトコルを有するマシーンとだけ交信するという具合であった。こうしたカスタマイズされた方式の１つの利点は，リモート・サービス・アプリケーションが対応するリモート・マシーンのアーキテクチャおよびパラメータにしっかりと結びつけられているので，それらが効率的である点である。

しかしながら，上記従来の技術である，個別的にカスタマイズされたリモート・サービス・アプリケーションによれば，以下の不具合およびそれらの不具合から発生する問題点があった。

第１に，各ソフトウェア・システムが往々にして，顧客データベース等の各システムのために一般的に使われ，あるいは複製された機能やデータを含んでいるという不具合があった。第２に，新しいタイプのリモート・マシーンが製造される度に，新しいソフトウェア・システムがその新しいタイプの独特の能力と取り組むために新しいソフトウェア・システムが作られる必要があるという不具合があった。

これらの不具合が存在することから，従来の技術では，ソフトウェア・システムがいろいろな断片からつくられることが多く，したがって，開発サイクル期間が非常に長くなるという問題点があった。また，それぞれ個別的にカスタマイズされた方式は，往々にして柔軟性が乏しいという問題点があった。一般的に，ソフトウェア・システムが一度オンライン化されると，そのソフトウェア・システムの他の部分に対して無数の繋がりがあるので，そのソフトウェア・システムに対する修正が非常に困難である。

本発明は上記に鑑みてなされたものであって，リモート・サービス・アプリケーションにオブジェクト指向を導入することにより，開発サイクル期間の低減を図り，システムの修正等の柔軟性を高めることができる通信方法を提供することを目的とする。

上述した課題を解決し、目的を達成するために、請求項１にかかる発明は、複数の周辺装置と，周辺装置の属性情報を記憶した記憶手段を有する情報処理装置とが通信する通信方法において，前記情報処理装置の前記記憶手段内部に，属性情報に基づいて前記複数の周辺装置の１つで実行される機能を記述するオブジェクトを構成するステップと，前記情報処理装置が前記オブジェクトに記述された実行される機能に応じて前記１つの周辺装置と交信するステップと，前記情報処理装置が前記第１の複数のオブジェクトに記述された実行される機能に応じて前記交信した周辺装置のオペレーションを呼び出すステップと，を含んでいることを特徴とする。

また，請求項２にかかる発明は、請求項１に記載の通信方法において、属性情報には、前記オブジェクトに対するポインタと前記１つの周辺装置内部でのデータ・アイテムの値に対応したカレント値を含んでいることを特徴とする。

また，請求項３にかかる発明は、請求項１または２に記載の通信方法において、属性情報には，読み出しリクエスト・フラッグと前記１つの周辺装置に送られるべき値に関するペンディング・リクエストを記述するための新しい値とを含んでいることを特徴とする。

以上説明したように，本発明の通信方法（請求項１〜請求項３）は，複数の周辺装置と，周辺装置の属性情報を記憶した記憶手段を有する情報処理装置とが通信する通信方法において，前記情報処理装置の前記記憶手段内部に，属性情報に基づいて前記複数の周辺装置の１つで実行される機能を記述するオブジェクトを構成するステップと，前記情報処理装置が前記オブジェクトに記述された実行される機能に応じて前記１つの周辺装置と交信するステップと，前記情報処理装置が前記第１の複数のオブジェクトに記述された実行される機能に応じて前記交信した周辺装置のオペレーションを呼び出すステップと，を含んでいるため，リモート・サービス・アプリケーションにオブジェクト指向を導入することにより，開発サイクル期間の低減を図り，システムの修正等の柔軟性を高めることができる通信方法を提供することができる。

以下，本発明のオブジェクト指向通信システムの使用方法について，〔本発明の概要〕，〔本発明で使用する用語の定義〕，〔命名上の規定〕，〔実施の形態〕，〔著作権に関する告知〕の順で，図面を参照して詳細に説明する。

〔本発明の概要〕
本発明の好ましい実施の形態は，本発明の譲受人（assignee) である株式会社リコーによって現在開発中のＲＥＳＴ（Rich Electronic Service Tool) オブジェクト指向アプリケーション・フレームワークの一部を示している。オブジェクト指向アプリケーション・フレームワーク（以下，『フレームワーク』と記載する）は，複数のクラスのオブジェクトのデクラレーション（宣言）およびインプリメンテーション（具体的記述）を含むクラス・ライブラリと，これらのクラスを用いてかかれたサンプル・アプリケーション・プログラムとから構成されている。

フレームワークは，アプリケーション・プログラマがいくつかのアプリケーション領域，例えば（本発明の場合には）リモート・サービス・アプリケーションにおいて新しいアプリケーション・プログラムを迅速，簡単に書けるようにするシステムである。特に，アプリケーション・プログラマは通常，新しいアプリケーション・プログラムをつくるために特定のリモート・マシーンのためにすでに書かれているサンプル・アプリケーション・プログラムの編集を行う。

本発明の好ましい実施の形態の一部であるフレームワークにおけるオブジェクト・クラスは，コンピュータ・システムのメモリ内部のソフトウェア・オブジェクトとして具体化された場合，それらを用いて実現されたどのアプリケーション・プログラムも，複数の異なったタイプの複数のリモート・マシーンと交信できるようにする１つのメカニズムとそれに関連した方法を構成している。

また，サンプル・アプリケーションは，それら自体が一定の組み合わせのタスク，例えば（本発明の場合には）リモート・サービス・タスクを実行するためのシステムを構成している。

また，本発明は，ファイル等のソフトウェア・エンティティと交信したり，その上でオペレーションを実行したりするアプリケーション，および同じコンピュータ・システム内にアプリケーション・プログラムとして入れられているプロセスをサポートするものである。

〔本発明で使用する用語の定義〕
以下，本発明で使用する用語の定義について説明する。
『コンポーネント』とは，あるリモート・マシーンのサービスおよび状態を示すソフトウェア・オブジェクトである。１つのコンポーネントは複数のサブ−コンポーネントを持っていても良く，例えば，コピー機はそれに取りつけられたソーターおよびフィーダーを持っていても良い。

『装置』（device) とは，その一部でリモート・サービス・アプリケーションが動作しているコンピュータ・システムが１つまたは複数のリモート・マシーンとの間で交信できるようにするためのコンピュータ・システムの周辺機器（peripheral) である。

『装置ドライバー』とは，リモート・サービス・アプリケーションが１つの装置と交信するためのインタフェースを提供するソフトウェアである。

『マシーン』とは，その内部でリモート・サービス・アプリケーションが動作しているコンピュータ・システムに対しては外部的なハードウェアまたはソフトウェア・エンティティである。例えば，リモート・オフィス・マシーン，ファイル・サーバーまたはデータベース・サーバーが挙げられる。

『マシーン・モデル』とは，『モデル・アイテム』オブジェクトを内容とする，あるコンポーネントによって提供されるサービスを記述するための集合（collection) オブジェクトである。

『モデル・アイテム』とは，あるリモート・マシーンによって提供される個別サービス・アイテムを記述するオブジェクトである。

『サービス』とは，そのコンポーネントに含まれるデータの検索，更新を含む，１つのコンポーネント上で，あるいはそれによって実行される全てのオペレーションである。

『サービス・アイテム』は，１つのサービスまたは一組のサービスあるいは１つのサービスに現在含まれているデータを記述する抽象的なクラスである。

『マシーン・ステート』とは，『アプリケーション・アイテム』オブジェクトをその内容とする集合（collection) オジェクトである。

『アプリケーション・オブジェクト』とは，そのマシーンにおけるサービスのカレント・ステート（データ）および，そのプログラムのエンド・ユーザーが要求し，まだ実行されていない変更あるいはオペレーションを含む，リモート・マシーンによって提供されるあるサービスに関してそのリモート・サービス・アプリケーションが有する情報を含むオブジェクトである。

〔命名上の規定〕
以下は，本明細書中および添付ソフトウェア付属資料で用いられている命名上の規定の要約である。クラスの名称は大文字で表記し，内側の大文字はワードの開始を示している。大域的機能，変数およびクラスの名称は，１つから３つの接頭辞を有しており，それらが属する全体的なファミリーを示している。

例えば，１つのサービス・アイテムを示すデータ構造と，その全てのサブクラスは“ＳＩ＿”という接頭辞を有している。

“Ｒ＿Ｂａｓｅ”から下のクラスは下線によって名称の他の部分から切り離された接頭辞を有しており，“Ｒ＿Ｂａｓｅ”は集合（collection) に入れられ，外部ファイルに書き込まれ，そしてそれらのファイルから読み出されるオブジェクトに関する基本クラスである。

その名称に下線が含まれていないクラスおよびデータ・タイプは，通常，変数，機能アーギュメントまたはクラス・データ・メンバーとしてのものであり，値によってパスされる。また，その名称が下線を含んでいる名称を含んだクラスは，ほとんど常に１つの塊として示され，基準あるいはポインタとしてパスされる。この規定によって，以下の説明で，オブジェクト指向プログラミングの当業者がクラスをインスタンスから簡単に区別し，また，インスタンスを基準やインスタンスに対するポインタから容易に区別することが可能になる。

また，大域機能，定数，および変数の名称は小文字の接頭辞を有している。
１つのクラスの公的インタフェースの一部であるメンバー機能およびデータ・メンバーは小文字から始まる。保護データ・メンバーは下線で終わる名称を有しており，通常は，そのデータにアクセスする公的メンバー機能が存在し，その名称は同じであるが，下線を有していない。すなわち，データ・メンバーは『属性』（attribute)と呼ばれ，その名称が“Ｒ＿ＡＴＴＲ”で始まるマクロを用いて宣言される。

１つの値を更新するメンバー機能がある場合，その名称は“Ｓｅｔ”でおわり，その更新機能はその属性を宣言する同じマクロで宣言される。

〔実施の形態〕
次に，本発明の好ましい実施の形態について，
１．システム概要
１．１．システム構成
１．２．フレームワークの説明
１．３．サンプル・アプリケーション・プログラムとファイルに関する説明
２．マシーン・モデル・モジュール
２．１．概要
２．２．コンポーネントおよび関連オブジェクト
２．２．１．合成データ
２．２．２．リモート・マシーン・ヒストリー
２．２．３．新しいモデル・アイテムの定義
２．２．４．初期化
２．３．典型的なクラス・デスクリプタ
２．３．１．Ｓｅｒｖｉｃｅクラス
２．３．２．ＳＩ＿ＳｅｒｖｉｃｅＩｔｅｍクラス
２．３．３．ＳＩ＿ＭｏｄｅｌＩｔｅｍクラス
２．３．４．ＳＩ＿ＲｅｍｏｔｅＩｔｅｍクラス
２．３．５．ＳＩ＿ＭｅｍｏｒｙＩｔｅｍクラス
２．３．６．ＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍクラス
３．通信モジュール
３．１．概要
３．２．詳細な説明
３．３．新しいセッション・タイプの定義
４．通信装置インタフェース
４．１．概要
４．２．詳細な説明
４．３．新しい装置の追加
５．追記
の順で，図面を参照して詳細に説明する。

１．システム概要
１．１．システム構成
図１は，本発明の好ましい実施の形態によるコンピュータ・システム１の構成図である。コンピュータ・システム１は，表示モニター１０，キーボード２０，マウス３０，およびコンピュータ２を含んでいる。

コンピュータ２は，プロセッサ４０，メモリ（例えば，半導体ＲＡＭ）５０，大容量記憶装置（例えば，ディスク・ドライブ）６０，通信装置（例えばモデム）７０，そして上記の構成部材を相互に接続するシステム・バス８０を含んでいる。なお，マウス３０はグラフィック的入力または出力装置の一例に過ぎない。リモート・マシーン９０は，通常，モデム等の通信装置７０経由でシステム１に結合されている。

好ましい実施の形態においては，システム１としては，ＬｉｎｕｘまたはＭｉｃｒｏｓｏｆｔ社からのＷｉｎｄｏｗｓ３．１で動作するマシーンに基づく８０４８６マイクロプロセッサ・クラスで，ＲＥＳＴアプリケーション・フレームワーク・プログラムを用いて開発されるリモート・サービス・アプリケーション・プログラムが現在リコー社で開発中である。ＲＥＳＴフレームワークにおけるオブジェクトのクラスの好ましい実施の形態は，以下に示されるようにＣ＋＋で書かれている。

なお，図１は，本発明を具体化するための１つのタイプのシステムを示している。多くのシステム・タイプおよび構成を本発明と結びつけて用いることができるのは，当業者には容易に分かる。

１．２．フレームワークの説明
図２は，本発明の好ましい実施の形態で用いられるオブジェクト指向アプリケーション・フレームワークの構成図である。アプリケーション層１４０は，エンド・ユーザーによって実行されるリモート・セット（Ｒｅｍｏｔｅ Ｓｅｔｔｉｎｇ）１００およびカスタマー・データベース・アクセス（Ｃｕｓｔｏｍｅｒ Ｄａｔａｂａｓｅ Ａｃｃｅｓｓ）１３０を含むアプリケーション・プログラムと，コール・アウト（Ｃａｌｌ−ｏｕｔ）１１０およびコール・イン（Ｃａｌｌ−ｉｎ）１２０等を含むオペレーティング・システムによって自動的に実行されるアプリケーション・プログラムによって構成されたシステムの一部である。

コア層１９０は，そのフレームワークのアプリケーション層１４０内にある全てのリモート・サービス・アプリケーションによって共有される機能を提供するクラス・デクラレーションおよびインプリメンテーションのライブラリで構成されており，グラフィック・ユーザー・インタフェース機能（ＧＵＩインタフェース機能）１５０，ジェネラル・プログラミング・システム機能１６０，マシーン・モデル・モジュール１７０，およびリモート・マシーンとの通信モジュール（通信機能）１８０とを含んでいる。

インタフェース層２６０は，モデム等の特定のローカル通信装置に対するインタフェースを提供するクラス（『装置ドライバー』），特定のファミリーのリモート・マシーン（例えば，コピー機２００およびファクシミリ装置２１０）と交信し，その上で作動するために必要な通信プロトコルに対するインタフェース，および，リモートまたはローカル・データベース・サーバー２２０，そして特定のタイプのリモート・マシーンによって提供されるサービスの記述を含んでいるファイル２３０，２４０，２５０（『マシーン記述ファイルおよびデータベース記述ファイル』）に対するインタフェースを提供するクラスを含んでいる。

このインタフェース層２６０におけるクラスのアプリケーション・プログラミング・インタフェース（ＡＰＩ）は，コア層１９０における抽象クラスによって定義されており，したがって，アプリケーション・プログラマは特殊なインタフェース装置およびリモート・マシーンの詳細を知らなくてもよいようになっている。

フレームワークを用いるアプリケーション・プログラマは，通常は，アプリケーション層１４０の１つまたは複数の既存サンプル・プログラムをコピーしたり修正したりするためのテキスト・エディタを用いることによってリモート・サービス・アプリケーション・プログラムを実行する。こうした方法で構成されたアプリケーションは，共通の十分に実証されたアーキテクチャおよびデザインと，大量の再使用可能コードを共有しており，ソフトウェア・ライフサイクルからデザインおよびデバッギング・フェーズのほとんどを取り除くことは，オブジェクト指向アプリケーション・フレームワークがリモート・サービス・アプリケーションの開発・実施（インプリメンテーション）をスピード・アップする１つの方法である。

リモート・マシーンと交信するために本発明を利用するプログラムはほとんどどんなリモート・マシーンとでも交信することができる。

１．３．サンプル・アプリケーション・プログラムとファイルに関する説明
図３は，上記フレームワーク（図２）のアプリケーション層１４０におけるサンプル・アプリケーション・プログラムの一部と，それらが情報を交信するために用いるファイルを示している。全てのアプリケーション・プログラムおよびファイルは，好ましくはコンピュータ・システム１の大容量記憶装置６０内に存在する。

ユーザーは，カスタマー・データベース・アクセス・アプリケーション３００，ジョブ・スケジューラ・アプリケーション３７０およびリモート・セッティング・アプリケーション４００と直接交信する（他の多くのインタラクティブ・プログラムが可能であることは当業者には明らかである。これらは単に説明のための例にすぎない）。

カスタマー・データベース・アクセス・アプリケーション３００を用いることによって，ユーザーは交信すべきマシーンを選択するためにカスタマー・データベース３１０を照会することができる。それはユーザーがマシーンのグループ（それぞれマシーン・グループ・ファイル３５０内に記述されている）およびサービス・アイテムのグループ（それぞれサービス・アイテム・グループ・ファイル３４０）を選択して，その上でオペレーションを行うことができる。

カスタマー・データベース・アクセス・アプリケーション３００は，それぞれ交信に関与する他のファイルのファイル名を含んだジョブ・アイテム・ファイル３２０およびケース・ファイル３３０を出力する。

次に，ユーザーは，１つまたは複数のリモート・マシーン９０と交信するために，ジョブ・アイテム・ファイル３２０を読み出して，コール・アウト・アプリケーション３８０およびリモート・セッティング・アプリケーション４００のインスタンスを自動的に実行させるジョブ・スケジューラ・アプリケーション３７０を実行させる。コール・イン・アプリケーション３９０はリモート・マシーン９０からの入力交信に応えていつでも実行することができる。

コール・イン・アプリケーション３９０とコール・アウト・アプリケーション３８０は，リモート・マシーン９０によってコール・イン・アプリケーションに送られるか，あるいはコール・アウト・アプリケーション３８０によってリモート・マシーン９０から検索されたコピーを含んでいるデータ・ダンプ・ファイル４１０を書き込む。データ・ダンプ・ファイル４１０はコール・トランスレータ・アプリケーション４４０によって，ケース・ファイル４２０かコンマ・デリミテッド・ファイル４５０のいずれかに翻訳されて，アナリシス・データベース４６０またはスプレッドシート等の他のアプリケーション・プログラムにインポートされる。コール・トランスレータ・アプリケーション４４０は，複数のマシーン・モデル・ファイル４３０の１つに含まれているリモート・マシーン９０の記述を用いてそのコンバージョン動作を行う。

リモート・セッティング・アプリケーション４００はユーザーとあるリモート・マシーン９０との間の直接のインタラクション（交信またはデータのやり取り）のために用いられ，そのリモート・マシーン９０で実行できるオペレーションは複数のマシーン・モデル・ファイル３５０ａの１つに記述され，リモート・マシーン９０とその上で実行されるオペレーションの一部のアクセス情報（例えば電話番号）をケース・ファイル３３０内で指定したり，ユーザーが直接入力したりすることができる。

２．マシーン・モデル・モジュール
２．１ 概要
図２のマシーン・モデル・モジュール１７０は，コア層１９０内の主要モジュールである。マシーン・モデル・モジュールの目的は，マシーン・モデルと呼ばれるオブジェクトの構成の形態でリモート・サービス・アプリケーションがリモート・マシーン上で使えるサービスを記述すること，そして，アプリケーション・プログラムがそのリモート・マシーンおよび全てのオペレーション，そしてユーザーによって要求されたデータ伝送の現在の状態を追跡的に監視するために必要な情報を含み，組織することである。

本発明の好ましい実施の形態においては，このマシーンおよびサービス・クラス階層は以下に示すものから成る。ここで，インデントは，上のものに対する従属を示す。
Ｃｏｍｐｏｎｅｎｔ リモート・マシーンを記述
Ｓｅｒｖｉｃｅ
ＳｅｒｉｖｃｅＣｏｌｌｅｃｔｉｏｎ サービス・アイテムの集合
ＳＣ＿ＳｅｒｉｃｅＭｏｄｅｌ コンポーネントのモデル
ＡＣ＿ＡｐｐＳｅｒｖｉｃｅｓ コンポーネントのアプリケーション・アイテム
ＳＣ＿Ｑｕｅｕｅ ＳＣ＿ＱｕｅｕｅＩｔｅｍの集合
（および他の種々の特殊な目的の集合）
ＳＩ＿ＳｅｒｖｉｃｅＩｔｅｍ リモート・サービスを記述
ＳＩ＿ＭｏｄｅｌＩｔｅｍ マシーン・モデル−−−記述のみ
ＳＩ＿ＧｕｉＩｔｅｍ １つのアイテムを示すＧＵＩ要素
ＳＩ＿ＡｐｐＩｔｅｍ １つのアイテムに関するアプリケーション・ステート
ＳＩ＿ＱｕｅｕｅＩｔｅｍ １つのアイテムに関するキューされた読み出しおよび書き込み

２．２．コンポーネントおよび関連オブジェクト
図４は，典型的なＣｏｍｐｏｎｅｎｔ７００（コンピュータ・システム１のメモリ５０内のリモート・マシーン９０を示すオブジェクト・インスタンス），およびそれが参照するオブジェクトを示している。これらのオブジェクトには，図示の如く，その『状態』属性６００であるＳＣ＿ＡｐｐＳｅｒｖｉｃｅｓオブジェクト，その『モデル』属性６３０であるＳＣ＿ＳｅｒｖｉｃｅＭｏｄｅｌオブジェクト，そのＷｒｉｔｅＱｕｅｕｅおよびｒｅａｄＱｕｅｕｅ属性６７０である各ＳＣ＿Ｑｕｅｕｅオブジェクト，およびその『セッション』属性７１０であるクラスＳＩ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｓｓｉｏｎのサブクラスのインスタンスに対するリファレンスがある。

ＳＣ＿ＳｅｒｖｉｃｅＭｏｄｅｌ６３０は，『モデル・アイテム』６４０，６５０の集合（collection) であり，各モデル・アイテムはＳＩ＿ＭｏｄｅｌＩｔｅｍのサブクラスのインスタンスである。その集合であるＳＣ＿ＳｅｒｖｉｃｅＭｏｄｅｌ６３０は，Ｃｏｍｐｏｎｅｎｔ７００によって示されるリモート・マシーン９０によって提供されるサービスの記述である。

ＳＣ＿ＡｐｐＳｅｒｖｉｃ ｅｓ６００は，『アプリケーション・アイテム』６１０，６２０の集合（collection) であり，各アプリケーション・アイテムはＳＩ＿ＡｐｐＩｔｅｍクラスの１つのインスタンスであり，ＳＩ＿ＭｏｄｅｌＩｔｅｍ６４０，６５０およびＳＩ＿ＣａｌｌｂａｃｋＬｉｓｔ５２０，５３０に対するリファレンスを持っている。各アプリケーション・アイテム６１０，６２０はそのリモート・マシーンにおける対応するサービスの現在値（分かれば），および全ての要求されたオペレーションまたはそのサービスに関連するデータ伝送に関する情報を含んでいる。

ＳＣ＿ＡｐｐＳｅｒｖｉｃｅｓオブジェクト６００は，クラスＣｏｍｐｏｎｅｎｔ７００上での“ｉｎｉｔＳｅｒｖｉｃｅｓ”オペレーションによってイニシャライズされ，そのパラメータの１つは，１つのアプリケーションがマシーン・モデル６３０からそのアプリケーションによって実際に使われるサービスだけを選択できるようにするブール（Ｂｏｏｌｅａｎ：論理演算）に対するｐｏｉｎｔｅｒ−ｔｏ−ＳＩ＿ＭｏｄｅｌＩｔｅｍからの機能に対するオプショナル・ポインタである。

ＳＩ＿ＣａｌｌｂａｃｋＬｉｓｔ５２０，５３０は，ＳＩ＿ＧｕｉＩｔｅｍオブジェクト５４０，５５０，５７０，５８０，５９０の集合（collection) であり，そのそれぞれが情報を表現するグラフィック・ユーザー・インタフェース５００における『コントロール』を示し，ユーザーが交信する単一のオブジェクト（ＧＵＩ５００のＧＵＩオブジェクト５１０）を参照したり，それに参照されたりする。ＳＩ＿ＧｕｉＩｔｅｍの目的はグラフィカル・ユーザー・インタフェースを用いているユーザーによって行われた変更がアプリケーション・ステート６００の適切なＳＩ＿ＡｐｐＩｔｅｍ６１０，６２０内で同等の変化を確実に行わせるようにすること，さらに，そのプログラムのオペレーションから，特にそのリモート・マシーンとの交信から生じるアプリケーション・ステート６００内のＳＩ＿ＡｐｐＩｔｅｍ６１０，６２０内の変化がグラフィカル・ユーザー・インタフェースによってユーザーに示される情報内に同等の変化を起こさせるようにすることである。

クラスＳＩ＿ＡｐｐＩｔｅｍのオペレーション“ｎｅｗＶａｌｕｅＳｅｔ”は，そのサービス内の状態の変化（書き込み動作）を要求するために用いられる。クラスＳＩ＿ＡｐｐＩｔｅｍのオペレーション“ｒｅａｄＲｅｑｕｅｓｔ”は読み込み動作を要求するために用いられる。読み込みまたは書き込み動作が要求される場合，ＳＩ＿ＡｐｐＩｔｅｍ６１０，６２０を参照し，要求された動作，読み込み・書き込み，および書き込みの場合はその書き込まれるべきデータを含んだクラスＳＩ＿ＱｕｅｕｅＩｔｅｍのオブジェクト６８０，６９０が構成される。ＳＩ＿ＱｕｅｕｅＩｔｅｍは読み出しキュー６７０，またはＣｏｍｐｏｎｅｎｔ７００に付加されている書き込みキューのいずれかに配置される。これらのキュー・アイテムは，以下にさらに通信モジュールとの関連で説明されるように，リモート・マシーンとのバッチ通信セッションをユーザーまたはアプリケーションが要求するまで蓄積される。

バッチ通信セッションが行われる場合，各ＳＩ＿ＡｐｐＩｔｅｍのＣｕｒｒｅｎｔＶａｌｕｅ属性は，そのリモート・マシーン内に保存されたり，あるいはそこから検索される値を反映するように更新される。また，ＳＩ＿ＡｐｐＩｔｅｍ６１０，６２０と関連した各ＳＩ＿ＧｕｉＩｔｅｍ５００は，“ｃｕｒｒｅｎｔＶａｌｕｅＳｅｔ”オペレーションの副次的作用としてその更新が自動的に通知される。

コンポーネント・オブジェクトは，それ自体，リモート・マシーンに接続された個別的に制御されるマシーンに対応した『サブ−コンポーネント』（図示せず）のためのコンテナーである。例えば，トップ−レベル・コンポーネント・オブジェクト（Ｃｏｍｐｏｎｅｎｔ７００）は，それに複数のコピー機が取りつけられる，トップ−レベル・コンポーネント（Ｃｏｍｐｏｎｅｎｔ７００）の内容によって示されるライン−アダプタ・マルチプレクサであって良い。

図５は，マシーン・モデル８６０（図４の６３０），アプリケーション・ステート８１０（図４で６００），そして，リモート・マシーン９０との間の関係を示している。これを説明するために，その内部でリモートからアクセスできるサービスが電子的に消去可能な読み取り専用メモリ９１０内に含まれたデータによって示され，それから，データを検索したり，あるいはその内部でファクシミリ装置９０にスターティング・アドレスおよびサイズを含んだ適切にフォーマット化されたリクエスを提示することによって修正することができるリコー・モデルＦＡＸ−６０と類似したファクシミリ装置を用いる。なお，転送されるデータを確認するための異なった方法およびデータをコード化する異なった方法を伴う他のプロトコルを用いることが可能であることは，当業者には明らかである。

リモート・ファクシミリ装置はメモリにサービス・アイテムを保存するので，マシン・モデル８６０はＳＩ＿ＳｅｒｖｉｃｅＩｔｅｍのサブクラスであるＳＩ＿ＲｅｍｏｔｅＩｔｅｍのサブクラスであるクラスＳＩ＿ＭｅｍｏｒｙＩｔｅｍのインスタンスであるオブジェクト８７０，８８０を含んでいる。例えば，ＳＩ＿ＭｅｍｏｒｙＩｔｅｍ８７０は長さ３のストリングを指定するその“ｉｔｅｍＳｉｚｅ”属性内にサイズ３を有している。ＳＩ＿ＭｅｍｏｒｙＩｔｅｍ８７０内のデータ・タイプ“Ｃｈａｒｓ”は，クラスＲ＿ＶａｌｕｅＤｓｃｒのサブクラスのインスタンスに対するポインタによって“ＶａｌｕｅＤｓｃｒ”属性内に示される。

リモートでアクセスできるデータの一部はそのメモリのバイト内に保存されているビットフィールドで構成されており，図５はリモート・ファクシミリ装置９０のメモリ９１０のバイト９２０内に含まれた２つのそうしたビットフィールド９２１，９２２を示しており，それぞれ，いずれもバイト９２０を示すＳＩ＿ＭｅｍｏｒｙＩｔｅｍオブジェクト８８０内に含まれるクラスＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍのインスタンス８９０，９００によって示されている。

リモート・サービス・アプリケーション・プログラムによって操作できる各サービス・アイテムは，クラスＳＩ＿ＡｐｐＩｔｅｍのインスタンス８２０，８３０によって示されるアプリケーション・ステート８１０内にカレント・ステートを有している。

本発明の好ましい実施の形態においては，マシーン・モデルは，ＳＩ＿ＭｏｄｅｌＩｔｅｍのサブクラスのインスタンスで構成されており，以下の階層を有している。ここで，インデントは，上のものへ対する従属を示している。
ＳＩ＿ＭｏｄｅｌＩｔｅｍ マシーン・モデル−−−記述のみ
ＳＩ＿ＩｎｔｅｒｎａｌＩｔｅｍ アプリケーションに対して内部的
ＳＩ＿ＥｘｔｅｒｎａｌＩｔｅｍ 外部記憶またはサーバー
ＳＩ＿ＤＩｒｅｃｔｏｒｙＩｔｅｍ ディレクトリ
ＳＩ＿ＦｉｌｅＩｔｅｍ ファイル
ＳＩ＿ＴａｂｌｅＩｔｅｍ データベース・テーブル
ＳＩ＿ＱｕｅｒｙＩｔｅｍ データベース照会
ＳＩ＿ＴｕｐｌｅＩｔｅｍ データベース・タップル
ＳＩ＿ＦｉｅｌｄＩｔｅｍ データベース・フィールド
ＳＩ＿ＲｅｍｏｔｅＩｔｅｍ リモート・マシーン
ＳＩ＿ＭｅｍｏｒｙＩｔｅｍ リモート・メモリに保存
ＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍ ワード内のビットフィールド
ＳＩ＿ＰｒｏｇｒａｍＩｔｅｍ リモート・プログラムによりアクセス

抽象クラスＳＩ＿ＭｏｄｅｌＩｔｅｍは，リモート・マシーン内に配置されているサービス・アイテムに対するアクセスおよび交信動作を実行するための抽象的なプログラニング・インタフェースを提供し，ＳＩ＿ＭｏｄｅｌＩｔｅｍの種々のサブクラスは，特定のマシーンに対する通信プロトコルを用いた特殊なタイプのリモート・データを処理するためのこれらのオペレーションのインプリメンテーションを可能にするものである。

サブクラス化することで，ＳＩ＿ＭｅｍｏｒｙＩｔｅｍオブジェクト８７０，８８０は，１つのリモート・マシーンのメモリに保存されているリモート・サービス・アイテムに対してそれぞれ個別的に振る舞うことができるようになり，ＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍオブジェクト８９０，９００は，リモート・マシーン・メモリ内に記憶されているワードに含まれているビットフィールドに対して個別的に振る舞うことができるようになる。例えば，“ｐａｃｋｅｄＳｉｚｅ”属性は，ＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍ内では単に“ｉｔｅｍＳｉｚｅ”属性の値をリターンし，ＳＩ＿ＭｅｍｏｒｙＩｔｅｍでは，バイト内のビットの数である８を掛けた“ｉｔｅｍＳｉｚｅ”属性の値をリターンする機能で計算される。

ＳＩ＿ＩｎｔｅｒｎａｌＩｔｅｍおよびＳＩ＿ＥｘｔｅｒｎａｌＩｔｅｍは，ＳＩ＿ＭｏｄｅｌＩｔｅｍの二つの主要なサブクラスである。ＳＩ＿ＩｎｔｅｒｎａｌＩｔｅｍオブジェクトは，そのリモート・マシーンに関連し，上記リモート・マシーン・アプリケーション（例えば，リモートではアクセスできないが，カスタマー・データベースから獲得することができるそのマシーンのシリアル番号）に対しては内部的なデータを記述する。データがそのリモート・マシーン・アプリケーションに対して外部的な場合は，ＳＩ＿ＥｘｔｅｒｎａｌＩｔｅｍサブクラスのサブクラスが用いられる。例えば，ＳＩ＿ＴａｂｌｅＩｔｅｍはリモート・データベース・テーブルにおけるテーブルを記述し，ＳＩ＿ＭｅｍｏｒｙＩｔｅｍはリモート・ファクシミリ装置のメモリにおけるデータ・アイテムを記述する。

データ自体，つまり，データ・タイプ（整数，基数，フロート，ストリング等），サイズ，数値の範囲およびその他の属性が，『バリュー・デスクリプタ』（クラスＶａｌｕｅＤｓｃｒ）と呼ばれるデータ・ストラクチャ内に記述される。これらの数値デスクリプタはＳｍａｌｌｔａｌｋ等の言語で用いられるものと同様のランタイム・クラス・デスクリプタである。数値デスクリプタに対するポインタとそのデータの初期値はＳＩ＿ＭｏｄｅｌＩｔｅｍオブジェクトの“ｄｅｆａｕｌｔＶａｌｕｅ”属性であるクラスＲｖａｌｕｅのオブジェクト内で結合されている。数値デスクリプタの一部の属性はＳＩ＿ＭｏｄｅｌＩｔｅｍの対応する属性によってオーバーライドされる場合もある。１つの値があるオブジェクトのインスタンスに対する基準である場合，そのクラス名および公的にアクセス可能な属性は上記オブジェクトのインスタンスの仮想機能“ｄｓｃｒ”によってリターンされるクラスＲ＿ＣｌａｓｓＤｓｃｒのインスタンスによって記述される。

アプリケーション・ステート８１０内の各ＳＩ＿ＡｐｐＩｔｅｍオブジェクト８２０，８３０，８４０，８５０は，リモート・マシーンのカレント・ステート，ユーザー・インタフェースの状態，そしてそれらの間の関係に関してリモート・サービス・アプリケーションが持っている情報を記憶する。

クラスＳＩ＿ＡｐｐＩｔｅｍ８２０，８３０，８４０，８５０の各インスタンスは，そのアイテムの許可可能状態，およびその位置またはそのリモート・マシーンに対するアクセス情報について記述するクラスＳＩ＿ＭｏｄｅｌＩｔｅｍ８７０，８８９，８９０，９００の１つのインスタンスに対するレファレンス（参照情報）を含んだ属性『モデル』を有している。

また，各ＳＩ＿ＡｐｐＩｔｅｍは，そのリモート・マシーンにおけるそのサービス・アイテムのカレント・ステートに関する情報を含んだ属性“ｃｕｒｒｅｎｔＶａｌｕｅ”と，そのリモートの要求された更新状態を示す属性“ｎｅｗＶａｌｕｅ”も有している。

２．２．１．合成データ
リモート・マシーン内の１つのサービス・アイテムが配列や構成等合成データ・ストラクチャでできている場合，それはその『子：チルドレン』としても知られている１つまたは複数の従属ＳＩ＿ＭｏｄｅｌＩｔｅｍオブジェクトの集合（collection) を有するＳＩ＿ＭｏｄｅｌＩｔｅｍによって記述される。１つの配列を示すＳＩ＿ＭｏｄｅｌＩｔｅｍオブジェクトは，アレイ・アイテム・オブジェクトを記述する１つの子（チャイルド）を有しており，１つのストラクチャを示すＳＩ＿ＭｏｄｅｌＩｔｅｍは，各フィールドを記述する別の子（チャイルド）を有している。

対応するＳＩ＿ＡｐｐＩｔｅｍは，各サブ−アイテム（ストラクチャ・フィールドの配列要素）のためのチャイルドＳＩ＿ＡｐｐＩｔｅｍか，あるいはサブ−アイテム値の配列に対する単一合成値のいずれかを有している場合もある。１つの配列要素を示す各ＳＩ＿ＡｐｐｌＩｔｅｍはその『位置』（“ｌｏｃａｔｉｏｎ”）属性に，その配列の冒頭からの指数（“ｉｎｄｅｘ”）である値を持っている。

アプリケーション・プログラマは，与えられたいずれかのアプリケーションに対してこれら二つの表現のうちのどれが最も適切かについて判断する。例えば，図５で，ＳＩ＿ＡｐｐＩｔｅｍオブジェクト８３０とＳＩ＿ＭｅｍｏｒｙＩｔｅｍによって記述されるリモート・データ・アイテムは，ＳＩ＿ＡｐｐＩｔｅｍオブジェクト８４０，８５０とＳＩ＿Ｂｉｔｆｉｅｌｄオブジェクト８９０および９００によって記述されるビットフィールドを含んでいる。

２．２．２．リモート・マシーン・ヒストリー
オプションとして，１つのリモート・マシーンの経時データ（ヒストリー）は，経時データベース（図示せず）に格納するようにしても良い。経時データのタイプは，例えば，毎月コピー機で作成されるコピーの枚数，顧客が購入するオプション等を含んでいる。経時データを追跡確認するために，ＳＩ＿ＡｐｐＩｔｅｍは異なったコンポーネントの別のＳＩ＿ＡｐｐＩｔｅｍを指示する属性“ｈｉｓｔｏｒｙ”を有している。この異なったコンポーネントとは，通常，データベースやファイルを記述するものである。

経時データ・アイテムの“ｃｕｒｒｅｎｔＶａｌｕｅ”は，アプリケーションが開始された場合（例えば，請求アプリケーションにおける前月のコピー・カウント等），そのアイテムについて知られていることを反映している。システムがそのアイテムに関して知っていることに変化が生じた場合，“ｃｕｒｒｅｎｔＶａｌｕｅＳｅｔ”が呼び出されてその変化を反映させ，そしてその経時データ・アイテムの“ｎｅｗＶａｌｕｅＳｅｔ”オペレーションが同じ値で呼び出される。いくつかのアプリケーション（例えば，リモート・セットアップ）では，１つのサービス・アイテムの値を，そのアプリケーションのユーザーによって行われた可能性のある全ての変更を無効にするように，プログラムが開始された場合に有していた値に戻すことができると非常に有益であることがある。

２．２．３．新しいモデル・アイテムの定義
上の説明で分かるように，アプリケーション・プログラマは，いずれのかの新しいリモート・マシーン，データベース，または他の外部リソースによって提供される新しい種類のサービス・アイテムを記述するために，クラスＳＩ＿ＭｏｄｅｌＩｔｅｍに対する新しいサブクラスを簡単に定義することができる。

こうしたサブクラスのためのコードを含んだライブラリにリンクされた全てのアプリケーションは，作動中，その新しいサービス・アイテムを用いることができ，そうしたアプリケーションをリコンパイルする必要はなく，再リンクすれば良いだけである。ダイナミック・リンク・ライブラリ（ＤＬＬ）に新しいクラスを入れることによって，適切に構成されたアプリケーションは，リンクされてユーザーに配分された後でも新しいサービス・アイテムを利用することができる。

２．２．４．初期化
アプリケーション・プログラムがあるリモート・マシーンと通信するためには，そのメモリ内にコンポーネントとその関連マシーン・モデルおよびアプリケーション・ステートとを有していなければならないことは，当業者にはすぐ分かる。

本発明の好ましい実施の形態においては，これはそれらのクラスの名称，その属性の名称と値，そして各集合オブジェクトに含まれるオブジェクトのテキストによる表現または二進値による表現を含む，構成されるオブジェクト・インスタンスのテキストまたは二進値による表現を含んだ１つまたは複数のファイルを文法的に解析することによって行うことができる。

そのファイル内に示される種々のクラスに関するコンストラクタを用いて，パース・ツリーがつくられ，そのルートは必要なコンポーネント・オブジェクト・インスタンス７００，８００であり，その“ｍｏｄｅｌ”属性はマシーン・モデル６３０，８６０を含んでおり，その“ｓｔａｔｅ”属性はアプリケーション・ステート６００，８１０を含んでいる。アプリケーション・ステートは個別ケース・ファイル３３０，４２０を文法的に解析することによって構成しても良く，マシーン・モデル・ファイル３５０，４３０からの初期値を用いて構成し，初期化してもよい。

１つの例として，アプリケーション・プログラムがファクシミリ装置と交信する必要が生じた場合，そのアプリケーション・プログラムは最初にそのファクシミリ装置を記述したマシーン・モデル・ファイルを検索する。そうしたファイルは，例えば，以下に示すように記述される（一部）。ただし，明細書における文字標記の制限から，制限のある文字を代用文字（以下に＄で記載する文字）に代えて記述する。

SC＿ServiceModel: (＄
name=k50
＄
SI＿MemoryItem: (＄
name=R17D4
defaultValue=BCD1:51
description=‘drmk50.dat#R17D4'
itemValueList=〔〕
features=S＿FeatureSet: (SYSTEM RemoteSetting)
readOnly=-
msbFirst=+
isremote=+
bitOffset=0
offset=6100
label=‘NCU 13'
＄)
SI＿MemoryItem: (＄
name=R17D5
defaultValue=BCD1:256
description = ‘drmk50.dat#R17D5'
itemValueList=〔〕
features= S＿FeatureSet: (SYSTEM
RemoteSetting)
readOnly=-
msbFirst=+
isremote=+
bitOffset=0
offset=6101
label=‘NCU 14'
＄)
SI＿MemoryItem: (＄
name=R17D6
defaultValue=BCD1:256
description=‘drmk50.dat#R17D6'
itemValueList=〔〕
features=S＿FeatureSet:
SYSTEM
RemoteSetting)
readOnly=-
msbFirst=+
isremote=+
bitOffset=0
offset=6102
label=‘NCU 15'
・・・

上に示したように，記述ファイルは“Ｋ５０”ファクシミリ装置に関するＳＣ＿ＳｅｒｖｉｃｅＭｏｄｅｌ（モデル）のテキストによる表現を含んでいる。ＳＩ＿ＭｅｍｏｒｙＩｔｅｍのインスタンスはＲ１７Ｄ４，Ｒ１７Ｄ６およびＲ１７Ｄ６を含んで記述されている。適切なインスタンスの内部の仮想機能は特定の通信プロトコルによって処理するために実行される。

別の例として，アプリケーション・プログラムはコピー機と交信することが必要な場合，アプリケーション・プログラムは先ずそのコピー機を記述するファイルを検索する。この場合，例えば，表２に示すように記述される（一部）。

SC＿ServiceModel: (＄
name=FT8780
＄
SI＿CopierItem: (＄
name=LampThermistor
writeDCode= ‘1302'
features=S＿FeatureSet: (
ReadOnly
RemoteSetting)
msbFirst=-
writeInfcode= ‘16040070101'
isremote=+
offset=0
label=LampThermistor
separator=‘;'
IDCode= 〔〕
defaultValue=Nchars2:"00"
size＿for ＿specify ＿data＿length=2
description=〔〕
readOnly=-
bitOffset=0
readInfCode=‘16040070101'
size=2
readDcode=‘1302;'
＄)
SI＿CopierItem: (＄
name= SC＿ChargerLeak
writeDCode= ‘1302;'
features=S＿FeatureSet: (
RemoteSetting
ScCall
msbFirst=-
writeInCode=‘32000930201'
isremote=+
offset=0
label=SC＿ChargerLeak
separator=‘;'
IDCode= 〔〕
defaultValue=Nchars1＿1:"0"
size＿for ＿specify ＿data＿length=2
description=〔〕
readOnly=-
bitOffset=0
readInfCode=‘32000930201'
size=1
readDCode=‘1302;'
＄)
SI＿CopierItem: (＄
name=FusingTempADJ
writeDCode= ‘1304'
features=S＿FeatureSet: (
ReadWrite
RemoteSetting)
msbFirst=-
writeInfCode= ‘51011050101'
isremote=+
offset=0
label=FusingTempADJ
separator=‘;'
IDCode= 〔〕
defaultValue=Nchars3s ＿16:"+00"
size＿for ＿specify ＿data＿length=2
description=〔〕
readOnly=-
bitOffset=0
readInfCode=‘51011050101'
size=1
readDCode=‘1302;'
＄)
・・・

上に示した通り，記述ファイルは“ＦＴ８７８０”コピー機に関するＳＣ＿ＳｅｒｖｉｃｅＭｏｄｅｌ（モデル）のテキストによる表現を含んでいる。ＳＩ＿ＣｏｐｉｅｒＩｔｅｍのインスタンスは，ＬａｍｐＴｈｅｒｍｉｔｏｒ，ＳＣ＿ＣｈａｒｇｅｒＬｅａｋおよびＦｕｓｉｎｇＴｅｍｐＡＤＪを含んで記述されている。

１つのアプリケーションは複数のコンポーネント・オブジェクト７００，８００および関連するモデル６３０，８６０，およびアプリケーション・ステート６００，８１０を段階的，あるいは同時並行的にそのメモリ内につくることによって複数のリモート・マシーンと交信することができる。

２．３．典型的なクラス・デスクリプタ
以下のＣ＋＋コードは，マシーン・モデル・クラスの好ましい実施の形態の説明的なサブセットに関するクラス・デクラレーションによって構成されている。

２．３．１．Ｓｅｒｖｉｃｅクラス
サービス・クラスは，サービス・アイテムおよびサービス集合（collection) に関する一般的で抽象的なベース・クラスである。

class Service: public R＿Nameable｛
Description ：
R＿ABSTRACT(Service, R Nameable);
public:
Pseudo-Attributes:
R＿FUNC＿RX(Service *, parent);
R＿CONTAINER ＿IS(parent);
ツリーにおけるこのサービスのペアレント。このサービスがサービス・ツリーのルートにある場合（つまり，そのペアレントはコンポーネント）。"parent"はそのサービスがつくられた場合にセットされるか，あるいはチャイルドがそれに付加された場合に，ペアレント自身によってセットされる。
R＿FUNC＿RO＿RC(R＿Collection, children);
R＿CONTENTS＿IS(children);
このサービスのチルドレンを保有するための集合。１つの場所で初期化，消去できるようにするために，ここに置かれる。この下側はスペシャライズするためにサブクラス内で行われるダウンキャスティングが行われねばならないことを示している。
virtual void setValueAt(Rcad i,Rvalue const &nv);
virtual void setValueOf(RKey const&Key, Rvalue const&nv);
virtual void append(Rvalue const&nv);
parentSet を呼び出すことができるように，チルドレンを付加するオペレーションをオーバーライドする。
virtual Service *getChildByName(R＿Symbol *nm)
サービス名が与えられたら，それに一致するチャイルドを見つける。ファスト・ルックアップを行うことができるサブクラス内にオーバーライドしなければならない。 virtual Component *component ( ) const;
コンポーネントがあった場合，このサービスが付加される。この内容のデクラレーションはそれが大文字でタイプされるまで（strongly typed) 遅らされる。これは，"S＿TYPED ＿CHILDREN(child＿type, collection＿type )"によって行われる。
#define S＿TYPED ＿CHILDREN(childType, collectionType) ＼
R＿CONTENTS＿INIT＿NEW(collectionType, children);＼
R＿CHILDREN＿ARE ＿TYPED(childType,collectionType, parentSet)

constructors:
Service (R＿Symbol &nm, Service *prnt = 0);
規則上，全てのServiceItem コンストラクタはその最初のアーギュメントとしての名称に関するレファレンスとその最後のアーギュメントしてのペアレントに対するポインタを含んでいる。

usage:
"parent ・ append (new Service(name, &parent))"
Service (R＿Base const &o);
そのコピー・インストラクタを用いてサービスを構成する場合，通常ボトム・アップでツリーを構成するので，ペアレントは分からない。parentSet で行うアペンドにアサインされねばならない。

Descructor:
〜Service( );
代表された集合オペレーション：一つのサービスをペアレント・サービスに対して付加するオペレーションは，必要な場合，そのチャイルドの"parent"フィールドをセットしなければならない。

２．３．２．ＳＩ＿ＳｅｒｖｉｃｅＩｔｅｍクラス
ＳＩ＿ＳｅｒｖｉｃｅＩｔｅｍクラスは，全てのサービス・アイテムに対して同じインタフェースを提供する。

class SI＿ServiceItem: public Service ｛
public:
S＿TYPED ＿CHILDREN (SI＿ServiceItem,
RT＿Table ＜SI＿ServiceItem ＞);
このサービス・アイテムに関する情報をリターンする。この情報はそのアプリケーション（特徴）およびユーザー（ラベル，記述）に対するこのサービス・アイテムを記述するために用いられる。
R＿ATTR＿XX＿RC(R＿String, label);
ユーザーに対する表現のために表示し，
このServiceItem をラベルするために用いられるストリング。これはデフォールト名で，アプリケーションに特有の名称変更や言語上の翻訳から，その名称と違っている場合もある。
R＿FUNC＿GET (R＿String *， description) ；
このサービスが何をするのかについての簡単な説明をするストリング。一般的に，この説明は，それが必要とされる前にそのアプリケーションのワーキング・メモリに保存されるのではなく，データベースまたはファイルでルック・アップされる。
R＿FUNC＿GET (S＿featureSet *, features);
このサービスに関する一定のシンボリックな特徴をリターンする。
R＿FUNC＿GET(Rcard,offset);
そのペアレントに対する本アイテムのアドレスを（バイトで）リターンする。
R＿FUNC＿GET(Rcard,bitoffset);
それを含んでいるアイテムがある場合，その低オーダー・ビットに対する本アイテムのビットによるオフセットをリターンする。
R＿FUNC＿GET(Rcard, index);
ペアレントが同じアイテムの列である場合，そのペアレ ントにおけるこのアイテムのインデックス。さもなけれ ばゼロ。
R＿FUNC＿GET(Rcard, address);
通常それを含んでいるメモリ，ファイル等のスタートに関連したアイテムの絶対アドレス（バイト）。オフセット，インデックス，およびサイズから計算される。

Value Description Information ：
以下の機能は，通常，デスクリプタ，特に，default-
Value の値デスクリプタによって代表される。サイズや valueList 等の少数の機能が，SI＿ModelItem の属性に よってオーバーライドされることができる。
R＿FUNC＿GET(Rvalue, defaultValue);
そのアイテムのデフォールト値。このデフォールト値の R＿ValueDscr はこのアイテムの全てのインスタンスに対して用いられるデスクリプタである。
R＿FUNC＿GET (R＿ValueDscr & ，defaultDscr);
デフォールト値デスクリプタ。"defaultValue ( )・dscr( )," と同じでなければならないが，効率のため（つまり，ユーザーがいくつかのレベルの間接的な方法で値全体をワインド・アップ・パシングしないようにするために），遅らされる。
R＿FUNC＿GET (Rcard, minSize);
R＿FUNC＿GET (Rcard, maxSize);
１つのアイテムの値をホールドするのに必要な，即ち，そのアイテムをリモート・マシーンのメモリに保存し，それをマシーンに送り，あるいはデータベース内に保存するために必要な最低および最大バイト数。
Rinvalidindex のmaxSize はそのサイズに関して上限のない可変長オブジェクトを示している。
R＿FUNC＿GET (Rcard，packedSize);
その値のホールドするのに必要なビット数。
R＿FUNC＿GET (Rcard, minWidth);
R＿FUNC＿GET (Rcard, maxWidth);
R＿FUNC＿GET (Rcard, minHeight);
R＿FUNC＿GET (Rcard, maxHeight);
プリントまたはディスプレイのために１つの値をストリングとして表現するのに必要な最小，および最大文字およびライン数。
R＿FUNC＿GET (Rvalue, minValue);
R＿FUNC＿GET (Rvalue, maxValue);
そのアイテムの最小および最大値。ストリング値化されたアイテムのRnullValueをリターン。
R＿FUNC＿GET (Rvalue, unit);
R＿FUNC＿GET (Rvalue, scaleFactor);
アイテム値の後に表示されるべき単位およびスケール・ファクタ。例えば，電圧の単位とそのスケール・ファクタはキロボルトで表された値の場合，Ｖと１０００である。
R＿FUNC＿GET (R＿Base *, valueList)
少数の名称のついた値をもったアイテムに対して用い得る値。数値でインデックスされ，符号名でキー入力された集合（collection) でなければならない。
R＿FUNC＿GET (Rbool, msbFirst);
バイト・オーダーリング
R＿FUNC＿GET (Rbool, readOnly);
そのリモート・マシーン上でアイテムが修正できない場合だけ有効。

２．３．３．ＳＩ＿ＭｏｄｅｌＩｔｅｍクラス
ＭｏｄｅｌＩｔｅｍは，マシーンの記述の一部，つまり，そのプログラム上でのマシーンのモデルである。これはそのマシーンのカレント・ステートに関する情報は含んでおらず，どのようにしてステートを得られるか，そしでどんな値が使えるかについての情報を含んでいるだけである。基本的に，ＭｏｄｅｌＩｔｅｍはリモート・マシーンを呼び出したり，データベースを調べたりせずに，予め１つのアイテムについて知り得る全ての情報を含んでいる。

Class SI＿ModelItem: public SI＿ServiceItem ｛
R＿ABSTRACT (SI＿ModelItem ，SI＿ServiceItem);
public:
R＿String *descriptionInit( );
記述をイニシャライズする。
R＿ATTR＿RW＿RC(S＿FeatureSet, features);
このアイテムの特徴
R＿ATTR＿R0 (Rcard,offset);
通常それを含んでいるマシーン・メモリ，ファイル，またはプロトコル・バッファのスタートに対するこのアイテムのアドレス
R＿ATTR＿R0 (Rcard, bitOffset);
それを含んでいるアイテムがあった場合，その低オーダー・ビットに対するこのアイテムのビット数でのオフセット

Value Description Information ：
ほとんどのデクスクリプタ属性は，１つまたはそれ以上のレベルでValueDescriptor により代表される。必要な場合，一部はここでオーバーライドされる場合もあ
る。
R＿ATTR＿R0 (Rvalue,defaultValue);
そのアイテムのデフォールト値。デフォールト値デスクリプタはこのアイテムの全てのインスタンスに対して用いられるデスクリプタである。
R＿FUNC＿GET (R＿ValueDscr & ，defaultDscr);
デフォールト値のデスクリプタ。
R＿ATTR＿RW (RBool, msbFirst);
バイト・オーダリング
R＿ATTR＿RW＿RC(R＿Base，itemValueList);
R＿FUNC＿GET (R＿Base *，ValueList);
デスクリプタの中のローカル値をオーバーライドできるローカル値リスト
R＿ATTR＿RW (RCard, itemSize);
サイズに関するオーバーライド，アイテムがビットフィールドかストリングかによって，ビットまたはバイト
R＿FUNC＿GET (RCard, minSize);
R＿FUNC＿GET (RCard, maxSize);
R＿FUNC＿GET (RCard, packedSize);

Read and Writing：
SI＿ RemoteItem はリモート・マシーン上のアイテムを読み出したり，アイテムを書き込んだりするためのオペレーションを含んでいるが，しかしながら，これらはプロトコル固有サブクラスにオーバーライドされる。これらのオペレーションはSI＿ ModelItemに組み込まれるが，それはこれがSI＿AppItem が参照するクラスだからである。SI＿AppItem がアイテムとデータベース・アイテムをそれぞれ別に取り扱わねばならないかについて特別な理由はなく，例えば，あるマシーンはそれ自身のシリアル番号についてレポートし，他のマシーンがネームプレート上およびカスタマー・データベース内にだけシリアル番号を保存するようにしても差し支えない。
なお，リモート・アクセス・オペレーションはSI＿AppItem アーギュメントの形式をとり，これはそのためにその作業が行われているアプリケーション・アイテムである。SI＿AppItem が"busy"とマークされれば，全てのオペレーションはすぐリターンされ，その作業が実際に行われる場合は，コールバック法が起動される。

R＿FUNC＿GET ＿IS(RBool, readOnly, rFalse);
R＿FUNC＿GET ＿IS(RBool, isRemote, rFalse);
このサービスが実際にリモート・マシーンに含まれている場合は有効。これは，ユーザーに対して，読み出しや書き込みを行うためには一定の時間がかかることを示唆するために用いることができる。
Virtual RBool updateParentNewValue(SI＿AppItem *, RValue const & ）；
必要な場合，AppleItem のペアレントのNewValueを更新する。
Virtual RBool updateChildrenNewValue(SI＿AppItem *,
RValue const & ）；
必要であれば，AppItem のペアレントのChildrenValue を更新
Virtual RBool updateParentCurrentValue(SI＿AppItem *,
RValue const & ）；
必要であれば，AppItem のペアレントのcurrentValueを更新
Virtual RBool updateChildrenCurrentValue(SI＿AppItem *,
RValue const & ）；
必要であれば，applItemのチルドレンのcurrentValueを更新

Virtual void readOrEnqueue(SI＿ AppItem *app, RBool mayQueue);
Virtual void writeOrEnqueue (SI＿AppItem *app, RValue const &v, RBool mayQueue);
AppItem のカレント値を読み出したり，書き込んだりする。isRemote( ) およびmayQueueが両方とも有効であれば，オペレーションは実際にキューされる。
virtual void readNotify(SI＿AppItem *app, RValue const &V,
R＿Symbol *status) ;
Virtual void writeNotify (SI＿AppItem *app, RValue const &V, R＿Symbol *status) ;
値が適切なステータスで読み出されたり，書き込まれたりしたことをアプリケーション・アイテムに伝える（ゼロは全てがうまく行ったことを示す）。
これは，AppItem に値を保存することである。
Virtual void readEnqueue (SI＿AppItem *app);
Virtual void writeEnqueue(SI＿AppItem *app, RValue const &v); キュー入力を行う。
Virtual void readValue (SI＿AppItem *app)
Virtual void writeValue(SI＿AppItem *app, RValue const &v);
実際に読み出し，書き込みを行い，その結果をAppItem 伝える。キュー入力から呼び出される場合もある。デフォールトではreadValue がModelItem のdefaultValueをリターンし，writevalueがApplItemにその値が書き込まれたことを伝える。
virtual RCard readValueFromBuffer(SI＿AppItem *app,R＿Buffer const &buf, RCard buf＿addr=0,RCard hdr＿size=0);
virtual RCard writeValueIntoBuffer (SI＿AppItem *app, RValue const &vR Buffer &buf, RCard buf＿addr=0,
RCard hdr size=0);
バッファー上で読み出しまたは書き込みを行い,AppItemに通知する。
buf＿ addr パラメータはそのマシーンのメモリ位置ゼロに対する｛＼em buffer ｝のスタート・アドレス。
hdr＿sizeはバッファー内のいずれかのプロトコル・ヘッダー情報以下の buf＿addrに対応する位置である。

Initalization:
virtual void initAppItem (class SI＿AppItem *, RValue&) ｛｝
AppItem のカレント値が初期化される必要がある場合，Si＿AppItem がつくられると呼び出される。このルーチンはカレント値に対する任意の直接アクセスである。

２．３．４．ＳＩ＿ＲｅｍｏｔｅＩｔｅｍクラス
ＳＩ＿ＲｅｍｏｔｅＩｔｅｍクラスは，リモート・マシーンによって実際に実行され，あるいは，リモート・マシーンに保存されたり，そこから検索されるサービス・アイテムに対するペアレント・クラスである。このクラスはメモリに基づくサービス・アイテムに関する実際のメモリ位置を示すと同時に，必要であれば，個々のビットに関する情報も含んでいる。リモート・マシーンが内容を保有している場合，このクラスはコンポーネントに対して，個々の名称および記述をデータ・ストラクチャの形式で提供する。同じアイテムの列は唯１つのアイテムを有しているだけである。

class SI＿RemoteItem: public SI＿ModelItem ｛
R＿ABSTRACT (SI＿RemoteItem, SI＿ModelItem);
public:
R＿ATTR＿GET ＿IS(RBool, isRemote, rTrue);
R＿ATTR＿RW(RBool, readOnly);
Constructors:
SI＿RemoteItem(R＿Base const &o);
SI＿RemoteItem(R＿Symbol &nm, RValue const &dflt,
Service *prnt0)

２．３．５．ＳＩ＿ＭｅｍｏｒｙＩｔｅｍクラス
ＳＩ＿ＭｅｍｏｒｙＩｔｅｍクラスは，リモート・マシーン上のメモリ内での位置を示すものである。背景の箇所でも述べたように，一部のリモート・マシーンはリモート・マシーン・メモリに対して直接のアクセスを可能にしている場合がある。

class IS＿MemoryItem: public SI＿RemoteItem｛
R＿CONCRETE (SI＿MemoryItem, SI＿RemoteItem);
public:
Attributes：
R＿FUNC＿GET ＿IS(RCard, start, address() );
スタート・アドレス
Reading and writing ：
virtual RBool updateChildrenNewValue(SI＿AppItem *, RValue
const &);
virtual RBool updateChildrenCurrentValue(SI＿AppItem *,
RValue const &);
Constructors：
R＿COPY＿ONSTRUCTOR SI＿MemoryItem(R＿Base const &o);
SI＿MemoryItem(R＿Symbol &nm,RValue const &dflt,RCard addr=0 Service *prnt=0);
SI＿MemoryItem(R＿Symbol &nm, RValue const &dflt, RCard
byteAdd , RCard bitAddr, Service *prnt=0) ;

２．３．６．ＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍクラス
ＳＩ＿ＢｉｔｆｉｅｌｄＩｔｅｍクラスは，それを含むＳＩ＿ＭｅｍｏｒｙＩｔｅｍ内のビットフィールドを示している。このビット数は含んでいるメモリ・アイテムの低オーダー・ビットに関するものであり，最大３２ビット長である。このビットフィールドのサイズ（packedSize) を指定するのは，デフォールト値のデスクリプタにまかせられる。

Class SI＿BitfieldItem: public SI＿ MemoryItem ｛
R＿CONCRETE (SI＿ BitfieldItem, SI＿RemoteItem);
public:
R＿FUNC＿GET(RCard, minSize);
R＿FUNC＿GET(RCard, maxSize);
R＿FUNC＿GET(RCard, packedSize);
itemSizeがゼロでない場合，サイズを正しく計算するために，これらをオーバーライドしなければならない。
virtual void readOrEnqueue (SI＿AppItem *app, RBool
mayQueue);
virtual void writeOrEnqueue
(SI＿AppItem *app, RValue const &v,
RBool mayQueue);
virtual void readEnqueue (SI＿AppItem *app);
virtual void writeEnqueue(SI＿AppItem *app, RValue const &v); virtual RBool updateParentNewValue (SI＿AppItem *,RValue
const &);
virtual RBool updateParentCurrentValue (SI＿AppItem *,RValue const &);

３．通信モジュール
３．１．概要
通信モジュール１８０は，マシーン・モデル・モジュール１７０を共同して，クラスＳＩ＿ＡｐｐＩｔｅｍのインスタンスで“ｒｅａｄＲｅｑｕｅｓｔ”および“ｎｅｗＶａｌｕｅＳｅｔ”オペレーションを実行することで行われるリクエストに従って，リモート・マシーン９０上でオペレーションを実行したりデータにアクセスしたりする。

図２でコア層１９０に配置されている通信モジュール１７０の目的は，リモート・サービス・アプリケーション・プログラム（図２のアプリケーション層１４０における１００，１１０，１２０，１３０等）が動作しているコンピュータ・システム１とあるリモート・マシーン１０との間で，『通信セッション』と呼ばれるインタラクションを実行するためのプログラムミング・インタフェースを提供することである。このプログラミング・インタフェースのインプリメンテーションは基本通信クラスのサブクラスに含まれており，これらのサブクラスは図２のインタフェース層２６０に配置されている。

本発明の好ましい実施の形態は，全てのタイプのリモート・マシーンのために，通信モジュール１７０内で定義される単一のプログラミング・インタフェースを用いる。インタフェース層２６０内のサブクラスは特定のタイプのリモート・マシーンとのインタフェースを行うのに適したそのプログラミング・インタフェースのインプリメンテーションを行う。

また，本発明の好ましい実施の形態において，セッション・クラス階層は以下のもので構成されている（インデントの部分はインヘリタンスを示す）。

SI＿DeviceCallBack
SI＿CommunicationSession
SI＿BufferedSession バッファーされたセッション
SI＿MemorySession メモリに基づくセッション
SI＿256BytesSession コール・セッションあたり 256バイト SI＿CopierSession プログラムに基づいたセッション
SI＿UnbufferedSession バッファーされないセッション
SI＿DBSession データ・ベース・セッション
SI＿CustAccessionSession カスタマー・データ・
ベース・アクセス
SI＿HistorySession 経時データベース
TI TaskItem
TI＿CommunicationItem 通信タスク・アイテム
TI＿MemoryItem メモリに基づくタスク・アイテム
TI＿ProgramItem プログラムに基づくタスク・アイテム TI＿HistoryItem データ・ベース・タスク・アイテム

３．２．詳細な説明
ＳＩ＿ＤｅｖｉｃｅＣａｌｌＢａｃｋクラスは，リモート・サービス・アプリケーションと外部プロセス，通信装置，またはリモート・マシーンとの間の非同期通信のための一組の抽象的プログラミング・インタフェースを含んでいる。こうした非同期入力または出力オペレーションはそれを実行するのに一定の時間がかかるので，このアプリケーションは単にリクエストを発行して，ユーザー・インタフェース・イベントを処理し続ける。このオペレーションの実行が完了すると，装置ドライバーは“ｃｏｎｎｅｃｔＤｏｎｅ”オペレーションを用いてそのアプリケーションを『コール・バック』する。

“ＳＩ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｓｓｉｏｎ”は，全てのセッションのための抽象的基本クラス，つまり，リモート・マシーンとのインタフェースである。バッファーされたものと，バッファーされていないものの二つのＳＩ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｓｓｉｏｎの二つのサブクラスが存在する。

バッファーされたセッション（ＳＩ＿ＢｕｆｆｅｒｅｄＳｅｃｔｉｏｎおよびそのサブクラス）は，多くの場合，プロトコル情報を含んでいるヘッダーを含むブロックで送受信されることを求めるプロトコルを用いて通信に対処する。このデータおよびヘッダーは，次に，送られる前または受信された後でバッファに保存される。ＳＩ＿ＢｕｆｆｅｒｅｄＳｅｓｓｉｏｎは，バッファー内のデータのフォーマットおよびその位置を指定するためにマシーン・モデル６３０，８６０内の情報を用いて，バッファとそのリモート・サービス・アプリケーションの内部データ・ストラクチャ（アプリケーション・ステート６００，８１０に含まれている）でデータを移動させるために必要なコードを含んでいる。

ＳＩ＿ＭｅｍｏｒｙＳｅｓｓｉｏｎ，ＳＩ＿２５６ＢｙｔｅＳｅｓｓｉｏｎ，およびＳＩ＿ＣｏｐｉｅｒＳｅｓｓｉｏｎは，異なったリモート・マシーンのための通信固有情報を与えるＳＩ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｓｓｉｏｎのサブクラスを示している。

バッファーされていないセッション（ＳＩ＿ＵｎｂｕｆｆｅｒｅｄＳｅｓｓｉｏｎおよびそのサブクラス）は，そのために，リモート・マシーンとアプリケーション・ステート６００，８１０内のデータ間のリモート手順呼び出しによる直接のデータ伝送をサポートする一定のオペレーティング・システムまたはライブラリによってアプリケーション・プログラミング・インタフェースが提供されるところのデータベース・サーバーまたはファイル・サーバー等のエンティティに対するインタフェースとして用いられる。

ＳＩ＿ＤＢＳｅｓｓｉｏｎ，ＳＩ＿ＣｕｓｔＡｃｃｅｓｓＳｅｓｓｉｏｎ，およびＳＩ＿ＨｉｓｔｏｒｙＳｅｓｓｉｏｎは，種々のリモート・データベース等に通信固有情報を提供するＳＩ＿ＵｎｂｕｆｆｅｒｅｄＳｅｓｓｉｏｎのサブクラスを示している。

ＴＩ＿ＴａｓｋＩｔｅｍｓは，１つの通信セッションをいくつか複数のステップに分割するために用いられる。図６は，コンピュータ・システム１とリモート・マシーン９０（ここでは，１１１０で示す）間の典型的なセッションを示している。セッション（Ｓｅｓｓｉｏｎ）１０００はローカル読み出しキュー１０４０およびローカル書き込みキュー１０７０，サービス・アイテムに関して要求されたオペレーションを実行するための仮想バッチング・オペーレション，およびリモート・マシーン１１１０で用いられる外部フォーマットとコンピュータ・システム１との間でデータを翻訳するための仮想マッピング・オペーレションを含んでいる。キュー１０４０および１０７０はＳＣ＿Ｑｕｅｕｅのインスタンスであり，ＳＩ＿ＱｕｅｕｅＩｔｅｍのインスタンス１０５０，１０６０，１０８０，１０９０を含んでいる。

各ＳＩ＿ＱｕｅｕｅＩｔｅｍ１０５０，１０８０等は，読み出しリクエスト１０５０に対しては有効（ｔｒｕｅ）で書き込みリクエスト１０８０に対しては無効（ｆａｌｓｅ）なブール（Ｂｏｏｌｅａｎ：論理演算）属性“ｒｅａｄ”と，読み出しリクエスト１０５０に対しては未定義で，書き込みリクエスト１０８０に対しては書き込まれるべき値を含んでいるＲＶａｌｕｅ属性“ｖａｌｕｅ”，および，その上でオペレートされるべきリモート・サービスを示すＳＩ＿ＡｐｐＩｔｅｍ１０５１，１０８１に対するリフェレンスを含む属性“ａｐｐＩｔｅｍ”を含んでいる。ＳＩ＿ＡｐｐＩｔｅｍ１０５１，１０８１は，データタイプや，サービスの一を記述したＳＩ＿ＭｏｄｅＩｔｅｍのサブクラスのインスタンス１０５２，１０８２を順番に参照する。

また，セッション１０００は，Ｔｉ＿ＴａｓｋＩｔｅｍのサブクラスであるインスタンス１０２０，１０３０のリストを参照する属性“ｃａｌｌＳｃｈｅｄｕｌｅ”を保有している。用いられるサブクラスは交信されるリモート・マシーン１１１０のタイプに固有である。コール・スケジュール・リストは一回の呼び出しで行われるべきオペレーションの順番を判定し，また，例えば，１回のコールあたり最大２５６の連続バイトを伝送するファクシミリ装置において，それらにアクセスするために必要な個別コールの数を最小限におさえるためにリモート・ファクシミリ装置のメモリ９１０内のアイテム９２０，９３０に対するレファレンスの順番を入れ替えることによって最適化をはかるために用いられる場合もある。

セッション１０００が開始されると，それは，それによってアプリケーション・プログラムがリモート・マシーン９０，１１１０と交信することができる通信装置７０に対するインタフェースを提供するＣＭ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＤｅｖｉｃｅのサブクラスのインスタンス１１００に対する装置マネジャーを要求する。セッション１０００によって行われる要求は，リモート・マシーン９０，１１１０との通信で用いられるプロトコルの指定を含んでおり，装置マネジャーは要求されたプロトコルを用いることができ，まだ使われていない装置７０のインスタンス１１１０をリターンする。

リモート・サービス・アプリケーションが通常ユーザーに応えて，キュー・アップされた通信リクエストの実行を要求すると，セッション１０００は，ｃａｌｌＳｃｈｅｄｕｌｅ１０１０を構成するためにその読み出しキュー１０４０および書き込みキュー１０７０を繰り返す。必要であれば，そのデータをＳＩ＿ＱｕｅｕｅＩｔｅｍ内での内部フォーマットからその外部表現に変換してそれをバッファ内に保存するために，各対応するＳＩ＿ＭｏｄｅｌＩｔｅｍ１０８２の仮想機能“ｐｕｔＶａｌｕｅＩｎｔｏＢｕｆｆｅｒ”を用いてバッファー内に書き込まれるべきデータを蓄積する。

これによって，セッション１０００は，呼び出しスケジュールを繰り返し，各タスク・アイテム１０２０，１０３０に対してそのオペレーションを実行するように命令する。各タスク・アイテム１０２０，１０３０は，それを受けてセッション１０００に対して，リモート・マシーン１１１０上でどのオペレーションを実行すべきかを順番に知らせる。そしてセッション１０００は装置コントローラ１１００（上述）を用いてリモート・マシーン１１１０との間で低レベル読み出しまたは書き込みオペレーションを実行する。必要であれば，各対応するＳＩ＿ＭｏｄｅｌＩｔｅｍ１０５２の仮想機能“ｇｅｔＶａｌｕｅＦｒｏｍＢｕｆｆｅｒ”を用いて，バッファーからデータを抽出し，それを内部表現から外部表現に翻訳し，そしてそれをＳＩ＿ＡｐｐＩｔｅｍ１０５１の“ｃｕｒｒｅｎｔＶａｌｕｅＳｅｔ”オペレーションを用いてＳＩ＿ＡｐｐＩｔｅｍ１０５１内に保存する。

３．３．新しいセッション・タイプの定義
上の説明でわかるように，アプリケーション・プログラマは，どのリモート・マシーン，データベース，または他の外部資源との通信の新しい方法を記述するために，クラスＳＩ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＳｅｓｓｉｏｎに対してサブクラスを簡単に定義することができる。そうしたサブクラスのためのコードを含んでいるライブラリとリンクされたどのアプリケーションも動作時にその新しいセッション・タイプを用いることができ，こうしたアプリケーションはリコンパイルする必要がなく，再リンクすれば良いだけである。新しいクラスをダイナミック・リンク・ライブラリ（ＤＬＬ）内に入れることにより，適切に構成されたアプリケーションは，リンクされユーザーに提供された後でも新しいセッション・タイプを用いることができる。

４．通信装置インタフェース
４．１．概要
通信装置７０は，それを通じてリモート・サービス・アプリケーションがリモート・マシーンと交信するための，モデム等コンピュータ・システムの周辺装置である。本発明の好ましい実施の形態においては，通信装置７０はクラスＣＭ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＤｅｖｉｃのサブクラスのインスタンス１１００として，アプリケーション・プログラム内に表現される。

本発明の好ましい実施の形態においては，装置クラス階層は以下の構成を有している（インデントはインヘリタンスを示す）。

CM＿CommunicationDevice
CM＿Modem モデム
CM＿CCA ＦＡＸのための通信アダプタ
CM＿USACCA ．．． ２５６バイト・プロトコル用のアダプタ
CM＿LADP ライン・アダプタ／マルチプレクサ
CM＿DBACESS データベース用の装置
CM＿DeviceManager

４．２．詳細な説明
クラスＣＭ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＤｅｖｉｃｅは，モデム等の物理的な通信装置ばかりでなく，データベースおよびデータベース・サーバー等に対するアプリケーション・プログラミング・インタフェースにも関連した全ての属性およびオペレーションの全てを内蔵している。ＣＭ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＤｅｖｉｃｅのインスタンスはリモート・マシーンの通信アドレス，そのリモート・マシーンに固有のプロトコル上の制約に関するリスト，そして，全ての装置に対してプログラミング・インタフェースを提供する仮想機能“ｉｎｉｔＤｅｖｉｃｅ”，“ｃｏｎｎｅｃｔ”，“ｒｅａｄ”，“ｗｒｉｔｅ”および“ｄｉｓｃｏｎｎｅｃｔ”を含む属性を保有している。

クラスＣｍ＿ＣＣＡは，リモート・ファクシミリ装置と交信するために用いられる通信制御装置アダプタに適用できる全ての属性およびオペレーションを定義するクラスの好ましい実施の形態である。ＣＣＡ（通信制御装置アダプタ）はそのリモート・マシーンの内部メモリをアクセスできる特殊な目的のファックス・モデムの１つの実施の形態である。ＣＭ＿ＵＳＡＣＣＡクラスは２５６タイプ・プロトコルを用いるファクシミリ装置のアクセス・修正をどのように行うかを示す好ましい実施の形態を示している。

クラスＣＭ＿ＬＡＤＰは，コピー機の通信のために用いられるクラスの好ましい実施の形態である。このクラスは通信チャンネルとしてＣＭ＿Ｍｏｄｅｍのインスタンスを用いる。ＬＡＤＰ（ライン・アダプター）は電話回線と最大５台のコピー機との間をつなぐモデムとマルチプレクサとの組み合わせの１つの実施の形態である。

クラスＣＭ＿ＤＢＡＣＥＳＳは，リモート・サービス・アプリケーションがデータベースを１つのリモート装置のように見ることができるようにするクラスの好ましい実施の形態である。このクラスはデータベースを操作する機能を有し，そのデータベース内のデータ・アイテムにアクセスし，それを更新するためのデータベース・インタフェース・ライブラリによって定義されるオペレーションを用いる。

クラスＣＭ＿ＤｅｖｉｃｅＭａｎａｇｅｒは，コンピュータ・システム１に取りつけられた全ての通信装置７０，そのステータス（アイドル，またはビジー），そしてそれらがサポートするプロトコルをトラッキングするための機能である大域オブジェクトのクラスの好ましい実施の形態である。通信セッション・オブジェクト１０００は装置マネジャーから装置オブジェクト１１００を要求し，その装置マネジャーは現在は空いているがリモート・マシーン９０，１１１０によって要求される通信プロトコルを取り扱うことができる装置に対するレファレンスをリターンする。

４．３．新しい装置の追加
上の説明で分かるとおり，アプリケーション・プログラマは，どの新しいリモート装置，データベース，あるいはその他の外部資源に対してそのプロトコルを定義するために，クラスＣＭ＿ＣｏｍｍｕｎｉｃａｔｉｏｎＤｅｖｉｃｅに対するサブクラスを簡単に定義することができる。そうしたサブクラスのためのコードを含んだライブラリにリンクされたどのアプリケーションも動作時に新しいプロトコルを用いることができ，そうしたアプリケーションはリコンパイルする必要はなく，再リンクするだけでよい。新しいクラスをダイナミック・リンク・ライブラリ（ＤＬＬ）に入れることによって，適切に構成されたアプリケーションは，リンクされ，ユーザーに渡された後でも新しいプロトコルを利用することができる。

５．追記
前述したように本実施の形態では，その１つの具体的な実施の形態を参照して本発明についての説明を行った。リモート装置のモデリングを簡単に行うフレームワークに対して多くの変更，修正，および機能的拡張は簡単に想起でき，それらは本発明の他の実施の形態に含まれる。したがって，明細書および図面は，本発明を限定するものではなく，説明のためのものであるとみなされるべきである。しかしながら，特許請求の範囲に定義されるような本発明の精神と範囲を逸脱することなく，種々の修正，変更を行うことができるのは明らかなことである。

〔著作権に関する告知〕
また，本特許開示の一部は，著作権保護の対象となる素材を含んでいる。著作権保有者は，この特許資料または特許開示の一部を特許商標特許ファイルあるいは記録に記載された通りにファクシミリ装置で複製することについては反対はしないが，それ以外に関しては著作権が適用される。

以上説明したように，本発明の通信方法（請求項１〜請求項３）は，複数の周辺装置と，周辺装置の属性情報を記憶した記憶手段を有する情報処理装置とが通信する通信方法において，前記情報処理装置の前記記憶手段内部に，属性情報に基づいて前記複数の周辺装置の１つで実行される機能を記述するオブジェクトを構成するステップと，前記情報処理装置が前記オブジェクトに記述された実行される機能に応じて前記１つの周辺装置と交信するステップと，前記情報処理装置が前記第１の複数のオブジェクトに記述された実行される機能に応じて前記交信した周辺装置のオペレーションを呼び出すステップと，を含んでいるため，リモート・サービス・アプリケーションにオブジェクト指向を導入することにより，開発サイクル期間の低減を図り，システムの修正等の柔軟性を高めることができる通信方法を提供することができる。

以上のように、本発明にかかる通信方法は、通信技術に有用であり、特に、通信を介して情報処理を行う差異の通信技術に適している。

本発明の好ましい実施の形態によるコンピュータ・システム１の構成図である。 本発明の好ましい実施の形態で用いられるオブジェクト指向アプリケーション・フレームワークの構成図である。 サンプル・リモート・サービス・アプリケーション・プログラムおよび本発明の好ましい実施の形態で使うためのフレームワークと共に提供されたデータ・ファイルの構成図である。 本発明の好ましい実施の形態における，コンポーネント，グラフィック・ユーザー・インタフェース，アプリケーション・ステート，マシーン・モデル，そしてリモート・マシーンを記述するキュー・オブジェクトを示す説明図である。 本発明の好ましい実施の形態における，リモート・ファクシミリ装置および対応するコンポーネント，マシーン・モデル，およびアプリケーション・ステート・オブジェクト，およびそれらの上記リモート・マシーン内に含まれたデータに対する関係を示す説明図である。 好ましい実施の形態における，リモート・マシーンとの交信，およびその上でのオペレーションのために必要なオブジェクトを示す説明図である。

符号の説明

１ コンピュータ・システム
２ コンピュータ
１０ 表示モニター
２０ キーボード
３０ マウス
４０ プロセッサ
５０ メモリ
６０ 大容量記憶装置
７０ 通信装置
８０ システム・バス
９０ リモート・マシーン
１４０ アプリケーション層
１７０ マシーン・モデル・モジュール
１８０ 通信モジュール（通信機能）
１９０ コア層
２３０，２４０ マシーン記述ファイル
２６０ インタフェース層

Claims (3)

1. 複数の周辺装置と，周辺装置の属性情報を記憶した記憶手段を有する情報処理装置とが通信する通信方法において，
   前記情報処理装置の前記記憶手段内部に，属性情報に基づいて前記複数の周辺装置の１つで実行される機能を記述するオブジェクトを構成するステップと，
   前記情報処理装置が前記オブジェクトに記述された実行される機能に応じて前記１つの周辺装置と交信するステップと，
   前記情報処理装置が前記第１の複数のオブジェクトに記述された実行される機能に応じて前記交信した周辺装置のオペレーションを呼び出すステップと，を含んでいることを特徴とする通信方法。
2. 属性情報には、前記オブジェクトに対するポインタと前記１つの周辺装置内部でのデータ・アイテムの値に対応したカレント値を含んでいることを特徴とする請求項１に記載の通信方法。
3. 属性情報には，読み出しリクエスト・フラッグと前記１つの周辺装置に送られるべき値に関するペンディング・リクエストを記述するための新しい値とを含んでいることを特徴とする請求項１または２に記載の通信方法。

Images