本記事では、McKesson事件(McKesson v. Epic (Fed. Cir., April 12, 2011))について説明したいと思います。関連するAkamai事件（Akamai事件を踏まえたクレーム作成）については以下の記事をご参照下さい。
要点
McKesson事件ではAkamai事件同様、複数主体による特許の実施が問題になりました。特許権者がMcKesson社で、Epic社が被疑侵害者です。Epic社製のソフトはMcKesson社の特許(US6757898B1, 以下’898特許)の方法を使用するものでしたが、当該方法が複数の主体(医者と患者)により用いられていたため、最終的には特許権侵害が認められませんでした。
シングル・エンティティルールに基づくと原則通りという結論ですが、Akamai事件とは逆の結論です。なぜこのような結論になったのか知っておくことは本事件の理解を深めることに加えて、Akamai事件の理解、これらの裁判例を踏まえたクレームドラフティングに役立つと思います。以下、本事件の解説をしたいと思います。
本事件の解説
以下、もう少し本事件の内容について触れていきたいと思います。主に、’898特許の内容及び被疑侵害者による行為を解説します。
‘898特許の概要
‘898特許は、医者と患者間とのコンピュータ上のコミュニケーション方法に関するものです。医者と患者はいずれも、患者の通院毎にアップデートされるオンラインコンテンツにアクセス可能で、当該コンテンツにより医者及び患者双方の利便性が向上するというものです。例えば次回の通院の予約、処方箋の追加の要求などが本方法によりできることになります。出願日等の書誌情報は以下の通りです。
- 特許番号: US6,757,898
- 発明の名称: Electronic provider – patient interface system
- 特許権者(登録時): McKesson Information Solutions, Inc.
- 出願日: 2000/1/18
- 登録日: 2004/6/29
代表クレーム
クレーム骨子
‘898特許の代表クレーム(Claim 1)の骨子は以下の通りです。まず概要として以下のようなクレームの構成となっています。
- user(患者)がコンピュータ上のコミュニケーションを開始。provider(医者)は、userごとの医療記録を保有。
- provider/patient interface(明細書記載のePPi™というシステム)を介してuser-provider間のコミュニケーションを実現
- 過去にproviderから提供されたコンテンツとコミュニケーションの内容とを比較
- コミュニケーションに対するレスポンスを返信
クレームの抜粋
本件のクレーム１は以下の通り方法クレームです。クレーム中のproviderが医者に対応し、userが患者に対応します。
1. A method of automatically and electronically communicating between at least one health-care provider and a plurality of users serviced by the health-care provider, said method comprising the steps of:
initiating a communication by one of the plurality of users to the provider for information, wherein the provider has established a preexisting medical record for each user;
enabling communication by transporting the communication through a provider/patient interface …;
electronically comparing content of the communication with mapped content…; and
returning the response to the communication automatically to the user’s computer…
said provider/patient interface providing a fully automated mechanism for generating a personalized page or area within the provider’s Web site for each user serviced by the provider; and
said patient-provider interface service center for dynamically assembling and delivering custom content to said user.
US6757898B1
細かい点ですが、クレーム１の最後の２つの要素(said provider/patient interface providing…と、said patient-provider interface service center for dynamically assembling)の部分は、それぞれ”provider/patient interface”と”patient-provider interface service center”という文言を限定する意図で記載されています。文法的・慣習的な観点では通例の記載方法には則ったものではありません（通常ですとwherein節により記載される内容です。）
被疑侵害者の行為
Epic社は主に医療関連ソフトを製造して医者に使用許諾するソフトウェア開発会社です。本事件では Epic社製のMyChart Softwareというソフトウェアにより実行される方法が問題になりました。なおEpic社は方法の使用を行ってはいないため、 McKessonは誘引侵害に基づく主張をしました(35 USC 271(b))。
ここで誘引侵害は直接侵害が発生していなければ成立しません。そのため本裁判では特許方法を実行する主体による直接侵害の有無が問題となりました。MyChart Softwareを利用して特許方法を実行する主体は、医者及び患者、つまり複数の主体です。具体的には、患者がMyChart Softwareを使って上記のクレーム中にて下線を付したinitiating a communication ….のステップを実行し、医者がMyChart Softwareを使ってその他の全ステップ(enabling, electronically comparing, returningのステップ)を実行しました。
ここでひとつのポイントが、医者は患者に対してMyChart Softwareの使用を義務付けていなかった点です。もし患者がMyChart Softwareを使うことを選択した場合には、その患者は医者のMyChartのウェブページにログインして、コミュニケーションを開始することになります。認証処理が完了すると患者は自身の医療記録が示されたマイページにアクセスできる形になっていました。
裁判所の判断
Akamai事件同様、本事件では、複数主体が関与しているものの、一方が他方を「指示又は管理している場合」に該当するか否かが判断されました。結果として、医者が患者に対してMyChart Softwareの使用を義務付けていなかった事実に基づき、医者が患者を「指示又は管理している場合」には当たらないとして、裁判所は直接侵害を否定しました。
まとめ
McKesson事件ではAkamai事件同様、複数主体による特許の実施が問題になり、当該方法が複数の主体(医者と患者)により用いられていました。患者が一部のステップ(initiatingステップ)を実行しており、医者により患者の行為が指示又は管理している場合には当たらず、最終的には特許権侵害が認められませんでした。
このように、シングル・エンティティルールに基づき、原則通りの結論となっている事例が存在します。他方でAkamai事件のように例外的な結論になっている事例もあります。クレームドラフトする際には本事件にも留意して、シングル・エンティティルールに照らして問題ないようにしておくことが肝要と思われます。
ここまで読んで頂きありがとうございました。
コメント