JPH09114753A - オブジェクト指向通信システムの使用方法 - Google Patents

Abstract

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

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，全体としては，リ
モート・マシーンのためのサービス・ツールの領域に関
し，より詳細には，コンピュータ・システムにおけるサ
ービス・アプリケーション・プログラムと，リモート・
マシーンや，ファイル，データベースおよびプログラム
内の外部データ等のリモート装置との間の通信を行うオ
ブジェクト指向通信システムの使用方法。

【０００２】

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

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

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

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

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

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

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

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

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

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

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

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

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

【００１５】

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

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

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

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

【００１９】

【課題を解決するための手段】上記の目的を達成するた
めに，請求項１に係るオブジェクト指向通信システムの
使用方法は，メモリを有するコンピュータ・システムを
使用し，複数のマシーン・タイプの複数のリモート・マ
シーンと通信する方法において，前記メモリ内部に，前
記複数のリモート・マシーンの１つにサービスを記述す
る第１の複数のソフトウェア・オブジェクトを構成する
ステップと，前記１つのリモート・マシーンと交信する
ステップと，前記第１の複数のソフトウェア・オブジェ
クトのサービスによって記述された要求に応じて１つの
リモート・マシーンのオペレーションを呼び出すステッ
プと，を含んでいるものである。

【００２０】また，請求項２に係るオブジェクト指向通
信システムの使用方法は，請求項１記載のオブジェクト
指向通信システムの使用方法において，前記１つのリモ
ート・マシーンに対する前記サービスが，前記１つのリ
モート・マシーン上でのオペレーションを含んでいるも
のである。

【００２１】また，請求項３に係るオブジェクト指向通
信システムの使用方法は，請求項１記載のオブジェクト
指向通信システムの使用方法において，前記１つのリモ
ート・マシーンに対する前記サービスが，データ・タイ
プ，データ・サイズおよびデータ位置を含む前記１つの
リモート・マシーンに伝送されるべきデータのアイテム
を含んでいるものである。

【００２２】また，請求項４に係るオブジェクト指向通
信システムの使用方法は，請求項１記載のオブジェクト
指向通信システムの使用方法において，さらに，前記メ
モリー内に，前記１つのリモート・マシーンに対するア
プリケーション・アイテムを記述する第２の複数のソフ
トウェア・オブジェクトを含んでいるものである。

【００２３】また，請求項５に係るオブジェクト指向通
信システムの使用方法は，請求項４記載のオブジェクト
指向通信システムの使用方法において，前記１つのリモ
ート・マシーンに対する前記アプリケーション・アイテ
ムが，前記第１の複数のソフトウェア・オブジェクトに
対するポインタと前記１つのリモート・マシーン内部で
のデータ・アイテムの値に対応したカレント値を含んで
いるものである。

【００２４】また，請求項６に係るオブジェクト指向通
信システムの使用方法は，請求項５記載のオブジェクト
指向通信システムの使用方法において，前記１つのリモ
ート・マシーンに対する前記アプリケーション・アイテ
ムが，さらに，読み出しリクエスト・フラッグと前記１
つのリモート・マシーンに送られるべき値に関するペン
ディング・リクエストを記述するための新しい値とを含
み，第２の複数のソフトウェア・オブジェクトを構成す
る前記ステップが，前記第２の複数のソフトウェア・オ
ブジェクトを１つのリモート・マシーンに送られるべき
データに対するリクエストを記録するために用いるステ
ップを含んでいるものである。

【００２５】また，請求項７に係るオブジェクト指向通
信システムの使用方法は，請求項１記載のオブジェクト
指向通信システムの使用方法において，さらに，前記メ
モリー内に，それぞれデータベース内の１つのアイテム
を識別および記述するための第２の複数のソフトウェア
・オブジェクトを構成するステップを含んでいるもので
ある。

【００２６】また，請求項８に係るオブジェクト指向通
信システムの使用方法は，請求項７記載のオブジェクト
指向通信システムの使用方法において，さらに，前記１
つのリモート・マシーンに対して移されるデータのアイ
テムに応じて，そのデータベースに対する更新をリクエ
ストするステップを含んでいるものである。

【００２７】また，請求項９に係るオブジェクト指向通
信システムの使用方法は，請求項１記載のオブジェクト
指向通信システムの使用方法において，前記第１の複数
のソフトウェア・オブジェクトを構成するステップが，
構成されるべき第１の複数のソフトウェア・オブジェク
トの表現を含んでいるデータ・ファイルを読み出すステ
ップを含んでいるものである。

【００２８】また，請求項１０に係るオブジェクト指向
通信システムの使用方法は，請求項９記載のオブジェク
ト指向通信システムの使用方法において，前記データ・
ファイルが，構成されるべき前記第１の複数のソフトウ
ェア・オブジェクトのテキストによる表現を含んでいる
ものである。

【００２９】また，請求項１１に係るオブジェクト指向
通信システムの使用方法は，請求項１記載のオブジェク
ト指向通信システムの使用方法において，さらに，グラ
フィック・ユーザー・インターフェースによるユーザー
入力に応えて，複数のリモート・マシーン上でサービス
に対するリクエストを行うステップと，前記複数のリモ
ート・マシーン上でリクエストされたサービスが終了し
た場合に，前記グラフィック・ユーザー・インターフェ
ースを更新するステップと，を含んでいるものである。

【００３０】また，請求項１２に係るオブジェクト指向
通信システムの使用方法は，請求項１１記載のオブジェ
クト指向通信システムの使用方法において，前記複数の
リモート・マシーンに対するサービスが，前記複数のリ
モート・マシーン上でのオペレーションを含んでいるも
のである。

【００３１】また，請求項１３に係るオブジェクト指向
通信システムの使用方法は，請求項１１記載のオブジェ
クト指向通信システムの使用方法において，前記複数の
リモート・マシーンに対する前記サービスが，データ・
タイプ，データ・サイズおよびデータ位置を含む前記複
数のリモート・マシーンに送られるべきデータのアイテ
ムを含んでいるものである。

【００３２】また，請求項１４に係るオブジェクト指向
通信システムの使用方法は，請求項１記載のオブジェク
ト指向通信システムの使用方法において，さらに，前記
メモリ内に，その他の複数のリモート・マシーンに対す
るサービスを記述する第２の複数のソフトウェア・オブ
ジェクトを構成するステップを含んでいるものである。

【００３３】また，請求項１５に係るオブジェクト指向
通信システムの使用方法は，請求項１４記載のオブジェ
クト指向通信システムの使用方法において，前記第２の
複数のソフトウェア・オブジェクトを構成するステップ
が，構成されるべき前記第２の複数のソフトウェア・オ
ブジェクトの表現を含んでいるデータ・ファイルを読み
出すステップを含んでいるものである。

【００３４】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７８】ＳＣ＿ＡｐｐＳｅｒｖｉｃｅｓ６００は，
『アプリケーション・アイテム』６１０，６２０の集合
（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) ;

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

【０１３４】 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

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

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

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

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

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

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

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

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

【０１６４】

【発明の効果】以上説明したように，本発明のオブジェ
クト指向通信システムの使用方法（請求項１〜請求項１
５）は，メモリを有するコンピュータ・システムを使用
し，複数のマシーン・タイプの複数のリモート・マシー
ンと通信する方法において，前記メモリ内部に，前記複
数のリモート・マシーンの１つにサービスを記述する第
１の複数のソフトウェア・オブジェクトを構成するステ
ップと，前記１つのリモート・マシーンと交信するステ
ップと，前記第１の複数のソフトウェア・オブジェクト
のサービスによって記述された要求に応じて１つのリモ
ート・マシーンのオペレーションを呼び出すステップ
と，を含んでいるため，リモート・サービス・アプリケ
ーションにオブジェクト指向を導入することにより，開
発サイクル期間の低減を図り，システムの修正等の柔軟
性を高めることができるオブジェクト指向通信システム
の使用方法を提供することができる。

【図面の簡単な説明】

【図１】本発明の好ましい実施の形態によるコンピュー
タ・システム１の構成図である。

【図２】本発明の好ましい実施の形態で用いられるオブ
ジェクト指向アプリケーション・フレームワークの構成
図である。

【図３】サンプル・リモート・サービス・アプリケーシ
ョン・プログラムおよび本発明の好ましい実施の形態で
使うためのフレームワークと共に提供されたデータ・フ
ァイルの構成図である。

【図４】本発明の好ましい実施の形態における，コンポ
ーネント，グラフィック・ユーザー・インタフェース，
アプリケーション・ステート，マシーン・モデル，そし
てリモート・マシーンを記述するキュー・オブジェクト
を示す説明図である。

【図５】本発明の好ましい実施の形態における，リモー
ト・ファクシミリ装置および対応するコンポーネント，
マシーン・モデル，およびアプリケーション・ステート
・オブジェクト，およびそれらの上記リモート・マシー
ン内に含まれたデータに対する関係を示す説明図であ
る。

【図６】好ましい実施の形態における，リモート・マシ
ーンとの交信，およびその上でのオペレーションのため
に必要なオブジェクトを示す説明図である。

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 リスイー ロス アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内 (72)発明者 ティナ イェン アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内 (72)発明者 ピーター ハート アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内 (72)発明者 リチャード ゴールディング アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内

Claims (15)

【特許請求の範囲】
1. 【請求項１】 メモリを有するコンピュータ・システム
   を使用し，複数のマシーン・タイプの複数のリモート・
   マシーンと通信する方法において，前記メモリ内部に，
   前記複数のリモート・マシーンの１つにサービスを記述
   する第１の複数のソフトウェア・オブジェクトを構成す
   るステップと，前記１つのリモート・マシーンと交信す
   るステップと，前記第１の複数のソフトウェア・オブジ
   ェクトのサービスによって記述された要求に応じて１つ
   のリモート・マシーンのオペレーションを呼び出すステ
   ップと，を含んでいることを特徴とするオブジェクト指
   向通信システムの使用方法。
2. 【請求項２】 請求項１記載のオブジェクト指向通信シ
   ステムの使用方法において，前記１つのリモート・マシ
   ーンに対する前記サービスが，前記１つのリモート・マ
   シーン上でのオペレーションを含んでいることを特徴と
   するオブジェクト指向通信システムの使用方法。
3. 【請求項３】 請求項１記載のオブジェクト指向通信シ
   ステムの使用方法において，前記１つのリモート・マシ
   ーンに対する前記サービスが，データ・タイプ，データ
   ・サイズおよびデータ位置を含む前記１つのリモート・
   マシーンに伝送されるべきデータのアイテムを含んでい
   ることを特徴とするオブジェクト指向通信システムの使
   用方法。
4. 【請求項４】 請求項１記載のオブジェクト指向通信シ
   ステムの使用方法において，さらに，前記メモリー内
   に，前記１つのリモート・マシーンに対するアプリケー
   ション・アイテムを記述する第２の複数のソフトウェア
   ・オブジェクトを含んでいることを特徴とするオブジェ
   クト指向通信システムの使用方法。
5. 【請求項５】 請求項４記載のオブジェクト指向通信シ
   ステムの使用方法において，前記１つのリモート・マシ
   ーンに対する前記アプリケーション・アイテムが，前記
   第１の複数のソフトウェア・オブジェクトに対するポイ
   ンタと前記１つのリモート・マシーン内部でのデータ・
   アイテムの値に対応したカレント値を含んでいることを
   特徴とするオブジェクト指向通信システムの使用方法。
6. 【請求項６】 請求項５記載のオブジェクト指向通信シ
   ステムの使用方法において，前記１つのリモート・マシ
   ーンに対する前記アプリケーション・アイテムが，さら
   に，読み出しリクエスト・フラッグと前記１つのリモー
   ト・マシーンに送られるべき値に関するペンディング・
   リクエストを記述するための新しい値とを含み，第２の
   複数のソフトウェア・オブジェクトを構成する前記ステ
   ップが，前記第２の複数のソフトウェア・オブジェクト
   を１つのリモート・マシーンに送られるべきデータに対
   するリクエストを記録するために用いるステップを含ん
   でいることを特徴とするオブジェクト指向通信システム
   の使用方法。
7. 【請求項７】 請求項１記載のオブジェクト指向通信シ
   ステムの使用方法において，さらに，前記メモリー内
   に，それぞれデータベース内の１つのアイテムを識別お
   よび記述するための第２の複数のソフトウェア・オブジ
   ェクトを構成するステップを含んでいることを特徴とす
   るオブジェクト指向通信システムの使用方法。
8. 【請求項８】 請求項７記載のオブジェクト指向通信シ
   ステムの使用方法において，さらに，前記１つのリモー
   ト・マシーンに対して移されるデータのアイテムに応じ
   て，そのデータベースに対する更新をリクエストするス
   テップを含んでいることを特徴とするオブジェクト指向
   通信システムの使用方法。
9. 【請求項９】 請求項１記載のオブジェクト指向通信シ
   ステムの使用方法において，前記第１の複数のソフトウ
   ェア・オブジェクトを構成するステップが，構成される
   べき第１の複数のソフトウェア・オブジェクトの表現を
   含んでいるデータ・ファイルを読み出すステップを含ん
   でいることを特徴とするオブジェクト指向通信システム
   の使用方法。
10. 【請求項１０】 請求項９記載のオブジェクト指向通信
    システムの使用方法において，前記データ・ファイル
    が，構成されるべき前記第１の複数のソフトウェア・オ
    ブジェクトのテキストによる表現を含んでいることを特
    徴とするオブジェクト指向通信システムの使用方法。
11. 【請求項１１】 請求項１記載のオブジェクト指向通信
    システムの使用方法において，さらに，グラフィック・
    ユーザー・インターフェースによるユーザー入力に応え
    て，複数のリモート・マシーン上でサービスに対するリ
    クエストを行うステップと，前記複数のリモート・マシ
    ーン上でリクエストされたサービスが終了した場合に，
    前記グラフィック・ユーザー・インターフェースを更新
    するステップと，を含んでいることを特徴とするオブジ
    ェクト指向通信システムの使用方法。
12. 【請求項１２】 請求項１１記載のオブジェクト指向通
    信システムの使用方法において，前記複数のリモート・
    マシーンに対するサービスが，前記複数のリモート・マ
    シーン上でのオペレーションを含んでいることを特徴と
    するオブジェクト指向通信システムの使用方法。
13. 【請求項１３】 請求項１１記載のオブジェクト指向通
    信システムの使用方法において，前記複数のリモート・
    マシーンに対する前記サービスが，データ・タイプ，デ
    ータ・サイズおよびデータ位置を含む前記複数のリモー
    ト・マシーンに送られるべきデータのアイテムを含んで
    いることを特徴とするオブジェクト指向通信システムの
    使用方法。
14. 【請求項１４】 請求項１記載のオブジェクト指向通信
    システムの使用方法において，さらに，前記メモリ内
    に，その他の複数のリモート・マシーンに対するサービ
    スを記述する第２の複数のソフトウェア・オブジェクト
    を構成するステップを含んでいることを特徴とするオブ
    ジェクト指向通信システムの使用方法。
15. 【請求項１５】 請求項１４記載のオブジェクト指向通
    信システムの使用方法において，前記第２の複数のソフ
    トウェア・オブジェクトを構成するステップが，構成さ
    れるべき前記第２の複数のソフトウェア・オブジェクト
    の表現を含んでいるデータ・ファイルを読み出すステッ
    プを含んでいることを特徴とするオブジェクト指向通信
    システムの使用方法に関するものである。