JP2009140185A - 不要品・要修理品の処理受付システム、不要品・要修理品の処理受付方法、および、不要品・要修理品の処理受付プログラム - Google Patents

Abstract

【課題】不用品・要修理品等の各種処理依頼を行う利用者に対して地域や処理に関する多様な選択肢を提示し、利用者所望の条件にマッチする処理が可能な処理業者を抽出し提示可能とする。
【解決手段】利用者端末２００から処理依頼情報を受信し処理を引き受け可能であり利用者所在地を引き受け対象地区に含む処理業者を検索する可能処理特定部１１０と、引き受け可能な処理の一覧より利用者所望の処理についての選択を受付ける入力画面データを生成し利用者端末２００に返信する処理一覧送信部１１１と、利用者所望の選択指示を利用者端末２００から受信し処理引き受け時に必要な情報を特定する必要情報特定部１１２と、必要情報の問合わせ画面のデータを生成し返信する必要情報問合わせ部１１３と、問合わせ画面を介して必要情報を受信し処理費用と日数の情報とを特定し業者一覧を生成し返信する最終結果送信部１１４とから不要品・要修理品の処理受付システム１００を構成する。
【選択図】図１

Description

本発明は、不要品・要修理品の処理受付システム、不要品・要修理品の処理受付方法、および、不要品・要修理品の処理受付プログラムに関し、特に、Webサービス技術を活用し、地域ポータルにおいて、サービス利用者の選択した条件に基づいて、複数のサービス提供業者の比較検討を行うことにより、不要品・要修理品の修理・オークション・寄付・リサイクル・廃棄についての処理受付を可能にする技術に関する。

不用品や要修理品の修理、販売、寄付、リサイクル、廃棄などの処理を行う際に、当該処理を行う処理業者と利用者とのマッチングを図るサービスとして、次のようなものがある。例えば、廃品を直ちに処分するのではなくできるだけリサイクル商品として再利用に供することのできる廃品オークションシステムを提供することを課題とした、廃棄処理すべきものとして受け付けられた廃品をリサイクル商品としてオークションにかけることにより廃品の再利用を図る廃品オークションシステムであって、オークションにかけられるリサイクル商品情報が登録されたデータベースと、通信ネットワークを介して前記データベースの内容を公開する公開手段とを備え、前記データベースには、リサイクル商品の品目ごとにオークション期間が設定されており、前記オークション期間内にオークションが成立すれば前記リサイクル商品を取引者に引渡し、前記オークション期間内にオークションが成立しなかった場合は前記リサイクル商品を処分するようにしたことを特徴とする廃品オークションシステム（特許文献１参照）が提案されている。

また、従来廃棄されていた物品を、効率よくリサイクル再使用するシステムを提供することを課題とした、少なくともシステム管理センター、物品処分希望者、物品購入希望者、リサイクル業者及び運送業者から構成されるネットワークにおいて、システム管理センターが各種データを記憶するデータベース、物品処分希望者から提供される物品に関する物品情報を受け取る手段と当該受け取った物品情報を登録、記憶する手段を有する物品登録部、該登録された物品をオークションにかける手段を有するオークション部、物品処分希望者及びリサイクル業者から提供される物品に係る物品情報を受け取る手段、該受け取った物品情報を掲載する手段を有する掲示板部、物品の運送を調整する手段を有する運送部並びに物品流通に係る費用の精算を行う手段を有する会計部を備えた物品リサイクルシステム（特許文献２参照）なども提案されている。
特開２００２−３４２６１２号公報 特開２００３−１２２８３０号公報

上述のような従来技術では、サービス利用者の希望とこれに応じた処理業者とのマッチング処理を提供できるが、単体の処理業者による条件に応じたマッチング処理であり、複数の地域や処理業者および処理内容を跨ってのマッチング処理は提供できていない。

以上のように、従来のシステムでは、一サービス提供業者によるサービス利用者の希望条件と提供処理とのマッチングを行うことはできるが、地域における様々なサービス提供業者の提供する処理間でのマッチングは実現できない。

したがって、利用者らが、複数の地域や業者および処理内容に跨ってサービスの比較検討を行う場合、各処理業者のｗｅｂサイトなどに逐一アクセスして情報を探索し、所望の条件に合致するものを特定し検討する必要があった。そのため、処理業者選出に手間と時間がかかっていた。加えて、各処理業者におけるｗｅｂサイト等で処理や見積等を依頼する場合、重複する項目について同一内容のデータ入力を利用者に強いることとなり、利用者への負担が大きい。

そこで本発明は上記課題を鑑みてなされたものであり、不用品・要修理品等の各種処理依頼を行う利用者に対して地域や処理に関する多様な選択肢を提示し、利用者所望の条件にマッチする処理が可能な処理業者を抽出し提示可能とする技術の提供を主たる目的とする。

上記課題を解決する本発明の不要品・要修理品の処理受付システムは、利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うコンピュータシステムであって、ネットワークを介して利用者端末と通信する通信装置と、処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベースを記憶した記憶装置と、利用者端末から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベースに照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリに格納する、可能処理特定処理と、前記メモリより前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末に返信する、処理一覧送信処理と、前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベースにて特定しメモリに格納する、必要情報特定処理と、前記メモリより前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末に返信する、必要情報問合わせ処理と、前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末から受信し、この必要情報を前記データベースに照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末に返信する、最終結果送信処理と、を実行する演算装置と、を備えることを特徴とする。

また、前記不要品・要修理品の処理受付システムにおいて前記必要情報問合わせ処理は、前記必要な情報が処理業者間で重複する場合に重複情報を削除して、前記必要な情報の問合わせ画面のデータを生成するものである、としてもよい。

また、前記不要品・要修理品の処理受付システムは、前記データベースにおいて、前記処理引き受け対象地区の情報は、各地区の隣接関係についても記述した情報を含み、前記可能処理特定処理は、前記検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索した結果、該当処理業者数が所定の閾値より少なければ、前記引き受け対象地区の隣接地区を引き受け対象地区とする処理業者についても検索対象とし、該当処理業者数が前記閾値を満たすまで検索対象を拡充するものである、としてもよい。

また、前記不要品・要修理品の処理依頼受付システムにおいて、前記演算装置は、前記利用者端末から、前記業者一覧中より指定された決定処理業者の情報を受信して記憶装置に格納し、該当処理業者の端末に宛てて前記利用者の前記物品に関する処理依頼と必要情報について情報を送信する、仲介処理を実行するものであるとしてもよい。

また、前記不要品・要修理品の処理依頼受付システムにおいて、前記最終結果送信処理は、前記記憶装置より前記決定処理業者の情報を読み出して、現在を含む所定時間帯における各利用者から前記決定処理業者に宛てた物品の処理希望数を算定し、この処理希望数が前記決定処理業者の処理可能量を越えるか、所定基準以上に接近しているか判定し、前記処理希望量が前記決定処理業者の処理可能量を越えるか、所定基準以上に接近している状況であれば、前記業者一覧を生成する際に、業者一覧からの該当処理業者の除外処理か、業者一覧中における所定数の順位低減を行うものである、としてもよい。

また、本発明の不要品・要修理品の処理依頼受付方法は、利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うコンピュータが、ネットワークを介して利用者端末と通信する通信装置と、処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベースを記憶した記憶装置と、演算装置とを備えて、利用者端末から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベースに照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリに格納する、可能処理特定処理と、前記メモリより前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末に返信する、処理一覧送信処理と、前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベースにて特定しメモリに格納する、必要情報特定処理と、前記メモリより前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末に返信する、必要情報問合わせ処理と、前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末から受信し、この必要情報を前記データベースに照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末に返信する、最終結果送信処理と、を実行することを特徴とする。

また、本発明の不要品・要修理品の処理受付プログラムは、利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うべく、ネットワークを介して利用者端末と通信する通信装置と、処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベースを記憶した記憶装置と、演算装置とを備えたコンピュータに、利用者端末から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベースに照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリに格納するステップと、前記メモリより前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末に返信するステップと、前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベースにて特定しメモリに格納するステップと、前記メモリより前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末に返信するステップと、前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末から受信し、この必要情報を前記データベースに照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末に返信するステップと、を実行させることを特徴とする。

なお、本実施形態において不要品・要修理品の処理受付システムを実現する技術的な基盤として、例えば、地域情報プラットフォームを想定することができる。この地域情報プラットフォームは、地方自治体のシステムを連携させるための仕組みとして提言された共通基盤技術である。地域情報プラットフォームでは、SOAPやXMLなどの技術を活用することによって、プラットフォームやデータ形式などが異なるシステム間でのシームレスな連携が可能となり、類似したデータや機能の重複を排除することができる。

また、各業務のインタフェースの標準化によって、システムを柔軟に変更・拡張できるようになるため、特定の事業者に依存しないシステム構築が可能である。このため、地域情報プラットフォームの導入が、汎用機を中心としたレガシーシステムから、サーバーとパソコンからなるオープンシステムへの移行や、ASP（アプリケーション・サービス・プロバイダー）採用の契機となって、システム関連経費の低減に貢献することも期待されている。

この地域情報プラットフォームを基盤として本実施形態における不要品・要修理品の処理受付システムを構築する場合、SOAP（Simple Object Access Protocol）、およびUDDI（Universal Description, Discovery, and Integration）の技術を採用する。SOAPは、XMLとHTTPなどをベースとした、他のコンピュータにあるデータやサービスを呼び出すためのプロトコル(通信規約)である。SOAPによる通信では、XML文書にエンベロープ(封筒)と呼ばれる付帯情報が付いたメッセージを、HTTPなどのプロトコルで交換する。サービスを利用するクライアント（例：本実施形態における不要品・要修理品の処理受付システム）と、サービスを提供するサーバ（例：処理業者の端末）の双方がSOAPの生成・解釈エンジンを持つことで、異なる環境間でのオブジェクト呼び出しを可能にしている。こうしたSOAPによって外部から利用可能な、部品化されたWebベースのアプリケーションソフトは「Webサービス」と呼ばれる。インターネット上で各社（本実施形態における処理業者）が提供しているWebサービスを集め、利用者らが検索・照会できるようにするWebサービスを「UDDI」という。

このUDDI（Universal Description, Discovery, and Integration）は、XMLを応用した、インターネット上に存在するWebサービスの検索・照会システムである。処理業者がインターネット上で提供しているWeb技術を応用したサービスに関する情報を集積し、業種や名称、機能、対象、詳細な技術仕様などで検索可能にする仕組みとなっている。Webサービスを提供する処理業者は、自社のサービスを「UDDIレジストリ」と呼ばれるリストに登録することができる。UDDIに参加するWebサービスは、前記SOAのプロトコルによる通信に対応している必要がある。必要なときに必要なサービスを探し出してサービスを利用することが容易になるため、従来のような特定の処理業者との固定的な取引を超えた取引が可能となる。

その他、本願が開示する課題、及びその解決方法は、発明の実施の形態の欄、及び図面により明らかにされる。

本発明によれば、不用品・要修理品等の各種処理依頼を行う利用者に対して地域や処理に関する多様な選択肢を提示し、利用者所望の条件にマッチする処理が可能な処理業者を抽出し提示可能となる。

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態における不要品・要修理品の処理受付システムを含むネットワーク構成図である。本実施形態の不要品・要修理品の処理受付システム１００（以下、システム１００）は、利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うコンピュータシステムであり、例えば、前記地域情報プラットフォームを基盤とした地域ポータルサイトを提供するシステムとして運営業者が管理するものであることを想定できる。前記システム１００には、ネットワーク１４０を介して、修理業者端末３１０、オークション業者端末３２０、寄付業者端末３３０、リサイクル業者端末３４０、地方自治体端末３５０が、前記地域情報プラットフォームに準拠した形態で接続されている。

また前記システム１００は、不要品・要修理品の処理受付方法を実行する機能を実現すべく書き換え可能メモリなどの記憶装置１０１に格納されたプログラム１０２をメモリ１０３に読み出し、演算装置たるＣＰＵ１０４により実行する。

また、前記システム１００は、コンピュータ装置が一般に備えている各種キーボードやボタン類などの入力インターフェイス１０５、ディスプレイなどの出力インターフェイス１０６、利用者端末２００や処理業者の端末３００などとの間のデータ授受を担う通信装置１０７などを有している。

続いて、前記システム１００が例えばプログラム１０２に基づき構成・保持する機能部につき説明を行う。なお、前記システム１００は、処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベース１２５を記憶装置１０１に記憶している。

前記システム１００は、利用者端末２００から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベース１２５に照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリ１０３に格納する、可能処理特定部１１０を備える。なお、前記データベース１２５において、前記処理引き受け対象地区の情報は、各地区の隣接関係についても記述した情報を含む場合、前記可能処理特定部１１０は、前記検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索した結果、該当処理業者数が所定の閾値より少なければ、前記引き受け対象地区の隣接地区を引き受け対象地区とする処理業者についても検索対象とし、該当処理業者数が前記閾値を満たすまで検索対象を拡充するものである、としてもよい。

また、前記システム１００は、前記メモリ１０３より前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末２００に返信する、処理一覧送信部１１１を備える。

また、前記システム１００は、前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末２００から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベース１２５にて特定しメモリ１０３に格納する、必要情報特定部１１２を備える。

また、前記システム１００は、前記メモリ１０３より前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末２００に返信する、必要情報問合わせ部１１３を備える。なお、前記必要情報問合わせ部１１３は、前記必要な情報が処理業者間で重複する場合に重複情報を削除して、前記必要な情報の問合わせ画面のデータを生成するものであるとすれば好適である。

また、前記システム１００は、前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末２００から受信し、この必要情報を前記データベース１２５に照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末２００に返信する、最終結果送信部１１４を備える。

また、前記システム１００は、前記利用者端末２００から、前記業者一覧中より指定された決定処理業者の情報を受信して記憶装置１０１に格納し、該当処理業者の端末３００に宛てて前記利用者の前記物品に関する処理依頼と必要情報について情報を送信する、仲介部１１５を備えるとしてもよい。

この場合、前記最終結果送信部１１４は、前記記憶装置１０１より前記決定処理業者の情報を読み出して、現在を含む所定時間帯における各利用者から前記決定処理業者に宛てた物品の処理希望数を算定し、この処理希望数が前記決定処理業者の処理可能量を越えるか、所定基準以上に接近しているか判定し、前記処理希望量が前記決定処理業者の処理可能量を越えるか、所定基準以上に接近している状況であれば、前記業者一覧を生成する際に、業者一覧からの該当処理業者の除外処理か、業者一覧中における所定数の順位低減を行うものであるとすれば好適である。

また、前記システム１００は、前記必要情報を構成する各項目について処理業者が独自に使用する項目名や選択肢名に関する情報を処理業者の端末３００から受信し、前記データベース１２５に登録する業者データ登録部１１６を備えるとしてもよい。

なお、これまで示した システム１００における各機能部１１０〜１１６は、ハードウェアとして実現してもよいし、メモリやＨＤＤ（Hard Disk Drive）などの適宜な記憶装置に格納したプログラムとして実現するとしてもよい。この場合、前記ＣＰＵ１０４がプログラム実行に合わせて記憶装置より該当プログラムをメモリ１０３に読み出して、これを実行することとなる。

また、前記ネットワーク１４０に関しては、インターネット、ＬＡＮの他、ＡＴＭ回線や専用回線、ＷＡＮ（Wide Area Network）、電灯線ネットワーク、無線ネットワーク、公衆回線網、携帯電話網、シリアル・インターフェース通信線など様々なネットワークを採用することも出来る。また、ＶＰＮ（Virtual Private Network）など仮想専用ネットワーク技術を用いれば、インターネットを採用した際にセキュリティ性を高めた通信が確立され好適である。

−−−データベース構造−−−
次に、本実施形態における前記システム１００が利用するデータベース１２５の構造について説明する。なお、本実施形態における前記データベース１２５は、下記の通り、複数のデータベースから構成されているものとする。

図２は、本実施形態における、（ａ）処理条件データベース１２６、（ｂ）業者定性情報データベース１２７、（ｃ）業者処理項目名データベース１２８、（ｄ）業者処理選択肢名データベース１２９の各データ構造例を示す図である。

前記処理条件データベース１２６は、利用者の所在地と物品大分類について利用者が選びうる選択肢を格納するデータベースである。また、この処理条件データベース１２６は、例えば項番をキーとして、地域名（例：東京都、神奈川県、埼玉県・・・）、および物品の大分類（例：家具、子供用品、日用品、電化製品・・・）といった情報を関連づけたレコードの集合体となっている。

また、前記業者定性情報データベース１２７は、システム１００に登録された処理業者の属性情報を格納するデータベースである。また、この業者定性情報データベース１２７は、例えば項番および業者番号をキーとして、業者名、（引き受け可能な）処理種類、地域（引き受け対象地区）、物品の大分類（引き受け可能な物品の大分類）、業者種別（例：全国企業、地場企業、地場ＮＰＯ、・・・）といった情報を関連づけたレコードの集合体となっている。

また、前記業者処理項目名データベース１２８は、各処理業者において処理受付に当たって必要な情報項目について格納するデータベースである。また、この業者処理項目名データベース１２８は、例えば項番および業者名をキーとして、各処理業者における必要情報の項目（例：物品名、製造年、会社名、型式、収容人数、大きさ、色、素材、破損状態・・・）が関連づけられたマトリクスとなっている。

また、業者処理選択肢名前記データベース１２９は、各処理業者の前記必要情報の各項目についての選択肢を格納するデータベースである。ここでの例では、前記必要情報の項目のうち、「物品名」についての各処理業者毎の選択肢を示すものとなっている。また、この業者処理選択肢名データベース１２９は、例えば項番および業者名をキーとして、選択肢名（例：テーブル、机、椅子、ソファ、タンス、食器棚、本棚、鏡台、ベッド・・・）が関連づけられたマトリクスとなっている。勿論、この業者処理選択肢名データベース１２９は、必要情報の各項目毎に用意されているものとする。

また、図３は、本実施形態における、（ａ）業者製品データベース１３０、（ｂ）優先順序データベース１３１、（ｃ）業者項目名対応データベース１３２、（ｄ）業者選択肢名対応データベース１３３、（ｅ）辞書データベース１３４、の各データ構造例を示す図である。

前記業者製品データベース１３０は、処理業者において引き受け可能な物品に関する必要情報の選択肢と、当該選択肢に応じて変化する処理に必要な料金と日数の情報を、各処理業者の端末３００からがシステム１００が取得し。格納するデータベースである。また、この業者製品データベース１３０は、例えば製品番号（物品の）をキーとして、物品名、製造年、収容人数、破損部位、色、処理価格、必要日数といった情報を関連づけたレコードの集合体となっている。

また、前記優先順序データベース１３１は、システム１００が利用者端末２００に提示する業者一覧の中で処理業者の情報を並べる際の所定基準を格納するデータベースである。また、この優先順序データベース１３１は、例えば順序番号をキーとして、全体順序（例：処理種類間＞処理種類内＞業者種別）、処理種類間（例：修理＞オークション＞寄付＞リサイクル＞粗大ゴミ）、処理種類内（例：処理価格＞業者種別＞必要日数）、業者種別（例：地場企業・ＮＰＯ＞全国企業・ＮＰＯ）といった情報を関連づけたレコードの集合体となっている。

また、前記業者項目名対応データベース１３２は、前記必要情報を構成する各項目について、システム側の名称と処理業者側の名称との対応関係データを格納するデータベースである。また、この業者項目名対応データベース１３２は、例えば項番および項目名（例：物品名、製造年、会社名、型式、収容人数、大きさ、色、素材、破損状態・・・）をキーとして、業者の対応項目名（例：商品名、出荷年、収容人数、カラー、破損状況）を関連づけたレコードの集合体となっている。

また、前記業者選択肢名対応データベース１３３は、前記必要情報についての選択肢について、システム側の名称と処理業者側の名称との対応関係データを格納するデータベースである。また、この業者選択肢名対応データベース１３３は、例えば項番および項目名（例：物品名、製造年・・・）をキーとして、選択肢名（例：テーブル、机、椅子、ソファ・・・）、業者の対応選択肢名（例：ダイニングテーブル、デスク、スツール、ソファ・・・）といった情報を関連づけたレコードの集合体となっている。

また、前記辞書データベース１３４は、システム側で管理する項目名と処理業者側で使用する可能性のある項目名との対応関係データを格納するデータベースである。また、この辞書データベース１３４は、例えば項番および項目名番号をキーとして、システム側で標準的に使用する標準項目名（例：物品名）、この標準項目名に対して処理業者側で使用する可能性のある類似項目名（例：商品名、製品名、品名、不要品名、処理品名・・・）といった情報を関連づけたレコードの集合体となっている。

−−−処理フロー例１−−−
以下、本実施形態における不要品・要修理品の処理受付方法の実際手順について、図に基づき説明する。なお、以下で説明する不要品・要修理品の処理受付方法に対応する各種動作は、前記システム１００がメモリ１０３に読み出して実行するプログラム１０２によって実現される。そして、このプログラム１０２は、以下に説明される各種の動作を行うためのコードから構成されている。ここでは、利用者が選択した条件に基づいて様々な処理業者の中から「N修理業者」が選出され、この「N修理業者」に対して処理依頼を行う例を示す。図６は、本実施形態における不要品・要修理品の処理受付方法の実際手順例１を示すフロー図である。

まず、前記利用者の利用者端末２００は、前記ネットワーク１４０を介して、不要品・要修理品の修理・オークション・寄付・リサイクル・廃棄処理受付サービスのサイトにアクセスし、前記サービスの選択指示を入力インターフェイスを介して利用者から受ける（ステップS1000）。ここで利用者端末２００が受け付けたサービス選択指示はシステム１００が取得し、システム１００の可能処理特定部１１０は、処理条件データベース１２６を参照して処理条件データの項目を抽出する（ステップS1001）。そして、この処理条件データの項目（図１０の例では、「地域」と「物品の大分類」）を選択肢とした選択画面１０（図１０参照）のデータを利用者端末２００に返信する（ステップS1002）。

一方、前記利用者端末２００は前記処理条件データをシステム１００から受け取る（ステップS1003）。この時、前記利用者端末２００は、前記選択画面１０を受信して、出力インターフェイスに表示する。なお当該選択画面１０において、「地域」については複数選択可能であり、主として利用者の居住自治体の選択を想定しているが、利用者の居住自治体以外の選択や、居住自治体を含む近隣自治体一帯まで広げての検索も受付けるとしてよい。

前記利用者は、前記利用者端末２００が表示した選択画面１０において、利用者が処理を希望する物品と利用者所在地との情報についての選択指示を行う。利用者端末２００ではこの選択指示を受け付けて、システム１００に送信する（ステップS1004）。この例では、「地域」の条件：「東京都」、「物品の大分類」の条件：「家具」の各情報が、前記利用者端末２００からの処理依頼情報としてシステム１００に返信される。

他方、前記システム１００の可能処理特定部１１０は、利用者端末２００から、前記処理依頼情報を受信する（ステップS1005）。また、この処理依頼情報が含む前記物品と前記利用者所在地の情報をキーにして業者定性情報データベース１２７を参照し（ステップS1006）、前記物品について引き受け可能な処理の検索と、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者の検索とを実行する（ステップS1007、S1008）。ここでの検索結果はシステム１００がメモリ１０３に格納する。

この例では、「東京都」をキーとして業者定性情報データベース１２７の「地域」を検索、「家具」をキーとして業者定性情報データベース１２７の「処理種類」を検索し、検索結果の「業者名」、「処理種類」を抽出することとなる。この時の検索結果の例を図１１（ａ）に示す。この検索結果１１は、「東京都」を引き受け対象地区に含み、「家具」を引き受け可能な物品とした処理業者の一覧となっている。

また、前記システム１００の処理一覧送信部１１１は、前記メモリ１０３より前記検索結果を読み出して、例えば、「処理種類」をキーとして処理種類それぞれの該当処理業者数をカウントし、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を生成し、前記物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末２００に返信する（ステップS1008）。

なお、前記業者定性情報データベース１２７において、前記処理引き受け対象地区の情報は、各地区の隣接関係についても記述した情報を含むことを想定できる。例えば、前記「地域」の欄の隣に、「隣接地域」の欄を設けて、「地域」：「東京都」、「隣接地域」：「埼玉県」、「千葉県」といった設定ができる。この場合、前記可能処理特定部１１０は、前記物品について引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索した結果、該当処理業者数が所定の閾値より少なければ、前記引き受け対象地区の隣接地区を引き受け対象地区とする処理業者についても前記業者定性情報データベース１２７で特定して検索対象とし、該当処理業者数が前記閾値を満たすまで検索対象を拡充するとしてもよい。

一方、利用者端末２００は、前記入力画面データを受信する（ステップS1009）。利用者端末２００が受信して出力インターフェイスに表示した前記入力画面１２の例を図１１（ｂ）に示す。この入力画面１２の例では、処理種別：「修理」について引き受け可能な処理業者：３件、同様に、処理：「オークション」について処理業者：２件、処理：「リサイクル」について処理業者：１件、処理：「寄付」について処理業者：１件、処理：「粗大ごみ」について処理業者：１件、がリストアップされ、処理種別＝希望処理を選択可能なチェックボックスが設定されている。利用者は、前記入力画面１２でもって処理種類と処理業者件数を確認することができる。

利用者端末２００は、利用者による前記入力画面１２での選択指示を受け付けて、この選択指示をシステム１００に送信する（ステップS1010）。なお、前記入力画面１２における「希望処理」は、複数選択できる。この例では、「修理」、「オークション」、「リサイクル」、「粗大ゴミ」について処理を希望する旨の「○」、「寄付」について処理を希望しない旨の「×」のデータが利用者端末２００からシステム１００に送信されることとなる。

他方、前記システム１００の必要情報特定部１１２は、前記利用者端末２００から前記希望処理の情報を受け取る（ステップS1011）。そして、前記システム１００の前記必要情報問合わせ部１１３は、前記ステップS1007で抽出した処理業者のうち、前記利用者が希望しない処理を提供する業者を削除する（ステップS1012）。この時の検索結果の例を図１１（ｃ）に示す。この検索結果１３では、処理：「寄付」を行う業者１件が削除されている。

また、前記システム１００の必要情報問合わせ部１１３（または必要情報特定部１１２）は、前記ステップS1012で抽出した処理業者について、「業者名」をキーとして、業者処理項目名データベース１２８を該当項目の検索を実行する（ステップS1013）。また、前記ステップS1012で抽出した処理業者について、業者処理項目名データベース１２８より抽出したデータを一覧化し、「○」のついていない項目名（つまり処理引き受けに必要ない情報）の行を削除する（ステップS1014）。この時の検索結果の例を図１２（ａ）に示す。この例における検索結果１４では、項目名が「型式」、「大きさ」、「素材」、の各行が削除されている。こうして得られた項目が、処理引き受け時に必要となる必要情報の項目となり、前記利用者に問合わせる項目名となる。

続いて、前記システム１００の必要情報問合わせ部１１３（または必要情報特定部１１２）は、利用者に問合わせる前記必要情報の各項目について、業者処理選択肢名データベース１２９を参照し、前記ステップS1012で抽出した処理業者について、「業者名」をキーとして、該当業者処理選択肢名の検索をする（ステップS1015）。例えば、業者処理項目名データベース１２９における項目名番号「１」である「物品名」について、業者処理選択肢名：物品名を参照し、前記ステップS1012で抽出した対象となる処理業者が扱う選択肢を抽出する。そして、前記ステップS1012で抽出した処理業者について、業者選択肢名データベース１２９より抽出したデータを一覧化し、「○」のついていない（つまり、該当処理業者にとって選択しえない）選択肢名の行を削除する（ステップS1016）。この時の検索結果の例を図１２（ｂ）に示す。この検索結果１５では、「食器棚」と「鏡台」の選択肢が削除された例となっている。

また、前記システム１００の必要情報問合わせ部１１３（または必要情報特定部１１２）は、前記必要情報の各項目について選択肢名の検索結果を参照し、前記利用者端末２００に送信する選択肢名を抽出し一覧化する（ステップS1017）。また、前記必要情報問合わせ部１１３は、前記ステップS1017の結果を前記利用者端末２００に送信する（ステップS1018）。この時の送信データ１６の例を図１３に示す。前記送信データとは、利用者端末２００に送信する必要情報の項目名、選択肢名をまとめたデータである。

図７は、本実施形態における不要品・要修理品の処理受付方法の実際手順例２を示すフロー図である。前記ステップS1019に引き続く処理について説明する。前記利用者端末２００は、前記システム１００より前記必要情報に関する問合わせたる前記送信データを受信する（ステップS1019）。この時の利用者端末２００が受信し出力インターフェイスに表示した条件選択画面１７の例を図１５に示す。この条件選択画面１７は、「物品名」、「製造年」、「会社名」、「収容人数」、「色」、「破損状態」が選択項目として表示されたものとなる。前記利用者は、前記利用者端末２００で表示されている前記条件選択画面１７でもって、処理を依頼したい物品に関する必要情報についての選択を行う。利用者端末２００ではこの選択指示を受け付けて、回答データとして前記システム１００に送信する（ステップS1020）。

一方、前記システム１００の最終結果送信部１１４は、前記利用者端末２００からの前記回答データを受信する（ステップS1021）。この時の回答データ１８の例を図１４（ｂ）に示す。また、前記最終結果送信部１１４は、前記回答データ１８の「選択肢」列にあるデータ、物品名：「テーブル」、製造年：「１９９３」、会社名：「ＡＡＡ会社」、収容人数：「４人用」、色：「ベージュ」、破損状態：「あり：小」、つまり必要情報をキーとして、各処理業者の業者製品データベース１３０で、該当物品に関する各処理に関するレコードの検索を実行する（ステップS1022）。前記最終結果送信部１１４は、前記ステップS1022で検索して特定したレコードの「処理価格」と「必要日数」を抽出し、前記ステップS1012で求めた検索結果に反映する（ステップS1023）。この時の検索結果１９の例を図１５（ａ）に示す。

また、前記最終結果送信部１１４は、前記検索結果１９が含む業者名をキーとして業者定性情報データベース１２７に業者種別を問合わせ、前記ステップS1023で求めた検索結果１９に加える（ステップS1024）。この時の検索結果２０の例を図１５（ｂ）に示す。また、優先順序データベース１３１に「全体順序」の順序番号を問合わせる（ステップS1025）。この例では、処理種類間＞処理種類内＞業者種別が優先順序データベース１３１から返される。

また、前記最終結果送信部１１４は、前記優先順序データベース１３１に問合わせた処理種類間の順序に従って、前記ステップS1022で求めた検索結果における各レコードを並べ替える（ステップS1026）。この時の検索結果２１の例を図１５（ｃ）に示す。この例では、「処理種類」の列について、修理＞オークション＞リサイクル＞粗大ごみ収集の順で順序付けがなされている。

次に、前記最終結果送信部１１４は、前記優先順序データベース１３１に処理種類内の順序を問合わせ、その問合わせ結果に従って、前記ステップS1026で求めた検索結果の各レコードを並べ替える（ステップS1027）。この時の検索結果２２の例を図１６（ａ）に示す。この例では、前記処理種類内の順序が、処理価格＞業者種別＞必要日数の順のため、「処理価格」の列について第１に順序付けがなされる。なお、「修理」、「リサイクル」については「処理価格」が安い順、「オークション」については「処理価格」が高い順に並べ替えがなされる。

また、前記最終結果送信部１１４は、前記優先順序データベース１３１に業者種別の順序を問合わせ、その問合わせ結果に従って、前記ステップS1027で求めた検索結果の各レコードを並べ替える（ステップS1028）。この時の検索結果２３の例を図１６（ｂ）に示す。この例では、業者種別の順序に従って、地場企業・NPO＞全国企業・NPOの順で順序付けがなされている。

次に前記最終結果送信部１１４は、前記ステップS1028で抽出した結果について、「処理種類」、「処理価格」、「必要日数」、「業者名」、「業者種別」を抽出する（ステップS1029）。この時の検索結果２４の例を図１６（ｃ）に示す。また、前記最終結果送信部１１４は、前記ステップS1029で抽出した結果（検索結果２４）を利用者端末２００に送信する（ステップS1030）。この時、システム１００から利用者端末２００に送信される検索結果２４は、図１７に示す検索結果確認・希望処理申込画面２５として送信される。

図８は。本実施形態における不要品・要修理品の処理受付方法の実際手順例３を示すフロー図である。前記ステップS1030に引き続く処理について説明する。前記利用者端末２００は、前記システム１００から前記検索結果確認・希望処理申込画面２５を受信する（ステップS1031）。また、前記利用者端末２００は、利用者による希望処理の選択指示を受け付けて、これをシステム１００に返信する（ステップS1032）。この例では、「修理」に希望処理「○」、つまり処理希望が、「オークション」、「リサイクル」、「粗大ごみ収集」について希望処理「×」、つまり処理非希望のデータが送信される。

一方、前記システム１００の仲介部１１５は、前記希望処理の選択指示（決定処理業者の情報）を利用者端末２００からを受信する（ステップS1033）。また、前記「希望処理」について、前記ステップS1029で抽出した結果に反映し、「希望処理」が「×」の行のデータを削除する。この時の検索結果２６の例を図１８（ａ）に示す。これにより、前記利用者は、物品について「N修理業者」に「修理」を依頼することが決定したこととなる。

続いて、前記仲介部１１５は、業者処理項目名データベース１３２を参照する（ステップS1034）。また、前記ステップS1014で求めた検索結果から、業者名「N」をキーとして、「N修理業者」に送信すべき項目名を抽出し（ステップS1035）、「項目名番号」について「○」のついていない行を削除する。この例では、「会社名」の列が削除される。この時の検索結果２７の例を図１８（ｂ）に示す。これが、処理業者たる「N修理業者」に送るべき項目名となる。

前記仲介部１１５は、前記ステップS1035で求めた「項目名」の列の項目をキーとして、前記ステップ1021で入手した回答データを参照する（ステップS1036）。そして、前記ステップS1036で求めた回答データの選択肢について、「N修理業者」に送るべき選択肢名を抽出する（ステップS1037）。この時の検索結果２８の例を図１８（ｃ）に示す。

続いて、前記仲介部１１５は、「N修理業者」の業者項目名対応データベース１３２を参照する（ステップS1038）。また、前記ステップS1035で求めた項目名について「N修理業者」の対応する項目名を抽出し、前記ステップS1037で求めた検索結果に反映する（ステップS1039）。この時の検索結果２９の例を図１９（ａ）に示す。

次に、前記仲介部１１５は、前記「N修理業者」の業者選択肢名対応データベース１３３を参照する（ステップS1040）。また、前記ステップS1037で求めた選択肢名について、前記「N修理業者」の対応する選択肢名を抽出し、前記ステップS1039で求めた検索結果に加える（ステップS1041）。この時の検索結果３０の例を図１９（ｂ）に示す。

また、前記仲介部１１５は、前記ステップS1041で求めた「業者の対応項目名」と「業者の対応選択肢名」のデータを抜き出し、このデータを処理依頼データとして「N修理業者」の修理業端末３１０に送信する（ステップS1042）。この時の処理依頼データ３１の例を図１９（ｃ）に示す。一方、前記「N修理業者」の修理業端末３１０は、前記処理依頼データを受け取り（ステップS1043）、本フローは終了する。

−−−他の実施例−−−
続いて、処理業者の用いる項目名、選択肢名の登録の実行方法について説明する。図９は、本実施形態における不要品・要修理品の処理受付方法の実際手順例４を示すフロー図である。ここでは、「O修理業者」の用いる項目名、選択肢名を前記システム１００に登録する例を想定する。ここで、前記システム１００の業者データ登録部１１６は、前記「O修理業者」の修理業端末３１５に対し、処理を行う際に必要とする必要情報の項目名と選択肢名の送信を要求する通知を送る（ステップS2001）。この時、前記「O修理業者」の修理業端末３１５は、前記送信要求を受信する（ステップS2002）。また、前記「O修理業者」の修理業端末３１５は、処理のために必要とする必要情報の項目名と選択肢名の情報を前記システム１００に返信する（ステップS2003）。この時の前記「O修理業者」の修理業端末３１５からの送信データ３２の例を図２０（ａ）に示す。

前記業者データ登録部１１６は、前記「O修理業者」の修理業端末３１５からの送信データ３２を回答として受け取る（ステップS2004）。そして、前記「O修理業者」の修理業端末３１５からの回答における必要情報の「項目名」をキーとして、辞書データベース１３４における「標準項目名」、「類似項目名」の検索を行う（ステップS2005）。そして、前記業者データ登録部１１６は、前記回答において、前記辞書データベース１３４の「類似項目名」と同一の項目名を、「類似項目名」が属する「標準項目名」に書き換える（ステップS2006）。この時の検索結果３３の例を図２０（ｂ）に示す。

続いて前記業者データ登録部１１６は、業者処理項目名データベース１２８に新たに前記「O修理業者」を登録する（ステップS2007）。この登録処理は、前記ステップS2006で求めた検索結果の辞書データベース１３４における「標準項目名」に合致する項目名についてなされる登録処理となる。業者処理項目名データベース１２８への登録例３４の例を図２１（ａ）に示す。この例では、前記業者処理項目名データベース１２８にて「O修理業者」の列が新設され、「物品名」、「製造年」、「会社名」、「収容人数」、「色」、「破損状態」の各項目について、「○」が登録されている。

次に、前記業者データ登録部１１６は、前記「O修理業者」の修理業端末３１５からの回答における「選択肢名」をキーとして、辞書データベース１３４（選択肢名対応）の「標準選択肢名」、「類似選択肢名」の検索を行う（ステップS2008）。この時の辞書データベース１３４の例を図２１（ｂ）に示す。

また、前記業者データ登録部１１６は、前記「O修理業者」の修理業端末３１５からの回答において、前記辞書データ１３４（選択肢名対応）における「類似選択肢名」と同一の選択肢名を、「類似選択肢名」が属する「標準選択肢名」に書き換える（ステップS2009）。この時の前記「O修理業者」の修理業端末３１５からの回答データと辞書データベース１３４の対照表３６の例を図２２に示す。

また、前記業者データ登録部１１６は、前記業者処理選択肢名データベース１２９の各項目について、新たに「O修理業者」を登録する（ステップS2010）。この登録処理は、前記ステップS2009で求めた検索結果の辞書データベース１３４における「選択肢名」に合致する選択肢名についてなされる。この時の検索結果３７の例を図２３に示す。この例では、前記業者処理選択肢名データベース１２９において「O修理業者」の列が新設され、選択肢名「テーブル」、「机」、「椅子」、「ソファ」、「本棚」、「ベッド」について、「○」が登録され、処理は終了する。

−−−その他の例−−−
図２４は本実施形態における不要品・要修理品の処理受付方法の実際手順例５を示すフロー図である。その他の例として、前記システム１００の仲介部１１５が、前記ステップS1033において受信した決定処理業者の情報（例えば、「Ｎ修理業者」）を記憶装置１０１に格納している状況を想定する。この時、前記システム１００の前記最終結果送信部１１４は、前記記憶装置１０１より前記「Ｎ修理業者」に関する情報を、例えば、所定時間毎にメモリ１０３に読み出す（ステップs300）。また、現在時刻（システム１００の備える時計機能から取得）を含む所定時間帯（例えば、現在時刻の前後３０分）における各利用者から前記「Ｎ修理業者」に宛てた物品の処理希望数を算定する（ステップs301）。例えば、前記「Ｎ修理業者」に対して、現在１００名の利用者から「家具」の「修理」処理の依頼がなされているとすれば、前記最終結果送信部１１４は、前記Ｎ修理業者に関する前記処理希望数を「１００」と算定する。

そして、最終結果送信部１１４は、前記処理希望数「１００」が前記「Ｎ修理業者」の処理可能量（予め業者定性情報データベース１２７等において処理業者毎に設定されている。例：１００）を越えるか、所定基準以上に接近しているか判定する（ステップs302）。この例では、前記処理希望量「１００」が前記決定処理業者の処理可能量「１００」に達しているから、所定基準以上に接近している状況と判定する（ステップs302：ＮＧ）。他方、前記処理希望量が前記決定処理業者の処理可能量に達していなかった場合や、所定基準以上に接近していない場合（ステップs302：ＯＫ）、処理を前記ステップs300に戻す。

前記処理希望量「１００」が前記決定処理業者の処理可能量「１００」に達していて、所定基準以上に接近している状況と判定したならば（ステップs302：ＮＧ）、前記最終結果送信部１１４は、前記業者一覧を生成する際に、業者一覧からの該当処理業者「Ｎ修理業者」の除外処理か、業者一覧中における所定数（例：５位）の順位低減を行う（ステップs303）。例えば、処理業者が「地方自治体」の管理する廃棄物処分業者である時など、廃棄処分場の容量の関係で処理量の低減が求められるような状況であれば、こうした処理を所定期間毎に行うことで、ある処理業者に処理依頼が集中して処理能力を越えるといった状況を解消できる。また、処理業者間での処理負荷の均等化を図れるので、地域に属する処理業者間でビジネスチャンスの均等化も図れ、処理業者の相互成長が見込める。

以上により、不要品・要修理品の処理依頼について、複数の地域や処理業者および処理内容を跨ってのマッチング処理サービスが提供できることとなる。また、利用者らが、複数の地域や業者および処理内容に跨ってサービスの比較検討を行う場合、各処理業者のｗｅｂサイトなどに逐一アクセスする必要は無くなり、効率的な処理業者選出が実現される。加えて、不要品・要修理品の処理依頼に必要な情報について、重複項目は予め削除され利用者側に提示できることから、同一内容のデータ入力を繰り返し利用者に強いるといった従来の状況は解消され、利用者への負担を圧縮しユーザビリティに優れた処理受付を実現できる。

したがって本実施例によれば、不用品・要修理品等の各種処理依頼を行う利用者に対して地域や処理に関する多様な選択肢を提示し、利用者所望の条件にマッチする処理が可能な処理業者を抽出し提示可能となる。

以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

本実施形態における不要品・要修理品の処理受付システムを含むネットワーク構成図である。 本実施形態における、（ａ）処理条件データベース、（ｂ）業者定性情報データベース、の各データ構造例を示す図である。 本実施形態における、（ａ）業者処理項目名データベース、（ｂ）業者処理選択肢名データベースの各データ構造例を示す図である。 本実施形態における、（ａ）業者製品データベース、（ｂ）優先順序データベース、（ｃ）業者項目名対応データベース、の各データ構造例を示す図である。 本実施形態における、（ａ）業者選択肢名対応データベース、（ｂ）辞書データベース、の各データ構造例を示す図である。 本実施形態における不要品・要修理品の処理受付方法の実際手順例１を示すフロー図である。 本実施形態における不要品・要修理品の処理受付方法の実際手順例２を示すフロー図である。 本実施形態における不要品・要修理品の処理受付方法の実際手順例３を示すフロー図である。 本実施形態における不要品・要修理品の処理受付方法の実際手順例４を示すフロー図である。 本実施形態における処理条件選択画面の例を示す図である。 本実施形態における、（ａ）業者絞込みに向けた検索結果１、（ｂ）希望処理種別選択画面、（ｃ）業者絞込みに向けた検索結果２の各例を示す図である。 本実施形態における、（ａ）利用者問合わせ項目抽出に向けた検索結果１、（ｂ）利用者問合わせ項目抽出に向けた検索結果２の各例を示す図である。 本実施形態における送信データの例を示す図である。 本実施形態における、（ａ）条件選択画面、（ｂ）回答データの各例を示す図である。 本実施形態における、（ａ）業者絞込みに向けた検索結果３、（ｂ）業者絞込みに向けた検索結果４、（ｃ）業者絞込みに向けた検索結果５の各例を示す図である。 本実施形態における、（ａ）業者絞込みに向けた検索結果６、（ｂ）業者絞込みに向けた検索結果７、（ｃ）業者絞込みに向けた検索結果８の各例を示す図である。 本実施形態における検索結果確認・希望処理申込画面の例を示す図である。 本実施形態における、（ａ）業者絞込みに向けた検索結果９、（ｂ）業者問合わせ項目抽出に向けた検索結果１、（ｃ）業者問合わせ項目抽出に向けた検索結果２の各例を示す図である。 本実施形態における、（ａ）業者問合わせ項目抽出に向けた検索結果３、（ｂ）業者問合わせ項目抽出に向けた検索結果４、（ｃ）修理業者への送信データの各例を示す図である。 他の実施形態における、（ａ）修理業者からの送信データ、（ｂ）項目名についての業者回答データと辞書データの対照表の各例を示す図である。 他の実施形態における、（ａ）業者処理項目名データ、（ｂ）辞書データにおける選択肢名の各例を示す図である。 他の実施形態における項目名、選択肢名についての業者回答データと辞書データの対照表の例を示す図である。 他の実施形態における業者処理選択肢名データの例を示す図である。 本実施形態における不要品・要修理品の処理受付方法の実際手順例５を示すフロー図である。

符号の説明

１００ 不要品・要修理品の処理受付システム
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ ＣＰＵ
１０５ 入力インターフェイス
１０６ 出力インターフェイス
１０７ 通信装置
１１０ 可能処理特定部
１１１ 処理一覧送信部
１１２ 必要情報特定部
１１３ 必要情報問合わせ部
１１４ 最終結果送信部
１１５ 仲介部
１１６ 業者データ登録部
１２５ データベース
１２６ 処理条件データベース
１２７ 業者定性情報データベース
１２８ 業者処理項目名データベース
１２９ 業者処理選択肢名データベース
１３０ 業者製品データベース
１３１ 優先順序データベース
１３２ 業者項目名対応データベース
１３３ 業者選択肢名対応データベース
１３４ 辞書データベース
１４０ ネットワーク
２００ 利用者端末
３００ 処理業者端末
３１０ 修理業者端末
３２０ オークション業者端末
３３０ 寄付業者端末
３４０ リサイクル業者端末
３５０ 地方自治体端末

Claims (7)

1. 利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うコンピュータシステムであって、
   ネットワークを介して利用者端末と通信する通信装置と、
   処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベースを記憶した記憶装置と、
   利用者端末から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベースに照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリに格納する、可能処理特定処理と、
   前記メモリより前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末に返信する、処理一覧送信処理と、
   前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベースにて特定しメモリに格納する、必要情報特定処理と、
   前記メモリより前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末に返信する、必要情報問合わせ処理と、
   前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末から受信し、この必要情報を前記データベースに照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末に返信する、最終結果送信処理と、を実行する演算装置と、
   を備えることを特徴とする不要品・要修理品の処理依頼受付システム。
2. 前記必要情報問合わせ処理は、前記必要な情報が処理業者間で重複する場合に重複情報を削除して、前記必要な情報の問合わせ画面のデータを生成するものである、ことを特徴とする請求項１に記載の不要品・要修理品の処理依頼受付システム。
3. 前記データベースにおいて、前記処理引き受け対象地区の情報は、各地区の隣接関係についても記述した情報を含み、
   前記可能処理特定処理は、前記検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索した結果、該当処理業者数が所定の閾値より少なければ、前記引き受け対象地区の隣接地区を引き受け対象地区とする処理業者についても検索対象とし、該当処理業者数が前記閾値を満たすまで検索対象を拡充するものである、ことを特徴とする請求項１または２に記載の不要品・要修理品の処理依頼受付システム。
4. 前記演算装置は、前記利用者端末から、前記業者一覧中より指定された決定処理業者の情報を受信して記憶装置に格納し、該当処理業者の端末に宛てて前記利用者の前記物品に関する処理依頼と必要情報について情報を送信する、仲介処理を実行するものである、ことを特徴とする請求項１〜３のいずれかに記載の不要品・要修理品の処理依頼受付システム。
5. 前記最終結果送信処理は、前記記憶装置より前記決定処理業者の情報を読み出して、現在を含む所定時間帯における各利用者から前記決定処理業者に宛てた物品の処理希望数を算定し、この処理希望数が前記決定処理業者の処理可能量を越えるか、所定基準以上に接近しているか判定し、前記処理希望量が前記決定処理業者の処理可能量を越えるか、所定基準以上に接近している状況であれば、前記業者一覧を生成する際に、業者一覧からの該当処理業者の除外処理か、業者一覧中における所定数の順位低減を行うものであることを特徴とする請求項４に記載の不要品・要修理品の処理依頼受付システム。
6. 利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うコンピュータが、
   ネットワークを介して利用者端末と通信する通信装置と、
   処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベースを記憶した記憶装置と、演算装置とを備えて、
   利用者端末から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベースに照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリに格納する、可能処理特定処理と、
   前記メモリより前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末に返信する、処理一覧送信処理と、
   前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベースにて特定しメモリに格納する、必要情報特定処理と、
   前記メモリより前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末に返信する、必要情報問合わせ処理と、
   前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末から受信し、この必要情報を前記データベースに照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末に返信する、最終結果送信処理と、
   を実行することを特徴とする不要品・要修理品の処理依頼受付方法。
7. 利用者の不要品、要修理品といった物品について、処理依頼を受け付けて利用者所望の処理を行う処理業者と前記利用者との仲介処理を行うべく、ネットワークを介して利用者端末と通信する通信装置と、処理引き受け可能な物品の属性、前記物品について引き受け可能な処理の属性、前記処理の引き受け時に必要な情報、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報、および処理引き受け対象地区の各情報について処理業者毎に格納したデータベースを記憶した記憶装置と、演算装置とを備えたコンピュータに、
   利用者端末から、利用者が処理を希望する物品と利用者所在地との情報を含む、処理依頼情報を受信し、この処理依頼情報が含む前記物品と前記利用者所在地の情報を、前記データベースに照合し、前記物品について引き受け可能な処理を検索し、ここで検索された処理を引き受け可能であり前記利用者所在地を引き受け対象地区に含む処理業者を検索し、検索結果をメモリに格納するステップと、
   前記メモリより前記検索結果を読み出して、前記物品について引き受け可能な処理と当該処理を引き受け可能な処理業者とについての一覧情報を含み、物品について引き受け可能な処理の一覧より、利用者所望の処理についての選択を受付ける入力画面データを生成し、この入力画面データを前記利用者端末に返信するステップと、
   前記入力画面を介して利用者所望の処理についての選択指示を前記利用者端末から受信し、この選択指示に対応する各処理業者において、前記利用者所望の処理の引き受け時に必要な情報を前記データベースにて特定しメモリに格納するステップと、
   前記メモリより前記利用者所望の処理の引き受け時に必要な情報を読み出して、前記必要な情報の問合わせ画面のデータを生成し、この問合わせ画面データを前記利用者端末に返信するステップと、
   前記問合わせ画面を介して利用者入力の必要情報を前記利用者端末から受信し、この必要情報を前記データベースに照合し、前記必要な情報に基づく前記物品についての引き受け可能な処理にかかる処理費用と日数の情報とを特定し、ここで特定した処理費用または日数の所定基準順に該当処理業者の情報を並べた業者一覧を生成し利用者端末に返信するステップと、
   を実行させることを特徴とする不要品・要修理品の処理依頼受付プログラム。

Images