IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 楽天株式会社の特許一覧

特許7723727商品提供制御装置、商品提供制御方法、及び商品提供制御プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-08-05
(45)【発行日】2025-08-14
(54)【発明の名称】商品提供制御装置、商品提供制御方法、及び商品提供制御プログラム
(51)【国際特許分類】
   G06Q 30/0601 20230101AFI20250806BHJP
   G16H 20/10 20180101ALI20250806BHJP
【FI】
G06Q30/0601 306
G16H20/10
【請求項の数】 12
(21)【出願番号】P 2023221436
(22)【出願日】2023-12-27
(65)【公開番号】P2025103796
(43)【公開日】2025-07-09
【審査請求日】2023-12-27
(73)【特許権者】
【識別番号】399037405
【氏名又は名称】楽天グループ株式会社
(74)【代理人】
【識別番号】110000958
【氏名又は名称】弁理士法人インテクト国際特許事務所
(74)【代理人】
【識別番号】100120189
【弁理士】
【氏名又は名称】奥 和幸
(74)【代理人】
【識別番号】100135518
【弁理士】
【氏名又は名称】青木 隆
(72)【発明者】
【氏名】平尾 カンナ
(72)【発明者】
【氏名】伊達 翼
(72)【発明者】
【氏名】小宮山 樹理
【審査官】松野 広一
(56)【参考文献】
【文献】国際公開第2023/009109(WO,A1)
【文献】特開2015-130140(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
G16H 20/10
(57)【特許請求の範囲】
【請求項1】
商品提供制御装置において、
顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報が所定の記憶手段に記憶されており、購入された購入商品の購入者に対して前記購入商品の提供が制限されていないことが、前記制限情報から特定可能であり、
前記購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の前記購入者が利用する購入者端末装置へ送信する質問情報送信手段と、
前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、
前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、
前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、前記記憶手段に記憶された前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段と、
を備え
前記変更手段は、前記購入者端末装置から前記商品提供制御装置へ前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御装置。
【請求項2】
注文のために顧客により選択された選択商品を示す選択商品識別情報及び前記選択商品を選択した前記顧客を識別する顧客識別情報を取得する識別情報取得手段と、
前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記顧客と前記選択商品の使用の可否を決定する決定者との面談を支援する面談支援手段と、
前記面談支援手段より支援された前記面談後、前記選択商品の注文を確定させる確定手段と、
を更に備え、
前記確定手段は、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談なくして前記注文を確定させることを特徴とする請求項1に記載の商品提供制御装置。
【請求項3】
前記面談支援手段は、前記顧客が利用する顧客端末装置と前記決定者が利用する決定者端末装置とを、前記面談のための通信を可能に接続させ、
前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続後、前記確定手段は前記注文を確定させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続を省略して、前記確定手段は前記注文を確定させることを特徴とする請求項2に記載の商品提供制御装置。
【請求項4】
前記購入商品の提供は、前記購入者に対して前記購入商品を定期的に発送する形態の提供であり、
前記変更手段により前記購入者に対して前記購入商品の提供が制限されることが特定可能に変更される場合、前記購入者に対する前記購入商品の次回の発送をキャンセルするキャンセル手段を更に備えることを特徴とする請求項1に記載の商品提供制御装置。
【請求項5】
商品の注文を可能とする電子商取引に係わる画面であって、顧客が利用する顧客端末装置からの要求に応じた要求商品に関する情報を含む画面を前記顧客端末装置に表示させる画面情報を、前記顧客端末装置へ送信する画面情報送信手段を更に備え、
前記画面情報送信手段は、前記顧客に対して前記要求商品の提供が制限されないことが前記制限情報から特定される場合、前記要求商品を選択するための操作を受け付ける前記画面を表示させるための前記画面情報を送信し、前記顧客に対して前記要求商品の提供が制限されることが前記制限情報から特定される場合、前記操作を受け付けない前記画面を表示させるための前記画面情報を送信することを特徴とする請求項1に記載の商品提供制御装置。
【請求項6】
前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段を更に備え、
前記変更手段は、前記解除情報取得手段により前記解除情報が取得された場合、前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されないことを前記制限情報から特定可能にすることを特徴とする請求項1乃至5の何れか一項に記載の商品提供制御装置。
【請求項7】
前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段と、
前記解除情報取得手段により前記解除情報が受信された場合、前記キャンセル手段による前記発送のキャンセルを取り下げる取り下げ手段と、
を更に備えることを特徴とする請求項4に記載の商品提供制御装置。
【請求項8】
前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者向けに送信する結果情報送信手段を更に備えることを特徴とする請求項1乃至5の何れか一項に記載の商品提供制御装置。
【請求項9】
前記購入された商品は医薬品であり、
前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段と、
前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記診察を通じて決済された商品の注文を確定させる確定手段と、
を更に備え、
前記質問情報送信手段は、前記確定手段により前記注文が確定された前記商品について、前記質問情報を送信することを特徴とする請求項1乃至5の何れか一項に記載の商品提供制御装置。
【請求項10】
前記変更手段は、前記質問情報送信手段により前記質問情報が送信されてから所定の期限までに前記購入者端末装置から前記商品提供制御装置へ前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする請求項1乃至5の何れか一項に記載の商品提供制御装置。
【請求項11】
コンピュータにより実行される商品提供制御方法において、
顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報が所定の記憶手段に記憶されており、購入された購入商品の購入者に対して前記購入商品の提供が制限されていないことが、前記制限情報から特定可能であり、
購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信ステップと、
前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信ステップと、
前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得ステップと、
前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、前記記憶手段に記憶された前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更ステップと、
を含み、
前記変更ステップは、前記購入者端末装置から前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御方法。
【請求項12】
コンピュータにより実行される商品提供制御プログラムにおいて、
顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報が所定の記憶手段に記憶されており、購入された購入商品の購入者に対して前記購入商品の提供が制限されていないことが、前記制限情報から特定可能であり、
前記コンピュータを、
購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信手段と、
前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、
前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、
前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、前記記憶手段に記憶された前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段、
として機能させ、
前記変更手段は、前記購入者端末装置から前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、購入された商品について所定の手続きを行う方法に関する。
【背景技術】
【0002】
従来、オンラインで商品の注文を可能とするウェブサイトが知られている。こうしたウェブサイトでは、一般的に、購入者は販売者と対面せずに商品を購入することができる。その一方で、販売される商品の中には、商品の購入に際して顧客が販売者等から説明を受けることが必要な商品も存在する。例えば、医薬品を購入する場合、顧客は、医療機関による診察を受けて処方を受ける必要があったり、薬剤師による服薬指導を受ける必要があったりする場合がある。また例えば、一部の化粧品を購入する場合、顧客は医師又はその他專門家等のカウンセリングを受ける必要がある場合がある。こうした購入の条件がある商品に対応したシステムも知られている。例えば特許文献1には、処方箋が必要な医療用医薬品について処方箋の情報を含んだ購入依頼と、処方箋が不要な医療用医薬品について処方箋の情報を含まない購入依頼と、それぞれを受け付け可能とし、購入依頼に基づいて、医療用医薬品を販売するための販売情報を生成することが開示されている。
【先行技術文献】
【特許文献】
【0003】
【文献】特開2020-135278号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、商品の購入後に購入者へのフォローアップが必要となる場合がある。例えば医薬品が購入された場合、その医薬品の服用に関して購入者に対する経過観察が実施される場合がある。従来の技術では、たとえ商品の購入までの手続きについては対応することができたとしても、購入後の対応については不十分であった。また、購入者がその商品を継続して購入することを望んでいても、購入後の購入者の状況によっては、商品の提供を制限する必要がある。
【0005】
本発明は以上の点に鑑みてなされたものであり、その課題の一例は、商品の購入後における購入者の状況に応じて商品の提供を制限するための情報を記憶させることを可能とする商品提供制御装置、商品提供制御方法、及び商品提供制御プログラムを提供することにある。
【課題を解決するための手段】
【0006】
(適用例1)適用例1は、商品提供制御装置において、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報が所定の記憶手段に記憶されており、購入された購入商品の購入者に対して前記購入商品の提供が制限されていないことが、前記制限情報から特定可能であり、前記購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の前記購入者が利用する購入者端末装置へ送信する質問情報送信手段と、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、前記記憶手段に記憶された前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段と、を備え、前記変更手段は、前記購入者端末装置から前記商品提供制御装置へ前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御装置である。
【0007】
本適用例によれば、購入された商品についてのフォローアップのための質問が購入者に提示される。この質問に対する回答を示す回答情報が、購入者端末から受信される。この回答情報に基づいて、購入された商品の使用継続の可否を示す可否情報が取得される。その商品の使用継続が不可である場合、制限情報が変更される。これにより、購入された商品を購入者へ提供することが制限されていることが、制限情報から特定可能となる。そのため、制限情報を参照することにより、購入者への商品の提供を制限するための処理を行うことができる。従って、商品の購入後における購入者の状況に応じて商品の提供を制限するための情報を記憶させることができる。
【0008】
(適用例2)適用例2は、注文のために顧客により選択された選択商品を示す選択商品識別情報及び前記選択商品を選択した前記顧客を識別する顧客識別情報を取得する識別情報取得手段と、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記顧客と前記選択商品の使用の可否を決定する決定者との面談を支援する面談支援手段と、前記面談支援手段より支援された前記面談後、前記選択商品の注文を確定させる確定手段と、を更に備え、前記確定手段は、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談なくして前記注文を確定させることを特徴とする商品提供制御装置である。
【0009】
本適用例によれば、注文のために顧客により選択された商品をその顧客に提供することが制限される場合、顧客とその商品の使用可否を決定する決定者との面談が可能とされる。その面談後、選択された商品の注文が確定する。選択された商品をその顧客に提供することが制限されない場合、顧客と決定者との面談を省略して、選択された商品の注文が確定する。そのため、商品の提供が制限されるか否かで、その商品の注文の確定に面談が必要であるか否かが異なる。従って、注文のための条件を設けることで、商品の提供を適切に制限することができる。
【0010】
(適用例3)適用例3は、前記面談支援手段は、前記顧客が利用する顧客端末装置と前記決定者が利用する決定者端末装置とを、前記面談のための通信を可能に接続させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続後、前記確定手段は前記注文を確定させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続を省略して、前記確定手段は前記注文を確定させることを特徴とする商品提供制御装置である。
【0011】
本適用例によれば、顧客端末と決定者端末とが通信接続されることにより、顧客と決定者とのオンラインでの面談が可能となる。オンラインでの面談後、注文が確定する。そのため、顧客に商品の提供が制限される場合、その商品の注文を確定させるための条件としての面談を、オンラインで実現することができる。
【0012】
(適用例4)適用例4は、前記購入商品の提供は、前記購入者に対して前記購入商品を定期的に発送する形態の提供であり、前記変更手段により前記購入者に対して前記購入商品の提供が制限されることが特定可能に変更される場合、前記購入者に対する前記購入商品の次回の発送をキャンセルするキャンセル手段を更に備えることを特徴とする商品提供制御装置である。
【0013】
本適用例によれば、購入された商品を購入者へ提供することが制限されない場合、その商品は購入者へ定期的に発送される。購入された商品を購入者へ提供することが制限される場合、その商品の次回の発送がキャンセルされる。これにより、商品の定期的な発送が停止される。そのため、商品が定期的に発送される形態における商品の提供を適切に制限することができる。
【0014】
(適用例5)適用例5は、商品の注文を可能とする電子商取引に係わる画面であって、顧客が利用する顧客端末装置からの要求に応じた要求商品に関する情報を含む画面を前記顧客端末装置に表示させる画面情報を、前記顧客端末装置へ送信する画面情報送信手段を更に備え、前記画面情報送信手段は、前記顧客に対して前記要求商品の提供が制限されないことが前記制限情報から特定される場合、前記要求商品を選択するための操作を受け付ける前記画面を表示させるための前記画面情報を送信し、前記顧客に対して前記要求商品の提供が制限されることが前記制限情報から特定される場合、前記操作を受け付けない前記画面を表示させるための前記画面情報を送信することを特徴とする商品提供制御装置である。
【0015】
本適用例によれば、顧客端末装置からの要求に応じた商品の情報を含む画面が顧客端末装置に表示される。顧客に対してその商品の提供が制限されない場合、その商品を選択する操作が可能なように、その画面が表示される。そのため、顧客はその商品を注文することができる。顧客に対してその商品の提供が制限される場合、その商品を選択する操作が不可能なように、その画面が表示される。そのため、顧客はその商品を注文することができない。そのため、電子商取引に係る画面が、商品を選択する操作を受け入れるか否かによって、商品の提供の制限を制御することができる。
【0016】
(適用例6)適用例6は、前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段を更に備え、前記変更手段は、前記解除情報取得手段により前記解除情報が取得された場合、前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されないことを前記制限情報から特定可能にすることを特徴とする商品提供制御装置である。
【0017】
本適用例によれば、購入された商品の提供が制限された後、その制限が解除される場合がある。その場合、制限情報が再変更される。これにより、購入された商品を購入者へ提供することが制限されないことが、制限情報から特定可能となる。そのため、制限情報を参照することにより、購入者への商品の提供を可能とするための処理を行うことができる。
【0018】
(適用例7)適用例7は、前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段と、前記解除情報取得手段により前記解除情報が受信された場合、前記キャンセル手段による前記発送のキャンセルを取り下げる取り下げ手段と、を更に備えることを特徴とする商品提供制御装置である。
【0019】
本適用例によれば、定期的に購入者へ発送される商品の提供が制限された後、その制限が解除される場合がある。その場合、その商品の次回の発送のキャンセルが取り消される。これにより、商品の定期的な発送を再開することができる。
【0020】
(適用例8)適用例8は、前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者向けに送信する結果情報送信手段を更に備えることを特徴とする商品提供制御装置である。
【0021】
本適用例によれば、購入された商品の使用継続の可否を、購入者に提示することができる。
【0022】
(適用例9)適用例9は、前記購入された商品は医薬品であり、前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段と、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記診察を通じて決済された商品の注文を確定させる確定手段と、を更に備え、前記質問情報送信手段は、前記確定手段により前記注文が確定された前記商品について、前記質問情報を送信することを特徴とする商品提供制御装置である。
(適用例10)適用例10は、前記変更手段は、前記質問情報送信手段により前記質問情報が送信されてから所定の期限までに前記購入者端末装置から前記商品提供制御装置へ前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御装置である。
【0023】
本適用例によれば、購入者端末と医師端末とが通信接続されることにより、医師によるオンラインでの診察が可能となる。この診察を通じて決定された医薬品が購入される。この購入された医薬品について、フォローアップのための質問情報が送信される。そのため、診察を受けて医薬品を購入した顧客の状況に応じて医薬品の提供を制限するための情報を記憶させることができる。
【0024】
(適用例11)適用例11は、コンピュータにより実行される商品提供制御方法において、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報が所定の記憶手段に記憶されており、購入された購入商品の購入者に対して前記購入商品の提供が制限されていないことが、前記制限情報から特定可能であり、購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信ステップと、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信ステップと、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得ステップと、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、前記記憶手段に記憶された前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更ステップと、を含み、前記変更ステップは、前記購入者端末装置から前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御方法である。
【0025】
(適用例12)適用例12は、コンピュータにより実行される商品提供制御プログラムにおいて、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報が所定の記憶手段に記憶されており、購入された購入商品の購入者に対して前記購入商品の提供が制限されていないことが、前記制限情報から特定可能であり、前記コンピュータを、購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信手段と、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、前記記憶手段に記憶された前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段、として機能させ、前記変更手段は、前記購入者端末装置から前記回答情報が送信されなかった場合、前記購入者に対して前記購入商品の提供を制限しないことを特徴とする商品提供制御プログラムである。
【発明の効果】
【0026】
本発明によれば商品の購入後における購入者の状況に応じて商品の提供を制限するための情報を記憶させることができる。
【図面の簡単な説明】
【0027】
図1】一実施形態に係る通信システムSの概要構成の一例を示す図である。
図2】(a)は、逐次購入の一例を示す図である。(b)は、定期自動購入の一例を示す図である。
図3】顧客端末4の画面遷移の一例を示す図である。
図4】一実施形態に係る販売管理サーバ1の概要構成の一例を示すブロック図である。
図5】販売管理サーバ1のデータベースに記憶される情報の例を示す図である。
図6】販売管理サーバ1のデータベースに記憶される情報の例を示す図である。
図7】販売管理サーバ1のデータベースに記憶される情報の例を示す図である。
図8】一実施形態に係る販売管理サーバ1におけるシステム制御部11の機能ブロックの一例を示す図である。
図9】商品画面1200の一例を示す図である。
図10】経過観察通知メールの一例を示す図である。
図11】(a)乃至(c)は、経過観察通知の送信タイミングの例を示す図である。
図12】経過観察のための質問の内容の例を示す図である。
図13】質問シート画面の一例を示す図である。
図14】経過観察画面の一例を示す図である。
図15】処方継続の可否の入力後における経過観察画面の一例を示す図である。
図16】(a)乃至(c)は、経過観察結果メールの一例を示す図である。
図17】購入権DB14gの更新例を示す図である。
図18】商品の提供の制限例を示す図である。
図19】定期自動購入における商品の提供の制限例を示す図である。
図20】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図21】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図22】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図23】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図24】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図25】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図26】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
図27】商品画面1200の一例を示す図である。
図28】一実施形態に係る販売管理サーバ1のシステム制御部11により実行される商品画面情報送信処理の一例を示すフローチャートである。
図29】一実施形態に係る販売管理サーバ1におけるシステム制御部11の機能ブロックの一例を示す図である。
図30】一実施形態に係る通信システムSの処理例を示すシーケンス図である。
【発明を実施するための形態】
【0028】
以下、図面を参照して本発明の実施形態について詳細に説明する。少なくとも一の実施形態においては、販売者が顧客に対して商品を販売してもよい。商品は、例えば実店舗で販売されてもよいし、オンラインで販売されてもよい。実店舗で販売される商品は、販売者から顧客に手渡されてもよい。オンラインで販売される商品は、販売者から顧客へ発送されてもよい。販売者の例として、医療機関、薬局、化粧品店、専門店等が挙げられる。
【0029】
少なくとも一の実施形態に係るフォローアップ制御装置(または商品提供制御装置)は、商品を購入した購入者に対するフォローアップを実施するか若しくはフォローアップの実施を支援してもよい。フォローアップは、例えば商品の購入後の購入者の状態及びその商品の状態のうち少なくとも何れか一方を顧客に確認することと、確認された状態に基づいて、必要に応じて購入者に情報を提供することと、を含んでもよい。購入者に提供される情報は、例えば購入者に対する助言を含んでもよいし、商品の使用についての何らかの判定結果を含んでもよい。フォローアップ制御装置は、顧客の状況を確認するために、顧客に対して質問情報を送信してもよい。質問情報は、購入者の状態や商品の状態を確認するための質問を示す情報であってもよい。フォローアップ制御装置は、購入者が利用する購入者端末から回答情報を受信してもよい。回答情報は、質問情報により示される質問に対する購入者若しくは商品の使用者の回答を示す情報であってもよい。商品の購入者とその商品の使用者とは同一人物であってもよい。或いは、使用者は購入者の関係者であってもよい。購入者は、関係者のために商品を購入する場合がある。関係者の例として、家族、親戚、友人等が挙げられる。
【0030】
少なくとも一の実施形態に係るフォローアップ制御装置は、購入者端末装置から回答情報を受信すると、フォローアップの結果を示すフォローアップ結果情報を送信してもよい。フォローアップ結果情報は、前述したとおり、購入者に提供される情報を含んでもよい。フォローアップ制御装置は、所定の決定者へ回答情報を送信してもよい。決定者は、購入者に対して提供される情報を決定する人物であってもよい。決定者の例として、販売者の従業員、購入された商品の專門家、医師、薬剤師、コンサルタント等が挙げる。フォローアップ制御装置は、その決定者からフォローアップ結果情報を受信してもよい。或いは、フォローアップ制御装置は、回答情報に基づいて、提供する情報を自動的に決定してもよい。例えば、回答と提供される情報とが予め予め関連付けて、所定の記憶手段に記憶されてもよい。
【0031】
購入者に対して提供される情報は、購入された商品の使用継続の可否を含んでもよい。決定者又はフォローアップ制御装置が、使用継続の可否を決定してもよい。購入者からの回答が、購入者が商品を使用継続することに対して問題がない場合、使用継続が決定されてもよい。購入者からの回答が、購入者が商品を使用継続することに対して問題がある場合、使用継続の不可若しくは使用中止が決定されてもよい。
【0032】
少なくとも一の実施形態においては、顧客により同一の商品が継続的に提供されてもよい。例えば、購入者による商品の再注文若しくは再購入が可能であったり、購入者に対して商品が継続的に発送されたりしてもよい。フォローアップにおいて、購入された商品の使用中止が決定された場合、フォローアップ制御装置は、その商品をその購入者へ提供することを制限するための処理を実行してもよい。商品の提供の制限の例として、商品の購入を不可能にすること、追加的な条件を購入者が満たした場合に限り購入を許可すること、商品を発送しないこと、商品の購入予定若しくは発送予定をキャンセルすること等が挙げられる。
【0033】
販売者が販売する商品の全部がフォローアップの対象であってもよい。或いは、一部の商品がフォローアップの対象であってもよい。例えば、顧客(または関係者)と決定者との面談が実施されたことを条件に、その顧客が購入可能となる商品が、フォローアップの対象となっていてもよい。例えば、遅くともその商品の注文の確定前に面談が行われることが必要であってもよい。面談の例として、診察、カウンセリング、コンサルティング、服薬指導、情報提供等が挙げられる。面談は、オフラインで行われてもよいし、オンラインで行われてもよい。面談においては、決定者から顧客に対してその商品の説明が行われてもよい。また面談においては、決定者が顧客の状態を確認してもよい。面談において、決定者が顧客に対してその商品の使用を許可した場合に限り、顧客は商品の購入が可能であってもよい。或いは、決定者による許可を要さずに、顧客は商品の購入が可能であってもよい。購入される商品は、決定者との面談前に顧客が選択してもよいし、面談中に決定者が決定してもよし、面談後に顧客又は決定者が決定してもよい。購入前の面談が不要な商品の中にも、フォローアップの対象となっている商品が存在してもよい。また、購入前の面談が必要な商品の中にも、フォローアップの対象となっていない商品が存在してもよい。
【0034】
決定者が医師である場合、フォローアップの対象となる商品は、医療用医薬品を含んでもよい。医療用医薬品を販売者が顧客へ提供するためには、医師の処方が必要である。この場合における商品の購入前の面談は、診察であってもよい。またこの場合のフォローアップは、経過観察であってもよい。医療用医薬品以外の医薬品の中にも、フォローアップの対象となる医薬品が存在してもよい。また医療用医薬品以外の化粧品の中にも、フォローアップの対象となる化粧品が存在してもよい。決定者が薬剤師である場合、フォローアップの対象となる商品は、医薬品を含んでもよい。この場合における商品の購入前の面談は、服薬指導又は薬剤師から顧客に対する情報提供であってもよい。
【0035】
以降においては、販売者は医療機関であり、フォローアップの対象となる商品は医療用医薬品であり、決定者は医師である場合の実施例について説明する。しかしながら、上述したように、販売者が医療機関とは異なる形態や、フォローアップの対象となる商品が医療用医薬品とは異なる形態や、販売者が医療機関とは異なる形態にも、本願は適用可能である。
【0036】
[1.第1実施形態]
[1-1.通信システムの構成]
先ず、本実施形態に係る通信システムSの構成及び機能概要について、図1を参照して説明する。図1は、本実施形態に係る通信システムSの概要構成の一例を示す図である。
【0037】
図1に示すように、通信システムSは、販売管理サーバ1と、少なくとも一の医師端末2と、少なくとも一の出荷端末3と、複数の顧客端末4と、を含んで構成されてもよい。販売管理サーバ1、医師端末2、出荷端末3及び各顧客端末4は、ネットワークNWを介して互いに接続される。ネットワークNWは、例えばインターネット、専用通信回線(例えば、CATV(Community Antenna Television)回線)、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築されている。
【0038】
販売管理サーバ1は、所定の医薬品EC(Electronic Commerce)プラットフォームに関する各種処理を行うサーバ装置であってもよい。医薬品ECプラットフォームは、顧客がオンラインで所定の医療機関から医薬品等を購入可能とするウェブサイトであってもよい。医薬品ECプラットフォームで販売される主な商品は医薬品であってもよい。販売される医薬品として、医療用医薬品と一般用医薬品とがあってもよい。医療用医薬品は、医師による処方に基づいて提供される医薬品である。一般用医薬品は、医師による処方が不要な医薬品である。医薬品ECプラットフォームでは、医薬品以外の商品も販売されてもよい。そうした商品の例として、化粧品、健康食品等が挙げられる。販売管理サーバ1は、例えば顧客端末4等からの要求に応じて、医薬品ECプラットフォームに含まれるウェブページ等のコンテンツを顧客端末4へ送信してもよい。また、販売管理サーバ1は、顧客からの商品の注文を受け付けるための処理を実行してもよい。更に、販売管理サーバ1は、顧客が医療用医薬品を注文するために医療機関での診察(または診療)の予約を受け付ける処理を実行してもよい。この診察は、オンライン診察であってもよいし、オフラインで行われる診察であってもよい。また更に、販売管理サーバ1は、オンライン診察が予約された場合において、そのオンライン診察を実現するための処理を実行してもよい。オンライン診察では、医師端末2と顧客端末4との間で音声及び映像の通信が行われてもよい。
【0039】
医師端末2は、医療機関に利用される端末装置であってもよい。この医師端末2は、医師が主に利用する端末装置であってもよい。例えば、医師端末2は、電子カルテの表示及び入力、処方の入力、経過観察のための質問及び回答の表示、購入後の医療用医薬品の処方継続の可否の入力等に用いられてもよい。また、医師端末2は、オンライン診察のために用いられてもよい。医師端末2の例として、パーソナルコンピュータ、タブレットコンピュータ等が挙げられる。医師端末2は、映像を撮影するためのビデオカメラを備えてもよいし、ビデオカメラと接続可能となっていてもよい。また、医師端末2は、音声の入力に用いられるマイクロホンを備えてもよいし、マイクロホンと接続可能になっていてもよい。医師端末2には、ウェブブラウザや電子メールクライアント等のソフトウェアが組み込まれていてもよい。医師端末2は、購入された商品の使用継続の可否を決定する決定者としての医師が利用する決定者端末装置の一例であってもよい。
【0040】
出荷端末3は、医療機関が主として商品の出荷の際に用いるための端末装置であってもよい。この出荷端末3は、薬剤師やその他の従業員が利用する端末装置であってもよい。例えば、出荷端末3は、発送される商品の情報や配送先に関する情報を表示してもよい。従業員は、出荷端末3に表示された情報に基づいて、注文された商品の出荷作業を行ってよい。出荷端末3の例として、パーソナルコンピュータ、タブレットコンピュータ等が挙げられる。出荷端末3には、ウェブブラウザや電子メールクライアント等のソフトウェアが組み込まれていてもよい。
【0041】
各顧客端末4は、医薬品ECプラットフォームを利用可能な商品の買い手としての顧客が利用する端末装置であってもよい。各顧客端末4は、例えば顧客による操作に基づいて販売管理サーバ1等からウェブページ等のコンテンツを受信して表示してもよい。顧客端末4の例として、スマートフォン、タブレットコンピュータ等の携帯情報端末、携帯電話機、PDA(Personal Digital Assistant)、パーソナルコンピュータ、セットトップボックス等が挙げられる。各顧客端末4は、映像を撮影するためのビデオカメラを備えてもよいし、ビデオカメラと接続可能となっていてもよい。また、各顧客端末4は、音声の入力に用いられるマイクロホンを備えてもよいし、マイクロホンと接続可能になっていてもよい。各顧客端末4には、ウェブブラウザや電子メールクライアント等のソフトウェアが組み込まれていてもよい。携帯用の顧客端末4には、専用アプリのインストールが可能であってもよい。専用アプリは、医薬品ECプラットフォームを利用するためのアプリケーションである。顧客端末4は、専用アプリに従って、販売管理サーバ1へ各種の要求を送信し、販売管理サーバ1からコンテンツを受信して表示してもよい。
【0042】
[1-2.商品の継続購入及び経過観察]
次に商品の継続購入について、図2を参照して説明する。或る商品を初めて購入することを、初回購入と称する。商品の継続購入とは、或る商品を初回購入した後、顧客がその商品を再購入することであってもよい。販売者からの立場からすると、継続購入とは、顧客に対して同一の商品を継続的に提供することに相当してもよい。特に本実施形態における継続購入とは、顧客が特定の条件若しくは追加的な条件を満たす必要なく同一の商品を再購入することであってもよい。或いは商品の継続購入は、フォローアップの対象となる商品を一度購入した後で、顧客がその商品を再購入することであってもよい。特定の条件若しくは追加的な条件とは、その商品を初めて購入する際に顧客が満たすべき条件であってもよい。例えば商品が医療用医薬品である場合、この条件は、医師の診察を受けること若しくは医師にその商品を処方してもらうことであってもよい。
【0043】
医療用医薬品には、最大処方量が定められてもよい。最大処方量は、1回の処方若しくは1枚の処方箋で、最大どれだけの量の医療用医薬品を処方することができるかを示してもよい。商品の量は、例えば商品が使用、服用若しくは消費されることが予定されている期間の長さで示されてもよい。この期間の長さは、例えば日数、週数若しくは月数で示されてもよい。本実施形態では月数が用いられるものとする。例えば、毎日、朝昼晩の3回1錠ずつ服用する医薬品の1ヶ月分の量は、90錠に相当してもよい。最大処方量の例として、6ヶ月、12ヶ月等が挙げられる。最大処方量は、例えば医薬品ECプラットフォーム内において、全医療用医薬品で共通に定められていてもよい。或いは最大処方量は、医薬品ごとに定められていてもよい。或いは最大処方量は、医薬品のカテゴリごとに定められていてもよい。或いは最大処方量は、処方の際に医師により決定されてもよい。本実施形態において、最大処方量は全医療用医薬品で共通であるものとする。
【0044】
医師の診察を受ける等の特定の条件を満たすことを条件として顧客が獲得する権利であって、商品を初回購入したり継続購入したりすることができる権利を、購入権と称する。初回購入で顧客が購入する医療用医薬品の量は、最大処方量以下の範囲で決定される。例えば顧客が購入量を選択してもよいし、医師が購入量を選択してもよい。最大処方量から初回購入時の医薬品の購入量を減算して得られる残量以下の範囲内で、顧客はその医薬品を継続購入することが可能であってもよい。購入権の主要な効果は、継続購入の際に、改めての医師の診察及び処方の何れも必要としないことであってもよい。
【0045】
購入権が設定されている商品について顧客が既にその商品を購入している総量若しくは販売者が顧客に発送している総量を、既購入量と称する。既購入量が最大処方量に達すると、購入権は消滅してもよい。また、その商品が処方された日から最大処方量に相当する長さの期間が経過した場合、購入権は消滅してもよいし、消滅しなくてもよい。一度購入権が消滅した商品を顧客が再購入するには、医師の診察を受ける等の特定の条件を顧客が満たす必要があってもよい。
【0046】
医薬品ECプラットフォームにおける商品の継続購入の形態として、逐次購入及び定期自動購入が存在してもよい。逐次購入及び定期自動購入のうち何れの形態で商品を購入するかを、顧客が選択可能になっていてもよい。或いは、逐次購入及び定期自動購入のうち何れか一方のみが可能なように、医薬品ECプラットフォームが構成されていてもよい。或いは、商品ごと若しくは商品のカテゴリごとに、逐次購入が可能であるか否か及び定期自動購入が可能であるか否かが予め定められていてもよい。
【0047】
逐次購入は、顧客がその都度商品を選択して注文する形態の購入であってもよい。図2(a)は、逐次購入の一例を示す図である。例えば顧客は、最大処方量が6ヶ月分の量である商品を初めて注文した。このとき、顧客は医師の診察を受けて、医師はその商品を処方した。図2(a)に示すように、顧客は1ヶ月分の商品を注文した。医療機関から顧客へ1ヶ月分の商品が発送された。この時点で、顧客は5ヶ月分の商品を購入する権利を有している。処方から1ヶ月後、顧客は同じ商品を2ヶ月分注文した。このとき、医師による診察は省略される。医療機関から顧客へ2ヶ月分の商品が発送された。この時点で、顧客は3ヶ月分の商品を購入する権利を有している。処方から3ヶ月後、顧客は同じ商品を3ヶ月分注文した。このとき、医師による診察は省略される。医療機関から顧客へ3ヶ月分の商品が発送された。この時点で、顧客の購入権は消滅する。2回目以降の商品の購入は、継続購入に相当してもよい。
【0048】
定期自動購入は、定期的に商品が購入者へ発送される形態の購入であってもよい。定期的な商品の配送は、定期配送とも称される。図2(b)は、定期自動購入の一例を示す図である。例えば、顧客は最大処方量が6ヶ月分の量である商品を初めて注文した。このとき、顧客は医師の診察を受けて、医師はその商品を処方した。図2(b)に示すように、先ず、医療機関から顧客へ1ヶ月分の商品が発送された。その後、1ヶ月間隔で医療機関から顧客へ1ヶ月分の商品が発送された。販売管理サーバ1は、その都度、1ヶ月分の商品の購入代金を自動的に決済してもよい。初回の発送を含めて、合計6回商品が発送されると、顧客の購入権は消滅する。2回目以降の決済及び発送は、継続購入に相当してもよい。なお、一度に配送される商品の量及び発送の間隔は、1ヶ月に限定されない。
【0049】
購入権が有効である期間若しくは最大処方量に相当する長さの期間の間に、顧客に対するフォローアップの一例として、経過観察が1回又は複数回が行われてもよい。例えば図2(a)及び図2(b)に示す例では、1ヶ月ごとに経過観察が行われている。しかしながら、経過観察の間隔は1ヶ月に限定されない。購入形態が逐次購入の場合、顧客は既購入量が最大処方量に達するまで商品を購入する必要はない。顧客は継続購入を中断してもよい。購入形態が定期自動購入である場合、顧客は途中で定期自動購入をキャンセル可能であるように、販売管理サーバ1が構成されていてもよい。これらの場合、既購入量に相当する期間中のみ、経過観察が行われてもよい。なお、初回購入に、医師の診察等の特定の条件を顧客が満たす必要がない商品についても、経過観察又はフォローアップが実施されてもよい。
【0050】
経過観察において、販売管理サーバ1は、その経過観察のための質問を示す質問情報を顧客端末4へ送信してもよい。顧客は、質問に対する回答を入力してもよい。販売管理サーバ1は、入力された回答を示す回答情報を、医師端末2へ送信してもよい。医師は、顧客からの回答に基づいて、顧客による商品の使用継続の可否を決定してしてもよい。例えば医師は、処方継続及び処方中止の何れかを決定してもよい。処方継続は、その商品の使用を継続してもよいことを示してもよい。処方中止は、その商品の使用の継続を中止すべきであることを示してもよい。処方中止が決定された場合、その商品について設定された購入権は、消滅してもよいし、停止されてもよい。これによって、医療機関から顧客へのその商品の提供は制限されてもよい。商品の提供の制限は、顧客によるその商品の購入が制限されることに相当してもよい。
【0051】
[1-3.画面遷移]
次に、医薬品ECプラットフォームにおける商品の選択から注文の完了までにおける顧客端末4の画面の遷移例について、図3を用いて説明する。医薬品ECプラットフォームにおける画面は、商品の注文を可能とする電子商取引に係わる画面であってもよい。図3は、顧客端末4の画面遷移の一例を示す図である。前述したように、医薬品ECプラットフォームにおいては、医療用医薬品と、一般用医薬品及び商品と、が販売される。医療用医薬品を販売するためには医師による処方が必要となる。処方を行うためには、医師が顧客を診察する必要がある。そのため、医療用医薬品とその他の商品とでは、商品を注文するための画面の遷移が異なる。各画面は、例えばウェブページで販売管理サーバ1から顧客端末4に提供されてもよい。
【0052】
図3に示すように、顧客端末4が医薬品ECプラットフォームにアクセスすると、先ず商品選択画面1100が表示されてもよい。商品選択画面1100は、詳細な情報を見たい商品を顧客が選択するための画面であってもよい。商品選択画面1100は、複数種類の画面を含んでもよい。例えば、商品選択画面1100は、検索条件入力画面、検索結果画面等を含んでもよい。検索条件入力画面は、商品の検索条件を入力又は選択するための画面であってもよい。検索条件の例として、商品のカテゴリ、キーワード等が挙げられる。検索結果画面は、入力された検索条件を満たす商品の一覧を検索結果として表示する画面であってもよい。
【0053】
検索結果の中から顧客が何れかの商品を選択すると、商品画面1200が表示されてもよい。商品画面1200は、選択された商品に関する詳細な情報が表示される画面であってもよい。商品画面1200において、顧客は、その商品を、注文するために選択する操作を行うことができる。例えば、その商品をカートに入れる操作が可能であってもよい。カートは、医薬品ECプラットフォームにおいて各顧客が有する仮想的な買い物用の入れ物又はリストであってもよい。顧客は、カートに入っている商品を注文することができる。
【0054】
その後、顧客による操作に基づいて、カート画面1300が表示されてもよい。カート画面1300は、現在カートに入っている商品の一覧を示す画面であってもよい。カート画面1300において、顧客は、注文しようとする商品の削除や数量の変更が可能であってもよい。
【0055】
カートに入れられている商品の中に医療用医薬品が1つも存在しない場合、次に注文内容確認画面2100が表示されてもよい。注文内容確認画面2100は、注文内容を示すとともに、その注文内容で注文を確定することを示す画面であってもよい。注文内容確認画面2100に示される注文内容は、カートに入れられている商品を含む。顧客は、注文内容確認画面2100で注文内容を確認して、注文を確定させる操作を行う。この操作に応じて、注文完了画面2200が表示されてもよい。注文完了画面2200は、注文が確定したことを示す画面であってもよい。
【0056】
一方、カートに入れられている商品の中に医療用医薬品が存在する場合、カート画面1300の次に注文申込内容確認画面1400が表示されてもよい。注文申込内容確認画面1400は、カートに入れられている商品の注文を申し込む(または注文の受け付けをリクエストする)ための画面であってもよい。注文申込内容確認画面1400は、申し込まれる注文内容を含んでもよい。注文内容は、カートに入れられている商品を含んでもよい。
【0057】
顧客が注文の申し込みを行うと、診察予約画面1500が表示されてもよい。診察予約画面1500は、顧客が注文を申し込んだ医療用医薬品の処方を受けるための診察の日時を選択するための画面であってもよい。この時点では、顧客の注文はまだ正式には受け付けられていなくてもよい。
【0058】
顧客が診察日時を選択すると、診察予約確認画面1600が表示されてもよい。診察予約確認画面1600は、診察の予約内容を確認するための画面であってもよい。
【0059】
診察予約確認画面1600に表示された予約内容で顧客が診察の予約を確定させると、診察予約受付完了画面1700が表示されてもよい。診察予約受付完了画面1700は、診察の予約が完了したことを示す画面であってもよい。
【0060】
次に、問診票画面1800が表示されてもよい。問診票画面1800は、診察に先だって顧客が問診票に記入するための画面であってもよい。
【0061】
診察の予約が確定した後、顧客宛てに診察通知メールが送信されてもよい。診察通知メールは、予約された診察に関する情報を通知する電子メールであってもよい。診察通知メールには、診察日時が記載されているとともに、オンライン診察用のURLが記載されてもよい。診察日当日に、顧客が診察通知メールからこのURLを選択すると、顧客端末4は販売管理サーバ1にアクセスして、診察待機画面1900が表示されてもよい。或いは、医薬品ECプラットフォーム内の所定のメニューから顧客がオンライン診察を選択すると、診察待機画面1900が表示されてもよい。診察待機画面1900は、診察開始まで待機状態であることを示す画面であってもよい。
【0062】
その後、診察開始時刻になると、顧客診察画面2000が表示されてもよい。顧客診察画面2000は、オンライン診察において顧客が医療機関の医師と会話するための画面であってもよい。顧客診察画面2000において、顧客は、医師から医療用医薬品に関する説明を受けることができる。また、顧客診察画面2000には、注文が予定される商品として、顧客が選択した商品に関する情報が表示されてもよい。診察を行っている医師により、その注文内容が変更されることがあってもよい。
【0063】
オンライン診察が終了して医師による処方が行われると、注文内容確認画面2100が表示されてもよい。注文内容確認画面2100は、最終的な注文内容を示すとともに、その注文内容で注文を確定させるための操作を受け付ける画面であってもよい。
【0064】
顧客が注文を確定させると、販売サーバ1は注文を受け付けて、注文された商品の購入代金を決済する処理を行ってもよい。決済が完了すると、注文完了画面2200が表示されてもよい。注文完了画面2200は、注文の完了及び決済の完了を示す画面であってもよい。決済が完了すると、注文された商品が医療機関から顧客へ発送されてもよい。
【0065】
なお、顧客により選択された医薬品が医療用医薬品である場合、その医薬品を医療機関が発送するのではなく、その顧客へ処方箋を提供するように販売管理サーバ1が構成されてもよい。例えば、医師による処方が行われると、販売管理サーバ1又は医師端末2は、処方箋を印刷してもよい。医療機関の従業員は、その処方箋を顧客へ郵送してもよい。或いは、販売管理サーバ1は、電子処方箋を生成してもよい。販売管理サーバ1は、顧客宛ての電子メールで電子処方箋を送信してもよい。或いは、販売管理サーバ1は、医薬品ECプラットフォームの所定のウェブページから電子処方箋をダウンロード可能にしてもよい。
【0066】
また、顧客により選択された医薬品が医療用医薬品である場合、その医薬品を薬局が発送するように販売管理サーバ1が構成されてもよい。例えば、医師による顧客の診察が終わると、医療機関から薬局へ処方箋が送付されてもよい。例えば、医療機関から薬局へ処方箋が郵送されてもよい。或いは、販売管理サーバ1が、電子処方箋を、薬局が利用する端末装置である図示せぬ薬局端末へ送信してもよい。処方箋を受領した薬局の薬剤師は、顧客に対して服薬指導を行ってもよい。服薬指導は、例えばオンラインで行われてもよい。オンライン診察の場合と同様に、オンラインの服薬指導では、薬局端末と顧客端末4との間で音声及び映像の通信が行われてもよい。服薬指導が終わった後、薬局は医療用医薬品を顧客へ発送してもよい。
【0067】
また、医療用医薬品と異なる商品の中に、医師の診察を受けることを条件として顧客が注文可能となる商品が存在してもよい。例えば医師の診察が必要な商品又は商品のカテゴリが、医薬品ECプラットフォームにおいて又は各薬局により予め定められていてもよい。
【0068】
[1-4.販売管理サーバの構成]
次に、販売管理サーバ1の構成について、図4乃至図7を用いて説明する。図4は、本実施形態に係る販売管理サーバ1の概要構成の一例を示すブロック図である。図4に示すように、販売管理サーバ1は、システム制御部11と、システムバス12と、入出力インタフェース13と、記憶部14と、通信部15と、を備えている。システム制御部11と入出力インタフェース13とは、システムバス12を介して接続されている。
【0069】
システム制御部11は、CPU(Central Processing Unit)11a、ROM(Read Only Memory)11b、RAM(Random Access Memory)11c等により構成されている。
【0070】
入出力インタフェース13は、記憶部14及び通信部15とシステム制御部11との間のインタフェース処理を行う。
【0071】
記憶部14は、例えば、ハードディスクドライブ等により構成されている。この記憶部14には、会員DB14a、商品DB14b、カートDB14c、診察予約DB14d、処方履歴DB14e、注文DB14f、購入権DB14g、発送予定DB14h、経過観察期間DB14i、質問情報DB14j、経過観察通知予定DB14k、回答DB14l、及び経過観察結果DB14m等のデータベースが記憶されてもよい。「DB」は、データベースの略語である。少なくとも一のデータベースは、販売管理サーバ1と異なるサーバ装置に記憶されてもよい。販売管理サーバ1は、そのサーバ装置を介してデータベースにアクセス可能であってもよい。
【0072】
図5乃至図7は、販売管理サーバ1のデータベースに記憶される情報の例を示す図である。会員DB14aには、医薬品ECプラットフォームを利用可能な各顧客に関する会員情報が記憶されてもよい。例えば図5に示すように、会員DB14aには、会員情報として、顧客ID、氏名、性別、生年月日、住所、電話番号、電子メールアドレス、及びクレジットカード情報等が、互いに関連付けて記憶されてもよい。顧客IDは、顧客を識別する識別情報であってもよい。クレジットカード情報は、その顧客が利用可能なクレジットカードに関する情報であってもよい。例えば、クレジットカード情報は、カード番号、有効期限、クレジットカードの所有者の氏名等を含んでもよい。
【0073】
商品DB14bには、医薬品ECプラットフォームで販売される各商品に関する商品情報が記憶されてもよい。例えば商品DB14bには、商品情報として、商品ID、カテゴリ情報、医療用医薬品フラグ、商品名、一般名、価格、商品説明、及び商品画像URL(Uniform Resource Locator)等が、互いに関連付けて記憶されてもよい。商品IDは、商品を識別する識別情報であってもよい。カテゴリ情報は、その商品が属するカテゴリを示す情報であってもよい。商品のカテゴリの例として、美容内服薬、美容外用薬、化粧品、ダイエット薬品、ピル、AGA(Androgenetic Alopecia)治療薬、ED(Erectile Dysfunction)治療薬等が挙げられる。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。医療用医薬品フラグは、図3に示すように、顧客端末4が表示する画面を、カート画面1300から注文申込内容確認画面1400に遷移させるか否かの判定に用いられてもよい。販売管理サーバ1は、医療用医薬品フラグがTRUEに設定されている商品がカートに入っている場合、顧客端末4の画面を注文申込内容確認画面1400に遷移させてもよい。その後、顧客は、診察を予約して、医師の診察を受けてから商品の注文を確定させることとなる。一方、販売管理サーバ1は、医療用医薬品フラグがFALSEに設定されている商品のみがカートに入っている場合、顧客端末4の画面を注文内容確認画面2100に遷移させてもよい。その後、顧客は、医師の診察を受けることなる商品の注文を確定させることとなる。前述したように、医療用医薬品と異なる商品の中に、医師の診察を受けることを条件として顧客が注文可能となる商品が存在してもよい。この場合、商品DB14bには、例えば診察対象フラグが記憶されてもよい。診察対象フラグは、その商品の注文を確定させるために顧客が医師の診察を受ける必要があるか否かを示してもよい。販売管理サーバ1は、診察対象フラグがTRUEに設定されている商品がカートに入っている場合、顧客端末4の画面を注文申込内容確認画面1400に遷移させてもよい。一方、販売管理サーバ1は、診察対象フラグがFALSEに設定されている商品のみがカートに入っている場合、顧客端末4の画面を注文内容確認画面2100に遷移させてもよい。商品名は、その商品の名称を示してもよい。一般名は、その商品が医薬品である場合において、その商品の主成分の名称を示してもよい。商品画像URLは、その商品の画像のデータのURLであってもよい。
【0074】
カートDB14cには、各顧客のカートに現在入れられている商品に関するカート情報が記憶されてもよい。例えば、カートDB14cには、カート情報として、顧客ID、及びカート商品情報等が、互いに関連付けて記憶されてもよい。顧客IDは、そのカードを所有する顧客を示してもよい。カート商品情報は、カートに入っている個別の商品に関する情報であってもよい。一のカートに複数の商品が入っている場合、カートDB14cには、それら複数の商品のそれぞれについて、カート商品情報が記憶されてもよい。各カート商品情報は、商品ID、購入形態、数量、及び医療用医薬品フラグ等を含んでもよい。商品IDは、カートに入っている商品を示してもよい。購入形態は、その商品の購入形態が、逐次購入及び定期自動購入のうちの何れであるかを示してもよい。数量は、その商品の購入量を月数で示してもよい。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。商品DB14bの場合と同様に、カートDB14cには診察対象フラグが記憶されてもよい。なお、販売管理サーバ1は、カート情報を記憶部14に記憶させるのではなく、例えば各顧客端末4にHTTP(HyperText Transfer Protocol)クッキーとしてカート情報を記憶させてもよい。
【0075】
診察予約DB14dには、オンライン診察の各予約に関する予約情報が記憶されてもよい。例えば、診察予約DB14dには、予約情報として、予約番号、診察日、診察開始時刻、診察終了時刻、及び顧客ID等が、互いに関連付けて記憶されてもよい。予約番号は、予約を識別する番号であってもよい。診察日は、予約された診察が行われる日付を示してもよい。診察開始時刻及び診察終了時刻は、それぞれ診察のために予約された時間帯の開始時刻及び終了時刻を示してもよい。顧客IDは、診察を予約した顧客を示してもよい。
【0076】
処方履歴DB14eには、医療機関の医師による処方の履歴が記憶されてもよい。処方履歴DB14eには、オンライン診察で行われた処方に関する履歴のみが記憶されてもよいし、オフラインでの診察で行われた処方に関する履歴も記憶されてもよい。例えば、処方履歴DB14eには、処方が行われるごとに、処方ログとして、処方番号、処方日時、予約番号、顧客ID、及び処方医薬品情報等が、互いに関連付けて記憶されてもよい。処方番号は、処方を識別する番号であってもよい。処方日時は、処方が行われた日時を示してもよい。予約番号は、その処方が行われた診察の予約を識別する番号であってもよい。顧客IDは、処方された医薬品が提供される顧客を示してもよい。すなわち、顧客IDは、医師が診察した顧客を示してもよい。処方医薬品情報は、処方された個別の医薬品に関する情報であってもよい。一の処方で複数の医薬品の調剤が指示された場合、処方履歴DB14eには、それら複数の医薬品のそれぞれについて、処方医薬品情報が記憶されてもよい。各処方医薬品情報報は、商品ID、購入形態、数量、及び医療用医薬品フラグ等を含んでもよい。商品IDは、処方された医薬品を示してもよい。購入形態は、その医薬品の購入形態が、逐次購入及び定期自動購入のうちの何れであるかを示してもよい。数量は、その医薬品の購入量を月数で示してもよい。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。商品DB14bの場合と同様に、処方履歴DB14eには診察対象フラグが記憶されてもよい。
【0077】
注文DB14fには、医薬品ECプラットフォームで受け付けられた注文に関する注文情報が、注文が確定するごとに記憶されてもよい。例えば図6に示すように、注文DB14fには、注文情報として、注文番号、注文日時、顧客ID、注文商品情報、処方番号、支払金額、配送先情報等が、互いに関連付けて記憶されてもよい。注文番号は、注文を識別する番号であってもよい。注文日時は、その注文が確定した日時を示してもよい。顧客IDは、その注文を行った顧客を示してもよい。注文商品情報は、注文された個別の商品に関する情報であってもよい。一の注文で複数の商品が注文された場合、注文DB14fには、それら複数の商品のそれぞれについて注文商品情報が記憶されてもよい。各注文商品情報は、商品ID、購入形態、数量、医療用医薬品フラグ、及び継続購入フラグ等を含んでもよい。商品IDは、注文された商品を示してもよい。購入形態は、その商品の購入形態が、逐次購入及び定期自動購入のうちの何れであるかを示してもよい。数量は、その商品の購入量を月数で示してもよい。医療用医薬品フラグは、その商品が医療用医薬品であるか否かを示してもよい。商品DB14bの場合と同様に、注文DB14fには診察対象フラグが記憶されてもよい。継続購入フラグは、その商品の購入が、初回購入及び継続購入のうちの何れであるかを示してもよい。処方番号は、注文された商品が医療用医薬品を含む場合において、その処方を識別する番号であってもよい。支払金額は、注文された商品の代金と送料との合計であってもよい。配送先情報は、注文された商品の配送先を示す情報であってもよい。
【0078】
購入権DB14gには、医療用医薬品の購入権に関する購入権情報が、医師の診察を経た上で注文が確定した医薬品ごとに、記憶されてもよい。例えば購入権DB14gには、購入権情報として、購入権ID、注文番号、設定日、顧客ID、商品ID、最大処方量、既購入量、及び権利状態等が、互いに関連付けて記憶されてもよい。購入権IDは、購入権を識別する識別情報であってもよい。注文番号は、その購入権に対応する注文を示してもよい。設定日は、購入権が設定された日付を示してもよい。顧客IDは、その購入権を有する顧客を示してもよい。商品IDは、その購入権が設定された商品を示してもよい。最大処方量は、その商品について最大どれだけの量を処方することができるかを示してもよい。全医療用医薬品で最大処方量が同一である場合、購入権DB14gには最大処方量が記憶されなくてもよい。既購入量は、その購入者によってその商品がどれだけの量既に購入されているかを示してもよい。権利状態は、その購入権の状態を示してもよい。例えば権利状態は、「有効」、「消滅」、及び「停止」のうちの何れかに設定されてもよい。「有効」は、その購入権が有効に存続していることを示してもよい。「消滅」は、最大処方量分の商品が顧客に提供されたことを理由に、その購入権が無効となったことを示してもよい。「停止」は、医師により処方中止が決定されたことを理由に、その購入権が無効となったことを示してもよい。
【0079】
発送予定DB14hには、購入された商品の発送予定を示す発送予定情報が、予定された発送ごとに記憶されてもよい。例えば発送予定DB14hには、発送予定情報として、発送予定ID、注文番号、顧客ID、購入形態、発送回、発送先情報、発送予定日、発送日、及び発送予定商品情報等が、互いに関連付けて記憶されてもよい。発送予定IDは、発送予定を識別する識別情報であってもよい。注文番号は、その商品の発送を必要とする注文を示してもよい。顧客IDは、商品を注文した顧客を示してもよい。購入形態は、発送される商品が逐次購入及び定期自動購入の何れで購入されたかを示してもよい。発送回は、購入形態が定期自動購入である場合に有効であってもよい。発送回は、定期配送で商品が発送される場合において、予定される配送が、定期配送における何回目の配送であるかを示してもよい。発送予定日は、商品の発送が予定されている日付を示してもよい。発送日は、商品が発送された日付を示してもよい。発送予定商品情報は、発送が予定される個別の商品に関する情報であってもよい。一の発送で複数の商品が発送される場合、発送予定DB14hには、それら複数の商品についての発送予定商品情報が記憶されてもよい。各発送予定商品情報は、商品ID、数量、及び発送状態を含んでもよい。商品IDは、発送される予定の商品を示してもよい。数量は、その商品の購入量を月数で示してもよい。発送状態は、その商品の発送の状態を示してもよい。例えば発送状態は、「未発送」、「発送完了」、及び「キャンセル」のうちの何れかに設定されてもよい。「未発送」は、その商品がまだ発送されていないことを示してもよい。「発送完了」は、その商品が既に発送されていることを示してもよい。「キャンセル」は、その商品の発送がキャンセルされたことを示してもよい。「キャンセル」は、定期配送についての発送予定について設定される場合があってもよい。
【0080】
経過観察期間DB14iには、経過観察のための質問に対する回答を顧客に促す通知を行うまでの期間に関する経過観察期間情報が、商品のカテゴリと経過観察の実施回との組み合わせごとに記憶されてもよい。経過観察の実施回は、実施される経過観察が、商品の初回購入から何回目の経過観察であるかを示してもよい。経過観察期間DB14iには、例えば経過観察期間情報として、カテゴリ情報、実施回、及び経過観察期間長等が、互いに関連付けて記憶されてもよい。カテゴリ情報は、経過観察の対象となる商品のカテゴリを示してもよい。経過観察期間長は、初回購入によるそのカテゴリの商品の発送日からその実施回の経過観察の通知までの期間の長さを示してもよい。経過観察期間長は、フォローアップの時期までの期間の長さを示す商品期間長情報の一例であってもよい。経過観察期間長の例として、日数、週数、月数等が挙げられる。本実施形態では、経過観察期間長は月数で示されるものとする。
【0081】
質問情報DB14jには、経過観察のための質問の内容を示す質問情報が、商品のカテゴリごとに記憶されてもよい。例えば質問情報DB14jには、カテゴリ情報及び質問状法等が、互いに関連付けて記憶されてもよい。カテゴリ情報は、質問の対象となる商品のカテゴリを示してもよい。質問情報は、1又は複数の質問のそれぞれの内容を示してもよい。例えば、質問情報は、質問ごとに、質問番号、質問内容を示すテキスト、回答として選択可能な選択肢を示すテキスト等を含んでもよい。記憶部14には、質問情報DB14jに加えて、質問シート画面表示情報が、商品のカテゴリごとにカテゴリ情報に関連付けて記憶されてもよい。質問シート画面表示情報は、質問シート画面を顧客端末4に表示させる情報であってもよい。質問シート画面は、経過観察のための質問を表示するとともに、その質問に対する回答の入力を受け付け可能な画面であってもよい。質問シート画面表示情報は、HTML(HyperText Markup Language)文書であってもよいし、その他の情報であってもよい。販売管理サーバ1は、質問情報DB14jに記憶された質問情報に基づいて、質問シート画面表示情報を予め生成しておいてもよい。
【0082】
経過観察通知予定DB14kには、経過観察のための質問に対する回答を顧客に促す通知を行う予定を示す経過観察通知予定情報が、経過観察ごとに記憶されてもよい。例えば図7に示すように、経過観察通知予定DB14kには、経過観察通知予定情報として、経過観察ID、顧客ID、カテゴリ情報、商品ID、及び送信予定日等が、互いに関連付けて記憶されてもよい。経過観察IDは、通知対象の経過観察を示してもよい。顧客IDは、通知先の顧客を示してもよい。カテゴリ情報は、経過観察の対象となる商品のカテゴリを示してもよい。商品IDは、経過観察の対象となる商品を示してもよい。経過観察の対象となる商品が複数存在する場合、経過観察通知予定DB14kには、それら複数の商品それぞれの商品IDが記憶されてもよい。送信予定日は、通知の送信が予定される日付を示してもよい。
【0083】
回答DB14lには、経過観察のための質問に対する回答に関する回答結果情報が、経過観察ごとに記憶されてもよい。例えば回答DB14lには、回答結果情報として、経過観察ID、顧客ID、質問情報、及び回答情報等が、互いに関連付けて記憶されてもよい。経過観察IDは、回答に対応する経過観察を示してもよい。顧客IDは、回答を行った顧客を示してもよい。質問情報は、回答の対象となる質問を示してもよい。回答情報は、その回答の内容を示してもよい。例えば回答情報は、設問ごとに、質問番号、顧客が選択した選択肢、顧客が入力したテキスト等を含んでもよい。
【0084】
経過観察結果DB14mには、医師による経過観察の結果を示す経過観察結果情報が、経過観察ごとに記憶されてもよい。例えば経過観察結果DB14mには、経過観察結果情報として、経過観察ID、顧客ID、処方継続可否情報、及びコメント等が、互いに関連付けて記憶されてもよい。経過観察IDは、医師が行った経過観察を示してもよい。顧客IDは、その経過観察の対象となる顧客を示してもよい。処方継続可否情報は、処方継続の可否判定に関する情報であってもよい。経過観察の対象となる商品が複数存在する場合、経過観察結果DB14mには、それら複数の商品それぞれの処方継続可否情報が記憶されてもよい。各処方継続可否情報は、商品ID及び処方継続フラグ等を含んでもよい。商品IDは、処方継続の可否判定の対象となった商品を示してもよい。処方継続フラグは、その商品の処方継続及び処方中止のうちの何れが医師により決定されたかを示してもよい。
【0085】
記憶部14には、更に、オペレーティングシステム、DBMS(Database Management System)、サーバプログラム等の各種プログラムが記憶されてもよい。サーバプログラムは、医薬品ECプラットフォームに関する処理をシステム制御部11に実行させるプログラムであってもよい。サーバプログラムは、例えば、他の装置からネットワークNWを介して取得されるようにしてもよいし、磁気テープ、光ディスク、メモリカード等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
【0086】
通信部15は、例えばネットワークインタフェースカード等により構成されている。通信部15は、ネットワークNWを介して、医師端末2、出荷端末3又は顧客端末4と接続し、接続された装置との通信状態を制御する。
【0087】
[1-5.販売管理サーバのシステム制御部の機能概要]
次に、図8乃至図19を用いて、販売管理サーバ1におけるシステム制御部11の機能概要について説明する。図8は、本実施形態に係る販売管理サーバ1におけるシステム制御部11の機能ブロックの一例を示す図である。システム制御部11は、CPU11aが、サーバプログラムに含まれる各種プログラムコードを読み出し実行することにより、図8に示すように、販売画面情報送信部111、選択商品識別情報取得部112、カート情報管理部113、診察支援部114、注文確定部115、発送予定情報管理部116、購入商品識別情報取得部117、経過観察通知送信部118、質問情報送信部119、回答情報受信部120、使用継続可否情報取得部121、経過観察結果情報送信部122、及び商品提供制限情報管理部123等として機能してもよい。
【0088】
[1-5-1.商品の選択から発送]
販売画面情報送信部111は、医薬品ECプラットフォームに関する各種の画面を顧客端末4に表示させる画面情報を、顧客端末4に送信してもよい。販売画面情報送信部111は、例えば画面情報として、画面に相当するウェブページのHTML文書を、顧客端末4へ送信してもよい。或いは、販売画面情報送信部111は、例えば画面内に表示されるべき情報を顧客端末4へ送信することで、その画面を表示させてもよい。或いは、販売画面情報送信部111は、特定の画面の表示の指示を顧客端末4へ送信するのみであってもよい。顧客端末4は、その顧客端末4に予め記憶されている情報に基づいて、販売管理サーバ1からの指示に応じた画面を表示してもよい。販売画面情報送信部111は、主に商品の選択や注文に係わる画面を顧客端末4に表示させてもよい。例えば販売画面情報送信部111は、顧客端末4からの要求に応じた商品に関する情報を含む画面の画面情報を送信してもよい。顧客端末4からの要求に応じた商品の例として、顧客により選択された商品、顧客により指定された条件を満たす商品、顧客が要求した画面に掲載されることが予め定められている商品等が挙げられる。顧客端末4からの要求に応じた商品の具体例として、商品選択画面1100の1つである検索結果画面、商品画面1200、カート画面1300、注文申込内容確認画面1400、注文内容確認画面2100等が挙げられる。
【0089】
販売画面情報送信部111は、商品の購入形態を選択するための操作が可能な画面を顧客端末4に表示させてもよい。また販売画面情報送信部111は、商品の購入数量を選択するための操作が可能な画面を顧客端末4に表示させてもよい。この画面は、例えば商品画面1200であってもよい。
【0090】
図9は、商品画面1200の一例を示す図である。図9に示すように、商品画面1200には、商品に関する情報、例えば商品名、商品のカテゴリ、商品画像、商品説明、価格等が表示されてもよい。商品画面1200に情報が表示されている商品が医療用医薬品である場合、商品画面1200には、注意事項が更に表示されてもよい。例えば、その商品の注文には医師の診察が必要である旨、診察の予約を促す旨等が表示されてもよい。また、商品画面1200は、購入形態・数量選択ボタン群1210、カート追加ボタン1220、及びカートアイコン1230を更に含んでもよい。購入形態・数量選択ボタン群1210は、購入数量及び購入数量を選択するための複数のボタンを含んでもよい。例えば購入形態・数量選択ボタン群1210は、定期配送ボタン1211、1ヶ月ボタン1212、3ヶ月ボタン1213、6ヶ月ボタン1214等を含んでもよい。定期配送ボタン1211は、定期自動購入を選択するためのボタンである。定期自動購入が選択された場合、購入数量は自動的に1ヶ月分に決定されてもよい。1ヶ月ボタン1212、3ヶ月ボタン1213、及び6ヶ月ボタン1214は、何れも逐次購入を選択するためのボタンである。1ヶ月ボタン1212は、1ヶ月分の数量の購入を選択するためのボタンである。2ヶ月ボタン1213は、1ヶ月分の数量の購入を選択するためのボタンである。3ヶ月ボタン1214は、1ヶ月分の数量の購入を選択するためのボタンである。カート追加ボタン1220は、商品画面1200に情報が表示されている商品をカートに追加するためのボタンである。カートアイコン1230は、カート画面1300を表示するために操作可能なアイコンである。
【0091】
選択商品識別情報取得部112は、注文するために顧客により選択された商品を識別する商品ID及びその顧客の顧客IDを取得してもよい。注文のための商品の選択は、例えばその商品をカートに入れることであってもよい。或いは、注文のための商品の選択は、その商品の注文を申し込むことであってもよい。例えば選択商品識別情報取得部112は、図9に示す商品画面1200が表示において、顧客がカート追加ボタン1220を押下する操作を行うと、顧客端末4は、その顧客の顧客ID及びその商品の商品IDを販売管理サーバ1へ送信してもよい。医薬品識別情報取得部111は、送信されてきた顧客ID及び商品IDを取得してもよい。
【0092】
カート情報管理部113は、各顧客のカート情報を管理してもよい。また、カート情報管理部113は、選択商品識別情報取得部112により取得された商品ID及び顧客IDに基づいて、顧客により選択された医薬品をカートに入れる処理を実行してもよい。例えば、カート情報管理部113は、取得された商品IDに関連付けられた医療用医薬品フラグを商品DB14bから検索してもよい。カート情報管理部113は、商品ID、医療用医薬品フラグ、並びに購入形態・数量選択ボタン群1210のうち選択されたボタンに対応する購入形態及び数量を含むカート商品情報を生成してもよい。カート情報管理部113は、生成されたカート商品情報を、カートDB14cに記憶されたその顧客のカート情報に追加してもよい。
【0093】
診察支援部114は、選択商品識別情報取得部112により取得された商品IDにより示される商品が医療用医薬品である場合、顧客(または関係者)と医師との面談として、診察を支援してもよい。診察の支援は、顧客による診察の予約を可能とさせること及びオンライン面接を実現させることのうち、少なくとも何れか一方を含んでもよい。予約可能な診察は、オンライン診察であってもよいし、オフライン診察であってもよい。
【0094】
診察の予約を可能とするため、診察支援部114は、予約申込画面情報を、顧客端末4へ送信してもよい。予約申込画面情報は、予約申込画面を顧客端末4に表示させる情報であってもよい。予約申込画面は、診察の予約を申し込むための操作を受け付け可能な画面であってもよい。この画面は、診察予約画面1500及び診察予約確認画面1600のうち、少なくとも何れか一方の画面であってもよい。予約申込画面情報は、例えばHTML文書であってもよいし、画面内に表示されるべき情報であってもよいし、予約申込画面の表示の指示であってもよい。また診察支援部114は、予約申込画面に対する顧客の操作に応じて、診察の予約を受け付けてもよい。そして診察支援部114は、診察予約情報を生成して、この診察予約情報を診察予約DB14dに記憶させてもよい。また診察支援部114は、診察予約DB14dに記憶された診察予約情報により示される診察予約に関する情報を、医師端末2へ送信してもよい。これにより、診察支援部114は、診察の予約があったことを医師に知らせてもよい。
【0095】
オンライン診察を実現するため、診察支援部114は、顧客端末4と医師端末2とを、診察のための通信を可能に接続させてもよい。例えば通信接続部115は、ビデオ通話、ビデオ会議又はウェブ会議等に用いられるプロトコルを用いてもよい。そのようなプロトコルの例として、H.323、WebRTC(Web Real-Time Communication)等が挙げられる。オンライン診察の間、顧客端末4と医師端末2との間でメディアデータ(またはメディアストリーム)が送受信される。メディアデータは、音声を示す音声データ及び映像を示す映像データのうち少なくとも音声データを含んでもよい。映像は、静止画及び動画の何れかであってもよい。メディアデータは顧客端末4と医師端末2との間でピアツーピアにより直接送受信されてもよい。或いは、クライアントサーバ方式で、販売管理サーバ1等のサーバ装置を介してメディアデータが送受信されてもよい。メディアデータを送受信するためのプロトコルとして、例えばRTP(Real-time Transport Protocol)、HLS(HTTP Live Streaming)、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)、RTMP(Real Time Messaging Protocol)等が用いられてもよい。音声データのフォーマットの例として、AAC(Advanced Audio Coding)、MP3(MPEG-1 Audio Layer-3)等が挙げられる。動画データのコンテナフォーマットの例として、MPEG2-TS、MP4、FLV(Flash Video)等が挙げられる。動画のフォーマットの例として、H.264、MPEG-2等が挙げられる。
【0096】
診察支援部114は、オンライン診察の間、顧客端末4に顧客診察画面2000を表示させ、医師端末2に医師診察画面を表示させてもよい。医師診察画面には、顧客の情報が表示されてもよい。また医師診察画面には、顧客により選択された商品の情報が表示されてもよい。例えば商品名、購入形態、及び数量が表示されてもよい。また医師診察画面は、医師が処方する商品に関する情報の入力を受け付け可能であってもよい。例えば、処方する商品、購入形態、及び数量の入力が可能であってもよい。顧客の注文内容を変更しない場合、医師は、処方に関する情報を、顧客の選択通りに入力してもよい。医師は、顧客の注文内容の一部又は全部を変更して処方可能であってもよい。注文内容の変更の例として、商品の削除、追加、変更、購入形態の変更、数量の変更等が挙げられる。カード情報管理部113は、注文内容の変更を、カートDB14cに反映させてもよい。
【0097】
診察支援部114は、顧客端末4へ、顧客診察画面2000のHTML文書を送信してもよい。また診察支援部114は、医師端末2へ、医師診察画面のHTML文書を送信してもよい。これらのHTML文書は、オンライン診察を実現するための情報を含んでもよい。例えば、これらのHTML文書は、顧客端末4と医師端末2と接続したり、映像及び音声を入出力したり、メディアデータを送受信したりするためのタグやスクリプトが含まれていてもよい。顧客端末4は、スクリプトに従って、販売管理サーバ1を介して医師端末2へその顧客端末4のセッション情報を送信してもよい。セッション情報は、例えば顧客端末4のIPアドレス、ポート番号、利用可能なメディアに関する情報、メディアデータの送受信に利用可能な経路に関する情報等を含んでもよい。同様に、医師端末2も、販売管理サーバ1を介して顧客端末4へその医師端末2のセッション情報を送信してもよい。それぞれセッション情報を受信した顧客端末4及び医師端末2は、セッション情報に基づいて互いに接続してもよい。接続された各端末装置は、その端末装置のビデオカメラにより映像を撮影させて映像データを生成し、その端末装置のマイクロホンにより集音させて音声データを生成してもよい。そして、各端末装置は、映像データ及び音声データを接続先の端末装置へ送信する。また、各端末装置は、接続先の端末装置から送信されてきた映像データに従って映像をディスプレイに表示してもよい。また、各端末装置は、接続先の端末装置から送信されてきた音声データに従って音声をスピーカから出力させてもよい。
【0098】
診察支援部114は、顧客により選択された商品が医療用医薬品ではない場合、診察の支援を省略してもよい。この場合、診察は行われなくてもよい。
【0099】
診察支援部114は、顧客により選択された商品が医療用医薬品であっても、その商品について有効に存続している購入権を顧客が有している場合、診察の支援を省略してもよい。この場合も、診察は行われなくてもよい。例えば購入権DB14gに記憶されている権利状態を参照することで、購入権が有効であるか否かの判定が可能である。
【0100】
注文確定部115は、選択商品識別情報取得部112により取得された商品IDにより示される商品の注文を確定させてもよい。例えば、注文確定部115は、注文内容確認画面2100において顧客が注文を確定させる操作を行ったことに応じて、注文情報を生成してもよい。注文確定部115は、生成された注文情報を注文DB14fに記憶させてもよい。ここで、顧客により選択された商品が医療用医薬品である場合、注文確定部115は、診察支援部114により支援される診察後、注文を確定してもよい。例えば、注文確定部115は、オンライン診察のための通信を可能とする顧客端末4と医師端末2との接続後、注文を確定してもよい。顧客により選択された商品が医療用医薬品ではない場合、注文確定部115は、診察なくして注文を確定してもよい。また、選択された商品が医療用医薬品であっても、その商品について有効に存続している購入権を顧客が有している場合も、注文確定部115は、診察なくして注文を確定してもよい。例えば注文確定部115は、診察支援部114による顧客端末4と医師端末2との接続を省略して、注文を確定してもよい。
【0101】
また注文確定部115は、確定した注文について、購入代金の決済を実行してもよい。例えば注文確定部115は、生成された注文情報に含まれる支払方法情報に基づいて、決済処理を実行してもよい。例えば、支払い方法がクレジットカード決済である場合、支払方法情報は、カード番号、有効期限、クレジットカードの所有者の氏名を含んでもよい。注文確定部115は、クレジットカード会社が管理する図示せぬ決済サーバへ、決済要求を送信してもよい。決済サーバは、クレジットカードを用いた決済を承認及び制御するサーバ装置であってもよい。決済要求は、カード番号、有効期限、クレジットカードの所有者の氏名、支払金額、支払先を示す情報を含んでもよい。支払先は、例えば医療機関であってもよいし、医薬品ECプラットフォームを管理する事業者であってもよい。支払先が、医薬品ECプラットフォームを管理する事業者である場合、後日その事業者から医療機関へ、支払代金から手数料を差し引いた額の売上金が支払われてもよい。決済サーバは、決済要求に基づいて、クレジットカードの情報の確認、有効期限の確認、利用限度枠の確認等を行ってもよい。決済サーバは、顧客による代金の支払いが可能であると判定すると、決済を承認し、決済成功を販売管理サーバ1へ送信してもよい。
【0102】
発送予定情報管理部116は、商品の発送予定情報を管理してもよい。例えば発送予定情報管理部116は、注文確定部115により注文が確定された場合、若しくは決済処理が完了した場合、発送予定情報を生成してもよい。このとき、発送予定情報管理部116は、注文された各商品の発送予定商品情報に含まれる発送状態を、「未発送」に設定してもよい。また注文確定部115は、発送予定日を、注文日若しくは注文日から所定日数後の日付に設定してもよい。顧客に配達日が指定されている場合、注文確定部115は、発送予定日を、その配達日から所定日数前の日付に設定してもよい。発送予定情報管理部116は、生成された発送予定情報を、発送予定DB14hに記憶させてもよい。
【0103】
発送予定情報管理部116は、生成された発送予定情報を、出荷端末3へ送信してもよい。例えば発送予定情報管理部116は、発送予定情報を生成したタイミングでその発送予定情報を送信してもよい。或いは発送予定情報管理部116は、発送予定日に発送予定情報を送信してもよいし、発送予定日の所定日数前に発送予定情報を送信してもよい。或いは発送予定情報管理部116は、発送予定日が、医療機関の従業員により指定された期間内にある発送予定情報を送信してもよい。出荷端末3は、販売管理サーバ1からの発送予定情報に基づいて、商品の発送予定を画面に表示してもよい。例えば出荷端末3は、発送予定の商品の名称、その商品の数量、発送先情報、発送予定日等を表示してもよい。医療機関の従業員は、表示され発送予定に基づいて、商品の発送作業を行ってもよい。
【0104】
発送予定情報管理部116は、商品が顧客に向けて発送されたことを示す発送完了通知を、出荷端末3から受信してもよい。例えば商品の発送作業が完了すると、医療機関の従業員は、その発送日及びその商品の配送伝票に付された伝票番号のうち少なくとも何れか一方を出荷端末3に入力してもよい。出荷端末3は、例えば入力された発送日及び発送予定IDを含む発送完了通知を、販売管理サーバ1へ送信してもよい。発送予定情報管理部116は、出荷端末3から受信した発送完了通知に基づいて、配送予定DB14hに記憶された発送予定情報を更新してもよい。例えば発送予定情報管理部116は、発送された各商品の発送予定商品情報に含まれる発送状態を、「発送完了」に変更してもよい。また発送予定情報管理部116は、配送予定情報に含まれる発送日を、発送完了通知に含まれる発送日又は発送完了通知を受信した日付に設定してもよい。
【0105】
購入された商品の中に、定期自動購入が顧客により選択された商品が存在する場合、発送予定情報管理部116は、定期配送での2回目以降の配送についての発送予定情報を生成してもよい。例えば発送予定情報管理部116は、出荷端末3から発送完了通知を受信することで、或る配送分の商品の発送が完了したことを確認すると、次回の配送についてのみ発送予定情報を生成してもよい。或いは発送予定情報管理部116は、最大処方量に相当する期間中に予定されている全ての配送のそれぞれについて、発送予定情報を予め生成してもよい。発送予定情報管理部116は、発送予定日を、例えば過去の配送分の商品の発送日及び1回の配送で発送する商品の数量に基づいて設定してもよい。例えば発送予定情報管理部116は、前回の配送分の商品の発送日に、商品の数量に相当する期間の長さを加算して、発送予定日を計算してもよい。
【0106】
顧客により定期自動購入がキャンセルされた場合、発送予定情報管理部116は、次回以降の発送をキャンセルしてもよい。例えば発送予定情報管理部116は、定期自動購入がキャンセルされた各商品の発送予定情報に含まれる発送状態を、「キャンセル」に変更してもよい。また、発送予定情報管理部116は、経過観察の結果、医師により処方中断が決定された商品の次回以降の発送をキャンセルしてもよい。例えば発送予定情報管理部116は、出荷端末3へ発送予定情報を送信する際、その発送予定情報から、発送がキャンセルされた商品の発送予定商品情報を削除してもよい。これにより、出荷端末3は、発送がキャンセルされた商品については、発送が予定されている商品として画面には表示しない。そのため、その商品は発送されない。或いは出荷端末3は、発送予定商品情報に含まれる発送状態が「キャンセル」に設定されていることに基づいて、その商品については発送がキャンセルされた旨を画面に表示してもよい。
【0107】
[1-5-2.経過観察]
購入商品識別情報取得部117は、経過観察の対象に定められている複数の商品のうち、購入された商品を識別する購入商品識別情報を取得してもよい。購入商品識別情報は、例えばその商品の商品IDであってもよいし、その商品が属するカテゴリのカテゴリ情報であってもよい。本実施形態においては、購入商品識別情報は商品IDであるものとする。購入商品識別情報取得部117は、注文確定部115により注文が確定した後、所定のタイミングでその商品IDを取得してもよい。例えば購入商品識別情報取得部117は、購入された商品の発送後、注文DB14f、購入権DB14g若しくは発送予定DB14hから、商品IDを取得してもよい。また購入商品識別情報取得部117は、その商品の発送日を、発送予定DB14hから取得してもよい。
【0108】
経過観察通知送信部118は、購入商品識別情報取得部117により取得された商品IDにより識別される商品について、経過観察通知を送信してもよい。経過観察通知は、商品IDにより識別される商品の経過観察のための質問への回答を、その商品の購入者に促す情報であってもよい。例えば経過観察通知送信部118は、その購入者宛ての電子メール又はインスタントメッセージで、経過観察通知を送信してもよい。或いは経過観察通知送信部118は、その購入者の顧客端末4へ、プッシュ通知で経過観察通知を送信してもよい。
【0109】
図10は、経過観察通知メールの一例を示す図である。経過観察通知メールは、経過観察通知を示す電子メールである。図10に示すように、経過観察通知メール3100は、商品名3110、促し情報3120、及び回答ボタン3130等を含んでもよい。商品名3110は、経過観察の対象となる商品を示す。一の経過観察で、1又は複数の商品が経過観察の対象となってもよい。促し情報3120は、経過観察のための質問への回答を促すテキストであってもよい。例えば促し情報3120として、「安全に服用するため定期的に体調を確認しましょう。」、及び、「問題がある場合、下記フォームより詳細を教えてください。」等のテキストが表示されてもよい。なお、促し情報3120は、経過観察通知メール3100に含まれる情報であれば、如何様な情報であってもよい。促し情報3120はテキストに限定されない。例えば促し情報3120は、商品名3110及び回答ボタン3130のうち少なくとも何れか一方を含んでもよい。回答ボタン3130は、質問シート画面を顧客端末4に表示させるために操作可能なボタンである。質問シート画面は、質問が表示されるとともに、その質問に対する回答の入力を受け付け可能な画面であってもよい。
【0110】
経過観察通知送信部118は、例えば経過観察期間長情報に基づいて、経過観察通知を送信するタイミングを決定してもよい。経過観察期間長情報は、経過観察の時期までの期間の長さを示す経過観察期間長を含む情報であってもよい。また経過観察期間長情報は、経過観察の対象に定められている複数の商品のそれぞれに対応する経過観察期間長を特定可能な情報であってもよい。これは、或る商品が指定された場合、その商品に対応する経過観察期間長を取得することが可能であることを意味するものであってもよい。必ずしも、経過観察期間長が商品ごとに定義されているとは限らない。経過観察期間長情報は、例えばデータベース又はテーブルであってもよい。例えば経過観察期間長情報は、商品DB14bと経過観察期間DB14iとの組み合わせであってもよい。商品DB14bに記憶されている商品IDとカテゴリ情報との組み合わせから、購入された商品のカテゴリを特定することができる。経過観察期間DB14iに記憶されているカテゴリ情報と経過観察期間長との組み合わせから、そのカテゴリに対応する経過観察期間長を特定することができる。なお、商品ごとに経過観察期間長が定められる場合、経過観察期間DB14iには、商品ごとに、商品IDと経過観察期間長とが関連付けて記憶されればよい。商品ごと又は商品のカテゴリごとに、経過観察期間長が定義可能であるので、購入された商品に応じたタイミングで、経過観察通知を送信することができる。
【0111】
経過観察通知送信部118は、商品の購入に関連する基準日から、その商品に対応する経過観察期間長の期間の経過後に、経過観察通知を送信してもよい。商品の購入に関連する基準日は、例えば商品の購入行為又は購入手続きに係わる日であってもよい。例えば基準日は、顧客が商品を購入したとみなされる日付、顧客による商品の購入意思が確定したとみなされる日付、または商品の購入若しくは注文の申し込みが受け付けられた日付であってもよい。基準日の例として、注文の確定日、決済の完了日、商品の発送日、及び商品の配達日等が挙げられる。本実施形態においては、基準日は発送日であるものとする。
【0112】
1回の注文で複数の商品が購入される場合がある。経過観察通知送信部118は、それら複数の商品の中で、経過観察通知の送信タイミング(または経過観察期間長)が互いに同一である商品ごとに、経過観察通知を送信してもよい。例えば経過観察通知送信部118は、商品のカテゴリごとに、経過観察通知を送信してもよい。
【0113】
後述するように、経過観察のための質問は、商品によって異なってもよい。1回の注文で複数の商品が購入された場合、経過観察通知送信部118は、購入された複数の商品の中で、互いに質問が同一である商品ごとに、経過観察通知を送信してもよい。或いは、経過観察通知送信部118は、質問が同一であるか否かに関係なく、購入された複数の商品について、まとめて経過観察通知を送信してもよい。購入された商品の中に、互いに質問が同一であるものの、経過観察通知を送信するタイミング(または経過観察期間長)が互いに異なる商品が存在する場合がある。この場合、経過観察通知送信部118は、送信のタイミングが同一である商品ごとに、経過観察通知を送信してもよい。或いは経過観察通知送信部118は、それらの商品の経過観察通知を送信するタイミングをマージしてもよい。経過観察通知送信部118は、マージされたタイミングで、それらの商品について、まとめて経過観察通知を送信してもよい。
【0114】
経過観察期間長は、最大処方量に相当する期間の長さを超えて定義されていてもよい。最大処方量に相当する量の商品が実際に購入された場合、その商品に設定された購入権は消滅する。購入権が消滅した商品を顧客が再購入するには、医師の診察を受ける必要がある。この場合の購入は、特別な継続購入であるとみなされてもよい。経過観察通知送信部118は、商品の初回購入の際の商品の発送日から経過観察期間長の期間の経過後に、経過観察通知を送信してもよい。或いは、経過観察期間長は、最大処方量に相当する期間の長さを超えて定義されていなくてもよい。この場合、購入権が消滅した商品の再購入は、初回購入とみなされてもよい。経過観察通知送信部118は、2回目の初回購入の際の商品の発送日から、1回目の経過観察についての経過観察期間長の期間の経過後に、経過観察通知を送信してもよい。
【0115】
図11(a)、図11(b)、及び図11(c)は、それぞれ商品A、B、及びCについての経過観察通知の送信タイミングの例を示す図である。図11(a)に示すように、商品Aが購入された場合、1ヶ月周期で経過観察通知が送信されてもよい。例えば、発送日から1ヶ月後に1回目の経過観察通知が送信される。その後、発送日から2ヶ月後に2回目の経過観察通知が送信される。その後、発送日から3ヶ月後に3回目の経過観察通知が送信される。その後、発送日から4ヶ月後に4回目の経過観察通知が送信される。同様に、5回目以降の経過観察通知が送信される。図11(b)に示すように、商品Bが購入された場合、2ヶ月周期で経過観察通知が送信されてもよい。例えば、発送日から2ヶ月後に1回目の経過観察通知が送信される。その後、発送日から4ヶ月後に2回目の経過観察通知が送信される。その後、発送日から6ヶ月後に3回目の経過観察通知が送信される。図11(c)に示すように、商品Cが購入された場合、最初の3ヶ月は、1ヶ月周期で経過観察通知が送信されてもよい。例えば、発送日から1ヶ月後に1回目の経過観察通知が送信される。その後、発送日から2ヶ月後に2回目の経過観察通知が送信される。その後、発送日から3ヶ月後に3回目の経過観察通知が送信される。その後、発送日から6ヶ月後に4回目の経過観察通知が送信される。
【0116】
購入形態が逐次購入である場合、経過観察通知送信部118は、発送日から丁度Nヶ月後(Nは1以上の整数)に経過観察通知を送信するのではなく、Nヶ月後から所定日数前の日に、経過観察通知を送信してもよい。或いは経過観察通知送信部118は、Nヶ月後から所定日数後の日に、経過観察通知を送信してもよい。これにより、経過観察通知の通知タイミングを、継続購入による商品の発送のタイミングとずらすことができる。
【0117】
経過観察通知送信部118は、購入された商品の最大処方量のうち、既購入量に相当する期間中にのみ、経過観察通知を送信してもよい。例えば、逐次購入且つ初回購入にて、商品Cが2ヶ月分購入されたとする。この場合、経過観察通知送信部118は、初回購入の発送日から1ヶ月後及び2ヶ月後にのみ、経過観察通知を送信してもよい。その後、継続購入にて、商品Cが4ヶ月分購入されたとする。この場合、経過観察通知送信部118は、初回購入の発送日から3ヶ月後及び6ヶ月後に、経過観察通知を送信してもよい。
【0118】
質問情報送信部119は、経過観察通知送信部118による経過観察通知の送信後に、経過観察通知の送信先の購入者が利用する顧客端末4からの要求に応じて、経過観察のための質問を示す質問情報を、その顧客端末4へ送信してもよい。質問情報送信部119は、質問シート画面情報を送信してもよい。質問シート画面は、質問シート画面を顧客端末4に表示させる情報であってもよい。質問シート画面情報は、質問情報を含んでもよい。質問シート画面情報は、HTML文書であってもよいし、質問シート画面に表示されるべき情報であってもよいし、質問シート画面の表示の指示であってもよい。質問情報送信部119は、例えば経過観察通知メール3100の回答ボタン3130が操作されたことに応じて、質問情報を送信してもよい。回答ボタン3130が操作されると、顧客端末4は、販売管理サーバ1へ質問シート画面要求を送信してもよい。質問シート画面要求は、例えば経過観察の対象となる商品の商品ID若しくはその商品のカテゴリを示すカテゴリ情報を含んでもよい。
【0119】
質問情報送信部119は、例えば商品質問情報に基づいて、顧客端末4に送信する質問情報を決定してもよい。商品質問情報は、経過観察の対象に定められている複数の商品のそれぞれに対応する質問を特定可能な情報であってもよい。これは、或る商品が指定された場合、その商品に対応する質問情報を取得することが可能であることを意味するものであってもよい。必ずしも、質問情報が商品ごとに定義されているとは限らない。商品質問情報は、質問情報自体を含んでもよい。或いは商品質問情報は、質問情報を識別するための識別情報を含んでもよい。商品質問情報とは別に、記憶部14には、各識別情報に関連付けて質問情報が記憶されてもよい。商品質問情報は、例えばデータベース又はテーブルであってもよい。例えば商品質問情報は、商品DB14bと質問情報DB14jとの組み合わせであってもよい。商品DB14bに記憶されている商品IDとカテゴリ情報との組み合わせから、購入された商品のカテゴリを特定することができる。質問情報DB14jに記憶されているカテゴリ情報と質問情報との組み合わせから、そのカテゴリに対応する質問情報を特定することができる。なお、商品ごとに質問情報が定められる場合、質問情報DB14jには、商品ごとに、商品IDと質問情報とが関連付けて記憶されればよい。商品ごと又は商品のカテゴリごとに、質問情報が定義可能であるので、購入された商品に応じた質問を、購入者に提示することができる。
【0120】
図12は、経過観察のための質問の内容の例を示す図である。例えば図12に示すように、商品のカテゴリとして、ピル、美容内服薬、ダイエット薬、及び外用薬が少なくとも存在するとする。ピルについての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、消化器症状の有無を確認するための質問、不正出血の有無を確認するための質問、体重増減の有無を確認するための質問、高血圧の有無を確認するための質問、美容内服薬の服用の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。美容内服薬についての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、ピルの服用の有無を確認するための質問、肌の状態の問題の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。ダイエット薬についての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、消化器症状の有無を確認するための質問、体重増減の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。外用薬についての質問は、病気及び他の医薬品の使用の有無を確認するための質問、体調の変化の有無を確認するための質問、肌の状態の問題の有無を確認するための質問、並びにその他の症状の有無を確認するための質問を含んでもよい。
【0121】
質問情報が互いに異なる複数の商品が、一の経過観察の対象となってもよい。この場合、質問情報送信部119は、それらの商品の質問情報をマージしてもよい。質問情報送信部119は、マージされた質問情報を、顧客端末4へ送信してもよい。或いは、一の経過観察の対象が、質問情報が互いに同一である商品となるように、経過観察通知送信部118又は質問情報送信部119が機能してもよい。
【0122】
図13は、質問シート画面の一例を示す図である。図13に示すように、質問シート画面3200は、1又は複数の入力フォーム3210、及び回答ボタン3220等を含んでもよい。各入力フォーム3210は、一の質問に対する回答を入力するためのフォームであってもよい。各入力フォーム3210は、例えば質問3210及びラジオボタン群3212等を含んでもよい。質問3210は、その質問を示すテキストである。ラジオボタン群3212は、その質問に対する回答を選択するために操作可能な複数のラジオボタンを含んでもよい。少なくとも一の入力フォーム3210は、回答入力欄3213を更に含んでもよい。例えば回答として、ラジオボタン群3212により「はい」及び「いいえ」の何れかが選択可能である場合、回答入力欄3213が表示されてもよい。回答入力欄3213は、質問に対する回答が「はい」である場合に具体的な回答内容を示すテキストを入力するための領域であってもよい。回答ボタン3220は、質問シート画面に入力された回答を販売管理サーバ1へ送信するために操作可能なボタンであってもよい。
【0123】
回答情報受信部120は、質問情報送信部119により送信された質問情報により示される質問に対する回答を示す回答情報を、顧客端末4から受信してもよい。例えば、質問シート画面3200の回答ボタン3220が操作されると、顧客端末4は回答情報を販売管理サーバ1へ送信してもよい。回答情報受信部120は、顧客端末4から受信された回答情報を、回答DB14lに記憶させてもよい。
【0124】
使用継続可否情報取得部121は、回答情報受信部120により受信された回答情報に基づいて、使用継続可否情報を取得してもよい。使用継続可否情報は、購入された商品の使用継続の可否を示す情報であってもよい。使用継続可否情報は、例えば処方継続可否情報であってもよい。処方継続可否情報は、購入された商品の処方の継続の可否を示す情報であってもよい。
【0125】
使用継続可否情報取得部121は、例えば回答情報を医師端末2へ送信することにより、処方継続可否情報を取得してよい。例えば医師端末2は、回答情報を画面に表示させてもよい。医師は、画面に表示された回答情報に基づいて、処方継続の可否を決定してもよい。医師は、決定した処方継続の可否を医師端末2に入力してもよい。使用継続可否情報取得部121は、入力された可否を示す処方継続可否情報を、医師端末2から受信してもよい。なお、システム制御部11は、図示せぬ使用継続可否情報受信部として機能してもよい。使用継続可否情報受信部は、処方継続可否情報を医師端末2から受信してもよい。
【0126】
使用継続可否情報取得部121は、回答情報を医師端末2へ送信するとともに、経過観察画面情報を、医師端末2へ送信してもよい。経過観察画面情報は、医師端末2に経過観察画面を表示させる情報であってもよい。経過観察画面は、医師による経過観察の結果を入力するための画面であってもよい。経過観察画面は、購入された商品の処方継続の可否の選択を受け付け可能な画面であってもよい。経過観察画面情報は、HTML文書であってもよいし、経過観察画面に表示されるべき情報であってもよいし、経過観察画面の表示の指示であってもよい。使用継続可否情報取得部121は、送信される経過観察画面情報に、回答情報を含めてもよい。この場合、経過観察画面に回答が表示されてもよい。
【0127】
図14は、経過観察画面の一例を示す図である。図14に示すように、経過観察画面3300は、質問回答情報3310、1又は複数の入力フォーム3320、コメント入力欄3330、及び送信ボタン3340等を含んでもよい。質問回答情報3310は、顧客に提示された質問及び顧客が入力した回答を示してもよい。各入力フォーム3320は、一の商品に対する処方継続の可否を入力するためのフォームであってもよい。図14に示す例では、商品AAAAAA、BBBBBB、及びCCCCCCのそれぞれについて、入力フォーム3320が表示されている。各入力フォーム3320は、経過観察の対象となる商品の商品名、購入量等を含んでもよい。また各入力フォーム3320は、処方継続選択メニュー3321を含んでもよい。処方継続選択メニュー3321は、処方継続及び処方中止のうち、医師が決定した対処を選択するために操作可能なプルダウンメニューであってもよい。コメント入力欄3330は、顧客に対するコメントを示すテキストを入力するための領域であってもよい。送信ボタン3340は、経過観察結果情報を、販売管理サーバ1へ送信するためのボタンであってもよい。経過観察結果情報は、経過観察の結果を示す情報であってもよい。経過観察結果情報は、処方継続選択メニュー3321にて選択された処方継続の可否を示す処方継続可否情報を含んでもよい。
【0128】
図15は、処方継続の可否の入力後における経過観察画面の一例を示す図である。図15に示すように、商品AAAAAについては、処方中止が選択されている。商品BBBBBB及びCCCCCCについては、処方継続が選択されている。コメント入力欄3330には、商品AAAAAAの処方が中止される理由が入力されている。
【0129】
経過観察結果情報送信部122は、経過観察結果情報を、商品の購入者に向けて送信してもよい。経過観察結果情報は、経過観察の結果を示す情報であってもよい。経過観察結果は、使用継続可否情報取得部121により取得された使用継続可否情報により示される使用継続の可否を含んでもよい。経過観察結果情報送信部122は、その購入者宛ての電子メール又はインスタントメッセージで、経過観察結果情報を送信してもよい。或いは経過観察結果情報送信部122は、その購入者の顧客端末4へ、プッシュ通知で経過観察結果情報を送信してもよい。或いは経過観察結果情報送信部122は、その顧客端末4からの要求に応じて、経過観察結果を含む画面を顧客端末4に表示させる画面情報を、その顧客端末4へ送信してもよい。
【0130】
図16(a)乃至図16(c)は、経過観察結果メールの一例を示す図である。経過観察結果メールは、経過観察結果を示す電子メールである。図16(a)は、医師により処方継続が決定された場合の経過観察結果メールの一例を示す。図16(a)に示すように、経過観察結果メール3400は、使用継続可情報3410、コメント3420、及び診察予約リンク3430等を含んでもよい。使用継続可情報3410は、商品の使用の継続が可能であることを示すテキストであってもよい。例えば、使用継続可情報3410として、「お薬の服用・使用には問題ありません。」等が表示されてもよい。コメント3420は、医師により入力されたコメントを示す。診察予約リンク3430は、オンライン診察の予約を行うために操作可能なリンクであってもよい。顧客が診察予約リンク3430を選択すると、顧客端末4は、例えば診察予約画面1500を表示してもよい。図3に示すように、顧客は、オンライン診察を予約して、その後オンライン診察を受けることができる。この状態においては、注文される商品は選択されていない。オンライン診察において、医師が商品を決定してもよい。
【0131】
図16(b)は、逐次購入により購入された商品について、医師により処方継続中止が決定された場合の経過観察結果メールの一例を示す。図16(b)において、図16(a)と同一の要素については同一の符号が付されている。図16(b)に示すように、経過観察結果メール3400は、使用中止情報3440、商品名3450、コメント3420、及び診察予約リンク3430等を含んでもよい。使用中止情報3440は、商品の使用の中止を促すことを示すテキストであってもよい。例えば、使用中止情報3440として、「お薬の服用を中止してください。」等が表示されてもよい。商品名3450は、使用中止の対象となる商品の名称を示す。
【0132】
図16(c)は、定期自動購入により購入された商品について、医師により処方継続中止が決定された場合の経過観察結果メールの一例を示す。図16(c)において、図16(b)と同一の要素については同一の符号が付されている。図16(c)に示すように、経過観察結果メール3400は、使用中止情報3440、定期配送キャンセル情報3460、商品名3450、コメント3420、及び診察予約リンク3430等を含んでもよい。定期配送キャンセル情報3460は、処方中止が決定された商品について、顧客への定期配送がキャンセルされることを示すテキストであってもよい。例えば、定期配送キャンセル情報3460として、「定期配送をご利用中の場合、医師の判断により、次回分以降は決済・発送をキャンセルいたします。」等が表示されてもよい。
【0133】
[1-5-3.商品の提供制限]
商品提供制限情報管理部123は、商品提供制限情報を管理してもよい。商品提供制限情報は、顧客に対して商品の提供が制限されるか否かを、顧客と商品との組み合わせごとに特定可能な情報であってもよい。商品提供制限情報から特定可能な提供の制限は、経過観察で使用中止若しくは処方中止が決定された商品の提供を制限することであってもよい。商品の提供が制限される顧客とその顧客に提供が制限される商品との組み合わせを、提供制限組み合わせという。商品の提供が制限されない顧客とその顧客に提供が制限されない商品との組み合わせを、提供非制限組み合わせという。商品提供制限情報は、各提供制限組み合わせを示す情報を含んでもよい。商品DB14bから、医薬品ECプラットフォームで取り扱われている全ての医療用医薬品を特定可能である。また、会員DB14aから、医薬品ECプラットフォームを利用可能な全ての顧客特定可能である。従って、商品提供制限情報から提供制限組み合わせを特定可能であれば、必然的に、提供非制限組み合わせを特定可能である。或いは、商品提供制限情報は、各提供非制限組み合わせを示す情報を含んでもよい。前述と同様の理由により、提供非制限組み合わせが特定可能であれば、必然的に、提供制限組み合わせも特定可能である。商品提供制限情報は、顧客と商品との全ての組み合わせについての情報を含まなくてもよい。例えば商品提供制限情報は、各提供制限組み合わせに関する情報のみを含んでもよいし、各提供非制限組み合わせに関する情報のみを含んでもよい。商品提供制限情報は、例えばデータベース又はテーブルであってもよい。
【0134】
商品提供制限情報は、例えば購入権DB14gであってもよい。購入権DB14gに記憶された各購入権情報は、過去に設定された購入権を示してもよい。購入権情報に含まれる顧客IDは、その購入権を有する顧客を示してもよい。購入権情報に含まれる商品IDは、その購入権が設定された商品を示してもよい。購入権情報に含まれる権利状態は、商品の提供が制限されるか否かを示してもよい。例えば、「有効」を示す権利状態は、商品の提供が制限されないことを示してもよい。「停止」を示す権利状態は、商品の提供が制限されることを示してもよい。また「消滅」を示す権利状態も、商品の提供が制限されることを示してもよい。商品提供制限情報管理部123は、注文確定部115により注文が確定される場合、注文された各商品について、購入権情報を生成してもよい。このとき、商品提供制限情報管理部123は、購入権情報に含まれる権利状態を、「有効」に設定してもよい。
【0135】
商品提供制限情報管理部123は、使用継続可否情報取得部121により取得された使用継続可否情報が使用継続の不可を示す場合、商品提供制限情報を変更又は更新してもよい。これにより、商品提供制限情報管理部123は、使用継続不可とされた商品の購入者に対してその商品の提供が制限されることが商品提供制限情報から特定可能にしてもよい。例えば商品提供制限情報管理部123は、その購入者とその商品との組み合わせが提供制限組み合わせであることを直接示す情報を、商品提供制限情報に追加してもよい。或いは商品提供制限情報管理部123は、商品提供制限情報から、その購入者とその商品との組み合わせが提供非制限組み合わせであることを示す情報を削除してもよい。或いは商品提供制限情報管理部123は、商品提供制限情報に含まれるその購入者とその商品との組み合わせを提供非制限組み合わせとして示す情報を、その購入者とその商品との組み合わせを提供制限組み合わせとして示す情報に変更してもよい。
【0136】
図17は、購入権DB14gの更新例を示す図である。商品提供制限情報が購入権DB14gであるとする。例えば医師が、顧客Xに対する商品Aの処方中止を決定したとする。この場合、図17に示すように、使用継続可否情報取得部121は、処方中止を示す処方継続可否情報を取得する。この場合、商品提供制限情報管理部123は、顧客Xと商品Aとの組み合わせを示す購入権情報に含まれる権利状態を、「有効」から「停止」に変更してもよい。
【0137】
商品の提供の制限は、特定の条件を顧客が満たすことを条件に、その商品の購入が可能となることであってもよい。商品の購入が制限されていない間、顧客は、その条件を満たす必要なく、商品の購入が可能であってもよい。特定の条件は、例えば医師の診察を受けること若しくは医師からその商品を処方してもらうことであってもよい。医師がその商品を処方することで、顧客はその商品についての新たな購入権を取得可能であってもよい。
【0138】
例えば、診察支援部114が、選択商品識別情報取得部112により取得された顧客IDにより示される顧客に対して選択商品識別情報取得部112により取得された商品IDにより示される商品の提供が制限されることが商品提供制限情報から特定される場合、その顧客に対する医師の診察を支援してもよい。この場合、注文確定部115は、その診察後に、注文を確定してもよい。一方、診察支援部114は、その顧客に対してその商品の提供が制限されないことが商品提供制限情報から特定される場合、その顧客に対する医師の診察を支援しなくてもよい。この場合、注文確定部115は、その診察なくして、注文を確定してもよい。
【0139】
前述したように、顧客により選択された商品が医療用医薬品ではあるものの、その商品について有効に存続している購入権を顧客が有している場合、診察支援部114は、診察の支援を省略してもよく、注文確定部115は、その診察なくして、注文を確定してもよい。これは、商品の提供が制限されていないことを示す。診察支援部114及び注文確定部115のうち少なくとも何れか一方は、購入権情報に含まれる権利状態が「有効」である場合、診察なくして注文を確定可能なように機能してもよい。例えば図3に示す画面遷移例において、カート画面1300の表示後、顧客端末4が注文内容確認画面2100を表示するように、注文確定部115が機能してもよい。その一方で、顧客により選択された商品が医療用医薬品であり、且つ、その商品について有効に存続している購入権を顧客が有していない場合、診察支援部114は、診察を支援してもよく、注文確定部115は、その診察後、注文を確定してもよい。これは、商品の提供が制限されていることを示す。診察支援部114及び注文確定部115のうち少なくとも何れか一方は、購入権情報に含まれる権利状態が「停止」である場合、顧客が診察を受けたことを条件として注文を確定可能なように機能してもよい。例えば図3に示す画面遷移例において、カート画面1300の表示後、顧客端末4が注文申込内容確認画面1400を表示するように、診察支援部114が機能してもよい。その後、例えば診察予約画面1500、診察予約確認画面1600、診察予約受付完了画面1700、問診票画面1800、診察待機画面1900、及び顧客診察画面2000の順で、これらの画面が表示されるように、診察支援部114が機能してもよい。その後、注文内容確認画面2100が表示されるように、注文確定部115が機能してもよい。
【0140】
図18は、商品の提供の制限例を示す図である。例えば顧客は、或る商品を1ヶ月分購入しようとする。この時点での購入権DB14gには、その顧客とその商品との組み合わせを示す購入権情報は記憶されていない。そのため、顧客は、医師の診察を受ける必要がある。診察を受けた上で顧客が商品を購入すると、商品提供制限情報管理部123は、購入権DB14gに購入権情報を記憶させてもよい。このときの購入権状態は「有効」に設定される。経過観察が1ヶ月ごとに実施されるとする。初回購入から1ヶ月後の経過観察では、使用継続が可能であることが決定された。従って、権利状態は「有効」のままである。また顧客は、初回購入から1ヶ月後に、商品を2ヶ月分購入する。権利状態は「有効」であるので、顧客は、医師の診察を受ける必要はない。初回購入から1ヶ月後の経過観察では、使用中止が決定された。従って、商品提供制限情報管理部123は、権利状態を「停止」に変更する。顧客は、初回購入から3ヶ月後に、商品を3ヶ月分購入する。権利状態は「停止」であるので、顧客は、医師の診察を受ける必要がある。
【0141】
購入形態が定期自動購入である場合の商品の提供の制限は、定期配送での次回以降の配送をキャンセルすることであってもよい。例えば、発送予定情報管理部116は、使用継続不可が決定された商品の購入者に対してその商品の提供が制限されることが特定可能に、商品提供制限情報が商品提供制限情報管理部123により変更された場合、発送予定情報管理部116は、その購入者に対するその商品の次回以降の発送をキャンセルしてもよい。発送予定情報管理部116は、例えば商品提供制限情報管理部123により権利状態が「停止」に変更された顧客と商品との組み合わせに対応する次回以降の配送についての発送予定情報について、発送状態を「キャンセル」に変更してもよい。
【0142】
図19は、定期自動購入における商品の提供の制限例を示す図である。例えば顧客は、或る商品を定期自動購入で購入しようとする。この時点での購入権DB14gには、その顧客とその商品との組み合わせを示す購入権情報は記憶されていない。そのため、顧客は、医師の診察を受ける必要がある。診察を受けた上で顧客が商品を購入すると、商品提供制限情報管理部123は、購入権DB14gに購入権情報を記憶させてもよい。このときの購入権状態は「有効」に設定される。そして、例えば1ヶ月分の商品を含む定期配送が発送される。経過観察が1ヶ月ごとに実施されるとする。初回購入から1ヶ月後の経過観察では、使用継続が可能であることが決定された。従って、権利状態は「有効」のままである。そのため、初回購入から1ヶ月後に商品は発送される。初回購入から2ヶ月後の経過観察では、使用継続が可能であることが決定された。従って、権利状態は「有効」のままである。そのため、初回購入から2ヶ月後に商品は発送される。初回購入から3ヶ月後の経過観察では、使用中止が決定された。従って、商品提供制限情報管理部123は、権利状態を「停止」に変更する。権利状態は「停止」であるので、初回購入から3ヶ月後以降の商品の発送はキャンセルされる。
【0143】
定期自動購入で購入された商品についての商品提供制限情報は、例えば購入権DB14gであってもよいし、発送予定DB14hであってもよい。商品提供制限情報が発送予定DB14hである場合の商品提供制限情報管理部123は、発送予定情報管理部116であってもよい。発送予定DB14hには、定期自動購入で購入された商品の次回の配送についての発送予定を示す発送予定情報が記憶される。発送予定情報に含まれる各商品についての発送状態は、その商品の提供が制限されるか否かを示してもよい。例えば、「未発送」を示す発送状態は、商品の提供が制限されないことを示してもよい。「キャンセル」を示す発送状態は、商品の提供が制限されることを示してもよい。或いは、商品提供制限情報管理部123は、使用中断が決定された商品の発送予定商品情報を、発送予定情報から削除してもよい。これにより、その商品の提供が制限されてもよい。
【0144】
顧客端末4から販売管理サーバ1へ回答情報が送信されてこなかった場合、経過観察の対象となった商品の提供は制限されなくてもよい。また回答情報の送信期限が設定されてもよい。この送信期限までに顧客端末4から回答情報が送信されてこなかった場合、商品の提供は制限されなくてもよい。医師端末2から販売管理サーバ1へ処方継続可否情報が送信されてこなかった場合、経過観察の対象となった商品の提供は制限されなくてもよい。また処方継続可否情報の送信期限が設定されてもよい。この送信期限までに医師端末2から処方継続可否情報が送信されてこなかった場合、商品の提供は制限されなくてもよい。
【0145】
システム制御部11は、商品提供制限情報を管理することなく若しくは商品提供制限情報を参照することなく、顧客に対して商品の提供を制限するための処理を行ってもよい。例えばシステム制御部11は、使用継続可否情報取得部121により取得された使用継続可否情報が使用継続可を示す場合、診察を省略して注文を確定させるか、または次回の定期配送をキャンセルしなくてもよい。システム制御部11は、使用継続可否情報取得部121により取得された使用継続可否情報が、使用継続の不可を示す場合、診察後に注文を確定させるか、または次回の定期配送をキャンセルしてもよい。
【0146】
[1-6.通信システムの動作]
次に、通信システムSの動作について、図20乃至図26を用いて説明する。図20乃至図26は、本実施形態に係る通信システムSの処理例を示すシーケンス図である。処理の順序は、図20乃至図26に示される順序に限定されない。また、図20乃至図26に示されるステップのうち少なくとも一のステップは実行されなくてもよい。販売管理サーバ1のシステム制御部11は、サーバプログラムに係る各種プログラムコードに従って、図20乃至図26に示される販売管理サーバ1の処理を実行してもよい。
【0147】
例えば、顧客端末4は、商品選択画面1100から顧客が何れかの商品を選択することに応じて、商品画面1200を表示する。顧客は、商品画面1200で購入形態・数量選択ボタン群1210に含まれる何れかのボタンを操作して、購入形態及び数量を選択する。そして図20に示すように、顧客は、カート追加ボタン1220を押下する(ステップS101)。この操作を検出した顧客端末4は、販売管理サーバ1へカート追加要求を送信する(ステップS102)。カート追加要求は、その顧客の顧客ID、選択された商品の商品ID、並びに選択された購入形態及び数量を含んでもよい。カート追加要求を受信した販売管理サーバ1のカート情報管理部113は、その顧客の顧客IDに関連付けてカートDB14cに記憶されているカート情報を更新する(ステップS103)。例えば、販売管理サーバ1は、カート追加要求に含まれる商品IDに関連付けられた医療用医薬品フラグを、商品DB14bから取得してもよい。カート情報管理部113は、商品ID,医療用医薬品フラグ、購入形態及び数量を含むカート商品情報を生成してもよい。カート情報管理部113は、生成されたカート商品情報をカート情報に追加してもよい。
【0148】
その後、顧客は、例えば商品画面1200でカートアイコン1230を選択する(ステップS104)。この操作を検出した顧客端末4は、カート画面要求を販売管理サーバ1へ送信する(ステップS105)。カート画面要求を受信した販売管理サーバ1の販売画面情報送信部111は、カート画面1300のHTML文書を顧客端末4へ送信する(ステップS106)。このとき、販売画面情報送信部111は、その顧客のカート情報に基づいて、現在カートに入っている商品の一覧を生成してもよい。販売画面情報送信部111は、この一覧を含むHTML文書を生成してもよい。顧客端末4は、このHTML文書に基づいて、カート画面1300を表示する。
【0149】
顧客端末4により表示されたカート画面1300において、顧客は、次の手続きに進むための操作を行う(ステップS107)。この操作を検出した顧客端末4は、販売管理サーバ1へ注文手続進行要求を送信する(ステップS108)。注文手続進行要求を受信した販売管理サーバ1の注文確定部115は、その顧客のカートに入っている商品は医療用医薬品を含むか否かを判定する(ステップS109)。例えば、注文確定部115は、その顧客のカート情報に含まれる少なくとも一つのカート商品情報の医療用医薬品フラグがTRUEに設定されている場合、カートに入っている商品は医療用医薬品を含むと判定してもよい。カートに入っている商品が医療用医薬品を含む場合(ステップS109:YES)、注文確定部115は、医療用医薬品である商品についてその顧客が有効に存続している購入権を有しているか否かを判定する(ステップS110)。例えば、注文確定部115は、その商品の商品IDとその顧客の顧客IDとの組み合わせを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権DB14gから検索してもよい。注文確定部115は、該当する購入権情報がない場合、顧客が有効に存続している購入権を有していないと判定してもよい。注文確定部115は、検索された購入権情報に含まれる権利状態が「有効」である場合、顧客が有効に存続している購入権を有していると判定してもよい。注文確定部115は、検索された購入権情報に含まれる権利状態が「停止」又は「消滅」である場合、顧客が有効に存続している購入権を有していないと判定してもよい。カート商品情報が診察対象フラグを含む場合、注文確定部115は、その診察対象フラグに基づいて、その顧客のカートに入っている商品は、注文の確定のために医師の診察が必要な商品を含むか否かを判定してもよい。カートに入っている商品が、医師の診察が必要な商品を含む場合、処理はステップS110に進んでもよい。
【0150】
顧客が有効に存続している購入権を有していない場合(ステップS110:NO)、診察支援部114は、注文申込内容確認画面1400のHTML文書を顧客端末4へ送信する(ステップS111)。このとき、診察支援部114は、その顧客のカート情報に基づいて、現在カートに入っている商品の一覧を生成してもよい。診察支援部114は、生成された一覧を含むHTML文書を生成してもよい。顧客端末4は、このHTML文書に基づいて、注文申込内容確認画面1400を表示する。
【0151】
顧客端末4により表示された注文申込内容確認画面1400において、注文を申し込むための操作を行う(ステップS112)。この操作を検出した顧客端末4は、販売管理サーバ1へ注文申込を送信する(ステップS113)。注文申込を受信した販売管理サーバ1の診察支援部114は、診察予約画面1500のHTML文書を顧客端末4へ送信する(ステップS114)。顧客端末4は、このHTML文書に基づいて、診察予約画面1500を表示する(ステップS115)。
【0152】
図21に示すように、顧客は、診察予約画面1500から診察日及び診察開始時刻を選択する(ステップS201)。この操作を検出した顧客端末4は、販売管理サーバ1へ予約確認画面要求を送信する(ステップS202)。予約確認画面要求は、選択された診察日及び診察開始時刻を含んでもよい。予約確認画面要求を受信した販売管理サーバ1の診察支援部114は、診察予約確認画面1600のHTML文書を顧客端末4へ送信する(ステップS203)。顧客端末4は、このHTML文書に基づいて、診察予約確認画面1600を表示する。
【0153】
注診察予約確認画面1600において、顧客が、予約を確定させる操作を行う(ステップS204)。この操作を検出した顧客端末4は、販売管理サーバ1へ予約確定要求を送信する(ステップS205)。予約確定要求を受信した販売管理サーバ1の診察支援部114は、予約情報を生成して診察予約DB14dに記憶させる(ステップS206)。次いで、診察支援部114は、診察予約受付完了画面1700のHTML文書を顧客端末4へ送信する(ステップS207)。
【0154】
顧客は、予約された診察日に、診察待機画面1900を顧客端末4により表示させる。医療機関の医師が医師端末2を操作すること応じて、診察支援部114は、診察を予約した顧客のための医師診察画面のHTML文書を医師端末2へ送信する。医師端末2は、このHTML文書に基づいて、図22に示すように医師診察画面を表示する(ステップS301)。医師診察画面において、医師が、診察のための通話を開始させる操作を行う。この操作を検出した医師端末2は、販売管理サーバ1へ通話接続要求を送信する(ステップS302)。通話接続要求は、例えば診察の予約番号や診察を予約した顧客の顧客IDを含んでもよい。通話接続要求を受信した販売管理サーバ1の診察支援部114は、顧客IDにより示される顧客の顧客端末4へ顧客診察画面2000のHTML文書を送信する(ステップS303)。顧客端末4は、このHTML文書に基づいて、顧客診察画面2000を表示する(ステップS304)。
【0155】
顧客端末4は、顧客診察画面2000を表示すると、そのHTML文書に含まれるスクリプトに基づいて、販売管理サーバ1を介してセッション情報を医師端末2へ送信する。医師端末2も、医師診察画面のHTML文書に含まれるスクリプトに基づいて、販売管理サーバ1を介してセッション情報を顧客端末4へ送信する(ステップS305)。顧客端末4及び医師端末2は、交換したセッション情報に基づいて互いに接続する(ステップS306)。顧客端末4と医師端末2とが接続されると、それらの端末装置間でメディアデータの送受信が行われることにより、オンライン診察が開始される(ステップS307)。
【0156】
オンライン診察中、医師は、顧客のカートに入っている商品の情報を参照して、医師診察画面に処方予定の商品の情報を入力する(ステップS308)。例えば医師は、処方する商品、購入形態、及び数量を選択してもよい。医師診察画面には、顧客のカートに入っている商品の一覧が表示されている。医師は、その一覧を参照して処方を入力してもよい。処方が入力されると、医師端末2は、販売管理サーバ1へ入力情報を送信する(ステップS309)。入力情報は、医師により選択された商品の商品ID、購入形態、及び数量を含んでもよい。
【0157】
入力情報を受信した販売管理サーバ1の診察支援部114は、この入力情報に基づいて、カートDB14cに記憶されている顧客のカート情報を更新する(ステップS310)。例えば診察支援部114は、カート情報に含まれる各カート商品情報を、入力情報で書き換えてもよい。このとき、診察支援部114は、各カート商品情報に、医師により選択された商品の医療用医薬品フラグを追加してもよい。ステップS308~S310は、必要に応じて繰り返されてもよい。
【0158】
その後、医師が、処方内容を確定する操作を行う(ステップS311)。この操作を検出した医師端末2は、販売管理サーバ1へ、処方内容確定要求を送信する(ステップS512)。処方内容確定要求を受信した販売管理サーバ1の診察支援部114は、顧客のカート情報に基づいて、処方ログを生成して処方履歴DB14eに記憶させる(ステップS313)。
【0159】
その後、例えば顧客又医師が通話を終了させる操作を行うことに応じて、顧客端末4と医師端末2との接続が切断し、メディアデータの送受信も停止する。そして、注文確定部115は、注文内容確認画面2100のHTML文書を顧客端末4へ送信する(ステップS314)。カートに入っている商品が医療用医薬品を含まない場合(ステップS109:NO)、または顧客が有効に存続している購入権を有している場合にも(ステップS110:YES)、注文確定部115は、注文内容確認画面2100のHTML文書を顧客端末4へ送信する(ステップS314)。顧客端末4は、このHTML文書に基づいて、注文内容確認画面2100を表示する(ステップS315)。注文内容確認画面2100において、顧客が、注文を確定させる操作を行う。(ステップSS316)。この操作を検出した顧客端末4は、販売管理サーバ1へ注文確定要求を送信する(ステップS317)。
【0160】
注文確定要求を受信した販売管理サーバ1の注文確定部115は、注文情報を生成して、この注文情報を注文DB14fに記憶させる(ステップS401)。注文確定部115は、その顧客のカート情報に基づいて、注文情報を生成しもよい。例えば注文確定部115は、カート情報に含まれる各カート商品情報に相当する注文商品情報を生成してもよい。このとき、注文確定部115は、医療用医薬品である各商品の注文商品情報に、継続購入フラグを追加してもよい。注文された商品についてその顧客が有効な購入権を有してない場合、注文確定部115は、継続購入フラグを「初回購入」に設定してもよい。顧客が有効な購入権を有している場合、注文確定部115は、継続購入フラグを「継続購入」に設定してもよい。また注文確定部115は、新たな注文番号を生成してもよい。また、注文確定部は、注文日時として、現在日時を取得してもよい。注文確定部115、注文番号、注文日時、注文を行った顧客の顧客ID、注文商品情報、顧客により指定された発送先を示す発送先情報、顧客の指定に応じた発送予定日等を含む注文情報を生成してもよい。次いで、注文確定部115は、決済処理を実行する(ステップS402)。
【0161】
次いで、商品提供制限情報管理部123は、生成された各注文商品情報に含まれる医療用医薬品フラグに基づいて、注文された商品が医療用医薬品を含むか否かを判定する(ステップS403)。注文された商品が医療用医薬品を含む場合(ステップS403:YES)、商品提供制限情報管理部123は、医療用医薬品である商品の注文商品情報に含まれる継続購入フラグに基づいて、その商品の購入が初回購入であるかを判定する(ステップS404)。その商品の購入が初回購入である場合(ステップS404:YES)、商品提供制限情報管理部123は、購入権情報を生成して、その購入権情報を購入権DB14gに記憶させる(ステップS405)。例えば商品提供制限情報管理部123は、新しい購入権IDを生成してもよい。また商品提供制限情報管理部123は、設定日を今日の日付に設定してもよい。また商品提供制限情報管理部123は、既購入量を0ヶ月に設定してもよい。また商品提供制限情報管理部123は、権利状態を「有効」に設定してもよい。商品提供制限情報管理部123は、購入権ID、注文番号、その顧客の顧客ID、設定日、その商品の商品ID、最大処方量、既購入量、及び権利状態等を含む購入権情報を生成してもよい。本実施形態においては、決済完了時に購入権情報が生成される。しかしながら、商品提供制限情報管理部123は、医師による処方の確定時又は注文の確定時に、購入権情報を生成してもよい。
【0162】
ステップS405が終了した場合、注文された商品が医療用医薬品を含まない場合(ステップS403:NO)、または商品の購入が継続購入である場合(ステップS404:NO)、発送予定情報管理部116は、発送予定情報を生成して、この発送予定情報を発送予定DB14hに記憶させる(ステップS406)。例えば発送予定情報管理部116は、新しい発送予定IDを生成してもよい。また発送予定情報管理部116は、生成された注文情報から、注文番号、顧客ID、各注文商品情報、発送先情報、発送予定日等を取得してもよい。発送予定情報管理部116は、例えば購入形態ごとに発送予定情報を生成してもよい。発送予定情報管理部116は、取得された注文商品情報のうち少なくとも一つに含まれる購入形態が「逐次購入」である場合、逐次購入の対象となる商品用の発送予定情報を生成してもよい。発送予定情報管理部116は、取得された注文商品情報のうち少なくとも一つに含まれる購入形態が「定期自動購入」である場合、定期自動購入の対象となる商品用の発送予定情報を生成してもよい。発送予定情報管理部116は、各注文商品情報に基づいて、発送予定商品情報を生成してもよい。このとき、発送予定情報管理部116は、発送状態を「未発送」に設定してもよい。また発送予定情報管理部116は、発送回を1に設定してもよい。また発送予定情報管理部116は、発送予定ID、注文番号、顧客ID、購入形態、発送回、発送予定商品情報、発送先情報、発送予定日、及び発送状態等を含む発送予定情報を生成してもよい。次いで、注文確定部115は、注文完了画面のHTML文書を、顧客端末4へ送信する(ステップS407)。
【0163】
例えば販売管理サーバ1の発送予定情報管理部116は、毎日所定の時刻に、発送予定DB14hから、出荷端末3へ送信すべき発送予定情報を検索する。例えば、発送予定情報管理部116は、今日の日付及び発送予定情報に含まれる発送日に基づいて、検索を行ってもよい。図24に示すように、発送予定情報管理部116は、検索された発送予定情報を出荷端末3へ送信する(ステップS501)。このとき、発送予定情報管理部116は、発送状態が「キャンセル」に設定されている発送予定商品情報を、送信する発送予定情報から削除してもよい。全ての発送予定商品情報の発送状態が「キャンセル」である場合、発送予定情報管理部116は、その発送予定情報自体を送信しなくてもよい。出荷端末3は、受信された発送予定情報に基づいて、商品の発送予定を画面に表示する。発送予定に従って商品の発送を行った後、従業員は、出荷端末3に発送日及びその商品の配送伝票に付された伝票番号のうち少なくとも何れか一方を入力する(ステップS502)。この入力に応じて、出荷端末3は、販売管理サーバ1へ発送完了通知を送信する(ステップS503)。発送完了通知は、従業員に入力された情報及びその発送予定の発送予定IDを含んでもよい。
【0164】
販売管理サーバ1の発送予定情報管理部116は、発送完了通知から従業員により入力された情報及び発送予定IDを取得する。発送予定情報管理部116は、この発送予定IDを含む発送予定情報を、発送予定DB14hから検索する。発送予定情報管理部116は、検索された発送予定情報に含まれる各商品の発送状態のうち、「未発送」に設定されている発送状態を、「発送完了」に変更する(ステップS504)。また発送予定情報管理部116は、発送予定情報に発送日を追加する。
【0165】
次いで、商品提供制限情報管理部123は、購入権DB14gに記憶されている購入権情報を更新する(ステップS505)。例えば商品提供制限情報管理部123は、検索された発送予定情報から、商品の発送先の顧客の顧客ID及び発送された商品の発送予定商品情報を取得してもよい。商品提供制限情報管理部123は、その顧客IDと発送予定商品情報に含まれる商品IDとの組み合わせを含む購入権情報のうち、最新の設定日を含む購入権情報を検索してもよい。商品提供制限情報管理部123は、検索された購入権情報に含まれる既購入量に、発送予定商品情報に含まれる数量を加算して、この既購入量を更新してもよい。更新後の既購入量が最大処方量に達している場合、商品提供制限情報管理部123は、購入権情報に含まれる権利状態を「消滅」に変更してもよい。本実施形態においては、発送完了時に購入権情報が更新される。しかしながら、商品提供制限情報管理部123は、医師による処方の確定時又は注文の確定時に、購入権情報を更新してもよい。
【0166】
次いで、発送予定情報管理部116は、検索された発送予定情報に含まれる購入形態が、「定期自動購入」であるか否かを判定する(ステップS506)。購入形態が「定期自動購入」である場合(ステップS506:YES)、発送予定情報管理部116は、購入形態が定期自動購入である商品の購入権情報に含まれる権利状態に基づいて、その商品についての購入権が有効に存続しているか否かを判定する(ステップS507)。購入権が有効に存続している場合(ステップS507:YES)、発送予定情報管理部116は、定期配送での次回の配送のための発送予定情報を生成して、この発送予定情報を発送予定DB14hに記憶させる(ステップS508)。例えば発送予定情報管理部116は、検索された発送予定情報のコピーを生成してもよい。発送予定情報管理部116は、コピーに含まれる発送予定IDを変更してもよい。また発送予定情報管理部116は、コピーに含まれる発送回に1を加算することにより、この発送回を更新してもよい。また発送予定情報管理部116は、コピーに含まれる発送日に、定期配送の発送周期の長さを加算して、発送予定日を計算してもよい。発送予定情報管理部116は、コピーに含まれる発送予定日を、計算された発送予定日で更新してもよい。発送予定情報管理部116は、コピーから、「発送完了」に設定された発送状態を検索してもよい。発送予定情報管理部116は、検索された発送状態を「未発送」に変更してもよい。発送予定情報管理部116は、このコピーを、次回の配送のための発送予定情報として、発送予定DB14hに記憶させてもよい。
【0167】
ステップS508が終了した場合、購入形態が「逐次購入」である場合(ステップS506:NO)、または購入権が存続していない場合(ステップS507:NO)、経過観察通知送信部118は、発送予定情報に含まれる購入形態及び発送回に基づいて、今回の発送は、2回目以降の配送分の商品の発送であるか否かを判定する(ステップS509)。今回の発送が2回目以降の配送分の商品の発送ではない場合(ステップS509:NO)、購入商品識別情報117は、発送予定情報に含まれる発送予定商品情報のうち、発送状態が「発送完了」である発送予定商品情報から、購入された商品の商品IDを取得する(ステップS510)。次いで、経過観察通知送信部118は、購入された各商品の経過観察期間長を取得する(ステップS511)。例えば経過観察通知送信部118は、商品DB14bから、商品IDに関連付けられたカテゴリ情報を取得してもよい。経過観察通知送信部118は、取得されたカテゴリ情報に関連付けられた経過観察期間長を、経過観察期間DB14iから1又は複数取得してもよい。経過観察通知送信部118は、購入形態が逐次購入である商品については、既購入量に相当する長さ以下の経過観察期間長を取得してもよい。経過観察通知送信部118は、購入形態が定期自動購入である商品については、最大処方量に相当する長さ以下の経過観察期間長を取得してもよい。次いで、経過観察通知送信部118は、経過観察通知予定情報を生成して、この経過観察通知予定情報を経過観察通知予定DB14kに記憶させる(ステップS512)。例えば経過観察通知送信部118は、質問が互いに同一である商品と経過観察期間長との組み合わせごとに、経過観察通知予定情報を生成してもよい。本実施形態においては、同一のカテゴリに属する商品間で質問が同一である。経過観察通知送信部118は、新しい経過観察IDを生成してもよい。また経過観察通知送信部118は、発送予定情報に含まれる発送日に経過観察期間長を加算することにより、送信予定日を計算してもよい。前述したように、経過観察通知送信部118は、送信予定日を、発送日の丁度Nヶ月後からずらしてもよい。購入形態が逐次購入であって、且つ今回の購入が継続購入である場合、経過観察通知送信部118は、発送予定DB14hから、初回購入時の発送予定情報を検索してもよい。経過観察通知送信部118は、検索された発送予定情報に含まれる発送日に基づいて、送信予定日を計算してもよい。経過観察通知送信部118は、経過観察ID、商品の発送先の顧客の顧客ID、カテゴリ情報、商品ID、及び送信予定日等を含む経過観察通知予定情報を生成してもよい。
【0168】
図25に示すように、例えば経過観察通知送信部118は、毎日所定の時刻に、送信予定日が今日である経過観察通知予定情報を、経過観察通知予定DB14kから検索する(ステップS601)。次いで、経過観察通知送信部118は、検索された各経過観察通知予定情報について、経過観察通知メールを送信する(ステップS602)。例えば経過観察通知送信部118は、経過観察通知予定情報に含まれる商品IDに基づいて、経過観察の対象となる商品の商品名を商品DB14bから取得してもよい。経過観察通知送信部118は、その商品名を、経過観察通知メールの本文に追加してもよいまた経過観察通知送信部118は、経過観察通知予定情報に含まれる顧客IDに基づいて、経過観察通知メールの送信先の顧客の電子メールアドレスを取得してもよい。経過観察通知送信部118は、経過観察通知メールの受信者アドレスを、この電子メールアドレスに設定してもよい。また経過観察通知送信部118は、経過観察通知メールに含まれる回答ボタン3130が操作された場合に、顧客端末4から販売管理サーバ1へ質問シート画面要求が送信されるように、経過観察通知メールを生成してもよい。経過観察通知送信部118は、質問シート画面要求が経過観察IDを含むようにしてもよい。
【0169】
顧客端末4は、顧客による操作に応じて経過観察通知メールを受信して表示する(ステップS603)。顧客は回答ボタン3130を押下する(ステップS604)。この操作を検出した顧客端末4は、販売管理サーバ1へ質問シート画面要求を送信する(ステップS605)。販売管理サーバ1の購入商品識別情報取得部117は、質問シート画面要求から経過観察IDを取得する。購入商品識別情報取得部117は、この経過観察IDを含む経過観察通知予定情報を、経過観察通知予定DB14kから検索する。購入商品識別情報取得部117は、検索された経過観察通知予定情報からカテゴリ情報を取得する(ステップS606)。次いで、質問情報送信部119は、取得されたカテゴリ情報に関連付けられた質問シート画面3200のHTML文書を、記憶部14から取得する(ステップS607)。質問情報送信部119は、取得されたHTML文書を、顧客端末4へ送信する(ステップS608)。顧客端末4は、このHTML文書に基づいて、質問シート画面3200を表示する(ステップS609)。
【0170】
顧客は、質問シート画面3200に回答を入力する(ステップS610)。顧客端末4は、入力された回答を示す回答情報及び質問シート画面3200に表示された質問を示す質問情報を、販売管理サーバ1へ送信する(ステップS611)。販売管理サーバ1の回答情報受信部120は、受信された回答情報及び質問情報を、その顧客の顧客ID及び経過観察IDに関連付けて、回答DB14lに記憶させる(ステップS612)。
【0171】
医師が、医師端末2の画面に表示された経過観察の一覧から何れかの経過観察を選択する。この操作を検出した医師端末2は、図26に示すように、販売管理サーバ1へ経過観察画面要求を送信する(ステップS701)。経過観察画面要求は、選択された経過観察の経過観察IDを含んでよい。販売管理サーバ1の使用継続可否情報取得部121は、経過観察IDに関連付けられた回答情報及び質問情報を、回答DB14lから取得する(ステップS702)。使用継続可否情報取得部121は、取得された回答情報及び質問情報を含む経過観察画面3300のHTML文書を生成して、このHTML文書を医師端末2へ送信する(ステップS703)。医師端末2は、このHTML文書に基づいて、経過観察画面3300を表示する(ステップS704)。医師は、経過観察画面3300において、各商品の処方継続の可否を選択する(ステップS705)。また医師は、必要に応じてコメントを入力する。医師が送信ボタン3340を押下すると、医師端末2は、販売管理サーバ1へ経過観察結果情報を送信する(ステップS706)。経過観察結果情報は、選択された経過観察の経過観察ID、経過観察の対象となる顧客の顧客ID、及びコメントを含んでもよい。また経過観察結果情報は、商品ごとに、商品ID及び医師の選択に応じた処方継続可否情報を含んでもよい。使用継続可否情報取得部121は、受信された経過観察結果情報を、経過観察結果DB14mに記憶させる。
【0172】
販売管理サーバ1の商品提供制限情報管理部123は、経過観察結果情報に含まれる処方継続可否情報に基づいて、処方中止が決定された商品があるか否かを判定する(ステップS707)。処方中止が決定された商品がある場合(ステップS707:YES)、商品提供制限情報管理部123は、経過観察の対象の顧客の顧客IDと処方中止が決定された商品の商品IDとの組み合わせを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権DB14gから検索する。商品提供制限情報管理部123は、検索された購入権情報に含まれる権利状態を、「停止」に変更する(ステップS708)。
【0173】
次いで、発送予定情報管理部116は、経過観察の対象の顧客の顧客IDと処方中止が決定された商品の商品IDと「定期自動購入」を示す購入形態との組み合わせを含む発送予定情報を、発送予定DB14hから検索する。このとき、発送予定情報管理部116は、その商品の発送予定商品情報に含まれる発送状態が「未発送」である発送予定商品情報を検索してもよい。発送予定情報管理部116は、この検索の結果に基づいて、その商品の購入が定期自動購入であるか否かを判定する(ステップS709)。その商品の購入が定期自動購入である場合(ステップS709:YES)、発送予定情報管理部116は、検索された発送予定情報に含まれるその商品の発送予定商品情報の発送状態を、「キャンセル」に変更する(ステップS710)。
【0174】
ステップS710が終了した場合、処方中止が決定された商品がない場合(ステップS707:NO)、または商品の購入が定期自動購入ではない場合(ステップS709:NO)、経過観察結果情報送信部122は、経過観察結果メールを送信する(ステップS711)。ここで、経過観察結果情報送信部122は、経過観察結果情報に基づいて、送信する経過観察結果メールを生成してもよい。例えば処方中止が決定された商品がない場合、経過観察結果情報送信部122は、図16(a)に示す経過観察結果メールを生成してもよい。処方中止が決定された商品が存在し、且つ、購入形態が逐次購入である場合、経過観察結果情報送信部122は、図16(b)に示す経過観察結果メールを生成してもよい。処方中止が決定された商品が存在し、且つ、購入形態が定期自動購入である場合、経過観察結果情報送信部122は、図16(c)に示す経過観察結果メールを生成してもよい。経過観察結果情報送信部122は、処方中止が決定された商品の名称を、経過観察結果メールに追加してもよい。経過観察結果情報送信部122は、経過観察結果情報に含まれる顧客IDに基づいて、経過観察結果メールの送信先の顧客の電子メールアドレスを取得してもよい。経過観察結果情報送信部122は、経過観察結果メールの受信者アドレスを、この電子メールアドレスに設定してもよい。
【0175】
以上説明したように、本実施形態によれば、販売管理サーバ1が、複数の商品のうち購入された商品の商品IDを取得してもよい。また販売管理サーバ1が、購入された商品についての経過観察通知を送信してもよい。このとき、販売管理サーバ1が、商品DB14b及び経過観察期間DB14iに基づいて、商品IDにより識別される商品の購入に関連する基準日からその商品に対応する長さの期間の経過後に、経過観察通知を送信してもよい。また、販売管理サーバ1が、経過観察通知の送信後にその商品の購入者が利用する顧客端末4からの要求に応じて、質問情報を顧客端末4へ送信してもよい。このとき、販売管理サーバ1が、商品DB14b及び質問情報DB14jに基づいて、購入された商品に対応する質問情報を送信してもよい。商品DB14b及び経過観察期間DB14iからは、複数の商品のそれぞれについて、その商品の購入に関連する基準日から経過観察の時期までの期間の長さを特定可能である。そのため、商品に応じてその期間の長さが異なっていても、購入された商品に対応する長さの期間の経過後に、経過観察通知を送信することができる。商品DB14b及び質問情報DB14jからは、複数の商品それぞれについて、その商品についての質問情報を特定可能である。そのため、商品に応じて質問が異なっていても、購入された商品に対する質問を購入者に提示することができる。従って、商品の購入者に対する経過観察の負担を解消することができる。
【0176】
ここで、販売管理サーバ1が、顧客端末4から回答情報を受信してもよい。また、販売管理サーバ1が、回答情報に基づいて、使用継続可否情報を取得してもよい。また、販売管理サーバ1が、使用継続可否情報により示される使用継続の可否を含む経過観察の結果を示す経過観察結果情報を、顧客端末4へ送信してもよい。この場合、経過観察の結果が、商品の購入者に提示される。この経過観察の結果は、購入された商品の使用継続の可否を含む。使用継続可否情報は、回答情報に基づいて取得される。そのため、購入者の状況に応じた商品の使用継続の可否を、その購入者に提示することができる。
【0177】
ここで、販売管理サーバ1が、回答情報と、購入された商品の使用継続の可否の選択を受け付け可能な画面を医師端末2に表示させる画面情報と、を医師端末2へ送信してもよい。また、販売管理サーバ1が、画面情報に基づいて医師端末2により表示された画面で選択された使用継続の可否を示す使用継続可否情報を、医師端末2から受信してもよい。この場合、回答情報は医師端末2へ送信される。そのため、医師端末2を利用する決定者は、回答情報に基づいて、購入された商品の使用継続の可否を決定することができる。また、医師端末2には、購入された商品の使用継続の可否の選択を受け付け可能な画面が表示される。そのため、決定者は、商品の使用継続の可否を画面で選択することができる。
【0178】
また、販売管理サーバ1が、顧客端末4と医師端末2とを、医師による診察のための通信を可能に接続させてもよい。また、販売管理サーバ1が、顧客端末4と医師端末2との接続後、購入された商品として、その診察を通じて決済された商品の商品IDを取得してもよい。この場合、顧客端末4と医師端末2とが通信接続されることにより、医師によるオンラインでの診察が可能となる。この診察で医師が提供を指示した医薬品が購入される。この購入された医薬品について経過観察通知が送信される。そのため、診察を受けて医薬品を購入した顧客に対する経過観察の負担を解消することができる。
【0179】
また、販売管理サーバ1が、出荷端末3から発送完了通知を受信してもよい。また、販売管理サーバ1が、発送完了通知が受信された場合、発送予定DB14hに記憶された発送状態を、「未発送」から「発送完了」に変更してもよい。また、販売管理サーバ1が、発送状態が「発送完了」に設定されていることを条件に経過観察通知を送信してもよい。このとき、販売管理サーバ1が、購入された商品の発送日からその商品に対応する長さの期間の経過後に、経過観察通知を送信してもよい。この場合、購入された商品が発送されると、発送者が利用する出荷端末3から発送完了通知が送信されて、その商品の発送状態が、「未発送」から「発送完了」に変更される。発送状態が「発送完了」に変更された後、経過観察通知が送信される。経過観察通知は、その商品の発送日から、その商品に対応する長さの期間の経過後に送信される。そのため、購入された商品に応じた時期であって、その商品の発送時期に応じた時期に、経過観察を行うことができる。
【0180】
また、販売管理サーバ1が、質問情報を顧客端末4へ送信してもよい。また、販売管理サーバ1が、質問情報を受信した顧客端末4から回答情報を受信してもよい。また、販売管理サーバ1が、回答情報に基づいて、使用継続可否情報を取得してもよい。また、販売管理サーバ1が、購入権DB14gを変更して、購入者に対して、購入された商品の提供が制限されることが購入権DB14gから特定可能にしてもよい。この場合、購入された商品についての経過観察のための質問が購入者に提示される。この質問に対する回答を示す回答情報が、購入者端末から受信される。この回答情報に基づいて、購入された商品の使用継続の可否を示す使用継続可否情報が取得される。その商品の使用継続が不可である場合、購入権DB14gが変更される。これにより、購入された商品を購入者へ提供することが制限されていることが、購入権DB14gから特定可能となる。そのため、購入権DB14gを参照することにより、購入者への商品の提供を制限するための処理を行うことができる。従って、商品の購入後における購入者の状況に応じて商品の提供を制限するための情報を記憶させることができる。
【0181】
ここで、販売管理サーバ1が、注文のために顧客により選択された商品を示す商品ID及びその商品を選択した顧客の顧客IDを取得してもよい。また、販売管理サーバ1が、顧客IDにより示される顧客に対して商品IDにより示される商品の提供が制限されることが購入権DB14gから特定される場合、顧客と医師との面談を支援してもよい。また、販売管理サーバ1が、その面談後、選択された商品の注文を確定させる確定させてもよい。また、販売管理サーバ1が、顧客IDにより示される顧客に対して商品IDにより示される選択された商品の提供が制限されないことが購入権DB14gから特定される場合、面談なくして注文を確定させてもよい。この場合、注文のために顧客により選択された商品をその顧客に提供することが制限される場合、顧客とその商品の使用可否を決定する医師との面談が可能とされる。その面談後、選択された商品の注文が確定する。選択された商品をその顧客に提供することが制限されない場合、顧客と医師との面談を省略して、選択された商品の注文が確定する。そのため、商品の提供が制限されるか否かで、その商品の注文の確定に面談が必要であるか否かが異なる。従って、注文のための条件を設けることで、商品の提供を適切に制限することができる。
【0182】
ここで、販売管理サーバ1が、顧客が利用する顧客端末4と医師が利用する医師端末2とを、面談のための通信を可能に接続させてもよい。また、販売管理サーバ1が、顧客IDにより示される顧客に対して商品IDにより示される商品の提供が制限されることが購入権DB14gから特定される場合、顧客端末4と医師端末2との接続後、注文を確定させてもよい。また、販売管理サーバ1が、その顧客に対してその商品の提供が制限されないことが購入権DB14gから特定される場合、顧客端末4と医師端末2との接続を省略して、注文を確定させてもよい。この場合、顧客端末と医師端末とが通信接続されることにより、顧客と医師とのオンラインでの面談が可能となる。オンラインでの面談後、注文が確定する。そのため、顧客に商品の提供が制限される場合、その商品の注文を確定させるための条件としての面談を、オンラインで実現することができる。
【0183】
また、販売管理サーバ1が、購入者に対して、購入された商品の提供が制限されることが特定可能に変更される場合、購入者に対するその商品の次回の発送をキャンセルしてもよい。この場合、購入された商品を購入者へ提供することが制限されない場合、その商品は購入者へ定期的に発送される。購入された商品を購入者へ提供することが制限される場合、その商品の次回の発送がキャンセルされる。これにより、商品の定期的な発送が停止される。そのため、商品が定期的に発送される形態における商品の提供を適切に制限することができる。
【0184】
[2.第2実施形態]
次に第2実施形態について、図27及び図28を参照して説明する。本実施形態においては、商品の注文に必要な操作が制限されることで、顧客に対する商品の提供が制限されてもよい。以下に説明する点を除き、第2実施形態は第1実施形態と同一であってもよい。
【0185】
前述したように、販売画面情報送信部111は、顧客端末4からの要求に応じた商品に関する情報を含む画面を表示させる画面情報を、その顧客端末4へ送信する。販売画面情報送信部111は、その顧客端末4を利用する顧客に対してその要求に応じた商品の提供が制限されることが商品提供制限情報から特定されない場合、その商品を選択するための操作を受け付ける画面を表示させるための画面情報を送信してもよい。一方、販売画面情報送信部111は、その顧客に対してその商品の提供が制限されることが商品提供制限情報から特定される場合、その商品を選択するための操作を受け付けない画面を表示させるための画面情報を送信してもよい。商品を選択するための操作は、その操作を行うことによって、最終的には顧客がその商品を注文することが可能となる操作であってもよい。商品を選択するための操作の例として、検索結果画面に表示された商品の一覧から何れかの商品を選択する操作、商品画面1200で商品をカートに追加する操作、注文申込内容確認画面1400で商品の注文を申し込む操作、注文内容確認画面2100で商品の注文を確定させる操作等が挙げられる。
【0186】
図27は、商品画面1200の一例を示す図である。図27において、図9と同一の要素については同一の符号が付されている。顧客に対して商品の提供が制限されない場合、図9に示すような商品画面1200が表示されてもよい。この場合、顧客はカート追加ボタン1220を操作することができる。これにより、その商品はカートに追加される。顧客に対して商品の提供が制限される場合、図12に示すような商品画面1200が表示されてもよい。図12に示すように、商品画面1200は、購入形態・数量選択ボタン群1210、カート追加ボタン1220、及びカートアコン1230等に加えて、メッセージ1240、及び診察予約リンク1250を含んでもよい。図12において、カート追加ボタン1220は破線で示されている。これは、カート追加ボタン1220が無効であることを示している。そのため、顧客はカート追加ボタン1220を操作することができない。なお、カート追加ボタン1220自体が非表示になっていてもよい。商品をカートに追加することができないため、顧客は商品を注文することができない。メッセージ1240は、顧客への商品の提供が制限されていることを示してもよい。診察予約リンク3430は、オンライン診察の予約を行うために操作可能なリンクであってもよい。提供が制限されている商品を選択して注文を申し込むことはできないものの、顧客は、オンライン診察において医師によりその商品を改めて処方してもらうことができる場合がある。
【0187】
システム制御部11は、商品提供制限情報を管理することなく若しくは商品提供制限情報を参照することなく、顧客に対して商品の提供を制限するための処理を行ってもよい。例えば販売画面情報送信部111は、使用継続可否情報取得部121により取得された使用継続可否情報が使用継続可を示す場合、その商品を選択するための操作を受け付ける画面を表示させるための画面情報を送信してもよい。販売画面情報送信部111は、使用継続可否情報取得部121により取得された使用継続可否情報が、使用継続の不可を示す場合、その商品を選択するための操作を受け付けない画面を表示させるための画面情報を送信してもよい。
【0188】
図28は、本実施形態に係る販売管理サーバ1のシステム制御部11により実行される商品画面情報送信処理の一例を示すフローチャートである。例えば顧客は、検索結果画面から、検索された商品のうち何れかの商品を選択する操作を行う。この操作を検出した顧客端末4は、販売管理サーバ1へ商品画面要求を送信する。商品画面要求は、その顧客の顧客ID及び選択された商品の商品IDを含んでもよい。システム制御部11は、販売管理サーバ1が顧客端末4から商品画面要求を受信することに応じて、商品画面情報送信処理を実行してもよい。
【0189】
図28に示すように、販売画面情報送信部111は、顧客により選択された商品の商品画面のHTML文書を取得する(ステップS801)。例えば記憶部14には、商品ごとに、その商品の商品画面のHTML文書が商品IDに関連付けて記憶されてもよい。販売画面情報送信部111は、商品画面要求に含まれる商品IDに関連付けられたHTML文書を取得してもよい。次いで、販売画面情報送信部111は、その顧客の顧客IDと選択された商品の商品IDとを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権DB14gから検索する(ステップS802)。検索の結果、販売画面情報送信部111は、該当する購入権情報があるか否かを判定する(ステップS803)。該当する購入権情報がある場合(ステップS803:YES)、販売画面情報送信部111は、その購入権情報に含まれる権利状態が「停止」であるか否かを判定する(ステップS804)。権利状態が「停止」ではない場合(ステップS804:NO)、または該当する購入権情報がない場合(ステップS803:NO)、販売画面情報送信部111は、商品画面のHTML文書内におけるカート追加ボタン1220の有効性を示す情報を、有効に設定する(ステップS805)。権利状態が「停止」である場合(ステップS804:YES)、販売画面情報送信部111は、カート追加ボタン1220の有効性を示す情報を、無効に設定する(ステップS806)。ステップS805又はS806が終了すると、販売画面情報送信部111は、商品画面のHTML文書を顧客端末4へ送信して(ステップS807)、商品画面情報送信処理は終了する。顧客端末4は、このHTML文書に基づいて商品画面を表示する。カート追加ボタン1220の有効性を示す情報が有効である場合、顧客端末4は、カート追加ボタン1220の操作が可能となるように、カート追加ボタン1220を表示する。その有効性を示す情報が無効である場合、顧客端末4は、カート追加ボタン1220の操作が不可能となるように、カート追加ボタン1220を表示する。
【0190】
以上説明したように、本実施形態によれば、顧客端末4からの要求に応じた商品の情報を含む画面が顧客端末4に表示される。顧客に対してその商品の提供が制限されない場合、その商品を選択する操作が可能なように、その画面が表示される。そのため、顧客はその商品を注文することができる。顧客に対してその商品の提供が制限される場合、その商品を選択する操作が不可能なように、その画面が表示される。そのため、顧客はその商品を注文することができない。そのため、電子商取引に係る画面が、商品を選択する操作を受け入れるか否かによって、商品の提供の制限を制御することができる。
【0191】
[3.第3実施形態]
次に第3実施形態について、図29及び図30を参照して説明する。本実施形態においては、顧客に対する商品の提供の制限が解除される場合がある。以下に説明する点を除き、第2実施形態は第1実施形態及び第2実施形態のうち少なくとも何れか一方と同一であってもよい。
【0192】
これまで説明したように、顧客に対して商品の提供が一度制限された場合であっても、その顧客は医師からその商品を改めて処方してもらうことで、その商品を購入することができた。これは、顧客が新しい購入権を取得することに相当してもよい。この場合、顧客は最大処方量の範囲内で、その商品を購入することができる。これに対して、本実施形態の提供制限の解除は、購入権の停止が解除されること、または消滅した購入権が回復することであってもよい。この場合、最大処方量から顧客が既に購入している数量を減算して計算される残量の範囲内で、顧客はその商品を継続購入することが可能であってもよい。顧客が定期自動購入で商品を購入していた場合、停止されていた定期配送が再開してもよい。
【0193】
図29は、本実施形態に係る販売管理サーバ1におけるシステム制御部11の機能ブロックの一例を示す図である。図29において、図8と同一の要素については同一の符号が付されている。図29に示すように、システム制御部11は、販売画面情報送信部111、選択商品識別情報取得部112、カート情報管理部113、診察支援部114、注文確定部115、発送予定情報管理部116、購入商品識別情報取得部117、経過観察通知送信部118、質問情報送信部119、回答情報受信部120、使用継続可否情報取得部121、経過観察結果情報送信部122、及び商品提供制限情報管理部123に加えて、商品提供制限解除情報取得部124及び商品提供制限解除通知送信部125として機能してもよい。
【0194】
商品提供制限解除情報取得部124は、商品提供制限情報管理部123により、商品の購入者に対してその商品の提供が制限されることを特定可能に商品提供制限情報が変更された後、商品提供制限解除情報を受信してもよい。商品提供制限解除情報は、その購入者に対するその商品の提供の制限が解除されることを示す情報であってもよい。商品提供制限解除情報は、提供の制限が解除される商品の商品IDを含んでもよい。また商品提供制限解除情報は、商品の提供が解除される顧客の顧客IDを含んでもよい。或いは、商品提供制限解除情報は、その商品の提供の制限が決定された経過観察の経過観察IDを含んでもよい。
【0195】
商品提供制限解除情報取得部124は、商品提供制限解除情報を医師端末2から取得してもよい。例えば医師が、顧客に対する商品の提供の制限を解除するか否かを決定してもよい。例えば、その顧客と医師との間でのやりとりの結果、医師が決定を行ってもよい。例えば診察により、商品の提供の制限を解除されるか否かが決定されてもよい。医師は、診察中に決定を行ってもよいし、診察後に決定を行ってもよい。或いは、処方中止後に経過観察が行われてもよい。この経過観察では、提供が制限された商品を顧客が使用していないという仮定の下でその顧客の状態を確認するための質問が顧客に提示されてもよい。この経過観察にて、医師が商品の提供に対する制限の解除を決定してもよい。
【0196】
商品提供制限情報管理部123は、商品提供制限解除情報取得部124により商品提供制限情報が取得された場合、商品提供制限情報を変更して、商品の購入者に対するその商品の提供が制限されないことを商品制限情報から特定可能にしてもよい。例えば商品提供制限情報管理部123は、該当する購入権情報に含まれる権利状態を、「停止」から「有効」に変更してもよい。これにより、購入権の停止が解除されてもよい。購入権の停止が解除されることで、逐次購入による継続購入が可能となる。例えば第1実施形態の場合、顧客は、医師の診察を受けることなく、その商品を注文することができる。第2実施形態の場合、顧客はその商品を選択することができる。
【0197】
発送予定情報管理部116は、定期自動購入で購入された商品について商品提供制限解除情報取得部124により商品提供制限情報が取得された場合、次回以降の配送のキャンセルを取り下げてもよい。これにより定期配送が再開されてもよい。例えば発送予定情報管理部116は、発送予定情報に含まれる該当の商品の発送状態を、「キャンセル」から「未発送」に変更してもよい。
【0198】
商品提供制限解除通知送信部125は、商品提供制限解除情報取得部124により商品提供制限情報が取得された場合、購入者に向けて商品提供制限解除通知を送信してもよい。商品提供制限解除通知は、その購入者に対する商品の提供の制限が解除されることを、購入者に知らせる情報であってもよい。商品提供制限解除通知は、提供制限が解除された商品の名称を含んでもよい。商品提供制限解除通知送信部125は、その購入者宛ての電子メール又はインスタントメッセージで、商品提供制限解除通知を送信してもよい。或いは商品提供制限解除通知送信部125は、その購入者の顧客端末4へ、プッシュ通知で商品提供制限解除通知を送信してもよい。或いは商品提供制限解除通知送信部125は、その顧客端末4からの要求に応じて、商品提供制限解除通知を含む画面を顧客端末4に表示させる画面情報を、その顧客端末4へ送信してもよい。
【0199】
図30は、本実施形態に係る通信システムSの処理例を示すシーケンス図である。例えば医師は、医師端末2を操作して、過去に処方中断を決定した経過観察を選択する。この操作に応じて、医師端末2は、各商品の処方継続の可否の決定結果を含む経過観察の結果を示す画面を表示する。この画面は、処方が中断された商品について、処方中断の解除の選択を受け付け可能であってもよい。図30に示すように、医師は、何れかの商品の処方中断の解除を選択する(ステップS901)。この操作を検出した医師端末2は、販売管理サーバ1へ処方中断解除情報を送信する(ステップS902)。処方中断解除情報は、商品提供制限解除情報に相当する。処方中断解除情報は、例えばその経過観察の経過観察ID、経過観察の対象となった顧客の顧客ID、及び処方中断が解除された商品の商品IDを含んでもよい。
【0200】
販売管理サーバ1の商品提供制限情報管理部123は、処方中断解除情報に基づいて、経過観察の対象となった顧客の顧客IDと処方中断が解除された商品の商品IDとを含む購入権情報のうち、最新の設定日を含む購入権情報を、購入権DB14gから検索する。商品提供制限情報管理部123は、検索された購入権情報に含まれる権利状態を、「有効」に変更する(ステップS903)。次いで、発送予定情報管理部116は、処方中断が解除された商品の購入形態が定期自動購入であるか否かを判定する(ステップS904)。例えば発送予定情報管理部116は、経過観察の対象となった顧客の顧客IDと処方中断が解除された商品の商品IDとを含む発送予定情報のうち、最新の発送予定日を含む発送予定情報を、発送予定DB14hから検索してもよい。発送予定情報管理部116は、検索された発送予定情報に含まれる購入形態に基づいて判定を行ってもよい。購入形態が定期自動購入である場合(ステップS904:YES)、商品提供制限情報管理部123は、検索された発送予定情報に含まれる発送状態を、「未発送」に変更する(ステップS905)。なお、定期配送での一の配送で複数の商品が発送される場合、それらの商品のうち、処方継続が決定された商品は既に発送されていることがある。この場合、発送予定情報管理部116は、処方中断が解除された商品のための新しい発送予定情報を生成してもよい。また発送予定情報管理部116は、新たな発送日を設定してもよい。
【0201】
ステップS905が終了した場合、または購入形態が逐次購入である場合(ステップS9904:NO)、商品提供制限解除通知送信部125は、商品提供制限解除通知メールを送信する(ステップS906)。商品提供制限解除通知メールは、商品提供制限解除通知を示す電子メールである。例えば商品提供制限解除通知送信部125は、処方中断解除情報に含まれる商品IDに基づいて、処方中断が解除される商品の商品名を商品DB14bから取得してもよい。商品提供制限解除通知送信部125は、その商品名を、商品提供制限解除通知メールの本文に追加してもよいまた商品提供制限解除通知送信部125は、処方中断解除情報に含まれる顧客IDに基づいて、顧客の電子メールアドレスを取得してもよい。商品提供制限解除通知送信部125は、商品提供制限解除通知メールの受信者アドレスを、この電子メールアドレスに設定してもよい。
【0202】
以上説明したように、本実施形態によれば、購入された商品の提供が制限された後、その制限が解除される場合がある。その場合、購入権DB14gが再変更される。これにより、購入された商品を購入者へ提供することが制限されないことが、購入権DB14gから特定可能となる。そのため、購入権DB14gを参照することにより、購入者への商品の提供を可能とするための処理を行うことができる。
【0203】
(付記1-1)複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段と、を備え、前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の購入に関連する基準日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御装置。
【0204】
(付記1-2)前記送信された質問情報により示される前記質問に対する前記回答を示す回答情報を、前記購入者端末装置から受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者端末装置へ送信する結果情報送信手段と、を更に備えることを特徴とする付記1-1に記載のフォローアップ制御装置。
【0205】
(付記1-3)前記可否情報取得手段は、前記受信された回答情報と、前記取得された購入商品識別情報により識別される前記購入商品の使用継続の可否の選択を受け付け可能な画面を、前記購入商品の使用継続の可否を決定する決定者が利用する決定者端末装置に表示させる画面情報と、を前記決定者端末装置へ送信する回答情報送信手段と、前記送信された画面情報に基づいて前記決定者端末装置により表示された前記画面で選択された前記使用継続の可否を示す前記可否情報を、前記決定者端末装置から受信する可否情報受信手段と、を含むことを特徴とする付記1-2に記載のフォローアップ制御装置。
【0206】
(付記1-4)前記購入商品は医薬品であり、前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段を更に備え、前記購入商品識別情報取得手段は、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記購入商品として、前記診察を通じて決済された商品を識別する前記購入商品識別情報を取得することを特徴とする付記1-1乃至1-3の何れか一に記載のフォローアップ制御装置。
【0207】
(付記1-5)前記購入商品が前記購入者に向けて発送されたことを示す発送完了情報を、前記購入商品の発送者が利用する発送者端末装置から受信する発送完了情報受信手段と、前記発送完了情報受信手段により前記発送完了情報が受信された場合、所定の記憶手段に記憶された発送状態であって、前記購入商品の前記購入者への発送状態を、未発送状態から発送完了状態に変更する変更手段と、を更に備え、前記基準日は、前記購入商品の発送日であり、前記促し情報送信手段は、前記発送状態が前記発送完了状態に設定されていることを条件に前記促し情報を送信し、前記発送日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信することを特徴とする付記1-1乃至1-4の何れか一に記載のフォローアップ制御装置。
【0208】
(付記1-6)コンピュータにより実行されるフォローアップ制御方法において、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得ステップと、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信ステップと、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信ステップと、を含み、前記促し情報送信ステップは、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の購入に関連する基準日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信ステップは、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御方法。
【0209】
(付記1-7)コンピュータを、複数の商品のうち購入された購入商品を識別する購入商品識別情報を取得する購入商品識別情報取得手段と、前記取得された購入商品識別情報により識別される前記購入商品についてのフォローアップのための質問への回答を前記購入商品の購入者に促す促し情報を送信する促し情報送信手段と、前記促し情報の送信後に前記購入者が利用する購入者端末装置からの要求に応じて、前記質問を示す質問情報を前記購入者端末装置へ送信する質問情報送信手段、として機能させ、前記促し情報送信手段は、前記フォローアップの時期までの期間の長さを示す商品期間長情報であって、前記複数の商品のそれぞれに対応する長さの特定が可能な商品期間長情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品の購入に関連する基準日から該購入商品に対応する前記長さの期間の経過後に、前記促し情報を送信し、前記質問情報送信手段は、前記複数の商品のそれぞれに対応する前記質問情報の特定が可能に該質問情報を示す商品質問情報に基づいて、前記取得された購入商品識別情報により識別される前記購入商品に対応する前記質問情報を送信することを特徴とするフォローアップ制御プログラム。
【0210】
(付記2-1)購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信手段と、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、所定の記憶手段に記憶された制限情報であって、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段と、を備えることを特徴とする商品提供制御装置。
【0211】
(付記2-2)注文のために顧客により選択された選択商品を示す選択商品識別情報及び前記選択商品を選択した前記顧客を識別する顧客識別情報を取得する識別情報取得手段と、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記顧客と該選択商品の使用の可否を決定する決定者との面談を支援する面談支援手段と、前記面談支援手段より支援された前記面談後、前記選択商品の注文を確定させる確定手段と、を更に備え、前記確定手段は、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談なくして前記注文を確定させることを特徴とする付記2-1に記載の商品提供制御装置。
【0212】
(付記2-3)前記面談支援手段は、前記顧客が利用する顧客端末装置と前記決定者が利用する決定者端末装置とを、前記面談のための通信を可能に接続させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されることが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続後、前記確定手段は前記注文を確定させ、前記取得された顧客識別情報により示される前記顧客に対して前記取得された選択商品識別情報により示される前記選択商品の提供が制限されないことが前記制限情報から特定される場合、前記面談支援手段による前記顧客端末装置と前記決定者端末装置との接続を省略して、前記確定手段は前記注文を確定させることを特徴とする付記2-2に記載の商品提供制御装置。
【0213】
(付記2-4)前記購入商品の提供は、前記購入者に対して前記購入商品を定期的に発送する形態の提供であり、前記変更手段により前記購入者に対して前記購入商品の提供が制限されることが特定可能に変更される場合、前記購入者に対する前記購入商品の次回の発送をキャンセルするキャンセル手段を更に備えることを特徴とする付記2-1乃至2-3の何れか一に記載の商品提供制御装置。
【0214】
(付記2-5)商品の注文を可能とする電子商取引に係わる画面であって、顧客が利用する顧客端末装置からの要求に応じた要求商品に関する情報を含む画面を前記顧客端末装置に表示させる画面情報を、前記顧客端末装置へ送信する画面情報送信手段を更に備え、前記画面情報送信手段は、前記顧客に対して前記要求商品の提供が制限されないことが前記制限情報から特定される場合、前記要求商品を選択するための操作を受け付ける前記画面を表示させるための前記画面情報を送信し、前記顧客に対して前記要求商品の提供が制限されることが前記制限情報から特定される場合、前記操作を受け付けない前記画面を表示させるための前記画面情報を送信することを特徴とする付記2-1乃至2-4の何れか一に記載の商品提供制御装置。
【0215】
(付記2-6)前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段を更に備え、前記変更手段は、前記解除情報取得手段により前記解除情報が取得された場合、前記制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されないことを前記制限情報から特定可能にすることを特徴とする付記2-1乃至2-5の何れか一に記載の商品提供制御装置。
【0216】
(付記2-7)前記変更手段により前記購入者に対して前記購入商品の提供が制限されることを特定可能に前記制限情報が変更された後、前記購入商品の提供制限の解除を示す解除情報を取得する解除情報取得手段と、前記解除情報取得手段により前記解除情報が受信された場合、前記キャンセル手段による前記発送のキャンセルを取り下げる取り下げ手段と、を更に備えることを特徴とする付記2-4に記載の商品提供制御装置。
【0217】
(付記2-8)前記取得された可否情報により示される前記使用継続の可否を含むフォローアップの結果を示す結果情報を、前記購入者向けに送信する結果情報送信手段を更に備えることを特徴とする付記2-1乃至2-7の何れか一に記載の商品提供制御装置。
【0218】
(付記2-9)前記購入された商品は医薬品であり、前記購入者端末装置と医師が利用する医師端末装置とを、前記医師による診察のための通信を可能に接続させる接続手段と、前記接続手段による前記購入者端末装置と前記医師端末装置との接続後、前記診察を通じて決済された商品の注文を確定させる確定手段と、を更に備え、前記質問情報送信手段は、前記確定手段により前記注文が確定された前記商品について、前記質問情報を送信することを特徴とする付記2-1乃至2-8の何れか一に記載の商品提供制御装置。
【0219】
(付記2-10)コンピュータにより実行される商品提供制御方法において、購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信ステップと、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信ステップと、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得ステップと、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、所定の記憶手段に記憶された制限情報であって、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更ステップと、を含むことを特徴とする商品提供制御方法。
【0220】
(付記2-11)コンピュータを、購入された購入商品についてのフォローアップのための質問を示す質問情報を、前記購入商品の購入者が利用する購入者端末装置へ送信する質問情報送信手段と、前記送信された質問情報を受信した前記購入者端末装置から、前記質問に対する回答を示す回答情報を受信する回答情報受信手段と、前記受信された回答情報に基づいて、前記購入商品の使用継続の可否を示す可否情報を取得する可否情報取得手段と、前記取得された可否情報により前記購入商品の使用継続の不可が示される場合、所定の記憶手段に記憶された制限情報であって、顧客に対して商品の提供が制限されるか否かを顧客と商品との組み合わせごとに特定可能な制限情報を変更して、前記購入者に対して前記購入商品の提供が制限されることが前記制限情報から特定可能にする変更手段、として機能させることを特徴とする商品提供制御プログラム。
【符号の説明】
【0221】
1 販売管理サーバ
2 医師端末
3 出荷端末
4 顧客端末
11 システム制御部
12 システムバス
13 入出力インタフェース
14 記憶部
14a 会員DB
14b 商品DB
14c カートDB
14d 診察予約DB
14e 処方履歴DB
14f 注文DB
14g 購入権DB
14h 発送予定DB
14i 経過観察期間DB
14j 質問情報DB
14k 経過観察通知予定DB
14l 回答DB
14m 経過観察結果DB
111 販売画面情報送信部
112 選択商品識別情報取得部
113 カート情報管理部
114 診察支援部
115 注文確定部
116 発送予定情報管理部
117 購入商品識別情報取得部
118 経過観察通知送信部
119 質問情報送信部
120 回答情報受信部
121 使用継続可否情報取得部
122 経過観察結果情報送信部
123 商品提供制限情報管理部
124 商品提供制限解除情報取得部
125 商品提供制限解除通知送信部
NW ネットワーク
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30