【事件の表示】
　特願２０００−１５７６７６「証明書管理システム」拒絶査定不服審判事件〔平成１３年１２月　７日出願公開、特開２００１−３３８０４０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明
　本願は、平成１２年５月２９日に出願されたものであって、平成１４年８月２日付けで拒絶の理由が通知され、これに対し平成１４年９月２７日付けで手続補正がなされ、平成１５年６月３０日付けで拒絶査定がなされ、これに対し平成１５年８月６日に拒絶査定に対する審判請求がなされたものであり、その請求項１〜３に係る発明は、平成１４年９月２７日付けの手続補正によって補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１〜３に記載されたとおりのものと認められるところ、請求項１に係る発明（以下、「本願発明」という。）は、次のとおりのものである。
　「【請求項１】所有者からの預託を受けて証明書を保管する保管者が、証明書の記載事項である証明書情報を管理するとともに、所有者および第三者を含む照会依頼者からの証明書情報の照会依頼に対して証明書情報の認証を行う証明書管理システムにおいて、
　保管されている証明書毎に、証明書情報と所有者とが関連づけて記述されたレコードで構成された証明書データベースと、
　照会依頼者側システムとの間でネットワークを介したデータ通信が可能であり、かつ、前記証明書データベースの検索と更新とを行うコンピュータとを有し、
　前記コンピュータは、
　ある証明書の保管依頼を受けた場合、保管者によって入力された証明書情報が記述されたレコードを前記証明書データベースに追加し、
　ある証明書情報に関する照会依頼を照会依頼者側システムのより受けた場合、前記証明書データベースを検索し、照会対象となるレコードに記述されている証明書情報を照会結果として出力するとともに、当該照会結果を前記照会依頼者側システムに対してネットワークを介して伝達することにより、前記照会依頼者に対して証明書情報を認証することを特徴とする証明書管理システム。」
　
２．引用例
　原審の拒絶の理由に引用された特開平１１−５３４５０号公報（平成１１年２月２６日出願公開。以下、「引用例１」という。）には、図面と共に次の各記載がある。
　
（ア）「【０００１】
【発明の属する技術分野】
本発明は、銀行等で会社（法人）等の有価証券等を預かって管理するための支援システムを提供することである
【０００２】
【発明の背景】多くの会社において、保有有価証券を社内で、あるいは一部は社内で一部は証券会社等で保有しているというような証券管理をしている。取引関係の強化や、子会社・孫会社設立と関連して等、証券保有目的は様々であるが、
保有証券が各社共に決して小さい金額でなく、決算においても重要な要素を構成している。日々、月次、決算時それぞれで証券管理が必要であり、時価評価等の管理業務の負担は大きくなっている
【０００３】
この管理も事業部別、企業全体、企業グループの連結決算等のため、複雑な業務となっている。そして、各証券の時価評価や配当の管理もその事務負担は大きな問題である
企業内で高価な有価証券の現物を管理することも、火事や地震等の災害や盗難等の安全面で問題がある
【０００４】
このため、銀行等で企業や企業グループの保有する有価証券を預かるとともに、その管理も行う業務を行うニーズがある
【０００５】
【発明が解決しようとする課題】
本発明の目的は、会社が保有している有価証券（株、債券等）を銀行等で預かり、会社に代わって預かった有価証券を管理するためのコンピュータによるカストディ支援システムを提供することである
【０００６】また、
事業部別、会社全体、連結決算のための企業グループ等多階層で管理することも本発明のカストディ支援システムの目的である
【０００７】
【課題を解決するための手段】上記目的を達成するために、本発明は、顧客から預かった証券の保管・管理をするカストディ支援システムにおいて、各顧客別に、階層を指定するデータと、階層に基づいて送付先を指定するデータとを有し、これらのデータを用いて、管理データの送付先を決定することを特徴とする。
【０００８】この階層を管理するため、下位の階層であると指定された場合、対応する上位の階層の顧客データを有している。
【０００９】また、送付する前記管理データの種類を顧客ごとに指定するデータも有している。
【００１０】管理データには、預かった証券の集計データが含まれており、顧客別に、前記預かった証券の集計データを階層別に行うことを指定するデータを有することもできる。
【００１１】
管理データには預かった証券の評価額も含まれており、顧客から預かった証券の評価額を時価データで更新することも本発明の特徴である。この時価データは外部のデータベースから得ている
【００１２】
前記管理データは、記録媒体を用いて送付したり、通信を用いて送付したりすることもできる
【００１３】
その上、カストディ支援システムをコンピュータ・システムに実現させるプログラムを格納した記録媒体も本発明である
【００１４】上記発明では、預かり証券を管理するのに、関連する顧客を階層管理することができる。
【００１５】また、管理データを顧客に送付するとき、顧客ごとに送付する管理データの種類を指定することができる。
【００１６】預かり証券のデータの集計やその報告も、階層に従って集計・報告を行うことができる。
【００１７】
送付する管理データには、預かり証券の時価データが含まれており、顧客は常に、預けた証券の最新の時価評価額を知ることができる
【００１８】
送付データは、印刷データ以外に
通信やフロッピー・ディスク等の電子データとしても送付することができる
【００１９】また、
証券の売買依頼も顧客側から通信により行うことができる
【００２０】このように、
本支援システムを用いることにより、顧客は証券を預けることにより、預けた証券に対して、火事や地震等の災害から安全であるとともに、いろいろな管理サービスを受けることができる
　
（イ）「【００２１】
【発明の実施の形態】本発明の実施形態を、図面を参照して詳細に説明する。
【００２２】図１は、カストディ支援システムを実施するためのシステム構成図である。図１において、カストディ支援システム１１０は、外部データベース１３０に接続されている。この外部データベースは、有価証券の時価データを有しており、１日の決まった時間にカストディ支援システム１１０に対して、有価証券の時価データを送ってくる。この時価データは、カストディ支援システム１１０のデータベース内に取り込まれて利用される。
【００２３】また、カストディ支援システムは、有価証券の保管を依頼した顧客の内、希望した顧客に対しては、その顧客のシステム１４０に接続されている場合もある。
カストディ支援システム１１０と顧客システム１４０との接続は、色々な形態が可能である。例えば、ｓｗｉｆｔのような銀行間のネットワークやパソコン通信を介して接続することもできる。また、カストディ支援システム１１０と顧客システムとの間を専用回線を介して接続することもできる。また、セキュリティの問題が解決されれば、インターネットを介して接続することもできる
【００２４】さて、図１に示したカストディ支援システムにおいては、顧客に対して色々なサービスを行っている。本カストディ支援システムで行っている主なサービスを以下に列挙する。
【００２５】（１）
事業部別・グループ別の管理サービス
（２）
預かり証券の時価洗い替えサービス
（３）
各種レポートの報告
（４）
電子データによる報告サービス
（５）
電子メールによる売買等の指示
これらのサービスについて詳しく以下に説明する。」
　
（ウ）「【００２６】＜
事業部別・グループ別の管理サービス
顧客の中には、事業部や持ち株会社構想に基づくデビジョン・カンパニー制を採用している企業も多い。このような企業では、証券の保有も事業部やデビジョンの判断で行われていることから、証券管理も事業部ごとやデビジョンごとに行い、かつ企業全体での証券保有残高に統合するという２階層管理や３階層管理が必要となる
【００２７】本カストディ支援システムにおいては、上述のニーズを実現するための階層管理が可能である。この階層管理を用いて、本システムにおいては、報告先の管理や残高集計の管理を行っている。これを本システムにおいてどの様に実現しているかを図２〜図７を用いて詳しく説明する。
【００２８】図２は、本システムが用いている３階層管理を可能とする制御表２００を示している。システムは、この制御表２００を参照して主として報告のサービス等を、この制御表２００に示されている階層管理に基づき行っている。
【００２９】図２において、各投資家（顧客）コード２１０毎に、報告種類と報告要否定義を示すフラグ２１２、報告宛先２１４、報告区分２１６、階層区分２１８、親投資家２２０、子投資家２２２の欄を有している。以下で各欄の意味を説明する。
【００３０】報告種類と報告要否の定義を示すフラグ２１２は、その投資家に対して報告する種類を示している。このフラグが立っていれば（「１」であれば）、その種類の報告を対応する投資家に送るように処理される。この報告の種類としては、例えば、図３に示すようなものがある。
【００３１】図３の一覧表において、「受渡実行明細」３１０は、新規の保管依頼があって証券を受け取ったり、証券を顧客へ返還したりした結果の詳細を報告することである。「証券出入明細」３１２は、株の増資があったり、証券を買ったり売ったりした等の結果、預かり証券が出入するので、その詳細の報告である。
【００３２】「証券残高通知」３１４は、預かり証券の時価で評価した結果の合計残高の報告である。この預かり証券を時価で評価する処理に関しては、後で説明する。これらの報告は毎日行う場合は、日次のフラグが「１」となる。毎週行う場合は、週次の欄に英字半角３文字で報告を行う曜日を示す。毎月行う場合は、月次に「１」を立てる。
【００３３】「配当金入金（予定）」３１６は、保管依頼されている株式に対する配当金の入金の予定の報告である。この報告は、配当金が何時入金されるかを顧客に知らせるために設けられている。顧客は、この報告により、資金の計画を綿密に行うことができる。報告されるのは配当金の単価が確定した時である。配当金が実際に入金されると「配当金入金（確定）」３１８が「１」であれば、報告が行われる。
【００３４】「増資入庫（予定）」３２０および「増資入庫（確定）」３２２も同様に保管依頼されている株式に対する増資の予定と結果である。増資割当日に予定の報告がなされ、実際に入庫されると確定の報告が行われる。
【００３５】「利金入金（予定）」３２４および「利金入金（確定）」３２６と「償還入金（予定）」３２８および「償還入金（確定）」３３０は、上述と同様の預かり債券に対する利息金および償還金に対する報告である。債券に対する入金の予定は、入金される前月の２０日のように決まった日に報告が行われる。また、確定については入金された日に報告が行われる。
【００３６】「名義書換未済」３３２は、預かり証券の名義人が保管依頼した顧客ではなく、まだ名義の書き換えが行われていない証券の一覧の報告である。名義の書き換えが終了しないと配当金や利息は名義人の方へ入金されてしまう。
【００３７】図２に戻り、そこに示されている制御表２００において、報告宛先２１４は、回線等を介して報告を行う場合のアドレス等を示している。
【００３８】図２における報告区分２１６、階層区分２１８および残高集計２２４については、図４を用いて説明する。
【００３９】図４（ａ）は、階層区分２１８についての説明である。図４（ａ）において、階層区分「１００」は、図２における投資家コード１０１００に対して付与されているが、これは「単階層」すなわち子や孫を持たないものを意味している。また、「１１０」は、図２で投資家コード５０００００に対して付与されているが、これは、親子階層すなわち２階層で、その親の階層を示しているコードである。この２階層の子の階層に対しては、図２において５０１０００や５０２０００に対するように、「０１０」が付与されるとともに、親投資家の欄２２０に対応する親のコード（５０００００）を付けて対応関係を明示している。
【００４０】３階層である親子孫の親には「１１１」が付与され（図２の５１００００）、子は「０１１」（図２の５２００００、５３００００）、孫は「００１」（図２の５２１０００や５３１０００等）を付している。それぞれの対応関係を明示するために、上位の親および子のコードを親投資家２２０や子投資家２２２の欄に格納している。
【００４１】したがって、図２の階層関係は、階層区分２１８の欄のコードにしたがって、投資家コードで表すと、下記のようになる。
【００４２】
（１）親のみの単階層　
　　１０１０００および２６４０００
（２）親子の階層（２階層）関係　
　　５０００００−５０１０００
　　　　　　　　−５０２０００
（３）親子孫の階層（３階層）関係　
　　５１００００−　　　　　　−５１１０００
　　　　　　　　　　　　　　　−５１２０００
　　　　　　　　−５２００００−５２１０００
　　　　　　　　　　　　　　　−５２２０００
　　　　　　　　−５３００００−５３１０００
　　　　　　　　　　　　　　　−５３２０００
また、図３を用いて説明した各投資家に対する報告は、特に、その投資家が子や孫の階層のものである場合は、上位の階層に対してどのように報告を行うかは、図２の報告区分２１６の欄にあるコードで決められる。このコードは、図４（ｂ）にその意味が示されている。図４（ｂ）で「１００」は親にのみ報告される。また、「１１０」では親と子に対して、「１１１」は親、子、孫の３箇所に対して送られる。また、「０１０」は子のみ、「０１１」は子と孫、「００１」は孫のみである。
【００４３】階層関係において最後の指定は、残高集計区分２２４である。これは図４（ｃ）を用いて説明する。階層管理において、どの階層まで集計するかの指定をこの残高集計区分で指定することができる。この集計は、会社内の部門別等の管理ばかりではなく、特に連結決算が要求されるようになってから、特に重要な管理である。例えば、図２において、投資家コード５０１０００（階層では子）に対しては、残高集計コードは「１０」で、親に集計されて親に報告されることが分かる。また、投資家コード５２１０００（階層では孫）は、残高集計コード「１１」で親と子で集計されて、親と子に対して報告されることが分かる。
【００４４】さて、これらの階層関係の指定を用いて、報告を行う際にどのようにして報告先を決定しているかを図５を用いて説明する。
【００４５】図２において、投資家コード２１０を読み出して、対応する階層区分２１８と報告区分２１６を読み出す。このときの階層区分コードと報告区分コードにより、図５に記載されているように報告先を決定する。すなわち、階層区分コードが「１ｘｘ」（ｘは０でも１でもよい）（親）であり、報告区分コードが「１００」（親）であると親投資家の報告テーブル２１４に記載されている報告先アドレスにあてて報告を作成する。
【００４６】階層区分コードが「０１ｘ」（子）である場合、報告区分コードが「１ｘ０」（親）であると、親投資家の欄２２０に記載されている親の投資家コードの報告先に報告する。次に報告区分コードが「ｘ１０」（子）であると、子の報告先にも送る。
【００４７】階層区分「００１」（孫）である場合も、上記と同様に報告区分コードの「１」が立っている親、子、孫に対して作成した報告を送る。
【００４８】また、報告区分が「ｘ００」、「０ｘ０」、「００ｘ」の場合は、すくなくとも親や子等階層上位に対しては送らないように処理される。
【００４９】上述の階層処理を含む報告処理を図６を用いて詳しく説明する。まず、ある日の報告を行う場合、まず、報告対象の投資家の抽出（Ｓ６０２）を、図２の制御表２００における報告の種類と報告要否のテーブル２１２を用いて行う。つぎに、階層構成テーブルすなわち階層区分２１６と報告区分２１８を用いて、上述の図４および図５で説明したような処理により、上位階層への報告情報を作成する（Ｓ６０４）。これで、報告投資家情報の結果（リザルト）が得られる。そして、作成使用とする報告の種類により、そのファイルから報告対象データの抽出（Ｓ６０６）を行い、日本語マスタより、コード・データを対応する日本語に直す等報告データの編集（Ｓ６０８）を行い、報告データを作成する。
【００５０】報告投資家の結果としては、たとえば図７（ａ）のように、親の投資家のみ、図７（ｂ）のように、子の投資家と親の投資家、図７（ｃ）のように、親、子、孫の３階層の投資家のすべてに送る等がある。
【００５１】なお、制御表は図２に示されている欄のみだけではなく、その他の処理に必要な欄を有している。例えば、手紙や記録媒体（フロッピー・ディスク等）による報告サービスを行うかどうかのフラグ等である。また、報告の種類も図３に示されているものに限らない。階層も上述のように３階層ではなく、２階層でもよく、また４階層以上も必要に応じて同様に管理することが可能である。」
　
（エ）「【００５２】＜
預かり証券の時価洗い替えサービス
本システムで行っている預かり証券の時価洗い替えサービスについて説明する。
【００５３】さて、
図１のシステムの構成図に戻り、時価データは外部データベース１３０から本カストディ支援システム１１０に取り込まれる。これはその日の終値が確定するとき以後の定時に行われる。取り込まれた時価データを用いて、保管されている証券の時価データを更新する。この処理は、たとえば、図８に示しているフローチャートにように行われる
【００５４】図８において、まず、顧客一覧のファイルをオープンし（Ｓ８０２）、顧客の口座番号（投資家コード）を読み出す（Ｓ８０４）。そして、読み出した顧客に対応する残高ファイルをオープンして（Ｓ８０６）、その残高ファイルに含まれる証券のコードを読み出す（Ｓ８０８）。読み出した証券のコードに対応する時価情報を得て（Ｓ８１０）、残高ファイルの時価データを更新する（Ｓ８１２）。この処理を顧客の残高ファイルに証券データが終了するまで（Ｓ８１４）繰り返して行う。読み出した顧客の証券データに対する時価データの更新がすべて終了すると、その顧客のファイルを閉じて（Ｓ８１８）、次の顧客に対する処理を始める。全顧客に対して更新処理が終了する（Ｓ８２０）と、顧客一覧ファイルを閉じて（Ｓ８２２）、処理を終了する。
【００５５】残高に対する報告の例は、図９に示されている。この報告は、ある顧客に対する残高報告である。これには、時価の基準日が示されており、この基準日の終値で各証券の時価データを更新している。
【００５６】この報告書の一番右側から次の欄には「時価単価」のデータがあり、これが上記の処理で更新されている。この更新されたデータを証券残高にあるデータとかけ算をすることで、各証券の時価評価額（一番右側）が求められる。このような形で出力されるのは、図６において編集処理（Ｓ６０８）を行うためである。
【００５７】
この時価の更新処理は毎日定時に行われ、顧客への報告に対しては、翌日の報告から反映されることになる。この報告は、このような印刷物だけでなく、電子メールのような通信や、フロッピー・ディスクのような記録媒体に記録して顧客に対して渡すことができる
【００５８】このように、このカストディ支援システムにおいては、常に時価のデータが得られるため、単なる証券の保管や保管されている証券のデータだけでなく、決算等に必要なデータも得られる。
【００５９】また、上記図４（ｃ）で説明した残高集計に対する階層管理を用いると、部門別やグループ別の集計も得ることができる。
【００６０】この階層管理のデータは、預かりサービスをある顧客に対して開始する際や、既存の顧客に関連する顧客とのサービスを開始する際等に設定する必要がある。
【００６１】なお、外部データベースからのデータは上述の時価データばかりではなく、増資、配当、利金等のデータも得ることができる。」
　
（オ）「【００６２】＜
電子メールによる売買等の指示
このカストディ支援システムでは、電子メール等により、直接システムを介して証券を売買することができる。売買の対象の証券は、保管されている証券や保管される証券である。すなわち、売る対象は預かり証券であり、買った証券は契約により、自動的に預かり証券となる。
【００６３】この通信するデータの例が図１０に示されている。投資家コードは、前述のコードとは異なり、別途連絡したコードを用いている。投資家名は略称でもよい。約定日は西暦(YYYYMMDD)で指定する。受渡相手先および相手先アカウントも内部コードである。自動／マニュアルはマニュアル（「Ｍ」）の場合は、別途個別の指示がある場合である。通常は自動（「Ａ」）である。
【００６４】売買区分は売り取引の場合は「Ｓ」、買い取引の場合は「Ｂ」である。受け渡し日も西暦で指定する。レファレンス番号(reference number)は、顧客が付与する参照番号である。約定単価、株数等も送られてくる。これらのデータが複数送られてくるので、最後のデータには、識別データとして「END 」が送られる。そして、最後のデータに送信したデータの件数を付与する。
【００６５】
受け取った本カストディ支援システムは、投資家コードや預かり証券との照合・確認後、送られたデータに従って、売買注文を出すことができる。その結果は、上述の報告処理により注文主や階層管理における上位の顧客に対して送付される
【００６６】本発明のプログラムでその機能を実行している部分に関して、それを記録媒体上に格納し、それをコンピュータ・システムで読み出すことにより、実施することもできる。この記録媒体には、フロッピー・ディスク、ＣＤ−ＲＯＭ、磁気テープ、ＲＯＭカセット等がある。」
　
（カ）「【００６７】
【発明の効果】上記の説明のように、本発明のカストディ支援システムは、預かり証券を管理するのに、関連する顧客を階層管理することができる。
【００６８】また、管理データを顧客に送付するとき、顧客ごとに送付する管理データの種類を指定することができる。
【００６９】預かり証券のデータの集計やその報告も、階層に従って集計・報告を行うことができる。
【００７０】送付する管理データには、預かり証券の時価データが含まれており、顧客は常に、預けた証券の最新の時価評価額を知ることができる。
【００７１】送付データは、印刷データ以外に、通信やフロッピー・ディスク等の電子データとしても送付することができる。
【００７２】また、証券の売買依頼も顧客側から通信により行うことができる。
【００７３】このように、本支援システムを用いることにより、顧客は証券を預けることにより、預けた証券に対して、火事や地震等の災害から安全であるとともに、いろいろな管理サービスを受けることができる。」　　
　なお、下線は、審決において付された。
　
　以上の記載から見て、引用例１には、次のような発明が記載されているものと認められる。
　
　「銀行が保管者となり、顧客の預託を受けて株式、債券等の有価証券を保管・管理するカストディシステム１１０であって、
　顧客システム１４０とカストディシステム１１０とは、ネットワークを介して通信可能に結ばれており、
　カストディシステム１１０は、顧客の預託依頼があり、顧客から有価証券の保管依頼を受けた時、顧客名と、顧客が所有する有価証券に記載された情報とを対応付けてレコードを作成し該レコードをカストディ・データベース１２０に追加し、
　カストディシステム１１０は、日次、周次、または月次に、すなわち定期的に、カストディ・データベース１２０を検索し、一つ宛有価証券情報を取り出し、有価証券の価額を時価で評価するとともに配当等をも計算し、時価による評価額、配当、及び有価証券関連情報からなる報告書を作成し、該報告書をネットワークを介して次々と顧客システム１４０に送信し、
　そして、カストディシステム１１０は、顧客システム１４０から、電子メールによる有価証券売買の指示と依頼を受けた時には、依頼者と有価証券との照合・確認を行い、依頼者が本人でありかつ有価証券が本人の有価証券であることが確認された場合、依頼者から送られたデータにしたがって、売買注文を出し、その結果につき報告書を作成し、該報告書をネットワークを介して顧客システム１４０に送信するカストディシステム１１０。」
    
３．対比
　本願発明と引用例１に記載された発明とを対比すると、引用例１に記載された発明の「顧客すなわち投資家」は、本願発明の「所有者」に相当し、引用例１に記載された発明の「銀行」は、本願発明の「保管者」に相当し、引用例１に記載された発明の「株、債権等の有価証券」は、本願発明の「証明書」に相当し、引用例１に記載された発明の「有価証券に関する管理データ」は、本願発明の「証明書情報」に相当し、引用例１に記載された発明の「有価証券に関する各種の情報を記憶しているカストディ・データベース１２０」は、本願発明の「証明書データベース」に相当し、引用例１に記載された発明の「カストディ支援システム」は、本願発明の「証明書管理システム」に相当することは、明らかである。
　
　そして、引用例１には、銀行が、顧客の預託を受けて株式、債券等の有価証券を保管するとともに、有価証券に記載されている所有者名、銘柄名、金額等の情報をカストディ・データベース１２０に記憶管理することが記載されており、また、カストディシステム１１０は、顧客システム１４０から、電子メールによる有価証券売買の依頼を受けた時、依頼者と有価証券との照合・確認を行い、依頼者が本人でありかつ有価証券が本人の有価証券であることが確認された場合、売買注文を出し、その結果報告書を作成し、ネットワークを介して顧客システム１４０に送信することが記載されている（段落【００１９】，【００６２】〜【００６５】参照。）から、本願発明と引用例１に記載された発明とは、
　「所有者からの預託を受けて証明書を保管する保管者が、証明書の記載事項である証明書情報を管理するとともに、所有者に対して証明書情報の認証を行う証明書管理システム」
である点において、差異はない。
　
　引用例１には、カストディ・データベース１２０に記憶されている制御表２００は、「投資家コード２１０」、「報告書類と報告要否定義２１２」、「報告宛先２１４」、「報告区分２１６」、「階層区分２１８」、「親投資家２２０」、「子投資家２２２」、及び「残高集計２２４」の欄から構成され、これらの欄は対応付けられてレコードが作成され、該レコードは、制御表２００に記憶されることが記載されており（図２参照。）、また、カストディ・データベース１２０に記憶されている一覧表は、「投資家コード」、「受渡実行明細３１０」、「証券出入明細３１２」、「証券残高通知３１４」、「配当金入金（予定）３１６」、「配当金入金（確定）３１８」、「増資入庫（予定）３２０」、「増資入庫（確定）３２２」、「利金入金（予定）３２４」、「利金入金（確定）３２６」、「償還入金（予定）３２８」、「償還入金（確定）３３０」、及び「名義書換未済３３２」の欄から構成され、これらの欄は対応付けられてレコードが作成され、該レコードは、一覧表に記憶されることが記載されている（図３参照。）。すなわち、引用例１には、保管されている有価証券毎に、有価証券に関する情報と顧客名とが対応付けられてレコードが作成され、該レコードは、カストディ・データベース１２０に記憶されることが記載されている（図２及び３参照。）から、本願発明と引用例１に記載された発明とは、
　「保管されている証明書毎に、証明書情報と所有者とが関連づけて記述されたレコードで構成された証明書データベース」
を有する点で差異はない。
　
　引用例１には、カストディ支援システム１１０と顧客システム１４０とは、swiftのような銀行間ネットワーク、パソコン通信、専用回線、またはインターネットを介して相互に接続されることが記載され（段落【００１９】、【００２３】、【００６２】〜【００６５】参照。）、また預かった有価証券の管理は、コンピュータにより行われることが記載されており（段落【０００５】、【００１３】参照。）、しかもデータベースの検索と更新は、コンピュータにより行われることは、自明な技術常識であるから、本願発明と引用例１に記載された発明とは、
　「依頼者側システムとの間でネットワークを介したデータ通信が可能であり、かつ、前記証明書データベースの検索と更新とを行うコンピュータ」
を有する点で差異はない、
　
　引用例１に記載されたカストディ支援システム１１０は、顧客から有価証券の新たな保管依頼を受けた時、該有価証券に関する情報を記述したレコードをカストディ・データベース１２０に追加していることは、自明であるところ、引用例１には、カストディ・データベース１２０に記憶されている制御表１２０は、多数の投資家コードの欄２１０を有し（図面２参照。）、またカストディ・データベース１２０に記憶されている一覧表も、多数の投資家コードの欄を有し（図面３参照。）、これらの投資家コードは、投資家の新規預託があった時、欄に書き込まれたものであることは明白であるから、本願発明と引用例１に記載された発明とは、
　「前記コンピュータは、ある証明書の保管依頼を受けた場合、保管者によって入力された証明書情報が記述されたレコードを前記証明書データベースに追加」
する点で差異はない。
　
　引用例１には、カストディ支援システム１１０は、定期的に有価証券に関するカストディ・データベース１２０を検索し、レコードに記述されている有価証券に関する情報を検索結果として出力するともに、その検索結果である有価証券に関する情報を顧客システム１４０に対して、ネットワークを介して送信することが記載されている（段落【００５２】〜【００５８】、及び図８，９参照。）から、本願発明と引用例１に記載された発明とは、
　「前記証明書データベースを検索し、対象となるレコードに記述されている証明書情報を検索結果として出力するとともに、当該検索結果を前記依頼者側システムに対してネットワークを介して伝達することにより、前記依頼者に対して証明書情報を認証する証明書管理システム」
である点において差異はない。
　
　そうすると、本願発明と引用例１に記載された発明とは、
（一致点）
　「所有者からの預託を受けて証明書を保管する保管者が、証明書の記載事項である証明書情報を管理するとともに、所有者に対して証明書情報の認証を行う証明書管理システムにおいて、
　保管されている証明書毎に、証明書情報と所有者とが関連づけて記述されたレコードで構成された証明書データベースと、
　依頼者側システムとの間でネットワークを介したデータ通信が可能であり、かつ、前記証明書データベースの検索と更新とを行うコンピュータとを有し、
　前記コンピュータは、
　ある証明書の保管依頼を受けた場合、保管者によって入力された証明書情報が記述されたレコードを前記証明書データベースに追加し、
　証明書に関する検索事由が発生した場合、前記証明書データベースを検索し、対象となるレコードに記述されている証明書情報を検索結果として出力するとともに、当該検索結果を前記依頼者側システムに対してネットワークを介して伝達することにより、前記依頼者に対して証明書情報を認証する証明書管理システム。」
である点で一致し、次の点で相違する。
　
（相違点１）
　本願発明では、照会依頼者は所有者および第三者を含むのに対して、引用例１に記載された発明では、照会依頼者は顧客すなわち所有者である点。
　
（相違点２）
　本願発明では、依頼者からの照会依頼があった時に、証明書情報を出力しているのに対し、引用例１に記載された発明では、システム側が、定期的に有価証券（証明書に相当）に関する情報を送付している点。
　
４．当審の判断
（相違点１について）
　上記相違点１について判断するに、システムが本人だけを照会依頼者として受け付けるようにするか、または本人以外の第三者の照会依頼をも受け付けるようにするかは、システムの設計事項的問題であり、システム設計者が保管する書類すなわち証明書の重要性を考慮して適宜なし得ることである。
　
（相違点２について）
　上記相違点２について判断するに、
(i)一般に、多数のデータが登録されているデータベースを有する検索システムに対し、パーソナルコンピュータ等の端末側から、あるデータの照会依頼を実行すると、システムがデータベースを検索し、照会結果としてのそのデータを直ちに返送し、照会依頼者に対しそのデータを認証することは、当業者が通常行っている技術常識程度のことであり、(ii)また、引用例１には、カストディ支援システム１１０は、顧客システム１４０からネットワークを介して、有価証券売買の依頼を受けた時、依頼者の照合・確認を行い、有価証券に関するカストディ・データベース１２０を検索し、レコードに記載されている有価証券データと依頼者から送られたデータとに基づいて売買注文を実行し、結果報告書を作成し、ネットワークを介して顧客システム１４０に結果報告書を送信することが記載されている（段落【００１９】，【００６２】〜【００６５】参照。）から、以上(i)及び(ii)に示される事項に鑑みると、引用例１に記載された発明に、前記(i)及び(ii)に示される記載事項を適用して、本願発明の如く、依頼者からの照会依頼があった時に、照会結果としての証明書情報を出力するようにすることは、当業者が適宜なし得ることである。
　　
５．むすび
　以上のとおり、本願発明は、引用例１に記載された発明と周知技術とに基いて当業者が容易に発明をすることができたものであり、特許法第２９条第２項の規定により特許を受けることができないものであるから、他の請求項について検討するまでもなく、本願は、特許を受けることができない。
　よって、結論のとおり審決する。