JP2023066916A - サービス提供システム、サービス提供方法、及びプログラム - Google Patents

Abstract

【課題】複数のアプリを利用するユーザの利便性が高まる。【解決手段】サービス提供システム（Ｓ）では、第１アプリに基づいて第１サービスがユーザに提供され、第２アプリに基づいて第２サービスがユーザに提供される。第２アプリでは、第２サービスに関するユーザのメンバーシップ情報が確認される。確認判定手段（４０１）は、第１サービスが提供される場合に、メンバーシップ情報が第２アプリで確認済みであるか否かを判定する。処理実行手段（４０２）は、メンバーシップ情報が第２アプリで確認済みであると判定された場合に、第１サービスに関する特定の処理を実行する。【選択図】図５

Description

本開示は、サービス提供システム、サービス提供方法、及びプログラムに関する。

従来、複数のアプリを利用するユーザの利便性を高める技術が知られている。例えば、特許文献１には、複数のアプリがインストールされたユーザ端末から、会員証を識別する会員証識別子と、アプリの種類を識別するアプリ種類識別子と、を有する会員証情報を受信し、各アプリの利用状況を一元管理する技術が記載されている。例えば、非特許文献１には、ユーザのウォレットアプリに登録されたクレジットカードを利用して、ウォレットアプリと連携する学生証アプリの電子マネーにチャージする技術が記載されている。

特許第６５９０８７９号公報

「iPhoneやApple WatchのWalletで学生証を使う」，インターネット，２０２１年１０月８日検索，ｏｎｌｉｎｅ，https://support.apple.com/ja-jp/HT208965

しかしながら、特許文献１の技術は、複数のアプリの利用状況を一元管理することはできるが、アプリ同士が連携するものではなく、ユーザの利便性を十分に高めることはできない。非特許文献１の技術は、学生証アプリに学生証が登録されたとしても、単に学生証アプリの電子マネーにチャージできるというだけであり、ウォレットアプリから利用可能な決済サービスの機能自体は変わらないので、ユーザの利便性を十分に高めることはできない。このため、従来の技術では、複数のアプリを利用するユーザの利便性を十分に高めることができなかった。

本開示の目的の１つは、複数のアプリを利用するユーザの利便性を高めることである。

本開示に係るサービス提供システムは、第１アプリに基づいて第１サービスがユーザに提供され、第２アプリに基づいて第２サービスが前記ユーザに提供されるサービス提供システムであって、前記第２アプリでは、前記第２サービスに関する前記ユーザのメンバーシップ情報が確認され、前記第１サービスが提供される場合に、前記メンバーシップ情報が前記第２アプリで確認済みであるか否かを判定する確認判定手段と、前記メンバーシップ情報が前記第２アプリで確認済みであると判定された場合に、前記第１サービスに関する特定の処理を実行する処理実行手段と、を含む。

本開示によれば、複数のアプリを利用するユーザの利便性が高まる。

サービス提供システムの全体構成の一例を示す図である。 学生証アプリが追加される前の決済アプリの画面の一例を示す図である。 学生証アプリを追加する流れの一例を示す図である。 学生証アプリが追加された後の決済アプリの画面の一例を示す図である。 第１実施形態で実現される機能の一例を示す機能ブロック図である。 第１データベースの一例を示す図である。 第２データベースの一例を示す図である。 第１実施形態で実行される処理の一例を示すフロー図である。 第１実施形態で実行される処理の一例を示すフロー図である。 第２実施形態における決済アプリの画面の一例を示す図である。 第２実施形態で実現される機能の一例を示す図である。 第２実施形態で実行される処理の一例を示すフロー図である。 第１実施形態に係る変形例における機能ブロック図の一例である。 第２実施形態に係る変形例における機能ブロック図の一例である。

［１．第１実施形態］
本開示に係るサービス提供システムの実施形態の一例である第１実施形態を説明する。

［１－１．サービス提供システムの全体構成］
図１は、サービス提供システムの全体構成の一例を示す図である。サービス提供システムＳは、第１サーバ１０、第２サーバ２０、ユーザ端末３０、及び店舗端末４０を含む。これらは、インターネット等のネットワークＮに接続可能である。サービス提供システムＳは、少なくとも１つのコンピュータを含めばよく、図１の例に限られない。

第１サーバ１０は、サーバコンピュータである。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。第１サーバ１０は、第１サービスの提供者により管理される。

第１実施形態では、第１サービスの一例として、決済サービスを説明する。このため、決済サービスと記載した箇所は、第１サービスと読み替えることができる。決済サービスは、電子決済（キャッシュレス決済）を提供するサービスである。決済サービスで利用可能な決済手段は、任意の種類であってよく、例えば、クレジットカード、電子マネー、ポイント、銀行口座、デビットカード、ウォレット、又は仮想通貨であってもよい。決済サービス以外の第１サービスの例は、後述の変形例で説明する。

第２サーバ２０は、サーバコンピュータである。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。第２サーバ２０は、第２サービスの提供者により管理される。

第１実施形態では、第２サービスの一例として、デジタル学生証サービスを説明する。このため、デジタル学生証サービスと記載した箇所は、第２サービスと読み替えることができる。デジタル学生証サービスは、ユーザの学生証を登録すると、学校生活に関する機能が提供されるサービスである。例えば、通学証明の表示、授業の出席登録、時間割の確認、学校との連絡、又は図書館等の施設へのチェックインといった機能が提供される。デジタル学生証サービス以外の第２サービスの例は、後述の変形例で説明する。

ユーザ端末３０は、ユーザのコンピュータである。例えば、ユーザ端末３０は、スマートフォン、タブレット端末、ウェアラブル端末、又はパーソナルコンピュータである。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。通信部１３は、ＮＦＣ（Near Field Communication）が可能な通信インタフェースを含んでもよい。

操作部３４は、タッチパネル等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。撮影部３６は、少なくとも１つのカメラを含む。ＩＣチップ３７は、任意の規格のチップであってよく、例えば、ＦｅｌｉＣａ（登録商標）のチップ、又は、非接触型規格におけるいわゆるＴｙｐｅＡ若しくはＴｙｐｅＢのチップである。ＧＰＳ受信部３８は、衛星からの信号を受信する受信機を含む。

店舗端末４０は、店舗に配置されたコンピュータである。例えば、店舗端末４０は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。制御部４１、記憶部４２、通信部４３、操作部４４、及び表示部４５の物理的構成は、それぞれ制御部１１、記憶部１２、通信部１３、操作部３４、及び表示部３５と同様である。通信部４３は、ＮＦＣが可能な通信インタフェースを含んでもよい。読取部４６は、コードリーダ又はカメラを含む。読取部４６は、店舗端末４０の外部に接続されてもよい。

なお、第１サーバ１０、第２サーバ２０、ユーザ端末３０、及び店舗端末４０の各々に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。また、情報記憶媒体に記憶されたプログラムが、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）を介して供給されてもよい。

［１－２．第１実施形態の概要］
サービス提供システムＳでは、決済アプリに基づいて決済サービスがユーザに提供される。決済アプリは、第１アプリの一例である。このため、決済アプリと記載した箇所は、第１アプリと読み替えることができる。第１アプリは、第１サービスを提供するためのアプリケーションである。第１アプリは、ユーザ端末３０にダウンロードされてインストールされる。なお、第１アプリは、ユーザ端末３０にインストールされるものではなく、第１サーバ１０上で実行されるタイプであってもよい。ユーザ端末３０には、第１サーバ１０上で実行された第１アプリの実行結果がブラウザ等を利用して表示されてもよい。

サービス提供システムＳでは、学生証アプリに基づいてデジタル学生証サービスがユーザに提供される。学生証アプリは、第２アプリの一例である。このため、学生証アプリと記載した箇所は、第２アプリと読み替えることができる。第２アプリは、第２サービスを提供するためのアプリケーションである。第２アプリは、ユーザ端末３０にダウンロードされてインストールされる。なお、第２アプリは、ユーザ端末３０にインストールされるものではなく、第２サーバ２０上で実行されるタイプであってもよい。ユーザ端末３０には、第２サーバ２０上で実行された第２アプリの実行結果がブラウザ等を利用して表示されてもよい。

第１実施形態では、決済アプリがスーパーアプリであり、学生証アプリが当該スーパーアプリから利用可能なミニアプリである場合を例に挙げる。スーパーアプリは、複数のアプリが統合されたプラットフォームの役割を果たすアプリである。ミニアプリは、スーパーアプリから利用可能なアプリである。ここでは、ユーザが、ユーザ端末３０に決済アプリをインストール済みであるが、まだ学生証アプリを追加していないものとする。

図２は、学生証アプリが追加される前の決済アプリの画面の一例を示す図である。ユーザが決済アプリを起動させると、決済アプリのトップ画面Ｇ１が表示部３５に表示される。例えば、トップ画面Ｇ１には、決済処理を実行するためのコード画像Ｃ１０が表示される。コード画像Ｃ１０が店舗端末４０の読取部４６で読み取られると、決済処理が実行されて決済完了画面Ｇ２が表示部３５に表示される。

トップ画面Ｇ１には、利用中のミニアプリのアイコンＩ１１も表示される。ユーザがアイコンＩ１１を選択すると、ミニアプリが起動する。ユーザは、リンクＬ１２を選択することによって、ミニアプリを追加できる。例えば、ユーザがリンクＬ１２を選択すると、ミニアプリを選択するための選択画面が表示部３５に表示される。ここでは、ユーザが学生証アプリを追加する流れを説明する。

図３は、学生証アプリを追加する流れの一例を示す図である。例えば、選択画面Ｇ３には、ユーザが追加できるミニアプリの一覧が表示される。ユーザが選択画面Ｇ３から学生証アプリを選択すると、学生証アプリがユーザ端末３０にダウンロード及びインストールされる。学生証アプリのインストールが完了すると、学生証を登録するための登録画面Ｇ４が表示部３５に表示される。学生証を登録するとは、学生証に含まれる情報を学生証アプリに登録することである。

第１実施形態では、ユーザの学生証は、学生番号等の種々の情報が記録されたＩＣチップを含むものとする。ユーザは、通信部３３のＮＦＣ機能を利用して、学生証をスキャンする。学生証のスキャンが完了すると、ユーザの学生証が学生証アプリに登録されて登録完了画面Ｇ５が表示部３５に表示される。以降、ユーザは、スーパーアプリである決済アプリから、ミニアプリである学生証アプリを呼び出すことによって、デジタル学生証サービスを利用できる。

図４は、学生証アプリが追加された後の決済アプリの画面の一例を示す図である。図４のトップ画面Ｇ１のように、学生証アプリのアイコンＩ１１が追加される。ユーザが学生証アプリのアイコンＩ１１を選択すると、学生証アプリのトップ画面Ｇ６が表示部３５に表示される。ユーザは、トップ画面Ｇ６から、デジタル学生証サービスが提供する種々の機能を利用できる。

第１実施形態では、ユーザが学生証アプリに学生証を登録すると、ユーザは、決済アプリから特定の機能を利用できるようになる。第１実施形態では、この機能の一例として、学割機能を説明する。この機能は、学生証アプリに学生証が登録されたことを条件として利用できるようになる機能であればよく、学割機能に限られない。学割機能以外の他の機能の例は、後述の変形例で説明する。

例えば、ユーザが学生証アプリに学生証を登録すると、ユーザが学生であることを示す情報がコード画像Ｃ１０に含まれるようになる。店舗端末４０は、この情報により、ユーザが学生であることを特定できる。例えば、映画館のように学割制度がある店舗であれば、店舗端末４０がこの情報を取得したことにより、自動的に学割が適用される。図４のように、ユーザが映画館でコード画像Ｃ１０を提示して決済処理を実行すると、学割価格で決済処理が実行されたことを示す決済完了画面Ｇ２が表示部３５に表示される。

以上のように、第１実施形態のサービス提供システムＳは、学生証アプリに学生証を登録すると、店舗端末４０でコード画像Ｃ１０を読み取るだけで自動的に学割が適用される。これにより、ユーザが映画館等の店舗でいちいち学生証を提示しなくても、通常の決済の流れと同じようにコード画像Ｃ１０を提示するだけで自動的に学割を適用できるので、ユーザの利便性が高まる。以降、第１実施形態の詳細を説明する。

［１－３．第１実施形態で実現される機能］
図５は、第１実施形態で実現される機能の一例を示す機能ブロック図である。

［１－３－１．第１サーバで実現される機能］
データ記憶部１００は、記憶部１２を主として実現される。第１提供部１０１は、制御部１１を主として実現される。

［データ記憶部］
データ記憶部１００は、ユーザに決済サービスを提供するために必要なデータを記憶する。例えば、データ記憶部１００は、第１データベースＤＢ１を記憶する。

図６は、第１データベースＤＢ１の一例を示す図である。図６に示すように、第１データベースＤＢ１は、決済サービスにおけるユーザに関する情報が格納されたデータベースである。このユーザは、決済サービスの利用登録をしたユーザである。例えば、第１データベースＤＢ１には、ユーザＩＤ、パスワード、ユーザ情報、コードＩＤ、有効期限、決済情報、ミニアプリ情報、及び利用履歴情報が格納される。第１データベースＤＢ１に格納される情報は、ユーザに関する任意の情報であってよく、図６の例に限られない。

ユーザＩＤは、決済サービスにおいてユーザを識別可能なユーザ識別情報の一例である。ユーザ識別情報は、任意の情報であってよく、例えば、ユーザアカウントと呼ばれる情報、メールアドレス、又は電話番号であってもよい。例えば、ユーザ識別情報は、文字、数字、その他の記号、又はこれらの組み合わせである。ユーザＩＤ及びパスワードは、第１サービスにログインするために利用される。

ユーザ情報は、ユーザが登録した情報である。例えば、ユーザ情報は、ユーザの個人情報である。例えば、ユーザ情報は、ユーザの氏名、性別、生年月日、住所、電話番号、メールアドレス、職業、又はこれらの組み合わせを含んでもよい。例えば、ユーザ情報は、ユーザが所属する組織の名前を含んでもよい。第１実施形態では、組織の一例として学校を説明するが、組織自体は、任意の種類であってよく、学校に限られない。例えば、組織は、会社、役所、地方公共団体、非営利団体、部活、又はサークルであってもよい。組織は、機関ということもできる。組織は、複数の組織であってもよい。

コードＩＤは、コード画像Ｃ１０に含まれる情報である。コードＩＤは、決済サービスを利用しようとしているユーザを識別可能な情報である。コードＩＤは、ユーザ識別情報の一例である。第１実施形態では、コードＩＤがコード画像Ｃ１０に含まれる場合を説明するが、ユーザＩＤ等の他のユーザ識別情報がコード画像Ｃ１０に含まれてもよい。有効期限は、コードＩＤが発行されてから所定時間後の時点である。有効期限は、任意の長さであってよく、例えば、１分～１時間程度であってもよいし、数時間～数日程度であってもよい。コードＩＤには、有効期限が設定されなくてもよい。

例えば、第１サーバ１０は、所定の発行ルールに基づいて、他のコードＩＤと重複しないようにコードＩＤを発行する。コードＩＤは、有効期限内の他のコードＩＤと重複しないようにすればよく、有効期限切れの他のコードＩＤとは重複してもよい。コードＩＤは、任意のタイミングで発行可能である。例えば、決済アプリが起動した場合、有効期限が経過した場合、コードＩＤを更新する操作が行われた場合、又は所定の日時が訪れた場合に、コードＩＤが発行されてもよい。

決済情報は、ユーザの決済手段に関する情報である。例えば、決済手段がクレジットカードであれば、決済情報は、クレジットカード番号、有効期限、及び名義人を含む。決済手段が電子マネーであれば、決済情報は、電子マネーを識別可能な電子マネーＩＤと、電子マネーの残高と、を含む。決済手段が銀行口座であれば、決済情報は、銀行口座の支店名（支店番号）、口座番号、及び名義人を含む。他の決済手段も同様に、決済情報は、決済手段に応じた情報を含めばよい。複数の決済手段を登録可能な決済サービスであれば、決済情報は、支払い元として設定された決済手段を識別可能な情報を含んでもよい。

ミニアプリ情報は、ユーザが利用するミニアプリに関する情報である。例えば、ミニアプリ情報は、ミニアプリを識別可能なミニアプリＩＤを含む。ユーザがリンクＬ１２を選択してミニアプリを追加すると、このミニアプリのミニアプリＩＤがミニアプリ情報に追加される。トップ画面Ｇ１のアイコンＩ１１は、ミニアプリ情報に基づいて表示される。第１実施形態では、ミニアプリの利用状況に関する利用状況情報が第２データベースＤＢ２に格納される場合を説明するが、ミニアプリの利用状況情報は、第１データベースＤＢ１に格納されてもよい。他にも例えば、ミニアプリ情報には、学生証アプリに登録された学生証に関する各種情報が含まれてもよい。この情報は、学生証アプリの登録時にユーザ端末３０からアップロードされて第１データベースに登録されてもよい。この情報は、学生証のＩＣカード又は券面に含まれる情報であり、例えば、学生番号、氏名、入学年といった情報であってよい。

利用履歴情報は、決済サービスの利用履歴に関する情報である。例えば、利用履歴情報は、決済サービスの利用日時、利用場所、及び利用額を含む。ユーザが決済サービスを利用するたびに、このユーザの利用履歴情報が更新される。

［第１提供部］
第１提供部１０１は、ユーザ端末３０の決済アプリに基づいて、ユーザに決済サービスを提供する。第１実施形態では、第１提供部１０１は、トップ画面Ｇ１に表示されたコード画像Ｃ１０に基づいて、ユーザに決済サービスを提供する。例えば、店舗端末４０は、コード画像Ｃ１０が読取部４６で読み取られた場合に、第１サーバ１０に決済要求を送信する。決済要求は、決済処理を要求するための通知である。例えば、決済要求には、店舗の店舗ＩＤ、コード画像Ｃ１０から取得されたコードＩＤ、及び利用額が含まれる。

第１提供部１０１は、第１サーバ１０が受信した決済要求に基づいて、ユーザに決済サービスを提供する。例えば、第１提供部１０１は、第１データベースＤＢ１を参照し、決済要求に含まれるコードＩＤの有効期限を取得する。コードＩＤの有効期限が経過している場合、決済処理は実行されない。第１提供部１０１は、コードＩＤの有効期限内である場合、コードＩＤに関連付けられた決済情報に基づいて、決済処理を実行する。決済処理自体は、公知の処理を利用可能である。第１提供部１０１は、決済処理の実行結果に基づいて、コードＩＤに関連付けられた利用履歴情報を更新する。

以上の一連の処理は、決済アプリが起点となるので、第１提供部１０１は、決済アプリに基づいて、ユーザに第１サービスを提供することになる。第１提供部１０１は、決済アプリがインストールされたユーザ端末３０と直接的に通信することによって、ユーザに第１サービスを提供してもよい。例えば、ユーザが決済アプリから決済サービスを利用する店舗を選択する場合には、第１提供部１０１は、ユーザ端末３０から決済要求を受信することによって、ユーザに第１サービスを提供する。この場合、ユーザが利用額を入力してもよい。

例えば、店舗端末４０に表示されたコード画像をユーザ端末３０で読み取ることによって、決済処理が実行されてもよい。この場合、このコード画像には、店舗ＩＤ及び利用額といった情報が含まれてもよい。ユーザ端末３０は、コード画像を読み取ると、第１サーバ１０に決済要求を送信する。第１サーバ１０が決済要求を受信した後の流れは、コード画像Ｃ１０が店舗端末４０で読み取られた場合の流れと同様であってもよい。他にも例えば、店舗に掲示されたコード画像をユーザ端末３０で読み取ることによって、決済処理が実行されてもよい。

［１－３－２．第２サーバで実現される機能］
データ記憶部２００は、記憶部２２を主として実現される。第２提供部２０１は、制御部２１を主として実現される。

［データ記憶部］
データ記憶部２００は、ユーザにデジタル学生証サービスを提供するために必要なデータを記憶する。例えば、データ記憶部２００は、第２データベースＤＢ２を記憶する。

図７は、第２データベースＤＢ２の一例を示す図である。第２データベースＤＢ２は、デジタル学生証サービスにおけるユーザに関する情報が格納されたデータベースである。このユーザは、学生証アプリに学生証を登録したユーザである。例えば、第２データベースＤＢ２には、学校ＩＤ、学生番号、パスワード、ユーザ情報、及び利用状況情報が格納される。学校ＩＤは、学校を一意に識別可能な学校識別情報の一例である。学校識別情報は、学校名等の他の情報であってもよい。

学生番号は、デジタル証明書サービスにおいてユーザを識別可能なユーザ識別情報の一例である。学生番号は、学籍番号と呼ばれることもある。このユーザ識別情報は、任意の情報であってよく、例えば、ユーザＩＤ、ユーザアカウント、メールアドレス、又は電話番号であってもよい。デジタル証明書サービスのユーザ識別情報と、決済サービスのユーザ識別情報と、は同じであってもよい。学生番号及びパスワードは、デジタル学生証サービスにログインするために利用される。なお、ある学校と他の学校で学生番号が同じになることがあるので、学校ＩＤ及び学生番号の組み合わせによってユーザが識別されてもよい。

ユーザ情報は、デジタル証明書サービスに登録されたユーザ情報という意味で、第１データデータＤＢ１に格納されたユーザ情報と異なるが、ユーザ情報の言葉の意味自体は、先述した通りである。第２データベースＤＢ２に格納されたユーザ情報は、学生証に含まれる情報であってもよいし、学生証には含まれない情報であってもよい。学生証に含まれる情報とは、学生証のＩＣチップに格納された情報、又は、学生証の券面に形成された情報である。例えば、ユーザ情報は、学生証に含まれる学生番号、氏名、生年月日、学科、学年、入学年、又は顔写真を含んでもよい。ユーザ情報は、ユーザの時間割の情報や学校とやり取りしたメッセージ等を含んでもよい。

利用状況情報は、デジタル学生証サービスの利用状況に関する情報である。例えば、利用状況情報には、授業への出欠状況、ユーザの時間割、学校との連絡内容、又は図書館等の施設へのチェックイン状況といった情報が格納される。ユーザが学生証アプリからデジタル学生証サービスを利用すると、利用状況情報が更新される。利用状況情報は、デジタル学生証サービスに関する任意の情報を含んでもよい。例えば、利用状況情報は、テストやレポートの成績、単位の取得状況、又は就職活動等のセミナーへの申し込み状況といった情報を含んでもよい。

［第２提供部］
第２提供部２０１は、ユーザ端末３０の学生証アプリに基づいて、ユーザにデジタル学生証サービスを提供する。例えば、第２提供部２０１は、ユーザ端末３０で学生証アプリが起動すると、所定のログイン処理を実行する。第２提供部２０１は、ログイン処理が成功すると、第２データベースＤＢ２に格納された、デジタル学生証サービスにログインしたユーザの情報に基づいて、ユーザにデジタル学生証サービスを提供する。

例えば、第２提供部２０１は、ユーザが通学証明の表示を要求した場合、ユーザ情報に含まれる学科や学年等に基づいて、通学証明の画面をユーザ端末３０に表示させる。第２提供部２０１は、ユーザが授業への出席登録を要求した場合、ユーザが要求した授業に出席したことを示すように利用状況情報を更新する。第２提供部２０１は、ユーザが時間割の表示を要求した場合、ユーザ情報に含まれる時間割の画面をユーザ端末３０に表示させる。

例えば、第２提供部２０１は、ユーザがメッセージの表示を要求した場合、ユーザ情報に含まれるメッセージをユーザ端末３０に表示させる。第２提供部２０１は、ユーザが図書館等の施設へのチェックインを要求した場合、学生証アプリにチェックイン用のコードを表示させる。このコードには、ユーザの学生番号が含まれてもよいし、決済アプリのコードＩＤのように一時的なＩＤが含まれてもよい。図書館等の施設では、コードリーダ又はカメラが配置されており、このコードが読み取られることによって、チェックインが実行されてもよい。

［１－３－３．ユーザ端末で実現される機能］
データ記憶部３００は、記憶部３２を主として実現される。表示制御部３０１及び確認部３０２は、制御部３１を主として実現される。

[データ記憶部]
データ記憶部３００は、ユーザが決済サービス及びデジタル学生証サービスの各々を利用するために必要なデータを記憶する。例えば、データ記憶部３００は、決済アプリ及びコードＩＤを記憶する。ユーザ端末３０は、第１サーバ１０により発行されたコードＩＤを受信して自身のデータ記憶部３００に記録する。ユーザ端末３０は、コードＩＤの有効期限も受信した場合には、有効期限も自身のデータ記憶部３００に記録する。

例えば、データ記憶部３００は、学生証アプリと、学生証アプリに登録された学生証に関する情報と、を記憶する。この情報は、第２データベースＤＢ２に格納されたユーザ情報の全部又は一部であってもよいし、学生証が学生証アプリに登録されたか否かを示すだけの情報であってもよい。データ記憶部３００は、学生証アプリ以外のミニアプリと、ミニアプリに関する情報と、も記憶する。

［表示制御部］
表示制御部３０１は、決済アプリに基づいて、図２～図４で説明した画面を表示部３５に表示させる。例えば、表示制御部３０１は、決済アプリに基づいて、コードＩＤを含むコード画像Ｃ１０をトップ画面Ｇ１に表示させる。コード画像Ｃ１０は、コードＩＤ以外の任意の情報を含んでよい。表示制御部３０１は、決済アプリに基づいて、決済完了画面Ｇ２等の他の画面も表示させる。表示制御部３０１は、学生証アプリに基づいて、学生証アプリのトップ画面Ｇ６等の画面を表示させる。

［確認部］
第１実施形態の学生証アプリでは、ユーザの学生証が確認される。確認部３０２は、学生証アプリに基づいて、ユーザの学生証を確認する。学生証を確認するとは、学生証の有無及び正当性を確認することである。学生証を確認することは、学生証を利用した所持認証を行うことに相当する。学生証は、メンバーシップ情報の一例である。このため、学生証と記載した箇所は、メンバーシップ情報と読み替えることができる。即ち、学生証に含まれる学生番号等の情報は、メンバーシップ情報の一例であり、学生番号等の情報について説明している箇所は、メンバーシップ情報と読み替えることができる。

メンバーシップ情報は、第２サービスを利用する権利を有すること、又は、第２サービスのユーザであることを識別可能な情報である。第１実施形態のように、第２サービスが、ユーザが所属する組織に関するサービスである場合には、メンバーシップ情報は、ユーザが組織に所属することを証明可能な情報である。例えば、第１実施形態のようなデジタル学生証サービスであれば、学生証を保有していることは、ユーザが学校に所属することを証明可能なので、学生証は、メンバーシップ情報に相当する。例えば、学生証に含まれる学生番号等の情報も、ユーザが学校に所属することを証明可能なので、学生番号等の情報は、メンバーシップ情報に相当する。

メンバーシップ情報は、第２サービスの内容に応じた任意の情報であってよく、学生証に限られない。第２サービスが店舗に関するサービスであれば、メンバーシップ情報は、店舗が発行した会員証、又は、会員証に含まれる会員番号等の情報であってもよい。例えば、会員証は、第２アプリをユーザ端末３０にインストールする前に、ユーザが訪れた店舗等で発行される。第２サービスが会社に関するサービスであれば、メンバーシップ情報は、社員証、又は、社員証に含まれる社員番号等の情報であってもよい。第２サービスが保険に関するサービスであれば、メンバーシップ情報は、保険証、又は、保険証に含まれる保険証番号等の情報であってもよい。

学生証を確認するとは、学生証の有無を確認することである。第１実施形態では、学生証が学生証アプリに登録されることは、学生証が確認されることに相当する。学生証は、学生証アプリに登録されるのではなく、単に学生証の有無の確認だけが行われてもよい。例えば、確認部３０２は、通信部３３のＮＦＣ機能を利用して学生証をスキャンすることによって、学生証を確認する。

確認部３０２は、学生証のＩＣチップに格納された学生番号や氏名等の情報を取得し、第２サーバ２０又は他のサーバ（例えば、学校が管理するサーバ）に、学生番号や氏名等の情報の正当性の確認を依頼する。第２サーバ２０又は他のサーバには、学生番号や氏名等の情報が格納された学生データベースが記憶されているものとする。第２サーバ２０又は他のサーバは、正当性の確認結果をユーザ端末３０に送信する。確認部３０２は、第２サーバ２０又は他のサーバから正当性の確認結果を受信する。確認部３０２は、正当性が確認されると、ユーザの学生証を学生証アプリに登録する。確認部３０２は、ユーザの学生証が確認されたことを示す確認済み情報を、データ記憶部３００に記録する。

［１－３－４．店舗端末で実現される機能］
データ記憶部４００は、記憶部４２を主として実現される。確認判定部４０１及び処理実行部４０２は、制御部４１を主として実現される。

［データ記憶部］
データ記憶部４００は、決済サービスの提供に必要なデータを記憶する。例えば、データ記憶部４００は、店舗端末４０が配置された店舗の店舗ＩＤと、店舗端末４０を識別可能な端末ＩＤと、を記憶する。

［確認判定部］
確認判定部４０１は、決済サービスが提供される場合に、学生証が学生証アプリで確認済みであるか否かを判定する。決済サービスが提供される場合とは、ユーザが決済サービスを利用するトリガとなる行為が行われた場合である。第１実施形態では、コード画像Ｃ１０が読み取られた場合が、決済サービスが提供される場合に相当する。確認判定部４０１は、任意の方法によって判定処理を実行可能である。第１実施形態では、決済アプリが出力した情報が確認判定部４０１の判定処理で利用される場合を説明する。

例えば、決済アプリは、学生証が学生証アプリで確認された場合に、学生証が学生証アプリで確認済みであることを示す確認済み情報を出力する。確認済み情報は、任意の形式であってよい。例えば、確認済み情報は、文字、数字、その他の記号、又はこれらの組み合わせである。図４の例では、コード画像Ｃ１０に含まれるコードＩＤの冒頭の「１１１１」の数字が確認済み情報に相当する。学生証が学生証アプリで確認された場合にのみ、この数字がコードＩＤに含まれる。学生証が学生証アプリで確認されない場合には、コードＩＤの冒頭は、他の数字になる。当該他の数字は、学生証が学生証アプリで確認されていないことを示す数字であってもよい。

例えば、第１サーバ１０は、あるユーザのユーザ端末３０から所定の発行要求を受信した場合、このユーザの学生番号が学生証アプリで確認されていれば、確認済み情報を含むコードＩＤを発行する。第１サーバ１０は、このユーザの学生番号が学生証アプリで確認されていなければ、確認済み情報を含まないコードＩＤを発行する。第１サーバ１０は、ユーザ端末３０に、当該発行されたコードＩＤを送信する。なお、確認済み情報は、決済アプリ側でコードＩＤに付与されてもよい。この場合、決済アプリは、第１サーバ１０から受信したコードＩＤの一部を確認済み情報に差し替えたり、第１サーバ１０から受信したコードＩＤに確認済み情報を付加したりすればよい。

例えば、確認判定部４０１は、決済アプリにより出力された確認済み情報に基づいて、学生証が決済アプリで確認済みであるか否かを判定する。確認判定部４０１は、店舗端末４０の読取部４６によりコード画像Ｃ１０が読み取られた場合に、コード画像Ｃ１０から取得したコードＩＤに確認済み情報が含まれているか否かを判定する。確認判定部４０１は、コードＩＤに確認済み情報が含まれていない場合には、学生証が学生証アプリで確認済みであると判定しない。確認判定部４０１は、コードＩＤに確認済み情報が含まれている場合に、学生証が学生証アプリで確認済みであると判定する。

図４の例では、確認判定部４０１は、コードＩＤの冒頭の数字が「１１１１」であるか否かを判定する。確認判定部４０１は、コードＩＤの冒頭の数字が「１１１１」でない場合には、学生証が学生証アプリで確認済みであると判定しない。確認判定部４０１は、コードＩＤの冒頭の数字が「１１１１」である場合には、学生証が学生証アプリで確認済みであると判定する。確認済み情報は、「１１１１」に限られず、任意の値であってよい。コードＩＤにおける確認済み情報の位置も、冒頭に限られず、任意の位置であってよい。

なお、確認済み情報は、コードＩＤの一部に含まれるのではなく、コードＩＤとは別の情報であってもよい。この場合、学生証が学生証アプリで確認されていれば、コード画像Ｃ１０は、コードＩＤと、確認済み情報と、を含む。学生証が学生証アプリで確認されていなければ、コード画像Ｃ１０は、コードＩＤを含むが確認済み情報を含まない。この場合、コード画像Ｃ１０は、学生証が学生証アプリで確認されていないことを示す情報を含んでもよい。

また、決済アプリは、コード画像Ｃ１０とは別のコード画像を利用して、確認済み情報を出力してもよい。更に、決済アプリによる確認済み情報の出力方法は、任意の方法であってよく、画像を利用した方法に限られない。例えば、決済アプリは、音声又はデータ通信によって、確認済み情報を出力してもよい。この場合、確認判定部４０１は、音声又はデータ通信によって確認済み情報が出力されたか否かを判定することによって、学生証が学生証アプリで確認されたか否かを判定してもよい。

［処理実行部］
処理実行部４０２は、学生証が決済アプリで確認済みであると判定された場合に、決済サービスに関する特定の処理を実行する。特定の処理は、学生証が決済アプリで確認済みであると判定されたことを条件として実行される処理である。処理実行部４０２は、学生証が決済アプリで確認済みであると判定されない場合には、特定の処理を実行しない。特定の処理は、ユーザの利便性を高める処理である。例えば、特定の機能は、ユーザの金銭的な負担を減らす処理、ユーザに特典を付与する処理、又はユーザの操作を簡略化する処理である。特定の処理は、決済サービスに関する特定の機能ということもできる。即ち、処理実行部４０２は、学生証が決済アプリで確認済みであると判定された場合に、ユーザに特定の機能を提供する。

第１実施形態では、決済サービス提供部は、特定の処理として、決済サービスにおいて割引を適用する割引処理を実行する。割引処理は、特定の処理の一例である。このため、割引処理について説明している箇所は、特定の処理と読み替えることができる。割引処理は、ユーザが支払う金額を減らす処理である。割引処理は、ユーザが購入する商品の価格を下げる処理である。割引処理は、ユーザが利用するレストラン等の施設の料金を下げる処理である。割引処理による割引後の価格は、データ記憶部４００に予め記憶されているものとするが、その場で動的に決定されてもよい。

［１－４．第１実施形態で実行される処理］
図８及び図９は、第１実施形態で実行される処理の一例を示すフロー図である。この処理は、制御部１１，２１，３１，４１がそれぞれ記憶部１２，２２，３２，４２に記憶されたプログラムに従って動作することによって実行される。

図８のように、ユーザ端末３０は、決済アプリが起動して所定のログイン処理が実行されると、学生証が学生証アプリで確認済みか否かを判定する（Ｓ１００）。Ｓ１００では、ユーザ端末３０は、学生証が学生証アプリで確認済みであることを示す情報が記憶部３２に記憶されているか否かを判定する。学生証が学生証アプリで確認済みであると判定されない場合（Ｓ１００；Ｎ）、第１サーバ１０に、確認済み情報を含まないコードＩＤの発行要求を送信する（Ｓ１０１）。第１サーバ１０は、発行要求を受信すると、確認済み情報を含まないコードＩＤを発行してユーザ端末３０に送信する（Ｓ１０２）。ユーザ端末３０は、確認済み情報を含まないコードＩＤを受信すると、このコードＩＤを含むコード画像Ｃ１０をトップ画面Ｇ１に表示させる（Ｓ１０３）。

ユーザ端末３０は、ユーザがリンクＬ１２を選択すると、選択画面Ｇ３を表示部３５に表示させる（Ｓ１０４）。ユーザ端末３０は、ユーザが選択画面Ｇ３から学生証アプリを選択すると、登録画面Ｇ４を表示部３５に表示させる（Ｓ１０５）。ユーザ端末３０は、通信部３３のＮＦＣ機能を利用して学生証をスキャンし（Ｓ１０６）、第２サーバ２０に、学生証から読み取った学生番号等の情報を送信する（Ｓ１０７）。第２サーバ２０は、学生番号等の情報を受信すると、その正当性を確認する（Ｓ１０８）。学生番号等の情報の正当性が確認されると、デジタル学生証サービスの利用を開始するための処理が実行され、ユーザ端末３０は、学生証を学生証アプリに登録する（Ｓ１０９）。

一方、Ｓ１００において、学生証が学生証アプリで確認済みであると判定された場合（Ｓ１００；Ｙ）、第１サーバ１０に、確認済み情報を含むコードＩＤの発行要求を送信する（Ｓ１１０）。第１サーバ１０は、発行要求を受信すると、確認済み情報を含むコードＩＤを発行してユーザ端末３０に送信する（Ｓ１１１）。ユーザ端末３０は、確認済み情報を含むコードＩＤを受信すると、このコード画像Ｃ１０をトップ画面Ｇ１に表示させる（Ｓ１１２）。

店舗端末４０は、Ｓ１０３又はＳ１１２で表示されたコード画像Ｃ１０を読み取る（Ｓ１１３）。店舗端末４０は、コード画像Ｃ１０から読み取ったコードＩＤに確認済み情報が含まれているか否かを判定する（Ｓ１１４）。確認済み情報が含まれていると判定された場合（Ｓ１１４；Ｙ）、店舗端末４０は、第１サーバ１０に、割引を適用した利用額に基づいて、決済要求を送信する（Ｓ１１５）。確認済み情報が含まれていると判定されない場合（Ｓ１１５；Ｙ）、店舗端末４０は、第１サーバ１０に、割引を適用しない利用額に基づいて、決済要求を送信する（Ｓ１１６）。第１サーバ１０は、決済要求を受信すると、決済処理を実行し（Ｓ１１７）、本処理は終了する。

第１実施形態のサービス提供システムＳによれば、学生証が学生証アプリで確認されたと判定された場合に、決済サービスに関する特定の処理を実行する。この特定の処理は、ユーザの利便性を高める処理なので、決済アプリ及び学生証アプリを利用するユーザの利便性が高まる。例えば、ユーザが学生証を提示しなくても通常の決済サービスと同じ流れで学割を適用することができるので、ユーザの利便性が高まる。店舗から見ても、学生証の確認作業を省略できるので、店舗の利便性も高まる。

また、サービス提供システムＳは、決済サービスにおいて割引を適用する割引処理を実行する。これにより、ユーザが割引価格で支払いを済ませられるので、決済サービスにおけるユーザの利便性が高まる。例えば、ユーザが学生証を店員に見せるのを忘れて通常価格になっていることに気付かないといったことを防止し、確実に割引価格を適用できる。

また、サービス提供システムＳは、学生証が学生証アプリで確認された場合に、学生証が学生証アプリで確認済みであることを示す確認済み情報を出力する。決済アプリにより出力された確認済み情報に基づいて、学生証が学生証アプリで確認済みであるか否かが判定される。これにより、学生証が確認済みであるか否かを確実に判定できる。例えば、決済アプリから決済サービスを利用する通常の流れと同じ流れで、学生証が学生証アプリで確認済みであるか否かを判定することができるので、ユーザに特別な操作をさせる必要がなく、ユーザの利便性が高まる。

また、サービス提供システムＳは、第１サービスが決済サービスであり、第２サービスが学校に関するデジタル学生証サービスであり、メンバーシップ情報が学校への所属を証明する学生証である。これにより、決済サービスとデジタル学生証サービスを効果的に連携させることができる。例えば、ユーザの学校で学生証アプリの利用が推奨されている場合には、ユーザが決済アプリを利用していなかったとしても、決済アプリをユーザ端末３０にインストールすれば便利に利用できるので、ユーザ端末３０に決済アプリをインストールする動機付けをユーザに与えることができる。このため、決済サービスの利用を促進できる。

また、サービス提供システムＳは、決済アプリがスーパーアプリであり、学生証アプリがスーパーアプリから利用可能なミニアプリである。これにより、スーパーアプリとミニアプリを効果的に連携させることができる。決済アプリと学生証アプリが別々のアプリである場合に比べて、アプリ同士の連携をしやすくなる。ユーザは、スーパーアプリである決済アプリから、学生証アプリ等のミニアプリを管理できるので、ユーザ端末３０のアプリを管理しやすくなる。

［２．第２実施形態］
第１実施形態では、ユーザが選択画面Ｇ３から学生証アプリを選択することによって、学生証アプリの利用を開始する場合を説明したが、ユーザは、自身の学校が学生証アプリに対応していることを知らなければ、学生証アプリを利用できることに気付かない可能性がある。この点、決済アプリは、ユーザ情報に基づいて、学生証アプリに対応している学校にユーザが通っていることを特定できることがある。そこで、第２実施形態では、決済アプリは、学生証アプリに対応している学校にユーザが通っていることを特定した場合には、学生証アプリの利用開始を促すようにする。

図１０は、第２実施形態における決済アプリの画面の一例を示す図である。図１０のように、ユーザがトップ画面Ｇ１から所定の操作をすると、ユーザ情報を登録するための設定画面Ｇ７が表示部３５に表示される。ユーザは、設定画面Ｇ７から新たにユーザ情報を登録したり、登録済みのユーザ情報を変更したりすることができる。例えば、ユーザが設定画面Ｇ７からユーザの組織として通学先の学校を登録すると、決済アプリは、この学校が学生証アプリに対応しているか否かを判定する。

決済アプリは、ユーザの学校が学生証アプリに対応していると判定された場合に、学生証アプリの利用開始を促すための通知画像Ｉ１３を、トップ画面Ｇ１に表示する。例えば、ユーザが通知画像Ｉ１３を選択すると、学生証アプリがユーザ端末３０にダウンロード及びインストールされる。その後、第１実施形態で説明した登録画面Ｇ４が表示部３５に表示される。ユーザが学生証をスキャンして学生証アプリに登録する流れは、第１実施形態と同様である。

以上のように、第２実施形態のサービス提供システムＳは、ユーザの学校が学生証アプリに対応していることが検知されると、学生証アプリの利用開始を促す通知画像Ｉ１３がトップ画面Ｇ１に表示される。これにより、ユーザが学生証アプリを利用可能なことに気付きやすくなるので、ユーザの利便性が高まるようになっている。以降、第２実施形態の詳細を説明する。第２実施形態では、第１実施形態と同様の点は省略する。

［２－１．第２実施形態で実現される機能］
図１１は、第２実施形態で実現される機能の一例を示す図である。図１１のように、第２実施形態では、第１サーバ１０でユーザ情報取得部１０２及び表示判定部１０３が実現される。これらの機能は、制御部１１を主として実現される。図１１の他の機能は、第１実施形態と同様であってよい。

［ユーザ情報取得部］
ユーザ情報取得部１０２は、ユーザに関するユーザ情報を取得する。第２実施形態では、ユーザ情報が第１データベースＤＢ１に格納されているので、ユーザ情報取得部１０２は、第１データベースＤＢ１からユーザ情報を取得する。第１サーバ以外の他のコンピュータ又は他の情報記憶媒体にユーザ情報が格納されている場合には、ユーザ情報取得部１０２は、他のコンピュータ又は他の情報記憶媒体からユーザ情報を取得する。第１実施形態で説明したように、ユーザ端末３０で決済アプリが起動した場合に、所定のログイン処理が実行される。ユーザ情報取得部１０２は、決済サービスにログインしたユーザのユーザ情報を取得する。

［表示判定部］
表示判定部１０３は、ユーザ情報に基づいて、通知画像Ｉ１３を決済アプリ上で表示させるか否かを判定する。通知画像Ｉ１３は、第２アプリ情報の一例である。このため、通知画像Ｉ１３と記載した箇所は、第２アプリ情報と読み替えることができる。第２アプリ情報は、第２アプリに関する情報である。例えば、第２アプリ情報は、第２アプリの名前、第２アプリの利用を開始することを促すメッセージ、第２アプリの起動を促すメッセージ、第２アプリをダウンロードするためのページのリンク、第２アプリのアイコン、又はこれらの組み合わせである。

第２実施形態では、表示判定部１０３は、ユーザが学生証アプリを利用していない場合に、学生証アプリの利用を開始することを促す通知画像Ｉ１３を、第２アプリ情報として決済アプリ上で表示させるか否かを判定する。通知画像Ｉ１３は、開始情報の一例でもある。このため、通知画像Ｉ１３と記載した箇所は、開始情報と読み替えることができる。開始情報は、学生証アプリの利用を開始することを促すメッセージ、学生証アプリの利用を開始することを促すアイコン、又は学生証アプリのバナーであってもよい。

通知画像Ｉ１３を決済アプリ上で表示させるとは、決済アプリの画面を利用して通知画像Ｉ１３を表示させることである。第２実施形態では、トップ画面Ｇ１に通知画像Ｉ１３を表示させることが通知画像Ｉ１３を決済アプリ上で表示させることに相当する。第２アプリ情報は、決済アプリの何らかの画面に表示されるようにすればよく、例えば、決済完了画面Ｇ２又は選択画面Ｇ３に通知画像Ｉ１３が表示されてもよいし、他の画面に通知画像Ｉ１３が表示されてもよい。例えば、決済アプリ内の通知機能を利用して、通知画像Ｉ１３が表示されてもよい。

表示判定部１０３は、ユーザ情報に基づいて、所定の表示条件が満たされたか否かを判定する。例えば、表示判定部１０３は、表示条件が満たされない場合に、通知画像Ｉ１３を決済アプリ上で表示させないと判定する。表示判定部１０３は、表示条件が満たされる場合に、通知画像Ｉ１３を決済アプリ上で表示させると判定する。表示条件の設定次第では、表示判定部１０３は、表示条件が満たされない場合に、通知画像Ｉ１３を決済アプリ上で表示させると判定してもよい。表示判定部１０３は、表示条件が満たされる場合に、通知画像Ｉ１３を決済アプリ上で表示させないと判定してもよい。

表示条件は、通知画像Ｉ１３を表示するか否かの判定基準となる条件である。表示条件は、任意の条件であってよく、例えば、下記に説明するような場所又は組織に関する条件であってもよいし、他の条件であってもよい。他の条件としては、ユーザの年齢又は学年が所定の年齢又は学年であるか否か、又は決済サービスの利用履歴が所定の履歴であるか否かである。表示条件は、ユーザ情報に基づいて判定可能な条件であればよい。表示条件は、ユーザ情報に関係のない条件を含んでもよい。例えば、表示条件は、現在の時間帯が所定の時間帯であるか否か、又は、現在の日付が所定の期間であるか否かといった条件を含んでもよい。

例えば、デジタル学生証サービスは、所定の場所に関するサービスなので、表示判定部１０３は、ユーザ情報に基づいて、ユーザが当該場所に関係あるか否かを判定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定してもよい。表示判定部１０３は、ユーザが所定の場所に関係ない場合に、決済アプリ上で通知画像Ｉ１３を表示させると判定しない。表示判定部１０３は、ユーザが所定の場所に関係ある場合に、決済アプリ上で通知画像Ｉ１３を表示させると判定する。

所定の場所とは、第２サービスに関係する場所である。第２実施形態の学生証アプリであれば、ユーザの学校生活を支援するサービスなので、学校がある場所又はその付近の場所は、所定の場所に相当する。例えば、ある場所でのみ第２サービスを利用できる場合には、第２サービスを利用可能な場所が所定の場所に相当してもよい。例えば、ある場所で第２サービスが提供される場合には、第２サービスが提供される場所が所定の場所に相当してもよい。

所定の場所を識別可能な情報は、データ記憶部１００に記憶されているものとする。第２実施形態では、学生証アプリに対応している学校又はその場所がデータ記憶部１００に記憶されている。例えば、表示判定部１０３は、ユーザ情報に含まれる通学先の学校が、学生証アプリに対応している学校であるか否かを判定する。例えば、表示判定部１０３は、ユーザ情報に含まれるユーザの住所が、学生証アプリに対応している学校又はその付近であるか否かを判定してもよい。

例えば、デジタル学生証サービスは、所定の組織に関するサービスなので、表示判定部１０３は、ユーザ情報に基づいて、ユーザが当該組織に関係あるか否かを判定することによって、決済アプリ上で学生証アプリ情報を表示させるか否かを判定する。表示判定部１０３は、ユーザが所定の組織に関係ない場合に、決済アプリ上で通知画像Ｉ１３を表示させると判定しない。表示判定部１０３は、ユーザが所定の組織に関係ある場合に、決済アプリ上で通知画像Ｉ１３を表示させると判定する。

所定の組織とは、第２サービスに関係する組織である。第２実施形態のように、学生証アプリであれば、ユーザの学校生活を支援するサービスなので、学校は、所定の組織に相当する。例えば、ある組織に所属する者のみが第２サービスを利用できる場合には、第２サービスを利用可能な組織が所定の組織に相当してもよい。例えば、ある組織が第２サービスを提供する場合には、第２サービスを提供する組織が所定の組織に相当してもよい。

所定の組織を識別可能な情報は、データ記憶部１００に記憶されているものとする。第２実施形態では、学生証アプリに対応している学校がデータ記憶部１００に記憶されている。例えば、表示判定部１０３は、ユーザ情報に含まれる通学先の学校が、学生証アプリに対応している学校であるか否かを判定する。学生証アプリに対応している学校とは、デジタル学生証サービスを導入している学校である。この学校は、大学、高校、中学校、小学校、又は専門学校といった任意の学校であってよい。

［表示制御部］
表示制御部３０１は、表示判定部１０３の判定結果に基づいて、決済アプリ上で通知画像Ｉ１３を表示させる。通知画像Ｉ１３は、第２アプリ情報及び開始情報の一例なので、表示制御部３０１は、表示判定部１０３の判定結果に基づいて、決済アプリ上で通知画像Ｉ１３を、第２アプリ情報及び開始情報として表示させる。表示制御部３０１は、表示判定部１０３により通知画像Ｉ１３を表示させると判定されない場合には、決済アプリ上で通知画像Ｉ１３を表示させない。表示制御部３０１は、表示判定部１０３により通知画像Ｉ１３を表示させると判定された場合に、決済アプリ上で通知画像Ｉ１３を表示させる。

［２－２．第２実施形態で実現される処理］
図１２は、第２実施形態で実行される処理の一例を示すフロー図である。この処理は、制御部１１，３１がそれぞれ記憶部１２，３２に記憶されたプログラムに従って動作することによって実行される。

図１２のように、第１サーバ１０は、決済アプリが起動して所定のログイン処理が実行されると、決済サービスにログインしたユーザのユーザ情報に基づいて、通知画像Ｉ１３を決済アプリ上で表示させるか否かを判定する（Ｓ２００）。Ｓ２００では、第１サーバ１０は、ユーザ情報に含まれるユーザの組織に基づいて、学生証アプリに対応している学校に通っているか否かを判定する。

通知画像Ｉ１３を決済アプリ上で表示させると判定された場合（Ｓ２００；Ｙ）、第１サーバ１０は、ユーザ端末３０に、通知画像Ｉ１３を含むトップ画面Ｇ１を表示させるためのデータを送信する（Ｓ２０１）。ユーザ端末３０は、データを受信すると、通知画像Ｉ１３を含むトップ画面Ｇ１を表示部３５に表示させ（Ｓ２０２）、本処理は終了する。以降、ユーザが通知画像Ｉ１３を選択すると、学生証アプリに学生証を登録するための処理が実行される。

通知画像Ｉ１３を決済アプリ上で表示させると判定されない場合（Ｓ２００；Ｎ）、第１サーバ１０は、ユーザ端末３０に、通知画像Ｉ１３を含まないトップ画面Ｇ１を表示させるためのデータを送信する（Ｓ２０３）。ユーザ端末３０は、データを受信すると、通知画像Ｉ１３を含まないトップ画面Ｇ１を表示部３５に表示させ（Ｓ２０４）、本処理は終了する。この場合、ユーザがリンクＬ１２を選択すれば、学生証アプリに学生証を登録するための処理が実行される。

第２実施形態のサービス提供システムＳによれば、ユーザ情報に基づいて、通知画像Ｉ１３を決済アプリ上で表示させるか否かを判定し、この判定結果に基づいて、決済アプリ上で通知画像Ｉ１３を表示させる。これにより、通知画像Ｉ１３を表示させた方がよいユーザのユーザ端末３０に通知画像Ｉ１３を表示させることができるので、ユーザの利便性が高まる。また、通知画像Ｉ１３を表示させることによって、学生証アプリの利用を促進できる。通知画像Ｉ１３を表示させる必要がないユーザのユーザ端末３０には通知画像Ｉ１３が表示されず、不必要な情報が表示されることがなくなるので、この点でもユーザの利便性が高まる。

また、サービス提供システムＳは、ユーザ情報に基づいて、ユーザが所定の場所に関係あるか否かを判定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。これにより、所定の場所に関係のあるユーザの利便性が高まる。所定の場所に関係のある学生証アプリの利用を促進できる。

また、サービス提供システムＳは、ユーザ情報に基づいて、ユーザが所定の組織に関係あるか否かを判定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。これにより、所定の組織に関係のあるユーザの利便性が高まる。所定の組織に関係のある学生証アプリの利用を促進できる。

また、サービス提供システムＳは、ユーザが学生証アプリを利用していない場合に、学生証アプリの利用を開始することを促す通知画像Ｉ１３を、学生証アプリ情報として決済アプリ上で表示させるか否かを判定し、この判定結果に基づいて、決済アプリ上で通知画像Ｉ１３を表示させる。これにより、学生証アプリの利用を促進できる。

また、サービス提供システムＳは、第１サービスが決済サービスであり、第２サービスが学校に関するデジタル学生証サービスである。これにより、決済サービスとデジタル学生証サービスを効果的に連携させることができる。決済アプリを利用して学生証アプリの利用も促進できる。

また、サービス提供システムＳは、決済アプリがスーパーアプリであり、学生証アプリがスーパーアプリから利用可能なミニアプリである。これにより、スーパーアプリとミニアプリを効果的に連携させることができる。決済アプリと学生証アプリが別々のアプリである場合に比べて、アプリ同士の連携をしやすくなる。ユーザは、スーパーアプリである決済アプリから、学生証アプリ等のミニアプリを管理できるので、ユーザ端末３０のアプリを管理しやすくなる。また、通常のアプリをインストールする場合に比べて、スーパーアプリからミニアプリの利用を開始するための操作は手間がかからないので、学生証の利用を開始するためのユーザの手間を軽減することもできる。

［３．変形例］
なお、本開示は、以上に説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

［３－１．第１実施形態に係る変形例］
まず、第１実施形態に係る変形例を説明する。図１３は、第１実施形態に係る変形例における機能ブロック図の一例である。制限部１０４及び関連付け部１０５は、制御部１１を主として実現される。一致判定部３０３及び処理実行部３０４は、制御部３１を主として実現される。条件判定部４０３及び表示制御部４０４は、制御部４１を主として実現される。

［変形例１－１］
例えば、割引処理を実行するか否かの条件となるのは、学生証を学生証アプリに登録することだけではなく、他の条件が存在してもよい。第１実施形態では、特定の処理の一例として割引処理を説明したが、変形例１－１では、特定の処理の一例として、ユーザに所定の特典を付与する付与処理を説明する。第１実施形態で説明したように、特定の処理は、任意の処理であってよく、割引処理又は付与処理に限られない。

特典は、ユーザに与えられる利益である。特典は、電子的なものであってもよいし、物理的なものであってもよい。特典は、ギフトと呼ばれることもある。変形例１－１では、決済サービスに関する特典を例に挙げるが、特典は、決済サービスに関係のないものであってもよい。例えば、電子商取引サービス又は保険サービスといった他のサービスで利用可能なクーポンを付与すること、又は、動画又は楽曲といったコンテンツを視聴可能にすることが特典に相当してもよい。

決済サービスに関する特典は、決済サービスで利用可能な決済手段を新たに付与すること、又は、決済サービスで利用可能な決済手段の残高を増やすことである。例えば、特典は、電子マネー、ポイント、又はクーポンを付与することである。付与処理自体は、種々の処理を利用可能であり、例えば、ユーザの電子マネー又はポイントの残高を増やす処理、ユーザにクーポンを獲得させる処理、又は即時に特典を付与するのではなく、ユーザが受け取り操作をした場合に受け取れる特典として登録する処理であってよい。物理的なものを特典として付与する場合には、ユーザが指定した住所に特典を配送する処理が付与処理に相当すればよい。

変形例１－１のサービス提供システムＳは、デジタル学生証サービスに関連付けられた所定の条件をユーザが満たすか否かを判定する条件判定部４０３を含む。この条件は、付与処理を実行するか否かの基準となる条件である。この条件は、デジタル学生証サービスに関する任意の条件を設定可能である。例えば、デジタル学生証サービスの利用状況が所定の状況になること、デジタル学生証サービスを継続した利用した期間が所定の期間になること、又はデジタル学生証サービスが提供する特定の機能を利用したことが所定の条件に相当してもよい。

変形例１－１では、第２データベースＤＢ２に格納された利用状況情報が所定の状況になることが所定の条件に相当する場合を説明する。条件判定部４０３は、第２データベースＤＢ２に格納された利用状況情報に基づいて、ユーザが所定の条件を満たすか否かを判定する。例えば、条件判定部４０３は、第２データベースＤＢ２に格納された利用状況情報が示す利用状況が所定の状況であるか否かを判定することによって、所定の条件を満たすか否かを判定する。利用状況が所定の状況であることは、所定の条件を満たすことに相当する。

なお、変形例１－１では、条件判定部４０３が店舗端末４０により実現される場合を説明するので、条件判定部４０３は、あるユーザが表示させたコード画像Ｃ１０が店舗端末４０で読み取られた場合に、このユーザの利用状況情報を第２サーバ２０から取得する。第２データベースＤＢ２では、利用状況情報は、学生番号に関連付けられているので、変形例１－１では、コード画像Ｃ１０に学生番号が含まれているものとする。条件判定部４０３は、コード画像Ｃ１０に含まれる学生番号に基づいて、利用状況情報を取得する。

例えば、所定の状況は、授業に所定回数以上出席することであってもよい。この場合、条件判定部４０３は、利用状況情報が示す授業への出欠状況に基づいて、ユーザが授業に所定回数以上出席したか否かを判定する。例えば、所定の状況は、図書館等の施設にチェックインすることであってもよい。この場合、条件判定部４０３は、利用状況情報が示すチェックイン状況に基づいて、ユーザが施設にチェックインしたか否かを判定する。例えば、所定の状況は、所定数の単位を取得することであってもよい。この場合、条件判定部４０３は、利用状況情報が示す単位の取得状況に基づいて、ユーザが所定数の単位を取得した買い安価を判定する。所定の状況が他の状況の場合には、条件判定部４０３は、利用状況情報に基づいて、所定の状況として定められた他の状況になったか否かを判定すればよい。

処理実行部４０２は、学生証が学生証アプリで確認済みであると判定され、かつ、ユーザが条件を満たすと判定された場合に、付与処理を実行する。処理実行部４０２は、学生証が学生証アプリで確認済みであることと、ユーザが所定の条件を満たすと判定されることと、の２つが成立した場合に、付与処理を実行する。これらの何れか又は両方が成立しない場合には、付与処理は実行されない。

変形例１－１によれば、学生証が学生証アプリで確認済みであると判定され、かつ、ユーザが所定の条件を満たすと判定された場合に、付与処理を実行する。これにより、デジタル学生証サービスに関連付けられた所定の条件をユーザが満たすことによって、付与処理をはじめとする特定の処理が実行されるので、デジタル学生証サービスを利用する動機付けをユーザに与えることができる。例えば、授業に所定回数以上出席することを所定の条件にしたり、所定数の単位を取得することを所定の条件にしたりすることによって、ユーザの学校生活のモチベーションを適切に高めることもできる。

［変形例１－２］
例えば、変形例１－１で説明した所定の条件は、デジタル学生証サービスに関連付けられた所定の課題をユーザが達成することであってもよい。課題とは、デジタル学生証サービスに関する課題である。例えば、デジタル学生証サービスへのログイン頻度を所定の頻度にすること、デジタル学生証サービスの継続利用期間を所定の期間にすること、又はデジタル学生証サービスの所定の機能を利用することが課題に相当してもよい。変形例１－２でも、変形例１－１と同様、所定の課題の達成有無は、利用状況情報に基づいて判定される場合を説明する。

条件判定部４０３は、ユーザが所定の課題を達成したか否かを判定することによって、ユーザが条件を満たすか否かを判定する。例えば、条件判定部４０３は、第２データベースＤＢ２に格納された利用状況情報に基づいて、ユーザが所定の課題を達成したか否かを判定する。ログイン頻度を所定の頻度にするといった課題であれば、条件判定部４０３は、ユーザの利用状況情報に基づいて、ユーザのログイン頻度が所定の頻度であるか否かを判定する。継続利用期間を所定の期間にするといった課題であれば、条件判定部４０３は、ユーザの利用状況情報に基づいて、ユーザの継続利用期間が所定の期間であるか否かを判定する。所定の機能を利用するといった課題であれば、条件判定部４０３は、ユーザの利用状況情報に基づいて、ユーザが所定の機能を利用したか否かを判定する。

処理実行部４０２は、学生証が学生証アプリで確認済みであると判定され、かつ、ユーザが所定の課題を達成したと判定された場合に、付与処理を実行する。処理実行部４０２は、学生証が学生証アプリで確認済みであることと、ユーザが所定の課題を達成したと判定されることと、の２つが成立した場合に、付与処理を実行する。これらの何れか又は両方が成立しない場合には、付与処理は実行されない。

変形例１－２によれば、学生証が学生証アプリで確認済みであると判定され、かつ、ユーザが課題を達成したと判定された場合に、付与処理を実行する。これにより、デジタル学生証サービスに関連付けられた所定の課題をユーザが達成することによって、付与処理をはじめとする特定の処理が実行されるので、デジタル学生証サービスを利用する動機付けをユーザに与えることができる。例えば、所定の課題を学校生活に関する課題にすることによって、ユーザの学校生活のモチベーションを適切に高めることもできる。

［変形例１－３］
例えば、変形例１－２で説明した所定の課題は、ユーザが組織で所定の成績を収めることであってもよい。組織が学校である場合には、成績は、学校における成績であり、例えば、テスト、ゼミ、又はレポートの点数である。成績は、資格試験等の学校のテスト以外の成績でもよい。成績は、組織に応じた内容であればよく、例えば、組織が会社である場合には、契約件数又は売上といった成績であってもよい。例えば、組織がスポーツクラブであれば、大会の成績であってもよい。変形例１－３では、第１実施形態と同様に、学校の成績を例に挙げるが、成績は、組織に応じたものであればよい。

条件判定部４０３は、ユーザが所定の成績を収めたか否かを判定することによって、ユーザが所定の課題を達成したか否かを判定する。ユーザの成績は、第２データベースＤＢ２に格納されていてもよいし、他のデータベースに格納されていてもよい。条件判定部４０３は、これらの何れかのデータベースに格納されたユーザの成績に基づいて、ユーザが所定の成績を収めたか否かを判定する。ユーザの成績は、学生番号に関連付けられている第２データベースＤＢ２又は他のデータベースに格納されているものとする。条件判定部４０３は、コード画像Ｃ１０に含まれる学生番号に関連付けられた成績を取得して、ユーザが所定の課題を達成したか否かを判定すればよい。

処理実行部４０２は、学生証が学生証アプリで確認済みであると判定され、かつ、ユーザが所定の成績を収めたと判定された場合に、付与処理を実行する。処理実行部４０２は、学生証が学生証アプリで確認済みであることと、ユーザが所定の成績を収めたと判定されることと、の２つが成立した場合に、付与処理を実行する。これらの何れか又は両方が成立しない場合には、付与処理は実行されない。

変形例１－３によれば、学生証が学生証アプリで確認済みであると判定され、かつ、ユーザが所定の成績を収めたと判定された場合に、付与処理を実行する。これにより、ユーザが所定の成績を収めることによって、付与処理をはじめとする特定の処理が実行されるので、デジタル学生証サービスを利用する動機付けをユーザに与えることができる。例えば、ユーザの学校生活のモチベーションを適切に高めることもできる。

［変形例１－４］
例えば、処理実行部４０２が実行する特定の処理として、割引処理及び付与処理を説明したが、処理実行部４０２は、特定の処理として、決済サービスにおける利用額をユーザと他の者とで分担する分担処理を実行してもよい。他の者は、ユーザ以外の者であればよく、例えば、ユーザの通学先の学校、ユーザの勤務先の会社、又はユーザの家族であってもよい。分担処理は、ユーザが支払う額を減らし、かつ、当該減った額を他の者に支払わせる処理である。他の者には、複数回の分担処理の合計額がまとめて請求されてもよいし、個々の分担処理で分担すべき額がその都度請求されてもよい。

変形例１－４では、コード画像Ｃ１０に、ユーザの学校を識別可能な情報が含まれているものとする。このため、店舗端末４０は、コード画像Ｃ１０を読み取った場合に、ユーザがどの学校に所属しているかを特定できる。店舗端末４０がユーザの学校を特定すると、処理実行部４０２は、本来の利用額の一部だけをユーザが支払い、かつ、当該特定された学校が残りの額を支払うように、分担処理を実行する。

例えば、処理実行部４０２は、本来の利用額の一部だけをユーザが支払うように、第１サーバ１０に第１決済要求を送信する。処理実行部４０２は、残りの額を他の者が支払うように、第１サーバ１０に第２決済要求を送信する。第１データベースＤＢ１には、他の者の決済情報が登録されているものとする。第１提供部１０１は、第１決済要求に基づいて、ユーザの決済情報に基づいて、本来の利用額の一部だけをユーザが支払うように、第１決済処理を実行する。第１提供部１０１は、第２決済要求に基づいて、他の者の決済情報に基づいて、残りの額を他の者が支払うように、第２決済処理を実行する。第１決済処理は、即時に実行され、第２決済処理は、後日に実行されてもよい。

なお、処理実行部４０２が上記のように２つの決済要求を送信するのではなく、決済要求としては１つであるが、第１決済処理及び第２決済処理を実行するか否かが第１サーバ１０により判定されてもよい。例えば、分担処理の対象となることを識別可能な情報を決済要求に含めておき、第１サーバ１０は、この情報に基づいて、分担処理を実行するか否かを判定してもよい。第１サーバ１０は、分担処理を実行すると判定した場合、第１決済処理及び第２決済処理を実行する。

ユーザの負担額と、他の者の負担額と、は決済要求に含まれていてもよいし、第１サーバ１０により決定されてもよい。例えば、第１サーバ１０は、所定の比率で分担するように、各自の負担額を決定してもよい。この比率は、データ記憶部１００に予め記憶されているものとする。他にも例えば、第１サーバ１０は、他の者が所定の額を分担するように、各自の負担額を決定してもよい。この所定の額は、データ記憶部１００に予め記憶されているものとする。なお、分担処理は、学校の売店又は食堂といった特定の店舗でのみ実行されてもよい。

変形例１－４によれば、決済サービスにおける利用額をユーザと他の者とで分担する分担処理を実行する。これにより、ユーザがより少ない額で支払いを済ませられるので、決済サービスにおけるユーザの利便性が高まる。例えば、学校が学生に対して学校の売店又は食堂等でキャンペーンを行う場合に、ユーザによるキャンペーンの利用を促進させることができる。第２アプリがユーザの会社の福利厚生を提供するアプリである場合には、会社の福利厚生の一環として、ユーザが食事した時に分担処理を実行することによって、食事代の補助を手軽に実現できる。

［変形例１－５］
例えば、ユーザがたばこ又は酒類等といった特定の商品を購入する場合に、決済サービスでは、ユーザの本人確認又は年齢確認が要求されることがある。他にも例えば、ユーザが所定額以上の商品を購入する場合に、決済サービスでは、ユーザの本人確認又は年齢確認が要求されることがある。この場合に、処理実行部４０２は、特定の処理として、本人確認又は年齢確認を省略する省略処理を実行してもよい。

省略処理は、ユーザの本人確認又は年齢確認が完了したとみなす処理である。省略処理が実行されると、通常の本人確認又は年齢確認における手続きをしなくても、本人確認又は年齢確認が行われたとみなされる。この手続き自体は、公知の種々の手続きであってよく、例えば、店舗端末４０に表示された確認ボタンを押すこと、店員に対して学生書等の身分証明書を提示すること、又は本人確認又は年齢確認が可能なＩＣカードをカードリーダにかざす行為である。省略処理は、これらの手続きがなくても、特定の商品の購入等を許可する処理である。例えば、省略処理は、本人確認又は年齢確認が不要であることを店舗端末４０の表示部４５に表示させる処理であってもよい。

変形例１－５では、ユーザが店舗でコード画像Ｃ１０を提示して酒類を購入する場合を例に挙げる。更に、ユーザが大学生であり、かつ、酒類を購入可能な年齢であるものとする。例えば、確認判定部４０１は、学生証が学生証アプリで確認され、かつ、ユーザが酒類を購入可能な年齢であるか否かを判定する。ユーザの年齢は、第１サーバ１０又は第２サーバ２０に問い合わせることによって取得されてもよいし、コード画像Ｃ１０にユーザの年齢が含まれてもよい。他にも例えば、ユーザが酒類を購入可能な年齢である場合にのみ、コード画像Ｃ１０に確認済み情報（図４では、冒頭の「１１１１」）が含まれてもよい。

例えば、処理実行部４０２は、学生証が学生証アプリで確認され、かつ、ユーザが酒類を購入可能な年齢であると判定された場合に、ユーザの本人確認又は年齢確認を省略可能である旨のメッセージを表示部４５に表示させることによって、省略処理を実行する。通常であれば、酒類を購入する場合には、操作部４４のタッチパネルに対する年齢確認の操作や身分証明書の提示が必要であるが、省略処理が実行された場合には、タッチパネルに対する操作や身分証明書の提示は不要になる。このため、タッチパネルに対する操作や身分証明書の提示がなくても、酒類を購入するための決済処理の実行が可能になる。学生証が学生証アプリで確認されていたとしても、ユーザが酒類を購入可能な年齢でなければ、省略処理は実行されない。

省略処理は、ユーザが酒類を購入する場面以外の任意の場面で実行可能である。例えば、第１実施形態で説明した学割も本人確認又は年齢確認が要求されることがあるので、第１実施形態で説明した学割が行われる場合にも、変形例１－５のような省略処理が実行されてもよい。即ち、ユーザが学生証を提示しなくても、コード画像Ｃ１０の読み取りだけで本人確認又は年齢確認が行われたとみなされるようにしてもよい。他にも例えば、ユーザが決済サービスで購入した飲食物を受け取る場合、ユーザが決済サービスで予約した施設にチェックインする場合、又はユーザが決済サービスで購入したチケットを利用する場合といった任意の場面で省略処理を実行可能である。

変形例１－５によれば、本人確認又は年齢確認を省略する省略処理を実行する。これにより、ユーザは、学生証を学生証アプリに登録すれば、本人確認又は年齢確認を省略できるので、ユーザの利便性が高まる。例えば、たばこ又は酒類の購入といったように、所定の年齢であることが条件になる場合でも、学生証アプリに登録した学生証により年齢確認を完了できるので、コード画像Ｃ１０の読み取りだけで、決済処理だけでなく、省略処理も完了できる。

［変形例１－６］
例えば、サービス提供システムＳは、決済サービスが提供される場合に、学生証に関連付けられたユーザの顔写真を表示部４５に表示させる表示制御部４０４を更に含んでもよい。変形例１－６では、ユーザの顔写真が第２データベースＤＢ２に格納されている場合を説明するが、ユーザの顔写真は、他のデータベースに記憶されていてもよい。ユーザの顔写真は、学生番号に関連付けられてこれらのデータベースに格納されているものとする。

表示制御部４０４は、コード画像Ｃ１０を読み取ると、第１サーバ１０に顔写真の取得要求を送信する。コード画像Ｃ１０には、ユーザの学生番号が含まれているものとする。取得要求には、この学生番号が含まれる。第２サーバ２０は、取得要求に含まれる学生番号により、どのユーザの顔写真が要求されているかを特定できる。第２サーバ２０は、この学生番号に関連付けられた顔写真を店舗端末４０に送信する。表示制御部４０４は、第２サーバ２０から受信した顔写真を表示部４５に表示させる。

店舗の店員は、店舗端末４０に表示された顔写真と、目の前にいるユーザの顔と、を比較し、これらが一致している場合に、決済処理を実行するための操作を行う。店舗の店員は、これらが一致していない場合には、この操作をしない。これらの比較は、店員が行うのではなく、店舗に備えられたカメラを利用した画像処理によって実現されてもよい。また、顔写真の表示は、決済処理の実行前に行われるのではなく、決済処理の実行後に行われてもよい。

なお、顔写真は、第２サーバ２０から直接的に取得されるのではなく、第１サーバ１０を介して取得されてもよいし、第１サーバ１０に顔写真が登録されている場合には第１サーバ１０から直接的に取得されてもよい。また、ユーザの顔写真は、ユーザ端末３０に記憶されていてもよい。この場合、ユーザ端末３０の表示制御部３０１は、決済サービスが提供される場合に、ユーザの顔写真を表示部３５に表示させてもよい。

変形例１－６によれば、決済サービスが提供される場合に、学生証に関連付けられたユーザの顔写真を店舗端末４０の表示部４５に表示させる。これにより、不正なユーザによる決済サービスの利用を防止できる。例えば、他人の学生証を登録したユーザによる学割の不正利用を防止できる。例えば、他人のユーザ端末３０を不正に取得した者による決済サービスの利用も防止できる。

［変形例１－７］
例えば、サービス提供システムＳは、決済サービスに登録されたユーザの第１ユーザ情報と、学生証に含まれるユーザの第２ユーザ情報と、が一致するか否かを判定する一致判定部３０３を更に含んでもよい。第１ユーザ情報は、第１データベースＤＢ１に格納されているユーザ情報である。第２ユーザ情報は、学生証に含まれるユーザ情報であり、学生証が学生証アプリに登録された場合に第２データベースＤＢ２に格納されるユーザ情報である。変形例１－７では、第１ユーザ情報及び第２ユーザ情報の一例として氏名を説明するが、一致判定部３０３による比較対象となる項目は、任意の項目であってよく、氏名に限られない。例えば、第１ユーザ情報及び第２ユーザ情報は、ユーザの生年月日、電話番号、住所、又はメールアドレスであってもよい。複数の項目の組み合わせが比較対象となってもよい。

一致判定部３０３は、第１ユーザ情報及び第２ユーザ情報の完全一致を判定してもよいし、部分一致を判定してもよい。例えば、ユーザ端末３０は、通信部３３のＮＦＣ機能を利用して、学生証に含まれる氏名を、第２ユーザ情報として取得する。ユーザ端末３０は、第１サーバ１０から、決済サービスにログイン中のユーザのユーザＩＤに関連付けられた氏名を、第１ユーザ情報として取得する。第１ユーザ情報としての氏名は、ユーザ端末３０に予め記憶されていてもよい。一致判定部３０３は、これらの第１ユーザ情報及び第２ユーザ情報が一致するか否かを判定する。

なお、一致判定部３０３が第１サーバ１０で実現される場合には、これらの一連の処理が第１サーバ１０で実行されてもよい。即ち、第１サーバ１０は、ユーザ端末３０から、学生証に含まれる氏名を第２ユーザ情報として取得し、第１データベースＤＢ１に格納された氏名を第１ユーザ情報として取得する。第１サーバ１０の一致判定部３０３は、これらの第１ユーザ情報及び第２ユーザ情報が一致するか否かを判定すればよい。

変形例１－７では、第１ユーザ情報及び第２ユーザ情報が一致すると判定された場合に、学生証が学生証アプリに登録されるものとする。第１ユーザ情報及び第２ユーザ情報が一致すると判定されない場合には、学生証は、学生証アプリに登録されない。このため、第１ユーザ情報及び第２ユーザ情報が一致すると判定されない場合には、確認済み情報はコード画像Ｃ１０に含まれない。このため、第１ユーザ情報及び第２ユーザ情報が一致すると判定されなければ、学生証が学生証アプリで確認されたとは判定されなくなる。

処理実行部４０２は、学生証が学生証アプリで確認済みであると判定され、かつ、第１ユーザ情報と第２ユーザ情報とが一致すると判定された場合に、特定の処理を実行する。処理実行部４０２は、学生証が学生証アプリで確認済みであることと、第１ユーザ情報と第２ユーザ情報とが一致することと、の２つが成立した場合に、特定の処理を実行する。これらの何れか又は両方が成立しない場合には、特定の処理は実行されない。変形例１－７では、第１ユーザ情報及び第２ユーザ情報が一致すると判定されなければ、学生証が学生証アプリに登録されず、上記２つが成立することはないので、特定の処理は実行されなくなる。

なお、第１ユーザ情報及び第２ユーザ情報が一致すると判定されない場合だったとしても、学生証が学生証アプリに登録されてもよい。この場合、学生証が学生証アプリに登録された後に、一致判定部３０３の処理が実行されてもよい。即ち、第１ユーザ情報及び第２ユーザ情報が一致しているか否かの判定は、学生証が学生証アプリに登録された後に事後的に実行されてもよい。この場合、学生証が学生証アプリに登録されたとしても、第１ユーザ情報及び第２ユーザ情報が一致していなければ、確認済み情報はコード画像Ｃ１０に含まれない。

他にも例えば、店舗端末４０によりコード画像Ｃ１０が読み取られた後に、一致判定部３０３の処理が実行されてもよい。この場合、一致判定部３０３が店舗端末４０により実行されてもよい。コード画像Ｃ１０には学生番号が含まれているものとする。店舗端末４０の一致判定部３０３は、第１サーバ１０からコードＩＤに関連付けられた氏名を第１ユーザ情報として取得し、第２サーバ２０又は他のサーバから学生番号に関連付けられた氏名を第２ユーザ情報として取得する。店舗端末４０の一致判定部３０３は、これらの第１ユーザ情報及び第２ユーザ情報が一致するか否かを判定すればよい。

変形例１－７によれば、学生証が学生証アプリで確認済みであると判定され、かつ、第１ユーザ情報と第２ユーザ情報とが一致すると判定された場合に、特定の処理を実行する。これにより、不正なユーザによる決済サービスの利用を防止できる。例えば、悪意のある者が他人の学生証を入手したとしても、ユーザ情報が一致せずに特定の処理を実行することができないので、学生証の不正利用を防止できる。

［変形例１－８］
例えば、サービス提供システムＳは、ユーザが学校に所属しなくなった場合に、特定の処理が実行されることを制限する制限部１０４を更に含んでもよい。変形例１－８では、ユーザが学校を卒業又は退学した場合に、第２データベースＤＢ２にその旨の情報が登録されるものとする。この情報の登録は、学校の関係者の操作により行われてもよいし、ユーザ自身で行ってもよい。この情報が登録されると、第１サーバ１０にその旨が通知されて、ユーザが学校を卒業又は退学したことが共有される。第１データベースＤＢ１には、ユーザが学校を卒業又は退学したことを示す情報が登録される。

制限部１０４は、ユーザが学校を卒業又は退学した場合には、コード画像Ｃ１０が読み取られても特定の処理が実行されないようにする。例えば、制限部１０４は、店舗端末４０から決済要求を受信したとしても、ユーザが学校を卒業又は退学した場合には、学割を適用した決済処理を実行しないようにする。決済要求には、学割が適用されているか否かを示す情報が含まれているものとする。学割が適用されているか否かは、決済要求に含まれる利用額に基づいて判定されてもよい。

なお、制限部１０４がユーザ端末３０で実現されてもよい。例えば、ユーザ端末３０の制限部１０４は、ユーザが学校を卒業又は退学した場合には、学生証アプリに登録された学生証を削除することによって、学割処理が実行されないようにしてもよい。この場合、ユーザ端末３０は、第１サーバ１０又は第２サーバ２０から、ユーザが学校を卒業又は退学したことを示す情報を受信するものとする。他にも例えば、制限部１０４は、学生証アプリから学生証を削除しなくても、確認済み情報をコード画像Ｃ１０に含まれないようにすることによって、学割処理が実行されないようにしてもよい。

また、制限部１０４が店舗端末４０で実現されてもよい。例えば、店舗端末４０の制限部１０４は、ユーザが学校を卒業又は退学した場合には、学生証アプリに登録された学生証を削除することによって、学割処理が実行されないようにしてもよい。この場合、店舗端末４０は、第１サーバ１０又は第２サーバ２０から、ユーザが学校を卒業又は退学したことを示す情報を受信するものとする。例えば、店舗端末４０は、コード画像Ｃ１０が読み取られた後に、コード画像Ｃ１０に含まれるコードＩＤ又は学生番号を利用して、ユーザが学校を卒業又は退学したことを示す情報を受信すればよい。

変形例１－８によれば、ユーザが学校に所属しなくなった場合に、特定の処理が実行されることを制限する。これにより、例えば、ユーザが卒業又は退学したとしても、学割が適用されるといったことを防止できる。ユーザからしても、ユーザ側で特別な操作をする必要がないので、ユーザの利便性が高まる。

［変形例１－９］
例えば、学生証が学生証アプリに登録された場合に、決済アプリ以外の他のアプリでも特定の処理が実行されてもよい。変形例１－９では、図２のアイコンＩ１１に表示されたミニアプリのうち、電子商取引アプリである「ＣＣＣ市場」で特定の処理が実行される場合を説明する。電子商取引アプリは、第３アプリの一例であり、電子商取引サービスは、第３サービスの一例である。このため、電子商取引アプリと記載した箇所は、第３アプリと読み替えることができ、電子商取引サービスと記載した箇所は、第３サービスと読み替えることができる。

第３アプリは、第１アプリ及び第２アプリと連携可能なアプリである。変形例１－９では、第３アプリがミニアプリである場合を説明するが、第３アプリは、ミニアプリではなくてもよい。第３サービスは、第３アプリで提供される任意の種類のサービスであればよく、電子商取引サービスに限られない。

変形例１－９では、電子商取引アプリに基づいて電子商取引サービスがユーザに提供される。サービス提供システムＳは、学生証が学生証アプリで確認済みであると判定された場合に、電子商取引サービスに関する特定の処理を実行する処理実行部３０４を更に含む。特定の処理自体は、電子商取引サービスに関する処理という意味では、第１実施形態で説明した特定の処理とは異なるが、特定の処理の言葉自体は、第１実施形態で説明した通りである。変形例１－９では、特定の処理の一例として、第１実施形態と同様の割引処理を説明するが、電子商取引サービスの特定の処理も、割引処理に限られず、分担処理等の他の処理であってもよい。

例えば、処理実行部３０４は、電子商取引アプリで学割が可能な商品を購入する場合に、商品の価格を下げる処理を実行する。処理実行部３０４は、当該処理により下げられた価格に基づいて、電子商取引サービスのサーバに対して商品の購入要求を送信する。電子商取引サービスのサーバは、割引後の商品の価格に基づいて、商品を購入するための処理を実行する。この処理自体は、公知の処理を適用可能である。なお、処理実行部３０４は、第３サービスのサーバにより実現されてもよい。この場合、第３サービスのサーバは、第１サービスのサーバと、第２サービスのサーバと、の少なくとも一方と連携しているものとする。

変形例１－９によれば、学生証が学生証アプリで確認済みであると判定された場合に、電子商取引サービスに関する特定の処理を実行する。これにより、ユーザの利便性が高まる。

［変形例１－１０］
例えば、第１実施形態で説明した決済サービスを、第１決済サービスと記載すると、第１決済サービスは、ユーザに関連付けられた他のユーザが利用する第２決済サービスと連携してもよい。変形例１－１０では、第１決済サービスは、決済アプリから提供される決済サービスであり、第２決済サービスは、第１決済サービスとは異なるクレジットカード会社が提供するサービスである場合を説明する。

処理実行部４０２は、特定の処理として、第２決済サービスにおいて他のユーザが利用する決済手段に基づく決済処理を実行してもよい。他のユーザは、決済アプリのユーザに関連付けられたユーザである。例えば、他のユーザは、決済アプリのユーザの家族であり、ここでは決済アプリのユーザの親とする。処理実行部４０２は、特定の処理として、決済アプリのユーザの親のクレジットカードに基づく決済処理を実行してもよい。即ち、あるユーザの学生証が学生証アプリに登録されることによって、このユーザの親のクレジットカードに基づく決済処理が可能になってもよい。ユーザと他のユーザとの関係は、第１データベースＤＢ１に登録されているものとする。他のユーザのカード番号等の決済情報は、第１データベースＤＢ１に登録されていてもよいし、他のデータベースに登録されていてもよい。

変形例１－１０によれば、特定の処理として、第２決済サービスにおいて他のユーザが利用する決済手段に基づく決済処理を実行する。これにより、ユーザの利便性が高まる。

［変形例１－１１］
例えば、第１実施形態と第２実施形態を組み合わせてもよい。更に、変形例１－１１では、決済アプリ以外の画面に通知画像Ｉ１３が表示されてもよい。表示判定部１０３は、ユーザ情報に基づいて、学生証アプリに関する学生証アプリ情報をユーザのユーザ端末３０に表示させるか否かを判定する。表示制御部３０１は、表示判定部１０３の判定結果に基づいて、ユーザ端末３０に学生証アプリ情報を表示させる。これらの処理は、第２実施形態で説明した通りである。

変形例１－１１によれば、第２実施形態と同様に、ユーザの利便性が高まる。

［変形例１－１２］
例えば、第１実施形態では、学生証が学生証アプリで確認済みであるか否かを判定する判定方法として、コード画像Ｃ１０を利用する方法を説明したが、この判定方法は、他の方法であってもよい。例えば、第１データベースＤＢ１に、学生証が学生証アプリで確認済みであるか否かを示す情報が格納されており、この情報が利用されてもよい。

変形例１－１２のサービス提供システムＳは、学生証が学生証アプリで確認された場合に、決済サービスにおけるユーザＩＤに、学生証が学生証アプリで確認済みであることを示す確認済み情報を関連付ける関連付け部１０５を更に含む。例えば、第１データベースＤＢ１において、ユーザＩＤと、確認済み情報と、が関連付けられる。変形例１－１２の確認済み情報は、学生証が学生証アプリで確認済みであるか否かを識別可能な情報であればよく、例えば、フラグのような情報であってもよい。

確認判定部４０１は、ユーザＩＤに関連付けられた確認済み情報に基づいて、学生証が学生証アプリで確認済みであるか否かを判定してもよい。例えば、確認判定部４０１は、店舗端末４０がコード画像Ｃ１０を読み取ると、第１サーバ１０に、確認済み情報の取得要求を送信する。この取得要求には、コード画像Ｃ１０から取得されたコードＩＤが含まれるものとする。第１サーバ１０は、取得要求を受信すると、コードＩＤに関連付けられた確認済み情報を取得して店舗端末４０に送信する。確認判定部４０１は、第１サーバ１０から受信した確認済み情報に基づいて、学生証が学生証アプリで確認済みであるか否かを判定する。

なお、確認判定部４０１は、店舗端末４０ではなく、第１サーバ１０により実現されてもよい。この場合、第１サーバ１０の確認判定部４０１は、店舗端末４０から決済要求を受信した場合に、第１データベースＤＢ１に基づいて、学生証が学生証アプリで確認済みであるか否かを判定すればよい。確認判定部４０１は、店舗端末４０に判定結果を送信してもよい。店舗端末４０の処理実行部４０２は、第１サーバ１０から受信した判定結果に基づいて、特定の処理を実行するか否かを決定すればよい。また、確認判定部４０１は、第２サーバ２０により実現されてもよいし、他のサーバにより実現されてもよい。

変形例１－１２によれば、ユーザＩＤに関連付けられた確認済み情報に基づいて、学生証が学生証アプリで確認済みであるか否かを判定する。これにより、コード画像Ｃ１０に確認済み情報を含めなくても、学生証が学生証アプリで確認済みであるか否かを判定できる。

［変形例１－１３］
例えば、第２アプリは、学生証アプリに限られない。変形例１－１３では、第２アプリが図２のアイコンＩ１１の「ＢＢＢ銀行」のミニアプリである場合を説明する。以降、このミニアプリを銀行アプリと記載する。このため、銀行アプリと記載した箇所は、第２アプリと読み替えることができる。銀行アプリは、金融サービスを提供するためのアプリケーションである。変形例１－１３では、金融サービスは、第２サービスの一例である。

例えば、銀行アプリでは、ユーザの身分証明書が確認される。身分証明書は、本人確認書類と呼ばれることもある。身分証明書自体は、種々の文書を利用可能であり、例えば、第１実施形態で説明した学生証以外にも、免許証、保険証、個人番号カード、パスポート、又は年金手帳であってもよい。身分証明書の確認方法自体は、公知の種々の方法を利用可能であり、例えば、ＮＦＣを利用した方法、撮影部３６で撮影した画像を利用した方法、又はｅＫＹＣと呼ばれる方法であってもよい。

ユーザは、銀行アプリから種々の金融サービスを利用できる。例えば、銀行アプリから預金残高の確認、明細の確認、又は振込の実行が可能である。銀行アプリでは、身分証明書が確認されることによって、特定の機能を利用できるようになってもよい。変形例１－１３の確認判定部４０１は、決済サービスが提供される場合に、身分証明書が銀行証アプリで確認済みであるか否かを判定する。処理実行部４０２は、身分証明書が銀行アプリで確認済みであると判定された場合に、決済サービスに関する特定の処理を実行する。

確認判定部４０１の処理と、処理実行部４０２の処理と、はメンバーシップ情報が利用されるか身分証明書が利用されるかが第１実施形態とは異なるが、基本的な処理の内容は第１実施形態で説明した通りである。例えば、身分証明書が学生証だったとすると、ユーザ端末３０は、身分証明書である学生証が銀行アプリで確認された場合に、確認済み情報を含むコード画像Ｃ１０を表示部３５に表示させる。

店舗端末４０でコード画像Ｃ１０が読み取られると、確認判定部４０１は、コード画像Ｃ１０に確認済み情報が含まれるか否かを判定する。処理実行部４０２は、コード画像Ｃ１０に確認済み情報が含まれると判定された場合に、割引処理を実行すればよい。なお、銀行アプリで確認された身分証明書が学生証以外の身分証明書であった場合には、ユーザが学生であるか否かを確認できないので、割引処理は実行されないようにしてもよい。

変形例１－１３によれば、身分証明書が学生証アプリで確認済みであると判定された場合に、決済サービスに関する特定の処理を実行する。これにより、決済アプリ側で身分証明書を確認する必要がなくなるので、ユーザの利便性が高まる。

［３－２．第２実施形態に係る変形例］
第２実施形態に係る変形例を説明する。図１４は、第２実施形態に係る変形例における機能ブロック図の一例である。制限部３０５は、制御部３１を主として実現される。

［変形例２－１］
例えば、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する際に利用されるユーザ情報は、ユーザの位置に関するユーザ位置情報であってもよい。ユーザ位置情報は、ユーザの位置を識別可能な情報であればよく、例えば、ＧＰＳにより得られた位置情報、ＧＰＳ以外のＧＮＳＳにより得られた位置情報、無線ＬＡＮのアクセスポイント情報、又は携帯基地局情報であってもよい。他にも例えば、ユーザ位置情報は、ユーザが自身で入力した住所又は郵便番号といった情報であってもよい。

変形例２－１では、ユーザ情報取得部１０２は、ユーザのユーザ端末３０により検出されたユーザ位置情報を取得する場合を説明する。例えば、ユーザ情報取得部１０２は、ユーザ端末３０のＧＰＳ受信部３８が受信した衛星からの信号に基づいて、ユーザ位置情報を取得する。他にも例えば、ユーザ情報取得部１０２は、ユーザ端末３０の通信部３３の通信結果に基づいて、ユーザ位置情報を取得する。これらの位置を取得する方法自体は、公知の測位技術を利用可能である。

表示判定部１０３は、ユーザ位置情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。変形例２－１では、表示判定部１０３は、ユーザ端末３０により検出されたユーザ位置情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。通知画像Ｉ１３を表示させるべき位置又はエリアは、予めデータ記憶部３００に定められているものとする。

例えば、第２実施形態で説明した学生証アプリであれば、学校又はその付近のエリアが、通知画像Ｉ１３を表示させるべき位置又はエリアとして予め指定されているものとする。付近とは、距離が閾値未満であることを意味する。表示判定部１０３は、ユーザ端末３０により検出されたユーザ位置情報が示すユーザの位置が学校又はその付近のエリアであるか否かを判定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。ユーザの位置が学校又はその付近のエリアである場合に、決済アプリ上で通知画像Ｉ１３を表示させると判定される。

変形例２－１によれば、ユーザ位置情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。これにより、学生証アプリを利用するユーザか否かを推定する精度が高まるので、ユーザの利便性が高まる。例えば、ユーザが決済アプリに組織を登録していなかったとしても、学生証アプリに対応している学校の生徒であるか否かをユーザの位置によって推定できるので、学生証アプリの利用を促進できる。

また、ユーザ端末３０により検出されたユーザ位置情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。これにより、ユーザの位置をより正確に取得したうえで、決済アプリ上で通知画像Ｉ１３を表示させることができるので、ユーザの利便性がより高まる。

［変形例２－２］
例えば、ユーザ情報取得部１０２は、ユーザが決済サービスを利用した位置に関するユーザ位置情報を取得してもよい。ユーザが決済サービスを利用した位置とは、ユーザが決済サービスを利用した時にユーザがいた場所の位置である。ユーザが決済サービスを利用した支払いをした店舗の位置は、ユーザが決済サービスを利用した位置に相当する。例えば、ユーザ情報取得部１０２は、第１データベースＤＢ１に格納された利用履歴情報に基づいて、ユーザが決済サービスを利用した利用場所を特定する。

なお、個々の利用場所の位置は、データ記憶部１００に予め記憶されているものとする。即ち、決済サービスの加盟店の位置は、データ記憶部１００に予め記憶されているものとする。ユーザ情報取得部１０２は、過去の全期間におけるユーザの利用場所を特定してもよいし、直近の一部の期間におけるユーザの利用場所を特定してもよい。ユーザ情報取得部１０２は、ユーザが複数の利用場所を利用した場合には、複数の利用場所の各々の位置の平均位置をユーザ位置情報として取得してもよい。更に、この平均位置は、利用日時が新しいほど重み係数が大きくなるような加重平均であってもよい。

表示判定部１０３は、ユーザが決済サービスを利用した位置に関するユーザ位置情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。ユーザ位置情報の取得方法が変形例２－１とは異なるが、表示判定部１０３の処理自体は、変形例２－１で説明した通りである。

変形例２－２によれば、ユーザが決済サービスを利用した位置に関するユーザ位置情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。これにより、ユーザ端末３０からユーザの位置を取得できなかったとしても、ユーザの位置を推定できる。

［変形例２－３］
例えば、変形例２－１及び２－２では、ユーザ情報の一例としてユーザ位置情報を説明したが、ユーザ情報は、ユーザの属性に関するユーザ属性情報であってもよい。ユーザの属性は、ユーザの分類である。ユーザの属性は、何らかの観点でユーザを分類可能な情報であればよく、例えば、年齢、年齢層、性別、住所、居住エリア、職業、年収、家族構成、又はこれらの組み合わせであってもよい。ユーザの属性は、デモグラフィックと呼ばれる情報であってもよい。ユーザが所属する組織もユーザの何らかの属性なので、変形例２－３では、ユーザの組織がユーザ属性情報として利用される場合を説明する。

表示判定部１０３は、ユーザ属性情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。通知画像Ｉ１３を表示させるべき属性は、予めデータ記憶部３００に定められているものとする。例えば、第２実施形態で説明した学生証アプリであれば、学生証アプリに対応している学校が、通知画像Ｉ１３を表示させるべき属性として予め指定されているものとする。表示判定部１０３は、第１データベースＤＢ１に格納されたユーザの組織が学生証アプリに対応している学校であるか否かを判定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。ユーザの組織が学生証アプリに対応している学校である場合に、決済アプリ上で通知画像Ｉ１３を表示させると判定される。

なお、通知画像Ｉ１３を表示させるべき属性は、ユーザの組織に限られない。例えば、表示判定部１０３は、ユーザの年齢、年齢層、住所、及び居住エリアといった複数の属性を総合的に考慮して、学生証アプリに対応している学校にユーザが通学しているか否かを推定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定してもよい。

この点は、第２アプリが学生証アプリ以外の他のアプリである場合も同様であり、表示判定部１０３は、ユーザの複数の属性を総合的に考慮して、ユーザが第２アプリを利用する確率が高いか否かを推定することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定してもよい。例えば、種々のユーザの複数の属性の各々と、第２アプリを表示させるか否かと、の関係が学習された機械学習モデルが利用されてもよい。表示判定部１０３は、あるユーザの複数の属性を機械学習モデルに入力し、機械学習モデルからの出力を取得することによって、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定してもよい。

変形例２－３によれば、ユーザ属性情報に基づいて、決済アプリ上で通知画像Ｉ１３を表示させるか否かを判定する。これにより、例えば、ユーザの位置を取得できなかったとしても、学生証アプリに対応している学校の生徒であるか否かをユーザの位置によって推定できるので、学生証アプリの利用を促進できる。

［変形例２－４］
例えば、第２実施形態では、第２アプリ情報の一例として通知画像Ｉ１３を説明したが、既に第２アプリをインストール済みである場合には、第２アプリ情報は、第２アプリの起動を促す起動情報であってもよい。起動情報は、学生証アプリの起動を促すメッセージ、学生証アプリの起動を促すアイコン、又は学生証アプリを起動させるためのバナーである。

変形例２－４の表示判定部１０３は、ユーザが学生証アプリを利用可能な場合に、学生証アプリの起動を促す起動情報を、第２アプリ情報として決済アプリ上で表示させるか否かを判定してもよい。ユーザが学生証アプリを利用可能とは、学生証アプリの利用開始の手続きを済ませていることである。即ち、学生証アプリをインストール済みであることは、ユーザが学生証アプリを利用可能であることに相当する。

表示判定部１０３は、ユーザ情報に基づいて、決済アプリ上で起動情報を表示させるか否かを判定する。例えば、表示判定部１０３は、変形例２－１又は変形例２－２で説明したユーザ位置情報に基づいて、決済アプリ上で起動情報を表示させるか否かを判定する。表示判定部１０３は、ユーザ位置情報が示すユーザの位置が学校又はその付近である場合に、決済アプリ上で起動情報を表示させると判定する。表示判定部１０３は、ユーザ位置情報が示すユーザの位置が学校又はその付近ではない場合に、決済アプリ上で起動情報を表示させると判定する。

なお、表示判定部１０３は、ユーザ位置情報以外のユーザ情報に基づいて、決済アプリ上で起動情報を表示させるか否かを判定してもよい。例えば、決済サービスの利用履歴情報も、ユーザに関する何らかの情報なので、ユーザ情報に相当してもよい。表示判定部１０３は、利用履歴情報が示す利用場所が学校又はその付近である場合に、決済アプリ上で起動情報を表示させると判定してもよい。

表示制御部３０１は、表示判定部１０３の判定結果に基づいて、決済アプリ上で起動情報を、第２アプリ情報として表示させる。表示制御部３０１は、決済アプリ上で起動情報を表示させると判定された場合に、決済アプリ上で起動情報を表示させる。表示制御部３０１は、決済アプリ上で起動情報を表示させると判定されない場合には、決済アプリ上で起動情報を表示させない。

変形例２－４によれば、ユーザが学生証アプリを利用可能な場合に、学生証アプリの起動を促す起動情報を決済アプリ上で表示させるか否かを判定し、決済アプリ上で起動情報を表示させる。これにより、学生証アプリが必要な場面で学生証アプリを起動させやすくなるので、ユーザの利便性が高まる。

［変形例２－５］
例えば、サービス提供システムＳは、起動情報が表示された場合に、学生証アプリの起動を許可し、起動情報が表示されない場合に、学生証アプリの起動を制限する制限部３０５を更に含んでもよい。即ち、変形例２－４で説明した起動情報が表示されている間のみ学生証アプリの起動が可能であってもよい。例えば、起動情報は、学生証アプリのアイコンＩ１１であってもよく、制限部３０５は、学生証アプリのアイコンＩ１１の表示／非表示を制御することによって、学生証アプリの起動を制限してもよい。他にも例えば、制限部３０５は、学生証アプリのアイコンＩ１１の表示／非表示を制御するのではなく、学生証アプリのアイコンＩ１１が選択されても学生証アプリを起動しないようにすることによって、学生証アプリの起動を制限してもよい。

変形例２－５によれば、起動情報が表示された場合に、学生証アプリの起動を許可し、起動情報が表示されない場合に、学生証アプリの起動を制限する。これにより、学生証アプリが必要ではない場面で誤って学生証アプリが起動することを防止できる。

［変形例２－６］
例えば、第２実施形態では、決済アプリにおけるユーザ情報が利用される場合を説明したが、決済アプリと連携する第３サービスにおけるユーザ情報が利用されてもよい。変形例２－６のユーザ情報取得部１０２は、第３サービスにおけるユーザ情報を取得する。変形例２－６では、変形例１－９と同様に、第３サービスが電子商取引サービスである場合を説明するが、第３サービスは、任意のサービスであってよい。

ユーザ情報取得部１０２は、電子商取引サービスのサーバから、電子商取引サービスにおけるユーザ情報を取得する。なお、決済サービス及び電子商取引サービスで共通のユーザＩＤが利用されてもよいし、決済サービス及び電子商取引サービスで異なるユーザＩＤが利用されていて同じユーザのユーザＩＤ同士が関連付けられていてもよい。決済サービスのユーザと、電子商取引サービスのユーザと、の対応関係が何らかの形で特定可能であればよい。

表示判定部１０３は、電子商取引サービスにおけるユーザ情報に基づいて、通知画像Ｉ１３を表示させるか否かを判定する。電子商取引サービスにおけるユーザ情報が利用されるといった点で第２実施形態と異なるが、ユーザ情報を利用した判定方法自体は、第２実施形態と同様である。例えば、表示判定部１０３は、電子商取引サービスにおけるユーザの組織として、学生証アプリに対応する学校が登録されているか否かを判定することによって、通知画像Ｉ１３を表示させるか否かを判定してもよい。他にも例えば、表示判定部１０３は、電子商取引サービスにおけるユーザの年齢や配送先の住所として、学生証アプリに対応する学校に通っていると推測される年齢や住所が登録されているか否かを判定することによって、通知画像Ｉ１３を表示させるか否かを判定してもよい。

変形例２－６によれば、電子商取引サービスにおけるユーザ情報に基づいて、通知画像Ｉ１３を表示させるか否かを判定する。これにより、通知画像Ｉ１３を表示させた方がよいユーザのユーザ端末３０に通知画像Ｉ１３を表示させることができるので、ユーザの利便性が高まる。

［変形例２－７］
例えば、第１実施形態と第２実施形態を組み合わせてもよい。変形例２－７のサービス提供システムＳは、第１実施形態で説明した確認判定部４０１及び処理実行部４０２を含む。これらの機能は、第１実施形態で説明した通りである。

変形例２－７によれば、第１実施形態と同様に、ユーザの利便性が高まる。

［変形例２－８］
例えば、変形例１－１３と同様に、学生証アプリでは、ユーザの身分証明書が確認されてもよい。変形例２－８のサービス提供システムＳは、変形例１－１３で説明した確認判定部４０１及び処理実行部４０２を含む。これらの機能は、変形例１－１３で説明した通りである。

変形例２－８によれば、変形例１－１３と同様に、ユーザの利便性が高まる。

［３－３．その他変形例］
例えば、上記説明した変形例を組み合わせてもよい。

例えば、第１サービス及び第２サービスの各々は、任意のサービスであってよい。例えば、第１サービス及び第２サービスの各々は、電子商取引サービス、行政サービス、金融サービス、通信サービス、保険サービス、動画配信サービス、ポイント管理サービス、又はＳＮＳ（Social Networking Service）であってもよい。第１サービス及び第２サービスは、互いに異なる種類のサービスであってもよいし、互いに同種のサービスであってもよい。

例えば、第１サービスが決済サービスであり、第２サービスがポイント管理サービスであったとする。ポイント管理サービスは、ある店舗又はグループにおけるポイントを管理するサービスである。例えば、ユーザがポイント管理サービスの会員になると、会員証を店舗で提示すれば、利用額に応じたポイントを獲得できる。ユーザは、第２アプリであるポイント管理アプリを利用することで、会員証を提示しなくてもポイントを獲得できるようになる。例えば、ポイント管理アプリでは、ユーザの会員証に相当するコード画像が表示される。店舗でコード画像が読み取られると、ユーザは利用額に応じたポイントを獲得できる。

例えば、ポイント管理アプリにユーザの会員証が登録されると、決済アプリのコード画像Ｃ１０を読み取るだけで、特定の処理として、ポイントを獲得する処理が実行されてもよい。この場合も第１実施形態と同様にして、会員証が登録済みであることを示す情報がコード画像Ｃ１０に含まれるようにすればよい。他にも例えば、決済アプリ側で、ユーザがポイント管理アプリの会員であることが推定されると、ポイント管理アプリの利用開始を促す通知画像Ｉ１３が決済アプリ上で表示されてもよい。例えば、ユーザの利用履歴情報に含まれる利用場所がポイント管理アプリに対応する店舗である場合に、通知画像Ｉ１３が決済アプリ上で表示されてもよい。

例えば、第１サービスが決済サービスであり、第２サービスが行政サービスであってもよい。この場合、第２アプリは、個人番号カードが登録されてもよい。個人番号カードは、身分証明書の一例である。例えば、第２アプリで個人番号カードが確認されると、決済アプリのコード画像Ｃ１０を提示するだけで、本人確認又は年齢確認が省略されるようにしてもよい。この省略については、変形例１－５で説明した通りである。例えば、第１サービス及び第２サービスは、上記の例にも限られず、任意の組み合わせであってよい。第１アプリ及び第２アプリの組み合わせも任意の組み合わせであってよい。例えば、第１アプリがミニアプリであり、第２アプリがスーパーアプリであってもよい。また、第１アプリと第２アプリは、それぞれスーパーアプリとミニアプリの関係になくてもよい。

例えば、第１サーバ１０と第２サーバ２０が分けられておらず、１つのコンピュータで各機能が実現されてもよい。例えば、第１サーバ１０、第２サーバ２０、ユーザ端末３０、及び店舗端末４０の各々で実現されるものとして説明した機能は、複数のコンピュータで分担されてもよい。各機能は、少なくとも１つのコンピュータで実現されるようにすればよい。

Ｓ サービス提供システム、Ｎ ネットワーク、１１，２１，３１，４１ 制御部、１２，２２，３２，４２ 記憶部、１３，２３，３３，４３ 通信部、３０ ユーザ端末、３４，４４ 操作部、３５，４５ 表示部、３６ 撮影部、３７ ＩＣチップ、３８ ＧＰＳ受信部、４０ 店舗端末、４６ 読取部、Ｇ１ トップ画面、Ｇ２ 決済完了画面、Ｇ３ 選択画面、Ｇ４ 登録画面、Ｇ５ 登録完了画面、Ｇ６ トップ画面、Ｇ７ 設定画面、１００ データ記憶部、１０１ 第１提供部、１０２ ユーザ情報取得部、１０３ 表示判定部、１０４ 制限部、１０５ 関連付け部、２００ データ記憶部、２０１ 第２提供部、３００ データ記憶部、３０１ 表示制御部、３０２ 確認部、３０３ 一致判定部、３０４ 処理実行部、３０５ 制限部、４００ データ記憶部、４０１ 確認判定部、４０２ 処理実行部、４０３ 条件判定部、４０４ 表示制御部、Ｃ１０ コード画像、Ｉ１１ アイコン、Ｌ１２ リンク、Ｉ１３ 通知画像。

Claims (20)

1. 第１アプリに基づいて第１サービスがユーザに提供され、第２アプリに基づいて第２サービスが前記ユーザに提供されるサービス提供システムであって、
   前記第２アプリでは、前記第２サービスに関する前記ユーザのメンバーシップ情報が確認され、
   前記第１サービスが提供される場合に、前記メンバーシップ情報が前記第２アプリで確認済みであるか否かを判定する確認判定手段と、
   前記メンバーシップ情報が前記第２アプリで確認済みであると判定された場合に、前記第１サービスに関する特定の処理を実行する処理実行手段と、
   を含むサービス提供システム。
2. 前記サービス提供システムは、前記第２サービスに関連付けられた所定の条件を前記ユーザが満たすか否かを判定する条件判定手段を更に含み、
   前記処理実行手段は、前記メンバーシップ情報が前記第２アプリで確認済みであると判定され、かつ、前記ユーザが前記条件を満たすと判定された場合に、前記処理を実行する、
   請求項１に記載のサービス提供システム。
3. 前記条件は、前記第２サービスに関連付けられた所定の課題を前記ユーザが達成することであり、
   前記条件判定手段は、前記ユーザが前記課題を達成したか否かを判定することによって、前記ユーザが前記条件を満たすか否かを判定し、
   前記処理実行手段は、前記メンバーシップ情報が前記第２アプリで確認済みであると判定され、かつ、前記ユーザが前記課題を達成したと判定された場合に、前記処理を実行する、
   請求項２に記載のサービス提供システム。
4. 前記第２サービスは、前記ユーザが所属する組織に関するサービスであり、
   前記課題は、前記ユーザが前記組織で所定の成績を収めることであり、
   前記条件判定手段は、前記ユーザが前記成績を収めたか否かを判定することによって、前記ユーザが前記課題を達成したか否かを判定し、
   前記処理実行手段は、前記メンバーシップ情報が前記第２アプリで確認済みであると判定され、かつ、前記ユーザが前記成績を収めたと判定された場合に、前記処理を実行する、
   請求項３に記載のサービス提供システム。
5. 前記第１サービスは、決済サービスであり、
   前記処理実行手段は、前記処理として、前記決済サービスにおいて割引を適用する割引処理を実行する、
   請求項１～４の何れかに記載のサービス提供システム。
6. 前記第１サービスは、決済サービスであり、
   前記処理実行手段は、前記処理として、前記決済サービスにおける利用額を前記ユーザと他の者とで分担する分担処理を実行する、
   請求項１～５の何れかに記載のサービス提供システム。
7. 前記第１サービスでは、前記ユーザの本人確認又は年齢確認が要求され、
   前記処理実行手段は、前記処理として、前記本人確認又は前記年齢確認を省略する省略処理を実行する、
   請求項１～６の何れかに記載のサービス提供システム。
8. 前記サービス提供システムは、前記第１サービスが提供される場合に、前記メンバーシップ情報に関連付けられた前記ユーザの顔写真を表示手段に表示させる表示制御手段を更に含む、
   請求項１～７の何れかに記載のサービス提供システム。
9. 前記サービス提供システムは、前記第１サービスに登録された前記ユーザの第１ユーザ情報と、前記メンバーシップ情報に含まれる前記ユーザの第２ユーザ情報と、が一致するか否かを判定する一致判定手段を更に含み、
   前記処理実行手段は、前記メンバーシップ情報が前記第２アプリで確認済みであると判定され、かつ、前記第１ユーザ情報と前記第２ユーザ情報とが一致すると判定された場合に、前記処理を実行する、
   請求項１～８の何れかに記載のサービス提供システム。
10. 前記第２サービスは、前記ユーザが所属する組織に関するサービスであり、
    前記サービス提供システムは、前記ユーザが前記組織に所属しなくなった場合に、前記処理が実行されることを制限する制限手段を更に含む、
    請求項１～９の何れかに記載のサービス提供システム。
11. 第３アプリに基づいて第３サービスが前記ユーザに提供され、
    前記サービス提供システムは、前記メンバーシップ情報が前記第２アプリで確認済みであると判定された場合に、前記第３サービスに関する特定の処理を実行する手段を更に含む、
    請求項１～１０の何れかに記載のサービス提供システム。
12. 前記第１サービスは、第１決済サービスであり、
    前記第１決済サービスは、前記ユーザに関連付けられた他のユーザが利用する第２決済サービスと連携し、
    前記処理実行手段は、前記処理として、前記第２決済サービスにおいて前記他のユーザが利用する決済手段に基づく決済処理を実行する、
    請求項１～１１の何れかに記載のサービス提供システム。
13. 前記サービス提供システムは、
    前記ユーザに関するユーザ情報を取得するユーザ情報取得手段と、
    前記ユーザ情報に基づいて、前記第２アプリに関する第２アプリ情報を前記ユーザのユーザ端末に表示させるか否かを判定する表示判定手段と、
    前記表示判定手段の判定結果に基づいて、前記ユーザ端末に前記第２アプリ情報を表示させる表示制御手段と、
    請求項１～１２の何れかに記載のサービス提供システム。
14. 前記第１アプリは、前記メンバーシップ情報が前記第２アプリで確認された場合に、前記メンバーシップ情報が前記第２アプリで確認済みであることを示す確認済み情報を出力し、
    前記確認判定手段は、前記第１アプリにより出力された前記確認済み情報に基づいて、前記メンバーシップ情報が前記第２アプリで確認済みであるか否かを判定する、
    請求項１～１３の何れかに記載のサービス提供システム。
15. 前記サービス提供システムは、前記メンバーシップ情報が前記第２アプリで確認された場合に、前記第１サービスにおけるユーザ識別情報に、前記メンバーシップ情報が前記第２アプリで確認済みであることを示す確認済み情報を関連付ける関連付け手段を更に含み、
    前記確認判定手段は、前記ユーザ識別情報に関連付けられた前記確認済み情報に基づいて、前記メンバーシップ情報が前記第２アプリで確認済みであるか否かを判定する、
    請求項１～１４の何れかに記載のサービス提供システム。
16. 前記第１サービスは、決済サービスであり、
    前記第２サービスは、前記ユーザが所属する組織に関するサービスであり、
    前記メンバーシップ情報は、前記ユーザが前記組織に所属することを証明する情報である、
    請求項１～１５の何れかに記載のサービス提供システム。
17. 前記第１アプリは、スーパーアプリであり、
    前記第２アプリは、前記スーパーアプリから利用可能なミニアプリである、
    請求項１～１６の何れかに記載のサービス提供システム。
18. 第１アプリに基づいて第１サービスがユーザに提供され、第２アプリに基づいて第２サービスが前記ユーザに提供されるサービス提供システムであって、
    前記第２アプリでは、前記ユーザの身分証明書が確認され、
    前記第１サービスが提供される場合に、前記身分証明書が前記第２アプリで確認済みであるか否かを判定する確認判定手段と、
    前記身分証明書が前記第２アプリで確認済みであると判定された場合に、前記第１サービスに関する特定の処理を実行する処理実行手段と、
    を含むサービス提供システム。
19. 第１アプリに基づいて第１サービスがユーザに提供され、第２アプリに基づいて第２サービスが前記ユーザに提供されるサービス提供方法であって、
    前記第２アプリでは、前記第２サービスに関する前記ユーザのメンバーシップ情報が確認され、
    前記第１サービスが提供される場合に、前記メンバーシップ情報が前記第２アプリで確認済みであるか否かを判定する確認判定ステップと、
    前記メンバーシップ情報が前記第２アプリで確認済みであると判定された場合に、前記第１サービスに関する特定の処理を実行する処理実行ステップと、
    を含むサービス提供方法。
20. 第１アプリに基づいて第１サービスがユーザに提供され、第２アプリに基づいて第２サービスが前記ユーザに提供され、前記第２アプリでは、前記第２サービスに関する前記ユーザのメンバーシップ情報が確認され、
    前記第１サービスが提供される場合に、前記メンバーシップ情報が前記第２アプリで確認済みであるか否かを判定する確認判定手段、
    前記メンバーシップ情報が前記第２アプリで確認済みであると判定された場合に、前記第１サービスに関する特定の処理を実行する処理実行手段、
    としてコンピュータを機能させるためのプログラム。

Images