2021-700201

特許第６７４６８２６号発明「通信モジュール、通信システム及び通信方法」の特許異議申立事件について、次のとおり決定する。

結 論 特許第６７４６８２６号の特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項〔２０〕について訂正することを認める。 特許第６７４６８２６号の請求項１ないし５及び１０に係る特許を取り消す。 同請求項２０に係る特許を維持する。

理 由 第１ 手続の経緯 特許６７４６８２６号の請求項１ないし２０に係る特許についての出願は、令和元年１２月１３日を国際出願日とする出願であって、令和２年８月７日にその特許権の設定登録がされ、令和２年８月２６日に特許掲載公報が発行された。本件特許異議の申立ての経緯は、次のとおりである。 令和３年 ２月２５日 特許異議申立人 加藤浩志（以下、「特許異 議申立人」という。）による請求項１ないし ５並びに１０及び２０に係る特許に対する特 許異議の申立て 令和３年 ６月２３日付け 取消理由通知書 令和３年 ８月２７日 特許権者による意見書および訂正請求書の提 出 令和３年１０月 １日 特許異議申立人による意見書の提出 令和３年１２月 ７日付け 取消理由通知書（決定の予告）（以下、この 取消理由通知書（決定の予告）を「取消理由 通知」という。） 第２ 訂正の適否 （１）訂正の内容 特許権者は、特許請求の範囲の請求項２０を、以下の事項により特定されるとおりに訂正することを請求する（訂正事項１）。 「【請求項２０】 異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースと、ＯＳ（Operating System）と、当該ＯＳ上で実行される第１アプリと監視アプリとを有する通信モジュールに、通信に使用される通信インターフェース規格に対応し当該ＯＳ上で実行され任意にアンインストール可能な第２アプリをインストールし、 前記ＯＳと前記第２アプリとの間のミドルウェアとしてのアプリである第１アプリ経由で前記第２アプリについて設定された通信タイミングで、当該第２アプリが、当該第２アプリに対応した通信インターフェース規格上での通信プロトコルに従う通信を行い、 前記第２アプリのリソース使用量が前記ＯＳにより前記通信モジュールが有するメモリに格納されるようになっており、 前記監視アプリが、 前記第２アプリのリソース使用量を前記第１アプリに問い合わせ、 当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、前記第２アプリ経由又は非経由で、サーバに送信する、 通信方法。」（下線は、訂正箇所を示す。） （２）訂正の目的の適否、新規事項の有無、特許請求の範囲の拡張・変更の存否 訂正事項１に係る請求項２０についての訂正は、「ＯＳ上で実行される」「通信モジュール」について「監視アプリ」が実行されるとの限定を加え、「第２アプリ」について「前記第２アプリのリソース使用量が前記ＯＳにより前記通信モジュールが有するメモリに格納されるようになっており、」との限定を加え、さらに、「前記監視アプリが、前記第２アプリのリソース使用量を前記第１アプリに問い合わせ、当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、前記第２アプリ経由又は非経由で、サーバに送信する、」との限定を加えたものであるから、特許請求の範囲の減縮を目的としたものであり、願書に添付した明細書の発明の詳細な説明に、 「【００６８】 また、監視アプリ３０３Ｂ１は、第３アプリ３０３Ｂの一例である。フレームワーク３０３Ａ及び監視アプリ３０３Ｂ１は、通信モジュール１０１の提供者によってインストール（例えば、プリインストール）されてよい。監視アプリ３０３Ｂ１については後述する。なお、フレームワーク３０３Ａが、監視アプリ３０３Ｂ１のような第３アプリ３０３Ｂを兼ねてよい。すなわち、フレームワーク３０３Ａが、監視アプリ３０３Ｂ１を兼ねてもよい。なお、「第３アプリ」とは、ＯＳ３０３上のアプリのうち第１アプリ及び第２アプリ以外のアプリでよい。」 「【００８４】 さて、個々の第２アプリ３０３Ｃは、ＯＳ３０１によりプロセスとみなされて実行される。個々の第２アプリ３０３Ｃは、実行ログのような使用履歴（例えば、リソース量）を、当該第２アプリ３０３について設定された領域に書き込む。フレームワーク３０３Ａは、個々の第２アプリ３０３Ｃの実行によって何が発生するか（例えば、いずれの種類のリソースがどの程度使用されるか）かまではわからない。 【００８５】 そこで、本実施形態では、監視アプリ３０３Ｂ１が通信モジュール１０１にインストールされる。監視アプリ３０３Ｂ１は、例えば、第２アプリ３０３Ｃ毎に、定期的に、フレームワーク３０３Ａに対し、当該第２アプリ３０３Ｃに対応した領域にデータがあるか否かを問合せる。フレームワーク３０３Ａは、データがあれば、当該データを領域から読み出して監視アプリ３０３Ｂ１に返し、データが無ければ、データが無いことを監視アプリ３０３Ｂ１に回答する。 【００８６】 監視アプリ３０３Ｂ１が問合せに応答してフレームワーク３０３Ａから受信するデータは、第２アプリ３０３Ｃの使用履歴を表す情報を含んでいる。監視アプリ３０３Ｂ１は、フレームワーク３０３Ａから受信したデータを、監視アプリ３０３Ｂ１のアプリＩＤと、当該データに対応した第２アプリ３０３ＣのアプリＩＤとに関連付けて、グローバルの第２アプリの一例であるMQTTアプリ３０３Ｃ３に渡す（例えば、メモリ２２３における所定の領域に書き込む）。MQTTアプリ３０３Ｃ３が、渡されたデータを管理サーバ１１５に送信する。」 と記載されているから、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものでもない。 （３）独立特許要件の適否 本件においては、訂正前の請求項２０については特許異議の申立てがされているので、訂正事項に関して、特許法第１２０条の５第９項で読み替えて準用する特許法第１２６条第７項に規定される独立特許要件は課されない。 （４）訂正の適否についてのまとめ 上記のとおり、訂正事項１に係る訂正は、特許法第１２０条の５第２項ただし書第１号に掲げる事項を目的とするものであり、かつ、同条第９項において準用する同法第１２６条第５項及び第６項の規定に適合する。 したがって、特許請求の範囲を、訂正請求書に添付された訂正特許請求の範囲のとおり、訂正後の請求項２０のとおり訂正することを認める。 第３ 訂正後の本件発明 請求項１ないし１９に係る発明、及び、本件訂正請求により訂正された、請求項２０に係る発明（以下、請求項１ないし２０に係る発明を、それぞれ「本件発明１」ないし「本件発明２０」という。）は、その特許請求の範囲の請求に記載された次の事項により特定されるとおりのものである。 「【請求項１】 異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースと、 ＯＳ（Operating System）を含む複数のプログラムが格納されるメモリと、 前記複数の通信インターフェースと前記メモリとに接続され前記複数のプログラムを実行するプロセッサと を備え、 前記複数のプログラムは、前記ＯＳ上で実行される第１アプリと、前記ＯＳ上で実行される一つ又は複数の第２アプリとを含み、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 前記第１アプリは、前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである、 通信モジュール。 【請求項２】 前記一つ又は複数の第２アプリの各々について、 当該第２アプリの実行オブジェクトと、 当該第２アプリについて一つ以上の設定項目を表す設定定義オブジェクトと、 当該一つ以上の設定項目について一つ以上の設定値が入力された場合に当該入力された一つ以上の設定値が登録される設定オブジェクトと を含んだアプリ構造体があり、 前記一つ又は複数の第２アプリの各々について、当該第２アプリの実行は、当該第２アプリの設定オブジェクトに基づいており、 前記第１アプリが、 指定された第２アプリの設定定義オブジェクトを基に、当該設定定義オブジェクトが表す一つ以上の設定項目について一つ以上の設定値を受け付けるＵＩ（User Interface）である設定画面を生成し、 当該生成した設定画面を提供し、 当該設定画面が表す一つ以上の設定項目について当該設定画面に入力された一つ以上の設定値を、前記指定された第２アプリの設定オブジェクトに登録する、 請求項１に記載の通信モジュール。 【請求項３】 前記設定画面は、前記通信モジュールに通信可能に接続された計算機で実行されるＷｅｂブラウザにより表示可能な画面である、 請求項２に記載の通信モジュール。 【請求項４】 前記一つ又は複数の第２アプリにそれぞれ対応した一つ又は複数のアプリ構造体は、ファイルシステムにおける所定のディレクトリに格納され、 各アプリ構造体において、実行オブジェクト、設定定義オブジェクト及び設定オブジェクトとは、それぞれ、実行ファイル、設定定義ファイル及び設定ファイルであり、 前記第１アプリは、前記所定のディレクトリを参照することで、前記一つ又は複数の第２アプリのインストール済を特定する、 請求項２に記載の通信モジュール。 【請求項５】 前記通信モジュールのエンドユーザ以外のエンティティにより管理されるシステムから当該エンドユーザの要求無しに第２アプリのアプリ構造体が前記所定のディレクトリに格納される、 請求項４に記載の通信モジュール。 【請求項６】 第１の第２アプリが、当該第１の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、当該通信インターフェースに接続されている機器からデータを受信し、 前記第１の第２アプリとは別の第２アプリである第２の第２アプリが、前記第１の第２アプリが受信したデータ又は当該データの加工後のデータを、当該第２の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、所定のサーバに送信する、 請求項１に記載の通信モジュール。 【請求項７】 前記複数のプログラムが、第３アプリとして監視アプリを含み、 少なくとも一つの第２アプリのリソース使用量が前記ＯＳにより前記メモリに格納されるようになっており、 前記監視アプリが、 前記少なくとも一つの第２アプリのリソース使用量を前記第１アプリに問い合わせ、 当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、前記第２の第２アプリに渡し、 前記第２の第２アプリが、渡されたデータを前記所定のサーバに送信する、 請求項６に記載の通信モジュール。 【請求項８】 前記複数のプログラムが、第３アプリとして監視アプリを含み、 少なくとも一つの第２アプリのリソース使用量が前記ＯＳにより前記メモリに格納されるようになっており、 前記監視アプリが、 前記少なくとも一つの第２アプリのリソース使用量を前記第１アプリに問い合わせ、 当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、いずれかの第２アプリ経由又は非経由で、サーバに送信する、 請求項１に記載の通信モジュール。 【請求項９】 前記複数のプログラムが、第３アプリとして課金アプリを含み、 前記第１アプリが、第２アプリにより通信インターフェース経由で通信されたデータの量であるデータ通信量を特定し、 前記課金アプリが、前記特定されたデータ通信量に基づいて、通信モジュールの使用に関する課金額を決定する、 請求項１に記載の通信モジュール。 【請求項１０】 異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースを有する通信モジュールと、 サーバと を備え、 前記通信モジュールが、ＯＳ（Operating System）と、当該ＯＳ上で実行される第１アプリと、当該ＯＳ上で実行される一つ又は複数の第２アプリとを有し、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 前記第１アプリは、前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリであり、 第１の第２アプリが、当該第１の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、当該通信インターフェースに接続されている機器からデータを受信し、 前記第１の第２アプリそれ自体又は別の第２アプリである第２の第２アプリが、当該第２の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、前記サーバにデータを送信する、 通信システム。 【請求項１１】 前記第２の第２アプリから送信されるデータが、第２アプリにより通信インターフェース経由で通信されたデータの量であるデータ通信量を含み当該第２アプリの使用履歴であるアプリ使用履歴を表すデータを含み、 前記サーバが、前記第２の第２アプリからのデータから特定される前記アプリ使用履歴に基づいて、前記通信モジュールの使用に関する課金額を決定する、 請求項１０に記載の通信システム。 【請求項１２】 前記アプリ使用履歴は、第２アプリと当該第２アプリのアクティベート時刻とを表す情報を含む、 請求項１１に記載の通信システム。 【請求項１３】 前記通信モジュールが、所定の通信網に対応し加入者識別情報を格納したカードを有しており、 前記第２の第２アプリが、前記カード内の加入者識別情報を含むデータを、前記第１アプリ経由で設定された通信タイミングで、前記サーバに送信する、 請求項１１に記載の通信システム。 【請求項１４】 前記サーバが、前記決定された課金額が反映された料金を前記所定の通信網を管理する通信事業者が請求可能にするために、前記決定された課金額を表す情報を、当該通信事業者宛に送信する、 請求項１３に記載の通信システム。 【請求項１５】 前記通信モジュールとして、少なくとも第１の通信モジュールと第２の通信モジュールとがあり、 前記サーバが、前記第１の通信モジュールのアプリ利用履歴が表す或る第２アプリのアクティベート時刻と、前記第２の通信モジュールのアプリ使用履歴が表す同一の第２アプリのアクティベート時刻とを基に、前記第１の通信モジュールに関する第１の課金額と前記第２の通信モジュールに関する第２の課金額とを決定する、 請求項１１に記載の通信システム。 【請求項１６】 前記第１の課金額のうち前記或る第２アプリの使用に関わる部分の料金と、前記第２の課金額のうち前記同一の第２アプリの使用に関わる部分の料金とのうち、当該第２アプリのアクティベート時刻が早い方の料金が安い、 請求項１５に記載の通信システム。 【請求項１７】 前記サーバは、決定された課金額の支払期限までの支払が無ければ、当該課金額が決定された通信モジュールの全部又は一部の使用を制限する、 請求項１１に記載の通信システム。 【請求項１８】 前記通信モジュールが、複数のリージョンに属する複数の通信網の各々について当該通信網の加入者識別情報を格納したカードを有しており、 前記通信モジュールにおけるいずれかのアプリが、当該通信モジュールが存在するリージョンを特定し、 当該特定されたリージョンが所定のリージョンの場合、前記通信モジュールにおけるいずれかのアプリが、当該所定のリージョンに属する通信網に対応した加入者識別情報を用いた通信を制限する、 請求項１０に記載の通信システム。 【請求項１９】 前記サーバとして、複数の通信網が属する複数のリージョンに属する複数のサーバがあり、 前記通信モジュールが、前記複数の通信網の各々について当該通信網の加入者識別情報を格納したカードを有しており、 前記通信モジュールが存在するリージョンに属するサーバが、 当該通信モジュールの通信が許可されているリージョンである許可リージョンを特定し、 当該許可リージョンに、前記通信モジュールが存在するリージョンが該当しない場合、当該リージョンに属する通信網に対応した加入者識別情報を用いた通信を制限する、 請求項１０に記載の通信システム。 【請求項２０】 異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースと、ＯＳ（Operating System）と、当該ＯＳ上で実行される第１アプリと監視アプリとを有する通信モジュールに、通信に使用される通信インターフェース規格に対応し当該ＯＳ上で実行され任意にアンインストール可能な第２アプリをインストールし、 前記ＯＳと前記第２アプリとの間のミドルウェアとしてのアプリである第１アプリ経由で前記第２アプリについて設定された通信タイミングで、当該第２アプリが、当該第２アプリに対応した通信インターフェース規格上での通信プロトコルに従う通信を行い、 前記第２アプリのリソース使用量が前記ＯＳにより前記通信モジュールが有するメモリに格納されるようになっており、 前記監視アプリが、 前記第２アプリのリソース使用量を前記第１アプリに問い合わせ、 当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、前記第２アプリ経由又は非経由で、サーバに送信する、 通信方法。」 第４ 取消理由通知について １ 取消理由の概要 請求項１ないし５及び１０に係る特許に対して、当審が特許権者に取消理由通知で通知した取消理由の要旨は、次のとおりである。 請求項１ないし５及び１０に係る発明は、甲第１号証に記載された発明に、甲第２号証ないし甲第５号証に記載された事項を組み合わせることにより、当業者が容易に発明をすることができたものである。 よって、請求項１ないし５及び１０に係る特許は、特許法第２９条第２項の規定に違反してされたものであり、取り消されるべきものである。 ２ 甲号証の記載 （１）甲第１号証（伊藤厚 外３名、「情報処理機能を強化したＩｏＴ対応産業用コントローラ」、日立評論、Ｖｏｌ．９９、Ｎｏ．６、［ｏｎｌｉｎｅ］、２０１７年１２月２０日、日立評論社、［２０２１年２月２４日検索］、インターネット<URL:https://d1.nd1.go.jp/view/download/digidepo_11180780_po_62-67_12A05.pdf?contentNo=1&alternativeNo=>）には、図面とともに以下の記載がある。 「１．はじめに 製造現場や設備・機械の動作を制御する制御用コントローラは、その制御をリアルタイムに行うために、設備や機械から必要なセンサーなどの入力信号を取り込み、制御内容を記述したプログラム（制御ロジック）に従って高速に演算し、その演算結果をアクチュエータなどへ出力信号として出力する構成となっている。」（第６２頁左欄１行ないし７行） 「さらに、複数の設備や機械、情報システムとの連携による制御システムの高度化のため、ネットワークが使用されている。特に制御用コントローラが制御に使用する入力信号や出力信号をネットワーク化するためには、各種制御ネットワークが使用され、多くの対応機器がこのネットワークに参加することが一般的になっている。 今後、制御用コントローラは、標準化されたプログラミング方式や制御ネットワークの活用が拡大し、半導体技術の進歩によってリアルタイム性能が大幅に向上することに加え、製造現場のＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）化への適用が求められると予想される。製造現場のＩｏＴ化により期待される効果は、生産効率向上、品質確保、納期短縮、コスト低減や予兆保守などであり、制御用コントローラが扱う多くの信号を活用することが有効となる。 次章で、リアルタイムに扱う多くの信号を情報として活用することができるように、新たな機能を付加したＩｏＴ対応産業用コントローラの新モデルを紹介する。」（第６２頁右欄７行ないし第６３頁８行） 「２．ＩｏＴ対応産業用コントローラ ＩｏＴ対応産業用コントローラ「ＨＸシリーズハイブリッドモデル（以下、「ＨＸハイブリッド」と記す。）は、ＰＬＣ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ）機能と各種ネットワーク機能に加え、情報処理機能を強化したものである。制御動作を行いながら製造現場でのＩｏＴ化を実現する情報処理プログラムを実行でき、製造現場と情報システムをシームレスに接続し、産業のＩｏＴ化を加速することができる（図１参照）。」（第６３頁右欄９行ないし１７行） 「２．２ 情報処理の実行環境 ＨＸシリーズは、製造現場のソフトウェア化をめざし、従来は専用のハードウェアで行っていた機能を、汎用プロセッサとＯＳ（Ｏｐｅｒｅａｔｉｎｇ ｓｙｓｔｅｍ）というオープンなハードウェアでコントローラに必要な制御性能をキャッチアップしている。ＨＸハイブリッドは、ＰＬＣ機能に加え、情報処理プログラミン言語（Ｃ／Ｃ＋＋）を１台のコントローラで実行させるため、コンテナ技術を導入して制御動作と情報処理をそれぞれ独立に実行できるようにする仕組みの制御コンテナと情報コンテナを搭載している（図４参照）。 制御ロジック開発環境で制御動作を記述しデバッグを行い、情報プログラム開発環境で情報処理を記述しデバッグを行い、それぞれのコンテナに格納し実行することで、製造現場と情報システムの接続をシームレスに実現する。それぞれを独立に動作可能としたことで、制御動作を行っていても情報プログラムの変更が可能であり、製造現場の生産活動に影響を与えずに、情報プログラムの改良や更新をするオンライン変更も可能としている。 ＨＸハイブリッドは、リアルタイム制御動作のための入力信号や出力信号のほか、製造現場で使用される機器を接続するために、制御ネットワークとして今後普及が見込まれるＥｔｈｅｒＣＡＴ対応機能を標準で備えている。また、その他の制御ネットワークとして、ＰＲＯＦＩＮＥＴやＰＲＯＦＩＢＵＳ、ＤｅｖｉｃｅＮｅｔ、ＦＬ－ｎｅｔ、Ｍｏｄｂｕｓなど広く普及している制御系ネットワークにも対応が可能となっており、情報システムからは制御系ネットワークとしてのゲートウェイ機能を提供し、製造現場と情報システムのシームレスな接続を可能とした。 一方、情報系ネットワークについては、ＯＰＣ ＵＡ（Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｏｒｏｌ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ機能を有しており、ＯＰＣ ＵＡサーバ機能を使って簡単に情報システムと双方向で制御データを交換することができる。加えて、ＨＸハイブリットが提供する情報プログラム実行用の情報コンテナを利用したＣ／Ｃ＋＋でのプログラムの実行も可能とする情報系エンジニア向けの開発環境を用意している。Ｃ／Ｃ＋＋プログラムを使ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の適用をスムーズに行うことも可能としている。 情報処理プログラムは最大４つの独立した情報コンテナで管理でき、制御動作を行っている最中にも情報処理プログラムを書き換えることができるオンライン変更機能を実現した。」（第６４頁左欄３行ないし第６５頁右欄１０行）（当審注：上記記載の「情報処理プログラム」は「情報プログラム」の意味で使用されていると認められる。） 第６３頁の図１「ＨＸハイブリッド」のコンセプトでは、「ＨＸハイブリッド」と「クラウドシステム／上位システム」は、情報系ネットワークを通じて接続されている。また、「各種産業用機械／装置」が接続される「フィールドネットワーク」と「クラウドシステム／上位システム」は、シームレスな接続で接続されている。 上記記載から、甲第１号証には以下の発明（以下、「引用発明１」という。）が記載されている。 「汎用プロセッサとＯＳというオープンなハードウェアを用いるＨＸハイブリッドモデルであって、 各種ネットワーク機能と、 制御ロジック（制御内容を記述したプログラム）と情報プログラムを備え、 制御動作と情報処理をそれぞれ独立に実行できるようにする仕組みの制御コンテナと情報コンテナを搭載し、 製造現場や設備・機械の動作を制御する制御ロジック（制御内容を記述したプログラム）は制御ロジック開発環境で制御動作を記述しデバッグを行い、情報プログラムは情報プログラム開発環境で情報処理を記述しデバッグを行い、それぞれのコンテナに格納し実行することで、製造現場と情報システムの接続をシームレスに実現し、 リアルタイム制御動作のための入力信号や出力信号のほか、製造現場で使用される機器を接続するために、制御ネットワークとしてＥｔｈｅｒＣＡＴに対応し、その他の制御ネットワークとして、ＰＲＯＦＩＮＥＴやＰＲＯＦＩＢＵＳ、ＤｅｖｉｃｅＮｅｔ、ＦＬ－ｎｅｔ、Ｍｏｄｂｕｓなどにも対応が可能となっており、 情報系ネットワークについては、ＯＰＣ ＵＡ（Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｏｒｏｌ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ機能を有し、Ｃ／Ｃ＋＋プログラムを使ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の適用をスムーズに行うことも可能としており、 情報プログラムは最大４つの独立した情報コンテナで管理でき、制御動作を行っている最中にも情報プログラムを書き換えることができる、 ＨＸハイブリッドモデル。」 また上記記載から、甲第１号証には以下の発明（以下、「引用発明２」という。）が記載されている。 「汎用プロセッサとＯＳというオープンなハードウェアを用いるＨＸハイブリッドモデルと、 クラウドシステム／上位システムと を備え、 ＨＸハイブリッドモデルは、 各種ネットワーク機能と、 制御ロジック（制御内容を記述したプログラム）と情報プログラムを備え、 制御動作と情報処理をそれぞれ独立に実行できるようにする仕組みの制御コンテナと情報コンテナを搭載し、 製造現場や設備・機械の動作を制御する制御ロジック（制御内容を記述したプログラム）は制御ロジック開発環境で制御動作を記述しデバッグを行い、情報プログラムは情報プログラム開発環境で情報処理を記述しデバッグを行い、それぞれのコンテナに格納し実行することで、製造現場と情報システムの接続をシームレスに実現し、 リアルタイム制御動作のための入力信号や出力信号のほか、製造現場で使用される機器を接続するために、制御ネットワークとしてＥｔｈｅｒＣＡＴに対応し、その他の制御ネットワークとして、ＰＲＯＦＩＮＥＴやＰＲＯＦＩＢＵＳ、ＤｅｖｉｃｅＮｅｔ、ＦＬ－ｎｅｔ、Ｍｏｄｂｕｓなどにも対応が可能となっており、 情報系ネットワークについては、ＯＰＣ ＵＡ（Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｏｒｏｌ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ機能を有しており、ＯＰＣ ＵＡサーバ機能を使って簡単に情報システムと双方向でデータを交換し、Ｃ／Ｃ＋＋プログラムを使ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の適用をスムーズに行うことも可能としており、 情報プログラムは最大４つの独立した情報コンテナで管理でき、制御動作を行っている最中にも情報プログラムを書き換えることができ、 クラウドシステム／上位システムとフィールドネットワークとは、シームレスな接続がされている、 システム。」 （２）甲第２号証（打越浩幸、「超入門 Ｄｏｃｋｅｒ：第１回 Ｄｏｃｋｅｒとは」、［ｏｎｌｉｎｅ］、２０１７年１月３０日、アイティメディア株式会社、［２０２１年２月１７日検索］、インターネット<URL:https://www.atmarkit.co.jp/ait/articles/1701/30/news037.hml>）には、図面とともに以下の記載がある。 「『Ｄｏｃｋｅｒ（ドッカー）』とは、非常に軽量なコンテナ型のアプリケーション実行環境である。ｄｏｔＣｌｏｕｄ社（現Ｄｏｃｋｅｒ社）が開発し、２０１３年にオープンソースのプロジェクトとして公開された。ソフトウェアの高速な配布・実行や容易なイメージのカスタマイズ、導入運用の手軽さ、豊富なプレビルドイメージの提供などの理由により、当初はソフトウェアの開発やテスト段階における利用が多かったが、現在ではパブリッククラウドからオンプレミスシステムまで、さまざまなシーンで急速に普及しつつある。」 「これに対してコンテナ型の仮想化環境とは、Ｌｉｎｕｘカーネルが持つ「コンテナ」機能などを使って、実行環境を他のプロセスから隔離し、その中でアプリケーションを動作させる技術である。」 「Ｄｏｃｋｅｒの実行環境 Ｄｏｃｋｅｒでは、最終的なアプリケーションはホストＯＳ中の１つのプロセスとして実行されているため、余計なオーバーヘッドがない。ただし通常のＬｉｎｕｘのプロセスと違って、Ｌｉｎｕｘカーネルのサポートする「コンテナ」技術などをベースにしている。コンテナは、他のプロセスから隔離された、ある程度独立したプロセス実行環境である。コンテナごとにファイルシステムやネットワークインタフェース、名前空間などが独立している。図中の「Ｄｏｃｋｅｒ Ｅｎｇｉｎｅ」はＤｏｃｋｅｒのコンテナの実行をサポートするためのモジュールであり、外部からはＤｏｃｋｅｒ ＡＰＩを使って制御される。Ｄｏｃｋｅｒ機能をインストールして、コンテナを実行できるようにしたＬｉｎｕｘシステム全体をまとめてＤｏｃｋｅｒホストと呼ぶ。１つのＤｏｃｋｅｒホスト内では複数のコンテナを実行できる。」 図「Ｌｉｎｕｘ＋Ｄｏｃｋｅｒサーバ」において、コンテナプロセスは、コンテナごとに仮想ネットワークＩ／Ｆを備え、このＩ／Ｆを介しＬｉｎｕｘ ＯＳ上に実装されたＤｏｃｋｅｒ Ｅｎｇｉｎｅを通じてＬｉｎｕｘ ＯＳと通信していると認められる。 上記記載から、甲第２号証には、以下の事項（以下、「甲第２号証記載事項」）が記載されている。 「Ｌｉｎｕｘカーネルが持つ「コンテナ」機能などを使って、実行環境を他のプロセスから隔離し、その中でアプリケーションを動作させる技術である、コンテナ型のアプリケーション実行環境であるＤｏｃｋｅｒにおいて、各コンテナはコンテナごとに仮想ネットワークＩ／Ｆを備え、このＩ／Ｆを介しＬｉｎｕｘ ＯＳ上に実装されたＤｏｃｋｅｒ Ｅｎｇｉｎｅを通じてＬｉｎｕｘ ＯＳと通信していること。」 （３）甲第３号証（特開２０１７－１３８８９５号公報）には、図面とともに以下の記載がある。 「【技術分野】 【０００１】 本発明は、仮想化環境管理システムおよび仮想化環境管理方法に関するものであり、具体的には、仮想環境における余剰リソースの抑制を図り、効率的なシステム運用を可能とする技術に関する。」 「【００１６】 ここで、本実施形態の仮想化環境とは、コンテナ型仮想環境である。コンテナ型仮想化環境では、いわゆるハイパーバイザ型の仮想化環境とは異なり、１台のハードウェア上の１つのＯＳに、それぞれが単体のサーバ装置とみなせるコンテナを複数配置して構成した仮想化環境である。本実施形態の場合、各コンテナは各業務システムや業務アプリケーションなどを実現するものとなる。 【００１７】 こうしたコンテナは、既に起動しているＯＳ上のプロセスとして起動されるため、高速起動が可能である。また、各コンテナは、ミドルウェアとアプリケーションおよびそれらが利用するライブラリを一体に備える構成であり、異なるハードウェア（サーバ装置）やクラウド間で移動させることも容易という特徴もある。」 上記記載から、甲第３号証には、以下の事項（以下、「甲第３号証記載事項」）が記載されている。 「コンテナ型仮想環境において、各コンテナは、ミドルウェアとアプリケーションおよびそれらが利用するライブラリを一体に備える構成とすること。」 （４）甲第４号証（「ＩｏＴ対応産業用コントローラ ＰＡＣシステム ＨＸシリーズ ＨＦ－Ｗ／ＩｏＴシリーズ」、株式会社日立産業システム、２０１７年１０月）には、図面とともに以下の記載がある。 「ＨＸシリーズ ハイブリッドモデル」（第９頁１行） 「１台のＣＰＵで制御プログラムと情報処理プログラム（Ｃ言語プログラム）の実装と動作が可能」（第９頁中段） 「ハイブリッドモデル環境設定用Ｗｅｂ管理ツール搭載 情報処理プログラムのアップロードや動作パラメータの設定、モニタは汎用Ｗｅｂブラウザで行えます。」（第９頁右下欄） 第９頁右下欄の「情報処理プログラムのアップロードや動作パラメータの設定、モニタは汎用Ｗｅｂブラウザで行えます。」の記載、および第１０頁上段の図においてＯＳ上にシステム設定Ｗｅｂサーバが実装されていることから、このシステム設定Ｗｅｂサーバは、情報処理プログラムの動作パラメータの設定に用いられていることがわかる。 第９頁中段の「１台のＣＰＵで制御プログラムと情報処理プログラム（Ｃ言語プログラム）の実装と動作が可能」の記載から、情報処理プログラムは実行可能となっている。そして、プログラムが実行可能となるためには、実行オブジェクトが必要であることは明らかであるから、甲第４号証記載の「ＨＸシリーズ ハイブリッドモデル」も、実行オブジェクトを備えていると認められる。 第９頁右下欄の「情報処理プログラムのアップロードや動作パラメータの設定、モニタは汎用Ｗｅｂブラウザで行えます。」の記載から、「情報処理プログラム」の「動作パラメータ」の設定を行う際に必要な項目の定義や、「パラメータ」の設定を行った結果としての設定結果を、甲第４号証記載の「ＨＸシリーズ ハイブリッドモデル」も、当然備えていると認められる。 第１０頁上段の「最大４本の情報処理プログラムを仮想コントローラとして並列動作可能」の図において、ＨＸハードウェア上にＯＳが実装され、その上に、情報処理プログラムや制御プログラムが実装されているとともに、システム設定Ｗｅｂサーバや、アプリケーション管理が実装されていることがわかる。 上記記載から、甲第４号証には、以下の事項（以下、「甲第４号証記載事項」）が記載されている。 「ＨＸシリーズ ハイブリッドモデルにおいて、情報処理プログラムには、その実行オブジェクトと、システム設定Ｗｅｂサーバを用いて汎用Ｗｅｂブラウザで情報プログラムの動作パラメータを設定する際に必要な項目の定義や、パラメータの設定を行った結果としての設定結果を備えること。」 （５）甲第５号証（「日立 ＩｏＴ対応産業用コントローラ ＨＸシリーズ アプリケーションマニュアル（サービスマニュアル）ハイブリッドモデル編」、株式会社日立産機システム、２０１８年２月、ＮＪＩ－６５３）には、図面とともに以下の記載がある。 「Ｃ言語プログラム管理用Ｗｅｂサーバ機能 Ｃ言語プログラムの管理は、ＰＣの汎用Ｗｅｂブラウザから本製品本体のＷｅｂサーバにアクセスして行います。専用ソフトのＰＣインストールは不要です。」（第２－３頁下段） 上記記載から、甲第５号証には、以下の事項（以下、「甲第５号証記載事項」）が記載されている。 「ＨＸシリーズ ハイブリッドモデルにおいて、Ｃ言語プログラムの管理は、ＰＣの汎用Ｗｅｂブラウザから本製品本体のＷｅｂサーバにアクセスして行うこと。」 ３ 当審の判断 （１）本件発明１について （１－１）引用文献：甲第１号証、甲第２号証 ア 対比 （ア）引用発明１は、「各種ネットワーク機能」を備え、「制御ネットワークとしてＥｔｈｅｒＣＡＴに対応」するとともに、「その他の制御ネットワーク」に対応可能であるから、このことは、本件発明１の「異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェース」を備えることに相当する。 （イ）引用発明１の「ＯＳ」を「汎用プロセッサ」で実行する際に、メモリに格納することは自明の事項である。 また、「制御ロジック」は「制御内容を記述したプログラム」であるから、プログラムの一種である。そして、「制御ロジック」や「情報プログラム」を「汎用プロセッサ」で実行するために、メモリに格納することも自明の事項である。 そうすると、引用発明１の「ＯＳ」や「制御ロジック」及び「情報プログラム」を実行するために、引用発明１は、本件発明１の「ＯＳ（Operating System）を含む複数のプログラムが格納されるメモリ」と同様の構成を備えている。 （ウ）引用発明１の「汎用プロセッサ」は、上記（ア）で検討した「複数の通信インターフェース」や、上記（イ）で検討した「メモリ」に接続されることは明らかであるから、引用発明１の「汎用プロセッサ」は、本件発明１の「前記複数の通信インターフェースと前記メモリとに接続され前記複数のプログラムを実行するプロセッサ」に相当する。 （エ）引用発明１の「制御ロジック」及び「情報プログラム」は、プログラムであるから「ＯＳ」上で実行されている。 また、「制御ロジック」及び「情報プログラム」をアプリと呼ぶことは任意であるから、引用発明１の「制御ロジック」及び「情報プログラム」は、本件発明１の「第２アプリ」に相当する。 引用発明１の「ＨＸハイブリッドモデル」は、リアルタイム制御動作のための入力信号や出力信号のほか、製造現場で使用される機器を接続するために、「ＥｔｈｅｒＣＡＴ」、「ＰＲＯＦＩＮＥＴ」、「ＰＲＯＦＩＢＵＳ」、「ＤｅｖｉｃｅＮｅｔ」、「ＦＬ－ｎｅｔ」、「Ｍｏｄｂｕｓ」などの「制御ネットワーク」を使用しており、この「制御ネットワーク」を使用して「制御ロジック」は製造現場や設備・機械の動作を制御している。 また、引用発明１の「情報プログラム」が使用する「情報系ネットワーク」は、ＯＰＣ ＵＡ（Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｏｒｏｌ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ機能を有し、Ｃ／Ｃ＋＋プログラムを使ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の適用をスムーズに行うことも可能としているのであるから、引用発明１の「情報プログラム」は、ＩＰの使用を前提として開発されたものである。 そうすると、引用発明１の「制御ロジック」及び「情報プログラム」は、本件発明１の「一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリ」に相当する。 加えて、引用発明１の「情報プログラム」は、「最大４つの独立した情報コンテナで管理でき、制御動作を行っている最中にも情報プログラムを書き換えることができる」プログラムであり、制御動作を行っている最中にも情報プログラムを書き換えるためには、プログラムのインストール及びアンインストールについて任意のタイミングで行うことが可能であることは明らかである。 そうすると、引用発明１の「情報プログラム」は、本件発明１の「任意にインストールされ任意にアンインストール可能なアプリ」に相当する。 してみると、引用発明１の「制御ロジック」及び「情報プログラム」と、本件発明１の 「前記複数のプログラムは、前記ＯＳ上で実行される第１アプリと、前記ＯＳ上で実行される一つ又は複数の第２アプリとを含み、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 前記第１アプリは、前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである」こととは、 「前記複数のプログラムは、前記ＯＳ上で実行される一つ又は複数の第２アプリとを含み、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリである」点で共通する。 （オ）引用発明１の「ＨＸハイブリッドモデル」は、汎用プロセッサとＯＳというオープンなハードウェアを用いるものであり、また、「制御ネットワーク」や「ＩＰ」を利用するものであるから、汎用プロセッサとＯＳというオープンなハードウェアに適用された通信モジュールということができる。 そうすると、引用発明１の「ＨＸハイブリッドモデル」は、本件発明１の「通信モジュール」に対応する。 （カ）してみると、本件発明１と引用発明１とは、以下の点で一致し、また相違する。 ［一致点］ 「異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースと、 ＯＳ（Operating System）を含む複数のプログラムが格納されるメモリと、 前記複数の通信インターフェースと前記メモリとに接続され前記複数のプログラムを実行するプロセッサと を備え、 前記複数のプログラムは、前記ＯＳ上で実行される一つ又は複数の第２アプリとを含み、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリである、 通信モジュール。」 ［相違点１］ 本件発明１は「複数のプログラム」が 「前記複数のプログラムは、前記ＯＳ上で実行される第１アプリと、前記ＯＳ上で実行される一つ又は複数の第２アプリとを含み、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 前記第１アプリは、前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである」 のに対して、引用発明１は、「複数のプログラム」について、上記「第２アプリ」に相当するプログラムであるとの明示はあるものの、「前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである」、「第１アプリ」について明示されていない点。 イ 相違点についての当審判断 上記相違点１について、検討する。 引用発明１は、「制御ロジック」や「情報プログラム」を「コンテナ」に格納し実行しているが、この「コンテナ」について、甲第２号証記載事項にあるＤｏｃｋｅｒを用いることは、当業者が容易に想到することである。 また、Ｄｏｃｋｅｒを利用する際には「Ｄｏｃｋｅｒ Ｅｎｇｉｎｅ」を必要とし、甲第２号証記載事項にある「Ｄｏｃｋｅｒ Ｅｎｇｉｎｅ」は、アプリケーションとＯＳとの間に存在するソフトウェアであるから、ミドルウェアということができる。 そして、引用発明１の「コンテナ」について、甲第２号証記載事項を適用した際に、引用発明１にミドルウェアである「Ｄｏｃｋｅｒ Ｅｎｇｉｎｅ」が採用されることとなるから、引用発明１は、「前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリ」を備えることとなる。 そうすると、本件発明１は、引用発明１及び甲第２号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 （１－２）引用文献：甲第１号証、甲第３号証 上記相違点１について、検討する。 甲第３号証記載事項にあるように、 「コンテナ型仮想環境において、各コンテナは、ミドルウェアとアプリケーションおよびそれらが利用するライブラリを一体に備える構成とすること。」 は周知の構成であるから、引用発明１の各「コンテナ」について、「コンテナ」内のアプリケーションを実行する際に、ＯＳとアプリケーションとの間にミドルウェアを設けるようにすることは、当業者が容易に想到することである。 そうすると、本件発明１は、引用発明１及び甲第３号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 （２）本件発明２について 引用文献：甲第１号証、甲第２号証、甲第３号証、甲第４号証 甲第４号証記載事項にあるように、 「ＨＸシリーズ ハイブリッドモデルにおいて、情報処理プログラムには、その実行オブジェクトと、システム設定Ｗｅｂサーバを用いて汎用Ｗｅｂブラウザで情報プログラムの動作パラメータを設定する際に必要な項目の定義や、パラメータの設定を行った結果としての設定結果を備えること。」 は、公知の事項であるから、同じ「ＨＸハイブリッドモデル」である引用発明１に上記甲第４号証記載事項を適用し、また、その際に、情報プログラムの実行オブジェクトと、情報プログラムの動作パラメータを設定するための項目の定義やパラメータの設定を行った結果としての設定結果を一つの構造体として格納することは、本件特許の出願時の技術常識からみて、当業者が容易になしえることである。 また、その際、汎用Ｗｅｂブラウザで情報プログラムの動作パラメータを設定するのであるから、本件発明２の 「前記第１アプリが、 指定された第２アプリの設定定義オブジェクトを基に、当該設定定義オブジェクトが表す一つ以上の設定項目について一つ以上の設定値を受け付けるＵＩ（User Interface）である設定画面を生成し、 当該生成した設定画面を提供し、 当該設定画面が表す一つ以上の設定項目について当該設定画面に入力された一つ以上の設定値を、前記指定された第２アプリの設定オブジェクトに登録する、」 と同様の動作を行うこととなる。 そうすると、本件発明２は、引用発明１及び甲第２号証ないし甲第４号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 （３）本件発明３について 引用文献：甲第１号証、甲第２号証、甲第３号証、甲第４号証、甲第５号証 甲第４号証記載事項や甲第５号証記載事項にあるように、ＨＸシリーズ ハイブリッドモデルにおいて、アプリケーションの設定を行うための設定画面をＷｅｂブラウザにより表示することは公知の技術であり、引用発明１において、同様の技術を採用することに格別の困難性は認められない。 そうすると、本件発明３は、引用発明１及び甲第２号証記載事項ないし甲第５号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 （４）本件発明４について 引用文献：甲第１号証、甲第２号証、甲第３号証、甲第４号証 本件特許の出願時の技術常識からみて、汎用プロセッサとＯＳというオープンなハードウェアを用いる際、オブジェクトをファイルとして、ファイルシステムで管理することは普通に行われていることである。 また、ファイルを所定のディレクトリに格納し管理することも普通に行われることであるから、引用発明１において、本件発明４の「アプリ構造体」に対応する構造体を、ファイルシステムにおける所定のディレクトリに格納し、構造体を構成する各オブジェクトをファイルとして管理することは、当業者が容易に想到することである。 そして、ファイルのインストールが行われているか否かを、そのファイルが格納されるディレクトリを参照することにより確認することも、普通に行われることである。 そうすると、本件発明４は、引用発明１及び甲第２号証記載事項ないし甲第４号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 （５）本件発明５について 引用文献：甲第１号証、甲第２号証、甲第３号証、甲第４号証 甲第１号証第６４頁記載の「図２｜ＳＤＣコンセプト」を参照すると、工場Ｂ、Ｃの情報プログラムが、工場Ｂ、Ｃ以外のエンティティである、「開発環境」で示されるエンティティ（本件発明５の「前記通信モジュールのエンドユーザ以外のエンティティ」に相当する。）から更新されていることが示されている。 そうすると、本件発明５は、引用発明１及び甲第２号証記載事項ないし甲第４号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 （６）本件発明１０について 引用文献：甲第１号証、甲第２号証、甲第３号証 ア 対比 （ア）上記（１）（１－１）アで検討したように、引用発明１の「ＨＸハイブリッドモデル」は、本件発明１の「通信モジュール」に対応するから、引用発明２の「ＨＸハイブリッドモデル」は、本件発明１０の「通信モジュール」に対応する。 （イ）引用発明２の「ＨＸハイブリッドモデル」は、「各種ネットワーク機能」を備え、「制御ネットワークとしてＥｔｈｅｒＣＡＴに対応」するとともに、「その他の制御ネットワーク」に対応可能であるから、このことは、本件発明１０の「通信モジュール」が「異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェース」を有することに相当する。 （ウ）本件特許の出願時の技術常識を参酌すると、引用発明２の「クラウドシステム／上位システム」は、通常サーバにより構成されるものであるから、引用発明２の「クラウドシステム／上位システム」は、本件発明１０の「サーバ」に相当する。 （エ）引用発明２の「ＯＳ」は、本件発明１０の「ＯＳ（Operating System）」に相当する。 また、引用発明２の「制御ロジック」及び「情報プログラム」は、プログラムであるから「ＯＳ」上で実行されている。 そして、「制御ロジック」及び「情報プログラム」をアプリと呼ぶことは任意であるから、引用発明２の「制御ロジック」及び「情報プログラム」は、本件発明１０の「第２アプリ」に相当する。 引用発明２の「ＨＸハイブリッドモデル」は、リアルタイム制御動作のための入力信号や出力信号のほか、製造現場で使用される機器を接続するために、「ＥｔｈｅｒＣＡＴ」、「ＰＲＯＦＩＮＥＴ」、「ＰＲＯＦＩＢＵＳ」、「ＤｅｖｉｃｅＮｅｔ」、「ＦＬ－ｎｅｔ」、「Ｍｏｄｂｕｓ」などの「制御ネットワーク」を使用し、「制御ロジック」が、製造現場や設備・機械の動作を制御している。 また、引用発明２の「情報プログラム」が使用する「情報系ネットワーク」は、ＯＰＣ ＵＡ（Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｏｒｏｌ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ機能を有し、Ｃ／Ｃ＋＋プログラムを使ってＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）の適用をスムーズに行うことも可能としているのであるから、引用発明２の「情報プログラム」は、ＩＰの使用を前提として開発されたものである。 そうすると、引用発明２の「制御ロジック」及び「情報プログラム」は、本件発明１０の「一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリ」に相当する。 そして、引用発明２の「情報プログラム」は、「最大４つの独立した情報コンテナで管理でき、制御動作を行っている最中にも情報プログラムを書き換えることができる」プログラムであり、制御動作を行っている最中にも情報プログラムを書き換えるためには、プログラムのインストール及びアンインストールについて任意のタイミングで行うことが可能であることは明らかである。 そうすると、引用発明２の「情報プログラム」は、本件発明１０の「任意にインストールされ任意にアンインストール可能なアプリ」に相当する。 してみると、引用発明２の「ＨＸハイブリッドモデル」が「汎用ＯＳ」及び、「制御ロジック（制御内容を記述したプログラム）と情報プログラムを備え」ることと、本件発明１０の 「ＯＳ（Operating System）と、当該ＯＳ上で実行される第１アプリと、当該ＯＳ上で実行される一つ又は複数の第２アプリとを有し、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 前記第１アプリは、前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである」こととは、 「ＯＳ（Operating System）と、当該ＯＳ上で実行される一つ又は複数の第２アプリとを有し、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリである」点で共通する。 （オ）引用発明２の「ＨＸハイブリッドモデル」は、リアルタイム制御動作のための入力信号や出力信号のほか、製造現場で使用される機器を接続するために、「ＥｔｈｅｒＣＡＴ」、「ＰＲＯＦＩＮＥＴ」、「ＰＲＯＦＩＢＵＳ」、「ＤｅｖｉｃｅＮｅｔ」、「ＦＬ－ｎｅｔ」、「Ｍｏｄｂｕｓ」などの「制御ネットワーク」を使用しており、この「制御ネットワーク」を使用して「制御ロジック」は製造現場や設備・機械の動作を制御している。その際に、製造現場や設備・機械から必要なデータを受信しているから、この「制御ロジック」は、本件発明１０の「第１の第２アプリが、当該第１の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、当該通信インターフェースに接続されている機器からデータを受信」することと同様の動作を行っている。 （カ）引用発明２は「情報系ネットワークについては、ＯＰＣ ＵＡ（Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ ｆｏｒ Ｐｒｏｃｅｓｓ Ｃｏｎｔｏｒｏｌ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）サーバ機能を有しており、ＯＰＣ ＵＡサーバ機能を使って簡単に情報システムと双方向でデータを交換し」ており、このサーバ機能を使ったデータ交換は、本件発明１０の「前記第１の第２アプリそれ自体又は別の第２アプリである第２の第２アプリが、当該第２の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、前記サーバにデータを送信する」ことに相当する。 （キ）引用発明２の「汎用プロセッサとＯＳというオープンなハードウェアを用いるＨＸハイブリッドモデルと、クラウドシステム／上位システムとを備え」るシステムは、通信を行っているシステムであるから、本件発明１０の「通信システム」に対応する。 （ク）してみると、本件発明１０と引用発明２とは、以下の点で一致し、また相違する。 ［一致点］ 「異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースを有する通信モジュールと、 サーバと を備え、 前記通信モジュールが、ＯＳ（Operating System）と、当該ＯＳ上で実行される一つ又は複数の第２アプリとを有し、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 第１の第２アプリが、当該第１の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、当該通信インターフェースに接続されている機器からデータを受信し、 前記第１の第２アプリそれ自体又は別の第２アプリである第２の第２アプリが、当該第２の第２アプリに対応した通信プロトコルに従う通信が行われる通信インターフェース規格に対応した通信インターフェース経由で、前記サーバにデータを送信する、 通信システム。」 ［相違点２］ 本件発明１０は「複数のプログラム」が 「前記複数のプログラムは、前記ＯＳ上で実行される第１アプリと、前記ＯＳ上で実行される一つ又は複数の第２アプリとを含み、 前記一つ又は複数の第２アプリのうちの一つ以上の第２アプリの各々は、一つ以上の通信インターフェース規格上での一つ以上の通信プロトコルに従う通信を行うアプリであり、且つ、任意にインストールされ任意にアンインストール可能なアプリであり、 前記第１アプリは、前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである」 のに対して、引用発明２は、「複数のプログラム」について、上記「第２アプリ」に相当するプログラムの明示はあるものの、「前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリである」、「第１アプリ」について明示されていない点。 イ 相違点についての当審判断 上記相違点２について、検討する。 上記（１）の（１－１）や（１－２）で検討したように、甲第２号証記載事項や、甲第３号証記載事項に基づいて、引用発明２に「前記ＯＳと前記一つ又は複数の第２アプリとの間のミドルウェアとしてのアプリ」を備えることとすることは、当業者が容易になしえることである。 そうすると、本件発明１０は、引用発明２及び甲第２号証記載事項ないし甲第３号証記載事項に基づいて、当業者が容易に発明をすることができたものである。 ４ 取消理由についてのまとめ 以上のとおりであるから、本件発明１ないし５及び１０は、甲第１号証ないし甲第５号証に基づいて当業者が容易に発明ができたものであるから、本件発明１ないし５及び１０に係る特許は、特許法第２９条第２項の規定に違反してされたものである。 第５ 取消理由通知において採用しなかった特許異議申立理由について 特許異議申立人は、特許異議申立書において、訂正前の特許請求の範囲に関し、請求項２０に係る発明は、甲第１号証に記載された発明並びに甲第２号証及び甲第３号証に記載された事項から、当業者が容易に発明をすることができたものである旨主張する。 しかしながら、本件発明２０は、令和３年８月２７日に特許権者から提出された訂正請求書により、上記第２で検討した 「【請求項２０】 異なる複数種類の通信インターフェース規格に対応した複数の通信インターフェースと、ＯＳ（Operating System）と、当該ＯＳ上で実行される第１アプリと監視アプリとを有する通信モジュールに、通信に使用される通信インターフェース規格に対応し当該ＯＳ上で実行され任意にアンインストール可能な第２アプリをインストールし、 前記ＯＳと前記第２アプリとの間のミドルウェアとしてのアプリである第１アプリ経由で前記第２アプリについて設定された通信タイミングで、当該第２アプリが、当該第２アプリに対応した通信インターフェース規格上での通信プロトコルに従う通信を行い、 前記第２アプリのリソース使用量が前記ＯＳにより前記通信モジュールが有するメモリに格納されるようになっており、 前記監視アプリが、 前記第２アプリのリソース使用量を前記第１アプリに問い合わせ、 当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、前記第２アプリ経由又は非経由で、サーバに送信する、 通信方法。」（下線は、訂正箇所を示す。） と訂正された。 そして、上記「前記第２アプリのリソース使用量が前記ＯＳにより前記通信モジュールが有するメモリに格納されるようになっており、 前記監視アプリが、 前記第２アプリのリソース使用量を前記第１アプリに問い合わせ、 当該問合せに応答して前記第１アプリにより前記メモリから取得され前記第１アプリから回答されたリソース使用量を表すデータを、前記第２アプリ経由又は非経由で、サーバに送信する」ことは、甲第１号証ないし甲第３号証には記載されておらず、又周知の事項であるともいえない。 そうすると、本件発明２０は、甲第１号証ないし甲第３号証に基づいて当業者が容易に発明をすることができたものではない。 第６ むすび 以上のとおりであるから、請求項１ないし５及び１０に係る特許は、特許法第２９条第２項の規定に違反してされたものであり、同法第１１３条第２号に該当するから、取り消されるべきものである。 また、請求項２０に係る特許は、特許異議申立書に記載した特許異議申立理由によっては取り消することはできない。さらに、他に請求項２０に係る特許を取り消すべき理由を発見しない。 よって、結論のとおり決定する。