令和1(ワ)21901 特許権侵害損害賠償請求事件

令和４年５月３１日判決言渡同日原本領収裁判所書記官令和元年（ワ）第２１９０１号特許権侵害損害賠償請求事件口頭弁論終結日令和４年２月１８日判決 原告株式会社サピエンス（以下「原告サピエンス」という。） 原告プラグインフリー・パテント・ホールディング株式会社（以下「原告プラグインフリー」という。） 上記両名訴訟代理人弁護士山本純平木内加奈子西阪裕 同訴訟代理人弁理士木内光春 旧商号ヤフー株式会社被告Ｚホールディングス株式会社 同訴訟代理人弁護士大野聖二小林英了木村広行同訴訟代理人弁理士松野知紘 主文 １ 原告らの請求をいずれも棄却する。 ２ 訴訟費用は原告らの負担とする。 事実及び理由 第１ 請求 １ 被告は、原告サピエンスに対し、６６００万円及びこれに対する令和元年８月２８日から支払済みまで年５分の割合による金員を支払え。 ２ 被告は、原告プラグインフリーに対し、１億３２００万円及びこれに対 、原告サピエンスに対し、６６００万円及びこれに対する令和元年８月２８日から支払済みまで年５分の割合による金員を支払え。 ２ 被告は、原告プラグインフリーに対し、１億３２００万円及びこれに対する令和元年８月２８日から支払済みまで年５分の割合による金員を支払え。 第２ 事案の概要本件は、発明の名称を「画像表示方法」とする発明に係る特許（特許第４０５９８０２号。以下「本件特許」といい、本件特許に係る特許権を「本件特許 権」という。）の特許権者であった原告サピエンス及び本件特許の特許権者である原告プラグインフリーが、被告が配信するＨＴＭＬ及びJavaScript のソースプログラム及び地図画像のデータ等（以下、これらを総称して「被告地図プログラム」という。）によりＷｅｂブラウザに地図を表示させる方法（以下「被告地図表示方法」という。）が本件特許に係る発明の技術的範囲に属する ものであり、被告による被告地図プログラムの配信は、本件特許権の間接侵害（特許法１０１条４号）に該当すると主張して、被告に対し、不法行為に基づき、原告サピエンスにあっては６６００万円（特許法１０２条３項の損害金２０億円の一部６０００万円及び弁護士費用６００万円の合計額）、原告プラグインフリーにあっては１億３２００万円（同項の損害金４０億円の一部１億２ ０００万円及び弁護士費用１２００万円の合計額）及びこれらに対する訴状送達の日である令和元年８月２８日から支払済みまで民法（平成２９年法律第４４号による改正前のもの）所定の年５分の割合による遅延損害金の支払を求める事案である。 なお、当裁判所は、本件事案に鑑み、画像表示方法に関する専門的知見を有 する専門委員３名を選任の上、民訴法９２条の２に基づき、技術説明会におい の支払を求める事案である。 なお、当裁判所は、本件事案に鑑み、画像表示方法に関する専門的知見を有 する専門委員３名を選任の上、民訴法９２条の２に基づき、技術説明会におい て上記専門的知見に基づく説明を口頭でさせている。 １ 前提事実（当事者間に争いがない事実並びに後掲証拠及び弁論の全趣旨により認定できる事実をいう。なお、本判決を通じ、証拠を摘示する場合には、特に記載しない限り、枝番を含むものとする。）当事者 ア原告サピエンスは、情報処理装置、電子電気機器及びそれに付随するソフトウェアの研究開発並びに製造販売等を目的とする株式会社である（弁論の全趣旨）。 イ原告プラグインフリーは、特許権の保有、利用、使用許諾及びそれに関連する業務並びに電子通信分野における研究開発等を目的とする株式会社 である（弁論の全趣旨）。 ウ被告は、インターネット上の広告事業、イーコマース事業及び会員サービス事業等を目的とする株式会社である。 本件特許権ア原告サピエンスは、平成１９年１２月２８日、以下の特許権の設定の登 録を受けた（以下、本件特許の願書に添付された明細書及び図面を「本件明細書等」という。甲１、２）。 発明の名称：画像表示方法特許番号：特許第４０５９８０２号出願日：平成１５年４月１７日（特願２００３－１１２９９８） イ原告プラグインフリーは、平成２７年２月９日、本件特許権の移転の登録を受け、原告サピエンスから本件特許権を取得した（甲１）。 本件特許に係る特許請求の範囲本件特許に係る特許請求の範囲の記載は、以下のとおりである（甲２）。 ア請求項１（以下「本件発明１」という。） 「Ｗｅｂブラウザの画像を表示する表示領域 に係る特許請求の範囲本件特許に係る特許請求の範囲の記載は、以下のとおりである（甲２）。 ア請求項１（以下「本件発明１」という。） 「Ｗｅｂブラウザの画像を表示する表示領域よりも大きい画像を分割し 該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像表示方法において、Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して 限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の 移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示で きる状態にする画像表示方法。」イ請求項２１（以下「本件発明２１」といい、本件発明１と併せて「本件各発明」という。）「前記Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される請求項１から２０のいずれかに記載の画 像表示方法。」本件各発明の構成要件本件各発明を構成要件に分説すると、以下 ーバから送信されるJavaScript（登録商標）に基づき実行される請求項１から２０のいずれかに記載の画 像表示方法。」本件各発明の構成要件本件各発明を構成要件に分説すると、以下のとおりである。 ア本件発明１１ＡＷｅｂブラウザの画像を表示する表示領域よりも大きい画像を分 割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像を サーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像表示方法において、１ＢＷｅｂブラウザの表示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に 当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、１Ｃ－１ Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべ き位置を演算して該位置に枠要素を移動し、１Ｃ－２ 該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素 に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする１Ｄ 画像表示方法。 イ本件発明２１２１Ａ 前記Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScr ipt（登録商標）に基づき実行される２１Ｂ 請求項１に記載の画像表示 画像表示方法。 イ本件発明２１２１Ａ 前記Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScr ipt（登録商標）に基づき実行される２１Ｂ 請求項１に記載の画像表示方法。 被告地図プログラムの配信被告は、被告管理のウェブページ（http://map.yahoo.co.jp、https://map.yahoo.co.jp）及びＷｅｂＡＰＩ「Yahoo! JavaScript マップＡＰＩ」を利 用したウェブページにＷｅｂブラウザを通じてアクセスしたユーザの利用端 末に、被告管理のサーバから、ＨＴＭＬ及びJavaScript のソースプログラム及び地図画像のデータ等（被告地図プログラム）を配信し、地図情報（被告管理のウェブサイトでの名称は、「Yahoo!地図」という。）を提供している（甲４、乙１、１６、３３）。 被告地図表示方法の構成 被告地図表示方法の構成は、以下のとおりである。 ア地図画像のダウンロード被告地図表示方法では、以下の５通りの方法により、被告管理のサーバから複数の地図画像がダウンロードされ、Ｗｅｂブラウザに地図として表示される（甲４、１０、１８、乙１、１６、３３）。 地図（標準地図）、鉄道路線（鉄道路線図）、地形図、モノトーン、OpenStreetMap（以下「地図画像１（標準地図等）」という。） ●（省略）● 地下街１（以下「地図画像２（地下街１）」という。） ●（省略）● 航空写真（以下「地図画像３（航空写真）」という。） ●（省略）● 航空写真＋注記（以 ●（省略）● 航空写真（以下「地図画像３（航空写真）」という。） ●（省略）● 航空写真＋注記（以下「地図画像４（航空写真＋注記）」という。） ●（省略）● 地下街２（以下「地図画像５（地下街２）」という。） ●（省略）●イ ＨＴＭＬソースコード被告地図表示方法のＨＴＭＬソースコードは、以下のように、①開始タグを<divstyle=”position…>とするdiv 要素（以下「div 要素（position）」という。）、②その一つ下の階層にある開始タグを<divclass=”yo lp-tilelayer”…>とするdiv 要素（以下「div 要素（yolp-tilelayer）」という。）③さらにその一つ下の階層にある複数のimg 要素などにより構成されている（甲４、乙１、１６、３３）。 ウ地図の表示被告地図表示方法では、img タグのstyle 属性で位置（left、top の値）及び大きさ（２５６px×２５６px）を指定し、地図が表示される領域を少なくともカバーするのに必要な位置に複数の矩形領域（以下の図の青色部 分）を設定し、img タグのsrc 属性に被告管理のサーバから受信した地図画像を特定するＵＲＬ（src=”https://map…）を指定することにより、Ｗｅｂブラウザの表示領域に地図を表示し、又は表示できる状態にする（甲 ４、１７、乙１、１６、３３）。 エ地図の移動被告地図表 Ｗｅｂブラウザの表示領域に地図を表示し、又は表示できる状態にする（甲 ４、１７、乙１、１６、３３）。 エ地図の移動被告地図表示方法におけるドラッグ操作による地図の移動は、以下のと おりである（甲４、２１、乙１、１６、２３）。 すなわち、被告地図表示方法では、div 要素（yolp-tilelayer）の開始タグ及びimg タグのstyle 属性のposition の値をabsolute に設定し、一つ上の階層の要素の左上の位置（div 要素（yolp-tilelayer）においては、div 要素（position）、img 要素においてはdiv 要素（yolp-tilelayer）） を基準にstyle 属性のleft、top の値を設定し、位置関係を固定している。 そのため、被告地図表示方法では、Ｗｅｂブラウザの表示領域に表示される地図に対してドラッグ操作が行われた場合、JavaScript ソースプログラムを実行することにより、div 要素（position）の開始タグのleft、top の値を演算して変更し、div 要素（yolp-tilelayer）及びimg 要素をdiv要素（position）と一体的に移動させることにより、地図の移動（スクロ ール）を行っている。 そして、ドラッグ操作を継続し、Ｗｅｂブラウザに地図が表示される領域の中心位置が矩形領域の境界を通過すると、地図が表示されなくなる位置（ドラッグ操作の方向と同方向にある位置）にある矩形領域のimg タグのstyle 属性のleft、top の値並びにsrc 属性のＵＲＬを書き換え、新た な地図の表示に必要となる位置（ドラッグ操作の方向と逆方向にある位置） 位置）にある矩形領域のimg タグのstyle 属性のleft、top の値並びにsrc 属性のＵＲＬを書き換え、新た な地図の表示に必要となる位置（ドラッグ操作の方向と逆方向にある位置）に矩形領域を設定し直し、新しい地図画像をＷｅｂブラウザの表示領域に表示し、又は表示できる状態にする。 先行文献本件特許の出願日である平成１５年４月１７日より前に、以下の公報が存在した。 ア発明の名称を「高精細画像表示装置及びそのプログラム記憶媒体」とす る公開特許公報（特開平１１－８８８６６号公報、平成１１年３月３０日公開。乙１０。以下「乙１０文献」という。）イ発明の名称を「画像情報提供システム、画像情報表示端末およびサーバ装置」とする公開特許公報（特開２０００－２９４４８号公報、平成１２年１月２８日公開。乙１４。以下「乙１４文献」という。） ウ発明の名称を「図形データ表示方法」とする公開特許公報（特開平１－１５９７６８号公報、平成元年６月２２日公開。乙１５。以下「乙１５文献」という。）エ発明の名称を「地図表示制御システム」とする公開特許公報（特開平１１－２３２４３３号公報、平成１１年８月２７日公開。乙２２。以下「乙 ２２文献」という。）オ発明の名称を「データ管理装置及び地図データ記憶システム」とする公開特許公報（特開２００２－３２４２２８号公報、平成１４年１１月８日 公開。乙２３。以下「乙２３文献」という。） ２ 争点 被告地図表示方法の構成要件充足性（争点１）被告は、構成要件２１Ａ及び２１Ｂの充足性を争っているものの、構成要件２１Ａの充足性については構成要件１Ｃ－１の非充足を、構成要件２１Ｂ の充足 被告地図表示方法の構成要件充足性（争点１）被告は、構成要件２１Ａ及び２１Ｂの充足性を争っているものの、構成要件２１Ａの充足性については構成要件１Ｃ－１の非充足を、構成要件２１Ｂ の充足性については構成要件１Ａないし１Ｃの非充足を、それぞれ理由とするものであるから、構成要件充足性の実質的な争点は、下記のとおりとなる。 ア構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」の充足性（争点１－１）イ構成要件１Ｂの「複数の枠要素の配列」の充足性（争点１－２） ウ構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」の充足性（争点１－３）エ構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠 要素の配列の位置を変更し」の充足性（争点１－４）本件各発明の無効理由の有無（争点２）ア乙１０文献を主引例とする進歩性欠如の有無（争点２－１）イ乙１４文献を主引例とする進歩性欠如の有無（争点２－２）ウ乙２２文献を主引例とする進歩性欠如の有無（争点２－３） エ乙２３文献を主引例とする新規性・進歩性欠如の有無（争点２－４）オ明確性要件違反の有無（争点２－５）カサポート要件違反、実施可能要件違反及び補正要件違反の有無（争点２－６）本件特許権の間接侵害の成否（争点３） 損害額（争点４） 第３ 争点に関する当事者の主張 １ 争点１－１（構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」の充足性）について（原告らの主張）「表示領域よりも大きい画像を分割し 第３ 争点に関する当事者の主張 １ 争点１－１（構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」の充足性）について（原告らの主張）「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）の意義 本件各発明は、大きい画像をダウンロードすることなく、少ない待ち時間でビューアに表示できることを解決課題とした発明であるところ（本件明細書等の段落【０００４】ないし【０００６】）、この課題解決の関係において、●（省略）●に限定する理由はない。 したがって、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割 画像」とは、●（省略）● 被告地図表示方法の構成要件充足性以下のとおり、被告地図表示方法でサーバからダウンロードする地図画像１ないし５は、「表示領域よりも大きい画像を分割し…分割画像」に該当するから、被告地図表示方法は、構成要件１Ａを充足する。 ア地図画像１（標準地図等）及び地図画像２（地下街１）地図画像１（標準地図等）及び地図画像２（地下街１）は、●（省略）●にほかならない。 したがって、地図画像１（標準地図等）及び地図画像２（地下街１）は、「表示領域よりも大きい画像を分割し…分割画像」に該当する。 また、仮に、被告の主張するとおり、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」が、●（省略）●に限定されるとしても、地図画像１及び２●（省略）●から、地図画像１（標準地図等）及び地図画像２（地下街１）は、いずれにせよ「表示領域よりも大きい画像を分割し…分割画像」に該当する。 イ地図画像３（航空写真） 地図画像３（航空写真）は、●（ 像２（地下街１）は、いずれにせよ「表示領域よりも大きい画像を分割し…分割画像」に該当する。 イ地図画像３（航空写真） 地図画像３（航空写真）は、●（省略）●としても、「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）に該当する。 ウ地図画像４（航空写真＋注記）地図画像４（航空写真＋注記）は、●（省略）●「表示領域よりも大きい画像を分割し…分割画像」に該当するから、地図画像４（航空写真＋注 記）は、「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）に該当する。 エ地図画像５（地下街２）地図画像５（地下街２）は、●（省略）●から、「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）に該当するものであり、こ の点については、被告も争っていない。 （被告の主張）「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）の意義本件各発明は、●（省略）●ものである。そして、構成要件１Ａは、「表 示領域よりも大きい画像を分割し…分割画像を…表示する画像表示方法」と定め、大きい画像を分割した画像を表示し、もって分割前の大きい画像の一部を表示することを明らかにしている。 したがって、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」とは、●（省略）●画像を分割して作成されたものを意味するという べきである。 被告地図表示方法の構成要件充足性以下のとおり、被告地図表示方法でサーバからダウンロードする地図画像１ないし４は、「表示領域よりも大きい画像を分割し…分割画像」に該当しない。 ア地図画像１（標準地図等）及び地図画像２（地下街 、被告地図表示方法でサーバからダウンロードする地図画像１ないし４は、「表示領域よりも大きい画像を分割し…分割画像」に該当しない。 ア地図画像１（標準地図等）及び地図画像２（地下街１） 地図画像１（標準地図等）及び地図画像２（地下街１）●（省略）●したがって、地図画像１（標準地図等）及び地図画像２（地下街１）は、「表示領域よりも大きい画像を分割し…分割画像」に該当しない。 イ地図画像３（航空写真）地図画像３（航空写真）は、●（省略）● したがって、地図画像３（航空写真）は、「表示領域よりも大きい画像を分割し…分割画像」に該当しない。 ウ地図画像４（航空写真＋注記）地図画像４（航空写真＋注記）は、●（省略）●したがって、地図画像４（航空写真＋注記）は、「表示領域よりも大き い画像を分割し…分割画像」に該当しない。 ２ 争点１－２（構成要件１Ｂの「複数の枠要素の配列」の充足性）について（原告らの主張） 「複数の枠要素の配列」（構成要件１Ｂ）の意義本件各発明は、プラグインソフトウェアを用いることなく、大きい画像の 全てをダウンロードしなくても、スクロール操作により所望とする位置の画像をＷｅｂブラウザに表示することを解決課題とし、それを実現した発明である（本件明細書等の段落【０００６】）。 このような解決課題を踏まえ、本件明細書等に実施例における「セル」に相当する構成として構成要件１Ｂの「枠要素」が規定されていることに鑑み ると、構成要件１Ｂの「複数の枠要素の配列」とは、Ｗｅｂブラウザの「表示領域」に表示される画像を構成する複数の「分割画像」を、それぞれ当てはめるためにＷｅｂブラウザの「表 れていることに鑑み ると、構成要件１Ｂの「複数の枠要素の配列」とは、Ｗｅｂブラウザの「表示領域」に表示される画像を構成する複数の「分割画像」を、それぞれ当てはめるためにＷｅｂブラウザの「表示領域」との関係において「位置」及び「大きさ」の指定により配列される構成要素であって、短い距離のスクロール操作においては「位置」を連続的に変更させることにより配列を維持した まま、また、長い距離のスクロール操作においては「位置」を「非」連続的 に変化させることにより配列を変更することによって、当該スクロール操作に応じた画像の移動を実現する、ＨＴＭＬソースプログラムによって記述される構成要素のことを意味し、開始タグと終了タグを持つコンテナ要素には限定されないものと解すべきである。 また、構成要件１Ｂは、「各枠要素に、該当する位置の分割画像を…表示 できる状態にし」と定め、設定される「枠要素」がＷｅｂブラウザの「表示領域」を正にカバーする位置関係にあるものに限定されないことを予定しており、本件明細書等の段落【００３３】にも、「図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では表示されないが、スクロール操作によりブ ラウザの表示領域に入ってくれば表示できる状態になっている」と記載されているから、構成要件１Ｂの「複数の枠要素の配列」は、表示領域を正にカバーする位置関係にあるものに限定されないものと解すべきである。 被告地図表示方法の構成要件充足性被告地図表示方法においては、img タグのstyle 属性部分に位置、サイズ 等が書き込まれることによってＷｅｂブラウザに設定された複数の矩形領域に、img タグのsrc 件充足性被告地図表示方法においては、img タグのstyle 属性部分に位置、サイズ 等が書き込まれることによってＷｅｂブラウザに設定された複数の矩形領域に、img タグのsrc 属性のＵＲＬの書込み、書換えがされることによって地図画像が当てはめられ、閾値（ドラッグ操作中に矩形領域の配列が変更になる距離）を超えない範囲でドラッグ操作が行われた場合は、矩形領域の位置を連続的に変化させその配列を維持したまま、また、閾値を超えてドラッグ 操作が行われた場合は、矩形領域の位置を非連続的に変化させその配列を変更することにより、ドラッグ操作に応じた画像の移動を実現しているから、上記の複数の矩形領域は、構成要件１Ｂの「複数の枠要素の配列」に該当する。 したがって、被告地図表示方法は、構成要件１Ｂを充足する。 （被告の主張） 「複数の枠要素の配列」（構成要件１Ｂ）の意義構成要件１Ｂは、「分割画像を、個々に当てはめ…る…複数の枠要素…をＷｅｂブラウザに設定し」と定めているから、「枠要素」とは、少なくともＷｅｂブラウザに設定され、画像を当てはめることが可能な要素であることが理解できる。そして、本件各発明は、Ｗｅｂブラウザを用いた画像表示方 法の発明であり、本件明細書等には、ＨＴＭＬやJavaScript を用いたソースコードを示しながら実施例が記載されているところ、本件特許出願当時の技術常識（乙２ないし５、７）からすると、当業者は、画像を当てはめることが可能な要素として、Ｗｅｂブラウザの種類を問わずに画像を配置でき、かつ、開始タグ及び終了タグによって画像を当てはめるための枠が観念できる ＨＴＭＬ文書のコンテナ要素を指すものと理解するといえ、現に、本件明細書等の実 ブラウザの種類を問わずに画像を配置でき、かつ、開始タグ及び終了タグによって画像を当てはめるための枠が観念できる ＨＴＭＬ文書のコンテナ要素を指すものと理解するといえ、現に、本件明細書等の実施例には、「６×６個のセルを設定する〈ＤＩＶ〉タグ」（段落【００２３】）などと、div タグにより設定されるコンテナ要素により、セル（枠要素）を設定する旨が記載されている。 したがって、構成要件１Ｂの「複数の枠要素の配列」は、複数のコンテナ 要素である必要があり、img タグのように終了タグのない非コンテナ要素（空要素）は含まれないと解すべきである。 また、構成要件１Ｂの「当てはめて表示する表示領域に相当する複数の枠要素の配列」の文言に照らすと、構成要件１Ｂの「複数の枠要素の配列」は、表示領域に関連する必要があり、かつ、分割画像が当てはめられると表示領 域に表示される必要があると解すべきである。 被告地図表示方法の構成要件充足性被告地図表示方法では、img タグを用いて、src 属性により指定した画像を、style 属性により指定した位置及びサイズに表示しているにすぎず、画像を当てはめる複数のコンテナ要素は存在しない。 仮に、原告らの主張するようにimg タグのstyle 属性による位置及びサイ ズ等の指定が「枠要素」に当たるとしても、被告地図表示方法では、Ｗｅｂブラウザのデベロッパーツールでimg タグにカーソルを合わせた場合に青く表示される矩形領域の配列は、表示領域の配列と全く異なり関連せず、しかも全く画像が表示されないものもある。 また、仮に、乙１０文献における「キャッシュ・メモリ」は、「画像表示 のための処理」が別途必要なものであり「 示領域の配列と全く異なり関連せず、しかも全く画像が表示されないものもある。 また、仮に、乙１０文献における「キャッシュ・メモリ」は、「画像表示 のための処理」が別途必要なものであり「ブロック」を画面上の位置に並べるものではないという原告らの主張（争点２－１（乙１０文献を主引例とする進歩性欠如の有無））を前提とすると、「分割画像を…当てはめて表示する」に該当するには特段の画像表示のための処理をしないものでなければいけないことになるが、被告地図表示方法では、img タグのvisibility の値を hidden からvisible に変更する処理を経なければ、画像が表示されることもない。 したがって、被告地図表示方法には、構成要件１Ｂの「複数の枠要素の配列」は存在しないから、構成要件１Ｂを充足しない。 ３ 争点１－３（構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位 置に枠要素を移動し」の充足性）について（原告らの主張） 「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）の意義本件明細書等の段落【００４３】には、スクロール制御を実現するための 方法として、各セル（本件各発明の「枠要素」に相当）毎に移動量の演算を行う方法のみならず、複数のセルにより構成されるブロックの移動量の演算を行う方法も開示されている。 また、本件明細書等には、スクロール操作を実現するためのJavaScript の関数を示す【図１３】がある。そして、本件明細書等の段落【００４２】の 「ブロック２０はブラウザの表示１６に対し相対移動」するという記載から すると、本件明細書等が、div タグのposition の値がabsolute であることを ２】の 「ブロック２０はブラウザの表示１６に対し相対移動」するという記載から すると、本件明細書等が、div タグのposition の値がabsolute であることを前提としていることは明らかであり、また、ＨＴＭＬソースプログラムのHEAD の部分でdiv タグやimg タグのposition の値を一括してabsolute にすることは技術常識であるから、【図１３】は、各セル（「枠要素」）の親要素であるブロック（複数の「枠要素」により構成）の位置の値を書き換える ことにより、「分割画像」の移動を行う構成を具体的に開示するものといえる。 したがって、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」には、枠要素の親要素やその親要素の移動すべき位置を演算する構成も含まれる。 被告地図表示方法の構成要件充足性被告地図表示方法では、img 要素の２つ上の階層にあるdiv 要素（position）の開始タグのleft、top の値を変更することにより、img タグが指定する位置（矩形領域の位置）を移動させている。 したがって、被告地図表示方法は、枠要素の親要素の親要素の移動すべき 位置を演算して、枠要素を移動させるものであるから、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」を充足する。 （被告の主張） 「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）の意義 本件特許の特許請求の範囲の記載によれば、本件発明１の従属項である請求項１５では、「ブロックの原点の移動すべき座標」の演算と「各枠要素の原点の移動すべき座標」の演算が峻別されているから、構成要件１Ｃ－１の の特許請求の範囲の記載によれば、本件発明１の従属項である請求項１５では、「ブロックの原点の移動すべき座標」の演算と「各枠要素の原点の移動すべき座標」の演算が峻別されているから、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算」は、ブロックのような親要素（の親要素）の移動すべき演算とは明らかに異なるものとして位置付けられているといえ る。 そして、本件明細書等をみても、「１つのブロックについて移動量を演算して該ブロックの移動後の原点を求め、該求められたブロックの原点の座標に基づき、該ブロックを構成する各セルの原点の座標を演算して求める。これによれば、ブロックの原点に対する各セルの原点の相対位置は予め定まっており、簡単な演算で求めることができ、一方複雑な演算を要する移動量の 演算は１つのブロックについてのみ行えばよいので、セル単位で（セルごとに）移動量の演算をする場合に比べて全体として演算量が少なくて済み、移動動作を高速化することができる。」（段落【００４３】）、「ブロックの原点の移動すべき座標が求められたら、この座標がブロックの最初セル〔Ｓｘｆ，Ｓｙｆ〕の原点の座標になるので、他のセルについてもX 軸方向およびＹ 軸方向にそれぞれ４８０ずつ順次足していくことによりそれぞれの原点の座標を求める。」（段落【００４４】）と記載されているように、ブロックの原点の座標を利用しつつ、それぞれの枠要素の移動すべき位置を演算して該位置に枠要素を移動させる構成は開示されている。他方、複数の枠要素により構成されるブロックの移動すべき位置を演算し、ブロックと枠要素を一体 的に移動させ、移動させる画像の数に関係なく演算量を一定にするという技術思想は開示されていない。この点について、本件明細書等の【図１３】について 動すべき位置を演算し、ブロックと枠要素を一体 的に移動させ、移動させる画像の数に関係なく演算量を一定にするという技術思想は開示されていない。この点について、本件明細書等の【図１３】についても、本件明細書等の実施例にあるブロックの〈DIVID=canvasBLOCK〉のタグには、position の値が設定されておらず（本件明細書等の【図４】）、初期値のstatic となるため、left、top の値を書き換えてもブロックは移動 しないから（甲８）、ブロックの移動すべき位置を演算し、ブロックと枠要素を一体的に移動させる関数を示すものとはいえない。 さらに、ブロックの移動すべき位置の演算によりブロックと枠要素を一体として移動させ演算量を一定にするという技術思想は、本件各発明の技術的意義や作用効果について、全分割画像に比べて限られた数の枠要素の演算を すればよいため、演算量が減少して画像の移動速度が速くなる旨が記載され た本件明細書等（段落【００２５】）や本件特許の出願過程で提出された意見書（乙２５の５）の内容と矛盾する。 したがって、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」とは、各枠要素の移動すべき位置をそれぞれ演算して枠要素を移動することを意味し、各枠要素の移動すべき位置を演算するこ となく、枠要素の親要素やその親要素の移動すべき位置を演算し、枠要素が親要素やその親要素と一体的に移動する構成は含まれないというべきである。 被告地図表示方法の構成要件充足性被告地図表示方法では、ドラッグ操作による画像の移動処理を、img 要素の親要素の親要素であるdiv 要素（position）の開始タグのleft、top の値 を演算して書き換え 被告地図表示方法では、ドラッグ操作による画像の移動処理を、img 要素の親要素の親要素であるdiv 要素（position）の開始タグのleft、top の値 を演算して書き換え、img 要素をdiv 要素（position）と一体的に移動させることで行っており、img 要素のleft、top の値を演算、変更して、img 要素を移動させることはしていない。 したがって、被告地図表示方法にimg タグにより設定される矩形領域があり、これが「枠要素」（構成要件１Ｂ等）に該当するとしても、被告地図表 示方法は、各枠要素の移動すべき位置を演算して枠要素を移動させるものではないから、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」を充足しない。 ４ 争点１－４（構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの 表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」の充足性）について（原告らの主張）被告地図表示方法では、ドラッグ操作を行い、表示領域の中心が矩形領域の境界を通過するあたりで、img タグのstyle 属性のleft、top の値及びsrc 属 性のＵＲＬの書換えを行うことにより、同境界を越えた方向と逆方向にある位 置から矩形領域を削除し、同境界を越えた方向と同方向にある新たに画像を表示させる可能性がある位置に矩形領域を追加して矩形領域の配列を変更しているから、構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠 の配列を変更しているから、構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の 配列の位置を変更し」を充足する。 （被告の主張）被告地図表示方法では、img タグのstyle 属性のleft、top の値及びsrc 属性のＵＲＬを変更し、この変更に係るimg タグで指定された地図画像のデータをダウンロードして表示することがあるものの、あくまでstyle 属性の値を変 更して矩形領域の位置を変更しているにすぎず、img タグやstyle 属性の記述について削除、追加の処理はしていない。そして、img タグのstyle 属性を可視化した矩形領域の数も不変であり、ドラッグ操作に伴いその数が増減することもない。 また、img タグのsrc 属性及びstyle 属性の変更において、Ｗｅｂブラウザ の表示領域から離れる画像であるか否か、Ｗｅｂブラウザの表示領域に近づく画像であるか否かを判別する処理は行われていない。 さらに、被告地図表示方法では、●（省略）●のみならず、急なドラッグ操作がされた場合は、表示領域が地図画像から外れた後のタイミングでimg タグの位置の書換えが行われ、近づく分割画像がな いところにimg タグの位置が移動するから、表示領域に近づく分割画像に該当する位置に枠要素が追加されることはない。 以上によれば、被告地図表示方法は、構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を 追加して画像に対する枠要素の配列の位置を変 伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を 追加して画像に対する枠要素の配列の位置を変更し」を充足しない。 ５ 争点２－１（乙１０文献を主引例とする進歩性欠如の有無）について（被告の主張）以下のとおり、本件各発明は、乙１０文献に記載された以下の２つの発明（以下「乙１０発明」、「乙１０´発明」という。）それぞれに基づき当業者は容易に想到し得たものであるから、進歩性を欠く。 乙１０発明ア乙１０発明の内容 乙１０文献には、以下の乙１０発明が開示されている。 １０Ａ 画像を表示する表示枠２４よりも大きい画像を分割し該表示枠２４に少なくとも一部が入る分割画像をサーバから優先的にダウ ンロードして該表示枠２４に表示する画像表示方法において、１０Ｂ 表示枠２４に少なくとも一部が入る分割画像を含む、表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示枠２４に相当する複数のキャッシュ・メモリ上のブロックの 配列を設定し、該各キャッシュ・メモリ上のブロックに、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、１０Ｃ－１ マウスを移動するなどのスクロール操作がなされた時に、表示枠２４に対するキャッシュ・メモリ上のブロックの移動 すべき位置を演算して該位置にキャッシュ・メモリ上のブロックを移動し、１０Ｃ－２ 該画像のスクロールに伴い表示枠２４から離れる分割画像該当する位置からキャッシュ・メモリ上のブロックを抹消し、表示枠２４に近づく分 て該位置にキャッシュ・メモリ上のブロックを移動し、１０Ｃ－２ 該画像のスクロールに伴い表示枠２４から離れる分割画像該当する位置からキャッシュ・メモリ上のブロックを抹消し、表示枠２４に近づく分割画像に該当する位置にキャッシュ・ メモリ上のブロックを追加して画像に対するキャッシュ・メ モリ上のブロックの配列の位置を変更し、該追加するキャッシュ・メモリ上のブロックに、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にし１０Ｄ 前記演算はクライアントにより実行される画像表示方法乙１０発明の「表示枠２４」、「キャッシュ・メモリ上のブロック」、 「マウスを移動するなどのスクロール操作がなされた時」及び「画像のスクロール」は、それぞれ本件各発明の「表示領域」、「枠要素」、「表示領域に対する画像の相対移動が指示された時」及び「画像の相対移動」に相当する。 ａ これに対し、原告らは、乙１０文献の「ブロック」は「分割画像」 そのものであって、「分割画像」を当てはめるものではないと主張する。 しかしながら、乙１０文献では、「ブロック」が、「分割画像」自体やイメージ（・データ）とは別の「区画」を意味する概念として記述され（段落【００３２】、【００３３】、【００６１】、【００９ １】）、また、キャッシュ・メモリにロードされたブロックの管理領域に「画像データ」が含まれるとして、「ブロック」が「分割画像」自体を意味しないことが明記されている（段落【００８３】、【００９３】ないし【００９８】、【図１６】）。 したがって、乙１０文献において、「ブロック」は、「分割画像」 を当てはめる区画を意味するものであり、「分割画像」そのものではない。 仮に、「ブロック」が厳密には「区画」を意味しない ）。 したがって、乙１０文献において、「ブロック」は、「分割画像」 を当てはめる区画を意味するものであり、「分割画像」そのものではない。 仮に、「ブロック」が厳密には「区画」を意味しないとしても、乙１０文献によれば、「キャッシュ・メモリ上のブロック」は、表示枠２４の関係で位置関係が特定されるものであり（段落【００６７】、 【図１１】）、その管理領域内に含まれる「画像データ」が必要に応 じてイメージ展開され（段落【００６１】）、当該イメージが「キャッシュ・メモリ上のブロック」と関連付けられ画像として表示されるのであるから、「キャッシュ・メモリ上のブロック」は、本件各発明の「枠要素」に相当する。 ｂ 原告らは、「キャッシュ・メモリ」は、「ブロック」のデータを一 時的に保管するものにすぎず、ブロックを画面上の位置に並べ、その削除と追加により位置の変更を生じさせる構成を備えていないと主張する。 しかしながら、「キャッシュ・メモリ」が、「ブロック」のデータを一時的に保管するものであるからといって、その削除と追加により 画像に対する位置の変更が生じる態様の配列に係る構成を備えていないと結論付ける理由が不明である。 上記で主張したとおり、表示枠２４に対して、キャッシュ・メモリ上にブロックの配列が設定され、キャッシュ・メモリ上のブロックの管理領域にある「画像データ」がイメージ展開され、キャッシュ・メ モリ上のブロックと関連付けられ画像として表示されるのであるから、乙１０文献には、表示枠２４に少なくとも一部が入る分割画像を含む、表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示枠 乙１０文献には、表示枠２４に少なくとも一部が入る分割画像を含む、表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示枠２４に相当する複数のキャッシュ・メモリ上のブロックの配列 を設定することが開示されているといえる。 イ一致点及び相違点乙１０発明と本件発明１には、以下の相違点１０－１及び２が存在し、乙１０発明と本件発明２１には上記の相違点に加えて相違点１０－５が存在するものの、その余は一致する。 （相違点１０－１） 本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙１０発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とは明示されてはいない点（相違点１０－２）本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」と されているのに対し、乙１０発明では、「キャッシュ・メモリ上のブロックの配置場所の配列」を、「Ｗｅｂブラウザに」設定するものとは明示されていない点（相違点１０－５）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信され るJavaScript（登録商標）に基づき実行される」のに対し、乙１０発明では、「演算はクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」「JavaScript（登録商標）に基づき実行される」とは明示されていない点ウ相違点の容易想到性 相違点１０－１乙１０文献の段落【００２２】、【００２３】及び【図１】の記載によれば、乙１０発明は、サーバ及びクライアントが通信回線を通じて通信を行ういわゆるクライアントサーバシステムに係る発明である 乙１０文献の段落【００２２】、【００２３】及び【図１】の記載によれば、乙１０発明は、サーバ及びクライアントが通信回線を通じて通信を行ういわゆるクライアントサーバシステムに係る発明である。 そして、本件特許出願日当時、このようなクライアントサーバシステ ムの典型的な例として、ＷｅｂサーバとＷｅｂブラウザを備えたクライアントからなるシステムは周知慣用技術であったから（乙１１ないし１３）、乙１０発明に触れた当業者には、乙１０発明のクライアントサーバシステムとして、ＷｅｂサーバとＷｅｂブラウザを備えたクライアントからなる構成を採用する強い動機付けがあった。また、このような典 型的なシステムを採用することは、設計事項にすぎなかった。 したがって、相違点１０－１に係る構成は容易に想到することができた。 相違点１０－２乙１０発明においてＷｅｂサーバとＷｅｂブラウザを備えたクライアントからなる構成を採用すれば、キャッシュ・メモリ上のブロックに、 該当する位置の分割画像をそれぞれ当てはめることで、Ｗｅｂブラウザの表示領域に分割画像を表示し又は表示できる状態にすることになり、必然的に複数のキャッシュ・メモリ上のブロックの配列はＷｅｂブラウザに設定されることになるから、相違点１０－２に係る構成は容易に想到することができた。 相違点１０－５ＷｅｂサーバとＷｅｂブラウザを備えたクライアントからなるシステムでは、演算をＷｅｂブラウザにおけるJavaScript の実行によるものとすることは、周知慣用技術であった（乙３ないし５、乙７）。そうすると、乙１０発明においてＷｅｂサーバとＷｅｂブラウザを備えたクラ イアントからなる構成を採 vaScript の実行によるものとすることは、周知慣用技術であった（乙３ないし５、乙７）。そうすると、乙１０発明においてＷｅｂサーバとＷｅｂブラウザを備えたクラ イアントからなる構成を採用するに当たり、演算をＷｅｂブラウザにおけるJavaScript の実行によるものとすることは、単なる設計事項にすぎず、また、演算の必要から採用する動機付けもあった。 したがって、相違点１０－５に係る構成は容易に想到することができた。 仮に、被告が認める相違点以外の相違があるとしても、実質的な相違点ではないか、その相違に係る構成が容易想到なものにすぎない。 乙１０´発明ア乙１０´発明の内容 仮に、原告らの主張するとおり、乙１０文献における「ブロック」が 「分割画像」そのものであり、「画像表示のための処理」（段落【００ ６１】、【００６２】、【図９】）により画面に表示されるものであるとすると、乙１０文献の「図１１は画像表示に当っての表示画像範囲の移動を説明する図である。…図示×印を付したブロックがクライアント５側へ転送されて、図示の表示画面２７に表示される。」という記載（段落【００６６】、【００６７】）によれば、【図１１】に、「画像表示 のための処理」により、表示枠に一部でも含まれる「ブロック」（分割画像）につき、表示枠との関係でそれぞれの配置場所を設定し、「ブロック」を表示し又は表示できる状態にすることの開示があるということになるから、乙１０文献には、以下の乙１０´発明が開示されていることになる。 １０´Ａ 画像を表示する表示枠２４よりも大きい画像を分割し該表示枠２４に少なくとも一部が入るブロックをサーバから優先的にダウンロードして該表 発明が開示されていることになる。 １０´Ａ 画像を表示する表示枠２４よりも大きい画像を分割し該表示枠２４に少なくとも一部が入るブロックをサーバから優先的にダウンロードして該表示枠２４に表示する画像表示方法において、１０´Ｂ 表示枠２４に少なくとも一部が入るブロックを含む、表示枠 ２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれるブロックを、「画像表示のための処理」により、個々に関連づけて表示する表示枠２４に相当する複数のブロックの配置場所の配列を設定し、該各ブロックの配置場所に、該当する位置のブロックをそれぞれ関連づけて表 示し又は表示できる状態にし、かつ、１０´Ｃ－１ マウスを移動するなどのスクロール操作がなされた時に、表示枠２４に対するブロックの配置場所の移動すべき位置を演算して該位置にブロックの配置場所を移動し、１０´Ｃ－２ 「画像表示のための処理」により、該画像のスクロール に伴い表示枠２４から離れるブロックに該当する位置か らブロックの配置場所を抹消し、表示枠２４に近づくブロックに該当する位置にブロックの配置場所を追加して画像に対するブロックの配置場所の配列の位置を変更し、該追加するブロックの配置場所に、該当する位置のブロックを関連づけて表示しまたは表示できる状態にし １０´Ｄ 前記演算はクライアントにより実行される画像表示方法乙１０´発明の「表示枠２４」、「ブロック」、「関連づけて」、「マウスを移動するなどのスクロール操作がなされた時」及び「画像のスクロール」は、それぞれ本件各発明の「表示領域」、「分割画像」、「当てはめて」、「表示領域に対する画像の相対移動が指示された時」及び 「画像の相対移動」に相 ル操作がなされた時」及び「画像のスクロール」は、それぞれ本件各発明の「表示領域」、「分割画像」、「当てはめて」、「表示領域に対する画像の相対移動が指示された時」及び 「画像の相対移動」に相当する。また、乙１０´発明の「ブロックの配置場所」は、所定の位置、サイズ等を特定するものであるから、本件各発明の「枠要素」に相当する。 ａ これに対し、原告らは、「ブロック」のうち表示枠に表示されない部分は、「画像表示のための処理」に先立ち、サーバ（段落【００３ １】ないし【００３４】）又はクライアント（段落【００４８】、【００４９】）のいずれかによりカットされるため、乙１０文献には、ブロックが表示できる状態にする構成の開示はないと主張する。 しかしながら、本件各発明は、「表示しまたは表示できる」と選択的に規定されているとおり、「表示」（する）と「表示できる」のい ずれかを満たせば足りるところ、乙１０´発明が「ブロック」を「表示」する構成を備えていることについて争いはないから、原告らの上記主張は乙１０´発明の認定とは無関係である。 もとより、乙１０´発明では、「表示枠」の外側にある部分も含めて全体がクライアント５に伝送され（段落【００３３】）、ブロック の一部は表示され、一部は表示されていない状態になるから、ブロッ クを表示し又は表示できる状態にする構成は開示されている。これに対し、原告らは、クライアントが画像をカットしている根拠として段落【００４８】、【００４９】を挙げるが、これらの段落には、クライアントのＣＰＵに余裕がある場合に限りＪＰＥＧのままで伝送させる割合を増加させることが開示しているのみであって、クライアント が画像をカットすることなどの記載はない。また、原告らがサーバ側で画像をカッ ＣＰＵに余裕がある場合に限りＪＰＥＧのままで伝送させる割合を増加させることが開示しているのみであって、クライアント が画像をカットすることなどの記載はない。また、原告らがサーバ側で画像をカットすることの根拠として挙げる段落【００３１】ないし【００３４】には、サーバ１が、一部のイメージだけをクライアント５に伝送する構成が開示されているが、これは乙１０文献に係る特許の請求項１の従属項に対応するものであり、乙１０´発明においては 必須の要素とされた構成ではない。 したがって、乙１０文献には、ブロックが表示できる状態にする構成の開示がある。 ｂ また、原告らは、乙１０文献の段落【００２３】の記載を根拠に、乙１０文献に記載された発明は、「画像表示のための処理」として「ブ ロック（画像）」の「貼り合わせ」処理を行った１枚の画像を「表示枠」に表示する構成を備えるものにすぎないと主張する。 しかしながら、段落【００２３】には、単に「分割画像の貼り合わせを行い」と記載されているのみで、分割画像を１枚の画像にすることなど記載されておらず、【図１１】等も踏まえれば、単に各「キャ ッシュ・メモリ上のブロック」に対応して各分割画像を位置付けること、あるいは、「ブロック」を「ブロックの配置場所」に配置することをもって、「分割画像の貼り合わせを行い」と表現したものと理解できる。 したがって、乙１０´発明が、「貼り合わせ」処理を行った１枚の 画像を「表示枠」に表示する構成を備えるものということはできない。 イ一致点及び相違点乙１０´発明と本件発明１には、以下の相違点１０´－１及び２が存在し、乙１０発明と本件発明２１には上記の相違点に加えて相違点１０´－５が存在する イ一致点及び相違点乙１０´発明と本件発明１には、以下の相違点１０´－１及び２が存在し、乙１０発明と本件発明２１には上記の相違点に加えて相違点１０´－５が存在するものの、その余は一致する。 （相違点１０´－１） 本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙１０´発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とは明示されてはいない点（相違点１０´－２）本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」と されているのに対し、乙１０´発明では、「ブロックの配置場所の配列」を、「Ｗｅｂブラウザに」設定するものとは明示されていない点（相違点１０´－５）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙１０´発明 では、「演算はクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」「JavaScript（登録商標）に基づき実行される」とは明示されていない点ウ相違点の容易想到性相違点１０´－１、２及び５に係る構成は、乙１０発明についての相違 点の容易想到性で主張した理由（上記ウ）と同じ理由により、容易に想到し得たものである。 仮に、被告が認める相違点以外の相違があるとしても、実質的な相違点ではないか、その相違に係る構成が容易想到なものにすぎない。 （原告らの主張） 以下のとおり、本件各発明は、乙１０発明及び乙１０´発明と相違し、当該 相違点は容易想到ではないから、乙１０発明及び乙１０´発明との関係で進歩性を有する らの主張） 以下のとおり、本件各発明は、乙１０発明及び乙１０´発明と相違し、当該 相違点は容易想到ではないから、乙１０発明及び乙１０´発明との関係で進歩性を有する。 乙１０発明についてア乙１０発明の内容について被告は、乙１０文献における「分割画像」は「ブロック」に当てはめら れる関係にあると主張する。 しかしながら、乙１０文献の段落【００２８】の「最高解像度ファイル１１を構成するブロック」という記載や、段落【００４５】の「当該ブロックをＪＰＥＧのままで転送する」という記載、【図３】、【図８】等の記載によれば、乙１０文献における「ブロック」は「分割画像」そのもの であり、「分割画像」を当てはめるものではない。 また、被告は、乙１０文献における「キャッシュ・メモリ」には「ブロック」の「配列」が設定され、また、この「配列」は表示させる画面上の位置に対応して並べられ、それゆえ「ブロック」の抹消（削除）と追加は全体画像に対する位置の変更をもたらすと主張する。 しかしながら、乙１０文献の段落【００６１】、【００６２】、【図９】等において、「キャッシュ・メモリ」上の「ブロック」のデータは、これに対応する分割画像を画面上に表示するために「画像表示のための処理」が別途必要とされているとおり、乙１０文献における「キャッシュ・メモリ」は、単に「サーバ１」から受信した「ブロック」のデータを一時的に 保管するものにすぎず、ブロックを画面上の位置に並べ、その削除と追加により画像に対する位置の変更を生じさせる構成を備えていない。 したがって、乙１０文献に開示されている乙１０発明の内容は、以下のものとなる。 １０Ａ 画像を表示する表示枠２４よりも大きい画像を分割し該表示枠 の変更を生じさせる構成を備えていない。 したがって、乙１０文献に開示されている乙１０発明の内容は、以下のものとなる。 １０Ａ 画像を表示する表示枠２４よりも大きい画像を分割し該表示枠 ２４に少なくとも一部が入る「ブロック（画像）」をサーバから優 先的にダウンロードして該表示枠２４に表示する画像表示方法において、１０Ｂ 表示枠２４に少なくとも一部が入る「ブロック（画像）」を含む、表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる「ブロック（画像）」を「画像表示 のための処理」により表示し、かつ、１０Ｃ－１ マウスを移動するなどのスクロール操作がなされた時に、表示枠２４に対する「ブロック（画像）」の移動すべき位置を演算して該位置に「ブロック（画像）」を移動し、１０Ｃ－２ 該画像のスクロールに伴い表示枠２４から離れる「ブロック （画像）」に該当する位置からキャッシュ・メモリ上の「ブロック（画像）」を抹消し、表示枠２４に近づく「ブロック（画像）」に該当する位置の「ブロック（画像）」をキャッシュ・メモリに追加して「画像表示のための処理」により表示し１０Ｄ 前記演算はクライアントにより実行される画像表示方法 イ一致点及び相違点について乙１０発明と本件発明１には、相違点１０－１のほか、以下のとおり、相違点１０－２´、３及び４が存在し、乙１０発明と本件発明２１には、上記の相違点に加えて相違点１０－５が存在する。 （相違点１０－２´） 本件各発明は、「…分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表 本件各発明は、「…分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし」とされているのに対し、乙１０発明はかかる構成を備えていない点 （相違点１０－３） 本件各発明は、「Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し」という構成を備えるのに対し、乙１０発明はかかる構成を備えていない点（相違点１０－４） 本件各発明は、「該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする」という構成を 備えるのに対し、乙１０発明はかかる構成を備えていない点ウ相違点の容易想到性について 相違点１０－１について被告は、ＷｅｂサーバとＷｅｂブラウザを備えたクライアントからなるシステムが周知慣用技術であったことを理由として、相違点１０－１ を解消することは容易に想到できると主張する。 しかしながら、乙１０文献にＨＴＭＬ、JavaScript など「Ｗｅｂブラウザ」により実現できることを示唆する記載がないことからすると、乙１０文献では「Ｗｅｂブラウザ」をクライアントに備えることは、全く予定されていない。 したがって、被告 t など「Ｗｅｂブラウザ」により実現できることを示唆する記載がないことからすると、乙１０文献では「Ｗｅｂブラウザ」をクライアントに備えることは、全く予定されていない。 したがって、被告の主張は、本件各発明の構成を念頭に置いた単なる後知恵のものにすぎない。 相違点１０－２´、３及び４について被告は、相違点１０－２´、３及び４に関する容易想到性の主張をしていない。 相違点１０－５について 上記及びで主張したとおり、乙１０発明に相違点１０－１、２´、３及び４に係る構成を適用すべき理由はないから、本件発明２１に相違点１０－５に係る構成を適用する前提を欠く。 乙１０´発明についてア乙１０´発明の内容について 被告は、乙１０文献の【図１１】などを根拠に、乙１０文献には、「ブロックの配置場所」という「枠要素」に相当する構成を含む「表示枠２４に相当する複数のブロックの配置場所の配列を設定し、該各ブロックの配置場所に、該当する位置のブロックをそれぞれ関連づけて表示しまたは表示できる状態にし」という構成が開示されていると主張する。 しかしながら、【図１１】は、画像表示と表示画像範囲の移動に関する説明のための概念図にすぎないから、【図１１】から、ブロックの配置場所の設定という細部の構成まで認定することはできない。 また、画像データを管理する「ブロック管理領域」には「当該ブロックの座標情報」 が記述されていることや（段落【００９４】ないし【００９ ８】、【図１６】）、表示枠と表示される画像位置の対応関係に関する情報が取得されていることからすれば、乙１０文献における「画像表示のための処理」（段落【０ や（段落【００９４】ないし【００９ ８】、【図１６】）、表示枠と表示される画像位置の対応関係に関する情報が取得されていることからすれば、乙１０文献における「画像表示のための処理」（段落【００６２】）とは、表示枠と表示する画像の位置関係を特定し、当該対応関係をもとに表示枠に含まれる「ブロック」及びその座標情報の伝送を受け、表示枠にブロックを表示させるというものである と合理的に推察される。そうすると、乙１０文献の記載から、ビューアに設定され「ブロック」を当てはめる「枠要素」に相当する構成など観念できない。 さらに、「画像表示のための処理」では、「ブロック」のうち表示枠に表示されない部分は、「画像表示のための処理」に先立ち、サーバ（段落 【００３１】ないし【００３４】）又はクライアント（段落【００４８】、 【００４９】）のいずれかによりカットされるため、乙１０文献には、ブロックが表示できる状態にする構成の開示はない。 加えて、乙１０文献には表示枠との関係でブロックの配置場所を設定する構成の記載はなく、乙１０文献の段落【００２３】の「（画像表示部は、）…分割画像の貼り合わせを行い」という記載によれば、乙１０文献に記載 された発明は、「画像表示のための処理」として「ブロック（画像）」の「貼り合わせ」処理を行った１枚の画像を「表示枠」に表示する構成を備えるものにすぎない。 したがって、乙１０文献に開示されている乙１０´発明の内容は、以下のものとなる。 １０´Ａ 画像を表示する表示枠２４よりも大きい画像を分割し該表示枠２４に少なくとも一部が入る「ブロック（画像）」をサーバから優先的にダウンロードして該表示枠２４に表示する画像表示方法において、１０´Ｂ 表示枠２４に少 示枠２４よりも大きい画像を分割し該表示枠２４に少なくとも一部が入る「ブロック（画像）」をサーバから優先的にダウンロードして該表示枠２４に表示する画像表示方法において、１０´Ｂ 表示枠２４に少なくとも一部が入る「ブロック（画像）」を含 む、表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる「ブロック（画像）」を、「画像表示のための処理」により表示し、かつ、１０´Ｃ－１ マウスを移動するなどのスクロール操作がなされた時に、スクロール後の地図の位置を演算して表示枠２４に表示すべ き「ブロック（画像）」を「画像表示のための処理」により表示し、１０´Ｃ－２ 「画像表示のための処理」により、該画像のスクロールに伴い表示枠２４から離れる「ブロック（画像）」に該当する位置から当該「ブロック（画像）」を抹消し、表示枠２４に近づ く「ブロック（画像）」に該当する位置に当該「ブロック（画 像）」を表示し１０´Ｄ 前記演算はクライアントにより実行される画像表示方法イ一致点及び相違点について乙１０´発明と本件発明１には、相違点１０´－１のほか、相違点１０－２´、３及び４と同様の相違点１０´－２´、３及び４が存在し、乙１ ０´発明と本件発明２１には、上記の相違点に加えて相違点１０´－５が存在する。 ウ相違点の容易想到性について乙１０´発明と本件各発明の相違点に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（上記ウ）と同じ理由により、容 易に想到できるものではない。 ６ 争点２－２（乙１４文献を主引例とする進歩性欠如の有無）について（被告の主張）以下のとおり、本件各発明は、乙１４文献 ウ）と同じ理由により、容 易に想到できるものではない。 ６ 争点２－２（乙１４文献を主引例とする進歩性欠如の有無）について（被告の主張）以下のとおり、本件各発明は、乙１４文献に記載された以下の２つの発明（以下「乙１４の１発明」、「乙１４の２発明」という。）それぞれに基づき、当 業者は容易に想到し得たものであるから、進歩性を欠く。 乙１４の１発明ア乙１４の１発明の内容 乙１４文献記載の第１実施形態には、以下の乙１４の１発明が開示されている。 乙１４の１Ａ 端末装置３における表示装置３１に画像を表示する表示区域５１よりも大きい、日本全国の地域を網羅する広い範囲の地図データをマトリクス状に区分し該表示装置３１の表示区域５１にその全体が入る、マトリクス状に区分された画像データをセンター装置２から優先的に受信して 該表示装置３１の表示区域５１に表示する画像表示方法 において、乙１４の１Ｂ 表示装置３１の表示区域５１にその全体が入る表示装置３１の表示区域５１に表示される、地図データ全体に対して限定された範囲の画像領域を構成する画像データを、個々に当てはめて表示する表示区域５１に相当する複数 の区画の配列を表示装置３１に設定し、該各区画に、該当する位置の画像データをそれぞれ当てはめて表示し、かつ、乙１４の１Ｃ－１ 表示装置３１の表示区域５１に対する画像のスクロールが指示された時に、表示装置３１の表示区域５１における各区画に当てはめられた画像データの移動す べき位置を演算して該位置にある固定されている区画に画像データを移動し、乙１４の１Ｃ－２ 該画像の相対移動に伴い表示装置３１の表示区域５１から離れる画像データを固定されている区画 移動す べき位置を演算して該位置にある固定されている区画に画像データを移動し、乙１４の１Ｃ－２ 該画像の相対移動に伴い表示装置３１の表示区域５１から離れる画像データを固定されている区画から削除し、表示装置３１の表示区域５１に近づく画像デー タを固定されている区画に追加して画像に対する区画の配列の位置を変更し、該追加する画像データを、該当する位置の固定されている区画に当てはめて表示し、前記演算は端末装置３により実行され、受信した画像データを記憶装置に記憶しておき、区 画に当てはめるべき画像データが記憶装置に記憶されている場合は、記憶されている画像データを区画に当てはめて表示させることができる乙１４の１Ｄ 画像表示方法 乙１４の１発明の「表示区域５１」、「画像データ」、「センター装 置２」及び「区画」は、それぞれ本件発明１の「表示領域」、「分割画 像」、「サーバ」及び「枠要素」にそれぞれ相当する。 イ一致点及び相違点 乙１４の１発明と本件発明１には、以下の相違点１４の１－１ないし５が存在し、乙１４の１発明と本件発明２１には上記の相違点に加えて、相違点１４の１－７が存在するものの、その余は一致する。 （相違点１４の１－１）本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙１４の１発明の「表示区域５１」は、「Ｗｅｂブラウザの表示領域」とは明示されてはいない点（相違点１４の１－２） 本件各発明は、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙１４の１発明では、「区画」を、「Ｗｅｂブラウザに」設定するものとは明示されていない点（相違点１４の１ 本件各発明は、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙１４の１発明では、「区画」を、「Ｗｅｂブラウザに」設定するものとは明示されていない点（相違点１４の１－３）表示領域に対する画像の相対移動が指示された時に行われる移動処理 が、本件発明１では、「枠要素の移動すべき位置を演算して該位置に枠要素を移動」することであるのに対し、乙１４の１発明では、「画像データの移動すべき位置を演算して該位置にある固定されている区画に画像データを移動」することである点（相違点１４の１－４） 画像の相対移動に伴い表示領域から離れる分割画像に関する削除処理が、本件各発明では、「表示領域から離れる分割画像に該当する位置から枠要素を削除」することであるのに対し、乙１４の１発明では、「表示区域５１から離れる画像データを固定されている区画から削除」することである点 （相違点１４の１－５） 表示領域に近づく分割画像に関する追加処理が、本件発明１では、「表示領域に近づく分割画像に該当する位置に枠要素を追加して…該追加する枠要素に、該当する位置の分割画像を当てはめ」るのに対し、乙１４の１発明では、「表示区域に近づく画像データを固定されている区画に追加」のみ行う点 （相違点１４の１－７）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバーから送信されるＪａｖａＳｃｒｉｐｔ（登録商標）に基づき実行される」のに対し、乙１４－１発明では、「端末装置３により実行される」ものの、これが「Ｗｅｂブラウザ」、「ＪａｖａＳｃｒｉｐｔ（登録商標）に基づ き実行される」とは明示されていない点 原告らは、乙１４の１発 発明では、「端末装置３により実行される」ものの、これが「Ｗｅｂブラウザ」、「ＪａｖａＳｃｒｉｐｔ（登録商標）に基づ き実行される」とは明示されていない点 原告らは、乙１４の１発明と本件各発明には、上記の相違点のほかに、相違点１４の１－６（本件各発明は、「枠要素」に当てはめられることにより「分割画像」は「表示しまたは表示できる状態」となるのに対し、乙１４の１発明では、「区画」に当てはめられた「画像データ」は常に その全体が表示される点）が存在すると主張する。 しかしながら、本件発明１の請求項の「表示しまたは表示できる状態にし（する）」なる文言は、「表示し」と「表示できる状態にし（する）」が「または」で結ばれているのだから、「表示し」と「表示できる状態にし（する）」の少なくとも一方を選択的に特定しているにすぎず、そ の両方を必須の要件としているわけではない。そうすると、乙１４の１発明の「表示し」の構成は、本件各発明の「表示しまたは表示できる状態」に相当する構成と一致する。 仮に、本件発明１の請求項の「表示しまたは表示できる状態にし（する）」なる文言が、「表示し」と「表示できる状態」の両方が必須のも のとして規定されていると限定解釈したとしても、乙１４の１発明は、 受信した画像データを区画に当てはめるとともに記憶装置に記憶しておき、その画像データが非表示になってもスクロール操作などによってその画像データを表示する必要が生じた場合には、これを記憶装置から読み出して区画に当てはめて表示させることができる状態になっていることからすると、乙１４の１発明は、「表示しまたは表示できる状態にし （する）」との構成を有しているといえる。 ウ相違点の容易想到性 に当てはめて表示させることができる状態になっていることからすると、乙１４の１発明は、「表示しまたは表示できる状態にし （する）」との構成を有しているといえる。 ウ相違点の容易想到性 相違点１４の１－１及び２乙１４の１発明も、サーバ（センター装置２）及びクライアント（端末装置３）が通信回線を通じて通信を行うクライアントサーバシステム である（乙１４文献の段落【００２３】）。したがって、相違点１４の１－１及び２に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（争点２－１（被告の主張）ウ及び）と同じ理由により、容易に想到できるものである。 相違点１４の１－３ 本件各発明では、枠要素を移動することによって、表示領域に表示される分割画像が移動するところ、乙１４の１発明では、画像データ（分割画像）を移動することによって、表示領域に表示される画像データ（分割画像）が移動する。したがって、本件各発明も乙１４の１発明も、表示領域に表示される分割画像が移動する点は一致しており、相違点１４ の１－３は、枠要素を移動するか、分割画像を移動するか、という表現上の違いにすぎないから、実質的な相違点ではない。 仮に実質的に相違するとしても、表示領域に表示させる分割画像を移動させるに当たり、枠要素及び分割画像のいずれを移動するかは、当業者であれば適宜なし得る設計事項であるから、相違点１４の１－３に係 る構成は容易に想到できるものである。 相違点１４の１－４本件各発明では、枠要素を削除することによって当該枠要素に当てはめられていた分割画像が表示領域から非表示となるところ、乙１４の１発明では 相違点１４の１－４本件各発明では、枠要素を削除することによって当該枠要素に当てはめられていた分割画像が表示領域から非表示となるところ、乙１４の１発明では、区画（枠画像）から画像データ（分割画像）を削除することによって当該区画（枠要素）に当てはめられていた画像データ（分割画 像）が表示領域から非表示となる。したがって、本件各発明も乙１４の１発明も、分割画像が表示領域から非表示となる点は一致しており、相違点１４の１－４は、枠要素を削除するか、分割画像を枠要素から削除するか、という表現上の違いにすぎないから、実質的な相違点ではない。 仮に実質的に相違するとしても、表示領域から分割画像を非表示とす るに当たり、枠要素及び分割画像のいずれを削除するかは、当業者であれば適宜なし得る設計事項であるから、相違点１４の１－４に係る構成は容易に想到できるものである。 相違点１４の１－５本件各発明では、枠要素を追加することによって当該枠要素に当ては められる分割画像が新たに表示領域から表示されるところ、乙１４の１発明では、画像データ（分割画像）を区画（枠要素）に追加することによって当該区画（枠要素）に当てはめられる画像データ（分割画像）が新たに表示領域に表示される。したがって、本件各発明も乙１４の１発明も、分割画像が新たに表示領域に表示される点は一致しており、相違 点１４の１－５は、枠要素を追加してこれに分割画像を当てはめるか、分割画像を枠要素に追加するか、という表現上の違いにすぎないから、実質的な相違点ではない。 仮に実質的に相違するとしても、分割画像を表示領域に新たに表示させるに当たり、枠要素を追加してこれに分割画像を当てはめるか、 という表現上の違いにすぎないから、実質的な相違点ではない。 仮に実質的に相違するとしても、分割画像を表示領域に新たに表示させるに当たり、枠要素を追加してこれに分割画像を当てはめるか、分割 画像を追加するかは、当業者であれば適宜なし得る設計事項であるから、 相違点１４の１－５に係る構成は容易に想到できるものである。 相違点１４の１－６相違点１４の１－６に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（争点２－１（被告の主張）ウ）と同じ理由により、容易に想到できるものである。 相違点１４の１－７相違点１４の１－７に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（争点２－１（被告の主張）ウ）と同じ理由により、容易に想到できるものである。 乙１４の２発明 ア乙１４の２発明の内容 乙１４文献記載の第２実施形態には、以下の乙１４の２発明が開示されている。 １４の２ＡＷｅｂブラウザの画像を表示する地図表示画面１５２よりも大きい、日本全国の地域を網羅する広い範囲の地図デー タをマトリクス状に区分し該Ｗｅｂブラウザの地図表示画面１５２にその全体が入る画像データをサーバ装置１０２から優先的にダウンロードして該Ｗｅｂブラウザの地図表示画面１５２に表示する画像表示方法において、１４の２ＢＷｅｂブラウザの地図表示画面１５２にその全体が入る、 Ｗｅｂブラウザの地図表示画面１５２に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域を構成する画像データを、個々に当てはめて表示する地図表示画面１５２に相当する複数の区画の配列をＷｅｂブラウザに設定し、該各区画 対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域を構成する画像データを、個々に当てはめて表示する地図表示画面１５２に相当する複数の区画の配列をＷｅｂブラウザに設定し、該各区画に、該当する位置の画像データをそれぞれ 当てはめて表示し、かつ、 １４の２Ｃ－１ Ｗｅｂブラウザの地図表示画面１５２に対する画像のスクロールが指示された時に、サーバ装置１０２から送信されるＨＴＭＬファイルを実行することによって、表示すべき画像データが記憶装置にキャッシュされていればその画像データを、キャッシュされていなければサー バ装置１０２に要求してサーバ装置１０２から受信した画像データを、固定されている区画にそれぞれ当てはめて表示することによってスクロール処理を行い、１４の２Ｃ－２ 受信した画像データを記憶装置に記憶しておき、区画に当てはめるべき画像データが記憶装置に記憶されてい る場合は、記憶されている画像データを区画に当てはめて表示させることができる１４の２Ｄ 画像表示方法 乙１４の２発明の「地図表示画面１５２」、「地図データ」、「画像データ」及び「区画」は、それぞれ本件発明１の「表示領域」、「画像」、 「分割画像」及び「枠要素」に相当する。 イ一致点及び相違点 乙１４の２発明と本件発明１には、以下の相違点１４の２－３ないし５が存在し、乙１４の２発明と本件発明２１には上記の相違点に加えて相違点１４の２－７が存在するものの、その余は一致する。 （相違点１４の２－３）表示領域に対する画像の相対移動が指示された時に行われる移動処理が、本件各発明では、「枠要素の移動すべき位置を演算して該位置に枠要素を移動」することであるのに対し、乙１４の２発 違点１４の２－３）表示領域に対する画像の相対移動が指示された時に行われる移動処理が、本件各発明では、「枠要素の移動すべき位置を演算して該位置に枠要素を移動」することであるのに対し、乙１４の２発明では「区画」は移動しない点（固定された「区画」に移動させた「画像データ」が当て はめられる。）。 （相違点１４の２－４）画像の相対移動に伴い表示領域から離れる分割画像に関する削除処理が、本件各発明では、「表示領域から離れる分割画像に該当する位置から枠要素を削除」することであるのに対し、乙１４の２発明では、「画像データを固定されている区画から削除」することである点 （相違点１４の２－５）表示領域に近づく分割画像に関する追加処理が、本件各発明では、「表示領域に近づく分割画像に該当する位置に枠要素を追加して…該追加する枠要素に、該当する位置の分割画像を当てはめ」るのに対し、乙１４の２発明では、「地図表示画面１５２」に近づく画像データを固定され ている「区画」に「追加」のみ行う点（相違点１４の２－７）本件発明２１は、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙１４の２発明では、「Ｗｅｂブラウザでの各演算はサーバから送信されるＨＴＭ Ｌファイルにより実行される」ものの、これが「JavaScript（登録商標）に基づき実行される」とは明示されていない点 原告らは、乙１４の２発明と本件各発明には、上記の相違点のほかに、相違点１４の２－６（本件発明１は、「枠要素」に当てはめられることにより「分割画像」は「表示しまたは表示できる状態」となるのに対し、 乙１４の２発明では、「区画」に当てはめられた「画像データ」は常 点１４の２－６（本件発明１は、「枠要素」に当てはめられることにより「分割画像」は「表示しまたは表示できる状態」となるのに対し、 乙１４の２発明では、「区画」に当てはめられた「画像データ」は常にその全体が表示される点）が存在すると主張するが、乙１４の１発明で主張した理由（上記イ）と同じ理由により、乙１４の２発明と本件各発明には、相違点１４の２－６は存在しないというべきである。 ウ相違点の容易想到性 相違点１４の２－３ないし５ ａ 乙１５文献で開示されている発明（以下「乙１５発明」という。）の内容は、表示領域に対する画像のスクロールが指示された時に、表示領域に対するセルの移動すべき位置を演算して該位置にセルを移動し、該画像の相対移動に伴い表示領域から離れる分割領域に該当する位置からセルを消去し、表示領域に近づく分割領域に該当する位置に セルを追加して画像に対するセルの配列の位置を変更し、該追加するセルに、該当する位置の分割領域を当てはめて表示し又は表示できる状態にする画像スクロール方法というものである。したがって、乙１５文献には、相違点１４の２－３ないし５の構成が開示されている。 ｂ 乙１４の２発明は、部分画像を送信するという構成により画像を１ 画面単位で送信するのに比べればスムーズにスクロールできるものの、乙１４文献の段落【００８８】に「端末装置１０３では、ブラウザソフトウェアが上記第３のＨＴＭＬファイル（009_012.htm)を受信すると、ブラウザソフトウェアはその第３のＨＴＭＬファイル（009_012.htm)のプログラムを実行し、このプログラムにより表示指示された画 像データがＲＡＭ１３３にキャッシュされていれば、それを表示し、 ソフトウェアはその第３のＨＴＭＬファイル（009_012.htm)のプログラムを実行し、このプログラムにより表示指示された画 像データがＲＡＭ１３３にキャッシュされていれば、それを表示し、ＲＡＭ１３３にキャッシュされていなければ、その画像データの転送要求をサーバ装置１０２に行う。」という記載があるように、スクロールを行う場合に、表示指示された分割データのうち端末装置１０３内にキャッシュされていない分割画像データを検索してサーバ装置１ ０２に転送を要求する必要があるため、当該処理に時間がかかり、連続的なスクロール自体の実現が困難であるという問題を有している。 これに対し、乙１５文献には「スクロールを行う場合、その途中で未表示データの検索表示が必要になるが、この処理に時間がかかり、連続的なスクロール自体の実現が困難であった。本発明の目的は、こ れらの問題を解決する図形データ表示方法を提案することにある。」 （４９０頁左上欄１７行目から右上欄２行目）と記載されているように、スクロールを行う場合にデータ検索が必要であると処理に時間がかかり、連続的なスクロール自体の実現が困難であるという乙１４の２発明の抱える問題が、乙１５発明によって解決されることが示されている。 そうすると、乙１４の２発明のスクロール処理として、乙１５発明に係るスクロール方法を適用する動機付けがあるから、相違点１４の２－３ないし５に係る構成は、乙１４の２発明に乙１５発明に係るスクロール方法を適用することによって、当業者が容易に想到することができた。 なお、仮に乙１４文献において「キャッシュされていない部分画像を検索する処理に時間がかかる」という課題が明示されていないとしても、 て、当業者が容易に想到することができた。 なお、仮に乙１４文献において「キャッシュされていない部分画像を検索する処理に時間がかかる」という課題が明示されていないとしても、乙１４の２発明及び乙１５発明はいずれも、分割された部分画像を用いた画像表示に係る発明で、スクロール操作をスムーズに行うことを目的とする点で共通し、また、乙１５発明におけるスクロール 処理を乙１４の２発明に適用するのが困難であるという事情も存在しないから、乙１４の２発明に乙１５発明のスクロール方法を適用する動機付けは十分に存在する。 相違点１４の２－７ＨＴＭＬファイルによって演算が行われる乙１４の２発明において、 ＨＴＭＬファイルにJavaScript を組み合わせ、JavaScript に基づいて演算を行うようにすることは、単なる設計事項であるか、周知慣用技術の適用にすぎないから、相違点１４の２－７に係る構成は、当業者であれば容易に想到することができた。 （原告らの主張） 以下のとおり、本件各発明は、乙１４の１発明及び乙１４の２発明と相違し、 当該相違点は容易想到ではないから、乙１４の１発明及び乙１４の２発明との関係で進歩性を有する。 乙１４の１発明についてア乙１４の１発明の内容について乙１４の１発明の内容が、被告主張のとおりであることは、争わない。 イ一致点及び相違点について 乙１４の１発明と本件発明１には、相違点１４の１－１ないし５及び７のほか、以下の相違点１４の１－６が存在し、乙１４の１発明と本件発明２１には、上記の相違点に加えて、以下の相違点１４の１－７が存在する。 （相違点１４の１－６） いし５及び７のほか、以下の相違点１４の１－６が存在し、乙１４の１発明と本件発明２１には、上記の相違点に加えて、以下の相違点１４の１－７が存在する。 （相違点１４の１－６）本件各発明は、「枠要素」に当てはめられることにより「分割画像」は「表示しまたは表示できる状態」となるのに対し、乙１４の１発明では、（演算は）「区画」に当てはめられた「画像データ」は常にその全体が表示される点 （相違点１４の１－７）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバーから送信されるＪａｖａＳｃｒｉｐｔ（登録商標）に基づき実行される」のに対し、乙１４－１発明では、「端末装置３により実行される」ものの、これが「Ｗｅｂブラウザ」、「ＪａｖａＳｃｒｉｐｔ（登録商標）に基づ き実行される」とは明示されていない点 被告は、乙１４の１発明と本件各発明に相違点１４の１－６は存在しないと主張する。 しかしながら、乙１４の１発明は、「画像データ」が、固定された「区画」に当てはめられて常にその全体が「表示区域５１」に表示される発 明であるのに対し、本件各発明は、「枠要素」に当てはめた「分割画像」 について、その画像全体が常には表示されない状態（すなわち、「表示できる状態」）を意図的に設けることによって（構成要件１Ｂ）、相対移動が指示された時に、従前の当てはめを維持しながら、「枠要素」を移動して「表示できる状態」にあった画像を「表示」することにより、上記指示に基づく移動後の画像表示を可能とする構成（構成要件１Ｃ－ １）を備えた発明である。 そうすると、常にその全体の「画像データ」を表示する乙１４の１発明には、「表示しまたは表示できる状態」（構成要件１ 移動後の画像表示を可能とする構成（構成要件１Ｃ－ １）を備えた発明である。 そうすると、常にその全体の「画像データ」を表示する乙１４の１発明には、「表示しまたは表示できる状態」（構成要件１Ｂ等）に相当する構成はないから、乙１４の１発明と本件各発明との間に相違点１４の１－６は存在する。 ウ相違点の容易想到性について被告の乙１４の１発明に基づく進歩性欠如の主張は、相違点１４の１－６に係る構成の容易想到性の主張がないので、失当である。 また、以下のとおり、その余の相違点に係る構成も容易に想到できたとはいえない。 相違点１４の１－１及び２について相違点１４の１－３に係る構成が適用された乙１４の１発明を仮想した場合、この仮想発明に対して相違点１４の１－１及び２に係る構成を適用することは容易でない。 相違点１４の１－３ないし５について 被告は、相違点１４の１－３ないし５は、実質的な相違点ではなく、仮に実質的に相違するとしても、設計事項であって、相違点１４の１－３ないし５に係る構成は容易に想到できると主張する。 しかしながら、乙１４の１発明は、「区画」の大きさ（「画像データ」の縦横の大きさ）を移動量とした飛び飛びの移動態様のスクロールしか 行えない構成であるのに対し、本件各発明は、「枠要素」の大きさ（「分 割画像」の縦横の大きさ）とは無関係に、ドラッグ操作に応じた適宜の量を移動させることができるものであって、両発明のスクロールによる移動の態様は全く異なっているから、相違点１４の１－３ないし５は、実質的な相違点である。 また、乙１４の１発明では、「表示区域５１」に表示されている所定 領域の部分地図が選 のスクロールによる移動の態様は全く異なっているから、相違点１４の１－３ないし５は、実質的な相違点である。 また、乙１４の１発明では、「表示区域５１」に表示されている所定 領域の部分地図が選択された場合、この選択位置に基づく「移動方向テーブル」から決定される移動量に基づいて、「画像データ」の移動先となる「区画」を定め、「画像データ」を移動させる構成により、スクロール処理を実現しており、「画像データ」と共に「区画」を移動させる構成を採用することは全く予定していないのであるから、乙１４の１発 明に相違点１４の１－３ないし５に係る構成を適用することは、当業者が適宜なし得る設計事項とはいえない。 したがって、相違点１４の１－３ないし５に係る構成が容易に想到できたとはいえない。 相違点１４の１－７について 乙１４の１発明に相違点１４の１－１ないし６に係る構成を適用すべき理由はないから、本件発明２１に相違点１４－７に係る構成を適用する前提を欠く。 また、仮に相違点１４の１－３に係る構成が適用された乙１４の１発明を想定した場合、この仮想発明に対して相違点１４の１－７に係る構 成を適用することは容易でない。 乙１４の２発明についてア乙１４の２発明の内容について乙１４の２発明の内容が、被告主張のとおりであることは、争わない。 イ一致点及び相違点について 乙１４の２発明と本件発明１には、相違点１４の２－３ないし５及び ７のほか、以下の相違点１４の２－６が存在し、乙１４の２発明と本件発明２１には、上記の相違点に加えて相違点１４の２－７が存在する。 （相違点１４の２－６）本件各発明は、「枠要素」に当ては ほか、以下の相違点１４の２－６が存在し、乙１４の２発明と本件発明２１には、上記の相違点に加えて相違点１４の２－７が存在する。 （相違点１４の２－６）本件各発明は、「枠要素」に当てはめられることにより「分割画像」は「表示しまたは表示できる状態」となるのに対し、乙１４の２発明で は、「区画」に当てはめられた「画像データ」は常にその全体が表示される点 被告は、乙１４の２発明と本件各発明に相違点１４の２－６は存在しないと主張する。 しかしながら、乙１４の２発明は、ＨＴＭＬファイル（「画像データ」 等を端末装置の表示画面の指定位置に表示させるプログラム）のサーバへの転送要求、ダウンロード等をＷｅｂブラウザで行う点が乙１４の１発明とは異なるものの、「画像データ」が、固定された「区画」に当てはめられて常にその全体が「地図表示画面１５２」に表示される点では、乙１４の１発明と構成を共通にする。したがって、乙１４の１発明と本 件各発明に相違点１４の１－６が存在するのと同様の理由（上記イ）により、乙１４の２発明と本件各発明にも相違点１４の２－６が存在するというべきである。 ウ相違点の容易想到性について被告の乙１４の２発明に基づく進歩性欠如の主張は、相違点１４の２－ ６に係る構成の容易想到性の主張がないので、失当である。 また、以下のとおり、その余の相違点に係る構成も容易に想到できたとはいえない。 相違点１４の２－３ないし５について乙１５発明は、相違点１４の２－３ないし５に係る構成を備えない。 この点を措くとしても、乙１４の２発明では、「Ｗｅｂブラウザの地 図表示画面１５２」に表示されている所定領域の部分地図が選 相違点１４の２－３ないし５に係る構成を備えない。 この点を措くとしても、乙１４の２発明では、「Ｗｅｂブラウザの地 図表示画面１５２」に表示されている所定領域の部分地図が選択された場合、この選択位置に基づく転送要求により送信を受けたＨＴＭＬファイルを実行し、「画像データ」を固定されている「区画」に適宜当てはめることにより、スクロール処理を実現しており、「画像データ」と共に「区画」を移動させる構成を採用することは、全く予定していない。 また、被告は、スクロールを行う場合にデータ検索が必要であると処理に時間がかかるため、連続的なスクロール自体の実現が困難であるという乙１４の２発明の抱える問題が、乙１５発明によって解決されると主張する。しかしながら、乙１４の２発明は、端末装置にキャッシュされていない部分のＨＴＭＬファイルのみを対象として転送を受けて画像 を表示する構成により、ネットワーク上でのデータ転送量の削除、効率化という課題を解決するとともに、サーバに対する「画像データ」を固定されている「区画」に適宜当てはめる構成により、スクロール処理を行うことによって、スムーズなスクロール操作を可能とした発明であり（段落【０１０９】、【０１１０】）、乙１４の２発明に被告が主張す るような問題はない。 さらに、「デスクトップアプリケーションの地図であれば、よくある機能だ。しかし、それ以前のＷｅｂ地図サービスにドラッグはなく…」というネット記事（甲３）の記載があるように、本件特許出願時点における当業者は、Ｗｅｂブラウザに「枠要素」を設定してスクロールさせ る地図を想到できなかったのであるから、Ｗｅｂブラウザとは別のアプリケーションを対象とする乙１５発明で相違点１４の２－３ないし５に係る構成が実現でき ウザに「枠要素」を設定してスクロールさせ る地図を想到できなかったのであるから、Ｗｅｂブラウザとは別のアプリケーションを対象とする乙１５発明で相違点１４の２－３ないし５に係る構成が実現できているからといって、Ｗｅｂブラウザを対象とした乙１４の２発明に乙１５発明を適用できたということにはならない。 したがって、乙１４の２発明に乙１５発明を適用して相違点１４の２ －３ないし５に係る構成を想到し得たとはいえない。 相違点１４の２－７について相違点１４の２－７の容易想到性に関する被告の主張は、失当である。 ７ 争点２－３（乙２２文献を主引例とする進歩性欠如の有無）について（被告の主張）以下のとおり、本件各発明は、乙２２文献に記載された発明（以下「乙２２ 発明」という。）に基づき当業者は容易に想到し得たものであるから、進歩性を欠く。 乙２２発明の内容ア乙２２文献には、以下の乙２２発明が開示されている。なお、原告らは、乙２２Ａの構成に関し、「（ただし、該当する「地図データ」であっても 表示サイズが最小表示サイズより小さいものはダウンロードされない。）」との構成を追加するが、同構成は、乙２２文献に係る特許の従属項で付加された構成にすぎないから、乙２２文献から上記構成を備えない発明を認定できることは明らかである。 ２２ＡＷｅｂクライアントの地図を表示するディスプレイ表示範囲よ りも大きい地図データを分割し該Ｗｅｂクライアントのディスプレイ範囲に少なくとも一部が入るメッシュ分割した地図データをサーバから優先的にダウンロードして該Ｗｅｂクライアントのディスプレイ表示範囲に表示する地図表示方法において、２２ＢＷｅｂクライアントのディスプレイ表示範囲に少なく メッシュ分割した地図データをサーバから優先的にダウンロードして該Ｗｅｂクライアントのディスプレイ表示範囲に表示する地図表示方法において、２２ＢＷｅｂクライアントのディスプレイ表示範囲に少なくとも一部 が入るメッシュ分割した地図データを含む、Ｗｅｂクライアントのディスプレイ表示範囲に対し所定の位置関係にある、地図データ全体に対して限定された範囲の地図領域に含まれるメッシュ分割した地図データを、個々に当てはめて表示するディスプレイ表示範囲に相当する複数の領域の配列をＷｅｂクライアントに設定し、該各領 域に、該当する位置のメッシュ分割した地図データをそれぞれ当て はめて表示しまたは表示できる状態にし、かつ、２２Ｃ－１ Ｗｅｂクライアントのディスプレイ表示範囲に対する地図の相対移動が指示された時に、Ｗｅｂクライアントのディスプレイ表示範囲に対する領域の移動すべき位置を演算して該位置に領域を移動し、 ２２Ｃ－２ 該地図の相対移動に伴いＷｅｂクライアントのディスプレイ表示範囲から離れるメッシュ分割した地図データに該当する位置から領域を削除し、Ｗｅｂクライアントのディスプレイ表示範囲に近づくメッシュ分割した地図データに該当する位置に領域を追加して地図に対する領域の配列の位置を変更し、 該追加する領域に、該当する位置のメッシュ分割した地図データを当てはめて表示しまたは表示できる状態にし２２Ｄ 前記演算はＷｅｂクライアントにより実行される地図表示方法イ乙２２発明の「地図（データ）」、「ディスプレイ表示範囲」、「メッシュ分割した地図データ」、「領域」、及び「地図表示方法」は、それぞ れ本件各発明の「画像」、「表示領域」、「分割画像」、「枠要素」、「画像表示方法」に相当する ディスプレイ表示範囲」、「メッシュ分割した地図データ」、「領域」、及び「地図表示方法」は、それぞ れ本件各発明の「画像」、「表示領域」、「分割画像」、「枠要素」、「画像表示方法」に相当する。 ウこれに対し、原告らは以下のとおり主張するが、いずれも理由がない。 原告らは、乙２２文献には、「枠要素」に相当する構成や画像を「当てはめ」る構成の開示がないと主張する。 しかしながら、乙２２文献の【図１１】には、データ要求範囲に係る４×４の個々の区画が記載されているところ、【図８】にデータ要求範囲に係る個々の区画が「領域」と表記されている。また、乙２２文献では、「メッシュ番号は、地図のデータの範囲を含む矩形領域を任意の矩形サイズで分割した領域に振られる番号であり、例えば北海道の地図デ ータを作成する場合の、メッシュ番号の採番状況を示したのが図９であ る。」、「地図をディスプレイ上に表示する場合、ディスプレイ上の左下の表示すべき緯度・経度及び表示倍率が指定されれば、ディスプレイに表示する４角の緯度・経度の座標が求められる。この４角の緯度・経度の座標を地図データのマクロ座標に変換し、そのマクロ座標が含まれるメッシュ番号を求めると、サーバーに要求すべきメッシュ番号の範囲 が求められる。」、「１データの表示領域の指定には、メッシュ・レイヤーインデックスファイルで管理するこのメッシュ番号を指定する。このことにより、表示領域を直ちに指示することが可能となる。」という記載（段落【００２６】）によって、Ｗｅｂクライアントにおいてメッシュ分割した地図データに付されたメッシュ番号を指定すれば、ディス プレイ表示範囲との関係で、表示領域（「領域」）の位置とサイズが特定されるものであることが示されている。これら トにおいてメッシュ分割した地図データに付されたメッシュ番号を指定すれば、ディス プレイ表示範囲との関係で、表示領域（「領域」）の位置とサイズが特定されるものであることが示されている。これらを踏まえると、【図１１】の示す４×４の区画は、「領域」であり、ディスプレイ表示範囲との関係で位置と大きさが特定され、Ｗｅｂクライアントに設定されているものと理解できる。 【図１１(A)】【図８】 【図９】 そして、乙２２文献には、「Ｗｅｂクライアントからの地図データ要求では、図８に示すようにデータ種別（レイヤー番号）と１データの表示領域（メッシュ番号）を指定する形式で、複数回の要求を行うことによって、必要範囲の地図データをＷｅｂサーバーから取得する。」とい う記載（段落【００２４】）があるところ、【図８】も参照すれば、乙２２文献の地図表示方法では、ディスプレイ表示範囲との関係で位置及びサイズが特定される各「領域」（表示領域）につき、（メッシュ番号で特定された）各メッシュ分割した地図データを要求し、これを受信して、各「領域」に対応づけて各メッシュ分割した地図データを表示する ものと理解されるから、各「領域」に、各「メッシュ分割した地図データ」を「当てはめ」る構成が開示されている。 また、原告らは、乙２２文献における地図表示処理では、「枠要素」は不要であるから、「枠要素」という概念が存在する余地はないと主張する。 しかしながら、上記のとおり、乙２２文献には、「枠要素」に相当する構成として「領域」（表示領域）という構成が明確に開示されている。 ある構成が必要か否かの問題と、ある構成が開示されているかどうかは全く別の問題であるから、原告らの上記主張は、「枠要素」に相当す する構成として「領域」（表示領域）という構成が明確に開示されている。 ある構成が必要か否かの問題と、ある構成が開示されているかどうかは全く別の問題であるから、原告らの上記主張は、「枠要素」に相当する構成の開示を否定する理由にならない。 さらに、原告らは、乙２２文献には、地図データを表示できる状態にする構成の開示はないと主張する。 しかしながら、争点２－１（被告の主張）のとおり、本件各発明は、「表示しまたは表示できる」と選択的に規定されているのであるから、「表示」（する）と「表示できる」のいずれかを満たせば足りるのであ って、原告らの上記主張は乙２２発明の認定とは無関係である。もとより、乙２２文献の段落【００１４】、【００１５】、【００３２】の記載によれば、個々の「領域」に対応付けられた（当てはめられた）地図データのうち、表示対象外の地図データも表示できるように保持されているのであるから、乙２２発明が「地図データを…表示できる状態」に する構成を備えていることは明らかである。 原告らは、乙２２文献の地図表示方法は、枠要素に相当する構成が移動するものではないから、乙２２文献には、「移動すべき位置を演算して該位置に…移動し」との構成の開示がないと主張する。 しかしながら、乙２２文献の段落【００２９】や【図１１】の記載に よれば、乙２２文献における「領域」は、ディスプレイ表示範囲との関係で（相対的に）移動するものである。そして、乙２２公報の段落【００２６】の記載によれば、上記の「領域」の移動が、緯度・経度等から領域の移動すべき位置を演算することにより行われていることは明らかであるから、乙２２文献には、「移動すべき位置を演算して該位置に… 移動し」との構成が開示されている。仮に、新たな ・経度等から領域の移動すべき位置を演算することにより行われていることは明らかであるから、乙２２文献には、「移動すべき位置を演算して該位置に… 移動し」との構成が開示されている。仮に、新たな地図データ要求のため、地図データ要求範囲が再計算されるとしても、【図１１】のとおり、メッシュ番号で特定された各「領域」がディスプレイ表示範囲との関係で移動しているのであるから、地図データ要求範囲の再計算は、上記構成の開示を否定するものとはいえない。 原告らは、乙２２文献は「地図データ」を「枠要素」に相当する領域 に「当てはめ」て表示する構成を開示するものではないから、その「削除」「追加」を観念することはできないと主張する。 しかしながら、乙２２文献に、各「領域」に各「メッシュ分割した地図データ」を「当てはめ」る構成が開示されていることは、上記のとおりである。そして、乙２２文献では、「現在表示対象の領域以外で利用 頻度の少ない領域のデータ順に、利用しなくなった地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することにより、メモリ使用の最適化を図ることができる。」（段落【００３２】）などの記載により、地図の相対移動に伴いＷｅｂクライアントのディスプレイ表示範囲から離れるメッシュ分割した地図データに該当する位置から 領域のデータが削除されることが、段落【００２１】、【００２８】ないし【００３２】、【図５】、【図１１】等の記載により、ディスプレイの表示範囲の外側にあるメッシュ分割された地図データを先読みで要求する構成のものも含め、Ｗｅｂクライアントのディスプレイ表示範囲に近づくメッシュ分割した地図データに該当する位置に領域を追加して 地図に対する領域の配列の位置を変更し、該追加する 先読みで要求する構成のものも含め、Ｗｅｂクライアントのディスプレイ表示範囲に近づくメッシュ分割した地図データに該当する位置に領域を追加して 地図に対する領域の配列の位置を変更し、該追加する領域に、該当する位置のメッシュ分割した地図データを当てはめて表示しまたは表示できる状態にすることが開示されている。 【図１１】 一致点及び相違点乙２２発明と本件発明１には、以下の相違点２２－１及び２が存在し、乙２２発明と本件発明２１には上記の相違点に加えて、相違点２２－５が存在するものの、その余は一致する。 （相違点２２－１）本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙２２発明の「表示領域」は、「Ｗｅｂクライアントのディスプレイ表示領域」とされている点（相違点２２－２） 本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙２２発明では、「Ｗｅｂクライアント」に設定するものとされている点 （相違点２２－５）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙２２発明では、「演算はＷｅｂクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」、「JavaScript（登録商標）に基づき実行される」とは明示され ていない点 相違点の容易想到性ア相違点２２－１乙２２発明は、Ｗｅｂクライアントを用いた発明であるところ、Ｗｅｂクライアントとして、Ｗｅｂブラウザを用いることは周知慣用技術となっ ていたから（乙１１ないし１３）、乙２２発明に触れた当業者には、乙２２発明のＷｅｂクラ ントを用いた発明であるところ、Ｗｅｂクライアントとして、Ｗｅｂブラウザを用いることは周知慣用技術となっ ていたから（乙１１ないし１３）、乙２２発明に触れた当業者には、乙２２発明のＷｅｂクライアントとして、Ｗｅｂブラウザを用いる構成を採用する強い動機付けがあった。 したがって、相違点２２－１に係る構成は容易に想到することができた。 イ相違点２２－２ 乙２２発明においてＷｅｂブラウザを用いる構成を採用すれば、「枠要素の配列」は、Ｗｅｂブラウザに設定されることになるから、相違点２２－２に係る構成は容易に想到することができた。 ウ相違点２２－５争点２－１（被告の主張）で主張した理由と同様の理由により、相違点 ２２－５に係る構成は容易に想到することができた。 エ仮に被告が認める相違点以外の相違があるとしても、実質的な相違点でないか、その相違に係る構成が容易想到なものにすぎない。 （原告らの主張）以下のとおり、本件各発明は、乙２２発明と相違し、当該相違点は容易想到 ではないから、乙２２発明との関係で進歩性を有する。 乙２２発明の内容についてア被告は、乙２２文献の【図８】、【図１１】を根拠に、乙２２文献には、「枠要素」に相当する「領域」がＷｅｂクライアントに設定されることが開示されていると主張する。 しかしながら、これらの図で示されている矩形領域は、一つの束として 要求可能な「地図データ」（「道路、鉄道、行政界等」のデータ）の範囲を示すものにすぎず（【図１１】は、指示されたディスプレイ表示範囲と「地図データ」の要求範囲の関係を説明するための概念図にすぎない。）、「枠要素」に相当する構成を開示するものではない。 また、被告は、乙２２文 すぎず（【図１１】は、指示されたディスプレイ表示範囲と「地図データ」の要求範囲の関係を説明するための概念図にすぎない。）、「枠要素」に相当する構成を開示するものではない。 また、被告は、乙２２文献の段落【００２４】及び【図８】を根拠に、 乙２２文献には、地図データの「当てはめ」の構成が開示されていると主張する。 しかしながら、段落【００２４】は、ＷｅｂクライアントとＷｅｂサーバの間における「地図データ」のやりとりを記載するものにすぎず、地図データを表示する際の「当てはめ」とは無関係な記載にすぎない。また、 【図８】は受信した「地図データ」を表示した場合に、所定の（二次元）領域に表示されることを示すものにすぎず、設定された（二次元）領域に「地図データ」が「当てはめ」られる関係にあることなど示していない。 そもそも、乙２２文献における「地図データ」は、数値データ（ベクタデータ）であるところ（同段落【００３４】）、単にこのベクタデータに 基づいて表示を行う場合に、ビューアに設定され、「当てはめ」を行う何らかの領域の存在は必要とされない。実際、乙２２文献における地図表示処理では、ディスプレイ上に表示する４角の緯度、経度の範囲に含まれる地図データを基に描画して表示しているにすぎないのであるから、「枠要素」に相当する概念が必要となる余地はない。 さらに、被告は、乙２２文献には、地図データを表示できる構成の開示 はあると主張するが、上記のとおり、乙２２文献には、地図データを「枠要素」に「当てはめ」て表示する構成の開示はないことから、乙２２文献は、「当てはめ」を前提とした「表示できる状態」を当然に開示するものではない。 イ被告は、乙２２文献の段落【００２９】及び【図１１】を根拠として、 構成の開示はないことから、乙２２文献は、「当てはめ」を前提とした「表示できる状態」を当然に開示するものではない。 イ被告は、乙２２文献の段落【００２９】及び【図１１】を根拠として、 乙２２文献には、「移動すべき位置を演算して該位置に…移動し」との構成の開示があると主張する。 しかしながら、乙２２文献の地図表示方法における表示領域の変更は、地図データの要求範囲を再度計算し、この要求に基づき送信を受けた「地図データ」をもとに表示するだけのことであり、「枠要素」に相当する構 成が移動するものではないから、乙２２文献に「移動すべき位置を演算して該位置に…移動し」の構成の開示はない。 ウ被告は、乙２２文献には、「（二次元）領域」を「削除」、「追加」する構成の開示があると主張する。 しかしながら、上記アのとおり、乙２２文献は「地図データ」を「枠要 素」に相当する領域に「当てはめ」て表示する構成を開示するものではないから、その「削除」、「追加」を観念することはできない。 エしたがって、乙２２文献に開示されている乙２２発明の内容は、以下のものとなる。 ２２ＡＷｅｂクライアントの地図を表示するディスプレイ表示範囲よ りも大きい地図データを分割し該Ｗｅｂクライアントのディスプレイ範囲に少なくとも一部が入るメッシュ分割した地図データをサーバから優先的にダウンロードして（ただし、該当する「地図データ」であっても表示サイズが最小表示サイズより小さいものはダウンロードされない。）該Ｗｅｂクライアントのディスプレイ表示範囲に 表示する地図表示方法において、 ２２ＢＷｅｂクライアントのディスプレイ表示範囲に少なくとも一部が入るメッシュ分割した地図データを含む、Ｗｅｂクライアン レイ表示範囲に 表示する地図表示方法において、 ２２ＢＷｅｂクライアントのディスプレイ表示範囲に少なくとも一部が入るメッシュ分割した地図データを含む、Ｗｅｂクライアントのディスプレイ表示範囲に対し所定の位置関係にある、地図データ全体に対して限定された範囲のメッシュ分割した地図データを、ディスプレイ表示範囲に表示すべき地図の表示要求（「例えばディスプ レイ上に表示すべき地図の左下の緯度、経度、表示すべき地図のデータ種別、表示倍率、最小表示サイズ」）に基づいて表示し、かつ、２２Ｃ－１ Ｗｅｂクライアントのディスプレイ表示範囲に対する地図の相対移動が指示された時に、移動後の地図の位置を演算してＷｅｂクライアントのディスプレイ表示範囲に表示すべき地 図の表示要求に基づいて既に保持している各地図データを表示し、２２Ｃ－２ 該地図の相対移動に伴いＷｅｂクライアントのディスプレイ表示範囲に近づくメッシュ分割した地図データをメモリに追加し、その追加により地図データの容量がメモリの記憶容量 を上回る場合には利用しなくなったメッシュ分割した地図データをメモリから削除し、移動後の地図の位置を演算してＷｅｂクライアントのディスプレイ表示範囲に表示すべき地図の表示要求に基づいて保持している各地図データを表示し２２Ｄ 前記演算はＷｅｂクライアントにより実行される地図表示方法 一致点及び相違点について乙２２発明と本件発明１には、相違点２２－１のほか、相違点１０－２´、３及び４と同様の相違点２２－２´、３及び４が存在し、乙２２発明と本件発明２１には、上記の相違点に加えて相違点２２－５が存在する。 相違点の容易想到性について 容易想到性に関する被告の主張は、乙２２発明と本 －２´、３及び４が存在し、乙２２発明と本件発明２１には、上記の相違点に加えて相違点２２－５が存在する。 相違点の容易想到性について 容易想到性に関する被告の主張は、乙２２発明と本件各発明の相違点を正 しく認定することなく、誤った相違点を前提として、これらの相違点は容易に解消されると主張するものにすぎず、失当である。 そもそも、乙２２発明は、「枠要素」がなくても、所定の位置に所定の地図を各「地図データ」に基づいて表示できる構成を有しているのであるから、乙２２発明にあえて「枠要素」に関する構成を採用する理由はない。また、 仮に乙２２発明に「枠要素」に関する構成を適用した場合であっても、乙２２文献では乙２２発明の画像表示方法を「Ｗｅｂブラウザ」をクライアントに備えることは全く予定されていないから、その表示領域を「Ｗｅｂブラウザの表示領域」とし、また、演算を「Ｗｅｂブラウザで」、「JavaScript（登録商標）に基づき実行される」構成に変更することの動機付けはない。 ８ 争点２－４（乙２３文献を主引例とする新規性・進歩性欠如の有無）について（被告の主張）以下のとおり、本件発明１は、乙２３文献に記載された発明（以下「乙２３発明」という。）と同一であるから新規性を欠く。また、本件発明２１は、乙 ２３発明に基づき当業者が容易に想到し得たものであるから、進歩性を欠く。 乙２３発明の内容ア乙２３文献には、以下の乙２３発明が開示されている。 ２３Ａ ウェブブラウザの画像を表示する表示範囲より大きい地図データを多数のメッシュに分割し該ウェブブラウザの表示範囲に少なくと も一部が入るメッシュに対応するファイル（各地図データが含まれる。以下同じ。）をサーバ 画像を表示する表示範囲より大きい地図データを多数のメッシュに分割し該ウェブブラウザの表示範囲に少なくと も一部が入るメッシュに対応するファイル（各地図データが含まれる。以下同じ。）をサーバから優先的にダウンロードして該ウェブブラウザの表示範囲に表示する地図表示方法において、２３Ｂ ウェブブラウザの表示範囲に少なくとも一部が入るメッシュに対応するファイルを含み、ウェブブラウザの表示範囲に表示される、 地図データ全体に対して限定された範囲の複数のメッシュに対応す る複数のファイルをダウンロードし、キャッシュ領域における所定の格納位置にそれぞれ格納し、キャッシュ領域における所定の各格納位置に格納された各ファイルを読み出してウェブブラウザの表示範囲における該当の領域にそれぞれ表示し、かつ、２３Ｃ－１ ウェブブラウザの表示範囲に対する地図のスクロール操作 がされると、地図の表示すべき範囲をウェブブラウザの地図表示プログラムが決定し、キャッシュ領域における所定の格納位置に残っているメッシュに対応するファイルを読み出して、ウェブブラウザの表示範囲における該当の領域に表示し、表示される地図をユーザの望む方向に変化させ、 ２３Ｃ－２ 表示される地図の変化に連れて、ウェブブラウザの表示範囲から離れるメッシュに対応するファイルをキャッシュ領域における所定の格納位置から削除し、ウェブブラウザの表示範囲に近づくメッシュに対応するファイルをダウンロードし、キャッシュ領域における前記削除された格納位置に格納し、ウェブ ブラウザの表示範囲における該当の領域に表示し、２３Ｄ 演算はウェブブラウザの地図表示プログラムにより実行される、地図表示方法。 イ乙２３発明の「地図データ」、「ウェブブラウザの表示範 ブラウザの表示範囲における該当の領域に表示し、２３Ｄ 演算はウェブブラウザの地図表示プログラムにより実行される、地図表示方法。 イ乙２３発明の「地図データ」、「ウェブブラウザの表示範囲」及び「地図表示方法」は、それぞれ構成要件１Ａ及び１Ｄの「画像（分割画像）」、 「Ｗｅｂブラウザの表示領域」、及び「画像表示方法」に相当する。 また、乙２３発明において、ダウンロードされた各地図データは「ウェブブラウザの表示範囲における該当の領域にそれぞれ表示」されるから、この「領域」はウェブブラウザに設定されるといえる。よって、この「領域」は、構成要件１Ｂの「Ｗｅｂブラウザに設定」されて「分割画像」を 「それぞれ当てはめ」る「枠要素」に相当する。 さらに、乙２３発明の「地図の表示すべき範囲をウェブブラウザの地図表示プログラムが決定」、「キャッシュ領域における所定の格納位置に残っているメッシュに対応するファイルを読み出して、ウェブブラウザの表示範囲における該当の領域に表示」、「ウェブブラウザの表示範囲から離れるメッシュに対応するファイルをキャッシュ領域における所定の格納 位置から削除」、「ウェブブラウザの表示範囲に近づくメッシュに対応するファイルをダウンロードし、キャッシュ領域における前記削除された格納位置に格納し、ウェブブラウザの表示範囲における該当の領域に表示」するは、それぞれ構成要件１Ｃの「Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算」、「枠要素を移動」、「Ｗｅｂブラウザの 表示領域から離れる分割画像に該当する位置から枠要素を削除」、「Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当す 域から離れる分割画像に該当する位置から枠要素を削除」、「Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする」に相当する。 ウこれに対し、原告らは、乙２３発明における「領域」は「枠要素」に相当する構成ではないと主張する。 しかしながら、乙２３発明における「領域」は、乙２３文献に「…地図画像を描画して、ディスプレイ画面の対応する領域に表示する（Ｓ１３）。」という記載（段落【００５９】）があるように、ディスプレイ画面（ウェ ブブラウザ）に複数の「領域」が設定され、それに対応する「地図画像」を表示するものであるから、「枠要素」に相当する構成である。 また、原告らは、乙２３発明における「領域」が「ウェブブラウザに設定されていない」ことを前提に、乙２３発明では、構成要件１Ｃの「移動」、「削除」、「追加」に相当する構成を観念できないと主張する。 しかしながら、上記のとおり、乙２３文献における「領域」はウェブブ ラウザに設定されるものであるから、原告らの上記主張は前提を欠く。 一致点及び相違点ア本件発明１との一致点及び相違点乙２３発明は本件発明１と一致し、相違点はない。 イ本件発明２１との一致点及び相違点 乙２３発明と本件発明２１には、以下の相違点２３－５が存在するものの、その余は一致する。 （相違点２３－５）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙２３発明で は、演算はウェブブラウザ ２３－５）本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙２３発明で は、演算はウェブブラウザの地図表示プログラムが行うものの、これが「JavaScript（登録商標）に基づき実行される」とは明示されていない点 相違点の容易想到性ア本件発明１の容易想到性上記アのとおり、乙２３発明と本件発明１に相違点はないが、仮に相 違点が存在するとしても、その相違点に係る構成は容易想到なものにすぎない。 イ本件発明２１の容易想到性争点２－１（被告の主張）で主張した理由と同様の理由により、相違点２３－５に係る構成は容易に想到できた。 （原告らの主張）以下のとおり、本件各発明は、乙２３発明と相違し、当該相違点は容易想到ではないから、乙２３発明との関係で新規性、進歩性を有する。 乙２３発明の内容乙２３発明の内容は、被告主張のとおりであるものの、乙２３発明は「枠 要素」に相当する構成や、「枠要素」の「移動」、「削除」、「追加」に相 当する構成を備えない。 これに対し、被告は、「該当の領域」に所定の「地図データ」が表示されることを理由として、乙２３発明における「領域」が「枠要素」に相当する構成であると主張する。 しかしながら、乙２３文献には、地図をディスプレイ表示領域に表示する に当たり、被告が主張する「領域」をウェブブラウザに設定することや、この「領域」に「地図データ」を当てはめることの記載はない。また、乙２３発明は、ある地図データが複数の「メッシュ」に跨る位置にある場合に所定のメッシュのみに「地図データ」も含ませる構成を備えるにもかか の「領域」に「地図データ」を当てはめることの記載はない。また、乙２３発明は、ある地図データが複数の「メッシュ」に跨る位置にある場合に所定のメッシュのみに「地図データ」も含ませる構成を備えるにもかかわらず、被告は、このような領域からなる「地図データ」を当てはめることができる 領域をどのようにウェブブラウザに設定しているかについて全く明らかにしていない。そもそも、乙２３発明では、乙２２発明と同様、その表示範囲の所定の位置に所定の画像を表示するために「枠要素」は必須ではない。 また、被告は、乙２３発明は、「枠要素」の「移動」、「削除」、「追加」に相当する構成を備えていると主張するが、ウェブブラウザに設定されてい ない「領域」について、スクロール処理における移動、削除、追加を観念することはできない。 一致点と相違点について乙２３発明と本件発明１には、相違点１０－２´、３及び４と同様の相違点２３－２ないし４が存在し、乙２３発明と本件発明２１には、上記の相違 点に加えて相違点２３－５が存在する。 相違点の容易想到性について容易想到性に関する被告の主張は、乙２３発明と本件各発明の相違についての誤った理解を前提として、これらの相違点は容易に解消されると主張するものにすぎず、失当である。 そもそも、乙２３発明は、「枠要素」がなくても、所定の位置に所定の地 図を各「地図データ」に基づいて表示できる構成を有しているのであるから、乙２３発明にあえて「枠要素」に関する構成（相違点２３－２ないし４）を採用する理由はない。 また、乙２３文献の「地図表示プログラム」は「プラグインソフトウエアのような形で付属している」プログラムであるところ（段落【００２６】）、 このようなプラグイン し４）を採用する理由はない。 また、乙２３文献の「地図表示プログラム」は「プラグインソフトウエアのような形で付属している」プログラムであるところ（段落【００２６】）、 このようなプラグインソフトウエアによる演算がJavaScript により実行されることが周知慣用技術であることは明らかでないから、相違点２３－５に係る構成が容易に想到できたとはいえない。 ９ 争点２－５（明確性要件違反の有無）について（被告の主張） 以下のとおり、本件発明１の請求項には及びの明確性要件違反が、本件発明２１の請求項にはないしの明確性要件違反が、それぞれ認められる。 「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係（構成要件１Ｂ、１Ｃ）本件発明１の請求項には「複数の枠要素の配列をＷｅｂブラウザに設定し、 該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除 し」（構成要件１Ｂ、１Ｃ）と記載されているから、本件各発明では、「Ｗｅｂブラウザの表示領域」に対する「分割画像」の移動は、「分割画像」が当てはめられた「枠要素」を移動させることによって行われるものと解される。 しかしながら、本件発明１の請求項には「Ｗｅｂブラウザの表示領域に対 する画像の相対移動が指示された時に、…Ｗｅｂブラウザの表示領域に近づ く分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位 Ｗｅｂブラウザの表示領域に対 する画像の相対移動が指示された時に、…Ｗｅｂブラウザの表示領域に近づ く分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする」（構成要件１Ｃ）と記載され、「枠要素」に当てはめられていない「分割画像」であっても「表示領域に近づく」ことがあるとされている。 したがって、本件発明１の請求項の記載では、「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係を整合的に理解することができない。 「枠要素」（構成要件１Ｂ等）本件発明１の請求項には「各枠要素に、…分割画像をそれぞれ当てはめて 表示しまたは表示できる状態にし」（構成要件１Ｂ）、「枠要素に、…分割画像を当てはめて表示しまたは表示できる状態にする」（構成要件１Ｃ－２）と記載されているから、分割画像が当てはめられた枠要素には、分割画像が表示されるものと、分割画像が表示されないが表示できる状態のものの２つの種類があるものと理解される。 しかしながら、本件発明１の請求項には「分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素」（構成要件１Ｂ）と記載され、「分割画像」が当てはめられた「枠要素」は、「分割画像」の全体を必ず表示するとされている。 したがって、本件発明１の請求項の記載では、いくら明細書等の記載を参 酌しても枠要素の意義を整合的に理解することはできない。 「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）本件発明１では、「移動すべき位置を演算」（構成要件１Ｃ－１）することについて、Ｗｅｂブラウザでの演算に限定していないから、本件発明 。 「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）本件発明１では、「移動すべき位置を演算」（構成要件１Ｃ－１）することについて、Ｗｅｂブラウザでの演算に限定していないから、本件発明２１の「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）が何を指すのか不 明である。 （原告らの主張）以下のとおり、本件各発明の請求項に被告の主張する明確性要件違反はない。 「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係（構成要件１Ｂ、１Ｃ）について本件各発明の「分割画像」とは、画像全体の一部を構成する画像であり、 「枠要素」への当てはめの有無にかかわらず、「分割画像」相互の位置関係は定まっているから、「Ｗｅｂブラウザの表示領域に近づく」、「分割画像」は特定されている。 したがって、「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係について、請求項の記載に第三者に不測の不利益を及ぼすほどに 不明確なものはない。 「枠要素」（構成要件１Ｂ等）について「枠要素」は、構成要件１Ｂで「分割画像を、個々に当てはめて表示する…複数の枠要素」と規定されているとおり、当てはめられた「分割画像」をＷｅｂブラウザの表示領域に表示する要素であるものの、実際の画像表示で は、当てはめられた「分割画像」の全体が常に表示される関係にはないため、構成要件１Ｂ、１Ｃ－２は、「分割画像を当てはめて表示しまたは表示できる状態に」すると規定しているのであるから、これらの記載を整合的に理解することは容易である。 「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）について 本件発明１の構成要件１Ｃ－１は、「相対移動が指示された時に、Ｗｅｂブラウザの らの記載を整合的に理解することは容易である。 「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）について 本件発明１の構成要件１Ｃ－１は、「相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算」と規定する。 そして、本件発明１に従属する本件発明２１の構成要件２１Ａは、この順次なされる「相対移動」において、「枠要素」の移動すべき位置の「演算」を「JavaScript（登録商標）に基づき実行される」ことを規定する。 そうすると、構成要件２１Ａの「前記Ｗｅｂブラウザでの各演算」の意義 に不明確な点はない。 争点２－６（サポート要件違反、実施可能要件違反及び補正要件違反の有無）について（被告の主張）以下のとおり、本件各発明には、サポート要件、実施可能要件及び補正要件 の各違反が存在する。 「枠要素」（構成要件１Ｂ等）に関するサポート要件及び実施可能要件違反仮に、構成要件１Ｂ等の「枠要素」にコンテナ要素以外のものが含まれ、例えば、img タグのstyle 属性の設定だけでも「枠要素」に該当するという のであれば、本件各発明では、Ｗｅｂブラウザの種類によっては画像の配置及び移動ができないことになる。 そうすると、本件各発明は、そもそも「画像表示方法を実現する方法を提供しようとする」（本件明細書等の段落【０００６】）という本件各発明の課題を解決することができない構成を含み、かつ、当業者が実施することの できない構成まで含んでしまうことになる。 したがって、仮に、「枠要素」にコンテナ要素以外のものが含まれるとすると、本件各発明は、サポート要件及び実施可能要件に違反する。 「枠要素の移動すべき位置を演算し 含んでしまうことになる。 したがって、仮に、「枠要素」にコンテナ要素以外のものが含まれるとすると、本件各発明は、サポート要件及び実施可能要件に違反する。 「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）に関するサポート要件違反及び補正要件違反 仮に、平成１９年１１月１２日付け手続補正書（乙２５の４）による補正によって新たに追加された構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に、枠要素の親要素やその親要素の移動すべき位置を演算して、枠要素の親要素やその親要素と枠要素を一体的に移動させる構成が含まれるとすると、上記構成やその技術的意義（移動させる 画像数に関係なく演算量を一定にする。）は、本件明細書等に開示はなく、 願書に最初に添付した明細書、特許請求の範囲及び図面にも記載されていないため、本件各発明は、発明の詳細な説明に記載された発明ではないことになるし、上記補正も、願書に最初に添付した明細書、特許請求の範囲又は図面の全ての記載を総合することにより導かれる技術的事項との関係において、新たな技術的事項を導入するものということになる。 また、仮に、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に、枠要素の親要素やその親要素が移動しても、枠要素が一体となって移動しない構成も含むものであるとすると、本件各発明は、当業者が、「横縦のサイズ（画素数）が大きい画像を…ビューアに表示できるようにした画像表示方法を提供」（本件明細書等の段落【０００６】） するという本件各発明の課題を解決できると認識できる範囲のものではないということになる。 したがって、仮に、構成要件１Ｃ－１の「枠要素の移 表示方法を提供」（本件明細書等の段落【０００６】） するという本件各発明の課題を解決できると認識できる範囲のものではないということになる。 したがって、仮に、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に、枠要素の親要素（の親要素）の移動すべき位置を演算する構成までも含まれるとすると、本件各発明は、サポート要 件及び補正要件に違反する。 従前と同一の「分割画像」の「枠要素」への再度の当てはめ（構成要件１Ｃ－２）に関するサポート要件違反原告らの主張によれば、本件明細書等には、長い距離のスクロール操作による画像の移動において、元々のセルによってカバーされる領域内にとどま っているセルには、従前と同一の分割画像を再度当てはめる構成のみが開示されているということになる。 しかしながら、本件各発明は、「枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめ」る（構成要件１Ｃ－２）と特定されているものの、従前と同一の「分 割画像」を「枠要素」に再度当てはめることについては特定されていない。 したがって、従前と同一の「分割画像」を「枠要素」に再度当てはめることを特定しない本件各発明の構成が、本件明細書等に記載されているとはいえないし、このような構成によって本件各発明の課題を解決できると当業者は認識できないから、本件各発明は、サポート要件に違反する。 （原告らの主張） 以下のとおり、本件各発明には、被告の主張するサポート要件、実施可能要件違反及び補正要件の各違反はない。 「枠要素」（構成要件１Ｂ等）に関するサポート要件違反及び実施可能要件違反について構成要件１Ｂ等の「 、被告の主張するサポート要件、実施可能要件違反及び補正要件の各違反はない。 「枠要素」（構成要件１Ｂ等）に関するサポート要件違反及び実施可能要件違反について構成要件１Ｂ等の「枠要素」を実現するためのＨＴＭＬの記述（プログラ ム）それ自体は当業者が適宜採用すれば足り、本件各発明の「枠要素」の構成について、サポート要件違反及び実施可能要件違反の問題が生じる余地はない。 「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）に関するサポート要件違反及び補正要件違反について 本件明細書等には、ブロックの移動量を計算してブロックの原点の移動すべき座標を求めるためのJavaScript の関数を示す【図１３】において、各セル（「枠要素」）ではなく、その親要素であるブロック（複数の「枠要素」により構成）の位置の値を書き換えることにより、「分割画像」の移動を行う構成が具体的に開示されている。 したがって、本件各発明の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」との構成について、サポート要件違反及び補正要件違反はない。 従前と同一の「分割画像」の「枠要素」への再度の当てはめ（構成要件１Ｃ－２）に関するサポート要件違反について 本件各発明は、プラグインソフトウェアを用いることなく、大きい画像の 全てをダウンロードしなくても、スクロール操作により所望とする位置の画像をＷｅｂブラウザの表示領域に表示することを解決課題とした発明であるところ、長い距離のスクロール操作がなされた場合に追加されるセル以外のセルについて、分割画像の再度の当てはめが行われるか否かは、上記課題の解決とは無関係である。 解決課題とした発明であるところ、長い距離のスクロール操作がなされた場合に追加されるセル以外のセルについて、分割画像の再度の当てはめが行われるか否かは、上記課題の解決とは無関係である。 したがって、本件明細書等の実施例にあるセルの記載をもって、本件各発明にサポート要件違反があるとはいえない。 争点３（本件特許権の間接侵害の成否）について（原告らの主張） 特許法１０１条４号の「その方法の使用にのみ用いる物」の意義 特許発明に係る方法の使用に用いる物に、当該特許発明を実施しない使用方法自体が存在する場合であっても、当該特許発明を実施しない機能のみを使用し続けながら、当該特許発明を実施する機能は全く使用しないという使用形態が、その物の経済的、商業的又は実用的な使用形態として認められない限り、その物を製造、販売等することによって侵害行為が誘発される蓋然 性が極めて高いことに変わりはないというべきであるから、当該物は、特許法１０１条４号の「その方法の使用にのみ用いる物」に該当するというべきである。 被告地図プログラムの配信の間接侵害該当性被告地図表示方法は、本件各発明の技術的範囲に属するところ、被告地図 プログラムは、ドラッグ操作によりスクロール可能な地図データを提供することにより、専用のソフトウェアを別途用いることなく、横縦のサイズの大きい画像をダウンロードして、少ない待ち時間でビューアに表示することを可能にする（本件明細書等の段落【０００４】ないし【０００６】）ものであり、地図のスクロールなしの使用形態を想定していないから、特許法１０ １条４号の「その方法の使用にのみ用いる物」に該当する。 したがって、被告による被告地図プログラムの配信につき ロールなしの使用形態を想定していないから、特許法１０ １条４号の「その方法の使用にのみ用いる物」に該当する。 したがって、被告による被告地図プログラムの配信につき、本件特許権の間接侵害が成立する。 （被告の主張） 特許法１０１条４号の「その方法の使用にのみ用いる物」の意義特許発明に係る方法の使用に用いる物について非侵害用途に使用すること が、経済的、商業的、実用的な用途としてあり得ないとまでいえない限り、当該物は特許法１０１条４号の「その方法の使用にのみ用いる物」に該当しない。 被告地図プログラムの配信の間接侵害該当性スクロールのドラッグ操作等をすることなく店舗付近や現在地付近の地図 を表示させるなど、被告地図プログラムの非侵害用途の使用が、経済的、商業的、実用的な用途としてあり得ないとはいえないから、被告地図プログラムは、特許法１０１条４号の「その方法の使用にのみ用いる物」に該当しない。 また、被告地図プログラムには、道沿い検索や距離計測等のスクロールの ドラッグ操作等が全く想定されない使用形態や、キーワード検索（乙６の６ないし８、乙１８）や宅配便の追跡（乙６の５、乙１９ないし２１）等の地図とは無関係の独立した使用形態など、本件各発明を実施する機能は全く使用しないという使用形態が、経済的、商業的又は実用的な使用形態として認められるから、仮に、同号の「その方法の使用にのみ用いる物」の意義につ いて原告らの主張する見解に立ったとしても、被告地図プログラムは、同号の「その方法の使用にのみ用いる物」に該当しない。 したがって、被告による被告地図プログラムの配信につき、本件特許権の間接侵害は成立しない。 争点４（損害額）について （原告らの 同号の「その方法の使用にのみ用いる物」に該当しない。 したがって、被告による被告地図プログラムの配信につき、本件特許権の間接侵害は成立しない。 争点４（損害額）について （原告らの主張） 原告サピエンスは、本件特許権の設定登録日である平成１９年１２月２８日から平成２７年２月８日までの間、原告プラグインフリーは、本件特許権の取得日である同月９日から現在までの間、被告による本件特許権の侵害により、以下の損害を被った。 ア実施料相当額の損害（特許法１０２条３項） 本件各発明の実施料相当額の損害は、以下の方法で算定される額のうち高額のものとするのが相当である。 算定法１被告は、被告地図プログラムの配信により、被告管理のウェブページで地図と共に表示される広告からの広告料や、「Yahoo! JavaScript マ ップＡＰＩ」の利用料などを受け取ったことにより、平成１９年１２月２８日から平成２７年２月８日までの間に２００億円、同月９日から現在までの間に少なくとも４００億円の売上げを得たところ、本件各発明の実施に対し受けるべき料率は、売上げの１０％を下回らない。そうすると、原告らの損害額は、原告サピエンスにあっては２０億円（２００ 億円×１０％）、原告プラグインフリーにあっては４０億円（４００億円×１０％）である。 算定法２被告地図プログラムの配信回数は、平成１９年１２月２８日から平成２７年２月８日までの間に少なくとも２０億回、同月９日から現在まで の間に少なくとも４０億回に及ぶところ、本件各発明の実施に対し受けるべき料率は、１配信当たり１円を下回らない。そうすると、原告らの損害額は、原告サ に少なくとも２０億回、同月９日から現在まで の間に少なくとも４０億回に及ぶところ、本件各発明の実施に対し受けるべき料率は、１配信当たり１円を下回らない。そうすると、原告らの損害額は、原告サピエンスにあっては２０億円（２０億回×１円）、原告プラグインフリーにあっては４０億円（４０億回×１円）である。 イ弁護士費用相当額 原告らは、被告による本件特許権の侵害により、本訴の遂行を余儀なく され、少なくとも損害賠償請求額の１０％に相当する弁護士費用相当額の損害を被った。 そこで、原告らは、被告に対し、原告サピエンスにあっては特許法１０２条３項の損害賠償金２０億円の一部６０００万円及び弁護士費用相当額６００万円の支払を、原告プラグインフリーにあっては同項の損害賠償金４０億 円の一部１億２０００万円及び弁護士費用相当額１２００万円の支払を求めるものである。 （被告の主張）争う。 第４ 当裁判所の判断 １ 本件各発明の内容 本件明細書等には、次のとおりの記載があることが認められる（甲２）。 ア発明の属する技術分野「この発明は、ビューアの表示領域よりも大きい画像をサーバからダウンロードしてビューアに表示する方法に関する。」（段落【０００１】） イ従来の技術「インターネット技術の発展により、世界中からあらゆる情報をブラウザで閲覧することができるようになった。画像情報も同様にブラウザで閲覧できる。これは、Ｗｅｂサーバ上に、ＪＰＥＧファイル等の画像ファイルを表示することを記述したＨＴＭＬファイルを保存しておくことによ り実現される。インターネット技術を利用した新聞紙面画像の配信および閲覧も実用化されている。…」（段落 ファイル等の画像ファイルを表示することを記述したＨＴＭＬファイルを保存しておくことによ り実現される。インターネット技術を利用した新聞紙面画像の配信および閲覧も実用化されている。…」（段落【０００２】）ウ発明が解決しようとする課題「インターネット技術を利用して新聞紙面等の横縦のサイズ（画素数）の大きい画像をダウンロードしてブラウザに表示するのに、従来は長い待 ち時間を要していた。」（段落【０００４】） 「また、インターネット技術を利用した新聞紙面画像の配信・閲覧は、従来は、ブラウザから起動される専用のソフトウェア（プラグインソフトウェア、専用ビューア）を別途入手して実現していた。よく知られているＶｅｒｉＳｉｇｎ（登録商標）などの認証機関によって確認されるソフトウェアさえも、製作した会社を証明するものであって、ソフトウェア自体 を保証するものではないことからソフトウェアの使用はユーザの責任になる。実際、ブラウザには新しい技術が続々と追加されるので、一般ユーザがブラウザの動きを理解し、自己責任でソフトウェアを選別して使用することは非常に難しい。このことから、一般ユーザはプラグインソフトウェアの使用に不安を感じることが多く、セキュリティやウィルス、ハードデ ィスクの破損などの問題からプラグインソフトウェアの使用を拒否するユーザも少なくない。」（段落【０００５】）「この発明は、上述の点に鑑みてなされたもので、横縦のサイズ（画素数）が大きい画像をダウンロードして、少ない待ち時間でビューアに表示できるようにした画像表示方法を提供しようとするものである。また、こ の発明は、併せて、プラグインソフトウェアなしで、該画像表示方法を実現する方法を提供しようとするものである でビューアに表示できるようにした画像表示方法を提供しようとするものである。また、こ の発明は、併せて、プラグインソフトウェアなしで、該画像表示方法を実現する方法を提供しようとするものである。」（段落【０００６】）エ課題を解決するための手段「この発明の画像表示方法は、Ｗｅｂブラウザの画像を表示する表示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも 一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像表示方法において、Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当す る複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当す る位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅ ｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にするものである。」（段落【０００７】）「この発明の画像表示方法によれば、Ｗｅｂブラウザの画像を表示する 表示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割 る。」（段落【０００７】）「この発明の画像表示方法によれば、Ｗｅｂブラウザの画像を表示する 表示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示するようにしたので、少ない待ち時間でビューアに表示することができる。また、この発明によればＷｅｂブラウザの表示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表 示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示 された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、 該当する位置の分割画像を当てはめて表示しまたは表示できる状態にし たので、画像の移動が指示されたときに、全分割画像数に比べて限られた数の枠要素を移動するように演算をすればよいので、画像全体（つまり全分割画像）を移動する場合に比べて演算量を減らすことができ、これにより画像の移動速度を速くする（つまり追従性をよくする）ことができる。」（段落【００１２】） オ発明の実施の形態「この発明の実施の 比べて演算量を減らすことができ、これにより画像の移動速度を速くする（つまり追従性をよくする）ことができる。」（段落【００１２】） オ発明の実施の形態「この発明の実施の形態を以下説明する。この実施の形態では、プラグインソフトウェアなしで、新聞紙面画像を配信・閲覧する場合について説明する。図１にシステム構成を示す。Ｗｅｂサーバ（サーバコンピュータ）１０とＷｅｂブラウザ（クライアントコンピュータ、ビューア）１２とは、 インターネット等の通信ネットワーク１４を介して接続されている。Ｗｅｂサーバ１０には、新聞紙面の画像データベースが予め格納されて用意されている。この画像データベースは、新聞１ページ全体を１つの画像とするもので、新聞を構成する各ページの画像を様々な倍率｛長さ比で例えば、２５％、３３％、５０％、６７％（以上、実際の新聞紙面の縮小画像）、 １００％（実際の新聞紙面と等倍画像）、１３３％、２００％、４００％（以上、実際の新聞紙面の拡大画像）｝で（すなわち、同一ページの画像を複数の倍率で）保存している。各分割画像のファイル形式は同一である必要はなく、例えば分割画像ごとの特徴（写真か文字か、カラーか白黒か等）に応じて圧縮率が高いファイル形式（ＪＰＥＧ形式、ＰＮＧ形式、Ｇ ＩＦ形式等）で保存する。したがって、新聞１ページの画像は、異なるファイル形式の分割画像が混在して構成される場合がある。このように、分割画像ごとに圧縮率が高いファイル形式を用いることにより送信時間を短縮できる。」（段落【００２０】） 【図１】 「１つの倍率の１ページの画像は、図２に示すように、左上位置（画像の原点位置）から横方向（Ｘ軸方向）および縦方向（Ｙ軸方向）にそれぞれ所定画素 【図１】 「１つの倍率の１ページの画像は、図２に示すように、左上位置（画像の原点位置）から横方向（Ｘ軸方向）および縦方向（Ｙ軸方向）にそれぞれ所定画素数ごとに格子状に分割されて、複数の矩形の分割画像の集合で構成されている。１つの分割画像を構成する画素数は、倍率の違いにかか わらず一定であり、例えば４８０×４８０ピクセルである（ただし、１ページ横方向全体の画素数が１つの分割画像について定められた横方向の画素数で割り切れない場合は、右端位置の分割画像の画素数は端数となる。 同様に、１ページ縦方向全体の画素数が１つの分割画像について定められた縦方向の画素数で割り切れない場合は、下端位置の分割画像の画素数は 端数となる。）。これに対し、１ページ分の紙面を構成する画素数は、倍率に応じて変化する｛倍率（＝長さ比）の二乗に比例する｝ので、１ページ分の紙面を構成する分割画像数は、倍率が低い画像ほど少なく、倍率が高い画像ほど多くなる。各分割画像には、１ページの画像における各分割画像の位置（番地）を示す座標値（分割画像座標値）として、図２に示す ように、横方向の座標をｘ、縦方向の座標をｙとし、左上角の分割画像位置を原点［０，０］とし、右に行くに従い、また下に行くに従い１ずつ増加する分割画像座標値［ｘ，ｙ］に相当するファイル名がそれぞれ付与されて保存されている。１ページの画像における右端の分割画像の横方向の座標値をｘｌ、下端の分割画像の縦方向の座標値をｙｌとすると、右下角の 最後の分割画像の座標値は［ｘｌ，ｙｌ］となる。特定の新聞の、特定のページの、特定の倍率の、特定の分割画像は、新聞名、日付、朝／夕刊別、ページ番号、倍率、分割画像座標値［ｘ，ｙ］の各情報を組み合わせた識 の分割画像の座標値は［ｘｌ，ｙｌ］となる。特定の新聞の、特定のページの、特定の倍率の、特定の分割画像は、新聞名、日付、朝／夕刊別、ページ番号、倍率、分割画像座標値［ｘ，ｙ］の各情報を組み合わせた識別情報で特定（指定）される。新聞紙面を閲覧する場合は、Ｗｅｂブラウザ１２から、閲覧者により指示される閲覧位置に応じた該識別情報が送信 され、Ｗｅｂサーバ１０は該識別情報を解析して、該当する分割画像を送信し、Ｗｅｂブラウザ１２は該分割画像を受け取って、元の画像の並びに配列して表示する。上記のような識別情報を用いれば、Ｗｅｂサーバ１０から最初にＷｅｂブラウザ１２に送信するＨＴＭＬ（後述する図３のステップＳ２）に、分割画像ごとのファイル名｛ファイル形式を指定する識別 子(.jpg、.png、.gif 等）が付加されたデータ｝を組み込んでおく必要がない（すなわち、Ｗｅｂブラウザ１２はファイル名やそのファイル形式を予め知らなくても、個々の分割画像を要求できる。）ので、該ＨＴＭＬのデータ量は少なくて済む。」（段落【００２１】）【図２】 「この実施例では、後述するように（図６）、画像上にブラウザの表示領域全体が入る大きさの『ブロック』を設定する。このブロックは、例えば６×６個の『セル』（枠要素）で構成される。１つのセルは１つの分割画像の大きさ（例えば４８０×４８０ピクセル）に相当し、該当する位置の分割画像が当てはめ（割り当て）られる。ブロックは、画像が移動（ス クロール）しても常にブラウザの表示領域全体が入るように、ブラウザの表示領域に対する画像の移動に応じて、ブラウザの表示領域に対してセル単位で移動し、これに伴い、セルに当てはめられる分割画像も順次入れ替えられる。」（段落【００２２】）「 が入るように、ブラウザの表示領域に対する画像の移動に応じて、ブラウザの表示領域に対してセル単位で移動し、これに伴い、セルに当てはめられる分割画像も順次入れ替えられる。」（段落【００２２】）「新聞紙面を閲覧する場合のＷｅｂブラウザ１２とＷｅｂサーバ１０と の間の通信のやり取りを図３に示す。閲覧者がＷｅｂブラウザ１２からＷｅｂサーバ１０に○月○日付の○○新聞の○刊（朝刊または夕刊）を閲覧する旨の指示をすると、該当する内容のＨＴＭＬを要求する指示が出される（Ｓ１）。Ｗｅｂサーバ１０はこの要求を受けて、図４に示す、分割画像データを当てはめる６×６個のセルを設定する＜ＤＩＶ＞タグ、および、 どの分割画像をどのセルに当てはめてブラウザ上のどの位置に表示するかを算出するためのJavaScript を含んだＨＴＭＬをＷｅｂブラウザに返す（Ｓ２）。なお、６×６個のセルには、図４に示すように、「canvas００００」～「canvas０５０５」の名前が付けられている。「canvas」に続く４桁の数字のうち、最初の２桁はブロック内でのセルのＸ軸方向の番地 （００～０５）を示し、それに続く残りの２桁はブロック内でのセルのＹ軸方向の番地（００～０５）を示す。」（段落【００２３】） 【図３】 【図４】 「Ｗｅｂブラウザ１２は、ＨＴＭＬを受け取ると、該ＨＴＭＬに記述されているJavaScript に基づき、各セルにどの分割画像を当てはめるかおよび各セルに当てはめられた分割画像をブラウザ１２上のどの位置に表 示するかを算出する。そして、算出された分割画像がＷｅｂブラウザ１２に既にダウンロードされてキャッシュメモリに保存されている分割画像であるかどうかを判断し、既に保存されている分割画像については、それを読み出し 出する。そして、算出された分割画像がＷｅｂブラウザ１２に既にダウンロードされてキャッシュメモリに保存されている分割画像であるかどうかを判断し、既に保存されている分割画像については、それを読み出して該当するセルに当てはめる。また、Ｗｅｂブラウザ１２に保存されていない分割画像については、Ｗｅｂサーバ１０に対し該当する分 割画像を要求する（Ｓ３）。Ｗｅｂサーバ１０は該要求に応じて、該当する分割画像データを送信する（Ｓ４）。Ｗｅｂブラウザ１２は該分割画像データを受け取り、該当するセルに当てはめる。このようにして、６×６個のセルに分割画像がそれぞれ当てはめられて（関連づけられて）、前記算出された位置にそれぞれ表示される（Ｓ５）。これにより、Ｗｅｂブラ ウザ１２の表示領域全体に、分割画像がつなぎ目なく表示されて、新聞紙面の画像が表示される。表示の一例を図５に示す（図５においてセルの境界線は仮想的に示したもので、実際の画面では表示されない。）。なお、閲覧開始当初は初期画面として、Ｗｅｂブラウザ１２から閲覧の指示をした新聞の第１ページの所定倍率（紙面の記事全体が見渡せるように比較的 低い倍率）の分割画像をＷｅｂブラウザ１２がＷｅｂサーバ１０に要求して表示するように、Ｗｅｂサーバ１０から送信するＨＴＭＬが記述されている。」（段落【００２４】）【図５】 「初期表示制御 ブロックを構成する各セルに当てはめる分割画像について説明する。ここでは、図６に示すように、ブラウザの表示領域１６よりも大きい画像１ ８（新聞紙面１ページ分の画像）を、ブラウザの表示領域１６の中心と画像１８の中心を一致させた状態に初期表示するものとする。また、ブロック２０を６×６個のセル２２で構成し、ブロック２０の左 ８（新聞紙面１ページ分の画像）を、ブラウザの表示領域１６の中心と画像１８の中心を一致させた状態に初期表示するものとする。また、ブロック２０を６×６個のセル２２で構成し、ブロック２０の左側および上側を１セルずつ空けて（つまり、ブラウザの表示領域１６の左上角が、ブロック２０の左から２番目、上から２番目のセルに位置するように）表示する ものとする。なお、以下の説明において、座標値あるいは番号（番地）はその種類に応じて次のように区別して表記する。 （ ， ）：ピクセル座標値（ピクセル単位の座標値）［ ， ］：分割画像座標値（画像全体における分割画像ごとの座標値）〔 ， 〕：セル番号（ブロックにおけるセルごとの番号値） ピクセル座標値は、ブラウザの原点（左上角）を原点（０，０）とし、Ｘ軸方向の極性は右方向を＋、左方向を－とし、Ｙ軸方向の極性は下方向を＋、上方向を－とする。」（段落【００２５】） 【図６】 「図６において、各変数は次を意味する。 Ｘｉ：画像（新聞紙面１ページ）全体の幅（ピクセル値）Ｙｉ：画像（新聞紙面１ページ）全体の高さ（ピクセル値）Ｘｂ：ブラウザの幅（ピクセル値） Ｙｂ：ブラウザの高さ（ピクセル値）Ｘ１＝Ｘｉ／２：画像幅の半値　…（式１）Ｙ１＝Ｙｉ／２：画像高さの半値　…（式２）Ｘ２＝Ｘｂ／２：ブラウザ幅の半値　…（式３）Ｙ２＝Ｙｂ／２：ブラウザ高さの半値　…（式４）」（段落【００２ ６】）「図６において、ブラウザの原点（左上角）を原点（０，０）とすると、画像の原点の座標値（Ｘ０，Ｙ０）は次式によって与えられる。 Ｘ０＝Ｘ２－Ｘ１： 段落【００２ ６】）「図６において、ブラウザの原点（左上角）を原点（０，０）とすると、画像の原点の座標値（Ｘ０，Ｙ０）は次式によって与えられる。 Ｘ０＝Ｘ２－Ｘ１：画像のＸ軸原点　…（式５）Ｙ０＝Ｙ２－Ｙ１：画像のＹ軸原点　…（式６）１つの分割画像の大きさ（＝１つのセルの大きさ）を４８０×４８０ピクセルとすると、画像全体の分割画像数は次式によって与えられる。 Ｇｘｉ＝Ｘｉ／４８０：Ｘ軸方向の全分割画像数 …（式７） Ｇｙｉ＝Ｙｉ／４８０：Ｙ軸方向の全分割画像数 …（式８）このＧｘｉ、Ｇｙｉが小数点以下の桁を有する場合は、小数点以下を切り上げた整数値が実際のＸ軸方向およびＹ軸方向の全分割画像数である。また、Ｇｘｉの小数点以下を切り捨てた値が右端の分割画像の横方向の座標値ｘｌ（図２）であり、Ｇｙｉの小数点以下を切り捨てた値が下端の分割画像の縦 方向の座標値ｙｌ（同）である。」（段落【００２８】）「一方、ブラウザの表示領域１６に必要な分割画像数は次式によって与えられる。 Ｇｘｂ＝Ｘｂ／４８０：Ｘ軸方向の表示に必要な分割画像数 …（式９）Ｇｙｂ＝Ｙｂ／４８０：Ｙ軸方向の表示に必要な分割画像数 …（式１０） ブラウザの表示領域１６に入る最初の分割画像｛ブラウザの原点（０，０）が属する（位置する）分割画像｝の座標［ｘｆ，ｙｆ］は、次式によって与えられる。 ｘｆ＝－｛（Ｘ０／４８０）の商の小数点以下を切り捨てた値｝ …（式１１） ｙｆ＝－｛（Ｙ０／４８０）の商の小数点以下を切り捨てた値｝ …（式１２）」（段落【００２９】）「ブロックの左端に配置されるセル（Ｘ軸方向のセル番号をＳｘｆとする。 以下「Ｘ軸最初セル」という ｙｆ＝－｛（Ｙ０／４８０）の商の小数点以下を切り捨てた値｝ …（式１２）」（段落【００２９】）「ブロックの左端に配置されるセル（Ｘ軸方向のセル番号をＳｘｆとする。 以下「Ｘ軸最初セル」という。）には、Ｘ軸方向の分割画像座標値がｘｆ－１の分割画像を当てはめる。同様に、ブロックの上端に配置されるセル（Ｙ 軸方向のセル番号をＳｙｆとする。以下「Ｙ軸最初セル」という。）には、 Ｙ軸方向の分割画像座標値がｙｆ－１の分割画像を当てはめる。すなわち、Ｓｘｆ＝ｘｆ－１　…（式１３）Ｓｙｆ＝ｙｆ－１　…（式１４）とする。これによれば、ブロックの最初のセル〔Ｓｘｆ，Ｓｙｆ〕（ブロックの左上角に配置されるセル。以下「最初セル」という。）には、［ｘｆ－１， ｙｆ－１］の分割画像が当てはめられる。－１を付加するのは、Ｓｘｆ＝ｘｆ、Ｓｙｆ＝ｙｆに設定すると、図７（ａ）に示すように、ブロック２０の左端部分および上端部分がブラウザの表示領域１６の左端部分および上端部分に接近して配置されることになり、画像を右下方向に移動（スクロール）させた際に、新たに左側および上側からブラウザの表示領域１６に入るべ き分割画像がＷｅｂサーバから新たに転送されて来るまでの待ち時間に、ブラウザの表示領域１６の左端部分および上端部分に空白部分（画像が表示されない部分）が生じ易くなるためである。これに対し、－１を付加すると、図７（ｂ）に示すように、ブロック２０は予めブラウザの表示領域１６に対して１セル分以上左方向および上方向にオフセットして配置さ れることになり、画像を右下方向に移動させた際に、ブラウザの表示領域１６の左端部分および上端部分に空白部分を生じにくくさせることができる。」（段落【００３０】） にオフセットして配置さ れることになり、画像を右下方向に移動させた際に、ブラウザの表示領域１６の左端部分および上端部分に空白部分を生じにくくさせることができる。」（段落【００３０】） 【図７】 「ブロックを構成するその他のセルに当てはめる分割画像の座標は、最初セル〔Ｓｘｆ，Ｓｙｆ〕に当てはめる分割画像の座標［ｘｆ－１，ｙｆ－１］に、Ｘ軸方向並びにＹ軸方向に１ずつ順次足していくことにより求められる。すなわち、最初セル〔Ｓｘｆ，Ｓｙｆ〕を０番目のセルとして、Ｘ軸方向 にｍ番目（ｍ＝０、１、…、５）、Ｙ軸方向にｎ番目（ｎ＝０、１、…、５）のセル〔Ｓｘｍ，Ｓｙｎ〕に当てはめられる分割画像座標値は、Ｓｘｍ＝Ｓｘｆ＋ｍ＝ｘｆ－１＋ｍ …（式１５）Ｓｙｎ＝Ｓｙｆ＋ｎ＝ｙｆ－１＋ｎ …（式１６）で与えられる。したがって、ブロックの最後のセル〔Ｓｘｌ，Ｓｙｌ〕（ブロ ックの右下角に配置されるセル。以下「最後セル」という。なお、ブロックの右端に配置されるセルをそれぞれ「Ｘ軸最後セル」、ブロックの下端に配置されるセルをそれぞれ「Ｙ軸最後セル」という。）に当てはめる分 割画像の座標は、Ｓｘｌ＝Ｓｘｆ＋５＝ｘｆ＋４ …（式１７）Ｓｙｌ＝Ｓｙｆ＋５＝ｙｆ＋４ …（式１８）となる。以上のようにして、ブロック２０を構成する６×６個のセル２２に当てはめるべき分割画像が求められる。」（段落【００３１】） 「次に、ブロック２０を構成する６×６個のセル２２のブラウザ上における表示位置について説明する。各セルのブラウザ上における表示位置は、該各セルの原点（左上角の位置）の座標値（ピクセル値）で特定（指定）される。各セルの原点の座標値は以下のようにして求められる。まず、最初セル〔Ｓｘｆ 説明する。各セルのブラウザ上における表示位置は、該各セルの原点（左上角の位置）の座標値（ピクセル値）で特定（指定）される。各セルの原点の座標値は以下のようにして求められる。まず、最初セル〔Ｓｘｆ，Ｓｙｆ〕の原点（Xｂ０，Ｙｂ０）は、ブロックの原点に相当し（図 ６参照）、Xｂ０＝Ｘ０＋（Ｓｘｆ×４８０） …（式１９）Ｙｂ０＝Ｙ０＋（Ｓｙｆ×４８０） …（式２０）で与えられる。ブロックを構成するその他のセルの原点は、このようにして求められた最初セル〔Ｓｘｆ，Ｓｙｆ〕の原点（Xｂ０，Ｙｂ０）にＸ軸方向並び にＹ軸方向に４８０ずつ順次足していくことにより求められる。すなわち、最初セル〔Ｓｘｆ，Ｓｙｆ〕を０番目のセルとして、Ｘ軸方向にｍ番目（ｍ＝０、１、…、５）、Ｙ軸方向にｎ番目（ｎ＝０、１、…、５）のセル〔Ｓｘｍ，Ｓｙｎ〕の原点（Xｂｍ，Ｙｂｎ）は、Xｂｍ＝Xｂ０＋（ｍ×４８０） …（式２１） Ｙｂｎ＝Ｙｂ０＋（ｎ×４８０） …（式２２）で与えられる。」（段落【００３２】）「Ｗｅｂサーバから送信されるＨＴＭＬ（図３のステップＳ２）には、以上の（式１）～（式２２）に相当する演算を実行するJavaScript が記述されており、Ｗｅｂブラウザは、該ＨＴＭＬを受け取ると、該JavaScript に基づき、ブロックを構成する６×６個のセルに当てはめる分割画像座標 値と、各セルのブラウザ上における表示位置（各セルの原点位置を表示するピクセル座標位置）を算出する。そして、Ｗｅｂブラウザは、算出された分割画像座標値を識別情報としてＷｅｂサーバに該当する分割画像を要求する（Ｗｅｂサーバから既にダウンロードされてキャッシュメモリに保存されている分割画像についてはそれを使用する。）（図３のス された分割画像座標値を識別情報としてＷｅｂサーバに該当する分割画像を要求する（Ｗｅｂサーバから既にダウンロードされてキャッシュメモリに保存されている分割画像についてはそれを使用する。）（図３のステップ Ｓ３）。Ｗｅｂサーバ１０は該要求に応じて、該当する分割画像データを送信し（同Ｓ４）、Ｗｅｂブラウザ１２は該分割画像データを受け取り、該当するセルに当てはめて、それぞれ前記求められた位置に表示する（同Ｓ５）（図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では 表示されないが、スクロール操作によりブラウザの表示領域に入ってくれば表示できる状態になっている）。」（段落【００３３】）「ここで、ブロック２０を構成する各セル２２のセル番号の付与方法について説明する。このセル番号の付与もＷｅｂサーバから送信されるＨＴＭＬに記述されているJavaScript に基づき実行される。各セルのセル番 号〔Ｓｘ，Ｓｙ〕は、該各セルに当てはめられる分割画像の座標［ｘ，ｙ］を、Ｘ軸方向についてはブロックを構成するＸ軸方向の総セル数、Ｙ軸方向についてはブロックを構成するＹ軸方向の総セル数でそれぞれ割った余りの値として付与する。これによれば、各分割画像が当てはめられるセルのセル番号（各分割画像に割り当てられるセル番号）は、分割画像ごと に一意的に定まる。この実施例では、Ｘ軸方向、Ｙ軸方向の総セル数はそれぞれ６であるから、セル番号は、Ｘ軸方向、Ｙ軸方向ともに０、１、２、…、５の繰り返しとなる。この場合、各分割画像が当てはめられるセルのセル番号を図９に示す。図９の各分割画像位置に記述されている数値のうち、上段は各分割画像２４の座標値を示し、下段は当てはめられるセルの 繰り返しとなる。この場合、各分割画像が当てはめられるセルのセル番号を図９に示す。図９の各分割画像位置に記述されている数値のうち、上段は各分割画像２４の座標値を示し、下段は当てはめられるセルの セル番号を示す。セル番号が繰り返し使われても、ブロック内のセル数は ６×６個だけであるから、ブロック内で同時に同じセル番号が重複して使用されることはない。このようにセル番号を繰り返し用いることにより、図４に示すように、ＨＴＭＬに記述する、セルを設定するための＜ＤＩＶ＞タグは６×６個だけ用意すれば足りることになる。」（段落【００３８】）【図９】 「以上のようにして、Ｗｅｂサーバから送信されるＨＴＭＬに記述されているJavaScript に基づき、ブロック２０を構成する６×６個のセル２２に当てはめる各分割画像２４の座標値と該各セル２２のセル番号およ び該各セル２２のブラウザ上における表示位置（各セルの原点位置を表示するピクセル座標位置）が求められたら、Ｗｅｂサーバに対し該当する分割画像２４の送信を要求し（図３のステップＳ３）、Ｗｅｂサーバから該要求に応じた分割画像データが送られてきたら（同Ｓ４）、該当するセル番号に当てはめてブラウザに表示する（同Ｓ５）。これにより、Ｗｅｂブ ラウザ１２の表示領域全体に、分割画像２４がつなぎ目なく表示されて、新聞紙面の画像１８が表示される。」（段落【００３９】）「図１０は、ブロック２０を構成する各セル２２に当てはめる各分割画像２４の座標値と、該各セル２２に付与するセル番号と、該各セル２２のブラウザ上における表示位置（各セルの原点位置）の関係を求め、該当す る分割画像をＷｅｂサーバに要求し、該要求に応じてＷｅｂサーバから送られてきた分割画像２４を各セル ル番号と、該各セル２２のブラウザ上における表示位置（各セルの原点位置）の関係を求め、該当す る分割画像をＷｅｂサーバに要求し、該要求に応じてＷｅｂサーバから送られてきた分割画像２４を各セル２２に当てはめるためのJavaScript の関数（抜粋）を示す。このJavaScript の関数は、画像の左上角の分割画像［０，０］を始点として、分割画像位置をＹ軸方向に走査してブロックに含まれる分割画像の有無を判断し、ブロックに含まれる分割画像があった 場合は、該分割画像が当てはめられるセルに、該分割画像のX 軸方向の座標値ｘを６で割った余りをＸ軸方向のセル番号sellX として付与し、該分割画像のＹ軸方向の座標値ｙを６で割った余りをＹ軸方向のセル番号sellY として付与する。そして、「document.all("canvas" + sellX +sellY).innerHTML = "<IMGID='image" +x +y + " 'SRC="image.cgi?a=xxx&b=xx x&c=xxx&d=xxx&e=xxx&f=xxx&g=xxx" STYLE='left:" +originX +";top:"+ originY + ";'>"; 」により、該当する分割画像をＷｅｂサーバに要求し、該要求に応じてＷｅｂサーバから送られてきた分割画像を該当するセルに当てはめる。なお、上のJavaScript の関数は、「canvassellXsellY」（sellX＝００～０５、sellY＝００～０５）のＩＤを持つＤＩＶタグ（図 ４参照）を、このセルに当てはめる分割画像の座標値「imagexy」のＩＤ を持つＩＭＧタグに変換し、該ＩＭＧタグのソースとして「image.cgi」（Ｗｅｂサーバ側の ４参照）を、このセルに当てはめる分割画像の座標値「imagexy」のＩＤ を持つＩＭＧタグに変換し、該ＩＭＧタグのソースとして「image.cgi」（Ｗｅｂサーバ側の画像データ検索および転送モジュール）からの分割画像データを埋め込むことを意味する。そのとき「a=xxx&b=xxx&c=xxx&d=xxx&e=xxx&f=xxx&g=xxx」は、Ｗｅｂサーバに保存されている画像を特定するためのパラメータ（新聞名、日付、朝／夕刊別、ページ番号、倍率等の情報） として、特定の画像ファイルを検索するための値となる。「STYLE='left:" +originX +";top:" + originY 」はこのセル（分割画像）の原点（左上の位置）を表示するブラウザの表示領域上の座標位置（ピクセル値）を示す。」（段落【００４０】） 【図１０】 「以上の処理をその列のＹ軸方向の最後の分割画像まで行ったら、その１つ右隣の列に移って同様に上端からブロックに含まれる分割画像の有無を判断し、ブロックに含まれる分割画像が当てはめられるセルに、Ｘ軸方向のセル番号sellX およびＹ軸方向のセル番号sellY を付与する。そし て、Ｘ軸方向の最後の列の最後の分割画像まで達したら、処理を終了する。」（段落【００４１】）「スクロール制御次に、以上のようにして初期表示がなされた後に、閲覧者のスクロール操 作によりブラウザの表示画面上で画像を任意の位置に移動させる（つまり、閲覧位置を移動する）方法について説明する。図１１は、スクロール操作による画像の移動動作を示す。図１１では、画像１８をＸ軸方向の右方向にＸｄ（ピクセル値）、Ｙ軸方向の下方向にＹｄ（ピクセル値）移動させた場合（移動後の画 法について説明する。図１１は、スクロール操作による画像の移動動作を示す。図１１では、画像１８をＸ軸方向の右方向にＸｄ（ピクセル値）、Ｙ軸方向の下方向にＹｄ（ピクセル値）移動させた場合（移動後の画像位置を符号１８’で示す。）を示す。ブロック２０は 画像１８と一体に移動するが、この移動によってブロック２０はブラウザの表示領域１６に対し相対移動し、何も手当をしなければ、ブロック２０はいずれブラウザの表示領域１６から外れてしまう。そこで、移動量に応じて画像１８に対するブロック２０の位置を変更し、これに伴い該ブロック２０を構成する各セル２２に対する分割画像の当てはめを更新する制 御（ブロックの再設定）を併せて行う。このブロックの再設定により、ブロック２０は常にブラウザの表示領域１６全体を含む（ブラウザの表示領域１６全体が常にブロック２０内に含まれる）ように制御される。図１１の例では、スクロール操作によりブロック２０がブラウザの表示領域１６に対し相対的に右方向に移動して、セルの境界線が１本ブラウザの原点を 越えているので、ブロックの再設定により、右端の１列のセルが削除され、その分左端に１列のセルが追加されている。それらの間の５列のセルには変更はない。」（段落【００４２】） 【図１１】 「スクロール操作時の制御フローを図１２に示す。図１２の制御は、Ｗｅｂサーバから送信されるＨＴＭＬに記述されているJavaScript によって行われる。スクロール操作時の制御は、画像を移動させる制御と、ブロックの再設定制御で構成される。はじめに、画像の移動制御について説明 する。新聞紙面の画像が表示されている画面上の任意の位置にマウスカーソル（ポインタ）を当ててマウス左ボタンを押下し（マウスダウン操作）（図１２のステ れる。はじめに、画像の移動制御について説明 する。新聞紙面の画像が表示されている画面上の任意の位置にマウスカーソル（ポインタ）を当ててマウス左ボタンを押下し（マウスダウン操作）（図１２のステップＳ１１）、押下したままマウスカーソルを移動させると（ドラッグ操作）、マウスカーソルに追従して画像が移動する（同Ｓ１２）。この場合、セル単位で移動量の演算をすると、演算処理に時間がか かり、移動動作が遅くなる。そこで、図４のＨＴＭＬのように、６×６個のセルを設定する＜ＤＩＶ＞タグ全体を、名前がcanvasBLOCK である＜ＤＩＶ＞タグで１つのブロックとして束ねて、該１つのブロックについて移動量を演算して該ブロックの移動後の原点を求め、該求められたブロックの原点の座標に基づき、該ブロックを構成する各セルの原点の座標を演 算して求める。これによれば、ブロックの原点に対する各セルの原点の相対位置は予め定まっており、簡単な演算で求めることができ、一方複雑な演算を要する移動量の演算は１つのブロックについてのみ行えばよいので、セル単位で（セルごとに）移動量の演算をする場合に比べて全体として演算量が少なくて済み、移動動作を高速化することができる。」（段落 【００４３】）【図１２】 「図１３は、ブロック（画像）の移動量（＝マウスカーソルの移動量） を計算してブロックの原点の移動すべき座標を求めるためのJavaScriptの関数を示す。この関数によりブロックの原点の移動すべき座標が求められたら、この座標がブロックの最初セル〔Ｓｘｆ，Ｓｙｆ〕の原点の座標になるので、他のセルについてもX 軸方向およびＹ軸方向にそれぞれ４８０ずつ順次足していくことによりそれぞれの原点の座標を求める。このような の座標がブロックの最初セル〔Ｓｘｆ，Ｓｙｆ〕の原点の座標になるので、他のセルについてもX 軸方向およびＹ軸方向にそれぞれ４８０ずつ順次足していくことによりそれぞれの原点の座標を求める。このような 演算をマウスカーソルが移動されている間中繰り返すことにより、マウスカーソルに追従して画像を移動させることができる。マウスカーソルを任意の位置に移動後、マウスボタンを離す（マウスアップ操作をする）と、画像はその位置で停止する。」（段落【００４４】）【図１３】 「次に、ブロックの再設定制御について説明する。ドラッグ操作を終了して、マウスアップ操作をすると、移動後の画像上でブラウザの原点（０，０）が属するセル位置（分割画像位置）が判断され、ドラッグ前の位置に対して変化しているかどうか｛つまり、ブラウザの原点（０，０）がセル の境界を超えたかどうか｝が判断される（図１２のステップＳ１３）。そして、変化している場合（セルの境界を越えた場合）は、その変化した分（セルの境界を越えた本数分）ブロック位置を画像の移動と同じ方向に移動させるとともに、該ブロックを構成する各セルに対する分割画像の当てはめを更新することによりブロックの再設定を行う（同Ｓ１４）。」（段 落【００４５】）「ブロックの再設定制御は次の演算により実現される。ドラッグ操作による画像の移動量を図１１のようにＸ軸方向の右方向にＸｄ、Ｙ軸方向の下方向にＹｄとすると｛画像の移動量Ｘｄ、Ｙｄは、ドラッグ終了位置（マウスアップ操作位置）でのマウスカーソル座標値からドラッグ開始位置（マウ スダウン操作位置）でのマウスカーソル座標値を引算することにより得られる。｝、移動後の画像の原点の座標値（Ｘｄ０，Ｙｄ０）は、次式によって与えられる。 Ｘｄ０＝Ｘｆ０ ラッグ開始位置（マウ スダウン操作位置）でのマウスカーソル座標値を引算することにより得られる。｝、移動後の画像の原点の座標値（Ｘｄ０，Ｙｄ０）は、次式によって与えられる。 Ｘｄ０＝Ｘｆ０＋Ｘｄ：移動後の画像のＸ軸原点 …（式２３）Ｙｄ０＝Ｙｆ０＋Ｙｄ：移動後の画像のＹ軸原点 …（式２４） ただし、Ｘｆ０：前回のスクロール操作による画像の最終的なＸ軸原点。初回のスクロール操作であれば、Ｘｆ０＝Ｘ０（初期表示時の画像のＸ軸原点）である。 Ｙｆ０：前回のスクロール操作による画像の最終的なＹ軸原点。初回のスクロール操作であれば、Ｙｆ０＝Ｙ０（初期表示時の画像のＹ軸原点）である。」 （段落【００４６】）「また、移動後にブラウザの表示領域に入る最初の分割画像｛ブラウザの原点（０，０）が属する分割画像｝の座標［ｘｄｆ，ｙｄｆ］は、次式によって与えられる。 ｘｄｆ＝－｛（Ｘｄ０／４８０）の商の小数点以下を切り捨てた値｝ …（式 ２５） ｙｄｆ＝－｛（Ｙｄ０／４８０）の商の小数点以下を切り捨てた値｝ …（式２６）したがって、ドラッグによってセルの境界がブラウザの原点（０，０）を越えた数Ｓｘｄ、Ｓｙｄは、次式によって与えられる。 Ｓｘｄ＝ｘｆ０－ｘｄｆ …（式２７） Ｓｙｄ＝ｙｆ０－ｙｄｆ …（式２８）ただし、ｘｆ０：前回のブロックの再設定時のブラウザの表示領域に入る最初の分割画像のX 軸座標ｙｆ０：前回のブロックの再設定時のブラウザの表示領域に入る最初の分割画像のＹ軸座標」（段落【００４７】） 「（式２７）によって求められるＳｘｄが０であれば、セルの境界はブラウザの原点（０，０）をX 軸方向に越えてないことがわかり、＋の値であれば、その本数分のセルの境 標」（段落【００４７】） 「（式２７）によって求められるＳｘｄが０であれば、セルの境界はブラウザの原点（０，０）をX 軸方向に越えてないことがわかり、＋の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を右方向に越えたことがわかり、－の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を左方向に越えたことがわかる。また、（式２８）によ って求められるＳｙｄが０であれば、セルの境界はブラウザの原点（０，０）をＹ軸方向に越えてないことがわかり、＋の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を下方向に越えたことがわかり、－の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を上方向に越えたことがわかる。」（段落【００４８】） 「（式２７）、（式２８）の演算の結果、Ｓｘｄ、Ｓｙｄがいずれも０の場合は、ブラウザの原点（０，０）が属する分割画像の位置はドラッグの前後で変化がないことになるから、ブロックの再設定は行われない。これに対し、（式２７）、（式２８）の演算の結果、Ｓｘｄ、Ｓｙｄのうち少なくとも一方が０以外の場合は、ブラウザの原点（０，０）が属する分割画像の位 置がドラッグの前後で変化したことになるから、ブロックの再設定が行わ れる。」（段落【００４９】）「ブロックの再設定は、Ｓｘｄ、Ｓｙｄに相当するセル数分、ブロック全体を、画像に対し、画像の移動方向と逆方向に相対的に移動させることで実現される。このブロックの再設定によって、該ブロックを構成する各セルには次のように分割画像が当てはめられる。ブロックの左端に配置される セル（Ｘ軸最初セル）Ｓｘｄｆには、Ｘ軸方向の分割画像座標値がｘｄｆ－１の分割画像が当てはめられる。同様に、ブロックの 各セルには次のように分割画像が当てはめられる。ブロックの左端に配置される セル（Ｘ軸最初セル）Ｓｘｄｆには、Ｘ軸方向の分割画像座標値がｘｄｆ－１の分割画像が当てはめられる。同様に、ブロックの上端に配置されるセル（Ｙ軸最初セル）には、Ｙ軸方向の分割画像座標値がｙｄｆ－１の分割画像が当てはめられる。すなわち、Ｓｘｄｆ＝ｘｄｆ－１　…（式２９） Ｓｙｄｆ＝ｙｄｆ－１　…（式３０）とする。これによれば、再設定後のブロックの左上角に配置されるセル（最初セル）〔Ｓｘｄｆ，Ｓｙｄｆ〕には、［ｘｄｆ－１，ｙｄｆ－１］の分割画像が当てはめられる。－１を付加するのは、（式１３）、（式１４）で－１を付加したのと同じ目的である。すなわち、ブロックをブラウザの表示領域に対 して１セル分以上左方向および上方向にオフセットして配置することにより、画像を右下方向に移動させた際に、ブラウザの表示領域の左端部分および上端部分に空白部分を生じにくくする。」（段落【００５０】）「ブロックを構成するその他のセルに当てはめる分割画像の座標は、最初セル〔Ｓｘｄｆ，Ｓｙｄｆ〕に当てはめる分割画像の座標［ｘｄｆ－１，ｙｄｆ－１］ に、Ｘ軸方向並びにＹ軸方向に１ずつ順次足していくことにより求められる。すなわち、最初セル〔Ｓｘｄｆ，Ｓｙｄｆ〕を０番目のセルとして、Ｘ軸方向にｍ番目（ｍ＝０、１、…、５）、Ｙ軸方向にｎ番目（ｎ＝０、１、…、５）のセル〔Ｓｘｄｍ，Ｓｙｄｎ〕に当てはめられる分割画像座標値は、Ｓｘｄｍ＝Ｓｘｄｆ＋ｍ＝ｘｄｆ－１＋ｍ …（式３１） Ｓｙｄｎ＝Ｓｙｄｆ＋ｎ＝ｙｄｆ－１＋ｎ …（式３２） で与えられる。したがって、ブロックの右下角に配置されるセル（最後セル）〔Ｓｘｄｌ， －１＋ｍ …（式３１） Ｓｙｄｎ＝Ｓｙｄｆ＋ｎ＝ｙｄｆ－１＋ｎ …（式３２） で与えられる。したがって、ブロックの右下角に配置されるセル（最後セル）〔Ｓｘｄｌ，Ｓｙｄｌ〕に当てはめる分割画像の座標は、Ｓｘｄｌ＝Ｓｘｄｆ＋５＝ｘｆ＋４ …（式３３）Ｓｙｄｌ＝Ｓｙｄｆ＋５＝ｙｆ＋４ …（式３４）となる。」（段落【００５１】） 「以上のようにして、再設定されたブロックを構成する６×６個のセルに当てはめるべき分割画像が求められる。６×６個のセルに当てはめるべき分割画像が求められたら、新たにブロックの領域に入ってきた分割画像について、未取得の場合はＷｅｂサーバに要求し、Ｗｅｂサーバから既にダウンロードされてキャッシュメモリに保存されている分割画像につい てはそれを読み出して、それぞれ該当するセルに当てはめて表示する（図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では表示されないが、スクロール操作によりブラウザの表示領域に入ってくれば表示できる状態になっている）。なお、図９に示したように、各分割画像が当ては められるセルのセル番号（各分割画像に割り当てられるセル番号）は、分割画像ごとに一意的に定まっている。前回のブロックの再設定からブロック内にとどまっている（スクロール操作によってもブロック内から出なかった）分割画像については、セル番号の変更はない。」（段落【００５２】）「以上のブロックの再設定制御による、ブロックを構成する各セルに対 する分割画像の当てはめの変更の一例を図１４に示す。図１４の各セル位置に記述されている数値のうち、上段は分割画像座標値を示し、下段はセル番号を示す。この例は、スクロー クを構成する各セルに対 する分割画像の当てはめの変更の一例を図１４に示す。図１４の各セル位置に記述されている数値のうち、上段は分割画像座標値を示し、下段はセル番号を示す。この例は、スクロール操作による画像の移動によって、セルの境界がブラウザの原点（０，０）をX 軸方向の右方向に１本だけ越えて、Ｙ軸方向には１本も越えていない場合（図１１に示すように画像が移 動した場合）を示す。」（段落【００５３】） 【図１４】 「なお、以上説明した実施の形態では、画像を縦横両方向に分割したが、縦横一方向にのみ分割することもできる。また、セル（枠要素）を縦横両方向に配列したが、縦横一方向のみに配列することもできる。また、分割画像およびセルを正方形としたが、長方形とすることもできる。分割画像 およびセルを矩形以外の形状に分割することもできる。また、ブロックを構成するセル数を縦横同一としたが、縦横非同一とすることもできる。また、ブロックをブラウザの表示領域に対して予め１セル分左方向および上方向にオフセットさせが、オフセット量は２セル以上にすることもできる。 また、分割画像をサーバに予め用意してビューアからの要求を待って送信 するようにしたが、ビューアからの要求を待って分割画像を生成して送信することもできる。また、初期表示した後、スクロール操作を待ってその周囲の分割画像をダウンロードするようにしたが、初期表示した後、スクロール操作を待たずにその周囲の分割画像を順次ダウンロードすることもできる。また、新聞を閲覧する場合について説明したが、その他の画像 （例えば漫画）を閲覧する場合にもこの発明を適用できる。また、Ｗｅｂブラウザを使用して閲覧する場合について説明したが、プラグインソフトウェ 、新聞を閲覧する場合について説明したが、その他の画像 （例えば漫画）を閲覧する場合にもこの発明を適用できる。また、Ｗｅｂブラウザを使用して閲覧する場合について説明したが、プラグインソフトウェアを使用して閲覧する場合にも、この発明を適用できる。」（段落【００６４】）本件特許の特許請求の範囲及び上記の記載によれば、本件各発明は、Ｗ ｅｂブラウザの表示領域よりも大きい画像をサーバからダウンロードしてビューアに表示する方法に関するものであり、従来技術では、横縦のサイズ（画素数）の大きい画像をダウンロードしてＷｅｂブラウザに表示するのに長い待ち時間を要し、また、セキュリティやウィルス、ハードディスクの破損などの問題が生じるおそれのあるプラグインソフトウェアをユーザの責任で別 途入手しなければ画像を表示できないという技術的課題があった。そのため、本件各発明は、Ｗｅｂブラウザの表示領域より大きい画像の分割画像を、サーバから優先的にダウンロードして表示する構成（構成要件１Ａ）を採用することにより、ダウンロードしてＷｅｂブラウザに表示するまでの待ち時間を少なくするとともに、画像全体に対して限定された範囲の分割画像を当て はめる複数の枠要素の配列をＷｅｂブラウザに設け、枠要素を移動、削除及び追加することにより画像を相対移動させる構成（構成要件１Ｂ及び１Ｃ）を採用し、画像を移動させるための演算を限られた枠要素に限定し、画像全体を移動させる場合よりも演算量を減らすことにより、画像の移動速度を速くすることを可能にするものであり、併せてプラグインソフトウェアなしで このような画像表示方法を実現するものであることが認められる。 ２ 被告地図表示方法の構成要件充足性（争点１）について争点１－１（構成要 ラグインソフトウェアなしで このような画像表示方法を実現するものであることが認められる。 ２ 被告地図表示方法の構成要件充足性（争点１）について争点１－１（構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」の充足性）についてア 「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）の意義 本件特許の特許請求の範囲には、「Ｗｅｂブラウザの画像を表示する表示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像表示方法において、」（構成要件１Ａ）という記載がある。また、本件明細書等には、実施例として、「図６ に示すように、ブラウザの表示領域１６よりも大きい画像１８（新聞紙面１ページ分の画像）」（段落【００２５】）、「新聞１ページの画像は、異なるファイル形式の分割画像が混在して構成される場合がある。」（段落【００２０】）、「１ページの画像は、図２に示すように、左上位置（画像の原点位置）から横方向（Ｘ軸方向）および縦方向（Ｙ軸方向）にそれ ぞれ所定画素数ごとに格子状に分割されて、複数の矩形の分割画像の集合で構成されている。…各分割画像には、１ページの画像における各分割画像の位置（番地）を示す座標値（分割画像座標値）として、図２に示すように、横方向の座標をｘ、縦方向の座標をｙとし、左上角の分割画像位置を原点［０，０］とし、右に行くに従い、また下に行くに従い１ずつ増加 する分割画像座標値［ｘ，ｙ］に相当するファイル名がそれぞれ付与されて保存されている。」（段落【００２１】）という記載がある。 そうすると、構成要件１Ａ及び本件明細書等の各記載内容によれば、 する分割画像座標値［ｘ，ｙ］に相当するファイル名がそれぞれ付与されて保存されている。」（段落【００２１】）という記載がある。 そうすると、構成要件１Ａ及び本件明細書等の各記載内容によれば、構成要件１Ａの構成は、ダウンロードの対象となる分割画像●（省略）●であるとまで限定して解することはできない。 のみならず、前記１で認定したとおり、本件各発明は、大きい画像をダ ウンロードしてブラウザに表示するのに長い待ち時間を要するという技術的課題を解決するため、Ｗｅｂブラウザの表示領域に一部が入る分割画像を優先的にダウンロードしてＷｅｂブラウザの表示領域に表示するという構成を採用して待ち時間の短縮を可能にする発明である。そうすると、当該技術思想に鑑みても、本件各発明の効果を奏するためには、大きい画 像を構成する分割画像●（省略）●までを必要とするものとはいえない。 したがって、構成要件１Ａ及び本件明細書等の各記載内容を踏まえると、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」とは、表示領域よりも大きい画像の一部を構成し、●（省略）●であれば足り、●（省略）●には限定されないと解するのが相当である。 これに対し、被告は、これと異なる見解に立って、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」とは、●（省略）●を意味するものと解すべきであると主張するが、上記の説示に照らし、採用することができない。 イ被告地図表示方法の構成要件充足性について 前提事実及び証拠（甲４、１０、乙１、１６、３３）によれば、被告地図表示方法でサーバからＷｅｂブラウザにダウンロードされる地図画像は、●（省略）●であり、Ｗｅｂブラウザから閲覧できる領域にとどまらず、Ｗｅｂブ 証拠（甲４、１０、乙１、１６、３３）によれば、被告地図表示方法でサーバからＷｅｂブラウザにダウンロードされる地図画像は、●（省略）●であり、Ｗｅｂブラウザから閲覧できる領域にとどまらず、Ｗｅｂブラウザから閲覧できない領域にも配置されることにより、Ｗｅｂブラウザの表示領域よりも大きい画像の一部を構成しているものと 認められるから、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」に該当する。 これに対し、被告は、●（省略）●を理由に「表示領域よりも大きい画像を分割し…分割画像」の該当性を争うものの、構成要件１Ａにも本件明細書等にも●（省略）●記載がないことに照らすと、構成要件１Ａの「表 示領域よりも大きい画像を分割し…分割画像」は、●（省略）●に限定さ れないものと解するのが相当である。 したがって、被告の主張は、採用することができない。 以上によれば、被告地図表示方法は、構成要件１Ａを充足するものと認められる。 争点１－２（構成要件１Ｂの「複数の枠要素の配列」の充足性）について ア 「複数の枠要素の配列」（構成要件１Ｂ）の意義について 本件特許の特許請求の範囲には、「Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する 位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、」（構成要件１Ｂ）との記載がある。この記載によれば、構成要件１Ｂの「複数の枠要素の配列」は、分割画像をＷｅｂブラウザの表示領域の所定の位置に表示させるために複数配列された要素であるものと解されるものの、上 件１Ｂ）との記載がある。この記載によれば、構成要件１Ｂの「複数の枠要素の配列」は、分割画像をＷｅｂブラウザの表示領域の所定の位置に表示させるために複数配列された要素であるものと解されるものの、上記要素の設定を開始タグと終了タグを使用するものに 限定することを示すものと解することはできない。 また、本件明細書等をみても、「複数の枠要素の配列」の実施例として、div タグにより設定され、ブラウザ上の表示位置が座標値によって特定された６×６個のセルが記載されているものの（段落【００２２】、【００２３】、【００３２】、【００４０】、【図４】、【図６】、【図 ９】等）、上記セルの設定をdiv タグのような開始タグと終了タグを使用するものに限定する趣旨の記載はない。 したがって、構成要件１Ｂ及び本件明細書等の各記載内容を踏まえると、構成要件１Ｂの「複数の枠要素の配列」とは、分割画像をＷｅｂブラウザの所定の位置に表示させるための複数の要素の配列を意味するも のであり、上記要素の設定について開始タグと終了タグを使用するもの には限定されないものと解するのが相当である。 そして、本件特許の特許請求の範囲に「各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、」（構成要件１Ｂ）という記載があるほか、本件明細書等に「画像上にブラウザの表示領域全体が入る大きさの『ブロック』を設定する。このブロッ クは、例えば６×６個の『セル』（枠要素）で構成される。」（段落【００２２】）、「図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では表示されないが、スクロール操作によりブラウザの表 （段落【００２２】）、「図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では表示されないが、スクロール操作によりブラウザの表示領域に入ってくれば表示できる状態になっている」（段落【００３３】、【０ ０５２】、【００６１】）、「ブロック２０は常にブラウザの表示領域１６全体を含む（ブラウザの表示領域１６全体が常にブロック２０内に含まれる）」（段落【００４２】）という記載があることからすれば、構成要件１Ｂの「複数の枠要素の配列」には、一部の枠要素がＷｅｂブラウザの表示領域から外れているものも含むと解するのが相当である。 これに対し、被告は、本件特許出願当時の技術常識によれば、当業者は、画像を当てはめることが可能な要素として、Ｗｅｂブラウザの種類を問わずに画像を配置でき、かつ、開始タグ及び終了タグによって画像を当てはめるための枠が観念できるＨＴＭＬ文書のコンテナ要素を指すものと理解すべきであり、また、本件明細書等にdiv タグにより設定さ れたコンテナ要素が記載されていることを根拠に、構成要件１Ｂの「複数の枠要素の配列」には、img タグのように終了タグのない非コンテナ要素（空要素）は含まれないと主張する。 しかしながら、本件特許出願当時においても、終了タグのないimg 要素によってＷｅｂブラウザに画像を表示させることができたものと認め られ（乙２）、また、本件明細書等において、div 要素の開始タグ及び終 了タグは、「セルを設定する（ための）＜ＤＩＶ＞タグ」（段落【００２３】、【００３８】、【００４３】）のように、枠要素それ自体ではなく、枠要素を設定するものとして位置付けられており、タグ自体から 了タグは、「セルを設定する（ための）＜ＤＩＶ＞タグ」（段落【００２３】、【００３８】、【００４３】）のように、枠要素それ自体ではなく、枠要素を設定するものとして位置付けられており、タグ自体から枠を観念できることが必要であることを示す記載はない。そうすると、本件特許出願当時の技術常識を踏まえても、枠要素がコンテナ要素のみ を意味するものと当業者に理解されるとはいえないから、被告の主張する上記事情は、構成要件１Ｂの「複数の枠要素の配列」をコンテナ要素に限定する理由にはならないというべきである。 また、被告は、構成要件１Ｂの「当てはめて表示する表示領域に相当する複数の枠要素の配列」の文言に照らすと、構成要件１Ｂの「複数の 枠要素の配列」は、表示領域に関連する必要があり、かつ、分割画像が当てはめられると表示領域に表示される必要があると主張するが、本件特許の特許請求の範囲や本件明細書等（段落【００３０】等参照）によれば、空白部分を生じにくくさせるために、ブロックがオフセットして配置されることなどが記載されており、枠要素がブラウザの表示領域か ら外れることが当然に想定されていることからすると、構成要件１Ｂの「複数の枠要素の配列」を被告主張のように限定して解釈する理由はない。 他方、原告らは、構成要件１Ｂの「複数の枠要素の配列」は、大きさの指定により配列されるもので、短い距離のスクロール操作においては 位置を連続的に変更させることにより配列を維持したまま、長い距離のスクロール操作においては位置を非連続的に変化させることにより配列を変更することによって、当該スクロール操作に応じた画像の移動を実現するものである必要があると主張する。 しかしながら、本件明細書等では、「１つのセルは１つの に変化させることにより配列を変更することによって、当該スクロール操作に応じた画像の移動を実現するものである必要があると主張する。 しかしながら、本件明細書等では、「１つのセルは１つの分割画像の 大きさ（例えば４８０×４８０ピクセル）に相当し」（段落【００２２】）、 「１つの分割画像の大きさ（＝１つのセルの大きさ）を４８０×４８０ピクセルとする」（段落【００２８】）と記載されているように、分割画像の大きさによってセルの大きさが定まる関係にあり、セルのソースプログラム（【図４】）や分割画像をセルに当てはめるためのJavaScript の関数（【図１０】）をみても、div タグによりブラウザの表示領域 上での大きさを指定する記載はない。しかも、本件明細書等では、セルの再設定の要否について、スクロール操作に係る距離の長短によってではなく、ブラウザの原点がセルの境界を越えたか否かで判断する構成が開示されていることが認められる（段落【００４２】、【００４５】）。 そうすると、スクロール操作の距離によって画像の移動を実現する趣 旨をいう原告らの主張は、そもそも、本件各発明の基本概念である「枠要素」の意義を明らかに正解しないものといえ、失当というほかない。 したがって、当事者の上記各主張は、いずれも採用することができず、その他に、当事者の提出する準備書面及び本件全証拠を改めて精査して検討しても、技術説明会における当事者双方の口頭議論の結果及び専門 委員３名の各説明内容を踏まえると、上記判断を左右するには至らない。 イ被告地図表示方法の構成要件充足性について前提事実及び証拠（甲４、１７、乙１、１６、３３）によれば、被告地図表示方法では、img タグのstyle 断を左右するには至らない。 イ被告地図表示方法の構成要件充足性について前提事実及び証拠（甲４、１７、乙１、１６、３３）によれば、被告地図表示方法では、img タグのstyle 属性のleft、top の値でＷｅｂブラウザにおける表示位置を定め、img タグのsrc 属性で地図画像を特定するＵ ＲＬを指定することによって、Ｗｅｂブラウザの表示領域の所定の位置に分割画像を表示し又は表示できる状態にしていること、このようなimg タグにより設定された矩形領域が、Ｗｅｂブラウザの画像の表示領域全体が入るように複数配置されていること、以上の事実が認められる。 これらの事実によれば、被告地図表示方法におけるimg タグによって設 定された複数の矩形領域の配列は、構成要件１Ｂの「複数の枠要素の配列」 に該当する。 したがって、被告地図表示方法は、構成要件１Ｂを充足するものと認められる。 争点１－３（構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」の充足性）について ア 「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）の意義について 本件特許の特許請求の範囲には、「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」との記載（構成要件１Ｃ－１）がある。この記載によれば、上記の構成が、枠要素の移動すべき位置を演算する構 成をいうものと解されるものの、枠要素を移動させるための演算の対象を枠要素に限定することを示すものとまで解することはできない。 そして、本件明細書等をみても、「枠要素の移動すべき位置を演算」の実施例として、ブロックの移動量を演算して移動後の原点を求め、こ 素に限定することを示すものとまで解することはできない。 そして、本件明細書等をみても、「枠要素の移動すべき位置を演算」の実施例として、ブロックの移動量を演算して移動後の原点を求め、この原点座標に基づき、各セルの原点の座標を演算して求める構成が記載 されているものの（段落【００４３】、【００４４】）、枠要素の移動させるための演算の対象を枠要素に限定する趣旨の記載はない。 したがって、構成要件１Ｃ－１及び本件明細書等の各記載内容を踏まえると、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算」は、枠要素自体を演算の対象とするものに限定されず、枠要素以外の要素を演 算の対象として枠要素を移動させる構成も含まれるものと解するのが相当である。 これに対し、被告は、本件発明１の従属項の請求項１５ではブロックの原点の移動すべき座標の演算と各枠要素の原点の移動すべき座標の演算が峻別されていることや、本件明細書等にブロックの移動すべき位置 を演算し、ブロックと枠要素を一体的に移動させる構成は開示されてい ないこと、上記構成により演算量を一定にするという技術思想は本件各発明の技術的意義や作用効果と矛盾するということを理由として、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」には、枠要素の親要素等の移動すべき位置を演算し、枠要素とその親要素等を一体的に移動させる構成は含まれないと主張する。 しかしながら、請求項１５は、画像の相対移動の演算方法を本件発明１よりも限定するものであるから、請求項１５の記載を理由として、本件各発明において、枠要素以外の要素を演算の対象として枠要素を移動させる構成が含まれないということはできない。 のみならず、本件明細 １よりも限定するものであるから、請求項１５の記載を理由として、本件各発明において、枠要素以外の要素を演算の対象として枠要素を移動させる構成が含まれないということはできない。 のみならず、本件明細書等に枠要素を移動させるための演算の対象を 枠要素に限定する趣旨の記載がないのは、上記で説示したとおりである上、そもそも本件各発明は、画像を移動させるための演算を限られた枠要素に限定して画像全体を移動させる場合よりも演算量を減らすことにより、画像の移動速度を速くすることを可能にするものであるところ、ブロックのみを演算の対象として枠要素を移動させる構成であっても、 画像全体を移動させる場合よりも演算量が減るのであるから、本件各発明の技術的思想と相容れないことにはならない。 そうすると、被告の主張する上記事情は、構成要件１Ｃの「枠要素の移動すべき位置を演算」の対象を枠要素自体に限定する理由には必ずしもならないというべきであり、上記判断を左右するものとはいえない。 その他に被告の提出する準備書面及び本件全証拠を改めて精査して検討しても、上記判断を左右する事情は見当たらない。 したがって、被告の主張は、採用することができない。 イ被告地図表示方法の構成要件充足性について前提事実及び証拠（甲４、乙１、１６、３３）によれば、被告地図表示 方法では、矩形領域を設定するimg タグの２つ上の階層にあるdiv 要素（p osition）の開始タグのleft、top の値を演算して変更し、複数の矩形領域を一体的に移動させているから、被告地図表示方法での矩形領域の移動は、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に該当する。 したがって、被告地図表示方法は、構成 を一体的に移動させているから、被告地図表示方法での矩形領域の移動は、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に該当する。 したがって、被告地図表示方法は、構成要件１Ｃ－１を充足するものと 認められる。 争点１－４（構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」の充足性）について ア前提事実によれば、被告地図表示方法では、ドラッグ操作を継続し、Ｗｅｂブラウザに地図が表示される領域の中心位置が矩形領域の境界を通過すると、地図が表示されなくなる位置（ドラッグ操作の方向と同方向にある位置）にある矩形領域のimg タグのstyle 属性のleft、top の値及びsrc 属性のＵＲＬを書き換え、新たに地図が表示されることになる必要と なる位置（ドラッグ操作の方向と逆方向にある位置）に矩形領域を設定し直し、矩形領域の配列を変更するものである。そうすると、このような被告地図表示方法の矩形領域の再設定は、構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する 位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」に該当するものと認められる。 したがって、被告地図表示方法は、構成要件１Ｃ－２を充足するものといえる。 イこれに対し、被告は、被告地図表示方法では、img タグのstyle 属性 の値を変更して矩形領域の位置を変更しているにすぎず、画像がＷｅｂ を充足するものといえる。 イこれに対し、被告は、被告地図表示方法では、img タグのstyle 属性 の値を変更して矩形領域の位置を変更しているにすぎず、画像がＷｅｂ ブラウザの表示領域から離れるか近づくかを判別する処理も行われていないと主張する。 しかしながら、本件特許の特許請求の範囲や本件明細書等において、削除する枠要素を新たに追加する枠要素として使用し枠要素の再設定を行う構成が開示されていることからすれば（【請求項１１】、段落【０ ０４２】）、構成要件１Ｃ－２には、被告地図表示方法のような枠要素の位置を変更する構成も含まれるものと解され、また、構成要件１Ｃ－２は、画像とＷｅｂブラウザの距離を判別する処理についてまで規定するものではないから、被告地図表示方法において画像がＷｅｂブラウザの表示領域から離れるか近づくかを判別する処理は行われていないこと は、構成要件１Ｃ－２の充足性を左右するものとはいえない。 被告は、被告地図表示方法では、●（省略）●と主張する。 しかしながら、本件特許の特許請求の範囲や本件明細書等において削除する枠要素を新たに追加する枠要素として使用する構成が開示されているのは、上記のとおりである。また、構成要件１Ｃ－２は「Ｗｅｂブ ラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加し」と規定し、「分割画像に該当する位置」という文言を採用していることからすると、●（省略）●するものと解するのが相当である。そうすると、●（省略）●は、構成要件１Ｃ－２の充足性を否定する理由にはならないというべきである。 被告は、被告地図表示方法では、急なドラッグ操作がされた場合は、表示領域が地図画像から外れた後のタイミングでimg タグの位置の書換 否定する理由にはならないというべきである。 被告は、被告地図表示方法では、急なドラッグ操作がされた場合は、表示領域が地図画像から外れた後のタイミングでimg タグの位置の書換えが行われると主張する。 しかしながら、本件明細書等の「ブロックを構成するセル数をより多くすれば、画像の移動動作時に空白部分をより生じにくくさせることが できるが、その反面、該画像の移動動作時に各セルの座標計算に時間を 要し、移動速度が遅くなる可能性がある（ただし、ＣＰＵの能力による）ので、移動動作時に空白部分が発生するのを防止することと画像の移動速度との兼ね合いで、ブロックを構成するセル数を設定する。」という記載（段落【００３５】）によれば、本件各発明の構成を採用したとしても、ドラッグ操作の速度次第では、画像の移動動作時に空白部分は生 じ得るものと解されるから、被告地図表示方法における急なドラッグ操作がされた場合のimg タグの書換えのタイミングが被告主張のとおりであったとしても、被告地図表示方法の構成は構成要件１Ｃ－２を充足するものというべきである。 したがって、被告の上記各主張は採用することができない。そして、 被告の提出する準備書面及び本件全証拠を改めて精査して検討しても、上記判断を左右するには至らない。 小括以上によれば、被告地図表示方法は、本件各発明の技術的範囲に属するものということができる。 ３ 本件各発明の無効理由の有無（争点２）について本件事案に鑑み、争点２－３から判断する。 争点２－３（乙２２文献を主引例とする進歩性欠如の有無）についてア乙２２文献の記載乙２２文献には、次のとおりの記載があることが認められる（乙２２）。 「【発明の属 断する。 争点２－３（乙２２文献を主引例とする進歩性欠如の有無）についてア乙２２文献の記載乙２２文献には、次のとおりの記載があることが認められる（乙２２）。 「【発明の属する技術分野】本発明は、通信回線を介して地図データベースを有するサーバーとクライアント端末を接続して、クライアント端末から地図データの要求を行って、サーバーが地図データの要求に基づき地図データベースから地図データを抽出して送信することにより、クライアント端末で地図データを受信し地図を表示する地図表示制御システムに 関する。」（段落【０００１】） 「【発明が解決しようとする課題】しかし、従来のインターネット上での地図表示制御システムでは、上記のようにＷｅｂサーバー側からＷｅｂクライアント側に地図を送信する場合に、Ｗｅｂサーバー側でイメージデータを生成又は選択してＷｅｂクライアント側に送信することにより、Ｗｅｂクライアント側でそのイメージデータを受信し表示しているため次 のような問題がある。例えばイメージデータはデータ量が大きいため、Ｗｅｂサーバー側でイメージデータを作成してからＷｅｂクライアント側に送信すると、Ｗｅｂサーバー側から送信するデータ量が膨大になる。また、Ｗｅｂクライアント側でイメージデータを受信して表示すると、イメージデータ自身のサイズが大きいため、Ｗｅｂクライアント側で表示する までに時間がかかる。しかも、表示する地図について、その位置を変更したり、拡大／縮小したりする場合に、再度、Ｗｅｂサーバー側に地図のイメージデータを要求しなければならないため、地図表示の移動・拡大・縮小を行うときにも、初期に地図を表示する場合と同様の時間がかかる。」（段落【０００４】） 「【課題を解決するた に地図のイメージデータを要求しなければならないため、地図表示の移動・拡大・縮小を行うときにも、初期に地図を表示する場合と同様の時間がかかる。」（段落【０００４】） 「【課題を解決するための手段】本発明は、上記課題を解決するものであって、サーバーにおけるデータ量を少なくし、初期の地図の表示速度および移動・拡大・縮小の操作時の地図の表示速度を高速化するものである。」（段落【０００５】）「【発明の実施の形態】以下、本発明の実施の形態を図面を参照しつつ 説明する。図１は本発明に係る地図表示制御システムの実施の形態を示す図であり、１はクライアント端末、２、５は記憶装置、３は表示装置、４はサーバー、１１は地図データ要求処理部、１２は地図データ受信処理部、１３は地図表示処理部、２１は地図要求受付処理部、２２は地図範囲確定処理部、２３は地図データ抽出処理部、２４は地図データ送信処理部を示 す。」（段落【０００８】） 【図１】 「図１において、クライアント端末１は、地図の表示要求が入力されると、通信回線、例えばインターネット回線を介してサーバー４に地図データの要求を送信し、その地図データの要求に応じてサーバー４から送信されてきた地図データを記憶装置２に格納し、表示装置３に地図を表示する ものである。これらの処理を行うものとして、クライアント端末１は、例えば地図データ要求処理部１１、地図データ受信処理部１２、地図表示処理部１３を有する。そして、地図データの要求では、地図データ要求処理 部１１により要求された地図の表示範囲、内容に基づき記憶装置２の管理テーブルを参照、設定して、データ種別のレイヤー番号、データ領域のメッシュ番号を求め、データ種別（レイヤー）とデータ領域（メッシュ 部１１により要求された地図の表示範囲、内容に基づき記憶装置２の管理テーブルを参照、設定して、データ種別のレイヤー番号、データ領域のメッシュ番号を求め、データ種別（レイヤー）とデータ領域（メッシュ）の組み合わせで、サーバー４に対して地図データの要求を行う。また、このとき、地図データの表示倍率や最小表示サイズも指定する。サーバー４か ら送信されてきた地図データは、地図データ受信処理部１２により記憶装置２に格納すると共に、管理テーブルの書き換え、更新を行って、地図表示処理部１３により表示倍率に従って所定の範囲の地図データを読み出して表示装置３に地図を表示する。」（段落【０００９】）「記憶装置２は、サーバー４に対する地図データの要求を行い、表示装 置３に地図を表示するために必要なデータ種別及びデータ領域を管理する管理テーブルとサーバー４から送信されてきた地図データを格納するものである。管理テーブルは、データ種別管理テーブルとデータ領域管理テーブルからなる。データ種別管理テーブルは、例えば道路地図であれば、道路（高速道路・国道・県道・一般道路）、鉄道、文字情報、シンボル情 報等のデータの種類を区別する情報を管理するものであり、地図の表示要求に基づき表示／非表示（表示フラグ）の設定がなされ、表示フラグの設定内容に基づき地図データの要求を行い、表示装置３への地図の表示制御を行う。また、データ領域管理テーブルは、データ領域のメッシュ番号とデータ種別のレイヤー番号により記憶装置２に格納された地図データを 管理するものであり、この管理テーブルに基づき地図データの要求を行うデータ領域、除外するデータ領域を判断し、また、データ受信時にはその地図データの容量が記憶容量を上回ると、古い地図データの破棄処理を行う。」（段落【００１０ 理テーブルに基づき地図データの要求を行うデータ領域、除外するデータ領域を判断し、また、データ受信時にはその地図データの容量が記憶容量を上回ると、古い地図データの破棄処理を行う。」（段落【００１０】）「サーバー４は、クライアント端末１からの地図データの要求に対し、 記憶装置５に格納したメッシュ・レイヤーインデックスファイルを参照し て地図データベースから地図データを抽出し、これをクライアント端末１へ送信するものである。これらの処理を行うものとして、サーバー４は、例えば地図要求受付部２１、地図範囲確定処理部２２、地図データ抽出処理部２３、地図データ送信処理部２４を有する。そして、クライアント端末１からの地図データの要求に対し、地図要求受付部２１によりその受付 処理を行い、地図範囲確定処理部２２によりデータ種別、データ領域、地図データの表示倍率、最小表示サイズからメッシュ・レイヤーインデックスファイルを参照して地図データの抽出範囲を確定することにより、地図データ抽出処理部２３により地図データベースから地図データの要求に対応した地図データの抽出を行い、地図データ送信処理部２４により抽出 した地図データをクライアント端末１に送信する。」（段落【００１１】）「記憶装置５は、データ領域のメッシュ番号とデータ種別のレイヤー番号から定まるファイル名を持つメッシュ・レイヤーインデックスファイルと、このメッシュ・レイヤーインデックスファイルで管理される地図データベースを格納するものである。地図データベースは、クライアント端末 １からの地図データの要求に対して高速にデータ抽出を実現するため、地図の範囲を複数のデータ領域（メッシュ）に分割し、かつ複数のデータ種別（レイヤー）に分割したデータ構造を持つ。すなわち 端末 １からの地図データの要求に対して高速にデータ抽出を実現するため、地図の範囲を複数のデータ領域（メッシュ）に分割し、かつ複数のデータ種別（レイヤー）に分割したデータ構造を持つ。すなわち、メッシュ・レイヤーインデックスファイルには、地図を作成するとき、縦×横を指定範囲、例えば１０ｋｍ×ｌ．５Ｋｍといった範囲の領域にメッシュ分割したデー タ領域の情報と、データの種類を区別する情報で分割したデータ種別の情報を持つインデックス情報を作成し、クライアント端末１からの地図データの要求に対して、即時に送信すべき地図データを抽出できるようにしている。」（段落【００１２】）「クライアント端末に設定される管理テーブルのうち、データ領域管理 テーブルは、例えば図２に示すように地図データを表示する領域（メッシ ュ）が識別できるデータ領域のメッシュ番号、データの種類を区別するデータ種別ごとに固有のレイヤー番号、表示頻度、表示フラグ、地図データブロック位置、地図データ数の各情報を有するものである。表示頻度は、地図表示にこの領域の地図データを利用した回数を設定するものであり、この回数は、地図の表示要求により表示装置３の地図表示に利用される毎 に加算される。表示フラグは、現在の地図表示で表示対象領域の場合は「１」、表示対象外であれば「０」を設定するものである。地図データブロック位置は、この領域の地図データのメモリ上での位置、つまり記憶装置２の地図データの格納位置を設定し、地図データ数は、地図のベクターデータ数を設定するものである。」（段落【００１４】） 【図２】 「上記構成のデータ領域管理テーブルでは、記憶装置２に保持されているデータ領域、データ種別の情報を登録しているので、例えば地図の表示要求があ のである。」（段落【００１４】） 【図２】 「上記構成のデータ領域管理テーブルでは、記憶装置２に保持されているデータ領域、データ種別の情報を登録しているので、例えば地図の表示要求があると、それに基づき要求すべきデータ領域が記憶装置２に保持されているか否かを知ることができる。したがって、要求すべきデータ領域 が記憶装置２に保持されていれば、地図データブロック位置に基づきその領域の地図データを読み出して表示に利用することができ、そのときデータ領域の表示フラグを「１」にして表示頻度を１回インクリメントする。 しかし、記憶装置２に要求すべきデータ領域の地図データが保持されていなければ、新たにサーバーに地図データの要求を行わなければならない。 この場合、地図データが送信されてくると、受信した地図データに関するデータ領域管理テーブルを設定して地図データを記憶装置２に格納し、表示装置３にその地図を表示すると同時に、データ領域管理テーブルの表示 フラグを「１」にして表示頻度を１回とする。なお、先に述べたようにデータを受信したときその地図データの容量が記憶容量を上回る場合には、データ領域管理テーブルから表示フラグが「１」でなく、表示頻度の最も小さいデータから破棄処理を行う。」（段落【００１５】）「クライアント端末における地図データ要求処理の例を説明する。地図 データ要求処理では、図５に示すようにユーザから地図の表示要求があるのを待ち（ステップＳ１１）、地図の表示要求があるとまず、地図の表示要求の指示情報を入力する（ステップＳ１２）。地図の表示要求では、例えばディスプレイ上に表示すべき地図の左下の緯度、経度、表示すべき地図のデータ種別、表示倍率、最小表示サイズが入力される。表示すべき地 図の左下 する（ステップＳ１２）。地図の表示要求では、例えばディスプレイ上に表示すべき地図の左下の緯度、経度、表示すべき地図のデータ種別、表示倍率、最小表示サイズが入力される。表示すべき地 図の左下の緯度、経度、表示倍率が指示されると、ディスプレイ上の表示範囲の座標として、ディスプレイ上に表示する４角の緯度、経度の座標を求める（ステップＳ１３）。」（段落【００１９】） 【図５】 「次に、この４角の緯度・経度の座標を地図データのマクロ座標に変換し、そのマクロ座標が含まれるメッシュ番号を求め、サーバーに要求すべきメッシュ番号の範囲を求める（ステップＳ１４）。そして、データ領域管理テーブルを参照して該当するデータ領域のメッシュ番号があるか否 かを調べる（ステップＳ１５）。既に要求した地図データで記憶装置に保持されているメッシュ番号が存在する場合には、そのメッシュ番号を要求するメッシュ番号から除外し（ステップＳ１６）、残りのメッシュ番号の地図データの要求をサーバーに送信する（ステップＳ１７）。すなわち、データ領域管理テーブルに要求すべきメッシュ番号がありクラアイント 端末で地図データを保持している場合には、同一の領域（メッシュ番号） の地図データを再度サーバーに対して要求することは、データ要求が重複し処理速度の低下を招くので、このような問題を解消するため、既にデータ要求してクライアント端末で地図データを保持しているメッシュ番号の再度の要求はさせないようにしている。」（段落【００２０】）「ディスプレイ表示範囲を含むメッシュ番号に対してデータ要求を行っ た後は、地図の拡大や移動に備えてその周囲を要求すべき先読みデータ範囲としてそれらのメッシュ番号を求め（ステップＳ１８）、ステップＳ１ プレイ表示範囲を含むメッシュ番号に対してデータ要求を行っ た後は、地図の拡大や移動に備えてその周囲を要求すべき先読みデータ範囲としてそれらのメッシュ番号を求め（ステップＳ１８）、ステップＳ１５と同様にクライアント端末で保持しているメッシュ番号を調べて除外し（ステップＳ１９、Ｓ２０）、残りのメッシュ番号の地図データの要求をサーバーに送信する（ステップＳ２１）。」（段落【００２１】） 「サーバーにおける地図要求受付・送信処理の例を説明する。地図要求受付・送信処理では、図６に示すようにクライアント端末から地図データの要求があるのを待ち（ステップＳ３１）、地図データの要求があるとまず、クライアントからの地図データの要求で指定されたデータ種別、メッシュ番号、表示倍率、最小表示サイズの受付を行う（ステップＳ３２）。 そして、表示倍率に基づき領域サイズを計算し（ステップＳ３３）、指定されたメッシュ番号、レイヤー番号にしたがってメッシュ・レイヤーインデックスファイルを参照して（ステップＳ３４）、最小表示サイズ以下か否かを調べ（ステップＳ３５）、最小表示サイズより大きい地図データを地図データベースから抽出して（ステップＳ３６）、抽出した地図データ を送信する（ステップＳ３７）。この地図データの抽出、送信を最小表示サイズになるまで繰り返す。」（段落【００２２】） 【図６】 【図７】 「本発明に係る地図表示制御システムでは、インターネット上でＷｅｂクライアントからＷｅｂサーバーに地図データの要求を行って地図表示を行う場合、図７に示すようにＷｅｂクライアント側からの地図データの 要求に対し、Ｗｅｂサーバーにおいて地図要求の受け付け処理を行って要求された範囲の地図データを確定し、要求地図データの抽出 示を行う場合、図７に示すようにＷｅｂクライアント側からの地図データの 要求に対し、Ｗｅｂサーバーにおいて地図要求の受け付け処理を行って要求された範囲の地図データを確定し、要求地図データの抽出を行って地図データをＷｅｂクライアントに対して送信する。このとき、Ｗｅｂクライアントからの地図データ要求では、図８に示すようにデータ種別（レイヤー番号）と１データの表示領域（メッシュ番号）を指定する形式で、複数 回の要求を行うことによって、必要範囲の地図データをＷｅｂサーバーか ら取得する。」（段落【００２４】）【図７】 【図８】 「Ｗｅｂクライアントから領域（メッシュ）①～④のデータをレイヤー番号順にＷｅｂサーバー側にデータ要求を送ると、Ｗｅｂサーバー側では、 メッシュ・レイヤーインデックスファイルを検索し、メッシュレイヤーインデックスファイル内のデータ表示サイズとクライアント側の表示倍率とから計算されるクライアント側表示サイズを求め、最小表示サイズと比較してデータ抽出を行う。このようにＷｅｂサーバーに要求する表示倍率および最小表示サイズによって、取得するデータが最適化され、送信され るデータ量が決定される。このようにして地図データベースから読み込んだ地図データはメッシュ単位でまとめて、Ｗｅｂクライアントに送信され地図が表示される。」（段落【００２５】） 「メッシュ番号は、地図のデータの範囲を含む矩形領域を任意の矩形サイズで分割した領域に振られる番号であり、例えば北海道の地図データを作成する場合の、メッシュ番号の採番状況を示したのが図９である。１データの表示領域の指定には、メッシュ・レイヤーインデックスファイルで管理するこのメッシュ番号を指定する。このことにより、表示領 タを作成する場合の、メッシュ番号の採番状況を示したのが図９である。１データの表示領域の指定には、メッシュ・レイヤーインデックスファイルで管理するこのメッシュ番号を指定する。このことにより、表示領域を直ち に指示することが可能となる。座標単位は、任意に決定されるマクロ座標であるが、原点位置（座標０，０）の緯度・経度とメッシュの矩形サイズ（距離）は地図データ作成時に指定するため、各メッシュ原点（左下座標）の緯度・経度は計算により求められる。また、地図をディスプレイ上に表示する場合、ディスプレイ上の左下の表示すべき緯度・経度及び表示倍率 が指定されれば、ディスプレイに表示する４角の緯度・経度の座標が求められる。この４角の緯度・経度の座標を地図データのマクロ座標に変換し、そのマクロ座標が含まれるメッシュ番号を求めると、サーバーに要求すべきメッシュ番号の範囲が求められる。」（段落【００２６】）【図９】 「地図データの要求は、地図表示等の処理とは別処理で同時に非同期で実行できることから、インターネット利用時にＬＡＮなどより通信速度が遅い公衆回線等の通信網を利用している場合には、ディスプレイの表示範囲を含むデータ領域のデータをクライアント側で取得した後、さらにその データ範囲の外側のデータ範囲を先読み方式でサーバーに要求することにより、地図操作（移動・縮小・拡大等）時により一層表示のレスポンスを高めることができる。」（段落【００２８】）「いま、地図の表示要求として図１１（Ａ）に示すようにディスプレイ表示範囲が指示されているとすると、その表示範囲の座標を含む１６個の メッシュが地図データの要求範囲となる。このディスプレイ表示範囲を図１１（Ｂ）に示すように移動すると、既にデータ要求済みの部分を除き 囲が指示されているとすると、その表示範囲の座標を含む１６個の メッシュが地図データの要求範囲となる。このディスプレイ表示範囲を図１１（Ｂ）に示すように移動すると、既にデータ要求済みの部分を除き、移動方向に１０個のメッシュが新たな地図データの要求範囲となる。」（段落【００２９】）【図１１】 「しかし、図１１（Ｃ）に示すように表示範囲の座標を含む１６個のメッシュを初期に要求するデータ範囲とし、その外側の２０個のメッシュを次に要求する先読みデータ範囲として先読みしておくと、図１１（Ｄ）に示すようにディスプレイ表示範囲を移動する場合には、移動方向に４個の メッシュだけが移動時に要求すべきデータ領域となる。」（段落【００３０】）「図１１（Ｂ）と図１１（Ｄ）とを比較すると明らかなように、図１１（Ｄ）に示す先読み処理により移動時に要求すべきデータ領域の数が、図１１（Ｂ）に示す先読みなしの場合に比べて減っていることがわかる。」 （段落【００３１】）「また、Ｗｅｂクライアントでは、非同期に地図データの要求を行うため、最初に要求した地図データが取得できた段階から、地図の描画処理を行うことができる。しかも、地図データの取得を、地図の描画に必要なデータ種別の順序（たとえば、道路・鉄道・行政界等）ごとに優先順位を付 け、その優先順位ごとに地図データの要求を行うと、要求した地図データを取得できたものから地図の描画処理を行うため、画面上の地図表示領域には徐々に地図が表示されていくようになる。しかし、要求に従って順次地図データを受け取り、表示可能な地図範囲は広がって行くが、Ｗｅｂクライアント側のメモリ容量にも限界がある。そこで、現在表示対象の領域 以外で利用頻度の少ない領域のデータ順に、利用しなくなっ 地図データを受け取り、表示可能な地図範囲は広がって行くが、Ｗｅｂクライアント側のメモリ容量にも限界がある。そこで、現在表示対象の領域 以外で利用頻度の少ない領域のデータ順に、利用しなくなった地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することにより、メモリ使用の最適化を図ることができる。」（段落【００３２】）「以上の説明から明らかなように、本発明によれば、クライアント端末から、地図の表示要求に基づき地図データの要求範囲のデータ領域とデー タ種別を確定して前記データ種別とデータ領域ごとにサーバーに対して地図データの要求を行い、サーバーで地図データベースをデータ領域とデータ種別ごとにメッシュ・レイヤーインデッスク情報で管理して、地図データの要求に基づき地図データベースから地図データを抽出して前記クライアント端末に送信し地図を表示するので、サーバーにおけるデータ量 を少なくし、初期の地図の表示速度および移動・拡大・縮小の操作時の地 図の表示速度を高速化することができる。しかも、地図表示時に、地図データをデータ領域とデータ種別に基づき表示に必要な部分から順次分割して取得し、取得できたデータから表示を行うので、インターネットでの利用に十分耐え得る地図の表示制御を行うことができる。また、地図データをイメージデータではなく、数値データ（ベクターデータ）としてＷｅ ｂクライアントに送信し、送信した地図データをＷｅｂクライアント側で必要な限り保持するため、地図の初期表示速度およぴ移動・拡大・縮小の操作時の地図表示速度を飛躍的に高速化することができる。さらに、Ｗｅｂサーバー側でも地図データをイメージデータとして持たないため、データ量を最小限度に抑えることができる。」（段落【００３４ ・縮小の操作時の地図表示速度を飛躍的に高速化することができる。さらに、Ｗｅｂサーバー側でも地図データをイメージデータとして持たないため、データ量を最小限度に抑えることができる。」（段落【００３４】） イ乙２２発明の内容上記アの記載によれば、乙２２発明の内容は、以下のとおりと認めるのが相当である。 ２２ＡＷｅｂクライアントの地図を表示するディスプレイ表示範囲よりも大きい地図データを分割し該Ｗｅｂクライアントのディス プレイ範囲に少なくとも一部が入るメッシュ分割した地図データをサーバから優先的にダウンロードして該Ｗｅｂクライアントのディスプレイ表示範囲に表示する地図表示方法において、２２ＢＷｅｂクライアントのディスプレイ表示範囲に少なくとも一部が入るメッシュ分割した地図データから描画された地図を含む、 Ｗｅｂクライアントのディスプレイ表示範囲に対し所定の位置関係にある、地図全体に対して限定された範囲の地図領域に含まれるメッシュ分割した地図データから描画された地図を、個々に当てはめて表示するディスプレイ表示範囲に相当する複数の表示領域の配列をＷｅｂクライアントに設定し、該各表示領域に、該当 する位置のメッシュ分割した地図データから描画された地図をそ れぞれ当てはめて表示し又は表示できる状態にし、かつ、２２Ｃ－１ Ｗｅｂクライアントのディスプレイ表示範囲に対する地図の相対移動が指示された時に、Ｗｅｂクライアントのディスプレイ表示範囲に対する表示領域の移動すべき位置を演算して該位置に表示領域を移動し、 ２２Ｃ－２ 該地図の相対移動に伴いＷｅｂクライアントのディスプレイ表示範囲から離れるメッシュ分割した地図データから描画された地図に該当する位置から表示領域を削 て該位置に表示領域を移動し、 ２２Ｃ－２ 該地図の相対移動に伴いＷｅｂクライアントのディスプレイ表示範囲から離れるメッシュ分割した地図データから描画された地図に該当する位置から表示領域を削除し、Ｗｅｂクライアントのディスプレイ表示範囲に近づくメッシュ分割した地図データから描画された地図に該当する位置に表 示領域を追加して地図に対する表示領域の配列の位置を変更し、該追加する表示領域に、該当する位置のメッシュ分割した地図データから描画された地図を当てはめて表示しまたは表示できる状態にし２２Ｄ 前記演算はＷｅｂクライアントにより実行される地図表示方法 乙２２文献の記載及び図の内容を総合すれば、乙２２発明の「地図データ」、「ディスプレイ表示範囲」、「メッシュ分割した地図データ（から描画された地図）」、「表示領域」、「地図表示方法」は、それぞれ本件各発明の「画像」、「表示領域」、「分割画像」、「枠要素」、「画像表示方法」に相当するものと解するのが相当である。 ａ 原告らは、乙２２文献には、「枠要素」に相当する構成や画像を「当てはめ」る構成の開示がないと主張する。 そこで検討するに、乙２２文献には、①Ｗｅｂクライアントの記憶装置につき、「記憶装置２は、…表示装置３に地図を表示するために必要なデータ種別及びデータ領域を管理する管理テーブルとサーバー ４から送信されてきた地図データを格納するものである。」、「管理 テーブルは、データ種別管理テーブルとデータ領域管理テーブルからなる。…データ領域管理テーブルは、データ領域のメッシュ番号とデータ種別のレイヤー番号により記憶装置２に格納された地図データを管理するものであり」（段落【００１０】）という記載が認められ、②メッシュ番号につ ータ領域管理テーブルは、データ領域のメッシュ番号とデータ種別のレイヤー番号により記憶装置２に格納された地図データを管理するものであり」（段落【００１０】）という記載が認められ、②メッシュ番号につき、「図２に示すように地図データを表示する領 域（メッシュ）が識別できるデータ領域のメッシュ番号」（段落【００１４】）、「メッシュ番号は、地図のデータの範囲を含む矩形領域を任意の矩形サイズで分割した領域に振られる番号であり、例えば北海道の地図データを作成する場合の、メッシュ番号の採番状況を示したのが図９である。」（段落【００２６】）という記載が認められ、 ③表示領域につき、「Ｗｅｂクライアントからの地図データ要求では、図８に示すように…１データの表示領域（メッシュ番号）を指定する形式で、複数回の要求を行うことによって、必要範囲の地図データをＷｅｂサーバーから取得する。」（段落【００２４】）、「１データの表示領域の指定には、メッシュ・レイヤーインデックスファイルで 管理するこのメッシュ番号を指定する。このことにより、表示領域を直ちに指示することが可能となる。座標単位は、任意に決定されるマクロ座標であるが、原点位置（座標０，０）の緯度・経度とメッシュの矩形サイズ（距離）は地図データ作成時に指定するため、各メッシュ原点（左下座標）の緯度・経度は計算により求められる。」（段落 【００２６】）という記載が認められ、④地図の表示につき、「地図データを取得できたものから地図の描画処理を行うため、画面上の地図表示領域には徐々に地図が表示されていく」（段落【００３２】）という記載が認められる。 上記各記載に加えて、【図１】、【図２】、【図８】、【図９】、 【図１１】の記載を併せ考慮すれば、表示領域は、原点位置が計算に れていく」（段落【００３２】）という記載が認められる。 上記各記載に加えて、【図１】、【図２】、【図８】、【図９】、 【図１１】の記載を併せ考慮すれば、表示領域は、原点位置が計算に より求められるものであること、Ｗｅｂクライアントは、地図データを表示するための矩形領域を識別するメッシュ番号の指定により、必要範囲の地図データをＷｅｂサーバーから取得し、表示領域を指示すること、取得された地図データは、メッシュ番号のある管理テーブルとは別の場所で記憶され、描画処理により、地図が画面上の表示領域 に表示されること、以上の内容が乙２２文献により理解されるものと認められる。 そうすると、乙２２文献における「表示領域」は、メッシュ分割した地図データを指定してＷｅｂクライアントのディスプレイ表示の所定の位置に地図を表示させるためのものであるから、乙２２文献には、 本件各発明における画像を「当てはめ」る「枠要素」に相当する構成が開示されていると認めるのが相当である。 ｂ これに対し、原告らは、乙２２文献における「地図データ」は、数値データ（ベクターデータ）であるから、これに基づき表示を行う場合に「当てはめ」を行う「領域」をビューアに設定する必要はないと 主張する。しかしながら、上記にいう必要性の問題は、構成が開示されているかどうかという問題とは、必ずしも同一の事柄ではなく、乙２２文献における「地図データ」がベクターデータであることは、上記発明の認定を左右するものではない。 ●（省略）● のみならず、乙２２文献の「地図データ」がベクターデータであるとしても、これをいわゆるラスターデータに置き換えることは、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を踏まえ ならず、乙２２文献の「地図データ」がベクターデータであるとしても、これをいわゆるラスターデータに置き換えることは、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を踏まえると、当時の技術常識に照らし、当業者が適宜になし得る事項にすぎず実質的相違点に当たらず、又は明らかに容易に想到 することができるものといえる。そうすると、被告の主張はその趣旨 をいうものとして相当であり、原告らの主張は、結論において進歩性の判断を左右するものとはいえない。 ｃ 原告らは、乙２２文献に地図データを「枠要素」に「当てはめ」て表示する構成の開示がないことを前提に、乙２２文献には「表示できる状態」の開示はないと主張するが、乙２２文献には、画像を「当て はめ」る「枠要素」に相当する構成の開示があることは、上記において説示したとおりであり、原告らの主張は、前提を欠く。 ｄ 原告らは、乙２２文献の地図表示方法における表示領域の変更は、「枠要素」に相当する構成が移動するものではないから、乙２２文献に「移動すべき位置を演算して該位置に…移動し」の構成の開示はな いと主張する。 そこで検討するに、乙２２文献の「このディスプレイ表示範囲を図１１（Ｂ）に示すように移動すると、既にデータ要求済みの部分を除き、移動方向に１０個のメッシュが新たな地図データの要求範囲となる。」（段落【００２９】）、「図１１（Ｄ）に示すようにディスプ レイ表示範囲を移動する場合には、移動方向に４個のメッシュだけが移動時に要求すべきデータ領域となる。」（段落【００３０】）という記載及び【図１１】の記載によれば、「表示領域」は、「ディスプレイ表示範囲」の関係で、相対的に移動するものであることが理解できる。そして、乙２２文 べきデータ領域となる。」（段落【００３０】）という記載及び【図１１】の記載によれば、「表示領域」は、「ディスプレイ表示範囲」の関係で、相対的に移動するものであることが理解できる。そして、乙２２文献の「座標単位は、任意に決定されるマクロ 座標であるが、原点位置（座標０，０）の緯度・経度とメッシュの矩形サイズ（距離）は地図データ作成時に指定するため、各メッシュ原点（左下座標）の緯度・経度は計算により求められる。また、地図をディスプレイ上に表示する場合、ディスプレイ上の左下の表示すべき緯度・経度及び表示倍率が指定されれば、ディスプレイに表示する４ 角の緯度・経度の座標が求められる。」（段落【００２６】）という 記載によれば、「表示領域」の移動については、緯度、経度、マクロ座標から領域の移動すべき位置を演算しているものと理解されることからすると、乙２２文献には、「移動すべき位置を演算して該位置に…移動し」との構成の開示があるものと認められる。 ｅ 原告らは、乙２２文献は「地図データ」を「枠要素」に相当する領 域に「当てはめ」て表示する構成を開示するものではないから、その「削除」、「追加」を観念することはできないと主張する。 しかしながら、乙２２文献には、画像を「当てはめ」る「枠要素」に相当する構成が開示されていることは、上記において説示したとおりであり、原告らの上記主張は、前提を欠く。そして、乙２２文献の 段落【００３２】には、Ｗｅｂクライアントにおいて、現在表示対象の領域以外で利用頻度の少ない領域のデータ順に、利用しなくなった地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することが、段落【００２８】ないし【００３２】及び【図１１】には、地図の相対移動に伴い、新た 領域のデータ順に、利用しなくなった地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することが、段落【００２８】ないし【００３２】及び【図１１】には、地図の相対移動に伴い、新たに表示領域を設定して地図を 表示させる旨が、それぞれ記載されていることからすると、乙２２文献には、本件各発明における「枠要素」の「削除」、「追加」に相当する構成が、もとより開示されているものと認められる。 ｆ その他に原告らの準備書面における各主張を改めて検討しても、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各 説明内容を踏まえると、原告らの主張は、乙２２文献の技術的内容を正解しないものに帰し、いずれも採用することができない。 ウ対比本件各発明と乙２２発明を比較すると、本件発明１と乙２２発明には以下の相違点２２－１及び２が存在し、本件発明２１と乙２２発明には上記 の相違点に加えて相違点２２－５が存在するものの、その余は一致するも のと認められる。 （相違点２２－１）本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙２２発明の「表示範囲」は、「Ｗｅｂクライアントのディスプレイ表示範囲」とされている点 （相違点２２－２）本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙２２発明では、「表示領域の配列」を「Ｗｅｂクライアントに設定」するものとされている点（相違点２２－５） 本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙２２発明では、「演算はＷｅｂクライアントにより実行される」もの 本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信されるJavaScript（登録商標）に基づき実行される」のに対し、乙２２発明では、「演算はＷｅｂクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」、「JavaScript（登録商標）に基づき実行される」とは明示されていない点 エ相違点の容易想到性について 相違点２２－１について乙２２文献の記載によれば、乙２２発明は、Ｗｅｂクライアントの端末で、通信回線を介してＷｅｂサーバから地図データを受信し地図を表示する地図表示制御システムであると認められ、また、前提事実、証拠 （乙１１ないし１３）及び弁論の全趣旨（技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を含む。）によれば、本件特許出願日（平成１５年４月１７日）当時、ＷｅｂクライアントにＷｅｂブラウザを採用することは周知慣用技術であったと認められる。 これらの事実によれば、乙２２発明の地図表示制御システムにおいて、 ＷｅｂクライアントにＷｅｂブラウザを採用することは、当業者が適宜 採用し得る設計的事項であると認められるから、相違点２２－１に係る構成は容易に想到できたものといえる。 相違点２２－２について乙２２発明におけるＷｅｂクライアントにＷｅｂブラウザが備われば、「表示領域の配列」は、Ｗｅｂブラウザに設定されることになるから、 相違点２２－２に係る構成は容易に想到できたものといえる。 相違点２２－５について前提事実、証拠（乙５、７）及び弁論の全趣旨（技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を含む。）によれば、本件特許 相違点２２－５について前提事実、証拠（乙５、７）及び弁論の全趣旨（技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を含む。）によれば、本件特許出願日当時、Ｗｅｂブラウザでの演算をJavaScript に基づいて実行することは、周知慣用技術であったと認められる。そうすると、乙２２発明では、演算がＷｅｂクライアントにより実行されるため、ＷｅｂクライアントにＷｅｂブラウザが備われば、当然に演算はJavaScript に基づき実行されると認められるから、相違点２２－５に係る構成は容易に想到できたものといえる。 オしたがって、本件各発明は、乙２２発明による進歩性欠如の無効理由があるものと認められる。その他に、原告らの提出する準備書面及び本件全証拠を改めて精査して検討しても、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を踏まえると、原告らの主張は、乙２２発明の技術的内容及び当時の技術常識に照らし、独自の見解をいう ものであり、上記判断を左右するに至らない。 小括以上によれば、本件各発明は、特許無効審判により無効にされるべきものと認められるから、その余の争点について判断するまでもなく、原告らは、被告に対し、本件特許権の侵害による損害賠償請求権の行使をすることがで きないというべきである。 第５ 結論よって、原告らの請求は、いずれも理由がないからこれを棄却することとし、主文のとおり判決する。 東京地方裁判所民事第４０部 裁判長裁判官 中島基至 裁判官 東京地方裁判所民事第40部 裁判長裁判官 中島基至 裁判官 小田誉太郎 裁判官 齊藤敦は退官のため署名押印することができない。 裁判長裁判官 中島基至

▼ クリックして全文を表示