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