(57)【特許請求の範囲】
【請求項１】
製品を構成するハードウェアとファームウェアとを同一の管理レベルのものとし、前記製品の開発、製造、検査等に必要な前記ハードウェアおよび前記ファームウェア関連の複数のコンポーネントをコンポーネントデータベースとして記憶する記憶手段と、
前記コンポーネントデータベースを管理するサーバと、
前記コンポーネントを前記記憶手段から引き出す日時の設定を受け付ける設定受付手段を有し、ネットワークを介して前記サーバに接続され、所定のコンポーネントを前記記憶手段から前記ネットワークを介して引き出すクライアントと、
を備え、
前記サーバは、前記記憶手段に既に記憶されているコンポーネントが改版された場合に前記クライアントに対して前記ネットワークを介して改版通知を出し、また、前記記憶手段に新たなコンポーネントが登録された場合に前記クライアントに対してネットワークを介して新規登録通知を出し、前記クライアントは、前記改版通知または前記新規登録通知を受けたことをトリガとして、前記設定受付手段により受け付けられた設定日時に当該コンポーネントを引き出すことを特徴とするコンポーネント管理システム。
【請求項２】
製品を構成するハードウェアとファームウェアとを同一の管理レベルのものとし、前記製品の開発、製造、検査等に必要な前記ハードウェアおよび前記ファームウェア関連の複数のコンポーネントをコンポーネントデータベースとして記憶する記憶手段と、
前記コンポーネントデータベースを管理し、前記コンポーネントを前記記憶手段から引き出す日時の設定を受け付ける設定受付手段を備えたクライアントが前記設定受付手段により受け付けられた設定日時にネットワークを介して所定のコンポーネントを前記記憶手段から引き出す際の制御を行う管理手段と、
を備え、
前記管理手段は、前記記憶手段に既に記憶されているコンポーネントが改版された場合に前記クライアントに対して前記ネットワークを介して改版通知を出し、また、前記記憶手段に新たなコンポーネントが登録された場合に前記クライアントに対してネットワークを介して新規登録通知を出し、前記クライアントは、前記改版通知または前記新規登録通知を受けたことをトリガとして、前記設定日時に当該コンポーネントを引き出すこと、
を特徴とするコンポーネント管理装置。
【請求項３】
前記複数のコンポーネントは、階層構造をなしており、前記記憶手段には、前記階層構造を表すメタ情報が記憶されており、前記クライアントは、前記メタ情報に基づいて、階層構造化された複数のコンポーネントの中から所望のコンポーネントを引き出すことを特徴とする請求項２に記載のコンポーネント管理装置。
【請求項４】
前記メタ情報には、コンポーネント単位で引き出しの許可／不許可に関する引出制限情報が含まれており、前記クライアントは、前記引出制限情報に基づいて、許可された場合にのみ当該コンポーネントを引き出すことを特徴とする請求項３に記載のコンポーネント管理装置。
【請求項５】
前記クライアントは、前記メタ情報に基づいて複数のコンポーネントの中から所望のコンポーネントを検索することを特徴とする請求項３または４に記載のコンポーネント管理装置。
【請求項６】
前記コンポーネントには、ファームウェアに対して自動的にパッチ処理を施すためのパッチ情報が含まれており、前記クライアントは、前記パッチ情報に基づいて、当該ファームウェアに対してパッチ処理を施すことを特徴とする請求項２〜５のいずれか一つに記載のコンポーネント管理装置。
【請求項７】
前記管理手段は、外部の開発メーカに設置され前記ネットワークを介して接続された開発メーカ側クライアントとの間で製品の開発委託に関する通信を行うことを特徴とする請求項２〜６のいずれか一つに記載のコンポーネント管理装置。
【請求項８】
前記管理手段は、製品を構成する部品のカタログの著作者側に設置された著作者側クライアントとの間で前記カタログの引用許諾を受けるための通信を行い、許諾が得られた場合に、前記記憶手段に前記カタログをデータベースとして登録することを特徴とする請求項２〜７のいずれか一つに記載のコンポーネント管理装置。
【請求項９】
製品を構成するハードウェアとファームウェアとを同一の管理レベルのものとし、前記製品の開発、製造、検査等に必要な前記ハードウェアおよび前記ファームウェア関連の複数のコンポーネントをコンポーネントデータベースとして記憶手段に記憶させる記憶工程と、
前記コンポーネントデータベースを管理させ、前記コンポーネントを前記記憶手段から引き出す日時の設定を受け付ける設定受付手段を備えたクライアントが前記設定受付手段により受け付けられた設定日時にネットワークを介して所定のコンポーネントを前記記憶手段から引き出す際の制御を行わせる管理工程と、
をコンピュータに実行させ、
前記管理工程は、前記記憶手段に既に記憶されているコンポーネントが改版された場合に前記クライアントに対して前記ネットワークを介して改版通知を出し、また、前記記憶工程により新たなコンポーネントが登録された場合に前記クライアントに対してネットワークを介して新規登録通知を出し、前記クライアントは、前記改版通知または前記新規登録通知を受けたことをトリガとして、前記設定日時に当該コンポーネントを引き出すこと、
を特徴とするコンポーネント管理プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、装置を構成するハードウェア、ファームウェアを同一レベル部品とみなし、装置の製造に不可欠なコンポーネント（ハードウェア図面、ファームウェア図面、ドキュメント、ソースコード、仕様書等）を統合的に管理するコンポーネント管理システム、コンポーネント管理装置およびコンポーネント管理プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
装置／ユニットの製造を業とする企業においては、開発過程、設計過程、製造過程、検査過程、出荷過程という一連の過程で設計図面、仕様書、契約書に加えて、ファームウェア（プログラム）という多種多様なコンポーネントが必要とされる。ここで、コンポーネントは、ハードウェア系のものと、ファームウェア系のものとに大別される。したがって、企業においては、ハードウェア系のコンポーネントと、ファームウェア系のコンポーネントとを分けて管理している。
【０００３】
しかしながら、ハードウェア系のコンポーネントとファームウェア系のコンポーネントとが本来同一の製品に適用されるものであるため、両者を分けて管理することは、管理ミス、管理効率の低下、開発から出荷までの時間の増大等が生じやすく、得策ではない。したがって、従来より、かかる問題点を解決するための手段、方法が要請されている。
【０００４】
【従来の技術】
図３６は、従来における製品の開発および製造過程を説明する図である。この図において、設計部門では、ステップＳ１〜ステップＳ９までの処理が順次実行される。すなわち、ステップＳ１では、製品の機能に関する仕様をまとめた機能仕様書が作成され、ステップＳ２では、製品の内部構成に関する仕様をまとめた内部仕様書が作成される。
【０００５】
つぎのステップＳ３では、製品の生産・組立に関する仕様をまとめた生産・組立仕様書が作成され、ステップＳ４では、生産された製品に対する試験・検査に関する仕様をまとめた試験・検査仕様書が作成される。また、ステップＳ５では、各種仕様書、設計図面の版数を管理するための版数管理表が作成される。
【０００６】
ここで、実際には、上述した機能仕様書、内部仕様書、・・・、版数管理表（以下、各種仕様書等と称する）は、ステップＳ６でワークステーションやパーソナルコンピュータを用いて作成される。そして、ステップＳ７では、各種仕様書に基づいて、たとえば、製品に搭載すべきファームウェアのソースコードが開発された後、ステップＳ８では、上記ソースコードがコンパイルされることによりオブジェクト（コード）が作成される。ステップＳ９では、上記オブジェクト（コード）および各種仕様書が記録媒体１に記録された後、この記録媒体１が設計部門から工場へ提供される。
【０００７】
これにより、工場において、ステップＳ１０では、記録媒体１からワークステーション、パーソナルコンピュータ等へオブジェクトコードおよび各種仕様書が移入された後、ステップＳ１１では、オブジェクトコードが編集される。つぎのステップＳ１２では、生産・組立仕様書（ステップＳ３参照）にしたがって、ターゲットマシン（製品）へオブジェクトコード（ファームウェア）が搭載される。具体的には、ターゲットマシンに実装されているＰＲＯＭ（Programmable Read Only Memory）にオブジェクトコード（ファームウェア）が書き込まれる。
【０００８】
そして、ステップＳ１３では、試験・検査仕様書（ステップＳ４参照）にしたがって、ターゲットマシンに対する試験・検査が行われた後、ステップＳ１４では、試験・検査に合格したターゲットマシンが出荷される。さらに、ステップＳ１５では、ターゲットマシンに対するフィールド試験が行われた後、フィールド試験に合格したターゲットマシンがユーザの元へ届けられる。
【０００９】
ここで、上述においては、主としてファームウェアについての説明をした。しかしながら、装置／ユニットを製造する際には、設計部門においては、ファームウェアに関する設計の他に、装置／ユニットを構成するハードウェアに関する設計が行われる。具体的には、設計部門では、親コンポーネント図面、子コンポーネント図面、論理回路図、プリント板実装図面、ハードウェア試験仕様書等のハードウェアに関する様々な形態の設計図面が作成される。
【００１０】
上記親コンポーネント図面は、装置／ユニットのコンポーネント（構成要素）の一覧を示すものであり、子コンポーネント図面は、子コンポーネント図面に記載されているコンポーネントの構成を示すものである。論理回路図は、当該装置における論理回路を示すものであり、プリント板実装図面は、プリント板に各部品を実装する際の実装状態を示すものである。ハードウェア試験仕様書は、組み立てられた装置に対する動作確認等の各種試験に関する仕様をまとめたものである。
【００１１】
ここで、以下においては、ハードウェアに関する設計図面等をハードウェアコンポーネントと称する。同様にして、前述したファームウェアに関する各種仕様書をファームウェアコンポーネントと称する。これらのハードウェアコンポーネントとファームウェアコンポーネントとは、管理部門において別々の管理ルールの下でそれぞれ個別的に管理されており、必要に応じて工場等へそれぞれ配布される。また、設計変更等の理由により、ハードウェアコンポーネントまたはファームウェアコンポーネントに改版が発生した場合にも、管理部門で個別的に版数管理が行われている。
【００１２】
また、従来においては、ハードウェアコンポーネントおよびファームウェアコンポーネントを管理する手段として、クライアント／サーバ型のシステムが用いられている。このシステムは、管理部門に設置されたサーバと、工場等に設置されネットワークを介して上記サーバにアクセス可能な複数のクライアントとから概略構成されている。
【００１３】
サーバには、ハードウェアコンポーネントおよびファームウェアコンポーネントが個別的に登録されている。クライアントにおいては、ブラウザにより、ハードウェアコンポーネントおよびファームウェアコンポーネントを参照する。また、クライアントは、ネットワークＮを介してハードウェアコンポーネントまたはファームウェアコンポーネントを受領する。これらの参照、受領に伴う各種操作は、クライアントのオペレータにより行われる。
【００１４】
ここで当該システムにおいては、セキュリティ確保を目的として、パスワード照合により、ハードウェアコンポーネントおよびファームウェアコンポーネントの配布先（クライアント）を制限している。つまり、従来においては、パスワード照合により、クライアント単位で配布先の制限が行われている。
【００１５】
具体的には、特定のパスワードが付与されたクライアントに対しては、特定のハードウェアコンポーネントおよびファームウェアコンポーネントの配布が許可されており、特定のパスワード以外のパスワードが付与されたクライアントに対しては、特定のハードウェアコンポーネントおよびファームウェアコンポーネントの配布が禁止されている。また、従来においては、ファームウェアコンポーネントにおけるファームウェアに不具合が発見された場合は、紙媒体に記載された仕様書に基づいて、手作業でパッチ適用作業、すなわち修正作業が行われていた。
【００１６】
【発明が解決しようとする課題】
ところで、前述したように、従来においては、ハードウェアコンポーネントとファームウェアコンポーネントとが個別的に管理されている旨を述べた。これは、一般的に製品開発におけるハードウェア開発とファームウェア開発とが別々に行われることに起因している。
【００１７】
しかしながら、装置の製造においては、ハードウェアコンポーネントとファームウェアコンポーネントとが有機的に関連づけられた状態で用いられる。したがって、個別的に管理されているハードウェアコンポーネントとファームウェアコンポーネントとを、有機的に関連づける際には、おのずと無理が生じるため、関連づけに伴う作業ミスが発生するという問題があった。
【００１８】
また、管理部門においては、ハードウェアコンポーネント用の管理ルールと、ファームウェアコンポーネント用の管理ルールという二種類の管理ルールが存在するため、管理作業が煩雑になるとともに、管理対象が増えるにしたがって、管理作業量も飛躍的に増大するという問題があった。同様にして、版数管理においても、ハードウェアコンポーネントの版数管理と、ファームウェアコンポーネントの版数管理とが個別的に行われているため、煩雑な作業を要する。
【００１９】
また、従来においては、パスワード照合によりクライアント単位で、ハードウェアコンポーネント、ファームウェアコンポーネントの配布先の制限を加えているため、ハードウェアコンポーネントのうち、たとえば、親子コンポーネント図面のみに配布先の制限を加えるといった、コンポーネント単位での配布先の制限を加えることができないため、きめ細かなセキュリティ対策を採ることができないという欠点があった。
【００２０】
さらに、従来においては、ファームウェアに修正を加える場合、紙媒体に記載された仕様書に基づいて、手作業でパッチ適用作業を行っていたため、おのずと、作業ミスが発生したり、作業時間が長くなるという問題があった。
【００２１】
加えて、従来においては、ハードウェアコンポーネント、ファームウェアコンポーネントに関する管理作業、受領作業、参照作業、パッチ適用作業という一連の作業がすべてオペレータ、管理者、作業者の手を介する必要があるため、一連の作業を行う時間帯が勤務時間帯に制限される。このことから、従来においては、作業効率が非常に悪いという問題があった。
【００２２】
本発明は、上記に鑑みてなされたもので、コンポーネントの版数管理効率、管理効率を向上させることができるとともに、作業ミスを防止することができ、さらに作業時間を短縮することができるコンポーネント管理システム、コンポーネント管理装置およびコンポーネント管理プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【００２３】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、製品を構成するハードウェアとファームウェアとを同一の管理レベルのものとし、前記製品の開発、製造、検査等に必要な前記ハードウェアおよび前記ファームウェア関連の複数のコンポーネントをコンポーネントデータベース（後述する一実施の形態のコンポーネントデータベースＤＢ１に相当）として記憶する記憶手段と、前記コンポーネントデータベースを管理するサーバ（後述する一実施の形態の管理サーバ１０に相当）と、前記コンポーネントを前記記憶手段から引き出す日時の設定を受け付ける設定受付手段（後述する一実施の形態の参照系クライアント３０、受領系クライアント４０、対称マシン５０に相当）を有し、ネットワークを介して前記サーバに接続され、所定のコンポーネントを前記記憶手段から前記ネットワークを介して引き出すクライアント（後述する一実施の形態の参照系クライアント３０、受領系クライアント４０、対称マシン５０に相当）と、を備え、前記サーバは、前記記憶手段に既に記憶されているコンポーネントが改版された場合に前記クライアントに対して前記ネットワークを介して改版通知を出し、また、前記記憶手段に新たなコンポーネントが登録された場合に前記クライアントに対してネットワークを介して新規登録通知を出し、前記クライアントは、前記改版通知または前記新規登録通知を受けたことをトリガとして、前記設定受付手段により受け付けられた設定日時に当該コンポーネントを引き出すことを特徴とする。
【００２４】
この請求項１にかかる発明によれば、記憶手段には、ハードウェアとファームウェアとの区別をすることなく、両者に関する複数のコンポーネント（たとえば、設計図面、ファームウェア自体、各種ドキュメント等）が記憶される。このような状態において、サーバは、複数のコンポーネントを一元的に管理する。また、クライアントは、サーバに管理された複数のコンポーネントの中から所定のコンポーネントをネットワークを介して引き出す。
【００２５】
このように、請求項１にかかる発明によれば、ハードウェアとファームウェアとを同一の管理レベルととらえて、両者に関する複数のコンポーネントを一元的に管理するようにしたので、従来のように両者に関するそれぞれのコンポーネントを個別的に管理する場合に比して、版数管理効率や管理効率を向上させることができるとともに、作業ミスの発生を防止することができる。
【００２６】
また、請求項２にかかる発明は、製品を構成するハードウェアとファームウェアとを同一の管理レベルのものとし、前記製品の開発、製造、検査等に必要な前記ハードウェアおよび前記ファームウェア関連の複数のコンポーネントをコンポーネントデータベース（後述する一実施の形態のコンポーネントデータベースＤＢ１に相当）として記憶する記憶手段と、前記コンポーネントデータベースを管理し、前記コンポーネントを前記記憶手段から引き出す日時の設定を受け付ける設定受付手段を備えたクライアント（後述する一実施の形態の参照系クライアント３０、受領系クライアント４０、対称マシン５０に相当）が前記設定受付手段により受け付けられた設定日時にネットワークを介して所定のコンポーネントを前記記憶手段から引き出す際の制御を行う管理手段（後述する一実施の形態の管理サーバ１０に相当）と、を備え、前記管理手段は、前記記憶手段に既に記憶されているコンポーネントが改版された場合に前記クライアントに対して前記ネットワークを介して改版通知を出し、また、前記記憶手段に新たなコンポーネントが登録された場合に前記クライアントに対してネットワークを介して新規登録通知を出し、前記クライアントは、前記改版通知または前記新規登録通知を受けたことをトリガとして、前記設定日時に当該コンポーネントを引き出すこと、を特徴とする。
【００２７】
この請求項２にかかる発明によれば、記憶手段には、ハードウェアとファームウェアとの区別をすることなく、両者に関する複数のコンポーネント（たとえば、設計図面、ファームウェア自体、各種ドキュメント等）が記憶される。このような状態において、管理手段は、複数のコンポーネントを一元的に管理するとともに、クライアントが複数のコンポーネントの中から所定のコンポーネントをネットワークを介して引き出す際の制御を行う。
【００２８】
このように、請求項２にかかる発明によれば、ハードウェアとファームウェアとを同一の管理レベルととらえて、両者に関する複数のコンポーネントを一元的に管理するようにしたので、従来のように両者に関するそれぞれのコンポーネントを個別的に管理する場合に比して、版数管理効率や管理効率を向上させることができるとともに、作業ミスの発生を防止することができる。
【００２９】
また、請求項３にかかる発明は、請求項２に記載のコンポーネント管理装置において、前記複数のコンポーネントは、階層構造をなしており、前記記憶手段には、前記階層構造を表すメタ情報が記憶されており、前記クライアントは、前記メタ情報に基づいて、階層構造化された複数のコンポーネントの中から所望のコンポーネントを引き出すことを特徴とする。
【００３０】
この請求項３にかかる発明によれば、クライアントは、メタ情報に基づいて、階層構造化された複数のコンポーネントの中から所望のコンポーネントを引き出す。このように、請求項３にかかる発明によれば、複数のコンポーネントを階層構造化するようにしたので、クライアント側でメタ情報に基づいて容易に上位階層のコンポーネントから下位階層のコンポーネントを引き出すことができる。
【００３１】
また、請求項４にかかる発明は、請求項３に記載のコンポーネント管理装置において、前記メタ情報には、コンポーネント単位で引き出しの許可／不許可に関する引出制限情報が含まれており、前記クライアントは、前記引出制限情報に基づいて、許可された場合にのみ当該コンポーネントを引き出すことを特徴とする。
【００３２】
この請求項４にかかる発明によれば、クライアントは、引出制限情報に基づいて当該コンポーネントの引き出しが許可された場合にのみ当該コンポーネントを引き出すことが可能である。このように、請求項４にかかる発明によれば、メタ情報にコンポーネント単位で引き出しの許可／不許可に関する引出制限情報を含ませたので、コンポーネント単位という極めて細かな単位でセキュリティ対策を採ることができる。
【００３３】
また、請求項５にかかる発明は、請求項３または４に記載のコンポーネント管理装置において、前記クライアントは、前記メタ情報に基づいて複数のコンポーネントの中から所望のコンポーネントを検索することを特徴とする。
【００３４】
この請求項５にかかる発明によれば、複数のコンポーネントが階層構造化されているため、ハードウェアとファームウェアとを区別することなく、メタ情報から容易に所望のコンポーネントを検索することができる。
【００３５】
また、請求項６にかかる発明は、請求項２〜５のいずれか一つに記載のコンポーネント管理装置において、前記コンポーネントには、ファームウェアに対して自動的にパッチ処理を施すためのパッチ情報が含まれており、前記クライアントは、前記パッチ情報に基づいて、当該ファームウェアに対してパッチ処理を施すことを特徴とする。
【００３６】
この請求項６にかかる発明によれば、パッチ情報が含まれたコンポーネントがクライアントに引き出されると、クライアントにおいては、ファームウェアに対して自動的にパッチ処理が施される。このように、請求項５にかかる発明によれば、コンポーネントにパッチ情報を含ませてクライアント側で自動的にパッチ処理を施すようにしたので、従来のように手作業によりパッチ適用作業を行っていた場合に比して、作業ミスを防止することができるとともに、作業時間を短縮することができる。
【００３７】
また、請求項７にかかる発明は、請求項２〜６のいずれか一つに記載のコンポーネント管理装置において、前記管理手段は、外部の開発メーカに設置され前記ネットワークを介して接続された開発メーカ側クライアント（後述する一実施の形態の開発委託先クライアント６０に相当）との間で製品の開発委託に関する通信を行うことを特徴とする。
【００３８】
この請求項７にかかる発明によれば、管理手段により、開発メーカ側クライアントとの間で製品の開発委託に関する通信も行うようにしたので、開発委託に関する連絡を迅速にとることができ、結果として製品の開発に要する期間を短縮することができる。
【００３９】
また、請求項８にかかる発明は、請求項２〜７のいずれか一つに記載のコンポーネント管理装置において、前記管理手段は、製品を構成する部品のカタログの著作者側に設置された著作者側クライアント（後述する一実施の形態のベンダー側クライアント７０に相当）との間で前記カタログの引用許諾を受けるための通信を行い、許諾が得られた場合に、前記記憶手段に前記カタログをデータベースとして登録することを特徴とする。
【００４０】
この請求項８にかかる発明によれば、管理手段により、著作者側クライアントとの間でカタログの引用許諾を受けるための通信も行うようにしたので、カタログの引用許諾を迅速に受けることができる。
【００４１】
また、請求項９にかかる発明は、製品を構成するハードウェアとファームウェアとを同一の管理レベルのものとし、前記製品の開発、製造、検査等に必要な前記ハードウェアおよび前記ファームウェア関連の複数のコンポーネントをコンポーネントデータベースとして記憶手段に記憶させる記憶工程（後述する一実施の形態のステップＳＡ１〜ステップＳＡ５に相当）と、前記コンポーネントデータベースを管理させ、前記コンポーネントを前記記憶手段から引き出す日時の設定を受け付ける設定受付手段を備えたクライアントが前記設定受付手段により受け付けられた設定日時にネットワークを介して所定のコンポーネントを前記記憶手段から引き出す際の制御を行わせる管理工程（後述する一実施の形態のステップＳＮ３〜ステップＳＮ４、ステップＳＰ３〜ステップＳＰ４、ステップＳＯ１〜ステップＳＯ１２に相当）と、をコンピュータに実行させ、前記管理工程は、前記記憶手段に既に記憶されているコンポーネントが改版された場合に前記クライアントに対して前記ネットワークを介して改版通知を出し、また、前記記憶工程により新たなコンポーネントが登録された場合に前記クライアントに対してネットワークを介して新規登録通知を出し、前記クライアントは、前記改版通知または前記新規登録通知を受けたことをトリガとして、前記設定日時に当該コンポーネントを引き出すこと、を特徴とするコンポーネント管理プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００４２】
この請求項９にかかる発明によれば、記憶工程では、ハードウェアとファームウェアとの区別をすることなく、両者に関する複数のコンポーネント（たとえば、設計図面、ファームウェア自体、各種ドキュメント等）が記憶手段に記憶される。このような状態において、管理工程では、複数のコンポーネントが一元的に管理されるとともに、クライアントが複数のコンポーネントの中から所定のコンポーネントをネットワークを介して引き出す際の制御が行われる。
【００４３】
このように、請求項９にかかる発明によれば、ハードウェアとファームウェアとを同一の管理レベルととらえて、両者に関する複数のコンポーネントを一元的に管理するようにしたので、従来のように両者に関するそれぞれのコンポーネントを個別的に管理する場合に比して、版数管理効率や管理効率を向上させることができるとともに、作業ミスの発生を防止することができる。
【００４４】
【発明の実施の形態】
以下、図面を参照して本発明にかかるコンポーネント管理システム、コンポーネント管理装置およびコンポーネント管理プログラムを記録したコンピュータ読み取り可能な記録媒体の一実施の形態について詳細に説明する。
【００４５】
図１は、本発明にかかる一実施の形態の構成を示すブロック図である。図１に示したコンポーネント管理システムは、ネットワークＮ（たとえば、インターネット）にそれぞれ接続された管理サーバ１０、登録系クライアント２０、参照系クライアント３０、受領系クライアント４０、対称マシン５０、開発委託先クライアント６０およびベンダー側クライアント７０から概略構成されている。
【００４６】
管理サーバ１０は、装置／ユニット等の製品を製造するメーカにおける管理部門に設置されており、電子化された複数のコンポーネントの管理や、外部の開発メーカへの開発委託に関する処理や、外部のベンダーに対する部品カタログ引用許諾に関する処理等をネットワークＮを介して行う。ここで、コンポーネントとは、製品を構成するハードウェアの図面、ファームウェア、各種プログラムや、仕様書、契約書等のように、製品の開発／設計から製造に至るまでに発生する電子化可能なものをいう。
【００４７】
コンポーネントデータベースＤＢ１は、電子化された複数のコンポーネントが階層構造（図２参照）をなすようにして構成されたものであり、記憶装置（図示略）に格納されている。これら複数のコンポーネントは、後述する登録系クライアント２０によりコンポーネントデータベースＤＢ１に登録される。
【００４８】
ここで、製品としてサーバを一例にとって、図２を参照してコンポーネントデータベースＤＢ１における階層構造について説明する。この図に示したように、サーバに関するコンポーネントデータベースＤＢ１は、第１層から第ｎ層（第３層）までの都合ｎ（３）段階の階層をなしている。第１層はトップ（最上位）の階層であり、ｎ層（第３層）は、ボトム（最下位）の階層である。なお、親コンポーネント図面ＰＫ、子コンポーネント図面ＣＫ1 〜ＣＫx 、子コンポーネント図面Ｄ11 〜子コンポーネント図面Ｄxx は、紙ドキュメントが電子化された電子データ、電子データそのもの（ファームウェア、プログラム等）である。
【００４９】
第１層に位置する親コンポーネント図面ＰＫは、親図面と呼ばれるものであり、サーバ（装置／ユニット）を構成する主要なｘ個の構成要素（以下、主要構成要素という）の一覧表に相当するものである。この主要構成要素としては、筐体、電源、プリント板等が挙げられる。また、親コンポーネント図面ＰＫには、「ＣＡ２０００１−００００」という識別用の親コンポーネント図番が付与されている。
【００５０】
第２層において、子コンポーネント図面ＣＫ1 〜ＣＫx のそれぞれは、親コンポーネント図面ＰＫにおけるｘ個の主要構成要素にリンクしており、主要構成要素を構成する複数のアイテム（ハードウェア部品、ファームウェア、仕様書、プログラム等）の一覧表に相当するものである。つまり、子コンポーネント図面ＣＫ1 〜ＣＫx は、親コンポーネント図面ＰＫに従属している。ここで注意すべきは、ハードウェア、ファームウェア、仕様書、プログラム等の別は問わず、いずれのアイテムも同一レベルのものとして扱われる。これらのアイテムとしては、ＰＲＯＭ、ファームウェア、コンデンサ、ＩＣ（Integrated Circuit）等が挙げられる。
【００５１】
また、これらの子コンポーネント図面ＣＫ1 〜ＣＫx のそれぞれには、識別用の子コンポーネント図番が付与されている。たとえば、子コンポーネント図面ＣＫx は、サーバの主要構成要素の一つであるプリント板に対応しており、子コンポーネント図面ＣＫx には、「ＣＡ２０００１−０００Ｘ」という識別用の子コンポーネント図番が付与されている。
【００５２】
第ｎ層（第３層）において、子コンポーネント図面Ｄ11 〜Ｄ1x のそれぞれは、子コンポーネント図面ＣＫ1 におけるｘ個のアイテムにリンクしており、ｘ個のアイテム（ハードウェア部品、ファームウェア等）に関する具体的な情報（設計図、ファームウェア自体、仕様書等）である。同様にして、子コンポーネント図面Ｄ21 〜Ｄ2x のそれぞれは、子コンポーネント図面ＣＫ2 におけるｘ個のアイテムにリンクしており、ｘ個のアイテム（ハードウェア部品、ファームウェア等）に関する具体的な情報（設計図、ファームウェア自体、仕様書等）である。
【００５３】
また、子コンポーネント図面Ｄx1 〜Ｄxx のそれぞれは、子コンポーネント図面ＣＫx におけるｘ個のアイテムにリンクしており、ｘ個のアイテム（ハードウェア部品、ファームウェア等）に関する具体的な情報（設計図、ファームウェア自体、仕様書等）である。ここで、子コンポーネント図面Ｄx1 は、子コンポーネント図面ＣＫx におけるＰＲＯＭ（アイテム）にリンクしており、このＰＲＯＭに関する仕様書である。つまり、ＰＲＯＭは、主要構成部品であるプリント板に実装されるアイテムである。また、子コンポーネント図面Ｄx1 には、「ＣＡ４１０００−１０００」という識別用の子コンポーネント図番が付与されている。
【００５４】
同様にして、子コンポーネント図面Ｄxx は、子コンポーネント図面ＣＫx におけるファームウェア（アイテム）にリンクしており、ファームウェア自体である。このファームウェアは、上記ＰＲＯＭに格納されるものであるが、ここではプリント板を構成する一つのアイテムとして扱われる。また、子コンポーネント図面Ｄxx には、「ＣＡ４１０００−１００Ｘ」という識別用の子コンポーネント図番が付与されている。このように、上述した子コンポーネント図面Ｄ11 〜Ｄ1x 、子コンポーネント図面Ｄ21 〜Ｄ2x および子コンポーネント図面Ｄx1 〜Ｄxx は、子コンポーネント図面ＣＫ1 〜ＣＫx にそれぞれ従属している。
【００５５】
また、図２に示した階層構造に関する情報は、図４に示したＸＭＬで記述されたメタ情報ファイルＦ1 としてコンポーネントデータベースＤＢ１のメタブロックに格納されている。図３は、メタ情報を説明する図である。この図に示したメタ情報ＳＫは、図２に示した子コンポーネント図面Ｄx1 （ＰＲＯＭ：ＣＡ４１０００−１０００）および子コンポーネント図面Ｄxx （ファームウェア：ＣＡ４１０００−１００Ｘ）に対応している。また、メタ情報ＳＫF は、メタ情報ＳＫにおける子コンポーネント図面Ｄxx （ファームウェア：ＣＡ４１０００−１００Ｘ）の詳細な情報である。
【００５６】
メタ情報ＳＫF において、「ｈｉｓｔｏｒｙ」の欄には、ファームウェアの履歴をＸＭＬで記述したファイルの名称「Ｈ９ＣＡ４１０００−１０００ａ．ｍｘｌ」が記述されている。「ＥＣＯ／ＮＲＮ」の欄には、後述する改版設計通知書（ＥＣＯ）または新規設計通知書（ＮＲＮ）をｘｍｌで記述したファイルの名称「Ｅ１ＣＡ４１０００−１０００ａ．ｘｍｌ」が記述されている。なお、他の欄に記載内容については、後に詳細に後述する。
【００５７】
図４に示したメタ情報ファイルＦ1 において、＜ＣＯＭＰＯＮＥＮＴ  ＮＡＭＥ＞タグの内容は、コンポーネントの名称（図２：プリント板（ＰＣＢ）参照）である。＜ＣＯＭＰＯＮＥＮＴ  ＮＵＭＢＥＲ＞タグの内容は、図２に示した子コンポーネント図面ＣＫx の子コンポーネント図番（ＣＡ２０００１−０００Ｘ）である。
【００５８】
＜ＰＡＲＴ  ＮＡＭＥ＞タグの内容は、ＰＣＢを構成するＰＲＯＭ、ファームウェア（図２：子コンポーネント図面Ｄx1 およびＤxx 参照）である。＜ＰＡＲＴ  ＮＵＭＢＥＲ＞タグの内容は、図２に示した子コンポーネント図面Ｄx1 およびＤxx のそれぞれの子コンポーネント図番（ＣＡ４１０００−１０００、ＣＡ４１０００−１０００Ｘ）である。＜ＷＥＢ  ＦＩＬＴＥＲ＞タグの内容については後述する。＜ＣＯＭＰＯＮＥＮＴ  ＭＯＤＵＬＥ＞タグの内容は、コンポーネント（ＰＲＯＭの設計図面等）のファイル名（ＣＡ２０００１−００００．ｐｓ、ＣＡ２０００１−００００．ｄｏｃ）である。これらの「ＣＡ２０００１−００００．ｐｓ」、「ＣＡ２０００１−００００．ｄｏｃ」のファイルはコンポーネントデータベースＤＢ１のデータブロックに格納されている。
【００５９】
図１に戻り、アドレス帳データベースＤＢ２は、後述する参照系クライアント３０、受領系クライアント４０、対称マシン５０、開発委託先クライアント６０およびベンダー側クライアント７０のそれぞれの電子メールアドレスからなるデータベースである。開発委託関連データベースＤＢ３は、後述する開発委託処理において用いられる各種ドキュメントからなるデータベースである。部品カタログ引用許諾関連データベースＤＢ４は、後述する部品カタログ引用許諾処理において用いられる各種ドキュメントからなるデータベースである。これらのアドレス帳データベースＤＢ２、開発委託関連データベースＤＢ３および部品カタログ引用許諾関連データベースＤＢ４の詳細については後述する。
【００６０】
参照系クライアント３０は、たとえば、工場に設置され、ブラウザを用いて、コンポーネントデータベースＤＢ１からコンポーネントをネットワークＮを介して参照する。受領系クライアント４０は、たとえば、工場に設置され、コンポーネントデータベースＤＢ１からコンポーネントをネットワークＮを介して受領する。対称マシン５０は、参照系クライアント３０および受領系クライアント４０の双方の機能を備えており、たとえば、工場に設置されている。
【００６１】
開発委託先クライアント６０は、外部の開発メーカに設置されており、後述する開発委託処理時に管理サーバ１０との間で通信を行う。ベンダー側クライアント７０は、部品を提供するベンダーに設置されており、後述する部品カタログ引用許諾処理時に管理サーバ１０との間で通信を行う。これらの開発委託先クライアント６０、ベンダー側クライアント７０の動作の詳細については後述する。
【００６２】
つぎに、一実施の形態における登録系処理について図５に示したフローチャートを参照しつつ説明する。ここでいう登録系処理は、主として、図１に示した登録系クライアント２０を用いて管理サーバ１０に対して各種情報の登録等を行う処理である。この登録系処理においては、管理サーバ１０は、図５に示したステップＳＡ１〜ステップＳＡ１０までの各イベント（採番処理、登録処理、・・・、部品カタログ引用許諾処理）を監視している。
【００６３】
図１に示した登録系クライアント２０からネットワークＮを介して管理サーバ１０にアクセスした状態で、登録系クライアント２０のブラウザが起動されると、登録系クライアント２０のディスプレイ２２には、図７に示した登録系画面Ｇ1 が表示される。これにより、登録系クライアント２０を操作している登録者は、図７に示した登録者情報入力欄Ｗ2 、電子メールアドレス入力欄Ｗ3 、設計者情報入力欄Ｗ4 、調査者情報入力欄Ｗ5 および承認者情報入力欄Ｗ6 にそれぞれの情報を入力する。
【００６４】
すなわち、登録者情報入力欄Ｗ2 には、登録者の氏名、所属が入力され、電子メールアドレス入力欄Ｗ3 には、登録者の電子メールアドレス（連絡先）が入力され、設計者情報入力欄Ｗ4 には、装置／ユニット等の設計者の氏名、所属が入力される。同様にして、調査者情報入力欄Ｗ5 には、調査者の氏名、所属が入力され、承認者情報入力欄Ｗ6 には、責任者の立場にある承認者の氏名、所属が入力される。
【００６５】
（採番処理）
このような状態において、登録者により採番処理が指定されると、採番処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ１の判断結果を「Ｙｅｓ」として、図６に示したステップＳＢ１〜ステップＳＢ１０までの採番処理を実行する。ここでいう採番処理とは、管理サーバ１０への登録対象（装置、ハードウェア、ファームウェア等）を親（または子）コンポーネント図面として登録するための親（または子）コンポーネント図番を採る処理をいう。
【００６６】
図６に示したステップＳＢ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＢ２へ進む。ステップＳＢ２では、管理サーバ１０は、装置／ユニット単位で採番するか否かを判断する。つまり、ステップＳＢ２では、親コンポーネント図面（図２参照）の採番を行うか否かが判断される。ステップＳＢ２の判断結果が「Ｙｅｓ」である場合、管理サーバ１０は、ステップＳＢ３へ進み、装置／ユニット用カウンタ（図示略）の値を読み取る。この装置／ユニット用カウンタは、ナンバリング機能を実現するためのものである。
【００６７】
ステップＳＢ５では、図７に示した採番表示欄Ｗ1 には、装置／ユニット用カウンタの値として、たとえば、親コンポーネント図番「ＣＡ２０００１−００００」（図２参照）が表示される。これにより、管理サーバ１０は、図５に示したメインルーチンへ戻った後、ステップＳＡ１の判断結果を「Ｙｅｓ」とし、さらに図６に示したステップＳＢ１の判断結果を「Ｎｏ」としてステップＳＢ６へ進む。
【００６８】
ステップＳＢ６では、管理サーバ１０は、採番表示欄Ｗ1 （図７参照）における親コンポーネント図番が確定したか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＢ７へ進む。なお、ステップＳＢ６の判断結果が「Ｎｏ」の場合、管理サーバ１０は、採番処理を終了する。ステップＳＢ７では、管理サーバ１０は、装置／ユニット単位で採番が行われたか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＢ８へ進む。
【００６９】
ステップＳＢ８では、管理サーバ１０は、装置／ユニット用カウンタ（図示略）を更新することにより、装置／ユニット用カウンタの値を次回の採番用の値とした後、ステップＳＢ１０へ進む。ステップＳＢ１０では、管理サーバ１０は、登録系クライアント２０より入力された採番担当者情報を登録した後、一連の採番処理を終了する。ここで、採番担当者情報としては、採番担当者（設計者等）の所属、氏名、電子メールのアドレス等がある。
【００７０】
一方、ステップＳＢ２の判断結果が「Ｎｏ」である場合、言い換えれば、装置／ユニット単位以外の単位で採番する場合、管理サーバ１０は、ステップＳＢ４へ進む。ここで、装置／ユニット単位以外の単位としては、図２に示したサーバ以外のもの（プリント板、ＰＲＯＭ、ファームウェア）が挙げられる。
【００７１】
ステップＳＢ４では、管理サーバ１０は、個別用カウンタ（図示略）の値を読み取る。この個別用カウンタは、装置／ユニット用カウンタと同様にして、ナンバリング機能を実現するためのものである。ステップＳＢ５では、図７に示した採番表示欄Ｗ1 には、個別用カウンタの値として、たとえば、子コンポーネント図番「ＣＡ２０００１−０００ｘ」（図２参照）が表示される。これにより、管理サーバ１０は、図５に示したメインルーチンへ戻った後、ステップＳＡ１の判断結果を「Ｙｅｓ」とし、さらに図６に示したステップＳＢ１の判断結果を「Ｎｏ」としてステップＳＢ６へ進む。
【００７２】
ステップＳＢ６では、管理サーバ１０は、採番表示欄Ｗ1 （図７参照）における子コンポーネント図番が確定したか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＢ７へ進む。ステップＳＢ７では、管理サーバ１０は、装置／ユニット単位で採番が行われたか否かを判断し、この場合、判断結果を「Ｎｏ」として、ステップＳＢ９へ進む。
【００７３】
ステップＳＢ９では、管理サーバ１０は、個別用カウンタ（図示略）を更新することにより、個別用カウンタの値を次回の採番用の値とした後、ステップＳＢ１０へ進む。ステップＳＢ１０では、管理サーバ１０は、前述と同様にして、登録系クライアント２０より入力された採番担当者情報を登録した後、一連の採番処理を終了する。
【００７４】
（登録処理）
つぎに、登録者により「登録処理」が指定されると、登録処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ２の判断結果を「Ｙｅｓ」として、図８に示したステップＳＣ１〜ステップＳＣ４までの登録処理を実行する。この登録処理においては、図２に示したような階層構造をなす複数のコンポーネント（構成部品表、論理回路図、構造図面、実装図面等）を登録する処理が実行される。
【００７５】
図８に示したステップＳＣ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＣ４へ進む。ステップＳＣ４では、管理サーバ１０は、登録系クライアント２０のディスプレイ２２に図９に示した登録メニュー画面Ｇ2 を表示させる。
【００７６】
これにより、登録者は、図９に示した入力欄に登録情報を入力する。すなわち、登録者は、ステップＳＡ１（図５参照）で採番された、たとえば、「ＣＡ２０００１−００００」という親コンポーネント図番を「登録コンポーネント図番」の入力欄に入力する。つぎに、登録者は、図９に示した「登録モジュール１」の入力欄に、たとえば、「ＣＡ２０００１−００００ａ．ｈ」という登録モジュールのファイル名を入力する。ここでいう登録モジュールは、コンポーネントを構成するものであり、例えば、ファームウェアのソースコード、ドキュメント（親コンポーネント図面、子コンポーネント図面、各種仕様書等）、パッチ情報等である。ここでいうパッチ情報は、ファームウェアを修正する際に用いられる情報である。
【００７７】
図９に示した例では、「登録モジュール１」に対応する「ＣＡ２０００１−００００ａ．ｈ」は、ファームウェアのソースコードに付与されたファイル名である。以下、登録者は、図９に示した「登録モジュール２」以降のそれぞれの入力欄に「ＣＡ２０００１−００００ａ．ｃ」、「ＣＡ２０００１−００００ａ．ｐｓ」、「ＣＡ２０００１−００００ａ．ｐａｔ」、・・・というファイル名を順次入力する。
【００７８】
ここで、「登録モジュール２」に対応する「ＣＡ２０００１−００００ａ．ｃ」は、ファームウェアのソースコードに付与されたファイル名であり、「登録モジュール３」に対応する「ＣＡ２０００１−００００ａ．ｐｓ」は、ドキュメントに付与されたファイル名である。同様にして、「登録モジュール４」に対応する「ＣＡ２０００１−００００ａ．ｐａｔ」は、パッチ情報に付与されたファイル名である。
【００７９】
なお、図９に示したソースコード、ドキュメント、パッチ情報等の登録モジュールは、たとえば、ＦＴＰ（File Transfer Protocol）にしたがって、図１に示した登録系クライアント２０からネットワークＮを介して管理サーバ１０へ登録処理の前にあらかじめ転送されている。さらに、転送された登録モジュールは、コンポーネントデータベースＤＢ１における所定のディレクトリ配下に格納されている。
【００８０】
そして、管理サーバ１０は、ステップＳＣ４で登録メニュー画面Ｇ2 の表示、および登録者による登録情報の入力が終了すると、図５に示したメインルーチンへ戻り、ステップＳＡ２の判断結果を「Ｙｅｓ」とし、図８に示したステップＳＣ１の判断結果を「Ｎｏ」とした後、ステップＳＣ２へ進む。ステップＳＣ２では、管理サーバ１０は、図９に示した登録情報（「ＣＡ２０００１−００００」、「ＣＡ２０００１−００００ａ．ｈ」、・・・）を読み込んだ後、ステップＳＣ３へ進む。ステップＳＣ３では、管理サーバ１０は、登録情報をコンポーネントデータベースＤＢ１のデータブロックに格納した後、図５に示したメインルーチンへ戻る。
【００８１】
（ＥＣＯ登録処理）
また、登録者により登録系クライアント２０で「ＥＣＯ登録処理」が指定されると、ＥＣＯ登録処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ３の判断結果を「Ｙｅｓ」として、図１０に示したステップＳＤ１〜ステップＳＤ９までのＥＣＯ登録処理を実行する。このＥＣＯ登録処理は、コンポーネントデータベースＤＢ１に登録済みのコンポーネントに改版が発生した場合に実行される。
【００８２】
すなわち、図１０に示したステップＳＤ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＤ２へ進む。ステップＳＤ２では、管理サーバ１０は、新ＥＣＯ番号（図１１に示した「ＥＣＯ／ＮＲＮ番号」を参照）を採番した後、ステップＳＤ３へ進む。この新ＥＣＯ番号は、コンポーネントの改版時に新たに付与されるものであり、改版されたコンポーネントを特定するためのものである。
【００８３】
ステップＳＤ３では、管理サーバ１０は、図１１に示したＮＲＮ／ＥＣＯ入力画面Ｇ3 を登録系クライアント２０のディスプレイ２２（図１参照）に表示させる。このＮＲＮ／ＥＣＯ入力画面Ｇ3 は、新規／改版設計通知書が電子化されたものであり、新規設計通知書（ＮＲＮ）の作成または改版設計通知書（ＥＣＯ）の作成に用いられる。
【００８４】
新規設計通知書（ＮＲＮ）は、新規にコンポーネント（親コンポーネント図面、子コンポーネント図面、ファームウェア等）がコンポーネントデータベースＤＢ１に新規登録された旨を図１に示した工場に設置された参照系クライアント３０、受領系クライアント４０へ通知するためのものである。一方、改版設計通知書（ＥＣＯ）は、コンポーネントデータベースＤＢ１に既に登録されているコンポーネントに改版が発生し、改版後のコンポーネントがコンポーネントデータベースＤＢ１に登録された旨を図１に示した工場に設置された参照系クライアント３０、受領系クライアント４０へ通知するためのものである。この場合、ＥＣＯ登録処理が実行されているため、ＮＲＮ／ＥＣＯ入力画面Ｇ3 は、改版設計通知書（ＥＣＯ）の作成に用いられる。
【００８５】
また、ＮＲＮ／ＥＣＯ入力画面Ｇ3 において、「送付先」の欄には、新規設計通知書（ＮＲＮ）または改版設計通知書（ＥＣＯ）の送付先が入力される。「図面番号」、「版」、「品名又は型格」、「メーカー」のそれぞれの欄には、親（または子）コンポーネント図面の図番、当該図面の版数、親（または子）コンポーネント図面に対応する部品の名称、当該部品のメーカ名がそれぞれ入力される。「１．変更箇所」、「２．改善理由」、「３．発生段階」、「４．発生部門」、「５．発生原因」のそれぞれのチェック欄には、新規設計または改版設計に関する詳細情報が列挙されており、該当するチェック欄には、チェックマークが記される。
【００８６】
そして、ＮＲＮ／ＥＣＯ入力画面Ｇ3 を登録系クライアント２０のディスプレイ２２に表示させると、管理サーバ１０は、図５に示したメインルーチンへ戻り、ステップＳＡ３の判断結果を「Ｙｅｓ」とし、図１０に示したステップＳＤ１の判断結果を「Ｎｏ」として、ステップＳＤ４へ進む。ステップＳＤ４では、管理サーバ１０は、ディスプレイ２２（図１参照）に図１１に示したＮＲＮ／ＥＣＯ入力画面Ｇ3 を表示させる。
【００８７】
これにより、登録者は、登録系クライアント２０を操作することにより、図１１に示したＮＲＮ／ＥＣＯ入力画面Ｇ3 に、改版設計通知に関する登録情報を入力する。ここでいう登録情報は、ＮＲＮ／ＥＣＯ入力画面Ｇ3 における「件名」、「代表機種名」、「図面番号」、「版」、「品名又は型格」、「メーカー」、「記事」、「送付先」、「１．変更箇所」等である。
【００８８】
そして、登録者による登録情報の入力が終了すると、ステップＳＤ５では、管理サーバ１０は、入力漏れや誤入力等に関する入力ミスチェックを行った後、ステップＳＤ６へ進む。ステップＳＤ６では、管理サーバ１０は、入力ミスチェックにおいてエラー（入力ミス）があるか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＤ７へ進む。なお、ステップＳＤ６の判断結果が「Ｙｅｓ」である場合、管理サーバ１０は、ステップＳＤ８へ進み、たとえば、「入力ミスです。」というエラーメッセージをディスプレイ２２に表示させた後、図５に示したメインルーチンへ戻る。
【００８９】
ステップＳＤ７では、管理サーバ１０は、改版設計通知書（ＥＣＯ）に関する情報を図１２に示したＸＭＬで記述されたＮＲＮ／ＥＣＯファイルＦ2 として、ＥＣＯデータベース（図示略）に格納した後、ステップＳＤ９へ進む。ここで、ＥＣＯデータベースは、図１に示したコンポーネントデータベースＤＢ１の一部の領域に確保されている。
【００９０】
また、図１２において、＜ＥＣＯ／ＮＲＮ＞タグは、ＮＲＮ／ＥＣＯファイルＦ2 が新規設計通知書（ＮＲＮ）に関するファイルであるか、または、改版設計通知書（ＥＣＯ）に関するファイルであるかを示すものである。具体的には、ＮＲＮ／ＥＣＯファイルＦ2 が新規設計通知書（ＮＲＮ）に関するファイルである場合、＜ＥＣＯ／ＮＲＮ＞タグの内容は、ＮＲＮである。一方、ＮＲＮ／ＥＣＯファイルＦ2 が改版設計通知書（ＥＣＯ）に関するファイルである場合、タグ＜ＥＣＯ／ＮＲＮ＞の内容は、ＥＣＯである。
【００９１】
＜配布先＞タグは、新規設計通知書（ＮＲＮ）または改版設計通知書（ＥＣＯ）の配布先を示すものであり、＜納入先＞タグは、装置／ユニット等の納入先を示すものである。また、＜変更理由＞タグは、新規設計または改版設計に伴う各種変更の理由を示すものであり、＜設計ミス＞タグ、＜障害発生＞タグ、＜障害改善＞タグ、＜仕様変更＞タグ、＜規格変更＞タグから構成されている。
【００９２】
これらの＜設計ミス＞タグ、＜障害発生＞タグ、・・・、＜規格変更＞タグは、新規設計または改版設計に伴う変更理由（設計ミス、障害発生、・・・、規格変更）の有無を示すものである。具体的には、＜設計ミス＞タグ、＜障害発生＞タグ、・・・、＜規格変更＞タグのそれぞれには、変更理由がある場合「１」が記され、変更理由がない場合、「０」が記される。図１３は、図１２に示したＮＲＮ／ＥＣＯファイルＦ2 を後述するディスプレイ３２またはディスプレイ４２に表示させた場合のＮＲＮ／ＥＣＯ画面Ｇ4 を示す図である。
【００９３】
図１０に示したステップＳＤ９では、管理サーバ１０は、改版設計通知書（ＥＣＯ）が正常に登録された旨を表す正常登録メッセージをディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻る。一方、ステップＳＤ６の判断結果が「Ｎｏ」である場合、管理サーバ１０は、ステップＳＤ８へ進み、たとえば、「入力ミスです。」というエラーメッセージをディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻る。
【００９４】
（ＮＲＮ登録処理）
また、登録者により登録系クライアント２０で「ＮＲＮ登録処理」が指定されると、ＮＲＮ登録処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ４の判断結果を「Ｙｅｓ」として、図１４に示したステップＳＥ１〜ステップＳＥ９までのＮＲＮ登録処理を実行する。このＮＲＮ登録処理は、コンポーネントデータベースＤＢ１に新規登録すべきコンポーネント（新規設計図面等）が発生した場合に実行される。
【００９５】
すなわち、図１４に示したステップＳＥ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＥ２へ進む。ステップＳＥ２では、管理サーバ１０は、新ＮＲＮ番号（図１１に示した「ＥＣＯ／ＮＲＮ番号」を参照）を採番した後、ステップＳＥ３へ進む。この新ＮＲＮ番号は、新規のコンポーネントに付与されるものであり、新規のコンポーネントを特定するためのものである。
【００９６】
ステップＳＥ３では、管理サーバ１０は、ステップＳＤ３（図１０参照）と同様にして、図１１に示したＮＲＮ／ＥＣＯ入力画面Ｇ3 を登録系クライアント２０のディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻り、ステップＳＡ４の判断結果を「Ｙｅｓ」とし、図１４に示したステップＳＥ１の判断結果を「Ｎｏ」として、ステップＳＥ４へ進む。ステップＳＥ４では、管理サーバ１０は、ディスプレイ２２（図１参照）に図１１に示したＮＲＮ／ＥＣＯ入力画面Ｇ3 を表示させる。
【００９７】
これにより、登録者は、前述したＥＣＯ登録処理と同様にして、登録系クライアント２０を操作することにより、図１１に示したＮＲＮ／ＥＣＯ入力画面Ｇ3 に、新規設計通知に関する登録情報を入力する。そして、登録者による登録情報の入力が終了すると、ステップＳＥ５では、管理サーバ１０は、入力漏れや誤入力等に関する入力ミスチェックを行った後、ステップＳＥ６へ進む。ステップＳＥ６では、管理サーバ１０は、入力ミスチェックにおいてエラー（入力ミス）があるか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＥ７へ進む。
【００９８】
ステップＳＥ７では、管理サーバ１０は、新規設計通知書（ＮＲＮ）に関する情報を図１２に示したＸＭＬで記述されたＮＲＮ／ＥＣＯファイルＦ2 として、ＮＲＮデータベース（図示略）に格納した後、ステップＳＥ９へ進む。ここで、ＮＲＮデータベースは、図１に示したコンポーネントデータベースＤＢ１の一部の領域に確保されている。この場合、図１２に示したＮＲＮ／ＥＣＯファイルＦ2 においては、＜ＥＣＯ／ＮＲＮ＞タグの内容は、ＮＲＮである。
【００９９】
ステップＳＥ９では、管理サーバ１０は、新規設計通知書（ＮＲＮ）が正常に登録された旨を表す正常登録メッセージをディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻る。一方、ステップＳＥ６の判断結果が「Ｙｅｓ」である場合、管理サーバ１０は、ステップＳＥ８へ進み、たとえば、「入力ミスです。」というエラーメッセージをディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻る。
【０１００】
（コンポーネントストラクチャ処理）
また、登録者により登録系クライアント２０で「コンポーネントストラクチャ処理」が指定されると、コンポーネントストラクチャ処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ５の判断結果を「Ｙｅｓ」として、図１５に示したステップＳＦ１〜ステップＳＦ９までのコンポーネントストラクチャ処理を実行する。このコンポーネントストラクチャ処理は、登録処理（図５および図８参照）で登録されたコンポーネントを図２に示したように階層構造化する処理である。
【０１０１】
ここで、コンポーネントデータベースＤＢ１のデータブロックには、図２に示した親コンポーネント図面ＰＫ 、子コンポーネント図面ＣＫ1 〜ＣＫx 、子コンポーネント図面Ｄ11 〜Ｄxx がそれぞれ登録されているものとする。この場合、図１５に示したステップＳＦ１では、管理サーバ１０は、コンポーネントデータベースＤＢ１から親コンポーネント図面ＰＫの図番（「ＣＡ２０００１−００００」）を取り出した後、ステップＳＦ２へ進む。ステップＳＦ２では、管理サーバ１０は、図２に示した親コンポーネント図面ＰＫを第２層の子コンポーネント図面ＣＫ1 〜ＣＫx と第ｎ層の子コンポーネント図面Ｄ11 〜Ｄxx に分解した後、ステップＳＦ３へ進む。
【０１０２】
ステップＳＦ３では、管理サーバ１０は、親コンポーネント図面ＰＫに基づいて、子コンポーネント数、すなわち、子コンポーネント図面ＣＫ1 〜ＣＫx の数ｘをコンポーネントデータベースＤＢ１に格納した後、ステップＳＦ４へ進む。ステップＳＦ４では、管理サーバ１０は、図２に示した第２層における子コンポーネント図面ＣＫ1 の子コンポーネント図番をキーとして、コンポーネントデータベースＤＢ１（図１参照）のデータブロックを検索した後、ステップＳＦ５へ進む。
【０１０３】
ステップＳＦ５では、管理サーバ１０は、ステップＳＦ４における検索結果にに基づいて、コンポーネントデータベースＤＢ１のデータブロックに子コンポーネント図面ＣＫ1 が登録されているか否かを判断する。この場合、管理サーバ１０は、ステップＳＦ５の判断結果を「Ｙｅｓ」として、ステップＳＦ７へ進む。なお、ステップＳＦ５の判断結果が「Ｎｏ」である場合、管理サーバ１０は、ステップＳＦ６へ進む。ステップＳＦ６では、管理サーバ１０は、「＊＊＊＊＊（子コンポーネント図番）に対応する図面は登録されていません。」という未登録メッセージをディスプレイ２２（図１参照）に表示させた後、ステップＳＦ７へ進む。
【０１０４】
ステップＳＦ７では、管理サーバ１０は、図２に示した第２層に関するすべての検索が終了したか否かを判断し、この場合、判断結果を「Ｎｏ」として、ステップＳＦ４へ戻る。ステップＳＦ４では、管理サーバ１０は、図２に示した第２層におけるつぎの子コンポーネント図面ＣＫ2 の子コンポーネント図番をキーとして、コンポーネントデータベースＤＢ１（図１参照）のデータブロックを検索した後、ステップＳＦ５へ進む。以後、管理サーバ１０は、ステップＳＦ７の判断結果が「Ｙｅｓ」となるまで、上述した動作を繰り返す。
【０１０５】
そして、図２に示した第２層の子コンポーネント図面ＣＫx の検索が終了すると、管理サーバ１０は、ステップＳＦ７の判断結果を「Ｙｅｓ」として、ステップＳＦ８へ進む。ステップＳＦ８では、管理サーバ１０は、図２に示した第ｎ層（ボトム層）に関するすべての検索が終了したか否かを判断し、この場合、判断結果を「Ｎｏ」として、ステップＳＦ４へ戻る。以後、ステップＳＦ４以降では、管理サーバ１０は、第２層の場合と同様にして、図２に示した第ｎ層の子コンポーネント図面Ｄ11 〜Ｄxx に関する検索を順次実行する。
【０１０６】
そして、図２に示した第ｎ層の子コンポーネント図面Ｄxx に関する検索が終了すると、管理サーバ１０は、ステップＳＦ８の判断結果を「Ｙｅｓ」として、ステップＳＦ９へ進む。これにより、図２に示したように、親コンポーネント図面ＰＫ 、子コンポーネント図面ＣＫ1 〜ＣＫx 、子コンポーネント図面Ｄ11 〜Ｄxx が階層構造化される。ステップＳＦ９では、管理サーバ１０は、たとえば、「コンポーネントストラクチャ処理はすべて完了しました。」という完了メッセージをディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻る。
【０１０７】
（廃図処理）
また、登録者により登録系クライアント２０で「廃図処理」が指定されると、廃図処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ６の判断結果を「Ｙｅｓ」として、図１６に示したステップＳＧ１〜ステップＳＧ５までの廃図処理を実行する。この廃図処理は、コンポーネントデータベースＤＢ１（図１参照）のデータブロックに登録済みのコンポーネント（設計図面、ファームウェア等）を削除する処理である。
【０１０８】
すなわち、登録者により登録系クライアント２０で廃図すべきコンポーネントに対応するコンポーネント図番が指定されると、管理サーバ１０は、図１６に示したステップＳＧ１へ進む。たとえば、図２に示した子コンポーネント図面Ｄxxの子コンポーネント図番（「ＣＡ４１０００−１００Ｘ」）が登録者により指定されると、ステップＳＧ１では、管理サーバ１０は、上記子コンポーネント図番（「ＣＡ４１０００−１００Ｘ」）をキーとして、コンポーネントデータベースＤＢ１のデータブロックにおけるコンポーネント図番を検索対象として検索した後、ステップＳＧ２へ進む。
【０１０９】
ステップＳＧ２では、管理サーバ１０は、ステップＳＧ１における検索結果がヒットであるか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＧ３へ進む。ステップＳＧ３では、管理サーバ１０は、コンポーネントデータベースＤＢ１のデータブロックにおけるつぎのコンポーネント図番を検索対象として検索を開始した後、ステップＳＧ１へ戻り、上述した検索動作を繰り返す。
【０１１０】
そして、廃図指定された子コンポーネント図番（「ＣＡ４１０００−１００Ｘ」）がコンポーネントデータベースＤＢ１のデータブロックに存在した場合、管理サーバ１０は、ステップＳＧ２の判断結果を「Ｙｅｓ」として、ステップＳＧ４へ進む。ステップＳＧ４では、管理サーバ１０は、廃図指定された子コンポーネント図番データ、すなわち、「ＣＡ４１０００−１００Ｘ」が付与された子コンポーネント図面Ｄxx （図２参照）をコンポーネントデータベースＤＢ１のデータブロックから削除した後、ステップＳＧ５へ進む。
【０１１１】
ステップＳＧ５では、管理サーバ１０は、コンポーネントデータベースＤＢ１のメタブロックに格納されているメタ情報ファイルＦ1 （図４参照）に＜廃図＞タグを記述した後、図５に示すメインルーチンへ戻る。具体的には、管理サーバ１０は、ＸＭＬにて＜廃図＞タグの内容を「１」にする。
【０１１２】
（登録系重要度設定処理）
また、登録者により登録系クライアント２０で「登録系重要度設定処理」が指定されると、登録系重要度設定処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ７の判断結果を「Ｙｅｓ」として、図１７に示したステップＳＨ１〜ステップＳＨ７までの登録系重要度設定処理を実行する。
【０１１３】
すなわち、図１７に示したステップＳＨ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＨ２へ進む。ステップＳＨ２では、管理サーバ１０は、図１８に示したサブメニュー画面Ｇ5 をディスプレイ２２（図１参照）に表示させた後、図５に示したメインルーチンへ戻る。これにより、登録者は、図１８に示したサブメニュー画面Ｇ5 における「配布対象モデル」の入力欄、「配布対象製造番号」の入力欄および「配布対象先」の入力欄にそれぞれデータを入力する。
【０１１４】
この場合、「配布対象モデル」の入力欄には、装置／ユニットのモデル名として「Ｘ８７７７Ｓ」、「Ｘ８７７７Ｄ」および「Ｘ８７７７Ｚ」がそれぞれ入力される。「配布対象製造番号」の入力欄には、装置／ユニットの製造番号として「００１００」〜「０１２３３」がそれぞれ入力される。「配布対象先」の入力欄には、「＊」および「ＡＢＣ  Ｃｏ．ＬＴＤ．」が入力される。
【０１１５】
ここで、「配布対象先」とは、コンポーネント（設計図面、ファームウェア等）を配布すべき会社名、部署等をいう。また、「＊」が入力された場合には、「ＡＢＣ  Ｃｏ．ＬＴＤ．」以外のすべての会社、部署等がコンポーネントの配布先となる。つまり、「＊」が入力された場合には、「ＡＢＣ  Ｃｏ．ＬＴＤ．」のみがコンポーネントの配布先から除外される。
【０１１６】
一方、「＊」が入力されない場合には、「ＡＢＣ  Ｃｏ．ＬＴＤ．」のみがコンポーネントの配布先となる。また、登録者は、設定対象となるコンポーネントに対応するコンポーネント図番を登録系クライアント２０より入力する。この場合、登録者は、図２に示した子コンポーネント図面ＣＫx の子コンポーネント図番（「ＣＡ２０００１−０００Ｘ」）を登録系クライアント２０より入力したものとする。
【０１１７】
上記入力が終了すると、管理サーバ１０は、図５に示したステップＳＡ７の判断結果を「Ｙｅｓ」とし、図１７に示したステップＳＨ１の判断結果を「Ｎｏ」とした後、ステップＳＨ３へ進む。ステップＳＨ３では、管理サーバ１０は、登録者により入力されたコンポーネント図番に対応するコンポーネント図面に関するメタ情報ファイルを図１に示したコンポーネントデータベースＤＢ１のメタブロックから読む込む。
【０１１８】
この場合、図２に示した子コンポーネント図番（「ＣＡ２０００１−０００Ｘ」）が登録者により入力されているため、管理サーバ１０は、図４に示したメタ情報ファイルＦ1 を読み込んだ後、ステップＳＨ４へ進む。なお、この時点では、図４に示した＜ＷＥＢ  ＦＩＬＴＥＲ＞タグおよびその内容がメタ情報ファイルＦ1 に埋め込まれていない。
【０１１９】
ステップＳＨ４では、管理サーバ１０は、図４に示したメタ情報ファイルＦ1 に図１８に示した「配布対象モデル」（＝「Ｘ８７７７Ｓ」、「Ｘ８７７７Ｄ」および「Ｘ８７７７Ｚ」）を埋め込む。具体的には、管理サーバ１０は、図４に示した＜ＷＥＢ  ＦＩＬＴＥＲ＞タグおよび＜ＭＯＤＥＬ＞タグを記述した後、＜ＭＯＤＥＬ＞タグの内容として「ｘ８７７７Ｓ」、「ｘ８７７７Ｄ」および「ｘ８７７７ｚ」を記述した後、ステップＳＨ５へ進む。
【０１２０】
ステップＳＨ５では、管理サーバ１０は、図４に示したメタ情報ファイルＦ1 に図１８に示した「配布対象製造番号」（＝「００１００」〜「０１２３３」）を埋め込む。具体的には、管理サーバ１０は、図４に示した＜ＷＥＢ  ＦＩＬＴＥＲ＞タグ内に＜ＳＥＲＩＡＬ  ＮＯ＞タグを記述した後、＜ＳＥＲＩＡＬ  ＮＯ＞タグの内容として「００１００−０１２３３」を記述した後、ステップＳＨ６へ進む。
【０１２１】
ステップＳＨ６では、管理サーバ１０は、図４に示したメタ情報ファイルＦ1 に図１８に示した「配布対象先」（＝「＊」および「ＡＢＣ  Ｃｏ．ＬＴＤ．」を埋め込む。具体的には、管理サーバ１０は、図４に示した＜ＷＥＢ  ＦＩＬＴＥＲ＞タグ内に＜ＵＳＥＲ＞タグを記述した後、＜ＵＳＥＲ＞タグの内容として「＊ＡＢＣ  Ｃｏ．ＬＴＤ」を記述した後、ステップＳＨ７へ進む。ステップＳＨ７では、管理サーバ１０は、上述した配布対象モデル、配布対象製造番号、配布対象先が埋め込めれたメタ情報ファイルＦ1 を図１に示したコンポーネントデータベースＤＢ１のメタブロックに格納した後、図５に示したメインルーチンへ戻る。
【０１２２】
（通知処理）
また、図５に示したＥＣＯ登録処理（またはＮＲＮ登録処理）、コンポーネントストラクチャ処理および登録系重要度設定処理が終了した後、登録者により登録系クライアント２０で「通知処理」が指定されると、通知処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ８の判断結果を「Ｙｅｓ」として、図１９に示したステップＳＩ１〜ステップＳＩ６までの通知処理を実行する。
【０１２３】
この通知処理は、ＥＣＯ登録処理またはＮＲＮ登録処理が終了した旨、言い換えれば、図１１に示した改版設計通知書（ＥＣＯ）または新規設計通知書（ＮＲＮ）が発行された旨を、図１に示した参照系クライアント３０、受領系クライアント４０へ通知する処理である。
【０１２４】
すなわち、図１９に示したステップＳＩ１では、管理サーバ１０は、ＥＣＯ登録処理（またはＮＲＮ登録処理）により登録されたコンポーネント図番をコンポーネントデータベースＤＢ１から読み出す。この場合、管理サーバ１０は、図２に示した子コンポーネント図面ＣＫx の子コンポーネント図番（「ＣＡ２０００１−０００Ｘ」）を読み出した後、ステップＳＩ２へ進む。
【０１２５】
ステップＳＩ２では、管理サーバ１０は、子コンポーネント図番（「ＣＡ２０００１−０００Ｘ」）に対応する図４に示したメタ情報ファイルＦ1 をコンポーネントデータベースＤＢ１のメタブロックから読み出した後、ステップＳＩ３へ進む。ステップＳＩ３では、管理サーバ１０は、図４に示したメタ情報ファイルＦ1 における＜ＵＳＥＲ＞タグを読み込んだ後、ステップＳＩ３へ進む。この場合、＜ＵＳＥＲ＞タグの内容は、「＊ＡＢＣ  Ｃｏ．ＬＴＤ」であり、前述した登録系重要度設定処理により設定された配布対象先（図１８参照）である。
【０１２６】
ステップＳＩ４では、管理サーバ１０は、ステップＳＩ３で読み込んだ＜ＵＳＥＲ＞タグの内容（「＊ＡＢＣ  Ｃｏ．ＬＴＤ」）に「＊」があるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＩ５へ進む。ステップＳＩ５では、管理サーバ１０は、アドレス帳データベースＤＢ２（図１参照）に基づいて、配布対象先である「ＡＢＣ  Ｃｏ．ＬＴＤ」に対応する指定アドレス以外のすべてのアドレス宛に電子メールを送信する。
【０１２７】
ここで送信される電子メールは、クライアントに対してＥＣＯ登録処理（またはＮＲＮ登録処理）が行われた旨を通知するためのものである。この場合、アドレス帳データベースＤＢ２において「＊」が付された「ａａｂｂｃｃ＠ＡＢＣ．ｃｏ．ｊｐ」というアドレスが、「ＡＢＣ  Ｃｏ．ＬＴＤ」会社に設置されたクライアント（図示略）のアドレスであるものとすると、管理サーバ１０は、アドレス帳データベースＤＢ２におけるアドレス「ａａｂｂｃｃ＠ＡＢＣ．ｃｏ．ｊｐ」以外のすべてのアドレスへ電子メールを送信する。
【０１２８】
具体的には、図１に示した管理サーバ１０は、参照系クライアント３０のアドレスおよび受領系クライアント４０のアドレスへ電子メールＥ30 および電子メールＥ40 をネットワークＮを介して送信した後、図５に示したメインルーチンへ戻る。ただし、参照系クライアント３０および受領系クライアント４０のそれぞれのアドレスは、指定アドレス「ａａｂｂｃｃ＠ＡＢＣ．ｃｏ．ｊｐ」以外のアドレスである。なお、電子メールＥ30 および電子メールＥ40 を参照系クライアント３０および受領系クライアント４０が受信した後の処理については、図２３に示したフローチャートを参照して後述する。
【０１２９】
また、図４に示した＜ＵＳＥＲ＞タグの内容が、たとえば、「ＡＢＣ  Ｃｏ．ＬＴＤ」である場合、つまり、＜ＵＳＥＲ＞タグの内容に「＊」が含まれていない場合、管理サーバ１０は、図１９に示したステップＳＩ４の判断結果を「Ｎｏ」として、ステップＳＩ６へ進む。ステップＳＩ６では、管理サーバ１０は、「ＡＢＣ  Ｃｏ．ＬＴＤ」会社に対応する指定アドレス「ａａｂｂｃｃ＠ＡＢＣ．ｃｏ．ｊｐ」宛に電子メールを送信した後、図５に示したメインルーチンへ戻る。これにより、「ＡＢＣ  Ｃｏ．ＬＴＤ」会社に設置されたクライアント（図示略）のみに対して、上記電子メールによりＥＣＯ登録処理（またはＮＲＮ登録処理）が行われた旨が通知される。
【０１３０】
（開発委託処理）
また、登録者により登録系クライアント２０で「開発委託処理」が指定されると、開発委託処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ９の判断結果を「Ｙｅｓ」として、図２０に示したステップＳＪ１〜ステップＳＪ１０までの開発委託処理を実行する。この開発委託処理は、外部の開発メーカに対して製品開発の一部（または全部）を委託する処理である。
【０１３１】
図２０に示したステップＳＪ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＪ２へ進む。ステップＳＪ２では、管理サーバ１０は、ＤＴＤ（Document Type Definition）を図１に示した開発委託関連データベースＤＢ３から読み込んだ後、ステップＳＪ３へ進む。このＤＴＤは、ＸＭＬで記述されたファイルにおけるタグを定義するものである。
【０１３２】
ステップＳＪ３では、管理サーバ１０は、開発委託関連データベースＤＢ３からＸＭＬで記述されたメーカ一覧のファイルを読み込み、ＤＴＤによりタグを解釈した後、メーカ一覧をディスプレイ２２に表示させる。このメーカ一覧（図示略）は、外部の開発メーカの名称、連絡先（電子メールアドレス、住所、電話番号等）に関する一覧である。これにより、登録者は、図１に示した登録系クライアント２０を操作することにより、ディスプレイ２２に表示されているメーカ一覧の中から一つの開発メーカを開発委託先の候補として選択する。そして、管理サーバ１０は、図５に示したメインルーチンへ戻り、ステップＳＡ９の判断結果を「Ｙｅｓ」とし、図２０に示したステップＳＪ１の判断結果を「Ｎｏ」とした後、ステップＳＪ４へ進む。
【０１３３】
ステップＳＪ４では、管理サーバ１０は、開発メーカからの応答があるか否かを判断する。ここでいう応答は、開発を受託するか否かである。この場合、開発委託を行っていないため、管理サーバ１０は、ステップＳＪ４の判断結果を「Ｎｏ」として、ステップＳＪ５へ進む。ステップＳＪ５では、管理サーバ１０は、登録者により、メーカ一覧の中から選択された開発メーカの情報を読み取った後、ステップＳＪ６へ進む。
【０１３４】
ステップＳＪ６では、管理サーバ１０は、開発委託に関する契約雛型（図示略）の情報を開発委託関連データベースＤＢ３から引き出した後、この契約雛型に、選択された開発メーカ名を入れた後、ステップＳＪ６へ進む。この契約雛型は、開発委託に関する契約条項文書、契約書等であり、一例として、「＊＊＊社は、〇〇〇社に対して開発関連技術の機密を守ります。・・・」という文面からなる。「＊＊＊」の部分には、選択された開発メーカ名が入れられる。これにより、開発委託に関する契約条項文書や契約書が作成される。
【０１３５】
ステップＳＪ７では、管理サーバ１０は、選択された開発メーカに設置されている、たとえば、図１に示した開発委託先クライアント６０のアドレス宛に電子メールを送信した後、図５に示したメインルーチンへ戻る。この電子メールの内容は、開発委託を依頼する旨である。具体的には、図１に示した管理サーバ１０は、ネットワークＮを介して開発委託先クライアント６０のアドレス宛に電子メールＥ60A を送信する。そして、管理サーバ１０は、図５に示したステップＳＡ９の判断結果を「Ｙｅｓ」とし、ステップＳＪ１の判断結果を「Ｎｏ」とした後、ステップＳＪ４へ進む。ステップＳＪ４では、管理サーバ１０は、開発委託に関する応答が開発メーカからあるか否かを判断する。
【０１３６】
そして、開発委託先クライアント６０により電子メールＥ60A が受信されると、開発メーカでは、開発を受託するか否かが決定され、その決定内容が電子メールＥ60B としてネットワークＮを介して管理サーバ１０へ送信される。開発を受託した場合、電子メールＥ60B の内容は、たとえば、「＊＊＊社は、〇〇〇の開発を受託致します。・・・」である。この電子メールＥ60B が受信されると、管理サーバ１０は、ステップＳＪ４の判断結果を「Ｙｅｓ」として、ステップＳＪ８へ進む。ステップＳＪ８では、管理サーバ１０は、電子メールＥ60B の内容に基づいて、当該開発メーカが開発を受託したか否かを判断し、受託した場合、判断結果を「Ｙｅｓ」として、ステップＳＪ９へ進む。
【０１３７】
ステップＳＪ９では、管理サーバ１０は、ステップＳＪ６で作成された契約条項文書や契約書等の関連ドキュメントを読み込んだ後、図１９に示したステップＳＩ１へ進む。ステップＳＩ１では、管理サーバ１０は、開発メーカへ開発委託すべきコンポーネント図番をコンポーネントデータベースＤＢ１から読み出した後、ステップＳＩ２へ進む。
【０１３８】
ステップＳＩ２では、管理サーバ１０は、当該コンポーネント図番に対応するメタ情報ファイルをコンポーネントデータベースＤＢ１のメタブロックから読み出した後、ステップＳＩ３およびステップＳＩ４をスキップして、ステップＳＩ６へ進む。ステップＳＩ６では、管理サーバ１０は、ステップＳＪ９で読み込んだ関連ドキュメント（契約条項文書、契約書等）およびメタ情報ファイルに対応するコンポーネント（設計図面、ファームウェア等）を図１に示した電子メールＥ60A に添付してネットワークＮを介して開発委託先クライアント６０へ送信する。
【０１３９】
これにより、開発メーカでは、契約条項文書および契約書に基づいて、開発委託されたコンポーネントの開発を行う。そして、開発が完了すると、開発メーカは、開発委託先クライアント６０から管理サーバ１０へ開発済みのコンポーネント（ファームウェア等）を送信することにより、電子納品を行う。なお、一実施の形態においては、コンポーネントが記録された記録媒体を介して電子納品を行ってもよい。
【０１４０】
一方、図２０に示したステップＳＪ８の判断結果が「Ｎｏ」である場合、すなわち、開発委託の要請先の開発メーカが受託を拒否した場合、管理サーバ１０は、ステップＳＪ１０へ進む。ステップＳＪ１０では、管理サーバ１０は、他の開発メーカを選択することを指示するための他メーカ選択指示メッセージをディスプレイ２２に表示させた後、図５に示したメインルーチンへ戻る。これにより、登録者は、メーカ一覧（ステップＳＪ３参照）の中から他の開発メーカを選択する。以後、上述したように、選択された他の開発メーカに関する一連の処理が実行される。
【０１４１】
（部品カタログ引用許諾処理）
また、登録者により登録系クライアント２０で「部品カタログ引用許諾処理」が指定されると、部品カタログ引用許諾処理のイベントが発生するため、管理サーバ１０は、図５に示したステップＳＡ１０の判断結果を「Ｙｅｓ」として、図２１に示したステップＳＫ１〜ステップＳＫ１０までの部品カタログ引用許諾処理を実行する。
【０１４２】
この部品カタログ引用許諾処理は、図２２に示した部品カタログＣおよび許諾ライセンスＬに関する情報を部品カタログ情報ファイルＦ3 として部品カタログ引用許諾関連データベースＤＢ４（図１参照）に、部品カタログＣを作成したベンダーの許可を得た上で登録し、これを管理サーバ１０により管理する処理である。
【０１４３】
部品カタログＣは、装置／ユニットの製造に必要な部品（ハードウェア部品、ファームウェア等）に関するカタログであり、図１に示したベンダー側クライアント７０にデータベースとして格納されている。なお、部品カタログＣは、紙媒体でベンダーからメーカへ提供される場合もある。許諾ライセンスＬは、ベンダーが著作権を有する部品カタログＣを、管理サーバ１０の部品カタログ引用許諾関連データベースＤＢ４で引用することを許諾する旨の許諾情報である。部品カタログ情報ファイルＦ3 は、部品カタログＣの情報および許諾ライセンスＬをＸＭＬで記述したものである。
【０１４４】
部品カタログ情報ファイルＦ3 において、＜ｖｅｎｄｏｒ＞タグの内容は、部品カタログＣが格納されているベンダー側クライアント７０のＵＲＬ（Uniform Resource Locator）である。＜ベンダ名＞タグの内容は、部品カタログＣを発行しているベンダーの名称（ｘｙｚ  ｃｏｒｐ）である。＜型番＞の内容は、部品カタログＣに付与された型番（０４９２６−４４２１）である。＜版数＞は、部品カタログＣの版数（０１）である。＜許諾＞タグの内容は、部品カタログＣを部品カタログ引用許諾関連データベースＤＢ４で引用することに関する許諾の可否フラグである。
【０１４５】
すなわち、許諾された場合には、＜許諾＞タグにフラグ「１」が設定され、許諾されなかった場合には、＜許諾＞タグにフラグ「０」が設定される。＜ＣＯＭＰＯＮＥＮＴ  ＭＯＤＵＬＥ＞フラグの内容は、部品カタログＣの内容を表す＜ＭＯＤＵＬＥ＞タグである。具体的には、＜ＭＯＤＵＬＥ＞タグの内容は、部品カタログＣの内容に関するファイル（ＣＡＴ２１２２９．ｄｏｃ）である。このファイル以外にも、ｐｓ（post script）形式、ＸＭＬ形式、ＨＴＭＬ（hypertext markup language）形式、ｐｄｆ（portable document format）形式等のファイルが＜ＭＯＤＵＬＥ＞タグ内に記述される。
【０１４６】
図２１に示したステップＳＫ１では、管理サーバ１０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＫ２へ進む。ステップＳＫ２では、管理サーバ１０は、ＤＴＤを図１に示した部品カタログ引用許諾関連データベースＤＢ４から読み込んだ後、ステップＳＫ３へ進む。このＤＴＤは、図２２に示した部品カタログ情報ファイルＦ3 におけるタグを定義するものである。
【０１４７】
ステップＳＫ３では、管理サーバ１０は、部品カタログ引用許諾関連データベースＤＢ４から部品カタログを提供しているベンダーの一覧をＸＭＬで記述したファイルを読み込み、ＤＴＤによりタグを解釈した後、ベンダー一覧（図示略）をディスプレイ２２に表示させる。このベンダー一覧は、ベンダーの名称、連絡先（電子メールアドレス、住所、電話番号等）に関する一覧である。これにより、登録者は、図１に示した登録系クライアント２０を操作することにより、ディスプレイ２２に表示されているベンダー一覧の中から一つのベンダーを部品カタログに関する引用許諾の依頼先の候補として選択する。そして、管理サーバ１０は、図５に示したメインルーチンへ戻り、ステップＳＡ１０の判断結果を「Ｙｅｓ」とし、図２１に示したステップＳＫ１の判断結果を「Ｎｏ」とした後、ステップＳＫ４へ進む。
【０１４８】
ステップＳＫ４では、管理サーバ１０は、ベンダーからの応答があるか否かを判断する。ここでいう応答は、部品カタログを部品カタログ引用許諾関連データベースＤＢ４に引用することを許諾するか否かである。この場合、ベンダーに対して、引用許諾の依頼をかけていないため、管理サーバ１０は、ステップＳＫ４の判断結果を「Ｎｏ」として、ステップＳＫ５へ進む。ステップＳＫ５では、管理サーバ１０は、登録者により指定されたベンダーの情報を読み取った後、ステップＳＫ６へ進む。
【０１４９】
ステップＳＫ６では、管理サーバ１０は、許諾に関する許諾雛型の情報を部品カタログ引用許諾関連データベースＤＢ４から引き出した後、この許諾雛型（図示略）に、指定されたベンダー名を入れた後、ステップＳＫ６へ進む。この許諾雛型は、許諾書のフォーマット文書であり、一例として、「＊＊＊殿、当社のカタログｘｙｚを貴社で引用することを許可致します。〇〇〇社」という文面からなる。「〇〇〇」の部分には、指定されたベンダー名が入れられる。これにより、許諾書が作成される。
【０１５０】
ステップＳＫ７では、管理サーバ１０は、選択されたベンダーに設置されている、たとえば、図１に示したベンダー側クライアント７０のアドレス宛に、上述した許諾書が添付された電子メールを送信した後、図５に示したメインルーチンへ戻る。この電子メール内容は、部品カタログＣを引用することに関する許諾を受けたい旨である。具体的には、図１に示した管理サーバ１０は、ネットワークＮを介してベンダー側クライアント７０のアドレス宛に電子メールＥ70A を送信する。そして、管理サーバ１０は、図５に示したステップＳＡ１０の判断結果を「Ｙｅｓ」とし、ステップＳＫ１の判断結果を「Ｎｏ」とした後、ステップＳＫ４へ進む。ステップＳＫ４では、管理サーバ１０は、引用許諾に関する応答がベンダーからあるか否かを判断する。
【０１５１】
そして、ベンダー側クライアント７０により電子メールＥ70A が受信されると、ベンダーでは、部品カタログＣの引用を許諾するか否かが決定され、その決定内容が電子メールＥ70B としてネットワークＮを介して管理サーバ１０へ送信される。引用が許諾された場合には、許諾書が添付された電子メールＥ70B がベンダー側クライアント７０からネットワークＮを介して管理サーバ１０へ送信される。一方、引用が許諾されなかった場合には、許諾しない旨の内容からなる電子メールＥ70B がベンダー側クライアント７０からネットワークＮを介して管理サーバ１０へ送信される。
【０１５２】
そして、電子メールＥ70B が受信されると、管理サーバ１０は、ステップＳＫ４の判断結果を「Ｙｅｓ」として、ステップＳＫ８へ進む。ステップＳＫ８では、管理サーバ１０は、電子メールＥ70B の内容に基づいて、当該ベンダーが部品カタログＣの引用を許諾したか否かを判断し、許諾した場合、判断結果を「Ｙｅｓ」として、ステップＳＫ１０へ進む。
【０１５３】
ステップＳＫ１０では、管理サーバ１０は、図２２に示した部品カタログ情報ファイルＦ3 における＜許諾＞タグにフラグ「１」を設定した後、許諾内容（部品カタログ情報ファイルＦ3 ）を部品カタログ引用許諾関連データベースＤＢ４に格納する。そして、管理サーバ１０は、図５に示したメインルーチンへ戻る。ここで、部品カタログ情報ファイルＦ3 における＜ＭＯＤＵＬＥ＞タグの内容（部品カタログＣの内容に関するファイル）は、＜ｖｅｎｄｏｒ＞タグ内のＵＲＬに基づいて、ベンダー側のデータベースから取得される。
【０１５４】
また、ベンダーは、部品カタログＣを改版した場合には、ベンダー側クライアント７０からネットワークＮを介して管理サーバ１０へ、電子メールＥ70B により通知する。この場合の電子メールＥ70B の内容は、たとえば、「改版通知  当社のカタログｘｙｚが０１版から０２版に改版されましたので、お知らせ致します。」である。これにより、管理サーバ１０は、図２２に示した部品カタログ情報ファイルＦ3 における＜版数＞タグの内容を０１から０２へ変更する。
【０１５５】
一方、図２１に示したステップＳＫ８の判断結果が「Ｎｏ」である場合、すなわち、ベンダーが部品カタログＣの引用許諾を拒否した場合、管理サーバ１０は、ステップＳＫ９へ進む。ステップＳＫ９では、管理サーバ１０は、引用許諾を拒否した旨を表す許諾拒否メッセージをディスプレイ２２に表示させた後、図５に示したメインルーチンへ戻る。
【０１５６】
（受領系処理および参照系処理）
つぎに、一実施の形態における受領系処理および参照系処理について図２３に示したフローチャートを参照しつつ説明する。ここでいう受領系処理は、図１に示したコンポーネントデータベースＤＢ１に登録されているコンポーネント（設計図面、ファームウェア等）を、受領系クライアント４０で受領する処理をいう。また、参照系処理は、参照系クライアント３０でコンポーネントを参照する処理をいう。
【０１５７】
この受領系処理および参照系処理においては、受領系クライアント４０および参照系クライアント３０のそれぞれは、図２３に示したステップＳＬ１〜ステップＳＬ７までの各イベント（図番指定処理、ＥＣＯ番号指定処理、・・・、検索処理）を監視している。
【０１５８】
図１に示した登録系クライアント２０からネットワークＮを介して管理サーバ１０にアクセスした状態で、受領系クライアント４０のブラウザおよび参照系クライアント３０のブラウザが起動されると、ディスプレイ４２およびディスプレイ３２には、図２４に示した受領／参照系画面Ｇ6 が表示される。
【０１５９】
（図番指定処理）
このような状態において、受領者により受領系クライアント４０で「図番指定処理」が指定されると、図番指定処理のイベントが発生するため、受領系クライアント４０は、図２３に示したステップＳＬ１の判断結果を「Ｙｅｓ」として、図２５に示したステップＳＭ１〜ステップＳＭ９までの図番指定処理を実行する。
【０１６０】
ここでいう図番指定処理とは、受領系クライアント４０（または参照系クライアント３０）が主体となって、図番指定により、コンポーネントデータベースＤＢ１からコンポーネント（設計図面、ファームウェア）を受領（または参照）する処理をいう。なお、以下においては、受領系クライアント４０によりコンポーネントを図番指定により受領する受領処理について説明するが、参照系クライアント３０によりコンポーネントを参照する参照処理も、受領処理と同様である。
【０１６１】
まず、受領者は、受領系クライアント４０を操作することにより、図２４に示した受領／参照系画面Ｇ6 における図面番号の入力欄Ｈ1 に受領すべきコンポーネントのコンポーネント図番を入力する。これにより、図２５に示したステップＳＭ１では、受領系クライアント４０は、入力欄Ｈ1 に入力されたコンポーネント図番を読み込んだ後、ステップＳＭ２へ進む。
【０１６２】
ステップＳＭ２では、図１に示した受領系クライアント４０は、ネットワークＮを介して管理サーバ１０にアクセスすることで、コンポーネントデータベースＤＢ１からコンポーネント図番に対応するメタ情報を読み込んだ後、ステップＳＭ３へ進む。この場合、図４に示したメタ情報ファイルＦ1 が読み込まれたものとする。ステップＳＭ３では、受領系クライアント４０は、記憶装置４１から受領系プロパティ重要度ファイルＦ5 を読み出した後、ステップＳＭ４へ進む。この受領系プロパティ重要度ファイルＦ5 は、受領系クライアント４０において受領可能なコンポーネントを限定するための情報からなるファイルであり、ＸＭＬで記述されている。
【０１６３】
具体的には、受領系プロパティ重要度ファイルＦ5 において、＜ＭＯＤＥＬ＞タグの内容は、「配布対象モデル」（＝「Ｘ８７７７Ｓ」）であり、＜ＳＥＲＩＡＬ＞タグの内容は、「配布対象製造番号」（＝「００１００」）である。また、＜ＵＳＥＲ＞タグの内容は、「配布対象先」（＝「ＸＹＺ  Ｃｏ．ＬＴＤ」）である。なお、参照系クライアント３０の場合には、受領系プロパティ重要度ファイルＦ5 と同様の参照系プロパティ重要度ファイルＦ4 が用いられる。
【０１６４】
ステップＳＭ４〜ステップＳＭ７では、受領系クライアント４０は、メタ情報ファイルＦ1 （図４参照）の一部（＜ＷＥＢ  ＦＩＬＴＥＲ＞タグ）をなす登録系重要度ファイルＦ6 と、受領系プロパティ重要度ファイルＦ5 とを比較する。すなわち、ステップＳＭ４では、受領系クライアント４０は、＜ＭＯＤＥＬ＞タグの条件を満たしているか否かを判断する。
【０１６５】
具体的には、受領系クライアント４０は、受領系プロパティ重要度ファイルＦ5 における＜ＭＯＤＥＬ＞タグの内容（＝「Ｘ８７７７Ｓ」）が、登録系重要度ファイルＦ6 における＜ＭＯＤＥＬ＞タグの内容（＝「Ｘ８７７７Ｓ、Ｘ８７７７Ｄ、Ｘ８７７７Ｚ」）に存在するか否かを判断する。この場合、受領系クライアント４０は、判断結果を「Ｙｅｓ」としてステップＳＭ５へ進む。
【０１６６】
ステップＳＭ５では、受領系クライアント４０は、＜ＳＥＲＩＡＬ  ＮＯ＞タグの条件を満たしているか否かを判断する。具体的には、受領系クライアント４０は、受領系プロパティ重要度ファイルＦ5 における＜ＳＥＲＩＡＬ  ＮＯ＞タグの内容（＝「００１００」）が、登録系重要度ファイルＦ6 における＜ＳＥＲＩＡＬ  ＮＯ＞タグの内容（＝「００１００−０１２３３」）に存在するか否かを判断する。この場合、受領系クライアント４０は、判断結果を「Ｙｅｓ」としてステップＳＭ６へ進む。
【０１６７】
ステップＳＭ６では、受領系クライアント４０は、＜ＵＳＥＲ＞タグの条件を満たしているか否かを判断する。具体的には、受領系クライアント４０は、受領系プロパティ重要度ファイルＦ5 における＜ＵＳＥＲ＞タグの内容（＝「ＸＹＺ  Ｃｏ．ＬＴＤ」）が、登録系重要度ファイルＦ6 における＜ＵＳＥＲ＞タグの内容（＝「＊ＡＢＣ  Ｃｏ．ＬＴＤ」）を満たしているか否かを判断する。この場合、「＊ＡＢＣ  Ｃｏ．ＬＴＤ」が「ＡＢＣ  Ｃｏ．ＬＴＤ」以外の配布対象先を表しているため、受領系クライアント４０は、ステップＳＭ６の判断結果を「Ｙｅｓ」として、ステップＳＭ７へ進む。
【０１６８】
ステップＳＭ７では、受領系クライアント４０は、図４に示したメタ情報ファイルＦ1 に基づいて、図２６に示した図番指定処理画面Ｇ7 における領域Ｇ8 にメタ情報（コンポーネント図番  ＣＡ２０００１−００００、部品名  ＰＲＯＭ  等）を表示させた後、ステップＳＭ８へ進む。なお、図番指定処理画面Ｇ7 は、ディスプレイ４２に表示される。
【０１６９】
ステップＳＭ８では、受領系クライアント４０は、コンポーネントデータベースＤＢ１からネットワークＮを介してコンポーネントを受領した後、図番指定処理画面Ｇ7 における領域Ｇ9 にデータ情報（コンポーネントモジュール  ＣＡ２０００１−００００．ｐｓ、ＣＡ２０００１−００００．ｄｏｃ、・・・）を表示させた後、図２３に示したメインルーチンへ戻る。
【０１７０】
なお、ステップＳＭ４〜ステップＳＭ６のうちいずれか一つの判断結果が「Ｎｏ」である場合、コンポーネントの受領（または参照）が許可されないため、受領系クライアント４０は、ステップＳＭ９へ進む。ステップＳＭ９では、受領系クライアント４０は、「図番指定されたコンポーネントの受領または参照が許可されておりません。」というエラーメッセージをディスプレイ４２に表示させた後、図２３に示したメインルーチンへ戻る。
【０１７１】
（ＥＣＯ番号指定処理）
また、受領者により受領系クライアント４０で「ＥＣＯ番号指定処理」が指定されると、ＥＣＯ番号指定処理のイベントが発生するため、受領系クライアント４０は、図２３に示したステップＳＬ２の判断結果を「Ｙｅｓ」として、図２７に示したステップＳＮ１〜ステップＳＮ４までのＥＣＯ番号指定処理を実行する。このＥＣＯ番号指定処理は、前述した通知処理（図１９参照）で管理サーバ１０から受領系クライアント４０へ電子メールＥ40 により改版設計通知書（ＥＣＯ：図１１、図１２参照）が通知された場合に、受領系クライアント４０で改版されたコンポーネントを受領する処理である。
【０１７２】
図２７に示したステップＳＮ１で電子メールＥ40 による改版設計通知書（ＥＣＯ）が受領系クライアント４０に受信されると、受領系クライアント４０は、ステップＳＮ２へ進む。ステップＳＮ２では、受領系クライアント４０は、改版されたコンポーネントを受領する処理を即実行するか否かを判断する。具体的には、受領系クライアント４０は、図２４に示したタイマ設定の入力欄Ｈ4 に設定時刻が入力されているか否かによりステップＳＮ２の判断を行う。
【０１７３】
この場合、入力欄Ｈ4 に「１９９９．１０．０１．１２：２３」という設定時刻が受領者により入力されているため、受領系クライアント４０は、ステップＳＮ２の判断結果を「Ｎｏ」として、ステップＳＮ３へ進む。なお、入力欄Ｈ4 が空欄である場合、受領系クライアント４０は、ステップＳＮ２の判断結果を「ＹＥＳ」として、図２８に示したステップＳＯ１へ進む。
【０１７４】
ステップＳＮ３では、受領系クライアント４０は、入力欄Ｈ4 に入力された設定時刻「１９９９．１０．０１．１２：２３」を読み取り、タイマ設定処理を実行した後、ステップＳＮ４へ進む。ステップＳＮ４では、受領系クライアント４０は、タイマ（図示略）の計時結果が上記設定時刻と一致するか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。そして、タイマ（図示略）の計時結果が設定時刻と一致すると、受領系クライアント４０は、ステップＳＮ４の判断結果を「Ｙｅｓ」として、図２８に示したステップＳＯ１へ進む。
【０１７５】
ステップＳＯ１では、受領系クライアント４０は、改版設計通知書（ＥＣＯ）により指定されたコンポーネント図番に対応するメタ情報をネットワークＮを介してコンポーネントデータベースＤＢ１から受領する。つぎに、受領系クライアント４０は、上記メタ情報から複数の子コンポーネント図番を展開した後、これらの子コンポーネント図番に対応する改版された子コンポーネント図面（図２参照）をネットワークＮを介してコンポーネントデータベースＤＢ１から受領した後、ステップＳＯ１５へ進む。
【０１７６】
ステップＳＯ１５では、受領系クライアント４０は、受領した子コンポーネント図面にファームウェアが存在するか否かを判断し、この判断結果が「Ｎｏ」である場合、図２３に示したメインルーチンへ戻る。ここで、ステップＳＯ１で図３に示したファームウェアに関する情報を含むメタ情報ＳＫおよびＳＫF を受領したものとすると、受領系クライアント４０は、ステップＳＯ１５の判断結果を「Ｙｅｓ」として、ステップＳＯ２へ進む。
【０１７７】
ステップＳＯ２では、受領系クライアント４０は、図３に示したメタ情報ＳＫF に基づいて、「Ｌｏａｄ  Ｍｏｄｕｌｅｓ」の欄に記述された「Ｍ９ＣＡ４１０００−１０００ａ．ｒｏｍ」というファイル名のロードモジュール（コンポーネント）をコンポーネントデータベースＤＢ１のデータブロックからネットワークＮを介して取り出した後、ステップＳＯ３へ進む。ステップＳＯ３では、受領系クライアント４０は、すべてのロードモジュールを取り出したか否かを判断し、この場合、判断結果を「Ｎｏ」として、ステップＳＯ２へ戻る。
【０１７８】
ステップＳＯ２では、受領系クライアント４０は、図３に示したメタ情報ＳＫF に基づいて、「Ｌｏａｄ  Ｍｏｄｕｌｅｓ」の欄に記述された「Ｍ９ＣＡ４１０００−１００１ａ．ｒｏｍ」というファイル名のロードモジュール（コンポーネント）をコンポーネントデータベースＤＢ１のデータブロックからネットワークＮを介して取り出した後、ステップＳＯ３へ進む。ステップＳＯ３では、受領系クライアント４０は、判断結果を「Ｙｅｓ」として、ステップＳＯ４へ進む。
【０１７９】
ステップＳＯ４では、受領系クライアント４０は、図３に示したメタ情報ＳＫF に基づいて、「Ｌｏａｄ  Ｐｒｏｇｒａｍ」の欄に記述された「Ｌ９ＣＡ４１０００−１０００ａ．ｅｘｅ」というファイル名のロードプログラム（コンポーネント）をコンポーネントデータベースＤＢ１のデータブロックからネットワークＮを介して取り出した後、ステップＳＯ５へ進む。ステップＳＯ５では、受領系クライアント４０は、すべてのロードプログラムを取り出したか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＯ６へ進む。
【０１８０】
ステップＳＯ６では、受領系クライアント４０は、図３に示したメタ情報ＳＫF に基づいて、「Ｌｏａｄ  Ｃｏｎｔｒｏｌ」の欄に記述された「Ｃ９ＣＡ４１０００−１００１ａ．ｔｘｔ」というファイル名の制御情報（コンポーネント）をコンポーネントデータベースＤＢ１のデータブロックからネットワークＮを介して取り出した後、ステップＳＯ７へ進む。ステップＳＯ７では、受領系クライアント４０は、すべての制御情報を取り出したか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＯ８へ進む。
【０１８１】
ステップＳＯ８では、受領系クライアント４０は、図３に示したメタ情報ＳＫF に基づいて、「Ｐａｔｃｈｅｓ」の欄に記述された「Ｐ９ＣＡ４１０００−１０００ａ．ｅｘｅ」というファイル名のパッチ情報（コンポーネント）をコンポーネントデータベースＤＢ１のデータブロックからネットワークＮを介して取り出した後、ステップＳＯ９へ進む。ステップＳＯ９では、受領系クライアント４０は、すべてのパッチ情報を取り出したか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、ステップＳＯ１０へ進む。
【０１８２】
ステップＳＯ１０では、受領系クライアント４０は、ステップＳＯ６で取り出した制御情報にしたがって、ステップＳＯ２で取り出したロードモジュールに対してパッチ情報を適用することにより、ロードモジュールに修正をかけた後、ステップＳＯ１１へ進む。これにより、ファームウェア（ロードモジュール）の改版が終了する。ステップＳＯ１１では、受領系クライアント４０は、ファームウェアのマニュアルに関するマニュアル情報（ドキュメント）がメタ情報ＳＫF に存在するか否かを判断し、判断結果が「Ｎｏ」の場合、図２３に示したメインルーチンへ戻る。
【０１８３】
この場合、図３に示したメタ情報ＳＫF における「Ｍａｎｕａｌｓ」の欄にファイル名として「Ｍ１ＣＡ４１０００−１０００ａ．ｄｏｃ」が記述されているため、受領系クライアント４０は、ステップＳＯ１１の判断結果を「Ｙｅｓ」として、ステップＳＯ１２へ進む。ステップＳＯ１２では、受領系クライアント４０は、「Ｍ１ＣＡ４１０００−１０００ａ．ｄｏｃ」というファイル名のマニュアル情報（コンポーネント）をコンポーネントデータベースＤＢ１のデータブロックからネットワークＮを介して取り出した後、図２３に示したメインルーチンへ戻る。
【０１８４】
（ＮＲＮ番号指定処理）
また、受領者により受領系クライアント４０で「ＮＲＮ番号指定処理」が指定されると、ＮＲＮ番号指定処理のイベントが発生するため、受領系クライアント４０は、図２３に示したステップＳＬ３の判断結果を「Ｙｅｓ」として、図２９に示したステップＳＰ１〜ステップＳＰ４までのＮＲＮ番号指定処理を実行する。このＮＲＮ番号指定処理は、前述した通知処理（図１９参照）で管理サーバ１０から受領系クライアント４０へ電子メールＥ40 により新規設計通知書（ＮＲＮ：図１１、図１２参照）が通知された場合に、受領系クライアント４０で新規に登録されたコンポーネントを受領する処理である。
【０１８５】
図２９に示したステップＳＰ１で電子メールＥ40 により新規設計通知書（ＮＲＮ）が受領系クライアント４０に受信されると、受領系クライアント４０は、ステップＳＰ２へ進む。ステップＳＰ２では、受領系クライアント４０は、新規に登録されたコンポーネントを受領する処理を即実行するか否かを判断する。具体的には、受領系クライアント４０は、図２４に示したタイマ設定の入力欄Ｈ4 に設定時刻が入力されているか否かによりステップＳＰ２の判断を行う。
【０１８６】
この場合、入力欄Ｈ4 に「１９９９．１０．０１．１２：２３」という設定時刻が受領者により入力されているため、受領系クライアント４０は、ステップＳＰ２の判断結果を「Ｎｏ」として、ステップＳＰ３へ進む。なお、入力欄Ｈ4 が空欄である場合、受領系クライアント４０は、ステップＳＰ２の判断結果を「ＹＥＳ」として、図２８に示したステップＳＯ１３へ進む。
【０１８７】
ステップＳＰ３では、受領系クライアント４０は、入力欄Ｈ4 に入力された設定時刻「１９９９．１０．０１．１２：２３」を読み取り、タイマ設定処理を実行した後、ステップＳＰ４へ進む。ステップＳＰ４では、受領系クライアント４０は、タイマ（図示略）の計時結果が上記設定時刻と一致するか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。そして、タイマ（図示略）の計時結果が設定時刻と一致すると、受領系クライアント４０は、ステップＳＰ４の判断結果を「Ｙｅｓ」として、図２８に示したステップＳＯ１３へ進む。
【０１８８】
ステップＳＯ１３では、受領系クライアント４０は、新規設計通知書（ＮＲＮ）により指定された親コンポーネント図番に対応するメタ情報をネットワークＮを介してコンポーネントデータベースＤＢ１から受領する。つぎに、受領系クライアント４０は、上記メタ情報から、図２に示したように第２層の子コンポーネント図番を展開した後、これらの子コンポーネント図番に対応する新規に登録された子コンポーネント図面（図２参照）をネットワークＮを介してコンポーネントデータベースＤＢ１から受領した後、ステップＳＯ１４へ進む。
【０１８９】
ステップＳＯ１４では、受領系クライアント４０は、すべての子コンポーネント図番に関する処理が終了したか否か、すなわち、図２に示した第ｎ層（ボトム層）における子コンポーネント図番の展開が終了したか否かを判断し、この場合、判断結果を「Ｎｏ」として、ステップＳＯ１３へ戻る。
【０１９０】
ステップＳＯ１３では、受領系クライアント４０は、メタ情報から、図２に示したように第ｎ層の子コンポーネント図番を展開した後、これらの子コンポーネント図番に対応する新規に登録された子コンポーネント図面（図２参照）をネットワークＮを介してコンポーネントデータベースＤＢ１から受領した後、ステップＳＯ１４へ進む。ステップＳＯ１４では、受領系クライアント４０は、判断結果を「Ｙｅｓ」として、ステップＳＯ１５へ進む。以後、受領系クライアント４０は、前述した動作と同様にして、ステップＳＯ１５以降の処理を実行する。
【０１９１】
（データ参照処理）
また、参照者により参照系クライアント３０で「データ参照処理」が指定されると、データ参照処理のイベントが発生するため、参照系クライアント３０は、図２３に示したステップＳＬ４の判断結果を「Ｙｅｓ」として、図３０に示したステップＳＱ１〜ステップＳＱ７までのデータ参照処理を実行する。このデータ参照処理は、前述した図番指定処理（図２５参照）が終了した後に実行される処理である。
【０１９２】
すなわち、図３０に示したステップＳＱ１では、参照者は、ディスプレイ３２に表示されているデータ参照処理画面Ｇ10 （図３１参照）におけるコンポーネントモジュール（ＣＡ２０００１−００００．ｐｓ、ＣＡ２０００１−００００．ｄｏｃ）の中から参照すべき一つのコンポーネントモジュールを選択する。このデータ参照処理画面Ｇ10 は、前述した図番指定処理画面Ｇ7 （図２６参照）に対応している。この場合、参照者は、「ＣＡ２０００１−００００．ｐｓ」というファイル名のコンポーネントモジュールを選択したものとする。
【０１９３】
これにより、ステップＳＱ２では、参照系クライアント３０は、ステップＳＱ１で選択された「ＣＡ２０００１−００００．ｐｓ」から拡張子（＝ｐｓ）を抽出した後、ステップＳＱ３へ進む。ステップＳＱ３では、参照系クライアント３０は、拡張子（＝ｐｓ）に対応するブラウザを起動した後、ステップＳＱ４へ進む。
【０１９４】
ステップＳＱ４では、参照系クライアント３０は、ステップＳＱ１で選択されたコンポーネントモジュールのファイルがＸＭＬファイルであるか否かを判断し、この場合、判断結果を「Ｎｏ」として、ステップＳＱ６へ進む。なお、ステップＳＱ４の判断結果が「Ｙｅｓ」である場合、参照系クライアント３０は、ステップＳＱ５へ進む。ステップＳＱ５では、参照系クライアント３０は、ＸＭＬファイルにおけるタグが定義されたＤＴＤを記憶装置３１から読み込んだ後、ステップＳＱ６へ進む。
【０１９５】
この場合、ステップＳＱ６では、参照系クライアント３０は、ステップＳＱ３で起動されたブラウザにより、ネットワークＮを介してコンポーネントデータベースＤＢ１のデータブロックに格納されているコンポーネントモジュール（ファイル名：「ＣＡ２０００１−００００．ｐｓ」）をディスプレイ３２に表示させた後、ステップＳＱ７へ進む。
【０１９６】
これにより、参照者は、ディスプレイ３２の表示画面により所望のコンポーネントモジュール（設計図面等）を参照する。なお、コンポーネントモジュールがファームウェア等のドキュメント以外のものであるである場合には、参照系クライアント３０は、当該ファームウェア等をディスプレイ３２に表示させない。
【０１９７】
ステップＳＱ７では、参照系クライアント３０は、ステップＳＱ１で選択されたすべてのコンポーネントモジュールをディスプレイ３２に表示させたか否かを判断し、この場合、判断結果を「Ｙｅｓ」として、図２３に示したメインルーチンへ戻る。なお、ステップＳＱ１で複数のコンポーネントモジュールが選択された場合には、参照系クライアント３０は、ステップＳＱ７の判断結果を「Ｎｏ」として、ステップＳＱ２へ戻り、前述した動作と同様にして、つぎのコンポーネントモジュールをディスプレイ３２に表示させる処理を実行する。
【０１９８】
（データ受領処理）
また、受領者により受領系クライアント４０で「データ受領処理」が指定されると、データ受領処理のイベントが発生するため、受領系クライアント４０は、図２３に示したステップＳＬ５の判断結果を「Ｙｅｓ」として、図３２に示したステップＳＲ１〜ステップＳＲ７までのデータ受領処理を実行する。このデータ受領処理は、前述した図番指定処理（図２５参照）が終了した後に実行される処理である。
【０１９９】
すなわち、図３２に示したステップＳＲ１では、受領系クライアント４０は、図２４に示した受領／参照系画面Ｇ6 におけるユーザ受領先の入力欄Ｈ5 に入力されたユーザ受領先（Ｃｒ／ｔｍｐ／ｍｏｄｕｌｅ）を読み込んだ後、ステップＳＲ２へ進む。このユーザ受領先は、コンポーネントデータベースＤＢ１のデータブロックに格納されているコンポーネント（コンポーネントモジュール：設計図面、ファームウェア等）を受領した際に、これを格納すべき記憶装置４１のディレクトリである。また、ユーザ受領先は、受領者により入力される。
【０２００】
ステップＳＲ２では、受領系クライアント４０は、コンポーネントモジュールを受領する処理を即実行するか否かを判断する。具体的には、受領系クライアント４０は、図２４に示したタイマ設定の入力欄Ｈ4 に設定時刻が入力されているか否かによりステップＳＲ２の判断を行う。
【０２０１】
この場合、入力欄Ｈ4 に「１９９９．１０．０１．１２：２３」という設定時刻が受領者により入力されているため、受領系クライアント４０は、ステップＳＲ２の判断結果を「Ｎｏ」として、ステップＳＲ６へ進む。なお、入力欄Ｈ4 が空欄である場合、受領系クライアント４０は、ステップＳＲ２の判断結果を「ＹＥＳ」として、ステップＳＲ３へ進む。
【０２０２】
ステップＳＲ６では、受領系クライアント４０は、入力欄Ｈ4 に入力された設定時刻「１９９９．１０．０１．１２：２３」を読み取り、タイマ設定処理を実行した後、ステップＳＲ７へ進む。ステップＳＲ７では、受領系クライアント４０は、タイマ（図示略）の計時結果が上記設定時刻と一致するか否かを判断し、この判断結果が「Ｎｏ」である場合、同判断を繰り返す。そして、タイマ（図示略）の計時結果が設定時刻と一致すると、受領系クライアント４０は、ステップＳＲ７の判断結果を「Ｙｅｓ」として、ステップＳＲ３へ進む。
【０２０３】
ステップＳＲ３では、受領系クライアント４０は、図２６に示した図番指定処理画面Ｇ7 における領域Ｇ9 に表示されているコンポーネントモジュール（ＣＡ２０００１−００００．ｐｓ）をネットワークＮを介してコンポーネントデータベースＤＢ１のデータブロックから読み出した後、ステップＳＲ４へ進む。
【０２０４】
ステップＳＲ４では、受領系クライアント４０は、受領したコンポーネントモジュール（ＣＡ２０００１−００００．ｐｓ）をユーザ受領先（図２４参照）に対応する記憶装置４１のディレクトリ配下に格納した後、ステップＳＲ５へ進む。ステップＳＲ５では、受領系クライアント４０は、すべてのコンポーネントモジュールを受領したか否かを判断する。この場合、図２６に示したコンポーネントモジュール（ＣＡ２０００１−００００．ｄｏｃ）が未受領であるため、受領系クライアント４０は、ステップＳＲ５の判断結果を「Ｎｏ」としてステップＳＲ３へ戻る。
【０２０５】
ステップＳＲ３では、受領系クライアント４０は、コンポーネントモジュール（ＣＡ２０００１−００００．ｄｏｃ）をネットワークＮを介してコンポーネントデータベースＤＢ１のデータブロックから読み出した後、ステップＳＲ４へ進む。ステップＳＲ４では、受領系クライアント４０は、受領したコンポーネントモジュール（ＣＡ２０００１−００００．ｄｏｃ）をユーザ受領先（図２４参照）に対応する記憶装置４１のディレクトリ配下に格納した後、ステップＳＲ５へ進む。ステップＳＲ５では、受領系クライアント４０は、判断結果を「Ｙｅｓ」として図２３に示したメインルーチンへ戻る。
【０２０６】
（ファームウェア受領処理）
また、受領者により受領系クライアント４０で「ファームウェア受領処理」が指定されると、ファームウェア受領処理のイベントが発生するため、受領系クライアント４０は、図２３に示したステップＳＬ６の判断結果を「Ｙｅｓ」として、図３３に示したステップＳＴ１〜ステップＳＴ１３までのファームウェア受領処理を実行する。このファームウェア受領処理は、前述したデータ受領処理（図図３２参照）が終了した後に実行され、コンポーネントとしてファームウェアを受領する処理である。
【０２０７】
すなわち、データ受領処理（図３２参照）が終了した後、図３３に示したステップＳＴ１では、受領系クライアント４０は、データ（コンポーネント）を受領したか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＴ１３へ進む。ステップＳＴ１３では、受領系クライアント４０は、たとえば、「目的とするコンポーネントのモジュールを受領しておりません。」という未受領メッセージをディスプレイ４２に表示させた後、図２３に示したメインルーチンへ戻る。
【０２０８】
一方、ステップＳＴ１の判断結果が「Ｙｅｓ」である場合、受領系クライアント４０は、ステップＳＴ２へ進む。ステップＳＴ２では、受領系クライアント４０は、受領したコンポーネントモジュール（データ＋チェックサム値）に対してチェックサム処理を実行した後、ステップＳＴ３へ進む。ここで、データにチェックサム値が付加されたものがコンポーネントモジュールとして受領系クライアント４０に受領される。
【０２０９】
ステップＳＴ３では、受領系クライアント４０は、チェックサム処理におけるチェック結果がＯＫであるか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＴ１２へ進む。ステップＳＴ１２では、受領系クライアント４０は、たとえば、「チェックサムエラーが発生しました。」というエラーメッセージをディスプレイ４２に表示させた後、図２３に示したメインルーチンへ戻る。
【０２１０】
一方、ステップＳＴ３の判断結果が「Ｙｅｓ」である場合、受領系クライアント４０は、ステップＳＴ４へ進む。ステップＳＴ４では、すべてのコンポーネントモジュールに関するチェックが終了したか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＴ２へ戻り、つぎのコンポーネントモジュールに対するチェックサム処理を実行する。
【０２１１】
そして、ステップＳＴ４の判断結果が「Ｙｅｓ」になると、受領系クライアント４０は、ステップＳＴ５へ進み、受領したコンポーネントモジュールのうち、シーケンスモジュールを記憶装置４１から読み込んだ後、ステップＳＴ６へ進む。ここでいうシーケンスモジュールとは、ファームウェアを自動的に修正するための一連のシーケンスに関するモジュールをいう。なお、シーケンスモジュールを受領していない場合には、受領系クライアント４０は、ステップＳＴ５をスキップしてステップＳＴ６へ進む。
【０２１２】
ステップＳＴ６では、受領系クライアント４０は、シーケンスモジュールがあるか否かを判断し、この判断結果が「Ｎｏ」である場合、図２３に示したメインルーチンへ戻る。一方、ステップＳＴ６の判断結果が「Ｙｅｓ」である場合、受領系クライアント４０は、ステップＳＴ７へ進む。ステップＳＴ７では、受領系クライアント４０は、シーケンスモジュールを実行する。これにより、ステップＳＴ８では、受領系クライアント４０は、ファームウェアの修正を制御するための制御情報を読み込んだ後、ステップＳＴ９へ進む。
【０２１３】
ステップＳＴ９では、受領系クライアント４０は、ファームウェアの修正を自動的に実行するための制御プログラムを実行した後、ステップＳＴ１０へ進む。ステップＳＴ１０では、受領系クライアント４０は、シーケンスモジュール、制御情報および制御プログラムにしたがって、ファームウェアに対してパッチ処理を実行した後、ステップＳＴ１１へ進む。
【０２１４】
ステップＳＴ１１では、受領系クライアント４０は、一連のシーケンスが終了したか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＴ７へ戻る。そして、ファームウェアに対する自動修正（パッチ処理）が終了すると、受領系クライアント４０は、ステップＳＴ１１の判断結果を「Ｙｅｓ」として、図２３に示したメインルーチンへ戻る。
【０２１５】
（検索処理）
また、受領者（または参照者）により受領系クライアント４０（または参照系クライアント３０）で「検索処理」が指定されると、検索処理のイベントが発生するため、受領系クライアント４０は、図２３に示したステップＳＬ７の判断結果を「Ｙｅｓ」として、図３４に示したステップステップＳＵ１〜ステップＳＵ９までの検索処理を実行する。
【０２１６】
この検索処理は、コンポーネントデータベースＤＢ１のメタブロックに格納されているメタ情報のうちコンポーネント図番をキーとして所望のメタ情報を検索する処理である。なお、以下においては、受領系クライアント４０における検索処理について説明するが、参照系クライアント３０における検索処理も、受領系クライアント４０における検索処理と同様である。
【０２１７】
図３４に示したステップＳＵ１では、受領系クライアント４０は、初期の入力であるか否かを判断し、この場合、判断結果を「Ｙｅｓ」としてステップＳＵ２へ進む。ステップＳＵ２では、受領系クライアント４０は、ディスプレイ４２に検索情報（コンポーネント図番）を入力するための入力欄を有する検索画面（図示略）を表示させた後、図２３に示したメインルーチンへ戻る。これにより、受領者は、上記入力欄に所望のコンポーネント図番を検索情報として入力する。
【０２１８】
そして、受領系クライアント４０は、図２３に示したステップＳＬ７の判断結果を「Ｙｅｓ」とし、図３４に示したステップＳＵ１の判断結果を「Ｎｏ」とした後、ステップＳＵ３へ進む。ステップＳＵ３では、受領系クライアント４０は、受領者により入力された検索情報（コンポーネント図番）を読み込んだ後、ステップＳＵ４へ進む。
【０２１９】
ステップＳＵ４では、受領系クライアント４０は、コンポーネントデータベースＤＢ１のメタブロックからＸＭＬで記述されたメタ情報を読み込んだ後、ステップＳＵ５へ進む。ステップＳＵ５では、受領系クライアント４０は、コンポーネントデータベースＤＢ１から、メタ情報におけるタグを定義したＤＴＤを読み込んだ後、ステップＳＵ６へ進む。ステップＳＵ６では、受領系クライアント４０は、メタ情報におけるコンポーネント図番と、検索情報（コンポーネント図番）とが一致するか否かを判断し、この判断結果が「Ｙｅｓ」である場合、ステップＳＵ７へ進む。
【０２２０】
ステップＳＵ７では、受領系クライアント４０は、検索結果として当該メタ情報をディスプレイ４２に表示させた後、図２３に示したメインルーチンへ戻る。一方、ステップＳＵ６の判断結果が「Ｎｏ」である場合、受領系クライアント４０は、ステップＳＵ８へ進む。ステップＳＵ８では、受領系クライアント４０は、検索が終了したか否かを判断し、この判断結果が「Ｎｏ」である場合、ステップＳＵ６へ戻り、メタ情報におけるつぎのコンポーネント図番と検索情報（コンポーネント図番）とが一致するか否かを判断する。
【０２２１】
そして、ステップＳＵ８の判断結果が「Ｙｅｓ」である場合、受領系クライアント４０は、ステップＳＵ９へ進み、たとえば、「該当するコンポーネント図番は存在しません。」という検索エラーメッセージをディスプレイ４２に表示させた後、図２３に示したメインルーチンへ戻る。
【０２２２】
なお、上述した一実施の形態においては、ステップＳＡ８（図５参照）で通知処理を行う場合に、管理サーバ１０で参照系クライアント３０、受領系クライアント４０および対称マシン５０に対してｐｉｎｇコマンドを送信することで通信回線の状況をチェックし、対称マシン５０の通信回線が正常である場合、参照系クライアント３０または受領系クライアント４０に代わって対称マシン５０がコンポーネントの受領または参照を行うようにしてもよい。この対称マシン５０は、参照系クライアント３０および受領系クライアント４０の上位マシンである。
【０２２３】
また、対称マシン５０の通信回線が異常であり、かつ参照系クライアント３０または受領系クライアント４０の通信回線が正常である場合には、受領系クライアント４０または参照系クライアント３０によりコンポーネントの受領または参照を行うようにしてもよい。
【０２２４】
以上説明したように、一実施の形態によれば、ハードウェアとファームウェアとを同一の管理レベルととらえて、両者に関する複数のコンポーネントを一元的に管理するようにしたので、従来のように両者に関するそれぞれのコンポーネントを個別的に管理する場合に比して、版数管理効率や管理効率を向上させることができるとともに、作業ミスの発生を防止することができる。
【０２２５】
また、一実施の形態によれば、図２に示したように、複数のコンポーネントを階層構造化するようにしたので、参照系クライアント３０（受領系クライアント４０または対称マシン５０）でメタ情報に基づいて容易に第１層のコンポーネント図面から第ｎ層のコンポーネント図面を引き出すことができる。
【０２２６】
また、一実施の形態によれば、図４に示したメタ情報ファイルＦ1 に＜ＷＥＢ  ＦＩＬＴＥＲ＞タグの内容を含ませたので、コンポーネント単位という極めて細かな単位でコンポーネントの受領または参照に関するセキュリティ対策を採ることができる。
【０２２７】
また、一実施の形態によれば、コンポーネントにパッチ情報を含ませて受領系クライアント４０側で自動的にパッチ処理を施すようにしたので、従来のように手作業によりパッチ適用作業を行っていた場合に比して、作業ミスを防止することができるとともに、作業時間を短縮することができる。
【０２２８】
また、一実施の形態によれば、図２に示したように複数のコンポーネントが階層構造化されているため、ハードウェアとファームウェアとを区別することなく、メタ情報から容易に所望のコンポーネントを検索することができる。
【０２２９】
また、一実施の形態によれば、コンポーネントに改版があった場合や、新規のコンポーネントがコンポーネントデータベースＤＢ１に登録された場合に、改版設計通知（ＥＣＯ）または新規設計通知（ＮＲＮ）によりリアルタイム（または任意の時刻）で受領系クライアント４０または参照系クライアント３０による当該コンポーネントの引き出しが可能であるため、通知漏れ等を防止することができるともに、しかも夜間帯に引き出しが行えるため、作業効率を向上させることができる。
【０２３０】
さらに、一実施の形態によれば、管理サーバ１０により、開発委託先クライアント６０との間で製品の開発委託に関する通信も行うようにしたので、開発委託に関する連絡を迅速にとることができ、結果として製品の開発に要する期間を短縮することができる。
【０２３１】
加えて、一実施の形態によれば、管理サーバ１０により、ベンダー側クライアント７０との間で部品カタログＣの引用許諾を受けるための通信も行うようにしたので、部品カタログＣの引用許諾を迅速に受けることができる。
【０２３２】
以上本発明にかかる一実施の形態について図面を参照して詳述してきたが、具体的な構成例はこの一実施の形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。たとえば、前述した一実施の形態においては、管理サーバ１０の機能を実現するためのコンポーネント管理プログラムを図３５に示したコンピュータ読み取り可能な記録媒体２００に記録して、この記録媒体２００に記録されたコンポーネント管理プログラムを同図に示したコンピュータ１００に読み込ませ、実行することによりコンポーネントに関する一連の管理を行うようにしてもよい。
【０２３３】
図３５に示したコンピュータ１００は、上記コンポーネント管理プログラムを実行するＣＰＵ１０１と、キーボード、マウス等の入力装置１０２と、各種データを記憶するＲＯＭ（Read Only Memory）１０３と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）１０４と、記録媒体２００からコンポーネント管理プログラムを読み取る読取装置１０５と、ディスプレイ、プリンタ等の出力装置１０６と、装置各部を接続するバスＢＵとから構成されている。
【０２３４】
ＣＰＵ１０１は、読取装置１０５を経由して記録媒体２００に記録されているコンポーネント管理プログラムを読み込んだ後、コンポーネント管理プログラムを実行することにより、前述したコンポーネントの管理を行う。なお、記録媒体２００には、光ディスク、フロッピーディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【０２３５】
【発明の効果】
以上説明したように、請求項１、２、９にかかる発明によれば、ハードウェアとファームウェアとを同一の管理レベルととらえて、両者に関する複数のコンポーネントを一元的に管理するようにしたので、従来のように両者に関するそれぞれのコンポーネントを個別的に管理する場合に比して、版数管理効率や管理効率を向上させることができるとともに、作業ミスの発生を防止することができるという効果を奏する。
【０２３６】
また、請求項３にかかる発明によれば、複数のコンポーネントを階層構造化するようにしたので、クライアント側でメタ情報に基づいて容易に上位階層のコンポーネントから下位階層のコンポーネントを引き出すことができるという効果を奏する。
【０２３７】
また、請求項４にかかる発明によれば、メタ情報にコンポーネント単位で引き出しの許可／不許可に関する引出制限情報を含ませたので、コンポーネント単位という極めて細かな単位でセキュリティ対策を採ることができるという効果を奏する。
【０２３８】
また、請求項５にかかる発明によれば、複数のコンポーネントが階層構造化されているため、ハードウェアとファームウェアとを区別することなく、メタ情報から容易に所望のコンポーネントを検索することができるという効果を奏する。
【０２３９】
また、請求項６にかかる発明によれば、コンポーネントにパッチ情報を含ませてクライアント側で自動的にパッチ処理を施すようにしたので、従来のように手作業によりパッチ適用作業を行っていた場合に比して、作業ミスを防止することができるとともに、作業時間を短縮することができるという効果を奏する。
【０２４０】
また、請求項７にかかる発明によれば、管理手段により、開発メーカ側クライアントとの間で製品の開発委託に関する通信も行うようにしたので、開発委託に関する連絡を迅速にとることができ、結果として製品の開発に要する期間を短縮することができるという効果を奏する。
【０２４１】
また、請求項８にかかる発明によれば、管理手段により、著作者側クライアントとの間でカタログの引用許諾を受けるための通信も行うようにしたので、カタログの引用許諾を迅速に受けることができるという効果を奏する。
【図面の簡単な説明】
【図１】  本発明にかかる一実施の形態の構成を示すブロック図である。
【図２】  同一実施の形態における階層構造を示す図である。
【図３】  同一実施の形態におけるメタ情報を説明する図である。
【図４】  同一実施の形態におけるメタ情報ファイルＦ1 を示す図である。
【図５】  同一実施の形態における登録系処理を説明するフローチャートである。
【図６】  同一実施の形態における採番処理を説明するフローチャートである。
【図７】  同一実施の形態における登録系画面Ｇ1 を示す図である。
【図８】  同一実施の形態における登録処理を説明するフローチャートである。
【図９】  同一実施の形態における登録メニュー画面Ｇ2 を示す図である。
【図１０】  同一実施の形態におけるＥＣＯ登録処理を説明するフローチャートである。
【図１１】  同一実施の形態におけるＮＲＮ／ＥＣＯ入力画面Ｇ3 を示す図である。
【図１２】  同一実施の形態におけるＮＲＮ／ＥＣＯファイルＦ2 を示す図である。
【図１３】  同一実施の形態におけるＮＲＮ／ＥＣＯ画面Ｇ4 を示す図である。
【図１４】  同一実施の形態におけるＮＲＮ登録処理を説明するフローチャートである。
【図１５】  同一実施の形態におけるコンポーネントストラクチャ処理を説明するフローチャートである。
【図１６】  同一実施の形態における廃図処理を説明するフローチャートである。
【図１７】  同一実施の形態における登録系重要度設定処理を説明するフローチャートである。
【図１８】  同一実施の形態におけるサブメニュー画面Ｇ5 を示す図である。
【図１９】  同一実施の形態における通知処理を説明するフローチャートである。
【図２０】  同一実施の形態における開発委託処理を説明するフローチャートである。
【図２１】  同一実施の形態における部品カタログ引用許諾処理を説明する図である。
【図２２】  同一実施の形態における部品カタログ引用許諾処理を説明するフローチャートである。
【図２３】  同一実施の形態における受領系処理および参照系処理を説明するフローチャートである。
【図２４】  同一実施の形態における受領／参照系画面Ｇ6 を示す図である。
【図２５】  同一実施の形態における図番指定処理を説明するフローチャートである。
【図２６】  同一実施の形態における図番指定処理画面Ｇ7 を示す図である。
【図２７】  同一実施の形態におけるＥＣＯ番号指定処理を説明するフローチャートである。
【図２８】  同一実施の形態における受領処理を説明するフローチャートである。
【図２９】  同一実施の形態におけるＮＲＮ番号指定処理を説明するフローチャートである。
【図３０】  同一実施の形態におけるデータ参照処理を説明するフローチャートである。
【図３１】  同一実施の形態におけるデータ参照処理画面Ｇ10 を示す図である。
【図３２】  同一実施の形態におけるデータ受領処理を説明するフローチャートである。
【図３３】  同一実施の形態におけるファームウェア受領処理を説明するフローチャートである。
【図３４】  同一実施の形態における検索処理を説明するフローチャートである。
【図３５】  同一実施の形態の変形例を示すブロック図である。
【図３６】  従来における製品の開発および製造過程を説明する図である。
【符号の説明】
１０  管理サーバ
３０  参照系クライアント
４０  受領系クライアント
５０  対称マシン
６０  開発委託先クライアント
７０  ベンダー側クライアント
Ｎ  ネットワーク
【図１】
0003910769.tif 000002
【図２】
0003910769.tif 000003
【図３】
0003910769.tif 000004
【図４】
0003910769.tif 000005
【図５】
0003910769.tif 000006
【図６】
0003910769.tif 000007
【図７】
0003910769.tif 000008
【図８】
0003910769.tif 000009
【図９】
0003910769.tif 000010
【図１０】
0003910769.tif 000011
【図１１】
0003910769.tif 000012
【図１２】
0003910769.tif 000013
【図１３】
0003910769.tif 000014
【図１４】
0003910769.tif 000015
【図１５】
0003910769.tif 000016
【図１６】
0003910769.tif 000017
【図１７】
0003910769.tif 000018
【図１８】
0003910769.tif 000019
【図１９】
0003910769.tif 000020
【図２０】
0003910769.tif 000021
【図２１】
0003910769.tif 000022
【図２２】
0003910769.tif 000023
【図２３】
0003910769.tif 000024
【図２４】
0003910769.tif 000025
【図２５】
0003910769.tif 000026
【図２６】
0003910769.tif 000027
【図２７】
0003910769.tif 000028
【図２８】
0003910769.tif 000029
【図２９】
0003910769.tif 000030
【図３０】
0003910769.tif 000031
【図３１】
0003910769.tif 000032
【図３２】
0003910769.tif 000033
【図３３】
0003910769.tif 000034
【図３４】
0003910769.tif 000035
【図３５】
0003910769.tif 000036
【図３６】
0003910769.tif 000037