JPWO2015025405A1 - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

ＡＰＩ使用を伴うサービスに関しアプリケーション提供者及びアプリケーション利用者の実績を適切に管理可能とする。情報処理装置は、アプリケーション提供者装置から送信されてきたＡＰＩを使用するアプリケーションプログラムを用いたサービスについてのＡＰＩ利用要求に対し、サービスコードを発行し、サービス識別情報及び使用ＡＰＩ情報をサービスコードと対応させて登録する。またアプリケーション提供者による利用者特定情報に応じてアプリケーション利用者毎に未承認状態のライセンス情報を発行する。このライセンス情報はアプリケーション利用者が承認してライセンス承認情報が登録される。サービス実行時はこのような登録情報を用いて認証を行ってＡＰＩ使用を許可する。この場合にサービスコードによりアプリケーション提供者が識別でき、ライセンス情報によりアプリケーション利用者が識別できることを利用して、それぞれのＡＰＩ使用の実績情報を生成する。

Description

本発明は、ＡＰＩ（Application Program Interface ）を使用するサービスにおいて用いられる情報処理装置とその情報処理方法、情報処理装置を実現するプログラム、及びプログラムを記憶した記憶媒体に関する。

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

上記特許文献１には、作成されたサービスプログラムについての登録要求に対してチェック処理を行い、サービスプログラムに規定されている機能モジュールの全てが利用可能な機能モジュールか否かを確認して、ＯＫならサービスＩＤ（identification）発行、及びクライアントＩＤに対応づけて登録することが記載されている。
上記特許文献２には、 アプリケーションサーバがクライアントからのリクエストに対して認証を行い、ＡＰＩアクセス要求であった場合は、認証処理結果をリクエストに付随させてＡＰＩサーバに送信し、ＡＰＩサーバは認証処理結果に基づいてリクエスト処理を行うことが記載されている。

例えばインターネットサービスの分野では、プログラムがＡＰＩを利用してシステム間で情報の受け渡しが行われている。
ＡＰＩの使用に関しては、ＡＰＩを用いたネットワークサービスを実現するアプリケーションプログラム（以下「サービスアプリケーション」という）を提供するアプリケーション提供者、サービスアプリケーションによるサービスを享受するアプリケーション利用者、ＡＰＩを提供するサーバ管理者、ＡＰＩで扱われるデータの提供者や所有者など、各種の立場が存在する。
このような状況で、ＡＰＩを提供するサーバ管理者側から見ると、ＡＰＩ使用に関連するサービスアプリケーションの提供者、利用者について、ＡＰＩ使用実績を的確に把握したいという要請がある。
そこで本発明は、ＡＰＩを使用するサービスの有用性を損なわずに、ＡＰＩ使用やＡＰＩが扱うデータの安全性を確保できるようにしたうえで、ＡＰＩ使用に関するアプリケーション提供者、アプリケーション利用者のＡＰＩ使用実績管理を的確に行うことができるようにする。

第１に、本発明に係る情報処理装置は、予め用意されたＡＰＩを使用するアプリケーションプログラムが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置であって、ＡＰＩを使用するアプリケーションプログラムを用いたサービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報を取得する登録情報取得部と、前記アプリケーションプログラムの実行に伴うＡＰＩ使用要求があった際に、当該ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいて前記登録情報取得部により取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の確認を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する認証処理部と、ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する実績管理部と、を備えたものである。
このような情報処理装置は、まず複数のアプリケーションプログラムが提供される状況下で、複数のサービス利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるシステムで用いられる。そしてこの情報処理装置では、ＡＰＩ使用を伴うサービスをアプリケーションプログラムにより実行する場合に、サービスコードとライセンス情報を用いた認証が行われる。
アプリケーション提供者は、サービスコードと一体化されたアプリケーションプログラムを提供する。サービスコードは、使用ＡＰＩ情報とサービス識別情報に紐づけられている。アプリケーション利用者は自身で承認したライセンス情報を用いてアプリケーションプログラムを実行する。このような前提でサービスコードとライセンス情報を用いた認証が行われることで、アプリケーション利用者が意図しないサービス利用や、ＡＰＩ使用による情報アクセスが制限される。
さらにサービスコードとライセンスを用いた、サービスの実行時の実績管理が行われる。サービスコードによりアプリケーション提供者の実績管理が可能となり、ライセンス情報によりアプリケーション利用者の実績管理が可能となる。

第２に、上記した本発明に係る情報処理装置においては、前記実績管理部は、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者に対する課金情報を生成することが望ましい。
即ちアプリケーション提供者に対する個別課金を可能とする。

第３に、上記した本発明に係る情報処理装置においては、前記実績管理部は、ＡＰＩ使用要求におけるライセンス情報に基づいて、アプリケーション利用者に対する課金情報を生成することが望ましい。
即ちアプリケーション利用者に対する個別課金を可能とする。

第４に、上記した本発明に係る情報処理装置においては、前記認証処理部は、前記アプリケーションプログラムが実行された外部端末装置からＡＰＩ使用要求とともに送信されてくる前記サービスコード及び前記ライセンス情報を受信して認証処理を行うことが望ましい。
即ちＡＰＩ使用要求とともに送信されてくるサービスコードやライセンス情報に紐付けされた登録情報を用いて認証を行う。

第５に、上記した本発明に係る情報処理装置においては、前記認証処理部は、サービスコード、サービス識別情報、使用ＡＰＩ情報、及びライセンス承認情報の全てについて所定の確認ができた場合に、ＡＰＩ使用要求に係るＡＰＩ使用を許可することが望ましい。
これにより情報の安全性確保を最優先した運用を実現する。

第６に、上記した本発明に係る情報処理装置においては、前記登録情報には前記ライセンス情報に対応する端末識別情報が含まれており、前記認証処理部は、認証処理において、前記アプリケーションプログラムが実行されＡＰＩ使用要求を送信してきた外部端末装置について前記端末識別情報を用いた認証も行うことが望ましい。
即ち端末単位で正規使用を認証する。

第７に、本発明に係る情報処理方法は、上述のシステムに備わる情報処理装置の情報処理方法であって、ＡＰＩを使用するアプリケーションプログラムを用いたサービスによるＡＰＩ使用要求についてのサービスコードとライセンス情報を取得し、前記サービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報に対して、前記ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいてアクセスし、前記アクセスで取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の照合を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可し、ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する情報処理方法である。この情報処理方法により適切な実績管理を可能とする。

第８に、本発明に係るプログラムは、上記情報処理方法として実行する処理を情報処理装置に実行させるプログラムである。
第９に、本発明に係る記憶媒体は、上記プログラムは記憶したプログラムである。
これらのプログラムや記憶媒体により上記の情報処理装置を実現する。

本発明によれば、サービスコードによりアプリケーション提供者を管理可能であり、かつライセンス情報によりアプリケーション利用者を管理可能となる。また認証ＯＫの場合に実績管理を行う。これによりＡＰＩ使用に対する実績をアプリケーション提供者、アプリケーション利用者のそれぞれについて適正なＡＰＩ使用の実績管理が可能となる。

本発明の実施の形態のネットワークシステムの説明図である。 実施の形態のコンピュータ装置のブロック図である。 実施の形態のＥＣシステムのブロック図である。 実施の形態の登録情報の説明図である。 実施の形態の登録時の動作の説明図である。 実施の形態のサービスコード処理の説明図である。 実施の形態のライセンス処理の説明図である。 実施の形態のライセンス承認処理の説明図である。 実施の形態の提供者ＷＥＢのＡＰＩ使用登録要求の入力画面の説明図である。 実施の形態の提供者ＷＥＢのサービスコード発行画面の説明図である。 実施の形態の提供者ＷＥＢのライセンス発行画面の説明図である。 実施の形態の利用者ＷＥＢのライセンスリスト画面の説明図である。 実施の形態の利用者ＷＥＢのライセンス内容確認画面の説明図である。 実施の形態の利用者ＷＥＢのライセンス承認画面の説明図である。 実施の形態のサービス利用時の動作の説明図である。 実施の形態のサービス利用時の処理例Ｉの説明図である。 実施の形態のサービス利用時の認証処理のフローチャートである。 実施の形態のサービス利用時の実績管理処理のフローチャートである。 実施の形態の実績情報の説明図である。 実施の形態の他の登録情報の説明図である。 実施の形態のサービス利用時の動作の説明図である。 実施の形態のサービス利用時の処理例IIの説明図である。 実施の形態のサービス利用時の認証処理のフローチャートである。 実施の形態のサービス利用時の処理例IIIの説明図である。 実施の形態のサービス利用時の動作の説明図である。 実施の形態のサービス利用時の処理例IVの説明図である。

以下、実施の形態を次の順序で説明する。
＜１．ネットワークシステム構成＞
＜２．ＥＣ管理システム＞
＜３．登録時の処理＞
＜４．サービス実行時の処理例Ｉ＞
＜５．サービス実行時の処理例II＞
＜６．サービス実行時の処理例III＞
＜７．サービス実行時の処理例IV＞
＜８．ＥＣ管理システムの実施による効果＞
＜９．プログラム及び記憶媒体＞
＜１０．変形例＞

＜１．ネットワークシステム構成＞
図１にネットワークシステムの例を示す。このネットワークシステムはＥＣ（ＥＣ：electronic commerce（電子商取引））システムとして機能する。
図１におけるＥＣ管理システム１が本発明の情報処理装置の実施の形態に相当する。
ネットワークシステムは、ネットワーク２を介して、ＥＣ管理システム１、アプリケーション提供者装置３Ａ、３Ｂ、３Ｃ・・・、アプリケーション利用者装置４Ａ、４Ｂ、４Ｃ・・・が互いに通信可能に構成されている。なおアプリケーション提供者装置３Ａ、３Ｂ・・・を特に区別しない場合は「アプリケーション提供者装置３」と総称する。同様にアプリケーション利用者装置４Ａ、４Ｂ、４Ｃ・・・を特に区別しない場合は「アプリケーション利用者装置４」と総称する。
さらに「アプリケーション提供者装置」「アプリケーション利用者装置」は、単に「提供者装置」「利用者装置」と略称する。

このネットワークシステムでは、ＥＣ管理システム１において各種ＡＰＩが使用可能に提供されている。この予め用意されたＡＰＩを使用するサービスアプリケーションを複数のアプリケーション提供者の各々が提供し、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるネットワークサービス（説明上、単に「サービス」ともいう）を享受することができる。
なお「サービス」とは、１つのタイトルとしてのサービスアプリケーションによって実現されるサービスを指す。

提供者装置３は、アプリケーション提供者が使用するネットワーク端末としての情報処理装置である。
アプリケーション提供者とは、サービスを実現するプログラムであるサービスアプリケーションを提供する個人や団体を指す。例えばサービスアプリケーションの開発や販売を行うソフトウエアデベロッパー／ベンダーであったり、或いはクラウドサービス等でサービスアプリケーションによるサービスを提供する業者等である。
図では提供者装置３Ａは、サービスアプリケーションとしてのパッケージ提供者が用いる情報処理装置としている。このパッケージ提供者とは、例えば複数のサービスアプリケーションＳＡ１，ＳＡ２，ＳＡ３としての各プログラムのダウンロードサービス、或いは光ディスクその他のパッケージメディアでのサービスアプリケーションの販売・譲渡等を行う団体又は個人である。
提供者装置３Ｂは、アプリケーション利用者の依頼等に応じて所有するサービスアプリケーションＳＡ１０を実行し、クラウドサービス的にサービスをアプリケーション利用者に提供する団体又は個人が使用する情報処理装置としている。例えばインターネットを通じて顧客（アプリケーション利用者）にサービスを提供する目的でサービスアプリケーションを実行する、いわゆるＡＳＰ（Application Service Provider）が、この場合のアプリケーション提供者に相当する。
また提供者装置３Ｃは、複数のサービスアプリケーションＳＡ２０，ＳＡ２１としての各プログラムを提供するアプリケーション提供者が使用する情報処理装置としている。
このように本実施の形態のネットワークシステムは、複数のアプリケーション提供者の各々が、１又は複数のサービスアプリケーションを提供することで、複数のサービスアプリケーションが提供される状況が得られている。またそのサービスアプリケーションは、ＥＣ管理システム１が予め用意したＡＰＩを使用するプログラムである。
なお、図１では複数のアプリケーション提供者が存在する場合を示しているが、単一のアプリケーション提供者が、複数のサービスアプリケーションを提供するという形態もあり得る。

利用者装置４は、アプリケーション利用者が使用するネットワーク端末としての情報処理装置である。
アプリケーション利用者とは、アプリケーション提供者にとっての顧客に当たる存在であり、例えばネットワークによる商品販売を店舗により行う者（商品販売業者）である。例えば店舗とは、ウエブサイトによる電子店舗であったり実際の店舗である。図では利用者装置４Ａ、４Ｂ、４Ｃは、異なる販売業者の情報処理装置として示している。
アプリケーション利用者は、提供者装置３が提供するサービスアプリケーションにより、例えば在庫管理サービス、販売管理サービスなどのサービスを受けて販売業務の効率化等を図ることができる。
なおアプリケーション利用者は、販売業者に限らず、或るサービスアプリケーションによるサービスを享受するあらゆる団体、個人が想定される。販売業者というのは一例である。
１又は複数のアプリケーション提供者によって、複数のサービスアプリケーションが提供されることで、各アプリケーション利用者は、複数のサービスアプリケーションの中で、自己が必要と考えるサービスアプリケーションを利用し、そのサービスアプリケーションによるサービスを享受できる。

ＥＣ管理システム１は、本実施の形態では、電子商取引システムを実現する当該ネットワークシステムにおいて次の機能を実行する情報処理装置としている。
・サービスアプリケーションが使用するＡＰＩの提供
・ＡＰＩを使用するサービスアプリケーションの登録に関する処理
・サービスアプリケーションの実行の際の認証に関する処理
・サービスアプリケーションの実行に伴うＡＰＩ使用実績の管理に関する処理
これらについて詳しくは後述するが、ＥＣ管理システム１は、これらの処理を実行すべく必要な構成を備える。
またＥＣ管理システム１は、電子商取引システムの管理者としての役割を持ってもよい。例えばアプリケーション利用者における電子店舗としての開設や、電子市場提供等のサービスを行う機能を持ってもよい。

ネットワーク２の構成は多様な例が想定される。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が想定される。
またネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線等の有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。

なお以上の図１では後述する本実施の形態の動作に直接関連する情報処理装置（ネットワーク端末）のみを示しており、実際には他にも各種の情報処理装置が本例のネットワークシステムに関連する。
例えばアプリケーション利用者としての店舗からネットワーク２を介した商品購入を行う一般ユーザの情報処理装置、ＥＣ管理システム１で提供するＡＰＩの開発者の情報処理装置、ＡＰＩの承認／管理／メンテナンス等を行うＡＰＩ管理者の情報処理装置などが存在する。

続いて図１に示したＥＣ管理システム１、提供者装置３、利用者装置４を構成する情報処理装置のハードウエア構成を図２に示す。ＥＣ管理システム１、提供者装置３、利用者装置４等の各装置は、情報処理および情報通信が可能な図２に示すようなコンピュータ装置として実現できる。

図２において、コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インターフェース１０５も接続されている。
入出力インターフェース１０５には、キーボード、マウス、タッチパネルなどよりなる入力部１０６、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどよりなる出力部１０７、ＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などより構成される記憶部１０８、ネットワーク２を介しての通信処理や機器間通信を行う通信部１０９が接続されている。
入出力インターフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われたり、リムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、ＥＣ管理システム１、提供者装置３、利用者装置４のそれぞれにおいて後述する情報処理や通信が実行される。
なお、ＥＣ管理システム１、提供者装置３、利用者装置４を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。

＜２．ＥＣ管理システム＞
例えば上述のコンピュータ装置として実現されるＥＣ管理システム１の機能構成を図３で説明する。図３は本実施の形態においてＥＣ管理システム１が行う動作について必要な機能、即ち主にＣＰＵ１０１の処理及び制御によって実現される機能をブロック化して示している。
本実施の形態のＥＣ管理システム１は機能構成として、登録サーバ１０、ＡＰＩサーバ２０、登録データベース３０、店舗情報データベース３１、実績データベース３２を備える。

登録サーバ１０は、ＡＰＩを使用するサービスアプリケーションによって実現されるサービスについての登録処理を行う。このためサービスコード処理部１１ａ及びライセンス処理部１１ｂとしての機能を持つ登録管理部１１が設けられる。
なお、サービスコード処理部１１ａはサービスコードに関する処理を行う機能、ライセンス処理部１１ｂはライセンス情報に関する処理を行う機能として、登録管理部１１が有する構成を示している。実際にはサービスコード処理部１１ａとライセンス処理部１１ｂは、個々のプログラムによって実現されたり、或いは関連した複数のプログラムによって実行される機能として実現される。さらに１つのプログラムにおいて実行されるサービスコード関連処理とライセンス情報関連処理をそれぞれ示したものと把握することもできる。

登録管理部１１は、サービスコード処理部１１ａとしての機能により、提供者装置３から送信されてきた、ＡＰＩを使用するサービスアプリケーションを用いたサービスについてのＡＰＩ使用登録要求に対し、サービスコードを生成する処理を行う。また、そのサービスについて、サービス識別情報、及び使用ＡＰＩ情報をサービスコードと対応させて登録データベース３０に登録する処理を行う。
なおサービス識別情報とは、ＡＰＩを使用するサービスアプリケーション（即ち該サービスアプリケーションを用いたサービス）を特定する情報である。例えばサービスアプリケーションの製品識別コードや製品名などである。
また使用ＡＰＩ情報は、サービスアプリケーションが使用するＡＰＩを特定する情報である。例えば後述のＡＰＩサーバ２０が管理するＡＰＩ２４の識別コードやＡＰＩ名などである。

また登録管理部１１は、ライセンス処理部１１ｂとしての機能により、提供者装置３から送信されてきた、サービスについての利用者特定情報に対応して未承認状態のライセンス情報を生成する処理を行う。またライセンス情報をサービスコードと対応させて登録データベース３０に登録する処理を行う。
なお利用者特定情報とは、サービスアプリケーションによるサービスを享受するアプリケーション利用者を特定する情報である。例えばアプリケーション利用者のＩＤ、管理コード、利用者装置４の識別情報、或いはアプリケーション利用者がＥＣ管理システム１の管理の下で開設する店舗（店舗としてのウェブサイト）のＵＲＬ（Uniform Resource Locator）などが考えられる。

さらに登録管理部１１は、ライセンス処理部１１ｂとしての機能により、ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者にライセンス発行通知を行う。そして利用者装置４からの指示によるライセンス承認情報を受け付けて、これをライセンス情報に対応させて登録データベース３０に登録する処理を行う。

登録管理部１１は、登録処理を行うために登録データベース３０にアクセス可能とされている。
また登録管理部１１は、ネットワーク通信により提供者装置３や利用者装置４に対して通信可能に構成される。
さらに登録管理部１１は、提供者装置３からの登録のための情報入力や情報提示のため、提供者ウェブサイト１２（以下「提供者ＷＥＢ」と表記）を提供しており、サービスコード処理部１１ａ及びライセンス処理部１１ｂの機能としての提供者装置３との情報受け渡しを提供者ＷＥＢ１２を介して行うようにしている。
また登録管理部１１は、利用者装置４からの登録のための情報入力や情報提示のため、利用者ウェブサイト１３（以下「利用者ＷＥＢ」と表記）を提供しており、ライセンス処理部１１ｂの機能としての利用者装置４との情報受け渡しを利用者ＷＥＢ１２を介して行うようにしている。

ここで“サービスコード”と“ライセンス情報”は、それぞれ実使用上は、識別コード、パスワード、シークレットコード、キーデータ、鍵情報、登録コード、認証コード、ＩＤコード、ログインコード、ライセンスコードなど、各種の名称で用いられることが想定される。

本実施の形態でいうサービスコードとは、提供者装置３から送信されてきた、ＡＰＩを使用するサービスアプリケーションを用いたサービスについてのＡＰＩ利用要求に対し、登録サーバ１０としての情報処理装置が生成し発行するコード情報である。
このサービスコードは、登録される個々のサービスに対応してユニークなコードデータとして生成され、少なくともサービス識別情報及び使用ＡＰＩ情報と対応づけられる。
従ってサービスコードは、サービスアプリケーションにより実行されるサービスがＡＰＩ使用サービスとして正規に登録されたことを示す機能を持つ。またサービスコードは、サービスアプリケーションによるサービス実行時の認証に用いられるパスワードとしての機能も持つ。
このような機能や性質を含有するコードデータは、その名称の如何を問わず、本実施の形態の“サービスコード”に相当する。

またライセンス情報とは、サービスコードで特定されるサービスについての、アプリケーション提供者が指定した利用者特定情報（つまりアプリケーション利用者）に対応して未承認状態で生成されるコードデータである。しかも、アプリケーション利用者に対応して生成されたライセンス情報は、アプリケーション利用者の意思に基づいて利用者装置４からの指示によるライセンス承認を受け付けるという性質を持つ。ライセンスの承認／非承認（又は未承認）の情報が、ライセンス承認情報としてライセンス情報に対応づけられる。
サービス実行時の認証においては、ライセンス情報は、そのサービスで使用するＡＰＩによってアクセスされる情報へのアクセス権限を確認する意味がある。従ってアプリケーション利用者が当該サービスにおいて、ＡＰＩによる情報アクセスの権限をサービスアプリケーションに与えたことを示すコードデータとしての機能も持つ。
このような機能や性質を含有するコードデータは、その名称の如何を問わず、本実施の形態の“ライセンス情報”に相当する。

登録サーバ１０の機能により登録データベース３０に登録される情報は図４のような関係を有する。
なお図４は、サービスコードから見て関連づけられる各種情報を、そのデータベース形式やリンク形式、或いはデータ構造等を考慮せずに示したものである。図示する各情報は、互いに直接関連づけられてもよいし、他の情報を介して間接的に関連づけられてもよい。
また図示する各情報は、１つのデータベースに集約して登録されてもよいし、複数のデータベースに離散されて登録されてもよい。また１つの情報内に他の情報が含有されてもよい。例えばサービス識別情報としてのコードデータにアプリケーション提供者の情報が含まれるなどである。
どのような形式であれ、本実施の形態の登録情報としては、図４の各情報が、関連づけられた状態で参照できるものであればよい。

サービスコードは、サービス識別情報、アプリケーション提供者の情報と関連づけられている。
サービス識別情報とは、上述のようにサービス自体を示すコードで、例えばサービスアプリケーションとしてのタイトルに応じて１つのサービス識別情報が与えられる。具体的にはサービスアプリケーションとしての製品名、製品ＩＤなどが含まれる情報が考えられるが、さらに製品内容として、どのような種類のサービスを実現するアプリケーションプログラムであるかを示す内容情報や、リリース日時情報、開発者情報などが含まれていてもよい。
また例えばサービスアプリケーションがバージョンアップされる場合などに、バージョン毎に異なるサービス識別情報が付与されるようにしてもよいが、あくまで同じタイトルのソフトウエアとして、同一のサービス識別情報が付与されてもよい。但し、バージョンアップ等により、少なくとも使用ＡＰＩ情報が異なる場合には、異なるサービス識別情報を付与することが適切となる。
アプリケーション提供者の情報は、アプリケーション提供者としての個人や団体を示す情報である。

またサービスコードには、１又は複数の使用ＡＰＩ情報が関連づけられる。
使用ＡＰＩ情報とは、当該サービスにおいて使用されるＡＰＩを示す情報である。図ではＡＰＩ＃１、ＡＰＩ＃２として示す２つのＡＰＩがサービスコードに関連づけられている。この使用ＡＰＩ情報は、登録時にアプリケーション提供者が指定する。

またサービスコードには、１又は複数の利用者特定情報が関連づけられる。利用者特定情報は、個々のアプリケーション利用者を示す情報である。登録処理の際に、アプリケーション提供者が１又は複数のアプリケーション利用者を指定することで、そのアプリケーション利用者を示す利用者特定情報（ＭＣ−Ａ、ＭＣ−Ｂ）がサービスコードに関連づけられる。
さらに各利用者特定情報に対応してライセンス情報が登録される。例えばライセンス情報ＬＣ＃Ａは利用者特定情報ＭＣ−Ａに対応する。またライセンス情報ＬＣ＃Ｂは利用者特定情報ＭＣ−Ｂに対応する。個々のライセンス情報（ライセンスキーＬＣ＃Ａ、ＬＣ＃Ｂ）は、それぞれ異なるユニークなコード値として発行されて、各アプリケーション利用者に対応されるものとなる。
なお説明上、個々の利用者特定情報に対して発行されるライセンス情報を「ライセンスキー」と呼ぶこととする。
また個々のライセンス情報（ライセンスキーＬＣ＃Ａ、ＬＣ＃Ｂ）にはライセンス承認情報が付随される。これは、アプリケーション利用者がライセンス内容を承認したか否かを示す情報である。
ライセンス情報は、当初はライセンス承認情報＝“未承認”の状態で発行される。そしてアプリケーション利用者が承認することで、ライセンス承認情報が“承認”に更新される。例えばライセンスキーＬＣ＃Ａについては、利用者特定情報ＭＣ−Ａで示されるアプリケーション利用者が承認を与えることで、ライセンス承認情報が“承認”となる。またアプリケーション利用者が承認を拒否した場合、ライセンス承認情報は“非承認”に更新される。

以上の図４のようにサービスコードと各種情報が関連づけられる。図３における登録データベース３０とは、このような一群の情報が対応づけられる状態で参照／更新可能な１又は複数のデータベースを概念的に示しているものである。
各登録情報は必ずしも１つのデータベース形態でまとめて保存される必要があるわけではなく、分散されて格納されてもよい。また各登録情報の全部又は一部は、ＥＣ管理システム１の外部に保存されるものであってもよい。

図３に示すように、ＥＣ管理システム１にはＡＰＩサーバ２０が設けられている。ＡＰＩサーバ２０では、各種のＡＰＩ２４（ＡＰＩ＃１、ＡＰＩ＃２，ＡＰＩ＃３・・・）を使用可能に提供している。
各ＡＰＩ２４は、ＥＣ管理システム１の内部で開発されたものであってもよいし、外部デベロッパーにより開発されたものでもよい。そして、各ＡＰＩ２４自体は、ＡＰＩサーバ２０内に用意されていてもよいし、外部の情報処理装置に用意され、ＡＰＩサーバ２０が使用を管理できるものであってもよい。
ＡＰＩ２４は、例えばＡＰＩサーバ２０が管理する各種情報へのアクセスのためのＡＰＩである。つまりサービスアプリケーションは、ＡＰＩ２４を使用することで特定の情報にアクセスでき、情報の参照や更新を行うことができる。

ここでいうＡＰＩ２４がアクセスすることができる各種情報とは、例えばアプリケーション利用者である各店舗毎の在庫情報、商品価格情報、売上情報、顧客情報であったり、電子商取引の管理運営を行うＥＣ管理システム１側が各店舗向けに作成した統計情報、販売履歴情報、管理情報、課金情報などである。
これらの情報は、例えばアプリケーション利用者毎の営業上の情報であって公開を制限したい公開制限情報である。例えば店舗Ａのスタッフが、上記のような自己の情報を店舗Ｂなどの他者に閲覧・更新等がなされることを想定していない、もしくは積極的に秘密にしたいと考える情報である。店舗Ｂも同様で、店舗Ｂのスタッフにとっては自己の営業上の情報を店舗Ａなどの他者に閲覧されることは想定していない。

サービスアプリケーションがＡＰＩ２４を使用するということは、そのサービスアプリケーションを実行することによって公開制限情報の閲覧や更新等が行われることを意味する。
例えば或る店舗Ａ（アプリケーション利用者）が、アプリケーション提供者から在庫管理用のサービスアプリケーションを購入して導入し、在庫管理を行うとする。当該サービスアプリケーションは、ＡＰＩ２４を使用して店舗Ａの在庫情報をアクセスする。従って、このサービスアプリケーションが勝手に使用されたり、流出、盗難されたり、なりすまし利用されることは防止されなければならない。他者がそのサービスアプリケーションを実行することによって店舗Ａの公開制限情報の閲覧や更新等が可能になるためである。
他の店舗Ｂにとっても同様であり、或るサービスアプリケーションを導入する場合、そのサービスアプリケーションによってＡＰＩ２４を介して店舗Ｂの営業上の情報がアクセスされるため、そのサービスの適正利用が確保されることが必要となる。
さらには不正使用が生じたとしても、被害を最小限に留めることができることが望ましい。
このためサービスアプリケーションの実行には、店舗Ａの意思による承認や制限を加えることが好適となる。後述するが、本実施の形態ではこのような点を考慮してライセンス情報についてのアプリケーション利用者による承認が行われるようにしている。

なお図３等では、説明上の便宜として、ＡＰＩ２４がアクセスするこのような情報（一例として各店舗の営業上の情報）を保存する記憶部位を、店舗情報データベース３１として概念的に示している。各情報が必ずしもデータベース形態でまとめて保存される必要があるわけではない。また各情報は、ＥＣ管理システム１の外部に保存されるものであってもよい。

ＡＰＩサーバ２０には、認証部２１が設けられる。
認証部２１は、認証処理部２１ａ及び登録情報取得部２１ｂとしての機能を備える。
なお、認証処理部２１ａは認証処理を行う機能、登録情報取得部２１ｂは認証に用いる登録情報を登録データベース３０にアクセスして取得する機能を示すものである。実際には認証処理部２１ａと登録情報取得部２１ｂは、個々のプログラムによって実現されたり、或いは関連した複数のプログラムによって実行される機能として実現される。さらに１つのプログラムにおいて実行される認証処理と登録情報取得処理をそれぞれ示したものと把握することもできる。

認証部２１は、例えば利用者装置４においてサービスアプリケーションが実行され、ＡＰＩサーバ２０に対してＡＰＩ使用が要求された際に、そのＡＰＩ使用要求に対する認証を行う。
このため認証部２１は、認証処理部２１ａの機能により、ＡＰＩ使用要求についてのサービスコードとライセンス情報（ライセンスキー）を取得する。後述するが、サービス実行時にはＡＰＩ使用要求に伴ってサービスコードとライセンス情報（アプリケーション利用者が承認したライセンスキー）が送信されてくる。認証部２１はこの送信されてくるサービスコードとライセンスキーを取得する。
また認証部２１は、登録情報取得部２１ｂとしての機能により、登録データベース３０にアクセスし、認証に必要な情報を取得する。具体的にはＡＰＩ使用要求におけるサービスコードとライセンス情報を用いて、図４に示した登録情報を取得する。例えば当該認証対象のサービスについてのサービスコードに対応するサービス識別情報、使用ＡＰＩ情報、アプリケーション提供者の情報や、ライセンス情報（今回用いられたライセンスキー）に対応するライセンス承認情報等を取得する。
そして認証部２１は、認証処理部２１ａの機能により、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の照合を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する処理を行う。

ＡＰＩサーバ２０には実績管理部２２が設けられる。
実績管理部２２は、認証部２１での認証処理によりＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する処理を行う。
サービスコードによってアプリケーション提供者が特定される。またライセンス情報（今回用いられたライセンスキー）には利用者特定情報が対応していることで、アプリケーション利用者を認識できる。従って、ＡＰＩ使用実績について、アプリケーション提供者とアプリケーション利用者のそれぞれについて実績情報を生成・更新することが可能となる。
実績情報とは、例えばＡＰＩ使用情報、ＡＰＩ使用に対する課金情報などである。
ＡＰＩ使用情報とは、サービスアプリケーションによるＡＰＩ使用要求回数や使用要求日時、使用履歴などが把握可能な情報でもよいし、実際にＡＰＩを使用したアクセスの回数（読出回数／更新回数）、日時、履歴などが把握可能な情報でもよい。またＡＰＩ使用要求に対する認証結果の履歴情報なども考えられる。
課金情報としては、ＡＰＩ使用要求に応じて課金される課金情報、ＡＰＩによる情報アクセスに応じて課金される課金情報、或いは実績回数の段階に応じて設定される課金情報など、各種の課金情報が想定される。

説明上、各アプリケーション提供者や各アプリケーション利用者の実績情報を保存する部位を実績データベース３２として概念的に示している。各種の実績情報が必ずしもデータベース形態でまとめて保存される必要があるわけではない。また実績情報は、ＥＣ管理システム１の外部に保存されるものであってもよい。

なお認証部２１、実績管理部２２としての機能部位を備えた情報処理装置は、ＡＰＩサーバ２０としての情報処理装置と一体でもよいし、ＡＰＩサーバ２０としての情報処理装置とは別体の情報処理装置で構成されてもよい。
また認証部２１を備えた情報処理装置と実績管理部２２を備えた情報処理装置が別体とされてもよい。
さらに登録サーバ１０としての機能部位を備えた情報処理装置と、ＡＰＩサーバ２０としての情報処理装置は、一体でもよいし別体の情報処理装置で構成されてもよい。

＜３．登録時の処理＞
上述のように図１に示したネットワークシステムでは、アプリケーション提供者が、ＡＰＩサーバ２０によって用意されたＡＰＩを使用するサービスアプリケーションをアプリケーション利用者に提供し、アプリケーション利用者が、提供されたアプリケーションプログラムの実行によるサービスを享受する。
本実施の形態では、このサービス実行の前提として、まずサービス（サービスアプリケーション）がＥＣ管理システム１において正規に登録されることを求める。具体的には或るサービスについてサービスコードの発行及び登録、ライセンス情報の発行及び登録、さらにライセンス承認情報の登録が行われる。以下、この登録処理について詳述する。

図５は登録処理のための関連部位と情報のやりとりを模式的に示したものである。一連の登録処理には、アプリケーション提供者（提供者装置３）、アプリケーション利用者（利用者装置４）、登録サーバ１０が関わって登録データベース３０への登録情報の書込・更新が実行される。

大まかには次の（Ｒ１）〜（Ｒ７）の手順で登録処理が行われる。
（Ｒ１）アプリケーション提供者は、提供者装置３から、提供者ＷＥＢ１２を利用して登録サーバ１０に対し、或るサービス（サービスアプリケーション）についてのＡＰＩ使用登録要求（ＡＰＩ使用を行うサービスの登録要求）を行う。
（Ｒ２）登録サーバ１０はサービスコードを生成し、提供者装置３に対して発行するとともに、登録データベース３０にサービスコードと対応させてサービスに関する情報を登録する。
（Ｒ３）アプリケーション提供者は、提供者装置３から、提供者ＷＥＢ１２を利用して登録サーバ１０に対し、ライセンス発行要求として利用者特定情報を通知する。なお、この場合に通知する利用者特定情報とは、一例としては、アプリケーション提供者との間のサービス利用契約などで当該サービスの利用を予定するアプリケーション利用者、或いはアプリケーション提供者がサービス提供を想定しているアプリケーション利用者などを示す情報が考えられる。もちろん、アプリケーション利用者がアプリケーション提供者にライセンス発行を要請することに応じて、そのアプリケーション利用者を示す利用者特定情報をアプリケーション提供者が登録サーバ１０に通知してもよい。
（Ｒ４）登録サーバ１０は利用者特定情報に対応させてライセンス情報（ライセンスキー）を発行し、これらをサービスコードに関連づけて登録データベース３０に登録する。
（Ｒ５）登録サーバ１０は、ライセンス情報が発行されたアプリケーション利用者（利用者装置４）に対して、ライセンス発行通知を行う。
（Ｒ６）アプリケーション利用者は、利用者装置４から利用者ＷＥＢ１３を利用して、ライセンス内容を確認し、承認／非承認を選択したライセンス承認情報を登録サーバ１０に送信する。
（Ｒ７）登録サーバ１０は、アプリケーション利用者の意思に基づくライセンス承認情報を受け取り、承認の場合は、ライセンス情報としてのユニークなコードであるライセンスキーを利用者装置４に送信する。また承認／非承認に関わらず、ライセンス承認情報をライセンス情報に対応させて登録データベース３０に登録する。

登録処理は以上のようになるが、登録されたサービスは、最終的にライセンスキーの“承認”が得られた場合に、その承認をしたアプリケーション利用者によって実行可能となる。

以下、図６〜図１４を参照して登録処理としての各部の具体的な処理例を説明する。
図６は主に提供者装置３と登録サーバ１０の処理を示している。
なお、以下、図６〜図８で示す登録サーバ１０の処理とは、登録管理部１０が図３で説明したサービスコード処理部１１ａ、ライセンス処理部１１ｂの機能を用い、かつ提供者ＷＥＢ１２、利用者ＷＥＢ１３を用いて実行する処理である。

或るサービスを実現するサービスアプリケーションの提供（例えば譲渡や貸与）を行うアプリケーション提供者は、まずそのサービスの登録のために、提供者装置３を用いて登録サーバ１０が用意する提供者ＷＥＢ１２にアクセスする。
提供者装置３はステップＳ１として、アプリケーション提供者に付与されているログインパスワード、ユーザＩＤ等を用いて提供者ＷＥＢ１２にログインする。

ログインにより登録サーバ１０は、ステップＳ１００でアプリケーション提供者を認識する。そして登録サーバ１０は、例えば提供者装置３側からのウェブ上の要求操作に応じて、ステップＳ１０１で、提供者ＷＥＢ１２においてＡＰＩ使用登録要求のための画面（ウェブページ）を提供する。
図９に提供者ＷＥＢ１２上で提供するＡＰＩ使用登録画面７０の例を示す。このＡＰＩ使用登録画面７０では、アプリケーション提供者の入力や操作のために、製品情報入力部７１、使用ＡＰＩ入力部７２、登録操作部７３、戻り操作部７４、ログアウト操作部７５、ＡＰＩ選択操作部７６等を用意している。
製品情報入力部７１では、提供するサービスアプリケーションとしての製品ＩＤ、製品名、概要（サービス内容の概要）、解説ページＵＲＬ、製品ＵＲＬ等を入力可能とする。
使用ＡＰＩ入力部７２では、当該サービスアプリケーションが使用するＡＰＩを入力可能とする。例えばＡＰＩ選択操作部７６を操作してＡＰＩ一覧を表示させ、その一覧からＡＰＩを選択可能とする。選択に応じて使用ＡＰＩ入力部７２にＡＰＩ名や処理内容がエントリされる。

アプリケーション提供者は提供者装置３から、このようなＡＰＩ使用登録画面７０に対して操作を行ってＡＰＩ使用登録要求を行う。
具体的には、アプリケーション提供者は提供者装置３を用いて、ＡＰＩ使用登録画面７０を閲覧し、必要事項を入力する。そして例えば図９に示すように製品情報入力部７１、使用ＡＰＩ入力部７２の入力を行った状態で、登録操作部７３を操作（クリック）する。これによりステップＳ２として、入力内容に基づくＡＰＩ使用登録要求が提供者装置３から登録サーバ１０に送信される。

ＡＰＩ使用登録要求があったら、登録サーバ１０はステップＳ１０２で、ＡＰＩ使用登録要求に係る情報を取得する。即ちＡＰＩ使用登録画面７０の製品情報入力部７１に入力された情報の全部又は一部を、サービスアプリケーションの識別情報（サービス識別情報）として取得する。一部の場合は、例えば製品ＩＤ、製品名、概要をサービス識別情報に含める。
また登録サーバ１０はＡＰＩ使用登録画面７０の使用ＡＰＩ入力部７２に入力された各ＡＰＩの情報を、使用ＡＰＩ情報として取得する。
さらに登録サーバ１０は、１つのＡＰＩ使用登録要求に対してユニークなコードであるサービスコードを生成する。

続いて登録サーバ１０はステップＳ１０３で、登録データベース３０に対する登録を行う。この時点では、生成したサービスコードに対応させて、ステップＳ１０２で取得したサービス識別情報と使用ＡＰＩ情報、及びステップＳ１００で認識したアプリケーション提供者の情報を関連づけて登録する。
ステップＳ１０４で登録サーバ１０は、サービスコードを提供者装置３に通知する。例えば提供者ＷＥＢ１２において、例えば図１０のような登録完了画面８０を提示する。
登録完了画面８０では、サービスコード提示部８１、サービス内容提示部８２、使用ＡＰＩ提示部８３、戻り操作部８４、ログアウト操作部８５等を表示する。
サービスコード提示部８１には、例えば数１０桁程度のユニークコードであるサービスコードが表示される。
サービス内容提示部８２には、当該サービスコードに対応して登録されたサービスアプリケーションの内容（サービス識別情報の内容）が表示される。
使用ＡＰＩ提示部８３には当該サービスアプリケーションが使用するものとして登録されたＡＰＩが表示される。

アプリケーション提供者は、このような登録完了画面８０を閲覧することで、サービスについて適正な登録が完了したことを確認できる。
そしてステップＳ３で提供者装置３は、提示されたサービスコードを取得する。
ここまでで登録サーバ１０とのやりとりは完了したため。提供者装置３はステップＳ４で提供者ＷＥＢ１２からログアウトする。
但し、ログアウトせずに、図７で述べるライセンス情報についての処理に進むようにしてもよい。

なお、図６ではステップＳ５，Ｓ６としての提供者装置３の処理を示しているが、このステップＳ５，Ｓ６は必ずしもこの登録処理の過程で行われなくてもよい。
ステップＳ５では、提供者装置３はサービスアプリケーションにサービスコードを付加する。即ち提供する製品としてのサービスアプリケーションにサービスコードを埋め込み、サービス利用時にサービスコードが用いられるようにする。
ステップＳ６では、提供者装置３から利用者装置４にサービスアプリケーションを提供する。例えばサービスコードの埋め込みを完了したサービスアプリケーションを利用者装置４にダウンロードする。或いはアプリケーション提供者がＡＳＰとしての業者であればサービスアプリケーションが使用可能なことをアプリケーション利用者に通知すればよい。
このステップＳ５、Ｓ６は、あくまでアプリケーション提供者の業務の一環で行われるもので、少なくともサービスコードの発行を受けた後において任意に行われればよく、ＥＣ管理システム１が関与するものではない。

続いてアプリケーション提供者は、ライセンス情報の発行について登録サーバ１０に求める。
図７のステップＳ１０として、提供者装置３は、アプリケーション提供者に付与されているログインパスワード、ユーザＩＤ等を用いて提供者ＷＥＢ１２にログインする。
ログインにより登録サーバ１０は、ステップＳ１１０でアプリケーション提供者を認識する。
そして登録サーバ１０は例えば提供者装置３側からのウェブ上の要求操作に応じて、ステップＳ１１１で、提供者ＷＥＢ１２においてライセンス発行のための画面（ウェブページ）を提供する。
図１１に提供者ＷＥＢ１２上で提供するライセンス発行画面９０の例を示す。このライセンス発行画面９０では、製品一覧表示部９１、店舗指定部９２、追加操作部９３、ライセンス発行対象リスト９４、削除操作部９５、ライセンス発行操作部９６、戻り操作部９７、ログアウト操作部９８等が表示される。

登録サーバ１０は、製品一覧表示部９１に、今回ログインしたアプリケーション提供者の製品として登録しているサービスアプリケーションを一覧表示する。
店舗指定部９２では、アプリケーション利用者としてのショップを指定する入力を可能とする。例えばＥＣ管理システム１が管理しているショップついて付与しているＩＤ（以下「ショップＩＤ」という）や、或いはショップのメールアドレス、その他ショップやショップの連絡先を特定できる情報により指定可能とする。
ライセンス発行対象リスト９４には、例えば製品ＩＤや製品名で示される或るサービスアプリケーションについて、ライセンス発行対象とするアプリケーション提供者（店舗）をリストアップすることを可能とする。

アプリケーション提供者は提供者装置３から、このようなライセンス発行画面９０に対して操作を行ってライセンス発行要求を行う。
具体的には、アプリケーション提供者は提供者装置３を用いてライセンス発行画面９０を閲覧し、必要事項を入力する。
まず製品一覧表示部９１で自分の製品の一覧を確認し、今回ライセンス発行要求を行う製品を選択する。
また店舗指定部９２に対して１又は複数の店舗（アプリケーション利用者）を特定する情報を入力する。そのうえで追加操作部９３を操作することで、指定した製品（サービスアプリケーション）について、店舗指定部９２に入力したアプリケーション利用者が、ライセンス発行対象としてライセンス発行対象リスト９４に追加される。
一旦ライセンス発行対象リスト９４に載せた後でも、削除操作部９５を用いてリストから除外することも可能である。
アプリケーション提供者は、例えばサービス提供の契約済みの店舗や、サービス利用を予定する店舗などを、店舗指定部９２で指定してライセンス発行対象リスト９４にエントリしていけばよい。

アプリケーション提供者は、ライセンス発行対象リスト９４に必要なライセンス発行対象をエントリさせた状態で、ライセンス発行操作部９６を操作する。これにより、ステップＳ１１として、入力内容に基づくライセンス発行要求が提供者装置３から登録サーバ１０に送信される。

ライセンス発行要求があったら、登録サーバ１０はステップＳ１１２で、ライセンス発行要求に係る情報を取得する。即ちライセンス発行画面９０のライセンス発行対象リスト９４にエントリされた情報に基づいて、サービスアプリケーションに対してライセンス発行を求められた利用者を特定する利用者特定情報を取得する。例えばショップＩＤを利用者特定情報として取り込む。
そして登録サーバ１０は、１または複数の利用者特定情報のそれぞれについてのライセンス情報（ライセンスキー）を発行する。

続いて登録サーバ１０はステップＳ１１３で、登録データベース３０に対する登録を行う。この場合は、今回の要求に係るサービスアプリケーションについて、既に登録されているサービスコードに対応させて、１または複数の利用者特定情報とライセンス情報のセットを登録する。但し、発行したライセンス情報については、この時点では、“未承認”を示すライセンス承認情報を付加する。
ステップＳ１１４で登録サーバ１０は、提供者装置３にライセンス発行完了を通知する。例えば提供者ＷＥＢ１２において、ライセンス発行完了画面を提示する。
アプリケーション提供者は、ライセンス発行完了画面を閲覧することで、指定したアプリケーション利用者のそれぞれについてのライセンス発行が完了したことを確認できる。
ここまでで登録サーバ１０とのやりとりは完了したため。提供者装置３はステップＳ１２で提供者ＷＥＢ１２からログアウトする。

ここまでの処理で、アプリケーション提供者が提供するサービスについての登録情報として、サービス識別情報とアプリケーション提供者がサービスコードに対応づけられ、また当該サービスについて、利用が想定されるアプリケーション利用者の利用者特定情報と、そのアプリケーション利用者について発行されたライセンス情報が、対応づけられた状態である。但しこの時点では、ライセンス情報について“未承認”とされたライセンス承認情報が付加されている。
この後、登録サーバ１０は、利用者装置４との間で、ライセンス承認に関する処理を行うことになる。

図８は、ライセンス承認に関する利用者装置４と登録サーバ１０の処理例を示している。
登録サーバ１０は、上述のようにライセンス発行を行った場合、ステップＳ１２０として、発行したライセンス情報に対応する利用者特定情報に基づいて、利用者装置４に対してライセンス発行の事実を通知する。
例えばＥＣ管理システム１は、ショップＩＤと電子メールアドレスを紐付けして管理しているとし、また利用者特定情報としてショップＩＤが用いられているとする。この場合、登録サーバ１０は、ショップＩＤからアプリケーション利用者の電子メールアドレスを取得し、その電子メールアドレス宛にライセンス発行通知を行う。アプリケーション利用者は、この通知により、新規に自己に関連するライセンス発行があったことを認識できる。

アプリケーション利用者は、利用者装置４を用いて利用者ＷＥＢ１３にアクセスして、ライセンスに関する確認や操作を行うことができる。
利用者装置４はステップＳ３００として、アプリケーション利用者に付与されているログインパスワード、ユーザＩＤ等を用いて利用者ＷＥＢ１３にログインする。

ログインに応じて登録サーバ１０はステップＳ１２１で、アプリケーション利用者を認識し、そのアプリケーション利用者についてのライセンスリスト画面を利用者ＷＥＢ１３上で提供する。
図１２にライセンスリスト画面１２０の例を示す。ライセンスリスト画面１２０では、当該アプリケーション利用者について発行されているライセンスの一覧を示すライセンス一覧表示部１２１、削除操作部１２３、ログアウト操作部１２４等が表示される。
ライセンス一覧表示部１２１では、そのアプリケーション利用者が対象とされている発行済みのライセンス情報の内容が示される。例えばアプリケーション提供者の会社名、サービス識別情報にくまれる製品名、ライセンス発行日、承認／未承認の状態などである。
アプリケーション利用者は、このライセンス一覧表示部１２１内で、承認に関する操作を行うライセンス情報を選択する。
なお、削除操作部１２３を用いて、ライセンス一覧から特定のライセンスを削除することもできる。

アプリケーション利用者のライセンス選択操作により、ステップＳ３０１として利用者装置４から登録サーバ１０にライセンス選択の情報が送信される。これに応じて登録サーバ１０はステップＳ１２２で、図１３のようなライセンス承認操作画面１３０を利用者ＷＥＢ１３上で提示する。
ライセンス承認操作画面１３０では、製品情報表示部１３１、ＡＰＩリスト表示部１３２、承認操作部１３３、承認拒否操作部１３４、戻り操作部１３５、ログアウト操作部１３６、注意喚起メッセージ１３７等が表示される。

製品情報表示部１３１には、当該ライセンス情報に係るサービスの内容が表示される。例えばアプリケーション提供者としての会社名、サービスアプリケーションの製品名、サービス内容の概要、ライセンス発行日などである。アプリケーション利用者は、これにより、当該ライセンスがどのようなサービスに関するものかを理解することができる。

注意喚起メッセージ１３７により、このサービスがＡＰＩを使用することが提示され、ＡＰＩリスト表示部１３２には、実際に使用されるＡＰＩが示される。この注意喚起メッセージ１３７とＡＰＩリスト表示部１３２の情報は、アプリケーション利用者に、サービス実行に伴うリスクを示すリスク情報としての意味を持つ。
ＡＰＩリスト表示部１３２では、当該サービスで使用するＡＰＩ名と、その内容が示される。内容によって、各ＡＰＩがどのような情報にアクセスして情報の取得や情報の更新を行うか等が示される。
アプリケーション利用者は、この表示によりサービス実行に伴う危険性、具体的には自己の店舗に関する情報の危険性を認識することができる。
なお、リスク情報としては、さらにＡＰＩによって読み出されたり更新される情報の種別、内容などについて、より具体的内容が示されるようにしてもよい。例えば各ＡＰＩによってアクセスされる価格情報、在庫情報、顧客名簿情報などの具体的な情報が提示されてもよい。またＡＰＩ使用に伴う情報流出の具体例などが示されてもよい。

アプリケーション利用者は、ＡＰＩ使用による危険性を認識した上で、ライセンス情報について承認するか承認を拒否するかを選択することができる。
ライセンス承認の手法としては、一括承認、個別承認が考えられる。
一括承認とは、アプリケーション利用者が、提示されているＡＰＩのすべてが使用されることを前提として、ライセンスを承認することのみを登録サーバ１０が受け付ける手法である。
個別承認とは、アプリケーション利用者が、提示されているＡＰＩのうちで、一部のみの使用を認めるというライセンス承認を、登録サーバ１０が許容する手法である。

まず一括承認を採用する場合について説明する。
アプリケーション利用者は、ライセンス承認操作画面１３０を確認し、すべてのＡＰＩについて使用されることを納得した上でのみ、承認操作部１３３の操作を行うことができる。
例えば図示のように各ＡＰＩについてチェックボックスを用意し、すべてのＡＰＩについてチェックがなされた場合のみ、承認操作部１３３がアクティブになるようにする。
アプリケーション利用者は、ライセンス情報について承認する場合は、承認操作部１３３を操作する。一方、危険性を考慮して承認しない場合は、承認拒否操作部１３４を操作する。
これらの操作により、図８のステップＳ３０２として利用者装置４から登録サーバ１０に、ライセンス承認情報が通知される。

登録サーバ１０はステップＳ１２３で、“承認”又は“非承認（承認拒否）”を示すライセンス承認情報を取得する。そしてステップＳ１２４で、対象のライセンス情報に対応するライセンス承認情報として登録データベース３０に登録する。
この場合、一括承認であることで、当該ライセンス情報について承認した場合、当該サービスにおいて使用ＡＰＩ情報に登録されたすべてのＡＰＩ使用を、アプリケーション利用者が承認したものとなる。

個別承認を採用する場合は次のようになる。
アプリケーション利用者は、ライセンス承認操作画面１３０を確認し、各ＡＰＩについて使用されることを承認するか否かを選択する。そして例えば使用を納得した一部又は全部のＡＰＩについてチェックボックスにチェックしたうえで、承認操作部１３３を操作する。すべてのＡＰＩの使用を認めない場合は承認拒否操作部１３４を操作する。
これらの操作により、図８のステップＳ３０２として利用者装置４から登録サーバ１０に、ライセンス承認情報が通知される。

登録サーバ１０はステップＳ１２３で、ＡＰＩ毎に“承認”又は“非承認（承認拒否）”を示すライセンス承認情報を取得する。そしてステップＳ１２４で、対象のライセンス情報に対応するライセンス承認情報として登録データベース３０に登録する。
この場合、ライセンス情報に対応させて、使用ＡＰＩ情報に挙げられた各ＡＰＩについての承認／非承認が登録されることになる。
なお、一部のＡＰＩを“非承認”とすることは、そのサービスにおいて、そのＡＰＩを使用させないということになる。つまりサービスアプリケーションの機能の一部をアプリケーション利用者が制限できるということになる。

ステップＳ１２４でライセンス承認情報の登録を行ったら、登録サーバ１０は利用者装置４に対して承認結果通知を行う。
例えば一括承認で承認が行われた場合、或いは部分承認で一部又は全部のＡＰＩの承認が行われた場合は、登録サーバ１０は提供者ＷＥＢ１２において、例えば図１４のようなライセンス承認結果画面１４０を提示する。
ライセンス承認結果画面１４０では、例えばサービス表示部１４１、ライセンスキー表示部１４２、戻り操作部１４３、ログアウト操作部１４４等が表示される。
サービス表示部でサービスアプリケーションのアプリケーション提供者や製品名が表示され、それについての承認したライセンスキーがライセンスキー表示部１４２に表示される。

アプリケーション利用者は、このようなライセンス承認結果画面１４０を閲覧することで、サービスについてのライセンス承認が完了したことを確認できる。
そしてステップＳ３０３で利用者装置３は、提示されたライセンスキーを取得する。このライセンスキーは、後に実際にサービスアプリケーションを使用するものとして保存する。
ここまでで登録サーバ１０とのやりとりは完了したため。利用者装置４はステップＳ３０４で利用者ＷＥＢ１３からログアウトする。

なお、ライセンス承認拒否の場合は、登録サーバ１０は利用者ＷＥＢ１３上でライセンス拒否（非承認）の結果を提示する。
利用者装置４は一旦拒否した後でも、図１２のライセンス一覧表示部１２１で再度そのサービスを選択して、ライセンス承認を行うことができる。

以上の図６から図８の処理により登録されたサービスアプリケーションは、その後ＡＰＩを使用した処理が実行可能となる。この時点で、サービスアプリケーションに関して、図４に示した登録情報が形成されていることになる。

＜４．サービス実行時の処理例Ｉ＞
続いてサービス実行時の処理例を説明する。
なお処理例Ｉ、処理例II、処理例IIIは、アプリケーション利用者としては、図１の提供者装置３Ａを利用する者、つまりアプリケーションプログラムとしてのパッケージを、ダウンロードやメディアにより利用者装置４に提供する者を想定して説明する。そして後述の処理例IVは、図１の提供者装置３Ｂを利用するＡＳＰとしての業者の場合を想定する。

まず処理例Ｉを図１５〜図１８を参照して説明する。
図１５はサービス実行時の認証やＡＰＩ使用の処理についての関連部位と情報のやりとりを模式的に示したものである。
この場合、利用者装置４には提供者装置３Ａからサービスアプリケーションが提供されているものとしている。つまり利用者装置４においてサービスアプリケーションとしてのプログラムがインストールされ、起動可能な状態になっている。
アプリケーション利用者は、利用者装置４においてサービスアプリケーションを起動して、そのサービスアプリケーションによるサービス、例えば商品管理、在庫管理、顧客管理などのサービスの結果を享受する。この際にサービスアプリケーションはＡＰＩサーバ２０が用意するＡＰＩを使用して必要な情報アクセスを行う。

サービス実行時の処理は大まかには次の（Ｐ１）〜（Ｐ４）の手順で行われる。
（Ｐ１）起動されたサービスアプリケーションに基づいて、利用者装置４はＡＰＩサーバ２０に対してＡＰＩ使用要求（ＡＰＩを使用した情報アクセス実行の要求）を送信する。この場合にサービスコードとライセンスキーも送信する。
（Ｐ２）ＡＰＩサーバ２０は、認証部２１の機能により、ＡＰＩ使用要求に伴うサービスコードとライセンスキーに基づいて認証処理を行う。そして認証結果を利用者装置４に通知する。
（Ｐ３）認証ＯＫの場合、ＡＰＩサーバ２０は、実績管理部２２の機能により、サービスコードとライセンスキーに基づいてアプリケーション提供者とアプリケーション利用者について個別の実績管理処理を行う。
（Ｐ４）認証ＯＫの場合、ＡＰＩサーバ２０はＡＰＩ使用を許可する。つまりサービスアプリケーションによる処理過程で発生する要求に応じて、ＡＰＩ使用が実行される。

以下、サービス実行時の各部の具体的な処理例を説明する。
図１６は主に利用者装置４とＡＰＩサーバ２０の処理を示している。
なお、図１６〜図１８で示すＡＰＩサーバ２０の処理とは、認証部２１が図３で説明した認証処理部２１ａ、登録情報取得部２１ｂの機能を用いて実行する処理と、実績管理部２２の機能による処理と、ＡＰＩ２４による処理を含む。

アプリケーション利用者が自己の利用者装置４によりサービスアプリケーションを実行する場合、まず利用者装置４では図１６のステップＳ３２０として、サービスアプリケーションの起動処理が行われる。
なお、サービスアプリケーションの起動の際には、アプリケーション利用者にライセンスキーを入力することが求められる。実際には、利用者装置４内の所定箇所（サービスアプリケーションが参照可能な特定フォルダ等）にライセンスキーが記憶されており、起動時にサービスアプリケーションが、そのライセンスキーを取得できるようにすればよい。
またサービスアプリケーションは、アプリケーション提供者側で、サービスコードが埋め込まれた状態で、ネットワーク２を介したダウンロードや、記憶媒体による受け渡しにより、アプリケーション利用者に提供され、利用者装置４にインストールされている。サービスアプリケーションの起動時には、このサービスコードも取得する。

サービスアプリケーションが起動されることで、そのサービスアプリケーションによって規定される処理として、利用者装置４ではステップＳ３２１以降の処理が行われる。
ステップＳ３２１で利用者装置４はＡＰＩサーバ２０に対してＡＰＩ使用要求を送信する。
このＡＰＩ使用要求の際に、利用者装置４はサービスコードとライセンスキーも同時に送信する。
なお、ＡＰＩ使用要求には、要求を行ったサービスアプリケーションを示すサービス識別情報、及び使用要求の対象となるＡＰＩを指定する情報も含まれている。

ＡＰＩサーバ２０はＡＰＩ使用要求に応じてステップＳ４００で、認証部２１の機能により認証処理を行う。この認証処理を図１７に示す。図１７は、認証処理部２１ａ、登録情報取得部２１ｂとしての機能を有する認証部２１によって実行される処理である。
認証部２１は図１７のステップＳ４１０で、ＡＰＩ使用要求とともに利用者装置４から送信されてきたサービスコードとライセンスキーを取得する。
また認証部２１は、ＡＰＩ使用要求としての情報に含まれているサービス識別情報と使用要求対象のＡＰＩを示す情報も取得する。

続いて認証部２１はステップＳ４１１で、サービスコードとライセンスキーを用いて登録データベース３０にアクセスし、そのサービスコード及びライセンスキーに対応する登録情報を取得する。図４を用いて説明すると、サービスコードに対応する登録情報として、サービス識別情報、アプリケーション提供者の情報、及び使用ＡＰＩ情報を取得する。またライセンスキーに対応する登録情報として、そのライセンスキー自体に対応する利用者特定情報及びライセンス承認情報を取得する。例えばライセンスキーＬＣ＃Ａの場合、利用者特定情報ＭＣ−Ａ、及びライセンスキーＬＣ＃Ａについてのライセンス承認情報を取得する。

ステップＳ４１２で認証部２１は、システムエラーを確認する。例えばシステム上のハードウエアによる原因、通信系や伝送路の原因、その他の動作エラーなどで、登録情報の読み込みが適切にできなかった場合、システムエラー発生とする。その場合はステップＳ４１９に進んで認証不能と最終判定を行う。

システムエラーが発生しておらず、正常に登録情報アクセスができていた場合は実際の認証処理に移る。
まずステップＳ４１３で認証部２１はサービスコードについての認証を行う。例えば以下の確認を行う。
・正規に登録されたサービスコードであるか否かの確認
ＡＰＩ使用要求と共に送信されてきたサービスコードが、登録データベース３０に登録されたサービスコードであるか否かを確認する。
・登録情報存在の確認
サービスコードに基づいて、サービス識別情報、アプリケーション提供者の情報、及び使用ＡＰＩ情報が適切に登録されており、取得できたか否かを確認する。
例えば以上の確認がＯＫであれば、サービスコードは認証ＯＫ、いずれかが満たされなければサービスコードは認証ＮＧとする。

ステップＳ４１４で認証部２１は使用ＡＰＩについての認証を行う。例えば以下の確認を行う。
・使用ＡＰＩの一致確認
ＡＰＩ使用要求において使用要求対象とされたＡＰＩと、登録情報の使用ＡＰＩ情報で示されるＡＰＩが一致しているか否かを確認する。なお複数のＡＰＩの完全一致のみをＯＫとしてもよいが、ＡＰＩ使用要求において使用要求対象とされた１又は複数のＡＰＩのすべてが、登録情報の使用ＡＰＩ情報に示されていればＯＫとしてもよい。
・ＡＰＩ使用可能状態の確認
ＥＣ管理システム１上で、ＡＰＩが何らかの事情により使用不可とされていたり、或いはメンテナンス等で使用停止とされる場合がある。例えばＡＰＩサーバ２０は、提供する各ＡＰＩについて、そのような状況を管理している。そこでＡＰＩ使用要求において使用要求対象とされた１又は複数のＡＰＩが現在使用可能であるか否かを確認する。
例えば以上の確認がＯＫであれば、使用ＡＰＩについては認証ＯＫ、いずれかが満たされなければ使用ＡＰＩについて認証ＮＧとする。

ステップＳ４１５で認証部２１はサービス識別情報についての認証を行う。例えば以下の確認を行う。
・登録情報との一致確認
ＡＰＩ使用要求において示されたサービス識別情報と、サービスコードに基づいて読み出された登録情報のサービス識別情報が一致しているか否かを確認する。つまり今回ＡＰＩ使用要求を送信したサービスアプリケーションが、正規に登録されたサービスアプリケーションであるか否かを確認する。
例えば以上の確認がＯＫであれば、サービス識別情報は認証ＯＫ、満たされなければサービス識別情報について認証ＮＧとする。

ステップＳ４１６で認証部２１はライセンスキーについての認証を行う。例えば以下の確認を行う。
・ライセンスキーの正当性確認
ＡＰＩ使用要求において送信されてきたライセンスキーとサービスコードが、登録情報としても関連づけられているか否か、つまりライセンスキーが、そのサービスアプリケーションに対応して正当に登録されたものであるか否かを確認する。
・ライセンス承認確認
ＡＰＩ使用要求において送信されてきたライセンスキーに対応して登録データベース３０から読み出されたライセンス承認情報を確認する。
例えば以上の確認において、ライセンスキーの正当性がＯＫで、かつライセンス承認情報が“承認”を示す情報となっていればライセンスキーは認証ＯＫとする。一方正当性がＮＧであるか、又はライセンス承認情報が“未承認”もしくは“非承認”であったら、ライセンスキーは認証ＮＧとする。

ステップＳ４１３〜Ｓ４１６のすべてで認証ＯＫとなった場合には、認証部２１はステップＳ４１８に進んで最終的に認証ＯＫとする。
一方、ステップＳ４１３〜Ｓ４１６のいずれかで認証ＮＧとなった場合には、認証部２１はステップＳ４１７に進んで最終的に認証ＮＧとする。

このような認証によりサービスアプリケーションによるＡＰＩ使用に伴う情報の安全性を確保する。
サービスコード認証により、サービスアプリケーションがアプリケーション提供者によって正しく登録されたという正当性が確認され、使用ＡＰＩ情報の認証により使用するＡＰＩの範囲としての権限が確認される。またライセンス情報により、アプリケーション提供者との関係におけるアプリケーション利用者の正当性と、アプリケーション利用者の承諾の範囲としてのＡＰＩ使用が確認される。このため、アプリケーション提供者とアプリケーション利用者の２者の意思による合意範囲内で、サービスアプリケーションによる正当なＡＰＩ使用が確保される。
このため少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の確認を含む認証処理を行うことが好適である。

以上の認証処理は一例である。上掲したすべての事項の認証を必ず実行しなければならないわけではない。例えば登録情報としてサービスコードに対応してアプリケーション提供者の情報が得られたか否かの確認は行われなくてもよい。
但しステップＳ４１３〜Ｓ４１６のサービスコード、サービス識別情報、使用ＡＰＩ情報、及びライセンスキーの全てについて上記の確認ができた場合に最終認証ＯＫとすることは、サービス実行時の情報の安全性の面で好適である。
また、他の事項の認証を加えてもよい。例えばＡＰＩ使用要求の際に、アプリケーション提供者の情報も送信されるのであれば、アプリケーション提供者の情報について登録情報との一致を確認してもよい。
同様にＡＰＩ使用要求の際に、アプリケーション利用者を示す情報が送信されるのであれば、ライセンスキーに対応する利用者特定情報との一致を確認してもよい。

図１６のステップＳ４００では例えば以上の図１７のように認証処理が行われる。
認証結果が得られたらＡＰＩサーバ２０はステップＳ４０１で利用者装置４に対して認証結果通知を行う。即ち図１７のステップＳ４１６又はＳ４１７で得られる認証ＯＫ、認証ＮＧ、或いは認証不能を通知する。

認証ＮＧ又は認証不能となった場合、ＡＰＩサーバ２０は、図１６のステップＳ４０２からＳ４０５に進んで、ＡＰＩ使用禁止としてＡＰＩ使用要求に対する処理を終了する。
また利用者装置４では、認証ＮＧ又は認証不能の通知を受信した場合、ステップＳ３２２からＳ３２４に進んで、サービスアプリケーションはエラー終了することになる。

認証ＯＫとなった場合、ＡＰＩサーバ２０はステップＳ４０２からＳ４０３に進んで実績管理部２２の機能による実績管理処理を行う。この実績管理処理を図１８に示す。実績管理部２２は例えば認証部２１から認証ＯＫの結果が通知されることに応じて、サービスコード、ライセンスキーを用いて実績管理処理を行う。

図１９に実績データベース３２に記憶される実績情報の一例を示す。
アプリケーション提供者についての実績情報として、各アプリケーション提供者Ｖ１，Ｖ２・・・毎に、ＡＰＩ使用実績が記憶される。
例えばＡＰＩ使用の発生毎に、日時、使用ＡＰＩを示す情報、アプリケーションプログラムを示す情報、アプリケーション利用者を示す情報、課金データが記憶されていく。
アプリケーション利用者についての実績情報も、同様に、各アプリケーション利用者Ｍ１，Ｍ２・・・毎に、ＡＰＩ使用実績が記憶される。
例えばＡＰＩ使用の発生毎に、日時、使用ＡＰＩ、アプリケーションプログラムを示す情報、アプリケーション提供者を示す、課金データが記憶されていく。
使用ＡＰＩを示す情報としては、サービスコードから導かれる使用ＡＰＩ情報を用いることができる。
アプリケーションプログラムを示す情報は、サービスコードから導かれるサービス識別情報を用いることができる。
アプリケーション利用者を示す情報は、ライセンスキーから導かれる利用者特定情報を用いることができる。
アプリケーション提供者を示す情報は、サービスコードから導かれるアプリケーション提供者の情報を用いることができる。
課金データは、使用するＡＰＩに応じた単価や、累積金額などである。
実績情報はこの図１９のような例に限らず、記憶すべき項目も他に多様に想定されるが、いずれにしても、ＡＰＩの使用実績や、それに応じた課金金額が把握できるものであればよい。

実績管理部２２は、例えばこのようなアプリケーション提供者の実績情報と、アプリケーション利用者の実績情報について、更新／追加等を行っていく。
図１８のステップＳ４３１で実績管理部２２は、サービスコードから、アプリケーション提供者Ｖ（ｘ）、サービス識別情報、使用ＡＰＩ情報を判定する。これらは、認証時に読み出された登録情報として取得してもよいし、実績管理部２２が登録データベース３０にアクセスして取得してもよい。
ステップＳ４３２で実績管理部２２は、アプリケーション提供者のＡＰＩ使用情報の更新を行う。例えばサービスコードから導かれたアプリケーション提供者Ｖ（ｘ）についての図１９のような実績情報に、今回のＡＰＩ使用要求に関する日時、使用ＡＰＩ、サービス識別情報、利用者特定情報を追加する。
またステップＳ４３３で実績管理部２２は、今回のＡＰＩ使用要求に関するアプリケーション提供者に対しての課金データを生成する。そして課金データを実績情報に追加する。

ステップＳ４３４で実績管理部２２は、ライセンスキーから導かれる利用者特定情報でアプリケーション使用者Ｍ（ｘ）を判定する。利用者特定情報は、認証時に読み出された登録情報として取得してもよいし、実績管理部２２が登録データベース３０にアクセスして取得してもよい。
ステップＳ４３５で実績管理部２２は、アプリケーション利用者のＡＰＩ使用情報の更新を行う。例えば利用者特定情報で特定されたアプリケーション利用者Ｍ（ｘ）についての図１９のような実績情報に、今回のＡＰＩ使用要求に関する日時、使用ＡＰＩ、サービス識別情報、アプリケーション提供者の情報を追加する。
またステップＳ４３６で実績管理部２２は、今回のＡＰＩ使用要求に関するアプリケーション利用者に対しての課金データを生成する。そして課金データを実績情報に追加する。

図１６のステップＳ４０３としての実績管理処理が、例えば以上の図１８のように行われることで、ＡＰＩ使用に関してアプリケーション提供者、アプリケーション利用者のそれぞれに実績管理や課金データ形成を行うことができ、ＡＰＩ使用の関係者の実績を容易に把握できる。また認証を経た上での使用のため、実績情報は正当なＡＰＩ使用についての実績であることが確保され、その意味でアプリケーション提供者、アプリケーション利用者のそれぞれに対する課金データも正当なＡＰＩ使用にかかる金額として算定できる。
なお、図１８は一例に過ぎない。実績情報のデータ形態は多様に想定される。設定する実績データのデータ種別、データベース形式など応じて、必要な実績情報の追加や更新が、アプリケーション提供者とアプリケーション利用者のそれぞれについて行われればよい。
また実績管理は、認証ＯＫの場合に包括的に使用実績を登録していくような手法ではなく、アプリケーションプログラムによるサービス実行中の処理過程で実際にＡＰＩが使用される都度、使用実績を登録するような手法も考えられる。

上述の認証ＯＫの場合、利用者装置４では、ステップＳ３２２からＳ３２３に進んで、サービスアプリケーションの通常処理が実行される。
そのサービスアプリケーションの処理過程で、ＡＰＩサーバ２０が用意しているＡＰＩが使用されてアプリケーション利用者に関する情報アクセスが行われる。ＡＰＩサーバ２０側では、サービスアプリケーションの要求に応じてステップＳ４０４として示すようにＡＰＩ処理が行われ、店舗情報データベース３１に対する情報アクセスが実行される。
例えば図１５に示すように、店舗情報データベース３１には、各アプリケーション利用者Ｍ１，Ｍ２・・・について、各アプリケーション利用者の営業情報Ｍ１ｄｔ、Ｍ２ｄｔ・・・等が保存されている。
今、図１５に示した利用者装置４が、アプリケーション利用者Ｍ１が用いる装置であるとすると、サービスアプリケーションの処理によって利用者装置４は例えばＡＰＩ＃１を利用して、自己の営業情報Ｍ１ｄｔにアクセスする。
このようなアクセスを利用して、サービスアプリケーションは利用者装置４上でアプリケーション利用者Ｍ１に対して、商品在庫、価格管理、顧客情報などの提示、編集対応などを行う。即ちネットワークサービスを提供することになる。

そしてこのようなＡＰＩ使用による情報アクセスは、上述のようにサービスコードとライセンスキーを用いた認証のうえで実行される。従ってむやみにＡＰＩ使用が行われることはなく、正当な使用の範囲に制限されることで、営業情報Ｍ１ｄｔ等の情報の安全性も確保される。
なお、ライセンスキーの認証によりアプリケーション利用者が特定されるため、ＡＰＩにより処理されるデータを限定することができる。例えばアプリケーション利用者Ｍ１の利用者装置４からのＡＰＩ使用の場合、例えばＡＰＩ＃１により営業情報Ｍ１ｄｔにアクセスされるが、他人の営業情報Ｍ２ｄｔにはアクセスできないようにすることができる。実際には、ＡＰＩ＃１が認証結果に基づいて、認証されたアプリケーション利用者Ｍ１向けの情報のみをアクセスするようにフィルタリングを行えばよい。このようにすることで各アプリケーション利用者Ｍ１、Ｍ２・・・にとっては、自己の営業情報にアクセスして閲覧・更新等ができ、かつその自己の営業情報を他人によってはアクセスできないものとなる。
即ち利用者限定性のある情報を扱うＡＰＩを想定した場合、ライセンスキーの認証結果に基づいて、ＡＰＩがアクセスする情報を限定することが好適である。
但し、ＡＰＩが特に利用者が限定されない一般公開情報を扱う場合は、このようなアクセスする情報をアプリケーション利用者に応じて限定するような情報のフィルタリングは行わなくてもよい。

ところで、先にアプリケーション利用者によるライセンス承認に関して、使用ＡＰＩの一括承認と個別承認について述べた。
ここまでの認証や実績管理を含むサービス実行時の処理は、一括承認を想定している。個別承認を採用する場合、認証処理においては、一部のＡＰＩの使用に関して許可するという最終結果が得られる場合が生ずる。つまりアプリケーション利用者がライセンス承認を行わなかったＡＰＩについては使用が禁止される。
例えば図１７のステップＳ４０６のライセンスキーの認証に関しては、一部のＡＰＩが“承認”で一部のＡＰＩが“非承認”ということがあり得る。このような場合、“承認”のＡＰＩについて許可という制限付きの認証ＯＫとなる。
この場合、例えば実績管理処理においては、使用ＯＫとされたＡＰＩについてのみの使用情報や課金情報を更新することが適切である。
またサービスアプリケーションの処理機能は、使用できないＡＰＩが存在することで、一部が制限されることが考えられる。

＜５．サービス実行時の処理例II＞
サービス実行時の処理例IIを図２０〜図２３を参照して説明する。処理例IIの場合の基本的な処理は上述した（Ｐ１）〜（Ｐ４）と同様であるが、この例は、登録情報にコピー制限回数や端末識別情報を加え、サービス実行時にこれらの確認も行う点が異なる。

この場合の登録情報の例を図２０に示す。図４と異なるのは、各ライセンスキーＬＣ＃Ａ、ＬＣ＃Ｂに対応してコピー制限回数ＣＮが登録され、また１又は複数の端末識別情報ＤＶ（ＤＶ１、ＤＶ２・・・）が登録される点である。
これらの登録は、上述の登録処理過程で行われても良いし、独立した端末登録として行われてもよい。また例えばサービスアプリケーションが利用者装置４において初めて起動されたときに行われるようにしてもよい。以下では、初回起動時に登録が行われる例で説明する。

図２１は、先の図１６と同様に、主に利用者装置４とＡＰＩサーバ２０の処理を示している。図１６と同一の処理は同一のステップ番号を付して説明を省略する。異なるのは利用者装置４においてはステップＳ３２０のサービスアプリケーション起動時の処理と、ステップＳ３３０が加わること、さらにはステップＳ３２１の送信内容である。ＡＰＩサーバ２０側ではステップＳ４００の認証処理が異なる。またステップＳ３２０に対応して登録サーバ１０のステップＳ１８０の登録要求対応処理が行われる。

まず、利用者装置４のステップＳ３２０のサービスアプリケーション起動時の処理と、それに対応する登録サーバ１０の処理を図２２で説明する。
図２２のステップＳ３２０１で、利用者装置４においてサービスアプリケーション起動が行われる。サービスアプリケーションに基づいて処理を行う利用者装置４は、今回の起動が、その利用者装置４としての端末上で初めてであるか否かを判断し、初回起動でなければステップＳ３２０２から処理を抜ける。この場合、図２１のステップＳ３２０が終了する。
初回起動の場合のみ、ステップＳ３２０２からＳ３２０３に進む。ステップＳ３２０３で、利用者装置４は、自己の端末識別情報を取得する。端末識別情報は、端末自体を識別できる情報である。例えばＭＡＣアドレス（Media Access Control address）や情報処理装置としての製品シリアルナンバなどが想定される。
そして利用者装置４はステップＳ３２０４で登録サーバ１０に対し端末登録要求を送信する。このとき、端末登録要求とともに、サービスコード、ライセンスキー、及び端末識別情報も送信する。
なお、この端末登録要求は、利用者ＷＥＢ１３を用いて実行するようにしてもよいし、ウェブサイトを介さずに利用者装置４がＥＣ管理システム１に送信する形態でもよい。

端末登録要求に対応して登録サーバ１０では、登録管理部１１が例えばライセンス処理部１１ｂの機能によりステップＳ１６０の端末登録可否判定を行う。
この場合、例えばサービスコードにより登録データベース３０をアクセスして登録情報を読み出す。そして例えば
・サービスコードが登録されているか。
・ライセンスキーがサービスコードに対応されているか。
・ライセンスキーについてライセンス承認情報が“承諾”になっているか。
・そのライセンスキーについて既に登録されている端末識別情報ＤＶの数が、コピー制限回数ＣＮの数に達していないか。
・送信されてきた端末識別情報が既に端末識別情報ＤＶとして登録済みでないか。
・送信されてきた端末識別情報が、登録禁止対象（例えばブラックリスト掲載）となっていないか。
等を確認する。そしてこれらの条件がクリアできた場合に登録可と判定する。

登録可とする場合、登録サーバ１０はステップＳ１６１からＳ１６２に進み、端末登録要求について送信されてきた端末識別情報を、ライセンスキーに対応させて登録データベース３０に登録する処理を行う。

そして登録サーバ１０はステップＳ１６３で登録確認処理を行う。これはアプリケーション利用者に、端末登録についての確認を求めるための処理である。
登録確認処理では、少なくともアプリケーション利用者に対して端末識別情報登録の通知（端末登録通知）を行う。この通知は、ライセンスキーに対応して登録されている利用者特定情報で示されるアプリケーション利用者に対して行う。従って実際に端末登録要求を送信してきた利用者装置４である場合もあるが、他の利用者装置４となる場合もある。通知は、例えば利用者特定情報から導かれる電子メールアドレス宛に電子メールとして送信してもよいし、他の手法でもよい。このステップＳ１６３は、あくまでも、利用者特定情報により登録されたアプリケーション利用者に対して通知を行うという処理となる。
この通知により、正規のアプリケーション利用者は、或る利用者装置４の端末識別情報が登録されたことを知ることができる。これがアプリケーション利用者自身が使用する端末であったり、管理下の端末であれば問題ない。ところがアプリケーション利用者にとって未知の端末であれば、サービスアプリケーションとライセンスキーが不正にコピー又は盗用されて流出した可能性がある。アプリケーション利用者は、このように通知により不正使用の危険性を知ることができる。

ステップＳ１６３の登録確認処理としては、少なくとも以上の端末登録通知が行われるが、さらに以下の処理を行うようにしても良い。
例えば端末登録通知に対してアプリケーション利用者からの端末登録承諾の通知を待機し、端末登録承諾の通知が得られた場合のみ、ステップＳ１６２で登録した端末識別情報を有効化してもよい。つまり正当なアプリケーション利用者の管理に基づくサービスアプリケーションの起動であれば、アプリケーション利用者に承諾通知を求め、その承諾通知によって端末識別情報の登録の正当性を担保する。
一方、所定期間内に承諾通知が得られなかったり、或いはアプリケーション利用者から拒否通知が送信されてきた場合、登録した端末識別情報ＤＶを削除したうえ、ステップＳ１６１で登録不可とする場合と同様にステップＳ１６５に進むようにしてもよい。
また拒否通知の場合、その対象の端末識別情報を上記したブラックリストに登録するということも考えられる。

続いて登録サーバ１０はステップＳ１６４で、利用者装置４に対して登録完了通知を行う。この場合の通知先の利用者装置４とは、ステップＳ３２０４で端末登録要求を送信してきた端末のことである。つまり端末登録要求に対する結果通知となる。
一方、登録不可の場合は、登録サーバ１０はステップＳ１６１からＳ１６５に進み、利用者装置４に対して登録不可通知を行う。
利用者装置４では、ステップＳ３２０５で登録完了通知又は登録不可通知を確認し、これを記憶する。

以上の図２２の処理が、図２１のステップＳ３２０，Ｓ１８０で行われる。
利用者装置４では、ステップＳ３２０の起動処理の後、ステップＳ３３０で、記憶してある登録通知を確認する。即ち、初回起動時であれば、直前に登録完了通知か登録不可通知が受信されているため、それを確認する。２回目以降の起動時は、初回起動時に上記図２２の処理で通知され、記憶した登録完了通知か登録不可通知を確認する。
ステップＳ３３０において、通知内容が登録不可通知であった場合、その利用者装置４は端末識別情報ＤＶが登録されていない端末である。この場合、正規のサービスアプリケーション使用とは認められないため、ステップＳ３２４に進み、エラー終了となる。

登録完了通知が確認された場合、ステップＳ３３０からＳ３２１に進み、利用者装置４はＡＰＩサーバ２０に対してＡＰＩ使用要求を送信する。このＡＰＩ使用要求の際に、利用者装置４はサービスコードとライセンスキー、さらには端末識別情報を同時に送信する。なお、ＡＰＩ使用要求には、要求を行ったサービスアプリケーションを示すサービス識別情報、及び使用要求の対象となるＡＰＩを指定する情報も含まれている。
利用者装置４側では、これ以降のステップＳ３２２，Ｓ３２３，Ｓ３２４は、処理例Ｉの図１６と同様に処理が行われる。

ＡＰＩサーバ２０では、ＡＰＩ使用要求に対して、ステップＳ４００〜Ｓ４０４の処理を図１６の場合と同様に実行するが、ステップＳ４００の認証処理で異なる点があるため、図２３で説明する。
図２３はＡＰＩサーバ２０が認証部２１によって実行する認証処理を示している。
認証部２１はステップＳ４１０Ａで、ＡＰＩ使用要求とともに利用者装置４から送信されてきたサービスコードとライセンスキー、さらに端末識別情報を取得する。
また認証部２１は、ＡＰＩ使用要求としての情報に含まれているサービス識別情報と使用要求対象のＡＰＩを示す情報も取得する。
そして認証部２１はステップＳ４１１で、サービスコードとライセンスキーを用いて登録データベース３０にアクセスし、そのサービスコード及びライセンスキーに対応する登録情報を取得する。この場合、図２０に示した登録情報を取得する。つまりサービスコードに対応する登録情報として、サービス識別情報、アプリケーション提供者の情報、及び使用ＡＰＩ情報を取得する。またライセンスキーに対応する登録情報として、そのライセンスキー自体に対応する利用者特定情報、ライセンス承認情報、及び端末識別情報を取得する。例えばライセンスキーＬＣ＃Ａの場合、利用者特定情報ＭＣ−Ａ、及びライセンスキーＬＣ＃Ａについてのライセンス承認情報、端末識別情報ＤＶ１，ＤＶ２，ＤＶ３である。

以降のステップＳ４１２〜Ｓ４１９は図１７で説明した処理と同様であるため重複説明を避ける。
この図２３の例では、ステップＳ４２０として認証事項に端末識別情報が加えられる。
ステップＳ４２０で認証部２１は端末識別情報についての認証として、例えば以下の確認を行う。
・正規に登録された端末識別情報であるか否かの確認
ＡＰＩ使用要求と共に送信されてきた端末識別情報が、登録データベース３０に登録された端末識別情報ＤＶに一致するか否かを確認する。この場合、ライセンスキーとの対応関係で一致確認を行うことになる。例えば図２０の場合で説明すると、ＡＰＩ使用要求においてライセンスキーＬＣ＃Ａが利用者装置４から送信されてきた場合、認証部２１は、利用者装置４から送信されてきた端末識別情報が、ライセンスキーＬＣ＃Ａに対応する端末識別情報ＤＶ１，ＤＶ２，ＤＶ３のいずれかに一致しているか否かを確認する。

このような端末識別情報についての認証を加えた上で、ステップＳ４１７，Ｓ４１８の認証結果判定が行われ、図２１のステップＳ４００の認証処理が完了する。
そして以降、ＡＰＩサーバ２０ではステップＳ４０１〜Ｓ４０４の処理が図１６の場合と同様に実行される。

以上の処理例IIのように、コピー制限回数や端末識別情報を用いた判断を行うことで、サービスアプリケーション利用の安全性をより高めることができる。つまりＡＰＩサーバ２０は利用者装置４としての端末単位で認証でき、登録されていない端末が用いられている場合に不正使用の可能性があるとして、ＡＰＩ使用要求を拒否できる。例えばサービスアプリケーションの不正コピーやライセンスキーの盗用によって、サービスアプリケーションが起動された場合におけるＡＰＩ使用を禁止できる。
また端末識別情報ＤＶの登録の条件に、ライセンスキーについて既に登録されている端末識別情報ＤＶの数がコピー制限回数ＣＮを越えないことを条件とすることで、サービスアプリケーションのコピーによる氾濫を防ぐこともできる

なお、コピー制限回数ＣＮの情報は、必ずしもライセンスキーに対応させて登録しなくても良い。例えば全ての場合にコピー制限回数は“１つのライセンスキーに対して３回”などとシステム上で設定する場合、コピー制限回数ＣＮを登録する必要はない。
またコピー制限回数はサービスアプリケーション（サービス識別情報）に対応させて登録するようにしても良い。例えばアプリケーション提供者が、上述したＡＰＩ使用登録要求において、コピー制限回数を入力可能とする。これに応じて登録サーバ１０が図６のステップＳ１０３の時点で、コピー制限回数ＣＮをサービス識別情報やサービスコードに対応させて登録するようにする。
またコピー制限回数ＣＮは、アプリケーション提供者が予め自己が提供するサービスアプリケーションについて固定的に設定し、登録サーバ１０に通知しておいてもよい。その場合、固定値のコピー制限回数ＣＮがサービスコードに対応して自動登録されるようにすることも考えられる。

またコピー制限回数ＣＮをライセンスキーに対応させる場合、アプリケーション提供者が顧客（アプリケーション利用者）毎にコピー制限回数ＣＮを設定可能としてもよい。
例えばライセンス発行要求として利用者特定情報を登録サーバ１０に送信する際に、その利用者特定情報に対応させてコピー制限回数ＣＮを設定できるようにする。登録サーバ１０では、図７のステップＳ１１３の処理で、ライセンスキー、利用者特定情報に対応させてコピー制限回数ＣＮを登録する。
このようにすれば、アプリケーション提供者が、アプリケーション利用者の個別にサービスアプリケーションの許容コピー回数を設定できる。例えばサービスアプリケーション提供の契約内容などにより許容コピー回数を設定することができる。

また、コピー制限回数ＣＮをサービス利用者が設定できるようにしてもよい。
例えばコピー制限回数ＣＮとしての上限がシステム上、もしくはアプリケーション提供者の設定により決められている範囲内で、アプリケーション利用者がライセンス承認を行う際にコピー制限回数ＣＮを入力可能とする。そして登録サーバ１０は図８のステップＳ１２４のライセンス承認情報の登録の際などに、そのライセンスキーに対応させてコピー制限回数ＣＮを登録する。この場合、アプリケーション利用者が、自己の情報（営業情報Ｍ１ｄｔ等）の流出を厳に防止するといった目的で、サービスアプリケーションのコピーを制限したいというときに有用となる。

またコピー制限回数ＣＮは登録されなくても良い。例えばコピー回数制限を行わない場合は必要ない。或いは、アプリケーション提供者が、自己が提供するサービスアプリケーションについてはコピー回数制限を設けたくない場合、そのアプリケーション提供者のサービスアプリケーションについてはコピー制限回数ＣＮが登録されないような手法も考えられる。
またコピー制限回数ＣＮは登録するが、端末識別情報ＤＶを登録しないという例も考えられる。

＜６．サービス実行時の処理例III＞
サービス実行時の処理例IIIを図２４を参照して説明する。基本的な処理は上述した（Ｐ１）〜（Ｐ４）と同様であるが、この例は、ＡＰＩ使用要求に対する認証の際に、アプリケーション提供者に対する確認を行うものとしている。
図２４には、利用者装置４とＡＰＩサーバ２０の処理に加えて提供者装置３Ａの処理も示している。利用者装置４とＡＰＩサーバ２０の処理において図１６と同様の処理は、同一のステップ番号を付して説明を省略する。この場合、ＡＰＩサーバ２０においてステップＳ４６０の真正アプリケーション確認処理が行われる点が図１６と異なる。

ＡＰＩサーバ２０は利用者装置４からＡＰＩ使用要求が送信され、例えばステップＳ４００の認証を行った後に、ステップＳ４６０の真正アプリケーション確認処理として、提供者装置３Ａに対して確認要求の通知を行う。
この場合、例えばサービスコード、ライセンスキー、サービス識別情報、利用者特定情報など、実行されようとしているサービスアプリケーションの内容や権限を示す情報を、提供者装置３Ａに送信する。
提供者装置３ＡにおいてはステップＳ３５１で、例えばこのサービスアプリケーションの内容や権限が正当なものであるか否かを確認する照合処理を行って、その結果を確認回答としてＡＰＩサーバ２０に通知する。
ＡＰＩサーバ２０は確認回答がＯＫであれば、提供者確認ＯＫ、確認回答がＮＧであれば提供者回答ＮＧとして処理する。
そしてＡＰＩサーバ２０はステップＳ４０１Ａで利用者装置４に対して認証結果と提供者確認結果を通知する。

認証ＮＧ又は認証不能となった場合、或いは提供者確認ＮＧとなった場合は、ＡＰＩサーバ２０は、ステップＳ４０２ＡからＳ４０５に進んで、ＡＰＩ使用禁止としてＡＰＩ使用要求に対する処理を終了する。
また利用者装置４では、認証ＮＧ又は認証不能の通知、或いは提供者確認ＮＧの通知を受信した場合、ステップＳ３２２ＡからＳ３２４に進んで、サービスアプリケーションはエラー終了することになる。
ＡＰＩサーバ２０は認証ＯＫかつ提供者確認ＯＫとなった場合に、ステップＳ４０２ＡからＳ４０３の実績管理処理、及びステップＳ４０４のＡＰＩ処理に進む。
利用者装置４では、認証ＯＫかつ提供者確認ＯＫの通知が得られた場合に、ステップＳ３２２ＡからＳ３２３に進んで、サービスアプリケーションの通常処理が実行される。

このようにサービス実行時にサービスアプリケーションが真正なものか否かを提供者装置３Ａ側の確認をとるようにすることで、不正アプリケーションによるＡＰＩ使用を排除できる。
具体的には、或るサービスアプリケーションについて登録されたサービスコードが盗用されて、正規登録されていない他のサービスアプリケーションに付加されて使用される場合が考えられる。
例えば悪意のアプリケーション利用者が、不正にサービスコードが付加されたサービスアプリケーションを取得して、自己に発行されたライセンスキーを使用してＡＰＩサーバ２０にアクセスする場合や、さらにライセンスキー自体も盗用されて第三者に不正サービスアプリケーションが使用される場合などが想定される。
このような不正サービスアプリケーションによるＡＰＩ使用要求があった場合に、そのサービスアプリケーションの内容をアプリケーション提供者側に確認することで、不正使用を排除できる。
なお、アプリケーション提供者側（提供者装置３Ａ）で確認を行うために、例えばサービス識別情報の照合を行うことが考えられる。サービス識別情報として、１つのサービスアプリケーションのタイトルに固有の情報を含むようにすれば、サービスコードとサービスアプリケーションの関係を確認できる。

また、真正アプリケーション確認処理は、提供者装置３Ａに対する通知のみとし、確認回答受付は行わないようにしてもよい。確認回答の待機によりサービス実行のパフォーマンス低下を避けるためである。提供者装置３Ａに対する通知のみであっても、アプリケーション提供者が確認して対処することで、事後的に不正アプリケーション使用に対処することが可能である。
また真正アプリケーション確認処理は、一例としてステップＳ４００の認証の後に行われるようにしたが、ステップＳ４００の認証処理の前に行っても良い。
またＡＰＩ使用要求の際に毎回行うのではなく、例えばサービスアプリケーションによる初回のＡＰＩ使用要求の際にのみ真正アプリケーション確認処理を行ったり、或いは定期的に行うようにしてもよい。
また以上の処理例IIIを、処理例IIの場合に適用してもよい。

＜７．サービス実行時の処理例IV＞
サービス実行時の処理例IVとして、図１の提供者装置３Ｂを利用するＡＳＰの場合について説明する。
なお、ＡＳＰとしての提供者装置３Ｂの場合、サービスアプリケーションを利用者装置４ではなく提供者装置３Ｂで起動し、提供者装置３Ｂがサービスアプリケーションに従ってＡＰＩ使用を行うことになる。この場合、基本的には上述の処理例Ｉ、II、IIIにおける利用者装置４の処理が提供者装置３Ｂにおいて実行されると考えればよい。
但しこの処理例IVとしては、悪意のＡＳＰによるＡＰＩ使用を排除する処理も加えた例を説明する。

図２５はサービス実行時の認証やＡＰＩ使用の処理についての関連部位と情報のやりとりを模式的に示したものである。
この場合、提供者装置３Ｂ側でサービスアプリケーションが用意されている。提供者装置３Ｂは、利用者装置４からの要請に応じてサービスアプリケーションを実行する。即ち提供者装置３Ｂにおいてサービスアプリケーションを起動する。この際にサービスアプリケーションはＡＰＩサーバ２０が用意するＡＰＩを使用して必要な情報アクセスを行う。例えばアプリケーション利用者Ｍ１の利用者装置４からの要請に応じて、提供者装置３Ｂで起動されているサービスアプリケーションは、ＡＰＩ＃１を使用して営業情報Ｍ１ｄｔにアクセスを行う。そして例えば商品管理、在庫管理、顧客管理などのサービスの結果を利用者装置４に提供する。この形態によりアプリケーション利用者がサービスアプリケーションによるサービスを享受できる。

サービス実行時の処理は大まかには次の（Ｐ１１）〜（Ｐ１４）の手順で行われる。
（Ｐ１１）提供者装置３Ｂは利用者装置４からのサービス要求及びライセンスキーを受け取る。そして提供者装置３Ｂは起動したサービスアプリケーションに基づいて、ＡＰＩサーバ２０に対してＡＰＩ使用要求を送信する。この場合にサービスコードとライセンスキーも送信する。
（Ｐ１２）ＡＰＩサーバ２０は、認証部２１の機能により、ＡＰＩ使用要求に伴うサービスコードとライセンスキーに基づいて認証処理を行う。そして認証結果を提供者装置３Ｂに通知する。このとき真正使用確認処理としてＡＰＩサーバ２０と利用者装置４の間で確認要求と確認回答のやりとりが行われる。ＡＰＩサーバ２０は、その確認結果も提供者装置３Ｂに通知する。
（Ｐ１３）認証ＯＫの場合、ＡＰＩサーバ２０は、実績管理部２２の機能により、サービスコードとライセンスキーに基づいてアプリケーション提供者とアプリケーション利用者について個別の実績管理処理を行う。
（Ｐ１４）認証ＯＫの場合、ＡＰＩサーバ２０はＡＰＩ使用を許可する。つまりサービスアプリケーションによる処理過程で発生する要求に応じて、ＡＰＩ使用が実行される。

以下、図２６を参照してサービス実行時の各部の具体的な処理例を説明する。
図２６は利用者装置４、提供者装置３Ｂ、ＡＰＩサーバ２０の処理を示している。図２６のＡＰＩサーバ２０の処理とは、認証部２１が図３で説明した認証処理部２１ａ、登録情報取得部２１ｂの機能を用いて実行する処理と、実績管理部２２の機能による処理と、ＡＰＩ２４による処理を含む。

アプリケーション利用者がＡＳＰとしてのアプリケーション提供者が提供するサービスを享受する場合、アプリケーション提供者にサービス実行を依頼する。即ち利用者装置４はステップＳ３５０で、提供者装置３Ｂに対してサービス実行要求を送信する。このときにそのサービスについて取得しているライセンスキーも送信する。

提供者装置３Ｂでは、サービス実行要求に応じてステップＳ５００でサービスアプリケーションの起動処理が行われる。
サービスアプリケーションが起動されることで、そのサービスアプリケーションによって規定される処理として、提供者装置３ＢではステップＳ５０１以降の処理が行われる。
ステップＳ５０１で提供者装置３ＢはＡＰＩサーバ２０に対してＡＰＩ使用要求を送信する。
このＡＰＩ使用要求の際に、提供者装置３Ｂは、サービスアプリケーションに付加されているサービスコードと、利用者装置４から受け取ったライセンスキーも同時に送信する。
なお、ＡＰＩ使用要求には、要求を行ったサービスアプリケーションを示すサービス識別情報、及び使用要求の対象となるＡＰＩを指定する情報も含まれている。

ＡＰＩサーバ２０はＡＰＩ使用要求に応じてステップＳ４００で、認証部２１の機能により、例えば図１７や図２３で説明した認証処理を行う。
認証処理に続いてＡＰＩサーバ２０は、ステップＳ４５０で真正使用確認処理を行う。
この場合、ＡＰＩサーバ２０は、ライセンスキーに対応して登録されている利用者特定情報で示される利用者装置４に対して、確認要求を送信する。例えばライセンスキー、サービス識別情報、利用者特定情報などに基づいて、実行されようとしているサービスアプリケーションの内容や権限を示す情報を、利用者装置４に送信する。
利用者装置４においては、ステップＳ３５１で、例えばこのサービスアプリケーションの内容や権限が正当なものであるか否かを確認する照合処理を行って、その結果を確認回答としてＡＰＩサーバ２０に通知する。
ＡＰＩサーバ２０は確認回答がＯＫであれば、利用者確認ＯＫ、確認回答がＮＧであれば利用者回答ＮＧとして処理する。
そしてＡＰＩサーバ２０はステップＳ４０１Ｂで提供者装置３Ｂに対して認証結果と利用者確認結果を通知する。

認証ＮＧ又は認証不能となった場合、或いは利用者確認ＮＧとなった場合は、ＡＰＩサーバ２０は、ステップＳ４０２ＡからＳ４０５に進んで、ＡＰＩ使用禁止としてＡＰＩ使用要求に対する処理を終了する。
また提供者装置３Ｂでは、認証ＮＧ又は認証不能の通知、或いは利用者確認ＮＧの通知を受信した場合、ステップＳ５０２からＳ５０４に進んで、サービスアプリケーションはエラー終了することになる。
ＡＰＩサーバ２０は認証ＯＫかつ利用者確認ＯＫとなった場合に、ステップＳ４０２ＡからＳ４０３の実績管理処理、及びステップＳ４０４のＡＰＩ処理に進む。
提供者装置３Ｂでは、認証ＯＫかつ利用者確認ＯＫの通知が得られた場合に、ステップＳ５０２からＳ５０３に進んで、ＡＰＩ使用を伴うサービスアプリケーションの通常処理が実行される。そしてサービス結果として得られるサービスデータを利用者装置４に送信する。利用者装置４ではステップＳ３５２でサービスデータを受け取る。アプリケーション利用者はサービスを享受する。

以上のようにＡＳＰとしての提供者装置３Ｂでサービスアプリケーションが実行される場合も、処理例Ｉの場合と同様に認証や実績管理が行われ、情報の安全性確保やアプリケーション提供者、アプリケーション利用者の個別の実績管理が可能となる。
またこの処理例IVでは、サービス実行時に、サービスアプリケーションが提供者装置３Ｂによって正しく使用されているか否かを利用者装置４側の確認をとるようにしている、これにより、悪意のＡＳＰがライセンスキーを盗用してサービスアプリケーションを実行することによる不正なＡＰＩ使用を排除できる。
具体的には、或るアプリケーション利用者が承認したライセンスキーを盗用したアプリケーション提供者が、そのライセンスキーを用いてサービスアプリケーションを実行し、アプリケーション利用者の情報（営業情報Ｍ１ｄｔ等）の不正閲覧、流出、改ざん等を行うことが防止される。

なお、アプリケーション利用者側の確認としては、正規にサービス実行要求を発したことに応じたサービスアプリケーションの実行であるかを確認すればよい。従って、例えば利用者装置４側でユーザの操作を待たずに自動的に確認回答をＡＰＩサーバ２０に送信することも可能である。

また真正使用確認処理は、利用者装置４に対する通知のみとし、確認回答受付は行わないようにしてもよい。確認回答の待機によりサービス実行のパフォーマンス低下を避けるためである。利用者装置４に対する通知のみであっても、アプリケーション利用者が確認して対処することで、事後的にライセンスキーの不正流出を知ることができ、サービスアプリケーションの不正使用に対処することが可能である。
また真正使用確認処理は、一例としてステップＳ４００の認証の後に行われるようにしたが、ステップＳ４００の認証処理の前に行っても良い。
またＡＰＩ使用要求の際に毎回行うのではなく、例えばサービスアプリケーションによる初回のＡＰＩ使用要求の際にのみ真正アプリケーション確認処理を行ったり、或いは定期的に行うようにしてもよい。

＜８．ＥＣ管理システムの実施による効果＞
以上、ＥＣ管理システム１の登録サーバ１０やＡＰＩサーバ２０による動作を説明してきたが、この実施の形態によれば以下の効果が得られる。

まずＥＣ管理システム１としての情報処理装置は、サービスコード処理部１１ａ、ライセンス処理部１１ｂとしての機能を持つ登録サーバ１０を備えている。
サービスコード処理部１１ａは、提供者装置３から送信されてきた、ＡＰＩ使用登録要求に対し、当該サービス（サービスアプリケーション）がＡＰＩ使用サービスとして登録されたことを示すサービスコードを生成する。そしてサービス識別情報及び使用ＡＰＩ情報をサービスコードと対応させて登録する処理を行う。
ライセンス処理部１１ｂは、提供者装置３から送信されてきた、サービスについての利用者特定情報に対応して、使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限が未承認状態のライセンス情報を生成する。またライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者の利用者装置４からの、情報アクセス権限の承認又は非承認を示すライセンス承認情報を受け付ける。そしてライセンス承認情報をライセンス情報に対応させて登録する。
このような登録サーバ１０としての構成により登録処理が行われることで、ＡＰＩ使用を伴うサービスアプリケーションについて、サービスコードにより正規登録を明示し、またライセンス情報によりアプリケーション利用者を特定し、かつアプリケーション利用者がライセンス承認を与える形式で管理できる。
従ってＥＣ管理システム１は、サービスコードによりアプリケーション提供者を管理可能であり、かつライセンス情報によりアプリケーション利用者を管理可能な状態の登録情報を得ることができる。
またライセンス情報は、アプリケーション利用者がサービスについて認識した上でサービス実行を承諾できる形式としている。従ってアプリケーション利用者によるＡＰＩ使用を伴うサービス利用についての主体的な可否判断機会が提供される。
また特に、本実施の形態が前提とするシステムは、ＡＰＩを使用するサービスアプリケーションが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたサービスアプリケーションの実行によるサービスを享受できるように構成されている。つまり複数のサービスアプリケーションと、複数のアプリケーション利用者が存在する中で、適切な管理や正当なＡＰＩ使用のための登録が実現されることが、システム管理上、非常に有用となる。

また登録サーバ１０は、アプリケーション利用者に対する、ライセンス情報発行の通知処理を行う。そしてその際にライセンス情報に対応するサービスの情報とリスク情報の提示処理を行うようにしている。これにより、アプリケーション利用者がサービスアプリケーションの内容やリスクを正しく理解してライセンス承認を行うことができる
提示するリスク情報としては使用ＡＰＩ情報を用いている。使用ＡＰＩ情報をリスク情報に含めることで、アプリケーション利用者が、サービスによって具体的にどのような情報が利用されるのかを認識でき、これもアプリケーション利用者による主体的なライセンス承認に適切である。

また登録サーバ１０は、リスク情報として通知した１又は複数の使用ＡＰＩ情報に対する、利用者装置４からの一括承認の情報のみを、ライセンス承認情報として受け付けるようにすれば、アプリケーション提供者が本来想定するＡＰＩ使用を全て維持した状態でのサービス提供を確保できる。つまりサービスを常に本来の機能を維持した状態で提供する環境をつくることができる。
一方で、個別承認の情報を、ライセンス承認情報として受け付けるようにすれば、アプリケーション利用者によるカスタマイズ（機能制限）を付加したサービス提供が可能な環境をつくることができる。またこれにより、サービスによる情報アクセスに対するアプリケーション利用者の制限意思を細かく反映させることが可能となる。

またサービス実行時の処理例IIにおいて述べたように、登録サーバ１０は、ライセンス情報に対応させてコピー許可回数を登録する。これによりサービスアプリケーションの無制限拡散防止のための環境を形成できる。
また登録サーバ１０は、ライセンス情報に対応させて端末識別情報を登録する。これにより登録した端末によりアプリケーション利用を行う環境を提供できる。アプリケーション利用者にとっては、なりすましやライセンス盗用などによる他端末からのサービス利用を防止できる環境となる。
また端末識別情報については、対応するライセンス情報についてのコピー許可回数分だけ登録可能として、端末識別情報の登録処理を行う。これによりサービスアプリケーションのコピー回数が、端末識別情報の登録により管理できる環境を実現できる。
またサービス実行時の処理例IIにおいて述べたように、登録サーバ１０は、端末識別情報を登録した際、登録の事実をアプリケーション利用者に通知する処理を行う。これによりアプリケーション利用者が、自分が承認したライセンス情報によるサービスを他端末で不正使用されないかチェックでき、サービス利用の安全性や情報流出防止効果を高めることができる。

また登録サーバ１０は、提供者ＷＥＢ１２によりＡＰＩ使用登録要求を受け付けることに応じてサービスコードの生成処理を行う。また提供者ＷＥＢ１２によってライセンス発行要求を受け付ける。これによりアプリケーション提供者によるサービスコード発行のための手続やライセンス発行のための手続を容易化できる。
また登録サーバ１０は、利用者ＷＥＢ１３により利用者装置４からライセンス承認情報を受け付けて、ライセンス情報に対応させて登録する処理を行う。これによりアプリケーション利用者によるライセンス承認のための手続を容易化できる。

また、ＡＰＩサーバ２０が提供するＡＰＩは、営業情報Ｍ１ｄｔ等の公開制限情報に対して読出又は書込アクセス可能な情報アクセス用ＡＰＩである。この場合、利用者固有情報である営業情報Ｍ１ｄｔ等を使用するサービスに関して、サービスアプリケーションによるＡＰＩ使用、つまり情報アクセスについての情報安全性が確保できる。
公開制限情報とは、例えばアプリケーション利用者の営業に関する情報であったり、ＥＣ管理システム１が作成して特定のアプリケーション利用者に提供するような情報、例えば電子商取引でのログ情報、統計情報、課金情報などが考えられる。
但し本例のシステムにおけるＡＰＩが、公開制限情報にアクセスするＡＰＩに限定されるものではない。公開情報へのアクセスのためのＡＰＩを利用するサービスにおいて実施の形態の処理を適用することは有用である。例えば他人によるサービスのただ乗り等を排除してサービス実行に関する安全性が確保されるためである。即ち公開情報であっても、そのアクセスについてアプリケーション利用者がライセンス承認を行う必要がある状況において実施の形態のシステムは有用である。

またＥＣ管理システム１としての情報処理装置は、認証処理部２１ａ、登録情報取得部２１ｂとしての機能を持つ認証部２１を備えている。認証部２１はＡＰＩサーバ２０内でも良いし、ＡＰＩサーバ２０の外部の情報処理装置で構成されてもよい。
登録情報取得部２１ｂは、ＡＰＩを使用するサービスアプリケーションについて、サービス識別情報と、使用ＡＰＩ情報と、サービスコードと、利用者特定情報と、ライセンス情報と、ライセンス承認情報とが関連づけられた登録情報を取得する。
認証処理部２１ａは、サービスアプリケーションの実行に伴うＡＰＩ使用要求があった際に、サービスコードとライセンス情報に基づいて登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の確認を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する。
このような認証部を有することで、正規のサービスアプリケーションの使用範囲内であり、かつアプリケーション利用者によるライセンス承認の範囲内で、ＡＰＩ使用が行われる状態が確保される。このためサービスにおけるＡＰＩ使用はアプリケーション利用者の想定範囲内となり、ＡＰＩによりアクセスされる情報の安全性が維持される。
特に認証は、サービスコード及びサービスコードに紐づけられた使用ＡＰＩ情報を用いた認証により、アプリケーション提供者の正当性及び使用ＡＰＩの範囲としての権限が確認される。またライセンス情報に基づく認証により、アプリケーション提供者との関係におけるアプリケーション利用者の正当性と、アプリケーション利用者の承諾の範囲としてのＡＰＩ使用が確認される。このため、アプリケーション提供者とアプリケーション利用者の２者の意思による合意範囲内で、サービスアプリケーションによる正当なＡＰＩ使用が確保される。
特に、複数のサービスアプリケーションと複数のアプリケーション利用者が存在する中で、適切な認証が行われることで、正当なＡＰＩ使用が維持され、システム運営上、非常に有用となる。

なお、アプリケーション利用者がライセンス承認情報を設定することにより、ＡＰＩ使用による情報流出の可能性は、ライセンス承認範囲に制限されるという側面もある。仮に通常は想定できないような行為やハッキングなどによってＡＰＩ使用が不正に行われてしまったとしても、それによる情報流出範囲は、アプリケーション利用者が当初承認した範囲にとどめられる。従ってアプリケーション利用者にとっては、このような最悪の事態を想定したうえで、ライセンス承認を行うということも可能である。

また認証部２１によっては、サービスアプリケーションが実行された外部端末装置からＡＰＩ使用要求とともに送信されてくるサービスコード及びライセンス情報を受信して、認証処理を行う。即ちＡＰＩ使用要求とともに送信されてくるサービスコードやライセンス情報に紐付けされた登録情報を用いて認証を行う。これによりサービスアプリケーションの正当性、及びライセンスキーによるアプリケーション利用者の正当性について適切に認証できる。
また認証処理では、サービスコード、サービス識別情報、使用ＡＰＩ情報、及びライセンス承認情報の全てについて所定の確認ができた場合に、ＡＰＩ使用要求に係るＡＰＩ使用を許可する。これにより情報の安全性確保を最優先した運用を実現できる。
また、登録情報にはライセンス情報に対応する端末識別情報を含むようにし、認証処理において、ＡＰＩ使用要求を送信してきた外部端末装置について端末識別情報を用いた認証も行う。これによりアプリケーションプログラムやライセンスキーの不正コピー、不正流出に対処した認証が可能となる。
また処理例IVのように、ＡＰＩ使用要求に対して、ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者に対するＡＰＩ使用要求発生の通知処理を行う。これにより、アプリケーションプログラムが実行されたことをアプリケーション利用者が認識でき、正規なサービス利用であるか否かの判断機会を与えることができる。これによりライセンスキー盗用などの不正利用を発見したり、対処を行うことができる。
特にＡＰＩサーバ２０が確認回答を待ってＡＰＩ使用を許可することで、不正なサービス利用を回避できる。
また処理例IIIのように、ＡＰＩ使用要求に対して、アプリケーション提供者に対するＡＰＩ使用要求発生の通知処理を行うことで、アプリケーションプログラムが実行されたことをアプリケーション提供者が認識でき、正規なサービス利用であるか否かの判断機会を与えることができる。これによりサービスアプリケーションやサービスコードの不正コピーや盗用を発見したり、必要な対処を行うことができる。
特にＡＰＩサーバ２０が確認回答を待ってＡＰＩ使用を許可することで、サービスコードやサービスコードの拡散に基づく不正なサービス利用を回避できる。

またＥＣ管理システム１としての情報処理装置は、実績管理部２２を備えている。実績管理部２２はＡＰＩサーバ２０内でも良いし、ＡＰＩサーバ２０の外部の情報処理装置で構成されてもよい。
実績管理部２２は、認証によりＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する。
本実施の形態のシステムではＡＰＩ使用を伴うサービスアプリケーションの実行について、サービスコードとライセンス情報を用いた認証が行われるが、サービスコードによりアプリケーション提供者の実績管理が可能となり、ライセンス情報によりアプリケーション利用者の実績管理が可能となる。つまり、ＡＰＩ使用に関して、アプリケーション提供者とアプリケーション利用者のそれぞれの実績を適切に管理できる。
また認証ＯＫの場合に実績管理を行う。これにより実際にＡＰＩ使用が行われる場合の実績として、アプリケーション提供者、アプリケーション利用者の実績管理が可能となる。
特に、複数の多様なサービスアプリケーションと、複数のアプリケーション利用者が存在する中で、それぞれのサービスアプリケーションとアプリケーション利用者について正当な実績管理が実現され、システム運営上、非常に有用となる。

また実績管理部２２は、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者に対する課金情報を生成する。またＡＰＩ使用要求におけるライセンス情報に基づいて、アプリケーション利用者に対する課金情報を生成する。
つまりアプリケーション提供者、アプリケーション利用者のそれぞれについて実際のＡＰＩ使用に応じた課金管理が実現され、アプリケーション提供者、アプリケーション利用者へのＡＰＩ使用料の個別課金も可能となる。

＜９．プログラム及び記憶媒体＞
以上、本発明の情報処理装置の実施の形態としてのＥＣ管理システム１を説明してきたが、実施の形態のプログラムは、ＥＣ管理システム１における登録サーバ１０やＡＰＩサーバ２０（認証部２１、実績管理部２２）の処理を情報処理装置（ＣＰＵ等）に実行させるプログラムである。

実施の形態のプログラムは、提供者装置３から送信されてきた、ＡＰＩを使用するアプリケーションプログラムを用いたサービスについてのＡＰＩ使用登録要求に対し、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードを生成するとともに、サービスのサービス識別情報、及び使用ＡＰＩ情報をサービスコードと対応させて登録する処理を情報処理装置に実行させる。また、提供者装置３から送信されてきた、サービスについての利用者特定情報に対応して、使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限が未承認状態のライセンス情報を生成する処理を情報処理装置に実行させる。さらにライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者の利用者装置４からの、情報アクセス権限の承認又は非承認を示すライセンス承認情報を受け付けて、ライセンス情報に対応させて登録する処理を情報処理装置に実行させる。
即ちこのプログラムは、登録サーバ１０に対して図６〜図９で説明した処理を実行させるプログラムである。また登録サーバ１０に図２１のステップＳ１８０を実行させる場合もある。

また実施の形態のプログラムは、ＡＰＩを使用するアプリケーションプログラムを用いたサービスによるＡＰＩ使用要求についてのサービスコードとライセンス情報を取得する処理を情報処理装置に実行させる。またサービスについての提供者装置３から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、提供者装置３から指定されたアプリケーション利用者を特定する利用者特定情報に対応して発行されたライセンス情報と、ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者の利用者装置４からの、使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報に対して、ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいてアクセスする処理を情報処理装置に実行させる。さらに、そのアクセスで取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の照合を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する処理を情報処理装置に実行させる。
即ちこのプログラムは、認証部２１を有するＡＰＩサーバ２０としての情報処理装置に対して図１６、図２１、図２４又は図２６で説明した処理、及び図１７又は図２３で説明した処理を実行させるプログラムである。

また実施の形態のプログラムは、さらにＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する処理を情報処理装置に実行させる。
即ちこのプログラムは、実績管理部２２を有するＡＰＩサーバ２０としての情報処理装置に対して図１６、図２１、図２４又は図２６で説明した処理、特には図１８で説明した処理を実行させるプログラムである。

このようなプログラムにより、上述したＥＣ管理システム１としての情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記録媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記録しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。またこのようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

＜１０．変形例＞
本発明は上述の実施の形態に限定されず、各種の変形例が考えられる。
登録時の処理やサービス実行時の処理は、上記例に限定されるものではない。ＡＰＩ使用登録要求、ライセンス承認、ＡＰＩ使用要求などにおける情報処理装置間の通信手法、情報提示手法、アプリケーション提供者やアプリケーション利用者による入力手法は多様に考えられる。
例えば図１６、図２１、図２４、図２６で例示したＡＰＩ使用時の処理としては、サービスアプリケーションが起動された利用者装置４は、ＡＰＩ使用要求と実際のＡＰＩ処理要求を同時に送信してもよい。その場合、認証部２１が認証を行ってＯＫであればＡＰＩ処理が行われるようにする。図１６でいえば、利用者装置４はステップＳ３２１の段階でＡＰＩ使用要求及びＡＰＩ処理要求（Ｓ３２３）をＡＰＩサーバ２０に送信する。ＡＰＩサーバ２０はステップＳ４００で認証を行った後、ＯＫであればＡＰＩ使用を許可してステップＳ４０４のＡＰＩ処理を行うというものである。認証結果の通知はＡＰＩ処理結果としてステップＳ４０４の処理内で行われればよい。従ってステップＳ４０１、Ｓ３２２は不要となる。
また同じくこれらのＡＰＩ使用時の処理として、ステップＳ４０３として示した実績管理処理は、ステップＳ４０４として示したＡＰＩ処理後で行ってもよい。実際にＡＰＩ処理後において課金処理を含めた実績管理が行われることで、実績データは、ＡＰＩ処理結果が反映され、より本来の実績を反映させたものとなりやすい。

また本発明については、電子商取引を行うネットワークシステムに適用する例で説明したが、必ずしも電子商取引におけるサービスでのＡＰＩ使用に限定されるものではない。本発明は多様なサービスアプリケーションにおいてＡＰＩ使用が発生する場合に適用できる技術である。
またその意味で、サービスを享受するアプリケーション利用者は、電子店舗の運営者などに限られない。

ところで上述のプログラムは、例えばＥＣ管理システム１において登録や認証、実績管理に関する機能を実現するプログラムであるが、上述の実施の形態からは、サービスアプリケーションとしてのプログラムの発明も把握される。即ち、以下の構成を備えるプログラムである。

アプリケーション提供者が、予め用意されたＡＰＩを使用するアプリケーションプログラムをアプリケーション利用者に提供し、前記アプリケーション利用者が、提供されたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置に処理を実行させる、前記アプリケーションプログラムであって、
当該アプリケーションプログラムに付随された、当該アプリケーションプログラムＡＰＩ使用サービスとして登録されたことを示すサービスコードを取得する処理と、
アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して発行されたライセンス情報を取得する処理と、
ＡＰＩ使用のためのＡＰＩ使用要求を、前記サービスコードと前記ライセンス情報とともに送信する処理と、
を情報処理装置に実行させるプログラム。

上述の実施の形態におけるサービスアプリケーションが、このようなプログラムの実施の形態となる。
またこのようなプログラムを記憶した記憶媒体や、このプログラムにより上記各処理を実行する情報処理装置としても発明として把握される。即ち利用者装置４や提供者装置３Ｂがそのような情報処理装置の実施の形態となる。

１ ＥＣシステム、２ ネットワーク、３，３Ａ，３Ｂ アプリケーション提供者装置、
４ アプリケーション利用者装置、１０ 登録サーバ、１１ 登録管理部、１１ａ サービスコード処理部、１１ｂ ライセンス処理部、１２ 提供者ＷＥＢ、１３ 利用者ＷＥＢ、２０ ＡＰＩサーバ、２１ 認証部、２１ａ 認証処理部、２１ｂ 登録情報取得部、２２ 実績管理部、３０ 登録データベース、３１ 店舗情報データベース、３２ 実績データベース

第１に、本発明に係る情報処理装置は、予め用意されたＡＰＩを使用するアプリケーションプログラムが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置であって、ＡＰＩを使用するアプリケーションプログラムを用いたサービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報を取得する登録情報取得部と、前記アプリケーションプログラムの実行に伴うＡＰＩ使用要求があった際に、当該ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいて前記登録情報取得部により取得される登録情報を参照して、少なくともサービスコードによる正規登録の確認、当該ＡＰＩ使用要求で使用を要求されたＡＰＩと使用ＡＰＩ情報との一致確認、ライセンス情報の正当性の確認、及びライセンス承認情報による承認確認を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する認証処理部と、ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する実績管理部と、を備えたものである。
このような情報処理装置は、まず複数のアプリケーションプログラムが提供される状況下で、複数のサービス利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるシステムで用いられる。そしてこの情報処理装置では、ＡＰＩ使用を伴うサービスをアプリケーションプログラムにより実行する場合に、サービスコードとライセンス情報を用いた認証が行われる。
アプリケーション提供者は、サービスコードと一体化されたアプリケーションプログラムを提供する。サービスコードは、使用ＡＰＩ情報とサービス識別情報に紐づけられている。アプリケーション利用者は自身で承認したライセンス情報を用いてアプリケーションプログラムを実行する。このような前提でサービスコードとライセンス情報を用いた認証が行われることで、アプリケーション利用者が意図しないサービス利用や、ＡＰＩ使用による情報アクセスが制限される。
さらにサービスコードとライセンスを用いた、サービスの実行時の実績管理が行われる。サービスコードによりアプリケーション提供者の実績管理が可能となり、ライセンス情報によりアプリケーション利用者の実績管理が可能となる。

第５に、上記した本発明に係る情報処理装置においては、前記認証処理部は、サービスコード、サービス識別情報、使用ＡＰＩ情報、ライセンス情報、及びライセンス承認情報の全てについて確認ができた場合に、ＡＰＩ使用要求に係るＡＰＩ使用を許可することが望ましい。
これにより情報の安全性確保を最優先した運用を実現する。

第７に、本発明に係る情報処理方法は、上述のシステムに備わる情報処理装置の情報処理方法であって、ＡＰＩを使用するアプリケーションプログラムを用いたサービスによるＡＰＩ使用要求についてのサービスコードとライセンス情報を取得し、前記サービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報に対して、前記ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいてアクセスし、前記アクセスで取得される登録情報を参照して、少なくともサービスコードによる正規登録の確認、当該ＡＰＩ使用要求で使用を要求されたＡＰＩと使用ＡＰＩ情報との一致確認、ライセンス情報の正当性の確認、及びライセンス承認情報による承認確認を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可し、ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する情報処理方法である。この情報処理方法により適切な実績管理を可能とする。

Claims (9)

1. 予め用意されたＡＰＩを使用するアプリケーションプログラムが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置であって、
   ＡＰＩを使用するアプリケーションプログラムを用いたサービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報を取得する登録情報取得部と、
   前記アプリケーションプログラムの実行に伴うＡＰＩ使用要求があった際に、当該ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいて前記登録情報取得部により取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の確認を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する認証処理部と、
   ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する実績管理部と、を備えた
   情報処理装置。
2. 前記実績管理部は、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者に対する課金情報を生成する
   請求項１に記載の情報処理装置。
3. 前記実績管理部は、ＡＰＩ使用要求におけるライセンス情報に基づいて、アプリケーション利用者に対する課金情報を生成する
   請求項１又は請求項２に記載の情報処理装置。
4. 前記認証処理部は、前記アプリケーションプログラムが実行された外部端末装置からＡＰＩ使用要求とともに送信されてくる前記サービスコード及び前記ライセンス情報を受信して認証処理を行う
   請求項１乃至請求項３のいずれかに記載の情報処理装置。
5. 前記認証処理部は、サービスコード、サービス識別情報、使用ＡＰＩ情報、及びライセンス承認情報の全てについて所定の確認ができた場合に、ＡＰＩ使用要求に係るＡＰＩ使用を許可する
   請求項１乃至請求項４のいずれかに記載の情報処理装置。
6. 前記登録情報には前記ライセンス情報に対応する端末識別情報が含まれており、
   前記認証処理部は、認証処理において、前記アプリケーションプログラムが実行されＡＰＩ使用要求を送信してきた外部端末装置について前記端末識別情報を用いた認証も行う
   請求項１乃至請求項５のいずれかに記載の情報処理装置。
7. 予め用意されたＡＰＩを使用するアプリケーションプログラムが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置の情報処理方法であって、
   ＡＰＩを使用するアプリケーションプログラムを用いたサービスによるＡＰＩ使用要求についてのサービスコードとライセンス情報を取得し、
   前記サービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報に対して、前記ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいてアクセスし、
   前記アクセスで取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の照合を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可し、
   ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する
   情報処理方法。
8. 予め用意されたＡＰＩを使用するアプリケーションプログラムが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置に処理を実行させるプログラムであって、
   ＡＰＩを使用するアプリケーションプログラムを用いたサービスによるＡＰＩ使用要求についてのサービスコードとライセンス情報を取得する処理と、
   前記サービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報に対して、前記ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいてアクセスする処理と、
   前記アクセスで取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の照合を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する処理と、
   ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する処理と、
   を前記情報処理装置に実行させるプログラム。
9. 予め用意されたＡＰＩを使用するアプリケーションプログラムが、複数、１又は複数のアプリケーション提供者によって提供され、複数のアプリケーション利用者の各々が、自己が利用可能とされたアプリケーションプログラムの実行によるサービスを享受できるように構成されたシステムに備わる情報処理装置に処理を実行させるプログラムであって、
   ＡＰＩを使用するアプリケーションプログラムを用いたサービスによるＡＰＩ使用要求についてのサービスコードとライセンス情報を取得する処理と、
   前記サービスについてのアプリケーション提供者装置から指定されたサービス識別情報及び使用ＡＰＩ情報と、当該サービスがＡＰＩ使用サービスとして登録されたことを示すサービスコードと、前記アプリケーション提供者装置から指定されたアプリケーション利用者を特定する利用者特定情報に対応して生成されたライセンス情報と、前記ライセンス情報に対応する利用者特定情報によって示されるアプリケーション利用者のアプリケーション利用者装置からの前記使用ＡＰＩ情報で示されるＡＰＩを使用した情報アクセス権限の承認又は非承認を示すライセンス承認情報と、が関連づけられた登録情報に対して、前記ＡＰＩ使用要求についてのサービスコードとライセンス情報に基づいてアクセスする処理と、
   前記アクセスで取得される登録情報を参照して、少なくともサービスコード、使用ＡＰＩ情報、及びライセンス承認情報の照合を含む認証処理を行い、認証結果に応じて要求されたＡＰＩ使用を許可する処理と、
   ＡＰＩ使用が許可された場合に、ＡＰＩ使用要求におけるサービスコードに基づいて、アプリケーション提供者の実績情報を生成し、またライセンス情報に基づいて、アプリケーション利用者の実績情報を生成する処理と、
   を前記情報処理装置に実行させるプログラムを記憶した記憶媒体。

Images