令和４年５月３１日判決言渡

同日原本領収令和元年（ワ）第２１９０１号
口頭弁論終結日

裁判所書記官

特許権侵害損害賠償請求事件

令和４年２月１８日
判

決

5

原

告

株 式 会 社 サ ピ エ ン ス（以下「原告サピエンス」という。）

原

10

告

プラグインフリー・パテント・ホールディング株式会社（以下「原告プラグインフリー」という。）

上記両名訴訟代理人弁護士

15

同訴訟代理人弁理士

山

本

純

木

内

加

西

阪

木

内

平
奈

子
裕

光

春

旧商号ヤフー株式会社
被告Ｚホールディングス株式会社

20

同訴訟代理人弁護士

同訴訟代理人弁理士
主

25

１

大

野

聖

二

小

林

英

了

木

村

広

行

松

野

知

紘

文

原告らの請求をいずれも棄却する。
1

２

訴訟費用は原告らの負担とする。
事

第１
１

実

及

び

理

由

請求
被告は、原告サピエンスに対し、６６００万円及びこれに対する令和元年８月２８日から支払済みまで年５分の割合による金員を支払え。

5２

被告は、原告プラグインフリーに対し、１億３２００万円及びこれに対する
令和元年８月２８日から支払済みまで年５分の割合による金員を支払え。

第２

事案の概要
本件は、発明の名称を「画像表示方法」とする発明に係る特許（特許第４０10

５９８０２号。以下「本件特許」といい、本件特許に係る特許権を「本件特許権」という。）の特許権者であった原告サピエンス及び本件特許の特許権者である原告プラグインフリーが、被告が配信するＨＴＭＬ及び JavaScript のソースプログラム及び地図画像のデータ等（以下、これらを総称して「被告地図プログラム」という。）によりＷｅｂブラウザに地図を表示させる方法（以下

15「被告地図表示方法」という。）が本件特許に係る発明の技術的範囲に属するものであり、被告による被告地図プログラムの配信は、本件特許権の間接侵害（特許法１０１条４号）に該当すると主張して、被告に対し、不法行為に基づき、原告サピエンスにあっては６６００万円（特許法１０２条３項の損害金２０億円の一部６０００万円及び弁護士費用６００万円の合計額）、原告プラグ

20

インフリーにあっては１億３２００万円（同項の損害金４０億円の一部１億２０００万円及び弁護士費用１２００万円の合計額）及びこれらに対する訴状送達の日である令和元年８月２８日から支払済みまで民法（平成２９年法律第４４号による改正前のもの）所定の年５分の割合による遅延損害金の支払を求める事案である。

25

なお、当裁判所は、本件事案に鑑み、画像表示方法に関する専門的知見を有する専門委員３名を選任の上、民訴法９２条の２に基づき、技術説明会におい2

て上記専門的知見に基づく説明を口頭でさせている。
１

前提事実（当事者間に争いがない事実並びに後掲証拠及び弁論の全趣旨により認定できる事実をいう。なお、本判決を通じ、証拠を摘示する場合には、特に記載しない限り、枝番を含むものとする。）
当事者

5

ア

原告サピエンスは、情報処理装置、電子電気機器及びそれに付随するソフトウェアの研究開発並びに製造販売等を目的とする株式会社である（弁論の全趣旨）。

イ

原告プラグインフリーは、特許権の保有、利用、使用許諾及びそれに関連する業務並びに電子通信分野における研究開発等を目的とする株式会社

10である（弁論の全趣旨）。
ウ

被告は、インターネット上の広告事業、イーコマース事業及び会員サービス事業等を目的とする株式会社である。
本件特許権

15

ア

原告サピエンスは、平成１９年１２月２８日、以下の特許権の設定の登録を受けた（以下、本件特許の願書に添付された明細書及び図面を「本件明細書等」という。甲１、２）。
発明の名称：画像表示方法
特許番号：特許第４０５９８０２号
出願日：平成１５年４月１７日（特願２００３－１１２９９８）20

イ

原告プラグインフリーは、平成２７年２月９日、本件特許権の移転の登録を受け、原告サピエンスから本件特許権を取得した（甲１）。
本件特許に係る特許請求の範囲
本件特許に係る特許請求の範囲の記載は、以下のとおりである（甲２）。

25ア請求項１（以下「本件発明１」という。）「Ｗｅｂブラウザの画像を表示する表示領域よりも大きい画像を分割し3

該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像
表示方法において、
Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して5限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示
する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の10

移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位
置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示で15きる状態にする画像表示方法。」
イ

請求項２１（以下「本件発明２１」といい、本件発明１と併せて「本件各発明」という。）「前記Ｗｅｂブラウザでの各演算がサーバから送信される JavaScript20（登録商標）に基づき実行される請求項１から２０のいずれかに記載の画像表示方法。」
本件各発明の構成要件
本件各発明を構成要件に分説すると、以下のとおりである。
ア

25

本件発明１

１Ａ

Ｗｅｂブラウザの画像を表示する表示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像を
4

サーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像表示方法において、
１Ｂ

Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像を含

む、Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に5当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂ
ブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、
１Ｃ－１

Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべ

10

き位置を演算して該位置に枠要素を移動し、
１Ｃ－２

該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素

15に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする１Ｄ
イ
20

画像表示方法。

本件発明２１
２１Ａ

前記Ｗｅｂブラウザでの各演算がサーバから送信される JavaScr
ipt（登録商標）に基づき実行される

２１Ｂ

請求項１に記載の画像表示方法。

被告地図プログラムの配信
被告は、被告管理のウェブページ（http://map.yahoo.co.jp、https://ma25p.yahoo.co.jp）及びＷｅｂＡＰＩ「Yahoo! JavaScript マップＡＰＩ」を利用したウェブページにＷｅｂブラウザを通じてアクセスしたユーザの利用端
5

末に、被告管理のサーバから、ＨＴＭＬ及び JavaScript のソースプログラム
及び地図画像のデータ等（被告地図プログラム）を配信し、地図情報（被告
管理のウェブサイトでの名称は、「Yahoo!地図」という。）を提供している（甲４、乙１、１６、３３）。
被告地図表示方法の構成

5

被告地図表示方法の構成は、以下のとおりである。
ア

地図画像のダウンロード
被告地図表示方法では、以下の５通りの方法により、被告管理のサーバ
から複数の地図画像がダウンロードされ、Ｗｅｂブラウザに地図として表10示される（甲４、１０、１８、乙１、１６、３３）。
地図（標準地図）、鉄道路線（鉄道路線図）、地形図、モノトーン、
OpenStreetMap（以下「地図画像１（標準地図等）」という。）●（省略）●
15

地下街１（以下「地図画像２（地下街１）」という。）●（省略）●
航空写真（以下「地図画像３（航空写真）」という。）

20●（省略）●
6

航空写真＋注記（以下「地図画像４（航空写真＋注記）」という。）●（省略）●
地下街２（以下「地図画像５（地下街２）」という。）

5●（省略）●イ

ＨＴＭＬソースコード
被告地図表示方法のＨＴＭＬソースコードは、以下のように、①開始タ
グを<div style=”position…>とする div 要素（以下「div 要素（positio

10n）」という。）、②その一つ下の階層にある開始タグを<div class=”yo
lp-tilelayer”…>とする div 要素（以下「div 要素（yolp-tilelayer）」という。）③さらにその一つ下の階層にある複数の img 要素などにより構成されている（甲４、乙１、１６、３３）。

7

ウ

地図の表示
被告地図表示方法では、img タグの style 属性で位置（left、top の値）
及び大きさ（２５６px×２５６px）を指定し、地図が表示される領域を少5なくともカバーするのに必要な位置に複数の矩形領域（以下の図の青色部分）を設定し、img タグの src 属性に被告管理のサーバから受信した地図
画像を特定するＵＲＬ（src=”https://map…）を指定することにより、Ｗｅｂブラウザの表示領域に地図を表示し、又は表示できる状態にする（甲8

４、１７、乙１、１６、３３）。

エ
5

地図の移動
被告地図表示方法におけるドラッグ操作による地図の移動は、以下のとおりである（甲４、２１、乙１、１６、２３）。
すなわち、被告地図表示方法では、div 要素（yolp-tilelayer）の開始
タグ及び img タグの style 属性の position の値を absolute に設定し、一つ上の階層の要素の左上の位置（div 要素（yolp-tilelayer）においては、

10

div 要素（position）、img 要素においては div 要素（yolp-tilelayer））
を基準に style 属性の left、top の値を設定し、位置関係を固定している。
9

そのため、被告地図表示方法では、Ｗｅｂブラウザの表示領域に表示される地図に対してドラッグ操作が行われた場合、JavaScript ソースプログ
ラムを実行することにより、div 要素（position）の開始タグの left、top の値を演算して変更し、div 要素（yolp-tilelayer）及び img 要素を div
5

要素（position）と一体的に移動させることにより、地図の移動（スクロール）を行っている。
そして、ドラッグ操作を継続し、Ｗｅｂブラウザに地図が表示される領域の中心位置が矩形領域の境界を通過すると、地図が表示されなくなる位
置（ドラッグ操作の方向と同方向にある位置）にある矩形領域の img タグ

10の style 属性の left、top の値並びに src 属性のＵＲＬを書き換え、新たな地図の表示に必要となる位置（ドラッグ操作の方向と逆方向にある位置）に矩形領域を設定し直し、新しい地図画像をＷｅｂブラウザの表示領域に表示し、又は表示できる状態にする。

10

先行文献
本件特許の出願日である平成１５年４月１７日より前に、以下の公報が存
在した。
5

ア

発明の名称を「高精細画像表示装置及びそのプログラム記憶媒体」とする公開特許公報（特開平１１－８８８６６号公報、平成１１年３月３０日公開。乙１０。以下「乙１０文献」という。）

イ

発明の名称を「画像情報提供システム、画像情報表示端末およびサーバ装置」とする公開特許公報（特開２０００－２９４４８号公報、平成１２
年１月２８日公開。乙１４。以下「乙１４文献」という。）

10

ウ

発明の名称を「図形データ表示方法」とする公開特許公報（特開平１－
１５９７６８号公報、平成元年６月２２日公開。乙１５。以下「乙１５文献」という。）

エ

発明の名称を「地図表示制御システム」とする公開特許公報（特開平１１－２３２４３３号公報、平成１１年８月２７日公開。乙２２。以下「乙15２２文献」という。）
オ

発明の名称を「データ管理装置及び地図データ記憶システム」とする公開特許公報（特開２００２－３２４２２８号公報、平成１４年１１月８日
11公開。乙２３。以下「乙２３文献」という。）
２

争点
被告地図表示方法の構成要件充足性（争点１）
被告は、構成要件２１Ａ及び２１Ｂの充足性を争っているものの、構成要5

件２１Ａの充足性については構成要件１Ｃ－１の非充足を、構成要件２１Ｂの充足性については構成要件１Ａないし１Ｃの非充足を、それぞれ理由とするものであるから、構成要件充足性の実質的な争点は、下記のとおりとなる。
ア

構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」の充足性（争点１－１）

10イ

構成要件１Ｂの「複数の枠要素の配列」の充足性（争点１－２）

ウ

構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」の充足性（争点１－３）

エ

構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示
領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠

15

要素の配列の位置を変更し」の充足性（争点１－４）
本件各発明の無効理由の有無（争点２）20

ア乙１０文献を主引例とする進歩性欠如の有無（争点２－１）

イ

乙１４文献を主引例とする進歩性欠如の有無（争点２－２）

ウ乙２２文献を主引例とする進歩性欠如の有無（争点２－３）エ

乙２３文献を主引例とする新規性・進歩性欠如の有無（争点２－４）

オ

明確性要件違反の有無（争点２－５）

カ

サポート要件違反、実施可能要件違反及び補正要件違反の有無（争点２－６）25

本件特許権の間接侵害の成否（争点３）
損害額（争点４）
12

第３
１

争点に関する当事者の主張
争点１－１（構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」の充足性）について（原告らの主張）

5「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）の意義
本件各発明は、大きい画像をダウンロードすることなく、少ない待ち時間
でビューアに表示できることを解決課題とした発明であるところ（本件明細書等の段落【０００４】ないし【０００６】）、この課題解決の関係において、●（省略）●に限定する理由はない。
したがって、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割

10

画像」とは、●（省略）●
被告地図表示方法の構成要件充足性
以下のとおり、被告地図表示方法でサーバからダウンロードする地図画像
１ないし５は、「表示領域よりも大きい画像を分割し…分割画像」に該当す
15るから、被告地図表示方法は、構成要件１Ａを充足する。
ア

地図画像１（標準地図等）及び地図画像２（地下街１）
地図画像１（標準地図等）及び地図画像２（地下街１）は、●（省略）●にほかならない。
したがって、地図画像１（標準地図等）及び地図画像２（地下街１）は、「表示領域よりも大きい画像を分割し…分割画像」に該当する。

20

また、仮に、被告の主張するとおり、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」が、●（省略）●に限定されるとしても、
地図画像１及び２●（省略）●から、地図画像１（標準地図等）及び地図
画像２（地下街１）は、いずれにせよ「表示領域よりも大きい画像を分割し…分割画像」に該当する。

25

イ

地図画像３（航空写真）
13

地図画像３（航空写真）は、●（省略）●としても、「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）に該当する。
ウ

地図画像４（航空写真＋注記）
地図画像４（航空写真＋注記）は、●（省略）●「表示領域よりも大きい画像を分割し…分割画像」に該当するから、地図画像４（航空写真＋注

5記）は、「表示領域よりも大きい画像を分割し…分割画像」（構成要件１
Ａ）に該当する。
エ地図画像５（地下街２）
地図画像５（地下街２）は、●（省略）●から、「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）に該当するものであり、こ10の点については、被告も争っていない。
（被告の主張）「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）の意
義
本件各発明は、●（省略）●ものである。そして、構成要件１Ａは、「表15

示領域よりも大きい画像を分割し…分割画像を…表示する画像表示方法」と定め、大きい画像を分割した画像を表示し、もって分割前の大きい画像の一部を表示することを明らかにしている。
したがって、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割
20

画像」とは、●（省略）●画像を分割して作成されたものを意味するというべきである。
被告地図表示方法の構成要件充足性
以下のとおり、被告地図表示方法でサーバからダウンロードする地図画像
１ないし４は、「表示領域よりも大きい画像を分割し…分割画像」に該当し

25

ない。
ア

地図画像１（標準地図等）及び地図画像２（地下街１）
14

地図画像１（標準地図等）及び地図画像２（地下街１）●（省略）●
したがって、地図画像１（標準地図等）及び地図画像２（地下街１）は、「表示領域よりも大きい画像を分割し…分割画像」に該当しない。
イ

地図画像３（航空写真）
地図画像３（航空写真）は、●（省略）●5

したがって、地図画像３（航空写真）は、「表示領域よりも大きい画像を分割し…分割画像」に該当しない。
ウ

地図画像４（航空写真＋注記）
地図画像４（航空写真＋注記）は、●（省略）●
したがって、地図画像４（航空写真＋注記）は、「表示領域よりも大き10い画像を分割し…分割画像」に該当しない。
２

争点１－２（構成要件１Ｂの「複数の枠要素の配列」の充足性）について（原告らの主張）「複数の枠要素の配列」（構成要件１Ｂ）の意義

15

本件各発明は、プラグインソフトウェアを用いることなく、大きい画像の全てをダウンロードしなくても、スクロール操作により所望とする位置の画像をＷｅｂブラウザに表示することを解決課題とし、それを実現した発明である（本件明細書等の段落【０００６】）。
このような解決課題を踏まえ、本件明細書等に実施例における「セル」に20相当する構成として構成要件１Ｂの「枠要素」が規定されていることに鑑みると、構成要件１Ｂの「複数の枠要素の配列」とは、Ｗｅｂブラウザの「表示領域」に表示される画像を構成する複数の「分割画像」を、それぞれ当て
はめるためにＷｅｂブラウザの「表示領域」との関係において「位置」及び「大きさ」の指定により配列される構成要素であって、短い距離のスクロー

25

ル操作においては「位置」を連続的に変更させることにより配列を維持した
まま、また、長い距離のスクロール操作においては「位置」を「非」連続的
15

に変化させることにより配列を変更することによって、当該スクロール操作に応じた画像の移動を実現する、ＨＴＭＬソースプログラムによって記述される構成要素のことを意味し、開始タグと終了タグを持つコンテナ要素には限定されないものと解すべきである。
5

また、構成要件１Ｂは、「各枠要素に、該当する位置の分割画像を…表示できる状態にし」と定め、設定される「枠要素」がＷｅｂブラウザの「表示領域」を正にカバーする位置関係にあるものに限定されないことを予定しており、本件明細書等の段落【００３３】にも、「図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外

10れている分割画像はその時点では表示されないが、スクロール操作によりブラウザの表示領域に入ってくれば表示できる状態になっている」と記載されているから、構成要件１Ｂの「複数の枠要素の配列」は、表示領域を正にカバーする位置関係にあるものに限定されないものと解すべきである。
被告地図表示方法の構成要件充足性

15

被告地図表示方法においては、img タグの style 属性部分に位置、サイズ等が書き込まれることによってＷｅｂブラウザに設定された複数の矩形領域に、img タグの src 属性のＵＲＬの書込み、書換えがされることによって地図画像が当てはめられ、閾値（ドラッグ操作中に矩形領域の配列が変更になる距離）を超えない範囲でドラッグ操作が行われた場合は、矩形領域の位置

20を連続的に変化させその配列を維持したまま、また、閾値を超えてドラッグ操作が行われた場合は、矩形領域の位置を非連続的に変化させその配列を変更することにより、ドラッグ操作に応じた画像の移動を実現しているから、
上記の複数の矩形領域は、構成要件１Ｂの「複数の枠要素の配列」に該当する。

25

したがって、被告地図表示方法は、構成要件１Ｂを充足する。
（被告の主張）16

「複数の枠要素の配列」（構成要件１Ｂ）の意義
構成要件１Ｂは、「分割画像を、個々に当てはめ…る…複数の枠要素…をＷｅｂブラウザに設定し」と定めているから、「枠要素」とは、少なくとも
Ｗｅｂブラウザに設定され、画像を当てはめることが可能な要素であること
5が理解できる。そして、本件各発明は、Ｗｅｂブラウザを用いた画像表示方法の発明であり、本件明細書等には、ＨＴＭＬや JavaScript を用いたソース
コードを示しながら実施例が記載されているところ、本件特許出願当時の技
術常識（乙２ないし５、７）からすると、当業者は、画像を当てはめることが可能な要素として、Ｗｅｂブラウザの種類を問わずに画像を配置でき、か10

つ、開始タグ及び終了タグによって画像を当てはめるための枠が観念できる
ＨＴＭＬ文書のコンテナ要素を指すものと理解するといえ、現に、本件明細書等の実施例には、「６×６個のセルを設定する〈ＤＩＶ〉タグ」（段落【００２３】）などと、div タグにより設定されるコンテナ要素により、セル（枠要素）を設定する旨が記載されている。

15

したがって、構成要件１Ｂの「複数の枠要素の配列」は、複数のコンテナ要素である必要があり、img タグのように終了タグのない非コンテナ要素（空要素）は含まれないと解すべきである。
また、構成要件１Ｂの「当てはめて表示する表示領域に相当する複数の枠要素の配列」の文言に照らすと、構成要件１Ｂの「複数の枠要素の配列」は、

20

表示領域に関連する必要があり、かつ、分割画像が当てはめられると表示領域に表示される必要があると解すべきである。
被告地図表示方法の構成要件充足性
被告地図表示方法では、img タグを用いて、src 属性により指定した画像
を、style 属性により指定した位置及びサイズに表示しているにすぎず、画25

像を当てはめる複数のコンテナ要素は存在しない。
仮に、原告らの主張するように img タグの style 属性による位置及びサイ
17ズ等の指定が「枠要素」に当たるとしても、被告地図表示方法では、Ｗｅｂ
ブラウザのデベロッパーツールで img タグにカーソルを合わせた場合に青く表示される矩形領域の配列は、表示領域の配列と全く異なり関連せず、しかも全く画像が表示されないものもある。
また、仮に、乙１０文献における「キャッシュ・メモリ」は、「画像表示5のための処理」が別途必要なものであり「ブロック」を画面上の位置に並べるものではないという原告らの主張（争点２－１（乙１０文献を主引例とす
る進歩性欠如の有無））を前提とすると、「分割画像を…当てはめて表示する」に該当するには特段の画像表示のための処理をしないものでなければい
けないことになるが、被告地図表示方法では、img タグの visibility の値を10

hidden から visible に変更する処理を経なければ、画像が表示されることもない。
したがって、被告地図表示方法には、構成要件１Ｂの「複数の枠要素の配列」は存在しないから、構成要件１Ｂを充足しない。
15３

争点１－３（構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」の充足性）について（原告らの主張）「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）の意義

20

本件明細書等の段落【００４３】には、スクロール制御を実現するための方法として、各セル（本件各発明の「枠要素」に相当）毎に移動量の演算を行う方法のみならず、複数のセルにより構成されるブロックの移動量の演算を行う方法も開示されている。
また、本件明細書等には、スクロール操作を実現するための JavaScript の25関数を示す【図１３】がある。そして、本件明細書等の段落【００４２】の「ブロック２０はブラウザの表示１６に対し相対移動」するという記載から18

すると、本件明細書等が、div タグの position の値が absolute であることを前提としていることは明らかであり、また、ＨＴＭＬソースプログラムのHEAD の部分で div タグや img タグの position の値を一括して absolute にすることは技術常識であるから、【図１３】は、各セル（「枠要素」）の親要
5素であるブロック（複数の「枠要素」により構成）の位置の値を書き換える
ことにより、「分割画像」の移動を行う構成を具体的に開示するものといえる。
したがって、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」には、枠要素の親要素やその親要素の移動すべき位10

置を演算する構成も含まれる。
被告地図表示方法の構成要件充足性
被告地図表示方法では、img 要素の２つ上の階層にある div 要素（position）の開始タグの left、top の値を変更することにより、img タグが指定する位置（矩形領域の位置）を移動させている。

15

したがって、被告地図表示方法は、枠要素の親要素の親要素の移動すべき
位置を演算して、枠要素を移動させるものであるから、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」を充足する。
（被告の主張）「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要20

件１Ｃ－１）の意義
本件特許の特許請求の範囲の記載によれば、本件発明１の従属項である請求項１５では、「ブロックの原点の移動すべき座標」の演算と「各枠要素の原点の移動すべき座標」の演算が峻別されているから、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算」は、ブロックのような親要素（の親要素）

25の移動すべき演算とは明らかに異なるものとして位置付けられているといえる。
19

そして、本件明細書等をみても、「１つのブロックについて移動量を演算して該ブロックの移動後の原点を求め、該求められたブロックの原点の座標に基づき、該ブロックを構成する各セルの原点の座標を演算して求める。これによれば、ブロックの原点に対する各セルの原点の相対位置は予め定まっ5ており、簡単な演算で求めることができ、一方複雑な演算を要する移動量の演算は１つのブロックについてのみ行えばよいので、セル単位で（セルごとに）移動量の演算をする場合に比べて全体として演算量が少なくて済み、移動動作を高速化することができる。」（段落【００４３】）、「ブロックの原点の移動すべき座標が求められたら、この座標がブロックの最初セル〔Ｓ10ｘｆ，Ｓｙｆ〕の原点の座標になるので、他のセルについても X 軸方向およびＹ

軸方向にそれぞれ４８０ずつ順次足していくことによりそれぞれの原点の座標を求める。」（段落【００４４】）と記載されているように、ブロックの原点の座標を利用しつつ、それぞれの枠要素の移動すべき位置を演算して該位置に枠要素を移動させる構成は開示されている。他方、複数の枠要素によ15り構成されるブロックの移動すべき位置を演算し、ブロックと枠要素を一体的に移動させ、移動させる画像の数に関係なく演算量を一定にするという技
術思想は開示されていない。この点について、本件明細書等の【図１３】についても、本件明細書等の実施例にあるブロックの〈DIV ID=canvas BLOCK〉のタグには、position の値が設定されておらず（本件明細書等の【図４】）、20

初期値の static となるため、left、top の値を書き換えてもブロックは移動しないから（甲８）、ブロックの移動すべき位置を演算し、ブロックと枠要
素を一体的に移動させる関数を示すものとはいえない。
さらに、ブロックの移動すべき位置の演算によりブロックと枠要素を一体として移動させ演算量を一定にするという技術思想は、本件各発明の技術的25

意義や作用効果について、全分割画像に比べて限られた数の枠要素の演算をすればよいため、演算量が減少して画像の移動速度が速くなる旨が記載され20た本件明細書等（段落【００２５】）や本件特許の出願過程で提出された意見書（乙２５の５）の内容と矛盾する。
したがって、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」とは、各枠要素の移動すべき位置をそれぞれ演算して枠要素を移動することを意味し、各枠要素の移動すべき位置を演算するこ

5となく、枠要素の親要素やその親要素の移動すべき位置を演算し、枠要素が親要素やその親要素と一体的に移動する構成は含まれないというべきである。
被告地図表示方法の構成要件充足性
被告地図表示方法では、ドラッグ操作による画像の移動処理を、img 要素の親要素の親要素である div 要素（position）の開始タグの left、top の値10を演算して書き換え、img 要素を div 要素（position）と一体的に移動させることで行っており、img 要素の left、top の値を演算、変更して、img 要素を移動させることはしていない。
したがって、被告地図表示方法に img タグにより設定される矩形領域があり、これが「枠要素」（構成要件１Ｂ等）に該当するとしても、被告地図表

15

示方法は、各枠要素の移動すべき位置を演算して枠要素を移動させるものではないから、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」を充足しない。
４20

争点１－４（構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」の充足性）について（原告らの主張）
被告地図表示方法では、ドラッグ操作を行い、表示領域の中心が矩形領域の25

境界を通過するあたりで、img タグの style 属性の left、top の値及び src 属
性のＵＲＬの書換えを行うことにより、同境界を越えた方向と逆方向にある位21

置から矩形領域を削除し、同境界を越えた方向と同方向にある新たに画像を表示させる可能性がある位置に矩形領域を追加して矩形領域の配列を変更しているから、構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領
5

域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」を充足する。
（被告の主張）被告地図表示方法では、img タグの style 属性の left、top の値及び src 属
性のＵＲＬを変更し、この変更に係る img タグで指定された地図画像のデータ

10をダウンロードして表示することがあるものの、あくまで style 属性の値を変更して矩形領域の位置を変更しているにすぎず、img タグや style 属性の記述について削除、追加の処理はしていない。そして、img タグの style 属性を可視化した矩形領域の数も不変であり、ドラッグ操作に伴いその数が増減するこ
ともない。

15

また、img タグの src 属性及び style 属性の変更において、Ｗｅｂブラウザの表示領域から離れる画像であるか否か、Ｗｅｂブラウザの表示領域に近づく画像であるか否かを判別する処理は行われていない。
さらに、被告地図表示方法では、●（省略）●のみならず、急なドラッグ操作がされた場合は、表示領域が地図画像から外20れた後のタイミングで img タグの位置の書換えが行われ、近づく分割画像がな
いところに img タグの位置が移動するから、表示領域に近づく分割画像に該当する位置に枠要素が追加されることはない。
以上によれば、被告地図表示方法は、構成要件１Ｃ－２の「相対移動に伴い
Ｗｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削25

除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」を充足しない。
22

５

争点２－１（乙１０文献を主引例とする進歩性欠如の有無）について（被告の主張）以下のとおり、本件各発明は、乙１０文献に記載された以下の２つの発明（以下「乙１０発明」、「乙１０´発明」という。）それぞれに基づき当業者は容5易に想到し得たものであるから、進歩性を欠く。
乙１０発明
ア

乙１０発明の内容
乙１０文献には、以下の乙１０発明が開示されている。
１０Ａ

画像を表示する表示枠２４よりも大きい画像を分割し該表示枠
２４に少なくとも一部が入る分割画像をサーバから優先的にダウ

10

ンロードして該表示枠２４に表示する画像表示方法において、
１０Ｂ

表示枠２４に少なくとも一部が入る分割画像を含む、表示枠２
４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する

15

表示枠２４に相当する複数のキャッシュ・メモリ上のブロックの配列を設定し、該各キャッシュ・メモリ上のブロックに、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、
１０Ｃ－１

マウスを移動するなどのスクロール操作がなされた時に、表示枠２４に対するキャッシュ・メモリ上のブロックの移動

20

すべき位置を演算して該位置にキャッシュ・メモリ上のブロックを移動し、
１０Ｃ－２

該画像のスクロールに伴い表示枠２４から離れる分割画像
該当する位置からキャッシュ・メモリ上のブロックを抹消し、

25

表示枠２４に近づく分割画像に該当する位置にキャッシュ・
メモリ上のブロックを追加して画像に対するキャッシュ・メ23モリ上のブロックの配列の位置を変更し、該追加するキャッシュ・メモリ上のブロックに、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にし１０Ｄ

前記演算はクライアントにより実行される画像表示方法

乙１０発明の「表示枠２４」、「キャッシュ・メモリ上のブロック」、

5「マウスを移動するなどのスクロール操作がなされた時」及び「画像のスクロール」は、それぞれ本件各発明の「表示領域」、「枠要素」、「表示領域に対する画像の相対移動が指示された時」及び「画像の相対移動」に相当する。
10ａ

これに対し、原告らは、乙１０文献の「ブロック」は「分割画像」
そのものであって、「分割画像」を当てはめるものではないと主張する。
しかしながら、乙１０文献では、「ブロック」が、「分割画像」自体やイメージ（・データ）とは別の「区画」を意味する概念として記15

述され（段落【００３２】、【００３３】、【００６１】、【００９１】）、また、キャッシュ・メモリにロードされたブロックの管理領
域に「画像データ」が含まれるとして、「ブロック」が「分割画像」
自体を意味しないことが明記されている（段落【００８３】、【００９３】ないし【００９８】、【図１６】）。

20

したがって、乙１０文献において、「ブロック」は、「分割画像」
を当てはめる区画を意味するものであり、「分割画像」そのものではない。
仮に、「ブロック」が厳密には「区画」を意味しないとしても、乙１０文献によれば、「キャッシュ・メモリ上のブロック」は、表示枠

25２４の関係で位置関係が特定されるものであり（段落【００６７】、【図１１】）、その管理領域内に含まれる「画像データ」が必要に応24

じてイメージ展開され（段落【００６１】）、当該イメージが「キャッシュ・メモリ上のブロック」と関連付けられ画像として表示されるのであるから、「キャッシュ・メモリ上のブロック」は、本件各発明の「枠要素」に相当する。
ｂ5

原告らは、「キャッシュ・メモリ」は、「ブロック」のデータを一時的に保管するものにすぎず、ブロックを画面上の位置に並べ、その削除と追加により位置の変更を生じさせる構成を備えていないと主張する。
しかしながら、「キャッシュ・メモリ」が、「ブロック」のデータを一時的に保管するものであるからといって、その削除と追加により

10

画像に対する位置の変更が生じる態様の配列に係る構成を備えていな
いと結論付ける理由が不明である。
上記で主張したとおり、表示枠２４に対して、キャッシュ・メモリ
上にブロックの配列が設定され、キャッシュ・メモリ上のブロックの管理領域にある「画像データ」がイメージ展開され、キャッシュ・メ

15

モリ上のブロックと関連付けられ画像として表示されるのであるから、
乙１０文献には、表示枠２４に少なくとも一部が入る分割画像を含む、
表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する
表示枠２４に相当する複数のキャッシュ・メモリ上のブロックの配列

20を設定することが開示されているといえる。
イ

一致点及び相違点
乙１０発明と本件発明１には、以下の相違点１０－１及び２が存在し、
乙１０発明と本件発明２１には上記の相違点に加えて相違点１０－５が25存在するものの、その余は一致する。
（相違点１０－１）25

本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙１０発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とは明示されてはいない点（相違点１０－２）
本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」と5

されているのに対し、乙１０発明では、「キャッシュ・メモリ上のブロックの配置場所の配列」を、「Ｗｅｂブラウザに」設定するものとは明示されていない点（相違点１０－５）
本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信され10

る JavaScript（登録商標）に基づき実行される」のに対し、乙１０発明では、「演算はクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」「JavaScript（登録商標）に基づき実行される」とは明示され
ていない点
15

ウ

相違点の容易想到性
相違点１０－１乙１０文献の段落【００２２】、【００２３】及び【図１】の記載によれば、乙１０発明は、サーバ及びクライアントが通信回線を通じて通信を行ういわゆるクライアントサーバシステムに係る発明である。

20

そして、本件特許出願日当時、このようなクライアントサーバシステ
ムの典型的な例として、ＷｅｂサーバとＷｅｂブラウザを備えたクライ
アントからなるシステムは周知慣用技術であったから（乙１１ないし１３）、乙１０発明に触れた当業者には、乙１０発明のクライアントサー
バシステムとして、ＷｅｂサーバとＷｅｂブラウザを備えたクライアン

25

トからなる構成を採用する強い動機付けがあった。また、このような典型的なシステムを採用することは、設計事項にすぎなかった。
26

したがって、相違点１０－１に係る構成は容易に想到することができた。
相違点１０－２
乙１０発明においてＷｅｂサーバとＷｅｂブラウザを備えたクライア
ントからなる構成を採用すれば、キャッシュ・メモリ上のブロックに、

5該当する位置の分割画像をそれぞれ当てはめることで、Ｗｅｂブラウザの表示領域に分割画像を表示し又は表示できる状態にすることになり、必然的に複数のキャッシュ・メモリ上のブロックの配列はＷｅｂブラウ
ザに設定されることになるから、相違点１０－２に係る構成は容易に想到することができた。

10

相違点１０－５
ＷｅｂサーバとＷｅｂブラウザを備えたクライアントからなるシステ
ムでは、演算をＷｅｂブラウザにおける JavaScript の実行によるものとすることは、周知慣用技術であった（乙３ないし５、乙７）。そうす
ると、乙１０発明においてＷｅｂサーバとＷｅｂブラウザを備えたクラ15

イアントからなる構成を採用するに当たり、演算をＷｅｂブラウザにおける JavaScript の実行によるものとすることは、単なる設計事項にすぎず、また、演算の必要から採用する動機付けもあった。
したがって、相違点１０－５に係る構成は容易に想到することができた。

20

仮に、被告が認める相違点以外の相違があるとしても、実質的な相違点ではないか、その相違に係る構成が容易想到なものにすぎない。
乙１０´発明ア25

乙１０´発明の内容
仮に、原告らの主張するとおり、乙１０文献における「ブロック」が「分割画像」そのものであり、「画像表示のための処理」（段落【００27

６１】、【００６２】、【図９】）により画面に表示されるものであるとすると、乙１０文献の「図１１は画像表示に当っての表示画像範囲の移動を説明する図である。…図示×印を付したブロックがクライアント
５側へ転送されて、図示の表示画面２７に表示される。」という記載（段5

落【００６６】、【００６７】）によれば、【図１１】に、「画像表示のための処理」により、表示枠に一部でも含まれる「ブロック」（分割画像）につき、表示枠との関係でそれぞれの配置場所を設定し、「ブロック」を表示し又は表示できる状態にすることの開示があるということになるから、乙１０文献には、以下の乙１０´発明が開示されているこ

10

とになる。
１０´Ａ

画像を表示する表示枠２４よりも大きい画像を分割し該表示
枠２４に少なくとも一部が入るブロックをサーバから優先的にダウンロードして該表示枠２４に表示する画像表示方法におい
て、

15

１０´Ｂ

表示枠２４に少なくとも一部が入るブロックを含む、表示枠
２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれるブロックを、「画像表示のための処理」により、個々に関連づけて表示する表示枠２４に相当する複数のブロックの配置場所の配列を設定し、該各ブロックの20

配置場所に、該当する位置のブロックをそれぞれ関連づけて表
示し又は表示できる状態にし、かつ、
１０´Ｃ－１

マウスを移動するなどのスクロール操作がなされた時に、表示枠２４に対するブロックの配置場所の移動すべき位置を演算して該位置にブロックの配置場所を移動し、

25

１０´Ｃ－２「画像表示のための処理」により、該画像のスクロールに伴い表示枠２４から離れるブロックに該当する位置か
28

らブロックの配置場所を抹消し、表示枠２４に近づくブロックに該当する位置にブロックの配置場所を追加して画像に対するブロックの配置場所の配列の位置を変更し、該追加するブロックの配置場所に、該当する位置のブロックを関連づけて表示しまたは表示できる状態にし

5

１０´Ｄ

前記演算はクライアントにより実行される画像表示方法

乙１０´発明の「表示枠２４」、「ブロック」、「関連づけて」、「マウスを移動するなどのスクロール操作がなされた時」及び「画像のスクロール」は、それぞれ本件各発明の「表示領域」、「分割画像」、「当10てはめて」、「表示領域に対する画像の相対移動が指示された時」及び「画像の相対移動」に相当する。また、乙１０´発明の「ブロックの配置場所」は、所定の位置、サイズ等を特定するものであるから、本件各発明の「枠要素」に相当する。
ａ15

これに対し、原告らは、「ブロック」のうち表示枠に表示されない部分は、「画像表示のための処理」に先立ち、サーバ（段落【００３１】ないし【００３４】）又はクライアント（段落【００４８】、【００４９】）のいずれかによりカットされるため、乙１０文献には、ブロックが表示できる状態にする構成の開示はないと主張する。
しかしながら、本件各発明は、「表示しまたは表示できる」と選択

20的に規定されているとおり、「表示」（する）と「表示できる」のいずれかを満たせば足りるところ、乙１０´発明が「ブロック」を「表示」する構成を備えていることについて争いはないから、原告らの上記主張は乙１０´発明の認定とは無関係である。
もとより、乙１０´発明では、「表示枠」の外側にある部分も含め25て全体がクライアント５に伝送され（段落【００３３】）、ブロックの一部は表示され、一部は表示されていない状態になるから、ブロッ
29

クを表示し又は表示できる状態にする構成は開示されている。これに対し、原告らは、クライアントが画像をカットしている根拠として段落【００４８】、【００４９】を挙げるが、これらの段落には、クライアントのＣＰＵに余裕がある場合に限りＪＰＥＧのままで伝送させる割合を増加させることが開示しているのみであって、クライアント

5

が画像をカットすることなどの記載はない。また、原告らがサーバ側で画像をカットすることの根拠として挙げる段落【００３１】ないし【００３４】には、サーバ１が、一部のイメージだけをクライアント
５に伝送する構成が開示されているが、これは乙１０文献に係る特許の請求項１の従属項に対応するものであり、乙１０´発明においては

10

必須の要素とされた構成ではない。
したがって、乙１０文献には、ブロックが表示できる状態にする構成の開示がある。
ｂ
15

また、原告らは、乙１０文献の段落【００２３】の記載を根拠に、
乙１０文献に記載された発明は、「画像表示のための処理」として「ブロック（画像）」の「貼り合わせ」処理を行った１枚の画像を「表示枠」に表示する構成を備えるものにすぎないと主張する。
しかしながら、段落【００２３】には、単に「分割画像の貼り合わせを行い」と記載されているのみで、分割画像を１枚の画像にするこ20となど記載されておらず、【図１１】等も踏まえれば、単に各「キャッシュ・メモリ上のブロック」に対応して各分割画像を位置付けること、あるいは、「ブロック」を「ブロックの配置場所」に配置することをもって、「分割画像の貼り合わせを行い」と表現したものと理解
できる。

25

したがって、乙１０´発明が、「貼り合わせ」処理を行った１枚の画像を「表示枠」に表示する構成を備えるものということはできない。
30

イ

一致点及び相違点
乙１０´発明と本件発明１には、以下の相違点１０´－１及び２が存在
し、乙１０発明と本件発明２１には上記の相違点に加えて相違点１０´－５が存在するものの、その余は一致する。
（相違点１０´－１）

5

本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙１０´発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とは明示されてはいない点（相違点１０´－２）
本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」と10されているのに対し、乙１０´発明では、「ブロックの配置場所の配列」
を、「Ｗｅｂブラウザに」設定するものとは明示されていない点（相違点１０´－５）
本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信される JavaScript（登録商標）に基づき実行される」のに対し、乙１０´発明

15では、「演算はクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」「JavaScript（登録商標）に基づき実行される」とは明示されていない点ウ
20

相違点の容易想到性
相違点１０´－１、２及び５に係る構成は、乙１０発明についての相違
点の容易想到性で主張した理由（上記ウ）と同じ理由により、容易に想到し得たものである。
仮に、被告が認める相違点以外の相違があるとしても、実質的な相違点ではないか、その相違に係る構成が容易想到なものにすぎない。
25（原告らの主張）
以下のとおり、本件各発明は、乙１０発明及び乙１０´発明と相違し、当該
31相違点は容易想到ではないから、乙１０発明及び乙１０´発明との関係で進歩性を有する。
乙１０発明について
ア5

乙１０発明の内容について
被告は、乙１０文献における「分割画像」は「ブロック」に当てはめられる関係にあると主張する。
しかしながら、乙１０文献の段落【００２８】の「最高解像度ファイル
１１を構成するブロック」という記載や、段落【００４５】の「当該ブロックをＪＰＥＧのままで転送する」という記載、【図３】、【図８】等の10記載によれば、乙１０文献における「ブロック」は「分割画像」そのものであり、「分割画像」を当てはめるものではない。
また、被告は、乙１０文献における「キャッシュ・メモリ」には「ブロック」の「配列」が設定され、また、この「配列」は表示させる画面上の位置に対応して並べられ、それゆえ「ブロック」の抹消（削除）と追加は

15

全体画像に対する位置の変更をもたらすと主張する。
しかしながら、乙１０文献の段落【００６１】、【００６２】、【図９】等において、「キャッシュ・メモリ」上の「ブロック」のデータは、これに対応する分割画像を画面上に表示するために「画像表示のための処理」
が別途必要とされているとおり、乙１０文献における「キャッシュ・メモ

20

リ」は、単に「サーバ１」から受信した「ブロック」のデータを一時的に保管するものにすぎず、ブロックを画面上の位置に並べ、その削除と追加により画像に対する位置の変更を生じさせる構成を備えていない。
したがって、乙１０文献に開示されている乙１０発明の内容は、以下のものとなる。

25

１０Ａ

画像を表示する表示枠２４よりも大きい画像を分割し該表示枠

２４に少なくとも一部が入る「ブロック（画像）」をサーバから優32

先的にダウンロードして該表示枠２４に表示する画像表示方法において、
１０Ｂ

表示枠２４に少なくとも一部が入る「ブロック（画像）」を含む、
表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる「ブロック（画像）」を「画像表示5のための処理」により表示し、かつ、
１０Ｃ－１

マウスを移動するなどのスクロール操作がなされた時に、表
示枠２４に対する「ブロック（画像）」の移動すべき位置を演算して該位置に「ブロック（画像）」を移動し、

１０Ｃ－２

10

該画像のスクロールに伴い表示枠２４から離れる「ブロック（画像）」に該当する位置からキャッシュ・メモリ上の「ブロック（画像）」を抹消し、表示枠２４に近づく「ブロック（画像）」に該当する位置の「ブロック（画像）」をキャッシュ・
メモリに追加して「画像表示のための処理」により表示し

１０Ｄ

15

イ

前記演算はクライアントにより実行される画像表示方法

一致点及び相違点について
乙１０発明と本件発明１には、相違点１０－１のほか、以下のとおり、相違点１０－２´、３及び４が存在し、乙１０発明と本件発明２１には、上記の相違点に加えて相違点１０－５が存在する。

20（相違点１０－２´）
本件各発明は、「…分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし」とされているのに対し、乙１０発明はかかる構成を備えていな

25

い点（相違点１０－３）33

本件各発明は、「Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき
位置を演算して該位置に枠要素を移動し」という構成を備えるのに対し、
乙１０発明はかかる構成を備えていない点（相違点１０－４）5

本件各発明は、「該画像の相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする」という構成を10備えるのに対し、乙１０発明はかかる構成を備えていない点
ウ

相違点の容易想到性について
相違点１０－１について
被告は、ＷｅｂサーバとＷｅｂブラウザを備えたクライアントからな

15るシステムが周知慣用技術であったことを理由として、相違点１０－１を解消することは容易に想到できると主張する。
しかしながら、乙１０文献にＨＴＭＬ、JavaScript など「Ｗｅｂブラウザ」により実現できることを示唆する記載がないことからすると、乙１０文献では「Ｗｅｂブラウザ」をクライアントに備えることは、全く20予定されていない。
したがって、被告の主張は、本件各発明の構成を念頭に置いた単なる後知恵のものにすぎない。
相違点１０－２´、３及び４について
被告は、相違点１０－２´、３及び４に関する容易想到性の主張をし

25

ていない。
相違点１０－５について
34

上記

及び

で主張したとおり、乙１０発明に相違点１０－１、２´、３及び４に係る構成を適用すべき理由はないから、本件発明２１に相違
点１０－５に係る構成を適用する前提を欠く。
乙１０´発明について5ア

乙１０´発明の内容について
被告は、乙１０文献の【図１１】などを根拠に、乙１０文献には、「ブロックの配置場所」という「枠要素」に相当する構成を含む「表示枠２４に相当する複数のブロックの配置場所の配列を設定し、該各ブロックの配置場所に、該当する位置のブロックをそれぞれ関連づけて表示しまたは表10

示できる状態にし」という構成が開示されていると主張する。
しかしながら、【図１１】は、画像表示と表示画像範囲の移動に関する説明のための概念図にすぎないから、【図１１】から、ブロックの配置場所の設定という細部の構成まで認定することはできない。
また、画像データを管理する「ブロック管理領域」には「当該ブロック

15の座標情報」 が記述されていることや（段落【００９４】ないし【００９８】、【図１６】）、表示枠と表示される画像位置の対応関係に関する情報が取得されていることからすれば、乙１０文献における「画像表示のための処理」（段落【００６２】）とは、表示枠と表示する画像の位置関係を特定し、当該対応関係をもとに表示枠に含まれる「ブロック」及びその

20

座標情報の伝送を受け、表示枠にブロックを表示させるというものであると合理的に推察される。そうすると、乙１０文献の記載から、ビューアに設定され「ブロック」を当てはめる「枠要素」に相当する構成など観念できない。
さらに、「画像表示のための処理」では、「ブロック」のうち表示枠に25表示されない部分は、「画像表示のための処理」に先立ち、サーバ（段落【００３１】ないし【００３４】）又はクライアント（段落【００４８】、
35

【００４９】）のいずれかによりカットされるため、乙１０文献には、ブロックが表示できる状態にする構成の開示はない。
加えて、乙１０文献には表示枠との関係でブロックの配置場所を設定する構成の記載はなく、乙１０文献の段落【００２３】の「（画像表示部は、）
5…分割画像の貼り合わせを行い」という記載によれば、乙１０文献に記載された発明は、「画像表示のための処理」として「ブロック（画像）」の「貼り合わせ」処理を行った１枚の画像を「表示枠」に表示する構成を備えるものにすぎない。
したがって、乙１０文献に開示されている乙１０´発明の内容は、以下10のものとなる。
１０´Ａ

画像を表示する表示枠２４よりも大きい画像を分割し該表示枠
２４に少なくとも一部が入る「ブロック（画像）」をサーバから優先的にダウンロードして該表示枠２４に表示する画像表示方法において、

15

１０´Ｂ

表示枠２４に少なくとも一部が入る「ブロック（画像）」を含
む、表示枠２４に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる「ブロック（画像）」を、「画像表示のための処理」により表示し、かつ、

１０´Ｃ－１20

マウスを移動するなどのスクロール操作がなされた時に、スクロール後の地図の位置を演算して表示枠２４に表示すべき「ブロック（画像）」を「画像表示のための処理」により表示し、
１０´Ｃ－２「画像表示のための処理」により、該画像のスクロールに伴い表示枠２４から離れる「ブロック（画像）」に該当する位
25

置から当該「ブロック（画像）」を抹消し、表示枠２４に近づく「ブロック（画像）」に該当する位置に当該「ブロック（画36

像）」を表示し１０´Ｄイ

前記演算はクライアントにより実行される画像表示方法

一致点及び相違点について
乙１０´発明と本件発明１には、相違点１０´－１のほか、相違点１０－２´、３及び４と同様の相違点１０´－２´、３及び４が存在し、乙１5０´発明と本件発明２１には、上記の相違点に加えて相違点１０´－５が存在する。
ウ

相違点の容易想到性について
乙１０´発明と本件各発明の相違点に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（上記

10ウ）と同じ理由により、容易に想到できるものではない。
６

争点２－２（乙１４文献を主引例とする進歩性欠如の有無）について（被告の主張）以下のとおり、本件各発明は、乙１４文献に記載された以下の２つの発明（以15下「乙１４の１発明」、「乙１４の２発明」という。）それぞれに基づき、当業者は容易に想到し得たものであるから、進歩性を欠く。
乙１４の１発明ア

乙１４の１発明の内容
乙１４文献記載の第１実施形態には、以下の乙１４の１発明が開示さ

20

れている。
乙１４の１Ａ

端末装置３における表示装置３１に画像を表示する表示
区域５１よりも大きい、日本全国の地域を網羅する広い範
囲の地図データをマトリクス状に区分し該表示装置３１の表示区域５１にその全体が入る、マトリクス状に区分さ25れた画像データをセンター装置２から優先的に受信して該表示装置３１の表示区域５１に表示する画像表示方法
37

において、
乙１４の１Ｂ

表示装置３１の表示区域５１にその全体が入る表示装置
３１の表示区域５１に表示される、地図データ全体に対して限定された範囲の画像領域を構成する画像データを、個々に当てはめて表示する表示区域５１に相当する複数

5の区画の配列を表示装置３１に設定し、該各区画に、該当する位置の画像データをそれぞれ当てはめて表示し、かつ、
乙１４の１Ｃ－１

表示装置３１の表示区域５１に対する画像のスクロールが指示された時に、表示装置３１の表示区域５１における各区画に当てはめられた画像データの移動す10べき位置を演算して該位置にある固定されている区画に画像データを移動し、
乙１４の１Ｃ－２

該画像の相対移動に伴い表示装置３１の表示区域５１から離れる画像データを固定されている区画から削除し、表示装置３１の表示区域５１に近づく画像デー

15

タを固定されている区画に追加して画像に対する区画の配列の位置を変更し、該追加する画像データを、該当する位置の固定されている区画に当てはめて表示し、前記演算は端末装置３により実行され、受信した画像データを記憶装置に記憶しておき、区20

画に当てはめるべき画像データが記憶装置に記憶されている場合は、記憶されている画像データを区画に当てはめて表示させることができる
乙１４の１Ｄ25

画像表示方法

乙１４の１発明の「表示区域５１」、「画像データ」、「センター装
置２」及び「区画」は、それぞれ本件発明１の「表示領域」、「分割画38

像」、「サーバ」及び「枠要素」にそれぞれ相当する。
イ

一致点及び相違点
乙１４の１発明と本件発明１には、以下の相違点１４の１－１ないし５が存在し、乙１４の１発明と本件発明２１には上記の相違点に加えて、

5

相違点１４の１－７が存在するものの、その余は一致する。
（相違点１４の１－１）
本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙１４の１発明の「表示区域５１」は、「Ｗｅｂブラ
ウザの表示領域」とは明示されてはいない点

10（相違点１４の１－２）
本件各発明は、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙１４の１発明では、「区画」を、「Ｗｅｂブラ
ウザに」設定するものとは明示されていない点（相違点１４の１－３）15

表示領域に対する画像の相対移動が指示された時に行われる移動処理が、本件発明１では、「枠要素の移動すべき位置を演算して該位置に枠要素を移動」することであるのに対し、乙１４の１発明では、「画像データの移動すべき位置を演算して該位置にある固定されている区画に画像データを移動」することである点

20（相違点１４の１－４）
画像の相対移動に伴い表示領域から離れる分割画像に関する削除処理
が、本件各発明では、「表示領域から離れる分割画像に該当する位置から枠要素を削除」することであるのに対し、乙１４の１発明では、「表示区域５１から離れる画像データを固定されている区画から削除」する25ことである点（相違点１４の１－５）39表示領域に近づく分割画像に関する追加処理が、本件発明１では、「表
示領域に近づく分割画像に該当する位置に枠要素を追加して…該追加する枠要素に、該当する位置の分割画像を当てはめ」るのに対し、乙１４の１発明では、「表示区域に近づく画像データを固定されている区画に5追加」のみ行う点（相違点１４の１－７）
本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバーから送信されるＪａｖａＳｃｒｉｐｔ（登録商標）に基づき実行される」のに対し、乙１４－１発明では、「端末装置３により実行される」ものの、こ10

れが「Ｗｅｂブラウザ」、「ＪａｖａＳｃｒｉｐｔ（登録商標）に基づ
き実行される」とは明示されていない点
原告らは、乙１４の１発明と本件各発明には、上記の相違点のほかに、相違点１４の１－６（本件各発明は、「枠要素」に当てはめられること
により「分割画像」は「表示しまたは表示できる状態」となるのに対し、

15

乙１４の１発明では、「区画」に当てはめられた「画像データ」は常にその全体が表示される点）が存在すると主張する。
しかしながら、本件発明１の請求項の「表示しまたは表示できる状態にし（する）」なる文言は、「表示し」と「表示できる状態にし（する）」
が「または」で結ばれているのだから、「表示し」と「表示できる状態

20にし（する）」の少なくとも一方を選択的に特定しているにすぎず、その両方を必須の要件としているわけではない。そうすると、乙１４の１
発明の「表示し」の構成は、本件各発明の「表示しまたは表示できる状態」に相当する構成と一致する。
仮に、本件発明１の請求項の「表示しまたは表示できる状態にし（す25る）」なる文言が、「表示し」と「表示できる状態」の両方が必須のものとして規定されていると限定解釈したとしても、乙１４の１発明は、40受信した画像データを区画に当てはめるとともに記憶装置に記憶しておき、その画像データが非表示になってもスクロール操作などによってその画像データを表示する必要が生じた場合には、これを記憶装置から読み出して区画に当てはめて表示させることができる状態になっていることからすると、乙１４の１発明は、「表示しまたは表示できる状態にし5（する）」との構成を有しているといえる。
ウ

相違点の容易想到性
相違点１４の１－１及び２
乙１４の１発明も、サーバ（センター装置２）及びクライアント（端10末装置３）が通信回線を通じて通信を行うクライアントサーバシステム
である（乙１４文献の段落【００２３】）。したがって、相違点１４の１－１及び２に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（争点２－１（被告の主張）

ウ

及び）と同じ理由により、容易に想到できるものである。
15

相違点１４の１－３
本件各発明では、枠要素を移動することによって、表示領域に表示される分割画像が移動するところ、乙１４の１発明では、画像データ（分割画像）を移動することによって、表示領域に表示される画像データ（分割画像）が移動する。したがって、本件各発明も乙１４の１発明も、表

20

示領域に表示される分割画像が移動する点は一致しており、相違点１４の１－３は、枠要素を移動するか、分割画像を移動するか、という表現上の違いにすぎないから、実質的な相違点ではない。
仮に実質的に相違するとしても、表示領域に表示させる分割画像を移動させるに当たり、枠要素及び分割画像のいずれを移動するかは、当業25者であれば適宜なし得る設計事項であるから、相違点１４の１－３に係る構成は容易に想到できるものである。
41

相違点１４の１－４
本件各発明では、枠要素を削除することによって当該枠要素に当てはめられていた分割画像が表示領域から非表示となるところ、乙１４の１発明では、区画（枠画像）から画像データ（分割画像）を削除すること
5によって当該区画（枠要素）に当てはめられていた画像データ（分割画像）が表示領域から非表示となる。したがって、本件各発明も乙１４の１発明も、分割画像が表示領域から非表示となる点は一致しており、相違点１４の１－４は、枠要素を削除するか、分割画像を枠要素から削除するか、という表現上の違いにすぎないから、実質的な相違点ではない。

10

仮に実質的に相違するとしても、表示領域から分割画像を非表示とするに当たり、枠要素及び分割画像のいずれを削除するかは、当業者であれば適宜なし得る設計事項であるから、相違点１４の１－４に係る構成は容易に想到できるものである。
相違点１４の１－５15

本件各発明では、枠要素を追加することによって当該枠要素に当てはめられる分割画像が新たに表示領域から表示されるところ、乙１４の１発明では、画像データ（分割画像）を区画（枠要素）に追加することによって当該区画（枠要素）に当てはめられる画像データ（分割画像）が新たに表示領域に表示される。したがって、本件各発明も乙１４の１発

20

明も、分割画像が新たに表示領域に表示される点は一致しており、相違
点１４の１－５は、枠要素を追加してこれに分割画像を当てはめるか、分割画像を枠要素に追加するか、という表現上の違いにすぎないから、実質的な相違点ではない。
仮に実質的に相違するとしても、分割画像を表示領域に新たに表示さ25

せるに当たり、枠要素を追加してこれに分割画像を当てはめるか、分割
画像を追加するかは、当業者であれば適宜なし得る設計事項であるから、
42

相違点１４の１－５に係る構成は容易に想到できるものである。
相違点１４の１－６
相違点１４の１－６に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（争点２－１（被告の主張）

ウ

）と同じ理

由により、容易に想到できるものである。

5

相違点１４の１－７
相違点１４の１－７に係る構成は、乙１０発明についての相違点の容易想到性で主張した理由（争点２－１（被告の主張）

ウ

）と同じ理

由により、容易に想到できるものである。
乙１４の２発明10

ア

乙１４の２発明の内容
乙１４文献記載の第２実施形態には、以下の乙１４の２発明が開示さ
れている。
１４の２Ａ

Ｗｅｂブラウザの画像を表示する地図表示画面１５２よりも大きい、日本全国の地域を網羅する広い範囲の地図デー

15

タをマトリクス状に区分し該Ｗｅｂブラウザの地図表示画面
１５２にその全体が入る画像データをサーバ装置１０２から優先的にダウンロードして該Ｗｅｂブラウザの地図表示画面
１５２に表示する画像表示方法において、
20

１４の２Ｂ

Ｗｅｂブラウザの地図表示画面１５２にその全体が入る、
Ｗｅｂブラウザの地図表示画面１５２に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域を構成する画像データを、個々に当てはめて表示する地図表示画
面１５２に相当する複数の区画の配列をＷｅｂブラウザに25設定し、該各区画に、該当する位置の画像データをそれぞれ当てはめて表示し、かつ、
43

１４の２Ｃ－１

Ｗｅｂブラウザの地図表示画面１５２に対する画像のスクロールが指示された時に、サーバ装置１０２から送信されるＨＴＭＬファイルを実行することによって、表示すべき画像データが記憶装置にキャッシュされていればその画像データを、キャッシュされていなければサー5

バ装置１０２に要求してサーバ装置１０２から受信した
画像データを、固定されている区画にそれぞれ当てはめて表示することによってスクロール処理を行い、
１４の２Ｃ－２

受信した画像データを記憶装置に記憶しておき、区画に当てはめるべき画像データが記憶装置に記憶されてい10る場合は、記憶されている画像データを区画に当てはめて表示させることができる
１４の２Ｄ

画像表示方法

乙１４の２発明の「地図表示画面１５２」、「地図データ」、「画像データ」及び「区画」は、それぞれ本件発明１の「表示領域」、「画像」、

15「分割画像」及び「枠要素」に相当する。
イ

一致点及び相違点
乙１４の２発明と本件発明１には、以下の相違点１４の２－３ないし５が存在し、乙１４の２発明と本件発明２１には上記の相違点に加えて20

相違点１４の２－７が存在するものの、その余は一致する。
（相違点１４の２－３）
表示領域に対する画像の相対移動が指示された時に行われる移動処理が、本件各発明では、「枠要素の移動すべき位置を演算して該位置に枠要素を移動」することであるのに対し、乙１４の２発明では「区画」は25

移動しない点（固定された「区画」に移動させた「画像データ」が当てはめられる。）。
44

（相違点１４の２－４）
画像の相対移動に伴い表示領域から離れる分割画像に関する削除処理
が、本件各発明では、「表示領域から離れる分割画像に該当する位置から枠要素を削除」することであるのに対し、乙１４の２発明では、「画像データを固定されている区画から削除」することである点

5（相違点１４の２－５）
表示領域に近づく分割画像に関する追加処理が、本件各発明では、「表
示領域に近づく分割画像に該当する位置に枠要素を追加して…該追加する枠要素に、該当する位置の分割画像を当てはめ」るのに対し、乙１４の２発明では、「地図表示画面１５２」に近づく画像データを固定され10ている「区画」に「追加」のみ行う点（相違点１４の２－７）
本件発明２１は、「Ｗｅｂブラウザでの各演算がサーバから送信される JavaScript（登録商標）に基づき実行される」のに対し、乙１４の２発明では、「Ｗｅｂブラウザでの各演算はサーバから送信されるＨＴＭ

15

Ｌファイルにより実行される」ものの、これが「JavaScript（登録商標）に基づき実行される」とは明示されていない点
原告らは、乙１４の２発明と本件各発明には、上記の相違点のほかに、相違点１４の２－６（本件発明１は、「枠要素」に当てはめられること
により「分割画像」は「表示しまたは表示できる状態」となるのに対し、

20

乙１４の２発明では、「区画」に当てはめられた「画像データ」は常にその全体が表示される点）が存在すると主張するが、乙１４の１発明で主張した理由（上記イ）と同じ理由により、乙１４の２発明と本件各発明には、相違点１４の２－６は存在しないというべきである。
25

ウ

相違点の容易想到性
相違点１４の２－３ないし５45

ａ

乙１５文献で開示されている発明（以下「乙１５発明」という。）の内容は、表示領域に対する画像のスクロールが指示された時に、表示領域に対するセルの移動すべき位置を演算して該位置にセルを移動し、該画像の相対移動に伴い表示領域から離れる分割領域に該当する位置からセルを消去し、表示領域に近づく分割領域に該当する位置に5セルを追加して画像に対するセルの配列の位置を変更し、該追加するセルに、該当する位置の分割領域を当てはめて表示し又は表示できる状態にする画像スクロール方法というものである。したがって、乙１
５文献には、相違点１４の２－３ないし５の構成が開示されている。
10ｂ

乙１４の２発明は、部分画像を送信するという構成により画像を１画面単位で送信するのに比べればスムーズにスクロールできるものの、
乙１４文献の段落【００８８】に「端末装置１０３では、ブラウザソ
フトウェアが上記第３のＨＴＭＬファイル（009_012.htm)を受信すると、ブラウザソフトウェアはその第３のＨＴＭＬファイル（009_012.

15htm)のプログラムを実行し、このプログラムにより表示指示された画像データがＲＡＭ１３３にキャッシュされていれば、それを表示し、ＲＡＭ１３３にキャッシュされていなければ、その画像データの転送要求をサーバ装置１０２に行う。」という記載があるように、スクロールを行う場合に、表示指示された分割データのうち端末装置１０３

20内にキャッシュされていない分割画像データを検索してサーバ装置１
０２に転送を要求する必要があるため、当該処理に時間がかかり、連続的なスクロール自体の実現が困難であるという問題を有している。
これに対し、乙１５文献には「スクロールを行う場合、その途中で未表示データの検索表示が必要になるが、この処理に時間がかかり、

25

連続的なスクロール自体の実現が困難であった。本発明の目的は、これらの問題を解決する図形データ表示方法を提案することにある。」
46

（４９０頁左上欄１７行目から右上欄２行目）と記載されているように、スクロールを行う場合にデータ検索が必要であると処理に時間がかかり、連続的なスクロール自体の実現が困難であるという乙１４の２発明の抱える問題が、乙１５発明によって解決されることが示され5ている。
そうすると、乙１４の２発明のスクロール処理として、乙１５発明に係るスクロール方法を適用する動機付けがあるから、相違点１４の２－３ないし５に係る構成は、乙１４の２発明に乙１５発明に係るス
クロール方法を適用することによって、当業者が容易に想到すること

10

ができた。
なお、仮に乙１４文献において「キャッシュされていない部分画像を検索する処理に時間がかかる」という課題が明示されていないとしても、乙１４の２発明及び乙１５発明はいずれも、分割された部分画像を用いた画像表示に係る発明で、スクロール操作をスムーズに行う

15

ことを目的とする点で共通し、また、乙１５発明におけるスクロール
処理を乙１４の２発明に適用するのが困難であるという事情も存在しないから、乙１４の２発明に乙１５発明のスクロール方法を適用する
動機付けは十分に存在する。
相違点１４の２－７

20

ＨＴＭＬファイルによって演算が行われる乙１４の２発明において、
ＨＴＭＬファイルに JavaScript を組み合わせ、JavaScript に基づいて演算を行うようにすることは、単なる設計事項であるか、周知慣用技術の適用にすぎないから、相違点１４の２－７に係る構成は、当業者であれば容易に想到することができた。

25（原告らの主張）
以下のとおり、本件各発明は、乙１４の１発明及び乙１４の２発明と相違し、
47

当該相違点は容易想到ではないから、乙１４の１発明及び乙１４の２発明との関係で進歩性を有する。
乙１４の１発明についてア

乙１４の１発明の内容について
乙１４の１発明の内容が、被告主張のとおりであることは、争わない。

5

イ

一致点及び相違点について
乙１４の１発明と本件発明１には、相違点１４の１－１ないし５及び７のほか、以下の相違点１４の１－６が存在し、乙１４の１発明と本件発明２１には、上記の相違点に加えて、以下の相違点１４の１－７が存

10

在する。
（相違点１４の１－６）
本件各発明は、「枠要素」に当てはめられることにより「分割画像」
は「表示しまたは表示できる状態」となるのに対し、乙１４の１発明では、（演算は）「区画」に当てはめられた「画像データ」は常にその全15体が表示される点（相違点１４の１－７）
本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバーから送信されるＪａｖａＳｃｒｉｐｔ（登録商標）に基づき実行される」のに対し、乙１４－１発明では、「端末装置３により実行される」ものの、こ20

れが「Ｗｅｂブラウザ」、「ＪａｖａＳｃｒｉｐｔ（登録商標）に基づ
き実行される」とは明示されていない点
被告は、乙１４の１発明と本件各発明に相違点１４の１－６は存在しないと主張する。
しかしながら、乙１４の１発明は、「画像データ」が、固定された「区25画」に当てはめられて常にその全体が「表示区域５１」に表示される発明であるのに対し、本件各発明は、「枠要素」に当てはめた「分割画像」
48

について、その画像全体が常には表示されない状態（すなわち、「表示できる状態」）を意図的に設けることによって（構成要件１Ｂ）、相対移動が指示された時に、従前の当てはめを維持しながら、「枠要素」を移動して「表示できる状態」にあった画像を「表示」することにより、
上記指示に基づく移動後の画像表示を可能とする構成（構成要件１Ｃ－5１）を備えた発明である。
そうすると、常にその全体の「画像データ」を表示する乙１４の１発
明には、「表示しまたは表示できる状態」（構成要件１Ｂ等）に相当す
る構成はないから、乙１４の１発明と本件各発明との間に相違点１４の１－６は存在する。

10

ウ

相違点の容易想到性について
被告の乙１４の１発明に基づく進歩性欠如の主張は、相違点１４の１－６に係る構成の容易想到性の主張がないので、失当である。
また、以下のとおり、その余の相違点に係る構成も容易に想到できたと15はいえない。
相違点１４の１－１及び２について相違点１４の１－３に係る構成が適用された乙１４の１発明を仮想した場合、この仮想発明に対して相違点１４の１－１及び２に係る構成を適用することは容易でない。

20

相違点１４の１－３ないし５について
被告は、相違点１４の１－３ないし５は、実質的な相違点ではなく、
仮に実質的に相違するとしても、設計事項であって、相違点１４の１－
３ないし５に係る構成は容易に想到できると主張する。
しかしながら、乙１４の１発明は、「区画」の大きさ（「画像データ」

25の縦横の大きさ）を移動量とした飛び飛びの移動態様のスクロールしか行えない構成であるのに対し、本件各発明は、「枠要素」の大きさ（「分49

割画像」の縦横の大きさ）とは無関係に、ドラッグ操作に応じた適宜の量を移動させることができるものであって、両発明のスクロールによる移動の態様は全く異なっているから、相違点１４の１－３ないし５は、実質的な相違点である。
また、乙１４の１発明では、「表示区域５１」に表示されている所定

5領域の部分地図が選択された場合、この選択位置に基づく「移動方向テーブル」から決定される移動量に基づいて、「画像データ」の移動先となる「区画」を定め、「画像データ」を移動させる構成により、スクロ
ール処理を実現しており、「画像データ」と共に「区画」を移動させる構成を採用することは全く予定していないのであるから、乙１４の１発

10

明に相違点１４の１－３ないし５に係る構成を適用することは、当業者が適宜なし得る設計事項とはいえない。
したがって、相違点１４の１－３ないし５に係る構成が容易に想到できたとはいえない。
相違点１４の１－７について

15

乙１４の１発明に相違点１４の１－１ないし６に係る構成を適用すべ
き理由はないから、本件発明２１に相違点１４－７に係る構成を適用す
る前提を欠く。
また、仮に相違点１４の１－３に係る構成が適用された乙１４の１発明を想定した場合、この仮想発明に対して相違点１４の１－７に係る構20成を適用することは容易でない。
乙１４の２発明についてア

乙１４の２発明の内容について
乙１４の２発明の内容が、被告主張のとおりであることは、争わない。

25

イ

一致点及び相違点について
乙１４の２発明と本件発明１には、相違点１４の２－３ないし５及び50

７のほか、以下の相違点１４の２－６が存在し、乙１４の２発明と本件発明２１には、上記の相違点に加えて相違点１４の２－７が存在する。
（相違点１４の２－６）
本件各発明は、「枠要素」に当てはめられることにより「分割画像」
は「表示しまたは表示できる状態」となるのに対し、乙１４の２発明で5は、「区画」に当てはめられた「画像データ」は常にその全体が表示される点
被告は、乙１４の２発明と本件各発明に相違点１４の２－６は存在しないと主張する。
しかしながら、乙１４の２発明は、ＨＴＭＬファイル（「画像データ」

10

等を端末装置の表示画面の指定位置に表示させるプログラム）のサーバへの転送要求、ダウンロード等をＷｅｂブラウザで行う点が乙１４の１発明とは異なるものの、「画像データ」が、固定された「区画」に当てはめられて常にその全体が「地図表示画面１５２」に表示される点では、
乙１４の１発明と構成を共通にする。したがって、乙１４の１発明と本15件各発明に相違点１４の１－６が存在するのと同様の理由（上記イ）により、乙１４の２発明と本件各発明にも相違点１４の２－６が存在するというべきである。
ウ
20

相違点の容易想到性について
被告の乙１４の２発明に基づく進歩性欠如の主張は、相違点１４の２－６に係る構成の容易想到性の主張がないので、失当である。
また、以下のとおり、その余の相違点に係る構成も容易に想到できたとはいえない。
相違点１４の２－３ないし５について

25

乙１５発明は、相違点１４の２－３ないし５に係る構成を備えない。
この点を措くとしても、乙１４の２発明では、「Ｗｅｂブラウザの地
51

図表示画面１５２」に表示されている所定領域の部分地図が選択された場合、この選択位置に基づく転送要求により送信を受けたＨＴＭＬファ
イルを実行し、「画像データ」を固定されている「区画」に適宜当てはめることにより、スクロール処理を実現しており、「画像データ」と共
5に「区画」を移動させる構成を採用することは、全く予定していない。
また、被告は、スクロールを行う場合にデータ検索が必要であると処理に時間がかかるため、連続的なスクロール自体の実現が困難であるという乙１４の２発明の抱える問題が、乙１５発明によって解決されると主張する。しかしながら、乙１４の２発明は、端末装置にキャッシュさ10

れていない部分のＨＴＭＬファイルのみを対象として転送を受けて画像を表示する構成により、ネットワーク上でのデータ転送量の削除、効率化という課題を解決するとともに、サーバに対する「画像データ」を固定されている「区画」に適宜当てはめる構成により、スクロール処理を行うことによって、スムーズなスクロール操作を可能とした発明であり

15（段落【０１０９】、【０１１０】）、乙１４の２発明に被告が主張するような問題はない。
さらに、「デスクトップアプリケーションの地図であれば、よくある機能だ。しかし、それ以前のＷｅｂ地図サービスにドラッグはなく…」というネット記事（甲３）の記載があるように、本件特許出願時点にお20ける当業者は、Ｗｅｂブラウザに「枠要素」を設定してスクロールさせる地図を想到できなかったのであるから、Ｗｅｂブラウザとは別のアプ
リケーションを対象とする乙１５発明で相違点１４の２－３ないし５に係る構成が実現できているからといって、Ｗｅｂブラウザを対象とした
乙１４の２発明に乙１５発明を適用できたということにはならない。

25

したがって、乙１４の２発明に乙１５発明を適用して相違点１４の２－３ないし５に係る構成を想到し得たとはいえない。
52

相違点１４の２－７について相違点１４の２－７の容易想到性に関する被告の主張は、失当である。
７

争点２－３（乙２２文献を主引例とする進歩性欠如の有無）について（被告の主張）5

以下のとおり、本件各発明は、乙２２文献に記載された発明（以下「乙２２発明」という。）に基づき当業者は容易に想到し得たものであるから、進歩性を欠く。
乙２２発明の内容
ア10

乙２２文献には、以下の乙２２発明が開示されている。なお、原告らは、
乙２２Ａの構成に関し、「（ただし、該当する「地図データ」であっても表示サイズが最小表示サイズより小さいものはダウンロードされない。）」との構成を追加するが、同構成は、乙２２文献に係る特許の従属項で付加された構成にすぎないから、乙２２文献から上記構成を備えない発明を認定できることは明らかである。

15

２２Ａ

Ｗｅｂクライアントの地図を表示するディスプレイ表示範囲よりも大きい地図データを分割し該Ｗｅｂクライアントのディスプレ
イ範囲に少なくとも一部が入るメッシュ分割した地図データをサーバから優先的にダウンロードして該Ｗｅｂクライアントのディスプ
レイ表示範囲に表示する地図表示方法において、
20

２２Ｂ

Ｗｅｂクライアントのディスプレイ表示範囲に少なくとも一部が入るメッシュ分割した地図データを含む、Ｗｅｂクライアントのディスプレイ表示範囲に対し所定の位置関係にある、地図データ全体に対して限定された範囲の地図領域に含まれるメッシュ分割した
地図データを、個々に当てはめて表示するディスプレイ表示範囲に25相当する複数の領域の配列をＷｅｂクライアントに設定し、該各領域に、該当する位置のメッシュ分割した地図データをそれぞれ当て53

はめて表示しまたは表示できる状態にし、かつ、
２２Ｃ－１

Ｗｅｂクライアントのディスプレイ表示範囲に対する地図の相対移動が指示された時に、Ｗｅｂクライアントのディスプ
レイ表示範囲に対する領域の移動すべき位置を演算して該位置に領域を移動し、

5２２Ｃ－２

該地図の相対移動に伴いＷｅｂクライアントのディスプレ

イ表示範囲から離れるメッシュ分割した地図データに該当する位置から領域を削除し、Ｗｅｂクライアントのディスプレイ
表示範囲に近づくメッシュ分割した地図データに該当する位置に領域を追加して地図に対する領域の配列の位置を変更し、10該追加する領域に、該当する位置のメッシュ分割した地図デー
タを当てはめて表示しまたは表示できる状態にし２２Ｄ
イ

前記演算はＷｅｂクライアントにより実行される地図表示方法

乙２２発明の「地図（データ）」、「ディスプレイ表示範囲」、「メッ
シュ分割した地図データ」、「領域」、及び「地図表示方法」は、それぞ

15

れ本件各発明の「画像」、「表示領域」、「分割画像」、「枠要素」、「画像表示方法」に相当する。
ウ

これに対し、原告らは以下のとおり主張するが、いずれも理由がない。
原告らは、乙２２文献には、「枠要素」に相当する構成や画像を「当20てはめ」る構成の開示がないと主張する。
しかしながら、乙２２文献の【図１１】には、データ要求範囲に係る４×４の個々の区画が記載されているところ、【図８】にデータ要求範
囲に係る個々の区画が「領域」と表記されている。また、乙２２文献では、「メッシュ番号は、地図のデータの範囲を含む矩形領域を任意の矩25形サイズで分割した領域に振られる番号であり、例えば北海道の地図データを作成する場合の、メッシュ番号の採番状況を示したのが図９であ54る。」、「地図をディスプレイ上に表示する場合、ディスプレイ上の左下の表示すべき緯度・経度及び表示倍率が指定されれば、ディスプレイ
に表示する４角の緯度・経度の座標が求められる。この４角の緯度・経度の座標を地図データのマクロ座標に変換し、そのマクロ座標が含まれ5るメッシュ番号を求めると、サーバーに要求すべきメッシュ番号の範囲が求められる。」、「１データの表示領域の指定には、メッシュ・レイ
ヤーインデックスファイルで管理するこのメッシュ番号を指定する。このことにより、表示領域を直ちに指示することが可能となる。」という記載（段落【００２６】）によって、Ｗｅｂクライアントにおいてメッ

10シュ分割した地図データに付されたメッシュ番号を指定すれば、ディス
プレイ表示範囲との関係で、表示領域（「領域」）の位置とサイズが特定されるものであることが示されている。これらを踏まえると、【図１１】の示す４×４の区画は、「領域」であり、ディスプレイ表示範囲との関係で位置と大きさが特定され、Ｗｅｂクライアントに設定されてい15

るものと理解できる。

【図１１(A)】

【図８】

55

【図９】
そして、乙２２文献には、「Ｗｅｂクライアントからの地図データ要求では、図８に示すようにデータ種別（レイヤー番号）と１データの表
示領域（メッシュ番号）を指定する形式で、複数回の要求を行うことに
5

よって、必要範囲の地図データをＷｅｂサーバーから取得する。」という記載（段落【００２４】）があるところ、【図８】も参照すれば、乙２２文献の地図表示方法では、ディスプレイ表示範囲との関係で位置及びサイズが特定される各「領域」（表示領域）につき、（メッシュ番号で特定された）各メッシュ分割した地図データを要求し、これを受信し10て、各「領域」に対応づけて各メッシュ分割した地図データを表示する
ものと理解されるから、各「領域」に、各「メッシュ分割した地図デー
タ」を「当てはめ」る構成が開示されている。
また、原告らは、乙２２文献における地図表示処理では、「枠要素」
は不要であるから、「枠要素」という概念が存在する余地はないと主張

15する。
しかしながら、上記のとおり、乙２２文献には、「枠要素」に相当する構成として「領域」（表示領域）という構成が明確に開示されている。
ある構成が必要か否かの問題と、ある構成が開示されているかどうかは全く別の問題であるから、原告らの上記主張は、「枠要素」に相当する

20

構成の開示を否定する理由にならない。
56

さらに、原告らは、乙２２文献には、地図データを表示できる状態にする構成の開示はないと主張する。
しかしながら、争点２－１（被告の主張）のとおり、本件各発明は、「表示しまたは表示できる」と選択的に規定されているのであるから、
5「表示」（する）と「表示できる」のいずれかを満たせば足りるのであって、原告らの上記主張は乙２２発明の認定とは無関係である。もとより、乙２２文献の段落【００１４】、【００１５】、【００３２】の記載によれば、個々の「領域」に対応付けられた（当てはめられた）地図
データのうち、表示対象外の地図データも表示できるように保持されて10いるのであるから、乙２２発明が「地図データを…表示できる状態」にする構成を備えていることは明らかである。
原告らは、乙２２文献の地図表示方法は、枠要素に相当する構成が移動するものではないから、乙２２文献には、「移動すべき位置を演算して該位置に…移動し」との構成の開示がないと主張する。

15

しかしながら、乙２２文献の段落【００２９】や【図１１】の記載によれば、乙２２文献における「領域」は、ディスプレイ表示範囲との関係で（相対的に）移動するものである。そして、乙２２公報の段落【００２６】の記載によれば、上記の「領域」の移動が、緯度・経度等から領域の移動すべき位置を演算することにより行われていることは明らか20であるから、乙２２文献には、「移動すべき位置を演算して該位置に…
移動し」との構成が開示されている。仮に、新たな地図データ要求のため、地図データ要求範囲が再計算されるとしても、【図１１】のとおり、
メッシュ番号で特定された各「領域」がディスプレイ表示範囲との関係で移動しているのであるから、地図データ要求範囲の再計算は、上記構25

成の開示を否定するものとはいえない。
原告らは、乙２２文献は「地図データ」を「枠要素」に相当する領域
57

に「当てはめ」て表示する構成を開示するものではないから、その「削除」「追加」を観念することはできないと主張する。
しかしながら、乙２２文献に、各「領域」に各「メッシュ分割した地図データ」を「当てはめ」る構成が開示されていることは、上記のとお5りである。そして、乙２２文献では、「現在表示対象の領域以外で利用頻度の少ない領域のデータ順に、利用しなくなった地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することにより、メモリ使用の最適化を図ることができる。」（段落【００３２】）などの記載により、地図の相対移動に伴いＷｅｂクライアントのディスプレ

10

イ表示範囲から離れるメッシュ分割した地図データに該当する位置から領域のデータが削除されることが、段落【００２１】、【００２８】ないし【００３２】、【図５】、【図１１】等の記載により、ディスプレ
イの表示範囲の外側にあるメッシュ分割された地図データを先読みで要求する構成のものも含め、Ｗｅｂクライアントのディスプレイ表示範囲

15に近づくメッシュ分割した地図データに該当する位置に領域を追加して地図に対する領域の配列の位置を変更し、該追加する領域に、該当する
位置のメッシュ分割した地図データを当てはめて表示しまたは表示できる状態にすることが開示されている。

58

【図１１】
一致点及び相違点
乙２２発明と本件発明１には、以下の相違点２２－１及び２が存在し、乙２２発明と本件発明２１には上記の相違点に加えて、相違点２２－５が存在
5

するものの、その余は一致する。
（相違点２２－１）
本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙２２発明の「表示領域」は、「Ｗｅｂクライアントのディス
プレイ表示領域」とされている点

10（相違点２２－２）
本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙２２発明では、「Ｗｅｂクライアント」に設定するものとされている点
59

（相違点２２－５）
本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信される
JavaScript（登録商標）に基づき実行される」のに対し、乙２２発明では、「演算はＷｅｂクライアントにより実行される」ものの、これが「Ｗｅｂブ5ラウザで」、「JavaScript（登録商標）に基づき実行される」とは明示されていない点
相違点の容易想到性
ア

相違点２２－１
乙２２発明は、Ｗｅｂクライアントを用いた発明であるところ、Ｗｅｂ
クライアントとして、Ｗｅｂブラウザを用いることは周知慣用技術となっ10

ていたから（乙１１ないし１３）、乙２２発明に触れた当業者には、乙２２発明のＷｅｂクライアントとして、Ｗｅｂブラウザを用いる構成を採用
する強い動機付けがあった。
したがって、相違点２２－１に係る構成は容易に想到することができた。
15

イ

相違点２２－２
乙２２発明においてＷｅｂブラウザを用いる構成を採用すれば、「枠要素の配列」は、Ｗｅｂブラウザに設定されることになるから、相違点２２－２に係る構成は容易に想到することができた。

ウ

相違点２２－５
争点２－１（被告の主張）で主張した理由と同様の理由により、相違点

20

２２－５に係る構成は容易に想到することができた。
エ

仮に被告が認める相違点以外の相違があるとしても、実質的な相違点でないか、その相違に係る構成が容易想到なものにすぎない。

（原告らの主張）25

以下のとおり、本件各発明は、乙２２発明と相違し、当該相違点は容易想到ではないから、乙２２発明との関係で進歩性を有する。
60

乙２２発明の内容についてア

被告は、乙２２文献の【図８】、【図１１】を根拠に、乙２２文献には、「枠要素」に相当する「領域」がＷｅｂクライアントに設定されることが開示されていると主張する。

5

しかしながら、これらの図で示されている矩形領域は、一つの束として要求可能な「地図データ」（「道路、鉄道、行政界等」のデータ）の範囲
を示すものにすぎず（【図１１】は、指示されたディスプレイ表示範囲と「地図データ」の要求範囲の関係を説明するための概念図にすぎない。）、「枠要素」に相当する構成を開示するものではない。

10

また、被告は、乙２２文献の段落【００２４】及び【図８】を根拠に、
乙２２文献には、地図データの「当てはめ」の構成が開示されていると主張する。
しかしながら、段落【００２４】は、ＷｅｂクライアントとＷｅｂサーバの間における「地図データ」のやりとりを記載するものにすぎず、地図

15

データを表示する際の「当てはめ」とは無関係な記載にすぎない。また、【図８】は受信した「地図データ」を表示した場合に、所定の（二次元）
領域に表示されることを示すものにすぎず、設定された（二次元）領域に「地図データ」が「当てはめ」られる関係にあることなど示していない。
そもそも、乙２２文献における「地図データ」は、数値データ（ベクタ20データ）であるところ（同段落【００３４】）、単にこのベクタデータに基づいて表示を行う場合に、ビューアに設定され、「当てはめ」を行う何らかの領域の存在は必要とされない。実際、乙２２文献における地図表示
処理では、ディスプレイ上に表示する４角の緯度、経度の範囲に含まれる地図データを基に描画して表示しているにすぎないのであるから、「枠要25素」に相当する概念が必要となる余地はない。
さらに、被告は、乙２２文献には、地図データを表示できる構成の開示
61

はあると主張するが、上記のとおり、乙２２文献には、地図データを「枠要素」に「当てはめ」て表示する構成の開示はないことから、乙２２文献
は、「当てはめ」を前提とした「表示できる状態」を当然に開示するもの
ではない。
5

イ

被告は、乙２２文献の段落【００２９】及び【図１１】を根拠として、
乙２２文献には、「移動すべき位置を演算して該位置に…移動し」との構成の開示があると主張する。
しかしながら、乙２２文献の地図表示方法における表示領域の変更は、地図データの要求範囲を再度計算し、この要求に基づき送信を受けた「地図データ」をもとに表示するだけのことであり、「枠要素」に相当する構

10

成が移動するものではないから、乙２２文献に「移動すべき位置を演算して該位置に…移動し」の構成の開示はない。
ウ

被告は、乙２２文献には、「（二次元）領域」を「削除」、「追加」する構成の開示があると主張する。
しかしながら、上記アのとおり、乙２２文献は「地図データ」を「枠要15素」に相当する領域に「当てはめ」て表示する構成を開示するものではな
いから、その「削除」、「追加」を観念することはできない。
エ

したがって、乙２２文献に開示されている乙２２発明の内容は、以下のものとなる。

20

２２Ａ

Ｗｅｂクライアントの地図を表示するディスプレイ表示範囲よりも大きい地図データを分割し該Ｗｅｂクライアントのディスプレ
イ範囲に少なくとも一部が入るメッシュ分割した地図データをサーバから優先的にダウンロードして（ただし、該当する「地図データ」
であっても表示サイズが最小表示サイズより小さいものはダウンロ
25

ードされない。）該Ｗｅｂクライアントのディスプレイ表示範囲に表示する地図表示方法において、
62

２２Ｂ

Ｗｅｂクライアントのディスプレイ表示範囲に少なくとも一部が入るメッシュ分割した地図データを含む、Ｗｅｂクライアントのディスプレイ表示範囲に対し所定の位置関係にある、地図データ全体に対して限定された範囲のメッシュ分割した地図データを、ディ
5

スプレイ表示範囲に表示すべき地図の表示要求（「例えばディスプ
レイ上に表示すべき地図の左下の緯度、経度、表示すべき地図のデータ種別、表示倍率、最小表示サイズ」）に基づいて表示し、かつ、
２２Ｃ－１

Ｗｅｂクライアントのディスプレイ表示範囲に対する地図の相対移動が指示された時に、移動後の地図の位置を演算してＷｅｂクライアントのディスプレイ表示範囲に表示すべき地

10

図の表示要求に基づいて既に保持している各地図データを表
示し、
２２Ｃ－２

該地図の相対移動に伴いＷｅｂクライアントのディスプレ

イ表示範囲に近づくメッシュ分割した地図データをメモリに追加し、その追加により地図データの容量がメモリの記憶容量15を上回る場合には利用しなくなったメッシュ分割した地図データをメモリから削除し、移動後の地図の位置を演算してＷｅｂクライアントのディスプレイ表示範囲に表示すべき地図の表示要求に基づいて保持している各地図データを表示し20

２２Ｄ

前記演算はＷｅｂクライアントにより実行される地図表示方法

一致点及び相違点について
乙２２発明と本件発明１には、相違点２２－１のほか、相違点１０－２´、
３及び４と同様の相違点２２－２´、３及び４が存在し、乙２２発明と本件発明２１には、上記の相違点に加えて相違点２２－５が存在する。
25

相違点の容易想到性について
容易想到性に関する被告の主張は、乙２２発明と本件各発明の相違点を正63

しく認定することなく、誤った相違点を前提として、これらの相違点は容易に解消されると主張するものにすぎず、失当である。
そもそも、乙２２発明は、「枠要素」がなくても、所定の位置に所定の地図を各「地図データ」に基づいて表示できる構成を有しているのであるから、
乙２２発明にあえて「枠要素」に関する構成を採用する理由はない。また、

5

仮に乙２２発明に「枠要素」に関する構成を適用した場合であっても、乙２２文献では乙２２発明の画像表示方法を「Ｗｅｂブラウザ」をクライアントに備えることは全く予定されていないから、その表示領域を「Ｗｅｂブラウ
ザの表示領域」とし、また、演算を「Ｗｅｂブラウザで」、「JavaScript（登録商標）に基づき実行される」構成に変更することの動機付けはない。

10

８

争点２－４（乙２３文献を主引例とする新規性・進歩性欠如の有無）について（被告の主張）以下のとおり、本件発明１は、乙２３文献に記載された発明（以下「乙２３15発明」という。）と同一であるから新規性を欠く。また、本件発明２１は、乙２３発明に基づき当業者が容易に想到し得たものであるから、進歩性を欠く。
乙２３発明の内容
ア

乙２３文献には、以下の乙２３発明が開示されている。
２３Ａ

20

ウェブブラウザの画像を表示する表示範囲より大きい地図データ
を多数のメッシュに分割し該ウェブブラウザの表示範囲に少なくとも一部が入るメッシュに対応するファイル（各地図データが含まれる。以下同じ。）をサーバから優先的にダウンロードして該ウェブ
ブラウザの表示範囲に表示する地図表示方法において、

２３Ｂ
25

ウェブブラウザの表示範囲に少なくとも一部が入るメッシュに対応するファイルを含み、ウェブブラウザの表示範囲に表示される、
地図データ全体に対して限定された範囲の複数のメッシュに対応す64

る複数のファイルをダウンロードし、キャッシュ領域における所定の格納位置にそれぞれ格納し、キャッシュ領域における所定の各格納位置に格納された各ファイルを読み出してウェブブラウザの表示範囲における該当の領域にそれぞれ表示し、かつ、
２３Ｃ－１

5

ウェブブラウザの表示範囲に対する地図のスクロール操作がされると、地図の表示すべき範囲をウェブブラウザの地図表
示プログラムが決定し、キャッシュ領域における所定の格納位置に残っているメッシュに対応するファイルを読み出して、ウェブブラウザの表示範囲における該当の領域に表示し、表示される地図をユーザの望む方向に変化させ、

10

２３Ｃ－２

表示される地図の変化に連れて、ウェブブラウザの表示範囲から離れるメッシュに対応するファイルをキャッシュ領域における所定の格納位置から削除し、ウェブブラウザの表示範囲に近づくメッシュに対応するファイルをダウンロードし、キャッシュ領域における前記削除された格納位置に格納し、ウェブ

15

ブラウザの表示範囲における該当の領域に表示し、２３Ｄ

演算はウェブブラウザの地図表示プログラムにより実行される、

地図表示方法。
イ
20

乙２３発明の「地図データ」、「ウェブブラウザの表示範囲」及び「地図表示方法」は、それぞれ構成要件１Ａ及び１Ｄの「画像（分割画像）」、「Ｗｅｂブラウザの表示領域」、及び「画像表示方法」に相当する。
また、乙２３発明において、ダウンロードされた各地図データは「ウェブブラウザの表示範囲における該当の領域にそれぞれ表示」されるから、
この「領域」はウェブブラウザに設定されるといえる。よって、この「領25域」は、構成要件１Ｂの「Ｗｅｂブラウザに設定」されて「分割画像」を「それぞれ当てはめ」る「枠要素」に相当する。
65

さらに、乙２３発明の「地図の表示すべき範囲をウェブブラウザの地図
表示プログラムが決定」、「キャッシュ領域における所定の格納位置に残っているメッシュに対応するファイルを読み出して、ウェブブラウザの表
示範囲における該当の領域に表示」、「ウェブブラウザの表示範囲から離れるメッシュに対応するファイルをキャッシュ領域における所定の格納5位置から削除」、「ウェブブラウザの表示範囲に近づくメッシュに対応するファイルをダウンロードし、キャッシュ領域における前記削除された格
納位置に格納し、ウェブブラウザの表示範囲における該当の領域に表示」
するは、それぞれ構成要件１Ｃの「Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算」、「枠要素を移動」、「Ｗｅｂブラウザの10

表示領域から離れる分割画像に該当する位置から枠要素を削除」、「Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加
して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする」に相当する。

15

ウ

これに対し、原告らは、乙２３発明における「領域」は「枠要素」に相当する構成ではないと主張する。
しかしながら、乙２３発明における「領域」は、乙２３文献に「…地図画像を描画して、ディスプレイ画面の対応する領域に表示する（Ｓ１３）。」20という記載（段落【００５９】）があるように、ディスプレイ画面（ウェブブラウザ）に複数の「領域」が設定され、それに対応する「地図画像」
を表示するものであるから、「枠要素」に相当する構成である。
また、原告らは、乙２３発明における「領域」が「ウェブブラウザに設定されていない」ことを前提に、乙２３発明では、構成要件１Ｃの「移動」、

25「削除」、「追加」に相当する構成を観念できないと主張する。
しかしながら、上記のとおり、乙２３文献における「領域」はウェブブ
66

ラウザに設定されるものであるから、原告らの上記主張は前提を欠く。
一致点及び相違点
ア

本件発明１との一致点及び相違点
乙２３発明は本件発明１と一致し、相違点はない。

5イ

本件発明２１との一致点及び相違点
乙２３発明と本件発明２１には、以下の相違点２３－５が存在するものの、その余は一致する。
（相違点２３－５）
本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信される JavaScript（登録商標）に基づき実行される」のに対し、乙２３発明で10は、演算はウェブブラウザの地図表示プログラムが行うものの、これが「JavaScript（登録商標）に基づき実行される」とは明示されていない点
相違点の容易想到性
ア

本件発明１の容易想到性
上記

15

アのとおり、乙２３発明と本件発明１に相違点はないが、仮に相違点が存在するとしても、その相違点に係る構成は容易想到なものにすぎない。
イ

本件発明２１の容易想到性
争点２－１（被告の主張）で主張した理由と同様の理由により、相違点

20

２３－５に係る構成は容易に想到できた。
（原告らの主張）
以下のとおり、本件各発明は、乙２３発明と相違し、当該相違点は容易想到ではないから、乙２３発明との関係で新規性、進歩性を有する。
乙２３発明の内容

25

乙２３発明の内容は、被告主張のとおりであるものの、乙２３発明は「枠要素」に相当する構成や、「枠要素」の「移動」、「削除」、「追加」に相67

当する構成を備えない。
これに対し、被告は、「該当の領域」に所定の「地図データ」が表示されることを理由として、乙２３発明における「領域」が「枠要素」に相当する構成であると主張する。
5

しかしながら、乙２３文献には、地図をディスプレイ表示領域に表示するに当たり、被告が主張する「領域」をウェブブラウザに設定することや、この「領域」に「地図データ」を当てはめることの記載はない。また、乙２３
発明は、ある地図データが複数の「メッシュ」に跨る位置にある場合に所定のメッシュのみに「地図データ」も含ませる構成を備えるにもかかわらず、

10

被告は、このような領域からなる「地図データ」を当てはめることができる
領域をどのようにウェブブラウザに設定しているかについて全く明らかにしていない。そもそも、乙２３発明では、乙２２発明と同様、その表示範囲の所定の位置に所定の画像を表示するために「枠要素」は必須ではない。
また、被告は、乙２３発明は、「枠要素」の「移動」、「削除」、「追加」

15に相当する構成を備えていると主張するが、ウェブブラウザに設定されていない「領域」について、スクロール処理における移動、削除、追加を観念することはできない。
一致点と相違点について
乙２３発明と本件発明１には、相違点１０－２´、３及び４と同様の相違

20

点２３－２ないし４が存在し、乙２３発明と本件発明２１には、上記の相違点に加えて相違点２３－５が存在する。
相違点の容易想到性について
容易想到性に関する被告の主張は、乙２３発明と本件各発明の相違についての誤った理解を前提として、これらの相違点は容易に解消されると主張す

25

るものにすぎず、失当である。
そもそも、乙２３発明は、「枠要素」がなくても、所定の位置に所定の地68

図を各「地図データ」に基づいて表示できる構成を有しているのであるから、
乙２３発明にあえて「枠要素」に関する構成（相違点２３－２ないし４）を採用する理由はない。
また、乙２３文献の「地図表示プログラム」は「プラグインソフトウエアのような形で付属している」プログラムであるところ（段落【００２６】）、5

このようなプラグインソフトウエアによる演算が JavaScript により実行されることが周知慣用技術であることは明らかでないから、相違点２３－５に係る構成が容易に想到できたとはいえない。
９10

争点２－５（明確性要件違反の有無）について（被告の主張）以下のとおり、本件発明１の請求項には
発明２１の請求項には

ないし

及び

の明確性要件違反が、本件の明確性要件違反が、それぞれ認められる。

「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係（構成要件１Ｂ、１Ｃ）
15

本件発明１の請求項には「複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅ20ｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除
し」（構成要件１Ｂ、１Ｃ）と記載されているから、本件各発明では、「Ｗｅｂブラウザの表示領域」に対する「分割画像」の移動は、「分割画像」が当てはめられた「枠要素」を移動させることによって行われるものと解される。

25

しかしながら、本件発明１の請求項には「Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、…Ｗｅｂブラウザの表示領域に近づ
69く分割画像に該当する位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする」（構成要件１Ｃ）と記載され、「枠要素」に当てはめられていない「分割画像」であっても「表示領域に近づく」
5

ことがあるとされている。
したがって、本件発明１の請求項の記載では、「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係を整合的に理解することができない。
「枠要素」（構成要件１Ｂ等）

10

本件発明１の請求項には「各枠要素に、…分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし」（構成要件１Ｂ）、「枠要素に、…分割
画像を当てはめて表示しまたは表示できる状態にする」（構成要件１Ｃ－２）と記載されているから、分割画像が当てはめられた枠要素には、分割画像が表示されるものと、分割画像が表示されないが表示できる状態のものの２つ

15の種類があるものと理解される。
しかしながら、本件発明１の請求項には「分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素」（構成要件１Ｂ）と記載され、「分割画像」が当てはめられた「枠要素」は、「分割画像」の全体を必ず表示するとされている。

20

したがって、本件発明１の請求項の記載では、いくら明細書等の記載を参酌しても枠要素の意義を整合的に理解することはできない。
「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）
本件発明１では、「移動すべき位置を演算」（構成要件１Ｃ－１）することについて、Ｗｅｂブラウザでの演算に限定していないから、本件発明２１

25の「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）が何を指すのか不
明である。
70

（原告らの主張）
以下のとおり、本件各発明の請求項に被告の主張する明確性要件違反はない。
「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」の位置関係（構成要件１Ｂ、１Ｃ）について
5

本件各発明の「分割画像」とは、画像全体の一部を構成する画像であり、「枠要素」への当てはめの有無にかかわらず、「分割画像」相互の位置関係
は定まっているから、「Ｗｅｂブラウザの表示領域に近づく」、「分割画像」
は特定されている。
したがって、「Ｗｅｂブラウザの表示領域」、「分割画像」、「枠要素」

10の位置関係について、請求項の記載に第三者に不測の不利益を及ぼすほどに不明確なものはない。
「枠要素」（構成要件１Ｂ等）について「枠要素」は、構成要件１Ｂで「分割画像を、個々に当てはめて表示する…複数の枠要素」と規定されているとおり、当てはめられた「分割画像」を

15

Ｗｅｂブラウザの表示領域に表示する要素であるものの、実際の画像表示では、当てはめられた「分割画像」の全体が常に表示される関係にはないため、
構成要件１Ｂ、１Ｃ－２は、「分割画像を当てはめて表示しまたは表示できる状態に」すると規定しているのであるから、これらの記載を整合的に理解することは容易である。

20「前記Ｗｅｂブラウザでの各演算」（構成要件２１Ａ）について
本件発明１の構成要件１Ｃ－１は、「相対移動が指示された時に、Ｗｅｂ
ブラウザの表示領域に対する枠要素の移動すべき位置を演算」と規定する。
そして、本件発明１に従属する本件発明２１の構成要件２１Ａは、この順次なされる「相対移動」において、「枠要素」の移動すべき位置の「演算」を25「JavaScript（登録商標）に基づき実行される」ことを規定する。
そうすると、構成要件２１Ａの「前記Ｗｅｂブラウザでの各演算」の意義
71

に不明確な点はない。
争点２－６（サポート要件違反、実施可能要件違反及び補正要件違反の有無）について（被告の主張）5

以下のとおり、本件各発明には、サポート要件、実施可能要件及び補正要件の各違反が存在する。
「枠要素」（構成要件１Ｂ等）に関するサポート要件及び実施可能要件違反
仮に、構成要件１Ｂ等の「枠要素」にコンテナ要素以外のものが含まれ、10

例えば、img タグの style 属性の設定だけでも「枠要素」に該当するというのであれば、本件各発明では、Ｗｅｂブラウザの種類によっては画像の配置
及び移動ができないことになる。
そうすると、本件各発明は、そもそも「画像表示方法を実現する方法を提供しようとする」（本件明細書等の段落【０００６】）という本件各発明の15

課題を解決することができない構成を含み、かつ、当業者が実施することのできない構成まで含んでしまうことになる。
したがって、仮に、「枠要素」にコンテナ要素以外のものが含まれるとす
ると、本件各発明は、サポート要件及び実施可能要件に違反する。
「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要20

件１Ｃ－１）に関するサポート要件違反及び補正要件違反
仮に、平成１９年１１月１２日付け手続補正書（乙２５の４）による補正によって新たに追加された構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に、枠要素の親要素やその親要素の移動
すべき位置を演算して、枠要素の親要素やその親要素と枠要素を一体的に移25動させる構成が含まれるとすると、上記構成やその技術的意義（移動させる
画像数に関係なく演算量を一定にする。）は、本件明細書等に開示はなく、
72

願書に最初に添付した明細書、特許請求の範囲及び図面にも記載されていな
いため、本件各発明は、発明の詳細な説明に記載された発明ではないことになるし、上記補正も、願書に最初に添付した明細書、特許請求の範囲又は図面の全ての記載を総合することにより導かれる技術的事項との関係において、
5

新たな技術的事項を導入するものということになる。
また、仮に、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に、枠要素の親要素やその親要素が移動しても、枠要素が一体となって移動しない構成も含むものであるとすると、本件各発明は、当業者が、「横縦のサイズ（画素数）が大きい画像を…ビューアに表示10できるようにした画像表示方法を提供」（本件明細書等の段落【０００６】）
するという本件各発明の課題を解決できると認識できる範囲のものではないということになる。
したがって、仮に、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に、枠要素の親要素（の親要素）の移動すべ

15

き位置を演算する構成までも含まれるとすると、本件各発明は、サポート要件及び補正要件に違反する。
従前と同一の「分割画像」の「枠要素」への再度の当てはめ（構成要件１
Ｃ－２）に関するサポート要件違反
原告らの主張によれば、本件明細書等には、長い距離のスクロール操作に20

よる画像の移動において、元々のセルによってカバーされる領域内にとどまっているセルには、従前と同一の分割画像を再度当てはめる構成のみが開示されているということになる。
しかしながら、本件各発明は、「枠要素を追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当て25はめ」る（構成要件１Ｃ－２）と特定されているものの、従前と同一の「分割画像」を「枠要素」に再度当てはめることについては特定されていない。
73したがって、従前と同一の「分割画像」を「枠要素」に再度当てはめることを特定しない本件各発明の構成が、本件明細書等に記載されているとはい
えないし、このような構成によって本件各発明の課題を解決できると当業者は認識できないから、本件各発明は、サポート要件に違反する。
5（原告らの主張）
以下のとおり、本件各発明には、被告の主張するサポート要件、実施可能要件違反及び補正要件の各違反はない。
「枠要素」（構成要件１Ｂ等）に関するサポート要件違反及び実施可能要件違反について10

構成要件１Ｂ等の「枠要素」を実現するためのＨＴＭＬの記述（プログラム）それ自体は当業者が適宜採用すれば足り、本件各発明の「枠要素」の構成について、サポート要件違反及び実施可能要件違反の問題が生じる余地はない。
「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要15

件１Ｃ－１）に関するサポート要件違反及び補正要件違反について
本件明細書等には、ブロックの移動量を計算してブロックの原点の移動すべき座標を求めるための JavaScript の関数を示す【図１３】において、各セル（「枠要素」）ではなく、その親要素であるブロック（複数の「枠要素」
により構成）の位置の値を書き換えることにより、「分割画像」の移動を行

20う構成が具体的に開示されている。
したがって、本件各発明の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」との構成について、サポート要件違反及び補正要件違反はない。
従前と同一の「分割画像」の「枠要素」への再度の当てはめ（構成要件１25Ｃ－２）に関するサポート要件違反について
本件各発明は、プラグインソフトウェアを用いることなく、大きい画像の74

全てをダウンロードしなくても、スクロール操作により所望とする位置の画像をＷｅｂブラウザの表示領域に表示することを解決課題とした発明である
ところ、長い距離のスクロール操作がなされた場合に追加されるセル以外のセルについて、分割画像の再度の当てはめが行われるか否かは、上記課題の5

解決とは無関係である。
したがって、本件明細書等の実施例にあるセルの記載をもって、本件各発明にサポート要件違反があるとはいえない。
争点３（本件特許権の間接侵害の成否）について（原告らの主張）10

特許法１０１条４号の「その方法の使用にのみ用いる物」の意義
特許発明に係る方法の使用に用いる物に、当該特許発明を実施しない使用
方法自体が存在する場合であっても、当該特許発明を実施しない機能のみを使用し続けながら、当該特許発明を実施する機能は全く使用しないという使用形態が、その物の経済的、商業的又は実用的な使用形態として認められな

15

い限り、その物を製造、販売等することによって侵害行為が誘発される蓋然性が極めて高いことに変わりはないというべきであるから、当該物は、特許
法１０１条４号の「その方法の使用にのみ用いる物」に該当するというべきである。
被告地図プログラムの配信の間接侵害該当性

20

被告地図表示方法は、本件各発明の技術的範囲に属するところ、被告地図プログラムは、ドラッグ操作によりスクロール可能な地図データを提供する
ことにより、専用のソフトウェアを別途用いることなく、横縦のサイズの大きい画像をダウンロードして、少ない待ち時間でビューアに表示することを可能にする（本件明細書等の段落【０００４】ないし【０００６】）もので25あり、地図のスクロールなしの使用形態を想定していないから、特許法１０１条４号の「その方法の使用にのみ用いる物」に該当する。
75

したがって、被告による被告地図プログラムの配信につき、本件特許権の間接侵害が成立する。
（被告の主張）特許法１０１条４号の「その方法の使用にのみ用いる物」の意義
5

特許発明に係る方法の使用に用いる物について非侵害用途に使用することが、経済的、商業的、実用的な用途としてあり得ないとまでいえない限り、当該物は特許法１０１条４号の「その方法の使用にのみ用いる物」に該当しない。
被告地図プログラムの配信の間接侵害該当性

10スクロールのドラッグ操作等をすることなく店舗付近や現在地付近の地図を表示させるなど、被告地図プログラムの非侵害用途の使用が、経済的、商業的、実用的な用途としてあり得ないとはいえないから、被告地図プログラ
ムは、特許法１０１条４号の「その方法の使用にのみ用いる物」に該当しない。

15

また、被告地図プログラムには、道沿い検索や距離計測等のスクロールのドラッグ操作等が全く想定されない使用形態や、キーワード検索（乙６の６ないし８、乙１８）や宅配便の追跡（乙６の５、乙１９ないし２１）等の地図とは無関係の独立した使用形態など、本件各発明を実施する機能は全く使用しないという使用形態が、経済的、商業的又は実用的な使用形態として認20められるから、仮に、同号の「その方法の使用にのみ用いる物」の意義について原告らの主張する見解に立ったとしても、被告地図プログラムは、同号の「その方法の使用にのみ用いる物」に該当しない。
したがって、被告による被告地図プログラムの配信につき、本件特許権の間接侵害は成立しない。

25

争点４（損害額）について（原告らの主張）
76原告サピエンスは、本件特許権の設定登録日である平成１９年１２月２８日から平成２７年２月８日までの間、原告プラグインフリーは、本件特許権の取得日である同月９日から現在までの間、被告による本件特許権の侵害により、以下の損害を被った。
5ア

実施料相当額の損害（特許法１０２条３項）
本件各発明の実施料相当額の損害は、以下の方法で算定される額のうち高額のものとするのが相当である。
算定法１
被告は、被告地図プログラムの配信により、被告管理のウェブページ
で地図と共に表示される広告からの広告料や、「Yahoo! JavaScript マ

10

ップＡＰＩ」の利用料などを受け取ったことにより、平成１９年１２月２８日から平成２７年２月８日までの間に２００億円、同月９日から現在までの間に少なくとも４００億円の売上げを得たところ、本件各発明の実施に対し受けるべき料率は、売上げの１０％を下回らない。そうす
ると、原告らの損害額は、原告サピエンスにあっては２０億円（２００15

億円×１０％）、原告プラグインフリーにあっては４０億円（４００億円×１０％）である。
算定法２
被告地図プログラムの配信回数は、平成１９年１２月２８日から平成
２７年２月８日までの間に少なくとも２０億回、同月９日から現在まで

20の間に少なくとも４０億回に及ぶところ、本件各発明の実施に対し受けるべき料率は、１配信当たり１円を下回らない。そうすると、原告らの損害額は、原告サピエンスにあっては２０億円（２０億回×１円）、原
告プラグインフリーにあっては４０億円（４０億回×１円）である。
25

イ

弁護士費用相当額
原告らは、被告による本件特許権の侵害により、本訴の遂行を余儀なく
77

され、少なくとも損害賠償請求額の１０％に相当する弁護士費用相当額の損害を被った。
そこで、原告らは、被告に対し、原告サピエンスにあっては特許法１０２条３項の損害賠償金２０億円の一部６０００万円及び弁護士費用相当額６００万円の支払を、原告プラグインフリーにあっては同項の損害賠償金４０億5円の一部１億２０００万円及び弁護士費用相当額１２００万円の支払を求めるものである。
（被告の主張）争う。
10第４

当裁判所の判断

１

本件各発明の内容
本件明細書等には、次のとおりの記載があることが認められる（甲２）。
ア

発明の属する技術分野「この発明は、ビューアの表示領域よりも大きい画像をサーバからダウ

15

ンロードしてビューアに表示する方法に関する。」（段落【０００１】）
イ

従来の技術「インターネット技術の発展により、世界中からあらゆる情報をブラウザで閲覧することができるようになった。画像情報も同様にブラウザで閲覧できる。これは、Ｗｅｂサーバ上に、ＪＰＥＧファイル等の画像ファイルを表示することを記述したＨＴＭＬファイルを保存しておくことによ20

り実現される。インターネット技術を利用した新聞紙面画像の配信および閲覧も実用化されている。…」（段落【０００２】）
ウ

発明が解決しようとする課題「インターネット技術を利用して新聞紙面等の横縦のサイズ（画素数）25の大きい画像をダウンロードしてブラウザに表示するのに、従来は長い待ち時間を要していた。」（段落【０００４】）78

「また、インターネット技術を利用した新聞紙面画像の配信・閲覧は、
従来は、ブラウザから起動される専用のソフトウェア（プラグインソフト
ウェア、専用ビューア）を別途入手して実現していた。よく知られている
ＶｅｒｉＳｉｇｎ（登録商標）などの認証機関によって確認されるソフト
5

ウェアさえも、製作した会社を証明するものであって、ソフトウェア自体を保証するものではないことからソフトウェアの使用はユーザの責任になる。実際、ブラウザには新しい技術が続々と追加されるので、一般ユーザ
がブラウザの動きを理解し、自己責任でソフトウェアを選別して使用することは非常に難しい。このことから、一般ユーザはプラグインソフトウェ

10アの使用に不安を感じることが多く、セキュリティやウィルス、ハードディスクの破損などの問題からプラグインソフトウェアの使用を拒否するユーザも少なくない。」（段落【０００５】）「この発明は、上述の点に鑑みてなされたもので、横縦のサイズ（画素数）が大きい画像をダウンロードして、少ない待ち時間でビューアに表示できるようにした画像表示方法を提供しようとするものである。また、こ15の発明は、併せて、プラグインソフトウェアなしで、該画像表示方法を実現する方法を提供しようとするものである。」（段落【０００６】）エ

課題を解決するための手段「この発明の画像表示方法は、Ｗｅｂブラウザの画像を表示する表示領20

域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブ
ラウザの表示領域に表示する画像表示方法において、Ｗｅｂブラウザの表
示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像

25領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当す
る複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当す
79

る位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラウザ
5の表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加
して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にする
ものである。」（段落【０００７】）

10「この発明の画像表示方法によれば、Ｗｅｂブラウザの画像を表示する
表示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少な
くとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗ
ｅｂブラウザの表示領域に表示するようにしたので、少ない待ち時間でビューアに表示することができる。また、この発明によればＷｅｂブラウザ

15の表示領域に少なくとも一部が入る分割画像を含む、Ｗｅｂブラウザの表
示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当する複数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状

20

態にし、かつ、Ｗｅｂブラウザの表示領域に対する画像の相対移動が指示された時に、Ｗｅｂブラウザの表示領域に対する枠要素の移動すべき位置を演算して該位置に枠要素を移動し、該画像の相対移動に伴いＷｅｂブラ
ウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を25追加して画像に対する枠要素の配列の位置を変更し、該追加する枠要素に、該当する位置の分割画像を当てはめて表示しまたは表示できる状態にし80たので、画像の移動が指示されたときに、全分割画像数に比べて限られた数の枠要素を移動するように演算をすればよいので、画像全体（つまり全分割画像）を移動する場合に比べて演算量を減らすことができ、これにより画像の移動速度を速くする（つまり追従性をよくする）ことができる。」（段落【００１２】）

5オ

発明の実施の形態「この発明の実施の形態を以下説明する。この実施の形態では、プラグインソフトウェアなしで、新聞紙面画像を配信・閲覧する場合について説明する。図１にシステム構成を示す。Ｗｅｂサーバ（サーバコンピュータ）

10１０とＷｅｂブラウザ（クライアントコンピュータ、ビューア）１２とは、インターネット等の通信ネットワーク１４を介して接続されている。Ｗｅ
ｂサーバ１０には、新聞紙面の画像データベースが予め格納されて用意されている。この画像データベースは、新聞１ページ全体を１つの画像とするもので、新聞を構成する各ページの画像を様々な倍率｛長さ比で例えば、

15

２５％、３３％、５０％、６７％（以上、実際の新聞紙面の縮小画像）、
１００％（実際の新聞紙面と等倍画像）、１３３％、２００％、４００％（以上、実際の新聞紙面の拡大画像）｝で（すなわち、同一ページの画像
を複数の倍率で）保存している。各分割画像のファイル形式は同一である
必要はなく、例えば分割画像ごとの特徴（写真か文字か、カラーか白黒か20等）に応じて圧縮率が高いファイル形式（ＪＰＥＧ形式、ＰＮＧ形式、Ｇ
ＩＦ形式等）で保存する。したがって、新聞１ページの画像は、異なるフ
ァイル形式の分割画像が混在して構成される場合がある。このように、分割画像ごとに圧縮率が高いファイル形式を用いることにより送信時間を短縮できる。」（段落【００２０】）

81

【図１】
「１つの倍率の１ページの画像は、図２に示すように、左上位置（画像の原点位置）から横方向（Ｘ軸方向）および縦方向（Ｙ軸方向）にそれぞれ所定画素数ごとに格子状に分割されて、複数の矩形の分割画像の集合で5構成されている。１つの分割画像を構成する画素数は、倍率の違いにかかわらず一定であり、例えば４８０×４８０ピクセルである（ただし、１ページ横方向全体の画素数が１つの分割画像について定められた横方向の画素数で割り切れない場合は、右端位置の分割画像の画素数は端数となる。
同様に、１ページ縦方向全体の画素数が１つの分割画像について定められ10た縦方向の画素数で割り切れない場合は、下端位置の分割画像の画素数は端数となる。）。これに対し、１ページ分の紙面を構成する画素数は、倍率に応じて変化する｛倍率（＝長さ比）の二乗に比例する｝ので、１ページ分の紙面を構成する分割画像数は、倍率が低い画像ほど少なく、倍率が高い画像ほど多くなる。各分割画像には、１ページの画像における各分割

15

画像の位置（番地）を示す座標値（分割画像座標値）として、図２に示す
82

ように、横方向の座標をｘ、縦方向の座標をｙとし、左上角の分割画像位
置を原点［０，０］とし、右に行くに従い、また下に行くに従い１ずつ増加する分割画像座標値［ｘ，ｙ］に相当するファイル名がそれぞれ付与さ
れて保存されている。１ページの画像における右端の分割画像の横方向の5

座標値をｘｌ、下端の分割画像の縦方向の座標値をｙ ｌ とすると、右下角の最後の分割画像の座標値は［ｘ ｌ ，ｙｌ ］となる。特定の新聞の、特定のページの、特定の倍率の、特定の分割画像は、新聞名、日付、朝／夕刊別、
ページ番号、倍率、分割画像座標値［ｘ，ｙ］の各情報を組み合わせた識別情報で特定（指定）される。新聞紙面を閲覧する場合は、Ｗｅｂブラウ

10

ザ１２から、閲覧者により指示される閲覧位置に応じた該識別情報が送信され、Ｗｅｂサーバ１０は該識別情報を解析して、該当する分割画像を送信し、Ｗｅｂブラウザ１２は該分割画像を受け取って、元の画像の並びに配列して表示する。上記のような識別情報を用いれば、Ｗｅｂサーバ１０から最初にＷｅｂブラウザ１２に送信するＨＴＭＬ（後述する図３のステ

15

ップＳ２）に、分割画像ごとのファイル名｛ファイル形式を指定する識別子(.jpg、.png、.gif 等）が付加されたデータ｝を組み込んでおく必要がな
い（すなわち、Ｗｅｂブラウザ１２はファイル名やそのファイル形式を予め知らなくても、個々の分割画像を要求できる。）ので、該ＨＴＭＬのデータ量は少なくて済む。」（段落【００２１】）

20

【図２】
83

「この実施例では、後述するように（図６）、画像上にブラウザの表示
領域全体が入る大きさの『ブロック』を設定する。このブロックは、例えば６×６個の『セル』（枠要素）で構成される。１つのセルは１つの分割
画像の大きさ（例えば４８０×４８０ピクセル）に相当し、該当する位置
5の分割画像が当てはめ（割り当て）られる。ブロックは、画像が移動（スクロール）しても常にブラウザの表示領域全体が入るように、ブラウザの表示領域に対する画像の移動に応じて、ブラウザの表示領域に対してセル
単位で移動し、これに伴い、セルに当てはめられる分割画像も順次入れ替えられる。」（段落【００２２】）

10「新聞紙面を閲覧する場合のＷｅｂブラウザ１２とＷｅｂサーバ１０との間の通信のやり取りを図３に示す。閲覧者がＷｅｂブラウザ１２からＷ
ｅｂサーバ１０に○月○日付の○○新聞の○刊（朝刊または夕刊）を閲覧する旨の指示をすると、該当する内容のＨＴＭＬを要求する指示が出される（Ｓ１）。Ｗｅｂサーバ１０はこの要求を受けて、図４に示す、分割画15

像データを当てはめる６×６個のセルを設定する＜ＤＩＶ＞タグ、および、
どの分割画像をどのセルに当てはめてブラウザ上のどの位置に表示するかを算出するための JavaScript を含んだＨＴＭＬをＷｅｂブラウザに返す（Ｓ２）。なお、６×６個のセルには、図４に示すように、「canvas００００」～「canvas０５０５」の名前が付けられている。「canvas」に続

20

く４桁の数字のうち、最初の２桁はブロック内でのセルのＸ軸方向の番地（００～０５）を示し、それに続く残りの２桁はブロック内でのセルのＹ
軸方向の番地（００～０５）を示す。」（段落【００２３】）

84

【図３】

【図４】
「Ｗｅｂブラウザ１２は、ＨＴＭＬを受け取ると、該ＨＴＭＬに記述されている JavaScript に基づき、各セルにどの分割画像を当てはめるかお
5

よび各セルに当てはめられた分割画像をブラウザ１２上のどの位置に表示するかを算出する。そして、算出された分割画像がＷｅｂブラウザ１２に既にダウンロードされてキャッシュメモリに保存されている分割画像
であるかどうかを判断し、既に保存されている分割画像については、それを読み出して該当するセルに当てはめる。また、Ｗｅｂブラウザ１２に保10存されていない分割画像については、Ｗｅｂサーバ１０に対し該当する分
85

割画像を要求する（Ｓ３）。Ｗｅｂサーバ１０は該要求に応じて、該当する分割画像データを送信する（Ｓ４）。Ｗｅｂブラウザ１２は該分割画像
データを受け取り、該当するセルに当てはめる。このようにして、６×６個のセルに分割画像がそれぞれ当てはめられて（関連づけられて）、前記
5算出された位置にそれぞれ表示される（Ｓ５）。これにより、Ｗｅｂブラ
ウザ１２の表示領域全体に、分割画像がつなぎ目なく表示されて、新聞紙面の画像が表示される。表示の一例を図５に示す（図５においてセルの境
界線は仮想的に示したもので、実際の画面では表示されない。）。なお、
閲覧開始当初は初期画面として、Ｗｅｂブラウザ１２から閲覧の指示をし10

た新聞の第１ページの所定倍率（紙面の記事全体が見渡せるように比較的低い倍率）の分割画像をＷｅｂブラウザ１２がＷｅｂサーバ１０に要求して表示するように、Ｗｅｂサーバ１０から送信するＨＴＭＬが記述されている。」（段落【００２４】）

【図５】
15

「初期表示制御
ブロックを構成する各セルに当てはめる分割画像について説明する。ここでは、図６に示すように、ブラウザの表示領域１６よりも大きい画像１
86

８（新聞紙面１ページ分の画像）を、ブラウザの表示領域１６の中心と画像１８の中心を一致させた状態に初期表示するものとする。また、ブロッ
ク２０を６×６個のセル２２で構成し、ブロック２０の左側および上側を１セルずつ空けて（つまり、ブラウザの表示領域１６の左上角が、ブロッ
5

ク２０の左から２番目、上から２番目のセルに位置するように）表示するものとする。なお、以下の説明において、座標値あるいは番号（番地）はその種類に応じて次のように区別して表記する。

10

（

，

）：ピクセル座標値（ピクセル単位の座標値）［，］：分割画像座標値（画像全体における分割画像ごとの座標値）〔，〕：セル番号（ブロックにおけるセルごとの番号値）

ピクセル座標値は、ブラウザの原点（左上角）を原点（０，０）とし、Ｘ
軸方向の極性は右方向を＋、左方向を－とし、Ｙ軸方向の極性は下方向を＋、上方向を－とする。」（段落【００２５】）

87

【図６】
「図６において、各変数は次を意味する。
Ｘｉ：画像（新聞紙面１ページ）全体の幅（ピクセル値）
Ｙｉ：画像（新聞紙面１ページ）全体の高さ（ピクセル値）
5

Ｘｂ：ブラウザの幅（ピクセル値）
Ｙｂ：ブラウザの高さ（ピクセル値）

10

Ｘ１＝Ｘｉ／２：画像幅の半値…（式１）Ｙ１＝Ｙｉ／２：画像高さの半値…（式２）

Ｘ２＝Ｘｂ／２：ブラウザ幅の半値…（式３）

Ｙ２＝Ｙｂ／２：ブラウザ高さの半値…（式４）」（段落【００２６】）「図６において、ブラウザの原点（左上角）を原点（０，０）とすると、画像の原点の座標値（Ｘ０，Ｙ０）は次式によって与えられる。
88

Ｘ０＝Ｘ２－Ｘ１：画像のＸ軸原点…（式５）

Ｙ０＝Ｙ２－Ｙ１：画像のＹ軸原点…（式６）１つの分割画像の大きさ（＝１つのセルの大きさ）を４８０×４８０ピク
セルとすると、画像全体の分割画像数は次式によって与えられる。
5

Ｇｘｉ＝Ｘｉ／４８０：Ｘ軸方向の全分割画像数…（式７）

Ｇｙｉ＝Ｙｉ／４８０：Ｙ軸方向の全分割画像数…（式８）

このＧｘｉ、Ｇｙｉ が小数点以下の桁を有する場合は、小数点以下を切り上げた整数値が実際のＸ軸方向およびＹ軸方向の全分割画像数である。また、Ｇ ｘｉ の小数点以下を切り捨てた値が右端の分割画像の横方向の座標値ｘ ｌ10（図２）であり、Ｇ ｙｉ の小数点以下を切り捨てた値が下端の分割画像の縦方向の座標値ｙｌ（同）である。」（段落【００２８】）「一方、ブラウザの表示領域１６に必要な分割画像数は次式によって与
えられる。

15

Ｇｘｂ＝Ｘｂ／４８０：Ｘ軸方向の表示に必要な分割画像数…（式９）

Ｇｙｂ＝Ｙｂ／４８０：Ｙ軸方向の表示に必要な分割画像数…（式１０）

ブラウザの表示領域１６に入る最初の分割画像｛ブラウザの原点（０，０）
が属する（位置する）分割画像｝の座標［ｘ ｆ，ｙｆ］は、次式によって与えられる。
ｘｆ＝－｛（Ｘ０／４８０）の商の小数点以下を切り捨てた値｝
20

…（式１

１）
ｙｆ＝－｛（Ｙ０／４８０）の商の小数点以下を切り捨てた値｝…（式１２）」（段落【００２９】）「ブロックの左端に配置されるセル（Ｘ軸方向のセル番号をＳ ｘｆ とする。
以下「Ｘ軸最初セル」という。）には、Ｘ軸方向の分割画像座標値がｘ ｆ－
25１の分割画像を当てはめる。同様に、ブロックの上端に配置されるセル（Ｙ
軸方向のセル番号をＳ ｙｆとする。以下「Ｙ軸最初セル」という。）には、
89

Ｙ軸方向の分割画像座標値がｙ ｆ－１の分割画像を当てはめる。すなわち、
Ｓｘｆ＝ｘｆ－１…（式１３）

Ｓｙｆ＝ｙｆ－１…（式１４）とする。これによれば、ブロックの最初のセル〔Ｓ ｘｆ ，Ｓｙｆ 〕（ブロック5の左上角に配置されるセル。以下「最初セル」という。）には、［ｘｆ－１，
ｙｆ－１］の分割画像が当てはめられる。－１を付加するのは、Ｓ ｘｆ＝ｘｆ、
Ｓｙｆ＝ｙｆに設定すると、図７（ａ）に示すように、ブロック２０の左端部分および上端部分がブラウザの表示領域１６の左端部分および上端部分に接近して配置されることになり、画像を右下方向に移動（スクロール）

10させた際に、新たに左側および上側からブラウザの表示領域１６に入るべき分割画像がＷｅｂサーバから新たに転送されて来るまでの待ち時間に、
ブラウザの表示領域１６の左端部分および上端部分に空白部分（画像が表示されない部分）が生じ易くなるためである。これに対し、－１を付加す
ると、図７（ｂ）に示すように、ブロック２０は予めブラウザの表示領域15１６に対して１セル分以上左方向および上方向にオフセットして配置されることになり、画像を右下方向に移動させた際に、ブラウザの表示領域
１６の左端部分および上端部分に空白部分を生じにくくさせることができる。」（段落【００３０】）

90

【図７】
「ブロックを構成するその他のセルに当てはめる分割画像の座標は、最初セル〔Ｓｘｆ，Ｓ ｙｆ〕に当てはめる分割画像の座標［ｘ ｆ－１，ｙ ｆ－１］に、Ｘ軸方向並びにＹ軸方向に１ずつ順次足していくことにより求められ5る。すなわち、最初セル〔Ｓ ｘｆ，Ｓｙｆ〕を０番目のセルとして、Ｘ軸方向にｍ番目（ｍ＝０、１、…、５）、Ｙ軸方向にｎ番目（ｎ＝０、１、…、
５）のセル〔Ｓｘｍ，Ｓｙｎ〕に当てはめられる分割画像座標値は、

10

Ｓｘｍ＝Ｓｘｆ＋ｍ＝ｘｆ－１＋ｍ…（式１５）

Ｓｙｎ＝Ｓｙｆ＋ｎ＝ｙｆ－１＋ｎ…（式１６）

で与えられる。したがって、ブロックの最後のセル〔Ｓ ｘｌ ，Ｓ ｙｌ〕（ブロックの右下角に配置されるセル。以下「最後セル」という。なお、ブロッ
クの右端に配置されるセルをそれぞれ「Ｘ軸最後セル」、ブロックの下端に配置されるセルをそれぞれ「Ｙ軸最後セル」という。）に当てはめる分91割画像の座標は、
Ｓｘｌ＝Ｓｘｆ＋５＝ｘｆ＋４…（式１７）

Ｓｙｌ＝Ｓｙｆ＋５＝ｙｆ＋４…（式１８）となる。以上のようにして、ブロック２０を構成する６×６個のセル２２5に当てはめるべき分割画像が求められる。」（段落【００３１】）「次に、ブロック２０を構成する６×６個のセル２２のブラウザ上における表示位置について説明する。各セルのブラウザ上における表示位置は、該各セルの原点（左上角の位置）の座標値（ピクセル値）で特定（指定）される。各セルの原点の座標値は以下のようにして求められる。まず、最10初セル〔Ｓｘｆ，Ｓｙｆ〕の原点（Xｂ０，Ｙｂ０）は、ブロックの原点に相当し（図６参照）、
Xｂ０＝Ｘ０＋（Ｓｘｆ×４８０）…（式１９）

Ｙｂ０＝Ｙ０＋（Ｓｙｆ×４８０）…（式２０）

で与えられる。ブロックを構成するその他のセルの原点は、このようにし15て求められた最初セル〔Ｓｘｆ，Ｓｙｆ〕の原点（Xｂ０，Ｙｂ０）にＸ軸方向並びにＹ軸方向に４８０ずつ順次足していくことにより求められる。すなわち、最初セル〔Ｓｘｆ，Ｓｙｆ〕を０番目のセルとして、Ｘ軸方向にｍ番目（ｍ＝０、１、…、５）、Ｙ軸方向にｎ番目（ｎ＝０、１、…、５）のセル〔Ｓｘｍ

20，Ｓｙｎ〕の原点（Xｂｍ，Ｙｂｎ）は、

Xｂｍ＝Xｂ０＋（ｍ×４８０）
Ｙｂｎ＝Ｙｂ０＋（ｎ×４８０）…（式２１）…（式２２）

で与えられる。」（段落【００３２】）「Ｗｅｂサーバから送信されるＨＴＭＬ（図３のステップＳ２）には、以上の（式１）～（式２２）に相当する演算を実行する JavaScript が記述
25されており、Ｗｅｂブラウザは、該ＨＴＭＬを受け取ると、該 JavaScriptに基づき、ブロックを構成する６×６個のセルに当てはめる分割画像座標92

値と、各セルのブラウザ上における表示位置（各セルの原点位置を表示するピクセル座標位置）を算出する。そして、Ｗｅｂブラウザは、算出された分割画像座標値を識別情報としてＷｅｂサーバに該当する分割画像を要求する（Ｗｅｂサーバから既にダウンロードされてキャッシュメモリに5保存されている分割画像についてはそれを使用する。）（図３のステップ
Ｓ３）。Ｗｅｂサーバ１０は該要求に応じて、該当する分割画像データを送信し（同Ｓ４）、Ｗｅｂブラウザ１２は該分割画像データを受け取り、
該当するセルに当てはめて、それぞれ前記求められた位置に表示する（同Ｓ５）（図６、図７、図９、図１１等から明らかなように、セルに当ては10

められてもブラウザの表示領域から外れている分割画像はその時点では表示されないが、スクロール操作によりブラウザの表示領域に入ってくれば表示できる状態になっている）。」（段落【００３３】）「ここで、ブロック２０を構成する各セル２２のセル番号の付与方法について説明する。このセル番号の付与もＷｅｂサーバから送信されるＨＴ

15

ＭＬに記述されている JavaScript に基づき実行される。各セルのセル番号〔Ｓｘ，Ｓｙ〕は、該各セルに当てはめられる分割画像の座標［ｘ，ｙ］
を、Ｘ軸方向についてはブロックを構成するＸ軸方向の総セル数、Ｙ軸方向についてはブロックを構成するＹ軸方向の総セル数でそれぞれ割った余りの値として付与する。これによれば、各分割画像が当てはめられるセ20

ルのセル番号（各分割画像に割り当てられるセル番号）は、分割画像ごとに一意的に定まる。この実施例では、Ｘ軸方向、Ｙ軸方向の総セル数はそれぞれ６であるから、セル番号は、Ｘ軸方向、Ｙ軸方向ともに０、１、２、…、５の繰り返しとなる。この場合、各分割画像が当てはめられるセルのセル番号を図９に示す。図９の各分割画像位置に記述されている数値のう25

ち、上段は各分割画像２４の座標値を示し、下段は当てはめられるセルのセル番号を示す。セル番号が繰り返し使われても、ブロック内のセル数は93

６×６個だけであるから、ブロック内で同時に同じセル番号が重複して使用されることはない。このようにセル番号を繰り返し用いることにより、図４に示すように、ＨＴＭＬに記述する、セルを設定するための＜ＤＩＶ＞タグは６×６個だけ用意すれば足りることになる。」（段落【００３８】）5【図９】「以上のようにして、Ｗｅｂサーバから送信されるＨＴＭＬに記述されている JavaScript に基づき、ブロック２０を構成する６×６個のセル２２に当てはめる各分割画像２４の座標値と該各セル２２のセル番号およ94

び該各セル２２のブラウザ上における表示位置（各セルの原点位置を表示
するピクセル座標位置）が求められたら、Ｗｅｂサーバに対し該当する分
割画像２４の送信を要求し（図３のステップＳ３）、Ｗｅｂサーバから該要求に応じた分割画像データが送られてきたら（同Ｓ４）、該当するセル
5

番号に当てはめてブラウザに表示する（同Ｓ５）。これにより、Ｗｅｂブ
ラウザ１２の表示領域全体に、分割画像２４がつなぎ目なく表示されて、新聞紙面の画像１８が表示される。」（段落【００３９】）「図１０は、ブロック２０を構成する各セル２２に当てはめる各分割画
像２４の座標値と、該各セル２２に付与するセル番号と、該各セル２２の

10

ブラウザ上における表示位置（各セルの原点位置）の関係を求め、該当する分割画像をＷｅｂサーバに要求し、該要求に応じてＷｅｂサーバから送られてきた分割画像２４を各セル２２に当てはめるための JavaScript の関数（抜粋）を示す。この JavaScript の関数は、画像の左上角の分割画像［０，０］を始点として、分割画像位置をＹ軸方向に走査してブロックに15含まれる分割画像の有無を判断し、ブロックに含まれる分割画像があった
場合は、該分割画像が当てはめられるセルに、該分割画像の X 軸方向の座
標値ｘを６で割った余りをＸ軸方向のセル番号 sellX として付与し、該分割画像のＹ軸方向の座標値ｙを６で割った余りをＹ軸方向のセル番号 sellY として付与する。そして、「document.all("canvas" + sellX +sellY).

20

innerHTML = "<IMG ID='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 の関数は、「canvas sellX sell

25

Y」
（sellX＝００～０５、sellY＝００～０５）のＩＤを持つＤＩＶタグ（図４参照）を、このセルに当てはめる分割画像の座標値「image x y」のＩＤ
95

を持つＩＭＧタグに変換し、該ＩＭＧタグのソースとして「image.cgi」（Ｗ
ｅｂサーバ側の画像データ検索および転送モジュール）からの分割画像データを埋め込むことを意味する。そのとき「a=xxx&b=xxx&c=xxx&d=xxx&e=
xxx&f=xxx&g=xxx」は、Ｗｅｂサーバに保存されている画像を特定するため
5のパラメータ（新聞名、日付、朝／夕刊別、ページ番号、倍率等の情報）として、特定の画像ファイルを検索するための値となる。「STYLE='left:" +originX +";top:" + originY 」はこのセル（分割画像）の原点（左上の位置）を表示するブラウザの表示領域上の座標位置（ピクセル値）を示す。」（段落【００４０】）96

【図１０】「以上の処理をその列のＹ軸方向の最後の分割画像まで行ったら、その１つ右隣の列に移って同様に上端からブロックに含まれる分割画像の有無を判断し、ブロックに含まれる分割画像が当てはめられるセルに、Ｘ軸
5方向のセル番号 sellX およびＹ軸方向のセル番号 sellY を付与する。そして、Ｘ軸方向の最後の列の最後の分割画像まで達したら、処理を終了する。」（段落【００４１】）「スクロール制御
次に、以上のようにして初期表示がなされた後に、閲覧者のスクロール操
97

作によりブラウザの表示画面上で画像を任意の位置に移動させる（つまり、閲覧位置を移動する）方法について説明する。図１１は、スクロール操作
による画像の移動動作を示す。図１１では、画像１８をＸ軸方向の右方向にＸｄ（ピクセル値）、Ｙ軸方向の下方向にＹ ｄ（ピクセル値）移動させた
5

場合（移動後の画像位置を符号１８’で示す。）を示す。ブロック２０は
画像１８と一体に移動するが、この移動によってブロック２０はブラウザの表示領域１６に対し相対移動し、何も手当をしなければ、ブロック２０
はいずれブラウザの表示領域１６から外れてしまう。そこで、移動量に応じて画像１８に対するブロック２０の位置を変更し、これに伴い該ブロッ

10

ク２０を構成する各セル２２に対する分割画像の当てはめを更新する制御（ブロックの再設定）を併せて行う。このブロックの再設定により、ブロック２０は常にブラウザの表示領域１６全体を含む（ブラウザの表示領
域１６全体が常にブロック２０内に含まれる）ように制御される。図１１の例では、スクロール操作によりブロック２０がブラウザの表示領域１６15に対し相対的に右方向に移動して、セルの境界線が１本ブラウザの原点を越えているので、ブロックの再設定により、右端の１列のセルが削除され、その分左端に１列のセルが追加されている。それらの間の５列のセルには変更はない。」（段落【００４２】）98【図１１】「スクロール操作時の制御フローを図１２に示す。図１２の制御は、Ｗ
ｅｂサーバから送信されるＨＴＭＬに記述されている JavaScript によって行われる。スクロール操作時の制御は、画像を移動させる制御と、ブロ
5ックの再設定制御で構成される。はじめに、画像の移動制御について説明する。新聞紙面の画像が表示されている画面上の任意の位置にマウスカー
ソル（ポインタ）を当ててマウス左ボタンを押下し（マウスダウン操作）（図１２のステップＳ１１）、押下したままマウスカーソルを移動させると（ドラッグ操作）、マウスカーソルに追従して画像が移動する（同Ｓ１10２）。この場合、セル単位で移動量の演算をすると、演算処理に時間がか99

かり、移動動作が遅くなる。そこで、図４のＨＴＭＬのように、６×６個のセルを設定する＜ＤＩＶ＞タグ全体を、名前が canvas BLOCK である＜ＤＩＶ＞タグで１つのブロックとして束ねて、該１つのブロックについて
移動量を演算して該ブロックの移動後の原点を求め、該求められたブロッ5クの原点の座標に基づき、該ブロックを構成する各セルの原点の座標を演算して求める。これによれば、ブロックの原点に対する各セルの原点の相対位置は予め定まっており、簡単な演算で求めることができ、一方複雑な演算を要する移動量の演算は１つのブロックについてのみ行えばよいので、セル単位で（セルごとに）移動量の演算をする場合に比べて全体とし10て演算量が少なくて済み、移動動作を高速化することができる。」（段落【００４３】）【図１２】「図１３は、ブロック（画像）の移動量（＝マウスカーソルの移動量）
100

を計算してブロックの原点の移動すべき座標を求めるための JavaScriptの関数を示す。この関数によりブロックの原点の移動すべき座標が求められたら、この座標がブロックの最初セル〔Ｓ ｘｆ ，Ｓｙｆ〕の原点の座標になるので、他のセルについても X 軸方向およびＹ軸方向にそれぞれ４８０ず
5

つ順次足していくことによりそれぞれの原点の座標を求める。このような演算をマウスカーソルが移動されている間中繰り返すことにより、マウス
カーソルに追従して画像を移動させることができる。マウスカーソルを任意の位置に移動後、マウスボタンを離す（マウスアップ操作をする）と、画像はその位置で停止する。」（段落【００４４】）

10

【図１３】
「次に、ブロックの再設定制御について説明する。ドラッグ操作を終了
して、マウスアップ操作をすると、移動後の画像上でブラウザの原点（０，０）が属するセル位置（分割画像位置）が判断され、ドラッグ前の位置に対して変化しているかどうか｛つまり、ブラウザの原点（０，０）がセル
101

の境界を超えたかどうか｝が判断される（図１２のステップＳ１３）。そして、変化している場合（セルの境界を越えた場合）は、その変化した分（セルの境界を越えた本数分）ブロック位置を画像の移動と同じ方向に移動させるとともに、該ブロックを構成する各セルに対する分割画像の当て
5

はめを更新することによりブロックの再設定を行う（同Ｓ１４）。」（段
落【００４５】）「ブロックの再設定制御は次の演算により実現される。ドラッグ操作による画像の移動量を図１１のようにＸ軸方向の右方向にＸｄ、Ｙ軸方向の下方向にＹｄとすると｛画像の移動量Ｘ ｄ、Ｙｄ は、ドラッグ終了位置（マウス10アップ操作位置）でのマウスカーソル座標値からドラッグ開始位置（マウスダウン操作位置）でのマウスカーソル座標値を引算することにより得られる。｝、移動後の画像の原点の座標値（Ｘ ｄ０ ，Ｙｄ０）は、次式によって与えられる。

15

Ｘｄ０＝Ｘｆ０＋Ｘｄ：移動後の画像のＸ軸原点…（式２３）

Ｙｄ０＝Ｙｆ０＋Ｙｄ：移動後の画像のＹ軸原点…（式２４）

ただし、Ｘｆ０：前回のスクロール操作による画像の最終的なＸ軸原点。初回のスクロール操作であれば、Ｘ ｆ０＝Ｘ０ （初期表示時の画像のＸ軸原点）である。
Ｙｆ０：前回のスクロール操作による画像の最終的なＹ軸原点。初回のスク20

ロール操作であれば、Ｙｆ０＝Ｙ０（初期表示時の画像のＹ軸原点）である。」（段落【００４６】）「また、移動後にブラウザの表示領域に入る最初の分割画像｛ブラウザの原点（０，０）が属する分割画像｝の座標［ｘ ｄｆ，ｙｄｆ］は、次式によって与えられる。

25

ｘｄｆ＝－｛（Ｘｄ０／４８０）の商の小数点以下を切り捨てた値｝
２５）
102

…（式

ｙｄｆ＝－｛（Ｙｄ０／４８０）の商の小数点以下を切り捨てた値｝

…（式

２６）
したがって、ドラッグによってセルの境界がブラウザの原点（０，０）を越えた数Ｓｘｄ、Ｓｙｄは、次式によって与えられる。
5

Ｓｘｄ＝ｘｆ０－ｘｄｆ…（式２７）

Ｓｙｄ＝ｙｆ０－ｙｄｆ…（式２８）

ただし、ｘｆ０：前回のブロックの再設定時のブラウザの表示領域に入る最初の分割画像の X 軸座標
ｙｆ０：前回のブロックの再設定時のブラウザの表示領域に入る最初の分割
10

画像のＹ軸座標」（段落【００４７】）「（式２７）によって求められるＳ ｘｄが０であれば、セルの境界はブラウザの原点（０，０）を X 軸方向に越えてないことがわかり、＋の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を右方向に越えたことがわかり、－の値であれば、その本数分のセルの境界がブラウザ

15の原点（０，０）を左方向に越えたことがわかる。また、（式２８）によって求められるＳｙｄが０であれば、セルの境界はブラウザの原点（０，０）
をＹ軸方向に越えてないことがわかり、＋の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を下方向に越えたことがわかり、－の値であれば、その本数分のセルの境界がブラウザの原点（０，０）を上20

方向に越えたことがわかる。」（段落【００４８】）「（式２７）、（式２８）の演算の結果、Ｓ ｘｄ 、Ｓｙｄがいずれも０の場
合は、ブラウザの原点（０，０）が属する分割画像の位置はドラッグの前後で変化がないことになるから、ブロックの再設定は行われない。これに対し、（式２７）、（式２８）の演算の結果、Ｓ ｘｄ、Ｓｙｄのうち少なくとも

25

一方が０以外の場合は、ブラウザの原点（０，０）が属する分割画像の位
置がドラッグの前後で変化したことになるから、ブロックの再設定が行わ103

れる。」（段落【００４９】）「ブロックの再設定は、Ｓ ｘｄ、Ｓｙｄに相当するセル数分、ブロック全体
を、画像に対し、画像の移動方向と逆方向に相対的に移動させることで実現される。このブロックの再設定によって、該ブロックを構成する各セル
5には次のように分割画像が当てはめられる。ブロックの左端に配置される
セル（Ｘ軸最初セル）Ｓｘｄｆには、Ｘ軸方向の分割画像座標値がｘ ｄｆ－１の分割画像が当てはめられる。同様に、ブロックの上端に配置されるセル（Ｙ軸最初セル）には、Ｙ軸方向の分割画像座標値がｙ ｄｆ －１の分割画像が当てはめられる。すなわち、

10

Ｓｘｄｆ＝ｘｄｆ－１…（式２９）

Ｓｙｄｆ＝ｙｄｆ－１…（式３０）とする。これによれば、再設定後のブロックの左上角に配置されるセル（最初セル）〔Ｓｘｄｆ，Ｓｙｄｆ〕には、［ｘｄｆ－１，ｙｄｆ－１］の分割画像が当てはめられる。－１を付加するのは、（式１３）、（式１４）で－１を付加15したのと同じ目的である。すなわち、ブロックをブラウザの表示領域に対して１セル分以上左方向および上方向にオフセットして配置することにより、画像を右下方向に移動させた際に、ブラウザの表示領域の左端部分
および上端部分に空白部分を生じにくくする。」（段落【００５０】）「ブロックを構成するその他のセルに当てはめる分割画像の座標は、最20

初セル〔Ｓｘｄｆ ，Ｓｙｄｆ〕に当てはめる分割画像の座標［ｘ ｄｆ－１，ｙｄｆ－１］に、Ｘ軸方向並びにＹ軸方向に１ずつ順次足していくことにより求められる。すなわち、最初セル〔Ｓｘｄｆ，Ｓｙｄｆ〕を０番目のセルとして、Ｘ軸方向にｍ番目（ｍ＝０、１、…、５）、Ｙ軸方向にｎ番目（ｎ＝０、１、…、
５）のセル〔Ｓｘｄｍ，Ｓｙｄｎ〕に当てはめられる分割画像座標値は、

25

Ｓｘｄｍ＝Ｓｘｄｆ＋ｍ＝ｘｄｆ－１＋ｍ…（式３１）

Ｓｙｄｎ＝Ｓｙｄｆ＋ｎ＝ｙｄｆ－１＋ｎ…（式３２）

104

で与えられる。したがって、ブロックの右下角に配置されるセル（最後セル）〔Ｓｘｄｌ，Ｓｙｄｌ〕に当てはめる分割画像の座標は、

5

Ｓｘｄｌ＝Ｓｘｄｆ＋５＝ｘｆ＋４…（式３３）

Ｓｙｄｌ＝Ｓｙｄｆ＋５＝ｙｆ＋４…（式３４）となる。」（段落【００５１】）「以上のようにして、再設定されたブロックを構成する６×６個のセルに当てはめるべき分割画像が求められる。６×６個のセルに当てはめるべ
き分割画像が求められたら、新たにブロックの領域に入ってきた分割画像
について、未取得の場合はＷｅｂサーバに要求し、Ｗｅｂサーバから既に10

ダウンロードされてキャッシュメモリに保存されている分割画像についてはそれを読み出して、それぞれ該当するセルに当てはめて表示する（図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では表示されな
いが、スクロール操作によりブラウザの表示領域に入ってくれば表示でき15る状態になっている）。なお、図９に示したように、各分割画像が当てはめられるセルのセル番号（各分割画像に割り当てられるセル番号）は、分
割画像ごとに一意的に定まっている。前回のブロックの再設定からブロッ
ク内にとどまっている（スクロール操作によってもブロック内から出なかった）分割画像については、セル番号の変更はない。」（段落【００５２】）

20「以上のブロックの再設定制御による、ブロックを構成する各セルに対する分割画像の当てはめの変更の一例を図１４に示す。図１４の各セル位
置に記述されている数値のうち、上段は分割画像座標値を示し、下段はセル番号を示す。この例は、スクロール操作による画像の移動によって、セルの境界がブラウザの原点（０，０）を X 軸方向の右方向に１本だけ越え

25て、Ｙ軸方向には１本も越えていない場合（図１１に示すように画像が移動した場合）を示す。」（段落【００５３】）105【図１４】「なお、以上説明した実施の形態では、画像を縦横両方向に分割したが、縦横一方向にのみ分割することもできる。また、セル（枠要素）を縦横両方向に配列したが、縦横一方向のみに配列することもできる。また、分割
5

画像およびセルを正方形としたが、長方形とすることもできる。分割画像
およびセルを矩形以外の形状に分割することもできる。また、ブロックを構成するセル数を縦横同一としたが、縦横非同一とすることもできる。また、ブロックをブラウザの表示領域に対して予め１セル分左方向および上方向にオフセットさせが、オフセット量は２セル以上にすることもできる。

10

また、分割画像をサーバに予め用意してビューアからの要求を待って送信
106

するようにしたが、ビューアからの要求を待って分割画像を生成して送信することもできる。また、初期表示した後、スクロール操作を待ってその周囲の分割画像をダウンロードするようにしたが、初期表示した後、スク
ロール操作を待たずにその周囲の分割画像を順次ダウンロードすること5もできる。また、新聞を閲覧する場合について説明したが、その他の画像（例えば漫画）を閲覧する場合にもこの発明を適用できる。また、Ｗｅｂ
ブラウザを使用して閲覧する場合について説明したが、プラグインソフト
ウェアを使用して閲覧する場合にも、この発明を適用できる。」（段落【０
０６４】）

10

本件特許の特許請求の範囲及び上記の記載によれば、本件各発明は、Ｗｅｂブラウザの表示領域よりも大きい画像をサーバからダウンロードしてビ
ューアに表示する方法に関するものであり、従来技術では、横縦のサイズ（画素数）の大きい画像をダウンロードしてＷｅｂブラウザに表示するのに長い待ち時間を要し、また、セキュリティやウィルス、ハードディスクの破損な15

どの問題が生じるおそれのあるプラグインソフトウェアをユーザの責任で別途入手しなければ画像を表示できないという技術的課題があった。そのため、
本件各発明は、Ｗｅｂブラウザの表示領域より大きい画像の分割画像を、サーバから優先的にダウンロードして表示する構成（構成要件１Ａ）を採用す
ることにより、ダウンロードしてＷｅｂブラウザに表示するまでの待ち時間20を少なくするとともに、画像全体に対して限定された範囲の分割画像を当てはめる複数の枠要素の配列をＷｅｂブラウザに設け、枠要素を移動、削除及び追加することにより画像を相対移動させる構成（構成要件１Ｂ及び１Ｃ）
を採用し、画像を移動させるための演算を限られた枠要素に限定し、画像全体を移動させる場合よりも演算量を減らすことにより、画像の移動速度を速25くすることを可能にするものであり、併せてプラグインソフトウェアなしでこのような画像表示方法を実現するものであることが認められる。
107

２

被告地図表示方法の構成要件充足性（争点１）について
争点１－１（構成要件１Ａの「表示領域よりも大きい画像を分割し…分割
画像」の充足性）について
ア5「表示領域よりも大きい画像を分割し…分割画像」（構成要件１Ａ）の意義
本件特許の特許請求の範囲には、「Ｗｅｂブラウザの画像を表示する表
示領域よりも大きい画像を分割し該Ｗｅｂブラウザの表示領域に少なくとも一部が入る分割画像をサーバから優先的にダウンロードして該Ｗｅｂブラウザの表示領域に表示する画像表示方法において、」（構成要件１

10Ａ）という記載がある。また、本件明細書等には、実施例として、「図６に示すように、ブラウザの表示領域１６よりも大きい画像１８（新聞紙面
１ページ分の画像）」（段落【００２５】）、「新聞１ページの画像は、異なるファイル形式の分割画像が混在して構成される場合がある。」（段
落【００２０】）、「１ページの画像は、図２に示すように、左上位置（画15

像の原点位置）から横方向（Ｘ軸方向）および縦方向（Ｙ軸方向）にそれ
ぞれ所定画素数ごとに格子状に分割されて、複数の矩形の分割画像の集合で構成されている。…各分割画像には、１ページの画像における各分割画像の位置（番地）を示す座標値（分割画像座標値）として、図２に示すよ
うに、横方向の座標をｘ、縦方向の座標をｙとし、左上角の分割画像位置

20を原点［０，０］とし、右に行くに従い、また下に行くに従い１ずつ増加
する分割画像座標値［ｘ，ｙ］に相当するファイル名がそれぞれ付与されて保存されている。」（段落【００２１】）という記載がある。
そうすると、構成要件１Ａ及び本件明細書等の各記載内容によれば、構成要件１Ａの構成は、ダウンロードの対象となる分割画像●（省略）●で25あるとまで限定して解することはできない。
のみならず、前記１で認定したとおり、本件各発明は、大きい画像をダ108ウンロードしてブラウザに表示するのに長い待ち時間を要するという技
術的課題を解決するため、Ｗｅｂブラウザの表示領域に一部が入る分割画
像を優先的にダウンロードしてＷｅｂブラウザの表示領域に表示するという構成を採用して待ち時間の短縮を可能にする発明である。そうすると、
当該技術思想に鑑みても、本件各発明の効果を奏するためには、大きい画5像を構成する分割画像●（省略）●までを必要とするものとはいえない。
したがって、構成要件１Ａ及び本件明細書等の各記載内容を踏まえると、
構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」とは、表示領域よりも大きい画像の一部を構成し、●（省略）●であれば足り、●（省略）●には限定されないと解するのが相当である。

10

これに対し、被告は、これと異なる見解に立って、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」とは、●（省略）●を意味
するものと解すべきであると主張するが、上記の説示に照らし、採用することができない。
15イ

被告地図表示方法の構成要件充足性について
前提事実及び証拠（甲４、１０、乙１、１６、３３）によれば、被告地
図表示方法でサーバからＷｅｂブラウザにダウンロードされる地図画像
は、●（省略）●であり、Ｗｅｂブラウザから閲覧できる領域にとどまらず、Ｗｅｂブラウザから閲覧できない領域にも配置されることにより、Ｗ

20ｅｂブラウザの表示領域よりも大きい画像の一部を構成しているものと認められるから、構成要件１Ａの「表示領域よりも大きい画像を分割し…
分割画像」に該当する。
これに対し、被告は、●（省略）●を理由に「表示領域よりも大きい画像を分割し…分割画像」の該当性を争うものの、構成要件１Ａにも本件明25

細書等にも●（省略）●記載がないことに照らすと、構成要件１Ａの「表示領域よりも大きい画像を分割し…分割画像」は、●（省略）●に限定さ109

れないものと解するのが相当である。
したがって、被告の主張は、採用することができない。
以上によれば、被告地図表示方法は、構成要件１Ａを充足するものと認められる。
争点１－２（構成要件１Ｂの「複数の枠要素の配列」の充足性）について

5

ア「複数の枠要素の配列」（構成要件１Ｂ）の意義について
本件特許の特許請求の範囲には、「Ｗｅｂブラウザの表示領域に対し所定の位置関係にある、画像全体に対して限定された範囲の画像領域に含まれる分割画像を、個々に当てはめて表示する表示領域に相当する複10数の枠要素の配列をＷｅｂブラウザに設定し、該各枠要素に、該当する
位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、」（構成要件１Ｂ）との記載がある。この記載によれば、構成要件
１Ｂの「複数の枠要素の配列」は、分割画像をＷｅｂブラウザの表示領域の所定の位置に表示させるために複数配列された要素であるものと解15されるものの、上記要素の設定を開始タグと終了タグを使用するものに限定することを示すものと解することはできない。
また、本件明細書等をみても、「複数の枠要素の配列」の実施例として、div タグにより設定され、ブラウザ上の表示位置が座標値によって特定された６×６個のセルが記載されているものの（段落【００２２】、

20【００２３】、【００３２】、【００４０】、【図４】、【図６】、【図９】等）、上記セルの設定を div タグのような開始タグと終了タグを使用するものに限定する趣旨の記載はない。
したがって、構成要件１Ｂ及び本件明細書等の各記載内容を踏まえると、構成要件１Ｂの「複数の枠要素の配列」とは、分割画像をＷｅｂブ

25

ラウザの所定の位置に表示させるための複数の要素の配列を意味するものであり、上記要素の設定について開始タグと終了タグを使用するもの
110には限定されないものと解するのが相当である。
そして、本件特許の特許請求の範囲に「各枠要素に、該当する位置の分割画像をそれぞれ当てはめて表示しまたは表示できる状態にし、」（構
成要件１Ｂ）という記載があるほか、本件明細書等に「画像上にブラウ
5

ザの表示領域全体が入る大きさの『ブロック』を設定する。このブロックは、例えば６×６個の『セル』（枠要素）で構成される。」（段落【００２２】）、「図６、図７、図９、図１１等から明らかなように、セルに当てはめられてもブラウザの表示領域から外れている分割画像はその時点では表示されないが、スクロール操作によりブラウザの表示領域に10入ってくれば表示できる状態になっている」（段落【００３３】、【００５２】、【００６１】）、「ブロック２０は常にブラウザの表示領域
１６全体を含む（ブラウザの表示領域１６全体が常にブロック２０内に含まれる）」（段落【００４２】）という記載があることからすれば、
構成要件１Ｂの「複数の枠要素の配列」には、一部の枠要素がＷｅｂブ

15

ラウザの表示領域から外れているものも含むと解するのが相当である。
これに対し、被告は、本件特許出願当時の技術常識によれば、当業者
は、画像を当てはめることが可能な要素として、Ｗｅｂブラウザの種類を問わずに画像を配置でき、かつ、開始タグ及び終了タグによって画像を当てはめるための枠が観念できるＨＴＭＬ文書のコンテナ要素を指す

20

ものと理解すべきであり、また、本件明細書等に div タグにより設定されたコンテナ要素が記載されていることを根拠に、構成要件１Ｂの「複数の枠要素の配列」には、img タグのように終了タグのない非コンテナ
要素（空要素）は含まれないと主張する。
しかしながら、本件特許出願当時においても、終了タグのない img 要

25

素によってＷｅｂブラウザに画像を表示させることができたものと認められ（乙２）、また、本件明細書等において、div 要素の開始タグ及び終111

了タグは、「セルを設定する（ための）＜ＤＩＶ＞タグ」（段落【００２３】、【００３８】、【００４３】）のように、枠要素それ自体ではなく、枠要素を設定するものとして位置付けられており、タグ自体から枠を観念できることが必要であることを示す記載はない。そうすると、
5

本件特許出願当時の技術常識を踏まえても、枠要素がコンテナ要素のみを意味するものと当業者に理解されるとはいえないから、被告の主張する上記事情は、構成要件１Ｂの「複数の枠要素の配列」をコンテナ要素に限定する理由にはならないというべきである。
また、被告は、構成要件１Ｂの「当てはめて表示する表示領域に相当10する複数の枠要素の配列」の文言に照らすと、構成要件１Ｂの「複数の枠要素の配列」は、表示領域に関連する必要があり、かつ、分割画像が当てはめられると表示領域に表示される必要があると主張するが、本件特許の特許請求の範囲や本件明細書等（段落【００３０】等参照）によれば、空白部分を生じにくくさせるために、ブロックがオフセットして15配置されることなどが記載されており、枠要素がブラウザの表示領域から外れることが当然に想定されていることからすると、構成要件１Ｂの「複数の枠要素の配列」を被告主張のように限定して解釈する理由はな
い。
他方、原告らは、構成要件１Ｂの「複数の枠要素の配列」は、大きさ20の指定により配列されるもので、短い距離のスクロール操作においては位置を連続的に変更させることにより配列を維持したまま、長い距離のスクロール操作においては位置を非連続的に変化させることにより配列を変更することによって、当該スクロール操作に応じた画像の移動を実現するものである必要があると主張する。

25

しかしながら、本件明細書等では、「１つのセルは１つの分割画像の大きさ（例えば４８０×４８０ピクセル）に相当し」（段落【００２２】）、112

「１つの分割画像の大きさ（＝１つのセルの大きさ）を４８０×４８０
ピクセルとする」（段落【００２８】）と記載されているように、分割
画像の大きさによってセルの大きさが定まる関係にあり、セルのソース
プログラム（【図４】）や分割画像をセルに当てはめるための JavaScript の関数（【図１０】）をみても、div タグによりブラウザの表示領域

5

上での大きさを指定する記載はない。しかも、本件明細書等では、セルの再設定の要否について、スクロール操作に係る距離の長短によってではなく、ブラウザの原点がセルの境界を越えたか否かで判断する構成が開示されていることが認められる（段落【００４２】、【００４５】）。
そうすると、スクロール操作の距離によって画像の移動を実現する趣10

旨をいう原告らの主張は、そもそも、本件各発明の基本概念である「枠要素」の意義を明らかに正解しないものといえ、失当というほかない。
したがって、当事者の上記各主張は、いずれも採用することができず、
その他に、当事者の提出する準備書面及び本件全証拠を改めて精査して検討しても、技術説明会における当事者双方の口頭議論の結果及び専門15

委員３名の各説明内容を踏まえると、上記判断を左右するには至らない。
イ

被告地図表示方法の構成要件充足性について
前提事実及び証拠（甲４、１７、乙１、１６、３３）によれば、被告地
図表示方法では、img タグの style 属性の left、top の値でＷｅｂブラウ

20

ザにおける表示位置を定め、img タグの src 属性で地図画像を特定するＵ
ＲＬを指定することによって、Ｗｅｂブラウザの表示領域の所定の位置に
分割画像を表示し又は表示できる状態にしていること、このような img タグにより設定された矩形領域が、Ｗｅｂブラウザの画像の表示領域全体が入るように複数配置されていること、以上の事実が認められる。

25

これらの事実によれば、被告地図表示方法における img タグによって設定された複数の矩形領域の配列は、構成要件１Ｂの「複数の枠要素の配列」
113

に該当する。
したがって、被告地図表示方法は、構成要件１Ｂを充足するものと認められる。
争点１－３（構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該5

位置に枠要素を移動し」の充足性）について
ア「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」（構成要件１Ｃ－１）の意義について
本件特許の特許請求の範囲には、「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」との記載（構成要件１Ｃ－１）がある。こ10の記載によれば、上記の構成が、枠要素の移動すべき位置を演算する構成をいうものと解されるものの、枠要素を移動させるための演算の対象を枠要素に限定することを示すものとまで解することはできない。
そして、本件明細書等をみても、「枠要素の移動すべき位置を演算」の実施例として、ブロックの移動量を演算して移動後の原点を求め、こ15の原点座標に基づき、各セルの原点の座標を演算して求める構成が記載されているものの（段落【００４３】、【００４４】）、枠要素の移動させるための演算の対象を枠要素に限定する趣旨の記載はない。
したがって、構成要件１Ｃ－１及び本件明細書等の各記載内容を踏まえると、構成要件１Ｃ－１の「枠要素の移動すべき位置を演算」は、枠

20

要素自体を演算の対象とするものに限定されず、枠要素以外の要素を演算の対象として枠要素を移動させる構成も含まれるものと解するのが相当である。
これに対し、被告は、本件発明１の従属項の請求項１５ではブロックの原点の移動すべき座標の演算と各枠要素の原点の移動すべき座標の演

25

算が峻別されていることや、本件明細書等にブロックの移動すべき位置を演算し、ブロックと枠要素を一体的に移動させる構成は開示されてい114

ないこと、上記構成により演算量を一定にするという技術思想は本件各発明の技術的意義や作用効果と矛盾するということを理由として、構成
要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」には、枠要素の親要素等の移動すべき位置を演算し、枠要素とその親要素等を一体的に移動させる構成は含まれないと主張する。

5

しかしながら、請求項１５は、画像の相対移動の演算方法を本件発明
１よりも限定するものであるから、請求項１５の記載を理由として、本件各発明において、枠要素以外の要素を演算の対象として枠要素を移動させる構成が含まれないということはできない。
のみならず、本件明細書等に枠要素を移動させるための演算の対象を10

枠要素に限定する趣旨の記載がないのは、上記で説示したとおりである
上、そもそも本件各発明は、画像を移動させるための演算を限られた枠要素に限定して画像全体を移動させる場合よりも演算量を減らすことにより、画像の移動速度を速くすることを可能にするものであるところ、
ブロックのみを演算の対象として枠要素を移動させる構成であっても、

15

画像全体を移動させる場合よりも演算量が減るのであるから、本件各発
明の技術的思想と相容れないことにはならない。
そうすると、被告の主張する上記事情は、構成要件１Ｃの「枠要素の移動すべき位置を演算」の対象を枠要素自体に限定する理由には必ずしもならないというべきであり、上記判断を左右するものとはいえない。

20

その他に被告の提出する準備書面及び本件全証拠を改めて精査して検討しても、上記判断を左右する事情は見当たらない。
したがって、被告の主張は、採用することができない。
イ
25

被告地図表示方法の構成要件充足性について
前提事実及び証拠（甲４、乙１、１６、３３）によれば、被告地図表示
方法では、矩形領域を設定する img タグの２つ上の階層にある div 要素（p115

osition）の開始タグの left、top の値を演算して変更し、複数の矩形領域を一体的に移動させているから、被告地図表示方法での矩形領域の移動は、
構成要件１Ｃ－１の「枠要素の移動すべき位置を演算して該位置に枠要素を移動し」に該当する。
したがって、被告地図表示方法は、構成要件１Ｃ－１を充足するものと5認められる。
争点１－４（構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示
領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウ
ザの表示領域に近づく分割画像に該当する位置に枠要素を追加して画像に対10する枠要素の配列の位置を変更し」の充足性）について
ア

前提事実によれば、被告地図表示方法では、ドラッグ操作を継続し、Ｗ
ｅｂブラウザに地図が表示される領域の中心位置が矩形領域の境界を通過すると、地図が表示されなくなる位置（ドラッグ操作の方向と同方向にある位置）にある矩形領域の img タグの style 属性の left、top の値及びsrc 属性のＵＲＬを書き換え、新たに地図が表示されることになる必要と15なる位置（ドラッグ操作の方向と逆方向にある位置）に矩形領域を設定し直し、矩形領域の配列を変更するものである。そうすると、このような被告地図表示方法の矩形領域の再設定は、構成要件１Ｃ－２の「相対移動に伴いＷｅｂブラウザの表示領域から離れる分割画像に該当する位置から枠要素を削除し、Ｗｅｂブラウザの表示領域に近づく分割画像に該当する

20

位置に枠要素を追加して画像に対する枠要素の配列の位置を変更し」に該当するものと認められる。
したがって、被告地図表示方法は、構成要件１Ｃ－２を充足するものと
いえる。
25

イ

これに対し、被告は、被告地図表示方法では、img タグの style 属性の値を変更して矩形領域の位置を変更しているにすぎず、画像がＷｅｂ
116

ブラウザの表示領域から離れるか近づくかを判別する処理も行われていないと主張する。
しかしながら、本件特許の特許請求の範囲や本件明細書等において、削除する枠要素を新たに追加する枠要素として使用し枠要素の再設定を5行う構成が開示されていることからすれば（【請求項１１】、段落【００４２】）、構成要件１Ｃ－２には、被告地図表示方法のような枠要素の位置を変更する構成も含まれるものと解され、また、構成要件１Ｃ－
２は、画像とＷｅｂブラウザの距離を判別する処理についてまで規定するものではないから、被告地図表示方法において画像がＷｅｂブラウザ

10の表示領域から離れるか近づくかを判別する処理は行われていないこと
は、構成要件１Ｃ－２の充足性を左右するものとはいえない。
被告は、被告地図表示方法では、●（省略）●と主張する。
しかしながら、本件特許の特許請求の範囲や本件明細書等において削除する枠要素を新たに追加する枠要素として使用する構成が開示されて15いるのは、上記のとおりである。また、構成要件１Ｃ－２は「Ｗｅｂブラウザの表示領域に近づく分割画像に該当する位置に枠要素を追加し」と規定し、「分割画像に該当する位置」という文言を採用していることからすると、●（省略）●するものと解するのが相当である。そうすると、●（省略）●は、構成要件１Ｃ－２の充足性を否定する理由にはな

20

らないというべきである。
被告は、被告地図表示方法では、急なドラッグ操作がされた場合は、表示領域が地図画像から外れた後のタイミングで img タグの位置の書換えが行われると主張する。
しかしながら、本件明細書等の「ブロックを構成するセル数をより多25くすれば、画像の移動動作時に空白部分をより生じにくくさせることができるが、その反面、該画像の移動動作時に各セルの座標計算に時間を117

要し、移動速度が遅くなる可能性がある（ただし、ＣＰＵの能力による）ので、移動動作時に空白部分が発生するのを防止することと画像の移動速度との兼ね合いで、ブロックを構成するセル数を設定する。」という記載（段落【００３５】）によれば、本件各発明の構成を採用したとしても、ドラッグ操作の速度次第では、画像の移動動作時に空白部分は生5

じ得るものと解されるから、被告地図表示方法における急なドラッグ操作がされた場合の img タグの書換えのタイミングが被告主張のとおりであったとしても、被告地図表示方法の構成は構成要件１Ｃ－２を充足するものというべきである。
したがって、被告の上記各主張は採用することができない。そして、

10

被告の提出する準備書面及び本件全証拠を改めて精査して検討しても、上記判断を左右するには至らない。
小括
以上によれば、被告地図表示方法は、本件各発明の技術的範囲に属するものということができる。

15

３

本件各発明の無効理由の有無（争点２）について
本件事案に鑑み、争点２－３から判断する。
争点２－３（乙２２文献を主引例とする進歩性欠如の有無）について
ア

20

乙２２文献の記載
乙２２文献には、次のとおりの記載があることが認められる（乙２２）。
「【発明の属する技術分野】本発明は、通信回線を介して地図データベースを有するサーバーとクライアント端末を接続して、クライアント端末
から地図データの要求を行って、サーバーが地図データの要求に基づき地図データベースから地図データを抽出して送信することにより、クライア

25

ント端末で地図データを受信し地図を表示する地図表示制御システムに関する。」（段落【０００１】）
118

「【発明が解決しようとする課題】しかし、従来のインターネット上での地図表示制御システムでは、上記のようにＷｅｂサーバー側からＷｅｂ
クライアント側に地図を送信する場合に、Ｗｅｂサーバー側でイメージデータを生成又は選択してＷｅｂクライアント側に送信することにより、Ｗ
5ｅｂクライアント側でそのイメージデータを受信し表示しているため次のような問題がある。例えばイメージデータはデータ量が大きいため、Ｗ
ｅｂサーバー側でイメージデータを作成してからＷｅｂクライアント側に送信すると、Ｗｅｂサーバー側から送信するデータ量が膨大になる。また、Ｗｅｂクライアント側でイメージデータを受信して表示すると、イメ

10ージデータ自身のサイズが大きいため、Ｗｅｂクライアント側で表示する
までに時間がかかる。しかも、表示する地図について、その位置を変更したり、拡大／縮小したりする場合に、再度、Ｗｅｂサーバー側に地図のイ
メージデータを要求しなければならないため、地図表示の移動・拡大・縮小を行うときにも、初期に地図を表示する場合と同様の時間がかかる。」

15（段落【０００４】）「【課題を解決するための手段】本発明は、上記課題を解決するものであって、サーバーにおけるデータ量を少なくし、初期の地図の表示速度および移動・拡大・縮小の操作時の地図の表示速度を高速化するものである。」（段落【０００５】）20「【発明の実施の形態】以下、本発明の実施の形態を図面を参照しつつ説明する。図１は本発明に係る地図表示制御システムの実施の形態を示す図であり、１はクライアント端末、２、５は記憶装置、３は表示装置、４はサーバー、１１は地図データ要求処理部、１２は地図データ受信処理部、
１３は地図表示処理部、２１は地図要求受付処理部、２２は地図範囲確定

25

処理部、２３は地図データ抽出処理部、２４は地図データ送信処理部を示す。」（段落【０００８】）
119

【図１】
「図１において、クライアント端末１は、地図の表示要求が入力されると、通信回線、例えばインターネット回線を介してサーバー４に地図デー
タの要求を送信し、その地図データの要求に応じてサーバー４から送信さ5れてきた地図データを記憶装置２に格納し、表示装置３に地図を表示するものである。これらの処理を行うものとして、クライアント端末１は、例
えば地図データ要求処理部１１、地図データ受信処理部１２、地図表示処
理部１３を有する。そして、地図データの要求では、地図データ要求処理
120

部１１により要求された地図の表示範囲、内容に基づき記憶装置２の管理
テーブルを参照、設定して、データ種別のレイヤー番号、データ領域のメ
ッシュ番号を求め、データ種別（レイヤー）とデータ領域（メッシュ）の組み合わせで、サーバー４に対して地図データの要求を行う。また、この5とき、地図データの表示倍率や最小表示サイズも指定する。サーバー４から送信されてきた地図データは、地図データ受信処理部１２により記憶装
置２に格納すると共に、管理テーブルの書き換え、更新を行って、地図表
示処理部１３により表示倍率に従って所定の範囲の地図データを読み出して表示装置３に地図を表示する。」（段落【０００９】）10「記憶装置２は、サーバー４に対する地図データの要求を行い、表示装
置３に地図を表示するために必要なデータ種別及びデータ領域を管理す
る管理テーブルとサーバー４から送信されてきた地図データを格納するものである。管理テーブルは、データ種別管理テーブルとデータ領域管理
テーブルからなる。データ種別管理テーブルは、例えば道路地図であれば、

15

道路（高速道路・国道・県道・一般道路）、鉄道、文字情報、シンボル情報等のデータの種類を区別する情報を管理するものであり、地図の表示要求に基づき表示／非表示（表示フラグ）の設定がなされ、表示フラグの設
定内容に基づき地図データの要求を行い、表示装置３への地図の表示制御を行う。また、データ領域管理テーブルは、データ領域のメッシュ番号と20

データ種別のレイヤー番号により記憶装置２に格納された地図データを管理するものであり、この管理テーブルに基づき地図データの要求を行う
データ領域、除外するデータ領域を判断し、また、データ受信時にはその地図データの容量が記憶容量を上回ると、古い地図データの破棄処理を行う。」（段落【００１０】）25「サーバー４は、クライアント端末１からの地図データの要求に対し、記憶装置５に格納したメッシュ・レイヤーインデックスファイルを参照し121

て地図データベースから地図データを抽出し、これをクライアント端末１へ送信するものである。これらの処理を行うものとして、サーバー４は、
例えば地図要求受付部２１、地図範囲確定処理部２２、地図データ抽出処
理部２３、地図データ送信処理部２４を有する。そして、クライアント端
5

末１からの地図データの要求に対し、地図要求受付部２１によりその受付
処理を行い、地図範囲確定処理部２２によりデータ種別、データ領域、地図データの表示倍率、最小表示サイズからメッシュ・レイヤーインデック
スファイルを参照して地図データの抽出範囲を確定することにより、地図データ抽出処理部２３により地図データベースから地図データの要求に10対応した地図データの抽出を行い、地図データ送信処理部２４により抽出した地図データをクライアント端末１に送信する。」（段落【００１１】）「記憶装置５は、データ領域のメッシュ番号とデータ種別のレイヤー番
号から定まるファイル名を持つメッシュ・レイヤーインデックスファイルと、このメッシュ・レイヤーインデックスファイルで管理される地図デー

15

タベースを格納するものである。地図データベースは、クライアント端末
１からの地図データの要求に対して高速にデータ抽出を実現するため、地図の範囲を複数のデータ領域（メッシュ）に分割し、かつ複数のデータ種
別（レイヤー）に分割したデータ構造を持つ。すなわち、メッシュ・レイ
ヤーインデックスファイルには、地図を作成するとき、縦×横を指定範囲、

20

例えば１０ｋｍ×ｌ．５Ｋｍといった範囲の領域にメッシュ分割したデー
タ領域の情報と、データの種類を区別する情報で分割したデータ種別の情報を持つインデックス情報を作成し、クライアント端末１からの地図デー
タの要求に対して、即時に送信すべき地図データを抽出できるようにしている。」（段落【００１２】）

25「クライアント端末に設定される管理テーブルのうち、データ領域管理
テーブルは、例えば図２に示すように地図データを表示する領域（メッシ122ュ）が識別できるデータ領域のメッシュ番号、データの種類を区別するデータ種別ごとに固有のレイヤー番号、表示頻度、表示フラグ、地図データ
ブロック位置、地図データ数の各情報を有するものである。表示頻度は、
地図表示にこの領域の地図データを利用した回数を設定するものであり、
5

この回数は、地図の表示要求により表示装置３の地図表示に利用される毎に加算される。表示フラグは、現在の地図表示で表示対象領域の場合は「１」、表示対象外であれば「０」を設定するものである。地図データブ
ロック位置は、この領域の地図データのメモリ上での位置、つまり記憶装
置２の地図データの格納位置を設定し、地図データ数は、地図のベクター

10

データ数を設定するものである。」（段落【００１４】）【図２】「上記構成のデータ領域管理テーブルでは、記憶装置２に保持されているデータ領域、データ種別の情報を登録しているので、例えば地図の表示要求があると、それに基づき要求すべきデータ領域が記憶装置２に保持さ15れているか否かを知ることができる。したがって、要求すべきデータ領域
が記憶装置２に保持されていれば、地図データブロック位置に基づきその領域の地図データを読み出して表示に利用することができ、そのときデータ領域の表示フラグを「１」にして表示頻度を１回インクリメントする。
123しかし、記憶装置２に要求すべきデータ領域の地図データが保持されていなければ、新たにサーバーに地図データの要求を行わなければならない。
この場合、地図データが送信されてくると、受信した地図データに関する
データ領域管理テーブルを設定して地図データを記憶装置２に格納し、表5

示装置３にその地図を表示すると同時に、データ領域管理テーブルの表示
フラグを「１」にして表示頻度を１回とする。なお、先に述べたようにデータを受信したときその地図データの容量が記憶容量を上回る場合には、データ領域管理テーブルから表示フラグが「１」でなく、表示頻度の最も小さいデータから破棄処理を行う。」（段落【００１５】）

10「クライアント端末における地図データ要求処理の例を説明する。地図
データ要求処理では、図５に示すようにユーザから地図の表示要求があるのを待ち（ステップＳ１１）、地図の表示要求があるとまず、地図の表示
要求の指示情報を入力する（ステップＳ１２）。地図の表示要求では、例
えばディスプレイ上に表示すべき地図の左下の緯度、経度、表示すべき地

15

図のデータ種別、表示倍率、最小表示サイズが入力される。表示すべき地
図の左下の緯度、経度、表示倍率が指示されると、ディスプレイ上の表示
範囲の座標として、ディスプレイ上に表示する４角の緯度、経度の座標を求める（ステップＳ１３）。」（段落【００１９】）

124

【図５】
「次に、この４角の緯度・経度の座標を地図データのマクロ座標に変換し、そのマクロ座標が含まれるメッシュ番号を求め、サーバーに要求すべきメッシュ番号の範囲を求める（ステップＳ１４）。そして、データ領域
5

管理テーブルを参照して該当するデータ領域のメッシュ番号があるか否かを調べる（ステップＳ１５）。既に要求した地図データで記憶装置に保持されているメッシュ番号が存在する場合には、そのメッシュ番号を要求するメッシュ番号から除外し（ステップＳ１６）、残りのメッシュ番号の地図データの要求をサーバーに送信する（ステップＳ１７）。すなわち、

10

データ領域管理テーブルに要求すべきメッシュ番号がありクラアイント
端末で地図データを保持している場合には、同一の領域（メッシュ番号）125

の地図データを再度サーバーに対して要求することは、データ要求が重複し処理速度の低下を招くので、このような問題を解消するため、既にデー
タ要求してクライアント端末で地図データを保持しているメッシュ番号の再度の要求はさせないようにしている。」（段落【００２０】）
5「ディスプレイ表示範囲を含むメッシュ番号に対してデータ要求を行った後は、地図の拡大や移動に備えてその周囲を要求すべき先読みデータ範
囲としてそれらのメッシュ番号を求め（ステップＳ１８）、ステップＳ１５と同様にクライアント端末で保持しているメッシュ番号を調べて除外
し（ステップＳ１９、Ｓ２０）、残りのメッシュ番号の地図データの要求

10をサーバーに送信する（ステップＳ２１）。」（段落【００２１】）「サーバーにおける地図要求受付・送信処理の例を説明する。地図要求
受付・送信処理では、図６に示すようにクライアント端末から地図データの要求があるのを待ち（ステップＳ３１）、地図データの要求があるとまず、クライアントからの地図データの要求で指定されたデータ種別、メッ

15

シュ番号、表示倍率、最小表示サイズの受付を行う（ステップＳ３２）。
そして、表示倍率に基づき領域サイズを計算し（ステップＳ３３）、指定されたメッシュ番号、レイヤー番号にしたがってメッシュ・レイヤーイン
デックスファイルを参照して（ステップＳ３４）、最小表示サイズ以下か否かを調べ（ステップＳ３５）、最小表示サイズより大きい地図データを

20

地図データベースから抽出して（ステップＳ３６）、抽出した地図データを送信する（ステップＳ３７）。この地図データの抽出、送信を最小表示
サイズになるまで繰り返す。」（段落【００２２】）

126

【図６】

【図７】
「本発明に係る地図表示制御システムでは、インターネット上でＷｅｂ
クライアントからＷｅｂサーバーに地図データの要求を行って地図表示
5を行う場合、図７に示すようにＷｅｂクライアント側からの地図データの要求に対し、Ｗｅｂサーバーにおいて地図要求の受け付け処理を行って要求された範囲の地図データを確定し、要求地図データの抽出を行って地図データをＷｅｂクライアントに対して送信する。このとき、Ｗｅｂクライ
アントからの地図データ要求では、図８に示すようにデータ種別（レイヤ10ー番号）と１データの表示領域（メッシュ番号）を指定する形式で、複数回の要求を行うことによって、必要範囲の地図データをＷｅｂサーバーか127ら取得する。」（段落【００２４】）

【図７】

【図８】
「Ｗｅｂクライアントから領域（メッシュ）①～④のデータをレイヤー
5

番号順にＷｅｂサーバー側にデータ要求を送ると、Ｗｅｂサーバー側では、
メッシュ・レイヤーインデックスファイルを検索し、メッシュレイヤーイ
ンデックスファイル内のデータ表示サイズとクライアント側の表示倍率とから計算されるクライアント側表示サイズを求め、最小表示サイズと比較してデータ抽出を行う。このようにＷｅｂサーバーに要求する表示倍率

10および最小表示サイズによって、取得するデータが最適化され、送信されるデータ量が決定される。このようにして地図データベースから読み込んだ地図データはメッシュ単位でまとめて、Ｗｅｂクライアントに送信され地図が表示される。」（段落【００２５】）128

「メッシュ番号は、地図のデータの範囲を含む矩形領域を任意の矩形サ
イズで分割した領域に振られる番号であり、例えば北海道の地図データを作成する場合の、メッシュ番号の採番状況を示したのが図９である。１データの表示領域の指定には、メッシュ・レイヤーインデックスファイルで5管理するこのメッシュ番号を指定する。このことにより、表示領域を直ちに指示することが可能となる。座標単位は、任意に決定されるマクロ座標であるが、原点位置（座標０，０）の緯度・経度とメッシュの矩形サイズ（距離）は地図データ作成時に指定するため、各メッシュ原点（左下座標）の緯度・経度は計算により求められる。また、地図をディスプレイ上に表10示する場合、ディスプレイ上の左下の表示すべき緯度・経度及び表示倍率が指定されれば、ディスプレイに表示する４角の緯度・経度の座標が求められる。この４角の緯度・経度の座標を地図データのマクロ座標に変換し、そのマクロ座標が含まれるメッシュ番号を求めると、サーバーに要求すべきメッシュ番号の範囲が求められる。」（段落【００２６】）

15

【図９】
「地図データの要求は、地図表示等の処理とは別処理で同時に非同期で実行できることから、インターネット利用時にＬＡＮなどより通信速度が遅い公衆回線等の通信網を利用している場合には、ディスプレイの表示範
囲を含むデータ領域のデータをクライアント側で取得した後、さらにその129

データ範囲の外側のデータ範囲を先読み方式でサーバーに要求すること
により、地図操作（移動・縮小・拡大等）時により一層表示のレスポンスを高めることができる。」（段落【００２８】）「いま、地図の表示要求として図１１（Ａ）に示すようにディスプレイ
5

表示範囲が指示されているとすると、その表示範囲の座標を含む１６個のメッシュが地図データの要求範囲となる。このディスプレイ表示範囲を図１１（Ｂ）に示すように移動すると、既にデータ要求済みの部分を除き、
移動方向に１０個のメッシュが新たな地図データの要求範囲となる。」（段
落【００２９】）10【図１１】「しかし、図１１（Ｃ）に示すように表示範囲の座標を含む１６個のメッシュを初期に要求するデータ範囲とし、その外側の２０個のメッシュを次に要求する先読みデータ範囲として先読みしておくと、図１１（Ｄ）に示すようにディスプレイ表示範囲を移動する場合には、移動方向に４個の130

メッシュだけが移動時に要求すべきデータ領域となる。」（段落【００３０】）「図１１（Ｂ）と図１１（Ｄ）とを比較すると明らかなように、図１１（Ｄ）に示す先読み処理により移動時に要求すべきデータ領域の数が、図5１１（Ｂ）に示す先読みなしの場合に比べて減っていることがわかる。」（段落【００３１】）「また、Ｗｅｂクライアントでは、非同期に地図データの要求を行うた
め、最初に要求した地図データが取得できた段階から、地図の描画処理を行うことができる。しかも、地図データの取得を、地図の描画に必要なデ10ータ種別の順序（たとえば、道路・鉄道・行政界等）ごとに優先順位を付
け、その優先順位ごとに地図データの要求を行うと、要求した地図データを取得できたものから地図の描画処理を行うため、画面上の地図表示領域には徐々に地図が表示されていくようになる。しかし、要求に従って順次
地図データを受け取り、表示可能な地図範囲は広がって行くが、Ｗｅｂク

15

ライアント側のメモリ容量にも限界がある。そこで、現在表示対象の領域以外で利用頻度の少ない領域のデータ順に、利用しなくなった地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することにより、メモリ使用の最適化を図ることができる。」（段落【００３２】）「以上の説明から明らかなように、本発明によれば、クライアント端末

20から、地図の表示要求に基づき地図データの要求範囲のデータ領域とデー
タ種別を確定して前記データ種別とデータ領域ごとにサーバーに対して
地図データの要求を行い、サーバーで地図データベースをデータ領域とデータ種別ごとにメッシュ・レイヤーインデッスク情報で管理して、地図データの要求に基づき地図データベースから地図データを抽出して前記ク

25

ライアント端末に送信し地図を表示するので、サーバーにおけるデータ量を少なくし、初期の地図の表示速度および移動・拡大・縮小の操作時の地
131

図の表示速度を高速化することができる。しかも、地図表示時に、地図データをデータ領域とデータ種別に基づき表示に必要な部分から順次分割して取得し、取得できたデータから表示を行うので、インターネットでの利用に十分耐え得る地図の表示制御を行うことができる。また、地図デー
タをイメージデータではなく、数値データ（ベクターデータ）としてＷｅ5ｂクライアントに送信し、送信した地図データをＷｅｂクライアント側で必要な限り保持するため、地図の初期表示速度およぴ移動・拡大・縮小の操作時の地図表示速度を飛躍的に高速化することができる。さらに、Ｗｅ
ｂサーバー側でも地図データをイメージデータとして持たないため、データ量を最小限度に抑えることができる。」（段落【００３４】）10

イ

乙２２発明の内容
上記アの記載によれば、乙２２発明の内容は、以下のとおりと認めるのが相当である。
２２Ａ

Ｗｅｂクライアントの地図を表示するディスプレイ表示範囲

よりも大きい地図データを分割し該Ｗｅｂクライアントのディス

15

プレイ範囲に少なくとも一部が入るメッシュ分割した地図データをサーバから優先的にダウンロードして該Ｗｅｂクライアントのディスプレイ表示範囲に表示する地図表示方法において、
２２Ｂ
20

Ｗｅｂクライアントのディスプレイ表示範囲に少なくとも一部が入るメッシュ分割した地図データから描画された地図を含む、
Ｗｅｂクライアントのディスプレイ表示範囲に対し所定の位置関係にある、地図全体に対して限定された範囲の地図領域に含まれるメッシュ分割した地図データから描画された地図を、個々に当てはめて表示するディスプレイ表示範囲に相当する複数の表示領

25

域の配列をＷｅｂクライアントに設定し、該各表示領域に、該当する位置のメッシュ分割した地図データから描画された地図をそ132

れぞれ当てはめて表示し又は表示できる状態にし、かつ、
２２Ｃ－１

Ｗｅｂクライアントのディスプレイ表示範囲に対する地図の相対移動が指示された時に、Ｗｅｂクライアントのディス
プレイ表示範囲に対する表示領域の移動すべき位置を演算して該位置に表示領域を移動し、

5

２２Ｃ－２

該地図の相対移動に伴いＷｅｂクライアントのディスプレ
イ表示範囲から離れるメッシュ分割した地図データから描画された地図に該当する位置から表示領域を削除し、Ｗｅｂ
クライアントのディスプレイ表示範囲に近づくメッシュ分
割した地図データから描画された地図に該当する位置に表10

示領域を追加して地図に対する表示領域の配列の位置を変更し、該追加する表示領域に、該当する位置のメッシュ分割
した地図データから描画された地図を当てはめて表示しま
たは表示できる状態にし
15２２Ｄ

前記演算はＷｅｂクライアントにより実行される地図表示方法

乙２２文献の記載及び図の内容を総合すれば、乙２２発明の「地図データ」、「ディスプレイ表示範囲」、「メッシュ分割した地図データ（から描画された地図）」、「表示領域」、「地図表示方法」は、それぞれ
本件各発明の「画像」、「表示領域」、「分割画像」、「枠要素」、「画20

像表示方法」に相当するものと解するのが相当である。
ａ

原告らは、乙２２文献には、「枠要素」に相当する構成や画像を「当てはめ」る構成の開示がないと主張する。
そこで検討するに、乙２２文献には、①Ｗｅｂクライアントの記憶装置につき、「記憶装置２は、…表示装置３に地図を表示するために25必要なデータ種別及びデータ領域を管理する管理テーブルとサーバー
４から送信されてきた地図データを格納するものである。」、「管理133テーブルは、データ種別管理テーブルとデータ領域管理テーブルからなる。…データ領域管理テーブルは、データ領域のメッシュ番号とデータ種別のレイヤー番号により記憶装置２に格納された地図データを管理するものであり」（段落【００１０】）という記載が認められ、
5②メッシュ番号につき、「図２に示すように地図データを表示する領域（メッシュ）が識別できるデータ領域のメッシュ番号」（段落【００１４】）、「メッシュ番号は、地図のデータの範囲を含む矩形領域
を任意の矩形サイズで分割した領域に振られる番号であり、例えば北海道の地図データを作成する場合の、メッシュ番号の採番状況を示し

10

たのが図９である。」（段落【００２６】）という記載が認められ、③表示領域につき、「Ｗｅｂクライアントからの地図データ要求では、
図８に示すように…１データの表示領域（メッシュ番号）を指定する
形式で、複数回の要求を行うことによって、必要範囲の地図データをＷｅｂサーバーから取得する。」（段落【００２４】）、「１データ15の表示領域の指定には、メッシュ・レイヤーインデックスファイルで管理するこのメッシュ番号を指定する。このことにより、表示領域を直ちに指示することが可能となる。座標単位は、任意に決定されるマクロ座標であるが、原点位置（座標０，０）の緯度・経度とメッシュの矩形サイズ（距離）は地図データ作成時に指定するため、各メッシ

20

ュ原点（左下座標）の緯度・経度は計算により求められる。」（段落【００２６】）という記載が認められ、④地図の表示につき、「地図データを取得できたものから地図の描画処理を行うため、画面上の地
図表示領域には徐々に地図が表示されていく」（段落【００３２】）という記載が認められる。

25

上記各記載に加えて、【図１】、【図２】、【図８】、【図９】、【図１１】の記載を併せ考慮すれば、表示領域は、原点位置が計算に134

より求められるものであること、Ｗｅｂクライアントは、地図データを表示するための矩形領域を識別するメッシュ番号の指定により、必要範囲の地図データをＷｅｂサーバーから取得し、表示領域を指示す
ること、取得された地図データは、メッシュ番号のある管理テーブルとは別の場所で記憶され、描画処理により、地図が画面上の表示領域5に表示されること、以上の内容が乙２２文献により理解されるものと認められる。
そうすると、乙２２文献における「表示領域」は、メッシュ分割した地図データを指定してＷｅｂクライアントのディスプレイ表示の所
定の位置に地図を表示させるためのものであるから、乙２２文献には、

10

本件各発明における画像を「当てはめ」る「枠要素」に相当する構成が開示されていると認めるのが相当である。
ｂ

これに対し、原告らは、乙２２文献における「地図データ」は、数値データ（ベクターデータ）であるから、これに基づき表示を行う場

15

合に「当てはめ」を行う「領域」をビューアに設定する必要はないと主張する。しかしながら、上記にいう必要性の問題は、構成が開示されているかどうかという問題とは、必ずしも同一の事柄ではなく、乙２２文献における「地図データ」がベクターデータであることは、上記発明の認定を左右するものではない。

20●（省略）●
のみならず、乙２２文献の「地図データ」がベクターデータであるとしても、これをいわゆるラスターデータに置き換えることは、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説
明内容を踏まえると、当時の技術常識に照らし、当業者が適宜になし

25得る事項にすぎず実質的相違点に当たらず、又は明らかに容易に想到することができるものといえる。そうすると、被告の主張はその趣旨
135

をいうものとして相当であり、原告らの主張は、結論において進歩性の判断を左右するものとはいえない。
ｃ

原告らは、乙２２文献に地図データを「枠要素」に「当てはめ」て表示する構成の開示がないことを前提に、乙２２文献には「表示できる状態」の開示はないと主張するが、乙２２文献には、画像を「当て5はめ」る「枠要素」に相当する構成の開示があることは、上記において説示したとおりであり、原告らの主張は、前提を欠く。
ｄ

原告らは、乙２２文献の地図表示方法における表示領域の変更は、「枠要素」に相当する構成が移動するものではないから、乙２２文献

10に「移動すべき位置を演算して該位置に…移動し」の構成の開示はな
いと主張する。
そこで検討するに、乙２２文献の「このディスプレイ表示範囲を図１１（Ｂ）に示すように移動すると、既にデータ要求済みの部分を除き、移動方向に１０個のメッシュが新たな地図データの要求範囲とな15る。」（段落【００２９】）、「図１１（Ｄ）に示すようにディスプ
レイ表示範囲を移動する場合には、移動方向に４個のメッシュだけが移動時に要求すべきデータ領域となる。」（段落【００３０】）とい
う記載及び【図１１】の記載によれば、「表示領域」は、「ディスプレイ表示範囲」の関係で、相対的に移動するものであることが理解で20きる。そして、乙２２文献の「座標単位は、任意に決定されるマクロ座標であるが、原点位置（座標０，０）の緯度・経度とメッシュの矩形サイズ（距離）は地図データ作成時に指定するため、各メッシュ原点（左下座標）の緯度・経度は計算により求められる。また、地図をディスプレイ上に表示する場合、ディスプレイ上の左下の表示すべき25

緯度・経度及び表示倍率が指定されれば、ディスプレイに表示する４角の緯度・経度の座標が求められる。」（段落【００２６】）という136

記載によれば、「表示領域」の移動については、緯度、経度、マクロ座標から領域の移動すべき位置を演算しているものと理解されることからすると、乙２２文献には、「移動すべき位置を演算して該位置に…移動し」との構成の開示があるものと認められる。
ｅ5

原告らは、乙２２文献は「地図データ」を「枠要素」に相当する領域に「当てはめ」て表示する構成を開示するものではないから、その「削除」、「追加」を観念することはできないと主張する。
しかしながら、乙２２文献には、画像を「当てはめ」る「枠要素」に相当する構成が開示されていることは、上記において説示したとおりであり、原告らの上記主張は、前提を欠く。そして、乙２２文献の10

段落【００３２】には、Ｗｅｂクライアントにおいて、現在表示対象の領域以外で利用頻度の少ない領域のデータ順に、利用しなくなった
地図範囲（アクセス、表示を行った古いもの）からメモリ上のデータを破棄することが、段落【００２８】ないし【００３２】及び【図１１】には、地図の相対移動に伴い、新たに表示領域を設定して地図を15表示させる旨が、それぞれ記載されていることからすると、乙２２文
献には、本件各発明における「枠要素」の「削除」、「追加」に相当する構成が、もとより開示されているものと認められる。
ｆ

その他に原告らの準備書面における各主張を改めて検討しても、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各20

説明内容を踏まえると、原告らの主張は、乙２２文献の技術的内容を正解しないものに帰し、いずれも採用することができない。
ウ

対比
本件各発明と乙２２発明を比較すると、本件発明１と乙２２発明には以25下の相違点２２－１及び２が存在し、本件発明２１と乙２２発明には上記の相違点に加えて相違点２２－５が存在するものの、その余は一致するも137

のと認められる。
（相違点２２－１）
本件各発明の「表示領域」は、「Ｗｅｂブラウザの表示領域」とされているのに対し、乙２２発明の「表示範囲」は、「Ｗｅｂクライアントのディスプレイ表示範囲」とされている点

5（相違点２２－２）
本件各発明では、「枠要素の配列」を、「Ｗｅｂブラウザに設定し」とされているのに対し、乙２２発明では、「表示領域の配列」を「Ｗｅｂクライアントに設定」するものとされている点（相違点２２－５）10本件発明２１では、「Ｗｅｂブラウザでの各演算がサーバから送信される JavaScript（登録商標）に基づき実行される」のに対し、乙２２発明では、「演算はＷｅｂクライアントにより実行される」ものの、これが「Ｗｅｂブラウザで」、「JavaScript（登録商標）に基づき実行される」とは明示されていない点

15

エ

相違点の容易想到性について
相違点２２－１について
乙２２文献の記載によれば、乙２２発明は、Ｗｅｂクライアントの端末で、通信回線を介してＷｅｂサーバから地図データを受信し地図を表

20

示する地図表示制御システムであると認められ、また、前提事実、証拠（乙１１ないし１３）及び弁論の全趣旨（技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を含む。）によれば、
本件特許出願日（平成１５年４月１７日）当時、Ｗｅｂクライアントに
Ｗｅｂブラウザを採用することは周知慣用技術であったと認められる。

25

これらの事実によれば、乙２２発明の地図表示制御システムにおいて、
ＷｅｂクライアントにＷｅｂブラウザを採用することは、当業者が適宜138

採用し得る設計的事項であると認められるから、相違点２２－１に係る構成は容易に想到できたものといえる。
相違点２２－２について
乙２２発明におけるＷｅｂクライアントにＷｅｂブラウザが備われば、「表示領域の配列」は、Ｗｅｂブラウザに設定されることになるから、

5

相違点２２－２に係る構成は容易に想到できたものといえる。
相違点２２－５について
前提事実、証拠（乙５、７）及び弁論の全趣旨（技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を含む。）によれば、本件特許出願日当時、Ｗｅｂブラウザでの演算を JavaScript10に基づいて実行することは、周知慣用技術であったと認められる。そうすると、乙２２発明では、演算がＷｅｂクライアントにより実行される
ため、ＷｅｂクライアントにＷｅｂブラウザが備われば、当然に演算はJavaScript に基づき実行されると認められるから、相違点２２－５に係る構成は容易に想到できたものといえる。

15

オ

したがって、本件各発明は、乙２２発明による進歩性欠如の無効理由があるものと認められる。その他に、原告らの提出する準備書面及び本件全証拠を改めて精査して検討しても、技術説明会における当事者双方の口頭議論の結果及び専門委員３名の各説明内容を踏まえると、原告らの主張は、

20

乙２２発明の技術的内容及び当時の技術常識に照らし、独自の見解をいう
ものであり、上記判断を左右するに至らない。
小括
以上によれば、本件各発明は、特許無効審判により無効にされるべきものと認められるから、その余の争点について判断するまでもなく、原告らは、25

被告に対し、本件特許権の侵害による損害賠償請求権の行使をすることができないというべきである。
139

第５

結論
よって、原告らの請求は、いずれも理由がないからこれを棄却することとし、主文のとおり判決する。

5

東京地方裁判所民事第４０部

裁判長裁判官

10

中

島

基

小

田

誉

至

裁判官

太

郎

15

裁判官齊藤敦は退官のため署名押印することができない。

裁判長裁判官

20

中

140

島

基

至