令和2(ワ)3339 特許権侵害差止請求及び損害賠償請求事件

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

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