JP2019125273A - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Abstract

【課題】ユーザの利便性を向上させることができる情報処理装置、情報処理方法および情報処理プログラムを提供すること。【解決手段】本願に係る情報処理装置は、受付部と、購入処理部とを備える。受付部は、商品の購入日時の期限である購入期限が指定される商品の購入要求を受け付ける。購入処理部は、受付部によって受け付けられた購入要求に基づく購入期限までに商品を提供可能である場合に、商品の購入処理を行う。【選択図】図３

Description

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

近年、インターネットなどのネットワークの飛躍的な普及に伴い、かかるネットワークを介した電子的な情報通信によって商品やサービスの売買などを行う電子商取引が盛んに行われている。

かかる電子商取引においては、複数の電子商店（以下、「ストア」と言う）を一同に集め、商品検索や決済処理の統一を図って利便性を向上させた、電子商店街（以下、「モール」と言う）も知られている。

モールは、例えば媒体社等の事業者によって運営されており、ストアで在庫切れであった商品が再度入荷された場合に、購入希望者に対して商品の再入荷を通知するものがある（例えば、特許文献１参照）。

国際公開第２０１４／１４１３２４号

しかしながら、上記した従来技術では、目当ての商品の再入荷がユーザの所望する期限を超えた場合、ユーザが自身で購入のキャンセル手続きを行う必要があった。このため、従来技術においては、ユーザの操作が増えるので、利便性を向上させるうえで改善の余地があった。

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

本願に係る情報処理装置は、受付部と、購入処理部とを備える。前記受付部は、商品の購入日時の期限である購入期限が指定される前記商品の購入要求を受け付ける。前記購入処理部は、前記受付部によって受け付けられた前記購入要求に基づく前記購入期限までに前記商品を提供可能である場合に、前記商品の購入処理を行う。

実施形態の一態様によれば、ユーザの利便性を向上させることができる。

図１は、実施形態に係る情報処理の一例を示す図である。 図２は、実施形態に係る情報処理システムの構成を示す図である。 図３は、実施形態に係るモールサーバの構成を示すブロック図である。 図４Ａは、実施形態に係るストア情報記憶部の一例を示す図である。 図４Ｂは、実施形態に係る商品情報記憶部の一例を示す図である。 図４Ｃは、実施形態に係る在庫情報記憶部の一例を示す図である。 図５は、実施形態に係る商品情報の一例を示す図（その１）である。 図６は、実施形態に係る商品情報の一例を示す図（その２）である。 図７は、実施形態に係るストアの在庫の有無による表示画面の一例を示す図である。 図８は、実施形態に係る管理部による処理の具体例を示す図である。 図９は、実施形態に係る購入期限の選択画面の一例を示す図である。 図１０は、実施形態に係る購入画面の一例を示す図である。 図１１は、実施形態に係る決済画面の一例を示す図である。 図１２は、実施形態に係る購入処理における価格の一例を示す図である。 図１３は、実施形態に係る通知部による処理の一例を示す図である。 図１４は、実施形態に係る配送通知に伴う決済処理の一例を示す図である。 図１５は、実施形態に係るモールサーバが実行する処理手順を示すフローチャートである。 図１６は、実施形態に係るモールサーバの機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

また、以下では、実施形態に係る情報処理装置が、モールサーバ１００である場合を例に挙げて説明する。モールサーバ１００は、電子商店街であるモールの運営事業者によって運用・管理されるサーバ装置である。

〔１．情報処理の一例〕
まず、実施形態に係る情報処理の一例について、図１を用いて説明する。図１は、実施形態に係る情報処理の一例を示す図である。

図１に示すモールサーバ１００は、モールを運営するためのサーバ装置である。例えば、モールサーバ１００は、モールにおいてユーザＵ０１および出品者Ｓ０１間で売買される商品の商品検索や決済処理を統一化するプラットフォームを提供する。また、モールサーバ１００は、かかるプラットフォームを介してモールが円滑に運用されるように管理する。例えば、モールサーバ１００は、ウェブサーバとしての機能を有しており、上記プラットフォームの一例として、ユーザＵ０１向けのポータルサイトや、出品者Ｓ０１向けの商品管理サイト等を提供する。

図１に示す出品者Ｓ０１は、モールにおける各ストアを運営し、ユーザＵ０１に対して商品を販売する出品者の一例である。出品者Ｓ０１は、ストア端末２０を利用して、販売する商品の登録や、決済、在庫管理といった、電子商取引における売り手としての各種手続きを行う。ストア端末２０は、例えばデスクトップ型ＰＣ（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）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ モールシステム
１０ ユーザ端末
２０ ストア端末
３０ 配送者端末
１００ モールサーバ（情報処理装置の一例）
１１０ 通信部
１２０ 記憶部
１２１ ストア情報記憶部
１２２ 商品情報記憶部
１２３ 在庫情報記憶部
１３０ 制御部
１３１ 取得部
１３２ 受付部
１３３ 管理部
１３４ 購入処理部
１３５ 通知部
Ｓ０１ 出品者
Ｕ０１ ユーザ

Claims (16)

1. 商品の購入日時の期限である購入期限が指定される前記商品の購入要求を受け付ける受付部と、
   前記受付部によって受け付けられた前記購入要求に基づく前記購入期限までに前記商品を提供可能である場合に、前記商品の購入処理を行う購入処理部と
   を備えることを特徴とする情報処理装置。
2. 前記購入処理部は、
   前記購入期限までに前記商品を提供可能でない場合、前記商品の購入をキャンセルすること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記受付部は、
   複数のストアに対する同一の前記商品の前記購入要求を受け付け、
   前記購入処理部は、
   前記複数のストアのうち、前記購入期限までに前記商品を提供可能な前記ストアで前記購入処理を行い、残りの前記ストアに対する購入をキャンセルすること
   を特徴とする請求項１または２に記載の情報処理装置。
4. 前記受付部は、
   前記商品と当該商品の代替品とを含む前記購入要求を受け付け、
   前記購入処理部は、
   前記商品と前記代替品とのうち、前記購入期限までに提供可能な前記商品または前記代替品について前記購入処理を行い、残りの前記商品または前記代替品について購入をキャンセルすること
   を特徴とする請求項１、２または３に記載の情報処理装置。
5. 前記購入処理部は、
   前記商品がユーザに届く日時を前記購入期限とすること
   を特徴とする請求項１〜４のいずれか一つに記載の情報処理装置。
6. 前記購入処理部は、
   前記商品を配送する配送業者から配送完了の通知を受けて決済処理を行うこと
   を特徴とする請求項１〜５のいずれか一つに記載の情報処理装置。
7. 複数のストアにおける前記商品の在庫状況を管理する管理部
   を備え、
   前記購入処理部は、
   前記管理部によって管理される前記在庫状況に基づき、前記購入期限までに前記商品を提供可能な前記ストアで購入処理を行うこと
   を特徴とする請求項１〜６のいずれか一つに記載の情報処理装置。
8. 前記管理部は、
   前記在庫状況をユーザへ提供すること
   を特徴とする請求項７に記載の情報処理装置。
9. 前記在庫状況が前記複数のストアで前記商品が在庫切れであり、前記受付部によって前記購入要求が受け付けられた場合に、前記複数のストアへ前記商品の入荷要求を通知する通知部
   を備え、
   前記購入処理部は、
   前記複数のストアのうち、最も早く前記商品を入荷した前記ストアで購入処理を行い、残りの前記ストアに対して購入をキャンセルすること
   を特徴とする請求項７または８に記載の情報処理装置。
10. 前記購入処理部は、
    前記購入要求が受け付けられた時の前記商品の価格を上限として前記購入処理を行うこと
    を特徴とする請求項１〜９のいずれか一つに記載の情報処理装置。
11. 前記購入処理部は、
    前記購入要求が受け付けられた時の前記商品の価格で前記購入処理を行うこと
    を特徴とする請求項１０に記載の情報処理装置。
12. 前記購入処理部は、
    前記購入期限までに付与される仮想通貨を用いて前記購入処理を行うこと
    を特徴とする請求項１〜１１のいずれか一つに記載の情報処理装置。
13. 前記購入処理部は、
    前記購入要求に含まれる商品について一覧情報をユーザへ提供すること
    を特徴とする請求項１〜１２のいずれか一つに記載の情報処理装置。
14. 前記受付部は、
    前記購入処理部による前記購入処理が完了する前であれば、前記商品の購入のキャンセルをユーザから受け付けること
    を特徴とする請求項１〜１３のいずれか一つに記載の情報処理装置。
15. コンピュータが実行する情報処理方法であって、
    商品の購入日時の期限である購入期限が指定される前記商品の購入要求を受け付ける受付工程と、
    前記受付工程によって受け付けられた前記購入要求に基づく前記購入期限までに前記商品を提供可能である場合に、前記商品の購入処理を行う購入処理工程と
    を含むことを特徴とする情報処理方法。
16. 商品の購入日時の期限である購入期限が指定される前記商品の購入要求を受け付ける受付手順と、
    前記受付手順によって受け付けられた前記購入要求に基づく前記購入期限までに前記商品を提供可能である場合に、前記商品の購入処理を行う購入処理手順と
    をコンピュータに実行させることを特徴とする情報処理プログラム。

Images