JP7482577B2 - サーバおよび通信デバイス - Google Patents

Description

特許法第３０条第２項適用 アプリ配信サービス「Ｇｏｏｇｌｅ Ｐｌａｙ」に掲載 令和１年９月２６日 アプリ配信サービス「Ａｐｐ ｓｔｏｒｅ」に掲載 令和１年９月３０日

本明細書に開示される技術分野は、通信デバイスにインストールされたプログラムと通信可能なサーバおよび通信デバイスに関する。

従来より、自社の機能ないしサービスを他社のアプリケーションプログラム（以下、本明細書では、「アプリケーションプログラム」を省略して、「アプリケーション」あるいは「アプリ」と称することがある）を介して利用可能にするために、ソフトウェア開発キット（Software Development Kit、ＳＤＫ）を提供する場合がある。

ＳＤＫを利用した技術を開示した文献としては、例えば特許文献１がある。特許文献１には、カメラアプリから利用されるカメラ制御ＳＤＫが開示されており、さらにカメラ制御ＳＤＫの利用可否を示す情報を互いに異なる２つのカメラアプリからアクセス可能な共有の記憶領域に記憶することで、あるカメラアプリで追加したカメラ制御ＳＤＫを別のカメラアプリでも利用可能にする構成が開示されている。

特開２０１６－１８５０１号公報

特許文献１では、互いに異なる２つのカメラアプリに同一のカメラ制御ＳＤＫがそれぞれ組み込まれる場合、共有の記憶領域に記憶された１つの利用可否情報、すなわち１つの情報を用いて異なる２つのカメラアプリを管理する技術について開示している。しかしながら、アプリケーションと、アプリケーションの少なくとも一部の機能を有するプログラム（ＳＤＫ）を有するアプリケーションの情報は、異なるアプリケーションの情報であるため１つの識別情報では管理することができない。

本明細書は、通信デバイスにインストール可能な少なくとも一部の機能を共通とする互いに異なるアプリケーションからの処理に基づく情報を、サーバを用いて管理可能とする技術を開示する。

上述した課題の解決を目的としてなされたサーバは、
第１アプリケーションと、
前記第１アプリケーションの少なくとも一部の機能を有するプログラムが組み込まれた第２アプリケーションと、通信可能なサーバにおいて、
前記第１アプリケーションの識別情報と、前記第２アプリケーションの識別情報と、を連携する、
ことを特徴としている。

上記装置の機能を実現するための制御方法、コンピュータプログラム、および当該コンピュータプログラムを格納するコンピュータにて読取可能な記憶媒体も、新規で有用である。

本明細書に開示される技術によれば、通信デバイスにインストール可能な少なくとも一部の機能を共通とする互いに異なるアプリケーションからの処理に基づく情報を、サーバを用いて管理可能とする技術が実現される。

実施の形態にかかる決済システムの概略構成図である。 実施の形態にかかる携帯端末の構成を示すブロック図である。 実施の形態にかかる決済サービスサーバの構成を示すブロック図である。 決済サービスサーバが有する決済ユーザＴＢの構成を示す図である。 決済サービスサーバが有する決済方法ＴＢの構成を示す図である。 決済サービスサーバが有する連携ＴＢの構成を示す図である。 決済サービスサーバが有する決済ＴＢの構成を示す図である。 決済サービスサーバが有するクーポンＴＢの構成を示す図である。 決済アプリからログイン要求する際の処理の流れを示す図である。 パートナーアプリからログイン要求する際の処理の流れを示す図である。 決済アプリから決済を行う際の処理の流れを示す図である。 決済アプリから決済履歴の照会を行う際の処理の流れを示す図である。 パートナーアプリから決済履歴の照会を行う際の処理の流れを示す図である。 パートナーサーバから決済履歴の照会を行う際の処理の流れを示す図である。 決済サービスサーバにおけるクーポン配信処理の手順を示すフローチャートである。 パートナーサーバからの要求によって決済サービスサーバからパートナーアプリにクーポンを発行する際の処理の流れを示す図である。 決済システムにおける決済ユーザＩＤと他の情報との関連を示す図である。

以下、本実施形態にかかるサーバおよび通信デバイスを含む決済システムを具体化した実施の形態について、添付図面を参照しつつ詳細に説明する。

［決済システム１００の構成］
本形態の決済システム１００は、図１に示すように、店舗端末１と、携帯端末２と、決済サービスサーバ３と、パートナーサーバ４とを備える。本形態の決済システム１００では、携帯端末２が、決済サービスサーバ３およびパートナーサーバ４とインターネット等のネットワークを介して通信可能となっている。また、決済サービスサーバ３は、携帯端末２の他、店舗端末１、パートナーサーバ４ともインターネット等のネットワークを介して通信可能となっている。携帯端末２と店舗端末１とはネットワーク上で直接的に繋がっていないが、一方が表示したコードを他方が読み取ることができる。

店舗端末１は、商品あるいはサービスを提供する店舗に設置された情報処理端末である。店舗端末１は、決済システム１００のサービスのプラットフォームを運用する決済サービス会社と提携した各店舗に備えられる。そのため、店舗端末１は、決済システム１００内に複数存在し得るが、図１では省略して１台のみ示している。

携帯端末２は、決済システム１００によってキャッシュレス決済のサービスを受けるユーザが保有する情報処理端末であり、例えばスマートフォンやＰＤＡである。携帯端末２も、決済システム１００のサービスを受けるユーザごとに存在する。そのため、携帯端末２も、決済システム１００内には複数存在し得るが、図１では省略して１台のみ示している。携帯端末２は、通信デバイスの一例である。

また、携帯端末２には、パートナーアプリ２２１と決済アプリ２２３との少なくとも一方がインストールされている。パートナーアプリ２２１は、決済サービス会社と提携した会社（以下、「パートナー」と称する）によって提供されるアプリケーションである。パートナーは、店舗端末１が備えられた店舗の少なくとも１つを運営する。パートナーアプリ２２１は、第２アプリケーションの一例である。決済アプリ２２３は、決済サービス会社によって提供されるアプリケーションである。決済アプリ２２３は、第１アプリケーションの一例である。

決済アプリ２２３は、決済機能を有している。すなわち、店舗端末１に決済アプリ２２３が示す情報を読み取らせる、あるいは店舗端末１の情報を決済アプリ２２３が読み取ることで、互いの情報が決済サービスサーバ３に渡され、決済サービスサーバ３による決済処理を受けることができる。この他、決済アプリ２２３は、決済履歴の照会や各種のクーポンの受信を行う機能を有している。

また、パートナーアプリ２２１には、決済機能を有する決済ＳＤＫ２２２が組み込まれている。決済ＳＤＫ２２２は、決済サービス会社によって提供されるプログラムである。決済ＳＤＫ２２２は決済アプリ２２３の少なくとも一部の機能を有するプログラムである。例えば、決済ＳＤＫ２２２は決済アプリ２２３と同等の決済機能を有する一方で、決済履歴の照会を行う機能の一部が決済アプリ２２３よりも制限されている。

なお、携帯端末２は、必ずしもパートナーアプリ２２１と決済アプリ２２３との両方がインストールされている必要はなく、いずれか一方がインストールされていれば、決済システム１００の決済サービスを利用することができる。すなわち、パートナーアプリ２２１がインストールされている携帯端末２と、決済アプリ２２３がインストールされている携帯端末２とが別であってもよい。

決済サービスサーバ３は、決済サービス会社が管理するサーバであり、決済処理を実行する。決済サービスサーバ３は、サーバの一例である。決済サービスサーバ３は、各種のテーブル（ＴＢ）を有している。具体的には、決済システム１００のサービスを受けるユーザの情報を記憶する決済ユーザＴＢ３２１と、各ユーザの決済方法を記憶する決済方法ＴＢ３２２と、パートナーとの連携情報を記憶する連携ＴＢ３２３と、各ユーザの決済情報を記憶する決済ＴＢ３２５と、現在登録されているクーポンの情報を記憶するクーポンＴＢ３２６と、を有している。各ＴＢは１つのＴＢから構成されてもよいし、複数のＴＢから連結されたものであってもよい。各ＴＢの詳細については後述する。

パートナーサーバ４は、パートナーが管理するサーバである。パートナーサーバ４も各種のＴＢを有しており、例えば、パートナーのサービスを受けるユーザの情報を記憶するパートナーユーザＴＢ４２１と、決済システム１００との連携を示す情報を記憶するパートナー連携ＴＢ４２２とを有している。

なお、図１中の決済サービスサーバ３およびパートナーサーバ４は、必ずしも単一のハードウェアを表すとは限らず、複数のハードウェアによって構成されていてもよい。例えば、決済サービスサーバ３の場合、決済処理が行われるハードウェア（デバイス）と、各種のＴＢを記憶するハードウェア（デバイス）と、が異なってもよい。

［携帯端末２のハードウェアの構成］
本形態の携帯端末２は、図２に示すように、ＣＰＵ２１と、メモリ２２と、を含むコントローラ２０を備えている。さらに、携帯端末２は、ユーザインタフェース（以下、「ユーザＩＦ」とする）２３と、カメラ２４と、通信インタフェース（以下、「通信ＩＦ」とする）２５とを備え、これらがコントローラ２０に電気的に接続されている。なお、図２中のコントローラ２０は、携帯端末２の制御に利用されるハードウェアやソフトウェアを纏めた総称であって、実際に携帯端末２に存在する単一のハードウェアを表すとは限らない。

ＣＰＵ２１は、メモリ２２から読み出したプログラムに従って、また、ユーザの操作に基づいて、各種の処理を実行する。メモリ２２は、ＲＯＭ、ＲＡＭを含み、さらにＨＤＤ、フラッシュメモリ等の不揮発性メモリを含み、各種のプログラムやデータを記憶する。メモリ２２には、例えば、前述した決済ＳＤＫ２２２が組み込まれたパートナーアプリ２２１や、決済アプリ２２３が記憶される。

ユーザＩＦ２３は、ユーザによる入力操作を受け付けるハードウェアと、情報を表示するハードウェアを含む。ユーザＩＦ２３は、例えば、入力機能と表示機能との両方を備えたタッチパネルが該当する。カメラ２４は、撮影を行うためのハードウェアを含む。通信ＩＦ２５は、外部装置との通信を行うためのハードウェアを含む。

［決済サービスサーバ３のハードウェアの構成］
本形態の決済サービスサーバ３は、図３に示すように、ＣＰＵ３１と、メモリ３２と、を含むコントローラ３０を備えている。さらに、決済サービスサーバ３は、ユーザＩＦ３３と、通信ＩＦ３５とを備え、これらがコントローラ３０に電気的に接続されている。なお、図３中のコントローラ３０も、決済サービスサーバ３の制御に利用されるハードウェアやソフトウェアを纏めた総称であって、実際に決済サービスサーバ３に存在する単一のハードウェアを表すとは限らない。

決済サービスサーバ３を構成するＣＰＵ３１等のハードウェアは、携帯端末２が備える各種のハードウェアと機能がほぼ同じであり、説明を省略する。なお、メモリ３２には、例えば、前述した決済ユーザＴＢ３２１、決済方法ＴＢ３２２、連携ＴＢ３２３、決済ＴＢ３２５、クーポンＴＢ３２６が記憶される。また、決済サービスサーバ３は、ユーザＩＦ３３を備えていなくてもよい。

［決済サービスサーバ３が有する各種のＴＢの構成］
決済ユーザＴＢ３２１は、図４に示すように、決済システム１００のサービスを受けるユーザの個人情報を１つのレコードとして記憶している。各レコードには、レコードを区別するための決済ユーザＩＤが付与される。決済ユーザＩＤは、決済サービスサーバ３にて決済処理を行う際に用いられる。すなわち、決済サービスサーバ３は、決済ユーザＩＤごとにユーザを区別する。決済ユーザＩＤは、第１アプリケーションの識別情報の一例である。ユーザの個人情報としては、電話番号やＥメールアドレス等、連絡先の情報が含まれる。ユーザの個人情報は、ユーザを認証するための情報として用いられる。

決済方法ＴＢ３２２は、図５に示すように、前述した決済ユーザＩＤと決済方法に関する情報とを関連付けて１つのレコードとして記憶している。各レコードには、レコードを区別するための決済方法ＩＤが付与される。決済方法に関する情報としては、クレジットカードや銀行口座等、決済の種類に関する情報が含まれる。本形態の決済システム１００を利用するユーザは、複数の決済方法を登録することが可能であり、１つの決済ユーザＩＤに対して決済方法が異なる複数のレコードが決済方法ＴＢ３２２に登録されることがある。例えば図５中、決済ユーザＩＤが「Ｕｓｅｒ０１」のユーザは、「方法０１」と「方法０２」の２種類の決済方法を登録しており、決済処理を要求する際にはいずれか１つを選択する。

連携ＴＢ３２３は、図６に示すように、前述した第１アプリケーションの識別情報の一例である決済ユーザＩＤと、アプリを識別するアプリコードと、を関連付けて１つのレコードとして記憶している。各レコードには、レコードを区別するための連携ＩＤが付与される。連携ＩＤおよび／またはアプリコードは、第２アプリケーションの識別情報の一例である。アプリコードは、決済ＳＤＫが組み込まれたパートナーアプリの種類（あるいは決済ＳＤＫの種類）を区別するための情報である。決済アプリ２２３にはアプリコードが付与されない。ユーザは複数種類のプログラムを決済に利用することが可能であり、１つの決済ユーザＩＤに対してアプリコードが異なる複数のレコードが連携ＴＢ３２３に登録されることがある。例えば図６中、決済ユーザＩＤが「Ｕｓｅｒ０１」のユーザは、「ＳＤＫ０１」が組み込まれたパートナーアプリと「ＳＤＫ０２」が組み込まれたパートナーアプリとの２種類のパートナーアプリを所有している。各パートナーアプリは、同じデバイスにインストールされていてもよいし、別々のデバイスにインストールされていてもよい。このように、第１アプリケーションの識別情報の一例である決済ユーザＩＤと第２アプリケーションの識別情報の一例であるアプリコードおよび／または連携ＩＤとを、決済サービスサーバ３で連携して記憶することにより、通信デバイスにインストール可能な少なくとも一部の機能を共通とする互いに異なるアプリケーションの情報を、サーバを用いて管理することが可能になる。

決済ＴＢ３２５は、図７に示すように、前述した決済ユーザＩＤと、前述した決済方法に関する情報と、前述したアプリコードと、前述した連携ＩＤと、決済の詳細情報と、を関連付けて１つのレコードとして記憶している。各レコードには、レコードを区別するための決済ＩＤが付与される。なお、決済アプリ２２３によって決済を行った場合には、アプリコードが付与されていないため、アプリコードおよび連携ＩＤはブランクとなる。決済の詳細情報には、例えば、商品ないしサービスの提供を受けた店舗を識別する店舗ＩＤと、決済を行った日時および金額が含まれる。

クーポンＴＢ３２６は、図８に示すように、前述した決済ユーザＩＤと、前述したアプリコードと、クーポンの詳細情報と、を関連付けて１つのレコードとして記憶している。各レコードには、レコードを区別するためのクーポンＩＤが付与される。クーポンの詳細情報には、例えば、クーポンの有効期限、割引額が含まれる。クーポンは特典の一例である。レコードに含まれる決済ユーザＩＤは、クーポンを利用可能なユーザを示す。また、アプリコードは、クーポンの発行元、すなわち原資を示す。例えばアプリコードが「ＳＤＫ０１」のパートナーアプリ２２１を提供するパートナーが原資のクーポンの場合、クーポンＴＢ３２６のアプリコードの欄には「ＳＤＫ０１」が記憶される。なお、決済サービス会社が原資のクーポンの場合には、アプリコードが付与されていないため、アプリコードはブランクとなり、決済アプリ２２３およびパートナーアプリ２２１で利用可能である。

［決済アプリ２２３からのログイン］
続いて、決済アプリ２２３から決済サービスサーバ３にログインする際の手順を、図９を参照しつつ説明する。本形態では、決済アプリ２２３から決済を行うにあたって、決済アプリ２２３が決済サービスサーバ３にログインしている必要がある。なお、本明細書での決済アプリ２２３が行う処理は、携帯端末２のＣＰＵ２１によって実行される処理であり、決済サービスサーバ３が行う処理は、決済サービスサーバ３のＣＰＵ３１によって実行される処理である。

決済アプリ２２３は、起動中、決済サービスサーバ３へログインするための操作、すなわちログイン要求を受け付ける（Ｓ０１）。ログイン要求を受け付ける際、決済アプリ２２３は、ユーザの個人情報として、電話番号とＥメールアドレスの入力も受け付ける。ログイン要求を受け付けると、決済アプリ２２３は、ログイン要求を、入力された個人情報とともに、決済サービスサーバ３に送信する（Ｓ０２）。

決済サービスサーバ３は、ログイン要求を受け付けると、決済ユーザＩＤを作成する（Ｓ０３）。そして、作成した決済ユーザＩＤを、ログイン要求に付されていた個人情報とともに、決済ユーザＴＢ３２１に登録する（Ｓ０４）。

その後、決済サービスサーバ３は、認証情報としてのアクセストークンを、ログイン要求を行った決済アプリ２２３に送信する（Ｓ０５）。認証情報は、決済サービスサーバ３によって期限管理され、決済ユーザＩＤと関連付けて決済サービスサーバ３のメモリ３２に記憶される。

なお、ログイン要求に付されていた個人情報と一致する個人情報が記憶されている決済ユーザＩＤがある場合、Ｓ０３およびＳ０４は省略される。そして、アクセストークンが更新され、そのアクセストークンが決済ユーザＩＤと関連付けて記憶され、さらにそのアクセストークンが決済アプリ２２３に送信される。

一方、決済サービスサーバ３から認証情報を受信した決済アプリ２２３は、その受信した認証情報をメモリ２２に記憶する（Ｓ０６）。以後、決済を要求する場合、決済アプリ２２３は、メモリ２２に記憶した認証情報を利用する。

なお、決済を要求するにあたって、決済アプリ２２３では、決済の要求を行う前に、決済方法に関する情報の入力も受け付け、入力された決済方法に関する情報を、メモリ２２に記憶した認証情報とともに決済サービスサーバ３に送信する。決済サービスサーバ３は、入力された決済方法に関する情報を受信すると、認証情報と関連付けられた決済ユーザＩＤを抽出し、その決済ユーザＩＤに関連付けて、受信した決済方法に関する情報を決済方法ＴＢ３２２に登録する。

［パートナーアプリ２２１からのログイン］
続いて、パートナーアプリ２２１から決済サービスサーバ３にログインする際の手順を、図１０を参照しつつ説明する。本形態では、パートナーアプリ２２１から決済を行うにあたっても、パートナーアプリ２２１が決済サービスサーバ３にログインしている必要がある。パートナーアプリ２２１からログインする場合、パートナーアプリ２２１によって決済ＳＤＫ２２２を起動し、決済ＳＤＫ２２２を介して決済サービスサーバ３にログインすることになる。そのため、パートナーアプリ２２１の処理を、決済ＳＤＫ２２２による処理と、決済ＳＤＫ２２２以外のパートナーアプリ２２１による処理とに分けて説明する。なお、本明細書でのパートナーアプリ２２１や決済ＳＤＫ２２２が行う処理は、携帯端末２のＣＰＵ２１によって実行される処理である。

決済ＳＤＫ２２２は、起動中、ログイン要求を受け付ける（Ｓ１１）。Ｓ１１では、決済ＳＤＫ２２２の起動要求がログイン要求を兼ねてもよい。ログイン要求を受け付けると、決済ＳＤＫ２２２は、パートナーアプリ２２１を介してパートナーサーバ４に対してアプリコードの送信要求を送信する（Ｓ１２）。

パートナーサーバ４は、アプリコードの送信要求を受信すると、決済ＳＤＫ２２２を介して決済サービスサーバ３にログイン要求を送信する（Ｓ１３）。ログイン要求には、あらかじめパートナーサーバ４に記憶されているパートナーアプリ２２１のアプリコードが付される。具体的にＳ１３では、決済ＳＤＫ２２２がパートナーサーバ４からのログイン要求を一旦受信し、決済サービスサーバ３が有する認証ページのＵＲＬおよびアプリコードを起動オプションに設定し、携帯端末２が有するブラウザを起動する。これにより、決済サービスサーバ３では、アプリコードを受信するとともに、ログインするための情報として、ユーザの個人情報を受け付ける。

決済サービスサーバ３は、個人情報が入力されると、決済ユーザＩＤを作成する（Ｓ１４）。そして、作成した決済ユーザＩＤを、入力された個人情報とともに、決済ユーザＴＢ３２１に登録する（Ｓ１５）。さらに、決済サービスサーバ３は、連携ＩＤを作成する（Ｓ１６）そして、作成した連携ＩＤを、Ｓ１４にて作成した決済ユーザＩＤおよび受信したアプリコードとともに、連携ＴＢ３２３に登録する（Ｓ１７）。

その後、決済サービスサーバ３は、認証情報としてのアクセストークンを、ログイン要求を行ったパートナーサーバ４に送信する（Ｓ１８）。認証情報は、決済サービスサーバ３によって期限管理され、決済ユーザＩＤおよびアプリコードと関連付けて決済サービスサーバ３のメモリ３２に記憶される。

なお、ログイン要求に付されていた個人情報と一致する個人情報が記憶されている決済ユーザＩＤがある場合、Ｓ１４からＳ１７は省略される。そして、アクセストークンが更新され、そのアクセストークンが決済ユーザＩＤと関連付けて記憶され、さらにそのアクセストークンがパートナーサーバ４に送信される。また、ログイン要求に付されていた個人情報と一致する個人情報が記憶されている決済ユーザＩＤがある場合であっても、連携ＩＤが登録されていない場合には、Ｓ１６およびＳ１７は行われる。

決済サービスサーバ３から認証情報を受信したパートナーサーバ４は、その受信した認証情報をパートナーアプリ２２１を介して決済ＳＤＫ２２２に送信し（Ｓ１９）、決済ＳＤＫ２２２はパートナーサーバ４から送信される認証情報をメモリ２２に記憶する（Ｓ２０）。以後、決済ＳＤＫ２２２は、決済を要求する場合、メモリ２２に記憶した認証情報を利用する。また、パートナーアプリ２２１も、決済履歴の照合処理を要求する場合、メモリ２２に記憶した認証情報を利用する。

なお、決済処理を要求するにあたって、パートナーアプリ２２１の決済ＳＤＫ２２２でも、決済処理の要求を行う前に、決済方法に関する情報の入力も受け付け、入力された決済方法に関する情報を、メモリ２２に記憶した認証情報とともに決済サービスサーバ３に送信する。決済サービスサーバ３は、入力された決済方法に関する情報を受信すると、認証情報と関連付けられた決済ユーザＩＤを抽出し、その決済ユーザＩＤに関連付けて、受信した決済方法に関する情報を決済方法ＴＢ３２２に登録する。

また、ログインが成功した後、パートナーアプリ２２１では、パートナーサーバ４にて連携ＩＤを利用可能にするため、図１０に示したように、連携ＩＤの送信命令を認証情報とともに決済ＳＤＫ２２２を介して決済サービスサーバ３に送信する（Ｓ２１）。決済サービスサーバ３は、連携ＩＤの送信命令を受信すると、認証情報と関連付けられた決済ユーザＩＤとアプリコードとの組み合わせを抽出し、その組み合わせに関連付けられた連携ＩＤを決済ＳＤＫ２２２に送信し（Ｓ２２）、決済ＳＤＫ２２２を介してパートナーアプリ２２１が受信する。パートナーアプリ２２１は、決済サービスサーバ３から受信した連携ＩＤをパートナーサーバ４に送信する（Ｓ２３）。なお、連携ＩＤは決済サービスサーバ３からパートナーサーバ４に直接送信されてもよい。

パートナーサーバ４は、受信した連携ＩＤをパートナーサーバ４のメモリに記憶する（Ｓ２４）。具体的には、パートナーアプリ２２１は、パートナーがユーザを管理するためのパートナーユーザＩＤを連携ＩＤとともにパートナーサーバ４に送信する。パートナーユーザＩＤは、パートナーユーザＴＢ４２１（図１参照）に登録されているものである。パートナーサーバ４は、受信した連携ＩＤを、同じく受信したパートナーユーザＩＤと関連付けて、パートナー連携ＴＢ４２２に登録する。

［決済アプリ２２３からの決済の手順］
続いて、決済アプリ２２３から決済を行う際の手順を、図１１を参照しつつ説明する。決済アプリ２２３は、コード支払いの指示を受け付ける（Ｓ３１）。このコード支払いの指示は、決済アプリ２２３からの決済の要求を意味する。そして、コード支払いの指示を受け付けると、コードの送信を要求するコード要求を、メモリ２２に記憶される認証情報とともに、決済サービスサーバ３に送信する（Ｓ３２）。

決済サービスサーバ３は、コード要求を受信すると、個々の二次元コードを識別するためのコード識別情報を含む二次元コードを作成し、コード識別情報を認証情報と関連付けて一時的に記憶する（Ｓ３３）。二次元コードは、コード識別情報を含められるものであればよく、例えばバーコードやＱＲコード（登録商標）が該当する。そして、作成した二次元コードを決済アプリ２２３に送信する（Ｓ３４）。決済サービスサーバ３から二次元コードを受信した決済アプリ２２３は、受信した二次元コードを携帯端末２のユーザＩＦ２３に表示する（Ｓ３５）。

一方、店舗側では、店舗端末１に金額が入力される（Ｓ３６）。そして金額が入力された状態で、店舗端末１は、携帯端末２に表示されている二次元コードを読み取る（Ｓ３７）。そして、店舗端末１は、二次元コードを解析し、二次元コードに含まれるコード識別情報を抽出し、抽出したコード識別情報と、入力された金額と、あらかじめ登録されている店舗ＩＤと、を決済サービスサーバ３に送信する（Ｓ３８）。

決済サービスサーバ３は、店舗端末１からコード識別情報、金額、店舗ＩＤを受信すると、そのコード識別情報に関連付けられた認証情報を抽出し、さらにその認証情報に関連付けられた決済ユーザＩＤを抽出し、さらにその決済ユーザＩＤに関連付けられた決済方法を抽出し、決済処理を行う（Ｓ３９）。そして、抽出した決済ユーザＩＤおよび決済方法と、受信した金額、店舗ＩＤ、および日時とを含む決済情報を、決済ＴＢ３２５に登録する（Ｓ４０）。

決済処理が完了した後、決済サービスサーバ３は、決済アプリ２２３に対して、ユーザ用の支払い通知をプッシュ通知によって行う（Ｓ４１）。また、店舗端末１に対して、店舗用の支払い通知をメッセージ送信によって行う（Ｓ４２）。

なお、パートナーアプリ２２１から決済ＳＤＫ２２２を介して決済処理を行う場合、決済ＳＤＫ２２２からは決済アプリ２２３と同様にコード要求と認証情報とを決済サービスサーバ３に送信する。そして、決済サービスサーバ３は、認証情報から決済ユーザＩＤとともにアプリコードを抽出し、アプリコードと、アプリコードと決済ユーザＩＤとに基づいて連携ＴＢ３２３から抽出される連携ＩＤとが含まれる決済情報を、決済ＴＢ３２５に登録することで決済処理を完了させる。すなわち、パートナーアプリ２２１から決済ＳＤＫ２２２を介して決済処理を行う場合であっても、第２アプリケーションの識別情報の一例である連携ＩＤでなく、第１アプリケーションの識別情報の一例である決済ユーザＩＤと決済方法ＴＢ３２２において関連付けられた決済方法を用いて決済処理を行う。このように、パートナーアプリ２２１から決済処理を行う場合であっても、決済ユーザＩＤを用いて決済を行うことでパートナーアプリ２２１毎に決済情報を登録する必要がなくなるため、ユーザの利便性が向上する。また、後述するように決済アプリ２２３とパートナーアプリ２２１での決済履歴の照会機能を差別化することが可能になる。

また、図１１に示した決済手順は、携帯端末２から二次元コードを表示し、店舗端末１でその二次元コードを読み取る手順（いわゆるConsumer-Presented Mode、ＣＰＭ）であるが、店舗端末１から二次元コードを表示し、携帯端末２でその二次元コードを読み取る手順（いわゆるMerchant-Presented Mode、ＭＰＭ）であってもよい。その場合、店舗端末１から金額および店舗ＩＤを含むコード要求を決済サービスサーバ３に要求し、店舗端末１が決済サービスサーバ３から送信される二次元コードを表示する。そして、決済アプリ２２３がその二次元コードを読み取ると、二次元コードの特定情報を認証情報とともに決済サービスサーバ３に送信し、認証情報から決済ユーザＩＤ等を抽出して決済処理を行う。

［決済アプリ２２３からの決済履歴の照会］
続いて、決済アプリ２２３から決済履歴の照会を行う際の手順を、図１２を参照しつつ説明する。決済アプリ２２３は、決済履歴の照会指示を受け付ける（Ｓ１０１）。そして、照会指示を受け付けると、決済履歴の送信を要求する照会要求を、メモリ２２に記憶される認証情報とともに、決済サービスサーバ３に送信する（Ｓ１０２）。

決済サービスサーバ３は、照会要求を受信すると、認証情報に関連付けられた決済ユーザＩＤを抽出し、さらに決済ユーザＩＤに関連付けられた決済情報を、決済ＴＢ３２５から抽出する（Ｓ１０３）。Ｓ１０３では、どのアプリから決済処理が行われたかは関係なく、抽出された決済ユーザＩＤに紐づく全ての決済情報を抽出する。すなわち、決済アプリ２２３からの照会要求の場合、決済サービスサーバ３は、決済アプリ２２３からの決済もパートナーアプリ２２１からの決済も両方とも抽出する。そして、抽出した決済情報を、決済アプリ２２３に送信する（Ｓ１０４）。

決済アプリ２２３は、決済サービスサーバ３から決済情報を受信すると、受信した決済情報をユーザＩＦ２３に一覧表示させる（Ｓ１０５）。なお、決済アプリ２２３が受信する決済情報には、決済ユーザＩＤや連携ＩＤが含まれない。また、アプリコードも含まれなくてもよい。ただし、アプリコードが含まれると、決済アプリ２２３は、決済を行ったアプリごとに決済情報を表示することができる。

［パートナーアプリ２２１からの決済履歴の照会］
続いて、パートナーアプリ２２１から決済ＳＤＫ２２２を介して決済履歴の照会を行う際の手順を、図１３を参照しつつ説明する。パートナーアプリ２２１は、決済履歴の照会指示を受け付ける（Ｓ１１１）。そして、照会指示を受け付けると、決済履歴の送信を要求する照会要求を、メモリ２２に記憶される認証情報とともに、決済ＳＤＫ２２２を介して決済サービスサーバ３に送信する（Ｓ１１２）。

決済サービスサーバ３は、パートナーアプリ２２１から決済ＳＤＫ２２２を介して照会要求を受信すると、認証情報に関連付けられた決済ユーザＩＤおよびアプリコードを抽出し、さらに決済ユーザＩＤおよびアプリコードに関連付けられた決済情報を、決済ＴＢ３２５から抽出する（Ｓ１１３）。Ｓ１１３では、決済ユーザＩＤに加えて、アプリコードによって抽出される決済処理が限定され、決済ユーザＩＤが一致したとしても他のアプリによって決済された決済情報は抽出されない。すなわち、パートナーアプリ２２１からの照会要求の場合、決済サービスサーバ３は、そのパートナーアプリ２２１を利用するユーザのパートナーアプリ２２１からの決済のみ抽出する。そして、抽出した決済情報を、パートナーアプリ２２１の決済ＳＤＫ２２２に送信する（Ｓ１１４）。

パートナーアプリ２２１は、決済ＳＤＫ２２２を介して決済サービスサーバ３から決済情報を受信すると、受信した決済情報をユーザＩＦ２３に一覧表示させる（Ｓ１１５）。受信する決済情報には、他のアプリからの決済情報は含まれない。そのため、ユーザの困惑が生じ難い。なお、パートナーアプリ２２１が受信する決済情報には、決済ユーザＩＤやアプリコードや連携ＩＤが含まれない。ここで、アプリコードが含まれない理由は、パートナーアプリ２２１から決済ＳＤＫ２２２を介して決済履歴の照会を行う場合、決済サービスサーバ３はアプリコードを用いて当該パートナーアプリ２２１による決済履歴のみを送信している。そのため、アプリコードに関する情報は不要であり、アプリコードを送信しないことでデータ量を削減できる。

［パートナーサーバ４からの決済履歴の照会］
続いて、パートナーサーバ４から決済履歴の照会を行う際の手順を、図１４を参照しつつ説明する。パートナーサーバ４は、決済履歴の照会指示を外部装置から受信する（Ｓ１２１）。そして、照会指示を受信すると、決済履歴の送信を要求する照会要求を、アプリコードとともに、決済サービスサーバ３に送信する（Ｓ１２２）。

決済サービスサーバ３は、パートナーサーバ４から照会要求を受信すると、受信したアプリコードに関連付けられた決済情報を、決済ＴＢ３２５から抽出する（Ｓ１２３）。Ｓ１２３では、アプリコードによって抽出される決済が限定され、他のアプリによって決済された決済情報は抽出されない。すなわち、パートナーサーバ４からの照会要求の場合、決済サービスサーバ３は、ユーザを特定せずにパートナーアプリ２２１からの決済のみ抽出する。そして、抽出した決済情報を、パートナーサーバ４に送信する（Ｓ１２４）。

パートナーサーバ４は、決済サービスサーバ３から決済情報を受信すると、受信した決済情報を、照会指示を送信した外部装置に送信する（Ｓ１２５）。受信する決済情報には、決済アプリ２２３および他のパートナー（他の企業）のパートナーアプリ２２１を用いて決済処理された決済情報は含まれない。そのため、パートナーサーバ４は、自社に関する情報のみを取得でき、決済情報を利用し易い。なお、パートナーサーバ４が受信する決済情報には、決済ユーザＩＤおよびアプリコードは含まれないが、連携ＩＤが含まれる。パートナーサーバ４は、連携ＩＤをパートナーユーザＩＤと関連付けて記憶していることから、決済情報をパートナーユーザＩＤごとに区別できる。そのため、パートナーサーバ４は、例えば外部装置からの特定のパートナーユーザＩＤの決済情報の送信要求に応えて、その特定のパートナーユーザＩＤに対応する決済情報に限定して送信することができる。そして、パートナーサーバ４が連携ＩＤを用いてパートナーユーザＩＤごとの決済情報を取得できることで、例えばパートナーユーザＩＤを持つユーザがパートナーの商品ないしサービスを購入する店舗（場所）、時間帯、価格帯を解析でき、そのユーザに適した広告やサービスを提供できる。

なお、図１４では、外部装置から照会指示を受信したことを契機にパートナーサーバ４から照会要求を送信しているが、定期的に照会要求を出力する等、外部装置からの指示に基づかなくても照会要求を送信してもよい。

［決済サービスサーバ３によるクーポンの配信］
続いて、決済サービスサーバ３によるクーポンを配信する際の手順を、図１５を参照しつつ説明する。なお、個々のクーポンは、図５に示したようにクーポンＴＢ３２６にあらかじめ登録されており、決済サービスサーバ３は、登録されている各クーポンの配信依頼を個別に受け付ける。そして、決済サービスサーバ３は、クーポンの配信依頼を受け付ける度に、図１５に示すクーポン配信処理を実行する。

クーポン配信処理では、決済サービスサーバ３は先ず、配信対象となるクーポンの情報をクーポンＴＢ３２６から読み出す（Ｓ２０１）。そして、配信対象となるクーポンにアプリコードが指定されているか否かを判断する（Ｓ２０２）。本形態では、パートナーが原資のクーポンにはアプリコードが付与され、決済サービス会社が原資のクーポンにはアプリコードが付与されない。そのため、Ｓ２０２は、クーポンの原資がパートナーか否かを判断することになる。決済サービス会社が原資のクーポンは、第１特典の一例であり、パートナーが原資のクーポンは、第２特典の一例である。

アプリコードが指定されていないクーポンの場合、すなわち決済サービス会社の原資のクーポンの場合（Ｓ２０２：ＮＯ）、決済サービスサーバ３は、決済アプリ２２３に対してクーポンのメッセージ配信とプッシュ通知を行う（Ｓ２０３）。また、決済サービスサーバ３は、連携ＴＢ３２３を参照し、クーポンにて指定される決済ユーザＩＤに関連付けられるアプリコードを抽出し、抽出したアプリコードに対応するパートナーアプリ２２１に対してクーポンのメッセージ配信を行う（Ｓ２０４）。

決済サービス会社の原資のクーポンはパートナーアプリ２２１からも使用できることで使い勝手がよくなるが、例えばパートナーアプリ２２１も決済アプリ２２３も同じ携帯端末２にインストールしているユーザにとっては、同じようなプッシュ通知を複数受け取ることになる。そのため、パートナーアプリにはプッシュ通知を行わず、パートナーアプリ２２１への通知を決済アプリ２２３への通知と比較して強度を弱めることで、複数の通知を受け取ることのユーザの煩わしさを軽減する。

一方、アプリコードが指定されているクーポンの場合、すなわちパートナーの原資のクーポンの場合（Ｓ２０２：ＹＥＳ）、決済サービスサーバ３は、そのアプリコードに対応するパートナーアプリ２２１に対してクーポンのメッセージ配信とプッシュ通知を行う（Ｓ２０５）。パートナーの原資のクーポンは、決済アプリ２２３に配信されない。Ｓ２０５あるいはＳ２０４の後、クーポン配信処理を終了する。

このようにクーポンは、原資がパートナーか否かによって配信先が異なる。そのため、パートナーアプリ２２１は、そのパートナーの原資のクーポンと決済サービス会社の原資のクーポンとが利用可能になる。一方で、決済アプリ２２３は、決済サービス会社の原資のクーポンのみが利用可能になる。例えば、図８に示したクーポンＴＢ３２６に登録されたクーポンが全て配信された場合、アプリコードが「ＳＤＫ０１」のパートナーアプリ２２１では、アプリコードが「ＳＤＫ０１」のクーポンである「ＣＰ０１」と「ＣＰ０４」に加え、アプリコードが無いクーポンである「ＣＰ０３」も利用可能に表示される。また、アプリコードが「ＳＤＫ０２」のパートナーアプリ２２１では、アプリコードが「ＳＤＫ０２」のクーポンである「ＣＰ０２」に加え、アプリコードが無いクーポンである「ＣＰ０３」も利用可能に表示される。一方、決済アプリ２２３では、アプリコードが無いクーポンである「ＣＰ０３」のみが利用可能に表示される。クーポンの配信とは、決済サービスサーバ３のクーポンＴＢ３２６に利用可能なクーポンが登録され、決済アプリ２２３やパートナーアプリ２２１でクーポンが利用可能な状態であればよい。

なお、決済サービス会社のクーポンは、決済ユーザＩＤに関連付けられる。そのため、例えば決済サービス会社の原資のクーポンは決済アプリ２２３でもパートナーアプリ２２１でも利用可能であるが、一方のアプリでそのクーポンを使用した場合、そのクーポンは消滅するため、他方のアプリでもそのクーポンは使用できなくなる。このようにクーポンを決済ユーザＩＤと関連付けることで、クーポンの２重取りを防ぐことができる。また、パートナー原資のクーポンは決済ユーザＩＤだけでなく、アプリコードに関連付けられている。そのため、パートナー原資のクーポンは、原資を出しているパートナーアプリ２２１からのみ利用可能である。更に、決済ユーザＩＤにも関連付けられているため、クーポンの２重取りを防ぐことができる。

［パートナーのポイントをクーポンに変換して配信］
続いて、パートナーのポイントをクーポンに変換して配信する際の手順を、図１６を参照しつつ説明する。なお、決済サービスサーバ３には、あらかじめパートナー原資のクーポンとして決済割引のクーポンが複数登録されている。具体的には、１００円割引、５００円割引、１０００円割引、といったクーポンである。そして、パートナーサーバ４は、決済サービスサーバ３からそのパートナー原資のクーポンの情報を取得している。

パートナーアプリ２２１は、パートナーサーバ４からそのクーポンの情報を取得して、ユーザからそれらのクーポンの発行指示を受け付ける（Ｓ３０１）。パートナーアプリ２２１は、ある１つのクーポンの発行指示を受け付けると、そのクーポンを示すクーポン情報を含むクーポン発行依頼をパートナーサーバ４に送信する（Ｓ３０２）。

パートナーサーバ４は、クーポン発行依頼を受け付けると、パートナー連携ＴＢ４２２を参照し、クーポンの発行依頼を行ったユーザのパートナーユーザＩＤから連携ＩＤを取得する（Ｓ３０３）。そして、取得した連携ＩＤおよび発行指示を受け付けたクーポンを示すクーポン情報を含むクーポン発行依頼を、決済サービスサーバ３に送信する（Ｓ３０４）。なお、選択されたクーポンに換算されるパートナーのポイントが不足している場合には、発行不可をパートナーアプリ２２１に応答する。

決済サービスサーバ３は、クーポン発行依頼を受信すると、連携ＴＢ３２３を参照し、クーポン発行依頼に含まれる連携ＩＤから決済ユーザＩＤおよびアプリコードを取得する（Ｓ３０５）。決済サービスサーバ３は、あらかじめ登録されているクーポンの中から、取得した決済ユーザＩＤおよびアプリコードを含むクーポンであって、クーポン発行依頼に含まれるクーポン情報によって示される内容に対応するクーポンを抽出して発行する（Ｓ３０６）。

Ｓ３０６の後、決済サービスサーバ３は、クーポンを発行したことを示すクーポン発行通知をパートナーサーバ４に送信する。パートナーサーバ４は、クーポン発行通知を受け付けると、そのユーザがパートナーの特典として有しているポイントのうち、そのクーポンに対応するポイント分を消費する（Ｓ３０７）。例えば、パートナーが１０ポイントを１円と換算している場合、１００円割引のクーポンの発行指示を受け付けると、１０ポイント×１００円＝１０００ポイントがユーザのポイントから減算される。

また、Ｓ３０６で発行されるクーポンはパートナー原資のクーポンであるため、パートナーアプリ２２１にのみそのクーポンが発行される。そのため、Ｓ３０６によるクーポンが発行された後、パートナーアプリ２２１の決済ＳＤＫ２２２で決済を行う際、そのクーポンを使用することができる（Ｓ３０８）。

本形態の決済システム１００では、パートナーサーバ４は、パートナーアプリ２２１と直接通信できるにもかかわらず、決済サービスサーバ３と決済ＳＤＫ２２２とを介してクーポンを発行する。すなわち、本形態の決済システム１００では、クーポンの発行依頼に基づきパートナー原資のクーポンがあらかじめ決済サービスサーバ３に登録されている。また、決済ＳＤＫ２２２上でユーザはクーポン発行依頼に基づくクーポンの発行を確認することができる。そのため、パートナーアプリ２２１にて決済する際、パートナーのポイントを利用するために決済サービスサーバ３はパートナーサーバ４と通信しなくてもクーポンを利用した決済処理を行うことができる。また、決済ＳＤＫ２２２上で容易にパートナーアプリ２２１を介して配信依頼したクーポンを選択することができる。このようにすることで、決済時間と通信回数を削減できる。

以上詳細に説明したように本形態の決済システム１００では、異なるアプリケーション間であっても、サーバ上で両者の識別情報を連携させることができる。両者の識別情報を連携させることにより、アプリケーションと、アプリケーションの少なくとも一部の機能を有するプログラム（ＳＤＫ）が組み込まれた別のアプリケーションとを連携させることができる。

そして、決済ユーザＩＤに紐づいて、決済アプリ２２３からもパートナーアプリ２２１からも決済を行うことができる。また、パートナーアプリ２２１から行った決済の決済情報も、図１７に示すように、連携ＩＤと紐づいて決済ユーザＩＤと関連付けられる。さらにパートナーアプリ２２１が複数ある場合には、パートナーアプリごとに連携ＩＤが付与される。例えばパートナーアプリ２２１（ａ）には連携ＩＤの「連携０１」が付与され、パートナーアプリ２２１（ｂ）には連携ＩＤの「連携０２」が付与される。そのため、連携ＩＤに基づいて、どのパートナーアプリでの決済かを区別できる。

そして、本形態の決済システム１００では、決済アプリ２２３からもパートナーアプリ２２１からも通信可能な決済サービスサーバ３が連携ＴＢ３２３を有し、連携ＴＢ３２３によって、決済ユーザＩＤと、連携ＩＤやアプリコードと、を関連付ける。この構成により、例えば決済ユーザＩＤを知り得ないパートナーサーバ４も、連携ＩＤを用いて決済ユーザＩＤと紐づいた決済情報を取得して利用できるようになる。

また、本形態の決済システム１００では、パートナーサーバ４は連携ＩＤを知っているものの、決済ユーザＩＤを知らず、決済ユーザＩＤに関連付けられた決済方法や電話番号等と直接的に連携していない。そのため、決済ユーザＩＤに関連付けられた決済方法や電話番号の安全性は高いものになる。このようにパートナーサーバ４が、決済ユーザＩＤと直接的に連携していないため、低リスクでパートナーサーバ４に決済サービスサーバ３の情報を提供できる。

また、本形態の決済システム１００では、決済機能を持つアプリケーションについて、各アプリに個別のユーザＩＤを持たせるのではなく、決済ユーザＩＤを用いた決済に集約することで、１つの識別情報で複数のアプリケーションないしプログラムからの決済要求を管理できる。さらに１つの識別情報で決済処理を行うことから、決済機能を有するアプリケーションないしプログラムごとに決済方法を登録する必要がなくなり、ユーザの手間を軽減できる。

また、少なくとも一部が異なる複数のアプリケーションから決済が可能な場合、決済履歴を照合する際に、他のアプリケーションからの決済まで照合すると、ユーザが混乱する可能性がある。

本形態の決済システム１００では、決済アプリ２２３はパートナーアプリ２２１からの決済も含めた全ての決済情報が取得できる一方、パートナーアプリ２２１はそのパートナーアプリ２２１からの決済のみを取得する。そのため、パートナーは自社の決済のみをユーザに開示することになり、ユーザの混乱を回避でき、またパートナーアプリ２２１がパートナーアプリ２２１の決済履歴に基づいて独自にポイント等を付与する場合についても、パートナーアプリ２２１の決済履歴のみを開示するためユーザの混乱を回避できる。また、決済アプリ２２３は自社の決済サービスを利用した全ての決済履歴を取得する。そのため、ユーザは全ての決済履歴を一覧することが可能で利便性が向上する。

また、本形態の決済システム１００では、パートナーアプリ２２１と通信するパートナーサーバ４から直接に決済履歴の照会の要求があった場合も、パートナーサーバ４はパートナーアプリ２２１からの決済のみを取得する。そのため、自社のアプリケーションを用いた決済のみを取得でき、自社のアプリケーションに対する決済履歴を他のサービスに活用できる。例えば、購入した商品の種類、時間帯、価格帯等の購買情報を活用した広告表示が可能になる。

また、少なくとも一部が異なる複数のアプリケーションから決済が可能な場合であって各社がそれぞれクーポンのような特典を発行可能な場合、他社のクーポンが自社のアプリケーションで表示されてしまうと、ユーザが混乱する可能性がある。

本形態の決済システム１００では、決済サービス会社の原資のクーポンは決済アプリ２２３とパートナーアプリ２２１とに配信し、パートナー原資のクーポンはそのパートナーのパートナーアプリ２２１にのみ配信する。このように原資ごとにクーポンの配信先を変えることで、パートナーにとって他社原資のクーポンが自社のアプリケーションに届かなくなり、ユーザの混乱を低減できる。

本形態の決済システム１００では、パートナーサーバ４からのクーポン発行依頼に基づくクーポンは、決済サービスサーバ３を介してパートナーアプリ２２１に組み込まれた決済ＳＤＫ２２２で利用可能となる。決済サービスサーバ３には、ユーザの店舗でのクーポン使用に先立ってパートナーのポイントに基づくクーポンが登録される。そのため、ユーザの決済時には、決済サービスサーバ３はパートナーサーバ４と通信を行うことなく、クーポンを使用した決済処理を実行することができ、決済時間と通信回数を削減することができる。

なお、本実施の形態は単なる例示にすぎず、本発明を何ら限定するものではない。したがって本発明は当然に、その要旨を逸脱しない範囲内で種々の改良、変形が可能である。例えば、各アプリがインストールされる装置は、携帯端末に限らず、デスクトップのＰＣ等の固定端末であってもよい。

また、実施の形態では、決済ＳＤＫ２２２がパートナーアプリ２２１に始めから組み込まれているが、例えば決済サービスサーバ３に決済ＳＤＫ２２２を記憶させ、携帯端末２が決済サービスサーバ３から決済ＳＤＫ２２２をダウンロードし、パートナーアプリ２２１に決済ＳＤＫ２２２を後から追加して組み込んでもよい。

また、実施の形態では、パートナーアプリ２２１や決済ＳＤＫ２２２は認証情報を用いて決済サービスサーバ３に決済要求や決済情報の照会要求を行っているが、連携ＴＢ３２３に連携ＩＤと決済ユーザＩＤとが関連付けられていることから、携帯端末２において連携ＩＤを記憶し、連携ＩＤを用いて決済サービスサーバ３に決済要求や決済情報の照会要求を行ってもよい。

また、実施の形態では、決済アプリ２２３にはアプリコードを付与していないが、アプリコードを付与し、決済アプリ２２３の情報を決済ＴＢ３２５等に明確に記憶できるようにしてもよい。この場合、例えば決済アプリ２２３からのログイン時には、連携ＴＢ３２３に、決済ユーザＩＤと決済アプリ２２３のアプリコードとを関連付けたレコードも記憶すればよい。また、例えば決済アプリ２２３からの支払要求に基づいて決済処理を行った際には、決済ＴＢ３２５に、決済アプリ２２３のアプリコードと連携ＩＤとを記憶すればよい。

また、実施の形態に記載した各種のＴＢの構成は一例であり、実施可能な範囲での変形が可能である。例えば、実施の形態のクーポンＴＢ３２６に、発行時間の項目を設けてもよい。また、例えば、実施の形態のクーポンＴＢ３２６には、発行先を特定するための決済ユーザＩＤが含まれているが、クーポンＴＢ３２６に決済ユーザＩＤを含めず、クーポンの発行先を管理するための別ＴＢを用意し、その別ＴＢでクーポンＩＤと決済ユーザＩＤとを関連付けて管理してもよい。この場合、発行時間はその別ＴＢで管理するとよい。

また、実施の形態に記載した認証方法は一例であり、実施の形態の手順に限るものではない。例えば、ＯＡｕｔｈ２．０を用いた認証方式であれば、任意に実行内容を変更できる。

また、実施の形態に開示されている任意のフローチャートにおいて、任意の複数のステップにおける複数の処理は、処理内容に矛盾が生じない範囲で、任意に実行順序を変更できる、または並列に実行できる。

また、実施の形態に開示されている処理は、単一のＣＰＵ、複数のＣＰＵ、ＡＳＩＣなどのハードウェア、またはそれらの組み合わせで実行されてもよい。また、実施の形態に開示されている処理は、その処理を実行するためのプログラムを記録した記録媒体、または方法等の種々の態様で実現することができる。

１ 店舗端末
２ 携帯端末
３ 決済サービスサーバ
４ パートナーサーバ
１００ 決済システム
２２１ パートナーアプリ
２２２ 決済ＳＤＫ
２２３ 決済アプリ
３２３ 連携ＴＢ
３２５ 決済ＴＢ
３２６ クーポンＴＢ

Claims (10)

1. 第１アプリケーションがインストールされた第１通信デバイスと、
   前記第１アプリケーションの少なくとも一部の機能を有するプログラムが組み込まれた第２アプリケーションがインストールされた第２通信デバイスと、通信可能なサーバにおいて、
   前記第１アプリケーションの識別情報と、前記第２アプリケーションの識別情報と、を連携し、
   前記第１通信デバイスと、前記第２通信デバイスとは、ともに前記サーバに決済処理を要求する決済機能を有しており、
   前記サーバは、
   前記第１通信デバイスからの決済処理の要求により決済処理が行われた場合、第１決済情報を決済データベースに登録し、
   前記第２通信デバイスからの決済処理の要求により決済処理が行われた場合、前記第２アプリケーションを用いた決済であることを識別可能な第２決済情報を前記決済データベースに登録し、
   前記第１通信デバイスからの決済履歴の照会の要求があった場合、前記第１決済情報と前記第２決済情報とを前記決済データベースから抽出して前記第１通信デバイスに応答し、
   前記第２通信デバイスからの決済履歴の照会の要求があった場合、前記第２決済情報を前記決済データベースから抽出して前記第２通信デバイスに応答する、
   ことを特徴とするサーバ。
2. 請求項１に記載するサーバにおいて、
   前記第１アプリケーションは、決済方法に関する情報と関連付けられており、
   前記サーバは、
   前記第２通信デバイスから決済処理の要求があった場合、前記第１アプリケーションに関連付けられた決済方法で決済処理を実行する、
   ことを特徴とするサーバ。
3. 請求項２に記載するサーバにおいて、
   前記第１通信デバイスから決済処理の要求があった場合、前記第１アプリケーションに関連付けられた決済方法で決済処理を実行する、
   ことを特徴とするサーバ。
4. 請求項１から請求項３のいずれか１つに記載するサーバにおいて、
   前記第１通信デバイスと同一のデバイスである前記第２通信デバイスと通信可能である、
   ことを特徴とするサーバ。
5. 請求項１から請求項４のいずれか１つに記載するサーバにおいて、
   前記第２通信デバイスと通信可能な外部サーバからの決済履歴の照会の要求があった場合、前記第２決済情報を前記決済データベースから抽出して前記外部サーバに応答する、
   ことを特徴とするサーバ。
6. 第１アプリケーションがインストールされた第１通信デバイスと、
   前記第１アプリケーションの少なくとも一部の機能を有するプログラムが組み込まれた第２アプリケーションがインストールされた第２通信デバイスと、通信可能なサーバにおいて、
   前記第１アプリケーションの識別情報と、前記第２アプリケーションの識別情報と、を連携し、
   前記サーバは、
   前記第１アプリケーションに関連付けられた第１特典と、
   前記第２アプリケーションに関連付けられた第２特典と、を発行し、
   前記第１特典は、前記第１アプリケーションおよび前記第２アプリケーションで利用可能であり、
   前記第２特典は、前記第２アプリケーションで利用可能である、
   ことを特徴とするサーバ。
7. 請求項１から請求項６のいずれか１つに記載するサーバにおいて、
   前記第２通信デバイスと通信可能な外部サーバから出力された特典の発行要求を受信したことに応じて、前記特典を前記プログラムを介して前記第２アプリケーションに発行する、
   ことを特徴とするサーバ。
8. サーバと通信可能な通信デバイスにインストールされる第１アプリケーションと第２アプリケーションとに含まれるプログラムであって、
   前記通信デバイスに、
   前記第１アプリケーションによる決済処理と、前記第２アプリケーションに組み込まれた前記プログラムによる決済処理を前記サーバに要求させる処理と、
   前記第１アプリケーションによる決済履歴の照会を前記サーバに要求させた場合、前記第１アプリケーションに関連付けられた第１決済情報と前記第２アプリケーションに関連付けられた第２決済情報とを、前記第１アプリケーションにより決済処理が行われた場合、前記第１アプリケーションに関連付けられた前記第１決済情報を決済データベースに登録し、前記第２アプリケーションにより決済処理が行われた場合、前記第２アプリケーションを用いた決済であることを識別可能な前記第２決済情報を前記決済データベースに登録する前記サーバから取得させる処理と、
   前記第２アプリケーションによる決済履歴の照会を前記サーバに要求させた場合、前記第２決済情報を前記サーバから取得させる処理と、
   を実行させるプログラム。
9. サーバに実行させるプログラムであって、
   第１アプリケーションがインストールされ、前記サーバに決済処理を要求する第１通信デバイスと、前記第１アプリケーションの少なくとも一部の機能を有するプログラムが組み込まれた第２アプリケーションがインストールされ、前記サーバに決済処理を要求する第２通信デバイスと、通信可能な前記サーバであって、前記第１アプリケーションの識別情報と、前記第２アプリケーションの識別情報とを連携する、前記サーバに、
   前記第１通信デバイスからの決済処理の要求により決済処理が行われた場合、第１決済情報を決済データベースに登録し、
   前記第２通信デバイスからの決済処理の要求により決済処理が行われた場合、前記第２アプリケーションを用いた決済であることを識別可能な第２決済情報を前記決済データベースに登録し、
   前記第１通信デバイスからの決済履歴の照会の要求があった場合、前記第１決済情報と前記第２決済情報とを前記決済データベースから抽出して前記第１通信デバイスに応答し、
   前記第２通信デバイスからの決済履歴の照会の要求があった場合、前記第２決済情報を前記決済データベースから抽出して前記第２通信デバイスに応答する、
   処理を実行させるプログラム。
10. サーバが実行する情報処理方法であって、
    第１アプリケーションがインストールされ、前記サーバに決済処理を要求する第１通信デバイスと、前記第１アプリケーションの少なくとも一部の機能を有するプログラムが組み込まれた第２アプリケーションがインストールされ、前記サーバに決済処理を要求する第２通信デバイスと、通信可能な前記サーバであって、前記第１アプリケーションの識別情報と、前記第２アプリケーションの識別情報と、を連携する、前記サーバが、
    前記第１通信デバイスからの決済処理の要求により決済処理が行われた場合、第１決済情報を決済データベースに登録し、
    前記第２通信デバイスからの決済処理の要求により決済処理が行われた場合、前記第２アプリケーションを用いた決済であることを識別可能な第２決済情報を前記決済データベースに登録し、
    前記第１通信デバイスからの決済履歴の照会の要求があった場合、前記第１決済情報と前記第２決済情報とを前記決済データベースから抽出して前記第１通信デバイスに応答し、
    前記第２通信デバイスからの決済履歴の照会の要求があった場合、前記第２決済情報を前記決済データベースから抽出して前記第２通信デバイスに応答する、
    処理を実行する情報処理方法。

Images