(57)【要約】【課題】ユーザの利便性を向上させることできる情報処理装置、情報処理方法および情報処理プログラムを提供すること。【解決手段】本願に係る情報処理装置は、受付部と、決済部とを備える。受付部は、現在よりも未来の日時が商品の購入日時として指定される商品の購入要求を受け付ける。決済部は、受付部によって受け付けられた購入要求に基づく購入日時に商品の決済が行われるよう制御する。【選択図】図３
2019125272.tif 000002
【特許請求の範囲】
【請求項１】
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求を受け付ける受付部と、
前記受付部によって受け付けられた前記購入要求に基づく前記購入日時に前記商品の決済が行われるよう制御する決済部と
を備えることを特徴とする情報処理装置。
【請求項２】
前記受付部によって前記購入要求が受け付けられた場合に、前記商品の在庫状況を購入数に応じて管理する管理部
を備えること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記管理部は、
前記購入要求を反映させた前記在庫状況をユーザへ提供すること
を特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記決済部は、
前記購入日時に決済の許可要求をユーザへ通知し、前記ユーザにより当該許可要求が承認された場合に、決済を行うこと
を特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
前記決済部は、
前記購入要求に含まれる前記商品の一覧情報をユーザへ提供すること
を特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
【請求項６】
前記決済部は、
前記商品をユーザへ配送する配送業者から配送完了の通知を受けて決済が行われるよう制御すること
を特徴とする請求項１〜５のいずれか一つに記載の情報処理装置。
【請求項７】
前記決済部は、
前記購入要求を受け付けた価格を上限として決済が行われるよう制御すること
を特徴とする請求項１〜６のいずれか一つに記載の情報処理装置。
【請求項８】
前記決済部は、
前記購入要求を受け付けた価格で前記購入日時に決済が行われるよう制御すること
を特徴とする請求項７に記載の情報処理装置。
【請求項９】
前記受付部は、
期間が指定された前記購入日時を含む前記購入要求を受け付けること
を特徴とする請求項１〜８のいずれか一つに記載の情報処理装置。
【請求項１０】
前記決済部は、
前記購入日時までに付与される仮想通貨を用いて決済が行われるよう制御すること
を特徴とする請求項１〜９のいずれか一つに記載の情報処理装置。
【請求項１１】
購入特典が付与される日時に関する情報をユーザへ提供する提供部
を備えること
を特徴とする請求項１〜１０のいずれか一つに記載の情報処理装置。
【請求項１２】
前記決済部は、
前記購入日時までに前記商品をユーザへ提供できなかった場合に、前記商品の購入をキャンセルすること
を特徴とする請求項１〜１１のいずれか一つに記載の情報処理装置。
【請求項１３】
コンピュータが実行する情報処理方法であって、
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求を受け付ける受付工程と、
前記受付工程によって受け付けられた前記購入要求に基づく前記購入日時に前記商品の決済が行われるよう制御する決済工程と
を含むことを特徴とする情報処理方法。
【請求項１４】
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求を受け付ける受付手順と、
前記受付手順によって受け付けられた前記購入要求に基づく前記購入日時に前記商品の決済が行われるよう制御する決済手順と
をコンピュータに実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
【背景技術】
【０００２】
近年、インターネットなどのネットワークの飛躍的な普及に伴い、かかるネットワークを介した電子的な情報通信によって商品やサービスの売買などを行う電子商取引が盛んに行われている。
【０００３】
かかる電子商取引においては、複数の電子商店（以下、「ストア」と言う）を一同に集め、商品検索や決済処理の統一を図って利便性を向上させた、電子商店街（以下、「モール」と言う）も知られている。
【０００４】
モールは、例えば媒体社等の事業者によって運営されており、ストアで在庫切れであった商品が再度入荷された場合に、モールから購入希望者に対して商品の再入荷を通知するものがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２０１４／１４１３２４号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記した従来技術では、ユーザが再入荷の通知を受けて、購入画面に再度アクセスし、決済処理を行う必要がある。このため、従来技術においては、ユーザの利便性の向上を図るうえで改善の余地があった。
【０００７】
本願は、上記に鑑みてなされたものであって、ユーザの利便性を向上させることができる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本願に係る情報処理装置は、受付部と、決済部とを備える。前記受付部は、現在よりも将来の日時が商品の購入日時として指定される前記商品の購入要求を受け付ける。前記決済部は、前記受付部によって受け付けられた前記購入要求に基づく前記購入日時に前記商品の決済が行われるよう制御する。
【発明の効果】
【０００９】
実施形態の一態様によれば、ユーザの利便性を向上させることができるという効果を奏する。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施形態に係る情報処理の一例を示す図である。
【図２】図２は、実施形態に係るモールシステムの構成を示す図である。
【図３】図３は、実施形態に係るモールサーバの構成を示すブロック図である。
【図４Ａ】図４Ａは、実施形態に係るストア情報記憶部の一例を示す図である。
【図４Ｂ】図４Ｂは、実施形態に係る商品情報記憶部の一例を示す図である。
【図４Ｃ】図４Ｃは、実施形態に係る在庫情報記憶部の一例を示す図である。
【図５】図５は、実施形態に係る商品情報の一例を示す図（その１）である。
【図６】図６は、実施形態に係る商品情報の一例を示す図（その２）である。
【図７】図７は、実施形態に係る購入画面の一例を示す図である。
【図８】図８は、実施形態に係る購入日時の指定画面の一例を示す図である。
【図９】図９は、実施形態に係る決済方法の一例を示す図である。
【図１０】図１０は、実施形態に係る決済処理における価格変動の一例を示す図である。
【図１１】図１１は、実施形態に係る管理部による処理の一例を示す図である。
【図１２】図１２は、実施形態に係る在庫切れにおいて表示される画面の一例を示す図である。
【図１３】図１３は、実施形態に係る商品の入荷要求に基づく処理の一例を示す図である。
【図１４】図１４は、実施形態に係る配送通知に伴う決済処理の一例を示す図である。
【図１５】図１５は、実施形態に係るモールサーバが実行する処理手順を示すフローチャートである。
【図１６】図１６は、実施形態に係るモールサーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【００１１】
以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムの実施形態について図面を参照しつつ詳細に説明する。なお、以下に示す実施形態によりこの発明が限定されるものではない。また、以下の実施形態において同一の部位には同一の符号が付され、重複する記載は省略される。
【００１２】
また、以下では、実施形態に係る情報処理装置が、モールサーバ１００である場合を例に挙げて説明する。モールサーバ１００は、電子商店街であるモールの運営事業者によって運用・管理されるサーバ装置である。
【００１３】
〔１．情報処理の一例〕
まず、実施形態に係る情報処理の一例について、図１を用いて説明する。図１は、実施形態に係る情報処理の一例を示す図である。
【００１４】
図１に示すモールサーバ１００は、モールを運営するためのサーバ装置である。例えば、モールサーバ１００は、モールにおいてユーザＵ０１および出品者Ｓ０１間で売買される商品の商品検索や決済処理を統一化するプラットフォームを提供する。また、モールサーバ１００は、かかるプラットフォームを介してモールが円滑に運用されるように管理する。例えば、モールサーバ１００は、ウェブサーバとしての機能を有しており、上記プラットフォームの一例として、ユーザＵ０１向けのポータルサイトや、出品者Ｓ０１向けの商品管理サイト等を提供する。
【００１５】
図１に示す出品者Ｓ０１は、モールにおける各ストアを運営し、ユーザＵ０１に対して商品を販売する出品者の一例である。出品者Ｓ０１は、ストア端末２０を利用して、販売する商品の登録や、決済、在庫管理といった、電子商取引における売り手としての各種手続きを行う。ストア端末２０は、例えばデスクトップ型ＰＣ（Personal  Computer）や、ノート型ＰＣ等の情報処理端末である。なお、以下の説明では、ストア端末２０を出品者Ｓ０１と読み替える場合がある。
【００１６】
また、図１に示すユーザＵ０１は、モールの各ストアが販売する商品の中から所望の商品を選択し、商品を購入する購入者の一例である。ユーザＵ０１は、ユーザ端末１０を利用して、購入したい商品の検索や、選択、決済、ストアの評価といった電子商取引における買い手としての各種手続きを行う。ユーザ端末１０は、例えばスマートフォンや、ノート型ＰＣ等の情報処理端末である。なお、以下の説明では、ユーザ端末１０をユーザＵ０１と読み替える場合がある。
【００１７】
ユーザＵ０１は、モールサーバ１００の提供するポータルサイトから、例えば購入したい商品のキーワードや、カテゴリ等を指定することによって、ストアを縦断して検索された各商品の一覧ページをユーザ端末１０に表示させることができる。そして、ユーザＵ０１が、一覧ページから詳細情報を確認したい商品を選択すると、その商品の詳細情報ページをユーザ端末１０に表示させることができる。
【００１８】
ところで、モールでは、バーゲン等の開催をユーザＵ０１へ事前に告知する場合がある。かかる告知を受けてユーザＵ０１は、バーゲン期間中に購入する目当ての商品を事前に検索し、バーゲン期間中に実際の購入手続きを行う場合がある。
【００１９】
しかしながら、ユーザＵ０１が、バーゲン期間中に購入手続きを忘れるなど、必ずしもバーゲン期間中に購入手続きを行うとは限らない。かかる場合、ユーザＵ０１の購買意欲を削がれてしまう恐れがあり、モールの運営事業者は、せっかくの商品の販売機会を喪失するおそれがあった。
【００２０】
そこで、実施形態に係るモールサーバ１００は、現在よりも未来の日時を商品の購入日時が指定された購入要求を受け付けて、かかる購入日時に商品の決済が行われるよう制御することとした。
【００２１】
具体的には、モールサーバ１００は、まず、出品者Ｓ０１から商品情報を取得する（ステップＳ１）。商品情報は、例えば、出品者Ｓ０１が出品する商品の商品名や価格、在庫状況等を含む。続いて、モールサーバ１００は、商品情報をユーザＵ０１へ提供する（ステップＳ２）。
【００２２】
ユーザＵ０１は、かかる商品情報を受けてユーザ端末１０を介して商品の購入手続きを行う。ここで、実施形態に係る情報処理において、ユーザＵ０１は、商品の購入日時を現在よりも未来の日時に指定することが可能である。
【００２３】
例えば、ユーザＵ０１が、商品の購入画面へ進むと、ユーザ端末１０には購入日時を指定する画面が表示される。ユーザＵ０１は、ユーザ端末１０を操作し、購入日時を指定することができる。
【００２４】
これにより、モールサーバ１００は、購入する商品と購入日時とを含む購入要求を受け付ける（ステップＳ３）。モールサーバ１００は、購入要求を受け付けると、購入要求を出品者Ｓ０１へ通知する（ステップＳ４）。出品者Ｓ０１へ通知される購入要求は、購入される商品に関する情報、ユーザＵ０１に関する情報や、ユーザＵ０１によって指定された購入日時に関する情報等を含む。
【００２５】
出品者Ｓ０１は、かかる購入要求に基づき、商品をユーザＵ０１へ提供することとなる。そして、モールサーバ１００は、指定された購入日時に決済が行われるように制御する（ステップＳ５）。なお、決済が行われるように制御するとは、モールサーバ１００にネットワーク上で各種決済を行う決済機能を備える場合、モールサーバ１００自体で決済することを示す。
【００２６】
また、モールサーバ１００とは別に決済機能を有するサーバを備える場合、モールサーバ１００は、購入日時に決済が行われるようかかるサーバに対して指示することにしてもよい。すなわち、実際に決済処理を行うのは、モールサーバ１００でなくてもよい。
【００２７】
このように、実施形態に係る情報処理において、ユーザＵ０１が購入日時を指定して商品を購入することが可能となる。これにより、ユーザＵ０１が、商品の購入を所望する期間において、再度ポータルサイトを通じて購入手続きを行うことなく、かかる期間中に商品を購入することが可能となる。
【００２８】
つまり、実施形態に係る情報処理では、ユーザＵ０１が商品の購入を所望した際に、未来の購入日時を指定して購入手続きを行うことができるので、ユーザＵ０１の利便性を向上させることが可能となる。また、ユーザＵ０１が商品を欲した際に購入手続きを行うことで、モールの運営事業者としては、販売機会の損失を低減することができる。
【００２９】
〔２．モールシステム１の構成〕
次に、図２を用いて、実施形態に係るモールシステム１の構成について説明する。図２  は、実施形態に係るモールシステム１の構成例を示す図である。図２に示すように、実施形態に係るモールシステム１には、ユーザ端末１０と、ストア端末２０と、モールサーバ１００とが含まれる。これらの各種装置は、通信ネットワークＮを介して、有線または無線により通信可能に接続される。また、図２に示すモールシステム１に含まれる各装置の数は図示したものに限られない。例えば、モールシステム１には、複数台のユーザ端末１０やストア端末２０が含まれてもよい。
【００３０】
ユーザ端末１０は、スマートフォンを含む携帯電話機や、タブレット端末や、デスクトップ型ＰＣや、ノート型ＰＣや、ＰＤＡ（Personal  Digital  Assistant）等の情報処理装置である。また、ユーザ端末１０には、眼鏡型や時計型の情報処理端末であるウェアラブルデバイス（wearable  device）も含まれる。
【００３１】
ユーザ端末１０は、ユーザＵ０１による操作や、ユーザ端末１０が有する機能（例えば、モールを利用するためのアプリを実行する機能や、ブラウザ機能等）に応じて、各種情報を取得し、取得した情報に応じた情報を生成して送信する。例えば、ユーザ端末１０は、通信ネットワークＮを介して、モールサーバ１００が提供するモールのポータルサイトへアクセスする。そして、ユーザＵ０１が例えば商品のキーワード等を指定することによって、ユーザ端末１０は、ストアを縦断して検索した商品の一覧ページをモールサーバ１００から取得する。
【００３２】
ストア端末２０は、ストアを出店する出品者Ｓ０１によって利用される情報処理端末である。ストア端末２０は、例えば、デスクトップ型ＰＣや、ノート型ＰＣ等である。ストア端末２０は、出品者Ｓ０１による操作や、ストア端末２０が有する機能に応じて、各種情報を取得し、取得した情報に応じた情報を生成して送信する。例えば、ストア端末２０は、モールサーバ１００が提供する入力フォーム等を介して、販売する商品に関しての詳細な商品情報をモールサーバ１００へアップロードしたり、変動する商品の在庫情報をモールサーバ１００へ送信したりする。
【００３３】
モールサーバ１００は、上述したように、ユーザＵ０１向けのポータルサイトや、出品者Ｓ０１向けの商品管理サイト等を提供する。そして、モールサーバ１００は、モールにおけるストアが販売する商品に関する商品情報をユーザＵ０１へ提供する。
【００３４】
なお、実施形態では、モールサーバ１００がウェブサーバとしての機能を有するものとして説明しているが、例えばウェブサーバとしての機能は、モールサーバ１００と関連する管理者によって管理される他の装置から提供されてもよい。
【００３５】
〔３．モールサーバ１００の構成〕
次に、図３を用いて、モールサーバ１００の構成例について説明する。図３は、実施形態に係るモールサーバ１００の構成例を示すブロック図である。なお、図３では、モールサーバ１００の説明に必要となる構成要素のみを示しており、一般的な構成要素についての記載を省略している。
【００３６】
図３に示すように、モールサーバ１００は、通信部１１０と、記憶部１２０と、制御部１３０とを有する。なお、モールサーバ１００は、モールサーバ１００を利用する管理者等から各種操作を受け付ける入力部（例えば、キーボードやマウス等）や、各種情報を表示するための表示部（例えば、液晶ディスプレイ等）を有してもよい。
【００３７】
（通信部１１０について）
通信部１１０は、例えば、ＮＩＣ（Network  Interface  Card）等によって実現される。通信部１１０は、通信ネットワークＮと有線または無線で接続され、通信ネットワークＮを介して、ユーザ端末１０や、ストア端末２０との間で情報の送受信を行う。
【００３８】
（記憶部１２０について）
記憶部１２０は、例えば、ＲＡＭ（Random  Access  Memory）、フラッシュメモリ（Flash  Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、図３の例では、ストア情報記憶部１２１と、商品情報記憶部１２２と、在庫情報記憶部１２３とを記憶する。
【００３９】
（ストア情報記憶部１２１について）
ストア情報記憶部１２１は、各ストアに関する情報を記憶する。ここで、図４Ａに、実施形態に係るストア情報記憶部１２１の一例を示す。図４Ａは、実施形態に係るストア情報記憶部１２１の一例を示す図である。
【００４０】
図４Ａに示した例では、ストア情報記憶部１２１は、「ストアＩＤ」、「ストア名称」、「出店者ＩＤ」、「ストア評価」といった項目を有する。
【００４１】
「ストアＩＤ」は、ストアを識別するための識別情報を示す。なお、実施形態において、ストアＩＤのような識別情報を、説明で用いる参照符号として用いる場合がある。例えば、ストアＩＤが「Ｓ００１」であるストアを「ストアＳ００１」と表記する場合がある。
【００４２】
「ストア名称」は、モールにおけるストアの名称を示す。「出店者ＩＤ」は、ストアの出店者を識別するための識別情報を示す。「ストア評価」は、モールにおけるストアの評価値を示す。かかる評価値は、例えば過去の取引についてユーザＵ０１からフィードバックされる採点結果等に基づいて算出される。なお、図４Ａに示した例では、「☆」印で評価値を表しており、「☆」の数が多いほど評価が高いことを意味している。
【００４３】
（商品情報記憶部１２２について）
図３の説明に戻り、つづいて商品情報記憶部１２２について説明する。商品情報記憶部１２２は、モールにおいて販売される商品に関する情報を記憶する。ここで、図４Ｂに、実施形態に係る商品情報記憶部１２２の一例を示す。図４Ｂは、実施形態に係る商品情報記憶部１２２の一例を示す図である。
【００４４】
図４Ｂに示した例では、商品情報記憶部１２２は、「商品ＩＤ」、「商品名称」、「サイズ」、「色」といった項目を有する。
【００４５】
「商品ＩＤ」は、商品を識別するための識別情報を示す。例えば、「商品ＩＤ」は、国家や公共性の高い団体等により付与される事業者コードや、「どの事業者が作成したどの商品か」を識別することができる商品コード（例えば、日本ではＪＡＮコード（Japanese  Article  Number）が知られている）である。
【００４６】
「商品名称」は、商品の名称を示す。「サイズ」および「色」は、それぞれ商品のサイズおよび商品の色を示す。
【００４７】
（在庫情報記憶部１２３について）
図３の説明に戻り、つづいて在庫情報記憶部１２３について説明する。在庫情報記憶部１２３は、各商品の各ストアにおける在庫に関する情報を記憶する。ここで、図４Ｃに、実施形態に係る在庫情報記憶部１２３の一例を示す。図４Ｃは、実施形態に係る在庫情報記憶部１２３の一例を示す図である。
【００４８】
図４Ｃに示した例では、在庫情報記憶部１２３は、「商品ＩＤ」、「ストアＩＤ」、「在庫数」といった項目を有する。
【００４９】
「商品ＩＤ」は、上述した商品情報記憶部１２２の「商品ＩＤ」に対応し、「ストアＩＤ」は、上述したストア情報記憶部１２１の「ストアＩＤ」に対応する。「在庫数」は、「商品ＩＤ」でサイズおよび色まで一意に定まる各商品の、各ストアにおける在庫数を示す。
【００５０】
（制御部１３０について）
図３の説明に戻り、つづいて制御部１３０について説明する。制御部１３０は、コントローラ（controller）であり、例えば、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）等によって、モールサーバ１００内部の記憶装置に記憶されている各種プログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３０は、例えば、コントローラであり、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）等の集積回路により実現される。
【００５１】
図３に示すように、制御部１３０は、取得部１３１と、受付部１３２と、管理部１３３と、決済部１３４と、提供部１３５とを有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３０の内部構成は、図３に示した構成に限られず、後述する情報処理を行うことができる構成であれば他の構成であってもよい。また、制御部１３０が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。
【００５２】
（取得部１３１について）  
取得部１３１は、通信ネットワークＮおよび通信部１１０を介して、ストア端末２０から、各ストアの商品情報を取得する。なお、上述したように、商品情報は、各ストアが提供可能な商品の商品ＩＤ、価格、在庫状況等を含む。また、取得部１３１は、取得した商品情報のうち、在庫状況を在庫情報記憶部１２３へ格納する。
【００５３】
（受付部１３２について）
受付部１３２は、通信ネットワークＮおよび通信部１１０を介して、ユーザ端末１０から商品の購入要求を受け付ける。上述のように、実施形態において、購入要求は、現在よりも未来の日時が商品の購入日時として指定された日時指定を含む。
【００５４】
（管理部１３３について）
管理部１３３は、受付部１３２によって購入要求が受け付けられた場合に、商品の在庫状況を購入数に応じて管理する。例えば、管理部１３３は、在庫情報記憶部１２３に格納された在庫情報を更新することで、商品の在庫状況を管理する。なお、管理部１３３による処理の一例については後述する。
【００５５】
（決済部１３４について）
決済部１３４は、受付部１３２によって受け付けられた購入要求に基づく購入日時に商品の決済が行われるよう制御する。なお、決済部１３４による処理の一例については後述する。
【００５６】
（提供部１３５について）
提供部１３５は、購入日時として購入特典が付与される日時に関する情報をユーザＵ０１へ提供する。購入特典とは、例えば、商品の購入を通じてユーザＵ０１へ還元されるポイント（仮想通貨の一例）の付与率の増大や、商品の値引き率の増大を示す。
【００５７】
すなわち、ユーザＵ０１は、購入特典が付与される日時に商品を購入することで、お得に買物を行うことができる。なお、提供部１３５は、かかる日時に関する情報を、例えば、モールの運営管理者や、出品者Ｓ０１から取得する。
【００５８】
（購入手続きの具体例について）
次に、ユーザＵ０１が商品を購入するまでの購入手続きの一連の処理について図５〜１４を用いて説明する。図５および図６は、実施形態に係る商品情報の一例を示す図である。
【００５９】
図５に示すように、まず、ユーザＵ０１は、モールにおいて商品の購入を検討する場合に、例えばユーザ端末１０に表示された商品の一覧ページから所望の商品を選択する。ここで、図５に示すように、ユーザＵ０１が、ユーザ端末１０の表示領域Ａ１に表示された商品の一覧ページから、インナーシャツを選択したものとする。なお、図６以降では、ユーザ端末１０の図示を簡略化し、表示領域Ａ１を主に示すこととする。
【００６０】
そして、図６に示すように、提供部１３５は、商品情報とともに、商品の在庫に関する情報をユーザＵ０１へ提供する。例えば、ユーザＵ０１は、商品の購入数を入力後、購入画面へのボタンＢ１を操作することで、図７に示す購入画面へ遷移する。図７は、実施形態に係る購入画面の一例を示す図である。
【００６１】
図７に示すように、購入画面において、希望購入日を選択する選択ボタンＢ２、決済方法を選択する選択ボタンＢ３およびお届け住所を選択する選択ボタンＢ４等が表示される。また、ユーザＵ０１は、希望購入日、決済方法およびお届け住所等をそれぞれ選択したのちに、確認画面へのボタンＢ５を操作することで、購入手続きの確認画面が表示される。
【００６２】
例えば、ユーザＵ０１が、希望購入日を選択する選択ボタンＢ２を操作すると、購入日の指定を促す購入日の指定画面が表示領域Ａ１に表示される。図８は、実施形態に係る購入日時の指定画面の一例である。
【００６３】
例えば、図８に示すように、かかる指定画面において、表示領域Ａ１には、カレンダーが表示され、ユーザＵ０１は、かかるカレンダーから希望する購入日を指定することができる。
【００６４】
ここで、図８において、カレンダーには、例えば、現在（ここでは、８日）より未来の日時が表示され、ユーザＵ０１は、現在より未来の日時を購入日として指定することができる。
【００６５】
また、例えば、ユーザＵ０１が、イベントを表示に対応するボタンＢ６を操作すると、図８右図に示すように、カレンダーにイベントが重畳して表示される。例えば、イベントは、上述の購入特典が付与される日時に対応する。
【００６６】
図８に示す例では、「☆」で示すイベント「ポイント５倍」は、ポイントの還元率が通常時の５倍であることを示す。また、イベントとして「○」で示すように、ポイント付与される日時が表示されることとしてもよい。なお、図８に示すイベントは、一例であり、これに限定されるものではない。例えば、イベントとしてセールやバーゲン、タイムセール等を含むことにしてもよい。また、購入される商品に応じたイベントのみを表示することにしてもよい。例えば、購入される商品がスポーツ用品である場合、スポーツ用品に関するイベントのみを表示することにしてもよい。
【００６７】
さらに、ユーザＵ０１が、イベントを指定して希望購入日時を選択可能とすることにしてもよい。例えば、希望購入日にイベントを指定するボタンを表示し、かかるボタンが操作された場合に、イベントの開催日時に決済が行われるに制御される。これにより、ユーザによる操作を簡略化することができ、結果として商品の購入を促すことが可能となる。
【００６８】
なお、かかる場合に、イベントの開催日時となる希望購入日時に決済を行った後に、ユーザＵ０１へ商品が発送されるようにしてもよいし、あるいは、希望購入日時以降の日時に商品の発送日時をユーザに選択させるようにしてもよい。
【００６９】
そして、例えば、ユーザＵ０１は、イベントを非表示に対応するボタンＢ７を操作することで、図８左図に示す画面が表示される。このように、実施形態では、ユーザＵ０１に対してイベントの日時に関する情報を提供する。これにより、ユーザＵ０１が買物をお得に行うことができるので、ユーザＵ０１の購買意欲を掻き立てることができる。
【００７０】
その結果、ユーザＵ０１による商品の購入を促進することができるので、モールの運営事業者は、商品の販売機会の損失を低減することが可能となる。また、ユーザＵ０１は、モールサーバ１００へアクセスしたタイミングで、イベントの日時における購入手続きを行えるので、イベント当日のモールサーバ１００に対するアクセス数を分散することも可能となる。なお、希望購入日の指定を受け付けるのは、ユーザＵ０１によるキーボード入力であってもよい。
【００７１】
また、モールサーバ１００は、購入日時に期間を設けて購入要求を受け付けることも可能である。かかる場合に、モールサーバ１００は、ユーザＵ０１からいつからいつまでに購入可能であれば、購入する旨の購入要求を受け付ける。
【００７２】
つまり、モールサーバ１００は、購入日時に期間を設けることで、ストア側では、指定された期間内にユーザＵ０１へ商品を提供すればよいので、ストア側の負担を軽減することができる。
【００７３】
続いて、図９を用いて決済方法の具体例について説明する。図９は、実施形態に係る決済方法の一例を示す図である。図９では、ユーザＵ０１が図７に示すボタンＢ３を選択した場面に対応する。図９に示すように、決済方法として、例えば、クレジットカード決済、代引き決済、コンビニ決済等が選択可能である。
【００７４】
また、ユーザＵ０１は、各決済方法に対して、ポイントの使用の有無を選択することが可能である。ここで、図９に示すように、ユーザＵ０１は、現在保持しているポイントと、現在から購入日までに付与される予定のポイントとを合算したポイントを商品の購入に使用することができる。
【００７５】
つまり、実施形態では、ユーザＵ０１が現在保持しているポイントに加えて、未来の購入日までに付与される予定のポイントを使用することも可能である。これにより、ユーザＵ０１が実質的に負担する金額を抑えることが可能となる。したがって、ユーザＵ０１による商品の購入を促進することができる。
【００７６】
また、現在と未来の購入日で商品の価格が変動する場合がある。かかる場合に、決済部１３４は、現在の価格を上限として決済が行われるよう制御する。図１０は、実施形態に係る決済処理における価格変動の一例を示す図である。図１０に示すように、現在の価格が価格ｐ１であり、購入日の価格が価格ｐ１から上昇し、価格ｐ２であったとする。
【００７７】
かかる場合に、決済部１３４は、現在の価格ｐ１で購入日に決済を行うよう制御する。また、購入日の価格が現在の価格ｐ１よりも下落し、価格ｐ３であった場合、決済部１３４は、購入日に価格ｐ３で決済を行うよう制御する。
【００７８】
つまり、現在の価格ｐ１を上限とすることで、ユーザＵ０１へ現在において提示した価格ｐ１を超えないので、価格の上昇に伴うユーザＵ０１からの苦情を回避することができる。また、ユーザＵ０１は、現在提示した価格に基づいて購入するか否かを決定するので、安心して買物を楽しむことができる。
【００７９】
なお、決済部１３４は、購入日の価格によらず、現在、すなわち購入要求を受け付けた時の価格ｐ１で決済処理を行うようにしてもよいし、あるいは、価格ｐ１によらず、購入日の価格（価格ｐ２または価格ｐ３）で決済を行うようにしてもよい。また、例えば、現在から購入日までの間で最も価格が安くなった価格ｐ４で決済を行うようにしてもよい。
【００８０】
ところで、上述のように、受付部１３２は、上記の購入要求を受け付けると、管理部１３３は、在庫状況を購入数に応じて更新する。図１１は、実施形態に係る管理部１３３による処理の一例を示す図である。
【００８１】
図１１に示すように、例えば、商品ＩＤ「Ｊ００１」の商品がストアＩＤ「Ｓ００１」で１つ購入された場合、管理部１３３は、在庫数を「５」から１つ減算し、在庫数を「４」とする。
【００８２】
つまり、管理部１３３は、商品の在庫を購入数に応じて予め確保することで、ユーザＵ０１に対して確実に商品を提供することが可能となる。また、出品者Ｓ０１は、商品の購入が確約されるので、売れ行きに応じて在庫数を増やすなどの在庫管理が容易となる。
【００８３】
また、管理部１３３は、更新後、すなわち、購入要求を反映させた在庫状況をユーザＵ０１へ提供する。つまり、管理部１３３は、実際には商品の在庫としてあるものの、購入要求により購入が確約されたものについては在庫数を減らしてユーザＵ０１へ提供する。これにより、ユーザＵ０１へ実質的な在庫状況を把握させることができる。
【００８４】
一方、例えば、ユーザＵ０１が、特定のストアから購入しようとした際に、在庫切れであった場合、再入荷ボタンＢ８が表示される。図１２は、実施形態に係る在庫切れにおいて表示される画面の一例を示す図である。
【００８５】
図１２に示すように、特定のストアで在庫切れである場合、表示領域Ａ１には、「在庫なし」の文言とともに、再入荷ボタンＢ８が表示される。
【００８６】
ユーザＵ０１が、再入荷ボタンＢ８を操作すると、他のストアの在庫状況に基づき、異なる画面が表示領域Ａ１に表示される。例えば、他のストアに同一商品の在庫がある場合、表示領域Ａ１には、他のストアでの商品の購入を促す画面が表示される。つまり、モールサーバ１００は、在庫がある他のストアでの商品の購入をユーザＵ０１に対して促すことができる。
【００８７】
一方、モールサーバ１００は、いずれのストアにおいても在庫切れであり、再入荷ボタンＢ８がユーザＵ０１によって操作された場合には、各ストアに対して商品の入荷を要求する。図１３は、実施形態に係る商品の入荷要求に基づく処理の一例を示す図である。
【００８８】
図１３に示すように、例えば、モールサーバ１００は、ユーザ端末１０から再入荷通知を取得すると（ステップＳ１１）、商品の在庫状況を確認する（ステップＳ１２）。
【００８９】
ここで、モールサーバ１００は、在庫状況を確認し、いずれのストアでも在庫切れであった場合、各ストアに対して商品の入荷要求を一斉に通知する（ステップＳ１３）。これにより、各ストアでは、商品を入荷する処理が行われる。
【００９０】
そして、モールサーバ１００は、商品が再入荷されたことを示す再入荷通知を各ストアから取得する（ステップＳ１４）。このとき、例えば、モールサーバ１００は、最も早く商品を再入荷したストアに対して商品の購入手続きを行うようにし、残りのストアに対して購入をキャンセルする（ステップＳ１５）。
【００９１】
図１３に示す例では、モールサーバ１００が、出品者Ｓ０１よりも早く出品者Ｓ０２から再入荷通知を受け付けた場合を示す。このため、モールサーバ１００は、出品者Ｓ０２に対して購入手続きを行うようにし、出品者Ｓ０１に対して購入をキャンセルする。
【００９２】
つまり、モールサーバ１００では、レスポンスが早いストアから商品が購入されるように、購入先のストアを選択する。これにより、各ストアがサービスの向上を競うこととなり、結果としてモールの運営事業者は、より良いサービスをユーザＵ０１へ提供することが可能となる。
【００９３】
なお、上記の例に限られず、モールサーバ１００は、ユーザＵ０１によって指定された購入日までに商品の再入荷を可能なストアを購入先として選択することにしてもよい。かかる場合に、例えば、モールサーバ１００は、最も価格が安いストアを購入先として選択することにしてもよいし、あるいは、図４Ａに示したストア評価が高いストアを購入先として選択することにしてもよい。これにより、各ストアによるサービスの向上を促すことができる。
【００９４】
また、全てのストアにおいて商品が在庫切れである場合、上記の再入荷ボタンＢ８が操作された場合、在庫が有る商品の中から、かかる商品に関連する商品や代替品の一覧をユーザへ提供することとしてもよい。
【００９５】
これにより、ユーザＵ０１に関連する商品や代替品の購入を促すことができる。ここで、関連する商品とは、例えば、在庫切れの商品が白色のインナーシャツである場合、他の色のインナーシャツや、同一ブランドのインナーシャツ、もしくは、同じ商品を閲覧した他のユーザが実際に購入したインナーシャツ等を含む。また、代替品とは、例えば、商品と同一の役割を担う商品であり、同一カテゴリに属す商品を含む。
【００９６】
ところで、決済部１３４は、商品がユーザＵ０１に届いてから決済処理を行うことも可能である。図１４は、実施形態に係る配送通知に伴う決済処理の一例を示す図である。図１４に示すように、例えば、出品者Ｓ０１が配送業者Ｄ０１に対して商品の配送を依頼し（ステップＳ２１）、配送業者Ｄ０１がユーザＵ０１に対して配送し、配送完了させる（ステップＳ２２）。
【００９７】
そして、モールサーバ１００は、配送者端末３０からの配送完了の通知を受けて（ステップＳ２３）、決済処理を行う（ステップＳ２４）。つまり、実施形態では、配送者端末３０からの配送完了の通知を受けて商品の決済処理を行うので、ユーザＵ０１に商品が確実に届いたことをもって決済処理を行うことが可能である。
【００９８】
ここで、実施形態において、ユーザＵ０１が希望する購入日は、例えば、ユーザＵ０１の手元へ商品が届く日時である。このため、ユーザＵ０１は、商品が届く日時を希望する購入日として入力するだけでよく、購入日と希望する届け日とを別々に入力しなくてよいので、ユーザＵ０１が購入手続きに際して入力に要する時間を削減することも可能である。また、購入日を商品がユーザＵ０１の手元に届く日時とすることで、ユーザＵ０１に対して直感的に購入日を認識させることができる。
【００９９】
このとき、モールサーバ１００は、ユーザＵ０１が希望した購入日までに商品をユーザＵ０１へ届けることができない場合、商品の購入を自動的にキャンセルすることにしてもよい。これにより、ユーザＵ０１が、一度は購入を希望したものの、モール側の都合で商品を届けることができなかった場合に、ユーザＵ０１がキャンセル手続きを行わなくてよいので、ユーザＵ０１による操作を簡略化することができる。
【０１００】
なお、モールサーバ１００では、例えば、購入画面（図７参照）において、自動的にキャンセルするか否かをユーザＵ０１に選択させることにしてもよい。これにより、モールサーバ１００では、ユーザＵ０１の意思に基づいて商品の購入をキャンセルすることができるので、キャンセルに伴うトラブルを未然に解消することができる。
【０１０１】
また、モールサーバ１００は、決済処理を行う前であれば、ユーザＵ０１から商品の購入のキャンセルを受け付けることも可能である。かかる場合に、モールサーバ１００は、ユーザＵ０１に対して購入要求に含まれる購入希望日時、購入金額、購入数とを含む一覧情報と、商品毎にキャンセルボタンを表示する。
【０１０２】
モールサーバ１００は、ユーザＵ０１によってかかるキャンセルボタンが操作された場合に、商品の購入についてキャンセルを行う。このように、モールサーバ１００は、ユーザＵ０１から商品の購入のキャンセルを受け付けることで、ユーザＵ０１の利便性を向上させることができ、ユーザＵ０１に気軽にモールを活用してもらうことが可能となる。なお、モールサーバ１００は、ユーザＵ０１から購入日時の変更を受け付けることにしてもよい。
【０１０３】
また、モールサーバ１００は、一覧情報を提供することで、ユーザＵ０１が購入要求を行った商品に関する情報を容易に把握することができるので、ユーザＵ０１の利便性を向上することができる。
【０１０４】
なお、決済処理を行う前とは、ストアから配送業者Ｄ０１へ商品の配送を依頼する前とすることにしてもよい。これにより、配送業者Ｄ０１による負担を軽減することが可能となる。また、ストアから配送業者Ｄ０１へ商品の配送を依頼した後に、キャンセル手数料が発生するようにしてもよい。
【０１０５】
また、モールサーバ１００は、配送者端末３０から配送完了が通知される前であっても、決済処理を行うことにしてもよい。例えば、モールサーバ１００は、決済処理を行った後に、ストアへ商品の購入を発注することにしてもよい。すなわち、決済処理を行う日時と、商品がユーザＵ０１へ届く日時とを別々の日時とすることにしてもよい。また、モールサーバ１００は、決済処理を行う日時と商品をユーザに届ける日時とをユーザＵ０１から別々に受け付けることにしてもよい。
【０１０６】
また、モールサーバ１００は、購入日時においてユーザＵ０１に対して決済の許可要求を通知し、かかる許可要求がユーザＵ０１から承認された場合に、購入日時に決済を行うようにしてもよい。一方、ユーザＵ０１は、許可要求を承認しない場合は、商品の購入をキャンセルすることも可能である。
【０１０７】
このように、モールサーバ１００は、ユーザＵ０１に対して購入するか否かの意思確認を改めて行ったうえで決済処理を行うことで、決済後に商品が返却される等のトラブルを未然に回避することができる。
【０１０８】
〔４．モールサーバ１００の処理手順〕
次に、図１５を用いて実施形態に係るモールサーバ１００による処理手順について説明する。図１５は、実施形態に係るモールサーバ１００が実行する処理手順を示すフローチャートである。
【０１０９】
図１５に示すように、まず、モールサーバ１００は、ユーザＵ０１のユーザ端末１０に対して商品情報を提供する（ステップＳ１０１）。続いて、モールサーバ１００は、ユーザＵ０１からの購入要求を受け付けたか否かを判定する（ステップＳ１０２）。
【０１１０】
モールサーバ１００は、購入要求を受け付けた場合（ステップＳ１０２，Ｙｅｓ）、ストアへ購入要求を通知し（ステップＳ１０３）、在庫状況を管理する（ステップＳ１０４）。続いて、モールサーバ１００は、配送者端末３０から配送通知を受け付けたか否かを判定する（ステップＳ１０５）。
【０１１１】
ここで、モールサーバ１００は、配送通知を受け付けた場合（ステップＳ１０５，Ｙｅｓ）、決済処理を行い（ステップＳ１０６）、処理を終了する。一方、ステップＳ１０２の処理において、購入要求を受け付けていない場合（ステップＳ１０２，Ｎｏ）、モールサーバ１００は、後続の処理を行わず、処理を終了する。
【０１１２】
また、ステップＳ１０５の判定において、配送通知を受け付けていない場合（ステップＳ１０５，Ｎｏ）、モールサーバ１００は、ユーザＵ０１によって指定された購入日時を超過したか否かを判定する（ステップＳ１０７）。
【０１１３】
かかる購入日時を超過していない場合（ステップＳ１０７，Ｎｏ）、モールサーバ１００は、ステップＳ１０５の処理を継続して行う。一方、購入日時を超過した場合（ステップＳ１０７，Ｙｅｓ）、モールサーバ１００は、商品の購入をキャンセルし（ステップＳ１０８）、処理を終了する。
【０１１４】
〔５．ハードウェア構成〕
上述してきた実施形態に係るモールサーバ１００やユーザ端末１０やストア端末２０は、例えば図１６に示すような構成のコンピュータ１０００によって実現される。以下、モールサーバ１００を例に挙げて説明する。図１６は、実施形態に係るモールサーバ１００の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。
【０１１５】
ＣＰＵ１１００は、ＲＯＭ１３００又はＨＤＤ１４００に記憶されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を記憶する。
【０１１６】
ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を記憶する。通信インターフェイス１５００は、ネットワークＮを介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータを、ネットワークＮを介して他の機器へ送信する。
【０１１７】
ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、入出力インターフェイス１６００を介して生成したデータを出力装置へ出力する。
【０１１８】
メディアインターフェイス１７００は、記録媒体１８００に記憶されたプログラム又はデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital  Versatile  Disc）、ＰＤ（Phase  change  rewritable  Disk）等の光学記録媒体、ＭＯ（Magneto-Optical  disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【０１１９】
例えば、コンピュータ１０００が実施形態に係るモールサーバ１００として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部１３０の機能を実現する。また、ＨＤＤ１４００には、記憶部１２０内のデータが記憶される。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置からネットワークＮを介してこれらのプログラムを取得してもよい。
【０１２０】
〔６．その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【０１２１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、図３に示した取得部１３１と、受付部１３２とは統合されてもよい。また、例えば、記憶部１２０に記憶される情報は、ネットワークＮを介して、外部に備えられた所定の記憶装置に記憶されてもよい。
【０１２２】
また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【０１２３】
〔７．効果〕
上述したように、実施形態に係るモールサーバ１００（情報処理装置の一例）は、受付部１３２と、決済部１３４とを備える。受付部１３２は、現在よりも将来の日時が商品の購入日時として指定される商品の購入要求を受け付ける。決済部１３４は、受付部１３２によって受け付けられた購入要求に基づく購入日時に商品の決済が行われるよう制御する。したがって、ユーザの利便性を向上させることができる。
【０１２４】
また、実施形態に係るモールサーバ１００は、受付部１３２によって購入要求が受け付けられた場合に、商品の在庫状況を購入数に応じて管理する管理部１３３を備える。したがって、購入要求により指定される購入日時における商品の在庫を確保することができる。
【０１２５】
また、管理部１３３は、購入要求を反映した在庫状況をユーザＵ０１へ提供する。したがって、ユーザＵ０１に対して実質的な在庫状況を提示することが可能となる。
【０１２６】
また、決済部１３４は、購入日時に決済の許可要求をユーザＵ０１へ通知し、ユーザＵ０１により当該許可要求が承認された場合に、決済を行う。したがって、決済後に商品が返却される等のトラブルを未然に回避することができる。
【０１２７】
また、決済部１３４は、購入要求に含まれる商品の一覧情報をユーザＵ０１へ提供する。したがって、ユーザＵ０１に対して購入要求を行った商品を容易に把握させることができる。
【０１２８】
また、決済部１３４は、商品をユーザＵ０１へ配送する配送業者Ｄ０１から配送完了の通知を受けて決済が行われるよう制御する。したがって、ユーザＵ０１へ商品が届かずに、決済が行われることによるとトラブルを未然に抑制することができる。
【０１２９】
また、決済部１３４は、購入要求を受け付けた時の価格を上限として決済が行われるよう制御する。したがって、購入日時における価格の上昇に伴うユーザＵ０１からの苦情を回避することができる。つまり、ユーザＵ０１が、将来の価格を気にすることなく買物を楽しむことが可能となる。
【０１３０】
また、決済部１３４は、購入要求を受け付けた時の価格で購入日時に決済が行われるよう制御する。したがって、ユーザＵ０１へ予め提示した価格で購入処理が行われるので、安心して買い物を楽しんでもらうことができる。
【０１３１】
また、受付部１３２は、期間が指定された購入日時を含む購入要求を受け付ける。これにより、ストア側では、指定された期間内にユーザＵ０１へ商品を提供すればよいので、ストア側の負担を軽減することができる。
【０１３２】
また、決済部１３４は、購入日時までに付与される予定のポイント（仮想通貨の一例）を用いて決済が行われるように制御する。これにより、ユーザＵ０１が現在保有しているポイントよりも多くのポイントを使用することができるので、ユーザＵ０１の実質的な負担を軽減することができる。
【０１３３】
また、モールサーバ１００は、購入特典が付与される日時に関する情報をユーザＵ０１へ提供する提供部１３５を備える。これにより、ユーザＵ０１が買物をお得に行うことができるので、ユーザＵ０１の購買意欲を掻き立てることができる。
【０１３４】
決済部１３４は、購入日時までに商品をユーザへ提供できなかった場合、購入をキャンセルする。これにより、ユーザＵ０１自身で、キャンセル手続きを行わなくて良いので、ユーザＵ０１の処理を簡略化することができる。
【０１３５】
以上、本願の実施形態を図面に基づいて詳細に説明したが、これは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【０１３６】
また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。
【符号の説明】
【０１３７】
１    モールシステム
１０    ユーザ端末
２０    ストア端末
３０    配送者端末
１００    モールサーバ（情報処理装置の一例）
１１０    通信部
１２０    記憶部
１２１    ストア情報記憶部
１２２    商品情報記憶部
１２３    在庫情報記憶部
１３０    制御部
１３１    取得部
１３２    受付部
１３３    管理部
１３４    決済部
１３５    提供部
Ｓ０１    出品者
Ｕ０１    ユーザ
【図１】
2019125272.tif 000003
【図２】
2019125272.tif 000004
【図３】
2019125272.tif 000005
【図４Ａ】
2019125272.tif 000006
【図４Ｂ】
2019125272.tif 000007
【図４Ｃ】
2019125272.tif 000008
【図５】
2019125272.tif 000009
【図６】
2019125272.tif 000010
【図７】
2019125272.tif 000011
【図８】
2019125272.tif 000012
【図９】
2019125272.tif 000013
【図１０】
2019125272.tif 000014
【図１１】
2019125272.tif 000015
【図１２】
2019125272.tif 000016
【図１３】
2019125272.tif 000017
【図１４】
2019125272.tif 000018
【図１５】
2019125272.tif 000019
【図１６】
2019125272.tif 000020
【手続補正書】
【提出日】平成30年8月24日(2018.8.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求に関する情報をユーザ端末から受け付けて記憶部に記憶する受付部と、
前記記憶部に記憶された前記情報に基づく前記購入日時に、前記ユーザ端末のユーザに対する前記商品の決済が行われるよう制御する決済部と
を備え、
前記決済部は、
前記購入日時に決済の許可要求を前記ユーザ端末へ通知し、前記ユーザ端末により当該許可要求が承認された場合に、決済を行うこと
を特徴とする情報処理装置。
【請求項２】
前記受付部によって前記購入要求が受け付けられた場合に、前記商品の在庫状況を購入数に応じて管理する管理部
を備えること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記管理部は、
前記購入要求を反映させた前記在庫状況をユーザへ提供すること
を特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記決済部は、
前記購入要求に含まれる前記商品の一覧情報をユーザへ提供すること
を特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
前記決済部は、
前記商品をユーザへ配送する配送業者から配送完了の通知を受けて決済が行われるよう制御すること
を特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
【請求項６】
前記決済部は、
前記購入要求を受け付けた価格を上限として決済が行われるよう制御すること
を特徴とする請求項１〜５のいずれか一つに記載の情報処理装置。
【請求項７】
前記決済部は、
前記購入要求を受け付けた価格で前記購入日時に決済が行われるよう制御すること
を特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記受付部は、
期間が指定された前記購入日時を含む前記購入要求を受け付けること
を特徴とする請求項１〜７のいずれか一つに記載の情報処理装置。
【請求項９】
前記決済部は、
前記購入日時までに付与される仮想通貨を用いて決済が行われるよう制御すること
を特徴とする請求項１〜８のいずれか一つに記載の情報処理装置。
【請求項１０】
購入特典が付与される日時に関する情報をユーザへ提供する提供部
を備えること
を特徴とする請求項１〜９のいずれか一つに記載の情報処理装置。
【請求項１１】
前記決済部は、
前記購入日時までに前記商品をユーザへ提供できなかった場合に、前記商品の購入をキャンセルすること
を特徴とする請求項１〜１０のいずれか一つに記載の情報処理装置。
【請求項１２】
コンピュータが実行する情報処理方法であって、
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求に関する情報をユーザ端末から受け付けて記憶部に記憶する受付工程と、
前記記憶部に記憶された前記情報に基づく前記購入日時に、前記ユーザ端末のユーザに対する前記商品の決済が行われるよう制御する決済工程と
を含み、
前記決済工程は、
前記購入日時に決済の許可要求を前記ユーザ端末へ通知し、前記ユーザ端末により当該許可要求が承認された場合に、決済を行うこと
を特徴とする情報処理方法。
【請求項１３】
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求に関する情報をユーザ端末から受け付けて記憶部に記憶する受付手順と、
前記記憶部に記憶された前記情報に基づく前記購入日時に、前記ユーザ端末のユーザに対する前記商品の決済が行われるよう制御する決済手順と
をコンピュータに実行させ、
前記決済手順は、
前記購入日時に決済の許可要求を前記ユーザ端末へ通知し、前記ユーザ端末により当該許可要求が承認された場合に、決済を行うこと
を特徴とする情報処理プログラム。
【手続補正書】
【提出日】平成31年2月15日(2019.2.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求に関する情報をユーザ端末から受け付けて記憶部に記憶する受付部と、
前記記憶部に記憶された前記情報に基づく前記購入日時に、前記ユーザ端末のユーザに対する前記商品の決済が行われるよう制御する決済部と
を備え、
前記決済部は、
前記購入日時に決済の許可要求を前記ユーザ端末へ通知し、前記ユーザ端末により当該許可要求が承認された場合に、当該商品の購入を確定させて、決済を行うこと
を特徴とする情報処理装置。
【請求項２】
前記受付部によって前記購入要求が受け付けられた場合に、前記商品の在庫状況を購入数に応じて管理する管理部
を備えること
を特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記管理部は、
前記購入要求を反映させた前記在庫状況をユーザへ提供すること
を特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記決済部は、
前記購入要求に含まれる前記商品の一覧情報をユーザへ提供すること
を特徴とする請求項１、２または３に記載の情報処理装置。
【請求項５】
前記決済部は、
前記購入要求を受け付けた価格を上限として決済が行われるよう制御すること
を特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
【請求項６】
前記決済部は、
前記購入要求を受け付けた価格で前記購入日時に決済が行われるよう制御すること
を特徴とする請求項５に記載の情報処理装置。
【請求項７】
前記受付部は、
期間が指定された前記購入日時を含む前記購入要求を受け付けること
を特徴とする請求項１〜６のいずれか一つに記載の情報処理装置。
【請求項８】
前記決済部は、
前記購入日時までに付与される仮想通貨を用いて決済が行われるよう制御すること
を特徴とする請求項１〜７のいずれか一つに記載の情報処理装置。
【請求項９】
購入特典が付与される日時に関する情報をユーザへ提供する提供部
を備えること
を特徴とする請求項１〜８のいずれか一つに記載の情報処理装置。
【請求項１０】
コンピュータが実行する情報処理方法であって、
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求に関する情報をユーザ端末から受け付けて記憶部に記憶する受付工程と、
前記記憶部に記憶された前記情報に基づく前記購入日時に、前記ユーザ端末のユーザに対する前記商品の決済が行われるよう制御する決済工程と
を含み、
前記決済工程は、
前記購入日時に決済の許可要求を前記ユーザ端末へ通知し、前記ユーザ端末により当該許可要求が承認された場合に、当該商品の購入を確定させて、決済を行うこと
を特徴とする情報処理方法。
【請求項１１】
現在よりも未来の日時が商品の購入日時として指定される前記商品の購入要求に関する情報をユーザ端末から受け付けて記憶部に記憶する受付手順と、
前記記憶部に記憶された前記情報に基づく前記購入日時に、前記ユーザ端末のユーザに対する前記商品の決済が行われるよう制御する決済手順と
をコンピュータに実行させ、
前記決済手順は、
前記購入日時に決済の許可要求を前記ユーザ端末へ通知し、前記ユーザ端末により当該許可要求が承認された場合に、当該商品の購入を確定させて、決済を行うこと
を特徴とする情報処理プログラム。