特開 2024-97822 サーバおよび通信デバイス

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024097822

(43)【公開日】2024-07-19

(54)【発明の名称】サーバおよび通信デバイス

(51)【国際特許分類】

   G06F 21/31 20130101AFI20240711BHJP

   G06Q 20/08 20120101ALI20240711BHJP

   G06Q 30/0207 20230101ALI20240711BHJP

【ＦＩ】

G06F21/31

G06Q20/08

G06Q30/0207 344

【審査請求】有

【請求項の数】11

【出願形態】ＯＬ

(21)【出願番号】P 2024071094

(22)【出願日】2024-04-25

(62)【分割の表示】P 2019201315の分割

【原出願日】2019-11-06

【新規性喪失の例外の表示】特許法第３０条第２項適用申請有り アプリ配信サービス「Ｇｏｏｇｌｅ Ｐｌａｙ」に掲載 令和１年９月２６日 アプリ配信サービス「Ａｐｐ ｓｔｏｒｅ」に掲載 令和１年９月３０日

(71)【出願人】

【識別番号】514053169

【氏名又は名称】株式会社メルカリ

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】梶谷 晋士

(72)【発明者】

【氏名】金 東日

(72)【発明者】

【氏名】玉城 信悟

(72)【発明者】

【氏名】二階堂 遍

(57)【要約】

【課題】通信デバイスにインストール可能な少なくとも一部の機能を共通とする互いに異
なるアプリケーションからの処理に基づく情報を、サーバを用いて管理可能とする技術を
提供すること。
【解決手段】決済システム１００は、決済アプリ２２３と、決済アプリ２２３の少なくと
も一部の機能を有する決済ＳＤＫ２２２が組み込まれたパートナーアプリ２２１と、通信
可能な決済サービスサーバ３を有する。決済サービスサーバ３は、決済アプリ２２３を識
別するための決済ユーザＩＤと、パートナーアプリ２２１を識別するための連携ＩＤおよ
びアプリコードと、を関連付けて連携ＴＢ３２３に記憶している。
【選択図】図１７

【特許請求の範囲】

【請求項1】

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

【請求項2】

請求項１に記載するサーバにおいて、
前記第１アプリケーションと、前記第２アプリケーションに組み込まれた前記プログラ
ムとは、ともに前記サーバに決済処理を要求する決済機能を有しており、
前記第１アプリケーションの識別情報は、決済方法に関する情報と関連付けられており
、
前記サーバは、
前記第２アプリケーションから決済処理の要求があった場合、前記第２アプリケーシ
ョンの識別情報と連携された前記第１アプリケーションの識別情報に関連付けられた決済
方法で決済処理を実行する、
ことを特徴とするサーバ。

【請求項3】

請求項２に記載するサーバにおいて、
前記第１アプリケーションから決済処理の要求があった場合、前記第１アプリケーショ
ンの識別情報に関連付けられた決済方法で決済処理を実行する、
ことを特徴とするサーバ。

【請求項4】

請求項２または請求項３に記載するサーバにおいて、
前記第１アプリケーションからの決済履歴の照会の要求があった場合、前記第１アプリ
ケーションの識別情報に関連付けられた決済履歴を前記第１アプリケーションに応答し、
前記第２アプリケーションからの決済履歴の照会の要求があった場合、前記第１アプリ
ケーションの識別情報に関連付けられた決済履歴のうち、前記第２アプリケーションから
の要求で決済された決済履歴を前記第２アプリケーションに応答する、
ことを特徴とするサーバ。

【請求項5】

請求項２から請求項４のいずれか１つに記載するサーバにおいて、
前記第２アプリケーションと通信可能な外部サーバからの決済履歴の照会の要求があっ
た場合、前記第１アプリケーションの識別情報に関連付けられた決済履歴のうち、前記第
２アプリケーションからの要求で決済された決済履歴を前記外部サーバに応答する、
ことを特徴とするサーバ。

【請求項6】

請求項１から請求項５のいずれか１つに記載するサーバにおいて、
前記サーバは、
前記第１アプリケーションの識別情報に関連付けられた第１特典と、
前記第２アプリケーションの識別情報に関連付けられた第２特典と、を発行し、
前記第１特典は、前記第１アプリケーションおよび前記プログラムが組み込まれた前記
第２アプリケーションで利用可能であり、
前記第２特典は、前記プログラムが組み込まれた前記第２アプリケーションで利用可能
である、
ことを特徴とするサーバ。

【請求項7】

請求項６に記載するサーバにおいて、
前記第１特典を発行する場合、前記第１アプリケーションおよび前記第２アプリケーシ
ョンに対して前記第１特典の発行を通知し、さらに前記第２アプリケーションに対する通
知は、第１アプリケーションへの通知と比較して、通知の強度が低い、
ことを特徴とするサーバ。

【請求項8】

請求項１から請求項７のいずれか１つに記載するサーバにおいて、
前記第２アプリケーションと通信可能な外部サーバから出力された特典の発行要求を受
信したことに応じて、前記特典を前記プログラムを介して前記第２アプリケーションに発
行する、
ことを特徴とするサーバ。

【請求項9】

第１アプリケーションと、
前記第１アプリケーションの一部の機能を有するプログラムが組み込まれた第２アプリ
ケーションと、がインストールされ、
前記第１アプリケーションと前記第２アプリケーションとは、ともにサーバと通信可能
であり、
前記第１アプリケーションと、前記第２アプリケーションに組み込まれた前記プログラ
ムとは、ともに前記サーバに決済処理を要求する決済機能を有しており、
前記第１アプリケーションから決済履歴の照会を前記サーバに要求した場合、前記第１
アプリケーションの識別情報に関連付けられた決済履歴を前記サーバから取得し、
前記第２アプリケーションから決済履歴の照会を前記サーバに要求した場合、前記第１
アプリケーションの識別情報に関連付けられた決済履歴のうち、前記第２アプリケーショ
ンからの要求で決済された決済履歴を前記サーバから取得する、
ことを特徴とする通信デバイス。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１６－１８５０１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

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

【0006】

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

【課題を解決するための手段】

【0007】

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

【0008】

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

【発明の効果】

【0009】

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

【図面の簡単な説明】

【0010】

【図1】実施の形態にかかる決済システムの概略構成図である。

【図2】実施の形態にかかる携帯端末の構成を示すブロック図である。

【図3】実施の形態にかかる決済サービスサーバの構成を示すブロック図である。

【図4】決済サービスサーバが有する決済ユーザＴＢの構成を示す図である。

【図5】決済サービスサーバが有する決済方法ＴＢの構成を示す図である。

【図6】決済サービスサーバが有する連携ＴＢの構成を示す図である。

【図7】決済サービスサーバが有する決済ＴＢの構成を示す図である。

【図8】決済サービスサーバが有するクーポンＴＢの構成を示す図である。

【図9】決済アプリからログイン要求する際の処理の流れを示す図である。

【図10】パートナーアプリからログイン要求する際の処理の流れを示す図である。

【図11】決済アプリから決済を行う際の処理の流れを示す図である。

【図12】決済アプリから決済履歴の照会を行う際の処理の流れを示す図である。

【図13】パートナーアプリから決済履歴の照会を行う際の処理の流れを示す図である。

【図14】パートナーサーバから決済履歴の照会を行う際の処理の流れを示す図である。

【図15】決済サービスサーバにおけるクーポン配信処理の手順を示すフローチャートである。

【図16】パートナーサーバからの要求によって決済サービスサーバからパートナーアプリにクーポンを発行する際の処理の流れを示す図である。

【図17】決済システムにおける決済ユーザＩＤと他の情報との関連を示す図である。

【発明を実施するための形態】

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【符号の説明】

【0099】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【手続補正書】

【提出日】2024-05-08

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

情報処理装置に、
第１決済手段を利用した決済履歴を表示する場合に、前記第１決済手段による決済履歴を表示させることと、
第２決済手段を利用した決済履歴を表示する場合に、前記第２決済手段による決済履歴と、前記第１決済手段による決済履歴とをともに表示させることと、
を実行させるプログラム。

【請求項2】

前記第１決済手段と、前記第２決済手段とは、同一の決済サービスから提供される、
請求項１に記載のプログラム。

【請求項3】

前記第１決済手段と、前記第２決済手段とは、それぞれ異なるアプリケーションに含まれる、
請求項１または２に記載のプログラム。

【請求項4】

情報処理装置に、
前記第１決済手段による決済要求を送信させることと、
前記第２決済手段による決済要求を送信させることと、をさらに実行させ、
前記第１決済手段による決済要求と、前記第２決済手段による決済要求とは、同一のサーバに送信される、
請求項１から３のいずれか一項に記載のプログラム。

【請求項5】

情報処理装置が、
第１決済手段を利用した決済履歴を表示する場合に、前記第１決済手段による決済履歴を表示させることと、
第２決済手段を利用した決済履歴を表示する場合に、前記第２決済手段による決済履歴と、前記第１決済手段による決済履歴とをともに表示させることと、
を実行する情報処理方法。

【請求項6】

第１決済手段を利用した決済履歴を表示する場合に、前記第１決済手段による決済履歴を表示させることと、
第２決済手段を利用した決済履歴を表示する場合に、前記第２決済手段による決済履歴と、前記第１決済手段による決済履歴とをともに表示させることと、
を実行する情報処理装置。

【請求項7】

情報処理装置が、
第１決済手段による第１決済情報と第２決済手段による第２決済情報とを記憶することと、
前記第１決済手段を利用した決済履歴表示要求を取得した場合に、前記第１決済手段による決済履歴を表示させることと、
前記第２決済手段を利用した決済履歴表示要求を取得した場合に、前記第２決済手段による決済履歴と、前記第１決済手段による決済履歴とを表示させることと、
を実行する情報処理方法。

【請求項8】

前記第１決済手段と、前記第２決済手段とは、同一の決済サービスから提供される、
請求項７に記載の情報処理方法。

【請求項9】

前記第１決済手段と、前記第２決済手段とは、それぞれ異なるアプリケーションに含まれる、
請求項７または８に記載の情報処理方法。

【請求項10】

情報処理装置に、
第１決済手段と第２決済手段とを対応付けることと、
前記第１決済手段を利用した決済履歴表示要求を取得した場合に、前記第１決済手段による決済履歴を表示させることと、
前記第２決済手段を利用した決済履歴表示要求を取得した場合に、前記第２決済手段による決済履歴と、前記第１決済手段による決済履歴とを表示させることと、
を実行させるプログラム。

【請求項11】

第１決済手段と第２決済手段とを対応付けることと、
前記第１決済手段を利用した決済履歴表示要求を取得した場合に、前記第１決済手段による決済履歴を表示させることと、
前記第２決済手段を利用した決済履歴表示要求を取得した場合に、前記第２決済手段による決済履歴と、前記第１決済手段による決済履歴とを表示させることと、
を実行する情報処理装置。