(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-05-09
(45)【発行日】2022-05-17
(54)【発明の名称】販売制御装置、販売制御方法および販売制御プログラム
(51)【国際特許分類】
G06Q 30/06 20120101AFI20220510BHJP
G06F 16/9538 20190101ALI20220510BHJP
【FI】
G06Q30/06 308
G06F16/9538
(21)【出願番号】P 2017168065
(22)【出願日】2017-08-31
【審査請求日】2018-10-18
【審判番号】
【審判請求日】2020-06-17
(73)【特許権者】
【識別番号】319013263
【氏名又は名称】ヤフー株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】特許業務法人酒井国際特許事務所
(72)【発明者】
【氏名】山中 祥太
(72)【発明者】
【氏名】坪内 孝太
(72)【発明者】
【氏名】寺岡 照彦
【合議体】
【審判長】渡邊 聡
【審判官】高瀬 勤
【審判官】松田 直也
(56)【参考文献】
【文献】特開2017-76219(JP,A)
【文献】特許第6142954(JP,B1)
【文献】特開2003-263582(JP,A)
【文献】特開2013-225259(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q10/00-99/00
G06F16/00-16/958
(57)【特許請求の範囲】
【請求項1】
電子商取引サービスにおいて販売される商品またはサービスに関する商品情報であって、支援物資または支援サービスとなる対象商品であるか否かの情報が紐付いた商品情報を記憶する記憶部と、
災害が発生した場合に、前記記憶部に記憶された前記商品情報に基づいて、前記電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる前記対象商品について、当該災害に伴う被災地のユーザから
検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、前記対象商品を購入可能な
検索結果画面を表示し、前記被災地以外のユーザから
検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、検索結果画面に前記被災地以外のユーザが前記対象商品を購入することを禁止することを示す表示を行う販売制御部と、
を備え、
前記販売制御部は、
前記被災地のユーザ
に対する検索結果に前記対象商品および前記対象商品ではない前記商品またはサービスが含ま
れる場合において検索結果画面を表示する場合に、前記対象商品となる前記商品またはサービスを前記対象商品ではない前記商品またはサービスよりも表示順位を先にすること
を特徴とする販売制御装置。
【請求項2】
前記対象商品の配送先を示す配送情報を含む購入要求を購入ユーザから受け付ける購入受付部をさらに備え、
前記販売制御部は、
前記購入受付部が受け付けた前記購入要求の配送情報に基づき、前記配送先が被災地以外の場所であった場合、前記購入ユーザによる前記対象商品の購入を禁止すること
を特徴とする請求項1に記載の販売制御装置。
【請求項3】
前記販売制御部は、
前記対象商品を前記被災地のユーザのみへ販売すること
を特徴とする請求項1または2に記載の販売制御装置。
【請求項4】
前記販売制御部は、
前記被災地のユーザに対する前記対象商品の販売の価格を被災地以外のユーザに対する前記対象商品の販売の価格よりも安くすること
を特徴とする請求項1~3のいずれか1つに記載の販売制御装置。
【請求項5】
前記対象商品は、複数の種別の前記商品を含み、
前記販売制御部は、
前記災害が発生してからの期間に応じて、前記対象商品の種別毎に、前記被災地のユーザが購入可能な在庫数の割合を増減すること
を特徴とする請求項1~4のいずれか1つに記載の販売制御装置。
【請求項6】
販売制御装置が実行する販売制御方法であって、
電子商取引サービスにおいて販売される商品またはサービスに関する商品情報であって、支援物資または支援サービスとなる対象商品であるか否かの情報が紐付いた商品情報を記憶部に記憶する記憶工程と、
災害が発生した場合に、前記記憶部に記憶された前記商品情報に基づいて、前記電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる前記対象商品について、当該災害に伴う被災地のユーザから
検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、前記対象商品を購入可能な
検索結果画面を表示し、前記被災地以外のユーザから
検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、検索結果画面に前記被災地以外のユーザが前記対象商品を購入することを禁止することを示す表示を行う販売制御工程と、
を含み、
前記販売制御工程は、
前記被災地のユーザ
に対する検索結果に前記対象商品および前記対象商品ではない前記商品またはサービスが含ま
れる場合において検索結果画面を表示する場合に、前記対象商品となる前記商品またはサービスを前記対象商品ではない前記商品またはサービスよりも表示順位を先にすること
を特徴とする販売制御方法。
【請求項7】
電子商取引サービスにおいて販売される商品またはサービスに関する商品情報であって、支援物資または支援サービスとなる対象商品であるか否かの情報が紐付いた商品情報を記憶部に記憶する記憶手順と、
災害が発生した場合に、前記記憶部に記憶された前記商品情報に基づいて、前記電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる前記対象商品について、当該災害に伴う被災地のユーザから
検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、前記対象商品を購入可能な
検索結果画面を表示し、前記被災地以外のユーザから
検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、検索結果画面に前記被災地以外のユーザが前記対象商品を購入することを禁止することを示す表示を行う販売制御手順と、
をコンピュータに実行させ、
前記販売制御手順は、
前記被災地のユーザ
に対する検索結果に前記対象商品および前記対象商品ではない前記商品またはサービスが含ま
れる場合において検索結果画面を表示する場合に、前記対象商品となる前記商品またはサービスを前記対象商品ではない前記商品またはサービスよりも表示順位を先にすること
を特徴とする販売制御プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、販売制御装置、販売制御方法および販売制御プログラムに関する。
【背景技術】
【0002】
従来、自然災害等が発生した際に、ユーザがストアの商品を購入し、支援物資として被災地へ供給する技術が提供されている。例えば、支援物資となる対象商品を予め在庫として確保しておき、災害発生時に必要量を被災地へ送る技術が提案されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、上記した従来技術では、例えば、被災地以外のユーザが支援物資を大量に購入する等した場合、十分な量の支援物資を被災地のユーザへ販売できないおそれがあった。また、支援物資を大量に確保したユーザが高額で転売等した場合、被災地のユーザが適切な価格で支援物資を購入できないおそれがあった。
【0005】
本願は、上記に鑑みてなされたものであって、被災地のユーザに対して支援物資を適切に販売することができる販売制御装置、販売制御方法および販売制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【0006】
本願に係る販売制御装置は、災害が発生した場合に、電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる対象商品を当該災害に伴う被災地用として販売する制御を行う販売制御部と、を備えることを特徴とする。
【発明の効果】
【0007】
実施形態の一態様によれば、被災地のユーザに対して支援物資や支援サービスを適切に販売することができるという効果を奏する。
【図面の簡単な説明】
【0008】
【
図1】
図1は、実施形態に係る販売制御処理の一例を示す図である。
【
図2】
図2は、実施形態に係る販売制御装置の構成例を示す図である。
【
図8】
図8は、販売制御部の処理内容を示す図である。
【
図9】
図9は、検索結果を示す画面例を示す図である。
【
図11】
図11は、実施形態に係る販売制御装置が実行する販売制御処理の処理手順を示すフローチャートである。
【
図12】
図12は、実施形態に係る販売制御装置が実行する購入処理の処理手順を示すフローチャートである。
【
図13】
図13は、実施形態に係る販売制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
【発明を実施するための形態】
【0009】
以下に、本願に係る販売制御装置、販売制御方法および販売制御プログラムを実施するための形態(以下、「実施形態」と記載する)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る販売制御装置、販売制御方法および販売制御プログラムが限定されるものではない。また、以下の各実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。
【0010】
(実施形態)
〔1.販売制御処理〕
まず、
図1を用いて、実施形態に係る販売制御処理の一例について説明する。
図1は、実施形態に係る販売制御処理の一例を示す図である。
図1に示す例では、商品の販売元(以下、ストアともいう)が商品を登録し、ユーザU1,U2が商品を検索する販売システムSについて示している。なお、ここでいう商品とは、食料や衣類等のストアが扱う物品を含む。また、商品は、ショッピングストアの物品に限らず、所定のサービスを含む。かかるサービスの一例として、宿泊施設(一般のホテルやAirB&B等)の確保や各種交通機関(飛行機、鉄道、レンタカー)の予約等のサービス等がある。特に、レンタカーでは、小回りのきく小型車、支援物資を運ぶための4輪駆動車、トラック等の被災地で特に需要が高まる車種の予約を優先させる。
【0011】
図1に示すように、実施形態に係る販売システムSは、販売制御装置1と、ユーザ端末100-1,100-2と、ストア端末10とを備える。販売制御装置1と、ユーザ端末100-1,100-2と、ストア端末10とは、図示しない所定のネットワークN(
図13参照)を介して、有線または無線により通信可能に接続される。
【0012】
なお、
図1に示した販売システムSには、複数台のユーザ端末100-1,100-2が含まれるが、例えば、複数台のストア端末10が含まれてもよい。また、複数台のユーザ端末100-1,100-2をユーザ端末100と記載する場合がある。
【0013】
ユーザ端末100は、ユーザによって利用される情報処理装置である。ユーザ端末100は、例えば、スマートフォンや、タブレット型端末や、ノート型PC(Personal Computer)や、デスクトップPCや、携帯電話機や、PDA(Personal Digital Assistant)等により実現される。また、
図1に示す例では、ユーザ端末100-1は、災害に伴う被災地のユーザU1が利用し、ユーザ端末100-2は、被災地以外のユーザU2が利用する場合を示す。
【0014】
ストア端末10は、販売元であるストアの管理者M1によって利用される情報処理装置である。例えば、ストアの管理者M1は、ストア端末10を用いて、電子商取引サービスにおいて販売する商品を追加する。また、ストア端末10は、例えば、スマートフォンや、タブレット型端末や、ノート型PCや、デスクトップPCや、携帯電話機や、PDA等により実現される。
図1は、ストア端末10がデスクトップPCである場合を示す。
【0015】
販売制御装置1は、ショッピングサービスやオークションサービス等の電子商取引サービスを提供するとともに、ストアから登録された商品の販売制御を行う。また、販売制御装置1は、災害の発生を検出する。ここで、災害とは、暴風、豪雨、豪雪、洪水、高潮、地震、津波、噴火等の自然災害や、車両、船舶、列車、飛行機等の交通事故のような人為的災害等を含む。また販売制御装置1は、災害を検出した場合に、電子商取引サービスにおいて販売される商品のうち、災害に応じた支援物資または支援サービスとなる対象商品を災害に伴う被災地のユーザU1に対して優先的に販売する制御を行う。
【0016】
ここで、従来の販売制御装置について説明する。従来の販売制御装置は、被災地のユーザに対して支援物資を適切に販売できないおそれがあった。例えば、被災地以外のユーザが支援物資を大量に購入する等した場合、十分な量の支援物資を被災地のユーザへ販売できないおそれがあった。また、支援物資を大量に確保した被災地以外のユーザが高額で転売等した場合、被災地のユーザが適切な価格で支援物資を購入できないおそれがあった。
【0017】
そこで、実施形態に係る販売制御装置1は、販売制御処理を実行し、災害発生時には、支援物資となる対象商品を被災地用として販売する制御を行う。
図1を用いて、販売制御処理について具体的に説明する。なお、
図1では、支援物資として「水」が設定されていることとする。
【0018】
図1に示すように、販売制御処理では、まず、ストアの管理者Aから商品の登録を受け付ける(ステップS1)。例えば、ストアの管理者Aは、商品を登録する際、災害発生時に、支援物資となる対象商品としてかかる商品を販売してもよい旨を通知する。
【0019】
つづいて、販売制御装置1は、災害が発生していない通常時には、ユーザU1およびユーザU2に対してショッピングにおける商品の検索結果や商品の詳細ページ等をユーザ端末100-1,100-2に表示させる。
【0020】
そして、販売制御装置1は、災害の発生を検出すると(ステップS2)、被災地のユーザU1に対して支援物資を優先的に販売する制御モードに切り替える(ステップS3)。なお、かかる制御モードについては、
図3で後述する。
【0021】
つづいて、販売制御装置1は、ユーザ端末100-1から送信される被災地のユーザU1から商品を検索する検索クエリ「水」を受け付ける(ステップS4-1)とともに、ユーザ端末100-2から送信される被災地以外のユーザU2から検索クエリ「水」を受け付ける(ステップS4-2)。
【0022】
そして、販売制御装置1は、ユーザ端末100-1へ検索クエリに対する結果を送信する(ステップS5-1)。具体的には、販売制御装置1は、被災地のユーザU1が利用するユーザ端末100-1に対しては、検索クエリ「水」に対応する検索結果を送信し、ユーザU1が対象商品を購入可能な画面を表示させる。
【0023】
また、販売制御装置1は、ユーザ端末100-2へ検索クエリに対する結果を送信する(ステップS5-2)。具体的には、販売制御装置1は、被災地以外のユーザU2が利用するユーザ端末100-2に対しては、検索クエリ「水」に対する結果として、対象商品である「水」が購入できない旨を通知する。
【0024】
つまり、実施形態に係る販売制御装置1は、支援物資となる対象商品を被災地のユーザU1が購入可能とする一方で、被災地以外のユーザU2が対象商品を購入できないようにする。これにより、被災地以外のユーザU2が支援物資となる対象商品を大量に購入することができなくなるとともに、高額での転売もできなくなる。従って、実施形態に係る販売制御装置1によれば、被災地のユーザU1に対して支援物資や支援サービスを適切に販売することができる。
【0025】
なお、
図1に示す例では、被災地以外のユーザU2が対象商品すべてを購入できないようにしたが、例えば、水の全在庫のうち、一定の割合(例えば、50%)を被災地用として確保し、残りの在庫について被災地以外用として販売してもよい。また、被災地用して確保した対象商品を、例えば、被災地以外のユーザU2が被災地へ寄付するために購入するのであれば販売してもよい。
【0026】
また、
図1では、対象商品である「水」を被災地以外のユーザU2が購入できない旨を通知したが、例えば、購入できない旨を通知しなくてもよい。例えば、検索結果の画面に被災地以外のユーザU20が購入可能な商品(例えば、対象商品として設定されていない「水」)のみを表示することとしてもよい。つまり、ユーザU20にとっては、対象商品以外の商品を普段通り購入可能にすることで、被災地以外のユーザU20の利便性が低下することを防止できる。
【0027】
〔2.販売制御装置1の構成〕
次に、
図2を用いて、実施形態に係る販売制御装置1の構成について説明する。
図2は、実施形態に係る販売制御装置1の構成例を示す図である。
図2に示すように、販売制御装置1は、通信部2と、制御部3と、記憶部4とを有する。なお、販売制御装置1は、販売制御装置1の管理者等から各種操作を受け付ける入力部(例えば、キーボードやマウス等)や、各種情報を表示するための表示部(例えば、液晶ディスプレイ等)を有してもよい。
【0028】
(2-1.通信部2)
通信部2は、例えば、NIC(Network Interface Card)等によって実現される。そして、通信部2は、ネットワークNと有線または無線で接続され、例えば販売システムSに含まれるユーザ端末100やストア端末10等の間で情報の送受信を行う。
【0029】
(2-2.記憶部4)
記憶部4は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。
図2に示すように、実施形態に係る記憶部4は、モード情報41と、商品情報42と、ストア情報43と、支援物資情報44と、ユーザ情報45とを記憶する。
【0030】
(2-2-1.モード情報41)
モード情報41は、後述する販売制御部34における制御モードを示す情報である。
図3は、モード情報41を示す図である。
図3に示すように、モード情報41には、通常時モードst1および非常時モードst2の2つの制御モードが存在する。
【0031】
通常時モードst1は、全てのユーザU1,U2に対して商品(対象商品および対象商品以外)を平等に販売する制御モードである。非常時モードst2は、被災地のユーザU1に対して支援物資となる対象商品を優先的に販売する制御モードである。
【0032】
後述する販売制御部34は、これら2つの制御モードのうち、通常時は、通常時モードst1を読み出して実行するとともに、後述する検出部33によって災害の発生が検出された場合には、通常時モードst1から非常時モードst2へ切り替える。
【0033】
(2-2-2.商品情報42)
商品情報42は、ストアによって登録された商品に関する情報である。
図4は、商品情報42を示す図である。
図4に示すように、商品情報42には、「商品ID」、「商品名」、「カテゴリ」、「ストア」、「価格(2L×6本)」、「在庫数」、「支援物資フラグ」といった項目が含まれる。
【0034】
「商品ID」は、商品を識別するための識別情報である。「商品名」は、商品の登録名を示す名称に関する情報である。「カテゴリ」は、商品の種別であり、具体的な名称等を示す情報である。「ストア」は、商品を販売しているストアの名称を示す情報である。「価格(2L×6本)」は、商品の売価(
図4では、2Lの水6本の売価)を示す。「在庫数」は、商品の在庫数を示す。「支援物資フラグ」は、商品が支援物資となる対象商品であるか否かを示す情報である。
【0035】
図4に示す例において、商品ID「GD1」は、商品名が「天然水A」であり、商品の種別が「食料」であり、ストアの名称が「ストアA」であり、1ケース(2L×6本)あたりの価格が「480」円であり、在庫数が「10000」ケースであることを示している。また、商品ID「GD1」は、支援物資フラグが「1」であることから、災害発生時に、支援物資となる対象商品であることを示す。
【0036】
また、商品ID「GD2」は、商品名が「天然水B」であり、商品の種別が「食料」であり、ストアの名称が「ストアB」であり、1ケース(2L×6本)あたりの価格が「540」円であり、在庫数が「5000」ケースであることを示している。また、商品ID「GD2」は、支援物資フラグが「0」であることから、災害発生時に、支援物資とならない商品であることを示す。
【0037】
つまり、災害発生時において、「天然水A」は、被災地のユーザU1が購入可能で、被災地以外のユーザU2が購入できない商品であり、「天然水B」は、被災地のユーザU1および被災地以外のユーザU2双方が購入可能な商品であることを示す。
【0038】
なお、商品情報42は、上記に限らず、目的に応じて種々の情報が含まれてもよい。例えば、商品情報42には、商品が追加された日時や商品が作成された日時に関する情報が含まれてもよい。また、商品情報42は、商品の画像や粗利、送料の有無、送料、商品を検索する際に使用されるキーワード、商品の種別等といった各種の情報が含まれてもよい。例えば、商品情報42には、「カテゴリ」として、階層的なカテゴリの情報が含まれてもよい。例えば、商品情報42は、商品「天然水A」の「カテゴリ」として、第1階層「食料」、第2階層「飲料」、第3階層「水」、第4階層「ミネラルウォータ」等のように階層的なカテゴリの情報が含まれてもよい。
【0039】
(2-2-3.ストア情報43)
ストア情報43は、商品の販売元であるストアに関する情報である。
図5は、ストア情報43を示す図である。
図5に示すように、ストア情報43には、「ストアID」、「ストア」、「店舗住所」、「商品数」、「支援物資登録数」といった項目を含む。なお、
図5に示すストア情報43は一例であって、すべての項目を含む必要はない。
【0040】
「ストアID」は、ストアを識別するための識別情報である。「ストア」は、商品を販売しているストアの名称を示す情報である。「店舗住所」は、ストアの実店舗の住所を示す情報である。「商品数」は、ストアが扱う商品の種類の数であり、ショッピングサービスに登録している商品の種類の数を示す情報である。「支援物資登録数」は、「商品数」のうち、支援物資となる対象商品として登録されている商品数を示す情報である。
【0041】
図5に示す例において、ストアID「SD1」は、ストアの名称が「ストアA」であり、実際の店舗の住所が「AA」であり、取り扱っている商品数が「50」種類であり、そのうち支援物資として「15」種類の商品が登録されていることを示す。
【0042】
なお、ストア情報43は、上記に限らず、目的に応じて種々の情報が含まれてもよい。例えば、実店舗を持たないストアにおいて、ストア情報43には、「店舗住所」として、商品の保管場所の住所が含まれてもよい。
【0043】
(2-2-4.支援物資情報44)
支援物資情報44は、支援物資となる対象商品に関する情報である。
図6は、支援物資情報44を示す図である。
図6に示すように、支援物資情報44は、「物資ID」、「カテゴリ」、「全在庫数」、「支援物資登録数」といった項目を含む。
【0044】
「物資ID」は、支援物資となる対象商品を識別するための識別情報である。「カテゴリ」は、対象商品の種別を示す情報である。「全在庫数」は、全ストアにおける商品の全ての在庫数を示す情報である。「支援物資登録数」は、「全在庫数」のうち支援物資となる対象商品として登録された在庫数を示す情報である。
【0045】
図6に示す例において、物資ID「1」は、対象商品の種別が「水」であり、「水」に対応する商品の全在庫数が「20000」個であり、そのうち対象商品として「10000」個が登録されていることを示す。
【0046】
(2-2-5.ユーザ情報45)
ユーザ情報45は、例えば、ショッピングサービスに登録されたユーザU1,U2に関する情報である。
図7は、ユーザ情報45を示す図である。
図7に示すように、ユーザ情報45には、「ユーザID」、「性別」、「年齢」、「住所」、「登録配送先」といった項目が含まれる。
【0047】
「ユーザID」は、ユーザU1,U2を識別するための識別情報である。「性別」は、ユーザU1,U2の性別を示す情報である。「年齢」は、ユーザU1,U2の年齢を示す情報である。「住所」は、ユーザU1,U2の住所を示す情報である。「登録配送先」は、ユーザU1,U2が商品を購入した場合の配送先の候補を示す情報である。
【0048】
図7に示す例において、ユーザID「A」は、性別が「男性」であり、年齢が「30代」であり、住所が「FF」であり、商品の配送先の候補として「FF」の住所が登録されていることを示す。
【0049】
また、ユーザID「B」は、性別が「女性」であり、年齢が「50代」であり、住所が「HH」であり、商品の配送先の候補として「GG」の住所が登録されていることを示す。つまり、「住所」と「登録配送先」との住所が異なっていることを示す。
【0050】
図2の説明に戻って、制御部3は、コントローラ(controller)であり、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、販売制御装置1内部の記憶装置に記憶されている各種プログラム(情報提供プログラムの一例に相当)がRAMを作業領域として実行されることにより実現される。また、制御部3は、コントローラであり、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。
【0051】
図2に示すように、制御部3は、クエリ受付部31と、購入受付部32と、検出部33と、販売制御部34とを有し、以下に説明する販売制御処理の機能や作用を実現または実行する。
【0052】
(2-3.クエリ受付部31)
クエリ受付部31は、ユーザU1,U2によって指定され、ユーザ端末100から送信される各種クエリを受け付ける。例えば、クエリ受付部31は、ユーザ端末100からショッピングサービスに登録された商品を検索する検索クエリを受け付ける。
【0053】
また、クエリ受付部31は、災害時において、対象商品を検索する検索クエリを受け付ける。また、クエリ受付部31は、検索クエリに応じた検索結果がユーザU1,U2へ提供された後、例えば、商品の詳細ページを要求するクエリを受け付ける。
【0054】
(2-4.購入受付部32)
購入受付部32は、商品を購入する要求である購入要求をユーザU1,U2(購入ユーザの一例)から受け付ける。購入要求には、例えば、選択した商品を示す情報や、商品の購入数、支払方法、商品の配送先を示す配送情報等が含まれる。
【0055】
(2-5.検出部33)
検出部33は、災害の発生を検出する。例えば、検出部33は、災害として、暴風、豪雨、豪雪、洪水、高潮、地震、津波、噴火等の自然災害や、車両、船舶、列車、飛行機等の交通事故のような人為的災害等を検出する。
【0056】
具体的には、検出部33は、気象庁等の機関が発する緊急信号(例えば、緊急地震速報を示す信号)を受信することで、災害の発生を検出する。また、検出部33は、例えば、ユーザU1,U2が有するユーザ端末100に搭載されたジャイロセンサ等の値に基づいてユーザU1,U2の周辺で発生する揺れ(地震や、噴火に伴う揺れ等)に基づいて災害の発生を検出する。あるいは、ユーザ端末100から災害発生の通知を受け付けることで災害の発生を検出してもよい。
【0057】
また、検出部33は、ユーザU1,U2の入力操作によって災害の発生を受け付けることで検出してもよい。また、検出部33は、例えば台風のように移動する場合、かかる台風の予測進路を示す情報に基づいて災害の発生および被災地の特定を行ってもよい。
【0058】
また、検出部33は、災害の規模を検出する。例えば、検出部33は、気象庁から送信される災害情報に基づいて地震の震度や、台風の最大瞬間風速、降水量、波の高さ等といった情報を災害の規模として検出する。
【0059】
(2-6.販売制御部34)
販売制御部34は、商品の販売に関する制御を行う。例えば、販売制御部34は、災害が発生していない通常時において、ユーザU1,U2に検索クエリに対応する商品を抽出し、検索結果としてユーザ端末100へ送信する。
【0060】
また、販売制御部34は、検出部33によって災害の発生が検出された場合に、電子商取引サービスにおいて販売される商品のうち、当該災害に応じた支援物資となる対象商品を災害に伴う被災地用として販売する制御を行う。
【0061】
例えば、販売制御部34は、対象商品の全在庫のうち、被災地用として購入可能な在庫の割合を被災地以外用として購入可能な割合よりも多くする。具体的には、販売制御部34は、支援物資情報44の「支援物資登録数」のうち、例えば50%以上を被災地用として確保する。つまり、販売制御部34は、残りの50%未満を被災地以外のユーザU2に対して販売する。
【0062】
なお、確保する割合は、災害の規模に応じて変更してもよい。具体的には、販売制御部34は、検出部33によって検出された災害の規模が大きいほど、被災地用として購入可能な割合を多くする。例えば、販売制御部34は、地震の震度が「5」の場合、「支援物資登録数」のうち、50%を被災地用として確保し、震度が「6」の場合、60%を確保し、震度が「7」の場合、70%を確保するように制御する。
【0063】
また、販売制御部34は、対象商品を扱うストアのうち、対象商品の配送元が被災地に近いストアが扱う対象商品を被災地用として優先的に販売する。具体的には、販売制御部34は、被災地に近いストアの在庫を優先的に確保する。
【0064】
また、販売制御部34は、対象商品を扱うストアのうち、対象商品の被災地への納期が早いストアが扱う対象商品を被災地用として優先的に販売する。具体的には、販売制御部34は、ストアと契約しているもしくは頻繁に使用する宅配業者の配送状況を示す情報に基づいて対象商品の被災地までの納期を算出する。そして、販売制御部34は、算出した納期が早いストアが扱う対象商品の在庫を優先して確保する。このとき、販売制御部34は、「被災地への納期を早めます」といった特記事項をユーザU1,U2に対して提示する。
【0065】
また、販売制御部34は、クエリ受付部31が受け付けた検索クエリの送信元が被災地以外のユーザU2であった場合、かかるユーザU2に対して検索クエリに応じた検索結果の出力を禁止する。なお、販売制御部34は、検索結果の出力を禁止する際、ユーザU2に対して出力を禁止した旨を示す情報を通知するが、かかる点については
図10で後述する。また、検索クエリの送信元は、例えば、検索クエリのアクセス元IP(Internet Protocol)アドレスに関する情報を取得することで特定可能である。
【0066】
また、販売制御部34は、購入受付部32が受け付けた購入要求の配送情報に基づき、配送先が被災地以外の場所であった場合、購入ユーザ(例えば、ユーザU1,U2)による対象商品の購入を禁止する。かかる場合、販売制御部34は、購入ユーザに対して、「この商品は被災地にしか配送できません」といった注意喚起をすることが好ましい。
【0067】
また、販売制御部34は、各情報に基づいて優先する対象商品を絞ってもよい。例えば、販売制御部34は、気温や気候等の気象情報に基づいて優先する対象商品を選択してもよい。具体的には、販売制御部34は、気温が低下した場合、冬用の衣類や毛布等の確保量を多くしてもよい。
【0068】
また、販売制御部34は、避難所から送信される情報に基づいて対象商品を抽出してもよい。例えば、販売制御部34は、避難所に食料が過度に到着した場合、食料の確保量を減らし、代わりに他の種別の支援物資を多く確保することとしてもよい。
【0069】
また、販売制御部34は、避難所から新規の種別の支援物資の要求を受け付けた場合、支援物資情報44に新規の種別の支援物資を登録するとともに、商品情報42から新規の種別の支援物資の在庫を確保する。
【0070】
なお、販売制御部34は、被災地用に在庫を多く確保する場合に限らず、例えば、被災地用に確保した対象商品については販売の価格を下げる(例えば、10%オフ等)制御を行ってもよい。つまり、販売制御部34は、被災地用としての対象商品の価格を被災地以外用としての対象商品の価格よりも安く販売する。また、販売制御部34は、例えば、対象商品の被災地への配送を被災地以外の配送よりも優先させてもよい。
【0071】
また、販売制御部34は、災害が発生してから経過する時間で優先する対象商品の種別を切り替えてもよい。かかる点について、
図8を用いて説明する。
【0072】
図8は、販売制御部34の処理内容を示す図である。
図8では、時刻t1において、検出部33が災害の発生を検出したこととする。販売制御部34は、災害が発生してから第1の期間(以下、第1期間)が経過するまでは第1の対象商品を優先して販売し、第1の期間経過後の第2の期間(以下、第2期間)が経過するまでは第1の対象商品とは種別が異なる第2の対象商品を優先して販売する。
【0073】
具体的には、販売制御部34は、時刻t1から時刻t2の期間である第1期間では、対象商品「水」の在庫を確保する割合を比較的高くする。そして、販売制御部34は、時刻t2から時刻t3の期間である第2期間では、対象商品「毛布」の在庫を確保する割合を比較的高くする。
【0074】
換言すれば、販売制御部34は、第1期間では、対象商品「毛布」の在庫を確保する割合を比較的低くし、第2期間では、対象商品「水」の在庫を確保する割合を比較的低くする。なお、第1期間および第2期間は、過去の災害に関する情報に基づいて設定することができる。
【0075】
また、販売制御部34は、第1期間および第2期間の2つの期間に区切って対象商品を切り替えたが、区切る期間は、3つ以上でもよい。例えば、販売制御部34は、時刻t3以降の期間については、避難所から受け付けた対象商品の種別を割り当ててもよい。
【0076】
次に、
図9および
図10を用いて、販売制御部34が生成する検索結果を示す画面例について説明する。
図9および
図10は、検索結果を示す画面例を示す図である。
図9および
図10では、検索クエリ「水」が指定された場合の画面例を示す。また、
図9では、被災地のユーザU1のユーザ端末100に表示される検索結果画面d1を示し、
図10では、被災地以外のユーザU2のユーザ端末100に表示される検索結果画面d2を示す。また、
図9および
図10では、商品「天然水A」が対象商品であることとする。
【0077】
まず、
図9の検索結果画面d1について説明する。
図9に示すように、販売制御部34は、被災地のユーザU1から検索クエリ「水」が受け付けられると、「水」に対応する商品の項目R1,R2を一覧表示する。具体的には、販売制御部34は、支援物資となる対象商品の項目R1を対象商品ではない商品の項目R2よりも表示順位を先にする。より好ましくは、販売制御部34は、対象商品の項目R1の表示順位を1位にする。
【0078】
そして、販売制御部34は、「天然水A」が対象商品であることを示す強調表示R1aを項目R1の領域内に表示する。なお、販売制御部34は、対象商品ではない「天然水B」も検索結果画面d1に表示したが、表示しなくてもよい。つまり、販売制御部34は、対象商品のみを検索結果画面d1に表示してもよい。
【0079】
次に、
図10の検索結果画面d2について説明する。
図10に示すように、販売制御部34は、被災地以外のユーザU2から検索クエリ「水」が受け付けられると、「水」に対応する商品の項目R1,R2を一覧表示する。このとき、販売制御部34は、対象商品である「天然水A」の項目R1の領域内に購入できない旨を示す警告表示R1bを表示する。
【0080】
なお、
図10では、対象商品である「天然水A」の項目R1を検索結果画面d2に表示したが、項目R1を表示しなくてもよい。つまり、販売制御部34は、「天然水B」の項目R2の表示順位を1位にする。かかる場合、販売制御部34は、「支援物資対象商品については検索結果画面から除外しています」といった旨の表示を行うことが好ましい。
【0081】
また、
図10では、販売制御部34は、対象商品である「天然水A」を被災地以外のユーザU2が購入できないように検索結果を出力したが、これに限定されない。例えば、販売制御部34は、被災地以外のユーザU2が「天然水A」を被災地用として購入するのであれば検索結果を出力してもよい。つまり、販売制御部34は、被災地以外のユーザU2に対して検索クエリに応じた検索結果として、被災地以外用として購入することを禁止するための出力を行ってもよい。
【0082】
また、販売制御部34は、対象商品を被災地以外のユーザU2が購入することを禁止し、被災地のユーザU1のみが購入できるように対象商品の販売を制御してもよい。すなわち、販売制御部34は、被災地用としての対象商品を被災地のユーザU1のみへ販売する。
【0083】
なお、販売制御部34は、すべての商品のうち、事前登録された対象商品に限って被災地用として販売することとしたが、必ずしも事前登録される必要はなく、例えば、各ストアから強制的に対象商品を抽出することとしてもよい。
【0084】
〔3.処理手順〕
次に、
図11および
図12を用いて、実施形態に係る販売制御装置1が実行する処理の手順について説明する。
図9は、実施形態に係る販売制御装置1が実行する販売制御処理の手順を示すフローチャートである。
図10は、実施形態に係る販売制御装置1が実行する購入処理の手順を示すフローチャートである。
【0085】
まず、販売制御処理の手順について説明する。
図9に示すように、まず、検出部33は、災害の発生を検出する(ステップS101)。つづいて、販売制御部34は、検出部33によって災害の発生が検出された場合に、電子商取引サービスにおいて販売される商品のうち、災害に応じた支援物資となる対象商品を災害に伴う被災地のユーザU1に対して優先的に販売し(ステップS102)、処理を終了する。
【0086】
次に、購入処理の手順について説明する。
図10に示すように、クエリ受付部31は、対象商品の検索クエリを受け付ける(ステップS201)。つづいて、販売制御部34は、検索クエリのアクセス元IPアドレスが被災地であるか否かを判定する(ステップS202)。
【0087】
販売制御部34は、ユーザU1,U2の検索クエリのアクセス元IPアドレスが被災地である場合(ステップS202,Yes)、ユーザU1,U2の登録住所が被災地であるか否かを判定する(ステップS203)。
【0088】
つづいて、販売制御部34は、ユーザU1,U2の登録住所が被災地である場合(ステップS203,Yes)、検索クエリに対する検索結果を出力する(ステップS204)。
【0089】
つづいて、購入受付部32は、対象商品の購入要求を受け付ける(ステップS205)。つづいて、販売制御部34は、購入要求に含まれる配送情報に基づいて入力された配送先が被災地であるか否かを判定する(ステップS206)。
【0090】
販売制御部34は、入力された配送先が被災地であった場合(ステップS206,Yes)、対象商品の購入確定処理を行い(ステップS207)、処理を終了する。なお、購入確定処理とは、対象商品の代金支払い処理や配送手続き処理等を含む購入が完了するまでの処理である。
【0091】
一方、ステップS206において、販売制御部34は、入力された配送先が被災地でない場合(ステップS206,No)、処理を終了する、すなわち、対象商品の購入処理を行わない。また、ステップS203において、販売制御部34は、ユーザU1,U2の登録住所が被災地でない場合(ステップS203,No)、ユーザU1,U2の登録配送先が被災地であるか否かを判定する(ステップS208)。
【0092】
販売制御部34は、登録配送先が被災地であった場合(ステップS208,Yes)、処理をステップS204へ移行する。また、ステップS208において、販売制御部34は、登録配送先が被災地でなかった場合(ステップS208,No)、検索クエリに対する検索結果の出力を禁止(ステップS209)し、処理を終了する。
【0093】
また、ステップS202において、販売制御部34は、アクセス元IPアドレスが被災地でない場合(ステップS202,No)、処理をステップS209へ移行する。
【0094】
〔4.効果〕
上述してきたように、実施形態に係る販売制御装置1は、販売制御部34を備える。販売制御部34は、災害が発生した場合に、電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる対象商品を当該災害に伴う被災地用として販売する制御を行う。
【0095】
これにより、被災地以外のユーザU2が支援物資となる対象商品を大量に購入することができなくなるとともに、高額での転売もできなくなる。従って、実施形態に係る販売制御装置1によれば、被災地のユーザU1に対して支援物資を適切に販売することができる。
【0096】
また、実施形態に係る販売制御装置1において、販売制御部34は、対象商品の全在庫のうち、被災地用として購入可能な在庫の割合を被災地以外用として購入可能な在庫の割合よりも多くする。
【0097】
これにより、被災地のユーザU1に対象商品を確実に割り当てることができるとともに、被災地以外のユーザU2による対象商品の大量買い占めを防ぐことができる。
【0098】
また、実施形態に係る販売制御装置1において、検出部33は、災害の規模をさらに検出する。販売制御部34は、検出部33によって検出された災害の規模が大きいほど、被災地用として購入可能な在庫の割合を多くする。
【0099】
これにより、災害の規模が大きく、被災地での支援物資が大量に必要になった場合であっても、支援物資を被災地へ確実に供給することができる。
【0100】
また、実施形態に係る販売制御装置1において、販売制御部34は、対象商品を扱うストアのうち、対象商品の配送元が被災地に近いストアが扱う対象商品を被災地用として優先的に販売する。
【0101】
これにより、対象商品の輸送に費やす配送時間を削減することができるため、より早く被災地へ支援物資を供給することができる。
【0102】
また、実施形態に係る販売制御装置1において、販売制御部34は、対象商品を扱うストアのうち、当該対象商品の被災地への納期が早いストアが扱う対象商品を被災地用として優先的に販売する。
【0103】
これにより、対象商品の納期を可能な限り短くできるため、例えば賞味期限が短い食料等であっても被災地へ供給することができる。
【0104】
また、実施形態に係る販売制御装置1は、クエリ受付部31をさらに備える。クエリ受付部31は、対象商品を検索する検索クエリを受け付ける。販売制御部34は、クエリ受付部31が受け付けた検索クエリの送信元が被災地以外のユーザU2であった場合、当該ユーザU2に対して検索クエリに応じた検索結果として、被災地以外用として購入することを禁止するための出力を行う。
【0105】
これにより、被災地のユーザU1と被災地以外のユーザU2とを確実に選別することができる。
【0106】
また、実施形態に係る販売制御装置1は、購入受付部32をさらに備える。購入受付部32は、対象商品の配送先を示す配送情報を含む購入要求を購入ユーザから受け付ける。販売制御部34は、購入受付部32が受け付けた購入要求の配送情報に基づき、配送先が被災地以外の場所であった場合、購入ユーザによる対象商品の購入を禁止する。
【0107】
これにより、例えば被災地以外のユーザU2がIPアドレスを偽装したり、登録住所を偽住所として被災地に設定した場合であっても、被災地以外のユーザU2に誤って対象商品が購入されてしまうことを防止できる。
【0108】
また、実施形態に係る販売制御装置1において、対象商品は、複数の種別の商品を含む。販売制御部34は、災害が発生してから第1の期間が経過するまでは第1の対象商品を優先して販売し、第1の期間経過後の第2の期間が経過するまでは第1の対象商品とは種別が異なる第2の対象商品を優先して販売する。
【0109】
これにより、災害発生後において、真に必要な対象商品の在庫の確保量をリアルタイムにコントロールできるため、被災地のユーザU1の満足度を向上させることができる。
【0110】
また、実施形態に係る販売制御装置1において、販売制御部34は、被災地用としての対象商品を被災地のユーザU1のみへ販売する。
【0111】
これにより、被災地のユーザU1のみが支援物資となる対象商品を購入できるため、被災地に支援物資が届かないという事態を防ぐことができる。
【0112】
また、実施形態に係る販売制御装置1において、販売制御部34は、被災地用としての対象商品の価格を被災地以外用としての対象商品の価格よりも安く販売する。
【0113】
これにより、被災地のユーザU1は、対象商品を安く購入できるため、被災地のユーザU1の経済状況を悪化させることを防ぐことができる。
【0114】
〔5.プログラム〕
また、上述してきた実施形態にかかる販売制御装置1は、例えば
図13に示すような構成のコンピュータ1000によって実現される。
図13は、実施形態に係る販売制御装置1の機能を実現するコンピュータ1000の一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、及びメディアインターフェイス(I/F)1700を有する。
【0115】
CPU1100は、ROM1300又はHDD1400に格納されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を格納する。
【0116】
HDD1400は、CPU1100によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス1500は、ネットワークNを介して他の機器からデータを受信してCPU1100へ送り、CPU1100が生成したデータを、ネットワークNを介して他の機器へ送信する。
【0117】
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、生成したデータを、入出力インターフェイス1600を介して出力装置へ出力する。
【0118】
メディアインターフェイス1700は、記録媒体1800に格納されたプログラム又はデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、例えばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
【0119】
例えば、コンピュータ1000が実施形態にかかる販売制御装置1として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部3の機能を実現する。また、HDD1400には、記憶部4内のデータが格納される。コンピュータ1000のCPU1100は、これらのプログラムを、記録媒体1800から読み取って実行するが、他の例として、他の装置から、ネットワークNを介してこれらのプログラムを取得してもよい。
【0120】
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
【0121】
〔6.その他〕
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
【0122】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【0123】
また、上述してきた実施形態に記載した各処理は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【0124】
また、上記してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、検出部33は、検出手段や検出回路に読み替えることができる。
【符号の説明】
【0125】
1 販売制御装置
2 通信部
3 制御部
4 記憶部
10 ストア端末
31 クエリ受付部
32 購入受付部
33 検出部
34 販売制御部
41 モード情報
42 商品情報
43 ストア情報
44 支援物資情報
45 ユーザ情報
100 ユーザ端末
U1,U2 ユーザ