平成17年 (行ケ) 10596号審決取消請求事件｜特許判例データベース

運営：アスタミューゼ株式会社

会員機能

ＩＤ登録

パテントビューロIDとは？

判例データベース

審決データベース

パナソニックで一緒に知財の仕事しませんか？

ポートフォリオ機能

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

関連審決	無効2004-35164

この判例の個人情報、企業機密に関する修正依頼をする

関連ワード

インターネット / アクセス / 進歩性(29条2項) / 容易に発明 / 引用発明の認定 / 一致点の認定 / 相違点の認定 / 周知技術 / 上位概念 / 先行技術 / 援用権(援用) / 置き換え / 容易に想到(容易想到性) / 意識的除外(意識的に除外) / 特許発明 / 構成要件 / 設定登録 / 訂正審判 / 請求の範囲 / 減縮 / 変更 / 訂正明細書 / 合理的な理由 /

元本PDF	裁判所収録の全文PDFを見る

事件	平成 17年 (行ケ) 10596号審決取消請求事件
事件	原告メガソフト株式会社代表者代表取締役訴訟代理人弁理士古谷栄男同松下正同鶴本祥文同佐々木康被告Ｙ訴訟代理人弁理士川崎研二同高田聖一
裁判所	知的財産高等裁判所
判決言渡日	2006/03/13
権利種別	特許権
訴訟類型	行政訴訟
主文	１原告の請求を棄却する。２訴訟費用は原告の負担とする。

事実及び理由
請求特許庁が無効2004-35164号事件について平成17年6月27日にした審決を取り消す。
事案の概要本件は,原告の有する後記特許について被告が無効審判を請求したところ,特許庁がこの特許を無効とする審決をしたことから,原告がその取消しを求めた事案である。
当事者の主張 1 請求原因(1) 特許庁等における手続の経緯原告は,名称を「データ転送システムおよびファクシミリ送信システム」とする発明につき平成13年4月27日特許出願し,平成15年7月4日特許庁から設定登録を受けた(特許第3447718号。請求項1ないし14。以下「本件特許」という。)。被告は,平成16年3月26日,本件特許の全請求項につき特許無効審判請求をした。特許庁は,これを無効2004-35164号事件として審理した上,平成16年11月9日本件特許を無効とする審決をした。これに対し,原告は審決取消訴訟を提起し(東京高等裁判所平成16年(行ケ)第545号),平成17年2月22日特許庁に本件特許の訂正を求める審判を請求したため,同裁判所は,平成17年2月28日,事件を審判官に差し戻すため特許法181条2項の規定により審決を取り消す決定(甲9)をした。そこで特許庁において上記事件についてさらに審理が続行され,原告は,平成17年3月22日,上記訂正審判請求書(甲10)に添付した明細書又は図面(以下,同明細書及び図面を併せて「訂正明細書」という。)を援用して訂正(以下「本件訂正」という。)を求めた(特許法134条の3第3項)。本件訂正は,発明の名称を「データ転送方法およびファクシミリ送信システム」と変更し,請求項13を削除する(したがって,訂正前請求項14が訂正後請求項13となる。)ほか,特許請求の範囲の減縮等を内容とするものであった。特許庁は,平成17年6月27日に「訂正を認める。特許第3447718号の請求項1から13に係る発明についての特許を無効とする。」との審決をし,その謄本は,平成17年7月7日原告に送達された。 (2) 発明の内容本件訂正後の発明の内容は,次のとおりである(下線は訂正部分。以下,請求項1～13を「本件発明1」～「本件発明13」といい,これらを併せて「本件各発明」という。)。【請求項1】A )以下のa1),a2)を備えa1)指定された送信先へ送信対象データをファクシミリ送信するサーバ,a2)前記サーバにネットワーク接続されたクライアント,前記サーバは前記クライアントから送信対象データおよび送信先データを受け取ると,指定された送信先へ前記送信対象データを送信するファクシミリ送信システムであって,B)前記クライアントにはプリンタドライバとして,以下のような自動通信処理プログラムがインストールされており,b1)送信対象データ作成可能アプリケーションプログラムにて,作成された送信対象データの出力先を制御するプリンタードライバとして選択されて,送信対象データが出力指定されると,前記サーバに当該送信対象データを送信先の特定されていない送信対象データとして送信し,b2)その後,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して,定められた送信先データ作成画面データを生成するURIにアクセスさせる,C)前記サーバは,前記クライアントから送信された送信対象データを,前記送信先データ作成画面データで表示された画面にて入力された送信先データによって特定される送信先に,ファクシミリ送信すること,を特徴とするファクシミリ送信システム。【請求項2】ネットワーク接続されたサーバを介して,指定された送信先へ送信対象データをファクシミリ送信するクライアントであって,送信対象データ作成アプリケーションプログラムから送信先の特定されていない送信対象データを受け取り,その送信対象データを前記サーバに送信するプリンタドライバがインストールされており,前記プリンタドライバは,前記送信対象データを前記サーバに送信すると,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムによって前記送信対象データの送信先データを入力させる送信先データ入力画面を表示させること,を特徴とするファクシミリ送信クライアント。【請求項3】請求項1のファクシミリ送信システムにおいて,前記サーバは,前記クライアントから個別セッションidが特定された送信対象データを受け取るとこれを記憶するとともに,前記送信対象データの送信先データを特定するためのウェブページを送信すること,を特徴とするもの。【請求項4】請求項3のファクシミリ送信システムにおいて,前記サーバは,前記クライアントからセッション開始要求を受け取ると,個別セッションidを当該クライアントに送信すること,を特徴とするもの。【請求項5】請求項3または請求項4のファクシミリ送信システムにおいて,前記送信対象データの送信先データを特定するためのウェブページの送信は,前記サーバが,前記クライアントから個別セッションidを特定するウェブページの送信要求を受け取って実行されること,を特徴とするもの。【請求項6】請求項1のファクシミリ送信システムまたは請求項2のファクシミリ送信クライアントにおいて,前記クライアントは個別セッションidが特定された送信対象データを前記サーバに送信し,当該送信対象データの送信先データを特定するためのウェブページを送信させる送信要求を前記サーバに送信すること,を特徴とするもの。【請求項7】請求項6のファクシミリ送信システムまたはファクシミリ送信クライアントにおいて,前記クライアントは,前記サーバにセッション開始要求を送信し,受け取った個別セッションidの前記送信対象データとして送信すること,を特徴とするもの。【請求項8】請求項6または請求項7のファクシミリ送信システムまたはファクシミリ送信クライアントにおいて,前記クライアントは,前記サーバに対して個別セッションidを特定するウェブページの送信要求を送信し,前記送信対象データの送信先データを特定するためのウェブページを受信すると,これを表示すること,を特徴とするもの。【請求項9】請求項6～請求項8のいずれかのファクシミリ送信システムまたはファクシミリ送信クライアントにおいて,前記クライアントは,前記送信対象データ用の送信先をクライアントの操作者が指定するための画面データを受け取るためのリソース識別子を,前記ブラウザプログラムに渡して,起動すること,を特徴とするもの。【請求項10】ネットワーク接続されたサーバを介して,指定された送信先へ送信対象データをファクシミリ送信するクライアントとしてコンピュータを機能させるためのコンピュータ可読のプログラムであって,プリンタドライバとして,送信対象データ作成アプリケーションプログラムから送信先の特定されていない送信対象データを受け取り,その送信対象データを前記サーバに送信するとともに,前記送信対象データを送信した後,前記送信対象データの送信先データを入力させる送信先データ入力画面が表示されるように,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動させる,ためのコンピュータ可読のプログラム。【請求項11】指定された送信先へ送信対象データをファクシミリ送信するサーバにクライアントをネットワーク接続し,前記クライアントから送信対象データおよび送信先データを受け取ると,前記サーバは指定された送信先へ前記送信対象データを送信するファクシミリ送信方法であって,前記クライアントは,送信対象データ作成可能アプリケーションプログラムにて作成された送信対象データの出力先を制御するプリンタードライバとして選択された状況で送信対象データが出力指定されると,前記サーバに当該送信対象データを送信先の特定されていない送信対象データとして送信するとともに,前記送信対象データの送信後,その送信先データを入力する画面を表示する画面データを受け取るためのリソース識別子をアプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムに与え,前記サーバは,前記クライアントから送信された送信対象データを,前記送信先データを入力する画面にて入力された送信先データによって特定される送信先に,ファクシミリ送信すること,を特徴とするファクシミリ送信方法。【請求項12】ネットワーク接続されたサーバを介してクライアントから指定された送信先へ送信対象データをファクシミリ送信するファクシミリ送信方法であって,前記クライアントから,送信対象データを送信先の特定されていない送信対象データとして送信対象データ作成アプリケーションプログラムの印刷コマンドから専用プリンタドライバを介して前記サーバに送信し,前記送信対象データを前記サーバに送信すると,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムによって前記送信対象データの送信先データを入力させる送信先データ入力画面を表示させること,を特徴とするクライアントを用いたファクシミリ送信方法。【請求項13】指定された送信先へ送信対象データをデータ転送するサーバにクライアントをネットワーク接続し,前記クライアントから送信対象データおよび送信先データを受け取ると,前記サーバは指定された送信先へ前記送信対象データを転送するデータ転送方法であって,前記サーバは,前記クライアントの送信対象データ作成可能アプリケーションプログラムにて作成された送信先の特定されていない送信対象データが,プリンタードライバとして機能する通信プログラムを介して送信されるとこれを記憶しておき,その後,前記クライアントから,前記送信対象データの送信先データを入力する画面を表示するための送信先データ作成画面データのダウンロード要求があると,前記サーバは当該クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムに前記通信プログラムを介して送信された送信対象データの送信先を特定する送信先データ作成画面データを送信し,前記クライアントから送信された送信対象データを,前記送信先データ作成画面データに対して返信された送信先データによって特定される送信先に,転送すること,を特徴とするデータ転送方法。」(以下,「本件発明1」～「本件発明13」といい,これらを併せて「本件各発明」という。)(3) 審決の内容ア審決の詳細は,別添審決写し記載のとおりである。その要旨は,本件発明1ないし13は,下記引用例並びに下記甲3刊行物,甲4刊行物及び甲5刊行物記載の発明に基づいて当業者が容易に発明をすることができたから,その特許は特許法29条2項の規定に違反し無効である等とするものであった。記・引用例(以下,これに基づく発明を「引用発明」という。):Windows対応FAXソフトウエアEasyFaxユーザーズマニュアル(審判甲1・本訴甲2)・甲3刊行物:特開2001-101132号公報(審判甲2・本訴甲3)・甲4刊行物:特開平5-153309号公報(審判甲3・本訴甲4)・甲5刊行物:特開平10-177548号公報(審判甲5・本訴甲5)イ本件発明1と引用発明との一致点及び相違点審決は,引用発明の内容を次のとおり認定した上,本件発明1との一致点と相違点を下記のように摘示した。記<引用発明の内容>「アプリケーションで作成したデータをクライアントPC上のクライアント版からサーバーPCを経由してファックスを送信するシステムであって,クライアントPC上のクライアント版はアプリケーションでプリンタドライバとして設定されており,印刷範囲を指定して[OK]ボタンをクリックすると,[FAX送信]ダイアログが表示され,ここで送信先を指定して[送信]ボタンをクリックすると指定した送信先に送信されるシステム。」<一致点>「A )以下のa1),a2)を備えa1)指定された送信先へ送信対象データをファクシミリ送信するサーバ,a2)前記サーバにネットワーク接続されたクライアント,前記サーバは前記クライアントから送信対象データおよび送信先データを受け取ると,指定された送信先へ前記送信対象データを送信するファクシミリ送信システムであって,B)前記クライアントにはプリンタドライバとして,以下のような自動通信処理プログラムがインストールされており,b1)送信対象データ作成可能アプリケーションプログラムにて,作成された送信対象データの出力先を制御するプリンタードライバとして選択されて,送信対象データが出力指定されると,b2)その後,送信先データ作成画面を表示し,C)前記サーバは,前記クライアントから送信された送信対象データを,前記送信先データ作成画面データで表示された画面にて入力された送信先データによって特定される送信先に,ファクシミリ送信すること,を特徴とするファクシミリ送信システム。」である点。 <相違点1>本件発明1では,送信対象データが出力指定されるとサーバに当該送信対象データを送信先の特定されていない送信対象データとして送信し,その後,送信先データ作成画面を表示するのに対し,引用発明では,出力指定されると送信先データ作成画面を表示しその後送信が行われる点。 <相違点2>本件発明1では,送信先データ作成画面の表示を,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して,定められた送信先データ作成画面データを生成するURIにアクセスさせることで行うのに対し,引用発明ではこの表示をどのように行うのか具体的な開示がない点。 (4) 審決の取消事由しかしながら,審決は,以下に述べる理由により,本件各発明の進歩性判断を誤っているから,違法として取り消されるべきである。ア取消事由1(引用発明の認定の誤り)(ｱ) 審決は,引用例には「アプリケーションで作成したデータをクライアントPC上のクライアント版からサーバーPCを経由してファックスを送信するシステムであって,クライアントPC上のクライアント版はアプリケーションでプリンタドライバとして設定されており,印刷範囲を指定して[OK]ボタンをクリックすると,[FAX送信]ダイアログが表示され,ここで送信先を指定して[送信]ボタンをクリックすると指定した送信先に送信されるシステム。」の発明(引用発明)が記載されていると認定した(審決13頁第2段落)上で,引用発明の「クライアントPC」は本件発明1の「クライアント」に相当するとした(同15頁最終段落～16頁第1段落)が誤りである。 (ｲ) 引用例には,①「スタンドアローンとしてのPCにおいて,アプリケーションでFAX送信ソフトウェアをプリンタドライバとして設定されており,印刷範囲を指定して[OK]ボタンをクリックすると,[FAX送信]ダイアログが表示され,ここで送信先を指定して[送信]ボタンをクリックすると指定した送信先に送信されるシステム」(以下「スタンドアローンシステム」という。),及び②「サーバーPCにおいて送受信されたデータ若しくはサーバーPCにおいて,当該サーバーPCのユーザによる操作によって登録されたデータを,クライアントPC上のクライアント版からの指示に基づき,サーバーPCがファックスを送信するシステム」(以下「サーバー-クライアントシステム」という。)は記載されているが,「クライアントPCにおいて作成されたデータを,サーバを介して,送信先へファックス送信するという発明」については開示も示唆もない。したがって,引用発明の「クライアントPC」は,本件発明1の「クライアント」に相当するものということはできない。その理由は,次のとおりである。 a 審決が摘示する引用例の記載アないしエ(審決11頁第4段落～12頁第1段落)には「スタンドアローンシステム」が記載されているが,記載オ(同12頁最終段落～13頁第1段落)からは「サーバーPCとクライアントPCとが接続されているネットワークにおいて,クライアントPCは,送信要求によってサーバーPCに対して実際にファックスを送信させることができるもの」は記載されているといえるが,当該クライアントPCがどのようなデータをファックス送信させることができるのかについては記載がない。そこで,引用例の他の部分の記載を見ると,引用例(Windows対応FAXソフトウエアEasyFaxユーザーズマニュアルの審判において提出された部分が甲2であり,提出されなかった部分が甲7である。)には,下記の記載(下線は原告付加)がある。記①「6.3 WEB閲覧/配信機能 PRO2000 ClientPRO2000をインストールしたPCが,Microsoft社のパーソナルWEBサーバーやIISによってWEBで公開されたディレクトリを持つとき,PRO2000では,配信ログ内のファックスをWEB上に公開することができます。「WEB閲覧/配信機能」といい,公開されたファックスは,ブラウザを利用して閲覧したり,必要なファックスの取り込みができます。」(甲2の207頁1行目～6行目)②「ブラウザを使って閲覧,配信する ClientPRO2000でWEB閲覧/配信機能が設定されている場合,クライアントではブラウザを使って,ファックスの閲覧や送信が行えます。 1 ブラウザを起動し,「EasyFax配信ログ」ファイルを開きます。「EasyFax配信ログ」ファイルの公開アドレス(URL)は,ネットワーク管理者にお尋ねください。 2 必要なファイルの閲覧や受信を行います。」(同209頁6行目～12行目)③「■ファックスを受信するファックスを受信します。インターネットFAXとして,または指定したファックス機への受信が可能です。 1 受信したいファックスの[取得]をオンします。複数のファックスを指定できます。 2 必要に応じてパスワードを入力します。パスワードが設定されている場合,パスワードを入力しないとファックス受信はできません。パスワードについては,ネットワーク管理者にお尋ねください。 3 [送信方法]の▼ボタンをクリックし,[インターネットFAX]または[FAX番号]を選択します。 4 [送信先]にメールアドレスまたはファックス番号を入力します。インターネットFAXで受信する場合は,メールアドレス(abc@aisoft.co.jpなど)を入力します。ファックス機で受信する場合は,そのファックス機の番号を入力します。 5 [選択したFAXを送信する]ボタンをクリックします。指定した送信方法により,ファックスが送信されます。送信方法がインターネットFAXの場合,インターネットメールサーバーやMicrosoftExchange,OutlookExpressなどの受信トレイに保存されます。」(同210頁1行目～211頁4行目)④「配信ログ 2000 PRO2000配信ログでは,外部からのポーリング受信に応じて配信するファックスや,PRO2000ではWEB公開用のファックスを管理しています。送信ログや受信ログと異なり,EasyFaxが配信するファックスの保存用ログとして利用されます。 ●配信ログが管理するデータ・[ファイル]-[配信ログへの入力]で読み込んだデータBMP,TIFF(非圧縮,MH,PackBits,ClassF)PCX,1T4形式のモノクロ2階調画像データ*配信ログ内では,1T4ファイルとして管理されます。・[編集]-[配信ログへのコピー]で,送信ログ,受信ログ,アーカイブログ,配信ログからコピーしたもの・送受信アシスタント機能で自動コピーしたもの・受信ログから未読のファックスをコピーしたもの・自動作成された配信リスト」(甲7の110頁19行目～32行目)⑤「画像データを読み込む 2000 PRO2000 Client他のアプリケーションで作成した画像データを読み込み,ファックスとして送信できます。読み込んだデータはアーカイブログまたは配信ログに保存され,各ログから送信したり,ポーリング受信やWEB閲覧/配信のためのファックス,他ファックスの添付ファイルとして利用できます。・・・■配信ログへ読み込む(クライアント版を除く)1 [ファイル]メニューの[配信ログへの入力]を選択します。 2 読み込むファイルの場所,ファイル名,ファイルの種類を指定し,[開く]ボタンをクリックします。」(甲7の129頁9行目～130頁8行目)⑥「送受信イメージをコピーする 2000 PRO2000 Client送受信したファックスをアーカイブログや配信ログにコピーし,送信ログや受信ログと区別して管理することができます。コピーしたファックスは,アーカイブログまたは配信ログから送信したり,他ファックスの添付ファイルとして利用できます。・・・■配信ログへコピー(クライアント版を除く)1 [ログ]メニューの[配信ログへのコピー]を選択します。 2 ▼ボタンをクリックし,コピー元のログを選択します。コピー元は,アーカイブログ,送信ログ,受信ログ,配信ログから指定できます。 3 リストからコピーするログを選び,[添付リストへ追加]ボタンをクリックします。」(甲7の126頁1行目～127頁10行目)⑦「ルールに関する設定 2000 PRO2000ルールの作成または編集時,対象にするファックスの指定や,どのような処理を自動で行うかを設定します。・・・■条件の設定内容・・・[配信ログに登録]条件に一致したファックスを配信ログに登録します。オンにすると,ファックスが送受信されると同時に配信ログにコピーされ,EasyFaxからの配信やWEB公開用のデータとして利用できるようになります。」(甲2の172頁1行目～173頁10行目)⑧「外部からのポーリング受信に対する設定 2000 PRO2000他のファックス機からポーリング受信の要求がくると,EasyFaxは要求にしたがってファックスを配信します。特に,受信ログに納められたファックスを配信ログにコピーすることによって,受信したファックスを他のファックス機からの操作で取り出すことが可能となります。・・・■配信ログの作成方法・・・●未読受信ファックスを一括して配信ログへ自動登録する[設定]ダイアログの[配信]タブで[未読一括配信を有効にする]をオンにすると,未読受信ファックスがまとめて配信ログのBOX番号9000に自動登録されます。」(甲2の192頁6行目～193頁28行目)⑨「配信に関する設定 2000 PRO2000他のファックス機からポーリング受信に応じて,配信ログ内のどのファックスを送るか,配信に関する設定を行います。また,PRO2000では,配信ログ内のファックスをWEB公開するかどうかなどの設定もできます。 ■通常の設定・[配信]タブ・・・[配信リスト][配信リストを作成]をオンにすると,外部からのポーリング受信に応じて,送信可能なファックスの一覧をBOX番号9999に作成します。外出先でファクスを受信する際,配信ログ内にどのようなファックスが登録されているかを知ることができます。」(甲7の151頁25行目～152頁12行目)b 上記①ないし③の記載から,引用例には「クライアントPCは,サーバーPCのEasyFax配信ログ内のファックスを送信させることができること」が記載されているということができる。 c 次に,上記「EasyFax配信ログ」内のファイルとはどのようなものであるかについて検討すると,まず,上記記載④によれば,引用例において,[編集]-[配信ログへのコピー]で,送信ログ,受信ログからコピーしたものとは,「サーバーPCにおいて送受信されたデータ」であると認められる。また,アーカイブログからコピーしたものとは,「サーバーPCにおいて,当該サーバーPCのユーザによる操作によって登録されたデータ」であるということができる。そして,配信ログが管理するデータに関しては,[ファイル]-[配信ログへの入力]で読み込んだデータについて上記⑤の記載があり,同記載から,引用例において,[ファイル]-[配信ログへの入力]で読み込んだデータとは,「サーバーPCにおいて,当該サーバーPCのユーザによる操作によって登録されたデータ」であるということができる。また,[編集]-[配信ログへのコピー]で,送信ログ,受信ログ,アーカイブログ,配信ログからコピーしたものについての上記⑥の記載,送受信アシスタント機能で自動コピーしたものについての上記⑦の記載から,[編集]-[配信ログへのコピー]で,送信ログ,受信ログからコピーしたものとは,「サーバーPCにおいて送受信されたデータ」であるということができる。さらに,受信ログから未読のファックスをコピーしたものについての上記⑧の記載,自動作成された配信リストについて上記⑨の記載において,外部からのポーリング受信に応じて配信可能なファックスとは,配信ログに登録されているデータであるから,配信リストのデータとは,配信ログに登録されているデータ,すなわち,「サーバーPCにおいて送受信されたデータ」又は「サーバーPCにおいて,当該サーバーPCのユーザによる操作によって登録されたデータ」ということができる。以上によれば,「EasyFax配信ログ」内のファイルとは,「サーバーPCにおいて送受信されたデータ」又は「サーバーPCにおいて,当該サーバーPCのユーザによる操作によって登録されたデータ」であって,「クライアントPCにおいて,送信対象データ作成可能アプリケーションにてプリンタードライバとして選択された自動通信処理プログラムによってサーバに対して送信されたデータ」ではないというべきである。 (ｳ) 以上より明らかなように,引用例には,スタンドアローンシステム及びサーバー-クライアントシステムは記載されているが,「クライアントPCにおいて作成されたデータを,サーバを介して,送信先へファックス送信するという発明」については開示も示唆もなく,引用発明の「クライアントPC」は,本件発明1の「クライアント」に相当するものということはできない。したがって,審決が,引用発明の「クライアントPC」は本件発明1の「クライアント」に相当すると認定したことは誤りであるから,審決の引用発明の認定は誤りである。イ取消事由2(本件発明1と引用発明との一致点・相違点の認定の誤り)(ｱ) 一致点の認定の誤り審決は,本件発明1と引用発明との一致点について,「B)前記クライアントにはプリンタドライバとして,以下のような自動通信処理プログラムがインストールされており,b1)送信対象データ作成可能アプリケーションプログラムにて,作成された送信対象データの出力先を制御するプリンタードライバとして選択されて,送信対象データが出力指定されると,b2)その後,送信先データ作成画面を表示し」(審決16頁第1段落)と認定した。確かに,両者は,「B)前記クライアントにはプリンタドライバとして,以下のような自動通信処理プログラムがインストールされており,b1)送信対象データ作成可能アプリケーションプログラムにて,作成された送信対象データの出力先を制御するプリンタードライバとして選択されて,送信対象データが出力指定される」点では一致するが,本件発明1における自動処理プログラムは,「b2)その後,送信先データ作成画面を表示」するものではない。本件発明1において,自動処理プログラムは,「b2)その後,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動し,定められた送信先データ作成画面データを生成するURIにアクセスさせる」ものである。要するに,当該自動処理プログラムは,「前記クライアントのブラウザプログラムを起動し,(起動したブラウザプログラムを)定められた送信先データ作成画面データを生成するURIにアクセスさせるもの」である。送信先データ作成画面データを生成するURIにアクセスするのはブラウザプログラムであり,当該送信先データ作成画面を表示するのも「ブラウザプログラム」である。このことは,訂正明細書(甲10)の段落【0055】「クライアント100のCPU123は,前記サーバ200への送信が終了すると,ブラウザプログラムに対して,アクセスするURIを指定した立ち上げ命令を与える(ステップS31)」,段落【0057】「サーバ200のCPU23は,かかるアクセス要求に基づいて,要求されたウェブページを送信する(ステップS35)」,段落【0058】「クライアント100は,かかる送信設定画面を受信すると,これを表示する」,【図6】及び【図7】の記載からも明らかである。したがって,審決は,本件発明1と引用発明との一致点の認定を誤り,結果として,相違点の認定も誤り,これにより誤った判断を導いている。 (ｲ) 相違点の認定の誤り審決のように「送信対象データの送信と送信先データ作成画面の表示との順番の観点(相違点1)」及び「送信先データ作成画面の表示処理の内容の観点(相違点2)」から相違点を認定することは誤りである。なぜならば,「送信先データ作成画面の表示処理」を検討するに当たっては,その前に「送信対象データの送信と送信先データ作成画面の表示との順番」を検討する必要があり,更にその前に「送信対象データ及び送信先データの分割送信」について検討する必要がある。すなわち,「送信対象データ及び送信先データの分割送信」の下において,「送信先データ作成画面の表示処理」と「送信対象データの送信と送信先データ作成画面の表示との順番」とが相互に関係しているものである。東京高裁平成8年(行ケ)第310号・平成9年11月18日判決(甲8)の判示するように「各構成要件の比較検討に当っても構成要件相互の関係を考慮すべきであ」り,相互の関係を考慮しないのであれば,一つの相違点として認定すべきである。すなわち,本件発明1と引用発明の相違点は,「本件発明1では,自動処理プログラムが,送信対象データが出力指定されるとサーバに当該送信対象データを送信先の特定されていない送信対象データとして送信し,その後,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動し,起動したブラウザプログラムを定められた送信先データ作成画面データを生成するURIにアクセスさせ,当該ブラウザプログラムが送信先データ作成画面を表示するのに対し,引用発明では,クライアントが,出力指定されると送信先データ作成画面を表示し,その後,送信対象データ送信の送信が行われる点」と認定すべきである。上記相違点には,少なくとも,「本件発明1では,自動処理プログラムが,送信対象データと送信先データとを分割して送信するのに対し,引用発明では,クライアントの自動処理プログラムは,送信対象データと送信先データとを一体として送信する点」,「本件発明1では,自動処理プログラムが,送信先の特定されていない送信対象データを送信した後,ブラウザに送信先データ作成画面を表示させるのに対し,クライアントの自動処理プログラムは,送信先データ作成画面を表示した後,送信対象データと送信先データとを一体として送信する点」及び「本件発明1では,自動処理プログラムが,ブラウザに送信先データ作成画面を表示させるのに対し,クライアントの自動処理プログラムは,自らが送信先データ作成画面を表示する点」が含まれている。そして,かかる相違点について,他の先行技術である甲3刊行物に記載がない以上,引用発明及び甲3刊行物の記載に基づき進歩性がないと判断した審決は,誤りというほかない。ウ取消事由3(本件発明1と引用発明との相違点の看過)(ｱ) 前述したように,本件発明1における自動処理プログラムは,「b2)その後,送信先データ作成画面を表示」するものではない。審決は,本件発明1における「その後,・・・という制約のあるブラウザを起動する」ことが規定されているにもかかわらず,これを看過している。本件発明1と引用発明との相違点は,正しくは,以下の相違点1-A及び相違点1-Bとして認定すべきである。 <相違点1-A>本件発明1では,自動処理プログラムが,送信対象データが出力指定されるとサーバに当該送信対象データを送信先の特定されていない送信対象データとして送信し,その後,ブラウザプログラムを起動し,起動したブラウザプログラムが送信先データ作成画面を表示するのに対し,引用発明では,クライアントが,出力指定されると送信先データ作成画面を表示し,その後,送信対象データ送信の送信が行われる点。 <相違点1-B>本件発明1では,送信先データ作成画面の表示を,自動処理プログラムが,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して,起動したブラウザプログラムを定められた送信先データ作成画面データを生成するURIにアクセスさせることで行うのに対し,引用発明ではこの表示をどのように行うのか具体的な開示がない点。 (ｲ) このように,引用例には,スタンドアローンシステム及びサーバー-クライアントシステムが開示されているのであって,「クライアントPCにおいて作成されたデータを,サーバを介して,送信先へファックス送信するという発明」については開示されておらず,その示唆もない。つまり,引用例には,少なくとも相違点1-Aについては記載がなく,その示唆もない。また,甲3刊行物においても,少なくとも相違点1-Aについては開示されておらず,その示唆もない。したがって,本件発明1は,引用発明及び甲3刊行物に記載された発明に基づき進歩性が否定されることはない。エ取消事由4(相違点についての判断手法の誤り)(ｱ) 審決は,「甲第1号証に記載された発明(判決注:引用発明)を考えれば,アプリケーションプログラムから送り込まれたデータはプリンタドライバにより送信されるから,ブラウザにアプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないという制約があっても何ら阻害要因にはならない」(審決17頁最終段落～18頁第1段落)としているが,誤りである。 (ｲ) 引用例には,送信先を指定する画面で送信対象データを読み込み,送信先が指定されると,送信対象データ及び送信先データを一体として送信することが開示され,他方,甲3刊行物には,送信先を指定する画面を表示する際に汎用ブラウザを用いることが開示されているが,引用発明に甲3刊行物記載の発明を適用した技術を検討すると,当該技術は,「送信先を指定する画面を表示したブラウザで送信対象データを読み込み,送信先が指定されると,ブラウザが送信対象データ及び送信先データを一体として送信するもの」となる。しかし,このような技術は実現不可能である。なぜなら,汎用ブラウザはアプリケーションからデータを受けることができないという制約があるからである。すなわち,汎用ブラウザが送信先を指定する画面を表示した状態で,送信対象データをアプリケーションから読み込もうとしても,送信対象データを読み込むことができず,結果として,送信対象データと送信先データとを一体として送信することはできない。引用発明が,送信対象データと送信先データとを一体として送信するものである以上,引用発明に甲3刊行物記載の発明をそのまま適用することについては明らかな阻害要因が存在することとなる。したがって,このような阻害要因が存在するにもかかわらず,引用発明に甲3刊行物記載の発明をそのまま適用した判断手法は明らかな誤りである。オ取消事由5(相違点についての判断の誤り)(ｱ) 審決は,相違点1について,「データを送信する際に一括して送ることも分割して送ることも,一般に広く行われていること」及び「印刷制御がバックグラウンドで行われること」を理由に,相違点1に当業者が容易に想到し得ると判断した(審決16頁最終段落～17頁第1段落)が,誤りである。審決における「データを分割して送ること」の技術的意味が定かではないが,例えば,ファイルサイズの大きなデータを複数に分割して送信することにせよ,一つのデータを所定の容量のパケットに分けて送信することにせよ,確かにネットワークを用いてデータを送信する際に,データを一括して送ることも分割して送ることも,一般に広く行われているが,一般的なデータの分割送信は,データの内容と送信先を分けて送るというものではなく,当然,送信先を指定することなく送信するものではない。また,ネットワークを用いた印刷を制御する際に,印刷制御をバックグラウンドで行うことも,一般的に広く行われているが,この場合においても,印刷の出力先(多くの場合はプリンタ)を指定することが一般的であり,ここでいうデータの送信先,印刷の出力先とは,データの最終的な到達先と考えられる。すなわち,「データを送信する際に一括して送ることも分割して送ることも,一般に広く行われていること」及び「印刷制御がバックグラウンドで行われること」に基づいて想到できる発明は,「分割した各データにおいて,当該データの最終的な到達先を指定して送信するもの」にすぎず,上記理由によっては,なぜ,①送信対象データと送信先データという複数のデータに分割し,②最終的な各データの送信先ではなく,中間的な送信先であるサーバへ送信し,③さらに,送信対象データを送信した後に送信先データを送信すること,が想到容易ということができるのかは全く不明である。したがって,このように論理的に意味をなさない審決の判断は明らかに誤りである。 (ｲ) また,審決は,相違点2について,「甲第1号証に記載された発明(判決注:引用発明)の送信先データ作成画面の表示機能を甲第2号証(判決注:甲3刊行物)に記載されたブラウザプログラムで行うように設計することは当業者が容易になし得ることである」と判断した(審決17頁第3段落)が,誤りである。そもそも,引用発明に基づき,①送信対象データと送信先データという複数のデータに分割し,②最終的な各データの送信先ではなく,中間的な送信先であるサーバへ送信し,③さらに,送信対象データを送信した後に送信先データを送信すること,が想到容易ということ自体が論理的に意味をなすものではないことは上記(ｱ)のとおりである。したがって,引用例に送信先データ作成画面を表示することが記載されていることに基づき,プログラムを送信対象データと送信先データとの分割送信モジュールと操作機データ表示モジュールとに分割し,当該送信先データ作成画面の表示機能を甲3刊行物に記載されたブラウザプログラムで行うように設計することは当業者が容易になし得るとした判断もまた,論理的意味を有するものとはいえない。したがって,審決の相違点2についての上記判断は,明らかな誤りである。 (ｳ) 仮に審決の相違点1,2についての個々の判断に誤りがないとしても,審決は,相違点1と相違点2との関係を検討せずに進歩性の判断をしている。しかし,前述のように,本件発明1における相違点1及び相違点2は互いに関係するから,相違点1と相違点2との関係を検討した上で,両相違点から得られる作用効果の認定をすべきであり,審決が相違点1と相違点2との関係を考慮せずに進歩性の判断をしたことは誤りである。カ取消事由6(本件発明2～13についての判断の誤り)本件発明2は,本件発明1の「送信先データ作成画面」を「送信先データ入力画面」に置き換えて,本件発明1のシステムを構成するクライアントを示すものである。本件発明3ないし本件発明9は,本件発明1の従属発明である。本件発明10は,本件発明2の「プリンタドライバ」を「コンピュータ可読のプログラム」とした表現したものである。本件発明11は,本件発明1の「送信先データ作成画面データ」を「その送信先データを入力する画面を表示する画面データ」に,また,「URI」を「リソース識別子」に,それぞれ置き換えて方法としたものである。本件発明12は,実質的に本件発明11におけるファクシミリ送信方法におけるクライアントに関する方法を示すものである。本件発明13は,本件発明11における「ファクシミリ送信」を「データ転送」と置き換えた,本件発明11におけるサーバーに関する方法を示すものである。したがって,本件発明1についての上記取消事由1ないし5と同様の理由により,審決の本件発明2～13についての判断は,誤りである。 2 請求原因に対する認否請求原因(1)ないし(3)の各事実はいずれも認めるが,(4)は争う。 3 被告の反論審決の認定判断は正当であり,原告主張の取消事由はいずれも理由がない。 (1) 取消事由1(引用発明の認定の誤り)に対しア引用例(甲2)の56頁～60頁には,アプリケーションプログラムが表示されている状態でそのファイルの出力先を制御するプリンタ名として「EasyFax」(プリンタドライバ)が選択され,次に送信対象データとして印刷範囲が指定され,更に「送信」ボタンがクリックされると送信を開始することが記載され,60頁の「10 [送信]ボタンをクリックします」という記載の後には「・・・クライアント版では,ファックスはサーバー経由で指定した送信先に送信されます」と記載されている。これらの記載によれば,引用例には「アプリケーションで作成したデータをクライアントPC上のクライアント版からサーバーPCを経由してファックスを送信するシステムであって,クライアントPC上のクライアント版はアプリケーションでプリンタドライバとして設定されており,印刷範囲を指定して[OK]ボタンクリックすると,[FAX送信]ダイヤログが表示され,ここで送信先を指定して[送信]ボタンをクリックすると指定した送信先に送信されるシステム」が開示されていることは明らかである。原告は,審決が摘示する引用例の記載アないしオのうち記載オの内容だけに基づいて開示内容を限定的に解釈している。しかし,記載オは,サーバ側で配信ログとして登録されているデータをクライアント側からの指示に応じてファックス送信するという,EasyFax2000のサービスの一部を説明したものにすぎないから,この記載のみに基づいて開示内容を矮小化して判断することは不当である。原告は,審決が摘示する引用例の記載アないしエ(審決11頁～12頁)に基づき,「スタンドアローンシステム」が記載されていることは認めるとしているが,記載エを参照すると,引用例の「クライアント版では,ファックスはサーバー経由で指定された送信先に送信されます」という記載が引用されている。原告のいう「スタンドアローンシステム」という用語の意味が「サーバーの機能を使わずにクライアントのみの機能によってファックス送信するシステム」という意味であるならば,記載アないしエには,このスタンドアローンシステムのみならず,クライアントからサーバを介して(サーバの機能を利用して)ファックス送信するシステムも開示されているのであるから,原告の上記主張は引用例の記載内容に基づかないものである。 (2) 取消事由2(本件発明1と引用発明との一致点・相違点の認定の誤り)に対しア原告の主張は,要するに,本件発明1において送信先データ作成画面を表示する直接の主体が「ブラウザプログラム」であるのに対し,引用発明においては,送信先データ作成画面を表示する直接の主体が「プリンタドライバ(本件発明1における自動処理プログラム)」である点で両者は相違している,というものである。しかし,この点については,審決も両者の相違点であることを認めている。すなわち,審決は,相違点2として,「本件特許発明1では,送信先データ作成画面の表示を,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して,定められた送信先データ作成画面データを生成するURIにアクセスさせることで行うのに対し,甲第1号証記載の発明ではこの表示をどのように行うのか具体的な開示がない点」を摘示し,この相違点2は,「表示主体となるプログラムが相違している」という原告の主張と同じ相違点を指摘するものである。さらに,審決は,「送信先データ作成画面の表示が通常のプリンタドライバに無い付加的な機能である」と記載されているように,送信先データ作成画面を表示する主体が本件発明1と引用発明とでは相違していることを認めており,その上で相違点の内容に基づいて本件発明1の進歩性について論じている。このように,原告が主張している本件発明1と引用発明の相違点は,審決によって相違点として指摘され,さらにその相違点の内容に基づいて本件発明1の進歩性が検討された上で,進歩性がないとの判断に至っているものである。イまた,原告は,「送信対象データの送信と送信先データ作成画面の表示との順番」の前に,「送信対象データ及び送信先データの分割送信」について検討すべきである旨主張する。しかし,この点は審決においても既に検討されている事項である。すなわち,審決は,相違点1として,「本件特許発明1では,送信対象データが出力指定されるとサーバに当該送信対象データを送信先の特定されていない送信対象データとして送信し,その後,送信先データ作成画面を表示するのに対し,引用発明では,出力指定されると送信先データ作成画面を表示しその後送信が行われる点」が認定しており,送信対象データと送信先データとが分割して送信される点で本件発明1が引用発明とは相違していることが指摘されている。さらに,審決は,この相違点1について,周知技術(常とう手段)を踏まえた上でその進歩性が検討されている。このように,審決においては,「送信対象データ及び送信先データの分割送信」について検討済みであり,原告の上記主張は,審決の検討内容を踏まえておらず,失当である。ウさらに,原告は,「構成要件相互の関係を考慮することなく相違点を認定した審決は違法なものとして取り消されるべきであるべきである」と主張する。確かに,発明の構成要件相互の関係を考慮すべきことは,各構成要件の比較検討に当たって必要な事項である。しかし,審決は,「データを送信する際に一括して送信することも分割して送ることも,一般的には広く行われていることである」として,送信対象データと送信先データの分割送信という技術について述べているが,そもそも分割送信という技術事項は,本件発明1の構成要件b1,b2及びCの相互の関係を考慮して初めて把握されるものであるから,この点からも明らかなように,審決は構成要件相互の関係について十分に検討しているものであり,原告の主張は失当である。 (3) 取消事由3(本件発明1と引用発明との相違点の看過)に対しア原告の主張するような相違点としてとらえたとしても,本件発明1は,引用発明,甲3刊行物記載の発明,甲4刊行物記載の発明に基づいて当業者が容易に想到し得たものである。イすなわち,上記(1)で述べたように,引用例には,クライアントPCにおいて作成されたデータを,サーバを介して,送信先へファックス送信するという発明について開示されている。また,引用例では,プリンタドライバでクライアントからサーバに送信対象データを送信するという技術や,クライアントのブラウザプログラムで表示された画面で送信先を指定するという技術が開示されており,甲3刊行物には,アプリケーションプログラムがブラウザプログラムを起動してURLにアクセスさせることが記載されている。甲3刊行物には,ブラウザプログラムと連携処理を行うアプリケーションプログラムの一例として,発注業務を行うプログラムが開示されているが,これ以外のアプリケーションプログラムをブラウザプログラムと連携させることを意識的に除外する記載はないから,引用発明のプリンタドライバにおいて送信先データ作成画面の表示機能をつかさどるプログラムとして,甲3刊行物に開示されたブラウザプログラムを適用することを阻害する要因はなく,また,一般にそのような複数のプログラム間の連携処理の設計は当業者にとって容易である。また,送信対象データと送信先データとを分割して送信する点に関しては引用例のみならず甲4刊行物にも開示ないし示唆されている。したがって,本件発明1は,引用発明,甲3刊行物記載の発明,甲4刊行物記載の発明に基づいて当業者が容易に想到し得たものということができる。 (4) 取消事由4(相違点についての判断手法の誤り)に対しア原告は,引用例には,送信先を指定する画面で送信対象データを読み込み,送信先が指定されると,送信対象データ及び送信先データを一体として送信することが開示されており,一方,甲3刊行物には,送信先を指定する画面を表示する際に汎用ブラウザを用いることが開示されているところ,引用発明に甲3刊行物記載の発明を適用した技術を検討すると,当該技術は,「送信先を指定する画面を表示したブラウザで送信対象データを読み込み,送信先が指定されると,ブラウザが送信対象データ及び送信先データを一体として送信するもの」となると主張する。しかし,審決は,「表示機能を実現する際にURI(URL)を指定してブラウザプログラムに行わせることは甲第2号証(判決注:甲3刊行物)に記載されているから,甲第1号証に記載された発明(判決注;引用発明)の送信先データ作成画面の表示機能を甲第2号証に記載されたブラウザプログラムで行うように設計することは当業者が容易になし得ることである」(審決17頁第3段落)とし,引用発明の「送信先データ作成画面の表示機能部分」に限って甲3刊行物に記載の表示技術を適用した場合について論じている。原告の上記主張は,引用発明における「送信対象データの送信機能部分」にブラウザを適用して主張するものであって,審決で示された判断内容と異なる事項に対するものである。イまた,原告は,ブラウザにアプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないという制約は,引用発明に甲3刊行物記載の発明を適用する際の阻害要因になる旨主張する。しかし,前述したように,審決は引用発明の表示機能部分に限って甲3刊行物に記載の表示技術を適用した場合を論じているのであり,その適用を阻害する合理的な理由は見当たらない。したがって,阻害要因が存在する旨の原告の主張は失当である。 (5) 取消事由5(相違点についての判断の誤り)に対しア原告は,本件特許出願前の周知技術(常とう手段)に基づいて,①送信対象データと送信先データという複数のデータに分割し,②最終的な各データの送信先ではなく,中間的な送信先であるサーバへ送信し,③さらに,送信対象データを送信した後に送信先データを送信すること,を容易に想到することはできない旨を主張するが,上記①ないし③は,次に述べるとおり,本件特許出願前の周知技術(常とう手段)に基づいて当業者が容易に想到し得る範囲のものである。イ引用例には,クライアントからサーバに送信対象ファイルと送信先データとを合わせて送信する際の態様として,送信対象ファイルの送信先をあらかじめ指定し,サーバを介してそのファイルを送信先に送信するという「第1の送信系統」(引用例(甲2)の56頁～60頁)と,送信対象ファイルの送信先を特定せずにサーバに送信対象ファイルを送り,その後にクライアントによって指定された送信先にサーバからそのファイルを送信するという「第2の送信系統」(同169頁～173頁及び209～212頁)とが開示されている。ここで,クライアントからサーバに送信対象ファイルを送信した時点で,第1の送信系統における送信先が特定されていたとしても,第2の送信系統においてはその送信先は何ら特定されていないから,第2の送信系統に着目すると,引用例には,送信先と送信対象データを分割してサーバに送信することと共に,送信対象データを送信した後に送信先データを送信するという各データの送信順序も開示されている。また,甲4刊行物においても,まず最初にクライアントからローカルネットワークを介してサーバに文書を送信しておき,次にクライアントからサーバに送信先データを送信する,という構成が開示されている(段落【0005】～【0006】)。甲4刊行物では,クライアントからローカルネットワークを介してサーバにあらかじめ文書を送信しておき,その後でクライアントから文書を指定するとともにその送信先を指定するというものであるが,「まず送信対象データを中間的な送信先であるサーバへ送信しておき,その送信対象データを送信した後に,送信先データを送信する」という発想そのものは,甲4刊行物に十分に開示されているというべきであり,これは,上記①ないし③と同様の内容である。ウさらに,原告は,審決は相違点1と相違点2との関係を検討せずに進歩性の判断を行っている旨主張する。しかし,審決が構成要件相互の関係について十分に検討していることは,上記(2)ウで述べたとおりである。また,仮に原告の主張するようにこれを一つの相違点としてとらえたとしても,本件発明1は,引用発明,甲3刊行物記載の発明,甲4刊行物記載の発明に基づいて当業者が容易に想到し得たものであることは,上記(3)で述べたとおりである。 (6) 取消事由6(本件発明2～13についての判断の誤り)に対し本件発明1に対する審決に誤りはないことは上記(1)ないし(5)に述べたとおりであるから,同様の理由により,本件発明2ないし13に対する審決にも誤りはない。
当裁判所の判断 1 請求原因(1)(特許庁等における手続の経緯),(2)(発明の内容),(3)(審決の内容)の各事実は,いずれも当事者間に争いがない。そこで,以下においては,審決の適否につき,原告主張の取消事由ごとに判断する。 2 取消事由1(引用発明の認定の誤り)について(1) 原告は,引用例には「クライアントPCにおいて作成されたデータを,サーバを介して,送信先へファックス送信するという発明」については開示も示唆もなく,したがって,引用例には,「アプリケーションで作成したデータをクライアントPC上のクライアント版からサーバーPCを経由してファックスを送信するシステムであって,クライアントPC上のクライアント版はアプリケーションでプリンタドライバとして設定されており,印刷範囲を指定して[OK]ボタンをクリックすると,[FAX送信]ダイアログが表示され,ここで送信先を指定して[送信]ボタンをクリックすると指定した送信先に送信されるシステム」についての発明(引用発明)が記載されているということはできず,引用発明の「クライアントPC」は,本件発明1の「クライアント」に相当するものということはできないと主張する。 (2) そこで,引用例の記載を見ると,引用例(甲2)には次の記載がある。ア(「はじめに」のi頁23行目～27行目)イ「アプリケーションから送る 2000 PRO2000 ClientWindowsのアプリケーションで作成したデータをEasyFaxから送信してみましょう。プリンタの代わりにEasyFaxを利用して,アプリケーションで作成したデータを送信する仕組みになっています。・・・1 アプリケーションで送信したいファイルを開きます。 2 [ファイル]メニューの[印刷]を選び,[プリンタ名]に「AISOFTEasyFax (95/98)」または「AISOFT EasyFax (NT40)」が設定されていることを確認します。・・・本マニュアルでは,サーバー・クライアントで利用できる機能については,次のマークを使用しています。お使いの環境に合わせてお読みください。 2000 :EasyFax 2000で利用できる機能です。 PRO 2000:EasyFax PRO2000で利用できる機能です。 Client :クライアント版で利用できる機能です。 3 印刷範囲を指定し,[OK]ボタンをクリックします。 [FAX送信]ダイアログが表示されます。「EasyFaxマネージャから送る」で説明した[FAX送信]ダイアログと同じものです。ダイアログ内の各項目については,「EasyFaxマネージャから送る(P.48)やヘルプを参照してください。・・・5 ファックスを送る相手をクリックします。指定した相手の氏名とファックス番号が,[送信先]や[FAX番号]に表示されます。・・・10[送信]ボタンをクリックします。 [表示]サブウィンドウが閉じて送信を開始します。送信中は,送信状況を表す[送信ステータス]ダイアログが表示されます。クライアント版では,ファックスはサーバー経由で指定した送信先に送信されます。送信先には,コメント入りの表紙とアプリケーションで作成したデータが送られます。送信後のファックスの確認や表示,削除などは「送信ログ」で管理します。→「送信ログを確認する(P.73)」参照」(甲2の56頁1行目～61頁3行目)(3) 上記記載イの冒頭右肩には「Client」との表示があるから,上記アの記載から,記載イの説明はクライアント版においても有する機能に係るものであると認められる。そして,記載イには,①アプリケーションプログラムが表示されている状態(上記イの1)で,②そのファイルの出力先を制御するプリンタ名として「EasyFax」が選択され(上記イの2),③次に送信対象データとして印刷範囲が指定され(上記イの3),④[送信]ボタンをクリックすると,指定した送信先に送信される(上記イの5,10),ことが記載されていることは,その記載自体から明らかである。そうすると,引用例には,「アプリケーションで作成したデータをクライアントPC上のクライアント版からサーバーPCを経由してファックスを送信するシステムであって,クライアントPC上のクライアント版はアプリケーションでプリンタドライバとして設定されており,印刷範囲を指定して[OK]ボタンをクリックすると,[FAX送信]ダイアログが表示され,ここで送信先を指定して[送信]ボタンをクリックすると指定した送信先に送信されるシステム」の発明が記載されているとの審決の認定は正当なものと認められる。原告の主張は,引用例の「6.3 WEB閲覧/配信機能」(甲2の207頁1行目～6行目),「ブラウザを使って閲覧,配信する」(甲2の209頁6行目～12行目),「ファックスを受信する」(甲2の210頁1行目～211頁4行目),「配信ログ」(甲7の110頁19行目～32行目),「画像データを読み込む」(甲7の129頁9行目～130頁8行目),「送受信イメージをコピーする」(甲7の126頁1行目～127頁10行目)の各項目の記載を根拠とするもののようであるが,これらの項目は,「EsasyFax」のサービス内容のうち,サーバ側で配信ログとして登録したデータをクライアント側の指示に応じてファックス送信するサービスについて説明するものであり,引用例に開示された事項が上記内容に限定されるものとする理由はないから,これら記載内容は上記の引用発明の認定の妨げとはならない。 (4) 以上のとおり,審決の引用発明の認定に誤りはなく,原告主張の取消事由1は理由がない。 3 取消事由2(本件発明1と引用発明との一致点・相違点の認定の誤り)について(1) 一致点の認定の誤りにつきア原告は,審決は,本件発明1と引用発明との一致点について,「B)前記クライアントにはプリンタドライバとして,以下のような自動通信処理プログラムがインストールされており,b1)送信対象データ作成可能アプリケーションプログラムにて,作成された送信対象データの出力先を制御するプリンタードライバとして選択されて,送信対象データが出力指定されると,b2)その後,送信先データ作成画面を表示し」(審決16頁第1段落)と認定しているが,本件発明1においては,自動処理プログラムは,「b2)その後,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動し,定められた送信先データ作成画面データを生成するURIにアクセスさせる」もの,すなわち,当該自動処理プログラムは,「前記クライアントのブラウザプログラムを起動し,(起動したブラウザプログラムを)定められた送信先データ作成画面データを生成するURIにアクセスさせるもの」であることを理由に,本件発明1における自動処理プログラムは,「b2)その後,送信先データ作成画面を表示」するものではないと主張する。イしかし,審決は,前記のように,本件発明1と引用発明との一致点について,「B)前記クライアントにはプリンタドライバとして,以下のような自動通信処理プログラムがインストールされており,b1)送信対象データ作成可能アプリケーションプログラムにて,作成された送信対象データの出力先を制御するプリンタードライバとして選択されて,送信対象データが出力指定されると,b2)その後,送信先データ作成画面を表示し」とした上で,両者の相違点2として,「本件発明1では,送信先データ作成画面の表示を,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して,定められた送信先データ作成画面データを生成するURIにアクセスさせることで行うのに対し,引用発明ではこの表示をどのように行うのか具体的な開示がない点」を挙げているのであるから,審決は,本件発明1の「前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動し,定められた送信先データ作成画面データを生成するURIにアクセスさせる」との構成は,「送信先データ画面を表示する」ものに包含され,当該上位概念を構成とする点において引用発明と異ならないから,「送信先データ画面を表示する」という上位概念のレベルにおいて両者は一致するとの認定をしていることが理解できる。そして,具体的な構成を離れて上位の構成のレベルで発明が把握でき,当該上位概念のレベルで本件発明と引用発明が一致するときは,これを一致点として認定することを妨げないところ,原告主張に係る本件発明1の「前記クライアントのブラウザプログラムを起動し,(起動したブラウザプログラムを)定められた送信先データ作成画面データを生成するURIにアクセスさせるもの」との構成は,「送信先データ画面を表示する」ものに包含されるというべきであるから,審決の一致点の認定に誤りはない。 (2) 相違点の認定の誤りにつきア原告は,本件発明1と引用発明との相違点について,「送信対象データ及び送信先データの分割送信」の下において,「送信先データ作成画面の表示処理」と「送信対象データの送信と送信先データ作成画面の表示との順番」とは相互に関係しているから,各構成要件の比較検討に当たっては構成要件相互の関係を考慮すべきであり,あるいは全体を一つの相違点として認定すべきであるとし,審決のように,相違点を「送信対象データの送信と送信先データ作成画面の表示との順番の観点(相違点1)」及び「送信先データ作成画面の表示処理の内容の観点(相違点2)」から認定することは誤りであると主張する。イ確かに,相違点は,技術的にまとまりのある構成が複数認識できるときは,便宜的に複数のものとして認定するのが普通であるが,観点により異なる切り分けがあり得ること,また,構成要件が互いに関連しているものであるときは,各構成要件の比較検討に当たっても構成要件相互の関係を考慮すべきであることは原告指摘のとおりである。そこで,審決の相違点の認定ついて,原告主張の誤りがあるか否かについて検討すると,審決は,本件発明1と引用発明との相違点として,前記のとおり,<相違点1>「本件発明1では,送信対象データが出力指定されるとサーバに当該送信対象データを送信先の特定されていない送信対象データとして送信し,その後,送信先データ作成画面を表示するのに対し,引用発明では,出力指定されると送信先データ作成画面を表示しその後送信が行われる点」及び<相違点2>「本件発明1では,送信先データ作成画面の表示を,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して,定められた送信先データ作成画面データを生成するURIにアクセスさせることで行うのに対し,引用発明ではこの表示をどのように行うのか具体的な開示がない点」の2点を認定している。このうち,相違点1は,「送信対象データの送信と送信先データ作成画面の表示との順番」についてのものであり,相違点2は,「送信先データ作成画面の表示処理の内容」についてのものであるが,それぞれ技術的なまとまりをもった構成であり,かつ,一致点の構成(その認定に誤りがないことは上記(1)のとおりである。)を相違点1及び相違点2の構成で補充すると本件発明1の構成要件に至ることは,その記載自体から明らかであり,上記各相違点の認定自体に誤りはない。また,両相違点の相互の関係については,①相違点1の構成とすること,②相違点2の構成とすること,の想到容易性の検討に加えて,③両者の構成を採用することの想到容易性の検討をすれば足りるものというべきである。そして,審決は上記①ないし③のいずれの点についても検討を行っており,その検討に誤りのないことも後記5,6のとおりである。したがって,審決の相違点の認定に原告主張の誤りはない。 (3) 以上のとおり,審決の一致点・相違点の認定に誤りはなく,原告主張の取消事由2は理由がない。 4 取消事由3(本件発明1と引用発明との相違点の看過)について原告は,本件発明1における自動処理プログラムは,「b2)その後,送信先データ作成画面を表示」するものではないから,審決は,本件発明1における「その後,・・・という制約のあるブラウザを起動する」ことが規定されているにもかかわらず,これを看過した誤りがあると主張する。しかし,本件発明1における自動処理プログラムが「その後,・・・という制約のあるブラウザを起動する」ものであることは,【請求項1】のb2)に「その後,前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して」と記載されるとおりであるが,このうち「その後,・・・」の点は相違点1として,「前記クライアントの,アプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないブラウザプログラムを起動して」の点は相違点2として,審決が認定していることは,審決の相違点の認定(上記第3の1(3)イ)の記載から明らかであり,また,上記各相違点の認定自体に誤りはないことは,上記3(2)のとおりである。したがって,審決に相違点の看過はなく,原告主張の取消事由3は理由がない。 5 取消事由4(相違点についての判断手法の誤り)について(1) 原告は,引用発明は,送信対象データと送信先データとを一体として送信するものであり,他方,甲3刊行物に記載された汎用ブラウザはアプリケーションからデータを受けることができないという制約があるから,引用発明に甲3刊行物に記載された送信先を指定する画面の表示に汎用ブラウザを用いる技術をそのまま適用することについて明らかな阻害要因が存在するところ,阻害要因がないとしてこれをそのまま適用した審決の判断手法は誤りであると主張する。 (2) そこで,検討すると,引用発明においては,クライアントからサーバに送信対象ファイルと送信先データとを合わせて送信しているが,送信先データは,サーバから送信対象ファイルを指定された送信先に送るために必要とされるものであって,送信対象ファイルを指定された送信先に送信する時点において送信対象ファイルと関連付けられていればよく,送信先データと送信対象ファイルを常時一体のものとして扱う必要はないことが明らかである。このことは,後述するように,甲4刊行物に,あらかじめ送信対象データ(文書データ)をクライアントからサーバに送信しておき,次にクライアントで送信先と送信対象データ(文書データ)を指定すると,既に送信しておいた送信対象データ(文書データ)がサーバから指定された送信先へと送信されるようになされた構成が記載されていることからも裏付けられる。そして,甲3刊行物には,送信先を指定する画面の表示に汎用ブラウザを用いる技術が開示されているのであるから,送信先データ作成画面の表示に汎用ブラウザを採用することに技術上の阻害要因があるとは認められない。そもそもプリンタドライバはアプリケーションから送り込まれたデータを自由に転送できるようにされているのであるから,ブラウザがアプリケーションから送り込まれたデータを受け取って送信するように設計されていないとしても,このことは,送信先データ作成画面の表示をどのように行うか具体的な開示のない引用発明において,本件発明1のようにその送信先データ作成画面の表示機能の部分にブラウザを適用する構成とすることを何ら阻害するものではない。以上のとおりであるから,引用発明に甲3刊行物記載の送信先を指定する画面の表示に汎用ブラウザを用いる技術をそのまま適用することについて明らかな阻害要因が存在するということはできず,「甲第1号証(判決注:引用例)に記載された発明を考えれば,アプリケーションプログラムから送り込まれたデータはプリンタドライバにより送信されるから,ブラウザにアプリケーションプログラムから送り込まれたデータを受け取って当該データを送信することができないという制約があっても何ら阻害要因にはならない」(審決17頁最終段落～18頁第1段落)とした審決に誤りはない。したがって,審決に相違点についての判断手法の誤りはなく,原告主張の取消事由4は理由がない。 6 取消事由5(相違点についての判断の誤り)について(1) 原告は,①送信対象データと送信先データという複数のデータに分割し,②最終的な各データの送信先ではなく,中間的な送信先であるサーバへ送信し,③さらに,送信対象データを送信した後に送信先データを送信すること,が想到容易ということができるのかは全く不明であるから,審決の相違点1についての判断は誤りであると主張する。 (2) 甲4刊行物には,クライアント・サーバ型ファクシミリシステムの構成を示すブロック図である【図1】とともに,次の記載がある。ア「【請求項1】ローカルエリアネットワークと網との通信を制御するサーバ手段を有したサーバ型フアクシミリシステムにおいて,前記サーバ手段は,前記ローカルエリアネットワークからの受け取った複数の送信文書を蓄積する蓄積手段と,前記蓄積手段で蓄積中の一送信文書及び該一送信文書の送信先情報の指示を受け付ける受け付け手段と,前記受け付け手段で受け付けた指示に従って前記一送信文書のデータフォーマットを前記送信先情報に基づく送信先のデータフォーマットに変換制御する変換制御手段と,前記変換制御手段の変換制御によって得られたデータフォーマットの送信文書を送信する送信手段とを備えることを特徴とするサーバ型フアクシミリシステム。」イ「【0001】【産業上の利用分野】本発明はサーバ型フアクシミリシステムに関し,例えば相手先端末指定方法に関するものである。【0002】【従来の技術】従来のFAX(フアクシミリ)送信のうち,少なくとも1つのクライアント端末と,LAN(ローカルエリアネットワーク)でつながつたフアイルを蓄積する蓄積機能を有するサーバ装置と公衆網とFAXとをつないだクライアント・サーバ型フアクシミリシステムでは,ユーザの使用するクライアント端末より相手先を入力し,サーバ装置にある送信可能なフアクシミリを選び送信するものであつた。これによりパソコン(パーソナルコンピュータ),または,ワークステーシヨン上で作られたフアイルを送信することが出来るといつた利点がある。」ウ「【0005】【課題を解決するための手段】上述した課題を解決し,目的を達成するため,本発明に係るサーバ型フアクシミリシステムは,ローカルエリアネットワークと網との通信を制御するサーバ手段を有したサーバ型フアクシミリシステムにおいて,前記サーバ手段は,前記ローカルエリアネットワークからの受け取った複数の送信文書を蓄積する蓄積手段と,前記蓄積手段で蓄積中の一送信文書及び該一送信文書の送信先情報の指示を受け付ける受け付け手段と,前記受け付け手段で受け付けた指示に従って前記一送信文書のデータフォーマットを前記送信先情報に基づく送信先のデータフォーマットに変換制御する変換制御手段と,前記変換制御手段の変換制御によって得られたデータフォーマットの送信文書を送信する送信手段とを備えることを特徴とする。【0006】【作用】かかる構成によれば,サーバ手段は,蓄積手段によってローカルエリアネットワークからの受け取った複数の送信文書を蓄積し,受け付け手段は蓄積手段で蓄積中の一送信文書及び一送信文書の送信先情報の指示を受け付け,変換制御手段は受け付け手段で受け付けた指示に従って一送信文書のデータフォーマットを送信先情報に基づく送信先のデータフォーマットに変換制御し,送信手段は変換制御手段の変換制御によって得られたデータフォーマットの送信文書を送信する。」(3) 上記アないしウの記載によれば,甲4刊行物には,クライアントからローカルネットワークを介してサーバにあらかじめ文書(送信対象データ)を送信しておき,その後,クライアントからサーバに送信先データを送信することにより,最終的に送信先に文書をファクシミリ送信するという技術が開示されていると認められる。そうすると,甲4刊行物には,原告のいう①送信対象データと送信先データという複数のデータに分割し,②最終的な各データの送信先ではなく,中間的な送信先であるサーバへ送信し,③さらに,送信対象データを送信した後に送信先データを送信すること,が開示されていることが明らかである。したがって,審決の相違点1についての判断に原告主張の誤りはない。 (4) また,原告は,相違点1についてと同様の理由により,審決の相違点2についての判断も誤りであると主張するが,相違点1についての原告の上記主張に理由がないことは上記(2),(3)のとおりである。したがって,審決の相違点2についての判断にも原告主張の誤りはない。 (5) 以上のとおり,審決の相違点についての判断に誤りはなく,原告主張の取消事由5は理由がない。 7 取消事由6(本件発明2～13についての判断の誤り)について原告は,本件発明1についての上記取消事由1ないし5と同様の理由により,審決の本件発明2～13についての判断は誤りであると主張する。しかし,原告主張の取消事由1ないし5に理由がないことは,上記2ないし6のとおりであるから,原告主張の取消事由6も理由がない。 8 以上のとおり,原告主張の取消事由はいずれも理由がない。よって,原告の本訴請求は理由がないからこれを棄却することとして,主文のとおり判決する。

裁判長裁判官	中野哲弘
裁判官	岡本岳
裁判官	上田卓哉

すごい知財EXPO'22

ページ上部へ