JP2015049905A - 決済サービス方法、決済サービスシステムおよびプログラム - Google Patents

Abstract

【課題】決済サービス方法およびシステムを提供する。
【解決手段】複数のサービスに対し、サービス毎に商品を商品データベースに登録および保持し４１０、ユーザから商品購買が要請されたサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）呼び出しに応じ、要請された商品のビリング（ｂｉｌｌｉｎｇ）情報を、商品データベースを利用して生成し４２０、ユーザと関連するマーケットにビリング情報を提供する４３０を含む。マーケットでビリング情報に基づいて商品購買による決済を処理する。
【選択図】図４

Description

本発明は、決済サービス方法およびシステムに関する。

ゲームやアプリケーションなどを通じて提供されるサービスでは、サービスに応じて様々な方式の決済（ｐａｙｍｅｎｔ）処理を必要とする。例えば、サービスを通じてアイテム、サイバマネー、クーポン、情報提供などの様々な形態の商品が販売されるが、ユーザが商品を購買した場合、ユーザの商品購買に応じた様々な方式の決済が処理されなければならない。

図１は、従来技術において、商品の決済過程を示した図である。図１は、モバイル端末機１１０、アプリケーション１２０、サービスサーバ１３０、複数のマーケット１４０、および複数の決済サービス１５０を示している。ユーザはモバイル端末機１１０にインストールされたアプリケーション１２０を通じてサービスサーバ１３０と通信してサービスの提供を受けてもよく、サービスを通じて提供される商品を購買してもよい。このとき、従来技術では、複数のサービスそれぞれに別途の決済システムが構築されなければならず、それぞれ別途の決済サービスが提供されなければならない。図１では、複数のマーケット１４０のうちでユーザと関連する第３マーケット、そして複数の決済サービス１５０のうちでアプリケーション１２０のために別途で構築および提供される第１決済サービスとの連携により、ユーザが購買しようとする商品の決済が処理されることを示している。これだけでなく、決済の管理とは、提供しようとするアイテムやサービスのような商品の管理、商品販売情報管理、個別決済に関するトランザクション（ｔｒａｎｓａｃｔｉｏｎ）管理、マーケット管理、商品配送、決済検証、決済情報管理、決済限度、または決済同意確認などのように非常に複雑なプロセスをすべて管理しなければならないことを意味するため、サービスの提供において極めて大きい部分を占める。

従来技術では、個別サービスの開発者はこのような決済のためのシステムを直接に構築して決済サービスを提供しなければならないため、提供しようとするサービスの開発だけに集中することができないという問題がある。

様々なサービスに対し、決済と関連するプロセスを統合的に処理することができる決済システムを構築し、開発者に決済のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供し、サービス毎に別途の決済システムを構築しなくても、そのサービスでＡＰＩ呼び出し（ｃａｌｌ）によってサービスにおける商品決済を簡単に処理することができる決済サービス方法およびシステムを提供することを目的とする。

決済サービスの提供のためにコンピュータで実現される決済サービス方法であって、複数のサービスに対し、サービス別に商品を商品データベースに登録および保持し、ユーザから商品購買が要請されたサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）呼び出しに応じ、要請された商品のビリング（ｂｉｌｌｉｎｇ）情報を前記商品データベースを利用して生成し、前記ユーザと関連するマーケットに前記ビリング情報を提供することを含み、前記マーケットで前記ビリング情報に基づいて前記商品購買による決済が処理されることを特徴とする決済サービス方法が提供される。

一実施形態によると、前記決済サービス方法は、前記ビリング情報または前記マーケットで生成された決済情報を、前記サービスまたは前記ユーザと関連付けて決済履歴データベースに格納し、前記決済履歴データベースを利用して前記サービスまたは前記ユーザに関する決済精算情報を生成することをさらに含んでもよい。

他の一実施形態によると、前記決済サービス方法は、前記サービスの提供者または前記ユーザの要請に応じて前記決済精算情報を提供することをさらに含んでもよい。

決済サービスの提供のためにコンピュータで実現される決済サービス方法であって、商品に関する情報をユーザの端末機に提供し、前記ユーザの端末機から前記商品に関する購買要請を受信する段階、前記購買要請に応じて決済サービスサーバと関連するＡＰＩを呼び出し、前記ユーザと関連するマーケットで前記購買要請の処理に応じて生成される決済情報を受信することを含み、前記決済情報は、前記ＡＰＩの呼び出しに応じて前記決済サービスサーバで商品データベースを利用して生成されたビリング情報に基づき、前記マーケットで生成され、前記商品データベースには、複数のサービスに対してサービス別に商品が登録および保持されることを特徴とする決済サービス方法が提供される。

複数のサービスに対し、サービス毎に商品が登録および保持される商品データベースが格納されたストレージユニットと、少なくとも１つのプロセッサと、を備え、前記少なくとも１つのプロセッサは、ユーザから商品購買が要請されたサービスのＡＰＩ呼び出しに応じ、要請された商品のビリング情報を、前記商品データベースを利用して生成するプロセスと、前記ユーザと関連するマーケットで前記ビリング情報を提供するプロセスと、を処理し、前記マーケットで前記ビリング情報に基づいて前記商品購買に応じた決済が処理されることを特徴とする決済サービスシステムが提供される。

商品に関する情報を格納する少なくとも１つのストレージユニットと、少なくとも１つのプロセッサと、を備え、前記少なくとも１つのプロセッサは、前記少なくとも１つのストレージユニットに格納された商品に関する情報をユーザの端末機に提供するプロセスと、前記ユーザの端末機から前記商品に対する購買要請を受信するプロセスと、前記購買要請に応じて決済サービスサーバと関連するＡＰＩを呼び出すプロセスと、前記ユーザと関連するマーケットで前記購買要請の処理に応じて生成される決済情報を受信するプロセスと、を処理し、前記決済情報は、前記ＡＰＩの呼び出しに応じて前記決済サービスサーバで商品データベースを利用して生成されたビリング情報に基づき、前記マーケットで生成され、前記商品データベースには、複数のサービスに対してサービス毎に商品が登録および保持されることを特徴とする決済サービスシステムが提供される。

様々なサービスに対し、決済と関連するプロセスを統合的に処理することができる決済システムを構築し、開発者に決済のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供し、サービス毎に別途の決済システムを構築することなく、そのサービスでＡＰＩ呼び出し（ｃａｌｌ）によってサービスにおける商品決済を簡単に処理することができる。

従来技術において、商品の決済過程を示した図である。 本発明の一実施形態において、決済サービスシステムの概括的な様子を示した図である。 本発明の一実施形態において、決済過程の一例を説明するための図である。 本発明の一実施形態において、決済サービス方法を示したフローチャートである。 本発明の他の実施形態において、決済サービス方法を示したフローチャートである。

以下、本発明の実施形態について、添付の図面を参照しながら詳細に説明する。

図２は、本発明の一実施形態において、決済サービスシステムの概括的な様子を示した図である。図２は、決済サービスシステム２００、複数のモバイル端末機２１０、複数のサービスシステム（サーバ）２２０、および複数のマーケット２３０を示している。

決済サービスシステム２００は、様々なサービスに対して統合的に決済サービスを提供することができるサーバを意味する。一例として、決済サービスシステム２００は、様々な種類のゲームを提供する互いに異なるゲームサーバに決済サービスを提供してもよい。

複数のモバイル端末機２１０に提供されるサービスの開発者は、商品および決済関連情報を決済サービスシステム２００に提供する。決済サービスシステム２００は、複数のサービスに対し、サービス毎に商品を登録および保持してもよい。サービスにおいて決済が必要なイベントが発生したとき、決済サービスシステム２００の決済サービスを呼び出す（ｃａｌｌ）ことにより、決済サービスシステム２００で商品の決済が処理されてもよい。

したがって、開発者は、決済システムを別途で構築する必要なく、提供しようとするサービスと関連する決済を、決済サービスシステム２００を利用して処理することができるため、サービスの開発に必要な費用を減らすことができる。

図３は、本発明の一実施形態において、決済プロセスの一例を説明するための図である。図３は、複数のゲーム３１０、スマートプラットフォームクライアント３２０、決済サービスサーバ３３０、マーケットゲートウェイ３４０、および複数のマーケット３５０を示している。スマートプラットフォームクライアント３２０および決済サービスサーバ３３０は、図２を参照しながら説明した決済サービスシステム２００に含まれてもよい。

複数のゲーム３１０で決済のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）が呼び出されると、ＡＰＩの呼び出しに応じて、スマートプラットフォームクライアント３２０から決済サービスサーバ３３０に商品の決済を要請してもよい。例えば、ゲームに関するサービスの提供を受けるユーザが商品への購買意思をゲームサーバに伝達すると、ゲームサーバは提供されたＡＰＩを利用してスマートプラットフォームクライアント３２０を呼び出し、スマートプラットフォームクライアント３２０の要請に応じて決済サービスサーバ３３０で商品の決済が処理されてもよい。

決済サービスサーバ３３０は、一例として、次の（１）ないし（５）のようなモジュールを備えてもよい。

（１）「登録販売管理」モジュール：商品を登録し、商品販売情報を管理。
（２）「商品情報管理」モジュール：商品情報を管理し、商品の配送および未配送を処理。
（３）「サービス管理」モジュール：サービス、サービスの商品、マーケットに関する情報を互いに関連付けて管理し、決済クレームと決済サービスの運営を管理。
（４）「決済情報管理」モジュール：個別決済およびビリング（ｂｉｌｌｉｎｇ）管理、領収証の送信、決済情報の事後管理および決済限度、およびユーザの同意可否などの確認。
（５）「決済および注文」モジュール：（１）ないし（４）のモジュールと相互作用して、スマートプラットフォームクライアント３２０から要請する商品の決済を処理。

決済サービスサーバ３３０は、マーケットゲートウェイ３４０を通じ、複数のマーケット３５０のうち、要請された商品の決済と関連するマーケットに接続してビリングを処理することにより、要請された商品の決済が行われるように処理してもよい。

このように、本発明の実施形態によると、サービスの特性やアイテム、サイバマネー、クーポンなどのように様々な形態で提供される商品の統合的な決済を支援することにより、サービスの開発者が別途の決済機能を実現する必要がなく、サービスの開発だけに集中できるように支援することができる。例えば、ゲーム開発者は、商品の決済と関連する処理を、提供されたＡＰＩ呼び出しによって処理することができるため、ゲームの開発だけに集中することができる。

また、セキュリティやマーケット毎のポリシー、商品に関する顧客サービス（一例として、アイテムに関する決済ヒストリ情報の提供）、クレーム処理、および仲裁なども、本発明の実施形態に係る決済サービスの提供者側で処理することができる。

さらに、サービス毎に商品情報が管理されないと、サービス毎にビリングと決済が提供されるだけで、商品情報に対するビュー（ｖｉｅｗ）を提供するのが困難になる。この反面、本発明の実施形態に係る決済サービスでは、商品価格や商品の販売量などのような商品情報を決済サービスで直接管理するため、ビリングと連動する自動精算機能を個別サービスの提供者に提供することが可能となる。

図４は、本発明の一実施形態において、決済サービス方法を示したフローチャートである。本実施形態に係る決済サービス方法は、サービスサーバに決済機能を提供する決済サービスシステムによって実行される。

一例として、本実施形態の決済サービスシステムは、図２を参照しながら説明した決済サービスシステム２００に対応する。決済サービスシステムは、少なくとも１つのストレージユニットと少なくとも１つのプロセッサとを備える。決済サービス方法に含まれるステップのそれぞれは、決済サービスシステムまたは決済サービスシステムが含む少なくとも１つのプロセッサによって実行されてもよい。図４では、決済サービスシステムがそれぞれのステップを実行する実施形態を説明する。

ステップ４１０において、決済サービスシステムは、複数のサービスに対し、サービス毎に商品を商品データベースに登録および保持する。このとき、商品データベースは、少なくとも１つのストレージユニットに格納されてもよい。なお、決済サービスシステムは、マーケットに関する情報をさらに保持してもよい。マーケットに関する情報は、別途のデータベースを利用して格納および保持されてもよく、または商品データベースで商品と関連付けて格納および保持されてもよい。

ステップ４２０において、決済サービスシステムは、ユーザから商品購買が要請されたサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）呼び出しに応じ、要請された商品のビリング（ｂｉｌｌｉｎｇ）情報を、上述した商品データベースを利用して生成する。上述したように、サービスの開発者は、別途の決済サービス機能を構築する必要がなく、決済サービスシステムを利用して提供する決済機能をＡＰＩ呼び出しによって提供されてもよい。このとき、決済サービスシステムは、商品データベースを利用して、要請された商品の決済のためのビリング情報を生成してもよい。

ステップ４３０において、決済サービスシステムは、ユーザと関連するマーケットにビリング情報を提供する。このとき、ユーザと関連するマーケットで、ビリング情報に基づいて商品購買による決済が処理されてもよい。処理された決済に関する情報は、決済サービスシステム、そしてユーザにサービスを提供するサービスサーバに提供されてもよい。

ステップ４４０ないしステップ４６０は、実施形態に応じて選択的に実行されてもよい。

ステップ４４０において、決済サービスシステムは、ビリング情報またはマーケットで生成された決済情報を、サービスまたはユーザと関連付けて決済履歴データベースに格納する。このとき、決済履歴データベースも、決済サービスシステムが備える少なくとも１つのストレージユニットに格納されてもよい。

ステップ４５０において、決済サービスシステムは、決済履歴データベースを利用してサービスまたはユーザに関する決済精算情報を生成する。

ステップ４６０において、決済サービスシステムは、サービスの提供者またはユーザの要請に応じて決済精算情報を提供する。上述したように、従来技術では、サービスの開発者が直接に決済機能を実現しなければならなかったため、決済情報やビリング情報がすべてサービスを提供するサービスサーバで管理されなければならない。この場合、決済精算情報を生成するためには、サービスの開発者が直接に精算機能を構築しなければならないという不便さがある。この反面、本実施形態によると、決済機能だけではなく、決済精算のための機能までも複数のサービスに統合的に支援されることができるため、開発者はサービスの開発だけに専念できるようになる。

図５は、本発明の他の実施形態において、決済サービス方法を示したフローチャートである。本実施形態に係る決済サービス方法は、ユーザの端末機にサービスを提供し、ユーザが購買しようとする商品の決済のために、図２を参照しながら説明した決済サービスシステム２００と通信するサービスサーバによって実行される。

本実施形態において、サービスサーバは、少なくとも１つのストレージユニットと少なくとも１つのプロセッサを備える。本実施形態の決済サービス方法が含むステップそれぞれは、サービスサーバまたはサービスサーバが備える少なくとも１つのプロセッサによって実行されてもよい。図５では、サービスサーバがそれぞれのステップを実行する実施形態について説明する。

ステップ５１０で、サービスサーバは、商品に関する情報をユーザの端末機に提供する。例えば、提供するサービスがゲームサービスである場合、ゲームサービスを提供するサービスサーバであるゲームサーバは、ゲームアイテムやサイバマネーのような商品に関する情報をユーザの端末機に提供してもよい。

ステップ５２０で、サービスサーバは、ユーザの端末機から商品に関する購買要請を受信する。上述した例において、商品に関する情報は、ユーザの端末機の画面に表示されてもよい。ユーザは表示された商品のうちから少なくとも１つを選択して購買を要請してもよく、サービスサーバはユーザの選択に応じて端末機から提供される購買要請を受信してもよい。

ステップ５３０で、サービスサーバは、購買要請に応じて決済サービスサーバと関連するＡＰＩを呼び出す。決済サービスサーバは、図２を参照しながら説明した決済サービスシステム２００に対応してもよい。決済サービスサーバは、複数のサービスを提供する複数のサービスサーバに決済機能を提供してもよい。このとき、サービスサーバそれぞれは、決済機能が必要な場合、ＡＰＩ呼び出しによって決済機能を利用してもよい。

この場合、決済サービスサーバは、ＡＰＩの呼び出しに応じて商品データベースを利用してビリング情報を生成し、生成されたビリング情報をユーザと関連するマーケットに提供してもよい。ここで、商品データベースには、複数のサービスに対してサービス毎に商品が登録および保持されてもよい。

マーケットは、ビリング情報を利用してユーザの購買要請に応じた商品の決済を処理し、決済情報を生成してサービスサーバと決済サービスサーバにそれぞれ提供してもよい。

ステップ５４０で、サービスサーバは、ユーザと関連するマーケットで購買要請の処理によって生成される決済情報を受信する。

このように、本発明の実施形態によれば、様々なサービスに対し、決済と関連するステップを統合的に処理することができる決済システムを構築し、開発者に決済のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を提供し、サービス毎に別途の決済システムを構築することなく、サービスでＡＰＩ呼び出し（ｃａｌｌ）によってサービスにおける商品決済を簡単に処理することができる。

上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素およびソフトウェア構成要素の組み合わせによって実現されてもよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ、ＦＰＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行して応答することができる他のデバイスのように、１つ以上の汎用コンピュータまたは特殊目的用のコンピュータを利用して実現されてもよい。処理装置は、Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してもよい。また、処理装置は、ソフトウェアの実行に応答し、データをアクセス、保存、操作、処理、および生成してもよい。理解の便宜のために、処理装置は１つが使用されると説明される場合もあるが、この技術分野において通常の知識を有する者は、処理装置が複数の処理要素（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ）および／または複数類型の処理要素を含んでもよい。例えば、処理装置は、複数のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでもよい。また、並列プロセッサ（ｐａｒａｌｌｅｌ ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成（ｐｒｏｃｅｓｓｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）も可能である。

ソフトウェアは、コンピュータプログラム（ｃｏｍｐｕｔｅｒ ｐｒｏｇｒａｍ）、コード（ｃｏｄｅ）、命令（ｉｎｓｔｒｕｃｔｉｏｎ）、またはこれらのうちの１つ以上の組み合わせを含んでもよく、所望どおりに動作するように処理装置を構成したり、独立的または結合的に（ｃｏｌｌｅｃｔｉｖｅｌｙ）処理装置を命令したりしてもよい。ソフトウェアおよび／またはデータは、処理装置によって解釈されたり処理装置に命令またはデータを提供したりするために、ある類型の機械、構成要素（ｃｏｍｐｏｎｅｎｔ）、物理的装置、仮想装置（ｖｉｒｔｕａｌ ｅｑｕｉｐｍｅｎｔ）、コンピュータ記録媒体または装置、または送信される信号波（ｓｉｇｎａｌ ｗａｖｅ）に永久的または一時的に具体化（ｅｍｂｏｄｙ）されてもよい。ソフトウェアは、ネットワークによって接続したコンピュータシステム上に分散し、分散した方法によって格納されたり実行されたりしてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてもよい。

実施形態に係る方法は、様々なコンピュータ手段によって実行が可能なプログラム命令形態で実現されてコンピュータで読み取り可能な媒体に記録されてもよい。コンピュータで読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独または組み合わせて含んでもよい。媒体に記録されるプログラム命令は、実施形態のために特別に設計されて構成されたものであってもよく、コンピュータソフトウェアの当業者に公知されて使用可能なものであってもよい。コンピュータで読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体（ｍａｇｎｅｔｉｃ ｍｅｄｉａ）、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体（ｏｐｔｉｃａｌ ｍｅｄｉａ）、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような磁気−光媒体（ｍａｇｎｅｔｏ−ｏｐｔｉｃａｌ ｍｅｄｉａ）、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を格納して実行するように特別に構成されたハードウェア装置が含まれる。プログラム命令の例としては、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。上述したハードウェア装置は、実施形態の動作を実行するために１つ以上のソフトウェアモジュールとして作動するように構成されてもよく、その逆も同じである。

以上のように、実施形態を限定された実施形態と図面に基づいて説明したが、該当する技術分野において通常の知識を有する者であれば、上述した記載から多様な修正および変形が可能であることが理解できるであろう。例えば、説明された技術が説明された方法とは異なる順序で実行されたり、および／または説明されたシステム、構造、装置、回路などの構成要素が説明された方法とは異なる形態で結合または組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

２００：決済サービスシステム

Claims (9)

1. 決済サービスの提供のためにコンピュータで実現される決済サービス方法であって、
   複数のサービスに対し、サービス毎に商品を商品データベースに登録および保持し、
   ユーザから商品購買が要請されたサービスのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）呼び出しに応じ、要請された商品のビリング（ｂｉｌｌｉｎｇ）情報を、前記商品データベースを利用して生成し、
   前記ユーザと関連するマーケットに前記ビリング情報を提供すること
   を含み、
   前記マーケットで前記ビリング情報に基づいて前記商品購買による決済が処理されることを特徴とする、決済サービス方法。
2. 前記ビリング情報または前記マーケットで生成された決済情報を、前記サービスまたは前記ユーザと関連付けて決済履歴データベースに格納し、
   前記決済履歴データベースを利用して前記サービスまたは前記ユーザに関する決済精算情報を生成することをさらに含む、請求項１に記載の決済サービス方法。
3. 前記サービスの提供者または前記ユーザの要請に応じて前記決済精算情報を提供することをさらに含む、請求項２に記載の決済サービス方法。
4. 決済サービスの提供のためにコンピュータで実現される決済サービス方法であって、
   商品に関する情報をユーザの端末機に提供し、
   前記ユーザの端末機から前記商品に対する購買要請を受信し、
   前記購買要請に応じて決済サービスサーバと関連するＡＰＩを呼び出し、
   前記ユーザと関連するマーケットで前記購買要請の処理によって生成される決済情報を受信すること
   を含み、
   前記決済情報は、前記ＡＰＩの呼び出しに応じて前記決済サービスサーバで商品データベースを利用して生成されたビリング情報に基づき、前記マーケットで生成され、
   前記商品データベースには、複数のサービスに対してサービス毎に商品が登録および保持されることを特徴とする、決済サービス方法。
5. 請求項１ないし請求項４のうちのいずれか一項の方法をコンピュータに実行させるためのプログラム。
6. 複数のサービスに対し、サービス毎に商品が登録および保持される商品データベースが格納されたストレージユニットと、
   少なくとも１つのプロセッサと、
   を含み、
   前記少なくとも１つのプロセッサは、
   ユーザから商品購買が要請されたサービスのＡＰＩ呼び出しに応じ、要請された商品のビリング情報を、前記商品データベースを利用して生成するプロセスと、
   前記ユーザと関連するマーケットに前記ビリング情報を提供するプロセスと、
   を処理し、
   前記マーケットで前記ビリング情報に基づいて前記商品購買による決済が処理されることを特徴とする、決済サービスシステム。
7. 前記ストレージユニットには、前記ビリング情報または前記マーケットで生成された決済情報を、前記サービスまたは前記ユーザと関連付けて格納および管理する決済履歴データベースがさらに格納され、
   前記少なくとも１つのプロセッサは、
   前記決済履歴データベースを利用して前記サービスまたは前記ユーザに関する決済精算情報を生成するプロセスをさらに処理することを特徴とする、請求項６に記載の決済サービスシステム。
8. 前記少なくとも１つのプロセッサは、
   前記サービスの提供者または前記ユーザの要請に応じて前記決済精算情報を提供するプロセスをさらに処理することを特徴とする、請求項７に記載の決済サービスシステム。
9. 商品に関する情報を格納する少なくとも１つのストレージユニットと、
   少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   前記少なくとも１つのストレージユニットに格納された商品に関する情報をユーザの端末機に提供するプロセスと、
   前記ユーザの端末機から前記商品に対する購買要請を受信するプロセスと、
   前記購買要請に応じて決済サービスサーバと関連するＡＰＩを呼び出すプロセスと、
   前記ユーザと関連するマーケットで前記購買要請の処理によって生成される決済情報を受信するプロセスと、
   を処理し、
   前記決済情報は、前記ＡＰＩの呼び出しに応じて前記決済サービスサーバで商品データベースを利用して生成されたビリング情報に基づき、前記マーケットで生成され、
   前記商品データベースには、複数のサービスに対してサービス毎に商品が登録および保持されることを特徴とする、決済サービスシステム。

Images