JP2004348397A - アプリケーションソフトウェアとサービス部とのインターフェース方法 - Google Patents
アプリケーションソフトウェアとサービス部とのインターフェース方法 Download PDFInfo
- Publication number
- JP2004348397A JP2004348397A JP2003144268A JP2003144268A JP2004348397A JP 2004348397 A JP2004348397 A JP 2004348397A JP 2003144268 A JP2003144268 A JP 2003144268A JP 2003144268 A JP2003144268 A JP 2003144268A JP 2004348397 A JP2004348397 A JP 2004348397A
- Authority
- JP
- Japan
- Prior art keywords
- service unit
- application software
- interface
- data
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】サービス部を利用してデータ参照を行うアプリケーションソフトウェアの開発効率を上げること。
【解決手段】仮想サービス部がインターフェースを介してアプリケーションソフトウェアからの引用、検索、登録等の要求をうけ、その要求に応じて各サービス部との間でそれら各サービス部が備えるインターフェースを介して実際の引用、検索、登録等のやりとりを行い、アプリケーションソフトウェアと各サービス部とが、前記仮想サービス部を介して間接的に引用、検索、登録等のやりとりを行うことを特徴とする。
【選択図】 図２
【解決手段】仮想サービス部がインターフェースを介してアプリケーションソフトウェアからの引用、検索、登録等の要求をうけ、その要求に応じて各サービス部との間でそれら各サービス部が備えるインターフェースを介して実際の引用、検索、登録等のやりとりを行い、アプリケーションソフトウェアと各サービス部とが、前記仮想サービス部を介して間接的に引用、検索、登録等のやりとりを行うことを特徴とする。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明は、本発明はファクシミリ装置、プリンタ装置、スキャナ装置、複写装置や、それら各装置の機能を複合的に備えたいわゆる複合機等に好適な、アプリケーションソフトウェアとサービス部とのインターフェース方法に関する。
【０００２】
【従来の技術】
複合機に適用されるアプリケーションソフトウェアを例にとると、ファクシミリ通信機能、プリンタ機能、スキャナ機能、複写機能、ＬＡＮ等を介したネットワーク通信等の、システムの多くの機能を実現するする必要があるため、それらの機能を実現するための各種アプリケーションソフトウェア（以後アプリケーションと略称）が必要となる。
【０００３】
アプリケーションの開発者側から見れば、特定の機種の複合機について複数のアプリケーション（アプリケーション群）を開発して装置に組み込む必要があるということになる。
【０００４】
最近では、構造化手法やオブジェクト手法の採用により機種が異なっても変更する必要のない固定部をアプリケーション群ができるだけ多く含むように配慮して開発することにより開発者の小人数化や開発納期短縮が求められている。
【０００５】
そのため、アプリケーション群の開発においては、アプリケーション群を構成する各アプリケーションが、他のアプリケーションとは関連を持たないように配慮して開発を行い、各アプリケーションの互いの独立性を高め、一部のアプリケーションの変更の影響が他のアプリケーションに及ばないよう（変更する必要が生じないよう）にして、特定機種における機能変更や、複数機種の複合機への共通のアプリケーション群の適用に柔軟に対応できるようにするのが一般的である。
【０００６】
また、アプリケーション群を構成する各アプリケーションは、その動作に関連して各種データ群により構成されるシステムデータ群を参照する必要がある。
【０００７】
そのため、例えば、ファクシミリ通信の履歴が登録された通信管理テーブルのデータを引用したり、新たなデータを登録したり、検索したりする場合、アプリケーションが通信管理テーブルを直接参照しなければならないとすると、通信管理テーブルの具体的な格納場所やデータ構造をアプリケーション（の開発者）が知っている必要がある。
【０００８】
アプリケーション群を構成する各アプリケーションは、機種が異なっても流用されるものもあるが、一般的には新たな機種が開発される際に新たに作成する必要がある。具体的には、例えば、ファクス機能を実現するためのアプリケーションは、各機種のファクス機能のそれぞれについて作成する必要がある。
【０００９】
もし仮に、各アプリケーションが、システムデータを直接参照しなればならないとすると、そのようにして新たに開発される各アプリケーション（の開発者）は、システムデータ群の全体構成や、自身が利用するデータ群について熟知しなければならない。しかし、それではあまりにも開発効率がよくない。
【００１０】
このため、近年、アプリケーション群を構成する各アプリケーションが、システムデータ群を構成する各種データ群を、引用、登録、検索などのために直接参照するのではなく、それら各種データ群の引用、登録、検索などの機能をサービス部群としてアプリケーション群から独立させ、その独立させたサービス部群を構成する各サービス部を、アプリケーション群を構成する各アプリケーションが必要に応じて利用するようにすることで、アプリケーション（の開発者）がシステムデータ群の具体的な構成についての知識なしに、システムデータ群を参照できるようにしている。
【００１１】
アプリケーションがサービス部を利用できるようにするために、各サービス部には、データ入出力（読み出し・書込み・検索など）のためのＩ／Ｆ（インターフェイス）が予め定義される。
【００１２】
そして、アプリケーションの開発者は、参照したいデータ群についての入出力のサービスを提供するサービス部（複数の場合もある）について予め定義されているインターフェースの仕様を理解して設計・開発を行うことになる。
【００１３】
一般にサービス部群は、例えば複合機の一連の製品群を構成する複数の機種に共通で利用される前提で考慮され、設計・開発される。そして、ある機種で仕様追加が発生したとしても、追加部分に修正を加えれば利用する複数機種への対応は容易にできる。
【００１４】
一方、アプリケーション開発は機種単位に行われるため、アプリケーションの開発者は複数のサービス部のインターフェース仕様を理解しなければならないだけでなく、自分が設計しているアプリケーションにとって、どれとどれのサービス部のインターフェースのうちのどの部分を利用すべきかなどについても把握する必要がある。そのため、複数の機種の開発を並行して行う場合などに開発効率が低下が顕著であるという問題があった。
【００１５】
図１２に、上記従来のアプリケーション群、サービス部群、及び、システムデータ群のインターフェース形態について示す。
【００１６】
同図において、システムデータ群７０は、装置動作に関連してメモリに記憶しておく必要がある、データ群７０ａ、７０ｂ、７０ｃなどの各種データの集まりである。そのシステムデータ群７０を構成する各データ群は、最終的には、アプリケーション群５０を構成する各アプリケーションにより利用されるものであるが、サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部を介して、アプリケーション群５０を構成する、アプリケーション５０ａ、５０ｂ、…、５０ｎなどにより、引用、登録、検索などのために間接的に参照される。
【００１７】
サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部には、それぞれ、インターフェース６０ａａ、６０ｂａ、６０ｃａ、…、６０ｍａなどの、各サービス部単位に、アプリケーション群５０を構成するアプリケーションに対して提供されるインターフェースが定義されている。各サービス部のインターフェースは単一のインターフェースではなく、様々な形態の引用、登録、検索などに対応するための複数種別のインターフェースの複合したものとして構成される場合もあり、アプリケーション群５０を構成するアプリケーション（の開発者）は、その詳細な仕様を予め熟知している必要がある。
【００１８】
なお、システムデータ群７０が各データ群に分けられているのは、サービス部群６０を構成する各サービス部単位に使うデータが決まっていることを反映している。また、システムデータ群７０を構成する各データ群の中には、複数のサービス部から参照されるデータもあり、また、データの参照形態も、引用、登録、検索などのための、読み出し、書き込み、読み書きの３形態あり、各データ群の性質に応じて参照形態も異なる。図１２には、その様が矢印で示されている。
【００１９】
複合機を例にとると、多数の宛先情報を管理する電話帳のデータ群（を参照するためのサービス部）は、ネットワークアプリケーションでもファクスアプリケーションでも利用される。ただ、Ｇ３ファクシミリ通信時に相手先装置に対して被呼端末識別信号ＣＳＩとして通知する自機のファクス番号のように、ファクスアプリケーションのみが参照するデータもある。
【００２０】
図１２において、アプリケーション５０ｂ（の開発者）は、データ群７０ａ、７０ｂ及び７０ｃを参照するために、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｂのＩ／Ｆ６０ｃａの仕様を理解する必要がある。
【００２１】
しかし、データ群７０ａ、７０ｂ及び７０ｃの参照の態様に応じて、Ｉ／Ｆ６０ａａ、６０ｂａ、及び、６０ｃａの仕様書の中には、利用すべきものとそうでないものとが混在していて、その取捨選択の巧拙は、開発者のスキルに依存する部分が大きく開発効率に大きく影響する。
【００２２】
特許文献１には、アプリケーションソフトウェアとサービスソフトウェアとが、それぞれ、ユーザページの状態を参照しながら、動作また処理するようにすることで、アプリケーションソフトウェアとサービスソフトウェアの相互依存性をなくし、それにより、ソフトウェアの再利用率の向上を図った「ソフトウェア間のインターフェース方法」が開示されいる。
【００２３】
【特許文献１】
特開２００１−０１６３９５号公報
【００２４】
【発明が解決しようとする課題】
しかし、上記特許文献１記載の従来技術は、ネットワークを介した情報共有、つまり、グループウェアを意識した技術であり、アプリケーションソフトウェアがサービス部利用を利用してデータを参照するインターフェース形態に単純に適用することはできない。
【００２５】
本発明は係る事情に鑑みてなされたものであり、サービス部を利用してデータ参照を行うアプリケーションソフトウェアの開発効率を上げることができる、アプリケーションソフトウェアとサービス部とのインターフェース方法を提供することを目的とする。
【００２６】
【課題を解決するための手段】
請求項１に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、システムの特定の機能に対応するアプリケーションソフトウェアが、所定仕様のインターフェースをそれぞれ備えた１または複数のサービス部とデータの引用、検索、登録等のやりとりを行うアプリケーションソフトウェアとサービス部とのインターフェース方法において、特定のアプリケーションソフトウェアに関連する各サービス部のインターフェースのうちの、当該特定のアプリケーションソフトウェアにおいて必要とされるデータに関連する部分のインターフェースのみを抜粋して、その抜粋したインターフェースの仕様を明確化した仮想サービス部を、当該特定のアプリケーションソフトウェアと、それと関連する各サービス部との間に介在させ、当該仮想サービス部がインターフェースを介して当該特定のアプリケーションソフトウェアからの引用、検索、登録等の要求をうけ、その要求に応じて当該特定のアプリケーションソフトウェアに関連する各サービス部との間でそれら各サービス部が備えるインターフェースを介して実際の引用、検索、登録等のやりとりを行うことで、当該特定のアプリケーションソフトウェアと、それに関連する各サービス部とが、前記仮想サービス部を介して間接的に引用、検索、登録等のやりとりを行うことを特徴とする。
【００２７】
請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項１に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記仮想サービス部が備える、前記特定のアプリケーションソフトウェアに対するインターフェースを、前記特定のアプリケーションソフトウェアが自身に都合よく決めた仕様とすると共に、前記仮想サービス部は、前記特定のアプリケーションソフトウェアからの要求を解析して、前記特定のアプリケーションソフトウェアに関連する各サービス部のインターフェースに置換することを特徴とする。
【００２８】
請求項３に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記仮想サービス部を、複数のアプリケーションソフトウェアのうちの、単独で開発したいアプリケーションソフトウェアのそれぞれについて、各アプリケーションソフトウェアと、それら各アプリケーションソフトウェアと関連する各サービス部との間に介在させることを特徴とする。
【００２９】
請求項４に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記仮想サービス部はキャッシュメモリを備え、アプリケーションソフトウェアからのインターフェースを介したデータ引用要求の処理時に、当該データ引用要求に該当するデータが前記キャッシュメモリに格納されていない場合には、当該データ引用要求に相当するサービス部のインターフェースから得られるデータを前記キャッシュメモリに格納すると共に格納履歴を保持した上で、当該得られたデータを要求元のアプリケーションソフトウェア所望の形式に置換して通知する一方、当該データ引用要求に該当するデータが既に前記キャッシュメモリに格納されている場合には、当該キャッシュメモリに格納されているデータを、要求元のアプリケーションソフトウェア所望の形式に置換して通知することを特徴とする。
【００３０】
請求項５に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項４に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記キャッシュメモリを備えた仮想サービス部を、複数のアプリケーションソフトウェアのうちの、単独で開発したいアプリケーションソフトウェアのそれぞれについて、各アプリケーションソフトウェアと、それら各アプリケーションソフトウェアと関連する各サービス部との間に介在させることを特徴とする。
【００３１】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を詳細に説明する。
【００３２】
先ず、図１に、本発明の実施の形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法が適用される複合機１のブロック構成について示す。
【００３３】
同図において、複合機１は、システム制御部２、ＲＯＭ３、ＲＡＭ４、操作表示部５、スキャナ６、プロッタ７、プロッタ制御部８、パラメータメモリ９、ページメモリ１０、符号化復号化部１１、通信制御部１２、モデム１３、網制御部１４、ＬＡＮ通信制御部１５、及び、システムバス１６により構成されている。
【００３４】
システム制御部２は、ＲＯＭ３に書き込まれた制御プログラムに従って、ＲＡＭ４を作業領域として使用しながら、装置各部を制御するマイクロコンピュータである。
【００３５】
ＲＯＭ３は、前述したように、システム制御部２が上記装置各部を制御するための制御プログラムや、各種システムデータのうちの固定的なデータが記憶されているリードオンリメモリである。ＲＡＭ４は、前述したようにシステム制御部２の作業領域として使用されるランダムアクセスメモリであり、システムデータのうちの内容の変更や追加のある一時的なデータも記憶する。
【００３６】
操作表示部５は宛先電話番号を指定するためのテンキー、送信スタートキー、ワンタッチダイヤルキー等の各種キーが配設される一方、液晶表示装置等の表示器を備え、ユーザに知らせるべき装置の動作状態や、各種メッセージを表示するものである。
【００３７】
スキャナ６は、３．８５本／ｍｍ、７．７本／ｍｍ、１５．４本／ｍｍ、２００ｄｐｉ、４００ｄｐｉ等の所定の読み取り線密度で原稿画像を読み取って、画像データを得るためのものである。プロッタ７は、画像データを記録紙上に印刷形成するためのものである。プロッタ制御部８は、プロッタ７を制御して画像データの記録紙への印刷を制御するものである。なお、プロッタ７により印刷される画像データとしては、スキャナ６により読み取られた画像データ（コピー機能）、ファクシミリ受信された画像データ（ファクシミリ機能）、ＬＡＮ３０を介してＰＣ４０等から転送されてきた画像データ（プリンタ機能）や、各種レポートの画像データなどがある。
【００３８】
パラメータメモリ９は、システムデータのうちの、変更、追加のあるデータであって、電源遮断時にも保持する必要のあるデータ、具体的には、送信宛先が多数登録された電話帳データ、通信管理テーブルのデータ等を記憶するためのメモリであり、具体的には、バッテリバックアップされたＳＲＡＭや、ＥＥＰＲＯＭ（電気的に書き換え可能な読み出し専用メモリ）等により構成されるものである。
【００３９】
ページメモリ１０は、プロッタ７により記録紙に印刷される画像データをビットマップ状態で展開するためのメモリである。
【００４０】
符号化復号化部１１は、送信画像データを、Ｇ３ファクシミリに適合する、ＭＨ符号化方式、ＭＲ符号化方式、ＭＭＲ符号化方式等の所定の符号化方式で符号化圧縮する一方、受信画情報をＭＨ符号化方式、ＭＲ符号化方式、ＭＭＲ符号化方式等に対応する所定の復号化方式で復号伸長するものである。
【００４１】
通信制御部１２は、モデム１３及び網制御部１４を制御して回線２０を介した相手装置との間のＧ３ファクシミリ通信を制御するものである。モデム１３は、ファクシミリモデム機能を備え、網制御部１４を介して、回線２０に送信するデータを変調する一方、網制御部１４を介して回線２０から受信した信号を復調するものであり、伝送手順信号をやりとりするための低速モデム機能（Ｖ．２１モデム）、および、おもに画像データをやりとりするための高速モデム機能である、Ｖ．１７、Ｖ．３３、Ｖ．３４、Ｖ．２９、Ｖ．２７ｔｅｒの各モデム機能を備えている。モデム１３は、ダイヤル番号に対応したＤＴＭＦ信号の送出も行う。
【００４２】
網制御部１４は、回線２０に接続されて、回線の直流ループの閉結・解放や、回線の極性反転の検出、回線解放の検出、発信音の検出、ビジートーン等のトーン信号の検出、呼出信号の検出等の回線との接続制御や、ダイヤルパルスの生成を行うものであり、また、自動発着信機能も備えている。また、回線２０からの受信信号Ｒは、網制御部１４を介してモデム１３に入力され、モデム１３からの送信信号Ｔは、網制御部１４を介して回線２０に出力される。
【００４３】
ＬＡＮ通信制御部１５は、ＬＡＮ４０に接続され、ＬＡＮプロトコル上でのＴＣＰ／ＩＰプロトコル制御等を行い、ＬＡＮ４０に接続されたＰＣ（パーソナルコンピュータ）６０等の他装置からの文書ファイルの転送を受けるためのものである。システムバス１６は、アドレスバス、データバス、制御バス、割り込み制御信号ライン等により構成され、上記各部がデータをやり取りするための信号ラインである。
【００４４】
以上のように構成される複合機１において、システム制御部２は、複合機としての機能を実現するための、ファクス機能、複写機能、プリンタ機能、ネットワーク通信機能等の各種機能にそれぞれ対応したアプリケーションソフトウェアのプログラムや、それらのアプリケーションソフトウェアと、ＲＯＭ３、ＲＡＭ４，パラメータメモリ９等に記憶される各種システムデータ群との間に介在する、サービス部に相当するソフトウェアのプログラムを実行する。
【００４５】
以下、複合機１に適用される、アプリケーションソフトウェアとサービス部とのインターフェース方法の第１ないし第４実施形態について、順に説明する。
【００４６】
先ず、第１実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について説明する。
【００４７】
図２は、第１実施形態に係るインターフェース方法について示すブロック図である。図２に示す構成は、従来技術の説明において参照した、図１２に示す構成と一部を除いて同一である。同一でない点は、特定のアプリケーションソフトウェアとしてのアプリケーション５０ｂが、直接、サービス部６０ａ、６０ｂ及び６０ｃを利用するのではなく、仮想サービス部８０を介してそれらのサービス部を利用するようにしている点である。
【００４８】
同２において、システムデータ群７０は、装置動作関連して、ＲＯＭ３、ＲＡＭ４、パラメータメモリ９等のメモリに記憶しておく必要がある、データ群７０ａ、７０ｂ、７０ｃなどの各種データの集まりである。そのシステムデータ群７０を構成する各データ群は、最終的には、アプリケーション群５０を構成する各アプリケーションにより利用されるものであるが、各データ群への直接のアクセスは、サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部が行う。
【００４９】
サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部には、それぞれ、インターフェース６０ａａ、６０ｂａ、６０ｃａ、…、６０ｍａなどの、各サービス部単位に、利用する側（仮想サービス部８０、アプリケーション群５０を構成するアプリケーション）対して提供されるインターフェースが定義されている。各サービス部のインターフェースは単一のインターフェースではなく、様々な形態の引用、登録、検索などに対応するための複数種別のインターフェースの複合したものとして構成される場合もある。
【００５０】
なお、システムデータ群７０が各データ群に分けられているのは、サービス部群６０を構成する各サービス部単位に使うデータが決まっていることを反映している。また、システムデータ群７０を構成する各データ群の中には、複数のサービス部から参照されるデータもあり、また、データの参照形態も、引用、登録、検索などのための、「読み出し」、「書き込み」、「読み書き」の３形態あり、各データ群の性質に応じて参照形態も異なる。
【００５１】
サービス部６０ａは、データ群７０ａを「読み書き」する。サービス部６０ｂは、データ群７０ｂを「読み書き」すると共にデータ群７０ｃを「書き込み」する。サービス部６０ｃは、データ群７０ｃを「読み書き」する。サービス部６０ｍａは、データ群８０ｃを「読み出し」する。
【００５２】
アプリケーション群５０を構成する各アプリケーションのうち、アプリケーション５０ａは、インターフェース６０ａａを介してサービス部６０ａを利用する。アプリケーション５０ｎは、インターフェース６０ｍａを介してサービス部６０ｍを利用する。
【００５３】
そして、アプリケーション５０ｂは、サービス部６０ａ、６０ｂ、６０ｃの３つのサービス部を利用するが、その利用は、仮想サービス部８０を介して間接的に行う。
【００５４】
アプリケーション５０ｂ（の開発者）は、データ群７０ａ、７０ｂ及び７０ｃを参照するために、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｂのＩ／Ｆ６０ｃａの各仕様の詳細を理解する必要はなく、仮想サービス部８０のインターフェース８０ａの仕様のみを理解すれば足りる。
【００５５】
従来、データ群７０ａ、７０ｂ及び７０ｃの参照の態様に応じて、Ｉ／Ｆ６０ａａ、６０ｂａ、及び、６０ｃａの仕様書の中には、利用すべきものとそうでないものとが混在していて、その取捨選択の巧拙は、開発者のスキルに依存する部分が大きかったが、仮想サービス部８０を介することで、アプリケーション５０ｂにより実現される機能（ファクス機能など）に関して必要にして十分なインターフェース仕様を理解するのみで、アプリケーション５０ｂを開発することが可能となる。
【００５６】
なお、仮想サービス部８０のインターフェース８０ａは、アプリケーション５０ｂ側の都合ではなく、仮想サービス部８０の開発に都合がよいように（サービス部都合）、開発される。
【００５７】
図６に、仮想サービス部８０が行う、アプリケーション５０ｂと、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｃのＩ／Ｆ６０ｃａとのインターフェース形態について示す。
【００５８】
同図において、サービス部６０ａの提供するＩ／Ｆ６０ａａは、Ａ１ないしＡｎの各種インターフェースの集合として構成されている。サービス部６０ｂの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。サービス部６０ｃの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。
【００５９】
仮想サービス部８０において、Ａ１ないしＡｎ、Ｂ１ないしＢｎ、及び、Ｃ１ないしＣｎのすべてのインターフェースを管理することも考えられるが、仮想サービス部８０は、アプリケーション５０ｂのためのものであるため、アプリケーション５０ｂが利用するインターフェースのみを管理できればよい。
【００６０】
アプリケーション５０ｂが利用したいインターフェースは、インターフェース６０ａａのインターフェース（Ａ１）及び（Ａ２）、インターフェース６０ｂａのインターフェース（Ｂ１）、（Ｂ２）及び（Ｂ３）、並びに、インターフェース６０ｃａのインターフェース（Ｃ１）のみであるため、それらの対応する必要のあるインターフェースのみを管理する。
【００６１】
そして、それらの対応する必要のあるインターフェースのみを、インターフェース８０ａを構成するインターフェースＳ１ないしＳ６と、１対１に対応させてアプリケーション５０ｂに公開する。
【００６２】
それにより、例えば、ある新機種の特定の機能、例えばファクス機能に対応するアプリケーション５０ｂの開発担当者は、必要にして十分な、無駄のないインターフェース仕様のみを理解すれば開発・設計を行えるようになる。また、仮想サービス部８０はサービス部６０ａなどと同様に、複数の機種開発が同時に発生してもあまり影響を受けず機種が異なっても流用できる場合が多いため、開発負担は小さい。また、インターフェース８０ａを構成する各インターフェース（Ｓ１ないしＳ６）は、それぞれ、Ｉ／Ｆ６０ａａ、６０ｂａ、６０ｃａ、の一部として既存のものであるため、それを流用すればよく、新規に開発する必要のある部分がその分少なくて済む。
【００６３】
以上、第１実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について説明したが、サービス部のインターフェースの特徴について考えてみると、そのインターフェースは、参照するシステムデータにより決定されることが多く、アプリケーション側に都合のよい形式とは異なる場合が多い。
【００６４】
具体的には、ある特定のシステムデータを１６進数の６４（１０進数の１００）と管理している場合、サービス部は読み出したまま利用するほうが、変換の手間が省けるため楽であり、また、その特定のシステムデータをアプリケーションが内部的に利用する場合は問題無いことが多い。
【００６５】
しかし、アプリケーションがその特定のシステムデータを表示したり印刷する場合には、１バイトの数字としての６４（１６進数）を「１００」の文字列に相当する文字コード列に変換する必要があり、アプリケーション（の開発者）側でその変換処理まで考慮しなければならないのは大きな負担となる。
【００６６】
その点を考慮したのが、第２、第３の実施形態に係るインターフェース方法である。
【００６７】
先ず、第２実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について図３を参照して説明する。なお、第２実施形態に係る図３に示すインターフェース方法と、図２に示した第１実施形態に係るインターフェース方法とで異なる点は、図２における仮想サービス部８０に代えて、図３においては、仮想サービス部８１ａを備えている点である。
【００６８】
図３において、アプリケーション開発の効率化を考える場合、アプリケーションに都合のよい（アプリケーション側の負担を軽減できる）インターフェースであるべき点に鑑みて、特定のアプリケーションソフトウェアとしてのアプリケーション５０ｂ用の仮想サービス部８１を設けると共に、そのインターフェース８１ａを、アプリケーション５０ｂ（の開発者）が自身に都合がよいように決定した仕様としている。
【００６９】
図７に、仮想サービス部８１が行う、アプリケーション５０ｂと、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｃのＩ／Ｆ６０ｃａとのインターフェース形態について示す。
【００７０】
同図において、サービス部６０ａの提供するＩ／Ｆ６０ａａは、Ａ１ないしＡｎの各種インターフェースの集合として構成されている。サービス部６０ｂの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。サービス部６０ｃの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。
【００７１】
仮想サービス部８１において、Ａ１ないしＡｎ、Ｂ１ないしＢｎ、及び、Ｃ１ないしＣｎのすべてのインターフェースを管理することも考えられるが、仮想サービス部８１は、アプリケーション５０ｂのためのものであるため、アプリケーション５０ｂが利用するインターフェースのみを管理できればよい。
【００７２】
アプリケーション５０ｂが利用したいインターフェースは、インターフェース６０ａａのインターフェース（Ａ１）及び（Ａ２）、インターフェース６０ｂａのインターフェース（Ｂ１）、（Ｂ２）及び（Ｂ３）、並びに、インターフェース６０ｃａのインターフェース（Ｃ１）のみであるため、それらの対応する必要のあるインターフェースのみを管理する。
【００７３】
そして、それらの対応する必要のあるインターフェースのみを、インターフェース８１ａを介してアプリケーション５０ｂに公開する。
【００７４】
その場合、インターフェース８１ａは、アプリケーション５０ｂに都合のよい仕様とされる。また、仮想サービス部８１には、Ａ１、Ａ２、Ｂ１、Ｂ２、Ｂ３及びＣ１の各インターフェースと、アプリケーション都合のインターフェース８１ａとを相互に変換する機能を持たせる。
【００７５】
このように、仮想サービス部８１に、各サービス部のインターフェースと、アプリケーション５０ｂから利用される場合のインターフェースとの変換機能を持たせることにより、各サービス部（の開発者）もアプリケーション５０ｂ（の開発者）も自身に都合のよいインターフェース仕様を定義することができる（特にアプリケーション５０ｂにおいて）。
【００７６】
それにより、無理・無駄がなくなり開発効果があがる。また、各サービス部とアプリケーション５０ｂとの直接の関連がなくなることになるため、独立した開発がしやすくなる。
【００７７】
また仮想サービス部８１自体はインターフェースの相互変換以外の機能を持たせないことで簡素化できる。また、仮想サービス部８１（の開発者）は、アプリケーション５０ｂと、各サービス部との両方の仕様を把握しているため、不具合解析なども容易となる。また、仮想サービス部８１は、機能追加など変更要因もあるが流用度も高くモジュール化しやすい利点がある。
【００７８】
次に、第３実施形態に係るインターフェース方法について、図４を参照して説明する。
【００７９】
同図において、図３に示した第２実施形態に係るインターフェース方法と異なる点は、特定のアプリケーションソフトウェアとしてのアプリケーション５０ｂについてのみ設けていた仮想サービス部８１を、アプリケーション５１ａ（仮想サービス部８２）やアプリケーション５０ｎ（仮想サービス部８３）などのアプリケーション群５０を構成するアプリケーションの全てについて設けた点である。
【００８０】
それにより、システム開発のいっそうの効率化が可能となる。なお、アプリケーション群５０を構成する全アプリケーションについてではなく、アプリケーション群５０を構成する各アプリケーションのうちの、機種毎に変更の発生する可能性の高いアプリケーションについてのみ、仮想サービス部をサービス部との間に介在させてもよく、また、データ交換の必要なアプリケーションについてのみ、仮想サービス部をサービス部との間に介在させてもよく、どのアプリケーションについて仮想サービス部を設けるかは、それを設けることによりもたらされる開発の効率化の程度を評価することで決めることができる。
【００８１】
次に、第４実施形態に係るインターフェース方法について、図５を参照して説明する。図５に示す第４実施形態に係るインターフェース方法は、図３に示した第２実施形態に係るインターフェース方法の変形例であり、仮想サービスブ８１が、キャッシュメモリ８１ｂを備えている点が異なる。
【００８２】
サービス部群６０を構成する各サービス部と、アプリケーション群５０を構成するのアプリケーションとのインターフェースは、１対１でないことが多い。具体的には、図７に示したように、アプリケーション５０ｂがサービス部６０ａを利用する場合インターフェース６０ａａを構成するＡ１ないしＡｎのインターフェースのうちのインターフェースＡ１及びＡ２のみを利用する。
【００８３】
また、サービス部が提供するインターフェースは、通常複数のインターフェースにより構成されるが、１のインターフェースで扱われるデータが１つとはならないことが多い。
【００８４】
具体的には、例えば、アプリケーション５０ｂからみて、従来は、ｄａｔａ１、ｄａｔａ２、ｄａｔａ３の各データが必要な場合はインターフェースＡ１を利用していて、ＤＡＴ１、ＤＡＴ２、ＤＡＴ３、ＤＡＴ４の各データが必要な場合にはインターフェースＡ２を利用しているような場合である。
【００８５】
そのような場合、ｄａｔａ１、２、３やＤＡＴ１、２、３、４は必ずしもアプリケーション５０ｂからみて一度に必要とはならない。それにもかかわらず、従来は、ｄａｔａ１、ｄａｔａ２、ｄａｔａ３を異なるタイミングでアプリケーション５０ｂが必要とする場合は、インターフェースＡ１をその都度実行する必要があった。一方、インターフェースＡ１の中でｄａｔａ１、ｄａｔａ２、ｄａｔａ３の各データに対応するシステムデータＳｄａｔａ１、Ｓｄａｔａ２、及び、Ｓｄａｔａ３は一括して一度に取得する場合も多い。その結果、システム負荷が増大していた。
【００８６】
そこで、この第４実施形態に係るインターフェース方法では、図５に示すように、仮想サービス部８１にキャッシュメモリ８１ｂを持たせている。キャッシュメモリ８１ｂは、具体的には、それ用に確保されたＲＡＭ４の一部記憶領域である。
【００８７】
そして、ｄａｔａ１、ｄａｔａ２、ｄａｔａ３のいずれか１つが最初に引用された場合に、仮想データ部８１ｂは、サービス部６０ａのインターフェース６０ａａの一部であるインターフェースＡ１利用して一括して取得される、Ｓｄａｔａ１、Ｓｄａｔａ２、及び、Ｓｄａｔａ３をキャッシュメモリ８１ｂに格納する。
【００８８】
仮想サービス部８１ｂにおいて、もし、インターフェース８１ａに対するアプリケーション５０ｂからの要求が、ｄａｔａ１の要求であった場合には、Ｓｄａｔａ１をインターフェース８１ａの仕様にあわせたｄａｔａ１に置換して渡すようにすればよい。
【００８９】
次にｄａｔａ２やｄａｔａ３、更には再度ｄａｔａ１のアプリケーション５０ｂからの引用が、インターフェース８１ａを介してあった場合もキャッシュメモリ８１ｂ内のＳｄａｔａ１、２、または、３を必要に応じて置換してアプリケーション５０ｂに渡せばよい。
【００９０】
それにより、サービス部の負荷が低減できる（特にシステムデータの引用を行う部分）。また、アプリケーション５０ｂとしても、必要なときに必要なデータのみ取得できるため、得たデータの取捨選択が不要となり処理の効率化を図ることができる。
【００９１】
仮想サービス部８１にけるキャッシュメモリ８１ｂを用いた、アプリケーション５０ｂからの要求に応じて行う、サービス処理手順について、図８ないし図１１を参照して説明する。
【００９２】
先ず、図８において、アプリケーション５０ｂからの要求をインターフェース８１ａから受けると、その要求の種別が、「引用」、「登録」、または、「検索」のいずれであるかを判定する（処理Ｓ１０１）。
【００９３】
判断Ｓ１０２においては、処理Ｓ１０１における判定結果が、「引用」の場合には、「引用対応処理」を行い（処理Ｓ１０４）、「登録」の場合には、「登録対応処理」を行い（処理Ｓ１０３）、「検索」の場合には、「検索対応処理」を行う（処理Ｓ１０５）。
【００９４】
図９に、処理Ｓ１０３の「登録対応処理」の具体的な処理手順に付いて示す。
【００９５】
同図において、先ず、該当するサービスを判断し（処理Ｓ２０１）、要求と共にアプリケーション５０ｂから渡された登録要求に係るデータを、システムデータとして登録される形式に置換する（処理Ｓ２０２）。
【００９６】
そして、その該当するサービスに係るデータがキャッシュメモリ８１ｂに格納済みであるか否かを示すキャッシュ履歴を確認して、キャッシュ履歴がある場合には（判断Ｓ２０３のＹｅｓ）、システムデータとしてこれから登録されようとするデータの内容とキャッシュメモリ８１ｂとの整合性がとれなくなるのを防止するために、キャッシュ履歴をリセットした上で（処理Ｓ２０３）、処理Ｓ２０５に移行する。キャッシュ履歴がない場合には（判断Ｓ２０３のＮｏ）、直接、処理Ｓ２０５に移行する。
【００９７】
処理Ｓ２０５では、処理Ｓ２０１で特定した、該当する登録のサービスを実行する（処理Ｓ２０５）。それにより、アプリケーション５０ｂからの登録要求に係るデータがシステムデータとして登録される。処理Ｓ２０５の後は、その処理結果をアプリケーション５０ｂに通知して（処理Ｓ２０６）、「登録対応処理」を完了する。
【００９８】
なお、場合によっては登録時にキャッシュ履歴がある場合（判断２０３のＹｅｓ）に、キャッシュメモリ８１ｂの内容を登録要求されたデータに置換するようにして、システムデータとして登録されるデータとキャッシュメモリ８１１ｂに保持されるデータとの整合性を確保するようにすれば、キャッシュ履歴をリセットする必要はない。そのようにすることで、次回の引用時におけるサービス部へのアクセスがなくなり、その分サービス部の負荷を軽減できる。
【００９９】
次に、図８の処理Ｓ１０４の「引用対応処理」の具体的な処理手順について図１０を参照して説明する。
【０１００】
図１０において、先ず、該当するサービスを判断した上で（処理Ｓ３０１）、その該当するサービスに係るデータがキャッシュメモリ８１ｂに格納済みであるか否かを示すキャッシュ履歴を確認して、キャッシュ履歴がない場合には（判断Ｓ３０２のＮｏ）、処理Ｓ３０１で特定した、該当する引用のサービスを実行する（処理Ｓ３０３）。それにより、アプリケーション５０ｂからの引用要求に係るシステムデータが読み出される。
【０１０１】
その読み出された引用要求に係るシステムデータは、キャッシュ履歴にセットされると共に（処理Ｓ３０４）、キャッシュメモリ８１ｂへ格納される（処理Ｓ３０５）。
【０１０２】
それにより、引用されたシステムデータや、そのデータと関連する一連のデータがキャッシュメモリ８１ｂに残ることになるため、次回の引用要求時には、サービス部に負荷かけることなく、その引用要求に迅速に応じることができる。
【０１０３】
処理Ｓ３０５の後、または、判断３０２においてキャッシュ履歴が既にある場合には（判断Ｓ３０２のＹｅｓ）、キャッシュメモリ８１ｂに格納されている、引用要求されたデータをアプリケーション５０ｂに渡すための形式に置換し（処理Ｓ３０６）、アプリケーション５０ｂにそのデータを通知して（処理Ｓ３０７）、「引用対応処理」を完了する。
【０１０４】
なお、処理Ｓ３０６及び処理Ｓ３０７が判断３０２のＹｅｓに引き続いて行われる場合、前回の引用処理時にキャッシュメモリ８１ｂに格納されたシステムデータがそのまま使用できるため、サービス部に負荷をかけることなく、引用要求に迅速に応じることができる。
【０１０５】
次に、図８の処理Ｓ１０５の「検索対応処理」の具体的な処理手順について図１１を参照して説明する。
【０１０６】
図１１において、先ず、該当するサービスを判断し（判断Ｓ４０１）、その該当する検索のサービスを実行し（処理Ｓ４０２）、その実行結果をアプリケーション５０ｂに通知する。
【０１０７】
処理Ｓ４０２の検索のサービスの実行の結果得られるのは、データそのものではなく、データの有無や位置の情報であるため、キャッシュメモリ８１ｂに格納していないが、キャッシュメモリ８１ｂに検索結果を格納しておき、次回に同一の検索条件がアプリケーション５０ｂから与えられた場合に、キャッシュメモリ８１ｂに格納しておいた検索結果を返すようにすることで、サービス部を負荷をかけることなく、検索の要求に応じることができる。もっとも、その場合、「登録対応処理」でシステムデータの内容に変更が生じた場合には、キャッシュメモリ８１ｂに格納された検索結果をクリアする必要が生じる場合もある。
【０１０８】
また、以上説明した第４実施形態は、図３に示した第２実施形態に係る仮想サービス部８１にキャッシュメモリ８１ｂを持たせたものであったが、図４に示した第３実施形態に係る、各アプリケーションごとに設けられた仮想サービス部８１、８２、８３等の全ての仮想サービス部のそれぞれにキャッシュメモリ８１ｂ持たせて、各仮想サービス部において、図８ないし図１１に示したサービス処理手順を行うようにしてもよく、その場合、各仮想サービス部において利用されるサービス部の処理負荷の軽減と、対応するアプリケーションからの要求に対する迅速な応答が可能となる。
【０１０９】
その場合、全ての仮想サービス部にキャッシュメモリを持たせるのではなく、利用頻度の高い仮想サービス部のみにキャッシュメモリを持たせるようにしてもよい。また、キャッシュメモリを備えた仮想サービス部を全てのアプリケーションに対応して設けるのではなく、アプリケーション群５０を構成する各アプリケーションのうちの、機種毎に変更の発生する可能性の高いアプリケーションについてのみ、キャッシュメモリを備えた仮想サービス部をサービス部との間に介在させてもよく、また、データ交換の必要なアプリケーションについてのみ、キャッシュメモリを備えた仮想サービス部をサービス部との間に介在させてもよく、どのアプリケーションについてキャッシュメモリを備えた仮想サービス部を設けるかは、それを設けることによりもたらされる開発の効率化の程度を評価することで決めることができる。
【０１１０】
なお、以上説明した実施の形態では、サービス部群６０を構成する各サービス部は、システムデータへの参照サービスを提供するソフトウェアとしたが、サービス部は、アプリケーションに対してデータ参照サービスを提供するものであれば、ハードウェアにより構成されたものであってもよいのはいうまでない。
【０１１１】
また、本発明は、複合機のシステムに限らず、複数のアプリケーションソフトウェアとがデータ参照サービスを提供するサービス部を利用するものであれば、同様に適用可能なものである。
【０１１２】
【発明の効果】
請求項１に係る発明によれば、特定のアプリケーションソフトウェアを開発する際、そのアプリケーションソフトウェアが利用する１つ以上のサービス部が提供するインターフェースの中の有為なインターフェースのみ、つまり、仮想サービス部のインターフェース仕様のみを意識してアプリケーション開発を行えるようになるため、開発効率の向上を図ることが可能となる効果が得られる。
【０１１３】
請求項２に係る発明によれば、前記特定のアプリケーションが関連する各サービス部のインターフェースの仕様を知ることなく必要なインターフェースを自身で決めで独自に開発することができるようになるため、開発効率のいっそうの向上を図ることが可能となる効果が得られる。
【０１１４】
請求項３に係る発明によれば、各アプリケーションソフトウェアが個々に自身に都合のよいインターフェース仕様を決定後に各アプリケーションソフトウェアを開発できるため、複数または必要に応じて搭載アプリケーションソフトウェアのすべてを単独で開発でき、システムが大きくなればなるほど開発効率の向上を図ることが可能となる効果が得られる。
【０１１５】
請求項４に係る発明によれば、前記仮想サービス部がキャッシュメモリを備え、前記サービス部から得たデータを保持して、保持しているデータの引用要求があった場合にはキャッシュメモリに保持しているデータを使用するようにしたため、前記サービス部へのアクセスを低減できると共に、アプリケーションソフトウェアからの要求に迅速に応答することが可能となる効果が得られる。
【０１１６】
請求項５に係る発明によれば、請求項４に係る発明と同様の効果に加えて、各アプリケーションソフトウェアが個々に自身に都合のよいインターフェース仕様を決定後に各アプリケーションソフトウェアを開発できるため、複数または必要に応じて搭載アプリケーションソフトウェアのすべてを単独で開発でき、システムが大きくなればなるほど開発効率の向上を図ることが可能となる効果が得られる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法が適用される複合機のブロック構成について示す図である。
【図２】本発明の第１実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図３】本発明の第２実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図４】本発明の第３実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図５】本発明の第４実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図６】アプリケーションとサービス部との仮想サービス部を介したインターフェース形態について具体的に示す図である。
【図７】アプリケーションとサービス部との仮想サービス部を介したインターフェース形態について具体的に示す、図６とは別の図である。
【図８】キャッシュメモリを備えた仮想サービス部におけるサービス処理手順について示すフローチャートである。
【図９】登録対応処理の具体的な処理手順について示すフローチャートである。
【図１０】引用対応処理の具体的な処理手順について示すフローチャートである。
【図１１】検索対応処理の具体的な処理手順について示すフローチャートである。
【図１２】従来の、アプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【符号の説明】
１ 複合機
２ システム制御部
３ ＲＯＭ
４ ＲＡＭ
５ 操作表示部
６ スキャナ
７ プロッタ
８ プロッタ制御部
９ パラメータメモリ
１０ ページメモリ
１１ 符号化復号化部
１２ 通信制御部
１３ モデム
１４ 網制御部
１５ ＬＡＮ通信制御部
１６ システムバス
２０ 回線
３０ ＬＡＮ
４０ ＰＣ
５０ アプリケーション群
５０ａ、５０ｂ、…、５０ｎ アプリケーションソフトウェア
６０ サービス部群
６０ａ、６０ｂ、６０ｃ、…、６０ｍ サービス部
６０ａａ、６０ｂａ、６０ｃａ、…、６０ｍａ インターフェース
７０ システムデータ群
７０ａ、７０ｂ、７０ｃ データ群
８０ 仮想サービス部
８０ａ インターフェース（サービス部都合）
８１ 仮想サービス部
８１ａ インターフェース（アプリケーション都合）
８１ｂ キャッシュメモリ
８２、８３ 仮想サービス部
８２ａ、８３ａ インターフェース（アプリケーション都合）
【発明の属する技術分野】
本発明は、本発明はファクシミリ装置、プリンタ装置、スキャナ装置、複写装置や、それら各装置の機能を複合的に備えたいわゆる複合機等に好適な、アプリケーションソフトウェアとサービス部とのインターフェース方法に関する。
【０００２】
【従来の技術】
複合機に適用されるアプリケーションソフトウェアを例にとると、ファクシミリ通信機能、プリンタ機能、スキャナ機能、複写機能、ＬＡＮ等を介したネットワーク通信等の、システムの多くの機能を実現するする必要があるため、それらの機能を実現するための各種アプリケーションソフトウェア（以後アプリケーションと略称）が必要となる。
【０００３】
アプリケーションの開発者側から見れば、特定の機種の複合機について複数のアプリケーション（アプリケーション群）を開発して装置に組み込む必要があるということになる。
【０００４】
最近では、構造化手法やオブジェクト手法の採用により機種が異なっても変更する必要のない固定部をアプリケーション群ができるだけ多く含むように配慮して開発することにより開発者の小人数化や開発納期短縮が求められている。
【０００５】
そのため、アプリケーション群の開発においては、アプリケーション群を構成する各アプリケーションが、他のアプリケーションとは関連を持たないように配慮して開発を行い、各アプリケーションの互いの独立性を高め、一部のアプリケーションの変更の影響が他のアプリケーションに及ばないよう（変更する必要が生じないよう）にして、特定機種における機能変更や、複数機種の複合機への共通のアプリケーション群の適用に柔軟に対応できるようにするのが一般的である。
【０００６】
また、アプリケーション群を構成する各アプリケーションは、その動作に関連して各種データ群により構成されるシステムデータ群を参照する必要がある。
【０００７】
そのため、例えば、ファクシミリ通信の履歴が登録された通信管理テーブルのデータを引用したり、新たなデータを登録したり、検索したりする場合、アプリケーションが通信管理テーブルを直接参照しなければならないとすると、通信管理テーブルの具体的な格納場所やデータ構造をアプリケーション（の開発者）が知っている必要がある。
【０００８】
アプリケーション群を構成する各アプリケーションは、機種が異なっても流用されるものもあるが、一般的には新たな機種が開発される際に新たに作成する必要がある。具体的には、例えば、ファクス機能を実現するためのアプリケーションは、各機種のファクス機能のそれぞれについて作成する必要がある。
【０００９】
もし仮に、各アプリケーションが、システムデータを直接参照しなればならないとすると、そのようにして新たに開発される各アプリケーション（の開発者）は、システムデータ群の全体構成や、自身が利用するデータ群について熟知しなければならない。しかし、それではあまりにも開発効率がよくない。
【００１０】
このため、近年、アプリケーション群を構成する各アプリケーションが、システムデータ群を構成する各種データ群を、引用、登録、検索などのために直接参照するのではなく、それら各種データ群の引用、登録、検索などの機能をサービス部群としてアプリケーション群から独立させ、その独立させたサービス部群を構成する各サービス部を、アプリケーション群を構成する各アプリケーションが必要に応じて利用するようにすることで、アプリケーション（の開発者）がシステムデータ群の具体的な構成についての知識なしに、システムデータ群を参照できるようにしている。
【００１１】
アプリケーションがサービス部を利用できるようにするために、各サービス部には、データ入出力（読み出し・書込み・検索など）のためのＩ／Ｆ（インターフェイス）が予め定義される。
【００１２】
そして、アプリケーションの開発者は、参照したいデータ群についての入出力のサービスを提供するサービス部（複数の場合もある）について予め定義されているインターフェースの仕様を理解して設計・開発を行うことになる。
【００１３】
一般にサービス部群は、例えば複合機の一連の製品群を構成する複数の機種に共通で利用される前提で考慮され、設計・開発される。そして、ある機種で仕様追加が発生したとしても、追加部分に修正を加えれば利用する複数機種への対応は容易にできる。
【００１４】
一方、アプリケーション開発は機種単位に行われるため、アプリケーションの開発者は複数のサービス部のインターフェース仕様を理解しなければならないだけでなく、自分が設計しているアプリケーションにとって、どれとどれのサービス部のインターフェースのうちのどの部分を利用すべきかなどについても把握する必要がある。そのため、複数の機種の開発を並行して行う場合などに開発効率が低下が顕著であるという問題があった。
【００１５】
図１２に、上記従来のアプリケーション群、サービス部群、及び、システムデータ群のインターフェース形態について示す。
【００１６】
同図において、システムデータ群７０は、装置動作に関連してメモリに記憶しておく必要がある、データ群７０ａ、７０ｂ、７０ｃなどの各種データの集まりである。そのシステムデータ群７０を構成する各データ群は、最終的には、アプリケーション群５０を構成する各アプリケーションにより利用されるものであるが、サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部を介して、アプリケーション群５０を構成する、アプリケーション５０ａ、５０ｂ、…、５０ｎなどにより、引用、登録、検索などのために間接的に参照される。
【００１７】
サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部には、それぞれ、インターフェース６０ａａ、６０ｂａ、６０ｃａ、…、６０ｍａなどの、各サービス部単位に、アプリケーション群５０を構成するアプリケーションに対して提供されるインターフェースが定義されている。各サービス部のインターフェースは単一のインターフェースではなく、様々な形態の引用、登録、検索などに対応するための複数種別のインターフェースの複合したものとして構成される場合もあり、アプリケーション群５０を構成するアプリケーション（の開発者）は、その詳細な仕様を予め熟知している必要がある。
【００１８】
なお、システムデータ群７０が各データ群に分けられているのは、サービス部群６０を構成する各サービス部単位に使うデータが決まっていることを反映している。また、システムデータ群７０を構成する各データ群の中には、複数のサービス部から参照されるデータもあり、また、データの参照形態も、引用、登録、検索などのための、読み出し、書き込み、読み書きの３形態あり、各データ群の性質に応じて参照形態も異なる。図１２には、その様が矢印で示されている。
【００１９】
複合機を例にとると、多数の宛先情報を管理する電話帳のデータ群（を参照するためのサービス部）は、ネットワークアプリケーションでもファクスアプリケーションでも利用される。ただ、Ｇ３ファクシミリ通信時に相手先装置に対して被呼端末識別信号ＣＳＩとして通知する自機のファクス番号のように、ファクスアプリケーションのみが参照するデータもある。
【００２０】
図１２において、アプリケーション５０ｂ（の開発者）は、データ群７０ａ、７０ｂ及び７０ｃを参照するために、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｂのＩ／Ｆ６０ｃａの仕様を理解する必要がある。
【００２１】
しかし、データ群７０ａ、７０ｂ及び７０ｃの参照の態様に応じて、Ｉ／Ｆ６０ａａ、６０ｂａ、及び、６０ｃａの仕様書の中には、利用すべきものとそうでないものとが混在していて、その取捨選択の巧拙は、開発者のスキルに依存する部分が大きく開発効率に大きく影響する。
【００２２】
特許文献１には、アプリケーションソフトウェアとサービスソフトウェアとが、それぞれ、ユーザページの状態を参照しながら、動作また処理するようにすることで、アプリケーションソフトウェアとサービスソフトウェアの相互依存性をなくし、それにより、ソフトウェアの再利用率の向上を図った「ソフトウェア間のインターフェース方法」が開示されいる。
【００２３】
【特許文献１】
特開２００１−０１６３９５号公報
【００２４】
【発明が解決しようとする課題】
しかし、上記特許文献１記載の従来技術は、ネットワークを介した情報共有、つまり、グループウェアを意識した技術であり、アプリケーションソフトウェアがサービス部利用を利用してデータを参照するインターフェース形態に単純に適用することはできない。
【００２５】
本発明は係る事情に鑑みてなされたものであり、サービス部を利用してデータ参照を行うアプリケーションソフトウェアの開発効率を上げることができる、アプリケーションソフトウェアとサービス部とのインターフェース方法を提供することを目的とする。
【００２６】
【課題を解決するための手段】
請求項１に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、システムの特定の機能に対応するアプリケーションソフトウェアが、所定仕様のインターフェースをそれぞれ備えた１または複数のサービス部とデータの引用、検索、登録等のやりとりを行うアプリケーションソフトウェアとサービス部とのインターフェース方法において、特定のアプリケーションソフトウェアに関連する各サービス部のインターフェースのうちの、当該特定のアプリケーションソフトウェアにおいて必要とされるデータに関連する部分のインターフェースのみを抜粋して、その抜粋したインターフェースの仕様を明確化した仮想サービス部を、当該特定のアプリケーションソフトウェアと、それと関連する各サービス部との間に介在させ、当該仮想サービス部がインターフェースを介して当該特定のアプリケーションソフトウェアからの引用、検索、登録等の要求をうけ、その要求に応じて当該特定のアプリケーションソフトウェアに関連する各サービス部との間でそれら各サービス部が備えるインターフェースを介して実際の引用、検索、登録等のやりとりを行うことで、当該特定のアプリケーションソフトウェアと、それに関連する各サービス部とが、前記仮想サービス部を介して間接的に引用、検索、登録等のやりとりを行うことを特徴とする。
【００２７】
請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項１に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記仮想サービス部が備える、前記特定のアプリケーションソフトウェアに対するインターフェースを、前記特定のアプリケーションソフトウェアが自身に都合よく決めた仕様とすると共に、前記仮想サービス部は、前記特定のアプリケーションソフトウェアからの要求を解析して、前記特定のアプリケーションソフトウェアに関連する各サービス部のインターフェースに置換することを特徴とする。
【００２８】
請求項３に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記仮想サービス部を、複数のアプリケーションソフトウェアのうちの、単独で開発したいアプリケーションソフトウェアのそれぞれについて、各アプリケーションソフトウェアと、それら各アプリケーションソフトウェアと関連する各サービス部との間に介在させることを特徴とする。
【００２９】
請求項４に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記仮想サービス部はキャッシュメモリを備え、アプリケーションソフトウェアからのインターフェースを介したデータ引用要求の処理時に、当該データ引用要求に該当するデータが前記キャッシュメモリに格納されていない場合には、当該データ引用要求に相当するサービス部のインターフェースから得られるデータを前記キャッシュメモリに格納すると共に格納履歴を保持した上で、当該得られたデータを要求元のアプリケーションソフトウェア所望の形式に置換して通知する一方、当該データ引用要求に該当するデータが既に前記キャッシュメモリに格納されている場合には、当該キャッシュメモリに格納されているデータを、要求元のアプリケーションソフトウェア所望の形式に置換して通知することを特徴とする。
【００３０】
請求項５に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法は、請求項４に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法において、前記キャッシュメモリを備えた仮想サービス部を、複数のアプリケーションソフトウェアのうちの、単独で開発したいアプリケーションソフトウェアのそれぞれについて、各アプリケーションソフトウェアと、それら各アプリケーションソフトウェアと関連する各サービス部との間に介在させることを特徴とする。
【００３１】
【発明の実施の形態】
以下、添付図面を参照しながら、本発明の実施の形態を詳細に説明する。
【００３２】
先ず、図１に、本発明の実施の形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法が適用される複合機１のブロック構成について示す。
【００３３】
同図において、複合機１は、システム制御部２、ＲＯＭ３、ＲＡＭ４、操作表示部５、スキャナ６、プロッタ７、プロッタ制御部８、パラメータメモリ９、ページメモリ１０、符号化復号化部１１、通信制御部１２、モデム１３、網制御部１４、ＬＡＮ通信制御部１５、及び、システムバス１６により構成されている。
【００３４】
システム制御部２は、ＲＯＭ３に書き込まれた制御プログラムに従って、ＲＡＭ４を作業領域として使用しながら、装置各部を制御するマイクロコンピュータである。
【００３５】
ＲＯＭ３は、前述したように、システム制御部２が上記装置各部を制御するための制御プログラムや、各種システムデータのうちの固定的なデータが記憶されているリードオンリメモリである。ＲＡＭ４は、前述したようにシステム制御部２の作業領域として使用されるランダムアクセスメモリであり、システムデータのうちの内容の変更や追加のある一時的なデータも記憶する。
【００３６】
操作表示部５は宛先電話番号を指定するためのテンキー、送信スタートキー、ワンタッチダイヤルキー等の各種キーが配設される一方、液晶表示装置等の表示器を備え、ユーザに知らせるべき装置の動作状態や、各種メッセージを表示するものである。
【００３７】
スキャナ６は、３．８５本／ｍｍ、７．７本／ｍｍ、１５．４本／ｍｍ、２００ｄｐｉ、４００ｄｐｉ等の所定の読み取り線密度で原稿画像を読み取って、画像データを得るためのものである。プロッタ７は、画像データを記録紙上に印刷形成するためのものである。プロッタ制御部８は、プロッタ７を制御して画像データの記録紙への印刷を制御するものである。なお、プロッタ７により印刷される画像データとしては、スキャナ６により読み取られた画像データ（コピー機能）、ファクシミリ受信された画像データ（ファクシミリ機能）、ＬＡＮ３０を介してＰＣ４０等から転送されてきた画像データ（プリンタ機能）や、各種レポートの画像データなどがある。
【００３８】
パラメータメモリ９は、システムデータのうちの、変更、追加のあるデータであって、電源遮断時にも保持する必要のあるデータ、具体的には、送信宛先が多数登録された電話帳データ、通信管理テーブルのデータ等を記憶するためのメモリであり、具体的には、バッテリバックアップされたＳＲＡＭや、ＥＥＰＲＯＭ（電気的に書き換え可能な読み出し専用メモリ）等により構成されるものである。
【００３９】
ページメモリ１０は、プロッタ７により記録紙に印刷される画像データをビットマップ状態で展開するためのメモリである。
【００４０】
符号化復号化部１１は、送信画像データを、Ｇ３ファクシミリに適合する、ＭＨ符号化方式、ＭＲ符号化方式、ＭＭＲ符号化方式等の所定の符号化方式で符号化圧縮する一方、受信画情報をＭＨ符号化方式、ＭＲ符号化方式、ＭＭＲ符号化方式等に対応する所定の復号化方式で復号伸長するものである。
【００４１】
通信制御部１２は、モデム１３及び網制御部１４を制御して回線２０を介した相手装置との間のＧ３ファクシミリ通信を制御するものである。モデム１３は、ファクシミリモデム機能を備え、網制御部１４を介して、回線２０に送信するデータを変調する一方、網制御部１４を介して回線２０から受信した信号を復調するものであり、伝送手順信号をやりとりするための低速モデム機能（Ｖ．２１モデム）、および、おもに画像データをやりとりするための高速モデム機能である、Ｖ．１７、Ｖ．３３、Ｖ．３４、Ｖ．２９、Ｖ．２７ｔｅｒの各モデム機能を備えている。モデム１３は、ダイヤル番号に対応したＤＴＭＦ信号の送出も行う。
【００４２】
網制御部１４は、回線２０に接続されて、回線の直流ループの閉結・解放や、回線の極性反転の検出、回線解放の検出、発信音の検出、ビジートーン等のトーン信号の検出、呼出信号の検出等の回線との接続制御や、ダイヤルパルスの生成を行うものであり、また、自動発着信機能も備えている。また、回線２０からの受信信号Ｒは、網制御部１４を介してモデム１３に入力され、モデム１３からの送信信号Ｔは、網制御部１４を介して回線２０に出力される。
【００４３】
ＬＡＮ通信制御部１５は、ＬＡＮ４０に接続され、ＬＡＮプロトコル上でのＴＣＰ／ＩＰプロトコル制御等を行い、ＬＡＮ４０に接続されたＰＣ（パーソナルコンピュータ）６０等の他装置からの文書ファイルの転送を受けるためのものである。システムバス１６は、アドレスバス、データバス、制御バス、割り込み制御信号ライン等により構成され、上記各部がデータをやり取りするための信号ラインである。
【００４４】
以上のように構成される複合機１において、システム制御部２は、複合機としての機能を実現するための、ファクス機能、複写機能、プリンタ機能、ネットワーク通信機能等の各種機能にそれぞれ対応したアプリケーションソフトウェアのプログラムや、それらのアプリケーションソフトウェアと、ＲＯＭ３、ＲＡＭ４，パラメータメモリ９等に記憶される各種システムデータ群との間に介在する、サービス部に相当するソフトウェアのプログラムを実行する。
【００４５】
以下、複合機１に適用される、アプリケーションソフトウェアとサービス部とのインターフェース方法の第１ないし第４実施形態について、順に説明する。
【００４６】
先ず、第１実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について説明する。
【００４７】
図２は、第１実施形態に係るインターフェース方法について示すブロック図である。図２に示す構成は、従来技術の説明において参照した、図１２に示す構成と一部を除いて同一である。同一でない点は、特定のアプリケーションソフトウェアとしてのアプリケーション５０ｂが、直接、サービス部６０ａ、６０ｂ及び６０ｃを利用するのではなく、仮想サービス部８０を介してそれらのサービス部を利用するようにしている点である。
【００４８】
同２において、システムデータ群７０は、装置動作関連して、ＲＯＭ３、ＲＡＭ４、パラメータメモリ９等のメモリに記憶しておく必要がある、データ群７０ａ、７０ｂ、７０ｃなどの各種データの集まりである。そのシステムデータ群７０を構成する各データ群は、最終的には、アプリケーション群５０を構成する各アプリケーションにより利用されるものであるが、各データ群への直接のアクセスは、サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部が行う。
【００４９】
サービス部群６０を構成する、サービス部６０ａ、６０ｂ、６０ｃ、…、６０ｍなどの各サービス部には、それぞれ、インターフェース６０ａａ、６０ｂａ、６０ｃａ、…、６０ｍａなどの、各サービス部単位に、利用する側（仮想サービス部８０、アプリケーション群５０を構成するアプリケーション）対して提供されるインターフェースが定義されている。各サービス部のインターフェースは単一のインターフェースではなく、様々な形態の引用、登録、検索などに対応するための複数種別のインターフェースの複合したものとして構成される場合もある。
【００５０】
なお、システムデータ群７０が各データ群に分けられているのは、サービス部群６０を構成する各サービス部単位に使うデータが決まっていることを反映している。また、システムデータ群７０を構成する各データ群の中には、複数のサービス部から参照されるデータもあり、また、データの参照形態も、引用、登録、検索などのための、「読み出し」、「書き込み」、「読み書き」の３形態あり、各データ群の性質に応じて参照形態も異なる。
【００５１】
サービス部６０ａは、データ群７０ａを「読み書き」する。サービス部６０ｂは、データ群７０ｂを「読み書き」すると共にデータ群７０ｃを「書き込み」する。サービス部６０ｃは、データ群７０ｃを「読み書き」する。サービス部６０ｍａは、データ群８０ｃを「読み出し」する。
【００５２】
アプリケーション群５０を構成する各アプリケーションのうち、アプリケーション５０ａは、インターフェース６０ａａを介してサービス部６０ａを利用する。アプリケーション５０ｎは、インターフェース６０ｍａを介してサービス部６０ｍを利用する。
【００５３】
そして、アプリケーション５０ｂは、サービス部６０ａ、６０ｂ、６０ｃの３つのサービス部を利用するが、その利用は、仮想サービス部８０を介して間接的に行う。
【００５４】
アプリケーション５０ｂ（の開発者）は、データ群７０ａ、７０ｂ及び７０ｃを参照するために、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｂのＩ／Ｆ６０ｃａの各仕様の詳細を理解する必要はなく、仮想サービス部８０のインターフェース８０ａの仕様のみを理解すれば足りる。
【００５５】
従来、データ群７０ａ、７０ｂ及び７０ｃの参照の態様に応じて、Ｉ／Ｆ６０ａａ、６０ｂａ、及び、６０ｃａの仕様書の中には、利用すべきものとそうでないものとが混在していて、その取捨選択の巧拙は、開発者のスキルに依存する部分が大きかったが、仮想サービス部８０を介することで、アプリケーション５０ｂにより実現される機能（ファクス機能など）に関して必要にして十分なインターフェース仕様を理解するのみで、アプリケーション５０ｂを開発することが可能となる。
【００５６】
なお、仮想サービス部８０のインターフェース８０ａは、アプリケーション５０ｂ側の都合ではなく、仮想サービス部８０の開発に都合がよいように（サービス部都合）、開発される。
【００５７】
図６に、仮想サービス部８０が行う、アプリケーション５０ｂと、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｃのＩ／Ｆ６０ｃａとのインターフェース形態について示す。
【００５８】
同図において、サービス部６０ａの提供するＩ／Ｆ６０ａａは、Ａ１ないしＡｎの各種インターフェースの集合として構成されている。サービス部６０ｂの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。サービス部６０ｃの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。
【００５９】
仮想サービス部８０において、Ａ１ないしＡｎ、Ｂ１ないしＢｎ、及び、Ｃ１ないしＣｎのすべてのインターフェースを管理することも考えられるが、仮想サービス部８０は、アプリケーション５０ｂのためのものであるため、アプリケーション５０ｂが利用するインターフェースのみを管理できればよい。
【００６０】
アプリケーション５０ｂが利用したいインターフェースは、インターフェース６０ａａのインターフェース（Ａ１）及び（Ａ２）、インターフェース６０ｂａのインターフェース（Ｂ１）、（Ｂ２）及び（Ｂ３）、並びに、インターフェース６０ｃａのインターフェース（Ｃ１）のみであるため、それらの対応する必要のあるインターフェースのみを管理する。
【００６１】
そして、それらの対応する必要のあるインターフェースのみを、インターフェース８０ａを構成するインターフェースＳ１ないしＳ６と、１対１に対応させてアプリケーション５０ｂに公開する。
【００６２】
それにより、例えば、ある新機種の特定の機能、例えばファクス機能に対応するアプリケーション５０ｂの開発担当者は、必要にして十分な、無駄のないインターフェース仕様のみを理解すれば開発・設計を行えるようになる。また、仮想サービス部８０はサービス部６０ａなどと同様に、複数の機種開発が同時に発生してもあまり影響を受けず機種が異なっても流用できる場合が多いため、開発負担は小さい。また、インターフェース８０ａを構成する各インターフェース（Ｓ１ないしＳ６）は、それぞれ、Ｉ／Ｆ６０ａａ、６０ｂａ、６０ｃａ、の一部として既存のものであるため、それを流用すればよく、新規に開発する必要のある部分がその分少なくて済む。
【００６３】
以上、第１実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について説明したが、サービス部のインターフェースの特徴について考えてみると、そのインターフェースは、参照するシステムデータにより決定されることが多く、アプリケーション側に都合のよい形式とは異なる場合が多い。
【００６４】
具体的には、ある特定のシステムデータを１６進数の６４（１０進数の１００）と管理している場合、サービス部は読み出したまま利用するほうが、変換の手間が省けるため楽であり、また、その特定のシステムデータをアプリケーションが内部的に利用する場合は問題無いことが多い。
【００６５】
しかし、アプリケーションがその特定のシステムデータを表示したり印刷する場合には、１バイトの数字としての６４（１６進数）を「１００」の文字列に相当する文字コード列に変換する必要があり、アプリケーション（の開発者）側でその変換処理まで考慮しなければならないのは大きな負担となる。
【００６６】
その点を考慮したのが、第２、第３の実施形態に係るインターフェース方法である。
【００６７】
先ず、第２実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について図３を参照して説明する。なお、第２実施形態に係る図３に示すインターフェース方法と、図２に示した第１実施形態に係るインターフェース方法とで異なる点は、図２における仮想サービス部８０に代えて、図３においては、仮想サービス部８１ａを備えている点である。
【００６８】
図３において、アプリケーション開発の効率化を考える場合、アプリケーションに都合のよい（アプリケーション側の負担を軽減できる）インターフェースであるべき点に鑑みて、特定のアプリケーションソフトウェアとしてのアプリケーション５０ｂ用の仮想サービス部８１を設けると共に、そのインターフェース８１ａを、アプリケーション５０ｂ（の開発者）が自身に都合がよいように決定した仕様としている。
【００６９】
図７に、仮想サービス部８１が行う、アプリケーション５０ｂと、サービス部６０ａのＩ／Ｆ（インターフェース）６０ａａ、サービス部６０ｂのＩ／Ｆ６０ｂａ、及び、サービス部６０ｃのＩ／Ｆ６０ｃａとのインターフェース形態について示す。
【００７０】
同図において、サービス部６０ａの提供するＩ／Ｆ６０ａａは、Ａ１ないしＡｎの各種インターフェースの集合として構成されている。サービス部６０ｂの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。サービス部６０ｃの提供するＩ／Ｆ６０ｂａは、Ｂ１ないしＢｎの各種インターフェースの集合として構成されている。
【００７１】
仮想サービス部８１において、Ａ１ないしＡｎ、Ｂ１ないしＢｎ、及び、Ｃ１ないしＣｎのすべてのインターフェースを管理することも考えられるが、仮想サービス部８１は、アプリケーション５０ｂのためのものであるため、アプリケーション５０ｂが利用するインターフェースのみを管理できればよい。
【００７２】
アプリケーション５０ｂが利用したいインターフェースは、インターフェース６０ａａのインターフェース（Ａ１）及び（Ａ２）、インターフェース６０ｂａのインターフェース（Ｂ１）、（Ｂ２）及び（Ｂ３）、並びに、インターフェース６０ｃａのインターフェース（Ｃ１）のみであるため、それらの対応する必要のあるインターフェースのみを管理する。
【００７３】
そして、それらの対応する必要のあるインターフェースのみを、インターフェース８１ａを介してアプリケーション５０ｂに公開する。
【００７４】
その場合、インターフェース８１ａは、アプリケーション５０ｂに都合のよい仕様とされる。また、仮想サービス部８１には、Ａ１、Ａ２、Ｂ１、Ｂ２、Ｂ３及びＣ１の各インターフェースと、アプリケーション都合のインターフェース８１ａとを相互に変換する機能を持たせる。
【００７５】
このように、仮想サービス部８１に、各サービス部のインターフェースと、アプリケーション５０ｂから利用される場合のインターフェースとの変換機能を持たせることにより、各サービス部（の開発者）もアプリケーション５０ｂ（の開発者）も自身に都合のよいインターフェース仕様を定義することができる（特にアプリケーション５０ｂにおいて）。
【００７６】
それにより、無理・無駄がなくなり開発効果があがる。また、各サービス部とアプリケーション５０ｂとの直接の関連がなくなることになるため、独立した開発がしやすくなる。
【００７７】
また仮想サービス部８１自体はインターフェースの相互変換以外の機能を持たせないことで簡素化できる。また、仮想サービス部８１（の開発者）は、アプリケーション５０ｂと、各サービス部との両方の仕様を把握しているため、不具合解析なども容易となる。また、仮想サービス部８１は、機能追加など変更要因もあるが流用度も高くモジュール化しやすい利点がある。
【００７８】
次に、第３実施形態に係るインターフェース方法について、図４を参照して説明する。
【００７９】
同図において、図３に示した第２実施形態に係るインターフェース方法と異なる点は、特定のアプリケーションソフトウェアとしてのアプリケーション５０ｂについてのみ設けていた仮想サービス部８１を、アプリケーション５１ａ（仮想サービス部８２）やアプリケーション５０ｎ（仮想サービス部８３）などのアプリケーション群５０を構成するアプリケーションの全てについて設けた点である。
【００８０】
それにより、システム開発のいっそうの効率化が可能となる。なお、アプリケーション群５０を構成する全アプリケーションについてではなく、アプリケーション群５０を構成する各アプリケーションのうちの、機種毎に変更の発生する可能性の高いアプリケーションについてのみ、仮想サービス部をサービス部との間に介在させてもよく、また、データ交換の必要なアプリケーションについてのみ、仮想サービス部をサービス部との間に介在させてもよく、どのアプリケーションについて仮想サービス部を設けるかは、それを設けることによりもたらされる開発の効率化の程度を評価することで決めることができる。
【００８１】
次に、第４実施形態に係るインターフェース方法について、図５を参照して説明する。図５に示す第４実施形態に係るインターフェース方法は、図３に示した第２実施形態に係るインターフェース方法の変形例であり、仮想サービスブ８１が、キャッシュメモリ８１ｂを備えている点が異なる。
【００８２】
サービス部群６０を構成する各サービス部と、アプリケーション群５０を構成するのアプリケーションとのインターフェースは、１対１でないことが多い。具体的には、図７に示したように、アプリケーション５０ｂがサービス部６０ａを利用する場合インターフェース６０ａａを構成するＡ１ないしＡｎのインターフェースのうちのインターフェースＡ１及びＡ２のみを利用する。
【００８３】
また、サービス部が提供するインターフェースは、通常複数のインターフェースにより構成されるが、１のインターフェースで扱われるデータが１つとはならないことが多い。
【００８４】
具体的には、例えば、アプリケーション５０ｂからみて、従来は、ｄａｔａ１、ｄａｔａ２、ｄａｔａ３の各データが必要な場合はインターフェースＡ１を利用していて、ＤＡＴ１、ＤＡＴ２、ＤＡＴ３、ＤＡＴ４の各データが必要な場合にはインターフェースＡ２を利用しているような場合である。
【００８５】
そのような場合、ｄａｔａ１、２、３やＤＡＴ１、２、３、４は必ずしもアプリケーション５０ｂからみて一度に必要とはならない。それにもかかわらず、従来は、ｄａｔａ１、ｄａｔａ２、ｄａｔａ３を異なるタイミングでアプリケーション５０ｂが必要とする場合は、インターフェースＡ１をその都度実行する必要があった。一方、インターフェースＡ１の中でｄａｔａ１、ｄａｔａ２、ｄａｔａ３の各データに対応するシステムデータＳｄａｔａ１、Ｓｄａｔａ２、及び、Ｓｄａｔａ３は一括して一度に取得する場合も多い。その結果、システム負荷が増大していた。
【００８６】
そこで、この第４実施形態に係るインターフェース方法では、図５に示すように、仮想サービス部８１にキャッシュメモリ８１ｂを持たせている。キャッシュメモリ８１ｂは、具体的には、それ用に確保されたＲＡＭ４の一部記憶領域である。
【００８７】
そして、ｄａｔａ１、ｄａｔａ２、ｄａｔａ３のいずれか１つが最初に引用された場合に、仮想データ部８１ｂは、サービス部６０ａのインターフェース６０ａａの一部であるインターフェースＡ１利用して一括して取得される、Ｓｄａｔａ１、Ｓｄａｔａ２、及び、Ｓｄａｔａ３をキャッシュメモリ８１ｂに格納する。
【００８８】
仮想サービス部８１ｂにおいて、もし、インターフェース８１ａに対するアプリケーション５０ｂからの要求が、ｄａｔａ１の要求であった場合には、Ｓｄａｔａ１をインターフェース８１ａの仕様にあわせたｄａｔａ１に置換して渡すようにすればよい。
【００８９】
次にｄａｔａ２やｄａｔａ３、更には再度ｄａｔａ１のアプリケーション５０ｂからの引用が、インターフェース８１ａを介してあった場合もキャッシュメモリ８１ｂ内のＳｄａｔａ１、２、または、３を必要に応じて置換してアプリケーション５０ｂに渡せばよい。
【００９０】
それにより、サービス部の負荷が低減できる（特にシステムデータの引用を行う部分）。また、アプリケーション５０ｂとしても、必要なときに必要なデータのみ取得できるため、得たデータの取捨選択が不要となり処理の効率化を図ることができる。
【００９１】
仮想サービス部８１にけるキャッシュメモリ８１ｂを用いた、アプリケーション５０ｂからの要求に応じて行う、サービス処理手順について、図８ないし図１１を参照して説明する。
【００９２】
先ず、図８において、アプリケーション５０ｂからの要求をインターフェース８１ａから受けると、その要求の種別が、「引用」、「登録」、または、「検索」のいずれであるかを判定する（処理Ｓ１０１）。
【００９３】
判断Ｓ１０２においては、処理Ｓ１０１における判定結果が、「引用」の場合には、「引用対応処理」を行い（処理Ｓ１０４）、「登録」の場合には、「登録対応処理」を行い（処理Ｓ１０３）、「検索」の場合には、「検索対応処理」を行う（処理Ｓ１０５）。
【００９４】
図９に、処理Ｓ１０３の「登録対応処理」の具体的な処理手順に付いて示す。
【００９５】
同図において、先ず、該当するサービスを判断し（処理Ｓ２０１）、要求と共にアプリケーション５０ｂから渡された登録要求に係るデータを、システムデータとして登録される形式に置換する（処理Ｓ２０２）。
【００９６】
そして、その該当するサービスに係るデータがキャッシュメモリ８１ｂに格納済みであるか否かを示すキャッシュ履歴を確認して、キャッシュ履歴がある場合には（判断Ｓ２０３のＹｅｓ）、システムデータとしてこれから登録されようとするデータの内容とキャッシュメモリ８１ｂとの整合性がとれなくなるのを防止するために、キャッシュ履歴をリセットした上で（処理Ｓ２０３）、処理Ｓ２０５に移行する。キャッシュ履歴がない場合には（判断Ｓ２０３のＮｏ）、直接、処理Ｓ２０５に移行する。
【００９７】
処理Ｓ２０５では、処理Ｓ２０１で特定した、該当する登録のサービスを実行する（処理Ｓ２０５）。それにより、アプリケーション５０ｂからの登録要求に係るデータがシステムデータとして登録される。処理Ｓ２０５の後は、その処理結果をアプリケーション５０ｂに通知して（処理Ｓ２０６）、「登録対応処理」を完了する。
【００９８】
なお、場合によっては登録時にキャッシュ履歴がある場合（判断２０３のＹｅｓ）に、キャッシュメモリ８１ｂの内容を登録要求されたデータに置換するようにして、システムデータとして登録されるデータとキャッシュメモリ８１１ｂに保持されるデータとの整合性を確保するようにすれば、キャッシュ履歴をリセットする必要はない。そのようにすることで、次回の引用時におけるサービス部へのアクセスがなくなり、その分サービス部の負荷を軽減できる。
【００９９】
次に、図８の処理Ｓ１０４の「引用対応処理」の具体的な処理手順について図１０を参照して説明する。
【０１００】
図１０において、先ず、該当するサービスを判断した上で（処理Ｓ３０１）、その該当するサービスに係るデータがキャッシュメモリ８１ｂに格納済みであるか否かを示すキャッシュ履歴を確認して、キャッシュ履歴がない場合には（判断Ｓ３０２のＮｏ）、処理Ｓ３０１で特定した、該当する引用のサービスを実行する（処理Ｓ３０３）。それにより、アプリケーション５０ｂからの引用要求に係るシステムデータが読み出される。
【０１０１】
その読み出された引用要求に係るシステムデータは、キャッシュ履歴にセットされると共に（処理Ｓ３０４）、キャッシュメモリ８１ｂへ格納される（処理Ｓ３０５）。
【０１０２】
それにより、引用されたシステムデータや、そのデータと関連する一連のデータがキャッシュメモリ８１ｂに残ることになるため、次回の引用要求時には、サービス部に負荷かけることなく、その引用要求に迅速に応じることができる。
【０１０３】
処理Ｓ３０５の後、または、判断３０２においてキャッシュ履歴が既にある場合には（判断Ｓ３０２のＹｅｓ）、キャッシュメモリ８１ｂに格納されている、引用要求されたデータをアプリケーション５０ｂに渡すための形式に置換し（処理Ｓ３０６）、アプリケーション５０ｂにそのデータを通知して（処理Ｓ３０７）、「引用対応処理」を完了する。
【０１０４】
なお、処理Ｓ３０６及び処理Ｓ３０７が判断３０２のＹｅｓに引き続いて行われる場合、前回の引用処理時にキャッシュメモリ８１ｂに格納されたシステムデータがそのまま使用できるため、サービス部に負荷をかけることなく、引用要求に迅速に応じることができる。
【０１０５】
次に、図８の処理Ｓ１０５の「検索対応処理」の具体的な処理手順について図１１を参照して説明する。
【０１０６】
図１１において、先ず、該当するサービスを判断し（判断Ｓ４０１）、その該当する検索のサービスを実行し（処理Ｓ４０２）、その実行結果をアプリケーション５０ｂに通知する。
【０１０７】
処理Ｓ４０２の検索のサービスの実行の結果得られるのは、データそのものではなく、データの有無や位置の情報であるため、キャッシュメモリ８１ｂに格納していないが、キャッシュメモリ８１ｂに検索結果を格納しておき、次回に同一の検索条件がアプリケーション５０ｂから与えられた場合に、キャッシュメモリ８１ｂに格納しておいた検索結果を返すようにすることで、サービス部を負荷をかけることなく、検索の要求に応じることができる。もっとも、その場合、「登録対応処理」でシステムデータの内容に変更が生じた場合には、キャッシュメモリ８１ｂに格納された検索結果をクリアする必要が生じる場合もある。
【０１０８】
また、以上説明した第４実施形態は、図３に示した第２実施形態に係る仮想サービス部８１にキャッシュメモリ８１ｂを持たせたものであったが、図４に示した第３実施形態に係る、各アプリケーションごとに設けられた仮想サービス部８１、８２、８３等の全ての仮想サービス部のそれぞれにキャッシュメモリ８１ｂ持たせて、各仮想サービス部において、図８ないし図１１に示したサービス処理手順を行うようにしてもよく、その場合、各仮想サービス部において利用されるサービス部の処理負荷の軽減と、対応するアプリケーションからの要求に対する迅速な応答が可能となる。
【０１０９】
その場合、全ての仮想サービス部にキャッシュメモリを持たせるのではなく、利用頻度の高い仮想サービス部のみにキャッシュメモリを持たせるようにしてもよい。また、キャッシュメモリを備えた仮想サービス部を全てのアプリケーションに対応して設けるのではなく、アプリケーション群５０を構成する各アプリケーションのうちの、機種毎に変更の発生する可能性の高いアプリケーションについてのみ、キャッシュメモリを備えた仮想サービス部をサービス部との間に介在させてもよく、また、データ交換の必要なアプリケーションについてのみ、キャッシュメモリを備えた仮想サービス部をサービス部との間に介在させてもよく、どのアプリケーションについてキャッシュメモリを備えた仮想サービス部を設けるかは、それを設けることによりもたらされる開発の効率化の程度を評価することで決めることができる。
【０１１０】
なお、以上説明した実施の形態では、サービス部群６０を構成する各サービス部は、システムデータへの参照サービスを提供するソフトウェアとしたが、サービス部は、アプリケーションに対してデータ参照サービスを提供するものであれば、ハードウェアにより構成されたものであってもよいのはいうまでない。
【０１１１】
また、本発明は、複合機のシステムに限らず、複数のアプリケーションソフトウェアとがデータ参照サービスを提供するサービス部を利用するものであれば、同様に適用可能なものである。
【０１１２】
【発明の効果】
請求項１に係る発明によれば、特定のアプリケーションソフトウェアを開発する際、そのアプリケーションソフトウェアが利用する１つ以上のサービス部が提供するインターフェースの中の有為なインターフェースのみ、つまり、仮想サービス部のインターフェース仕様のみを意識してアプリケーション開発を行えるようになるため、開発効率の向上を図ることが可能となる効果が得られる。
【０１１３】
請求項２に係る発明によれば、前記特定のアプリケーションが関連する各サービス部のインターフェースの仕様を知ることなく必要なインターフェースを自身で決めで独自に開発することができるようになるため、開発効率のいっそうの向上を図ることが可能となる効果が得られる。
【０１１４】
請求項３に係る発明によれば、各アプリケーションソフトウェアが個々に自身に都合のよいインターフェース仕様を決定後に各アプリケーションソフトウェアを開発できるため、複数または必要に応じて搭載アプリケーションソフトウェアのすべてを単独で開発でき、システムが大きくなればなるほど開発効率の向上を図ることが可能となる効果が得られる。
【０１１５】
請求項４に係る発明によれば、前記仮想サービス部がキャッシュメモリを備え、前記サービス部から得たデータを保持して、保持しているデータの引用要求があった場合にはキャッシュメモリに保持しているデータを使用するようにしたため、前記サービス部へのアクセスを低減できると共に、アプリケーションソフトウェアからの要求に迅速に応答することが可能となる効果が得られる。
【０１１６】
請求項５に係る発明によれば、請求項４に係る発明と同様の効果に加えて、各アプリケーションソフトウェアが個々に自身に都合のよいインターフェース仕様を決定後に各アプリケーションソフトウェアを開発できるため、複数または必要に応じて搭載アプリケーションソフトウェアのすべてを単独で開発でき、システムが大きくなればなるほど開発効率の向上を図ることが可能となる効果が得られる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法が適用される複合機のブロック構成について示す図である。
【図２】本発明の第１実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図３】本発明の第２実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図４】本発明の第３実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図５】本発明の第４実施形態に係るアプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【図６】アプリケーションとサービス部との仮想サービス部を介したインターフェース形態について具体的に示す図である。
【図７】アプリケーションとサービス部との仮想サービス部を介したインターフェース形態について具体的に示す、図６とは別の図である。
【図８】キャッシュメモリを備えた仮想サービス部におけるサービス処理手順について示すフローチャートである。
【図９】登録対応処理の具体的な処理手順について示すフローチャートである。
【図１０】引用対応処理の具体的な処理手順について示すフローチャートである。
【図１１】検索対応処理の具体的な処理手順について示すフローチャートである。
【図１２】従来の、アプリケーションソフトウェアとサービス部とのインターフェース方法について示す図である。
【符号の説明】
１ 複合機
２ システム制御部
３ ＲＯＭ
４ ＲＡＭ
５ 操作表示部
６ スキャナ
７ プロッタ
８ プロッタ制御部
９ パラメータメモリ
１０ ページメモリ
１１ 符号化復号化部
１２ 通信制御部
１３ モデム
１４ 網制御部
１５ ＬＡＮ通信制御部
１６ システムバス
２０ 回線
３０ ＬＡＮ
４０ ＰＣ
５０ アプリケーション群
５０ａ、５０ｂ、…、５０ｎ アプリケーションソフトウェア
６０ サービス部群
６０ａ、６０ｂ、６０ｃ、…、６０ｍ サービス部
６０ａａ、６０ｂａ、６０ｃａ、…、６０ｍａ インターフェース
７０ システムデータ群
７０ａ、７０ｂ、７０ｃ データ群
８０ 仮想サービス部
８０ａ インターフェース（サービス部都合）
８１ 仮想サービス部
８１ａ インターフェース（アプリケーション都合）
８１ｂ キャッシュメモリ
８２、８３ 仮想サービス部
８２ａ、８３ａ インターフェース（アプリケーション都合）
Claims (5)
- システムの特定の機能に対応するアプリケーションソフトウェアが、所定仕様のインターフェースをそれぞれ備えた１または複数のサービス部とデータの引用、検索、登録等のやりとりを行うアプリケーションソフトウェアとサービス部とのインターフェース方法において、
特定のアプリケーションソフトウェアに関連する各サービス部のインターフェースのうちの、当該特定のアプリケーションソフトウェアにおいて必要とされるデータに関連する部分のインターフェースのみを抜粋して、その抜粋したインターフェースの仕様を明確化した仮想サービス部を、当該特定のアプリケーションソフトウェアと、それと関連する各サービス部との間に介在させ、当該仮想サービス部がインターフェースを介して当該特定のアプリケーションソフトウェアからの引用、検索、登録等の要求をうけ、その要求に応じて当該特定のアプリケーションソフトウェアに関連する各サービス部との間でそれら各サービス部が備えるインターフェースを介して実際の引用、検索、登録等のやりとりを行うことで、当該特定のアプリケーションソフトウェアと、それに関連する各サービス部とが、前記仮想サービス部を介して間接的に引用、検索、登録等のやりとりを行うことを特徴とするアプリケーションソフトウェアとサービス部とのインターフェース方法。 - 前記仮想サービス部が備える、前記特定のアプリケーションソフトウェアに対するインターフェースを、前記特定のアプリケーションソフトウェアが自身に都合よく決めた仕様とすると共に、前記仮想サービス部は、前記特定のアプリケーションソフトウェアからの要求を解析して、前記特定のアプリケーションソフトウェアに関連する各サービス部のインターフェースに置換することを特徴とする請求項１に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法。
- 前記仮想サービス部を、複数のアプリケーションソフトウェアのうちの、単独で開発したいアプリケーションソフトウェアのそれぞれについて、各アプリケーションソフトウェアと、それら各アプリケーションソフトウェアと関連する各サービス部との間に介在させることを特徴とする請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法。
- 前記仮想サービス部はキャッシュメモリを備え、アプリケーションソフトウェアからのインターフェースを介したデータ引用要求の処理時に、当該データ引用要求に該当するデータが前記キャッシュメモリに格納されていない場合には、当該データ引用要求に相当するサービス部のインターフェースから得られるデータを前記キャッシュメモリに格納すると共に格納履歴を保持した上で、当該得られたデータを要求元のアプリケーションソフトウェア所望の形式に置換して通知する一方、当該データ引用要求に該当するデータが既に前記キャッシュメモリに格納されている場合には、当該キャッシュメモリに格納されているデータを、要求元のアプリケーションソフトウェア所望の形式に置換して通知することを特徴とする請求項２に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法。
- 前記キャッシュメモリを備えた仮想サービス部を、複数のアプリケーションソフトウェアのうちの、単独で開発したいアプリケーションソフトウェアのそれぞれについて、各アプリケーションソフトウェアと、それら各アプリケーションソフトウェアと関連する各サービス部との間に介在させることを特徴とする請求項４に記載のアプリケーションソフトウェアとサービス部とのインターフェース方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003144268A JP2004348397A (ja) | 2003-05-22 | 2003-05-22 | アプリケーションソフトウェアとサービス部とのインターフェース方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003144268A JP2004348397A (ja) | 2003-05-22 | 2003-05-22 | アプリケーションソフトウェアとサービス部とのインターフェース方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004348397A true JP2004348397A (ja) | 2004-12-09 |
Family
ID=33531752
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003144268A Pending JP2004348397A (ja) | 2003-05-22 | 2003-05-22 | アプリケーションソフトウェアとサービス部とのインターフェース方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004348397A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010528343A (ja) * | 2006-12-08 | 2010-08-19 | マイクロソフト コーポレーション | クローズドシステムにおける無署名コンテンツの実行とアクセスのセキュアリング |
| US8752067B2 (en) | 2008-07-30 | 2014-06-10 | Autonetworks Technologies, Ltd. | Control apparatus, control method and storage medium |
-
2003
- 2003-05-22 JP JP2003144268A patent/JP2004348397A/ja active Pending
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010528343A (ja) * | 2006-12-08 | 2010-08-19 | マイクロソフト コーポレーション | クローズドシステムにおける無署名コンテンツの実行とアクセスのセキュアリング |
| US8875271B2 (en) | 2006-12-08 | 2014-10-28 | Microsoft Corporation | Executing unsigned content and securing access in a closed system |
| US8752067B2 (en) | 2008-07-30 | 2014-06-10 | Autonetworks Technologies, Ltd. | Control apparatus, control method and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH09149076A (ja) | データ通信装置及び方法 | |
| CN101237505B (zh) | 控制成像设备的装置及方法 | |
| JP2006040061A (ja) | 画像処理装置、ネットワークシステム、情報処理方法、ならびにプログラム、記憶媒体 | |
| JP4030943B2 (ja) | 画像処理装置、画像処理システム、画像処理装置の制御方法、プログラム及び記録媒体 | |
| JP2004348397A (ja) | アプリケーションソフトウェアとサービス部とのインターフェース方法 | |
| US7782476B2 (en) | Image forming apparatus and facsimile data transfer method of image forming apparatus | |
| US8300247B2 (en) | Image processing apparatus and image processing method | |
| JPH06350791A (ja) | ファクシミリ装置 | |
| JP2586846B2 (ja) | ファクシミリ装置 | |
| JP4181276B2 (ja) | 画像通信方法およびファクシミリ装置 | |
| JP4606452B2 (ja) | 画像処理装置およびユーザ情報取得方法 | |
| JP4067478B2 (ja) | 画像処理装置およびユーザ情報取得方法 | |
| JP2004072162A (ja) | 画像通信装置およびジョブ管理方法およびコンピュータが読み取り可能な記憶媒体およびプログラム | |
| KR100242031B1 (ko) | 컴퓨터의 팩스데이터 관리방법 | |
| JP4416271B2 (ja) | 画像形成装置及び画像形成装置の制御方法 | |
| JP2008228202A (ja) | 画像処理装置およびプログラム | |
| JPH0897983A (ja) | ファクシミリ装置 | |
| JP3542495B2 (ja) | 画像形成装置管理システム | |
| JP2005275471A (ja) | サービス連携システム | |
| JPH01314467A (ja) | ファクシミリ通信システム | |
| CN101087357A (zh) | 图像处理装置和方法以及信息处理装置和方法 | |
| JP2004252542A (ja) | ネットワーク通信端末装置 | |
| JP2003032430A (ja) | ファクシミリ利用装置、ファクシミリ装置、ファクシミリ利用ネットワークシステム、ファクシミリ利用方法、ファクシミリ依頼処理方法、及び記憶媒体 | |
| JP2001084185A (ja) | データ処理装置、データ処理システムにおけるデータ処理方法及びコンピュータ可読記憶媒体 | |
| JPH09307688A (ja) | ファクシミリ制御システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Effective date: 20050707 Free format text: JAPANESE INTERMEDIATE CODE: A621 |
|
| A977 | Report on retrieval |
Effective date: 20071226 Free format text: JAPANESE INTERMEDIATE CODE: A971007 |
|
| A131 | Notification of reasons for refusal |
Effective date: 20080422 Free format text: JAPANESE INTERMEDIATE CODE: A131 |
|
| A521 | Written amendment |
Effective date: 20080620 Free format text: JAPANESE INTERMEDIATE CODE: A523 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080729 |
|
| A521 | Written amendment |
Effective date: 20080901 Free format text: JAPANESE INTERMEDIATE CODE: A523 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081118 |