JP2020087263A - 決済システム及びそのコンピュータプログラム - Google Patents

Abstract

【課題】種々の決済サービスへの対応に要する負担を軽減する決済システムを提供する。【解決手段】決済端末４０が表示する情報画像１００に含まれた情報がユーザ端末６０を介してサーバ３０に提供されて決済処理が実行される決済システムにおいて、決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報ＩＦａが含まれるようにして情報画像１００を決済端末４０に表示させ、情報画像１００の必須情報ＩＦａをユーザ端末６０に取得させ、複数種類の決済手段から決済に用いられるべき決済手段をユーザ端末６０を介してユーザに選択させ、選択された決済手段を識別するための情報と必須情報ＩＦａとを含む決済情報ＩＦｂをユーザ端末６０からサーバ３０に送信させ、決済情報ＩＦｂに基づいて決済手段を識別させ、識別された決済手段に従って必須情報ＩＦａに応じた決済が行われるようにサーバ３０に決済処理を実行させる。【選択図】図５

Description

本発明は、二次元コード等の画像を利用して決済サービスを提供するシステム等に関する。

決済用の情報が埋め込まれた二次元コードを店舗等に設置された決済用の端末上に表示させ、その二次元コードの情報をユーザが所持する端末に読み取らせ、得られた情報をサーバに送信して決済処理を進めるシステムが知られている（例えば特許文献１参照）。

特開２０１６−１７３７５２号公報

二次元コード等の画像には種々の情報を含めることができるため、その種の画像を利用した情報のやり取りは種々の決済サービスに対応させることが可能である。しかしながら、一般に、二次元コード等の画像に含めるべき情報の種類、フォーマット等は決済サービスごとに独自に設定されている。したがって、新たな決済サービスを導入するためには、二次元コード等を発行する側の端末に新たなプログラムを導入し、あるいは新たな端末を導入するといった対応が必要となり、サービス端末側における作業や費用の負担が増す。

そこで、本発明は種々の決済サービスに対応するために要する負担を軽減することが可能な決済システム等を提供することを目的とする。

本発明の一態様に係る決済システムは、サーバ及び当該サーバに対するクライアントとして機能するユーザ端末及び決済端末を含んだクライアントサーバシステムとして構築され、前記決済端末にて提示される情報画像に含まれている決済処理に必要な情報が前記ユーザ端末を介して前記サーバに提供されることにより、ユーザが支払うべき料金を決済するための決済処理が前記サーバにて実行される決済システムであって、決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報が前記決済処理に必要な情報として含まれるようにして前記情報画像を前記決済端末に表示させる情報画像表示手段と、前記情報画像に含まれている前記必須情報を前記ユーザ端末に取得させる情報取得手段と、複数種類の決済手段から決済に用いられるべき決済手段を、前記ユーザ端末を介して前記ユーザに選択させ、選択された決済手段を識別するための決済手段識別情報と前記情報取得手段が取得した前記必須情報とを含む決済情報を前記ユーザ端末から前記サーバに送信させる決済情報提供手段と、前記サーバに、前記決済情報に含まれている前記決済手段識別情報に基づいて決済手段を識別させ、前記決済情報に含まれている前記必須情報に応じた決済が、識別された決済手段に従って行われるように前記決済処理を実行させる決済実行手段と、前記決済処理が実行された結果を示す結果情報を前記サーバから前記決済端末に送信させる結果情報提供手段と、を備えたものである。を備えたものである。

本発明の一態様に係るコンピュータプログラムは、サーバ及び当該サーバに対するクライアントとして機能するユーザ端末及び決済端末を含んだクライアントサーバシステムとして構築され、前記決済端末にて提示される情報画像に含まれている決済処理に必要な情報が前記ユーザ端末を介して前記サーバに提供されることにより、ユーザが支払うべき料金を決済するための決済処理が前記サーバにて実行される決済システムに適用されるコンピュータプログラムであって、前記決済システムに含まれたコンピュータを、決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報が前記決済処理に必要な情報として含まれるようにして前記情報画像を前記決済端末に表示させる情報画像表示手段、前記情報画像に含まれている前記必須情報を前記ユーザ端末に取得させる情報取得手段、複数種類の決済手段から決済に用いられるべき決済手段を、前記ユーザ端末を介して前記ユーザに選択させ、選択された決済手段を識別するための決済手段識別情報と前記情報取得手段が取得した前記必須情報とを含む決済情報を前記ユーザ端末から前記サーバに送信させる決済情報提供手段、前記サーバに、前記決済情報に含まれている前記決済手段識別情報に基づいて決済手段を識別させ、前記決済情報に含まれている前記必須情報に応じた決済が、識別された決済手段に従って行われるように前記決済処理を実行させる決済実行手段、及び前記決済処理が実行された結果を示す結果情報を前記サーバから前記決済端末に送信させる結果情報提供手段、として機能させるように構成されたものである。

本発明の第１の形態に係る決済システムの概略構成を示した図。 決済実行サーバが決済処理で用いる処理プログラムの一例としてのスクリプトの構造の一例を示す図。 図１の決済システムにて二次元コードが表示されるまでに行われるべき処理の概略例を示す図。 図１の決済システムにて二次元コードが表示された後に行われるべき処理の概略例を示す図。 図４の手順において、スクリプトに記述される情報が順次確定する様子を示す図。 図１の決済システムの具体例を示す図。 図６の決済システムにて二次元コードが表示されるまでに行われるべき処理の手順を示すフローチャート。 図６の決済システムにて二次元コードが表示された後に行われるべき処理の手順を示すフローチャート。 図８に続くフローチャート。 図５の変形例を示す図。 第２の形態に係る決済システムにて二次元コードが表示されるまでに行われるべき処理の概略例を示す図。 図１１の手順において、スクリプトに記述される情報が順次確定する様子を示す図。 第２の形態に係る決済システムにて二次元コードが表示されるまでに行われるべき処理の手順を示すフローチャート。 本発明の第３の形態に係る決済システムの概略構成を示した図。 図１４の決済システムにおいて、サービス端末からユーザ端末を経由して決済実行サーバへと情報が伝達される様子の一例を示す図。 図１４の決済システムの具体例を示す図。。 図１６の決済システムにて決済処理を実行するために行われる各種の処理の手順の一例を示すフローチャート。 売上を集計するための変形例を示す図。

（第１の形態）
以下、図１〜図９を参照して本発明の第１の形態を説明する。図１に示すように、第１の形態に係る決済システム１は、バックオフィスサーバ１０、スクリプト管理サーバ２０、及び決済実行サーバ３０と、これらのサーバ１０〜３０に対するクライアントとして機能するサービス端末４０、管理端末５０及びユーザ端末６０とをコンピュータの一例として含んでいる。また、決済システム１は、決済サービスに関連して口座管理サーバ７０、品目管理サーバ８０及びサービス管理サーバ９０と連携する。サーバ１０〜３０、７０〜９０、及び端末４０〜６０のそれぞれは不図示のネットワーク、一例としてインターネットに適宜に接続されることにより、相互間で情報を送信又は受信することが可能である。したがって、サービス端末４０、管理端末５０及びユーザ端末６０は、口座管理サーバ７０、品目管理サーバ８０、サービス管理サーバ９０のクライアントとしても適宜に機能してよい。

サービス端末４０は、ユーザに対して決済サービスを提供しようとする者（以下、これをサービス提供者と呼ぶ。）が商業施設等の管理領域ＳＡに設置し、運用する端末装置である。サービス端末４０は、決済サービスを提供するためにユーザ端末６０に読み取らせるべき情報画像の一例としての二次元コード１００を表示する機能を有している。決済システム１における決済サービスは、決済端末の一例としてのサービス端末４０に表示された二次元コード１００がユーザ端末６０にて読み取られ、その二次元コード１００に記録されている必須情報に所定の情報を付加した決済情報がユーザ端末６０から決済実行サーバ３０に送信されることによって進められる。決済処理の手順は後に詳しく説明する。

サービス端末４０には、一例として、ゲーム機４０Ａ、店頭端末４０Ｂ等の端末装置が含まれてよい。ゲーム機４０Ａは、所定の料金の支払いと引き換えにユーザにゲームをプレイさせる業務用のゲーム機の一例である。店頭端末４０Ｂは、例えばコンビニエンスストア等の店舗内に設置され、チケット等の各種の商品の販売、あるいは料金の収受といった各種のサービスを提供する端末装置の一例である。ゲーム機４０Ａ、及び店頭端末４０Ｂによってユーザに提供されるサービスは、決済システム１によって処理される決済サービスと関連付けてその適用が制御されるサービスであって、決済サービスとは区別されるべきものである。以下では、この種のサービスを関連サービスと称して決済サービスと区別することがある。

サービス端末４０は関連サービスを提供する例に限らない。例えば、店舗等でユーザが購入した商品を売上登録し、ユーザが支払うべき料金を計算するレジスター端末のように、決済サービスそれ自体をユーザに利用させる目的で設置され、関連サービスを提供しない端末がサービス端末４０として設けられてもよい。いわゆるＰＯＳ端末がサービス端末４０として設けられてもよい。その他にもサービス端末４０としては各種の端末装置が用いられてよい。ただし、サービス端末４０は二次元コード１００を表示するための表示装置を備えている必要がある。

管理端末５０は、決済サービスの管理、あるいは決済サービスに関する各種の設定等を目的として管理領域ＳＡに設けられる端末装置である。管理端末５０は、決済サービスを実現するために必要な情報をバックオフィスサーバ１０に提供する端末として利用可能である。管理端末５０としては、例えばブック型のパーソナルコンピュータ等の各種の端末装置が用いられてよい。ゲーム機４０Ａ、あるいは店頭端末４０Ｂ等のサービス端末４０が管理端末５０として兼用されてもよい。なお、管理領域ＳＡはサービス提供者が管理する領域を示す概念であって、一つのまとまった場所を必ずしも意味しない。例えば、サービス端末４０は店舗等に設置され、管理端末５０はサービス端末４０を運用するサービス提供者の事務所等に設置されてよい。

ユーザ端末６０は、ユーザの個人的用途に利用されるべき端末である。一例として、ネットワーク接続機能を備えたスマートフォンがユーザ端末６０として利用される。ユーザ端末６０はサービス端末４０上に表示された二次元コード１００を読み取り、その二次元コード１００に含まれた必須情報に対して所定の情報を付加して決済情報を生成し、得られた決済情報を決済実行サーバ３０に送信する。ユーザ端末６０としては、スマートフォンに限らず、ネットワーク接続機能を備え、かつサービス端末４０上に表示される二次元コード１００を読み取ることが可能であれば適宜の端末装置が用いられてよい。ユーザ端末６０は、サービス端末４０が設置された場所に携行して使用できる携行性を備えることが好ましい。

次に、各サーバについて順次説明する。バックオフィスサーバ１０、スクリプト管理サーバ２０及び決済実行サーバ３０は、決済サービスを提供するために必要な決済処理を実行し、あるいはその実行に必要な付随的な処理を担当するサーバとして設けられている。バックオフィスサーバ１０は、サービス端末４０及び管理端末５０とスクリプト管理サーバ２０との間を仲介するサーバとして設けられている。例えば、バックオフィスサーバ１０は、管理端末５０から取得した情報に基づいて、ユーザがユーザ端末６０を利用する際に支払うべき料金の支払条件を設定し、その支払条件の情報をスクリプト管理サーバ２０に通知する。また、バックオフィスサーバ１０は、スクリプト管理サーバ２０から二次元コード１００を発行するために必要な情報を取得してこれをサービス端末４０に提供する。

スクリプト管理サーバ２０は、バックオフィスサーバ１０が設定した支払条件に従って決済実行サーバ３０に決済処理を実行させるためのスクリプトを作成し、得られたスクリプトをスクリプトデータベースＤＢ２に蓄積して管理する。スクリプト管理サーバ２０が作成するスクリプトは、決済システム１にて行われるべき決済処理の内容を、決済実行サーバ３０が実行可能なフォーマットで記述したコンピュータプログラムの一種であって、サービスを提供するために決済実行サーバ３０が実行すべき処理を定めた処理プログラムの一例に相当する。また、スクリプトデータベースＤＢ２はプログラム保持手段の一例に相当する。スクリプトについては後に一例を挙げて説明する。決済実行サーバ３０は、ユーザ端末６０から取得した決済情報に対応するスクリプトをスクリプト管理サーバ２０から取得し、得られたスクリプトに従って決済処理を実行する。

決済実行サーバ３０は、決済処理を実行するサーバである。決済実行サーバ３０は、決済処理の内容に応じて、口座管理サーバ７０等の他のサーバと適宜に連携して決済処理を実行する。連携相手の一例としての口座管理サーバ７０は、口座データベースＤＢ７を操作して特定種類の電子通貨を用いた料金の支払いを処理するサーバである。例えば、口座データベースＤＢ７には、ユーザが所持する特定種類の電子通貨の残高の情報がユーザ認証コードと対応付けて記録されている。口座管理サーバ７０は、ユーザ認証コードを手掛かりとしてユーザの残高を特定し、特定された残高からユーザが支払うべき料金に相当する量又は額の電子通貨を消費（減算）することにより、電子通貨による支払いを実現する。

決済実行サーバ３０は、口座管理サーバ７０が管理する電子通貨による料金の支払いが必要とされる場合、口座管理サーバ７０に支払処理を依頼することにより、口座管理サーバ７０と連携して決済処理を実行する。なお、図１では料金の支払いを実現する決済手段として口座管理サーバ７０が管理する電子通貨による決済手段が利用される例を示したものである。決済手段として、ユーザの銀行口座（オンラインバンキング）からの引き落とし、あるいはクレジットカードを用いた決済等が必要とされる場合、決済実行サーバ３０はそれらの決済手段による支払いを実現する他のサーバと適宜に連携して決済処理を実行する。つまり、口座管理サーバ７０は決済実行サーバ３０と連携して決済処理を実行するサーバの一例に過ぎない。電子通貨、銀行口座、あるいはクレジットカードといったようにネットワークを介した情報の交換を利用して支払いを処理する仕組みそれ自体は市場で広く実用に供されており、決済実行サーバ３０は決済手段に応じて各種の仕組みを適宜に利用して決済処理を実行すればよい。いずれにしても、決済実行サーバ３０は、ユーザ識別情報と関連付けてサーバに保持されている情報（上述した口座の残高の情報はその一例である。）を参照して決済処理を実行するように構成されてよい。

決済実行サーバ３０は、決済処理に関連して、品目管理サーバ８０及びサービス管理サーバ９０とも適宜に連携する。品目管理サーバ８０は、品目管理データベースＤＢ８を適宜に参照しつつ、サービス端末４０で提供される商品、あるいはサービスを品目として各品目の単価等の販売に関する事項を管理し、あるいはサービス端末４０における品目ごとの料金の支払先といったように売上の処理に関する事項を管理するサーバである。例えば、ゲーム機４０Ａを対象とする場合、品目管理サーバ８０は、ゲーム機４０Ａにて提供される各種のコンテンツを品目として、各品目の単価、支払先等を品目ごとにユニークな品目コードに対応付けて品目管理データベースＤＢ８に記録する。その場合、品目管理サーバ８０は、ゲーム機４０Ａや管理端末５０の求めに応じてそれらの情報を提供する。あるいは、品目管理サーバ８０は、ゲーム機４０Ａにおけるコンテンツの利用に対して支払われた料金を売上として記録し、得られた売上を関係する事業者間で分配するといった処理を担当する。店頭端末４０Ｂの場合も同様であって、店頭端末４０Ｂにて提供される商品やサービスを品目として管理するものである。決済実行サーバ３０は、スクリプトに従って実行した決済処理にて料金が支払われた場合、その支払内容を品目管理サーバ８０に通知する。品目管理サーバ８０はその通知を受けて支払内容を把握し、売上の管理等に反映させることができる。

サービス管理サーバ９０は、サービス端末４０にてユーザに提供される関連サービス、又はその関連サービスとさらに関連付けられた他のサービスを管理するサーバである。以下では、サービス管理サーバ９０が提供するサービスをユーザサービスと呼ぶことがある。例えば、サービス端末４０としてゲーム機４０Ａが設けられている場合、サービス管理サーバ９０はゲーム機４０Ａにてゲームをプレイするユーザを認証し、そのユーザがゲーム機４０Ａにてゲームをプレイした結果をプレイデータとしてユーザデータベースＤＢ９に保存し、保存されたプレイデータをゲーム機４０Ａからの求めに応じて送信するサービスをユーザサービスとして提供する。あるいは、サービス管理サーバ９０はユーザ端末６０からの求めに応じてプレイデータに基づくユーザサービスを提供する。この場合のユーザサービスとしては、例えばユーザのプレイ履歴の閲覧、過去のプレイ映像の閲覧、ゲームにて使用するアイテムの購入といった各種のサービスが用意されてよい。サービス端末４０として店頭端末４０Ｂが設けられている場合も同様であって、サービス管理サーバ９０は店頭端末４０Ｂにおける関連サービスの提供に際してユーザを認証し、関連サービスの提供に必要な各種の情報を店頭端末４０Ｂに適宜に提供するように構成されてよい。

サービス管理サーバ９０におけるユーザの認証は、例えばユーザＩＤといったユーザごとにユニークなユーザ識別情報を用いて行われる。決済実行サーバ３０、あるいは口座管理サーバ７０にてユーザの識別に用いられるべきユーザ認証コードは、例えば、サービス管理サーバ９０にて利用されるユーザ識別情報と共通化される。ただし、そのユーザ認証コードは、サービス管理サーバ９０にて利用されるユーザ識別情報と１対１に対応付けられてもよい。いずれの場合でも、決済実行サーバ３０はサービス管理サーバ９０と連携することにより、例えば決済処理の結果をサービス管理サーバ９０に提供して、サービス管理サーバ９０が提供するユーザサービスに反映させる、といった処理を関連処理の一例として実行することができる。関連処理は、決済処理とは区別され、かつユーザ識別情報と関連付けられている限りにおいて適宜に変更されてよい。なお、サービス端末４０が関連サービスを提供しない場合、決済実行サーバ３０とサービス管理サーバ９０との連携は不要である。

次に、図２を参照してスクリプトの一例を説明する。図２に示したスクリプトは、決済処理を実行するためのスクリプトの一例であって、ユーザ、支払先、支払方法、及び支払内容のそれぞれを特定する情報を含む。スクリプトに記述される情報は、決済処理に関して、「誰が」、「誰に」、「何で」、「何をするか」を特定するための情報の一例である。ユーザの情報は、支払いを「誰が」行うべきかを特定するためにスクリプトに記述される。ユーザの情報としては、例えばユーザごとにユニークに設定されるユーザ認証コードが用いられてよい。

支払先の情報は、「誰に」対して料金を支払うべきかを特定するためにスクリプトに記述される。支払先は、要するに料金が支払われるべき相手である。支払先は、一例として、サービス提供者としての事業者とされてよい。あるいは、サービス端末４０を介して関連サービスを提供する他の事業者が支払先として設定されてもよい。そのような事業者としては、例えば、ゲーム機４０Ａにて利用されるコンテンツを提供する事業者、店頭端末４０Ｂを介して販売されるチケット等の商品を提供する事業者、あるいは、それらの事業者から料金徴収の委託を受けた事業者等が支払先として設定されてよい。一例として、図１の品目管理サーバ８０を運用する事業者、又は当該事業者が指定する収受機関、決済機関等が支払先としてスクリプトに記述されてよい。この場合は、決済実行サーバ３０から品目管理サーバ８０に対して料金の支払いが通知されることにより、支払先への支払いが実現される。

支払方法の情報は、「何で」決済をするか、すなわち料金の支払いに用いられるべき決済手段を特定するためにスクリプトに記述される。例えば、電子通貨による決済、銀行の預金口座からの引き落としによる決済、クレジットカードを用いた決済等のように、ネットワークを介した情報処理を用いて決済を完了させることが可能な決済手段が支払方法として設定される。電子通貨には発行主体あるいは管理主体に応じて種々の電子通貨が存在するが、支払方法の情報にて電子通貨による支払いが指定される場合には、いずれの電子通貨を利用して決済が行われるべきか、が特定できるように支払方法の情報が設定されてよい。例えば、図１の口座管理サーバ７０にて管理されている電子通貨による支払いが決済手段としてスクリプトに記述されてよい。この場合は、スクリプトに従って決済実行サーバ３０が口座管理サーバ７０に決済を依頼することにより、料金の支払いが実現される。決済サービスに関連するスクリプトは、少なくとも決済手段の異同に応じて作り分けられる。換言すれば、決済サービスは決済手段の相違に応じて区分され、決済手段の種類に応じてスクリプトも異なる。さらに、スクリプトは、料金の支払先の相違に応じてさらに区分して作成されてよい。

支払内容の情報は、決済処理に関して、「何をするか」を特定するためにスクリプトに記述される。例えば、「品目Ｘの購入に対して〇〇円を支払う」といったように、決済処理の原因となったユーザの行為内容を特定する情報がスクリプトに記述されてよい。スクリプトに記述された支払方法及び支払先とともに、支払内容の情報が参照されることにより、決済処理にて実現されるべき支払いの詳細を確定することができる。支払内容の情報は最小限の情報として支払額の情報を含むものとされてよい。例えば、ユーザが購入した品目の情報が決済処理にて不要とされる場合、スクリプトの支払内容の情報は支払額を指定する情報として設定されてよい。支払内容には、品目の種類を特定する情報が含まれてもよい。例えばゲーム機４０Ａを対象とする場合、ゲームのプレイの対価として消費されるべき遊戯価値を計量する単位としての「クレジット」を品目の種類として特定し、これをスクリプトに記述するようにしてもよい。その場合、ユーザが購入する品目としてのクレジットの数量をユーザ端末６０にて選択することにより最終的な支払内容を確定させるようにしてもよい。つまり、１クレジット、２クレジットといった数量をゲーム機４０Ａにて選択するのではなく、ユーザ端末６０にてユーザに選択させることも可能である。これにより、サービス端末４０におけるユーザインターフェースを簡素化することができる。

スクリプトは、さらにコメント、有効期限及びシリアル番号の情報を含む。コメントは、ユーザ端末６０を介してユーザに決済の承認を求める際にユーザ端末６０上に表示させるべきテキスト情報としてスクリプトに記述される。有効期限はスクリプトが決済処理にて通用する期限を示す情報としてスクリプトに記述される。有効期限が経過したスクリプトはスクリプトデータベースＤＢ２から適宜に削除される。それにより、スクリプトデータベースＤＢ２に記録されるデータ量を適切な範囲に抑えることが可能である。シリアル番号はスクリプトごとにユニークに設定されるコードであって、スクリプトに対してユニークに関連付けられる処理情報及び処理識別情報のそれぞれの一例に相当する。図２では、スクリプトとシリアル番号とを関連付ける手法として、スクリプトの一部としてシリアル番号をスクリプトに含めているが、シリアル番号はスクリプトに含めることなく、スクリプトとシリアル番号とを１対１で対応付けてスクリプトデータベースＤＢ２に記録することにより、スクリプトとシリアル番号とが関連付けられてもよい。

以上のように、スクリプト管理サーバ２０が作成するスクリプトは、決済実行サーバ３０にて実行されるべき処理の内容を記述したコンピュータプログラムとしての処理プログラムの一例である。また、スクリプトに記述されるべき各種の情報の集合は、そのスクリプトに含まれる変数群の一例に相当する。スクリプトデータベースＤＢ２に保持されたスクリプトに記述される情報には、確定した状態と未確定の状態とが存在する。それらの状態はスクリプトに含まれる変数の値が確定した状態、又は未確定の状態の一例に相当する。例えば、ユーザの情報を一つの変数とした場合、ユーザ認証コードが具体的に指定された状態は変数の値が確定した状態であって、ユーザ認証コードが指定されていない状態は変数の値が未指定の状態に相当する。スクリプトに記録される各種の情報の一部は管理端末５０から与えられる情報に従って設定される。例えば、支払先といった情報は、管理端末５０からバックオフィスサーバ１０を介して与えられる情報に従って具体的な値が確定した変数としてスクリプトに記述されてよい。スクリプトが作成された時点では全ての情報が具体的に確定しているわけではなく、スクリプトデータベースＤＢ２に保持されているスクリプトにおいては、少なくとも一部の変数の値が未確定な状態にある。その未確定な変数の値は、サービス端末４０からユーザ端末６０を経て決済実行サーバ３０へと情報が順次伝達される過程で適宜に確定される。なお、上記ではスクリプトに記録すべき情報の種類を予め定めた上でスクリプト管理サーバ２０がスクリプトを作成しているが、サービス端末４０からユーザ端末６０を経て決済実行サーバ３０へと情報が伝達される過程で、スクリプトに対して追加されるべき新たな種類の情報が指定されてもよい。いずれにしても、スクリプト管理サーバ２０がスクリプトを作成して記録する段階では、スクリプトが未完成であって、サービス端末４０からユーザ端末６０を経て決済実行サーバ３０へと情報が伝達される過程でスクリプトがそこに含まれる変数の種類及び変数の値を適宜に確定させるようにしてスクリプトを完成させればよい。

次に、図３及び図４を参照して、決済システム１が決済サービスを提供するために実行する処理の概略的な手順の一例を説明する。ただし、以下に説明する手順は図１に例示した構成にて実行される処理の手順の一例である。図３及び図４のそれぞれにおいて、図中の手順に直接関係しないサーバ等はグレーにて示してある。

図３は二次元コード１００を発行するための手順の一例を、図４は二次元コード１００を起点として進められる手順の一例をそれぞれ示している。図３の例においては、まず品目管理サーバ８０から管理端末５０（サービス端末４０にて代替されてもよい。）に対して支払条件等を設定するために必要な情報が提供される（Ｆ１１）。提供される情報には、例えばサービス端末４０にて提供される商品、サービスの品目コード、単価、支払先等を特定する情報を含めることができる。

次に、管理端末５０にてスクリプトを作成するために必要な情報が入力され、入力された情報が管理端末５０からバックオフィスサーバ１０に提供される（Ｆ１２）。管理端末５０にて入力される情報は、スクリプト管理サーバ２０にどのようなスクリプトを作成させるかを指定する情報である。例えば、図２のスクリプトを作成させる場合には、そのスクリプトに含めるべき情報（変数）の種類として、ユーザ、支払先、支払方法、支払内容、コメント及び有効期限が管理端末５０を介してバックオフィスサーバ１０に指定され、かつ一部の情報に関しては具体的な値（確定した値）がバックオフィスサーバ１０に指定される。この場合、支払先、及び有効期限についてはその確定した値がバックオフィスサーバ１０に対して与えられてよい。コメントはその全てが確定した状態で指定されてもよいし、一部が未確定な状態で与えられてもよい。また、支払方法として、サービス提供者が利用することを希望する決済手段に関する複数の候補がバックオフィスサーバ１０に与えられてもよい。なお、有効期限は、管理端末５０のオペレータにより適宜に設定されてもよいし、一定のルールに従って自動的に設定されてもよい。

必要な情報がバックオフィスサーバ１０に与えられると、バックオフィスサーバ１０にてスクリプトの作成条件が設定され、その条件がスクリプト管理サーバ２０に提供される。これに応じてスクリプト管理サーバ２０にて与えられた条件に応じたスクリプトが作成される（Ｆ１３）。作成されたスクリプトにはシリアル番号が付加されてスクリプトデータベースＤＢ２に記録される。そのシリアル番号がスクリプト管理サーバ２０からバックオフィスサーバ１０を介してサービス端末４０に通知される（Ｆ１４）。シリアル番号は管理端末５０を経由してサービス端末４０に通知されてもよい。なお、与えられたシリアル番号は、どの決済サービスに対応するものか、を判別するために、サービス端末４０、管理端末５０あるいはバックオフィスサーバ１０にて決済サービスの種類と対応付けて適宜に保存されてよい。

サービス端末４０では、特定の決済サービスの提供が要求されると、その決済サービスに対応するスクリプトのシリアル番号を含んだ必須情報が記録されるようにして二次元コード１００が生成され、得られた二次元コード１００がサービス端末４０にて表示される（Ｆ１５）。二次元コード１００に含まれる必須情報には、スクリプトのシリアル番号に加えて、スクリプトにて未確定である支払内容の情報、すなわち、どのような品目を購入して幾ら支払うか、を特定する情報が付加されてよい。スクリプト管理サーバ２０にてスクリプトが作成される段階では、サービス端末４０を介してユーザが購入する品目やその購入数が未確定であって、それらの具体的な値はスクリプトに記述されない。一方、サービス端末４０にてユーザが商品又はサービスを購入する時点では、どのような品目を購入して幾ら支払うか、が具体的に確定される。よって、サービス端末４０では、ユーザが商品等を購入する時点で確定する情報を、確定情報の一例として、スクリプトのシリアル番号とともに二次元コード１００に記録する。それにより、二次元コード１００を介してユーザ端末６０にシリアル番号及び支払内容の情報を伝達することが可能となる。なお、ユーザ端末６０に対してシリアル番号が提供されるまでの処理と、ユーザ端末６０が二次元コード１００を表示させる処理とは時間的に連続していることを必ずしも要しない。すなわち、ユーザ端末６０は予めシリアル番号をスクリプト管理サーバ２０からバックオフィスサーバ１０を介して取得し、ユーザが実際に支払いを行う時点で、先に取得したシリアル番号の情報と、その時点での支払内容に応じた情報とを参照して二次元コード１００を生成し、表示すればよい。

次に、図４を参照して、サービス端末４０にて二次元コード１００が表示された後の処理手順を説明する。なお、図４の手順を開始するに先立って、ユーザ端末６０ではサービス管理サーバ９０にアクセスして関連サービスに関するユーザ認証が完了し（Ｆ２０）、それにより、ユーザ認証に用いられるユーザＩＤ等のユーザ識別情報をユーザ端末６０及びサービス管理サーバ９０のそれぞれが保持しているものとする。また、サービス管理サーバ９０におけるユーザ認証で用いられるユーザ識別情報は決済処理用のスクリプトにおけるユーザの情報の確定値であるユーザ認証コードの一例として通用するものとする。

図４の手順においては、まず、ユーザ端末６０にて二次元コード１００が撮影され、その二次元コード１００に含まれている必須情報がユーザ端末６０にて取得される（Ｆ２１）。次に、ユーザ端末６０にて、関連サービスのユーザ認証で用いられたユーザ認証コード（ユーザＩＤ）が、二次元コード１００から読み取った必須情報に対して確定情報の一例として付加され、得られた情報が決済情報の一部である一次情報の一例として決済実行サーバ３０に送信される（Ｆ２２）。決済実行サーバ３０が情報を受け取ると、その情報に含まれているシリアル番号、すなわち二次元コード１００に含まれていたシリアル番号が決済実行サーバ３０からスクリプト管理サーバ２０に通知され、シリアル番号に対応するスクリプトの提供が要求される（Ｆ２３）。

スクリプト管理サーバ２０では、通知されたシリアル番号に対応するスクリプトがスクリプトデータベースＤＢ２から抽出され、得られたスクリプトが決済実行サーバ３０に提供される（Ｆ２４）。この場合、スクリプトが有効期限内か否かが確認され、有効期限が経過したスクリプトは無効なものとして以降の処理が中止されてもよい。決済実行サーバ３０にスクリプトが提供されると、決済実行サーバ３０ではそのスクリプトで確定していない支払方法を確定する処理が開始される（Ｆ２５）。その処理においては、決済実行サーバ３０にて、料金の支払いに利用可能な決済手段のリストが生成され、その決済手段のリストが選択情報の一例としてユーザ端末６０に提供される。この場合、スクリプトの支払方法に関する情報に関して決済手段の候補が指定されていれば、その候補が決済手段のリストに記述される。支払方法に関して指定がなければ、決済実行サーバ３０が処理可能な決済手段がリストの記述される。一方、ユーザ端末６０では、提供されたリストが表示され、料金の支払いに用いる決済手段をユーザに選択させる処理が行われる。その選択結果は決済情報ＩＦｂのさらなる一部である二次情報の一例としてユーザ端末６０から決済実行サーバ３０に送信される。この場合、選択結果を示す情報は決済手段識別情報の一例に相当する。なお、ユーザ端末６０に対するリストの提供に併せて、スクリプトに記述されたテキストがユーザ端末６０に送信され、ユーザ端末６０にてそのテキストが表示されることにより、選択した決済手段を用いて決済を実行してもよいか否かをユーザに確認する処理が行われてもよい。

ユーザ端末６０から決済手段の選択結果が送信されると、決済実行サーバ３０では、ユーザ端末６０からの選択結果に従ってスクリプトの支払方法に関する具体的な値が確定される。そして、決済実行サーバ３０では、確定したスクリプトに従って決済処理が実行される。例えば、スクリプトに記述された支払方法に従って口座管理サーバ７０に電子通貨を用いた決済、すなわちユーザ認証コードに対応した口座からの電子通貨の引き落とし（消費）が要求され（Ｆ２６）、その処理に成功した場合には品目管理サーバ８０に対して支払内容が通知され（Ｆ２７）、サービス管理サーバ９０に対しても支払完了が通知される（Ｆ２８）。さらに、ユーザ端末６０及びサービス端末４０のそれぞれに対しても支払完了が通知される（Ｆ２９、Ｆ３０）。それにより、ユーザはユーザ端末６０を介して支払いが完了したことを把握することができる。また、サービス端末４０も支払いの完了を把握することができる。この場合、サービス端末４０が支払完了を条件として関連サービスを提供する場合には、その通知をトリガーとして関連サービスの提供に必要な処理を開始することができる。なお、決済実行サーバ３０からサービス端末４０に支払完了を通知するためには、その通知先を判別する情報が決済実行サーバ３０に提供される必要がある。そのためには、例えばスクリプトデータベースＤＢ２に記録されるスクリプトに通知先の情報を予め記録し、あるいはサービス端末４０にて通知先を示す情報を二次元コード１００に必須情報の一部として含め、これをユーザ端末６０から決済実行サーバ３０に提供することにより、決済実行サーバ３０が通知先を把握できるようにしてもよい。あるいは、バックオフィスサーバ１０にて各サービス端末４０における二次元コード１００の発行状況を管理し、決済実行サーバ３０からバックオフィスサーバ１０を経由してサービス端末４０に支払完了を通知してもよい。

図５は、図３及び図４に示した手順において、スクリプトに記述されるべき情報が確定する様子の一例を示している。図示の例では、まずサービス端末４０（図では店頭端末４０Ｂを示すが、他のサービス端末でもよい。）にて生成される二次元コード１００には支払内容及びシリアル番号が必須情報ＩＦａに含まれている。次に、二次元コード１００を読み取ったユーザ端末６０では、二次元コード１００に含まれていた支払内容及びシリアル番号の情報に対してユーザ認証コード及び支払方法が確定情報として付加されて決済情報ＩＦｂが生成される。得られた決済情報ＩＦｂは決済実行サーバ３０に送信される。ただし、決済情報ＩＦｂの送信は一度に行われることを必須とするものではない。例えば、図４の例では、支払方法を除く情報が決済実行サーバ３０に先行して送信され、先行して送信された情報に基づいて決済実行サーバ３０から決済手段のリストが提供され、そのリストに基づいてユーザに決済手段を選択させることにより支払方法の情報が確定され、その確定後に、支払方法を指定する情報がユーザ端末６０から決済実行サーバ３０に送信される。スクリプトに予め支払方法の候補を記述しない場合には、ユーザ認証コード、スクリプト等の送信に先行して決済実行サーバ３０から決済手段のリストを取得し、そのリストに従って決済手段をユーザに選択させることによって決済情報ＩＦｂを確定させ、得られた決済情報ＩＦｂを決済実行サーバ３０に一括して送信することも可能である。決済情報ＩＦｂに含まれているシリアル番号は決済実行サーバ３０からスクリプト管理サーバ２０に提供され、そのシリアル番号に対応するスクリプトがスクリプト管理サーバ２０から決済実行サーバ３０に提供される。スクリプト管理サーバ２０から決済実行サーバ３０に提供されるスクリプトにおいては、図中にグレーで示したように、ユーザの情報、支払方法の情報及び支払内容の情報が未確定の状態である。

決済実行サーバ３０では、スクリプト管理サーバ２０から取得したスクリプトにて未確定であるユーザ、支払方法及び支払内容の情報に対して、ユーザ端末６０から取得した決済情報ＩＦｂのユーザ認証コード、支払方法及び支払内容の情報が引用される。それによりスクリプトの全ての情報が確定する。

以上の例によれば、決済処理に必要なスクリプトが管理端末５０から提供される情報に従ってスクリプト管理サーバ２０にて作成されてスクリプトデータベースＤＢ２に保存され、そのスクリプトのシリアル番号がサービス端末４０へと提供される。スクリプト管理サーバ２０にて作成されるスクリプトには、サービス提供者側が設定した条件に従って確定した情報を予め記述しておくことができる。例えば、支払先の情報に関する具体的な値を管理端末５０からバックオフィスサーバ１０を介してスクリプト管理サーバ２０に送信すれば、その情報の具体的な値（確定した情報）を予めスクリプトに記述しておくことができる。それらの情報を二次元コード１００に含める必要はない。

一方、決済実行サーバ３０側では、スクリプトに記述され得る支払方法に応じて決済処理の内容を変更する必要がある。例えば、支払先や支払方法に応じて連携相手となるサーバ（図１の例では口座管理サーバ７０や品目管理サーバ８０）を適宜に選択し、あるいはサービス端末４０の種類に応じて連携相手となるサーバ（図１の例ではサービス管理サーバ９０）を適宜に選択し、連携相手のサーバとの間では適宜に定められた手順に従って決済に関連した処理を進める必要がある。しかしながら、それらの処理を実現するためのプログラムの追加、修正、変更といった作業は決済実行サーバ３０を運営する事業者側で行えば足り、サービス端末４０側では負担が生じない。

また、二次元コード１００に記録される必須情報ＩＦａは、決済手段の種類を問わず決済処理を実行するために必要となる共通の情報である。すなわち、支払内容の情報は、決済手段の種類を問わず、決済処理を実行するために必要不可欠である。しかも、支払内容の情報に関する具体的な値は、個々の支払いが発生する度にサービス端末４０にて確定されるものである。つまり、決済サービスがどのような決済手段を利用するかに関わりなく、支払額等の情報は、決済実行サーバ３０が決済処理を実行するために共通して必要となる情報であって、しかもその具体的に確定した値が決済実行サーバ３０に与えられることが必要である。したがって、決済サービスとして行われるべき決済処理の内容、例えば支払先、あるいは支払方法等が種々変化しても、サービス端末４０では支払内容を示す情報を二次元コード１００に共通して含めておく必要がある。また、シリアル番号は決済手段の種類に関わりなく、スクリプトを特定するために必要な情報として二次元コード１００に共通して記録されているべき情報である。このように必須情報ＩＦａは、決済手段の種類に関わりなく二次元コード１００に記録されるべき共通の情報である。そして、決済手段の種類を問わず必要な情報としての共通性があるがゆえに、決済手段の種類に関わりなく一定のフォーマットで必須情報ＩＦａを二次元コード１００に記録することが可能である。

したがって、新たな決済サービスを導入する場合でもサービス端末４０側では、その決済サービスに対応するフォーマットの二次元コードを新たに生成するためのプログラムを追加する必要がない。また、サービス端末４０側に、新たな決済サービスに対応する専用のハードウエアを設ける、といった設備投資も不要である。一方、二次元コード１００に記述されない情報は、スクリプトの作成時に予め具体的に確定した状態で記述し、あるいはユーザ端末６０で適宜に付加することが可能である。したがって、決済処理を実行する際に必要な情報に関して決済サービス間で差があったとしても、二次元コード１００に記録されるべき共通の必須情報以外の情報は予めスクリプトに確定した状態で記述し、あるいはユーザ端末６０側で適宜に追加することにより対応可能である。

次に、図６を参照して、決済システム１の要部に関する具体的な構成の一例を説明する。なお、図６の構成は図１の決済システム１の具体例の一つであり、図１に対応する構成要素には図１と共通の参照符号が付されている。図６の例において、バックオフィスサーバ１０には、そのコンピュータハードウエアとコンピュータプログラムＰｓ１との組み合わせによって実現される論理的装置として、条件設定部１１及びシリアル取得部１２が設けられる。条件設定部１１は、管理端末５０からの入力に従ってスクリプトの作成に必要な条件を設定し、これをスクリプト管理サーバ２０に提供する。シリアル取得部１２はスクリプト管理サーバ２０からスクリプトのシリアル番号を取得し、これをサービス端末４０に提供する。シリアル番号の提供は、サービス端末４０からの求めに応じて行われてよい。

スクリプト管理サーバ２０には、そのコンピュータハードウエアとコンピュータプログラムＰｓ２との組み合わせによって実現される論理的装置として、スクリプト作成部２１及びスクリプト管理部２２が設けられる。スクリプト作成部２１は、バックオフィスサーバ１０から送信される条件の情報に従って決済処理を実行するためのスクリプトを作成し、得られたスクリプトにシリアル番号を付してスクリプトデータベースＤＢ２に保存する。スクリプト管理部２２はバックオフィスサーバ１０に対してシリアル番号を提供する。また、スクリプト管理部２２は、決済実行サーバ３０からの求めに応じてスクリプトデータベースＤＢ２を検索して決済実行サーバ３０に実行させるべきスクリプトを選択し、得られたスクリプトを決済実行サーバ３０に提供する。スクリプト管理部２２は、スクリプトの有効期限を適宜のタイミングでチェックし、有効期限を経過したスクリプトがスクリプトデータベースＤＢ２から削除されるようにスクリプトデータベースＤＢ２を管理してもよい。

決済実行サーバ３０には、そのコンピュータハードウエアとコンピュータプログラムＰｓ３との組み合わせによって実現される論理的装置として、決済実行部３１及び決済通知部３２が設けられる。決済実行部３１は、ユーザ端末６０から受け取った決済情報ＩＦｂに含まれているシリアル番号に対応するスクリプトをスクリプト管理サーバ２０から取得し、あるいは決済手段のリストをユーザ端末６０に提供するとともに、確定したスクリプトに従って口座管理サーバ７０等と連携しつつ決済処理を実行する。決済通知部３２は決済実行部３１が実行した決済処理の結果の情報をサービス端末４０及びユーザ端末６０に、さらには必要に応じて品目管理サーバ８０及びサービス管理サーバ９０に通知する。

サービス端末４０には、そのコンピュータハードウエアとコンピュータプログラムＰｔ１との組み合わせによって実現される論理的装置として、支払制御部４１及びコード制御部４２が設けられる。支払制御部４１は、サービス端末４０における商品やサービスの購入に対応して二次元コード１００に必須情報ＩＦａの一部として含めるべき支払内容の情報を確定させる処理、例えばユーザが支払うべき支払額の計算等の処理を担当する。コード制御部４２は二次元コード１００に必須情報ＩＦａの一部として含めるべきシリアル番号を取得し、支払制御部４１が確定させた支払内容と合わせて必須情報ＩＦａを生成し、得られた必須情報ＩＦａに基づいて二次元コード１００を生成し、サービス端末４０に表示させる。

ユーザ端末６０には、そのコンピュータハードウエアとコンピュータプログラムＰｔ２との組み合わせによって実現される論理的装置として、コード取得部６１及び支払制御部６２が設けられる。コード取得部６１はユーザ端末６０のカメラ（不図示）等を制御して二次元コード１００を撮影し、二次元コード１００に含まれている必須情報ＩＦａを取得する。支払制御部６２は、コード取得部６１が取得した必須情報ＩＦａに対してユーザ認証コード、あるいは支払方法の情報等を付加して決済情報ＩＦｂを生成し、得られた決済情報ＩＦｂを決済実行サーバ３０に送信するといった料金の支払いに必要な各種の処理を実行する。

なお、管理端末５０にもそのコンピュータハードウエアとコンピュータプログラムとの組み合わせによって適宜の論理的装置が設けられるが、管理端末５０はバックオフィスサーバ１０に対してスクリプトの作成に必要な支払条件等の情報を入力する端末装置として機能すればよく、例えばバックオフィスサーバ１０が提供するＷｅｂページにＷｅｂブラウザ等を介してアクセスして情報を入力するように設けられていればよい。この種の仕組みは周知であり、図６では詳細を省略する。

図７〜図９は、図６に示した決済システム１において決済サービスを提供するために実行される手順の一例を示すフローチャートである。図７は図３に例示した二次元コードの発行までの手順の具体例、図８及び図９は図４に例示した二次元コードの表示以降の手順の具体例である。図７の手順においては、まず品目管理サーバ８０から管理端末５０（又はサービス端末４０であってもよい。）に対して品目コード等の情報が送信され（ステップＳ１１）、管理端末５０では受け取った情報に基づいてスクリプトを作成するために必要な条件を指定する情報が入力されてバックオフィスサーバ１０に提供される（ステップＳ１２）。この場合の情報は、例えば、バックオフィスサーバ１０の条件設定部１１の案内に従って管理端末５０上で入力されてよい。

次に、バックオフィスサーバ１０では、条件設定部１１により管理端末５０から取得した情報に基づいてスクリプトを作成するための条件が設定され、設定された条件に対応するスクリプトの作成が条件設定部１１からスクリプト管理サーバ２０に依頼される（ステップＳ１３）。これを受けて、スクリプト管理サーバ２０のスクリプト作成部２１にて条件に合致したスクリプトが作成され（ステップＳ１４）、そのスクリプトにシリアル番号が追加され（ステップＳ１５）、得られたスクリプトがスクリプトデータベースＤＢ２に記録される（ステップＳ１６）。

スクリプトデータベースＤＢ２に新たなスクリプトが記録されると、そのシリアル番号がスクリプト管理部２２からバックオフィスサーバ１０のシリアル取得部１２に提供され（ステップＳ１７）、そのシリアル番号はさらにサービス端末４０に提供される（ステップＳ１８）。シリアル番号は、一例として、スクリプトが作成されるごとにサービス端末４０に提供されてそのサービス端末４０上で保管される。ただし、バックオフィスサーバ１０にてステップＳ１３の作成依頼と対応付けてシリアル番号が保管され、サービス端末４０からの求めに応じてサービス端末４０にシリアル番号が提供されてもよい。なお、複数のスクリプトが適宜に使い分けられる場合には、サービス端末４０にて発生する支払いに応じたスクリプトのシリアル番号を特定できるようにしてシリアル番号を保持しておく必要がある。例えば、バックオフィスサーバ１０がスクリプト作成時に指定した条件に照らしてサービス端末４０にて提供すべき決済サービスに対応するスクリプトのシリアル番号を特定し、得られたシリアル番号をサービス端末４０に提供する、といった処理が行われてよい。

サービス端末４０では、ユーザによる商品等の購入に対応して支払いが発生すると、その支払内容が支払制御部４１にて決定され（ステップＳ２１）、次いで、コード制御部４２により、支払内容の情報と支払いを実現するためのスクリプトのシリアル番号とを含めるようにして二次元コード１００が生成されて表示される（ステップＳ２２）。なお、ステップＳ１８の処理とステップＳ２１の処理とは時間的に連続していることを要しない。例えば、複数回の決済に対して同一のスクリプトがその情報の確定値を置き換えつつ繰り返し利用される場合には、サービス端末４０、あるいはバックオフィスサーバ１０に保管されたシリアル番号と、決済の都度確定する支払内容とを組み合わせて決済ごとに二次元コード１００が作成されてよい。サービス端末４０にて発生する支払いに関して、支払先が異なるといった理由から複数のスクリプトが選択的に適用され得る場合には、例えばサービス端末４０にてどの支払先を選択すべきかを指定し、その支払先に対応するシリアル番号が必須情報ＩＦａに含まれるようにして二次元コード１００が作成されてよい。

サービス端末４０にて二次元コード１００が表示されると、処理は図８の手順へと進められる。図８の手順においては、まずユーザ端末６０のコード取得部６１によりユーザ端末６０のカメラ等が制御されて二次元コード１００が撮影され、その二次元コード１００に含まれている必須情報ＩＦａ、すなわち支払内容の情報とシリアル番号とがコード取得部６１により取得される（ステップＳ３１）。取得された必須情報ＩＦａは支払制御部６２に渡され、支払制御部６２により必須情報ＩＦａに対してユーザ認証コードが端末付加情報の一例として付加される（ステップＳ３２）。この場合のユーザ認証コードは、一例として、ユーザがユーザ端末６０を用いてサービス管理サーバ９０のサービスを利用する際に用いるユーザ認証情報である。ユーザがユーザ端末６０を用いてサービス管理サーバ９０の認証を済ませており、そのユーザ認証情報がユーザ端末６０に保持されていれば、支払制御部６２はそのユーザ認証情報をユーザ認証コードとして付加すればよい。ただし、ステップＳ３２の段階でユーザがユーザ認証コードを入力するものとしてもよいし、コンピュータプログラムＰｔ２の機能によりユーザ端末６０がユーザ認証コードを保持していれば、その保持されたユーザ認証コードがステップＳ３２で付加されてもよい。

続いて、必須情報ＩＦａにユーザ認証コードが付加された情報が決済情報ＩＦｂの一部である一次情報の一例として支払制御部６２から決済実行サーバ３０に送信されて決済処理が要求される（ステップＳ３３）。その要求を受けた決済実行サーバ３０では、決済実行部３１によりユーザ端末６０から取得した情報に含まれているシリアル番号が取り出されてスクリプト管理サーバ２０に送信され、そのシリアル番号に対応するスクリプトが照会される（ステップＳ３４）。スクリプト管理サーバ２０では、スクリプト管理部２２により、決済実行サーバ３０から与えられたシリアル番号をキーとしてスクリプトデータベースＤＢ２が検索されることにより、シリアル番号に対応するスクリプトが選択される（ステップＳ３５）。選択されたスクリプトはスクリプト管理部２２から決済実行サーバ３０に提供される（ステップＳ３６）。それにより、決済実行サーバ３０の決済実行部３１は、スクリプト管理サーバ２０から提供されたスクリプトを、実行すべきスクリプトとして特定する。なお、ステップＳ３５において、スクリプト管理部２２にて選択されたスクリプトが有効期限内か否かが確認され、有効期限が経過している場合には該当するスクリプトが存在しないものとして決済処理が打ち切られてもよい。この場合は、決済実行サーバ３０からサービス端末４０及びユーザ端末６０に対して決済不能が通知され、それぞれの端末４０、６０にて適宜のエラー処理が実行されてもよい。

決済実行サーバ３０の決済実行部３１に対してスクリプトが提供されると、そのスクリプトにて未確定である支払方法の情報に関して、今回の決済で利用可能な決済手段のリストが選択情報の一例として決済実行部３１からユーザ端末６０に提供される（ステップＳ３７）。そのリストは、上述したように、スクリプトにて予め指定された決済手段の候補を記述することにより生成されてよい。スクリプトにて決済手段の候補が指定されていない場合には、決済実行サーバ３０が処理可能な決済手段がリストに記述されてよい。決済実行サーバ３０が利用可能な決済手段については、例えば新たな決済手段に対応した処理プログラムが決済実行サーバ３０に追加されるごとに更新されるといった手法により、決済実行サーバ３０に予め与えておくことができる。ユーザ端末６０の支払制御部６２では、提供されたリストからユーザに決済手段を選択させる処理が行われ、その選択結果が決済情報ＩＦｂのさらなる一部である二次情報の一例として決済実行サーバ３０に送信される（ステップＳ３８）。このとき、決済処理を実行してよいか否かをユーザに確認させる処理が併せて行われ、ユーザが決済実行を承認した場合に限って決済手段の選択結果が送信されるものとしてもよい。

決済手段の選択結果が決済実行サーバ３０に送信されると、決済実行部３１により決済情報ＩＦｂに含まれている情報、すなわち、ユーザ認証コード、支払方法（ユーザが選択した決済手段に相当する。）及び支払内容の確定値がスクリプトに代入されてスクリプトの全ての情報が確定され、その確定したスクリプトに従って決済実行部３１により決済処理が実行される（ステップＳ３９）。

決済処理は、一例として、決済実行部３１から口座管理サーバ７０に対してユーザ認証コード及び支払額が通知されて電子通貨による支払処理が口座管理サーバ７０に要求され、これに応じて口座管理サーバ７０がユーザ認証コードに対応する口座の電子通貨の残高を支払額に応じて減算することにより実現される（ステップＳ４０）。その後、決済処理は図９の手順へと進められ、口座管理サーバ７０から決済実行サーバ３０に支払処理の結果が通知される（ステップＳ４２）。支払いが正常に完了していれば、決済実行サーバ３０の決済通知部３２から品目管理サーバ８０に対して支払完了が支払先、支払内容といった情報を添えて通知され（ステップＳ４３）、品目管理サーバ８０ではその通知を受けて支払実績が記録される（ステップＳ４４）。また、支払結果は決済通知部３２からサービス端末４０、ユーザ端末６０、サービス管理サーバ９０にも通知される（ステップＳ４５）。なお、サービス端末４０に対する通知は、例えばバックオフィスサーバ１０にてサービス端末４０における二次元コード１００の発行状況を管理し、決済実行サーバ３０からバックオフィスサーバ１０に支払結果を通知してバックオフィスサーバ１０が通知先のサービス端末４０を判別し、判別されたサービス端末４０へと支払結果を転送することにより実現されてよい。あるいは、図２に示したスクリプトにおいて、支払結果の通知先を追加し、スクリプトの作成時に予め通知先の確定値を記録しておくか、又はサービス端末４０が二次元コード１００を生成する際に、その通知先の情報の確定値を含めることにより、決済実行サーバ３０が通知先となるサービス端末４０を特定できるようにしてもよい。通知先の情報をスクリプトに含める場合には、例えば、支払先と通知先とが異なる場合において、支払先への処理と通知先への処理とを区別して実行できる利点がある。

支払結果の通知を受けて、サービス端末４０の支払制御部４１では、料金の支払い完了を条件として許可されるべき所定の処理が後続処理として開始される（ステップＳ４６）。例えば、ゲームのプレイの許可、チケットの発行といった処理が後続処理として開始されてよい。ユーザ端末６０では支払いが完了した旨がユーザに対して通知される（ステップＳ４７）。さらに、サービス管理サーバ９０では、料金の支払い完了を条件として許可されるべき所定の処理が関連処理として実行される（ステップＳ４８）。例えば、サービス管理サーバ９０が提供するサービスに対してユーザに特典を付与するといったごとく、料金の支払いと関連付けた処理が関連処理としてサービス管理サーバ９０にて実行されてよい。いずれにしても、サービス端末４０は、決済実行サーバ３０から通知される結果が決済完了を示す場合に、ゲームサービス、チケット発行サービスといった各種のサービスをユーザに提供するように構成されてよい。

以上の形態によれば、スクリプトデータベースＤＢ２に保持されたスクリプトにおいて、決済が発生する都度に確定すべきユーザ、支払内容等の情報が未確定であり、決済が発生した時点で確定する情報をサービス端末４０あるいはユーザ端末６０にて適宜に付加することにより、スクリプトの情報が確定する。したがって、複数の決済間で共通して確定すべき情報を予めスクリプトに記述してスクリプトデータベースＤＢ２に記録しておけば、スクリプトデータベースＤＢ２に保持された一つのスクリプトを、その有効期限内に発生する複数の決済で繰り返し使用することが可能である。これにより、スクリプト作成に要するスクリプト管理サーバ２０の負担を軽減し、あるいはスクリプトデータベースＤＢ２に記録すべき情報量を削減できる、といった利点が得られる。

第１の形態においては、コード制御部４２が図７のステップＳ２２の処理を実行することにより情報画像表示手段の一例として機能し、コード取得部６１が図８のステップＳ３１の処理を実行することにより情報取得手段の一例として機能し、支払制御部６２が図８のステップＳ３２、Ｓ３３及びＳ３８の処理を実行することにより決済情報提供手段の一例として機能し、決済実行部３１が図８のステップＳ３９の処理を実行することにより決済実行手段の一例として機能し、決済通知部３２が図９のステップＳ４５の処理を実行することにより結果情報提供手段の一例として機能する。また、支払制御部６２が図８のステップＳ３２及びＳ３３の処理を実行することにより一次情報提供手段の一例として機能し、支払制御部６２が図８のステップＳ３８の処理を実行することにより二次情報提供手段の一例として機能し、決済実行部３１が図８のステップＳ３７の処理を実行することにより選択情報提供手段の一例として機能する。さらに、サービス管理サーバ９０は図９のステップＳ４８の処理を実行することにより関連処理実行手段の一例として機能する。

なお、上記の形態では、サービス端末４０にて二次元コード１００に記録されるべき処理情報としてスクリプトのシリアル番号を例示したが、スクリプトそのものを処理情報として設定してもよい。その一例を図１０に示す。図１０の例では、図２に例示したスクリプトがスクリプト管理サーバ２０からサービス端末４０に提供され、サービス端末４０では支払額等の情報が支払内容に関する確定した情報として付加されて必須情報ＩＦａが生成され、その必須情報ＩＦａが二次元コード１００に記録される。つまり、二次元コード１００にはスクリプトそれ自体が処理情報として記録される。二次元コード１００を読み取ったユーザ端末６０ではユーザに関する確定した情報としてユーザ認証コードが付加されて決済情報ＩＦｂの一部である一次情報が生成され、その一次情報が決済実行サーバ３０に提供される。また、決済実行サーバ３０から送信される決済手段のリストに基づいてユーザ端末６０にて決済手段が選択されることにより、決済情報ＩＦｂのさらなる一部である二次情報が生成され、その二次情報が決済実行サーバ３０に提供される。したがって、決済実行サーバ３０は、スクリプト管理サーバ２０に照会することなく、実行すべきスクリプトを特定してこれに応じた処理を実行することができる。なお、二次元コード１００に記録されるスクリプトは、復元可能な方法で圧縮され、あるいは暗号化された状態であってもよい。

上記の形態では、サービス提供者が管理端末５０を利用してスクリプトの作成を要求できるものとしたが、これに代えて、又は加えてスクリプト管理サーバ２０の管理者が管理端末５０を利用してスクリプトの作成を指示してもよい。あるいは、サービス端末４０がスクリプトの作成を指示するものとしてもよい。その場合、管理端末５０を省略することも可能である。

（第２の形態）
上述した第１の形態では、サービス端末４０における決済の発生に先行して、管理端末５０からの情報に従ってスクリプトを作成し、これをスクリプトデータベースＤＢ２に予め保存しているが、スクリプトを作成する時期はそのような例に限られない。例えば、サービス端末４０にて決済が発生する時点でスクリプトを作成することも可能である。以下、図１１〜図１３を参照してそのような変更を施した第２の形態に係る決済システムの一例を説明する。なお、以下に説明する例は図１に示した決済システム１における処理を部分的に変更したものである。図１１〜図１３において、図１〜図９と共通する部分には同一の参照符号を付し、以下では相違点を中心に説明する。

図１１の決済システム１Ａでは、スクリプトの作成から二次元コード１００の発行に至るまでの処理の手順が異なる。図１１のサービスシステム１Ａでは、ユーザが購入する商品又はサービスを選択するとスクリプトの作成に関する処理が開示される。ただし、その処理に先行して、管理端末５０からバックオフィスサーバ１０に対して、あるいはバックオフィスサーバ１０を経由してスクリプト管理サーバ２０に対してスクリプトの作成に関連した情報が提供されてもよい（Ｆ５０）。この時点で提供される情報は、例えばサービス端末４０が設置された店舗等の施設、あるいはサービス提供者といった適宜の範囲内で共通して用いられるべき情報とされてよい。サービス提供者がユーザに利用させることを希望する決済手段の種類を指定する情報が管理端末５０からバックオフィスサーバ１０に提供されてもよい。ただし、それらの情報を後述するサービス端末４０からの情報の提供時に併せて提供するものとし、それにより、管理端末５０からの情報提供を省略してもよい。また、スクリプトを作成するために必要な品目コード、単価等が品目管理サーバ８０からサービス端末４０あるいは管理端末５０に提供されてもよい（Ｆ５１）。それらの情報が品目管理サーバ８０からの提供以外の手段にてサービス端末４０、あるいは管理端末５０に与えられていれば、品目管理サーバ８０からの提供は不要である。

ユーザがサービス端末４０を操作して購入したい商品又はサービスを選択すると、その商品又はサービスの料金を決済するためのスクリプトの作成に必要な情報がサービス端末４０からバックオフィスサーバ１０に提供される（Ｆ５２）。例えば、支払先、支払方法、有効期限、あるいはコメントの情報がバックオフィスサーバ１０に提供されてよい。支払方法として、複数の決済手段が指定されてもよい。バックオフィスサーバ１０では、得られた情報がデフォルト設定情報として一時的に記憶される。ただし、これらの情報の一部、例えば支払先、支払方法等に関して、サービス端末４０が設置された店舗、あるいはサービス端末４０を運用するサービス提供者が個々の決済に関わりなく共通した値を設定する場合には、それらの情報が管理端末５０からバックオフィスサーバ１０に先行して与えられてもよい。

次に、ユーザがサービス端末４０に対して購入を要求すると、支払品目、単価、個数といった支払内容の情報と、サービス端末４０を識別するための端末識別情報とがバックオフィスサーバ１０に提供される（Ｆ５３）。それにより、図２に示したスクリプトのうち、ユーザ、シリアル番号及び支払方法の情報を除く情報がその値を確定させた状態でバックオフィスサーバ１０上に揃う。支払方法として複数種類の決済手段が指定されている場合、その支払方法は未確定な状態である。この後、バックオフィスサーバ１０からスクリプト管理サーバ２０に対し、デフォルト設定情報とその後にサービス端末４０から提供された情報とを添えてスクリプトの作成が要求される（Ｆ５４）。スクリプト管理サーバ２０では、バックオフィスサーバ１０から得られた情報に従ってスクリプトが作成され、そのスクリプトに対してシリアル番号が付加された上でスクリプトデータベースＤＢ２に記録される。この段階で保存されるスクリプトは、ユーザ及び支払方法の情報以外の情報が全て確定した状態で記録されたものとなる。そして、作成されたスクリプトのシリアル番号がサービス端末４０に提供される（Ｆ５５）。サービス端末４０では、得られたシリアル番号のみが必須情報として含まれるようにして二次元コード１００が表示される（Ｆ５６）。

二次元コード１００に含まれる必須情報がユーザ端末６０にて読み取られた後の手順は図４と同様であるために詳細を省略する。ただし、この例では、図１２に示すように、二次元コード１００を読み取ったユーザ端末６０にて、必須情報ＩＦａとしてのシリアル番号に対してユーザ認証コードが付加されて決済情報ＩＦｂが生成され、その決済情報ＩＦｂが決済実行サーバ３０に送信される。スクリプトデータベースＤＢ２に記録されたスクリプトでは、ユーザ認証コード及び支払方法以外の情報は全て確定した状態で記録されているので、決済実行サーバ３０はスクリプト管理サーバ２０から提供されたスクリプトに基づいてユーザ端末６０に決済手段のリストを提供してユーザに決済手段を選択させ、選択された決済手段の情報とユーザ認証コードとをユーザ端末６０から取得してそれらの値をスクリプトに代入することによりスクリプトの全ての情報を確定させる。それにより、決済処理を実行することが可能である。

図１３は、図１１の決済システム１Ａにおける二次元コード１００の発行までの手順の具体例を図７に対応させて示している。なお、図１３の各処理を実行するための決済システム１Ａの具体的な構成は図６と同様でよく、以下では図６に示した構成に基づいて図１３の各処理が実行されるものとして処理手順を説明する。図１３の手順においては、まず管理端末５０からバックオフィスサーバ１０への先行情報の送信（ステップＳ１０）、及び品目管理サーバ８０からサービス端末４０（又は管理端末５０であってもよい。）に対する品目コード等の送信が実行される（ステップＳ１１）。ただし、これらの処理が適宜に省略されてよいことは上述した通りである。

サービス端末４０にてユーザが商品又はサービスを選択すると、支払先等の一定の情報がサービス端末４０の支払制御部４１からバックオフィスサーバ１０に提供される（ステップＳ１２Ａ）。この段階で、支払方法に関して一又は複数種類の決済手段を指定する情報が提供されてもよい。その情報はステップＳ１０で先行して提供されてもよい。バックオフィスサーバ１０の条件設定部１１は、得られた情報をデフォルト設定情報としてバックオフィスサーバ１０の記憶装置（不図示）に記憶する（ステップＳ１２Ｂ）。この後、サービス端末４０に対してユーザが購入を確定する操作を行うと、サービス端末４０の支払制御部４１により、その時点で確定した支払品目、単価、個数といった支払内容の情報と、支払方法に関する選択肢を示す情報と、サービス端末４０を識別するための端末識別情報とがバックオフィスサーバ１０に提供される（ステップＳ１２Ｃ）。バックオフィスサーバ１０では、条件設定部１１により、ステップＳ１２Ｂで記憶した情報とステップＳ１２Ｃによって送信された情報とをスクリプト作成条件として指定しつつ、スクリプト管理サーバ２０に対してスクリプトの作成が要求される（ステップＳ１３Ａ）。

スクリプトの作成が要求されると、スクリプト管理サーバ２０のスクリプト作成部２１にて作成条件に合致したスクリプトが作成され（ステップＳ１４）、そのスクリプトにシリアル番号が追加され（ステップＳ１５）、得られたスクリプトがスクリプトデータベースＤＢ２に記録される（ステップＳ１６）。この場合に記録されるスクリプトは、上記の通り、ユーザ及び支払方法の情報が未確定で、それ以外の情報は全て確定した状態である。ただし、支払方法として一種類の決済手段が指定された場合には、支払方法の情報はこの時点で実質的に確定している。

スクリプトデータベースＤＢ２に新たなスクリプトが記録されると、そのシリアル番号がスクリプト管理部２２からバックオフィスサーバ１０のシリアル取得部１２に提供され（ステップＳ１７）、そのシリアル番号はさらにサービス端末４０に提供される（ステップＳ１８）。その提供を受けて、サービス端末４０では、コード制御部４２によりバックオフィスサーバ１０を経由して与えられたシリアル番号のみを含んだ必須情報ＩＦａが記録されるようにして二次元コード１００が生成されて表示される（ステップＳ２２）。

サービス端末４０にて二次元コード１００が表示されると、以降はユーザ端末６０から決済実行サーバ３０への決済情報ＩＦｂの提供といった処理が行われるが、それらの処理は図８及び図９と同様でよく、その詳細は説明を省略する。ただし、ユーザ端末６０にて追加される情報はユーザ認証コードとユーザが選択した決済手段を支払方法として指定する情報のみで足りる。また、決済処理が完了した場合、それに用いられたスクリプトを、有効期限内であっても削除する処理が追加されてもよい。

第２の形態によれば、サービス端末４０にて支払いが発生する都度に新たなスクリプトが作成される。したがって、スクリプト作成時には、第１の形態と比較して、より多くの情報を確定させた状態でスクリプトを作成することが可能である。そのため、二次元コード１００に記録すべき情報を削減して二次元コード１００を簡素化し、複数種類の決済サービス間にて二次元コード１００を共通化するに有利である。なお、第２の形態に係る決済システム１Ａにおけるサービス端末４０のコード制御部４２、ユーザ端末６０のコード取得部６１及び支払制御部６２、決済実行サーバ３０の決済実行部３１、決済通知部３２が第１の形態と同様の手段の一例として機能する。

第２の形態では、サービス端末４０から先行して送信される情報（ステップＳ１２Ａ）をバックオフィスサーバ１０に記憶し、その後に送信される情報（ステップＳ１２Ｃ）と合わせることにより、スクリプトのユーザ認証コード以外の情報を揃えた上でスクリプト管理サーバ２０にスクリプトの作成を依頼したが、それらの情報をユーザの購入操作に従ってサービス端末４０上で一時的に保持し、ユーザ認証コード以外の情報が揃った時点でサービス端末４０からスクリプト作成をスクリプト管理サーバ２０に依頼するようにしてもよい。この場合、バックオフィスサーバ１０は省略されてもよい。また、管理端末５０も、バックオフィスサーバ１０への情報の提供等が不要であれば、適宜に省略されてよい。さらに、第２の形態においても、二次元コード１００に記録されるべき必須情報ＩＦａとして、シリアル番号に代えて、図１０と同様にスクリプトそれ自体が記録されてもよい。

上述した第１及び第２の形態では、バックオフィスサーバ１０、スクリプト管理サーバ２０及び決済実行サーバ３０を互いに区分して設けているが、その構成はあくまで一例であり、これらは適宜に統合されてもよい。バックオフィスサーバ１０を省略し、サービス端末４０、あるいは管理端末５０がスクリプト管理サーバ２０に直接的にアクセスするものとしてもよい。サービス端末４０は単一の端末装置として構成されることを必ずしも要しない。例えば、複数の端末装置を協働させることにより、それらの端末装置の集合を一つのサービス端末として機能させてもよい。

必須情報に含まれるべき情報には、決済手段の種類に関わりなく共通してサーバが必要とする情報である限りは適宜の情報が選択されてよい。例えば、第１の形態において、支払先の情報は、決済手段の種類に関わりなくサーバが共通して必要とする情報であるが、第１の形態ではこれを確定する情報がスクリプトデータベースＤＢ２に保持されたスクリプトに予め記述されているために、サービス端末４０側では二次元コード１００に支払先の情報を記録する必要がない。しかしながら、支払先の情報をサービス端末４０側で二次元コード１００に記録するように第１の形態が変形されてもよい。この場合には、支払先の異同の観点でスクリプトを区別して作成する必要がなく、異なる支払先間で共通のスクリプトを利用できる可能性がある。第２の形態においても、スクリプトに記述される情報の一部の確定値を二次元コード１００に含めるようにしてもよい。例えば、シリアル番号に加えて支払額の確定値が二次元コード１００に記録されるようにしてもよい。このように、サービス端末にて表示すべき情報画像に対してどのような情報を必須情報として記録すべきか、は、サービスの異同に関わりなく情報画像に記録すべき情報の種類を共通化できる限りにおいて適宜に変更されてよい。

上記の形態では情報画像の一例として二次元コード１００が利用されているが、情報画像は必須情報をユーザ端末６０が取得可能な態様で記録できる限りにおいて、二次元コードに限らず種々のフォーマットで情報を記録するように設けられてよい。

上記の形態では、決済実行サーバ３０が口座管理サーバ７０と連携して決済処理を実行し、かつ決済処理の結果を品目管理サーバ８０及びサービス管理サーバ９０に通知してこれらのサーバ８０、９０で関連した処理を実行するものとしたが、例えばサーバ８０、９０は、決済サービスを提供するための処理を実行する上で必須なものではなく、決済端末にて提供されるべき決済サービスで利用されるべき決済手段の種類、その決済手段による決済処理を実現するためにサーバが実行すべき処理の内容に応じて適宜に追加、変更又は削除されてよい。また、決済実行サーバ３０は口座管理サーバ７０として例示した他のサーバと連携して決済処理を実行するように構成されることを必ずしも要しない。例えば、決済実行サーバ３０自身がユーザの電子通貨の残高を管理するといったように決済処理を自ら実行可能であってもよい。

（第３の形態）
次に、図１４〜図１７を参照して本発明の第３の形態を説明する。なお、各図において、第１の形態と共通する部分には同一の参照符号を付し、以下では相違点を中心として説明する。図１４は第３の形態に係る決済システム１Ｂの概略構成を示している。本形態の決済システム１Ｂは、第１又は第２の形態におけるスクリプトを利用することなく複数種類の決済サービスからいずれか一つの決済サービスを選択して決済処理を進めるように構成されている。

図１４に示すように、決済システム１Ｂは、サービス提供者が運用するサービス端末４０にて二次元コード１００を表示し、ユーザの個人的用途に利用されるユーザ端末６０にて二次元コード１００に記録された必須情報を読み取って決済処理を実行する点では第１及び第２の形態の決済システム１と共通する。ただし、第１及び第２の形態におけるバックオフィスサーバ１０及びスクリプト管理サーバ２０は省略されている。管理端末５０は、例えばサービス端末４０の管理や設定、あるいは決済実行サーバ３０Ａとの情報交換の必要に応じて適宜に設けられてよい。また、図１４では図示を省略したが、図１の品目管理サーバ８０も例えばサービス端末４０側への情報提供の必要等に応じて適宜に設けられてよい。口座管理サーバ７０及びサービス管理サーバ９０は第１及び第２の形態と同様である。口座管理サーバ７０は、第１及び第２の形態のそれと同様に、特定種類の電子通貨の口座の残高をユーザ識別情報と関連付けて管理するサーバであって、決済実行サーバ３０Ａと連携して電子通貨による料金の支払いを処理するサーバの一例である。決済実行サーバ３０Ａが決済処理において連携するサーバは、図示の口座管理サーバ７０に限らず、他の種類の電子通貨を管理するサーバ、銀行口座からの料金の引き落としを処理するサーバ、クレジットカードによる支払いを処理するサーバ等が適宜に使い分けられてよい。決済実行サーバ３０Ａには、連携相手となるサーバとの間で決済を処理するための手順を記述したコンピュータプログラム群が予め実装され、それらのコンピュータプログラムが料金の支払いに用いられるべき決済手段の選択に応じて適宜に実行される。また、決済実行サーバ３０Ａには、処理可能な支払方法、つまり料金の支払いに利用可能な決済手段を特定するための情報が予め与えられている。その情報は、例えば第１及び第２の形態においてユーザ端末６０に提供される決済手段のリストの情報として与えられてよい。

図１５は、決済システム１Ｂにおけるサービス端末４０からユーザ端末６０を経由して決済実行サーバ３０Ａへと情報が伝達される様子の一例を示している。図示の例においては、まずサービス端末４０（図では店頭端末４０Ｂを示すが、他のサービス端末でもよい。）にて生成される二次元コード１００には支払先及び支払内容の情報が必須情報ＩＦａＡに含まれている。支払先が含まれているのは、サービス端末４０にて支払いが発生するごとに、サービス提供者の都合、あるいは販売される商品、サービスの種類等に応じて支払先が適宜に変更される可能性があり、個々の支払いにおける事情に対応するためにはサービス端末４０側で支払先を指定することが好都合だからである。ただし、例えば決済手段に応じて支払先が固定的に定まるといったように、サービス端末４０間での支払先の相違を考慮する必要がない場合には、決済実行サーバ３０Ａに対して予め支払先の情報を与えておくことにより必須情報ＩＦａＡから支払先の情報が省略されてもよい。

二次元コード１００を読み取ったユーザ端末６０では、二次元コード１００に含まれていた支払先及び支払内容の情報に対してユーザ認証コード及び決済が確定情報として付加されて決済情報ＩＦｂＡが生成され、得られた決済情報ＩＦｂＡが決済実行サーバ３０Ａに送信される。ただし、決済情報ＩＦｂＡの送信は一度に行われることを必須とするものではない。例えば、支払方法を除く情報、例えばユーザ認証コードが一次情報の一例として決済実行サーバ３０Ａに先行して送信され、支払方法の情報が決済実行サーバ３０Ａから提供される決済手段リストに基づいてユーザに決済手段を選択させることにより確定され、その確定後に、未送信の情報がユーザ端末６０から決済実行サーバ３０Ａに送信されてよい。ユーザ認証コード等の送信に先行して、決済実行サーバ３０Ａから決済手段のリストを取得し、そのリストに従って決済手段をユーザに選択させることによって決済情報ＩＦｂＡを確定させ、得られた決済情報ＩＦｂＡを決済実行サーバ３０Ａに一括して送信してもよい。決済実行サーバ３０Ａでは、ユーザ端末６０から取得した決済情報ＩＦｂＡに従って決済処理が実行される。

図１６は、決済システム１Ｂの要部に関する具体的な構成の一例を示している。図１６の例において、決済実行サーバ３０Ａには、そのコンピュータハードウエアとコンピュータプログラムＰｓ３Ａとの組み合わせによって実現される論理的装置として、決済実行部３１Ａ及び決済通知部３２が設けられる。決済実行部３１Ａは、決済手段のリストをユーザ端末６０に提供し、あるいはユーザ端末６０から受け取った決済情報に従って口座管理サーバ７０等と連携しつつ決済処理を実行する。決済通知部３２は決済実行部３１Ａが実行した決済処理の結果の情報をサービス端末４０等に通知する点で第１及び第２の形態のそれと同様である。

サービス端末４０には、そのコンピュータハードウエアとコンピュータプログラムＰｔ１Ａとの組み合わせによって実現される論理的装置として、支払制御部４１及びコード制御部４２Ａが設けられる。支払制御部４１は第１の形態のそれと同様である。コード制御部４２Ａは二次元コード１００に必須情報ＩＦａＡの一部として含めるべき支払内容を支払制御部４１から取得し、得られた情報とサービス端末４０に予め与えられている支払先の情報とを合わせて必須情報ＩＦａＡを生成し、得られた必須情報ＩＦａＡに基づいて二次元コード１００を生成し、サービス端末４０に表示させる。

ユーザ端末６０には、そのコンピュータハードウエアとコンピュータプログラムＰｔ２Ａとの組み合わせによって実現される論理的装置として、コード取得部６１及び支払制御部６２Ａが設けられる。コード取得部６１は第１の形態のそれと同様である。支払制御部６２Ａは、コード取得部６１が取得した必須情報ＩＦａＡに対してユーザ認証コード、あるいは支払方法の情報等を付加して決済情報ＩＦｂＡを生成し、得られた決済情報ＩＦｂＡを決済実行サーバ３０に送信するといった料金の支払いに必要な各種の処理を実行する。

図１７は、図１６に示した決済システム１Ｂにおいて決済サービスを提供するために実行される処理の手順の一例を示すフローチャートである。図１７の手順においては、まずサービス端末４０の支払制御部４１にてユーザの支払内容が決定され（ステップＳ２１）、コード制御部４２Ａにて二次元コード１００が生成されて表示される（ステップＳ２２）。これらの手順は図８のステップＳ２１、Ｓ２２の処理と同様であるが、二次元コード１００に記録される必須情報ＩＦａＡは、図１５に例示したように支払先及び支払内容の情報を含むものである。

サービス端末４０における処理と並行して、ユーザ端末６０の支払制御部６２Ａではユーザ認証処理が行われる（ステップＳ３０）。この処理は、ユーザ端末６０にてユーザ認証コードを入力させてユーザ端末６０がユーザを識別するローカル処理であってもよいし、ユーザ端末６０とサービス管理サーバ９０とが連携してユーザを認証する処理であってもよい。ユーザ認証処理が完了すると、ユーザ端末６０では、コード取得部６１により二次元コード１００に含まれている必須情報ＩＦａＡが取得され（ステップＳ３１）、支払制御部６２ＡによりステップＳ３０のユーザ認証処理で得られているユーザ認証コードが端末付加情報の一例として必須情報ＩＦａに付加され（ステップＳ３２）、得られた情報が決済情報ＩＦｂＡの一部である一次情報の一例として支払制御部６２から決済実行サーバ３０Ａに送信されて決済処理が要求される（ステップＳ３３）。

決済実行サーバ３０Ａでは、今回の決済処理で利用することが可能な決済手段のリストが選択情報の一例として決済実行部３１からユーザ端末６０に提供される（ステップＳ３７Ａ）。このリストは基本的には第１の形態と同様にステップＳ３３で送信される情報に基づいて決定されてよい。ただし、第３の形態では第１の形態におけるスクリプトが用いられていないため、スクリプトに決済手段の候補を予め記述し、それらの候補をリストとして提供することはできない。しかしながら、例えば支払先、あるいは支払方法と関連付けて利用可能な決済手段を指定する情報を予め決済実行サーバ３０Ａに与えておけば、ステップＳ３３で送信される情報に基づいて今回の決済処理で利用可能な決済手段を判別し、その判別結果に従って決済手段のリストを生成してユーザ端末６０に提供することが可能である。一方、ステップＳ３３にて送信される情報に関わりなく、決済実行サーバ３０Ａが処理可能な決済手段のリストをユーザ端末６０に提供するようにしてもよい。

リストを受け取ったユーザ端末６０の支払制御部６２Ａでは、提供されたリストからユーザに決済手段を選択させる処理が行われ、その選択結果が決済情報ＩＦｂＡのさらなる一部である二次情報の一例として決済実行サーバ３０Ａに送信される（ステップＳ３８）。これらの処理も第１及び第２の形態と同様である。決済処理を実行してよいか否かをユーザに確認させる処理が併せて行われ、ユーザが決済実行を承認した場合に限って決済手段の選択結果が送信されるものとしてもよい。

決済手段の選択結果が決済実行サーバ３０Ａに送信されると、決済実行部３１Ａにより決済情報ＩＦｂＡに含まれている情報、すなわち、ユーザ認証コード、支払方法及び支払内容を参照しつつ決済実行部３１Ａにより決済処理が実行される（ステップＳ３９）。決済処理は、第１の形態と同様に、決済情報ＩＦｂＡに含まれている支払方法に従って口座管理サーバ７０等と連携して行われてよい（ステップＳ４０）。決済処理が実行されると、口座管理サーバ７０から決済実行サーバ３０Ａに支払処理の結果が通知され（ステップＳ４２）、決済実行サーバ３０Ａの決済通知部３２からサービス端末４０、ユーザ端末６０、サービス管理サーバ９０に支払結果が通知される（ステップＳ４５）。支払いが正常に完了していれば、サービス端末４０の支払制御部４１Ａでは、料金の支払い完了を条件として許可されるべき所定の処理が後続処理として開始され（ステップＳ４６）、ユーザ端末６０では支払いが完了した旨をユーザに通知する処理が後続処理の一例として実行される（ステップＳ４７）。さらに、サービス管理サーバ９０では、料金の支払い完了を条件として許可されるべき所定の処理が関連処理として実行される（ステップＳ４８）。これらの後続処理、あるいは関連処理は第１及び第２の形態と同様にして実施されてよい。

図１６及び図１７に示した形態では、コード制御部４２Ａが図１７のステップＳ２２の処理を実行することにより情報画像表示手段の一例として機能し、コード取得部６１が図１７のステップＳ３１の処理を実行することにより情報取得手段の一例として機能し、支払制御部６２Ａが図１７のステップＳ３２、Ｓ３３及びＳ３８の処理を実行することにより決済情報提供手段の一例として機能し、決済実行部３１Ａが図１７のステップＳ３９の処理を実行することにより決済実行手段の一例として機能し、決済通知部３２が図１７のステップＳ４５の処理を実行することにより結果情報提供手段の一例として機能する。また、支払制御部６２Ａが図１７のステップＳ３２及びＳ３３の処理を実行することにより一次情報提供手段の一例として機能し、支払制御部６２Ａが図１７のステップＳ３８の処理を実行することにより二次情報提供手段の一例として機能し、決済実行部３１Ａが図１７のステップＳ３７Ａの処理を実行することにより選択情報提供手段の一例として機能する。さらに、サービス管理サーバ９０は図１７のステップＳ４８の処理を実行することにより関連処理実行手段の一例として機能する。

上述した第３の形態においても、適宜の変形又は変更を施すことが可能である。例えば、第３の形態でも、情報画像は二次元コード１００に限らず種々のフォーマットの画像が情報画像として利用されてよい。サービス管理サーバ９０も適宜に追加、変更又は削除されてよい。

さらに、第１〜第３の形態のいずれに対しても適用可能な変形例を以下に例示する。

各形態では、サービス端末４０を決済端末としても機能させたが、サービス端末と決済端末とは互いに異なる端末装置として設けられてもよい。その場合、決済端末が受け取る決済処理の結果に応じてサービス端末におけるサービスの提供が制御されるといったように、サービス端末と決済端末とを連動させてもよい。要するに、サービス端末は決済端末と関連付けて動作するものであれば足り、両端末は同一装置によって実現されてもよいし、互いに関連付けて動作する別装置として設けられてもよい。

各形態では決済が発生する都度に予め決済実行サーバ３０、３０Ａからユーザ端末６０に決済手段のリストを選択情報の一例として提供するものとしたが、選択情報を提供する時期は必ずしも個々の決済が発生した時点であることを要しない。例えば決済実行サーバ３０、３０Ａ側で選択情報が更新されるごとに、あるいは定期的に決済実行サーバ３０、３０Ａ側からユーザ端末６０に選択情報を配信し、個々の決済時にはユーザ端末６０が自らの記憶装置に保存された選択情報を参照してユーザに決済手段を選択させるようにしてもよい。例えば、ユーザ端末６０に実装されるべきコンピュータプログラムＰｔ２、Ｐｔ２Ａのアップデートモジュールを決済実行サーバ３０、３０Ａあるいは他のサーバから適宜に配信する仕組みが設けられる場合、そのアップデートモジュールの配信を利用して選択情報をユーザ端末６０に予め与えておくことができる。要するに、選択情報を決済処理が発生する都度にユーザ端末６０に提供する処理は必須ではなく、決済の発生時点でユーザ端末６０が決済手段を選択できる限りにおいて、選択情報は適宜の態様でユーザ端末６０に与えられてよい。したがって、上述したように、ユーザ端末６０からの決済情報ＩＦｂ、ＩＦｂＡの送信も一次情報及び二次情報に分けて行われることを必須とせず、ユーザ端末６０に既に選択情報が存在する場合には決済情報ＩＦｂ、ＩＦｂＡを一括して送信することも可能である。

一方、各形態では、ユーザ端末６０からの決済情報ＩＦｂ、ＩＦｂＡの送信を、一次情報及び二次情報に分けて行うことと関連して、決済実行サーバ３０、３０Ａが一次情報に基づいて利用可能な決済手段の種類を判別し、その判別結果に従って選択情報としての決済手段のリストをユーザ端末６０に提供する可能性について説明した。例えば、第１及び第２の形態では、シリアル番号に従ってスクリプトを特定し、そのスクリプトに記述された決済手段の候補に基づいてリストを生成することが可能である。第３の形態では、支払先、支払内容等に基づいて決済手段のリストを生成することが可能である。これに代えて、あるいは加えて、ユーザ認証コード等のユーザ識別情報を利用して決済手段の候補を判別し、選択情報を提供することも可能である。そのような処理は、例えば、ユーザ識別情報と選択情報とを対応付けて決済実行サーバ３０、３０Ａに保持させ、ユーザ端末６０から取得したユーザ識別情報に対応する選択情報をユーザ端末６０に提供することによって実現することができる。その場合、ユーザが利用を希望する決済手段の候補を予めユーザからユーザ端末６０を介して決済実行サーバ３０、３０Ａに指定させ、その指定内容をユーザ認証コード等のユーザ識別情報と対応付けて決済実行サーバ３０、３０Ａに保持しておくようにしてもよい。さらにユーザ識別情報と関連付けて決済手段の種類に対するデフォルト値を設定し、あるいは優先順位を設定することも可能である。この場合には決済手段の選択に関するユーザの利便性を高めることが可能である。デフォルト設定等は、ユーザからの指示に基づいて処理されてもよいし、ユーザの利用履歴等に基づいて自動的に処理されてもよい。

あるいは、サービス端末４０を適宜の単位でグループに区別し、グループに応じて選択情報が差別化されてもよい。そのようなグループは個々のサービス端末４０ごとに区別されてもよいし、サービス提供者の異同に応じて区別されてもよい。一例として、サービス提供者が運営する店舗などを単位としてサービス端末４０をグループに区別し、店舗ごとに選択情報が差別化されてもよい。この場合には、グループ別に決済手段として利用可能な決済手段の候補をサービス提供者等に指定させ、その指定内容をグループの識別情報と対応付けて決済実行サーバ３０、３０Ａに保持しておけばよい。ただし、ユーザ端末６０から選択情報の提供が求められた場合には、いずれのグループに対応する選択情報を提供すべきかを判別する必要があるため、二次元コード１００には、グループの識別情報を必須情報の一部として含めておき、これをユーザ端末６０から決済実行サーバ３０、３０Ａに提供することを要する。

上記の各形態では、関連処理の一例として、例えば、サービス管理サーバ９０が提供するサービスに対してユーザに特典を付与する例を挙げたが、関連処理はこれに限られない。例えば、第３の形態において、図１７のステップＳ３０のユーザ認証処理がローカル処理である場合、そのユーザはサービス管理サーバ９０に関してはユーザ認証を済ませていないことがある。一方、決済実行サーバ３０ＡはステップＳ３１の処理でユーザ認証コードを取得している。したがって、ステップＳ４８の関連処理として、決済実行サーバ３０Ａからサービス管理サーバ９０にユーザ認証コードを提供し、関連処理の一種としてサービス管理サーバ９０にてユーザ認証処理を実行することも可能である。この場合、サービス端末４０の利用に関して決済システム１Ａにて料金の支払いを済ませると、それと連動してサービス管理サーバ９０におけるユーザ認証が完了することになる。したがって、ユーザは、サービス管理サーバ９０に対して別途ユーザ認証を求めることなく、料金の支払いを契機としてサービス管理サーバ９０が提供するサービスを利用しつつサービス端末４０を利用することが可能となり、ユーザの利便性が向上する。例えばゲーム機４０Ａに対するプレイデータの送信といったサービスをサービス管理サーバ９０がユーザ認証を条件として提供する場合、ユーザは料金の支払い完了後、別途のユーザ認証を必要とせずにサービス管理サーバ９０のサービスを利用しつつゲーム機４０Ａを利用することが可能である。このような変形例は、第１及び第２の形態の決済システム１、１Ａにおいても同様に適用することが可能である。

また、サービス端末４０にて提供されるサービスを識別するためのサービス識別情報を二次元コード１００に必須情報の一部として含めておき、これをユーザ端末６０から決済情報の一部として決済実行サーバ３０、３０Ａに提供するようにしてもよい。あるいは、ユーザ端末６０にてサービス識別情報を決済情報の一部として付加し、これを決済実行サーバ３０、３０Ａに提供するようにしてもよい。その場合、決済実行サーバ３０、３０Ａは、決済処理がどのようなサービスに対するものか、をサービス識別情報に従って判別することが可能である。よって、サービス識別情報と関連付けられた処理を関連処理の一種として自ら実行し、あるいはサービス管理サーバ９０等の連携相手のサーバに実行させることができる。例えば、サービス端末４０にて提供されるサービスがゲーム機４０Ａにおけるゲームサービスと判別された場合、そのゲームサービスに固有の関連処理を実行するといった処理が可能となる。

各形態の決済システム１、１Ａ、１Ｂでは決済実行サーバ３０、３０Ａにて決済処理が行われるために、決済実行サーバ３０、３０Ａ側で各サービス端末４０の売上を把握する情報を生成することができる。一方、サービス端末４０には、例えば現金による料金の徴収を可能とする仕組みが実装されることがあり、決済実行サーバ３０、３０Ａではそうしたサービス端末４０側で完結する決済、すなわち決済システム１、１Ａ、１Ｂを経由しない決済に基づく売上を把握することができない。このような状況で、例えば、決済システム１、１Ａ、１Ｂを介した決済による売上と、サービス端末４０にて完結する決済による売上とを合算して管理する必要がある場合には、例えば図１８に示すように、サーバ側で売上を合算して集計できる仕組みが設けられてもよい。図１８の例では、サービス端末４０の一例としてのゲーム機４０Ａに現金による料金支払いを処理する料金徴収装置４３が料金徴収手段の一例として設けられ、品目管理サーバ８０が売上を管理する集計手段の一例として機能する。この場合、ゲーム機４０Ａでは料金徴収装置４３を介して徴収した料金の額が店舗売上情報として生成され、得られた情報が品目管理サーバ８０に適時に提供される。一方、決済実行サーバ３０では、決済処理が行われるごとに、品目管理サーバ８０に対してシステム売上情報が提供される。システム売上情報は例えば図９のステップＳ４３にて通知される情報としてよい。品目管理サーバ８０では、得られた店舗売上情報及びシステム売上情報とに基づいて、ゲーム機４０Ａが自ら徴収した料金と、決済システム１を介して徴収された料金とが合算されて集計情報が生成される。集計情報の生成あるいは更新は、例えば一月ごとといった適宜の周期で行われてよい。また、売上の集計は、サービス端末４０が設置された店舗等、適宜の集合を単位として行われてよい。なお、売上を集計するサーバは品目管理サーバ８０に限らず、適宜のサーバが担当してよい。図１８は第１の形態を例に挙げているが、このような変形は第２及び第３の形態でも同様に適用可能である。

上述した実施の形態及び変形例のそれぞれから導き出される本発明の各種の態様を以下に記載する。なお、以下の説明では、本発明の各態様の理解を容易にするために添付図面に図示された対応する構成要素を括弧書きにて付記するが、それにより本発明が図示の形態に限定されるものではない。

本発明の一態様に係る決済システム（１；１Ａ；１Ｂ）は、サーバ（３０；３０Ａ）及び当該サーバに対するクライアントとして機能するユーザ端末（６０）及び決済端末（４０）を含んだクライアントサーバシステムとして構築され、前記決済端末にて提示される情報画像（１００）に含まれている決済処理に必要な情報が前記ユーザ端末を介して前記サーバに提供されることにより、ユーザが支払うべき料金を決済するための決済処理が前記サーバにて実行される決済システムであって、決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報（ＩＦａ；ＩＦａＡ）が前記決済処理に必要な情報として含まれるようにして前記情報画像を前記決済端末に表示させる情報画像表示手段（４２、Ｓ２２；４２Ａ、Ｓ２２）と、前記情報画像に含まれている前記必須情報を前記ユーザ端末に取得させる情報取得手段（６１、Ｓ３１）と、複数種類の決済手段から決済に用いられるべき決済手段を、前記ユーザ端末を介して前記ユーザに選択させ、選択された決済手段を識別するための決済手段識別情報（一例として支払方法の情報）と前記情報取得手段が取得した前記必須情報とを含む決済情報（ＩＦｂ；ＩＦｂＡ）を前記ユーザ端末から前記サーバに送信させる決済情報提供手段（６２、Ｓ３２、Ｓ３３、Ｓ３８；６２Ａ、Ｓ３２、Ｓ３３、Ｓ３８）と、前記サーバに、前記決済情報に含まれている前記決済手段識別情報に基づいて決済手段を識別させ、前記決済情報に含まれている前記必須情報に応じた決済が、識別された決済手段に従って行われるように前記決済処理を実行させる決済実行手段（３０、Ｓ３９；３０Ａ、Ｓ３９）と、前記決済処理が実行された結果を示す結果情報を前記サーバから前記決済端末に送信させる結果情報提供手段（３２、Ｓ４５）と、を備えたものである。

本発明の一態様に係るコンピュータプログラム（Ｐｓ１〜Ｐｓ３、Ｐｔ１、Ｐｔ２；Ｐｓ３Ａ、Ｐｔ１Ａ、Ｐｔ２Ａ）は、サーバ（３０；３０Ａ）及び当該サーバに対するクライアントとして機能するユーザ端末（６０）及び決済端末（４０）を含んだクライアントサーバシステムとして構築され、前記決済端末にて提示される情報画像（１００）に含まれている決済処理に必要な情報が前記ユーザ端末を介して前記サーバに提供されることにより、ユーザが支払うべき料金を決済するための決済処理が前記サーバにて実行される決済システム（１；１Ａ；１Ｂ）に適用されるコンピュータプログラムであって、前記決済システムに含まれたコンピュータを、決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報（ＩＦａ；ＩＦａＡ）が前記決済処理に必要な情報として含まれるようにして前記情報画像を前記決済端末に表示させる情報画像表示手段（４２、Ｓ２２；４２Ａ、Ｓ２２）、前記情報画像に含まれている前記必須情報を前記ユーザ端末に取得させる情報取得手段（６１、Ｓ３１）、複数種類の決済手段から決済に用いられるべき決済手段を、前記ユーザ端末を介して前記ユーザに選択させ、選択された決済手段を識別するための決済手段識別情報（一例として支払方法の情報）と前記情報取得手段が取得した前記必須情報とを含む決済情報（ＩＦｂ；ＩＦｂＡ）を前記ユーザ端末から前記サーバに送信させる決済情報提供手段（６２、Ｓ３２、Ｓ３３、Ｓ３８；６２Ａ、Ｓ３２、Ｓ３３、Ｓ３８）、前記サーバに、前記決済情報に含まれている前記決済手段識別情報に基づいて決済手段を識別させ、前記決済情報に含まれている前記必須情報に応じた決済が、識別された決済手段に従って行われるように前記決済処理を実行させる決済実行手段（３０、Ｓ３９；３０Ａ、Ｓ３９）、及び前記決済処理が実行された結果を示す結果情報を前記サーバから前記決済端末に送信させる結果情報提供手段（３２、Ｓ４５）、として機能させるように構成されたものである。

上記態様によれば、決済端末では、決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報が決済処理に必要な情報として含まれるようにして情報画像を表示させる一方で、いずれの種類の決済手段を決済に用いるかに関してはユーザ端末を介してユーザに選択させ、その選択結果と情報画像に含まれている情報とが含まれた決済情報がユーザ端末からサーバへと送信される。したがって、決済端末側にて情報画像に記録されるべき必須情報は、いずれの種類の決済手段が用いられるかに関わりなく共通のフォーマットで情報画像に記録することが可能である。したがって、新たな決済サービスを導入する場合でも決済端末側では、その決済サービスに対応する独自の情報を含んだ情報画像を表示させるプログラムを追加する必要がなく、新たな決済サービスに対応する専用のハードウエアを設ける、といった設備投資も不要である。一方、新たな決済サービスへの対応は、ユーザ端末側にて新たな決済サービスに対応する決済手段を選択肢として追加し、かつサーバ側でその新たな決済サービスに対応する決済手段に従って決済処理を実行するためにプログラムを追加するといった措置によって実現できる。それにより、決済端末側で要する負担を軽減しつつ種々の決済サービスに対応することが可能である。

なお、本発明の一態様に係るコンピュータプログラムは、記憶媒体に記憶された状態で提供されてもよい。この記憶媒体を用いれば、例えばコンピュータに本発明に係るコンピュータプログラムをインストールして実行することにより、そのコンピュータを利用して本発明のシステムを実現することができる。コンピュータプログラムを記憶した記憶媒体は、ＣＤＲＯＭ等の非一過性の記憶媒体であってもよい。

上記の態様において、前記必須情報は、前記ユーザが支払うべき料金及び当該料金が支払われるべき相手の少なくともいずれか一方を指定する情報を含むようにしてもよい。ユーザが支払うべき料金、あるいは料金が支払われるべき相手に関する情報は、決済を処理するにあたって、決済手段の種類を問わず共通して必要となる情報である。また、料金が固定されていない場合には、支払いが発生する都度に料金が変動するため、その料金を決済端末側から指定する必要がある。支払いの相手が固定されていない場合も、同様に支払いが発生する都度にその相手を決済端末側から指定する必要がある。このような場合、料金又は支払いの相手に関する情報は、決済手段の種類を問わず共通して定めるべき情報であって、その種の情報を情報画像に含めても決済手段の種類を問わず情報画像のフォーマットを共通化することが可能であり、決済端末側の負担の軽減を図ることができる。

前記決済情報提供手段には、前記必須情報を含む一次情報を前記決済情報の一部として前記ユーザ端末から前記サーバに送信させる一次情報提供手段（６２、Ｓ３２、Ｓ３３；６２Ａ、Ｓ３２、Ｓ３３）と、前記決済手段識別情報を含む二次情報を前記決済情報の一部として前記ユーザ端末から前記サーバに送信させる二次情報提供手段（６２、Ｓ３８；６２Ａ；Ｓ３８）とが設けられ、前記サーバには、前記一次情報に基づいて、前記必須情報に応じた決済にて用いることが可能な決済手段を判別し、判別された決済手段を、前記決済に用いるべき決済手段として選択可能な決済手段として示した選択情報を前記ユーザ端末に送信する選択情報提供手段（３１、Ｓ３７；３１Ａ、Ｓ３７Ａ）が設けられ、前記二次情報提供手段は、前記サーバから送信された前記選択情報に基づいて、前記必須情報に応じた決済にて用いることが可能な決済手段を前記ユーザに提示して前記決済に用いるべきいずれか一つの決済手段を前記ユーザに選択させ、選択された決済手段が前記決済手段識別情報にて識別されるようにして前記二次情報を前記ユーザ端末から前記サーバに送信させてもよい。この形態によれば、ユーザ端末から提供される一次情報に従って選択情報を適宜に変化させることができる。したがって、決済が発生する都度に、その決済に適した決済手段の候補をユーザに提示してユーザにいずれかの決済手段を選択させることができる。

前記決済情報提供手段は、前記ユーザ端末のユーザを識別するためのユーザ識別情報が含まれるようにして前記決済情報を前記ユーザ端末から前記サーバに送信させ、前記決済実行手段は、前記ユーザ識別情報と関連付けて前記サーバに保持されている情報を参照して前記決済処理を実行してもよい。これによれば、ユーザを識別して決済を処理する各種の仕組みを利用して決済処理を実行することができる。

上記態様において、前記決済端末と関連付けて動作するように設けられ、かつ前記ユーザに所定のサービスを提供するサービス端末（４０）を決済システムが備え、前記サービス端末は、前記結果情報提供手段によって送信される前記結果情報が、前記料金の決済が完了したことを示す場合に前記サービスを前記ユーザに提供してもよい。これによれば、サービス端末によるサービスの提供を決済システムによる決済の完了と関連付けて制御することができる。

前記決済情報提供手段は、前記ユーザ端末のユーザを識別するためのユーザ識別情報が含まれるようにして前記決済情報を前記ユーザ端末から前記サーバに送信させ、前記決済情報に含まれているユーザ識別情報に関連付けられた処理を前記決済処理とは異なる関連処理として前記サーバに実行させる関連処理実行手段（９０、Ｓ４８）を決済システムがさらに備えてもよい。これによれば、決済のためにサーバ側に提供されるユーザ識別情報を利用して、決済処理とは別の関連処理を並行して実行することができる。したがって、関連処理の実行のためにユーザ識別情報をユーザ端末からサーバ側に別途提供する処理を省略することが可能となり、ユーザの利便性を高めることができる。

前記関連処理実行手段は、前記サービス端末の前記サービスに関して前記ユーザを認証する処理を前記関連処理として実行してもよい。あるいは、前記関連処理実行手段は、前記決済情報に含まれた前記ユーザ識別情報に基づいてユーザを識別し、識別されたユーザに対して特典を付与する処理を前記関連処理として実行してもよい。これらの形態によれば、ユーザ認証、あるいはユーザに対する特典の付与を決済処理と連動して処理することができるので、決済システムの付加価値を高めることが可能である。

前記決済情報提供手段は、前記サービス端末にて提供されるサービスを識別するためのサービス識別情報が含まれるようにして前記決済情報を前記ユーザ端末から前記サーバに送信させ、前記決済情報に含まれているサービス識別情報に関連付けられた処理を前記決済処理とは異なる関連処理として前記サーバに実行させる関連処理実行手段（９０）をさらに備えてもよい。これによれば、決済処理と並行して、サービス端末にて提供されるサービスに固有の処理を関連処理として実行することにより、決済システムの付加価値を高めることが可能である。

前記サービス端末には、前記料金を前記決済実行手段による決済処理を用いることなく前記ユーザから徴収する料金徴収手段（４３）が設けられ、前記サーバには、前記料金徴収手段が徴収した料金の額を前記サービス端末から取得し、得られた料金の額と前記決済処理にて決済された料金の額とを所定の集計単位ごとに集計する集計手段（８０）が設けられてもよい。これによれば、サービス端末それ自体が料金を徴収する仕組みを有している場合でも、決済システムを利用して徴収した料金とサービス端末が徴収した料金とを集計し、得られた売上を一括して処理することが可能である。

１、１Ａ 決済システム
３０、３０Ａ 決済実行サーバ
３１、３１Ａ 決済実行部（決済実行手段、選択情報提供手段）
３２ 決済通知部（結果情報提供手段）
４０ サービス端末（決済端末）
４０Ａ ゲーム機
４０Ｂ 店頭端末
４１ 支払制御部
４２、４２Ａ コード制御部（情報画像表示手段）
４３ 料金徴収装置（料金徴収手段）
６０ ユーザ端末
６１ コード取得部（情報取得手段）
６２、６２Ａ 支払制御部（決済情報提供手段、一次情報提供手段、二次情報提供手段）
７０ 口座管理サーバ
８０ 品目管理サーバ（集計手段）
９０ サービス管理サーバ（関連処理実行手段）
１００ 二次元コード（情報画像）

Claims (11)

1. サーバ及び当該サーバに対するクライアントとして機能するユーザ端末及び決済端末を含んだクライアントサーバシステムとして構築され、前記決済端末にて提示される情報画像に含まれている決済処理に必要な情報が前記ユーザ端末を介して前記サーバに提供されることにより、ユーザが支払うべき料金を決済するための決済処理が前記サーバにて実行される決済システムであって、
   決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報が前記決済処理に必要な情報として含まれるようにして前記情報画像を前記決済端末に表示させる情報画像表示手段と、
   前記情報画像に含まれている前記必須情報を前記ユーザ端末に取得させる情報取得手段と、
   複数種類の決済手段から決済に用いられるべき決済手段を、前記ユーザ端末を介して前記ユーザに選択させ、選択された決済手段を識別するための決済手段識別情報と前記情報取得手段が取得した前記必須情報とを含む決済情報を前記ユーザ端末から前記サーバに送信させる決済情報提供手段と、
   前記サーバに、前記決済情報に含まれている前記決済手段識別情報に基づいて決済手段を識別させ、前記決済情報に含まれている前記必須情報に応じた決済が、識別された決済手段に従って行われるように前記決済処理を実行させる決済実行手段と、
   前記決済処理が実行された結果を示す結果情報を前記サーバから前記決済端末に送信させる結果情報提供手段と、
   決済システム。
2. 前記必須情報は、前記ユーザが支払うべき料金及び当該料金が支払われるべき相手の少なくともいずれか一方を指定する情報を含む請求項１に記載の決済システム。
3. 前記決済情報提供手段には、前記必須情報を含む一次情報を前記決済情報の一部として前記ユーザ端末から前記サーバに送信させる一次情報提供手段と、前記決済手段識別情報を含む二次情報を前記決済情報の一部として前記ユーザ端末から前記サーバに送信させる二次情報提供手段とが設けられ、
   前記サーバには、前記一次情報に基づいて、前記必須情報に応じた決済にて用いることが可能な決済手段を判別し、判別された決済手段を、前記決済に用いるべき決済手段として選択可能な決済手段として示した選択情報を前記ユーザ端末に送信する選択情報提供手段が設けられ、
   前記二次情報提供手段は、前記サーバから送信された前記選択情報に基づいて、前記必須情報に応じた決済にて用いることが可能な決済手段を前記ユーザに提示して前記決済に用いるべきいずれか一つの決済手段を前記ユーザに選択させ、選択された決済手段が前記決済手段識別情報にて識別されるようにして前記二次情報を前記ユーザ端末から前記サーバに送信させる、請求項１又は２に記載の決済システム。
4. 前記決済情報提供手段は、前記ユーザ端末のユーザを識別するためのユーザ識別情報が含まれるようにして前記決済情報を前記ユーザ端末から前記サーバに送信させ、
   前記決済実行手段は、前記ユーザ識別情報と関連付けて前記サーバに保持されている情報を参照して前記決済処理を実行する請求項１〜３のいずれか一項に記載の決済システム。
5. 前記決済端末と関連付けて動作するように設けられ、かつ前記ユーザに所定のサービスを提供するサービス端末を備え、
   前記サービス端末は、前記結果情報提供手段によって送信される前記結果情報が、前記料金の決済が完了したことを示す場合に前記サービスを前記ユーザに提供する請求項１〜３のいずれか一項に記載の決済システム。
6. 前記決済情報提供手段は、前記ユーザ端末のユーザを識別するためのユーザ識別情報が含まれるようにして前記決済情報を前記ユーザ端末から前記サーバに送信させ、
   前記決済情報に含まれているユーザ識別情報に関連付けられた処理を前記決済処理とは異なる関連処理として前記サーバに実行させる関連処理実行手段をさらに備えた請求項５に記載の決済システム。
7. 前記関連処理実行手段は、前記サービス端末の前記サービスに関して前記ユーザを認証する処理を前記関連処理として実行する請求項６に記載の決済システム。
8. 前記関連処理実行手段は、前記決済情報に含まれた前記ユーザ識別情報に基づいてユーザを識別し、識別されたユーザに対して特典を付与する処理を前記関連処理として実行する請求項６又は７に記載の決済システム。
9. 前記決済情報提供手段は、前記サービス端末にて提供されるサービスを識別するためのサービス識別情報が含まれるようにして前記決済情報を前記ユーザ端末から前記サーバに送信させ、
   前記決済情報に含まれているサービス識別情報に関連付けられた処理を前記決済処理とは異なる関連処理として前記サーバに実行させる関連処理実行手段をさらに備えた請求項５に記載の決済システム。
10. 前記サービス端末には、前記料金を前記決済実行手段による決済処理を用いることなく前記ユーザから徴収する料金徴収手段が設けられ、
    前記サーバには、前記料金徴収手段が徴収した料金の額を前記サービス端末から取得し、得られた料金の額と前記決済処理にて決済された料金の額とを所定の集計単位ごとに集計する集計手段が設けられている請求項５〜９のいずれか一項に記載の決済システム。
11. サーバ及び当該サーバに対するクライアントとして機能するユーザ端末及び決済端末を含んだクライアントサーバシステムとして構築され、前記決済端末にて提示される情報画像に含まれている決済処理に必要な情報が前記ユーザ端末を介して前記サーバに提供されることにより、ユーザが支払うべき料金を決済するための決済処理が前記サーバにて実行される決済システムに適用されるコンピュータプログラムであって、
    前記決済システムに含まれたコンピュータを、
    決済に用いられるべき決済手段の種類を問わず共通に定められた必須情報が前記決済処理に必要な情報として含まれるようにして前記情報画像を前記決済端末に表示させる情報画像表示手段、
    前記情報画像に含まれている前記必須情報を前記ユーザ端末に取得させる情報取得手段、
    複数種類の決済手段から決済に用いられるべき決済手段を、前記ユーザ端末を介して前記ユーザに選択させ、選択された決済手段を識別するための決済手段識別情報と前記情報取得手段が取得した前記必須情報とを含む決済情報を前記ユーザ端末から前記サーバに送信させる決済情報提供手段、
    前記サーバに、前記決済情報に含まれている前記決済手段識別情報に基づいて決済手段を識別させ、前記決済情報に含まれている前記必須情報に応じた決済が、識別された決済手段に従って行われるように前記決済処理を実行させる決済実行手段、及び
    前記決済処理が実行された結果を示す結果情報を前記サーバから前記決済端末に送信させる結果情報提供手段、として機能させるように構成された決済システムのコンピュータプログラム。