(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0013】
以下、図面を参照しながら、本発明の実施形態を説明する。
【0014】
[概要]
最初に、本発明の概要について説明する。
【0015】
現在、画像形成装置では、エンドユーザーの課題を解決する手段の一つとして、画像形成装置にインストールしアクティベートして使われるサードパーティー製のアプリケーションプログラム(以下、プログラムと呼ぶ)がある。
【0016】
プログラムは、画像形成装置の持つ多くの機能を利用するものが数多く存在し、販社など様々なところで開発され、エンドユーザーに提供されている。
【0017】
プログラムが画像形成装置の様々な機能を利用するためには、画像形成装置から提供される数多くのAPI群を利用することになる。
【0018】
API群には標準で提供されるものに加えて、スキャン・エクステンション・キットなどのオプションで購入されるキットに含まれるものもある。
【0019】
以下の説明では、スキャン・エクステンション・キットとそこで提供されるAPI群を例に挙げて説明する。
【0020】
なお、スキャン・エクステンション・キットとは、原稿をスキャンして得られるスキャンデータをOCR処理してサーチャブルPDF(Portable Document Format)を生成したり、スキャンデータをマイクロソフトオフィス形式へ変換したり、バーコード認識したり、マーカー認識したり、ゾーンOCR機能を提供したり、名刺読み取り機能を提供したりするなど、スキャン機能を拡張するために画像形成装置に内蔵された拡張キットを指す。
【0021】
典型的な技術では、例えば、スキャン・エクステンション・キットに含まれるAPI群は、スキャン・エクステンション・キットをアクティベートしなければどれも使用することが出来なかった。スキャン・エクステンション・キットをアクティベートすれば、含まれるAPI群を全て使用可能なことに加えて、上に挙げた機能を利用するためのメニューが操作パネルに表示されるので、ユーザーはプログラムからのAPI利用に限らずスキャン・エクステンション・キットの機能を使用することが出来た。
【0022】
しかし、典型的な技術では、スキャン・エクステンション・キット内の1つの機能をAPI経由で使いたい場合でも、スキャン・エクステンション・キットをアクティベートしなければならずコスト的に問題であった。
【0023】
本発明では、例えば、スキャン・エクステンション・キットにより提供される1つ1つのAPIについて、使用の可否を制御でき、課金を制御できるので、エンドユーザーに対し適切なコストパフォーマンスで機能を提供することが出来る。
【0024】
なお、本発明は、画像形成装置において許可されたAPIのみを使用可能にする仕組みと管理サーバーにおいて使用を許可されたAPIを用いたプログラムを導入したエンドユーザーに対して課金する仕組みとから構成されている。
【0025】
そこで、最初に、画像形成装置で許可されたAPIのみを使用可能にする仕組みを説明した後、管理サーバーにてエンドユーザーに課金する仕組みについて説明する。
【0027】
[画像形成装置の構成]
次に、本発明の一実施形態に係る画像形成装置20の構成について説明する。
図1は画像形成装置20の構成を概略的に示す構成図である。
【0028】
画像形成装置20は、制御部21を備える。制御部21は、CPU(Central Processing Unit)、RAM(Random Access Memory)、ROM(Read Only Memory)、および専用のハードウェア回路等から構成され、画像形成装置20の全体的な動作制御を司る。
【0029】
制御部21は、原稿読取部22、画像処理部23、画像メモリー24、画像形成部25、操作部26、表示部26a、ファクシミリ通信部27、通信部28、記憶部29等と接続されている。制御部21は、接続されている上記各部の動作制御や、各部との間での信号又はデータの送受信を行う。
【0030】
制御部21は、ユーザーから、操作部26またはネッワーク接続されたPC(Personal Computer)等を通じて入力されるジョブの実行指示に従って、スキャナ機能、印刷機能、コピー機能、およびファクシミリ送受信機能などの各機能についての動作制御を実行するために必要な機構の駆動及び処理を制御する。
【0031】
また、制御部21は、プログラム実行プラットフォーム21aを有している。プログラム実行プラットフォーム21aは、ROMなどからRAMにロードされたプログラムがCPUにより実行されることで実現される機能ブロックである。
【0032】
プログラム実行プラットフォーム21aは、画像形成装置20上でプログラムを実行するためのプラットフォームであり、テーブルチェック部21bおよびAPI群21cを含んでいる。
【0033】
テーブルチェック部21bは、API実行可否テーブル29b(後述)をチェックし、画像形成装置20上で実行されるプログラムから呼び出されたAPIを実行するか否かを制御する。
【0034】
API群21cは、例えば、上述したスキャン・エクステンション・キットなどにより提供される一連のAPIである。
【0035】
原稿読取部22は、原稿から画像を読み取る。
【0036】
画像処理部23は、原稿読取部22で読み取られた画像の画像データを必要に応じて画像処理する。例えば、画像処理部23は、原稿読取部22により読み取られた画像が画像形成された後の品質を向上させるために、シェーディング補正等の画像処理を行う。
【0037】
画像メモリー24は、原稿読取部22による読み取りで得られた原稿画像のデータを一時的に記憶したり、画像形成部25での印刷対象となるデータを一時的に記憶したりする領域である。
【0038】
画像形成部25は、原稿読取部22で読み取られた画像データ等の画像形成を行う。
【0039】
操作部26は、画像形成装置20が実行可能な各種動作及び処理についてユーザーからの指示を受け付けるタッチパネル部および操作キー部を備える。タッチパネル部は、タッチパネルが設けられたLCD(Liquid Crystal Display)等の表示部26aを備えている。
【0040】
ファクシミリ通信部27は、図示しない符号化/復号化部、変復調部、およびNCU(Network Control Unit)を備え、公衆電話回線網を用いてのファクシミリの送信を行う。
【0041】
通信部28は、LANボード等の通信モジュールから構成され、通信部28に接続されたLAN等を介して、ネットワーク上の装置(PC等)と種々のデータの送受信を行う。
【0042】
記憶部29は、原稿読取部22によって読み取られた原稿画像およびパッケージファイル29aなどを記憶する。記憶部29は、HDDなどの大容量の記憶装置である。
【0043】
パッケージファイル29aは、プログラムを画像形成装置20にインストールし、プログラム実行プラットフォーム21a上で実行させるためのファイルであり、API実行可否テーブル29bおよびjarファイル29c(格納ファイル)を含んでいる。
【0044】
API実行可否テーブル29bは、このテーブルを持つプログラムが、API群21cのうちどのAPIの使用が許可されているかを示すテーブルである。
【0045】
jarファイル29cは、プログラム実行プラットフォーム21a上で実行させるプログラムをjar(Java(登録商標) Archive)形式で格納したファイルである。なお、ここでは画像形成装置20上で実行させるプログラムとしてjava(登録商標)プログラムを想定しているのでパッケージファイル29aではプログラムを格納するファイルとしてjar形式のファイルを想定しているが、この構成に限られるものではない。
【0046】
以上、画像形成装置20の構成について説明した。
【0047】
[典型的なAPI呼び出し]
次に、本発明によるAPI使用制御と対比させるために、典型的な技術により、jarファイル内のプログラムからAPIを呼び出す場合の仕組みについて説明する。
図2は、典型的な技術により、jarファイル内のプログラムからAPIを呼び出す場合の仕組みについて説明するための図である。
【0048】
まず、プログラムの開発元であるサードパーティーが、申請ファイルを作成する。申請ファイルは、プログラムのパッケージ化の許可をメーカーから得るための申請を行う際に作成されるファイルである。
【0049】
申請ファイルには、プログラムID(Identification)、プログラム名などのプログラム情報が記載される。
【0050】
次に、パッケージ化の許可を貰った開発元が作るのがパッケージファイルである。パッケージファイルには、申請ファイルに記載されていたプログラム情報に加えて、jar形式でプログラムが格納されたjarファイルが追加される。
【0051】
パッケージファイルは、開発元または画像形成装置のメーカーなどによりエンドユーザーに提供され、画像形成装置にインストールされ利用される。
【0052】
インストールされたプログラムの実行時には、jarファイル内のプログラムからプログラム実行プラットフォーム上のAPI群が呼び出される形となる。
【0053】
以上、典型的な技術により、jarファイル内のプログラムからAPIを呼び出す場合の仕組みについて説明した。
【0054】
[本発明によるAPI呼び出し]
次に、本発明の一実施形態に係る画像形成装置20でのAPI呼び出しの仕組みを説明する。
図3は、本発明の一実施形態に係る画像形成装置20でのAPI呼び出しの仕組みを説明するための図である。
【0055】
まず、
図2に示した典型的な技術と異なる点は、申請ファイルに、API実行可否テーブル29bが追加されている点である。このテーブルにより、開発元は、パッケージ化を申請するプログラムがどのAPIを呼び出すかを申請することになる。
【0056】
API実行可否テーブル29bは、パッケージファイル29aに引き継がれ、プログラム情報およびjarファイル29cと共に、パッケージファイル29aを構成する。
【0057】
プログラムの実行時には、jarファイル内のプログラムからAPI群21c内のAPIが呼び出されると、逐一テーブルチェック部21bがパッケージファイル内のAPI実行可否テーブル29bをチェックし、APIの呼び出しの可否を決定する。
【0058】
例えば、
図3に示す例では、ScanToWordというAPIは、API実行可否テーブル29bで「on」になっているので、テーブルチェック部21bはAPI呼び出しを許可し、呼び出されたAPIはそのまま実行され、スキャンデータはWORD形式に変換される。また、ScanToExcelというAPIは、API実行可否テーブル29bで「off」になっているので、テーブルチェック部21bはAPI呼び出しを許可せず、このAPIを呼び出しても実行はされずエラーとなる。
【0059】
以上、本発明の一実施形態に係る画像形成装置20でのAPI呼び出しの仕組みを説明した。
【0060】
[処理の流れ]
次に、画像形成装置20におけるAPI呼び出し制御の処理の流れについて説明する。
図4は、画像形成装置20におけるAPI呼び出し制御の処理の流れについて説明するためのフローチャートである。
【0061】
まず、ユーザーの指示に基づき、プログラム実行プラットフォーム21aがパッケージファイル29aのjarファイル29c内のプログラムを実行する(ステップS1)。
【0062】
次に、実行されたプログラムがAPIの呼び出しを行う(ステップS2)。
【0063】
次に、テーブルチェック部21bが、パッケージファイル29a内のAPI実行可否テーブル29bをチェックする(ステップS3)。
【0064】
次に、テーブルチェック部21bが、API実行可否テーブル29bに基づき、呼び出されたAPIの実行が許可されているか否かをチェックする(ステップS4)。
【0065】
APIの実行が許可されている場合(ステップS4のY)、呼び出されたAPIが実行され処理が終了する(ステップS5)。
【0066】
APIの実行が許可されていない場合(ステップS4のN)、APIの呼び出しはエラーとなり処理は終了する(ステップS6)。
【0067】
以上、画像形成装置20におけるAPI呼び出し制御の処理の流れについて説明した。
【0068】
[管理サーバーの構成]
次に、課金を行う管理サーバー10の構成について説明する。管理サーバー10は、専用のハードウェアやソフトウェアにより構成されていてもよいし、一般的なコンピューターにより構成されてもよい。管理サーバー10が一般的なコンピューターにより構成される場合の構成図を
図5に示す。
【0069】
同図に示すように、管理サーバー10は、CPU11、ROM12、RAM13、操作入力部14、通信部15、表示部16、および記憶部17を有し、これら各ブロックがバス18を介して接続されている。
【0070】
ROM12は、各種の処理を実行するためのファームウェア等の複数のプログラムやデータを記憶する。RAM13は、CPU11の作業用領域として用いられ、OS(Operating System)、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。
【0071】
記憶部17は、例えばHDD(Hard Disk Drive)や、フラッシュメモリー、その他の不揮発性メモリーである。記憶部17には、OSや各種アプリケーション、各種データ、プログラムDB(Database)17aおよびアイテムコードDB17bが記憶される。
【0072】
プログラムDB17aは、開発元により開発されたプログラムを登録し管理するデータベースである。プログラムIDをキーとして登録されてもよい。
【0073】
アイテムコードDB17bは、開発されたプログラムに一意に対応したアイテムコードを登録し管理するデータベースである。アイテムコードは、プログラムを開発した開発元や開発されたプログラムを導入し使用するエンドユーザーに対し、API使用権の使用料を課金するために用いられる。
【0074】
通信部15は、ネットワーク上のPC等と情報のやりとりを行う為のネットワークと結ばれている。
【0075】
CPU11は、ROM12や記憶部17に格納された複数のプログラムのうち、操作入力部14から与えられる命令に対応するプログラムをRAM13に展開し、この展開されたプログラムにしたがって、表示部16及び記憶部17を適宜制御する。
【0076】
操作入力部14は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の操作装置である。
【0077】
表示部16は、例えば液晶ディスプレイ、EL(Electro-Luminescence)ディスプレイ、プラズマディスプレイ等である。
【0078】
次に、CPU11においてプログラムが実行されることにより実現される機能ブロックについて説明する。
【0079】
管理サーバー10のCPU11において実現される機能ブロックは、プログラム登録部11a、アイテムコード発行部11b、API情報紐付け部11c、および課金部11dである。
【0080】
プログラム登録部11aは、開発元により開発され、パッケージ化の申請がなされたプログラムを、当該プログラムのプログラムIDをキーとしてプログラムDB17aに登録する。
【0081】
アイテムコード発行部11bは、プログラムDB17aに登録されたプログラムについて、課金に用いるためのアイテムコードを発行する。なお、発行されたアイテムコードは、アイテムコードDB17bに登録される。
【0082】
API情報紐付け部11cは、発行されたアイテムコードに、有料API情報を紐付け、紐付けられた有料API情報をアイテムコードDB17b内の登録されたアイテムコードに紐付けて登録する。なお、有料API情報とは、API群21cで提供される個々のAPIをプログラムが利用する権利を得るためのAPIごとの価格である。
【0083】
なお、紐付けは申請ファイルに含まれるAPI実行可否テーブル29bの記載に基づいて行われてもよい。例えば、API実行可否テーブル29bに「ScanToWord=on」(それ以外のAPIについてはoffであるとする)の記載があるプログラムでは、「ScanToWord 100円」という有料API情報がアイテムコードに紐付けられ、「ScanToExcel 150円」という有料API情報はアイテムコードに紐付けられないことになる。この場合、課金部11dはアイテムコードに紐付けられた個々の有料API情報を積算することにより実際の課金額を計算する。
【0084】
課金部11dは、特定のAPIを呼び出すプログラムを開発した開発元および/またはそのプログラムを利用するエンドユーザーにアイテムコードに基づいて課金する。
【0085】
なお、実際の課金は、パッケージ化の申請ファイルに含まれるAPI実行可否テーブル29bの内容に基づいて行われてもよい。その場合、API実行可否テーブル29bの内容がアイテムコードDB17bに登録されてもよい。課金部11dは、アイテムコードDB17bにアイテムコードをキーとして登録されているAPI実行可否テーブル29bの内容に基づいて実際の課金額を算出してもよい。
【0086】
例えば、「ScanToWord」のAPI利用権が100円と有料API情報で定められている場合、API実行可否テーブル29bに「ScanToWord=on」(それ以外のAPIについてはoffであるとする)の記載があるプログラムでは、100円が課金される。
【0087】
以上、管理サーバー10の構成について説明した。
【0088】
[典型的なプログラムのパッケージ化の流れ]
次に、本発明におけるプログラムのパッケージ化および課金の流れと対比させるために、典型的なプログラムのパッケージ化の流れについて説明する。
図6は、典型的なプログラムのパッケージ化の流れについて説明する図である。
【0089】
まず、開発元(図では開発元の販社として示す)が画像形成装置20上で動作するプログラムを開発する。
【0090】
次に、開発元は、画像形成装置20のメーカーから提供された動作チェックツールを用いて動作テストを行い、動作チェック結果を得る。開発元は、開発したプログラムを配布するためのパッケージ化を行うための申請をリージョナルヘッドクォーター(以下、RHQと呼ぶ)に対して行う。申請は、動作チェック結果と申請ファイルを添付して行う。
【0091】
次に、開発元からパッケージ化の申請を受領したRHQは、申請内容を確認した後、画像形成装置20のメーカーに対しパッケージ化の申請を行う。
【0092】
次に、申請を受けた画像形成装置20のメーカーは、申請内容を確認した後、プログラムを管理サーバーに登録する。
【0093】
次に、管理サーバーが登録されたプログラムに対応したアイテムコードを発行する。
【0094】
次に、画像形成装置20のメーカーは、RHQに発行されたアイテムコードを連絡し、パッケージ化を許可する。
【0095】
次に、RHQは、開発元にパッケージ化が許可されたことを伝える。
【0096】
最後に、パッケージ化が許可された開発元は、最終的なパッケージファイルの作成を行う。
【0097】
以上、典型的なプログラムのパッケージ化の流れについて説明した。
【0098】
[本発明によるパッケージ化と課金の流れ]
次に、本発明におけるプログラムのパッケージ化および課金の流れについて説明する。
図7は、本発明におけるプログラムのパッケージ化および課金の流れについて説明するための図である。
【0099】
まず、開発元が画像形成装置20上で動作するプログラムを開発する。
【0100】
次に、開発元は、画像形成装置20のメーカーから提供された動作チェックツールを用いて動作テストを行い、動作チェック結果を得る。開発元は、開発したプログラムを配布するためのパッケージ化を行うための申請をRHQに対して行う。申請は、動作チェック結果と申請ファイルを添付して行う。なお、申請ファイルには、上述したように、API実行可否テーブル29bが記載されている。
【0101】
次に、開発元からパッケージ化の申請を受領したRHQは、申請内容を確認した後、画像形成装置20のメーカーに対しパッケージ化の申請を行う。
【0102】
次に、申請を受けた画像形成装置20のメーカーは、申請内容を確認した後、申請内容に含まれるプログラムIDをキーとして、当該プログラムを管理サーバーに登録する。
【0103】
次に、管理サーバーが、登録されたプログラムに対応したアイテムコードを発行する。
【0104】
次に、管理サーバーは、発行されたアイテムコードと有料API情報との紐付けを行う。
【0105】
次に、管理サーバーは、プログラムの開発元および/または当該パッケージファイルを導入するエンドユーザーに対し、アイテムコードに基づき課金する。
【0106】
次に、画像形成装置20のメーカーは、RHQに発行されたアイテムコードを連絡し、パッケージ化を許可する。
【0107】
次に、RHQは、開発元にパッケージ化が許可されたことを伝える。
【0108】
最後に、パッケージ化が許可された開発元は、API実行可否テーブル29bを含んだ最終的なパッケージファイルの作成を行う。
【0109】
以上、本発明におけるプログラムのパッケージ化および課金の流れについて説明した。
【0110】
[補足事項]
以上のように、本発明に係る管理サーバー10は、開発元が開発した、画像形成装置20上で稼働するプログラムをエンドユーザーに配布するためにパッケージ化し、課金するための管理サーバー10であって、前記プログラムを一意に識別可能なプログラムIDをキーとして前記プログラムが登録されるプログラムデータベース17aと、前記プログラムIDに1対1に対応するアイテムコードをキーとして前記アイテムコードが登録されるアイテムコードデータベース17bとが記憶された記憶部17と、前記開発元により前記パッケージ化が申請された前記プログラムを、当該プログラムの前記プログラムIDをキーとして前記プログラムデータベース17aに登録するプログラム登録部11aと、前記プログラムデータベース17aに登録された前記プログラムについて、前記アイテムコードを発行するアイテムコード発行部11bと、前記画像形成装置20の提供する1以上のアプリケーション・プログラミング・インターフェイス(API)の、前記プログラムからの呼び出しおよび実行の可否が記述されたAPI実行可否テーブル29bに基づいて、前記プログラムが前記APIを利用する権利を得るための前記APIごとの価格である有料API情報を、発行された前記アイテムコードに紐付けるAPI情報紐付け部11cと、前記有料API情報が紐付いた前記アイテムコードに基づいて、前記開発元および/または前記エンドユーザーに課金する課金部11dとを備える。
【0111】
そのため、画像形成装置上で稼働するサードパーティープログラムのAPI利用に対し簡単に課金することが出来る。
【0112】
その他、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。