JP6192583B2 - 情報管理装置、決済方法及び決済プログラム - Google Patents

Description

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

近年、店舗やインターネット上での買い物の支払いを電子マネーで決済する技術が知られている。例えば、このような技術では、決済時に電子マネー内に残高不足があった場合、チャージ処理を行う。この技術によれば、電子マネー残高が不足する状況になったとしても、決済手順を中断することなく、電子マネーをチャージすることができるとも考えられる。

特開２００９−７５９８６号公報

しかしながら、上記の従来技術では、売買取引を取り止める利用者を減らすことができるとは限らない。具体的には、上記の従来技術では、利用者が契約する金融機関の口座からチャージ金額を引き出すことによりチャージ処理を行う。このため、銀行口座やクレジットカードを持っていない利用者は、電子マネーをチャージすることができないので、売買取引を取り止める場合がある。このように、上記の従来技術では、売買取引を取り止める利用者を減らすことができるとは限らない。

本願は、上記に鑑みてなされたものであって、売買取引を取り止める利用者を減らすことができる情報管理装置、決済方法及び決済プログラムを提供することを目的とする。

本願に係る情報管理装置は、売買取引の支払いの決済要求を受け付ける受付部と、前記受付部によって受け付けられた決済要求に対応する売買取引の支払い可否を判定する判定部と、前記判定部によって前記売買取引の支払いが不可であると判定された場合に、前記売買取引を未払い取引として登録する登録部と、前記登録部によって前記未払い取引として登録される売買取引の前記決済要求を未払いの状態で受け付けた旨を通知する通知部とを備えたことを特徴とする。

実施形態の一態様によれば、売買取引を取り止める利用者を減らすことができるという効果を奏する。

図１は、実施形態に係る情報管理システムによる決済処理の一例を示す説明図である。 図２は、実施形態に係る情報管理装置の構成例を示す図である。 図３は、実施形態に係る注文情報記憶部の一例を示す図である。 図４は、実施形態に係る口座情報記憶部の一例を示す図である。 図５は、実施形態に係る端末装置の構成例を示す図である。 図６は、実施形態に係る端末装置による未払い注文処理の一例を示す説明図である。 図７は、実施形態に係る端末装置による支払い処理の一例を示す説明図である。 図８は、実施形態に係る端末装置による入金処理の一例を示す説明図である。 図９は、実施形態に係る端末装置による注文処理の一例を示す説明図である。 図１０は、情報管理装置による受付処理手順を示すフローチャートである。 図１１は、情報管理装置による決済処理手順を示すフローチャートである。 図１２は、変形例に係る口座情報記憶部の一例を示す図である。 図１３は、情報管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

〔１．決済処理〕
まず、図１を用いて、実施形態に係る決済処理の一例について説明する。図１は、実施形態に係る情報管理システムによる決済処理の一例を示す説明図である。図１の例では、情報管理装置１００によって未払いの売買取引（例えば、注文）の支払いを決済する決済処理が行われる例を示す。なお、図１に示すユーザＵ１１は、クレジットカードや銀行口座を有していないものとする。

サーバ装置１０は、ＥＣサイトのウェブページを提供するウェブサーバ等である。例えば、サーバ装置１０は、インターネットを介して商品を購入することができるショッピングサイトやオークションサイトのウェブページを提供する。

端末装置２０は、ユーザによって利用される情報処理装置である。端末装置２０は、ユーザの注文操作によってＥＣサイトで出品されている商品の注文を行う。また、端末装置２０は、ユーザがＥＣサイトで注文した商品の支払いを行う。例えば、端末装置２０は、予めインストールされた電子マネーで決済するアプリケーションである決済アプリによって注文の支払いを実行する。ここでは、電子マネーは、情報管理装置１００によって管理されるものとする。例えば、電子マネーは、情報管理装置１００によって管理される口座に予め入金されることで決済可能となるプリペイド型のものとする。

情報管理装置１００は、注文の決済を行うウェブサーバ等である。例えば、情報管理装置１００は、商品の代金が未払いの状態で注文が完了された後に、注文の決済を受け付ける。この点について図１を用いて詳細に説明する。

図１に示すように、端末装置２０を有するユーザＵ１１は、サーバ装置１０が提供するＥＣサイトで商品Ａの注文をしたものとする（ステップＳ１）。その後、端末装置２０は、商品Ａの注文の支払いの決済要求を情報管理装置１００に送信する（ステップＳ２）。ここで、決済要求には、商品Ａの買い手（例えば、注文主）や商品Ａの支払額などといった決済に関する各種の決済情報が含まれる。具体的には、端末装置２０は、ユーザの起動操作によって決済アプリを起動する。そして、端末装置２０は、ユーザＵ１１の決済アプリにおける支払い操作によって商品Ａの代金の支払いを実行することで決済情報を含む決済要求を情報管理装置１００に送信する。これにより、情報管理装置１００は、商品Ａの注文の支払いの決済要求を受け付ける。

そして、情報管理装置１００は、受け付けられた決済要求に対応する注文の支払い可否を判定する。一例としては、情報管理装置１００は、決済要求に対応する商品Ａの注文の支払額が、注文の注文主であるユーザＵ１１によって予め入金される入金額の残高を超過するか否かを判定する（ステップＳ３）。例えば、情報管理装置１００は、受け付けられた商品Ａの注文の支払額が、ユーザＵ１１が有する電子マネーの口座の残高を超過するか否かを判定する。

ここで、情報管理装置１００は、商品Ａの注文の支払額がユーザＵ１１の口座の残高を超過すると判定したものとする。この場合、情報管理装置１００は、ユーザＵ１１の商品Ａの注文を未払い取引（例えば、未払い注文）として登録する（ステップＳ４）。例えば、情報管理装置１００は、ユーザＵ１１の商品Ａの注文を、代金の決済が完了していない未払い注文の一覧である未払いリストへ登録する。

そして、情報管理装置１００は、未払い注文として登録された注文の決済要求を未払いの状態で受け付けた旨を通知する（ステップＳ５）。例えば、情報管理装置１００は、商品Ａの注文の決済要求を未払いの状態で受け付けた旨をサーバ装置１０に通知する。そして、サーバ装置１０は、情報管理装置１００から商品Ａの注文が未払いである旨を受け付けた場合に、未払い注文として商品Ａの注文手続きを完了する（ステップＳ６）。その後、サーバ装置１０は、商品Ａの注文の決済要求を未払いの状態で受け付けた旨をＥＣサイトに商品Ａを出品する売り手（例えば、出品者）に通知する。これにより、出品者は、商品Ａの取り置きを行う。

また、情報管理装置１００は、商品Ａの注文が未払い注文として登録された場合に、注文の決済要求を未払いの状態で受け付けた旨を、端末装置２０に通知する（ステップＳ７）。なお、情報管理装置１００は、ステップＳ５またはステップＳ７における通知のいずれか一方のみを通知してもよい。ここで、情報管理装置１００がステップＳ７における通知のみを通知する場合には、端末装置２０は、注文の決済要求を未払いの状態で受け付けた旨をサーバ装置１０に通知する。また、ステップＳ７における通知は、情報管理装置１００に限らずサーバ装置１０が端末装置２０に通知してもよい。

その後、端末装置２０は、ユーザＵ１１の決済アプリにおける入金操作によってユーザＵ１１の口座に電子マネーをチャージする（ステップＳ８）。例えば、端末装置２０は、電子マネーを取り扱う店舗に設置されたチャージ端末を介して電子マネーを口座にチャージする。これにより、情報管理装置１００は、ユーザＵ１１の口座への入金を受け付ける。例えば、情報管理装置１００は、ユーザごとに口座の残高が記憶された口座情報記憶部１２２のうち、ユーザＵ１１に対応する口座の残高に入金された入金額を加算する。

続いて、端末装置２０は、決済アプリを介して未払い注文の支払いの決済要求を情報管理装置１００に送信する（ステップＳ９）。そして、情報管理装置１００は、未払い注文の支払いの決済要求が受け付けられた場合に、ユーザＵ１１の口座から未払い注文の支払額を引き落とす（ステップＳ１０）。

そして、情報管理装置１００は、ユーザＵ１１の口座から未払い注文の支払額が引き落とされた場合に、未払い注文の決済が完了した旨をサーバ装置１０に通知する（ステップＳ１１）。その後、サーバ装置１０は、未払い注文の決済が完了した旨を商品Ａの出品者に通知する。そして、商品Ａの出品者は、ユーザＵ１１に商品Ａを発送する（ステップＳ１２）。

このように、実施形態に係る情報管理装置１００は、売買取引の支払いの決済要求を受け付ける。また、情報管理装置１００は、受け付けられた売買取引の支払額が、売買取引の買い手によって予め入金される入金額の残高を超過するか否かを判定する。また、情報管理装置１００は、支払額が残高を超過すると判定された場合に、売買取引を未払い取引として登録する。また、情報管理装置１００は、未払い取引として登録される売買取引の決済要求を未払いの状態で受け付けた旨を通知する。また、情報管理装置１００は、残高への入金を受け付ける。また、情報管理装置１００は、未払い取引の支払いの決済要求を受け付ける。また、情報管理装置１００は、未払い取引の支払いの決済要求が受け付けられた場合に、入金された残高から未払い取引の支払額を引き落とす。また、情報管理装置１００は、残高から未払い取引の支払額が引き落とされた場合に、未払い取引の決済が完了した旨を通知する。

これにより、情報管理装置１００は、支払額が口座の残高を超過していても銀行口座やクレジットカードを使わずに注文手続きを完了することができるので、注文を取り止める利用者を減らすことができる。例えば、情報管理装置１００は、銀行口座やクレジットカードを持っていないため注文を完了できず商品の購入をあきらめて注文を取り止める利用者を減らすことができる。

また、情報管理装置１００は、ユーザが銀行の口座やクレジットカードを持っていなくても中断することなく注文手続きを完了させることができるので、利用者の客層を広げることができる。例えば、情報管理装置１００は、銀行の口座やクレジットカードを持っていない学生などの客層やクレジットカードを使用しない高齢者などの客層の利便性を向上させることができるので、商品の注文数を増やすことができる。

また、情報管理装置１００は、残高不足でも商品の注文を受け付けることができるので、ユーザの手間を軽減することができる。例えば、情報管理装置１００は、注文時に口座の残高が支払額を超えるように入金するユーザの手間を削減することができる。

また、情報管理装置１００は、残高不足でも商品の注文を受け付けることができるので、ユーザの利便性を向上させることができる。例えば、情報管理装置１００は、ユーザが口座に入金後再び商品を注文して商品を購入する際に商品が在庫切れで購入できないといった事態を防ぐことができる。

また、情報管理装置１００は、注文を取り止める利用者を減らすとともにユーザの利便性を向上させることができるので、商品の注文数を増やすことができる。このため、情報管理装置１００は、出品者が商品を販売することで得られる売上を向上させることができる。

また、情報管理装置１００は、支払額と残高との間の不足分をユーザが入金すればよいので、ユーザが無駄に口座に入金することを回避することができる。

また、情報管理装置１００は、ユーザが希望するタイミングで未払い注文の決済をすることができるので、決済にかかる手間を軽減することができる。例えば、情報管理装置１００は、店舗が混雑しているときなどを回避して決済することができるので、ユーザや店舗の店員にかかる負荷を軽減することができる。

〔２．情報管理装置の構成〕
次に、図２を用いて、実施形態に係る情報管理装置１００の構成について説明する。図２は、実施形態に係る情報管理装置１００の構成例を示す図である。図２に示すように、情報管理装置１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、情報管理装置１００は、情報管理装置１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。

（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ等によって実現される。かかる通信部１１０は、ネットワークと有線又は無線で接続され、ネットワークＮを介して、サーバ装置１０や端末装置２０との間で情報の送受信を行う。

（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random Access Memory)、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。かかる記憶部１２０は、決済情報記憶部１２１と口座情報記憶部１２２とを有する。

（決済情報記憶部１２１について）
決済情報記憶部１２１は、注文の決済に関する決済情報を記憶する。具体的には、決済情報記憶部１２１は、サーバ装置１０や端末装置２０から送信された決済要求に含まれる決済情報を記憶する。ここで、図３に、実施形態に係る決済情報記憶部１２１の一例を示す。図３に示すように、決済情報記憶部１２１は、「決済ＩＤ」、「注文主」、「ユーザＩＤ」、「支払額」、「支払有無」といった項目を有する。

「決済ＩＤ」は、決済情報を識別するための識別情報を示す。「注文主」は、注文を行った注文主であるユーザを示す。「ユーザＩＤ」は、注文主であるユーザを識別するための識別情報を示す。「支払額」は、注文された商品の代金を示す。なお、「支払額」には、商品を注文主へ発送するための送料などが含まれてもよい。「支払有無」は、注文の支払いが完了したか否かを示す。例えば、注文の支払額が支払われることで注文の決済が完了した場合には、「支払有無」に「１」が記憶される。一方、注文の支払額が決済されていない場合には、「支払有無」に「０」が記憶される。

すなわち、図３では、決済ＩＤ「Ｐ１１」の決済情報は、ユーザＩＤが「Ｕ１１」の注文主「ユーザＡ」によってされた注文の決済に関する情報である例を示している。また、決済ＩＤ「Ｐ１１」の決済情報に対応する注文は、支払額が「２０００」円である例を示している。また、決済ＩＤ「Ｐ１１」の決済情報に対応する注文は、支払いがされていない例を示している。

（口座情報記憶部１２２について）
口座情報記憶部１２２は、ユーザが有する口座に関する情報を記憶する。具体的には、口座情報記憶部１２２は、ユーザごとに、口座の残高を記憶する。ここで、図４に、実施形態に係る口座情報記憶部１２２の一例を示す。図４に示すように、口座情報記憶部１２２は、「ユーザＩＤ」、「ユーザ名」、「残高」といった項目を有する。

「ユーザＩＤ」は、ユーザが有する口座を識別するための識別情報を示す。「ユーザ名」は、口座の持ち主であるユーザの氏名を示す。「残高」は、口座に入金されている電子マネーの総額を示す。

すなわち、図４では、ユーザＩＤ「Ｕ１１」のユーザＡの口座には、「１０００」円分の電子マネーが預金されている例を示している。

（制御部１３０について）
制御部１３０は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、情報管理装置１００内部の記憶装置に記憶されている各種プログラム（受付プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

かかる制御部１３０は、図２に示すように、受付部１３１と、判定部１３２と、登録部１３３と、通知部１３４と、入金部１３５と、決済部１３６とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図２に示した構成に限られず、後述する商品管理処理を行う構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図２に示した接続関係に限られず、他の接続関係であってもよい。

（受付部１３１について）
受付部１３１は、売買取引（例えば、注文）の支払いの決済要求を受け付ける。具体的には、受付部１３１は、端末装置２０から売買取引の決済に関する各種の決済情報が含まれる決済要求を受け付ける。例えば、受付部１３１は、端末装置２０の決済アプリを介して、「決済ＩＤ」、「注文主」、「ユーザＩＤ」、「支払額」、「支払有無」といった決済情報が含まれる決済要求を受け付ける。そして、受付部１３１は、決済要求に含まれる決済情報を決済情報記憶部１２１に格納する。

また、受付部１３１は、未払い取引の支払いの決済要求を受け付ける。例えば、受付部１３１は、端末装置２０の決済アプリを介して、「ユーザＩＤ」などが含まれる未払い注文の支払いの決済要求を受け付ける。

なお、受付部１３１は、端末装置２０に限らず、サーバ装置１０から決済要求に含まれる各種の決済情報を受け付けてもよい。

（判定部１３２について）
判定部１３２は、売買取引の支払いの決済の可否を判定する。具体的には、判定部１３２は、受付部１３１によって受け付けられた決済要求に対応する売買取引の支払い可否を判定する。一例としては、判定部１３２は、受付部１３１によって受け付けられた決済要求に対応する売買取引の支払額が、売買取引の買い手によって予め入金される入金額の残高を超過するか否かを判定する。より具体的には、判定部１３２は、決済要求に対応する売買取引の支払額を決済情報記憶部１２１から取得する。また、判定部１３２は、決済要求の送信元であるユーザの口座の残高を口座情報記憶部１２２から取得する。そして、判定部１３２は、取得した支払額が残高を超過するか否かを判定する。

この点について、図３および図４を用いて説明する。図３の例では、決済ＩＤ「Ｐ１１」の決済情報に対応するユーザＡの注文の支払額は、「２０００」円である。また、図４の例では、ユーザＡの口座の残高は、「１０００」円である。この場合、判定部１３２は、支払額として「２０００」円を決済情報記憶部１２１から取得する。また、判定部１３２は、残高として「１０００」円を口座情報記憶部１２２から取得する。そして、判定部１３２は、注文の支払額「２０００」円が口座の残高「１０００」円より大きいので、支払額が口座の残高を超過すると判定する。

（登録部１３３について）
登録部１３３は、所定の注文を未払い取引として登録する。具体的には、登録部１３３は、判定部１３２によって売買取引の支払いが不可であると判定された場合に、売買取引を未払い取引として登録する。一例としては、判定部１３２は、判定部１３２によって売買取引の支払額が買い手の残高を超過すると判定された場合に、売買取引を未払い取引として登録する。例えば、登録部１３３は、注文の支払額が注文主の残高を超過すると判定された場合に、決済情報記憶部１２１の支払有無に「０」を格納することで注文を未払い注文として登録する。

この点について、図３および図４を用いて説明する。図３および図４の例では、上述したように、判定部１３２は、注文の支払額「２０００」円が口座の残高「１０００」円より大きいので、支払額が口座の残高を超過すると判定する。このため、登録部１３３は、決済ＩＤ「Ｐ１１」の決済情報に対応する注文を未払い注文として登録する。例えば、登録部１３３は、決済情報記憶部１２１に記憶された決済ＩＤ「Ｐ１１」の支払有無に「０」を格納することで注文を未払い注文として登録する。

一方、図３に示すように、決済ＩＤ「Ｐ２１」の決済情報に対応するユーザＢの注文の支払額は、「５０００」円である。また、図４に示すように、ユーザＢの口座の残高は、「６０００」円である。この場合、判定部１３２は、注文の支払額「５０００」円が口座の残高「６０００」円より少ないので、支払額が口座の残高を超過しないと判定する。このため、登録部１３３は、決済ＩＤ「Ｐ２１」の決済情報に対応する注文を未払い注文として登録しない。この場合、登録部１３３は、決済情報記憶部１２１の支払有無に「１」を格納する。

（通知部１３４について）
通知部１３４は、各種の情報を通知する。具体的には、通知部１３４は、登録部１３３によって未払い注文として登録された注文の決済要求を未払いの状態で受け付けた旨を通知する。例えば、通知部１３４は、注文の決済要求を未払いの状態で受け付けた旨をサーバ装置１０にする。そして、サーバ装置１０は、注文の決済要求を未払いの状態で受け付けた旨を商品の出品者に通知する。これにより、出品者は、未払いの状態で受け付けた注文の商品を取り置くことができる。

また、通知部１３４は、注文の決済要求を未払いの状態で受け付けた旨を注文主の端末装置２０に通知する。これにより、注文主は、注文の支払いの決済が完了していないことを把握することができる。

また、通知部１３４は、決済が完了した旨を通知する。例えば、通知部１３４は、後述の決済部１３６によって注文主の残高から未払い注文の支払額が引き落とされた場合に、決済要求の決済が完了した旨をサーバ装置１０や端末装置２０に通知する。これにより、サーバ装置１０は、出品者に対して商品を注文主に発送する指示を出すことができる。また、注文主は、注文の決済が完了したことを把握することができる。

また、通知部１３４は、残高が不足している旨を通知する。例えば、通知部１３４は、判定部１３３によって未払い注文の支払額が残高を超過すると判定された場合に、残高が不足している旨を端末装置２０に通知する。これにより、注文主は、残高不足で注文の決済を完了することができない旨を把握することができる。

（入金部１３５について）
入金部１３５は、残高への入金を受け付ける。具体的には、入金部１３５は、注文主の端末装置２０の決済アプリを介して、注文主によって指定された入金額を注文主の残高に加算することで入金する。より具体的には、入金部１３５は、口座情報記憶部１２２に記憶された「残高」に入金額を加算することで入金する。例えば、入金部１３５は、端末装置２０の決済アプリに表示された入金額を示すバーコードを用いて、電子マネーを取り扱う店舗に入金額がユーザによって支払われた場合に、残高への入金を受け付ける。

（決済部１３６について）
決済部１３６は、注文主の残高から注文の支払額を引き落とす。具体的には、決済部１３６は、判定部１３２によって注文の支払額が残高を超過しないと判定された場合に、入金部１３５によって入金された注文主の残高から注文の支払額を引き落とす。例えば、決済部１３６は、口座情報記憶部１２２に記憶された残高から支払額を減算して更新することで注文の支払いを決済する。

また、決済部１３６は、判定部１３２によって未払い注文の支払額が残高を超過しないと判定された場合に、入金部１３５によって入金された注文主の残高から未払い注文の支払額を引き落とす。そして、決済部１３６は、決済情報記憶部１２１に記憶されている支払有無の「０」を「１」に更新する。

〔３．端末装置の構成〕
次に、図５を用いて、実施形態に係る端末装置２０の構成について説明する。図５は、実施形態に係る端末装置の構成例を示す図である。図５に示す端末装置２０は、商品の注文や口座への入金、決済を行うユーザなどによって利用される情報処理装置である。例えば、端末装置２０は、スマートフォンや、タブレット端末や、携帯電話機、ＰＣ（Personal Computer）等である。図５に示すように、端末装置２０は、表示部２１０と、入力部２２０と、通信部２３０と、制御部２５０とを有する。

（表示部２１０、入力部２２０について）
表示部２１０は、各種情報を表示するための表示デバイスである。例えば、表示部２１０は、液晶ディスプレイ等によって実現される。入力部２２０は、ユーザから各種操作を受け付ける入力デバイスである。なお、端末装置２０がスマートフォンである場合にはタッチパネルが採用されているので、表示部２１０と入力部２２０とは一体化される。

（通信部２３０について）
通信部２３０は、ネットワークに接続され、ネットワークを介して、サーバ装置１０や情報管理装置１００などとの間で情報の送受信を行う。かかる通信部２３０は、ネットワークとの接続を有線又は無線で行う。

（制御部２５０について）
制御部２５０は、例えば、ＣＰＵやＭＰＵ等によって、端末装置２０内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部２５０は、例えば、ＡＳＩＣやＦＰＧＡ等の集積回路により実現される。

かかる制御部２５０は、図６に示すように、各種アプリ制御部２６０と、決済アプリ制御部２７０と、表示制御部２７２とを有する。

（各種アプリ制御部２６０について）
各種アプリ制御部２６０は、例えば、検索アプリ制御部２６２と、ブラウザ制御部２６３とを有する。検索アプリ制御部２６２は、端末装置２０内の各種情報を検索する検索アプリケーションを実行制御する。ブラウザ制御部２６３は、ウェブブラウザと呼ばれるアプリケーションを実行制御する。

なお、制御部２５０は、図５に示した検索アプリ制御部２６２及びブラウザ制御部２６３のアプリ制御部に限られず、端末装置２０にインストールされているアプリケーション毎に、かかるアプリケーションを実行制御するアプリ制御部を有する。例えば、制御部２５０は、天気予報サイトにアクセスするアプリケーションを実行制御するアプリ制御部や、オークションサイトにアクセスするアプリケーションを実行制御するアプリ制御部などを有してもよい。

（決済アプリ制御部２７０について）
決済アプリ制御部２７０は、注文した商品の代金を決済する決済アプリケーションを実行制御する。このような決済アプリケーションは、予め端末装置２０にインストールされていてもよいし、ユーザ操作に従ってサーバ装置（例えば、各種アプリケーションを提供するサーバ装置）からダウンロードされることで端末装置２０にインストールされてもよい。かかる決済アプリ制御部２７０は、図５に示すように、受付部２７１と、送信部２７３とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、決済アプリ制御部２７０の内部構成は、図５に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部２５０及び決済アプリ制御部２７０が有する各処理部の接続関係は、図５に示した接続関係に限られず、他の接続関係であってもよい。

（受付部２７１について）
受付部２７１は、各種の操作を受け付ける。具体的には、受付部２７１は、端末装置２０を有するユーザから注文の決済を行う支払い操作や口座に入金する入金操作、口座の残高を照会する照会操作などを受け付ける。

また、受付部２７１は、各種の通知を受け付ける。具体的には、受付部２７１は、注文を未払い注文として受け付けた旨や決済が完了した旨、残高が不足している旨などを情報管理装置１００から受け付ける。そして、受付部２７１によって受け付けられた各種の通知は、後述の表示制御部２７２による制御によって表示部２１０に表示される。

（表示制御部２７２について）
表示制御部２７２は、表示部２１０の表示を制御する。具体的には、表示制御部２７２は、代金を未払いの状態で商品を注文する未払い注文処理や注文の支払いを行う支払い処理、口座へ入金する入金処理、代金を決済した上で注文する注文処理などにおけるウェブページの画面遷移を制御する。この点について、図６〜図９を用いて一例を説明する。

図６は、実施形態に係る端末装置による未払い注文処理の一例を示す説明図である。受付部２７１は、ユーザから商品を注文する注文操作を受け付けたものとする。図６に示すように、表示制御部２７２は、注文の請求金額が表示された注文を確認するウェブページＷ１１を表示部２１０に表示する。

ここで、請求金額は、ユーザの口座の残高を超過するものとする。この場合、受付部２７１は、情報管理装置１００から残高が不足している旨の通知を受け付ける。そして、表示制御部２７２は、受付部２７１によってユーザから商品の注文を確定する確定操作がされた場合に、残高が不足していることを示すウェブページＷ１２を表示部２１０に表示する。

続いて、受付部２７１は、例えば、ユーザからウェブページＷ１２を下方向にスワイプすることで未払いの状態で商品を注文する未払い注文操作を受け付けたものとする。この場合、受付部２７１は、情報管理装置１００から注文が完了した旨の通知を受け付ける。そして、表示制御部２７２は、注文が完了したことを示すウェブページＷ１３を表示部２１０に表示する。

図７は、実施形態に係る端末装置による支払い処理の一例を示す説明図である。受付部２７１は、決済アプリの支払処理を実行する操作を受け付けたものとする。この場合、表示制御部２７２は、図７に示すように、支払い対象となる注文の請求金額などが表示されたウェブページＷ２１を表示部２１０に表示する。

ここで、請求金額は、ユーザの残高以下であるものとする。この場合、受付部２７１は、受付部２７１によってユーザから支払いの確認画面へ遷移する確認操作がされた場合に、支払額が残高を超過していない旨の通知を情報管理装置１００から受け付ける。そして、表示制御部２７２は、残高と支払額が表示されたウェブページＷ２２を表示部２１０に表示する。

そして、受付部２７１は、ユーザからウェブページＷ２２を上方向にスワイプすることで注文の支払を行う支払い操作を受け付けたものとする。この場合、受付部２７１は、注文の支払いの決済が完了した旨の通知を情報管理装置１００から受け付ける。そして、表示制御部２７２は、支払いが完了したことを示すウェブページＷ２３を表示部２１０に表示する。

図８は、実施形態に係る端末装置による入金処理の一例を示す説明図である。受付部２７１は、決済アプリの入金処理を実行する操作を受け付けたものとする。この場合、表示制御部２７２は、図８に示すように、口座へ入金する入金額などが表示されたウェブページＷ３１を表示部２１０に表示する。なお、ウェブページＷ３１には、注文の支払額と残高との間の差額である不足額などが表示されてもよい。

ここで、受付部２７１は、ユーザから入金額の選択を受け付けたものとする。この場合、表示制御部２７２は、受付部２７１によって受け付けられた入金額を示すバーコードが表示されたウェブページＷ３２を表示部２１０に表示する。

そして、ユーザは、ウェブページＷ３２に表示されたバーコードを用いて、電子マネーを取り扱うコンビニエンスストアなどの店舗で入金額を支払ったものとする。この場合、受付部２７１は、入金が完了した旨の通知を情報管理装置１００から受け付ける。そして、表示制御部２７２は、入金が完了したことを示すウェブページＷ３３を表示部２１０に表示する。

図９は、実施形態に係る端末装置による注文処理の一例を示す説明図である。受付部２７１は、ユーザから商品を注文する注文操作を受け付けたものとする。この場合、表示制御部２７２は、図９に示すように、注文の請求金額が表示された注文を確認するウェブページＷ４１を表示部２１０に表示する。

ここで、請求金額は、ユーザの口座の残高以下であるものとする。そして、受付部２７１は、ユーザから商品の注文を確定する確定操作を受け付けたものとする。この場合、受付部２７１は、支払額が残高を超過していない旨の通知を情報管理装置１００から受け付ける。そして、表示制御部２７２は、残高と支払額が表示されたウェブページＷ４２を表示部２１０に表示する。

そして、受付部２７１は、例えば、ユーザからウェブページＷ４２を上方向にスワイプすることで商品の注文および決済を行う操作を受け付けたものとする。この場合、決済部１３６は、ユーザの口座から支払額を引き落とす。そして、受付部２７１は、注文および決済が完了した旨の通知を受け付ける。そして、表示制御部２７２は、注文および決済が完了したことを示すウェブページＷ４３を表示部２１０に表示する。

（送信部２７３について）
送信部２７３は、注文の決済に関する決済情報を送信する。具体的には、送信部２７３は、注文主や支払額などといった決済に関する各種の決済情報を情報管理装置１００に送信する。例えば、送信部２７３は、受付部２７１によって支払い操作が受け付けられた場合に、決済情報を情報管理装置１００に送信する。

また、送信部２７３は、入金に関する入金情報を送信する。具体的には、送信部２７３は、入金主や入金額などといった入金に関する各種の入金情報を情報管理装置１００に送信する。例えば、送信部２７３は、受付部２７１によって入金操作が受け付けられた場合に、入金情報を情報管理装置１００に送信する。

〔４．受付処理手順〕
次に、図１０を用いて、実施形態に係る情報管理装置１００による受付処理の手順について説明する。図１０は、実施形態に係る情報管理装置１００による受付処理手順を示すフローチャートである。

図１０に示すように、情報管理装置１００は、端末装置２０から決済要求を受け付けたか否かを判定する（ステップＳ１０１）。そして、情報管理装置１００は、決済要求を受け付けていない場合には（ステップＳ１０１；Ｎｏ）、決済要求を受け付けるまで待機する。

一方、情報管理装置１００は、決済要求を受け付けた場合（ステップＳ１０１；Ｙｅｓ）、受け付けた決済要求に対応する支払額が口座の残高を超過するか否かを判定する（ステップＳ１０２）。そして、情報管理装置１００は、支払額が口座の残高を超過していない場合には（ステップＳ１０２；Ｎｏ）、残高から支払額を引き落とすことで決済する（ステップＳ１０３）。そして、情報管理装置１００は、注文の支払いの決済を完了した旨をサーバ装置１０や端末装置２０に通知する（ステップＳ１０４）。

一方、情報管理装置１００は、支払額が口座の残高を超過する場合（ステップＳ１０２；Ｙｅｓ）、決済要求に対応する注文を未払い注文として登録する（ステップＳ１０５）。そして、情報管理装置１００は、未払い注文を受け付けた旨をサーバ装置１０や端末装置２０に通知する（ステップＳ１０６）。

〔５．決済処理手順〕
次に、図１１を用いて、実施形態に係る情報管理装置１００による決済処理の手順について説明する。図１１は、実施形態に係る情報管理装置１００による決済処理手順を示すフローチャートである。

図１１に示すように、情報管理装置１００は、端末装置２０から未払い注文の決済要求を受け付けたか否かを判定する（ステップＳ２０１）。そして、情報管理装置１００は、未払い注文の決済要求を受け付けていない場合には（ステップＳ２０１；Ｎｏ）、決済要求を受け付けるまで待機する。

一方、情報管理装置１００は、未払い注文の決済要求を受け付けた場合（ステップＳ２０１；Ｙｅｓ）、受け付けた未払い注文の決済要求に対応する支払額が残高を超過するか否かを判定する（ステップＳ２０２）。そして、情報管理装置１００は、未払い注文の支払額が残高を超過している場合には（ステップＳ２０２；Ｙｅｓ）、残高不足である旨を端末装置２０に通知する（ステップＳ２０３）。

一方、情報管理装置１００は、未払い注文の支払額が残高を超過していない場合には（ステップＳ２０２；Ｎｏ）、残高から支払額を引き落とすことで決済する（ステップＳ２０４）。そして、情報管理装置１００は、未払い注文の決済を完了した旨をサーバ装置１０や端末装置２０に通知する（ステップＳ２０５）。

〔６．変形例〕
上述した実施形態に係る情報管理装置１００は、上記実施形態以外にも種々の異なる形態にて実施されてよい。そこで、以下では、上記の情報管理装置１００の他の実施形態について説明する。

〔６−１．未払い取引（１）〕
上記実施形態では、登録部１３３は、判定部１３２によって支払額が残高を超過すると判定された場合に、注文を未払い注文として登録する例を示した。ここで、登録部１３３は、支払額が残高を超過する場合に限らず、残高に関わらず売買取引の買い手（例えば、注文の注文主）によって選択された売買取引を未払い取引として登録してもよい。

具体的には、端末装置２０は、まず、注文が表示されたウェブページを表示部２１０に表示する。例えば、端末装置２０は、図７に示すウェブページＷ２１を表示部２１０に表示する。続いて、端末装置２０は、未払い注文として注文手続きを完了した後に決済を行う注文を選択する選択操作を受け付ける。例えば、端末装置２０は、表示部２１０に表示された注文をユーザがタップする操作を選択操作として受け付ける。そして、端末装置２０は、ユーザによって選択された注文に関する情報を情報管理装置１００に送信する。

これにより、情報管理装置１００の受付部１３１は、未払い注文として注文手続きを完了した後に決済を行う注文の選択をユーザから受け付ける。そして、登録部１３３は、受付部１３１によって受け付けられた注文を未払い注文として登録する。これにより、登録部１３３は、支払額が残高を超過しない場合でも未払い注文として登録することができる。

このように、情報管理装置１００は、売買取引の買い手によって選択された注文を未払い注文として登録する。

これにより、情報管理装置１００は、残高が十分にある場合でも未払い注文として登録することができるので、ユーザが希望する商品の注文を完了した後に決済することができる。このため、情報管理装置１００は、例えば、今は払いたくないなどユーザの都合に合わせて決済をすることができるので、ユーザの利便性を向上させることができる。

〔６−２．未払い取引（２）〕
上記変形例では、登録部１３３は、売買取引の買い手によって選択された注文を未払い注文として登録する例を示した。ここで、登録部１３３は、売買取引の買い手に限らず、売買取引の売り手（例えば、出品者）によって選択された売買取引を未払い取引として登録してもよい。

一例としては、サーバ装置１０は、商品を出品する出品者によって選択された注文手続きを完了した後に決済を行う注文を出品者の出品者端末から受け付ける。そして、サーバ装置１０は、出品者によって選択された注文を情報管理装置１００に送信する。これにより、情報管理装置１００の受付部１３１は、出品者によって選択された注文を受け付ける。そして、登録部１３３は、受付部１３１によって受け付けられた注文を未払い注文として登録する。これにより、登録部１３３は、出品者によって選択された注文を未払い注文として登録することができる。

このように、情報管理装置１００は、売買取引の売り手によって選択された注文を未払い注文として登録する。

これにより、情報管理装置１００は、出品者が希望する注文を未払い注文として登録することができるので、注文を完了した後に決済することができる。このため、情報管理装置１００は、例えば、現時点では商品の在庫がないが将来的に入荷する予定があるので注文を受け付けておきたい場合や商品が予約だけされた場合に決済を後回しにすることができる。これにより、情報管理装置１００は、何らかの原因で入荷できなかった場合に発生する注文をキャンセルする処理などに掛かる手間を回避することができる。

〔６−３．未払い取引（３）〕
上記実施形態では、情報管理装置１００は、判定部１３２によって支払額が残高を超過すると判定された場合に、注文を未払い注文として登録する例を示した。ここで、情報管理装置１００は、買い手が所定の条件を満たすと判定された場合に、売買取引を未払い取引として登録してもよい。

具体的には、情報管理装置１００の判定部１３２は、受付部１３１によって受け付けられた決済要求に対応する売買取引の買い手が所定の条件を満たすか否かを判定する。一例としては、判定部１３２は、買い手の過去の未払い取引の実績が所定の条件を満たすか否かを判定する。例えば、判定部１３２は、買い手の過去の未払い取引のうち、支払いが行われずに取りやめとなった未払い取引の数が所定の閾値未満であるか否かを判定する。

他の例では、判定部１３２は、未払い取引の支払額が上限額未満であるか否かを判定する。例えば、未払い取引の上限額は、情報管理装置１００やサーバ装置１０の管理者、商品の出品者によって予め設定される。なお、上限額は、例えば、買い手ごとに設定されてもよいし、出品者ごとに設定されてもよい。そして、登録部１３３は、判定部１３２によって買い手が所定の条件を満たすと判定された場合に、売買取引を未払い取引として登録する。

このように、情報管理装置１００は、受付部１３１によって受け付けられた決済要求に対応する売買取引の買い手が所定の条件を満たすか否かを判定する。また、登録部１３３は、判定部１３２によって買い手が所定の条件を満たすと判定された場合に、売買取引を未払い取引として登録する。

これにより、情報管理装置１００は、買い手に応じて未払い取引を登録することができるので、出品者の利便性を向上させることができる。例えば、情報管理装置１００は、未払い注文を決済する可能性が低いユーザに対しては未払い取引として登録しないので、注文後に取り止めとなる回数を少なくすることができる。また、情報管理装置１００は、支払額の大きい注文は未払い取引として登録しないので、注文後に取り止めとなった場合のリスクを低減することができる。

〔６−４．自動引き落とし〕
上記実施形態では、決済部１３６は、受付部１３１によって決済要求が受け付けられた場合に、入金部１３５によって入金された残高から未払い注文の支払額を引き落とす例を示した。ここで、決済部１３６は、入金部１３５によって未払い注文の支払額以上の入金が受け付けられた場合に、残高から未払い注文の支払額を引き落としてもよい。

具体的には、まず、入金部１３５は、未払い注文の支払額以上の入金を受け付ける。そして、判定部１３２は、未払い注文の支払額が残高を超過しないと判定する。続いて、決済部１３６は、残高から未払い注文の支払額を引き落とす。これにより、決済部１３６は、未払い注文の支払額以上が入金された場合には、未払い注文の支払いの決済を自動で完了する。

このように、情報管理装置１００は、受付部１３１によって決済要求が受け付けられた場合に、入金部１３５によって入金された残高から未払い注文の支払額を引き落とす。

これにより、情報管理装置１００は、未払い注文の支払額以上が入金されると自動で決済を完了することができるので、ユーザの手間を軽減することができる。例えば、情報管理装置１００は、ユーザが未払い注文の決済を行う手間を削減することができる。

また、情報管理装置１００は、未払い注文の支払額以上が入金されると自動で決済を完了することができるので、注文を取り止める利用者を減らすことができる。例えば、情報管理装置１００は、未払い注文をしたものの決済を行わずに注文をキャンセルする利用者を減らすことができる。

〔６−５．信用度に応じて商品を発送〕
上記実施形態では、出品者は、未払い注文の支払いの決済が完了した後に商品を注文主に発送する例を示した。ここで、出品者は、注文主の信用度が所定の閾値以上である場合に、注文の商品を決済が完了する前に発送してもよい。具体的には、通知部１３４は、未払い注文の注文主の信用度が所定の閾値以上である場合に、未払い注文の商品を発送する指示を通知する。

例えば、情報管理装置１００は、ユーザごとに、信用度に関する情報をユーザＩＤと対応付けて口座情報記憶部１２２に記憶する。図１２は、変形例に係る口座情報記憶部の一例を示す図である。図１２に示すように、口座情報記憶部１２２は、「信用度」の項目をさらに有する。

「信用度」は、ユーザの信用度合を示す。一例としては、信用度は、０から１００の間の数値であって、数値が高いほどユーザの信用が高いことを示す。例えば、ユーザが過去の売買取引で期限内に支払いを行った回数や未払い注文の決済を完了する割合が高いほど信用度が高くなる。一方、ユーザが過去の売買取引で期限内に支払いを行わなかった回数や未払い注文の決済を完了せず取り止める割合が高いほど信用度が低くなる。すなわち、図１２では、ユーザＩＤ「Ｕ１１」のユーザＡは、信用度「１００」である例を示している。

ここで、受付部１３１は、注文の決済要求を付け付けたものとする。そして、判定部１３２は、注文の支払額が残高を超過すると判定したものとする。続いて、登録部１３３は、注文を未払い注文として登録したものとする。

この場合、通知部１３４は、まず、未払い注文の注文主の信用度が所定の閾値以上であるか否かを判定する。そして、通知部１３４は、未払い注文の注文主の信用度が所定の閾値以上であると判定したものとする。この場合、通知部１３４は、未払い注文の商品を発送する指示をサーバ装置１０に通知する。そして、サーバ装置１０は、未払い注文の商品を発送する指示を出品者に通知する。その後、出品者は、未払い注文の商品を注文主に発送する。これにより、信用度の高い注文主は、決済を完了する前でも商品を受け取ることができる。

一方、通知部１３４は、未払い注文の注文主の信用度が所定の閾値未満であると判定した場合には、注文の決済要求を未払いの状態で受け付けた旨をサーバ装置１０に通知する。その後、サーバ装置１０は、未払い注文の決済が完了した旨を情報管理装置１００から受け付けた場合に、注文の商品を発送する指示を出品者に通知する。これにより、信用度の低い注文主は、決済を完了すれば商品を受け取ることができる。

このように、情報管理装置１００は、未払い注文の注文主の信用度が所定の閾値以上である場合に、未払い注文の商品を発送する指示を通知する。

これにより、情報管理装置１００は、信用度に応じて商品を注文主に発送させることができるので、ユーザの利便性を向上させることができる。例えば、情報管理装置１００は、信用度の高いユーザに対して注文した商品を迅速に入手させることができる。

また、情報管理装置１００は、ユーザの信用度が低い場合には決済が完了した後に商品を注文主に発送するので、出品者の利便性を向上させることができる。例えば、情報管理装置１００は、商品を発送した後にユーザが決済を完了せずに出品者が代金を回収できないリスクを抑えることができる。

なお、注文の支払額である商品の代金は、例えば、情報管理装置１００の管理者が立て替えて出品者に支払う。また、上記変形例において説明した注文は、ＥＣサイトにおける仮想店舗に対する注文に限らず、実際に存在する実店舗に対する注文であってもよい。この場合、実店舗は、ユーザの信用度を情報管理装置１００から取得する。そして、実店舗は、取得したユーザの信用度に応じて商品を支払する前に渡すか支払い後に渡すか決定する。

〔６−６．自動キャンセル〕
上記実施形態では、情報管理装置１００は、注文を未払い注文として登録してから所定の期間が経過した場合に、注文を自動的にキャンセルしてもよい。具体的には、登録部１３３は、注文を未払い注文として登録してから所定の期間が経過した場合に、注文を未払い注文から解除する。また、通知部１３４は、登録部１３３によって解除された注文が取り消された旨を通知する。

例えば、商品の出品者は、注文を未払い注文として登録してからキャンセルするまでの所定の期間として３０日を設定したものとする。例えば、情報管理装置１００は、設定された取消期間「３０日」を「決済ＩＤ」と対応付けて決済情報記憶部１２１に記憶する。

そして、登録部１３３は、決済情報記憶部１２１に記憶された取消期間を用いて、注文を未払い注文として登録してから所定の期間が経過したか否かを判定する。例えば、登録部１３３は、注文を未払い注文として登録してから３０日が経過したか否かを判定する。ここで、登録部１３３は、注文を未払い注文として登録してから３０日が経過したと判定した場合に、注文を未払い注文から解除する。例えば、登録部１３３は、未払い注文から解除する注文と対応付けて注文が取り消されたことを示す「キャンセルフラグ」を決済情報記憶部１２１に記憶する。これにより、未払い注文から解除された注文は、キャンセルされたものとみなされる。

そして、通知部１３４は、登録部１３３によって解除された注文が取り消された旨を通知する。例えば、通知部１３４は、注文が取り消された旨を注文主やサーバ装置１０の管理者、商品の出品者に通知する。

なお、注文を未払い注文として登録してからキャンセルするまでの所定の期間は、商品の出品者に限らず、例えば、情報管理装置１００の管理者やサーバ装置１０の管理者によって設定されてもよい。また、登録部１３３は、未払い注文から解除する注文に対応する決済情報を決済情報記憶部１２１から削除することで、キャンセルされたものとみなしてもよい。

このように、情報管理装置１００は、注文を未払い注文として登録してから所定の期間が経過した場合に、注文を未払い注文から解除する。また、情報管理装置１００は、登録部１３３によって解除された注文が取り消された旨を通知する。

これにより、情報管理装置１００は、所定の期間が経過した注文を自動でキャンセルすることができるので、出品者の利便性を向上させることができる。例えば、情報管理装置１００は、注文主が支払いを忘れていても自動で注文をキャンセルするので、出品者が在庫を取り置くことで発生する損失を抑えることができる。

〔６−７．信頼度に応じて自動キャンセル〕
上記変形例では、情報管理装置１００は、注文を未払い注文として登録してから所定の期間が経過した場合に、注文を自動的にキャンセルする例を示した。ここで、情報管理装置１００は、注文主の信用度に応じた所定の期間が経過した場合に、注文を自動的にキャンセルしてもよい。具体的には、情報管理装置１００は、注文を未払い注文として登録してから未払い注文の注文主の信用度に応じた所定の期間が経過した場合に、注文を未払い注文から解除する。

例えば、情報管理装置１００は、注文主の信頼度が高いほど注文を未払い注文として登録してからキャンセルするまでの所定の期間を長く設定する。一方、情報管理装置１００は、注文主の信頼度が低いほど注文を未払い注文として登録してからキャンセルするまでの所定の期間を短く設定する。

すなわち、図１２の例では、情報管理装置１００は、ユーザＡの方がユーザＢより信用度が高いので、注文をキャンセルするまでの所定の期間を、ユーザＢによる注文と比較してユーザＡによる注文の方が長くなるように設定する。例えば、情報管理装置１００は、ユーザＡの注文をキャンセルするまでの所定の期間を５０日に設定する。一方、情報管理装置１００は、ユーザＢの注文をキャンセルするまでの所定の期間を１０日に設定する。

そして、登録部１３３は、注文を未払い注文として登録してから所定の期間が経過したか否かを判定する。ここで、登録部１３３は、注文を未払い注文として登録してから所定の期間が経過したと判定した場合に、注文を未払い注文から解除する。そして、通知部１３４は、登録部１３３によって解除された注文が取り消された旨を通知する。

このように、情報管理装置１００は、注文を未払い注文として登録してから未払い注文の注文主の信用度に応じた所定の期間が経過した場合に、注文を未払い注文から解除する。

これにより、情報管理装置１００は、ユーザの信用度に応じてキャンセルするまでの期間を調整することができるので、出品者の利便性を向上することができる。例えば、情報管理装置１００は、信用度の低いユーザに対してはキャンセルするまでの期間を短く設定するので、出品者が在庫を取り置くことで発生する損失を抑えることができる。一方、情報管理装置１００は、信用度の高いユーザに対してはキャンセルするまでの期間を長く設定するので、注文がキャンセルされることで失われる利益を抑えることができる。

〔６−８．ストック件数に上限〕
上記実施形態では、情報管理装置１００は、未払い注文として登録する注文の上限を設けてもよい。具体的には、情報管理装置１００は、未払い注文の累計が所定の閾値以下である場合に、注文を未払い注文として登録する。

例えば、情報管理装置１００やサーバ装置１０の管理者は、未払い注文として登録可能な注文数の上限を設定する。そして、登録部１３３は、判定部１３２によって支払額が残高を超過すると判定された場合に、注文主の未払い注文数の累計が所定の閾値以下であるか否かを判定する。例えば、登録部１３３は、決済情報記憶部１２１に記憶された「注文主」および「支払有無」を参照して注文主の未払い注文数の累計を算出する。そして、登録部１３３は、未払い注文数の累計が所定の閾値以下である場合に、注文を未払い注文として登録する。一方、未払い注文数の累計が所定の閾値を超過する場合には、通知部１３４は、例えば、未払い注文の上限を超えている旨を注文主に通知する。

なお、所定の閾値は、未払い注文数の累計に限らず、例えば、未払い注文の支払額の累計や未払い注文の経過期間の累計などであってもよい。

このように、情報管理装置１００は、未払い注文の累計が所定の閾値以下である場合に、注文を未払い注文として登録する。

これにより、情報管理装置１００は、未払い注文に制限を付けることができるので、出品者の損失を抑えることができる。例えば、情報管理装置１００は、未払い注文後に注文がキャンセルされることで発生する出品者の損失を抑えることができる。

また、情報管理装置１００は、未払い注文数の累計が所定の閾値を超過すると未払い注文として受け付けないので、未払い注文後に注文をキャンセルする利用者を減らすことができる。

〔６−９．信用度に応じたストック件数〕
上記変形例では、情報管理装置１００は、未払い注文の累計が所定の閾値以下である場合に、注文を未払い注文として登録する例を示した。ここで、情報管理装置１００は、未払い注文の累計が未払い注文の注文主の信用度に応じた所定の閾値以下である場合に、注文を未払い注文として登録してもよい。

例えば、情報管理装置１００は、注文主の信用度が高いほど未払い注文として登録可能な注文数の所定の閾値を高く設定する。すなわち、図１２の例では、情報管理装置１００は、ユーザＡの方がＢより信用度が高いので、未払い注文として登録可能な注文数を、ユーザＢと比較してＡによる注文の方が多くなるように設定する。例えば、情報管理装置１００は、ユーザＡの未払い注文として登録可能な注文数を１０個に設定する。一方、情報管理装置１００は、ユーザＢの未払い注文として登録可能な注文数を２個に設定する。

そして、登録部１３３は、判定部１３２によって支払額が残高を超過すると判定された場合に、注文主の未払い注文数の累計が所定の閾値以下であるか否かを判定する。そして、登録部１３３は、未払い注文数の累計が所定の閾値以下である場合に、注文を未払い注文として登録する。一方、未払い注文数の累計が所定の閾値を超過する場合には、通知部１３４は、例えば、未払い注文の上限を超えている旨を注文主に通知する。

なお、所定の閾値は、未払い注文数の累計に限らず、例えば、未払い注文の支払額の累計や未払い注文の経過期間の累計などであってもよい。

このように、情報管理装置１００は、未払い注文の累計が未払い注文の注文主の信用度に応じた所定の閾値以下である場合に、注文を未払い注文として登録する。

これにより、情報管理装置１００は、注文主の信用度に応じて未払い注文に制限を付けることができるので、出品者の損失を抑えることができる。例えば、情報管理装置１００は、信用度が低い出品者に対しては未払い注文を少なく制限するので、未払い注文後に注文がキャンセルされることで発生する出品者の損失を抑えることができる。一方、情報管理装置１００は、信用度が高い出品者に対しては未払い注文を多く受け付け可能にするので、未払い注文によって出品者が得る利益を増やすことができる。

〔６−１０．リマインド〕
上記実施形態では、情報管理装置１００は、注文主に未払い注文のリマインドをしてもよい。具体的には、情報管理装置１００は、登録部１３３によって登録された未払い注文がある場合に、未払い注文の注文主の端末装置２０に未払いの注文がある旨を通知する。

例えば、通知部１３４は、決済情報記憶部１２１に記憶された支払有無が「０」となっている注文を未払い注文として抽出する。これにより、通知部１３４は、未払い注文として抽出された注文の「ユーザＩＤ」を取得する。そして、通知部１３４は、取得した「ユーザＩＤ」に対応する端末装置２０に未払いの注文がある旨を通知する。これにより、端末装置２０は、未払いの注文がある旨を表示部２１０に表示する。

このように、情報管理装置１００は、登録部１３３によって登録された未払い注文がある場合に、未払い注文の注文主の端末装置２０に未払いの注文がある旨を通知する。

これにより、情報管理装置１００は、注文主に未払い注文があることを把握させることができるので、出品者の利益を増やすことができる。例えば、情報管理装置１００は、注文主の未払い注文の失念を防ぐことができるので、未払い注文の決済が完了する割合を増やすことができる。

〔６−１１．不足額を通知〕
上記変形例では、情報管理装置１００は、登録部１３３によって登録された未払い注文がある場合に、未払い注文の注文主の端末装置２０に未払いの注文がある旨を通知する例を示した。ここで、情報管理装置１００は、未払い注文の支払額に対する残高の不足額を端末装置２０に通知してもよい。

例えば、通知部１３４は、決済情報記憶部１２１に記憶された支払有無が「０」となっている注文を未払い注文として抽出する。これにより、通知部１３４は、未払い注文として抽出された注文の「ユーザＩＤ」と「支払額」とを取得する。そして、通知部１３４は、取得した「ユーザＩＤ」に対応する口座情報記憶部１２２に記憶された「残高」を抽出する。その後、通知部１３４は、取得した「支払額」と「残高」との間の差額を算出する。そして、通知部１３４は、算出した「支払額」と「残高」との間の差額を不足額として「ユーザＩＤ」に対応する端末装置２０に通知する。これにより、端末装置２０は、不足額を表示部２１０に表示する。

このように、情報管理装置１００は、未払い注文の支払額に対する残高の不足額を端末装置２０に通知する。

これにより、情報管理装置１００は、注文主に不足額を把握させることができるので、ユーザの利便性を向上させることができる。例えば、情報管理装置１００は、いくら入金すればよいかを注文主が把握できるので、未払い注文の決済が完了する割合を増やすことができる。

〔６−１２．未払いリスト〕
上記実施形態では、情報管理装置１００は、注文の支払額が注文主の残高を超過すると判定された場合に、決済情報記憶部１２１の支払有無に「０」を格納することで注文を未払い注文として登録する例を示した。ここで、情報管理装置１００は、未払い注文について記憶する記憶部を独立して有してもよい。例えば、情報管理装置１００は、支払いが行われていない注文の決済情報を記憶した未払いリスト記憶部をさらに有する。

これにより、情報管理装置１００は、未払い注文を独立して管理することができるので、未払い注文の管理を容易にすることができる。

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

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

また、上記実施形態において説明した商品は、有体物である商品に限らず、無体物である商品やサービスであってもよい。例えば、商品は、ダウンロードすることで取得する音楽ファイルや動画コンテンツ、証券取引や保険などの金融サービスなどであってもよい。

また、上記実施形態において説明した「売買取引」は、ＥＣサイトを介した商品の「注文」に限らず、各種の形態の取引であってもよい。例えば、売買取引は、オークションサイトを介した「入札」などであってもよい。

〔６−１４．ハードウェア構成〕
また、上述してきた実施形態に係る情報管理装置１００は、例えば図１３に示すような構成のコンピュータ１０００によって実現される。以下、情報管理装置１００を例に挙げて説明する。図１３は、情報管理装置１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、およびメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００またはＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、通信網５０を介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを通信網５０を介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラムまたはデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る情報管理装置１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが格納される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置から通信網５０を介してこれらのプログラムを取得してもよい。

〔７．効果〕
上述してきたように、実施形態に係る情報管理装置１００は、受付部１３１と、判定部１３２と、登録部１３３と、通知部１３４とを有する。受付部１３１は、売買取引（例えば、注文）の支払いの決済要求を受け付ける。判定部１３２は、受付部１３１によって受け付けられた決済要求に対応する売買取引の支払い可否を判定する。登録部１３３は、判定部１３２によって売買取引の支払いが不可であると判定された場合に、売買取引を未払い取引として登録する。通知部１３４は、登録部１３３によって未払い取引として登録される売買取引の決済要求を未払いの状態で受け付けた旨を通知する。

また、実施形態に係る情報管理装置１００において、判定部１３２は、受付部１３１によって受け付けられた決済要求に対応する売買取引の支払額が、売買取引の買い手によって予め入金される入金額の残高を超過するか否かを判定する。また、登録部１３３は、判定部１３２によって支払額が残高を超過すると判定された場合に、売買取引を未払い取引として登録する。

これにより、実施形態に係る情報管理装置１００は、支払額が口座の残高を超過していても銀行口座やクレジットカードを使わずに注文手続きを完了することができるので、注文を取り止める利用者を減らすことができる。

また、変形例に係る情報管理装置１００において、登録部１３３は、売買取引の買い手によって選択された売買取引を未払い取引として登録する。

これにより、変形例に係る情報管理装置１００は、残高が十分にある場合でも未払い注文として登録することができるので、ユーザが希望する商品の注文を完了した後に決済することができる。

また、変形例に係る情報管理装置１００において、登録部１３３は、売買取引の売り手によって選択された売買取引を未払い取引として登録する。

これにより、変形例に係る情報管理装置１００は、出品者が希望する注文を未払い注文として登録することができるので、注文を完了した後に決済することができる。

また、変形例に係る情報管理装置１００において、判定部１３２は、受付部１３１によって受け付けられた決済要求に対応する売買取引の買い手が所定の条件を満たすか否かを判定する。登録部１３３は、判定部１３２によって買い手が所定の条件を満たすと判定された場合に、売買取引を未払い取引として登録する。

これにより、変形例に係る情報管理装置１００は、買い手に応じて未払い取引を登録することができるので、出品者の利便性を向上させることができる。

また、実施形態に係る情報管理装置１００において、入金部１３５は、残高への入金を受け付ける。また、受付部１３１は、未払い取引の支払いの決済要求を受け付ける。また、決済部１３６は、未払い取引の支払いの決済要求が受け付けられた場合に、入金された残高から未払い取引の支払額を引き落とす。また、通知部１３４は、残高から未払い取引の支払額が引き落とされた場合に、未払い取引の決済が完了した旨を通知する。

これにより、実施形態に係る情報管理装置１００は、支払額と残高との間の不足分をユーザが入金すればよいので、ユーザが無駄に口座に入金することを回避することができる。また、情報管理装置１００は、ユーザが希望するタイミングで未払い注文の決済をすることができるので、決済にかかる手間を軽減することができる。

また、変形例に係る情報管理装置１００において、決済部１３６は、受付部１３１によって決済要求が受け付けられた場合に、入金部１３５によって入金された残高から未払い取引の支払額を引き落とす。

これにより、変形例に係る情報管理装置１００は、未払い注文の支払額以上が入金されると自動で決済を完了することができるので、ユーザの手間を軽減することができる。

また、変形例に係る情報管理装置１００において、通知部１３４は、未払い取引の買い手の信用度が所定の閾値以上である場合に、未払い取引の商品を発送する指示を通知する。

これにより、変形例に係る情報管理装置１００は、信用度に応じて商品を買い手に発送させることができるので、ユーザの利便性を向上させることができる。

また、変形例に係る情報管理装置１００において、登録部１３３は、売買取引を未払い取引として登録してから所定の期間が経過した場合に、売買取引を未払い取引から解除する。また、通知部１３４は、登録部１３３によって解除された売買取引が取り消された旨を通知する。

これにより、変形例に係る情報管理装置１００は、所定の期間が経過した売買取引を自動でキャンセルすることができるので、出品者の利便性を向上させることができる。

また、変形例に係る情報管理装置１００において、登録部１３３は、売買取引を未払い取引として登録してから未払い取引の買い手の信用度に応じた所定の期間が経過した場合に、売買取引を未払い取引から解除する。

これにより、変形例に係る情報管理装置１００は、ユーザの信用度に応じてキャンセルするまでの期間を調整することができるので、出品者の利便性を向上することができる。

また、変形例に係る情報管理装置１００において、登録部１３３は、未払い取引の累計が所定の閾値以下である場合に、売買取引を未払い取引として登録する。

これにより、変形例に係る情報管理装置１００は、未払い注文に制限を付けることができるので、出品者の損失を抑えることができる。

また、変形例に係る情報管理装置１００において、登録部１３３は、未払い取引の累計が未払い取引の買い手の信用度に応じた所定の閾値以下である場合に、売買取引を未払い取引として登録する。

これにより、変形例に係る情報管理装置１００は、注文主の信用度に応じて未払い注文に制限を付けることができるので、出品者の損失を抑えることができる。

また、変形例に係る情報管理装置１００において、通知部１３３は、登録部１３３によって登録された未払い取引がある場合に、未払い取引の買い手の端末装置２０に未払いの売買取引がある旨を通知する。

これにより、変形例に係る情報管理装置１００は、注文主に未払い注文があることを把握させることができるので、出品者の利益を増やすことができる。

また、変形例に係る情報管理装置１００において、通知部１３４は、未払い取引の支払額に対する残高の不足額を端末装置２０に通知する。

これにより、変形例に係る情報管理装置１００は、注文主に不足額を把握させることができるので、ユーザの利便性を向上させることができる。

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

１０ サーバ装置
２０ 端末装置
１００ 情報管理装置
１２１ 決済情報記憶部
１２２ 口座情報記憶部
１３１ 受付部
１３２ 判定部
１３３ 登録部
１３４ 通知部
１３５ 入金部
１３６ 決済部

Claims (15)

1. 売買取引の支払いの決済要求を受け付ける受付部と、
   前記受付部によって受け付けられた決済要求に対応する売買取引の支払い可否を判定する判定部と、
   前記判定部によって前記売買取引の支払いが不可であると判定された場合に、前記売買取引を未払い取引として登録する登録部と、
   前記登録部によって前記未払い取引として登録される売買取引の前記決済要求を未払いの状態で前記売買取引の注文手続きを完了させるための通知を前記売買取引の売り手に通知する通知部と、
   前記売買取引の買い手の口座への入金を受け付ける入金部と、
   前記買い手の口座の残高から売買取引の支払額を引き落とす決済部と、を備え、
   前記受付部は、
   前記登録部によって登録された未払い取引のうち、前記買い手によって選択された未払い取引の支払いの決済要求を受け付け、
   前記決済部は、
   前記受付部によって前記買い手によって選択された未払い取引の支払いの決済要求が受け付けられた場合に、前記入金部によって入金された口座の残高から、当該買い手によって選択された未払い取引の支払額を引き落とし、
   前記通知部は、
   前記決済部によって前記買い手によって選択された未払い取引の支払額が引き落とされた場合に、前記決済要求の決済が完了した旨を通知する、
   ことを特徴とする情報管理装置。
2. 前記登録部は、
   前記売買取引の買い手によって選択された売買取引を未払い取引として登録する
   ことを特徴とする請求項１に記載の情報管理装置。
3. 前記判定部は、
   前記受付部によって受け付けられた決済要求に対応する売買取引の支払額が、前記売買取引の買い手の口座の残高を超過するか否かを判定し、
   前記登録部は、
   前記判定部によって前記支払額が前記残高を超過すると判定された場合に、前記売買取引を未払い取引として登録する
   ことを特徴とする請求項１または２に記載の情報管理装置。
4. 前記登録部は、
   前記売買取引の売り手によって選択された売買取引を未払い取引として登録する
   ことを特徴とする請求項１〜３のいずれか１つに記載の情報管理装置。
5. 前記判定部は、
   前記受付部によって受け付けられた決済要求に対応する売買取引の買い手が所定の条件を満たすか否かを判定し、
   前記登録部は、
   前記判定部によって前記買い手が所定の条件を満たすと判定された場合に、前記売買取引を未払い取引として登録する
   ことを特徴とする請求項１〜４のいずれか１つに記載の情報管理装置。
6. 前記決済部は、
   前記入金部によって前記未払い取引の支払額以上の入金が受け付けられた場合に、前記残高から前記未払い取引の支払額を引き落とす
   ことを特徴とする請求項１〜５のいずれか１つに記載の情報管理装置。
7. 前記通知部は、
   前記未払い取引の買い手の信用度が所定の閾値以上である場合に、当該未払い取引の商品を発送する指示を通知する
   ことを特徴とする請求項１〜６のいずれか１つに記載の情報管理装置。
8. 前記登録部は、
   前記売買取引を未払い取引として登録してから所定の期間が経過した場合に、当該売買取引を前記未払い取引から解除し、
   前記通知部は、
   前記登録部によって解除された売買取引が取り消された旨を通知する
   ことを特徴とする請求項１〜７のいずれか１つに記載の情報管理装置。
9. 前記登録部は、
   前記売買取引を未払い取引として登録してから当該未払い取引の買い手の信用度に応じた所定の期間が経過した場合に、当該売買取引を前記未払い取引から解除する
   ことを特徴とする請求項８に記載の情報管理装置。
10. 前記登録部は、
    前記未払い取引の累計が所定の閾値以下である場合に、前記売買取引を未払い取引として登録する
    ことを特徴とする請求項１〜９のいずれか１つに記載の情報管理装置。
11. 前記登録部は、
    前記未払い取引の累計が当該未払い取引の買い手の信用度に応じた所定の閾値以下である場合に、前記売買取引を未払い取引として登録する
    ことを特徴とする請求項１０に記載の情報管理装置。
12. 前記通知部は、
    前記登録部によって登録された未払い取引がある場合に、当該未払い取引の買い手の端末装置に未払いの売買取引がある旨を通知する
    ことを特徴とする請求項１〜１１のいずれか１つに記載の情報管理装置。
13. 前記通知部は、
    前記未払い取引の支払額に対する前記売買取引の買い手によって予め入金される入金額の残高の不足額を前記端末装置に通知する
    ことを特徴とする請求項１２に記載の情報管理装置。
14. 情報管理装置が実行する決済方法であって、
    売買取引の支払いの決済要求を受け付ける受付工程と、
    前記受付工程によって受け付けられた決済要求に対応する売買取引の支払い可否を判定する判定工程と、
    前記判定工程によって前記売買取引の支払いが不可であると判定された場合に、前記売買取引を未払い取引として登録する登録工程と、
    前記登録工程によって前記未払い取引として登録される売買取引の前記決済要求を未払いの状態で前記売買取引の注文手続きを完了させるための通知を前記売買取引の売り手に通知する通知工程と、
    前記売買取引の買い手の口座への入金を受け付ける入金工程と、
    前記買い手の口座の残高から売買取引の支払額を引き落とす決済工程と、を含み、
    前記受付工程は、
    前記登録工程によって登録された未払い取引のうち、前記買い手によって選択された未払い取引の支払いの決済要求を受け付け、
    前記決済工程は、
    前記受付工程によって前記買い手によって選択された未払い取引の支払いの決済要求が受け付けられた場合に、前記入金工程によって入金された口座の残高から、当該買い手によって選択された未払い取引の支払額を引き落とし、
    前記通知工程は、
    前記決済工程によって前記買い手によって選択された未払い取引の支払額が引き落とされた場合に、前記決済要求の決済が完了した旨を通知する、
    ことを特徴とする決済方法。
15. 売買取引の支払いの決済要求を受け付ける受付手順と、
    前記受付手順によって受け付けられた決済要求に対応する売買取引の支払い可否を判定する判定手順と、
    前記判定手順によって前記売買取引の支払いが不可であると判定された場合に、前記売買取引を未払い取引として登録する登録手順と、
    前記登録手順によって前記未払い取引として登録される売買取引の前記決済要求を未払いの状態で前記売買取引の注文手続きを完了させるための通知を前記売買取引の売り手に通知する通知手順と、
    前記売買取引の買い手の口座への入金を受け付ける入金手順と、
    前記買い手の口座の残高から売買取引の支払額を引き落とす決済手順と、を含み、
    前記受付手順は、
    前記登録手順によって登録された未払い取引のうち、前記買い手によって選択された未払い取引の支払いの決済要求を受け付け、
    前記決済手順は、
    前記受付手順によって前記買い手によって選択された未払い取引の支払いの決済要求が受け付けられた場合に、前記入金手順によって入金された口座の残高から、当該買い手によって選択された未払い取引の支払額を引き落とし、
    前記通知手順は、
    前記決済手順によって前記買い手によって選択された未払い取引の支払額が引き落とされた場合に、前記決済要求の決済が完了した旨を通知する、
    をコンピュータに実行させることを特徴とする決済プログラム。

Images