JP6705395B2

JP6705395B2 - 管理サーバーおよび情報処理方法

Info

Publication number: JP6705395B2
Application number: JP2017031916A
Authority: JP
Inventors: 俊史荒木
Original assignee: Kyocera Document Solutions Inc
Current assignee: Kyocera Document Solutions Inc
Priority date: 2017-02-23
Filing date: 2017-02-23
Publication date: 2020-06-03
Anticipated expiration: 2037-02-23
Also published as: JP2018136826A

Description

本発明は、提供されるＡＰＩ（Application Programming Interface）に対する課金を管理する管理サーバーおよび情報処理方法に関する。

近年、ユーザーにサービスを提供するだけで無く、サービスを提供するアプリケーションプログラム等のＡＰＩを提供することが行われるようになってきた。ユーザーは提供されたＡＰＩの中から所望の機能を呼び出して利用するプログラムを作成できるようになってきた。

例えば、特許文献１において開示されている技術では、ＡＰＩ使用を伴うサービスに関しアプリケーション提供者およびアプリケーション利用者によるＡＰＩの使用実績を適切に管理可能とするために、アプリケーション提供者を一意に識別可能なサービスコードと、アプリケーション利用者を一意に識別可能なライセンス情報とを用いている。サービスコードはアプリケーション提供者装置からのＡＰＩ利用要求に対して発行される。ライセンス情報はアプリケーション利用者ごとに発行される。サービス実行時にはこれらサービスコードやライセンス情報に基づき認証を行ってＡＰＩ使用が許可される。

特許５４８５４８５号公報

特許文献１の技術は、ＥＣ（Electronic Commerce）分野でのＡＰＩ使用を想定したものであるが、画像形成装置（ＭＦＰ、Multifunction Peripheral）上で稼働するサードパーティープログラムのＡＰＩ利用に対する課金に用いるには複雑過ぎるものであった。

以上のような事情に鑑み、本発明の目的は、画像形成装置上で稼働するサードパーティープログラムのＡＰＩ利用に対し簡単に課金することが出来る管理サーバーおよび情報処理方法を提供することにある。

上記目的を達成するため、本発明の一形態に係る管理サーバーは、開発元が開発した、画像形成装置上で稼働するプログラムをエンドユーザーに配布するためにパッケージ化し、課金するための管理サーバーであって、前記プログラムを一意に識別可能なプログラムＩＤをキーとして前記プログラムが登録されるプログラムデータベースと、前記プログラムＩＤに１対１に対応するアイテムコードをキーとして前記アイテムコードが登録されるアイテムコードデータベースとが記憶された記憶部と、前記開発元により前記パッケージ化が申請された前記プログラムを、当該プログラムの前記プログラムＩＤをキーとして前記プログラムデータベースに登録するプログラム登録部と、前記プログラムデータベースに登録された前記プログラムについて、前記アイテムコードを発行するアイテムコード発行部と、前記画像形成装置の提供する１以上のアプリケーション・プログラミング・インターフェイス（ＡＰＩ）の、前記プログラムからの呼び出しおよび実行の可否が記述されたＡＰＩ実行可否テーブルに基づいて、前記プログラムが前記ＡＰＩを利用する権利を得るための前記ＡＰＩごとの価格である有料ＡＰＩ情報を、発行された前記アイテムコードに紐付けるＡＰＩ情報紐付け部と、前記有料ＡＰＩ情報が紐付いた前記アイテムコードに基づいて、前記開発元および／または前記エンドユーザーに課金する課金部とを備える。

そのため、画像形成装置上で稼働するサードパーティープログラムのＡＰＩ利用に対し簡単に課金することが出来る。

上記目的を達成するため、本発明の一形態に係る管理サーバーでは、前記ＡＰＩ実行可否テーブルは、前記開発元から提供されてもよい。

上記目的を達成するため、本発明の一形態に係る情報処理方法は、開発元が開発した、画像形成装置上で稼働するプログラムをエンドユーザーに配布するためにパッケージ化し、課金するための管理サーバーにおける情報処理方法であって、前記開発元により前記パッケージ化が申請された前記プログラムを、前記プログラムを一意に識別可能なプログラムＩＤをキーとしてプログラムデータベースに登録し、前記プログラムデータベースに登録された前記プログラムについて、前記プログラムＩＤに１対１に対応するアイテムコードを発行し、前記画像形成装置の提供する１以上のアプリケーション・プログラミング・インターフェイス（ＡＰＩ）の、前記プログラムからの呼び出しおよび実行の可否が記述されたＡＰＩ実行可否テーブルに基づいて、前記プログラムが前記ＡＰＩを利用する権利を得るための前記ＡＰＩごとの価格である有料ＡＰＩ情報を、発行された前記アイテムコードに紐付け、前記有料ＡＰＩ情報が紐付いた前記アイテムコードに基づいて、前記開発元および／または前記エンドユーザーに課金することを前記管理サーバーが実行する。

以上のように、本発明によれば、画像形成装置上で稼働するサードパーティープログラムのＡＰＩ利用に対し簡単に課金することが出来る。

画像形成装置２０の構成を概略的に示す構成図である。典型的な技術により、ｊａｒファイル内のプログラムからＡＰＩを呼び出す場合の仕組みについて説明するための図である。本発明の一実施形態に係る画像形成装置２０でのＡＰＩ呼び出しの仕組みを説明するための図である。画像形成装置２０におけるＡＰＩ呼び出し制御の処理の流れについて説明するためのフローチャートである。管理サーバー１０が一般的なコンピューターにより構成される場合の構成図である。典型的なプログラムのパッケージ化の流れについて説明する図である。本発明におけるプログラムのパッケージ化および課金の流れについて説明するための図である。

以下、図面を参照しながら、本発明の実施形態を説明する。

［概要］
最初に、本発明の概要について説明する。

現在、画像形成装置では、エンドユーザーの課題を解決する手段の一つとして、画像形成装置にインストールしアクティベートして使われるサードパーティー製のアプリケーションプログラム（以下、プログラムと呼ぶ）がある。

プログラムは、画像形成装置の持つ多くの機能を利用するものが数多く存在し、販社など様々なところで開発され、エンドユーザーに提供されている。

プログラムが画像形成装置の様々な機能を利用するためには、画像形成装置から提供される数多くのＡＰＩ群を利用することになる。

ＡＰＩ群には標準で提供されるものに加えて、スキャン・エクステンション・キットなどのオプションで購入されるキットに含まれるものもある。

以下の説明では、スキャン・エクステンション・キットとそこで提供されるＡＰＩ群を例に挙げて説明する。

なお、スキャン・エクステンション・キットとは、原稿をスキャンして得られるスキャンデータをＯＣＲ処理してサーチャブルＰＤＦ（Portable Document Format）を生成したり、スキャンデータをマイクロソフトオフィス形式へ変換したり、バーコード認識したり、マーカー認識したり、ゾーンＯＣＲ機能を提供したり、名刺読み取り機能を提供したりするなど、スキャン機能を拡張するために画像形成装置に内蔵された拡張キットを指す。

典型的な技術では、例えば、スキャン・エクステンション・キットに含まれるＡＰＩ群は、スキャン・エクステンション・キットをアクティベートしなければどれも使用することが出来なかった。スキャン・エクステンション・キットをアクティベートすれば、含まれるＡＰＩ群を全て使用可能なことに加えて、上に挙げた機能を利用するためのメニューが操作パネルに表示されるので、ユーザーはプログラムからのＡＰＩ利用に限らずスキャン・エクステンション・キットの機能を使用することが出来た。

しかし、典型的な技術では、スキャン・エクステンション・キット内の１つの機能をＡＰＩ経由で使いたい場合でも、スキャン・エクステンション・キットをアクティベートしなければならずコスト的に問題であった。

本発明では、例えば、スキャン・エクステンション・キットにより提供される１つ１つのＡＰＩについて、使用の可否を制御でき、課金を制御できるので、エンドユーザーに対し適切なコストパフォーマンスで機能を提供することが出来る。

なお、本発明は、画像形成装置において許可されたＡＰＩのみを使用可能にする仕組みと管理サーバーにおいて使用を許可されたＡＰＩを用いたプログラムを導入したエンドユーザーに対して課金する仕組みとから構成されている。

そこで、最初に、画像形成装置で許可されたＡＰＩのみを使用可能にする仕組みを説明した後、管理サーバーにてエンドユーザーに課金する仕組みについて説明する。

以上、概要について説明した。

［画像形成装置の構成］
次に、本発明の一実施形態に係る画像形成装置２０の構成について説明する。図１は画像形成装置２０の構成を概略的に示す構成図である。

画像形成装置２０は、制御部２１を備える。制御部２１は、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、および専用のハードウェア回路等から構成され、画像形成装置２０の全体的な動作制御を司る。

制御部２１は、原稿読取部２２、画像処理部２３、画像メモリー２４、画像形成部２５、操作部２６、表示部２６ａ、ファクシミリ通信部２７、通信部２８、記憶部２９等と接続されている。制御部２１は、接続されている上記各部の動作制御や、各部との間での信号又はデータの送受信を行う。

制御部２１は、ユーザーから、操作部２６またはネッワーク接続されたＰＣ（Personal Computer）等を通じて入力されるジョブの実行指示に従って、スキャナ機能、印刷機能、コピー機能、およびファクシミリ送受信機能などの各機能についての動作制御を実行するために必要な機構の駆動及び処理を制御する。

また、制御部２１は、プログラム実行プラットフォーム２１ａを有している。プログラム実行プラットフォーム２１ａは、ＲＯＭなどからＲＡＭにロードされたプログラムがＣＰＵにより実行されることで実現される機能ブロックである。

プログラム実行プラットフォーム２１ａは、画像形成装置２０上でプログラムを実行するためのプラットフォームであり、テーブルチェック部２１ｂおよびＡＰＩ群２１ｃを含んでいる。

テーブルチェック部２１ｂは、ＡＰＩ実行可否テーブル２９ｂ（後述）をチェックし、画像形成装置２０上で実行されるプログラムから呼び出されたＡＰＩを実行するか否かを制御する。

ＡＰＩ群２１ｃは、例えば、上述したスキャン・エクステンション・キットなどにより提供される一連のＡＰＩである。

原稿読取部２２は、原稿から画像を読み取る。

画像処理部２３は、原稿読取部２２で読み取られた画像の画像データを必要に応じて画像処理する。例えば、画像処理部２３は、原稿読取部２２により読み取られた画像が画像形成された後の品質を向上させるために、シェーディング補正等の画像処理を行う。

画像メモリー２４は、原稿読取部２２による読み取りで得られた原稿画像のデータを一時的に記憶したり、画像形成部２５での印刷対象となるデータを一時的に記憶したりする領域である。

画像形成部２５は、原稿読取部２２で読み取られた画像データ等の画像形成を行う。

操作部２６は、画像形成装置２０が実行可能な各種動作及び処理についてユーザーからの指示を受け付けるタッチパネル部および操作キー部を備える。タッチパネル部は、タッチパネルが設けられたＬＣＤ（Liquid Crystal Display）等の表示部２６ａを備えている。

ファクシミリ通信部２７は、図示しない符号化／復号化部、変復調部、およびＮＣＵ（Network Control Unit）を備え、公衆電話回線網を用いてのファクシミリの送信を行う。

通信部２８は、ＬＡＮボード等の通信モジュールから構成され、通信部２８に接続されたＬＡＮ等を介して、ネットワーク上の装置(ＰＣ等)と種々のデータの送受信を行う。

記憶部２９は、原稿読取部２２によって読み取られた原稿画像およびパッケージファイル２９ａなどを記憶する。記憶部２９は、ＨＤＤなどの大容量の記憶装置である。

パッケージファイル２９ａは、プログラムを画像形成装置２０にインストールし、プログラム実行プラットフォーム２１ａ上で実行させるためのファイルであり、ＡＰＩ実行可否テーブル２９ｂおよびｊａｒファイル２９ｃ（格納ファイル）を含んでいる。

ＡＰＩ実行可否テーブル２９ｂは、このテーブルを持つプログラムが、ＡＰＩ群２１ｃのうちどのＡＰＩの使用が許可されているかを示すテーブルである。

ｊａｒファイル２９ｃは、プログラム実行プラットフォーム２１ａ上で実行させるプログラムをｊａｒ（Java（登録商標） Archive）形式で格納したファイルである。なお、ここでは画像形成装置２０上で実行させるプログラムとしてｊａｖａ（登録商標）プログラムを想定しているのでパッケージファイル２９ａではプログラムを格納するファイルとしてｊａｒ形式のファイルを想定しているが、この構成に限られるものではない。

以上、画像形成装置２０の構成について説明した。

［典型的なＡＰＩ呼び出し］
次に、本発明によるＡＰＩ使用制御と対比させるために、典型的な技術により、ｊａｒファイル内のプログラムからＡＰＩを呼び出す場合の仕組みについて説明する。図２は、典型的な技術により、ｊａｒファイル内のプログラムからＡＰＩを呼び出す場合の仕組みについて説明するための図である。

まず、プログラムの開発元であるサードパーティーが、申請ファイルを作成する。申請ファイルは、プログラムのパッケージ化の許可をメーカーから得るための申請を行う際に作成されるファイルである。

申請ファイルには、プログラムＩＤ（Identification）、プログラム名などのプログラム情報が記載される。

次に、パッケージ化の許可を貰った開発元が作るのがパッケージファイルである。パッケージファイルには、申請ファイルに記載されていたプログラム情報に加えて、ｊａｒ形式でプログラムが格納されたｊａｒファイルが追加される。

パッケージファイルは、開発元または画像形成装置のメーカーなどによりエンドユーザーに提供され、画像形成装置にインストールされ利用される。

インストールされたプログラムの実行時には、ｊａｒファイル内のプログラムからプログラム実行プラットフォーム上のＡＰＩ群が呼び出される形となる。

以上、典型的な技術により、ｊａｒファイル内のプログラムからＡＰＩを呼び出す場合の仕組みについて説明した。

［本発明によるＡＰＩ呼び出し］
次に、本発明の一実施形態に係る画像形成装置２０でのＡＰＩ呼び出しの仕組みを説明する。図３は、本発明の一実施形態に係る画像形成装置２０でのＡＰＩ呼び出しの仕組みを説明するための図である。

まず、図２に示した典型的な技術と異なる点は、申請ファイルに、ＡＰＩ実行可否テーブル２９ｂが追加されている点である。このテーブルにより、開発元は、パッケージ化を申請するプログラムがどのＡＰＩを呼び出すかを申請することになる。

ＡＰＩ実行可否テーブル２９ｂは、パッケージファイル２９ａに引き継がれ、プログラム情報およびｊａｒファイル２９ｃと共に、パッケージファイル２９ａを構成する。

プログラムの実行時には、ｊａｒファイル内のプログラムからＡＰＩ群２１ｃ内のＡＰＩが呼び出されると、逐一テーブルチェック部２１ｂがパッケージファイル内のＡＰＩ実行可否テーブル２９ｂをチェックし、ＡＰＩの呼び出しの可否を決定する。

例えば、図３に示す例では、ＳｃａｎＴｏＷｏｒｄというＡＰＩは、ＡＰＩ実行可否テーブル２９ｂで「ｏｎ」になっているので、テーブルチェック部２１ｂはＡＰＩ呼び出しを許可し、呼び出されたＡＰＩはそのまま実行され、スキャンデータはＷＯＲＤ形式に変換される。また、ＳｃａｎＴｏＥｘｃｅｌというＡＰＩは、ＡＰＩ実行可否テーブル２９ｂで「ｏｆｆ」になっているので、テーブルチェック部２１ｂはＡＰＩ呼び出しを許可せず、このＡＰＩを呼び出しても実行はされずエラーとなる。

以上、本発明の一実施形態に係る画像形成装置２０でのＡＰＩ呼び出しの仕組みを説明した。

［処理の流れ］
次に、画像形成装置２０におけるＡＰＩ呼び出し制御の処理の流れについて説明する。図４は、画像形成装置２０におけるＡＰＩ呼び出し制御の処理の流れについて説明するためのフローチャートである。

まず、ユーザーの指示に基づき、プログラム実行プラットフォーム２１ａがパッケージファイル２９ａのｊａｒファイル２９ｃ内のプログラムを実行する（ステップＳ１）。

次に、実行されたプログラムがＡＰＩの呼び出しを行う（ステップＳ２）。

次に、テーブルチェック部２１ｂが、パッケージファイル２９ａ内のＡＰＩ実行可否テーブル２９ｂをチェックする（ステップＳ３）。

次に、テーブルチェック部２１ｂが、ＡＰＩ実行可否テーブル２９ｂに基づき、呼び出されたＡＰＩの実行が許可されているか否かをチェックする（ステップＳ４）。

ＡＰＩの実行が許可されている場合（ステップＳ４のＹ）、呼び出されたＡＰＩが実行され処理が終了する（ステップＳ５）。

ＡＰＩの実行が許可されていない場合（ステップＳ４のＮ）、ＡＰＩの呼び出しはエラーとなり処理は終了する（ステップＳ６）。

以上、画像形成装置２０におけるＡＰＩ呼び出し制御の処理の流れについて説明した。

［管理サーバーの構成］
次に、課金を行う管理サーバー１０の構成について説明する。管理サーバー１０は、専用のハードウェアやソフトウェアにより構成されていてもよいし、一般的なコンピューターにより構成されてもよい。管理サーバー１０が一般的なコンピューターにより構成される場合の構成図を図５に示す。

同図に示すように、管理サーバー１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、操作入力部１４、通信部１５、表示部１６、および記憶部１７を有し、これら各ブロックがバス１８を介して接続されている。

ＲＯＭ１２は、各種の処理を実行するためのファームウェア等の複数のプログラムやデータを記憶する。ＲＡＭ１３は、ＣＰＵ１１の作業用領域として用いられ、ＯＳ（Operating System）、実行中の各種アプリケーション、処理中の各種データを一時的に保持する。

記憶部１７は、例えばＨＤＤ（Hard Disk Drive）や、フラッシュメモリー、その他の不揮発性メモリーである。記憶部１７には、ＯＳや各種アプリケーション、各種データ、プログラムＤＢ（Database）１７ａおよびアイテムコードＤＢ１７ｂが記憶される。

プログラムＤＢ１７ａは、開発元により開発されたプログラムを登録し管理するデータベースである。プログラムＩＤをキーとして登録されてもよい。

アイテムコードＤＢ１７ｂは、開発されたプログラムに一意に対応したアイテムコードを登録し管理するデータベースである。アイテムコードは、プログラムを開発した開発元や開発されたプログラムを導入し使用するエンドユーザーに対し、ＡＰＩ使用権の使用料を課金するために用いられる。

通信部１５は、ネットワーク上のＰＣ等と情報のやりとりを行う為のネットワークと結ばれている。

ＣＰＵ１１は、ＲＯＭ１２や記憶部１７に格納された複数のプログラムのうち、操作入力部１４から与えられる命令に対応するプログラムをＲＡＭ１３に展開し、この展開されたプログラムにしたがって、表示部１６及び記憶部１７を適宜制御する。

操作入力部１４は、例えばマウス等のポインティングデバイス、キーボード、タッチパネル、その他の操作装置である。

表示部１６は、例えば液晶ディスプレイ、ＥＬ（Electro-Luminescence）ディスプレイ、プラズマディスプレイ等である。

次に、ＣＰＵ１１においてプログラムが実行されることにより実現される機能ブロックについて説明する。

管理サーバー１０のＣＰＵ１１において実現される機能ブロックは、プログラム登録部１１ａ、アイテムコード発行部１１ｂ、ＡＰＩ情報紐付け部１１ｃ、および課金部１１ｄである。

プログラム登録部１１ａは、開発元により開発され、パッケージ化の申請がなされたプログラムを、当該プログラムのプログラムＩＤをキーとしてプログラムＤＢ１７ａに登録する。

アイテムコード発行部１１ｂは、プログラムＤＢ１７ａに登録されたプログラムについて、課金に用いるためのアイテムコードを発行する。なお、発行されたアイテムコードは、アイテムコードＤＢ１７ｂに登録される。

ＡＰＩ情報紐付け部１１ｃは、発行されたアイテムコードに、有料ＡＰＩ情報を紐付け、紐付けられた有料ＡＰＩ情報をアイテムコードＤＢ１７ｂ内の登録されたアイテムコードに紐付けて登録する。なお、有料ＡＰＩ情報とは、ＡＰＩ群２１ｃで提供される個々のＡＰＩをプログラムが利用する権利を得るためのＡＰＩごとの価格である。

なお、紐付けは申請ファイルに含まれるＡＰＩ実行可否テーブル２９ｂの記載に基づいて行われてもよい。例えば、ＡＰＩ実行可否テーブル２９ｂに「ＳｃａｎＴｏＷｏｒｄ＝ｏｎ」（それ以外のＡＰＩについてはｏｆｆであるとする）の記載があるプログラムでは、「ＳｃａｎＴｏＷｏｒｄ１００円」という有料ＡＰＩ情報がアイテムコードに紐付けられ、「ＳｃａｎＴｏＥｘｃｅｌ１５０円」という有料ＡＰＩ情報はアイテムコードに紐付けられないことになる。この場合、課金部１１ｄはアイテムコードに紐付けられた個々の有料ＡＰＩ情報を積算することにより実際の課金額を計算する。

課金部１１ｄは、特定のＡＰＩを呼び出すプログラムを開発した開発元および／またはそのプログラムを利用するエンドユーザーにアイテムコードに基づいて課金する。

なお、実際の課金は、パッケージ化の申請ファイルに含まれるＡＰＩ実行可否テーブル２９ｂの内容に基づいて行われてもよい。その場合、ＡＰＩ実行可否テーブル２９ｂの内容がアイテムコードＤＢ１７ｂに登録されてもよい。課金部１１ｄは、アイテムコードＤＢ１７ｂにアイテムコードをキーとして登録されているＡＰＩ実行可否テーブル２９ｂの内容に基づいて実際の課金額を算出してもよい。

例えば、「ＳｃａｎＴｏＷｏｒｄ」のＡＰＩ利用権が１００円と有料ＡＰＩ情報で定められている場合、ＡＰＩ実行可否テーブル２９ｂに「ＳｃａｎＴｏＷｏｒｄ＝ｏｎ」（それ以外のＡＰＩについてはｏｆｆであるとする）の記載があるプログラムでは、１００円が課金される。

以上、管理サーバー１０の構成について説明した。

［典型的なプログラムのパッケージ化の流れ］
次に、本発明におけるプログラムのパッケージ化および課金の流れと対比させるために、典型的なプログラムのパッケージ化の流れについて説明する。図６は、典型的なプログラムのパッケージ化の流れについて説明する図である。

まず、開発元（図では開発元の販社として示す）が画像形成装置２０上で動作するプログラムを開発する。

次に、開発元は、画像形成装置２０のメーカーから提供された動作チェックツールを用いて動作テストを行い、動作チェック結果を得る。開発元は、開発したプログラムを配布するためのパッケージ化を行うための申請をリージョナルヘッドクォーター（以下、ＲＨＱと呼ぶ）に対して行う。申請は、動作チェック結果と申請ファイルを添付して行う。

次に、開発元からパッケージ化の申請を受領したＲＨＱは、申請内容を確認した後、画像形成装置２０のメーカーに対しパッケージ化の申請を行う。

次に、申請を受けた画像形成装置２０のメーカーは、申請内容を確認した後、プログラムを管理サーバーに登録する。

次に、管理サーバーが登録されたプログラムに対応したアイテムコードを発行する。

次に、画像形成装置２０のメーカーは、ＲＨＱに発行されたアイテムコードを連絡し、パッケージ化を許可する。

次に、ＲＨＱは、開発元にパッケージ化が許可されたことを伝える。

最後に、パッケージ化が許可された開発元は、最終的なパッケージファイルの作成を行う。

以上、典型的なプログラムのパッケージ化の流れについて説明した。

［本発明によるパッケージ化と課金の流れ］
次に、本発明におけるプログラムのパッケージ化および課金の流れについて説明する。図７は、本発明におけるプログラムのパッケージ化および課金の流れについて説明するための図である。

まず、開発元が画像形成装置２０上で動作するプログラムを開発する。

次に、開発元は、画像形成装置２０のメーカーから提供された動作チェックツールを用いて動作テストを行い、動作チェック結果を得る。開発元は、開発したプログラムを配布するためのパッケージ化を行うための申請をＲＨＱに対して行う。申請は、動作チェック結果と申請ファイルを添付して行う。なお、申請ファイルには、上述したように、ＡＰＩ実行可否テーブル２９ｂが記載されている。

次に、申請を受けた画像形成装置２０のメーカーは、申請内容を確認した後、申請内容に含まれるプログラムＩＤをキーとして、当該プログラムを管理サーバーに登録する。

次に、管理サーバーが、登録されたプログラムに対応したアイテムコードを発行する。

次に、管理サーバーは、発行されたアイテムコードと有料ＡＰＩ情報との紐付けを行う。

次に、管理サーバーは、プログラムの開発元および／または当該パッケージファイルを導入するエンドユーザーに対し、アイテムコードに基づき課金する。

最後に、パッケージ化が許可された開発元は、ＡＰＩ実行可否テーブル２９ｂを含んだ最終的なパッケージファイルの作成を行う。

以上、本発明におけるプログラムのパッケージ化および課金の流れについて説明した。

［補足事項］
以上のように、本発明に係る管理サーバー１０は、開発元が開発した、画像形成装置２０上で稼働するプログラムをエンドユーザーに配布するためにパッケージ化し、課金するための管理サーバー１０であって、前記プログラムを一意に識別可能なプログラムＩＤをキーとして前記プログラムが登録されるプログラムデータベース１７ａと、前記プログラムＩＤに１対１に対応するアイテムコードをキーとして前記アイテムコードが登録されるアイテムコードデータベース１７ｂとが記憶された記憶部１７と、前記開発元により前記パッケージ化が申請された前記プログラムを、当該プログラムの前記プログラムＩＤをキーとして前記プログラムデータベース１７ａに登録するプログラム登録部１１ａと、前記プログラムデータベース１７ａに登録された前記プログラムについて、前記アイテムコードを発行するアイテムコード発行部１１ｂと、前記画像形成装置２０の提供する１以上のアプリケーション・プログラミング・インターフェイス（ＡＰＩ）の、前記プログラムからの呼び出しおよび実行の可否が記述されたＡＰＩ実行可否テーブル２９ｂに基づいて、前記プログラムが前記ＡＰＩを利用する権利を得るための前記ＡＰＩごとの価格である有料ＡＰＩ情報を、発行された前記アイテムコードに紐付けるＡＰＩ情報紐付け部１１ｃと、前記有料ＡＰＩ情報が紐付いた前記アイテムコードに基づいて、前記開発元および／または前記エンドユーザーに課金する課金部１１ｄとを備える。

その他、本発明は、上述の実施形態にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。

１０ … 管理サーバー
１１ … ＣＰＵ
１１ａ… プログラム登録部
１１ｂ… アイテムコード発行部
１１ｃ… ＡＰＩ情報紐付け部
１１ｄ… 課金部
１２ … ＲＯＭ
１３ … ＲＡＭ
１４ … 操作入力部
１５ … 通信部
１６ … 表示部
１７ … 記憶部
１７ａ… プログラムＤＢ
１７ｂ… アイテムコードＤＢ
１８ … バス
２０ … 画像形成装置
２１ … 制御部
２１ａ… プログラム実行プラットフォーム
２１ｂ… テーブルチェック部
２１ｃ… ＡＰＩ群
２２ … 原稿読取部
２３ … 画像処理部
２４ … 画像メモリー
２５ … 画像形成部
２６ … 操作部
２６ａ… 表示部
２７ … ファクシミリ通信部
２８ … 通信部
２９ … 記憶部
２９ａ… パッケージファイル
２９ｂ… ＡＰＩ実行可否テーブル
２９ｃ… ｊａｒファイル

Claims

画像形成装置上で稼働するプログラムをパッケージ化するための管理サーバーであって、
前記プログラムを一意に識別可能なプログラムＩＤをキーとして前記プログラムが登録されるプログラムデータベースと、前記プログラムＩＤに１対１に対応するアイテムコードをキーとして前記アイテムコードが登録されるアイテムコードデータベースとが記憶された記憶部と、
前記パッケージ化が申請された前記プログラムを、当該プログラムの前記プログラムＩＤをキーとして前記プログラムデータベースに登録し、
前記プログラムデータベースに登録された前記プログラムについて、前記アイテムコードを発行し、
前記画像形成装置の提供する１以上のアプリケーション・プログラミング・インターフェイス（ＡＰＩ）の、前記プログラムからの呼び出しおよび実行の可否が記述されたＡＰＩ実行可否テーブルに基づいて、前記プログラムが前記ＡＰＩを利用する権利を得るための前記ＡＰＩごとの価格である有料ＡＰＩ情報を、発行された前記アイテムコードに紐付け、
前記アイテムコードに紐づけられた個々の前記有料ＡＰＩ情報を積算することにより、課金額を計算する
プロセッサーと
を備えた
管理サーバー。
請求項１に記載の管理サーバーであって、
前記ＡＰＩ実行可否テーブルは、
前記プログラムを開発する開発元から提供される
管理サーバー。
画像形成装置上で稼働するプログラムをパッケージ化するための管理サーバーにおける情報処理方法であって、
前記パッケージ化が申請された前記プログラムを、前記プログラムを一意に識別可能なプログラムＩＤをキーとしてプログラムデータベースに登録し、
前記プログラムデータベースに登録された前記プログラムについて、前記プログラムＩＤに１対１に対応するアイテムコードを発行し、
前記画像形成装置の提供する１以上のアプリケーション・プログラミング・インターフェイス（ＡＰＩ）の、前記プログラムからの呼び出しおよび実行の可否が記述されたＡＰＩ実行可否テーブルに基づいて、前記プログラムが前記ＡＰＩを利用する権利を得るための前記ＡＰＩごとの価格である有料ＡＰＩ情報を、発行された前記アイテムコードに紐付け、
前記アイテムコードに紐づけられた個々の前記有料ＡＰＩ情報を積算することにより、課金額を計算する
ことを前記管理サーバーが実行する情報処理方法。