JP4357308B2

JP4357308B2 - 部品流通プログラム

Info

Publication number: JP4357308B2
Application number: JP2004014447A
Authority: JP
Inventors: 治畠山
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-01-22
Filing date: 2004-01-22
Publication date: 2009-11-04
Anticipated expiration: 2024-01-22
Also published as: JP2005208909A

Description

本発明は、車両を解体することにより取り出される部品を流通させるための技術に関するものである。

資源を有効活用するため、例えば自動車を解体することにより取り出される部品（リサイクル部品）の売買等は一般的に行われている。例えばリサイクル部品の情報提供を行うための技術が存在する（例えば特許文献１参照）。すなわち、センタ装置に、車両構成を特定する車両識別情報と車両の構成部品の一覧情報とを対応付けたデータベース機能をもたせ、解体業者のユーザ装置は、入庫した車両の上記車両識別情報の指定で上記構成部品一覧情報を入手できるようにしておき、解体業者が構成部品一覧からリサイクル部品として取り外す部品を指定してリサイクル部品情報としてセンタ装置に登録する。センタ装置は、登録されたリサイクル部品情報を、リサイクル部品の需要者からのアクセスでみられるようにする。解体業者が異なってもリサイクル部品情報を共通化することで正確な情報を需要者に届け、リサイクル部品の取引を活性化する。
特開２００２−１０９３２３号公報

しかしながら、このような従来技術によると、例えば複数の在庫車両があった場合、どの車両を解体するかということは解体業者の判断に委ねられている。従って、ある車両を解体したとしても、ユーザからの需要がない部品については在庫部品として残ってしまう。一方、ユーザは購入したい部品を検索し、解体済み又は解体業者が解体を決定した車両から取り出せる部品に該当するものがない場合にはあきらめるしかない。しかしながら、未だ解体していない又は解体業者が未だ解体を決定していない車両を解体することにより、ユーザが希望する部品が取り出せる場合もある。すなわち、スムーズな流通を可能とする仕組みが整っているとは言い難い。

従って、本発明の目的は、車両を解体することにより取り出される部品を適切に流通させるための新規な技術を提供することである。

本発明に係る方法は、車両を解体することにより取り出される部品を流通させるための部品流通方法であって、ユーザからの部品注文データが格納されている注文データ格納部を参照し、未発注の部品注文データを特定し、記憶装置に格納するステップと、未発注の部品注文データから特定される未発注の部品と、予め部品車両データ格納部に格納されている、車種と当該車種の車両を解体することにより取り出し可能な車両解体部品との関連データとを用いて、未発注の部品に対応する車両解体部品の、全体に対する割合が所定の閾値以上である車種を特定し、優先解体車種として記憶装置に格納する優先解体車種特定ステップとを含む。

このように、未発注の部品、すなわち需要に基づいて、解体を優先すべき車種を特定することにより、適切な部品流通が可能となる。例えば、取り出し可能な車両解体部品の全てについて需要がある車種を優先解体車種として特定するようにしてもよいし、例えば、需要がある部品の数が、取り出し可能な車両解体部品の総数の例えば８割以上である車種を優先解体車種として特定するようにしてもよい。また例えば、需要がある部品の合計価格が、取り出し可能な車両解体部品の総価格の例えば８割以上である車種を優先解体車種として特定するようにしてもよいし、例えば、部品毎に所定のポイントを対応付けておき、需要がある部品の合計ポイントが、取り出し可能な車両解体部品の総ポイントの例えば８割以上である車種を優先解体車種として特定するようにしてもよい。

また、上記優先解体車種特定ステップが、解体業者が所有する車両に関するデータが格納されている在庫車両データ格納部に、未発注の部品に対応する車両解体部品を取り出し可能な解体候補車両についてのデータが登録されているか判定する在庫確認ステップと、在庫確認ステップにおいて解体候補車両についてのデータが登録されていると判定された場合、未発注の部品に対応する車両解体部品の仮予約データを、解体候補車両から特定される車種別に生成されるニーズ登録テーブルに登録する仮予約ステップとを含み、ニーズ登録テーブルに登録されたデータに基づき、未発注の部品に対応する車両解体部品の、全体に対する割合を算出するようにしてもよい。

このように、需要に応じて仮予約データを登録していく。これにより、例えば所定以上の需要がある車種を特定することが可能となり、例えば解体を推奨する車種として解体業者に通知することができる。すなわち、無駄の少ない解体が実現可能となる。

また、上記在庫確認ステップにおいて、未発注の部品注文データに特定の車種を指定するデータが含まれていた場合、当該特定の車種の車両であって且つ未発注の部品に対応する車両解体部品を取り出し可能な解体候補車両についてのデータが登録されているか判定するようにしてもよい。例えば、異なる車種から同一又は互換性のある部品を取り出し可能な場合もある。一般的には同一部品として扱っても特に問題はないが、このように、ユーザから車種の指定があった場合には、指定された車種のみが解体候補車両となり得るようにすることで、よりユーザ・ニーズに応じた部品供給が可能となる。

また、上記仮予約ステップにおいて、解体候補車両に対応する車種が複数存在する場合、該当する全ての車種のニーズ登録テーブルについて、仮予約データを登録するようにしてもよい。上で述べたように、異なる車種から同一又は互換性のある部品を取り出し可能な場合もある。ユーザが、どの車種から取り出された部品なのかにこだわらないのであれば、このように複数の車種について仮予約データを登録しておくことにより、例えば最も早く解体される車両から取り出される部品を入手することができる。

また、上記仮予約ステップにおいて、特定の車種の車両解体部品に対応する、未発注の部品が複数存在する場合、当該特定の車種についての複数のニーズ登録テーブルに仮予約データを登録するようにしてもよい。ニーズ登録テーブルは車種毎に生成されるが、例えば他の車種と同一又は互換性のある部品が数多く組み込まれている車種や、人気のある車種等については、一つの部品に対して複数の需要がある場合がある。そのような場合には、同じ車種について複数のニーズ登録テーブルを生成することにより、需要に対応することができる。

なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することも可能であって、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してデジタル信号として配信される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、優先的に解体すべき車種を解体業者に示すことができ、ユーザ・ニーズに応じた適切な部品流通を行うことができる。

本発明の一実施の形態に係るシステム構成図を図１に示す。例えばインターネットであるネットワーク１には、例えばパーソナル・コンピュータである１又は複数のユーザ端末３と１又は複数の中古部品流通サーバ５とＡ販売者サーバ７とＢ販売者サーバ９とＣ販売者サーバ１１とが無線又は有線により接続されている。なお、図示しない他の販売者サーバが接続されている場合もある。

また、ユーザ端末３、中古部品流通サーバ５、Ａ販売者サーバ７、Ｂ販売者サーバ９及びＣ販売者サーバ１１は、図２に示すようなコンピュータ装置であって、メモリ２０１とＣＰＵ２０３とハードディスク・ドライブ（ＨＤＤ）２０５と表示装置２０９に接続される表示制御部２０７とリムーバブル・ディスク２１１用のドライブ装置２１３と入力装置２１５とネットワークに接続するための通信制御部２１７とがバス２１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実現するためのプログラムを含むアプリケーション・プログラムは、ＨＤＤ２０５に格納されており、ＣＰＵ２０３により実行される際にはＨＤＤ２０５からメモリ２０１に読み出される。必要に応じてＣＰＵ２０３は、表示制御部２０７、通信制御部２１７、ドライブ装置２１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２０１に格納され、必要があればＨＤＤ２０５に格納される。本発明の実施の形態における処理を実現するためのプログラムは例えばリムーバブル・ディスク２１１に格納されて頒布されドライブ装置２１３から、又はネットワーク及び通信制御部２１７を介して受信し、ＨＤＤ２０５にインストールされる。このようなコンピュータ装置は、上で述べたＣＰＵ２０３、メモリ２０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、以下で説明する各種機能を実現する。

図１の説明に戻り、中古部品流通サーバ５には、発注受付部５１とニーズ登録表管理部５２と引当処理部５３とが含まれている。これらの処理内容については、後の処理フローの説明において述べるが、発注受付部５１はウェブ（Ｗｅｂ）サーバ機能を有し、Ｗｅｂブラウザ機能を有するユーザ端末３からのアクセスが可能となっている。また、引当処理部５３はメーラ機能を有し、同様にメーラ機能を有するユーザ端末３及び各販売者サーバとの間でメール・データの送受信を行うことが可能となっている。また、中古部品流通サーバ５には、ニーズ登録表格納部５４と部品車両ＤＢ５５と販売者ＤＢ５６と客発注ＤＢ５７とが接続されている。

Ａ販売者サーバ７には、商品ＤＢ７１と部品価格ＤＢ７２とが接続されている。同様に、Ｂ販売者サーバ９には、商品ＤＢ９１と部品価格ＤＢ９２とが接続されており、Ｃ販売者サーバ１１には、商品ＤＢ１１１と部品価格ＤＢ１１２とが接続されている。

なお、本実施の形態において、各販売者サーバを管理・使用する販売者は、例えば解体業者であり、車の中古部品を供給する者を指す。また、ユーザ端末３を操作するユーザは、個人の消費者であってもよいし、修理工場や卸・小売店等の業者であってもよい。

図３に、部品車両ＤＢ５５のテーブル構成及び格納されるデータの一例を示す。図３の例には、車種番号の列３００と車種名の列３０２と搭載部品番号の列３０４とが含まれている。本テーブルには、車種毎に、当該車種の車両に搭載されている（当該車種の車両を解体することにより取り出し可能な）部品の番号が登録されている。図３に示した例によると、例えば部品番号が「Ｂ００１」である部品は「マルチ」及び「ビック」のいずれの車種からも取り出し可能である。

図４に、販売者ＤＢ５６のテーブル構成及び格納されるデータの一例を示す。図４の例には、販売者番号の列４００と名称の列４０２と連絡先の列４０４と所有車種の列４０６とが含まれている。販売者番号の列４００には、販売者毎に一意に付与された番号が登録されている。連絡先の列４０４には、販売者に通知を行う際に宛先とするメール・アドレスが登録されている。所有車種の列４０６には、販売者が所有している車両の車種番号が登録されている。所有車種の列４０６の値については、例えば、定期的に又は販売者の所有車種に変更があった際に、管理者等が更新する。中古部品流通サーバ５と各販売者サーバとの通信により、自動的に更新される場合もある。なお、本実施の形態においては、同一の販売者が同じ車種の車両を複数台所有していても、当該車種について登録される車種番号は１つであるが、車種毎の所有台数を把握可能な態様にてデータを保持してもよい。また、図４の例では、必要最低限の項目について示されているが、その他、販売者の住所や電話番号等、販売者の属性が登録される場合もある。

図５に、客発注ＤＢ５７のテーブル構成及び格納されるデータの一例を示す。図５の例には、発注番号の列５００と部品番号の列５０２と氏名の列５０４と連絡先の列５０６と希望車種の列５０８と発注済フラグの列５１０とが含まれている。レコードはユーザからの部品注文があった際に中古部品流通サーバ５の発注受付部５１によって生成される。また、レコードは自動生成される発注番号の列５００の値によって一意に特定される。なお、１つのレコードの部品番号の列５０２には１つの部品番号のみが登録されるようになっている。

連絡先の列５０６には、発注者であるユーザに通知を行う際に宛先とするメール・アドレスが登録されている。また、希望車種の列５０８には、特定の車種の部品をユーザが希望する場合に、車種名が登録される。車種番号の場合もある。発注済フラグの列５１０には、当該部品注文に対して販売者が割り当てられると「○」が登録される。すなわち、発注済フラグの列５１０に「○」が登録されていないレコードは、部品の注文に対して未だ販売者の割り当て及び販売者に対する発注処理がなされていないということを示している。

図６に、ニーズ登録表格納部５４に格納されるニーズ登録表の構成及び格納されるデータの一例を示す。図６の例には、車種番号の列６００と部品番号の列６０２と登録発注番号の列６０４とが含まれている。このニーズ登録表は販売者が所有する車種別にユーザからの部品注文に応じて生成される。図６では、車種番号「Ｓ００１」の車種についての例が示されているが、同様に、異なる車種についてのニーズ登録表も存在し、同じ車種についてのニーズ登録表が複数生成される場合もある。ニーズ登録表生成時には、まず、部品車両ＤＢ５５（図３）に基づき、車種番号の列６００と部品番号の列６０２とに値が登録される。そして、客発注ＤＢ５７（図５）の各レコード（発注済フラグの列５１０の値が「○」であるレコードを除く）の部品番号の列５０２の値と合致する部品番号の列６０２の値を有するニーズ登録表の行を特定する。そして、特定された行の登録発注番号の列６０４に、客発注ＤＢ５７（図５）のレコードの発注番号の列５００の値を登録する。

例えば図５に示した例の１行目のレコードは、部品番号の列５０２の値が「Ｂ００１」である。従って、この「Ｂ００１」を用いてニーズ登録表を検索する。図６に示した例では、１行目の部品番号の列６０２の値が「Ｂ００１」であるため、１行目が特定される。そして、ニーズ登録表の１行目の登録発注番号の列６０４に、客発注ＤＢ５７（図５）の１行目の発注番号の列５００の値である「Ｈ００１」が登録される。なお、異なる車種についてのニーズ登録表に、部品番号の列６０２の値が「Ｂ００１」である行が存在する場合には、その行の登録発注番号の列６０４にも「Ｈ００１」と登録される。ニーズ登録表は、供給可能な部品に対する需要を仮予約データとして登録する一時的な表であるため、このような重複登録を許可している。

このようにして、ニーズ登録表の登録発注番号の列６０４に値が登録されていく。なお、ニーズ登録表の登録発注番号の列６０４に、既に値が登録されている場合には、新たなニーズ登録表が生成され、当該新たなニーズ登録表の登録発注番号の列６０４に、値が登録される。

図７に、商品ＤＢ７１のテーブル構成及び格納されるデータの一例を示す。なお、商品ＤＢは販売者毎に設けられるＤＢであり、商品ＤＢ９１及び商品ＤＢ１１１も同様のテーブル構成である。図７の例には、車種番号の列７００と製造番号の列７０２と解体日の列７０４とが含まれている。製造番号の列７０２には、車両を一意に特定可能な製造番号が登録されている。販売者が独自にユニークな番号を付与する場合もある。解体日の列７０４には、車両の解体予定日が決定すると、その日付が登録される。

図８に、部品価格ＤＢ７２のテーブル構成及び格納されるデータの一例を示す。なお、部品価格ＤＢは、販売者毎に設けられるＤＢであり、部品価格ＤＢ９２及び部品価格ＤＢ１１２も同様のテーブル構成である。図８の例には、部品番号の列８００と価格の列８０２とが含まれている。価格の列８０２には、販売者が独自に設定した部品の価格が登録されている。

次に、図９乃至図１２を用いて、図１に示したシステムの処理内容について説明する。ここで、図９に示した処理フローの前提処理について説明する。まず、ユーザ端末３の表示画面には、ユーザ端末３のＷｅｂブラウザと、Ｗｅｂサーバ機能を有する中古部品流通サーバ５の発注受付部５１との処理によって、注文データ入力用のページが表示されているものとする。システムを利用する際にログインが必要な場合にはログイン処理もなされているものとする。そして、ユーザ端末３のＷｅｂブラウザは、注文者であるユーザからの注文入力を受け付ける。図示しないが、例えば表示されているページに含まれるテキストボックスや注文ボタン等によって注文データの入力及びデータ送信要求を受け付ける。そして、ユーザ端末３は、入力された注文データを中古部品流通サーバ５に送信する。送信される注文データには、部品番号、注文者氏名及び連絡先メール・アドレスが含まれる。また、希望車種の指定があれば希望車種の名称も含まれる。以下、図９に示した処理ステップに従い説明する。

中古部品流通サーバ５の発注受付部５１は、注文データをユーザ端末３から受信し、注文データに基づき客発注ＤＢ５７のレコードを生成して客発注ＤＢ５７（図５）に格納する（図９：ステップＳ１）。発注番号の列５００には自動生成したユニークな値を登録し、発注済フラグの列５１０には、値を登録しない又は「−」と登録する。そして、発注受付部５１は、所定の期間が経過したか判定する（ステップＳ３）。所定期間が経過していないと判定された場合（ステップＳ３：Ｎｏルート）、ステップＳ１の処理に戻り、次の注文を受け付ける。一方、所定期間が経過したと判定された場合（ステップＳ３：Ｙｅｓルート）、中古部品流通サーバ５の引当処理部５３は、客発注ＤＢ５７から未処理のレコードを１件抽出する（ステップＳ５）。未処理のレコードとは、発注済フラグの列５１０の値が「○」ではないレコードである。そして、当該未処理のレコードについて、車種の指定があるか判定する（ステップＳ７）。希望車種の列５０８に車種名又は車種番号が登録されている場合には、車種の指定があると判定される。車種の指定があると判定されなかった場合（ステップＳ７：Ｎｏルート）、処理は端子Ａを介して図１０の処理に移行する。

一方、車種の指定があると判定された場合（ステップＳ７：Ｙｅｓルート）、引当処理部５３は、販売者ＤＢ５６（図４）を参照し、指定された車種の車両をいずれかの販売者が所有しているか判定する（ステップＳ９）。具体的には所有車種の列４０６の値をチェックする。なお、希望車種の列５０８に車種番号ではなく車種名を登録するようにしている場合には、部品車両ＤＢ５５（図３）に基づき車種番号を特定してから販売者ＤＢ５６を参照する。

販売者ＤＢ５６に指定車種がなかったと判定された場合（ステップＳ９：Ｎｏルート）、引当処理部５３は、注文者宛てに「希望部品なし」及び「互換部品を有する他の車種に変更可能か」という旨の通知を送信する（ステップＳ１１）。例えば「ご希望の部品はありませんでした。ご希望の部品と互換性のある、他の車種の部品でもよろしいでしょうか？」というメッセージを、客発注ＤＢ５７において現在処理中であるレコードの連絡先の列５０６（図５）に登録されているメール・アドレスに送信する。さらに、引当処理部５３は、全ての販売者宛てに、リクエスト・データを送信する（ステップＳ１３）。例えば「車種番号Ｓ００１、部品番号Ｂ００２につき、注文がありました。」というメッセージを、販売者ＤＢ５６の連絡先の列４０４（図４）に登録されている全てのメール・アドレスに送信する。そして、後に述べるステップＳ２１の処理に移行する。

一方、販売者ＤＢ５６に指定車種があったと判定された場合（ステップＳ９：Ｙｅｓルート）、中古部品流通サーバ５のニーズ登録表管理部５２は、ニーズ登録表更新処理を行う（ステップＳ１５）。ニーズ登録表更新処理の詳細については後述するが、特定の車種についてのニーズ登録表の登録発注番号の列６０４（図６）に値を登録することにより、ニーズ登録表を更新する。ここでは、ユーザにより指定された車種について、ニーズ登録表更新処理を行う。

ニーズ登録表更新処理が終了すると、引当処理部５３は、ユーザに指定された車種に対応する全ての部品番号について仮予約データが登録されたか判定する（ステップＳ１７）。すなわち、ニーズ登録表の登録発注番号の列６０４の値が全て登録されたかチェックする。全ての部品番号について仮予約データが登録されたと判定されなかった場合（ステップＳ１７：Ｎｏルート）、後に述べるステップＳ２１の処理に移行する。一方、全ての部品番号について仮予約データが登録されたと判定された場合（ステップＳ１７：Ｙｅｓルート）、引当処理部５３は、販売者引当処理を行う（ステップＳ１９）。販売者引当処理の詳細については後述する。

そして、引当処理部５３は、未処理のレコード全てについての処理が終了したか判定する（ステップＳ２１）。未処理のレコード全てについての処理が終了したと判定されなかった場合（ステップＳ２１：Ｎｏルート）、ステップＳ５の処理に戻り、次の未処理レコードを抽出する。一方、未処理のレコード全てについての処理が終了したと判定された場合（ステップＳ２１：Ｙｅｓルート）、引当処理部５３は、ニーズ登録表格納部５４に格納されている全てのニーズ登録表を参照し、所定割合以上の部品について仮予約データが登録されている車種があるか判定する（ステップＳ２３）。例えば、登録発注番号６０４の値が登録済みである部品の数が、当該車種に対応する部品の総数の例えば８割以上となる車種があるか判定する。また例えば、登録発注番号６０４の値が登録済みである部品の合計価格（例えば各販売者における価格の平均値）が、当該車種に対応する部品の総価格（例えば各販売者における価格の平均値）の例えば８割以上となる車種があるか判定するようにしてもよい。また例えば、部品毎に所定のポイントを対応付けておき、登録発注番号６０４の値が登録済みである部品の合計ポイントが、当該車種に対応する部品の総ポイントの例えば８割以上となる車種があるか判定するようにしてもよい。

所定割合以上の部品について仮予約データが登録されている車種があると判定されなかった場合（ステップＳ２３：Ｎｏルート）、中古部品流通サーバ５における一連の処理を終了する。一方、所定割合以上の部品について仮予約データが登録されている車種があると判定された場合（ステップＳ２３：Ｙｅｓルート）、引当処理部５３は、販売者引当処理を行う（ステップＳ２５）。販売者引当処理の詳細については後述する。ステップＳ２５の販売者引当処理が終了すると、中古部品流通サーバ５における一連の処理を終了する。

このように、所定期間内に受け付けた注文データに基づき、需要と供給の突合せが行われる。

図１０に、端子Ａを介して移行した後の処理フローを示す。まず、中古部品流通サーバ５の引当処理部５３は、部品車両ＤＢ５５を参照し、ユーザが希望する部品（注文部品）を有する車種を抽出する（図１０：ステップＳ３１）。具体的には、客発注ＤＢ５７において現在処理中であるレコードの部品番号の列５０２（図５）の値を特定し、特定された値（部品番号）と合致する、部品搭載番号３０４（図３）の値を有する車種番号を抽出する。例えば部品番号５０２の値が「Ｂ００１」であった場合、図３に示した例では、部品搭載番号の列３０４の１行目及び８行目の値が「Ｂ００１」であることから、車種番号の「Ｓ００１」及び「Ｓ００２」が抽出される。

そして、引当処理部５３は、販売者ＤＢ５６（図４）を参照し、抽出された車種（注文部品を有する車種）をいずれかの販売者が所有しているか判定する（ステップＳ３３）。販売者ＤＢ５６に、注文部品を有する車種（以下、互換車種と呼ぶ）がなかったと判定された場合（ステップＳ３３：Ｎｏルート）、引当処理部５３は、注文者宛てに「該当部品なし」という旨の通知を送信する（ステップＳ３５）。例えば「現在、ご希望の部品は品切れ状態となっております。」というメッセージを、客発注ＤＢ５７における現在処理中であるレコードの連絡先の列５０６（図５）に登録されているメール・アドレスに送信する。さらに、引当処理部５３は、全ての販売者宛てに、リクエスト・データを送信する（ステップＳ３７）。例えば「部品番号Ｂ００１につき、注文がありました。」というメッセージを、販売者ＤＢ５６の連絡先の列４０４（図４）に登録されている全てのメール・アドレスに送信する。そして、処理は端子Ｃを介してステップＳ２１（図９）の処理に移行する。

一方、販売者ＤＢ５６に、互換車種があったと判定された場合（ステップＳ３３：Ｙｅｓルート）、引当処理部５３は、互換車種のうち１件を特定する（ステップＳ３９）。そして、ニーズ登録表管理部５２は、特定された互換車種についてニーズ登録表更新処理を行う（ステップＳ４１）。ニーズ登録表更新処理の詳細については後述する。ニーズ登録表更新処理が終了すると、引当処理部５３は、特定された互換車種に対応する全ての部品番号について仮予約データが登録されたか判定する（ステップＳ４３）。すなわち、ニーズ登録表の登録発注番号の列６０４の値が全て登録されたかチェックする。全ての部品番号について仮予約データが登録されたと判定された場合（ステップＳ４３：Ｙｅｓルート）、引当処理部５３は、販売者引当処理を行う（ステップＳ４５）。販売者引当処理の詳細については後述する。そして、処理は端子Ｃを介してステップＳ２１（図９）の処理に移行する。一方、全ての部品番号について仮予約データが登録されたと判定されなかった場合（ステップＳ４３：Ｎｏルート）、引当処理部５３は、全ての互換車種についての処理が終了したか判定する（ステップＳ４７）。全ての互換車種についての処理が終了したと判定されなかった場合（ステップＳ４７：Ｎｏルート）、処理はステップＳ３９に戻り、次の互換車種が１件特定される。一方、全ての互換車種についての処理が終了したと判定された場合（ステップＳ４７：Ｙｅｓルート）、処理は端子Ｃを介してステップＳ２１（図９）の処理に移行する。

このようにして、ユーザから車種が指定されなかった場合の処理が行われる。

図１１を用いて、ニーズ登録表更新処理（ステップＳ１５（図９）及びステップＳ４１（図１０））の詳細について説明する。まず、ニーズ登録表更新処理の前提として、車種及びユーザの希望（注文）部品が１件ずつ特定されている。そして、中古部品流通サーバ５のニーズ登録表管理部５２は、ニーズ登録表格納部５４を参照し、特定されている車種についてのニーズ登録表が存在するか判定する（図１１：ステップＳ５１）。特定されている車種についてのニーズ登録表が存在しないと判定された場合（ステップＳ５１：Ｎｏルート）、後に述べるステップＳ５５の処理に移行する。一方、特定されている車種についてのニーズ登録表が存在すると判定された場合（ステップＳ５１：Ｙｅｓルート）、ニーズ登録表管理部５２は、当該ニーズ登録表において、ユーザの希望部品に対応する登録発注番号の列６０４の値が既に登録済みであるか判定する（ステップＳ５３）。すなわち、他の注文により、ユーザの希望部品に対して既に仮予約がなされてしまっているか確認する。ユーザの希望部品に対応する登録発注番号の列６０４の値が既に登録済みであると判定された場合（ステップＳ５３：Ｙｅｓルート）、ニーズ登録表管理部５２は、新たにニーズ登録表を生成し、該当する部品の行の登録発注番号の列６０４に値（客発注ＤＢ５７の発注番号の列５００の値）を登録する（ステップＳ５５）。新たなニーズ登録表は、特定されている車種番号及び部品車両ＤＢ５５（図３）に格納されているデータに基づき、車種番号の列６００と部品番号の列６０２（図６）とに値が登録され、且つ登録発注番号の列６０４には値が登録されない又は「−」が登録された状態で生成される。そして、元の処理に戻る。一方、ユーザの希望部品に対応する登録発注番号の列６０４の値が未だ登録済みではないと判定された場合（ステップＳ５３：Ｎｏルート）、ニーズ登録表管理部５２は、当該ニーズ登録表の該当する部品の行の登録発注番号の列６０４に値（客発注ＤＢ５７の発注番号の列５００の値）を登録することにより、ニーズ登録表を更新する（ステップＳ５７）。そして元の処理に戻る。

このようにして、ニーズ登録表更新処理が行われ、ユーザの希望部品について、仮予約データが登録される。

図１２を用いて、販売者引当処理（ステップＳ１９（図９）、ステップＳ２５（図９）及びステップＳ４５（図１０））の詳細について説明する。まず、中古部品流通サーバ５の引当処理部５３は、現時点において特定されている車種が１種類であるか判定する（図１２：ステップＳ７１）。ステップＳ１９（図９）及びステップＳ４５（図１０）における販売者引当処理は、特定されている車種が１種類の状態で開始され、ステップＳ２５（図９）における販売者引当処理は、特定されている車種が１又は複数種類の状態で開始される。

特定されている車種が１種類であると判定された場合（ステップＳ７１：Ｙｅｓルート）、後に述べるステップＳ７９の処理に移行する。この際、販売者引当処理の直前のステップ（ステップＳ１７（図９）、ステップＳ２３（図９）又はステップＳ４３（図１０））の判定条件を満たすニーズ登録表を特定しておく。なお、ステップＳ２５（図９）における販売者引当処理の場合、特定されている車種が１種類であっても、当該車種について、ステップＳ２３（図９）の判定条件を満たす複数のニーズ登録表が存在する場合がある。そのような場合、例えば最も早く生成されたニーズ登録表を特定しておく。

一方、特定されている車種が１種類ではないと判定された場合（ステップＳ７１：Ｎｏルート）、引当処理部５３は、希望車種としてユーザから指定されている車種があるか判定する（ステップＳ７３）。具体的には、ニーズ登録表の各行について登録発注番号の列６０４（図６）の値に基づき客発注ＤＢ５７（図５）を参照し、希望車種の列５０８に車種名が登録されているかチェックする。

希望車種としてユーザから指定されている車種があると判定された場合（ステップＳ７３：Ｙｅｓルート）、引当処理部５３は、最も多く希望指定されている車種のニーズ登録表を１件特定する（ステップＳ７５）。最も多く希望指定されている車種について複数のニーズ登録表がある場合には、例えば最も早く生成されたニーズ登録表を特定する。そして、後に述べるステップＳ７９の処理に移行する。一方、希望車種としてユーザから指定されている車種がないと判定された場合（ステップＳ７３：Ｎｏルート）、引当処理部５３は、最も多く販売者が車両を有している車種についてのニーズ登録表を１件特定する（ステップＳ７７）。図４に示した例のように販売者ＤＢ５６に車両台数のデータが含まれていない場合には、引当処理部５３は、各販売者サーバの商品ＤＢを参照して台数データを取得する。各販売者サーバに問い合わせるような場合もある。また、最も多く販売者が車両を有している車種について複数のニーズ登録表がある場合には、例えば最も早く生成されたニーズ登録表を特定する。

そして、引当処理部５３は、特定されたニーズ登録表に対応する車種を所有する販売者が複数存在するか判定する（ステップＳ７９）。販売者ＤＢ５６の所有車種の列４０６（図４）を参照して判定する。特定されたニーズ登録表に対応する車種を所有する販売者が複数存在しないと判定された場合（ステップＳ７９：Ｎｏルート）、すなわち、販売者を１人又は１業者に絞り込めた場合、引当処理部５３は、当該販売者宛てに発注通知を送信する（ステップＳ８１）。販売者に対する通知は、例えば上で述べたようにメールを用いて行えばよい。具体的には、特定されているニーズ登録表に基づき、車種及び注文部品の番号等を含む通知データを生成し、送信する。そして、後に述べるステップＳ９１の処理に移行する。

一方、特定されたニーズ登録表に対応する車種を所有する販売者が複数存在すると判定された場合（ステップＳ７９：Ｙｅｓルート）、引当処理部５３は、解体予定日が決定している車両があるか判定する（ステップＳ８３）。具体的には、各販売者サーバの商品ＤＢを参照して、特定されている車種に該当する車両の解体日データ（解体日の列７０４（図７）の値）を取得する。各販売者サーバに問い合わせるような場合もある。解体予定日が決定している車両があると判定された場合（ステップＳ８３：Ｙｅｓルート）、引当処理部５３は、解体予定日が最も早い車両を有する販売者宛てに発注通知を送信する（ステップＳ８５）。そして、後に述べるステップＳ９１の処理に移行する。

一方、解体予定日が決定している車両がないと判定された場合（ステップＳ８３：Ｎｏルート）、引当処理部５３は、特定されているニーズ登録表における仮予約済みの（登録発注番号の列６０４（図６）に発注番号が登録されている）部品番号に基づき、各販売者サーバの部品価格ＤＢを検索する（ステップＳ８７）。各販売者サーバに問い合わせるような場合もある。そして、引当処理部５３は、仮予約済みである部品の合計価格が最も安い販売者を特定し、当該販売者宛てに発注通知を送信する（ステップＳ８９）。

そして、引当処理部５３は、客発注ＤＢ５７（図５）に格納されているレコードのうち、発注通知がなされた注文データに該当するレコードにおいて、発注済フラグの列５１０に「○」を登録する。さらに、引当処理部５３は、ニーズ登録表を全てクリアする（ステップＳ９３）。そして元の処理に戻る。

このようにして、販売者引当処理が行われる。これにより、注文（予約）状況に応じて適切な販売者を特定することができる。

以上、図９乃至図１２を用いて説明したように処理を実行することにより、需要に応じた適切な部品流通を行うことが可能となる。なお、本実施の形態においては、ステップＳ９３（図１２）においてニーズ登録表を全てクリアするため、例えばステップＳ２３（図９）の条件を満たすニーズ登録表が複数存在した場合にも、一旦全てクリアするようになっている。そのため、ステップＳ２３（図９）の条件を満たすニーズ登録表が複数存在した場合、所定期間の経過後（ステップＳ３（図９）参照）、再度ニーズ登録表が生成されて当該ニーズ登録表に基づく処理が実行される。そこで、ステップＳ２３（図９）の条件を満たすニーズ登録表が複数存在した場合には、ステップＳ２５（図９）における販売者引当処理の後、ステップＳ５（図９）に戻るようにしてもよい。同様に、ステップＳ２３（図９）の条件を満たすニーズ登録表が複数存在した場合には、ステップＳ９３（図１２）において全てのニーズ登録表をクリアするのではなく、発注処理済みのニーズ登録表及び当該ニーズ登録表と重複して他のニーズ登録表に登録されていた仮予約データのみをクリアしておき、ステップＳ２３（図９）に戻るようにしてもよい。

また、例えば１週間や１ヶ月等、比較的長期間において発注処理がなされない注文データを別途抽出し、全販売者又は注文部品を取り出し可能な車両を有する販売者にリクエスト・データを通知するようにしてもよい。この場合、客発注ＤＢ５７（図５）に、注文日等の項目を設けておくようにする。

以上本発明の一実施の形態について説明したが、本発明はこれに限定されるものではない。例えば、図３乃至図８に示したテーブル構成は一例であって、同様のデータを格納するためであれば別の構成を採用するようにしてもよいし、必要に応じて項目を追加又は削除してもよい。また、図１に示した中古部品流通サーバ５の機能ブロック構成は一例であって、実際のプログラム・モジュール構成とは異なる場合がある。また、各装置が複数のサーバやコンピュータによって構成されていてもよい。また、図２に示したコンピュータの機能ブロック図も一例であって、実際のハードウェア構成とは異なる場合もある。また図９乃至図１２に示した処理フローも一例であって、同様の処理結果が得られる範囲において処理の順序を入れ替えてもよいし、必要に応じてステップを追加又は削除してもよい。

なお、車両の中古部品に適用した例を用いて実施の形態を説明したが、例えばパーソナル・コンピュータの部品等、本発明に係る技術を他の様々な部品流通システムに応用することも可能である。

（付記１）
車両を解体することにより取り出される部品を流通させるための部品流通プログラムであって、
ユーザからの部品注文データが格納されている注文データ格納部を参照し、未発注の部品注文データを特定し、記憶装置に格納するステップと、
前記未発注の部品注文データから特定される未発注の部品と、予め部品車両データ格納部に格納されている、車種と当該車種の車両を解体することにより取り出し可能な車両解体部品との関連データとを用いて、前記未発注の部品に対応する車両解体部品の、全体に対する割合が所定の閾値以上である車種を特定し、優先解体車種として前記記憶装置に格納する優先解体車種特定ステップと、
をコンピュータに実行させる部品流通プログラム。

（付記２）
前記優先解体車種特定ステップが、
解体業者が所有する車両に関するデータが格納されている在庫車両データ格納部に、前記未発注の部品に対応する車両解体部品を取り出し可能な解体候補車両についてのデータが登録されているか判定する在庫確認ステップと、
前記在庫確認ステップにおいて前記解体候補車両についてのデータが登録されていると判定された場合、前記未発注の部品に対応する車両解体部品の仮予約データを、前記解体候補車両から特定される車種別に生成されるニーズ登録テーブルに登録する仮予約ステップとを含み、
前記ニーズ登録テーブルに登録されたデータに基づき、前記未発注の部品に対応する車両解体部品の、全体に対する割合を算出することを特徴とする
付記１記載の部品流通プログラム。

（付記３）
前記在庫確認ステップにおいて、
前記未発注の部品注文データに特定の車種を指定するデータが含まれていた場合、当該特定の車種の車両であって且つ前記未発注の部品に対応する車両解体部品を取り出し可能な解体候補車両についてのデータが登録されているか判定することを特徴とする
付記２記載の部品流通プログラム。

（付記４）
前記仮予約ステップにおいて、
前記解体候補車両に対応する車種が複数存在する場合、該当する全ての車種のニーズ登録テーブルについて、前記仮予約データを登録することを特徴とする
付記２記載の部品流通プログラム。

（付記５）
前記仮予約ステップにおいて、
前記未発注の部品注文データに特定の車種を指定するデータが含まれていた場合、当該特定の車種のニーズ登録テーブルについて、前記仮予約データを登録することを特徴とする
付記２記載の部品流通プログラム。

（付記６）
前記仮予約ステップにおいて、
特定の車種の車両解体部品に対応する、前記未発注の部品が複数存在する場合、当該特定の車種についての複数のニーズ登録テーブルに前記仮予約データを登録することを特徴とする
付記２記載の部品流通プログラム。

（付記７）
前記優先解体車種特定ステップが、
前記在庫確認ステップにおいて前記解体候補車両についてのデータが未登録であると判定された場合、前記未発注の部品に関するデータを解体業者に送信するステップ
をさらに含む付記２記載の部品流通プログラム。

（付記８）
解体業者が所有する車両に関するデータが格納されている在庫車両データ格納部を参照し、前記記憶装置に格納された優先解体車種に対応する車両を所有する解体業者を特定し、前記未発注の部品と当該解体業者とを対応付けて発注データとして発注データ格納部に格納する解体業者決定ステップ
をさらにコンピュータに実行させる、付記１記載の部品流通プログラム。

（付記９）
前記解体業者決定ステップが、
前記優先解体車種が複数存在する場合、前記未発注の部品注文データに含まれ且つ特定の車種の指定に関するデータと、解体業者が所有する車両に関するデータが格納されている在庫車両データ格納部を参照することにより特定される、車種別の在庫車両台数との少なくともいずれかに基づき、１種類の車種を特定するステップ
を含む付記８記載の部品流通プログラム。

（付記１０）
前記解体業者決定ステップが、
前記記憶装置に格納された優先解体車種に対応する車両を所有する解体業者が複数存在する場合、解体業者が所有する車両に関するデータが格納されている在庫車両データ格納部を参照することにより特定される、車両の解体予定日と、部品価格格納部に格納されている解体業者毎の部品価格データに基づき算出される、合計発注価格との少なくともいずれかに基づき、１の解体業者を特定するステップ
を含む付記８記載の部品流通プログラム。

（付記１１）
車両を解体することにより取り出される部品を流通させるための部品流通方法であって、
ユーザからの部品注文データが格納されている注文データ格納部を参照し、未発注の部品注文データを特定し、記憶装置に格納するステップと、
前記未発注の部品注文データから特定される未発注の部品と、予め部品車両データ格納部に格納されている、車種と当該車種の車両を解体することにより取り出し可能な車両解体部品との関連データとを用いて、前記未発注の部品に対応する車両解体部品の、全体に対する割合が所定の閾値以上である車種を特定し、優先解体車種として前記記憶装置に格納するステップと、
を含み、コンピュータにより実行される部品流通方法。

（付記１２）
車両を解体することにより取り出される部品を流通させるための部品流通装置であって、
ユーザからの部品注文データが格納されている注文データ格納部を参照し、未発注の部品注文データを特定し、記憶装置に格納する手段と、
前記未発注の部品注文データから特定される未発注の部品と、予め部品車両データ格納部に格納されている、車種と当該車種の車両を解体することにより取り出し可能な車両解体部品との関連データとを用いて、前記未発注の部品に対応する車両解体部品の、全体に対する割合が所定の閾値以上である車種を特定し、優先解体車種として前記記憶装置に格納する手段と、
を有する部品流通装置。

本発明の一実施の形態におけるシステム構成図である。本発明の実施の形態におけるコンピュータの機能ブロックの概要を示す図である。部品車両ＤＢテーブルの一例を示す図である。販売者ＤＢテーブルの一例を示す図である。客発注ＤＢテーブルの一例を示す図である。ニーズ登録表の一例を示す図である。商品ＤＢテーブルの一例を示す図である。部品価格ＤＢテーブルの一例を示す図である。本発明の一実施の形態における処理フローの第１の部分を示す図である。本発明の一実施の形態における処理フローの第２の部分を示す図である。ニーズ登録表更新処理の処理フローを示す図である。販売者引当処理の処理フローを示す図である。

符号の説明

１ネットワーク３ユーザ端末
５中古部品流通サーバ７Ａ販売者サーバ
９Ｂ販売者サーバ１１Ｃ販売者サーバ
５１発注受付部５２ニーズ登録表管理部
５３引当処理部５４ニーズ登録表格納部
５５部品車両ＤＢ５６販売者ＤＢ
５７客発注ＤＢ
７１，９１，１１１商品ＤＢ
７２，９２，１１２部品価格ＤＢ

Claims

車両を解体することにより取り出される部品を流通させるための部品流通プログラムであって、
コンピュータを、
注文に係る部品のデータを格納する客発注データベースに格納されている未処理の注文を、車両から取り出し可能な車両解体部品のデータが車種毎に格納されているニーズ登録表格納部において当該未処理の注文に係る部品に対応する車両解体部品に関連付けて登録する手段と、
前記ニーズ登録表格納部から、１車種の前記車両解体部品の総数に対する前記注文が関連付けられている前記車両解体部品の数の割合が所定値以上である車種を特定し、特定された前記車種のデータで、販売者のデータと当該販売者が所有する車両の車種のデータとが対応付けて格納されている販売者データベースを検索し、特定された前記車種の車両を所有する販売者を特定する引当処理部
として機能させることを特徴とする部品流通プログラム。
車両を解体することにより取り出される部品を流通させるための部品流通プログラムであって、
コンピュータを、
注文に係る部品のデータを格納する客発注データベースに格納されている未処理の注文を、車両から取り出し可能な車両解体部品のデータが車種毎に格納されているニーズ登録表格納部において当該未処理の注文に係る部品に対応する車両解体部品に関連付けて登録する手段と、
前記ニーズ登録票格納部において前記注文が関連付けられている前記車両解体部品を有する車種について、部品のデータと当該部品の価格とが対応付けて格納されている部品価格データベースから各前記車両解体部品の価格を抽出し、１車種の前記車両解体部品の総価格に対する前記注文が関連付けられている前記車両解体部品の合計価格の割合が所定値以上である車種を特定し、特定された前記車種のデータで、販売者のデータと当該販売者が所有する車両の車種のデータとが対応付けて格納されている販売者データベースを検索し、特定された前記車種の車両を所有する販売者を特定する引当処理部
として機能させることを特徴とする部品流通プログラム。
特定された前記販売者が複数である場合、特定された前記車種のデータで、車種のデータと当該車種の車両の解体日のデータとが対応付けて格納されている商品データベースを検索し、特定された前記車種の車両の解体日のデータを各前記販売者について特定し、複数の前記販売者の中から解体日が最も早い販売者を特定するように前記引当処理部を機能させる
ことを特徴とする請求項１又は２記載の部品流通プログラム。
車両を解体することにより取り出される部品を流通させるための部品流通方法であって、
コンピュータが、
注文に係る部品のデータを格納する客発注データベースに格納されている未処理の注文を、車両から取り出し可能な車両解体部品のデータが車種毎に格納されているニーズ登録表格納部において当該未処理の注文に係る部品に対応する車両解体部品に関連付けて登録するステップと、
前記ニーズ登録表格納部から、１車種の前記車両解体部品の総数に対する前記注文が関連付けられている前記車両解体部品の数の割合が所定値以上である車種を特定するステップと、
特定された前記車種のデータで、販売者のデータと当該販売者が所有する車両の車種のデータとが対応付けて格納されている販売者データベースを検索し、特定された前記車種の車両を所有する販売者を特定する引当ステップと、
を実行することを特徴とする部品流通方法。
車両を解体することにより取り出される部品を流通させるための部品流通方法であって、
コンピュータが、
注文に係る部品のデータを格納する客発注データベースに格納されている未処理の注文を、車両から取り出し可能な車両解体部品のデータが車種毎に格納されているニーズ登録表格納部において当該未処理の注文に係る部品に対応する車両解体部品に関連付けて登録するステップと、
前記ニーズ登録票格納部において前記注文が関連付けられている前記車両解体部品を有する車種について、部品のデータと当該部品の価格とが対応付けて格納されている部品価格データベースから各前記車両解体部品の価格を抽出し、１車種の前記車両解体部品の総価格に対する前記注文が関連付けられている前記車両解体部品の合計価格の割合が所定値以上である車種を特定するステップと、
特定された前記車種のデータで、販売者のデータと当該販売者が所有する車両の車種のデータとが対応付けて格納されている販売者データベースを検索し、特定された前記車種の車両を所有する販売者を特定する引当ステップと、
を実行することを特徴とする部品流通方法。