JP2017182682A

JP2017182682A - 電子機器

Info

Publication number: JP2017182682A
Application number: JP2016072669A
Authority: JP
Inventors: 真也神田; Masaya Kanda
Original assignee: Kyocera Document Solutions Inc
Current assignee: Kyocera Document Solutions Inc
Priority date: 2016-03-31
Filing date: 2016-03-31
Publication date: 2017-10-05
Anticipated expiration: 2036-03-31
Also published as: JP6440099B2

Abstract

【課題】第１のプログラミング言語で構成されている第１プログラミング部分によって、第１のプログラミング言語とは異なる第２のプログラミング言語で構成されている第２プログラミング部分を高速に呼び出すことができる電子機器を提供する。【解決手段】Ｊａｖａ（登録商標）言語で構成されているＪａｖａ部分と、ネイティブ言語で構成されていてＪａｖａ部分によって呼び出されるネイティブ部分とを備えるアプリケーションをインストール可能な電子機器は、Ｊａｖａ部分によるネイティブ部分の呼び出しが許可されているか否かを、アプリケーションに関連付けられている認証情報に基づいて判断しＳ１３３、呼び出しが許可されていると判断したときＳ１３３でＹＥＳに呼び出しの権限をアプリケーションに付与しＳ１３４、アプリケーションの実行後も権限を維持する。【選択図】図４

Description

本発明は、第１のプログラミング言語で構成されている第１プログラミング部分によって、第１のプログラミング言語とは異なる第２のプログラミング言語で構成されている第２プログラミング部分を呼び出すことができる電子機器に関する。

従来、Ｊａｖａ（登録商標）言語で構成されているアプリケーション（以下「Ｊａｖａアプリケーション」という。）をインストール可能な電子機器が知られている（例えば、特許文献１参照。）。

Ｊａｖａアプリケーションは、Ｊａｖａの仮想環境で動作するので、使用可能なＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）や、使用可能なメモリーの容量などの制御が容易である。そのため、電子機器は、Ｊａｖａアプリケーションがインストールされても、Ｊａｖａアプリケーションによって電子機器の製造者の想定外の動作が実行される可能性が低く、セキュリティー上の問題が発生する可能性が低い。

しかしながら、Ｊａｖａの仮想環境の処理が高負荷であるので、Ｊａｖａ言語で構成されているプログラムの処理は、低速になる場合がある。そのため、Ｊａｖａには、Ｃ＋＋などのＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）上でそのまま動作するネイティブ言語で構成されているプログラム（以下「ネイティブプログラム」という。）を相互に呼び出すことができるＪＮＩ（ＪａｖａＮａｔｉｖｅＩｎｔｅｒｆａｃｅ）という仕組みが提供されていて、処理の高速化のためや、ネイティブ言語で構成されているライブラリーを呼び出すために利用されている。

しかしながら、ネイティブ言語は、ＯＳが提供している機能を自由に利用することができる。そのため、ネイティブプログラムは、例えば、電子機器における任意のファイルに対して読み出しおよび書き込みが可能である。したがって、電子機器は、電子機器の製造者の想定外の動作がネイティブプログラムによって実行される可能性が高くなり、セキュリティー上の問題が発生する可能性が高くなる。

特許文献１に記載された電子機器は、Ｊａｖａアプリケーションの処理が開始されてＪａｖａアプリケーションがネイティブプログラムを呼び出す場合にＪａｖａアプリケーションの認証を実行し、この認証が成功したときに、Ｊａｖａアプリケーションによるネイティブプログラムの呼び出しを許可する。特許文献１に記載された電子機器は、この認証をＪａｖａアプリケーションが保持しているデジタル署名によって行うので、電子機器の製造者の想定外の動作をネイティブプログラムによって実行しないＪａｖａアプリケーションのみに適切なデジタル署名を付与することによって、セキュリティー上の問題が発生する可能性を低下させることができる。

特開２０１５−０１１５１８号公報

しかしながら、従来の電子機器においては、Ｊａｖａアプリケーションによってネイティブプログラムが呼び出される度に認証が実行されるので、認証のための処理の負担によって、Ｊａｖａアプリケーションの処理が遅くなるという問題がある。

そこで、本発明は、第１のプログラミング言語で構成されている第１プログラミング部分によって、第１のプログラミング言語とは異なる第２のプログラミング言語で構成されている第２プログラミング部分を高速に呼び出すことができる電子機器を提供することを目的とする。

本発明の電子機器は、第１のプログラミング言語で構成されている第１プログラミング部分と、前記第１のプログラミング言語とは異なる第２のプログラミング言語で構成されていて前記第１プログラミング部分によって呼び出される第２プログラミング部分とを備えるアプリケーションをインストール可能な電子機器であって、前記第１プログラミング部分による前記第２プログラミング部分の呼び出しが許可されているか否かを、前記アプリケーションに関連付けられている認証情報に基づいて判断し、前記呼び出しが許可されていると判断した場合に前記呼び出しの権限を前記アプリケーションに付与し、前記アプリケーションの実行後も前記権限を維持することを特徴とする。

この構成により、本発明の電子機器は、第１プログラミング部分による第２プログラミング部分の呼び出しが許可されていると認証情報に基づいて判断した場合に呼び出しの権限をアプリケーションに付与し、アプリケーションの実行後も呼び出しの権限を維持するので、アプリケーションの実行の度に認証情報に基づいて判断する必要がなく、第１プログラミング部分によって第２プログラミング部分を高速に呼び出すことができる。

本発明の電子機器は、前記呼び出しが許可されているか否かを前記アプリケーションのインストール時に判断しても良い。

この構成により、本発明の電子機器は、第１プログラミング部分による第２プログラミング部分の呼び出しが許可されているか否かを、アプリケーションの実行時ではなく、アプリケーションのインストール時に判断するので、アプリケーションを高速に実行することができる。

本発明の電子機器は、前記権限を不揮発性の記憶デバイスに記憶しても良い。

この構成により、本発明の電子機器は、第１プログラミング部分による第２プログラミング部分の呼び出しが許可されているか否かを電子機器の起動の度に判断する必要がないので、処理負担を軽減することができる。

本発明の電子機器において、前記認証情報と、前記アプリケーションの少なくとも一部から特定の計算アルゴリズムに基づいて作成された情報とが一致する場合に、前記呼び出しが許可されていると判断しても良い。

この構成により、本発明の電子機器は、アプリケーション毎に認証情報が異なる可能性が高いので、特定のアプリケーションに正当に関連付けられている認証情報が他のアプリケーションに不正に流用されることを防止することができ、セキュリティー性能を向上することができる。

本発明の電子機器は、第１のプログラミング言語で構成されている第１プログラミング部分によって、第１のプログラミング言語とは異なる第２のプログラミング言語で構成されている第２プログラミング部分を高速に呼び出すことができる。

本発明の第１の実施の形態に係るＭＦＰのブロック図である。図１に示すＭＦＰのソフトウェア構成を示す図である。図１に示すアプリケーションの作成のシーケンス図である。アプリケーションがインストールされる場合の図１に示すＭＦＰの動作のフローチャートである。アプリケーションがインストールされる場合の図１に示すＭＦＰのソフトウェア構成を示す図である。Ｊａｖａが提供している機能と、ＯＳが提供している機能とのうちＪａｖａが提供している機能のみをアプリケーションが利用する場合の図１に示すＭＦＰのソフトウェア構成を示す図である。ＯＳが提供している機能をプラットフォーム側アプリケーション経由でアプリケーションが利用する場合の図１に示すＭＦＰのソフトウェア構成を示す図である。ＯＳが提供している機能をプラットフォーム側アプリケーションを経由せずにアプリケーションが利用する場合の図１に示すＭＦＰの動作のフローチャートである。ＯＳが提供している機能をプラットフォーム側アプリケーションを経由せずにアプリケーションが利用する場合の図１に示すＭＦＰのソフトウェア構成を示す図である。本発明の第２の実施の形態に係るＭＦＰのブロック図である。図１０に示すアプリケーションの作成のシーケンス図である。アプリケーションがインストールされる場合の図１０に示すＭＦＰの動作のフローチャートである。

以下、本発明の実施の形態について、図面を用いて説明する。

（第１の実施の形態）
まず、本発明の第１の実施の形態に係る電子機器としてのＭＦＰ（ＭｕｌｔｉｆｕｎｃｔｉｏｎＰｅｒｉｐｈｅｒａｌ）の構成について説明する。

図１は、本実施の形態に係るＭＦＰ１０のブロック図である。

図１に示すように、ＭＦＰ１０は、種々の操作が入力されるボタンなどの入力デバイスである操作部１１と、種々の情報を表示するＬＣＤ（ＬｉｑｕｉｄＣｒｙｓｔａｌＤｉｓｐｌａｙ）などの表示デバイスである表示部１２と、用紙などの記録媒体に印刷を実行する印刷デバイスであるプリンター１３と、原稿から画像を読み取る読取デバイスであるスキャナー１４と、図示していない外部のファクシミリ装置と公衆電話回線などの通信回線経由でファックス通信を行うファックスデバイスであるファックス通信部１５と、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）、インターネットなどのネットワーク経由で外部の装置と通信を行うネットワーク通信デバイスであるネットワーク通信部１６と、各種の情報を記憶する半導体メモリー、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）などの不揮発性の記憶デバイスである記憶部１７と、ＭＦＰ１０全体を制御する制御部１８とを備えている。

図２は、ＭＦＰ１０のソフトウェア構成を示す図である。

図１および図２に示すように、記憶部１７は、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）１７ａと、ＯＳ１７ａ上で動作するＪａｖａプラットフォーム１７ｂとを記憶している。Ｊａｖａプラットフォーム１７ｂは、ＯＳ１７ａ上で動作するＪａｖａＶＭ（ＶｉｒｔｕａｌＭａｃｈｉｎｅ）１７ｃと、ＪａｖａＶＭ１７ｃ上で動作するＯＳＧｉ（ＯｐｅｎＳｅｒｖｉｃｅＧａｔｅｗａｙｉｎｉｔｉａｔｉｖｅ）ＦｒａｍｅＷｏｒｋ１７ｄと、ＯＳＧｉＦｒａｍｅＷｏｒｋ１７ｄ上で動作するＪａｖａアプリケーションである少なくとも１つのプラットフォーム側アプリケーション１７ｅとを含んでいる。

記憶部１７は、ＯＳＧｉＦｒａｍｅＷｏｒｋ１７ｄ上で動作するＪａｖａアプリケーションである少なくとも１つのアプリケーション１７ｆを記憶可能である。アプリケーション１７ｆは、第１のプログラミング言語としてのＪａｖａ言語で構成されている第１プログラミング部分としてのＪａｖａ部分１７ｇと、Ｊａｖａ言語とは異なる第２のプログラミング言語としてのネイティブ言語で構成されていてＪａｖａ部分１７ｇによって呼び出される第２プログラミング部分としてのネイティブ部分１７ｈとを備える。なお、図２においては、ネイティブ部分１７ｈを、「ｌｉｂｒａｒｙ．ｓｏ」と示している。ネイティブ部分１７ｈは、認証されたことを示す認証情報１７ｉを含んでいる。アプリケーション１７ｆは、ＭＦＰ１０の製造段階でＭＦＰ１０にインストールされていても良いし、ＳＤカード、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）メモリーなどの外部の記憶媒体からＭＦＰ１０に追加でインストールされても良いし、ネットワーク上からＭＦＰ１０に追加でインストールされても良い。

記憶部１７は、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているか否かの判断に使用される判断用情報１７ｊを記憶している。

制御部１８は、例えば、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）と、プログラムおよび各種のデータを記憶しているＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）と、ＣＰＵの作業領域として用いられるＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）とを備えている。ＣＰＵは、記憶部１７またはＲＯＭに記憶されているプログラムを実行する。

なお、Ｊａｖａ言語は、ネイティブ言語と比較して、機能の制限をかけることが容易である。一方、ネイティブ言語は、Ｊａｖａ言語と比較して、高速に処理されることができる。

アプリケーション１７ｆは、プリント、コピー、ファックス、スキャンなど、ＭＦＰ１０の主たる機能を構成する図示していないプログラム（以下「主機能プログラム」という。）と、主機能プログラムの設定情報、秘密情報など、主機能プログラムが有する情報と、ＭＦＰ１０のハードウェアとの保護のために、これらの利用の少なくとも一部がＪａｖａプラットフォーム１７ｂによって制限される場合がある。

以下においては、ネイティブ言語がＣ＋＋であるものとして説明する。

次に、アプリケーション１７ｆの作成について説明する。

図３は、アプリケーション１７ｆの作成のシーケンス図である。

図３に示すように、アプリケーション１７ｆの開発者（以下「アプリ開発者」という。）２０は、ＭＦＰ１０にネイティブで実行させたい部分をＣ＋＋で実装し、ライブラリーとして「．ｓｏ形式」のファイル（以下「ｌｉｂｒａｒｙ．ｓｏ」とする。）を作成する（Ｓ１０１）。

次いで、アプリ開発者２０は、Ｓ１０１において作成したｌｉｂｒａｒｙ．ｓｏの認証をＭＦＰ１０の製造者（以下「ＭＦＰ製造者」という。）３０に依頼する（Ｓ１０２）。

ＭＦＰ製造者３０は、Ｓ１０２における依頼に応じて、ｌｉｂｒａｒｙ．ｓｏを検証する（Ｓ１０３）。

ＭＦＰ製造者３０は、Ｓ１０３における検証において問題ないと判断すると、ｌｉｂｒａｒｙ．ｓｏに認証情報１７ｉを埋め込み（Ｓ１０４）、認証情報１７ｉを埋め込んだｌｉｂｒａｒｙ．ｓｏをアプリ開発者２０に返す（Ｓ１０５）。

アプリ開発者２０は、Ｓ１０５において返されたｌｉｂｒａｒｙ．ｓｏ、すなわち、ネイティブ部分１７ｈと、このｌｉｂｒａｒｙ．ｓｏをロードする命令を含むＪａｖａ部分１７ｇとを含むアプリケーション１７ｆを作成する（Ｓ１０６）。

次に、ＭＦＰ１０の動作について説明する。

まず、アプリケーション１７ｆがインストールされる場合のＭＦＰ１０の動作について説明する。

なお、以下においては、プラットフォーム側アプリケーション１７ｅの動作として記載しているが、実際には、制御部１８がプラットフォーム側アプリケーション１７ｅを実行することによって実現される機能の動作である。

図４は、アプリケーション１７ｆがインストールされる場合のＭＦＰ１０の動作のフローチャートである。図５は、アプリケーション１７ｆがインストールされる場合のＭＦＰ１０のソフトウェア構成を示す図である。

図４および図５に示すように、プラットフォーム側アプリケーション１７ｅは、インストールされたアプリケーション１７ｆにネイティブ部分１７ｈとしてのｌｉｂｒａｒｙ．ｓｏが存在するか否かを判断する（Ｓ１３１）。

プラットフォーム側アプリケーション１７ｅは、ｌｉｂｒａｒｙ．ｓｏが存在するとＳ１３１において判断すると、このｌｉｂｒａｒｙ．ｓｏに認証情報１７ｉが埋め込まれているか否かを判断する（Ｓ１３２）。

プラットフォーム側アプリケーション１７ｅは、認証情報１７ｉが埋め込まれているとＳ１３２において判断すると、埋め込まれている認証情報１７ｉが正当なものであるか否か、すなわち、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているか否かを判断する（Ｓ１３３）。ここで、プラットフォーム側アプリケーション１７ｅは、インストールされたアプリケーション１７ｆのｌｉｂｒａｒｙ．ｓｏに埋め込まれている認証情報１７ｉと、判断用情報１７ｊとが一致する場合に、認証情報１７ｉが正当なものであると判断する。

プラットフォーム側アプリケーション１７ｅは、埋め込まれている認証情報１７ｉが正当なものである、すなわち、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているとＳ１３３において判断すると、インストールされたアプリケーション１７ｆに対して、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しの権限、すなわち、ネイティブ部分１７ｈとしてのｌｉｂｒａｒｙ．ｓｏをＪａｖａの実行環境にロードする権限を付与する（Ｓ１３４）。

プラットフォーム側アプリケーション１７ｅは、ｌｉｂｒａｒｙ．ｓｏが存在しないとＳ１３１において判断するか、認証情報１７ｉが埋め込まれていないとＳ１３２において判断するか、埋め込まれている認証情報１７ｉが正当なものではないとＳ１３３において判断するか、Ｓ１３４の処理を実行すると、図４に示す動作を終了する。

次に、アプリケーション１７ｆが実行される場合のＭＦＰ１０の動作について説明する。

まず、Ｊａｖａが提供している機能と、ＯＳ１７ａが提供している機能とのうちＪａｖａが提供している機能のみをアプリケーション１７ｆが利用する場合のＭＦＰ１０の動作について説明する。

なお、Ｊａｖａは、記憶部１７にアクセスする機能、プリンター１３によって印刷するときに図示していないステープラーによってステープルを実行する機能など、ＯＳ１７ａが提供している少なくとも一部の機能を提供していない。

図６は、Ｊａｖａが提供している機能と、ＯＳ１７ａが提供している機能とのうちＪａｖａが提供している機能のみをアプリケーション１７ｆが利用する場合のＭＦＰ１０のソフトウェア構成を示す図である。

図６に示すように、アプリケーション１７ｆは、Ｊａｖａが提供している機能と、ＯＳ１７ａが提供している機能とのうちＪａｖａが提供している機能のみを利用する。

次に、ＯＳ１７ａが提供している機能をプラットフォーム側アプリケーション１７ｅ経由でアプリケーション１７ｆが利用する場合のＭＦＰ１０の動作について説明する。

図７は、ＯＳ１７ａが提供している機能をプラットフォーム側アプリケーション１７ｅ経由でアプリケーション１７ｆが利用する場合のＭＦＰ１０のソフトウェア構成を示す図である。

図７に示すように、アプリケーション１７ｆは、ＯＳ１７ａが提供している機能をプラットフォーム側アプリケーション１７ｅ経由で利用する。プラットフォーム側アプリケーション１７ｅは、ＯＳ１７ａとの通信にＪＮＩを利用する。アプリケーション１７ｆは、Ｊａｖａが提供している機能もプラットフォーム側アプリケーション１７ｅ経由で利用可能である。

次に、ＯＳ１７ａが提供している機能をプラットフォーム側アプリケーション１７ｅを経由せずにアプリケーション１７ｆが利用する場合のＭＦＰ１０の動作について説明する。

図８は、ＯＳ１７ａが提供している機能をプラットフォーム側アプリケーション１７ｅを経由せずにアプリケーション１７ｆが利用する場合のＭＦＰ１０の動作のフローチャートである。図９は、ＯＳ１７ａが提供している機能をプラットフォーム側アプリケーション１７ｅを経由せずにアプリケーション１７ｆが利用する場合のＭＦＰ１０のソフトウェア構成を示す図である。

図８に示すように、Ｊａｖａプラットフォーム１７ｂは、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しの権限、すなわち、ネイティブ部分１７ｈとしてのｌｉｂｒａｒｙ．ｓｏをＪａｖａの実行環境にロードする権限がアプリケーション１７ｆに付与されているか否かを判断する（Ｓ１６１）。

Ｊａｖａプラットフォーム１７ｂは、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しの権限がアプリケーション１７ｆに付与されているとＳ１６１において判断すると、アプリケーション１７ｆにＪＮＩの利用を許可して（Ｓ１６２）、図８に示す動作を終了する。したがって、アプリケーション１７ｆは、Ｊａｖａ部分１７ｇによってネイティブ部分１７ｈを呼び出す、すなわち、ネイティブ部分１７ｈとしてのｌｉｂｒａｒｙ．ｓｏをＪａｖａの実行環境にロードすることができる。その結果、アプリケーション１７ｆは、ＯＳ１７ａが提供している機能を図９に示すようにプラットフォーム側アプリケーション１７ｅを経由せずに利用可能である。

Ｊａｖａプラットフォーム１７ｂは、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しの権限がアプリケーション１７ｆに付与されていないとＳ１６１において判断すると、アプリケーション１７ｆにＪＮＩの利用を許可せずに、図８に示す動作を終了する。

以上に説明したように、ＭＦＰ１０は、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されていると認証情報１７ｉに基づいて判断した場合（Ｓ１３３でＹＥＳ）に呼び出しの権限をアプリケーション１７ｆに付与し（Ｓ１３４）、アプリケーション１７ｆの実行後も呼び出しの権限を維持するので、アプリケーション１７ｆの実行の度に認証情報１７ｉに基づいて判断する必要がなく、Ｊａｖａ部分１７ｇによってネイティブ部分１７ｈを高速に呼び出すことができる。

ＭＦＰ１０は、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているか否かを、アプリケーション１７ｆの実行時ではなく、アプリケーション１７ｆのインストール時に判断するので、アプリケーション１７ｆを高速に実行することができる。しかしながら、ＭＦＰ１０は、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているか否かを、アプリケーション１７ｆのインストール時ではなく、アプリケーション１７ｆの最初の実行時に判断する構成でも良い。

ＭＦＰ１０は、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しの権限を不揮発性の記憶部１７に記憶することによって、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているか否かをＭＦＰ１０の起動の度に判断する必要がないので、処理負担を軽減することができる。しかしながら、ＭＦＰ１０は、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しの権限を制御部１８のＲＡＭに記憶して、Ｊａｖａ部分１７ｇによるネイティブ部分１７ｈの呼び出しが許可されているか否かをＭＦＰ１０の起動の度に判断する構成でも良い。

なお、認証情報１７ｉは、本実施の形態においてネイティブ部分１７ｈに埋め込まれている。しかしながら、認証情報１７ｉは、アプリケーション１７ｆのうち、ネイティブ部分１７ｈ以外の部分に含まれていても良い。また、認証情報１７ｉは、アプリケーション１７ｆに関連付けられて、アプリケーション１７ｆとは別ファイルとして存在しても良い。

ＭＦＰ製造者３０は、本実施の形態においてｌｉｂｒａｒｙ．ｓｏを検証する。しかしながら、ＭＦＰ製造者３０は、ｌｉｂｒａｒｙ．ｓｏを含むアプリケーション全体を検証しても良い。

（第２の実施の形態）
まず、本発明の第２の実施の形態に係る電子機器としてのＭＦＰの構成について説明する。

図１０は、本実施の形態に係るＭＦＰ２１０のブロック図である。

図１０に示すＭＦＰ２１０の構成は、以下に述べる構成を除いて、第１の実施の形態に係るＭＦＰ１０（図１参照。）の構成と同様である。

ＭＦＰ２１０は、アプリケーション１７ｆ（図１参照。）ではなく、アプリケーション２１７ａを備えている。アプリケーション２１７ａは、Ｊａｖａ部分１７ｇと、ネイティブ言語で構成されていてＪａｖａ部分１７ｇによって呼び出される第２プログラミング部分としてのネイティブ部分２１７ｂとを備えている。ネイティブ部分２１７ｂは、認証情報１７ｉ（図１参照。）を含んでいない。

ＭＦＰ２１０は、アプリケーション２１７ａ毎に関連付けられている認証情報２１７ｃを備えている。

ＭＦＰ２１０は、判断用情報１７ｊ（図１参照。）を備えておらず、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているか否かの判断に使用される判断用計算アルゴリズム２１７ｄを備えている。

次に、アプリケーション２１７ａの作成について説明する。

図１１は、アプリケーション２１７ａの作成のシーケンス図である。

図１１に示すように、アプリ開発者２０は、ＭＦＰ２１０にネイティブで実行させたい部分をＣ＋＋で実装し、ライブラリーとしてｌｉｂｒａｒｙ．ｓｏを作成する（Ｓ３０１）。

次いで、アプリ開発者２０は、Ｓ３０１において作成したｌｉｂｒａｒｙ．ｓｏ、すなわち、ネイティブ部分２１７ｂと、このｌｉｂｒａｒｙ．ｓｏをロードする命令を含むＪａｖａ部分１７ｇとを含むアプリケーション２１７ａを作成する（Ｓ３０２）。

次いで、アプリ開発者２０は、Ｓ３０２において作成したアプリケーション２１７ａの認証をＭＦＰ製造者３０に依頼する（Ｓ３０３）。

ＭＦＰ製造者３０は、Ｓ３０３における依頼に応じて、認証を依頼されたアプリケーション２１７ａ、特に、このアプリケーション２１７ａに含まれるｌｉｂｒａｒｙ．ｓｏを検証する（Ｓ３０４）。

ＭＦＰ製造者３０は、Ｓ３０４における検証において問題ないと判断すると、ｌｉｂｒａｒｙ．ｓｏから特定の計算アルゴリズムに基づいて認証情報２１７ｃを作成し（Ｓ３０５）、認証情報２１７ｃをアプリ開発者２０に送信する（Ｓ３０６）。ここで、この計算アルゴリズムは、判断用計算アルゴリズム２１７ｄと同一内容のものである。

次に、ＭＦＰ２１０の動作について説明する。

ＭＦＰ２１０は、アプリ開発者によって作成されたアプリケーション２１７ａがインストールされるとともに、このアプリケーション２１７ａに関連付けられてＭＦＰ製造者によって作成された認証情報２１７ｃが記憶部１７に記憶させられる。

まず、アプリケーション２１７ａがインストールされる場合のＭＦＰ２１０の動作について説明する。

図１２は、アプリケーション２１７ａがインストールされる場合のＭＦＰ２１０の動作のフローチャートである。

図１２に示すように、プラットフォーム側アプリケーション１７ｅは、インストールされたアプリケーション２１７ａにネイティブ部分２１７ｂとしてのｌｉｂｒａｒｙ．ｓｏが存在するか否かを判断する（Ｓ３３１）。

プラットフォーム側アプリケーション１７ｅは、ｌｉｂｒａｒｙ．ｓｏが存在するとＳ３３１において判断すると、アプリケーション２１７ａに関連付けられている認証情報２１７ｃが存在するか否かを判断する（Ｓ３３２）。

プラットフォーム側アプリケーション１７ｅは、認証情報２１７ｃが存在するとＳ３３２において判断すると、この認証情報２１７ｃが正当なものであるか否か、すなわち、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているか否かを判断する（Ｓ３３３）。ここで、プラットフォーム側アプリケーション１７ｅは、インストールされたアプリケーション２１７ａのｌｉｂｒａｒｙ．ｓｏから判断用計算アルゴリズム２１７ｄに基づいて作成した情報と、このアプリケーション２１７ａに関連付けられている認証情報２１７ｃとが一致する場合に、認証情報２１７ｃが正当なものであると判断する。

プラットフォーム側アプリケーション１７ｅは、認証情報２１７ｃが正当なものである、すなわち、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているとＳ３３３において判断すると、インストールされたアプリケーション２１７ａに対して、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しの権限、すなわち、ネイティブ部分２１７ｂとしてのｌｉｂｒａｒｙ．ｓｏをＪａｖａの実行環境にロードする権限を付与する（Ｓ３３４）。

プラットフォーム側アプリケーション１７ｅは、ｌｉｂｒａｒｙ．ｓｏが存在しないとＳ３３１において判断するか、認証情報２１７ｃが存在しないとＳ３３２において判断するか、認証情報２１７ｃが正当なものではないとＳ３３３において判断するか、Ｓ３３４の処理を実行すると、図１２に示す動作を終了する。

なお、アプリケーション２１７ａが実行される場合のＭＦＰ２１０の動作については、第１の実施の形態と同様である。

以上に説明したように、ＭＦＰ２１０は、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されていると認証情報２１７ｃに基づいて判断した場合（Ｓ３３３でＹＥＳ）に呼び出しの権限をアプリケーション２１７ａに付与し（Ｓ３３４）、アプリケーション２１７ａの実行後も呼び出しの権限を維持するので、Ｊａｖａ部分１７ｇによってネイティブ部分２１７ｂを呼び出す度に認証情報２１７ｃに基づいて判断する必要がなく、Ｊａｖａ部分１７ｇによってネイティブ部分２１７ｂを高速に呼び出すことができる。

ＭＦＰ２１０は、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているか否かを、アプリケーション２１７ａの実行時ではなく、アプリケーション２１７ａのインストール時に判断するので、アプリケーション２１７ａを高速に実行することができる。しかしながら、ＭＦＰ２１０は、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているか否かを、アプリケーション２１７ａのインストール時ではなく、アプリケーション２１７ａの最初の実行時に判断する構成でも良い。

ＭＦＰ２１０は、認証情報２１７ｃと、アプリケーション２１７ａのネイティブ部分２１７ｂから判断用計算アルゴリズム２１７ｄに基づいて作成された情報とが一致する場合に、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されていると判断する。したがって、ＭＦＰ２１０は、アプリケーション２１７ａ毎に認証情報２１７ｃが異なる可能性が高いので、特定のアプリケーション２１７ａに正当に関連付けられている認証情報２１７ｃが他のアプリケーション２１７ａに不正に流用されることを防止することができ、セキュリティー性能を向上することができる。

ＭＦＰ２１０は、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しの権限を不揮発性の記憶部１７に記憶することによって、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているか否かをＭＦＰ２１０の起動の度に判断する必要がないので、処理負担を軽減することができる。しかしながら、ＭＦＰ２１０は、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しの権限を制御部１８のＲＡＭに記憶して、Ｊａｖａ部分１７ｇによるネイティブ部分２１７ｂの呼び出しが許可されているか否かをＭＦＰ２１０の起動の度に判断する構成でも良い。

なお、認証情報２１７ｃは、本実施の形態においてアプリケーション２１７ａに関連付けられて、アプリケーション２１７ａとは別ファイルとして存在している。しかしながら、認証情報２１７ｃは、アプリケーション２１７ａのうち、ネイティブ部分２１７ｂ以外の部分に含まれていても良い。

ＭＦＰ製造者３０は、本実施の形態においてｌｉｂｒａｒｙ．ｓｏを含むアプリケーション２１７ａ全体を検証する。しかしながら、ＭＦＰ製造者３０は、ｌｉｂｒａｒｙ．ｓｏのみを検証しても良い。ＭＦＰ製造者３０がｌｉｂｒａｒｙ．ｓｏのみを検証する場合、アプリ開発者２０からＭＦＰ製造者３０へはアプリケーション２１７ａのうちｌｉｂｒａｒｙ．ｓｏのみが送信されれば良い。

本発明の電子機器は、上述の各実施の形態においてＭＦＰであるが、プリンター専用機、コピー専用機、ファックス専用機、スキャナー専用機など、ＭＦＰ以外の画像形成装置でも良いし、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）など、画像形成装置以外の電子機器でも良い。

１０ＭＦＰ（電子機器）
１７記憶部（不揮発性の記憶デバイス）
１７ｆアプリケーション
１７ｇＪａｖａ部分（第１プログラミング部分）
１７ｈネイティブ部分（第２プログラミング部分）
１７ｉ認証情報
２１０ＭＦＰ（電子機器）
２１７ａアプリケーション
２１７ｂネイティブ部分（第２プログラミング部分）
２１７ｃ認証情報
２１７ｄ判断用計算アルゴリズム（特定の計算アルゴリズム）

Claims

第１のプログラミング言語で構成されている第１プログラミング部分と、
前記第１のプログラミング言語とは異なる第２のプログラミング言語で構成されていて前記第１プログラミング部分によって呼び出される第２プログラミング部分と
を備えるアプリケーションをインストール可能な電子機器であって、
前記第１プログラミング部分による前記第２プログラミング部分の呼び出しが許可されているか否かを、前記アプリケーションに関連付けられている認証情報に基づいて判断し、前記呼び出しが許可されていると判断した場合に前記呼び出しの権限を前記アプリケーションに付与し、前記アプリケーションの実行後も前記権限を維持することを特徴とする電子機器。
前記呼び出しが許可されているか否かを前記アプリケーションのインストール時に判断することを特徴とする請求項１に記載の電子機器。
前記権限を不揮発性の記憶デバイスに記憶することを特徴とする請求項１または請求項２に記載の電子機器。
前記認証情報と、前記アプリケーションの少なくとも一部から特定の計算アルゴリズムに基づいて作成された情報とが一致する場合に、前記呼び出しが許可されていると判断することを特徴とする請求項１から請求項３までの何れかに記載の電子機器。