JP7068790B2 - 販売制御装置、販売制御方法および販売制御プログラム - Google Patents

Description

本発明は、販売制御装置、販売制御方法および販売制御プログラムに関する。

従来、自然災害等が発生した際に、ユーザがストアの商品を購入し、支援物資として被災地へ供給する技術が提供されている。例えば、支援物資となる対象商品を予め在庫として確保しておき、災害発生時に必要量を被災地へ送る技術が提案されている。

特開２０１７－６５９０９号公報

しかしながら、上記した従来技術では、例えば、被災地以外のユーザが支援物資を大量に購入する等した場合、十分な量の支援物資を被災地のユーザへ販売できないおそれがあった。また、支援物資を大量に確保したユーザが高額で転売等した場合、被災地のユーザが適切な価格で支援物資を購入できないおそれがあった。

本願は、上記に鑑みてなされたものであって、被災地のユーザに対して支援物資を適切に販売することができる販売制御装置、販売制御方法および販売制御プログラムを提供することを目的とする。

本願に係る販売制御装置は、災害が発生した場合に、電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる対象商品を当該災害に伴う被災地用として販売する制御を行う販売制御部と、を備えることを特徴とする。

実施形態の一態様によれば、被災地のユーザに対して支援物資や支援サービスを適切に販売することができるという効果を奏する。

図１は、実施形態に係る販売制御処理の一例を示す図である。 図２は、実施形態に係る販売制御装置の構成例を示す図である。 図３は、モード情報を示す図である。 図４は、商品情報を示す図である。 図５は、ストア情報を示す図である。 図６は、支援物資情報を示す図である。 図７は、ユーザ情報を示す図である。 図８は、販売制御部の処理内容を示す図である。 図９は、検索結果を示す画面例を示す図である。 図１０は、検索結果を示す画面例を示す図である。 図１１は、実施形態に係る販売制御装置が実行する販売制御処理の処理手順を示すフローチャートである。 図１２は、実施形態に係る販売制御装置が実行する購入処理の処理手順を示すフローチャートである。 図１３は、実施形態に係る販売制御装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

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

（実施形態）
〔１．販売制御処理〕
まず、図１を用いて、実施形態に係る販売制御処理の一例について説明する。図１は、実施形態に係る販売制御処理の一例を示す図である。図１に示す例では、商品の販売元（以下、ストアともいう）が商品を登録し、ユーザＵ１，Ｕ２が商品を検索する販売システムＳについて示している。なお、ここでいう商品とは、食料や衣類等のストアが扱う物品を含む。また、商品は、ショッピングストアの物品に限らず、所定のサービスを含む。かかるサービスの一例として、宿泊施設（一般のホテルやＡｉｒＢ＆Ｂ等）の確保や各種交通機関（飛行機、鉄道、レンタカー）の予約等のサービス等がある。特に、レンタカーでは、小回りのきく小型車、支援物資を運ぶための４輪駆動車、トラック等の被災地で特に需要が高まる車種の予約を優先させる。

図１に示すように、実施形態に係る販売システムＳは、販売制御装置１と、ユーザ端末１００－１，１００－２と、ストア端末１０とを備える。販売制御装置１と、ユーザ端末１００－１，１００－２と、ストア端末１０とは、図示しない所定のネットワークＮ（図１３参照）を介して、有線または無線により通信可能に接続される。

なお、図１に示した販売システムＳには、複数台のユーザ端末１００－１，１００－２が含まれるが、例えば、複数台のストア端末１０が含まれてもよい。また、複数台のユーザ端末１００－１，１００－２をユーザ端末１００と記載する場合がある。

ユーザ端末１００は、ユーザによって利用される情報処理装置である。ユーザ端末１００は、例えば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等により実現される。また、図１に示す例では、ユーザ端末１００－１は、災害に伴う被災地のユーザＵ１が利用し、ユーザ端末１００－２は、被災地以外のユーザＵ２が利用する場合を示す。

ストア端末１０は、販売元であるストアの管理者Ｍ１によって利用される情報処理装置である。例えば、ストアの管理者Ｍ１は、ストア端末１０を用いて、電子商取引サービスにおいて販売する商品を追加する。また、ストア端末１０は、例えば、スマートフォンや、タブレット型端末や、ノート型ＰＣや、デスクトップＰＣや、携帯電話機や、ＰＤＡ等により実現される。図１は、ストア端末１０がデスクトップＰＣである場合を示す。

販売制御装置１は、ショッピングサービスやオークションサービス等の電子商取引サービスを提供するとともに、ストアから登録された商品の販売制御を行う。また、販売制御装置１は、災害の発生を検出する。ここで、災害とは、暴風、豪雨、豪雪、洪水、高潮、地震、津波、噴火等の自然災害や、車両、船舶、列車、飛行機等の交通事故のような人為的災害等を含む。また販売制御装置１は、災害を検出した場合に、電子商取引サービスにおいて販売される商品のうち、災害に応じた支援物資または支援サービスとなる対象商品を災害に伴う被災地のユーザＵ１に対して優先的に販売する制御を行う。

ここで、従来の販売制御装置について説明する。従来の販売制御装置は、被災地のユーザに対して支援物資を適切に販売できないおそれがあった。例えば、被災地以外のユーザが支援物資を大量に購入する等した場合、十分な量の支援物資を被災地のユーザへ販売できないおそれがあった。また、支援物資を大量に確保した被災地以外のユーザが高額で転売等した場合、被災地のユーザが適切な価格で支援物資を購入できないおそれがあった。

そこで、実施形態に係る販売制御装置１は、販売制御処理を実行し、災害発生時には、支援物資となる対象商品を被災地用として販売する制御を行う。図１を用いて、販売制御処理について具体的に説明する。なお、図１では、支援物資として「水」が設定されていることとする。

図１に示すように、販売制御処理では、まず、ストアの管理者Ａから商品の登録を受け付ける（ステップＳ１）。例えば、ストアの管理者Ａは、商品を登録する際、災害発生時に、支援物資となる対象商品としてかかる商品を販売してもよい旨を通知する。

つづいて、販売制御装置１は、災害が発生していない通常時には、ユーザＵ１およびユーザＵ２に対してショッピングにおける商品の検索結果や商品の詳細ページ等をユーザ端末１００－１，１００－２に表示させる。

そして、販売制御装置１は、災害の発生を検出すると（ステップＳ２）、被災地のユーザＵ１に対して支援物資を優先的に販売する制御モードに切り替える（ステップＳ３）。なお、かかる制御モードについては、図３で後述する。

つづいて、販売制御装置１は、ユーザ端末１００－１から送信される被災地のユーザＵ１から商品を検索する検索クエリ「水」を受け付ける（ステップＳ４－１）とともに、ユーザ端末１００－２から送信される被災地以外のユーザＵ２から検索クエリ「水」を受け付ける（ステップＳ４－２）。

そして、販売制御装置１は、ユーザ端末１００－１へ検索クエリに対する結果を送信する（ステップＳ５－１）。具体的には、販売制御装置１は、被災地のユーザＵ１が利用するユーザ端末１００－１に対しては、検索クエリ「水」に対応する検索結果を送信し、ユーザＵ１が対象商品を購入可能な画面を表示させる。

また、販売制御装置１は、ユーザ端末１００－２へ検索クエリに対する結果を送信する（ステップＳ５－２）。具体的には、販売制御装置１は、被災地以外のユーザＵ２が利用するユーザ端末１００－２に対しては、検索クエリ「水」に対する結果として、対象商品である「水」が購入できない旨を通知する。

つまり、実施形態に係る販売制御装置１は、支援物資となる対象商品を被災地のユーザＵ１が購入可能とする一方で、被災地以外のユーザＵ２が対象商品を購入できないようにする。これにより、被災地以外のユーザＵ２が支援物資となる対象商品を大量に購入することができなくなるとともに、高額での転売もできなくなる。従って、実施形態に係る販売制御装置１によれば、被災地のユーザＵ１に対して支援物資や支援サービスを適切に販売することができる。

なお、図１に示す例では、被災地以外のユーザＵ２が対象商品すべてを購入できないようにしたが、例えば、水の全在庫のうち、一定の割合（例えば、５０％）を被災地用として確保し、残りの在庫について被災地以外用として販売してもよい。また、被災地用して確保した対象商品を、例えば、被災地以外のユーザＵ２が被災地へ寄付するために購入するのであれば販売してもよい。

また、図１では、対象商品である「水」を被災地以外のユーザＵ２が購入できない旨を通知したが、例えば、購入できない旨を通知しなくてもよい。例えば、検索結果の画面に被災地以外のユーザＵ２０が購入可能な商品（例えば、対象商品として設定されていない「水」）のみを表示することとしてもよい。つまり、ユーザＵ２０にとっては、対象商品以外の商品を普段通り購入可能にすることで、被災地以外のユーザＵ２０の利便性が低下することを防止できる。

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

（２－１．通信部２）
通信部２は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。そして、通信部２は、ネットワークＮと有線または無線で接続され、例えば販売システムＳに含まれるユーザ端末１００やストア端末１０等の間で情報の送受信を行う。

（２－２．記憶部４）
記憶部４は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図２に示すように、実施形態に係る記憶部４は、モード情報４１と、商品情報４２と、ストア情報４３と、支援物資情報４４と、ユーザ情報４５とを記憶する。

（２－２－１．モード情報４１）
モード情報４１は、後述する販売制御部３４における制御モードを示す情報である。図３は、モード情報４１を示す図である。図３に示すように、モード情報４１には、通常時モードｓｔ１および非常時モードｓｔ２の２つの制御モードが存在する。

通常時モードｓｔ１は、全てのユーザＵ１，Ｕ２に対して商品（対象商品および対象商品以外）を平等に販売する制御モードである。非常時モードｓｔ２は、被災地のユーザＵ１に対して支援物資となる対象商品を優先的に販売する制御モードである。

後述する販売制御部３４は、これら２つの制御モードのうち、通常時は、通常時モードｓｔ１を読み出して実行するとともに、後述する検出部３３によって災害の発生が検出された場合には、通常時モードｓｔ１から非常時モードｓｔ２へ切り替える。

（２－２－２．商品情報４２）
商品情報４２は、ストアによって登録された商品に関する情報である。図４は、商品情報４２を示す図である。図４に示すように、商品情報４２には、「商品ＩＤ」、「商品名」、「カテゴリ」、「ストア」、「価格（２Ｌ×６本）」、「在庫数」、「支援物資フラグ」といった項目が含まれる。

「商品ＩＤ」は、商品を識別するための識別情報である。「商品名」は、商品の登録名を示す名称に関する情報である。「カテゴリ」は、商品の種別であり、具体的な名称等を示す情報である。「ストア」は、商品を販売しているストアの名称を示す情報である。「価格（２Ｌ×６本）」は、商品の売価（図４では、２Ｌの水６本の売価）を示す。「在庫数」は、商品の在庫数を示す。「支援物資フラグ」は、商品が支援物資となる対象商品であるか否かを示す情報である。

図４に示す例において、商品ＩＤ「ＧＤ１」は、商品名が「天然水Ａ」であり、商品の種別が「食料」であり、ストアの名称が「ストアＡ」であり、１ケース（２Ｌ×６本）あたりの価格が「４８０」円であり、在庫数が「１００００」ケースであることを示している。また、商品ＩＤ「ＧＤ１」は、支援物資フラグが「１」であることから、災害発生時に、支援物資となる対象商品であることを示す。

また、商品ＩＤ「ＧＤ２」は、商品名が「天然水Ｂ」であり、商品の種別が「食料」であり、ストアの名称が「ストアＢ」であり、１ケース（２Ｌ×６本）あたりの価格が「５４０」円であり、在庫数が「５０００」ケースであることを示している。また、商品ＩＤ「ＧＤ２」は、支援物資フラグが「０」であることから、災害発生時に、支援物資とならない商品であることを示す。

つまり、災害発生時において、「天然水Ａ」は、被災地のユーザＵ１が購入可能で、被災地以外のユーザＵ２が購入できない商品であり、「天然水Ｂ」は、被災地のユーザＵ１および被災地以外のユーザＵ２双方が購入可能な商品であることを示す。

なお、商品情報４２は、上記に限らず、目的に応じて種々の情報が含まれてもよい。例えば、商品情報４２には、商品が追加された日時や商品が作成された日時に関する情報が含まれてもよい。また、商品情報４２は、商品の画像や粗利、送料の有無、送料、商品を検索する際に使用されるキーワード、商品の種別等といった各種の情報が含まれてもよい。例えば、商品情報４２には、「カテゴリ」として、階層的なカテゴリの情報が含まれてもよい。例えば、商品情報４２は、商品「天然水Ａ」の「カテゴリ」として、第１階層「食料」、第２階層「飲料」、第３階層「水」、第４階層「ミネラルウォータ」等のように階層的なカテゴリの情報が含まれてもよい。

（２－２－３．ストア情報４３）
ストア情報４３は、商品の販売元であるストアに関する情報である。図５は、ストア情報４３を示す図である。図５に示すように、ストア情報４３には、「ストアＩＤ」、「ストア」、「店舗住所」、「商品数」、「支援物資登録数」といった項目を含む。なお、図５に示すストア情報４３は一例であって、すべての項目を含む必要はない。

「ストアＩＤ」は、ストアを識別するための識別情報である。「ストア」は、商品を販売しているストアの名称を示す情報である。「店舗住所」は、ストアの実店舗の住所を示す情報である。「商品数」は、ストアが扱う商品の種類の数であり、ショッピングサービスに登録している商品の種類の数を示す情報である。「支援物資登録数」は、「商品数」のうち、支援物資となる対象商品として登録されている商品数を示す情報である。

図５に示す例において、ストアＩＤ「ＳＤ１」は、ストアの名称が「ストアＡ」であり、実際の店舗の住所が「ＡＡ」であり、取り扱っている商品数が「５０」種類であり、そのうち支援物資として「１５」種類の商品が登録されていることを示す。

なお、ストア情報４３は、上記に限らず、目的に応じて種々の情報が含まれてもよい。例えば、実店舗を持たないストアにおいて、ストア情報４３には、「店舗住所」として、商品の保管場所の住所が含まれてもよい。

（２－２－４．支援物資情報４４）
支援物資情報４４は、支援物資となる対象商品に関する情報である。図６は、支援物資情報４４を示す図である。図６に示すように、支援物資情報４４は、「物資ＩＤ」、「カテゴリ」、「全在庫数」、「支援物資登録数」といった項目を含む。

「物資ＩＤ」は、支援物資となる対象商品を識別するための識別情報である。「カテゴリ」は、対象商品の種別を示す情報である。「全在庫数」は、全ストアにおける商品の全ての在庫数を示す情報である。「支援物資登録数」は、「全在庫数」のうち支援物資となる対象商品として登録された在庫数を示す情報である。

図６に示す例において、物資ＩＤ「１」は、対象商品の種別が「水」であり、「水」に対応する商品の全在庫数が「２００００」個であり、そのうち対象商品として「１００００」個が登録されていることを示す。

（２－２－５．ユーザ情報４５）
ユーザ情報４５は、例えば、ショッピングサービスに登録されたユーザＵ１，Ｕ２に関する情報である。図７は、ユーザ情報４５を示す図である。図７に示すように、ユーザ情報４５には、「ユーザＩＤ」、「性別」、「年齢」、「住所」、「登録配送先」といった項目が含まれる。

「ユーザＩＤ」は、ユーザＵ１，Ｕ２を識別するための識別情報である。「性別」は、ユーザＵ１，Ｕ２の性別を示す情報である。「年齢」は、ユーザＵ１，Ｕ２の年齢を示す情報である。「住所」は、ユーザＵ１，Ｕ２の住所を示す情報である。「登録配送先」は、ユーザＵ１，Ｕ２が商品を購入した場合の配送先の候補を示す情報である。

図７に示す例において、ユーザＩＤ「Ａ」は、性別が「男性」であり、年齢が「３０代」であり、住所が「ＦＦ」であり、商品の配送先の候補として「ＦＦ」の住所が登録されていることを示す。

また、ユーザＩＤ「Ｂ」は、性別が「女性」であり、年齢が「５０代」であり、住所が「ＨＨ」であり、商品の配送先の候補として「ＧＧ」の住所が登録されていることを示す。つまり、「住所」と「登録配送先」との住所が異なっていることを示す。

図２の説明に戻って、制御部３は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、販売制御装置１内部の記憶装置に記憶されている各種プログラム（情報提供プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部３は、コントローラであり、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現される。

図２に示すように、制御部３は、クエリ受付部３１と、購入受付部３２と、検出部３３と、販売制御部３４とを有し、以下に説明する販売制御処理の機能や作用を実現または実行する。

（２－３．クエリ受付部３１）
クエリ受付部３１は、ユーザＵ１，Ｕ２によって指定され、ユーザ端末１００から送信される各種クエリを受け付ける。例えば、クエリ受付部３１は、ユーザ端末１００からショッピングサービスに登録された商品を検索する検索クエリを受け付ける。

また、クエリ受付部３１は、災害時において、対象商品を検索する検索クエリを受け付ける。また、クエリ受付部３１は、検索クエリに応じた検索結果がユーザＵ１，Ｕ２へ提供された後、例えば、商品の詳細ページを要求するクエリを受け付ける。

（２－４．購入受付部３２）
購入受付部３２は、商品を購入する要求である購入要求をユーザＵ１，Ｕ２（購入ユーザの一例）から受け付ける。購入要求には、例えば、選択した商品を示す情報や、商品の購入数、支払方法、商品の配送先を示す配送情報等が含まれる。

（２－５．検出部３３）
検出部３３は、災害の発生を検出する。例えば、検出部３３は、災害として、暴風、豪雨、豪雪、洪水、高潮、地震、津波、噴火等の自然災害や、車両、船舶、列車、飛行機等の交通事故のような人為的災害等を検出する。

具体的には、検出部３３は、気象庁等の機関が発する緊急信号（例えば、緊急地震速報を示す信号）を受信することで、災害の発生を検出する。また、検出部３３は、例えば、ユーザＵ１，Ｕ２が有するユーザ端末１００に搭載されたジャイロセンサ等の値に基づいてユーザＵ１，Ｕ２の周辺で発生する揺れ（地震や、噴火に伴う揺れ等）に基づいて災害の発生を検出する。あるいは、ユーザ端末１００から災害発生の通知を受け付けることで災害の発生を検出してもよい。

また、検出部３３は、ユーザＵ１，Ｕ２の入力操作によって災害の発生を受け付けることで検出してもよい。また、検出部３３は、例えば台風のように移動する場合、かかる台風の予測進路を示す情報に基づいて災害の発生および被災地の特定を行ってもよい。

また、検出部３３は、災害の規模を検出する。例えば、検出部３３は、気象庁から送信される災害情報に基づいて地震の震度や、台風の最大瞬間風速、降水量、波の高さ等といった情報を災害の規模として検出する。

（２－６．販売制御部３４）
販売制御部３４は、商品の販売に関する制御を行う。例えば、販売制御部３４は、災害が発生していない通常時において、ユーザＵ１，Ｕ２に検索クエリに対応する商品を抽出し、検索結果としてユーザ端末１００へ送信する。

また、販売制御部３４は、検出部３３によって災害の発生が検出された場合に、電子商取引サービスにおいて販売される商品のうち、当該災害に応じた支援物資となる対象商品を災害に伴う被災地用として販売する制御を行う。

例えば、販売制御部３４は、対象商品の全在庫のうち、被災地用として購入可能な在庫の割合を被災地以外用として購入可能な割合よりも多くする。具体的には、販売制御部３４は、支援物資情報４４の「支援物資登録数」のうち、例えば５０％以上を被災地用として確保する。つまり、販売制御部３４は、残りの５０％未満を被災地以外のユーザＵ２に対して販売する。

なお、確保する割合は、災害の規模に応じて変更してもよい。具体的には、販売制御部３４は、検出部３３によって検出された災害の規模が大きいほど、被災地用として購入可能な割合を多くする。例えば、販売制御部３４は、地震の震度が「５」の場合、「支援物資登録数」のうち、５０％を被災地用として確保し、震度が「６」の場合、６０％を確保し、震度が「７」の場合、７０％を確保するように制御する。

また、販売制御部３４は、対象商品を扱うストアのうち、対象商品の配送元が被災地に近いストアが扱う対象商品を被災地用として優先的に販売する。具体的には、販売制御部３４は、被災地に近いストアの在庫を優先的に確保する。

また、販売制御部３４は、対象商品を扱うストアのうち、対象商品の被災地への納期が早いストアが扱う対象商品を被災地用として優先的に販売する。具体的には、販売制御部３４は、ストアと契約しているもしくは頻繁に使用する宅配業者の配送状況を示す情報に基づいて対象商品の被災地までの納期を算出する。そして、販売制御部３４は、算出した納期が早いストアが扱う対象商品の在庫を優先して確保する。このとき、販売制御部３４は、「被災地への納期を早めます」といった特記事項をユーザＵ１，Ｕ２に対して提示する。

また、販売制御部３４は、クエリ受付部３１が受け付けた検索クエリの送信元が被災地以外のユーザＵ２であった場合、かかるユーザＵ２に対して検索クエリに応じた検索結果の出力を禁止する。なお、販売制御部３４は、検索結果の出力を禁止する際、ユーザＵ２に対して出力を禁止した旨を示す情報を通知するが、かかる点については図１０で後述する。また、検索クエリの送信元は、例えば、検索クエリのアクセス元ＩＰ（Internet Protocol）アドレスに関する情報を取得することで特定可能である。

また、販売制御部３４は、購入受付部３２が受け付けた購入要求の配送情報に基づき、配送先が被災地以外の場所であった場合、購入ユーザ（例えば、ユーザＵ１，Ｕ２）による対象商品の購入を禁止する。かかる場合、販売制御部３４は、購入ユーザに対して、「この商品は被災地にしか配送できません」といった注意喚起をすることが好ましい。

また、販売制御部３４は、各情報に基づいて優先する対象商品を絞ってもよい。例えば、販売制御部３４は、気温や気候等の気象情報に基づいて優先する対象商品を選択してもよい。具体的には、販売制御部３４は、気温が低下した場合、冬用の衣類や毛布等の確保量を多くしてもよい。

また、販売制御部３４は、避難所から送信される情報に基づいて対象商品を抽出してもよい。例えば、販売制御部３４は、避難所に食料が過度に到着した場合、食料の確保量を減らし、代わりに他の種別の支援物資を多く確保することとしてもよい。

また、販売制御部３４は、避難所から新規の種別の支援物資の要求を受け付けた場合、支援物資情報４４に新規の種別の支援物資を登録するとともに、商品情報４２から新規の種別の支援物資の在庫を確保する。

なお、販売制御部３４は、被災地用に在庫を多く確保する場合に限らず、例えば、被災地用に確保した対象商品については販売の価格を下げる（例えば、１０％オフ等）制御を行ってもよい。つまり、販売制御部３４は、被災地用としての対象商品の価格を被災地以外用としての対象商品の価格よりも安く販売する。また、販売制御部３４は、例えば、対象商品の被災地への配送を被災地以外の配送よりも優先させてもよい。

また、販売制御部３４は、災害が発生してから経過する時間で優先する対象商品の種別を切り替えてもよい。かかる点について、図８を用いて説明する。

図８は、販売制御部３４の処理内容を示す図である。図８では、時刻ｔ１において、検出部３３が災害の発生を検出したこととする。販売制御部３４は、災害が発生してから第１の期間（以下、第１期間）が経過するまでは第１の対象商品を優先して販売し、第１の期間経過後の第２の期間（以下、第２期間）が経過するまでは第１の対象商品とは種別が異なる第２の対象商品を優先して販売する。

具体的には、販売制御部３４は、時刻ｔ１から時刻ｔ２の期間である第１期間では、対象商品「水」の在庫を確保する割合を比較的高くする。そして、販売制御部３４は、時刻ｔ２から時刻ｔ３の期間である第２期間では、対象商品「毛布」の在庫を確保する割合を比較的高くする。

換言すれば、販売制御部３４は、第１期間では、対象商品「毛布」の在庫を確保する割合を比較的低くし、第２期間では、対象商品「水」の在庫を確保する割合を比較的低くする。なお、第１期間および第２期間は、過去の災害に関する情報に基づいて設定することができる。

また、販売制御部３４は、第１期間および第２期間の２つの期間に区切って対象商品を切り替えたが、区切る期間は、３つ以上でもよい。例えば、販売制御部３４は、時刻ｔ３以降の期間については、避難所から受け付けた対象商品の種別を割り当ててもよい。

次に、図９および図１０を用いて、販売制御部３４が生成する検索結果を示す画面例について説明する。図９および図１０は、検索結果を示す画面例を示す図である。図９および図１０では、検索クエリ「水」が指定された場合の画面例を示す。また、図９では、被災地のユーザＵ１のユーザ端末１００に表示される検索結果画面ｄ１を示し、図１０では、被災地以外のユーザＵ２のユーザ端末１００に表示される検索結果画面ｄ２を示す。また、図９および図１０では、商品「天然水Ａ」が対象商品であることとする。

まず、図９の検索結果画面ｄ１について説明する。図９に示すように、販売制御部３４は、被災地のユーザＵ１から検索クエリ「水」が受け付けられると、「水」に対応する商品の項目Ｒ１，Ｒ２を一覧表示する。具体的には、販売制御部３４は、支援物資となる対象商品の項目Ｒ１を対象商品ではない商品の項目Ｒ２よりも表示順位を先にする。より好ましくは、販売制御部３４は、対象商品の項目Ｒ１の表示順位を１位にする。

そして、販売制御部３４は、「天然水Ａ」が対象商品であることを示す強調表示Ｒ１ａを項目Ｒ１の領域内に表示する。なお、販売制御部３４は、対象商品ではない「天然水Ｂ」も検索結果画面ｄ１に表示したが、表示しなくてもよい。つまり、販売制御部３４は、対象商品のみを検索結果画面ｄ１に表示してもよい。

次に、図１０の検索結果画面ｄ２について説明する。図１０に示すように、販売制御部３４は、被災地以外のユーザＵ２から検索クエリ「水」が受け付けられると、「水」に対応する商品の項目Ｒ１，Ｒ２を一覧表示する。このとき、販売制御部３４は、対象商品である「天然水Ａ」の項目Ｒ１の領域内に購入できない旨を示す警告表示Ｒ１ｂを表示する。

なお、図１０では、対象商品である「天然水Ａ」の項目Ｒ１を検索結果画面ｄ２に表示したが、項目Ｒ１を表示しなくてもよい。つまり、販売制御部３４は、「天然水Ｂ」の項目Ｒ２の表示順位を１位にする。かかる場合、販売制御部３４は、「支援物資対象商品については検索結果画面から除外しています」といった旨の表示を行うことが好ましい。

また、図１０では、販売制御部３４は、対象商品である「天然水Ａ」を被災地以外のユーザＵ２が購入できないように検索結果を出力したが、これに限定されない。例えば、販売制御部３４は、被災地以外のユーザＵ２が「天然水Ａ」を被災地用として購入するのであれば検索結果を出力してもよい。つまり、販売制御部３４は、被災地以外のユーザＵ２に対して検索クエリに応じた検索結果として、被災地以外用として購入することを禁止するための出力を行ってもよい。

また、販売制御部３４は、対象商品を被災地以外のユーザＵ２が購入することを禁止し、被災地のユーザＵ１のみが購入できるように対象商品の販売を制御してもよい。すなわち、販売制御部３４は、被災地用としての対象商品を被災地のユーザＵ１のみへ販売する。

なお、販売制御部３４は、すべての商品のうち、事前登録された対象商品に限って被災地用として販売することとしたが、必ずしも事前登録される必要はなく、例えば、各ストアから強制的に対象商品を抽出することとしてもよい。

〔３．処理手順〕
次に、図１１および図１２を用いて、実施形態に係る販売制御装置１が実行する処理の手順について説明する。図９は、実施形態に係る販売制御装置１が実行する販売制御処理の手順を示すフローチャートである。図１０は、実施形態に係る販売制御装置１が実行する購入処理の手順を示すフローチャートである。

まず、販売制御処理の手順について説明する。図９に示すように、まず、検出部３３は、災害の発生を検出する（ステップＳ１０１）。つづいて、販売制御部３４は、検出部３３によって災害の発生が検出された場合に、電子商取引サービスにおいて販売される商品のうち、災害に応じた支援物資となる対象商品を災害に伴う被災地のユーザＵ１に対して優先的に販売し（ステップＳ１０２）、処理を終了する。

次に、購入処理の手順について説明する。図１０に示すように、クエリ受付部３１は、対象商品の検索クエリを受け付ける（ステップＳ２０１）。つづいて、販売制御部３４は、検索クエリのアクセス元ＩＰアドレスが被災地であるか否かを判定する（ステップＳ２０２）。

販売制御部３４は、ユーザＵ１，Ｕ２の検索クエリのアクセス元ＩＰアドレスが被災地である場合（ステップＳ２０２，Ｙｅｓ）、ユーザＵ１，Ｕ２の登録住所が被災地であるか否かを判定する（ステップＳ２０３）。

つづいて、販売制御部３４は、ユーザＵ１，Ｕ２の登録住所が被災地である場合（ステップＳ２０３，Ｙｅｓ）、検索クエリに対する検索結果を出力する（ステップＳ２０４）。

つづいて、購入受付部３２は、対象商品の購入要求を受け付ける（ステップＳ２０５）。つづいて、販売制御部３４は、購入要求に含まれる配送情報に基づいて入力された配送先が被災地であるか否かを判定する（ステップＳ２０６）。

販売制御部３４は、入力された配送先が被災地であった場合（ステップＳ２０６，Ｙｅｓ）、対象商品の購入確定処理を行い（ステップＳ２０７）、処理を終了する。なお、購入確定処理とは、対象商品の代金支払い処理や配送手続き処理等を含む購入が完了するまでの処理である。

一方、ステップＳ２０６において、販売制御部３４は、入力された配送先が被災地でない場合（ステップＳ２０６，Ｎｏ）、処理を終了する、すなわち、対象商品の購入処理を行わない。また、ステップＳ２０３において、販売制御部３４は、ユーザＵ１，Ｕ２の登録住所が被災地でない場合（ステップＳ２０３，Ｎｏ）、ユーザＵ１，Ｕ２の登録配送先が被災地であるか否かを判定する（ステップＳ２０８）。

販売制御部３４は、登録配送先が被災地であった場合（ステップＳ２０８，Ｙｅｓ）、処理をステップＳ２０４へ移行する。また、ステップＳ２０８において、販売制御部３４は、登録配送先が被災地でなかった場合（ステップＳ２０８，Ｎｏ）、検索クエリに対する検索結果の出力を禁止（ステップＳ２０９）し、処理を終了する。

また、ステップＳ２０２において、販売制御部３４は、アクセス元ＩＰアドレスが被災地でない場合（ステップＳ２０２，Ｎｏ）、処理をステップＳ２０９へ移行する。

〔４．効果〕
上述してきたように、実施形態に係る販売制御装置１は、販売制御部３４を備える。販売制御部３４は、災害が発生した場合に、電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる対象商品を当該災害に伴う被災地用として販売する制御を行う。

これにより、被災地以外のユーザＵ２が支援物資となる対象商品を大量に購入することができなくなるとともに、高額での転売もできなくなる。従って、実施形態に係る販売制御装置１によれば、被災地のユーザＵ１に対して支援物資を適切に販売することができる。

また、実施形態に係る販売制御装置１において、販売制御部３４は、対象商品の全在庫のうち、被災地用として購入可能な在庫の割合を被災地以外用として購入可能な在庫の割合よりも多くする。

これにより、被災地のユーザＵ１に対象商品を確実に割り当てることができるとともに、被災地以外のユーザＵ２による対象商品の大量買い占めを防ぐことができる。

また、実施形態に係る販売制御装置１において、検出部３３は、災害の規模をさらに検出する。販売制御部３４は、検出部３３によって検出された災害の規模が大きいほど、被災地用として購入可能な在庫の割合を多くする。

これにより、災害の規模が大きく、被災地での支援物資が大量に必要になった場合であっても、支援物資を被災地へ確実に供給することができる。

また、実施形態に係る販売制御装置１において、販売制御部３４は、対象商品を扱うストアのうち、対象商品の配送元が被災地に近いストアが扱う対象商品を被災地用として優先的に販売する。

これにより、対象商品の輸送に費やす配送時間を削減することができるため、より早く被災地へ支援物資を供給することができる。

また、実施形態に係る販売制御装置１において、販売制御部３４は、対象商品を扱うストアのうち、当該対象商品の被災地への納期が早いストアが扱う対象商品を被災地用として優先的に販売する。

これにより、対象商品の納期を可能な限り短くできるため、例えば賞味期限が短い食料等であっても被災地へ供給することができる。

また、実施形態に係る販売制御装置１は、クエリ受付部３１をさらに備える。クエリ受付部３１は、対象商品を検索する検索クエリを受け付ける。販売制御部３４は、クエリ受付部３１が受け付けた検索クエリの送信元が被災地以外のユーザＵ２であった場合、当該ユーザＵ２に対して検索クエリに応じた検索結果として、被災地以外用として購入することを禁止するための出力を行う。

これにより、被災地のユーザＵ１と被災地以外のユーザＵ２とを確実に選別することができる。

また、実施形態に係る販売制御装置１は、購入受付部３２をさらに備える。購入受付部３２は、対象商品の配送先を示す配送情報を含む購入要求を購入ユーザから受け付ける。販売制御部３４は、購入受付部３２が受け付けた購入要求の配送情報に基づき、配送先が被災地以外の場所であった場合、購入ユーザによる対象商品の購入を禁止する。

これにより、例えば被災地以外のユーザＵ２がＩＰアドレスを偽装したり、登録住所を偽住所として被災地に設定した場合であっても、被災地以外のユーザＵ２に誤って対象商品が購入されてしまうことを防止できる。

また、実施形態に係る販売制御装置１において、対象商品は、複数の種別の商品を含む。販売制御部３４は、災害が発生してから第１の期間が経過するまでは第１の対象商品を優先して販売し、第１の期間経過後の第２の期間が経過するまでは第１の対象商品とは種別が異なる第２の対象商品を優先して販売する。

これにより、災害発生後において、真に必要な対象商品の在庫の確保量をリアルタイムにコントロールできるため、被災地のユーザＵ１の満足度を向上させることができる。

また、実施形態に係る販売制御装置１において、販売制御部３４は、被災地用としての対象商品を被災地のユーザＵ１のみへ販売する。

これにより、被災地のユーザＵ１のみが支援物資となる対象商品を購入できるため、被災地に支援物資が届かないという事態を防ぐことができる。

また、実施形態に係る販売制御装置１において、販売制御部３４は、被災地用としての対象商品の価格を被災地以外用としての対象商品の価格よりも安く販売する。

これにより、被災地のユーザＵ１は、対象商品を安く購入できるため、被災地のユーザＵ１の経済状況を悪化させることを防ぐことができる。

〔５．プログラム〕
また、上述してきた実施形態にかかる販売制御装置１は、例えば図１３に示すような構成のコンピュータ１０００によって実現される。図１３は、実施形態に係る販売制御装置１の機能を実現するコンピュータ１０００の一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

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

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

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

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

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

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

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

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

また、上述してきた実施形態に記載した各処理は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上記してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、検出部３３は、検出手段や検出回路に読み替えることができる。

１ 販売制御装置
２ 通信部
３ 制御部
４ 記憶部
１０ ストア端末
３１ クエリ受付部
３２ 購入受付部
３３ 検出部
３４ 販売制御部
４１ モード情報
４２ 商品情報
４３ ストア情報
４４ 支援物資情報
４５ ユーザ情報
１００ ユーザ端末
Ｕ１，Ｕ２ ユーザ

Claims (7)

1. 電子商取引サービスにおいて販売される商品またはサービスに関する商品情報であって、支援物資または支援サービスとなる対象商品であるか否かの情報が紐付いた商品情報を記憶する記憶部と、
   災害が発生した場合に、前記記憶部に記憶された前記商品情報に基づいて、前記電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる前記対象商品について、当該災害に伴う被災地のユーザから検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、前記対象商品を購入可能な検索結果画面を表示し、前記被災地以外のユーザから検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、検索結果画面に前記被災地以外のユーザが前記対象商品を購入することを禁止することを示す表示を行う販売制御部と、
   を備え、
   前記販売制御部は、
   前記被災地のユーザに対する検索結果に前記対象商品および前記対象商品ではない前記商品またはサービスが含まれる場合において検索結果画面を表示する場合に、前記対象商品となる前記商品またはサービスを前記対象商品ではない前記商品またはサービスよりも表示順位を先にすること
   を特徴とする販売制御装置。
2. 前記対象商品の配送先を示す配送情報を含む購入要求を購入ユーザから受け付ける購入受付部をさらに備え、
   前記販売制御部は、
   前記購入受付部が受け付けた前記購入要求の配送情報に基づき、前記配送先が被災地以外の場所であった場合、前記購入ユーザによる前記対象商品の購入を禁止すること
   を特徴とする請求項１に記載の販売制御装置。
3. 前記販売制御部は、
   前記対象商品を前記被災地のユーザのみへ販売すること
   を特徴とする請求項１または２に記載の販売制御装置。
4. 前記販売制御部は、
   前記被災地のユーザに対する前記対象商品の販売の価格を被災地以外のユーザに対する前記対象商品の販売の価格よりも安くすること
   を特徴とする請求項１～３のいずれか１つに記載の販売制御装置。
5. 前記対象商品は、複数の種別の前記商品を含み、
   前記販売制御部は、
   前記災害が発生してからの期間に応じて、前記対象商品の種別毎に、前記被災地のユーザが購入可能な在庫数の割合を増減すること
   を特徴とする請求項１～４のいずれか１つに記載の販売制御装置。
6. 販売制御装置が実行する販売制御方法であって、
   電子商取引サービスにおいて販売される商品またはサービスに関する商品情報であって、支援物資または支援サービスとなる対象商品であるか否かの情報が紐付いた商品情報を記憶部に記憶する記憶工程と、
   災害が発生した場合に、前記記憶部に記憶された前記商品情報に基づいて、前記電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる前記対象商品について、当該災害に伴う被災地のユーザから検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、前記対象商品を購入可能な検索結果画面を表示し、前記被災地以外のユーザから検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、検索結果画面に前記被災地以外のユーザが前記対象商品を購入することを禁止することを示す表示を行う販売制御工程と、
   を含み、
   前記販売制御工程は、
   前記被災地のユーザに対する検索結果に前記対象商品および前記対象商品ではない前記商品またはサービスが含まれる場合において検索結果画面を表示する場合に、前記対象商品となる前記商品またはサービスを前記対象商品ではない前記商品またはサービスよりも表示順位を先にすること
   を特徴とする販売制御方法。
7. 電子商取引サービスにおいて販売される商品またはサービスに関する商品情報であって、支援物資または支援サービスとなる対象商品であるか否かの情報が紐付いた商品情報を記憶部に記憶する記憶手順と、
   災害が発生した場合に、前記記憶部に記憶された前記商品情報に基づいて、前記電子商取引サービスにおいて販売される商品またはサービスのうち、当該災害に応じた支援物資または支援サービスとなる前記対象商品について、当該災害に伴う被災地のユーザから検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、前記対象商品を購入可能な検索結果画面を表示し、前記被災地以外のユーザから検索クエリを受け付け、検索結果に前記対象商品が含まれる場合には、検索結果画面に前記被災地以外のユーザが前記対象商品を購入することを禁止することを示す表示を行う販売制御手順と、
   をコンピュータに実行させ、
   前記販売制御手順は、
   前記被災地のユーザに対する検索結果に前記対象商品および前記対象商品ではない前記商品またはサービスが含まれる場合において検索結果画面を表示する場合に、前記対象商品となる前記商品またはサービスを前記対象商品ではない前記商品またはサービスよりも表示順位を先にすること
   を特徴とする販売制御プログラム。

Images