(57)【要約】      （修正有）【課題】異常運転の際に迅速且つ確実に補修ができ、施設管理、メンテナンス業者管理、メンテナンス費用の管理などの複雑な管理を一括管理できる発酵処理施設の管理システムを提供すること。【解決手段】管理センタサーバ２は、施設端末１から送信された運転データを受信し、該運転データが所定範囲にあるか否か判断し、所定範囲にある場合メンテナンス業者端末５に定期的メンテナンス指示を行い、所定範囲を越えた場合メンテナンス業者端末５に緊急補修指示を行い、メンテナンス業者端末５からメンテナンス終了通知を受信し、発酵処理施設の販売形態が買い取りの場合にはメンテナンス業者端末５からのメンテナンス終了通知を受信した後製造販売者端末３に課金情報を送信し、該販売形態がリース又はレンタル販売の場合にはメンテナンス業者端末５からのメンテナンス終了通知をリース業者端末４に送信することを特徴とする発酵処理施設の管理システム。【選択図】        図１
2006338260.tif 000002
【特許請求の範囲】
【請求項１】
使用済み紙おむつを破砕・攪拌し発酵処理する発酵処理施設の運転データを取得する取得手段と該運転データを送信する送信手段とを有する施設端末と、
前記発酵処理施設の製造及び又は販売を少なくとも行う製造販売者が保有する製造販売者端末と、
前記発酵処理施設のリース又はレンタル販売を行う販売者が保有するリース業者端末と、
前記発酵処理施設のメンテナンスを行うメンテナンス業者が保有するメンテナンス業者端末と、
前記施設端末と前記製造販売者端末とリース業者端末とメンテナンス業者端末とに通信回線を介して接続されたシステム管理者が所有する管理センタサーバとを備え、
前記管理センタサーバは、前記施設端末から送信された運転データを受信し、該運転データが所定範囲にあるか否か判断し、所定範囲にある場合前記メンテナンス業者端末に定期的メンテナンス指示を行い、所定範囲を越えた場合前記メンテナンス業者端末に緊急補修指示を行い、
前記メンテナンス業者端末からメンテナンス終了通知を受信し、
前記発酵処理施設の販売形態が買い取りの場合には前記メンテナンス業者端末からのメンテナンス終了通知を受信した後前記製造販売者端末に課金情報を送信し、
該販売形態がリース又はレンタル販売の場合には前記メンテナンス業者端末からのメンテナンス終了通知を前記リース業者端末に送信することを特徴とする発酵処理施設の管理システム。
【請求項２】
前記メンテナンス業者が複数あり、該複数のメンテナンス業者の各々が保有するメンテナンス業者端末を有し、
前記管理センタサーバが前記定期的メンテナンス指示又は前記緊急補修指示を前記複数のメンテナンス業者端末から選択されたいずれかに送信することを特徴とする請求項１記載の発酵処理施設の管理システム。
【請求項３】
前記管理センタサーバは、前記販売形態がリース又はレンタル販売の場合には前記メンテナンス業者端末からのメンテナンス終了通知を前記リース業者端末に送信し、前記リース業者端末に前記メンテナンス業者端末の保有者に支払い命令を行うことを特徴とする請求項１又は２記載の発酵処理施設の管理システム。
【請求項４】
前記管理センタサーバは、前記発酵処理施設の販売形態が買い取りの場合には前記メンテナンス業者端末からのメンテナンス終了通知を受信した後、前記製造販売者端末に前記メンテナンス業者端末の保有者に支払い命令を行うことを特徴とする請求項１、２又は３記載の発酵処理施設の管理システム。
【請求項５】
前記製造販売者端末、前記リース業者端末及び前記メンテナンス業者端末の何れか一つ以上が車両に搭載された又は移動可能な端末であることを特徴とする請求項１〜４の何れかに記載の発酵処理施設の管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は発酵処理施設の管理システムに関し、詳しくは異常運転の際に迅速且つ確実に補修ができる発酵処理施設の管理システムに関する。
【背景技術】
【０００２】
吸水材として吸水性ポリマーを用いた紙おむつは、吸水性ポリマーの優れた吸水性能によって、乳幼児用のみならず老人用としても幅広く使用されている一方、使い捨て製品であるために、特に病院や老人ホーム、老人介護施設等において、使用済みの紙おむつが日々大量に廃棄されている現状にあり、その処分が問題となっている。
【０００３】
使用済みの紙おむつを可燃ゴミとして焼却処分するには、紙おむつから予め汚物を取り除いておく必要があり、また、ゴミの収集日まで保管しておく必要もあることから、病原菌による感染のおそれや悪臭の発生等の問題がある。
【０００４】
そこで、本出願人は、紙おむつの破砕効果が高く、効率良く発酵分解処理することができる使用済み紙おむつの発酵処理施設及びこれを用いた発酵処理装置を先に先願特許１の明細書において提案した。
【先願特許１】
【０００５】
特願２００４−２５７５９８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記発酵処理施設は、病院施設に設置されることが多いが、かかる病院施設ではコストの面でメンナンス作業員が確保できないことが多いので、発酵処理運転中に異常運転となった場合に、対策が遅れ重大な問題になるおそれがあった。
【０００７】
また病院施設は、複数あり、これらの複数の施設に上記発酵処理施設をおのおの設置した場合、それらのメンテナンスが煩雑であり、またメンテナンス業者も１社とは限らない。さらに病院側が発酵処理施設を導入する形態もリースなど様々であり、従って、施設管理やメンテナンス業者管理、さらにはメンテナンス費用の管理など複雑な管理が必要となる。
【０００８】
そこで、本発明は、異常運転の際に、迅速且つ確実に補修ができ、さらに施設管理、メンテナンス業者管理、さらにはメンテナンス費用の管理などの複雑な管理を一括管理できる発酵処理施設の管理システムを提供することにある。
【０００９】
本発明の他の課題は、以下の記載により明らかとなる。
【課題を解決するための手段】
【００１０】
上記課題は、以下の各発明によって解決される。
【００１１】
（請求項１）
使用済み紙おむつを破砕・攪拌し発酵処理する発酵処理施設の運転データを取得する取得手段と該運転データを送信する送信手段とを有する施設端末と、
前記発酵処理施設の製造及び又は販売を少なくとも行う製造販売者が保有する製造販売者端末と、
前記発酵処理施設のリース又はレンタル販売を行う販売者が保有するリース業者端末と、
前記発酵処理施設のメンテナンスを行うメンテナンス業者が保有するメンテナンス業者端末と、
前記施設端末と前記製造販売者端末とリース業者端末とメンテナンス業者端末とに通信回線を介して接続されたシステム管理者が所有する管理センタサーバとを備え、
前記管理センタサーバは、前記施設端末から送信された運転データを受信し、該運転データが所定範囲にあるか否か判断し、所定範囲にある場合前記メンテナンス業者端末に定期的メンテナンス指示を行い、所定範囲を越えた場合前記メンテナンス業者端末に緊急補修指示を行い、
前記メンテナンス業者端末からメンテナンス終了通知を受信し、
前記発酵処理施設の販売形態が買い取りの場合には前記メンテナンス業者端末からのメンテナンス終了通知を受信した後前記製造販売者端末に課金情報を送信し、
該販売形態がリース又はレンタル販売の場合には前記メンテナンス業者端末からのメンテナンス終了通知を前記リース業者端末に送信することを特徴とする発酵処理施設の管理システム。
【００１２】
（請求項２）
前記メンテナンス業者が複数あり、該複数のメンテナンス業者の各々が保有するメンテナンス業者端末を有し、
前記管理センタサーバが前記定期的メンテナンス指示又は前記緊急補修指示を前記複数のメンテナンス業者端末から選択されたいずれかに送信することを特徴とする請求項１記載の発酵処理施設の管理システム。
【００１３】
（請求項３）
前記管理センタサーバは、前記販売形態がリース又はレンタル販売の場合には前記メンテナンス業者端末からのメンテナンス終了通知を前記リース業者端末に送信し、前記リース業者端末に前記メンテナンス業者端末の保有者に支払い命令を行うことを特徴とする請求項１又は２記載の発酵処理施設の管理システム。
【００１４】
（請求項４）
前記管理センタサーバは、前記発酵処理施設の販売形態が買い取りの場合には前記メンテナンス業者端末からのメンテナンス終了通知を受信した後、前記製造販売者端末に前記メンテナンス業者端末の保有者に支払い命令を行うことを特徴とする請求項１、２又は３記載の発酵処理施設の管理システム。
【００１５】
（請求項５）
前記製造販売者端末、前記リース業者端末及び前記メンテナンス業者端末の何れか一つ以上が車両に搭載された又は移動可能な端末であることを特徴とする請求項１〜４の何れかに記載の発酵処理施設の管理システム。
【発明の効果】
【００１６】
本発明によれば、異常運転の際に、迅速且つ確実に補修ができ、さらに施設管理、メンテナンス業者管理、さらにはメンテナンス費用の管理などの複雑な管理を一括管理できる発酵処理施設の管理システムを提供することができる。
【発明を実施するための最良の形態】
【００１７】
以下、図面に基づいて本発明の実施の形態を説明する。
【００１８】
図１は、本発明に係る発酵処理施設の管理システムの一例を示すブロック図である。
【００１９】
図１において、１は使用済み紙おむつを破砕・攪拌し、発酵処理する発酵処理施設が保有する施設端末であり、運転データを取得する取得手段１００と該運転データを送信する送信手段１０１とを少なくとも備えている。該発酵処理施設は図示のように複数存在していることがシステム設計上は好ましく、施設端末１は各施設毎に保有していることが好ましい。なお、本発明における「施設端末」というのは、通常の端末以外に、各施設に運転制御パネルに運転データを取得する取得手段１００と該運転データを送信する送信手段１０１を組み込んだ端末装置であってもよい。
【００２０】
運転データを取得する取得手段１００において取得する運転データは、発酵処理施設に設けられる例えば特願２００４−２５７５９８号明細書記載の処理機（図示せず）内の温度データ、攪拌機回転モータの電流値、蓋開閉センサデータなどである。
【００２１】
処理機内の温度データは、処理機に送風する温風用のヒータ温度データであってもよい。ヒータ温度と処理機内温度は相関があるからである。処理機内発酵槽内の温度は、使用される微生物の種類によっても異なるが、一例を挙げれば、発酵処理中は３５〜４５℃、処理後の処理物を排出する前に行う滅菌のための高温処理時は８０℃程度に制御されている。処理機は上記のような温度となるようにヒータ温度が適宜制御されている。
【００２２】
図１において、２はシステム管理者が所有する管理センタサーバ、３は前記発酵処理施設の製造及び又は販売を少なくとも行う製造販売者が保有する製造販売者端末、４は前記発酵処理施設のリース又はレンタル販売を行う販売者が保有するリース業者端末、５は前記発酵処理施設のメンテナンスを行うメンテナンス業者が保有するメンテナンス業者端末である。
【００２３】
前記施設端末１と前記製造販売者端末３とリース業者端末４とメンテナンス業者端末５は通信回線６を介して前記管理センタサーバ２に接続されている。
【００２４】
管理センタサーバ２は、図２に示すように、ＣＰＵによって構成される主制御部２００、データベースなどによって構成される記憶部２０１、インターフェースなどによって構成される入出力制御部２０２、モデムなどによって構成される通信部２０３、キーボードやマウスなどによって構成される入力部２０４、モニターなどによって構成される表示部２０５、プリンタなどによって構成される出力部２０６を備えている。
【００２５】
次に、記憶部２０１内のデータベースについて図３に基づいて説明する。
【００２６】
各種テーブルは、各フィールドが対応付けられ格納されている。以下の説明では、各処理施設や処理機を単に「装置」と称する。
【００２７】
テーブルの種類としては、装置テーブル、装置詳細テーブル、メンテナンステーブル、装置導入テーブル、地域テーブル、顧客テーブル、メンテナンス業者テーブル、メンテナンス実施テーブル、料金テーブルが少なくとも挙げられ、これらのテーブルがデータベースに格納されている。
【００２８】
装置テーブルのフィールドは、装置コード（例えば装置を識別する識別番号、装置の詳細なデータを示す詳細コードなど）、装置名、導入コード（例えば装置を導入した時の形態を示すコードなど）、地域コード（例えば装置設置場所の地域を示すコードなど）、定期メンテナンス日、装置の運転履歴ファイル名が少なくとも対応付けられている。導入コードは、買取、リース、レンタルの種別を、装置を導入した時の形態を示すコードであらわす。
【００２９】
運転履歴ファイル名とは、管理センタサーバ２が、各装置から運転データを受信したら、その受信したデータを記録し、運転履歴ファイルを作り、その運転履歴ファイルを管理センタサーバ２に格納し、運転履歴ファイルを呼び出すためのパスである。
【００３０】
装置詳細テーブルのフィールドは、例えば装置コード、メンテナンス実施日、故障原因、故障部位などのメンテナンス実施内容などが少なくとも対応付けられている。
【００３１】
またメンテナンス実施内容ファイル名は、メンテナンスを実施した実施内容、事故原因、メンテナンス実施日などのデータを記録し、メンテナンス実施内容ファイルを管理センタサーバに格納し、メンテナンス実施ファイルを呼び出すためのパス名である。
【００３２】
メンテナンステーブルのフィールドは、例えばメンテナンスの種類を識別する識別番号（メンテナンスコード）、メンテナンスの種類が少なくとも対応付けられている。
【００３３】
装置導入テーブルのフィールドは、例えば導入形態を示す識別番号（導入コード）、導入形態（買取、レンタル、リース）が少なくとも対応付けられている。
【００３４】
地域テーブルのフィールドは、例えば地域毎の識別番号（地域コード）とその地域名が対応付けられている。
【００３５】
顧客テーブルのフィールドは、例えば顧客を識別する識別番号（顧客コード）の他顧客の属性情報が少なくとも対応付けられている。
【００３６】
メンテナンス業者テーブルのフィールドは、例えばメンテナンス業者を識別する識別番号（メンテナンス業者コード）、メンテナンス業者が請け負う地域を示す住所コードの他メンテナンス業者の属性情報が対応付けられている。
【００３７】
メンテナンス実施テーブルのフィールドは、例えば、メンテナンス業者コード、メンテナンス業者名、装置コード、装置名、メンテナンスコード、メンテナンスの種類が少なくとも対応付けられている。
【００３８】
料金テーブルのフィールドは、メンテナンス業者コード、支払業者、支払金額、支払日が少なくとも対応付けられている。
【００３９】
次に、本発明の管理システムの処理フローについて図４に基づいて説明する。
【００４０】
まず管理センタサーバ２は、複数の施設端末１、１・・・・からの運転データを装置コード毎に取得する（Ｓ１）。取得したら運転データを装置コード毎に解析し、装置コード毎にある運転履歴ファイルにそれぞれ記録する。記録の仕方は特に限定されない。
【００４１】
次に、運転データが所定範囲にあるか否かを判断する（Ｓ２）。例えば、設定値を用いる場合は、管理センタサーバ２の入力部２０４より入力された設定値の上限、下限を超えるか否かを管理センタサーバ２は監視する。
【００４２】
設定値としては、装置内温度の場合、発酵処理中は３５〜４５℃、処理後の処理物を排出する前に行う滅菌のための高温処理時は８０℃程度に制御されているので、発酵処理中は３５〜４５℃に設定する。また排出時には８０℃に設定する。ヒータ温度で設定する場合は、上記の温度に相関値をかけて算出した値を設定値とする。
【００４３】
次に、運転データで所定範囲を超えた場合（Ｓ２でＮＯであった場合）は、メンテナンスコードを割当てる（Ｓ３）。例えば、複数台の施設端末からの運転データにより、ある１台の施設端末から取得した運転データが所定範囲を超えた場合は、その施設端末１に対してメンテナンスコードを割当てる。装置コードと施設端末の関係は１対１であるため、装置コードとメンテナンスコードが関連付けられる。これにより、ある１台の装置のメンテナンスの種類は、緊急メンテナンスであるとわかる。
【００４４】
また、運転データが所定範囲を超えていない場合（Ｓ２でＹＥＳであった場合）は、装置テーブルを参照し、定期メンテナンス日のデータを取得する（Ｓ４）。
【００４５】
次に、定期メンテナンス日か否かの判断をする（Ｓ５）。メンテナンス日でなかった場合は、Ｓ１の処理に戻りまた監視を続ける。超えていた場合は、エラーを表示し更新させるように指示してもよいし、定期メンテナンス日として処理を進めてもよい。
【００４６】
次に、定期メンテナンス日であった場合（Ｓ５でＹＥＳであった場合）は、メンテナンスコードを割当てる（Ｓ６）。前記Ｓ３の処理と同様に、装置コードと施設端末の関係は１対１であるため、装置コードとメンテナンスコードが関連付けられる。ある１台の装置のメンテナンスの種類は、定期メンテナンスであるとわかる。
【００４７】
次に、メンテナンス業者テーブルの地域コードと装置テーブルの地域コードが一致するメンテナンス業者を選択する（Ｓ７）。地域コードの一致により、装置コードとメンテナンス業者コードが関連付けられる。また前記Ｓ３とＳ６の処理により、装置コードとメンテナンスコードも関連付けられている。よって、ある装置のメンテナンスの種類が定期か緊急であり、そのメンテナンスを行う業者がどこであるかということがわかる。また一致する地域コードがなかった場合は、地域コードが近いものを選ぶようにしてもよい。  
【００４８】
次に、メンテナンス実施テーブルにレコードを更新する（Ｓ８）。メンテナンス実施テーブルのフィールドは、メンテナンス業者コード、メンテナンス業者名、装置コード、装置名、メンテナンスコード、メンテナンス種類が少なくとも関連付けられているため、上記Ｓ７の処理までで更新するフィールド情報は全て関連付けられていることがわかる。
【００４９】
更新後には、メンテナンスを実施する装置に接続された施設端末のメールアドレスにメンテナンス実施する情報を送信するようにしてもよい。このとき装置テーブルの装置コードと顧客テーブルの顧客コードを関連付けするテーブルを事前に作成しておくことが好ましい。これにより装置コードに対応する顧客のメールアドレスを検索することが可能となる。
【００５０】
次に、Ｓ７で選択されたメンテナンス業者のメンテナンス業者端末５へ連絡する（Ｓ９）。連絡する方法としては、例えば、メンテナンス業者へメールソフトの機能などを用いて連絡する手段、当該選択されたメンテナンス業者のメンテナンス業者端末５の表示画面に警告や点滅などして連絡する手段がある。表示画面に警告や点滅などをして連絡する手段は、例えば、メンテナンス業者端末５から管理センタサーバ２にアクセスできるようなクライアントソフトを用い、管理センタサーバ２のデータベースで端末に表示させるレポートを作成しておき、アクセスしてきたメンテナンス業者端末５に関連するレポートを表示させ、メンテナンス実施テーブルが更新されたらその表示するレポートの前面に警告信号や点滅信号などを表示させる。
【００５１】
次に、メンテナンス業者からの入力を待ち（Ｓ１０）、入力があったか判断する（Ｓ１１）。入力の例としては、管理センタサーバ２が、装置詳細テーブルの各フィールドから図示しない入力フォームなどを予め作成し、メンテナンス業者端末５に入力フォームを表示させ、メンテナンス業者はメンテナンス業者端末５から入力フォームの所定のフィールドに対して入力作業を行う。管理サーバ２は、メンテナンス業者が、メンテナンス業者端末５に表示された入力フォームの所定のフィールドに対して入力を終えたら、フィールド上にある登録ボタンを押すことで入力されたと判断する。
【００５２】
入力があった場合は、メンテナンス実施フィールドから、対応する装置コードのレコードが削除され（Ｓ１２）、装置詳細テーブルが更新される（Ｓ１３）。
【００５３】
次に、施設端末１への終了通知を送信する（Ｓ１４）。このとき装置テーブルの装置コードと顧客テーブルの顧客コードを対応付けるテーブルを作成しておくことが好ましい。これにより装置コードに対応するメールアドレスを検索することが可能となる。終了通知を宛先メールアドレスに対して送信することが可能となる。
【００５４】
次に、当該メンテナンスを実施した装置の装置コードに対応する導入コードを呼び出し、導入コードがＤ０１であるか否かを判断する（Ｓ１５）。導入形態がどの形態かを調べてそれに応じて対応する。
【００５５】
導入形態がＤ０１（買取）であった場合（Ｓ１５でＹＥＳであった場合）は、製造販売者端末３へ課金情報、終了通知、メンテナンス業者への支払通知を送信する（Ｓ１６）。
【００５６】
また、導入形態がＤ０１以外（リース・レンタル）であった場合（Ｓ１５でＮＯであった場合）は、リース業者端末４へ終了通知、メンテナンス業者端末５への支払通知を送信する（Ｓ１７）。
【００５７】
製造販売者端末３、リース業者端末４からの支払終了の入力を待ち（Ｓ１８）、入力があったか判断する（Ｓ１９）。
【００５８】
入力があったら、料金テーブルに更新し（Ｓ２０）、メンテナンス業者のメンテナンス業者端末５へ支払済通知を送信する（Ｓ２１）。送信したら処理を終了する。
【００５９】
以上、本発明の好ましい態様について説明したが、管理センタサーバ２と製造販売者端末３の所有者が同一の場合には、管理センタサーバ２に製造販売者端末３の機能をもたせることができ、管理センタサーバ２と製造販売者端末３の通信のやり取りを省略することもできる。
【００６０】
前記製造販売者端末３、前記リース業者端末４及び前記メンテナンス業者端末５の何れか一つ以上が車両に搭載された又は移動可能な端末であることも好ましい。移動しながらメンテナンスの指示やメンテナンス作業計画を実施でき、特にメンテナンス業者端末５が巡回車に搭載されている場合には、少ないメンテナンス業者で広範囲にメンテナンスを実施できて好ましい。
【００６１】
製造販売者やリース・レンタル業者は複数存在するようになった場合には、各々端末を上記のように機能させることによって本発明を実施できる。
【００６２】
また各端末間で電子マネー化して金銭の授受を実施できるようにすることも好ましい。その場合、管理センタサーバ所有者が銀行機能を行うことも好ましい。
【図面の簡単な説明】
【００６３】
【図１】本発明の発酵処理施設の管理システムの一例を示すブロック図
【図２】本発明に係る管理センタサーバの一例を示す構成図
【図３】図２の管理センタサーバの記憶部内のデータベースの構成例を示す図
【図４】本発明の管理システムの処理フローの一例を示す図
【符号の説明】
【００６４】
１：施設端末
１００：取得手段
１０１：送信手段
２：管理センタサーバ
２００：主制御部
２０１：記憶部
２０２：入出力制御部
２０３：通信部
２０４：入力部
２０５：表示部
２０６：出力部
３：製造販売者端末
４：リース業者端末
５：メンテナンス業者端末
６：通信回線
【図１】
2006338260.tif 000003
【図４】
2006338260.tif 000004
【図２】
2006338260.tif 000005
【図３】
2006338260.tif 000006