JP4549316B2 - 電子商取引システム - Google Patents

Description

本発明は、電子商取引システムおよびキャリアサーバに関し、特に、２次元コード読み取り可能な複数の携帯電話端末とキャリアサーバとを備えた電子商取引システム、および、２次元コード読み取り可能な複数の携帯電話端末と通信可能なキャリアサーバに関する。

電子商取引を行なう場合、一般的に、商品の販売者（電子商店の出店者）は、ＰＣ（Personal Computer）をツールにインターネット上のショッピングモールに出店し、商品を展示する。たとえば、特許文献１では、商品の販売者により管理される販売センター端末は、ワークステーション、サーバー等の情報処理装置によって構成されており、内部または外部の記憶装置内に商品管理ＤＢ（データベース）を格納することが記載されている。

また、従来より、電子商取引を円滑に行なうための一策として、バーコードを利用した技術が提案されている。たとえば、特許文献１には、商品購入者の携帯電話端末に内蔵されたバーコード読み取り装置を利用することで、販売センター端末へのアクセスを容易にすることが開示されている。

また、バーコードに関連した技術として、特許文献２には、建設工事用資機材に設けられたバーコードの情報をユーザ端末が接続するバーコードリーダによって読み取ることが開示されている。これによると、建設工事用資機材の効率の良い管理を行なうことが可能となる。
特開２００４−１０２６０８号公報 特開平１０−１３１４９１号公報

従来の電子商取引において、電子商店の出店者は、ＰＣがツールであり、受注業務以外はマニュアル作業が多い。たとえば、商品を受注すると、電子商店の出店者は、宅配業者等に商品発送を依頼し、代金の回収を行なわなければならない。また、受注確認や発送連絡等を電子メールで発信したり、場合によっては、返品の受付もしなければならない。

このため、小規模の事業者にとって、インターネット上のショッピングモールに手軽に出店することは困難であった。

特許文献１および２では、バーコードを利用することで、特定の処理を容易にすることができるが、小規模事業者が、電子商取引の様々な処理を円滑に行なえることについては提案されていない。

本発明は、上記のような問題を解決するためになされたものであって、その目的は、電子商店の出店者が行なうべき各種処理を、小規模事業者でも円滑に行なうことのできる電子商取引システム、およびキャリアサーバを提供することである。

この発明のある局面に従う電子商取引システムは、商品の発注者により所有される携帯電話である発注者端末と、配送業者により所有される携帯電話である配送業者端末と、発注者端末および配送業者端末と携帯電話ネットワークを介して接続されるキャリアサーバとを備える。キャリアサーバは、発注者より商品の受注があった場合に、注文ＩＤを発生させることによって商品の受注処理を行うための受注処理手段と、電子商店の出店者により所有される電子商店端末より、商品の受注時の数量全てが揃わない旨の連絡を受信した場合に、充足分について、商品の発送を可能とするための処理を行ない、不足分については、新たな受注処理を行なうための発送処理手段と、商品の出荷状況を管理するために梱包ごとに作成される出荷用コードを作成するための第１のコード作成手段と、出荷用コードとは異なるコードであって、発注者による商品の受領を管理するために梱包ごとに作成される受領用コードを、注文ＩＤごとに作成するための第２のコード作成手段と、受領用コードを発注者端末に送信するための第１のデータ送信手段とを含む。発注者端末は、キャリアサーバから、携帯電話ネットワークを介して受領用コードを受信するための第１の受信手段と、受信された受領用コードを記憶するための第１の記憶手段とを含む。配送業者端末は、発注者による操作に応じて発注者端末から受領用コードを取得するための取得手段と、取得手段により受領用コードが取得された場合に、発注者が商品を受領したことを確認するための受領確認情報をキャリアサーバに送信するための第２のデータ送信手段とを含む。

これにより、キャリアサーバにおいて、発注者が注文した商品が発注者に届けられたか否かを管理することができる。

好ましくは、発注者端末は、第１の記憶手段に記憶された受領用コードを受領用２次元コードに変換するための第１の変換手段と、受領用２次元コードを表示するための表示手段とをさらに含み、取得手段は、表示手段に表示された受領用２次元コードを撮影するための第１の撮影手段を有する。
好ましくは、受領用コードは、ランダムに作成される。
好ましくは、配送業者端末における、発注者が商品を受領したことの確認は、受領用コードのみを使用して行なわれる。

好ましくは、第１のデータ送信手段は、さらに、受領用コードを配送業者端末に送信し、配送業者端末は、キャリアサーバから、携帯電話ネットワークを介して受領用コードを受信するための第２の受信手段と、受信された受領用コードを記憶するための第２の記憶手段と、第１の撮影手段により撮影された受領用２次元コードに基づく受領用コードと、第２の記憶手段に記憶された受領用コードとが一致したか否かを判断するための第１の判断手段と、第１の判断手段により一致していると判断された場合に、受領確認連絡のデータを生成するための第１の生成手段とをさらに含み、第２のデータ送信手段は、キャリアサーバに対し、受領確認情報として受領確認連絡のデータを送信する。

好ましくは、電子商店の出店者により所有され、キャリアサーバと携帯電話ネットワークを介して接続される携帯電話である電子商店端末と、集荷業者により所有され、キャリアサーバと携帯電話ネットワークを介して接続される携帯電話である集荷業者端末とをさらに備え、第１のデータ送信手段は、さらに、出荷用コードを、電子商店端末および集荷業者端末に送信し、電子商店端末は、キャリアサーバから、携帯電話ネットワークを介して出荷用コードを受信するための第３の受信手段と、受信された出荷用コードを出荷用２次元コードに変換するための第２の変換手段と、出荷用２次元コードの印刷指示を出力するための印刷指示手段とを含み、集荷業者端末は、キャリアサーバから、携帯電話ネットワークを介して出荷用コードを受信するための第４の受信手段と、受信された出荷用コードを記憶するための第３の記憶手段と、出店者により商品の梱包用材に貼り付けられた出荷用２次元コードを撮影するための第２の撮影手段と、撮影された出荷用２次元コードに基づく出荷用コードと、第３の記憶手段に記憶された出荷用コードとが一致したか否かを判断するための第２の判断手段と、第２の判断手段により一致していると判断された場合に、第１の集荷完了連絡のデータを生成するための第２の生成手段と、キャリアサーバに対し、第１の集荷完了連絡のデータを送信するための第３のデータ送信手段とを含む。

好ましくは、キャリアサーバは、集荷業者端末から、携帯電話ネットワークを介して第１の集荷完了連絡のデータを受信するための第５の受信手段をさらに含み、第１のデータ送信手段は、第１の集荷完了連絡のデータが受信された場合に、配送業者端末に受領用コードを送信する。

好ましくは、キャリアサーバは、集荷業者端末から、携帯電話ネットワークを介して第１の集荷完了連絡のデータを受信するための第５の受信手段をさらに含み、第１のデータ送信手段は、第１の集荷完了連絡のデータが受信された場合に、発注者端末に受領用コードを送信する。

好ましくは、第１のデータ送信手段は、さらに、出荷用コードを配送業者端末に送信し、第２の受信手段は、キャリアサーバから、携帯電話ネットワークを介して出荷用コードをさらに受信し、第２の記憶手段は、受信された出荷用コードをさらに記憶し、第１の撮影手段は、梱包用材に貼り付けられた出荷用２次元コードをさらに撮影し、配送業者端末は、撮影された出荷用２次元コードに基づく出荷用コードと、第２の記憶手段に記憶された出荷用コードとが一致したか否かを判断するための第３の判断手段と、第３の判断手段により一致していると判断された場合に、第２の集荷完了連絡のデータを生成するための第３の生成手段とをさらに含み、第２のデータ送信手段は、さらに、キャリアサーバに対し、第２の集荷完了連絡のデータを送信する。

好ましくは、発注者端末は、返品対象の商品の梱包用材に貼り付けられた出荷用２次元コードを撮影するための第３の撮影手段と、撮影された出荷用２次元コードに基づく出荷用コードのデータをキャリアサーバに送信する第４のデータ送信手段とを含み、第５の受信手段は、発注者端末から、携帯電話ネットワークを介して出荷用コードをさらに受信し、キャリアサーバは、出荷用コードが受信された場合に、返品対象の商品の出店者の電子商店端末を検索するための検索手段をさらに含み、第１のデータ送信手段は、さらに、検索された電子商店端末に対し、出荷用コードを送信する。

好ましくは、キャリアサーバは、第１のコード作成手段により作成された出荷用コードを、商品の出店者を識別するための識別情報と関連付けて記憶するための受注管理データベースをさらに含み、検索手段は、受注管理データベースを参照して、返品対象の商品の出店者の電子商店端末を検索する。

好ましくは、電子商店端末は、キャリアサーバより受付けた出荷用コードを記憶するための第４の記憶手段と、返品対象の商品の梱包用材に貼り付けられた出荷用２次元コードを撮影するための第４の撮影手段と、撮影された出荷用２次元コードに基づく出荷用コードと、第４の記憶手段に記憶された出荷用コードとが一致したか否かを判断するための第４の判断手段と、第４の判断手段により一致していると判断された場合に、返品完了連絡のデータを生成するための第４の生成手段と、キャリアサーバに対し、返品完了連絡のデータを送信するための第５のデータ送信手段とをさらに含む。

好ましくは、キャリアサーバは、発注者の口座情報を含む発注者管理データを記憶するための発注者管理テーブルと、配送業者端末より受領確認連絡を受信した場合に、発注者管理テーブルを参照して、発注者の口座より商品の取引に関連する商品関連代金の仮引落処理を行なうための仮引落処理手段と、電子商店端末より返品完了連絡を受信した場合に、発注者管理テーブルを参照して、発注者の口座に商品関連代金の返金処理を行なうための返金処理手段とをさらに含む。

好ましくは、キャリアサーバは、出店者の口座情報を含む電子商店管理データを記憶するための電子商店管理テーブルと、商品の返品期限を経過した場合に、電子商店管理テーブルを参照して、出店者の口座に商品の代金の支払処理を行なうための支払処理手段とをさらに含む。

好ましくは、キャリアサーバは、発注者より商品の受注があった場合に、商品の受注処理を行なうための受注処理手段と、電子商店の出店者により所有される電子商店端末より、商品の受注時の数量全てが揃わない旨の連絡を受信した場合に、充足分について、商品の発送を可能とするための処理を行ない、不足分については、新たな受注処理を行なうための発送処理手段とをさらに含む。

好ましくは、取得手段は、第１の記憶手段に記憶された受領用コードを読み取るための読み取り手段を有する。

好ましくは、第１のデータ送信手段は、さらに、受領用コードを配送業者端末に送信し、配送業者端末は、キャリアサーバから、携帯電話ネットワークを介して受領用コードを受信するための第２の受信手段と、受信された受領用コードを記憶するための第２の記憶手段と、読み取り手段により読み取られた受領用コードと、第２の記憶手段に記憶された受領用コードとが一致したか否かを判断するための判断手段と、判断手段により一致していると判断された場合に、受領確認連絡のデータを生成するための生成手段とをさらに含み、第２のデータ送信手段は、キャリアサーバに対し、受領確認情報として受領確認連絡のデータを送信する。

この発明の他の局面に従うキャリアサーバは、商品の発注者により所有される携帯電話である発注者端末、および、配送業者により所有される携帯電話である配送業者端末と携帯電話ネットワークを介して接続されるキャリアサーバであって、発注者より商品を受注した場合に、商品の出荷状況を管理するために梱包ごとに作成される出荷用コードを作成するための第１のコード作成手段と、出荷用コードとは異なるコードであって、発注者による商品の受領を管理するための受領用コードを作成するための第２のコード作成手段と、受領用コードを、発注者端末に送信するための第１のデータ送信手段と、配送業者端末より、受領用コードに基づいた受領確認情報を受信するためのデータ受信手段とを備える。

好ましくは、キャリアサーバは、電子商店の出店者により所有される携帯電話である電子商店端末、および、集荷業者により所有される携帯電話である集荷業者端末と携帯電話ネットワークを介してさらに接続され、出荷用コードを、電子商店端末および集荷業者端末に送信するための第２のデータ送信手段をさらに備え、データ受信手段は、さらに、集荷業者端末より出荷用コードに基づいた集荷完了連絡のデータを受信し、第２のデータ送信手段は、集荷完了連絡のデータを受信した場合に、出荷用コードを配送業者端末にさらに送信する。

本発明によると、配送業者が発注者に商品を届けたときに、キャリアサーバから発注者端末に予め送られた受領用コードを配送業者端末にて取得することで、受領確認情報がキャリアサーバに送信される。これにより、キャリアサーバは、発注者が商品を実際に受領したか否かを確認することができる。このように、キャリアサーバにおいて商品の取引状態の管理を可能とすることで、小規模事業者であっても、円滑に電子商取引を行なうことができる。

また、出荷用コードとは異なるコードであって、受領処理時に発注者端末側で操作が行なわれるまで公開されない受領処理専用の受領用コードを用いることで、受領確認の安全性を高めることができる。

あるいは、出荷用コードと受領用コードとを使い分けることにより、手頃な出荷管理処理と安全性の高い受領確認処理とを両立させることができる。

あるいは、携帯端末の位置情報を利用した発送処理や、決済処理を組み入れることで、小規模事業者の電子商取引を円滑にすすめることが可能となる。

本発明の実施の形態について図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰返さない。

＜電子商取引システムの構成＞
（全体構成について）
図１は、本発明の実施の形態における電子商取引システム１の全体構成を示す図である。

図１を参照して、電子商取引システム１は、携帯電話事業者により運営されるサーバであるキャリアサーバ１０、および、キャリアサーバ１０と携帯電話ネットワーク２を介して接続される複数の携帯端末２０，３０，４０，５０を主に備える。

キャリアサーバ１０は、インターネット３を介して銀行サーバ６０と接続されている。 携帯端末２０は、電子商店の各出店者によって所有され、プリンタ２２と接続されている。各出店者は、携帯端末２０の他に、商品情報や後述する作業枠情報などの登録を行なうためのＰＣ端末２４を所有していてもよい。ＰＣ端末２４は、インターネット３を介してキャリアサーバ１０と接続される。

携帯端末３０は、各配送業者によって所有される。携帯端末３０は、他の端末に搭載された非接触型のＩＣカードより、データを読み取り可能なＩＣカードリーダ３２と接続されていてもよい。

携帯端末４０は、各発注者により所有される。
携帯端末５０は、各集荷業者により所有される。本実施の形態において、集荷業者の業務場所を「集荷ポイント」という。集荷ポイントは、配送業者の集荷場所であり、かつ、電子商店の出店者が商品を持ち込む場所を表わし、たとえばコンビニエンスストアなどが該当する。

携帯端末２０，３０，４０，５０は、それぞれ、ホームページ閲覧可能なＷＥＢ（World Wide Web）対応の携帯電話であり、かつ、２次元コードを読み取り可能な（カメラ付きの）端末である。なお、発注者により所有される携帯端末４０は、後述するように、カメラに代えて／加え、非接触型のＩＣカードを備えていてもよい。

（キャリアサーバおよび各携帯端末のハードウェア構成について）
図２は、キャリアサーバ１０のハードウェア構成を示すブロック図である。

図２を参照して、キャリアサーバ１０は、キャリアサーバ１０全体を制御するためのＣＰＵ１０１、予めプログラムやデータが格納されるＲＯＭ１０２、作業データを一時的に記録するＲＡＭ１０３、ハードディスク１０４、携帯電話ネットワーク２およびインターネット３と接続される通信Ｉ／Ｆ（インターフェイス）１０５、ユーザからの指示を受付けるための操作部１０７、表示部１０８、および、計時動作を行なうためのタイマ１０９を含む。

図３は、電子商店の携帯端末２０のハードウェア構成を示すブロック図である。
図３を参照して、携帯端末２０は、携帯端末２０全体の制御をするためのＣＰＵ２０１、予めプログラムやデータが格納されるＲＯＭ２０２、作業データを一時的に記録するＲＡＭ２０３、不揮発性のメモリたとえばフラッシュメモリ２０４、携帯電話ネットワーク２と接続される通信Ｉ／Ｆ２０５、計時動作を行なうためのタイマ２０６、ユーザからの指示を受付けるための操作部２０７、表示部２０８、カメラ２０９、および、プリンタ２２と接続するための入出力Ｉ／Ｆ２１０を含む。

図４は、配送業者の携帯端末３０のハードウェア構成を示すブロック図である。
図４を参照して、携帯端末３０は、携帯端末３０全体の制御をするためのＣＰＵ３０１、予めプログラムやデータが格納されるＲＯＭ３０２、作業データを一時的に記録するＲＡＭ３０３、ユーザからの指示を受付けるための操作部３０４、表示部３０５、不揮発性のメモリたとえばフラッシュメモリ３０６、携帯電話ネットワーク２と接続される通信Ｉ／Ｆ３０７、カメラ３０８、および、計時動作を行なうためのタイマ３０９、ＩＣカードリーダ３２と接続するための入出力Ｉ／Ｆ３１０を含む。

図５は、発注者の携帯端末４０のハードウェア構成を示すブロック図である。
図５を参照して、携帯端末４０は、携帯端末４０全体の制御をするためのＣＰＵ４０１、予めプログラムやデータが格納されるＲＯＭ４０２、作業データを一時的に記録するＲＡＭ４０３、ユーザからの指示を受付けるための操作部４０４、表示部４０５、不揮発性のメモリたとえばフラッシュメモリ４０６、携帯電話ネットワーク２と接続される通信Ｉ／Ｆ４０７、カメラ４０８、および、計時動作を行なうためのタイマ４０９を含む。

なお、携帯端末４０は、カメラ４０８に代えて／加え、非接触型のＩＣカード４１０をさらに含んでいてもよい。このような非接触型のＩＣカード４１０は、不揮発性メモリと無線通信チップが内蔵されており、読み取り端末（ＩＣカードリーダ）にかざすだけでデータのやり取りができる。

図６は、集荷ポイントの携帯端末５０のハードウェア構成を示すブロック図である。
図６を参照して、携帯端末５０は、携帯端末５０全体の制御をするためのＣＰＵ５０１、予めプログラムやデータが格納されるＲＯＭ５０２、作業データを一時的に記録するＲＡＭ５０３、ユーザからの指示を受付けるための操作部５０４、表示部５０５、不揮発性のメモリたとえばフラッシュメモリ５０６、携帯電話ネットワーク２と接続される通信Ｉ／Ｆ５０７、カメラ５０８、および、計時動作を行なうためのタイマ５０９を含む。

（キャリアサーバの機能構成について）
図７は、キャリアサーバ１０の機能ブロック図である。

図７を参照して、ＣＰＵ１０１は、発注者からの商品の受注処理を行なう受注処理部１１、電子商店の出店者の商品発送の管理処理を行なう発送処理部１２、集荷ポイントでの商品集荷の管理処理を行なう第１集荷処理部１３、配送業者による商品集荷の管理処理を行なう第２集荷処理部１４、発注者の商品受領（配送業者から発注者への商品引渡し）の管理処理を行なう受領処理部１５、発注者からの返品依頼の受付を行なう返品処理部１６、電子商店の出店者の返品商品受領を管理する返品受領処理部１７、および、決済処理を行なう決済処理部１８を含む。ＣＰＵ１０１に含まれる機能ブロックは、ＲＯＭ１０２に記憶されたプログラムを読み出して実行することにより、それぞれの機能を実現する。

ハードディスク１０４は、発注者管理ＤＢ（データベース）１１１、電子商店管理ＤＢ１１２、配送業者管理ＤＢ１１３、受注管理ＤＢ１１４、ＭＡＰコードＤＢ１１６、および、集荷ポイントＤＢ１１７を有する。

発注者管理ＤＢ１１１には、複数の発注者に関する情報を格納するための発注者テーブル１１１１が格納される。発注者テーブル１１１１のデータ構造の一例を図８に示す。

図８を参照して、発注者テーブル１１１１には、発注者ごとに、発注者ＩＤ、パスワード、氏名、住所区分、住所、電話番号、メールアドレス、および、口座のデータを含む発注者管理データが格納されている。なお、このような情報は、発注者により、携帯端末４０あるいは図示しないＰＣ端末などを介して予め登録されているものとする。発注者ＩＤは、登録の際に自動的に付与され、発注者に知らせられる。住所区分は、たとえばハードディスク１０４に住所区分と住所とが対応付けられた対応テーブルが記憶されており、発注者から入力される住所に基づき、ＣＰＵ１０１によって定められる。本実施の形態において、「住所区分」とは、近畿、中部、関東といった広域の地域区分をいうものとする。

電子商店管理ＤＢ１１２には、複数の電子商店の出店者に関する情報を格納するための電子商店テーブル１１２１、複数の商品の情報を格納するための商品テーブル１１２２、各電子商店の出店者の作業能力に関する情報を格納するための作業枠テーブル１１２３、および、各商品の在庫情報を格納するための在庫テーブル１１２４を含む。各テーブル１１２１〜１１２４に格納される情報は、電子商店の出店者により、携帯端末２０あるいはＰＣ端末２４などを介して予め登録されているものとする。

図９は、電子商店テーブル１１２１のデータ構造の一例を示す図である。図９を参照して、電子商店テーブル１１２１には、電子商店の出店者ごとに、商店ＩＤ、パスワード、電子商店名（出店者名）、住所区分、住所、電話番号、メールアドレス、および、口座のデータを含む電子商店管理データが格納されている。商店ＩＤは、登録の際に自動的に付与され、電子商店の出店者に知らせられてよい。

図１０は、商品テーブル１１２２のデータ構造の一例を示す図である。図１０を参照して、商品テーブル１１２２には、商品ごとに、商店ＩＤ、商品ＩＤ、単価（円）、輸送条件、重量（ｋｇ）、梱包単位、および、梱包サイズのデータを含む商品管理データが格納されている。商品ＩＤは、登録の際に自動的に付与され、電子商店の出店者に知らせられてよい。「輸送条件」とは、商品配送の際に注意すべき事柄を表わす情報であり、たとえば、要冷蔵の場合‘１’が格納され、ワレモノの場合‘２’が格納される。「梱包単位」とは、１つの箱に梱包可能な商品の数を表わす。「梱包サイズ」とは、商品を梱包する箱（以下「梱包箱」という）のサイズを表わし、後述する梱包テーブル１１３３に記憶されている梱包サイズのいずれかが格納される。

図１１は、作業枠テーブル１１２３のデータ構造の一例を示す図である。図１１を参照して、作業枠テーブル１１２３には、商店ごとに、商店ＩＤ、作業日、作業枠、引当済枠、および、作業枠残のデータを含む作業枠管理データが格納されている。「作業枠」とは、対応する作業日に作業可能な量を表わし、本実施の形態では、対応する作業日に（商品にかかわらず）梱包可能な箱（梱包箱）の数を示す。「引当済枠」とは、対応する作業日の作業枠のうち、受注により引当てられた作業枠（梱包箱の数）を表わし、「作業枠残」とは、対応する作業日の作業枠のうち、引当てられていない作業枠（梱包箱の数）を表わす。

図１２は、在庫テーブル１１２４のデータ構造の一例を示す図である。図１２を参照して、在庫テーブル１１２４には、期限日ごとに、商店ＩＤ、商品ＩＤ、在庫ロット番号、在庫予定数、引当済在庫、在庫残、有効期限開始日、および、有効期限終了日のデータを含む在庫管理データが格納されている。「在庫ロット番号」とは、有効期限ごとに設けられた番号であり、登録の際に、ＣＰＵ１０１により自動的に付与されてよい。「在庫予定数」とは、在庫として存在する予定の商品の数を表わす。「引当済在庫」とは、在庫予定数のうち、受注により引当てられた在庫数（商品の数）を表わし、「在庫残」とは、在庫予定数のうち、引当てられていない在庫数（商品の数）を表わす。

配送業者管理ＤＢ１１３には、１以上の配送業者に関する情報を格納するための配送業者テーブル１１３１、配送費に関する情報を格納するための配送テーブル１１３２、および、梱包箱に関する情報を格納するための梱包テーブル１１３３が含まれる。各テーブル１１３１〜１１３３に格納される情報は、配送業者により、携帯端末３０あるいは図示しないＰＣ端末などを介して予め登録されているものとする。

図１３は、配送業者テーブル１１３１のデータ構造の一例を示す図である。図１３を参照して、配送業者テーブル１１３１には、配送業者ごとに、配送業者ＩＤ、パスワード、配送業者名、住所、電話番号、メールアドレス、および、口座のデータを含む配送業者管理データが格納されている。このような情報は、配送業者により、携帯端末３０あるいは図示しないＰＣ端末などを介して予め登録されているものとする。配送業者ＩＤは、登録の際に自動的に付与され、配送業者に知らせられてよい。

図１４は、配送テーブル１１３２のデータ構造の一例を示す図である。図１４を参照して、配送テーブル１１３２には、発送元の住所区分、発送先の住所区分、輸送条件、梱包サイズ、梱包重量区分、料金（円）、および、所要日数のデータを含む配送料金管理データが格納される。「梱包重量区分」とは、１箱に梱包する商品の重量の区分を表わし、たとえば、２０ｋｇ以下であれば‘１’、３０ｋｇ以下であれば‘２’が格納される。配送テーブル１１３２の情報は、所定の配送業者により、携帯端末３０あるいは図示しないＰＣ端末などを介して予め登録されていてもよい。あるいは、配送業者ごとに、配送テーブル１１３２が設けられてもよい。

図１５は、梱包テーブル１１３３のデータ構造の一例を示す図である。図１５を参照して、梱包テーブル１１３３には、梱包サイズごとに、梱包サイズおよび梱包箱重量（ｋｇ）のデータを含む重量管理データが格納されている。「梱包箱重量」とは、梱包箱１つ当りの重量（箱単体の重量）を表わす。

受注管理ＤＢ１１４には、受注情報を格納するための受注テーブル１１４１、受注された商品の取引についての進捗状況を管理するための進捗状況テーブル１１４２、および、引当てた在庫に関する情報を格納するための引当在庫テーブル１１４４が含まれる。

図１６は、受注テーブル１１４１のデータ構造の一例を示す図である。図１６を参照して、受注テーブル１１４１には、後述する梱包ＩＤごとに受注管理データが格納される。各受注管理データには、注文ＩＤ、梱包ＩＤ、数量、梱包サイズ、輸送条件、梱包当り重量（ｋｇ）、梱包重量区分、商品代金（円）、サーバ利用料（円）、配送料（円）、受注時の住所区分、配送実費（円）、後述する集荷ポイントＩＤ、集荷時の住所区分、および、出荷コードのデータが含まれる。「出荷コード」とは、商品出荷の際に必要となるデータであり、所定のタイミングでＣＰＵ１０１により作成される。

図１７は、進捗状況テーブル１１４２のデータ構造の一例を示す図である。図１７を参照して、進捗状況テーブル１１４２には、後述する注文ＩＤごとに進捗状況管理データが格納される。各進捗状況管理データには、注文ＩＤ、発注者ＩＤ、商店ＩＤ、商品ＩＤ、受注回答日時、受注確認日時、受注キャンセル日時、発送日、発送指示日時、発送確定日時、発送情報連絡日時、付近集荷ポイント連絡日時、集荷ポイント選択日時、集荷情報連絡日時、集荷ポイント集荷日時、受領コード連絡日時、配送情報連絡日時、配送業者集荷日時、配送完了日時、返品期限日、返品受付日時、返品連絡日時、返品受取日時、仮払処理日時、配送費支払日時、返金処理日時、決済処理日時、および、受領コードのデータが含まれる。「受領コード」とは、商品受領の際に必要となるデータであり、所定のタイミングで作成される。

図１８は、引当在庫テーブル１１４４のデータ構造の一例を示す図である。図１８を参照して、引当在庫テーブル１１４４には、どの梱包箱にどの引当在庫ロット番号の商品が梱包されるかを管理するための引当在庫管理データが格納される。引当在庫管理データには、梱包ＩＤ、引当在庫ロット番号、有効期限開始日、および、有効期限終了日のデータが含まれる。

ＭＡＰコードＤＢ１１６には、位置情報（基地局情報）に基づく複数の住所が、それぞれ、ＭＡＰコードと対応付けられて予め記憶されている。

集荷ポイントＤＢ１１７には、集荷ポイントに関する情報を格納するための集荷ポイントテーブル１１７１が含まれる。集荷ポイントテーブル１１７１の情報は、集荷業者により、携帯端末５０あるいは図示しないＰＣ端末などを介して予め登録されているものとする。

図１９は、集荷ポイントテーブル１１７１のデータ構造の一例を示す図である。図１９を参照して、集荷ポイントテーブル１１７１には、集荷ポイントごとに、集荷ポイントＩＤ、パスワード、集荷ポイント名（集荷業者名）、住所区分、ＭＡＰコード、住所、電話番号、メールアドレス、および、営業時間のデータを含む集荷ポイント管理データが格納されている。集荷ポイントＩＤは、登録の際に自動的に付与され、集荷業者に知らせられてよい。

＜電子商取引システムの動作＞
（動作の概要について）
図２０は、本発明の実施の形態における電子商取引システム１において実行される処理の概要を示すフローチャートである。

図２０を参照して、電子商取引システム１は、発注者からの商品の注文に応じて、受注処理（ステップＳ１）、発送処理（ステップＳ２）、第１集荷処理（ステップＳ３）、第２集荷処理（ステップＳ４）、および、受領処理（ステップＳ５）を実行する。さらに、発注者からの返品の希望があれば、返品処理（ステップＳ６）、および、返品受領処理（ステップＳ７）が実行される。これらの処理が終了すると、決済処理（ステップＳ８）が実行される。

以下に、各処理の具体的な流れについて詳細に説明する。
（受注処理について）
図２１および図２２は、受注処理を示すフローチャートである。

図２１を参照して、発注者の携帯端末４０において、発注者からの指示に基づきメインメニューの要求がされると（ステップＳ１０２）、キャリアサーバ１０の受注処理部１１は、要求のあった発注者の携帯端末４０に対し、メインメニューを送信する（ステップＳ１０４）。次に、発注者の携帯端末４０において、商品発注画面の要求がなされると（ステップＳ１０６）、キャリアサーバ１０の受注処理部１１は、要求のあった発注者の携帯端末４０に対し、商品発注画面を送信する（ステップＳ１０８）。

発注者の携帯端末４０は、キャリアサーバ１０より送信されてきた商品発注画面を表示する（ステップＳ１０９）。ここで、発注者の携帯端末４０の表示部４０５に表示される商品発注画面の一例を図３３に示す。

図３３を参照して、商品発注画面では、発注者のＩＤおよびパスワードを入力するための欄、および、発注対象の電子商店コード、商品コード、および商品の数量を入力するための欄が表示される。この図に示した例では、発注者ＩＤ“Ｂ７５０００”で識別される発注者によって、電子商店コード“Ｃ３５３３０”，商品コード“ＥＸ１５２２３３”により特定される商品が１０個注文されたことが示される。

ユーザより商品発注情報が入力されると（ステップＳ１１０）、発注者の携帯端末４０は、キャリアサーバ１０に対し、発注請求を行なう（ステップＳ１１２）。

キャリアサーバ１０の受注処理部１１は、商品発注情報を受付けると（ステップＳ１１４）、商品ＩＤごとに注文ＩＤを発生させる（ステップＳ１２０）。ステップＳ１２０において、受注処理部１１は、進捗状況テーブル１１４２に、発生された新たな注文ＩＤと対応付けて、発注者ＩＤ、電子商店ＩＤ、および商品ＩＤを格納する。このように、商品ＩＤごとに注文ＩＤを発生させるため、商品ごとの進捗状況を管理することができる。

続いて、受注処理部１１は、受付けた発注情報に基づいて、必要な梱包箱の数（梱包数）の計算を行なう（ステップＳ１２１）。ステップＳ１２１において、さらに、受注処理部１１は、梱包数の計算結果に基づき、梱包ＩＤを発生させる。梱包数の計算を行なう際、受注処理部１１は、商品テーブル１１２２を参照する。より具体的には、たとえば、電子商店コード“Ｃ３５３３０”，商品コード“ＥＸ１５２２３３”により特定される商品が１０個注文されたと仮定する。この場合、図１０の商品テーブル１１２２を参照すると、当該商品の梱包単位は「７」であるため、梱包数は、２個と計算される。そうすると、２つの梱包ＩＤが発生される。

ステップＳ１２１において、受注処理部１１は、受注テーブル１１４１に、発生した梱包ＩＤの数分の新たな受注管理データを記憶する領域を確保する。そして、梱包ＩＤごとに、ステップＳ１２０で発生された注文ＩＤと、梱包ＩＤと、商品の数量と、当該商品の梱包サイズと、輸送条件と、梱包当り重量と、梱包重量区分とを受注テーブル１１４１に記録する。なお、梱包当り重量は、商品テーブル１１２２の商品１個当りの重量と、１箱に梱包される商品の個数と、梱包テーブル１１３３の梱包箱重量とに基づいて計算される。梱包重量区分は、梱包当り重量に基づいて決定される。

次に、受注処理部１１は、作業枠テーブル１１２３を参照して、作業枠の引当を行なう（ステップＳ１２２）。たとえば、上記例によると、作業枠残が２以上である直近の作業日の引当済枠の数を２インクリメントし、作業枠残の数を２だけデクリメントする。

作業枠の引当後、受注処理部１１は、発注者テーブル１１１１、電子商店テーブル１１２１および配送テーブル１１３２を参照して、発注者への商品の到着予定日を計算する（ステップＳ１２４）。具体的には、電子商店テーブル１１２１より電子商店の出店者の住所区分（つまり、発送元の住所区分）を読み出し、発注者テーブル１１１１より発注者の住所区分（つまり、発送先の住所区分）を読み出す。読み出した発送元および発送先の住所区分と、商品の輸送条件、重量および梱包サイズとに基づいて、配送テーブル１１３２より、所要日数を読み出す。これにより、ステップＳ１２２で引当てられた作業日と、読み出した所要日数とに基づいて、到着予定日が計算される。なお、読み出された各住所区分は、受注テーブル１１４１の受注時住所区分の欄に、梱包ＩＤと対応付けられて格納される。

次に、受注処理部１１は、在庫テーブル１１２４を参照して、有効期限内の在庫の検索を行ない（ステップＳ１２６）、有効期限内の在庫があったか否かを判断する（ステップＳ１２８）。具体的には、作業日と到着予定日との双方が、有効期限開始日から有効期限終了日までの間にある在庫が存在するか否かが検索される。

有効期限内の在庫が存在すると判断された場合（ステップＳ１２８でＹＥＳ）、ステップＳ１３０に進む。一方、有効期限内の在庫が存在しないと判断された場合（ステップＳ１２８でＮＯ）、ステップＳ１３２に進む。

ステップＳ１３０において、受注処理部１１は、在庫の引当を行なう（ステップＳ１３０）。具体的には、在庫テーブル１１２４における引当済在庫の数に、受注した商品（以下「受注商品」という）の個数（たとえば２個）をインクリメントし、在庫残の数から受注商品の個数（たとえば２個）をデクリメントする。また、在庫テーブル１１２４より、該当の在庫ロット番号を読み出し、引当在庫テーブル１１４４に、梱包ＩＤ、引当在庫ロット番号、有効期限開始日、および、有効期限終了日のデータを各々関連付けて記憶する。ステップＳ１３０の処理が終わると、ステップＳ１３６に進む。

ステップＳ１３２において、受注処理部１１は、有効期限内の在庫が存在しないため、受注不能である旨の通知を発注者の携帯端末４０に電子メールにて送信する。発注者の携帯端末４０が、キャリアサーバ１０より受注不能である旨の通知を受信すると（ステップＳ１３４）、この受注処理は終了される。

ステップＳ１３６において、受注処理部１１は、梱包ＩＤごとに、商品代金およびサーバ利用料を計算する（ステップＳ１３６）。商品代金は、商品テーブル１１２２の商品単価と、受注商品の個数とにより計算される。サーバ利用料は、たとえば一律であってもよいし、所定の計算式と梱包ＩＤの数とに応じて計算されてもよい。計算された商品代金およびサーバ利用料は、受注テーブル１１４１に、梱包ＩＤと対応付けて記憶される。

続いて、受注処理部１１は、配送テーブル１１３２を参照して配送料金の仮計算を行なう（ステップＳ１３８）。具体的には、電子商店の出店者および発注者それぞれの住所区分と、梱包箱の数と、梱包箱ごとの配送料とに基づいて、配送料金が仮計算される。計算された仮の配送料金は、受注テーブル１１４１に、梱包ＩＤと対応付けて記憶される。ここで配送料金の仮計算が行なわれるのは、発送元の住所区分が変更される可能性があるからである。本実施の形態における電子商取引システム１では、たとえば電子商店の出店者が産地直送の商品を取扱っている場合など、発送元の住所区分が変更される場合にも対応することができる。

次に、図２２を参照して、受注処理部１１は、発注者の携帯端末４０に対し、電子メールにて受注内容の連絡を行なう（ステップＳ１４０）。受注内容には、たとえば、図３３で示された情報（パスワードを除く）に加えて、注文ＩＤ、商品の到着予定日、商品代金、サーバ利用料、および配送料金（仮）の情報が含まれる。

発注者の携帯端末４０は、キャリアサーバ１０より受注内容の連絡を受信する（ステップＳ１４２）。その後、発注者の携帯端末４０は、発注者からの指示に基づき、注文またはキャンセルの回答を行なう（ステップＳ１４４）。

キャリアサーバ１０の受注処理部１１は、発注者の携帯端末４０からの回答を受信すると（ステップＳ１４６）、進捗状況テーブル１１４２に、注文ＩＤと対応付けて受注回答日時を記録する。

続いて、受注処理部１１は、受信した回答の内容がキャンセルであったか否かを判断する（ステップＳ１４８）。回答の内容がキャンセルではないと判断された場合、すなわち注文する旨の回答であった場合（ステップＳ１４８においてＮＯ）、受注確認を行なう（ステップＳ１５０）。受注処理部１１は、ステップＳ１５０において、注文ＩＤと対応付けて、進捗状況テーブル１１４２の受注確認日時の欄に現在の日時を記録する。同時に、進捗状況テーブル１１４２の発送日の欄に作業日（ステップＳ１２２で引当てた作業日）を、発送指示日時の欄にたとえば作業日の前日の午前０時をそれぞれ記録する。

一方、ステップＳ１４８において、発注者からの回答の内容がキャンセルであると判断された場合（ステップＳ１４８においてＹＥＳ）、受注処理部１１は、キャンセル確認を行なう（ステップＳ１５２）。ステップＳ１５２において、受注処理部１１は、進捗状況テーブル１１４２の受注キャンセル日時の欄に、注文ＩＤと対応付けて、現在の日時を記録する。また、受注処理部１１は、上記ステップＳ１２２で行なった作業枠の引当を解除し、ステップＳ１３０で行なった在庫の引当を解除する（ステップＳ１５４）。たとえば、作業枠テーブル１１２３を参照して、作業枠の引当が２であったなら、作業日の引当済枠の数を２デクリメントし、作業枠残の数を２インクリメントする。在庫テーブル１１２４を参照して、在庫の引当が２であったなら、引当済在庫の数を２デクリメントし、在庫残の数を２インクリメントする。また、引当在庫テーブル１１４４を参照して、梱包ＩＤと対応付けて引当在庫ロット番号、有効期限開始日、有効期限終了日のデータを削除する。

以上で受注処理は終了される。
（発送処理について）
図２３〜図２５は、発送処理を示すフローチャートである。

図２３を参照して、キャリアサーバ１０の発送処理部１２は、進捗状況テーブル１１４２の検索を行なう（ステップＳ２０２）。そして、現在の日時が発送指示日時であるか否かを判断する（ステップＳ２０４）。現在の日時が発送指示日時でないと判断された場合（ステップＳ２０４においてＮＯ）、ステップＳ２０２に戻る。一方、現在の日時が発送指示日時であると判断された場合（ステップＳ２０４においてＹＥＳ）、発送処理部１２は、電子商店の携帯端末２０に、商品の発送指示を電子メールにて送信する（ステップＳ２０６）。ここで送信される電子メールには、商品ＩＤと、受注テーブル１１４１において注文ＩＤと対応付けられている梱包ＩＤ，数量と、引当在庫テーブル１１４４において梱包ＩＤと対応付けられているの引当在庫ロット番号の情報が含まれる。

電子商店の携帯端末２０は、発送指示の電子メールを受信すると（ステップＳ２０８）、キャリアサーバ１０に対し、商品発送に関する確認内容の連絡を行なう（ステップＳ２１０）。確認内容には、商品発送の可否や、発送可能な商品の個数の情報が含まれる。

キャリアサーバ１０の発送処理部１２は、確認内容の連絡を受信する（ステップＳ２１１）。

発送処理部１２は、電子商店の携帯端末２０より、所定期間の間に確認内容の連絡があったか否かを判断する（ステップＳ２１２）。連絡があったと判断された場合（ステップＳ２１２においてＮＯ）、ステップＳ２２０に進む。一方、連絡がなかった判断された場合（ステップＳ２１２においてＹＥＳ）、ステップＳ２１４に進む。

ステップＳ２１４において、キャリアサーバ１０の発送処理部１２は、上述の受注処理において行なわれた作業枠および在庫の引当を解除する。ステップＳ２１４の処理は図２２のＳ１５４の処理と同様であるので、ここでの詳細な説明は繰り返さない。

そして、発注者の携帯端末４０に対し、電子メールにて、受注がキャンセルされた旨の連絡を行なう（ステップＳ２１６）。発注者の携帯端末４０が、受注がキャンセルされた旨の連絡を受信すると（ステップＳ２１８）、この発送処理は終了される。

ステップＳ２２０において、発送処理部１２は、受信した確認内容に基づき、数量不足であるか否かを判断する。数量不足であると判断された場合（ステップＳ２２０においてＹＥＳ）、ステップＳ２２２に進む。数量不足ではないと判断された場合（ステップＳ２２０においてＮＯ）、発送処理部１２は、進捗状況テーブル１１４２の発送確定日時の欄に、注文ＩＤと対応付けて現在の日時を記録して、ステップＳ２６４に進む。

ステップＳ２２２において、キャリアサーバ１０の発送処理部１２は、確定分の梱包箱の数（梱包数）を再計算する。また、確定分について作業枠の再引当を行なう（ステップＳ２２４）。つまり、作業枠テーブル１１２３において、上述の受注処理で引当てられた作業枠のうち不要となった作業枠の分を引当済枠からデクリメントし、作業枠残にその分だけインクリメントする処理を行なう。

発送処理部１２は、さらに、確定分について、商品代金およびサーバ料の再計算を行ない（ステップＳ２２６）、仮の配送料金の再計算を行なう（ステップＳ２２８）。これらの処理に基づいて、受注テーブル１１４１の情報が書き換えられる。

次に、発送処理部１２は、不足分について新たな注文ＩＤを発生させる（ステップＳ２３０）。そして、不足分について梱包数を計算し、計算した梱包数に基づき梱包ＩＤを発生させる（ステップＳ２３２）。ステップＳ２３０およびＳ２３２の処理は、それぞれ、上述の受注処理で示した図２１のステップＳ１２０およびＳ１２１の処理と同様であるので、ここでの詳細な説明は繰返さない。

続いて、発送処理部１２は、不足分について作業枠の引当を行ない（ステップＳ２３４）、到着予定日の計算をする（ステップＳ２３６）。また、不足分について、有効期限内の在庫検索を行ない（ステップＳ２３８）、有効期限内の在庫が存在するか否かを判断する（ステップＳ２４０）。ステップＳ２３４、Ｓ２３６、Ｓ２３８およびＳ２４０の処理も、それぞれ、上述の受注処理で示した図２１のステップＳ１２２、Ｓ１２４、Ｓ１２６およびＳ１２８の処理と同様であるので、ここでの詳細な説明は繰返さない。

ステップＳ２４０において、有効期限内の在庫が存在すると判断された場合（ステップＳ２４０においてＹＥＳ）、ステップＳ２４２に進む。一方、有効期限内の在庫が存在しないと判断された場合（ステップＳ２４０においてＮＯ）、ステップＳ２４８に進む。

ステップＳ２４２において、発送処理部１２は、不足分について在庫の引当を行なう。また、不足分について、商品代金およびサーバ利用料の計算を行ない（ステップＳ２４４）、配送料金の仮計算を行なう（ステップＳ２４６）。ステップＳ２４６の処理が終わると、ステップＳ２５０に進む。なお、ステップＳ２４２、Ｓ２４４およびＳ２４６の処理も、それぞれ、上述の受注処理で示した図２１のステップＳ１３０、Ｓ１３６およびＳ１３８の処理と同様であるので、ここでの詳細な説明は繰返さない。

ステップＳ２４８において、発送処理部１２は、不足分について発生させた注文ＩＤおよび梱包ＩＤを取消し、ステップＳ２５０に進む。

ステップＳ２５０において、発送処理部１２は、発注者の携帯端末４０に対し、電子メールにて、受注していた商品についての変更内容の連絡を行なう。変更内容には、たとえば、図３３で示された情報（パスワードを除く）に加えて、注文ＩＤ、予定通り発送可能な商品の個数、不足分についての到着予定日、商品代金、サーバ利用料、および配送料金（仮）の情報が含まれる。

発注者の携帯端末４０は、キャリアサーバ１０より送信されてきた変更内容を受信する（ステップＳ２５２）。変更内容を受信すると、発注者からの指示に基づき、キャリアサーバ１０に対し、承認またはキャンセルの回答を行なう（ステップＳ２５４）。

キャリアサーバ１０の発送処理部１２は、発注者の携帯端末４０からの回答を受信する（ステップＳ２５６）。次に、受信した回答の内容がキャンセルであったか否かが判断される（ステップＳ２５８）。回答の内容がキャンセルであると判断された場合（ステップＳ２５８においてＹＥＳ）、ステップＳ２６０に進む。一方、回答の内容がキャンセルではないと判断された場合（ステップＳ２５８においてＮＯ）、ステップＳ２６２に進む。

ステップＳ２６０において、発送処理部１２は、確定分および不足分の作業枠および在庫の引当を解除し、ステップＳ２１６に戻る。ステップＳ２６０の処理は、図２２のＳ１５４の処理と同様であるので、ここでの詳細な説明は繰り返さない。

ステップＳ２６２において、発送処理部１２は、受注確認を行なう。ステップＳ２６２において、不足分についての注文ＩＤと対応付けて、進捗状況テーブル１１４２の受注確認日時の欄に現在の日時を記録する。同時に、進捗状況テーブル１１４２の発送日の欄に作業日を、発送指示日時の欄にたとえば作業日の前日の午前０時をそれぞれ記録する。

ステップＳ２６２の処理が終わると、発送処理部１２は、進捗状況テーブル１１４２の発送確定日時の欄に、注文ＩＤと対応付けて現在の日時を記録して、ステップＳ２６４に進む。

ステップＳ２６４において、キャリアサーバ１０の発送処理部１２は、梱包ＩＤごとに、出荷コードを作成する。出荷コードは、ランダムに作成されてよい。作成した出荷コードは、受注テーブル１１４１に、梱包ＩＤと対応付けて記憶される。

発送処理部１２は、出荷コードを含む発送情報を生成し、電子メールにて、電子商店の携帯端末２０宛に、生成した発送情報の連絡を行なう（ステップＳ２６６）。発送情報には、出荷コードの他、梱包ＩＤ、数量、梱包サイズ、輸送条件の情報が含まれ、さらに、進捗状況テーブル１１４２において注文ＩＤと対応付けられている商品ＩＤ，発注者ＩＤ、引当在庫テーブル１１４４において梱包ＩＤと対応付けられている引当在庫ロット番号、および、発注者テーブル１１１１において発注者ＩＤと対応付けられている氏名，住所，電話番号の情報が含まれる。発送処理部１２は、進捗状況テーブル１１４２の発送情報連絡日時の欄に、注文ＩＤと対応付けて現在の日時を格納する。

電子商店の携帯端末２０は、発送情報を受信する（ステップＳ２６８）。電子商店の携帯端末２０のＣＰＵ２０１は、受信した出荷コードをたとえばフラッシュメモリ２０４に記録しておく。

次に、電子商店の携帯端末２０は、キャリアサーバ１０に対し、電子商店の出店者（の携帯端末２０）の現在の位置を示す位置情報（基地局情報）の連絡を行なう（ステップＳ２７０）。

発送処理部１２は、位置情報の連絡を受信すると（ステップＳ２７２）、ＭＡＰコードＤＢ１１６を参照して、位置情報をＭＡＰコードに変換する（ステップＳ２７４）。

発送処理部１２は、集荷ポイントテーブル１１７１を参照して、ＭＡＰコード周辺の集荷ポイントの検索・抽出を行なう（ステップＳ２７６）。発送処理部１２は、抽出した集荷ポイントの情報を、電子メールにて電子商店の携帯端末２０に送信する（ステップＳ２７８）。集荷ポイントの情報を送信すると、発送処理部１２は、進捗状況テーブル１１４２の付近集荷ポイント連絡日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

電子商店の携帯端末２０は、集荷ポイント情報を受信すると（ステップＳ２８０）、表示部２０８に、受信した集荷ポイント情報を表示する（ステップＳ２８１）。そして、ユーザ（電子商店の出店者）より、集荷ポイントを選択する指示が入力されると（ステップＳ２８２）、選択された集荷ポイントの情報をキャリアサーバ１０に送信する（ステップＳ２８３）。

キャリアサーバ１０の発送処理部１２は、選択された集荷ポイントの情報を受信すると（ステップＳ２８４）、受注テーブル１１４１の集荷ポイントの欄に、梱包ＩＤと対応付けて、選択された集荷ポイントのＩＤを格納し、進捗状況テーブル１１４２の集荷ポイント選択日時の欄に現在の日時を記録する。また、受注テーブル１１４１の集荷時住所区分の欄に、選択された集荷ポイントの住所区分（発送元の住所区分）と発注者の住所区分（発送先の住所区分）とを格納する。

次に、発送処理部１２は、集荷ポイントの住所区分に基づき、到着予定日の計算を行なう（ステップＳ２８６）。ステップＳ２８６の処理は、図２１のＳ１２４の処理と同様であるので、ここでの詳細な説明は繰り返さない。ここで再度到着予定日の計算を行なうのは、電子商店の出店者が電子商店テーブル１１２１に記憶された住所区分とは異なる住所区分の場所から、商品を発送する可能性があるからである。

次に、発送処理部１２は、引当在庫テーブル１１４４を参照して、計算された到着予定日が、受注商品の在庫期限をオーバーしているか否かを判断する（ステップＳ２８８）。在庫期限をオーバーしていると判断された場合（ステップＳ２８８においてＹＥＳ）、ステップＳ２８９に進む。一方、在庫期限をオーバーしていないと判断された場合（ステップＳ２８８においてＮＯ）、ステップＳ２９２に進む。

ステップＳ２８９において、発送処理部１２は、受注処理（および発注処理）で行なった在庫引当の解除を行なう（ステップＳ２８９）。ステップＳ２８９の処理は、図２２のＳ１５４の処理と同様であるので、ここでの詳細な説明は繰り返さない。その後、電子商店の携帯端末２０に対し、電子メールにて、在庫期限をオーバーしている旨の連絡を行なう（ステップＳ２９０）。また、図２３のステップＳ２１６に戻り、発注者の携帯端末４０に対し、電子メールにて受注がキャンセルされた旨の連絡を行う。

発注者の携帯端末４０が、受注をキャンセルされた旨の連絡を受信し（ステップＳ２１８）、電子商店の携帯端末２０が、在庫期限をオーバーしている旨の連絡を受信すると（ステップＳ２９１）、この発送処理は終了される。

ステップＳ２９２において、発送処理部１２は、出荷コードを含む集荷情報を生成し、電子メールにて、集荷ポイントの携帯端末５０宛に、生成した集荷情報の連絡を行なう。集荷情報には、出荷コードの他、受注テーブル１１４１において出荷コードと対応付けられている梱包サイズ，輸送条件，梱包当り重量、進捗状況テーブル１１４２において注文ＩＤと対応付けられている商店ＩＤ、電子商店テーブル１１２１において商店ＩＤと対応付けられている商店名，電話番号の情報が含まれてよい。集荷情報の連絡を行なうと、発送処理部１２は、進捗状況テーブル１１４２の集荷情報連絡日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

集荷ポイントの携帯端末５０は、集荷情報を受信する（ステップＳ２９６）。集荷ポイントの携帯端末５０のＣＰＵ５０１は、受信した出荷コードをたとえばフラッシュメモリ５０６に記録しておく。

続いて、発送処理部１２は、電子商店の携帯端末２０に対し、電子メールにて、選択した集荷ポイントへの商品の持込を指示する（ステップＳ２９３）。電子商店の携帯端末２０は、集荷ポイントへの持込指示を受信する（ステップＳ２９４）。

以上で発送処理は終了される。
このように、本実施の形態では、受注商品の数全てが揃わなくても、確定分について商品の発送が可能とされる。さらに、不足分については、自動的に新たな受注処理が実行されるため、電子商店の出店者は、円滑に商取引を行なうことができる。また、これにより、発注者による再度の注文の手間を省くことができる。

（第１集荷処理について）
図２６および図２７は、第１集荷処理を示すフローチャートである。

図２６を参照して、ユーザ（電子商店の出店者）が所定の操作を行なうと、電子商店の携帯端末２０は、フラッシュメモリ２０４に記憶しておいた出荷コードを読み出し、読み出した出荷コードを２次元コード（出荷用２次元コード）に変換する（ステップＳ３０１）。そして、ユーザ（電子商店の出店者）から、出荷ラベルの印刷指示が入力されると（ステップＳ３０２）、電子商店の携帯端末２０は、ラベルの印刷指示をプリンタ２２に対して行なう（ステップＳ３０４）。印刷されたラベルは、電子商店の出店者によって梱包箱に貼り付けられるものとする。なお、本実施の形態では、印刷されたラベルが梱包箱に貼り付けられるものとして説明するが、梱包箱に限定されず、梱包用材であればよい。「梱包用材」とは、商品の包みを表わし、商品が包装された袋などであってもよい。

電子商店の出店者によって集荷ポイントに商品（梱包箱）が持込まれると、集荷ポイントの携帯端末５０は、集荷業者からの指示に基づき、キャリアサーバ１０に対し、メインメニューの要求を行なう（ステップＳ３０６）。キャリアサーバ１０の第１集荷処理部１３は、要求のあった集荷ポイントの携帯端末５０に対し、メインメニューの送信を行なう（ステップＳ３０８）。

集荷ポイントの携帯端末５０は、続いて、ユーザ（集荷業者）からの指示に基づき、キャリアサーバ１０に対し、集荷連絡画面の要求を行なう（ステップＳ３１０）。キャリアサーバ１０は、要求のあった集荷ポイントの携帯端末５０に対し、集荷連絡画面の送信を行なう（ステップＳ３１２）。

集荷ポイントの携帯端末５０は、集荷連絡画面を表示部５０５に表示し、ユーザ（集荷業者）から、撮影の指示が入力されたか否かを判断する（ステップＳ３１４）。表示部５０５に表示される集荷連絡画面の一例を、図３４に示す。図３４を参照すると、表示部５０５には、たとえば「受け取った商品に貼付けられたラベル（出荷用２次元コード）を撮影して下さい。」というメッセージが表示される。

集荷ポイントの携帯端末５０のＣＰＵ５０１は、ユーザより撮影の指示が入力されるまで待機する（ステップＳ３１４においてＮＯ）。ユーザから、撮影指示が入力されると（ステップＳ３１４においてＹＥＳ）、カメラ５０８により集荷商品の梱包箱に貼付けられたラベル上の二次元化された出荷コード（出荷用２次元コード）が撮影される（ステップＳ３１６）。集荷ポイントの携帯端末５０のＣＰＵ５０１は、撮影された出荷用２次元コードを読み込み、出荷用２次元コードを出荷コードに変換する処理を行なう。

次に、集荷ポイントの携帯端末５０のＣＰＵ５０１は、フラッシュメモリ５０６に記憶されている出荷コードと、撮影された出荷用２次元コードに基づく出荷コードとが一致しているか否かを判断する（ステップＳ３１８）。出荷コードが一致していると判断された場合（ステップＳ３１８においてＹＥＳ）、ステップＳ３２０に進む。一方、出荷コードが一致していないと判断された場合（ステップＳ３１８においてＮＯ）、ステップＳ３１４に戻る。

ステップＳ３２０において、集荷ポイントの携帯端末５０は、１次集荷完了連絡のデータを生成し、キャリアサーバ１０に対し、１次集荷が完了した旨の連絡を行なう。

キャリアサーバ１０の第１集荷処理部１３は、１次集荷の完了連絡を受信すると（ステップＳ３２２）、進捗状況テーブル１１４２の集荷ポイント集荷日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

次に、第１集荷処理部１３は、配送料金の確定を行なう（ステップＳ３２４）。配送料金の実費は、受注テーブル１１４１に記憶された集荷時住所区分と、配送テーブル１１３２に記憶された配送料金管理データとに基づいて計算される。確定した配送料金は、受注テーブル１１４１の配送実費の欄に、梱包ＩＤと対応付けて格納される。

続いて、第１集荷処理部１３は、注文ＩＤ単位で受領コードを作成する（ステップＳ３２６）。受領コードは、ランダムに作成されてよい。作成した受領コードは、進捗状況テーブル１１４２に、注文ＩＤと対応付けて記憶される。

第１集荷処理部１３は、受領コードを含む受領情報を生成し、電子メールにて、発注者の携帯端末４０宛に、生成した受領情報の連絡を行なう（ステップＳ３２８）。受領情報の連絡を行なうと、第１集荷処理部１３は、進捗状況テーブル１１４２の受領コード連絡日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。さらに、第１集荷処理部１３は、出荷コードおよび受領コードを含む配送情報を生成し、電子メールにて、配送業者の携帯端末３０宛に、生成した配送情報の連絡を行なう（ステップＳ３３２）。配送情報の連絡を行なうと、第１集荷処理部１３は、進捗状況テーブル１１４２の配送情報連絡日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。配送情報には、出荷コードおよび受領コードのほか、たとえば、受注テーブル１１４１において出荷コードと対応付けられている梱包サイズ，輸送条件，梱包当り重量，集荷ポイント（ＩＤ）、集荷ポイントテーブル１１７１において集荷ポイント（ＩＤ）と対応付けられている集荷ポイント名，住所，電話番号，営業時間、進捗状況テーブル１１４２において注文ＩＤと対応付けられている発注者ＩＤ、および、発注者テーブル１１１１において発注者ＩＤと対応付けられている氏名，住所，電話番号の情報が含まれる。

発注者の携帯端末４０は、キャリアサーバ１０より受領情報を受信すると（ステップＳ３３０）、受信した受領コードをたとえばフラッシュメモリ４０６に格納する。また、配送業者の携帯端末３０は、配送情報を受信すると（ステップＳ３３４）、受信した出荷コードおよび受領コードをたとえばフラッシュメモリ３０６に格納する。

以上で、第１集荷処理は終了される。
このように、集荷業者は、自分の携帯端末５０のカメラ５０８で梱包箱に貼り付けられた出荷ラベルを撮影するだけで、キャリアサーバ１０への集荷完了の連絡を行なうことができる。これにより、集荷業者に商品が持ち込まれたか否かを容易に管理することができる。

なお、本実施の形態では、集荷業者の携帯端末５０において、出荷コードの一致／不一致を判断し、一致した場合に、キャリアサーバ１０に集荷完了の連絡を行なうこととした。これにより、キャリアサーバ１０への通信のデータ量を少なくすることができ、通信時間を短縮化することができる。しかしながら、このような方法に限定されるものではなく、たとえば、集荷業者の携帯端末５０は、撮影した出荷用２次元コードの画像データを、集荷確認情報（集荷業者が商品を集荷したことを示すための情報）としてキャリアサーバ１０に送信し、キャリアサーバ１０内において、出荷コードの一致／不一致を判断してもよい。

（第２集荷処理について）
図２８は、第２集荷処理を示すフローチャートである。

配送業者は、キャリアサーバ１０より配送情報の連絡を受けると（図２７のステップＳ３３４）、商品（梱包箱）が持ち込まれた集荷ポイントへ商品を取りに行く。配送業者が当該集荷ポイントへ到着すると、配送業者の携帯端末３０は、所定の操作が行なわれることで、キャリアサーバ１０に対しメインメニューの要求を行なう（ステップＳ４０２）。キャリアサーバ１０の第２集荷処理部１４は、要求のあった配送業者の携帯端末３０に対し、メインメニューの送信を行なう（ステップＳ４０４）。

次に、配送業者の携帯端末３０は、キャリアサーバ１０に対し、集荷連絡画面の要求を行なう（ステップＳ４０６）。キャリアサーバ１０の第２集荷処理部１４は、要求のあった配送業者の携帯端末３０に対し、集荷連絡画面の送信を行なう（ステップＳ４０８）。

配送業者の携帯端末３０は、集荷連絡画面を表示部３０５に表示し、ユーザ（配送業者）から、撮影の指示が入力されたか否かを判断する（ステップＳ４１０）。表示部３０５に表示される集荷連絡画面は、第１集荷処理で示した図３４と同様であってよい。

配送業者の携帯端末３０のＣＰＵ３０１は、ユーザより撮影の指示が入力されるまで待機する（ステップＳ４１０においてＮＯ）。ユーザより撮影の指示が入力されると（ステップＳ４１０においてＹＥＳ）、カメラ３０８によって集荷商品の梱包箱に貼付けられたラベル上の、二次元化された出荷コード（出荷用２次元コード）が撮影される（ステップＳ４１２）。配送業者の携帯端末３０のＣＰＵ３０１は、撮影された出荷用２次元コードを読み込み、出荷用２次元コードを出荷コードに変換する処理を行なう。

次に配送業者の携帯端末３０のＣＰＵ３０１は、フラッシュメモリ３０６に記憶された出荷コードと、撮影された出荷用２次元コードに基づく出荷コードとが一致しているか否かを判断する（ステップＳ４１４）。出荷コードが一致していると判断された場合（ステップＳ４１４においてＹＥＳ）、ステップＳ４１６に進む。一方、出荷コードが一致していないと判断された場合（ステップＳ４１４においてＮＯ）、ステップＳ４１０に戻る。

ステップＳ４１６において、配送業者の携帯端末３０は、２次集荷完了連絡のデータを生成し、２次集荷を完了した旨の連絡を行なう。

キャリアサーバ１０の第２集荷処理部１４は、２次集荷の完了連絡を受信すると（ステップＳ４１８）、進捗状況テーブル１１４２の配送業者集荷日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

以上で第２集荷処理は終了される。
このように、配送業者は、自分の携帯端末３０のカメラ３０８で梱包箱に貼り付けられた出荷ラベルを撮影するだけで、キャリアサーバ１０への集荷完了の連絡を行なうことができる。これにより、配送業者により商品が引き取られたか否かを容易に管理することができる。

なお、本実施の形態では、配送業者の携帯端末３０において、出荷コードの一致／不一致を判断し、一致した場合に、キャリアサーバ１０に集荷完了の連絡を行なうこととした。これにより、キャリアサーバ１０への通信のデータ量を少なくすることができ、通信時間を短縮化することができる。しかしながら、このような方法に限定されるものではなく、たとえば、配送業者の携帯端末３０は、撮影した出荷用２次元コードの画像データを、集荷確認情報（配送業者が商品を集荷したことを示すための情報）としてキャリアサーバ１０に送信し、キャリアサーバ１０内において、出荷コードの一致／不一致を判断してもよい。

（受領処理について）
図２９は、受領処理を示すフローチャートである。

配送業者によって、発注者に商品（梱包箱）が届けられると、配送業者が所定の操作を行なうことで、配送業者の携帯端末３０は、キャリアサーバ１０に対し、メインメニューに要求を行なう（ステップＳ５０２）。キャリアサーバ１０の受領処理部１５は、要求のあった配送業者の携帯端末３０に対し、メインメニューを送信する（ステップＳ５０４）。

次に、配送業者の携帯端末３０は、キャリアサーバ１０に対し、受領連絡画面の要求を行なう（ステップＳ５０６）。キャリアサーバ１０の受領処理部１５は、要求のあった配送業者の携帯端末３０に対し、受領連絡画面を送信する（ステップＳ５０８）。ステップＳ５０８の処理が終わると、ステップＳ５２１に進む。

一方で、配送業者によって、発注者に商品（梱包箱）が届けられると、発注者の携帯端末４０は、ユーザ（発注者）からの受領コード呼出の指示の入力を受付ける（ステップＳ５１０）。受領コード呼出の指示が入力されると、発注者の携帯端末４０のＣＰＵ４０１は、フラッシュメモリ４０６に記憶しておいた受領コードを呼出す（読み出す）（ステップＳ５１２）。

ここで、発注者の携帯端末４０が、ＩＣカード機能を有している場合（ステップＳ５１４においてＹＥＳ）、ステップＳ５１６に進む。これに対し、発注者の携帯端末４０が、ＩＣカード機能を有していない場合（ステップＳ５１４においてＮＯ）、ステップＳ５１８に進む。

このように、本実施の形態では、発注者の携帯端末４０がＩＣカード機能を有しているか否かに応じて、受領確認のための処理が異なる。

ステップＳ５１６において、発注者の携帯端末４０のＣＰＵ４０１は、読み出した受領コードをＩＣカード４１０に書込む。

一方、ステップＳ５１８においては、発注者の携帯電話４０のＣＰＵ４０１は、読み出した受領コードを２次元コード（受領用２次元コード）に変換する。その後、ＣＰＵ４０１は、変換された受領用２次元コードを表示部４０５に表示する。

上記ステップＳ５０８においてキャリアサーバ１０より受領連絡画面が送信されると、ステップＳ５２１において、配送業者の携帯端末３０は、表示部３０５に受領連絡画面を表示する。ここで、配送業者の携帯端末３０の表示部３０５に表示される受領連絡画面の一例を図３５に示す。

図３５を参照して、受領連絡画面では、たとえば、「ＩＣカードリーダで発注者の携帯端末より受領用２次元コードを読み取って下さい。または、発注者の携帯端末の画面に表示された受領用２次元コードを撮影して下さい。」というメッセージが表示される。

このように、発注者の携帯端末４０がＩＣカード機能を有しているか否かに基づき、配送業者は、ＩＣカードリーダ３２による受領用２次元コード読み取りのための操作またはカメラ３０８による受領用２次元コード撮影のための操作を行なうことになる。

受領連絡画面が表示された後、配送業者の携帯端末３０のＣＰＵ３０１は、ユーザ（配送業者）より、ＩＣカードリーダ３２による受領用２次元コード読み取りの指示が入力されたか否かを判断する（ステップＳ５２２）。ＩＣカードリーダ３２による受領用２次元コード読み取りの指示を検知すると（ステップＳ５２２においてＹＥＳ）、ステップＳ５２４に進む。一方、ＩＣカードリーダ３２による受領用２次元コード読取の指示が検知されない場合（ステップＳ５２２においてＮＯ）、ステップＳ５２６に進む。

ステップＳ５２４において、配送業者は発注者の携帯端末４０にＩＣカードリーダ３２を接触させることで、ＩＣカードリーダ３２によって発注者の携帯端末４０のＩＣカード４１０に書込まれた受領コードが読取られる。ステップＳ５２４の処理が終わると、ステップＳ５３０に進む。

ステップＳ５２６において、配送業者の携帯端末３０のＣＰＵ３０１は、ユーザより、撮影の指示が入力されたか否かを判断する（ステップＳ５２６）。撮影の指示が検知されない場合（ステップＳ５２６においてＮＯ）、ステップＳ５２２に戻る。ユーザからの撮影の指示が検知されると（ステップＳ５２６においてＹＥＳ）、カメラ３０８によって発注者の携帯端末４０の表示部４０５の画面上に表示された、２次元化された受領コード（受領用２次元コード）が撮影される（ステップＳ５２８）。配送業者の携帯端末３０のＣＰＵ３０１は、撮影された受領用２次元コードを読み込み、受領用２次元コードを受領コードに変換する処理を行なう。ステップＳ５２８の処理が終わると、ステップＳ５３０に進む。

ステップＳ５３０において、配送業者の携帯端末３０のＣＰＵ３０１は、フラッシュメモリ３０６に記憶しておいた受領コードと、読み取られた受領コードまたは撮影された受領用２次元コードに基づく受領コードとが一致しているか否かを判断する。受領コードが一致していないと判断された場合（ステップＳ５３０においてＮＯ）、ステップＳ５２２に戻る。受領コードが一致していると判断された場合（ステップＳ５３０においてＹＥＳ）、配送業者の携帯端末３０は、受領確認連絡のデータを生成し、キャリアサーバ１０に対し、受領確認（引渡し完了）の連絡を行なう（ステップＳ５３２）。

キャリアサーバ１０の受領処理部１５は、配送業者の携帯端末３０より、受領確認の連絡を受信すると（ステップＳ５３４）、進捗状況テーブル１１４２の配送完了日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。また、進捗状況テーブル１１４２の返品期限日の欄に、現在日よりたとえば所定期間後の日付を記録する。返品期限日の欄に記録される日付は、商品ごとに異なっていてよい。

このように、商品が発注者に届けられたことが確認できると、キャリアサーバ１０の受領処理部１５は、銀行サーバ６０にアクセスして、各種料金の仮払処理を行なう（ステップＳ５３６）。具体的には、受領処理部１５は、進捗状況テーブル１１４２において注文ＩＤと対応付けられている発注者ＩＤより、発注者テーブル１１１１において該発注者ＩＤと対応付けられている発注者口座を特定する。そして、その発注者口座から、請求金額（商品代金＋配送料金＋サーバ利用料）を引き落とし、引き落とした請求金額を携帯電話キャリア仮払口座に移動させる。なお、ここで発注者の口座から引き落とされる配送料金は、配送実費であってもよいし、受注時に発注者に提示した受注時の配送料金であってもよい。発注者の口座から引き落とされる配送料金が後者の場合、配送実費の方が配送料金よりも高ければ、電子商店の出店者がその差額分を負担することとしてよい。

仮払処理が終わると、受領処理部１５は、進捗状況テーブル１１４２の仮払処理日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

また、キャリアサーバ１０の受領処理部１５は、銀行サーバ６０にアクセスして、配送実費支払処理を行なう（ステップＳ５３８）。具体的には、進捗状況テーブル１１４２において注文ＩＤと対応付けられている商店ＩＤより、電子商店テーブル１１２１において該商店ＩＤと対応付けられている電子商店の出店者の口座を読み出す。そして、その電子商店の出店者の口座から配送料金（実費）とサーバ利用料とを引き落とし、配送業者の口座に配送料金を振り込み、サーバ利用料を携帯電話キャリア口座に振り込む。配送実費支払処理が終わると、受領処理部１５は、進捗状況テーブル１１４２の配送費支払処理日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

以上で受領処理は終了される。
このように、本実施の形態では、配送業者は、自分の携帯端末３０のカメラ３０８で、発注者の携帯端末４０の表示部４０５に表示された２次元コードを撮影するだけで、キャリアサーバ１０への受領確認（引渡し完了）の連絡を行なうことができる。これにより、配送業者から発注者へ商品が届けられたか否かを容易に管理することができる。さらに、受領処理時に発注者の携帯端末４０側で操作が行われるまで公開されない、２次元コードを撮影することで、受領用コードの一致／不一致が判断されるため、配送業者による不正（データの改ざん等）を防止することができる。

または、配送業者は、自分の携帯端末３０に接続されたＩＣカードリーダ３２によって、発注者の携帯端末４０のＩＣカード４１０に書き込まれた受領用コードを読み取るだけで、キャリアサーバ１０への受領確認（引渡し完了）の連絡を行なうことができる。これにより、配送業者から発注者へ商品が届けられたか否かを容易に管理することができる。さらに、ＩＣカード４１０に書き込まれた受領用コードは改ざんすることが困難またはできないため、配送業者による不正（データの改ざん等）を防止することができる。

また、キャリアサーバ１０は、受領確認の連絡を受けると所定の仮払処理を実行するため、電子商店の出店者の管理負担を軽減することができる。

なお、本実施の形態では、配送業者の携帯端末３０において、受領コードの一致／不一致を判断し、一致した場合に、キャリアサーバ１０に受領確認（引渡し完了）の連絡を行なうこととした。これにより、キャリアサーバ１０への通信のデータ量を少なくすることができ、通信時間を短縮化することができる。しかしながら、このような方法に限定されるものではなく、たとえば、配送業者の携帯端末３０は、撮影した受領用２次元コードの画像データを、受領確認情報（発注者が商品を受領したことを示すための情報）としてキャリアサーバ１０に送信し、キャリアサーバ１０内において、受領コードの一致／不一致を判断してもよい。または、配送業者の携帯端末３０は、ＩＣカードリーダ３２により読み取られた受領コードをキャリアサーバ１０に送信し、キャリアサーバ１０内において、受領コードの一致／不一致を判断してもよい。

（返品処理について）
図３０は、返品処理を示すフローチャートである。

図３０を参照して、発注者の携帯端末４０は、発注者からの指示に基づき、キャリアサーバ１０に対し、メインメニューの要求を行なう（ステップＳ６０２）。キャリアサーバ１０の返品処理部１６は、要求のあった発注者の携帯端末４０に対し、メインメニューを送信する（ステップＳ６０４）。

次に、発注者の携帯端末４０は、キャリアサーバ１０に対し、返品請求画面の要求を行なう（ステップＳ６０６）。キャリアサーバ１０の返品処理部１６は、要求のあった発注者の携帯端末４０に対し、返品請求画面の送信を行なう（ステップＳ６０８）。

発注者の携帯端末４０は、表示部４０５に返品請求画面を表示し、ユーザより返品情報の入力を受付ける（ステップＳ６１０）。ここで、表示部４０５に表示される返品請求画面の一例を図３６に示す。

図３６を参照して、返品請求画面には、発注者のＩＤおよびパスワードを入力するための入力欄が表示され、さらに、たとえば「返品対象商品のラベル（出荷用２次元コード）を撮影して下さい。」というメッセージが表示される。

次に、発注者の携帯端末４０のＣＰＵ４０１は、ユーザ（発注者）より、撮影の指示が入力されたか否かを判断する（ステップＳ６１２）。撮影の指示が入力されるまで待機する（ステップＳ６１２においてＮＯ）。ユーザより撮影の指示が入力されたと判断された場合（ステップＳ６１２においてＹＥＳ）、カメラ４０８によって返品対象商品の梱包箱に貼り付けられたラベル上の、２次元化された出荷コード（出荷用２次元コード）が撮影される（ステップＳ６１４）。発注者の携帯端末４０のＣＰＵ４０１は、撮影された出荷用２次元コードを読み込み、出荷用２次元コードを出荷コードに変換する処理を行なう。

出荷用２次元コードが撮影されると、発注者の携帯端末４０は、キャリアサーバ１０に対し、返品請求を行なう（ステップＳ６１６）。返品請求には、撮影された出荷用２次元コードに基づく出荷コード、および、返品商品の発注者を特定するための情報（発注者ＩＤ、パスワード）が含まれる。

キャリアサーバ１０の返品処理部１６は、返品請求を受付ける（ステップＳ６１８）。返品請求を受付けると、返品処理部１６は、受注テーブル１１４１を参照して、受信した出荷コードに基づき、返品請求対象の梱包ＩＤ、数量、注文ＩＤ、および、進捗状況テーブル１１４２を参照して商品ＩＤ、集荷ポイント集荷日時を特定する。その後、返品処理部１６は、進捗状況テーブル１１４２の返品受付日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

次に、返品処理部１６は、返品請求の対象の商品が、決済処理済か否かを判断する（ステップＳ６２０）。具体的には、進捗状況テーブル１１４２を参照して、返品対象の注文ＩＤに対応する決済処理日時の欄に日付が記録されているか否かを判断する。

返品請求の対象の商品が、決済処理済であると判断された場合（ステップＳ６２０においてＹＥＳ）、返品処理は終了される。

一方、決済処理済でないと判断された場合（ステップＳ６２０においてＮＯ）、返品処理部１６は、電子商店の携帯端末２０に対し、電子メールにて、出荷コードを含む返品情報を連絡する（ステップＳ６２２）。返品情報の連絡を行なうと、進捗状況テーブル１１４２の返品連絡日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。返品情報としては、出荷コードのほかに、返品商品を特定するための情報（注文ＩＤ、商品ＩＤ、数量および集荷ポイント集荷日時など）が含まれる。

電子商店の携帯端末２０は、キャリアサーバ１０より返品情報の連絡を受信すると（ステップＳ６２４）、受信した出荷コードを、たとえばフラッシュメモリ２０４に格納する。

以上で、返品処理は終了される。
このように、本実施の形態では、梱包箱に貼り付けられていた出荷用ラベルを利用して、容易に返品管理を行なうことができる。

（返品受領処理について）
図３１は、返品受領処理を示すフローチャートである。

返品商品が、（配送業者により）電子商店の出店者に届けられると、電子商店の携帯端末２０は、出店者からの指示に基づき、キャリアサーバ１０に対しメインメニューの要求を行なう（ステップＳ７０２）。キャリアサーバ１０の返品受領処理部１７は、要求のあった電子商店の携帯端末２０に対し、メインメニューを送信する（ステップＳ７０４）。

電子商店の携帯端末２０は、次に、電子商店の出店者からの指示に基づき、返品受領連絡画面の要求を行なう（ステップＳ７０６）。キャリアサーバ１０の返品受領処理部１７は、返品受領連絡画面の送信を行なう（ステップＳ７０８）。

電子商店の携帯端末２０は、返品受領連絡画面を受信すると、ユーザ（出店者）より、撮影の指示が入力されたか否かを判断する（ステップＳ７１０）。電子商店の携帯端末２０のＣＰＵ２０１は、ユーザより、撮影の指示が入力されるまで待機する（ステップＳ７１０においてＮＯ）。

ユーザより撮影の指示が入力されると（ステップＳ７１０においてＹＥＳ）、カメラ２０９によって返品商品の梱包箱に貼付けられたラベル上の、２次元化された出荷コード（出荷用２次元コード）を撮影する（ステップＳ７１２）。電子商店の携帯端末２０のＣＰＵ２０１は、撮影された出荷用２次元コードを読み込み、出荷用２次元コードを出荷コードに変換する処理を行なう。

電子商店の携帯端末２０は、フラッシュメモリ２０４に記憶しておいた出荷コードと撮影された出荷用２次元コードに基づく出荷コードとが一致しているか否かを判断する（ステップＳ７１４）。出荷コードが一致していないと判断された場合（ステップＳ７１４においてＮＯ）、ステップＳ７１０に戻る。一方、出荷コードが一致していると判断された場合（ステップＳ７１４においてＹＥＳ）、電子商店の携帯端末２０は、キャリアサーバ１０に対し、返品商品の受領完了連絡を行なう（ステップＳ７１６）。

キャリアサーバ１０の返品受領処理部１７は、返品完了の連絡を受信する（ステップＳ７１８）。そうすると、進捗状況テーブル１１４２の返品受取日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

次に、返品受領処理部１７は、発注者への返金処理を行なう（ステップＳ７２０）。つまり、返品受領処理部１７は、進捗状況テーブル１１４２において注文ＩＤと対応付けられている発注者ＩＤおよび商店ＩＤより、発注者テーブル１１１１および電子商店テーブル１１２１において該発注者ＩＤおよび該商店ＩＤと対応付けられている発注者口座および出店者口座を特定する。そして、携帯電話キャリア仮払口座にある請求金額（商品代金＋配送料金＋サーバ利用料）を発注者の口座に返金する。ただし、既にステップＳ５３８で配送実費が差し引かれているため、梱包ＩＤと対応付けて受注テーブル１１４１の配送実費を出店者口座より引き落し、発注者の口座へ返金する。また、電子商店の出店者の口座から、サーバ利用料を引き落とし、携帯電話キャリア口座に振り込む。返金の処理が終わると、返品受領処理部１７は、進捗状況テーブル１１４２の返金処理日時の欄に、注文ＩＤと対応付けて現在の日時を記録する。

以上で返品受領処理は終了される。
このように、本実施の形態では、電子商店の出店者が返品商品を受領したか否かを容易に管理することができる。また、返品商品の受領が完了すると、発注者への返金処理も自動で行なわれるため、電子商店の出店者による管理負担を大幅に軽減することができる。

なお、本実施の形態では、電子商店の携帯端末２０において、出荷コードの一致／不一致を判断し、一致した場合に、キャリアサーバ１０に返品商品の受領完了の連絡を行なうこととした。これにより、キャリアサーバ１０への通信のデータ量を少なくすることができ、通信時間を短縮化することができる。しかしながら、このような方法に限定されるものではなく、たとえば、電子商店の携帯端末２０は、撮影した出荷用２次元コードの画像データを、返品受領確認情報（電子商店の出店者が返品商品を受領したことを示すための情報）としてキャリアサーバ１０に送信し、キャリアサーバ１０内において、出荷コードの一致／不一致を判断してもよい。

ここでは、返品請求を受付けた後の返品商品の集荷管理については特に記載しなかったが、キャリアサーバ１０は、さらに、返品商品の集荷処理を行なうこととしてもよい。

（決済処理について）
図３２は、決済処理を示すフローチャートである。

図３２を参照して、キャリアサーバ１０の決済処理部１８は、進捗状況テーブル１１４２を検索する（ステップＳ８０２）。そして、現在の日時が、返品期限を過ぎたか否かを判断する（ステップＳ８０４）。現在の日時が返品期限を過ぎていないと判断された場合（ステップＳ８０４においてＮＯ）、ステップＳ８０２に戻る。一方、返品期限が過ぎたと判断された場合（ステップＳ８０４においてＹＥＳ）、ステップＳ８０５に進む。

ステップＳ８０５において、決済処理部１８は、返品受付済か否かを判断する。具体的には、進捗状況テーブル１１４２に、返品受付日時が記録されているか否かが判断される。返品受付済みと判断された場合（ステップＳ８０５においてＹＥＳ）、ステップＳ８０６に進む。一方、返品受付済みでないと判断された場合（ステップＳ８０５においてＮＯ）、この決済処理を終了する。

ステップＳ８０６において、決済処理部１８は、キャリア仮払口座にある請求金額（商品代金＋配送料金＋サーバ利用料）を、進捗状況テーブル１１４２において注文ＩＤと対応付けられている商店ＩＤより、電子商店テーブル１１２１の出店者口座を特定し、銀行サーバ６０にアクセスすることで、電子商店の出店者の口座に振込依頼する（ステップＳ８０６）。以上で決済処理は終了される。

以上説明したように、本発明の実施の形態の電子商取引システム１によると、電子商店の出店者による受注後の管理業務を軽減することができる。これにより、小規模な事業者であっても、気軽にＥコマースに参入することができる。

なお、電子商店の携帯端末２０より、キャリアサーバ１０にアクセスして、電子商店のＩＤを入力することで、進捗状況テーブル１１４２および引当在庫テーブル１１４４の内容が確認できてもよい。

また、本実施の形態における受領処理では、発注者の携帯端末４０に表示された受領用２次元コードを配送業者の携帯端末３０で撮影するか、あるいは、発注者の携帯端末４０のＩＣカード４１０と配送業者の携帯端末３０に接続されたＩＣカードリーダ３２とを接近させることにより、受領コードの送受信が行なわれた。しかしながら、セキュリティが保たれれば他の方法により受領コードの送受信が行なわれてもよい。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

本発明の実施の形態における電子商取引システムの全体構成を示す図である。 本発明の実施の形態の電子商取引システムにおけるキャリアサーバのハードウェア構成を示すブロック図である。 本発明の実施の形態の電子商取引システムにおける電子商店の携帯端末のハードウェア構成を示すブロック図である。 本発明の実施の形態の電子商取引システムにおける配送業者の携帯端末のハードウェア構成を示すブロック図である。 本発明の実施の形態の電子商取引システムにおける発注者の携帯端末のハードウェア構成を示すブロック図である。 本発明の実施の形態の電子商取引システムにおける集荷ポイントの携帯端末のハードウェア構成を示すブロック図である。 本発明の実施の形態の電子商取引システムにおけるキャリアサーバの機能ブロック図である。 発注者テーブルのデータ構造の一例を示す図である。 電子商店テーブルのデータ構造の一例を示す図である。 商品テーブルのデータ構造の一例を示す図である。 作業枠テーブルのデータ構造の一例を示す図である。 在庫テーブルのデータ構造の一例を示す図である。 配送業者テーブのデータ構造の一例を示す図である。 配送テーブルのデータ構造の一例を示す図である。 梱包テーブルのデータ構造の一例を示す図である。 受注テーブルのデータ構造の一例を示す図である。 進捗状況テーブルのデータ構造の一例を示す図である。 引当在庫テーブルのデータ構造の一例を示す図である。 集荷ポイントテーブルのデータ構造の一例を示す図である。 本発明の実施の形態における電子商取引システムにおいて実行される処理の概要を示すフローチャートである。 本発明の実施の形態における受注処理を示すフローチャートである。 本発明の実施の形態における受注処理を示すフローチャートである。 本発明の実施の形態における発送処理を示すフローチャートである。 本発明の実施の形態における発送処理を示すフローチャートである。 本発明の実施の形態における発送処理を示すフローチャートである。 本発明の実施の形態における第１集荷処理を示すフローチャートである。 本発明の実施の形態における第１集荷処理を示すフローチャートである。 本発明の実施の形態における第２集荷処理を示すフローチャートである。 本発明の実施の形態における受領処理を示すフローチャートである。 本発明の実施の形態における返品処理を示すフローチャートである。 本発明の実施の形態における返品受領処理を示すフローチャートである。 本発明の実施の形態における決済処理を示すフローチャートである。 商品発注画面の一例を示す図である。 集荷連絡画面の一例を示す図である。 受領連絡画面の一例を示す図である。 返品請求画面の一例を示す図である。

符号の説明

１ 電子商取引システム、２ 携帯電話ネットワーク、３ インターネット、１０ キャリアサーバ、１１ 受注処理部、１２ 発送処理部、１３ 第１集荷処理部、１４ 第２集荷処理部、１５ 受領処理部、１６ 返品処理部、１７ 返品受領処理部、１８ 決済処理部、２０，３０，４０，５０ 携帯端末、２２ プリンタ、２４ ＰＣ端末、３２ ＩＣカードリーダ、６０ 銀行サーバ、１０１，２０１，３０１，４０１，５０１ ＣＰＵ、１０２，２０２，３０２，４０２，５０２ ＲＯＭ、１０３，２０３，３０３，４０３，５０３ ＲＡＭ、１０４ ハードディスク、１０５，２０５，３０７，４０７，５０７ 通信Ｉ／Ｆ、１０７，２０７，３０４，４０４，５０４ 操作部、１０８，２０８，３０５，４０５，５０５ 表示部、１０９，２０６，３０９，４０９，５０９ タイマ、１１１ 発注者管理ＤＢ、１１２ 電子商店管理ＤＢ、１１３ 配送業者管理ＤＢ、１１４ 受注管理ＤＢ、１１６ ＭＡＰコードＤＢ、１１７ 集荷ポイントＤＢ、２０４，３０６，４０６，５０６ フラッシュメモリ、２０９，３０８，４０８，５０８ カメラ、２１０，３１０ 入出力Ｉ／Ｆ、４１０ ＩＣカード、１１１１ 発注者テーブル、１１２１ 電子商店テーブル、１１２２ 商品テーブル、１１２３ 作業枠テーブル、１１２４ 在庫テーブル、１１３１ 配送業者テーブル、１１３２ 配送テーブル、１１３３ 梱包テーブル、１１４１ 受注テーブル、１１４２ 進捗状況テーブル、１１４４ 引当在庫テーブル、１１７１ 集荷ポイントテーブル。

Claims (16)

1. 商品の発注者により所有される携帯電話である発注者端末と、
   配送業者により所有される携帯電話である配送業者端末と、
   前記発注者端末および前記配送業者端末と携帯電話ネットワークを介して接続されるキャリアサーバとを備え、
   前記キャリアサーバは、
   前記発注者より前記商品の受注があった場合に、注文ＩＤを発生させることによって前記商品の受注処理を行うための受注処理手段と、
   電子商店の出店者により所有される電子商店端末より、前記商品の受注時の数量全てが揃わない旨の連絡を受信した場合に、充足分について、前記商品の発送を可能とするための処理を行ない、不足分については、新たな受注処理を行なうための発送処理手段と、
   前記商品の出荷状況を管理するために梱包ごとに作成される出荷用コードを作成するための第１のコード作成手段と、
   前記出荷用コードとは異なるコードであって、前記発注者による前記商品の受領を管理するための受領用コードを、前記注文ＩＤごとに作成するための第２のコード作成手段と、
   前記受領用コードを前記発注者端末に送信するための第１のデータ送信手段とを含み、
   前記発注者端末は、
   前記キャリアサーバから、前記携帯電話ネットワークを介して前記受領用コードを受信するための第１の受信手段と、
   受信された前記受領用コードを記憶するための第１の記憶手段とを含み、
   前記配送業者端末は、
   前記発注者による操作に応じて前記発注者端末から前記受領用コードを取得するための取得手段と、
   前記取得手段により前記受領用コードが取得された場合に、前記発注者が前記商品を受領したことを確認するための受領確認情報を前記キャリアサーバに送信するための第２のデータ送信手段とを含む、電子商取引システム。
2. 前記発注者端末は、
   前記第１の記憶手段に記憶された前記受領用コードを受領用２次元コードに変換するための第１の変換手段と、
   前記受領用２次元コードを表示するための表示手段とをさらに含み、
   前記取得手段は、前記表示手段に表示された前記受領用２次元コードを撮影するための第１の撮影手段を有する、請求項１に記載の電子商取引システム。
3. 前記受領用コードは、ランダムに作成される、請求項１または２に記載の電子商取引システム。
4. 前記配送業者端末における、前記発注者が前記商品を受領したことの確認は、前記受領用コードのみを使用して行なわれる、請求項１〜３のいずれかに記載の電子商取引システム。
5. 前記第１のデータ送信手段は、さらに、前記受領用コードを前記配送業者端末に送信し、
   前記配送業者端末は、
   前記キャリアサーバから、前記携帯電話ネットワークを介して前記受領用コードを受信するための第２の受信手段と、
   受信された前記受領用コードを記憶するための第２の記憶手段と、
   前記第１の撮影手段により撮影された前記受領用２次元コードに基づく受領用コードと、前記第２の記憶手段に記憶された前記受領用コードとが一致したか否かを判断するための第１の判断手段と、
   前記第１の判断手段により一致していると判断された場合に、受領確認連絡のデータを生成するための第１の生成手段とをさらに含み、
   前記第２のデータ送信手段は、前記キャリアサーバに対し、前記受領確認情報として前記受領確認連絡のデータを送信する、請求項２に記載の電子商取引システム。
6. 電子商店の出店者により所有され、前記キャリアサーバと前記携帯電話ネットワークを介して接続される携帯電話である電子商店端末と、
   集荷業者により所有され、前記キャリアサーバと前記携帯電話ネットワークを介して接続される携帯電話である集荷業者端末とをさらに備え、
   前記第１のデータ送信手段は、さらに、前記出荷用コードを、前記電子商店端末および前記集荷業者端末に送信し、
   前記電子商店端末は、
   前記キャリアサーバから、前記携帯電話ネットワークを介して前記出荷用コードを受信するための第３の受信手段と、
   受信された前記出荷用コードを出荷用２次元コードに変換するための第２の変換手段と、
   前記出荷用２次元コードの印刷指示を出力するための印刷指示手段とを含み、
   前記集荷業者端末は、
   前記キャリアサーバから、前記携帯電話ネットワークを介して前記出荷用コードを受信するための第４の受信手段と、
   受信された前記出荷用コードを記憶するための第３の記憶手段と、
   前記出店者により前記商品の梱包用材に貼り付けられた前記出荷用２次元コードを撮影するための第２の撮影手段と、
   撮影された前記出荷用２次元コードに基づく出荷用コードと、前記第３の記憶手段に記憶された前記出荷用コードとが一致したか否かを判断するための第２の判断手段と、
   前記第２の判断手段により一致していると判断された場合に、第１の集荷完了連絡のデータを生成するための第２の生成手段と、
   前記キャリアサーバに対し、前記第１の集荷完了連絡のデータを送信するための第３のデータ送信手段とを含む、請求項５に記載の電子商取引システム。
7. 前記キャリアサーバは、前記集荷業者端末から、前記携帯電話ネットワークを介して前記第１の集荷完了連絡のデータを受信するための第５の受信手段をさらに含み、
   前記第１のデータ送信手段は、前記第１の集荷完了連絡のデータが受信された場合に、前記配送業者端末に前記受領用コードを送信する、請求項６に記載の電子商取引システム。
8. 前記キャリアサーバは、前記集荷業者端末から、前記携帯電話ネットワークを介して前記第１の集荷完了連絡のデータを受信するための第５の受信手段をさらに含み、
   前記第１のデータ送信手段は、前記第１の集荷完了連絡のデータが受信された場合に、前記発注者端末に前記受領用コードを送信する、請求項６に記載の電子商取引システム。
9. 前記第１のデータ送信手段は、さらに、前記出荷用コードを前記配送業者端末に送信し、
   前記第２の受信手段は、前記キャリアサーバから、前記携帯電話ネットワークを介して前記出荷用コードをさらに受信し、
   前記第２の記憶手段は、受信された前記出荷用コードをさらに記憶し、
   前記第１の撮影手段は、前記梱包用材に貼り付けられた前記出荷用２次元コードをさらに撮影し、
   前記配送業者端末は、撮影された前記出荷用２次元コードに基づく出荷用コードと、前記第２の記憶手段に記憶された前記出荷用コードとが一致したか否かを判断するための第３の判断手段と、
   前記第３の判断手段により一致していると判断された場合に、第２の集荷完了連絡のデータを生成するための第３の生成手段とをさらに含み、
   前記第２のデータ送信手段は、さらに、前記キャリアサーバに対し、前記第２の集荷完了連絡のデータを送信する、請求項７または８に記載の電子商取引システム。
10. 前記発注者端末は、
    返品対象の前記商品の前記梱包用材に貼り付けられた前記出荷用２次元コードを撮影するための第３の撮影手段と、
    撮影された前記出荷用２次元コードに基づく前記出荷用コードのデータを前記キャリアサーバに送信する第４のデータ送信手段とを含み、
    前記第５の受信手段は、前記発注者端末から、前記携帯電話ネットワークを介して前記出荷用コードをさらに受信し、
    前記キャリアサーバは、前記出荷用コードが受信された場合に、前記返品対象の商品の出店者の前記電子商店端末を検索するための検索手段をさらに含み、
    前記第１のデータ送信手段は、さらに、検索された前記電子商店端末に対し、前記出荷用コードを送信する、請求項９に記載の電子商取引システム。
11. 前記キャリアサーバは、前記第１のコード作成手段により作成された前記出荷用コードを、前記商品の出店者を識別するための識別情報と関連付けて記憶するための受注管理データベースをさらに含み、
    前記検索手段は、前記受注管理データベースを参照して、前記返品対象の商品の出店者の前記電子商店端末を検索する、請求項１０に記載の電子商取引システム。
12. 前記電子商店端末は、
    前記キャリアサーバより受付けた前記出荷用コードを記憶するための第４の記憶手段と、
    前記返品対象の商品の前記梱包用材に貼り付けられた前記出荷用２次元コードを撮影するための第４の撮影手段と、
    撮影された前記出荷用２次元コードに基づく出荷用コードと、前記第４の記憶手段に記憶された前記出荷用コードとが一致したか否かを判断するための第４の判断手段と、
    前記第４の判断手段により一致していると判断された場合に、返品完了連絡のデータを生成するための第４の生成手段と、
    前記キャリアサーバに対し、前記返品完了連絡のデータを送信するための第５のデータ送信手段とをさらに含む、請求項１０に記載の電子商取引システム。
13. 前記キャリアサーバは、
    前記発注者の口座情報を含む発注者管理データを記憶するための発注者管理テーブルと、
    前記配送業者端末より前記受領確認連絡を受信した場合に、前記発注者管理テーブルを参照して、前記発注者の口座より前記商品の取引に関連する商品関連代金の仮引落処理を行なうための仮引落処理手段と、
    前記電子商店端末より前記返品完了連絡を受信した場合に、前記発注者管理テーブルを参照して、前記発注者の口座に前記商品関連代金の返金処理を行なうための返金処理手段とをさらに含む、請求項１２に記載の電子商取引システム。
14. 前記キャリアサーバは、
    前記出店者の口座情報を含む電子商店管理データを記憶するための電子商店管理テーブルと、
    前記商品の返品期限を経過した場合に、前記電子商店管理テーブルを参照して、前記出店者の口座に前記商品の代金の支払処理を行なうための支払処理手段とをさらに含む、請求項１３に記載の電子商取引システム。
15. 前記取得手段は、前記第１の記憶手段に記憶された前記受領用コードを読み取るための読み取り手段を有する、請求項１に記載の電子商取引システム。
16. 前記第１のデータ送信手段は、さらに、前記受領用コードを前記配送業者端末に送信し、
    前記配送業者端末は、
    前記キャリアサーバから、前記携帯電話ネットワークを介して前記受領用コードを受信するための第２の受信手段と、
    受信された前記受領用コードを記憶するための第２の記憶手段と、
    前記読み取り手段により読み取られた前記受領用コードと、前記第２の記憶手段に記憶された前記受領用コードとが一致したか否かを判断するための判断手段と、
    前記判断手段により一致していると判断された場合に、受領確認連絡のデータを生成するための生成手段とをさらに含み、
    前記第２のデータ送信手段は、前記キャリアサーバに対し、前記受領確認情報として受領確認連絡のデータを送信する、請求項１５に記載の電子商取引システム。

Images