【事件の表示】
　特願２００３−３２６９８１「医療機関検索サービスを提供する方法、個人医療情報検索サービスを提供する方法およびコンピュータシステム」拒絶査定不服審判事件〔平成１７年　４月　７日出願公開、特開２００５−　９２６５０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　
　本件出願は，平成１５年９月１８日の出願であって，平成１８年６月２６日付けで拒絶査定がなされ，これに対し，同年７月２７日に拒絶査定に対する審判請求がなされるとともに，同年８月２８日付けで手続補正がなされ，当審において，平成２１年１月８日付け審尋に対し，同年３月９日付けで回答書が提出され，同年５月１１日付けで平成１８年８月２８日付けの手続補正の却下の決定がなされ，同日付けの拒絶理由通知に対し，同年７月１３日付けで手続補正がなされたものである。
　
　
２．本件発明
　
　本件の請求項１に係る発明（以下，「本件発明」という。）は，平成２１年７月１３日付け手続補正により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された事項により特定される，以下のとおりのものである。
　
「　【請求項１】
　第１の端末装置と複数の第２の端末装置と第１のサーバー装置と第２のサーバー装置とを含むコンピュータシステムを用いて，個人医療情報検索サービスを提供する方法であって，
　前記第１の端末装置と前記第２の端末装置と前記第１のサーバー装置と前記第２のサーバー装置とはネットワークを介して互いに接続されており，前記第１のサーバー装置には，各医療機関に関する情報と各医療機関が診療可能な症状を示す情報とを対応づけて格納した医療機関データベースが接続されており，前記第２のサーバー装置には，各個人を識別するためにバイナリデータで表現された個人識別情報と各個人を特定するための個人特定情報とを対応づけて格納した個人認証データベースと，各個人識別情報と各個人医療情報とを対応づけて格納した個人医療情報データベースとが接続されており，
　前記方法は，
　（ａ）前記第１のサーバー装置が，ユーザの症状を示す症状情報を前記第１の端末装置から受信するステップと，
　（ｂ）前記第１のサーバー装置が，前記第１の端末装置から受信した前記症状情報を検索条件として前記医療機関データベースを検索することにより，前記第１の端末装置から受信した前記症状情報に対応する少なくとも１つの医療機関に関する情報を取得するステップと，
　（ｃ）前記第１のサーバー装置が，前記少なくとも１つの医療機関に関する情報を前記第１の端末装置に送信するステップと，
　（ｄ）前記第１のサーバー装置が，前記少なくとも１つの医療機関のうち前記ユーザによって選択された医療機関を特定する医療機関特定情報を前記第１の端末装置から受信するステップと
　を包含し，
　前記方法は，
　（ｅ）前記第１のサーバー装置が，前記医療機関特定情報を前記第１の端末装置から受信したことに応答して，前記複数の第２の端末装置のうち，前記医療機関特定情報によって特定された医療機関に設置されている第２の端末装置に，前記第２のサーバー装置へのアクセスを可能にするアクセス情報として前記第２のサーバー装置のＵＲＬアドレスを送信するステップであって，前記第２のサーバー装置は，前記ＵＲＬアドレスによって前記第２の端末装置からのアクセスが可能にされるように構成されている，ステップと，
　（ｆ）前記第２のサーバー装置が，前記第２の端末装置において入力された前記ユーザを識別するための個人識別情報を前記第２の端末装置から受信するステップと，
　（ｇ）前記第２のサーバー装置が，前記第２の端末装置において入力された前記個人識別情報を検索条件として前記個人認証データベースを検索することにより，前記第２の端末装置において入力された前記個人識別情報に対応する個人を特定する個人特定情報を取得するステップと，
　（ｈ）前記第２のサーバー装置が，前記個人特定情報を検索条件として前記個人医療情報データベースを検索することにより，前記個人特定情報に対応する個人医療情報を取得するステップと，
　（ｉ）前記第２のサーバー装置が，前記個人医療情報を前記第２の端末装置に送信するステップと
　をさらに包含する，方法。」
　
　
３．当審の拒絶の理由について
　
　当審において，平成２１年５月１１日付けで通知した拒絶の理由の概要は以下のとおりである。
　
「［理由Ａ］
　この出願の下記の請求項に係る発明は，その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
　　　　　記　　　（引用文献等については引用文献等一覧参照） 
　
引用文献等一覧
　
引用例１：特開２００２−３２４７８号公報
引用例２：特開２００１−２７３４１２号公報
引用例３：特開２００２−３３４１７５号公報
　
（以下略）」
　
　
４．引用例
　
（１）引用例１（特開２００２−３２４７８号公報）
　当審における拒絶の理由で引用した特開２００２−３２４７８号公報（以下，「「引用例１」という。）には，図面とともに，次の事項が記載されている。（下線は，当審で付加。）
（ア）「【０００１】
【発明の属する技術分野】本発明は，患者の診療情報を一括管理する診療情報管理装置に関する。」
　
（イ）「【０００７】本発明は，上記事情に鑑み，病院内若しくは病院間において複雑なシステムを構築することなく，病院間での情報の共有化，患者の過去の病歴を簡単に把握することの可能な診療情報管理装置を提供することを目的とする。」
　
（ウ）「【００１１】同図に示すように，
患者ａ，ｂ，ｃの自宅等に設置されている，パーソナルコンピュータ等の患者側端末ａ１，ｂ１，ｃ１と，診療情報管理装置２に設置されているホストコンピュータ３とが，インターネット等，外部に開放されている通信回線網４を介して接続されている。更に，このホストコンピュータ３が，閉鎖された専用通信回線５を介して，予め登録されている特定病院Ｌ，Ｍ，Ｎ，及び，特定処方箋薬局Ｘ，Ｙに各々設置されているパーソナルコンピュータ等の病院側端末Ｌ１，Ｍ１，Ｎ１，処方箋薬局側端末Ｘ１，Ｙ１に接続されている
【００１２】
ホストコンピュータ３の記憶手段３ａには，登録された患者の個人情報を備える患者情報データベース１１，登録された病院毎の情報を備える病院情報データベース１２
【００１３】
図３に示すように，患者情報データベース１１は，登録された患者ａ，ｂ，ｃの情報がディレクトリ構造で格納されている。
【００１４】
患者ディレクトリＤａには，診療情報管理装置２側で発行する患者ａのUSER IDやPASSWORD（図１８参照）等のように管理者側が患者を特定するのに必要な個人情報ファイル１１１と特定の病院間で保険証のコピーとして取り扱うことのできるメンバー登録情報ファイル１１２とが格納される
【００１５】
診察情報ディレクトリＤｈには，患者ａが予約し，或いは実際に診察を受けた病院の病院ディレクトリＤｌ，Ｄｍ，Ｄｎが作成され，この各病院ディレクトリＤｌ，Ｄｍ，Ｄｎの領域に，診療予約情報ディレクトリＤａｐ，診療結果／処方箋情報ディレクトリＤｍｅ，
【００１６】診療予約情報ディレクトリＤａｐには，患者ａが過去に予約した日付データ（日付１，日付２，日付３…）を記録する予約日付記録ファイル１１３が格納されており，又，
診療結果／処方箋情報ディレクトリＤｍｅには，実際に診療を受けたときの診療結果，処方箋の内容（カルテ１，カルテ２…）を記録したカルテファイル１１４が格納される。
【００１７】又，
図４に示すように，病院情報データベース１２には，登録されている特定病院Ｌ，Ｍ，Ｎの病院ディレクトリＤｌ，Ｄｍ，Ｄｎが作成されており，各病院ディレクトリＤｌ，Ｄｍ，Ｄｎの領域に，各病院Ｌ，Ｍ，Ｎが各々登録した病院の所在，診療科等，各病院Ｌ，Ｍ，Ｎの病院情報が登録される登録情報ファイル１１６ｌ，１１６ｍ，１１６ｎが作成される。
病院の所在地，電話番号，診療科，診療時間，最寄り駅から病院までの地図，及び１日の診療時間内での混雑状況の統計表等を示すデータ
【００１８】混雑状況の統計表を登録しておくことで，病院への来院時間を決定する際の参考とすることができる。尚，この場合，ある一定期間の平均値を登録するようにしても良く，
病院側から病院情報データベース１２への定期的なアクセスにより，混雑状況をほぼリアルタイムに更新するようにしても良い。
　
（エ）「【００２２】又，各病院Ｌ，Ｍ，Ｎに設置されている
病院側端末Ｌ１，Ｍ１，Ｎ１の記憶手段Ｌ２，Ｍ２，Ｎ２には，診療の予約状況を示す予約状況データベース１４が備えられている。
　
（オ）「【００２３】次に，図２の模式図を参照しながら，診療情報管理システムにおける手続きの流れについて概略的に説明する。尚，診療情報管理装置２のホストコンピュータ３の記憶手段３ａに設けられている病院情報データベース１２，処方箋薬局情報データベース１３には，各病院側，各処方箋薬局側が登録した病院情報，処方箋薬局情報が予め登録されている。
【００２４】先ず，
患者ａが病院を検索する場合
患者側端末ａ１から病院名，或いは診察を受けようとする診療科，所在地等の内の１つ或いは複数のキーワードを入力する
【００２５】
ホストコンピュータ３は，患者側端末ａ１から送信された病院検索要求信号を受信すると，病院情報データベース１２を検索し，キーワード等の病院検索要求に合致する病院があるかどうかを調べ，キーワード等でヒットした病院の一覧情報を，検索結果一覧情報として患者側端末ａ１へ送信する
【００２６】
患者ａは，モニタ等に表示された検索結果一覧を確認して，自宅から一番近い病院等，患者の希望に合致した病院を選択する。
【００２７】すると，ホストコンピュータ３では，病院情報データベース１２に格納されている病院Ｌの詳細情報を読込み，患者側端末ａ１に対し，病院Ｌの詳細情報を送信する（(4)）。
【００２８】患者ａは，患者側端末ａ１に表示された病院Ｌの詳細情報の内容を確認し，病院Ｌに対して診察予約を行いたい場合は，ホストコンピュータ３に対し，病院Ｌの予約状況データベースへの接続要求信号を送信する（(5)）。
【００２９】ホストコンピュータ３では，患者側端末ａ１からの接続要求信号に基づき，病院Ｌに設置されている病院側端末Ｌ１に対し，予約状況データベース４への接続及び予約状況情報取得の要求信号を送信する（(6)）。
【００３０】病院側端末Ｌ１では，ホストコンピュータ３からの要求信号を受けて，記憶手段Ｌ２内の予約状況データベース４に格納されている予約状況情報を読込み，予約状況情報をホストコンピュータ３へ送信する（(7)）。ホストコンピュータ３では，病院側端末Ｌ１から送られてきた予約状況情報と予約希望日時入力画面情報とを患者側端末ａ１へ送信する（(8)）。
【００３１】患者ａは，患者側端末ａ１に表示された予約状況を示す画像から，自分の希望する日時の予約状況を確認し，希望に即した日時が予約可能の場合は，患者側端末ａ１に表示されている予約希望日時入力画面に，希望する日時を入力し，ホストコンピュータ３へ予約希望日時情報として送信する（(9)）。
【００３２】ホストコンピュータ３では，患者側端末ａ１から送られてきた予約希望日時情報と病院側端末Ｌ１から送られてきた予約状況情報とを照合し，予約可能か否かを判断し，予約可能な場合は，病院側端末Ｌ１に対して予約希望日時情報を送信する（(10)）。
【００３３】病院側端末Ｌ１では，患者ａの予約を確認すると共に，予約状況データベースに患者ａの予約を登録し，ホストコンピュータ３に対して予約結果確認信号を送信する（(11)）。
【００３４】ホストコンピュータ３では，病院側端末Ｌ１からの予約結果確認信号を受けて，患者側端末ａ１に「予約完了」通知信号を送信し（(12)），患者ａの診療予約が終了する。」
　
（カ）「【００４５】ところで，ホストコンピュータ３に対するアクセス権は，患者と病院とシステム管理者との三者に有り，USER IDは，患者用USER ID，病院用USER ID，システム管理者用USER IDと各々区別して登録される。この中で，患者と病院との各データベース１１〜１４へのアクセス権は，表１に示す通りである。
【００４６】
【表１】（略）
ここで，自己の登録した情報に対し，◎：閲覧，編集，削除，登録可能，○：閲覧，追記，登録可能，△：閲覧可能，×：アクセス不可を示す。
【００４７】但し，患者ａが病院Ｌに対して診療予約を行い，患者ｃ，病院Ｎは，各々患者ａ，病院Ｌとは無関係とする。この場合，病院Ｌで診療を受けた患者の診療情報及び病院Ｌの予約状況データベースは，病院Ｌの責任において管理することになる。又，病院Ｌが病院Ｎへ患者ａを紹介する場合，患者ａのUSER IDを連絡することで，病院Ｎも患者ａの診療情報を閲覧可能となる。又，病院用USER IDは，病院毎に限らず，病院内の診療科毎に情報を区分して設定しても良い。」
　
（キ）「【００５１】先ず，
患者が病院の診療予約を行う手順について説明する。
（中略）
【００７３】ここで，病院検索データベースは，患者ａがキーワード入力により希望する病院を検索するメニュー，病院予約データベースは患者ａが診療を希望する病院を予め決めている場合に，当該病院の端末に直接アクセスして診療予約を行うメニュー，患者情報データベースはホストコンピュータ３の患者情報データベース１１にアクセスし，自己の過去の診察歴等，患者情報データベース１１に登録されている自己の情報を閲覧するメニューである。
（中略）
【００７５】そして，患者ａが患者側端末ａ１のモニタに表示されているメニューから，例えば病院検索データベースを選択すべく，この「病院検索データベース」の表示位置にポインタを移動させてＯＮすると，ホストコンピュータ３へ「病院検索データベース」への要求信号が送信される。尚，病院予約データベース，或いは患者情報データベースを選択した場合の流れについては，後述する。
【００７６】ホストコンピュータ３で，患者側端末ａ１から送信された「病院検索データベース」への要求信号を受信すると，プログラムは，ステップＳ１３からＳ１６へ進み，病院情報データベース１２に接続し，続くステップＳ１７で，
患者側端末ａ１へ「病院検索キーワード」入力画面情報を送信し，
【００７７】すると，患者側端末ａ１には，図２２に示すような，「病院検索キーワード」入力画面Ｍ５が表示される。この「病院検索キーワード」入力画面Ｍ５には，検索項目として，病院名検索，診療科目検索，所作位置検索の３項目を入力するウインドウ３５と，「実行」ボタン３６，「戻る」ボタン３７，「メインメニューへ」ボタン３８が表示される。
【００７８】そして，患者ａ１が，これらの入力項目の内，少なくとも１つ以上の項目を選択して，
検索のためのキーワードを入力した後，「実行」ボタン３６をＯＮすると，ホストコンピュータ３へ検索キーワード及び検索の要求信号が送信される
【００７９】そして，これを受信した
ホストコンピュータ３では，ステップＳ１９へ進み，受信した検索キーワードに基づき，病院情報データベース１２を検索し，
【００８０】そして，検索キーワードに合致する病院情報が登録されていないときは，ステップＳ１７へ戻り，患者側端末ａ１に対し，再度「病院検索キーワード」の入力画面情報を送信する。一方，
検索キーワードに合致する病院情報が登録されているときは，ステップＳ２１へ進み，患者側端末ａ１へ検索結果一覧情報を送信し，患者側端末ａ１からの表示要求信号の送信を待つ
【００８１】
患者側端末ａ１に検索結果一覧情報が送信されると，
（中略）
【００８５】
患者ａは，病院の一覧を参照して，診療を受けたい病院を特定し，特定した病院名にポインタを移動させて，ＯＮする。
【００８６】ホストコンピュータ３で，患者側端末ａ１から送信される特定病院の詳細情報の表示要求信号を受信すると，ステップＳ２３へ進み，病院情報データベース１２に蓄積されている特定病院の詳細情報を，患者側端末ａ１へ送信し，ステップＳ２４へ進み，患者側端末ａ１からの接続要求信号の送信を待つ。
【００８７】例えば，患者ａが病院Ｌを特定病院として指定した場合，ホストコンピュータ３から患者側端末ａ１に対して，病院Ｌの詳細情報が送信される。以下の説明では，患者ａが病院Ｌを特定し，この病院Ｌに対し診察予約を申し込む場合を例示して説明する。
【００８８】患者側端末ａ１が特定病院の詳細情報を受信すると，モニタ上には，「病院別詳細情報」表示画面Ｍ８が表示される。例えば，患者ａが病院Ｌの詳細情報の表示を要求した場合，図２５に示すように，「病院別詳細情報」表示画面Ｍ８には，病院Ｌの所在地，電話番号，診療科目，診察時間に加え，最寄り駅からの地図４６，及び，１日の診療時間内での混雑状況，或いは一定期間の平均的な混雑状況の統計を示すグラフ４７と，「予約」ボタン４８，「戻る」ボタン４９，「メインメニューへ」ボタン５０が表示される。
【００８９】そして，これを確認した患者ａが「予約」ボタン４８をＯＮすると，ホストコンピュータ３に対して，病院Ｌの予約状況データベース１４への接続要求信号が送信され，これを受信したホストコンピュータ３では，ステップＳ２７へ進む。
（中略）
【００９６】そして，ステップＳ２４或いはＳ２６からステップＳ２７へ進むと，病院Ｌに設置されている病院側端末Ｌ１の記憶手段Ｌ２に備えられている予約状況データベース１４に回線を接続する。次いで，ステップＳ２８へ進み，病院側端末Ｌ１の予約状況データベース１４から予約状況情報を受信し，ステップＳ２９で，患者側端末ａ１へ予約希望日時入力画面情報と共に，病院Ｌの予約状況情報を送信する。又，同時に，この予約状況情報をホストコンピュータ３内の記憶手段に一時格納しておく。
（中略）
【００９９】そして，患者ａが予約状況を示すウインドウ５５を参照して，予約希望日時（例えば，７月６日 13:00〜14:00）を予約希望日時入力ウインドウ５６に入力して，「送信」ボタン５７をＯＮすると，ホストコンピュータ３へ予約希望日時情報が送信され，これを受信したホストコンピュータ３では，ステップＳ３１へ進み，受信した予約希望日時と，一時的に記憶されている病院Ｌの予約状況情報とを照合する。そして，ステップＳ３２へ進み，予約希望日時は予約が可能かどうか判断し，予約が「満」のときは，ステップＳ３０へ戻り，患者側端末ａ１から送信される新たな予約希望日時情報の受信を待つ。
【０１００】一方，予約が「空」のときは，ステップＳ３３へ進み，病院Ｌの病院側端末Ｌ１へ予約希望日時情報を送信し，ステップＳ３４で，病院側端末Ｌ１から送信される予約結果確認信号の受信を待つ。
（中略）
【０１０２】ホストコンピュータ３で予約結果確認信号を受信すると，ステップＳ３５へ進み，病院側端末Ｌ１の予約状況データベース１４との接続を遮断する。次いで，ステップＳ３６へ進み，患者情報データベース１１内に患者ａの患者ディレクトリＤａが作成されているか否かを調べ，既に作成されている場合は，ステップＳ３８へジャンプし，又，患者ディレクトリＤａが作成されていない場合は，ステップＳ３７へ分岐する。
【０１０３】そして，ステップＳ３７で，予約状況データベース１４に患者ａの患者ディレクトリＤａを作成し，その領域に患者ａのUSER ID及びPASSWORDを登録する個人情報ファイル１１１と，患者ａのメンバー登録情報を登録するメンバー登録情報ファイル１１２と，病院情報ディレクトリＤｈを作成し，更に，病院情報ディレクトリＤｈの領域に，診療予約情報ディレクトリＤａｐ，診療結果／処方箋情報ディレクトリＤｍｅ，診療／処方箋費用情報ディレクトリＤｅｘを作成し（図３参照），ステップＳ３８へ進む。
【０１０４】ステップＳ３８では，患者情報データベース１１に作成されている患者ディレクトリＤａの診療予約情報ディレクトリＤａｐに格納されている予約日付記録ファイル１１３に，予約日時を登録する。
【０１０５】尚，患者情報データベース１１内に患者の患者ディレクトリが既に作成されている場合であっても，予約の度に各種の診療情報を登録する領域を患者ディレクトリの領域に作成するようにしても良い。
【０１０６】その後，ステップＳ３９へ進み，予約完了の旨の通知情報を患者側端末ａ１へ送信すると共に，患者側端末ａ１から送信される遮断要求信号に基づき，診療情報管理装置２のホストコンピュータ３と患者側端末ａ１とを接続する回線を遮断し，ルーチンを終了する。」
　
（ク）「【０１２０】次に，病院側端末Ｌから患者情報データベース１１にアクセスして，病院ディレクトリＤｌに作成されている診療結果／処方箋情報ディレクトリＤｍｅに，
診療結果，及び処方箋情報を入力する手順
【０１２１】病院Ｌの医師が患者ａの診察中，若しくは診察を終えると，
カルテ記入の代わりに，診療情報管理装置２のホストコンピュータ３へアクセスし，患者ａの診療結果／処方箋情報等を，インターネット等外部の通信回線網を介して，外部からアクセス可能な患者情報データベース１１に登録する。これにより，この診療結果/処方箋情報登録の記録が，言わば電子カルテとして機能する。
　
（ケ）「【０１２３】病院Ｌの病院側端末Ｌ１からホストコンピュータ３にアクセスすると，先ず，モニタ上に，図１８に示すような，「ログイン」画面Ｍ１が表示され，USER IDを入力するウインドウ２１に病院用USER IDを入力し，PASSWORDを入力するウインドウ２２に，担当医師のPASSWORDを入力するなど，予め登録されている病院用USER ID，及びPASSWORDを入力する。
【０１２４】すると，この病院用USER ID，及びPASSWORDがホストコンピュータ３に対し，接続要求信号として送信され，ホストコンピュータ３では，ステップＳ５１で，病院側端末Ｌ１から送信される接続要求信号に基づき，病院側端末Ｌ１とホストコンピュータ３の回線を接続し，「患者情報データベースメニュー」画面情報を送信し，ステップＳ５２へ進み，病院側端末Ｌ１と患者情報データベース１１との回線を接続する。
（中略）
【０１２７】そして，
病院側端末Ｌで「診療結果／処方箋登録」の項目を選択すると，ホストコンピュータ３に対して，「診療結果／処方箋登録」への接続要求信号が送信され，この信号を受信したホストコンピュータ３では，ステップＳ５４へ進み，登録対象となる患者の患者用USER IDの入力画面情報を送信し，ステップＳ５５へ進み，病院側端末Ｌ１から送信される患者用USER ID信号の受信を待つ。
【０１２９】この特定患者（患者ａ）の患者用USER ID信号を受信したホストコンピュータ３では，ステップＳ５６へ進み，
入力された特定患者（患者ａ）の患者用USER IDに基づき，患者情報データベース１１に作成されている各患者の患者ディレクトリＤａ内を検索し，
【０１３０】そして，登録されていない場合は，ルーチンを終了し，又，登録されている場合は，ステップＳ５８へ進み，
病院端末Ｌ１へ患者ａの「診察結果／処方箋情報登録」画面情報を送信し，
（中略）
【０１３２】一方，
ホストコンピュータ３から患者ａの「診察結果／処方箋情報登録」画面情報を受信した病院側端末Ｌ１のモニタには，「診察結果／処方箋情報登録」画面Ｍ２５が表示される。
【０１３３】そして，診察結果／処方箋情報を入力するウインドウ７１に，診察結果，処方箋情報を入力し，必要な場合は，内視鏡像等の電子画像をペーストして，「完了」ボタン７２をＯＮする。
【０１３４】すると，病院側端末Ｌ１からホストコンピュータ３へ登録要求信号が送信され，この登録要求信号を受信したホストコンピュータ３では，ステップＳ６０へ進み，予め，
患者情報データベース１１に作成されている患者ａの患者ディレクトリＤａ内の病院ディレクトリＤｌに作成されている診察結果／処方箋情報ディレクトリＤｍｅに，診療日データと共に診察結果及び処方箋情報を記憶した新たなカルテファイルを作成する。又，患者ａが再診の場合は，新たなカルテファイルを作成すること無く，既に作成されているカルテファイルに必要事項を追記するようにしても良い
　
　上記摘記事項（キ）【０１０３】の「ステップ３７で，予約状況データベース１４に患者ａの患者ディレクトリＤａを作成し…診療／処方箋費用情報ディレクトリＤｅｘを作成し（図３参照），ステップ３８へ進む。」の記載は，【図１１】Ｓ３７の「患者情報ＤＢ内の患者ａの領域内に，…」とあること，【図３】が「患者情報データベース」の説明であること等から，「予約状況データベース１４」は「患者情報データベース１１」の誤記である。
　
　そうすると，引用例１の上記摘記事項及び図面から，引用例１には，次の発明（以下，「引用発明」という。）が記載されていると認められる。
　
「患者端末ａ１，ｂ１，ｃ１と複数の病院側端末Ｌ１，Ｍ１，Ｎ１とホストコンピュータ３とを含むコンピュータシステムを用いて，個人医療情報検索サービスを提供する方法であって，
　前記患者端末ａ１，ｂ１，ｃ１と前記病院側端末Ｌ１，Ｍ１，Ｎ１と前記ホストコンピュータ３とは通信回線網４を介して互いに接続されており，前記ホストコンピュータ３には，各病院の所在，診療科，診療時間，最寄り駅から病院までの地図，１日の診療時間内での混雑状況の統計表等の病院情報が登録された病院情報データベース１２，患者の診療結果，USER IDやPASSWORDとを対応付けて格納した患者情報データベース１１が接続されており，
　前記方法は，
　前記ホストコンピュータ３が，キーワードを前記患者端末ａ１，ｂ１，ｃ１から受信するステップと，
　前記ホストコンピュータ３が，前記患者端末ａ１，ｂ１，ｃ１から受信した前記キーワードを検索条件として前記病院情報データベース１２を検索することにより，前記患者端末ａ１，ｂ１，ｃ１から受信したキーワードに対応する少なくとも１つの病院に関する情報を取得するステップと，
　前記ホストコンピュータ３が，前記少なくとも１つの病院に関する情報を前記患者端末ａ１，ｂ１，ｃ１に送信するステップと，
　前記ホストコンピュータ３が，前記少なくとも１つの病院のうち前記患者によって選択された病院を特定したことを前記患者端末ａ１，ｂ１，ｃ１から受信するステップと，
　前記ホストコンピュータ３が前記病院側端末Ｌ１，Ｍ１，Ｎ１において入力された前記患者のUSER IDを検索条件として前記患者情報データベース１１を検索することにより，患者のUSER IDが登録されているか否かを調べ，登録されている場合は，診療結果／処方箋情報等を取得するステップと，
　前記ホストコンピュータ３が，前記診療結果／処方箋情報等を前記病院側端末Ｌ１，Ｍ１，Ｎ１に送信するステップと
　をさらに包含する，方法。」
　
（２）引用例２（特開２００１−２７３４１２号公報）
　当審における拒絶の理由で引用した特開２００１−２７３４１２号公報（以下，「引用例２」という。）には，図面とともに，次の事項が記載されている。
（コ）「【００７４】〔Ｃ−８−１．平時病院紹介〕（図２３〜図２６）
「平時病院紹介」メニューが選択されたときは図２４に示す病院等検索画面９１を表示する（ステップ２）。この画面９１では，エリア設定欄９１ａにリスト表示されるエリアの中から当該会員の住所地又はその周辺を含むエリアを選択すると共に，診療科目設定欄９１ｂにリスト表示される科目の中から受診すべき診療科目を設定する。会員自身も受診科目を判別できない場合は，「症状からの検索」欄９１ｃに患部や症状等の検索ワードを幾つか入力して「検索」ボタン９１ｄを選択すると，その検索ワードに対応する診療科目が医療データテーブルから検索されて該当診療科目表示枠９１ｅに表示される。該当診療科目表示枠９１ｅに複数の診療科目が表示されたときは，オペレーターはその中の１つを選択する。」　
　
　
５．対比
　
　引用発明の「患者端末ａ１，ｂ１，ｃ１」，「病院側端末Ｌ１，Ｍ１，Ｎ１」，「ホストコンピュータ３」，「通信回線網４」，「患者の診療結果，USER IDやPASSWORDとを対応付けて格納した患者情報データベース１１」，「前記ホストコンピュータ３が，前記少なくとも１つの病院に関する情報を前記患者端末ａ１，ｂ１，ｃ１に送信するステップ」，「前記ホストコンピュータ３が，前記少なくとも１つの病院のうち前記患者によって選択された病院を特定したことを前記患者端末ａ１，ｂ１，ｃ１から受信するステップ」は，それぞれ，本件発明の「第１の端末装置」，「第２の端末装置」，「第１のサーバー」，「ネットワーク」，「各個人を識別するためにバイナリデータで表現された個人識別情報と各個人を特定するための個人特定情報とを対応づけて格納した個人認証データベース」と「各個人識別情報と各個人医療情報とを対応づけて格納した個人医療情報データベース」，「前記第１のサーバー装置が，前記少なくとも１つの医療機関に関する情報を前記第１の端末装置に送信するステップ」，「前記第１のサーバー装置が，前記少なくとも１つの医療機関のうち前記ユーザによって選択された医療機関を特定する医療機関特定情報を前記第１の端末装置から受信するステップ」に相当する。
　
　引用発明の「各病院の所在，診療科，診療時間，最寄り駅から病院までの地図，１日の診療時間内での混雑状況の統計表等の病院情報が登録された病院情報データベース１２」と本件発明の「各医療機関に関する情報と各医療機関が診療可能な症状を示す情報とを対応づけて格納した医療機関データベース」は，後述する各［相違点］で相違するものの，「各医療機関に関する情報を格納した医療機関のデータベース」で共通する。
　
　引用発明の「前記ホストコンピュータ３が，キーワードを前記患者端末ａ１，ｂ１，ｃ１から受信するステップ」と，本件発明の「前記第１のサーバー装置が，ユーザの症状を示す症状情報を前記第１の端末装置から受信するステップ」は，後述する各［相違点］で相違するものの，「前記第１のサーバー装置が，検索キーを前記第１の端末装置から受信するステップ」で共通する。
　
　引用発明の「前記患者端末ａ１，ｂ１，ｃ１から受信した前記キーワードを検索条件として前記病院情報データベース１２を検索することにより，前記患者端末ａ１，ｂ１，ｃ１から受信したキーワードに対応する少なくとも１つの病院に関する情報を取得するステップ」と，本件発明の「前記第１のサーバー装置が，前記第１の端末装置から受信した前記症状情報を検索条件として前記医療機関データベースを検索することにより，前記第１の端末装置から受信した前記症状情報に対応する少なくとも１つの医療機関に関する情報を取得するステップ」は，後述する各［相違点］で相違するものの，「前記第１のサーバー装置が，前記第１の端末装置から受信した検索キーを検索条件として前記医療機関のデータベースを検索することにより，前記第１の端末装置から受信した前記検索キーに対応する少なくとも１つの医療機関に関する情報を取得するステップ」で共通する。
　
　引用発明の「前記ホストコンピュータ３が前記病院側端末Ｌ１，Ｍ１，Ｎ１において入力された前記患者のUSER IDを検索条件として前記患者情報データベース１１を検索することにより，患者のUSER IDが登録されているか否かを調べ，登録されている場合は，診療結果／処方箋情報等を取得するステップ」と，本件発明の「前記第２のサーバー装置が，前記第２の端末装置において入力された前記個人識別情報を検索条件として前記個人認証データベースを検索することにより，前記第２の端末装置において入力された前記個人識別情報に対応する個人を特定する個人特定情報を取得するステップ，前記第２のサーバー装置が，前記個人特定情報を検索条件として前記個人医療情報データベースを検索することにより，前記個人特定情報に対応する個人医療情報を取得するステップ」は，後述する各［相違点］で相違するものの，「前記第２の端末装置において入力された前記個人識別情報を検索条件として前記個人医療情報データベースを検索することにより，個人識別情報に対応する個人を特定し，個人医療情報を取得するステップ」で共通する。
　
　引用発明の「前記ホストコンピュータ３が，前記診療結果／処方箋情報等を前記病院側端末Ｌ１，Ｍ１，Ｎ１に送信するステップ」と，本件発明の「前記第２のサーバー装置が，前記個人医療情報を前記第２の端末装置に送信するステップ」は，後述する各［相違点］で相違するものの，「前記個人医療情報を前記第２の端末装置に送信するステップ」で共通する。
　
　そうすると，本件発明と引用発明とは，
　
「第１の端末装置と複数の第２の端末装置と第１のサーバー装置とを含むコンピュータシステムを用いて，個人医療情報検索サービスを提供する方法であって，
　前記第１の端末装置と前記第２の端末装置と前記第１のサーバー装置とはネットワークを介して互いに接続されており，前記第１のサーバー装置には，各医療機関に関する情報を格納した医療機関のデータベースが接続されており，
　各個人を識別するためにバイナリデータで表現された個人識別情報と各個人を特定するための個人特定情報とを対応づけて格納した個人認証データベースと，各個人識別情報と各個人医療情報とを対応づけて格納した個人医療情報データベースとが接続されており，
　前記方法は，
　前記第１のサーバー装置が，検索キーを前記第１の端末装置から受信するステップと，
　前記第１のサーバー装置が，前記第１の端末装置から受信した検索キーを検索条件として前記医療機関のデータベースを検索することにより，前記第１の端末装置から受信した前記検索キーに対応する少なくとも１つの医療機関に関する情報を取得するステップと，
　前記第１のサーバー装置が，前記少なくとも１つの医療機関に関する情報を前記第１の端末装置に送信するステップと，
　前記第１のサーバー装置が，前記少なくとも１つの医療機関のうち前記ユーザによって選択された医療機関を特定する医療機関特定情報を前記第１の端末装置から受信するステップと
　を包含し，
　前記方法は，
　前記第２の端末装置において入力された前記個人識別情報を検索条件として前記個人医療情報データベースを検索することにより，個人識別情報に対応する個人を特定し，個人医療情報を取得するステップと，
　前記個人医療情報を前記第２の端末装置に送信するステップと
　をさらに包含する，方法。」
　
で一致し，次の点で相違する。
　
［相違点１］
　本件発明では，医療機関のデータベースが「各医療機関が診療可能の症状を示す情報」と各医療機関に関する情報が対応付けられて格納されており，検索キーとしてユーザの症状を用いるのに対し，引用発明では，医療機関のデータベースが「各機関が診療可能な症状を示す情報」を格納しておらず，検索キーとしてキーワードを用いている点。
　
［相違点２］
　本件発明では，コンピュータシステムが第２のサーバー装置を含み，第１のサーバー装置には「医療機関データベース」が接続され，第２のサーバー装置には，「個人認証データベース」と「個人医療情報データベース」が接続されており，第２のサーバー装置が，個人識別情報を第２の端末装置から受信し，個人識別情報を検索条件として個人認証データベースを検索することにより個人特定情報を取得し，個人特定情報を検索条件として個人医療情報を取得し，個人医療情報を第２の端末装置に送信するのに対し，引用発明は，コンピュータシステムが第２のサーバー装置を含まず，ホストコンピュータ３には「医療機関データベース」，「個人認証データベース」と「個人医療情報データベース」が接続され，ホストコンピュータ３が，病院側端末から送られてきた患者のUSER IDに基づいて検索した患者の診療結果を病院側端末に送信する点。
　
［相違点３］
　本件発明では，「前記第１のサーバー装置が，前記医療機関特定情報を前記第１の端末装置から受信したことに応答して，前記複数の第２の端末装置のうち，前記医療機関特定情報によって特定された医療機関に設置されている第２の端末装置に，前記第２のサーバー装置へのアクセスを可能にするアクセス情報として前記第２のサーバー装置のＵＲＬアドレスを送信するステップであって，前記第２のサーバー装置は，前記ＵＲＬアドレスによって前記第２の端末装置からのアクセスが可能にされるように構成されている」のに対し，引用発明では，そのような構成にはなっていない点。
　
　
６．当審の判断
　
［相違点１］について
　引用例２の上記摘記事項（コ）には，患部や症状等の検索ワードを用いる「症状からの検索」による病院検索に関する技術的思想が開示されている。
　そうすると，引用例２に記載された当該技術的思想を引用発明に適用して，医療機関を検索するための検索キーをキーワードに代えて診療が可能な症状とすること，そして，検索に用いられるデータベースに医療機関に関する情報と診療が可能な症状を対応付けて格納することは，当業者が容易になし得たものであるので，引用発明において，医療機関のデータベースが各医療機関が診療可能の症状を示す情報と各医療機関に関する情報が対応付けられて格納されており，検索キーとしてユーザの症状を用いるとすることは，当業者が容易に推考し得た事項である。
　したがって，相違点１に係る本件発明の構成は，引用発明及び引用例２に記載された事項に基づいて当業者が容易に想到し得たものである。
　
［相違点２］について
　本件発明は，２つのサーバー装置を用いることにより，「医療機関データベース」，「個人認証データベース」及び「個人医療情報データベース」を管理するものであり，引用発明は，１つのホストコンピュータでこれらの３つデータベースを管理するものである。
　しかしながら，管理する目的，業務の内容は，引用発明と本件発明で異なるものではないことから，３つのデータベースを１つコンピュータで管理する構成とするか，２つのサーバー装置で管理する構成とするかは，当業者が適宜選択し得たものである。
　さらに，引用例１の上記摘記事項（ウ），（ケ），【図３】，【図２９】及び【図３０】から，患者情報データベース１１には，患者の氏名が，患者用USER ID，診察結果と関連づけられていることは明らかであるから，患者のUSER IDが登録されているか調べ，登録されている場合に，この患者のUSER IDにより氏名等の個人特定情報を取得し，個人特定情報を用いて個人医療情報を取得する構成とすることは，当業者が容易になし得た事項である。
　そうすると，引用発明において，３つのデータベースを１つのホストコンピュータで管理する構成に代えて，業務内容に応じて第１のサーバー装置及び第２のサーバー装置に分けて管理する構成とすること，第２のサーバー装置が，個人識別情報を第２の端末装置から受信し，個人識別情報を検索条件として個人認証データベースを検索することにより個人特定情報を取得し，個人特定情報を検索条件として個人医療情報を取得し，個人医療情報を第２の端末装置に送信することは，当業者が容易になし得た事項である。
　したがって，相違点２に係る本件発明の構成は，引用発明に基づいて当業者が容易に想到し得たものである。
　
［相違点３］について
　一方の者により許可された情報を他方の者に閲覧させるために，仲介する装置を介して情報の所在情報であるＵＲＬアドレスを他方の者に送ることは，例えば，特開２００３−１８７０２１号公報（【００３３】等の記載参照），特開２００３−２０８５５２号公報（【０００８】等の記載参照），特開２００３−１１６７９６号公報（【００２８】）にあるように周知技術であるので，引用発明において，第１のサーバー装置が，医療機関特定情報を第１の端末装置から受信したことに応答して，複数の第２の端末装置のうち，医療機関特定情報によって特定された医療機関に設置されている第２の端末装置に，第２のサーバー装置へのアクセスを可能にするアクセス情報として第２のサーバー装置のＵＲＬアドレスを送信するステップであって，第２のサーバー装置は，前記ＵＲＬアドレスによって第２の端末装置からのアクセスが可能にされるようにすることは，当業者が容易になし得た事項である。
　したがって，相違点３に係る本件補正発明の構成は，引用発明及び周知技術に基づいて当業者が容易に想到し得たものである。
　
　審判請求人は，平成２１年７月１３日付け意見書において，本件発明の特徴点である［相違点２］及び［相違点３］は，引用例１に記載された発明及び周知技術に基づいて当業者が容易に想到し得たものではない旨主張している。
　しかしながら，審判請求人が主張した特徴点は，上記［相違点２］について及び［相違点３］についてで検討したとおり，引用発明及び周知技術に基づいて当業者が容易に想到し得たものである。
　よって，当該特徴点が引用発明等から容易に想到し得たものはない旨の審判請求人の上記主張は採用できない。
　
　以上より，本件発明の構成は，引用発明，引用例２に記載された事項及び周知技術に基づき，当業者が容易に想到し得たものである。
　そして，本件発明の作用効果も，引用例１〜２から当業者が予測できる範囲のものである。
　ゆえに，本件発明は，引用発明，引用例２に記載された事項及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
　
７．むすび
　
　以上のとおり，本件発明は，引用発明，引用例２に記載された事項及び周知技術に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条２項の規定により特許を受けることができない。
　
　よって，結論のとおり審決する。