(57)【要約】      （修正有）【課題】リモートから製品の各ユニットの品質レベルを判別し、確実な情報を基にかつ早期に在庫情報を更新することを可能にすることで、リサイクル部品を用いた製品の在庫管理費用や部品調達費用の削減を達成することのできるリユニット支援システムを提供する。【解決手段】製品１１０と在庫管理サーバ１３０とアプリケーションサーバがネットワーク１２０を介して互いに接続されており通信可能なシステムで、製品回収時にアプリケーションサーバからユニット検査用のプログラムをダウンロードしてユニット毎の品質を判断し、ユニット毎の品質レベルを在庫管理サーバ１３０へ送信する。在庫管理サーバ１３０は、受信した情報で在庫管理情報を更新し、部品の発注を行う際に参照する。【選択図】図１
2006172078.tif 000002
【特許請求の範囲】
【請求項１】
複数のユニットで構成されている製品と、ユニットやパーツの在庫管理サーバがネットワークを介して相互に情報をやりとりできるリユニット支援システムであって、
前記製品を回収するタイミングに前記製品の前記複数のユニットの品質レベルをそれぞれ製品側で判別する判別手段と、
前記判別手段により判別された結果を前記ネットワークを介して前記在庫管理サーバへ送信する手段と、
前記在庫管理サーバが前記判別結果に応じてユニットやパーツの在庫情報を更新する手段と、を有することを特徴とするリユニット支援システム。
【請求項２】
請求項１に記載のリユニット支援システムにおいて、
前記製品が前記判別手段として用いるプログラムまたは情報を前記ネットワークを介してダウンロードするダウンロード手段と、
前記製品がダウンロードしたプログラムまたは情報を実行する手段と
を有することを特徴とするリユニット支援システム。
【請求項３】
請求項１に記載のリユニット支援システムにおいて、
前記判断手段として、機器の動作テストを行いその結果を判断材料として用いることを特徴とするリユニット支援システム。
【請求項４】
請求項１に記載のリユニット支援システムにおいて、
回収した製品を工場側で再度検査した後、前記検査結果に応じて、前記在庫データベースの情報を補正するために再度更新する再更新手段を有することを特徴とするリユニット支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パソコン、複写機、プリンターのように複数のユニットから構成され、ネットワークを介して通信可能な製品のリユニット支援システムに関する。
【背景技術】
【０００２】
近年、多くの電子機器がインターネットに接続できるようになり、遠隔地にあるサーバと情報のやり取りが可能になっている。そして、多くの電子機器がインターネットに接続され、その情報を収集するようになるにつれ、情報の収集や管理を行うサーバ側の負荷が増加し過ぎないように機器側である程度の処理を行う仕組みが求められている。
【０００３】
また、コンピュータの世界は、変化が速く、数年前のソフトウエアやシステムが現状にそぐわないものになってしまうという問題もある。サーバ側のソフトウエアであれば、ソフトウエアの更新を比較的容易に行うことができるが、クライアント側の機器に組み込まれているソフトウエアの更新は、従来容易に行うことが出来なかった。
【０００４】
このような問題に対して、Ｊａｖａ（登録商標）バーチャルマシンのようにダウンロードしてきたプログラムを機器側で容易に実行できる仕組みや、ＸＭＬのように構造化されたデータをやりとりすることでシステムの振る舞いを変更するような技術が提案され、一般的になってきている。
【０００５】
また、地球環境問題への関心の高まり、法規制、企業イメージの向上の観点から、従来は顧客先で使用後に廃棄されていた製品をリサイクル、リユース、リユニット、リパーツしようという機運が高まりつつある。
【０００６】
ここで、リサイクルとは、製品を回収し最悪材料レベルまで製品を戻し、次の製品として再利用することである。材料レベルまで戻すので、前記３つの再利用方法の中では最もエネルギーを消費する。
【０００７】
リユースとは、材料レベルまで製品を戻すことなく再利用することである。本発明では、回収製品を簡単なメンテナンスのみで中古製品として市場に還流させる場合に製品のリユースという言葉を用いる。製品のリユースは、回収製品がリユース可能な場合は、前記３つの再利用方法の中で最もエネルギー効率が良い。しかし、ユーザーが回収を要求するような電子機器は、機能や性能が悪く中古品として市場に出しても製品価値が乏しい場合や故障しているユニットがあるために廃棄されてしまう場合もあり、より再生時の廃棄量を削減するためには、パーツやユニットレベルでの再利用を組み合わせて用いる必要がある。
【０００８】
リユニットとは、複数のパーツからなり、ある機能を実現するユニットの単位で再利用を行うことである。例えば、複写機のスキャナ部、ハードディスクなどは、それぞれ複数のパーツからなっており、原稿を光学的に読み取る機能や、情報を記憶しておく機能を備えている。パソコン、複写機、プリンターなどは、複数のユニットにて構成されており、一部のユニットが故障した場合は、故障ユニットの交換または故障ユニットの故障パーツの交換を行うことで再び製品としての価値を得る。また、製品自体の市場価値が低下してしまった場合でも、ユニットとしては他の製品に使える場合もあり、この場合は、ユニットの再利用を行う。
【０００９】
リパーツとは、ねじ、ベアリング、ローラなどの部品レベルでの再利用を行うことである。パーツレベルでの再利用は、ユニットを一回分解し、再度組み立てる必要があるので、リユニットよりは、エネルギー効率が悪いが、材料からこれらのパーツを作成するのに比べるとエネルギー効率がよい。
【００１０】
これらの使用済み製品を回収し再利用する逆工程生産においても、従来の生産と同様に部品のＱＣＤ（Ｑ：ｑｕａｒｉｔｙ／ｑｕａｎｔｉｔｙ＝質または量，Ｃ：ｃｏｓｔ＝価格，Ｄ：ｄｅｌｉｖｅｒｙ＝納期）管理が重要である。そして、販売後の製品の情報を取得して逆工程生産におけるＱＣＤ管理をより円滑に行う必要がある。例えば、従来のパーツやユニットの在庫管理は、新規部品に関するものを中心に行われてきたが、今後は回収製品に含まれるパーツやユニットに関しても在庫管理の対象にしていく必要がある。
【００１１】
従来、これらに関して以下の提案がなされてきている。
【００１２】
特許文献１では、家庭にある機器を通信回線を介して使用状況を収集し、機器を中古品として再利用するか廃棄するかを判断する手段が開示されている。しかし、中古製品とするか廃棄するかについてのみ判別が可能で、ユニット単位の再利用を効率よく行うシステムにはなっていない。また、プログラムを動的にダウンロードする機構を備えていないため、出荷後に検査項目が変更になった場合には対応できない。
【００１３】
特許文献２では、顧客とオンライン接続された受注システムにて数量および納期に応じて製造原価が変動する商品の受注システムについて開示している。この公報で明記されているように、製造原価は、数量や納期に応じて変動する。短納期の発注は、一般に高価になる。これを避けるため、数量が正式に決まる前に予測により発注することもある。しかし、予測による発注は多くの不要部品、半製品在庫、製品在庫を抱えてしまう危険がある。そこで、少しでも早い時期に在庫把握の確度を向上させることができれば、製造原価を低下させることが可能となる。
【００１４】
特許文献３では、複数のユニットからなる製品において、予め定められた使用状況になった場合に、その旨をホストに通知し、ホストはその情報を製品のユニット毎にメモリに記憶し管理するリユースシステムに関する技術を開示している。しかし、このシステムは、すべての機器のすべてのユニットを常時監視していることになり、ユニットやパーツのリユースのみに必要な情報を管理するのには、サーバの負荷が多い。また、予め定められた使用状況になったときに情報を送信する仕組みでは、判断基準、判断方法、判断項目が製品出荷後に変更したくなった場合に対応することができない。
【００１５】
特許文献４では、生産、使用、廃棄された製品・部品・原材料すべてを記憶装置に記憶しリサイクルの回収予測と生産計画を設定する技術に関して開示している。しかしながら、ユーザーの機器の使用具合や、設計時の製品毎の寿命のばらつきなどから、予測による生産計画は実際に機器を検査する手法よりも精度が悪くなる。また、すべての情報をサーバで管理する手法はサーバへの負荷が大きい。
【００１６】
特許文献５では、再生した部品を用いて生産する、生成製品の生産を情報通信ネットワークを用いて管理するシステムに関して開示している。このシステムでは、工場に回収した後に初めて、在庫として計上するため、顧客のところに機器がある段階で在庫を把握できる手法よりも、在庫把握の時期が遅れてしまう。
【００１７】
特許文献６では、顧客の受注履歴データおよび統計学的確率分布に基づいて受注数を予測し、在庫数を決定する方法に関して開示している。このような確率的手法は、サンプルが十分では無い場合正しい予測ができない。特に、機器のリサイクルやリユースは、数年に一度しか生じない事象なので顧客の特性に合わせた有効なサンプルを収集することは困難である。
【００１８】
特許文献７では、製品に付加されている情報を読み込み、データベースに記憶し、リサイクルの判定を行うシステムに関して開示している。このシステムでは、リサイクル工場にて製品に付加されている情報を読み込んでいるため、在庫の把握が遅れる。また、製品に付加されている情報のみで判定しているが、動作テストを行うことで判定を行うユニットやパーツに関する記載がない。
【特許文献１】特開平１１−７０３７８号公報
【特許文献２】特開２０００−５７２１４号公報
【特許文献３】特開２００１−３２５５５４号公報
【特許文献４】特開２０００−１８１９５８号公報
【特許文献５】特開２００２−１０８４３２号公報
【特許文献６】特開２００２−２３０１２１号公報
【特許文献７】特開２００２−２５９５５３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１９】
以上のように、上述の方法では、
・製品単位の再利用では廃棄量を削減させることができない。
・調達コストを削減するためにユーザー先に機器がある早期段階でのユニット単位の再利用可否判断と在庫への繰り入れができない。
・リモートから機器の判断を行いサービスマンの訪問回数を減少させることができない。
・適切な情報取得によりサーバの付加を軽減させることができていない。
・製品出荷時に数年後に必要となるリサイクル、リユース、リユニット、リパーツのプログラムを組み込むためソフト開発費がかさむ。
・製品出荷後にリサイクル、リユース、リユニット、リパーツの仕組みや判断基準が変更になった場合に対応ができない。
・メモリに保存してある情報のみから再利用の可否を判断する方法では、動的なテストを行い再利用の可否を判断するようなユニットには対応できない。また、必要メモリ容量が増加してしまう。
・ユーザー先での情報収集による誤差を修正する方法がない。
といった、課題が存在する。
【００２０】
本発明は、上述の問題点に着目してなされたものであって、リモートから製品の各ユニットの品質レベルを判別し、確実な情報を基にかつ早期に在庫情報を更新することを可能にすることで、リサイクル部品を用いた製品の在庫管理費用や部品調達費用の削減を達成することのできるリユニット支援システムを提供することを目的とする。
【課題を解決するための手段】
【００２１】
〔第１の発明〕
本発明の第１の発明に係るリユニット支援システムは、
複数のユニットで構成されている製品と、ユニットやパーツの在庫管理サーバがネットワークを介して相互に情報をやりとりできるリユニット支援システムであって、
前記製品を回収するタイミングに前記製品の前記複数のユニットの品質レベルをそれぞれ製品側で判別する判別手段と、
前記判別手段により判別された結果を前記ネットワークを介して前記在庫管理サーバへ送信する手段と、
前記在庫管理サーバが前記判別結果に応じてユニットやパーツの在庫情報を更新する手段と、を有する。
【００２２】
〔第２の発明〕
本発明の第２の発明に係るリユニット支援システムは、
第１の発明の手段と、
前記製品が前記判別手段として用いるプログラムまたは情報を前記ネットワークを介してダウンロードするダウンロード手段と、
前記製品がダウンロードしたプログラムまたは情報を実行する手段と
を有する。
【００２３】
〔第３の発明〕
本発明の第３の発明に係るリユニット支援システムは、
第１の発明の手段と、
前記判断手段として、機器の動作テストを行いその結果を判断材料として用いる。
【００２４】
〔第４の発明〕
本発明の第４の発明に係るリユニット支援システムは、
第１の発明の手段と、
回収した製品を工場側で再度検査した後、前記検査結果に応じて、前記在庫データベースの情報を補正するために再度更新する再更新手段を有する。
【発明の効果】
【００２５】
・請求項１では、ユニット単位の再利用を行うため、製品単位の再利用よりも廃棄量が減少する。
【００２６】
・請求項１では、ユーザー先に機器がある状態で、ユニットの再利用が可能かどうかの判別が可能なため、在庫把握が早い段階に確実にできる。これにより、調達コストが下がる。
【００２７】
・請求項１では、リモートから判定を行うため、サービスマンが訪問するための人件費を削減することが可能になる。
【００２８】
・請求項１では、製品を回収するタイミングで再利用のための機器診断を行うため、再利用に必要な情報を収集するためにサーバにかかる負荷を軽減することが可能である。また、製品の回収が決定されてから、製品のパーツやユニットが再利用されるまでの間のみ前記情報の管理を行えばよいため、市場にあるすべての製品のすべての情報を管理するのと比較してサーバで管理する情報量を削減することが可能である。
【００２９】
・請求項２では、製品出荷時に将来のリサイクル、リユース、リユニット、リパーツといったことに関するすべてのプログラムを組み込まなくてもよくなるため、プログラムの開発コストを低減させることが可能である。
【００３０】
・請求項２では、製品出荷後にリサイクル、リユース、リユニット、リパーツの仕組みや判断基準が変更になっても、判断が必要な時点に必要なプログラムまたは情報を動的に更新することで、前記変更に対応することが可能である。
【００３１】
・請求項３では、動作テストによる自己診断を行えるユニットに関しては、この結果を用いることで、機器の状態を常時メモリやサーバの記憶装置に蓄えておく必要がなくなる。
【００３２】
・請求項４では、ユーザー先に機器がある状態での検査結果と、回収工場での検査結果をともに在庫サーバの情報に反映させることで、在庫の情報を早い時期から把握できるのとともに、製品が回収工場に回収された時点で、誤差を修正することが可能になる。
【発明を実施するための最良の形態】
【００３３】
以下本発明を実施するための最良の形態を、実施例により詳しく説明する。
【実施例１】
【００３４】
図１は、実施例１におけるシステム図である。
【００３５】
製品１１０はネットワーク１２０を介して在庫管理サーバ１３０と接続されている。
【００３６】
製品１１０はネットワーク１２０を介してデータをやりとりするための通信装置１１１、製品の制御や動作テストプログラムを実行する制御装置１１２、ユニットに係る情報を記憶しておく記憶装置１１３、複数のユニットの例としてユニットＡ１１４、ユニットＢ１１５、ユニットＣ１１６を備えており、それぞれは、制御バス１１７を介して通信を行う。ここで、制御バス１１７は無線でもよい。
【００３７】
在庫管理サーバ１３０は、ネットワーク１２０を介して情報をやりとりするための通信装置１３１、在庫管理サーバの情報を操作する制御装置１３２、在庫情報を記憶する記憶装置１３３を備えており、制御バス１３４を介してこれらの間の情報をやりとりする。
【００３８】
図２は、実施例１におけるフローチャートである。
【００３９】
以下図面では、ステップをＳと略す。
【００４０】
ステップ２０１にてユーザーが回収依頼を行うと、ステップ２０２にて在庫管理サーバはネットワークを介して製品１１０にユニットの品質を判断するように指令する。ステップ２０３にてユニット毎の品質判断指令を受信した製品１１０はユニット毎の品質を判断し、ステップ２０４にて判断結果をサーバへ送信する。ステップ２０５にてユニット毎の品質判断結果を受信した在庫管理サーバ１３０はユニットが再利用可能な場合はステップ２０６を実行し、ユニット在庫を追加する。そして、ステップ２０７の待機状態に至る。ユニットが再利用できない場合はステップ２０７の待機状態になる。ステップ２０５、ステップ２０６、ステップ２０７の一連のステップはユニット毎に行う。ステップ２０７の待機状態で、ユーザーからの新たな回収以来通知を受信した場合は、ステップ２０１からのステップを再度実行する。ステップ２０７の待機状態で、部品発注量の算出をする指令を受けると、ステップ２０８へ進み、在庫情報をもとに部品発注量を算出する。
【００４１】
この実施例の応用としてステップ２０１、ステップ２０２を省略し、ユーザーが回収依頼を行いたいときに、製品の操作部から回収依頼ボタンを押下するとステップ２０３の判断を行い、その結果をサーバへ送信することで回収依頼と結果送信を同時に行うフローも考えられる。
【実施例２】
【００４２】
図３は、実施例２におけるシステム図である。
【００４３】
製品３１０と、在庫管理サーバ３３０と、アプリケーションサーバ３４０はネットワーク３２０を介して接続されている。
【００４４】
製品３１０はネットワーク３２０を介してデータをやりとりするための通信装置３１１、製品の制御や動作テストプログラムを実行する制御装置３１２、ユニットに係る情報を記憶しておく記憶装置３１３、複数のユニットの例としてユニットＡ３１４、ユニットＢ３１５、ユニットＣ３１６を備えている。そしてこれらは制御バス３１７を介して情報や命令をやり取りする。制御バス３１７は無線でもよい。
【００４５】
在庫管理サーバ３３０は、ネットワーク３２０を介して情報をやりとりするための通信装置３３１、在庫管理サーバの情報を操作する制御装置３３２、在庫情報を記憶する記憶装置３３３を備え、制御バス３３４を介して情報や命令のやり取りを行う。
【００４６】
アプリケーションサーバ３４０は、ネットワークを介して情報やプログラムをやり取りするための通信装置３４１と、それを制御するための制御装置３４２と、ユニットの品質を判断するためのプログラムを格納しておくための記憶装置３４３とを備えており、情報や命令を制御バス３４４を介してやりとりする。
【００４７】
図４は、実施例２におけるフローチャートである。
【００４８】
ユーザーがステップ４０１にて製品の回収を依頼すると、ステップ４０２にて製品３１０はユニット毎の品質を判断するためのプログラムが最新のものかどうかをアプリケーションサーバ３４０に問い合わせに行く。アプリケーションサーバ３４０に、製品３１０に対応するより新しいプログラムがある場合は、ステップ４０４にて製品３１０は前記より新しいプログラムをダウンロードしてくる。ステップ４０５では、最新のプログラムを使用してユニット毎の品質を判断する。ステップ４０６にて判断結果を在庫管理サーバ３３０へ送信する。在庫管理サーバでは、受信した結果に応じてステップ４０７にてユニット毎在庫を増加させる（ステップ４０８）。ステップ４０９では待機状態に入り、ユーザーからの回収依頼があれば、ステップ４０１からの処理を再度繰り返す。ステップ４０９の状態で部品の発注量を算出する指令を受けると、ステップ４１０へ進み、記憶装置３３３に蓄えられている在庫情報を元に部品の発注量を算出する。
【実施例３】
【００４９】
図５は、実施例３に係る説明図である。
【００５０】
これは、複写機のユニットの再利用の可否を判断するための検査項目、その検査結果、判定された品質を表にまとめたものである。Ｎｏ．１，Ｎｏ．３，Ｎｏ．５，Ｎｏ．６は従来からも行われている検査項目で、メモリに情報を蓄え、その情報を取得することでユニットの品質レベルを判定できる情報の例である。それに対して、Ｎｏ．２，Ｎｏ．４，Ｎｏ．７，Ｎｏ．８，Ｎｏ．９，Ｎｏ．１０はユニットを動的にテストさせてその結果をもってユニットの品質レベルを判断するための情報の例である。ユニットを再利用するかどうかに必要なテストは、普段は行う必要が無く、再利用するかどうかの判断を行いたいときだけに実施することで、システムの利用効率が向上する。ここで、再利用するかどうかの判断を行いたいときとは、製品のレンタル期限が終了するときや、ユーザーから回収依頼があったときや、契約により製品が故障した場合に故障製品を引き取り新製品を顧客に渡さなければならないときが例としてあげられる。
【００５１】
図５の例では、一つのユニットに複数の検査項目がある場合、複数の検査すべてに合格すれば、Ａランク、時間やカウンタといった指標ではＡランクの値をクリアできないが、動作自体が正常であればＢランクといった基準でランク付けを行っている。これらの判断は、例えば実施例２の場合だと、ダウンロードしてきたプログラムが実行する。
【実施例４】
【００５２】
図６は、実施例４におけるシステム図である。
【００５３】
ユーザーが回収を依頼するとユニット毎の再利用可否情報が在庫管理サーバ６０２へ行き在庫情報を更新する。在庫管理サーバはこの時点で、情報をもとに発注１を部品工場６０４に対して行う。製品６０１が回収工場６０３に回収され、再度精密な検査を行った後、前記回収依頼時の検査と相違があった場合は、回収工場６０３から在庫管理サーバ６０２へ修正依頼がり、在庫管理サーバは在庫を適切に修正した後、部品工場６０４に対して修正発注２を行う。
【００５４】
図７は実施例４におけるフローチャートである。
【００５５】
ステップ７０１で在庫サーバはリモートから製品のユニット毎の品質レベル判断を行い、ステップ７０２にて在庫データベースを更新する。この情報をもとに、ステップ７０３にて部品工場に発注を行う。ステップ７０４では、回収工場にて回収後のユニットのレベル判断を行い、判断結果に応じて、ステップ７０５にて部品発注量の微調整を行う。
【００５６】
このように、前もってある程度の確度の情報で大量に発注を行い、後になって、少量の微調整のための発注を行うことで、部品調達コストを低減させることが可能である。
【図面の簡単な説明】
【００５７】
【図１】図１は、実施例１におけるシステム図である。
【図２】図２は、実施例１におけるフローチャートである。
【図３】図３は、実施例２におけるシステム図である。
【図４】図４は、実施例２におけるフローチャートである。
【図５】図５は、実施例３に係る説明図である。
【図６】図６は、実施例４におけるシステム図である。
【図７】図７は実施例４におけるフローチャートである。
【符号の説明】
【００５８】
１１０  製品
１１１  通信装置
１１２  制御装置
１１３  記憶装置
１１４  ユニットＡ
１１５  ユニットＢ
１１６  ユニットＣ
１１７  制御バス
１２０  ネットワーク
１３０  在庫管理サーバ
１３１  通信装置
１３２  制御装置
１３３  記憶装置
１３４  制御バス
【図１】
2006172078.tif 000003
【図２】
2006172078.tif 000004
【図３】
2006172078.tif 000005
【図４】
2006172078.tif 000006
【図５】
2006172078.tif 000007
【図６】
2006172078.tif 000008
【図７】
2006172078.tif 000009