2021-012067

特願２０１９－１２２６３３「インテリジェント運転自動車の通信システム、通信方法、端末装置、及び記憶媒体」拒絶査定不服審判事件〔令和 ２年 ３月１２日出願公開、特開２０２０－ ３８６１６〕について、次のとおり審決する。

結 論 本件審判の請求は、成り立たない。

理 由 第１ 手続の経緯 本願は、令和元年７月１日（パリ条約による優先権主張２０１８年８月３１日（以下、「優先日」という。） 中国）の出願であって、その手続の経緯は以下のとおりである。 令和２年 ９月 ８日付け：拒絶理由通知書 令和２年１２月１１日 ：意見書、手続補正書の提出 令和３年 ５月１２日付け：拒絶査定 令和３年 ９月１０日 ：審判請求書、手続補正書の提出 令和４年 ８月２６日付け：拒絶理由通知書 令和４年１１月２４日 ：意見書、手続補正書の提出 令和４年１２月 ９日付け：拒絶理由（最後の拒絶理由）通知書 令和５年 ３月１０日 ：意見書、手続補正書の提出 第２ 令和５年３月１０日にされた手続補正についての補正の却下の決定 ［補正の却下の決定の結論］ 令和５年３月１０日にされた手続補正（以下「本件補正」という。）を却下する。 ［理由］ １ 本件補正について（補正の内容） （１）本件補正後の特許請求の範囲の記載 本件補正により、特許請求の範囲の請求項１の記載は、次のとおり補正された。（下線部は、補正箇所である。） 「 車載端末と、複数のアプリケーションモジュールとを備えるインテリジェント運転自動車の通信システムであって、 前記車載端末は、他のインテリジェント運転自動車またはサーバと通信する外部通信モジュールと、前記インテリジェント運転自動車の、前記車載端末の外部にある前記アプリケーションモジュールと通信する内部通信モジュールとを備え、 複数の前記アプリケーションモジュールが、前記内部通信モジュールと通信し、 複数の前記アプリケーションモジュールと前記内部通信モジュールとが、非Ｓｏｃｋｅｔ方式であるサービス式通信方式で通信し、前記外部通信モジュールと、前記他のインテリジェント運転自動車またはサーバとがメッセージ式通信方式で通信し、 前記サービス式通信方式は、ＲＰＣ方式であり、前記メッセージ式通信方式は、Ｓｏｃｋｅｔ方式である、インテリジェント運転自動車の通信システム。」 （２）本件補正前の特許請求の範囲 本件補正前の、令和４年１１月２４日に手続補正により補正された特許請求の範囲の請求項１の記載は次のとおりである。 「 車載端末と、複数のアプリケーションモジュールとを備えるインテリジェント運転自動車の通信システムであって、 前記車載端末は、他のインテリジェント運転自動車またはサーバと通信する外部通信モジュールと、前記インテリジェント運転自動車の、前記車載端末の外部にある前記アプリケーションモジュールと通信する内部通信モジュールとを備え、 複数の前記アプリケーションモジュールが、前記内部通信モジュールと通信し、 複数の前記アプリケーションモジュールと前記内部通信モジュールとが、サービス式通信方式で通信し、前記外部通信モジュールと、前記他のインテリジェント運転自動車またはサーバとがメッセージ式通信方式で通信し、 前記サービス式通信方式は、ＲＰＣ方式であり、前記メッセージ式通信方式は、Ｓｏｃｋｅｔ方式である、インテリジェント運転自動車の通信システム。」 ２ 補正の適否 （１）補正の目的について 本件補正は、本件補正前の請求項１に記載された発明（以下、「本件補正前発明１」という。）を特定するために必要な事項である「サービス式通信方式」を「非Ｓｏｃｋｅｔ方式であるサービス式通信方式」と補正することを含むものである。 もっとも、本件補正前発明１は、「前記サービス式通信方式は、ＲＰＣ方式であり」との構成を含み、かつ、「ＲＰＣ方式」が「非Ｓｏｃｋｅｔ方式である」ことは、本願優先日前における技術常識であるところ、本件補正は、本件補正前発明１において「ＲＰＣ方式」であると特定されていた「サービス式通信方式」を何ら限定するものではなく、本件補正前発明１において自明な事項を単に付加するものにすぎない。 そして、そのような本件補正は、請求項の削除、特許請求の範囲の減縮、誤記の訂正及び明りょうでない記載の釈明のいずれをも目的とするものとは認められない。 よって、本件補正は、特許法第１７条の２第５項に規定する要件を満たしていない。 （２）新規事項について 令和４年１２月９日付けの拒絶理由では、「理由１（明確性要件）」として、 「請求項１ないし１５に係る発明は、「車載端末」と「サーバ」又は「他の車載端末」との間で使用する通信方式については、プログラム間の抽象的なプロトコルである「ＲＰＣ方式」のみを特定し、一方、「車載端末」と、当該「車載端末」の外部にある「アプリケーションモジュール」との間で使用する通信方式については、ネットワークインターフェースを規定する具体的なプロトコルである「Ｓｏｃｋｅｔ方式」のみを特定するものであり、そのことに、どのような技術的意義があるのか不明である。（請求項１ないし１５に係る発明は、「車載端末」と「サーバ」又は「他の車載端末」との間で使用する通信方式と、「車載端末」と、当該「車載端末」の外部にある「アプリケーションモジュール」との間で使用する通信方式として、いずれも、抽象的なプロトコルとしては「ＲＰＣ方式」を使用し、ネットワークインターフェースを規定する具体的なプロトコルとしては「Ｓｏｃｋｅｔ方式」を使用する態様を含むことに留意されたい。）」（下線は、強調のため当審が付与した。これ以降の下線についても同様。）との指摘をしており、令和５年３月１０日に提出された意見書において、請求人は、 「２．拒絶の理由１（特許法第３６条第６項第２号）について 上記のように、請求項１、８において、内部通信モジュールと複数のアプリケーションモジュールとの間のサービス式通信方式から「Ｓｏｃｋｅｔ方式」を排除し、サービス式通信方式として「Ｓｏｃｋｅｔ方式」ではない「非Ｓｏｃｋｅｔ方式」を用いることを明確化しました」と主張していることからすると、本件補正は、内部通信モジュールと複数のアプリケーションモジュールとの間の通信方式である「サービス式通信方式」のうち、ネットワークインターフェースを規定する具体的なプロトコルが「非Ｓｏｃｋｅｔ方式である」ことを明確にする、明りょうでない記載の釈明を目的としたものとも理解することも可能である。 ここで、願書に最初に添付した明細書（以下、「当初明細書」という。）、特許請求の範囲又は図面（以下、これらを総称して「当初明細書等」という。）の記載について検討するに、当初明細書の【０００３】の記載「従来技術において、現在の車両では、Ｓｏｃｋｅｔ（ソケット）との通信方式によりアプリケーション層データを車載機器に送信し、車載機器がＳｏｃｋｅｔの通信方式でアプリケーション層データを他の車両またはサーバに送信する。しかしながら、車両内のアプリケーションシーンがますます多くなり、アプリケーションを増加する場合、アプリケーション層と車載機器との間にＳｏｃｋｅｔプロトコルを修正する必要があるため、柔軟性が悪く、車両アプリケーションの増加、または減少する柔軟なニーズを満足することができない。」、同【０００６】の記載「本態様に係るインテリジェント運転自動車の通信システムにおいて、内部通信モジュールと複数のアプリケーションモジュールとがサービス式通信方式で通信し、外部通信モジュールと他のインテリジェント運転自動車またはサーバとがメッセージ式通信方式で通信する。これにより、サービス式通信方式によって車載端末と複数のアプリケーションモジュールとが通信する時に、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要がなく、アプリケーション層配置の柔軟性を大幅に向上することを実現することができる。」、同【００２０】の記載「本実施形態において、サービス式通信は、ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ、リモートプロシージャコール）であってもよい。」、同【００２３】の記載「ここで、ＲＰＣフレームワークは、ＧＲＰＣ（Ｇｏｏｇｌｅが支配的に開発したＲＰＣフレーム）、ＢＲＰＣ（Ｂａｉｄｕ－ＲＰＣ）及びＸＭＬＲＰＣ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ－ＲＰＣ、エクステンシブル マークアップ ランゲージ－リモートプロシージャコール）などを含むが、これらに限定されるものではない。」、同【００２４】の記載「なお、サービス式通信は、ＲＰＣ、ＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ、遠隔メソッド呼び出し）などを含むが、これらに限定されない。」、同【００２５】の記載「サービス式通信方式で通信する場合、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要がないため、アプリケーションの増加または減少時に、アプリケーション層と車載機器との間のＳｏｃｋｅｔプロトコルを修正する必要がなく、アプリケーション層配置の柔軟性が向上することを理解されたい。」、及び、同【００２６】の記載「以上により、本発明の一実施形態に係るインテリジェント運転自動車の通信システムにおいて、車載端末１００における内部通信モジュール１２０と複数のアプリケーションモジュール２００とがサービス式通信方式で通信し、車載端末１００における外部通信モジュール１１０と他のインテリジェント運転自動車またはサーバとがメッセージ式通信方式で通信する。これにより、サービス式通信方式によりアプリケーション層配置の柔軟性を大幅に向上することを実現することができる。例えば、アプリケーションを新たに追加する必要がある場合、サービスを直接に登録すればよく、異なるサービスは互いに独立し、互いに非干渉し、従来技術において車両アプリケーションを増加、または減少する時の柔軟性が悪いという課題が解決される。」によれば、当初明細書等には、車載端末と複数のアプリケーションモジュールとの間の通信方式である「サービス式通信方式」として、「ＲＰＣ」又はこれに類する通信方式を使用することにより、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要をなくすことで、車両アプリケーションの増加又は減少に柔軟に対応できるようにするという課題を解決することが記載されているといえる。そうすると、当初明細書等には、「車載端末」と「アプリケーションモジュール」との間の通信に、「ネットワーク技術プロトコル」すなわちネットワークインターフェースを規定する具体的なプロトコルの使用を回避することで課題を解決することが記載されているのであるから、内部通信モジュールと複数のアプリケーションモジュールとの間の通信方式である「サービス式通信方式」のうち、ネットワークインターフェースを規定する具体的なプロトコルが「非Ｓｏｃｋｅｔ方式である」ことが、当初明細書等に記載されているとはいえない。なお、外部のモジュールとの間の通信に何らかのネットワーク技術プロトコルを使用すること、及び、当該ネットワーク技術プロトコルとして、「非Ｓｏｃｋｅｔ方式」は、本願優先日前における技術常識又は周知技術ではあるが、当初明細書等には、当該技術常識又は周知技術とは異なる手段である、「ネットワーク技術プロトコル」すなわちネットワークインターフェースを規定する具体的なプロトコルの使用を回避することで課題を解決することが記載されている以上、上記技術常識又は周知技術のみを参酌して、「サービス通信方式」のうち、ネットワークインターフェースを規定する具体的なプロトコルが「非Ｓｏｃｋｅｔ方式である」ことが、実質的に当初明細書等に記載されているということはできない。 したがって、本件補正が、明りょうでない記載の釈明を目的としたものである場合には、本件補正は、当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において新たな技術的事項を導入しないものとはいえない。 よって、本件補正は、その目的が明りょうでない記載の釈明である場合には、当初明細書等に記載した事項の範囲内においてしたものではないから、特許法第１７条の２第３項に規定する要件を満たしていない。 ３ まとめ 以上のとおり、本件補正は、特許法第１７条の２第３項又は第５項の規定に違反するので、同法第５３条第１項の規定により上記結論のとおり決定する。 第３ 本願発明 令和５年３月１０日にされた手続補正は、上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、上記第２の１（２）のとおりのものである。 第４ 拒絶理由の概要 令和４年１２月９日付けで当審が通知した拒絶理由の概要は、次のとおりである。 理由１ （明確性要件） この出願は、特許請求の範囲の記載が、特許法第３６条第６項第２号に規定する要件を満たしていない。 理由２ （委任省令要件） この出願は、発明の詳細な説明の記載が、特許法第３６条第４項第１号に規定する要件を満たしていない。 理由３ （進歩性）この出願の請求項１及び８に係る発明は、その出願前に日本国内又は外国において頒布された以下の引用文献１ないし３に記載された発明に基いて、また、請求項２ないし７及び９ないし１５に係る発明は、以下の引用文献１ないし４に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 引用文献１ 米国特許出願公開第２０１７／０２５７３４５号明細書 引用文献２ 国際公開第２０１７／０４６８９９号 引用文献３ 国際公開第２０１８／０９５５５４号 引用文献４ 特表平８－５０４９７５号公報 以下、上記各理由について検討する。 第５ 理由１（明確性要件）について 特許を受けようとする発明が明確であるか否かは、特許請求の範囲の記載だけではなく、願書に添付した明細書の記載及び図面を考慮し、また、当業者の出願当時における技術常識を基礎として、特許請求の範囲の記載が、第三者に不測の不利益を及ぼすほどに不明確であるか否かという観点から判断されるべきである。 本願発明において、「車載端末」と「サーバ」又は「他の車載端末」との間では、「Ｓｏｃｋｅｔ方式」で、「車載端末」と、当該「車載端末」の外部にある「アプリケーションモジュール」との間では、「ＲＰＣ方式」で通信を行うものである。 ここで、「ＲＰＣ方式」は、プログラム間の通信を規定する抽象的なプロトコル、すなわちアプリケーション層における通信方式であり、「Ｓｏｃｋｅｔ方式」は、プログラムに対してネットワークインターフェースを規定する具体的なプロトコル、すなわちトランスポート層における通信方式であることは本願出願時（又は優先日前）の技術常識である。（必要であれば、https://www.web-dev-qa-db-ja.com/ja/sockets/socket%E3%81%A8rpc%E3%81%AE%E9%81%95%E3%81%84%E3%81%AF%E4%BD%95%E3%81%A7%E3%81%99%E3%81%8B%EF%BC%9F/834374870/（「SocketとRPCの違いは何ですか？」とのインターネット記事）を参考にされたい。） そうすると、本願発明は、「車載端末」と「サーバ」又は「他の車載端末」との間で使用する通信方式については、ネットワークインターフェースを規定する具体的なプロトコルである「Ｓｏｃｋｅｔ方式」のみを特定し、一方、「車載端末」と、当該「車載端末」の外部にある「アプリケーションモジュール」との間で使用する通信方式については、プログラム間の抽象的なプロトコルである「ＲＰＣ方式」のみを特定するものである。 また、上記第２の２（２）で述べたように、本願の明細書及び図面には、車載端末と複数のアプリケーションモジュールとの間の通信方式である「サービス式通信方式」として、「ＲＰＣ」又はこれに類する通信方式を使用することにより、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要をなくすことで、車両アプリケーションの増加又は減少に柔軟に対応できるようにするという課題を解決することが記載されているといえるが、本願発明は、「車載端末」と、当該「車載端末」の外部にある「アプリケーションモジュール」との間で、ネットワークインターフェースを規定する具体的なプロトコルを使用するのか否か、また、使用する場合には、どのようなプロトコルを使用するのか何ら特定がないため、本願発明の技術思想が明確であるとはいえない。 よって、本願発明は、第三者に不測の不利益を及ぼすほどに不明確であるといわざるを得ないから、特許法第３６条第６項第２項に規定する要件を満たしていない。 第６ 理由２（委任省令要件）について 上記第２の２（２）で述べたように、本願の明細書及び図面には、車載端末と複数のアプリケーションモジュールとの間の通信方式である「サービス式通信方式」として、「ＲＰＣ」又はこれに類する通信方式を使用することにより、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要をなくすことで、車両アプリケーションの増加又は減少に柔軟に対応できるようにするという課題を解決することが記載されているといえる。 一方、装置がその外部にあるモジュールと通信をするためには、プログラム間の抽象的なプロトコルのみならず、ネットワークインターフェースを規定する具体的なプロトコルを使用すること、すなわち、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要があることは、本願優先日前における技術常識である。 したがって、本願発明は、装置がその外部にあるモジュールとの間の通信にＳｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要があるとの技術常識に反し、車載端末とその外部にある複数のアプリケーションモジュールとの間の通信において、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要をなくすことで課題を解決するものであるが、明細書には、「サービス式通信方式」として、「ＲＰＣ」又はこれに類する通信方式を使用することにより、Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要がなくすことができる理由について何ら記載がなく、当然ながら、そのことが本願優先日前における技術常識から自明であるということはない。 また、本願発明は、車載端末と複数のアプリケーションモジュールとの通信にネットワークインターフェースを規定する具体的なプロトコルを使用すること、すなわち、「Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する」場合を含むが、明細書及び図面には、そのような場合であっても課題を解決することができることについてはまったく記載がなく、そのことが自明ともいえない。 よって、発明の詳細な説明は、本願発明の技術上の意義を理解するために必要な事項を記載したものではなく、経済産業省令で定めるところにより記載されたものでないから、特許法第３６条第４項第１号に規定する要件を満たしていない。 第７ 理由３（進歩性）について １ 引用文献の記載、引用発明等 （１）引用文献１について ア 引用文献１記載事項 引用文献１には、図面とともに、次の事項が記載されている。 （ア） 「[0023] FIG. 1 illustrates an example diagram of a system 100 configured to provide telematics services to a vehicle 102. The vehicle 102 may include various types of passenger vehicle, such as crossover utility vehicle (CUV), sport utility vehicle (SUV), truck, recreational vehicle (RV), boat, plane or other mobile machine for transporting people or goods. Telematics services may include, as some non-limiting possibilities, navigation, turn-by-turn directions, vehicle health reports, local business search, accident reporting, and hands-free calling. In an example, the system 100 may include the SYNC system manufactured by The Ford Motor Company of Dearborn, Mich. It should be noted that the illustrated system 100 is merely an example, and more, fewer, and/or differently located elements may be used. [0024] The computing platform 104 may include one or more processors 106 configured to perform instructions, commands and other routines in support of the processes described herein. For instance, the computing platform 104 may be configured to execute instructions of vehicle applications 110 to provide features such as navigation, accident reporting, satellite radio decoding, and hands-free calling. Such instructions and other data may be maintained in anon-volatile manner using a variety of types of computer-readable storage medium 112. The computer-readable medium 112 (also referred to as a processor-readable medium or storage) includes any non-transitory medium (e.g., a tangible medium) that participates in providing instructions or other data that may be read by the processor 106 of the computing platform 104. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and/or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C#, Objective C, Fortran, Pascal, JavaScript, Python, Perl, and PL/SQL. [0025] The computing platform 104 may be provided with various features allowing the vehicle occupants to interface with the computing platform 104. For example, the computing platform 104 may include an audio input 114 configured to receive spoken commands from vehicle occupants through a connected microphone 116, and auxiliary audio input 118 configured to receive audio signals from connected devices. The auxiliary audio input 118 may be a physical connection, such as an electrical wire or a fiber optic cable, or a wireless input, such as a BLUETOOTH audio connection. In some examples, the audio input 114 may be configured to provide audio processing capabilities, such as pre-amplification of low-level signals, and conversion of analog inputs into digital data for processing by the processor 106.」 （当審訳） 「[0023] 図１は、車両102にテレマティクスサービスを提供するように構成されたシステム100の例示図である。車両102は、クロスオーバーユーティリティビークル（CUV）、スポーツユーティリティビークル（SUV）、トラック、娯楽車両（RV）、ボート、飛行機、または人や物を輸送するための他の移動機械などの様々なタイプの乗用車を含むことができる。テレマティクスサービスは、いくつかの非限定的な可能性として、ナビゲーション、ターンバイターン方向指示、車両健康レポート、ローカルビジネス検索、事故報告、およびハンズフリー通話を含んでもよい。一例として、システム100は、ミシガン州ディアボーンのフォード・モーター・カンパニーによって製造されたSYNCシステムを含んでもよい。図示されたシステム100は単なる例示であり、より多くの、より少ない、及び／又は異なる位置にある要素が使用されてもよいことに留意されたい。 [0024] コンピューティングプラットフォーム104は、本明細書に記載されたプロセスをサポートする命令、コマンド、および他のルーチンを実行するように構成された１つまたは複数のプロセッサ106を含んでもよい。例えば、コンピューティングプラットフォーム104は、ナビゲーション、事故報告、衛星ラジオ復号化、及びハンズフリー通話などの機能を提供するために、車両アプリケーション110の命令を実行するように構成されてもよい。そのような命令および他のデータは、様々なタイプのコンピュータ可読記憶媒体112を用いて不揮発性で維持されてもよい。コンピュータ可読媒体112（プロセッサ可読媒体またはストレージとも呼ばれる）は、演算プラットフォーム104のプロセッサ106によって読み取られ得る命令または他のデータの提供に参加する任意の非一時的媒体（例えば、有形の媒体）を含む。コンピュータ実行可能な命令は、限定されないが、Java、C、C++、C#、Objective C、Fortran、Pascal、JavaScript、Python、Perl、およびPL/SQLを単独または組み合わせて含む、様々なプログラミング言語および/または技術を使用して作成したコンピュータプログラムからコンパイルまたは解釈することができる。 [0025] コンピューティングプラットフォーム104は、車両乗員がコンピューティングプラットフォーム104とインターフェースすることを可能にする様々な機能を提供してもよい。例えば、コンピューティングプラットフォーム104は、接続されたマイクロフォン116を介して車両乗員から話されたコマンドを受け取るように構成されたオーディオ入力114、および接続された装置からオーディオ信号を受け取るように構成された補助オーディオ入力118を含んでもよい。補助オーディオ入力118は、電気配線や光ファイバーケーブルなどの物理的接続であってもよいし、BLUETOOTHオーディオ接続などの無線入力であってもよい。いくつかの例では、オーディオ入力114は、低レベル信号の前増幅、及びプロセッサ106による処理のためのアナログ入力のデジタルデータへの変換などのオーディオ処理能力を提供するように構成されてもよい。」 （イ） 「[0028] The computing platform 104 may also receive input from human-machine interface (HMI) controls 136 configured to provide for occupant interaction with the vehicle 102. For instance, the computing plat form 104 may interface with one or more buttons or other HMI controls configured to invoke functions on the computing platform 104 (e.g., steering wheel audio buttons, a push-to-talk button, instrument panel controls , etc.). The computing platform 104 may also drive or otherwise communicate with one or more displays 138 configured to provide visual output to vehicle occupants byway of a video controller 140. In some cases, the display 138 may be a touchscreen further configured to receive user touch input via the video controller 140, while in other cases the display 138 may be a display only, without touch input capabilities. [0029] The computing platform 104 may be further configured to communicate with other components of the vehicle 102 via one or more in-vehicle networks 142. The in-vehicle networks 142 may include one or more of a vehicle controller area network (CAN), an Ethernet network, and a media oriented system transfer (MOST), as some examples. The in-vehicle networks 142 may allow the computing platform 104 to communicate with other vehicle 102 systems, such as a vehicle modem 144 (which may not be present in some configurations), a global positioning system (GPS) module 146 configured to provide current vehicle 102 location and heading information, and various vehicle ECUs 148 configured to corporate with the computing platform 104. As some non-limiting possibilities, the vehicle ECUs 148 may include a power train control module configured to provide control of engine operating components (e.g., idle control components, fuel delivery components, emissions control components, etc.) and monitoring of engine operating components (e.g., status of engine diagnostic codes); a body control module configured to manage various power control functions such as exterior lighting, interior lighting, keyless entry, remote start, and point of access status verification (e.g., closure status of the hood, doors and/or trunk of the vehicle 102); a radio transceiver module configured to communicate with key fobs or other local vehicle 102 devices; and a climate control management module configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).」 （当審訳） 「[0028] コンピューティングプラットフォーム104は、車両102との乗員相互作用を提供するように構成されたヒューマンマシンインターフェース（HMI）コントロール136からの入力を受け取ることもできる。例えば、コンピューティングプラットフォーム104は、コンピューティングプラットフォーム104上の機能を呼び出すように構成された１つまたは複数のボタンまたは他のHMI制御とインターフェースしてもよい（例えば、ステアリングホイールのオーディオボタン、プッシュトークボタン、計器パネル制御、など）。コンピューティングプラットフォーム104は、ビデオコントローラ140を介して車両乗員に視覚的出力を提供するように構成された１つ以上のディスプレイ138を駆動するか、さもなければ通信することもできる。場合によっては、ディスプレイ138は、ビデオコントローラ140を介してユーザのタッチ入力を受け取るようにさらに構成されたタッチスクリーンであってもよく、他の場合には、ディスプレイ138は、タッチ入力機能を持たない、ディスプレイのみであってもよい。 [0029] コンピューティングプラットフォーム104は、１つ以上の車載ネットワーク142を介して車両102の他の構成要素と通信するようにさらに構成されてもよい。車載ネットワーク142は、いくつかの例として、車両コントローラエリアネットワーク（CAN）、イーサネットネットワーク、およびメディア指向システム転送（MOST）のうちの１つまたは複数を含んでもよい。車載ネットワーク142は、コンピューティングプラットフォーム104が、車両モデム144（いくつかの構成では存在しない場合がある）、現在の車両102の位置および方位情報を提供するように構成されたグローバルポジショニングシステム（GPS）モジュール146、およびコンピューティングプラットフォーム104と連携するために構成された種々の車両ECU148などの、車両102の他のシステムとの通信を可能にする場合がある。いくつかの非限定的な可能性として、車両ECU148は、エンジン動作コンポーネント（例えば、アイドル制御コンポーネント、燃料供給コンポーネント、排出制御コンポーネントなど）の制御およびエンジン動作コンポーネントの監視（例えば、エンジン診断コードの状態）を提供するように構成されたパワートレイン制御モジュール；外部照明、内部照明、キーレスエントリー、リモートスタート、アクセスポイント状態検証（例えば、車両のフード、ドア及び／又はトランクの閉鎖状態）などの様々な電力制御機能を管理するように構成されたボディ制御モジュール、キーフォブ又は他の局所的な車両102の装置と通信するように構成された無線トランシーバモジュール、および加熱および冷却システムコンポーネント（例えば、圧縮機クラッチおよび送風ファン制御、温度センサ情報など）の制御および監視を提供するように構成された気候制御管理モジュールから構成される。」 （ウ） 「[0031] The computing platform 104 may also be configured to communicate with mobile devices 152 of the vehicle occupants. The mobile devices 152 may be any of various types of portable computing device, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other devices capable of communication with the computing platform 104. In many examples, the computing platform 104 may include a wireless transceiver 150 (e.g., a BLUETOOTH module, a ZIGBEE transceiver, a Wi-Fi transceiver, an IrDA transceiver, an RFID transceiver, etc.) configured to communicate with a compatible wireless transceiver 154 of the mobile device 152. Additionally or alternately, the computing platform 104 may communicate with the mobile device 152 over a wired connection, such as via a USB connection between the mobile device 152 and the USB subsystem 132. In some examples the mobile device 152 may be battery powered, while in other cases the mobile device 152 may receive at least a portion of its power from the vehicle 102 via the wired connection. [0032] The communications network 156 may provide communications services, such as packet-switched network services (e.g., Internet access, VoIP communication services), to devices connected to the communications network 156. An example of a communications network 156 may include a cellular telephone network. Mobile devices 152 may provide network connectivity to the communications network 156 via a device modem 158 of the mobile device 152. To facilitate the communications over the communications network 156, mobile devices 152 may be associated with unique device identifiers (e.g., mobile device numbers (MDNs), Internet protocol (IP) addresses, etc.) to identify the communications of the mobile devices 152 over the communications network 156. In some cases, occupants of the vehicle 102 or devices having permission to connect to the computing platform 104 may be identified by the computing platform104 according to paired device data160 maintained in the storage medium112. The paired device data 160 may indicate, for example, the unique device identifiers of mobile devices 152 previously paired with the computing platform 104 of the vehicle 102, secret information shared between the paired device and the computing platform 104 such as link keys, and/or personal identification numbers (PINs), and most recently used or device priority information, such that the computing platform 104 may automatically reconnect to the mobile devices 152 matching data in the paired device data 160 without user intervention.」 （当審訳） 「[0031] コンピューティングプラットフォーム104はまた、車両乗員のモバイル装置152と通信するように構成されてもよい。モバイル装置152は、携帯電話、タブレットコンピュータ、スマートウォッチ、ラップトップコンピュータ、携帯音楽プレーヤー、またはコンピューティングプラットフォーム104と通信可能な他の装置などの様々なタイプの携帯コンピューティング装置のいずれかであってもよい。多くの例では、コンピューティングプラットフォーム104は、モバイル装置152の互換性のある無線トランシーバ154と通信するように構成された無線トランシーバ150（例えば、BLUETOOTHモジュール、ZIGBEEトランシーバ、Wi-Fiトランシーバ、IrDAトランシーバ、RFIDトランシーバ、等）を含んでもよい。加えて又は代替的に、コンピューティングプラットフォーム104は、モバイル装置152とUSBサブシステム132との間のUSB接続を介するなど、有線接続を介してモバイル装置152と通信することができる。いくつかの例では、モバイル装置152は、バッテリ駆動されてもよく、他の例では、モバイル装置152は、有線接続を介して車両102からその電力の少なくとも一部を受信してもよい。 [0032] 通信ネットワーク156は、通信ネットワーク156に接続された装置に、パケット交換ネットワークサービス（例えば、インターネットアクセス、VoIP通信サービス）等の通信サービスを提供してもよい。通信ネットワーク156の一例は、セルラー電話ネットワークを含んでもよい。モバイル装置152は、モバイル装置152の装置モデム158を介して通信ネットワーク156へのネットワーク接続性を提供してもよい。通信ネットワーク156上の通信を容易にするために、モバイル装置152は、通信ネットワーク156上のモバイル装置152の通信を識別するために一意の装置識別子（例えば、モバイル装置番号（MDN）、インターネットプロトコル（IP）アドレスなど）と関連付けられることがある。場合によっては、車両102の乗員またはコンピューティングプラットフォーム104に接続する許可を有する装置は、記憶媒体112に保持されるペア装置データ160に従ってコンピューティングプラットフォーム104によって識別されてもよい。ペア装置データ160は、例えば、車両102のコンピューティングプラットフォーム104と以前にペアリングされたモバイル装置152の固有の装置識別子、リンクキー、および／または個人識別番号（PIN）などのペアリングされた装置とコンピューティングプラットフォーム104との間で共有される秘密情報、および最近使用されたまたは装置優先度情報を示してよく、コンピューティングプラットフォーム104がユーザの介入なしにペア装置データ160のデータに一致するモバイル装置152に自動的に再接続できるようにしてもよい。」 （エ） 「[0034] Similar to the computing platform 104, the mobile device 152 may include one or more processors 164 configured to execute instructions of mobile applications loaded to a memory 166 of the mobile device 152 from storage medium 168 of the mobile device 152. In some examples, the mobile applications may be configured to communicate with the computing platform 104 via the wireless transceiver 154 and with the remote telematics server 162 or other network services via the device modem 158. The computing platform 104 may also include a device link interface 172 to facilitate the integration of functionality of the mobile applications into the grammar of commands available via the voice interface 134. The device link interface172 may also provide the mobile applications with access to vehicle functions and information available to the computing platform 104 via the in-vehicle networks 142. An example of a device link interface 172 may be the SYNC APPLINK component of the SYNC system provided by The Ford Motor Company of Dearborn, Mich.」 （当審訳） 「[0034] コンピューティングプラットフォーム104と同様に、モバイル装置152は、モバイル装置152の記憶媒体168からモバイル装置152のメモリ166にロードされた複数のモバイルアプリケーションの命令を実行するように構成された１つまたは複数のプロセッサ164を含んでもよい。いくつかの例では、複数のモバイルアプリケーションは、無線トランシーバ154を介してコンピューティングプラットフォーム104と通信し、装置モデム158を介してリモートテレマティクスサーバ162または他のネットワークサービスと通信するよう構成されてもよい。コンピューティングプラットフォーム104は、音声インターフェース134を介して利用可能なコマンドの文法に複数のモバイルアプリケーションの機能を統合することを容易にするために、装置リンクインターフェース172を含むこともできる。装置リンクインターフェース172はまた、複数のモバイルアプリケーションに、車載ネットワーク142を介してコンピューティングプラットフォーム104に利用可能な車両機能および情報へのアクセスを提供してもよい。装置リンクインターフェース172の一例は、ミシガン州ディアボーンのフォード・モーター・カンパニーが提供するSYNCシステムのSYNC APPLINKコンポーネントであってよい。」 （オ） 「[0038] The local policy table 206 may be configured to store key information detailing application permissions in the vehicle 102. Thus, the local policy table 206 may define the type of interaction that is allowed between the computing platform 104 and a given mobile application 202. In an example, the local policy table 206 may include permission information for the mobile applications 202 keyed according to the application identifiers 204 as signed to the mobile applications 202. [0039] The permission information may include, for example, a listing of APIs and vehicle 102 systems that are deemed allowable for use by the mobile applications 202. As some specific examples, the local policy table 206 may include permission information with respect to remote procedure calls of the computing platform 104 that are allowable for access by the mobile application 202, such as to stream audio using the audio module 122, use the display 138, receive input from the HMI controls 136, or to retrieve a current GPS location of the vehicle 102. As some other examples, the local policy table 206 may include permission information with respect whether the mobile application 202 has permission to perform a context switch and take focus from another application, e.g., to interrupt the radio to provide a message. As yet a further example, the local policy table 206 may include permission information with respect whether the mobile application 202 may execute scripts on the computing platform 104. As an even a further example, the local policy table 206 may include permission information with respect to which vehicle 102 functions may be utilized when the vehicle 102 is parked or stationary, and which may be used when the vehicle 102 is in motion. The local policy table 206 may also include information to configure how and when the vehicle 102 requests updates to the local policy table 206, as well as information regarding how to contact a source of updated local policy tables 206 (e.g., a URL or other address of the backend server 218).」 （当審訳） 「[0038] ローカルポリシーテーブル206は、車両102におけるアプリケーションの許可を詳述する重要な情報を格納するように構成されてもよい。したがって、ローカルポリシーテーブル206は、コンピューティングプラットフォーム104と所定のモバイルアプリケーション202との間で許可される相互作用の種類を定義してもよい。一例では、ローカルポリシーテーブル206は、モバイルアプリケーション202に割り当てられたアプリケーション識別子204に従ってキー設定されたモバイルアプリケーション202の許可情報を含んでもよい。 [0039] 許可情報は、例えば、モバイルアプリケーション202による使用が許可されるとみなされるAPI及び車両102システムのリストを含んでもよい。いくつかの具体例として、ローカルポリシーテーブル206は、オーディオモジュール122を使用してオーディオをストリーミングする、ディスプレイ138を使用する、HMIコントロール136から入力を受け取る、または車両102の現在のGPS位置を取得するなど、モバイルアプリケーション202によるアクセスを許可するコンピューティングプラットフォーム104のリモートプロシージャコールに関する権限情報を含んでいてもよい。いくつかの他の例として、ローカルポリシーテーブル206は、モバイルアプリケーション202が、コンテキストスイッチを実行し、他のアプリケーションからフォーカスを取る、例えば、メッセージを提供するためにラジオを中断する許可を有するかどうかに関する許可情報を含んでもよい。さらに別の例として、ローカルポリシーテーブル206は、モバイルアプリケーション202がコンピューティングプラットフォーム104上でスクリプトを実行することができるかどうかに関する許可情報を含んでもよい。さらにさらなる例として、ローカルポリシーテーブル206は、車両102が駐車または静止しているときにどの車両102の機能を利用してもよく、車両102が移動しているときにどの機能を利用してもよいかということに関する許可情報を含んでもよい。また、ローカルポリシーテーブル206は、車両102がローカルポリシーテーブル206の更新を要求する方法及びタイミングを構成するための情報、並びに更新されたローカルポリシーテーブル206のソース（例えば、バックエンドサーバ218のURL又は他のアドレス）に連絡する方法に関する情報を含んでいてもよい。」 （カ） 「[0046] The wireless transceiver 115 of the vehicle 102 may be connected to a paired mobile device 152 (e.g. via a BLUETOOTH connection, via a USB connection, etc.), such that the communications features of the mobile device 152 may be used to allow the computing platform 104 to communicate via the communications network 156 with the backend server 218. The communications network 156 may accordingly be utilized by the mobile device 152 via a cellular data plan of the mobile device 152 (e.g., to provide TCP/IP-based communications functionality to the computing platform 104. Additionally or alternately, the computing platform 104 may utilize the vehicle modem 144 to communicate data between the processor 106 and the communications network 156. Messages directed to the vehicle 102 via the communications network 156 may be queued in the cloud until a connection to the vehicle 102 can be established or until the message expires. In an example, the queuing and message expiration functionality may be implemented via the backend server 218. The communications network 156 message queuing functionality may also act as a first line of defense against server denial-of-service attacks.」 （当審注：上記[0046]において、「(e.g., to provide TCP/IP-based communications functionality to the computing platform 104」の最後に“）”が抜けていることが明らかであるので、以下の当審訳ではこれを補って訳した。） （当審訳） 「[0046] 車両102の無線トランシーバ115は、モバイル装置152の通信機能を使用して、コンピューティングプラットフォーム104が通信ネットワーク156を介してバックエンドサーバ218と通信できるように、（例えば、BLUETOOTH接続を介して、USB接続を介してなど）ペアになったモバイル装置152に接続されてもよい。通信ネットワーク156は、それに応じて、モバイル装置152のセルラーデータプランを介してモバイル装置152によって利用されてもよい（例えば、TCP／IPベースの通信機能性をコンピューティングプラットフォーム104に提供するために利用される）。さらに、または代替的に、コンピューティングプラットフォーム104は、プロセッサ106と通信ネットワーク156との間でデータを通信するために車両モデム144を利用してもよい。通信ネットワーク156を介して車両102に向けられたメッセージは、車両102への接続が確立され得るまで、またはメッセージが期限切れになるまで、クラウド内でキューイングされてもよい。一例では、キューイング及びメッセージ満了の機能性は、バックエンドサーバ218を介して実装されてもよい。通信ネットワーク156のメッセージキューイング機能は、サーバDoS攻撃に対する第一の防御線としても機能し得る。」 （キ） 「[0054] In an example, the mobile device 152 may operate as the TLS server, and the computing platform 104 may operate as the TLS client device. In such an example, the computing platform 104 may connect to the mobile device 152 to request a secure connection. For instance, the computing platform 104 may request the creation of a secure tunnel 302 for a mobile application 202 indicated in the local policy table 206 as requiring the use of audio/video or other media features of the computing platform 104.」 （当審訳） 「[0054] 一例において、モバイル装置152は、TLSサーバとして動作してもよく、コンピューティングプラットフォーム104は、TLSクライアント装置として動作してもよい。このような例では、コンピューティングプラットフォーム104は、モバイル装置152に接続して、安全な接続を要求することができる。例えば、コンピューティングプラットフォーム104は、コンピューティングプラットフォーム104のオーディオ／ビデオ又は他のメディア機能の使用を必要とするとしてローカルポリシーテーブル206に示されたモバイルアプリケーション202のための安全なトンネル302の作成を要求してもよい。」 （ク） 「[0087] At operation 906, the mobile application 202 determines whether the mobile application 202 requires a secure tunnel 302. In an example, if the mobile application 202 attempts to access a secure vehicle function services that is flagged as requiring encryption, the mobile application 202 may request the creation of a secure tunnel 302. As some examples, the mobile application 202 may attempt to access secure vehicle function services such as such as audio and/or video function or other media features of the computing platform 104, vehicle diagnostics such as engine data, writing of information to the vehicle 102, personally identifiable information such as location, or access to audio data from the microphone116. As even further examples, the mobile application 202 may attempt to access secure vehicle function services for authentication for one or more of mobile payment, autonomous driving, unlocking the vehicle, starting the vehicle, ride sharing, micro-rental, and access to personalization settings for a user of the mobile device. If the mobile application 202 requires the secure tunnel 302, control passes to operation 908. Otherwise control passes to operation 918 to proceed without the secure tunnel 302.」 （当審訳） 「[0087] 動作906において、モバイルアプリケーション202は、モバイルアプリケーション202がセキュアトンネル302を必要とするかどうかを決定する。一例として、モバイルアプリケーション202が、暗号化を必要とするフラグが立てられた安全な車両機能サービスにアクセスしようとする場合、モバイルアプリケーション202は、安全なトンネル302の作成を要求してよい。いくつかの例として、モバイルアプリケーション202は、コンピューティングプラットフォーム104のオーディオ及び／又はビデオ機能又は他のメディア機能など、エンジンデータなどの車両診断、車両102への情報の書き込み、位置などの個人識別情報、又はマイク116からのオーディオデータへのアクセスなど、安全な車両機能サービスにアクセスしようとする場合がある。さらなる例として、モバイルアプリケーション202は、モバイル決済、自律走行、車両のロック解除、車両の始動、ライドシェアリング、マイクロレンタル、及びモバイル装置のユーザの個人化設定へのアクセスのうちの１つ以上のための認証のためのセキュア車両機能サービスにアクセスしようとすることができる。モバイルアプリケーション202がセキュアトンネル302を必要とする場合、制御は操作908に渡される。そうでなければ、制御は、セキュアトンネル302なしで進行するために操作918にパスする。」 （ケ） 「FIG.1（図１） ［図：0001402057000001.jpg］ 」（図中の当審訳は省略） （コ） 「FIG.2（図２） ［図：0001402057000002.jpg］ 」（図中の当審訳は省略） イ 引用発明 上記（ケ）（図１）から、「通信ネットワーク156」は、「車両102」と「リモートテレマティクスサーバ162」を通信接続するものであることを看取することができる。 よって、上記（ウ）の[0032]に記載の「通信ネットワーク156は、通信ネットワーク156に接続された装置に、パケット交換ネットワークサービス（例えば、インターネットアクセス、VoIP通信サービス）等の通信サービスを提供し」において、「通信ネットワーク156に接続された装置」は、“車両102”と“リモートテレマティクスサーバ162”と言い換えることができる。 以上より、上記アの特に下線部に着目すると、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。 「 車両102にテレマティクスサービスを提供するように構成されたシステム100であって、 車両102は、様々なタイプの乗用車を含み、 コンピューティングプラットフォーム104は、プロセスをサポートする命令、コマンド、および他のルーチンを実行するように構成された１つまたは複数のプロセッサ106を含み、ナビゲーション、事故報告、衛星ラジオ復号化、及びハンズフリー通話などの機能を提供するために、車両アプリケーション110の命令を実行するように構成され、そのような命令および他のデータは、様々なタイプのコンピュータ可読記憶媒体112を用いて不揮発性で維持され、 コンピューティングプラットフォーム104は、車両102との乗員相互作用を提供するように構成されたヒューマンマシンインターフェース（HMI）コントロール136からの入力を受け取ることもでき、 コンピューティングプラットフォーム104は、車両乗員のモバイル装置152と通信するように構成され、 通信ネットワーク156は、通信ネットワーク156に接続された車両102とリモートテレマティクスサーバ162に、パケット交換ネットワークサービス（例えば、インターネットアクセス、VoIP通信サービス）等の通信サービスを提供し、 モバイル装置152は、モバイル装置152の記憶媒体168からモバイル装置152のメモリ166にロードされた複数のモバイルアプリケーションの命令を実行するように構成された１つまたは複数のプロセッサ164を含み、 ローカルポリシーテーブル206は、モバイルアプリケーション202に割り当てられたアプリケーション識別子204に従ってキー設定されたモバイルアプリケーション202の許可情報を含み、 許可情報は、モバイルアプリケーション202による使用が許可されるとみなされるAPI及び車両102システムのリストを含み、具体例として、モバイルアプリケーション202によるアクセスを許可するコンピューティングプラットフォーム104のリモートプロシージャコールに関する権限情報を含み、 通信ネットワーク156は、TCP／IPベースの通信機能性をコンピューティングプラットフォーム104に提供するために利用され、 コンピューティングプラットフォーム104は、プロセッサ106と通信ネットワーク156との間でデータを通信するために車両モデム144を利用し、通信ネットワーク156を介して車両102に向けられたメッセージは、車両102への接続が確立され得るまで、またはメッセージが期限切れになるまで、クラウド内でキューイングされ、 モバイル装置152は、TLSサーバとして動作してもよく、コンピューティングプラットフォーム104は、TLSクライアント装置として動作してもよく、 モバイルアプリケーション202は、モバイル決済、自律走行、車両のロック解除、車両の始動、ライドシェアリング、マイクロレンタル、及びモバイル装置のユーザの個人化設定へのアクセスのうちの１つ以上のための認証のためのセキュア車両機能サービスにアクセスしようとすることができる、 システム100。」 （２）引用文献２ないし４について ア 引用文献２について 引用文献２には、図面とともに、以下の事項が記載されている。 「[0013] 車載ゲートウェイ機器１０は、第１の車載機器であり、例えばダッシュボードに設置されたカーナビゲーションシステムである。この車載ゲートウェイ機器１０は、インターネット１などの外部通信網との間で情報を授受する外部通信部１１と、車内ＬＡＮ２などの内部通信網との間で情報を授受する内部通信部１２と、映像をディスプレイ５１に出力する映像出力部１３と、音声をスピーカ５２に出力する音声出力部１４と、制御部１５とを備えている。この制御部１５は、外部通信部１１、内部通信部１２、映像出力部１３および音声出力部１４の動作を制御する。」 「[図１] ［図：0001402057000003.jpg］ 」 イ 引用文献３について 引用文献３には、図面とともに、以下の事項が記載されている。 （第１ページ第３～７行） 「Technical field Various embodiments relate to methods, apparatuses, computer program products and systems for controlling a client in a network, for example in scenarios where automated/autonomous vehicles are involved.」 （当審訳） 「技術分野 多様な実施形態は、例えば自動化された／自律的な車両が関与するシナリオにおいて、ネットワーク内でクライアントを制御するための方法、装置、コンピュータプログラムプロダクト及びシステムに関する。」 （第１２ページ第３０行～第１３ページ第６行） 「Figure 1 show an example of a distributed system architecture where the control system is implemented in autonomous vehicles. Autonomous vehicles 1-1, 1-2, 1-3 and 1-4 are driving on highway 1-13. Maneuver decisions are done for each vehicle by the control system implemented at the corresponding vehicle. The control system of each vehicle may use wireless communication means to exchange information with the environment and surrounding vehicles. Information about vehicles not being able to communicate with each other (for example legacy vehicles not supporting autonomous driving -not shown in figure 1) may be determined by the control system of an autonomous vehicle by monitoring its surrounding, for example by utilizing a radar to detect legacy vehicles and related properties (like for example speed, driving direction etc. ... of the legacy vehicle). Collected information about legacy vehicles may be exchanged between autonomous vehicles. This enables autonomous vehicles not being able to detect legacy vehicles, or where the legacy vehicle is not in the detection range, to consider also the collected information about legacy vehicles received from other autonomous vehicles when making their maneuver decisions.」 （当審訳） 「図１は、制御システムが自律的な車両に実装される分散型のシステムアーキテクチャの一例を示している。自律的な車両１－１、１－２、１－３及び１－４がハイウェイ１－１３を走行している。操作決定は、対応する車両に実装される制御システムにより、各車両について行われる。各車両の制御システムは、ワイヤレス通信手段を用いて環境及び周囲の車両と情報を交換し得る。互いに通信することができない車両（例えば、図１には示されていない、自律走行をサポートしていないレガシー車両）に関する情報は、自律的な車両の制御システムにより、例えばレーダを利用してレガシー車両及び（例えば、レガシー車両の速度、走行方向のような）関連する特性を検出することで、周囲を監視することによって判定されてもよい。レガシー車両に関する収集された情報が自律的な車両間で交換されてもよい。それにより、レガシー車両を検出できない自律的な車両、又は検出レンジ内にレガシー車両がいない自律的な車両が、自身の操作決定を行う際に他の自律的な車両から受信されるレガシー車両に関する収集された情報をも考慮することが可能となる。」 （第１３ページ第８～２９行） 「The example of figure 1 illustrates the distributed system from the perspective of autonomous vehicle 1-2 and its control system (legacy vehicles and information transmitted to vehicles 1-1, 1-3 and 1-4 is not shown). The autonomous vehicles 1-1, 1-2, 1-3 and 1-4 are synchronized to a common time base 1-14 which provides synchronization 1-15 to the vehicles. Vehicles 1-1, 1-3 and 1-4 collect local information (for example dynamic information like location, current speed, heading direction, acceleration rate, local maneuver rule, distance to preceding vehicle, etc.) at time point T-p. The information may be collected from local sensors. The information collected at time point T-p may broadcast (or send on request, 1-6, 1-7, 1-8), optionally together with the information about the maneuver rule that a vehicle is using, to surrounding vehicles using wireless communication (only shown towards vehicle 1-2 in figure 1). Each vehicle receives information broadcasted by other vehicles in the vicinity. As shown in figure 1 vehicle 1-2 may receive information 1-6, 1-7 and 1-8 collected at T-p from surrounding vehicles 1-1, 1-3 and 1-4. In addition vehicle 1-2 may receive 1-9 information about the environment (for example weather and road condition information or information from infrastructure elements in its vicinity like for example traffic lights or variable traffic signs, not shown in figure 1). Vehicle 1-2 may either receive the information either periodically via broadcast messages, or may request the information (for example via individual or group request). The information may be requested once for a certain time period and with a certain frequency, thus avoiding to send frequent requests within the time period to the same vehicle/client.」 （当審訳） 「図１の例は、自律的な車両１－２及びその制御システムの視点から分散型システムを示している（レガシー車両及び車両１－１、１－３及び１－４へ送信される情報は示されていない）。自律的な車両１－１、１－２、１－３及び１－４は、車両に同期１－１５を提供する共通の時間ベース１－１４へ同期される。車両１－１、１－３、及び１－４は、時点Ｔ－ｐにおけるローカル情報（例えば、位置、現在速度、進行方向、加速率、ローカル操作ルール、先行車両までの距離などのような動的な情報）を収集する。その情報は、ローカルセンサから収集され得る。時点Ｔ－ｐで収集された情報は、オプションとして、車両が使用している操作ルールに関する情報と共に、ワイヤレス通信を用いて周囲の車両へ（図１では車両１－２向けのみが示されている）ブロードキャストされ得る（又は要求に応じて送信され得る１－６、１－７、１－８）。各車両は、近隣の他の車両によりブロードキャストされた情報を受信する。図１に示すように、車両１－２は、Ｔ－ｐで収集された情報１－６、１－７及び１－８を周囲の車両１－１、１－３及び１－４から受信し得る。加えて、車両１－２は、環境に関する情報（例えば気象及び道路条件の情報、又は、例えば図１には示していない信号機若しくは可変交通標識のような近傍の基盤的要素からの情報）を受信１－９し得る。車両１－２は、ブロードキャストメッセージを介して周期的に情報を受信するか、又は（例えば、個別の要求若しくはグループ要求を介して）情報を要求するかのいずれかであり得る。その情報はある時間的周期に１度かつある頻度で要求されてもよく、そのようにして同じ車両／クライアントへその時間的周期内に頻繁な要求を送信することが回避される。」 （第１４ページ第２１行～第１５ページ第２行） 「Then vehicle 1-2 predicts the traffic situation at time point T (for example the position, speed, acceleration rate of surrounding vehicles 1-1 in its perception area 1-12, optionally predicting also the maneuver decisions of vehicles 1-1 at time T). This may be done by assuming that the identical vehicle maneuver rule is used at all vehicles, e.g. a desired distance oriented vehicle maneuver rule. Alternatively the vehicle maneuver rule may be received (1-7) from surrounding vehicles per wireless communication. T is the time point in the future where the next maneuver decision will be executed synchronously by the vehicles. In order to predict the maneuver decisions at its surrounding (for example preceding) vehicles at the future time T, the control system at vehicle 1-2 may perform the prediction one vehicle by one vehicle, preferably starting from the most distant preceding vehicle in its perception range 1-12. Alternatively vehicles 1-1 may predict their position and properties at time point T by themselves after executing their maneuver decision at time point T-p, and send/broadcast the predicted information (1-7) to vehicle 1-2. This saves computation resources at vehicle 1-2, since vehicle 1-2 does not need to perform the prediction for each vehicle by itself, instead it could simply combine the received information 1-7 in order to predict the traffic situation in its surrounding at time point T.」 （当審訳） 「そして、車両１－２は、時点Ｔにおける交通状況を予測する（例えば、その認識エリア１－１２内の周囲の車両１－１の位置、速度、加速率、及び、オプションとして、時刻Ｔにおける車両１－１の操作決定をも予測する）。これは、例えば所望の距離を指向する車両操作ルールといった同一の車両操作ルールが全ての車両で使用されるものと想定することにより行われてもよい。代替的に、ワイヤレス通信ごとに周囲の車両から車両操作ルールが受信されてもよい（１－７）。Ｔは、次の操作決定がそれら車両により同期的に実行されることになる将来の時点である。将来の時刻Ｔにおけるその周囲の（例えば前を行く）車両における操作決定を予測する目的で、車両１－２の制御システムは、好ましくはその知覚範囲１－１２内で最も離れた先行車両から始めて、車両１つずつ予測を実行し得る。 代替的に、車両１－１は、時点Ｔ－ｐで自身の操作決定を実行した後、時点Ｔでの自身の位置及び特性を自ら予測し、そして予測した情報（１－７）を車両１－２へ送信／ブロードキャストしてもよい。これにより、車両１－２における計算リソースが節約され、なぜなら車両１－２が各車両についての予測を単独で実行しなくてよいからであり、代わりに、車両１－２は、時点Ｔにおけるその周囲の交通状況を予測するために受信情報１－７を簡易に組合せることができるであろう。」 （第１５ページ第１６～２１行） 「Figure 2 shows an example embodiment for a centralized control system implemented in a network entity 2-10. The network entity 2-10 may be for example an application server or may be an entity located close to the clients (vehicles), for example comprised in a roadside cabinet or co-located or integrated to a base station. There may be several network entities 2-10 implementing centralized control system functionality, for example for different geographical areas.」 （当審訳） 「図２は、ネットワークエンティティ２－１０に実装される集中型の制御システムについての例示的な実施形態を示している。ネットワークエンティティ２－１０は、例えば、アプリケーションサーバであってもよく、クライアント（車両）の近くに位置するエンティティであってもよく、例えば、路側キャビネットに含まれ又は基地局と共設され若しくは統合されてもよい。例えば異なる地理的エリアのための集中的な制御システムの機能性を実装するいくつかのネットワークエンティティ２－１０が存在してもよい。」 （第１５ページ第３０行～第１６ページ第６行） 「Network entity 2-10 acts as a central controller and communicates with autonomous vehicles using for example wireless communication means 2-11. Network entity 2-10 controls (or at least influences) the movements of the vehicles by sending maneuver decision (2-16, shown here only for vehicle 2-2) to autonomous vehicles. Like for figure 1 vehicles 2-1, 2-2, 2-3 and 2-4 collect local information at time point T-p. Each vehicle may broadcast (or send on request) the information (2-5, 2-6, 2-7, 2-8) collected at time point T-p to the network entity 2-10. Alternatively vehicles 2-1, 2-2, 2-3 and 2-4 may predict their position and properties at time point T by themselves after executing their maneuver decision at time point T-p, and send/broadcast the predicted information (2-5, 2-6, 2-7, 2-8) to network entity 2-10. This saves computation resources at network entity 2-10, since network entity 2-10 does not need to perform the prediction for 5 each vehicle by itself, instead it could simply combine the received prediction information 2-5, 2-6, 2-7 and 2-8 in order to predict the traffic situation at time point T.」 （当審訳） 「ネットワークエンティティ２－１０は、中央コントローラとして動作し、例えばワイヤレス通信手段２－１１を用いて自律的な車両と通信する。ネットワークエンティティ２－１０は、自律的な車両に操作決定（２－１６、ここでは車両２－２についてのみ示されている）を送信することにより、車両の動きを制御する（又は少なくとも影響を及ぼす）。 図１と同様に、車両２－１、２－２、２－３及び２－４は、時点Ｔ－ｐでローカル情報を収集する。各車両は、時点Ｔ－ｐで収集された情報（２－５、２－６、２－７、２－８）をネットワークエンティティ２－１０へブロードキャスト（又は要求に応じて送信）し得る。代替的に、車両２－１、２－２、２－３及び２－４は、時点Ｔ－ｐで自身の操作決定を実行した後、時点Ｔでの自身の位置及び特性を自ら予測し、そして予測した情報（２－５、２－６、２－７、２－８）をネットワークエンティティ２－１０へ送信／ブロードキャストしてもよい。これにより、ネットワークエンティティ２－１０における計算リソースが節約され、なぜならネットワークエンティティ２－１０が各車両についての予測を単独で実行しなくてよいからであり、代わりに、ネットワークエンティティ２－１０は、時点Ｔにおける交通状況を予測するために、受信した予測情報２－５、２－６、２－７及び２－８を簡易に組合せることができるであろう。」 「Fig.1（図１） ［図：0001402057000004.jpg］ 」 （当審訳）省略 「Fig.2（図２） ［図：0001402057000005.jpg］ 」 （当審訳）省略 ウ 引用文献４について 引用文献４には、図面とともに、以下の事項が記載されている。 （第６ページ下から７行目～第７ページ第９行） 「 この発明に従うと、高レベルデータ構造をサポートする遠隔手続き呼出し構造および方法は、共通のデータ構造すなわちクラス（“基礎（base）”クラス）の使用によって提供される。分散オブジェクトまたは共用オブジェクトを得るために共用データ構造を使用することによって、遠隔手続き呼出しのためのクライアントスタブルーチンおよびサーバースタブルーチンの両方を自動的に発生するためプリプロセッサを構築することができる。サーバールーチンを呼出す応用プログラムは、同じデータ構造をローカルルーチンに送るのと同様に、サーバールーチンの高レベルデータに送られることができる。 この発明の一実施例において、前記サーバーは、システム初期化時にデーモン処理として創造される。該サーバーは、１つまたは複数の遠隔手続き呼出しクライアントオブジェクト（“RpcClients”）を受入れ可能な遠隔手続き呼出しサーバーオブジェクト（“RpcServer”）を作り出す。前記クライアントにおいて作り出されるRpcClientは、前記サーバー側のRpcServerと前記クライアントとの間の通信チャンネルを提供する。さらに、RpcC1ientは、前記サーバー側と前記クライアントとの間の非同期通信を提供するために、前記サーバー側に作り出される。」 （第１９ページ第１～４行） 「遠隔手続き呼出しメカニズム２０３、および、これに対応する遠隔手続き呼出しメカニズム２０４は、カーネル２５１に対して、マシーンの境界を超えて通信を行うためのシステムサービス（例えば、ポートおよびプロトコル）を要求する。」 「【図２】 ［図：0001402057000006.jpg］ 」 ２ 対比 本願発明と引用発明とを対比する。 （１） 引用発明の「コンピューティングプラットフォーム104」は、「プロセスをサポートする命令、コマンド、および他のルーチンを実行するように構成された１つまたは複数のプロセッサ106を含み、ナビゲーション、事故報告、衛星ラジオ復号化、及びハンズフリー通話などの機能を提供するために、車両アプリケーション110の命令を実行するように構成され」たものであって、かつ、「車両102との乗員相互作用を提供するように構成されたヒューマンマシンインターフェース（HMI）コントロール136からの入力を受け取ることもでき」るものである。 すなわち、「コンピューティングプラットフォーム104」は、「車両102」に搭載され、当該「車両102」の「乗員」からの入力を受け付けて、「車両アプリケーション110」を実行することにより「ナビゲーション」等の「機能」を提供することができることから、“端末”といい得るものであるから、本願発明の「車載端末」に相当する。 （２） 引用発明の「モバイルアプリケーション」は、一群のひとまとまりの命令で構成された“モジュール”といい得るものであることからすると、本願発明の「アプリケーションモジュール」に相当し、よって、引用発明の「モバイル装置152のメモリ166にロードされた複数のモバイルアプリケーション」は、本願発明の「複数のアプリケーションモジュール」に相当する。 （３） 引用発明の「車両102」は、「モバイルアプリケーション202」に対し、「セキュア車両機能サービス」による「認証」を介して、「モバイル決済、自律走行、車両のロック解除、車両の始動、ライドシェアリング、マイクロレンタル、及びモバイル装置のユーザの個人化設定へのアクセス」を提供するものといえる。 すなわち、「車両102」は、「自律走行」といった“インテリジェント”な運転を行う自動車といい得るものであるから、本願発明の「インテリジェント運転自動車」に相当する。 （４） 引用発明の「システム100」は、通信機能を備えるから、“通信システム”といい得るものであり、かつ、少なくとも「コンピューティングプラットフォーム104」と「複数のモバイルアプリケーション」とを備えるものといえる。 よって、上記（１）ないし（３）を参酌すると、引用発明の「システム100」は、本願発明の「車載端末と、複数のアプリケーションモジュールとを備えるインテリジェント運転自動車の通信システム」に相当する。 （５） 引用発明の「コンピューティングプラットフォーム104」は、「プロセッサ106と通信ネットワーク156との間でデータを通信するために車両モデム144を利用」するものであって、かつ、「通信ネットワーク156」は、「通信ネットワーク156に接続された車両102とリモートテレマティクスサーバ162に、パケット交換ネットワークサービス（例えば、インターネットアクセス、VoIP通信サービス）等の通信サービスを提供」するものである。 よって、「コンピューティングプラットフォーム104」は、「車両モデム144」及び「通信ネットワーク156」を介して、「システム100」外部の「リモートテレマティクスサーバ162」と通信するための機能手段を備えているといえる。 また、引用発明の「リモートテレマティクスサーバ162」と本願発明の「他のインテリジェント運転自動車またはサーバ」とは、「サーバ」の限りにおいて一致する。 また、引用発明において、「コンピューティングプラットフォーム104」が「リモートテレマティクスサーバ162」と通信するための機能手段と、本願発明の「外部通信モジュール」とは、“外部通信手段”である点において共通する。 よって、引用発明の「コンピューティングプラットフォーム104」が備える上記機能手段と、本願発明の「他のインテリジェント運転自動車またはサーバと通信する外部通信モジュール」とは、「サーバと通信する外部通信手段」である点において共通する。 （６） 引用発明において、「コンピューティングプラットフォーム104」は、「車両乗員のモバイル装置152と通信するように構成され」ており、また、「モバイル装置152」が備える「モバイルアプリケーション202」の「許可情報」を含む「ローカルポリシーテーブル206」において、当該「許可情報」は、「モバイルアプリケーション202による使用が許可されるとみなされるAPI及び車両102システムのリストを含み、具体例として、モバイルアプリケーション202によるアクセスを許可するコンピューティングプラットフォーム104のリモートプロシージャコールに関する権限情報を含」むものである。 また、「車両乗員のモバイル装置152」との文言からすると、「モバイル装置152」は、「車両乗員」が「車両102」内で使用するものといえる。 以上から、「コンピューティングプラットフォーム104」は、「車両102」内の「モバイルアプリケーション202」と通信を行うための機能手段を備えているといえる。また、前記（１）のとおり、「コンピューティングプラットフォーム104」は「車両102」に搭載されたものであるから、「コンピューティングプラットフォーム104」と「モバイルアプリケーション202」とは、「車両102」の内部で通信を行うことを想定している。よって、引用発明において、「コンピューティングプラットフォーム104」が「モバイルアプリケーション202」と通信を行うための機能手段は、“内部通信手段”といい得るものである。 また、引用発明の「モバイル装置152」が「コンピューティングプラットフォーム104」の外部にあることは自明であり、そうすると、「モバイルアプリケーション202」も「コンピューティングプラットフォーム104」の外部にあるものといえる。 （７） よって、上記（２）及び（４）を参酌すると、引用発明において、「コンピューティングプラットフォーム104」が「モバイルアプリケーション202」と通信するための機能手段（内部通信手段）と、本願発明の「前記インテリジェント運転自動車の、前記車載端末の外部にある前記アプリケーションモジュールと通信する内部通信モジュール」とは、「前記インテリジェント運転自動車の前記アプリケーションモジュールと通信する内部通信手段」である点において共通する。 （８） 上記（５）及び（７）より、引用発明において、「コンピューティングプラットフォーム104」が「リモートテレマティクスサーバ162」と通信するための機能手段と「モバイルアプリケーション202」と通信するための機能手段とを備えることと、本願発明の「前記車載端末は、他のインテリジェント運転自動車またはサーバと通信する外部通信モジュールと、前記インテリジェント運転自動車の、前記車載端末の外部にある前記アプリケーションモジュールと通信する内部通信モジュールとを備え」ることとは、「前記車載端末は、サーバと通信する外部通信手段と、前記インテリジェント運転自動車の、前記車載端末の外部にある前記アプリケーションモジュールと通信する内部通信手段とを備え」る点において共通する。 （９） 上記（２）及び（６）より、引用発明の「複数のモバイルアプリケーション」に含まれる「モバイルアプリケーション202」は、「コンピューティングプラットフォーム104」が「モバイルアプリケーション202」と通信を行うための機能手段と通信することは自明である。 よって、上記（７）を参酌すると、引用発明において、「モバイルアプリケーション202」が、「コンピューティングプラットフォーム104」が「モバイルアプリケーション202」と通信を行うための機能手段と通信することと、本願発明の「複数の前記アプリケーションモジュールが、前記内部通信モジュールと通信」することとは、「複数の前記アプリケーションモジュールが、前記内部通信手段と通信」することとの共通の構成を備えているといえる。 （１０） 次に、本願発明の「複数の前記アプリケーションモジュールと前記内部通信モジュールとが、サービス式通信方式で通信し、前記外部通信モジュールと、前記他のインテリジェント運転自動車またはサーバとがメッセージ式通信方式で通信し、前記サービス式通信方式は、ＲＰＣ方式であり、前記メッセージ式通信方式は、Ｓｏｃｋｅｔ方式である」との構成についてまとめて検討する。 引用発明において、「モバイルアプリケーション202の許可情報」は、「モバイルアプリケーション202による使用が許可されるとみなされるAPI及び車両102システムのリストを含み、具体例として、モバイルアプリケーション202によるアクセスを許可するコンピューティングプラットフォーム104のリモートプロシージャコールに関する権限情報を含」むものであり、ここで、「API」は、アプリケーションの機能（関数）を呼び出すために使用されるインターフェースであるから、呼び出されるアプリケーションが異なる装置にある場合には、「リモートプロシージャコール」と同一視できるものである。 そして、引用発明において、「モバイルアプリケーション202」は「モバイル装置152」とは異なる「コンピューティングプラットフォーム104」の機能を呼び出すために前記「API」が使用されるものであるから、当該「API」を使用した通信方式は、実質的に「リモートプロシージャコール」すなわち「ＲＰＣ方式」と同等である。 よって、引用発明において、「モバイルアプリケーション202」と「コンピューティングプラットフォーム104」が「モバイルアプリケーション202」と通信するための機能手段（内部通信手段）との間では、「ＲＰＣ方式」で通信するものと認められる。 また、引用発明において、「通信ネットワーク156」は、「通信ネットワーク156に接続された車両102とリモートテレマティクスサーバ162に、パケット交換ネットワークサービス（例えば、インターネットアクセス、VoIP通信サービス）等の通信サービスを提供」するものであり、具体的には、「TCP／IPベースの通信機能性をコンピューティングプラットフォーム104に提供する」ものとして特定しており、「パケット交換ネットワークサービス」特に「TCP/IP」の通信方式がソケットを使用するもの、すなわち「Ｓｏｃｋｅｔ方式」を含むことは本願優先日前の技術常識である。 よって、引用発明において、「コンピューティングプラットフォーム104」が「リモートテレマティクスサーバ162」と通信するための機能手段と、「リモートテレマティクスサーバ162」との間では、「Ｓｏｃｋｅｔ方式」で通信するものと認められる。 したがって、前記（５）及び（７）を参酌すれば、引用発明と、本願発明の「複数の前記アプリケーションモジュールと前記内部通信モジュールとが、サービス式通信方式で通信し、前記外部通信モジュールと、前記他のインテリジェント運転自動車またはサーバとがメッセージ式通信方式で通信し、前記サービス式通信方式は、ＲＰＣ方式であり、前記メッセージ式通信方式は、Ｓｏｃｋｅｔ方式である」とは、「複数の前記アプリケーションモジュールと前記内部通信手段とが、サービス式通信方式で通信し、前記外部通信手段と、サーバとがメッセージ式通信方式で通信し、前記サービス式通信方式は、ＲＰＣ方式であり、前記メッセージ式通信方式は、Ｓｏｃｋｅｔ方式である」との構成を備える点において共通する。 ３ 一致点・相違点 以上から、本願発明と引用発明とは、以下の点において一致ないし相違する。 ○一致点 「 車載端末と、複数のアプリケーションモジュールとを備えるインテリジェント運転自動車の通信システムであって、 前記車載端末は、サーバと通信する外部通信手段と、前記インテリジェント運転自動車の、前記車載端末の外部にある前記アプリケーションモジュールと通信する内部通信手段とを備え、 複数の前記アプリケーションモジュールが、前記内部通信手段と通信し、 複数の前記アプリケーションモジュールと前記内部通信手段とが、サービス式通信方式で通信し、前記外部通信手段と、サーバとがメッセージ式通信方式で通信し、 前記サービス式通信方式は、ＲＰＣ方式であり、前記メッセージ式通信方式は、Ｓｏｃｋｅｔ方式である、インテリジェント運転自動車の通信システム。」 ○相違点 （相違点１） 「アプリケーションモジュール」と通信するものが、本願発明においては「内部通信モジュール」であるのに対し、引用発明において、「モバイル装置152」が備える「モバイルアプリケーション202」と通信するための機能手段は、“モジュール”といえるものであるのか具体的ではない点。 （相違点２） 「サーバ」と通信するものが、本願発明においては、「外部通信モジュール」であるのに対し、引用発明において、「コンピューティングプラットフォーム104」が「リモートテレマティクスサーバ162」と通信するための機能手段は、“モジュール”といえるものであるのか具体的ではない点。 （相違点３）（予備的な相違点） 仮に、本願発明の「外部通信モジュール」が、「他のインテリジェント運転自動車」との間で通信を行うことが必須の要件であるとした場合には、本願発明が当該要件を備えるのに対し、引用発明は、当該要件に相当する構成を具体的に特定していない点。 ４ 相違点についての判断 （１） 相違点１及び２について 所定の機能手段をソフトウェア又はハードウェアもしくはこれらの組み合わせによるひとまとまりの“モジュール”として構成することは本願優先日前における常套手段にすぎない。 また、引用文献２に記載されているように、車載機器が、車両の外部とは「外部通信部」で、また、車両の内部とは「内部通信部」で通信することは、本願優先日前の周知技術である。 そして、引用文献２に記載の「外部通信部」及び「内部通信部」は、[図１]を参酌すると、いずれも“モジュール”といい得るものである。 よって、引用発明において、「モバイル装置152」が備える「モバイルアプリケーション202」と通信するための機能手段及び「コンピューティングプラットフォーム104」が「リモートテレマティクスサーバ162」と通信するための機能手段のそれぞれをモジュール化したもの、すなわち「内部通信モジュール」及び「外部通信モジュール」とすることは当業者が必要に応じて適宜になし得た事項にすぎない。 （２）相違点３について（予備的な判断） 引用文献３に記載されているように、自動化された／自律的な車両が関与するシナリオにおいて、各車両の制御システムがワイヤレス通信手段を用いて環境及び周囲の車両と情報を交換し得る分散型のシステムアーキテクチャと、アプリケーションサーバであるネットワークエンティティがワイヤレス通信手段を用いて自律的な車両と通信する集中型の制御システムとがあり得ることは、本願優先日前の周知技術である。 よって、仮に、本願発明の「外部通信モジュール」が、「他のインテリジェント運転自動車」との間で通信を行うことが必須の要件である場合であるとしても、引用発明において、周知である集中型の制御システムを採用することにより、「コンピューティングプラットフォーム104」が、他の車両すなわち「他のインテリジェント運転自動車」と通信を行うよう構成することは当業者が容易に想到し得たことである。 ５ 請求人の主張について 請求人は、令和５年３月１０日に提出された意見書において、以下の主張をしている。 「４．拒絶の理由３（特許法第２９条第２項）について 本願請求項１～１５に係る発明（以下、本願発明という。）は、内部通信モジュールとアプリケーションモジュールとが、非Ｓｏｃｋｅｔ方式のサービス式通信方式であるＲＰＣ方式で通信し、外部通信モジュールと他のインテリジェント運転自動車又はサーバとが、メッセージ式通信方式であるＳｏｃｋｅｔ方式で通信することを特徴としています。 審判官殿は、引用文献１～４を引用して本願発明の進歩性を否定されています。しかし、本願発明の上記特徴は引用文献１～４に記載されておらず、本願発明は上記特徴において引用文献１～４に記載の発明（以下、引用発明１～４という。）と相違します。 具体的には、審判官殿は、引用発明１に記載の「ＡＰＩ」について、「当該『ＡＰＩ』を使用した通信方式は、実質的に『リモートプロシージャコール』すなわち『ＲＰＣ方式』と同等である」と認定されています。しかし、当該ご認定は妥当ではないと思料致します。 「ＡＰＩ」は、一般的には、アプリケーションのインターフェースであり、各アプリケーションはそれぞれの独立のインターフェースを備え、アプリケーションを呼び出す前に、相応するアプリケーションを増加する必要があります。一方、「ＲＰＣ方式」は、遠隔呼び出し用の通信手段であり、遠隔呼び出しされるプログラムの配置情報を知らない状況で、ローカル呼び出しのように呼び出すことができ、それぞれのインターフェースを増加する必要がりません。 また、引用発明１の段落００９４には、「At operation 920, the computing platform 104 logs application usage of the mobile application 202. For example, the computing platform 104 may record application usage 208 including usage of vehicle functions, APIs, RPCs and vehicle 102 systems by the mobile applications 202.」と記載されています。この記載から分かるように、「ＡＰＩ」と「ＲＰＣ」は個別に表記されおり、引用発明１においても、「ＡＰＩ」と「ＲＰＣ」とを同等のものと見なしていないことは明らかです。 したがって、引用発明１には、本願発明の上記特徴が開示も示唆もされていないと思料致します。 また、引用発明２～４にも、本願発明の上記特徴は開示も示唆もされていません。 さらに、本願発明によれば、上記特徴により、「アプリケーションを新たに追加する必要がある場合、サービスを直接に登録すればよく、異なるサービスは互いに独立し、互いに非干渉する」という特有の効果を奏します。この効果は、本願発明の上記特徴が開示も示唆もされていない引用発明１～４から容易に予測し得るものではないと思料致します。 以上、意見を申し上げましたように、本願発明は、引用発明１～４には開示も示唆もされていない構成を備え、その構成によって引用発明１～４と比較した有利な効果を奏するものであり、たとえ当業者といえども、引用発明１～４に基づいて容易に想到し得るものではありません。よって、本願発明は、引用発明１～４に対して進歩性を有しており、拒絶の理由３には該当しないものと思料致します。」 上記主張について、以下検討する。 （１）本願発明の「ＲＰＣ方式」と引用発明の「ＡＰＩ」について 本願発明の「ＲＰＣ方式」とは、本願明細書の【００２０】の記載「ＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ、リモートプロシージャコール）」からすれば、リモート（遠隔）プロシージャ（手続）コール（呼び出し）、すなわち、遠隔にある手続を呼び出す方式である。 そして、上記２（１０）で述べたように、引用発明において、「モバイルアプリケーション202の許可情報」は、「モバイルアプリケーション202による使用が許可されるとみなされるAPI及び車両102システムのリストを含み、具体例として、モバイルアプリケーション202によるアクセスを許可するコンピューティングプラットフォーム104のリモートプロシージャコールに関する権限情報を含」むものであり、ここで、「API」は、アプリケーションの機能（関数）を呼び出すために使用されるインターフェースであるから、呼び出されるアプリケーションが異なる装置にある場合には、「リモートプロシージャコール」と同一視できるものである。 すなわち、引用発明において、「モバイルアプリケーション202」が「API」を使用して行うアプリケーションの機能の呼び出しは、実質的に、本願発明の「ＲＰＣ方式」と変わるところはない。 仮に、厳密には「ＡＰＩ」が「ＲＰＣ」とは異なるものであるとしても、引用文献１の段落００９４には、「ＲＰＣ」を使用することが記載されている以上、この点が本願発明と引用発明との間の相違点とはならない。 （２）本願発明の作用効果について 本願明細書の【０００６】には、請求人が上記意見書において主張する「アプリケーションを新たに増加する必要がある時、サービスを直接に登録すればよく、異なるサービスは、互いに独立し、互いに非干渉し、従来技術において車両アプリケーションの増加または減少時の柔軟性が悪いという課題を解決することができる。」との作用効果が記載されているものの、本願発明は、「サービス通信方式」について特定するものの、「サービス」自体については、これをどこにどのように登録するのか、また、当該「サービス」と「アプリケーション（モジュール）」との関係について何ら具体的に特定しておらず、加えて、明細書及び図面にもその具体的な構成が開示されているとも認められないから、当該作用効果は、本願発明の構成に具体的に基づくものではない。 また、本願発明は、本願明細書の【０００６】に記載された「Ｓｏｃｋｅｔなどのネットワーク技術プロトコルを経由する必要がな」いという従来技術とは異なる構成を具体的に特定するものではない。 よって、上記各相違点を総合的に勘案しても、本願発明の奏する作用効果は、引用発明及び周知技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。 以上のとおりであるから、上記請求人の主張は、採用することができない。 ６ まとめ したがって、本願発明は、当業者が引用文献１ないし３に記載された発明に基づいて容易に発明をすることができたものである。 第８ むすび 以上のとおり、本願発明は、特許法第３６条第６項第２号、同第４項第１号及び同第２９条第２項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。 よって、結論のとおり審決する。