拒絶査定不服の審決｜不服2003-15122 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

ポートフォリオを新規に作成して保存		追加
既存のポートフォリオに追加保存		追加

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服特36条6項1、2号及び3号請求の範囲の記載不備特許、登録しない。 G06F 審判査定不服 2項進歩性特許、登録しない。 G06F 審判査定不服特36条4項詳細な説明の記載不備特許、登録しない。 G06F 審判査定不服産業上利用性特許、登録しない。 G06F
管理番号	1128235
審判番号	不服2003-15122
総通号数	74
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2001-12-07
種別	拒絶査定不服の審決
審判請求日	2003-08-06
確定日	2005-12-21
事件の表示	特願2000-157676「証明書管理システム」拒絶査定不服審判事件〔平成13年12月 7日出願公開、特開2001-338040〕について、次のとおり審決する。
結論	本件審判の請求は、成り立たない。
理由	1.手続きの経緯・本願発明本願は、平成12年5月29日に出願されたものであって、平成14年8月2日付けで拒絶の理由が通知され、これに対し平成14年9月27日付けで手続補正がなされ、平成15年6月30日付けで拒絶査定がなされ、これに対し平成15年8月6日に拒絶査定に対する審判請求がなされたものであり、その請求項1～3に係る発明は、平成14年9月27日付けの手続補正によって補正された明細書及び図面の記載からみて、特許請求の範囲の請求項1～3に記載されたとおりのものと認められるところ、請求項1に係る発明(以下、「本願発明」という。)は、次のとおりのものである。「【請求項1】所有者からの預託を受けて証明書を保管する保管者が、証明書の記載事項である証明書情報を管理するとともに、所有者および第三者を含む照会依頼者からの証明書情報の照会依頼に対して証明書情報の認証を行う証明書管理システムにおいて、保管されている証明書毎に、証明書情報と所有者とが関連づけて記述されたレコードで構成された証明書データベースと、照会依頼者側システムとの間でネットワークを介したデータ通信が可能であり、かつ、前記証明書データベースの検索と更新とを行うコンピュータとを有し、前記コンピュータは、ある証明書の保管依頼を受けた場合、保管者によって入力された証明書情報が記述されたレコードを前記証明書データベースに追加し、ある証明書情報に関する照会依頼を照会依頼者側システムのより受けた場合、前記証明書データベースを検索し、照会対象となるレコードに記述されている証明書情報を照会結果として出力するとともに、当該照会結果を前記照会依頼者側システムに対してネットワークを介して伝達することにより、前記照会依頼者に対して証明書情報を認証することを特徴とする証明書管理システム。」 2.引用例原審の拒絶の理由に引用された特開平11-53450号公報(平成11年2月26日出願公開。以下、「引用例1」という。)には、図面と共に次の各記載がある。 (ア)「【0001】【発明の属する技術分野】本発明は、銀行等で会社(法人)等の有価証券等を預かって管理するための支援システムを提供することである。【0002】【発明の背景】多くの会社において、保有有価証券を社内で、あるいは一部は社内で一部は証券会社等で保有しているというような証券管理をしている。取引関係の強化や、子会社・孫会社設立と関連して等、証券保有目的は様々であるが、保有証券が各社共に決して小さい金額でなく、決算においても重要な要素を構成している。日々、月次、決算時それぞれで証券管理が必要であり、時価評価等の管理業務の負担は大きくなっている。【0003】この管理も事業部別、企業全体、企業グループの連結決算等のため、複雑な業務となっている。そして、各証券の時価評価や配当の管理もその事務負担は大きな問題である。また、企業内で高価な有価証券の現物を管理することも、火事や地震等の災害や盗難等の安全面で問題がある。【0004】このため、銀行等で企業や企業グループの保有する有価証券を預かるとともに、その管理も行う業務を行うニーズがある。【0005】【発明が解決しようとする課題】本発明の目的は、会社が保有している有価証券(株、債券等)を銀行等で預かり、会社に代わって預かった有価証券を管理するためのコンピュータによるカストディ支援システムを提供することである。【0006】また、事業部別、会社全体、連結決算のための企業グループ等多階層で管理することも本発明のカストディ支援システムの目的である。【0007】【課題を解決するための手段】上記目的を達成するために、本発明は、顧客から預かった証券の保管・管理をするカストディ支援システムにおいて、各顧客別に、階層を指定するデータと、階層に基づいて送付先を指定するデータとを有し、これらのデータを用いて、管理データの送付先を決定することを特徴とする。【0008】この階層を管理するため、下位の階層であると指定された場合、対応する上位の階層の顧客データを有している。【0009】また、送付する前記管理データの種類を顧客ごとに指定するデータも有している。【0010】管理データには、預かった証券の集計データが含まれており、顧客別に、前記預かった証券の集計データを階層別に行うことを指定するデータを有することもできる。【0011】管理データには預かった証券の評価額も含まれており、顧客から預かった証券の評価額を時価データで更新することも本発明の特徴である。この時価データは外部のデータベースから得ている。【0012】前記管理データは、記録媒体を用いて送付したり、通信を用いて送付したりすることもできる。【0013】その上、カストディ支援システムをコンピュータ・システムに実現させるプログラムを格納した記録媒体も本発明である。【0014】上記発明では、預かり証券を管理するのに、関連する顧客を階層管理することができる。【0015】また、管理データを顧客に送付するとき、顧客ごとに送付する管理データの種類を指定することができる。【0016】預かり証券のデータの集計やその報告も、階層に従って集計・報告を行うことができる。【0017】送付する管理データには、預かり証券の時価データが含まれており、顧客は常に、預けた証券の最新の時価評価額を知ることができる。【0018】送付データは、印刷データ以外に、通信やフロッピー・ディスク等の電子データとしても送付することができる。【0019】また、証券の売買依頼も顧客側から通信により行うことができる。【0020】このように、本支援システムを用いることにより、顧客は証券を預けることにより、預けた証券に対して、火事や地震等の災害から安全であるとともに、いろいろな管理サービスを受けることができる。」 (イ)「【0021】【発明の実施の形態】本発明の実施形態を、図面を参照して詳細に説明する。【0022】図1は、カストディ支援システムを実施するためのシステム構成図である。図1において、カストディ支援システム110は、外部データベース130に接続されている。この外部データベースは、有価証券の時価データを有しており、1日の決まった時間にカストディ支援システム110に対して、有価証券の時価データを送ってくる。この時価データは、カストディ支援システム110のデータベース内に取り込まれて利用される。【0023】また、カストディ支援システムは、有価証券の保管を依頼した顧客の内、希望した顧客に対しては、その顧客のシステム140に接続されている場合もある。カストディ支援システム110と顧客システム140との接続は、色々な形態が可能である。例えば、ｓｗifｔのような銀行間のネットワークやパソコン通信を介して接続することもできる。また、カストディ支援システム110と顧客システムとの間を専用回線を介して接続することもできる。また、セキュリティの問題が解決されれば、インターネットを介して接続することもできる。【0024】さて、図1に示したカストディ支援システムにおいては、顧客に対して色々なサービスを行っている。本カストディ支援システムで行っている主なサービスを以下に列挙する。【0025】(1)事業部別・グループ別の管理サービス (2)預かり証券の時価洗い替えサービス (3)各種レポートの報告 (4)電子データによる報告サービス (5)電子メールによる売買等の指示これらのサービスについて詳しく以下に説明する。」 (ウ)「【0026】＜事業部別・グループ別の管理サービス＞顧客の中には、事業部や持ち株会社構想に基づくデビジョン・カンパニー制を採用している企業も多い。このような企業では、証券の保有も事業部やデビジョンの判断で行われていることから、証券管理も事業部ごとやデビジョンごとに行い、かつ企業全体での証券保有残高に統合するという2階層管理や3階層管理が必要となる。また、保管している証券の事業部別ではなく、保有目的別の管理の依頼もある。【0027】本カストディ支援システムにおいては、上述のニーズを実現するための階層管理が可能である。この階層管理を用いて、本システムにおいては、報告先の管理や残高集計の管理を行っている。これを本システムにおいてどの様に実現しているかを図2～図7を用いて詳しく説明する。【0028】図2は、本システムが用いている3階層管理を可能とする制御表200を示している。システムは、この制御表200を参照して主として報告のサービス等を、この制御表200に示されている階層管理に基づき行っている。【0029】図2において、各投資家(顧客)コード210毎に、報告種類と報告要否定義を示すフラグ212、報告宛先214、報告区分216、階層区分218、親投資家220、子投資家222の欄を有している。以下で各欄の意味を説明する。【0030】報告種類と報告要否の定義を示すフラグ212は、その投資家に対して報告する種類を示している。このフラグが立っていれば(「1」であれば)、その種類の報告を対応する投資家に送るように処理される。この報告の種類としては、例えば、図3に示すようなものがある。【0031】図3の一覧表において、「受渡実行明細」310は、新規の保管依頼があって証券を受け取ったり、証券を顧客へ返還したりした結果の詳細を報告することである。「証券出入明細」312は、株の増資があったり、証券を買ったり売ったりした等の結果、預かり証券が出入するので、その詳細の報告である。【0032】「証券残高通知」314は、預かり証券の時価で評価した結果の合計残高の報告である。この預かり証券を時価で評価する処理に関しては、後で説明する。これらの報告は毎日行う場合は、日次のフラグが「1」となる。毎週行う場合は、週次の欄に英字半角3文字で報告を行う曜日を示す。毎月行う場合は、月次に「1」を立てる。【0033】「配当金入金(予定)」316は、保管依頼されている株式に対する配当金の入金の予定の報告である。この報告は、配当金が何時入金されるかを顧客に知らせるために設けられている。顧客は、この報告により、資金の計画を綿密に行うことができる。報告されるのは配当金の単価が確定した時である。配当金が実際に入金されると「配当金入金(確定)」318が「1」であれば、報告が行われる。【0034】「増資入庫(予定)」320および「増資入庫(確定)」322も同様に保管依頼されている株式に対する増資の予定と結果である。増資割当日に予定の報告がなされ、実際に入庫されると確定の報告が行われる。【0035】「利金入金(予定)」324および「利金入金(確定)」326と「償還入金(予定)」328および「償還入金(確定)」330は、上述と同様の預かり債券に対する利息金および償還金に対する報告である。債券に対する入金の予定は、入金される前月の20日のように決まった日に報告が行われる。また、確定については入金された日に報告が行われる。【0036】「名義書換未済」332は、預かり証券の名義人が保管依頼した顧客ではなく、まだ名義の書き換えが行われていない証券の一覧の報告である。名義の書き換えが終了しないと配当金や利息は名義人の方へ入金されてしまう。【0037】図2に戻り、そこに示されている制御表200において、報告宛先214は、回線等を介して報告を行う場合のアドレス等を示している。【0038】図2における報告区分216、階層区分218および残高集計224については、図4を用いて説明する。【0039】図4(a)は、階層区分218についての説明である。図4(a)において、階層区分「100」は、図2における投資家コード10100に対して付与されているが、これは「単階層」すなわち子や孫を持たないものを意味している。また、「110」は、図2で投資家コード500000に対して付与されているが、これは、親子階層すなわち2階層で、その親の階層を示しているコードである。この2階層の子の階層に対しては、図2において501000や502000に対するように、「010」が付与されるとともに、親投資家の欄220に対応する親のコード(500000)を付けて対応関係を明示している。【0040】3階層である親子孫の親には「111」が付与され(図2の510000)、子は「011」(図2の520000、530000)、孫は「001」(図2の521000や531000等)を付している。それぞれの対応関係を明示するために、上位の親および子のコードを親投資家220や子投資家222の欄に格納している。【0041】したがって、図2の階層関係は、階層区分218の欄のコードにしたがって、投資家コードで表すと、下記のようになる。【0042】 (1)親のみの単階層 101000および264000 (2)親子の階層(2階層)関係 500000-501000 -502000 (3)親子孫の階層(3階層)関係 510000- -511000 -512000 -520000-521000 -522000 -530000-531000 -532000 また、図3を用いて説明した各投資家に対する報告は、特に、その投資家が子や孫の階層のものである場合は、上位の階層に対してどのように報告を行うかは、図2の報告区分216の欄にあるコードで決められる。このコードは、図4(b)にその意味が示されている。図4(b)で「100」は親にのみ報告される。また、「110」では親と子に対して、「111」は親、子、孫の3箇所に対して送られる。また、「010」は子のみ、「011」は子と孫、「001」は孫のみである。【0043】階層関係において最後の指定は、残高集計区分224である。これは図4(c)を用いて説明する。階層管理において、どの階層まで集計するかの指定をこの残高集計区分で指定することができる。この集計は、会社内の部門別等の管理ばかりではなく、特に連結決算が要求されるようになってから、特に重要な管理である。例えば、図2において、投資家コード501000(階層では子)に対しては、残高集計コードは「10」で、親に集計されて親に報告されることが分かる。また、投資家コード521000(階層では孫)は、残高集計コード「11」で親と子で集計されて、親と子に対して報告されることが分かる。【0044】さて、これらの階層関係の指定を用いて、報告を行う際にどのようにして報告先を決定しているかを図5を用いて説明する。【0045】図2において、投資家コード210を読み出して、対応する階層区分218と報告区分216を読み出す。このときの階層区分コードと報告区分コードにより、図5に記載されているように報告先を決定する。すなわち、階層区分コードが「1ｘｘ」(ｘは0でも1でもよい)(親)であり、報告区分コードが「100」(親)であると親投資家の報告テーブル214に記載されている報告先アドレスにあてて報告を作成する。【0046】階層区分コードが「01ｘ」(子)である場合、報告区分コードが「1ｘ0」(親)であると、親投資家の欄220に記載されている親の投資家コードの報告先に報告する。次に報告区分コードが「ｘ10」(子)であると、子の報告先にも送る。【0047】階層区分「001」(孫)である場合も、上記と同様に報告区分コードの「1」が立っている親、子、孫に対して作成した報告を送る。【0048】また、報告区分が「ｘ00」、「0ｘ0」、「00ｘ」の場合は、すくなくとも親や子等階層上位に対しては送らないように処理される。【0049】上述の階層処理を含む報告処理を図6を用いて詳しく説明する。まず、ある日の報告を行う場合、まず、報告対象の投資家の抽出(S602)を、図2の制御表200における報告の種類と報告要否のテーブル212を用いて行う。つぎに、階層構成テーブルすなわち階層区分216と報告区分218を用いて、上述の図4および図5で説明したような処理により、上位階層への報告情報を作成する(S604)。これで、報告投資家情報の結果(リザルト)が得られる。そして、作成使用とする報告の種類により、そのファイルから報告対象データの抽出(S606)を行い、日本語マスタより、コード・データを対応する日本語に直す等報告データの編集(S608)を行い、報告データを作成する。【0050】報告投資家の結果としては、たとえば図7(a)のように、親の投資家のみ、図7(b)のように、子の投資家と親の投資家、図7(c)のように、親、子、孫の3階層の投資家のすべてに送る等がある。【0051】なお、制御表は図2に示されている欄のみだけではなく、その他の処理に必要な欄を有している。例えば、手紙や記録媒体(フロッピー・ディスク等)による報告サービスを行うかどうかのフラグ等である。また、報告の種類も図3に示されているものに限らない。階層も上述のように3階層ではなく、2階層でもよく、また4階層以上も必要に応じて同様に管理することが可能である。」 (エ)「【0052】＜預かり証券の時価洗い替えサービス＞本システムで行っている預かり証券の時価洗い替えサービスについて説明する。【0053】さて、図1のシステムの構成図に戻り、時価データは外部データベース130から本カストディ支援システム110に取り込まれる。これはその日の終値が確定するとき以後の定時に行われる。取り込まれた時価データを用いて、保管されている証券の時価データを更新する。この処理は、たとえば、図8に示しているフローチャートにように行われる。【0054】図8において、まず、顧客一覧のファイルをオープンし(S802)、顧客の口座番号(投資家コード)を読み出す(S804)。そして、読み出した顧客に対応する残高ファイルをオープンして(S806)、その残高ファイルに含まれる証券のコードを読み出す(S808)。読み出した証券のコードに対応する時価情報を得て(S810)、残高ファイルの時価データを更新する(S812)。この処理を顧客の残高ファイルに証券データが終了するまで(S814)繰り返して行う。読み出した顧客の証券データに対する時価データの更新がすべて終了すると、その顧客のファイルを閉じて(S818)、次の顧客に対する処理を始める。全顧客に対して更新処理が終了する(S820)と、顧客一覧ファイルを閉じて(S822)、処理を終了する。【0055】残高に対する報告の例は、図9に示されている。この報告は、ある顧客に対する残高報告である。これには、時価の基準日が示されており、この基準日の終値で各証券の時価データを更新している。【0056】この報告書の一番右側から次の欄には「時価単価」のデータがあり、これが上記の処理で更新されている。この更新されたデータを証券残高にあるデータとかけ算をすることで、各証券の時価評価額(一番右側)が求められる。このような形で出力されるのは、図6において編集処理(S608)を行うためである。【0057】この時価の更新処理は毎日定時に行われ、顧客への報告に対しては、翌日の報告から反映されることになる。この報告は、このような印刷物だけでなく、電子メールのような通信や、フロッピー・ディスクのような記録媒体に記録して顧客に対して渡すことができる。【0058】このように、このカストディ支援システムにおいては、常に時価のデータが得られるため、単なる証券の保管や保管されている証券のデータだけでなく、決算等に必要なデータも得られる。【0059】また、上記図4(c)で説明した残高集計に対する階層管理を用いると、部門別やグループ別の集計も得ることができる。【0060】この階層管理のデータは、預かりサービスをある顧客に対して開始する際や、既存の顧客に関連する顧客とのサービスを開始する際等に設定する必要がある。【0061】なお、外部データベースからのデータは上述の時価データばかりではなく、増資、配当、利金等のデータも得ることができる。」 (オ)「【0062】＜電子メールによる売買等の指示＞このカストディ支援システムでは、電子メール等により、直接システムを介して証券を売買することができる。売買の対象の証券は、保管されている証券や保管される証券である。すなわち、売る対象は預かり証券であり、買った証券は契約により、自動的に預かり証券となる。【0063】この通信するデータの例が図10に示されている。投資家コードは、前述のコードとは異なり、別途連絡したコードを用いている。投資家名は略称でもよい。約定日は西暦(YYYYMMDD)で指定する。受渡相手先および相手先アカウントも内部コードである。自動/マニュアルはマニュアル(「M」)の場合は、別途個別の指示がある場合である。通常は自動(「A」)である。【0064】売買区分は売り取引の場合は「S」、買い取引の場合は「B」である。受け渡し日も西暦で指定する。レファレンス番号(reference number)は、顧客が付与する参照番号である。約定単価、株数等も送られてくる。これらのデータが複数送られてくるので、最後のデータには、識別データとして「END 」が送られる。そして、最後のデータに送信したデータの件数を付与する。【0065】受け取った本カストディ支援システムは、投資家コードや預かり証券との照合・確認後、送られたデータに従って、売買注文を出すことができる。その結果は、上述の報告処理により注文主や階層管理における上位の顧客に対して送付される。【0066】本発明のプログラムでその機能を実行している部分に関して、それを記録媒体上に格納し、それをコンピュータ・システムで読み出すことにより、実施することもできる。この記録媒体には、フロッピー・ディスク、CD-ROM、磁気テープ、ROMカセット等がある。」 (カ)「【0067】【発明の効果】上記の説明のように、本発明のカストディ支援システムは、預かり証券を管理するのに、関連する顧客を階層管理することができる。【0068】また、管理データを顧客に送付するとき、顧客ごとに送付する管理データの種類を指定することができる。【0069】預かり証券のデータの集計やその報告も、階層に従って集計・報告を行うことができる。【0070】送付する管理データには、預かり証券の時価データが含まれており、顧客は常に、預けた証券の最新の時価評価額を知ることができる。【0071】送付データは、印刷データ以外に、通信やフロッピー・ディスク等の電子データとしても送付することができる。【0072】また、証券の売買依頼も顧客側から通信により行うことができる。【0073】このように、本支援システムを用いることにより、顧客は証券を預けることにより、預けた証券に対して、火事や地震等の災害から安全であるとともに、いろいろな管理サービスを受けることができる。」なお、下線は、審決において付された。以上の記載から見て、引用例1には、次のような発明が記載されているものと認められる。「銀行が保管者となり、顧客の預託を受けて株式、債券等の有価証券を保管・管理するカストディシステム110であって、顧客システム140とカストディシステム110とは、ネットワークを介して通信可能に結ばれており、カストディシステム110は、顧客の預託依頼があり、顧客から有価証券の保管依頼を受けた時、顧客名と、顧客が所有する有価証券に記載された情報とを対応付けてレコードを作成し該レコードをカストディ・データベース120に追加し、カストディシステム110は、日次、周次、または月次に、すなわち定期的に、カストディ・データベース120を検索し、一つ宛有価証券情報を取り出し、有価証券の価額を時価で評価するとともに配当等をも計算し、時価による評価額、配当、及び有価証券関連情報からなる報告書を作成し、該報告書をネットワークを介して次々と顧客システム140に送信し、そして、カストディシステム110は、顧客システム140から、電子メールによる有価証券売買の指示と依頼を受けた時には、依頼者と有価証券との照合・確認を行い、依頼者が本人でありかつ有価証券が本人の有価証券であることが確認された場合、依頼者から送られたデータにしたがって、売買注文を出し、その結果につき報告書を作成し、該報告書をネットワークを介して顧客システム140に送信するカストディシステム110。」 3.対比本願発明と引用例1に記載された発明とを対比すると、引用例1に記載された発明の「顧客すなわち投資家」は、本願発明の「所有者」に相当し、引用例1に記載された発明の「銀行」は、本願発明の「保管者」に相当し、引用例1に記載された発明の「株、債権等の有価証券」は、本願発明の「証明書」に相当し、引用例1に記載された発明の「有価証券に関する管理データ」は、本願発明の「証明書情報」に相当し、引用例1に記載された発明の「有価証券に関する各種の情報を記憶しているカストディ・データベース120」は、本願発明の「証明書データベース」に相当し、引用例1に記載された発明の「カストディ支援システム」は、本願発明の「証明書管理システム」に相当することは、明らかである。そして、引用例1には、銀行が、顧客の預託を受けて株式、債券等の有価証券を保管するとともに、有価証券に記載されている所有者名、銘柄名、金額等の情報をカストディ・データベース120に記憶管理することが記載されており、また、カストディシステム110は、顧客システム140から、電子メールによる有価証券売買の依頼を受けた時、依頼者と有価証券との照合・確認を行い、依頼者が本人でありかつ有価証券が本人の有価証券であることが確認された場合、売買注文を出し、その結果報告書を作成し、ネットワークを介して顧客システム140に送信することが記載されている(段落【0019】,【0062】～【0065】参照。)から、本願発明と引用例1に記載された発明とは、「所有者からの預託を受けて証明書を保管する保管者が、証明書の記載事項である証明書情報を管理するとともに、所有者に対して証明書情報の認証を行う証明書管理システム」である点において、差異はない。引用例1には、カストディ・データベース120に記憶されている制御表200は、「投資家コード210」、「報告書類と報告要否定義212」、「報告宛先214」、「報告区分216」、「階層区分218」、「親投資家220」、「子投資家222」、及び「残高集計224」の欄から構成され、これらの欄は対応付けられてレコードが作成され、該レコードは、制御表200に記憶されることが記載されており(図2参照。)、また、カストディ・データベース120に記憶されている一覧表は、「投資家コード」、「受渡実行明細310」、「証券出入明細312」、「証券残高通知314」、「配当金入金(予定)316」、「配当金入金(確定)318」、「増資入庫(予定)320」、「増資入庫(確定)322」、「利金入金(予定)324」、「利金入金(確定)326」、「償還入金(予定)328」、「償還入金(確定)330」、及び「名義書換未済332」の欄から構成され、これらの欄は対応付けられてレコードが作成され、該レコードは、一覧表に記憶されることが記載されている(図3参照。)。すなわち、引用例1には、保管されている有価証券毎に、有価証券に関する情報と顧客名とが対応付けられてレコードが作成され、該レコードは、カストディ・データベース120に記憶されることが記載されている(図2及び3参照。)から、本願発明と引用例1に記載された発明とは、「保管されている証明書毎に、証明書情報と所有者とが関連づけて記述されたレコードで構成された証明書データベース」を有する点で差異はない。引用例1には、カストディ支援システム110と顧客システム140とは、swiftのような銀行間ネットワーク、パソコン通信、専用回線、またはインターネットを介して相互に接続されることが記載され(段落【0019】、【0023】、【0062】～【0065】参照。)、また預かった有価証券の管理は、コンピュータにより行われることが記載されており(段落【0005】、【0013】参照。)、しかもデータベースの検索と更新は、コンピュータにより行われることは、自明な技術常識であるから、本願発明と引用例1に記載された発明とは、「依頼者側システムとの間でネットワークを介したデータ通信が可能であり、かつ、前記証明書データベースの検索と更新とを行うコンピュータ」を有する点で差異はない、引用例1に記載されたカストディ支援システム110は、顧客から有価証券の新たな保管依頼を受けた時、該有価証券に関する情報を記述したレコードをカストディ・データベース120に追加していることは、自明であるところ、引用例1には、カストディ・データベース120に記憶されている制御表120は、多数の投資家コードの欄210を有し(図面2参照。)、またカストディ・データベース120に記憶されている一覧表も、多数の投資家コードの欄を有し(図面3参照。)、これらの投資家コードは、投資家の新規預託があった時、欄に書き込まれたものであることは明白であるから、本願発明と引用例1に記載された発明とは、「前記コンピュータは、ある証明書の保管依頼を受けた場合、保管者によって入力された証明書情報が記述されたレコードを前記証明書データベースに追加」する点で差異はない。引用例1には、カストディ支援システム110は、定期的に有価証券に関するカストディ・データベース120を検索し、レコードに記述されている有価証券に関する情報を検索結果として出力するともに、その検索結果である有価証券に関する情報を顧客システム140に対して、ネットワークを介して送信することが記載されている(段落【0052】～【0058】、及び図8,9参照。)から、本願発明と引用例1に記載された発明とは、「前記証明書データベースを検索し、対象となるレコードに記述されている証明書情報を検索結果として出力するとともに、当該検索結果を前記依頼者側システムに対してネットワークを介して伝達することにより、前記依頼者に対して証明書情報を認証する証明書管理システム」である点において差異はない。そうすると、本願発明と引用例1に記載された発明とは、 (一致点) 「所有者からの預託を受けて証明書を保管する保管者が、証明書の記載事項である証明書情報を管理するとともに、所有者に対して証明書情報の認証を行う証明書管理システムにおいて、保管されている証明書毎に、証明書情報と所有者とが関連づけて記述されたレコードで構成された証明書データベースと、依頼者側システムとの間でネットワークを介したデータ通信が可能であり、かつ、前記証明書データベースの検索と更新とを行うコンピュータとを有し、前記コンピュータは、ある証明書の保管依頼を受けた場合、保管者によって入力された証明書情報が記述されたレコードを前記証明書データベースに追加し、証明書に関する検索事由が発生した場合、前記証明書データベースを検索し、対象となるレコードに記述されている証明書情報を検索結果として出力するとともに、当該検索結果を前記依頼者側システムに対してネットワークを介して伝達することにより、前記依頼者に対して証明書情報を認証する証明書管理システム。」である点で一致し、次の点で相違する。 (相違点1) 本願発明では、照会依頼者は所有者および第三者を含むのに対して、引用例1に記載された発明では、照会依頼者は顧客すなわち所有者である点。 (相違点2) 本願発明では、依頼者からの照会依頼があった時に、証明書情報を出力しているのに対し、引用例1に記載された発明では、システム側が、定期的に有価証券(証明書に相当)に関する情報を送付している点。 4.当審の判断 (相違点1について) 上記相違点1について判断するに、システムが本人だけを照会依頼者として受け付けるようにするか、または本人以外の第三者の照会依頼をも受け付けるようにするかは、システムの設計事項的問題であり、システム設計者が保管する書類すなわち証明書の重要性を考慮して適宜なし得ることである。 (相違点2について) 上記相違点2について判断するに、 (i)一般に、多数のデータが登録されているデータベースを有する検索システムに対し、パーソナルコンピュータ等の端末側から、あるデータの照会依頼を実行すると、システムがデータベースを検索し、照会結果としてのそのデータを直ちに返送し、照会依頼者に対しそのデータを認証することは、当業者が通常行っている技術常識程度のことであり、(ii)また、引用例1には、カストディ支援システム110は、顧客システム140からネットワークを介して、有価証券売買の依頼を受けた時、依頼者の照合・確認を行い、有価証券に関するカストディ・データベース120を検索し、レコードに記載されている有価証券データと依頼者から送られたデータとに基づいて売買注文を実行し、結果報告書を作成し、ネットワークを介して顧客システム140に結果報告書を送信することが記載されている(段落【0019】,【0062】～【0065】参照。)から、以上(i)及び(ii)に示される事項に鑑みると、引用例1に記載された発明に、前記(i)及び(ii)に示される記載事項を適用して、本願発明の如く、依頼者からの照会依頼があった時に、照会結果としての証明書情報を出力するようにすることは、当業者が適宜なし得ることである。 5.むすび以上のとおり、本願発明は、引用例1に記載された発明と周知技術とに基いて当業者が容易に発明をすることができたものであり、特許法第29条第2項の規定により特許を受けることができないものであるから、他の請求項について検討するまでもなく、本願は、特許を受けることができない。よって、結論のとおり審決する。
審理終結日	2005-09-27
結審通知日	2005-10-03
審決日	2005-11-08
出願番号	特願2000-157676(P2000-157676)
審決分類	P 1 8・ 536- Z (G06F) P 1 8・ 537- Z (G06F) P 1 8・ 121- Z (G06F) P 1 8・ 14- Z (G06F)
最終処分	不成立
前審関与審査官	谷口信行
特許庁審判長	関川正志
特許庁審判官	岡本俊威大野弘
発明の名称	証明書管理システム
代理人	久米川正光

プライバシーポリシーセキュリティーポリシー運営会社概要サービスに関しての問い合わせ