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