JP5065805B2 - 電子機器、サービス提供方法及びプログラム - Google Patents

Description

本発明は、アプリケーションによるサービスをユーザに提供可能な電子機器、サービス提供方法及びプログラムに関するものである。

この種の電子機器、例えば画像形成装置にはアプリケーションがインストールされており、このアプリケーションは当該装置のデバイス（例えば、プリンタ、スキャナやＦＡＸ等）を用いてサービスをユーザに提供する。

ここで、当該サービスの提供に関しては種々の技術が開示されている（例えば、特許文献１〜４参照）。具体的には、アプリケーションがコントローラＡＰＩ（Controller Application Program Interface）を呼び出し、このコントローラＡＰＩはデバイスの操作をコントローラに要求する。そして、このコントローラがデバイスを操作すると、アプリケーションによるサービスがユーザに提供される。

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

ところで、上述したアプリケーションは、ＡＰＩ（Application Program Interface）を使用して提供元で予め作成され、画像形成装置にインストールされるが、当該ＡＰＩのバージョン情報が装置内のコントローラＡＰＩのバージョン情報よりも新しい場合には、当該アプリケーションが起動しないとの問題がある。

詳しくは、上記特許文献１，２の技術では、バージョン情報の違いについては格別な配慮がなされておらず、ＡＰＩがコントローラＡＰＩよりも新しいバージョン情報であった場合には、このアプリケーションは起動しない。なお、特許文献２の技術では、動作しない画像形成装置を代行するための別の画像形成装置も必要になる。

これに対し、上記特許文献３，４の技術では、バージョン情報の違いについては示されている。しかしながら、特許文献３の技術では、ＡＰＩとコントローラＡＰＩとの各バージョン情報を単にチェックするのみであり、これらの各バージョン情報が一致しない場合には、アプリケーションが装置にインストールされず、このアプリケーションは起動しない。

また、特許文献４の技術では、複数のバージョン情報に対応可能なコントローラＡＰＩを有しているが、仮に、ＡＰＩがコントローラＡＰＩでは対応できないバージョン情報で構成されていた場合には、このＡＰＩを使用して作成されたアプリケーションは起動しないことになる。

そこで、本発明の目的は、上記課題を解消し、ＡＰＩのバージョン情報がコントローラＡＰＩのバージョン情報よりも新しい場合であっても、アプリケーションを起動させる電子機器、サービス提供方法及びプログラムを提供することである。

上記目的を達成するための第１の発明は、コントローラを介してデバイスを制御する電子機器に係り、ＡＰＩ（Application Program Interface）を使用して作成されており、デバイスを操作してサービスをユーザに提供し、電子機器の動作時に選択されるアプリケーションを管理する管理部と、これらアプリケーションとＡＰＩとの関連付け情報を記憶する記憶部と、アプリケーションに呼び出され、デバイスの操作をコントローラに要求するコントローラＡＰＩ（Controller Application Program Interface）と、選択されたアプリケーションとＡＰＩとの関連付け情報に基づいてアプリケーションに呼び出されており、ＡＰＩのバージョン情報がコントローラＡＰＩのバージョン情報よりも新しい場合には、コントローラＡＰＩに未実装のインタフェースでコントローラＡＰＩに対してデバイスの操作をコントローラに要求させるフォローＡＰＩとを具備する。

第１の発明によれば、電子機器はコントローラＡＰＩ、コントローラ、及びデバイスを備えている。また、この電子機器はアプリケーションを管理する管理部を備え、このアプリケーションはサービスをユーザに提供する。詳しくは、アプリケーションがコントローラＡＰＩを呼び出し、このコントローラＡＰＩはデバイスの操作をコントローラに要求しており、コントローラがデバイスを操作すると、アプリケーションによるサービスがユーザに提供される。

ここで、このアプリケーションはＡＰＩを使用して作成されているが、当該ＡＰＩのバージョン情報がコントローラＡＰＩのバージョン情報よりも新しい場合には、当該アプリケーションが起動しないとの懸念がある。電子機器に搭載されているコントローラＡＰＩが、バージョン情報の新しいＡＰＩに対応したインタフェースを実装していないためである。

しかしながら、本発明の電子機器はフォローＡＰＩを備えており、このフォローＡＰＩが、コントローラＡＰＩに未実装のインタフェースを実装しているので、当該アプリケーションは起動可能になる。
しかも、このフォローＡＰＩが、これらアプリケーションの作成に使用したＡＰＩとコントローラＡＰＩとのバージョン情報の差を解消するので、アプリケーション自体を電子機器のモデル毎に開発しなくて済む。
さらに、電子機器は管理部や記憶部も備え、記憶された関連付け情報に基づき、選択されたアプリケーションの起動及びフォローＡＰＩの呼び出しが実行されるので、当該アプリケーションは確実に起動することができる。

第２の発明は、第１の発明の構成において、フォローＡＰＩは、アプリケーションによるサービスとは異なる擬似サービスをユーザに提供することを特徴とする。
第２の発明によれば、第１の発明の作用に加えてさらに、ＡＰＩのバージョン情報がコントローラＡＰＩのバージョン情報よりも新しい場合であっても、擬似サービスはユーザに提供されるので、アプリケーションの起動が明らかになる。この結果、ユーザの所望するサービスの早期完了化が可能になるし、電子機器の信頼性向上にも寄与する。

第３の発明は、第１の発明の構成において、フォローＡＰＩは、アプリケーションによるサービスを提供できない旨をユーザに知らせることを特徴とする。
第３の発明によれば、第１の発明の作用に加えてさらに、アプリケーションによるサービスを提供できない旨がユーザに知らされることから、この場合にもアプリケーションの起動が明らかになる。

第４の発明は、第１から第３の発明の構成において、フォローＡＰＩは、アプリケーションに同梱されており、アプリケーションが電子機器にインストールされる時点にて、ＡＰＩのバージョン情報がコントローラＡＰＩのバージョン情報よりも新しい場合にのみ、アプリケーションとともに電子機器にインストールされることを特徴とする。
第４の発明によれば、第１から第３の発明の作用に加えてさらに、フォローＡＰＩは、当該フォローＡＰＩが必要になる場合にのみ、アプリケーションとともに電子機器にインストールされるので、電子機器の能力低下も防止可能になる。

また、第５の発明は、電子機器がコントローラを介してデバイスを制御し、アプリケーションによるサービスをユーザに提供する方法に係り、電子機器は、その動作時に選択される複数のアプリケーションを管理する管理部と、アプリケーションとアプリケーションの作成時に使用したＡＰＩとの関連付け情報を記憶する記憶部とを備えており、電子機器が、コントローラＡＰＩのバージョン情報よりも新しいバージョン情報で構成されたＡＰＩを使用して作成したアプリケーションの起動をユーザから要求されるステップと、管理部が、記憶された関連付け情報を読み込むステップと、管理部が、起動の要求されたアプリケーションに対し、関連付け情報に基づいてアプリケーションの起動する旨を通知するとともに、コントローラＡＰＩに未実装のインタフェースを有するフォローＡＰＩを呼び出す旨を通知するステップと、起動の要求されたアプリケーションが、フォローＡＰＩを呼び出すステップと、フォローＡＰＩがコントローラＡＰＩを呼び出すステップと、コントローラＡＰＩが、デバイスの操作をコントローラに要求するステップと、コントローラが、デバイスを操作するステップとから構成される。

さらに、第６の発明は、電子機器がコントローラを介してデバイスを制御し、アプリケーションによるサービスをユーザに提供するプログラムに係り、電子機器は、その動作時に選択される複数のアプリケーションを管理する管理部と、アプリケーションとアプリケーションの作成時に使用したＡＰＩとの関連付け情報を記憶する記憶部とを備え、プログラムは、電子機器のコンピュータに備えられており、電子機器が、コントローラＡＰＩのバージョン情報よりも新しいバージョン情報で構成されたＡＰＩを使用して作成したアプリケーションの起動をユーザから要求される手順と、管理部が、記憶された関連付け情報を読み込む手順と、管理部が、起動の要求されたアプリケーションに対し、関連付け情報に基づいてアプリケーションの起動する旨を通知するとともに、コントローラＡＰＩに未実装のインタフェースを有するフォローＡＰＩを呼び出す旨を通知する手順と、起動の要求されたアプリケーションが、フォローＡＰＩを呼び出す手順と、フォローＡＰＩがコントローラＡＰＩを呼び出す手順と、コントローラＡＰＩが、デバイスの操作をコントローラに要求する手順と、コントローラが、デバイスを操作する手順とを実行させる。

これら第５や第６の発明によれば、フォローＡＰＩがコントローラＡＰＩに未実装のインタフェースを実装しており、ＡＰＩのバージョン情報がコントローラＡＰＩのバージョン情報よりも新しい場合であっても、当該ＡＰＩを使用して作成されたアプリケーションは起動可能になる。
しかも、このフォローＡＰＩが、これらアプリケーションの作成に使用したＡＰＩとコントローラＡＰＩとのバージョン情報の差を解消するので、アプリケーション自体を電子機器のモデル毎に開発しなくて済む。

さらに、管理部が、起動の要求されたアプリケーションに対し、記憶された関連付け情報に基づいてその起動及びフォローＡＰＩを呼び出す旨を通知するので、当該アプリケーションは確実に起動することができる。

本発明によれば、アプリケーションの作成に使用したＡＰＩとコントローラＡＰＩとのバージョン情報の差を解消し、当該アプリケーションを起動させる電子機器、サービス提供方法及びプログラムを提供することである。

以下、本発明の好適な実施形態について図面を用いて説明する。
図１は、本実施例におけるシステム構成図である。当該システムは複数の画像形成装置やパーソナルコンピュータ等の電子機器の他、サーバ５０を有し、これらはインターネット４０に接続されている。

サーバ５０はアプリケーションの提供者が保有しており、そのデータベース５０ａにはアプリケーションパッケージ６０が格納されている。このパッケージ６０はユーザからの要求に応じて画像形成装置に配布され、このユーザは当該装置をインターネット４０に接続した状態で利用することができる。

本実施例の画像形成装置は、いわゆる多機能周辺機器（Multiple Function Peripheral、以下、ＭＦＰと称する）１０、すなわち、デジタル複合機である。このＭＦＰ１０は、そのデバイスとして複写機の他、プリンタ２２、スキャナ２４、及びファクシミリ（ＦＡＸ）２６を備えている。
より具体的には、プリンタ２２は、原稿の複写物やＦＡＸ２６にて受信した文書等を印刷し、スキャナ２４は原稿を読み取り、複写やＦＡＸ送信を行うための画像データを生成している。

また、ＭＦＰ１０は、これらプリンタ２２、スキャナ２４やＦＡＸ２６の機能に加え、ネットワークプリンタやネットワークスキャナ、或いはネットワーククライアントとしての機能も複合的に備えている。なお、ネットワーク対応のプリンタ機能やスキャナ機能等は、インターネット１０２とは別のネットワーク環境（ＬＡＮ，ＷＡＮ）を通じて使用される。

ＭＦＰ１０の基本的な構成は公知のものが適用可能である。すなわち、ＭＦＰ１０は、上記構成の他、原稿をスキャナ２４の画像読取位置に搬送する自動原稿搬送装置（ＡＳＦ）、用紙を供給する用紙供給部、画像データに基づいて形成した画像を用紙に転写するプリントエンジン、転写済みの用紙にソート、穴開けやステープル処理等を行う後処理装置等を備えている。

また、ＭＦＰ１０は、ユーザの操作を受け付けるための操作キーや操作パネルも備えている。このパネルには、タッチ操作用のボタンの他、文字情報や案内画像等が表示されている。
そして、上述したＭＦＰ１０の各種動作はコントローラ２０で制御される。このコントローラ２０はコンピュータとして機能する要素であり、ＣＰＵやメモリデバイス等のハードウエア資源を有している。

コントローラ２０は、このハードウエア資源や基本ソフトウェアであるＯＳ（Operating System）１１を用いて所定のプログラムを実行しており、ＯＳ１１を介して上述のプリンタ２２、スキャナ２４やＦＡＸ２６の各デバイスを操作する。なお、ＯＳ１１はネットワーク制御部１１ａを有し、この制御部１１ａは、所定のプロトコルを用いてインターネット４０等に接続可能に構成されている。

一方、ＭＦＰ１０は複数のＪａｖａ（登録商標）アプリケーション１８ａ，１８ｂ，１８ｃを有している。
このアプリケーション１８ａ〜１８ｃは、パッケージ６０のダウンロードによってＭＦＰ１０に配布されており、ＭＦＰ１０を用いた各種のサービスをユーザに提供している。

詳しくは、ＭＦＰ１０には、Ｊａｖａ（登録商標）仮想マシン１２、コントローラＡＰＩ（Controller Application Program Interface）１４、及びアプリケーション管理部（管理部）１６が設けられている。
そして、ユーザに選択された各アプリケーション１８ａ〜１８ｃは、管理部１６にてその起動が要求され、この要求された各アプリケーション１８ａ〜１８ｃはコントローラＡＰＩ１４を呼び出している。

このコントローラＡＰＩ１４は、仮想マシン１２を通じてプリンタ２２、スキャナ２４やＦＡＸ２６の操作をコントローラ２０に要求しており、このコントローラ２０がプリンタ２２、スキャナ２４やＦＡＸ２６を操作することにより、アプリケーション１８ａ〜１８ｃによるＭＦＰ１０を用いた各種のサービスがユーザに提供される。

ところで、本実施例のＭＦＰ１０はアプリケーション１８ａ〜１８ｃを補足するサブアプリケーションを備えている。
具体的には、図２に示されるように、アプリケーション１８ａ〜１８ｃとコントローラＡＰＩ１４との間にはＡＰＩフォローＡＰＩ（フォローＡＰＩ）１９が配置されており、このフォローＡＰＩ１９はコントローラＡＰＩ１４を呼び出す機能を有している。

より詳しくは、アプリケーション１８ａ〜１８ｃはその提供者側にて作成され、この作成にはＡＰＩ（Application Program Interface）が使用されている。例えば、図３にはアプリケーション１８ｂ（以下、アプリ（２）と称する）を有するパッケージ６０が示されており、このアプリ（２）の作成には、バージョン情報Ｖ２．００のＡＰＩが使用されている。

また、同図に示される如く、パッケージ６０には、フォローＡＰＩ１９及びインストーラ６２が当該アプリ（２）とともに同梱されている。ＭＦＰ１０の例えば購入時にはフォローＡＰＩ１９は配置されておらず、このフォローＡＰＩ１９は必要に応じてＭＦＰ１０内に配置されるからである。
より具体的には、図４のパッケージ６０のインストールまでのフローチャートを用いて説明する。

同図のステップＳ４０１では、ＭＦＰ１０がインターネット４０を経由してパッケージ６０をダウンロードする。次に、ステップＳ４０２では、ＭＦＰ１０がパッケージ６０のインストーラ６２を起動し、ステップＳ４０３に進む。
このステップＳ４０３では、インストーラ６２がフォローＡＰＩ１９をＭＦＰ１０内に配置するか否かを判別する。詳しくは、インストーラ６２は、コントローラＡＰＩ１４のレベルをチェックし、アプリ（２）の作成に使用されたＡＰＩのバージョン情報がコントローラＡＰＩ１４のバージョン情報よりも新しい（番号が大きい）場合には、フォローＡＰＩ１９をＭＦＰ１０内に配置する旨を決定する。

例えば、上述のように、アプリ（２）のＡＰＩはバージョン情報Ｖ２．００であるのに対し、ＭＦＰ１０内のコントローラＡＰＩ１４がバージョン情報Ｖ１．００であった場合には、ステップＳ４０３にて、インストーラ６２はＹＥＳと判定する。コントローラＡＰＩ１４に対応できないアプリ（２）をＭＦＰ１０にインストールしなければ、アプリ（２）は起動できないからである。

次いで、ステップＳ４０４に進み、アプリ（２）及びフォローＡＰＩ１９をＭＦＰ１０にインストールし、ステップＳ４０５に進む。
このステップＳ４０５では、インストーラ６２が新規にインストールしたアプリケーションを登録する。詳しくは、このアプリ（２）をインストールした場合には、フォローＡＰＩ１９もインストールされているので、アプリ（２）の起動にはフォローＡＰＩ１９を使用することになる。そこで、このインストーラ６２は、アプリ（２）についてはフォローＡＰＩ１９を使用する旨を登録する（図５に○で示す）。

これに対し、仮に、アプリケーション１８ａ（以下、アプリ（１）と称する）を有する他のパッケージ６０がデータベース５０ａに準備されており、このアプリ（１）の作成にはバージョン情報Ｖ１．００のＡＰＩが使用されていたとすれば、これらアプリ（１）のＡＰＩ及びコントローラＡＰＩ１４はバージョン情報がいずれもＶ１．００であることから、ステップＳ４０３にて、このインストーラ６２はＮＯと判定する。

つまり、この場合には、当該パッケージ６０に同梱されたフォローＡＰＩ１９をＭＦＰ１０内に配置せず、アプリ（１）だけをＭＦＰ１０にインストールしてステップＳ４０５に進む。そして、ステップＳ４０５では、フォローＡＰＩ１９はインストールされていないことから、インストーラ６２が、アプリ（１）についてはフォローＡＰＩを使用しない旨を登録する（図５に×で示す）。

これら図５に示されたアプリケーションとフォローＡＰＩとの関連付けは、記憶部１７に登録される（図６）。本実施例の記憶部１７は管理部１６に設けられている。なお、この関連付け情報は、ＭＦＰ１０内に設けられた他の記録領域に登録されていても良い。
次に、この図６には、インストール後のイベントフローチャートが示されており、以下、上記の如く構成されたＭＦＰ１０の本発明に係る作用について説明する。また、これにより、ＭＦＰ１０によるサービスの提供方法や提供プログラムも明確になる。

まず、ユーザが仮に２ｕｐ（印刷レイアウトのページ集約２）印刷を希望しており、ＭＦＰ１０が、アプリ（１）の起動をユーザから要求された場合には、管理部１６は、記憶部１７に登録された関連付け情報（アプリ（１）はフォローＡＰＩを使用しない旨）を読み込む。次いで、この管理部１６は、アプリ（１）に対し、その起動及びコントローラＡＰＩ１４を呼び出す旨を通知する。

続いて、このアプリ（１）がコントローラＡＰＩ１４を呼び出すと、コントローラＡＰＩ１４はプリンタ２２の操作をコントローラ２０に要求する。そして、コントローラ２９がプリンタ２２を操作し、ユーザ所望の２ｕｐ印刷された用紙を当該ユーザに提供する。
これに対し、ユーザが仮に２ｕｐ印刷、且つ、両面印刷を希望し、ＭＦＰ１０がアプリ（２）の起動をユーザから要求された場合には、このアプリ（２）の起動は確保する。

詳しくは、この場合の管理部１６は、記憶部１７に登録された関連付け情報（アプリ（２）はフォローＡＰＩ１９を使用する旨）を読み込み、当該アプリ（２）に対し、その起動及びアプリ（２）がフォローＡＰＩ１９を呼び出す旨を通知する。
続いて、このアプリ（２）は、フォローＡＰＩ１９及びコントローラＡＰＩ１４を呼び出すと、フォローＡＰＩ１９がアプリ（２）を起動するとともに、コントローラＡＰＩ１４が、プリンタ２２の操作をコントローラ２０に要求する。そして、コントローラ２９はプリンタ２２を操作するが、この場合には両面印刷は行われず、上記と同様に、２ｕｐ印刷された用紙を当該ユーザに提供する。

以上のように、本実施例によれば、このアプリ（２）は、ＡＰＩを使用して提供元で予め作成されているが、当該ＡＰＩのバージョン情報がコントローラＡＰＩ１４のバージョン情報よりも新しい場合には、当該アプリ（２）が起動しないとの懸念がある。

詳しくは、図７に示されるように、アプリケーションの作成時に使用したＡＰＩのバージョン情報とコントローラＡＰＩ１４のバージョン情報とが同じ場合、若しくは、このＡＰＩのバージョン情報がコントローラＡＰＩ１４のバージョン情報よりも古い（番号が小さい）場合には、当該アプリケーションはプリンタ２２、スキャナ２４やＦＡＸ２６の各デバイスを正常に操作できる（図７に○で示す）。

一方、上述のアプリ（２）の如く、このＡＰＩのバージョン情報Ｖ２．００がコントローラＡＰＩ１４のバージョン情報Ｖ１．００よりも新しい場合には、当該アプリケーションは上記各デバイスを正常に操作できない（図７に×で示す）。
より具体的には、図８に示されるように、アプリ（２）がコントローラＡＰＩ１４を呼び出そうとしても、ＭＦＰ１０内で不変のコントローラＡＰＩ１４がインタフェース（Ａ，Ｂ）だけを実装し、バージョン情報の新しいＡＰＩに対応したインタフェース（Ｃ，Ｄ）を実装していないため、当該アプリ（２）は起動すらできないことになる。

そして、アプリ（２）が起動しなければ、ユーザが所望するサービスの早期完了化は困難になる。
なぜならば、ユーザがその起動を要求したにも拘わらず、アプリ（２）が起動しない場合には、現在の状況がコントローラＡＰＩ１４に対応していないアプリ（２）がＭＦＰ１０にインストールされたのか、或いは、アプリ（２）のインストールがＭＦＰ１０に未だ完了していないのかが不明になり、ここで、万一、後者のインストールの未完了状態であった場合には、当該アプリ（２）を改めてＭＦＰ１０にインストールする必要があり、ユーザ所望のサービスが完了するまでには長い期間を要するからである。

しかしながら、本実施例では、図９に示される如く、当該アプリ（２）の起動が要求された場合にはフォローＡＰＩ１９がＭＦＰ１０に配置される。そして、このフォローＡＰＩ１９は、アプリ（２）の作成に使用されたＡＰＩを補い、コントローラＡＰＩ１４に未実装であって、アプリ（２）の作成に使用されたＡＰＩに対応した仮のインタフェース（Ｃ´，Ｄ´）を実装しており、これにより、アプリ（２）は起動可能になる。

しかも、このフォローＡＰＩ１９が、これらアプリ（２）の作成に使用したＡＰＩとコントローラＡＰＩ１４とのバージョン情報の差を解消するので、アプリ（２）自体をＭＦＰ１０のモデル毎に開発しなくて済む。
但し、当該アプリ（２）の作成時に使用したＡＰＩのバージョン情報とコントローラＡＰＩ１４のバージョン情報とが同じではないので、本実施例で云えば、このＭＦＰ１０では両面印刷は実行できない。

そこで、フォローＡＰＩ１９は、上述した仮のインタフェース（Ｃ´，Ｄ´）を用い、アプリ（２）によるサービスとは異なる擬似サービス、例えば、ユーザ希望のサービスに完全には一致しないものの、２ｕｐ印刷された用紙を当該ユーザに提供している。

これにより、アプリ（２）の起動は明らかになり、ユーザは、現在の状況がコントローラＡＰＩ１４に対応していないアプリ（２）がＭＦＰ１０にインストールされた旨を認識する。この結果、当該アプリ（２）を改めてＭＦＰ１０にインストールする必要がなくなり、ユーザの所望するサービスの早期完了化が可能になるし、現在の状況が明らかになってＭＦＰ１０の信頼性向上にも寄与する。

また、フォローＡＰＩ１９は、このフォローＡＰＩ１９が必要になる場合にのみ、アプリ（２）とともにＭＦＰ１０にインストールされる。よって、多くのＡＰＩをＭＦＰ１０に保持する必要がないことから、ＭＦＰ１０の能力低下も防止可能になる。
さらに、管理部１６が、起動の要求されたアプリ（２）に対し、記憶された関連付け情報に基づいてその起動及びフォローＡＰＩ１９を呼び出す旨を通知するので、当該アプリ（２）は確実に起動する。

本発明は、上記実施例に限定されず、特許請求の範囲を逸脱しない範囲で種々の変更を行うことができる。
例えば、上記実施例では、フォローＡＰＩ１９はアプリ（２）によるサービスとは異なる擬似サービスをユーザに提供しているが、必ずしもこの形態に限定されるものではなく、アプリ（２）によるサービスを提供できない旨をユーザに知らせても良く、この場合にもアプリ（２）の起動は明らかになる。

また、当該フォローＡＰＩ１９によるユーザへの振る舞いは、アプリケーションを起動させる限り、このアプリケーションの作成者が自由に決定できる。
さらに、当該フォローＡＰＩ１９はＭＦＰ１０内に複数配置されていても良い。この場合には、ＡＰＩとアプリケーションとの関連付けの際に、アプリケーション毎に異なるＡＰＩを関連付けることができる。

本実施例のＭＦＰを有するシステム構成図である。 図１のＭＦＰの具体的な構成図である。 図１のアプリケーションをインストールする際に用いられるパッケージの説明図である。 図３のパッケージを用いたインストールまでのフローチャートである。 図４にてインストールされたアプリケーションとフォローＡＰＩとの関連付け情報の説明図である。 図４にてインストールされた後のイベントフローチャートである。 従来におけるアプリケーションが使用したＡＰＩとコントローラＡＰＩとの関係の説明図である。 従来におけるアプリケーション及びコントローラＡＰＩの関係を示す図である。 図６におけるアプリケーション、フォローＡＰＩ及びコントローラＡＰＩの関係を示す図である。

符号の説明

１０ ＭＦＰ（電子機器）
１４ コントローラＡＰＩ
１６ アプリケーション管理部（管理部）
１７ 記憶部
１８ｂ アプリ（２）（アプリケーション）
１９ ＡＰＩフォローＡＰＩ（フォローＡＰＩ）
２０ コントローラ
２２ プリンタ（デバイス）
２４ スキャナ（デバイス）
２６ ＦＡＸ（デバイス）
６０ アプリケーションパッケージ
６２ インストーラ

Claims (6)

1. コントローラを介してデバイスを制御する電子機器であって、
   ＡＰＩを使用して作成されており、前記デバイスを操作してサービスをユーザに提供し、前記電子機器の動作時に選択されるアプリケーションを管理する管理部と、
   該アプリケーションと前記ＡＰＩとの関連付け情報を記憶する記憶部と、
   該アプリケーションに呼び出され、該デバイスの操作を前記コントローラに要求するコントローラＡＰＩと、
   前記関連付け情報に基づいて該アプリケーションに呼び出されており、前記ＡＰＩのバージョン情報が前記コントローラＡＰＩのバージョン情報よりも新しい場合には、該コントローラＡＰＩに未実装のインタフェースで前記コントローラＡＰＩに対して前記デバイスの操作を前記コントローラに要求させるフォローＡＰＩと
   を具備することを特徴とする電子機器。
2. 請求項１に記載の電子機器であって、
   前記フォローＡＰＩは、前記アプリケーションによるサービスとは異なる擬似サービスを前記ユーザに提供することを特徴とする電子機器。
3. 請求項１に記載の電子機器であって、
   前記フォローＡＰＩは、前記アプリケーションによるサービスを提供できない旨を前記ユーザに知らせることを特徴とする電子機器。
4. 請求項１から３のいずれか一項に記載の電子機器であって、
   前記フォローＡＰＩは、前記アプリケーションに同梱されており、該アプリケーションが前記電子機器にインストールされる時点にて、前記ＡＰＩのバージョン情報が前記コントローラＡＰＩのバージョン情報よりも新しい場合にのみ、該アプリケーションとともに前記電子機器にインストールされることを特徴とする電子機器。
5. 電子機器がコントローラを介してデバイスを制御し、アプリケーションによるサービスをユーザに提供する方法であって、
   前記電子機器は、その動作時に選択される複数のアプリケーションを管理する管理部と、該アプリケーションと該アプリケーションの作成時に使用したＡＰＩとの関連付け情報を記憶する記憶部とを備えており、
   前記電子機器が、コントローラＡＰＩのバージョン情報よりも新しいバージョン情報で構成されたＡＰＩを使用して作成したアプリケーションの起動をユーザから要求されるステップと、
   前記管理部が、前記記憶された関連付け情報を読み込むステップと、
   該管理部が、前記起動の要求されたアプリケーションに対し、前記関連付け情報に基づいて該アプリケーションの起動する旨を通知するとともに、前記コントローラＡＰＩに未実装のインタフェースを有するフォローＡＰＩを呼び出す旨を通知するステップと、
   該起動の要求されたアプリケーションが、該フォローＡＰＩを呼び出すステップと、
   該フォローＡＰＩが前記コントローラＡＰＩを呼び出すステップと、
   前記コントローラＡＰＩが、前記デバイスの操作を前記コントローラに要求するステップと、
   該コントローラが、前記デバイスを操作するステップと
   から構成されるサービス提供方法。
6. 電子機器がコントローラを介してデバイスを制御し、アプリケーションによるサービスをユーザに提供するプログラムであって、
   前記電子機器は、その動作時に選択される複数のアプリケーションを管理する管理部と、該アプリケーションと該アプリケーションの作成時に使用したＡＰＩとの関連付け情報を記憶する記憶部とを備え、
   前記プログラムは、前記電子機器のコンピュータに備えられており、
   前記電子機器が、コントローラＡＰＩのバージョン情報よりも新しいバージョン情報で構成されたＡＰＩを使用して作成したアプリケーションの起動をユーザから要求されるステップと、
   前記管理部が、前記記憶された関連付け情報を読み込む手順と、
   前記管理部が、前記起動の要求されたアプリケーションに対し、前記関連付け情報に基づいて該アプリケーションの起動する旨を通知するとともに、前記コントローラＡＰＩに未実装のインタフェースを有するフォローＡＰＩを呼び出す旨を通知する手順と、
   該起動の要求されたアプリケーションが、該フォローＡＰＩを呼び出す手順と、
   該フォローＡＰＩが前記コントローラＡＰＩを呼び出す手順と、
   前記コントローラＡＰＩが、前記デバイスの操作を前記コントローラに要求する手順と、
   該コントローラが、前記デバイスを操作する手順と
   を実行させるためのプログラム。

Images