JP7342235B1 - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

【課題】送金を行うユーザの利便性を高めること。【解決手段】本願に係る情報処理装置は、コード発行部と、送金受付部と、残高処理部とを有する。コード発行部は、法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、事業者に対して所定の目的での送金を行うために記述されたコード情報を発行する。送金受付部は、コード発行部により発行されたコード情報を通じて、他のアカウントから送金を受け付ける。残高処理部は、送金受付部により受け付けられた送金の額に相当する電子マネーを法人アカウントが有するウォレットの残高に加算する。コード情報の各々は、事業者、及び他のコード情報とは異なる所定の目的を識別するための識別情報を含み、送金受付部は、識別情報に基づいて、所定の目的を示す情報を他のアカウントに提供した後、他のアカウントから所定の目的による送金要求を受け付ける。【選択図】図３

Description

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

近年、紙幣や硬貨などの現金を離れ、災害が発生した際の義援金や、寺社仏閣に対する賽銭などをキャッシュレスで送金する方法が提案され始めている。また、近年では、クラウドファンディングのように、ネットワークを通じた資金調達が世間一般に認知され、個人から特定の団体に対して送金が行われる場合も日常的に想定される。

また、昨今、他人の口座情報などを詐取することを目的としたフィッシング詐欺などが問題となっており、口座情報を悪意あるアクセスから守るための技術も提案されている。

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

しかしながら、従来の技術は、送金を行うユーザの利便性を高める上で改善の余地がある。たとえば、ユーザが、インターネットバンキングを利用して義援金や賽銭などの送金を行う場合、金融機関の専用サイトにログインしたり、振込先の情報を入力したりするなどの手間を要する。また、ユーザがクレジッドカードの決済サービスを利用して義援金や賽銭などの送金を行う場合も、送金先のウェブページにアクセスしたり、カード情報を入力したりするなどの手間を要する。このように、現状、ユーザは、送金を行うためにいくつかの手順を踏む必要があり、必ずしも、送金を行うユーザにとって利便性が高いとは言えない状況にある。また、ウェブページへのカード情報の入力は、セキュリティの面でも好ましいものではない。

本願は、上記に鑑みてなされたものであって、送金を行うユーザの利便性を高めることができる情報処理装置、情報処理方法及び情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、他のアカウントからの送金を受付可能とする法人向けサービスに関する処理を実行する。また、情報処理装置は、コード発行部と、送金受付部と、残高処理部とを有する。コード発行部は、法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、事業者を送金先として所定の目的での送金を行うための情報が記述されたコード情報を発行する。送金受付部は、コード発行部により発行されたコード情報を通じて、他のアカウントから送金を受け付ける。残高処理部は、送金受付部により受け付けられた送金の額に相当する電子マネーを法人アカウントが有するウォレットの残高に加算する。各コード情報は、事業者、及び他のコード情報とは異なる所定の目的を識別するための識別情報を含み、送金受付部は、他のアカウントから受信した受信情報に含まれている識別情報に基づいて、所定の目的を示す情報を他のアカウントに提供した後、他のアカウントから所定の目的による送金要求を受け付ける。

実施形態の一態様によれば、送金を行うユーザの利便性を高めることができるという効果を奏する。

図１は、本実施形態に係る情報処理の概要を示す図である。 図２は、本実施形態に係る情報処理の概要を示す図である。 図３は、本実施形態に係る情報処理装置の構成例を示すブロック図である。 図４は、本実施形態に係る事業者情報記憶部に記憶される事業者情報の概要を示す図である。 図５は、本実施形態に係るコード情報記憶部に記憶されるコード情報の概要を示す図である。 図６は、本実施形態に係る送金受付履歴記憶部に記憶される送金の受付履歴を示す情報の概要を示す図である。 図７は、本実施形態に係る情報処理装置の処理手順例を示すフローチャートである。 図８は、本実施形態または変形例に係る情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．本実施形態に係る情報処理の一例〕
以下、図１および図２を用いて、本実施形態に係る情報処理の一例について説明する。図１および図２は、本実施形態に係る情報処理の概要を示す図である。

図１に示すように、本実施形態に係る情報処理システムＳＹＳは、端末装置１０と、情報処理装置１００とを含む。なお、図１は、本実施形態に係る情報処理システムＳＹＳの一例を示しており、図１には示されていない他の端末装置が含まれていてもよい。

端末装置１０および情報処理装置１００は、有線または無線によりネットワークＮ（たとえば、図３参照）に接続される。端末装置１０および情報処理装置１００は、ネットワークＮを通じて相互に通信できる。

図１に示す端末装置１０は、情報処理装置１００から提供される送金サービスの利用者であるユーザＵによって使用される情報処理端末である。端末装置１０の典型例としては、スマートフォンが該当するが、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）などにより実現されてもよい。図１の例では、端末装置１０として、スマートフォンが示されている。なお、以下の説明では、端末装置１０をユーザＵと言い換えて表記する場合がある。つまり、ユーザＵを端末装置１０と読み替えることができる。また、以下の説明において、情報処理装置１００から提供される各種サービスの利用者を単に「ユーザ」と称する場合がある。

また、端末装置１０は、ＬＴＥ（Long Term Evolution）、４Ｇ（4th Generation）、５Ｇ（5th Generation：第５世代移動通信システム）などの無線通信網や、Ｂｌｕｅｔｏｏｔｈ（登録商標）、無線ＬＡＮ（Local Area Network）などの近距離無線通信を介してネットワークＮに接続するための通信ユニットを有する。これにより、ユーザＵ１は、端末装置１０を操作して情報処理装置１００にアクセスして、情報処理装置１００により提供される送金サービスを利用できる。

また、端末装置１０は、情報処理装置１００により提供される送金サービスを利用するための情報を、ウェブブラウザやアプリケーションにより表示できる。このとき、端末装置１０は、ウェブブラウザやアプリケーションなどによる情報の表示処理を実現するための制御情報を情報処理装置１００から受け取った場合には、受け取った制御情報に従って表示処理を実現する。

図１に示す情報処理装置１００は、ユーザＵ１対して送金サービスを提供する情報処理装置である。また、図１に示す情報処理装置１００は、他のアカウントからの送金を受付可能とする法人向けサービスに関する処理を実行する。情報処理装置１００は、典型的にはサーバ装置であるが、メインフレームやワークステーションなどにより実現されてもよい。情報処理装置１００がサーバ装置で実現される場合、単独のサーバにより実現されてもよいし、複数のサーバ装置及び複数のストレージ装置が協働して動作するクラウドシステムなどにより実現されてもよい。

なお、情報処理装置１００は、ユーザＵが使用する端末装置１０に制御情報を配信する配信装置として機能してもよい。ここで、制御情報は、たとえば、ＪａｖａＳｃｒｉｐｔ（登録商標）などのスクリプト言語やＣＳＳ（Cascading Style Sheets）などのスタイルシート言語により記述される。なお、情報処理装置１００から配信されるアプリケーションそのものを制御情報とみなしてもよい。

また、情報処理装置１００が提供する送金サービスは、ユーザＵなどの個人から企業や団体などに対する送金を可能とするサービスである。また、情報処理装置１００が提供する法人向けサービスは、送金サービスを利用してユーザＵなどの個人から企業や団体などの法人に対して行われた送金を受取可能とするサービスである。本実施形態に係る情報処理装置１００は、以下に説明する情報処理により、送金を行うユーザの利便性を高めることができる。

以下、本実施形態に係る情報処理について、この情報処理が実施される際に想定される流れに沿って具体的に説明する。なお、以下では、ユーザＵが、募金活動を行っている事業者Ｍに対し、送金サービスを利用して寄付の送金を行う場合について説明するが、実施形態に係る情報処理は、この事例には特に限定されることなく、電子マネーで行われる種々の送金に対して適用できる。

たとえば、ユーザＵは、端末装置１０を操作してコード情報Ｑ１を読み取る（ステップＳ１）。コード情報Ｑ１は、事業者Ｍからの要求に応じて、情報処理装置１００において予め生成される。たとえば、コード情報Ｑ１は、ＱＲコード（登録商標）などの２次元コードにより構成され、ユーザＵからの送金要求を受け付けるための受付手段として機能する。なお、コード情報Ｑ１は、ユーザＵからの送金要求を受け付けるための受付手段の一例であり、ユーザＵからの送金要求を受付可能な任意の手段を採用できる。コード情報Ｑ１には、法人向けサービスを利用する事業者Ｍに提供される法人アカウントに紐付けて、事業者Ｍを送金先として所定の目的での送金を行うための情報が記述される。たとえば、コード情報Ｑ１は、事業者Ｍが募金活動のために立ち上げたプロジェクトごとに予め用意された送金画面（ウェブページ）にアクセスするための情報が記述される。たとえば、コード情報Ｑ１に記述される情報には、送金先の事業者を識別するための識別情報である事業者ＩＤや法人アカウントを識別できる法人アカウントＩＤ、事業者が立ち上げたプロジェクトを識別するための識別情報であるコードＩＤ（「事業者および所定の目的を識別するための識別情報」の一例）などが含まれている。

端末装置１０は、コード情報Ｑ１の読取に伴って、図１に示す送金画面を表示する（ステップＳ２）。たとえば、端末装置１０は、コード情報Ｑ１に記述された情報にアクセスすることにより、情報処理装置１００から提供される送金画面を表示する。この送金画面には、端末装置１０がコード情報Ｑ１から読み取った情報を情報処理装置１００に送信することにより、情報処理装置１００から取得される情報が表示される。具体的には、端末装置１０は、コード情報Ｑ１から読み取った各種識別情報（たとえば、送金先の事業者を識別するための事業者ＩＤや、プロジェクトを識別するためのコードＩＤ）を情報処理装置１００に送信することにより、情報処理装置１００から募金先などを示すプロジェクトの名称（送金先表示名）などの情報を取得し、送金画面に表示する。たとえば、図１に示す送金画面には、情報処理装置１００から取得されるプロジェクトの名称の一例として、送金先表示名：「Ａ募金」が表示されている。また、図１に示す送金画面には、送金金額の入力欄と、送金ボタンと、キャンセルボタンとが設けられている。ユーザＵは、送金金額の入力欄に所望の金額を入力した後、送金ボタンを操作することにより、送金要求を情報処理装置１００に送信できる。また、ユーザＵは、キャンセルボタンを操作することにより、送金要求を送信する前に送金処理を中止できる。なお、図１に示す送金画面は一例であり、募金活動に対応するコード情報Ｑ１であれば、募金の目的や送金先の団体（たとえば、事業者Ｍ）についての詳細情報などを情報処理装置１００から取得して表示し、送金要求を送信する前にユーザＵが確認できるようにしてもよい。

端末装置１０は、ユーザＵの操作に応じて、送金要求を情報処理装置１００に送信する（ステップＳ３）。送金要求には、送金元を示す情報と、送金金額を示す情報と、送金先を表す事業者を識別するための事業者ＩＤと、上述のプロジェクトを識別するためのコードＩＤが含まれる。たとえば、送金元を示す情報には、ユーザＵが送金サービスの利用登録時に情報処理装置１００から発行されたユーザＩＤ（「他のアカウント」の一例）を利用できる。

情報処理装置１００は、ユーザＵから送金要求を受信すると、送金金額に相当する電子マネーを、事業者Ｍのプロジェクト：「Ａ募金」に対応するサブウォレットの残高に加算する（ステップＳ４）。たとえば、情報処理装置１００は、送金金額に相当する額を、送金要求に含まれる事業ＩＤおよびコードＩＤに紐付けられているサブウォレットの残高に加算する。

続いて、情報処理装置１００は、所定のタイミングで、サブウォレットの残高を、事業者Ｍのメインウォレットに移行する（ステップＳ５）。そして、情報処理装置１００は、所定のタイミングで、メインウォレットの残高を事業者Ｍの銀行口座に払い出す（ステップＳ６）。

以下、図２を用いて、情報処理装置１００により実行される送金サービスについて、具体的な利用シーンを交えて説明する。なお、以下の説明において、図２に示すユーザＵ１，Ｕ２，Ｕ３を区別して説明する必要がない場合、ユーザＵと総称して説明する。また、以下の説明において、図２に示す端末装置１０－１，１０－２，１０－３を区別して説明する必要がない場合、端末装置１０と総称して説明する。また、以下の説明において、図２に示すコード情報Ｑ１，Ｑ２，Ｑ３を区別して説明する必要がない場合、コード情報Ｑと総称して説明する。

たとえば、事業者Ｍは、募金活動のための３つのプロジェクトを立ち上げる。そして、事業者Ｍは、立ち上げた３つのプロジェクトのそれぞれについて個別にユーザＵからの寄付（送金）を電子マネーで受け取るためのサービスを契約する。そして、事業者Ｍは、情報処理装置１００に対して、各サービスに対応するコード情報の発行を要求する。情報処理装置１００は、事業者Ｍからの要求に応じて、３つのプロジェクトの各々に個別に対応するコード情報Ｑとして、図２に示すコード情報Ｑ１，Ｑ２，Ｑ３を発行する。なお、コード情報Ｑは、ユーザＵが端末装置１０を用いて読み取り可能な形態で構成されていればよく、デジタルサイネージなどに画像情報として表示されてもよいし、紙などの所定の媒体に印字された印字物であってもよい。

たとえば、コード情報Ｑ１は、事業者Ｍが募金活動のために立ち上げたプロジェクトの名称：「Ａ募金」に対するユーザＵからの寄付（送金）を受け付けるための情報であり、たとえば、送金先の事業者Ｍを識別するための事業者ＩＤや法人アカウントを識別するための法人アカウントＩＤ、プロジェクトを識別するためのコードＩＤなどが含まれる。コード情報Ｑ１は、たとえば、募金活動が行われるＸ会場に設置される。

また、たとえば、コード情報Ｑ２は、事業者Ｍが募金活動のために立ち上げたプロジェクトの名称：「Ｂ募金」に対するユーザＵからの寄付（送金）を受け付けるための情報であり、たとえば、送金先の事業者Ｍを識別するための事業者ＩＤや法人アカウントを識別できるアカウントＩＤ、プロジェクトを識別するためのコードＩＤなどが含まれる。コード情報Ｑ２は、たとえば、募金活動が行われるＹ会場に設置される。

また、たとえば、コード情報Ｑ３は、事業者Ｍが募金活動のために立ち上げたプロジェクトの名称：「Ｃ募金」に対するユーザＵからの寄付（送金）を受け付けるための情報であり、たとえば、送金先の事業者Ｍを識別するための事業者ＩＤや法人アカウントを識別するためのアカウントＩＤ、プロジェクトを識別するためのコードＩＤなどが含まれる。コード情報Ｑ３は、たとえば、募金活動が行われるＺ会場に設置される。

情報処理装置１００は、事業者Ｍに対して発行したコード情報に関する各種情報を、事業者Ｍの法人アカウントに紐付けて管理する。図２に示す例では、事業者Ｍのコード情報に関する各種情報として、事業者ＩＤや、法人アカウントＩＤや、コードＩＤや、送金先表示名や、有効期限や、会場を示す各情報が含まれている。コード情報に関するこれらの情報は相互に対応付けられている。

事業者ＩＤは、事業者Ｍを識別するための識別情報である。法人アカウントＩＤは、事業者Ｍに提供した法人アカウントを識別するための識別情報である。コードＩＤは、事業者Ｍに対して発行したコード情報を識別するための識別情報である。送金先表示名は、事業者Ｍが募金活動や資金調達などのために立ち上げたプロジェクトの名称に対応する。有効期限は、コード情報が有効な状態で機能できる期限として予め設定される日付である。会場は、事業者により決定されたコード情報の設置場所を示す。

図２に示す例において、たとえば、ユーザＵ１は、Ｘ会場に設置されているコード情報Ｑ１を読み取ることにより、コード情報Ｑ１から読み取った各種識別情報（たとえば、送金先の事業者を識別するための事業者ＩＤや、上述のプロジェクトを識別するためのコードＩＤ）を情報処理装置１００に送信することにより、情報処理装置１００から取得した募金先などを示すプロジェクトの名称（たとえば、「Ａ募金」）などが記載された送金画面を表示し、この送金画面を通じてユーザＵ１から受け付けた送金指示に従い、２０２２年１月１日に、寄付として１０００円の送金要求を送信する。ユーザＵ１からの送金要求は、情報処理装置１００において処理され、事業者Ｍの法人アカウント：「Ｈ＃００１」に紐付くＡ募金用のサブウォレットの残高に加算される。

また、図２に示す例において、たとえば、ユーザＵ２は、Ｙ会場に設置されているコード情報Ｑ２を読み取ることにより、コード情報Ｑ２から読み取った各種識別情報（たとえば、送金先の事業者を識別するための事業者ＩＤや、上述のプロジェクトを識別するためのコードＩＤ）を情報処理装置１００に送信することにより、情報処理装置１００から取得した募金先などを示すプロジェクトの名称（たとえば、「Ｂ募金」）などが記載された送金画面を表示し、この送金画面を通じてユーザＵ２から受け付けた送金指示に従い、２０２２年２月１日に、寄付として２０００円の送金要求を送信する。また、ユーザＵ２は、Ｚ場に設置されているコード情報Ｑ３を読み取ることにより、コード情報Ｑ３から読み取った各種識別情報（たとえば、送金先の事業者を識別するための事業者ＩＤや、上述のプロジェクトを識別するためのコードＩＤ）を情報処理装置１００に送信することにより、情報処理装置１００から取得した募金先などを示すプロジェクトの名称（たとえば、「Ｃ募金」）などが記載された送金画面を表示し、この送金画面を通じてユーザＵ２から受け付けた送金指示に従い、２０２２年２月１日に、寄付として１０００円の送金要求を送信する。ユーザＵ２からの各送金要求は、情報処理装置１００においてそれぞれ処理される。たとえば、コード情報Ｑ２を通じて行われたユーザＵ２からの送金要求は、事業者Ｍの法人アカウント：「Ｈ＃００１」に紐付くＢ募金用のサブウォレットの残高に加算される。一方、コード情報Ｑ３を通じて行われたユーザＵ２からの送金要求は、事業者Ｍの法人アカウント：「Ｈ＃００１」に紐付くＣ募金用のサブウォレットの残高に加算される。

なお、ユーザＵ２は、２０２２年２月１日に、Ｘ会場に設置されているコード情報Ｑ１を読み取っても、コード情報Ｑ１の有効期限が切れているので、寄付（送金）を行うことはできない。このように、情報処理装置１００は、ユーザＵ２から受信した受信情報に含まれる各情報に紐付くコード情報Ｑ１の有効期限が切れている場合、受信情報の送信元であるユーザＵ２に対してエラー処理を返すことができる。たとえば、情報処理装置１００は、ユーザＵ２から送金先の事業者を識別するための事業者ＩＤと上述のプロジェクトを識別するためのコードＩＤを端末装置１０から受信した場合、その受信情報に含まれる各情報に紐づくコード情報Ｑ１の有効期限を参照し、受信情報の受付日が有効期限を過ぎている場合（有効期限内にない場合）は、「この寄付用のＱＲコードは有効期限が切れています。」といったエラーメッセージを送信できる。すなわち、情報処理装置１００は、ユーザＵから受信した受信情報に含まれる各情報に紐付くコード情報Ｑの有効期限が切れている場合（受信日が有効期限を過ぎている場合）は、送金処理を実施しない。なお、情報処理装置１００は、コード情報Ｑに対して予め有効期限を設定する代わりに、コード情報Ｑを通じた送金の受付を有効な状態にするフラグと、無効な状態にするフラグとを事業者が任意のタイミングで柔軟に設定可能としてもよい。

また、情報処理装置１００は、有効期限が切れている旨のメッセージの表示の他に、同一事業者が受け付けている他の寄付のプロジェクト情報を参照できるようにしてもよい。具体的には、端末装置１０から受信した送金先の事業者を識別する情報とプロジェクトを識別する情報に基づいて、有効期限を参照し、有効期限が切れている場合に、送金先の事業者が同一であって、有効期限が切れていない他の寄付のプロジェクトがあるか確認し、ある場合に、そのプロジェクトの情報を表示してもよい。プロジェクトの情報はそのプロジェクトの送金画面へリンク可能な情報であってもよいし、コード情報に含まれる寄付会場の情報であってもよいし、送金先表示名であってもよい。たとえば、図２に示す例では、情報処理装置１００は、エラーメッセージ（テキスト情報）にハイパーリンクなどの参照情報を埋め込むことにより、事業者Ｍに紐付く複数のコード情報Ｑ１～Ｑ３のうち、ユーザＵ２の送金受付日である２０２２日２月１日が有効期限内である他のコード情報Ｑ３に関する情報を、送金元であるユーザＵ２に提供できる。これにより、たとえば、所定の団体に対して寄付を行おうとしているユーザＵに対して、有益な情報を提供できる。

また、図２に示す例において、たとえば、ユーザＵ３は、Ｘ会場に設置されているコード情報Ｑ３を読み取ることにより、コード情報Ｑ３から読み取った各種識別情報（たとえば、送金先の事業者を識別するための識別情報や、プロジェクトを識別するための識別情報）を情報処理装置１００に送信することにより、情報処理装置１００から取得した募金先などを示すプロジェクトの名称（たとえば、「Ｃ募金」）などが記載された送金画面を表示し、この送金画面を通じてユーザＵ３から受け付けた送金指示に従い、２０２２年３月１日に、寄付として３０００円の送金要求を送信する。ユーザＵ３からの送金要求は、情報処理装置１００において処理され、事業者Ｍの法人アカウント：「Ｈ＃００１」に紐付くＣ募金用のサブウォレットの残高に加算される。

情報処理装置１００は、各ユーザＵから受信した送金要求を、送金受付履歴として管理する。図２に示す場合、送金受付履歴は、送金先表示名と、日付と、送金元と、送金金額と、会場を示す各情報を含んでいる。情報処理装置１００は、事業者Ｍからの要求に応じて、これらの情報を含む送金受付履歴を提供できる。たとえば、情報処理装置１００は、送金を受け取るためのサービス契約単位で（たとえば、送金先表示名ごとに）、コード情報Ｑごとに送金受付履歴を提供できる。

上述してきたように、実施形態に係る情報処理によれば、ユーザＵは、送金サービスを利用することにより、コード情報Ｑを読み取る簡便な操作で送金を行うことができ、送金を行うユーザＵの利便性を高めることができる。この結果、ユーザＵが送金を行う確度を高めることも可能となる。一方、事業者Ｍは、法人向けサービスを利用することにより、ユーザＵからの送金を受け取るためのシステムを改めて構築する必要がなく、手軽に送金を受け取ることができる。また、事業者Ｍは、ユーザＵからの送金を受け取るためのサービスの契約単位でユーザＵからの送金を受け取ることが可能となり、送金が行われたルートの分析が可能となるとともに、受け取った資金の管理も容易となる。

〔２．装置構成例〕
以下、本実施形態に係る情報処理装置１００の構成について説明する。図３は、本実施形態に係る情報処理装置の構成例を示すブロック図である。

図３に示すように、情報処理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。

（通信部１１０について）
通信部１１０は、有線又は無線により、ネットワークＮに接続される。通信部１１０は、ネットワークＮを介して、端末装置１０との間で情報の送受信を行う。通信部１１０は、たとえば、ＮＩＣ（Network Interface Card）等によって実現される。ネットワークＮは、インターネットなどのＷＡＮ（Wide Area Network）である。なお、ネットワークＮは、たとえば、ＬＡＮ（Local Area Network）、電話網（たとえば、携帯電話網や固定電話網など）、地域ＩＰ（Internet Protocol）網などの通信ネットワークを含んでもよい。また、ネットワークＮには、有線ネットワークが含まれていてもよいし、無線ネットワークが含まれていてもよい。

（記憶部１２０について）
記憶部１２０は、制御部１３０による制御及び演算に用いられるプログラム及びデータを記憶する。記憶部１２０は、たとえば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置によって実現される。図３に示すように、記憶部１２０は、事業者情報記憶部１２１と、コード情報記憶部１２２と、送金受付履歴記憶部１２３とを有する。

（事業者情報記憶部１２１について）
事業者情報記憶部１２１は、法人アカウントサービスを利用する事業者に関する情報を記憶する。以下に説明するように、法人アカウントサービスでは、送金サービスを利用して送金された電子マネーを受け取るために利用されるサブウォレットと、サブウォレットの残高を事業者の銀行口座に払い出すために利用されるメインウォレットとが提供される。図４は、本実施形態に係る事業者情報記憶部に記憶される事業者情報の概要を示す図である。なお、図４は、本実施形態に係る事業者情報の一例を示すものであり、図４に示す例とは異なる形態で構成されていてもよい。

図４に示すように、事業者情報記憶部１２１に記憶される事業者情報は、「事業者ＩＤ」の項目や、「法人アカウントＩＤ」の項目や、「ウォレット」の項目や、「金融機関口座」の項目などの複数の項目を有する。事業者情報が有するこれらの項目は相互に対応付けられている。

「事業者ＩＤ」の項目には、法人アカウントサービスを利用する事業者を識別するための識別情報である事業者ＩＤが記憶される。「法人アカウントＩＤ」の項目には、法人アカウントを識別するための識別情報である法人アカウントＩＤが記憶される。

「ウォレット」の項目には、「メインウォレット」の項目や、「サブウォレット１」の項目や、「サブウォレット２」の項目や、「サブウォレット３」の項目などの複数の項目が含まれている。

「メインウォレット」の項目には、メインウォレットを識別するための識別情報であるメインウォレットＩＤと、メインウォレットに登録されているマネー残高の情報が記憶される。

「サブウォレット１」の項目には、Ａ募金用のサブウォレットを識別するための識別情報であるサブウォレットＩＤと、Ａ募金用のサブウォレットに登録されているマネー残高の情報が記憶される。Ａ募金用のサブウォレットは、Ａ募金に対応するコード情報Ｑを通じてユーザＵから送金（寄付）される電子マネーを受け取るためのサービスに対応付けて設けられる。

「サブウォレット２」の項目には、Ｂ募金用のサブウォレットを識別するための識別情報であるサブウォレットＩＤと、Ｂ募金用のサブウォレットに登録されているマネー残高の情報が記憶される。Ｂ募金用のサブウォレットは、Ｂ募金に対応するコード情報Ｑを通じてユーザＵから送金（寄付）される電子マネーを受け取るためのサービスに対応付けて設けられる。

「サブウォレット３」の項目には、Ｃ募金用のサブウォレットを識別するための識別情報であるサブウォレットＩＤと、Ｃ募金用のサブウォレットに登録されているマネー残高の情報が記憶される。Ｃ募金用のサブウォレットは、Ｃ募金に対応するコード情報Ｑを通じてユーザＵから送金（寄付）される電子マネーを受け取るためのサービスに対応付けて設けられる。

「金融機関口座」の項目には、メインウォレットに紐付けられる金融機関の口座を示す口座番号が記憶される。この口座番号は、ユーザＵから受け取った寄付などの払出先として利用される。なお、金融機関の口座は、ワンタイム口座であってもよい。

なお、事業者情報は、上述した各情報の他に、ユーザＵから受け取った寄付などを払い出す払出サイクルを示す情報を記憶してもよい。この場合、事業者は、法令（たとえば、資金決済法）に定められている滞留規制を順守可能な範囲内で任意のサイクルを設定できる。

（コード情報記憶部１２２について）
コード情報記憶部１２２は、事業者に対して発行したコード情報に関する各種情報を記憶する。図５は、本実施形態に係るコード情報記憶部に記憶されるコード情報の概要を示す図である。なお、図５は、本実施形態に係るコード情報の一例を示すものであり、図５に示す例とは異なる形態で構成されていてもよい。

図５に示すように、コード情報記憶部１２２に記憶されるコード情報に関する各種情報は、「事業者ＩＤ」の項目や、「法人アカウントＩＤ」の項目や、「コードＩＤ」の項目や、「送金先表示名」の項目や、「有効期限」の項目や、「会場」の項目といった複数の項目を有する。コード情報に関する各種情報が有するこれらの項目は相互に対応付けられている。

「事業者ＩＤ」の項目には、法人アカウントサービスを利用する事業者を識別するための識別情報である事業者ＩＤが記憶される。「法人アカウントＩＤ」の項目には、法人アカウントを識別するための識別情報である法人アカウントＩＤが記憶される。

「コードＩＤ」の項目には、事業者に対して発行したコードを識別するための識別情報であるコードＩＤが記憶される。「送金先表示名」の項目には、資金調達のために事業者が立ち上げたプロジェクトの名称を示す情報が記憶される。たとえば、「送金先表示名」の項目に記憶されるプロジェクトの名称は、端末装置１０によりコード情報の読取が行われた際、端末装置１０において送金先（たとえば、「Ａ募金」）として表示される。

「有効期限」の項目には、コード情報が有効な状態で機能できる期限として予め設定される日付を示す情報が記憶される。「会場」の項目には、事業者により決定されたコード情報の設置場所を示す情報が記憶される。

図５によれば、事業者ＩＤが「Ｇ＃００１」である事業者の法人アカウント：「Ｈ＃００１」に紐付けて発行されたコードＩＤ：「Ｃ＃００１」のコード情報の送金先表示名が「Ａ募金」であり、有効期限が「２０２２年１月３１日」であり、会場が「Ｘ会場」であることが示されている。

（送金受付履歴記憶部１２３について）
送金受付履歴記憶部１２３は、事業者に対する送金の受付履歴を示す情報が記憶される。図６は、本実施形態に係る送金受付履歴記憶部に記憶される送金の受付履歴を示す情報の概要を示す図である。なお、図６は、本実施形態に係る送金の受付履歴を示す情報の一例を示すものであり、図６に示す例とは異なる形態で構成されていてもよい。たとえば、送金の受付履歴を示す情報は、「法人アカウントＩＤ」の項目を有していなくてもよい。

図６に示すように、送金受付履歴記憶部１２３に記憶される送金の受付履歴を示す情報は、「事業者ＩＤ」の項目や、「法人アカウントＩＤ」の項目や、「送金受付日」の項目や、「送金金額」の項目や、「送金元ＩＤ」の項目や、「送金先表示名」の項目や、「会場」の項目といった複数の項目を有する。送金の受付履歴を示す情報が有するこれらの項目は相互に対応付けられている。

「事業者ＩＤ」の項目には、法人アカウントサービスを利用する事業者を識別するための識別情報である事業者ＩＤが記憶される。「法人アカウントＩＤ」の項目には、法人アカウントを識別するための識別情報である法人アカウントＩＤが記憶される。

「送金受付日」の項目には、ユーザＵからの送金要求を受け付けた日付（送金要求の受信日）を示す情報が記憶される。「送金金額」の項目には、ユーザＵからの送金要求に含まれる送金金額を示す情報が記憶される。

「送金元ＩＤ」の項目には、送金要求の送金元を示す情報（ユーザＩＤ）が記憶される。「送金先表示名」の項目には、送金要求の送信に際してユーザＵにより読み取られたコード情報Ｑに紐付くプロジェクトの名称を示す情報が記憶される。「会場」の項目には、送金要求の送信に際してユーザＵにより読み取られたコード情報Ｑの設置会場を示す情報が記憶される。

情報処理装置１００は、事業者からの要求に応じて、送金の受付履歴を示す情報を、コード情報ごと事業者に提供できる。たとえば、情報処理装置１００は、コード情報に紐付く送金先表示名ごとに送金の受付履歴を取りまとめて、事業者に提供できる。

（制御部１３０について）
制御部１３０は、情報処理装置１００の制御や演算を実行するコントローラ（controller）である。制御部１３０の各部は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などによって、情報処理装置１００の内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）、ＳｏＣ（System on a Chip）などの集積回路により実現される。

図３に示すように、制御部１３０は、コード発行部１３１と、送金受付部１３２と、残高処理部１３３とを有する。制御部１３０は、図３に示す各部により、以下に説明する情報処理の機能や作用を実現または実行する。

（コード発行部１３１について）
コード発行部１３１は、他のアカウントからの送金を受付可能とする法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、事業者を送金先として所定の目的での送金を行うための情報が記述されたコード情報を発行する。たとえば、コード情報には、事業者が募金活動や資金調達のために立ち上げたプロジェクトごとに予め用意された送金画面（ウェブページ）にアクセスするための情報が記述される。具体的には、コード発行部１３１は、図５で示す各種情報を受け付けて記憶し、各種情報を一意で特定できる情報、たとえば、送金先の事業者を識別するための事業者ＩＤと、上述のプロジェクトを識別するためのコードＩＤとを含むコード情報を発行する。コード発行部１３１は、法人アカウントに紐付けて、事業者に発行したコード情報を管理する。また、コード発行部１３１は、法人アカウントに紐付けて複数のコード情報を発行できる。

（送金受付部１３２について）
送金受付部１３２は、コード発行部１３１により発行されたコード情報を通じて、他のアカウントから送金を受け付ける。具体的には、送金受付部１３２は、コード情報を読み取った端末装置１０から送信される識別情報（送信先の事業者を識別するための事業者ＩＤやプロジェクトを識別するためのコードＩＤ）に基づいて、コード情報記憶部１２１に記憶されているコード情報から、識別情報に対応付けられているプロジェクトの名称（送金先表示名）などを示す情報を取得し、端末装置１０に提供する。また、送金受付部１３２は、他のアカウントから受信した受信情報に含まれる各情報に紐付くコード情報の有効期限が切れている場合、送金元である前記他のアカウントに対してエラー処理を返す。具体的には、送金受付部１３２は、他のアカウント（たとば、ユーザＵ）から送金先の事業者を識別するための事業者ＩＤと上述のプロジェクトを識別するためのコードＩＤを受信した場合、その受信情報に含まれる各情報に紐づくコード情報Ｑ１の有効期限を参照し、受信情報の受付日が有効期限を過ぎている場合（有効期限内にない場合）は、「この寄付用のＱＲコードは有効期限が切れています。」といったエラーメッセージを送信できる。また、送金受付部１３２は、同一の事業者に紐付くコード情報が複数発行されている場合、複数のコード情報のうち、受信情報の受付日が有効期限内である他のコード情報に関する情報を、受信受法の送信元である他のアカウントに提供する。具体的には、送金受付部１３２は、端末装置１０から受信した事業者ＩＤとコードＩＤとに基づいて、コード情報記憶部１２１に記憶されているコード情報の中から、送金要求から取得した各情報に紐づく有効期限を参照する。そして、送金受付部１３２は、端末装置１０から受信した事業者ＩＤとコードＩＤとに紐付く有効期限が切れている場合、さらに、コード情報記憶部１２１に記憶されているコード情報を参照し、送金先の事業者が同一であって、有効期限が切れていない他の寄付のプロジェクトがあるか確認し、有効期限が切れていない他のプロジェクトがある場合、そのプロジェクトの情報を端末装置１０に提供する。なお、プロジェクトの情報はそのプロジェクトの送金画面へリンク可能な情報であってもよいし、コード情報に含まれる寄付会場の情報であってもよいし、送金先表示名であってもよい。

（残高処理部１３３について）
残高処理部１３３は、送金受付部１３２により受け付けられた送金の額に相当する電子マネーを法人アカウントが有するウォレットの残高に加算する。たとえば、残高処理部１３３は、送金受付部１３２により受け付けられた送金の額に相当する電子マネーを、送金の際に読み取られたコード情報に対応するサブウォレットの残高に加算する。また、残高処理部１３３は、法人アカウントごとに、送金が行われた日付を示す情報と、送金の額を示す情報と、送金元を示す情報と、送金先を示す情報とを対応付けて管理する。また、残高処理部１３３は、コード情報を通じて受け付けられた送金に関する情報をコード情報ごとに提供する。

〔３．処理手順〕
次に、図７を用いて、本実施形態に係る情報処理装置１００による処理手順について説明する。図７は、本実施形態に係る情報処理装置の処理手順例を示すフローチャートである。なお、以下に示す処理手順は、情報処理装置１００が有する制御部１３０により繰り返し実行される。

図７に示すように、コード発行部１３１は、法人アカウントに紐付けて、事業者を送金先として所定の目的での送金を行うための情報が記述されたコード情報を発行する（ステップＳ１０１）。

また、送金受付部１３２は、ステップＳ１０１で発行されたコード情報を通じて、他のアカウントから送金を受け付ける（ステップＳ１０２）。

また、残高処理部１３３は、ステップＳ１０２で受け付けられた送金の額に対応する電子マネーを、法人アカウントが有するウォレット（サブウォレット）の残高に加算して（ステップＳ１０３）、図７に示す処理手順を終了する。

〔４．変形例〕
上述してきた本実施形態は、本実施形態に係る情報処理の一例を示したものであり、種々の変更及び応用が可能である。

（４－１．有効期限切れのコード情報について）
たとえば、上述の情報処理の一例において、情報処理装置１００は、有効期限が切れているコード情報Ｑを通じた送金要求が多発する場合、その旨を事業者に通知してもよい。また、情報処理装置１００は、有効期限が切れているコード情報Ｑを通じた送金要求の送信元のアカウントに紐づく位置情報を取得し、取得した位置情報に基づいて、送信要求が送信された地点を推定し、推定結果を事業者に提供してもよい。

（４－２．コード情報に対する上限金額の設定について）
たとえば、上述の情報処理の一例において、情報処理装置１００は、コード情報Ｑに対して、送金を受け付けることが可能な上限金額を設定してもよい。これにより、事業者の想定よりも大きな金額の受取を回避できる。また、上限金額に達した場合には、該当のコード情報Ｑに紐づく有効期限が過ぎていない場合においても、送金の受付を停止し、エラーメッセージを端末側に表示しても良い。具体的には、上限金額に達した場合に、コード関連情報に上限金額に到達したことを示す情報を記憶しておき、それ以降に送金受付部１３２が端末装置１０から事業者ＩＤとコードＩＤを受信した場合に、受信した事業者ＩＤとコードＩＤとに基づいて、コード情報記憶部１２１に記憶されているコード情報の中から上限金額に到達したことを示す情報が付与されている場合、「募金の上限金額に達しました」との情報を端末側に表示する。

（４－３．コード情報に記述される情報について）
上述の情報処理では、コード情報に記述される情報として、送金先の事業者を識別するための識別情報である事業者ＩＤや法人アカウントを識別できる法人アカウントＩＤ、事業者が立ち上げたプロジェクトを識別するための識別情報であるコードＩＤを挙げたが、事業者と事業者が立ち上げたプロジェクトが情報処理装置１００において一意に識別されればよいため、これに限定されない。例えば、一つの識別情報で、情報処理装置１００にて対応する事業者とプロジェクトが識別できるものでもよい。

〔５．ハードウェア構成〕
また、上述してきた本実施形態に係る情報処理装置１００は、たとえば、図８に示すような構成のコンピュータ１０００によって実現される。図８は、本実施形態または変形例に係るサービス提供装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

コンピュータ１０００は、出力装置１０１０、入力装置１０２０と接続され、演算装置１０３０、一次記憶装置１０４０、二次記憶装置１０５０、出力ＩＦ（Interface）１０６０、入力ＩＦ１０７０、ネットワークＩＦ１０８０がバス１０９０により接続された形態を有する。

演算装置１０３０は、一次記憶装置１０４０や二次記憶装置１０５０に格納されたプログラムや入力装置１０２０から読み出したプログラムなどに基づいて動作し、各種の処理を実行する。一次記憶装置１０４０は、ＲＡＭなど、演算装置１０３０が各種の演算に用いるデータを一次的に記憶するメモリ装置である。また、二次記憶装置１０５０は、演算装置１０３０が各種の演算に用いるデータや、各種のデータベースが登録される記憶装置であり、ＲＯＭ（Read Only Memory)、ＨＤＤ、フラッシュメモリ等により実現される。

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

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

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

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

たとえば、コンピュータ１０００が本実施形態に係る情報処理装置１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）を実行することにより、制御部３３０と同様の機能を実現する。すなわち、演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）との協働により、本実施形態に係る情報処理装置１００による処理を実現する。

また、コンピュータ１０００が変形例に係る情報処理装置１００として機能する場合、コンピュータ１０００の演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）を実行することにより、制御部４３０と同様の機能を実現する。すなわち、演算装置１０３０は、一次記憶装置１０４０上にロードされたプログラム（たとえば、情報処理プログラム）との協働により、変形例に係る情報処理装置１００による処理を実現する。

〔６．効果〕
上述してきたように、本実施形態に係る情報処理装置１００は、他のアカウントからの送金を受付可能とする法人向けサービスに関する処理を実行する。また、情報処理装置１００は、コード発行部１３１と、送金受付部１３２と、残高処理部１３３とを有する。コード発行部１３１は、法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、事業者に対して所定の目的での送金を行うために記述されたコード情報を発行する。送金受付部１３２は、コード発行部１３１により発行されたコード情報を通じて、他のアカウントから送金を受け付ける。残高処理部１３３は、送金受付部１３２により受け付けられた送金の額に相当する電子マネーを法人アカウントが有するウォレットの残高に加算する。

また、コード情報は、事業者および所定の目的を識別するための識別情報を含み、送金受付部１３２は、他のアカウントから受信した受信情報に含まれる識別情報に基づいて、所定の目的を示す情報を他のアカウントに提供した後、他のアカウントから所定の目的による送金要求を受け付ける。

このようにして、本実施形態に係る情報処理装置１００によれば、たとえば、送金サービスを利用するユーザＵが、コード情報Ｑを読み取る簡便な操作で送金を行うことが可能となり、送金を行うユーザＵの利便性を高めることができる。この結果、ユーザＵが送金を行う確度を高めることも可能となる。一方、情報処理装置１００によれば、送金サービスを通じた送金を受け取る法人向けサービスを利用する事業者Ｍが、ユーザＵからの送金を受け取るためのシステムを改めて構築する必要がなく、手軽に送金を受け取ることを可能とする。また、情報処理装置１００によれば、事業者Ｍが、ユーザＵからの送金を受け取るためのサービスの契約単位でユーザＵからの送金を受け取ることが可能となり、送金が行われたルートの分析を可能とするとともに、受け取った資金の管理も容易とすることができる。

また、送金受付部１３２は、他のアカウントから受信した受信情報に紐付く前記コード情報の有効期限が切れている場合、前記受信情報の送信元である前記他のアカウントに対してエラー処理を返す。

また、送金受付部１３２は、受信情報に含まれる識別情報に紐付くコード情報の有効期限を参照し、受信情報の受付日が有効期限を過ぎている場合、コード情報の有効期限が切れている旨のメッセージを他のアカウントに提供する。

このようにして、情報処理装置１００は、たとえば、ユーザＵから募金の期間を超えて送金されることを防止できる。

また、送金受付部１３２は、同一の事業者に紐付くコード情報が複数発行されている場合、複数のコード情報のうち、受信情報の受付日が有効期限内である他のコード情報に関する情報を、受信情報の送信元である他のアカウントに提供する。これにより、情報処理装置１００は、たとえば、所定の団体に対して寄付を行おうとしているユーザＵに対して、有益な情報を提供できる。

また、残高処理部１３３は、法人アカウントごとに、送金が行われた日付を示す情報と、送金の額を示す情報と、送金元を示す情報と、送金先を示す情報とを対応付けて、送金の受付履歴として管理する。これにより、情報処理装置１００は、事業者Ｍからの要求に応じて、これらの情報を含む送金受付履歴を提供できる。

また、コード発行部１３１は、法人アカウントに紐付けて複数のコード情報を発行する。また、残高処理部１３３は、コード情報を通じて受け付けられた送金に関する情報をコード情報ごとに提供する。これにより、情報処理装置１００は、送金を受け取るためのサービス契約単位で（たとえば、送金先表示名ごとに）、コード情報ごとに送金受付履歴を提供できる。

〔７．その他〕
以上、本実施形態および変形例のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。

また、上述した情報処理装置１００は、機能によっては外部のプラットフォームなどをＡＰＩ（Application Programming Interface）やネットワークコンピューティングなどで呼び出して実現するなど、その構成を柔軟に変更できる。

また、特許請求の範囲に記載した「部」は、「手段」や「回路」などに読み替えることができる。例えば、制御部は、制御手段や制御回路に読み替えることができる。

また、本願の実施形態に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本願の実施形態は、上記の効果とともに、または上記の効果に代えて、実施形態の記載から当業者にとって明らかな他の効果を奏しうる。

１００ 情報処理装置
１１０ 通信部
１２０ 記憶部
１２１ 事業者情報記憶部
１２２ コード情報記憶部
１２３ 送金受付履歴記憶部
１３０ 制御部
１３１ コード発行部
１３２ 送金受付部
１３３ 残高処理部

Claims (9)

1. 他のアカウントからの送金を受付可能とする法人向けサービスに関する処理を実行する情報処理装置であって、
   前記法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、前記事業者を送金先として所定の目的での送金を行うための情報が記述されたコード情報を発行するコード発行部と、
   前記コード発行部により発行された前記コード情報を通じて、前記他のアカウントから送金を受け付ける送金受付部と、
   前記送金受付部により受け付けられた送金の額に相当する電子マネーを、前記法人アカウントを識別するための識別情報に対応付けて前記所定の目的ごとに設けられるサブウォレットの中から、対応する前記サブウォレットの残高に加算する残高処理部と
   を有し、
   前記コード情報の各々は、
   前記事業者、及び他の前記コード情報とは異なる前記所定の目的を識別するための識別情報を含み、
   前記送金受付部は、
   前記他のアカウントから受信した受信情報に含まれている前記識別情報に基づいて、前記所定の目的を示す情報を前記他のアカウントに提供した後、前記他のアカウントから前記所定の目的による送金要求を受け付け、
   前記残高処理部は、
   所定のタイミングで、前記サブウォレットの残高を、前記事業者のメインウォレットに移行する
   ことを特徴とする情報処理装置。
2. 前記送金受付部は、
   前記他のアカウントから受信した受信情報に含まれている前記事業者および前記所定の目的を識別するための識別情報に基づいて、前記所定の目的を示す情報を前記他のアカウントに提供する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記送金受付部は、
   前記他のアカウントから受信した受信情報に紐付く前記コード情報の有効期限が切れている場合、前記受信情報の送信元である前記他のアカウントに対してエラー処理を返す
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記送金受付部は、
   同一の前記事業者に紐付く前記コード情報が複数発行されている場合、複数の前記コード情報のうち、前記受信情報の受付日が有効期限内である他の前記コード情報に関する情報を、前記受信情報の送信元である前記他のアカウントに提供する
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記送金受付部は、
   前記コード情報を通じて行われた送金が前記他のアカウントからの送金が予め設定される上限金額に到達している場合、前記送金の受付を停止する
   ことを特徴とする請求項１に記載の情報処理装置。
6. 前記送金受付部は、
   前記受信情報に含まれている前記識別情報に対応付けて前記上限金額に到達したことを示す情報が記憶されている場合、前記上限金額に到達している旨を前記受信情報の送信元である端末側に表示する
   ことを特徴とする請求項５に記載の情報処理装置。
7. 有効期限が切れている前記コード情報を通じた送金要求の送信元である前記他のアカウントに紐付く位置情報を取得し、取得した位置情報に基づいて、前記送金要求が送信された地点を推定し、推定結果を前記事業者に提供する制御部
   をさらに有することを特徴とする請求項１に記載の情報処理装置。
8. 他のアカウントからの送金を受付可能とする法人向けサービスに関する処理を実行するコンピュータが実行する情報処理方法であって、
   前記法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、前記事業者を送金先として所定の目的での送金を行うための情報が記述されたコード情報を発行するコード発行工程と、
   前記コード発行工程により発行された前記コード情報を通じて、前記他のアカウントから送金を受け付ける送金受付工程と、
   前記送金受付工程により受け付けられた送金の額に相当する電子マネーを、前記法人アカウントを識別するための識別情報に対応付けて前記所定の目的ごとに設けられるサブウォレットの中から、対応する前記サブウォレットの残高に加算する残高処理工程と
   を含み、
   前記コード情報の各々は、
   前記事業者、及び他の前記コード情報とは異なる前記所定の目的を識別するための識別情報を含み、
   前記送金受付工程は、
   前記他のアカウントから受信した受信情報に含まれている前記識別情報に基づいて、前記所定の目的を示す情報を前記他のアカウントに提供した後、前記他のアカウントから前記所定の目的による送金要求を受け付け、
   前記残高処理工程は、
   所定のタイミングで、前記サブウォレットの残高を、前記事業者のメインウォレットに移行する
   ことを特徴とする情報処理方法。
9. 他のアカウントからの送金を受付可能とする法人向けサービスに関する処理を実行するコンピュータに、
   前記法人向けサービスを利用する事業者に提供される法人アカウントに紐付けて、前記事業者を送金先として所定の目的での送金を行うための情報が記述されたコード情報を発行するコード発行手順と、
   前記コード発行手順により発行された前記コード情報を通じて、前記他のアカウントから送金を受け付ける送金受付手順と、
   前記送金受付手順により受け付けられた送金の額に相当する電子マネーを、前記法人アカウントを識別するための識別情報に対応付けて前記所定の目的ごとに設けられるサブウォレットの中から、対応する前記サブウォレットの残高に加算する残高処理手順と
   を実行させ、
   前記コード情報の各々は、
   前記事業者、及び他の前記コード情報とは異なる前記所定の目的を識別するための識別情報を含み、
   前記送金受付手順は、
   前記他のアカウントから受信した受信情報に含まれている前記識別情報に基づいて、前記所定の目的を示す情報を前記他のアカウントに提供した後、前記他のアカウントから前記所定の目的による送金要求を受け付け、
   前記残高処理手順は、
   所定のタイミングで、前記サブウォレットの残高を、前記事業者のメインウォレットに移行する
   ことを特徴とする情報処理プログラム。

Images