• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特17条の2、3項新規事項追加の補正 特許、登録しない。 G06Q
審判 査定不服 2項進歩性 特許、登録しない。 G06Q
管理番号 1217734
審判番号 不服2007-3534  
総通号数 127 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-07-30 
種別 拒絶査定不服の審決 
審判請求日 2007-02-05 
確定日 2010-06-02 
事件の表示 特願2002-547066「データ検証支援サーバー」拒絶査定不服審判事件〔平成14年 6月 6日国際公開、WO02/44973〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由
第1 手続の経緯

本願は、2001年11月30日(優先権主張2000年12月1日,日本国)を国際出願日とする出願であって、
平成18年10月23日付けで拒絶査定がなされ、これに対し、平成19年2月5日に拒絶査定不服審判の請求がなされるとともに、平成19年2月5日付けで手続補正がなされたものである。




第2 平成19年2月5日付けの手続補正についての補正却下の決定

〔結論〕

平成19年2月5日付けの手続補正を却下する。

〔理由〕

1.補正内容

平成19年2月5日付けの手続補正(以下、「本件補正」という。)は、特許請求の範囲の請求項1乃至22の補正を含むものであって、
本件補正前の特許請求の範囲の請求項1,14,17,20,22(以下、「補正請求項」という。)に、

「更に以降の上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態のうち、少なくとも四つのいずれかの状態を状態フラグに登録」、
すなわち、
「上記実施者端末から該調査票を受信した状態」(以下、「状態A」という。)、
「検証者端末に該調査票を送信した状態」(以下、「状態B」という。)、「該検証者端末から再調査依頼要求情報を受信した状態」(以下、「状態C」という。)、
「該実施者端末に該再調査を送信した状態」(以下、「状態D」という。)、
「該実施者端末から該再調査票を受信した状態」(以下、「状態E」という。)、
「該検証者端末から調査完了を受信した状態」(以下、「状態F」という。)のうち、
少なくとも四つのいずれかの状態を状態フラグに登録、

することを追加する補正を含むものである。



2.本件補正に対する判断

(1)
本出願に係る国際出願日における明細書又は図面(以下、「本出願当初明細書等」という、)の第9頁13行から第15頁第5行、すなわち、以下の(a)乃至(g)という一連の記載(下線は当審にて付加)がある。

(a)
「症例の登録が終了すると、すなわち、担当医師によって患者情報の入力が完了すると、調査票管理システム100は、症例に応じた調査票に関する情報が調査票管理情報で管理し、該調査票の医師側ステータスに「未送信」及び製薬メーカー側ステータスに「(空欄)」を設定する(図3参照)。」

(b)
「担当医師は、医師端末30から症例情報の入力後、症例毎に、調査票管理システム100によって提供される調査票入力画面から情報を入力及び更新し、その調査票を製薬メーカー担当者へ送信する(操作手順25)。操作手順25において、調査票管理システム100は、調査票情報DB113の項目定義を参照しつつ調査票入力画面に基づいて、調査票入力画面を構成し、医師端末30へ該調査票入力画面を提供する。また、担当医師によって医師端末30から入力された調査票の情報を調査票情報として調査票情報DB113に格納する。更に、医師端末30でのメール送信の操作によって、所定の調査票を入力したことを通知するメールを担当医師から製薬メーカー担当者へ送信する。そして、調査票管理システム100は、調査票管理情報の該調査票の医師側ステータスを「送信済」及び製薬メーカー側ステータスを「新着」に変更する(図3参照)。
更に、上記操作手順25において、医師端末30から入力された調査票の情報に基づいて、依頼した医薬品に関して、有害事象や妊娠症例等の緊急に対応が必要となる緊急事象の発生等を示す情報が含まれていた場合、調査票管理システム100は緊急事象発生等を示すメールを生成し、担当医師から製薬メーカー担当者(例えば、安全性担当者)へ送信する。
調査票管理システム100が自動的に行なう緊急事象発生等を示すメールの発信によって、担当医師は、個別に緊急事象が発生した症例を製薬メーカー担当者に通知する手間を省くことができる。また、製薬メーカー担当者は、担当医師が調査票を入力した時点で該メールを製薬メーカー端末40で受信することができるため、緊急事象発生を示す報告等を迅速に対応することができる。」

(c)
「製薬メーカー担当者は、上記操作手順22又は23によって、製薬メーカー端末40から担当医師へ調査票の入力依頼又は催促を行なった後、調査票管理情報に基づいて、調査票管理システム100が提供する契約施設情報画面を参照し、ステータスが「新着」と表示されている調査票を選択し、その調査票の情報を確認する(操作手順26)。調査票管理システム100は、医師側の調査票ステータスを「メーカー受領」、及び、製薬メーカー側の調査票ステータスを「確認中」に変更する(図3参照)。
操作手順26において、製薬メーカー端末40が調査票を選択すると、調査票管理システム100は、選択された調査票の情報に論理矛盾があるか否かを検証する論理チェックを実行し、実行結果を含む調査票を製薬メーカー端末40に表示させる。製薬メーカー担当者は、表示された論理チェックの実行結果を含む調査票に基づいて、担当医師による再調査が必要となる項目を設定する。調査票管理システム100による論理チェックの実行結果及び製薬メーカー端末40によって設定された再調査を必要とする項目に関する情報は、再調査情報として再調査依頼情報DB114に格納される。また、設定した項目のうち、製薬メーカー担当者によって依頼内容が入力されている場合、該依頼内容が再調査依頼内容として再調査依頼情報DB114に格納される。」

(d)
「一方、担当医師への再調査の依頼を必要としない場合、該調査票を完了する(操作手順31)。」

(e)
「製薬メーカー担当者は、再調査の依頼を担当医師へ行なう(操作手順27)。調査票管理システム100は、製薬メーカー端末40での上記操作手順27によって、所定の再調査を依頼するメールを製薬メーカー担当者から担当医師毎に送信する。調査票管理システム100は、調査票管理情報の医師側の調査票ステータスを「新着」、及び、製薬メーカー側の調査票ステータスを「依頼中」に変更する(図3参照)。また、調査票管理システム100は、調査票情報を調査票履歴として履歴版数を1つ上げて調査票履歴テーブル134に転送する。
製薬メーカー担当者は、再調査依頼後、契約施設情報画面を参照し、調査票ステータスが「依頼中」のままである場合、再調査の催促を担当医師へ行なう(操作手順28)。調査票管理システム100は、製薬メーカー担当者による上記操作手順28によって、所定の再調査を催促するメールを製薬メーカー端末40から担当医師へ送信する。」

(f)
「担当医師が、医師端末30にて製薬メーカー担当者からの再調査を依頼するメール又は再調査を催促するメールを受信後、再調査対象となった調査票の情報を修正する(操作手順28)。調査票管理システム100は、医師側の調査票ステータスを「未送信」に変更し、製薬メーカー側の調査票ステータスは「依頼中」のまま変更しない(図3参照)。
担当医師は、医師端末30から修正した調査票情報を製薬メーカー担当者へ送信する(操作手順29)。調査票管理システム100は、担当医師による上記操作手順29によって、所定の再調査を行なったことを示すメールを製薬メーカー担当者へ発信する。」

(g)
「製薬メーカー担当者は、製薬メーカー端末40にて所定の再調査を行なったことを示すメールを担当医師から受信すると、調査票管理情報に基づいて、調査票管理システム100が提供する契約施設情報画面を参照し、ステータスが「新着」と表示されている調査票を選択し、その調査票の情報を確認する(操作手順31)。調査票管理システム100は、医師側の調査票ステータスを「メーカー受領」、及び、製薬メーカー側の調査票ステータスを「確認中」に変更する(図3参照)。
操作手順31において、製薬メーカー担当者が調査票を選択すると、調査票管理システム100は、上記操作手順26と同様に、選択された調査票の情報に論理矛盾があるか否かを検証する論理チェックを実行し、実行結果を含む調査票情報を製薬メーカー端末40に表示させる。製薬メーカー担当者は、表示された論理チェックの実行結果を含む調査票に基づいて、担当医師による再調査が必要となる項目を設定し、再度、操作手順27において、担当医師へ再調査の依頼を行なう。」


なお、本出願当初明細書等の第4頁第4乃至5行の
「上記実施者は、例えば、医師である。
上記検証者は、例えば、制約メーカー担当者等である。」
という記載から、
上記(a)乃至(g)に記載された「製薬メーカー端末」及び「医師端末」は、
補正請求項の「検証者端末」及び「実施者端末」に対応することは明らかである。


(2)
以上の本出願当初明細書等の記載によれば、本出願当初明細書等には以下の事項が開示されていると認められる。

上記(b)の「担当医師は、医師端末30から症例情報の入力後、症例毎に、調査票管理システム100によって提供される調査票入力画面から情報を入力及び更新し、その調査票を製薬メーカー担当者へ送信」するという記載から、
補正請求項の「検証者端末に該調査票を送信した状態」(状態B)が開示されているといえる。

上記(c)の「調査票管理システム100が提供する契約施設情報画面を参照し、ステータスが「新着」と表示されている調査票を選択し、その調査票の情報を確認する」という記載から、
補正請求項の「上記実施者端末から該調査票を受信した状態」(状態A)が開示されているといえる。

上記(d)の「担当医師への再調査の依頼を必要としない場合、該調査票を完了する」という記載から、
補正請求項の「該検証者端末から調査完了を受信した状態」(状態C)が開示されているといえる。

上記(e)の「製薬メーカー担当者は、再調査の依頼を担当医師へ行なう」という記載から、
補正請求項の「該実施者端末に該再調査を送信した状態」(状態D)が開示されているといえる。

上記(f)の「担当医師が、医師端末30にて製薬メーカー担当者からの再調査を依頼するメール又は再調査を催促するメールを受信後、再調査対象となった調査票の情報を修正する」という記載から、
補正請求項の「該検証者端末から再調査依頼要求情報を受信した状態」(状態E)が開示されているといえる。

上記(g)の「製薬メーカー担当者は、製薬メーカー端末40にて所定の再調査を行なったことを示すメールを担当医師から受信する」という記載から、
補正請求項の「該実施者端末から該再調査票を受信した状態」(状態F)が開示されているといえる。


(3)
また、上記(a)乃至(g)の記載、及び【図3】に図示された表(特に、「状態A」乃至「状態F」に対応する、操作手順Nｏ.25,26,27,28,30,31を参照)によれば、「状態A」乃至「状態F」を、
「医師のステータス」と「製薬メーカーのステータス」の2種類のステータスを用いて表現すること、
又は、「医師のステータス」が有する「送信済」、「メーカー受領」、「新着」、「未送信」という4通りの状態と、「製薬メーカーのステータス」が有する「新着」、「確認中」、「依頼中」、「完了」の4通りの状態の合計7種類(なお、「新着」は重複しているので、8種類より1つ少なくなる。)のステータスを用いて表現すること、
が開示されている。


(4)
したがって、本出願当初明細書等の第9頁13行から第15頁第5行の記載、すなわち(a)乃至(g)という一連の記載、及び【図3】に図示された表からは、
「上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態」という『六つの状態』を、
「医師のステータス」と「製薬メーカーのステータス」の2種類のステータスを用いて表現すること、
又は、「医師のステータス」と「製薬メーカーのステータス」で用いられる、「送信済」、「メーカー受領」、「新着」、「未送信」、「確認中」、「依頼中」、「完了」の7種類のステータスを用いて表現すること、
は開示されているとはいえるものの、
「上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態」のうち『少なくとも四つのいずれかの状態』を『状態フラグ』に登録することが開示されているとはいえない。


(5)
本出願当初明細書等における他の箇所の記載を精査しても、上記「上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態」のうち『少なくとも四つのいずれかの状態』を『状態フラグ』に登録することが開示されているとは認められない。


(6)
以上のことから、補正請求項の「更に以降の上記実施者端末から該調査票を受信した状態、検証者端末に該調査票を送信した状態、該検証者端末から再調査依頼要求情報を受信した状態、該実施者端末に該再調査を送信した状態、該実施者端末から該再調査票を受信した状態、該検証者端末から調査完了を受信した状態のうち、少なくとも四つのいずれかの状態を状態フラグに登録」することを追加する補正は、
本出願当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入したものである。



3.むすび

したがって、本件補正は、特許法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。




第3 本願発明について

1.本願発明の認定

本件補正は上記のとおり却下されたので、本願の請求項22に係る発明(以下、「本願発明」という。)は、平成18年6月28日付けの手続補正書の特許請求の範囲の請求項22に記載されたとおりのものと認められるところ、本願発明は、次のとおりのものである。

「 【請求項22】
製品の実施による影響を調べる調査票の各項目に入力されたデータの検証を支援するデータ検証支援方法において、
実施者の実施者端末から送信された調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶することによって管理する調査票管理手順と、
調査票を検証する検証者の検証者端末から受信した再調査を依頼する再調査依頼要求に基づいて、再調査依頼要求で指定される該調査票を送信した実施者へ再調査依頼を通知する再調査情報管理手順と、
調査票を検証する検証者の検証者端末からの指示に応じて、上記実施者端末から受信した上記調査票の各入力項目に入力されたデータが論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック手順と、
上記検証者端末から調査票の検証完了を受信すると、上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶することによって保管する調査票保管手順とを有するようにしたデータ検証支援方法。」



2.引用例の認定

原査定の拒絶の理由に引用文献1として引用された、村上 憲之 他,医薬品製造業における計測・制御・情報システム,日立評論,日立評論社,1996年 4月 1日,第78巻 第4号,ｐ.65-70(以下、「引用例」という)には、図面とともに以下の技術事項が記載されている。

(ア)
「臨床開発情報システム〔(a),(b)〕と市販後調査システム〔(b),(c)〕」の図には、「市販後調査業務サーバ」、「文書管理サーバ」、及び「デスクトップパソコン」を含む「市販後調査システム」が図示されている。
(第65頁)

(イ)
「新薬開発業務および市販後調査業務の推進にあたっては,GCP(Gｏｏd Clinical Pｒacｔice:臨床試験基準),GPMSP(Gｏｏd Pｏｓｔ-Maｒkeｔing Sｕｒｖeillance Pｒacｔice:市販後調査基準)のガイドラインなどに厳格に対応し,かつ期間を短縮するために,適切な対応が求められている。
また,医薬品開発でもグローバル化が進み,医薬品の世界同時開発,同時申請という大きな目標に向けて,ICH(Inｔeｒnaｔiｏnal Cｏnfeｒence ｏn Haｒmｏniｚaｔiｏn)で国際的な立場から効率的,かつ質の高い医薬品開発の実現について検討された。
このような状況の下では,今後,コンピュータを利用することによって業務を大幅に改善する必要があると考える。そこで日立製作所は,従来取り組み培ってきたノウハウをベースに業務の効率と法規制対応をねらった臨床開発・市販後調査のための情報システムを構築した。この情報システムにより,臨床開発では業務の効率化,質の向上,査察への対応を図ることができ,市販後調査では副作用案件の管理を一元化することができる。」
(第65頁左欄第1行から同頁右欄第10行)

(ウ)
「3 臨床開発情報システムの特徴
3.1 臨床開発情報システムの概要
臨床開発情報システムは,大きく11個のサブシステムで構成される(図1参照)。」
(第67頁左欄第14乃至17行)

(エ)
「(9)症例管理サブシステム
症例データの項目定義とCRF(Clinical Reｐｏｒｔ File:症例カード)によく似た入力画面の作成から症例データの入力・更新までを容易に実現し,その更新履歴を管理することができる。また,症例データの項目を選択し,症例一覧表を容易に作成することができる。」
(第68頁左欄第9乃至14行)

(オ)
「4 市販後調査情報システムの特徴
臨床開発試験は,健常人に対して安全性(副作用,血中濃度,薬物動態)をみるフェイズI,アーリー(eaｒlｙ)とレイト(laｔe)があり,至適用法・用量の検討(dｏｓe finding)を行うフェイズII,ダブルブラインドで実施するフェイズIIIがある。概して,上市前の試験(Tｒial)であり,安全性を確保しながら,有効性を見いだすことに主眼が置かれている。」
(第68頁右欄第13乃至20行)

(カ)
「市販後調査はフェイズIVとして位置づけられ,上市後に特に安全性についてさらに精度を高めて行う調査(Sｕｒｖeillance)である。
試験と調査は業務的に違うところはあるが,重複する部分も非常に多いと考える。システム的には臨床開発試験の延長線上でとらえたほうが,創薬プロセスというフレームワークの中での連携および展開が図りやすい。
ここでは,市販後調査特有の業務であるADR(副作用自発報告)のワークフローを利用したシステム化について述べる。
ADRの業務フローの例を図4に示す。
フロー定義をすることにより,副作用が発生してから厚生省に報告するまでの一連の業務が,連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など,それぞれの役割を明確にして業務を進めなければならないADRのような業務には最適であると考える。日立製品では,ワークフローシステム“Flｏｗmaｔe”(フローメイト)が適用できる。」
(第68頁右欄第21行から第69頁左欄第16行)


以上の引用例の記載によれば、引用例には以下の事項が開示されていると認められる。

(a)
引用例の上記(イ)の
「新薬開発業務および市販後調査業務の推進にあたっては,GCP(Gｏｏd Clinical Pｒacｔice:臨床試験基準),GPMSP(Gｏｏd Pｏｓｔ-Maｒkeｔing Sｕｒｖeillance Pｒacｔice:市販後調査基準)のガイドラインなどに厳格に対応し,かつ期間を短縮するために,適切な対応が求められている。
・・・(中略)・・・
このような状況の下では,今後,コンピュータを利用することによって業務を大幅に改善する必要があると考える。そこで日立製作所は,従来取り組み培ってきたノウハウをベースに業務の効率と法規制対応をねらった臨床開発・市販後調査のための情報システムを構築した。この情報システムにより,臨床開発では業務の効率化,質の向上,査察への対応を図ることができ,市販後調査では副作用案件の管理を一元化することができる。」
という記載、
(当該記載から、「臨床開発・市販後調査のための情報システム」が、「新薬の市販による副作用を調べる」ことを「支援」するためのものであることは明らかである。)

引用例の上記(カ)の
「市販後調査はフェイズIVとして位置づけられ,上市後に特に安全性についてさらに精度を高めて行う調査(Sｕｒｖeillance)である。
・・・(中略)・・・
ここでは,市販後調査特有の業務であるADR(副作用自発報告)のワークフローを利用したシステム化について述べる。
ADRの業務フローの例を図4に示す。
フロー定義をすることにより,副作用が発生してから厚生省に報告するまでの一連の業務が,連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など,それぞれの役割を明確にして業務を進めなければならないADRのような業務には最適であると考える。日立製品では,ワークフローシステム“Flｏｗmaｔe”(フローメイト)が適用できる。」
という記載、
(なお、「連絡票」の具体的内容については明記されていないものの、新薬に関する市販後調査では、入力すべきデータが複数あることは世間常識であることを鑑みれば、「連絡票の各項目に入力されたデータの評価」を行っていることは明らかである。)

引用例の上記(カ)において引用している「図4 ADRの業務フロー図」には、連絡票を用いて「製品別一次評価(ADR)」や「二次評価(ADR)」等を行うフロー(方法)が図示されていることから、
(なお、ワークフローシステムで用いられる「連絡票」がコンピュータ間で送受信される電子データであることは明らかである。)

引用例には、「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法」が開示されていると認められる。


(b)
上記(a)の「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法」という開示、

引用例の上記(カ)の
「市販後調査はフェイズIVとして位置づけられ,上市後に特に安全性についてさらに精度を高めて行う調査(Sｕｒｖeillance)である。
・・・(中略)・・・
ここでは,市販後調査特有の業務であるADR(副作用自発報告)のワークフローを利用したシステム化について述べる。
ADRの業務フローの例を図4に示す。
フロー定義をすることにより,副作用が発生してから厚生省に報告するまでの一連の業務が,連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など,それぞれの役割を明確にして業務を進めなければならないADRのような業務には最適であると考える。日立製品では,ワークフローシステム“Flｏｗmaｔe”(フローメイト)が適用できる。」
という記載、

引用例の上記(カ)において引用している「図4 ADRの業務フロー図」には、
・連絡票を受け取ってから、「製品別一次評価(ADR)」を行い、当該一次評価が完了したら「二次評価(ADR)」を行い、当該二次評価が完了したら「最終評価」を行うこと、
・「製品別一次評価(ADR)」や「二次評価(ADR)」を行う者(例:「安全性管理責任者など」の評価者)が「再調査依頼」を通知すること、
・「調査票(ADR)使用成績調査」によって「再調査(副作用分)」に関する「連絡票」を受け取ってから、「製品別一次評価(ADR)」を行い、当該一次評価が完了したら「二次評価(ADR)」を行い、当該二次評価が完了したら「最終評価」を行うこと、
が図示されていること、

引用例の上記(ア)の、「臨床開発情報システム〔(a),(b)〕と市販後調査システム〔(b),(c)〕」の図には、
「市販後調査業務サーバ」、「文書管理サーバ」、及び「デスクトップパソコン」を含む「市販後調査システム」が図示されていることから、
(なお、「市販後調査業務サーバ」を有する「市販後調査システム」等のような、サーバを有する「ワークフローシステム」では、「連絡票」等の各種データを「記憶領域」に「記憶」することによって「管理」又は「保管」することは、情報処理分野における技術常識である。)

引用例には、
「連絡票を、記憶領域内に記憶することによって管理する連絡票管理手順と、
連絡票を評価する評価者の再調査依頼に基づいて、再調査依頼を通知する再調査情報管理手順と、
上記連絡票の各項目に入力されたデータの評価をする評価手順と、
連絡票の評価完了を受け取ると、連絡票を記憶領域内に記憶することによって保管する連絡票保管手順」
が開示されていると認められる。


以上の引用例の記載によれば、引用例には下記の発明(以下、「引用例発明」という。)が開示されていると認められる。

「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法において、
連絡票を、記憶領域内に記憶することによって管理する連絡票管理手順と、
連絡票を評価する評価者の再調査依頼に基づいて、再調査依頼を通知する再調査情報管理手順と、
上記連絡票の各項目に入力されたデータの評価をする評価手順と、
連絡票の評価完了を受け取ると、連絡票を記憶領域内に記憶することによって保管する連絡票保管手順とを有するようにしたデータ評価支援方法。」



3.本願発明と引用例発明との対比

(1)
引用例発明の「新薬の市販による副作用」、「連絡票」、「評価」、「評価者」、「再調査依頼」は、

それぞれ、

本願発明の「製品の実施による影響」、「調査票」、「検証」、「検証者」、「再調査を依頼する再調査依頼要求」に相当する。


(2)
引用例発明の「新薬の市販による副作用を調べる連絡票の各項目に入力されたデータの評価を支援するためのデータ評価支援方法」は、

本願発明の「製品の実施による影響を調べる調査票の各項目に入力されたデータの検証を支援するデータ検証支援方法」に相当する。


(3)
引用例発明の
「連絡票を、記憶領域内に記憶することによって管理する連絡票管理手順と、
連絡票の評価完了を受け取ると、連絡票を記憶領域内に記憶することによって保管する連絡票保管手順」と、

本願発明の
「実施者の実施者端末から送信された調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶することによって管理する調査票管理手順と、
上記検証者端末から調査票の検証完了を受信すると、上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶することによって保管する調査票保管手順」とは、

「調査票を、記憶領域内に記憶することによって管理する調査票管理手順と、
調査票の検証完了を受け取ると、調査票を記憶領域内に記憶することによって保管する調査票保管手順」という点で一致し、

・本願発明の「調査票」は、「実施者の実施者端末から送信された」ものであるのに対し、
引用例発明の「調査票」は、その点が不明である点、

・本願発明では、調査票の検証完了を「検証者端末」から「受信」するのに対し、
引用例発明では、その点が不明である点、

・本願発明では、「調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶」し「上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶」するのに対し、
引用例発明では、「連絡票を、記憶領域内に記憶する」のに留まる点、

で相違する。


(4)
引用例発明の「連絡票を評価する評価者の再調査依頼に基づいて、再調査依頼を通知する再調査情報管理手順」と、

本願発明の「調査票を検証する検証者の検証者端末から受信した再調査を依頼する再調査依頼要求に基づいて、再調査依頼要求で指定される該調査票を送信した実施者へ再調査依頼を通知する再調査情報管理手順」とは、

「調査票を検証する検証者の再調査を依頼する再調査依頼要求に基づいて、再調査依頼を通知する再調査情報管理手順」という点で一致し、

・本願発明では、「再調査依頼要求」は「検証者端末から受信」されたり、「再調査依頼要求で指定される該調査票を送信した実施者」へ通知したりするのに対し、
引用例発明では、その点が不明である点、

で相違する。


(5)
引用例発明の「上記連絡票の各項目に入力されたデータの評価をする評価手順」と、

本願発明の「調査票を検証する検証者の検証者端末からの指示に応じて、上記実施者端末から受信した上記調査票の各入力項目に入力されたデータが論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック手順」とは、

「上記調査票の各入力項目に入力されたデータを判断するチェック手順」という点で一致し、

・本願発明の「調査票」は、「上記実施者端末から受信した」ものであるのに対し、
引用例発明の「調査票」は、その点が不明である点、

・本願発明では、「調査票を検証する検証者の検証者端末からの指示に応じて」、調査票の各入力項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック」を行うのに対し、
引用例発明では、そのようになっていない点、

で相違する。


(6)
したがって、本願発明と引用例発明とは、

「製品の実施による影響を調べる調査票の各項目に入力されたデータの検証を支援するデータ検証支援方法において、
調査票を、記憶領域内に記憶することによって管理する調査票管理手順と、
調査票を検証する検証者の再調査を依頼する再調査依頼要求に基づいて、再調査依頼を通知する再調査情報管理手順と、
上記調査票の各入力項目に入力されたデータを判断するチェック手順と、
調査票の検証完了を受け取ると、調査票を記憶領域内に記憶することによって保管する調査票保管手順とを有するようにしたデータ検証支援方法。」

という点で一致し、

(相違点1)
・本願発明の「調査票」は、「実施者の実施者端末から送信された」ものであるのに対し、
引用例発明の「調査票」は、その点が不明である点、
(なお、「実施者端末から送信された」ということと「実施者端末から受信した」ということは、受信側から見れば同趣旨の意味であることを鑑みれば、上記(5)で抽出した相違点である、
『本願発明の「調査票」は、「上記実施者端末から受信した」ものであるのに対し、
引用例発明の「調査票」は、その点が不明である点』は、上記相違点と同趣旨であるから、上記相違点に纏めている。)

・本願発明では、調査票の検証完了を「検証者端末」から「受信」するのに対し、
引用例発明では、その点が不明である点、

・本願発明では、「再調査依頼要求」は「検証者端末から受信」されたり、「再調査依頼要求で指定される該調査票を送信した実施者」へ通知したりするのに対し、
引用例発明では、その点が不明である点、


(相違点2)
本願発明では、「調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶」し「上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶」するのに対し、
引用例発明では、「連絡票を、記憶領域内に記憶する」のに留まる点、

(相違点3)
本願発明では、「調査票を検証する検証者の検証者端末からの指示に応じて」、調査票の各入力項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック」を行うのに対し、
引用例発明では、そのようになっていない点、


で相違する。



4.相違点の判断

(1)相違点1について

本出願の明細書の「背景技術」の欄に、
「従来より、製薬企業では、医薬品の安全性及び有効性を保証するために、市販中の医薬品を市販後調査によって調査をおこなっている。市販後調査では、製薬メーカー担当者が医師を訪問して医薬品の調査・試験を依頼すると共に、所定の調査票を医師へ手渡し、医師は、調査依頼のあった医薬品の処方例を所定の調査票に記入し、サイン又は捺印後、回収担当者を介して、製薬メーカーへと提供される。すなわち、市販後調査の工程は、通常、医師が製薬メーカーから依頼のあった医薬品を処方した患者の容態をカルテから調査票へ転記し、その調査票を製薬メーカーがDB(Daｔa Baｓe)へと入力する。製薬メーカーは、DBに入力されたデータを集計して解析を行うことによって、厚生省へ報告している。
後日、前記報告した情報が医師からの調査票に基づいていることを保証するため、医師が記入し、サイン又は捺印した調査票を保管及び管理している。
・・・(中略)・・・。調査票に論理矛盾があった場合、製薬メーカー担当者は、依頼状に医師へのコメントを記入し、再度、医師を訪問し再調査の依頼を行なっている。再調査によって医師から得られた調査票に対して、上記同様の工程が繰り返される。このような再調査は、調査票のデータから論理矛盾等が無くなるまで何度も繰り返される。繰り返し行なわれた再調査によって調査票のデータの信頼性が確認されるとデータが固定され、厚生省への報告のため、データ解析が可能となる。」(第1頁第17行から第2頁第22行)
と記載されているように、市販後調査において、
・「製薬メーカー」側が、(再調査を含む)依頼要求を「医師」側に行う手順、
・「医師」側が、医薬品の調査・試験を行った結果を「調査票」に記入し、「製薬メーカー」側に調査票に提供する手順、
・「製薬メーカー」側が、「医師」から受け取った「調査票」をデータベース化して「保管及び管理」する手順、
を行うことは、出願人(審判請求人)が「背景技術」として認めているような、医療分野における一般常識である。


一方、引用例の上記(カ)に
「市販後調査はフェイズIVとして位置づけられ,上市後に特に安全性についてさらに精度を高めて行う調査(Sｕｒｖeillance)である。
・・・(中略)・・・
ここでは,市販後調査特有の業務であるADR(副作用自発報告)のワークフローを利用したシステム化について述べる。
ADRの業務フローの例を図4に示す。
フロー定義をすることにより,副作用が発生してから厚生省に報告するまでの一連の業務が,連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など,それぞれの役割を明確にして業務を進めなければならないADRのような業務には最適であると考える。日立製品では,ワークフローシステム“Flｏｗmaｔe”(フローメイト)が適用できる。」
と記載されているように、引用例は、「ワークフローシステム」を採用したものである。

しかも、当該「ワークフローシステム」に関して、複数の組織にまたがる連携を行うワークフローシステム(所謂、インタワークフローシステム)があることは、

・インタワークフロー支援技術,NTT R＆D,社団法人電気通信学会,1996年12月10日,Vｏl.45,Nｏ.12,ｐ.1301-ｐ.1314
(「あらまし」の欄に、
「近年,ビジネスプロセスを自動化し,管理する多数のワークフロー管理システム(WfMS)が利用可能となってきた.現在,これらの市販製品は,基本的には単一の組織内の業務支援を目的としている.しかし,多くのビジネスプロセスは単独の組織だけで完遂されるものではなく,複数の組織にまたがる連携が必要となる.また,すべての組織が同一の市販製品を導入しているわけでもない.各組織に導入されている市販製品を相互接続することにより,連携したビジネスプロセスのワークフロー(これを,インタワークフローと呼ぶ)化を実現するためには,業務連携を表現するインタワークフローモデルと接続プロトコルが必要である.
本論文では,NTTの物品調達における公告からサプライヤ選定までのビジネスプロセスにおいて,調達物品の開発事業部,調達窓口部門,およびサプライヤ間にまたがる業務連携のケーススタディを行い,その結果に基づいて検討したインタワークフローモデルと接続プロトコルを提案する.」
と記載されているように、「NTT」と「サプライヤ」という独立した組織間でワークフローを行う技術が開示されている。)

・特開平10-320490号広報(特に、段落【0005】及び【0006】乃至【0010】を参照)

にあるように、情報処理分野における周知技術である。

なお、「ワークフローシステム」が、サーバ装置と複数の端末から構成され、ワークフローにおいて流されるデータを、予め決められた配付ルールに従って、サーバ装置を介して端末間で送受信するものであることは、情報処理分野における周知技術である。


したがって、より円滑なワークフロー処理を行うべく、引用例発明に対して、上記周知技術を適用することによって、製薬メーカー側だけのワークフローシステムを拡張して、医者側も含めたワークフローシステムとし、
実施者(例:医者)及び検証者(例:製薬メーカー側の者)に、ワークフローを処理できる端末(例:実施者の実施者端末、検証者の検証者端末)を与えて、(たとえば、ワークフローシステムが有するサーバ装置(例:引用例の上記(ア)に図示された「市販後調査業務サーバ」)を介して)調査票や依頼要求を送受信させることにより、
「調査票」を「実施者の実施者端末から送信された」ものとしたり、
調査票の検証完了を「検証者端末」から「受信」するようにしたり、
「再調査依頼要求」を「検証者端末から受信」されるようにしたり、「再調査依頼要求で指定される該調査票を送信した実施者」へ通知するようにしたりすることは、
当業者が容易に想到し得ることである。



(2)相違点2について

(2-a)
引用例の上記(カ)に、
「市販後調査はフェイズIVとして位置づけられ,上市後に特に安全性についてさらに精度を高めて行う調査(Sｕｒｖeillance)である。
試験と調査は業務的に違うところはあるが,重複する部分も非常に多いと考える。システム的には臨床開発試験の延長線上でとらえたほうが,創薬プロセスというフレームワークの中での連携および展開が図りやすい。 」
と記載されているように、「市販後調査」と「臨床開発試験」とは「重複する部分も非常に多い」と考えられ、「市販後調査」を「システム的には臨床開発試験の延長線上でとらえたほうが,創薬プロセスというフレームワークの中での連携および展開が図りやすい」ということが開示されている。

そして、「市販後調査」に関するシステム(市販後調査情報システム)と重複する部分が非常に多く、延長線上に「市販後調査」があるととらえられている、「臨床開発試験」に関するシステム(臨床開発情報システム)が有するサブシステムに関して、引用例の上記(エ)に、
「(9)症例管理サブシステム
症例データの項目定義とCRF(Clinical Reｐｏｒｔ File:症例カード)によく似た入力画面の作成から症例データの入力・更新までを容易に実現し,その更新履歴を管理することができる。また,症例データの項目を選択し,症例一覧表を容易に作成することができる。」
と記載されているように、入力データの更新履歴を管理する技術が開示されている。

つまり、「臨床開発情報システム」における入力データの更新履歴を管理する技術が開示されているのであるから、
「臨床開発情報システム」と重複する部分が非常に多く、「臨床開発情報システム」の延長線上にあるととらえられている、「市販後調査情報システム」における入力データ、例えば「調査票」(連絡票)の更新履歴を管理することが、引用例には示唆されているといえる。


しかも、更新履歴を管理する技術の一種として、データの修正に応じた版数管理を行う技術は、情報処理分野における周知技術である。

なお、版数の異なるデータを識別可能にするためには、当該データと共に版数情報を記憶する必要があることや、
処理対象のデータを「一時的な記憶領域」(例:第一の記憶領域)に記憶して管理しておき、当該データに対する処理が完了した後に、「恒久的な記憶領域」(例:第二の記憶領域)に保管しておくこと(なお、「一時的な記憶領域」から「恒久的な記憶領域」へデータを移す際に、データの「複写」を伴うことは技術的必然である。)は、
情報処理分野における周知技術である。

また、データの修正に応じて版数情報を変更する場合、マイナーバーションやメジャーバーションを上げることによって版数情報とするか、データの変更回数をそのまま版数情報とするかは、当業者が適宜なし得る設計的事項に過ぎない。


したがって、引用例の上記示唆に基づき、引用例発明に対して、当該周知技術を適用することによって、
「調査票を、該調査票の修正回数を示す版数情報と共に第一の記憶領域内に記憶」し「上記調査票管理手順で管理される該調査票を複写した調査票と上記版数情報とを第二の記憶領域内に記憶」するように構成することは、
当業者が容易に想到し得ることである。


(2-b)
仮に、更新履歴を管理する技術の一種として、データの修正に応じた版数管理を行う技術について、
情報処理分野という一般的分野ではなく、医療に関する情報処理分野に基づいて周知性を判断すべきであるとしても、例えば、

原査定の拒絶の理由に引用文献8として引用された、本村 恭一,「医薬品情報提供システム」と「治験情報」,医療とコンピュータ,株式会社日本電子出版,2000年 9月20日,第11巻 第9号,ｐ.40-45
(第44頁右欄第23乃至29行には「この際、変更箇所に関しては全て履歴を採取し、後で参照することが可能である。また、先に述べたプロトコールの電子標準書式にはバージョンの概念が導入されている。これはプロトコールの変更を重大な変更の場合はメジャーバーションを上げ、軽微な変更はマイナーバーションを上げて記述するものである。」と記載されている。)

という医療関係の雑誌に掲載されているように、データの修正に応じた版数管理を行う技術は、医療に関する情報処理分野における周知技術である。

したがって、上記(2-a)の判断は維持される。



(3)相違点3について

引用例の上記(カ)に
「市販後調査はフェイズIVとして位置づけられ,上市後に特に安全性についてさらに精度を高めて行う調査(Sｕｒｖeillance)である。
・・・(中略)・・・
ここでは,市販後調査特有の業務であるADR(副作用自発報告)のワークフローを利用したシステム化について述べる。
ADRの業務フローの例を図4に示す。
フロー定義をすることにより,副作用が発生してから厚生省に報告するまでの一連の業務が,連絡票という書類が流れていく過程で処理されていく。安全性管理責任者など,それぞれの役割を明確にして業務を進めなければならないADRのような業務には最適であると考える。日立製品では,ワークフローシステム“Flｏｗmaｔe”(フローメイト)が適用できる。」
と記載されているように、引用例は、「ワークフローシステム」を採用したものである。

なお、「ワークフローシステム」が、サーバ装置と複数の端末から構成され、ワークフローにおいて流されるデータを、予め決められた配付ルールに従って、サーバを介して端末間で送受信するものであることは、情報処理分野における周知技術である。


一方、本出願の明細書の「背景技術」の欄に、
「複数の人員によってDBに入力されたデータの一致が確認された後、そのデータに論理矛盾がないかを検証するプログラム等を使用して、論理矛盾の検証を行なっている。調査票に論理矛盾があった場合、製薬メーカー担当者は、依頼状に医師へのコメントを記入し、再度、医師を訪問し再調査の依頼を行なっている。」(第2頁第14乃至18行)
と記載されているように、市販後調査において、入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者」に報告するという「論理チェック」をプログラム等を使用して行うことは、医療分野における一般常識である。
なお、仮にそうでないとしても、一般的に、入力されたデータが「論理的に正しいか否かを判断し、その判断結果」を(検証者などの)報告対象者に報告するという「論理チェック」をプログラム等を使用して行うことは、情報処理分野における周知技術である。

そうすると、引用例発明の「上記連絡票の各項目に入力されたデータの評価をする評価手順」という構成における、「入力されたデータの評価」に、
連絡票の各項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者」に報告するという「論理チェック」を含めることが好ましいといえる。

そして、当該「論理チェック」を含めることによって、当該「論理チェック」を行うプログラムを動作させる場合、
引用例の「ワークフローシステム」が備えているといえるサーバ装置又は端末で、当該プログラムを実行させたり(なお、本願発明の「論理チェック手順」に関する規定では、当該論理チェックを何が行っているのは特定されていないことに留意されたい。)、
調査票を検証する検証者の検証者端末からの指示に応じて当該プログラムを実行させたり、
当該プログラムが実行されることによって得られる判断結果を該検証者端末に表示させたりすればよいこことは明らかである。


したがって、より円滑なワークフロー処理を行うべく、引用例発明に対して、上記一般常識及び周知技術を適用することによって、
検証者(例:製薬メーカー側の者)に、ワークフローを処理できる端末(例:検証者の検証者端末)を与えて、
連絡票の各項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者」に報告するという「論理チェック」を含めたり、
調査票を検証する検証者の検証者端末からの指示に応じて当該プログラムを実行させたり、
当該プログラムが実行されることによって得られる判断結果を該検証者端末に表示させたりすることによって、
「調査票を検証する検証者の検証者端末からの指示に応じて」、調査票の各入力項目に入力されたデータが「論理的に正しいか否かを判断し、その判断結果を該検証者端末に表示させる論理チェック」をすることは、
当業者が容易に想到し得ることである。



5.むすび

したがって、本願発明は、引用例発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであり、特許法29条2項の規定により特許を受けることができないから、他の請求項について検討するまでもなく、本願は拒絶されるべきものである。

よって、結論のとおり審決する。
 
審理終結日 2009-12-24 
結審通知日 2010-01-05 
審決日 2010-01-18 
出願番号 特願2002-547066(P2002-547066)
審決分類 P 1 8・ 121- Z (G06Q)
P 1 8・ 561- Z (G06Q)
最終処分 不成立  
前審関与審査官 佐藤 裕子、松田 直也  
特許庁審判長 田口 英雄
特許庁審判官 和田 財太
小曳 満昭
発明の名称 データ検証支援サーバー  
代理人 伊東 忠彦  
代理人 伊東 忠彦  

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