JP7720385B2 - フォローアップ制御装置、フォローアップ制御方法、及びフォローアップ制御プログラム - Google Patents

Description

本発明は、購入された商品について所定の手続きを行う方法に関する。

従来、オンラインで商品の注文を可能とするウェブサイトが知られている。こうしたウェブサイトでは、一般的に、購入者は販売者と対面せずに商品を購入することができる。その一方で、販売される商品の中には、商品の購入に際して顧客が販売者等から説明を受けることが必要な商品も存在する。例えば、医薬品を購入する場合、顧客は、医療機関による診察を受けて処方を受ける必要があったり、薬剤師による服薬指導を受ける必要があったりする場合がある。また例えば、一部の化粧品を購入する場合、顧客は医師又はその他專門家等のカウンセリングを受ける必要がある場合がある。こうした購入の条件がある商品に対応したシステムも知られている。例えば特許文献１には、処方箋が必要な医療用医薬品について処方箋の情報を含んだ購入依頼と、処方箋が不要な医療用医薬品について処方箋の情報を含まない購入依頼と、のそれぞれを受け付け可能とし、購入依頼に基づいて、医療用医薬品を販売するための販売情報を生成することが開示されている。

特開２０２０－１３５２７８号公報

しかしながら、商品の購入後に購入者へのフォローアップが必要となる場合がある。例えば医薬品が購入された場合、その医薬品の服用に関して購入者に対する経過観察が実施される場合がある。従来の技術では、たとえ商品の購入までの手続きについては対応することができたとしても、購入後の対応については不十分であった。また、フォローアップの時期やその時期に購入者へ確認する事項は、商品によって異なる場合がある。そうした事情が、フォローアップのための作業の負担となっていた。

本発明は以上の点に鑑みてなされたものであり、その課題の一例は、商品の購入者に対するフォローアップの負担を解消することを可能とするフォローアップ制御装置、フォローアップ制御方法、及びフォローアップ制御プログラムを提供することにある。

（適用例１）適用例１は、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段と、を備え、前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品が前記購入者に向けて発送された発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御装置である。

本適用例によれば、購入された商品についてのフォローアップのための質問への回答を促す促し情報が送信される。促し情報の送信の時期は、商品期間長情報に基づいて特定される。商品期間長情報からは、複数の商品のそれぞれについて、その商品の発送日からフォローアップの時期までの期間の長さを特定可能である。そのため、商品に応じてその期間の長さが異なっていても、購入された商品に対応する長さの期間の経過後に、促し情報を送信することができる。促し情報の送信後、その商品の購入者が利用する購入者端末装置へ、質問情報が送信される。送信される質問情報は、商品質問情報に基づいて特定される。商品質問情報からは、複数の商品それぞれについて、その商品についての質問情報を特定可能である。そのため、商品に応じて質問が異なっていても、購入された商品に対する質問を購入者に提示することができる。従って、商品の購入者に対するフォローアップの負担を解消することができる。

（適用例２）適用例２は、前記送信された質問情報により示される前記質問に対する前記回答を示す回答情報を、前記購入者端末装置から受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者端末装置へ送信する結果情報送信手段と、を更に備えることを特徴とするフォローアップ制御装置である。

本適用例によれば、フォローアップの結果が、商品の購入者に提示される。このフォローアップの結果は、購入された商品の使用継続の可否を含む。商品の使用継続の可否を示す可否情報は、フォローアップのための質問に対する回答を示す回答情報に基づいて、取得される。そのため、購入者の状況に応じた商品の使用継続の可否を、その購入者に提示することができる。

（適用例３）適用例３は、前記可否情報取得手段は、前記受信された回答情報と、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否の選択を受け付け可能な画面を、前記購入商品の使用継続の可否を決定する決定者が利用する決定者端末装置に表示させる画面情報と、を前記決定者端末装置へ送信する回答情報送信手段と、前記送信された画面情報に基づいて前記決定者端末装置により表示された前記画面で選択された前記使用継続の可否を示す前記可否情報を、前記決定者端末装置から受信する可否情報受信手段と、を含むことを特徴とするフォローアップ制御装置である。

本適用例によれば、回答情報は、決定者端末装置へ送信される。そのため、決定者端末装置を利用する決定者は、回答情報に基づいて、購入された商品の使用継続の可否を決定することができる。また、決定者端末装置には、購入された商品の使用継続の可否の選択を受け付け可能な画面が表示される。そのため、決定者は、商品の使用継続の可否を画面で選択することができる。

（適用例４）適用例４は、前記購入商品は医薬品であり、前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段を更に備え、前記購入商品識別情報取得手段は、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記購入商品として、前記診察を通じて決済された商品を識別する前記購入商品識別情報を取得することを特徴とするフォローアップ制御装置である。

本適用例によれば、購入者端末装置と医師端末装置とが通信接続されることにより、医師によるオンラインでの診察が可能となる。この診察を通じて決定された医薬品が購入される。この購入された医薬品について促し情報が送信される。そのため、診察を受けて医薬品を購入した顧客に対するフォローアップの負担を解消することができる。

（適用例５）適用例５は、前記購入商品が前記購入者に向けて発送されたことを示す発送完了情報を、前記購入商品の発送者が利用する発送者端末装置から受信する発送完了情報受信手段と、前記発送完了情報受信手段により前記発送完了情報が受信された場合、所定の記憶手段に記憶された発送状態であって、前記購入商品の前記購入者への発送状態を、未発送状態から発送完了状態に変更する変更手段と、を更に備え、前記促し情報送信手段は、前記発送状態が前記発送完了状態に設定されていることを条件に前記促し情報を送信することを特徴とするフォローアップ制御装置である。

本適用例によれば、購入された商品が発送されると、発送者が利用する発送者端末装置から発送完了情報が送信されて、その商品の発送状態が、未発送状態から発送完了状態に変更される。発送状態が発送完了状態に変更された後、促し情報が送信される。促し情報は、その商品の発送日から、その商品に対応する長さの期間の経過後に送信される。そのため、購入された商品に応じた時期であって、その商品の発送時期に応じた時期に、フォローアップを行うことができる。

（適用例６）適用例６は、コンピュータにより実行されるフォローアップ制御方法において、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得ステップと、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信ステップと、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信ステップと、を含み、前記促し情報送信ステップは、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品が前記購入者に向けて発送された発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信ステップは、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御方法である。

（適用例７）適用例７は、コンピュータを、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段、として機能させ、前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品が前記購入者に向けて発送された発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御プログラムである。

本発明によれば、商品の購入者に対するフォローアップの負担を解消することができる。

一実施形態に係る通信システムＳの概要構成の一例を示す図である。 （ａ）は、逐次購入の一例を示す図である。（ｂ）は、定期自動購入の一例を示す図である。 顧客端末４の画面遷移の一例を示す図である。 一実施形態に係る販売管理サーバ１の概要構成の一例を示すブロック図である。 販売管理サーバ１のデータベースに記憶される情報の例を示す図である。 販売管理サーバ１のデータベースに記憶される情報の例を示す図である。 販売管理サーバ１のデータベースに記憶される情報の例を示す図である。 一実施形態に係る販売管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。 商品画面１２００の一例を示す図である。 経過観察通知メールの一例を示す図である。 （ａ）乃至（ｃ）は、経過観察通知の送信タイミングの例を示す図である。 経過観察のための質問の内容の例を示す図である。 質問シート画面の一例を示す図である。 経過観察画面の一例を示す図である。 処方継続の可否の入力後における経過観察画面の一例を示す図である。 （ａ）乃至（ｃ）は、経過観察結果メールの一例を示す図である。 購入権ＤＢ１４ｇの更新例を示す図である。 商品の提供の制限例を示す図である。 定期自動購入における商品の提供の制限例を示す図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。 商品画面１２００の一例を示す図である。 一実施形態に係る販売管理サーバ１のシステム制御部１１により実行される商品画面情報送信処理の一例を示すフローチャートである。 一実施形態に係る販売管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。 一実施形態に係る通信システムＳの処理例を示すシーケンス図である。

以下、図面を参照して本発明の実施形態について詳細に説明する。少なくとも一の実施形態においては、販売者が顧客に対して商品を販売してもよい。商品は、例えば実店舗で販売されてもよいし、オンラインで販売されてもよい。実店舗で販売される商品は、販売者から顧客に手渡されてもよい。オンラインで販売される商品は、販売者から顧客へ発送されてもよい。販売者の例として、医療機関、薬局、化粧品店、専門店等が挙げられる。

少なくとも一の実施形態に係るフォローアップ制御装置（または商品提供制御装置）は、商品を購入した購入者に対するフォローアップを実施するか若しくはフォローアップの実施を支援してもよい。フォローアップは、例えば商品の購入後の購入者の状態及びその商品の状態のうち少なくとも何れか一方を顧客に確認することと、確認された状態に基づいて、必要に応じて購入者に情報を提供することと、を含んでもよい。購入者に提供される情報は、例えば購入者に対する助言を含んでもよいし、商品の使用についての何らかの判定結果を含んでもよい。フォローアップ制御装置は、顧客の状況を確認するために、顧客に対して質問情報を送信してもよい。質問情報は、購入者の状態や商品の状態を確認するための質問を示す情報であってもよい。フォローアップ制御装置は、購入者が利用する購入者端末から回答情報を受信してもよい。回答情報は、質問情報により示される質問に対する購入者若しくは商品の使用者の回答を示す情報であってもよい。商品の購入者とその商品の使用者とは同一人物であってもよい。或いは、使用者は購入者の関係者であってもよい。購入者は、関係者のために商品を購入する場合がある。関係者の例として、家族、親戚、友人等が挙げられる。

少なくとも一の実施形態に係るフォローアップ制御装置は、購入者端末装置から回答情報を受信すると、フォローアップの結果を示すフォローアップ結果情報を送信してもよい。フォローアップ結果情報は、前述したとおり、購入者に提供される情報を含んでもよい。フォローアップ制御装置は、所定の決定者へ回答情報を送信してもよい。決定者は、購入者に対して提供される情報を決定する人物であってもよい。決定者の例として、販売者の従業員、購入された商品の專門家、医師、薬剤師、コンサルタント等が挙げる。フォローアップ制御装置は、その決定者からフォローアップ結果情報を受信してもよい。或いは、フォローアップ制御装置は、回答情報に基づいて、提供する情報を自動的に決定してもよい。例えば、回答と提供される情報とが予め予め関連付けて、所定の記憶手段に記憶されてもよい。

購入者に対して提供される情報は、購入された商品の使用継続の可否を含んでもよい。決定者又はフォローアップ制御装置が、使用継続の可否を決定してもよい。購入者からの回答が、購入者が商品を使用継続することに対して問題がない場合、使用継続が決定されてもよい。購入者からの回答が、購入者が商品を使用継続することに対して問題がある場合、使用継続の不可若しくは使用中止が決定されてもよい。

少なくとも一の実施形態においては、顧客により同一の商品が継続的に提供されてもよい。例えば、購入者による商品の再注文若しくは再購入が可能であったり、購入者に対して商品が継続的に発送されたりしてもよい。フォローアップにおいて、購入された商品の使用中止が決定された場合、フォローアップ制御装置は、その商品をその購入者へ提供することを制限するための処理を実行してもよい。商品の提供の制限の例として、商品の購入を不可能にすること、追加的な条件を購入者が満たした場合に限り購入を許可すること、商品を発送しないこと、商品の購入予定若しくは発送予定をキャンセルすること等が挙げられる。

販売者が販売する商品の全部がフォローアップの対象であってもよい。或いは、一部の商品がフォローアップの対象であってもよい。例えば、顧客（または関係者）と決定者との面談が実施されたことを条件に、その顧客が購入可能となる商品が、フォローアップの対象となっていてもよい。例えば、遅くともその商品の注文の確定前に面談が行われることが必要であってもよい。面談の例として、診察、カウンセリング、コンサルティング、服薬指導、情報提供等が挙げられる。面談は、オフラインで行われてもよいし、オンラインで行われてもよい。面談においては、決定者から顧客に対してその商品の説明が行われてもよい。また面談においては、決定者が顧客の状態を確認してもよい。面談において、決定者が顧客に対してその商品の使用を許可した場合に限り、顧客は商品の購入が可能であってもよい。或いは、決定者による許可を要さずに、顧客は商品の購入が可能であってもよい。購入される商品は、決定者との面談前に顧客が選択してもよいし、面談中に決定者が決定してもよし、面談後に顧客又は決定者が決定してもよい。購入前の面談が不要な商品の中にも、フォローアップの対象となっている商品が存在してもよい。また、購入前の面談が必要な商品の中にも、フォローアップの対象となっていない商品が存在してもよい。

決定者が医師である場合、フォローアップの対象となる商品は、医療用医薬品を含んでもよい。医療用医薬品を販売者が顧客へ提供するためには、医師の処方が必要である。この場合における商品の購入前の面談は、診察であってもよい。またこの場合のフォローアップは、経過観察であってもよい。医療用医薬品以外の医薬品の中にも、フォローアップの対象となる医薬品が存在してもよい。また医療用医薬品以外の化粧品の中にも、フォローアップの対象となる化粧品が存在してもよい。決定者が薬剤師である場合、フォローアップの対象となる商品は、医薬品を含んでもよい。この場合における商品の購入前の面談は、服薬指導又は薬剤師から顧客に対する情報提供であってもよい。

以降においては、販売者は医療機関であり、フォローアップの対象となる商品は医療用医薬品であり、決定者は医師である場合の実施例について説明する。しかしながら、上述したように、販売者が医療機関とは異なる形態や、フォローアップの対象となる商品が医療用医薬品とは異なる形態や、販売者が医療機関とは異なる形態にも、本願は適用可能である。

［１．第１実施形態］
［１－１．通信システムの構成］
先ず、本実施形態に係る通信システムＳの構成及び機能概要について、図１を参照して説明する。図１は、本実施形態に係る通信システムＳの概要構成の一例を示す図である。

図１に示すように、通信システムＳは、販売管理サーバ１と、少なくとも一の医師端末２と、少なくとも一の出荷端末３と、複数の顧客端末４と、を含んで構成されてもよい。販売管理サーバ１、医師端末２、出荷端末３及び各顧客端末４は、ネットワークＮＷを介して互いに接続される。ネットワークＮＷは、例えばインターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。

販売管理サーバ１は、所定の医薬品ＥＣ（Electronic Commerce）プラットフォームに関する各種処理を行うサーバ装置であってもよい。医薬品ＥＣプラットフォームは、顧客がオンラインで所定の医療機関から医薬品等を購入可能とするウェブサイトであってもよい。医薬品ＥＣプラットフォームで販売される主な商品は医薬品であってもよい。販売される医薬品として、医療用医薬品と一般用医薬品とがあってもよい。医療用医薬品は、医師による処方に基づいて提供される医薬品である。一般用医薬品は、医師による処方が不要な医薬品である。医薬品ＥＣプラットフォームでは、医薬品以外の商品も販売されてもよい。そうした商品の例として、化粧品、健康食品等が挙げられる。販売管理サーバ１は、例えば顧客端末４等からの要求に応じて、医薬品ＥＣプラットフォームに含まれるウェブページ等のコンテンツを顧客端末４へ送信してもよい。また、販売管理サーバ１は、顧客からの商品の注文を受け付けるための処理を実行してもよい。更に、販売管理サーバ１は、顧客が医療用医薬品を注文するために医療機関での診察（または診療）の予約を受け付ける処理を実行してもよい。この診察は、オンライン診察であってもよいし、オフラインで行われる診察であってもよい。また更に、販売管理サーバ１は、オンライン診察が予約された場合において、そのオンライン診察を実現するための処理を実行してもよい。オンライン診察では、医師端末２と顧客端末４との間で音声及び映像の通信が行われてもよい。

医師端末２は、医療機関に利用される端末装置であってもよい。この医師端末２は、医師が主に利用する端末装置であってもよい。例えば、医師端末２は、電子カルテの表示及び入力、処方の入力、経過観察のための質問及び回答の表示、購入後の医療用医薬品の処方継続の可否の入力等に用いられてもよい。また、医師端末２は、オンライン診察のために用いられてもよい。医師端末２の例として、パーソナルコンピュータ、タブレットコンピュータ等が挙げられる。医師端末２は、映像を撮影するためのビデオカメラを備えてもよいし、ビデオカメラと接続可能となっていてもよい。また、医師端末２は、音声の入力に用いられるマイクロホンを備えてもよいし、マイクロホンと接続可能になっていてもよい。医師端末２には、ウェブブラウザや電子メールクライアント等のソフトウェアが組み込まれていてもよい。医師端末２は、購入された商品の使用継続の可否を決定する決定者としての医師が利用する決定者端末装置の一例であってもよい。

出荷端末３は、医療機関が主として商品の出荷の際に用いるための端末装置であってもよい。この出荷端末３は、薬剤師やその他の従業員が利用する端末装置であってもよい。例えば、出荷端末３は、発送される商品の情報や配送先に関する情報を表示してもよい。従業員は、出荷端末３に表示された情報に基づいて、注文された商品の出荷作業を行ってよい。出荷端末３の例として、パーソナルコンピュータ、タブレットコンピュータ等が挙げられる。出荷端末３には、ウェブブラウザや電子メールクライアント等のソフトウェアが組み込まれていてもよい。

各顧客端末４は、医薬品ＥＣプラットフォームを利用可能な商品の買い手としての顧客が利用する端末装置であってもよい。各顧客端末４は、例えば顧客による操作に基づいて販売管理サーバ１等からウェブページ等のコンテンツを受信して表示してもよい。顧客端末４の例として、スマートフォン、タブレットコンピュータ等の携帯情報端末、携帯電話機、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータ、セットトップボックス等が挙げられる。各顧客端末４は、映像を撮影するためのビデオカメラを備えてもよいし、ビデオカメラと接続可能となっていてもよい。また、各顧客端末４は、音声の入力に用いられるマイクロホンを備えてもよいし、マイクロホンと接続可能になっていてもよい。各顧客端末４には、ウェブブラウザや電子メールクライアント等のソフトウェアが組み込まれていてもよい。携帯用の顧客端末４には、専用アプリのインストールが可能であってもよい。専用アプリは、医薬品ＥＣプラットフォームを利用するためのアプリケーションである。顧客端末４は、専用アプリに従って、販売管理サーバ１へ各種の要求を送信し、販売管理サーバ１からコンテンツを受信して表示してもよい。

［１－２．商品の継続購入及び経過観察］
次に商品の継続購入について、図２を参照して説明する。或る商品を初めて購入することを、初回購入と称する。商品の継続購入とは、或る商品を初回購入した後、顧客がその商品を再購入することであってもよい。販売者からの立場からすると、継続購入とは、顧客に対して同一の商品を継続的に提供することに相当してもよい。特に本実施形態における継続購入とは、顧客が特定の条件若しくは追加的な条件を満たす必要なく同一の商品を再購入することであってもよい。或いは商品の継続購入は、フォローアップの対象となる商品を一度購入した後で、顧客がその商品を再購入することであってもよい。特定の条件若しくは追加的な条件とは、その商品を初めて購入する際に顧客が満たすべき条件であってもよい。例えば商品が医療用医薬品である場合、この条件は、医師の診察を受けること若しくは医師にその商品を処方してもらうことであってもよい。

医療用医薬品には、最大処方量が定められてもよい。最大処方量は、１回の処方若しくは１枚の処方箋で、最大どれだけの量の医療用医薬品を処方することができるかを示してもよい。商品の量は、例えば商品が使用、服用若しくは消費されることが予定されている期間の長さで示されてもよい。この期間の長さは、例えば日数、週数若しくは月数で示されてもよい。本実施形態では月数が用いられるものとする。例えば、毎日、朝昼晩の３回１錠ずつ服用する医薬品の１ヶ月分の量は、９０錠に相当してもよい。最大処方量の例として、６ヶ月、１２ヶ月等が挙げられる。最大処方量は、例えば医薬品ＥＣプラットフォーム内において、全医療用医薬品で共通に定められていてもよい。或いは最大処方量は、医薬品ごとに定められていてもよい。或いは最大処方量は、医薬品のカテゴリごとに定められていてもよい。或いは最大処方量は、処方の際に医師により決定されてもよい。本実施形態において、最大処方量は全医療用医薬品で共通であるものとする。

医師の診察を受ける等の特定の条件を満たすことを条件として顧客が獲得する権利であって、商品を初回購入したり継続購入したりすることができる権利を、購入権と称する。初回購入で顧客が購入する医療用医薬品の量は、最大処方量以下の範囲で決定される。例えば顧客が購入量を選択してもよいし、医師が購入量を選択してもよい。最大処方量から初回購入時の医薬品の購入量を減算して得られる残量以下の範囲内で、顧客はその医薬品を継続購入することが可能であってもよい。購入権の主要な効果は、継続購入の際に、改めての医師の診察及び処方の何れも必要としないことであってもよい。

購入権が設定されている商品について顧客が既にその商品を購入している総量若しくは販売者が顧客に発送している総量を、既購入量と称する。既購入量が最大処方量に達すると、購入権は消滅してもよい。また、その商品が処方された日から最大処方量に相当する長さの期間が経過した場合、購入権は消滅してもよいし、消滅しなくてもよい。一度購入権が消滅した商品を顧客が再購入するには、医師の診察を受ける等の特定の条件を顧客が満たす必要があってもよい。

医薬品ＥＣプラットフォームにおける商品の継続購入の形態として、逐次購入及び定期自動購入が存在してもよい。逐次購入及び定期自動購入のうち何れの形態で商品を購入するかを、顧客が選択可能になっていてもよい。或いは、逐次購入及び定期自動購入のうち何れか一方のみが可能なように、医薬品ＥＣプラットフォームが構成されていてもよい。或いは、商品ごと若しくは商品のカテゴリごとに、逐次購入が可能であるか否か及び定期自動購入が可能であるか否かが予め定められていてもよい。

逐次購入は、顧客がその都度商品を選択して注文する形態の購入であってもよい。図２（ａ）は、逐次購入の一例を示す図である。例えば顧客は、最大処方量が６ヶ月分の量である商品を初めて注文した。このとき、顧客は医師の診察を受けて、医師はその商品を処方した。図２（ａ）に示すように、顧客は１ヶ月分の商品を注文した。医療機関から顧客へ１ヶ月分の商品が発送された。この時点で、顧客は５ヶ月分の商品を購入する権利を有している。処方から１ヶ月後、顧客は同じ商品を２ヶ月分注文した。このとき、医師による診察は省略される。医療機関から顧客へ２ヶ月分の商品が発送された。この時点で、顧客は３ヶ月分の商品を購入する権利を有している。処方から３ヶ月後、顧客は同じ商品を３ヶ月分注文した。このとき、医師による診察は省略される。医療機関から顧客へ３ヶ月分の商品が発送された。この時点で、顧客の購入権は消滅する。２回目以降の商品の購入は、継続購入に相当してもよい。

定期自動購入は、定期的に商品が購入者へ発送される形態の購入であってもよい。定期的な商品の配送は、定期配送とも称される。図２（ｂ）は、定期自動購入の一例を示す図である。例えば、顧客は最大処方量が６ヶ月分の量である商品を初めて注文した。このとき、顧客は医師の診察を受けて、医師はその商品を処方した。図２（ｂ）に示すように、先ず、医療機関から顧客へ１ヶ月分の商品が発送された。その後、１ヶ月間隔で医療機関から顧客へ１ヶ月分の商品が発送された。販売管理サーバ１は、その都度、１ヶ月分の商品の購入代金を自動的に決済してもよい。初回の発送を含めて、合計６回商品が発送されると、顧客の購入権は消滅する。２回目以降の決済及び発送は、継続購入に相当してもよい。なお、一度に配送される商品の量及び発送の間隔は、１ヶ月に限定されない。

購入権が有効である期間若しくは最大処方量に相当する長さの期間の間に、顧客に対するフォローアップの一例として、経過観察が１回又は複数回が行われてもよい。例えば図２（ａ）及び図２（ｂ）に示す例では、１ヶ月ごとに経過観察が行われている。しかしながら、経過観察の間隔は１ヶ月に限定されない。購入形態が逐次購入の場合、顧客は既購入量が最大処方量に達するまで商品を購入する必要はない。顧客は継続購入を中断してもよい。購入形態が定期自動購入である場合、顧客は途中で定期自動購入をキャンセル可能であるように、販売管理サーバ１が構成されていてもよい。これらの場合、既購入量に相当する期間中のみ、経過観察が行われてもよい。なお、初回購入に、医師の診察等の特定の条件を顧客が満たす必要がない商品についても、経過観察又はフォローアップが実施されてもよい。

経過観察において、販売管理サーバ１は、その経過観察のための質問を示す質問情報を顧客端末４へ送信してもよい。顧客は、質問に対する回答を入力してもよい。販売管理サーバ１は、入力された回答を示す回答情報を、医師端末２へ送信してもよい。医師は、顧客からの回答に基づいて、顧客による商品の使用継続の可否を決定してしてもよい。例えば医師は、処方継続及び処方中止の何れかを決定してもよい。処方継続は、その商品の使用を継続してもよいことを示してもよい。処方中止は、その商品の使用の継続を中止すべきであることを示してもよい。処方中止が決定された場合、その商品について設定された購入権は、消滅してもよいし、停止されてもよい。これによって、医療機関から顧客へのその商品の提供は制限されてもよい。商品の提供の制限は、顧客によるその商品の購入が制限されることに相当してもよい。

［１－３．画面遷移］
次に、医薬品ＥＣプラットフォームにおける商品の選択から注文の完了までにおける顧客端末４の画面の遷移例について、図３を用いて説明する。医薬品ＥＣプラットフォームにおける画面は、商品の注文を可能とする電子商取引に係わる画面であってもよい。図３は、顧客端末４の画面遷移の一例を示す図である。前述したように、医薬品ＥＣプラットフォームにおいては、医療用医薬品と、一般用医薬品及び商品と、が販売される。医療用医薬品を販売するためには医師による処方が必要となる。処方を行うためには、医師が顧客を診察する必要がある。そのため、医療用医薬品とその他の商品とでは、商品を注文するための画面の遷移が異なる。各画面は、例えばウェブページで販売管理サーバ１から顧客端末４に提供されてもよい。

図３に示すように、顧客端末４が医薬品ＥＣプラットフォームにアクセスすると、先ず商品選択画面１１００が表示されてもよい。商品選択画面１１００は、詳細な情報を見たい商品を顧客が選択するための画面であってもよい。商品選択画面１１００は、複数種類の画面を含んでもよい。例えば、商品選択画面１１００は、検索条件入力画面、検索結果画面等を含んでもよい。検索条件入力画面は、商品の検索条件を入力又は選択するための画面であってもよい。検索条件の例として、商品のカテゴリ、キーワード等が挙げられる。検索結果画面は、入力された検索条件を満たす商品の一覧を検索結果として表示する画面であってもよい。

検索結果の中から顧客が何れかの商品を選択すると、商品画面１２００が表示されてもよい。商品画面１２００は、選択された商品に関する詳細な情報が表示される画面であってもよい。商品画面１２００において、顧客は、その商品を、注文するために選択する操作を行うことができる。例えば、その商品をカートに入れる操作が可能であってもよい。カートは、医薬品ＥＣプラットフォームにおいて各顧客が有する仮想的な買い物用の入れ物又はリストであってもよい。顧客は、カートに入っている商品を注文することができる。

その後、顧客による操作に基づいて、カート画面１３００が表示されてもよい。カート画面１３００は、現在カートに入っている商品の一覧を示す画面であってもよい。カート画面１３００において、顧客は、注文しようとする商品の削除や数量の変更が可能であってもよい。

カートに入れられている商品の中に医療用医薬品が１つも存在しない場合、次に注文内容確認画面２１００が表示されてもよい。注文内容確認画面２１００は、注文内容を示すとともに、その注文内容で注文を確定することを示す画面であってもよい。注文内容確認画面２１００に示される注文内容は、カートに入れられている商品を含む。顧客は、注文内容確認画面２１００で注文内容を確認して、注文を確定させる操作を行う。この操作に応じて、注文完了画面２２００が表示されてもよい。注文完了画面２２００は、注文が確定したことを示す画面であってもよい。

一方、カートに入れられている商品の中に医療用医薬品が存在する場合、カート画面１３００の次に注文申込内容確認画面１４００が表示されてもよい。注文申込内容確認画面１４００は、カートに入れられている商品の注文を申し込む（または注文の受け付けをリクエストする）ための画面であってもよい。注文申込内容確認画面１４００は、申し込まれる注文内容を含んでもよい。注文内容は、カートに入れられている商品を含んでもよい。

顧客が注文の申し込みを行うと、診察予約画面１５００が表示されてもよい。診察予約画面１５００は、顧客が注文を申し込んだ医療用医薬品の処方を受けるための診察の日時を選択するための画面であってもよい。この時点では、顧客の注文はまだ正式には受け付けられていなくてもよい。

顧客が診察日時を選択すると、診察予約確認画面１６００が表示されてもよい。診察予約確認画面１６００は、診察の予約内容を確認するための画面であってもよい。

診察予約確認画面１６００に表示された予約内容で顧客が診察の予約を確定させると、診察予約受付完了画面１７００が表示されてもよい。診察予約受付完了画面１７００は、診察の予約が完了したことを示す画面であってもよい。

次に、問診票画面１８００が表示されてもよい。問診票画面１８００は、診察に先だって顧客が問診票に記入するための画面であってもよい。

診察の予約が確定した後、顧客宛てに診察通知メールが送信されてもよい。診察通知メールは、予約された診察に関する情報を通知する電子メールであってもよい。診察通知メールには、診察日時が記載されているとともに、オンライン診察用のＵＲＬが記載されてもよい。診察日当日に、顧客が診察通知メールからこのＵＲＬを選択すると、顧客端末４は販売管理サーバ１にアクセスして、診察待機画面１９００が表示されてもよい。或いは、医薬品ＥＣプラットフォーム内の所定のメニューから顧客がオンライン診察を選択すると、診察待機画面１９００が表示されてもよい。診察待機画面１９００は、診察開始まで待機状態であることを示す画面であってもよい。

その後、診察開始時刻になると、顧客診察画面２０００が表示されてもよい。顧客診察画面２０００は、オンライン診察において顧客が医療機関の医師と会話するための画面であってもよい。顧客診察画面２０００において、顧客は、医師から医療用医薬品に関する説明を受けることができる。また、顧客診察画面２０００には、注文が予定される商品として、顧客が選択した商品に関する情報が表示されてもよい。診察を行っている医師により、その注文内容が変更されることがあってもよい。

オンライン診察が終了して医師による処方が行われると、注文内容確認画面２１００が表示されてもよい。注文内容確認画面２１００は、最終的な注文内容を示すとともに、その注文内容で注文を確定させるための操作を受け付ける画面であってもよい。

顧客が注文を確定させると、販売サーバ１は注文を受け付けて、注文された商品の購入代金を決済する処理を行ってもよい。決済が完了すると、注文完了画面２２００が表示されてもよい。注文完了画面２２００は、注文の完了及び決済の完了を示す画面であってもよい。決済が完了すると、注文された商品が医療機関から顧客へ発送されてもよい。

なお、顧客により選択された医薬品が医療用医薬品である場合、その医薬品を医療機関が発送するのではなく、その顧客へ処方箋を提供するように販売管理サーバ１が構成されてもよい。例えば、医師による処方が行われると、販売管理サーバ１又は医師端末２は、処方箋を印刷してもよい。医療機関の従業員は、その処方箋を顧客へ郵送してもよい。或いは、販売管理サーバ１は、電子処方箋を生成してもよい。販売管理サーバ１は、顧客宛ての電子メールで電子処方箋を送信してもよい。或いは、販売管理サーバ１は、医薬品ＥＣプラットフォームの所定のウェブページから電子処方箋をダウンロード可能にしてもよい。

また、顧客により選択された医薬品が医療用医薬品である場合、その医薬品を薬局が発送するように販売管理サーバ１が構成されてもよい。例えば、医師による顧客の診察が終わると、医療機関から薬局へ処方箋が送付されてもよい。例えば、医療機関から薬局へ処方箋が郵送されてもよい。或いは、販売管理サーバ１が、電子処方箋を、薬局が利用する端末装置である図示せぬ薬局端末へ送信してもよい。処方箋を受領した薬局の薬剤師は、顧客に対して服薬指導を行ってもよい。服薬指導は、例えばオンラインで行われてもよい。オンライン診察の場合と同様に、オンラインの服薬指導では、薬局端末と顧客端末４との間で音声及び映像の通信が行われてもよい。服薬指導が終わった後、薬局は医療用医薬品を顧客へ発送してもよい。

また、医療用医薬品と異なる商品の中に、医師の診察を受けることを条件として顧客が注文可能となる商品が存在してもよい。例えば医師の診察が必要な商品又は商品のカテゴリが、医薬品ＥＣプラットフォームにおいて又は各薬局により予め定められていてもよい。

［１－４．販売管理サーバの構成］
次に、販売管理サーバ１の構成について、図４乃至図７を用いて説明する。図４は、本実施形態に係る販売管理サーバ１の概要構成の一例を示すブロック図である。図４に示すように、販売管理サーバ１は、システム制御部１１と、システムバス１２と、入出力インタフェース１３と、記憶部１４と、通信部１５と、を備えている。システム制御部１１と入出力インタフェース１３とは、システムバス１２を介して接続されている。

システム制御部１１は、ＣＰＵ（Central Processing Unit）１１ａ、ＲＯＭ（Read Only Memory）１１ｂ、ＲＡＭ（Random Access Memory）１１ｃ等により構成されている。

入出力インタフェース１３は、記憶部１４及び通信部１５とシステム制御部１１との間のインタフェース処理を行う。

記憶部１４は、例えば、ハードディスクドライブ等により構成されている。この記憶部１４には、会員ＤＢ１４ａ、商品ＤＢ１４ｂ、カートＤＢ１４ｃ、診察予約ＤＢ１４ｄ、処方履歴ＤＢ１４ｅ、注文ＤＢ１４ｆ、購入権ＤＢ１４ｇ、発送予定ＤＢ１４ｈ、経過観察期間ＤＢ１４ｉ、質問情報ＤＢ１４ｊ、経過観察通知予定ＤＢ１４ｋ、回答ＤＢ１４ｌ、及び経過観察結果ＤＢ１４ｍ等のデータベースが記憶されてもよい。「ＤＢ」は、データベースの略語である。少なくとも一のデータベースは、販売管理サーバ１と異なるサーバ装置に記憶されてもよい。販売管理サーバ１は、そのサーバ装置を介してデータベースにアクセス可能であってもよい。

図５乃至図７は、販売管理サーバ１のデータベースに記憶される情報の例を示す図である。会員ＤＢ１４ａには、医薬品ＥＣプラットフォームを利用可能な各顧客に関する会員情報が記憶されてもよい。例えば図５に示すように、会員ＤＢ１４ａには、会員情報として、顧客ＩＤ、氏名、性別、生年月日、住所、電話番号、電子メールアドレス、及びクレジットカード情報等が、互いに関連付けて記憶されてもよい。顧客ＩＤは、顧客を識別する識別情報であってもよい。クレジットカード情報は、その顧客が利用可能なクレジットカードに関する情報であってもよい。例えば、クレジットカード情報は、カード番号、有効期限、クレジットカードの所有者の氏名等を含んでもよい。

商品ＤＢ１４ｂには、医薬品ＥＣプラットフォームで販売される各商品に関する商品情報が記憶されてもよい。例えば商品ＤＢ１４ｂには、商品情報として、商品ＩＤ、カテゴリ情報、医療用医薬品フラグ、商品名、一般名、価格、商品説明、及び商品画像ＵＲＬ（Uniform Resource Locator）等が、互いに関連付けて記憶されてもよい。商品ＩＤは、商品を識別する識別情報であってもよい。カテゴリ情報は、その商品が属するカテゴリを示す情報であってもよい。商品のカテゴリの例として、美容内服薬、美容外用薬、化粧品、ダイエット薬品、ピル、ＡＧＡ（Androgenetic Alopecia）治療薬、ＥＤ（Erectile Dysfunction）治療薬等が挙げられる。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。医療用医薬品フラグは、図３に示すように、顧客端末４が表示する画面を、カート画面１３００から注文申込内容確認画面１４００に遷移させるか否かの判定に用いられてもよい。販売管理サーバ１は、医療用医薬品フラグがＴＲＵＥに設定されている商品がカートに入っている場合、顧客端末４の画面を注文申込内容確認画面１４００に遷移させてもよい。その後、顧客は、診察を予約して、医師の診察を受けてから商品の注文を確定させることとなる。一方、販売管理サーバ１は、医療用医薬品フラグがＦＡＬＳＥに設定されている商品のみがカートに入っている場合、顧客端末４の画面を注文内容確認画面２１００に遷移させてもよい。その後、顧客は、医師の診察を受けることなる商品の注文を確定させることとなる。前述したように、医療用医薬品と異なる商品の中に、医師の診察を受けることを条件として顧客が注文可能となる商品が存在してもよい。この場合、商品ＤＢ１４ｂには、例えば診察対象フラグが記憶されてもよい。診察対象フラグは、その商品の注文を確定させるために顧客が医師の診察を受ける必要があるか否かを示してもよい。販売管理サーバ１は、診察対象フラグがＴＲＵＥに設定されている商品がカートに入っている場合、顧客端末４の画面を注文申込内容確認画面１４００に遷移させてもよい。一方、販売管理サーバ１は、診察対象フラグがＦＡＬＳＥに設定されている商品のみがカートに入っている場合、顧客端末４の画面を注文内容確認画面２１００に遷移させてもよい。商品名は、その商品の名称を示してもよい。一般名は、その商品が医薬品である場合において、その商品の主成分の名称を示してもよい。商品画像ＵＲＬは、その商品の画像のデータのＵＲＬであってもよい。

カートＤＢ１４ｃには、各顧客のカートに現在入れられている商品に関するカート情報が記憶されてもよい。例えば、カートＤＢ１４ｃには、カート情報として、顧客ＩＤ、及びカート商品情報等が、互いに関連付けて記憶されてもよい。顧客ＩＤは、そのカードを所有する顧客を示してもよい。カート商品情報は、カートに入っている個別の商品に関する情報であってもよい。一のカートに複数の商品が入っている場合、カートＤＢ１４ｃには、それら複数の商品のそれぞれについて、カート商品情報が記憶されてもよい。各カート商品情報は、商品ＩＤ、購入形態、数量、及び医療用医薬品フラグ等を含んでもよい。商品ＩＤは、カートに入っている商品を示してもよい。購入形態は、その商品の購入形態が、逐次購入及び定期自動購入のうちの何れであるかを示してもよい。数量は、その商品の購入量を月数で示してもよい。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。商品ＤＢ１４ｂの場合と同様に、カートＤＢ１４ｃには診察対象フラグが記憶されてもよい。なお、販売管理サーバ１は、カート情報を記憶部１４に記憶させるのではなく、例えば各顧客端末４にＨＴＴＰ（HyperText Transfer Protocol）クッキーとしてカート情報を記憶させてもよい。

診察予約ＤＢ１４ｄには、オンライン診察の各予約に関する予約情報が記憶されてもよい。例えば、診察予約ＤＢ１４ｄには、予約情報として、予約番号、診察日、診察開始時刻、診察終了時刻、及び顧客ＩＤ等が、互いに関連付けて記憶されてもよい。予約番号は、予約を識別する番号であってもよい。診察日は、予約された診察が行われる日付を示してもよい。診察開始時刻及び診察終了時刻は、それぞれ診察のために予約された時間帯の開始時刻及び終了時刻を示してもよい。顧客ＩＤは、診察を予約した顧客を示してもよい。

処方履歴ＤＢ１４ｅには、医療機関の医師による処方の履歴が記憶されてもよい。処方履歴ＤＢ１４ｅには、オンライン診察で行われた処方に関する履歴のみが記憶されてもよいし、オフラインでの診察で行われた処方に関する履歴も記憶されてもよい。例えば、処方履歴ＤＢ１４ｅには、処方が行われるごとに、処方ログとして、処方番号、処方日時、予約番号、顧客ＩＤ、及び処方医薬品情報等が、互いに関連付けて記憶されてもよい。処方番号は、処方を識別する番号であってもよい。処方日時は、処方が行われた日時を示してもよい。予約番号は、その処方が行われた診察の予約を識別する番号であってもよい。顧客ＩＤは、処方された医薬品が提供される顧客を示してもよい。すなわち、顧客ＩＤは、医師が診察した顧客を示してもよい。処方医薬品情報は、処方された個別の医薬品に関する情報であってもよい。一の処方で複数の医薬品の調剤が指示された場合、処方履歴ＤＢ１４ｅには、それら複数の医薬品のそれぞれについて、処方医薬品情報が記憶されてもよい。各処方医薬品情報報は、商品ＩＤ、購入形態、数量、及び医療用医薬品フラグ等を含んでもよい。商品ＩＤは、処方された医薬品を示してもよい。購入形態は、その医薬品の購入形態が、逐次購入及び定期自動購入のうちの何れであるかを示してもよい。数量は、その医薬品の購入量を月数で示してもよい。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。商品ＤＢ１４ｂの場合と同様に、処方履歴ＤＢ１４ｅには診察対象フラグが記憶されてもよい。

注文ＤＢ１４ｆには、医薬品ＥＣプラットフォームで受け付けられた注文に関する注文情報が、注文が確定するごとに記憶されてもよい。例えば図６に示すように、注文ＤＢ１４ｆには、注文情報として、注文番号、注文日時、顧客ＩＤ、注文商品情報、処方番号、支払金額、配送先情報等が、互いに関連付けて記憶されてもよい。注文番号は、注文を識別する番号であってもよい。注文日時は、その注文が確定した日時を示してもよい。顧客ＩＤは、その注文を行った顧客を示してもよい。注文商品情報は、注文された個別の商品に関する情報であってもよい。一の注文で複数の商品が注文された場合、注文ＤＢ１４ｆには、それら複数の商品のそれぞれについて注文商品情報が記憶されてもよい。各注文商品情報は、商品ＩＤ、購入形態、数量、医療用医薬品フラグ、及び継続購入フラグ等を含んでもよい。商品ＩＤは、注文された商品を示してもよい。購入形態は、その商品の購入形態が、逐次購入及び定期自動購入のうちの何れであるかを示してもよい。数量は、その商品の購入量を月数で示してもよい。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。商品ＤＢ１４ｂの場合と同様に、注文ＤＢ１４ｆには診察対象フラグが記憶されてもよい。継続購入フラグは、その商品の購入が、初回購入及び継続購入のうちの何れであるかを示してもよい。処方番号は、注文された商品が医療用医薬品を含む場合において、その処方を識別する番号であってもよい。支払金額は、注文された商品の代金と送料との合計であってもよい。配送先情報は、注文された商品の配送先を示す情報であってもよい。

購入権ＤＢ１４ｇには、医療用医薬品の購入権に関する購入権情報が、医師の診察を経た上で注文が確定した医薬品ごとに、記憶されてもよい。例えば購入権ＤＢ１４ｇには、購入権情報として、購入権ＩＤ、注文番号、設定日、顧客ＩＤ、商品ＩＤ、最大処方量、既購入量、及び権利状態等が、互いに関連付けて記憶されてもよい。購入権ＩＤは、購入権を識別する識別情報であってもよい。注文番号は、その購入権に対応する注文を示してもよい。設定日は、購入権が設定された日付を示してもよい。顧客ＩＤは、その購入権を有する顧客を示してもよい。商品ＩＤは、その購入権が設定された商品を示してもよい。最大処方量は、その商品について最大どれだけの量を処方することができるかを示してもよい。全医療用医薬品で最大処方量が同一である場合、購入権ＤＢ１４ｇには最大処方量が記憶されなくてもよい。既購入量は、その購入者によってその商品がどれだけの量既に購入されているかを示してもよい。権利状態は、その購入権の状態を示してもよい。例えば権利状態は、「有効」、「消滅」、及び「停止」のうちの何れかに設定されてもよい。「有効」は、その購入権が有効に存続していることを示してもよい。「消滅」は、最大処方量分の商品が顧客に提供されたことを理由に、その購入権が無効となったことを示してもよい。「停止」は、医師により処方中止が決定されたことを理由に、その購入権が無効となったことを示してもよい。

発送予定ＤＢ１４ｈには、購入された商品の発送予定を示す発送予定情報が、予定された発送ごとに記憶されてもよい。例えば発送予定ＤＢ１４ｈには、発送予定情報として、発送予定ＩＤ、注文番号、顧客ＩＤ、購入形態、発送回、発送先情報、発送予定日、発送日、及び発送予定商品情報等が、互いに関連付けて記憶されてもよい。発送予定ＩＤは、発送予定を識別する識別情報であってもよい。注文番号は、その商品の発送を必要とする注文を示してもよい。顧客ＩＤは、商品を注文した顧客を示してもよい。購入形態は、発送される商品が逐次購入及び定期自動購入の何れで購入されたかを示してもよい。発送回は、購入形態が定期自動購入である場合に有効であってもよい。発送回は、定期配送で商品が発送される場合において、予定される配送が、定期配送における何回目の配送であるかを示してもよい。発送予定日は、商品の発送が予定されている日付を示してもよい。発送日は、商品が発送された日付を示してもよい。発送予定商品情報は、発送が予定される個別の商品に関する情報であってもよい。一の発送で複数の商品が発送される場合、発送予定ＤＢ１４ｈには、それら複数の商品についての発送予定商品情報が記憶されてもよい。各発送予定商品情報は、商品ＩＤ、数量、及び発送状態を含んでもよい。商品ＩＤは、発送される予定の商品を示してもよい。数量は、その商品の購入量を月数で示してもよい。発送状態は、その商品の発送の状態を示してもよい。例えば発送状態は、「未発送」、「発送完了」、及び「キャンセル」のうちの何れかに設定されてもよい。「未発送」は、その商品がまだ発送されていないことを示してもよい。「発送完了」は、その商品が既に発送されていることを示してもよい。「キャンセル」は、その商品の発送がキャンセルされたことを示してもよい。「キャンセル」は、定期配送についての発送予定について設定される場合があってもよい。

経過観察期間ＤＢ１４ｉには、経過観察のための質問に対する回答を顧客に促す通知を行うまでの期間に関する経過観察期間情報が、商品のカテゴリと経過観察の実施回との組み合わせごとに記憶されてもよい。経過観察の実施回は、実施される経過観察が、商品の初回購入から何回目の経過観察であるかを示してもよい。経過観察期間ＤＢ１４ｉには、例えば経過観察期間情報として、カテゴリ情報、実施回、及び経過観察期間長等が、互いに関連付けて記憶されてもよい。カテゴリ情報は、経過観察の対象となる商品のカテゴリを示してもよい。経過観察期間長は、初回購入によるそのカテゴリの商品の発送日からその実施回の経過観察の通知までの期間の長さを示してもよい。経過観察期間長は、フォローアップの時期までの期間の長さを示す商品期間長情報の一例であってもよい。経過観察期間長の例として、日数、週数、月数等が挙げられる。本実施形態では、経過観察期間長は月数で示されるものとする。

質問情報ＤＢ１４ｊには、経過観察のための質問の内容を示す質問情報が、商品のカテゴリごとに記憶されてもよい。例えば質問情報ＤＢ１４ｊには、カテゴリ情報及び質問状法等が、互いに関連付けて記憶されてもよい。カテゴリ情報は、質問の対象となる商品のカテゴリを示してもよい。質問情報は、１又は複数の質問のそれぞれの内容を示してもよい。例えば、質問情報は、質問ごとに、質問番号、質問内容を示すテキスト、回答として選択可能な選択肢を示すテキスト等を含んでもよい。記憶部１４には、質問情報ＤＢ１４ｊに加えて、質問シート画面表示情報が、商品のカテゴリごとにカテゴリ情報に関連付けて記憶されてもよい。質問シート画面表示情報は、質問シート画面を顧客端末４に表示させる情報であってもよい。質問シート画面は、経過観察のための質問を表示するとともに、その質問に対する回答の入力を受け付け可能な画面であってもよい。質問シート画面表示情報は、ＨＴＭＬ（HyperText Markup Language）文書であってもよいし、その他の情報であってもよい。販売管理サーバ１は、質問情報ＤＢ１４ｊに記憶された質問情報に基づいて、質問シート画面表示情報を予め生成しておいてもよい。

経過観察通知予定ＤＢ１４ｋには、経過観察のための質問に対する回答を顧客に促す通知を行う予定を示す経過観察通知予定情報が、経過観察ごとに記憶されてもよい。例えば図７に示すように、経過観察通知予定ＤＢ１４ｋには、経過観察通知予定情報として、経過観察ＩＤ、顧客ＩＤ、カテゴリ情報、商品ＩＤ、及び送信予定日等が、互いに関連付けて記憶されてもよい。経過観察ＩＤは、通知対象の経過観察を示してもよい。顧客ＩＤは、通知先の顧客を示してもよい。カテゴリ情報は、経過観察の対象となる商品のカテゴリを示してもよい。商品ＩＤは、経過観察の対象となる商品を示してもよい。経過観察の対象となる商品が複数存在する場合、経過観察通知予定ＤＢ１４ｋには、それら複数の商品それぞれの商品ＩＤが記憶されてもよい。送信予定日は、通知の送信が予定される日付を示してもよい。

回答ＤＢ１４ｌには、経過観察のための質問に対する回答に関する回答結果情報が、経過観察ごとに記憶されてもよい。例えば回答ＤＢ１４ｌには、回答結果情報として、経過観察ＩＤ、顧客ＩＤ、質問情報、及び回答情報等が、互いに関連付けて記憶されてもよい。経過観察ＩＤは、回答に対応する経過観察を示してもよい。顧客ＩＤは、回答を行った顧客を示してもよい。質問情報は、回答の対象となる質問を示してもよい。回答情報は、その回答の内容を示してもよい。例えば回答情報は、設問ごとに、質問番号、顧客が選択した選択肢、顧客が入力したテキスト等を含んでもよい。

経過観察結果ＤＢ１４ｍには、医師による経過観察の結果を示す経過観察結果情報が、経過観察ごとに記憶されてもよい。例えば経過観察結果ＤＢ１４ｍには、経過観察結果情報として、経過観察ＩＤ、顧客ＩＤ、処方継続可否情報、及びコメント等が、互いに関連付けて記憶されてもよい。経過観察ＩＤは、医師が行った経過観察を示してもよい。顧客ＩＤは、その経過観察の対象となる顧客を示してもよい。処方継続可否情報は、処方継続の可否判定に関する情報であってもよい。経過観察の対象となる商品が複数存在する場合、経過観察結果ＤＢ１４ｍには、それら複数の商品それぞれの処方継続可否情報が記憶されてもよい。各処方継続可否情報は、商品ＩＤ及び処方継続フラグ等を含んでもよい。商品ＩＤは、処方継続の可否判定の対象となった商品を示してもよい。処方継続フラグは、その商品の処方継続及び処方中止のうちの何れが医師により決定されたかを示してもよい。

記憶部１４には、更に、オペレーティングシステム、ＤＢＭＳ（Database Management System）、サーバプログラム等の各種プログラムが記憶されてもよい。サーバプログラムは、医薬品ＥＣプラットフォームに関する処理をシステム制御部１１に実行させるプログラムであってもよい。サーバプログラムは、例えば、他の装置からネットワークＮＷを介して取得されるようにしてもよいし、磁気テープ、光ディスク、メモリカード等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。

通信部１５は、例えばネットワークインタフェースカード等により構成されている。通信部１５は、ネットワークＮＷを介して、医師端末２、出荷端末３又は顧客端末４と接続し、接続された装置との通信状態を制御する。

［１－５．販売管理サーバのシステム制御部の機能概要］
次に、図８乃至図１９を用いて、販売管理サーバ１におけるシステム制御部１１の機能概要について説明する。図８は、本実施形態に係る販売管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。システム制御部１１は、ＣＰＵ１１ａが、サーバプログラムに含まれる各種プログラムコードを読み出し実行することにより、図８に示すように、販売画面情報送信部１１１、選択商品識別情報取得部１１２、カート情報管理部１１３、診察支援部１１４、注文確定部１１５、発送予定情報管理部１１６、購入商品識別情報取得部１１７、経過観察通知送信部１１８、質問情報送信部１１９、回答情報受信部１２０、使用継続可否情報取得部１２１、経過観察結果情報送信部１２２、及び商品提供制限情報管理部１２３等として機能してもよい。

［１－５－１．商品の選択から発送］
販売画面情報送信部１１１は、医薬品ＥＣプラットフォームに関する各種の画面を顧客端末４に表示させる画面情報を、顧客端末４に送信してもよい。販売画面情報送信部１１１は、例えば画面情報として、画面に相当するウェブページのＨＴＭＬ文書を、顧客端末４へ送信してもよい。或いは、販売画面情報送信部１１１は、例えば画面内に表示されるべき情報を顧客端末４へ送信することで、その画面を表示させてもよい。或いは、販売画面情報送信部１１１は、特定の画面の表示の指示を顧客端末４へ送信するのみであってもよい。顧客端末４は、その顧客端末４に予め記憶されている情報に基づいて、販売管理サーバ１からの指示に応じた画面を表示してもよい。販売画面情報送信部１１１は、主に商品の選択や注文に係わる画面を顧客端末４に表示させてもよい。例えば販売画面情報送信部１１１は、顧客端末４からの要求に応じた商品に関する情報を含む画面の画面情報を送信してもよい。顧客端末４からの要求に応じた商品の例として、顧客により選択された商品、顧客により指定された条件を満たす商品、顧客が要求した画面に掲載されることが予め定められている商品等が挙げられる。顧客端末４からの要求に応じた商品の具体例として、商品選択画面１１００の１つである検索結果画面、商品画面１２００、カート画面１３００、注文申込内容確認画面１４００、注文内容確認画面２１００等が挙げられる。

販売画面情報送信部１１１は、商品の購入形態を選択するための操作が可能な画面を顧客端末４に表示させてもよい。また販売画面情報送信部１１１は、商品の購入数量を選択するための操作が可能な画面を顧客端末４に表示させてもよい。この画面は、例えば商品画面１２００であってもよい。

図９は、商品画面１２００の一例を示す図である。図９に示すように、商品画面１２００には、商品に関する情報、例えば商品名、商品のカテゴリ、商品画像、商品説明、価格等が表示されてもよい。商品画面１２００に情報が表示されている商品が医療用医薬品である場合、商品画面１２００には、注意事項が更に表示されてもよい。例えば、その商品の注文には医師の診察が必要である旨、診察の予約を促す旨等が表示されてもよい。また、商品画面１２００は、購入形態・数量選択ボタン群１２１０、カート追加ボタン１２２０、及びカートアイコン１２３０を更に含んでもよい。購入形態・数量選択ボタン群１２１０は、購入数量及び購入数量を選択するための複数のボタンを含んでもよい。例えば購入形態・数量選択ボタン群１２１０は、定期配送ボタン１２１１、１ヶ月ボタン１２１２、３ヶ月ボタン１２１３、６ヶ月ボタン１２１４等を含んでもよい。定期配送ボタン１２１１は、定期自動購入を選択するためのボタンである。定期自動購入が選択された場合、購入数量は自動的に１ヶ月分に決定されてもよい。１ヶ月ボタン１２１２、３ヶ月ボタン１２１３、及び６ヶ月ボタン１２１４は、何れも逐次購入を選択するためのボタンである。１ヶ月ボタン１２１２は、１ヶ月分の数量の購入を選択するためのボタンである。２ヶ月ボタン１２１３は、１ヶ月分の数量の購入を選択するためのボタンである。３ヶ月ボタン１２１４は、１ヶ月分の数量の購入を選択するためのボタンである。カート追加ボタン１２２０は、商品画面１２００に情報が表示されている商品をカートに追加するためのボタンである。カートアイコン１２３０は、カート画面１３００を表示するために操作可能なアイコンである。

選択商品識別情報取得部１１２は、注文するために顧客により選択された商品を識別する商品ＩＤ及びその顧客の顧客ＩＤを取得してもよい。注文のための商品の選択は、例えばその商品をカートに入れることであってもよい。或いは、注文のための商品の選択は、その商品の注文を申し込むことであってもよい。例えば選択商品識別情報取得部１１２は、図９に示す商品画面１２００が表示において、顧客がカート追加ボタン１２２０を押下する操作を行うと、顧客端末４は、その顧客の顧客ＩＤ及びその商品の商品ＩＤを販売管理サーバ１へ送信してもよい。医薬品識別情報取得部１１１は、送信されてきた顧客ＩＤ及び商品ＩＤを取得してもよい。

カート情報管理部１１３は、各顧客のカート情報を管理してもよい。また、カート情報管理部１１３は、選択商品識別情報取得部１１２により取得された商品ＩＤ及び顧客ＩＤに基づいて、顧客により選択された医薬品をカートに入れる処理を実行してもよい。例えば、カート情報管理部１１３は、取得された商品ＩＤに関連付けられた医療用医薬品フラグを商品ＤＢ１４ｂから検索してもよい。カート情報管理部１１３は、商品ＩＤ、医療用医薬品フラグ、並びに購入形態・数量選択ボタン群１２１０のうち選択されたボタンに対応する購入形態及び数量を含むカート商品情報を生成してもよい。カート情報管理部１１３は、生成されたカート商品情報を、カートＤＢ１４ｃに記憶されたその顧客のカート情報に追加してもよい。

診察支援部１１４は、選択商品識別情報取得部１１２により取得された商品ＩＤにより示される商品が医療用医薬品である場合、顧客（または関係者）と医師との面談として、診察を支援してもよい。診察の支援は、顧客による診察の予約を可能とさせること及びオンライン面接を実現させることのうち、少なくとも何れか一方を含んでもよい。予約可能な診察は、オンライン診察であってもよいし、オフライン診察であってもよい。

診察の予約を可能とするため、診察支援部１１４は、予約申込画面情報を、顧客端末４へ送信してもよい。予約申込画面情報は、予約申込画面を顧客端末４に表示させる情報であってもよい。予約申込画面は、診察の予約を申し込むための操作を受け付け可能な画面であってもよい。この画面は、診察予約画面１５００及び診察予約確認画面１６００のうち、少なくとも何れか一方の画面であってもよい。予約申込画面情報は、例えばＨＴＭＬ文書であってもよいし、画面内に表示されるべき情報であってもよいし、予約申込画面の表示の指示であってもよい。また診察支援部１１４は、予約申込画面に対する顧客の操作に応じて、診察の予約を受け付けてもよい。そして診察支援部１１４は、診察予約情報を生成して、この診察予約情報を診察予約ＤＢ１４ｄに記憶させてもよい。また診察支援部１１４は、診察予約ＤＢ１４ｄに記憶された診察予約情報により示される診察予約に関する情報を、医師端末２へ送信してもよい。これにより、診察支援部１１４は、診察の予約があったことを医師に知らせてもよい。

オンライン診察を実現するため、診察支援部１１４は、顧客端末４と医師端末２とを、診察のための通信を可能に接続させてもよい。例えば通信接続部１１５は、ビデオ通話、ビデオ会議又はウェブ会議等に用いられるプロトコルを用いてもよい。そのようなプロトコルの例として、Ｈ．３２３、ＷｅｂＲＴＣ（Web Real-Time Communication）等が挙げられる。オンライン診察の間、顧客端末４と医師端末２との間でメディアデータ（またはメディアストリーム）が送受信される。メディアデータは、音声を示す音声データ及び映像を示す映像データのうち少なくとも音声データを含んでもよい。映像は、静止画及び動画の何れかであってもよい。メディアデータは顧客端末４と医師端末２との間でピアツーピアにより直接送受信されてもよい。或いは、クライアントサーバ方式で、販売管理サーバ１等のサーバ装置を介してメディアデータが送受信されてもよい。メディアデータを送受信するためのプロトコルとして、例えばＲＴＰ（Real-time Transport Protocol）、ＨＬＳ（HTTP Live Streaming）、ＭＰＥＧ－ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）、ＲＴＭＰ（Real Time Messaging Protocol）等が用いられてもよい。音声データのフォーマットの例として、ＡＡＣ（Advanced Audio Coding）、ＭＰ３（MPEG-1 Audio Layer-3）等が挙げられる。動画データのコンテナフォーマットの例として、ＭＰＥＧ２－ＴＳ、ＭＰ４、ＦＬＶ（Flash Video）等が挙げられる。動画のフォーマットの例として、Ｈ．２６４、ＭＰＥＧ－２等が挙げられる。

診察支援部１１４は、オンライン診察の間、顧客端末４に顧客診察画面２０００を表示させ、医師端末２に医師診察画面を表示させてもよい。医師診察画面には、顧客の情報が表示されてもよい。また医師診察画面には、顧客により選択された商品の情報が表示されてもよい。例えば商品名、購入形態、及び数量が表示されてもよい。また医師診察画面は、医師が処方する商品に関する情報の入力を受け付け可能であってもよい。例えば、処方する商品、購入形態、及び数量の入力が可能であってもよい。顧客の注文内容を変更しない場合、医師は、処方に関する情報を、顧客の選択通りに入力してもよい。医師は、顧客の注文内容の一部又は全部を変更して処方可能であってもよい。注文内容の変更の例として、商品の削除、追加、変更、購入形態の変更、数量の変更等が挙げられる。カード情報管理部１１３は、注文内容の変更を、カートＤＢ１４ｃに反映させてもよい。

診察支援部１１４は、顧客端末４へ、顧客診察画面２０００のＨＴＭＬ文書を送信してもよい。また診察支援部１１４は、医師端末２へ、医師診察画面のＨＴＭＬ文書を送信してもよい。これらのＨＴＭＬ文書は、オンライン診察を実現するための情報を含んでもよい。例えば、これらのＨＴＭＬ文書は、顧客端末４と医師端末２と接続したり、映像及び音声を入出力したり、メディアデータを送受信したりするためのタグやスクリプトが含まれていてもよい。顧客端末４は、スクリプトに従って、販売管理サーバ１を介して医師端末２へその顧客端末４のセッション情報を送信してもよい。セッション情報は、例えば顧客端末４のＩＰアドレス、ポート番号、利用可能なメディアに関する情報、メディアデータの送受信に利用可能な経路に関する情報等を含んでもよい。同様に、医師端末２も、販売管理サーバ１を介して顧客端末４へその医師端末２のセッション情報を送信してもよい。それぞれセッション情報を受信した顧客端末４及び医師端末２は、セッション情報に基づいて互いに接続してもよい。接続された各端末装置は、その端末装置のビデオカメラにより映像を撮影させて映像データを生成し、その端末装置のマイクロホンにより集音させて音声データを生成してもよい。そして、各端末装置は、映像データ及び音声データを接続先の端末装置へ送信する。また、各端末装置は、接続先の端末装置から送信されてきた映像データに従って映像をディスプレイに表示してもよい。また、各端末装置は、接続先の端末装置から送信されてきた音声データに従って音声をスピーカから出力させてもよい。

診察支援部１１４は、顧客により選択された商品が医療用医薬品ではない場合、診察の支援を省略してもよい。この場合、診察は行われなくてもよい。

診察支援部１１４は、顧客により選択された商品が医療用医薬品であっても、その商品について有効に存続している購入権を顧客が有している場合、診察の支援を省略してもよい。この場合も、診察は行われなくてもよい。例えば購入権ＤＢ１４ｇに記憶されている権利状態を参照することで、購入権が有効であるか否かの判定が可能である。

注文確定部１１５は、選択商品識別情報取得部１１２により取得された商品ＩＤにより示される商品の注文を確定させてもよい。例えば、注文確定部１１５は、注文内容確認画面２１００において顧客が注文を確定させる操作を行ったことに応じて、注文情報を生成してもよい。注文確定部１１５は、生成された注文情報を注文ＤＢ１４ｆに記憶させてもよい。ここで、顧客により選択された商品が医療用医薬品である場合、注文確定部１１５は、診察支援部１１４により支援される診察後、注文を確定してもよい。例えば、注文確定部１１５は、オンライン診察のための通信を可能とする顧客端末４と医師端末２との接続後、注文を確定してもよい。顧客により選択された商品が医療用医薬品ではない場合、注文確定部１１５は、診察なくして注文を確定してもよい。また、選択された商品が医療用医薬品であっても、その商品について有効に存続している購入権を顧客が有している場合も、注文確定部１１５は、診察なくして注文を確定してもよい。例えば注文確定部１１５は、診察支援部１１４による顧客端末４と医師端末２との接続を省略して、注文を確定してもよい。

また注文確定部１１５は、確定した注文について、購入代金の決済を実行してもよい。例えば注文確定部１１５は、生成された注文情報に含まれる支払方法情報に基づいて、決済処理を実行してもよい。例えば、支払い方法がクレジットカード決済である場合、支払方法情報は、カード番号、有効期限、クレジットカードの所有者の氏名を含んでもよい。注文確定部１１５は、クレジットカード会社が管理する図示せぬ決済サーバへ、決済要求を送信してもよい。決済サーバは、クレジットカードを用いた決済を承認及び制御するサーバ装置であってもよい。決済要求は、カード番号、有効期限、クレジットカードの所有者の氏名、支払金額、支払先を示す情報を含んでもよい。支払先は、例えば医療機関であってもよいし、医薬品ＥＣプラットフォームを管理する事業者であってもよい。支払先が、医薬品ＥＣプラットフォームを管理する事業者である場合、後日その事業者から医療機関へ、支払代金から手数料を差し引いた額の売上金が支払われてもよい。決済サーバは、決済要求に基づいて、クレジットカードの情報の確認、有効期限の確認、利用限度枠の確認等を行ってもよい。決済サーバは、顧客による代金の支払いが可能であると判定すると、決済を承認し、決済成功を販売管理サーバ１へ送信してもよい。

発送予定情報管理部１１６は、商品の発送予定情報を管理してもよい。例えば発送予定情報管理部１１６は、注文確定部１１５により注文が確定された場合、若しくは決済処理が完了した場合、発送予定情報を生成してもよい。このとき、発送予定情報管理部１１６は、注文された各商品の発送予定商品情報に含まれる発送状態を、「未発送」に設定してもよい。また注文確定部１１５は、発送予定日を、注文日若しくは注文日から所定日数後の日付に設定してもよい。顧客に配達日が指定されている場合、注文確定部１１５は、発送予定日を、その配達日から所定日数前の日付に設定してもよい。発送予定情報管理部１１６は、生成された発送予定情報を、発送予定ＤＢ１４ｈに記憶させてもよい。

発送予定情報管理部１１６は、生成された発送予定情報を、出荷端末３へ送信してもよい。例えば発送予定情報管理部１１６は、発送予定情報を生成したタイミングでその発送予定情報を送信してもよい。或いは発送予定情報管理部１１６は、発送予定日に発送予定情報を送信してもよいし、発送予定日の所定日数前に発送予定情報を送信してもよい。或いは発送予定情報管理部１１６は、発送予定日が、医療機関の従業員により指定された期間内にある発送予定情報を送信してもよい。出荷端末３は、販売管理サーバ１からの発送予定情報に基づいて、商品の発送予定を画面に表示してもよい。例えば出荷端末３は、発送予定の商品の名称、その商品の数量、発送先情報、発送予定日等を表示してもよい。医療機関の従業員は、表示され発送予定に基づいて、商品の発送作業を行ってもよい。

発送予定情報管理部１１６は、商品が顧客に向けて発送されたことを示す発送完了通知を、出荷端末３から受信してもよい。例えば商品の発送作業が完了すると、医療機関の従業員は、その発送日及びその商品の配送伝票に付された伝票番号のうち少なくとも何れか一方を出荷端末３に入力してもよい。出荷端末３は、例えば入力された発送日及び発送予定ＩＤを含む発送完了通知を、販売管理サーバ１へ送信してもよい。発送予定情報管理部１１６は、出荷端末３から受信した発送完了通知に基づいて、配送予定ＤＢ１４ｈに記憶された発送予定情報を更新してもよい。例えば発送予定情報管理部１１６は、発送された各商品の発送予定商品情報に含まれる発送状態を、「発送完了」に変更してもよい。また発送予定情報管理部１１６は、配送予定情報に含まれる発送日を、発送完了通知に含まれる発送日又は発送完了通知を受信した日付に設定してもよい。

購入された商品の中に、定期自動購入が顧客により選択された商品が存在する場合、発送予定情報管理部１１６は、定期配送での２回目以降の配送についての発送予定情報を生成してもよい。例えば発送予定情報管理部１１６は、出荷端末３から発送完了通知を受信することで、或る配送分の商品の発送が完了したことを確認すると、次回の配送についてのみ発送予定情報を生成してもよい。或いは発送予定情報管理部１１６は、最大処方量に相当する期間中に予定されている全ての配送のそれぞれについて、発送予定情報を予め生成してもよい。発送予定情報管理部１１６は、発送予定日を、例えば過去の配送分の商品の発送日及び１回の配送で発送する商品の数量に基づいて設定してもよい。例えば発送予定情報管理部１１６は、前回の配送分の商品の発送日に、商品の数量に相当する期間の長さを加算して、発送予定日を計算してもよい。

顧客により定期自動購入がキャンセルされた場合、発送予定情報管理部１１６は、次回以降の発送をキャンセルしてもよい。例えば発送予定情報管理部１１６は、定期自動購入がキャンセルされた各商品の発送予定情報に含まれる発送状態を、「キャンセル」に変更してもよい。また、発送予定情報管理部１１６は、経過観察の結果、医師により処方中断が決定された商品の次回以降の発送をキャンセルしてもよい。例えば発送予定情報管理部１１６は、出荷端末３へ発送予定情報を送信する際、その発送予定情報から、発送がキャンセルされた商品の発送予定商品情報を削除してもよい。これにより、出荷端末３は、発送がキャンセルされた商品については、発送が予定されている商品として画面には表示しない。そのため、その商品は発送されない。或いは出荷端末３は、発送予定商品情報に含まれる発送状態が「キャンセル」に設定されていることに基づいて、その商品については発送がキャンセルされた旨を画面に表示してもよい。

［１－５－２．経過観察］
購入商品識別情報取得部１１７は、経過観察の対象に定められている複数の商品のうち、購入された商品を識別する購入商品識別情報を取得してもよい。購入商品識別情報は、例えばその商品の商品ＩＤであってもよいし、その商品が属するカテゴリのカテゴリ情報であってもよい。本実施形態においては、購入商品識別情報は商品ＩＤであるものとする。購入商品識別情報取得部１１７は、注文確定部１１５により注文が確定した後、所定のタイミングでその商品ＩＤを取得してもよい。例えば購入商品識別情報取得部１１７は、購入された商品の発送後、注文ＤＢ１４ｆ、購入権ＤＢ１４ｇ若しくは発送予定ＤＢ１４ｈから、商品ＩＤを取得してもよい。また購入商品識別情報取得部１１７は、その商品の発送日を、発送予定ＤＢ１４ｈから取得してもよい。

経過観察通知送信部１１８は、購入商品識別情報取得部１１７により取得された商品ＩＤにより識別される商品について、経過観察通知を送信してもよい。経過観察通知は、商品ＩＤにより識別される商品の経過観察のための質問への回答を、その商品の購入者に促す情報であってもよい。例えば経過観察通知送信部１１８は、その購入者宛ての電子メール又はインスタントメッセージで、経過観察通知を送信してもよい。或いは経過観察通知送信部１１８は、その購入者の顧客端末４へ、プッシュ通知で経過観察通知を送信してもよい。

図１０は、経過観察通知メールの一例を示す図である。経過観察通知メールは、経過観察通知を示す電子メールである。図１０に示すように、経過観察通知メール３１００は、商品名３１１０、促し情報３１２０、及び回答ボタン３１３０等を含んでもよい。商品名３１１０は、経過観察の対象となる商品を示す。一の経過観察で、１又は複数の商品が経過観察の対象となってもよい。促し情報３１２０は、経過観察のための質問への回答を促すテキストであってもよい。例えば促し情報３１２０として、「安全に服用するため定期的に体調を確認しましょう。」、及び、「問題がある場合、下記フォームより詳細を教えてください。」等のテキストが表示されてもよい。なお、促し情報３１２０は、経過観察通知メール３１００に含まれる情報であれば、如何様な情報であってもよい。促し情報３１２０はテキストに限定されない。例えば促し情報３１２０は、商品名３１１０及び回答ボタン３１３０のうち少なくとも何れか一方を含んでもよい。回答ボタン３１３０は、質問シート画面を顧客端末４に表示させるために操作可能なボタンである。質問シート画面は、質問が表示されるとともに、その質問に対する回答の入力を受け付け可能な画面であってもよい。

経過観察通知送信部１１８は、例えば経過観察期間長情報に基づいて、経過観察通知を送信するタイミングを決定してもよい。経過観察期間長情報は、経過観察の時期までの期間の長さを示す経過観察期間長を含む情報であってもよい。また経過観察期間長情報は、経過観察の対象に定められている複数の商品のそれぞれに対応する経過観察期間長を特定可能な情報であってもよい。これは、或る商品が指定された場合、その商品に対応する経過観察期間長を取得することが可能であることを意味するものであってもよい。必ずしも、経過観察期間長が商品ごとに定義されているとは限らない。経過観察期間長情報は、例えばデータベース又はテーブルであってもよい。例えば経過観察期間長情報は、商品ＤＢ１４ｂと経過観察期間ＤＢ１４ｉとの組み合わせであってもよい。商品ＤＢ１４ｂに記憶されている商品ＩＤとカテゴリ情報との組み合わせから、購入された商品のカテゴリを特定することができる。経過観察期間ＤＢ１４ｉに記憶されているカテゴリ情報と経過観察期間長との組み合わせから、そのカテゴリに対応する経過観察期間長を特定することができる。なお、商品ごとに経過観察期間長が定められる場合、経過観察期間ＤＢ１４ｉには、商品ごとに、商品ＩＤと経過観察期間長とが関連付けて記憶されればよい。商品ごと又は商品のカテゴリごとに、経過観察期間長が定義可能であるので、購入された商品に応じたタイミングで、経過観察通知を送信することができる。

経過観察通知送信部１１８は、商品の購入に関連する基準日から、その商品に対応する経過観察期間長の期間の経過後に、経過観察通知を送信してもよい。商品の購入に関連する基準日は、例えば商品の購入行為又は購入手続きに係わる日であってもよい。例えば基準日は、顧客が商品を購入したとみなされる日付、顧客による商品の購入意思が確定したとみなされる日付、または商品の購入若しくは注文の申し込みが受け付けられた日付であってもよい。基準日の例として、注文の確定日、決済の完了日、商品の発送日、及び商品の配達日等が挙げられる。本実施形態においては、基準日は発送日であるものとする。

１回の注文で複数の商品が購入される場合がある。経過観察通知送信部１１８は、それら複数の商品の中で、経過観察通知の送信タイミング（または経過観察期間長）が互いに同一である商品ごとに、経過観察通知を送信してもよい。例えば経過観察通知送信部１１８は、商品のカテゴリごとに、経過観察通知を送信してもよい。

後述するように、経過観察のための質問は、商品によって異なってもよい。１回の注文で複数の商品が購入された場合、経過観察通知送信部１１８は、購入された複数の商品の中で、互いに質問が同一である商品ごとに、経過観察通知を送信してもよい。或いは、経過観察通知送信部１１８は、質問が同一であるか否かに関係なく、購入された複数の商品について、まとめて経過観察通知を送信してもよい。購入された商品の中に、互いに質問が同一であるものの、経過観察通知を送信するタイミング（または経過観察期間長）が互いに異なる商品が存在する場合がある。この場合、経過観察通知送信部１１８は、送信のタイミングが同一である商品ごとに、経過観察通知を送信してもよい。或いは経過観察通知送信部１１８は、それらの商品の経過観察通知を送信するタイミングをマージしてもよい。経過観察通知送信部１１８は、マージされたタイミングで、それらの商品について、まとめて経過観察通知を送信してもよい。

経過観察期間長は、最大処方量に相当する期間の長さを超えて定義されていてもよい。最大処方量に相当する量の商品が実際に購入された場合、その商品に設定された購入権は消滅する。購入権が消滅した商品を顧客が再購入するには、医師の診察を受ける必要がある。この場合の購入は、特別な継続購入であるとみなされてもよい。経過観察通知送信部１１８は、商品の初回購入の際の商品の発送日から経過観察期間長の期間の経過後に、経過観察通知を送信してもよい。或いは、経過観察期間長は、最大処方量に相当する期間の長さを超えて定義されていなくてもよい。この場合、購入権が消滅した商品の再購入は、初回購入とみなされてもよい。経過観察通知送信部１１８は、２回目の初回購入の際の商品の発送日から、１回目の経過観察についての経過観察期間長の期間の経過後に、経過観察通知を送信してもよい。

図１１（ａ）、図１１（ｂ）、及び図１１（ｃ）は、それぞれ商品Ａ、Ｂ、及びＣについての経過観察通知の送信タイミングの例を示す図である。図１１（ａ）に示すように、商品Ａが購入された場合、１ヶ月周期で経過観察通知が送信されてもよい。例えば、発送日から１ヶ月後に１回目の経過観察通知が送信される。その後、発送日から２ヶ月後に２回目の経過観察通知が送信される。その後、発送日から３ヶ月後に３回目の経過観察通知が送信される。その後、発送日から４ヶ月後に４回目の経過観察通知が送信される。同様に、５回目以降の経過観察通知が送信される。図１１（ｂ）に示すように、商品Ｂが購入された場合、２ヶ月周期で経過観察通知が送信されてもよい。例えば、発送日から２ヶ月後に１回目の経過観察通知が送信される。その後、発送日から４ヶ月後に２回目の経過観察通知が送信される。その後、発送日から６ヶ月後に３回目の経過観察通知が送信される。図１１（ｃ）に示すように、商品Ｃが購入された場合、最初の３ヶ月は、１ヶ月周期で経過観察通知が送信されてもよい。例えば、発送日から１ヶ月後に１回目の経過観察通知が送信される。その後、発送日から２ヶ月後に２回目の経過観察通知が送信される。その後、発送日から３ヶ月後に３回目の経過観察通知が送信される。その後、発送日から６ヶ月後に４回目の経過観察通知が送信される。

購入形態が逐次購入である場合、経過観察通知送信部１１８は、発送日から丁度Ｎヶ月後（Ｎは１以上の整数）に経過観察通知を送信するのではなく、Ｎヶ月後から所定日数前の日に、経過観察通知を送信してもよい。或いは経過観察通知送信部１１８は、Ｎヶ月後から所定日数後の日に、経過観察通知を送信してもよい。これにより、経過観察通知の通知タイミングを、継続購入による商品の発送のタイミングとずらすことができる。

経過観察通知送信部１１８は、購入された商品の最大処方量のうち、既購入量に相当する期間中にのみ、経過観察通知を送信してもよい。例えば、逐次購入且つ初回購入にて、商品Ｃが２ヶ月分購入されたとする。この場合、経過観察通知送信部１１８は、初回購入の発送日から１ヶ月後及び２ヶ月後にのみ、経過観察通知を送信してもよい。その後、継続購入にて、商品Ｃが４ヶ月分購入されたとする。この場合、経過観察通知送信部１１８は、初回購入の発送日から３ヶ月後及び６ヶ月後に、経過観察通知を送信してもよい。

質問情報送信部１１９は、経過観察通知送信部１１８による経過観察通知の送信後に、経過観察通知の送信先の購入者が利用する顧客端末４からの要求に応じて、経過観察のための質問を示す質問情報を、その顧客端末４へ送信してもよい。質問情報送信部１１９は、質問シート画面情報を送信してもよい。質問シート画面は、質問シート画面を顧客端末４に表示させる情報であってもよい。質問シート画面情報は、質問情報を含んでもよい。質問シート画面情報は、ＨＴＭＬ文書であってもよいし、質問シート画面に表示されるべき情報であってもよいし、質問シート画面の表示の指示であってもよい。質問情報送信部１１９は、例えば経過観察通知メール３１００の回答ボタン３１３０が操作されたことに応じて、質問情報を送信してもよい。回答ボタン３１３０が操作されると、顧客端末４は、販売管理サーバ１へ質問シート画面要求を送信してもよい。質問シート画面要求は、例えば経過観察の対象となる商品の商品ＩＤ若しくはその商品のカテゴリを示すカテゴリ情報を含んでもよい。

質問情報送信部１１９は、例えば商品質問情報に基づいて、顧客端末４に送信する質問情報を決定してもよい。商品質問情報は、経過観察の対象に定められている複数の商品のそれぞれに対応する質問を特定可能な情報であってもよい。これは、或る商品が指定された場合、その商品に対応する質問情報を取得することが可能であることを意味するものであってもよい。必ずしも、質問情報が商品ごとに定義されているとは限らない。商品質問情報は、質問情報自体を含んでもよい。或いは商品質問情報は、質問情報を識別するための識別情報を含んでもよい。商品質問情報とは別に、記憶部１４には、各識別情報に関連付けて質問情報が記憶されてもよい。商品質問情報は、例えばデータベース又はテーブルであってもよい。例えば商品質問情報は、商品ＤＢ１４ｂと質問情報ＤＢ１４ｊとの組み合わせであってもよい。商品ＤＢ１４ｂに記憶されている商品ＩＤとカテゴリ情報との組み合わせから、購入された商品のカテゴリを特定することができる。質問情報ＤＢ１４ｊに記憶されているカテゴリ情報と質問情報との組み合わせから、そのカテゴリに対応する質問情報を特定することができる。なお、商品ごとに質問情報が定められる場合、質問情報ＤＢ１４ｊには、商品ごとに、商品ＩＤと質問情報とが関連付けて記憶されればよい。商品ごと又は商品のカテゴリごとに、質問情報が定義可能であるので、購入された商品に応じた質問を、購入者に提示することができる。

図１２は、経過観察のための質問の内容の例を示す図である。例えば図１２に示すように、商品のカテゴリとして、ピル、美容内服薬、ダイエット薬、及び外用薬が少なくとも存在するとする。ピルについての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、消化器症状の有無を確認するための質問、不正出血の有無を確認するための質問、体重増減の有無を確認するための質問、高血圧の有無を確認するための質問、美容内服薬の服用の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。美容内服薬についての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、ピルの服用の有無を確認するための質問、肌の状態の問題の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。ダイエット薬についての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、消化器症状の有無を確認するための質問、体重増減の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。外用薬についての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、肌の状態の問題の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。

質問情報が互いに異なる複数の商品が、一の経過観察の対象となってもよい。この場合、質問情報送信部１１９は、それらの商品の質問情報をマージしてもよい。質問情報送信部１１９は、マージされた質問情報を、顧客端末４へ送信してもよい。或いは、一の経過観察の対象が、質問情報が互いに同一である商品となるように、経過観察通知送信部１１８又は質問情報送信部１１９が機能してもよい。

図１３は、質問シート画面の一例を示す図である。図１３に示すように、質問シート画面３２００は、１又は複数の入力フォーム３２１０、及び回答ボタン３２２０等を含んでもよい。各入力フォーム３２１０は、一の質問に対する回答を入力するためのフォームであってもよい。各入力フォーム３２１０は、例えば質問３２１０及びラジオボタン群３２１２等を含んでもよい。質問３２１０は、その質問を示すテキストである。ラジオボタン群３２１２は、その質問に対する回答を選択するために操作可能な複数のラジオボタンを含んでもよい。少なくとも一の入力フォーム３２１０は、回答入力欄３２１３を更に含んでもよい。例えば回答として、ラジオボタン群３２１２により「はい」及び「いいえ」の何れかが選択可能である場合、回答入力欄３２１３が表示されてもよい。回答入力欄３２１３は、質問に対する回答が「はい」である場合に具体的な回答内容を示すテキストを入力するための領域であってもよい。回答ボタン３２２０は、質問シート画面に入力された回答を販売管理サーバ１へ送信するために操作可能なボタンであってもよい。

回答情報受信部１２０は、質問情報送信部１１９により送信された質問情報により示される質問に対する回答を示す回答情報を、顧客端末４から受信してもよい。例えば、質問シート画面３２００の回答ボタン３２２０が操作されると、顧客端末４は回答情報を販売管理サーバ１へ送信してもよい。回答情報受信部１２０は、顧客端末４から受信された回答情報を、回答ＤＢ１４ｌに記憶させてもよい。

使用継続可否情報取得部１２１は、回答情報受信部１２０により受信された回答情報に基づいて、使用継続可否情報を取得してもよい。使用継続可否情報は、購入された商品の使用継続の可否を示す情報であってもよい。使用継続可否情報は、例えば処方継続可否情報であってもよい。処方継続可否情報は、購入された商品の処方の継続の可否を示す情報であってもよい。

使用継続可否情報取得部１２１は、例えば回答情報を医師端末２へ送信することにより、処方継続可否情報を取得してよい。例えば医師端末２は、回答情報を画面に表示させてもよい。医師は、画面に表示された回答情報に基づいて、処方継続の可否を決定してもよい。医師は、決定した処方継続の可否を医師端末２に入力してもよい。使用継続可否情報取得部１２１は、入力された可否を示す処方継続可否情報を、医師端末２から受信してもよい。なお、システム制御部１１は、図示せぬ使用継続可否情報受信部として機能してもよい。使用継続可否情報受信部は、処方継続可否情報を医師端末２から受信してもよい。

使用継続可否情報取得部１２１は、回答情報を医師端末２へ送信するとともに、経過観察画面情報を、医師端末２へ送信してもよい。経過観察画面情報は、医師端末２に経過観察画面を表示させる情報であってもよい。経過観察画面は、医師による経過観察の結果を入力するための画面であってもよい。経過観察画面は、購入された商品の処方継続の可否の選択を受け付け可能な画面であってもよい。経過観察画面情報は、ＨＴＭＬ文書であってもよいし、経過観察画面に表示されるべき情報であってもよいし、経過観察画面の表示の指示であってもよい。使用継続可否情報取得部１２１は、送信される経過観察画面情報に、回答情報を含めてもよい。この場合、経過観察画面に回答が表示されてもよい。

図１４は、経過観察画面の一例を示す図である。図１４に示すように、経過観察画面３３００は、質問回答情報３３１０、１又は複数の入力フォーム３３２０、コメント入力欄３３３０、及び送信ボタン３３４０等を含んでもよい。質問回答情報３３１０は、顧客に提示された質問及び顧客が入力した回答を示してもよい。各入力フォーム３３２０は、一の商品に対する処方継続の可否を入力するためのフォームであってもよい。図１４に示す例では、商品ＡＡＡＡＡＡ、ＢＢＢＢＢＢ、及びＣＣＣＣＣＣのそれぞれについて、入力フォーム３３２０が表示されている。各入力フォーム３３２０は、経過観察の対象となる商品の商品名、購入量等を含んでもよい。また各入力フォーム３３２０は、処方継続選択メニュー３３２１を含んでもよい。処方継続選択メニュー３３２１は、処方継続及び処方中止のうち、医師が決定した対処を選択するために操作可能なプルダウンメニューであってもよい。コメント入力欄３３３０は、顧客に対するコメントを示すテキストを入力するための領域であってもよい。送信ボタン３３４０は、経過観察結果情報を、販売管理サーバ１へ送信するためのボタンであってもよい。経過観察結果情報は、経過観察の結果を示す情報であってもよい。経過観察結果情報は、処方継続選択メニュー３３２１にて選択された処方継続の可否を示す処方継続可否情報を含んでもよい。

図１５は、処方継続の可否の入力後における経過観察画面の一例を示す図である。図１５に示すように、商品ＡＡＡＡＡについては、処方中止が選択されている。商品ＢＢＢＢＢＢ及びＣＣＣＣＣＣについては、処方継続が選択されている。コメント入力欄３３３０には、商品ＡＡＡＡＡＡの処方が中止される理由が入力されている。

経過観察結果情報送信部１２２は、経過観察結果情報を、商品の購入者に向けて送信してもよい。経過観察結果情報は、経過観察の結果を示す情報であってもよい。経過観察結果は、使用継続可否情報取得部１２１により取得された使用継続可否情報により示される使用継続の可否を含んでもよい。経過観察結果情報送信部１２２は、その購入者宛ての電子メール又はインスタントメッセージで、経過観察結果情報を送信してもよい。或いは経過観察結果情報送信部１２２は、その購入者の顧客端末４へ、プッシュ通知で経過観察結果情報を送信してもよい。或いは経過観察結果情報送信部１２２は、その顧客端末４からの要求に応じて、経過観察結果を含む画面を顧客端末４に表示させる画面情報を、その顧客端末４へ送信してもよい。

図１６（ａ）乃至図１６（ｃ）は、経過観察結果メールの一例を示す図である。経過観察結果メールは、経過観察結果を示す電子メールである。図１６（ａ）は、医師により処方継続が決定された場合の経過観察結果メールの一例を示す。図１６（ａ）に示すように、経過観察結果メール３４００は、使用継続可情報３４１０、コメント３４２０、及び診察予約リンク３４３０等を含んでもよい。使用継続可情報３４１０は、商品の使用の継続が可能であることを示すテキストであってもよい。例えば、使用継続可情報３４１０として、「お薬の服用・使用には問題ありません。」等が表示されてもよい。コメント３４２０は、医師により入力されたコメントを示す。診察予約リンク３４３０は、オンライン診察の予約を行うために操作可能なリンクであってもよい。顧客が診察予約リンク３４３０を選択すると、顧客端末４は、例えば診察予約画面１５００を表示してもよい。図３に示すように、顧客は、オンライン診察を予約して、その後オンライン診察を受けることができる。この状態においては、注文される商品は選択されていない。オンライン診察において、医師が商品を決定してもよい。

図１６（ｂ）は、逐次購入により購入された商品について、医師により処方継続中止が決定された場合の経過観察結果メールの一例を示す。図１６（ｂ）において、図１６（ａ）と同一の要素については同一の符号が付されている。図１６（ｂ）に示すように、経過観察結果メール３４００は、使用中止情報３４４０、商品名３４５０、コメント３４２０、及び診察予約リンク３４３０等を含んでもよい。使用中止情報３４４０は、商品の使用の中止を促すことを示すテキストであってもよい。例えば、使用中止情報３４４０として、「お薬の服用を中止してください。」等が表示されてもよい。商品名３４５０は、使用中止の対象となる商品の名称を示す。

図１６（ｃ）は、定期自動購入により購入された商品について、医師により処方継続中止が決定された場合の経過観察結果メールの一例を示す。図１６（ｃ）において、図１６（ｂ）と同一の要素については同一の符号が付されている。図１６（ｃ）に示すように、経過観察結果メール３４００は、使用中止情報３４４０、定期配送キャンセル情報３４６０、商品名３４５０、コメント３４２０、及び診察予約リンク３４３０等を含んでもよい。定期配送キャンセル情報３４６０は、処方中止が決定された商品について、顧客への定期配送がキャンセルされることを示すテキストであってもよい。例えば、定期配送キャンセル情報３４６０として、「定期配送をご利用中の場合、医師の判断により、次回分以降は決済・発送をキャンセルいたします。」等が表示されてもよい。

［１－５－３．商品の提供制限］
商品提供制限情報管理部１２３は、商品提供制限情報を管理してもよい。商品提供制限情報は、顧客に対して商品の提供が制限されるか否かを、顧客と商品との組み合わせごとに特定可能な情報であってもよい。商品提供制限情報から特定可能な提供の制限は、経過観察で使用中止若しくは処方中止が決定された商品の提供を制限することであってもよい。商品の提供が制限される顧客とその顧客に提供が制限される商品との組み合わせを、提供制限組み合わせという。商品の提供が制限されない顧客とその顧客に提供が制限されない商品との組み合わせを、提供非制限組み合わせという。商品提供制限情報は、各提供制限組み合わせを示す情報を含んでもよい。商品ＤＢ１４ｂから、医薬品ＥＣプラットフォームで取り扱われている全ての医療用医薬品を特定可能である。また、会員ＤＢ１４ａから、医薬品ＥＣプラットフォームを利用可能な全ての顧客特定可能である。従って、商品提供制限情報から提供制限組み合わせを特定可能であれば、必然的に、提供非制限組み合わせを特定可能である。或いは、商品提供制限情報は、各提供非制限組み合わせを示す情報を含んでもよい。前述と同様の理由により、提供非制限組み合わせが特定可能であれば、必然的に、提供制限組み合わせも特定可能である。商品提供制限情報は、顧客と商品との全ての組み合わせについての情報を含まなくてもよい。例えば商品提供制限情報は、各提供制限組み合わせに関する情報のみを含んでもよいし、各提供非制限組み合わせに関する情報のみを含んでもよい。商品提供制限情報は、例えばデータベース又はテーブルであってもよい。

商品提供制限情報は、例えば購入権ＤＢ１４ｇであってもよい。購入権ＤＢ１４ｇに記憶された各購入権情報は、過去に設定された購入権を示してもよい。購入権情報に含まれる顧客ＩＤは、その購入権を有する顧客を示してもよい。購入権情報に含まれる商品ＩＤは、その購入権が設定された商品を示してもよい。購入権情報に含まれる権利状態は、商品の提供が制限されるか否かを示してもよい。例えば、「有効」を示す権利状態は、商品の提供が制限されないことを示してもよい。「停止」を示す権利状態は、商品の提供が制限されることを示してもよい。また「消滅」を示す権利状態も、商品の提供が制限されることを示してもよい。商品提供制限情報管理部１２３は、注文確定部１１５により注文が確定される場合、注文された各商品について、購入権情報を生成してもよい。このとき、商品提供制限情報管理部１２３は、購入権情報に含まれる権利状態を、「有効」に設定してもよい。

商品提供制限情報管理部１２３は、使用継続可否情報取得部１２１により取得された使用継続可否情報が使用継続の不可を示す場合、商品提供制限情報を変更又は更新してもよい。これにより、商品提供制限情報管理部１２３は、使用継続不可とされた商品の購入者に対してその商品の提供が制限されることが商品提供制限情報から特定可能にしてもよい。例えば商品提供制限情報管理部１２３は、その購入者とその商品との組み合わせが提供制限組み合わせであることを直接示す情報を、商品提供制限情報に追加してもよい。或いは商品提供制限情報管理部１２３は、商品提供制限情報から、その購入者とその商品との組み合わせが提供非制限組み合わせであることを示す情報を削除してもよい。或いは商品提供制限情報管理部１２３は、商品提供制限情報に含まれるその購入者とその商品との組み合わせを提供非制限組み合わせとして示す情報を、その購入者とその商品との組み合わせを提供制限組み合わせとして示す情報に変更してもよい。

図１７は、購入権ＤＢ１４ｇの更新例を示す図である。商品提供制限情報が購入権ＤＢ１４ｇであるとする。例えば医師が、顧客Ｘに対する商品Ａの処方中止を決定したとする。この場合、図１７に示すように、使用継続可否情報取得部１２１は、処方中止を示す処方継続可否情報を取得する。この場合、商品提供制限情報管理部１２３は、顧客Ｘと商品Ａとの組み合わせを示す購入権情報に含まれる権利状態を、「有効」から「停止」に変更してもよい。

商品の提供の制限は、特定の条件を顧客が満たすことを条件に、その商品の購入が可能となることであってもよい。商品の購入が制限されていない間、顧客は、その条件を満たす必要なく、商品の購入が可能であってもよい。特定の条件は、例えば医師の診察を受けること若しくは医師からその商品を処方してもらうことであってもよい。医師がその商品を処方することで、顧客はその商品についての新たな購入権を取得可能であってもよい。

例えば、診察支援部１１４が、選択商品識別情報取得部１１２により取得された顧客ＩＤにより示される顧客に対して選択商品識別情報取得部１１２により取得された商品ＩＤにより示される商品の提供が制限されることが商品提供制限情報から特定される場合、その顧客に対する医師の診察を支援してもよい。この場合、注文確定部１１５は、その診察後に、注文を確定してもよい。一方、診察支援部１１４は、その顧客に対してその商品の提供が制限されないことが商品提供制限情報から特定される場合、その顧客に対する医師の診察を支援しなくてもよい。この場合、注文確定部１１５は、その診察なくして、注文を確定してもよい。

前述したように、顧客により選択された商品が医療用医薬品ではあるものの、その商品について有効に存続している購入権を顧客が有している場合、診察支援部１１４は、診察の支援を省略してもよく、注文確定部１１５は、その診察なくして、注文を確定してもよい。これは、商品の提供が制限されていないことを示す。診察支援部１１４及び注文確定部１１５のうち少なくとも何れか一方は、購入権情報に含まれる権利状態が「有効」である場合、診察なくして注文を確定可能なように機能してもよい。例えば図３に示す画面遷移例において、カート画面１３００の表示後、顧客端末４が注文内容確認画面２１００を表示するように、注文確定部１１５が機能してもよい。その一方で、顧客により選択された商品が医療用医薬品であり、且つ、その商品について有効に存続している購入権を顧客が有していない場合、診察支援部１１４は、診察を支援してもよく、注文確定部１１５は、その診察後、注文を確定してもよい。これは、商品の提供が制限されていることを示す。診察支援部１１４及び注文確定部１１５のうち少なくとも何れか一方は、購入権情報に含まれる権利状態が「停止」である場合、顧客が診察を受けたことを条件として注文を確定可能なように機能してもよい。例えば図３に示す画面遷移例において、カート画面１３００の表示後、顧客端末４が注文申込内容確認画面１４００を表示するように、診察支援部１１４が機能してもよい。その後、例えば診察予約画面１５００、診察予約確認画面１６００、診察予約受付完了画面１７００、問診票画面１８００、診察待機画面１９００、及び顧客診察画面２０００の順で、これらの画面が表示されるように、診察支援部１１４が機能してもよい。その後、注文内容確認画面２１００が表示されるように、注文確定部１１５が機能してもよい。

図１８は、商品の提供の制限例を示す図である。例えば顧客は、或る商品を１ヶ月分購入しようとする。この時点での購入権ＤＢ１４ｇには、その顧客とその商品との組み合わせを示す購入権情報は記憶されていない。そのため、顧客は、医師の診察を受ける必要がある。診察を受けた上で顧客が商品を購入すると、商品提供制限情報管理部１２３は、購入権ＤＢ１４ｇに購入権情報を記憶させてもよい。このときの購入権状態は「有効」に設定される。経過観察が１ヶ月ごとに実施されるとする。初回購入から１ヶ月後の経過観察では、使用継続が可能であることが決定された。従って、権利状態は「有効」のままである。また顧客は、初回購入から１ヶ月後に、商品を２ヶ月分購入する。権利状態は「有効」であるので、顧客は、医師の診察を受ける必要はない。初回購入から１ヶ月後の経過観察では、使用中止が決定された。従って、商品提供制限情報管理部１２３は、権利状態を「停止」に変更する。顧客は、初回購入から３ヶ月後に、商品を３ヶ月分購入する。権利状態は「停止」であるので、顧客は、医師の診察を受ける必要がある。

購入形態が定期自動購入である場合の商品の提供の制限は、定期配送での次回以降の配送をキャンセルすることであってもよい。例えば、発送予定情報管理部１１６は、使用継続不可が決定された商品の購入者に対してその商品の提供が制限されることが特定可能に、商品提供制限情報が商品提供制限情報管理部１２３により変更された場合、発送予定情報管理部１１６は、その購入者に対するその商品の次回以降の発送をキャンセルしてもよい。発送予定情報管理部１１６は、例えば商品提供制限情報管理部１２３により権利状態が「停止」に変更された顧客と商品との組み合わせに対応する次回以降の配送についての発送予定情報について、発送状態を「キャンセル」に変更してもよい。

図１９は、定期自動購入における商品の提供の制限例を示す図である。例えば顧客は、或る商品を定期自動購入で購入しようとする。この時点での購入権ＤＢ１４ｇには、その顧客とその商品との組み合わせを示す購入権情報は記憶されていない。そのため、顧客は、医師の診察を受ける必要がある。診察を受けた上で顧客が商品を購入すると、商品提供制限情報管理部１２３は、購入権ＤＢ１４ｇに購入権情報を記憶させてもよい。このときの購入権状態は「有効」に設定される。そして、例えば１ヶ月分の商品を含む定期配送が発送される。経過観察が１ヶ月ごとに実施されるとする。初回購入から１ヶ月後の経過観察では、使用継続が可能であることが決定された。従って、権利状態は「有効」のままである。そのため、初回購入から１ヶ月後に商品は発送される。初回購入から２ヶ月後の経過観察では、使用継続が可能であることが決定された。従って、権利状態は「有効」のままである。そのため、初回購入から２ヶ月後に商品は発送される。初回購入から３ヶ月後の経過観察では、使用中止が決定された。従って、商品提供制限情報管理部１２３は、権利状態を「停止」に変更する。権利状態は「停止」であるので、初回購入から３ヶ月後以降の商品の発送はキャンセルされる。

定期自動購入で購入された商品についての商品提供制限情報は、例えば購入権ＤＢ１４ｇであってもよいし、発送予定ＤＢ１４ｈであってもよい。商品提供制限情報が発送予定ＤＢ１４ｈである場合の商品提供制限情報管理部１２３は、発送予定情報管理部１１６であってもよい。発送予定ＤＢ１４ｈには、定期自動購入で購入された商品の次回の配送についての発送予定を示す発送予定情報が記憶される。発送予定情報に含まれる各商品についての発送状態は、その商品の提供が制限されるか否かを示してもよい。例えば、「未発送」を示す発送状態は、商品の提供が制限されないことを示してもよい。「キャンセル」を示す発送状態は、商品の提供が制限されることを示してもよい。或いは、商品提供制限情報管理部１２３は、使用中断が決定された商品の発送予定商品情報を、発送予定情報から削除してもよい。これにより、その商品の提供が制限されてもよい。

顧客端末４から販売管理サーバ１へ回答情報が送信されてこなかった場合、経過観察の対象となった商品の提供は制限されなくてもよい。また回答情報の送信期限が設定されてもよい。この送信期限までに顧客端末４から回答情報が送信されてこなかった場合、商品の提供は制限されなくてもよい。医師端末２から販売管理サーバ１へ処方継続可否情報が送信されてこなかった場合、経過観察の対象となった商品の提供は制限されなくてもよい。また処方継続可否情報の送信期限が設定されてもよい。この送信期限までに医師端末２から処方継続可否情報が送信されてこなかった場合、商品の提供は制限されなくてもよい。

システム制御部１１は、商品提供制限情報を管理することなく若しくは商品提供制限情報を参照することなく、顧客に対して商品の提供を制限するための処理を行ってもよい。例えばシステム制御部１１は、使用継続可否情報取得部１２１により取得された使用継続可否情報が使用継続可を示す場合、診察を省略して注文を確定させるか、または次回の定期配送をキャンセルしなくてもよい。システム制御部１１は、使用継続可否情報取得部１２１により取得された使用継続可否情報が、使用継続の不可を示す場合、診察後に注文を確定させるか、または次回の定期配送をキャンセルしてもよい。

［１－６．通信システムの動作］
次に、通信システムＳの動作について、図２０乃至図２６を用いて説明する。図２０乃至図２６は、本実施形態に係る通信システムＳの処理例を示すシーケンス図である。処理の順序は、図２０乃至図２６に示される順序に限定されない。また、図２０乃至図２６に示されるステップのうち少なくとも一のステップは実行されなくてもよい。販売管理サーバ１のシステム制御部１１は、サーバプログラムに係る各種プログラムコードに従って、図２０乃至図２６に示される販売管理サーバ１の処理を実行してもよい。

例えば、顧客端末４は、商品選択画面１１００から顧客が何れかの商品を選択することに応じて、商品画面１２００を表示する。顧客は、商品画面１２００で購入形態・数量選択ボタン群１２１０に含まれる何れかのボタンを操作して、購入形態及び数量を選択する。そして図２０に示すように、顧客は、カート追加ボタン１２２０を押下する（ステップＳ１０１）。この操作を検出した顧客端末４は、販売管理サーバ１へカート追加要求を送信する（ステップＳ１０２）。カート追加要求は、その顧客の顧客ＩＤ、選択された商品の商品ＩＤ、並びに選択された購入形態及び数量を含んでもよい。カート追加要求を受信した販売管理サーバ１のカート情報管理部１１３は、その顧客の顧客ＩＤに関連付けてカートＤＢ１４ｃに記憶されているカート情報を更新する（ステップＳ１０３）。例えば、販売管理サーバ１は、カート追加要求に含まれる商品ＩＤに関連付けられた医療用医薬品フラグを、商品ＤＢ１４ｂから取得してもよい。カート情報管理部１１３は、商品ＩＤ，医療用医薬品フラグ、購入形態及び数量を含むカート商品情報を生成してもよい。カート情報管理部１１３は、生成されたカート商品情報をカート情報に追加してもよい。

その後、顧客は、例えば商品画面１２００でカートアイコン１２３０を選択する（ステップＳ１０４）。この操作を検出した顧客端末４は、カート画面要求を販売管理サーバ１へ送信する（ステップＳ１０５）。カート画面要求を受信した販売管理サーバ１の販売画面情報送信部１１１は、カート画面１３００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ１０６）。このとき、販売画面情報送信部１１１は、その顧客のカート情報に基づいて、現在カートに入っている商品の一覧を生成してもよい。販売画面情報送信部１１１は、この一覧を含むＨＴＭＬ文書を生成してもよい。顧客端末４は、このＨＴＭＬ文書に基づいて、カート画面１３００を表示する。

顧客端末４により表示されたカート画面１３００において、顧客は、次の手続きに進むための操作を行う（ステップＳ１０７）。この操作を検出した顧客端末４は、販売管理サーバ１へ注文手続進行要求を送信する（ステップＳ１０８）。注文手続進行要求を受信した販売管理サーバ１の注文確定部１１５は、その顧客のカートに入っている商品は医療用医薬品を含むか否かを判定する（ステップＳ１０９）。例えば、注文確定部１１５は、その顧客のカート情報に含まれる少なくとも一つのカート商品情報の医療用医薬品フラグがＴＲＵＥに設定されている場合、カートに入っている商品は医療用医薬品を含むと判定してもよい。カートに入っている商品が医療用医薬品を含む場合（ステップＳ１０９：ＹＥＳ）、注文確定部１１５は、医療用医薬品である商品についてその顧客が有効に存続している購入権を有しているか否かを判定する（ステップＳ１１０）。例えば、注文確定部１１５は、その商品の商品ＩＤとその顧客の顧客ＩＤとの組み合わせを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権ＤＢ１４ｇから検索してもよい。注文確定部１１５は、該当する購入権情報がない場合、顧客が有効に存続している購入権を有していないと判定してもよい。注文確定部１１５は、検索された購入権情報に含まれる権利状態が「有効」である場合、顧客が有効に存続している購入権を有していると判定してもよい。注文確定部１１５は、検索された購入権情報に含まれる権利状態が「停止」又は「消滅」である場合、顧客が有効に存続している購入権を有していないと判定してもよい。カート商品情報が診察対象フラグを含む場合、注文確定部１１５は、その診察対象フラグに基づいて、その顧客のカートに入っている商品は、注文の確定のために医師の診察が必要な商品を含むか否かを判定してもよい。カートに入っている商品が、医師の診察が必要な商品を含む場合、処理はステップＳ１１０に進んでもよい。

顧客が有効に存続している購入権を有していない場合（ステップＳ１１０：ＮＯ）、診察支援部１１４は、注文申込内容確認画面１４００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ１１１）。このとき、診察支援部１１４は、その顧客のカート情報に基づいて、現在カートに入っている商品の一覧を生成してもよい。診察支援部１１４は、生成された一覧を含むＨＴＭＬ文書を生成してもよい。顧客端末４は、このＨＴＭＬ文書に基づいて、注文申込内容確認画面１４００を表示する。

顧客端末４により表示された注文申込内容確認画面１４００において、注文を申し込むための操作を行う（ステップＳ１１２）。この操作を検出した顧客端末４は、販売管理サーバ１へ注文申込を送信する（ステップＳ１１３）。注文申込を受信した販売管理サーバ１の診察支援部１１４は、診察予約画面１５００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ１１４）。顧客端末４は、このＨＴＭＬ文書に基づいて、診察予約画面１５００を表示する（ステップＳ１１５）。

図２１に示すように、顧客は、診察予約画面１５００から診察日及び診察開始時刻を選択する（ステップＳ２０１）。この操作を検出した顧客端末４は、販売管理サーバ１へ予約確認画面要求を送信する（ステップＳ２０２）。予約確認画面要求は、選択された診察日及び診察開始時刻を含んでもよい。予約確認画面要求を受信した販売管理サーバ１の診察支援部１１４は、診察予約確認画面１６００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ２０３）。顧客端末４は、このＨＴＭＬ文書に基づいて、診察予約確認画面１６００を表示する。

注診察予約確認画面１６００において、顧客が、予約を確定させる操作を行う（ステップＳ２０４）。この操作を検出した顧客端末４は、販売管理サーバ１へ予約確定要求を送信する（ステップＳ２０５）。予約確定要求を受信した販売管理サーバ１の診察支援部１１４は、予約情報を生成して診察予約ＤＢ１４ｄに記憶させる（ステップＳ２０６）。次いで、診察支援部１１４は、診察予約受付完了画面１７００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ２０７）。

顧客は、予約された診察日に、診察待機画面１９００を顧客端末４により表示させる。医療機関の医師が医師端末２を操作すること応じて、診察支援部１１４は、診察を予約した顧客のための医師診察画面のＨＴＭＬ文書を医師端末２へ送信する。医師端末２は、このＨＴＭＬ文書に基づいて、図２２に示すように医師診察画面を表示する（ステップＳ３０１）。医師診察画面において、医師が、診察のための通話を開始させる操作を行う。この操作を検出した医師端末２は、販売管理サーバ１へ通話接続要求を送信する（ステップＳ３０２）。通話接続要求は、例えば診察の予約番号や診察を予約した顧客の顧客ＩＤを含んでもよい。通話接続要求を受信した販売管理サーバ１の診察支援部１１４は、顧客ＩＤにより示される顧客の顧客端末４へ顧客診察画面２０００のＨＴＭＬ文書を送信する（ステップＳ３０３）。顧客端末４は、このＨＴＭＬ文書に基づいて、顧客診察画面２０００を表示する（ステップＳ３０４）。

顧客端末４は、顧客診察画面２０００を表示すると、そのＨＴＭＬ文書に含まれるスクリプトに基づいて、販売管理サーバ１を介してセッション情報を医師端末２へ送信する。医師端末２も、医師診察画面のＨＴＭＬ文書に含まれるスクリプトに基づいて、販売管理サーバ１を介してセッション情報を顧客端末４へ送信する（ステップＳ３０５）。顧客端末４及び医師端末２は、交換したセッション情報に基づいて互いに接続する（ステップＳ３０６）。顧客端末４と医師端末２とが接続されると、それらの端末装置間でメディアデータの送受信が行われることにより、オンライン診察が開始される（ステップＳ３０７）。

オンライン診察中、医師は、顧客のカートに入っている商品の情報を参照して、医師診察画面に処方予定の商品の情報を入力する（ステップＳ３０８）。例えば医師は、処方する商品、購入形態、及び数量を選択してもよい。医師診察画面には、顧客のカートに入っている商品の一覧が表示されている。医師は、その一覧を参照して処方を入力してもよい。処方が入力されると、医師端末２は、販売管理サーバ１へ入力情報を送信する（ステップＳ３０９）。入力情報は、医師により選択された商品の商品ＩＤ、購入形態、及び数量を含んでもよい。

入力情報を受信した販売管理サーバ１の診察支援部１１４は、この入力情報に基づいて、カートＤＢ１４ｃに記憶されている顧客のカート情報を更新する（ステップＳ３１０）。例えば診察支援部１１４は、カート情報に含まれる各カート商品情報を、入力情報で書き換えてもよい。このとき、診察支援部１１４は、各カート商品情報に、医師により選択された商品の医療用医薬品フラグを追加してもよい。ステップＳ３０８～Ｓ３１０は、必要に応じて繰り返されてもよい。

その後、医師が、処方内容を確定する操作を行う（ステップＳ３１１）。この操作を検出した医師端末２は、販売管理サーバ１へ、処方内容確定要求を送信する（ステップＳ５１２）。処方内容確定要求を受信した販売管理サーバ１の診察支援部１１４は、顧客のカート情報に基づいて、処方ログを生成して処方履歴ＤＢ１４ｅに記憶させる（ステップＳ３１３）。

その後、例えば顧客又医師が通話を終了させる操作を行うことに応じて、顧客端末４と医師端末２との接続が切断し、メディアデータの送受信も停止する。そして、注文確定部１１５は、注文内容確認画面２１００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ３１４）。カートに入っている商品が医療用医薬品を含まない場合（ステップＳ１０９：ＮＯ）、または顧客が有効に存続している購入権を有している場合にも（ステップＳ１１０：ＹＥＳ）、注文確定部１１５は、注文内容確認画面２１００のＨＴＭＬ文書を顧客端末４へ送信する（ステップＳ３１４）。顧客端末４は、このＨＴＭＬ文書に基づいて、注文内容確認画面２１００を表示する（ステップＳ３１５）。注文内容確認画面２１００において、顧客が、注文を確定させる操作を行う。（ステップＳＳ３１６）。この操作を検出した顧客端末４は、販売管理サーバ１へ注文確定要求を送信する（ステップＳ３１７）。

注文確定要求を受信した販売管理サーバ１の注文確定部１１５は、注文情報を生成して、この注文情報を注文ＤＢ１４ｆに記憶させる（ステップＳ４０１）。注文確定部１１５は、その顧客のカート情報に基づいて、注文情報を生成しもよい。例えば注文確定部１１５は、カート情報に含まれる各カート商品情報に相当する注文商品情報を生成してもよい。このとき、注文確定部１１５は、医療用医薬品である各商品の注文商品情報に、継続購入フラグを追加してもよい。注文された商品についてその顧客が有効な購入権を有してない場合、注文確定部１１５は、継続購入フラグを「初回購入」に設定してもよい。顧客が有効な購入権を有している場合、注文確定部１１５は、継続購入フラグを「継続購入」に設定してもよい。また注文確定部１１５は、新たな注文番号を生成してもよい。また、注文確定部は、注文日時として、現在日時を取得してもよい。注文確定部１１５、注文番号、注文日時、注文を行った顧客の顧客ＩＤ、注文商品情報、顧客により指定された発送先を示す発送先情報、顧客の指定に応じた発送予定日等を含む注文情報を生成してもよい。次いで、注文確定部１１５は、決済処理を実行する（ステップＳ４０２）。

次いで、商品提供制限情報管理部１２３は、生成された各注文商品情報に含まれる医療用医薬品フラグに基づいて、注文された商品が医療用医薬品を含むか否かを判定する（ステップＳ４０３）。注文された商品が医療用医薬品を含む場合（ステップＳ４０３：ＹＥＳ）、商品提供制限情報管理部１２３は、医療用医薬品である商品の注文商品情報に含まれる継続購入フラグに基づいて、その商品の購入が初回購入であるかを判定する（ステップＳ４０４）。その商品の購入が初回購入である場合（ステップＳ４０４：ＹＥＳ）、商品提供制限情報管理部１２３は、購入権情報を生成して、その購入権情報を購入権ＤＢ１４ｇに記憶させる（ステップＳ４０５）。例えば商品提供制限情報管理部１２３は、新しい購入権ＩＤを生成してもよい。また商品提供制限情報管理部１２３は、設定日を今日の日付に設定してもよい。また商品提供制限情報管理部１２３は、既購入量を０ヶ月に設定してもよい。また商品提供制限情報管理部１２３は、権利状態を「有効」に設定してもよい。商品提供制限情報管理部１２３は、購入権ＩＤ、注文番号、その顧客の顧客ＩＤ、設定日、その商品の商品ＩＤ、最大処方量、既購入量、及び権利状態等を含む購入権情報を生成してもよい。本実施形態においては、決済完了時に購入権情報が生成される。しかしながら、商品提供制限情報管理部１２３は、医師による処方の確定時又は注文の確定時に、購入権情報を生成してもよい。

ステップＳ４０５が終了した場合、注文された商品が医療用医薬品を含まない場合（ステップＳ４０３：ＮＯ）、または商品の購入が継続購入である場合（ステップＳ４０４：ＮＯ）、発送予定情報管理部１１６は、発送予定情報を生成して、この発送予定情報を発送予定ＤＢ１４ｈに記憶させる（ステップＳ４０６）。例えば発送予定情報管理部１１６は、新しい発送予定ＩＤを生成してもよい。また発送予定情報管理部１１６は、生成された注文情報から、注文番号、顧客ＩＤ、各注文商品情報、発送先情報、発送予定日等を取得してもよい。発送予定情報管理部１１６は、例えば購入形態ごとに発送予定情報を生成してもよい。発送予定情報管理部１１６は、取得された注文商品情報のうち少なくとも一つに含まれる購入形態が「逐次購入」である場合、逐次購入の対象となる商品用の発送予定情報を生成してもよい。発送予定情報管理部１１６は、取得された注文商品情報のうち少なくとも一つに含まれる購入形態が「定期自動購入」である場合、定期自動購入の対象となる商品用の発送予定情報を生成してもよい。発送予定情報管理部１１６は、各注文商品情報に基づいて、発送予定商品情報を生成してもよい。このとき、発送予定情報管理部１１６は、発送状態を「未発送」に設定してもよい。また発送予定情報管理部１１６は、発送回を１に設定してもよい。また発送予定情報管理部１１６は、発送予定ＩＤ、注文番号、顧客ＩＤ、購入形態、発送回、発送予定商品情報、発送先情報、発送予定日、及び発送状態等を含む発送予定情報を生成してもよい。次いで、注文確定部１１５は、注文完了画面のＨＴＭＬ文書を、顧客端末４へ送信する（ステップＳ４０７）。

例えば販売管理サーバ１の発送予定情報管理部１１６は、毎日所定の時刻に、発送予定ＤＢ１４ｈから、出荷端末３へ送信すべき発送予定情報を検索する。例えば、発送予定情報管理部１１６は、今日の日付及び発送予定情報に含まれる発送日に基づいて、検索を行ってもよい。図２４に示すように、発送予定情報管理部１１６は、検索された発送予定情報を出荷端末３へ送信する（ステップＳ５０１）。このとき、発送予定情報管理部１１６は、発送状態が「キャンセル」に設定されている発送予定商品情報を、送信する発送予定情報から削除してもよい。全ての発送予定商品情報の発送状態が「キャンセル」である場合、発送予定情報管理部１１６は、その発送予定情報自体を送信しなくてもよい。出荷端末３は、受信された発送予定情報に基づいて、商品の発送予定を画面に表示する。発送予定に従って商品の発送を行った後、従業員は、出荷端末３に発送日及びその商品の配送伝票に付された伝票番号のうち少なくとも何れか一方を入力する（ステップＳ５０２）。この入力に応じて、出荷端末３は、販売管理サーバ１へ発送完了通知を送信する（ステップＳ５０３）。発送完了通知は、従業員に入力された情報及びその発送予定の発送予定ＩＤを含んでもよい。

販売管理サーバ１の発送予定情報管理部１１６は、発送完了通知から従業員により入力された情報及び発送予定ＩＤを取得する。発送予定情報管理部１１６は、この発送予定ＩＤを含む発送予定情報を、発送予定ＤＢ１４ｈから検索する。発送予定情報管理部１１６は、検索された発送予定情報に含まれる各商品の発送状態のうち、「未発送」に設定されている発送状態を、「発送完了」に変更する（ステップＳ５０４）。また発送予定情報管理部１１６は、発送予定情報に発送日を追加する。

次いで、商品提供制限情報管理部１２３は、購入権ＤＢ１４ｇに記憶されている購入権情報を更新する（ステップＳ５０５）。例えば商品提供制限情報管理部１２３は、検索された発送予定情報から、商品の発送先の顧客の顧客ＩＤ及び発送された商品の発送予定商品情報を取得してもよい。商品提供制限情報管理部１２３は、その顧客ＩＤと発送予定商品情報に含まれる商品ＩＤとの組み合わせを含む購入権情報のうち、最新の設定日を含む購入権情報を検索してもよい。商品提供制限情報管理部１２３は、検索された購入権情報に含まれる既購入量に、発送予定商品情報に含まれる数量を加算して、この既購入量を更新してもよい。更新後の既購入量が最大処方量に達している場合、商品提供制限情報管理部１２３は、購入権情報に含まれる権利状態を「消滅」に変更してもよい。本実施形態においては、発送完了時に購入権情報が更新される。しかしながら、商品提供制限情報管理部１２３は、医師による処方の確定時又は注文の確定時に、購入権情報を更新してもよい。

次いで、発送予定情報管理部１１６は、検索された発送予定情報に含まれる購入形態が、「定期自動購入」であるか否かを判定する（ステップＳ５０６）。購入形態が「定期自動購入」である場合（ステップＳ５０６：ＹＥＳ）、発送予定情報管理部１１６は、購入形態が定期自動購入である商品の購入権情報に含まれる権利状態に基づいて、その商品についての購入権が有効に存続しているか否かを判定する（ステップＳ５０７）。購入権が有効に存続している場合（ステップＳ５０７：ＹＥＳ）、発送予定情報管理部１１６は、定期配送での次回の配送のための発送予定情報を生成して、この発送予定情報を発送予定ＤＢ１４ｈに記憶させる（ステップＳ５０８）。例えば発送予定情報管理部１１６は、検索された発送予定情報のコピーを生成してもよい。発送予定情報管理部１１６は、コピーに含まれる発送予定ＩＤを変更してもよい。また発送予定情報管理部１１６は、コピーに含まれる発送回に１を加算することにより、この発送回を更新してもよい。また発送予定情報管理部１１６は、コピーに含まれる発送日に、定期配送の発送周期の長さを加算して、発送予定日を計算してもよい。発送予定情報管理部１１６は、コピーに含まれる発送予定日を、計算された発送予定日で更新してもよい。発送予定情報管理部１１６は、コピーから、「発送完了」に設定された発送状態を検索してもよい。発送予定情報管理部１１６は、検索された発送状態を「未発送」に変更してもよい。発送予定情報管理部１１６は、このコピーを、次回の配送のための発送予定情報として、発送予定ＤＢ１４ｈに記憶させてもよい。

ステップＳ５０８が終了した場合、購入形態が「逐次購入」である場合（ステップＳ５０６：ＮＯ）、または購入権が存続していない場合（ステップＳ５０７：ＮＯ）、経過観察通知送信部１１８は、発送予定情報に含まれる購入形態及び発送回に基づいて、今回の発送は、２回目以降の配送分の商品の発送であるか否かを判定する（ステップＳ５０９）。今回の発送が２回目以降の配送分の商品の発送ではない場合（ステップＳ５０９：ＮＯ）、購入商品識別情報１１７は、発送予定情報に含まれる発送予定商品情報のうち、発送状態が「発送完了」である発送予定商品情報から、購入された商品の商品ＩＤを取得する（ステップＳ５１０）。次いで、経過観察通知送信部１１８は、購入された各商品の経過観察期間長を取得する（ステップＳ５１１）。例えば経過観察通知送信部１１８は、商品ＤＢ１４ｂから、商品ＩＤに関連付けられたカテゴリ情報を取得してもよい。経過観察通知送信部１１８は、取得されたカテゴリ情報に関連付けられた経過観察期間長を、経過観察期間ＤＢ１４ｉから１又は複数取得してもよい。経過観察通知送信部１１８は、購入形態が逐次購入である商品については、既購入量に相当する長さ以下の経過観察期間長を取得してもよい。経過観察通知送信部１１８は、購入形態が定期自動購入である商品については、最大処方量に相当する長さ以下の経過観察期間長を取得してもよい。次いで、経過観察通知送信部１１８は、経過観察通知予定情報を生成して、この経過観察通知予定情報を経過観察通知予定ＤＢ１４ｋに記憶させる（ステップＳ５１２）。例えば経過観察通知送信部１１８は、質問が互いに同一である商品と経過観察期間長との組み合わせごとに、経過観察通知予定情報を生成してもよい。本実施形態においては、同一のカテゴリに属する商品間で質問が同一である。経過観察通知送信部１１８は、新しい経過観察ＩＤを生成してもよい。また経過観察通知送信部１１８は、発送予定情報に含まれる発送日に経過観察期間長を加算することにより、送信予定日を計算してもよい。前述したように、経過観察通知送信部１１８は、送信予定日を、発送日の丁度Ｎヶ月後からずらしてもよい。購入形態が逐次購入であって、且つ今回の購入が継続購入である場合、経過観察通知送信部１１８は、発送予定ＤＢ１４ｈから、初回購入時の発送予定情報を検索してもよい。経過観察通知送信部１１８は、検索された発送予定情報に含まれる発送日に基づいて、送信予定日を計算してもよい。経過観察通知送信部１１８は、経過観察ＩＤ、商品の発送先の顧客の顧客ＩＤ、カテゴリ情報、商品ＩＤ、及び送信予定日等を含む経過観察通知予定情報を生成してもよい。

図２５に示すように、例えば経過観察通知送信部１１８は、毎日所定の時刻に、送信予定日が今日である経過観察通知予定情報を、経過観察通知予定ＤＢ１４ｋから検索する（ステップＳ６０１）。次いで、経過観察通知送信部１１８は、検索された各経過観察通知予定情報について、経過観察通知メールを送信する（ステップＳ６０２）。例えば経過観察通知送信部１１８は、経過観察通知予定情報に含まれる商品ＩＤに基づいて、経過観察の対象となる商品の商品名を商品ＤＢ１４ｂから取得してもよい。経過観察通知送信部１１８は、その商品名を、経過観察通知メールの本文に追加してもよいまた経過観察通知送信部１１８は、経過観察通知予定情報に含まれる顧客ＩＤに基づいて、経過観察通知メールの送信先の顧客の電子メールアドレスを取得してもよい。経過観察通知送信部１１８は、経過観察通知メールの受信者アドレスを、この電子メールアドレスに設定してもよい。また経過観察通知送信部１１８は、経過観察通知メールに含まれる回答ボタン３１３０が操作された場合に、顧客端末４から販売管理サーバ１へ質問シート画面要求が送信されるように、経過観察通知メールを生成してもよい。経過観察通知送信部１１８は、質問シート画面要求が経過観察ＩＤを含むようにしてもよい。

顧客端末４は、顧客による操作に応じて経過観察通知メールを受信して表示する（ステップＳ６０３）。顧客は回答ボタン３１３０を押下する（ステップＳ６０４）。この操作を検出した顧客端末４は、販売管理サーバ１へ質問シート画面要求を送信する（ステップＳ６０５）。販売管理サーバ１の購入商品識別情報取得部１１７は、質問シート画面要求から経過観察ＩＤを取得する。購入商品識別情報取得部１１７は、この経過観察ＩＤを含む経過観察通知予定情報を、経過観察通知予定ＤＢ１４ｋから検索する。購入商品識別情報取得部１１７は、検索された経過観察通知予定情報からカテゴリ情報を取得する（ステップＳ６０６）。次いで、質問情報送信部１１９は、取得されたカテゴリ情報に関連付けられた質問シート画面３２００のＨＴＭＬ文書を、記憶部１４から取得する（ステップＳ６０７）。質問情報送信部１１９は、取得されたＨＴＭＬ文書を、顧客端末４へ送信する（ステップＳ６０８）。顧客端末４は、このＨＴＭＬ文書に基づいて、質問シート画面３２００を表示する（ステップＳ６０９）。

顧客は、質問シート画面３２００に回答を入力する（ステップＳ６１０）。顧客端末４は、入力された回答を示す回答情報及び質問シート画面３２００に表示された質問を示す質問情報を、販売管理サーバ１へ送信する（ステップＳ６１１）。販売管理サーバ１の回答情報受信部１２０は、受信された回答情報及び質問情報を、その顧客の顧客ＩＤ及び経過観察ＩＤに関連付けて、回答ＤＢ１４ｌに記憶させる（ステップＳ６１２）。

医師が、医師端末２の画面に表示された経過観察の一覧から何れかの経過観察を選択する。この操作を検出した医師端末２は、図２６に示すように、販売管理サーバ１へ経過観察画面要求を送信する（ステップＳ７０１）。経過観察画面要求は、選択された経過観察の経過観察ＩＤを含んでよい。販売管理サーバ１の使用継続可否情報取得部１２１は、経過観察ＩＤに関連付けられた回答情報及び質問情報を、回答ＤＢ１４ｌから取得する（ステップＳ７０２）。使用継続可否情報取得部１２１は、取得された回答情報及び質問情報を含む経過観察画面３３００のＨＴＭＬ文書を生成して、このＨＴＭＬ文書を医師端末２へ送信する（ステップＳ７０３）。医師端末２は、このＨＴＭＬ文書に基づいて、経過観察画面３３００を表示する（ステップＳ７０４）。医師は、経過観察画面３３００において、各商品の処方継続の可否を選択する（ステップＳ７０５）。また医師は、必要に応じてコメントを入力する。医師が送信ボタン３３４０を押下すると、医師端末２は、販売管理サーバ１へ経過観察結果情報を送信する（ステップＳ７０６）。経過観察結果情報は、選択された経過観察の経過観察ＩＤ、経過観察の対象となる顧客の顧客ＩＤ、及びコメントを含んでもよい。また経過観察結果情報は、商品ごとに、商品ＩＤ及び医師の選択に応じた処方継続可否情報を含んでもよい。使用継続可否情報取得部１２１は、受信された経過観察結果情報を、経過観察結果ＤＢ１４ｍに記憶させる。

販売管理サーバ１の商品提供制限情報管理部１２３は、経過観察結果情報に含まれる処方継続可否情報に基づいて、処方中止が決定された商品があるか否かを判定する（ステップＳ７０７）。処方中止が決定された商品がある場合（ステップＳ７０７：ＹＥＳ）、商品提供制限情報管理部１２３は、経過観察の対象の顧客の顧客ＩＤと処方中止が決定された商品の商品ＩＤとの組み合わせを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権ＤＢ１４ｇから検索する。商品提供制限情報管理部１２３は、検索された購入権情報に含まれる権利状態を、「停止」に変更する（ステップＳ７０８）。

次いで、発送予定情報管理部１１６は、経過観察の対象の顧客の顧客ＩＤと処方中止が決定された商品の商品ＩＤと「定期自動購入」を示す購入形態との組み合わせを含む発送予定情報を、発送予定ＤＢ１４ｈから検索する。このとき、発送予定情報管理部１１６は、その商品の発送予定商品情報に含まれる発送状態が「未発送」である発送予定商品情報を検索してもよい。発送予定情報管理部１１６は、この検索の結果に基づいて、その商品の購入が定期自動購入であるか否かを判定する（ステップＳ７０９）。その商品の購入が定期自動購入である場合（ステップＳ７０９：ＹＥＳ）、発送予定情報管理部１１６は、検索された発送予定情報に含まれるその商品の発送予定商品情報の発送状態を、「キャンセル」に変更する（ステップＳ７１０）。

ステップＳ７１０が終了した場合、処方中止が決定された商品がない場合（ステップＳ７０７：ＮＯ）、または商品の購入が定期自動購入ではない場合（ステップＳ７０９：ＮＯ）、経過観察結果情報送信部１２２は、経過観察結果メールを送信する（ステップＳ７１１）。ここで、経過観察結果情報送信部１２２は、経過観察結果情報に基づいて、送信する経過観察結果メールを生成してもよい。例えば処方中止が決定された商品がない場合、経過観察結果情報送信部１２２は、図１６（ａ）に示す経過観察結果メールを生成してもよい。処方中止が決定された商品が存在し、且つ、購入形態が逐次購入である場合、経過観察結果情報送信部１２２は、図１６（ｂ）に示す経過観察結果メールを生成してもよい。処方中止が決定された商品が存在し、且つ、購入形態が定期自動購入である場合、経過観察結果情報送信部１２２は、図１６（ｃ）に示す経過観察結果メールを生成してもよい。経過観察結果情報送信部１２２は、処方中止が決定された商品の名称を、経過観察結果メールに追加してもよい。経過観察結果情報送信部１２２は、経過観察結果情報に含まれる顧客ＩＤに基づいて、経過観察結果メールの送信先の顧客の電子メールアドレスを取得してもよい。経過観察結果情報送信部１２２は、経過観察結果メールの受信者アドレスを、この電子メールアドレスに設定してもよい。

以上説明したように、本実施形態によれば、販売管理サーバ１が、複数の商品のうち購入された商品の商品ＩＤを取得してもよい。また販売管理サーバ１が、購入された商品についての経過観察通知を送信してもよい。このとき、販売管理サーバ１が、商品ＤＢ１４ｂ及び経過観察期間ＤＢ１４ｉに基づいて、商品ＩＤにより識別される商品の購入に関連する基準日からその商品に対応する長さの期間の経過後に、経過観察通知を送信してもよい。また、販売管理サーバ１が、経過観察通知の送信後にその商品の購入者が利用する顧客端末４からの要求に応じて、質問情報を顧客端末４へ送信してもよい。このとき、販売管理サーバ１が、商品ＤＢ１４ｂ及び質問情報ＤＢ１４ｊに基づいて、購入された商品に対応する質問情報を送信してもよい。商品ＤＢ１４ｂ及び経過観察期間ＤＢ１４ｉからは、複数の商品のそれぞれについて、その商品の購入に関連する基準日から経過観察の時期までの期間の長さを特定可能である。そのため、商品に応じてその期間の長さが異なっていても、購入された商品に対応する長さの期間の経過後に、経過観察通知を送信することができる。商品ＤＢ１４ｂ及び質問情報ＤＢ１４ｊからは、複数の商品それぞれについて、その商品についての質問情報を特定可能である。そのため、商品に応じて質問が異なっていても、購入された商品に対する質問を購入者に提示することができる。従って、商品の購入者に対する経過観察の負担を解消することができる。

ここで、販売管理サーバ１が、顧客端末４から回答情報を受信してもよい。また、販売管理サーバ１が、回答情報に基づいて、使用継続可否情報を取得してもよい。また、販売管理サーバ１が、使用継続可否情報により示される使用継続の可否を含む経過観察の結果を示す経過観察結果情報を、顧客端末４へ送信してもよい。この場合、経過観察の結果が、商品の購入者に提示される。この経過観察の結果は、購入された商品の使用継続の可否を含む。使用継続可否情報は、回答情報に基づいて取得される。そのため、購入者の状況に応じた商品の使用継続の可否を、その購入者に提示することができる。

ここで、販売管理サーバ１が、回答情報と、購入された商品の使用継続の可否の選択を受け付け可能な画面を医師端末２に表示させる画面情報と、を医師端末２へ送信してもよい。また、販売管理サーバ１が、画面情報に基づいて医師端末２により表示された画面で選択された使用継続の可否を示す使用継続可否情報を、医師端末２から受信してもよい。この場合、回答情報は医師端末２へ送信される。そのため、医師端末２を利用する決定者は、回答情報に基づいて、購入された商品の使用継続の可否を決定することができる。また、医師端末２には、購入された商品の使用継続の可否の選択を受け付け可能な画面が表示される。そのため、決定者は、商品の使用継続の可否を画面で選択することができる。

また、販売管理サーバ１が、顧客端末４と医師端末２とを、医師による診察のための通信を可能に接続させてもよい。また、販売管理サーバ１が、顧客端末４と医師端末２との接続後、購入された商品として、その診察を通じて決済された商品の商品ＩＤを取得してもよい。この場合、顧客端末４と医師端末２とが通信接続されることにより、医師によるオンラインでの診察が可能となる。この診察で医師が提供を指示した医薬品が購入される。この購入された医薬品について経過観察通知が送信される。そのため、診察を受けて医薬品を購入した顧客に対する経過観察の負担を解消することができる。

また、販売管理サーバ１が、出荷端末３から発送完了通知を受信してもよい。また、販売管理サーバ１が、発送完了通知が受信された場合、発送予定ＤＢ１４ｈに記憶された発送状態を、「未発送」から「発送完了」に変更してもよい。また、販売管理サーバ１が、発送状態が「発送完了」に設定されていることを条件に経過観察通知を送信してもよい。このとき、販売管理サーバ１が、購入された商品の発送日からその商品に対応する長さの期間の経過後に、経過観察通知を送信してもよい。この場合、購入された商品が発送されると、発送者が利用する出荷端末３から発送完了通知が送信されて、その商品の発送状態が、「未発送」から「発送完了」に変更される。発送状態が「発送完了」に変更された後、経過観察通知が送信される。経過観察通知は、その商品の発送日から、その商品に対応する長さの期間の経過後に送信される。そのため、購入された商品に応じた時期であって、その商品の発送時期に応じた時期に、経過観察を行うことができる。

また、販売管理サーバ１が、質問情報を顧客端末４へ送信してもよい。また、販売管理サーバ１が、質問情報を受信した顧客端末４から回答情報を受信してもよい。また、販売管理サーバ１が、回答情報に基づいて、使用継続可否情報を取得してもよい。また、販売管理サーバ１が、購入権ＤＢ１４ｇを変更して、購入者に対して、購入された商品の提供が制限されることが購入権ＤＢ１４ｇから特定可能にしてもよい。この場合、購入された商品についての経過観察のための質問が購入者に提示される。この質問に対する回答を示す回答情報が、購入者端末から受信される。この回答情報に基づいて、購入された商品の使用継続の可否を示す使用継続可否情報が取得される。その商品の使用継続が不可である場合、購入権ＤＢ１４ｇが変更される。これにより、購入された商品を購入者へ提供することが制限されていることが、購入権ＤＢ１４ｇから特定可能となる。そのため、購入権ＤＢ１４ｇを参照することにより、購入者への商品の提供を制限するための処理を行うことができる。従って、商品の購入後における購入者の状況に応じて商品の提供を制限するための情報を記憶させることができる。

ここで、販売管理サーバ１が、注文のために顧客により選択された商品を示す商品ＩＤ及びその商品を選択した顧客の顧客ＩＤを取得してもよい。また、販売管理サーバ１が、顧客ＩＤにより示される顧客に対して商品ＩＤにより示される商品の提供が制限されることが購入権ＤＢ１４ｇから特定される場合、顧客と医師との面談を支援してもよい。また、販売管理サーバ１が、その面談後、選択された商品の注文を確定させる確定させてもよい。また、販売管理サーバ１が、顧客ＩＤにより示される顧客に対して商品ＩＤにより示される選択された商品の提供が制限されないことが購入権ＤＢ１４ｇから特定される場合、面談なくして注文を確定させてもよい。この場合、注文のために顧客により選択された商品をその顧客に提供することが制限される場合、顧客とその商品の使用可否を決定する医師との面談が可能とされる。その面談後、選択された商品の注文が確定する。選択された商品をその顧客に提供することが制限されない場合、顧客と医師との面談を省略して、選択された商品の注文が確定する。そのため、商品の提供が制限されるか否かで、その商品の注文の確定に面談が必要であるか否かが異なる。従って、注文のための条件を設けることで、商品の提供を適切に制限することができる。

ここで、販売管理サーバ１が、顧客が利用する顧客端末４と医師が利用する医師端末２とを、面談のための通信を可能に接続させてもよい。また、販売管理サーバ１が、顧客ＩＤにより示される顧客に対して商品ＩＤにより示される商品の提供が制限されることが購入権ＤＢ１４ｇから特定される場合、顧客端末４と医師端末２との接続後、注文を確定させてもよい。また、販売管理サーバ１が、その顧客に対してその商品の提供が制限されないことが購入権ＤＢ１４ｇから特定される場合、顧客端末４と医師端末２との接続を省略して、注文を確定させてもよい。この場合、顧客端末と医師端末とが通信接続されることにより、顧客と医師とのオンラインでの面談が可能となる。オンラインでの面談後、注文が確定する。そのため、顧客に商品の提供が制限される場合、その商品の注文を確定させるための条件としての面談を、オンラインで実現することができる。

また、販売管理サーバ１が、購入者に対して、購入された商品の提供が制限されることが特定可能に変更される場合、購入者に対するその商品の次回の発送をキャンセルしてもよい。この場合、購入された商品を購入者へ提供することが制限されない場合、その商品は購入者へ定期的に発送される。購入された商品を購入者へ提供することが制限される場合、その商品の次回の発送がキャンセルされる。これにより、商品の定期的な発送が停止される。そのため、商品が定期的に発送される形態における商品の提供を適切に制限することができる。

［２．第２実施形態］
次に第２実施形態について、図２７及び図２８を参照して説明する。本実施形態においては、商品の注文に必要な操作が制限されることで、顧客に対する商品の提供が制限されてもよい。以下に説明する点を除き、第２実施形態は第１実施形態と同一であってもよい。

前述したように、販売画面情報送信部１１１は、顧客端末４からの要求に応じた商品に関する情報を含む画面を表示させる画面情報を、その顧客端末４へ送信する。販売画面情報送信部１１１は、その顧客端末４を利用する顧客に対してその要求に応じた商品の提供が制限されることが商品提供制限情報から特定されない場合、その商品を選択するための操作を受け付ける画面を表示させるための画面情報を送信してもよい。一方、販売画面情報送信部１１１は、その顧客に対してその商品の提供が制限されることが商品提供制限情報から特定される場合、その商品を選択するための操作を受け付けない画面を表示させるための画面情報を送信してもよい。商品を選択するための操作は、その操作を行うことによって、最終的には顧客がその商品を注文することが可能となる操作であってもよい。商品を選択するための操作の例として、検索結果画面に表示された商品の一覧から何れかの商品を選択する操作、商品画面１２００で商品をカートに追加する操作、注文申込内容確認画面１４００で商品の注文を申し込む操作、注文内容確認画面２１００で商品の注文を確定させる操作等が挙げられる。

図２７は、商品画面１２００の一例を示す図である。図２７において、図９と同一の要素については同一の符号が付されている。顧客に対して商品の提供が制限されない場合、図９に示すような商品画面１２００が表示されてもよい。この場合、顧客はカート追加ボタン１２２０を操作することができる。これにより、その商品はカートに追加される。顧客に対して商品の提供が制限される場合、図１２に示すような商品画面１２００が表示されてもよい。図１２に示すように、商品画面１２００は、購入形態・数量選択ボタン群１２１０、カート追加ボタン１２２０、及びカートアコン１２３０等に加えて、メッセージ１２４０、及び診察予約リンク１２５０を含んでもよい。図１２において、カート追加ボタン１２２０は破線で示されている。これは、カート追加ボタン１２２０が無効であることを示している。そのため、顧客はカート追加ボタン１２２０を操作することができない。なお、カート追加ボタン１２２０自体が非表示になっていてもよい。商品をカートに追加することができないため、顧客は商品を注文することができない。メッセージ１２４０は、顧客への商品の提供が制限されていることを示してもよい。診察予約リンク３４３０は、オンライン診察の予約を行うために操作可能なリンクであってもよい。提供が制限されている商品を選択して注文を申し込むことはできないものの、顧客は、オンライン診察において医師によりその商品を改めて処方してもらうことができる場合がある。

システム制御部１１は、商品提供制限情報を管理することなく若しくは商品提供制限情報を参照することなく、顧客に対して商品の提供を制限するための処理を行ってもよい。例えば販売画面情報送信部１１１は、使用継続可否情報取得部１２１により取得された使用継続可否情報が使用継続可を示す場合、その商品を選択するための操作を受け付ける画面を表示させるための画面情報を送信してもよい。販売画面情報送信部１１１は、使用継続可否情報取得部１２１により取得された使用継続可否情報が、使用継続の不可を示す場合、その商品を選択するための操作を受け付けない画面を表示させるための画面情報を送信してもよい。

図２８は、本実施形態に係る販売管理サーバ１のシステム制御部１１により実行される商品画面情報送信処理の一例を示すフローチャートである。例えば顧客は、検索結果画面から、検索された商品のうち何れかの商品を選択する操作を行う。この操作を検出した顧客端末４は、販売管理サーバ１へ商品画面要求を送信する。商品画面要求は、その顧客の顧客ＩＤ及び選択された商品の商品ＩＤを含んでもよい。システム制御部１１は、販売管理サーバ１が顧客端末４から商品画面要求を受信することに応じて、商品画面情報送信処理を実行してもよい。

図２８に示すように、販売画面情報送信部１１１は、顧客により選択された商品の商品画面のＨＴＭＬ文書を取得する（ステップＳ８０１）。例えば記憶部１４には、商品ごとに、その商品の商品画面のＨＴＭＬ文書が商品ＩＤに関連付けて記憶されてもよい。販売画面情報送信部１１１は、商品画面要求に含まれる商品ＩＤに関連付けられたＨＴＭＬ文書を取得してもよい。次いで、販売画面情報送信部１１１は、その顧客の顧客ＩＤと選択された商品の商品ＩＤとを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権ＤＢ１４ｇから検索する（ステップＳ８０２）。検索の結果、販売画面情報送信部１１１は、該当する購入権情報があるか否かを判定する（ステップＳ８０３）。該当する購入権情報がある場合（ステップＳ８０３：ＹＥＳ）、販売画面情報送信部１１１は、その購入権情報に含まれる権利状態が「停止」であるか否かを判定する（ステップＳ８０４）。権利状態が「停止」ではない場合（ステップＳ８０４：ＮＯ）、または該当する購入権情報がない場合（ステップＳ８０３：ＮＯ）、販売画面情報送信部１１１は、商品画面のＨＴＭＬ文書内におけるカート追加ボタン１２２０の有効性を示す情報を、有効に設定する（ステップＳ８０５）。権利状態が「停止」である場合（ステップＳ８０４：ＹＥＳ）、販売画面情報送信部１１１は、カート追加ボタン１２２０の有効性を示す情報を、無効に設定する（ステップＳ８０６）。ステップＳ８０５又はＳ８０６が終了すると、販売画面情報送信部１１１は、商品画面のＨＴＭＬ文書を顧客端末４へ送信して（ステップＳ８０７）、商品画面情報送信処理は終了する。顧客端末４は、このＨＴＭＬ文書に基づいて商品画面を表示する。カート追加ボタン１２２０の有効性を示す情報が有効である場合、顧客端末４は、カート追加ボタン１２２０の操作が可能となるように、カート追加ボタン１２２０を表示する。その有効性を示す情報が無効である場合、顧客端末４は、カート追加ボタン１２２０の操作が不可能となるように、カート追加ボタン１２２０を表示する。

以上説明したように、本実施形態によれば、顧客端末４からの要求に応じた商品の情報を含む画面が顧客端末４に表示される。顧客に対してその商品の提供が制限されない場合、その商品を選択する操作が可能なように、その画面が表示される。そのため、顧客はその商品を注文することができる。顧客に対してその商品の提供が制限される場合、その商品を選択する操作が不可能なように、その画面が表示される。そのため、顧客はその商品を注文することができない。そのため、電子商取引に係る画面が、商品を選択する操作を受け入れるか否かによって、商品の提供の制限を制御することができる。

［３．第３実施形態］
次に第３実施形態について、図２９及び図３０を参照して説明する。本実施形態においては、顧客に対する商品の提供の制限が解除される場合がある。以下に説明する点を除き、第２実施形態は第１実施形態及び第２実施形態のうち少なくとも何れか一方と同一であってもよい。

これまで説明したように、顧客に対して商品の提供が一度制限された場合であっても、その顧客は医師からその商品を改めて処方してもらうことで、その商品を購入することができた。これは、顧客が新しい購入権を取得することに相当してもよい。この場合、顧客は最大処方量の範囲内で、その商品を購入することができる。これに対して、本実施形態の提供制限の解除は、購入権の停止が解除されること、または消滅した購入権が回復することであってもよい。この場合、最大処方量から顧客が既に購入している数量を減算して計算される残量の範囲内で、顧客はその商品を継続購入することが可能であってもよい。顧客が定期自動購入で商品を購入していた場合、停止されていた定期配送が再開してもよい。

図２９は、本実施形態に係る販売管理サーバ１におけるシステム制御部１１の機能ブロックの一例を示す図である。図２９において、図８と同一の要素については同一の符号が付されている。図２９に示すように、システム制御部１１は、販売画面情報送信部１１１、選択商品識別情報取得部１１２、カート情報管理部１１３、診察支援部１１４、注文確定部１１５、発送予定情報管理部１１６、購入商品識別情報取得部１１７、経過観察通知送信部１１８、質問情報送信部１１９、回答情報受信部１２０、使用継続可否情報取得部１２１、経過観察結果情報送信部１２２、及び商品提供制限情報管理部１２３に加えて、商品提供制限解除情報取得部１２４及び商品提供制限解除通知送信部１２５として機能してもよい。

商品提供制限解除情報取得部１２４は、商品提供制限情報管理部１２３により、商品の購入者に対してその商品の提供が制限されることを特定可能に商品提供制限情報が変更された後、商品提供制限解除情報を受信してもよい。商品提供制限解除情報は、その購入者に対するその商品の提供の制限が解除されることを示す情報であってもよい。商品提供制限解除情報は、提供の制限が解除される商品の商品ＩＤを含んでもよい。また商品提供制限解除情報は、商品の提供が解除される顧客の顧客ＩＤを含んでもよい。或いは、商品提供制限解除情報は、その商品の提供の制限が決定された経過観察の経過観察ＩＤを含んでもよい。

商品提供制限解除情報取得部１２４は、商品提供制限解除情報を医師端末２から取得してもよい。例えば医師が、顧客に対する商品の提供の制限を解除するか否かを決定してもよい。例えば、その顧客と医師との間でのやりとりの結果、医師が決定を行ってもよい。例えば診察により、商品の提供の制限を解除されるか否かが決定されてもよい。医師は、診察中に決定を行ってもよいし、診察後に決定を行ってもよい。或いは、処方中止後に経過観察が行われてもよい。この経過観察では、提供が制限された商品を顧客が使用していないという仮定の下でその顧客の状態を確認するための質問が顧客に提示されてもよい。この経過観察にて、医師が商品の提供に対する制限の解除を決定してもよい。

商品提供制限情報管理部１２３は、商品提供制限解除情報取得部１２４により商品提供制限情報が取得された場合、商品提供制限情報を変更して、商品の購入者に対するその商品の提供が制限されないことを商品制限情報から特定可能にしてもよい。例えば商品提供制限情報管理部１２３は、該当する購入権情報に含まれる権利状態を、「停止」から「有効」に変更してもよい。これにより、購入権の停止が解除されてもよい。購入権の停止が解除されることで、逐次購入による継続購入が可能となる。例えば第１実施形態の場合、顧客は、医師の診察を受けることなく、その商品を注文することができる。第２実施形態の場合、顧客はその商品を選択することができる。

発送予定情報管理部１１６は、定期自動購入で購入された商品について商品提供制限解除情報取得部１２４により商品提供制限情報が取得された場合、次回以降の配送のキャンセルを取り下げてもよい。これにより定期配送が再開されてもよい。例えば発送予定情報管理部１１６は、発送予定情報に含まれる該当の商品の発送状態を、「キャンセル」から「未発送」に変更してもよい。

商品提供制限解除通知送信部１２５は、商品提供制限解除情報取得部１２４により商品提供制限情報が取得された場合、購入者に向けて商品提供制限解除通知を送信してもよい。商品提供制限解除通知は、その購入者に対する商品の提供の制限が解除されることを、購入者に知らせる情報であってもよい。商品提供制限解除通知は、提供制限が解除された商品の名称を含んでもよい。商品提供制限解除通知送信部１２５は、その購入者宛ての電子メール又はインスタントメッセージで、商品提供制限解除通知を送信してもよい。或いは商品提供制限解除通知送信部１２５は、その購入者の顧客端末４へ、プッシュ通知で商品提供制限解除通知を送信してもよい。或いは商品提供制限解除通知送信部１２５は、その顧客端末４からの要求に応じて、商品提供制限解除通知を含む画面を顧客端末４に表示させる画面情報を、その顧客端末４へ送信してもよい。

図３０は、本実施形態に係る通信システムＳの処理例を示すシーケンス図である。例えば医師は、医師端末２を操作して、過去に処方中断を決定した経過観察を選択する。この操作に応じて、医師端末２は、各商品の処方継続の可否の決定結果を含む経過観察の結果を示す画面を表示する。この画面は、処方が中断された商品について、処方中断の解除の選択を受け付け可能であってもよい。図３０に示すように、医師は、何れかの商品の処方中断の解除を選択する（ステップＳ９０１）。この操作を検出した医師端末２は、販売管理サーバ１へ処方中断解除情報を送信する（ステップＳ９０２）。処方中断解除情報は、商品提供制限解除情報に相当する。処方中断解除情報は、例えばその経過観察の経過観察ＩＤ、経過観察の対象となった顧客の顧客ＩＤ、及び処方中断が解除された商品の商品ＩＤを含んでもよい。

販売管理サーバ１の商品提供制限情報管理部１２３は、処方中断解除情報に基づいて、経過観察の対象となった顧客の顧客ＩＤと処方中断が解除された商品の商品ＩＤとを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権ＤＢ１４ｇから検索する。商品提供制限情報管理部１２３は、検索された購入権情報に含まれる権利状態を、「有効」に変更する（ステップＳ９０３）。次いで、発送予定情報管理部１１６は、処方中断が解除された商品の購入形態が定期自動購入であるか否かを判定する（ステップＳ９０４）。例えば発送予定情報管理部１１６は、経過観察の対象となった顧客の顧客ＩＤと処方中断が解除された商品の商品ＩＤとを含む発送予定情報のうち、最新の発送予定日を含む発送予定情報を、発送予定ＤＢ１４ｈから検索してもよい。発送予定情報管理部１１６は、検索された発送予定情報に含まれる購入形態に基づいて判定を行ってもよい。購入形態が定期自動購入である場合（ステップＳ９０４：ＹＥＳ）、商品提供制限情報管理部１２３は、検索された発送予定情報に含まれる発送状態を、「未発送」に変更する（ステップＳ９０５）。なお、定期配送での一の配送で複数の商品が発送される場合、それらの商品のうち、処方継続が決定された商品は既に発送されていることがある。この場合、発送予定情報管理部１１６は、処方中断が解除された商品のための新しい発送予定情報を生成してもよい。また発送予定情報管理部１１６は、新たな発送日を設定してもよい。

ステップＳ９０５が終了した場合、または購入形態が逐次購入である場合（ステップＳ９９０４：ＮＯ）、商品提供制限解除通知送信部１２５は、商品提供制限解除通知メールを送信する（ステップＳ９０６）。商品提供制限解除通知メールは、商品提供制限解除通知を示す電子メールである。例えば商品提供制限解除通知送信部１２５は、処方中断解除情報に含まれる商品ＩＤに基づいて、処方中断が解除される商品の商品名を商品ＤＢ１４ｂから取得してもよい。商品提供制限解除通知送信部１２５は、その商品名を、商品提供制限解除通知メールの本文に追加してもよいまた商品提供制限解除通知送信部１２５は、処方中断解除情報に含まれる顧客ＩＤに基づいて、顧客の電子メールアドレスを取得してもよい。商品提供制限解除通知送信部１２５は、商品提供制限解除通知メールの受信者アドレスを、この電子メールアドレスに設定してもよい。

以上説明したように、本実施形態によれば、購入された商品の提供が制限された後、その制限が解除される場合がある。その場合、購入権ＤＢ１４ｇが再変更される。これにより、購入された商品を購入者へ提供することが制限されないことが、購入権ＤＢ１４ｇから特定可能となる。そのため、購入権ＤＢ１４ｇを参照することにより、購入者への商品の提供を可能とするための処理を行うことができる。

（付記１－１）複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段と、を備え、前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の購入に関連する基準日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御装置。

（付記１－２）前記送信された質問情報により示される前記質問に対する前記回答を示す回答情報を、前記購入者端末装置から受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者端末装置へ送信する結果情報送信手段と、を更に備えることを特徴とする付記１－１に記載のフォローアップ制御装置。

（付記１－３）前記可否情報取得手段は、前記受信された回答情報と、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否の選択を受け付け可能な画面を、前記購入商品の使用継続の可否を決定する決定者が利用する決定者端末装置に表示させる画面情報と、を前記決定者端末装置へ送信する回答情報送信手段と、前記送信された画面情報に基づいて前記決定者端末装置により表示された前記画面で選択された前記使用継続の可否を示す前記可否情報を、前記決定者端末装置から受信する可否情報受信手段と、を含むことを特徴とする付記１－２に記載のフォローアップ制御装置。

（付記１－４）前記購入商品は医薬品であり、前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段を更に備え、前記購入商品識別情報取得手段は、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記購入商品として、前記診察を通じて決済された商品を識別する前記購入商品識別情報を取得することを特徴とする付記１－１乃至１－３の何れか一に記載のフォローアップ制御装置。

（付記１－５）前記購入商品が前記購入者に向けて発送されたことを示す発送完了情報を、前記購入商品の発送者が利用する発送者端末装置から受信する発送完了情報受信手段と、前記発送完了情報受信手段により前記発送完了情報が受信された場合、所定の記憶手段に記憶された発送状態であって、前記購入商品の前記購入者への発送状態を、未発送状態から発送完了状態に変更する変更手段と、を更に備え、前記基準日は、前記購入商品の発送日であり、前記促し情報送信手段は、前記発送状態が前記発送完了状態に設定されていることを条件に前記促し情報を送信し、前記発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信することを特徴とする付記１－１乃至１－４の何れか一に記載のフォローアップ制御装置。

（付記１－６）コンピュータにより実行されるフォローアップ制御方法において、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得ステップと、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信ステップと、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信ステップと、を含み、前記促し情報送信ステップは、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の購入に関連する基準日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信ステップは、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御方法。

（付記１－７）コンピュータを、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段、として機能させ、前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の購入に関連する基準日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御プログラム。

（付記２－１）購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信手段と、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、所定の記憶手段に記憶された制限情報であって、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段と、を備えることを特徴とする商品提供制御装置。

（付記２－２）注文のために顧客により選択された選択商品を示す選択商品識別情報及び前記選択商品を選択した前記顧客を識別する顧客識別情報を取得する識別情報取得手段と、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記顧客と該選択商品の使用の可否を決定する決定者との面談を支援する面談支援手段と、前記面談支援手段より支援された前記面談後、前記選択商品の注文を確定させる確定手段と、を更に備え、前記確定手段は、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談なくして前記注文を確定させることを特徴とする付記２－１に記載の商品提供制御装置。

（付記２－３）前記面談支援手段は、前記顧客が利用する顧客端末装置と前記決定者が利用する決定者端末装置とを、前記面談のための通信を可能に接続させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続後、前記確定手段は前記注文を確定させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続を省略して、前記確定手段は前記注文を確定させることを特徴とする付記２－２に記載の商品提供制御装置。

（付記２－４）前記購入商品の提供は、前記購入者に対して前記購入商品を定期的に発送する形態の提供であり、前記変更手段により前記購入者に対して前記購入商品の提供が制限されることが特定可能に変更される場合、前記購入者に対する前記購入商品の次回の発送をキャンセルするキャンセル手段を更に備えることを特徴とする付記２－１乃至２－３の何れか一に記載の商品提供制御装置。

（付記２－５）商品の注文を可能とする電子商取引に係わる画面であって、顧客が利用する顧客端末装置からの要求に応じた要求商品に関する情報を含む画面を前記顧客端末装置に表示させる画面情報を、前記顧客端末装置へ送信する画面情報送信手段を更に備え、前記画面情報送信手段は、前記顧客に対して前記要求商品の提供が制限されないことが前記制限情報から特定される場合、前記要求商品を選択するための操作を受け付ける前記画面を表示させるための前記画面情報を送信し、前記顧客に対して前記要求商品の提供が制限されることが前記制限情報から特定される場合、前記操作を受け付けない前記画面を表示させるための前記画面情報を送信することを特徴とする付記２－１乃至２－４の何れか一に記載の商品提供制御装置。

（付記２－６）前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段を更に備え、前記変更手段は、前記解除情報取得手段により前記解除情報が取得された場合、前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されないことを前記制限情報から特定可能にすることを特徴とする付記２－１乃至２－５の何れか一に記載の商品提供制御装置。

（付記２－７）前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段と、前記解除情報取得手段により前記解除情報が受信された場合、前記キャンセル手段による前記発送のキャンセルを取り下げる取り下げ手段と、を更に備えることを特徴とする付記２－４に記載の商品提供制御装置。

（付記２－８）前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者向けに送信する結果情報送信手段を更に備えることを特徴とする付記２－１乃至２－７の何れか一に記載の商品提供制御装置。

（付記２－９）前記購入された商品は医薬品であり、前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段と、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記診察を通じて決済された商品の注文を確定させる確定手段と、を更に備え、前記質問情報送信手段は、前記確定手段により前記注文が確定された前記商品について、前記質問情報を送信することを特徴とする付記２－１乃至２－８の何れか一に記載の商品提供制御装置。

（付記２－１０）コンピュータにより実行される商品提供制御方法において、購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信ステップと、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信ステップと、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得ステップと、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、所定の記憶手段に記憶された制限情報であって、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更ステップと、を含むことを特徴とする商品提供制御方法。

（付記２－１１）コンピュータを、購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信手段と、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、所定の記憶手段に記憶された制限情報であって、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段、として機能させることを特徴とする商品提供制御プログラム。

１ 販売管理サーバ
２ 医師端末
３ 出荷端末
４ 顧客端末
１１ システム制御部
１２ システムバス
１３ 入出力インタフェース
１４ 記憶部
１４ａ 会員ＤＢ
１４ｂ 商品ＤＢ
１４ｃ カートＤＢ
１４ｄ 診察予約ＤＢ
１４ｅ 処方履歴ＤＢ
１４ｆ 注文ＤＢ
１４ｇ 購入権ＤＢ
１４ｈ 発送予定ＤＢ
１４ｉ 経過観察期間ＤＢ
１４ｊ 質問情報ＤＢ
１４ｋ 経過観察通知予定ＤＢ
１４ｌ 回答ＤＢ
１４ｍ 経過観察結果ＤＢ
１１１ 販売画面情報送信部
１１２ 選択商品識別情報取得部
１１３ カート情報管理部
１１４ 診察支援部
１１５ 注文確定部
１１６ 発送予定情報管理部
１１７ 購入商品識別情報取得部
１１８ 経過観察通知送信部
１１９ 質問情報送信部
１２０ 回答情報受信部
１２１ 使用継続可否情報取得部
１２２ 経過観察結果情報送信部
１２３ 商品提供制限情報管理部
１２４ 商品提供制限解除情報取得部
１２５ 商品提供制限解除通知送信部
ＮＷ ネットワーク

Claims (7)

1. 複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、
   前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、
   前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段と、
   を備え、
   前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品が前記購入者に向けて発送された発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、
   前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御装置。
2. 前記送信された質問情報により示される前記質問に対する前記回答を示す回答情報を、前記購入者端末装置から受信する回答情報受信手段と、
   前記受信された回答情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、
   前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者端末装置へ送信する結果情報送信手段と、
   を更に備えることを特徴とする請求項１に記載のフォローアップ制御装置。
3. 前記可否情報取得手段は、
   前記受信された回答情報と、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否の選択を受け付け可能な画面を、前記購入商品の使用継続の可否を決定する決定者が利用する決定者端末装置に表示させる画面情報と、を前記決定者端末装置へ送信する回答情報送信手段と、
   前記送信された画面情報に基づいて前記決定者端末装置により表示された前記画面で選択された前記使用継続の可否を示す前記可否情報を、前記決定者端末装置から受信する可否情報受信手段と、
   を含むことを特徴とする請求項２に記載のフォローアップ制御装置。
4. 前記購入商品は医薬品であり、
   前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段を更に備え、
   前記購入商品識別情報取得手段は、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記購入商品として、前記診察を通じて決済された商品を識別する前記購入商品識別情報を取得することを特徴とする請求項１乃至３の何れか一項に記載のフォローアップ制御装置。
5. 前記購入商品が前記購入者に向けて発送されたことを示す発送完了情報を、前記購入商品の発送者が利用する発送者端末装置から受信する発送完了情報受信手段と、
   前記発送完了情報受信手段により前記発送完了情報が受信された場合、所定の記憶手段に記憶された発送状態であって、前記購入商品の前記購入者への発送状態を、未発送状態から発送完了状態に変更する変更手段と、
   を更に備え、
   前記促し情報送信手段は、前記発送状態が前記発送完了状態に設定されていることを条件に前記促し情報を送信することを特徴とする請求項１乃至３の何れか一項に記載のフォローアップ制御装置。
6. コンピュータにより実行されるフォローアップ制御方法において、
   複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得ステップと、
   前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信ステップと、
   前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信ステップと、
   を含み、
   前記促し情報送信ステップは、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品が前記購入者に向けて発送された発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、
   前記質問情報送信ステップは、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御方法。
7. コンピュータを、
   複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、
   前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、
   前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段、
   として機能させ、
   前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品が前記購入者に向けて発送された発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、
   前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御プログラム。