令和４年３月１７日判決言渡同日原本領収裁判所書記官
令和２年(ワ)第３３３９号特許権侵害差止請求及び損害賠償請求事件
口頭弁論終結日令和３年１２月２１日
判決
原告株式会社聖亘トランスネットワーク
同訴訟代理人弁護士高井雅秀
同平野敬
同訴訟復代理人弁護士笠木貴裕
同訴訟代理人弁理士間山進也
被告株式会社ナビタイムジャパン
同訴訟代理人弁護士三村量一
同松井真一
同粂内将人
同澤田将史
主文
１ 原告の請求をいずれも棄却する。
２ 訴訟費用は原告の負担とする。
事実及び理由
第１ 請求
１ 被告は、別紙被告製品目録記載のビジネスナビタイム・サービスを提供するシステム及びプログラムを製造し、使用し、譲渡し、貸し渡し、若しくは輸出し、または譲渡若しくは貸渡しの申出をしてはならない。
２ 被告は、別紙被告製品目録記載のビジネスナビタイム・サービスを提供するシステム及びプログラムを廃棄せよ。
３ 被告は、原告に対し、１１００万円及びこれに対する令和２年３月１７日から支払済みまで年５分の割合による金員を支払え。
第２ 事案の概要
本件は、発明の名称を「物流クラウドシステムおよびプログラム」とする特許に係る特許権を有する原告が、被告が製造・使用等して事業者向けに提供している別紙被告製品目録記載のシステム及びプログラム（以下「被告製品」という。）が、上記特許に係る特許発明の技術的範囲に属し、上記特許権に係る文言侵害、均等侵害、間接侵害が成立する旨主張し、被告に対し、特許法１００条１項及び２項に基づき、被告製品の製造、使用等の差止め及びその廃棄を求めるとともに、民法７０９条に基づき、損害賠償金及び訴状送達の日の翌日から支払済みまで民法（平成２９年法律第４４号による改正前のもの）所定の年５分の割合による金員の支払を求める事案である。
１ 前提事実（証拠を掲げた事実以外は、当事者間に争いがないか弁論の全趣旨により容易に認められる。）
(1) 当事者
ア 原告は、貨物運送取扱業、物流業務のコンサルタント、ソフトウェアの開発及び販売業等を目的とする株式会社である。
イ 被告は、ナビゲーションサイトアプリの運営・開発、法人向けソリューション事業等を目的とする株式会社である。
(2) 本件特許権
ア 原告は、次の内容の特許権を有する（特許第５９２３６９１号。請求項の数は８である。以下、本件特許の特許出願の願書に添付した明細書（図面を含む。）を「本件明細書」といい、その該当部分の記載を【０００１】などと表すこととする。）登録番号特許第５９２３６９１号
発明の名称物流クラウドシステムおよびプログラム
原出願日平成２２年８月３１日
分割出願日平成２６年３月７日
登録日平成２８年４月２８日
イ 本件特許権は、８の請求項から成り（以下、各請求項に係る発明を、請求項の順に「本件発明１」などといい、本件発明１ないし８を併せて「本件発明」という。）、本件発明に係る特許請求の範囲は、次のとおりである。
（請求項１）
物流の輸送を管理するための物流クラウドシステムであって、ネットワークを介して配送するべき荷物の配送依頼に関連して当該荷物を運搬するための運搬車両を特定する情報を少なくとも運行計画データとして運行計画データベースに登録する手段と、前記ネットワークを介して荷物を輸送している運搬車両の最新の位置情報および日時情報を取得して、運行ログとして動態データベースに登録する手段と、配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答して送付する手段とを含み、共通のインターフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、前記運行データベースの検索を実行し、検索された運搬車両の運行計画および過去の位置情報から得た配送目的地までに要する時間および前記動態データベースの運行ログデータの最新の日時情報のデータを取得し、複数のデータベースを横断した検索結果からレスポンスデータを作成して要求元に返す、物流クラウドシステム。
（請求項２）
さらに、登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段と、前記納品先および検索された運行ログで指定される前記運搬車両の最新の位置を参照して地図情報を取得する手段と、前記取得した地図情報に対して前記納品先と最新の位置としてそれぞれ異なる図形オブジェクトを合成し、前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算し、現在配送中の前記運搬車両の集配リストに前記納品予定時刻として顧客または配送依頼元が参照可能な形式で追加して配送状況テーブルを作成する手段とを含む、請求項１に記載の物流クラウドシステム。
（請求項３）
前記物流クラウドシステムは、前記運搬車両が搭載するモバイル端末からの定期的な前記位置情報および日時情報のアップロードを受け付け、前記ネットワークを介してブラウザ手段を介した配送状況の提供および運行計画の作成支援を行う、請求項１または２に記載の物流クラウドシステム。
（請求項４）
前記配送状況要求は、荷主または配送依頼元が発行し、前記物流クラウドシステムは、配送状況要求の発行元に応答を返す、請求項１～３のいずれか１項に記載の物流クラウドシステム。
（請求項５）
情報処理装置を、荷物の輸送を管理するための物流クラウドシステムとして機能させるための情報処理装置実行可能なプログラムであって、情報処理装置を、ネットワークを介して配送するべき荷物の配送依頼に関連して当該荷物を運搬するための運搬車両を特定する情報を少なくとも運行計画データとして運行データベースに登録する手段、前記ネットワークを介して荷物を輸送している運搬車両の最新の位置情報および日時情報を取得して、運行ログとして動態データベースに登録する手段、配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答として送付する手段として機能させ、前記情報処理装置を、共通のインターフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、前記運行データベースの検索を実行し、検索された運搬車両の運行計画および過去の位置情報から得た配送目的地までに要する時間および前記動態データベースの運行ログデータの最新の日時情報のデータを取得し、複数のデータベースを横断した検索結果からレスポンスデータを作成して要求元に返す、プログラム。
（請求項６）
さらに、登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段、前記納品先および検索された運行ログで指定される前記運搬車両の最新の位置を参照して地図情報を取得する手段、前記取得した地図情報に対して前記納品先と最新の位置としてそれぞれ異なる図形オブジェクトを合成し、前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算し、現在配送中の前記運搬車両の集配リストに前記納品予定時刻として顧客または配送依頼元が参照可能な形式で追加して配送状況テーブルを作成する手段として情報処理装置を機能させる、請求項５に記載のプログラム。
（請求項７）
さらに、前記プログラムは情報処理装置を、前記運搬車両が搭載するモバイル端末からの定期的な位置情報および日時情報のアップロードを受け付ける手段、前記ネットワークを介してブラウザ手段を介した配送状況の提供および運行計画の作成支援を行う手段として機能させる、請求項５または６に記載のプログラム。（請求８）
前記配送状況要求は、荷主または配送依頼元が発行し、前記プログラムは、前記情報処理装置を、配送状況要求の発行元に応答を返す手段として機能させる、請求項５～７のいずれか１項に記載のプログラム。
(3) 本件発明の構成要件の分説
本件発明を構成要件に分説すると、次のとおりである（以下、分説した構成要件をそれぞれの符号に従い「構成要件１Ａ」などのようにいう。）。
ア 本件発明１（請求項１）
１Ａ物流の輸送を管理するための物流クラウドシステムであって、
１Ｂネットワークを介して配送するべき荷物の配送依頼に関連して当該荷物を運搬するための運搬車両を特定する情報を少なくとも運行計画データとして運行計画データベースに登録する手段と、
１Ｃ前記ネットワークを介して荷物を輸送している運搬車両の最新の位置情報および日時情報を取得して、運行ログとして動態データベースに登録する手段と、１Ｄ配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答して送付する手段とを含み、
１Ｅ－１共通のインターフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、
１Ｅ－２前記運行データベースの検索を実行し、検索された運搬車両の運行計画および過去の位置情報から得た配送目的地までに要する時間および前記動態データベースの運行ログデータの最新の日時情報のデータを取得し、
１Ｅ－３複数のデータベースを横断した検索結果からレスポンスデータを作成して要求元に返す、
１Ｆ物流クラウドシステム。
イ 本件発明２（請求項２）
２Ｇ登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段と、
２Ｈ前記納品先および検索された運行ログで指定される前記運搬車両の最新の位置を参照して地図情報を取得する手段と、
２Ｉ前記取得した地図情報に対して前記納品先と最新の位置としてそれぞれ異なる図形オブジェクトを合成し、前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算し、現在配送中の前記運搬車両の集配リストに前記納品予定時刻として顧客または配送依頼元が参照可能な形式で追加して配送状況テーブルを作成する手段とを含む、
２Ｊ請求項１に記載の物流クラウドシステム。
ウ 本件発明３（請求項３）
３Ｋ前記物流クラウドシステムは、前記運搬車両が搭載するモバイル端末からの定期的な前記位置情報および日時情報のアップロードを受け付け、
３Ｌ前記ネットワークを介してブラウザ手段を介した配送状況の提供および運行計画の作成支援を行う、
３Ｍ請求項１または２に記載の物流クラウドシステム。
エ 本件発明４（請求項４）
４Ｎ前記配送状況要求は、荷主または配送依頼元が発行し、前記物流クラウドシステムは、配送状況要求の発行元に応答を返す、
４Ｏ請求項１～３のいずれか１項に記載の物流クラウドシステム。
オ 本件発明５（請求項５）
５Ａ情報処理装置を、荷物の輸送を管理するための物流クラウドシステムとして機能させるための情報処理装置実行可能なプログラムであって、情報処理装置を、５Ｂネットワークを介して配送するべき荷物の配送依頼に関連して当該荷物を運搬するための運搬車両を特定する情報を少なくとも運行計画データとして運行データベースに登録する手段、
５Ｃ前記ネットワークを介して荷物を輸送している運搬車両の最新の位置情報および日時情報を取得して、運行ログとして動態データベースに登録する手段、５Ｄ配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答として送付する手段として機能させ、
５Ｅ－１前記情報処理装置を、共通のインターフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、
５Ｅ－２前記運行データベースの検索を実行し、検索された運搬車両の運行計画および過去の位置情報から得た配送目的地までに要する時間および前記動態データベースの運行ログデータの最新の日時情報のデータを取得し、
５Ｅ－３複数のデータベースを横断した検索結果からレスポンスデータを作成して要求元に返す、
５Ｆプログラム。
カ 本件発明６（請求項６）
６Ｇ登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段、
６Ｈ前記納品先および検索された運行ログで指定される前記運搬車両の最新の位置を参照して地図情報を取得する手段、
６Ｉ前記取得した地図情報に対して前記納品先と最新の位置としてそれぞれ異なる図形オブジェクトを合成し、前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算し、現在配送中の前記運搬車両の集配リストに前記納品予定時刻として顧客または配送依頼元が参照可能な形式で追加して配送状況テーブルを作成する手段
６Ｊとして情報処理装置を機能させる、請求項５に記載のプログラム。
キ 本件発明７（請求項７）
７Ｋ前記プログラムは情報処理装置を、前記運搬車両が搭載するモバイル端末からの定期的な位置情報および日時情報のアップロードを受け付ける手段、７Ｌ前記ネットワークを介してブラウザ手段を介した配送状況の提供および運行計画の作成支援を行う手段
７Ｍとして機能させる、請求項５または６に記載のプログラム。
ク 本件発明８（請求項８）
８Ｎ前記配送状況要求は、荷主または配送依頼元が発行し、前記プログラムは、前記情報処理装置を、配送状況要求の発行元に応答を返す手段として機能させる、８Ｏ請求項５～７のいずれか１項に記載のプログラム。
(4) 被告の行為
被告は、平成２４年６月１３日、被告製品の提供を開始した。
被告製品は、スマートフォンのＧＰＳ機能を活用したリアルタイム動態管理、ナビゲーション機能、パーソナルコンピュータ等の計算機端末からの配車計画の転送、車両位置や作業状況の把握、メッセージ送受信等の運行管理支援の機能を含んでいる。
(5) 被告製品の構成
原告が主張する被告製品の構成は、別紙被告製品の構成記載のとおりであるところ、被告製品が構成要件１Ｂ及び５Ｂ、１Ｃ及び５Ｃ、１Ｅ－３及び５Ｅ－３、２Ｈ及び６Ｈ、３Ｋ及び７Ｋ、３Ｌ及び７Ｌを充足することについては当事者間で争いがない。
(6) 先行文献
本件特許権に係る特許の原出願日である平成２２年８月３１日より前に存在する文献として、特開２００３－２５６５１１（乙６。以下、「乙６公報」といい、この公報において開示された発明を「乙６発明」という。）がある。
２ 争点
原告は、本件発明の各構成要件と被告製品の各構成とを対比すると、被告製品は本件発明１及び５の技術的範囲に属する旨主位的に主張し、予備的に、被告製品は本件発明２ないし４、６ないし８の技術的範囲に属する旨主張するとともに、本件発明に関して均等侵害あるいは間接侵害（特許法１０１条２号）が成立すると主張する。被告は、被告製品が本件発明の技術的範囲に属することを否認するとともに、本件発明には無効理由があるとして争っている。本件の争点は、次のとおりである。
(1) 被告製品が本件発明１及び５の技術的範囲に属するか（主位的主張）（争点１）
ア 被告製品が「配送状況要求」を行う構成を有するか（構成要件１Ｄ及び５Ｄの充足性）（争点１－１）
イ 被告製品が「共通のインターフェース」を有するか（構成要件１Ｅ－１及び５Ｅ－１の充足性）（争点１－２）
ウ 被告製品が「荷物ＩＤを指定」して現在位置の要求を行うものか（構成要件１Ｅ－１及び５Ｅ－１の充足性）（争点１－３）
エ 被告製品が「過去の位置情報から得た」配送目的地までの時間に係るデータを用いて配送目的地までの所要時間を計算するか（構成要件１Ｅ－２及び５Ｅ－２の充足性）（争点１－４）
オ 被告製品が「物流クラウドシステム」か（構成要件１Ａ及び５Ａ並びに１Ｆ及び５Ｆの充足性）（争点１－５）
(2) 被告製品が本件発明２及び６の技術的範囲に属するか（予備的主張）（争点２）
ア 被告製品が「配送状況要求」を行う構成を有するか（構成要件２Ｇ及び６Ｇの充足性）（争点２－１）
イ 被告製品が「前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算」する構成を有するか（構成要件２Ｉ及び６Ｉの充足性）（争点２－２）
ウ 被告製品が本件発明１の「物流クラウドシステム」であり、本件発明５の「プログラム」か（構成要件２Ｊ及び６Ｊの充足性）（争点２－３）
(3) 被告製品が本件発明３及び７の技術的範囲に属するか（予備的主張）（争点３）
被告製品が請求項１及び２のいずれかに記載された「物流クラウドシステム」であり、請求項５及び６のいずれかに記載された「プログラム」か（構成要件３Ｍ及び７Ｍの充足性）（争点３－１）
(4) 被告製品が本件発明４及び８の技術的範囲に属するか（予備的主張）（争点４）
ア 被告製品が「配送状況要求」を行う構成を有するか（構成要件４Ｎ及び８Ｎの充足性）（争点４－１）
イ 被告製品が請求項１ないし３のいずれかに記載された「物流クラウドシステム」であり、請求項５ないし７のいずれかに記載された「プログラム」か（構成要件４Ｏ及び８Ｏの充足性）（争点４－２）
(5) 被告製品について本件発明１、５の均等侵害が成立するか（争点５）
(6) 被告製品について本件発明１の間接侵害が成立するか（争点６）
(7) 本件発明は特許無効審判により無効にされるべきものか（争点７）
ア 無効理由１（乙６発明を主引例とする進歩性の欠如）の有無（争点７－１）
イ 無効理由２（明確性要件違反）の有無（争点７－２）
ウ 無効理由３（サポート要件違反）の有無（争点７－３）
エ 無効理由４（補正に係る新規事項の追加違反）の有無（争点７－４）
(8) 差止めの必要性の有無（争点８）
(9) 原告の損害の有無及びその額（争点９）
３ 争点に対する当事者の主張
(1) 争点１－１（被告製品が「配送状況要求」を行う構成を有するか（構成要件１Ｄ及び５Ｄの充足性））
〔原告の主張〕
ア 「配送状況要求」の意義
特許発明の技術的範囲については、特許請求の範囲に基づいて定められ（特許法７０条１項）、特許請求の範囲で用いられている用語は、明細書で特に定義されていない限り、通常の用法や当業者の技術常識に照らして解釈される。本件発明の請求項１及び５に記載されている「配送状況要求」の意義についても、通常の用法と異なる用法を採用している旨の記述はなく、通常の用法に照らして解釈すべきである。そして、通常の用法に従えば、「配送状況要求」とは、運搬車両の配送状況を要求するものであれば足り、かかる要求を超える何らかの情報は必要とされていない。本件明細書の図２３に示されている配送状況テーブルにおいても、荷物を指定して行われない「配送状況要求」の構成が具体的に開示されている。
イ 被告製品の構成
被告製品は、運送業者又は荷送人により動態管理画面の地図タブを表示する操作が行われるか、地図タブを表示した状態で所定時間を経過すると、作業履歴データベースを検索して、作業者（運搬車両）の最新の位置情報及び日時情報が取得される。被告製品においては、地図タブを表示する操作又は地図タブを表示した状態で所定時間が経過することにより、作業者（運搬車両）を指定した配送状況要求が行われている。
また、被告製品の配車計画は、対象日、作業者ユーザーコード、訪問順番、訪問先コード、案件名称、案件詳細、出発時刻、到着時刻、荷物量が含まれており、これらの全部又は一部の情報によって、特定の日における特定の訪問先に配送される荷物が特定される。そして、本件特許の「配送状況要求」と対照すべき被告製品の処理は、前記のとおり、「地図タブを表示する操作」又は「地図タブを表示した状態で所定時間を経過する」ことにあり、被告製品の地図タブには、日にち、作業者、訪問順番、訪問先、案件名称、案件詳細、出発時刻、到着時刻の情報が掲載される。そうすると、被告製品は、地図タブを表示する操作又は地図タブを表示した状態で所定時間が経過することによって、これらの情報を指定した上で、配送状況要求が行われており、被告製品は、荷物（訪問先に配送される荷物）を指定して配送状況を要求する構成を備えている。
ウ 小括
以上より、被告製品は、「配送状況要求」を行う構成を有している。
〔被告の主張〕
ア 「配送状況要求」の意義
「配送状況要求」を定めている構成要件１Ｄ及び５Ｄには、その意義について記載はないものの、構成要件１Ｂに「配送するべき荷物の配送依頼」との文言があることからすると、配送状況要求の対象は、「荷物」であることが明らかである。そして、「荷物」の配送状況を要求する際には、個々の「荷物」を指定して行われることが自然であることからすると、構成要件１Ｄの「配送状況要求」は、個々の荷物を指定することによって、荷物の配送の状況を要求することを意味するというべきである。このような解釈が正しいことは、構成要件２Ｇに「登録した前記配送状況要求で指定された荷物について」との文言があることからも明らかである。
イ 被告製品の構成
被告製品は、運送業者又は訪問先ごとに割り当てられる顧客コードを指定した設定を行った荷送人により動態管理画面の地図タブを表示する操作が行われる、又は地図タブを表示した状態で所定時間を経過すると、作業履歴データベースを検索して作業者の最新の位置情報及び日時情報を使用して、訪問先と作業者の最新の位置とを表示するための地図情報を取得し、訪問先及び作業者に対してそれぞれ異なる図形オブジェクトを割り当てて、前記地図情報上に合成し、画面に表示する手段を備えている。このように、被告製品は、作業者を指定して地図情報の取得等を要求する手段を備えているものの、配車計画の作成において個々の荷物の情報は含まれておらず、個々の荷物を指定して地図情報の取得等を要求する手段を備えていない。
ウ 小括
以上より、被告製品は、個々の荷物を指定して行われる「配送状況要求」を行う構成を備えていない。
(2) 争点１－２（被告製品が「共通のインターフェース」を有するか（構成要件１Ｅ－１及び５Ｅ－１の充足性））
〔原告の主張〕
ア 「共通のインターフェース」の意義
物流サーバとクライアントが情報通信を行う際の方式を「インターフェース」といい、「共通」とは、荷主及び配送依頼元において情報通信方式が共通であることを意味する。すなわち、「共通のインターフェースを介して」とは、荷主及び配送依頼元において、ＨＴＴＰプロトコロル方式・ＦＴＰプロトコル方式にて情報通信が行われることを指す。「共通のインターフェースを介して」という構成は、クラウドシステムの幅広いネットワークアクセスを可能とするという、従来のクライアントサーバシステムが有しない特徴を示すものである。
ここで、「共通のインターフェース」を介して現在位置状況を共有する「荷主」及び「配送依頼元」につき、「荷主」とは、本件明細書に「荷物に対する権利を有する人、団体、または企業を意味」【００２０】と記載されており、たとえば、通販会社で商品を購入して通販会社が物流者（荷物の運搬を実際に行う運送業者）に荷物の運送を依頼する場合、「荷主」には、荷物の購入者又は通販会社などの仲介業者を含む。一方、「配送依頼元」は、物流に関わる者のうち、集配を指令する者で、「荷主」に該当しない者をいう。
イ 被告製品の構成
被告製品は、クラウドシステムであり、ブラウザという共通のインターフェースを介して配送依頼元である運送会社から運搬車両の現在位置要求をナビタイムサーバに送付している。したがって、被告製品は、共通のインターフェースを介して運送業者又は荷送人において作業者を指定した到着予定時刻を含む案件進捗状況の表示を要求する操作が行われる構成を備えている。
ウ 小括
以上より、被告製品は、「共通のインターフェース」を有している。
〔被告の主張〕
ア 「共通のインターフェース」の意義
「共通のインターフェース」とは、「荷主」及び「配送依頼元」ごとに異なる処理プロセスを用意したり、アクセスキーの発行、電子メールの発行などの追加の処理を行うことなく、「荷主」又は「配送依頼元」に対し、荷物の現在位置情報を提供することができるインターフェースであると解される。そして、原告の本件発明の特許出願の際の主張によれば、本件発明における「荷主」や「配送依頼元」とは、荷物を受け取る荷受人が「荷主」に当たり、運送業務を依頼する荷送人は「配送依頼元」に当たり、運送業務を請け負う運送業者は「荷主」にも「配送依頼元」にも当たらないというべきである。
イ 被告製品の構成
これを前提とすると、被告製品は、運送業務を請け負う運送業者向けの運送管理システムであるが、運送業務を依頼する荷送人が「動態管理のみロール」のユーザ（以下「動態管理のみユーザ」という。）として利用することが可能である一方、荷物を受け取る荷受人がユーザとして利用することは予定していない。そして、上記の本件発明における「荷主」及び「配送依頼元」の意義に従うと、荷送人は「配送依頼元」に当たるが、運送業者は「荷主」にも「配送依頼元」にも当たらないのであるから、被告製品は、本件発明でいう「荷主」に当たる荷受人の利用を予定していないということができる。したがって、荷主及び配送依頼元に対し、荷物の現在位置情報を提供することができるインターフェースが存在しない。また、「配送依頼元」に当たる荷送人については、訪問先ごとに割り当てられる顧客コードを指定した設定を行わなければ、当該訪問先に係る案件の進捗情状を閲覧することはできないから、荷主及び配送依頼元ごとに異なる処理プロセスを用意したり、アクセスキーの発行、電子メールの発行などの追加の処理を行うことなく荷物の現在位置情報提供することができるインターフェースを有していない。
ウ 小括
以上のとおり、被告製品は、「共通のインターフェースを介して」との構成を有していない。
(3) 争点１－３（被告製品が「荷物ＩＤを指定」して現在位置の要求を行うものか（構成要件１Ｅ－１及び５Ｅ－１の充足性））
〔原告の主張〕
ア 「荷物ＩＤを指定」するの意義
「荷物」という文言は、例えば、一台の運搬車両に複数箱の段ボール箱が積載されている場合、複数箱全体を総称して「荷物」と称することもあれば、ひと箱のみを指して「荷物」と称することもあるように、その文言のみから、その範囲は明確に定まらない。そして、本件発明における「荷物ＩＤ」については、運搬車両に積載されているひと箱の荷物を一意的に識別・特定することが可能なものであることは要求されておらず、運搬車両に積載されている荷物を識別・特定する識別子を意味する。すなわち、運搬車両に積載されている荷物全体を識別・特定する識別子や、運搬車両に積載されている特定の荷物を識別・特定する識別子を「荷物ＩＤ」として用いることができる。このことは、構成要件２Ｇにおいて「登録した前記配送状況要求で指定された荷物」についても同様である。本件明細書にも、「荷物ＩＤ、すなわち当該荷物を運送している運搬車両」（【００９２】）と記載している。
イ 被告製品の構成
被告製品は、運送業者又は荷送人から、作業者（運搬車両）を指定した到着予定時刻を含む案件進捗状況の表示を要求する操作が行われる構成を備えている。これは、運搬車両に積載されている荷物全体を識別・特定する識別子を指定することである。
ウ 小括
以上より、被告製品は、「荷物ＩＤを指定」して現在位置要求を行う構成を備えている。
〔被告の主張〕
ア 「荷物ＩＤを指定」するの意義
「荷物ＩＤを指定」するとは、荷物を一意に識別・特定することが可能である荷物固有の識別子を指定することを意味すると解される。まず、「ＩＤ」という文言の一般的な字義からすれば、荷物固有の識別子を指すと理解するのが通常である。あえて「ＩＤ」という識別子を指す文言を用い、当該識別子の対象を「荷物」としていることからすると、運搬車両を識別・特定する識別子で足りると解することはできず、「荷物」の最小単位である個々の荷物を固有に識別することができる識別子であることを要すると解するのが合理的である。また、本件特許権に係る特許請求の範囲の請求項１をみると、「現在位置要求」は「荷主」と「配送依頼元」が行うとされているところ、これらの者、すなわち、荷受人及び荷送人は、個々の荷物を固有に識別する情報（伝票番号など）が与えられることを受けて、当該情報を指定して「現在位置要求」を行うことが通常予定され、このことからも、「荷物ＩＤを指定」とは、個々の荷物固有の識別子を指定することを意味すると解するのが相当である。さらに言えば、本件明細書段落【００７０】には、運搬車両ごとに与えられる集配リストに関し、「荷物を識別するための荷物ＩＤ」が用いられていることが示唆されているし、段落【００９７】には、配送状況確認が要求された場合には、荷物を特定する荷物ＩＤを受領し、当該荷物ＩＤに対応する運搬車両の運行ログデータを抽出するとか、地図情報表示が要求された場合には、地図情報要求が含む荷物ＩＤを受領し、当該荷物ＩＤに対応する運搬車両の配送状況を取得するなどといった記載があり、荷物ＩＤは、荷物を一意的に識別・特定することが可能なものとされている。加えて、段落【００６２】にも、運搬車両が特定の荷物について集配を完了すると、運転者がその旨を運行管理部に通知すること、当該通知には、荷物ＩＤ及び集配完了日時を含むことが必要であることの記載があり、ここでも、特定の荷物と荷物ＩＤが対応することの示唆がある。
したがって、「荷物ＩＤを指定」の意義には、個々の荷物固有の識別子を指定することを意味すると解される。
イ 被告製品の構成
被告製品は、作業者を指定して到着予定時刻を含む案件進捗状況の表示を要求する操作が行われるものであり、個々の荷物を指定して案件進捗状況の表示が行われるものではない。また、作業者は、複数の荷物を運搬しており、作業者を指定しただけでは、当該作業者が配送する複数の荷物の中のいずれの荷物を指すかが明らかになるものではなく、個々の荷物固有の識別子を指定したことにはならない。
ウ 小括
以上から、被告製品は、「荷物ＩＤを指定」する構成を有しない。
(4) 争点１－４（被告製品が「過去の位置情報から得た」配送目的地までの時間に係るデータを用いて配送目的地までの所要時間を計算するか（構成要件１Ｅ－２及び５Ｅ－２の充足性））
〔原告の主張〕
ア 「過去の位置情報」の意義
「過去の位置情報」とは、車両の過去の位置情報を意味する。車両の過去の位置情報は、検索された運搬車両の過去の位置情報であってもよいし、不特定の走行車から収集される過去の位置情報であってもよい。構成要件１Ｅ－２及び５Ｅ－２において「前記運行データベースの検索を実行し、検索された運搬車両の運行計画および過去の位置情報から得た配送目的地までに要する時間」と規定しているところ、「検索された運搬車両の運行計画」及び「過去の位置情報」から配送目的地までに要する時間を算出する具体的な構成として、本件明細書の段落【００９１】には、ＧｏｏｇｌｅＭａｐといった商用データベースに含まれる速度データベースを用いるなどの不特定の走行車から収集される「過去の位置情報」を用いる態様が示され、また、段落【０１０６】には、検索された運搬車両の「過去の位置情報」を用いる態様が示されている。
イ 被告製品の構成
被告製品は、少なくとも、プローブ情報に含まれる所要時間（走行速度）の情報を取得し、これらを用いて到着予定時刻を計算する構成を備えている。したがって、被告製品は、不特定の走行車から収集される過去の位置情報を用いて配送目的地までに要する時間が取得されている。
加えて、被告製品は、検索された運搬車両の過去の位置情報を用いて配送目的地までに要する時間が取得されている。まず、被告製品の提供が開始された時点において、全国のすべての道路を網羅するプローブ情報データを保有することは不可能であって、常識的に考えても、ＶＩＣＳ情報及びプローブ情報などの統計的なデータが存在しない道路については、これらの情報以外の情報、すなわち、当該個別の運搬車両の過去の位置情報を用いて配送目的地までに要する時間を算出していたと考えるのが自然かつ合理的である。また、被告によれば、被告が開発した経路検索システムのうち、システムの中核をなす経路探索エンジンにおける最適経路の算出において考慮される要因は、①所要時間、②金銭（有料道路料金、燃料代）、③走りやすさの３種類に大別され、①の所要時間の算出には、プローブデータ（予測、リアルタイム）及びＶＩＣＳデータ（長期予測、短期予測、リアルタイム）の動的な交通情報のほかに、予め算出した標準旅行速度が用いられており、「プローブデータを基にした統計的な予測データのみを用いているため、実際のサービスで運用しているＶＩＣＳ・リアルタイム情報による影響は把握できていない」との報告がされている。そうであれば、被告製品において、リアルタイム情報、すなわち、当該個別の運搬車両の過去の位置情報を考慮した上で、次のとおりの計算式を用いて、配送目的地までに要する時間が算出されていることが明らかである。
【計算式】
到着予定時刻＝Ｔｇ＋Ｌ
Ｖ＋Ｄｇ−Ｌ
Ｖｓ
Ｔｇ：現在時刻
Ｌ：Ｔｇ以後の実走行距離（ｋｍ／ｈ）
Ｖ：Ｔｇ以前（過去）に所定距離を走行した車両の実際の平均速度
Ｄｇ：現在地から目的地までのマップ上の距離（ｋｍ）
Ｖｓ：アプリシステムが設定する目的地までの未走行部分での平均速度
ウ 小括
以上から、被告製品は、到着予定時刻の算出に当たって、不特定の走行車から収集される過去の位置情報及び個別の運搬車両の過去の位置情報を用いており、「過去の位置情報から得た」配送目的地までの時間に係るデータを用いて配送目的地までの所要時間を算出する構成を有している。
〔被告の主張〕
ア 「過去の位置情報」の意義
構成要件１Ｅ－２及び５Ｅ－２では、配送目的地までに要する時間は、運行データベースの検索を実行し、検索された運搬車両の運行計画及び過去の位置情報から得るものとされている。この「過去の位置情報」は、検索された当該個別の運搬車両の過去の位置情報を指しており、多数の自動車の統計的な情報は含んでいない。本件発明がこのような構成を採用している理由は、本件明細書によれば、多数の自動車の統計的な情報だけでは、納品時刻を当該運搬車両から送付された運行ログデータの時系列解析によって平均時速を計算することができないため、納品時刻を当該運搬車両から送付された運行ログデータの時系列解析によって平均時速を計算し、予定されている経路に沿った距離を当該平均時速で除算して、現在の時刻に加算し、予定時刻として算出すれば（【０１０６】参照）、運搬車両の現実的な移動速度に基づいて計算されるので、単に道路状況などを利用して計算される予定時刻よりも正確なものとなり（【０１０７】参照）、よって、時々刻々と変化する状況をリアルタイムに反映することができ、ユーザへの納品、ユーザによる納品後処理をより効率化させることができるということである。さらには、本件明細書においては、「運搬車両の現在位置および過去の位置情報から計算された平均速度」との記載があり（【００９１】）、「検索された運搬車両」（荷物ＩＤに対応する荷物を運搬する車両）の「過去の位置情報」を用いて配送目的地までに要する時間を計算しているし、実施形態として、「該当する運搬車両の現在位置及び動態ＤＢ１２０の運行ログから計算される配送予定時刻」との記載があり（【０１０２】）、検索された運搬車両の過去の位置情報を用いて配送目的地までに要する時間を計算している。
このように、本件明細書では、一貫して「検索された運搬車両」（荷物ＩＤに対応する荷物を運搬する車両）の過去の位置情報を用いて配送目的地までに要する時間を計算することを前提として記載されており、多数の自動車の統計的な情報が「過去の位置情報」に含まれることを前提とした記載は見当たらない。
したがって、「過去の位置情報」には、多数の自動車の統計的な情報は含まず、「検索された当該個別の運搬車両の過去の位置情報」を意味するというべきである。
イ 被告製品の構成
被告製品では、到着予定時刻の算出には、①配車計画データベースの検索を実行して取得される作業者ごとの配車計画のうちの訪問先及び作業時間の情報、②作業履歴データベースの検索を実行して取得される作業者の最新の位置情報及び日時情報、③ＶＩＣＳ情報やプローブ情報などの統計的な情報に含まれる所要時間（走行速度）の情報を用いているのであって、本件発明が用いる個別の運搬車両の過去の位置情報は用いていない。このことは、被告製品では、移動速度が異なる複数の車両間の、ほぼ同一の時点での到着予定時刻の算出の結果（走行中の到着予定時刻の更新の場合も含む。）がほぼ同じであることからも明らかである。
なお、被告製品は、次の計算式を用いて到着予定時刻を算出している。
【計算式】
到着予定時刻＝Ｔｇ＋Ｄｇ／Ｖｓ
Ｔｇ：現在時刻
Ｄｇ：現在地から目的地までのマップ上の距離（ｋｍ）
Ｖｓ：アプリシステムが設定する目的地までの未走行部分での平均速度
ウ 小括
以上より、被告製品は、「過去の位置情報から得た」配送目的地までの時間に係るデータを用いて配送目的地までの所要時間を算出する構成を有しない。
(5) 争点１－５（被告製品が「物流クラウドシステム」か（構成要件１Ａ及び５Ａ並びに１Ｆ及び５Ｆの充足性））
〔原告の主張〕
被告は、本件訴訟において、被告製品が「クラウドシステム」であることについて認める旨の主張をしており、この点について既に自白が成立している。原告が主張する「クラウドシステム」の解釈が当業者の技術的常識に照らして妥当であることは明らかであって、被告が自らクラウドシステムを展開する事業者であることも考慮すれば、自白の撤回を許すべき理由もない。
また、下記のとおり、被告製品が「クラウドシステム」に該当しないとの被告の主張には理由がない。
ア 「クラウドシステム」の意義
「クラウドシステム」とは、共用の構成可能なコンピューティングリソースの集積に、どこからでも、簡単に、必要に応じてネットワーク経由でアクセスすることを可能とするシステムであり、最小限の利用手続又はサービスプロバイダとのやり取りで速やかに割り当てられ提供されるシステムのことをいう。また、クラウドサービスとは、クラウドシステムにより提供されるサービスのことをいう。クラウドシステムには、次の５つの基本的な特徴が必要とされる。
① ユーザが各サービスの提供者と直接やり取りすることなく、必要に応じ、自動的に、サーバの稼働時間やネットワークストレージのようなコンピューティング能力を一方的に設定できること（オンデマンド・セルフサービス）
② ネットワークを通じて利用可能で、標準的な仕組みで接続可能なコンピューティング能力を備え、そのことにより、様々なシン及びシッククライアントプラットフォーム（例えばモバイルフォン、タブレット、ラップトップコンピュータ、ワークステーション）からの利用を可能とすること（幅広いネットワークアクセス）
③ サービスの提供者のコンピューティングリソースが集積され、複数のユーザにマルチテナントモデルを利用して提供されること（リソースの共有）
④ コンピューティング能力が、伸縮自在に、場合によっては自動で割当て及び提供が可能で、需要に応じて即座にスケールアウト、スケールインできること（スピーディな拡張性）
⑤ 計測能力を利用して、サービスの種類（ストレージ、処理能力、帯域、実利用中のユーザアカウント数）に適した管理レベルで、リソースの利用をコントロールし最適化できること（サービスが計測可能であること）
イ 被告製品の構成
被告製品は、クラウドシステムの有する上記５つの特徴全てを備えている。被告は、被告製品がクラウドサービスであるとうたって販促を行っている。実際にも、被告製品の動態管理のみユーザは、顧客コードを被告製品に登録するのみで、被告製品のサーバから地図情報及び案件情報に対して障壁なく接続し、動態管理のみユーザの権限に基づいてそれらを統合（マッシュアップ）した情報を閲覧することができ、地図情報を管理するデータベース、動態情報を管理するデータベース及び運送計画を管理するデータベースという少なくとも３つのデータベース間においてコンピューティングリソースが集積されている（上記③）。また、被告は、顧客の申込みに対して手動でアカウントの登録などの作業を行っていることを理由にオンデマンド・セルフサービス（上記①）を満たさない旨主張するが、これは、被告の営業活動の一環として、顧客が被告の提供するクラウドサービスを利用できるように設定しているのみであり、オンデマンド・セルフサービスを満たさないことを意味しない。そして、被告製品が、そのほかの特徴（上記②、④及び⑤）を有することについては、争いがない。
ウ 小括
以上より、被告製品は「物流クラウドシステム」である。
〔被告の主張〕
被告は、被告製品が一般的な意味でのクラウドシステムの解釈を前提として被告製品が「クラウドシステム」であることを認めていたが、以下のとおり、原告が主張する「クラウドシステム」の意義が原告独自の解釈に基づくものであることが判明したため、被告製品が原告の解釈を前提とする「クラウドシステム」を有するものではないとして否認するに至ったものである。したがって、このような事情の下においては、自白の撤回を許すべきである。
ア 「クラウドシステム」の意義
本件発明の「クラウドシステム」は、一般的な意義、すなわち、コンピュータの機能や処理能力、ソフトウェア、データなどをインターネットなどの通信ネットワークを通じてサービスとして呼び出して遠隔から利用するシステムと解すべきである。
イ 被告製品の構成
被告製品は、顧客から利用の申込みを受け付けると、被告の担当者が顧客に対し、サービスの導入の説明及び初期設定に必要な情報を取得するためのヒアリングを行い、必要な提案をした上で、手動でアカウントの登録などの作業を行っており、オンラインストレージサービスやメールサービスのように利用者が申込みをすれば、サービス提供者とコミュニケーションを行わずに自動的にサービスを利用開始できるものではない。
したがって、被告製品は、原告の主張するクラウドシステムの意義を前提とすると、その特徴である上記①（オンデマンド・セルフサービス）の点を備えていない。また、被告製品は、荷送人については、訪問先として特定の顧客に割り当てられた顧客コードの登録を行わなければ、当該訪問先に係る案件の進捗状況を閲覧することができず、アクセスキーの発行が必要とされている。
そのため、被告製品は、原告の主張するクラウドシステムの意義を前提とすると、その特徴である上記③（リソースの共有）の点を備えていない。
ウ 小括
以上より、被告製品は、原告の主張する「クラウドシステム」の意義を前提とすると、構成要件１Ａ及び５Ａ並びに１Ｆ及び５Ｆを充足しない。
(6) 争点２－１（被告製品が「配送状況要求」を行う構成を有するか（構成要件２Ｇ及び６Ｇの充足性））
〔原告の主張〕
前記(1)で主張したとおり、被告製品は、荷物（訪問先に配送される荷物）を指定して配送状況を要求する構成を備えている。
したがって、被告製品は、「登録した前記配送状況要求で指定された荷物」について運行ログを検索する手段である構成要件２Ｇ及び６Ｇを充足する。
〔被告の主張〕
構成要件２Ｇは「登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段」及び構成要件６Ｇは「登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段」であり、荷物を指定して地図情報の取得等を要求する構成である。
一方、前記(1)で主張したとおり、被告製品は、作業者を指定して到着予定時刻を含む案件進捗状況の表示を要求する操作が行われるのであって、荷物を指定して地図情報の取得等を要求する手段を備えていない。
したがって、被告製品は、構成要件２Ｇ及び６Ｇを充足しない。
(7) 争点２－２（被告製品が「前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算」する構成を有するか（構成要件２Ｉ及び６Ｉの充足性））
〔原告の主張〕
被告製品は、前記(4)で主張したとおり、当該個別の運搬車両の過去の位置情報を用いて配送目的地への所要時間を算出している。
したがって、被告製品は、「前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算」する構成を有しており、構成要件２Ｉ及び６Ｉを充足する。
〔被告の主張〕
構成要件１Ｃ及び５Ｃにおいて「運搬車両の最新の位置情報および日時情報」が「運行ログ」として運行データベースに登録されると規定されていることから、構成要件２Ｉ及び６Ｉの「運行ログにおける履歴」は、順次記録されていった過去の一時点での運搬車両の最新の位置情報及び日時情報、すなわち、当該個別の運搬車両の過去の位置情報及び日時情報を意味している。そうすると、構成要件２Ｉ及び６Ｉにおいて、「納品予定時刻」は「運行ログにおける履歴」すなわち、当該個別の運搬車両の過去の位置情報及び日時情報を使用して算出される必要がある。一方、被告製品が到着予定時刻の算出に用いている情報は、上記(4)で主張したとおり、①配車計画データベースの検索を実行して取得される作業者ごとの配車計画のうちの訪問先及び作業時間の情報、②作業履歴データベースの検索を実行して取得される作業者の最新の位置情報及び日時情報、③ＶＩＣＳ情報やプローブ情報などの統計的な情報に含まれる所要時間（走行速度）のみであり、当該個別の運搬車両の過去の位置情報は用いていない。
したがって、被告製品では、「納品予定時刻」は、「運行ログにおける履歴」を使用して算出されておらず、構成要件２Ｉ及び６Ｉを充足しない。
(8) 争点２－３（被告製品が本件発明１の「物流クラウドシステム」であり、本件発明５の「プログラム」か（構成要件２Ｊ及び６Ｊの充足性））
〔原告の主張〕
被告製品は、上記(5)で主張したとおり、本件発明１の「物流クラウドシステム」であり、本件発明５の「プログラム」である。
したがって、被告製品は、構成要件２Ｊ及び６Ｊを充足する。
〔被告の主張〕
被告製品は、上記(5)で主張したとおり、本件発明１の「物流クラウドシステム」でもなければ、本件発明５の「プログラム」でもない。
したがって、被告製品は、構成要件２Ｊ及び６Ｊを充足しない。
(9) 争点３－１（被告製品が請求項１及び２のいずれかに記載された「物流クラウドシステム」であり、請求項５及び６のいずれかに記載された「プログラム」か（構成要件３Ｍ及び７Ｍの充足性））
〔原告の主張〕
本件特許の特許請求の範囲の請求項３Ｍは、「請求項１または２に記載の物流クラウドシステム」、構成要件７Ｍは「として機能させる、請求項５または６に記載のプログラム」であるところ、被告製品は、上記(8)で主張したとおり、本件発明１及び２の「物流クラウドシステム」であり、本件発明５及び６の「プログラム」であるから、構成要件３Ｍ及び７Ｍを充足する。
〔被告の主張〕
被告製品は、上記(8)で主張したとおり、本件発明１又は２に記載の「物流クラウドシステム」ではなく、また、本件発明５又は６に記載の「プログラム」ではないから、構成要件３Ｍ及び７Ｍを充足しない。
(10) 争点４－１（被告製品が「配送状況要求」を行う構成を有するか（構成要件４Ｎ及び８Ｎの充足性））
〔原告の主張〕
構成要件４Ｎは「前記配送状況要求は、荷主または配送依頼元が発行し、前記物流クラウドシステムは、配送状況要求の発行元に応答を返す」、構成要件８Ｎは「前記配送状況要求は、荷主または配送依頼元が発行し、前記プログラムは、前記情報処理装置を、配送状況要求の発行元に応答を返す手段として機能させる」である。被告製品は、上記(1)で主張したとおり、個々の荷物を指定して地図情報の取得等を要求する手段を備えているから、構成要件４Ｎ及び８Ｎを充足する。
〔被告の主張〕
被告製品は、上記(1)で述べたとおり、荷物を指定して地図情報の取得等を要求する手段を備えておらず、「前記配送状況要求」を行う構成を備えていない。したがって、被告製品は、構成要件４Ｎ及び８Ｎを充足しない。
(11) 争点４－２（被告製品が請求項１ないし３のいずれかに記載された「物流クラウドシステム」であり、請求項５ないし７のいずれかに記載された「プログラム」か（構成要件４Ｏ及び８Ｏの充足性））
〔原告の主張〕
構成要件４Ｏは「請求項１～３のいずれか１項に記載の物流クラウドシステム」、構成要件８Ｏは「請求項５～７のいずれか１項に記載のプログラム」である。被告製品は、本件発明１及び３に記載の「物流クラウドシステム」であり、本件発明５ないし７の「プログラム」である。
したがって、被告製品は、構成要件４Ｏ及び８Ｏを充足する。
〔被告の主張〕
被告製品は、既に主張したとおり、本件発明１ないし３に記載された物流クラウドシステムではなく、また、本件発明５ないし７のいずれかに記載されたプログラムでもない。
したがって、被告製品は、構成要件４Ｏ及び８Ｏを充足しない。
(12) 争点５（被告製品について本件発明１、５の均等侵害が成立するか）〔原告の主張〕
被告製品が本件発明についての文言侵害が成立しないとしても、①右部分が特許発明の本質的部分ではなく、②右部分を対象製品等におけるものと置き換えても、特許発明の目的を達することができ、同一の作用効果を奏するものであって、③右のように置き換えることに、当該発明の属する技術の分野における通常の知識を有する者が、対象製品等の製造等の時点において容易に想到することができたものであり、④対象製品等が、特許発明の特許出願時における公知技術と同一又は当業者がこれから右出願時に容易に推考できたものではなく、かつ、⑤対象製品等が特許発明の特許出願手続において特許請求の範囲から意識的に除外されたものに当たるなどの特段の事情もないときは、右対象製品等は、特許請求の範囲に記載された構成と均等なものとして、特許発明の技術的範囲に属するといえる（最高裁平成１０年２月２４日第三小法廷判決・民集５２巻１号１１３頁参照。以下、「平成１０年最高裁判決」という。）。そして、次のとおり、本件発明１及び５については、均等の第１要件から第５要件を全て充足するから、均等侵害が成立する。
ア 本件発明１及び５について
(ｱ) 第１要件（非本質的部分）
本件発明１及び５と被告製品とで相違点があるとすれば、①本件発明１及び５は、荷物を指定した配送状況要求を行う構成を備えている（１Ｄ、５Ｄ）ところ、被告製品においては荷物ではなく作業者を指定した配送状況要求を行う構成を備えている点（以下「相違点１」という。）、②本件発明１及び５は、荷物ＩＤを指定した現在位置要求を行う構成を備えている（１Ｅ－１、５Ｅ－１）ところ、被告製品においては荷物ではなく作業者を指定した配送状況要求を行う構成を備えている点（以下「相違点２」という。）、③本件発明１及び５は、検索された当該個別の運搬車両の過去の位置情報から移動速度を算出する構成を備えている（１Ｅ－２、５Ｅ－２）ところ、被告製品においてはＶＩＣＳ情報及びプローブ情報などの統計的な情報を用いて移動速度を算出する構成を備えている点（以下「相違点３」という。）である。ところで、均等の第１要件に関して、本件発明１及び５の本質的部分は、従来個別で行われてきた物流管理と顧客管理とを統合した物流クラウドシステム及びプログラムを用いていることにある。本件発明１及び５は、クラウド情報処理基盤の特性を有効に利用し、物流管理と顧客管理とを統合したシステム及びプログラムを用いることで上記課題を解決している。
このように、相違点１ないし３は、本件発明１及び５の本質的部分に関わるものではなく、均等の第１要件を満たす。
(ｲ) 第２要件（置換可能性）
被告製品の構成は、物流管理と顧客管理とを統合するものであるから、本件発明１及び５と同一の作用効果を奏する。
したがって、均等の第２要件を満たす。
(ｳ) 第３要件（置換容易性）
相違点１及び２に関し、本件発明１及び５と被告製品とが配送状況要求において荷物を指定するか作業者を指定するかの違いがあるとしても、いずれも運搬する荷物を特定するに至る情報に過ぎず、配送依頼元が便宜により書き換え可能である。また、相違点３に関しても、ＶＩＣＳは平成８年から供用されており、ＶＩＣＳは平成２７年４月頃からプローブ情報を利用していたのであるから、被告製品の提供開始時点において、本件発明１及び５の構成に置換することは容易であった。したがって、均等の第３要件を満たす。
(ｴ) 第４要件及び第５要件
本件発明１及び５と被告製品との間に、第４要件及び第５要件に該当する事情は存在しないから、均等の第４要件及び第５要件を満たす。
イ 本件発明２及び６について
仮に、本件発明２及び６が荷物を指定した配送状況要求を行う構成を備えている（構成要件２Ｇ及び６Ｇ）のに対し、被告製品が荷物ではなく作業者を指定した配送状況要求を行う構成を備えている点が相違点であるとしても、上記アのとおり、かかる相違点について均等侵害の要件は充足する。
また、本件発明２及び６が納品予定時刻を当該個別の運搬車両の過去の位置情報等を使用して算出する必要がある（構成要件２Ｉ及び６Ｉ）のに対し、被告製品が統計的な情報等を用いて納品予定時刻を算出する必要がある点が相違点であるとしても、上記アのとおり、かかる相違点について均等侵害の要件は充足する。さらに、被告製品が構成要件２Ｊ及び６Ｊを充足しないとしても、上記アのとおり、この点についても、均等侵害の要件は充足する。
ウ 本件発明３及び７について
仮に、被告製品が構成要件３Ｍ及び７Ｍを充足しないとしても、この点は、本件発明１及び５並びに本件発明２及び６を充足しないことと同旨であるから、上記ア及びイのとおり、均等侵害の要件は充足する。
エ 本件発明４及び８について
仮に、被告製品が構成要件４Ｏ及び８Ｏを充足しないとしても、この点は、本件発明１ないし３及び５ないし７を充足しないことと同旨であるから、上記アないしウのとおり、均等侵害の要件は充足する。
〔被告の主張〕
原告の均等侵害の上記主張は、争う。
ア 本件発明１及び５について
(ｱ) 第１要件
特許発明の本質的部分は、特許請求の範囲及び明細書の記載、特に明細書記載の従来技術との比較から認定されるべきであり、明細書に従来技術が解決できなかった課題として記載されているところが、出願時の従来技術に照らして客観的に見て不十分な場合には、明細書に記載されていない従来技術も参酌して、当該特許発明の従来技術に見られない特有の技術的思想を構成する特徴的部分が認定されるべきであって、かかる場合には、特許発明の本質的部分は、特許請求の範囲及び明細書の記載のみから認定される場合に比べ、より特許請求の範囲の記載に近接したものとなり、均等が認められる範囲がより狭いものとなるというべきである。本件において、原告が主張する物流管理と顧客管理とを統合した物流クラウドシステム及びプログラムは、公知文献に開示された従来技術であり、本件明細書の記述は従来技術に照らして客観的に見て不十分な場合に該当する。
そして、これらの従来技術からすれば、本件発明１及び５には従来技術に見られない技術的思想を構成する特有の部分は何ら存在しないから、本件発明１及び５は、そこに記載された事項の全ての組合せ、すなわち特許請求の範囲に記載された内容自体を特徴的部分とするものである。このように本件発明１及び５は、均等侵害の成立する範囲が極めて小さい、言わば実施例限定発明に類するものと評価されるものであるから、対象製品に特許請求の範囲の記載と異なる部分があれば、均等侵害は成立しないことになる。これを前提とすると、相違点１ないし３は、特許請求の範囲で殊更に限定された構成要件とは明らかに異なるのであるから、特許請求の範囲に記載された内容自体が本件発明１及び５の特徴的部分となる以上、均等侵害が成立する余地はない。
したがって、被告製品は、均等の第１要件を充足しない。
(ｲ) 第５要件
相違点２に係る構成要件（荷物ＩＤを指定した現在位置要求（１Ｅ－１、５Ｅ－１））及び相違点３に係る構成要件（配送目的地までに要する時間を検索された当該個別の運搬車両の過去の位置情報から計算する（１Ｅ－２、５Ｅ－２））は、平成２７年３月１２日付け手続補正書による減縮補正で追加された構成要件である。そのため、これらの構成要件を充足しない構成は、本件発明１及び５の出願手続において特許請求の範囲から意識的に除外されたものであるといえる。
したがって、被告製品は、均等の第５要件を充足しない。
イ 本件発明２及び６について
原告が主張する本件発明２及び６と被告製品との相違点は、構成要件２Ｇ及び６Ｇについて構成要件１Ｄ及び５Ｄにおいて主張する内容と、構成要件２Ｉ及び６Ｉについて構成要件１Ｅ－２及び５Ｅ－２において主張する内容と、構成要件２Ｊ及び６Ｊについて構成要件について本件発明１及び５に関して主張する内容とそれぞれ同旨であるところ、上記アのとおり、本件発明１及び５に関して均等侵害の要件を充足するものではないから、本件発明２及び６についても、均等侵害は成立しない。
ウ 本件発明３及び７について
原告が主張する構成要件３Ｍ及び７Ｍと被告製品との相違点は、本件発明１及び５に関して主張する内容と同旨であるところ、上記アのとおり、本件発明１及び５に関して均等侵害の要件を充足するものではないから、本件発明３及び７についても、均等侵害は成立しない。
エ 本件発明４及び８について
原告が主張する構成要件４Ｏ及び８Ｏと被告製品との相違点は、本件発明１及び５に関して主張する内容と同旨であるところ、上記アのとおり、本件発明１及び５に関して均等侵害の要件を充足するものではないから、本件発明４及び８についても、均等侵害は成立しない。
(13) 争点６（被告製品について本件発明１の間接侵害が成立するか）〔原告の主張〕
被告製品には、本件発明の構成要件１ＢないしＤに記載された機能を発揮するための構造化文書（プログラムモジュール。以下「被告プログラムモジュール」という。）が存在するところ、被告プログラムモジュールは、本件発明の課題の解決に不可欠なものであるといえるから、被告において、被告プログラムモジュールを含む被告製品を業として生産し、電気通信回路を通じた提供及び当該提供の申出をする行為は、特許法１０１条２号に規定された行為に該当し、本件発明に係る特許権の侵害（間接侵害）が成立する。
すなわち、仮に、現状の被告プログラムモジュールが、構成要件１Ｄに規定された個別の荷物を指定した配送状況要求を行う構成を備えていないとしても、被告は、そのプレスリリースにおいて、今後荷物の位置をリアルタイムに確認できる機能を備える予定があるとうたっており、被告製品中のプログラムを変更することにより、上記構成を備えることができるし（生産用途要件）、被告プログラムモジュールは、クラウド情報処理基盤において、配送依頼元における物流管理と荷主における顧客管理を連携する機能を提供するものであり、本件発明による課題の解決に不可欠なものである（不可欠性要件）。そして、被告プログラムモジュールは、日本国内において広く一般に流通しているものではない（非汎用性要件）。
さらに、被告は、平成２４年、原告との間で、原告の製品について商談を行っているから、本件発明が特許発明であること、被告プログラムモジュールが本件発明の実施に用いられることを知っていたといえるし、原告代理人の通知により、遅くとも、平成２９年１１月２２日には、主観的要件を満たしていたといえる。〔被告の主張〕
原告の上記主張は、争う。本件発明に係る特許権の侵害（間接侵害）は、成立しない。
まず、間接侵害の成立には、現に特許発明の実施品の生産が行われていることが必要である。ところが、原告は、被告プログラムモジュールによって、構成要件１Ｂないし１Ｄに記載された機能を実現すると主張しているものの、被告プログラムモジュールが構成要件の全てを充足するものとは主張しておらず、被告によって本件発明の実施品の生産が行われていることを前提としていない。そして、被告以外の第三者によっても、本件発明の実施品の生産が行われていないことは明らかであるから、特許法１０１条２号の間接侵害の成立をいう原告の主張は失当である。また、原告は、被告製品中のプログラムを変更することにより、構成要件１Ｄの構成を備えることが可能であるとして、被告プログラムモジュールが本件発明の生産に用いる物に当たると主張するが、プログラムを変更して構成要件を備えることが可能という理由で「その物の生産に用いる物」に該当するとすれば、およそどのようなプログラムであっても、「その物の生産に用いる物」に該当することとなり、特許法１０１条２号の間接侵害が極めて広範に成立することになってしまい、不合理である。仮に、原告が主張するようにプログラムを変更すればよいという前提に立つのであれば、元のプログラムはどのようなものでもよいはずであり、本件発明との関係で原告のいう被告プログラムモジュールが「その発明による課題の解決に不可欠なもの」には該当しないから、間接侵害が成立する余地はない。
(14) 争点７－１（無効理由１（乙６発明を主引例とする進歩性の欠如）の有無）〔被告の主張〕
本件発明は、次のとおり、本件特許の特許出願の原出願日（平成２２年８月３１日）より前の平成１５年９月１２日に公開された乙６発明に基づいて当業者が容易に発明をすることができたものであるから、本件発明は、特許法２９条２項の規定に違反して特許されたものであり、特許無効審判により無効にされるべきものである（特許法１２３条１項２号）。
ア 乙６発明の構成
乙６公報から、以下のとおりの構成が認められる（以下、乙６発明に係る構成を、「乙６ａ」などという。）。
(ｱ) 本件発明１及び５関係
乙６ａ：ネットワークを経由してサーバに要求を行い、サーバ上で処理をさせ、その処理結果の提供を受ける、荷物の輸送を管理するためのシステム及び情報処理装置を当該システムとして機能させるプログラムであって、
乙６ｂ：ネットワークを介して、依頼に係る荷物の運送業務に関連して、当該荷物を運搬する運送用車両を特定する情報を含む運送業務の情報をデータベースに登録する手段と、
乙６ｃ：ネットワークを介して、運送用車両の最新の位置情報及び日時情報を取得して、データベースに登録する手段と
乙６ｄ：運送用車両を指定して行われる運送用車両の位置と卸地の位置を示す地図情報の表示要求を含む運送状況の問合せに応答して、取得した前記位置情報及び日時情報を使用して前記荷物の卸地と運送用車両の現在の位置を表示するための道路地図などの地図情報を取得し、現在の運送用車両と荷物の卸地に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報に合成し、荷送人、荷受人、運送業者に対して回答情報として送付する手段を含み、
乙６ｅ－１：それぞれアクセスキーの発行・通知を受けた荷送人、荷受人（荷受人は荷送人からアクセスキーの通知を受ける必要がある）、運送業者からの、運送用車両を指定した運送状況の問合せを受領すると、
乙６ｅ－２：運送計画の記録されたデータベースの検索を実行して運送用車両の経路などの運行計画の情報を取得し、また、位置情報が記録されたデータベースの検索を実行して、運送用車両の現在位置情報及び日時情報並びに過去の位置情報及び日時情報を取得し、これらの情報を用いて、Ｘ分後の当該車両の位置をシミュレーションにより計算し、
乙６ｅ－３：複数のデータベースの検索結果から作成したデータを応答として表示する（乙６ｅ－２と同様）
乙６ｆ：ネットワークを経由してサーバに要求を行い、サーバ上で処理をさせ、その処理結果の提供を受ける、荷物の輸送を管理するためのシステム及び情報処理装置を当該システムとして機能させるプログラム（乙６ａと同様）
(ｲ) 本件発明２及び６関係
乙６ｇ：運送用車両を指定してデータベースに登録された当該運送用車両の位置情報及び日時情報を検索する手段と、（乙６ｄと同様）
乙６ｈ：卸地及びデータベースを検索して取得された運送用車両の最新の位置情報及び日時情報を使用して地図情報を取得する手段と、（乙６ｄと同様）乙６ｉ：現在の運送用車両の位置と荷物の卸地に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報に合成し、Ｘ分後の当該車両の位置をシミュレーションにより計算し、また、少なくとも運送業者が利用可能な運送用車両ごとの集配スケジュールのリストが作成する手段と
乙６ｊ：を含む、ネットワークを経由してサーバに要求を行い、サーバ上で処理をさせ、その処理結果の提供を受ける、荷物の輸送を管理するためのシステム及び情報処理装置を当該システムとして機能させるプログラム（乙６ａと同様）(ｳ) 本件発明３及び７関係
乙６ｋ：運送用車両に搭載された携帯電話機から定期的な位置情報及び日時情報のアップロードを受け付け、
乙６ｌ：ネットワークを介してウェブブラウザを介した配送状況の提供及び運送計画の作成支援を行う
乙６ｍ：ネットワークを経由してサーバに要求を行い、サーバ上で処理をさせ、その処理結果の提供を受ける、荷物の輸送を管理するためのシステム及び情報処理装置を当該システムとして機能させるプログラム（乙６ａと同様）
(ｴ) 本件発明４及び８関係
乙６ｎ：運送状況の問合せは、荷送人、荷受人、運送業者が行い、運送情報センタは発行元に対し応答を返す（乙６ｄと同様）
乙６ｏ：ネットワークを経由してサーバに要求を行い、サーバ上で処理をさせ、その処理結果の提供を受ける、荷物の輸送を管理するためのシステム及び情報処理装置を当該システムとして機能させるプログラム（乙６ａと同様）
イ 本件発明１及び５の進歩性の欠如
(ｱ) 本件発明１及び５と乙６発明との対比
本件発明１及び５と乙６発明とは、次の点で相違し、その余の点で一致する。
ａ 相違点１
本件発明１及び５は、荷物を指定して当該荷物の運搬車両の位置と納品先の位置を示す地図情報の表示を要求するものであるのに対し、乙６発明は、運送用車両を指定して、運送用車両の位置と卸地の位置を示す地図情報の表示要求を含む運送状況の問合せを行うものである点。
ｂ 相違点２
本件発明１及び５は、荷物の固有の識別子を指定して、当該荷物の運搬車両の現在位置の情報を要求するものであるのに対し、乙６発明は、運送用車両を指定して、当該車両の現在位置の情報を要求するものである点。
ｃ 相違点３
本件発明１及び５は、荷主及び配送依頼元に対し、荷物の現在位置情報を提供するに当たって、荷主及び配送依頼元ごとに異なる処理プロセスを用意したり、アクセスキーの発行、電子メールの発行などの追加の処理を行うことがないものであるのに対し、乙６発明は、「荷主」に該当する荷受人については、運送業務ごとに荷送人から荷受人にアクセスキーの通知を行う必要がある点。
ｄ 相違点４
本件発明１及び５は、運行計画の情報、運搬車両の現在位置情報及び日時情報並びに過去の位置情報及び日時情報を用いて、配送目的地までに要する時間を計算するものであるのに対し、乙６発明は、これらの情報を用いて、Ｘ分後の運送用車両の位置を計算するものである点。
(ｲ) 相違点の容易想到性
本件発明１及び５は、以下に述べるとおり、乙６発明に基づいて当業者が容易に想到することができたものである。
ａ 相違点１及び２の容易想到性
相違点１及び２は、要するに、荷物の運送状況の問合せに当たって、本件発明１及び５では、固有の識別子を用いて荷物を指定するものであるのに対し、乙６発明では、（当該荷物を運送する）運送用車両を指定するものであるという相違点であり、相違点１及び相違点２は、実質的に同一である。
相違点１及び２に係る構成、すなわち、固有の識別子を用いて荷物を指定して当該荷物の運送状況の問合せを行うことは、本件特許出願の原出願日（平成２２年８月３１日）において、当業者において周知の技術であった。
したがって、当業者は、乙６発明に固有の識別子を用いて荷物を指定して当該荷物の運送状況の問合せを行う周知技術を適用して、相違点１及び２に係る構成とすることは容易になし得たことであった。
ｂ 相違点３の容易想到性
相違点３に関し、乙６公報の請求項２２の記載によれば、このようなアクセスキーを用いずに荷送人・荷受人が運送用車両の位置情報を閲覧することができる技術が開示されている。
したがって、当業者において、乙６公報の請求項２２の記載を踏まえ、乙６発明の構成を、位置情報を閲覧するためのアクセスキーの発行・通知を行わない構成、すなわち、「荷主」及び「配送依頼元」ごとに異なる処理プロセスを用意したり、アクセスキーの発行、電子メールの発行などの追加の処理を行うことがない構成（相違点３に係る構成）に変更することは、容易になし得たものであった。
ｃ 相違点４の容易想到性
相違点４に係る構成、すなわち、運行計画の情報、運搬車両の現在位置情報及び日時情報並びに過去の位置情報及び日時情報を用いて配送目的地までに要する時間を計算することは、本件特許出願の原出願日（平成２２年８月３１日）において、当業者において周知の技術であった。
したがって、当業者は、乙６発明に、運行計画の情報、運送用車両の現在位置情報及び日時情報並びに過去の位置情報及び日時情報を用いて配送目的地までに要する時間を計算する周知技術を適用して、相違点４に係る構成とすることは容易になし得たことであった。
ウ 本件発明２及び６の進歩性の欠如
(ｱ) 本件発明２及び６と乙６発明との対比
本件発明２及び６と乙６発明とは、上記相違点１ないし４に加え、次の点で相違し、その余の点で一致する。なお、荷物の指定に関する原告の解釈（運送用車両の指定も荷物の指定に当たる。）を前提とするのであれば、乙６発明では、運送用車両を指定しているのであるから、相違点５は存在しないことになる。
ａ 相違点５
本件発明２及び６は、荷物を指定して、データベースに登録された運送用車両の位置情報及び日時情報を検索する手段を備えるものであるのに対し、運送用車両を指定して、データベースに登録された運送用車両の位置情報及び日時情報を検索する手段を備えるものである点。
ｂ 相違点６
本件発明２及び６は、運送車両の現在位置情報及び日時情報並びに過去の位置情報及び日時情報を用いて、「納品予定時刻」を計算するものであるのに対し、乙６発明は、これらの情報を用いて、Ｘ分後の運送用車両の位置を計算する点。
ｃ 相違点７
本件発明２及び６は、現在配送中の運搬車両の集配リストに納品予定時刻を顧客または配送依頼元が参照可能な形式で追加して配送状況テーブルを作成する手段を備えるものであるのに対し、乙６発明では、少なくとも運送業者が利用可能な運送用車両ごとの集配スケジュールのリストが作成されているが、当該リストに納品予定時刻は追加されず、また、これを荷受人及び荷送人が利用可能であるかは不明である点。
(ｲ) 相違点の容易想到性
本件発明２及び６は、以下に述べるとおり、乙６発明に基づいて当業者が容易に想到することができたものである。
ａ 相違点１ないし４の容易想到性
上記イ(ｲ)において述べたとおり、相違点１ないし４に係る構成は、当業者が容易に想到することができたものであった。
ｂ 相違点５の容易想到性
相違点５の内容は、相違点１及び２と実質的に同じ内容であり、上記イ(ｲ)ａにおいて述べたところから明らかなとおり、相違点５に係る構成は、当業者が容易に想到することができたものであった。
ｃ 相違点６の容易想到性
相違点６の内容は、相違点４と実質的に同じ内容であり、上記イ(ｲ)ｃにおいて述べたところから明らかなとおり、相違点６に係る構成は、当業者が容易に想到することができたものであった。
ｄ 相違点７の容易想到性
相違点７に関し、上記イ(ｲ)ｃにおいて述べたとおり、運行計画の情報、運送用車両の現在位置情報及び日時情報並びに過去の位置情報及び日時情報を用いて配送目的地に到着する時刻（納品予定時刻）を計算する技術は周知であった。そして、納品予定時刻は運送用車両ごとの集配スケジュールに関わるものであることから、乙６発明に当該周知技術を適用する際に、当該集配スケジュールのリストに納品予定時刻を追加することは、当業者であれば当然に行うことである。また、当該集配スケジュールのリストを、乙６発明において位置情報の要求をすることができ、納品予定時刻を知ることができる荷受人及び荷送人に利用可能とするかどうかは、当業者が必要に応じ適宜選択する設計事項である。
したがって、当業者は、相違点７に係る構成とすることは容易になし得たことであった。
エ 本件発明３及び７の進歩性の欠如
(ｱ) 本件発明３及び７と乙６発明との対比
本件発明３及び７と乙６発明とは、請求項１に記載の物流クラウドシステム及び請求項５に記載のプログラムとの関係では上記相違点１ないし４、請求項２に記載の物流クラウドシステム及び請求項６に記載のプログラムとの関係では上記相違点１ないし７の点で相違し、その余の点で一致する。
(ｲ) 相違点の容易想到性
上記イ(ｲ)において述べたとおり、相違点１ないし４に係る構成は、当業者が容易に想到することができたものであった。また、上記ウ(ｲ)において述べたとおり、相違点５ないし７に係る構成は、当業者が容易に想到することができたものであった。したがって、本件発明３及び７は、乙６発明に基づいて当業者が容易に想到することができた。
オ 本件発明４及び８の進歩性の欠如
(ｱ) 本件発明４及び８と乙６発明との対比
本件発明４及び８と乙６発明とは、請求項１に記載の物流クラウドシステム及び請求項５に記載のプログラムとの関係では相違点１ないし４、請求項２に記載の物流クラウドシステム及び請求項６に記載のプログラムとの関係では相違点１ないし７、請求項３に記載の物流クラウドシステム及び請求項７に記載のプログラムとの関係では相違点１ないし４又は相違点１ないし７の点で相違するほか、次の点で相違し、その余の点で一致する。すなわち、本件発明４及び８は、荷物を指定して当該荷物を運搬している車両の位置と納品先の位置を示す地図情報の表示を要求するものであるのに対し、乙６発明は、運送用車両を指定して、運送用車両の位置と卸地の位置を示す地図情報の表示要求を含む運送状況の問合せを行うものである点で相違する（相違点８）。
(ｲ) 相違点の容易想到性
本件発明４及び８は、以下に述べるとおり、乙６発明に基づいて当業者が容易に想到することができたものである。
ａ 相違点１ないし７の容易想到性
上記イ(ｲ)において述べたとおり、相違点１ないし４に係る構成は、当業者が容易に想到することができたものであった。また、上記ウ(ｲ)において述べたとおり、相違点５ないし７に係る構成は、当業者が容易に想到することができたものであった。
ｂ 相違点８の容易想到性
相違点８の内容は、相違点１と全く同じ内容であり、上記イ(ｲ)ａにおいて述べたところから明らかなとおり、相違点８に係る構成は、当業者が容易に想到することができたものであった。
〔原告の主張〕
ア 乙６発明の構成
乙６発明は、被告が主張する乙６ａないしоの構成を備えていない。すなわち、乙６発明においては、運送業者側に運送業務管理用の運送業者サーバが設けられ、同サーバがウェブサーバや入札管理サーバを含む運送情報センタと通信を行っており、運送業者は、かかるサーバを直接操作しているのであって、ネットワークを経由してサーバに要求を行っていないから、乙６ａ、乙６ｆ、乙６ｊ、乙６ｍ、乙６оの構成を備えていない。また、乙６発明においては、運送用車両の情報は、ネットワークを通じてデータベースに登録されるのではなく、運送業者に設置された運送業者サーバに通信が行われたのち、運送情報センタに対して送信が行われており、ネットワークを介して運送用車両の情報が運送情報センタに送信されていないから、乙６ｂ、乙６ｃ、乙６ｋ、乙６ｍの構成を備えていない。さらに、乙６発明において、アクセスキーが使用されるという点を除き、荷送人及び荷受人がどのような問合せを行い、どのような情報が得られるのかが開示されておらず、乙６ｄ、乙６ｅ－１、乙６ｇ、乙６ｈ、乙６ｎの構成を備えているということはできない。加えて、被告が主張する乙６ｅ－２の構成についても、それと同じことが当てはまる上、乙６発明については、入札データベース、応札データベース及び車両データベースの３つのデータベースが存在することはうかがえるものの、３つのデータベースにどのような情報が蓄積され、指令が出された場合にどのようにデータベースの検索が実行され、どのような結果が得られるのか、一切不明であり、乙６ｅ－２及び乙６ｅ－３について、被告の主張する構成が備えられているということはできない。続いて、乙６公報で開示されているのは、入札をするための運送計画に規定された到着時刻を落札時に、そのまま図１９の形式のスケジュールに追加するというものであり、限定された範囲でのスケジュール作成でしかないから、乙６ｉの構成を備えていない。さらに、乙６公報の明細書の段落【００４２】には、運送業者側には事務所などの運送業務管理用の運送業者サーバが設けられ、ウェブサーバや入札管理サーバと通信を行う旨の記載がある。したがって、インターネットを経由してホームページを閲覧しながら利用するシステムではないし、配送状況の提供についても、運送計画の作成支援については、単に荷送人が運送計画を作成して、運送情報センタに送信しているのみであり、運送計画の作成を支援する機能について記載がないのであるから、乙６ｌの構成を備えていない。
イ 本件発明と乙６発明との対比
乙６発明は、次のとおり、少なくともクラウドシステムではない。
まず、乙６発明は、クラウドシステムが有する特徴②（幅広いネットワークアクセス）を備えていない。乙６発明においては、インターネットなどのネットワークと無線通信や携帯電話網などのネットワークを併存させているが、無線通信や携帯電話網などのネットワークは、デジタルデータ通信能力を利用したデータパケット通信であり、特定の通信会社が提供するサービスであって、携帯電話が異なればネットワークも異なるし、そのことは、ウェブと無線通信や携帯電話網とで異なるテキストファイルを作成する必要があることを意味する。クラウドシステムでは、ＨＴＴＰプロトコル方式やＦＴＰプロトコル方式にて情報通信を行うため様々なシン及びシッククライアントプラットフォームからの利用が可能である。したがって、乙６発明は、上記特徴②を備えていない。
次に、乙６発明は、クラウドシステムが有する特徴③（リソースの共有）を備えていない。乙６公報の明細書の【図３】に示されているとおり、乙６発明においては、運送業者サーバを運送業者ごとに設置する必要がある。運送業者代理サーバを設ける場合であっても、同サーバを運送業者ごとに設置しなければならず、サービス提供者のコンピューティングリソースが集積され、複数のユーザにマルチテナントモデルを利用して提供されていないことは明らかである。また、乙６公報の明細書には、入札データベース及び応札データベースにどのような情報が格納され、どのような処理が行われるか全く記載がなく、複数のデータベースを共用するとの構成は示されていない。したがって、乙６発明は、上記特徴③を備えていない。さらに、乙６発明は、クラウドシステムが有する特徴④（スピーディな拡張性）を備えていない。乙６発明においては、運送業者ごとに運送業者サーバ又は運送業者代理サーバを設置する必要があり、運送業者が増えるたびに、これらのサーバを設置する必要があるし、入札に関連した求車情報の閲覧及び応札、落札関係の情報の授受については、インターネットなどのネットワークを利用し、車両位置などの運用に関する情報の授受については無線通信や携帯電話網などのネットワークを利用して通信を行っており、このような状況では、無線通信や携帯電話網ごとにウェブサーバを構築する必要がある。したがって、乙６発明が、到底、上記特徴④を備えているとはいえない。
ウ 相違点７について容易想到ではないこと
被告が本件発明と乙６発明との相違点７として主張する相違点は、当業者において容易想到とはいえない。すなわち、乙６発明においては、運送業者ばかりではなく、荷送人や荷受人が利用可能な運送車両ごとの集配スケジュールが作成されるのではなく、限定された範囲でスケジュールが作成され、集配スケジュールのリストには、予め設定された到着予定時刻が記載されるのみであり、本件発明のように動態データベースを含むデータベースから取得した情報に基づき算出された到着予定時刻ではない。乙６発明は、荷送人により予め設定された到着予定時刻を記載する構成を開示するのみで、同発明から、動態データベースを含むデータベースから取得した情報に基づき、リアルタイムで到着予定時刻を記載する構成とすることは、当業者において容易想到ではない。
(15) 争点７－２（無効理由２（明確性要件違反）の有無）
〔被告の主張〕
本件発明は、以下のとおり、その内容が不明確であり、本件発明に係る特許請求の範囲の記載は、特許法３６条６項２号の要件（以下「明確性要件」という。）に適合するものではない。
したがって、本件発明は、同号の規定する明確性要件を満たしていない特許出願にされたものであるから、特許無効審判により無効にされるべきものである（特許法１２３条１項４号）。
ア 無効理由２－１（「配送依頼元」に関する明確性要件違反）について本件発明１の特許請求の範囲には、「共通のインタフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、」（構成要件１Ｅ－１）と記載されている。
「配送依頼元」との用語は、物流業界において一般的に用いられる用語ではないところ、本件明細書には「配送依頼元」の意義についての記載はない。
原告は、「配送依頼元」が「物流に関わる者のうち、集配を指令する者で、荷主に該当しない者」を指すと主張するが、本件明細書の段落【００１９】において「集配を管理する物流者」という別の用語が用いられており、「配送依頼元」を原告の主張するような意義と解することはできない。
したがって、「配送依頼元」が何を指し示すのかは不明確であり、明確性要件に適合しない。
本件特許２ないし４は、本件発明１の従属項であるから、当然、本件発明２ないし４の特許請求の範囲の記載も明確性要件に適合しない。本件発明５についても、その特許請求の範囲に「配送依頼元」との用語が用いられており、本件発明１と同様の理由で、本件発明５の特許請求の範囲の記載は明確性要件に適合しない。本件発明６ないし８は、本件特許５の従属項であるから、当然、本件発明６ないし８の特許請求の範囲の記載も明確性要件に適合しない。
イ 無効理由２－２（「共通のインタフェースを介して」に関する明確性要件違反）について
本件発明１の特許請求の範囲には、「共通のインタフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、」（構成要件１Ｅ－１）と記載されている。
「インタフェース」との用語は、本件明細書において、「ネットワークインタフェース」（段落【００２９】）、「ストレージインタフェース」（段落【００３３】）、「無線ネットワークインタフェース」（段落【００３７】）、「ソケットインタフェースおよび無線ネットワークインタフェース」及び「ネットワークインタフェース」（段落【００３９】）、「ネットワークインタフェース」及び「ソケットインタフェース」（段落【００４１】）、「通信インタフェース」、「無線通信インタフェース」及び「ソケットインタフェース」（段落【００５９】）、「通信インタフェース」及び「ソケットインタフェース」（段落【００７６】）、「通信インタフェース」（段落【００９０】）、「グラフィカルユーザインタフェース」（段落【００９６】）と様々な形で用いられており、特許請求の範囲に記載された「インタフェース」が、このうちのいずれの意味で用いられているか又はこれらと異なる意味で用いられているかは、特許請求の範囲の記載及び本件明細書を見ても全く不明である。
また、原告は、「インタフェース」の用語について、本件訴訟においても、「ウェブブラウザ」であるとか、「物流サーバとクライアントが情報通信を行う際の方式」を意味するなどと主張しているほか、出願過程の平成２７年１０月７日付け意見書では、「荷主および配送依頼元ごとに異なる処理プロセスを用意したり、アクセスキーの発行、電子メールの発行などの追加の処理を行うことなく、効率的に提示すること」が可能であることをもって「共通のインタフェース」と主張しているように思われ、その時々で全く異なる意味で用いており、その主張は変遷している。このように原告の主張が変遷していること自体が、「インタフェース」との用語が指し示す内容が極めて不明確であることの証左である。
また、「共通のインタフェース」とは、「荷主」と「配送依頼元」に「共通」する「インタフェース」であるところ、上記のとおり、「配送依頼元」の指し示す内容も不明確である。
したがって、「共通のインタフェース」が何を指し示すかは不明確であり、明確性要件に違反する。本件発明２ないし８についても、同様のことがいえる。〔原告の主張〕
ア 無効理由２－１（「配送依頼元」に関する明確性要件違反）について被告は、「配送依頼元」について不明確である旨主張するが、「配送依頼元」の意義が明確であることは、前記(15)で主張したとおりであり、本件発明の構成要件に用いられている「配送依頼元」に明確性を欠くところはない。
イ 無効理由２－２（「共通のインタフェースを介して」に関する明確性要件違反）について
被告は、「インターフェース」について、本件明細書において「…インターフェース」という用語が列挙されていることを指摘して、その内容が不明確であると主張するが、被告が指摘する「…インターフェース」という用語は、もともと「インターフェース」から派生してできたものであり、「インターフェース」の語義と異なる用い方をされているものはない。したがって、「…インターフェース」という用語が用いられていることをもって、本件発明の構成要件に用いられている「インターフェース」が不明確であることにはならず、明確性要件に欠ける点はない。
(16) 争点７－３（無効理由３（サポート要件違反）の有無）
〔被告の主張〕
本件発明は、本件明細書の発明の詳細な説明に記載されたものではなく、本件発明の特許請求の範囲の記載は、サポート要件に適合するものではない。したがって、本件発明は、同号の規定するサポート要件を満たしていない特許出願に対してされたものであるから、特許無効審判により無効にされるべきものである（特許法１２３条１項４号）。
ア 無効理由３－１（「共通のインタフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、」に関するサポート要件違反）について
本件発明１の特許請求の範囲には、「配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答として送付する手段と」（構成要件１Ｄ）、「共通のインタフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、」（構成要件１Ｅ－１）との記載があるところ、そもそも本件明細書において、「配送依頼元」については、特許請求の範囲の記載を引き写した箇所を除いて記載が存在しない。また、本件明細書段落【００９７】の「（２）配送状況要求」が「現在位置要求」に当たるものと考えられるが、同段落のその他の箇所を見ても、「荷主」と「配送依頼元」に「共通」する「インタフェース」を介して現在位置要求が行われることについての記載は一切存在しない。
したがって、特許請求の範囲に記載された本件発明１は、そもそも発明の詳細な説明に記載されておらず、サポートの形式的要件すら満たしていない。本件発明２ないし８も、同様のことがいえる。
イ 無効理由３－２（（原告の解釈を前提とした）「過去の位置情報」に関するサポート要件違反）について
原告は、「過去の位置情報」につき、車両の過去の位置情報を意味し、車両については、検索された運搬車両（構成要件１Ｅ－２及び構成要件５Ｅ－２）に限定されるものではないことを前提に、「過去の位置情報」とは、「検索された運搬車両」の「過去の位置情報」であってもよいし、不特定の走行車から収集される「過去の位置情報」であってもよいとする。しかし、正しい「過去の位置情報」の解釈は、既に指摘したとおりであり、この原告の解釈は誤っている。
万一、原告の主張する「過去の位置情報」の解釈が採用されたとしても、本件明細書には、「検索された運搬車両」（荷物ＩＤに対応する荷物を運搬する車両）の「過去の位置情報」を用いて配送目的地までに要する時間を計算していることについての記載しかなく、原告が主張する（検索された運搬車両以外の不特定の車両も含む）およそ「車両」の過去の位置情報を用いた配送目的地までに要する時間の計算方法については何らの記述もない。
したがって、原告の主張する「過去の位置情報」の解釈を前提とすると、本件明細書にはそのような「過去の位置情報」を用いた配送目的地までに要する時間の計算方法について何らの記載もないことから、特許請求の範囲に記載された発明が発明の詳細な説明に記載されておらず、サポートの形式的要件を満たしていない。上記のとおり、原告の「過去の位置情報」に関する解釈を前提とすると、本件発明１の特許請求の範囲の記載はサポート要件に適合しない。本件発明２ないし８についても、同様のことが当てはまる。
ウ 無効理由３－３（（原告の解釈を前提とした）「クラウドシステム」に関するサポート要件違反）について
原告は、特徴①～⑤を備えるもののみが「クラウドシステム」であると主張しているが、正しい「クラウドシステム」の解釈は、既に指摘したとおりであり、原告の解釈は誤っている。
万一、原告の主張する「クラウドシステム」の解釈が採用されたとしても、本件特許の特許請求の範囲の記載及び本件明細書の記載には、「クラウドシステム」の用語についての説明は一切なく、原告が主張する特徴①～⑤に関する説明もない。そして、原告の主張によれば、「クラウドシステム」である時点で当然に特徴①～⑤を備えるということになるが、むしろ、本件明細書の段落【００２２】では、クラウドシステムである本件発明の実施形態においてクライアントサーバーアプリケーションを実装することも許容されており、これは特徴②を満たすものではなく、原告の「クラウドシステム」の意義に関する主張とは整合しない記載がある。したがって、原告の主張する「クラウドシステム」の解釈を前提とすると、本件明細書にはそのような「クラウドシステム」について何らの記載もないことから、特許請求の範囲に記載された発明が発明の詳細な説明に記載されておらず、サポートの形式的要件を満たしていない。
上記のとおり、原告の「クラウドシステム」に関する解釈を前提とすると、本件発明１の特許請求の範囲の記載はサポート要件に適合しない。本件発明２ないし８も、同様のことが当てはまる。
〔原告の主張〕
ア 無効理由３－１（「共通のインタフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、」に関するサポート要件違反）について
本件明細書には、「配送依頼元」に該当する「集配を管理する物流者」が記載されている。また、本件明細書には、発注端末と物流管理サーバの通信プロトコル及び物流端末と物流管理サーバの通信プロトコルの両方がＨＴＴＰプロトコルを用いることが記載されており（【００２１】、【００２２】）、また、本件明細書に記載されている【図２３】ないし【図２５】は、配送依頼元の物流端末に表示される画面であって、これらの画面は、インターネットエクスプローラーというブラウザソフトウェアを用いて使用され、当該ソフトウェアにおいて情報通信が行われる際にＨＴＴＰプロトコルという通信方式が用いられている。したがって、本件明細書上、発注端末と物流管理サーバ、配送依頼元側の端末に相当する物流端末と物流管理サーバは、それぞれ、ＨＴＴＰプロトコルという通信方式を利用して通信が行われていることは明らかであり、「共通のインタフェースを介して前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領すると、」という構成要件にサポート要件違反はない。
イ 無効理由３－２（（原告の解釈を前提とした）「過去の位置情報」に関するサポート要件違反）について
「過去の位置情報」とは、車両の過去の位置情報を意味し、「車両」については、「検索された運搬車両」に限定されない。このことは、不特定の車両の過去の位置情報に関する記載があること（【００９１】）や、特定の車両に紐づけられずに渋滞情報などの情報が取得されることの記載があること（【００９４】）から、ＶＩＣＳ情報等を使用することがあることが記載されている。
ウ 無効理由３－３（（原告の解釈を前提とした）「クラウドシステム」に関するサポート要件違反）について
本件明細書には、「クラウドシステム」について、「…図２の物流管理サーバの機能は、クラウドのコンピューティング基盤上に構成することができる」と明確に記載されている（【００３４】）し、クラウドシステムで用いられているアクセス管理を使用していることについても明確に記載されている（【００４３】）。このことは、本件明細書の【図２】において、全てのアプリケーション手段が、データアクセス部によるアクセス制御の下で、受注ＤＢ、動態ＤＢ、運行ＤＢにアクセスしていることからも明らかである。
(17) 争点７－４（無効理由４（補正に係る新規事項の追加違反）の有無）〔被告の主張〕
本件発明は、以下に述べるとおり、特許法１７条の２第３項に規定する要件（新規事項の追加の禁止）を満たしていない補正を経た出願に対して特許されたものであった。
したがって、本件特許１ないし８は、特許無効審判により無効にされるべきものである（特許法１２３条１項１号）。
ア 無効理由４－１（「共通のインタフェースを介して」に関する新規事項の追加）について
「共通のインタフェースを介して」という構成は、平成２７年１０月７日付けの補正で追加されたものであるところ、「共通のインタフェースを介して」という構成は発明の詳細な説明に記載がないものであるから、当該補正は特許法１７条の２第３項に規定する要件を満たしていない補正である。
したがって、本件発明１に係る特許は、特許法１７条の２第３項に規定する要件を満たしていない補正を経た出願に対して特許されたものであり、特許法１２３条１項１号に定める無効理由が存在する。本件発明２ないし８についても、同じである。
イ 無効理由４－２（（原告の解釈を前提とした）「過去の位置情報」に関する新規事項の追加）について
「過去の位置情報」という構成は、平成２７年３月１２日付けの補正で追加されたものであるところ、原告のクレーム解釈を前提とすると、「過去の位置情報」という構成は発明の詳細な説明に記載がないものであるから、当該補正は特許法１７条の２第３項に規定する要件を満たしていない補正である。
したがって、本件発明１に係る特許は、特許法１７条の２第３項に規定する要件を満たしていない補正を経た出願に対して特許されたものであり、特許法１２３条１項１号に定める無効理由が存在する。本件発明２ないし８についても、同じである。
〔原告の主張〕
上記(16)において主張したとおり、「共通のインターフェースを介して」及び「過去の位置情報」について、本件明細書に具体的な構成が記載されているのであるから、これらの文言を補正により加えたことが、新規事項の追加に当たらないことは明らかである。
(18) 争点８（差止めの必要性の有無）
〔原告の主張〕
原告は、被告に対し、本件特許権の侵害について、二度にわたり通知を行ったが、被告はこれに誠実に対応せず、また、調停手続においても、何らの対応もしなかったため、原告は、やむなく本件訴訟を提起するに至った。また、被告製品の変更等により、本件特許権が侵害されるおそれもあるから、被告の行為については、差止めの必要性が存する。
〔被告の主張〕
原告の上記主張は、争う。
(19) 争点９（原告の損害の有無及びその額）
〔原告の主張〕
ア 実施料相当額
被告が平成２４年５月２９日から現在に至るまで、被告製品を販売等したことにより得た売上額は、１億円を下らない。
そして、本件発明の技術分野、被告製品の市場、コスト構造、類似事例、実務慣行に鑑みれば、本件発明の実施について相当な実施料率は、１０パーセントを下るものではない。
したがって、原告は、被告に対して少なくとも１０００万円の損害賠償請求権を有している。
イ 弁護士費用
本件訴訟追行に当たって、相当な弁護士費用は、上記実施料相当額の１０パーセントの１００万円が相当である。
〔被告の主張〕
原告の上記主張は、争う。
第３ 当裁判所の判断
１ 本件発明について
(1) 本件発明の特許請求の範囲の記載は、前記第２の１(2)イのとおりである。そして、本件明細書には、次の記載がある。
ア 技術分野
「本発明は、ネットワークを介した物流管理に関し、より詳細には、物流の状態をリアルタイムで取得することにより、物流管理を可能とし、さらに最新の荷物の配送状況を荷主に報告する、物流クラウドシステムおよびプログラムに関する。」（【０００１】）
イ 背景技術
「近年、ネットワーク基盤が普及し、また移動体通信も普及していることから、多くの車両は、GPS(Global Positioning System)端末を搭載し、その位置や目的地などに関する情報を取得している。この様な状況は、陸上物流の主体を担うトラックなどの貨物車両についても同様である。…」（【０００２】）
「上述したネットワーク環境を介して取得できる情報は、これまでも物流の計画立案、実績などの管理、貨物車両の運行管理のために利用されている。…」（【０００３】）
ウ 発明が解決しようとする課題
「上述したように、貨物車両に搭載した GPS などの位置情報を利用して物流管理を行うシステムや方法は多数提案されている。中でも上述した特許文献１～７は、GPS などの車載型端末から取得した情報を物流業者のためにだけ利用することを目的とするものである。しかしながら、運搬する荷物は、そもそも荷主による依頼を受けて物流業者が運搬するものだから、特定の荷物を積載した貨物車両が現在何処でどのような状況になっているかについての情報は、物流業者ばかりではなく、荷主における荷物管理および営業管理のためにも重要な情報を提供することができる。」（【００１０】）
「このためには、位置情報を管理するサーバ、運行状況／積載情報を管理するサーバ、および荷主管理を行うためのサーバなど複数のサーバが取得した情報を組み合わせて目的に適合する新たなコンテンツを生成することが必要とされるが、特許文献１～７では、複数サーバが取得したデータを組み合わせて異なるデータを生成し、荷主に対して提供することを課題とするものではない。この主な理由としては、貨物／物流管理と、荷主／顧客管理とは、独立したサーバまたはウェブシステムで提供されるものであり、物流管理の情報を荷主に提供する場合、情報漏洩やデータ同期化などの問題からシステムが複雑化することもその１つの要因と考えられる。」（【００１１】）
「本発明は、上述した従来技術に鑑みてなされたものであり、本発明は、貨物車両の運搬状況を管理するために取得した情報を使用して、物流管理を行うとともに、当該情報から荷主毎に現在の荷物の配送状況情報を作成し、荷主に通知することを可能とする物流クラウドシステムおよびプログラムを提供することを課題とする。」（【００１２】）
エ 課題を解決するための手段
「本発明では、上記課題を解決するために、荷物の輸送を管理するための物流クラウドシステムであって、ネットワークを介して配送するべき荷物の配送依頼に関連して当該荷物を運搬するための運搬車両を特定する情報を少なくとも運行計画データとして運行データベースに登録する手段と、前記ネットワークを介して荷物を輸送している運搬車両の最新の位置情報および日時情報を取得して、運行ログとして動態データベースに登録する手段と、配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答として送付する手段とを含む、物流クラウドシステムが提供される。」（【００１３】）
「さらに、物流クラウドシステムは、登録した前記配送状況要求で指定された荷物について前記運行ログを検索する手段と、前記納品先および検索された運行ログで指定される前記運搬車両の最新の位置を参照して地図情報を取得する手段と、前記取得した地図情報に対して前記納品先と最新の位置としてそれぞれ異なる図形オブジェクトを合成し、前記運行ログにおける履歴および前記最新の位置を使用して納品予定時刻を計算し、現在配送中の前記運搬車両の集配リストに前記納品予定時刻として顧客または配送依頼元が参照可能な形式で追加して配送状況テーブルを作成する手段とを含む、ことができる。」（【００１４】）
「前記物流クラウドシステムは、前記運搬車両が搭載するモバイル端末からの定期的な前記位置情報および日時情報のアップロードを受け付け、前記ネットワークを介してブラウザ手段を介した配送状況の提供および運行計画の作成支援を行うことができる。」（【００１５】）
「前記配送状況要求は、荷主または配送依頼元が発行し、前記物流クラウドシステムは、配送状況要求の発行元に応答を返す、物流クラウドシステム。」（【００１６】）「また、本発明によれば、情報処理装置を、荷物の輸送を管理するための物流クラウドシステムとして機能させるための情報処理装置実行可能なプログラムであって、情報処理装置を、ネットワークを介して配送するべき荷物の配送依頼に関連して当該荷物を運搬するための運搬車両を特定する情報を少なくとも運行計画データとして運行データベースに登録する手段、前記ネットワークを介して荷物を輸送している運搬車両の最新の位置情報および日時情報を取得して、運行ログとして動態データベースに登録する手段、配送状況要求に応答して、取得した前記位置情報および日時情報を使用して前記荷物の納品先と、前記運搬車両の最新の位置とを表示するための地図情報を取得し、前記納品先および前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて前記地図情報上に合成し、荷主または配送依頼元に応答として送付する手段として機能させる、プログラムが提供される。」（【００１７】）
オ 発明を実施するための形態
「…図１は、本実施形態の物
流管理システム１００の概略
図である。物流管理システム
１００は、ネットワーク１１
０を介して遠隔的に荷主が配
送を依頼し、荷主からの依頼
に対応して物流業者が集配を
指令し、さらに集配状況のモ
ニタを可能としている。物流
管理システム１００は、荷主
サイトに設置された発注端末１１２と、集配を管理する物流者サイトに設置された物流端末１１４とを含んでいる。」（【００１９】）
「発注端末１１２は、運送するべき荷物を指定して物流管理サーバ１１６に登録することにより、荷物の運送を依頼する。本実施形態において。用語「荷主」とは、荷物に対する権利を有する人、団体、または企業を意味し、用語「物流者」とは、荷物の運搬を実際に行う、運送業者を意味する。したがって、例えば一般ユーザが、例えば通販会社で商品を購入し、通販会社が物流者に荷物の搬送を依頼する場合、「荷主」には、荷物の購入者または通販会社などの仲介業者を含む。」（【００２０】）「発注端末１１２は、物流管理サーバ１１６に対して荷物の配送状況を問い合わせ、物流管理サーバ１１６から、当該荷物の現在位置、配送完了予定時刻など現在の配送状況を略リアルタイムで取得する。また、物流端末１１４は、物流管理サーバ１１６に対して発注端末１１２からの新規な荷物集配の依頼の有無を問い合わせ、物流管理サーバ１１６に対して荷物の集配のための運行管理および要員管理などを依頼している。」（【００２１】）
「発注端末１１２および物流端末１１４は、パーソナルコンピュータやワークステーション、またはサーバコンピュータから構成することができ、中央処理装置（【図１】
CPU）、ＲＡＭ、ＲＯＭ、ハードディスクなどを実装し、適切なオペレーティングシステム（ＯＳ）の制御の下でオブジェクト指向プログラミング言語やレガシープログラミング言語などを実行し、各種処理を実行するための機能手段を提供している。また、発注端末１１２、物流端末１１４は、物流管理サーバ１１６に対してアクセスするための専用のクライアント－サーバアプリケーションを実装することもできるが、より好ましい実施形態では、発注端末１１２、物流端末１１４は、InternetExplorer（登録商標）、Mozilla（登録商標）、Opera（登録商標）、FireFox（登録商標）、Chrome（登録商標）などのブラウザソフトウェアを搭載し、物流管理サーバ１１６に対して、HTTP プロトコルや FTP プロトコルを使用してアクセスし、JAVA（登録商標）、AVAAPPLET（登録商標）、JAVASCRIPT（登録商標）などのアプリケーションプログラムを介して各種サービスの提供を受ける構成とされている。」（【００２２】）「物流管理サーバ１１６は、それぞれ発注端末１１２および物流端末１１４からの発注要求または運行管理要求を受領し、発注要求に基づいて集配計画の作成を支援する。物流管理サーバ１１６は、現在集配業務を行っている運搬車両に搭載されたモバイル端末１３０、１４０から、それぞれの運搬車両１３２、１４２の集配状況を、無線ネットワークを介した通信により取得し、略リアルタイムで集配状況の更新を行っている。本実施形態で、「略リアルタイム」とは、モバイル端末１３０、１４０から定期的にその位置情報および日時情報が送付され、更新されることを意味する。」（【００２３】）
「物流管理サーバ１１６は、このために、受注ＤＢ１１８、動態ＤＢ１２０および運行ＤＢ１２２を管理しており、発注端末１１２からの受注、運搬車両の集配状況の管理、および新規受注に基づく運行計画作成支援を行っている。物流管理サーバ１１６は、上述した処理を実行するためにＷｅｂサーバおよびＦＴＰサーバとして機能し、さらにリレーショナルデータベース（ＲＤＢ）やオブジェクト指向データベース（ＯＯＤＢ）などのデータベースアプリケーションを実装し、物流に関連するデータ取得要求を取得し、ＳＱＬ(Structured Query Language)や、ＸＭＬ(eXtensible Markup Language)などを利用して、要求を処理し、それぞれ発注端末１１２または物流端末１１４に対して要求された情報を提供している。」（【００２４】）
「図２は、本実施形態の
物流管理サーバ１１６の
機能ブロック２００を示
す図である。物流管理サ
ーバ１１６は、上述した
ようにＷｅｂサーバとし
て実装されており、ネッ
トワークインタフェース
ＮＩＣを介してインター
ネットといったネットワ
ーク１１０から各種情報
および要求を受領する。
さらに物流管理サーバ１
１６は、運行管理部２１０と、動態管理部２２０と、発注管理部２３０を備えている。運行管理部２１０は、発注端末からの集配要求を受領し、特定の物流端末１１４からのアクセスに応じて運送業者の集配資源情報を参照して配送計画作成を支援する。また、運行管理部２１０は、運行ＤＢ１２２に作成した配送計画を登録し、管理している。」（【００２９】
「動態管理部２２０は、運搬車両１３２、１４２から送付される位置情報、時刻情報などを受領して動態ＤＢ１２０に登録された特定の運搬車両の現在情報を更新する。動態ＤＢ１２０は、発注端末１１２から特定の運搬車両が担当する荷物がどのような配送状況にあるかの問合わせを受領すると、運搬車両の配送状況を検索して、後述する発注管理部２３０に検索された情報を渡すことで、発注管理部２３０【図２】
による対応する地図情報や道路情報などの取得、現在位置や予定配送時刻などを表示させるためのオブジェクトの地図データへの合成、集配計画テーブルの生成および地図データへの合成などの処理を可能とさせている。」（【００３０】）「また、モバイル端末１３０からの運行ログを受領した動態管理部２２０は、受領したデータを処理し、その結果を運行ログデータとして動態ＤＢ１２０に登録し、他の機能部からの運行ログデータへのアクセスを可能とする。発注管理部２３０が発注端末１１２からの状況確認要求を受領すると、状況確認要求から荷物ＩＤを取得し、ステップＳ６０６で、当該荷物ＩＤを検索キーとして運行ＤＢ１２２、動態ＤＢ１２０を検索し、状況確認テーブルを作成する。さらに発注管理部２３０は、動態ＤＢ１２０に格納されている現在の位置情報と、運送先の位置情報とを参照して、地図データを検索し、これらの情報を統合して、状況確認用の HTML、XHTML、または XML といった構造
化文書を作成する。発注
管理部２３０は、作成し
た構造化文書を発注端
末１１２に送付して、状
況確認要求に対する応
答する。」（【００５７】）
「図１８は、本実施形
態の発注管理部２３０
の機能ブロックを示す。
本実施形態の発注管理部２３０は、発注端末１１２との間で、ＨＴＴＰまたはＨＴＴＰＳプロトコルを使用するデータトランザクションを行っており、物流管理サーバ１１６のＷｅｂサーバ機能として実装されている。発注管理部２３０は、通信インタフェース１８１０を備えており、ソケット通信を使用して発注端末１１２との間でネットワーク１１０を介したデータ送受信を実行する。」（【００９０】）【図１８】
「さらに、発注管理部２３０は、新規発注受領部１８２０と、配送状況検索部１８３０と、予定時刻計算部１８４０とを含んでいる。新規発注受領部１８２０は、発注端末１１２から送付される新規な発注を受領し、特定の実施形態では所定の期間新規発注を格納部に蓄積し、所定の期間経過後にデータベースアクセス部２４０を呼び出して受注ＤＢ１１８に格納し、運行管理部２１０に対して新規な受注データが更新されたことを通知し、運行計画の作成を指令する。また、配送状況検索部１８３０は、発注端末１１２からの現在位置要求を受領して要求された運搬車両の最新の配送状況を検索するため、データベースアクセス部２４０を呼び出し、運行ＤＢ１２２の検索を実行し、検索された運搬車両の運行計画を、例えばビューとして作成する。また、予定時刻計算部１８４０は、運搬車両の現在位置および過去の位置情報から計算された平均速度から、配送目的地までに要する時間を計算し、現在時刻に加算して到達予定時刻を取得し、発注端末１１２の要求に対するレスポンスデータに追加する。」（【００９１】）
「また、発注管理部２３０は、運行ログ検索部１８５０と、地図情報取得部１８７０と、マッシュアップ処理部１８８０とを含んでいる。運行ログ検索部１８５０は、発注端末１１２から送付された現在位置要求に含まれる荷物ＩＤを検索キーとして動態ＤＢ１２０を検索し、荷物ＩＤ、すなわち当該荷物を運送している運搬車両の運行ログデータのうち、最新の日時情報が付されたデータを取得し、地図情報取得部１８７０およびマッシュアップ処理部１８８０に渡す。地図情報取得部１８７０は、地図ＤＢを検索し、運行ログ検索部１８５０から取得した位置情報および配送先の位置情報を含む適切な縮尺の地図情報を検索し、そのデータ識別値をマッシュアップ処理部１８８０に送付する。なお、地図ＤＢは、物流管理サーバ１１６がその機能として含んでいてもよいし、例えば、ＧｏｏｇｌｅＭａｐ（登録商標）などの商用ＤＢにアクセスして、そのＵＲＬアドレスを取得してもよい。」（【００９２】）
「マッシュアップ処理部１８８０は、配送状況検索部１８３０、予定時刻計算部１８４０、運行ログ検索部１８５０および地図情報取得部１８７０がそれぞれ取得した情報に対してウィンドウフレームを割り当て、表示のための各種オブジェクトを地図情報に重畳してスナップショットを作成し、現在位置要求に対するレスポンスデータを、例えばＨＴＭＬ／ＸＭＬなどの構造化文書およびＣＳＳなどを使用して作成する。作成されたレスポンスデータは、ネットワーク１１０を介して発注端末１１２へと送付され、デスクトップ画面上に表示される。すなわち、マッシュアップ処理部１８８０は、物流管理サーバ１１６のＷｅｂサーバ機能により取得された情報、ＦＴＰサーバ機能により収集された情報、地図ＤＢから取得した情報をマッシュアップして発注端末１１２に送付することで、依頼した荷物の配送状況を略リアルタイムで提供することを可能としている。」（【００９３】）
「図２０は、本実施形態のマッシュアップ処理部１８８０が実行する処理のフローチャートである。マッシュアップ処理部１８８０は、発注端末１１２のデスクトップ画面上にブラウザプログラムが表示するグラフィカルユーザインタフェース（ＧＵＩ）からハイパーリンクやパラメータの送信を行うことで、マッシュアップ処理部１８８０に対して遠隔的に図２０に示した処理を実行させる。図２０の処理は、特定の発注端末１１２からの要求を受領してステップＳ２０００でセッションを開始し、ステップＳ２００１で、ユーザＩＤおよびパスワードなどの認証情報からクライアントを特定する。ステップＳ２００２では、受注ＤＢを検索し、当該クライアントの受注リストをビューなどとして作成する。」（【００９６】）「ステップＳ２００３～ステップＳ２００５は、マッシュアップ処理部１８８０が発注端末１１２からの要求を判断する処理である。マッシュアップ処理部１８８０は、ステップＳ２００３でまず要求が新規発注であるか否かを判断し、新規発注である場合（ｙｅｓ）ステップＳ２００６およびステップＳ２００９の処理を実行する。また、要求が新規発注でない場合（ｎｏ）、処理をステップＳ２００４に渡し、要求が配送状況の要求か否かを判断し、配送状況の要求である場合（ｙｅｓ）、ステップＳ２００７およびステップＳ２０１０の処理を実行する。一方、要求が配送状況の要求ではない場合（ｎｏ）、処理をステップＳ２００５に渡し、地図情報の表示を要求するか否かを判断し、地図情報が要求されている場合（ｙｅｓ）、ステップＳ２００８以下の処理を実行する。以下、各処理ステップを要求内容ごとに説明する。
(1) 新規発注
（中略）
(2) 配送状況要求
要求が配送状況確認であると判断した場合、ステップＳ２００７で配送状況要求が含む荷物を特定する荷物ＩＤを受領し、動態ＤＢ１２０を呼び出して、当該荷物ＩＤに対応する運搬車両の運行ログデータを抽出する。そして、ステップＳ２０１０で現在時刻、位置座標および配送先の各情報から受注リストの納品予定時刻を更新し、現在位置の位置座標に対応してリンクするべき地図データの地図ＩＤを更新する。その後、処理をステップＳ２００４に戻し、次の要求を待機する。
(3) 地図情報要求
ステップＳ２００５で、発注端末１１２からの地図情報表示要求であると判断した場合、ステップＳ２００８で、地図情報要求が含む荷物ＩＤを受領し、動態ＤＢ１２０にアクセスして、当該荷物ＩＤに対応する運搬車両の配送状況を取得し、ステップＳ２０１１で、現在位置および配送先の緯度・経度情報を含む縮尺の地図情報を取得する。ステップＳ２０１２で、取得した地図情報に対して配送先を示す第１オブジェクトおよび運搬車両の現在位置を示す第２オブジェクトをそれぞれ合成し、適切なＵＲＬを付して格納し、当該ＵＲＬを発注端末１１２へと応答として送付して、デスクトップ画面上に地図を表示させる。」（【００９７】）
「図２３は、本実施形態の発注管理部２３０がクライアントからの配送状況要求に対応して作成した配送状況テーブル２３１０を表示する表示画面２３００の実施形態を示す。図２３の表示画面２３００には、特定のユーザについての荷物について、受注番号、積込日、積込地、積込住所、納品日、納品時間、納品先、納品住所、予定時間、および車番が登録されて、配送状況テーブル２３１０の１つのレコード２３２０が構成される。配送状況テーブル２３１０には、同様のレコードが荷物ごとにリストされ、ユーザは、依頼した荷物が現在どのような配送状況にあるかについて、表示画面２３００を表示させることにより、認識することができる。なお、配送状況テーブル２３１０は、特定の登録ユーザの現在配送中である荷物を、運行ＤＢ１２２に登録された集配リストから抽出し、さらに該当する運搬車両の現在位置および動態ＤＢ１２０の運行ログから計算される配送予定時刻を登録するカラムを挿入することで、発注管理部２３０が生成することができる。」（【０１０２】）「また、図２３の予定
時刻は、マッシュアッ
プ処理部１８８０が運
行ログデータを利用し
て作成した荷物の配送
予定時刻が表示されて
おり、ユーザが、特定の
レコード２３２０の予
定時刻をクリックする
ことで、リンクされた
地図データが表示フィ
ールド２３３０に表示
される。地図データには、各種のランドマークを示すオブジェクトの他、納品場所を示す第１オブジェクトが、納品場所の緯度・経度に対応する位置に重畳され、また、運搬車両の現在位置には、現在位置を示す第２オブジェクトが配置される。このため、ユーザは、荷物が現在どの位置にあるのかを容易に認識でき、荷物到着後の作業手順を予め決定することができ、より効率的な納品後処理が可能となる。」（【０１０３】）
「図２４は、ウェブページとして実装した場合の図２３に示した配送状況を表示【図２３】
する実施形態におけるＧＵＩ２４００を示す。なお、図２４に示した実施形態では、地図データ２４５０を表示させるウィンドウフレームは特に設けられておらず、特定の荷物の予定時刻を登録した配送状況テーブル２４１０のフィールド２４２０をクリックすることにより、物流管理サーバ１１６が生成した地図データを、そのＵＲＬからダウンロードしてポップアップ表示して地図データ２４５０として表示している。」（【０１０５】）
「地図データ２４
５０には、第１オブ
ジ ェクト２４３０
が追加され、また運
搬車両の現在位置
を示す第２オブジ
ェ クト２４４０が
追加されていて、ユ
ーザは、視覚的に現
在荷物がどのよう
な状況にあるかを
確認することがで
きる。また、位置的な距離ばかりではなく、納品時刻は、道路状況にも依存する。このため、正確な納品時刻は、単に距離だけでは判断できないこともある。図２３に示した実施形態では、配送状況のレコードに予定時間を表示するのではなく、図２４に示した実施形態では、物流管理サーバ１１６は、納品時刻を当該運搬車両から送付された運行ログデータの時系列解析によって平均時速を計算し、予定されている経路に沿った距離を当該平均時速で除算して、現在の時刻に加算し、予定時刻として算出し、第１オブジェクトのクリックなどのマウスイベントに応じてポップアップ表示する。」（【０１０６】）
【図２４】
「以上のように本発明によれば、運搬車両の運搬状況を管理するために取得した情報を使用して、物流管理を行うとともに、当該情報から荷主毎に現在の荷物の配送状況情報を作成し、荷主に通知することを可能とする物流管理システム、物流管理方法、およびプログラムを提供することにより、荷物運搬を依頼した発注者の納品後処理を効率化すると共に、再配送などの物流者側の配送も効率化することが可能となる。」（【０１０９】）
(2) 以上によれば、本件発明に関し、次のことを指摘することができる。
ア 本件発明は、荷物の輸送を管理するための物流クラウドシステム及びプログラムに係るものである。
イ 従来、特定の荷物を積載した貨物車両が現在何処でどのような状況になっているかについての情報は、主に、物流業者にのみ提供されていたが、これを、荷物管理および営業管理の必要がある荷主に対しても提供するシステムを作りたいとの課題があった。
ウ そこで、上記課題を解決すべく、次のような構成を有する本件発明がなされた。
(ｱ) 荷物を指定して荷物の運送を依頼することのできる発注端末、集配を管理する物流端末及び物流管理サーバを、ネットワークを介して接続する。
(ｲ) そして、ネットワークを介して荷物を運搬するための運搬車両を特定する情報を運行計画データとして運行データベースに登録し、荷物を輸送している運搬車両の最新の位置情報及び日時情報を取得して運行ログとして動態データベースに登録する。
(ｳ) さらに、指定された荷物に係る配送状況要求に対して運行ログを検索し、納品先及び検索された前記運行ログで指定される前記運搬車両の最新の位置をモバイル端末からの定期的な前記位置情報及び日時情報をアップロードして地図情報を取得し、前記運行ログにおける履歴及び前記最新の位置から納品予定時刻を計算して、前記納品先及び前記運搬車両に対してそれぞれ異なる図形オブジェクトを割り当てて、前記地図情報上に合成し、荷主又は配送依頼元に応答として送付する。
エ そして、本件明細書には、上記のとおり、「特定の荷物を積載した貨物車両が現在何処でどのような状況になっているかについての情報は、物流業者ばかりではなく、荷主における荷物管理および営業管理のためにも重要な情報を提供することができる」（【００１０】）ものの、「このためには、位置情報を管理するサーバ、運行状況／積載情報を管理するサーバ、および荷主管理を行うためのサーバなど複数のサーバが取得した情報を組み合わせて目的に適合する新たなコンテンツを作成することが必要」であるが、従来技術では、「複数サーバが取得したデータを組合せて異なるデータを生成し、荷主に対して提供することを課題とするものではないこと（【００１１】）から、「本発明は、貨物車両の運搬状況を管理するために取得した情報を使用して、物流管理を行うとともに、当該情報から荷主毎に現在の荷物の配送状況情報を作成し、荷主に通知することを可能とする物流クラウドシステムおよびプログラムを提供することを課題とする。」（【００１２】）という記載がある。これらによれば、本件発明は、上記課題を解決するために、「前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領」し、「複数のデータベースを横断した検索結果からレスポンスデータを作成して要求元に返す」構成（構成要件１Ｅ－１ないし３及び５Ｅ－１ないし３）を採用することによって、荷主に対し、特定の荷物を積載した貨物車両が現在何処でどのような状況になっているかの情報を提供すること（【００１０】参照）を可能とするものであるといえる。そして、本件発明は、このような構成を採用することによって、特定の荷物を積載した貨物車両が現在どこでどのような状況になっているかについて、物流業者のみならず、荷主毎に当該荷物の配送状況情報を作成して提供することにより、荷主の荷物管理及び営業管理に必要な情報を提供することができるというものである。以上を前提に、被告製品の本件発明の技術的範囲への属否について検討する。
２ 争点１－１（被告製品が「配送状況要求」を行う構成を有するか（構成要件１Ｄ及び５Ｄの充足性））について
(1) 「配送状況要求」の意義について
本件発明１及び本件発明５は、「荷物の輸送を管理する」ための物流クラウドシステム（構成要件１Ａ、５Ａ）に係るものであること、及び、構成要件１Ｂ、５Ｂの文言も、「配送するべき荷物の配送依頼」というものであることに照らせば、「配送状況要求」（構成要件１Ｄ、５Ｄ）の対象は、「荷物」であると解するのが相当である。そして、荷物がどこでどのような状況になっているかの要求は、当該荷物を指定することによって行われるとみることが合理的かつ自然であることからすれば、本件発明１及び５における「配送状況要求」は、個々の荷物を指定して行われると解するのが相当である。このことは、本件明細書において、荷物の運送依頼は、運送すべき荷物を指定してされるものであること（【００２０】）、発注端末は、物流管理サーバから当該荷物の現在位置、配送完了予定時刻などの現在の配送状況をリアルタイムで取得すること（【００２１】）、発注管理部は、発注端末からの状況確認要求を受領すると、状況確認要求から荷物ＩＤを取得し、当該荷物ＩＤを検索キーとして、運行データベース及び当該荷物ＩＤに対応する運搬車両の運行ログデータを検索し、動態データベースにアクセスして、当該荷物ＩＤに対応する運搬車両の配送状況を取得し、現在位置及び配送先の緯度・経度情報を含む地図情報を取得すること（【００５７】、【００９７】）といった記載があることからも裏付けられるというべきである。
(2) 被告製品の構成について
証拠（乙２、１９）によれば、被告製品は、配車計画の作成に当たり、予め入力項目を定めたテンプレートを利用してシステムに情報を入力して案件（一つの訪問先への移動から作業完了までのこと）を登録し、各作業者への案件の割り振りである配車計画を登録する構成を採用していること、上記入力項目には、対象日、作業者ユーザーコード、訪問順番、訪問先コード、案件名称、到着希望日、到着希望時刻、作業時間、荷物量等の配車計画の作成に必要な情報及びルート作成方法、出発営業所コード、到着営業所コード、出発・到着時刻、渋滞考慮、有料道路優先・一般道路優先等の選択等のルート作成に必要な情報が挙げられているものの、個別の荷物を特定する内容の情報は入力項目には存在しないことが認められる。そのほか、本件全証拠をみても、被告製品において配車計画を作成するに当たり、配送の対象となる個別の荷物を特定してされていることをうかがわせる事実は見当たらない。そうすると、被告製品においては、個々の荷物を特定する情報が、配車計画の作成に必要な情報として配車計画の内容を構成しているものとは認められないから、被告製品においては、個別の荷物を指定して行われる「配送状況要求」を行う構成を有しておらず、構成要件１Ｄ及び５Ｄを充足しないというべきである。
(3) 原告の主張について
原告は、「配送状況要求」の意義につき、その文言の通常の意義からすれば、運送車両の配送状況を要求するものであれば足りると主張する。
しかしながら、前記で説示したとおり、本件明細書の上記各記載からすれば、配送状況要求は、特定の荷物を指定して行われるものであると解するのが相当であり、これが、運送車両を特定して行われるものであると解することはできず、原告の上記主張は採用することができない。
また、原告は、被告製品が特定の荷物を指定して配車計画を作成していないとしても、本件発明の実施形態の一例として本件明細書に記載された「荷物ＩＤ」について、運搬車両に積載されているひと箱の荷物を一意的に識別・特定することが可能なものであることを意味せず、運搬車両に積載されている荷物全体を識別・特定する識別子を用いることも可能であるとして、特定の荷物ではなく、運搬車両を特定してされる配送状況の確認依頼も、「配送状況要求」に当たるとも主張する。しかしながら、通常、運搬車両には荷主が異なるもの、配送先が異なるものなど複数の荷物が混在して積載されていることも考慮すれば、運搬車両に積載されている荷物全体を識別・特定する識別子を用いる場合において現在位置として特定されるのは、飽くまで当該識別子が付された運搬車両でしかないというべきであって、個別の荷物の現在位置状況を特定することにはならないといわざるを得ない。これでは、特定の荷物の配送状況を荷主に通知するという本件発明の課題を達成することができないというべきである。そうすると、「荷物ＩＤ」は、特定の荷物を一意的に識別・特定することを可能とする識別子を意味すると解さざるを得ず、「荷物ＩＤ」は運搬車両に積載されているひと箱の荷物を一意的に識別・特定することが可能なものであることを意味しないとの原告の上記主張は理由がないというべきである。
３ 争点１－３（被告製品が「荷物ＩＤを指定」して現在位置の要求を行うものか（構成要件１Ｅ－１及び５Ｅ－１の充足性））について
(1) 「荷物ＩＤを指定」の意義について
前記２(3)において説示したおとり、構成要件１Ｅ－１及び５Ｅ－１で規定されている「荷物ＩＤ」は、特定の荷物を一意的に識別・特定することを可能とするもののことをいうものと解される。このことは、「荷物ＩＤ」の文言の通常の意義からしても明らかである。すなわち、「ＩＤ」とは、ＩＤ番号・ＩＤカードの略であるところ、「ＩＤ番号」とは、複数の人や物を一意的に識別するための符号の意を有しているのであって（「広辞苑」第７版）、かかる意を有する語が「荷物」に用いられるときである「荷物ＩＤ」の場合、複数ある荷物からある特定の荷物を区別して識別するために付され、名称、番号、記号等を用いて構成される識別子のことをいうと解すべきである。
そうすると、構成要件１Ｅ－１及び５Ｅ－１で規定されている「荷物ＩＤを指定」して行われる現在位置の要求は、荷物ＩＤにより特定される、個別の荷物を対象としてされるものであると解するのが相当である。
(2) 被告製品の構成について
証拠（乙４）によれば、被告製品は、運送業者だけでなく、荷送人自身で作業者の位置などをリアルタイムに確認することを可能とするため、荷送人専用の動態管理画面を用意しており、かかる画面を利用するには、ユーザ設定時に「動態管理のみロール」を選択してユーザコードの割当てを受けてユーザ登録を行い、訪問先として特定の顧客ごとに割り当てられる顧客コードを指定して登録する必要があるものである。そして、「動態管理のみユーザ」が「動態管理のみユーザ」向け設定において作業者ステータスの設定において特定の作業者を指定した場合において、「動態管理のみユーザ」が登録した訪問先が割り当てられた配車計画があるときには、「動態管理のみユーザ」は、当該訪問先が割り当てられている車両の位置情報が表示された地図を動態管理画面上で確認することができることが認められる。また、証拠（乙３）によれば、「動態管理のみユーザ」が利用できる動態管理画面の地図タブ中の作業者タブを選択すると、作業者ごとの到着予定時刻を含む案件進捗状況が表示され、また、地図タブの地図上で車両のオブジェクトで表される作業者アイコンに表示される吹き出しをクリックすると、到着予定時刻を含む案件進捗状況が表示され、これらによって、「動態管理のみユーザ」は、作業者を指定した上で到着予定時刻を含む案件進捗状況を確認することができることが認められる。このように、被告製品は、運送業者又は訪問先として特定の顧客に割り当てられた顧客コードを登録した荷送人から、「作業者」を指定した当該訪問先への到着予定時刻を含む案件進捗状況の表示の要求を受領する構成を有していると認められるが、それにとどまり、本件全証拠をみても、「個別の荷物」を特定して当該荷物の現在位置要求を受領する構成を採用していることをうかがわせる事情は見当たらない。したがって、被告製品は、「荷物ＩＤを指定」した現在位置要求を受領する構成を備えていないというべきであり、構成要件１Ｅ－１及び５Ｅ－１を充足しないというべきである。
(3) 原告の主張について
原告は、運搬車両に積載されている荷物全体を識別・特定する識別子も「荷物ＩＤ」として用いることができる旨主張する。
しかしながら、前記説示のとおり、通常、運搬車両には複数の荷物が積載されていることからすれば、運搬車両に積載されている荷物全体を識別・特定する識別子を用いる場合において現在位置として特定されるのは、当該識別子が付された運搬車両であり、必ずしも個別の荷物の現在位置状況を特定することにはならず、これでは、特定の荷物の配送状況を荷主に通知するという本件発明の課題を達成することができないというべきである。そうすると、「荷物ＩＤ」は、特定の荷物を一意的に識別・特定することを可能とする識別子を意味すると解さざるを得ず、運搬車両に積載されている荷物全体を識別・特定する識別子も「荷物ＩＤ」として用いることができるとの原告の上記主張は理由がない。また、本件発明１及び５に係る特許請求の範囲においても、構成要件１Ｂ及び５Ｂにおいて「運搬車両を特定する情報」と規定し、一方で、構成要件１Ｅ－１及び５Ｅ－１において「荷物ＩＤ」と規定しており、運搬車両を識別・特定する趣旨の表現と個別の荷物を識別・特定する趣旨の表現とが書き分けられていることからしても、原告の上記主張は理由がないといわざるを得ない。
４ 争点２－１（被告製品が「配送状況要求」を行う構成を有するか（構成要件２Ｇ及び６Ｇの充足性））について
続いて、予備的主張である、被告製品の本件発明２及び６の技術的範囲への属否について検討する。
構成要件２Ｇ及び６Ｇは、「前記」「配送状況要求」で指定された荷物について運行ログを検索する手段について規定しているものであるところ、前記２及び３で説示したとおり、「配送状況要求」は、特定の荷物を指定してされるものであると解される。しかして、被告製品は、特定の荷物を指定して案件進捗状況を検索する構成を有していないから、被告製品は、構成要件２Ｇ及び６Ｇを充足しないというべきである。
５ 争点３－１（被告製品が請求項１及び２のいずれかに記載された「物流クラウドシステム」であり、請求項５及び６のいずれかに記載された「プログラム」か（構成要件３Ｍ及び７Ｍの充足性））について
更に続いて、予備的主張である、被告製品の本件発明３及び７の技術的範囲への属否について検討する。
構成要件３Ｍは「請求項１または２に記載の物流クラウドシステム」、構成要件７Ｍは「請求項５または６に記載のプログラム」とそれぞれ規定しているところ、前記説示のとおり、被告製品は、本件発明１、２、５及び６の技術的範囲に属さないのであるから、被告製品は、請求項１又は２に記載の物流クラウドシステムであるとはいえず、請求項５又は請求項６に記載のプログラムであるともいえない。したがって、被告製品は、構成要件３Ｍ及び７Ｍを充足しない。
６ 争点４－１（被告製品が「配送状況要求」を行う構成を有するか（構成要件４Ｎ及び８Ｎの充足性））について
更に続いて、予備的主張である、被告製品の本件発明４及び８の技術的範囲の属否について検討する。
構成要件４Ｎ及び８Ｎは、「前記」「配送状況要求」が荷主又は配送依頼元が発行することを規定しているところ、前記２及び３で説示したとおり、「配送状況要求」は、特定の荷物を指定してされるものであると解される。しかして、被告製品は、特定の荷物を指定して案件進捗状況を検索する構成を有していないから、被告製品は、構成要件４Ｎ及び８Ｎを充足しないというべきである。
以上によれば、被告製品について、本件発明の文言侵害は成立しないというべきであるが、続いて、均等侵害等について検討する。
７ 争点５（被告製品について本件発明の均等侵害が成立するか）について
(1) 前記２及び３において説示したとおり、❶本件発明１及び５は、特定の荷物を指定して配送状況要求を行う構成を備えているところ、被告製品においては作業者を指定した配送状況要求を行う構成を備えている点、及び❷本件発明１及び５は、荷物ＩＤを指定した現在位置要求を行う構成を備えているところ、被告製品においては作業者を指定した現在位置要求を行う構成を備えている点で、本件発明１及び５と被告製品とは相違する。
しかしながら、特許請求の範囲に記載された構成中に、相手方が製造等をする製品（対象製品）と異なる部分が存する場合であっても、①異なる部分が特許発明の本質的部分ではないこと、②上記部分を対象製品におけるものと置き換えても、特許発明の目的を達することができ、同一の作用効果を奏するものであること、③上記のように置き換えることに、当該発明の属する技術の分野における通常の知識を有する者（当業者）が、対象製品の製造等の時点において容易に想到することができたものであること、④対象製品が、特許発明の特許出願時における公知技術と同一又は当業者がこれから同出願時に容易に推考できたものではないこと、かつ、⑤対象製品が特許発明の特許出願手続において特許請求の範囲から意識的に除外されたものに当たるなどの特段の事情もないこと、の各要件を満たすときは、上記対象製品は、特許請求の範囲に記載された構成と均等なものとして、特許発明の技術的範囲に属するものと解するのが相当である（平成１０年最高裁判決参照）。
(2) 均等の第１要件にいう特許発明の本質的部分とは、当該特許発明の特許請求の範囲の記載のうち、従来技術に見られない特有の技術思想を構成する特徴的部分であると解すべきであり、このような本質的部分が相違する場合には、全体として当該特許発明の技術的思想とは別個のものと認められ、均等は認められないというべきである。
しかして、前記説示のとおり、従来技術に見られない、本件発明の課題であるところの荷主に通知する「現在の荷物の配送状況情報」は、「特定の荷物を積載した貨物車両が現在何処でどのような状況になっているかについての情報」であって、特定の荷物の所在や状況を把握するためには、特定の貨物車両や作業者の動向把握のみでは足りないと考えられることに照らせば、本件発明特有の技術思想を構成する特徴的部分は、特定の荷物が現在どこに在り、どのような状況になっているかという情報を荷主に提供することにあるものと解される。
そして、本件発明１及び５は、上記課題を解決するために、「前記荷主または配送依頼元からの荷物ＩＤを指定した現在位置要求を受領」し、「複数のデータベースを横断した検索結果からレスポンスデータを作成して要求元に返す」構成（構成要件１Ｅ－１ないし３及び５Ｅ－１ないし３）を有することによって、荷主に対し、特定の荷物を積載した貨物車両が現在何処でどのような状況になっているかの情報を提供することを可能とするものである。また、本件発明１及び５は、「荷物ＩＤ」を使用した現在位置要求がされることを規定しているところ、前記説示のとおりの本件発明の課題からすれば、本件発明１及び５は、運搬車両が積載している荷物全体を識別するものではなく、荷物の対象単位である個別の荷物にそれぞれ識別子を付することにより、当該個別の荷物を識別することができるようにする点に技術的意義があると認められ、この点が本件発明１及び５の特有の技術的思想を構成する特徴的部分であると認められる。
しかるに、被告製品における配送状況要求や現在位置要求は、本件発明１及び５のように個別の荷物を指定するのではなく、飽くまで作業者を指定してされるものであり、この点が、前記のように、両者の相違点となっている（相違点❶（本件発明１及び５は、特定の荷物を指定して配送状況要求を行う構成を備えているところ、被告製品においては作業者を指定した配送状況要求を行う構成を備えている点）、及び相違点❷（本件発明１及び５は、荷物ＩＤを指定した現在位置要求を行う構成を備えているところ、被告製品においては作業者を指定した現在位置要求を行う構成を備えている点）ものである。そうである以上、本件発明１及び５と被告製品とは、本件発明１及び５の特許請求の範囲の記載のうち、従来技術に見られない、特有の技術思想を構成する特徴的部分において相違しており、被告製品は、本件発明の技術的思想とは別個のものと認められるといわざるを得ない。
したがって、被告製品は、本件発明１及び５の本質的部分において相違しているということができ、均等の第１要件を満たさない。
(3) また、均等の第２要件についてみても、前記のように、被告製品における配送状況要求や現在位置要求が作業者をしてされるものである以上、そのような被告製品について、上記各要求が特定の荷物を指定してされる構成を有する本件発明１及び５の目的を達することができるとも、同一の作用効果を奏するものであるともいえないことは明らかである。
したがって、被告製品は、均等の第２要件を満たさない。
(4) 以上によれば、その余の点について検討するまでもなく、被告製品は、本件発明１及び５に記載された構成と均等なものとして、本件発明１及び５の技術的範囲に属するということはできない。
(5) 原告は、本件発明２ないし４及び６ないし８についても均等侵害を主張するが、これらの主張はいずれも、本件発明１及び５に関して認められる相違点❶及び❷を前提とするものと解される。そして、本件発明２ないし４及び６ないし８と被告製品との間においても同様の相違点❶及び❷が存在することが認められる。そうすると、上記(4)のとおり、本件発明１及び５に関して均等侵害が成立しない以上、本件発明２ないし４及び６ないし８についても、均等侵害は成立しないというべきである。
８ 争点６（被告製品について本件発明１の間接侵害が成立するか）について
(1) 原告は、被告プログラムモジュールが課題解決に不可欠なものであるとして、被告プログラムモジュールを含む被告製品を業として生産し、電気通信回路を通じた提供及び当該提供の申出をする行為は、特許法１０１条２号に規定された行為に該当し、本件発明１に係る特許権の侵害（間接侵害）が成立する旨主張する。しかし、前記説示のとおり、被告プログラムモジュールを含むとされる被告製品自体、本件発明１の構成要件１Ｄを充足するものではなく、また、その他、被告プログラムモジュールを用いた本件発明１の実施品の生産が被告あるいは第三者により行われていることを認めるに足りる証拠はない。そうすると、原告の上記間接侵害の主張は、そもそも主張の前提を欠くものである。
この点、原告は、被告製品が配送状告製品中のプログラムを変更することにより、上記構成を備えることは可能であるとして、被告のプレスリリース（甲４９）を提出するが、そのような浮動的な事情をもって、被告プログラムモジュールを用いた本件発明１の実施品の生産が認められることにはならないというべきである。
(2) また、前記説示のとおり、被告製品における配送状況要求や現在位置要求は、本件発明のように個別の荷物を指定するのではなく、飽くまで作業者を指定してされるものである。このことに照らすと、被告製品に用いられる被告プログラムモジュールについても、上記については被告製品と同様の構成であると解されるから、本件発明の課題解決手段（個別の荷物を特定して現在位置要求を行うなどの手段）を具備しない構成のものであるといわざるを得ない。そうすると、被告プログラムモジュールは、本件発明１の特許請求の範囲の記載のうち、従来技術に見られない、特有の技術思想を構成する特徴的部分を備えないものといわざるを得ず、被告プログラムモジュールは、特許法１０１条２号にいう「発明の課題の解決に不可欠なもの」に当たらないというべきである。
(3) したがって、被告製品について本件発明１の間接侵害が成立するということはできない（なお、原告は本件発明１につき間接侵害を主張するものであるが、仮にその余の本件発明２ないし８につき検討したとしても、同様に、間接侵害が成立する余地はないというべきである。）。
第４ 結論
以上によれば、その余の争点について検討するまでもなく、原告の主張する特許権侵害（文言侵害、均等侵害、間接侵害）はいずれも成立せず、原告の請求はいずれも理由がないことに帰する。
よって、主文のとおり判決する。
東京地方裁判所民事第４７部
裁判長裁判官
田中孝一
裁判官
小口五大
裁判官
鈴木美智子
別紙
被告製品目録
被告が２０１２年（平成２４年）５月頃開発し、その後も更新しながら提供を続けている「ＢＵＳＩＮＥＳＳＮＡＮＩＴＩＭＥ動態管理ソリューション」若しくは「ビジネスナビタイム動態管理ソリューション」の名称を有する経路検索エンジンを活用した流通業者向けの移動の最適化を軸とした業務効率化に向けたサービスシステム及びそのシステム内で利用されているプログラム。
別紙
被告製品の構成
ａ 荷物の輸送を行う運送業者の運行管理を支援するためのクラウドシステムであり、同時に、トラック専用のカーナビアプリである。
ｂ インターネットを介して、配送依頼に関連して荷物を運搬する運搬車両、作業者及び納品先のデータをナビタイムサーバに登録する。
ｃ スマートフォンのＧＰＳ機能を使用して荷物を輸送している運搬車両の位置を時系列的に、少なくとも１日分保存取得し、インターネット経由でナビタイムサーバに登録する。
ｄ 位置情報、日時情報を使用して、車両の行き先をピンマークで表示し、運搬車両を車両マークで表示し、これらを表示する地図情報を取得し、これらを配送依頼元である運送会社の計算機端末に表示する。
ｅ ブラウザ上で構成ｄと同じ地図上に、検索された運搬車両の運行計画及び過去の位置情報から得た配送目的地までに要する時間をＶＩＣＳ（道路交通情報システム）、渋滞情報及び運搬車両の現在位置を示す最新の日時情報データから取得して運送会社の計算機端末に表示する。
ｆ 荷物の輸送を行う運送業者の運行管理を支援するための物流クラウドシステム
ｇ 「予定／実績一覧」で計画と実績を比較し、運搬車両の運行状態を検索し、運搬車両の運行が計画からどれだけ遅れているかという遅延状況を検索し、検索結果として遅延状況を表示する機能や運行ログを特定の運搬車両やドライバーに関連して検索し、その日ごとの行動を検索結果として生成する「日報作成」機能により移動履歴をエクセルファイルで出力する機能を有する。
ｈ ブラウザ上で、納品先と現在の運搬車両の位置を地図上に車両マークで表示する機能を有する。
ｉ ブラウザ上で、地図上に現在の運搬車両の位置を車両マーク、納品先をピンマークで表示し、到着予定時刻を計算・表示する機能を有し、これを荷主や配送依頼元が閲覧できる機能を有する
ｊ ｇないしｉを含む荷物の輸送を行う運送業者の運行管理を支援するための物流クラウドシステム
ｋ スマートフォンを含むモバイル端末から位置情報及び日時情報を送信し、受信する機能を有し、パーソナルコンピュータ等の計算機端末で共通のインターフェースであるウェブブラウザを使用して表示する機能を有する。
ｌ 配送状況を表示したり、効率的な訪問順や最適経路を検索・表示したり、登録された訪問先に対して周辺の作業者を検索する機能を使用して、効率的な訪問順や最適経路を表示する
ｍ 荷物の輸送を行う運送業者の運行管理を支援するための物流クラウドシステム
ｎ 荷主又は配達依頼者から配送状況を確認する操作、配送状況を要求することにより、荷物を運んでいる車両の現在位置やステータスがウェブブラウザ上に表示される機能を有する。
ｏ 荷物の輸送を行う運送業者の運行管理を支援するための物流クラウドシステム
出典：裁判所ウェブサイト「裁判例検索」（https://www.courts.go.jp/hanrei/91888/detail7/index.html）。本文は同サイト掲載の判決書PDFからTaiLexi AIがテキスト化・整形したもの（正確な文言は原本PDFを参照）。判示事項・裁判要旨・参照法条は裁判所の公表どおり。