JPH09101883A - オブジェクト指向通信フレームワーク・システム，およびオブジェクト指向プログラム・フレームワークを使用する複数のアプリケーション・プログラムの構築方法 - 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

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

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

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

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

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

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

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

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

【０１６３】

【発明の効果】以上説明したように，本発明のオブジェ
クト指向通信フレームワーク・システム（請求項１〜請
求項１２）は，メモリ，プロセッサ，大容量記憶装置を
有し，オブジェクト指向プログラム言語におけるプログ
ラム，クラス・デクラレーション（宣言）およびクラス
・ライブラリを記憶するためのコンピュータ・システム
と，オブジェクト指向プログラム言語におけるアプリケ
ーション・プログラムのソース・コード表現を含むファ
イルをコンパイルするコンパイル手段と，それぞれに一
連のデータおよび一連のデータを操作するためのメソッ
ドが記述されている，データ記述クラスの階層のインプ
リメントと，それぞれに複数のリモート・マシーンの一
つに含まれたデータのアイテムおよびデータ・アイテム
にアクセスするためのメソッドが記述されている，リモ
ート・データ記述クラスの階層のインプリメントと，そ
れぞれが複数のリモート・マシーンの少なくとも一つと
交信する複数のサンプル・アプリケーション・プログラ
ムのためのソース・コード・ファイルと，を具備したた
め，リモート・サービス・アプリケーションにオブジェ
クト指向を導入することにより，開発サイクル期間の低
減を図り，システムの修正等の柔軟性を高めることがで
きる。

【０１６４】また，本発明のオブジェクト指向プログラ
ム・フレームワークを使用する複数のアプリケーション
・プログラムの構築方法（請求項１３および請求項１
４）は，オブジェクト指向プログラム・フレームワーク
に含まれる複数のサンプル・アプリケーション・プログ
ラムから，適切なアプリケーション・プログラムを選択
するステップと，修正されたアプリケーション・プログ
ラムを作成するために適切なサンプル・アプリケーショ
ン・プログラムを修正するステップと，修正されたアプ
リケーション・プログラムをコンパイルするステップ
と，を含んでいるため，リモート・サービス・アプリケ
ーションにオブジェクト指向を導入することにより，開
発サイクル期間の低減を図り，システムの修正等の柔軟
性を高めることができる。

【図面の簡単な説明】

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

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

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

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

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

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

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 技術表示箇所 Ｈ０４Ｎ 1/32 Ｈ０４Ｎ 1/32 Ｚ (72)発明者 ティナ イェン アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内 (72)発明者 リスイー ロス アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内 (72)発明者 ステフェン アール．サビツキー アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内 (72)発明者 リチャード ゴールディング アメリカ合衆国，カリフォルニア州 94025，メンロー パーク，スウィート 115，サンド ヒル ロード 2882，リコ ー コーポレイション シー・アール・シ ー内

Claims (14)

【特許請求の範囲】
1. 【請求項１】 アプリケーション・プログラマによっ
   て，リモート・アクセスが可能なデータとリモート操作
   が可能なオペレーションとを有する複数のマシーン・タ
   イプのリモート・マシーンのそれぞれと交信するための
   複数のアプリケーション・プログラムを構築することが
   可能なシステムにおいて，メモリ，プロセッサ，大容量
   記憶装置を有し，オブジェクト指向プログラム言語にお
   けるプログラム，クラス・デクラレーション（宣言）お
   よびクラス・ライブラリを記憶するためのコンピュータ
   ・システムと，オブジェクト指向プログラム言語におけ
   るアプリケーション・プログラムのソース・コード表現
   を含むファイルをコンパイルするコンパイル手段と，そ
   れぞれに一連のデータおよび前記一連のデータを操作す
   るためのメソッドが記述されている，データ記述クラス
   の階層のインプリメントと，それぞれに前記複数のリモ
   ート・マシーンの一つに含まれたデータのアイテムおよ
   び前記データ・アイテムにアクセスするためのメソッド
   が記述されている，リモート・データ記述クラスの階層
   のインプリメントと，それぞれが前記複数のリモート・
   マシーンの少なくとも一つと交信する複数のサンプル・
   アプリケーション・プログラムのためのソース・コード
   ・ファイルと，を具備することを特徴とするオブジェク
   ト指向通信フレームワーク・システム。
2. 【請求項２】 請求項１記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，前記複数のデータ記
   述クラスが，さらに，前記一連のデータのデータ・タイ
   プ，データ・サイズおよび許容値を含んでいることを特
   徴とするオブジェクト指向通信フレームワーク・システ
   ム。
3. 【請求項３】 請求項１記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，前記複数のリモート
   ・データ記述クラスが，さらに，前記データのアイテム
   のデータ・タイプ，データ・サイズおよび許容値を含ん
   でいることを特徴とするオブジェクト指向通信フレーム
   ワーク・システム。
4. 【請求項４】 請求項１記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，さらに，それぞれに
   前記複数のリモート・マシーンに対するアプリケーショ
   ン・アイテムを記述するための，アプリケーション・ス
   テート・クラスのインプリメントを含んでいることを特
   徴とするオブジェクト指向通信フレームワーク・システ
   ム。
5. 【請求項５】 請求項４記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，前記アプリケーショ
   ン・アイテムが，前記複数のリモート・データ記述クラ
   スの階層のインプリメントに対するポインタを含んでい
   ることを特徴とするオブジェクト指向通信フレームワー
   ク・システム。
6. 【請求項６】 請求項１記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，さらに，それぞれが
   前記複数のリモート・マシーン上で行なわれるオペレー
   ションのリクエストを記憶するための，オペレーション
   ・リクエスト・キュー・クラスのインプリメントを含ん
   でいることを特徴とするオブジェクト指向通信フレーム
   ワーク・システム。
7. 【請求項７】 請求項１記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，さらに，それぞれが
   前記複数のリモート・マシーンに送られるべきデータの
   アイテムのリクエストを記憶するための，オペレーショ
   ン・リクエスト・キュー・クラスのインプリメントを含
   んでいることを特徴とするオブジェクト指向通信フレー
   ムワーク・システム。
8. 【請求項８】 請求項１記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，それぞれがデータ・
   ファイルに含まれる複数のオブジェクト・インスタンス
   の表現を検索すると共に，前記複数のオブジェクト・イ
   ンスタンスの表現から，複数のオブジェクト・インスタ
   ンスをメモリ内に作るためのアプリケーション・プログ
   ラムを可能にする，パーサー・クラスのインプリメント
   を含んでいることを特徴とするオブジェクト指向通信フ
   レームワーク・システム。
9. 【請求項９】 請求項８記載のオブジェクト指向通信フ
   レームワーク・システムにおいて，前記データ・ファイ
   ルが，テキストによるデータを含んでいることを特徴と
   するオブジェクト指向通信フレームワーク・システム。
10. 【請求項１０】 請求項１記載のオブジェクト指向通信
    フレームワーク・システムにおいて，さらに，それぞれ
    がベース・クラスのサブ・クラスのオブジェクト・イン
    スタンスの表現を作るためのメソッドを記述するため
    の，データ・ファイル中のベース・クラスのインプリメ
    ントを含んでいることを特徴とするオブジェクト指向通
    信フレームワーク・システム。
11. 【請求項１１】 請求項１０記載のオブジェクト指向通
    信フレームワーク・システムにおいて，前記データ・フ
    ァイルが，テキストによるデータを含んでいることを特
    徴とするオブジェクト指向通信フレームワーク・システ
    ム。
12. 【請求項１２】 請求項４記載のオブジェクト指向通信
    フレームワーク・システムにおいて，それぞれが前記複
    数のアプリケーション・ステート・クラスをインプリメ
    ントするためのリンクを保持するための，グラフィック
    ・ユーザー・インターフェース・クラスのインプリメン
    トを含んでいることを特徴とするオブジェクト指向通信
    フレームワーク・システム。
13. 【請求項１３】 リモート・アクセスが可能なデータと
    リモート操作が可能なオペレーションとを有する複数の
    リモート・マシーンのそれぞれと交信するための，コン
    ピュータ・システムにおけるオブジェクト指向プログラ
    ム・フレームワークを使用する複数のアプリケーション
    ・プログラムの構築方法において，前記オブジェクト指
    向プログラム・フレームワークに含まれる複数のサンプ
    ル・アプリケーション・プログラムから，適切なアプリ
    ケーション・プログラムを選択するステップと，修正さ
    れたアプリケーション・プログラムを作成するために適
    切なサンプル・アプリケーション・プログラムを修正す
    るステップと，前記修正されたアプリケーション・プロ
    グラムをコンパイルするステップと，を含んでいること
    を特徴とするオブジェクト指向プログラム・フレームワ
    ークを使用する複数のアプリケーション・プログラムの
    構築方法。
14. 【請求項１４】 請求項１３記載のオブジェクト指向プ
    ログラム・フレームワークを使用する複数のアプリケー
    ション・プログラムの構築方法において，さらに，前記
    オブジェクト指向プログラム・フレームワークに含まれ
    る複数のサンプル・アプリケーション・プログラムか
    ら，その他の適切なアプリケーション・プログラムを選
    択するステップと，その他の修正されたアプリケーショ
    ン・プログラムを作成するために前記その他の適切なサ
    ンプル・アプリケーション・プログラムを修正するステ
    ップと，前記その他の修正されたアプリケーション・プ
    ログラムをコンパイルするステップと，を含んでいるこ
    とを特徴とするオブジェクト指向プログラム・フレーム
    ワークを使用する複数のアプリケーション・プログラム
    の構築方法。