JP2010072997A - 電子機器及びアプリケーション実行方法 - Google Patents

Abstract

【課題】 アプリケーションからＡＰＩを介して要求された機能が利用不可能なとき、この機能を利用しようとするような不適切な処理要求を阻止し、予測不可能な動作が実行されるのを防止する。
【解決手段】 アプリケーション１１により出力される処理要求情報に基づいて、ＡＰＩを用いて所定の機能を実行する電子機器であって、処理要求情報を入力し、この処理要求情報により指定された機能が利用可能であるか否かを判定し、この利用可否の判定結果に基づいてＡＰＩを制御するＡＰＩＩｍｐｌ１３と、ＡＰＩＩｍｐｌ１３により、処理要求情報により指定された機能が利用可能であると判定された場合に機能を実現する処理を実行するコントローラ１４とを備えた構成としてある。
【選択図】 図１

Description

本発明は、電子機器及びアプリケーション実行方法に関し、特に、アプリケーションからの指示によって、所定の機能を利用するときに、安定して所望の機能が提供される電子機器及びアプリケーション実行方法に関する。

一般に、複数の機能、例えば、コピー機能、ファクシミリ機能、スキャナ機能、プリンタ機能等を備えたＭＦＰ（Ｍｕｌｔｉｐｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）などの画像形成装置は、ネットワーク上で端末機や他の画像形成装置と接続され、広く使用されている。
このような各機能は、画像形成装置に組み込まれるアプリケーションによって利用され、さらに、アプリケーションが効率良く稼働するために、例えば、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）と呼ばれるインタフェースが提供されることが一般的に知られている。ＡＰＩは、機能の拡張（機能の追加、変更等）を可能とし、アプリケーションは、ＡＰＩを呼び出すことで機能を提供することができる。

また、上述した機能は、各機能において有効／無効と設定することによって、機能の利用可否を制限することができる。このような場合、画像形成装置で無効とされているにも拘らず機能が誤って呼び出され、処理されようとした場合にはアプリケーションの動作が不安定になるばかりか、データやメモリ、極端な場合はシステムを壊してしまう可能性がある。
例えば、画像形成装置がファクシミリ機能を利用できない場合（無効の場合）に、ＡＰＩの一つとしてファクシミリ機能が提供され、この機能をアプリケーションからＡＰＩを介して利用しようとすると、画像形成装置がどのような動作を行うかは予測不可能である。

そこで、このような問題を解消するべく、特許文献１に記載の発明が提案されている。この特許文献１には、アプリケーションが起動される際に、リソース情報を参照することによって、アプリケーションの起動可否を判断し、システムがリソース不足によって不安定になるのを未然に防ぐことができ、安定性を図ることができる装置及び方法が記載されている。

特開２００４−３０６０１号公報

しかしながら、特許文献１に記載の技術では、アプリケーションの起動時に、アプリケーションのサービス（機能）などが記録されたリソース情報と現在の複合機のリソースを比較することで起動判断が行われており、アプリケーションの起動中にサービス（機能）が何らかの理由で無効とされた場合には、動作が不安定になる場合がある。

本発明は、上記のような従来の技術が有する問題を解決するために提案されたものであり、処理要求情報に基づく機能が利用できるか否かを判定し、ＡＰＩを制御することで、不適切な処理の実行を防ぐとともに、予測不可能な動作の発生を防止して安定した利用を可能とする電子機器及びアプリケーション実行方法の提供を目的とする。

上記目的を達成するため、本発明の電子機器は、アプリケーションにより出力される処理要求情報に基づいて、ＡＰＩを用いて所定の機能を実行する電子機器であって、処理要求情報を入力し、この処理要求情報により指定された機能が利用可能であるか否かを判定し、この利用可否の判定結果に基づいてＡＰＩを制御するＡＰＩ制御手段と、ＡＰＩ制御手段により、処理要求情報により指定された機能が利用可能であると判定された場合に機能を実現する処理を実行する機能提供手段とを備えた構成としてある。

また、本発明のアプリケーション実行方法は、アプリケーションにより出力される処理要求情報に基づいて、ＡＰＩを用いて所定の機能を実行する電子機器におけるアプリケーション実行方法であって、処理要求情報を入力し、この処理要求情報により指定された機能が利用可能であるか否かを判定し、この利用可否の判定結果に基づいてＡＰＩを制御するＡＰＩ制御工程と、ＡＰＩ制御工程により、処理要求情報により指定された機能が利用可能であると判定された場合に機能を実現する処理を実行する機能提供工程とを備えた実行方法としてある。

本発明によれば、ＡＰＩ制御手段によって、アプリケーションから出力される処理要求情報に基づく機能が利用可能であるか否かが判定され、この判定結果に基づいてＡＰＩが制御される。
これによって、処理要求した機能が利用不可能であるときに、この機能を利用しようとするような不適切な処理要求を阻止し、予測不可能な動作が実行されるのを防止できる。

以下、本発明の好ましい実施形態について図面を参照して説明する。
ここで、以下に示す本実施形態では、本発明の電子機器として画像形成装置を適用して説明する。
[第一実施形態]

図１は、本発明の第一実施形態に係る画像形成装置の概略構成を示すブロック図である。
画像形成装置（ＭＦＰ）１０と端末機(４０、４１、…、４ｎ)は、通信回線としてのネットワーク３０を介して接続されており、処理データやコマンドの授受が相互に通信可能となっている。

ＭＦＰ１０は、アプリケーション１１、アプリケーション向けＡＰＩ１２、アプリケーション向けＡＰＩＩｍｐｌ１３、コントローラ１４、通信部１６、報知手段１７等を有している。また、ＭＦＰ１０は、図示しないが、アプリケーション１１を動作させるプラットフォームを備えている。

アプリケーション１１は、ＭＦＰ１０が備えるプリンタ、スキャナ、コピー、ファクシミリ等の種々の機能を利用することで、ユーザへサービスを提供するソフトウェアであり、ＭＦＰ１０の備える図示しないハードディスクなどにアプリケーションプログラムとして記憶されている。このハードディスクなどに記憶されたアプリケーションプログラムが、ＭＦＰ１０の備える図示しないＣＰＵによって読み出されて実行されることによって、アプリケーション１１としての機能を実現する。また、アプリケーション１１は、アプリケーション向けＡＰＩ１２を呼び出すことで、プリンタ、スキャナ、コピー、ファクシミリ等の種々の機能を利用可能とする。なお、アプリケーション１１は、ＭＦＰの出荷時に予め実装されるか又は出荷後に実装され、例えば、Ｊａｖａ（登録商標）アプリケーションとして実装される。

アプリケーション向けＡＰＩ（以下、ＡＰＩ）１２は、ＭＦＰ１０が備える各種機能を利用するためにアプリケーション向けに提供される。このＡＰＩ１２は、上述したプラットフォーム上で動作し、アプリケーション１１からの要求に応答して機能を提供する。
ここで、ＡＰＩ１２は、各機能を実現する処理を実行するための各コマンドにそれぞれ対応するインタフェースの集合となっている。通常、アプリケーション１１から利用するＯＳやプログラミング言語によって用意されたライブラリなどの機能の入口となるものであり、その多くは関数の形で提供される。すなわち、ＭＦＰの機能を利用するようなアプリケーション開発をする場合には、開発者は、機能制御に係る詳細なプログラム開発を行う必要はなく、予め用意されているＡＰＩ関数を指定して、利用したい機能に対応したＡＰＩを呼び出すことで所望の機能を利用することができる。

アプリケーション向けＡＰＩＩｍｐｌ（以下、ＡＰＩＩｍｐｌ）１３は、ＡＰＩ１２の実装部であり、プラットフォーム上で動作し、利用可否判定部１３０を備えている。このＡＰＩＩｍｐｌ１３は、ＭＦＰ１０が備える各機能を有効又は無効とする制御を行うモジュールであり、有効とされた機能はコントローラ１４によって実現され、無効とされた機能は実現されない。具体的には、利用可否判定部１３０の判定結果に基づいて、コントローラ１４との通信に使用するＡＰＩのクラス、及びインタフェースを有効又は無効に制御することにより、ＭＦＰ１０が備える各機能を制御する。
なお、ＡＰＩＩｍｐｌ１３は、本発明におけるＡＰＩ制御手段に相当する。

利用可否判定部１３０は、アプリケーション１１から出力されてきた処理要求情報において指定された機能が、同じく処理要求情報において指定されたＭＦＰ１０において利用可能であるか否かを判定する。具体的には、ＭＦＰ１０の各機能が有効であるか又は無効であるかを示す設定情報を含んだ、後述するクラス設定情報を参照することで、機能の利用可否判定を行う。

コントローラ１４は、アプリケーション１１から出力されてきた処理要求情報に基づく機能が利用可能（有効）である場合にその機能を実現する処理を実行する。
さらに、コントローラ１４は、ＭＦＰ１０の状態又はＭＦＰ１０が備える機能のステータス変更に係るイベントを監視する。例えば、ユーザによる有効／無効の機能切替え、電源オン／オフ、通信線接続／非接続などを監視する。なお、本実施形態においてイベントとは、ＭＦＰ１０に備えられた、図示しない各種センサ等によって、ＭＦＰ１０の状態が変化したことを認識できる情報である。
なお、コントローラ１４は、本発明における機能提供手段に相当する。

イベント通知手段１４０は、コントローラ１４が上述したイベントを取得したとき、このイベントに関する内容（例えば、機能が有効又は無効に変更）を含んだステータス情報をＡＰＩＩｍｐｌ１３へ通知する。これにより、後述する、クラス設定情報が、このステータス情報に対応づけて内容が更新されて、ＭＦＰ１０の最新の状態を保持する。

通信部１６は、ネットワーク３０に接続されており、ＭＦＰ１０とコントローラ１４間でデータの受け渡しをする機能を果たす。
報知手段１７は、アプリケーション１１より処理要求された機能が利用不可能な場合に、その旨のメッセージをユーザに報知する。具体的には、ポップアップメッセージ等を用いることによって、上記メッセージを図示しない表示操作部に出力してユーザへ通知する。

また、本実施形態におけるＡＰＩ管理システム１とは、アプリケーション１１、ＡＰＩ１２、ＡＰＩＩｍｐｌ１３、コントローラ１４で構成されている。

次に、本実施形態におけるＡＰＩ管理システムの詳細な構成について、図２を参照して説明する。
図２は、本発明の第一実施形態に係る画像形成装置におけるＡＰＩ管理システムの内部構成図を示している。

インタフェース１５は、ＡＰＩ１２へアクセスするための窓口の役割を果たしており、利用可能（有効）又は利用不可能（無効）と状態が変化する。
また、ＡＰＩＩｍｐｌ１３には、図示しないが、ＭＦＰ１０が備える各機能に対応した複数のクラスが実装されている。例えば、コピー機能に対応したコピークラス、プリンタ機能に対応したプリンタクラス、ファクシミリ機能に対応したファクシミリクラス等である。これらのクラスには、アクセス内容に応じて、その機能を制御する多数の動作を記述したメソッドが含まれている。

インタフェース１５は、ＭＦＰ１０が備える各種機能にアクセスするための規約が定義されており、クラスは、このインタフェース１５にそれぞれ対応して機能に応じた実装がされている。すなわち、ＡＰＩＩｍｐｌ１３に含まれるこれらのクラスが制御されると、ＡＰＩＩｍｐｌ１３とコントローラ１４間のインタフェース１５が利用可能（有効）又は利用不可能（無効）と状態が変化し、ＭＦＰ１０の機能が制限される。
なお、図２において、×で付されているインタフェース１５は利用不可能（無効）なインタフェースを示している。

次に、本実施形態におけるクラス設定情報について説明する。
図３は、本発明の第一実施形態に係るクラス設定情報の設定例を示す図である。

図３に示すように、クラス設定情報には、機能名とその機能に関連するクラスがマッピングリストとして記述されている。すなわち、クラス設定情報では、例えば、ファクシミリ機能、コピー機能、スキャナ機能に対応したクラスの利用可否を設定した構成となっており、ファクシミリ機能では、ＦＡＸクラスＡとして原稿読み込み機能、ＦＡＸクラスＢとして原稿送信機能、ＦＡＸクラスＣとして受信機能等のように設定される。
また、上述した利用可否判定部１３０は、このクラス設定情報に記述されている内容を参照することで判定を行う。さらに、このクラス設定情報は、ＡＰＩＩｍｐｌ１３内に予め定義されており、上述したイベント通知手段１４０によって送信されてくるステータス情報に対応づけて利用可否の内容が更新される。
なお、クラス設定情報の保有方法としては、例えばデータベースやＸＭＬファイル、ＣＶＳファイルとして保有される。

次に、以上のような構成からなる第一実施形態の画像形成装置におけるＡＰＩの制御動作について説明する。
図４は、本発明の第一実施形態に係る画像形成装置におけるＡＰＩ制御処理手順（アプリケーション実行方法）を示すフローチャートである。

例えば、アプリケーション１１から処理要求がされると、図４に示す処理フローが開始される。
まず、アプリケーション１１は、所望の機能を利用するために、インタフェース１５を介して処理要求情報に基づいた機能に対応するＡＰＩを呼び出す（ステップＳ１０）。続いて、この機能が実現される先のＭＦＰ１０において、利用できるか否かを判定するため、ＡＰＩＩｍｐｌ１３内に定義されているクラス設定情報を呼び出す（ステップＳ１１）。機能が実現される先のＭＦＰ１０とは、所望の機能を利用するために、アプリケーション１１から出力した処理要求情報において指定されたＭＦＰ１０であり、本実施形態においては、当該アプリケーション１１を有するＭＦＰ１０が指定される。

次に、利用可否判定部１３０において、ステップＳ１１で呼び出したクラス設定情報を参照して、処理要求情報に基づく機能が利用可能であるかを判定する（ステップＳ１２）。
ここで、機能が利用可能であると判定された場合は（ステップＳ１２：ＹＥＳ）、インタフェース１５が利用可能に制御され、ＡＰＩ１２からコントローラに対して、対応する機能を実現する処理の実行を依頼する（ステップＳ１３）。

一方、機能が利用不可能であると判定された場合は（ステップＳ１２：ＮＯ）、インタフェース１５が利用不可能に制御され、機能が提供できない。そして、コントローラ１４は、報知手段１７へ利用不可能であることを示すメッセージを報知させる（ステップＳ１４）。例えば、ＭＦＰ１０の図示しない表示操作部に「指定した出力先では、○○の機能は利用できません。」などのメッセージを表示する。他の方法として、例えば、警告音を出力することによって報知するなどのように、利用不可能である旨をユーザへ通知することができる方法であればよい。これによりユーザは、指定したＭＦＰ１０ではこの機能が利用できないことを認識できる。

次に、クラス設定情報の更新の方法について説明する。
図５は、本発明の第一実施形態に係るクラス設定情報の更新処理手順を示すフローチャートである。
まず、コントローラ１４が、ＭＦＰ１０の状態、ＭＦＰ１０が備える機能の有効又は無効などに関するイベントを取得すると、この取得したステータス情報がイベント通知手段１４０によって、ＡＰＩＩｍｐｌ１３に通知される（ステップＳ２０）。

続いて、ＡＰＩＩｍｐｌ１３内に定義されている、クラス設定情報を呼び出し（ステップＳ２１）、ＡＰＩＩｍｐｌ１３は、ステータス情報とクラス設定情報との内容が異なる場合に、クラス設定情報をステータス情報の内容に対応づけて書き換える（ステップＳ２２）。
これによって、クラス設定情報がＭＦＰ１０の状態や機能が有効とされた又は無効とされたかを示すステータス情報に対応づけて更新されるため、最新の状態で機能の利用可否判定をすることができる。

以上説明したように、本実施形態の画像形成装置によれば、処理要求をした機能が画像形成装置において利用可能であるか否かを判定し、判定結果に基づいてＡＰＩが提供する機能を制御することができる。このため、所望の機能が利用不可能である場合に、この機能が実現されることがなく、予測不可能な動作が発生することを防ぐことが可能となる。

［第二実施形態］
次に、本発明に係る画像形成装置の第二実施形態について説明する。
図６は、本発明の第二実施形態に係る画像形成装置の概略構成を示すブロック図である。

本実施形態は、第一実施形態と比較して記憶手段１８と代行処理選択指示部１９の構成が追加されている点で相違する。すなわち、本実施形態では、他のＭＦＰ１０において機能を代行処理するための構成として、記憶手段１８と代行処理選択指示部１９を付加してある。なお、本実施形態において、第一実施形態と同様の構成部分については同一の符号を付して、その詳細な説明を省略する。

ＭＦＰ１０は、記憶手段１８と代行処理選択指示部１９を有しており、これらは、コントローラ１４に接続されており、通信可能な構成となっている。なお、図６に示すように、ＭＦＰ１０がネットワーク３０上に複数台接続されている。

記憶手段１８は、処理要求された機能が実現される先のＭＦＰ１０において、利用可否判定部１３０によって利用不可能であると判定された場合に、アプリケーションから出力されてきた処理要求情報を記憶領域に格納する。
これは、例えば、ファクシミリ機能が実現される先のＭＦＰ１０において利用できない場合（無効の場合）に、他のＭＦＰ１０でファクシミリ機能を実現する処理を実行する場合、または、実行先のＭＦＰ１０が利用できるようになった場合に、処理要求情報を再利用することで、同じＭＦＰ１０で処理を再実行するために一時的に格納しておく。

代行処理選択指示部１９は、処理要求された機能が実現される先のＭＦＰ１０において、利用不可能である場合に、機能が利用可能な他のＭＦＰ１０で代行処理を行うか否かを選択するための操作部である。また、代行処理選択指示部１９が操作されることで、選択された情報をコントローラ１４へ出力する。

次に、以上のような構成からなる第二実施形態の画像形成装置におけるＡＰＩの制御動作について説明する。
図７は、本発明の第二実施形態に係る画像形成装置におけるＡＰＩ制御処理手順（アプリケーション実行方法）を示すフローチャートである。

例えば、アプリケーション１１から処理要求がされると、図７で示す処理フローが開始される。
まず、第一実施形態で説明したステップＳ１０〜ステップＳ１２（ＡＰＩの呼び出し〜機能の利用可否判定）が行われる。
ここで、ステップＳ１２において、処理要求された機能が実現される先のＭＦＰ１０において、利用可能であると判定された場合には（ステップＳ１２：ＹＥＳ）、第一実施形態で説明したステップＳ１３へ移り、コントローラ１４へ対応する機能を実現する処理の実行を依頼する。

一方、ステップＳ１２において、処理要求された機能が利用不可能であると判定された場合には（ステップＳ１２：ＮＯ）、第一実施形態で説明したステップＳ１４が実行されてユーザへの報知が行われる。続いて、記憶手段１８によって、アプリケーションから出力されてきた処理要求情報を記憶領域に一時的に格納する（ステップＳ１５）。この処理要求情報は、例えば、少なくとも処理要求された機能、指定した出力先などが対応して格納される。

次に、他のＭＦＰ１０で代行処理を行うか否かを代行処理選択指示部１９で選択する（ステップＳ１６）。このとき、代行処理選択指示部１９は、図示しない選択操作が可能な操作部を備えている。
代行処理選択指示部１９において、代行処理を行うと選択された場合（ステップＳ１６：ＹＥＳ）、続いて、コントローラ１４は、図示しない表示操作部へネットワーク３０上で機能が利用可能なＭＦＰ１０を表示する（ステップＳ１７）。そして、表示操作部から選択されたＭＦＰ１０へ記憶領域に格納されている処理要求情報を送信する（ステップＳ１８）。
これによって、ユーザは処理の実行先として指定したＭＦＰ１０で機能が利用不可能な場合であっても、ネットワーク上で機能が利用可能な他のＭＦＰ１０で代行して処理をすることができ、処理待ちに係る時間が軽減される。さらに、代行処理によって、ネットワーク上のリソースを有効活用することができる。

一方、ステップＳ１６において、代行処理選択指示部１９で代行処理を行わないと選択された場合（ステップＳ１６：ＮＯ）、当初、処理要求情報を出力したＭＦＰ１０で再実行を行うため、機能が利用可能になるまで待機をする（ステップＳ１９）。そして、機能が利用可能となった場合（ステップＳ１９：ＹＥＳ）、ステップＳ１３へ移り、記憶領域に格納されている処理要求情報に基づく機能が再実行される。ここで、実行が完了したときに、処理要求情報は記憶領域から削除される。
これによって、例えば、トナー・用紙切れ、紙詰まり等の一時的に利用不可能な場合やＭＦＰ１０の利用が混んでいるときでも、機能が利用できるようになったこと（有効化された）をキャッチし、格納された処理要求情報を再利用することで、ユーザが所望した機能を実現する処理を再実行することができる。

また、処理要求情報が記憶領域から削除されるタイミングとして、例えば、代行処理先に送信が完了した場合、ユーザによって一定時間操作キーが選択されなかった場合、あるいは、強制的に操作を終了した場合などのタイミングで削除されることにしてもよい。

以上のように、本実施形態の画像形成装置によれば、処理要求をした機能が利用不可能である場合に、他の画像形成装置において代行処理を実行することができる。さらに、一時的に機能が利用不可能な場合などで実行を待機する場合でも、機能が有効化されたことをキャッチし、格納された処理要求情報を再利用することで再実行することができる。

以上、本発明の電子機器及びアプリケーション実行方法について好ましい実施形態を示して説明したが、本発明にかかる装置は、上述した実施形態にのみ限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。

例えば、本実施形態では、ＭＦＰを例として説明しているが、これに限らず、ＡＰＩを有する装置であれば、例えば、プリンタ、コピー機、ファクシミリ、スキャナの単独で有する装置であってもよく、また、これらを各種組み合わせた装置であってもよい。さらに、プリンタは、インクジェットプリンタ、昇華型熱転写方式プリンタ、ドットインパクトプリンタ、インクジェット式プリンタ、レーザプリンタ、溶融型熱転写方式プリンタなど、各種のプリンタ方式を備えたプリンタであってもよい。

本発明は、電子機器が備える機能を利用する際のＡＰＩの制御に関する発明であるため、プリンタ、ファクシミリ、コピー機など画像形成を行う機器や情報処理装置に利用可能である。

本発明の第一実施形態に係る画像形成装置の概略構成を示すブロック図である。 本発明の第一実施形態に係る画像形成装置におけるＡＰＩ管理システムの内部構成図である。 本発明の第一実施形態に係るクラス設定情報の設定例を示す図である。 本発明の第一実施形態に係る画像形成装置におけるＡＰＩ制御処理手順（アプリケーション実行方法）を示すフローチャートである。 本発明の第一実施形態に係るクラス設定情報の更新処理手順を示すフローチャートである。 本発明の第二実施形態に係る画像形成装置の概略構成を示すブロック図である。 本発明の第二実施形態に係る画像形成装置におけるＡＰＩ制御処理手順（アプリケーション実行方法）を示すフローチャートである。

符号の説明

１ ＡＰＩ管理システム
１０ 画像形成装置（ＭＦＰ）
１１ アプリケーション
１２ アプリケーション向けＡＰＩ
１３ アプリケーション向けＡＰＩＩｍｐｌ
１３０ 利用可否判定部
１４ コントローラ
１４０ イベント通知手段
１５ インタフェース
１６ 通信部
１７ 報知手段
１８ 記憶手段
１９ 代行処理選択指示部
３０ ネットワーク
４０(４１、・・、４ｎ) 端末機（ＰＣ）

Claims (7)

1. アプリケーションにより出力される処理要求情報に基づいて、ＡＰＩを用いて所定の機能を実行する電子機器であって、
   前記処理要求情報を入力し、この処理要求情報により指定された機能が利用可能であるか否かを判定し、この利用可否の判定結果に基づいて前記ＡＰＩを制御するＡＰＩ制御手段と、
   前記ＡＰＩ制御手段により、前記処理要求情報により指定された機能が利用可能であると判定された場合に当該機能を実現する処理を実行する機能提供手段と、
   を備えたことを特徴とする電子機器。
2. 前記ＡＰＩ制御手段が、前記利用可否の判定を行う利用可否判定部を有し、この利用可否判定部により前記電子機器の所定の機能が有効又は無効である設定を含んだクラス設定情報に基づいて、判定を行うことを特徴とする請求項１記載の電子機器。
3. 前記機能提供手段は、前記電子機器の状態又は機能のステータスが変更されるイベントを監視し、この変更の内容を含んだステータス情報を前記ＡＰＩ制御手段へ通知するイベント通知手段を備え、
   前記クラス設定情報が、前記ステータス情報に対応づけて内容が更新されることを特徴とする請求項２記載の電子機器。
4. 請求項２又は３記載の電子機器がネットワークに接続され、
   前記利用可否判定部により、前記機能が利用不可能であると判定された場合に、前記処理要求情報を記憶する記憶手段と、前記機能が利用可能である他の電子機器において代行処理を行うか否かを選択する代行処理選択指示部とを更に備え、
   前記代行処理選択指示部において、代行処理を行うと選択された場合に、選択された所望の他の電子機器へ前記処理要求情報を前記ネットワークを介して送信し、当該他の電子機器により代行処理を実行することを特徴とする電子機器。
5. 前記利用可否判定部により、前記機能が利用不可能であると判定された場合に、利用不可能である旨を出力する報知手段を備えたことを特徴とする請求項２〜４のいずれか一項に記載の電子機器。
6. 前記代行処理選択指示部において、代行処理を行わないと選択された場合に、最初に前記機能を実行した電子機器において、前記機能が利用可能になるまで待機することを特徴とする請求項４又は５記載の電子機器。
7. アプリケーションにより出力される処理要求情報に基づいて、ＡＰＩを用いて所定の機能を実行する電子機器におけるアプリケーション実行方法であって、
   前記処理要求情報を入力し、この処理要求情報により指定された機能が利用可能であるか否かを判定し、この利用可否の判定結果に基づいて前記ＡＰＩを制御するＡＰＩ制御工程と、
   前記ＡＰＩ制御工程により、前記処理要求情報により指定された機能が利用可能であると判定された場合に当該機能を実現する処理を実行する機能提供工程と、
   を備えたことを特徴とするアプリケーション実行方法。

Images