(57)【要約】【課題】受注者が安心して電子商取引を行うことができ、ひいては、受注者にとってもメリットがあるような電子商取引システムを提供する。【解決手段】  保険申請データを発注用端末３００から受信するデータ受信部４１０と、データ受信部４１０によって受信された保険申請データを記憶しておくＤＢ４４０と、前記保険申請データの受信に基づく日からフラグをオンし、所定時間後に当該フラグをオフする管理を行うとともに、停止命令に従って前記オフを回避するように管理するフラグ管理部４６０と、前記フラグがオンしたまま前記所定期間を経過している保険申請データを特定する判定処理部４２０とを備える。【選択図】  図１
2008065553.tif 000002
【特許請求の範囲】
【請求項１】
保険申請データを発注用端末から受信する手段と、
前記受信された保険申請データを記憶しておく手段と、
前記保険申請データの受信に基づく日からフラグをオンし、所定時間後に当該フラグをオフする管理を行うとともに、停止命令に従って前記オフを回避する手段と、
前記フラグがオンしたまま前記所定期間を経過している保険申請データを特定する手段と、を備える仲介サーバ。
【請求項２】
買掛での購入希望商品を示す情報を含む保険審査依頼データを発注用端末から受信する手段と、
前記受信した保険審査依頼データを記憶しておく手段と、
前記受信した保険審査依頼データを保険会社端末へ送信する手段と、
前記送信した保険審査依頼データに基づく買掛債権保険の加入認可が得られた場合に前記情報に従って受注用端末に発注を行う手段と、
前記発注後に前記発注用端末に係る発注者から前記商品の購入代金が所定期間内に支払われない場合に対応する買掛保険審査依頼データを特定する手段と、を備える仲介サーバ。
【請求項３】
前記所定期間を計時する手段を備える請求項１又は２記載の仲介サーバ。
【請求項４】
請求項１又は２記載の仲介サーバと、前記発注用端末と、前記受注用端末とがネットワークを介して相互に接続されている、電子商取引システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仲介サーバ及び電子商取引システムに関する。
【背景技術】
【０００２】
従来、例えば非特許文献１などに掲載されているように、複数の受注者が取り扱っている商品、サービスの購買に必要な情報を提供する技術がある。非特許文献１の場合には、発注者が、発注用端末を用いて非特許文献１に示すウェブページを閲覧し、商品の購入を希望する受注者を決定したら、その受注者に対して商品の購入代金を支払い、後日、商品を受け取るという電子商取引が行われる。
【０００３】
【非特許文献１】http://kakaku.com/
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、従来の電子商取引では、発注者が受注者に対して商品の購入代金を支払ったにもかかわらず、その受注者が倒産し、発注者が商品を受け取れず、損害を被ったという事態が生じた。
【０００５】
これでは、発注者が安心して電子商取引を行うことができないので、発注者を保護する手立てが必要である。また、発注者は、商品を代金引換で受け取るという方法をとることも可能であるが、代金引換手数料が必要であったり、商品の受け取り時に待機していなければならなかったり、受注者側も早期入金が実現しなかったりと、不都合も多い。
【０００６】
そこで、本発明は、発注者が安心して電子商取引を行うことができ、ひいては、受注者にとってもメリットがあるような電子商取引システムを提供することを課題とする。
【０００７】
また、非特許文献１に開示されている電子商取引の場合は、主として、「Business to Consumer （B to C」）と称される企業と一般消費者の取引形態が想定されているが、「Business to Business (B to B）」と称される企業間取引形態の場合には、単に、商品の販売、購入にとどまらず、売掛、買掛がなされることが実情である。
【０００８】
しかし、受注者の中には、売掛を希望する者或いはしない者、売掛ができる者或いはできない者等、種々存在する。したがって、例えば、
（１）発注者が買掛で商品購入を希望していて、
（２）当該商品を扱っている受注者が数社あるが、
（３）最も好条件の受注者が売掛をしていない、という状況下では、発注者は、
（ａ）２番以降の好条件の受注者から買掛で商品を購入する、又は
（ｂ）最も好条件の受注者から現金で商品を購入せざるを得ない。
【０００９】
このように、従来の手法では、発注者が行うことができる電子商取引は限定的であり、受注者・発注者のビジネスが制限されている。
【００１０】
そこで、本発明は、受注者・発注者の双方にとってメリットがある、電子商取引システムを提供することを課題とする。
【課題を解決するための手段】
【００１１】
上記課題を解決するために、本発明の仲介サーバは、
保険申請データを発注用端末から受信する手段と、
前記受信された保険申請データを記憶しておく手段と、
前記保険申請データの受信に基づく日からフラグをオンし、所定時間後に当該フラグをオフする管理を行うとともに、停止命令に従って前記オフを回避するように管理する手段と、
前記フラグがオンしたまま前記所定期間を経過している保険申請データを特定する手段と、を備える。
【００１２】
本発明の一例としては、図１を用いて説明すると、保険申請データを発注用端末３００から受信するデータ受信部４１０と、データ受信部４１０によって受信された保険申請データを記憶しておくＤＢ４４０と、前記保険申請データの受信に基づく日からフラグをオンし、所定時間後に当該フラグをオフする管理を行うとともに、停止命令に従って前記オフを回避するように管理するフラグ管理部４６０と、前記フラグがオンしたまま前記所定期間を経過している保険申請データを特定する判定処理部４２０と、を備える。
【００１３】
また、本発明の仲介サーバは、
買掛での購入希望商品を示す情報を含む保険審査依頼データを発注用端末から受信する手段と、
前記受信した保険審査依頼データを記憶しておく手段と、
前記受信した保険審査依頼データを保険会社端末へ送信する手段と、
前記送信した保険審査依頼データに基づく買掛債権保険の加入認可が得られた場合に前記情報に従って受注用端末に発注を行う手段と、
前記発注後に前記発注用端末に係る発注者から前記商品の購入代金が所定期間内に支払われない場合に対応する買掛保険審査依頼データを特定する手段と、を備える。
【００１４】
本発明は、一例としては、図１を用いて説明すると、買掛での購入希望商品を示す情報を含む保険審査依頼データを発注用端末３００から受信するデータ受信部４１０と、前記受信した保険審査依頼データを記憶しておくＤＢ４４０と、前記受信した保険審査依頼データを保険会社端末２００へ送信するデータ送信部４５０と、前記送信した保険審査依頼データに基づく買掛債権保険の加入認可が得られた場合に前記情報に従って受注用端末１００に発注を行う手段と、前記発注後に発注用端末に係る発注者から前記商品の購入代金が所定期間内に支払われない場合に対応する買掛保険審査依頼データを特定する判定処理部４２０とを備える。
【００１５】
さらに、本発明は、前記所定期間を計時する手段を備えてもよい。
【００１６】
本発明の電子商取引システムは、上記仲介サーバと、前記発注用端末と、前記受注用端末とがネットワークを介して相互に接続されている。
【発明の実施の形態】
【００１７】
以下、本発明の実施形態について、図面を参照して説明する。なお、各図において、同様の部分には同一符号を付している。また、発明の実施形態で「商品」の中には「役務」も含まれるものとする。
（実施形態１）        
図１は、本発明の実施形態１の仲介システムの模式的な構成を示すブロック図である。図１には、問屋業者のように商品の受注者が使用する受注用端末１００と、保険会社の社員等が使用する保険会社端末２００と、小売業者又は商品の購入を希望する個人のように商品の発注者が使用する発注用端末３００と、仲介業者の管理者等によって管理される仲介業者サーバ４００とが、インターネットなどのネットワーク５００を介して接続されている状態を示している。なお、受注用端末１００及び発注用端末３００は、実際には、ネットワーク５００上に、各々複数台接続される。
【００１８】
本実施形態では、まず、仲介業者サーバ４００の管理者等によって開設されたホームページ等を通じて受注用端末１００に係る受注者を募り、そのホームページ上に各受注者に関する情報を掲載する。この掲載情報には、そのホームページに各受注者が開設しているホームページへのリンクを貼る、又は、電話番号を掲載しておくなど、その受注者に対して直接問い合わせ等ができるようにしておく。
【００１９】
この結果、発注用端末３００に係る発注者が、仲介業者サーバ４００の管理者等によって開設されたホームページにアクセスすれば、受注者に関する情報を取得できる。各発注者は、商品を購入したいと思える受注者が見つかれば、その受注者に対して上記リンクを通じてアクセスすることも可能となる。このように、仲介業者サーバ４００は、発注用端末３００に係る発注者と受注用端末１００に係る受注者との間の電子商取引を仲介する。
【００２０】
特に、本実施形態では、以下説明する発注者保険の適用申請に対する認可がなされることを条件とするものの、発注用端末３００に係る発注者が、保険会社端末２００の保険会社で用意している発注者保険のもとで、安心して電子商取引を行える環境を提供する。
【００２１】
ここで、発注者保険とは、発注者が受注者に対して商品の購入代金を支払ったにもかかわらず、その受注者が例えば倒産することで、発注者が商品を受け取れなかった場合に発生する損失を補填する保険である。より具体的には、仲介業者サーバ４００の管理者等が発注者保険に加入し、上記事態が発生した場合に、仲介業者サーバ４００の管理者等が保険会社から前記損失を補填する保険金を取得して発注者に支払う。このために、仲介業者サーバ４００の管理者等は、保険会社に対して、予め、発注者保険の申請、加入をしておく必要がある。
【００２２】
もっとも、受注者が取り扱うすべての商品を、発注者保険の対象とする必要があるわけではない点に留意されたい。
【００２３】
仲介業者サーバ４００は、以下説明する、データ受信部４１０と、判定処理部４２０と、ＩＤ番号割当部４３０と、データベース（以下、「ＤＢ」と称する。）４４０と、データ送信部４５０と、フラグ管理部４６０と、ＤＢ管理部４７０と、タイマ４８０と、タイマ管理部４９０とを備える。なお、仲介業者サーバ４００は、以下ウェブサーバが設けられていることを前提として説明するが、既知のように、ウェブサーバ自体は、仲介業者サーバ４００とは別に設けてもよい。
【００２４】
データ受信部４１０は、受注用端末１００、保険会社端末２００、発注用端末３００から送信されるデータを受信するものである。
【００２５】
判定処理部４２０は、データ受信部４１０によってデータが受信されたか否かの判定などを行ったり、各部に対して所要の命令を行い種々の処理を実行したりするものである。
【００２６】
ＩＤ番号割当部４３０は、受注用端末１００又は保険会社端末２００からの所定のデータを受信した場合に、当該データ等に対して固有のＩＤ番号を割り当てるものである。
【００２７】
ＤＢ４４０は、受注用端末１００などから送信される種々のデータ等が格納されるものである。
【００２８】
データ送信部４５０は、受注用端末１００等に対してデータを送信するものである。
【００２９】
フラグ管理部４６０は、ＤＢ４４０内に格納されているデータに対するフラグのオン／オフなどを管理するものである。
【００３０】
ＤＢ管理部４７０は、ＤＢ４４０に対して種々のデータを格納し、ＤＢ４００に格納されているデータを読み出すものである。
【００３１】
タイマ４８０は、仲介業者サーバ４００における種々の動作を制御するためのものである。タイマ４８０は、現在の時刻の計時機能も有している。
【００３２】
タイマ管理部４９０は、タイマ４８０が示す時間に従って、図示しないタイムスイッチを管理するものである。
【００３３】
図２は、図１に示すＤＢ４４０に格納されているデータ例を示す図である。図２には、「ＩＤ番号」「受注者の名称」「発注者の名称」「商品名」「販売単価」「販売数量」「入金予定日」「出荷日」「保険用フラグ」について示している。
【００３４】
「ＩＤ番号」とは、ＩＤ番号割当部４３０によって割り当てられた固有のＩＤ番号である。ここでは、「０００１」等が例示されている。
【００３５】
「受注者の名称」とは、受注用端末１００に係る受注者の名称である。この名称は、受注者の会社名、代表者名、担当者名、又は個人名等、受注者が特定できるものでありさえすればよい。これに代えて、会社名等に固有の識別番号等を割り当て、その識別番号等としてもよい。ここでは、「ＡＡ」等が例示されている。
【００３６】
「発注者の名称」とは、発注用端末３００に係る発注者の名称である。この名称は、発注者の会社名、代表者名又は担当者名等、発注者が特定できるものでありさえすればよい。これに代えて、会社名等に固有の識別番号等を割り当て、その識別番号等としてもよい。ここでは、「ＢＢ」等が例示されている。
【００３７】
「商品名」とは、購入（希望）商品名である。これに代えて、当該商品の型番など商品自体を特定できるものとしてもよい。ここでは、テレビジョンの略語の「ＴＶ」等が例示されている。
【００３８】
「販売単価」は、購入（希望）商品の販売単価である。ここでは、「１００，０００」（円）等が例示されている。
【００３９】
「販売数量」は、購入（希望）商品の販売数量である。ここでは、「５００」（台）等が例示されている。
【００４０】
「入金予定日」は、発注用端末３００から送信される、商品の購入代金の入金予定日である。ここでは、２００６年６月１日を示す「２００６．０６．０１」等が例示されている。
【００４１】
「出荷日」は、受注用端末１００から送信される、商品の出荷日である。ここでは、２００６年６月５日を示す「２００６．０６．０５」等が例示されている。
【００４２】
「保険用フラグ」は、「入金予定日」の到達に基づいてオンされ、対応する発注者から商品が発送されてこない旨の連絡を受けない限り、「入金予定日」から所定期間経過（例えば２ヶ月）に基づいてオフされるものである。
【００４３】
なお、ＤＢ４４０には、上記データのほかに、受注用端末１００に係るメールアドレスなどの宛先が、ＩＤ番号等と対応付けされて記憶される。また、ＤＢ４４０には、以下説明する振込み人名も記憶される。
【００４４】
図３は、図１に示す発注用端末３００によって仲介業者サーバ４００のウェブサーバからダウンロードされるウェブページ（以下、「保険申請データ入力ページ」と称する。）である。保険申請データ入力ページは、仲介業者サーバ４００の管理者等によって作成され、ウェブサーバにアップロードされる。
【００４５】
図３には、「発注者の名称」の入力欄２１と、「受注者の名称」の入力欄２２と、「商品名」の入力欄２３と、「販売単価×販売数量」の入力欄２４と、「入金予定日」の入力欄２５と、「振込み人名」の入力欄２５ａと、「送信」ボタン２６とを示している。入力欄２１〜２５に係るデータは、図２を参照して説明したものである。
【００４６】
発注者が、入力欄２１〜２５に対して対応するデータを入力し、「送信」ボタン２６を押下すると、発注用端末３００から仲介業者サーバ４００に対してウェブメールなどを用いて、データが送信される。
【００４７】
図４は、図１に示す受注用端末１００によって仲介業者サーバ４００のウェブサーバからダウンロードされるウェブページ（以下、「出荷確認ページ」と称する。）である。出荷確認ページは、仲介業者サーバ４００の管理者等によって作成され、ウェブサーバにアップロードされる。
【００４８】
図４には、「発注者の名称」の掲載欄２７と、「受注者の名称」の掲載欄２８と、「商品名」の掲載欄２９と、「販売単価×販売数量」の掲載欄３０と、「入金予定日」の掲載欄３１と、「出荷日」の入力欄３２と、「変更」ボタン３３と、「送信」ボタン３４とを示している。掲載欄２７〜３１及び入力欄３２に係るデータは、図２を参照して説明したものである。「変更」ボタン３３は、掲載欄２７〜３１に掲載されているデータを変更するためのボタンである。
【００４９】
受注者が、実際に商品を出荷し、入力欄３２に対して出荷日データを入力し、「送信」ボタン３４を押下すると、受注用端末１００から仲介業者サーバ４００に対してウェブメールなどを用いて、データが送信される。
【００５０】
図５は、図１に示す仲介業者サーバ４００の動作を示すフローチャートである。図５に示す動作は、例えば、タイマ割り込み処理によって例えば１分乃至３０分或いは１時間毎のように定期的に又は不定期に実行してもよい。タイマ割り込み処理は、仲介業者サーバ４００が受信するデータ量に応じて適宜決定すればよい。
【００５１】
まず、仲介業者サーバ４００は、判定処理部４２０によって、データ受信部４１０を参照し、保険申請データの受信の有無を判定する（ステップＳ１１）。具体的には、図３に示した保険申請入力ページが、発注用端末３００から仲介業者サーバ４００に対して送信されると、保険申請データが受信されたと判定される。
【００５２】
ステップＳ１１の判定の結果、保険申請データが受信されていない場合には、ステップＳ１４へ移行する。一方、保険申請データが受信されていた場合には、判定処理部４２０は、ＩＤ番号割当部４３０に対して、ＩＤ番号を割り当てるように指示する。ＩＤ番号割当部４３０は、当該指示に応じて、仲介業者サーバ４００と受注用端末１００等との間でなされるデータの送受信の際などに用いるＩＤ番号を割り当てる（ステップＳ１２）。
【００５３】
具体的には、ＩＤ番号割当部４３０は、図示しないカウンタを備えていて、ＩＤ番号を割り当てるたびに、カウンタのカウンタ値を例えばカウントアップし、かつ、その際のカウンタ値をＩＤ番号として割り当てる。
【００５４】
その後、ＩＤ番号割当部４３０は、当該ＩＤ番号を判定処理部４２０に出力する。判定処理部４２０は、ＩＤ番号割当部４３０から出力されたＩＤ番号を入力すると、そのＩＤ番号と保険申請データとを一組にして、ＤＢ管理部４７０へ出力する。ＤＢ管理部４７０は、ＩＤ番号を入力すると、それをＤＢ４４０に格納する（ステップＳ１３）。
【００５５】
なお、一度ＤＢ４４０に格納された保険申請データは、受注者又は発注者が変更できるようにしている。このためには、図２に対応する情報が掲載され、かつ、変更ボタンが付されている変更ページなどをウェブサーバにアップロードしておくことが考えられる。ちなみに、この変更は、受注者等から依頼を受けて、仲介業者サーバ４００の管理者等が行ってもよい。
【００５６】
つぎに、判定処理部４２０は、タイマ４８０を参照することによって現在の日時を把握し、当該日時データをＤＢ管理部４７０に出力する。ＤＢ管理部４７０は、判定処理部４２０から出力された日時データに基づいてＤＢ４４０内を参照し、「入金予定日」に到達した保険申請データの有無について判定する（ステップＳ１４）。
【００５７】
ここで、ステップＳ１４では、「入金予定日」の到達の有無を判定対象としているが、これは例示である。判定対象は、たとえば、保険申請データから１ヶ月後、入金日など、保険申請データの基づく日とすることもできる。
【００５８】
ステップＳ１４の判定の結果、「入金予定日」に到達した保険申請データがなければ、ステップＳ１８へ移行する。一方、「入金予定日」に到達した保険申請データがあれば、ＤＢ管理部４７０は、その保険申請データに係る「ＩＤ番号」を特定し、更に、そのＩＤ番号に対応する保険申請データをＤＢ４４０から読み出して、判定処理部４２０へ出力する。判定処理部４２０は、ＤＢ管理部４７０から保険申請データを入力すると、当該保険申請データに基づいて、図４に示した出荷確認ページを作成して、当該ページにＵＲＬを割り当て、そのＵＲＬを含むメールを作成し、「受注者の名称」に対応する「宛先」に送信する（ステップＳ１５）。
【００５９】
つぎに、判定処理部４２０は、フラグ管理部４６０に対して、出荷確認ページの送信先に対応するデータのフラグをオンするように指示する。フラグ管理部４６０は、この指示に従って、上記データのフラグをオンする（ステップＳ１６）。
【００６０】
つぎに、判定処理部４２０は、タイマ管理部４９０に対して、出荷確認ページの送信に係るＩＤ番号を送信して、タイムスイッチ管理を行うように指示する。タイマ管理部４９０は、この指示に従って、ＩＤ番号に対応するタイムスイッチがタイムアウトする時刻をセットする（ステップＳ１７）。
【００６１】
なお、タイムアウトする時刻は、例えば２ヶ月後の時刻とすればよい。タイムスイッチがタイムアウトすると、その旨が、データ受信部４１０へ出力される。
【００６２】
つぎに、判定処理部４２０は、仲介業者用サーバ４００の管理者等から、タイマ停止命令がなされているか否かを判定する（ステップＳ１８）。ここで、タイマ停止命令とは、仲介業者用サーバ４００の管理者等が、タイムスイッチを停止させるために行う命令である。この命令は、典型的には、仲介業者用サーバ４００の管理者等が、商品が発送されてこない旨の連絡を、発注者から受けた場合に、仲介業者用サーバ４００に対して行うものである。命令の際には、停止を希望するタイムスイッチに係るＩＤ番号を指定するようにしておく。
【００６３】
タイマ停止命令は、データ受信部４１０によって受信される。このため、判定処理部４２０がデータ受信部４１０を参照することで、タイマ停止命令がなされているか否かを判定することが可能となる。
【００６４】
ステップＳ１８の判定の結果、タイマ停止命令がなされている場合には、判定処理部４２０は、タイマ管理部４９０に対して、指定されたＩＤ番号に係るタイムスイッチを停止する（ステップＳ２３）。なお、タイマ停止命令の後に、タイマ再開命令がなされると、タイマ停止時が解かれ、再び、タイムアウトまでの計時が始まる。
【００６５】
一方、ステップＳ１８の判定の結果、タイマ停止命令がなされていない場合には、判定処理部４２０は、出荷確認データが受信されているか否かを判定する（ステップＳ１９）。具体的には、図４に示した出荷確認ページが、受注用端末１００から仲介業者サーバ４００に対して送信されると、出荷確認データが受信されたと判定される。
【００６６】
ステップＳ１９の判定の結果、出荷確認データが受信されていない場合には、ステップＳ２１へ移行する。一方、出荷確認データが受信されている場合には、判定処理部４２０は、出荷確認データのうち「出荷日」をＤＢ管理部４７０に対して出力するとともに、「出荷日」をＤＢ４４０に格納するように指示する。この結果、ＤＢ管理部４７０によって、「出荷日」がＤＢ４４０に格納される（ステップＳ２０）。
【００６７】
つぎに、判定処理部４２０は、データ受信部４１０を参照して、タイムアウトしたタイムスイッチが存在しているか否かを判定する（ステップＳ２１）。
【００６８】
ステップＳ２１の判定の結果、タイムアウトしたタイムスイッチが存在していない場合には、ステップＳ２３へ移行する。一方、タイムアウトしたタイムスイッチが存在している場合には、当該タイムアウトに係るＩＤ番号に対応するフラグをオフする（ステップＳ２２）。
【００６９】
つぎに、判定処理部４２０は、例えば２ヶ月以上フラグオンが継続しているデータの有無について判定するために、ＤＢ管理部４７０に対して、フラグがオンされているデータの読み出し命令を行う。ＤＢ管理部４７０は、判定処理部４２０からの命令に従って、フラグがオンし続けているデータをＤＢ４４０から読み出して、判定処理部４２０へ出力する。判定処理部４２０は、ＤＢ管理部４７０から出力されたデータを入力すると、タイマ４８０が示す現在の時刻を取得して、当該データの「入金予定日」と対比して、例えば２ヶ月以上フラグオンが継続しているデータの有無を判定する（ステップＳ２４）。
【００７０】
ステップＳ２４の判定の結果、例えば２ヶ月以上フラグオンが継続しているデータがなければ、図５に示す処理を終了する。一方、例えば２ヶ月以上フラグオンが継続しているデータがあれば、判定処理部４２０は、データ送信部４５０を通じて、そのデータを保険会社端末２００へ送信する（ステップＳ２５）。
【００７１】
なお、既述のタイマ停止命令に代えて、ステップＳ２５の実行停止命令とすることも可能である。この場合には、一例として、実行停止命令を受けた場合に、実行停止フラグをオンしておき、ステップＳ２４を例えば２ヶ月以上フラグオンが継続していて、かつ、実行停止フラグがオンされているデータの有無を判定するようにしてもよい。
【００７２】
以上説明したように、本実施形態によると、タイマ停止命令が出され、その後、タイマ再開命令が出されない限り、その命令に係るデータのフラグは、例えば２ヶ月以上フラグがオンされ続けることになる。係る場合には、発注者が購入商品の代金を入金したにもかかわらず商品が届かないという事態が生じている。この場合には、発注者は、保険会社端末２００に係る保険会社から、発注者保険の適用を受けることが可能となる。したがって、発注者は、発注者保険に基づいて、受注者との間で、安心した電子商取引を実現することができる。
【００７３】
（実施形態２）
つぎに、本発明の実施形態２について説明する。本実施形態では、受注用端末１００に係る受注者が売掛不可であっても発注者が買掛を希望する場合に、発注者が保険会社端末２００に係る保険会社で用意している買掛債権保険に加入することを条件に、仲介業者サーバ４００の管理者等が発注者の希望する商品を、受注者から購入するとともに、発注者に売掛で転売するという電子商取引を行える環境を提供する。
【００７４】
ここで、買掛債権保険とは、仲介業者サーバ４００の管理者等が発注者に代わって受注者から商品を現金で購入して、発注者に転売した後に、発注者が例えば倒産することで、仲介業者サーバ４００の管理者等がその代金が回収できなかった場合に発生する損失を補填する保険である。
【００７５】
図６は、図１に示すＤＢ４４０に格納されているデータ例を示す図である。図６には、「発注者の名称」「受注者の名称」「受注者の宛先」「限度額」「取引可能額」について示している。
【００７６】
「発注者の名称」「受注者の名称」は、図２に示したものと同じである。ここでは、「ＢＢ」「ＡＡ」等が例示されている。
【００７７】
「発注者の宛先」は、発注者のメールアドレス、電話番号、ファクシミリ番号、住所などである。「発注者の宛先」は、例えば、以下説明する買掛申請データ入力ページの受信の際に、発注者から取得する。ここでは、「123@abc.com」等が例示されている。
【００７８】
「受注者の宛先」は、受注者のメールアドレス、電話番号、ファクシミリ番号、住所などである。「受注者の宛先」は、典型的には、メールアドレスとなる。ここでは、「xxx@yyy.com」等が例示されている。
【００７９】
「限度額」は、買掛保険の限度額を示している。ここでは、「１００，０００，０００」等が例示されている。
【００８０】
「取引可能額」は、発注者が買掛保険に基づいて取引可能な額である。具体的には、「限度額」から買掛中の額を差し引いた額である。ここでは、「３，０００，０００」等が例示されている。
【００８１】
図７は、図１に示す発注用端末３００によって仲介業者サーバ４００のウェブサーバからダウンロードされるウェブページ（以下、「買掛申請データ入力ページ」と称する。）である。買掛申請データ入力ページは、仲介業者サーバ４００の管理者等によって作成され、ウェブサーバにアップロードされる。
【００８２】
図７には、「受注者の名称」の入力欄４１と、「発注者の名称」の入力欄４２と、「商品名」の入力欄４３と、「販売単価×販売数量」の入力欄４４と、「締日」の入力欄４５と、「支払日」の入力欄４６と、「送信」ボタン４７とを示している。また、図２に示したデータ例に代えて又はこれと共に、入力欄４５，４６に入力されたデータを、ＤＢ４４０の格納対象としてもよい。
【００８３】
図８は、図１に示す発注用端末３００によって仲介業者サーバ４００のウェブサーバからダウンロードされるウェブページ（以下、「保険審査依頼データ入力ページ」と称する。）である。保険審査依頼データ入力ページは、仲介業者サーバ４００の管理者等によって作成され、ウェブサーバにアップロードされる。
【００８４】
図８に示すように、保険審査依頼データ入力ページは、法人名、所在地、業種等の入力欄を有する「企業概要」の入力欄４８と、取引商品、過去の取引暦、新規取引の取引経緯等の入力欄を有する「取引概要」の入力欄４９とに大別される。
【００８５】
図９は、本実施形態の仲介業者サーバ４００の動作を示すフローチャートである。図９に示す動作は、例えば、タイマ割り込み処理によって１時間毎のように定期的に或いは不定期に実行してもよい。
【００８６】
まず、仲介業者サーバ４００は、判定処理部４２０によって、データ受信部４１０を参照し、買掛申請データの受信の有無を判定する（ステップＳ３１）。具体的には、図７に示した買掛申請データ入力ページが、発注用端末３００から仲介業者サーバ４００に対して送信されると、買掛申請データが受信されたと判定される。
【００８７】
ステップＳ３１の判定の結果、買掛申請データが受信されていない場合には、ステップＳ３４へ移行する。一方、買掛申請データが受信されていた場合には、ステップＳ１２，Ｓ１３と同様に、ＩＤ番号の割り当て（ステップＳ３２）、買掛申請データの格納が実行される（ステップＳ３３）。
【００８８】
ここで、発注者がブラックリストの掲載者である場合、発注者の資本金等に対して商品の購入希望額等が大きい場合、「取引可能額」が小額の場合などには、保険業者端末２００に対して保険申請を行っても、当該申請が許可される可能性が低いので、保険申請を行わないようにすることも一法であると考えられる。
【００８９】
そこで、本実施形態では、仲介業者サーバ４００の管理者が、ＤＢ４４０に登録された買掛申請データに基づいて保険申請を行うか否かを判断できるようにし、かつ、例えば保険申請を行うことを決定した場合にのみ、図８に示す保険審査依頼データ入力ページの発注用端末３００への送信命令を行えるようにしている。なお、当該送信命令は、ＩＤ番号等を指定して行われ、かつ、データ受信部４１０で受信される。
【００９０】
ちなみに、保険申請が許可される可能性の高低に拘らず、全件に対して保険申請を行うことも可能であり、この場合には、ステップＳ３４を割愛すればよい。また、ステップＳ３１で送信するページを、図７及び図８に示す全ての入力欄を有するページとしてもよい。
【００９１】
つぎに、判定処理部４２０は、図８に示す保険審査依頼データ入力ページの送信命令がなされたか否かを判定する（ステップＳ３４）。
【００９２】
ステップＳ３４の判定の結果、図８に示す保険審査依頼データ入力ページの送信命令がなされていない場合には、ステップＳ３６へ移行する。一方、図８に示す保険審査依頼データ入力ページの送信命令がなされていた場合には、判定処理部４２０は、保険審査依頼データ入力ページのＵＲＬを含むメールを作成し、「発注者の名称」に対応する「宛先」宛に送信する（ステップＳ３５）。この結果、発注者は、保険審査依頼データ入力ページに必要事項を入力可能となる。
【００９３】
つぎに、判定処理部４２０は、データ受信部４１０を参照し、保険審査依頼データの受信の有無を判定する（ステップＳ３６）。具体的には、図８に示した保険審査依頼データ入力ページが、発注用端末３００から仲介業者サーバ４００に対して送信されると、保険審査依頼データが受信されたと判定される。
【００９４】
ステップＳ３６の判定の結果、保険審査依頼データの受信されていない場合には、ステップＳ３９へ移行する。一方、保険審査依頼データが受信されている場合には、判定処理部４２０は、保険審査依頼データをＤＢ管理部４７０に対して出力するとともに、当該データをＤＢ４４０に格納するように指示する。この結果、ＤＢ管理部４７０によって、保険審査依頼データがＤＢ４４０に格納される（ステップＳ３７）。
【００９５】
つづいて、判定処理部４２０は、保険審査依頼データを、対応するＩＤ番号とともに、データ送信部４５０に出力する。この結果、保険審査依頼データは、保険業者用端末２００へ転送される（ステップＳ３８）。したがって、保険業者は、保険審査依頼データに基づいて、保険の加入の可否を判断可能となる。
【００９６】
なお、判断結果は、以下、仲介業者サーバ４００にネットワーク５００を通じて返信されることを前提として説明する。ただし、判断結果は、仲介業者サーバ４００の管理者等に口頭、電話などを通じて返答されてもよい。係る場合には、仲介業者用サーバ４００の管理者等が仲介業者用サーバ４００に対してＩＤ番号等を指定して判断結果を入力することとし、かつ、ステップＳ３９に代えて判断結果の入力がなされているか否かを判定すればよい。
【００９７】
つぎに、判定処理部４２０は、データ受信部４１０を参照し、保険業者用端末２００からの返信の有無を判定する（ステップＳ３９）。
【００９８】
ステップＳ３６の判定の結果、保険業者用端末２００からの返信がない場合には、ステップＳ４５へ移行する。一方、保険業者用端末２００からの返信がある場合には、保険加入を認可する旨の返答であるか否かを判定する（ステップＳ４０）。
【００９９】
ステップＳ４０の判定の結果、保険加入を認可する旨の返答でない場合には、発注者に対して、保険加入不可通知を送信する（ステップＳ４４）。この結果、発注者は、買掛保険の適用を受けることなく電子商取引を行う、又は、電子商取引を行わないという判断が強いられる。
【０１００】
一方、ステップＳ４０の判定の結果、保険加入を認可する旨の返答である場合には、発注者が購入希望していた商品を受注用端末１００へ発注する（ステップＳ４１）。つづいて、ステップＳ１６と同様にフラグをオンし（ステップＳ４２）、ステップＳ１７と同様にタイムスイッチをセットする（ステップＳ４３）。
【０１０１】
ここで、ステップＳ４３においてセットするタイムアウトまでの時刻は、ステップＳ１７の場合とは異なり、一意に定まるものではない。ここでの時刻は、一例として、入力欄４６に入力された「支払日」となる点に留意されたい。
【０１０２】
つぎに、判定処理部４２０は、ステップＳ１９に相当する、商品の購入に対する入金の有無を判定する（ステップＳ４５）。この判定のための一例としては、所定の銀行口座等への入金履歴などが、仲介業者用サーバ４００の管理者等へ送られてきた場合に、当該管理者等が仲介業者用サーバ４００に、ＩＤ番号を指定して、入金金額とともに入金済みであることを入力する。この入力は、データ受信部４１０によって受信されるようにしておき、この結果、判定処理部４２０が入金の有無等を判定することが可能となる。
【０１０３】
ステップＳ４５の判定の結果、入金がなければステップＳ４８へ移行する。一方、入金があれば、ステップＳ２０と同様にＤＢ４４０を上書きする。
【０１０４】
ここで、ステップＳ４５の判定のための手法を以下のようにすることも可能である。すなわち、第一に、仲介業者サーバ４００の管理者等が、予め銀行から複数の銀行口座を取得して、各発注者に固有の銀行口座を割り当てておく。第二に、発注者とその発注者に割り当てられた銀行口座の口座番号とを対応させてＤＢ４４０に登録しておく。第三に、銀行口座に入金があると、その旨の連絡と入金金額とがメールなどで銀行から仲介業者サーバ４００に送信されてくるようにしておく。こうすると、仲介業者サーバ４００では、ステップＳ４５で、当該メールの受信を確認することが可能となる。そして、実際に当該メールの受信を確認したら、ステップＳ４６で、判定処理部４２０が口座番号と入金金額とをＤＢ４４０に登録するようにする。こうすると、人手を介さずに、ＤＢ４４０に入金等の情報が上書きされる。
【０１０５】
つぎに、判定処理部４２０は、ＤＢ４４０に格納された入金金額と、商品単価×商品数量とを比較する（ステップＳ５０）。ステップＳ５０の比較の結果、これらの差額がゼロであればステップＳ４７へ移行する。この場合、ステップＳ２２と同様にフラグをオフする（ステップＳ４７）。
【０１０６】
一方、ステップＳ５０の比較の結果、これらの差額がゼロでなければ、アラームを出力してステップＳ４８へ移行する（ステップＳ５１）。この結果、仲介業者サーバ４００は、入金金額が商品単価×商品数量よりも多い場合には、発注者に対して差額を返金することができるし、逆の場合には、差額請求をすることができる。
【０１０７】
つぎに、判定処理部４２０は、ステップＳ２１と同様に、タイムアウトしたタイムスイッチが存在しているか否かを判定する（ステップＳ４８）。
【０１０８】
ステップＳ４８の判定の結果、タイムアウトしたタイムスイッチが存在していない場合には、図９に示す処理を終了する。一方、タイムアウトしたタイムスイッチが存在している場合には、ステップＳ５１とは異なるアラームを出力する（ステップＳ４９）。なお、アラームの出力とともに又はこれに代えて、ステップＳ２４，Ｓ２５で実行する処理を行ってもよい。もっとも、実施形態１では、ステップＳ２４，Ｓ２５で実行する処理に代えて又はこれとともに、ステップＳ４９を実行してもよい。
【０１０９】
以上説明したように、本実施形態によると、買掛後に発注者が支払日までに入金をしない場合、或いは入金額が所要でないには、アラーム出力がなされることになる。係る場合には、発注者が仲介業者サーバ４００の管理者等に対して買掛によって商品を得たにもかかわらず、その購入代金を仲介業者サーバ４００の管理者等に入金していないという事態が生じている。この場合には、保険会社端末２００に係る保険会社を通じて、仲介業者サーバ４００の管理者等は、買掛債権保険の適用を受けることが可能となる。
【０１１０】
一方、売掛処理が対応できない受注者は、本システムの適用により、売掛処理に対応できないことを理由に電子商取引が敬遠されていた発注者との電子商取引が可能となる。
【０１１１】
また、上記各実施形態で説明した手法によると、仲介業者サーバ４００側で、受注用端末１００と発注用端末３００との間の取引状況、受注用端末１００に係る受注者の売り上げ等を把握することが可能となる。したがって、仲介業者サーバ４００は、受注用端末１００と発注用端末３００との間の商取引結果に応じたサービス料金を、受注用端末１００等から徴収することが可能となる。
【０１１２】
具体的には、例えば、受注用端末１００との契約から一年後に、ＤＢ４４０に記憶されているデータを、「受注者の名称」に基づいて抽出する。そして、「販売単価」「販売数量」に基づいて受注用端末１００からの翌年のサービス料金として算出して、徴収するといった処理が可能となる。
【図面の簡単な説明】
【０１１３】
【図１】本発明の実施形態１の仲介システムの模式的な構成を示すブロック図である。
【図２】図１に示すＤＢ４４０に格納されているデータ例を示す図である。
【図３】図１に示す発注用端末３００によって仲介業者サーバ４００のウェブサーバからダウンロードされる保険申請データ入力ページである。
【図４】図１に示す受注用端末１００によって仲介業者サーバ４００のウェブサーバからダウンロードされる出荷確認ページである。
【図５】図１に示す仲介業者サーバ４００の動作を示すフローチャートである。
【図６】図１に示すＤＢ４４０に格納されているデータ例を示す図である。
【図７】図１に示す受注用端末１００によって仲介業者サーバ４００のウェブサーバからダウンロードされる買掛申請データ入力ページである。
【図８】図１に示す受注用端末１００によって仲介業者サーバ４００のウェブサーバからダウンロードされる保険審査依頼データ入力ページである。
【図９】本発明の実施形態２の仲介業者サーバ４００の動作を示すフローチャートである。
【符号の説明】
【０１１４】
受注用端末１００、保険会社端末２００、発注用端末３００、仲介業者サーバ４００、データ受信部４１０、判定処理部４２０、ＩＤ番号割当部４３０、データベース（以下、「ＤＢ」称する。）４４０、データ送信部４５０、フラグ管理部４６０、ＤＢ管理部４７０、タイマ４８０、タイマ管理部４９０、ネットワーク５００
【図１】
2008065553.tif 000003
【図２】
2008065553.tif 000004
【図３】
2008065553.tif 000005
【図４】
2008065553.tif 000006
【図５】
2008065553.tif 000007
【図６】
2008065553.tif 000008
【図７】
2008065553.tif 000009
【図８】
2008065553.tif 000010
【図９】
2008065553.tif 000011