TW201541384A - 資訊系統及資訊處理方法 - Google Patents

資訊系統及資訊處理方法 Download PDF

Info

Publication number
TW201541384A
TW201541384A TW104107412A TW104107412A TW201541384A TW 201541384 A TW201541384 A TW 201541384A TW 104107412 A TW104107412 A TW 104107412A TW 104107412 A TW104107412 A TW 104107412A TW 201541384 A TW201541384 A TW 201541384A
Authority
TW
Taiwan
Prior art keywords
information
order
confirmation
content
recorded
Prior art date
Application number
TW104107412A
Other languages
English (en)
Other versions
TWI614709B (zh
Inventor
Jun Katakawa
Original Assignee
Rakuten Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rakuten Inc filed Critical Rakuten Inc
Publication of TW201541384A publication Critical patent/TW201541384A/zh
Application granted granted Critical
Publication of TWI614709B publication Critical patent/TWI614709B/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0613—Third-party assisted
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0631—Item recommendations

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

目的在於提供一種，即使在購入者發送資訊提供對象之商品的訂購內容的情況下，可使程序是和非資訊提供對象之商品的時候同樣容易理解，在商品的寄送之前可進行個別之資訊提供的資訊系統及資訊處理方法。資訊系統，係若已被受理之訂購內容所示之商品是對象商品，則將相應於狀態資訊所生成的留意資訊，輸出給購入者讓其可以確認。又，資訊系統，係在受理了表示購入者已經確認理解留意資訊的確認通知時，則將確認狀態更新成完成狀態。又，資訊系統，係將確認狀態予以輸出，而可判定對象商品之販售成立所需之處理是否可行。

Description

資訊系統及資訊處理方法
本發明係有關於，針對購入者所欲購入之商品從販售者進行資訊提供所需之系統的技術領域。
例如，專利文獻1中係揭露，購入者向線上購物系統之諮詢員諮詢健康狀態等，諮詢員隨著諮詢內容而進行回答同時提示推薦商品，購入者從推薦商品之中選擇購入商品的系統。於該系統中，購入者在訂購商品之前，從諮詢員會進行資訊提供。
[先前技術文獻] [專利文獻]
[專利文獻1]日本特開2002-24639號公報
可是，在利用網際網路來販售醫藥品的情況下，有時候即使購入者已經決定要購入的醫藥品，為了確 保安全性而仍對購入者進行資訊提供，較為理想。具體而言，先考慮使用該醫藥品的使用者之症狀等之狀態然後由販售者進行符合使用者的資訊提供，先確認購入者理解了所被提供之資訊然後販售者才向購入者販售該醫藥品，有時候比較理想。這類商品並不限於醫藥品。例如，即使關於和食物過敏有關連性的食材或營養食品等，仍進行如上述的資訊提供，有時候比較理想。
另一方面，購入者利用網際網路而購入商品時，含有所購入之商品、配送目標、結帳方法等的訂購內容會由購入者來發送的此一程序，是一般慣用的。因此，在進行隨應於商品、使用者之狀態的個別之資訊提供時，例如像是專利文獻1所記載之系統，若在購入者發送訂購內容前進行資訊提供，則對一般慣用的程序會造成變更。其結果為，到發送訂購內容為止之程序，難以讓購入者所理解。
本發明係有鑑於以上問題點而研發，目的在於提供一種，即使在購入者發送資訊提供對象之商品的訂購內容的情況下，可使程序是和非資訊提供對象之商品的時候同樣容易理解，在商品的販售(契約)成立為止可進行個別之資訊提供的資訊系統及資訊處理方法。
為了解決上記課題，請求項1所記載之發明，其特徵為，具備：狀態資訊受理手段，係若購入者所 訂購之商品是要從商品之販售者向購入者提供使用之際之留意資訊的對象商品時，則從前記購入者受理使用前記商品之使用者的狀態資訊；和訂購內容記憶控制手段，係在從前記購入者受理了商品之訂購內容時，令該訂購內容被記憶在訂購內容記憶手段中；和確認狀態記憶控制手段，係若已被受理之前記訂購內容所示的商品是前記對象商品時，則與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而令前記留意資訊之確認狀態且是被設定成未完成狀態的確認狀態，被記憶在確認狀態記憶手段中；和留意資訊輸出手段，係將隨應於前記訂購內容所示之前記對象商品和已被前記狀態資訊受理手段所受理之前記狀態資訊而被生成的留意資訊，輸出成可讓前記購入者確認；和確認通知受理手段，係受理表示前記購入者已經確認理解了前記留意資訊的確認通知；和更新手段，係在藉由前記確認通知受理手段受理了前記確認通知時，將前記確認狀態記憶手段中所記憶的前記確認狀態，更新成完成狀態；和確認狀態輸出手段，係將前記確認狀態記憶手段中所記憶的前記確認狀態，輸出成可以判定用來使前記訂購內容所示之前記對象商品之販售成立所需的處理是否可行。
若依據本發明，則對象商品之訂購內容被受理後，進行留意資訊之提供及確認。又，由於表示留意資訊是否已被確認的確認狀態會被輸出，因此例如販售者係可以留意資訊已被確認為條件，進行商品的販售成立所需 之處理。因此，即使在購入者發送資訊提供對象之商品的訂購內容的情況下，仍可使程序是和非資訊提供對象之商品的時候同樣容易理解，在商品的販售(契約)成立為止可進行個別之資訊提供。
請求項2所記載之發明，係如請求項1所記載之資訊系統，其中，其特徵為，還具備：狀態記憶控制手段，係與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而令該訂購內容所示之商品的購入費用之支付所需的處理狀態、和該商品之寄送狀態，被記憶在狀態記憶手段中；和第1寄送狀態更新手段，係若前記訂購內容所示之商品並非前記對象商品時，則以前記處理狀態已經被更新成完成狀態為條件，將前記寄送狀態更新成可寄送狀態；和第2寄送狀態更新手段，係若前記訂購內容所示之商品是前記對象商品時，則以前記處理狀態與前記確認狀態均已經被更新成完成狀態為條件，將前記寄送狀態更新成可寄送狀態；和寄送狀態輸出手段，係將前記狀態記憶手段中所記憶的前記寄送狀態，予以輸出。
若依據本發明，則若訂購內容所示之商品並非對象商品，則購入費用之支付所需之處理完成後，就可寄送商品。又，若訂購內容所示之商品是對象商品，則在購入者確認留意資訊，且購入費用之支付所需之處理完成後，就可寄送商品。因此，可防止販售者錯誤寄送商品。
請求項3所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：連結資訊 提示控制手段，係若前記訂購內容所示之商品是前記對象商品時，則令往前記留意資訊之連結資訊被提示；前記留意資訊輸出手段，係在前記連結資訊被選擇時，令可操作之確認要素被提示以用來表示已確認前記留意資訊與理解了該留意資訊之事實；前記確認通知受理手段，係取得以前記確認要素有被操作之事實為依據的前記確認通知。
若依據此發明，則購入者所做的留意資訊之確認，可變得容易。
請求項4所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，前記確認狀態輸出手段，係針對前記訂購內容記憶手段中所記憶之前記訂購內容，令販售者專用之資訊被提示，若前記訂購內容所示之商品是前記對象商品時，則令外觀隨著該訂購內容所被建立關連對應到的前記確認狀態而變化的影像，連同前記販售者專用之資訊一併被提示。
若依據本發明，則藉由影像，販售者係可容易辨識購入者是否已經確認留意資訊。
請求項5所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：訂購內容輸出手段，係將前記訂購內容記憶手段中所記憶之前記訂購內容，輸出給販售者專用，其中，該訂購內容輸出手段係為，若前記訂購內容所示之商品是前記對象商品，且前記訂購內容所被建立關連對應到的前記確認狀態係為未完成狀態時，則在前記訂購內容之中，不將商品的寄送目標 地址予以輸出。
若依據此發明，則確認狀態為未完成狀態時，商品之寄送目標地址就不會被提示給販售者。因此，就算購入者沒有確認留意資訊，仍可防止販售者寄送商品。
請求項6所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：配送傳票受理手段，係用來受理前記訂購內容記憶手段中所記憶之前記訂購內容所示之商品的配送傳票資訊之輸入，其中，該配送傳票受理手段係為，若前記商品是前記對象商品且前記訂購內容所被建立關連對應到的前記確認狀態是未完成狀態時，則不受理前記配送傳票資訊。
若依據此發明，則確認狀態為未完成狀態時，配送傳票資訊的輸入係不被受理。因此，就算購入者沒有確認留意資訊，仍可防止販售者使用配送傳票來寄送商品。
請求項7所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：通知資訊輸出手段，係在前記留意資訊被生成時，輸出向前記購入者通知需要確認該留意資訊的通知資訊；和取消手段，係在從前記通知資訊輸出手段輸出前記通知資訊起算的設定期間內，都沒有藉由前記確認通知受理手段受理到前記確認通知的情況下，則取消前記訂購內容之受理。
若依據本發明，則即使經過一定期間，購入 者仍未確認留意資訊時，資訊系統係取消訂購內容之受理。因此，由於留意資訊未被確認因此也無法寄送，可減少也無法販售給其他購入者的商品之數量。
請求項8所記載之發明，係如請求項7所記載之資訊系統，其中，其特徵為，還具備：狀態資訊記憶控制手段，係令已被前記狀態資訊受理手段所受理之前記狀態資訊，與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而被記憶在狀態資訊記憶手段中；和取消訂購提示控制手段，係令已經被取消受理的訂購內容的至少一部分、和為了該訂購內容所示之商品的重新訂購所需而可操作之重新訂購要素，被提示出來；前記狀態資訊受理手段，係在基於前記重新訂購要素已被操作之事實而受理前記重新訂購所需之訂購內容時，將前記已經被取消受理的訂購內容所被建立關連對應到的狀態資訊，當作與前記重新訂購所需之訂購內容建立關連對應的狀態資訊而加以取得。
若依據本發明，則在訂購內容之受理已被取消後，若購入者重新訂購相同的商品，則資訊系統係將已被取消之訂購內容所被建立關連對應到的狀態資訊，與重新訂購時的訂購內容建立關連而記憶。因此，在重新訂購之際，購入者係可省去重新輸入狀態資訊的麻煩。
請求項9所記載之發明，係如請求項8所記載之資訊系統，其中，其特徵為，還具備：有效日數取得手段，係若前記已經被取消受理的訂購內容所被建立關連 對應到的狀態資訊是有變化之可能性的資訊時，則取得該狀態資訊之有效日數；和要求資訊提示控制手段，係若前記已經被取消受理的訂購內容被受理起至前記重新訂購要素被操作為止的經過日數，是超過已被前記有效日數取得手段所取得之前記有效日數時，則提示向前記購入者要求重新輸入前記使用者之狀態資訊的要求資訊；前記狀態資訊受理手段，係將從前記購入者所重新輸入的狀態資訊，予以受理。
若依據本發明，則若已被取消的訂購內容所被建立關連對應到的狀態資訊是處於有變化之可能性的狀態時，則資訊系統係根據該狀態資訊所相應之有效日數和重新訂購要素被操作為止的經過日數，控制是否讓購入者再度輸入狀態資訊。因此，也可一面省去重新輸入狀態資訊的麻煩，一面防止因為重新輸入未被進行導致狀態資訊被錯誤記憶。
請求項10所記載之發明，係如請求項7所記載之資訊系統，其中，其特徵為，還具備：寄送期限取得手段，係若從前記購入者所受理到的訂購內容是含有配送日之指定時，則取得用來在該配送日遞送商品所需的寄送期限；和確認期限決定手段，根據前記寄送期限，來決定前記留意資訊之確認期限；前記取消手段，係若到了已被前記確認期限決定手段所決定之前記確認期限為止都沒有藉由前記確認通知受理手段受理到前記確認通知的情況下，則取消前記訂購內容之受理。
若依據本發明，則資訊系統係在購入者所指定之配送日期時間直到可配送商品的時期為止，不會取消訂購內容之受理，可等待確認者所做的留意資訊的確認。因此，可適切地設定留意資訊的確認期間。
請求項11所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：次數取得手段，係針對已被生成之前記留意資訊而向前記購入者通知需要確認該留意資訊的通知資訊已被輸出後，直到藉由前記確認通知受理手段受理到前記確認通知以前，取得向前記購入者催促前記留意資訊之確認的提醒資訊且為每隔所定時間間隔就被輸出的提醒資訊所被輸出的次數；和時間間隔決定手段，係將前記通知資訊被輸出後前記確認通知未被受理的訂購內容所需的前記提醒資訊的輸出之時間間隔，隨應於前記次數取得手段所取得之前記次數而加以決定。
若依據本發明，則資訊系統係隨應於過去購入者確認留意資訊為止之期間中提醒資訊所被輸出的次數，來決定輸出提醒資訊的時間間隔。因此，可有效率地輸出提醒資訊。
請求項12所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：時間取得手段，係取得藉由前記確認通知受理手段受理了前記確認通知的時間；和時間決定手段，係將針對已被生成之前記留意資訊而向前記購入者通知需要確認該留意資訊的通知 資訊已被輸出後前記確認通知未被受理時的向前記購入者催促前記留意資訊之確認的提醒資訊的輸出之時間，隨應於前記時間取得手段所取得之前記時間而加以決定。
若依據本發明，則資訊系統係隨應於過去購入者確認了留意資訊的時間，來決定輸出提醒資訊的時間。因此，可提高購入者確認留意資訊的或然性。
請求項13所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：商品數取得手段，係若從前記購入者所受理之前記訂購內容所示的商品是前記對象商品時，則針對該商品將目前為止所受理的1個以上之訂購內容之中尚未完成寄送的訂購內容所相應的前記商品之數目，加以取得；和頻繁度決定手段，係決定針對已被生成之前記留意資訊而向前記購入者通知需要確認該留意資訊的通知資訊已被輸出後，前記確認通知未被受理時的向前記購入者催促前記留意資訊之確認的提醒資訊的輸出之頻繁度，其中，該頻繁度決定手段係為，已被前記商品數取得手段所取得的前記數目越多，則將前記頻繁度設得越高。
若依據本發明，則資訊系統係針對某對象商品，未被寄送之商品數越多，則輸出提醒資訊的頻繁度會越高。因此，可減少因為購入者未確認留意資訊導致販售者不能寄送的商品之數量。
請求項14所記載之發明，係如請求項1或2所記載之資訊系統，其中，其特徵為，還具備：受理資訊 提示控制手段，係在從前記購入者受理了任一商品的訂購內容時，就令表示該訂購內容已被受理的受理資訊被提示出來，其中，該受理資訊提示控制手段係為，若從前記購入者針對前記對象商品在過去曾經受理過的訂購內容所被建立關連對應到的確認狀態係為未完成狀態時，則令用來催促前記留意資訊之確認的資訊連同前記受理資訊一併被顯示。
若依據本發明，則針對指定商品若購入者沒有確認留意資訊，則資訊系統係在受理了任一商品之訂購內容時，除了提示表示受理已完成之資訊，並且還會提示催促確認留意資訊的資訊。因此，可在對購入者而言不會打擾的時間點上，讓購入者想起確認留意資訊。
請求項15所記載之發明，係屬於被電腦所執行的資訊處理方法，其特徵為，含有：狀態資訊受理步驟，係若購入者所訂購之商品是要從商品之販售者向購入者提供使用之際之留意資訊的對象商品時，則從前記購入者受理使用前記商品之使用者的狀態資訊；和訂購內容記憶控制步驟，係在從前記購入者受理了商品之訂購內容時，令該訂購內容被記憶在訂購內容記憶手段中；和確認狀態記憶控制步驟，係若前記訂購內容所示的商品是前記對象商品時，則與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而令前記留意資訊之確認狀態且是被設定成未完成狀態的確認狀態，被記憶在確認狀態記憶手段中；和留意資訊輸出步驟，係將隨應於前記訂購內容 所示之前記對象商品和已被前記狀態資訊受理步驟所受理之前記狀態資訊而被生成的留意資訊，輸出成可讓前記購入者確認；和確認通知受理步驟，係受理表示前記購入者已經確認理解了前記留意資訊的確認通知；和更新步驟，係在藉由前記確認通知受理步驟受理了前記確認通知時，將前記確認狀態記憶手段中所記憶的前記確認狀態，更新成完成狀態；和確認狀態輸出步驟，係將前記確認狀態記憶手段中所記憶的前記確認狀態，輸出成可以判定用來使前記訂購內容所示之前記對象商品之販售成立所需的處理是否可行。
若依據本發明，則對象商品之訂購內容被受理後，進行留意資訊之提供及確認。又，由於表示留意資訊是否已被確認的確認狀態會被輸出，因此例如販售者係可以留意資訊已被確認為條件，進行商品的販售成立所需之處理。因此，即使在購入者發送資訊提供對象之商品的訂購內容的情況下，仍可使程序是和非資訊提供對象之商品的時候同樣容易理解，在商品的販售(契約)成立為止可進行個別之資訊提供。
1‧‧‧電子商店街伺服器
2、6‧‧‧店舖終端
3‧‧‧購入者終端
4‧‧‧店舖系統
5‧‧‧店舖伺服器
7‧‧‧配送管理伺服器
11、51‧‧‧通訊部
12、52‧‧‧記憶部
12a‧‧‧會員DB
12b‧‧‧店舖DB
12c‧‧‧商品DB
12d‧‧‧購物籃DB
12e‧‧‧訂購DB
12f‧‧‧訊息DB
12g‧‧‧使用者狀態質問DB
12h‧‧‧配送日數DB
13、53‧‧‧輸出入介面
14、54‧‧‧系統控制部
14a、54a‧‧‧CPU
14b、54b‧‧‧ROM
14c、54c‧‧‧RAM
15、55‧‧‧系統匯流排
141‧‧‧使用者狀態資訊受理部
142‧‧‧訂購內容受理部
143‧‧‧訊息處理部
144‧‧‧狀態控制部
145‧‧‧接單資訊提供部
146‧‧‧訂購履歷提供部
147‧‧‧取消處理部
148‧‧‧提醒處理部
201‧‧‧購物籃登錄鈕
202‧‧‧個數輸入欄
203‧‧‧質問內容
204‧‧‧選擇選單
211‧‧‧確認狀態小圖示
221‧‧‧結帳授權要求鈕
222‧‧‧寄送狀態更新要求鈕
223‧‧‧配送傳票輸入鈕
231‧‧‧確認狀態小圖示
232‧‧‧訊息一覽顯示領域
233‧‧‧訊息顯示領域
234‧‧‧新增訊息鈕
235‧‧‧表示確認完成之訊息
236‧‧‧訊息
241‧‧‧確認狀態小圖示
242‧‧‧主旨輸入欄
243‧‧‧訊息輸入欄
244‧‧‧送訊鈕
251‧‧‧訂購內容顯示領域
252‧‧‧店舖訊息確認連結
253‧‧‧訊息
254‧‧‧重新訂購鈕
261‧‧‧訊息一覽顯示領域
262‧‧‧訊息顯示領域
263‧‧‧勾選盒
264‧‧‧輸入欄
265‧‧‧OK鈕
271‧‧‧訂購內容顯示領域
272‧‧‧使用者狀態資訊顯示領域
273‧‧‧訂購內容編輯鈕
274‧‧‧使用者狀態資訊編輯鈕
275‧‧‧確定鈕
276‧‧‧使用者狀態資訊重新輸入領域
277‧‧‧選擇選單
281‧‧‧訊息
282‧‧‧訊息
283‧‧‧店舖訊息確認連結
541‧‧‧伺服器通訊部
542‧‧‧使用者介面部
543‧‧‧狀態判定部
NW‧‧‧網路
S1、S2、S3‧‧‧資訊系統
[圖1]一實施形態所述之資訊處理系統S1的概要構成 之一例的圖示。
[圖2]指定醫藥品之購入的相關程序之概要的流程圖。
[圖3](a)係一實施形態所述之電子商店街伺服器1的概要構成之一例的區塊圖。(b)係一實施形態所述之宿泊設施預約伺服器1的系統控制部14之機能區塊之一例的圖示。
[圖4](a)係會員DB12a中所被登錄之內容之一例的圖示。(b)係店舖DB12b中所被登錄之內容之一例的圖示。(c)係商品DB12c中所被登錄之內容之一例的圖示。(d)係購物籃DB12d中所被登錄之內容之一例的圖示。(e)係訂購DB12e中所被登錄之內容之一例的圖示。(f)係訊息DB12f中所被登錄之內容之一例的圖示。
[圖5]一實施形態所述之資訊處理系統S1的處理之一例的程序圖。
[圖6]一實施形態所述之資訊處理系統S1的處理之一例的程序圖。
[圖7]指定醫藥品之商品網頁之顯示例的圖示。
[圖8](a)係接單一覽網頁之顯示例的圖示。(b)係相應於確認狀態的確認狀態小圖示之外觀之例的圖示。
[圖9]接單管理網頁之顯示例的圖示。
[圖10](a)係訊息管理網頁之顯示例的圖示。(b)係訊息輸入網頁之顯示例的圖示。
[圖11]訂購履歷網頁之顯示例的圖示。
[圖12](a)係訊息確認網頁之顯示例的圖示。(b)係對所有的留意事項的勾選盒263都被設定成已勾選的訊息確認網頁之例子。
[圖13](a)係確認狀態被更新成確認完成後的接單一覽網頁之顯示例。(b)係確認狀態被更新成確認完成後的訊息管理網頁之顯示例。
[圖14](a)係確認狀態未被更新成確認完成時的接單一覽網頁之顯示例。(b)係確認狀態未被更新成確認完成時的訊息管理網頁之顯示例。
[圖15](a)係結帳狀態被更新成處理完成，且確認狀態被更新成確認完成後的接單管理網頁之顯示例。(b)係寄送狀態被更新成等待寄送後的接單一覽網頁之顯示例。
[圖16]一實施形態所述之電子商店街伺服器1的系統控制部14的訂購內容登錄處理之一例的流程圖。
[圖17]一實施形態所述之電子商店街伺服器1的系統控制部14的接單一覽送訊處理之一例的流程圖。
[圖18]一實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。
[圖19]一實施形態所述之電子商店街伺服器1的系統控制部14的訂購履歷送訊處理之一例的流程圖。
[圖20]一實施形態所述之電子商店街伺服器1的系統控制部14的購入者訊息登錄處理之一例的流程圖。
[圖21]一實施形態之變形例所述之電子商店街伺服器1的系統控制部14的寄送狀態控制處理之一例的流程 圖。
[圖22]一實施形態所述之資訊處理系統S2的概要構成之一例的圖示。
[圖23](a)係一實施形態所述之店舖伺服器5之概要構成之一例的區塊圖。(b)係一實施形態所述之宿泊設施預約伺服器1的系統控制部54之機能區塊之一例的圖示。
[圖24]一實施形態所述之資訊處理系統S2的留意資訊之提供的相關處理之一例的程序圖。
[圖25]一實施形態所述之資訊處理系統S2的確認狀態及寄送狀態之更新的相關處理之一例的程序圖。
[圖26]一實施形態所述之店舖伺服器5之系統控制部54的寄送狀態更新判定處理之一例的流程圖。
[圖27](a)係確認狀態為確認完成時的接單管理網頁之顯示例的圖示。(b)係確認狀態為確認未完成時的接單管理網頁之顯示例的圖示。
[圖28]一實施形態所述之電子商店街伺服器1的系統控制部14的接單管理網頁送訊處理之一例的流程圖。
[圖29]一實施形態所述之資訊處理系統S3的概要構成之一例的圖示。
[圖30](a)係確認狀態為確認完成時的接單管理網頁之顯示例的圖示。(b)係確認狀態為確認未完成時的接單管理網頁之顯示例的圖示。
[圖31]一實施形態所述之電子商店街伺服器1的系統控制部14的接單管理網頁送訊處理之一例的流程圖。
[圖32]一實施形態所述之宿泊設施預約伺服器1的系統控制部14之機能區塊之一例的圖示。
[圖33]一實施形態所述之電子商店街伺服器1的系統控制部14的自動取消處理之一例的流程圖。
[圖34]訂購履歷網頁之顯示例的圖示。
[圖35]重新訂購內容確認網頁之顯示例的圖示。
[圖36]一實施形態所述之電子商店街伺服器1的系統控制部14的訂購履歷送訊處理之一例的流程圖。
[圖37]一實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購確認網頁送訊處理之一例的流程圖。
[圖38]一實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購內容登錄處理之一例的流程圖。
[圖39]重新訂購內容確認網頁之顯示例的圖示。
[圖40]使用者狀態質問DB12g中所被登錄之內容之一例的圖示。
[圖41]一實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購確認網頁送訊處理之一例的流程圖。
[圖42]一實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購內容登錄處理之一例的流程圖。
[圖43]配送日數DB12h中所被登錄之內容之一例。
[圖44]一實施形態所述之電子商店街伺服器1的系統控制部14的自動取消處理之一例的流程圖。
[圖45]一實施形態所述之宿泊設施預約伺服器1的系統控制部14之機能區塊之一例的圖示。
[圖46]一實施形態所述之電子商店街伺服器1的系統控制部14的提醒時間間隔決定處理之一例的流程圖。
[圖47]一實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。
[圖48]一實施形態所述之電子商店街伺服器1的系統控制部14的提醒郵件送訊處理之一例的流程圖。
[圖49]一實施形態所述之電子商店街伺服器1的系統控制部14的提醒時間間隔決定處理之一例的流程圖。
[圖50]一實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。
[圖51]一實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。
[圖52]訂購內容受理完成網頁之顯示例的圖示。
[圖53]一實施形態所述之電子商店街伺服器1的系統控制部14的訂購內容受理完成送訊處理之一例的流程圖。
以下，參照圖面來詳細說明本發明的實施形態。此外，以下說明的實施形態，係對資訊處理系統適用本發明時的實施形態。
〔1.第1實施形態〕 〔1-1.資訊處理系統之構成及機能概要〕
首先，關於本實施形態中所述之資訊處理系統S1之構成及機能概要，使用圖1及圖2來說明。圖1係本實施形態所述之資訊處理系統S1的概要構成之一例的圖示。
如圖1所示，資訊處理系統S1係含有：電子商店街伺服器1、複數店舖終端2、複數購入者終端3所構成。然後，電子商店街伺服器1與各店舖終端2及各購入者終端3，係透過網路NW，例如在通訊協定是使用TCP/IP等，而可彼此收送資料。此外，網路NW，係由例如網際網路、專用通訊線路(例如CATV(Community Antenna Television)線路)、移動體通訊網(包含基地台等)、及閘道等所架構而成。
電子商店街伺服器1，係為執行有可購入商品之電子商店街的相關之各種處理的伺服器裝置。電子商店街伺服器1，係為本發明中的資訊系統之一例。利用電子商店街的購入者，係於電子商店街中可從所望之店舖購入所望之商品。電子商店街伺服器1，係隨應於來自店舖終端2或購入者終端3的請求，例如，發送電子商店街之網頁，或是進行商品之檢索或訂購等之相關處理。
店舖終端2係為，在電子商店街中開店之店舖的從業員等所利用的終端裝置。店舖終端2，係基於來自從業員等之操作而向電子商店街伺服器1等之伺服器裝置進行存取。藉此，店舖終端2係從伺服器裝置接收網頁 並顯示之。店舖終端2中係安裝有瀏覽器或電子郵件客戶端等之軟體。從業員係藉由利用店舖終端2，而例如，將所販售之商品的資訊登錄至電子商店街，或確認商品的訂購內容等等。店舖係為販售商品之販售者之一例。
購入者終端3，係為從電子商店街購入商品的購入者之終端裝置。購入者終端3，係基於來自購入者之操作而向電子商店街伺服器1進行存取，從電子商店街伺服器1接收網頁並顯示之。購入者終端3中係安裝有瀏覽器或電子郵件客戶端等之軟體。作為購入者終端3係可使用例如個人電腦、PDA(Personal Digital Assistant)、智慧型手機等之攜帶型資訊終端、行動電話機等。
為了在電子商店街中購入商品，購入者係令電子商店街伺服器1檢索滿足所望條件的商品。從被檢索到的商品之中一旦購入者選擇所望之商品，則電子商店街伺服器1係向購入者終端3發送商品網頁。商品網頁，係例如顯示已被購入者所選擇之商品的相關詳細資訊的網頁。於商品網頁中，購入者係選擇商品之個數。又，在商品網頁中存在有，購入者必須要針對特定項目進行選擇的商品。作為這類項目係有例如：商品的顏色、尺寸等。於商品網頁中，購入者，係將已選擇之商品，放入購物籃。購物籃係為，被購入者選擇來作為欲訂購之對象的商品所被放入的虛擬之盛裝物。在訂購已被放入購物籃之商品時，購入者係輸入訂購內容。作為訂購內容係有例如：購入者所致之購入之意思、訂購的商品、商品之個數、購入 費用之支付方法、配送方法、配送日期時間、商品之寄送目標地址等。關於訂購的商品及商品之個數係已被選擇。訂購內容所示的商品，稱為訂購商品。一旦購入者確定訂購內容，則訂購內容就被電子商店街伺服器1所受理。店舖，係一旦訂購商品之購入費用之支付所需之處理完成，則將訂購商品寄送給購入者。
於電子商店街中係販售有各式種類之商品。所被販售的商品之中，係有為了確保使用之際的安全性，由店舖對購入者進行資訊提供會比較理想的商品。在日本，作為這類商品係有例如第1類醫藥品及第2類醫藥品。第1類醫藥品及第2類醫藥品，係由厚生勞動大臣來指定。這些醫藥品，稱為指定醫藥品。指定醫藥品，係為本發明中的對象商品之例子。將購入者所欲購入之指定醫藥品加以使用的人，稱為使用者。指定商品之購入者和使用者有可能是同一人物，也有可能兩者不同。例如，有時候，作為使用者之代理，而由購入者來購入指定商品。為了確保使用者所做的指定醫藥品的使用安全性，電子商店街伺服器1係對欲購入指定醫藥品的購入者，進行：用來從店舖進行符合使用者狀態的個別之資訊提供所需之處理、及以購入者確認了已經理解從店舖所提供之資訊這件事情為條件，使指定醫藥品之販售成立(買賣契約成立)所需之處理。表示使用者之狀態的資訊，稱為使用者狀態資訊。使用者狀態資訊，係為本發明中的狀態資訊之一例。作為使用者狀態資訊係可為例如：使用者之性別、年齡、 症狀、副作用史之有無、副作用之內容、持病之有無、持病之內容、醫療機關之受診之有無、受診之內容、妊娠之有無、是否為授乳中、其他注意事項等。相應於使用者之狀態而從店舖提供給購入者的資訊，稱為留意資訊。作為留意資訊係可為例如：用法、用量、使用上之留意點、使用後應注意之事項、質問之有無之詢問等。此外，指定醫藥品，係除了第1類醫藥品及第2類醫藥品以外，還可包含例如第3類醫藥品。又，指定醫藥品係亦可為只有第1類醫藥品。又，異於指定醫藥品的商品之中的特定之商品，也可作為上述資訊提供之對象的商品。作為此種商品係有例如：與食物過敏有關連性的食材或營養食品等。於本實施形態中，係需要留意資訊之提供的商品係假設為第1類醫藥品及第2類醫藥品來進行說明。不需要留意資訊之提供的商品，稱為一般商品。
接著說明，指定醫藥品之購入的相關程序之概要。圖2係指定醫藥品之購入的相關程序之概要的流程圖。首先，電子商店街伺服器1，係受理將購入者所訂購之指定醫藥品予以使用的使用者之使用者狀態資訊(步驟S1)。應輸入的使用者狀態資訊係可為，例如由店舖針對每一指定商品預先定義。購入者係可例如，於指定醫藥品之商品網頁中，輸入使用者狀態資訊。使用者狀態資訊之輸入後，一旦購入者進行將指定醫藥品放入購物籃所需之操作，則購入者終端3係將使用者狀態資訊，發送至電子商店街伺服器1。此外，電子商店街伺服器1，係例如在 進行將指定醫藥品放入購物籃所需之操作時，亦可為，將用來輸入使用者狀態資訊所需之網頁發送至購入者終端3，將該網頁中所被輸入之使用者狀態資訊予以接收。
其後，購入者，係針對已被放入購物籃之商品，輸入訂購內容。購入者終端3，係將已被輸入之訂購內容，發送至電子商店街伺服器1，電子商店街伺服器1係將訂購內容予以受理(步驟S2)。電子商店街伺服器1，係將訂購內容與使用者狀態資訊建立關連，記憶在電子商店街伺服器1所具備之記憶手段中。若訂購商品為指定醫藥品，則電子商店街伺服器1係還會與訂購內容建立關連而將確認狀態記憶在記憶手段中。確認狀態，係表示購入者是否確認了已經理解來自店舖之留意資訊的狀態。確認狀態，係大致可分成被設定為確認未完成與確認完成之任一者。訂購內容受理時之確認狀態係為確認未完成。以後，電子商店街伺服器1，係可將確認狀態，提供給店舖側(步驟S3)。此時，電子商店街伺服器1，係提供確認狀態，以使得訂購商品之販售成立所需之處理是否可行，能夠被判定。電子商店街伺服器1，係例如將顯示接單之相關資訊的網頁發送至店舖終端2時，在該網頁中包含表示確認狀態的資訊。於本實施形態中，例如訂購商品之寄送，是被規定成訂購商品之販售成立所需之處理。亦即，於本實施形態中，確認狀態，係為用來判定訂購商品是否可寄送所需之資訊。此外，例如，亦可將店舖向購入者發送用來確認訂購內容所需之電子郵件這件事情，規定成訂 購商品之販售成立所需之處理。
針對指定醫藥品的訂購內容受理後，電子商店街伺服器1，係將使用者狀態資訊提供給店舖終端2(步驟S4)。店舖終端2，係相應於使用者狀態資訊而生成留意資訊(步驟S5)。例如，店舖中所屬的藥劑師，會將相應於使用者狀態資訊的留意資訊予以輸入。店舖終端2係將留意資訊發送至電子商店街伺服器1，電子商店街伺服器1係將留意資訊提供給購入者終端3(步驟S6)。此時，電子商店街伺服器1，係以可確認留意資訊的方式，提供留意資訊。購入者，係對從店舖所提供之留意資訊，輸入回答。如此一來，購入者終端3，係將已被輸入之回答，發送至電子商店街伺服器1。一旦購入者進行回答已經理解留意資訊之意旨所需之操作，則電子商店街伺服器1係將從購入者終端3所發送的回答，當作表示購入者已經確認理解留意資訊的通知而加以受理(步驟S7)。受理該通知的電子商店街伺服器1，係將確認狀態更新成確認完成(步驟S8)。
接受確認狀態之提供的店舖，係根據確認狀態，判定訂購商品之販售成立所需之處理是否可行。於本發實施形態中，店舖係判定訂購商品之寄送是否可行。例如，亦可為，除了確認狀態之外，作為其他用來判定訂購商品之寄送是否可行所需之資訊，係為結帳狀態。結帳狀態，係為本發明中的處理狀態之一例。結帳狀態，係表示訂購商品之購入費用之支付所需之處理是否已經完成之狀 態。結帳狀態，係可被設定成處理未完成與處理完成之任一者。確認狀態為確認未完成，或結帳狀態為處理未完成時，則店舖係判定訂購商品之寄送為不可。確認狀態為確認完成，且結帳狀態為處理完成時，店舖係判定訂購商品之寄送為可行。然後，店舖係寄送訂購商品(步驟S9)。此外，若想定將店舖向購入者發送用來確認訂購內容所需之電子郵件這件事情，被規定成訂購商品之販售成立所需之處理，則例如，若確認狀態是確認完成，則亦可為，店舖係無關於結帳狀態為何，都判定成販售成立所需之處理係為可行。
一般商品和指定醫藥品間，來自購入者的訂購內容之送訊為止的程序，基本上係為相同。關於訂購指定醫藥品所需之使用者狀態資訊，也是可由購入者用和商品之顏色或尺寸等之項目相同的感覺來輸入。因此，對購入者而言，程序容易理解。此外，例如被訂購內容發送後，亦可由電子商店街伺服器1來進行控制令購入者輸入使用者狀態資訊。又，電子商店街伺服器1，係在訂購內容被受理後，將表示購入者是否已確認留意事項的確認狀態加以提供，而可判定販售成立所需之處理是否可行。因此，可抑制店舖錯誤進行販售成立所需之處理。
〔1-2.電子商店街伺服器之構成〕
接著，關於電子商店街伺服器1之構成，使用圖3及圖4來說明。圖3(a)係本實施形態所述之電子商店街伺服 器1之概要構成之一例的區塊圖。如圖3(a)所示，電子商店街伺服器1係具備有：通訊部11、記憶部12、輸出入介面13、系統控制部14。然後，系統控制部14與輸出入介面13，係透過系統匯流排15而連接。
通訊部11，係連接至網路NW，控制著與店舖終端2或購入者終端3等的通訊狀態。
記憶部12係由例如硬碟機等所構成。記憶部12，係為本發明中的訂購內容記憶手段、確認狀態記憶手段、狀態記憶手段、及狀態資訊記憶手段之一例。例如，訂購內容記憶手段、確認狀態記憶手段、狀態記憶手段、及狀態資訊記憶手段之其中至少2個記憶手段係亦可為同一記憶裝置，亦可這些記憶手段都是彼此互異的記憶裝置。在該記憶部12中係建構有：會員DB12a、店舖DB12b、商品DB12c、購物籃DB12d、訂購DB12e、訊息DB12f等之資料庫。「DB」係為資料庫的簡稱。
圖4(a)係會員DB12a中所被登錄之內容之一例的圖示。會員DB12a中係被登錄有，對電子商店街進行了會員登錄的購入者的相關之會員資訊。具體而言，會員DB12a中係有使用者ID、密碼、暱稱、姓名、出生年月日、性別、郵遞區號、住址、電話號碼、電子郵件位址、信用卡資訊等之購入者的屬性，是對每位購入者對應關連而被登錄。
圖4(b)係店舖DB12b中所被登錄之內容之一例的圖示。店舖DB12b中係被登錄有，在電子商店街中 販售商品的店舖的相關之店舖資訊。具體而言，在店舖DB12b中，店舖ID、店舖之名稱、郵遞區號、地址、電話號碼、FAX號碼、電子郵件位址等之店舖之屬性，是對每一店舖建立對應而登錄。店舖ID，係為店舖的識別資訊。
圖4(c)係商品DB12c中所被登錄之內容之一例的圖示。商品DB12c中係被登錄有，電子商店街中所販售之商品的相關之商品資訊。商品資訊係含有，由店舖所登錄的資訊。具體而言，商品DB12c中係有店舖ID、商品ID、商品代碼、類型ID、商品名、商品影像之URL、商品說明、價格、庫存數及狀態質問資訊等，對店舖所販售之每一商品對應關連而被登錄。店舖ID，係表示商品的販售來源之店舖。商品ID係為，店舖用來管理所販售之商品用的商品之識別資訊。商品代碼，係為識別商品的代碼編號。當有複數店舖販售同一商品時，相同的商品代碼係會被賦予至各個商品。作為商品代碼，係有例如JAN(Japanese Article Number Code)代碼。類型ID，係在各種商品類型之中，用來識別商品所屬類型所需之識別資訊。類型ID之中，係有表示第1類醫藥品的類型ID、和表示第2類醫藥品的類型ID存在。系統控制部14，係可根據類型ID，來識別商品是否為指定醫藥品。狀態質問資訊，係在類型ID是表示指定醫藥品時，會被登錄。狀態質問資訊，係用來質問指定醫藥品之使用者之狀態所需的資訊。例如，狀態質問資訊，係亦可針對每一質問， 含有表示質問內容的文字、和表示對質問之回答之選項的文字。
圖4(d)係購物籃DB12d中所被登錄之內容之一例的圖示。購物籃DB12d中係被登錄有，關於被放入購物籃之商品的購物籃資訊。具體而言，在購物籃DB12d中，購物籃ID、登錄日期時間、使用者ID、店舖ID、商品ID、商品之個數、使用者狀態資訊等，係對每一被放入購物籃之商品，建立對應而登錄。購物籃ID，係為購物籃資訊的識別資訊。登錄日期時間，係表示商品被放入購物籃的日期時間。使用者ID，係表示將商品放入購物籃的購入者。店舖ID及商品ID之組合，係表示已被放入購物籃之商品。已被放入購物籃之商品是指定醫藥品時，購物籃DB12d中會登錄有使用者狀態資訊。購物籃DB12d中所被登錄的使用者狀態資訊，係表示使用已被放入購物籃之商品的使用者之狀態。
圖4(e)係訂購DB12e中所被登錄之內容之一例的圖示。訂購DB12e中係被登錄有關於商品之訂購的訂購資訊。訂購資訊，係被使用來作為店舖進行接單管理所需之資訊，並且被使用來作為購入者進行訂購的履歷資訊。訂購履歷，係為訂購內容被受理的履歷。訂購履歷，係亦可表示為例如購入履歷。在訂購DB12e中，具體而言，訂購號碼、受理日期時間、使用者ID、店舖ID、商品ID、商品之個數、結帳方法、寄送目的地資訊、配送日期時間指定旗標、指定配送日期時間、取消旗標、商品 區分、使用者狀態資訊、結帳狀態、確認狀態、寄送狀態等，是每次電子商店街伺服器1從購入者受理訂購內容時，就被建立對應而登錄。訂購號碼，係為訂購之識別號碼。受理日期時間，係訂購內容被受理的日期時間。
使用者ID、店舖ID、商品ID、商品之個數、結帳方法、寄送目的地資訊、配送日期時間指定旗標、及指定配送日期時間，係表示訂購內容。使用者ID，係表示訂購商品的購入者。店舖ID係表示訂購目標店舖。店舖ID及商品ID之組合係表示訂購商品。結帳方法，係表示商品購入費用之支付方法。作為結帳方法係有例如：信用卡結帳、銀行匯款、便利商店之支付、貨到付款等。寄送目的地資訊，係含有商品之寄送目的地的郵遞區號、地址、姓名等。配送日期時間指定旗標，係表示購入者是否指定商品之配送日或配送日期時間。指定配送日期時間，係配送日期時間指定旗標被設定為TRUE時，會被登錄。指定配送日期時間，係表示所被指定的配送日或配送日期時間。取消旗標係表示訂購內容之受理是否被取消。商品區分，係表示訂購商品是否為指定醫藥品或是否不須提供留意資訊的一般商品。若商品區分是指定醫藥品時則訂購DB12e中會登錄有使用者狀態資訊。訂購DB12e中所被登錄的使用者狀態資訊，係表示使用訂購商品的使用者之狀態。
結帳狀態，係表示訂購商品之購入費用之支付所需之處理的狀態。結帳狀態，係被設定成例如處理未 完成與處理完成之任一者。處理未完成，係表示購入費用之支付所需之處理尚未完成。處理完成，係表示購入費用之支付所需之處理已經完成。例如，亦可為，根據電子商店街伺服器1或來自店舖之從業員等之操作，結帳狀態係被更新成處理完成。例如，結帳方法是信用卡結帳時，則例如由電子商店街伺服器1執行利用信用卡的購入費用支付所需之授權處理，在獲得信用卡之利用之授權時，電子商店街伺服器1係將結帳狀態更新成處理完成。若結帳方法是銀行匯款或便利商店之支付時，則亦可為，例如，店舖係一旦確認來自購入者的入金，則藉由操作店舖終端2，令電子商店街伺服器1將結帳狀態更新成處理完成。
確認狀態，係在商品區分是指定醫藥品時，被登錄在訂購DB12e中。確認狀態，係大致可分成被設定為確認未完成與確認完成之任一者。作為確認未完成係存在有例如：店舖送訊前、購入者回答前、回答後繼續中。店舖送訊前，係表示處於店舖發送留意資訊前之狀態。購入者回答前，係表示店舖發送留意資訊後，購入者尚未對留意資訊進行回答的狀態。回答後繼續中係表示，購入者雖然一度對留意資訊做了回答，但是關於留意資訊之至少一部分之項目尚未從購入者獲得確認的狀態。
寄送狀態，係表示訂購商品之寄送的狀態。寄送狀態，係可被設定成例如：不可寄送、等待寄送、及寄送完畢等之任一者。不可寄送，係表示無法寄送訂購商品的狀態。等待寄送，係表示是處於可寄送訂購商品的狀 態，且訂購商品尚未被寄送的狀態。寄送完畢，係表示訂購商品已被寄送。例如，亦可根據來自店舖之從業員的操作，寄送狀態會被更新。
圖4(f)係訊息DB12f中所被登錄之內容之一例的圖示。訊息DB12f中，若訂購商品是指定醫藥品時，則會登錄有購入者與店舖之間所交換的訊息。具體而言，在訊息DB12f中，訂購號碼、訊息號碼、訊息之主旨、店舖訊息及店舖送訊日期時間等，係每次從店舖終端2往電子商店街伺服器1發送訊息時，就被登錄。訊息DB12f中所被登錄的訂購號碼，係表示來自店舖之訊息所被建立關連對應到的訂購內容之訂購號碼。訊息號碼，係為表示從店舖所發送之訊息之順序的號碼。店舖訊息，係為從店舖所發送之訊息。訊息號碼為1號的店舖訊息，係為留意資訊。店舖送訊日期時間，係表示店舖訊息所被發送的日期時間。對從店舖所發送之訊息若從購入者有發送回答之訊息時，則訊息DB12f中係還會被登錄有購入者訊息及購入者送訊日期時間。購入者訊息，係為從購入者所發送的訊息。購入者送訊日期時間，係表示購入者訊息所被發送的日期時間。
接著說明記憶部12中所記憶之其他資訊。記憶部12中係記憶著，用來顯示網頁所需的各種資料，例如HTML(HyperText Markup Language)文件、XML(Extensible Markup Language)文件、影像資料、文字資料、電子文書等。例如，記憶部12中係記憶著，與各確認 狀態對應的確認狀態小圖示之影像資料。又，記憶部12中係記憶有各種設定值。
又，在記憶部12中係記憶有作業系統、WWW(World Wide Web)伺服器程式、DBMS(Database Management System)、電子商務管理程式等各種程式。電子商務管理程式，係用來執行關於電子商務之各種處理所需的程式。此外，各種程式例如可從其他伺服器裝置等透過網路NW而取得，也可記錄在光碟等之記錄媒體中然後透過驅動機裝置而被讀取。又，電子商務管理程式等係亦可為程式產品。
輸出入介面13，係在通訊部11及記憶部12與系統控制部14之間，進行介面處理。
系統控制部14，係由CPU14a、ROM(Read Only Memory)14b、RAM(Random Access Memory)14c等所構成。CPU14a係為處理器之一例。此外，本發明係亦可對異於CPU的各種處理器做適用。記憶部12、ROM14b及RAM14c，係皆為記憶體之一例。此外，本發明係亦可對異於硬碟、ROM及RAM的各種記憶體做適用。
此外，電子商店街伺服器1係亦可由複數伺服器裝置所構成。例如，於電子商店街中進行商品之訂購等之處理的伺服器裝置、進行指定醫藥品的相關資訊提供所需之處理的伺服器裝置、隨應於來自店舖終端2或購入者終端3之請求而發送網頁的伺服器裝置、及管理資料庫 的伺服器裝置等，亦可彼此用LAN等而被連接。
〔1-3.系統控制部之機能概要〕
接著，使用圖3(b)，說明系統控制部14的機能概要。圖3(b)係本實施形態所述之宿泊設施預約伺服器1的系統控制部14的機能區塊之一例的圖示。系統控制部14，係藉由CPU14a讀出電子商務管理程式等之程式並執行，而如圖3(b)所示，成為使用者狀態資訊受理部141、訂購內容受理部142、訊息處理部143、狀態控制部144、接單資訊提供部145、訂購履歷提供部146等而發揮機能。使用者狀態資訊受理部141，係為本發明中的狀態資訊受理手段之一例。訂購內容受理部142，係為本發明中的訂購內容記憶控制手段、確認狀態記憶控制手段及狀態記憶控制手段、狀態資訊記憶控制手段之一例。訊息處理部143，係為本發明中的留意資訊輸出手段、通知資訊輸出手段之一例。訊息處理部143，係為本發明中的確認通知受理手段之一例。狀態控制部144，係為本發明中的更新手段之一例。接單資訊提供部145，係為本發明中的確認狀態輸出手段之一例。訂購履歷提供部146，係為本發明中的連結資訊提示控制手段之一例。
使用者狀態資訊受理部141，係若購入者所訂購之商品是指定醫藥品時，則將使用該商品的使用者之使用者狀態資訊，從購入者予以受理。訂購內容受理部142，係在從購入者終端2往電子商店街伺服器1發送商 品之訂購內容時，將該訂購內容予以受理。然後，訂購內容受理部142，係將所受理到的訂購內容、被設定成處理未完成的結帳狀態、被設定成不可寄送的寄送狀態、已被使用者狀態資訊受理部141所受理的使用者狀態資訊等，建立關連，成為訂購資訊而記憶在訂購DB12e中。若已被受理之訂購內容所示之訂購商品是指定醫藥品時，則訂購內容受理部142，係還會與訂購內容建立關連而將被設定成店舖送訊前(確認未完成)的確認狀態，記憶在訂購DB12e中。訊息處理部143係進行，從店舖終端2所發送之店舖訊息對訊息DB12f的登錄，以及將店舖訊息提供給購入者終端3所需之處理。又，訊息處理部143，係在訂購商品是指定醫藥品時，將隨應於訂購商品與使用者狀態資訊而生成的留意資訊，讓購入者可確認地予以輸出。又，訊息處理部143係進行，從購入者終端3所發送之購入者訊息對訊息DB12f之登錄以及將購入者訊息提供給店舖終端2所需之處理。又，訊息處理部143，係將表示購入者已經確認理解訊息處理部143所輸出之留意資訊的通知，從購入者終端3予以受理。狀態控制部144，係在表示購入者已確認理解留意資訊的通知是已被訊息處理部143所受理時，將訂購DB12e中所記憶之確認狀態，更新成確認完成。接單資訊提供部145，係將接單管理用之網頁，發送至店舖終端2。接單管理用之網頁，係用來管理對店舖而已被受理之訂購內容所示之訂購所需之網頁。又，接單資訊提供部145，係將訂購DB12e中所記憶之確 認狀態，輸出成可以判定訂購DB12e中所記憶之訂購內容所示之訂購商品之販售成立所需之處理是否可行。訂購履歷提供部146，係將訂購履歷網頁發送至購入者終端3。訂購履歷網頁，係為表示來自購入者之訂購之履歷的網頁。各部之處理細節將於後述。
〔1-4.資訊處理系統之動作〕 〔1-4-1.系統全體之動作〕
接著，針對資訊處理系統S1之全體的動作，使用圖5乃至及圖15來說明。圖5及圖6係本實施形態所述之資訊處理系統S1之處理之一例的序列圖。購入者，係例如藉由操作購入者終端3，令電子商店街伺服器1檢索商品。購入者，係一旦從被檢索到的商品之中，選擇所望之商品，例如某種指定醫藥品，則如圖5所示，電子商店街伺服器1的系統控制部14，係隨應於來自購入者終端3之要求，而將已被選擇的指定醫藥品之商品網頁，發送至購入者終端3(步驟S11)。
圖7係指定醫藥品之商品網頁之顯示例的圖示。如圖7所示，商品網頁中係顯示有商品的相關資訊，例如：商品名、價格、商品之影像、商品之說明等。又，在商品網頁中係顯示有購物籃登錄鈕201、個數輸入欄202。購物籃登錄鈕201，係用來將商品網頁中所示之商品放入購物籃所需的按鈕。個數輸入欄202，係用來輸入所訂購之商品之數量所需之輸入欄位。指定醫藥品的情況 下，在商品網頁中係還會顯示出狀態質問資訊。具體而言，關於使用者之狀態的每一質問，會顯示出質問內容203和選擇選單204。質問內容203，係為表示質問內容的文字。選擇選單204，係用來選擇對質問之回答所需之下拉式選單。商品網頁之HTML文件生成時，系統控制部14係根據商品DB12c中所被登錄之商品資訊而生成HTML文件。若商品資訊中所含的類型ID是表示指定醫藥品時，則系統控制部14係從商品資訊取得狀態質問資訊。然後，系統控制部14，係根據狀態質問資訊，將用來顯示質問內容203和選擇選單204所需之資料，追加至商品網頁之HTML文件。
購入者，係在訂購已選擇的指定醫藥品時，因應需要而操作選擇選單204來選擇使用者之狀態(步驟S12)。然後，一旦購入者選擇購物籃登錄鈕201(步驟S13)，則購入者終端3係將購物籃登錄要求，發送至電子商店街伺服器1(步驟S14)。購物籃登錄要求係含有例如：購入者之使用者ID、放入購物籃之商品所對應的店舖ID及商品ID、商品之個數等。又，購物籃登錄要求，係含有使用者狀態資訊。例如，在使用者狀態資訊中，係有每一質問而表示質問內容之文字和表示購入者已選擇之狀態之文字，係被建立對應而登錄。使用者狀態資訊受理部141，係將購物籃登錄要求中所含的店舖ID及商品ID所對應之類型ID，從商品DB12c加以取得，判定類型ID是否表示指定醫藥品。類型ID並非表示指定醫藥品時， 則使用者狀態資訊受理部141，係將所接收之購物籃登錄要求中所含的資訊，當作購物籃資訊而登錄至購物籃DB12d中。另一方面，若類型ID是表示指定醫藥品時，則使用者狀態資訊受理部141係將注意喚起網頁，發送至購入者終端3(步驟S15)。注意喚起網頁，係為用來對訂購指定醫藥品之購入者催促注意所需之網頁。購入者係一旦選擇了注意喚起網頁中所被顯示的用來表示同意注意事項所需的按鈕，則使用者狀態資訊受理部141係根據來自購入者終端3的要求，購物籃登錄要求中所含的資訊，當作購物籃資訊而登錄至購物籃DB12d中(步驟S16)。如此一來，使用者狀態資訊受理部141係受理使用者狀態資訊。
接下來，系統控制部14，係將購物籃網頁，發送至購入者終端3(步驟S17)。購物籃網頁，係為顯示已經放入購物籃之商品的相關資訊的網頁。於購物籃網頁中，購入者係一旦選擇用來訂購被放入購物籃之指定醫藥品所需的按鈕，則訂購內容受理部142係根據來自購入者終端3的要求，將訂購內容輸入網頁發送至購入者終端3(步驟S18)。訂購內容輸入網頁，係用來輸入訂購內容之至少一部分所需之網頁。於訂購內容輸入網頁中，購入者係輸入例如結帳方法、配送方法、配送日期時間之指定之有無、指定配送日期時間、寄送目標地址等。然後，一旦購入者選擇了用來確定訂購內容所需的按鈕，則購入者終端3係將所被輸入的資訊、及購入者的使用者ID、訂購 商品所對應之店舖ID及商品ID、商品個數等之訂購內容的資訊，發送至電子商店街伺服器1(步驟S19)。訂購內容受理部142，係將含有所接收到之資訊的訂購資訊，登錄至訂購DB12e(步驟S20)。此時，訂購內容受理部142，係於訂購資訊中，將寄送狀態設定成不可寄送，將結帳狀態設定成處理未完成。又，訂購內容受理部142，係將取消旗標設定成FALSE。訂購商品是指定醫藥品時，訂購內容受理部142，係從購物籃DB12d取得使用者狀態資訊，將使用者狀態資訊、和被設定成店舖送訊前(確認未完成)的確認狀態，包含在訂購資訊中。如此一旦受理了訂購內容，則訂購內容受理部142係將訂購內容受理完成網頁，發送至購入者終端3(步驟S21)。訂購內容受理完成網頁，係為顯示表示訂購內容已被受理之訊息的網頁。又，訂購內容受理部142，係向訂購資訊中所含的店舖ID所示的店舖，發送訂購內容受理通知郵件(步驟S22)。訂購內容受理通知郵件，係針對店舖所販售之商品而通知訂購內容已被受理的電子郵件。訂購內容受理通知郵件之本文係含有例如：訂購內容之至少一部分、訂購號碼、受理日期時間等。又，訂購內容受理通知郵件之本文，係亦可含有例如使用者狀態資訊。
閱讀了訂購內容受理通知郵件的店舖之從業員，係進行令接單資訊被顯示所需之操作。如此一來，接單資訊提供部145，係隨應於來自店舖終端2之要求而將接單一覽網頁發送至店舖終端2(步驟S23)。接單一覽網 頁，係顯示對店舖之訂購之一覽的網頁。接單一覽網頁，係為本發明中的販售者專用之資訊之一例。圖8(a)係接單一覽網頁之顯示例的圖示。如圖8(a)所示，接單一覽網頁中，係針對已被受理之每一訂購內容，顯示有例如訂購日期時間、訂購號碼、結帳方法、結帳狀態、對購入者之請款金額、寄送狀態、寄送日等。又，指定醫藥品之訂購的相關資訊所被顯示的行中，係顯示有確認狀態小圖示211。確認狀態小圖示，係為表示確認狀態的影像。確認狀態小圖示，其外關係隨著確認狀態而改變。例如，確認狀態小圖示之顏色、形狀、模樣、大小等係可改變。圖8(b)係相應於確認狀態的確認狀態小圖示之外觀之例的圖示。圖8(b)之例子中，隨著確認狀態，確認狀態小圖示之顏色會改變。圖8(a)所示之確認狀態小圖示211，係表示確認狀態是店舖送訊前。藉由確認狀態小圖示211被顯示，店舖係可容易辨識訂購商品是否為需要提供留意資訊的指定醫藥品，同時，可容易辨識現在之確認狀態。確認狀態小圖示，係隨著確認狀態而改變外觀的影像之一例。此外，此種影像係不限於小圖示。例如，亦可採用表示圖形、記號等的影像。
一旦從業員選擇某個訂購號碼，則隨應於來自店舖終端2之要求，接單資訊提供部145係將接單管理網頁發送至店舖終端2(步驟S24)。接單管理網頁，係為用來管理已被選擇之訂購號碼所示的訂購所需的網頁。圖9係接單管理網頁之顯示例的圖示。如圖9所示，接單管 理網頁中係顯示有，例如，訂購DB12e中所被登錄之訂購資訊之內容等。例如，接單管理網頁中係顯示有：訂購號碼、受理日期時間、購入者之姓名、商品ID、商品名、商品之個數、請款金額、寄送目的地資訊、結帳方法、寄送目的地資訊、指定配送日期時間、結帳狀態、寄送狀態等。甚至在接單管理網頁中係還顯示有：結帳授權要求鈕221、寄送狀態更新要求鈕222等。結帳授權要求鈕221係為，若結帳方法是信用卡結帳，則用來向電子商店街伺服器1要求請款金額之結帳之授權所需之按鈕。若結帳方法非信用卡結帳，則取代結帳授權要求鈕221，改為顯示結帳狀態更新要求鈕。結帳狀態更新要求鈕，係為用來將結帳狀態更新成處理完成所需之按鈕。寄送狀態更新要求鈕222，係用來將寄送狀態從不可寄送更新成等待寄送所需之按鈕。訂購商品是指定醫藥品時，接單管理網頁中還會顯示確認狀態及使用者狀態。
例如，購入者一旦選擇結帳授權要求鈕221，則購入者終端3係將結帳授權要求發送至電子商店街伺服器1(步驟S25)。相應於此，狀態控制部144，係根據購入者之信用卡資訊，例如與信用卡公司的伺服器裝置合作，執行利用信用卡之支付所需之授權處理。然後，狀態控制部144，係只有在取得了表示支付已被授權的處理結果時，才將結帳狀態更新成處理完成(步驟S26)。此外，若結帳方法並非信用卡結帳，則從業員係在確認了購入者所做的費用支付所需之處理後，選擇結帳狀態更新要求鈕。 如此一來，狀態控制部144係將結帳狀態更新成處理完成。
其後，根據從業員之操作，例如接單資訊提供部145，係如圖6所示將接單一覽網頁發送至店舖終端2(步驟S31)。於接單一覽網頁中，一旦從業員選擇例如確認狀態小圖示211(步驟S32)，則隨應於來自店舖終端2之要求，訊息處理部143係將訊息管理網頁發送至店舖終端2(步驟S33)。訊息管理網頁，係用來顯示已被選擇之確認狀態小圖示211所對應之訂購所相關之購入者訊息所需之網頁。圖10(a)係訊息管理網頁之顯示例的圖示。如圖10(a)所示，訊息管理網頁中係顯示有：確認狀態小圖示231、訊息一覽顯示領域232、訊息顯示領域233及新增訊息鈕234。訊息一覽顯示領域232中係顯示購入者訊息之一覽。購入者訊息係被當成對店舖訊息之回答而發送。因此，針對某個訂購若店舖訊息一次都沒被發送時，亦即留意資訊未被生成時，則購入者訊息係未被通常登錄。訊息顯示領域233，係顯示從訊息一覽顯示領域232所選擇之購入者訊息。新增訊息鈕234，係用來輸入店舖訊息所需之按鈕。
一旦從業員選擇新增訊息鈕234，則隨應於來自店舖終端2之要求，訊息處理部143係將訊息輸入網頁，發送至店舖終端2(步驟S34)。圖10(b)係訊息輸入網頁之顯示例的圖示。如圖10(b)所示，訊息輸入網頁中係顯示有：確認狀態小圖示241、主旨輸入欄242、訊息輸 入欄243、送訊鈕244。主旨輸入欄242，係用來輸入店舖訊息之主旨所需之輸入欄位。訊息輸入欄243，係用來輸入店舖訊息所需之輸入欄位。送訊鈕，係用來發送已被輸入之主旨及店舖訊息所需之按鈕。
於訊息輸入網頁中，從業員係輸入主旨及店舖訊息。針對某個訂購而首次輸入店舖訊息時，從業員係隨應於接單管理網頁中所顯示的使用者狀態資訊而輸入留意資訊(步驟S35)。此外，訊息管理網頁或訊息輸入網頁中亦可顯示使用者狀態資訊。留意資訊輸入時，從業員係針對每一留意事項，輸入留意事項之內容，並且例如在留意事項之內容之前，輸入表示勾選盒的文字。該文字稱為勾選盒顯示文字。勾選盒顯示文字，係亦可為例如表示四角形的文字。勾選盒顯示文字，係在對購入者提示留意資訊時，令用來進行確認已經理解留意資訊之操作所需之勾選盒被實際顯示所需之資料。又，在從購入者受理質問等的情況下，從業員係輸入例如「：」。從業員一旦輸入留意資訊，就選擇送訊鈕244。如此一來，店舖終端2，係將作為主旨及店舖訊息之留意資訊，發送至電子商店街伺服器1(步驟S36)。一旦接收留意資訊，訊息處理部143係將留意資訊登錄至訊息DB12f，同時，向購入者發送店舖訊息登錄通知郵件(步驟S37)。店舖訊息登錄通知郵件，係用來將店舖訊息已被登錄之事實，及必須確認留意資訊這件事情，通給購入者的電子郵件。店舖訊息登錄通知郵件，係為本發明中的通知資訊之一例。
閱讀了店舖訊息登錄通知郵件的購入者，係操作購入者終端3而要求訂購履歷。如此一來，訂購履歷提供部146係將訂購履歷網頁，發送至購入者終端3(步驟S38)。藉此，訂購履歷提供部146，係令前往留意資訊之連結，被購入者終端3所提示。圖11係訂購履歷網頁之顯示例的圖示。如圖11所示，訂購履歷網頁中，係隨著目前為止購入者所發送的每一訂購內容，顯示有訂購內容顯示領域251。訂購內容顯示領域251中，係顯示訂購內容之至少一部分。例如，訂購內容顯示領域251中係顯示有：商品名、商品之購入目標店舖之名稱、價格、商品之影像等。訂購商品是指定醫藥品時，訂購內容顯示領域251中係還會顯示有店舖訊息確認連結252。店舖訊息確認連結252，係為本發明中的連結資訊之一例。店舖訊息確認連結252，係為前往針對所對應之訂購的訊息確認網頁之超連結。訊息確認網頁，係用來令店舖訊息被顯示所需之網頁，是將針對店舖訊息的回答當成購入者訊息進行輸入所需之網頁。此外，例如訊息處理部143，係亦可使店舖訊息登錄通知郵件中，含有前往訊息確認網頁之URL。
一旦購入者選擇店舖訊息確認連結252(步驟S39)，則購入者終端3係將訊息確認網頁之URL，發送至電子商店街伺服器1(步驟S40)。訊息處理部143，係根據所接收之URL而特定出訂購號碼，從訊息DB12f取得訂購號碼所對應之主旨、店舖訊息、店舖送訊日期時間。接 下來，訊息處理部143，係根據所取得的資訊而生成訊息確認網頁，發送至購入者終端3(步驟S41)。若店舖訊息係被複數登錄時，則訊息處理部143係亦可為例如使得最新之店舖訊息被顯示的方式，來生成訊息確認網頁。
圖12(a)係訊息確認網頁之顯示例的圖示。如圖12(a)所示，訊息確認網頁中係顯示有：訊息一覽顯示領域261、訊息顯示領域262及OK鈕265。訊息一覽顯示領域261中係顯示店舖訊息之一覽。訊息顯示領域262，係顯示從訊息一覽顯示領域261所選擇之店舖訊息。此處，店舖之從業員所輸入的勾選盒顯示文字，係變化成勾選盒263。又，「：」之後會顯示輸入欄264。購入者係因應需要而在輸入欄264中輸入質問內容等。OK鈕265，係用來發送購入者訊息所需之按鈕。勾選盒263及OK鈕265，係皆為本發明中的確認要素之一例。如此，訊息處理部143，係連同留意資訊，將用來表示確認已經理解留意資訊而可操作的勾選盒263及OK鈕265，一併加以提示。購入者，係針對每一理解的留意事項，操作勾選盒263，將勾選盒263設定成已勾選(步驟S42)。圖12(b)係對所有的留意事項的勾選盒263都被設定成已勾選的訊息確認網頁之例子。購入者一旦選擇OK鈕265，則購入者終端3係將已被輸入之購入者訊息，發送至電子商店街伺服器1(步驟S43)。例如，購入者訊息係含有，訊息顯示領域262中所被顯示的店舖訊息之文字。又，訊息顯示領域262中勾選盒263所被顯示的位置上， 會被插入勾選盒顯示文字。此時，隨著勾選盒263是已勾選還是未勾選，而會被插入不同的勾選盒顯示文字。又，輸入欄264中有被輸入質問內容等的情況下，購入者訊息係還會含有質問內容等。
接收到購入者訊息的狀態控制部144，係若購入者訊息中所含的所有勾選盒顯示文字都表示已勾選時，則將確認狀態更新成確認完成(步驟S44)。所有勾選盒顯示文字都是表示已勾選的購入者訊息，係為本發明中的確認通知之一例。接下來，訊息處理部143，係向店舖發送購入者訊息登錄通知郵件(步驟S45)。購入者訊息登錄通知郵件，係將購入者訊息已被登錄之事實，通知給店舖的電子郵件。閱讀了購入者訊息的從業員，係一旦進行令接單資訊顯示所需之操作，則接單資訊提供部145係將接單一覽網頁，發送至店舖終端2(步驟S46)。圖13(a)係確認狀態被更新成確認完成後的接單一覽網頁之顯示例。如圖13(a)所示，確認狀態小圖示211係表示確認完成。又，結帳狀態係為處理完成。此處，從業員一旦選擇確認狀態小圖示211，則訊息處理部143係將訊息管理網頁發送至店舖終端2。圖13(b)係確認狀態被更新成確認完成後的訊息管理網頁之顯示例。如圖13(b)所示，確認狀態小圖示231係表示確認完成。又，在訊息一覽顯示領域232中所被顯示的主旨旁邊，顯示有表示確認完成的訊息235。又，訊息顯示領域233中所被顯示的購入者訊息中，所有勾選盒顯示文字都表示已勾選。
此外，於訊息確認網頁中，若購入者有至少1個勾選盒尚未勾選，則狀態控制部144係不將確認狀態更新成確認完成。此情況下，訊息處理部143也會發送購入者訊息登錄通知郵件。圖14(a)係確認狀態未被更新成確認完成時的接單一覽網頁之顯示例。如圖14(a)所示，確認狀態小圖示211係表示回答後繼續中。圖14(b)係確認狀態未被更新成確認完成後的訊息管理網頁之顯示例。如圖14(b)所示，確認狀態小圖示231係表示回答後繼續中。又，在訊息一覽顯示領域232中所被顯示的主旨旁邊，顯示有表示回答後繼續中的訊息236。又，訊息顯示領域233中所被顯示的購入者訊息中，至少1個勾選顯示文字係表示未勾選。此種情況下，從業員係令訊息輸入網頁被顯示在店舖終端2，對購入者訊息輸入店舖訊息。此時，從業員係將勾選盒顯示文字輸入一個文字以上。例如購入者輸入有質問內容時，從業員係亦可針對質問內容輸入回答。然後，從業員係輸入，用來確認沒有其他質問等所需之勾選盒顯示文字。其後的店舖與購入者之間的訊息之交換所需之處理，基本上是和步驟S31~S43相同。直到被購入者將所有勾選盒設定成已勾選為止，會重複訊息之交換。
確認狀態被更新成確認完成後的接單一覽網頁中(圖13(a))，一旦從業員選擇確認狀態小圖示211所對應之訂購號碼，則接單資訊提供部145係將接單管理網頁，發送至店舖終端2(步驟S47)。圖15(a)係結帳狀態被 更新成處理完成，且確認狀態被更新成確認完成後的接單管理網頁之顯示例。例如，從業員，係於接單管理網頁或接單一覽網頁中，一旦辨識結帳狀態為處理完成且確認狀態為確認完成，則選擇寄送狀態更新要求鈕222。如此一來，店舖終端2，係將寄送狀態更新要求，發送至電子商店街伺服器1(步驟S48)。接收到寄送狀態更新要求的狀態控制部144，係將寄送狀態變更成等待寄送(步驟S49)，將完成回應發送至店舖終端2。如此一來，店舖終端2係將接單管理畫面中的寄送狀態，變更成等待寄送。圖15(b)係寄送狀態被更新成等待寄送後的接單一覽網頁之顯示例。辨識到接單管理網頁或接單一覽網頁中寄送狀態為等待寄送的從業員，係將訂購商品也就是指定醫藥品，予以寄送。
在圖5及圖6之例中，先進行購入費用之支付所需之處理，其後才進行留意資訊之提供和確認。然而，亦可先進行留意資訊之提供和確認，其後才進行購入費用之支付所需之處理。又，這些處理亦可平行而進行之。
〔1-4-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖16至圖20來說明。圖16係本實施形態所述之電子商店街伺服器1的系統控制部14的訂購內容登錄處理之一例的流程圖。在接收到訂購內容輸入網頁 中所被輸入之訂購內容等時，系統控制部14係執行訂購內容登錄處理(例如圖5步驟S20、S21)。如圖16所示，訂購內容受理部142係生成含有已接收之訂購內容等的訂購資訊(步驟S51)。此時，訂購內容受理部142，係生成新的訂購號碼，同時，取得現在日期時間來作為受理日期時間。接下來，訂購內容受理部142，係將已生成之訂購資訊之寄送狀態設定成不可寄送，將結帳狀態設定成處理未完成(步驟S52)。接下來，訂購內容受理部142，係判定訂購商品是否為指定醫藥品(步驟S53)。具體而言，訂購內容受理部142，係將訂購資訊中所含的店舖ID及商品ID所對應之類型ID，從商品DB12c加以取得。然後，訂購內容受理部142，係若類型ID是表示第1類醫藥品及第2類醫藥品之任一者時，則判定訂購商品為指定醫藥品(步驟S53：YES)。此時，訂購內容受理部142係前進至步驟S54。
步驟S54中，訂購內容受理部142係將訂購資訊之商品區分，設定成指定醫藥品。接下來，訂購內容受理部142，係將訂購資訊中所含的使用者ID、店舖ID及商品ID所對應之使用者狀態資訊，從購物籃DB12d加以取得。然後，訂購內容受理部142，係將使用者狀態資訊，追加至訂購資訊(步驟S55)。接下來，訂購內容受理部142，係對訂購資訊追加確認狀態，將確認狀態設定成店舖送訊前(步驟S56)。接下來，訂購內容受理部142係前進至步驟S58。
於步驟S53中，訂購內容受理部142係在判定訂購商品並非指定醫藥品時(步驟S53：NO)，則前進至步驟S57。步驟S57中，訂購內容受理部142係將商品區分設定成一般商品。接下來，訂購內容受理部142係前進至步驟S58。
步驟S58中，訂購內容受理部142係將所生成的訂購資訊，登錄至訂購DB12e。接下來，訂購內容受理部142，係向發送出訂購內容的購入者，發送訂購內容受理通知郵件(步驟S59)。訂購內容受理部142，係一旦步驟S59結束就結束訂購內容登錄處理。
圖17係本實施形態所述之電子商店街伺服器1的系統控制部14的接單一覽送訊處理之一例的流程圖。從店舖終端2接收接單一覽網頁之要求時，系統控制部14係執行接單一覽送訊處理(例如圖5步驟S23、圖6步驟S31、S46)。接單一覽網頁之要求係含有例如：要求接單一覽網頁的店舖之店舖ID、訂購資訊之檢索條件等。如圖17所示，接單資訊提供部145，係將所接收到的要求中所含的店舖ID所對應之訂購資訊，從訂購DB12e檢索出來(步驟S61)。此時，接單資訊提供部145係檢索，對應於檢索條件的訂購資訊。接下來，接單資訊提供部145係將號碼i設定成1(步驟S62)。又，接單資訊提供部145，係從記憶部12取得要作為樣版的接單一覽網頁之HTML文件。接下來，接單資訊提供部145，係將檢索到的訂購資訊之中第i個訂購資訊之一部分之內容， 例如受理日期時間、訂購號碼、結帳方法、結帳狀態、寄送狀態等，追加至HTML文件(步驟S63)。
接下來，接單資訊提供部145係判定，第i個訂購資訊中所含的商品區分是否為指定醫藥品(步驟S64)。此時，接單資訊提供部145係在判定商品區分是指定醫藥品時(步驟S64：YES)，則前進至步驟S65。於步驟S65中，接單資訊提供部145係取得，第i個訂購資訊中所含的確認狀態所對應之確認狀態小圖示之影像資料之URL。又，接單資訊提供部145，係根據例如第i個訂購資訊中所含的訂購號碼，來生成訊息管理網頁之URL。接下來，接單資訊提供部145，係作為用來顯示確認狀態小圖示所需之資訊，而將含有例如影像資料之URL、訊息管理網頁之URL的標籤資料或腳本，追加至HTML文件。接下來，接單資訊提供部145係前進至步驟S66。另一方面，接單資訊提供部145係在判定商品區分不是指定醫藥品時(步驟S64：NO)，則前進至步驟S66。
於步驟S66中，接單資訊提供部145係判定，號碼i是否和檢索到的訂購資訊之數目一致。此時，接單資訊提供部145係在判定號碼i是和訂購資訊之數目不一致時(步驟S66：NO)，則前進至步驟S67。於步驟S67中，接單資訊提供部145係對號碼i加算1，前進至步驟S63。另一方面，接單資訊提供部145係在判定號碼i是和訂購資訊之數目一致時(步驟S66：YES)，則前進至步驟S68。於步驟S68中，接單資訊提供部145係已完成 的接單一覽網頁的HTML文件，發送至店舖終端2。接單資訊提供部145，係一旦結束步驟S68，就結束接單一覽送訊處理。接收到HTML文件的店舖終端2，係顯示接單一覽網頁。若確認狀態小圖示顯示所需之資訊有被包含在HTML文件中，則店舖終端2係基於該資訊而將確認狀態小圖示之影像資料從電子商店街伺服器1加以取得並顯示。如此一來，例如圖8(a)、圖13(a)、圖14(a)或圖15(b)所示的接單一覽網頁，就被顯示。
圖18係本實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。從店舖終端2接收到店舖訊息時，系統控制部14係執行店舖訊息登錄處理(例如圖6步驟S37)。店舖終端2，係將店舖訊息連同例如主旨、訂購號碼等，發送至電子商店街伺服器1。如圖18所示，訊息處理部143係將接收到之訂購號碼所對應之店舖訊息，從訊息DB12f檢索出來。此時，若對應之店舖訊息未被登錄，則訊息處理部143係將新的訊息號碼設定成1。若對應的店舖訊息有被登錄，則訊息處理部143係對店舖送訊日期時間為最新之訊息號碼加算1，設定新的訊息號碼。又，訊息處理部143，係取得現在日期時間來作為店舖送訊日期時間。接下來，訊息處理部143係將訊息號碼、店舖送訊日期時間、店舖訊息、主旨及訂購號碼，建立對應而登錄在訊息DB12f中(步驟S71)。
接下來，狀態控制部144，係將訂購號碼所對 應之訂購資訊，從訂購DB12e中加以特定，判定訂購資訊中所含的確認狀態是否為店舖送訊前(步驟S72)。此時，狀態控制部144，係在判定確認狀態為店舖送訊前的情況下(步驟S72：YES)，前進至步驟S73。於步驟S73中，狀態控制部144係將確認狀態設定成購入者回答前，前進至步驟S74。另一方面，狀態控制部144，係在判定確認狀態不是店舖送訊前的情況下(步驟S72：NO)，前進至步驟S74。
於步驟S74中，訊息處理部143係發送店舖訊息登錄通知郵件。具體而言，訊息處理部143係將所特定之訂購資訊中所含之使用者ID所對應之電子郵件位址，從會員DB12a加以取得。然後，訂購內容受理部142係生成將所取得之電子郵件位址儲存成送件位址的店舖訊息登錄通知郵件並予以發送。訊息處理部143，係一旦結束步驟S74就結束店舖訊息登錄處理。
圖19係本實施形態所述之電子商店街伺服器1的系統控制部14的訂購履歷送訊處理之一例的流程圖。從購入者終端3接收到訂購履歷網頁之要求時，系統控制部14係執行訂購履歷送訊處理(例如圖6步驟S38)。訂購履歷網頁之要求係含有例如：要求了訂購履歷網頁的購入者之使用者ID、訂購資訊之檢索條件等。如圖19所示，訂購履歷提供部146，係將所接收到的要求中所含的使用者ID所對應之訂購資訊，從訂購DB12e檢索出來(步驟S81)。此時，訂購履歷提供部146係檢索，對應於檢索 條件的訂購資訊。接下來，訂購履歷提供部146係將號碼i設定成1(步驟S82)。又，訂購履歷提供部146，係從記憶部12取得要作為樣版的訂購履歷網頁之HTML文件。接下來，訂購履歷提供部146，係將所取得的訂購資訊之中第i個訂購資訊之一部分的內容，例如：受理日、店舖之名稱、商品名、價格等，追加至HTML文件(步驟S83)。
接下來，訂購履歷提供部146係判定，第i個訂購資訊中所含的商品區分是否為指定醫藥品(步驟S84)。此時，訂購履歷提供部146係在判定商品區分是指定醫藥品時(步驟S84：YES)，則前進至步驟S85。於步驟S85中，訂購履歷提供部146係判定，第i個訂購資訊中所含之確認狀態是否為確認未完成。此時，訂購履歷提供部146係在判定確認狀態是確認未完成時(步驟S85：YES)，則前進至步驟S86。於步驟S86中，訂購履歷提供部146係根據例如第i個訂購資訊中所含的訂購號碼，來生成訊息確認網頁之URL。接下來，訂購履歷提供部146，係作為用來顯示店舖訊息確認連結252所需之資訊，而將例如含有訊息確認網頁之URL的標籤資料，追加至HTML文件。接下來，訂購履歷提供部146係前進至步驟S87。另一方面，訂購履歷提供部146係在判定商品區分並非指定醫藥品時(步驟S84：NO)，或判定確認狀態並非確認未完成時(步驟S85：NO)，則前進至步驟S87。
於步驟S87中，訂購履歷提供部146係判 定，號碼i是否和檢索到的訂購資訊之數目一致。此時，訂購履歷提供部146係在判定號碼i是和訂購資訊之數目不一致時(步驟S87：NO)，則前進至步驟S88。於步驟S88中，訂購履歷提供部146係對號碼i加算1，前進至步驟S83。另一方面，訂購履歷提供部146係在判定號碼i是和訂購資訊之數目一致時(步驟S87：YES)，則前進至步驟S89。於步驟S89中，訂購履歷提供部146係已完成的訂購履歷網頁的HTML文件，發送至店舖終端2。訂購履歷提供部146，係一旦結束步驟S89，就結束訂購履歷送訊處理。接收到HTML文件的購入者終端3，係顯示訂購履歷網頁。若含有訊息確認網頁之URL的標籤資料是被HTML文件所包含，則購入者終端3係根據該資料而顯示店舖訊息確認連結252。如此一來，例如圖11所示的訂購履歷網頁就被顯示。
圖20係本實施形態所述之電子商店街伺服器1的系統控制部14的購入者訊息登錄處理之一例的流程圖。從購入者終端3接收到購入者訊息時，系統控制部14係執行購入者訊息登錄處理(例如圖6步驟S44、45)。購入者終端3，係將購入者訊息連同例如訂購號碼等，發送至電子商店街伺服器1。如圖20所示，訊息處理部143係取得現在日期時間來作為購入者送訊日期時間。又，訊息處理部143，係將所接收之訂購號碼所對應之訊息號碼，從訊息DB12f檢索出來。然後，訊息處理部143，係與被檢索到的訊息號碼之中最新之訊息號碼建立對應，將 購入者訊息及購入者送訊日期時間登錄在訊息DB12f中(步驟S91)。
接下來，狀態控制部144，係從所接收到的購入者訊息中，檢索出勾選盒顯示文字。然後，狀態控制部144，係判定檢索出來的所有勾選盒顯示文字是否表示已勾選(步驟S92)。此時，訊息處理部143，係在判定所有勾選盒顯示文字都表示已勾選時(步驟S92：YES)，則前進至步驟S93。於步驟S93中，訊息處理部143係將所接收到的訂購號碼所對應之訂購資訊，從訂購DB12e中加以特定，將訂購資訊中所含的確認狀態，設定成確認完成。接下來，狀態控制部144係前進至步驟S95。另一方面，訊息處理部143，係在未判定所有勾選盒顯示文字都表示已勾選時(步驟S92：NO)，則前進至步驟S94。於步驟S94中，訊息處理部143係將確認狀態設定成回答繼續中。接下來，狀態控制部144係前進至步驟S95。
於步驟S95中，訊息處理部143係發送購入者訊息登錄通知郵件。具體而言，訊息處理部143係將所特定之訂購資訊中所含之店舖ID所對應之電子郵件位址，從店舖DB12b加以取得。然後，訂購內容受理部142係生成將所取得之電子郵件位址儲存成為送件位址的購入者訊息登錄通知郵件並予以發送。訊息處理部143，係一旦結束步驟S95就結束購入者訊息登錄處理。
如以上說明，若依據本實施形態，則系統控制部14係若購入者所訂購之商品是指定醫藥品時，則從 購入者受理使用商品之使用者的狀態資訊。又，系統控制部14係在從購入者受理了商品之訂購內容時，將該訂購內容記憶在記憶部12中。又，系統控制部14係若訂購商品是指定醫藥品時，則與記憶部12中所記憶之訂購內容建立關連，將被設定成確認未完成的確認狀態，記憶在記憶部12中。又，系統控制部14係將隨應於訂購內容所示之指定醫藥品和已被受理之使用者狀態資訊而生成的留意資訊，輸出成可讓購入者確認。又，系統控制部14係受理表示購入者已經確認理解了留意資訊的購入者訊息。又，系統控制部14係在受理了購入者訊息時，將記憶部12中所記憶之確認狀態，更新成確認完成。又，系統控制部14係將記憶部12中所記憶之確認狀態，輸出成可以判定用來使訂購內容所示之指定醫藥品之販售成立所需的處理是否可行。因此，即使在發送指定醫藥品的訂購內容的情況下，仍可使程序是和一般商品的時候同樣容易理解，同時，在商品寄送之前可進行個別之資訊提供。
又，系統控制部14係若訂購商品是指定醫藥品時，則令店舖訊息確認連結252被購入者終端3所提示。又，系統控制部14係在店舖訊息確認連結252被選擇時，令訊息確認網頁被購入者終端3所提示。又，系統控制部14係根據訊息確認網頁中的OK鈕265有被操作而取得購入者訊息。因此，購入者所做的留意資訊之確認，可變得容易。
又，系統控制部14係令記憶部12中所記憶 之關於訂購內容的接單一覽網頁，被店舖終端2所提示。此時，系統控制部14係若訂購商品是指定醫藥品時，則令確認狀態小圖示211連同接單一覽網頁一起被提示。因此，藉由確認狀態小圖示211，店舖係可容易辨識購入者是否已經確認留意資訊。
〔1-5.變形例〕
接著使用圖21來說明本實施形態的變形例。電子商店街伺服器1，係亦可不是藉由店舖之操作而將寄送狀態更新成等待寄送，而是自動地更新寄送狀態。例如，狀態控制部144，係亦可在確認狀態或結帳狀態被變更的時間點上，判定是否更新寄送狀態。於本變形例中，狀態判定部543係為本發明中的第1寄送狀態更新手段、第2寄送狀態更新手段之一例。
圖21係本變形例所述之電子商店街伺服器1的系統控制部14的寄送狀態控制處理之一例的流程圖。例如，亦可為，在藉由信用卡所致之結帳的授權處理而更新結帳狀態時(圖5步驟S26)，隨應於結帳狀態更新要求而更新結帳狀態時，及確認狀態被更新成確認完成時(圖6步驟S44)，系統控制部14係執行寄送狀態控制處理。
如圖21所示，狀態控制部144係將確認狀態或結帳狀態已被更新的訂購資訊，從訂購DB12e中加以特定。然後，狀態控制部144係判定所特定之訂購資訊中所含之結帳狀態是否為處理完成(步驟S101)。此時，狀態 控制部144係在判定結帳狀態並非處理完成時(步驟S101：NO)，則令寄送狀態控制處理結束。另一方面，狀態控制部144，係在判定結帳狀態是處理完成時(步驟S101：YES)，則前進至步驟S102。於步驟S102中，狀態控制部144係判定所特定之訂購資訊中所含之商品區分是否為指定醫藥品。此時，狀態控制部144係在判定商品區分不是指定醫藥品時(步驟S102：NO)，則前進至步驟S104。另一方面，狀態控制部144係在判定商品區分是指定醫藥品時(步驟S102：YES)，則前進至步驟S103。於步驟S103中，狀態控制部144係判定，所特定之訂購資訊中所含之確認狀態是否為確認完成。此時，狀態控制部144係在判定確認狀態並非確認完成時(步驟S103：NO)，則令寄送狀態控制處理結束。另一方面，狀態控制部144，係在判定確認狀態為確認完成時(步驟S103：YES)，則前進至步驟S104。於步驟S104中，狀態控制部144係將所特定之訂購資訊中所含之寄送狀態設定成等待寄送，令狀態控制處理結束。
如以上說明，若依據本變形例，則系統控制部14係若訂購商品不是指定醫藥品時，則以結帳狀態已經被更新成處理完成為條件，將寄送狀態更新成等待寄送。又，系統控制部14係若訂購商品是指定醫藥品時，則以結帳狀態已經被更新成處理完成且確認狀態已經被更新成確認完成為條件，將寄送狀態更新成等待寄送。因此，可防止店舖錯誤寄送商品。
〔2.第2實施形態〕
接著說明第2實施形態。於第1實施形態中，是將有關於接單、使用者狀態之提示、留意資訊之輸入、各種狀態之提示等的使用者介面，由電子商店街伺服器1對店舖做提供(例如：接單一覽網頁、接單管理網頁、訊息管理網頁、訊息輸入網頁等)。於第2實施形態中則是，可每一店舖設計獨特的使用者介面。為此，從電子商店街伺服器1對店舖之系統會提供API(Application Programming Interface)。除了以下所說明的點以外，第2實施形態基本上是和第1實施形態相同。
〔2-1.資訊處理系統之構成及機能概要〕
接著，關於本實施形態中所述之資訊處理系統S2之構成及機能概要，使用圖22來說明。圖22係本實施形態所述之資訊處理系統S2的概要構成之一例的圖示。於圖22中，關於和圖1相同之要素，係標示相同的符號。
如圖22所示，資訊處理系統S2係含有：電子商店街伺服器1、複數店舖系統4、複數購入者終端3所構成。然後，電子商店街伺服器1與各店舖系統4及各購入者終端3，係透過網路NW而可彼此收送資料。
本實施形態中的電子商店街伺服器1，係隨應於利用到API的來自店舖系統4之要求，將確認狀態輸出至店舖系統4，以使其可判定販售成立所需之處理是否可 行。
店舖系統4，係為由店舖所架設的系統。店舖系統4係含有例如：店舖伺服器5和1台以上之店舖終端6所構成。店舖伺服器5與店舖終端6係透過例如LAN(Local Area Network)等之網路而可彼此通訊。店舖伺服器5，係利用API等而與電子商店街伺服器1進行通訊。又，店舖伺服器5，係對店舖終端6提供各種使用者介面。所被提供的使用者介面，係可為例如網頁空間之介面，也可為其他介面。甚至店舖伺服器5，係還進行針對訂購商品的寄送狀態之控制。於本實施形態中，電子商店街伺服器1與店舖伺服器5之組合，係為本發明中的資訊系統之一例。店舖伺服器5，係被店舖之從業員等所操作的終端裝置。藉由店舖終端6存取店舖伺服器5，從業員係進行商品之訂購內容之確認、使用者狀態資訊之瀏覽、留意資訊之輸入等。
電子商店街伺服器1與購入者終端3之間之通訊的相關處理，及與店舖系統4之通訊所伴隨的電子商店街伺服器1內部之處理，係和第1實施形態相同，因此省略這些的詳細說明。
此外，究竟是要利用店舖獨特之使用者介面，或是利用從電子商店街伺服器1所提供的使用者介面，係可讓每一店舖做選擇。關於利用從電子商店街伺服器1所提供之使用者介面的店舖，係不需要店舖伺服器5。此時，電子商店街伺服器1與店舖終端6係亦可直接 通訊，電子商店街伺服器1的處理係和第1實施形態相同。
〔2-2.店舖伺服器之構成〕
接著，針對店舖伺服器5之構成，使用圖23來說明。圖23(a)係本實施形態所述之店舖伺服器5之概要構成之一例的區塊圖。如圖23(a)所示，店舖伺服器5係具備有：通訊部51、記憶部52、輸出入介面53、系統控制部54。然後，系統控制部54與輸出入介面53，係透過系統匯流排55而連接。
通訊部51，係連接至網路NW，控制著與電子商店街伺服器1或店舖終端6等的通訊狀態。記憶部52係由例如硬碟機等所構成。記憶部52中係記憶有：店舖所販售之商品的相關資訊、接單的相關資訊等。又，在記憶部52中係記憶有作業系統、WWW(World Wide Web)伺服器程式、DBMS(Database Management System)、接單管理程式等各種程式。接單管理程式，係用來執行關於電子商店街之接單的各種處理所需的程式。此外，各種程式例如可從其他伺服器裝置等透過網路NW而取得，也可記錄在光碟等之記錄媒體中然後透過驅動機裝置而被讀取。又，接單管理程式等係亦可為程式產品。輸出入介面53，係在通訊部51及記憶部52與系統控制部54之間，進行介面處理。系統控制部54係由CPU54a、ROM54b、RAM54c等所構成。
〔2-3.系統控制部之機能概要〕
接著，使用圖23(b)，說明系統控制部54的機能概要。圖2(b)係本實施形態所述之宿泊設施預約伺服器1的系統控制部54的機能區塊之一例的圖示。系統控制部54，係藉由CPU54a讀出接單管理程式等之程式並執行，而如圖23(b)所示，成為伺服器通訊部541、使用者介面部542、狀態判定部543等而發揮機能。伺服器通訊部541，係利用API而向電子商店街伺服器1發送要求，或將從電子商店街伺服器1所發送過來的資訊予以接收。使用者介面部542，係對店舖終端6提供使用者介面，控制伺服器通訊部541與店舖終端6之間的資訊交換。狀態判定部543，係根據商品區分、結帳狀態及確認狀態，判定是否可更新寄送狀態。
〔2-4.資訊處理系統之動作〕 〔2-4-1.系統全體之動作〕
接著，針對資訊處理系統S2之全體的動作，使用圖24及圖25來說明。圖24係本實施形態所述之資訊處理系統S2的留意資訊之提供的相關處理之一例的程序圖。將含有來自購入者之關於指定醫藥品之訂購內容的訂購資訊登錄至訂購DB12e的訂購內容受理部142，係如圖24所示般地發送訂購內容受理通知郵件(步驟S111)。接收到訂購內容受理通知郵件的店舖伺服器5之伺服器通訊部 541，係將例如該電子郵件中所含的受理日期時間、訂購號碼、訂購內容等，建立關連而記憶在記憶部52中。又，伺服器通訊部541，係執行相應於該電子郵件中所含的結帳方法的處理。例如，若結帳方法是信用卡結帳時，則伺服器通訊部541係將結帳授權要求，發送至電子商店街伺服器1(步驟S112)。電子商店街伺服器1的狀態控制部144係執行授權處理，在取得了表示支付已被授權的處理結果時，才將結帳狀態更新成處理完成(步驟S113)。此外，若結帳方法不是信用卡結帳，則店舖伺服器5係基於例如店舖之從業員所做的店舖終端6之操作，將結帳狀態更新要求，發送至電子商店街伺服器1。如此一來，狀態控制部144係將結帳狀態更新成處理完成。一旦授權處理完成，則電子商店街伺服器1的系統控制部14係將現在之結帳狀態，發送至店舖伺服器5(步驟S114)。店舖伺服器5的狀態判定部543，係將接收到的結帳狀態與訂購資訊建立關連，記憶在記憶部52中。
接下來，伺服器通訊部541係將使用者狀態資訊之要求，發送至電子商店街伺服器1(步驟S115)。該要求係含有訂購號碼。電子商店街伺服器1的系統控制部14，係將所接收到的要求中所含的訂購號碼所對應之使用者狀態資訊，從訂購DB12e加以取得，將使用者狀態資訊發送至店舖伺服器5(步驟S116)。此外，若訂購內容受理通知郵件是含有使用者狀態資訊時，就不需要步驟S115及S116。店舖伺服器5的使用者介面部542，係將 所接收到的使用者狀態資訊發送至店舖終端6(步驟S117)，令店舖終端6顯示使用者狀態資訊。從業員係隨應於使用者狀態資訊而輸入留意資訊(步驟S118)。如此一來，店舖終端6係將留意資訊當作店舖訊息而發送至店舖伺服器5(步驟S119)，伺服器通訊部541係將店舖訊息發送至電子商店街伺服器1(步驟S120)。電子商店街伺服器1的訊息處理部143，係將所接收到的店舖訊息登錄至訊息DB12f，同時，向購入者發送店舖訊息登錄通知郵件(步驟S121)。
圖25係本實施形態所述之資訊處理系統S2的確認狀態及寄送狀態之更新的相關處理之一例的程序圖。購入者終端3中所被顯示的訊息確認網頁中一旦購入者輸入購入者訊息，則如圖25所示，購入者終端3係將購入者訊息發送至電子商店街伺服器1(步驟S131)。電子商店街伺服器1的狀態控制部144，係若購入者訊息中所含的所有勾選盒顯示文字都表示已勾選時，則將確認狀態更新成確認完成(步驟S132)。接下來，訊息處理部143，係向店舖發送購入者訊息登錄通知郵件(步驟S133)。接收到購入者訊息登錄通知郵件的店舖伺服器5的訊息判定部543，係將購入者訊息及確認狀態之要求，發送至電子商店街伺服器1(步驟S134)。該要求係含有接單號碼。電子商店街伺服器1的系統控制部14，係將要求中所含的接單號碼所對應之購入者訊息，從訊息DB12f加以取得，並且，將接單號碼所對應之確認狀態，從訂購DB12e加以 取得。然後，系統控制部14係將購入者訊息及確認狀態，發送至店舖伺服器5(步驟S135)。店舖伺服器5的狀態判定部543，係一旦判定結帳狀態為處理完成且確認狀態為確認完成(步驟S136)，則將寄送狀態更新要求，發送至電子商店街伺服器1(步驟S137)。該要求係含有訂購號碼。電子商店街伺服器1的狀態控制部144，係將要求中所含的訂購號碼所對應之訂購資訊，從訂購DB12e加以特定，將訂購資訊中所含的寄送狀態更新成等待寄送(步驟S138)。
此外，若店舖伺服器5從電子商店街伺服器1所接收到的確認狀態是確認未完成時，則店舖伺服器5係將購入者訊息發送至店舖終端6，令從業員輸入針對購入者訊息的店舖訊息。然後，店舖伺服器5，係將已被輸入之購入者訊息，發送至電子商店街伺服器1。
在圖24及圖25之例中，先進行購入費用之支付所需之處理，其後才進行留意資訊之提供和確認。然而，亦可先進行留意資訊之提供和確認，其後才進行購入費用之支付所需之處理。又，這些處理亦可平行而進行之。
〔2-4-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖26來說明。圖26係本實施形態所述之店舖伺服器5之系統控制部54的寄送狀態更新判定處理 之一例的流程圖。例如，亦可在藉由信用卡所致之結帳的授權處理之結果被從電子商店街伺服器1發送至店舖伺服器5時(圖24步驟S114)，店舖伺服器5向電子商店街伺服器1發送結帳狀態更新要求時，及店舖伺服器5接收到購入者訊息登錄通知郵件時(圖26步驟S133)，系統控制部54係執行寄送狀態控制處理。
如圖26所示，狀態判定部543係將對象之訂購所對應之結帳狀態或確認狀態、或其雙方，因應需要而從電子商店街伺服器1加以取得(步驟S141)。例如，狀態判定部543係將含有訂購號碼的要求，發送至電子商店街伺服器1，電子商店街伺服器1係將訂購號碼所對應之結帳狀態及確認狀態，發送至店舖伺服器5。接下來，狀態判定部543係判定結帳狀態是否為處理完成(步驟S142)。此時，狀態判定部543係在判定結帳狀態並非處理完成時(步驟S142：NO)，則令狀態判定處理結束。另一方面，狀態判定部543，係在判定結帳狀態是處理完成時(步驟S142：YES)，則前進至步驟S143。於步驟S143中，狀態判定部543係判定，對象之訂購的訂購號碼所對應之商品區分是否為指定醫藥品。狀態判定部543，係例如可根據訂購商品之類型ID來判定商品區分是否為指定醫藥品，也可從電子商店街伺服器1取得商品區分。此時，狀態判定部543係在判定商品區分不是指定醫藥品時(步驟S143：NO)，則前進至步驟S145。另一方面，狀態判定部543係在判定商品區分是指定醫藥品時(步驟S143： YES)，則前進至步驟S144。於步驟S144中，狀態判定部543係判定，對象之訂購所對應之確認狀態是否為確認完成。此時，狀態判定部543係在判定確認狀態並非確認完成時(步驟S144：NO)，則令狀態判定處理結束。另一方面，狀態判定部543，係在判定確認狀態為確認完成時(步驟S144：YES)，則前進至步驟S145。於步驟S145中，狀態判定部543係將含有對象訂購之訂購號碼的寄送狀態更新要求，發送至電子商店街伺服器1，令狀態控制處理結束。
如以上說明，若依據本實施形態，則店舖伺服器5係若訂購商品不是指定醫藥品時，則以結帳狀態已經被更新成處理完成為條件而發送寄送狀態更新要求，電子商店街伺服器1係將寄送狀態更新成等待寄送。又，店舖伺服器5係若訂購商品是指定醫藥品時，則以結帳狀態已經被更新成處理完成且確認狀態已經被更新成確認完成為條件，發送寄送狀態更新要求，電子商店街伺服器1係將寄送狀態更新成等待寄送。因此，可防止店舖錯誤寄送商品。
〔3.第3實施形態〕 〔3-1.系統控制部之機能概要〕
接著，關於第3實施形態中的系統控制部14之機能，使用圖27來說明。除了以下所說明的點以外，第3實施形態基本上是和第1實施形態相同。在本實施形態 中，接單資訊提供部145，係針對指定醫藥品之訂購，隨著確認狀態而控制訂購商品之寄送目標地址之提供。在本實施形態中，接單資訊提供部145，係為本發明中的訂購內容提示控制手段之一例。圖27(a)係確認狀態為確認完成時的接單管理網頁之顯示例的圖示，圖27(b)係確認狀態為確認未完成時的接單管理網頁之顯示例的圖示。如圖27(a)所示，若確認狀態是確認完成，則接單資訊提供部145係令寄送目標地址被顯示。另一方面，如圖27(b)所示，若確認狀態是確認未完成，則接單資訊提供部145係不令寄送目標地址被顯示。藉此，就算購入者沒有確認留意資訊，仍可防止店舖誤將訂購商品予以寄送。又，訊息處理部143，係不使訂購內容受理通知郵件中含有寄送目標地址。
〔3-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖28來說明。圖28係本實施形態所述之電子商店街伺服器1的系統控制部14的接單管理網頁送訊處理之一例的流程圖。從店舖終端2接收到接單管理網頁之要求時，系統控制部14係執行接單管理網頁送訊處理。該要求係含有訂購號碼。如圖28所示，接單資訊提供部145，係將要求中所含之訂購號碼所對應之訂購資訊，從訂購DB12e加以取得(步驟S151)。又，接單資訊提供部145，係從記憶部12取得要作為樣版的接單管理 網頁之HTML文件。接下來，接單資訊提供部145係判定，訂購資訊中所含的商品區分是否為指定醫藥品(步驟S152)。此時，接單資訊提供部145係在判定商品區分不是指定醫藥品時(步驟S152：NO)，則前進至步驟S154。另一方面，接單資訊提供部145係在判定商品區分是指定醫藥品時(步驟S152：YES)，則前進至步驟S153。
於步驟S153中，接單資訊提供部145係判定，訂購資訊中所含之確認狀態是否為確認完成。此時，接單資訊提供部145係在判定確認狀態是確認完成時(步驟S153：YES)，則前進至步驟S154。步驟S154中，接單資訊提供部145係將訂購資訊之內容，追加至接單管理網頁的HTML文件。此時，接單資訊提供部145係也追加寄送目的地資訊。接下來，接單資訊提供部145係前進至步驟S156。另一方面，接單資訊提供部145係在判定確認狀態不是確認完成時(步驟S153：NO)，則前進至步驟S155。步驟S155中，接單資訊提供部145係把寄送目的地資訊除外，將訂購資訊之內容，追加至接單管理網頁的HTML文件。接下來，接單資訊提供部145係前進至步驟S156。於步驟S165中，接單資訊提供部145係將接單管理網頁的HTML文件，發送至店舖終端2，結束接單管理網頁送訊處理。
如以上說明，若依據本實施形態，則系統控制部14係在訂購商品是指定醫藥品，且訂購內容所被建立關連對應到的確認狀態是確認未完成時，則在訂購內容 之中，不將商品的寄送目標地址予以輸出。因此，就算購入者沒有確認留意資訊，仍可防止店舖寄送商品。
〔4.第4實施形態〕 〔4-1.資訊處理系統之構成及機能概要〕
接著說明第4實施形態。除了以下所說明的點以外，第4實施形態基本上是和第1實施形態相同。首先，關於第4實施形態所述之資訊處理系統S3之構成及機能概要，使用圖29來說明。圖29係本實施形態所述之資訊處理系統S3的概要構成之一例的圖示。於圖29中，關於和圖1相同之要素，係標示相同的符號。
如圖29所示，資訊處理系統S3係含有：電子商店街伺服器1、複數店舖終端2、複數購入者終端3、配送管理伺服器7所構成。然後，電子商店街伺服器1與各店舖終端2及各購入者終端3及配送管理伺服器7，係透過網路NW而可彼此收送資料。
配送管理伺服器7，係在宅配等之配送服務中，管理品物之配送狀況的伺服器裝置。配送管理伺服器7，係亦可被例如所定之配送業者所設置。在本實施形態中，電子商店街伺服器1，係與配送管理伺服器7合作，提供電子商店街中所被購入之商品的配送狀態。
例如，店舖係在配送訂購商品前，將配送傳票資訊輸入至店舖終端2。配送傳票資訊，係為配送傳票中所被顯示的資訊。配送傳票資訊，係至少含有配送傳票 號碼。配送傳票號碼，係為配送傳票之識別號碼。配送傳票資訊係亦可還含有配送目標之地址、姓名、電話號碼、配送日期時間等。店舖終端2，係將已被輸入之配送傳票資訊，連同訂購號碼一併發送至電子商店街伺服器1。電子商店街伺服器1，係將配送傳票資訊與訂購號碼建立關連而記憶在記憶部12中。例如，電子商店街伺服器1，係將配送傳票資訊，登錄在訂購DB12e中。
店舖係向訂購商品附上配送傳票然後交給配送業者。配送業者，係將配送傳票上所顯示的資訊，登錄至配送管理伺服器7。其後，例如於購入者終端3上顯示訂購履歷網頁時，購入者係選擇任一訂購商品之配送狀況之顯示。如此一來，購入者終端3係發送訂購號碼，電子商店街伺服器1係取得訂購號碼所對應之配送傳票號碼，將配送傳票號碼所對應之配送狀況，從配送管理伺服器7加以取得。然後，電子商店街伺服器1，係令購入者終端3顯示出配送狀況。又，例如，亦可於店舖終端2之接單管理網頁等中，也顯示出配送狀況。
〔4-2.系統控制部之機能概要〕
接著，針對系統控制部14的機能，使用圖30來說明。在本實施形態中，接單資訊提供部145，係從店舖受理配送傳票資訊之輸入。此時，接單資訊提供部145，係針對指定醫藥品之訂購，隨應於確認狀態而控制配送傳票資訊之輸入之受理。接單資訊提供部145，係為本發明中 的訂購內容提示控制手段之一例。圖30(a)係確認狀態為確認完成時的接單管理網頁之顯示例的圖示，圖30(b)係確認狀態為確認未完成時的接單管理網頁之顯示例的圖示。如圖30(a)所示，若確認狀態是確認完成，則接單資訊提供部145係令接單管理網頁中顯示配送傳票輸入鈕223。配送傳票輸入鈕223，係用來顯示配送傳票輸入網頁所需之按鈕。配送傳票輸入網頁，係用來輸入配送傳票資訊所需之網頁。於配送傳票輸入網頁中，一旦從業員輸入配送傳票資訊，則店舖終端2係將資訊當作配送傳票資訊而發送至電子商店街伺服器1。然後，電子商店街伺服器1，係將配送傳票資訊，登錄在訂購DB12e中。另一方面，如圖30(b)所示，若確認狀態是確認未完成，則接單資訊提供部145係不令配送傳票輸入鈕223被顯示。藉此，就算購入者沒有確認留意資訊，仍可防止店舖誤將訂購商品予以寄送。
此外，接單資訊提供部145，係亦可控制配送傳票輸入鈕223之顯示，同時，和第3實施形態同樣地控制寄送目標地址之顯示。又，亦可不是控制配送傳票輸入鈕223之顯示，而是例如接單資訊提供部145，在確認狀態是確認未完成時，則在配送傳票輸入網頁中，顯示出表示不可寄送之警告訊息等。
〔4-3.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的 具體動作，使用圖31來說明。圖31係本實施形態所述之電子商店街伺服器1的系統控制部14的接單管理網頁送訊處理之一例的流程圖。從店舖終端2接收到接單管理網頁之要求時，系統控制部14係執行接單管理網頁送訊處理。該要求係含有訂購號碼。如圖31所示，接單資訊提供部145，係將要求中所含之訂購號碼所對應之訂購資訊，從訂購DB12e加以取得(步驟S161)。又，接單資訊提供部145，係從記憶部12取得要作為樣版的接單管理網頁之HTML文件。該HTML文件，係含有用來顯示配送傳票輸入鈕223所需之資料。接著，接單資訊提供部145係將訂購資訊之內容，追加至接單管理網頁的HTML文件(步驟S162)。接下來，接單資訊提供部145係判定，訂購資訊中所含的商品區分是否為指定醫藥品(步驟S163)。此時，接單資訊提供部145係在判定商品區分不是指定醫藥品時(步驟S163：NO)，則前進至步驟S166。另一方面，接單資訊提供部145係在判定商品區分是指定醫藥品時(步驟S163：YES)，則前進至步驟S164。
於步驟S164中，接單資訊提供部145係判定，訂購資訊中所含之確認狀態是否為確認完成。此時，接單資訊提供部145係在判定確認狀態是確認完成時(步驟S164：YES)，則前進至步驟S166。另一方面，接單資訊提供部145係在判定確認狀態不是確認完成時(步驟S164：NO)，則前進至步驟S165。於步驟S165中，接單資訊提供部145係從接單管理網頁的HTML文件，刪除用 來表示配送傳票輸入鈕223所需之資料。接下來，接單資訊提供部145係前進至步驟S166。於步驟S166中，接單資訊提供部145係將接單管理網頁的HTML文件，發送至店舖終端2，結束接單管理網頁送訊處理。
此外，亦可不是控制配送傳票輸入鈕223之顯示，而是系統控制部14係控制例如配送傳票資訊之登錄。例如，系統控制部14，係亦可在從店舖終端2接收已被輸入之配送傳票資訊時，根據所對應的訂購資訊之商品區分及確認狀態，判定是否將配送傳票資訊登錄至訂購DB12e。判定方法係和圖31相同。
如以上說明，若依據本實施形態，則系統控制部14係在商品是指定醫藥品，且訂購內容所被建立關連對應到的確認狀態是確認未完成時，不受理配送傳票資訊。因此，就算購入者沒有確認留意資訊，仍可防止店舖使用配送傳票來寄送商品。
〔5.第5實施形態〕 〔5-1.系統控制部之機能概要〕
接著，關於第5實施形態中的系統控制部14之機能，使用圖32來說明。除了以下所說明的點以外，第5實施形態基本上是和第1實施形態~第4實施形態相同。圖32係本實施形態所述之宿泊設施預約伺服器1的系統控制部14的機能區塊之一例的圖示。於圖32中，關於和圖3(b)相同之要素，係標示相同的符號。如圖32所示， 系統控制部14係成為使用者狀態資訊受理部141、訂購內容受理部142、訊息處理部143、狀態控制部144、接單資訊提供部145、訂購履歷提供部146、取消處理部147等而發揮機能。取消處理部147，係為本發明中的取消手段之一例。
取消處理部147，係關於指定醫藥品之訂購而通知留意資訊已被登錄的店舖訊息登錄通知郵件被發送起，即使經過了預先設定的確認期間，確認狀態仍是確認未完成的情況下，則自動取消該指定醫藥品的訂購。訂購商品是指定醫藥品時，在確認購入者已經理解留意資訊以前，店舖係無法寄送訂購商品。店舖係在寄送訂購商品為止，必須要將訂購商品當作庫存而確保。即使經過一定期間仍無法獲得來自購入者之確認的情況下，藉由自動取消訂購，店舖就可釋放庫存。確認期間之日數，係亦可由例如電子商店街伺服器1的管理者預先設定。所被設定的確認期間之日數，係被記憶在記憶部12中。
〔5-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖33來說明。圖33係本實施形態所述之電子商店街伺服器1的系統控制部14的自動取消處理之一例的流程圖。例如，系統控制部14係定期地執行自動取消處理。例如，系統控制部14係亦可每隔所定時間，或每隔所定日數，就執行自動取消處理。
如圖33所示，取消處理部147，係從訂購DB12e，檢索出商品區分是指定醫藥品、確認狀態為確認未完成、且取消旗標為FALSE的訂購資訊(步驟S171)。接下來，取消處理部147係將號碼i設定成1(步驟S172)。接下來，取消處理部147係判定，所被檢索到的訂購資訊之中第i個訂購資訊所對應之留意資訊是否為已被登錄(步驟S173)。具體而言，取消處理部147，係將第i個訂購資訊中所含的訂購號碼所對應之店舖訊息，從訊息DB12f中檢索出來。取消處理部147，係若找不到店舖訊息，則判定留意資訊為未被登錄(步驟S173：NO)。此時，取消處理部147係前進至步驟S179。另一方面，取消處理部147，係若有找到店舖訊息，則判定留意資訊為有被登錄(步驟S173：YES)。此時，取消處理部147係前進至步驟S174。
於步驟S174中，取消處理部147係取得留意資訊的送訊日期時間。具體而言，取消處理部147，係在第i個訂購資訊中所含的訂購號碼所對應之店舖送訊日期時間之中，將訊息號碼為1的店舖送訊日期時間，從訊息DB12f加以取得。店舖送訊日期時間，係被視為店舖訊息登錄通知郵件的送訊日期時間。接下來，取消處理部147，係藉由從現在日期時間，減去所取得的送訊日期時間，以計算經過日數(步驟S175)。接下來，取消處理部147係判定，經過日數是否為記憶部12中所記憶之確認期間日數以上(步驟S176)。此時，取消處理部147係在判 定經過日數並非確認期間日數以上時(步驟S176：NO)，則前進至步驟S179。另一方面，取消處理部147係在判定經過日數是確認期間日數以上時(步驟S176：YES)，則前進至步驟S177。
於步驟S177中，取消處理部147係將第i個訂購資訊中所含之取消旗標，設定成TRUE。接下來，取消處理部147，係將自動取消通知郵件，分別發送給購入者及店舖(步驟S178)。自動取消通知郵件，係用來通知訂購被自動取消的電子郵件。取消處理部147，係根據第i個訂購資訊中所含的使用者ID及店舖ID而取得購入者及店舖之各自的電子郵件位址，根據這些電子郵件位址而發送自動取消通知郵件。接下來，取消處理部147係前進至步驟S179。
於步驟S179中，取消處理部147係判定，號碼i是否和檢索到的訂購資訊之數目一致。此時，取消處理部147係在判定號碼i是和訂購資訊之數目不一致時(步驟S179：NO)，則前進至步驟S180。於步驟S180中，取消處理部147係對號碼i加算1，前進至步驟S173。另一方面，取消處理部147係在判定號碼i是和訂購資訊之數目一致時(步驟S179：YES)，則結束自動取消處理。
如以上說明，若依據本實施形態，則系統控制部14係在留意資訊被生成時，將用來通知必須確認該留意資訊的店舖訊息登錄通知郵件，予以輸出。又，系統 控制部14係在從店舖訊息登錄通知郵件被輸出起的所定時間內都沒有受理到購入者訊息時，則取消訂購內容之受理。因此，由於留意資訊未被確認因此也無法寄送，可減少也無法販售給其他購入者的商品之數量。
〔6.第6實施形態〕 〔6-1.系統控制部之機能概要〕
接著，關於第6實施形態中的系統控制部14之機能，使用圖34及圖35來說明。除了以下所說明的點以外，第6實施形態基本上是和第5實施形態相同。如第5實施形態所說明，在訂購內容被自動取消後，訂購內容受理部142係讓購入者可以進行訂購內容已被取消之商品的重新訂購。此時，訂購內容受理部142係使得已被取消之訂購內容可當成重新訂購時的訂購內容而加以受理，並且，使得已被取消之訂購內容所被建立關連對應到的使用者狀態資訊，可當成重新訂購時的使用者狀態資訊而加以受理。藉此，在重新訂購之際，可省去訂購內容之重新輸入的麻煩，同時可省去使用者狀態資訊之重新輸入的麻煩。
圖34係訂購履歷網頁之顯示例的圖示。於圖34中，關於和圖11相同之要素，係標示相同的符號。如圖34所示，於訂購履歷網頁中，已被自動取消的訂購內容所對應之訂購內容顯示領域251中，係顯示有表示已被取消之事實的訊息253、和重新訂購鈕254。重新訂購鈕 254，係用來重新訂購已被取消之訂購內容所示之商品所需之按鈕。重新訂購鈕254，係為本發明中的重新訂購要素之一例。一旦購入者選擇重新訂購鈕254，則訂購內容受理部142係將重新訂購內容確認網頁，發送至購入者終端3。重新訂購內容確認網頁，係用來確認重新訂購時的訂購內容及使用者狀態資訊所需之網頁。
圖35係重新訂購內容確認網頁之顯示例的圖示。如圖35所示，重新訂購內容確認網頁中係顯示有：訂購內容顯示領域271、使用者狀態資訊顯示領域272、訂購內容編輯鈕273、使用者狀態資訊編輯鈕274、及確定鈕275。訂購內容顯示領域271中係顯示訂購內容。使用者狀態資訊顯示領域272中係顯示使用者狀態資訊。重新訂購內容確認網頁中所被顯示的訂購內容及使用者狀態資訊，係為已被取消之訂購內容及與該訂購內容建立關連的使用者狀態資訊。一旦購入者選擇訂購內容編輯鈕273，則訂購內容受理部142係將訂購內容編輯網頁，發送至購入者終端3。於該訂購內容編輯網頁中，購入者係可編輯重新訂購內容確認網頁中所被顯示的訂購內容。一旦編輯結束，則訂購內容受理部142係將重新訂購內容確認網頁，發送至購入者終端3。一旦購入者選擇使用者狀態資訊編輯鈕274，則使用者狀態資訊受理部141係將使用者狀態資訊編輯網頁，發送至購入者終端3。於該使用者狀態資訊編輯網頁中，購入者係可編輯重新訂購內容確認網頁中所被顯示的使用者狀態資訊。一旦編輯結束，則 訂購內容受理部142係將重新訂購內容確認網頁，發送至購入者終端3。確定鈕275，係用來確定訂購內容及使用者狀態資訊所需之按鈕。若購入者沒有編輯訂購內容及使用者狀態資訊就選擇確定鈕275，則訂購內容受理部142係將已被取消之訂購內容級該訂購內容所被建立關連對應到的使用者狀態資訊，從訂購DB12e加以取得。然後，訂購內容受理部142，係將含有已取得之訂購內容及使用者狀態資訊的新的訂購資訊，登錄至訂購DB12e。若訂購內容有被編輯，則訂購內容受理部142係將含有已被編輯之訂購內容、和已被取消之訂購內容所被建立關連對應到之使用者狀態資訊的訂購資訊，予以登錄。若使用者狀態資訊有被編輯，則訂購內容受理部142係將含有已被編輯之使用者狀態資訊、和已被取消之訂購內容的訂購資訊，予以登錄。若訂購內容及使用者狀態資訊之雙方都有被編輯，則訂購內容受理部142係將含有已被編輯之資訊的訂購資訊，予以登錄。
此外，若店舖的從業員對重新訂購時的使用者狀態資訊輸入了留意資訊時，則訊息處理部143係亦可令已被取消之訂購內容所被建立關連對應到的留意資訊，被店舖終端2所顯示。藉此，從業員係可一面參照之前的留意資訊一面輸入重新訂購時的留意資訊。例如，訊息處理部143，係亦可在訊息輸入網頁之訊息輸入欄243中，將已被取消之訂購內容所被建立關連對應到的留意資訊，以預先輸入之狀態而加以顯示。
〔6-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖36乃至圖38來說明。圖36係本實施形態所述之電子商店街伺服器1的系統控制部14的訂購履歷送訊處理之一例的流程圖。於圖36中，關於和圖19相同之處理，係標示相同的符號。如圖36所示，訂購內容受理部142係執行步驟S81~S84。於步驟S84中，訂購內容受理部142係在判定商品區分並非指定醫藥品時(步驟S84：NO)，則前進至步驟S87。另一方面，訂購內容受理部142係在判定商品區分是指定醫藥品時(步驟S84：NO)，則前進至步驟S191。於步驟S191中，訂購內容受理部142係判定，第i個訂購資訊中所含之取消旗標是否為TRUE。此時，訂購內容受理部142係在判定取消旗標不是TRUE時(步驟S191：NO)，則前進至步驟S85。另一方面，訂購內容受理部142係在判定取消旗標是TRUE時(步驟S191：YES)，則前進至步驟S192。於步驟S192中，訂購內容受理部142係針對第i個訂購資訊而將用來顯示重新訂購鈕254所需之資料，追加至訂購履歷網頁的HTML文件。接下來，訂購內容受理部142係前進至步驟S87。關於步驟S85~S89之處理，係和第1實施形態相同。
圖37係本實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購確認網頁送訊處理之一例 的流程圖。在購入者終端3中顯示有訂購履歷網頁時，一旦購入者選擇了重新訂購鈕254，則購入者終端3係將重新訂購確認要求，發送至電子商店街伺服器1。重新訂購確認要求，係含有已被選擇之重新訂購鈕254所對應之訂購號碼。從購入者終端3接收到重新訂購確認要求時，系統控制部14係執行重新訂購確認網頁送訊處理。如圖37所示，訂購內容受理部142係將重新訂購確認要求中所含之訂購號碼所對應的訂購內容及使用者狀態資訊，從訂購DB12e加以取得(步驟S201)。又，訂購內容受理部142，係從記憶部12取得要作為樣版的訂購履歷網頁之HTML文件。接著，訂購內容受理部142係將所取得的訂購內容及使用者狀態資訊，追加至重新訂購確認網頁的HTML文件(步驟S202)。接下來，訂購內容受理部142，係將訂購履歷網頁之HTML文件，發送至購入者終端3(步驟S203)，結束重新訂購確認網頁送訊處理。
圖38係本實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購內容登錄處理之一例的流程圖。在購入者終端3中顯示有重新訂購內容確認網頁時，一旦購入者選擇了確定鈕275，則購入者終端3係將重新訂購內容確定要求，發送至電子商店街伺服器1。重新訂購內容確定要求係含有，從訂購履歷網頁被購入者所選擇之重新訂購鈕254所對應之訂購號碼。訂購內容有被編輯時，重新訂購內容確定要求係含有編輯後之訂購內容，訂購內容未被編輯時，重新訂購內容確定要求係不含 訂購內容。使用者狀態資訊有被編輯時，重新訂購內容確定要求係含有編輯後之使用者狀態資訊，使用者狀態資訊未被編輯時，重新訂購內容確定要求係不含使用者狀態資訊。從購入者終端3接收到重新訂購內容確定要求時，系統控制部14係執行重新訂購內容登錄處理。
如圖38所示，訂購內容受理部142係判定重新訂購內容確定要求是否含有訂購內容(步驟S211)。此時，訂購內容受理部142係在判定重新訂購內容確定要求是含有訂購內容時(步驟S211：YES)，則前進至步驟S213。另一方面，訂購內容受理部142係在判定重新訂購內容確定要求是不含訂購內容時(步驟S211：NO)，則前進至步驟S212。於步驟S212中，訂購內容受理部142係將重新訂購內容確定要求中所含之訂購號碼所對應之訂購內容，從訂購DB12e加以取得。接下來，訂購內容受理部142係前進至步驟S213。於步驟S213中，訂購內容受理部142係生成，含有重新訂購內容確定要求中所含之訂購內容或步驟S212中所取得之訂購內容的訂購資訊。此時，訂購內容受理部142，係生成新的訂購號碼，同時，取得現在日期時間來作為受理日期時間。
接下來，訂購內容受理部142係判定重新訂購內容確定要求是否含有使用者狀態資訊(步驟S214)。此時，使用者狀態資訊受理部141係在判定重新訂購內容確定要求是含有使用者狀態資訊時(步驟S214：YES)，則前進至步驟S216。另一方面，使用者狀態資訊受理部141 係在判定重新訂購內容確定要求是不含使用者狀態資訊時(步驟S214：NO)，則前進至步驟S215。於步驟S215中，使用者狀態資訊受理部141係將重新訂購內容確定要求中所含之訂購號碼所對應之使用者狀態資訊，從訂購DB12e加以取得。接下來，使用者狀態資訊受理部141係前進至步驟S216。於步驟S216中，使用者狀態資訊受理部141，係將重新訂購內容確定要求中所含的使用者狀態資訊或步驟S215中所取得之使用者狀態資訊，追加至訂購資訊。
接下來，訂購內容受理部142係設定訂購資訊中所含的資訊(步驟S217)。具體而言，訂購內容受理部142，係將商品區分設定成指定醫藥品。又，訂購內容受理部142，係將寄送狀態設定成不可寄送，將結帳狀態設定成處理未完成。又，訂購內容受理部142係將確認狀態設定成店舖送訊前。接下來，訂購內容受理部142係將已生成之訂購資訊登錄至訂購DB12e(步驟S218)，接下來，訂購內容受理部142係將訂購內容受理通知郵件予以發送(步驟S219)，結束重新訂購內容登錄處理。
如以上說明，若依據本實施形態，則系統控制部14係將含有已經被取消受理的訂購內容之至少一部分的訂購內容顯示領域251和重新訂購鈕254，予以提示。又，系統控制部14係在基於重新訂購鈕254已被操作之事實而受理重新訂購所需之訂購內容時，將已經被取消受理的訂購內容所被建立關連對應到的使用者狀態資 訊，當作與重新訂購所需之訂購內容建立關連對應的使用者狀態資訊而加以取得。因此，在重新訂購之際，購入者係可省去重新輸入使用者狀態資訊的麻煩。
〔7.第7實施形態〕 〔7-1.系統控制部之機能概要〕
接著，關於第7實施形態中的系統控制部14之機能，使用圖39來說明。除了以下所說明的點以外，第7實施形態基本上是和第6實施形態相同。在本實施形態中，訂購內容受理部142，係於重新訂購中，受理已被取消之訂購內容所被建立關連對應到的使用者狀態資訊時，針對使用者狀態資訊之各項目，判定使用者之狀態是否為有可能變化的狀態。訂購內容受理部142，係為本發明中的有效日數取得手段、要求資訊提示控制手段之一例。若使用者之狀態是有可能變化的項目，則訂購內容受理部142，係基於從已被取消之訂購內容之受理日期時間起算之經過日數，針對符合的項目，令購入者終端3提示要求重新輸入使用者之狀態的資訊。具體而言，訂購內容受理部142，係若經過日數是沒有超過使用者狀態資訊之有效期間日數，則不提示要求重新輸入的資訊，若經過日數是超過了有效期間日數，則提示要求重新輸入的資訊。例如，可隨項目之區分或每一種類而設定有效期間日數。或者，亦可每一項目地設定有效期間日數。又，有效期間日數，係例如於資訊處理系統中預先指定，也可依每一指定 醫藥品或每一店舖而個別設定。有效期間日數，係亦可隨著已被取消之訂購內容被受理時的使用者之狀態是持續到現在為止的可能性，而被設定。例如，狀態持續的期間一般較長的項目，則有效期間日數就亦可越長。藉由目前為止所說明的處理，可減少重新訂購時的使用者狀態資訊之重新輸入的麻煩，同時可防止使用者狀態資訊被錯誤登錄。
例如，訂購內容受理部142，係亦可判定使用者之性別係不會有變化。又，例如，症狀、妊娠之有無等，係有可能變化。又例如，曾經使用過訂購商品的此一狀態、或有副作用歷的此一狀態，係即使在將來也不會改變；而另一方面，未使用過訂購商品的此一狀態、或沒有副作用歷的此一狀態，係在將來有可能改變。又例如，65歲以上的此一狀態即使在將來也不會改變，但另一方面，未滿15歲的此一狀態係有可能改變。
圖39係重新訂購內容確認網頁之顯示例的圖示。於圖39中，關於和圖35相同之要素，係標示相同的符號。如圖39所示，重新訂購內容確認網頁中係顯示有：訂購內容顯示領域271、使用者狀態資訊顯示領域272、訂購內容編輯鈕273、使用者狀態資訊編輯鈕274、確定鈕275、及使用者狀態資訊重新輸入領域276。在本實施形態中，使用者狀態資訊顯示領域272中係顯示，已被取消之訂購內容所被建立關連對應到的使用者狀態資訊之中，不改變的狀態、及在有效期間內的狀態。使用者狀 態資訊重新輸入領域276中係顯示，已被取消之訂購內容所被建立關連對應到的使用者狀態資訊之中，針對經過了有效期間之狀態的質問與選擇選單277。又，使用者狀態資訊重新輸入領域276中係顯示，要求重新輸入使用者狀態資訊重新輸入領域276中所被顯示之使用者狀態資訊的訊息。選擇選單277，係用來選擇對質問之回答所需之下拉式選單。購入者，係藉由操作選擇選單277以選擇使用者之狀態。然後，一旦購入者選擇確定鈕275，則購入者終端3係針對使用者狀態資訊重新輸入領域276中所被顯示的質問，將相應於選擇選單277之選擇狀態的使用者狀態資訊，發送至電子商店街伺服器1。
為了判定使用者之狀態是否有可能變化、是否為有效期間內，例如在電子商店街伺服器1的記憶部12中，係架構有使用者狀態質問DB12g。圖40係使用者狀態質問DB12g中所被登錄之內容之一例的圖示。使用者狀態質問DB12g中係登錄有，用來質問使用者狀態所需之質問內容、回答之選項、有效期間等。具體而言，在使用者狀態質問DB12g中，狀態項目ID、質問內容之文字、及複數之選項資訊，是按照使用者狀態資訊之每一項目而被建立對應而登錄。狀態項目ID，係為使用者狀態資訊之項目的識別資訊。各選項資訊係含有：回答選項之文字、變化旗標及有效期間日數。變化旗標，係表示選項之文字所示之狀態是否有可能變化。有效期間日數，係為選項之文字所示之狀態為有效的日數。例如亦可由電子商 店街伺服器1的管理者，來登錄這些資訊。店舖對使用者狀態資訊作成質問時，例如隨應於來自店舖終端2之要求，電子商店街伺服器1係將質問作成網頁，發送至店舖終端2。於質問作成網頁中，店舖之從業員，係可選擇使用者狀態質問DB12g中所被登錄之文字所示之質問內容，並且，可從使用者狀態質問DB12g中所被登錄之文字所示之選項之中，複數選擇可回答之選項。店舖終端2，係將已被從業員所選擇之內容當作狀態質問資訊而發送至電子商店街伺服器1，電子商店街伺服器1係將狀態質問資訊登錄至商品DB12c。
此外，訂購內容受理部142，係亦可判定例如：有可能變化之狀態，是否在已被取消之訂購內容被受理時到重新訂購為止，已經變化成特定之狀態。然後，訂購內容受理部142，係在判定使用者之狀態已經變化成特定之狀態的情況下，亦可將使用者狀態資訊變更成特定之狀態。此情況下，訂購內容受理部142係亦可提示出要求重新輸入使用者狀態的資訊。另一方面，訂購內容受理部142，係在判定使用者之狀態不一定會變化成特定之狀態時，則提示出要求重新輸入使用者狀態的資訊。例如，假設被取消之訂購內容被受理時，使用者之狀態係為「預產期為12週以內：是」此一狀態。因此，重新訂購之訂購內容之受理時點上已經經過了12週的情況下，則出產已經結束。此時，訂購內容受理部142，係將該狀態變更成「預產期為12週以內：否」。然後，針對預產期是否為 12週以內此一質問，係不提示要求重新輸入的資訊。另一方面，在重新訂購之訂購內容之受理時點上尚未經過12週的情況下，使用者係有可能已經出產，也有可能尚未出產。因此，訂購內容受理部142，係提示要求重新輸入的資訊。
〔7-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖41及圖42來說明。圖41係本實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購確認網頁送訊處理之一例的流程圖。於圖41中，關於和圖37相同之要素，係標示相同的符號。如圖41所示，訂購內容受理部142係將重新訂購確認要求中所含之訂購號碼所對應的訂購內容及使用者狀態資訊，從訂購DB12e加以取得(步驟S201)。接著，訂購內容受理部142係將所取得的訂購內容、重新訂購確認網頁的HTML文件(步驟S221)。接下來，訂購內容受理部142，係將重新訂購確認要求中所含的訂購號碼所對應之受理日期時間，從訂購DB12e加以取得。然後，訂購內容受理部142，係藉由從現在日期時間減去受理日期時間，以計算經過日數(步驟S222)。接下來，訂購內容受理部142係將號碼i設定成1(步驟S223)。
接下來，訂購內容受理部142係判定，已取得的使用者狀態資訊中的第i個之狀態是否有可能改變 (步驟S224)。具體而言，訂購內容受理部142，係將與使用者狀態資訊中的第i個質問內容一致的質問內容，從使用者狀態質問DB12g中檢索出來，在已被檢索到的質問內容所被建立關連對應到的選項之中，將與使用者狀態資訊中的第i個回答一致的選項，從使用者狀態質問DB12g中檢索出來。接下來，訂購內容受理部142，係取得檢索到的選項所對應之變化旗標及有效期間日數。訂購內容受理部142，係若變化旗標是FALSE時，則判定第i個狀態沒有可能改變(步驟S224：NO)。此時，訂購內容受理部142係前進至步驟S228。另一方面，訂購內容受理部142，係若變化旗標是TRUE時，則判定第i個狀態有可能改變(步驟S224：YES)。此時，訂購內容受理部142係前進至步驟S225。
於步驟S225中，訂購內容受理部142係判定，經過日數是否未滿有效期間日數。此時，訂購內容受理部142係在判定經過日數是未滿有效期間日數時(步驟S225：YES)，則前進至步驟S226。於步驟S226中，訂購內容受理部142係將使用者狀態資訊中的第i個質問及回答的文字，追加至重新訂購確認網頁的HTML文件的使用者狀態資訊顯示領域272。接下來，訂購內容受理部142係前進至步驟S228。另一方面，訂購內容受理部142係在判定經過日數並非未滿有效期間日數時(步驟S225：NO)，則前進至步驟S227。於步驟S227中，訂購內容受理部142係將使用者狀態資訊中的第i個質問的文字、和 用來顯示選擇選單277所需之資料，追加至重新訂購確認網頁的HTML文件的使用者狀態資訊重新輸入領域276。此時，訂購內容受理部142，係將重新訂購確認要求中所含的訂購號碼所對應之店舖ID及商品ID，從訂購DB12e加以取得，將店舖ID及商品ID所對應之狀態質問資訊，從商品DB12c加以取得。然後，訂購內容受理部142，係基於狀態質問資訊而追加資料。接下來，訂購內容受理部142係前進至步驟S228。
於步驟S228中，訂購內容受理部142係判定，號碼i是否和使用者狀態資訊中所含之質問之數目一致。此時，訂購內容受理部142係在判定號碼i是和質問之數目不一致時(步驟S228：NO)，則前進至步驟S229。於步驟S229中，訂購內容受理部142係對號碼i加算1，前進至步驟S224。另一方面，訂購內容受理部142係在判定號碼i是和質問之數目一致時(步驟S228：YES)，則前進至步驟S203。於步驟S203中，訂購內容受理部142，係將訂購履歷網頁之HTML文件，發送至購入者終端3，結束重新訂購確認網頁送訊處理。
圖42係本實施形態所述之電子商店街伺服器1的系統控制部14的重新訂購內容登錄處理之一例的流程圖。於圖42中，關於和圖38相同之要素，係標示相同的符號。如圖38所示，訂購內容受理部142係執行步驟S211~S213。接下來，訂購內容受理部142，係將重新訂購內容確定要求中所含之訂購號碼所對應之使用者狀態資 訊，從訂購DB12e加以取得(步驟S231)。接下來，訂購內容受理部142係判定重新訂購內容確定要求是否含有使用者狀態資訊(步驟S232)。此時，使用者狀態資訊受理部141係在判定重新訂購內容確定要求是含有使用者狀態資訊時(步驟S232：YES)，則前進至步驟S233。於步驟S233中，訂購內容受理部142，係用重新訂購內容確定要求中所含之使用者狀態資訊，將從訂購DB12e取得之使用者狀態資訊予以更新。具體而言，訂購內容受理部142，係將與重新訂購內容確定要求中所含的使用者狀態資訊中所含的質問內容一致的質問內容，從訂購DB12e所取得之使用者狀態資訊中，檢索出來。接下來，訂購內容受理部142，係將所檢索到的訂購內容所對應之回答，置換成重新訂購內容確定要求中所含的使用者狀態資訊中所含的回答。訂購內容受理部142，係將如此處理，針對重新訂購內容確定要求中所含的使用者狀態資訊中所含的每一質問內容，加以執行。接下來，訂購內容受理部142係前進至步驟S216。另一方面，訂購內容受理部142係在判定重新訂購內容確定要求是不含使用者狀態資訊時(步驟S232：NO)，則前進至步驟S216。
於步驟S216中，訂購內容受理部142，係將從訂購DB12e取得之使用者狀態資訊、或步驟S233中所被更新的使用者狀態資訊，追加至訂購資訊。接下來，訂購內容受理部142係執行步驟S217~S219。
如以上說明，若依據本實施形態，則系統控 制部14係若已經被取消受理的訂購內容所被建立關連對應到的使用者狀態資訊是有變化之可能性的資訊時，則取得該使用者狀態資訊的有效期間日數。又，系統控制部14係若已經被取消受理的訂購內容被受理起至重新訂購鈕254被操作為止的經過日數是超過有效期間日數，則令重新訂購內容確認網頁中顯示出使用者狀態資訊重新輸入領域276。因此，也可一面省去重新輸入使用者狀態資訊的麻煩。一面防止因為重新輸入未被進行導致使用者狀態資訊被錯誤記憶。
〔8.第8實施形態〕 〔8-1.系統控制部之機能概要〕
接著，關於第8實施形態中的系統控制部14之機能，使用圖43來說明。除了以下所說明的點以外，第8實施形態基本上是和第5實施形態~第7實施形態相同。如第5實施形態所說明，若購入者經過確認期間日數仍沒有確認留意事項，則取消處理部147係將訂購內容的受理予以取消。在第5實施形態中，確認期間日數係被預先決定。於本實施形態中，取消處理部147，係在藉由購入者指定了訂購商品的配送時期(寄送日或寄送日期時間)時，則以使得訂購商品可在所指定之配送時期以前配送的方式，設定確認期間。取消處理部147，係為本發明中的寄送期限取得手段、確認期限決定手段之一例。由購入者指定了訂購商品之配送時期的情況下，店舖係必須要使得訂 購商品在配送時期以前就被配送的方式，來寄送之。配送時期以前能夠配送訂購商品的最晚的寄送時期(寄送日或寄送日期時間)，稱為寄送期限。因此，為了讓店舖在配送時期以前就寄送訂購商品，購入者必須最晚在寄送期限以前就確認留意事項。配送時期以前能夠配送訂購商品的最晚的留意事項之確認時期(確認日或確認日期時間)，稱為確認期限。取消處理部147，係亦可根據例如寄送期限來設定確認期限。例如，取消處理部147，係亦可將與寄送期限的同一日決定成確認期限，也可將寄送期限之前日或前2日以上前之日子決定成確認期限。
為了設定確認期限，例如在電子商店街伺服器1的記憶部12中係架設有，配送日數DB12h。圖43係配送日數DB12h中所被登錄之內容之一例。配送日數DB12h係登錄有，商品之配送所需的日數。具體而言，在配送日數DB12h中，配送來源地區、配送目標地區及配送日數，是和配送來源地區與配送目標地區之每一組合，建立對應而登錄。配送來源地區，係為商品之寄送來源之地區。配送目標地區，係為商品之寄送目標之地區。配送來源地區及寄送目標地區，係亦可為例如都道府縣。配送日數，係表示從配送來源地區至寄送目標地區的商品之配送所需的日數。例如亦可由電子商店街伺服器1的管理者來設定配送日數。又例如，亦可由電子商店街伺服器1根據過去的實績來設定配送日數。例如，亦可由各店舖輸入實際之寄送日和配送日，電子商店街伺服器1係根據寄送 日及配送日而計算配送日數，根據這些配送日數，決定要登錄至配送日數DB12h的配送日數。又例如，電子商店街伺服器1，係從配送管理伺服器7，將過去從店舖的商品之收貨日及配送日，針對配送來源地區及寄送目標地區之每一組合而加以取得，決定要登錄至配送日數DB12h的配送日數。
〔8-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖44來說明。圖44係本實施形態所述之電子商店街伺服器1的系統控制部14的自動取消處理之一例的流程圖。於圖44中，關於和圖33相同之處理，係標示相同的符號。如圖44所示，取消處理部147係執行步驟S171~S173。於步驟S173中，取消處理部147係在判定留意資訊未被登錄時(步驟S173：NO)，則前進至步驟S179。另一方面，取消處理部147係在判定留意資訊有被登錄時(步驟S173：YES)，則前進至步驟S241。
於步驟S241中，取消處理部147係判定，第i個訂購資訊中所含之配送日期時間指定旗標是否為TRUE。此時，取消處理部147係在判定配送日期時間指定旗標並非TRUE時(步驟S241：NO)，則前進至步驟S174。然後，取消處理部147，係執行步驟S174~S176，在S176中基於判定結果，前進至步驟S177或步驟S179。另一方面，取消處理部147係在判定配送日期時間 指定旗標是TRUE時(步驟S241：YES)，則前進至步驟S242。
於步驟S242中，取消處理部147係決定寄送期限。具體而言，取消處理部147，係從第i個訂購資訊，取得店舖ID及使用者ID。接下來，取消處理部147，係將店舖ID所對應之地址從店舖DB12b加以取得，將該地址所對應之寄送來源地區予以特定。又，取消處理部147，係將使用者ID所對應之地址從會員DB12a加以取得，將該地址所對應之寄送目標地區予以特定。接下來，取消處理部147，係將所特定之寄送來源地區及寄送目標地區之組合所對應之配送日數，從配送日數DB12h加以取得。接下來，取消處理部147，係從第i個訂購資訊中所含的指定配送日期時間，減去配送日數，計算寄送期限。
接下來，取消處理部147，係根據寄送期限而決定確認期限(步驟S243)。例如，取消處理部147，係亦可將與寄送期限相同的期限，決定成確認期限。又例如，取消處理部147係亦可將記憶部12中所預先記憶的日數，從寄送期限中予以減去，來計算確認期限。記憶部12中所記憶之日數，係例如只要為0日以上即可。接下來，取消處理部147，係判定現在日期時間是否比確認期限還晚(步驟S244)。此時，取消處理部147係在判定現在日期時間是比確認期限還晚時(步驟S244：YES)，則前進至步驟S177。然後，取消處理部147，係將取消旗標設定 成TRUE(步驟S177)，發送自動取消通知郵件(步驟S178)，前進至步驟S179。另一方面，取消處理部147係在判定現在日期時間並非比確認期限還晚時(步驟S244：NO)，則前進至步驟S179。取消處理部147，係執行步驟S179~S181。
此外，取消處理部147，係亦可例如在圖16中所示之訂購內容登錄處理中決定確認期限，將確認期限登錄至訂購資訊。然後，取消處理部147，係亦可於自動取消處理中，從訂購資訊取得確認期限然後進行判定。
如以上說明，若依據本實施形態，則系統控制部14係若從購入者所受理到的訂購內容是含有配送日之指定時，則取得用來在該配送日遞送商品所需的寄送期限。又，系統控制部14係根據寄送期限，決定留意資訊之確認期限。又，系統控制部14在所被決定的確認期限以前都沒有受理到購入者訊息，則取消訂購內容之受理。因此，可適切地設定留意資訊的確認期間。
〔9.第9實施形態〕 〔9-1.系統控制部之機能概要〕
接著，關於第9實施形態中的系統控制部14之機能，使用圖45來說明。除了以下所說明的點以外，第9實施形態基本上是和第1實施形態~第8實施形態相同。圖45係本實施形態所述之宿泊設施預約伺服器1的系統控制部14的機能區塊之一例的圖示。於圖45中，關於和 圖3(b)相同之要素，係標示相同的符號。如圖45所示，系統控制部14係成為：使用者狀態資訊受理部141、訂購內容受理部142、訊息處理部143、訊息處理部143、狀態控制部144、接單資訊提供部145、訂購履歷提供部146、提醒處理部148等而發揮機能。提醒處理部148，係為本發明中的次數取得手段及時間間隔決定手段之一例。
提醒處理部148，係在用來向購入者通知留意資訊已被登錄的店舖訊息登錄通知郵件被登錄後，若沒有受理到表示留意資訊已確認的購入者訊息，則輸出向購入者催促確認留意資訊的資訊。具體而言，提醒處理部148，作為此種資訊是向購入者發送留意資訊確認提醒郵件。提醒郵件，係為本發明中的提醒資訊之一例。
尤其在本實施形態中，提醒處理部148，係將留意資訊確認提醒郵件，每隔所定時間間隔加以送訊。甚至，提醒處理部148係在店舖訊息登錄通知郵件已被登錄後，根據直到表示留意資訊已確認的購入者訊息被受理以前所被發送的留意資訊確認提醒郵件之數目，來決定發送留意資訊確認提醒郵件的時間間隔。購入者訊息被受理為止所發送的留意資訊確認提醒郵件之數目，稱為提醒次數。將發送留意資訊確認提醒郵件的時間間隔，稱為提醒時間間隔。提醒時間間隔的預設值，係亦可由例如電子商店街伺服器1的管理者預先設定。例如，預設值係可為所定小時，也可為所定日數。
例如，假設預設值為1日。留意資訊確認提醒郵件被發送3次後，購入者確認了留意資訊時，則第1封及第2封的留意資訊確認提醒郵件就有沒有必要發送之或然性。於是，提醒處理部148，係將例如提醒時間間隔，變更成3日。又，亦可將提醒時間間隔縮短。如此，配合購入者有確認留意資訊確認提醒郵件之留意資訊之或然性的時間點，而由提醒處理部148來決定提醒時間間隔，就可削減提醒處理部148所致之無謂的送訊處理，而且可提高送訊處理之效率。
為了決定留意資訊確認提醒郵件之送訊時間點，例如在會員DB12a中，還會登錄有每一購入者的現在之提醒時間間隔。最初，提醒時間間隔係被設定成預設值。又，例如在訂購DB12e中係還登錄有，下次提醒日期時間、及提醒次數。下次提醒日期時間，係表示下一次留意資訊確認提醒郵件被發送的日期時間。
〔8-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖46乃至圖48來說明。圖46係本實施形態所述之電子商店街伺服器1的系統控制部14的提醒時間間隔決定處理之一例的流程圖。例如，在圖20中所示之購入者訊息登錄處理中若確認狀態是已被設定成確認完成，則系統控制部14係亦可執行提醒時間間隔決定處理。如圖46所示，提醒處理部148，係從確認狀態已被 設定成確認完成的訂購資訊，取得使用者ID。然後，提醒處理部148，係在從訂購DB12e所取得的使用者ID所對應之訂購資訊之中，檢索出商品區分是指定醫藥品、確認狀態是確認完成的訂購資訊(步驟S261)。接下來，提醒處理部148係判定是否找到訂購資訊(步驟S262)。此時，提醒處理部148係在判定未找到訂購資訊時(步驟S262：NO)，則前進至步驟S263。於步驟S263中，提醒處理部148係將提醒時間間隔設定成預設值，前進至步驟S266。另一方面，提醒處理部148係在判定有找到訂購資訊時(步驟S262：YES)，則前進至步驟S264。
於步驟S264中，提醒處理部148係判定，找到的訂購資訊之數目，是否和記憶部12中預先記憶的設定值一致。此時，提醒處理部148係在判定訂購資訊之數目與設定值不一致時(步驟S264：NO)，則結束提醒時間間隔決定處理。另一方面，提醒處理部148係在判定訂購資訊之數目是與設定值一致時(步驟S264：YES)，則前進至步驟S265。於步驟S265中，提醒處理部148係從找到的訂購資訊之每一者，取得過去的提醒次數。然後，提醒處理部148，係根據過去之提醒次數，來決定提醒時間間隔。例如，提醒處理部148，係亦可對過去之提醒次數之最頻值或平均值等之代表值，乘上預設值，而計算提醒時間間隔。此處，若代表值為0，則提醒處理部148，係例如，將提醒時間間隔維持成預設值即可，也可將提醒時間間隔設成比預設值還短。提醒處理部148，係一旦結束步 驟S265，就前進至步驟S266。於步驟S266中，提醒處理部148，係將所設定之提醒時間間隔，與所取得之使用者ID建立對應而登錄至會員DB12a。提醒處理部148，係一旦結束步驟S266就結束提醒時間間隔決定處理。
圖47係本實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。於圖47中，關於和圖18相同之處理，係標示相同的符號。如圖47所示，訊息處理部143係執行步驟S71~S74。接下來，提醒處理部148係判定，這次所設定之訊息號碼是否為1(步驟S271)。亦即，提醒處理部148，係判定本次留意資訊是否已經登錄。此時，提醒處理部148係在判定訊息號碼並非1時(步驟S271：NO)，則結束店舖訊息登錄處理。另一方面，提醒處理部148係在判定訊息號碼是1時(步驟S271：YES)，則前進至步驟S272。於步驟S272中，提醒處理部148係將從店舖終端2所接收到的訂購號碼所對應之使用者ID，從訂購DB12e加以取得。然後，提醒處理部148，係將使用者ID所對應之提醒時間間隔，從會員DB12a加以取得。接下來，提醒處理部148，係對現在日期時間加算提醒時間間隔，計算下次提醒日期時間(步驟S273)。然後，提醒處理部148，係與所接收到的訂購號碼建立對應而將下次提醒日期時間登錄至訂購DB12e。又，提醒處理部148，係將已被設定成0的提醒次數，與訂購號碼建立對應而登錄至訂購DB12e(步驟S274)。提醒處理部148，係一旦結束步驟 S274就結束店舖訊息登錄處理。
圖48係本實施形態所述之電子商店街伺服器1的系統控制部14的提醒郵件送訊處理之一例的流程圖。例如，系統控制部14係定期地執行提醒郵件送訊處理。例如，系統控制部14，係亦可每隔所定時間就執行提醒郵件送訊處理。
如圖48所示，提醒處理部148，係從訂購DB12e，檢索出商品區分是指定醫藥品、確認狀態為確認未完成、且取消旗標為FALSE的訂購資訊(步驟S281)。接下來，提醒處理部148係將號碼i設定成1(步驟S282)。接下來，提醒處理部148，係在被檢索到的訂購資訊之中，從第i個訂購資訊取得下次提醒日期時間。然後，提醒處理部148係判定，現在日期時間是否比下次提醒日期時間還晚(步驟S283)。此時，提醒處理部148係在判定現在日期時間並非比下次提醒日期時間還晚時(步驟S283：NO)，則前進至步驟S288。另一方面，提醒處理部148係在判定現在日期時間是比下次提醒日期時間還晚時(步驟S283：YES)，則前進至步驟S284。
於步驟S284中，提醒處理部148係發送留意資訊確認提醒郵件。具體而言，提醒處理部148係將第i個訂購資訊中所含之使用者ID所對應之電子郵件位址，從會員DB12a加以取得。然後，提醒處理部148係生成將所取得之電子郵件位址儲存成送件位址的留意資訊確認提醒郵件。又，提醒處理部148，係根據第i個訂購資 訊，而將訂購號碼、商品名等，追加至留意資訊確認提醒郵件之本文。然後，提醒處理部148係將所生成的留意資訊確認提醒郵件予以發送。
接下來，提醒處理部148係將第i個訂購資訊中所含之使用者ID所對應之提醒時間間隔，從會員DB12a加以取得(步驟S285)。接下來，提醒處理部148，係對所取得的下次提醒日期時間加算提醒時間間隔，計算新的下次提醒日期時間。然後，提醒處理部148，係將第i個訂購資訊中所含的下次提醒日期時間，更新成新的下次提醒日期時間(步驟S286)。接下來，提醒處理部148，係對第i個訂購資訊中所含的提醒次數加算1而計算新的提醒次數。然後，提醒處理部148，係將第i個訂購資訊中所含的提醒次數，更新成新的提醒次數(步驟S287)。接下來，提醒處理部148係前進至步驟S288。
於步驟S288中，提醒處理部148係判定，號碼i是否和檢索到的訂購資訊之數目一致。此時，提醒處理部148係在判定號碼i是和訂購資訊之數目不一致時(步驟S288：NO)，則前進至步驟S289。於步驟S289中，提醒處理部148係對號碼i加算1，前進至步驟S283。另一方面，提醒處理部148係在判定號碼i是和訂購資訊之數目一致時(步驟S288：YES)，則結束提醒郵件送訊處理。
此外，在圖46所示之提醒時間間隔決定處理中，提醒處理部148，係只有在購入者有確認留意資訊的 訂購之數目是與設定值一致時，亦即只有1次，決定提醒時間間隔。然而，提醒處理部148係亦可例如無關於購入者有確認留意資訊的訂購之數目為何，每次都決定提醒時間間隔。此情況下，提醒處理部148，係除了過去之提醒次數，還必須使用當時的提醒時間間隔，來決定新的提醒時間間隔。其理由為，當時的提醒時間間隔有可能和預設值不同。具體而言，圖47所示之店舖訊息登錄處理中，提醒處理部148係將從會員DB12a所取得之提醒時間間隔(步驟S272)，登錄至訂購資訊。於圖46所示之提醒時間間隔決定處理中，提醒處理部148，係針對找到的每一訂購資訊，對過去之提醒次數乘上當時之提醒時間間隔，計算留意資訊未確認時間。然後，提醒處理部148係亦可例如，將留意資訊未確認時間之最頻值或平均值等之代表值，決定成為提醒時間間隔。
如以上說明，若依據本實施形態，則系統控制部14係在店舖訊息登錄通知郵件已被輸出後，取得購入者訊息被受理為止的留意資訊確認提醒郵件所被輸出之次數。又，系統控制部14係將留意資訊確認提醒郵件輸出的時間間隔，隨應於所取得的次數而加以決定。因此，可有效率地輸出留意資訊確認提醒郵件。
〔10.第10實施形態〕 〔10-1.系統控制部之機能概要〕
接著，說明第10實施形態中的系統控制部14之機 能。除了以下所說明的點以外，第10實施形態基本上是和第9實施形態相同。在本實施形態中，提醒處理部148，係根據表示已經確認留意資訊的購入者訊息所被受理之時間，來決定發送留意資訊確認提醒郵件的時間點。提醒處理部148，係為本發明中的時間取得手段之一例。例如，提醒處理部148，係將購入者有確認留意資訊之傾向的時間帶加以特定，在該時間帶之前，發送留意資訊確認提醒郵件。藉此，可提高購入者確認留意資訊的或然性。例如，時間帶之長度係被預先設定。會員DB12a中係還登錄有，每一購入者的提醒時刻。提醒時刻，係留意資訊確認提醒郵件被發送的時刻。
〔10-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖49及圖50來說明。圖49係本實施形態所述之電子商店街伺服器1的系統控制部14的提醒時間間隔決定處理之一例的流程圖。於圖49中，關於和圖46相同之處理，係標示相同的符號。如圖49所示，提醒處理部148係執行步驟S261~S266。接下來，提醒處理部148，係從找到的訂購資訊之每一者，取得訂購號碼。接下來，提醒處理部148，係針對所取得的每一訂購號碼，從訊息DB12f，將訂購號碼所對應之購入者送訊日期時間之中最晚的購入者送訊日期時間，當作確認完成日期時間而加以取得(步驟S301)。接下來，提醒處理部148， 係在分割1日而成的複數時間帶之中，將含有最多確認完成日期時間的時間帶，予以特定(步驟S302)。接下來，提醒處理部148，係將已特定之時間帶的前一個時間帶的開始時刻，決定成提醒時刻(步驟S303)。接下來，提醒處理部148，係與從確認狀態已被設定成確認完成之訂購資訊所取得的使用者ID建立對應，而將提醒時刻，登錄至會員DB12a(步驟S304)。提醒處理部148，係一旦結束步驟S304就結束提醒時間間隔決定處理。
圖50係本實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。於圖50中，關於和圖47相同之處理，係標示相同的符號。如圖50所示，訊息處理部143係執行步驟S71~S74，提醒處理部148係執行步驟S271~S273。接下來，提醒處理部148，係將從訂購DB12e所取得之使用者ID所對應之會員資訊，從會員DB12a中加以特定出來，判定會員資訊中是否有被登錄提醒時刻(步驟S311)。此時，提醒處理部148係在判定提醒時刻有被登錄時(步驟S311：YES)，則前進至步驟S312。於步驟S312中，提醒處理部148，係將所計算之下次提醒日期時間中所含之時刻，更新成提醒時刻。然後，提醒處理部148，係將已被變更的下次提醒日期時間，與接收到的訂購號碼建立對應而將下次提醒日期時間登錄至訂購DB12e。接下來，提醒處理部148係前進至步驟S274。
此外，提醒處理部148，係亦可每隔提醒時間 間隔就發送留意資訊確認提醒郵件。例如，提醒處理部148係亦可在用來通知留意資訊已被登錄的店舖訊息登錄通知郵件之送訊起的所定日數後、訂購內容被自動取消的所定日數前、所定的星期幾、或所定的日子等，發送留意資訊確認提醒郵件。此情況下，提醒處理部148，係只在在決定的提醒時刻，發送留意資訊確認提醒郵件即可。
如以上說明，若依據本實施形態，則系統控制部14，係將留意資訊確認提醒郵件的輸出時間，隨應於購入者訊息所被受理之時間而加以決定。因此，可提高購入者確認留意資訊的或然性。
〔11.第11實施形態〕 〔11-1.系統控制部之機能概要〕
接著，說明第11實施形態中的系統控制部14之機能。除了以下所說明的點以外，第11實施形態基本上是和第1實施形態~第8實施形態相同。在本實施形態中，系統控制部14係和第9實施形態同樣地，成為：使用者狀態資訊受理部141、訂購內容受理部142、訊息處理部143、訊息處理部143、狀態控制部144、接單資訊提供部145、訂購履歷提供部146、提醒處理部148等而發揮機能。然而，提醒處理148，係用與第9實施形態不同的方法，來決定留意資訊確認提醒郵件的送訊時間點。提醒處理部148，係為本發明中的商品數取得手段之一例。
具體而言，提醒處理部148，係針對每一指定 醫藥品，在訂購內容已被受理的指定醫藥品之中，隨應於寄送尚未完成的指定醫藥品之數量，來決定發送留意資訊確認提醒郵件的頻繁度。該頻繁度稱為提醒頻繁度。寄送尚未完成的商品之數量，稱為未寄送訂購商品數。提醒處理部148係亦可例如未寄送訂購商品數越多，則將提醒頻繁度設得越高。提醒頻繁度越高，購入者確認留意資訊的或然性就越高。若購入者確認留意資訊，完成支付相關之處理，則店舖就可寄送商品。因此，藉由提醒處理部148來提高提醒頻繁度，對店舖而言可以減少未寄送訂購商品數。
又，提醒處理部148，係亦可例如根據未寄送訂購商品數和庫存數，來決定提醒頻繁度。例如，提醒處理部148，係若未寄送訂購商品數相對於庫存數的比率越大，則將提醒頻繁度設得越高。藉此，可以解決尚未被寄送之訂購商品壓迫到庫存。
〔11-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖51來說明。此外，以下的例子中，將提醒頻繁度以提醒時間間隔來表示。圖51係本實施形態所述之電子商店街伺服器1的系統控制部14的店舖訊息登錄處理之一例的流程圖。於圖51中，關於和圖18相同之處理，係標示相同的符號。如圖51所示，訊息處理部143係執行步驟S71~S74。接下來，提醒處理部148係判 定，這次所設定之訊息號碼是否為1(步驟S321)。此時，提醒處理部148係在判定訊息號碼並非1時(步驟S321：NO)，則結束店舖訊息登錄處理。另一方面，提醒處理部148係在判定訊息號碼是1時(步驟S321：YES)，則前進至步驟S322。
於步驟S322中，提醒處理部148係將從店舖終端2所接收到的訂購號碼所對應之店舖ID及商品ID，從訂購DB12e加以取得。接下來，提醒處理部148，係將店舖ID及商品ID之組合所對應之訂購資訊，從訂購DB12e檢索出來。接下來，提醒處理部148，係從所被檢索到的訂購資訊，抽出寄送狀態並非寄送完成的訂購資訊。接下來，提醒處理部148，係從已抽出的訂購資訊之每一者，取得商品之個數。然後，提醒處理部148，係計算商品之個數之合計，來作為未寄送訂購商品數(步驟S323)。接下來，提醒處理部148，係將店舖ID及商品ID之組合所對應之庫存數，從商品DB12c加以取得。然後，提醒處理部148，係計算未寄送訂購商品數相對於庫存數之比率(步驟S324)。接下來，提醒處理部148，係隨應於所計算之比率來決定提醒時間間隔(步驟S325)。具體而言，提醒處理部148，係比率越大則越縮短提醒時間間隔。例如，亦可每一比率地，將比率與提醒時間間隔建立對應而儲存的表格，記憶在記憶部12中。然後，提醒處理部148，係亦可根據該表格，來決定提醒時間間隔。接下來，提醒處理部148，係對現在日期時間加算提醒時間 間隔，計算下次提醒日期時間(步驟S326)。然後，提醒處理部148，係與所接收到的訂購號碼建立對應而將下次提醒日期時間登錄至訂購DB12e。提醒處理部148，係一旦結束步驟S326就結束店舖訊息登錄處理。於本實施形態中也是，提醒處理部148，係只要執行圖47所示的提醒郵件送訊處理即可。
如以上說明，若依據本實施形態，則系統控制部14係若訂購商品是指定醫藥品時，則針對該商品，於目前為止所受理的1個以上之訂購內容之中，將隨應於尚未完成寄送的訂購內容的未寄送訂購商品數，加以取得。又，系統控制部14係將留意資訊確認提醒郵件輸出的頻繁度，隨著未寄送訂購商品數越多而設成越高。因此，可減少因為購入者未確認留意資訊導致店舖不能寄送的商品之數量。
〔12.第12實施形態〕 〔12-1.系統控制部之機能概要〕
接著，關於第12實施形態中的系統控制部14之機能，使用圖52來說明。除了以下所說明的點以外，第11實施形態基本上是和第1實施形態~第11實施形態相同。於本實施形態中，訂購內容受理部142係在針對任一商品將訂購內容受理完成網頁發送至購入者終端3時，若從購入者針對指定醫藥品在過去曾經受理過的訂購內容所被建立關連對應到的確認狀態是確認未完成，則令用來催 促留意資訊之確認的資訊被提示在訂購內容受理完成網頁中。藉此，可在對購入者而言不會打擾的時間點上，讓購入者想起確認留意資訊。訂購內容受理部142，係為本發明中的受理資訊提示控制手段之一例。
圖52係訂購內容受理完成網頁之顯示例的圖示。如圖52所示，訂購內容受理完成網頁中係顯示，表示訂購內容已被受理的訊息281。訊息281，係為本發明中的受理資訊之一例。若有購入者尚未完成留意資訊之確認的訂購商品，則訂購內容受理完成網頁中係還會顯示用來催促留意資訊之確認的訊息282及店舖訊息確認連結283。店舖訊息確認連結283，係為前往關於訊息282所示之訂購商品的訊息確認網頁的超連結。
〔12-2.系統控制部之動作〕
接著，關於電子商店街伺服器1的系統控制部14的具體動作，使用圖53來說明。圖53係本實施形態所述之電子商店街伺服器1的系統控制部14的訂購內容受理完成送訊處理之一例的流程圖。圖16所示之訂購內容登錄處理完成時，訂購內容受理部142係執行訂購內容受理完成送訊處理。如圖53所示，訂購內容受理部142，係從記憶部12取得要作為樣版的訂購內容受理完成網頁的HTML文件。接下來，從訂購內容登錄處理所登錄的訂購資訊，取得使用者ID。接下來，訂購內容受理部142係在已取得之使用者ID所對應的訂購資訊之中，將確認狀 態是確認未完成的訂購資訊，從訂購DB12e中檢索出來(步驟S331)。接下來，訂購內容受理部142係判定是否找到訂購資訊(步驟S332)。此時，訂購內容受理部142係在判定未找到訂購資訊時(步驟S332：NO)，則前進至步驟S334。另一方面，訂購內容受理部142係在判定有找到訂購資訊時(步驟S332：YES)，則前進至步驟S333。
於步驟S333中，訂購內容受理部142係將用來顯示訊息282及店舖訊息確認連結283所需之資料，追加至訂購內容受理完成網頁。具體而言，訂購內容受理部142，係將找到的訂購資訊中所含的店舖ID及商品ID所對應之商品名，從商品DB加以取得。接下來，訂購內容受理部142係生成，含有所取得之商品名的訊息282之文字。然後，訂購內容受理部142係將該文字追加至HTML文件。又，訂購內容受理部142，係根據訂購資訊中所含的訂購號碼，生成訊息確認網頁之URL。接下來，訂購內容受理部142，係作為用來顯示店舖訊息確認連結283所需之資訊，而將例如含有訊息確認網頁之URL的標籤資料，追加至HTML文件。訂購內容受理部142，係一旦結束步驟S333，就前進至步驟S334。於步驟S334中，訂購內容受理部142，係將訂購內容受理完成網頁之HTML文件，發送至購入者終端3，結束訂購內容受理完成送訊處理。
如以上說明，若依據本實施形態，則系統控制部14係若從購入者針對指定醫藥品在過去曾經受理過 的訂購內容所被建立關連對應到的確認狀態是確認未完成，則在訂購內容受理完成網頁中，提示出表示訂購內容已被受理的訊息281，以及用來催促留意資訊之確認的訊息282。因此，可在對購入者而言不會打擾的時間點上，讓購入者想起確認留意資訊。
此外，於上記各實施形態中，是將本發明適用於，從複數店舖販售商品的電子商店街。然而，本發明亦可適用於，由單一販售商來販售商品的電子商務網站。

Claims (15)

  1. 一種資訊系統，其特徵為，具備：狀態資訊受理手段，係若購入者所訂購之商品是要從商品之販售者向購入者提供使用之際之留意資訊的對象商品時，則從前記購入者受理使用前記商品之使用者的狀態資訊；和訂購內容記憶控制手段，係在從前記購入者受理了商品之訂購內容時，令該訂購內容被記憶在訂購內容記憶手段中；和確認狀態記憶控制手段，係若已被受理之前記訂購內容所示的商品是前記對象商品時，則與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而令前記留意資訊之確認狀態且是被設定成未完成狀態的確認狀態，被記憶在確認狀態記憶手段中；和留意資訊輸出手段，係將隨應於前記訂購內容所示之前記對象商品和已被前記狀態資訊受理手段所受理之前記狀態資訊而被生成的留意資訊，輸出成可讓前記購入者確認；和確認通知受理手段，係受理表示前記購入者已經確認理解了前記留意資訊的確認通知；和更新手段，係在藉由前記確認通知受理手段受理了前記確認通知時，將前記確認狀態記憶手段中所記憶的前記確認狀態，更新成完成狀態；和確認狀態輸出手段，係將前記確認狀態記憶手段中所 記憶的前記確認狀態，輸出成可以判定用來使前記訂購內容所示之前記對象商品之販售成立所需的處理是否可行。
  2. 如請求項1所記載之資訊系統，其中，還具備：狀態記憶控制手段，係與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而令該訂購內容所示之商品的購入費用之支付所需的處理狀態、和該商品之寄送狀態，被記憶在狀態記憶手段中；和第1寄送狀態更新手段，係若前記訂購內容所示之商品並非前記對象商品時，則以前記處理狀態已經被更新成完成狀態為條件，將前記寄送狀態更新成可寄送狀態；和第2寄送狀態更新手段，係若前記訂購內容所示之商品是前記對象商品時，則以前記處理狀態與前記確認狀態均已經被更新成完成狀態為條件，將前記寄送狀態更新成可寄送狀態；和寄送狀態輸出手段，係將前記狀態記憶手段中所記憶的前記寄送狀態，予以輸出。
  3. 如請求項1或2所記載之資訊系統，其中，還具備：連結資訊提示控制手段，係若前記訂購內容所示之商品是前記對象商品時，則令往前記留意資訊之連結資訊被提示；前記留意資訊輸出手段，係在前記連結資訊被選擇時，令可操作之確認要素被提示以用來表示已確認前記留意資訊與理解了該留意資訊之事實； 前記確認通知受理手段，係取得以前記確認要素有被操作之事實為依據的前記確認通知。
  4. 如請求項1或2所記載之資訊系統，其中，前記確認狀態輸出手段，係針對前記訂購內容記憶手段中所記憶之前記訂購內容，令販售者專用之資訊被提示，若前記訂購內容所示之商品是前記對象商品時，則令外觀隨著該訂購內容所被建立關連對應到的前記確認狀態而變化的影像，連同前記販售者專用之資訊一併被提示。
  5. 如請求項1或2所記載之資訊系統，其中，還具備：訂購內容輸出手段，係將前記訂購內容記憶手段中所記憶之前記訂購內容，輸出給販售者專用，其中，該訂購內容輸出手段係為，若前記訂購內容所示之商品是前記對象商品，且前記訂購內容所被建立關連對應到的前記確認狀態係為未完成狀態時，則在前記訂購內容之中，不將商品的寄送目標地址予以輸出。
  6. 如請求項1或2所記載之資訊系統，其中，還具備：配送傳票受理手段，係用來受理前記訂購內容記憶手段中所記憶之前記訂購內容所示之商品的配送傳票資訊之輸入，其中，該配送傳票受理手段係為，若前記商品是前記對象商品且前記訂購內容所被建立關連對應到的前記確認狀態是未完成狀態時，則不受理前記配送傳票資訊。
  7. 如請求項1或2所記載之資訊系統，其中，還具備： 通知資訊輸出手段，係在前記留意資訊被生成時，輸出向前記購入者通知需要確認該留意資訊的通知資訊；和取消手段，係在從前記通知資訊輸出手段輸出前記通知資訊起算的設定期間內，都沒有藉由前記確認通知受理手段受理到前記確認通知的情況下，則取消前記訂購內容之受理。
  8. 如請求項7所記載之資訊系統，其中，還具備：狀態資訊記憶控制手段，係令已被前記狀態資訊受理手段所受理之前記狀態資訊，與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而被記憶在狀態資訊記憶手段中；和取消訂購提示控制手段，係令已經被取消受理的訂購內容的至少一部分、和為了該訂購內容所示之商品的重新訂購所需而可操作之重新訂購要素，被提示出來；前記狀態資訊受理手段，係在基於前記重新訂購要素已被操作之事實而受理前記重新訂購所需之訂購內容時，將前記已經被取消受理的訂購內容所被建立關連對應到的狀態資訊，當作與前記重新訂購所需之訂購內容建立關連對應的狀態資訊而加以取得。
  9. 如請求項8所記載之資訊系統，其中，還具備：有效日數取得手段，係若前記已經被取消受理的訂購內容所被建立關連對應到的狀態資訊是有變化之可能性的 資訊時，則取得該狀態資訊之有效日數；和要求資訊提示控制手段，係若前記已經被取消受理的訂購內容被受理起至前記重新訂購要素被操作為止的經過日數，是超過已被前記有效日數取得手段所取得之前記有效日數時，則提示向前記購入者要求重新輸入前記使用者之狀態資訊的要求資訊；前記狀態資訊受理手段，係將從前記購入者所重新輸入的狀態資訊，予以受理。
  10. 如請求項7所記載之資訊系統，其中，還具備：寄送期限取得手段，係若從前記購入者所受理到的訂購內容是含有配送日之指定時，則取得用來在該配送日遞送商品所需的寄送期限；和確認期限決定手段，根據前記寄送期限，來決定前記留意資訊之確認期限；前記取消手段，係若到了已被前記確認期限決定手段所決定之前記確認期限為止都沒有藉由前記確認通知受理手段受理到前記確認通知的情況下，則取消前記訂購內容之受理。
  11. 如請求項1或2所記載之資訊系統，其中，還具備：次數取得手段，係針對已被生成之前記留意資訊而向前記購入者通知需要確認該留意資訊的通知資訊已被輸出後，直到藉由前記確認通知受理手段受理到前記確認通知 以前，取得向前記購入者催促前記留意資訊之確認的提醒資訊且為每隔所定時間間隔就被輸出的提醒資訊所被輸出的次數；和時間間隔決定手段，係將前記通知資訊被輸出後前記確認通知未被受理的訂購內容所需的前記提醒資訊的輸出之時間間隔，隨應於前記次數取得手段所取得之前記次數而加以決定。
  12. 如請求項1或2所記載之資訊系統，其中，還具備：時間取得手段，係取得藉由前記確認通知受理手段受理了前記確認通知的時間；和時間決定手段，係將針對已被生成之前記留意資訊而向前記購入者通知需要確認該留意資訊的通知資訊已被輸出後前記確認通知未被受理時的向前記購入者催促前記留意資訊之確認的提醒資訊的輸出之時間，隨應於前記時間取得手段所取得之前記時間而加以決定。
  13. 如請求項1或2所記載之資訊系統，其中，還具備：商品數取得手段，係若從前記購入者所受理之前記訂購內容所示的商品是前記對象商品時，則針對該商品將目前為止所受理的1個以上之訂購內容之中尚未完成寄送的訂購內容所相應的前記商品之數目，加以取得；和頻繁度決定手段，係決定針對已被生成之前記留意資訊而向前記購入者通知需要確認該留意資訊的通知資訊已 被輸出後，前記確認通知未被受理時的向前記購入者催促前記留意資訊之確認的提醒資訊的輸出之頻繁度，其中，該頻繁度決定手段係為，已被前記商品數取得手段所取得的前記數目越多，則將前記頻繁度設得越高。
  14. 如請求項1或2所記載之資訊系統，其中，還具備：受理資訊提示控制手段，係在從前記購入者受理了任一商品的訂購內容時，就令表示該訂購內容已被受理的受理資訊被提示出來，其中，該受理資訊提示控制手段係為，若從前記購入者針對前記對象商品在過去曾經受理過的訂購內容所被建立關連對應到的確認狀態係為未完成狀態時，則令用來催促前記留意資訊之確認的資訊連同前記受理資訊一併被顯示。
  15. 一種資訊處理方法，係屬於被電腦所執行的資訊處理方法，其特徵為，含有：狀態資訊受理步驟，係若購入者所訂購之商品是要從商品之販售者向購入者提供使用之際之留意資訊的對象商品時，則從前記購入者受理使用前記商品之使用者的狀態資訊；和訂購內容記憶控制步驟，係在從前記購入者受理了商品之訂購內容時，令該訂購內容被記憶在訂購內容記憶手段中；和確認狀態記憶控制步驟，係若前記訂購內容所示的商品是前記對象商品時，則與前記訂購內容記憶手段中所被記憶的前記訂購內容建立關連，而令前記留意資訊之確認 狀態且是被設定成未完成狀態的確認狀態，被記憶在確認狀態記憶手段中；和留意資訊輸出步驟，係將隨應於前記訂購內容所示之前記對象商品和已被前記狀態資訊受理步驟所受理之前記狀態資訊而被生成的留意資訊，輸出成可讓前記購入者確認；和確認通知受理步驟，係受理表示前記購入者已經確認理解了前記留意資訊的確認通知；和更新步驟，係在藉由前記確認通知受理步驟受理了前記確認通知時，將前記確認狀態記憶手段中所記憶的前記確認狀態，更新成完成狀態；和確認狀態輸出步驟，係將前記確認狀態記憶手段中所記憶的前記確認狀態，輸出成可以判定用來使前記訂購內容所示之前記對象商品之販售成立所需的處理是否可行。
TW104107412A 2014-06-06 2015-03-09 資訊系統及資訊處理方法 TWI614709B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014118096A JP5658842B1 (ja) 2014-06-06 2014-06-06 情報システム及び情報処理方法

Publications (2)

Publication Number Publication Date
TW201541384A true TW201541384A (zh) 2015-11-01
TWI614709B TWI614709B (zh) 2018-02-11

Family

ID=52437479

Family Applications (1)

Application Number Title Priority Date Filing Date
TW104107412A TWI614709B (zh) 2014-06-06 2015-03-09 資訊系統及資訊處理方法

Country Status (3)

Country Link
US (1) US20150356654A1 (zh)
JP (1) JP5658842B1 (zh)
TW (1) TWI614709B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI750701B (zh) * 2020-06-18 2021-12-21 遠東百貨股份有限公司 推播系統及其操作方法

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107590166B (zh) * 2016-12-20 2019-02-12 百度在线网络技术（北京）有限公司 一种基于查询内容的数据生成方法及装置
US10489980B1 (en) * 2017-03-30 2019-11-26 Amazon Technologies, Inc. Data discovery through visual interactions
US10606449B2 (en) 2017-03-30 2020-03-31 Amazon Technologies, Inc. Adjusting audio or graphical resolutions for data discovery
KR101934807B1 (ko) * 2017-11-15 2019-01-03 고권석 온라인 공개 배송시스템
JP7211899B2 (ja) * 2018-07-03 2023-01-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法及び情報処理装置
JP2020107236A (ja) * 2018-12-28 2020-07-09 富士化学工業株式会社 指示医薬品類の販売プログラム及びシステム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU7111100A (en) * 1999-08-31 2001-03-26 Accenture Llp System, method, and article of manufacture for electronic merchandising in an e-commerce application framework
JP2002024390A (ja) * 2000-07-06 2002-01-25 Kobayashi Pharmaceut Co Ltd オンラインショッピングシステム
JP2003162574A (ja) * 2001-11-27 2003-06-06 Micronet Co Ltd 賃貸住宅仲介システム
JP2004094377A (ja) * 2002-08-29 2004-03-25 Mizuho Bank Ltd 商品販売方法及び商品販売プログラム
JP3671173B2 (ja) * 2002-10-10 2005-07-13 三井住友海上火災保険株式会社 保険募集支援サーバ
US9141764B2 (en) * 2010-11-12 2015-09-22 Edge Medical Properties, Llc System and method for online integrated multiple tablet ordering
US7707070B2 (en) * 2006-03-31 2010-04-27 Sap Ag Method and system for dynamic purchase order handling
US9123069B1 (en) * 2008-02-11 2015-09-01 Amazon Technologies, Inc. Moving transaction details forward in buying process
JP5556008B2 (ja) * 2008-12-16 2014-07-23 株式会社寺岡精工 会計システム
US20150206262A1 (en) * 2009-09-30 2015-07-23 Mckesson Financial Holdings Systems and methods for determining and communicating notification messages to a point of sale device
US20150170439A1 (en) * 2010-04-27 2015-06-18 Innova Electronics, Inc. Automotive fleet management system having an automated vehicle maintenance and repair referral
JP5535411B1 (ja) * 2014-01-07 2014-07-02 株式会社 ディー・エヌ・エー サーバ装置、プログラム、および、システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI750701B (zh) * 2020-06-18 2021-12-21 遠東百貨股份有限公司 推播系統及其操作方法

Also Published As

Publication number Publication date
TWI614709B (zh) 2018-02-11
US20150356654A1 (en) 2015-12-10
JP5658842B1 (ja) 2015-01-28
JP2015230708A (ja) 2015-12-21

Similar Documents

Publication Publication Date Title
TWI614709B (zh) 資訊系統及資訊處理方法
JP5523433B2 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
US20160314517A1 (en) Ordering and payment systems
TWI499991B (zh) 於實體銷售點商務前自動講價之方法及設備
TWI584214B (zh) 資訊處理裝置、資訊處理方法、及資訊處理程式產品
US20020095345A1 (en) Standing order system and method
JP5688388B2 (ja) 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体
JP5690393B2 (ja) 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体
TWI575467B (zh) Information processing device, information processing method, memory media
JP2004126825A (ja) カタログギフトシステム及びカタログギフトシステム管理サーバ
US11928725B2 (en) Methods for searching and obtaining design items and meta data concerning the design items
JP2003187151A (ja) 電子取引方法、その方法を実行させるためのプログラム、プログラムを記録した情報記録媒体、情報処理装置、及び電子取引システム
AU2021107626A4 (en) Real estate buyer identification tool and method of use
US11810047B2 (en) Certified deliveries of high-value items
US20230092351A1 (en) Information processing device, information processing program, and supported medium
KR20180000160A (ko) 모듈화된 개별 제품에 대한 콘텐츠 기반의 제품 판매 편의 제공방법
JP6683319B2 (ja) 情報処理装置、情報処理方法、及び、プログラム
EP4256496A1 (en) System and method for controlling access to a private marketplace on supply chain network
JP2021077277A (ja) 情報処理装置及び情報処理方法
JP2024115223A (ja) 弁当配送オンラインシステム
JP2006058967A (ja) 商品情報の提供方法、提供プログラム、提供システム及びそのサーバ装置
KR20140108488A (ko) 참여형 pos 시스템을 통한 물건 판매 방법 및 물건 판매를 위한 참여형 pos 시스템
JP2003091668A (ja) ネットワークシステム、サーバ装置、情報提供方法及びプログラム
JP2003157376A (ja) ネットワークシステム、識別情報管理方法、サーバ装置、プログラム、および記録媒体
KR20000053769A (ko) 전자상거래 서비스 방법