(57)【要約】【課題】購入者が情報提供の対象となる商品の注文内容を送信する場合であっても、情報提供の対象とはされていない商品の場合と同様に分かりやすい手順としつつ、商品の発送までに個別の情報提供を可能とする情報システム及び情報処理方法を提供する。【解決手段】情報システムは、受け付けられた注文内容に示される商品が対象商品である場合、状態情報に応じて生成された留意情報を購入者が確認可能に出力する。また、情報システムは、留意情報を理解したと購入者が確認したことを示す確認通知を受け付けた場合、確認状態を完了状態に更新する。また、情報システムは、確認状態を、対象商品の販売成立のための処理が可能であるかを判定可能に出力する。【選択図】図２
2015230708.tif 000002
【特許請求の範囲】
【請求項１】
購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付手段と、
前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御手段と、
受け付けられた前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御手段と、
前記注文内容に示される前記対象商品と前記状態情報受付手段により受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力手段と、
前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付手段と、
前記確認通知受付手段により前記確認通知が受け付けられた場合、前記注文内容記憶手段に記憶された前記確認状態を完了状態に更新する更新手段と、
前記注文内容記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力手段と、  を備えることを特徴とする情報システム。
【請求項２】
請求項１に記載の情報システムにおいて、
前記注文内容記憶手段に記憶される前記注文内容に関連付けて、該注文内容に示される商品の購入代金の支払いのための処理状態と、該商品の発送状態とを状態記憶手段に記憶させる状態記憶制御手段と、
前記注文内容に示される商品が前記対象商品ではない場合、前記処理状態が完了状態に更新されていることを条件に、前記発送状態を発送可能状態に更新する第１発送状態更新手段と、
前記注文内容に示される商品が前記対象商品である場合、前記処理状態と前記確認状態との何れもが完了状態に更新されていることを条件に、前記発送状態を発送可能状態に更新する第２発送状態更新手段と、
前記状態記憶手段に記憶された前記発送状態を出力する発送状態出力手段と、
を更に備えることを特徴とする情報システム。
【請求項３】
請求項１又は２に記載の情報システムにおいて、
前記注文内容に示される商品が前記対象商品である場合、前記留意情報へのリンク情報を提示させるリンク情報提示制御手段を更に備え、
前記留意情報出力手段は、前記リンク情報が選択された場合、前記留意情報と該留意情報を理解したと確認したことを示すために操作可能な確認要素とを提示させ、
前記確認通知受付手段は、前記確認要素が操作されることに基づく前記確認通知を取得することを特徴とする情報システム。
【請求項４】
請求項１乃至３の何れか１項に記載の情報システムにおいて、
前記確認状態出力手段は、前記注文内容記憶手段に記憶された前記注文内容について販売者向けの情報を提示させ、前記注文内容に示される商品が前記対象商品である場合、該注文内容に関連付けられた前記確認状態に応じて外観が変化する画像を前記販売者向けの情報とともに提示させることを特徴とする情報システム。
【請求項５】
請求項１乃至４の何れか１項に記載の情報システムにおいて、
前記注文内容記憶手段に記憶された前記注文内容を販売者向けに出力する注文内容出力手段であって、前記注文内容に示される商品が前記対象商品であり、且つ前記注文内容に関連付けられた前記確認状態が未完了状態である場合、前記注文内容のうち商品の送付先の住所を出力しない注文内容出力手段を更に備えることを特徴とする情報システム。
【請求項６】
請求項１乃至５の何れか１項に記載の情報システムにおいて、
前記注文内容記憶手段に記憶された前記注文内容に示される商品の配送伝票情報の入力を受け付ける配送伝票受付手段であって、前記商品が前記対象商品であり且つ前記注文内容に関連付けられた前記確認状態が未完了状態である場合、前記配送伝票情報を受け付けない配送伝票受付手段を更に備えることを特徴とする情報システム。
【請求項７】
請求項１乃至６の何れか１項に記載の情報システムにおいて、
前記留意情報が生成された場合、該留意情報の確認が必要であることを前記購入者に通知する通知情報を出力する通知情報出力手段と、
前記通知情報出力手段により前記通知情報が出力されてから設定期間内に前記確認通知受付手段により前記確認通知が受け付けられなかった場合、前記注文内容の受け付けをキャンセルするキャンセル手段を更に備えることを特徴とする情報システム。
【請求項８】
請求項７に記載の情報システムにおいて、
前記状態情報受付手段により受け付けられた前記状態情報を前記注文内容記憶手段に記憶される前記注文内容に関連付けて状態情報記憶手段に記憶させる状態情報記憶制御手段と、
受け付けがキャンセルされた注文内容の少なくとも一部と、該注文内容に示される商品の再注文のために操作可能な再注文要素とを提示させるキャンセル注文提示制御手段と、
を更に備え、
前記状態情報受付手段は、前記再注文要素が操作されることに基づいて前記再注文のための注文内容が受け付けられる場合、前記受け付けがキャンセルされた注文内容に関連付けられた状態情報を、前記再注文のための注文内容に関連付けられる状態情報として取得することを特徴とする情報システム。
【請求項９】
請求項８に記載の情報システムにおいて、
前記受け付けがキャンセルされた注文内容に関連付けられた状態情報が変化する可能性がある情報である場合、該状態情報の有効日数を取得する有効日数取得手段と、
前記受け付けがキャンセルされた注文内容が受け付けられてから前記再注文要素が操作されるまでの経過日数が、前記有効日数取得手段により取得された前記有効日数を超える場合、前記使用者の状態情報の再入力を前記購入者に要求する要求情報を提示させる要求情報提示制御手段と、
を更に備え、
前記状態情報受付手段は、前記購入者から再入力された状態情報を受け付けることを特徴とする情報システム。
【請求項１０】
請求項７乃至９の何れか１項に記載の情報システムにおいて、
前記購入者から受け付けられた注文内容が配送日の指定を含む場合、該配送日に商品を配達するための発送期限を取得する発送期限取得手段と、
前記発送期限に基づいて、前記留意情報の確認期限を決定する確認期限決定手段と、
を更に備え、
前記キャンセル手段は、前記確認期限決定手段により決定された前記確認期限までに前記確認通知受付手段により前記確認通知が受け付けられなかった場合、前記注文内容の受け付けをキャンセルすることを特徴とする情報システム。
【請求項１１】
請求項１乃至１０の何れか１項に記載の情報システムにおいて、
生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後、前記確認通知受付手段により前記確認通知が受け付けられるまでに、前記留意情報の確認を前記購入者に促すリマインド情報であって所定時間間隔ごとに出力されるリマインド情報が出力された回数を取得する回数取得手段と、
前記通知情報が出力された後に前記確認通知が受け付けられていない注文内容のための前記リマインド情報を出力する時間間隔を、前記回数取得手段により取得された前記回数に応じて決定する時間間隔決定手段と、
を更に備えることを特徴とする情報システム。
【請求項１２】
請求項１乃至１１の何れか１項に記載の情報システムにおいて、
前記確認通知受付手段により前記確認通知が受け付けられた時間を取得する時間取得手段と、
生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後に前記確認通知が受け付けられていない場合における前記留意情報の確認を前記購入者に促すリマインド情報を出力する時間を、前記時間取得手段により取得された前記時間に応じて決定する時間決定手段と、
を更に備えることを特徴とする情報システム。
【請求項１３】
請求項１乃至１２の何れか１項に記載の情報システムにおいて、
前記購入者から受け付けられた前記注文内容に示される商品が前記対象商品である場合、該商品についてこれまでに受け付けられている１以上の注文内容のうち発送が完了していない注文内容に応じた前記商品の数を取得する商品数取得手段と、
生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後に前記確認通知が受け付けられていない場合における前記留意情報の確認を前記購入者に促すリマインド情報を出力する頻度を決定する頻度決定手段であって、前記商品数取得手段により取得された前記数が多いほど前記頻度を高くする頻度決定手段と、
を更に備えることを特徴とする情報システム。
【請求項１４】
請求項１乃至１３の何れか１項に記載の情報システムにおいて、
前記購入者から何れかの商品の注文内容が受け付けられた場合に該注文内容が受け付けられたことを示す受付情報を提示させる受付情報提示制御手段であって、前記購入者から前記対象商品について過去に受け付けられた注文内容に関連付けられた確認状態が未完了状態である場合、前記留意情報の確認を促す情報を前記受付情報とともに提示させる受付情報提示制御手段を更に備えることを特徴とする情報システム。
【請求項１５】
コンピュータにより実行される情報処理方法であって、
購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付ステップと、
前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御ステップと、
前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御ステップと、
前記注文内容に示される前記対象商品と前記状態情報受付ステップにより受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力ステップと、
前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付ステップと、
前記確認通知受付ステップにより前記確認通知が受け付けられた場合、前記注文内容記憶手段に記憶された前記確認状態を完了状態に更新する更新ステップと、
前記注文内容記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力ステップと、
を含むことを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、購入者が購入しようとする商品について販売者から情報提供を行うためのシステムの技術分野に関する。
【背景技術】
【０００２】
例えば、特許文献１には、購入者が健康状態等をオンラインショッピングシステムの相談員に相談して、相談員が相談内容に応じて回答を行うとともに推奨商品を提示し、購入者が推奨商品の中から購入商品を選択するシステムが開示されている。このシステムにおいては、購入者が商品を注文する前に、相談員から情報提供が行われる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−２４６３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、インターネットを利用して医薬品が販売される場合、購入者が購入する医薬品を決めている場合であっても、安全性を確保するために購入者に対して情報提供を行うことが好ましい場合がある。具体的に、その医薬品を使用する使用者の症状などの状態を考慮した上で販売者から使用者に合った情報提供を行い、提供された情報を購入者が理解したことを確認した上で販売者が購入者へその医薬品を販売することが好ましい場合がある。このような商品は医薬品に限られるものではない。例えば、食物アレルギーとの関連性がある食材や栄養食品等についても、上述したような情報提供を行うことが好ましい場合がある。
【０００５】
その一方で、インターネットを利用して購入者が商品を購入する場合、購入する商品、配送先、決済方法等を含んだ注文内容を購入者が送信するという手順が一般的に定着している。そのため、商品、使用者の状態に応じた個別の情報提供を行うとき、例えば特許文献１に記載のシステムのように、購入者が注文内容を送信する前に情報提供が行われると、一般的に定着した手順を変更することになる。その結果、注文内容を送信までの手順が購入者にとって分かりにくくなる。
【０００６】
本発明は、以上の点に鑑みてなされたものであり、購入者が情報提供の対象となる商品の注文内容を送信する場合であっても、情報提供の対象とはされていない商品の場合と同様に分かりやすい手順としつつ、商品の販売（契約）成立までに個別の情報提供を可能とする情報システム及び情報処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付手段と、前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御手段と、受け付けられた前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御手段と、前記注文内容に示される前記対象商品と前記状態情報受付手段により受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力手段と、前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付手段と、前記確認通知受付手段により前記確認通知が受け付けられた場合、前記注文内容記憶手段に記憶された前記確認状態を完了状態に更新する更新手段と、前記注文内容記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力手段と、を備えることを特徴とする。
【０００８】
この発明によれば、対象商品の注文内容が受け付けられた後に、留意情報の提供及び確認が行われる。また、留意情報が確認されたか否かを示す確認状態が出力されるので、例えば販売者は、留意情報が確認されたことを条件として、商品の販売成立のための処理を行うことができる。そのため、購入者が情報提供の対象となる商品の注文内容を送信する場合であっても、情報提供の対象とはされていない商品の場合と同様に分かりやすい手順としつつ、商品の販売（契約）成立までに個別の情報提供が可能となる。
【０００９】
請求項２に記載の発明は、請求項１に記載の情報システムにおいて、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、該注文内容に示される商品の購入代金の支払いのための処理状態と、該商品の発送状態とを状態記憶手段に記憶させる状態記憶制御手段と、前記注文内容に示される商品が前記対象商品ではない場合、前記処理状態が完了状態に更新されていることを条件に、前記発送状態を発送可能状態に更新する第１発送状態更新手段と、前記注文内容に示される商品が前記対象商品である場合、前記処理状態と前記確認状態との何れもが完了状態に更新されていることを条件に、前記発送状態を発送可能状態に更新する第２発送状態更新手段と、前記状態記憶手段に記憶された前記発送状態を出力する発送状態出力手段と、を更に備えることを特徴とする。
【００１０】
この発明によれば、注文内容に示される商品が対象商品ではない場合、購入代金の支払いのための処理が完了した後に商品を発送することができる。また、注文内容に示される商品が対象商品である場合、購入者が留意情報を確認し、且つ購入代金の支払いのための処理が完了した後に商品を発送することができる。そのため、販売者が誤って商品を発送することを防止することができる。
【００１１】
請求項３に記載の発明は、請求項１又は２に記載の情報システムにおいて、前記注文内容に示される商品が前記対象商品である場合、前記留意情報へのリンク情報を提示させるリンク情報提示制御手段を更に備え、前記留意情報出力手段は、前記リンク情報が選択された場合、前記留意情報と該留意情報を理解したと確認したことを示すために操作可能な確認要素とを提示させ、前記確認通知受付手段は、前記確認要素が操作されることに基づく前記確認通知を取得することを特徴とする。
【００１２】
この発明によれば、購入者による留意情報の確認を容易にすることができる。
【００１３】
請求項４に記載の発明は、請求項１乃至３の何れか１項に記載の情報システムにおいて、前記確認状態出力手段は、前記注文内容記憶手段に記憶された前記注文内容について販売者向けの情報を提示させ、前記注文内容に示される商品が前記対象商品である場合、該注文内容に関連付けられた前記確認状態に応じて外観が変化する画像を前記販売者向けの情報とともに提示させることを特徴とする。
【００１４】
この発明によれば、画像により、販売者は、購入者が留意情報を確認したか否かを容易に認識することができる。
【００１５】
請求項５に記載の発明は、請求項１乃至４の何れか１項に記載の情報システムにおいて、前記注文内容記憶手段に記憶された前記注文内容を販売者向けに出力する注文内容出力手段であって、前記注文内容に示される商品が前記対象商品であり、且つ前記注文内容に関連付けられた前記確認状態が未完了状態である場合、前記注文内容のうち商品の送付先の住所を出力しない注文内容出力手段を更に備えることを特徴とする。
【００１６】
この発明によれば、確認状態が未完了状態である場合、商品の送付先の住所が販売者に提示されない。そのため、購入者が留意情報を確認していないのにもかかわらず、販売者が商品を発送することを防止することができる。
【００１７】
請求項６に記載の発明は、請求項１乃至５の何れか１項に記載の情報システムにおいて、前記注文内容記憶手段に記憶された前記注文内容に示される商品の配送伝票情報の入力を受け付ける配送伝票受付手段であって、前記商品が前記対象商品であり且つ前記注文内容に関連付けられた前記確認状態が未完了状態である場合、前記配送伝票情報を受け付けない配送伝票受付手段を更に備えることを特徴とする。
【００１８】
この発明によれば、確認状態が未完了状態である場合、配送伝票情報の入力が受け付けられない。そのため、購入者が留意情報を確認していないのにもかかわらず、販売者が配送伝票を使用して商品を発送することを防止することができる。
【００１９】
請求項７に記載の発明は、請求項１乃至６の何れか１項に記載の情報システムにおいて、前記留意情報が生成された場合、該留意情報の確認が必要であることを前記購入者に通知する通知情報を出力する通知情報出力手段と、前記通知情報出力手段により前記通知情報が出力されてから設定期間内に前記確認通知受付手段により前記確認通知が受け付けられなかった場合、前記注文内容の受け付けをキャンセルするキャンセル手段を更に備えることを特徴とする。
【００２０】
この発明によれば、一定期間が経過しても購入者が留意情報を確認しない場合、情報システムは、注文内容の受け付けをキャンセルする。そのため、留意情報が確認されないために発送もできず、他の購入者に販売することもできない商品の数を減らすことができる。
【００２１】
請求項８に記載の発明は、請求項７に記載の情報システムにおいて、前記状態情報受付手段により受け付けられた前記状態情報を前記注文内容記憶手段に記憶される前記注文内容に関連付けて状態情報記憶手段に記憶させる状態情報記憶制御手段と、受け付けがキャンセルされた注文内容の少なくとも一部と、該注文内容に示される商品の再注文のために操作可能な再注文要素とを提示させるキャンセル注文提示制御手段と、を更に備え、前記状態情報受付手段は、前記再注文要素が操作されることに基づいて前記再注文のための注文内容が受け付けられる場合、前記受け付けがキャンセルされた注文内容に関連付けられた状態情報を、前記再注文のための注文内容に関連付けられる状態情報として取得することを特徴とする。
【００２２】
この発明によれば、注文内容の受け付けがキャンセルされた後に、同じ商品を購入者が再注文する場合、情報システムは、キャンセルされた注文内容に関連付けられた状態情報を、再注文における注文内容と関連付けて記憶させる。そのため、再注文の際、購入者は状態情報を再入力する手間を省くことができる。
【００２３】
請求項９に記載の発明は、請求項８に記載の情報システムにおいて、前記受け付けがキャンセルされた注文内容に関連付けられた状態情報が変化する可能性がある情報である場合、該状態情報の有効日数を取得する有効日数取得手段と、前記受け付けがキャンセルされた注文内容が受け付けられてから前記再注文要素が操作されるまでの経過日数が、前記有効日数取得手段により取得された前記有効日数を超える場合、前記使用者の状態情報の再入力を前記購入者に要求する要求情報を提示させる要求情報提示制御手段と、を更に備え、前記状態情報受付手段は、前記購入者から再入力された状態情報を受け付けることを特徴とする。
【００２４】
この発明によれば、キャンセルされた注文内容に関連付けられた状態情報が、変化する可能性がある状態である場合、情報システムは、この状態情報に応じた有効日数と再注文要素が操作されるまでの経過日数とに基づいて、購入者に状態情報を再度入力させるか否かを制御する。そのため、状態情報を再入力する手間を省くことも可能としつつ、再入力が行われないことによる誤った状態情報が記憶されることを防止することができる。
【００２５】
請求項１０に記載の発明は、請求項７乃至９の何れか１項に記載の情報システムにおいて、前記購入者から受け付けられた注文内容が配送日の指定を含む場合、該配送日に商品を配達するための発送期限を取得する発送期限取得手段と、前記発送期限に基づいて、前記留意情報の確認期限を決定する確認期限決定手段と、を更に備え、前記キャンセル手段は、前記確認期限決定手段により決定された前記確認期限までに前記確認通知受付手段により前記確認通知が受け付けられなかった場合、前記注文内容の受け付けをキャンセルすることを特徴とする。
【００２６】
この発明によれば、情報システムは、購入者が指定した配送日時に商品を配送可能な時期まで注文内容の受け付けをキャンセルせずに、確認者による留意情報の確認を待つことができる。従って、留意情報の確認期間を適切に設定することができる。
【００２７】
請求項１１に記載の発明は、請求項１乃至１０の何れか１項に記載の情報システムにおいて、生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後、前記確認通知受付手段により前記確認通知が受け付けられるまでに、前記留意情報の確認を前記購入者に促すリマインド情報であって所定時間間隔ごとに出力されるリマインド情報が出力された回数を取得する回数取得手段と、前記通知情報が出力された後に前記確認通知が受け付けられていない注文内容のための前記リマインド情報を出力する時間間隔を、前記回数取得手段により取得された前記回数に応じて決定する時間間隔決定手段と、を更に備えることを特徴とする。
【００２８】
この発明によれば、情報システムは、過去に購入者が留意情報を確認するまでの間にリマインド情報が出力された回数に応じて、リマインド情報を出力する時間間隔を決定する。そのため、リマインド情報を効率的に出力することができる。
【００２９】
請求項１２に記載の発明は、請求項１乃至１１の何れか１項に記載の情報システムにおいて、前記確認通知受付手段により前記確認通知が受け付けられた時間を取得する時間取得手段と、生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後に前記確認通知が受け付けられていない場合における前記留意情報の確認を前記購入者に促すリマインド情報を出力する時間を、前記時間取得手段により取得された前記時間に応じて決定する時間決定手段と、を更に備えることを特徴とする。
【００３０】
この発明によれば、情報システムは、過去に購入者が留意情報を確認した時間に応じて、リマインド情報を出力する時間を決定する。そのため、購入者が留意情報を確認する蓋然性を高めることができる。
【００３１】
請求項１３に記載の発明は、請求項１乃至１２の何れか１項に記載の情報システムにおいて、前記購入者から受け付けられた前記注文内容に示される商品が前記対象商品である場合、該商品についてこれまでに受け付けられている１以上の注文内容のうち発送が完了していない注文内容に応じた前記商品の数を取得する商品数取得手段と、生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後に前記確認通知が受け付けられていない場合における前記留意情報の確認を前記購入者に促すリマインド情報を出力する頻度を決定する頻度決定手段であって、前記商品数取得手段により取得された前記数が多いほど前記頻度を高くする頻度決定手段と、を更に備えることを特徴とする。
【００３２】
この発明によれば、情報システムは、或る対象商品について、未だ発送されていない商品数が多いほど、リマインド情報を出力する頻度を高くする。そのため、購入者が留意情報を確認しないために販売者が発送することができない商品の数を減らすことができる。
【００３３】
請求項１４に記載の発明は、請求項１乃至１３の何れか１項に記載の情報システムにおいて、前記購入者から何れかの商品の注文内容が受け付けられた場合に該注文内容が受け付けられたことを示す受付情報を提示させる受付情報提示制御手段であって、前記購入者から前記対象商品について過去に受け付けられた注文内容に関連付けられた確認状態が未完了状態である場合、前記留意情報の確認を促す情報を前記受付情報とともに提示させる受付情報提示制御手段を更に備えることを特徴とする。
【００３４】
この発明によれば、指定商品について購入者が留意情報を確認していない場合、情報システムは、何らかの商品の注文内容が受け付けられた場合に、受け付けが完了したことを示す情報とともに、留意情報の確認を促す情報を提示させる。そのため、購入者にとって邪魔にならないタイミングで、留意情報を確認することを購入者に思い出させることができる。
【００３５】
請求項１５に記載の発明は、コンピュータにより実行される情報処理方法であって、購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付ステップと、前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御ステップと、前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御ステップと、前記注文内容に示される前記対象商品と前記状態情報受付ステップにより受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力ステップと、前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付ステップと、前記確認通知受付ステップにより前記確認通知が受け付けられた場合、前記注文内容記憶手段に記憶された前記確認状態を完了状態に更新する更新ステップと、前記注文内容記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力ステップと、を含むことを特徴とする。
【発明の効果】
【００３６】
本発明によれば、対象商品の注文内容が受け付けられた後に、留意情報の提供及び確認が行われる。また、留意情報が確認されたか否かを示す確認状態が出力されるので、例えば販売者は、留意情報が確認されたことを条件として、商品の販売成立のための処理を行うことができる。そのため、購入者が情報提供の対象となる商品の注文内容を送信する場合であっても、情報提供の対象とはされていない商品の場合と同様に分かりやすい手順としつつ、商品の販売（契約）成立までに個別の情報提供が可能となる。
【図面の簡単な説明】
【００３７】
【図１】一実施形態に係る情報処理システムＳ１の概要構成の一例を示す図である。
【図２】指定医薬品の購入に関する手順の概要を示すフローチャートである。
【図３】（ａ）は、一実施形態に係る電子商店街サーバ１の概要構成の一例を示すブロック図である。（ｂ）は、一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の機能ブロックの一例を示す図である。
【図４】（ａ）は、会員ＤＢ１２ａに登録される内容の一例を示す図である。（ｂ）は、店舗ＤＢ１２ｂに登録される内容の一例を示す図である。（ｃ）は、商品ＤＢ１２ｃに登録される内容の一例を示す図である。（ｄ）は、買い物かごＤＢ１２ｄに登録される内容の一例を示す図である。（ｅ）は、注文ＤＢ１２ｅに登録される内容の一例を示す図である。（ｆ）は、メッセージＤＢ１２ｆに登録される内容の一例を示す図である。
【図５】一実施形態に係る情報処理システムＳ１の処理の一例を示すシーケンス図である。
【図６】一実施形態に係る情報処理システムＳ１の処理の一例を示すシーケンス図である。
【図７】指定医薬品の商品ページの表示例を示す図である。
【図８】（ａ）は、受注一覧ページの表示例を示す図である。（ｂ）は、確認ステータスに応じた確認ステータスアイコンの外観の例を示す図である。
【図９】受注管理ページの表示例を示す図である。
【図１０】（ａ）は、メッセージ管理ページの表示例を示す図である。（ｂ）は、メッセージ入力ページの表示例を示す図である。
【図１１】注文履歴ページの表示例を示す図である。
【図１２】（ａ）は、メッセージ確認ページの表示例を示す図である。（ｂ）は、全ての留意事項に対するチェックボックス２６３をチェック済みに設定されたメッセージ確認ページの例である。
【図１３】（ａ）は、確認ステータスが確認完了に更新された後の受注一覧ページの表示例である。（ｂ）は、確認ステータスが確認完了に更新された後のメッセージ管理ページの表示例である。
【図１４】（ａ）は、確認ステータスが確認完了に更新されなかった場合の受注一覧ページの表示例である。（ｂ）は、確認ステータスが確認完了に更新されなかった場合のメッセージ管理ページの表示例である。
【図１５】（ａ）は、決済ステータスが処理完了に更新され、且つ確認ステータスが確認完了に更新された後の受注管理ページの表示例である。（ｂ）は、発送ステータスが発送待ちに更新された後の受注一覧ページの表示例である。
【図１６】一実施形態に係る電子商店街サーバ１のシステム制御部１４の注文内容登録処理の一例を示すフローチャートである。
【図１７】一実施形態に係る電子商店街サーバ１のシステム制御部１４の受注一覧送信処理の一例を示すフローチャートである。
【図１８】一実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。
【図１９】一実施形態に係る電子商店街サーバ１のシステム制御部１４の注文履歴送信処理の一例を示すフローチャートである。
【図２０】一実施形態に係る電子商店街サーバ１のシステム制御部１４の購入者メッセージ登録処理の一例を示すフローチャートである。
【図２１】一実施形態の変形例に係る電子商店街サーバ１のシステム制御部１４の発送ステータス制御処理の一例を示すフローチャートである。
【図２２】一実施形態に係る情報処理システムＳ２の概要構成の一例を示す図である。
【図２３】（ａ）は、一実施形態に係る店舗サーバ５の概要構成の一例を示すブロック図である。（ｂ）は、一実施形態に係る宿泊施設予約サーバ１のシステム制御部５４の機能ブロックの一例を示す図である。
【図２４】一実施形態に係る情報処理システムＳ２の、留意情報の提供に関する処理の一例を示すシーケンス図である。
【図２５】一実施形態に係る情報処理システムＳ２の、確認ステータス及び発送ステータスの更新に関する処理の一例を示すシーケンス図である。
【図２６】一実施形態に係る店舗サーバ５のシステム制御部５４の発送ステータス更新判定処理の一例を示すフローチャートである。
【図２７】（ａ）は、確認ステータスが確認完了である場合の受注管理ページの表示例を示す図である。（ｂ）は、確認ステータスが確認未完了である場合の受注管理ページの表示例を示す図である。
【図２８】一実施形態に係る電子商店街サーバ１のシステム制御部１４の受注管理ページ送信処理の一例を示すフローチャートである。
【図２９】一実施形態に係る情報処理システムＳ３の概要構成の一例を示す図である。
【図３０】（ａ）は、確認ステータスが確認完了である場合の受注管理ページの表示例を示す図である。（ｂ）は、確認ステータスが確認未完了である場合の受注管理ページの表示例を示す図である。
【図３１】一実施形態に係る電子商店街サーバ１のシステム制御部１４の受注管理ページ送信処理の一例を示すフローチャートである。
【図３２】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の機能ブロックの一例を示す図である。
【図３３】一実施形態に係る電子商店街サーバ１のシステム制御部１４の自動キャンセル処理の一例を示すフローチャートである。
【図３４】注文履歴ページの表示例を示す図である。
【図３５】再注文内容確認ページの表示例を示す図である。
【図３６】一実施形態に係る電子商店街サーバ１のシステム制御部１４の注文履歴送信処理の一例を示すフローチャートである。
【図３７】一実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文確認ページ送信処理の一例を示すフローチャートである。
【図３８】一実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文内容登録処理の一例を示すフローチャートである。
【図３９】再注文内容確認ページの表示例を示す図である。
【図４０】使用者状態質問ＤＢ１２ｇに登録される内容の一例を示す図である。
【図４１】一実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文確認ページ送信処理の一例を示すフローチャートである。
【図４２】一実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文内容登録処理の一例を示すフローチャートである。
【図４３】配送日数ＤＢ１２ｈに登録される内容の一例である。
【図４４】一実施形態に係る電子商店街サーバ１のシステム制御部１４の自動キャンセル処理の一例を示すフローチャートである。
【図４５】一実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の機能ブロックの一例を示す図である。
【図４６】一実施形態に係る電子商店街サーバ１のシステム制御部１４のリマインド時間間隔決定処理の一例を示すフローチャートである。
【図４７】一実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。
【図４８】一実施形態に係る電子商店街サーバ１のシステム制御部１４のリマインドメール送信処理の一例を示すフローチャートである。
【図４９】一実施形態に係る電子商店街サーバ１のシステム制御部１４のリマインド時間間隔決定処理の一例を示すフローチャートである。
【図５０】一実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。
【図５１】一実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。
【図５２】注文内容受付完了ページの表示例を示す図である。
【図５３】一実施形態に係る電子商店街サーバ１のシステム制御部１４の注文内容受付完了送信処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００３８】
以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、情報処理システムに対して本発明を適用した場合の実施形態である。
【００３９】
［１．第１実施形態］
［１−１．情報処理システムの構成及び機能概要］
先ず、本実施形態に係る情報処理システムＳ１の構成及び機能概要について、図１及び図２を用いて説明する。図１は、本実施形態に係る情報処理システムＳ１の概要構成の一例を示す図である。
【００４０】
図１に示すように、情報処理システムＳ１は、電子商店街サーバ１と、複数の店舗端末２と、複数の購入者端末３と、を含んで構成されている。そして、電子商店街サーバ１と各店舗端末２及び各購入者端末３とは、ネットワークＮＷを介して、例えば、通信プロトコルにＴＣＰ／ＩＰ等を用いて相互にデータの送受信が可能になっている。なお、ネットワークＮＷは、例えば、インターネット、専用通信回線（例えば、ＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、及びゲートウェイ等により構築されている。
【００４１】
電子商店街サーバ１は、商品の購入が可能な電子商店街に関する各種処理を実行するサーバ装置である。電子商店街サーバ１は、本発明における情報システムの一例である。電子商店街を利用する購入者は、電子商店街において所望の店舗から所望の商品を購入することができる。電子商店街サーバ１は、店舗端末２や購入者端末３からのリクエストに応じて、例えば電子商店街のウェブページを送信したり、商品の検索や注文等に関する処理を行ったりする。
【００４２】
店舗端末２は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末２は、従業員等からの操作に基づいて電子商店街サーバ１等のサーバ装置にアクセスする。これにより、店舗端末２は、サーバ装置からウェブページを受信して表示する。店舗端末２には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。従業員は、店舗端末２を利用することにより、例えば、販売する商品の情報を電子商店街に登録したり、商品の注文内容を確認したりする。店舗は、商品を販売する販売者の一例である。
【００４３】
購入者端末３は、電子商店街から商品を購入する購入者の端末装置である。購入者端末３は、購入者からの操作に基づいて電子商店街サーバ１にアクセスすることにより、電子商店街サーバ１からウェブページを受信して表示する。購入者端末３には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。購入者端末３としては、例えば、パーソナルコンピュータ、ＰＤＡ（Personal Digital Assistant）、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
【００４４】
電子商店街において商品を購入するために、購入者は電子商店街サーバ１に所望の条件を満たす商品を検索させる。検索された商品の中から購入者が所望の商品を選択すると、電子商店街サーバ１は購入者端末３へ商品ページを送信する。商品ページは、例えば購入者により選択された商品に関する詳細な情報を表示するウェブページである。商品ページにおいて、購入者は商品の個数を選択する。また、商品ページにて購入者が特定の項目について選択を行う必要がある商品が存在する。そのような項目として、例えば商品の色、サイズ等がある。商品ページにおいて、購入者は、選択した商品を買い物かごに入れる。買い物かごは、注文しようとする対象として購入者が選択した商品が入れられる仮想的な入れ物である。買い物かごに入れられた商品を注文する場合、購入者は注文内容を入力する。注文内容として、例えば、購入者による購入の意思、注文する商品、商品の個数、購入代金の支払い方法、配送方法、配送日時、商品の送付先の住所等がある。注文する商品及び商品の個数については既に選択されている。注文内容に示される商品を、注文商品と称する。購入者が注文内容を確定すると、電子商店街サーバ１により注文内容が受け付けられる。店舗は、注文商品の購入代金の支払いのための処理が完了すると、注文商品を購入者へ発送する。
【００４５】
電子商店街においては様々な種類の商品が販売されている。販売される商品の中には、使用の際の安全性を確保するために、購入者に対して店舗が情報提供を行うことが好ましい商品がある。日本においては、そのような商品として例えば第１類医薬品及び第２類医薬品がある。第１類医薬品及び第２類医薬品は、厚生労働大臣が指定する。これらの医薬品を、指定医薬品と称する。指定医薬品は、本発明における対象商品の例である。購入者が購入しようとする指定医薬品を使用する人を、使用者という。指定商品の購入者と使用者とは同一人物である場合もあるが、両者が異なる場合もある。例えば、使用者の代理で購入者が指定商品を購入する場合がある。使用者による指定医薬品の使用の安全性を確保するため、電子商店街サーバ１は、指定医薬品を購入しようとする購入者に対して、店舗から使用者の状態に応じた個別の情報提供を行うための処理、及び店舗から提供された情報を理解したことを購入者が確認したことを条件として、指定医薬品の販売を成立させる（売買契約を成立させる）ための処理を行う。使用者の状態を示す情報を使用者状態情報と称する。使用者状態情報は、本発明における状態情報の一例である。使用者状態情報として、例えば使用者の性別、年齢、症状、副作用歴の有無、副作用の内容、持病の有無、持病の内容、医療機関の受診の有無、受診の内容、妊娠の有無、授乳中であるか否か、その他気になる事項等があってもよい。使用者の状態に応じて店舗から購入者に提供される情報を、留意情報と称する。留意情報として、例えば用法、用量、使用上の留意点、使用後に注意すべき事項、質問の有無の問い合わせ等があってもよい。なお、指定医薬品は、第１類医薬品及び第２類医薬品に加えて、例えば第３類医薬品を含んでもよい。また、指定医薬品は第１類医薬品のみであってもよい。また、指定医薬品と異なる商品の中で特定の商品が、上述した情報提供の対象となる商品であってもよい。このような商品として、例えば食物アレルギーとの関連性がある食材や栄養食品等がある。本実施形態においては、留意情報の提供が必要とされる商品が第１類医薬品及び第２類医薬品であるものとして説明する。留意情報の提供が不要な商品を、一般商品と称する。
【００４６】
次に、指定医薬品の購入に関する手順の概要を説明する。図２は、指定医薬品の購入に関する手順の概要を示すフローチャートである。先ず、電子商店街サーバ１は、購入者が注文する指定医薬品を使用する使用者の使用者状態情報を受け付ける（ステップＳ１）。入力すべき使用者状態情報は、例えば店舗により指定商品ごとに予め定義されていてもよい。購入者は、例えば指定医薬品の商品ページにおいて使用者状態情報を入力することができる。使用者状態情報の入力後、購入者が指定医薬品を買い物かごに入れるための操作を行うと、購入者端末３は使用者状態情報を電子商店街サーバ１へ送信する。なお、電子商店街サーバ１は、例えば指定医薬品を買い物かごに入れるための操作を行ったときに、使用者状態情報を入力するためのウェブページを購入者端末３へ送信してもよく、このウェブページにおいて入力された使用者状態情報を受信してもよい。
【００４７】
その後、購入者は、買い物かごに入れられた商品について注文内容を入力する。購入者端末３は、入力された注文内容を電子商店街サーバ１へ送信し、電子商店街サーバ１は注文内容を受け付ける（ステップＳ２）。電子商店街サーバ１は、注文内容と使用者状態情報とを関連付けて、電子商店街サーバ１が備える記憶手段に記憶させる。注文商品が指定医薬品である場合、電子商店街サーバ１は、注文内容に関連付けて更に確認ステータスを記憶手段に記憶させる。確認ステータスは、店舗からの留意情報を理解したことを購入者が確認している状態であるか否かを示す。確認ステータスは、大別して確認未完了と確認完了との何れかに設定される。注文内容の受け付け時の確認ステータスは確認未完了である。以降、電子商店街サーバ１は、確認ステータスを店舗側に提供することが可能である（ステップＳ３）。このとき、電子商店街サーバ１は、注文商品の販売成立のための処理が可能であるかを判定可能に確認ステータスを提供する。電子商店街サーバ１は、例えば受注に関する情報を表示するウェブページを店舗端末２へ送信するとき、このウェブページに確認ステータスを示す情報を含める。本実施形態においては、例えば注文商品の発送が、注文商品の販売成立のための処理と規定される。すなわち、本実施形態においては、確認ステータスは、注文商品の発送が可能であるかを判定するための情報である。なお、例えば店舗が購入者宛てに注文内容を確認するための電子メールを送信することが、注文商品の販売成立のための処理と規定されてもよい。
【００４８】
指定医薬品についての注文内容を受け付けた後、電子商店街サーバ１は、使用者状態情報を店舗端末２へ提供する（ステップＳ４）。店舗端末２は、使用者状態情報に応じた留意情報を生成する（ステップＳ５）。例えば、店舗に所属する薬剤師が、使用者状態情報に応じた留意情報を入力する。店舗端末２は留意情報を電子商店街サーバ１へ送信し、電子商店街サーバ１は留意情報を購入者端末３へ提供する（ステップＳ６）。このとき、電子商店街サーバ１は、留意情報を確認可能に留意情報を提供する。購入者は、店舗から提供された留意情報に対して回答を入力する。すると、購入者端末３は、入力された回答を電子商店街サーバ１に送信する。購入者が留意情報を理解した旨を回答するための操作を行うと、電子商店街サーバ１は購入者端末３から送信された回答を、留意情報を理解したことを購入者が確認したことを示す通知として受け付ける（ステップＳ７）。この通知を受け付けた電子商店街サーバ１は、確認ステータスを確認完了に更新する（ステップＳ８）。
【００４９】
確認ステータスの提供を受ける店舗は、確認ステータスに基づいて、注文商品の販売成立のための処理が可能であるか否かを判定する。本発実施形態においては、店舗は、注文商品の発送が可能であるか否かを判定する。例えば、確認ステータスのほかに、注文商品の発送が可能であるか否かを判定するための情報として、決済ステータスがあってもよい。決済ステータスは、本発明における処理状態の一例である。決済ステータスは、注文商品の購入代金の支払いのための処理が完了している状態であるか否かを示す。決済ステータスは、処理未完了と処理完了との何れかに設定される。確認ステータスが確認未完了である場合、又は決済ステータスが処理未完了である場合、店舗は注文商品の発送が可能ではないと判定する。確認ステータスが確認完了であり、且つ決済ステータスが処理完了である場合、店舗は注文商品の発送が可能であると判定する。そして、店舗は注文商品を発送する（ステップＳ９）。なお、店舗が購入者宛てに注文内容を確認するための電子メールを送信することが、注文商品の販売成立のための処理であると規定されている場合、例えば、確認ステータスが確認完了であれば、店舗は、決済ステータスの如何に関わらず、販売成立のための処理が可能であると判定してもよい。
【００５０】
一般商品と指定医薬品とでは、購入者からの注文内容の送信までの手順は基本的に同様である。指定医薬品を注文するための使用者状態情報についても、購入者は、商品の色やサイズ等の項目と同様の感覚で入力可能である。そのため、購入者にとって手順が分かりやすい。なお、例えば注文内容が送信された後に使用者状態情報を購入者に入力させるように電子商店街サーバ１が制御を行ってもよい。また、電子商店街サーバ１は、注文内容が受け付けられた後、購入者が留意事項を確認したか否かを示す確認ステータスを、販売成立のための処理が可能であるかを判定可能に提供する。そのため、店舗が販売成立のための処理を誤って行うことを抑制することができる。
【００５１】
［１−２．電子商店街サーバの構成］
次に、電子商店街サーバ１の構成について、図３及び図４を用いて説明する。図３（ａ）は、本実施形態に係る電子商店街サーバ１の概要構成の一例を示すブロック図である。図３（ａ）に示すように、電子商店街サーバ１は、通信部１１と、記憶部１２と、入出力インターフェース１３と、システム制御部１４と、を備えている。そして、システム制御部１４と入出力インターフェース１３とは、システムバス１５を介して接続されている。
【００５２】
通信部１１は、ネットワークＮＷに接続して、店舗端末２や購入者端末３等との通信状態を制御するようになっている。
【００５３】
記憶部１２は、例えば、ハードディスクドライブ等により構成されている。記憶部１２は、本発明における注文内容記憶手段、確認状態記憶手段、状態記憶手段、及び状態情報記憶手段の一例である。例えば、注文内容記憶手段、確認状態記憶手段、状態記憶手段、及び状態情報記憶手段のうち少なくとも２つの記憶手段が同一の記憶装置であってもよいし、これらの記憶手段が互いに異なる記憶装置であってもよい。この記憶部１２には、会員ＤＢ１２ａ、店舗ＤＢ１２ｂ、商品ＤＢ１２ｃ、買い物かごＤＢ１２ｄ、注文ＤＢ１２ｅ、メッセージＤＢ１２ｆ等のデータベースが構築されている。「ＤＢ」は、データベースの略語である。
【００５４】
図４（ａ）は、会員ＤＢ１２ａに登録される内容の一例を示す図である。会員ＤＢ１２ａには、電子商店街に会員登録している購入者に関する会員情報が登録される。具体的に、会員ＤＢ１２ａには、ユーザＩＤ、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、電子メールアドレス、クレジットカード情報等の購入者の属性が、購入者ごとに対応付けて登録される。
【００５５】
図４（ｂ）は、店舗ＤＢ１２ｂに登録される内容の一例を示す図である。店舗ＤＢ１２ｂには、電子商店街で商品を販売する店舗に関する店舗情報が登録される。具体的に、店舗ＤＢ１２ｂには、店舗ＩＤ、店舗の名称、郵便番号、住所、電話番号、ＦＡＸ番号、電子メールアドレス等の店舗の属性が、店舗ごとに対応付けて登録される。店舗ＩＤは、店舗の識別情報である。
【００５６】
図４（ｃ）は、商品ＤＢ１２ｃに登録される内容の一例を示す図である。商品ＤＢ１２ｃには、電子商店街で販売されている商品に関する商品情報が登録される。商品情報は、店舗により登録される情報を含む。具体的に、商品ＤＢ１２ｃには、店舗ＩＤ、商品ＩＤ、商品コード、ジャンルＩＤ、商品名、商品画像のＵＲＬ、商品説明、価格、在庫数及び状態質問情報等が、店舗が販売する商品ごとに対応付けて登録される。店舗ＩＤは、商品の販売元の店舗を示す。商品ＩＤは、店舗が、販売する商品を管理するための商品の識別情報である。商品コードは、商品を識別するコード番号である。複数の店舗で同一の商品が販売される場合、同一の商品コードがそれぞれの商品に対して付与される。商品コードとしては、例えば、ＪＡＮ（Japanese Article Number Code）コードがある。ジャンルＩＤは、様々な商品ジャンルの中で商品が属するジャンルを識別するための識別情報である。ジャンルＩＤの中には、第１類医薬品を示すジャンルＩＤと、第２類医薬品を示すジャンルＩＤとが存在する。システム制御部１４は、ジャンルＩＤに基づいて、商品が指定医薬品であるか否かを識別することができる。状態質問情報は、ジャンルＩＤが指定医薬品を示す場合に登録される。状態質問情報は、指定医薬品の使用者の状態を質問するための情報である。例えば、状態質問情報は、質問ごとに、質問内容を示すテキストと、質問に対する回答の選択肢を示すテキストを含んでもよい。
【００５７】
図４（ｄ）は、買い物かごＤＢ１２ｄに登録される内容の一例を示す図である。買い物かごＤＢ１２ｄには、買い物かごに入れられている商品に関する買い物かご情報が登録される。具体的に、買い物かごＤＢ１２ｄには、買い物かごＩＤ、登録日時、ユーザＩＤ、店舗ＩＤ、商品ＩＤ、商品の個数、使用者状態情報等が、買い物かごに入れられている商品ごとに対応付けて登録される。買い物かごＩＤは、買い物かご情報の識別情報である。登録日時は、商品が買い物かごに入れられた日時を示す。ユーザＩＤは、商品を買い物かごに入れた購入者を示す。店舗ＩＤ及び商品ＩＤの組み合わせは、買い物かごに入れられた商品を示す。買い物かごに入れられた商品が指定医薬品である場合に買い物かごＤＢ１２ｄに使用者状態情報が登録される。買い物かごＤＢ１２ｄに登録される使用者状態情報は、買い物かごに入れられた商品を使用する使用者の状態を示す。
【００５８】
図４（ｅ）は、注文ＤＢ１２ｅに登録される内容の一例を示す図である。注文ＤＢ１２ｅには、商品の注文に関する注文情報が登録される。注文情報は、店舗による受注管理のための情報として用いられるとともに、購入者による注文履歴の情報としても用いられる。注文履歴には、注文内容が受け付けられた履歴である。注文履歴は、例えば購入履歴と表記されてもよい。注文ＤＢ１２ｅには、具体的に注文番号、受付日時、ユーザＩＤ、店舗ＩＤ、商品ＩＤ、商品の個数、決済方法、送付先情報、配送日時指定フラグ、指定配送日時、キャンセルフラグ、商品区分、使用者状態情報、決済ステータス、確認ステータス、発送ステータス等が、電子商店街サーバ１が購入者からの注文内容を受け付けるごとに対応付けて登録される。注文番号は、注文の識別番号である。受付日時は、注文内容が受け付けられた日時を示す。
【００５９】
ユーザＩＤ、店舗ＩＤ、商品ＩＤ、商品の個数、決済方法、送付先情報、配送日時指定フラグ、及び指定配送日時は、注文内容を示す。ユーザＩＤは、商品を注文する購入者を示す。店舗ＩＤは注文先の店舗を示す。店舗ＩＤ及び商品ＩＤの組み合わせは注文商品を示す。決済方法は、商品を購入代金の支払い方法を示す。決済方法として、例えば、クレジットカード決済、銀行振込、コンビニエンスストアでの支払い、代金引換等がある。送付先情報は、商品の送付先の郵便番号、住所、氏名等を含む。配送日時指定フラグは、購入者が商品の配送日又は配送日時を指定したか否かを示す。指定配送日時は、配送日時指定フラグがＴＲＵＥに設定されているときに登録される。指定配送日時は、指定された配送日又は配送日時を示す。キャンセルフラグは注文内容の受け付けがキャンセルされているか否かを示す。商品区分は、注文商品が指定医薬品であるか又は留意情報の提供が不要な一般商品であるかを示す。商品区分が指定医薬品である場合に注文ＤＢ１２ｅに使用者状態情報が登録される。注文ＤＢ１２ｅに登録される使用者状態情報は、注文商品を使用する使用者の状態を示す。
【００６０】
決済ステータスは、注文商品の購入代金の支払いのための処理の状態を示す。決済ステータスは、例えば処理未完了と処理完了の何れかに設定される。処理未完了は、購入代金の支払いのための処理が完了していないことを示す。処理完了は、購入代金の支払いのための処理が完了していることを示す。例えば、電子商店街サーバ１又は店舗の従業員等からの操作に基づいて、決済ステータスが処理完了に更新されてもよい。例えば、決済方法がクレジットカード決済である場合、例えば電子商店街サーバ１がクレジットカードを利用した購入代金支払いのための承認処理を実行し、クレジットカードの利用の承認を得た場合、電子商店街サーバ１は決済ステータスを処理完了に更新してもよい。決済方法が銀行振込又はコンビニエンスストアでの支払いである場合、例えば店舗は購入者からの入金を確認すると、店舗端末２を操作することにより、電子商店街サーバ１に決済ステータスを処理完了に更新させてもよい。
【００６１】
確認ステータスは、商品区分が指定医薬品である場合に注文ＤＢ１２ｅに登録される。確認ステータスは、大別して確認未完了と確認完了の何れかに設定される。確認未完了として、例えば店舗送信前、購入者回答前、回答後継続中が存在してもよい。店舗送信前は、店舗が留意情報を送信する前の状態であることを示す。購入者回答前は、店舗が留意情報を送信した後、留意情報に対して購入者が未だ回答していない状態を示す。回答後継続中は、留意情報に対して購入者が一度は回答しているものの、留意情報の少なくとも一部の項目について購入者からの確認が得られていない状態を示す。
【００６２】
発送ステータスは、注文商品の発送の状態を示す。発送ステータスは、例えば発送不可、発送待ち、及び発送済み等の何れかに設定されてもよい。発送不可は、注文商品を発送することができない状態を示す。発送待ちは、注文商品を発送することができる状態であって、注文商品が未だ発送されていない状態を示す。発送済みは、注文商品が発送されていることを示す。例えば店舗の従業員からの操作に基づいて、発送ステータスが更新されてもよい。
【００６３】
図４（ｆ）は、メッセージＤＢ１２ｆに登録される内容の一例を示す図である。メッセージＤＢ１２ｆには、注文商品が指定医薬品である場合において、購入者と店舗との間でやりとりされるメッセージが登録される。具体的に、メッセージＤＢ１２ｆには、注文番号、メッセージ番号、メッセージの件名、店舗メッセージ及び店舗送信日時等が、店舗端末２から電子商店街サーバ１へメッセージが送信されるごとに登録される。メッセージＤＢ１２ｆに登録される注文番号は、店舗からのメッセージに関連付けられた注文内容の注文番号を示す。メッセージ番号は、店舗から送信されたメッセージの順番を示す番号である。店舗メッセージは、店舗から送信されたメッセージである。メッセージ番号が１番である店舗メッセージは留意情報である。店舗送信日時は、店舗メッセージが送信された日時を示す。店舗から送信されたメッセージに対して購入者から回答のメッセージが送信された場合、メッセージＤＢ１２ｆには、更に購入者メッセージ及び購入者送信日時が登録される。購入者メッセージは、購入者から送信されたメッセージである。購入者送信日時は、購入者メッセージが送信された日時を示す。
【００６４】
次に、記憶部１２に記憶されるその他の情報について説明する。記憶部１２には、ウェブページを表示するための各種データ、例えばＨＴＭＬ（HyperText Markup Language）文書、ＸＭＬ（Extensible Markup Language）文書、画像データ、テキストデータ、電子文書等が記憶されている。例えば、記憶部１２には、各確認ステータスに対応した確認ステータスアイコンの画像データが記憶されている。また、記憶部１２には、各種の設定値が記憶されている。
【００６５】
また、記憶部１２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、電子商取引に関する各種の処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、光ディスク等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。また、電子商取引管理プログラム等は、プログラム製品であってもよい。
【００６６】
入出力インターフェース１３は、通信部１１及び記憶部１２とシステム制御部１４との間のインターフェース処理を行うようになっている。
【００６７】
システム制御部１４は、ＣＰＵ１４ａ、ＲＯＭ（Read Only Memory）１４ｂ、ＲＡＭ（Random Access Memory）１４ｃ等により構成されている。ＣＰＵ１４ａは、プロセッサの一例である。なお、本発明は、ＣＰＵと異なる様々なプロセッサに対しても適用可能である。記憶部１２、ＲＯＭ１４ｂ及びＲＡＭ１４ｃは、それぞれメモリの一例である。なお、本発明は、ハードディスク、ＲＯＭ及びＲＡＭと異なる様々なメモリに対しても適用可能である。
【００６８】
なお、電子商店街サーバ１が、複数のサーバ装置で構成されてもよい。例えば、電子商店街において商品の注文等の処理を行うサーバ装置、指定医薬品に関する情報提供のための処理を行うサーバ装置、店舗端末２や購入者端末３からのリクエストに応じてウェブページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにＬＡＮ等で接続されてもよい。
【００６９】
［１−３．システム制御部の機能概要］
次に、図３（ｂ）を用いて、システム制御部１４の機能概要について説明する。図３（ｂ）は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の機能ブロックの一例を示す図である。システム制御部１４は、ＣＰＵ１４ａが、電子商取引管理プログラム等のプログラムを読み出し実行することにより、図３（ｂ）に示すように、使用者状態情報受付部１４１、注文内容受付部１４２、メッセージ処理部１４３、ステータス制御部１４４、受注情報提供部１４５、注文履歴提供部１４６等として機能する。使用者状態情報受付部１４１は、本発明における状態情報受付手段の一例である。注文内容受付部１４２は、本発明における注文内容記憶制御手段、確認状態記憶制御手段及び状態記憶制御手段、状態情報記憶制御手段の一例である。メッセージ処理部１４３は、本発明における留意情報出力手段、通知情報出力手段の一例である。メッセージ処理部１４３は、本発明における確認通知受付手段の一例である。ステータス制御部１４４は、本発明における更新手段の一例である。受注情報提供部１４５は、本発明における確認状態出力手段の一例である。注文履歴提供部１４６は、本発明におけるリンク情報提示制御手段の一例である。
【００７０】
使用者状態情報受付部１４１は、購入者が注文する商品が指定医薬品である場合、その商品を使用する使用者の使用者状態情報を購入者から受け付ける。注文内容受付部１４２は、購入者端末２から電子商店街サーバ１へ商品の注文内容が送信された場合、この注文内容を受け付ける。そして、注文内容受付部１４２は、受け付けた注文内容、処理未完了に設定された決済ステータス、発送不可に設定された発送ステータス、使用者状態情報受付部１４１により受け付けられた使用者状態情報等を関連付けて、注文情報として注文ＤＢ１２ｅに記憶させる。受け付けられた注文内容に示される注文商品が指定医薬品である場合、注文内容受付部１４２は、注文内容に関連付けて、店舗送信前（確認未完了）に設定された確認ステータスを更に注文ＤＢ１２ｅに記憶させる。メッセージ処理部１４３は、店舗端末２から送信される店舗メッセージのメッセージＤＢ１２ｆへの登録及び店舗メッセージを購入者端末３へ提供するための処理を行う。また、メッセージ処理部１４３は、注文商品が指定医薬品である場合、注文商品と使用者状態情報とに応じて生成された留意情報を購入者が確認可能に出力する。また、メッセージ処理部１４３は、購入者端末３から送信される購入者メッセージのメッセージＤＢ１２ｆへの登録及び購入者メッセージを店舗端末２へ提供するための処理を行う。また、メッセージ処理部１４３は、メッセージ処理部１４３により出力された留意情報を理解したと購入者が確認したことを示す通知を購入者端末３から受け付ける。ステータス制御部１４４は、留意情報を理解したと購入者が確認したことを示す通知がメッセージ処理部１４３により受け付けられた場合、注文ＤＢ１２ｅに記憶された確認ステータスを確認完了に更新する。受注情報提供部１４５は、受注管理用のウェブページを店舗端末２に送信する。受注管理用のウェブページは、店舗に対して受け付けられた注文内容が示す注文を管理するためのウェブページである。また、受注情報提供部１４５は、注文ＤＢ１２ｅに記憶された確認ステータスを、注文ＤＢ１２ｅに記憶された注文内容に示される注文商品の販売成立のための処理が可能であるかを判定可能に出力する。注文履歴提供部１４６は、注文履歴ページを購入者端末３へ送信する。注文履歴ページは、購入者からの注文の履歴を示すウェブページである。各部の処理の詳細については後述する。
【００７１】
［１−４．情報処理システムの動作］
［１−４−１．システム全体の動作］
次に、情報処理システムＳ１の全体の動作について、図５乃至及び図１５を用いて説明する。図５及び図６は、本実施形態に係る情報処理システムＳ１の処理の一例を示すシーケンス図である。購入者は、例えば購入者端末３を操作することにより、電子商店街サーバ１のに商品を検索させる。購入者は、検索された商品の中から所望の商品、例えば或る指定医薬品を選択すると、図５に示すように、電子商店街サーバ１のシステム制御部１４は、購入者端末３からの要求に応じて、選択された指定医薬品の商品ページを購入者端末３へ送信する（ステップＳ１１）。
【００７２】
図７は、指定医薬品の商品ページの表示例を示す図である。図７に示すように、商品ページには、商品に関する情報、例えば商品名、価格、商品の画像、商品の説明等が表示される。また、商品ページには、買い物かご登録ボタン２０１、個数入力欄２０２が表示される。買い物かご登録ボタン２０１は、商品ページに示される商品を買い物かごに入れるためのボタンである。個数入力欄２０２は、注文する商品の数を入力するための入力フィールドである。指定医薬品の場合、商品ページには、更に状態質問情報が表示される。具体的に、使用者の状態に関する質問ごとに、質問内容２０３と選択メニュー２０４とが表示される。質問内容２０３は、質問内容を示すテキストである。選択メニュー２０４は、質問に対する回答を選択するためのプルダウンメニューである。商品ページのＨＴＭＬ文書を生成するとき、システム制御部１４は、商品ＤＢ１２ｃに登録された商品情報に基づいてＨＴＭＬ文書を生成する。商品情報に含まれるジャンルＩＤが指定医薬品を示す場合、システム制御部１４は、商品情報から状態質問情報を取得する。そして、システム制御部１４は、状態質問情報に基づいて、質問内容２０３と選択メニュー２０４を表示するためのデータを、商品ページのＨＴＭＬ文書に追加する。
【００７３】
購入者は、選択した指定医薬品を注文する場合、必要に応じて選択メニュー２０４を操作して使用者の状態を選択する（ステップＳ１２）。そして、購入者が買い物かご登録ボタン２０１を選択すると（ステップＳ１３）、購入者端末３は、買い物かご登録要求を電子商店街サーバ１へ送信する（ステップＳ１４）。買い物かご登録要求は、例えば、購入者のユーザＩＤ、買い物かごに入れられる商品に対応する店舗ＩＤ及び商品ＩＤ、商品の個数等を含む。また、買い物かご登録要求は、使用者状態情報を含む。例えば、使用者状態情報には、質問ごとに質問内容を示すテキストと購入者が選択した状態を示すテキストとが対応付けて登録されている。使用者状態情報受付部１４１は、買い物かご登録要求に含まれる店舗ＩＤ及び商品ＩＤに対応するジャンルＩＤを商品ＤＢ１２ｃから取得し、ジャンルＩＤが指定医薬品を示すか否かを判定する。ジャンルＩＤが指定医薬品を示していない場合、使用者状態情報受付部１４１は、受信した買い物かご登録要求に含まれる情報を買い物かご情報として買い物かごＤＢ１２ｄに登録する。一方、ジャンルＩＤが指定医薬品を示す場合、使用者状態情報受付部１４１は、注意喚起ページを購入者端末３へ送信する（ステップＳ１５）。注意喚起ページは、指定医薬品を注文する購入者に対して注意を促すためのウェブページである。購入者は、注意喚起ページに表示された注意事項に同意したことを示すためのボタンを選択すると、使用者状態情報受付部１４１は、購入者端末３からの要求に基づき、買い物かご登録要求に含まれる情報を買い物かご情報として買い物かごＤＢ１２ｄに登録する（ステップＳ１６）。こうして、使用者状態情報受付部１４１は使用者状態情報を受け付ける。
【００７４】
次いで、システム制御部１４は、買い物かごページを購入者端末３へ送信する（ステップＳ１７）。買い物かごページは、買い物かごに入れられている商品に関する情報を表示するウェブページである。買い物かごページにおいて、購入者は、買い物かごに入れられている指定医薬品を注文するためのボタンを選択すると、注文内容受付部１４２は、購入者端末３からの要求に基づき、注文内容入力ページを購入者端末３へ送信する（ステップＳ１８）。注文内容入力ページは、注文内容の少なくとも一部を入力するためのウェブページである。注文内容入力ページにおいて、購入者は、例えば決済方法、配送方法、配送日時の指定の有無、指定配送日時、送付先の住所等を入力する。そして、購入者が注文内容を確定するためのボタンを選択すると、購入者端末３は、入力された情報、及び購入者のユーザＩＤ、注文商品に対応する店舗ＩＤ及び商品ＩＤ、商品の個数等の注文内容の情報を電子商店街サーバ１へ送信する（ステップＳ１９）。注文内容受付部１４２は、受信した情報を含む注文情報を注文ＤＢ１２ｅに登録する（ステップＳ２０）。このとき、注文内容受付部１４２は、注文情報において、発送ステータスを発送不可に設定し、決済ステータスを処理未完了に設定する。また、注文内容受付部１４２は、キャンセルフラグをＦＡＬＳＥに設定する。注文商品が指定医薬品である場合、注文内容受付部１４２は、買い物かごＤＢ１２ｄから使用者状態情報を取得し、使用者状態情報と、店舗送信前（確認未完了）に設定された確認ステータスとを注文情報に含ませる。こうして注文内容を受け付けると、注文内容受付部１４２は、注文内容受付完了ページを購入者端末３へ送信する（ステップＳ２１）。注文内容受付完了ページは、注文内容が受け付けられたことを示すメッセージを表示するウェブページである。また、注文内容受付部１４２は、注文情報に含まれる店舗ＩＤが示す店舗宛てに、注文内容受付通知メールを送信する（ステップＳ２２）。注文内容受付通知メールは、店舗が販売する商品について注文内容が受け付けられたことを通知する電子メールである。注文内容受付通知メールの本文は、例えば、注文内容の少なくとも一部、注文番号、受付日時等を含む。また、注文内容受付通知メールの本文は、例えば使用者状態情報を含んでもよい。
【００７５】
注文内容受付通知メールを読んだ店舗の従業員は、受注情報を表示させるための操作を行う。すると、受注情報提供部１４５は、店舗端末２からの要求に応じて受注一覧ページを店舗端末２へ送信する（ステップＳ２３）。受注一覧ページは、店舗への注文の一覧を表示するウェブページである。受注一覧ページは、本発明における販売者向けの情報の一例である。図８（ａ）は、受注一覧ページの表示例を示す図である。図８（ａ）に示すように、受注一覧ページには、受け付けられた注文内容ごとに、例えば注文日時、注文番号、決済方法、決済ステータス、購入者への請求金額、発送ステータス、発送日等が表示される。また、指定医薬品の注文に関する情報が表示されている行には、確認ステータスアイコン２１１が表示される。確認ステータスアイコンは、確認ステータスを示す画像である。確認ステータスアイコンは、確認ステータスに応じてその外観が変化する。例えば、確認ステータスアイコンの色、形状、模様、大きさ等が変化してもよい。図８（ｂ）は、確認ステータスに応じた確認ステータスアイコンの外観の例を示す図である。図８（ｂ）の例では、確認ステータスに応じて確認ステータスアイコンの色が変化する。図８（ａ）に示される確認ステータスアイコン２１１は、確認ステータスが店舗送信前であることを示す。確認ステータスアイコン２１１が表示されることで、店舗は、注文商品が、留意情報の提供が必要な指定医薬品であるか否かを容易に認識することができるとともに、現在の確認ステータスを容易に認識することができる。確認ステータスアイコンは、確認状態に応じて外観が変化する画像の一例である。なお、このような画像はアイコンに限られるものではない。例えば、図形、記号などを示す画像が用いられてもよい。
【００７６】
従業員が何れかの注文番号を選択すると、店舗端末２からの要求に応じて、受注情報提供部１４５は、受注管理ページを店舗端末２へ送信する（ステップＳ２４）。受注管理ページは、選択された注文番号が示す注文を管理するためのウェブページである。図９は、受注管理ページの表示例を示す図である。図９に示すように、受注管理ページには、例えば注文ＤＢ１２ｅに登録された注文情報の内容等が表示される。例えば、受注管理ページには、注文番号、受付日時、購入者の氏名、商品ＩＤ、商品名、商品の個数、請求金額、送付先情報、決済方法、送付先情報、指定配送日時、決済ステータス、発送ステータス等が表示される。更に受注管理ページには、決済承認要求ボタン２２１、発送ステータス更新要求ボタン２２２等が表示される。決済承認要求ボタン２２１は、決済方法がクレジットカード決済である場合に、請求金額の決済の承認を電子商店街サーバ１に要求するためのボタンである。決済方法がクレジットカード決済ではない場合、決済承認要求ボタン２２１に代えて、決済ステータス更新要求ボタンが表示される。決済ステータス更新要求ボタンは、決済ステータスを処理完了に更新するためのボタンである。発送ステータス更新要求ボタン２２２は、発送ステータスを発送不可から発送待ちに更新するためのボタンである。注文商品が指定医薬品である場合、受注管理ページには、更に確認ステータス及び使用者状態が表示される。
【００７７】
例えば、購入者が決済承認要求ボタン２２１を選択すると、購入者端末３は、決済承認要求を電子商店街サーバ１へ送信する（ステップＳ２５）。これに応じて、ステータス制御部１４４は、購入者のクレジットカード情報に基づき、例えば信販会社のサーバ装置と連携して、クレジットカードを利用した支払いのための承認処理を実行する。そして、ステータス制御部１４４は、支払いが承認されたことを示す処理結果を取得した場合にのみ、決済ステータスを処理完了に更新する（ステップＳ２６）。なお、決済方法がクレジットカード決済ではない場合、従業員は、購入者による代金の支払いのための処理を確認した後、決済ステータス更新要求ボタンを選択する。すると、ステータス制御部１４４は、決済ステータスを処理完了に更新する。
【００７８】
その後、従業員の操作に基づいて、例えば受注情報提供部１４５は、図６に示すように受注一覧ページを店舗端末２へ送信する（ステップＳ３１）。受注一覧ページにおいて、従業員が例えば確認ステータスアイコン２１１を選択すると（ステップＳ３２）、店舗端末２からの要求に応じて、メッセージ処理部１４３は、メッセージ管理ページを店舗端末２へ送信する（ステップＳ３３）。メッセージ管理ページは、選択された確認ステータスアイコン２１１に対応する注文についての購入者メッセージを表示するためのウェブページである。図１０（ａ）は、メッセージ管理ページの表示例を示す図である。図１０（ａ）に示すように、メッセージ管理ページには、確認ステータスアイコン２３１、メッセージ一覧表示領域２３２、メッセージ表示領域２３３及び新規メッセージボタン２３４が表示される。メッセージ一覧表示領域２３２には、購入者メッセージの一覧が表示される。購入者メッセージは店舗メッセージに対する回答として送信される。従って、或る注文について店舗メッセージが一度も送信されていない場合、すなわち留意情報が生成されていない場合、購入者メッセージは通常登録されていない。メッセージ表示領域２３３は、メッセージ一覧表示領域２３２から選択された購入者メッセージが表示される。新規メッセージボタン２３４は、店舗メッセージを入力するためのボタンである。
【００７９】
従業員が新規メッセージボタン２３４を選択すると、店舗端末２からの要求に応じて、メッセージ処理部１４３はメッセージ入力ページを店舗端末２へ送信する（ステップＳ３４）。図１０（ｂ）は、メッセージ入力ページの表示例を示す図である。図１０（ｂ）に示すように、メッセージ入力ページには、確認ステータスアイコン２４１、件名入力欄２４２、メッセージ入力欄２４３、送信ボタン２４４が表示される。件名入力欄２４２は、店舗メッセージの件名を入力するための入力フィールドである。メッセージ入力欄２４３は、店舗メッセージを入力するための入力フィールドである。送信ボタンは、入力された件名及び店舗メッセージを送信するためのボタンである。
【００８０】
メッセージ入力ページにおいて、従業員は、件名及び店舗メッセージを入力する。或る注文について店舗メッセージを初めて入力するとき、従業員は、受注管理ページに表示される使用者状態情報に応じた留意情報を入力する（ステップＳ３５）。なお、メッセージ管理ページ又はメッセージ入力ページに使用者状態情報が表示されてもよい。留意情報を入力するとき、従業員は、留意事項ごとに、留意事項の内容を入力するとともに、例えば留意事項の内容の前に、チェックボックスを表す文字を入力する。この文字を、チェックボックス表示文字と称する。チェックボックス表示文字は、例えば四角形を表す文字であってもよい。チェックボックス表示文字は、購入者に対して留意情報が提示されるときに、留意情報を理解したことを確認する操作を行うためのチェックボックスを実際に表示させるためのデータである。また、購入者から質問等を受け付ける場合、従業員は、例えば「：」を入力する。従業員は留意情報を入力すると、送信ボタン２４４を選択する。すると、店舗端末２は、件名、及び店舗メッセージとしての留意情報を電子商店街サーバ１へ送信する（ステップＳ３６）。留意情報を受信すると、メッセージ処理部１４３は、留意情報をメッセージＤＢ１２ｆに登録するとともに、購入者宛てに店舗メッセージ登録通知メールを送信する（ステップＳ３７）。店舗メッセージ登録通知メールは、店舗メッセージが登録されたこと、及び留意情報の確認が必要であることを購入者に通知する電子メールである。店舗メッセージ登録通知メールは、本発明における通知情報の一例である。
【００８１】
店舗メッセージ登録通知メールを読んだ購入者は、購入者端末３を操作して注文履歴を要求する。すると、注文履歴提供部１４６は、注文履歴ページを購入者端末３へ送信する（ステップＳ３８）。これにより、注文履歴提供部１４６は、留意情報へのリンクを購入者端末３により提示させる。図１１は、注文履歴ページの表示例を示す図である。図１１に示すように、注文履歴ページには、これまでに購入者が送信した注文内容ごとに、注文内容表示領域２５１が表示される。注文内容表示領域２５１には、注文内容の少なくとも一部が表示される。例えば、注文内容表示領域２５１には、商品名、商品の購入先の店舗の名称、価格、商品の画像等が表示される。注文商品が指定医薬品である場合、注文内容表示領域２５１には、更に店舗メッセージ確認リンク２５２が表示される。店舗メッセージ確認リンク２５２は、本発明におけるリンク情報の一例である。店舗メッセージ確認リンク２５２は、対応する注文についてのメッセージ確認ページへのハイパーリンクである。メッセージ確認ページは、店舗メッセージを表示させるためのウェブページであり、店舗メッセージに対する回答を購入者メッセージとして入力するためのウェブページである。なお、例えばメッセージ処理部１４３は、店舗メッセージ登録通知メールにメッセージ確認ページへのＵＲＬを含ませてもよい。
【００８２】
購入者が店舗メッセージ確認リンク２５２を選択すると（ステップＳ３９）、購入者端末３は、メッセージ確認ページのＵＲＬを電子商店街サーバ１へ送信する（ステップＳ４０）。メッセージ処理部１４３は、受信したＵＲＬに基づいて注文番号を特定し、メッセージＤＢ１２ｆから注文番号に対応する件名、店舗メッセージ、店舗送信日時を取得する。次いで、メッセージ処理部１４３は、取得した情報に基づいてメッセージ確認ページを生成して購入者端末３へ送信する（ステップＳ４１）。店舗メッセージが複数登録されている場合、メッセージ処理部１４３は、例えば最新の店舗メッセージが表示されるように、メッセージ確認ページを生成してもよい。
【００８３】
図１２（ａ）は、メッセージ確認ページの表示例を示す図である。図１２（ａ）に示すように、メッセージ確認ページには、メッセージ一覧表示領域２６１、メッセージ表示領域２６２及びＯＫボタン２６５が表示される。メッセージ一覧表示領域２６１には、店舗メッセージの一覧が表示される。メッセージ表示領域２６２は、メッセージ一覧表示領域２６１から選択された店舗メッセージが表示される。ここで、店舗の従業員が入力したチェックボックス表示文字は、チェックボックス２６３に変化している。また、「：」の後に入力欄２６４が表示される。購入者は必要に応じて入力欄２６４に質問内容等を入力する。ＯＫボタン２６５は、購入者メッセージを送信するためのボタンである。チェックボックス２６３及びＯＫボタン２６５は、それぞれ本発明における確認要素の一例である。このように、メッセージ処理部１４３は、留意情報とともに、留意情報を理解したと確認したことを示すために捜査可能なチェックボックス２６３及びＯＫボタン２６５を提示させる。購入者は、理解した留意事項ごとにチェックボックス２６３を操作して、チェックボックス２６３をチェック済みに設定する（ステップＳ４２）。図１２（ｂ）は、全ての留意事項に対するチェックボックス２６３がチェック済みに設定されたメッセージ確認ページの例である。購入者がＯＫボタン２６５を選択すると、購入者端末３は入力された購入者メッセージを電子商店街サーバ１へ送信する（ステップＳ４３）。例えば、購入者メッセージは、メッセージ表示領域２６２に表示された店舗メッセージのテキストを含む。また、メッセージ表示領域２６２においてチェックボックス２６３が表示されていた位置に、チェックボックス表示文字が挿入される。このとき、チェックボックス２６３がチェック済みであるか未チェックであるかに応じて異なるチェックボックス表示文字が挿入される。また、入力欄２６４に質問内容等が入力されていた場合、購入者メッセージは、質問内容等を更に含む。
【００８４】
購入者メッセージを受信したステータス制御部１４４は、購入者メッセージに含まれる全てのチェックボックス表示文字がチェック済みを示す場合、確認ステータスを確認完了に更新する（ステップＳ４４）。全てのチェックボックス表示文字がチェック済みを示す購入者メッセージは、本発明における確認通知の一例である。次いで、メッセージ処理部１４３は、店舗宛てに購入者メッセージ登録通知メールを送信する（ステップＳ４５）。購入者メッセージ登録通知メールは、購入者メッセージが登録されたことを店舗に通知する電子メールである。購入者メッセージを読んだ従業員は、受注情報を表示させるための操作を行うと、受注情報提供部１４５は受注一覧ページを店舗端末２へ送信する（ステップＳ４６）。図１３（ａ）は、確認ステータスが確認完了に更新された後の受注一覧ページの表示例である。図１３（ａ）に示すように、確認ステータスアイコン２１１は確認完了を示している。また、決済ステータスは処理完了である。ここで、従業員が確認ステータスアイコン２１１を選択すると、メッセージ処理部１４３はメッセージ管理ページを店舗端末２へ送信する。図１３（ｂ）は、確認ステータスが確認完了に更新された後のメッセージ管理ページの表示例である。図１３（ｂ）に示すように、確認ステータスアイコン２３１は確認完了を示している。また、メッセージ一覧表示領域２３２に表示された件名の横に、確認完了を示すメッセージ２３５が表示される。また、メッセージ表示領域２３３に表示された購入者メッセージにおいて、全てのチェックボックス表示文字がチェック済みを示している。
【００８５】
なお、メッセージ確認ページにおいて、購入者が少なくとも１つのチェックボックスをチェック済みにしなかった場合、ステータス制御部１４４は、確認ステータスを確認完了に更新しない。この場合も、メッセージ処理部１４３は、購入者メッセージ登録通知メールを送信する。図１４（ａ）は、確認ステータスが確認完了に更新されなかった場合の受注一覧ページの表示例である。図１４（ａ）に示すように、確認ステータスアイコン２１１は回答後継続中を示している。図１４（ｂ）は、確認ステータスが確認完了に更新されなかった場合のメッセージ管理ページの表示例である。図１４（ｂ）に示すように、確認ステータスアイコン２３１は回答後継続中を示している。また、メッセージ一覧表示領域２３２に表示された件名の横に、回答後継続中を示すメッセージ２３６が表示される。また、メッセージ表示領域２３３に表示された購入者メッセージにおいて、少なくとも１つのチェック表示文字が未チェックを示している。このような場合、従業員は、メッセージ入力ページを店舗端末２に表示させて、購入者メッセージに対する店舗メッセージを入力する。このとき、従業員はチェックボックス表示文字を一文字以上入力する。例えば購入者が質問内容を入力していた場合、従業員は、質問内容に対する回答を入力してもよい。そして、従業員は、ほかに質問等がないことを確認するためのチェックボックス表示文字を入力する。その後の店舗と購入者との間のメッセージのやりとりのための処理は、基本的にステップＳ３１〜Ｓ４３と同様である。購入者により全てのチェックボックスがチェック済みに設定されるまで、メッセージのやりとりが繰り返される。
【００８６】
確認ステータスが確認完了に更新された後の受注一覧ページにおいて（図１３（ａ））、従業員が確認ステータスアイコン２１１に対応する注文番号を選択すると、受注情報提供部１４５は、受注管理ページを店舗端末２へ送信する（ステップＳ４７）。図１５（ａ）は、決済ステータスが処理完了に更新され、且つ確認ステータスが確認完了に更新された後の受注管理ページの表示例である。例えば、従業員は、受注管理ページ又は受注一覧ページにおいて、決済ステータスが処理完了であり且つ確認ステータスが確認完了であることを認識すると、発送ステータス更新要求ボタン２２２を選択する。すると、店舗端末２は、発送ステータス更新要求を電子商店街サーバ１へ送信する（ステップＳ４８）。発送ステータス更新要求を受信したステータス制御部１４４は、発送ステータスを発送待ちに変更し（ステップＳ４９）、完了応答を店舗端末２へ送信する。すると、店舗端末２は、受注管理画面における発送ステータスを発送待ちに変更する。図１５（ｂ）は、発送ステータスが発送待ちに更新された後の受注一覧ページの表示例である。受注管理ページ又は受注一覧ページにおいて発送ステータスが発送待ちであることを認識した従業員は、注文商品である指定医薬品を発送する。
【００８７】
図５及び図６の例では、先に購入代金の支払いのための処理が行われ、その後に留意情報の提供と確認が行われていた。しかしながら、先に留意情報の提供と確認が行われ、その後に購入代金の支払いのための処理が行われてもよい。また、これらの処理が並行して行われてもよい。
【００８８】
［１−４−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図１６乃至及び図２０を用いて説明する。図１６は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の注文内容登録処理の一例を示すフローチャートである。注文内容入力ページにおいて入力された注文内容等を受信したとき、システム制御部１４は注文内容登録処理を実行する（例えば図５ステップＳ２０、Ｓ２１）。図１６に示すように、注文内容受付部１４２は、受信した注文内容等を含む注文情報を生成する（ステップＳ５１）。このとき、注文内容受付部１４２は、新しい注文番号を生成するとともに、現在日時を受付日時として取得する。次いで、注文内容受付部１４２は、生成した注文情報の発送ステータスを発送不可に設定し、決済ステータスを処理未完了に設定する（ステップＳ５２）。次いで、注文内容受付部１４２は、注文商品が指定医薬品であるか否かを判定する（ステップＳ５３）。具体的に、注文内容受付部１４２は、注文情報に含まれる店舗ＩＤ及び商品ＩＤに対応するジャンルＩＤを商品ＤＢ１２ｃから取得する。そして、注文内容受付部１４２は、ジャンルＩＤが第１類医薬品及び第２類医薬品の何れかを示す場合、注文商品が指定医薬品であると判定する（ステップＳ５３：ＹＥＳ）。この場合、注文内容受付部１４２は、ステップＳ５４に進む。
【００８９】
ステップＳ５４において、注文内容受付部１４２は、注文情報の商品区分を指定医薬品に設定する。次いで、注文内容受付部１４２は、注文情報に含まれるユーザＩＤ、店舗ＩＤ及び商品ＩＤに対応する使用者状態情報を物かごＤＢ１２ｄから取得する。そして、注文内容受付部１４２は、使用者状態情報を注文情報に追加する（ステップＳ５５）。次いで、注文内容受付部１４２は、注文情報に確認ステータスを追加し、確認ステータスを店舗送信前に設定する（ステップＳ５６）。次いで、注文内容受付部１４２は、ステップＳ５８に進む。
【００９０】
ステップＳ５３において、注文内容受付部１４２は、注文商品が指定医薬品ではないと判定した場合には（ステップＳ５３：ＮＯ）、ステップＳ５７に進む。ステップＳ５７において、注文内容受付部１４２は、商品区分を一般商品に設定する。次いで、注文内容受付部１４２は、ステップＳ５８に進む。
【００９１】
ステップＳ５８において、注文内容受付部１４２は、生成した注文情報を注文ＤＢ１２ｅに登録する。次いで、注文内容受付部１４２は、注文内容を送信した購入者宛てに注文内容受付通知メールを送信する（ステップＳ５９）。注文内容受付部１４２は、ステップＳ５９を終えると注文内容登録処理を終了させる。
【００９２】
図１７は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の受注一覧送信処理の一例を示すフローチャートである。店舗端末２から受注一覧ページの要求を受信したとき、システム制御部１４は受注一覧送信処理を実行する（例えば図５ステップＳ２３、図６ステップＳ３１、Ｓ４６）。受注一覧ページの要求は、例えば、受注一覧ページを要求した店舗の店舗ＩＤ、注文情報の検索条件等を含む。図１７に示すように、受注情報提供部１４５は、受信した要求に含まれる店舗ＩＤに対応する注文情報を注文ＤＢ１２ｅから検索する（ステップＳ６１）。このとき、受注情報提供部１４５は、検索条件に対応する注文情報を検索する。次いで、受注情報提供部１４５は、番号ｉを１に設定する（ステップＳ６２）。また、受注情報提供部１４５は、記憶部１２からテンプレートとなる受注一覧ページのＨＴＭＬ文書を取得する。次いで、受注情報提供部１４５は、検索した注文情報のうちｉ番目の注文情報の一部の内容、例えば受付日時、注文番号、決済方法、決済ステータス、発送ステータス等を、ＨＴＭＬ文書に追加する（ステップＳ６３）。
【００９３】
次いで、受注情報提供部１４５は、ｉ番目の注文情報に含まれる商品区分が指定医薬品であるか否かを判定する（ステップＳ６４）。このとき、受注情報提供部１４５は、商品区分が指定医薬品であると判定した場合には（ステップＳ６４：ＹＥＳ）、ステップＳ６５に進む。ステップＳ６５において、受注情報提供部１４５は、ｉ番目の注文情報に含まれる確認ステータスに対応する確認ステータスアイコンの画像データのＵＲＬを取得する。また、受注情報提供部１４５は、例えばｉ番目の注文情報に含まれる注文番号に基づいて、メッセージ管理ページのＵＲＬを生成する。次いで、受注情報提供部１４５は、確認ステータスアイコンを表示するための情報として、例えば画像データのＵＲＬ、メッセージ管理ページのＵＲＬを含むタグデータ又はスクリプトをＨＴＭＬ文書に追加する。次いで、受注情報提供部１４５は、ステップＳ６６に進む。一方、受注情報提供部１４５は、商品区分が指定医薬品ではないと判定した場合には（ステップＳ６４：ＮＯ）、ステップＳ６６に進む。
【００９４】
ステップＳ６６において、受注情報提供部１４５は、番号ｉが、検索された注文情報の数と一致するか否かを判定する。このとき、受注情報提供部１４５は、番号ｉが注文情報の数と一致しないと判定した場合には（ステップＳ６６：ＮＯ）、ステップＳ６７に進む。ステップＳ６７において、受注情報提供部１４５は、番号ｉに１を加算して、ステップＳ６３に進む。一方、受注情報提供部１４５は、番号ｉが注文情報の数と一致すると判定した場合には（ステップＳ６６：ＹＥＳ）、ステップＳ６８に進む。ステップＳ６８において、受注情報提供部１４５は、完成した受注一覧ページのＨＴＭＬ文書を店舗端末２へ送信する。受注情報提供部１４５は、ステップＳ６８を終えると、受注一覧送信処理を終了させる。ＨＴＭＬ文書を受信した店舗端末２は、受注一覧ページを表示する。確認ステータスアイコンを表示するための情報がＨＴＭＬ文書に含まれている場合、店舗端末２は、この情報に基づいて確認ステータスアイコンの画像データを電子商店街サーバ１から取得して表示する。こうして、例えば図８（ａ）、図１３（ａ）、図１４（ａ）又は図１５（ｂ）に示すような受注一覧ページが表示される。
【００９５】
図１８は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。店舗端末２から店舗メッセージを受信したとき、システム制御部１４は店舗メッセージ登録処理を実行する（例えば図６ステップＳ３７）。店舗端末２は、店舗メッセージとともに、例えば件名、注文番号等を電子商店街サーバ１へ送信する。図１８に示すように、メッセージ処理部１４３は、受信した注文番号に対応する店舗メッセージをメッセージＤＢ１２ｆから検索する。このとき、対応する店舗メッセージが登録されていない場合、メッセージ処理部１４３は、新しいメッセージ番号を１に設定する。対応する店舗メッセージが登録されている場合、メッセージ処理部１４３は、店舗送信日時が最新のメッセージ番号に１を加算して、新しいメッセージ番号を設定する。また、メッセージ処理部１４３は、現在日時を店舗送信日時として取得する。次いで、メッセージ処理部１４３は、メッセージ番号、店舗送信日時、店舗メッセージ、件名及び注文番号を対応付けてメッセージＤＢ１２ｆに登録する（ステップＳ７１）。
【００９６】
次いで、ステータス制御部１４４は、注文番号に対応する注文情報を注文ＤＢ１２ｅから特定し、注文情報に含まれる確認ステータスが店舗送信前であるか否かを判定する（ステップＳ７２）。このとき、ステータス制御部１４４は、確認ステータスが店舗送信前であると判定した場合には（ステップＳ７２：ＹＥＳ）、ステップＳ７３に進む。ステップＳ７３において、ステータス制御部１４４は、確認ステータスを購入者回答前に設定して、ステップＳ７４に進む。一方、ステータス制御部１４４は、確認ステータスが店舗送信前ではないと判定した場合には（ステップＳ７２：ＮＯ）、ステップＳ７４に進む。
【００９７】
ステップＳ７４において、メッセージ処理部１４３は、店舗メッセージ登録通知メールを送信する。具体的に、メッセージ処理部１４３は、特定した注文情報に含まれるユーザＩＤに対応する電子メールアドレスを会員ＤＢ１２ａから取得する。そして、注文内容受付部１４２は、取得した電子メールアドレスを宛先アドレスに格納した店舗メッセージ登録通知メールを生成して送信する。メッセージ処理部１４３は、ステップＳ７４を終えると店舗メッセージ登録処理を終了させる。
【００９８】
図１９は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の注文履歴送信処理の一例を示すフローチャートである。購入者端末３から注文履歴ページの要求を受信したとき、システム制御部１４は注文履歴送信処理を実行する（例えば図６ステップＳ３８）。注文履歴ページの要求は、例えば、注文履歴ページを要求した購入者のユーザＩＤ、注文情報の検索条件等を含む。図１９に示すように、注文履歴提供部１４６は、受信した要求に含まれるユーザＩＤに対応する注文情報を注文ＤＢ１２ｅから検索する（ステップＳ８１）。このとき、注文履歴提供部１４６は、検索条件に対応する注文情報を検索する。次いで、注文履歴提供部１４６は、番号ｉを１に設定する（ステップＳ８２）。また、注文履歴提供部１４６は、記憶部１２からテンプレートとなる注文履歴ページのＨＴＭＬ文書を取得する。次いで、注文履歴提供部１４６は、取得した注文情報のうちｉ番目の注文情報の一部の内容、例えば、受付日、店舗の名称、商品名、価格等を、ＨＴＭＬ文書に追加する（ステップＳ８３）。
【００９９】
次いで、注文履歴提供部１４６は、ｉ番目の注文情報に含まれる商品区分が指定医薬品であるか否かを判定する（ステップＳ８４）。このとき、注文履歴提供部１４６は、商品区分が指定医薬品であると判定した場合には（ステップＳ８４：ＹＥＳ）、ステップＳ８５に進む。ステップＳ８５において、注文履歴提供部１４６は、ｉ番目の注文情報に含まれる確認ステータスが確認未完了であるか否かを判定する。このとき、注文履歴提供部１４６は、確認ステータスが確認未完了であると判定した場合には（ステップＳ８５：ＹＥＳ）、ステップＳ８６に進む。ステップＳ８６において、注文履歴提供部１４６は、例えばｉ番目の注文情報に含まれる注文番号に基づいて、メッセージ確認ページのＵＲＬを生成する。次いで、注文履歴提供部１４６は、店舗メッセージ確認リンク２５２を表示するための情報として、例えばメッセージ確認ページのＵＲＬを含むタグデータをＨＴＭＬ文書に追加する。次いで、注文履歴提供部１４６は、ステップＳ８７に進む。一方、注文履歴提供部１４６は、商品区分が指定医薬品ではないと判定した場合（ステップＳ８４：ＮＯ）、又は確認ステータスが確認未完了ではないと判定した場合には（ステップＳ８５：ＮＯ）、ステップＳ８７に進む。
【０１００】
ステップＳ８７において、注文履歴提供部１４６は、番号ｉが、検索された注文情報の数と一致するか否かを判定する。このとき、注文履歴提供部１４６は、番号ｉが注文情報の数と一致しないと判定した場合には（ステップＳ８７：ＮＯ）、ステップＳ８８に進む。ステップＳ８８において、注文履歴提供部１４６は、番号ｉに１を加算して、ステップＳ８３に進む。一方、注文履歴提供部１４６は、番号ｉが注文情報の数と一致すると判定した場合には（ステップＳ８７：ＹＥＳ）、ステップＳ８９に進む。ステップＳ８９において、注文履歴提供部１４６は、完成した注文履歴ページのＨＴＭＬ文書を店舗端末２へ送信する。注文履歴提供部１４６は、ステップＳ８９を終えると、注文履歴送信処理を終了させる。ＨＴＭＬ文書を受信した購入者端末３は、注文履歴ページを表示する。メッセージ確認ページのＵＲＬを含むタグデータがＨＴＭＬ文書に含まれている場合、購入者端末３は、このデータに基づいて店舗メッセージ確認リンク２５２を表示する。こうして、例えば図１１に示すような注文履歴ページが表示される。
【０１０１】
図２０は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の購入者メッセージ登録処理の一例を示すフローチャートである。購入者端末３から購入者メッセージを受信したとき、システム制御部１４は購入者メッセージ登録処理を実行する（例えば図６ステップＳ４４、４５）。購入者端末３は、購入者メッセージとともに、例えば注文番号等を電子商店街サーバ１へ送信する。図２０に示すように、メッセージ処理部１４３は、現在日時を購入者送信日時として取得する。また、メッセージ処理部１４３は、受信した注文番号に対応するメッセージ番号をメッセージＤＢ１２ｆから検索する。そして、メッセージ処理部１４３は、検索されたメッセージ番号のうち最新のメッセージ番号に対応付けて、購入者メッセージ及び購入者送信日時をメッセージＤＢ１２ｆに登録する（ステップＳ９１）。
【０１０２】
次いで、ステータス制御部１４４は、受信した購入者メッセージからチェックボックス表示文字を検索する。そして、ステータス制御部１４４は、検索された全てのチェックボックス表示文字がチェック済みを示すか否かを判定する（ステップＳ９２）。このとき、メッセージ処理部１４３は、全てのチェックボックス表示文字がチェック済みを示すと判定した場合には（ステップＳ９２：ＹＥＳ）、ステップＳ９３に進む。ステップＳ９３において、メッセージ処理部１４３は、受信した注文番号に対応する注文情報を注文ＤＢ１２ｅから特定し、注文情報に含まれる確認ステータスを確認完了に設定する。次いで、ステータス制御部１４４は、ステップＳ９５に進む。一方、メッセージ処理部１４３は、全てのチェックボックス表示文字がチェック済みを示すとは判定しなかった場合には（ステップＳ９２：ＮＯ）、ステップＳ９４に進む。ステップＳ９４において、メッセージ処理部１４３は、確認ステータスを回答継続中に設定する。次いで、ステータス制御部１４４は、ステップＳ９５に進む。
【０１０３】
ステップＳ９５において、メッセージ処理部１４３は、購入者メッセージ登録通知メールを送信する。具体的に、メッセージ処理部１４３は、特定した注文情報に含まれる店舗ＩＤに対応する電子メールアドレスを店舗ＤＢ１２ｂから取得する。そして、注文内容受付部１４２は、取得した電子メールアドレスを宛先アドレスとして格納した購入者メッセージ登録通知メールを生成して送信する。メッセージ処理部１４３は、ステップＳ９５を終えると購入者メッセージ登録処理を終了させる。
【０１０４】
以上説明したように、本実施形態によれば、システム制御部１４が、購入者が注文する商品が指定医薬品である場合、商品を使用する使用者の状態情報を購入者から受け付ける。また、システム制御部１４が、購入者から商品の注文内容が受け付けられた場合、この注文内容を記憶部１２に記憶させる。また、システム制御部１４が、注文商品が指定医薬品である場合、記憶部１２に記憶される注文内容に関連付けて、確認未完了に設定された確認ステータスを記憶部１２に記憶させる。また、システム制御部１４が、注文内容に示される指定医薬品と受け付けられた使用者状態情報とに応じて生成された留意情報を、購入者が確認可能に出力する。また、システム制御部１４が、留意情報を理解したと購入者が確認したことを示す購入者メッセージを受け付ける。また、システム制御部１４が、購入者メッセージが受け付けられた場合、記憶部１２に記憶された確認ステータスを確認完了に更新する。また、システム制御部１４が、記憶部１２に記憶された確認ステータスを、注文内容に示される指定医薬品の販売成立のための処理が可能であるかを判定可能に出力する。そのため、指定医薬品の注文内容を送信する場合であっても、一般商品の場合と同様に分かりやすい手順としつつ、商品の発送までに個別の情報提供が可能となる。
【０１０５】
また、システム制御部１４が、注文商品が指定医薬品である場合、店舗メッセージ確認リンク２５２を購入者端末３により提示させる。また、システム制御部１４が、店舗メッセージ確認リンク２５２が選択された場合、メッセージ確認ページを購入者端末３により提示させる。また、システム制御部１４が、メッセージ確認ページにおけるＯＫボタン２６５が操作されることに基づく購入者メッセージを取得する。従って、購入者による留意情報の確認を容易にすることができる。
【０１０６】
また、システム制御部１４が、記憶部１２に記憶された注文内容についての受注一覧ページを店舗端末２により提示させる。このとき、システム制御部１４が、注文商品が指定医薬品である場合、確認ステータスアイコン２１１を受注一覧ページとともに提示させる。従って、確認ステータスアイコン２１１により、店舗は、購入者が留意情報を確認したか否かを容易に認識することができる。
【０１０７】
［１−５．変形例］
次に本実施形態の変形例について図２１を用いて説明する。電子商店街サーバ１は、店舗の操作により発送ステータスを発送待ちに更新することに代えて、自動的に発送ステータスを更新してもよい。例えば、ステータス制御部１４４は、確認ステータス又は決済ステータスが変更されたタイミングで、発送ステータスを更新するか否かを判定してもよい。本変形例において、ステータス判定部５４３は、本発明における第１発送状態更新手段、第２発送状態更新手段の一例である。
【０１０８】
図２１は、本変形例に係る電子商店街サーバ１のシステム制御部１４の発送ステータス制御処理の一例を示すフローチャートである。例えば、クレジットカードによる決済の承認処理により決済ステータスが更新されたとき（図５ステップＳ２６）、決済ステータス更新要求に応じて決済ステータスが更新されたとき、及び確認ステータスが確認完了に更新されたときに（図６ステップＳ４４）、システム制御部１４は発送ステータス制御処理を実行してもよい。
【０１０９】
図２１に示すように、ステータス制御部１４４は、確認ステータス又は決済ステータスが更新された注文情報を注文ＤＢ１２ｅから特定する。そして、ステータス制御部１４４は、特定した注文情報に含まれる決済ステータスが処理完了であるか否かを判定する（ステップＳ１０１）。このとき、ステータス制御部１４４は、決済ステータスが処理完了ではないと判定した場合には（ステップＳ１０１：ＮＯ）、発送ステータス制御処理を終了させる。一方、ステータス制御部１４４は、決済ステータスが処理完了であると判定した場合には（ステップＳ１０１：ＹＥＳ）、ステップＳ１０２に進む。ステップＳ１０２において、ステータス制御部１４４は、特定した注文情報に含まれる商品区分が指定医薬品であるか否かを判定する。このとき、ステータス制御部１４４は、商品区分が指定医薬品ではないと判定した場合には（ステップＳ１０２：ＮＯ）、ステップＳ１０４に進む。一方、ステータス制御部１４４は、商品区分が指定医薬品であると判定した場合には（ステップＳ１０２：ＹＥＳ）、ステップＳ１０３に進む。ステップＳ１０３において、ステータス制御部１４４は、特定した注文情報に含まれる確認ステータスが確認完了であるか否かを判定する。このとき、ステータス制御部１４４は、確認ステータスが確認完了ではないと判定した場合には（ステップＳ１０３：ＮＯ）、発送ステータス制御処理を終了させる。一方、ステータス制御部１４４は、確認ステータスが確認完了であると判定した場合には（ステップＳ１０３：ＹＥＳ）、ステップＳ１０４に進む。ステップＳ１０４において、ステータス制御部１４４は、特定した注文情報に含まれる発送ステータスを発送待ちに設定して、ステータス制御処理を終了させる。
【０１１０】
以上説明したように、本変形例によれば、システム制御部１４が、注文商品が指定医薬品ではない場合、決済ステータスが処理完了に更新されていることを条件に、発送ステータスを発送待ちに更新する。また、システム制御部１４が、注文商品が指定医薬品である場合、決済ステータスが処理完了に更新され且つ確認ステータスが確認完了に更新されていることを条件に、発送ステータスを発送待ちに更新する。そのため、店舗が誤って商品を発送することを防止することができる。
【０１１１】
［２．第２実施形態］
次に、第２実施形態について説明する。第１実施形態においては、受注、使用者状態の提示、留意情報の入力、各種ステータスの提示等に関するユーザインターフェースを電子商店街サーバ１が店舗に対して提供していた（例えば、受注一覧ページ、受注管理ページ、メッセージ管理ページ、メッセージ入力ページ等）。第２実施形態においては、店舗ごとに独自のユーザインターフェースを設計可能とする。そのため、電子商店街サーバ１から店舗のシステムに対してＡＰＩ（Application Programming Interface）が提供される。以下に説明する点を除き、第２実施形態は第１実施形態と基本的に同様である。
【０１１２】
［２−１．情報処理システムの構成及び機能概要］
次に、本実施形態に係る情報処理システムＳ２の構成及び機能概要について、図２２を用いて説明する。図２２は、本実施形態に係る情報処理システムＳ２の概要構成の一例を示す図である。図２２において図１と同様の要素については同様の符号が付されている。
【０１１３】
図２２に示すように、情報処理システムＳ２は、電子商店街サーバ１と、複数の店舗システム４と、複数の購入者端末３と、を含んで構成されている。そして、電子商店街サーバ１と各店舗システム４及び各購入者端末３とは、ネットワークＮＷを介して相互にデータの送受信が可能になっている。
【０１１４】
本実施形態における電子商店街サーバ１は、ＡＰＩを利用した店舗システム４からの要求に応じて、確認ステータスを、販売成立のための処理が可能であるかを判定可能に店舗システム４に出力する。
【０１１５】
店舗システム４は、店舗により構築されたシステムである。店舗システム４は、例えば店舗サーバ５と１以上の店舗端末６とを含んで構成されている。店舗サーバ５と店舗端末６とは例えばＬＡＮ（Local Area Network）等のネットワークを介して互いに通信可能である。店舗サーバ５は、ＡＰＩ等を利用して電子商店街サーバ１との通信を行う。また、店舗サーバ５は、店舗端末６に対して各種のユーザインターフェースを提供する。提供されるユーザインターフェースは、例えばウェブベースのインターフェースであってもよいし、他のインターフェースであってもよい。更に店舗サーバ５は、注文商品についての発送ステータスの制御を行う。本実施形態においては、電子商店街サーバ１と店舗サーバ５との組み合わせが、本発明における情報システムの一例である。店舗サーバ５は、店舗の従業員等により操作される端末装置である。店舗端末６が店舗サーバ５にアクセスすることにより、従業員は、商品の注文内容の確認、使用者状態情報の閲覧、留意情報の入力等を行う。
【０１１６】
電子商店街サーバ１と購入者端末３との間の通信に関する処理、及び店舗システム４との通信を伴わない電子商店街サーバ１内部の処理については第１実施形態と同様であるので、これらの詳細な説明は省略する。
【０１１７】
なお、店舗独自のユーザインターフェースを利用するのか、又は電子商店街サーバ１から提供されるユーザインターフェースを利用するのかを、店舗ごとに選択可能であってもよい。電子商店街サーバ１から提供されるユーザインターフェースを利用する店舗については店舗サーバ５は不要である。この場合、電子商店街サーバ１と店舗端末６とが直接通信してもよく、電子商店街サーバ１の処理は第１実施形態の場合と同様である。
【０１１８】
［２−２．店舗サーバの構成］
次に、店舗サーバ５の構成について、図２３を用いて説明する。図２３（ａ）は、本実施形態に係る店舗サーバ５の概要構成の一例を示すブロック図である。図２３（ａ）に示すように、店舗サーバ５は、通信部５１と、記憶部５２と、入出力インターフェース５３と、システム制御部５４と、を備えている。そして、システム制御部５４と入出力インターフェース５３とは、システムバス５５を介して接続されている。
【０１１９】
通信部５１は、ネットワークＮＷに接続して、電子商店街サーバ１や店舗端末６等との通信状態を制御するようになっている。記憶部５２は、例えば、ハードディスクドライブ等により構成されている。記憶部５２には、店舗が販売する商品に関する情報、受注に関する情報等が記憶されている。また、記憶部５２には、オペレーティングシステム、ＷＷＷ（World Wide Web）サーバプログラム、ＤＢＭＳ（Database Management System）、受注管理プログラム等の各種プログラムが記憶されている。受注管理プログラムは、電子商店街での受注に関する各種の処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークＮＷを介して取得されるようにしてもよいし、光ディスク等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。また、受注管理プログラム等は、プログラム製品であってもよい。入出力インターフェース５３は、通信部５１及び記憶部５２とシステム制御部５４との間のインターフェース処理を行うようになっている。システム制御部５４は、ＣＰＵ５４ａ、ＲＯＭ５４ｂ、ＲＡＭ５４ｃ等により構成されている。
【０１２０】
［２−３．システム制御部の機能概要］
次に、図２３（ｂ）を用いて、システム制御部５４の機能概要について説明する。図２（ｂ）は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部５４の機能ブロックの一例を示す図である。システム制御部５４は、ＣＰＵ５４ａが、受注管理プログラム等のプログラムを読み出し実行することにより、図２３（ｂ）に示すように、サーバ通信部５４１、ユーザインターフェース部５４２、ステータス判定部５４３等として機能する。サーバ通信部５４１は、ＡＰＩを利用して電子商店街サーバ１へ要求を送信したり、電子商店街サーバ１から送信されてきた情報を受信したりする。ユーザインターフェース部５４２は、店舗端末６に対してユーザインターフェースを提供し、サーバ通信部５４１と店舗端末６との間の情報交換を制御する。ステータス判定部５４３は、商品区分、決済ステータス及び確認ステータスに基づき、発送ステータスの更新の可否を判定する。
【０１２１】
［２−４．情報処理システムの動作］
［２−４−１．システム全体の動作］
次に、情報処理システムＳ２の全体の動作について、図２４及び図２５を用いて説明する。図２４は、本実施形態に係る情報処理システムＳ２の、留意情報の提供に関する処理の一例を示すシーケンス図である。購入者からの指定医薬品についての注文内容を含む注文情報を注文ＤＢ１２ｅに登録した注文内容受付部１４２は、図２４に示すように注文内容受付通知メールを送信する（ステップＳ１１１）。注文内容受付通知メールを受信した店舗サーバ５のサーバ通信部５４１は、例えばこの電子メールに含まれる受付日時、注文番号、注文内容等を関連付けて記憶部５２に記憶させる。また、サーバ通信部５４１は、この電子メールに含まれる決済方法に応じた処理を実行する。例えば、決済方法がクレジットカード決済である場合、サーバ通信部５４１は決済承認要求を電子商店街サーバ１へ送信する（ステップＳ１１２）。電子商店街サーバ１のステータス制御部１４４は承認処理を実行し、支払いが承認されたことを示す処理結果を取得した場合、決済ステータスを処理完了に更新する（ステップＳ１１３）。なお、決済方法がクレジットカード決済ではない場合、店舗サーバ５は、例えば店舗の従業員による店舗端末６の操作に基づいて、決済ステータス更新要求を電子商店街サーバ１へ送信する。すると、ステータス制御部１４４は、決済ステータスを処理完了に更新する。承認処理が完了すると、電子商店街サーバ１のシステム制御部１４は、現在の決済ステータスを店舗サーバ５へ送信する（ステップＳ１１４）。店舗サーバ５のステータス判定部５４３は、受信した決済ステータスを注文情報と関連付けて記憶部５２に記憶させる。
【０１２２】
次いで、サーバ通信部５４１は、使用者状態情報の要求を電子商店街サーバ１へ送信する（ステップＳ１１５）。この要求は、注文番号を含む。電子商店街サーバ１のシステム制御部１４は、受信した要求に含まれる注文番号に対応する使用者状態情報を注文ＤＢ１２ｅから取得し、使用者状態情報を店舗サーバ５へ送信する（ステップＳ１１６）。なお、注文内容受付通知メールが使用者状態情報を含む場合、ステップＳ１１５及びＳ１１６は不要である。店舗サーバ５のユーザインターフェース部５４２は、受信した使用者状態情報を店舗端末６に送信し（ステップＳ１１７）、店舗端末６に使用者状態情報を表示させる。従業員は、使用者状態情報に応じて留意情報を入力する（ステップＳ１１８）。すると、店舗端末６は留意情報を店舗メッセージとして店舗サーバ５へ送信し（ステップＳ１１９）、サーバ通信部５４１は、店舗メッセージを電子商店街サーバ１へ送信する（ステップＳ１２０）。電子商店街サーバ１のメッセージ処理部１４３は、受信した店舗メッセージをメッセージＤＢ１２ｆに登録するとともに、購入者宛てに店舗メッセージ登録通知メールを送信する（ステップＳ１２１）。
【０１２３】
図２５は、本実施形態に係る情報処理システムＳ２の、確認ステータス及び発送ステータスの更新に関する処理の一例を示すシーケンス図である。購入者端末３において表示されているメッセージ確認ページにおいて購入者が購入者メッセージを入力すると、図２５に示すように、購入者端末３は購入者メッセージを電子商店街サーバ１へ送信する（ステップＳ１３１）。電子商店街サーバ１のステータス制御部１４４は、購入者メッセージに含まれる全てのチェックボックス表示文字がチェック済みを示す場合、確認ステータスを確認完了に更新する（ステップＳ１３２）。次いで、メッセージ処理部１４３は、店舗宛てに購入者メッセージ登録通知メールを送信する（ステップＳ１３３）。購入者メッセージ登録通知メールを受信した店舗サーバ５のメッセージ判定部５４３は、購入者メッセージ及び確認ステータスの要求を電子商店街サーバ１へ送信する（ステップＳ１３４）。この要求は受注番号を含む。電子商店街サーバ１のシステム制御部１４は、要求に含まれる受注番号に対応する購入者メッセージをメッセージＤＢ１２ｆから取得するとともに、受注番号に対応する確認ステータスを注文ＤＢ１２ｅから取得する。そして、システム制御部１４は、購入者メッセージ及び確認ステータスを店舗サーバ５へ送信する（ステップＳ１３５）。店舗サーバ５のステータス判定部５４３は、決済ステータスが処理完了であり且つ確認ステータスが確認完了であると判定する（ステップＳ１３６）と、発送ステータス更新要求を電子商店街サーバ１へ送信する（ステップＳ１３７）。この要求は注文番号を含む。電子商店街サーバ１のステータス制御部１４４は、要求に含まれる注文番号に対応する注文情報を注文ＤＢ１２ｅから特定し、注文情報に含まれる発送ステータスを発送待ちに更新する（ステップＳ１３８）。
【０１２４】
なお、店舗サーバ５が電子商店街サーバ１から受信した確認ステータスが確認未完了である場合、店舗サーバ５は購入者メッセージを店舗端末６へ送信し、購入者メッセージに対する店舗メッセージを従業員に入力させる。そして、店舗サーバ５は、入力された購入者メッセージを電子商店街サーバ１へ送信する。
【０１２５】
図２４及び図２５の例では、先に購入代金の支払いのための処理が行われ、その後に留意情報の提供と確認が行われていた。しかしながら、先に留意情報の提供と確認が行われ、その後に購入代金の支払いのための処理が行われてもよい。また、これらの処理が並行して行われてもよい。
【０１２６】
［２−４−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について図２６を用いて説明する。図２６は、本実施形態に係る店舗サーバ５のシステム制御部５４の発送ステータス更新判定処理の一例を示すフローチャートである。例えば、クレジットカードによる決済の承認処理の結果が電子商店街サーバ１から店舗サーバ５へ送信されたとき（図２４ステップＳ１１４）、店舗サーバ５が電子商店街サーバ１へ決済ステータス更新要求を送信したとき、及び店舗サーバ５が購入者メッセージ登録通知メールを受信したときに（図２６ステップＳ１３３）、システム制御部５４は発送ステータス制御処理を実行してもよい。
【０１２７】
図２６に示すように、ステータス判定部５４３は、対象となる注文に対応する決済ステータス又は確認ステータス、或いはその両方を必要に応じて電子商店街サーバ１から取得する（ステップＳ１４１）。例えば、ステータス判定部５４３は、注文番号を含む要求を電子商店街サーバ１へ送信し、電子商店街サーバ１は注文番号に対応する決済ステータス及び確認ステータスを店舗サーバ５へ送信する。次いで、ステータス判定部５４３は、決済ステータスが処理完了であるか否かを判定する（ステップＳ１４２）。このとき、ステータス判定部５４３は、決済ステータスが処理完了ではないと判定した場合には（ステップＳ１４２：ＮＯ）、ステータス判定処理を終了させる。一方、ステータス判定部５４３は、決済ステータスが処理完了であると判定した場合には（ステップＳ１４２：ＹＥＳ）、ステップＳ１４３に進む。ステップＳ１４３において、ステータス判定部５４３は、対象の注文の注文番号に対応する商品区分が指定医薬品であるか否かを判定する。ステータス判定部５４３は、例えば注文商品のジャンルＩＤに基づいて商品区分が指定医薬品であるか否かを判定してもよいし、電子商店街サーバ１から商品区分を取得してもよい。このとき、ステータス判定部５４３は、商品区分が指定医薬品ではないと判定した場合には（ステップＳ１４３：ＮＯ）、ステップＳ１４５に進む。一方、ステータス判定部５４３は、商品区分が指定医薬品であると判定した場合には（ステップＳ１４３：ＹＥＳ）、ステップＳ１４４に進む。ステップＳ１４４において、ステータス判定部５４３は、対象の注文に対応する確認ステータスが確認完了であるか否かを判定する。このとき、ステータス判定部５４３は、確認ステータスが確認完了ではないと判定した場合には（ステップＳ１４４：ＮＯ）、ステータス判定処理を終了させる。一方、ステータス判定部５４３は、確認ステータスが確認完了であると判定した場合には（ステップＳ１４４：ＹＥＳ）、ステップＳ１４５に進む。ステップＳ１４５において、ステータス判定部５４３は、対象の注文の注文番号を含む発送ステータス更新要求を電子商店街サーバ１へ送信して、ステータス制御処理を終了させる。
【０１２８】
以上説明したように、本実施形態によれば、店舗サーバ５が、注文商品が指定医薬品ではない場合、決済ステータスが処理完了に更新されていることを条件に発送ステータス更新要求を送信し、電子商店街サーバ１が発送ステータスを発送待ちに更新する。また、店舗サーバ５が、注文商品が指定医薬品である場合、決済ステータスが処理完了に更新され且つ確認ステータスが確認完了に更新されていることを条件に、発送ステータス更新要求を送信し、電子商店街サーバ１が発送ステータスを発送待ちに更新する。そのため、店舗が誤って商品を発送することを防止することができる。
【０１２９】
［３．第３実施形態］
［３−１．システム制御部の機能概要］
次に、第３実施形態におけるシステム制御部１４の機能について、図２７を用いて説明する。以下に説明する点を除き、第３実施形態は第１実施形態と基本的に同様である。本実施形態において、受注情報提供部１４５は、指定医薬品の注文について、確認ステータスに応じて注文商品の送付先の住所の提供を制御する。本実施形態において、受注情報提供部１４５は、本発明における注文内容提示制御手段の一例である。図２７（ａ）は、確認ステータスが確認完了である場合の受注管理ページの表示例を示す図であり、図２７（ｂ）は、確認ステータスが確認未完了である場合の受注管理ページの表示例を示す図である。図２７（ａ）に示すように、確認ステータスが確認完了である場合、受注情報提供部１４５は、送付先の住所を表示させる。一方、図２７（ｂ）に示すように、確認ステータスが確認未完了である場合、受注情報提供部１４５は、送付先の住所を表示させない。これにより、購入者が留意情報を確認していないのにもかかわらず、店舗が誤って注文商品を発送することを防止することができる。また、メッセージ処理部１４３は、注文内容受け付け通知メールに送付先の住所を含めない。
【０１３０】
［３−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図２８を用いて説明する。図２８は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の受注管理ページ送信処理の一例を示すフローチャートである。店舗端末２から受注管理ページの要求を受信したとき、システム制御部１４は受注管理ページ送信処理を実行する。この要求は注文番号を含む。図２８に示すように、受注情報提供部１４５は、要求に含まれる注文番号に対応する注文情報を注文ＤＢ１２ｅから取得する（ステップＳ１５１）。また、受注情報提供部１４５は、記憶部１２からテンプレートとなる受注管理ページのＨＴＭＬ文書を取得する。次いで、受注情報提供部１４５は、注文情報に含まれる商品区分が指定医薬品であるか否かを判定する（ステップＳ１５２）。このとき、受注情報提供部１４５は、商品区分が指定医薬品ではないと判定した場合には（ステップＳ１５２：ＮＯ）、ステップＳ１５４に進む。一方、受注情報提供部１４５は、商品区分が指定医薬品であると判定した場合には（ステップＳ１５２：ＹＥＳ）、ステップＳ１５３に進む。
【０１３１】
ステップＳ１５３において、受注情報提供部１４５は、注文情報に含まれる確認ステータスが確認完了であるか否かを判定する。このとき、受注情報提供部１４５は、確認ステータスが確認完了であると判定した場合には（ステップＳ１５３：ＹＥＳ）、ステップＳ１５４に進む。ステップＳ１５４において、受注情報提供部１４５は、注文情報の内容を受注管理ページのＨＴＭＬ文書に追加する。このとき、受注情報提供部１４５は、送付先情報も追加する。次いで、受注情報提供部１４５は、ステップＳ１５６に進む。一方、受注情報提供部１４５は、確認ステータスが確認完了ではないと判定した場合には（ステップＳ１５３：ＮＯ）、ステップＳ１５５に進む。ステップＳ１５５において、受注情報提供部１４５は、送付先情報を除き、注文情報の内容を受注管理ページのＨＴＭＬ文書に追加する。次いで、受注情報提供部１４５は、ステップＳ１５６に進む。ステップＳ１６５において、受注情報提供部１４５は、受注管理ページのＨＴＭＬ文書を店舗端末２に送信して、受注管理ページ送信処理を終了させる。
【０１３２】
以上説明したように、本実施形態によれば、システム制御部１４が、注文商品が指定医薬品であり、且つ注文内容に関連付けられた確認ステータスが確認未完了である場合、注文内容のうち商品の送付先の住所を出力しない。そのため、購入者が留意情報を確認していないのにもかかわらず、店舗が商品を発送することを防止することができる。
【０１３３】
［４．第４実施形態］
［４−１．情報処理システムの構成及び機能概要］
次に、第４実施形態について説明する。以下に説明する点を除き、第４実施形態は第１実施形態と基本的に同様である。先ず、第４実施形態に係る情報処理システムＳ３の構成及び機能概要について、図２９を用いて説明する。図２９は、本実施形態に係る情報処理システムＳ３の概要構成の一例を示す図である。図２９において図１と同様の要素については同様の符号が付されている。
【０１３４】
図２９に示すように、情報処理システムＳ３は、電子商店街サーバ１と、複数の店舗端末２と、複数の購入者端末３と、配送管理サーバ７を含んで構成されている。そして、電子商店街サーバ１と各店舗端末２及び各購入者端末３及び配送管理サーバ７とは、ネットワークＮＷを介して相互にデータの送受信が可能になっている。
【０１３５】
配送管理サーバ７は、宅配などの配送サービスにおいて、品物の配送状況を管理するサーバ装置である。配送管理サーバ７は、例えば所定の配送業者により設置されてもよい。本実施形態において、電子商店街サーバ１は、配送管理サーバ７と連携することにより、電子商店街で購入された商品の配送状態を提供する。
【０１３６】
例えば、店舗は、注文商品を配送する前に、配送伝票情報を店舗端末２に入力する。配送伝票情報は、配送伝票に表示される情報である。配送伝票情報は、少なくとも配送伝票番号を含む。配送伝票番号は、配送伝票の識別番号である。配送伝票情報は、更に配送先の住所、氏名、電話番号、配送日時等を含んでもよい。店舗端末２は、入力された配送伝票情報を注文番号とともに電子商店街サーバ１へ送信する。電子商店街サーバ１は、配送伝票情報と注文番号とに関連付けて記憶部１２に記憶させる。例えば、電子商店街サーバ１は、配送伝票情報を注文ＤＢ１２ｅに登録する。
【０１３７】
店舗は注文商品に配送伝票を付して配送業者に引き渡す。配送業者は、配送伝票に表示されている情報を配送管理サーバ７に登録する。その後、例えば購入者端末３において注文履歴ページが表示されているとき、購入者が何れかの注文商品の配送状況の表示を選択する。すると、購入者端末３は注文番号を送信し、電子商店街サーバ１は、注文番号に対応する配送伝票番号を取得し、配送伝票番号に対応する配送状況を配送管理サーバ７から取得する。そして、電子商店街サーバ１は、購入者端末３に配送状況を表示させる。また、例えば店舗端末２の受注管理ページ等においても配送状況が表示されてもよい。
【０１３８】
［４−２．システム制御部の機能概要］
次に、システム制御部１４の機能について、図３０を用いて説明する。本実施形態において、受注情報提供部１４５は、店舗からの配送伝票情報の入力を受け付ける。このとき、受注情報提供部１４５は、指定医薬品の注文について、確認ステータスに応じて配送伝票情報の入力の受け付けを制御する。受注情報提供部１４５は、本発明における注文内容提示制御手段の一例である。図３０（ａ）は、確認ステータスが確認完了である場合の受注管理ページの表示例を示す図であり、図３０（ｂ）は、確認ステータスが確認未完了である場合の受注管理ページの表示例を示す図である。図３０（ａ）に示すように、確認ステータスが確認完了である場合、受注情報提供部１４５は、受注管理ページに配送伝票入力ボタン２２３を表示させる。配送伝票入力ボタン２２３は、配送伝票入力ページを表示するためのボタンである。配送伝票入力ページは、配送伝票情報を入力するためのウェブページである。配送伝票入力ページにおいて、従業員が配送伝票情報を入力すると、店舗端末２は情報を配送伝票情報として電子商店街サーバ１へ送信する。そして、電子商店街サーバ１は、配送伝票情報を注文ＤＢ１２ｅに登録する。一方、図３０（ｂ）に示すように、確認ステータスが確認未完了である場合、受注情報提供部１４５は、配送伝票入力ボタン２２３を表示させない。これにより、購入者が留意情報を確認していないのにもかかわらず、店舗が誤って注文商品を発送することを防止することができる。
【０１３９】
なお、受注情報提供部１４５は、配送伝票入力ボタン２２３の表示を制御するとともに、第３実施形態と同様に送付先の住所の表示を制御してもよい。また、配送伝票入力ボタン２２３の表示を制御することに代えて、例えば受注情報提供部１４５は、確認ステータスが確認未完了である場合、配送伝票入力ページに、発送が不可であることを示す警告メッセージ等を表示させてもよい。
【０１４０】
［４−３．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図３１を用いて説明する。図３１は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の受注管理ページ送信処理の一例を示すフローチャートである。店舗端末２から受注管理ページの要求を受信したとき、システム制御部１４は受注管理ページ送信処理を実行する。この要求は注文番号を含む。図３１に示すように、受注情報提供部１４５は、要求に含まれる注文番号に対応する注文情報を注文ＤＢ１２ｅから取得する（ステップＳ１６１）。また、受注情報提供部１４５は、記憶部１２からテンプレートとなる受注管理ページのＨＴＭＬ文書を取得する。このＨＴＭＬ文書は、配送伝票入力ボタン２２３を表示するためのデータを含む。次いで、受注情報提供部１４５は、注文情報の内容を受注管理ページのＨＴＭＬ文書に追加する（ステップＳ１６２）。次いで、受注情報提供部１４５は、注文情報に含まれる商品区分が指定医薬品であるか否かを判定する（ステップＳ１６３）。このとき、受注情報提供部１４５は、商品区分が指定医薬品ではないと判定した場合には（ステップＳ１６３：ＮＯ）、ステップＳ１６６に進む。一方、受注情報提供部１４５は、商品区分が指定医薬品であると判定した場合には（ステップＳ１６３：ＹＥＳ）、ステップＳ１６４に進む。
【０１４１】
ステップＳ１６４において、受注情報提供部１４５は、注文情報に含まれる確認ステータスが確認完了であるか否かを判定する。このとき、受注情報提供部１４５は、確認ステータスが確認完了であると判定した場合には（ステップＳ１６４：ＹＥＳ）、ステップＳ１６６に進む。一方、受注情報提供部１４５は、確認ステータスが確認完了ではないと判定した場合には（ステップＳ１６４：ＮＯ）、ステップＳ１６５に進む。ステップＳ１６５において、受注情報提供部１４５は、受注管理ページのＨＴＭＬ文書から、配送伝票入力ボタン２２３を表示するためのデータを削除する。次いで、受注情報提供部１４５は、ステップＳ１６６に進む。ステップＳ１６６において、受注情報提供部１４５は、受注管理ページのＨＴＭＬ文書を店舗端末２に送信して、受注管理ページ送信処理を終了させる。
【０１４２】
なお、配送伝票入力ボタン２２３の表示を制御することに代えて、システム制御部１４は、例えば配送伝票情報の登録を制御してもよい。例えば、システム制御部１４は、店舗端末２から入力された配送伝票情報を受信したとき、対応する注文情報の商品区分及び確認ステータスに基づいて、配送伝票情報を注文ＤＢ１２ｅに登録するか否かを判定してもよい。判定方法は図３１と同様である。
【０１４３】
以上説明したように、本実施形態によれば、システム制御部１４が、商品が指定医薬品であり且つ注文内容に関連付けられた確認ステータスが確認未完了である場合、配送伝票情報を受け付けない。そのため、購入者が留意情報を確認していないのにもかかわらず、店舗が配送伝票を使用して商品を発送することを防止することができる。
【０１４４】
［５．第５実施形態］
［５−１．システム制御部の機能概要］
次に、第５実施形態におけるシステム制御部１４の機能について、図３２を用いて説明する。以下に説明する点を除き、第５実施形態は第１実施形態〜第４実施形態と基本的に同様である。図３２は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の機能ブロックの一例を示す図である。図３２において図３（ｂ）と同様の要素については同様の符号が付されている。図３２に示すように、システム制御部１４は、使用者状態情報受付部１４１、注文内容受付部１４２、メッセージ処理部１４３、ステータス制御部１４４、受注情報提供部１４５、注文履歴提供部１４６、キャンセル処理部１４７等として機能する。キャンセル処理部１４７は、本発明におけるキャンセル手段の一例である。
【０１４５】
キャンセル処理部１４７は、指定医薬品の注文について留意情報が登録されたことを通知する店舗メッセージ登録通知メールが送信されてから、予め設定された確認期間が経過しても確認ステータスが確認未完了である場合には、その指定医薬品の注文を自動的にキャンセルする。注文商品が指定医薬品である場合、購入者が留意情報を理解したことを確認するまでは、店舗は注文商品を発送することができない。店舗は、注文商品を発送するまではその注文商品を在庫として確保しておく必要がある。一定期間が経過しても購入者からの確認を得ることができなかった場合には注文が自動的にキャンセルされることで、店舗は在庫を解放することができる。確認期間の日数は、例えば電子商店街サーバ１の管理者により予め設定されていてもよい。設定された確認期間の日数は記憶部１２に記憶されている。
【０１４６】
［５−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図３３を用いて説明する。図３３は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の自動キャンセル処理の一例を示すフローチャートである。例えば、システム制御部１４は定期的に自動キャンセル処理を実行する。例えば、システム制御部１４は、所定時間ごとに、又は所定日数ごとに自動キャンセル処理を実行してもよい。
【０１４７】
図３３に示すように、キャンセル処理部１４７は、注文ＤＢ１２ｅから、商品区分が指定医薬品、確認ステータスが確認未完了であり、且つキャンセルフラグがＦＡＬＳＥである注文情報を検索する（ステップＳ１７１）。次いで、キャンセル処理部１４７は、番号ｉを１に設定する（ステップＳ１７２）。次いで、キャンセル処理部１４７は、検索された注文情報のうちｉ番目の注文情報に対応する留意情報が登録されているか否かを判定する（ステップＳ１７３）。具体的に、キャンセル処理部１４７は、ｉ番目の注文情報に含まれる注文番号に対応する店舗メッセージをメッセージＤＢ１２ｆから検索する。キャンセル処理部１４７は、店舗メッセージが見つからなかった場合には、留意情報が登録されていないと判定する（ステップＳ１７３：ＮＯ）。この場合、キャンセル処理部１４７は、ステップＳ１７９に進む。一方、キャンセル処理部１４７は、店舗メッセージが見つかった場合には、留意情報が登録されていると判定する（ステップＳ１７３：ＹＥＳ）。この場合、キャンセル処理部１４７は、ステップＳ１７４に進む。
【０１４８】
ステップＳ１７４において、キャンセル処理部１４７は、留意情報の送信日時を取得する。具体的に、キャンセル処理部１４７は、ｉ番目の注文情報に含まれる注文番号に対応する店舗送信日時のうち、メッセージ番号が１である店舗送信日時をメッセージＤＢ１２ｆから取得する。店舗送信日時は、店舗メッセージ登録通知メールの送信日時として扱われる。次いで、キャンセル処理部１４７は、現在日時から、取得した送信日時を減算することにより、経過日数を計算する（ステップＳ１７５）。次いで、キャンセル処理部１４７は、経過日数が、記憶部１２に記憶されている確認期間日数以上であるか否かを判定する（ステップＳ１７６）。このとき、キャンセル処理部１４７は、経過日数が確認期間日数以上ではないと判定した場合には（ステップＳ１７６：ＮＯ）、ステップＳ１７９に進む。一方、キャンセル処理部１４７は、経過日数が確認期間日数以上であると判定した場合には（ステップＳ１７６：ＹＥＳ）、ステップＳ１７７に進む。
【０１４９】
ステップＳ１７７において、キャンセル処理部１４７は、ｉ番目の注文情報に含まれるキャンセルフラグをＴＲＵＥに設定する。次いで、キャンセル処理部１４７は、自動キャンセル通知メールを購入者及び店舗のそれぞれに宛てて送信する（ステップＳ１７８）。自動キャンセル通知メールは、注文が自動的にキャンセルされたことを通知する電子メールである。キャンセル処理部１４７は、ｉ番目の注文情報に含まれるユーザＩＤ及び店舗ＩＤに基づいて購入者及び店舗のそれぞれの電子メールアドレスを取得し、これらの電子メールアドレスに基づいて自動キャンセル通知メールを送信する。次いで、キャンセル処理部１４７は、ステップＳ１７９に進む。
【０１５０】
ステップＳ１７９において、キャンセル処理部１４７は、番号ｉが、検索された注文情報の数と一致するか否かを判定する。このとき、キャンセル処理部１４７は、番号ｉが注文情報の数と一致しないと判定した場合には（ステップＳ１７９：ＮＯ）、ステップＳ１８０に進む。ステップＳ１８０において、キャンセル処理部１４７は、番号ｉに１を加算して、ステップＳ１７３に進む。一方、キャンセル処理部１４７は、番号ｉが注文情報の数と一致すると判定した場合には（ステップＳ１７９：ＹＥＳ）、自動キャンセル処理を終了させる。
【０１５１】
以上説明したように、本実施形態によれば、システム制御部１４が、留意情報が生成された場合、この留意情報の確認が必要であることを通知する店舗メッセージ登録通知メールを出力する。また、システム制御部１４が、店舗メッセージ登録通知メールが出力されてから所定間内に購入者メッセージが受け付けられなかった場合、注文内容の受け付けをキャンセルする。そのため、留意情報が確認されないために発送もできず、他の購入者に販売することもできない商品の数を減らすことができる。
【０１５２】
［６．第６実施形態］
［６−１．システム制御部の機能概要］
次に、第６実施形態におけるシステム制御部１４の機能について、図３４及び図３５を用いて説明する。以下に説明する点を除き、第６実施形態は第５実施形態と基本的に同様である。第５実施形態で説明したように注文内容が自動的にキャンセルされた後、注文内容受付部１４２は、注文内容がキャンセルされた商品の再注文を購入者が行うことを可能とする。このとき、注文内容受付部１４２は、キャンセルされた注文内容を、再注文における注文内容として受け付けることを可能とするとともに、キャンセルされた注文内容に関連付けられた使用者状態情報を、再注文における使用者状態情報として受け付けることを可能とする。これにより、再注文の際、注文内容の再入力の手間を省くことができるとともに、使用者状態情報の再入力の手間を省くことができる。
【０１５３】
図３４は、注文履歴ページの表示例を示す図である。図３４において、図１１と同様の要素については同様の符号が付されている。図３４に示すように、注文履歴ページにおいて、自動的にキャンセルされた注文内容に対応する注文内容表示領域２５１には、キャンセルされていることを示すメッセージ２５３と、再注文ボタン２５４とが表示される。再注文ボタン２５４は、キャンセルされた注文内容が示す商品を再注文するためのボタンである。再注文ボタン２５４は、本発明における再注文要素の一例である。購入者が再注文ボタン２５４を選択すると、注文内容受付部１４２は、再注文内容確認ページを購入者端末３へ送信する。再注文内容確認ページは、再注文における注文内容及び使用者状態情報を確認するためのウェブページである。
【０１５４】
図３５は、再注文内容確認ページの表示例を示す図である。図３５に示すように、再注文内容確認ページには、注文内容表示領域２７１、使用者状態情報表示領域２７２、注文内容編集ボタン２７３、使用者状態情報編集ボタン２７４、及び確定ボタン２７５が表示される。注文内容表示領域２７１には注文内容が表示される。使用者状態情報表示領域２７２には、使用者状態情報が表示される。再注文内容確認ページに表示される注文内容及び使用者状態情報は、キャンセルされた注文内容及びその注文内容に関連付けられている使用者状態情報である。購入者が注文内容編集ボタン２７３を選択すると、注文内容受付部１４２は、注文内容編集ページを購入者端末３へ送信する。この注文内容編集ページにおいて、購入者は再注文内容確認ページに表示されていた注文内容を編集することができる。編集が終わると、注文内容受付部１４２は、再注文内容確認ページを購入者端末３へ送信する。購入者が使用者状態情報編集ボタン２７４を選択すると、使用者状態情報受付部１４１は、使用者状態情報編集ページを購入者端末３へ送信する。この使用者状態情報編集ページにおいて、購入者は再注文内容確認ページに表示されていた使用者状態情報を編集することができる。編集が終わると、注文内容受付部１４２は、再注文内容確認ページを購入者端末３へ送信する。確定ボタン２７５は、注文内容及び使用者状態情報を確定するためのボタンである。注文内容及び使用者状態情報の何れも編集せずに購入者が確定ボタン２７５を選択すると、注文内容受付部１４２は、キャンセルされた注文内容及びこの注文内容に関連付けられた使用者状態情報を注文ＤＢ１２ｅから取得する。そして、注文内容受付部１４２は、取得した注文内容及び使用者状態情報を含む新たな注文情報を注文ＤＢ１２ｅに登録する。注文内容が編集された場合、注文内容受付部１４２は、編集された注文内容と、キャンセルされた注文内容に関連付けられた使用者状態情報を含む注文情報を登録する。使用者状態情報が編集された場合、注文内容受付部１４２は、編集された使用者状態情報と、キャンセルされた注文内容を含む注文情報を登録する。注文内容及び使用者状態情報の両方が編集された場合、注文内容受付部１４２は、編集された情報を含む注文情報を登録する。
【０１５５】
なお、再注文における使用者状態情報に対して店舗の従業員が留意情報を入力する場合、メッセージ処理部１４３は、キャンセルされた注文内容に関連付けられた留意情報を店舗端末２に表示させてもよい。これにより、従業員は、前の留意情報を参照しながら再注文における留意情報を入力することができる。例えば、メッセージ処理部１４３は、メッセージ入力ページのメッセージ入力欄２４３に、キャンセルされた注文内容に関連付けられた留意情報を、予め入力された状態で表示させてもよい。
【０１５６】
［６−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図３６乃至図３８を用いて説明する。図３６は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の注文履歴送信処理の一例を示すフローチャートである。図３６において図１９と同様の処理については同様の符号が付されている。図３６に示すように、注文内容受付部１４２は、ステップＳ８１〜Ｓ８４を実行する。ステップＳ８４において、注文内容受付部１４２は、商品区分が指定医薬品ではないと判定した場合には（ステップＳ８４：ＮＯ）、ステップＳ８７に進む。一方、注文内容受付部１４２は、商品区分が指定医薬品であると判定した場合には（ステップＳ８４：ＮＯ）、ステップＳ１９１に進む。ステップＳ１９１において、注文内容受付部１４２は、ｉ番目の注文情報に含まれるキャンセルフラグがＴＲＵＥであるか否かを判定する。このとき、注文内容受付部１４２は、キャンセルフラグがＴＲＵＥではないと判定した場合には（ステップＳ１９１：ＮＯ）、ステップＳ８５に進む。一方、注文内容受付部１４２は、キャンセルフラグがＴＲＵＥであると判定した場合には（ステップＳ１９１：ＹＥＳ）、ステップＳ１９２に進む。ステップＳ１９２において、注文内容受付部１４２は、ｉ番目の注文情報について再注文ボタン２５４を表示するためのデータを、注文履歴ページのＨＴＭＬ文書に追加する。次いで、注文内容受付部１４２は、ステップＳ８７に進む。ステップＳ８５〜Ｓ８９の処理については、第１実施形態の場合と同様である。
【０１５７】
図３７は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文確認ページ送信処理の一例を示すフローチャートである。購入者端末３において注文履歴ページが表示されているとき、購入者が再注文ボタン２５４を選択すると、購入者端末３は、再注文確認要求を電子商店街サーバ１へ送信する。再注文確認要求は、選択された再注文ボタン２５４に対応する注文番号を含む。購入者端末３から再注文確認要求を受信したとき、システム制御部１４は再注文確認ページ送信処理を実行する。図３７に示すように、注文内容受付部１４２は、再注文確認要求に含まれる注文番号に対応する注文内容及び使用者状態情報を注文ＤＢ１２ｅから取得する（ステップＳ２０１）。また、注文内容受付部１４２は、記憶部１２からテンプレートとなる注文履歴ページのＨＴＭＬ文書を取得する。次いで、注文内容受付部１４２は、取得した注文内容及び使用者状態情報を、再注文確認ページのＨＴＭＬ文書に追加する（ステップＳ２０２）。次いで、注文内容受付部１４２は、注文履歴ページのＨＴＭＬ文書を購入者端末３を送信して（ステップＳ２０３）、再注文確認ページ送信処理を終了させる。
【０１５８】
図３８は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文内容登録処理の一例を示すフローチャートである。購入者端末３において再注文内容確認ページが表示されているとき、購入者が確定ボタン２７５を選択すると、購入者端末３は、再注文内容確定要求を電子商店街サーバ１へ送信する。再注文内容確定要求は、注文履歴ページから購入者が選択した再注文ボタン２５４に対応する注文番号を含む。注文内容が編集されている場合、再注文内容確定要求は編集後の注文内容を含み、注文内容が編集されていない場合、再注文内容確定要求は注文内容を含まない。使用者状態情報が編集されている場合、再注文内容確定要求は編集後の使用者状態情報を含み、使用者状態情報が編集されていない場合、再注文内容確定要求は使用者状態情報を含まない。購入者端末３から再注文内容確定要求を受信したとき、システム制御部１４は再注文内容登録処理を実行する。
【０１５９】
図３８に示すように、注文内容受付部１４２は、再注文内容確定要求が注文内容を含むか否かを判定する（ステップＳ２１１）。このとき、注文内容受付部１４２は、再注文内容確定要求が注文内容を含むと判定した場合には（ステップＳ２１１：ＹＥＳ）、ステップＳ２１３に進む。一方、注文内容受付部１４２は、再注文内容確定要求が注文内容を含まないと判定した場合には（ステップＳ２１１：ＮＯ）、ステップＳ２１２に進む。ステップＳ２１２において、注文内容受付部１４２は、再注文内容確定要求に含まれる注文番号に対応する注文内容を注文ＤＢ１２ｅから取得する。次いで、注文内容受付部１４２は、ステップＳ２１３に進む。ステップＳ２１３において、注文内容受付部１４２は、再注文内容確定要求に含まれる注文内容又はステップＳ２１２で取得した注文内容を含む注文情報を生成する。このとき、注文内容受付部１４２は、新しい注文番号を生成するとともに、現在日時を受付日時として取得する。
【０１６０】
次いで、注文内容受付部１４２は、再注文内容確定要求が使用者状態情報を含むか否かを判定する（ステップＳ２１４）。このとき、使用者状態情報受付部１４１は、再注文内容確定要求が使用者状態情報を含むと判定した場合には（ステップＳ２１４：ＹＥＳ）、ステップＳ２１６に進む。一方、使用者状態情報受付部１４１は、再注文内容確定要求が使用者状態情報を含まないと判定した場合には（ステップＳ２１４：ＮＯ）、ステップＳ２１５に進む。ステップＳ２１５において、使用者状態情報受付部１４１は、再注文内容確定要求に含まれる注文番号に対応する使用者状態情報を注文ＤＢ１２ｅから取得する。次いで、使用者状態情報受付部１４１は、ステップＳ２１６に進む。ステップＳ２１６において、使用者状態情報受付部１４１は、再注文内容確定要求に含まれる使用者状態情報又はステップＳ２１５で取得した使用者状態情報を、注文情報に追加する。
【０１６１】
次いで、注文内容受付部１４２は、注文情報に含まれる情報を設定する（ステップＳ２１７）。具体的に、注文内容受付部１４２は、商品区分を指定医薬品に設定する。また、注文内容受付部１４２は、発送ステータスを発送不可に設定し、決済ステータスを処理未完了に設定する。また、注文内容受付部１４２は、確認ステータスを店舗送信前に設定する。次いで、注文内容受付部１４２は、生成した注文情報を注文ＤＢ１２ｅに登録する（ステップＳ２１８）、次いで、注文内容受付部１４２は、注文内容受付通知メールを送信して（ステップＳ２１９）、再注文内容登録処理を終了させる。
【０１６２】
以上説明したように、本実施形態によれば、システム制御部１４が、受け付けがキャンセルされた注文内容の少なくとも一部を含む注文内容表示領域２５１と再注文ボタン２５４とを提示させる。また、システム制御部１４が、再注文ボタン２５４が操作されることに基づいて再注文のための注文内容が受け付けられる場合、受け付けがキャンセルされた注文内容に関連付けられた使用者状態情報を、再注文のための注文内容に関連付けられる使用者状態情報として取得する。そのため、再注文の際、購入者は使用者状態情報を再入力する手間を省くことができる。
【０１６３】
［７．第７実施形態］
［７−１．システム制御部の機能概要］
次に、第７実施形態におけるシステム制御部１４の機能について、図３９を用いて説明する。以下に説明する点を除き、第７実施形態は第６実施形態と基本的に同様である。本実施形態において、注文内容受付部１４２は、再注文において、キャンセルされた注文内容に関連付けられた使用者状態情報を受け付けるとき、使用者状態情報の各項目について、使用者の状態が変化する可能性がある状態であるか否かを判定する。注文内容受付部１４２は、本発明における有効日数取得手段、要求情報提示制御手段の一例である。使用者の状態が変化する可能性がある項目がある場合、注文内容受付部１４２は、キャンセルされた注文内容の受付日時からの経過日数に基づいて、該当する項目について使用者の状態を再入力を要求する情報を購入者端末３に提示させる。具体的に、注文内容受付部１４２は、経過日数が使用者状態情報の有効期間日数を超えていない場合、再入力を要求する情報を提示させず、経過日数が有効期間日数を超えている場合、再入力を要求する情報を提示させる。例えば項目の区分又は種類ごとに有効期間日数が設定される。或いは、項目ごとに有効期間日数が設定されてもよい。また、有効期間日数は、例えば情報処理システムにおいて予め定められていてもよいし、指定医薬品ごと又は店舗ごとに設定されてもよい。有効期間日数は、キャンセルされた注文内容が受け付けられたときにおける使用者の状態が現在まで継続している可能性に応じて設定されてもよい。例えば、状態が継続する期間が一般的に長い項目であるほど、有効期間日数が長くてもよい。これまでに説明した処理により、再注文における使用者状態情報の再入力の手間を減らしつつ、誤った使用者状態情報が登録されることを防止することができる。
【０１６４】
例えば、注文内容受付部１４２は、使用者の性別は変化しないと判定してもよい。また例えば、症状、妊娠の有無等は、変化する可能性がある。また例えば、注文商品を使用したことがあるという状態や、副作用歴があるという状態は、将来においても変化しない一方で、注文商品を使用したことがないという状態や、副作用歴がないという状態は、将来において変化する可能性がある。また例えば、６５才以上であるという状態は将来においても変化しない一方で、１５才未満であるという状態は変化する可能性がある。
【０１６５】
図３９は、再注文内容確認ページの表示例を示す図である。図３９において図３５と同様の要素については同様の符号が付されている。図３９に示すように、再注文内容確認ページには、注文内容表示領域２７１、使用者状態情報表示領域２７２、注文内容編集ボタン２７３、使用者状態情報編集ボタン２７４、確定ボタン２７５、及び使用者状態情報再入力領域２７６が表示される。本実施形態において、使用者状態情報表示領域２７２には、キャンセルされた注文内容に関連付けられた使用者状態情報のうち、変化しない状態、及び有効期間内である状態が表示される。使用者状態情報再入力領域２７６には、キャンセルされた注文内容に関連付けられた使用者状態情報のうち、有効期間を経過した状態についての質問と選択メニュー２７７とが表示される。また、使用者状態情報再入力領域２７６には、使用者状態情報再入力領域２７６に表示されている使用者状態情報の再入力を要求するメッセージが表示される。選択メニュー２７７は、質問に対する回答を選択するためのプルダウンメニューである。購入者は、選択メニュー２７７を操作することにより使用者の状態を選択する。そして、購入者が確定ボタン２７５を選択すると、購入者端末３は、使用者状態情報再入力領域２７６に表示された質問について、選択メニュー２７７の選択状態に応じた使用者状態情報を電子商店街サーバ１へ送信する。
【０１６６】
使用者の状態が変化する可能性がある状態であるのか、有効期間内であるのか否か等を判定するため、例えば電子商店街サーバ１の記憶部１２には、使用者状態質問ＤＢ１２ｇが構築されている。図４０は、使用者状態質問ＤＢ１２ｇに登録される内容の一例を示す図である。使用者状態質問ＤＢ１２ｇには、使用者の状態を質問するための質問内容、回答の選択肢、有効期間等が登録される。具体的に、使用者状態質問ＤＢ１２ｇには、状態項目ＩＤ、質問内容のテキスト、及び複数の選択肢情報が、使用者状態情報の項目ごとに対応付けて登録される。状態項目ＩＤは、使用者状態情報の項目の識別情報である。各選択肢情報は、回答の選択肢のテキスト、変化フラグ及び有効期間日数を含む。変化フラグは、選択肢のテキストが示す状態が変化する可能性があるか否かを示す。有効期間日数は、選択肢のテキストが示す状態が有効である日数である。例えば電子商店街サーバ１の管理者が、これらの情報を登録してもよい。店舗が使用者状態情報に対する質問を作成する場合、例えば店舗端末２からの要求に応じて電子商店街サーバ１は、質問作成ページを店舗端末２へ送信する。質問作成ページにおいて、店舗の従業員は、使用者状態質問ＤＢ１２ｇに登録されたテキストが示す質問内容を選択することができるとともに、使用者状態質問ＤＢ１２ｇに登録されたテキストが示す選択肢の中から、回答可能な選択肢を複数選択することができる。店舗端末２は、従業員に選択された内容を状態質問情報として電子商店街サーバ１へ送信し、電子商店街サーバ１は状態質問情報を商品ＤＢ１２ｃに登録する。
【０１６７】
なお、注文内容受付部１４２は、例えば変化する可能性がある状態が、キャンセルされた注文内容が受け付けられたときから再注文までに特定の状態に変化しているか否かを判定してもよい。そして、注文内容受付部１４２は、使用者の状態が特定の状態に変化していると判定した場合には、使用者状態情報を特定の状態に変更してもよい。この場合、注文内容受付部１４２は、使用者の状態を再入力を要求する情報を提示させない。一方、注文内容受付部１４２は、使用者の状態が特定の状態に変化しているとは限らないと判定した場合には、使用者の状態を再入力を要求する情報を提示させる。例えば、キャンセルされた注文内容が受け付けられたときに使用者の状態が、「出産予定日まで１２週以内である：はい」という状態であったとする。従って、再注文の注文内容の受け付け時点において１２週が経過している場合、既に出産が終わっている。この場合、注文内容受付部１４２は、この状態を、「出産予定日まで１２週以内である：いいえ」に変更する。そして、出産予定日まで１２週以内であるかという質問については、再入力を要求する情報を提示させない。一方、再注文の注文内容の受け付け時点において１２週が経過していない場合、使用者は出産しているかもしれないし、出産していないかもしれない。従って、注文内容受付部１４２は、再入力を要求する情報を提示させる。
【０１６８】
［７−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図４１及び図４２を用いて説明する。図４１は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文確認ページ送信処理の一例を示すフローチャートである。図４１において図３７と同様の要素については同様の符号が付されている。図４１に示すように、注文内容受付部１４２は、再注文確認要求に含まれる注文番号に対応する注文内容及び使用者状態情報を注文ＤＢ１２ｅから取得する（ステップＳ２０１）。次いで、注文内容受付部１４２は、取得した注文内容を、注再注文確認ページのＨＴＭＬ文書に追加する（ステップＳ２２１）。次いで、注文内容受付部１４２は、再注文確認要求に含まれる注文番号に対応する受付日時を注文ＤＢ１２ｅから取得する。そして、注文内容受付部１４２は、現在日時から受付日時を減算することにより、経過日数を計算する（ステップＳ２２２）。次いで、注文内容受付部１４２は、番号ｉを１に設定する（ステップＳ２２３）。
【０１６９】
次いで、注文内容受付部１４２は、取得した使用者状態情報におけるｉ番目の状態が変化する可能性があるか否かを判定する（ステップＳ２２４）。具体的に、注文内容受付部１４２は、使用者状態情報におけるｉ番目における質問内容と一致する質問内容を使用者状態質問ＤＢ１２ｇから検索し、検索された質問内容に関連付けられた選択肢のうち、使用者状態情報におけるｉ番目の回答と一致する選択肢を使用者状態質問ＤＢ１２ｇから検索する。次いで、注文内容受付部１４２は、検索した選択肢に対応する変化フラグ及び有効期間日数を取得する。注文内容受付部１４２は、変化フラグがＦＡＬＳＥである場合には、ｉ番目の状態が変化する可能性はないと判定する（ステップＳ２２４：ＮＯ）。この場合、注文内容受付部１４２は、ステップＳ２２８に進む。一方、注文内容受付部１４２は、変化フラグがＴＲＵＥである場合には、ｉ番目の状態が変化する可能性があると判定する（ステップＳ２２４：ＹＥＳ）。この場合、注文内容受付部１４２は、ステップＳ２２５に進む。
【０１７０】
ステップＳ２２５において、注文内容受付部１４２は、経過日数が有効期間日数未満であるか否かを判定する。このとき、注文内容受付部１４２は、経過日数が有効期間日数未満であると判定した場合には（ステップＳ２２５：ＹＥＳ）、ステップＳ２２６に進む。ステップＳ２２６において、注文内容受付部１４２は、使用者状態情報におけるｉ番目の質問及び回答のテキストを再注文確認ページのＨＴＭＬ文書の使用者状態情報表示領域２７２に追加する。次いで、注文内容受付部１４２は、ステップＳ２２８に進む。一方、注文内容受付部１４２は、経過日数が有効期間日数未満ではないと判定した場合には（ステップＳ２２５：ＮＯ）、ステップＳ２２７に進む。ステップＳ２２７において、注文内容受付部１４２は、使用者状態情報におけるｉ番目の質問のテキストと、選択メニュー２７７を表示するためのデータとを再注文確認ページのＨＴＭＬ文書の使用者状態情報再入力領域２７６に追加する。このとき、注文内容受付部１４２は、再注文確認要求に含まれる注文番号に対応する店舗ＩＤ及び商品ＩＤを注文ＤＢ１２ｅから取得し、店舗ＩＤ及び商品ＩＤに対応する状態質問情報を商品ＤＢ１２ｃから取得する。そして、注文内容受付部１４２は、状態質問情報に基づいてデータを追加する。次いで、注文内容受付部１４２は、ステップＳ２２８に進む。
【０１７１】
ステップＳ２２８において、注文内容受付部１４２は、番号ｉが、使用者状態情報に含まれる質問の数と一致するか否かを判定する。このとき、注文内容受付部１４２は、番号ｉが質問の数と一致しないと判定した場合には（ステップＳ２２８：ＮＯ）、ステップＳ２２９に進む。ステップＳ２２９において、注文内容受付部１４２は、番号ｉに１を加算して、ステップＳ２２４に進む。一方、注文内容受付部１４２は、番号ｉが質問の数と一致すると判定した場合には（ステップＳ２２８：ＹＥＳ）、ステップＳ２０３に進む。ステップＳ２０３において、注文内容受付部１４２は、注文履歴ページのＨＴＭＬ文書を購入者端末３を送信して、再注文確認ページ送信処理を終了させる。
【０１７２】
図４２は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の再注文内容登録処理の一例を示すフローチャートである。図４２において図３８と同様の要素については同様の符号が付されている。図３８に示すように、注文内容受付部１４２は、ステップＳ２１１〜Ｓ２１３を実行する。次いで、注文内容受付部１４２は、再注文内容確定要求に含まれる注文番号に対応する使用者状態情報を注文ＤＢ１２ｅから取得する（ステップＳ２３１）。次いで、注文内容受付部１４２は、再注文内容確定要求が使用者状態情報を含むか否かを判定する（ステップＳ２３２）。このとき、使用者状態情報受付部１４１は、再注文内容確定要求が使用者状態情報を含むと判定した場合には（ステップＳ２３２：ＹＥＳ）、ステップＳ２３３に進む。ステップＳ２３３において、注文内容受付部１４２は、再注文内容確定要求に含まれる使用者状態情報で、注文ＤＢ１２ｅから取得した使用者状態情報を更新する。具体的に、注文内容受付部１４２は、再注文内容確定要求に含まれる使用者状態情報に含まれる質問内容と一致する質問内容を、注文ＤＢ１２ｅから取得した使用者状態情報から検索する。次いで、注文内容受付部１４２は、検索された注文内容に対応する回答を、再注文内容確定要求に含まれる使用者状態情報に含まれる回答で書き換える。注文内容受付部１４２は、このような処理を、再注文内容確定要求に含まれる使用者状態情報に含まれる質問内容ごとに実行する。次いで、注文内容受付部１４２は、ステップＳ２１６に進む。一方、注文内容受付部１４２は、再注文内容確定要求が使用者状態情報を含まないと判定した場合には（ステップＳ２３２：ＮＯ）、ステップＳ２１６に進む。
【０１７３】
ステップＳ２１６において、注文内容受付部１４２は、注文ＤＢ１２ｅから取得した使用者状態情報、又はステップＳ２３３で更新された使用者状態情報を注文情報に追加する。次いで、注文内容受付部１４２は、ステップＳ２１７〜Ｓ２１９を実行する。
【０１７４】
以上説明したように、本実施形態によれば、システム制御部１４が、受け付けがキャンセルされた注文内容に関連付けられた使用者状態情報が変化する可能性がある情報である場合、この使用者状態情報の有効期間日数を取得する。また、システム制御部１４が、受け付けがキャンセルされた注文内容が受け付けられてから再注文ボタン２５４が操作されるまでの経過日数が有効期間日数を超える場合、再注文内容確認ページに使用者状態情報再入力領域２７６を表示させる。そのため、使用者状態情報を再入力する手間を省くことも可能としつつ、再入力が行われないことによる誤った使用者状態情報が記憶されることを防止することができる。
【０１７５】
［８．第８実施形態］
［８−１．システム制御部の機能概要］
次に、第８実施形態におけるシステム制御部１４の機能について、図４３を用いて説明する。以下に説明する点を除き、第８実施形態は第５実施形態〜第７実施形態と基本的に同様である。第５実施形態で説明したように、確認期間日数が経過するまでに購入者が留意事項を確認していないと、キャンセル処理部１４７は、注文内容の受け付けをキャンセルにする。第５実施形態においては確認期間日数は予め定められていた。本実施形態において、キャンセル処理部１４７は、購入者により注文商品の配送時期（発送日又は発送日時）が指定されている場合、指定された配送時期までに注文商品を配送可能なように、確認期間を設定する。キャンセル処理部１４７は、本発明における発送期限取得手段、確認期限決定手段の一例である。購入者により注文商品の配送時期が指定されている場合、店舗は注文商品を配送時期までに配送されるように、発送する必要がある。配送時期までに注文商品を配送可能な最も遅い発送時期（発送日又は発送日時）を発送期限という。従って、店舗が配送時期までに注文商品を発送するまでには、遅くとも発送期限までに購入者は留意事項を確認する必要がある。配送時期までに注文商品を配送可能な最も遅い留意事項の確認時期を（確認日又は確認日時）、確認期限という。キャンセル処理部１４７は、例えば発送期限に基づいて確認期限を設定してもよい。例えば、キャンセル処理部１４７は、発送期限と同一の日を確認期限と決定してもよいし、発送期限の前日又は２日以上前の日を確認期限と決定してもよい。
【０１７６】
確認期限を設定するため、例えば電子商店街サーバ１の記憶部１２には、配送日数ＤＢ１２ｈが構築されている。図４３は、配送日数ＤＢ１２ｈに登録される内容の一例である。配送日数ＤＢ１２ｈは、商品の配送に要する日数が登録される。具体的に、配送日数ＤＢ１２ｈには、配送元地域、配送先地域及び配送日数が、配送元地域と配送先地域との組み合わせごとに対応付けて登録される。配送元地域は、商品の発送元の地域である。配送先地域は、商品の発送先の地域である。配送元地域及び発送先地域は、例えば都道府県であってもよい。配送日数は、配送元地域から発送先地域までの商品の配送に要する日数を示す。例えば電子商店街サーバ１の管理者が配送日数を設定してもよい。また例えば、電子商店街サーバ１が過去の実績に基づいて配送日数を設定してもよい。例えば、各店舗が実際の発送日と配送日と入力し、電子商店街サーバ１は、発送日及び配送日に基づいて配送日数を計算し、これらの配送日数に基づいて、配送日数ＤＢ１２ｈに登録する配送日数を決定してもよい。また例えば、電子商店街サーバ１は、配送管理サーバ７から過去における店舗からの商品の受入日及び配送日を、配送元地域及び発送先地域の組み合わせごとに取得して、配送日数ＤＢ１２ｈに登録する配送日数を決定してもよい。
【０１７７】
［８−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図４４を用いて説明する。図４４は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の自動キャンセル処理の一例を示すフローチャートである。図４４において図３３と同様の処理については同様の符号が付されている。図４４に示すように、キャンセル処理部１４７は、ステップＳ１７１〜Ｓ１７３を実行する。ステップＳ１７３において、キャンセル処理部１４７は、留意情報が登録されていないと判定した場合には（ステップＳ１７３：ＮＯ）、ステップＳ１７９に進む。一方、キャンセル処理部１４７は、留意情報が登録されていると判定した場合には（ステップＳ１７３：ＹＥＳ）、ステップＳ２４１に進む。
【０１７８】
ステップＳ２４１において、キャンセル処理部１４７は、ｉ番目の注文情報に含まれる配送日時指定フラグがＴＲＵＥであるか否かを判定する。このとき、キャンセル処理部１４７は、配送日時指定フラグがＴＲＵＥではないと判定した場合には（ステップＳ２４１：ＮＯ）、ステップＳ１７４に進む。そして、キャンセル処理部１４７は、ステップＳ１７４〜Ｓ１７６を実行し、Ｓ１７６に判定結果に基づいて、ステップＳ１７７又はステップＳ１７９に進む。一方、キャンセル処理部１４７は、配送日時指定フラグがＴＲＵＥであると判定した場合には（ステップＳ２４１：ＹＥＳ）、ステップＳ２４２に進む。
【０１７９】
ステップＳ２４２において、キャンセル処理部１４７は、発送期限を決定する。具体的に、キャンセル処理部１４７は、ｉ番目の注文情報から店舗ＩＤ及びユーザＩＤ取得する。次いで、キャンセル処理部１４７は、店舗ＩＤに対応する住所を店舗ＤＢ１２ｂから取得して、この住所に対応する発送元地域を特定する。また、キャンセル処理部１４７は、ユーザＩＤに対応する住所を会員ＤＢ１２ａから取得して、この住所に対応する発送先地域を特定する。次いで、キャンセル処理部１４７は、特定した発送元地域及び発送先地域の組み合わせに対応する配送日数を配送日数ＤＢ１２ｈから取得する。次いで、キャンセル処理部１４７は、ｉ番目の注文情報に含まれる指定配送日時から配送日数を減算して、発送期限を計算する。
【０１８０】
次いで、キャンセル処理部１４７は、発送期限に基づいて確認期限を決定する（ステップＳ２４３）。例えば、キャンセル処理部１４７は、発送期限と同一の期限を確認期限に決定してもよい。また例えば、キャンセル処理部１４７は、記憶部１２に予め記憶されている日数を発送期限から減算して、確認期限を計算してもよい。記憶部１２に記憶される日数は、例えば０日以上であればよい。次いで、キャンセル処理部１４７は、現在日時が確認期限よりも遅いか否かを判定する（ステップＳ２４４）。このとき、キャンセル処理部１４７は、現在日時が確認期限よりも遅いと判定した場合には（ステップＳ２４４：ＹＥＳ）、ステップＳ１７７に進む。そして、キャンセル処理部１４７は、キャンセルフラグをＴＲＵＥに設定し（ステップＳ１７７）、自動キャンセル通知メールを送信して（ステップＳ１７８）、ステップＳ１７９に進む。一方、キャンセル処理部１４７は、現在日時が確認期限よりも遅くはないと判定した場合には（ステップＳ２４４：ＮＯ）、ステップＳ１７９に進む。キャンセル処理部１４７は、ステップＳ１７９〜Ｓ１８１を実行する。
【０１８１】
なお、キャンセル処理部１４７は、例えば図１６に示す注文内容登録処理において確認期限を決定し、確認期限を注文情報に登録してもよい。そして、キャンセル処理部１４７は、自動キャンセル処理において、注文情報から確認期限を取得して判定を行ってもよい。
【０１８２】
以上説明したように、本実施形態によれば、システム制御部１４が、購入者から受け付けられた注文内容が配送日の指定を含む場合、この配送日に商品を配達するための発送期限を取得する。また、システム制御部１４が、発送期限に基づいて、留意情報の確認期限を決定する。また、システム制御部１４が、決定された確認期限までに購入者メッセージが受け付けられなかった場合、注文内容の受け付けをキャンセルする。従って、留意情報の確認期間を適切に設定することができる。
【０１８３】
［９．第９実施形態］
［９−１．システム制御部の機能概要］
次に、第９実施形態におけるシステム制御部１４の機能について、図４５を用いて説明する。以下に説明する点を除き、第９実施形態は第１実施形態〜第８実施形態と基本的に同様である。図４５は、本実施形態に係る宿泊施設予約サーバ１のシステム制御部１４の機能ブロックの一例を示す図である。図４５において図３（ｂ）と同様の要素については同様の符号が付されている。図４５に示すように、システム制御部１４は、使用者状態情報受付部１４１、注文内容受付部１４２、メッセージ処理部１４３、メッセージ処理部１４３、ステータス制御部１４４、受注情報提供部１４５、注文履歴提供部１４６、リマインド処理部１４８等として機能する。リマインド処理部１４８は、本発明における回数取得手段及び時間間隔決定手段の一例である。
【０１８４】
リマインド処理部１４８は、留意情報が登録されたことを購入者に通知する店舗メッセージ登録通知メールが登録された後、留意情報を確認したことを示す購入者メッセージが受け付けられていない場合、留意情報の確認を購入者に促す情報を出力する。具体的に、リマインド処理部１４８は、このような情報として購入者宛ての留意情報確認リマインドメールを送信する。リマインドメールは、本発明におけるリマインド情報の一例である。
【０１８５】
特に本実施形態において、リマインド処理部１４８は、留意情報確認リマインドメールを所定の時間間隔ごとに送信する。更にリマインド処理部１４８は、店舗メッセージ登録通知メールが登録された後、留意情報を確認したことを示す購入者メッセージが受け付けられるまでに送信された留意情報確認リマインドメールの数に基づいて、留意情報確認リマインドメールを送信する時間間隔を決定する。購入者メッセージが受け付けられるまでに送信された留意情報確認リマインドメールの数を、リマインド回数という。留意情報確認リマインドメールを送信する時間間隔を、リマインド時間間隔という。リマインド時間間隔のデフォルト値は、例えば電子商店街サーバ１の管理者により予め設定されていてもよい。例えば、デフォルト値は、所定時間であってもよいし、所定日数であってもよい。
【０１８６】
例えば、デフォルト値が１日であるとする。留意情報確認リマインドメールが３回送信された後に、購入者が留意情報を確認した場合、１通目及び２通目の留意情報確認リマインドメールは送信する必要がなかった蓋然性がある。そこで、リマインド処理部１４８は、例えばリマインド時間間隔を３日に変更する。また、リマインド時間間隔を短くすることも可能である。このように、購入者が留意情報確認リマインドメールに基づき留意情報を確認する蓋然性があるタイミングに合わせてリマインド処理部１４８がリマインド時間間隔を決定することで、リマインド処理部１４８による無駄な送信処理を削減し又は送信処理の効率を高めることができる。
【０１８７】
留意情報確認リマインドメールの送信タイミングを決定するために、例えば会員ＤＢ１２ａには、購入者ごとの現在のリマインド時間間隔が更に登録される。当初、リマインド時間間隔にはデフォルト値が設定されている。また、例えば注文ＤＢ１２ｅには、次回リマインド日時、及びリマインド回数が更に登録される。次回リマインド日時は、次に留意情報確認リマインドメールが送信される日時を示す。
【０１８８】
［８−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図４６乃至図４８を用いて説明する。図４６は、本実施形態に係る電子商店街サーバ１のシステム制御部１４のリマインド時間間隔決定処理の一例を示すフローチャートである。例えば、図２０に示す購入者メッセージ登録処理において確認ステータスが確認完了に設定された場合、システム制御部１４はリマインド時間間隔決定処理を実行してもよい。図４６に示すように、リマインド処理部１４８は、確認ステータスが確認完了に設定された注文情報からユーザＩＤを取得する。そして、リマインド処理部１４８は、注文ＤＢ１２ｅから、取得したユーザＩＤに対応する注文情報のうち、商品区分が指定医薬品、確認ステータスが確認完了である注文情報を検索する（ステップＳ２６１）。次いで、リマインド処理部１４８は、注文情報が見つかったか否かを判定する（ステップＳ２６２）。このとき、リマインド処理部１４８は、注文情報が見つからなかったと判定した場合には（ステップＳ２６２：ＮＯ）、ステップＳ２６３に進む。ステップＳ２６３において、リマインド処理部１４８は、リマインド時間間隔をデフォルト値に設定して、ステップＳ２６６に進む。一方、リマインド処理部１４８は、注文情報が見つかったと判定した場合には（ステップＳ２６２：ＹＥＳ）、ステップＳ２６４に進む。
【０１８９】
ステップＳ２６４において、リマインド処理部１４８は、見つかった注文情報の数が、記憶部１２に予め記憶されている設定値と一致するか否かを判定する。このとき、リマインド処理部１４８は、注文情報の数が設定値と一致しないと判定した場合には（ステップＳ２６４：ＮＯ）、リマインド時間間隔決定処理を終了させる。一方、リマインド処理部１４８は、注文情報の数が設定値と一致すると判定した場合には（ステップＳ２６４：ＹＥＳ）、ステップＳ２６５に進む。ステップＳ２６５において、リマインド処理部１４８は、見つかった注文情報のそれぞれから過去のリマインド回数を取得する。そして、リマインド処理部１４８は、過去のリマインド回数に基づいて、リマインド時間間隔を決定する。例えば、リマインド処理部１４８は、過去のリマインド回数の最頻値又は平均値等の代表値にデフォルト値を掛けて、リマインド時間間隔を計算してもよい。ここで、代表値が０である場合、リマインド処理部１４８は、例えば、リマインド時間間隔をデフォルト値のままにしてもよいし、リマインド時間間隔をデフォルト値よりも短くしてもよい。リマインド処理部１４８は、ステップＳ２６５を終えると、ステップＳ２６６に進む。ステップＳ２６６において、リマインド処理部１４８は、設定したリマインド時間間隔を、取得したユーザＩＤに対応付けて会員ＤＢ１２ａに登録する。リマインド処理部１４８は、ステップＳ２６６を終えると、リマインド時間間隔決定処理を終了させる。
【０１９０】
図４７は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。図４７において図１８と同様の処理については同様の符号が付されている。図４７に示すように、メッセージ処理部１４３は、ステップＳ７１〜Ｓ７４を実行する。次いで、リマインド処理部１４８は、今回設定したメッセージ番号が１であるか否かを判定する（ステップＳ２７１）。すなわち、リマインド処理部１４８は、今回留意情報を登録したか否かを判定する。このとき、リマインド処理部１４８は、メッセージ番号が１ではないと判定した場合には（ステップＳ２７１：ＮＯ）、店舗メッセージ登録処理を終了させる。一方、リマインド処理部１４８は、メッセージ番号が１であると判定した場合には（ステップＳ２７１：ＹＥＳ）、ステップＳ２７２に進む。ステップＳ２７２において、リマインド処理部１４８は、店舗端末２から受信した注文番号に対応するユーザＩＤを注文ＤＢ１２ｅから取得する。そして、リマインド処理部１４８は、ユーザＩＤに対応するリマインド時間間隔を会員ＤＢ１２ａから取得する。次いで、リマインド処理部１４８は、現在日時にリマインド時間間隔を加算して、次回リマインド日時を計算する（ステップＳ２７３）。そして、リマインド処理部１４８は、受信した注文番号に対応付けて次回リマインド日時を注文ＤＢ１２ｅに登録する。また、リマインド処理部１４８は、０に設定されたリマインド回数を、注文番号に対応付けて注文ＤＢ１２ｅに登録する（ステップＳ２７４）。リマインド処理部１４８は、ステップＳ２７４を終えると、店舗メッセージ登録処理を終了させる。
【０１９１】
図４８は、本実施形態に係る電子商店街サーバ１のシステム制御部１４のリマインドメール送信処理の一例を示すフローチャートである。例えば、システム制御部１４は定期的にリマインドメール送信処理を実行する。例えば、システム制御部１４は、所定時間ごとにリマインドメール送信処理を実行してもよい。
【０１９２】
図４８に示すように、リマインド処理部１４８は、注文ＤＢ１２ｅから、商品区分が指定医薬品、確認ステータスが確認未完了であり、且つキャンセルフラグがＦＡＬＳＥである注文情報を検索する（ステップＳ２８１）。次いで、リマインド処理部１４８は、番号ｉを１に設定する（ステップＳ２８２）。次いで、リマインド処理部１４８は、検索された注文情報のうちｉ番目の注文情報から次回リマインド日時を取得する。そして、リマインド処理部１４８は、現在日時が次回リマインド日時よりも遅いか否かを判定する（ステップＳ２８３）。このとき、リマインド処理部１４８は、現在日時が次回リマインド日時よりも遅くはないと判定した場合には（ステップＳ２８３：ＮＯ）、ステップＳ２８８に進む。一方、リマインド処理部１４８は、現在日時が次回リマインド日時よりも遅いと判定した場合には（ステップＳ２８３：ＹＥＳ）、ステップＳ２８４に進む。
【０１９３】
ステップＳ２８４において、リマインド処理部１４８は、留意情報確認リマインドメールを送信する。具体的に、リマインド処理部１４８は、ｉ番目の注文情報に含まれるユーザＩＤに対応する電子メールアドレスを会員ＤＢ１２ａから取得する。そして、リマインド処理部１４８は、取得した電子メールアドレスを宛先アドレスに格納した留意情報確認リマインドメールを生成する。また、リマインド処理部１４８は、ｉ番目の注文情報に基づいて、注文番号、商品名等を留意情報確認リマインドメールの本文に追加する。そして、リマインド処理部１４８は、生成した留意情報確認リマインドメールを送信する。
【０１９４】
次いで、リマインド処理部１４８は、ｉ番目の注文情報に含まれるユーザＩＤに対応するリマインド時間間隔を会員ＤＢ１２ａから取得する（ステップＳ２８５）。次いで、リマインド処理部１４８は、取得した次回リマインド日時にリマインド時間間隔を加算して、新しい次回リマインド日時を計算する。そして、リマインド処理部１４８は、ｉ番目の注文情報に含まれる次回リマインド日時を新しい次回リマインド日時で更新する（ステップＳ２８６）。次いで、リマインド処理部１４８は、ｉ番目の注文情報に含まれるリマインド回数に１を加算して新しいリマインド回数を計算する。そして、リマインド処理部１４８は、ｉ番目の注文情報に含まれるリマインド回数を新しいリマインド回数で更新する（ステップＳ２８７）。次いで、リマインド処理部１４８は、ステップＳ２８８に進む。
【０１９５】
ステップＳ２８８において、リマインド処理部１４８は、番号ｉが、検索された注文情報の数と一致するか否かを判定する。このとき、リマインド処理部１４８は、番号ｉが注文情報の数と一致しないと判定した場合には（ステップＳ２８８：ＮＯ）、ステップＳ２８９に進む。ステップＳ２８９において、リマインド処理部１４８は、番号ｉに１を加算して、ステップＳ２８３に進む。一方、リマインド処理部１４８は、番号ｉが注文情報の数と一致すると判定した場合には（ステップＳ２８８：ＹＥＳ）、リマインドメール送信処理を終了させる。
【０１９６】
なお、図４６に示すリマインド時間間隔決定処理では、リマインド処理部１４８は、購入者が留意情報を確認したことがある注文の数が設定値と一致する場合にのみ、すなわち１回のみリマインド時間間隔を決定している。しかしながら、リマインド処理部１４８は、例えば購入者が留意情報を確認したことがある注文の数に関わらず、毎回リマインド時間間隔を決定してもよい。この場合、リマインド処理部１４８は、過去のリマインド回数に加え、その当時のリマインド時間間隔を用いて新しいリマインド時間間隔を決定する必要がある。その理由は、当時のリマインド時間間隔がデフォルト値とは異なっている場合があるからである。具体的に、図４７に示す店舗メッセージ登録処理において、リマインド処理部１４８は、会員ＤＢ１２ａから取得したリマインド時間間隔を（ステップＳ２７２）、注文情報に登録する。図４６に示すリマインド時間間隔決定処理において、リマインド処理部１４８は、見つかった注文情報ごとに、過去のリマインド回数にその当時のリマインド時間間隔を掛けて、留意情報未確認時間を計算する。そして、リマインド処理部１４８は、例えば、留意情報未確認時間の最頻値又は平均値等の代表値を、リマインド時間間隔に決定してもよい。
【０１９７】
以上説明したように、本実施形態によれば、システム制御部１４が、店舗メッセージ登録通知メールが出力された後、購入者メッセージが受け付けられるまでに留意情報確認リマインドメールが出力された回数を取得する。また、システム制御部１４が、留意情報確認リマインドメールを出力する時間間隔を、取得された回数に応じて決定する。そのため、留意情報確認リマインドメールを効率的に出力することができる。
【０１９８】
［１０．第１０実施形態］
［１０−１．システム制御部の機能概要］
次に、第１０実施形態におけるシステム制御部１４の機能について説明する。以下に説明する点を除き、第１０実施形態は第９実施形態と基本的に同様である。本実施形態において、リマインド処理部１４８は、留意情報を確認したことを示す購入者メッセージが受け付けられた時間に基づいて、留意情報確認リマインドメールを送信するタイミングを決定する。リマインド処理部１４８は、本発明における時間取得手段の一例である。例えば、リマインド処理部１４８は、購入者が留意情報を確認する傾向がある時間帯を特定し、その時間帯の前に留意情報確認リマインドメールを送信する。これにより、購入者が留意情報を確認する蓋然性を高めることができる。例えば、時間帯の長さは予め設定されている。会員ＤＢ１２ａには、購入者ごとのリマインド時刻が更に登録される。リマインド時刻は、留意情報確認リマインドメールが送信される時刻である。
【０１９９】
［１０−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図４９及び図５０を用いて説明する。図４９は、本実施形態に係る電子商店街サーバ１のシステム制御部１４のリマインド時間間隔決定処理の一例を示すフローチャートである。図４９において図４６と同様の処理については同様の符号が付されている。図４９に示すように、リマインド処理部１４８は、ステップＳ２６１〜Ｓ２６６を実行する。次いで、リマインド処理部１４８は、見つかった注文情報のそれぞれから注文番号を取得する。次いで、リマインド処理部１４８は、取得した注文番号ごとに、メッセージＤＢ１２ｆから、注文番号に対応する購入者送信日時のうち最も遅い購入者送信日時を、確認完了日時として取得する（ステップＳ３０１）。次いで、リマインド処理部１４８は、１日を分割した複数の時間帯のうち、最も多くの確認完了日時を含む時間帯を特定する（ステップＳ３０２）。次いで、リマインド処理部１４８は、特定した時間帯の直前の時間帯の開始時刻を、リマインド時刻に決定する（ステップＳ３０３）。次いで、リマインド処理部１４８は、確認ステータスが確認完了に設定された注文情報から取得したユーザＩＤに対応付けて、リマインド時刻を会員ＤＢ１２ａに登録する（ステップＳ３０４）。リマインド処理部１４８は、ステップＳ３０４を終えるとリマインド時間間隔決定処理を終了させる。
【０２００】
図５０は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。図５０において図４７と同様の処理については同様の符号が付されている。図５０に示すように、メッセージ処理部１４３は、ステップＳ７１〜Ｓ７４を実行し、リマインド処理部１４８は、ステップＳ２７１〜Ｓ２７３を実行する。次いで、リマインド処理部１４８は、注文ＤＢ１２ｅから取得したユーザＩＤに対応する会員情報を会員ＤＢ１２ａから特定し、会員情報にリマインド時刻が登録されているか否かを判定する（ステップＳ３１１）。このとき、リマインド処理部１４８は、リマインド時刻が登録されていると判定した場合には（ステップＳ３１１：ＹＥＳ）、ステップＳ３１２に進む。ステップＳ３１２において、リマインド処理部１４８は、計算した次回リマインド日時に含まれる時刻を、リマインド時刻に変更する。そして、リマインド処理部１４８は、変更された次回リマインド日時を、受信した注文番号に対応付けて次回リマインド日時を注文ＤＢ１２ｅに登録する。次いで、リマインド処理部１４８は、ステップＳ２７４に進む。
【０２０１】
なお、リマインド処理部１４８は、リマインド時間間隔ごとに留意情報確認リマインドメールを送信しなくてもよい。例えば、リマインド処理部１４８は、留意情報が登録されたことを通知する店舗メッセージ登録通知メールの送信から所定日数後、注文内容が自動的にキャンセルされる所定日数前、所定の曜日、又は所定の日等に留意情報確認リマインドメールを送信してもよい。この場合、リマインド処理部１４８は、決定したリマインド時刻に留意情報確認リマインドメールを送信すればよい。
【０２０２】
以上説明したように、本実施形態によれば、ステム制御部１４が、留意情報確認リマインドメールを出力する時間を、購入者メッセージが受け付けられた時間に応じて決定する。そのため、購入者が留意情報を確認する蓋然性を高めることができる。
【０２０３】
［１１．第１１実施形態］
［１１−１．システム制御部の機能概要］
次に、第１１実施形態におけるシステム制御部１４の機能について説明する。以下に説明する点を除き、第１１実施形態は第１実施形態〜第８実施形態と基本的に同様である。本実施形態において、システム制御部１４は、第９実施形態と同様に、使用者状態情報受付部１４１、注文内容受付部１４２、メッセージ処理部１４３、メッセージ処理部１４３、ステータス制御部１４４、受注情報提供部１４５、注文履歴提供部１４６、リマインド処理部１４８等として機能する。しかしながら、リマインド処理１４８は、第９実施形態とは異なる方法で留意情報確認リマインドメールを送信するタイミングを決定する。リマインド処理部１４８は、本発明における商品数取得手段の一例である。
【０２０４】
具体的に、リマインド処理部１４８は、指定医薬品ごとに、注文内容が受け付けられている指定医薬品のうち、発送が完了していない指定医薬品の数に応じて、留意情報確認リマインドメールを送信する頻度を決定する。この頻度をリマインド頻度という。発送が完了していない商品の数を、未発送注文商品数という。リマインド処理部１４８は、例えば未発送注文商品数が多いほどリマインド頻度を高くしてもよい。リマインド頻度が高くなるほど、購入者が留意情報を確認する蓋然性が高くなる。購入者が留意情報を確認し、支払いに関する処理が完了すれば、店舗は商品を発送することができる。従って、リマインド処理部１４８がリマインド頻度を高くすることにより、店舗としては未発送注文商品数を減らすことができる。
【０２０５】
また、リマインド処理部１４８は、例えば未発送注文商品数と在庫数とに基づいてリマインド頻度を決定してもよい。例えば、リマインド処理部１４８は、在庫数に対する未発送注文商品数の割合が大きいほど、リマインド頻度を高くする。これにより、発送されていない注文商品で在庫が圧迫されることを解消することができる。
【０２０６】
［１１−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図５１を用いて説明する。なお、以下の例では、リマインド頻度をリマインド時間間隔で表している。図５１は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の店舗メッセージ登録処理の一例を示すフローチャートである。図５１において図１８と同様の処理については同様の符号が付されている。図５１に示すように、メッセージ処理部１４３は、ステップＳ７１〜Ｓ７４を実行する。次いで、リマインド処理部１４８は、今回設定したメッセージ番号が１であるか否かを判定する（ステップＳ３２１）。このとき、リマインド処理部１４８は、メッセージ番号が１ではないと判定した場合には（ステップＳ３２１：ＮＯ）、店舗メッセージ登録処理を終了させる。一方、リマインド処理部１４８は、メッセージ番号が１であると判定した場合には（ステップＳ３２１：ＹＥＳ）、ステップＳ３２２に進む。
【０２０７】
ステップＳ３２２において、リマインド処理部１４８は、店舗端末２から受信した注文番号に対応する店舗ＩＤ及び商品ＩＤを注文ＤＢ１２ｅから取得する。次いで、リマインド処理部１４８は、店舗ＩＤ及び商品ＩＤの組み合わせに対応する注文情報を注文ＤＢ１２ｅから検索する。次いで、リマインド処理部１４８は、検索された注文情報から発送ステータスが発送完了ではない注文情報を抽出する。次いで、リマインド処理部１４８は、抽出した注文情報のそれぞれから商品の個数を取得する。そして、リマインド処理部１４８は、商品の個数の合計を未発送注文商品数として計算する（ステップＳ３２３）。次いで、リマインド処理部１４８は、店舗ＩＤ及び商品ＩＤの組み合わせに対応する在庫数を商品ＤＢ１２ｃから取得する。そして、リマインド処理部１４８は、在庫数に対する未発送注文商品数の割合を計算する（ステップＳ３２４）。次いで、リマインド処理部１４８は、計算した割合に応じてリマインド時間間隔を決定する（ステップＳ３２５）。具体的に、リマインド処理部１４８は、割合が大きいほどリマインド時間間隔を短くする。例えば、割合ごとに、割合とリマインド時間間隔とを対応付けて格納するテーブルが記憶部１２に記憶されていてもよい。そして、リマインド処理部１４８は、このテーブルに基づいてリマインド時間間隔を決定してもよい。次いで、リマインド処理部１４８は、現在日時にリマインド時間間隔を加算して、次回リマインド日時を計算する（ステップＳ３２６）。そして、リマインド処理部１４８は、受信した注文番号に対応付けて次回リマインド日時を注文ＤＢ１２ｅに登録する。リマインド処理部１４８は、ステップＳ３２６を終えると、店舗メッセージ登録処理を終了させる。本実施形態においても、リマインド処理部１４８は、図４７に示すリマインドメール送信処理を実行すればよい。
【０２０８】
以上説明したように、本実施形態によれば、システム制御部１４が、注文商品が指定医薬品である場合、この商品についてこれまでに受け付けられている１以上の注文内容のうち発送が完了していない注文内容に応じた未発送注文商品数を取得する。また、システム制御部１４が、留意情報確認リマインドメールを出力する頻度を、未発送注文商品数が多いほど高くする。そのため、購入者が留意情報を確認しないために店舗が発送することができない商品の数を減らすことができる。
【０２０９】
［１２．第１２実施形態］
［１２−１．システム制御部の機能概要］
次に、第１２実施形態におけるシステム制御部１４の機能について、図５２を用いて説明する。以下に説明する点を除き、第１１実施形態は第１実施形態〜第１１実施形態と基本的に同様である。本実施形態において、注文内容受付部１４２は、何れかの商品について注文内容受付完了ページを購入者端末３へ送信するときに、購入者から指定医薬品について過去に受け付けられた注文内容に関連付けられた確認ステータスが確認未完了である場合、留意情報の確認を促す情報を注文内容受付完了ページに提示させる。これにより、購入者にとって邪魔にならないタイミングで、留意情報の確認することを購入者に思い出させることができる。注文内容受付部１４２は、本発明における受付情報提示制御手段の一例である。
【０２１０】
図５２は、注文内容受付完了ページの表示例を示す図である。図５２に示すように、注文内容受付完了ページには、注文内容が受け付けられたことを示すメッセージ２８１が表示される。メッセージ２８１は、本発明における受け付け情報の一例である。購入者が留意情報の確認を完了していない注文商品がある場合、注文内容受付完了ページには、更に留意情報の確認を促すメッセージ２８２及び店舗メッセージ確認リンク２８３が表示される。店舗メッセージ確認リンク２８３は、メッセージ２８２が示す注文商品についてのメッセージ確認ページへのハイパーリンクである。
【０２１１】
［１２−２．システム制御部の動作］
次に、電子商店街サーバ１のシステム制御部１４の具体的な動作について、図５３を用いて説明する。図５３は、本実施形態に係る電子商店街サーバ１のシステム制御部１４の注文内容受付完了送信処理の一例を示すフローチャートである。図１６に示す注文内容登録処理が完了したとき、注文内容受付部１４２は、注文内容受付完了送信処理を実行する。図５３に示すように、注文内容受付部１４２は、記憶部１２からテンプレートとなる注文内容受付完了ページのＨＴＭＬ文書を取得する。次いで、注文内容登録処理で登録された注文情報からユーザＩＤを取得する。次いで、注文内容受付部１４２は、取得したユーザＩＤに対応する注文情報のうち、確認ステータスが確認未完了である注文情報を注文ＤＢ１２ｅから検索する（ステップＳ３３１）。次いで、注文内容受付部１４２は、注文情報が見つかったか否かを判定する（ステップＳ３３２）。このとき、注文内容受付部１４２は、注文情報が見つからなかったと判定した場合には（ステップＳ３３２：ＮＯ）、ステップＳ３３４に進む。一方、注文内容受付部１４２は、注文情報が見つかったと判定した場合には（ステップＳ３３２：ＹＥＳ）、ステップＳ３３３に進む。
【０２１２】
ステップＳ３３３において、注文内容受付部１４２は、メッセージ２８２及び店舗メッセージ確認リンク２８３を表示するためのデータを注文内容受付完了ページに追加する。具体的に、注文内容受付部１４２は、見つかった注文情報に含まれる店舗ＩＤ及び商品ＩＤに対応する商品名を商品ＤＢから取得する。次いで、注文内容受付部１４２は、取得した商品名を含むメッセージ２８２のテキストを生成する。そして、注文内容受付部１４２は、このテキストをＨＴＭＬ文書に追加する。また、注文内容受付部１４２は、注文情報に含まれる注文番号に基づいて、メッセージ確認ページのＵＲＬを生成する。次いで、注文内容受付部１４２は、店舗メッセージ確認リンク２８３を表示するための情報として、例えばメッセージ確認ページのＵＲＬを含むタグデータをＨＴＭＬ文書に追加する。注文内容受付部１４２は、ステップＳ３３３を終えると、ステップＳ３３４に進む。ステップＳ３３４において、注文内容受付部１４２は、注文内容受付完了ページのＨＴＭＬ文書を購入者端末３へ送信して、注文内容受付完了送信処理を終了させる。
【０２１３】
以上説明したように、本実施形態によれば、システム制御部１４が、購入者から指定医薬品について過去に受け付けられた注文内容に関連付けられた確認ステータスが確認未完了である場合、注文内容受付完了ページに、注文内容が受け付けられたことを示すメッセージ２８１とともに、留意情報の確認を促すメッセージ２８２を提示させる。そのため、購入者にとって邪魔にならないタイミングで、留意情報の確認することを購入者に思い出させることができる。
【０２１４】
なお、上記各実施形態においては、複数の店舗から商品が販売される電子商店街に本発明が適用されていた。しかしながら、単一の販売元から商品が販売される電子商取引のウェブサイトに本発明が適用されてもよい。
【符号の説明】
【０２１５】
１  電子商店街サーバ
２、６  店舗端末
３  購入者端末
４  店舗システム
５  店舗サーバ
７  配送管理サーバ
１１、５１  通信部
１２、５２  記憶部
１２ａ  会員ＤＢ
１２ｂ  店舗ＤＢ
１２ｃ  商品ＤＢ
１２ｄ  買い物かごＤＢ
１２ｅ  注文ＤＢ
１２ｆ  メッセージＤＢ
１２ｇ  使用者状態質問ＤＢ
１２ｈ  配送日数ＤＢ
１３、５３  入出力インターフェース
１４、５４  システム制御部
１４ａ、５４ａ  ＣＰＵ
１４ｂ、５４ｂ  ＲＯＭ
１４ｃ、５４ｃ  ＲＡＭ
１５、５５  システムバス
ＮＷ  ネットワーク
Ｓ１、Ｓ２、Ｓ３  情報システム
【図１】
2015230708.tif 000003
【図２】
2015230708.tif 000004
【図３】
2015230708.tif 000005
【図４】
2015230708.tif 000006
【図５】
2015230708.tif 000007
【図６】
2015230708.tif 000008
【図７】
2015230708.tif 000009
【図８】
2015230708.tif 000010
【図９】
2015230708.tif 000011
【図１０】
2015230708.tif 000012
【図１１】
2015230708.tif 000013
【図１２】
2015230708.tif 000014
【図１３】
2015230708.tif 000015
【図１４】
2015230708.tif 000016
【図１５】
2015230708.tif 000017
【図１６】
2015230708.tif 000018
【図１７】
2015230708.tif 000019
【図１８】
2015230708.tif 000020
【図１９】
2015230708.tif 000021
【図２０】
2015230708.tif 000022
【図２１】
2015230708.tif 000023
【図２２】
2015230708.tif 000024
【図２３】
2015230708.tif 000025
【図２４】
2015230708.tif 000026
【図２５】
2015230708.tif 000027
【図２６】
2015230708.tif 000028
【図２７】
2015230708.tif 000029
【図２８】
2015230708.tif 000030
【図２９】
2015230708.tif 000031
【図３０】
2015230708.tif 000032
【図３１】
2015230708.tif 000033
【図３２】
2015230708.tif 000034
【図３３】
2015230708.tif 000035
【図３４】
2015230708.tif 000036
【図３５】
2015230708.tif 000037
【図３６】
2015230708.tif 000038
【図３７】
2015230708.tif 000039
【図３８】
2015230708.tif 000040
【図３９】
2015230708.tif 000041
【図４０】
2015230708.tif 000042
【図４１】
2015230708.tif 000043
【図４２】
2015230708.tif 000044
【図４３】
2015230708.tif 000045
【図４４】
2015230708.tif 000046
【図４５】
2015230708.tif 000047
【図４６】
2015230708.tif 000048
【図４７】
2015230708.tif 000049
【図４８】
2015230708.tif 000050
【図４９】
2015230708.tif 000051
【図５０】
2015230708.tif 000052
【図５１】
2015230708.tif 000053
【図５２】
2015230708.tif 000054
【図５３】
2015230708.tif 000055
【手続補正書】
【提出日】平成26年9月11日(2014.9.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付手段と、
前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御手段と、
受け付けられた前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御手段と、
前記注文内容に示される前記対象商品と前記状態情報受付手段により受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力手段と、
前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付手段と、
前記確認通知受付手段により前記確認通知が受け付けられた場合、前記確認状態記憶手段に記憶された前記確認状態を完了状態に更新する更新手段と、
前記確認状態記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力手段と、
を備えることを特徴とする情報システム。
【請求項２】
請求項１に記載の情報システムにおいて、
前記注文内容記憶手段に記憶される前記注文内容に関連付けて、該注文内容に示される商品の購入代金の支払いのための処理状態と、該商品の発送状態とを状態記憶手段に記憶させる状態記憶制御手段と、
前記注文内容に示される商品が前記対象商品ではない場合、前記処理状態が完了状態に更新されていることを条件に、前記発送状態を発送可能状態に更新する第１発送状態更新手段と、
前記注文内容に示される商品が前記対象商品である場合、前記処理状態と前記確認状態との何れもが完了状態に更新されていることを条件に、前記発送状態を発送可能状態に更新する第２発送状態更新手段と、
前記状態記憶手段に記憶された前記発送状態を出力する発送状態出力手段と、
を更に備えることを特徴とする情報システム。
【請求項３】
請求項１又は２に記載の情報システムにおいて、
前記注文内容に示される商品が前記対象商品である場合、前記留意情報へのリンク情報を提示させるリンク情報提示制御手段を更に備え、
前記留意情報出力手段は、前記リンク情報が選択された場合、前記留意情報と該留意情報を理解したと確認したことを示すために操作可能な確認要素とを提示させ、
前記確認通知受付手段は、前記確認要素が操作されることに基づく前記確認通知を取得することを特徴とする情報システム。
【請求項４】
請求項１乃至３の何れか１項に記載の情報システムにおいて、
前記確認状態出力手段は、前記注文内容記憶手段に記憶された前記注文内容について販売者向けの情報を提示させ、前記注文内容に示される商品が前記対象商品である場合、該注文内容に関連付けられた前記確認状態に応じて外観が変化する画像を前記販売者向けの情報とともに提示させることを特徴とする情報システム。
【請求項５】
請求項１乃至４の何れか１項に記載の情報システムにおいて、
前記注文内容記憶手段に記憶された前記注文内容を販売者向けに出力する注文内容出力手段であって、前記注文内容に示される商品が前記対象商品であり、且つ前記注文内容に関連付けられた前記確認状態が未完了状態である場合、前記注文内容のうち商品の送付先の住所を出力しない注文内容出力手段を更に備えることを特徴とする情報システム。
【請求項６】
請求項１乃至５の何れか１項に記載の情報システムにおいて、
前記注文内容記憶手段に記憶された前記注文内容に示される商品の配送伝票情報の入力を受け付ける配送伝票受付手段であって、前記商品が前記対象商品であり且つ前記注文内容に関連付けられた前記確認状態が未完了状態である場合、前記配送伝票情報を受け付けない配送伝票受付手段を更に備えることを特徴とする情報システム。
【請求項７】
請求項１乃至６の何れか１項に記載の情報システムにおいて、
前記留意情報が生成された場合、該留意情報の確認が必要であることを前記購入者に通知する通知情報を出力する通知情報出力手段と、
前記通知情報出力手段により前記通知情報が出力されてから設定期間内に前記確認通知受付手段により前記確認通知が受け付けられなかった場合、前記注文内容の受け付けをキャンセルするキャンセル手段を更に備えることを特徴とする情報システム。
【請求項８】
請求項７に記載の情報システムにおいて、
前記状態情報受付手段により受け付けられた前記状態情報を前記注文内容記憶手段に記憶される前記注文内容に関連付けて状態情報記憶手段に記憶させる状態情報記憶制御手段と、
受け付けがキャンセルされた注文内容の少なくとも一部と、該注文内容に示される商品の再注文のために操作可能な再注文要素とを提示させるキャンセル注文提示制御手段と、
を更に備え、
前記状態情報受付手段は、前記再注文要素が操作されることに基づいて前記再注文のための注文内容が受け付けられる場合、前記受け付けがキャンセルされた注文内容に関連付けられた状態情報を、前記再注文のための注文内容に関連付けられる状態情報として取得することを特徴とする情報システム。
【請求項９】
請求項８に記載の情報システムにおいて、
前記受け付けがキャンセルされた注文内容に関連付けられた状態情報が変化する可能性がある情報である場合、該状態情報の有効日数を取得する有効日数取得手段と、
前記受け付けがキャンセルされた注文内容が受け付けられてから前記再注文要素が操作されるまでの経過日数が、前記有効日数取得手段により取得された前記有効日数を超える場合、前記使用者の状態情報の再入力を前記購入者に要求する要求情報を提示させる要求情報提示制御手段と、
を更に備え、
前記状態情報受付手段は、前記購入者から再入力された状態情報を受け付けることを特徴とする情報システム。
【請求項１０】
請求項７乃至９の何れか１項に記載の情報システムにおいて、
前記購入者から受け付けられた注文内容が配送日の指定を含む場合、該配送日に商品を配達するための発送期限を取得する発送期限取得手段と、
前記発送期限に基づいて、前記留意情報の確認期限を決定する確認期限決定手段と、
を更に備え、
前記キャンセル手段は、前記確認期限決定手段により決定された前記確認期限までに前記確認通知受付手段により前記確認通知が受け付けられなかった場合、前記注文内容の受け付けをキャンセルすることを特徴とする情報システム。
【請求項１１】
請求項１乃至１０の何れか１項に記載の情報システムにおいて、
生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後、前記確認通知受付手段により前記確認通知が受け付けられるまでに、前記留意情報の確認を前記購入者に促すリマインド情報であって所定時間間隔ごとに出力されるリマインド情報が出力された回数を取得する回数取得手段と、
前記通知情報が出力された後に前記確認通知が受け付けられていない注文内容のための前記リマインド情報を出力する時間間隔を、前記回数取得手段により取得された前記回数に応じて決定する時間間隔決定手段と、
を更に備えることを特徴とする情報システム。
【請求項１２】
請求項１乃至１１の何れか１項に記載の情報システムにおいて、
前記確認通知受付手段により前記確認通知が受け付けられた時間を取得する時間取得手段と、
生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後に前記確認通知が受け付けられていない場合における前記留意情報の確認を前記購入者に促すリマインド情報を出力する時間を、前記時間取得手段により取得された前記時間に応じて決定する時間決定手段と、
を更に備えることを特徴とする情報システム。
【請求項１３】
請求項１乃至１２の何れか１項に記載の情報システムにおいて、
前記購入者から受け付けられた前記注文内容に示される商品が前記対象商品である場合、該商品についてこれまでに受け付けられている１以上の注文内容のうち発送が完了していない注文内容に応じた前記商品の数を取得する商品数取得手段と、
生成された前記留意情報について該留意情報の確認が必要であることを前記購入者に通知する通知情報が出力された後に前記確認通知が受け付けられていない場合における前記留意情報の確認を前記購入者に促すリマインド情報を出力する頻度を決定する頻度決定手段であって、前記商品数取得手段により取得された前記数が多いほど前記頻度を高くする頻度決定手段と、
を更に備えることを特徴とする情報システム。
【請求項１４】
請求項１乃至１３の何れか１項に記載の情報システムにおいて、
前記購入者から何れかの商品の注文内容が受け付けられた場合に該注文内容が受け付けられたことを示す受付情報を提示させる受付情報提示制御手段であって、前記購入者から前記対象商品について過去に受け付けられた注文内容に関連付けられた確認状態が未完了状態である場合、前記留意情報の確認を促す情報を前記受付情報とともに提示させる受付情報提示制御手段を更に備えることを特徴とする情報システム。
【請求項１５】
コンピュータにより実行される情報処理方法であって、
購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付ステップと、
前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御ステップと、
前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御ステップと、
前記注文内容に示される前記対象商品と前記状態情報受付ステップにより受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力ステップと、
前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付ステップと、
前記確認通知受付ステップにより前記確認通知が受け付けられた場合、前記確認状態記憶手段に記憶された前記確認状態を完了状態に更新する更新ステップと、
前記確認状態記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力ステップと、
を含むことを特徴とする情報処理方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
上記課題を解決するために、請求項１に記載の発明は、購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付手段と、前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御手段と、受け付けられた前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御手段と、前記注文内容に示される前記対象商品と前記状態情報受付手段により受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力手段と、前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付手段と、前記確認通知受付手段により前記確認通知が受け付けられた場合、前記確認状態記憶手段に記憶された前記確認状態を完了状態に更新する更新手段と、前記確認状態記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力手段と、を備えることを特徴とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００３５
【補正方法】変更
【補正の内容】
【００３５】
請求項１５に記載の発明は、コンピュータにより実行される情報処理方法であって、購入者が注文する商品が、商品の販売者から購入者へ使用の際の留意情報を提供する対象商品である場合、前記商品を使用する使用者の状態情報を前記購入者から受け付ける状態情報受付ステップと、前記購入者から商品の注文内容が受け付けられた場合、該注文内容を注文内容記憶手段に記憶させる注文内容記憶制御ステップと、前記注文内容に示される商品が前記対象商品である場合、前記注文内容記憶手段に記憶される前記注文内容に関連付けて、前記留意情報の確認状態であって、未完了状態に設定された確認状態を確認状態記憶手段に記憶させる確認状態記憶制御ステップと、前記注文内容に示される前記対象商品と前記状態情報受付ステップにより受け付けられた前記状態情報とに応じて生成された留意情報を前記購入者が確認可能に出力する留意情報出力ステップと、前記留意情報を理解したと前記購入者が確認したことを示す確認通知を受け付ける確認通知受付ステップと、前記確認通知受付ステップにより前記確認通知が受け付けられた場合、前記確認状態記憶手段に記憶された前記確認状態を完了状態に更新する更新ステップと、前記確認状態記憶手段に記憶された前記確認状態を、前記注文内容に示される前記対象商品の販売成立のための処理が可能であるかを判定可能に出力する確認状態出力ステップと、を含むことを特徴とする。