(57)【要約】      （修正有）【課題】同一のＡＰＩであっても、利用側に応じて柔軟に課金量を変化させることのできるＡＰＩ課金システム等を提供する。【解決手段】ＡＰＩ管理装置１００は、ＡＰＩを利用する際の課金条件の選択を受け付ける受付部１１４と、ＡＰＩへのリクエストを受信するＡＰＩ受信部１１２と、リクエストに応じたレスポンスをアプリケーションへ送信するＡＰＩ送信部１１３と、ＡＰＩへのリクエスト及びレスポンスの履歴を記憶する履歴記憶部１３２とを備える。課金管理装置２００は、複数のアプリケーション毎に、受付部１１４で受け付けた、課金条件を記憶する課金条件記憶部２３１と、履歴記憶部１３２から履歴に関する情報を取得する取得部２１１と、課金条件及び履歴に関する情報に基づき、課金値を決定する決定部２１３とを備える。決定部２１３は、履歴が同一の少なくとも２つのアプリケーションに対し、課金条件に応じて、異なる課金値を決定する。【選択図】図２
2019096060.tif 000002
【特許請求の範囲】
【請求項１】
複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、前記ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置と、を少なくとも含むＡＰＩ課金システムであって、
前記ＡＰＩ管理装置は、
前記アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付部と、
前記アプリケーションから、一のＡＰＩへのリクエストを受信する受信部と、
前記リクエストに応じたレスポンスを、前記アプリケーションへ送信する送信部と、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記一のＡＰＩへの前記リクエスト及び前記レスポンスの履歴を記憶する履歴記憶部と、を備え、
前記課金管理装置は、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記受付部で受け付けられた、前記一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶部と、
前記履歴記憶部から、前記履歴に関する情報を取得する取得部と、
前記課金条件及び前記履歴に関する情報に基づき、前記一のＡＰＩを利用するアプリケーションへの課金値を決定する決定部と、を備え、
前記決定部は、前記一のＡＰＩを利用する、前記履歴が同一の少なくとも２のアプリケーションに対し、前記課金条件に応じて、異なる値の課金値を決定する、ＡＰＩ課金システム。
【請求項２】
前記課金条件記憶部は、前記リクエストの成否に応じた課金の有無を、前記課金条件として記憶し、
前記送信部は、前記レスポンスを、ＨＴＴＰステータスコードで前記アプリケーションへ送信し、
前記決定部は、前記ＨＴＴＰステータスコードに応じて前記リクエストの成否を判定し、前記課金値を決定する、
ことを特徴とする請求項１に記載のＡＰＩ課金システム。
【請求項３】
前記課金条件記憶部は、前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記リクエストのデータ量、及び、前記レスポンスのデータ量の少なくともいずれか１つに応じた課金値を、前記課金条件として記憶し、
前記決定部は、（１）前記リクエストのデータ量、及び、前記レスポンスのデータ量、（２）前記リクエストのデータ量、並びに、（３）前記レスポンスのデータ量の（１）〜（３）の少なくともいずれか１つに応じ、前記課金値を決定する、
ことを特徴とする請求項１または２に記載のＡＰＩ課金システム。
【請求項４】
前記決定部は、前記リクエスト及び前記レスポンスのパケットデータのうち、メッセージボディに関するデータ量に応じて、前記課金値を決定する、
ことを特徴とする請求項３に記載のＡＰＩ課金システム。
【請求項５】
前記課金条件記憶部は、前記一のＡＰＩを利用する前記アプリケーションを提供するクライアント毎に、異なる課金条件を記憶する、
ことを特徴とする請求項１〜４のいずれか一項に記載のＡＰＩ課金システム。
【請求項６】
前記ＡＰＩ管理装置に、前記課金条件に応じて、前記アプリケーションへ所定のアラートを送信するアラート作成部をさらに実現させる、
ことを特徴とする請求項１〜５のいずれか一項に記載のＡＰＩ課金システム。
【請求項７】
複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、前記ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置と、を少なくとも含むＡＰＩ課金システムにおけるＡＰＩ課金管理方法であって、
前記ＡＰＩ管理装置が、
前記アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付ステップと、
前記アプリケーションから、一のＡＰＩへのリクエストを受信する受信ステップと、
前記リクエストに応じたレスポンスを、前記アプリケーションへ送信する送信ステップと、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記一のＡＰＩへの前記リクエスト及び前記レスポンスの履歴を記憶する履歴記憶ステップと、を含み、
前記課金管理装置が、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記受付ステップで受け付けられた、前記一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶ステップと、
前記履歴記憶ステップによって記憶された、前記履歴に関する情報を取得する取得ステップと、
前記課金条件及び前記履歴に関する情報に基づき、前記一のＡＰＩを利用するアプリケーションへの課金値を決定する決定ステップと、を含み、
前記決定ステップは、前記一のＡＰＩを利用する、前記履歴が同一の少なくとも２のアプリケーションに対し、前記課金条件に応じて、異なる値の課金値を決定する、ＡＰＩ課金管理方法。
【請求項８】
ＡＰＩ課金システムに含まれる、複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、前記ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置が実行するＡＰＩ課金プログラムであって、
前記ＡＰＩ管理装置に、
前記アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付機能と、
前記アプリケーションから、一のＡＰＩへのリクエストを受信する受信機能と、
前記リクエストに応じたレスポンスを、前記アプリケーションへ送信する送信機能と、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記一のＡＰＩへの前記リクエスト及び前記レスポンスの履歴を記憶する履歴記憶機能と、を実現させ、
前記課金管理装置に、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記受付機能で受け付けられた、前記一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶機能と、
前記履歴記憶機能によって記憶された、前記履歴に関する情報を取得する取得機能と、
前記課金条件及び前記履歴に関する情報に基づき、前記一のＡＰＩを利用するアプリケーションへの課金値を決定する決定機能と、を実現させ、
前記決定機能は、前記一のＡＰＩを利用する、前記履歴が同一の少なくとも２のアプリケーションに対し、前記課金条件に応じて、異なる値の課金値を決定する、ＡＰＩ課金プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＡＰＩ（Application Progam Interface）を利用するアプリケーションに対するＡＰＩ課金システム、ＡＰＩ課金管理方法、及び、ＡＰＩ課金プログラムに関する。
【背景技術】
【０００２】
近年、開発したアプリケーションを、ＡＰＩを介して他のアプリケーションに利用させる仕組みが広がっている。この際、アプリケーションの提供側は、自アプリケーションの利用側へ、自アプリケーションの利用に応じた課金を行うことが一般的である。例えば、特許文献１には、広告付きのＷｅｂページを生成するために貢献したＷｅｂＡＰＩを明確にし、広告の紹介料を分配可能にする広告提供システム等において、ＷｅｂＡＰＩの利用回数に応じて対価の総量をＷｅｂＡＰＩ提供者に分配することが開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１１６８６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載の課金方法では、あるＡＰＩの利用に対し、利用回数に応じて対価が決定され、利用回数が同じであれば、利用側のアプリケーションの種類に関わらずその利用料は同一となる。すなわち、アプリケーションの利用側に応じて、利用料が柔軟に決定されるものではない。これに対し、ＡＰＩの提供側は、提供するアプリケーションを利用側がどんなアプリケーションに利用するのかに応じて、課金量を変化させたいという要望がある。
【０００５】
そこで、本発明は、同一のＡＰＩであっても、利用側に応じて柔軟に課金量を変化させることのできるＡＰＩ課金システム、ＡＰＩ課金管理方法、及び、ＡＰＩ課金プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の一実施形態によるＡＰＩ課金システムは、複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置と、を少なくとも含むＡＰＩ課金システムであって、ＡＰＩ管理装置は、アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付部と、アプリケーションから、一のＡＰＩへのリクエストを受信する受信部と、リクエストに応じたレスポンスを、アプリケーションへ送信する送信部と、一のＡＰＩを利用する複数のアプリケーション毎に、一のＡＰＩへのリクエスト及びレスポンスの履歴を記憶する履歴記憶部と、を備え、課金管理装置は、一のＡＰＩを利用する複数のアプリケーション毎に、受付部で受け付けられた、一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶部と、履歴記憶部から、履歴に関する情報を取得する取得部と、課金条件及び履歴に関する情報に基づき、一のＡＰＩを利用するアプリケーションへの課金値を決定する決定部と、を備え、決定部は、一のＡＰＩを利用する、履歴が同一の少なくとも２のアプリケーションに対し、課金条件に応じて、異なる値の課金値を決定する。
【０００７】
本発明の一実施形態によるＡＰＩ課金システムにおいて、課金条件記憶部は、リクエストの成否を、課金条件として記憶し、送信部は、レスポンスを、ＨＴＴＰステータスコードでアプリケーションへ送信し、決定部は、ＨＴＴＰステータスコードに応じてリクエストの成否を判定し、課金値を決定してもよい。
【０００８】
本発明の一実施形態によるＡＰＩ課金システムにおいて、課金条件記憶部は、一のＡＰＩを利用する複数のアプリケーション毎に、リクエストのデータ量、及び、レスポンスのデータ量の少なくともいずれか１つに応じた課金値を、課金条件として記憶し、決定部は、（１）リクエストのデータ量、及び、レスポンスのデータ量、（２）リクエストのデータ量、並びに、（３）レスポンスのデータ量の（１）〜（３）の少なくともいずれか１つに応じ、課金値を決定してもよい。
【０００９】
本発明の一実施形態によるＡＰＩ課金システムにおいて、決定部は、リクエスト及びレスポンスのパケットデータのうち、メッセージボディに関するデータ量に応じて、課金値を決定してもよい。
【００１０】
本発明の一実施形態によるＡＰＩ課金システムにおいて、課金条件記憶部は、一のＡＰＩを利用するアプリケーションを提供するクライアント毎に、異なる課金条件を記憶してもよい。
【００１１】
本発明の一実施形態によるＡＰＩ課金管理方法は、複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置と、を少なくとも含むＡＰＩ課金システムにおけるＡＰＩ課金管理方法であって、ＡＰＩ管理装置が、アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付ステップと、アプリケーションから、一のＡＰＩへのリクエストを受信する受信ステップと、リクエストに応じたレスポンスを、アプリケーションへ送信する送信ステップと、一のＡＰＩを利用する複数のアプリケーション毎に、一のＡＰＩへのリクエスト及びレスポンスの履歴を記憶する履歴記憶ステップと、を含み、課金管理装置が、一のＡＰＩを利用する複数のアプリケーション毎に、受付ステップで受け付けられた、一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶ステップと、履歴記憶ステップによって記憶された、履歴に関する情報を取得する取得ステップと、課金条件及び履歴に関する情報に基づき、一のＡＰＩを利用するアプリケーションへの課金値を決定する決定ステップと、を含み、決定ステップは、一のＡＰＩを利用する、履歴が同一の少なくとも２のアプリケーションに対し、課金条件に応じて、異なる値の課金値を決定する。
【００１２】
本発明の一実施形態によるＡＰＩ課金プログラムは、ＡＰＩ課金システムに含まれる、複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置が実行するＡＰＩ課金プログラムであって、ＡＰＩ管理装置に、アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付機能と、アプリケーションから、一のＡＰＩへのリクエストを受信する受信機能と、リクエストに応じたレスポンスを、アプリケーションへ送信する送信機能と、一のＡＰＩを利用する複数のアプリケーション毎に、一のＡＰＩへのリクエスト及びレスポンスの履歴を記憶する履歴記憶機能と、を実現させ、課金管理装置に、一のＡＰＩを利用する複数のアプリケーション毎に、受付機能で受け付けられた、一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶機能と、履歴記憶機能によって記憶された、履歴に関する情報を取得する取得機能と、課金条件及び履歴に関する情報に基づき、一のＡＰＩを利用するアプリケーションへの課金値を決定する決定機能と、を実現させ、決定機能は、一のＡＰＩを利用する、履歴が同一の少なくとも２のアプリケーションに対し、課金条件に応じて、異なる値の課金値を決定する。
【発明の効果】
【００１３】
本発明によれば、同一のＡＰＩであっても、利用側に応じて柔軟に課金量を変化させることのできるＡＰＩ課金システム、ＡＰＩ課金管理方法、及び、ＡＰＩ課金プログラムを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態によるＡＰＩ課金システム構成の概略図である。
【図２】本発明の一実施形態によるＡＰＩ管理装置、課金管理装置のブロック図の一例である。
【図３】本発明の一実施形態による、ＡＰＩリクエスト・レスポンスについての説明図である。
【図４】本発明の一実施形態による、ＡＰＩリクエスト・レスポンスについての説明図である。
【図５】本発明の一実施形態による、課金プランの種類についての説明図である。
【図６】本発明の一実施形態による、ＡＰＩ課金システムの概要についての説明図である。
【図７】本発明の一実施形態による、課金条件テーブルの一例を示す図である。
【図８】本発明の一実施形態による、ＡＰＩ利用履歴テーブルの一例を示す図である。
【図９】本発明の一実施形態による、アラート種別の説明図である。
【図１０】本発明の一実施形態による、ＡＰＩ課金管理方法のフローチャートの一例である。
【図１１】本発明の一実施形態による、ＡＰＩ課金システムのシーケンス図の一例である。
【発明を実施するための形態】
【００１５】
以下、諸図面を参照しながら、本発明の一実施形態を詳細に説明する。図１は、本発明の一実施形態によるＡＰＩ課金システム構成の概略図である。図１に示すように、ＡＰＩ課金システム５００は、ＡＰＩ管理装置１００と、課金管理装置２００と、複数の各種プラットフォーム３００Ａ，３００Ｂ，３００Ｃと、個人又は法人の顧客（開発者アプリケーション）４００Ａ，４００Ｂとを少なくとも含む。プラットフォーム３００Ａ〜３００Ｃは、ＡＰＩの提供側が提供する既存のアプリケーションについてのプラットフォームである。ＡＰＩ管理装置１００は、複数のプラットフォーム３００Ａ〜３００Ｃ毎のＡＰＩを管理する。すなわち、ＡＰＩ管理装置１００は、既存アプリケーションの提供側が所有するシステムや、情報等のリソースにアクセスするためのＡＰＩを取りまとめ、一元管理するためのゲートウェイシステムである。ＡＰＩ管理装置１００は、ネットワークＮＥＴを介して各種プラットフォーム３００Ａ，３００Ｂ，３００Ｃと相互通信可能に接続される。ネットワークＮＥＴは、例えば、無線ネットワークや有線ネットワークである。具体的には、ネットワークＮＥＴは、有線ＬＡＮ、ワイヤレスＬＡＮ（ｗｉｒｅｌｅｓｓ  ＬＡＮ：ＷＬＡＮ）や広域ネットワーク（ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ：ＷＡＮ）、ＩＳＤＮｓ（ｉｎｔｅｇｒａｔｅｄ  ｓｅｒｖｉｃｅ  ｄｉｇｉｔａｌ  ｎｅｔｗｏｒｋｓ）、無線ＬＡＮｓ、ＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ−Ａｄｖａｎｃｅｄ、第４世代（４Ｇ）、第５世代（５Ｇ）、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などである。なお、なお、ＡＰＩ管理装置１００は、図１では１つ示してあるが、より多くのサーバ群として実現されてもよいし、単独で実現されてもよい。
【００１６】
開発者アプリケーション４００Ａ，４００Ｂは、ＡＰＩの提供側が提供する既存のアプリケーションを利用する、顧客のアプリケーションである。ＡＰＩ管理装置１００は、開発者アプリケーション４００Ａ，４００Ｂからの、既存アプリケーションの利用申請や、顧客情報等の管理などを行う。なお、図では、プラットフォーム３００Ａ〜３００Ｃ、開発者アプリケーション４００Ａ，４００Ｂをそれぞれ３つ、４つ示してあるが、これ以上存在してもよいことは言うまでもない。また、これ以降、特に区別する必要がない場合、これらをプラットフォーム３００、開発者アプリケーション４００と総称する。
【００１７】
課金管理装置２００は、ＡＰＩを利用する開発者アプリケーション４００に対する課金を管理する。なお、ＡＰＩ管理装置１００と課金管理装置２００とは、ネットワークＮＥＴを介して接続され、課金に関する情報等を互いにやり取りしてもよい。または、社内ＬＡＮや専用のＬＡＮネットワークで接続されていてもよい。
【００１８】
図２は、本発明の一実施形態によるＡＰＩ管理装置１００及び課金管理装置２００のブロック図である。まず、ＡＰＩ管理装置１００について説明する。
【００１９】
図２に示すように、ＡＰＩ管理装置１００は、制御部１１０、通信Ｉ／Ｆ（インタフェース）部１２０及び記憶部１３０を備える。制御部１１０は、ＡＰＩ管理装置１００の各部を制御する機能を有するプロセッサである。制御部１１０は、送受信部１１１、ＡＰＩ受信部１１２、ＡＰＩ送信部１１３、受付部１１４、判定部１１５、解析部１１６及びアラート作成部１１７を少なくとも備える。
【００２０】
送受信部１１１は、通信Ｉ／Ｆ部１２０を介した、ＡＰＩ管理装置１００と開発者アプリケーション４００、プラットフォーム３００等の外部装置との間の各種情報の送受信（やり取り）を制御する。例えば、送受信部１１１は、開発者アプリケーション４００から、一のＡＰＩを利用する際の課金条件の選択を受け付ける。本発明の一実施形態によれば、一のＡＰＩに対して、複数種類の課金条件が設定されており、開発者アプリケーション４００側（アプリケーションの利用側）毎に異なる課金条件を設定することができる。このことを、図５を用いて説明する。
【００２１】
図５に示すように、あるＡＰＩに対して、課金条件は、「リクエスト数課金」、「データ量課金」、及び、「リクエスト数課金＋データ量課金」で大別される。「リクエスト数課金」とは、ＡＰＩの利用リクエスト数に応じて課金される条件である。「データ量課金」とは、ＡＰＩの利用リクエスト、及び、当該リクエストに対するレスポンスにおけるデータ量に応じて課金される条件である。さらに、「リクエスト数課金＋データ量課金」は、それらの組み合わせである。そして「リクエスト数課金」において、「リクエスト成功のみ」、又は、「リクエスト成功／失敗」の別がある。「リクエスト成功のみ」とは、ＡＰＩの利用リクエストが成功した場合のみ課金され、リクエストが失敗した場合には課金されない条件である。対し、「リクエスト成功／失敗」とは、ＡＰＩのリクエストの成否に関わらず、課金される条件である。「リクエスト数課金＋データ量課金」については、上記の組み合わせとなる。そして、各条件において、料金の徴収が「定額課金」であるか「従量課金」であるかを選択可能である。ＡＰＩ管理装置１００の受付部１１４は、開発者アプリケーション４００から、既存アプリケーションの利用申請とともに、課金条件の選択を受け付ける。
【００２２】
ここで、ＡＰＩリクエスト・レスポンスについて、図３を用いて説明する。ＡＰＩ受信部１１２は、開発者アプリケーション４００から、一のＡＰＩへのリクエストを受信する。図３に示すように、ＡＰＩリクエスト１０は、開発者アプリケーション４００からＡＰＩ管理装置１００へ送信される。ＡＰＩ管理装置１００のＡＰＩ送信部１１３は、ＡＰＩリクエストを、ＡＰＩリクエストの内容に応じて、プラットフォーム３００へ送信する。そして、ＡＰＩ送信部１１３は、プラットフォーム３００から送信されたＡＰＩレスポンス１１を、開発者アプリケーション４００へ送信する。ＡＰＩリクエスト１０、ＡＰＩレスポンス１１は、ＨＴＴＰ形式で送信される。ＡＰＩ管理装置１００の解析部１１６は、ＡＰＩレスポンスを解析し、リクエストの成功・失敗を判定する。例えば、解析部１１６は、レスポンス１１のステータスコードが「２００」番台であれば、リクエストが成功したと判定する。また、解析部１１６は、レスポンス１１のステータスコードが「４００」番台であれば、リクエストが失敗したと判定する。
【００２３】
さらに、解析部１１６は、ＡＰＩリクエスト１０及びＡＰＩレスポンス１１の内容を解析し、パケットデータのメッセージ本体におけるデータ量を求める。本発明の一実施形態によれば、データ量に応じた課金の際に、メッセージ本体のうち、本体部分のみのデータ量を課金対象とし、ヘッダ部分のデータ量を課金対象としなくてもよい。これにより、より顧客の要望に則したサービスを提供できる。なお、ＡＰＩ管理装置１００の判定部１１５は、各種判定処理を行う。解析部１１６によって解析されたデータ量や、リクエストの成否に関する情報は、送受信部１１１によって、課金管理装置２００へ送信される。
【００２４】
記憶部１３０は、典型的には、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなど各種の記録媒体により実現され、ＡＰＩ管理装置１００が動作するうえで必要とする各種プログラム及びデータを記憶（格納）する機能を有する。記憶部１３０は、少なくとも、アプリケーション情報記憶部１３１、履歴記憶部１３２を含む。アプリケーション情報記憶部１３１は、開発者アプリケーション４００が利用する既存アプリケーションについての情報を記憶する。履歴記憶部１３２は、開発者アプリケーション４００が、ＡＰＩを介して既存アプリケーションを利用した際の履歴情報を記憶する。すなわち、履歴記憶部１３２は、一のＡＰＩを利用する複数のアプリケーション毎に、一のＡＰＩへのリクエスト及びレスポンスの履歴を記憶する。
【００２５】
判定部１１５は、各種判定処理を行う。また、アラート作成部１１７は、開発者アプリケーション４００の、ＡＰＩの利用頻度に応じた所定のアラートを作成する（詳細は後述する）。
【００２６】
次に、課金管理装置２００について説明する。課金管理装置２００は、制御部２１０、通信Ｉ／Ｆ部２２０、及び、記憶部２３０を少なくとも備える。制御部２１０は、課金管理装置２００の各部を制御する機能を有するプロセッサであり、取得部２１１、送受信部２１２、決定部２１３を少なくとも備える。取得部２１１は、ＡＰＩ管理装置１００の履歴記憶部１３２から、ＡＰＩリクエスト及びレスポンスについての履歴に関する情報を取得する。送受信部２１２は、通信Ｉ／Ｆ部２２０を介した、ＡＰＩ管理装置１００等の外部装置とのデータのやり取りを制御する。決定部２１３は、課金条件及び履歴に関する情報に基づき、一のＡＰＩを利用するアプリケーションへの課金値を決定する。
【００２７】
記憶部２３０は、典型的には、ＨＤＤ（Hard Disc Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなど各種の記録媒体により実現され、課金管理装置２００が動作するうえで必要とする各種プログラム及びデータを記憶（格納）する機能を有する。記憶部２３０は、少なくとも、課金条件記憶部２３１、アラート条件記憶部２３２を含む。課金条件記憶部２３１は、一のＡＰＩを利用する複数の開発者アプリケーション毎に、ＡＰＩ管理装置１００の受付部１１４で受け付けられた、一のＡＰＩを利用する際の課金条件を記憶する。課金条件の種別は、図５で説明した通りである。課金条件記憶部２３１に記憶される課金条件テーブルについて、図７を用いて説明する。図７に示すように、開発者アプリケーション毎に、利用するＡＰＩと、料金プランが、関連付けられて記憶される。そして、これらの情報は、顧客ごとにまとめられていてもよい。そして、図８に、履歴情報記憶部に記憶される履歴情報の一例を示す。図８に示すように、利用ＡＰＩのプラン毎に、リクエスト数や、データ量が記憶される。
【００２８】
ここで、図６を用いて、開発者アプリケーションによって課金条件が柔軟に設定される例について、概略を説明する。なお、図６における「プラン」は、図５のものに相当する。図６に示すように、顧客４００Ａは、アプリケーションＡ（アプリＡ）を、顧客４００Ｂは、アプリケーションＢ（アプリＢ）を開発しているとする。アプリＡ、アプリＢとも、既存アプリケーションとして「生体認証ＡＰＩ」、「ＩｏＴＡＰＩ」を利用する。ここで、アプリＡは、生体認証ＡＰＩを「プラン５」で利用するのに対し、アプリＢは、生体認証ＡＰＩを「プラン８」で利用する。そして、アプリＡは、ＩｏＴＡＰＩを「プラン１３」で利用するのに対し、アプリＢは、「プラン５」で利用する。
【００２９】
この様に、本発明の一実施形態によれば、同一のＡＰＩであっても、利用者のアプリケーションに応じて異なる課金条件を設定することができる。従って、ＡＰＩの提供者側にとっては、既存アプリケーションが利用される幅を広げ、効率的な課金を行うことができる。なお上述では、利用者のアプリケーション毎に異なるプランの課金条件を設定する例について説明したが、課金条件の設定が、顧客毎に設定されてもよい。すなわち、同一の顧客であれば、一のアプリケーション（例えば、「生体認証ＡＰＩ」）は、一のプランのみ利用できるように設定されてもよい。この様にすれば、課金管理をより簡単に行うことができる。
【００３０】
なお、課金条件に応じて、開発者アプリケーションへ所定のアラートが送信されてもよい。図９に、課金管理装置２００のアラート条件記憶部２３２に記憶された、アラート条件の一例を示す。本発明の一実施形態によれば、アプリ単位で料金が課金されるため、図９の種別６．に示すように、アプリ単位で料金が超過した場合に、アラートが送信されるように設定することができる。なお、アラートは、メールで送信されてもよいし、顧客毎の管理画面において、何らかの表示がなされるようにされてもよい。
【００３１】
次に、上述したＡＰＩ管理装置１００によるＡＰＩ課金管理方法について、図を用いて説明する。図１０は、ＡＰＩ管理装置１００によるＡＰＩ課金管理方法のフローチャートである。まず、記憶部１３０は、一のＡＰＩを利用する複数のアプリケーション毎に、一のＡＰＩを利用する際の課金条件を記憶する（ステップＳ１１）。具体的には、図７で示した課金条件テーブルが記憶される。次に、ＡＰＩ受信部１１２は、開発者アプリケーションから、一のＡＰＩへのリクエストを受信する（ステップＳ１２）。ＡＰＩ送信部１１３は、リクエストに応じたレスポンスを、開発者アプリケーションへ送信する（ステップＳ１３）。履歴記憶部１３２には、一のＡＰＩを利用する複数のアプリケーション毎に、一のＡＰＩへのリクエスト及びレスポンスの履歴が記憶される（ステップＳ１４）。取得部２１１は、履歴記憶部１３２から、履歴に関する情報を取得する（ステップＳ１５）。決定部２１３は、課金条件及び履歴に関する情報に基づき、一のＡＰＩを利用するアプリケーションへの課金値を決定する。その際、一のＡＰＩを利用するアプリケーションの間で、履歴情報が同一であっても（例えば、同じリクエスト数であっても）、課金条件が異なっていれば（例えば、リクエスト数による課金か、データ量による課金か等）、異なる課金値となる（ステップＳ１６）。
【００３２】
次に、ＡＰＩ管理装置１００と、課金管理装置２００と、プラットフォーム３００と、開発者アプリケーション４００によるＡＰＩ管理処理について説明する。図１１は、一実施形態における、ＡＰＩ管理装置１００と、課金管理装置２００と、プラットフォーム３００と、開発者アプリケーション４００によるＡＰＩ管理処理の流れを示すシーケンス図である。
【００３３】
開発者アプリケーション４００から、一のＡＰＩを利用する際の課金条件の選択が送信される（ステップＳ２１）。ＡＰＩ管理装置１００の受付部１１４は、課金条件の選択を受け付ける（ステップＳ２２）開発者アプリケーション４００は、一のＡＰＩへの利用リクエストを送信する（ステップＳ２３）。ＡＰＩ管理装置１００は、リクエストをプラットフォーム３００へ送信する（ステップＳ２４）。プラットフォーム３００は、リクエストに応じたレスポンスを送信する（ステップＳ２５）。ＡＰＩ管理装置１００は、レスポンスを、開発者アプリケーションへ送信する（ステップＳ２６）。その後、履歴記憶部１３２は、一のＡＰＩへのリクエスト及びレスポンスの履歴を記憶する（ステップＳ２７）。課金管理装置２００は、履歴に関する情報を取得する（ステップＳ２８）。そして、課金管理装置２００は、課金条件及び履歴に関する情報に基づき、一のＡＰＩを利用するアプリケーションへの課金値を決定する（ステップＳ２９）。
【００３４】
このように、本発明の一実施形態によれば、ＡＰＩの提供側は、利用者側のアプリケーション毎に、同一のＡＰＩでも、異なる課金条件を設定することができる。従って、利用者側のアプリケーションの内容に応じて、柔軟にＡＰＩを提供することができる。例えば、既存アプリケーションが、データの提供を目的とするものであった場合、より多くのデータを抜き取るアプリケーションに対しては、データ量に応じた課金とし、そうでないアプリケーションに対しては、リクエスト数に応じた課金等にすることができる。また、本発明の一実施形態によれば、既存アプリケーションの内容に応じて、課金条件を変化させることができる。例えば、利用者側のアプリケーションが、所定のデータベースからデータを取得するものであった場合、リクエストは無課金とし、レスポンス（データの取得）に課金することができる。これにより、データの取得を目的とする利用者側のニーズにこたえることができる。
【００３５】
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を容易に行えることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。また、上記実施の形態に示す構成を適宜組み合わせることとしてもよい。例えば、ＡＰＩ管理装置１００又は課金管理装置２００として区別して説明した機能は、ＡＰＩ管理装置１００のみにによって行われても良い。また、ＡＰＩ管理装置１００が備えるとして説明した各構成部は、複数の情報処理装置によって分散されて実現されてもよい。
【００３６】
また、本発明に係る発明の一実施形態を説明したが、本発明はこれに限られないことは言うまでもない。例えば、上述において、ＡＰＩ管理装置１００の記憶部１３０や、課金管理装置２００の記憶部２３０に記憶されると説明した各種情報は、ＡＰＩ管理装置１００とは別の外部メモリや、クラウド上に記憶されてもよいし、どちらかの記憶部に集約されていてもよい。また、図７、図８で示したテーブルは一例であって、記憶される情報が図示したものに限られる訳ではない。
【００３７】
また、上述では、アプリケーション毎に図５に示す課金条件を説明したが、アプリケーションによっては、データ量のみの課金であったり、リクエスト数のみの課金であったりしてもよい。また、課金における基本値（基本料金や、１リクエスト当たりの課金値等）は、アプリケーション毎に同一であってもよいし、顧客に応じて異ならせてもよい。
【００３８】
なお、課金値は都度計算され、課金値に関する情報は、ＡＰＩ管理装置１００へと渡されてもよい。ＡＰＩ管理装置１００は、顧客から課金値の閲覧要求があれば、現在の課金値情報を、テキスト、グラフ等で顧客が閲覧可能に制御する。なお、例えば日毎の課金値が小数点以下の値を含む場合、日毎の課金値は小数点以下の値を含まずに顧客に閲覧可能にし、例えば月毎の所定期間における課金値の徴収時に、小数点以下の累積値を含めて課金値が算出されてもよい。
【００３９】
また、ネットワークＮＥＴは、上述の例に限られず、例えば、公衆交換電話網（Ｐｕｂｌｉｃ  Ｓｗｉｔｃｈｅｄ  Ｔｅｌｅｐｈｏｎｅ  Ｎｅｔｗｏｒｋ：ＰＳＴＮ）やブルートゥース（Ｂｌｕｅｔｏｏｔｈ（登録商標））、光回線、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）回線、衛星通信などであってもよく、どのようなネットワークであってもよい。また、ネットワークＮＥＴは、これらの組み合わせであってもよい。
【００４０】
なお、上述では、顧客の選択によって課金条件が設定される態様について説明したが、制御部１１０が、顧客アプリケーションの内容に応じて、適切な課金条件を設定してもよい。例えば、人工知能（ＡＩ：Artificial Intelligence）を用いて、顧客の情報（規模、開発済のアプリケーション等）に応じて課金が設定されてもよい。なお、課金条件は変更されてもよい。
【００４１】
ＡＰＩ管理装置１００の各機能部は、集積回路（ＩＣ（Integrated Circuit）チップ、ＬＳＩ（Large Scale Integration））等に形成された論理回路（ハードウェア）や専用回路によって実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェアによって実現してもよい。また、各機能部は、１または複数の集積回路により実現されてよく、複数の機能部の機能を１つの集積回路により実現されることとしてもよい。さらに、上述したＡＰＩ管理装置１００は、複数のサーバコンピュータで実現してもよいし、機能によっては、外部のプラットフォーム等をＡＰＩ等で呼び出して実現してもよい。
【００４２】
ＡＰＩ管理装置１００の各機能部をソフトウェアにより実現する場合、ＡＰＩ管理装置１００または課金管理装置２００は、各機能を実現するソフトウェアであるプログラムの命令を実行するＣＰＵ、上記プログラム及び各種データがコンピュータ（またはＣＰＵ）で読み取り可能に記録されたＲＯＭ（Read Only Memory）または記憶装置（これらを「記録媒体」と称する）、上記プログラムを展開するＲＡＭ（Random Access Memory）などを備えている。そして、コンピュータ（またはＣＰＵ）が上記プログラムを上記記録媒体から読み取って実行することにより、本発明の目的が達成される。すなわち、本発明に係るＡＰＩ管理装置１００は、ＣＰＵがＲＡＭ上にロードされたプログラムを実行することにより、送受信部１１１、ＡＰＩ受信部１１２、ＡＰＩ送信部１１３、受付部１１４、判定部１１５、解析部１１６及びアラート作成部１１７として機能する。上記記録媒体としては、「一時的でない有形の媒体」、例えば、半導体メモリ、プログラマブルな論理回路などを用いることができる。また、上記プログラムは、当該プログラムを伝送可能な任意の伝送媒体（通信ネットワークや放送波等）を介して上記コンピュータに供給されてもよい。本発明は、上記プログラムが電子的な伝送によって具現化された、搬送波に埋め込まれたデータ信号の形態でも実現され得る。
【００４３】
なお、上記プログラムは、例えば、ActionScript、JavaScript（登録商標）、Python、Rubyなどのスクリプト言語、C言語、C＋＋、C＃、Objective-C、Swift、Java（登録商標）などのオブジェクト指向プログラミング言語、HTML5などのマークアップ言語などを用いて実装できる。さらに、特許請求の範囲における「部（section、module、unit）」との記載は、「手段」や「回路」に読み替えてもよい。例えば、受信部は、受信手段や受信回路に読み替えることができる。
【符号の説明】
【００４４】
５００  課金システム
１００  ＡＰＩ管理装置
２００  課金管理装置
３００Ａ，３００Ｂ，３００Ｃ  プラットフォーム
４００Ａ，４００Ｂ  開発者アプリケーション（顧客）
１１０  制御部
１２０  部
１３０  記憶部
１１１  送受信部
１１２  ＡＰＩ受信部
１１３  ＡＰＩ送信部
１１４  受付部
１１５  判定部
１１６  解析部
１１７  アラート作成部
１０  リクエスト
１１  レスポンス
１３１  アプリケーション情報記憶部
１３２  履歴記憶部
２１０  制御部
２３０  記憶部
２１１  取得部
２１２  送受信部
２１３  決定部
２３１  課金条件記憶部
２３２  アラート条件記憶部
【図１】
2019096060.tif 000003
【図２】
2019096060.tif 000004
【図３】
2019096060.tif 000005
【図４】
2019096060.tif 000006
【図５】
2019096060.tif 000007
【図６】
2019096060.tif 000008
【図７】
2019096060.tif 000009
【図８】
2019096060.tif 000010
【図９】
2019096060.tif 000011
【図１０】
2019096060.tif 000012
【図１１】
2019096060.tif 000013
【手続補正書】
【提出日】平成31年1月18日(2019.1.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、前記ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置と、を少なくとも含むＡＰＩ課金システムであって、
前記ＡＰＩ管理装置は、
前記アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付部と、
前記アプリケーションから、一のＡＰＩへのリクエストを受信する受信部と、
前記リクエストに応じたレスポンスを、前記アプリケーションへ送信する送信部と、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記一のＡＰＩへの前記リクエスト及び前記レスポンスの履歴を記憶する履歴記憶部と、を備え、
前記課金管理装置は、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記受付部で受け付けられた、前記一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶部と、
前記履歴記憶部から、前記履歴に関する情報を取得する取得部と、
前記課金条件及び前記履歴に関する情報に基づき、前記一のＡＰＩを利用するアプリケーションへの課金値を決定する決定部であって、前記一のＡＰＩを利用する、前記履歴が同一の少なくとも２のアプリケーションに対し、前記課金条件に応じて、異なる値の課金値を決定する決定部と、を備え、
前記複数のプラットフォーム毎のＡＰＩのうち複数のＡＰＩを利用する一のアプリケーションにおいて、当該複数のＡＰＩ毎に異なる課金条件を設定可能である、ＡＰＩ課金システム。
【請求項２】
前記課金条件記憶部は、前記リクエストの成否に応じた課金の有無を、前記課金条件として記憶し、
前記送信部は、前記レスポンスを、ＨＴＴＰステータスコードで前記アプリケーションへ送信し、
前記決定部は、前記ＨＴＴＰステータスコードに応じて前記リクエストの成否を判定し、前記課金値を決定する、
ことを特徴とする請求項１に記載のＡＰＩ課金システム。
【請求項３】
前記課金条件記憶部は、前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記リクエストのデータ量、及び、前記レスポンスのデータ量の少なくともいずれか１つに応じた課金値を、前記課金条件として記憶し、
前記決定部は、（１）前記リクエストのデータ量、及び、前記レスポンスのデータ量、（２）前記リクエストのデータ量、並びに、（３）前記レスポンスのデータ量の（１）〜（３）の少なくともいずれか１つに応じ、前記課金値を決定する、
ことを特徴とする請求項１または２に記載のＡＰＩ課金システム。
【請求項４】
前記決定部は、前記リクエスト及び前記レスポンスのパケットデータのうち、メッセージボディに関するデータ量に応じて、前記課金値を決定する、
ことを特徴とする請求項３に記載のＡＰＩ課金システム。
【請求項５】
前記課金条件記憶部は、前記一のＡＰＩを利用する前記アプリケーションを提供するクライアント毎に、異なる課金条件を記憶する、
ことを特徴とする請求項１〜４のいずれか一項に記載のＡＰＩ課金システム。
【請求項６】
前記ＡＰＩ管理装置に、前記課金条件に応じて、前記アプリケーションへ所定のアラートを送信するアラート作成部をさらに実現させる、
ことを特徴とする請求項１〜５のいずれか一項に記載のＡＰＩ課金システム。
【請求項７】
前記ＡＰＩ管理装置は、前記アプリケーションの内容に応じて前記課金条件を設定する、
ことを特徴とする請求項１〜６のいずれか一項に記載のＡＰＩ課金システム。
【請求項８】
複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、前記ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置と、を少なくとも含むＡＰＩ課金システムにおけるＡＰＩ課金管理方法であって、
前記ＡＰＩ管理装置が、
前記アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付ステップと、
前記アプリケーションから、一のＡＰＩへのリクエストを受信する受信ステップと、
前記リクエストに応じたレスポンスを、前記アプリケーションへ送信する送信ステップと、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記一のＡＰＩへの前記リクエスト及び前記レスポンスの履歴を記憶する履歴記憶ステップと、を含み、
前記課金管理装置が、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記受付ステップで受け付けられた、前記一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶ステップと、
前記履歴記憶ステップによって記憶された、前記履歴に関する情報を取得する取得ステップと、
前記課金条件及び前記履歴に関する情報に基づき、前記一のＡＰＩを利用するアプリケーションへの課金値を決定する決定ステップであって、前記一のＡＰＩを利用する、前記履歴が同一の少なくとも２のアプリケーションに対し、前記課金条件に応じて、異なる値の課金値を決定する決定ステップと、を含み、
前記複数のプラットフォーム毎のＡＰＩのうち複数のＡＰＩを利用する一のアプリケーションにおいて、当該複数のＡＰＩ毎に異なる課金条件を設定可能である、ＡＰＩ課金管理方法。
【請求項９】
ＡＰＩ課金システムに含まれる、複数のプラットフォーム毎のＡＰＩを管理するＡＰＩ管理装置と、前記ＡＰＩを利用するアプリケーションに対する課金を管理する課金管理装置が実行するＡＰＩ課金プログラムであって、
前記ＡＰＩ管理装置に、
前記アプリケーションから、一のＡＰＩを利用する際の課金条件の選択を受け付ける受付機能と、
前記アプリケーションから、一のＡＰＩへのリクエストを受信する受信機能と、
前記リクエストに応じたレスポンスを、前記アプリケーションへ送信する送信機能と、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記一のＡＰＩへの前記リクエスト及び前記レスポンスの履歴を記憶する履歴記憶機能と、を実現させ、
前記課金管理装置に、
前記一のＡＰＩを利用する複数の前記アプリケーション毎に、前記受付機能で受け付けられた、前記一のＡＰＩを利用する際の課金条件を記憶する課金条件記憶機能と、
前記履歴記憶機能によって記憶された、前記履歴に関する情報を取得する取得機能と、
前記課金条件及び前記履歴に関する情報に基づき、前記一のＡＰＩを利用するアプリケーションへの課金値を決定する決定機能であって、前記一のＡＰＩを利用する、前記履歴が同一の少なくとも２のアプリケーションに対し、前記課金条件に応じて、異なる値の課金値を決定する決定機能と、を実現させ、
前記複数のプラットフォーム毎のＡＰＩのうち複数のＡＰＩを利用する一のアプリケーションにおいて、当該複数のＡＰＩ毎に異なる課金条件を設定可能である、ＡＰＩ課金プログラム。