【事件の表示】
　特願２００２−５４７０６６「データ検証支援サーバー」拒絶査定不服審判事件〔平成１４年　６月　６日国際公開、ＷＯ０２／４４９７３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
第１　手続の経緯  
　
　本願は、２００１年１１月３０日（優先権主張２０００年１２月１日，日本国）を国際出願日とする出願であって、  
　平成１８年１０月２３日付けで拒絶査定がなされ、これに対し、平成１９年２月５日に拒絶査定不服審判の請求がなされるとともに、平成１９年２月５日付けで手続補正がなされたものである。  
　
　
　
　
第２　平成１９年２月５日付けの手続補正についての補正却下の決定  
　
〔結論〕  
　
　平成１９年２月５日付けの手続補正を却下する。  
　
〔理由〕
　
１．補正内容  
　
　平成１９年２月５日付けの手続補正（以下、「本件補正」という。）は、特許請求の範囲の請求項１乃至２２の補正を含むものであって、  
　本件補正前の特許請求の範囲の請求項１，１４，１７，２０，２２（以下、「補正請求項」という。）に、
　
「更に以降の上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態のうち、少なくとも四つのいずれかの状態を状態フラグに登録」、
　すなわち、
「上記実施者端末から該調査票を受信した状態」（以下、「状態Ａ」という。）、
「検証者端末に該調査票を送信した状態」（以下、「状態Ｂ」という。）、「該検証者端末から再調査依頼要求情報を受信した状態」（以下、「状態Ｃ」という。）、
「該実施者端末に該再調査を送信した状態」（以下、「状態Ｄ」という。）、
「該実施者端末から該再調査票を受信した状態」（以下、「状態Ｅ」という。）、
「該検証者端末から調査完了を受信した状態」（以下、「状態Ｆ」という。）のうち、
少なくとも四つのいずれかの状態を状態フラグに登録、
　
　することを追加する補正を含むものである。  
　
　
　
 ２．本件補正に対する判断  
　
（１）
　本出願に係る国際出願日における明細書又は図面（以下、「本出願当初明細書等」という、）の第９頁１３行から第１５頁第５行、すなわち、以下の（ａ）乃至（ｇ）という一連の記載（下線は当審にて付加）がある。
　
（ａ）
「症例の登録が終了すると、すなわち、担当医師によって患者情報の入力が完了すると、調査票管理システム１００は、症例に応じた調査票に関する情報が調査票管理情報で管理し、該調査票の医師側ステータスに「未送信」及び製薬メーカー側ステータスに「（空欄）」を設定する（図３参照）。」
　
（ｂ）
「
担当医師は、医師端末３０から症例情報の入力後、症例毎に、調査票管理システム１００によって提供される調査票入力画面から情報を入力及び更新し、その調査票を製薬メーカー担当者へ送信
　更に、上記操作手順２５において、医師端末３０から入力された調査票の情報に基づいて、依頼した医薬品に関して、有害事象や妊娠症例等の緊急に対応が必要となる緊急事象の発生等を示す情報が含まれていた場合、調査票管理システム１００は緊急事象発生等を示すメールを生成し、担当医師から製薬メーカー担当者（例えば、安全性担当者）へ送信する。
　調査票管理システム１００が自動的に行なう緊急事象発生等を示すメールの発信によって、担当医師は、個別に緊急事象が発生した症例を製薬メーカー担当者に通知する手間を省くことができる。また、製薬メーカー担当者は、担当医師が調査票を入力した時点で該メールを製薬メーカー端末４０で受信することができるため、緊急事象発生を示す報告等を迅速に対応することができる。」
　
（ｃ）
「製薬メーカー担当者は、上記操作手順２２又は２３によって、製薬メーカー端末４０から担当医師へ調査票の入力依頼又は催促を行なった後、調査票管理情報に基づいて、
調査票管理システム１００が提供する契約施設情報画面を参照し、ステータスが「新着」と表示されている調査票を選択し、その調査票の情報を確認する
　操作手順２６において、製薬メーカー端末４０が調査票を選択すると、調査票管理システム１００は、選択された調査票の情報に論理矛盾があるか否かを検証する論理チェックを実行し、実行結果を含む調査票を製薬メーカー端末４０に表示させる。製薬メーカー担当者は、表示された論理チェックの実行結果を含む調査票に基づいて、担当医師による再調査が必要となる項目を設定する。調査票管理システム１００による論理チェックの実行結果及び製薬メーカー端末４０によって設定された再調査を必要とする項目に関する情報は、再調査情報として再調査依頼情報ＤＢ１１４に格納される。また、設定した項目のうち、製薬メーカー担当者によって依頼内容が入力されている場合、該依頼内容が再調査依頼内容として再調査依頼情報ＤＢ１１４に格納される。」
　
（ｄ）
「一方、
担当医師への再調査の依頼を必要としない場合、該調査票を完了する
　
（ｅ）
「
製薬メーカー担当者は、再調査の依頼を担当医師へ行なう
　製薬メーカー担当者は、再調査依頼後、契約施設情報画面を参照し、調査票ステータスが「依頼中」のままである場合、再調査の催促を担当医師へ行なう（操作手順２８）。調査票管理システム１００は、製薬メーカー担当者による上記操作手順２８によって、所定の再調査を催促するメールを製薬メーカー端末４０から担当医師へ送信する。」
　
（ｆ）
「
担当医師が、医師端末３０にて製薬メーカー担当者からの再調査を依頼するメール又は再調査を催促するメールを受信後、再調査対象となった調査票の情報を修正する
　担当医師は、医師端末３０から修正した調査票情報を製薬メーカー担当者へ送信する（操作手順２９）。調査票管理システム１００は、担当医師による上記操作手順２９によって、所定の再調査を行なったことを示すメールを製薬メーカー担当者へ発信する。」
　
（ｇ）
「
製薬メーカー担当者は、製薬メーカー端末４０にて所定の再調査を行なったことを示すメールを担当医師から受信する
　操作手順３１において、製薬メーカー担当者が調査票を選択すると、調査票管理システム１００は、上記操作手順２６と同様に、選択された調査票の情報に論理矛盾があるか否かを検証する論理チェックを実行し、実行結果を含む調査票情報を製薬メーカー端末４０に表示させる。製薬メーカー担当者は、表示された論理チェックの実行結果を含む調査票に基づいて、担当医師による再調査が必要となる項目を設定し、再度、操作手順２７において、担当医師へ再調査の依頼を行なう。」
　
　
　なお、本出願当初明細書等の第４頁第４乃至５行の
「上記実施者は、例えば、医師である。
　上記検証者は、例えば、制約メーカー担当者等である。」
　という記載から、
　上記（ａ）乃至（ｇ）に記載された「製薬メーカー端末」及び「医師端末」は、
　補正請求項の「検証者端末」及び「実施者端末」に対応することは明らかである。
　
　
（２）
　以上の本出願当初明細書等の記載によれば、本出願当初明細書等には以下の事項が開示されていると認められる。
　
　上記（ｂ）の「担当医師は、医師端末３０から症例情報の入力後、症例毎に、調査票管理システム１００によって提供される調査票入力画面から情報を入力及び更新し、その調査票を製薬メーカー担当者へ送信」するという記載から、
　補正請求項の「検証者端末に該調査票を送信した状態」（状態Ｂ）が開示されているといえる。
　
　上記（ｃ）の「調査票管理システム１００が提供する契約施設情報画面を参照し、ステータスが「新着」と表示されている調査票を選択し、その調査票の情報を確認する」という記載から、
　補正請求項の「上記実施者端末から該調査票を受信した状態」（状態Ａ）が開示されているといえる。
　
　上記（ｄ）の「担当医師への再調査の依頼を必要としない場合、該調査票を完了する」という記載から、
　補正請求項の「該検証者端末から調査完了を受信した状態」（状態Ｃ）が開示されているといえる。
　
　上記（ｅ）の「製薬メーカー担当者は、再調査の依頼を担当医師へ行なう」という記載から、
　補正請求項の「該実施者端末に該再調査を送信した状態」（状態Ｄ）が開示されているといえる。　
　
　上記（ｆ）の「担当医師が、医師端末３０にて製薬メーカー担当者からの再調査を依頼するメール又は再調査を催促するメールを受信後、再調査対象となった調査票の情報を修正する」という記載から、
　補正請求項の「該検証者端末から再調査依頼要求情報を受信した状態」（状態Ｅ）が開示されているといえる。
　
　上記（ｇ）の「製薬メーカー担当者は、製薬メーカー端末４０にて所定の再調査を行なったことを示すメールを担当医師から受信する」という記載から、
　補正請求項の「該実施者端末から該再調査票を受信した状態」（状態Ｆ）が開示されているといえる。
　
　
（３）
　また、上記（ａ）乃至（ｇ）の記載、及び【図３】に図示された表（特に、「状態Ａ」乃至「状態Ｆ」に対応する、操作手順Ｎｏ．２５，２６，２７，２８，３０，３１を参照）によれば、「状態Ａ」乃至「状態Ｆ」を、
　「医師のステータス」と「製薬メーカーのステータス」の２種類のステータスを用いて表現すること、
　又は、「医師のステータス」が有する「送信済」、「メーカー受領」、「新着」、「未送信」という４通りの状態と、「製薬メーカーのステータス」が有する「新着」、「確認中」、「依頼中」、「完了」の４通りの状態の合計７種類（なお、「新着」は重複しているので、８種類より１つ少なくなる。）のステータスを用いて表現すること、
　が開示されている。
　
　
（４）
　したがって、本出願当初明細書等の第９頁１３行から第１５頁第５行の記載、すなわち（ａ）乃至（ｇ）という一連の記載、及び【図３】に図示された表からは、
　「上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態」という『六つの状態』を、
　「医師のステータス」と「製薬メーカーのステータス」の２種類のステータスを用いて表現すること、
　又は、「医師のステータス」と「製薬メーカーのステータス」で用いられる、「送信済」、「メーカー受領」、「新着」、「未送信」、「確認中」、「依頼中」、「完了」の７種類のステータスを用いて表現すること、
　は開示されているとはいえるものの、
　「上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態」のうち『少なくとも四つのいずれかの状態』を『状態フラグ』に登録することが開示されているとはいえない。
　
　
（５）
　本出願当初明細書等における他の箇所の記載を精査しても、上記「上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態」のうち『少なくとも四つのいずれかの状態』を『状態フラグ』に登録することが開示されているとは認められない。
　
　
（６）　
　以上のことから、補正請求項の「更に以降の上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態のうち、少なくとも四つのいずれかの状態を状態フラグに登録」することを追加する補正は、
　本出願当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入したものである。
　
　
　
３．むすび  
 　  
　したがって、本件補正は、特許法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。  
 　  
 　  
 　  
 　  
第３　本願発明について  
　
１．本願発明の認定  
　
　本件補正は上記のとおり却下されたので、本願の請求項２２に係る発明（以下、「本願発明」という。）は、平成１８年６月２８日付けの手続補正書の特許請求の範囲の請求項２２に記載されたとおりのものと認められるところ、本願発明は、次のとおりのものである。  
　
「　　【請求項２２】
製品の実施による影響を調べる調査票の各項目に入力されたデータの検証を支援するデータ検証支援方法において、
　実施者の実施者端末から送信された調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶することによって管理する調査票管理手順と、
　調査票を検証する検証者の検証者端末から受信した再調査を依頼する再調査依頼要求に基づいて、再調査依頼要求で指定される該調査票を送信した実施者へ再調査依頼を通知する再調査情報管理手順と、
　調査票を検証する検証者の検証者端末からの指示に応じて、上記実施者端末から受信した上記調査票の各入力項目に入力されたデータが論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック手順と、
　上記検証者端末から調査票の検証完了を受信すると、上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶することによって保管する調査票保管手順とを有するようにしたデータ検証支援方法。」
　
　
　
２．引用例の認定  
　
　原査定の拒絶の理由に引用文献１として引用された、村上　憲之　他，医薬品製造業における計測・制御・情報システム，日立評論，日立評論社，１９９６年　４月　１日，第７８巻　第４号，ｐ．６５−７０（以下、「引用例」という）には、図面とともに以下の技術事項が記載されている。 
　
（ア）
「臨床開発情報システム〔（ａ），（ｂ）〕と市販後調査システム〔（ｂ），（ｃ）〕」の図には、「市販後調査業務サーバ」、「文書管理サーバ」、及び「デスクトップパソコン」を含む「市販後調査システム」が図示されている。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（第６５頁）
　
（イ）  
「新薬開発業務および市販後調査業務の推進にあたっては，ＧＣＰ（Ｇｏｏｄ　Ｃｌｉｎｉｃａｌ　Ｐｒａｃｔｉｃｅ：臨床試験基準），ＧＰＭＳＰ（Ｇｏｏｄ　Ｐｏｓｔ−Ｍａｒｋｅｔｉｎｇ　Ｓｕｒｖｅｉｌｌａｎｃｅ　Ｐｒａｃｔｉｃｅ：市販後調査基準）のガイドラインなどに厳格に対応し，かつ期間を短縮するために，適切な対応が求められている。
　また，医薬品開発でもグローバル化が進み，医薬品の世界同時開発，同時申請という大きな目標に向けて，ＩＣＨ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｈａｒｍｏｎｉｚａｔｉｏｎ）で国際的な立場から効率的，かつ質の高い医薬品開発の実現について検討された。
　このような状況の下では，今後，コンピュータを利用することによって業務を大幅に改善する必要があると考える。そこで日立製作所は，従来取り組み培ってきたノウハウをベースに業務の効率と法規制対応をねらった臨床開発・市販後調査のための情報システムを構築した。この情報システムにより，臨床開発では業務の効率化，質の向上，査察への対応を図ることができ，市販後調査では副作用案件の管理を一元化することができる。」 
　　　　　　　　　　　　　（第６５頁左欄第１行から同頁右欄第１０行）
　
（ウ）
「３　臨床開発情報システムの特徴
３．１　臨床開発情報システムの概要
　臨床開発情報システムは，大きく１１個のサブシステムで構成される（図１参照）。」
　　　　　　　　　　　　　　　　　　（第６７頁左欄第１４乃至１７行）
　
（エ）  
「（９）症例管理サブシステム
　症例データの項目定義とＣＲＦ（Ｃｌｉｎｉｃａｌ　Ｒｅｐｏｒｔ　Ｆｉｌｅ：症例カード）によく似た入力画面の作成から症例データの入力・更新までを容易に実現し，その更新履歴を管理することができる。また，症例データの項目を選択し，症例一覧表を容易に作成することができる。」 
　　　　　　　　　　　　　　　　　　　（第６８頁左欄第９乃至１４行）
　
（オ）  
「４　市販後調査情報システムの特徴
　臨床開発試験は，健常人に対して安全性（副作用，血中濃度，薬物動態）をみるフェイズＩ，アーリー（ｅａｒｌｙ）とレイト（ｌａｔｅ）があり，至適用法・用量の検討（ｄｏｓｅ　ｆｉｎｄｉｎｇ）を行うフェイズＩＩ，ダブルブラインドで実施するフェイズＩＩＩがある。概して，上市前の試験（Ｔｒｉａｌ）であり，安全性を確保しながら，有効性を見いだすことに主眼が置かれている。」
　　　　　　　　　　　　　　　　　　（第６８頁右欄第１３乃至２０行）
　
（カ）
「市販後調査はフェイズＩＶとして位置づけられ，上市後に特に安全性についてさらに精度を高めて行う調査（Ｓｕｒｖｅｉｌｌａｎｃｅ）である。
　試験と調査は業務的に違うところはあるが，重複する部分も非常に多いと考える。システム的には臨床開発試験の延長線上でとらえたほうが，創薬プロセスというフレームワークの中での連携および展開が図りやすい。
　ここでは，市販後調査特有の業務であるＡＤＲ（副作用自発報告）のワークフローを利用したシステム化について述べる。
　ＡＤＲの業務フローの例を図４に示す。
　フロー定義をすることにより，副作用が発生してから厚生省に報告するまでの一連の業務が，連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など，それぞれの役割を明確にして業務を進めなければならないＡＤＲのような業務には最適であると考える。日立製品では，ワークフローシステム“Ｆｌｏｗｍａｔｅ”（フローメイト）が適用できる。」 
　　　　　　　　　　（第６８頁右欄第２１行から第６９頁左欄第１６行）
　
　
　以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。 
　
（ａ）
　引用例の上記（イ）の
「新薬開発業務および市販後調査業務の推進にあたっては，ＧＣＰ（Ｇｏｏｄ　Ｃｌｉｎｉｃａｌ　Ｐｒａｃｔｉｃｅ：臨床試験基準），ＧＰＭＳＰ（Ｇｏｏｄ　Ｐｏｓｔ−Ｍａｒｋｅｔｉｎｇ　Ｓｕｒｖｅｉｌｌａｎｃｅ　Ｐｒａｃｔｉｃｅ：市販後調査基準）のガイドラインなどに厳格に対応し，かつ期間を短縮するために，適切な対応が求められている。
　　　　　　　　　　　・・・（中略）・・・
 このような状況の下では，今後，コンピュータを利用することによって業務を大幅に改善する必要があると考える。そこで日立製作所は，従来取り組み培ってきたノウハウをベースに業務の効率と法規制対応をねらった臨床開発・市販後調査のための情報システムを構築した。この情報システムにより，臨床開発では業務の効率化，質の向上，査察への対応を図ることができ，市販後調査では副作用案件の管理を一元化することができる。」
 という記載、
（当該記載から、「臨床開発・市販後調査のための情報システム」が、「新薬の市販による副作用を調べる」ことを「支援」するためのものであることは明らかである。）
　
　引用例の上記（カ）の
「市販後調査はフェイズＩＶとして位置づけられ，上市後に特に安全性についてさらに精度を高めて行う調査（Ｓｕｒｖｅｉｌｌａｎｃｅ）である。
　　　　　　　　　　　・・・（中略）・・・
　ここでは，市販後調査特有の業務であるＡＤＲ（副作用自発報告）のワークフローを利用したシステム化について述べる。
　ＡＤＲの業務フローの例を図４に示す。
　フロー定義をすることにより，副作用が発生してから厚生省に報告するまでの一連の業務が，連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など，それぞれの役割を明確にして業務を進めなければならないＡＤＲのような業務には最適であると考える。日立製品では，ワークフローシステム“Ｆｌｏｗｍａｔｅ”（フローメイト）が適用できる。」
　という記載、
（なお、「連絡票」の具体的内容については明記されていないものの、新薬に関する市販後調査では、入力すべきデータが複数あることは世間常識であることを鑑みれば、「連絡票の各項目に入力されたデータの評価」を行っていることは明らかである。）　
　
　引用例の上記（カ）において引用している「図４　ＡＤＲの業務フロー図」には、連絡票を用いて「製品別一次評価（ＡＤＲ）」や「二次評価（ＡＤＲ）」等を行うフロー（方法）が図示されていることから、
（なお、ワークフローシステムで用いられる「連絡票」がコンピュータ間で送受信される電子データであることは明らかである。）
　
　引用例には、「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法」が開示されていると認められる。 　
　
　
（ｂ）　
　上記（ａ）の「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法」という開示、
　
　引用例の上記（カ）の
「市販後調査はフェイズＩＶとして位置づけられ，上市後に特に安全性についてさらに精度を高めて行う調査（Ｓｕｒｖｅｉｌｌａｎｃｅ）である。
　　　　　　　　　　　・・・（中略）・・・
　ここでは，市販後調査特有の業務であるＡＤＲ（副作用自発報告）のワークフローを利用したシステム化について述べる。
　ＡＤＲの業務フローの例を図４に示す。
　フロー定義をすることにより，副作用が発生してから厚生省に報告するまでの一連の業務が，連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など，それぞれの役割を明確にして業務を進めなければならないＡＤＲのような業務には最適であると考える。日立製品では，ワークフローシステム“Ｆｌｏｗｍａｔｅ”（フローメイト）が適用できる。」
　という記載、
　
　引用例の上記（カ）において引用している「図４　ＡＤＲの業務フロー図」には、
・連絡票を受け取ってから、「製品別一次評価（ＡＤＲ）」を行い、当該一次評価が完了したら「二次評価（ＡＤＲ）」を行い、当該二次評価が完了したら「最終評価」を行うこと、
・「製品別一次評価（ＡＤＲ）」や「二次評価（ＡＤＲ）」を行う者（例：「安全性管理責任者など」の評価者）が「再調査依頼」を通知すること、
・「調査票（ＡＤＲ）使用成績調査」によって「再調査（副作用分）」に関する「連絡票」を受け取ってから、「製品別一次評価（ＡＤＲ）」を行い、当該一次評価が完了したら「二次評価（ＡＤＲ）」を行い、当該二次評価が完了したら「最終評価」を行うこと、
　が図示されていること、
　
　引用例の上記（ア）の、「臨床開発情報システム〔（ａ），（ｂ）〕と市販後調査システム〔（ｂ），（ｃ）〕」の図には、
　「市販後調査業務サーバ」、「文書管理サーバ」、及び「デスクトップパソコン」を含む「市販後調査システム」が図示されていることから、
（なお、「市販後調査業務サーバ」を有する「市販後調査システム」等のような、サーバを有する「ワークフローシステム」では、「連絡票」等の各種データを「記憶領域」に「記憶」することによって「管理」又は「保管」することは、情報処理分野における技術常識である。）
　
　引用例には、
「連絡票を、記憶領域内に記憶することによって管理する連絡票管理手順と、
　連絡票を評価する評価者の再調査依頼に基づいて、再調査依頼を通知する再調査情報管理手順と、
　上記連絡票の各項目に入力されたデータの評価をする評価手順と、
　連絡票の評価完了を受け取ると、連絡票を記憶領域内に記憶することによって保管する連絡票保管手順」
　が開示されていると認められる。
　
　
　以上の引用例の記載によれば、引用例には下記の発明（以下、「引用例発明」という。）が開示されていると認められる。  
 　  
「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法において、
　連絡票を、記憶領域内に記憶することによって管理する連絡票管理手順と、
　連絡票を評価する評価者の再調査依頼に基づいて、再調査依頼を通知する再調査情報管理手順と、
　上記連絡票の各項目に入力されたデータの評価をする評価手順と、
　連絡票の評価完了を受け取ると、連絡票を記憶領域内に記憶することによって保管する連絡票保管手順とを有するようにしたデータ評価支援方法。」  
　
　
　
３．本願発明と引用例発明との対比  
 　  
（１）  
　引用例発明の「新薬の市販による副作用」、「連絡票」、「評価」、「評価者」、「再調査依頼」は、  
 　  
 　それぞれ、  
 　  
 　本願発明の「製品の実施による影響」、「調査票」、「検証」、「検証者」、「再調査を依頼する再調査依頼要求」に相当する。  
 　  
　
（２）
　引用例発明の「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法」は、
　
　本願発明の「製品の実施による影響を調べる調査票の各項目に入力されたデータの検証を支援するデータ検証支援方法」に相当する。
　
　
（３）
　引用例発明の
「連絡票を、記憶領域内に記憶することによって管理する連絡票管理手順と、
　連絡票の評価完了を受け取ると、連絡票を記憶領域内に記憶することによって保管する連絡票保管手順」と、
　
　本願発明の
「実施者の実施者端末から送信された調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶することによって管理する調査票管理手順と、
　上記検証者端末から調査票の検証完了を受信すると、上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶することによって保管する調査票保管手順」とは、
　
「調査票を、記憶領域内に記憶することによって管理する調査票管理手順と、
　調査票の検証完了を受け取ると、調査票を記憶領域内に記憶することによって保管する調査票保管手順」という点で一致し、
　
・本願発明の「調査票」は、「実施者の実施者端末から送信された」ものであるのに対し、
　引用例発明の「調査票」は、その点が不明である点、
　
・本願発明では、調査票の検証完了を「検証者端末」から「受信」するのに対し、
　引用例発明では、その点が不明である点、
　
・本願発明では、「調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶」し「上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶」するのに対し、
　引用例発明では、「連絡票を、記憶領域内に記憶する」のに留まる点、
　
　で相違する。
　
　
（４）　
　引用例発明の「連絡票を評価する評価者の再調査依頼に基づいて、再調査依頼を通知する再調査情報管理手順」と、
　
　本願発明の「調査票を検証する検証者の検証者端末から受信した再調査を依頼する再調査依頼要求に基づいて、再調査依頼要求で指定される該調査票を送信した実施者へ再調査依頼を通知する再調査情報管理手順」とは、
　
「調査票を検証する検証者の再調査を依頼する再調査依頼要求に基づいて、再調査依頼を通知する再調査情報管理手順」という点で一致し、　
　
・本願発明では、「再調査依頼要求」は「検証者端末から受信」されたり、「再調査依頼要求で指定される該調査票を送信した実施者」へ通知したりするのに対し、
　引用例発明では、その点が不明である点、
　
　で相違する。　
　
　
（５）
　引用例発明の「上記連絡票の各項目に入力されたデータの評価をする評価手順」と、
　
　本願発明の「調査票を検証する検証者の検証者端末からの指示に応じて、上記実施者端末から受信した上記調査票の各入力項目に入力されたデータが論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック手順」とは、 
　
「上記調査票の各入力項目に入力されたデータを判断するチェック手順」という点で一致し、
　
・本願発明の「調査票」は、「上記実施者端末から受信した」ものであるのに対し、
　引用例発明の「調査票」は、その点が不明である点、　　
　
・本願発明では、「調査票を検証する検証者の検証者端末からの指示に応じて」、調査票の各入力項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック」を行うのに対し、
　引用例発明では、そのようになっていない点、
　
　で相違する。　
　
  
（６）  
　したがって、本願発明と引用例発明とは、  
 　  
「製品の実施による影響を調べる調査票の各項目に入力されたデータの検証を支援するデータ検証支援方法において、
　調査票を、記憶領域内に記憶することによって管理する調査票管理手順と、
　調査票を検証する検証者の再調査を依頼する再調査依頼要求に基づいて、再調査依頼を通知する再調査情報管理手順と、
　上記調査票の各入力項目に入力されたデータを判断するチェック手順と、
　調査票の検証完了を受け取ると、調査票を記憶領域内に記憶することによって保管する調査票保管手順とを有するようにしたデータ検証支援方法。」
 　  
　という点で一致し、 
 　 
（相違点１）
・本願発明の「調査票」は、「実施者の実施者端末から送信された」ものであるのに対し、
　引用例発明の「調査票」は、その点が不明である点、
（なお、「実施者端末から送信された」ということと「実施者端末から受信した」ということは、受信側から見れば同趣旨の意味であることを鑑みれば、上記（５）で抽出した相違点である、
『本願発明の「調査票」は、「上記実施者端末から受信した」ものであるのに対し、
　引用例発明の「調査票」は、その点が不明である点』は、上記相違点と同趣旨であるから、上記相違点に纏めている。）
　
・本願発明では、調査票の検証完了を「検証者端末」から「受信」するのに対し、
　引用例発明では、その点が不明である点、
　
・本願発明では、「再調査依頼要求」は「検証者端末から受信」されたり、「再調査依頼要求で指定される該調査票を送信した実施者」へ通知したりするのに対し、
　引用例発明では、その点が不明である点、
　
　
（相違点２）
　本願発明では、「調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶」し「上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶」するのに対し、
　引用例発明では、「連絡票を、記憶領域内に記憶する」のに留まる点、
　
（相違点３）
　本願発明では、「調査票を検証する検証者の検証者端末からの指示に応じて」、調査票の各入力項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック」を行うのに対し、
　引用例発明では、そのようになっていない点、
　
　
　で相違する。 
　
　
　
４．相違点の判断  
　
（１）相違点１について
　
　本出願の明細書の「背景技術」の欄に、
「従来より、製薬企業では、医薬品の安全性及び有効性を保証するために、市販中の医薬品を市販後調査によって調査をおこなっている。市販後調査では、製薬メーカー担当者が医師を訪問して医薬品の調査・試験を依頼すると共に、所定の調査票を医師へ手渡し、医師は、調査依頼のあった医薬品の処方例を所定の調査票に記入し、サイン又は捺印後、回収担当者を介して、製薬メーカーへと提供される。すなわち、市販後調査の工程は、通常、医師が製薬メーカーから依頼のあった医薬品を処方した患者の容態をカルテから調査票へ転記し、その調査票を製薬メーカーがＤＢ（Ｄａｔａ　Ｂａｓｅ）へと入力する。製薬メーカーは、ＤＢに入力されたデータを集計して解析を行うことによって、厚生省へ報告している。
　後日、前記報告した情報が医師からの調査票に基づいていることを保証するため、医師が記入し、サイン又は捺印した調査票を保管及び管理している。
　・・・（中略）・・・。調査票に論理矛盾があった場合、製薬メーカー担当者は、依頼状に医師へのコメントを記入し、再度、医師を訪問し再調査の依頼を行なっている。再調査によって医師から得られた調査票に対して、上記同様の工程が繰り返される。このような再調査は、調査票のデータから論理矛盾等が無くなるまで何度も繰り返される。繰り返し行なわれた再調査によって調査票のデータの信頼性が確認されるとデータが固定され、厚生省への報告のため、データ解析が可能となる。」（第１頁第１７行から第２頁第２２行）
　と記載されているように、市販後調査において、
・「製薬メーカー」側が、（再調査を含む）依頼要求を「医師」側に行う手順、
・「医師」側が、医薬品の調査・試験を行った結果を「調査票」に記入し、「製薬メーカー」側に調査票に提供する手順、
・「製薬メーカー」側が、「医師」から受け取った「調査票」をデータベース化して「保管及び管理」する手順、
　を行うことは、出願人（審判請求人）が「背景技術」として認めているような、医療分野における一般常識である。
　
　
　一方、引用例の上記（カ）に
「市販後調査はフェイズＩＶとして位置づけられ，上市後に特に安全性についてさらに精度を高めて行う調査（Ｓｕｒｖｅｉｌｌａｎｃｅ）である。
　　　　　　　　　　　・・・（中略）・・・
　ここでは，市販後調査特有の業務であるＡＤＲ（副作用自発報告）のワークフローを利用したシステム化について述べる。
　ＡＤＲの業務フローの例を図４に示す。
　フロー定義をすることにより，副作用が発生してから厚生省に報告するまでの一連の業務が，連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など，それぞれの役割を明確にして業務を進めなければならないＡＤＲのような業務には最適であると考える。日立製品では，ワークフローシステム“Ｆｌｏｗｍａｔｅ”（フローメイト）が適用できる。」
　と記載されているように、引用例は、「ワークフローシステム」を採用したものである。
　
　しかも、当該「ワークフローシステム」に関して、複数の組織にまたがる連携を行うワークフローシステム（所謂、インタワークフローシステム）があることは、
　
・インタワークフロー支援技術，ＮＴＴ　Ｒ＆Ｄ，社団法人電気通信学会，１９９６年１２月１０日，Ｖｏｌ.４５，Ｎｏ．１２，ｐ．１３０１−ｐ．１３１４
（「あらまし」の欄に、
「近年，ビジネスプロセスを自動化し，管理する多数のワークフロー管理システム（ＷｆＭＳ）が利用可能となってきた．現在，これらの市販製品は，基本的には単一の組織内の業務支援を目的としている．しかし，多くのビジネスプロセスは単独の組織だけで完遂されるものではなく，複数の組織にまたがる連携が必要となる．また，すべての組織が同一の市販製品を導入しているわけでもない．各組織に導入されている市販製品を相互接続することにより，連携したビジネスプロセスのワークフロー（これを，インタワークフローと呼ぶ）化を実現するためには，業務連携を表現するインタワークフローモデルと接続プロトコルが必要である．
　本論文では，ＮＴＴの物品調達における公告からサプライヤ選定までのビジネスプロセスにおいて，調達物品の開発事業部，調達窓口部門，およびサプライヤ間にまたがる業務連携のケーススタディを行い，その結果に基づいて検討したインタワークフローモデルと接続プロトコルを提案する．」
　と記載されているように、「ＮＴＴ」と「サプライヤ」という独立した組織間でワークフローを行う技術が開示されている。）
　
・特開平１０−３２０４９０号広報（特に、段落【０００５】及び【０００６】乃至【００１０】を参照）
　
　にあるように、情報処理分野における周知技術である。
　
　なお、「ワークフローシステム」が、サーバ装置と複数の端末から構成され、ワークフローにおいて流されるデータを、予め決められた配付ルールに従って、サーバ装置を介して端末間で送受信するものであることは、情報処理分野における周知技術である。
　
　
　したがって、より円滑なワークフロー処理を行うべく、引用例発明に対して、上記周知技術を適用することによって、製薬メーカー側だけのワークフローシステムを拡張して、医者側も含めたワークフローシステムとし、
　実施者（例：医者）及び検証者（例：製薬メーカー側の者）に、ワークフローを処理できる端末（例：実施者の実施者端末、検証者の検証者端末）を与えて、（たとえば、ワークフローシステムが有するサーバ装置（例：引用例の上記（ア）に図示された「市販後調査業務サーバ」）を介して）調査票や依頼要求を送受信させることにより、
　「調査票」を「実施者の実施者端末から送信された」ものとしたり、
　調査票の検証完了を「検証者端末」から「受信」するようにしたり、
　「再調査依頼要求」を「検証者端末から受信」されるようにしたり、「再調査依頼要求で指定される該調査票を送信した実施者」へ通知するようにしたりすることは、
　当業者が容易に想到し得ることである。
　
　
　
（２）相違点２について
　
（２−ａ）
　引用例の上記（カ）に、
「市販後調査はフェイズＩＶとして位置づけられ，上市後に特に安全性についてさらに精度を高めて行う調査（Ｓｕｒｖｅｉｌｌａｎｃｅ）である。 
　試験と調査は業務的に違うところはあるが，重複する部分も非常に多いと考える。システム的には臨床開発試験の延長線上でとらえたほうが，創薬プロセスというフレームワークの中での連携および展開が図りやすい。 」
　と記載されているように、「市販後調査」と「臨床開発試験」とは「重複する部分も非常に多い」と考えられ、「市販後調査」を「システム的には臨床開発試験の延長線上でとらえたほうが，創薬プロセスというフレームワークの中での連携および展開が図りやすい」ということが開示されている。
　
　そして、「市販後調査」に関するシステム（市販後調査情報システム）と重複する部分が非常に多く、延長線上に「市販後調査」があるととらえられている、「臨床開発試験」に関するシステム（臨床開発情報システム）が有するサブシステムに関して、引用例の上記（エ）に、
「（９）症例管理サブシステム 
　症例データの項目定義とＣＲＦ（Ｃｌｉｎｉｃａｌ　Ｒｅｐｏｒｔ　Ｆｉｌｅ：症例カード）によく似た入力画面の作成から症例データの入力・更新までを容易に実現し，その更新履歴を管理することができる。また，症例データの項目を選択し，症例一覧表を容易に作成することができる。」
　と記載されているように、入力データの更新履歴を管理する技術が開示されている。
　
　つまり、「臨床開発情報システム」における入力データの更新履歴を管理する技術が開示されているのであるから、
　「臨床開発情報システム」と重複する部分が非常に多く、「臨床開発情報システム」の延長線上にあるととらえられている、「市販後調査情報システム」における入力データ、例えば「調査票」（連絡票）の更新履歴を管理することが、引用例には示唆されているといえる。
　
　
　しかも、更新履歴を管理する技術の一種として、データの修正に応じた版数管理を行う技術は、情報処理分野における周知技術である。
　
　なお、版数の異なるデータを識別可能にするためには、当該データと共に版数情報を記憶する必要があることや、
　処理対象のデータを「一時的な記憶領域」（例：第一の記憶領域）に記憶して管理しておき、当該データに対する処理が完了した後に、「恒久的な記憶領域」（例：第二の記憶領域）に保管しておくこと（なお、「一時的な記憶領域」から「恒久的な記憶領域」へデータを移す際に、データの「複写」を伴うことは技術的必然である。）は、
　情報処理分野における周知技術である。
　
　また、データの修正に応じて版数情報を変更する場合、マイナーバーションやメジャーバーションを上げることによって版数情報とするか、データの変更回数をそのまま版数情報とするかは、当業者が適宜なし得る設計的事項に過ぎない。
　
　
　したがって、引用例の上記示唆に基づき、引用例発明に対して、当該周知技術を適用することによって、
　「調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶」し「上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶」するように構成することは、
　当業者が容易に想到し得ることである。
　
　
（２−ｂ）
　仮に、更新履歴を管理する技術の一種として、データの修正に応じた版数管理を行う技術について、
　情報処理分野という一般的分野ではなく、医療に関する情報処理分野に基づいて周知性を判断すべきであるとしても、例えば、
　
　原査定の拒絶の理由に引用文献８として引用された、本村　恭一，「医薬品情報提供システム」と「治験情報」，医療とコンピュータ，株式会社日本電子出版，２０００年　９月２０日，第１１巻  第９号，ｐ．４０−４５
（第４４頁右欄第２３乃至２９行には「この際、変更箇所に関しては全て履歴を採取し、後で参照することが可能である。また、先に述べたプロトコールの電子標準書式にはバージョンの概念が導入されている。これはプロトコールの変更を重大な変更の場合はメジャーバーションを上げ、軽微な変更はマイナーバーションを上げて記述するものである。」と記載されている。）
　
　という医療関係の雑誌に掲載されているように、データの修正に応じた版数管理を行う技術は、医療に関する情報処理分野における周知技術である。
　
　したがって、上記（２−ａ）の判断は維持される。
　
　
　
（３）相違点３について
　
　引用例の上記（カ）に
「市販後調査はフェイズＩＶとして位置づけられ，上市後に特に安全性についてさらに精度を高めて行う調査（Ｓｕｒｖｅｉｌｌａｎｃｅ）である。
　　　　　　　　　　　・・・（中略）・・・
　ここでは，市販後調査特有の業務であるＡＤＲ（副作用自発報告）のワークフローを利用したシステム化について述べる。
　ＡＤＲの業務フローの例を図４に示す。
　フロー定義をすることにより，副作用が発生してから厚生省に報告するまでの一連の業務が，連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など，それぞれの役割を明確にして業務を進めなければならないＡＤＲのような業務には最適であると考える。日立製品では，ワークフローシステム“Ｆｌｏｗｍａｔｅ”（フローメイト）が適用できる。」
　と記載されているように、引用例は、「ワークフローシステム」を採用したものである。
　
　なお、「ワークフローシステム」が、サーバ装置と複数の端末から構成され、ワークフローにおいて流されるデータを、予め決められた配付ルールに従って、サーバを介して端末間で送受信するものであることは、情報処理分野における周知技術である。
　
　
　一方、本出願の明細書の「背景技術」の欄に、
「複数の人員によってＤＢに入力されたデータの一致が確認された後、そのデータに論理矛盾がないかを検証するプログラム等を使用して、論理矛盾の検証を行なっている。調査票に論理矛盾があった場合、製薬メーカー担当者は、依頼状に医師へのコメントを記入し、再度、医師を訪問し再調査の依頼を行なっている。」（第２頁第１４乃至１８行）
　と記載されているように、市販後調査において、
入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者」に報告するという「論理チェック」
　なお、仮にそうでないとしても、一般的に、
入力されたデータが「論理的に正しいか否かを判断し、その判断結果」を（検証者などの）報告対象者に報告するという「論理チェック」
　
　そうすると、引用例発明の「上記連絡票の各項目に入力されたデータの評価をする評価手順」という構成における、「入力されたデータの評価」に、
　連絡票の各項目に
入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者」に報告するという「論理チェック」
　
　そして、当該「論理チェック」を含めることによって、当該「論理チェック」を行うプログラムを動作させる場合、
　引用例の「ワークフローシステム」が備えているといえるサーバ装置又は端末で、当該プログラムを実行させたり（なお、本願発明の「論理チェック手順」に関する規定では、当該論理チェックを何が行っているのは特定されていないことに留意されたい。）、
　
調査票を検証する検証者の検証者端末からの指示に応じて
　当該プログラムが実行されることによって得られる
判断結果を該検証者端末に表示させ
　
　
　したがって、より円滑なワークフロー処理を行うべく、引用例発明に対して、上記一般常識及び周知技術を適用することによって、
　検証者（例：製薬メーカー側の者）に、ワークフローを処理できる端末（例：検証者の検証者端末）を与えて、
　連絡票の各項目に
入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者」に報告するという「論理チェック」
　
調査票を検証する検証者の検証者端末からの指示に応じて
　当該プログラムが実行されることによって得られる
判断結果を該検証者端末に表示させ
　「調査票を検証する検証者の検証者端末からの指示に応じて」、調査票の各入力項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック」をすることは、
　当業者が容易に想到し得ることである。
　
　
　
５．むすび  
　
　したがって、本願発明は、引用例発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法２９条２項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、本願は拒絶されるべきものである。  
　
　よって、結論のとおり審決する。