ポートフォリオ機能| 関連審決 |
不服2022-3025 |
|---|
| 元本PDF |
裁判所収録の全文PDFを見る
 |
|---|---|
| 元本PDF |
裁判所収録の別紙1PDFを見る
|
| 元本PDF |
裁判所収録の別紙2PDFを見る
|
| 元本PDF |
裁判所収録の別紙3PDFを見る
|
| 事件 |
令和
6年
(行ケ)
10005号
審決取消請求事件
|
|---|---|
|
5 原告 デカ・プロダクツ・リミテッド・パート ナーシップ 同訴訟代理人弁理士 朴志恩 10 同赤松利昭 同 内藤忠雄 被告 特許庁長官 同 指定代理人梶尾誠哉 15 同伏本正典 同 相崎裕恒 同 後藤亮治 |
|
| 裁判所 | 知的財産高等裁判所 |
| 判決言渡日 | 2024/11/27 |
| 権利種別 | 特許権 |
| 訴訟類型 | 行政訴訟 |
| 主文 |
１ 特許庁が不服２０２２−３０２５事件について令和５年９月１１日にし20 た審決を取り消す。 ２ 訴訟費用は被告の負担とする。 |
| 事実及び理由 | |
|---|---|
|
請求
25 主文同旨 |
|
|
事案の概要
1 本件は、特許出願の拒絶査定に対する不服審判請求を不成立とした審決の取消 訴訟である。争点は、@本願の特許請求の範囲の記載が明確性要件(特許法36 条6項2号)を満たすか否か、A本願明細書の発明の詳細な説明の記載が実施可 能要件(特許法36条4項1号)を満たすか否かである。 5 1 特許庁における手続の経緯等(争いがない) (1) 原告は、令和元年10月28日、発明の名称を「電子患者介護用のシステ ム、方法および装置」とする発明について、本願に係る特許出願をした(特 願2019-195004号)。 本願は、平成25年(2013年)12月20日を国際出願日とする特許10 出願(特願2015-549809号。パリ条約による優先権主張:平成2 4年(2012年)12月21日・米国ほか)の一部を分割して平成30年 3月19日にした特許出願(特願2018-50746号)の一部をさらに 分割し、新たな出願としたものである。 (2) 原告は、令和3年10月20日付けで拒絶査定を受けたため、令和4年215 月28日、拒絶査定不服審判を請求した。 (3) 特許庁は、同審判請求を不服2022-3025号事件として審理し、令 和5年9月11日、「本件審判の請求は、成り立たない。」との審決(以下 「本件審決」という。)をし(出訴期間90日付加)、その謄本は、同月2 6日、原告に送達された。 20 (4) 原告は、令和6年1月24日、本件審決の取消しを求めて本件訴えを提起 した。 2 本願発明の内容 本願の特許請求の範囲の請求項1から11までの記載は、別紙「特許請求の 範囲」のとおりであり、うち請求項1の記載は以下のとおりである。 25 【請求項1】 電子患者介護用のシステムであって、 2 ウェブ・サービスと、ルーティング機能および医療デバイスソフトウェ ア更新の無しまたは少なくとも1つと、を提供するように構成されたゲ ートウェイ;および 前記ウェブ・サービスを使用して前記ゲートウェイと動作可能に通信す 5 るように構成された医療デバイス を備えるとともに、前記ウェブ・サービスがトランザクション・ベース のウェブ・サービスである、システム。 3 本件審決の理由の要旨 ? 明確性(特許法36条6項2号)について10 ア 本願発明1について 本願発明1の「ウェブ・サービス」がどのようなものであるのか、その 技術的な意味が不明である。 例えば、「ウェブ・サービス」とは、「ウェブを介したサービス」とい う広い概念を有しているとも考えられ、その場合、インターネットを介15 したサービスである「電子メール」であっても「ウェブ・サービス」と いうことができる。 しかしながら、本願明細書の発明の詳細な説明には、「ウェブ・サービ ス」について、【0678】に特許請求の範囲と同様の記載しかなく、 本願発明1の「ウェブ・サービス」の具体的な例が一切示されていない20 から、どのようなものが本願発明1の範囲に入るのかを理解することが できず、特許を受けようとする発明を明確に把握することができない。 また、本願発明1の「トランザクション・ベースのウェブ・サービス」 についても、どのようなものであるのか、その技術的な意味が不明である。 まず、「トランザクション・ベース」との記載について、上記と同様、 25 【0678】の記載しかなく、本願発明1の「トランザクション・ベー ス」の具体的な例が一切示されていないから、どのようなものであるの 3 か、その技術的な意味が不明である。 また、「トランザクション・ベース」と「トランザクション」との関係 についても、発明の詳細な説明をみても不明である。 そして、上記のとおり、本願発明1の「ウェブ・サービス」自体も不明 5 であるから、「トランザクション・ベース」であることが「ウェブ・サ ービス」の何を特定(限定)するのか不明であり、本願明細書の発明の 詳細な説明を参酌してもそれを理解することができず、特許を受けよう とする発明を明確に把握することができない。 以上によれば、本願発明1の特許請求の範囲(請求項1)の記載から特10 許を受けようとする発明の内容を把握することはできないから、請求項1 の記載は、特許を受けようとする発明が明確であるということはできない。 イ 本願発明2〜11について 本願発明4の特許請求の範囲(請求項4)の記載は、「医療デバイス」 に係る発明を特定するものであるところ、発明特定事項に請求項1と同15 様の内容を含むものである。 本願発明8の特許請求の範囲(請求項8)の記載は、本願 発 明1の 「システム」に対応する「方法」に係る発明を特定するものであるとこ ろ、発明特定事項に請求項1と同様の内容を含むものである。 そして、請求項2、3は請求項1を、請求項5〜7は請求項4を、請20 求項9〜11は請求項8をそれぞれ引用するものである。 したがって、上記アと同様の理由から、本願発明2〜11の特許請求 の範囲(請求項2〜11)の記載から特許を受けようとする発明の内容 を把握することはできないから、請求項2〜11の記載は、特許を受け ようとする発明が明確であるということはできない。 25 ウ 以上のとおり、本願は、特許請求の範囲の記載が特許法36条6項2号 に規定する要件を満たしていない。 4 ? 実施可能要件(特許法36条4項1号)について 上記?のとおり、本願明細書の発明の詳細な説明をみても、請求項1〜1 1の記載から特許を受けようとする発明の内容を把握することはできないか ら、本願各発明の内容は明確でない。 5 そうすると、本願各発明の内容が明確でない以上、本願明細書の発明の詳 細な説明の記載は、当業者が本願各発明を実施することができる程度に明確 かつ十分に記載したものであるとはいえない。 したがって、本願は、発明の詳細な説明の記載が特許法36条4項1号に 規定する要件を満たしていない。 10 4 原告主張の審決取消事由 ? 明確性要件に関する判断の誤り(取消事由1) ? 実施可能要件に関する判断の誤り(取消事由2) |
|
|
当事者の主張
1 取消事由1(明確性要件に関する判断の誤り)について15 (原告の主張) ? 本願各発明の「ウェブ・サービス」とは、HTTPなどのインターネット 関連技術を応用して、分散コンピューティングを実現したものを指し、19 98年にXMLを基盤とした分散コンピューティングの新技術として登場し て現在に至っている(甲2)。 20 本願明細書には、ウェブ・サービスを構築する要素や仕組みに関する記載 や、ウェブ・サービスの利用を前提とした記載が多数存在している。 ? 本願各発明の「トランザクション・ベースのウェブ・サービス」とは、 「マシンツーマシン通信(コンピュータネットワークに繋がれた機械同士が 人間を介在せずに相互に情報交換し、自動的に最適な制御が行われるシステ25 ム)専用のウェブ・サービス」を指し(甲3)、複数のステップでデータを やり取りし、これらの処理が完全に成功するかどうかを保証するタイプのウ 5 ェブ・サービスであり、すべての操作が成功した場合にのみ処理が確定され るため、原子性、一貫性、独立性、耐久性(ACID特性)を持つことが特 徴である。 例えば、オンラインストアで商品を購入する際に、複数の操作(商品をカ 5 ートに入れる、支払いを処理する、注文を確認するなど)が一つの取引とし てまとめられ、いずれかの操作が失敗した場合、全体の取引が取り消され、 データの整合性が保たれるものが、これに当たる。 ? 「ウェブ・サービス」、「トランザクション・ベースのウェブ・サービス」 とも、人々にとって身近な周知技術であるため(甲4〜9、11、13〜110 7)、発明の詳細な説明に定義や具体的説明がなくとも、当業者は解釈・理 解が可能である。 したがって、本願各発明の「ウェブ・サービス」及び「トランザクショ ン・ベースのウェブ・サービス」の技術的な意味は明確であるから、本願の 特許請求の範囲の記載は、特許法36条6項2号に規定する要件を満たして15 いる。 (被告の主張) ? 本願明細書には、段落【0678】に特許請求の範囲と同様の記載がある のみで、原告も自認するように、「ウェブ・サービス」及び「トランザクシ ョン・ベースのウェブ・サービス」の具体的な説明は一切ないから、本願の20 添付書類ではなく、本願との関係が明らかではない文献の記載をいくら参照 したとしても、本願における用語の技術的な意味が明確であるということは ならない。 したがって、原告の提出した各証拠(甲2〜9、11、13〜17)に上 記の用語の説明が記載されていたとしても、これらは本願の添付書類ではな25 く、本願とは関係がないから、その記載をもって、本願各発明の「ウェブ・ サービス」及び「トランザクション・ベースのウェブ・サービス」の技術的 6 な意味が明確であるということはできない。 当業者の技術常識を踏まえて用語の技術的意味を把握するとしても、本願 明細書には、上記のとおり「ウェブ・サービス」及び「トランザクション・ ベースのウェブ・サービス」について特許請求の範囲の記載と同様の記載し 5 かなく、具体的な実施例は一切示されていないから、技術常識を考慮して用 語の技術的な意味を把握しようとしても、本願明細書にはその手掛かりさえ ない。 このような状況において、本願とは関係がない証拠を後から提出し、特許 請求の範囲に記載された用語の技術的な意味を自由に変更することができる10 とすれば、用語の技術的な意味を、本願明細書の開示を超えて変更すること ができることになってしまう。 したがって、原告の主張は、特許請求の範囲に記載された発明の独占権が 及ぶ範囲を何の制限もなしに自由に拡張したり、変更したりすることを可能 にし、独占権の予測可能性を第三者から奪うことにほかならないから、明確15 性要件の判断規範に照らし、失当である。 ? 原告が挙げるウィキペディア(甲2)、発明者の宣誓供述書(甲3)の記 載内容は、「ウェブ・サービス」、「トランザクション・ベースのウェブ・ サービス」が、原告の主張する技術的意味であることを裏付けるものではな いし、原告の主張する内容によっても、どのような技術に本願発明の権利が20 及ぶのか、第三者はその範囲を一義的に理解することはできない。 その他の各証拠(甲4〜9、11、13〜17)が、原告の主張のどの部 分を裏付けるのかも不明である。 したがって、本件出願当時、本願各発明の「ウェブ・サービス」及び「ト ランザクション・ベースのウェブ・サービス」が、本願各発明の属する技術25 分野の当業者に知られていた技術であったということはできない。 ? 原告は、審判段階において、「ウェブ・サービス」について「インターネ 7 ットを介したサービス」を意味していると主張するなど、本件訴訟における ものとは異なる主張をしており、その主張は変遷している。 また、本願と同じく特願2018-50746号の一部をさらに分割し、 新たな出願とした特願2020-096874号(以下「関連出願」という。 5 明細書の記載は本願明細書と全く同じ。)に係る、本件訴訟と並行して同時 期に審理されている審判手続においては、「ウェブ・サービス」の技術的な 意味が不明である旨の拒絶理由通知に対し、「さらに、請求項4において、 「ウェブ・サービス」との記載を「インターネット(ウェブ)」に補正しま した。「(ウェブ)」を加えたのは、請求項4においてインターネットとウ10 ェブとは同じ意味で使われているからです。」との、本件訴訟におけるもの とは異なる主張をしている。 このような主張の変遷を可能とする本願の特許請求の範囲の記載は、本願 明細書、図面の記載及び技術常識を考慮しても、第三者の利益が不当に害さ れるほどに不明確であるといわざるを得ない。 15 2 取消事由2(実施可能要件に関する判断の誤り)について (原告の主張) 前記のとおり、本願各発明の「ウェブ・サービス」及び「トランザクショ ン・ベースのウェブ・サービス」の技術的な意味は明確であり、発明の詳細な 説明に具体的な記載がなくとも当業者がその内容を把握することができるもの20 であるから、本願明細書の発明の詳細な説明の記載は、特許法36条4項1号 に規定する要件を満たしている。 (被告の主張) 前記のとおり、本願各発明の「ウェブ・サービス」及び「トランザクショ ン・ベースのウェブ・サービス」の技術的な意味は不明確であり、発明の詳細25 な説明にも具体的な記載はないから、本願明細書の発明の詳細な説明の記載は、 本願発明を実施することができる程度に明確かつ十分に記載したものであると 8 はいえない。 |
|
|
当裁判所の判断
1 本願各発明の概要 本願各発明の内容及び本件明細書(甲1)の記載によれば、本願各発明の概 5 要は、次のとおりと認められる(以下、特に断らない限り、【 】内の番号は 本願明細書の段落番号を指す。)。 ? 本願各発明は、電子患者介護用のシステム、方法および装置に関する (【0009】)。 ? 電子診療録(EMR)およびコンピュータ化プロバイダ指示エントリ(C10 POE)を組み込んだもののような介護過程を容易にすることを意図したシ ステムの存在にも関わらず、投薬などの診療を指示および送達することを含 む総合的介護を患者に提供する過程、例えば治療を指示し、送達することは、 いくつかの重要な問題と関連しており、例えば、重要な情報が誤って通信さ れること、治療決定が完全な情報に直ちにアクセスすることなしに行なわれ15 ること、および/または不必要なほどに冗長かつ非効率な手続きに起因する 処方箋の実施の遅れ、が生じる大きい可能性が存在する(【0011】、 【0181】)。 例えば、投薬過誤は、数百件の死の原因となることがあり、米国だけでも 毎年、数千またはさらには数百万人を苦しめている可能性があり、財政的圧20 迫を受けている病院は、多くの投薬過誤の事故を経験している可能性があり、 適切な指示および適切なラベル付をしても、判読できない手書き、薬剤の処 方箋の誤った伝達、および同じような名前を有する薬剤の誤った発音により、 薬剤はなお不適切に投与される可能性がある。投薬過誤の事故を減らすため に、電子医療録(EMR)および薬剤用のバーコード・システムを使用する25 傾向が現れてきており、EMRシステムは、例えば患者の診断、アレルギー、 体重および/または年齢に適合しないコンピュータ・プロバイダ指示入力 9 (CPOE)およびフラグ処方箋を拙速に進めることがあり、しかし、これ らのシステムは幅広く採用されるまでには至っておらず、また、その実施は、 薬剤を指示、調製、および投与する際のかなりの遅延および非効率性をもた らす可能性がある(【0182】)。 5 ? 本願各発明は、これらの課題を解決するために、本願各発明の構成が採用 されているものである。 2 取消事由1(明確性要件に関する判断の誤り)について ? 判断の枠組み 特許法36条6項2号は、特許請求の範囲の記載に関し、特許を受けよう10 とする発明が明確でなければならない旨規定する。同号がこのように規定し た趣旨は、仮に、特許請求の範囲に記載された発明が明確でない場合には、 特許の付与された発明の技術的範囲が不明確となり、第三者に不測の不利益 を及ぼすことがあり得るので、そのような不都合な結果を防止することにあ る。そして、特許を受けようとする発明が明確であるか否かは、特許請求の15 範囲の記載だけではなく、願書に添付した明細書の記載及び図面を考慮し、 また、その発明の属する技術分野における通常の知識を有する者である当業 者の出願当時における技術常識を基礎として、特許請求の範囲の記載が、第 三者に不測の不利益を及ぼすほどに不明確であるか否かという観点から判断 すべきである。 20 ? 当業者の出願当時における技術常識について ア 本願の国際出願日(平成25年(2013年)12月20日)までに公 開されていた刊行物(甲5、6、11、13、16)には、以下の記載が ある。 (ｱ) 特表2005-539324号公報(甲5)25 ビジネス対ビジネス(B2B)及びアプリケーション対アプリケーシ ョン(A2A)電子商取引は、電子データ交換(EDI)のための以 10 前のプロトコルに置き換わりつつある。企業がB2B及びA2Aシス テムでそれらの効率を改善するように努力するにつれて、多数の互換 性のないプラットホームや計算規格が出現した。互換性のある規格の 中には、埋めるべきギャップが残っている。例えば、業界は、簡単な 5 ウェブサービスとは何かを定義した。簡単なウェブサービスに関連し た規格は、UDDI、WSDL、XSDL及びSOAPを含む。… (【0003】) B2B及びA2A電子商取引を実施する 1 つの方法は、ウェブサービ スの利用である。ウェブサービスは、基本的に、ウェブ上の機能をモ10 ジュラー(modular)形態で提示させる新規な方法である。…(【000 4】) ウェブサービスの現在の実施は、通常、3つの規格に適合する。UD DIは、サーチ基準に基づいてウェブサービスを発見しそしてそのイ ンターフェイスをダウンロードするためのレジストリー規格である。 15 WSDLは、ウェブサービスのメッセージインターフェイスを定義す るインターフェイス規格である。SOAPは、有線上のペイロードを 伝送するのに使用されるHTTP(S)トランスポートへのバインデ ィングが定義されたエンベロープ(envelope)プロトコル規格である。 ウェブサービスは、通常、XSDL、Xlink、Xbaｓe及びX20 ｐｏinｔeｒのようなXML規格、並びにHTTP(S)及びUR Iのような汎用ウェブ規格に依存する。(【0005】) (ｲ) 特開2008-33938号公報(甲6) 「ウェブサービス」なる用語は、インターネットプロトコルバックボ ーン上でXML、SOAP、WSDL規格(スタンダード)を使用する25 ウェブベースのアプリケーションをまとめた標準化され方法を記述す る。XMLはデータをタグ付けするのに使用され、SOAPはデータ 11 を転送するのに使用され、WSDLは利用可能なサービスを記述する のに使用される。クライアントとの間で及び互いの間で主に商用の通 信手段として使用されるウェブサービスは、ファイヤウォール背後の 互いのITシステムの詳細な情報なしに商用組織がデータを通信する 5 ことを可能にする。(【0003】) (ｳ) Web Services Atomic Transaction(WS-AtomicTransaction)Version 1.1(甲11、2007年4月16日付け。当業者が作成した仕様書と 認められ、技術常識を示すものと認められる。)の訳文(7〜8頁) 「現在の Web サービス仕様セット[WSDL][SOAP11][SOAP12]は、 10 Web サービスの相互運用性のためのプロトコルを定義しています。Web サービスは、多数の参加者を結び付けて大規模な分散アプリケーショ ンを形成することがますます増えています。」 「アトミック トランザクションには、全か無かの特性があります。 トランザクション参加者がコミット前に実行するアクションは暫定的15 なものにすぎません。通常、それらは永続的ではなく、トランザクシ ョンの外部で可視化されることもありません。アプリケーションはト ランザクションの作業を終了すると、コーディネーターにトランザク ションの結果を決定するよう要求します。コーディネーターは、参加 者に投票を依頼して、処理エラーがあったかどうかを判断します。参20 加者全員が正常に実行できたと投票した場合、コーディネーターは実 行されたすべてのアクションをコミットします。参加者が中止する必 要があると投票した場合、または参加者がまったく応答しない場合、 コーディネーターは実行されたすべてのアクションを中止します。コ ミットは、参加者に暫定的なアクションを最終的なものにするよう指25 示します。これにより、たとえば、アクションを永続化し、トランザ クションの外部から見えるようにすることができます。」 12 「XML[XML]、SOAP[SOAP11][SOAP12]、および WSDL[WSDL]拡 張モデルを使用することにより、SOAP ベースと WSDL ベースの仕様が連 携して機能する豊富な Web サービス環境を定義するように設計されてい ます。そのため、WS-AtomicTransaction 自体は、完全なソリューショ 5 ン に 必 要 な す べ て の 機 能 を 定 義 し て い る わ け で は あ り ま せ ん 。 WS- AtomicTransaction は 、 Web サ ー ビ ス の 他 の 仕 様 ( WS-Coordination [WSCOOR]、WS-Security[WSSec]など)およびアプリケーション固有 のプロトコルで使用されるビルディングブロックであり、Web サービス に関連するさまざまな調整プロトコルに対応できます。」10 ( ｴ ) A Family of Test Criteria for Web Services Transactions (Procedia Computer Science 10(2012)880-887)(甲13)の訳文 「Web サービス(WS)トランザクションは、インターネット上に分散 され、同時に複数のユーザーがアクセスする効率的で信頼性の高い Web アプリケーションを構築するために使用されます。現在の研究では、 15 WSトランザクションのパフォーマンスと信頼性を向上させるために、 さまざまなモデルとプロトコルが開発されています。ただし、WSト ランザクションベースのアプリケーションのテストに関する研究はほ とんどありません。」(訳文1枚目) 「Web サービス(WS)トランザクションの基本原理は、Web サービス20 の信頼性の高い実行と、通常は同時にアクセスされる基礎となるデー タの一貫性を確保することです。」(訳文1枚目) 「2. Web サービスのトランザクションモデル このセクションでは、Web サービス環境の一般化されたトランザクシ ョン モデルを示します。…25 Web サービストランザクション(ｗT)は、アクティビティのフロー によって実行される作業の論理単位であり、その目標は、WSベース 13 のアプリケーションで合意された結果を達成することです。これはｗ T= {A, D} と定義されます。ここで、Aはアクティビティのセッ ト、Dはアクティビティ間の依存関係のセットです。アクティビティ は、作業が実行されるｗT内のポイントを表します。アクティビティ 5 はアトミック(タスク)または非アトミック(サブトランザクション) の場合があります。」(訳文2枚目) (ｵ) Web サービスのトランザクション管理(情報処理学会第66回全国大 会)(甲16。平成16年(2004年)3月開催) 「1. はじめに10 ビジネスの世界に Web サービスを適用するために、複数のサービ スをひとまとまりとする、トランザクション管理に観点をおいた。」 「2.1 Web サービスの概要 Web サービスとは、インターネット上に分散した複数のアプリケ ーションシステムをシステム同士で動的に連携させる技術である。 15 Web サービスの仕組みは Fig.1 に示す。 @提供者がディレクトリにサービスを登録・公開する。 A利用者はディレクトリからサービスを検索する。 B発見したサービスと結合する。」20 「3. Web サービスによるトランザクション管理 14 3.1 概要 Web サ ー ビ ス の ト ラ ン ザ ク シ ョ ン に 関 す る 仕 様 で あ る “ WS- Transaction”を参考にした。この、WS-Transaction には2種類の 規定がある。 5 3.2 アトミックトランザクション(AT) ATとは、all-or-nothing の厳密なトランザクションである、 2フェーズコミットである。 旅行代理店ポータルサイトを例にすると、代理店はまず仮予約を し、すべての予約をすることができる場合は本予約(コミット)し、 10 1つでも予約ができない場合は失敗(アボート)となり、実行前の 状態に戻す(ロールバック)。 3.3 ビジネスアクティビティモデル(BA) BAは、トランザクションの参加者の処理がすべて成功すると仮 定し、すぐに予約(コミット)する。その後、他の参加者の処理が15 失敗した場合は、それまでに成功したすべての参加者の処理をキャ ンセルし、元の状態に戻す。」 「5. おわりに 当研究では、従来の Web サービスにトランザクションが導入され ることによって、今までとは違ったビジネスが提供され、そして、 20 新しいビジネスチャンスが生まれる可能性があることを提案し、そ の有効性について検証した。」 (ｶ) Web サービスのトランザクション処理(甲17。南山大学数理情報 学部情報通信学科2004年度卒業論文要旨集) 「現在、Web サービスを B2B で利用するために、複数のシステムを連25 携する様々な仕様の策定が進められている。Web サービスに対応した トランザクション仕様では長期のトランザクション処理を実現してい 15 る。」 「本研究では、ビジネスプロセス連携に対応した、柔軟性の高いトラ ンザクション処理の実現を目的とした。そこで、Web サービスに対応 したトランザクション仕様である WS-Transaction と、ビジネスプロ 5 セスの連携方法である対話モデルを組み合わせた、対話型トランザク ションを提案した。」 イ 上記アの各刊行物(甲5、6、11、13、16、17)の各記載によ れば、「ウェブ・サービス」という用語は、「インターネット上に分散し た複数のウェブアプリケーションシステムをシステム同士で連携させる技10 術であり、XML、UDDI、WSDL及びSOAPの規格に適合したも の」という意味で用いられ、本願の国際出願日の当時、技術常識となって いたと認められる。 また、この「ウェブ・サービス」との関係において、「トランザクシ ョン」という用語は、「複数の処理をひとまとまりにしたものであって、 15 同時にアクセスされる基礎データの一貫性を確保することができるもの」 という意味で用いられると認められ、そうすると、「トランザクショ ン・ベースのウェブ・サービス」とは、この「トランザクション」を基 礎とした「ウェブ・サービス」という意味の用語であって、これも、本 願の国際出願日(平成25年12月20日)の当時、技術常識となって20 いたと認められる。 したがって、出願当時における技術常識を踏まえると、本願各発明の 「ウェブ・サービス」及び「トランザクション・ベースのウェブ・サー ビス」は、それぞれ、上記の意味で用いられているといえるから、本願 明細書において、これらの用語の具体的な説明がされていなかったとし25 ても、特許請求の範囲の記載が第三者に不測の不利益を及ぼすほどに不 明確であるとはいえない。 16 ? 被告の主張について ア 被告は、本願明細書には「ウェブ・サービス」及び「トランザクショ ン・ベースのウェブ・サービス」の具体的な説明が一切ないから、本願と の関係が明らかではない文献の記載を参照しても技術的な意味が明確であ 5 るということはならず、また、出願当時の技術常識を考慮して用語の技術 的な意味を把握しようとしても、本願明細書にはその手掛かりさえないか ら、本願とは関係がない証拠の提出により用語の技術的な意味を自由に変 更することができることになる旨主張する。 しかし、前記?のとおり、明確性要件の判断は、当業者の出願当時に10 おける技術常識を基礎とすべきところ、「ウェブ・サービス」及びウェ ブサービスに関係する「トランザクション」という用語自体の意味が技 術常識であったと認められるから、本願明細書に具体的な説明がなくと も、「ウェブ・サービス」及び「トランザクション・ベースのウェブ・ サービス」の技術的意味が不明確であるということはできない。 15 また、このように解することは、技術常識の認定の問題であって、原 告が特許請求の範囲に記載された用語の意味を自由に変更することがで きることを意味するものではない。 イ 被告は、原告提出の各証拠から「ウェブ・サービス」及び「トランザク ション・ベースのウェブ・サービス」が当業者に知られていた技術であ20 ったとはいえない旨主張するが、本件各証拠から認定することができる 技術常識は、前記のとおりである。 ウ 被告は、審判段階からの原告の主張に変遷があることや、関連出願にお ける原告の主張が本件訴訟における主張と異なることを指摘する。 しかし、特許法36条6項2号該当性の判断は、審判段階からの原告の25 主張の変遷や、関連出願における原告の主張内容如何にかかわらず、前記 ?のとおり、その発明の属する技術分野における通常の知識を有する者で 17 ある当業者の出願当時における技術常識を基礎として、特許請求の範囲の 記載が、第三者に不測の不利益を及ぼすほどに不明確であるか否かという 観点から客観的に判断されるべきである。被告の主張する点は、本願の特 許請求の範囲の記載が第三者に不測の不利益を及ぼすほどに不明確である 5 とはいえない旨の前記判断を左右するに足りる事情とはならない。 ? 取消事由1についての結論 以上のとおり、本願発明の特許請求の範囲の記載が明確性要件を欠くとす る本件審決の判断には誤りがあるから、取消事由1は理由がある。 3 取消事由2(実施可能要件に関する判断の誤り)について10 ? 特許法36条4項1号は、特許による技術の独占が発明の詳細な説明をも って当該技術を公開したことへの代償として付与されるという仕組みを踏ま え、発明の詳細な説明の記載につき実施可能要件を定める。このような同号 の趣旨に鑑みると、発明の詳細な説明の記載が実施可能要件を充足するため には、当該発明の詳細な説明の記載及び出願当時の技術常識に基づいて、当15 業者が過度の試行錯誤を要することなく、特許を受けようとする発明の実施 をすることができる程度の記載があることを要するものと解される 。 ? 本件審決は、本願各発明の内容が明確でないことから、本願明細書の発明 の詳細な説明の記載は、当業者が本願各発明を実施することができる程度に 明確かつ十分に記載したものであるとはいえないと判断している。 20 しかし、前記2のとおり、本願各発明の内容が明確でないとする本件審 決の判断には誤りがあるから、その判断を前提に、発明の詳細な説明の記載 が実施可能要件を欠くとした本件審決の判断にも誤りがある。 したがって、取消事由2は理由がある。 4 結論25 以上のとおり、本願の特許請求の範囲の記載が明確性要件(特許法36条6 項2号)を満たすとはいえず、本願明細書の発明の詳細な説明の記載が実施可 18 能要件(特許法36条4項1号)を満たすとはいえないとする本件審決の判断 にはいずれも誤りがあり、原告の請求には理由があるから、主文のとおり判決 する。 |
|
| 追加 | |
|
5裁判長裁判官清水響10裁判官菊池絵理15裁判官頼晋一19 (別紙)特許請求の範囲【請求項1】電子患者介護用のシステムであって、 5ウェブ・サービスと、ルーティング機能および医療デバイスソフトウェア更新の無しまたは少なくとも1つと、を提供するように構成されたゲートウェイ;および前記ウェブ・サービスを使用して前記ゲートウェイと動作可能に通信するように構成された医療デバイスを備えるとともに、前記ウェブ・サービスがトランザクション・ベースのウェブ・サー10ビスである、システム。 【請求項2】前記ゲートウェイが前記ウェブ・サービスのウェブ・サーバであり、前記医療デバイスが前記ウェブ・サービスのクライアントである、請求項1に記載のシステム。 【請求項3】15前記医療デバイスが注入ポンプである、請求項1に記載のシステム。 【請求項4】医療デバイスであって、 トランシーバ;および前記トランシーバとインターフェースで接続されて前記トランシーバを介して通信する20ように構成された少なくとも1台のプロセッサであって、前記トランシーバと動作可能に通信するウェブ・サービスと通信するように構成された少なくとも1台のプロセッサ、 を備えるとともに、前記ウェブ・サービスがトランザクション・ベースのウェブ・サービスである、医療デバイス。 【請求項5】25前記医療デバイスが、前記ウェブ・サービスのウェブ・クライアントであるように構成される、請求項4に記載のデバイス。 20 【請求項6】前記ウェブ・サービスがトランザクション・ベースのウェブ・サービスである、請求項4に記載のデバイス。 【請求項7】5前記医療デバイスが注入ポンプである、請求項4に記載のデバイス。 【請求項8】医療デバイスとゲートウェイとの間の通信の方法であって、 前記医療デバイスと前記ゲートウェイとの間に通信を確立する工程;前記医療デバイスと前記ゲートウェイとの間にウェブ・サービスを確立する工程;10および前記ウェブ・サービスを使用して前記医療デバイスと前記ゲートウェイとの間で通信する工程、 を含むとともに、前記ウェブ・サービスがトランザクション・ベースのウェブ・サービスである、方法。 15【請求項9】前記ゲートウェイが前記ウェブ・サービスのウェブ・サーバである、請求項8に記載の方法。 【請求項10】前記医療デバイスが前記ウェブ・サービスのウェブ・クライアントである、請求項8に20記載の方法。 【請求項11】前記ゲートウェイが前記医療デバイスのためのデータをルーティングし、前記データが前記ウェブ・サービスを使用して前記医療デバイスと前記ゲートウェイとの間で通信される、請求項8に記載の方法。 25以上21 |