特開 2023-155122 情報処理装置、情報処理方法及び情報処理プログラム

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

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

(11)【公開番号】P2023155122

(43)【公開日】2023-10-20

(54)【発明の名称】情報処理装置、情報処理方法及び情報処理プログラム

(51)【国際特許分類】

   G06Q 40/06 20120101AFI20231013BHJP

【ＦＩ】

G06Q40/06

【審査請求】有

【請求項の数】3

【出願形態】ＯＬ

(21)【出願番号】P 2022144250

(22)【出願日】2022-09-12

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

【原出願日】2022-04-08

(11)【特許番号】

(45)【特許公報発行日】2023-06-16

(71)【出願人】

【識別番号】519110124

【氏名又は名称】ＰａｙＰａｙ株式会社

(71)【出願人】

【識別番号】514108584

【氏名又は名称】ＰａｙＰａｙ証券株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】安念 宣子

(72)【発明者】

【氏名】平田 梨紗

(72)【発明者】

【氏名】内山 昌秋

【テーマコード（参考）】

5L055

【Ｆターム（参考）】

5L055BB52

(57)【要約】

【課題】債権譲渡（ファクタリング）により有価証券の売却取引当日の売却代金を電子マネーで受領できるスキームを実現する。
【解決手段】情報処理装置は、決済サービス事業者の決済サーバから、ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信部と、保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知部と、前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理部と、を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

決済サービス事業者の決済サーバから、ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信部と、
保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知部と、
前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理部と、
を備えることを特徴とする情報処理装置。

【請求項2】

情報処理装置が実行する情報処理方法であって、
決済サービス事業者の決済サーバから、ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信工程と、
保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知工程と、
前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理工程と、
を含むことを特徴とする情報処理方法。

【請求項3】

決済サービス事業者の決済サーバから、ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信手順と、
保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知手順と、
前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理手順と、
をコンピュータに実行させるための情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置、情報処理方法及び情報処理プログラムに関する。

【背景技術】

【0002】

従来、複数の証券会社間で、売注文の売却代金の受渡日よりも前の日に、顧客の買付余力を確保するための技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかしながら、上記の従来技術は、ある証券会社での売注文の売却代金により別の証券会社で別の銘柄の買付を行う際の売却処理と買付処理との時間差を無くすか、短くするというものに過ぎない。現在、資産運用ミニアプリにおける資金決済に関する仕組みとして、ユーザが有価証券売却取引当日に電子マネーを受領できる仕組みの実現を目指して技術開発が進められている。

【0005】

本願は、上記に鑑みてなされたものであって、債権譲渡（ファクタリング）により有価証券の売却取引当日の売却代金を電子マネーで受領できるスキームを実現することを目的とする。

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

【0006】

本願に係る情報処理装置は、決済サービス事業者の決済サーバから、ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信部と、保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知部と、前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理部と、を備えることを特徴とする。

【発明の効果】

【0007】

実施形態の一態様によれば、債権譲渡（ファクタリング）により有価証券の売却取引当日の売却代金を電子マネーで受領できるスキームを実現することができる。

【図面の簡単な説明】

【0008】

【図1】図１は、実施形態に係る情報処理方法の概要を示す説明図である。

【図2】図２は、資産運用ミニアプリの提供サービスの一例を示す概念図である。

【図3】図３は、決済サービス事業者－証券会社間での資産運用ミニアプリの資金フローの一例を示す概念図である。

【図4】図４は、ユーザ－決済サービス事業者－証券会社間での資産運用ミニアプリの資金フローの一例を示す概念図である。

【図5】図５は、資産運用ミニアプリの概要を示す図である。

【図6】図６は、実施形態に係る情報処理システムの構成例を示す図である。

【図7】図７は、実施形態に係る端末装置の構成例を示す図である。

【図8】図８は、実施形態に係る決済サーバの構成例を示す図である。

【図9】図９は、利用者情報データベースの一例を示す図である。

【図10】図１０は、実施形態に係る処理手順を示すフローチャートである。

【図11】図１１は、証券サーバの構成例を示す図である。

【図12】図１２は、ハードウェア構成の一例を示す図である。

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

【0009】

以下に、本願に係る情報処理装置、情報処理方法及び情報処理プログラムを実施するための形態（以下、「実施形態」と記載する）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法及び情報処理プログラムが限定されるものではない。また、以下の実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

【0010】

〔１．情報処理方法の概要〕
まず、図１を参照し、実施形態に係る情報処理装置が行う情報処理方法の概要について説明する。図１は、実施形態に係る情報処理方法の概要を示す説明図である。なお、図１では、債権譲渡（ファクタリング）により有価証券の売却取引当日の売却代金を電子マネーで受領する場合を例に挙げて説明する。

【0011】

図１に示すように、情報処理システム１は、端末装置１０と決済サーバ１００と証券サーバ２００とを含む。端末装置１０と決済サーバ１００と証券サーバ２００とは、ネットワークＮ（図６参照）を介して有線又は無線で互いに通信可能に接続される。本実施形態では、端末装置１０は、決済サーバ１００と連携する。

【0012】

端末装置１０は、利用者Ｕ（ユーザ）により使用されるスマートフォンやタブレット等のスマートデバイスであり、４Ｇ（Generation）やＬＴＥ（Long Term Evolution）等の無線通信網を介して任意のサーバ装置と通信を行うことができる携帯端末装置である。また、端末装置１０は、液晶ディスプレイ等の画面であって、タッチパネルの機能を有する画面を有し、利用者Ｕから指やスタイラス等によりタップ操作、スライド操作、スクロール操作等、コンテンツ等の表示データに対する各種の操作を受付ける。なお、画面のうち、コンテンツが表示されている領域上で行われた操作を、コンテンツに対する操作としてもよい。また、端末装置１０は、スマートデバイスのみならず、デスクトップＰＣ（Personal Computer）やノートＰＣ等の情報処理装置であってもよい。

【0013】

決済サーバ１００及び証券サーバ２００は、各利用者Ｕの端末装置１０と連携し、各利用者Ｕの端末装置１０に対して、各種アプリケーション（以下、アプリ）等に対するＡＰＩ（Application Programming Interface）サービス等と、各種データを提供する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。

【0014】

決済サーバ１００は、第１事業者（決済サービス事業者）により運営・管理され、端末装置１０を用いた決済（電子決済）のためのアプリケーション（決済アプリ）を提供する。

【0015】

証券サーバ２００は、第２事業者（証券会社）により運営・管理され、決済サーバ１００と連携し、決済アプリ内で起動するアプリケーション（ミニアプリ）として、有価証券の売買を行うことができる資産運用ミニアプリを提供する。

【0016】

証券サーバ２００は、有価証券の売買に関与する情報処理装置である。例えば、証券サーバ２００は、金額指定による有価証券の売却申し込みを受け付けると、有価証券の基準価格に基づいて顧客が有数する有価証券のうち売却対象となる有価証券の数、すなわち売却数量を算出し、売却代金を利用者Ｕに支払う情報処理装置である。売却代金の支払いは、例えばオンラインでのインターネットバンキングや電子決済等により行われる。なお、当該有価証券は、利用者Ｕが保有する有価証券であって、売却申し込みから売却代金の受け渡しまでに所定の日数（例えば２営業日）を要する有価証券である。

【0017】

本実施形態では、第１事業者（決済サービス事業者）と第２事業者（証券会社）とがいる場合に、ユーザが第１事業者の決済アプリ内の資産運用ミニアプリ経由で第２事業者が扱う有価証券の売却指示を第２事業者に出すと、第１事業者が先にユーザに電子マネーを渡して、後日、第２事業者から第１事業者に代金を支払う。

【0018】

なお、証券会社は、金融機関の一例に過ぎない。有価証券を取り扱う銀行等の他の金融機関であってもよい。すなわち、証券会社は、有価証券の売買を仲介する金融機関であればよい。また、有価証券は、金融商品の一例に過ぎない。有価証券は、株式、債券、手形、小切手等を含む。投資信託（投信：ファンド）やＥＴＦ（Exchange Traded Funds）、保険商品等であってもよい。

【0019】

なお、本実施形態では、便宜上、端末装置１０、決済サーバ１００及び証券サーバ２００の動作を、それぞれユーザ、決済サービス事業者及び証券会社の動作として説明する場合がある。

【0020】

〔１－１．端末装置１０を用いた決済〕
ここで、実施形態に係る情報処理に先立ち、端末装置１０を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗に配置された２次元コード（ＱＲコード（登録商標））であって、店舗を識別する店舗識別情報を示す２次元コードを用いて、利用者Ｕが端末装置１０を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者が任意の端末装置１０を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、ＱＲコード（登録商標）のみならず、バーコードや所定のマーク、番号等であってもよい。

【0021】

例えば、利用者Ｕが店舗にて各種の商品やサービスといった決済対象（取引対象）の利用や購入に伴う決済を行う場合、利用者Ｕは、端末装置１０にインストールされた決済用のアプリケーション（決済アプリ）を起動する。そして、利用者Ｕは、決済アプリを介して、店舗に設置された店舗識別情報を撮影する。このような場合、端末装置１０は、決済対象の価格を入力するための画面を表示し、利用者Ｕ或いは店舗の店員Ｍから決済金額の入力を受け付ける。そして、端末装置１０は、利用者Ｕを識別する利用者識別情報と、店舗識別情報（若しくは、店舗識別情報が示す情報、すなわち、店舗を示す情報（例えば、店舗ＩＤ（Identifier）））と、決済金額とを示す決済情報を決済サーバ１００へと送信する。

【0022】

このような場合、決済サーバ１００は、利用者識別情報が示す利用者Ｕの口座から、店舗識別情報が示す店舗の口座へと、決済金額が示す額の電子マネーを移行させる。そして、決済サーバ１００は、決済が完了した旨の通知を端末装置１０へと送信する。このような場合、端末装置１０は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。

【0023】

なお、端末装置１０を用いた決済は、上述した処理に限定されるものではない。例えば、端末装置１０を用いた決済は、店舗に設置された店舗端末を用いたものであってもよい。例えば、端末装置１０は、利用者Ｕを識別するための利用者識別情報を画面上に表示させる。このような場合、店舗に設置された店舗端末は、端末装置１０に表示された利用者識別情報を読み取り、利用者識別情報（若しくは、利用者識別情報が示す情報、すなわち、利用者Ｕを示す情報（例えば、利用者ＩＤ））と、決済金額と、店舗を識別する情報とを示す決済情報を決済サーバ１００へと送信する。このような場合、決済サーバ１００は、利用者識別情報が示す利用者Ｕの口座から、店舗の口座へと、決済金額が示す額の電子マネーを移行させ、店舗の店舗端末或いは端末装置１０に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。

【0024】

また、端末装置１０を用いた決済は、利用者Ｕが予め電子マネーをチャージした口座から店舗の口座へと電子マネーを移行させる処理のみならず、例えば、利用者Ｕが予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、端末装置１０は、店舗の口座に対して決済金額の電子マネーを移行させるとともに、利用者Ｕのクレジットカードの運用会社に対し、決済金額を請求してもよい。

【0025】

端末装置１０を用いた決済では、決済アプリが利用者口座から決済額分の電子マネーを引き出して、加盟店の売上情報として管理する（加盟店口座への入金とは異なる）。また、所定のタイミングで、売上情報をもとに、加盟店の銀行口座に、売上から管理手数料を減算した額の現金を入金する。なお、利用者口座から、加盟店が管理する加盟店の電子マネー口座に電子マネーを入金してもよく、入金時あるいは所定のタイミングで、手数料を加盟店が管理する加盟店口座から取得してもよい。さらに、決済アプリに関して利用者Ｕに提供されるクーポンの原資が加盟店負担であれば、銀行口座に現金を入金する際、もしくは、加盟店の口座に電子マネーを入金する際等に、負担分の現金若しくは電子マネーを減算して提供する。

【0026】

現状、上述した決済手段や決済サービスでは、加盟店は電子マネー残高を扱うことはなく、上述した決済手段や決済サービスでの加盟店ごとの売上は決済サーバ上で管理している。このとき、売上を電子マネー残高で加盟店口座に送金しておらず、現金にして銀行口座に入金している。入金の際に、クーポンの原資が加盟店負担なら、売上からクーポンの原資の分を差し引いた額を振り込む。

【0027】

なお、上述した決済手段や決済サービスは、商品の購入や役務の提供に対する対価の提供（債務の精算）のためのものに限定されるものではない。例えば、上述した決済手段や決済サービスは、複数の利用者が有する口座間の送金に関する機能を有していてもよい。すなわち、上述した決済手段や決済サービスは、利用者や店舗等、電子マネーの所有者と紐づく任意の所有者の口座間における電子マネーの送受信を制御するサービスであればよい。すなわち、実施形態に係る決済手段や決済サービスは、電子マネーのやり取りを実現するための各種制御（電子マネーを介した各種の口座間送金制御のみならず、電子マネー口座と銀行口座間のやり取りに関する制御や、分割、ボーナス払いに伴う処理といった各種債権処理、その他電子マネーを含む財産のやり取りに関する各種制御）を実行する取引手段や取引サービスであれば、任意の態様で提供されるものであってもよい。また、このような取引手段や取引サービスが実現する各種の制御には、決済に関する制御と送金に関する制御の両方が含まれていてもよく、いずれか一方のみが含まれていてもよい。すなわち、「取引」とは、電子マネーに関する「決済」のみならず、電子マネーの「送金」やその他各種の処理をも含む概念である。すなわち、決済サーバ１００は、任意の所有者間における電子マネーのやり取りを制御する取引手段を実現する情報処理装置であってもよい。

【0028】

例えば、決済サーバ１００は、決済や送金等といった電子マネーの取引に関する取引情報が生じると、取引情報に基づいて利益を受け取るか否かの選択を利用者から受け付け、利用者が利益を受け取る場合は、利用者に対して取引を行ったことによる利益を付与する。また、決済サーバ１００は、利益を受け取らない場合は、取引サービスにおける利用者の行動に基づき、より有利な利益を利用者に付与することとなる。

【0029】

〔１－２．債権譲渡による有価証券売却取引当日の売却代金受領スキーム〕
次に、図１を参照して、債権譲渡（ファクタリング）により有価証券の売却取引当日の売却代金を電子マネーで受領するスキームについて説明する。本実施形態では、資産運用ミニアプリの提供に向けての資金決済に関する仕組みとして、ユーザが有価証券売却取引当日に電子マネーを受領できる仕組みを実現するスキームを策定する。例えば、通常２営業日以降が受渡日（売却資金の着金）となる有価証券取引において、債権譲渡（ファクタリング）により取引当日に電子マネーチャージを行うスキームを策定する。

【0030】

図１に示すように、利用者Ｕの端末装置１０は、事前に、資産運用ミニアプリを介して、利用者Ｕが証券会社に対して有する債権を決済サービス事業者へ譲渡する（ステップＳ１）。すなわち、債権譲渡（ファクタリング）を行う。

【0031】

本実施形態では、利用者Ｕの端末装置１０は、資産運用ミニアプリを介して、個々の取引について個別に債権譲渡するのではなく、全ての取引について一括して債権譲渡するように決済サービス事業者の決済サーバ１００と事前に契約を締結する。これにより、利用者Ｕの端末装置１０は、資産運用ミニアプリを介した全ての取引について、取引当日である「Ｔ日」から２営業日後の「Ｔ＋２日目」に発生する証券口座からの出金に係る債権を決済サービス事業者へ譲渡したことになる。ここでは、取引当日を「Ｔ日」として表す。

【0032】

なお、実際には、利用者Ｕの端末装置１０は、資産運用ミニアプリを介して、個々の取引について取引の度に個別に債権譲渡するようにしてもよい。

【0033】

次に、利用者Ｕの端末装置１０は、取引当日である「Ｔ日」に、資産運用ミニアプリでの利用者Ｕの操作に応じて、証券会社の証券サーバ２００に有価証券の売却を指示する（ステップＳ２）。本実施形態では、自動出金により、電子マネー口座と証券口座との間を資金が自動で移動する。

【0034】

本実施形態では、有価証券の売却は、相対取引によるリアルタイム処理で行われる。すなわち、証券取引所などの市場を通さずに、売り手と買い手が当事者同士で価格や売買数量などを決めて行う。また、利用者Ｕは、資産運用ミニアプリ上において、保有する有価証券の銘柄ごとの売却数量や売却金額を指定することができる。すなわち、利用者Ｕは、保有する有価証券の銘柄ごとの所有分（株数／口数）の全量を一括で売却する場合に限らず、任意の金額を指定して売却することもできる。なお、有価証券の売却は、市場取引による成行注文や指値注文で行われてもよい。成行注文の場合には、売買が成立して金額が決まった時に売却金額（売却代金）が決定する。指値注文の場合には、指定した額で売買が成立した時に売却金額が決定する。

【0035】

次に、証券会社の証券サーバ２００は、取引当日である「Ｔ日」に、上記ステップＳ２の有価証券の売却代金に関する情報を決済サービス事業者の決済サーバ１００に送信する（ステップＳ３）。本実施形態では、利用者Ｕの端末装置１０の資産運用ミニアプリで有価証券の売買が行われると、利用者Ｕを示すユーザＩＤ（UID）とチャージ金額とが、証券会社の証券サーバ２００から決済サービス事業者の決済サーバ１００に送信される。

【0036】

次に、決済サービス事業者の決済サーバ１００は、取引当日である「Ｔ日」に、上記ステップＳ３の有価証券の売却代金に関する情報に基づき、上記ステップＳ２の有価証券の売却代金に相当する電子マネーを利用者Ｕの電子マネー口座にチャージする（ステップＳ４）。このとき、決済サーバ１００は、有価証券の売却代金に相当する電子マネーを、決済サービス事業者の電子マネー口座から利用者Ｕの電子マネー口座に移行させる（入金する）ようにしてもよい。

【0037】

なお、本実施形態では、23:59に売却して0:01にチャージされるような日付をまたぐタイムラグが生じた場合であっても、「当日」として処理する。例えば、翌日の深夜等の時間帯にチャージが完了する場合、その深夜等の時間帯は、当日の２５時、２６時等として扱う。

【0038】

また、本実施形態では、説明の便宜上、利用者Ｕへの電子マネーのチャージ金額は、有価証券の売却代金と同額であるものとして説明する。なお、実際には、利用者Ｕへの電子マネーのチャージ金額は、有価証券の売却代金から手数料等を差し引いた金額や、有価証券の売却代金にキャンペーン等でポイントを追加した金額であってもよい。すなわち、厳密には、利用者Ｕへの電子マネーのチャージ金額は、有価証券の売却代金と同額でなくてもよい。また、有価証券の売却代金自体が、手数料等を差し引いた金額やキャンペーン等でポイントを追加した金額であってもよい。証券会社の証券サーバ２００は、決済サービス事業者の決済サーバ１００に売却額と手数料とを通知してもよい。また、証券会社の証券サーバ２００は、資産運用ミニアプリを介して、利用者Ｕの端末装置１０に売却額と手数料とを通知してもよい。このような場合、決済サービス事業者の決済サーバ１００は、売却額から証券会社の手数料を減算した額、もしくは、この額からさらに決済サービス事業者の手数料を除いた額を利用者Ｕの電子マネー口座にチャージしてもよい。

【0039】

また、電子マネーのチャージ代金（電子マネーに交換する現金等）は、後日（有価証券の売却代金の出金が可能になる日以降）支払いが行われるものとする。すなわち、ここでは電子マネーのみ先払いし、チャージ代金は後払いとする。形式的には、証券会社が決済サービス事業者から電子マネーを一時的に借りる（立て替えてもらう）形であってもよい。例えば、証券会社の証券サーバ２００は、決済サービス事業者の決済サーバ１００に対して、利用者Ｕの電子マネー口座への電子マネーのチャージの指示のみ行い、後日そのチャージ代金を支払うようにしてもよい。チャージ代金の支払いの詳細については後述する。

【0040】

次に、決済サービス事業者の決済サーバ１００は、上記ステップＳ４の利用者Ｕへの電子マネーのチャージ代金を証券会社の証券サーバ２００に請求するための処理をする（ステップＳ５）。例えば、決済サービス事業者の決済サーバ１００は、取引当日である「Ｔ日」に行われた全ての取引をまとめて、日次に、上記ステップＳ４の利用者Ｕへの電子マネーのチャージ代金を集計した金額を証券会社の証券サーバ２００に請求するための処理をしてもよい。なお、実際には、証券サーバ２００に請求するための処理をするタイミングは、取引当日である「Ｔ日」以降であってもよい。

【0041】

次に、決済サービス事業者の決済サーバ１００は、取引当日から２営業日後の「Ｔ＋２日目」以降に、上記ステップＳ１の債権譲渡に基づき、上記ステップＳ４のチャージ代金の相当額を証券会社の証券サーバ２００に請求する（ステップＳ６）。すなわち、決済サーバ１００は、取引当日から２営業日後の「Ｔ＋２日目」以降に、電子マネーのチャージ分に相当する現金の入金を請求する。この際、決済サーバ１００は、証券サーバ２００に対して、ユーザの識別情報も送信する。証券サーバ２００は、決済サーバ１００から「ユーザの識別情報及び電子マネーのチャージ代金（チャージ代金の相当額）」を含む請求情報を受信して保存する。

【0042】

なお、チャージ代金の相当額を証券会社の証券サーバ２００に請求するタイミング自体は、取引当日である「Ｔ日」又はそれ以降（２営業日後より前を含む）であってもよい。すなわち、有価証券の売却代金に相当する電子マネーを利用者Ｕの電子マネー口座にチャージした後であればよい。例えば、決済サーバ１００は、取引当日である「Ｔ日」又はそれ以降に、チャージ代金の相当額を証券会社の証券サーバ２００に請求してもよい。すなわち、決済サーバ１００は、取引当日である「Ｔ日」又はそれ以降に、電子マネーのチャージ分に相当する現金の入金を請求してもよい。

【0043】

次に、証券会社の証券サーバ２００は、取引当日から２営業日後の「Ｔ＋２日目」に、上記ステップＳ２の有価証券の売却代金が証券会社へ着金したことを確認する（ステップＳ７）。例えば、証券サーバ２００は、保存した請求情報に含まれるユーザの識別情報に応じたユーザの証券口座への着金を検知する。すなわち、証券会社の証券サーバ２００は、取引当日から２営業日後の「Ｔ＋２日目」に、上記ステップＳ２の有価証券の売却代金が証券会社の口座（利用者Ｕの証券口座）へ着金したことを確認する。

【0044】

次に、証券会社の証券サーバ２００は、取引当日から２営業日後の「Ｔ＋２日目」以降に、決済サービス事業者の決済サーバ１００からの請求に基づいて、上記ステップＳ４のチャージ代金の相当額を支払う（ステップＳ８）。例えば、証券サーバは、ユーザの証券口座への着金を検知した場合、保存した請求情報に含まれるチャージ代金を、着金を検知したユーザの証券口座から決済サービス事業者の銀行口座へ入金する。すなわち、証券サーバ２００は、決済サーバ１００からの請求に基づいて、電子マネーのチャージ分に相当する現金を決済サービス事業者の銀行口座に入金する。なお、「銀行口座に入金する」とは、外部の銀行サーバ（図示省略）への入金や送金の指示等、銀行口座に入金するための処理を行うことを示す。本実施形態では、便宜上、簡略に「銀行口座に入金する」と記載する。

【0045】

例えば、証券会社の証券サーバ２００は、有価証券の売却代金が利用者Ｕの証券口座に着金すると同時に、その着金した額のうち電子マネーのチャージ分に相当する額を電子マネーのチャージ代金として決済サービス事業者の銀行口座に入金する。すなわち、証券サーバ２００は、上記ステップＳ４で利用者Ｕの電子マネー口座にチャージした電子マネーのチャージ代金を、取引当日から２営業日後の「Ｔ＋２日目」以降に、証券会社の銀行口座からではなく、着金があった利用者Ｕの証券口座から決済サービス事業者の銀行口座に入金する。

【0046】

そして、証券会社の証券サーバ２００は、決済サービス事業者の銀行口座に入金した際（又はその後）、決済サービス事業者の銀行口座に入金したことを決済サービス事業者の決済サーバ１００に通知する。なお、実際には、証券会社からの入金を確認した銀行の銀行サーバ（図示省略）が決済サービス事業者の決済サーバ１００に証券会社からの入金があったことを通知してもよい。決済サービス事業者の銀行口座は、決済サービス事業者と同一の企業グループの銀行（又は業務提携している銀行）に開設された銀行口座であってもよい。また、銀行口座に限らず、他の金融機関の口座であってもよい。

【0047】

このとき、決済サービス事業者の決済サーバ１００は、証券会社の証券サーバ２００からの通知（入金通知）を受けて、決済サービス事業者の銀行口座への入金を確認する。そして、決済サーバ１００は、決済サービス事業者の銀行口座への入金が確認できた場合、上記ステップＳ４のチャージ代金の相当額を受領したと判断する。なお、実際には、決済サーバ１００は、証券会社の証券サーバ２００からの通知（入金通知）を受けた時点で、上記ステップＳ４のチャージ代金の相当額を受領したと判断してもよい。

【0048】

通常、証券会社での有価証券取引においては取引日から２営業日後の「受渡日」に証券・代金の授受が行われ、売却の場合は顧客が受渡日まで売却代金の証券口座での受領を待つ必要がある。本実施形態に係る債権譲渡（ファクタリング）を活用したスキームにおいては、電子決済サービスのユーザが資産運用ミニアプリを利用して行った有価証券の売却取引当日に売却代金を電子マネーにて受領し、取引当日より電子マネーとして利用できる。

【0049】

本実施形態において、有効な債権譲渡（ファクタリング）として認められる事項として、当事者間の主観的意図を示すものとしての契約締結や、その主観的意図を裏付ける客観的事実、会計上債権譲渡を前提とした取扱い等が挙げられる。

【0050】

当事者間の主観的意図を示すものとしての契約締結として、決済サービス事業者－証券会社間については、電子マネーの発行に係る業務委託契約（ファクリングスキームを踏まえた内容）を締結する。決済サービス事業者－ユーザ間については、決済サービス利用規約（ファクタリングスキームへの個別特約）を締結する。証券会社－ユーザ間については、証券会社ミニアプリ利用規約（ファクタリングスキームへの個別同意含む）を締結する。

【0051】

主観的意図を裏付ける客観的事実として、特にポイントとなる要素は、債権の回収不能等に係る危険及び経済的利益が譲受人に移転している点（買戻特約、求償合意等が譲渡人と譲受人との間でなされている場合は消極の評価要素となる）、債権の現実的な支配権が譲受人に移転している点、債権管理や回収等を譲渡人が行っている点（回収等を譲渡人が行っている場合は消極の評価要素となる場合は消極の評価要素となる）、対抗要件を具備している点。対抗要件を具備している点、債権譲渡債権譲渡の対価が相当なものである点、対価が相当なものである点、等である。

【0052】

これにより、資産運用ミニアプリによる有価証券取引の利便性向上が期待できる。また、証券会社が顧客である利用者に対して有価証券の売却代金を「電子マネー」で即日払いするための適法（合法的）な仕組みを提供できる。また、決済アプリの利用頻度の向上が期待できる。

【0053】

〔１－３．資産運用ミニアプリの提供サービス〕
図２は、資産運用ミニアプリの提供サービスの一例を示す概念図である。図２に示すように、証券会社が資産運用ミニアプリにて提供するサービスは、証券会社口座の開設（証券会社による本人確認（eKYC：electronic Know Your Customer）、法定書面の交付含む）、電子マネーによる有価証券取引、資産残高推移、資産割合、お知らせ等の情報提供等である。

【0054】

証券会社は、資産運用サービスを資産運用ミニアプリで提供する。このとき、証券会社は、資産運用ミニアプリ用に取扱商品を選定する。資産運用ミニアプリでは、電子マネーによる有価証券の買付・出金（売却時）を可能とする。本実施形態では、電子マネー以外の決済手段は導入しない。なお、電子マネー金額上限（例えば、１００万円）を超える出金の場合のみ金融機関口座への出金も可能とする。

【0055】

電子マネーのチャージには一日の上限がある。通常、２４時間で５０万円、３０日で２００万円が上限になる。滞留上限が１００万円である。このため、チャージ後の残高が１００万円になるように調整する。例えば、滞留上限が１００万円あるときに、販売をすると、１００万円を超えた分は、販売額は銀行口座に振り込むように表示を出してもよい。また、残高が９０万円あるときに３０万円が売却益ならば、売却益である３０万円のうち、２０万円（又はそれ以上）を銀行口座に振り込むようにする。あるいは、売却益である３０万円の全額を銀行口座に振り込むようにする。いずれでもよい。また、滞留上限を超えないように、有価証券の売買金額の上限を設けてもよい。

【0056】

銀行振り込みの場合は、取引当日から２営業日後の「Ｔ＋２日目」以降に、証券口座から銀行口座への振り込みでもよい。また、電子マネー口座から銀行口座への振り込みでもよい。例えば、電子マネー口座に一旦チャージして、滞留上限を超えた分を銀行口座に振り込むようにしてもよい。電子マネー口座から滞留上限を超えた分が証券口座に払い戻されて、証券口座から銀行口座に振り込むようにしてもよい。銀行については、ユーザが証券会社に登録している銀行ならどこでもよい。銀行振り込みは、即時でもよいし、取引当日から２営業日後でもよい。

【0057】

〔１－４．資産運用ミニアプリの資金フロー〕
図３は、決済サービス事業者－証券会社間での資産運用ミニアプリの資金フローの一例を示す概念図である。図３に示すように、決済サービス事業者－証券会社間での資産運用ミニアプリの資金フローでは、決済サービス事業者は、証券会社から決済サービス事業者への金融仲介業に関する業務委託から生じるプロフィットシェア（profit share）による分配金を収入として得る（毎月）。例えば、証券会社がユーザによる有価証券の取引・保有から得るプロフィット（利益）の一部を決済サービス事業者が受領する。

【0058】

また、ユーザの電子マネーによる有価証券買付及び売却代金合計の授受を行う（毎日）。例えば、決済サービス事業者から証券会社へ、電子マネーによる有価証券の買付代金合計の振込を行う。また、証券会社から決済サービス事業者へ、電子マネーによる有価証券の売却代金合計の振込を行う。なお、ユーザの有価証券の売却代金合計の振込については、ユーザから決済サービス事業者への債権譲渡（ファクタリング）に基づく。

【0059】

図４は、ユーザ－決済サービス事業者－証券会社間での資産運用ミニアプリの資金フローの一例を示す概念図である。すなわち、ユーザの視点から見た資金フローを示す。図４に示すように、ユーザ－決済サービス事業者－証券会社間での資産運用ミニアプリの資金フローでは、決済アプリ内の資産運用ミニアプリでの買付代金分の電子マネー支払いや、売却代金分の電子マネー受領（取引当日）を行う。

【0060】

ユーザは、買付をすれば自動的に電子マネーから減算、売却をすれば自動的に電子マネーが加算される。通常であれば、現金での証券口座への入金手続きや証券口座からの出金手続きが行われるが、本実施形態では、電子マネーを使用するため、現金での証券口座への入金手続きや証券口座からの出金手続きは行わない。すなわち、銀行口座から証券口座への入金手続きや証券口座から銀行口座への出金手続きは行わない。取引当日の売却代金分の電子マネー受領については、図１に示すような債権譲渡（ファクタリング）のスキームに基づく。

【0061】

〔１－５．資産運用ミニアプリの概要〕
図５は、資産運用ミニアプリの概要を示す図である。図５に示すように、資産運用ミニアプリの対象ユーザとして、決済サービス事業者が提供する決済アプリの利用者であって、証券会社に証券口座を有する顧客を想定している。対象商品は有価証券であり、有価証券の買付・出金（売却）には電子マネーを使用する。有価証券の買付や売却の受付時間は２４時間、３６５日対応可能であるものとし、電子マネーによる入金・買付タイミングや売却・出金タイミングはリアルタイム（Ｔ＋０日目）とする。すなわち、取引当日「Ｔ日」である。電子マネーの利用可能単位は、買付の場合は「１００円以上、１円単位」であり、売却の場合は「１円以上、１円単位」である。また、取引上限は、電子マネーの上限に準ずるものとする。

【0062】

〔１－６．事業者の役務・業、収入〕
（決済サービス事業者の役務と業）
決済サービス事業者は、証券会社を所属金融機関とする金融商品仲介業者として、資産運用ミニアプリを経由し証券会社へ顧客の送客を行う。また、証券会社にミニアプリプラットフォームを提供する。

【0063】

（決済サービス事業者の収入）
決済サービス事業者は、資産運用ミニアプリ経由で証券会社に口座開設した顧客による有価証券取引・投信の信託報酬から証券会社が得た収益の一部をプロフィットシェアとして収入を得る。

【0064】

（証券会社の役務と業）
証券会社は、金融商品仲介業者としての決済サービス事業者の所属金融機関（第一種金融商品取引業者）として、決済サービス事業者から資産運用ミニアプリを経由し送客を受け証券口座開設や有価証券取引サービス、関連業務を提供する。また、証券会社は、ミニアプリ加盟店として顧客にミニアプリを提供する。

【0065】

（証券会社の収入）
証券会社は、資産運用ミニアプリを経由し証券会社株式会社に口座開設した顧客による有価証券取引・投信の信託報酬から収入を得る。

【0066】

〔２．情報処理システムの構成例〕
次に、図６を用いて、実施形態に係る決済サーバ１００が含まれる情報処理システム１の構成について説明する。図６は、実施形態に係る情報処理システム１の構成例を示す図である。図６に示すように、実施形態に係る情報処理システム１は、端末装置１０と決済サーバ１００と証券サーバ２００を含む。これらの各種装置は、ネットワークＮを介して、有線又は無線により通信可能に接続される。ネットワークＮは、例えば、ＬＡＮ（Local Area Network）や、インターネット等のＷＡＮ（Wide Area Network）である。

【0067】

また、図６に示す情報処理システム１に含まれる各装置の数は図示したものに限られない。例えば、図６では、図示の簡略化のため、端末装置１０を１台のみ示したが、これはあくまでも例示であって限定されるものではなく、２台以上であってもよい。

【0068】

端末装置１０は、利用者Ｕによって使用される情報処理装置である。例えば、端末装置１０は、スマートフォンやタブレット端末等のスマートデバイス、フィーチャーフォン、ＰＣ（Personal Computer）、ＰＤＡ（Personal Digital Assistant）、通信機能を備えたゲーム機やＡＶ機器、カーナビゲーションシステム、スマートウォッチやヘッドマウントディスプレイ等のウェアラブルデバイス（Wearable Device）、スマートグラス等である。

【0069】

また、かかる端末装置１０は、ＬＴＥ（Long Term Evolution）、４Ｇ（4th Generation）、５Ｇ（5th Generation：第５世代移動通信システム）等の無線通信網や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（Local Area Network）等の近距離無線通信を介してネットワークＮに接続し、決済サーバ１００と通信することができる。

【0070】

決済サーバ１００及び証券サーバ２００は、例えばＰＣやサーバ装置、あるいはメインフレーム又はワークステーション等である。なお、決済サーバ１００及び証券サーバ２００は、クラウドコンピューティングにより実現されてもよい。

【0071】

〔３．端末装置の構成例〕
次に、図７を用いて、端末装置１０の構成について説明する。図７は、端末装置１０の構成例を示す図である。図７に示すように、端末装置１０は、通信部１１と、表示部１２と、入力部１３と、測位部１４と、センサ部２０と、制御部３０（コントローラ）と、記憶部４０とを備える。

【0072】

（通信部１１）
通信部１１は、ネットワークＮ（図６参照）と有線又は無線で接続され、ネットワークＮを介して、決済サーバ１００との間で情報の送受信を行う。例えば、通信部１１は、ＮＩＣ（Network Interface Card）やアンテナ等によって実現される。

【0073】

（表示部１２）
表示部１２は、位置情報等の各種情報を表示する表示デバイスである。例えば、表示部１２は、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）や有機ＥＬディスプレイ（Organic Electro-Luminescent Display）である。また、表示部１２は、タッチパネル式のディスプレイであるが、これに限定されるものではない。

【0074】

（入力部１３）
入力部１３は、利用者Ｕから各種操作を受け付ける入力デバイスである。例えば、入力部１３は、文字や数字等を入力するためのボタン等を有する。なお、入力部１３は、入出力ポート（I/O port）やＵＳＢ（Universal Serial Bus）ポート等であってもよい。また、表示部１２がタッチパネル式のディスプレイである場合、表示部１２の一部が入力部１３として機能する。また、入力部１３は、利用者Ｕから音声入力を受け付けるマイク等であってもよい。マイクはワイヤレスであってもよい。

【0075】

（測位部１４）
測位部１４は、ＧＰＳ（Global Positioning System）の衛星から送出される信号（電波）を受信し、受信した信号に基づいて、自装置である端末装置１０の現在位置を示す位置情報（例えば、緯度及び経度）を取得する。すなわち、測位部１４は、端末装置１０の位置を測位する。なお、ＧＰＳは、ＧＮＳＳ（Global Navigation Satellite System）の一例に過ぎない。

【0076】

また、測位部１４は、ＧＰＳ以外にも、種々の手法により位置を測位することができる。例えば、測位部１４は、位置補正等のための補助的な測位手段として、下記のように、端末装置１０の様々な通信機能を利用して位置を測位してもよい。

【0077】

（Ｗｉ－Ｆｉ測位）
例えば、測位部１４は、端末装置１０のＷｉ－Ｆｉ（登録商標）通信機能や、各通信会社が備える通信網を利用して、端末装置１０の位置を測位する。具体的には、測位部１４は、Ｗｉ－Ｆｉ通信等を行い、付近の基地局やアクセスポイントとの距離を測位することにより、端末装置１０の位置を測位する。

【0078】

（ビーコン測位）
また、測位部１４は、端末装置１０のＢｌｕｅｔｏｏｔｈ（登録商標）機能を利用して位置を測位してもよい。例えば、測位部１４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）機能によって接続されるビーコン（beacon）発信機と接続することにより、端末装置１０の位置を測位する。

【0079】

（地磁気測位）
また、測位部１４は、予め測定された構造物の地磁気のパターンと、端末装置１０が備える地磁気センサとに基づいて、端末装置１０の位置を測位する。

【0080】

（ＲＦＩＤ測位）
また、例えば、端末装置１０が駅改札や店舗等で使用される非接触型ＩＣカードと同等のＲＦＩＤ（Radio Frequency Identification）タグの機能を備えている場合、もしくはＲＦＩＤタグを読み取る機能を備えている場合、端末装置１０によって決済等が行われた情報とともに、使用された位置が記録される。測位部１４は、かかる情報を取得することで、端末装置１０の位置を測位してもよい。また、位置は、端末装置１０が備える光学式センサや、赤外線センサ等によって測位されてもよい。

【0081】

測位部１４は、必要に応じて、上述した測位手段の一つ又は組合せを用いて、端末装置１０の位置を測位してもよい。

【0082】

（センサ部２０）
センサ部２０は、端末装置１０に搭載又は接続される各種のセンサを含む。なお、接続は、有線接続、無線接続を問わない。例えば、センサ類は、ウェアラブルデバイスやワイヤレスデバイス等、端末装置１０以外の検知装置であってもよい。図７に示す例では、センサ部２０は、加速度センサ２１と、ジャイロセンサ２２と、気圧センサ２３と、気温センサ２４と、音センサ２５と、光センサ２６と、磁気センサ２７と、画像センサ（カメラ）２８とを備える。

【0083】

なお、上記した各センサ２１～２８は、あくまでも例示であって限定されるものではない。すなわち、センサ部２０は、各センサ２１～２８のうちの一部を備える構成であってもよいし、各センサ２１～２８に加えてあるいは代えて、湿度センサ等その他のセンサを備えてもよい。

【0084】

加速度センサ２１は、例えば、３軸加速度センサであり、端末装置１０の移動方向、速度、及び、加速度等の端末装置１０の物理的な動きを検知する。ジャイロセンサ２２は、端末装置１０の角速度等に基づいて３軸方向の傾き等の端末装置１０の物理的な動きを検知する。気圧センサ２３は、例えば端末装置１０の周囲の気圧を検知する。

【0085】

端末装置１０は、上記した加速度センサ２１やジャイロセンサ２２、気圧センサ２３等を備えることから、これらの各センサ２１～２３等を利用した歩行者自律航法（ＰＤＲ：Pedestrian Dead-Reckoning）等の技術を用いて端末装置１０の位置を測位することが可能になる。これにより、ＧＰＳ等の測位システムでは取得することが困難な屋内での位置情報を取得することが可能になる。

【0086】

例えば、加速度センサ２１を利用した歩数計により、歩数や歩くスピード、歩いた距離を算出することができる。また、ジャイロセンサ２２を利用して、利用者Ｕの進行方向や視線の方向、体の傾きを知ることができる。また、気圧センサ２３で検知した気圧から、利用者Ｕの端末装置１０が存在する高度やフロアの階数を知ることもできる。

【0087】

気温センサ２４は、例えば端末装置１０の周囲の気温を検知する。音センサ２５は、例えば端末装置１０の周囲の音を検知する。光センサ２６は、端末装置１０の周囲の照度を検知する。磁気センサ２７は、例えば端末装置１０の周囲の地磁気を検知する。画像センサ２８は、端末装置１０の周囲の画像を撮像する。

【0088】

上記した気圧センサ２３、気温センサ２４、音センサ２５、光センサ２６及び画像センサ２８は、それぞれ気圧、気温、音、照度を検知したり、周囲の画像を撮像したりすることで、端末装置１０の周囲の環境や状況等を検知することができる。また、端末装置１０の周囲の環境や状況等から、端末装置１０の位置情報の精度を向上させることが可能になる。

【0089】

（制御部３０）
制御部３０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ、入出力ポート等を有するマイクロコンピュータや各種の回路を含む。また、制御部３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路等のハードウェアで構成されてもよい。制御部３０は、送信部３１と、受信部３２と、処理部３３とを備える。

【0090】

（送信部３１）
送信部３１は、例えば入力部１３を用いて利用者Ｕにより入力された各種情報や、端末装置１０に搭載又は接続された各センサ２１～２８によって検知された各種情報、測位部１４によって測位された端末装置１０の位置情報等を、通信部１１を介して決済サーバ１００へ送信することができる。

【0091】

（受信部３２）
受信部３２は、通信部１１を介して、決済サーバ１００から提供される各種情報や、決済サーバ１００からの各種情報の要求を受信することができる。

【0092】

（処理部３３）
処理部３３は、表示部１２等を含め、端末装置１０全体を制御する。例えば、処理部３３は、送信部３１によって送信される各種情報や、受信部３２によって受信された決済サーバ１００からの各種情報を表示部１２へ出力して表示させることができる。

【0093】

（記憶部４０）
記憶部４０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、光ディスク等の記憶装置によって実現される。かかる記憶部４０には、各種プログラムや各種データ等が記憶される。

【0094】

〔４．決済サーバの構成例〕
次に、図８を用いて、実施形態に係る決済サーバ１００の構成について説明する。図８は、実施形態に係る決済サーバ１００の構成例を示す図である。図８に示すように、決済サーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。

【0095】

（通信部１１０）
通信部１１０は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。また、通信部１１０は、ネットワークＮ（図６参照）と有線又は無線で接続される。

【0096】

（記憶部１２０）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ＨＤＤ、ＳＳＤ、光ディスク等の記憶装置によって実現される。図８に示すように、記憶部１２０は、取引情報データベース１２１を有する。

【0097】

（取引情報データベース１２１）
取引情報データベース１２１は、利用者Ｕの有価証券の売買に関する各種情報を記憶する。図９は、取引情報データベース１２１の一例を示す図である。図９に示した例では、取引情報データベース１２１は、「利用者」、「債権譲渡」、「有価証券」、「売却日」、「売却代金」、「チャージ」、「受渡日」、「代金請求」、「代金受領」といった項目を有する。

【0098】

「利用者」は、決済サービス事業者の顧客であって、証券会社の顧客である利用者Ｕを識別するための識別情報を示す。なお、利用者Ｕの識別情報は、利用者Ｕの連絡先（電話番号、メールアドレス等）であってもよいし、利用者Ｕの端末装置１０を識別するための識別情報であってもよい。

【0099】

また、「債権譲渡」は、有価証券の売却代金の出金に関する債権の譲渡の有無を示す。すなわち、債権譲渡（ファクタリング）が行われたか否かを示す。本実施形態では、全ての取引について一括して債権譲渡を行うものとしているが、実際には、個々の取引ごと（有価証券の売却ごと）に債権譲渡を行うようにしてもよい。すなわち、債権譲渡の有無は、有価証券ごとに判定してもよい。

【0100】

また、「有価証券」は、有価証券を識別するための識別情報を示す。なお、有価証券の識別情報は、有価証券の名前、証券コード等であってもよい。また、「売却日」は、利用者Ｕが有価証券の売却指示をした日を示す。すなわち、売却日は、有価証券の売却の約定日を示す。また、「売却代金」は、有価証券の売却代金（金額）を示す。

【0101】

また、「チャージ」は、利用者Ｕの電子マネー口座へのチャージの有無を示す。すなわち、債権譲渡（ファクタリング）に応じて、利用者Ｕの電子マネー口座へ有価証券の売却代金に相当する電子マネーがチャージされたか否かを示す。

【0102】

また、「受渡日」は、有価証券の売買後、買手が代金を支払い、売手が証券を相手側に渡して決済を行う受渡日（決済日）を示す。すなわち、受渡日は、利用者Ｕの証券口座から有価証券の売却代金の出金が可能となる日を示す。通常、受渡日は、取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）である。

【0103】

また、「代金請求」は、利用者Ｕの電子マネー口座へのチャージ代金の相当額の請求の有無を示す。すなわち、代金請求は、受渡日以降に、利用者Ｕの電子マネー口座へのチャージ代金の相当額について、証券会社への請求が行われたか否かを示す。

【0104】

また、「代金受領」は、利用者Ｕの電子マネー口座へのチャージ代金の相当額の受領の有無を示す。すなわち、代金受領は、受渡日以降に、利用者Ｕの電子マネー口座へのチャージ代金の相当額を、証券会社から受領したか否かを示す。

【0105】

例えば、図９に示す例において、利用者「Ｕ１」による債権譲渡（ファクタリング）が行われており、有価証券「Ａ１」の売却指示が売却日「2021/11/3」に行われ、利用者Ｕの電子マネー口座へ有価証券の売却代金「12,000円」に相当する電子マネーがチャージされ、その後、利用者Ｕの電子マネー口座へのチャージ代金の相当額について証券会社への請求が行われ、受渡日「2021/11/5」以降に、利用者Ｕの電子マネー口座へのチャージ代金の相当額を証券会社から受領したことを示す。

【0106】

ここで、図９に示す例では、「Ｕ１」及び「Ａ１」といった抽象的な値を用いて図示するが、「Ｕ１」及び「Ａ１」には、具体的な文字列や数値等の情報が記憶されるものとする。以下、他の情報に関する図においても、抽象的な値を図示する場合がある。

【0107】

なお、取引情報データベース１２１は、上記に限らず、目的に応じて種々の情報を記憶してもよい。例えば、取引情報データベース１２１は、証券会社を識別するための識別情報を記憶していてもよい。なお、証券会社の識別情報は、証券会社の名前、金融機関コード、支店コードや店番、支店番号等であってもよい。また、取引情報データベース１２１は、有価証券に関する各種情報を記憶してもよい。また、取引情報データベース１２１は、証券会社に関する各種情報を記憶してもよい。また、取引情報データベース１２１は、利用者Ｕのデモグラフィック（人口統計学的属性）、サイコグラフィック（心理学的属性）、ジオグラフィック（地理学的属性）、ベヘイビオラル（行動学的属性）等の属性に関する情報を記憶してもよい。例えば、取引情報データベース１２１は、氏名、家族構成、出身地（地元）、職業、職位、収入、資格、居住形態（戸建、マンション等）等の情報を記憶してもよい。

【0108】

（制御部１３０）
図８に戻り、説明を続ける。制御部１３０は、コントローラ（Controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等によって、決済サーバ１００の内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等の記憶領域を作業領域として実行されることにより実現される。図８に示す例では、制御部１３０は、取得部１３１と、受付部１３２と、チャージ処理部１３３と、代金要求部１３４と、代金受領部１３５とを有する。

【0109】

（取得部１３１）
取得部１３１は、利用者Ｕにより入力された検索クエリを取得する。例えば、取得部１３１は、利用者Ｕが検索エンジン等に検索クエリを入力してキーワード検索を行った際に、通信部１１０を介して、当該検索クエリを取得する。すなわち、取得部１３１は、通信部１１０を介して、利用者Ｕにより検索エンジンやサイト又はアプリの検索窓に入力されたキーワードを取得する。

【0110】

また、取得部１３１は、通信部１１０を介して、利用者Ｕ、証券会社及び有価証券に関する各種情報を取得する。例えば、取得部１３１は、利用者Ｕの端末装置１０から、利用者Ｕを示す識別情報（利用者ＩＤ等）や、利用者Ｕの位置情報、利用者Ｕの属性情報等を取得する。また、取得部１３１は、証券会社の証券サーバ２００から、証券会社の会社情報及び有価証券に関する詳細情報等を取得してもよい。そして、取得部１３１は、これらの情報を、記憶部１２０の取引情報データベース１２１に登録してもよい。

【0111】

（受付部１３２）
受付部１３２は、電子マネーによる決済を行う決済アプリを介してユーザが売却した金融商品（有価証券）の売却代金に関する債権の譲渡を受け付ける。本実施形態では、受付部１３２は、利用者Ｕの端末装置１０の資産運用ミニアプリを介して、金融商品の売却代金に関する債権譲渡（ファクタリング）の契約を締結する。このとき、受付部１３２は、個々の取引について個別に債権譲渡の契約を締結するのではなく、全ての取引について一括して債権譲渡する旨の契約を締結する。そして、受付部１３２は、その旨を、記憶部１２０の取引情報データベース１２１に登録する。

【0112】

なお、受付部１３２は、個々の取引について、電子マネーによる決済を行う決済アプリ内において、有価証券の売買を仲介する証券会社の資産運用ミニアプリを介してユーザが有価証券の売却指示を行う度に、有価証券の売却代金の出金に関する債権の譲渡を受け付けてもよい。そして、受付部１３２は、その旨を、記憶部１２０の取引情報データベース１２１に登録してもよい。

【0113】

すなわち、受付部１３２は、電子マネーでの決済サービスを提供する第１事業者（決済サービス事業者）の決済アプリ内のミニアプリのうち有価証券の売買を仲介する第２事業者（証券会社）の資産運用ミニアプリを介してユーザが有価証券の売却指示を行う度に、有価証券の売却代金の出金に関する債権の譲渡を受け付けてもよい。

【0114】

また、受付部１３２は、電子マネーによる決済を行う決済アプリを介してユーザが金融商品の売買を制御する外部サーバ（証券サーバ２００）に対して金融商品を売却する旨の指示を行った場合は、通信部１１０を介して、当該外部サーバから、金融商品の売却代金に関する情報を受け付ける。例えば、受付部１３２は、ユーザの端末装置１０の資産運用ミニアプリで有価証券の売買が行われると、資産運用ミニアプリと連携する外部サーバから、ユーザを示すユーザＩＤ（UID）とチャージ金額とを受信する。また、受付部１３２は、外部サーバから金融商品の売却代金に基づいた額の電子マネーのチャージ指示を受け付けてもよい。

【0115】

（チャージ処理部１３３）
チャージ処理部１３３は、金融商品の売却代金に関する情報に基づき、ユーザが金融商品を売却した当日（Ｔ日）に、金融商品の売却代金に相当する電子マネーを決済アプリにチャージする。 また、チャージ処理部１３３は、外部サーバからのチャージ指示に応じて、金融商品の売却代金に基づいた額の電子マネーを決済アプリにチャージしてもよい。そして、チャージ処理部１３３は、その旨を、記憶部１２０の取引情報データベース１２１に登録する。

【0116】

例えば、チャージ処理部１３３は、有価証券の売却代金の出金に関する情報に基づき、ユーザが有価証券の売却指示を行った当日（Ｔ日）に、有価証券の売却代金に相当する電子マネーを決済アプリのユーザの電子マネー口座にチャージする。

【0117】

すなわち、チャージ処理部１３３は、有価証券の売却代金の出金に関する情報に基づき、ユーザが有価証券の売却指示を行った当日（Ｔ日）に、有価証券の売却代金に相当する電子マネーを決済アプリのユーザの電子マネー口座にチャージする。

【0118】

（代金要求部１３４）
代金要求部１３４は、金融商品の売却代金に関する債権に基づき、通信部１１０を介して、外部サーバ（証券サーバ２００）に決済アプリへのチャージ代金の相当額を請求する。例えば、代金要求部１３４は、後日、金融商品の売却代金に関する債権に基づき、債務者の情報処理装置に対して決済アプリへのチャージ代金の相当額を請求する。また、代金要求部１３４は、ユーザが金融商品を売却した当日（Ｔ日）に、金融商品の売却代金に関する債権に基づき、債務者の情報処理装置に対して決済アプリへのチャージ代金を請求する。そして、代金要求部１３４は、その旨を、記憶部１２０の取引情報データベース１２１に登録する。

【0119】

例えば、代金要求部１３４は、有価証券の売却代金の出金に関する債権に基づき、通信部１１０を介して、証券会社の証券サーバ２００に対してユーザの電子マネー口座へのチャージ代金の相当額を請求する。このとき、代金要求部１３４は、有価証券の売却代金の出金が可能となる日（Ｔ＋２日目）以降に、有価証券の売却代金の出金に関する債権に基づき、証券会社の証券サーバ２００に対してユーザの電子マネー口座へのチャージ代金の相当額を請求する。

【0120】

すなわち、代金要求部１３４は、有価証券の売却代金の出金に関する債権に基づき、債権者である第１事業者（決済サービス事業者）として債務者である第２事業者（証券会社）に対してユーザの電子マネー口座へのチャージ代金の相当額を請求する。ここでは、代金要求部１３４は、第１事業者（決済サービス事業者）の決済サーバ１００として債務者である第２事業者（証券会社）の証券サーバ２００に対してユーザの電子マネー口座へのチャージ代金の相当額の支払い要求を送信する。なお、実際には、代金要求部１３４は、債務者である第２事業者（証券会社）の証券サーバ２００に対してユーザの電子マネー口座へのチャージ代金の相当額を支払うための仕組み（支払画面等）を提供してもよい。電子マネー口座へのチャージ代金の請求についても同様である。

【0121】

（代金受領部１３５）
代金受領部１３５は、通信部１１０を介して、債務者から決済アプリへのチャージ代金の相当額の支払いを受領する。例えば、代金受領部１３５は、後日、債務者からチャージ代金の相当額の支払いを受領する。そして、代金受領部１３５は、その旨を、記憶部１２０の取引情報データベース１２１に登録する。

【0122】

例えば、代金受領部１３５は、通信部１１０を介して、証券会社の証券サーバ２００からユーザの電子マネー口座へのチャージ代金の相当額の支払いの通知を受領する。例えば、証券サーバ２００は、チャージ代金を決済サービス事業者の銀行口座へ入金し、入金した旨の通知を決済サーバ１００へ送る。このため、代金受領部１３５は、証券サーバ２００から入金通知を受信する。このとき、代金受領部１３５は、有価証券の売却代金の出金が可能となる日（Ｔ＋２日目）以降に、証券会社の証券サーバ２００からチャージ代金の相当額の支払いの通知を受領する。

【0123】

すなわち、代金受領部１３５は、通信部１１０を介して、第２事業者（証券会社）の証券サーバ２００から、ユーザの電子マネー口座へのチャージ代金の相当額の支払いの通知を受領する。

【0124】

〔５．処理手順〕
次に、図１０を用いて実施形態に係る決済サーバ１００による処理手順について説明する。図１０は、実施形態に係る処理手順を示すフローチャートである。なお、以下に示す処理手順は、決済サーバ１００の制御部１３０によって繰り返し実行される。

【0125】

図１０に示すように、決済サーバ１００の受付部１３２は、事前に、電子マネーによる決済を行う決済アプリ内において、有価証券の売買を仲介する証券会社の資産運用ミニアプリを介してユーザが売却する有価証券の売却代金の出金に関する債権の譲渡を受け付ける（ステップＳ１０１）。受付部１３２は、全ての取引について一括して債権譲渡を受け付ける旨の契約を締結する。なお、実際には、受付部１３２は、個別の取引ごとに（有価証券の売却が発生する度に）、有価証券の売却代金の出金に関する債権の譲渡を受け付けてもよい。

【0126】

続いて、決済サーバ１００の受付部１３２は、ユーザが有価証券の売却指示を行った当日（Ｔ日）に、有価証券の売却代金に関する情報を受け付ける（ステップＳ１０２）。例えば、受付部１３２は、ユーザの端末装置１０の資産運用ミニアプリで有価証券の売買が行われると、資産運用ミニアプリと連携する証券会社の証券サーバ２００から、ユーザを示すユーザＩＤ（UID）とチャージ金額とを受信する。なお、受付部１３２は、証券サーバ２００から、有価証券の売却代金に基づいた額の電子マネーのチャージ指示を受け付けてもよい。

【0127】

続いて、決済サーバ１００のチャージ処理部１３３は、有価証券の売却代金に関する情報に基づき、ユーザが有価証券の売却指示を行った当日（Ｔ日）に、有価証券の売却代金に相当する電子マネーを決済アプリのユーザの電子マネー口座にチャージする（ステップＳ１０３）。

【0128】

続いて、決済サーバ１００の代金要求部１３４は、有価証券の売却代金に相当する電子マネーを決済アプリのユーザの電子マネー口座にチャージした後、通信部１１０を介して、証券会社の証券サーバ２００に対してユーザの電子マネー口座へのチャージ代金の相当額を請求する（ステップＳ１０４）。なお、チャージ代金の相当額を証券会社の証券サーバ２００に請求するタイミング自体は、取引当日である「Ｔ日」又はそれ以降（２営業日後より前を含む）であってもよい。無論、取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）以降であってもよい。すなわち、有価証券の売却代金に相当する電子マネーを利用者Ｕの電子マネー口座にチャージした後であればよい。

【0129】

続いて、決済サーバ１００の代金受領部１３５は、ユーザの電子マネー口座へのチャージ代金の相当額の請求後であって、取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）以降に、通信部１１０を介して、証券会社の証券サーバ２００からチャージ代金の相当額の支払いの通知を受領する（ステップＳ１０５）。すなわち、取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）より前にチャージ代金の相当額を請求したとしても、チャージ代金の相当額の支払いの通知を受領するのは取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）以降である。チャージ代金の相当額を請求するのが取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）以降であれば、当然にチャージ代金の相当額の支払いの通知を受領するのも取引当日（Ｔ日）から２営業日後（Ｔ＋２日目）以降となる。

【0130】

〔６．変形例〕
上述した端末装置１０及び決済サーバ１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、実施形態の変形例について説明する。

【0131】

上記の実施形態において、決済サーバ１００が実行している処理の一部又は全部は、実際には、端末装置１０が実行してもよい。例えば、スタンドアローン（Stand-alone）で（端末装置１０単体で）処理が完結してもよい。この場合、端末装置１０に、上記の実施形態における決済サーバ１００の機能が備わっているものとする。また、上記の実施形態では、端末装置１０は決済サーバ１００と連携しているため、利用者Ｕから見れば、決済サーバ１００の処理も端末装置１０が実行しているように見える。すなわち、他の観点では、端末装置１０は、決済サーバ１００を備えているともいえる。

【0132】

また、上記の実施形態において、証券会社の証券サーバ２００は、図１に示すステップＳ３の送信の際に、上記ステップＳ２の有価証券の売却代金に関する情報を送信するとともに／代わりに、ステップＳ２の有価証券の売却代金に相当する電子マネーを入金してもよい。すなわち、証券サーバ２００は、ステップＳ２の有価証券の売却代金に相当する電子マネーを、証券会社の電子マネー口座から決済サービス事業者の電子マネー口座に移行させる（入金する）ようにしてもよい。そして、決済サービス事業者の決済サーバ１００は、証券会社からの電子マネーに応じて、有価証券の売却代金に相当する電子マネーを利用者Ｕの電子マネー口座にチャージするようにしてもよい。また、証券会社の証券サーバ２００は、電子マネーでの支払分に相当する額を、利用者Ｕの証券口座に着金した額から補填してもよい。例えば、証券会社の証券サーバ２００は、利用者Ｕの有価証券の売却代金を用いて、決済サービス事業者の電子マネー口座に移行させた額に相当する電子マネーを証券会社の電子マネー口座にチャージする。このとき、決済サービス事業者の決済サーバ１００は、証券会社の証券サーバ２００から金融商品の売却代金に基づいた額の電子マネーの入金を受け付け、証券会社の証券サーバ２００からの電子マネーの入金に応じて、金融商品の売却代金に基づいた額の電子マネーを決済アプリにチャージしてもよい。この場合、ステップＳ１の債権譲渡、及びステップＳ５～Ｓ８の請求及び支払いに関する処理は不要となる。

【0133】

また、上記の実施形態において、証券会社の証券サーバ２００は、図１に示すステップＳ８の支払いの際に、ステップＳ４のチャージ代金の相当額を、銀行口座への入金ではなく、電子マネーで支払ってもよい。すなわち、証券サーバ２００は、ステップＳ４のチャージ代金の相当額を、証券会社の電子マネー口座から決済サービス事業者の電子マネー口座に移行させる（入金する）ようにしてもよい。また、証券会社の証券サーバ２００は、電子マネーでの支払分に相当する額を、利用者Ｕの証券口座に着金した額から補填する。例えば、証券会社の証券サーバ２００は、利用者Ｕの有価証券の売却代金を用いて、支払分に相当する額の電子マネーを証券会社の電子マネー口座にチャージする。このとき、決済サービス事業者の決済サーバ１００は、利用者Ｕが金融商品の売却指示を行った当日に、証券会社の証券サーバ２００に対して利用者Ｕの電子マネー口座へのチャージ代金を請求し、証券会社の証券サーバ２００からチャージ代金の支払いを電子マネーで受領してもよい。この場合、ステップＳ１の債権譲渡は不要となる。また、ステップＳ５～Ｓ８の請求及び支払いに関する処理は取引当日でも可能となる。

【0134】

また、上記の実施形態において、決済サーバ１００は、各利用者Ｕの端末装置１０に対して、オンラインで何らかのＷｅｂサービスを提供する情報処理装置であってもよい。例えば、決済サーバ１００は、Ｗｅｂサービスとして、インターネット接続、検索サービス、ＳＮＳ（Social Networking Service）、電子商取引（ＥＣ：Electronic Commerce）、電子決済、オンラインゲーム、オンラインバンキング、オンライントレーディング、宿泊・チケット予約、動画・音楽配信、ニュース、地図、ルート検索、経路案内、路線情報、運行情報、天気予報等のサービスを提供してもよい。実際には、決済サーバ１００は、上記のようなＷｅｂサービスを提供する各種サーバと連携し、Ｗｅｂサービスを仲介してもよいし、Ｗｅｂサービスの処理を担当してもよい。

【0135】

また、上記の実施形態において、決済サーバ１００は、利用者Ｕに関する利用者情報を取得してもよい。例えば、決済サーバ１００は、利用者Ｕの性別、年代、居住地域といった利用者Ｕの属性に関する情報を取得する。そして、決済サーバ１００は、利用者Ｕを示す識別情報（利用者ＩＤ等）とともに利用者Ｕの属性に関する情報を記憶して管理する。

【0136】

また、上記の実施形態において、決済サーバ１００は、利用者Ｕの端末装置１０から、あるいは利用者ＩＤ等に基づいて各種サーバ等から、利用者Ｕの行動を示す各種の履歴情報（ログデータ）を取得してもよい。例えば、決済サーバ１００は、利用者Ｕの位置や日時の履歴である位置履歴を端末装置１０から取得する。また、決済サーバ１００は、利用者Ｕが入力した検索クエリの履歴である検索履歴を検索サーバ（検索エンジン）から取得する。また、決済サーバ１００は、利用者Ｕが閲覧したコンテンツの履歴である閲覧履歴をコンテンツサーバから取得する。また、決済サーバ１００は、利用者Ｕの商品購入や決済処理の履歴である購入履歴（決済履歴）を電子商取引サーバや決済処理サーバから取得する。また、決済サーバ１００は、利用者Ｕのマーケットプレイスへの出品の履歴である出品履歴や販売履歴を電子商取引サーバや決済処理サーバから取得してもよい。また、決済サーバ１００は、利用者Ｕの投稿の履歴である投稿履歴を口コミの投稿サービスを提供する投稿サーバやＳＮＳサーバから取得する。

【0137】

〔７．効果〕
上述してきたように、本願に係る情報処理装置（端末装置１０及び決済サーバ１００）は、電子マネーによる決済を行う決済アプリを介してユーザが金融商品の売買を制御する外部サーバに対して金融商品を売却する旨の指示を行った場合は、外部サーバから、金融商品の売却代金に関する情報を受け付ける受付部１３２と、金融商品の売却代金に関する情報に基づき、ユーザが金融商品を売却してから外部サーバが金融商品の売却代金の受領を確認するまでの間に、金融商品の売却代金に基づいた額の電子マネーを決済アプリにチャージするチャージ処理部１３３と、を備える。

【0138】

また、本願に係る情報処理装置は、外部サーバに決済アプリへのチャージ代金の相当額を請求する代金要求部１３４と、外部サーバから決済アプリへのチャージ代金の相当額の支払いを受領する代金受領部１３５と、をさらに備える。

【0139】

また、代金要求部１３４は、後日、外部サーバに対して決済アプリへのチャージ代金の相当額を請求し、代金受領部１３５は、後日、外部サーバからチャージ代金の相当額の支払いを受領する。

【0140】

なお、受付部１３２は、外部サーバから金融商品の売却代金に基づいた額の電子マネーの入金を受け付け、チャージ処理部１３３は、外部サーバからの電子マネーの入金に応じて、金融商品の売却代金に基づいた額の電子マネーを決済アプリにチャージしてもよい。

【0141】

あるいは、代金要求部１３４は、ユーザが金融商品の売却指示を行った当日に、外部サーバに対してユーザの電子マネー口座へのチャージ代金を請求し、代金受領部１３５は、外部サーバからチャージ代金の支払いを電子マネーで受領してもよい。

【0142】

また、受付部１３２は、電子マネーによる決済を行う決済アプリ内において、有価証券の売買を仲介する証券会社の資産運用ミニアプリを介してユーザが売却する有価証券の売却代金の出金に関する債権の譲渡を受け付け、チャージ処理部１３３は、有価証券の売却代金の出金に関する債権の譲渡に応じて、ユーザが有価証券の売却指示を行った当日に、有価証券の売却代金に相当する電子マネーを決済アプリのユーザの電子マネー口座にチャージする。

【0143】

また、代金要求部１３４は、有価証券の売却代金の出金に関する債権に基づき、証券会社に対してユーザの電子マネー口座へのチャージ代金の相当額を請求し、代金受領部１３５は、証券会社からユーザの電子マネー口座へのチャージ代金の相当額の支払いを受領する。

【0144】

また、代金要求部１３４は、有価証券の売却代金の出金が可能となる日以降に、有価証券の売却代金の出金に関する債権に基づき、証券会社に対してユーザの電子マネー口座へのチャージ代金の相当額を請求し、代金受領部１３５は、有価証券の売却代金の出金が可能となる日以降に、証券会社からチャージ代金の相当額の支払いの通知を受領する。

【0145】

すなわち、本願に係る情報処理装置は、電子マネーでの決済サービスを提供する第１事業者の決済アプリ内のミニアプリのうち有価証券の売買を仲介する第２事業者の資産運用ミニアプリを介してユーザが有価証券の売却指示を行った当日に、有価証券の売却代金に関する情報を受け付ける受付部１３２と、有価証券の売却代金に関する情報に基づき、ユーザが有価証券の売却指示を行った当日に、有価証券の売却代金に相当する電子マネーを決済アプリのユーザの電子マネー口座にチャージするチャージ処理部１３３と、第１事業者の情報処理装置として第２事業者の情報処理装置に対してユーザの電子マネー口座へのチャージ代金の相当額を請求する代金要求部１３４と、第２事業者の情報処理装置からユーザの電子マネー口座へのチャージ代金の相当額の支払いを受領する代金受領部１３５と、を備える。

【0146】

また、本願に係る他の情報処理装置（証券サーバ２００）は、決済サービス事業者の決済サーバ１００から、ユーザの識別情報及びユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信部と、保存された請求情報に含まれるユーザの識別情報に応じたユーザの証券口座への着金を検知する検知部と、ユーザの証券口座への着金を検知した場合、保存された請求情報に含まれるチャージ代金を、着金が検知されたユーザの証券口座から決済サービス事業者の銀行口座へ入金する入金処理部と、を備えることを特徴とする。

【0147】

本実施形態に係る情報処理システム１は、決済サービス事業者の決済サーバ１００と、証券会社の証券サーバ２００と、を含み、決済サーバ１００は、電子マネーによる決済を行う決済アプリを介してユーザが金融商品の売買を制御する証券サーバ２００に対して金融商品を売却する旨の指示を行った場合は、証券サーバ２００から、金融商品の売却代金に関する情報を受け付ける受付部と、金融商品の売却代金に関する情報に基づき、ユーザが金融商品を売却してから証券サーバ２００が金融商品の売却代金の受領を確認するまでの間に、金融商品の売却代金に基づいた額の電子マネーを決済アプリにチャージするチャージ処理部と、証券サーバ２００に、ユーザの識別情報及びユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を送信する送信部と、を備え証券サーバ２００は、決済サーバ１００から、ユーザの識別情報及びユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信部と、保存された請求情報に含まれるユーザの識別情報に応じたユーザの証券口座への着金を検知する検知部と、ユーザの証券口座への着金を検知した場合、保存された請求情報に含まれるチャージ代金を、着金が検知されたユーザの証券口座から決済サービス事業者の銀行口座へ入金する入金処理部と、を備えることを特徴とする。

【0148】

上述した各処理のいずれかもしくは組合せにより、本願に係る情報処理装置は、債権譲渡（ファクタリング）により有価証券の売却取引当日の売却代金を電子マネーで受領できるスキームを実現することができる。

【0149】

なお、上述の例では、ユーザの証券口座から決済サービス事業者の銀行口座へ入金する例について説明したが、実施形態は、これに限定されない。上述した処理における銀行口座は、銀行以外の信用金庫、信用組合、商工組合中央金庫、農林漁業組合等の金融機関（但し、証券会社は除く）の口座を含むものである。上述の処理において、「銀行口座」とは、各種金融機関の口座である「金融機関口座」と読み替えることができ、金融機関口座の一例として、銀行口座が該当する。

【0150】

〔８．証券サーバの構成例〕
続いて、証券サーバ２００の一例について説明する。図１１は、証券サーバ２００の構成例を示す図である。図１１に示すように、証券サーバ２００は、通信部２１０と、記憶部２２０と、制御部２３０とを有する。

【0151】

（通信部２１０）
通信部２１０は、例えば、ＮＩＣ等によって実現される。また、通信部２１０は、ネットワークＮ（図６参照）と有線又は無線で接続される。

【0152】

（記憶部２２０）
記憶部２２０は、例えば、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、又は、ＨＤＤ、ＳＳＤ、光ディスク等の記憶装置によって実現される。図１１に示すように、記憶部２２０は、証券口座データベース２２１と、証券サーバ用情報処理プログラム２２２とを有する。

【0153】

（証券口座データベース２２１）
証券口座データベース２２１は、利用者Ｕの証券口座に関するデータベースである。例えば、証券口座データベース２２１には、利用者Ｕの証券口座に関する情報として、利用者Ｕ（例えば、利用者Ｕの識別情報）と、利用者Ｕが保有する有価証券の情報（例えば、利用者Ｕが保有する有価証券の銘柄と数量を示す情報）と、利用者Ｕの証券口座への入金額を示す情報（例えば、利用者Ｕ所有の有価証券の売却による着金額）とが対応付けて登録されている。なお、証券口座データベース２２１には、他にも、利用者Ｕの証券口座に関する情報であれば任意の情報が登録されていてよい。また、証券口座データベース２２１には、いわゆる有価証券に関する証券口座を実現するために必要な各種公知の情報が登録される。

【0154】

（証券サーバ用情報処理プログラム）
証券サーバ用情報処理プログラム２２２は、証券サーバ２００に各種の処理を実行させるためのプログラムである。証券サーバ２００は、証券サーバ用情報処理プログラム２２２を実行することにより、後述する受信部２３１、検知部２３２、入金処理部２３３として動作する。なお、証券サーバ２００は、証券サーバ用情報処理プログラム２２２以外にも、証券サーバ２００として各種公知の動作を実現するためのプログラムを保持し、実行してもよい。

【0155】

（制御部２３０）
制御部２３０は、コントローラ（Controller）であり、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等によって、証券サーバ２００の内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭ等の記憶領域を作業領域として実行されることにより実現される。図１１に示す例では、制御部２３０は、受信部２３１、検知部２３２、および入金処理部２３３として動作する。

【0156】

受信部２３１は、決済サーバ１００から、ユーザＵの識別情報及びユーザＵの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信する。このような場合、受信部３２１は、受信した請求情報を記憶部２２０に保存する。

【0157】

検知部２３２は、受信部２３１により保存された請求情報に含まれるユーザＵの識別情報に応じたユーザＵの証券口座への着金を検知する。例えば、検知部２３２は、証券口座データベース２２１と請求情報とを参照し、ユーザＵの証券口座への着金があった場合は、かかる着金が請求情報に対応するものであるかを判定し、着金が請求情報に対応するものである場合は、ユーザＵの証券口座への着金を検知したものとする。

【0158】

入金処理部２３３は、ユーザＵの証券口座への着金を検知した場合、保存された請求情報に含まれるチャージ代金を、着金が検知されたユーザの証券口座から決済サービス事業者の金融機関口座へ入金する。例えば、入金処理部２３３は、ユーザＵの証券口座からチャージ代金の減算を行うとともに、対応する額が決済サービス事業者の金融機関口座に入金されるように、所定の金融機関サーバに対して振り込み処理の実行を依頼する。さらに、この振り込み処理の実行に伴い、入金処理部２３３は、入金した旨の通知を決済サーバ１００へ通信部２１０を介して送信する処理を実行する。

【0159】

なお、証券サーバ２００は、上述した処理に加えて、以下の処理を実行してもよい。例えば、売却時にユーザＵが指定可能な有価証券額の上限は、ユーザの所有する金融商品の数量に応じた額となる。例えば、市場開場時であれば、そのときの株価や、基準価額等により、金融商品の数量に応じた額も変動する。このため、証券サーバ２００は、利用者Ｕが所有する証券の情報を管理し、これに基づいて、利用者が設定できる金額の上限を算出し、算出した金額の上限を任意のタイミングで端末装置１０や決済サーバ１００に通知してもよい。

【0160】

また、証券サーバ２００は、金融商品の売却が行われると、金融商品の所有に係る情報に基づいて、売却した金融商品の数量が、ユーザの所有から証券会社の所有へ移す処理を実行してもよい。

【0161】

〔９．ハードウェア構成〕
また、上述した実施形態に係る端末装置１０や決済サーバ１００、証券サーバ２００は、例えば図１２に示すような構成のコンピュータ１０００によって実現される。以下、決済サーバ１００を例に挙げて説明する。図１２は、ハードウェア構成の一例を示す図である。コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力Ｉ／Ｆ（Interface）１０６０、入力Ｉ／Ｆ１０７０、ネットワークＩ／Ｆ１０８０がバス１０９０により接続された形態を有する。

【0162】

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラム等に基づいて動作し、各種の処理を実行する。演算装置１０３０は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等により実現される。

【0163】

一次記憶装置１０４０は、ＲＡＭ（Random Access Memory）等、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等により実現される。二次記憶装置１０５０は、内蔵ストレージであってもよいし、外付けストレージであってもよい。また、二次記憶装置１０５０は、ＵＳＢ（Universal Serial Bus）メモリやＳＤ（Secure Digital）メモリカード等の取り外し可能な記憶媒体であってもよい。また、二次記憶装置１０５０は、クラウドストレージ（オンラインストレージ）やＮＡＳ（Network Attached Storage）、ファイルサーバ等であってもよい。

【0164】

出力Ｉ／Ｆ１０６０は、ディスプレイ、プロジェクタ、及びプリンタ等といった各種の情報を出力する出力装置１０１０に対し、出力対象となる情報を送信するためのインターフェースであり、例えば、ＵＳＢ（Universal Serial Bus）やＤＶＩ（Digital Visual Interface）、ＨＤＭＩ（登録商標）（High Definition Multimedia Interface）といった規格のコネクタにより実現される。また、入力Ｉ／Ｆ１０７０は、マウス、キーボード、キーパッド、ボタン、及びスキャナ等といった各種の入力装置１０２０から情報を受信するためのインターフェースであり、例えば、ＵＳＢ等により実現される。

【0165】

また、出力Ｉ／Ｆ１０６０及び入力Ｉ／Ｆ１０７０はそれぞれ出力装置１０１０及び入力装置１０２０と無線で接続してもよい。すなわち、出力装置１０１０及び入力装置１０２０は、ワイヤレス機器であってもよい。

【0166】

また、出力装置１０１０及び入力装置１０２０は、タッチパネルのように一体化していてもよい。この場合、出力Ｉ／Ｆ１０６０及び入力Ｉ／Ｆ１０７０も、入出力Ｉ／Ｆとして一体化していてもよい。

【0167】

なお、入力装置１０２０は、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、又は半導体メモリ等から情報を読み出す装置であってもよい。

【0168】

ネットワークＩ／Ｆ１０８０は、ネットワークＮを介して他の機器からデータを受信して演算装置１０３０へ送り、また、ネットワークＮを介して演算装置１０３０が生成したデータを他の機器へ送信する。

【0169】

演算装置１０３０は、出力Ｉ／Ｆ１０６０や入力Ｉ／Ｆ１０７０を介して、出力装置１０１０や入力装置１０２０の制御を行う。例えば、演算装置１０３０は、入力装置１０２０や二次記憶装置１０５０からプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行する。

【0170】

例えば、コンピュータ１０００が決済サーバ１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、コンピュータ１０００の演算装置１０３０は、ネットワークＩ／Ｆ１０８０を介して他の機器から取得したプログラムを一次記憶装置１０４０上にロードし、ロードしたプログラムを実行してもよい。また、コンピュータ１０００の演算装置１０３０は、ネットワークＩ／Ｆ１０８０を介して他の機器と連携し、プログラムの機能やデータ等を他の機器の他のプログラムから呼び出して利用してもよい。

【0171】

〔１０．その他〕
以上、本願の実施形態を説明したが、これら実施形態の内容により本発明が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換又は変更を行うことができる。

【0172】

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

【0173】

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

【0174】

例えば、上述した決済サーバ１００は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティング等で呼び出して実現するなど、構成は柔軟に変更できる。

【0175】

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

【0176】

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

【符号の説明】

【0177】

１ 情報処理システム
１０ 端末装置
１００ 決済サーバ
１１０ 通信部
１２０ 記憶部
１２１ 取引情報データベース
１３０ 制御部
１３１ 取得部
１３２ 受付部
１３３ チャージ処理部
１３４ 代金要求部
１３５ 代金受領部
２００ 証券サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【手続補正書】

【提出日】2023-02-03

【手続補正1】

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

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

決済サービス事業者の決済サーバであって、ユーザが金融商品を売却する旨の指示を行った当日に、当該金融商品の売却代金に基づいた額の電子マネーを前記決済サービス事業者が提供する決済サービスにおける前記ユーザの電子マネー口座にチャージする決済サーバから、前記ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信部と、
保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知部と、
前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理部と、
を備えることを特徴とする情報処理装置。

【請求項2】

情報処理装置が実行する情報処理方法であって、
決済サービス事業者の決済サーバであって、ユーザが金融商品を売却する旨の指示を行った当日に、当該金融商品の売却代金に基づいた額の電子マネーを前記決済サービス事業者が提供する決済サービスにおける前記ユーザの電子マネー口座にチャージする決済サーバから、前記ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信工程と、
保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知工程と、
前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理工程と、
を含むことを特徴とする情報処理方法。

【請求項3】

決済サービス事業者の決済サーバであって、ユーザが金融商品を売却する旨の指示を行った当日に、当該金融商品の売却代金に基づいた額の電子マネーを前記決済サービス事業者が提供する決済サービスにおける前記ユーザの電子マネー口座にチャージする決済サーバから、前記ユーザの識別情報及び前記ユーザの電子マネー口座への電子マネーのチャージ代金を含む請求情報を受信して保存する受信手順と、
保存された前記請求情報に含まれる前記ユーザの識別情報に応じた前記ユーザの証券口座への着金を検知する検知手順と、
前記ユーザの証券口座への着金を検知した場合、保存された前記請求情報に含まれるチャージ代金を、着金が検知された前記ユーザの証券口座から前記決済サービス事業者の金融機関口座へ入金する入金処理手順と、
をコンピュータに実行させるための情報処理プログラム。