2019-015838

第２ 原査定の概要

原査定（令和元年７月１６日付け拒絶査定）の概要は次のとおりである。

本願請求項１ないし１６に係る発明は、以下の引用文献ＡないしＣに記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

［引用文献等一覧］

Ａ 沢田輝、Ｗｅｂプラットフォーム 新潮流 車載プラットフォーム シリーズ 第２回 カーテレマティクス（後編） 多彩なアプリをブラウザーで実現 ＷｅｂＳｏｃｋｅｔとＷｅｂＲＴＣが鍵、日経コミュニケーション 第５９９号、日本、日経ＢＰ社、２０１３年１１月２８日、第５９９号、pp.60-63

Ｂ 特開２０００－５９７６２号公報（周知技術を示す文献）

Ｃ Ilya Grigorik、Chapter 18. WebRTC、High Performance Browser Networking、２０１３年 ９月 ９日、pp.309-362、ＵＲＬ、http://met.guc.edu.eg/Download.ashx?id=25985&file=High-Performance-Browser-Networking-Ilya-Grigorik_25985.pdf（周知技術を示す文献）

第３ 当審拒絶理由の概要

１ 当審拒絶理由１

令和２年１１月１８日付けで当審が通知した拒絶理由（以下、「当審拒絶理由１」という。）の概要は次のとおりである。

［理由１］明確性要件

本願請求項１ないし１４に係る発明は、以下の（１）ないし（３）の点において明確ではないから、特許法第３６条第６項第２号に規定する要件を満たしていない。

［理由２］サポート要件

本願請求項１ないし１４に係る発明は、以下の（２）の点において発明の詳細な説明に記載したものではないから、特許法第３６条第６項第１号に規定する要件を満たしていない。

（１）請求項１及び８に記載の「前記オペレーションコマンドは、異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づき、」は、これに続く、「…直接ピアツーピア接続を確立する」に係るのか、あるいは、単に「オペレーションコマンド」が「異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較」に基づいたものであることを示すのか、明確ではない。

請求項４及び１２に記載の「前記オーディオ信号及び/またはビデオ信号の処理は、異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づき、」についても同様である。

（２）請求項１、４、８及び１２に記載の「ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎインターフェースを介して」「直接ピアツーピア接続を確立する」ことは、明細書及び図面には記載されていない。

また、「ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎインターフェースを介して」「直接ピアツーピア接続を確立する」とは、どのような意味であるのか明確ではない。

（３）請求項４の記載において、「…デバイス…は、Ｗｅｂオペレーティングシステムで実行する」は、日本語として明確でない。

［理由３］

本願請求項１ないし１４に係る発明は、以下の引用文献１ないし４に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

［引用文献等一覧］

１ 今月のスマートフォン通信、ラジオライフ、ＫＫ三才ブックス、２０１３年８月２５日、第３４巻・第９号、第９８－９９ページ（当審で新たに引用した文献）

２ ASCII.Jp:WebRTCでブラウザーが防犯カメラに！(1/4)、２０１２年６月２０日、ＵＲＬ：https://ascii.jp/elem/000/000/702/702494/、検索日：２０２０年１１月１０日（周知技術を示す文献；当審で新たに引用した文献）

３ Ilya Grigorik、Chapter 18. WebRTC、High Performance Browser Networking、２０１３年 ９月 ９日、pp.309-362、ＵＲＬ、http://met.guc.edu.eg/Download.ashx?id=25985&file=High-Performance-Browser-Networking-Ilya-Grigorik_25985.pdf（拒絶査定の引用文献Ｃ）

４ 特開２０００－５９７６２号公報（拒絶査定の引用文献Ｂ）

２ 当審拒絶理由２

令和３年６月８日付け当審が通知した拒絶理由（以下、「当審拒絶理由２」という。）の概要は次のとおりである。

［理由１］明確性要件

本願請求項１ないし１４に係る発明は、以下の（１）及び（２）の点において明確ではないから、特許法第３６条第６項第２号に規定する要件を満たしていない。

［理由２］サポート要件

本願請求項１ないし１４に係る発明は、以下の（１）及び（２）の点において発明の詳細な説明に記載したものではないから、特許法第３６条第６項第１号に規定する要件を満たしていない。

（１）請求項１及び８の記載において、「アラーム」は、

ａ 「オペレーションコマンド」と同様に、「信号取得デバイス」が「リモートモニタリングデバイス」から受信するよう構成されている、又は、

ｂ 「オペレーションコマンド」とは無関係に処理される（例えば、「リモートモニタリングデバイス」において発行される等）

のいずれであるのか、明確ではない。

また、請求項１及び８の記載は、上記ａとも解される以上、発明の詳細な説明に記載したものではない。

（２）請求項４及び１２の記載は、

ｃ 「リモートモニタリング結果のフィードバック」として「ユーザ」に「アラーム」を送信する、又は、

ｄ 「リモートモニタリング結果のフィードバック」とは無関係に「アラーム」を使用する、

のいずれの態様であるのか、明確ではない。

また、請求項４及び１２の記載は、上記ｃ及びｄのいずれであっても発明の詳細な説明（特に、明細書の【００４８】）に記載したものではない。

［理由３］

本願請求項１ないし１４に係る発明は、上記引用文献１ないし４に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

第４ 本願発明

本願請求項１ないし１４に係る発明（以下、それぞれ「本願発明１」ないし「本願発明１４」という。）は、令和３年９月１５日に提出された手続補正書に係る手続補正（以下、「本件補正」という。）により補正された特許請求の範囲の請求項１ないし１４に記載された事項により特定される発明であり、このうち、本願発明１、４、８及び１２は、以下のとおりの発明である。なお、下線は、補正された箇所を示す。

［本願発明１］

「 Ｗｅｂオペレーティングシステムを実行する信号取得デバイスとリモートモニタリングデバイスとの間で、ＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立することと、

前記信号取得デバイスが、オーディオ信号及び／またはビデオ信号を取得することと、

前記信号取得デバイスが、前記通信リンクを介して前記リモートモニタリングデバイスに前記オーディオ信号及び/または前記ビデオ信号を送信することと、

前記信号取得デバイスが、前記リモートモニタリングデバイスから、異なる瞬間において受信された前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づいて、オペレーションコマンドを受信することであって、前記オペレーションコマンドについてのフィードバックは前記リモートモニタリングデバイスからユーザに送信される、ことと、

前記信号取得デバイスが、前記オペレーションコマンドに応じたオペレーションを実行することと、

を含み、前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する、リモートモニタリングの方法。」

［本願発明４］

「 リモートモニタリングデバイスにおいて、信号取得デバイス及びＷｅｂＲＴＣ技術を使用する前記リモートモニタリングデバイスの間で確立されたピアツーピア接続の通信リンクを介して前記信号取得デバイスからオーディオ信号及び／またはビデオ信号を受信することであって、前記信号取得デバイス及び前記リモートモニタリングデバイスの両方は、Ｗｅｂオペレーティングシステムを実行することと、

リモートモニタリングのための前記リモートモニタリングデバイスにおいて、前記信号取得デバイスから受信した前記オーディオ信号及び/またはビデオ信号を処理することと、

前記リモートモニタリングデバイスにおいて、前記オーディオ信号及び／またはビデオ信号を処理した後、前記処理に基づいてオペレーションコマンドを前記信号取得デバイスに送信するとともに、前記オペレーションコマンドに基づくリモートモニタリング結果のフィードバックをユーザに送信することと

を含み、

前記オーディオ信号及び/またはビデオ信号の処理は、異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づくものであり、前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する、リモートモニタリングの方法。」

［本願発明８］

「 プロセッサ、コンピュータ読み込み可能メモリ及びストレッジメディア、及び入出力デバイスを有するコンピューティングデバイスを有し、前記コンピューティングデバイスは、Ｗｅｂオペレーティングシステムを実行し及び機能モジュールを有するためにプログラムされることを含む信号取得のための装置であって、

オーディオ信号及び／またはビデオ信号を取得するための信号取得モジュールと、

前記信号取得モジュールとリモートモニタリングデバイスとの間でＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立し、前記通信リンクを介して前記オーディオ信号及び／または前記ビデオ信号を前記リモートモニタリングデバイスに送信するための信号送信モジュールと、を有し、前記リモートモニタリングデバイスは、前記Ｗｅｂオペレーティングシステム、及びＷｅｂＲＴＣ技術を使用して確立される前記通信リンクをサポートし、

前記コンピューティングデバイスは、動作を実施するためにさらにプログラムされ、

前記動作は、

前記リモートモニタリングデバイスからオペレーションコマンドを受信し、前記オペレーションコマンドについてのフィードバックは前記リモートモニタリングデバイスからユーザに送信され、

前記オペレーションコマンドに応じたオペレーションを行うことを含み、

前記オペレーションコマンドは、異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づくものであり、前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する、前記信号取得のための装置。」

［本願発明１２］

「 プロセッサ、コンピュータ読み込み可能メモリ及びストレッジメディア、及び入出力デバイスを有するコンピューティングデバイスを有し、前記コンピューティングデバイスは、Ｗｅｂオペレーティングシステムを実行し及び機能モジュールを有するためにプログラムされることを含むリモートモニタリングシステムであって、この機能モジュールは

信号取得デバイス及び信号受信モジュールの間でＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立し、前記通信リンクを介してオーディオ信号及び／またはビデオ信号を受信するための信号受信モジュールと、

リモートモニタリングのための前記オーディオ信号及び／またはビデオ信号の処理のための信号処理モジュールと、を含み、

前記コンピューティングデバイスは、前記オーディオ信号及び／またはビデオ信号を処理した後、前記処理に基づいてオペレーションコマンドを前記信号取得デバイスに送信するとともに、前記オペレーションコマンドについてのリモートモニタリング結果のフィードバックをユーザに送るようにプログラムされており、

前記オーディオ信号及び/またはビデオ信号の処理は、異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づくものであり、前記コンピューティングデバイスは、前記リアルタイムの比較の結果大きな差を示すことをアラームの条件の１つとして使用する、前記リモートモニタリングシステム。」

本願発明１ないし１４は、全体としてみれば、信号を取得するデバイスとモニタリングを行うデバイスとからなるコンビネーションシステムの一部を特定した発明であり、具体的には、本願発明１は、「信号取得デバイス」を主体とする方法の発明であり、本願発明４は、「モニタリングデバイス」を主体とする方法の発明であり、本願発明８は本願発明１に対応する「信号取得のための装置」の発明であり、本願発明１２は、本願発明４に対応する「リモートモニタリングシステム」の発明である。

また、本願発明２及び３は、本願発明１を減縮したものであり、本願発明５ないし７は、本願発明４を減縮したものであり、本願発明９ないし１１は、本願発明８を減縮したものであり、また、本願発明１３及び１４は、本願発明１２を減縮したものである。

なお、本願発明１２における「前記リアルタイムの比較の結果大きな差を示すこと」は、本願発明１、４及び８の記載からして「前記リアルタイムの比較の結果が大きな差を示すこと」の誤記と認められる。

第５ 引用文献、引用発明等

１ 引用文献１について

（２）引用発明

引用文献１には、「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」を使用した監視方法」が記載されているといえる。

よって、前記（１）より、上記引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。

「 ＰＣやスマホで遠隔操作でき、監視目的（監視カメラ）として使うにはうってつけの、インターネット経由でリアルタイムに撮影映像を転送してくれるＷｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」を使用した監視方法であって、

iPhoneやAndroid端末であるスマホで遠隔視聴する場合、無料アプリ「iPCloud」をスマホにインストールすることで、Ｐ２Ｐ方式による映像配信によりスマホにカメラの映像が表示され、カメラを首フリさせたい場合は、スマホの画面をその方向にフリックすればよく、

外出先のＰＣからカメラにアクセスする場合、カメラと同一のネットワーク上にあるＰＣのWebブラウザにより、DDNSアドレスを設定し、外出先のPCでWebブラウザを立ち上げ、アドレスバーに「DDNSアドレス」を入力すると、Webブラウザ上にカメラの映像が表示される、

監視方法。」

２ 引用文献２について

当審拒絶理由１及び当審拒絶理由２に引用された引用文献２には、図面とともに次の事項が記載されている。

「WebRTCでブラウザーが防犯カメラに！（１／４）

…（中略）

WebブラウザーからPCのカメラなどのデバイスにアクセスするには、従来、FlashPlayerを利用する必要がありましたが、最近ではJavaScriptで利用できるAPIがWebブラウザーに実装されてきています。…（中略）…

WebRTCは「Web Real-Time Communications」の略でカメラやマイクなどのデバイスからリアルタイムでデータをとりこめるJavaScriptのAPIが揃っています。」

以上の記載から、引用文献２には、次の事項（以下、「引用文献２記載事項」という。）が記載されている。

「Webブラウザーに実装されているWebRTCのAPIで防犯カメラからリアルタイムでデータをとりこむこと。」

３ 引用文献３（引用文献Ｃ）について

当審拒絶理由１及び当審拒絶理由２に引用された引用文献３（原査定の引用文献Ｃ）には、次の事項が記載されている。

「Web Real-Time Communication (WebRTC) is a collection of standards, protocols, and JavaScript APIs, the combination of which enables peer-to-peer, audio, video, and data sharing between browsers (peers).

Instead of relying on third-party plug-ins or proprietary software, WebRTC turns real-time communication into a standard feature that any web application can leverage via a simple JavaScript API.

Delivering rich, high-quality, RTC applications such as audio and video teleconferencing and peer-to-peer data exchange requires a lot of new functionality in the browser: audio and video processing capabilities, new application APIs, and support for half a dozen new network protocols. Thankfully, the browser abstracts most of this complexity behind three primary APIs.

・MediaStream: acquision of audio and video streams

・RTCPeerConnection: communication of audio and video data

・RTCDataChannel: communication of arbitrary application data

」（第３０９ページ）

［当審訳］

「Web Real-Time Communication（WebRTC）は、規約、プロトコル、およびJavaScript APIのコレクションであり、これらを組み合わせることで、ブラウザー（ピア）間でのピアツーピア、オーディオ、ビデオ、およびデータ共有が可能になる。WebRTCは、サードパーティのプラグインや独自のソフトウェアに依存する代わりに、リアルタイム通信を、任意のWebアプリケーションが単純なJavaScriptAPIを介して活用できる標準機能に変える。

オーディオとビデオの電話会議やピアツーピアデータ交換などのリッチで高品質のRTCアプリケーションを提供するには、ブラウザーに多くの新機能、つまり、オーディオとビデオの処理機能、新しいアプリケーションAPI、および半ダースの新しいネットワークプロトコルへのサポートが必要だ。ありがたいことに、ブラウザーは３つの主要なAPIの背後にあるこの複雑さのほとんどを抽象化する。

・MediaStream:オーディオ及びビデオストリームの獲得

・RTCPeerConnection:オーディオ及びビデオデータの通信

・RTCDataChannel:任意のアプリケーションデータの通信」

「Brief Introduction to RTCPeerConnection API

Despite the many protocols involved in setting up and maintaining a peer-to-peer connection, the application API exposed by the browser is relatively simple. The RTCPeerConnection interface (Figure 18-4) is responsible for managing the full life cycle of each peer-to-peer connection.

RTCPeerConnection manages the full ICE workflow for NAT traversal.

・ RTCPeerConnection sends automatic (STUN) keep alives between peers.

・ RTCPeerConnection keeps track of local streams.

・ RTCPeerConnection keeps track of remote streams.

・ RTCPeerConnection triggers automatic stream renegotiation as required.

・ RTCPeerConnection provides necessary APIs to generate the connection offer, accept the answer, allows us to query the connection for its current state, and more.

In short, RTCPeerConnection encapsulates all the connection setup, management, and state within a single interface. However, before we dive into the details of each configuration option of the RTCPeerConnection API, we need to understand signaling and negotiation, the offer-answer workflow, and ICE traversal. Let's take it step by step.」（第３１７～３１８ページ）

［当審訳］

「RTCPeerConnectionAPIの簡単な紹介

ピアツーピア接続のセットアップと維持に関係する多くのプロトコルにもかかわらず、ブラウザーによって公開されるアプリケーションAPIは比較的単純です。RTCPeerConnectionインターフェイス（図18-4）は、各ピアツーピア接続のライフサイクル全体を管理する。

RTCPeerConnectionは、NATトラバーサルの完全なICEワークフローを管理する。

・RTCPeerConnectionは、ピア間で自動（STUN）キープアライブを送信する。

・RTCPeerConnectionは、ローカルストリームを追跡する。

・RTCPeerConnectionは、リモートストリームを追跡する。

・RTCPeerConnectionは、必要に応じて自動ストリーム再ネゴシエーションをトリガーする。

・RTCPeerConnectionは、接続オファーの生成、回答の受け入れ、接続の現在の状態の照会などに必要なAPIを提供する。

つまり、RTCPeerConnectionは、すべての接続設定、管理、および状態を単一のインターフェース内にカプセル化する。ただし、RTCPeerConnection APIの各構成オプションの詳細に入る前に、シグナリングとネゴシエーション、オファーとアンサーのワークフロー、およびICEトラバーサルについて理解する必要がある。ステップバイステップで見ていこう。」

以上の記載から、引用文献３には、次の事項が記載されている。

「WebRTCは、ブラウザー（ピア）間でのピアツーピア、オーディオ、ビデオ、およびデータ共有を可能にするJavaScript APIのコレクションであり、リアルタイム通信を単純なJavaScriptAPIを介して活用できる標準機能に変えるものであって、３つの主要なAPIは、

・MediaStream:オーディオ及びビデオストリームの獲得

・RTCPeerConnection:オーディオ及びビデオデータの通信

・RTCDataChannel:任意のアプリケーションデータの通信

であり、

RTCPeerConnectionは、各ピアツーピア接続のライフサイクル全体を管理するものであり、接続オファーの生成、回答の受け入れ、接続の現在の状態の照会などに必要なAPIを提供すること。」

４ 引用文献４（引用文献Ｂ）について

当審拒絶理由１及び当審拒絶理由２に引用された引用文献４（原査定の引用文献Ｂ）には、図面とともに次の事項が記載されている。

「【０００１】

【発明の属する技術分野】本発明は、ビデオカメラ等のカメラで撮像された画像中の部分的な変化を検出し、この検出に応じてカメラを制御するカメラ制御装置、方法及びそれに用いられるコンピュータ読み取り可能な記憶媒体に関するものである。

【０００２】

【従来の技術】従来よりカメラで撮像した映像の変化を検出して侵入者の出現や、異常事態の発生を自動的に検出する装置が提案されている。これらの装置の中には、撮像中の映像の全域を監視対象とするのではなく、撮像中の映像の一部領域をあらかじめ指定し、この一部領域内での変化のみを検出対象として扱うものがある。また、一部領域を複数設定してそれぞれ変化を検出するものもある。」

「【００１２】即ち、ＣＰＵ３１は、Ｉ／Ｏ３４を介して信号線１４にズーム制御コマンドを出力することで、ビデオカメラ１のズーム倍率の制御が可能であり、また、信号線２４に雲台制御コマンドを出力することで、ビデオカメラ１の撮像方向の制御が可能である。」

「【００６１】さて、ステップＳ６の処理を終えると、ステップＳ７へ進む。ステップＳ７では、上記表４の如くに格納された各部分領域毎に、順に変化量Ｖkが、あらかじめ定めた閾値Ｔ以下か否かを吟味し、全ての部分領域に関して、変化量が閾値未満の場合は、ステップＳ６へ戻り、吟味の途中で、例えばｍ番目の部分領域の変化量Ｖmが閾値Ｔ以上であった場合は、その時点でステップＳ８へ進む。

【００６２】ステップＳ８では、直前のステップで、全体撮像領域の画像中において変化が有ると判定した部分画像領域に対応する部分監視領域に対してビデオカメラの姿勢（パン、チルト、ズーム）をセットして、その画角での変化検出を行う。」

「【００６６】ステップＳ９では、ステップＳ８で求めた部分監視領域の撮影方向と画角で入力した画像での変化量Ｖwがあらかじめ定めた閾値Ｔw以上であると否かを判定し、Ｔw以上の場合には、ステップＳ１０へ、そうでない場合には、ステップＳ11に進む。

【００６７】ステップＳ１０では、直前にステップＳ８及びステップＳ９で吟味した部分監視領域に、変化が発生している旨を警告として通信Ｉ／Ｆ３７を経由にして外部に通報する。また、ディスプレイ５１上に警告のメッセージを表示したり、図示しないスピーカ等を用いて、音による警告等を行なうように構成してもよい。ステップＳ１０を終えると、ステップＳ１１に進む。」

「【図１】

［図：0001380223000001.jpg］

」

以上の記載から、引用文献４（引用文献Ｂ）には、次の事項（以下、「引用文献４（引用文献Ｂ）記載事項」という。）が記載されている。

「 カメラで撮像した映像の変化を検出して侵入者の出現や、異常事態の発生を自動的に検出するカメラ制御装置において、

ＣＰＵ３１は、Ｉ／Ｏ３４を介して信号線１４にズーム制御コマンドを出力することで、ビデオカメラ１のズーム倍率の制御が可能であり、また、信号線２４に雲台制御コマンドを出力することで、ビデオカメラ１の撮像方向の制御が可能であり、

各部分領域毎に、順に変化量Ｖkが、あらかじめ定めた閾値Ｔ以下か否かを吟味し、例えばｍ番目の部分領域の変化量Ｖmが閾値Ｔ以上であった場合は、変化が有ると判定した部分画像領域に対応する部分監視領域に対してビデオカメラの姿勢（パン、チルト、ズーム）をセットして、その画角での変化検出を行い、

部分監視領域の撮影方向と画角で入力した画像での変化量Ｖwがあらかじめ定めた閾値Ｔw以上であると否かを判定し、Ｔw以上の場合には、部分監視領域に、変化が発生している旨を警告として通信Ｉ／Ｆ３７を経由にして外部に通報したり、ディスプレイ５１上に警告のメッセージを表示したり、図示しないスピーカ等を用いて、音による警告等を行なうこと。」

５ 引用文献Ａについて

（２）引用発明Ａ

引用文献Ａには、全体としてみれば「WebRTCによる車載アプリを使用する方法」が記載されているといえる。

よって、前記（１）より、引用文献Ａには、次の事項（以下、「引用発明Ａ」という。）が記載されている。

「 WebRTCによる車載アプリを使用する方法であって、

WebRTCがサポートする機能は、

（１）メディアストリームの取り込み、（２）P2P（Peer to Peer）でメディアストリームを送受信、（３）P2Pで任意のデータを送受信の３つがあり、

（１）は、ローカルの端末に接続されたカメラやマイクの音声や映像を「getUserMedia」というコマンドを使うことによってブラウザーに取り込めるものであり、

（２）の機能を使うことで可能になる、車載アプリ例「渋滞ライブカメラ共有サービス」において、P2Pでメディアストリームを送受信する際には「PeerConnection」というコマンドを使い、渋滞に差し掛かったクルマが、先頭付近を走行するクルマへライブカメラ映像の送信リクエストをすると、先頭付近のクルマが前方のカメラ映像を「getUserMedia」を使ってブラウザーから取得、さらに「PeerConnection」を使って、リクエストを発信したクルマの車載機とP2Pで接続し、渋滞先頭付近の映像をストリームとして返し、

WebRTCを使った車載アプリの例として「盗難防止監視カメラ」がある、

方法。」

第６ 当審拒絶理由２についての判断

１ 理由１（明確性）及び理由２（サポート要件）について

（１）本件補正により、本件補正後の請求項１及び８の記載は「前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する」と補正されることにより、「リモートモニタリングデバイス」が「リアルタイムの比較の結果が大きな差を示すこと」を「アラーム」の条件の１つとして使用することが明確となり、また、発明の詳細な説明に記載したものとなった。

（２）本件補正により、本件補正後の請求項４及び１２の記載は、「前記リモートモニタリングデバイスにおいて、前記オーディオ信号及び／またはビデオ信号を処理した後、前記処理に基づいてオペレーションコマンドを前記信号取得デバイスに送信するとともに、前記オペレーションコマンドに基づくリモートモニタリング結果のフィードバックをユーザに送信する」及び「前記オーディオ信号及び/またはビデオ信号の処理は、異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づくものであり、前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する」と補正されることにより、「フィードバック」は、「オペレーションコマンドに基づくリモートモニタリング結果」についてのものであり、「アラーム」は、「異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づくもの」であることが明確となり、また、発明の詳細な説明に記載したものとなった。

よって、理由１（明確性）及び理由２（サポート要件）はいずれも解消した。

２ 理由３（進歩性）について

（１）本願発明１について

ア 対比

本願発明１と引用発明とを対比する。

（ア）引用発明は、「スマホ」等により「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」」（及び単に「カメラ」）を「遠隔操作」し、また、「監視」するものであるから、「スマホ」は「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」」（「カメラ」）を遠隔監視（リモートモニタリング）するデバイスといい得るものである。

また、引用発明の「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」」（「カメラ」）は、映像、音声等の信号を取得するデバイスである。

よって、引用発明の「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」」（「カメラ」）及び「スマホ」はそれぞれ、本願発明１の「信号取得デバイス」及び「リモートモニタリングデバイス」に相当する。

（イ）引用発明は、「Ｐ２Ｐ方式による映像配信によりスマホにカメラの映像が表示され」るものであるから、「カメラと同一のネットワーク上にあるＰＣのWebブラウザにより、DDNSアドレスを設定し、外出先のPCでWebブラウザを立ち上げ、アドレスバーに「DDNSアドレス」を入力する」ことにより、「カメラ」と「スマホ」との間で「Ｐ２Ｐ方式」の通信リンクを確立する処理を行うものと認められる。また、「Ｐ２Ｐ方式」は「ピアツーピア接続」といい得るものである。

よって、前記（ア）を参酌すれば、引用発明において、「カメラ」と「スマホ」との間で「Ｐ２Ｐ方式」（ピアツーピア接続）の通信リンクを確立することと、本願発明１の「Ｗｅｂオペレーティングシステムを実行する信号取得デバイスとリモートモニタリングデバイスとの間で、ＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立すること」とは、「信号取得デバイスとリモートモニタリングデバイスとの間で、ピアツーピア接続の通信リンクを確立すること」との点において共通する。

（ウ）引用発明において、「Ｐ２Ｐ方式による映像配信によりスマホにカメラの映像が表示され」るためには、「カメラ」が、映像に係るオーディオ信号及び／又はビデオ信号を取得する必要があるため、引用発明は、本願発明１の「前記信号取得デバイスが、オーディオ信号及び／またはビデオ信号を取得すること」に相当する構成を備える。

（エ）引用発明において、「Ｐ２Ｐ方式による映像配信によりスマホにカメラの映像が表示され」るためには、「カメラ」が、映像に係るオーディオ信号及び／又はビデオ信号を「スマホ」に送信する必要があるため、引用発明は、本願発明１の「前記信号取得デバイスが、前記通信リンクを介して前記リモートモニタリングデバイスに前記オーディオ信号及び/または前記ビデオ信号を送信すること」に相当する構成を備える。

（オ）引用発明の「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」」は、「ＰＣやスマホで遠隔操作でき」るものであって、また、「カメラを首フリさせたい場合は、スマホの画面をその方向にフリックすればよく」との構成からすると、「スマホ」の画面をフリックする操作により、「カメラ」を「首フリ」させるための指示命令が「スマホ」から「カメラ」に送信され、「カメラ」は、前記指示命令に応じた「首フリ」を実行するものと理解することができる。

ここで、引用発明の「指示命令」及び「首フリ」はそれぞれ、本願発明１の「オペレーションコマンド」及び「オペレーション」に相当する。

よって、引用発明と、本願発明１の「前記信号取得デバイスが、前記リモートモニタリングデバイスから、異なる瞬間において受信された前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づいて、オペレーションコマンドを受信することであって、前記オペレーションコマンドについてのフィードバックは前記リモートモニタリングデバイスからユーザに送信される、こと」とは、「前記信号取得デバイスが、前記リモートモニタリングデバイスから、オペレーションコマンドを受信すること」との共通の構成を備えるといえる。

（カ）よって、引用発明は、本願発明１の「前記信号取得デバイスが、前記オペレーションコマンドに応じたオペレーションを実行すること」に相当する構成を備える。

（キ）前記（ア）を参酌すれば、引用発明の「監視方法」と本願発明１の「リモートモニタリングの方法」とは、後述する相違点をのぞいて、上記（イ）ないし（カ）で検討した各処理を含む「リモートモニタリングの方法」である点において共通する。

イ 一致点、相違点

したがって、本願発明１と引用発明との間には、次の点において一致ないし相違する。

［一致点］

「 信号取得デバイスとリモートモニタリングデバイスとの間で、ピアツーピア接続の通信リンクを確立することと、

前記信号取得デバイスが、オーディオ信号及び／またはビデオ信号を取得することと、

前記信号取得デバイスが、前記通信リンクを介して前記リモートモニタリングデバイスに前記オーディオ信号及び/または前記ビデオ信号を送信することと、

前記信号取得デバイスが、前記リモートモニタリングデバイスから、オペレーションコマンドを受信することと、

前記信号取得デバイスが、前記オペレーションコマンドに応じたオペレーションを実行することと、

を含む、

リモートモニタリングの方法。」

［相違点］

＜相違点１＞

「信号取得デバイス」が、本願発明１では、「Ｗｅｂオペレーティングシステムを実行する」ものであるのに対し、引用発明の「Ｗｅｂカメラ「ＣＰＨ５３７－Ｐ２Ｐ」」は、「Ｗｅｂ」に係る技術を使用しているものの、「Ｗｅｂオペレーティングシステムを実行する」ものとして具体的に特定されていない点。

＜相違点２＞

「ピアツーピア接続の通信リンクを確立する」に際し、本願発明１では「ＷｅｂＲＴＣ技術を使用して」行うのに対し、引用発明において、「ＷｅｂＲＴＣ技術」を使用することに言及がない点。

＜相違点３＞

「オペレーションコマンドを受信すること」が、本願発明１では、「前記信号取得デバイスが、前記リモートモニタリングデバイスから、異なる瞬間において受信された前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づいて」なされるのに対し、引用発明では、この点を具体的に特定するものではない点。

＜相違点４＞

本願発明１は、「前記オペレーションコマンドについてのフィードバックは前記リモートモニタリングデバイスからユーザに送信される」との構成を備えるのに対し、引用発明は、前記構成を具体的に特定しない点。

＜相違点５＞

本願発明１は、「前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する」との構成を備えるのに対し、引用発明は、前記構成を具体的に特定しない点。

ウ 相違点についての判断

事案に鑑みて、上記相違点３ないし５について先に検討する。なお、相違点３ないし５は、いずれも「前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較」に直接又は間接的に連関するため、まとめて判断する。

引用文献４（引用文献Ｂ）記載事項にあるように、「ＣＰＵ３１」が「Ｉ／Ｏ３４」を介して「ビデオカメラ１」を制御可能であり、「ＣＰＵ３１」が、「ビデオカメラ１」が撮像した複数の部分領域の画像うち、特定の部分領域の画像の変化量が閾値以上であった場合は、当該部分監視領域に対して「ビデオカメラ」の姿勢（パン、チルト、ズーム）をセットして、さらに、その部分監視領域の画像の変化量があらかじめ定めた閾値以上である場合には、警告を、通信Ｉ／Ｆ３７を経由して外部に通報する等の処理を行うことは、本願優先日前の周知技術であるといえる。

しかしながら、引用文献４（引用文献Ｂ）記載事項において、「ＣＰＵ３１」と「ビデオカメラ１」とは「Ｉ／Ｏ３４」を介して接続されたものであるから、引用発明のように「Ｐ２Ｐ方式」で通信接続をするものではなく、また、「ビデオカメラ１」も、引用発明のような「Ｗｅｂカメラ」ではない。

そうすると、引用発明と、引用文献４（引用文献Ｂ）記載事項とは、前提とするシステム構成が異なり、引用発明に引用文献４（引用文献Ｂ）記載事項を適用する動機付けを見い出すことはできず、当業者といえどもこのように適用することが容易に想到できたとはいえない。加えて、引用発明は、「スマホ」の画面を「フリック」する等により、ユーザがカメラを手動で操作するものであるが、そのような構成に替えて、引用文献４記載事項にあるように、画像の変化量に基づいてビデオカメラを自動的に制御するように変更する動機付けも存在しない。

また、当該相違点３ないし５に係る本願発明１の構成は、引用文献２及び３にも記載されていない。

したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用文献１ないし４に記載された発明に基いて容易に発明をすることができたものであるとはいえない。

（２）本願発明４、８及び１２について

本願発明４、８及び１２は、上記相違点３ないし５に係る本願発明１の構成に相当する構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用文献１ないし４に記載された発明に基いて容易に発明をすることができたものとはいえない。

（３）本願発明２、３、５ないし７、９ないし１１、１３及び１４について

本願発明２、３、５ないし７、９ないし１１、１３及び１４は、本願発明１、４又は１２の構成をすべて備え、上記相違点３ないし５に係る本願発明１の構成に相当する構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用文献１ないし４に記載された発明に基いて容易に発明をすることができたものとはいえない。

（４）小括

以上のとおり、本願発明１ないし１４は、当業者が引用文献１ないし４に記載された発明に基いて容易に発明をすることができたものとはいえないから、理由３（進歩性）は、解消した。

第７ 当審拒絶理由１についての判断

１ 理由１（明確性）及び理由２（サポート要件）について

（１）本件補正後の請求項１、４、８及び１２の記載は、「異なる瞬間における前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較」に基づくものが「オペレーションコマンド」であることが明確となった。

（２）本件補正後の請求項１、４、８及び１２の記載は、「ＲＴＣＰｅｅｒＣｏｎｎｅｃｔｉｏｎインターフェースを介して」「直接ピアツーピア接続を確立する」旨の記載は削除され、発明の詳細な説明に記載したものとなった。

（３）本件補正後の請求項４の記載は、日本語として明確でない記載はなく、明確となった。

よって、理由１（明確性）及び理由２（サポート要件）はいずれも解消した。

２ 理由３（進歩性）について

上記第６の２で述べたことと同じ理由により、理由３（進歩性）は、解消した。

第８ 原査定についての判断

１ 本願発明１について

（１）対比

本願発明１と引用発明Ａとを対比する。

ア 引用発明Ａの「車載アプリ例「渋滞ライブカメラ共有サービス」」においては、渋滞の先頭付近を走行するクルマの「ローカル端末」に接続された「カメラ」によって撮影された「カメラ画像」を、リクエストを発信した「クルマの車載機」に送信することにより、当該「クルマの車載機」のユーザが、送信された「カメラ画像」を視聴することができるものと認められる。加えて、引用発明Ａには、「車載アプリ」の例として「盗難防止監視カメラ」を挙げている。以上より、「クルマの車載機」は、渋滞先頭の付近の「カメラ画像」を「ローカル端末」から受信することにより、遠隔地にいるユーザが当該渋滞の様子を「モニタリング」するためのデバイスといい得るものである。

よって、引用発明Ａの（リクエストを発信した）「クルマの車載機」は、本願発明１の「リモートモニタリングデバイス」に相当する。

また、「カメラやマイク」が接続された（渋滞先頭の付近のクルマの）「ローカル端末」は、本願発明１の「信号取得デバイス」に相当する。

また、引用発明Ａは、「WebRTCによる車載アプリ」を使用する方法であることから、「ＷｅｂＲＴＣ」技術を使用しているといえ、また、「WebRTCがサポートする機能」として「P2P（Peer to Peer）でメディアストリームを送受信」を含み、さらに、「PeerConnection」というコマンドを使って「P2Pで接続」していることからすると、「リクエストを発信したクルマの車載機」（ローカルの端末）と「ローカル端末」との間で「カメラ画像」をストリームで送受信するにあたり、「ＷｅｂＲＴＣ」技術として「PeerConnection」を使って「ピアツーピア接続」の通信リンクを確立していると認められる。

よって、引用発明Ａと、本願発明１の「Ｗｅｂオペレーティングシステムを実行する信号取得デバイスとリモートモニタリングデバイスとの間で、ＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立すること」とは、「信号取得デバイスとリモートモニタリングデバイスとの間で、ＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立すること」との共通の構成を備える。

イ 引用発明Ａにおいて、リクエストを発信した「クルマの車載機」が「ローカル端末」からストリームで受信（取得）する「カメラ画像」は、本願発明１の「ビデオ信号」に相当する。

よって、引用発明Ａは、本願発明１の「前記信号取得デバイスが、オーディオ信号及び／またはビデオ信号を取得すること」に相当する構成を備える。

ウ 引用発明Ａにおいて、「WebRTCがサポートする機能」として、「（３）P2Pで任意のデータを送受信」が含まれる。

また、引用発明Ａは、「渋滞に差し掛かったクルマ」（の車載機）が、「PeerConnection」を使い、先頭付近を走行するクルマ（ローカル端末）へライブカメラ映像の「送信リクエスト」をすると、先頭付近を走行するクルマ（ローカル端末）が、当該「送信リクエスト」に応じて、前方のカメラ映像を「getUserMedia」を使ってブラウザーから取得し、さらに「PeerConnection」を使って、リクエストを発信したクルマの車載機とP2Pで接続し、渋滞先頭付近の映像をストリームとして返すという「オペレーション」を実行していると認められる。

よって、引用発明Ａと、本願発明１の「前記信号取得デバイスが、前記リモートモニタリングデバイスから、異なる瞬間において受信された前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づいて、オペレーションコマンドを受信することであって、前記オペレーションコマンドについてのフィードバックは前記リモートモニタリングデバイスからユーザに送信される、こと」とは、「前記信号取得デバイスが、前記リモートモニタリングデバイスから、オペレーションコマンドを受信すること」という共通の構成を備える。

エ 前記ウより、引用発明Ａは、本願発明１の「前記信号取得デバイスが、前記オペレーションコマンドに応じたオペレーションを実行すること」との構成を備える。

オ 前記アを参酌すれば、引用発明Ａの「WebRTCによる車載アプリを使用する方法」と本願発明１の「リモートモニタリングの方法」とは、後述する相違点をのぞいて、上記アないしエで検討した各処理を含む「リモートモニタリングの方法」である点において共通する。

（２）一致点、相違点

したがって、本願発明１と引用発明Ａとの間には、次の点において一致ないし相違する。

［一致点］

「 信号取得デバイスとリモートモニタリングデバイスとの間で、ＷｅｂＲＴＣ技術を使用してピアツーピア接続の通信リンクを確立することと、

前記信号取得デバイスが、オーディオ信号及び／またはビデオ信号を取得することと、

前記信号取得デバイスが、前記通信リンクを介して前記リモートモニタリングデバイスに前記オーディオ信号及び/または前記ビデオ信号を送信することと、

前記信号取得デバイスが、前記リモートモニタリングデバイスから、オペレーションコマンドを受信することと、

前記信号取得デバイスが、前記オペレーションコマンドに応じたオペレーションを実行することと、

を含む、

リモートモニタリングの方法。」

［相違点］

＜相違点１＞

「信号取得デバイス」が、本願発明１では、「Ｗｅｂオペレーティングシステムを実行する」ものであるのに対し、引用発明Ａの「ローカル端末」は、「Ｗｅｂオペレーティングシステムを実行する」ものとして具体的に特定されていない点。

＜相違点２＞

「オペレーションコマンドを受信すること」が、本願発明１では、「異なる瞬間において受信された前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較に基づいて」なされるのに対し、引用発明Ａは、「送信リクエスト」が受信されるにあたり、そのような条件を規定していない点。

＜相違点３＞

本願発明１は、「前記オペレーションコマンドについてのフィードバックは前記リモートモニタリングデバイスからユーザに送信される」との構成を備えるのに対し、引用発明Ａは、当該構成を備えることについて具体的に特定していない点。

＜相違点４＞

本願発明１は、「前記リモートモニタリングデバイスは、前記リアルタイムの比較の結果が大きな差を示すことをアラームの条件の１つとして使用する」との構成を備えるのに対し、引用発明Ａは、当該構成を備えることについて具体的に特定していない点。

（３）相違点についての判断

事案に鑑みて、上記相違点２ないし４について先に検討する。なお、相違点２ないし４は、いずれも「前記オーディオ信号及び/またはビデオ信号のリアルタイムの比較」に直接又は間接的に連関するものであるため、まとめて判断する。

引用発明Ａは、「WebRTCを使った車載アプリ」の例として「盗難防止監視カメラ」を挙げているものの、「監視」に特化した具体的な構成について何ら特定していない。

また、引用文献４（引用文献Ｂ）記載事項は、「監視」を目的としたものであるが、「ＣＰＵ３１」と「ビデオカメラ１」とは「Ｉ／Ｏ３４」を介して接続されたものであるから、引用発明Ａのように「Ｐ２Ｐ方式」で通信接続をするものではなく、引用発明Ａのように「ＷｅｂＲＴＣ」技術を使用したものでもない。

そうすると、引用発明Ａと、引用文献４（引用文献Ｂ）記載事項とは、前提とするシステム構成や技術分野が異なり、引用発明Ａに引用文献４（引用文献Ｂ）記載事項を適用する動機付けを見い出すことはできず、当業者といえどもこのような適用が容易に想到できたとはいえない。

また、当該相違点２ないし４に係る本願発明１の構成は、引用文献Ｃ（引用文献３）にも記載されていない。

したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用文献ＡないしＣに記載された発明に基いて容易に発明をすることができたものであるとはいえない。

２ 本願発明４、８及び１２について

本願発明４、８及び１２は、上記相違点２ないし４に係る本願発明１の構成に相当する構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用文献ＡないしＣに記載された発明に基いて容易に発明をすることができたものとはいえない。

３ 本願発明２、３、５ないし７、９ないし１１、１３及び１４について

本願発明２、３、５ないし７、９ないし１１、１３及び１４は、本願発明１、４又は１２の構成をすべて備え、上記相違点２ないし４に係る本願発明１の構成に相当する構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用文献ＡないしＣに記載された発明に基いて容易に発明をすることができたものとはいえない。

第９ むすび

以上のとおり、原査定の理由によって、本願を拒絶することはできない。

他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。