• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 H04W
審判 査定不服 5項独立特許用件 特許、登録しない。 H04W
審判 査定不服 1項3号刊行物記載 特許、登録しない。 H04W
管理番号 1351791
審判番号 不服2018-2790  
総通号数 235 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-07-26 
種別 拒絶査定不服の審決 
審判請求日 2018-02-27 
確定日 2019-05-16 
事件の表示 特願2013-271480「通信装置」拒絶査定不服審判事件〔平成27年 7月 6日出願公開、特開2015-126491〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、平成25年12月27日の出願であって、その手続の経緯は以下のとおりである。

平成29年 1月26日付け 拒絶理由通知書
平成29年 5月17日 意見書、手続補正書の提出
平成29年11月24日付け 拒絶査定
平成30年 2月27日 拒絶査定不服審判の請求、手続補正書の提出

第2 平成30年2月27日にされた手続補正についての補正の却下の決定
[補正の却下の決定の結論]
平成30年2月27日にされた手続補正(以下、「本件補正」という。)を却下する。

[理由]
1 本件補正について
(1)本件補正後の特許請求の範囲の記載
本件補正により、特許請求の範囲の請求項1の記載は、次のとおり補正された。(以下、「本願補正発明」という。)(下線部は、補正箇所である。)

「通信装置であって、
NFC(Near Field Communicationの略)規格に従った通信方式であるNFC方式の無線通信を実行するための第1のインターフェースと、
制御部と、を備え、
前記制御部は、
前記第1のインターフェースが前記NFC規格のP2P(Peer to Peerの略)モードに従って動作しており、かつ、前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第1のインターフェースを介した第1の接続が携帯端末と確立される場合に、前記第1のインターフェースに第2の動作を実行させることによって、前記第1の接続を利用して、前記携帯端末から要求を受信しなくても、前記エラー状態に関係する関係情報を前記携帯端末に送信する第1の送信制御部であって、前記第2の動作は、前記第1のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作であって、前記NFC規格のSNEP(Simple NDEF (NFC Data Exchange Formatの略) Exchange Protocolの略)で定められているクライアントの動作である、前記第1の送信制御部と、
前記第1のインターフェースが前記P2Pモードに従って動作しており、かつ、前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第1のインターフェースを介した第2の接続が前記携帯端末と確立される場合に、前記第1のインターフェースに第1の動作を実行させることによって、前記第2の接続を利用して、前記携帯端末から特定要求を受信する受信制御部であって、前記第1の動作は、前記第1のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作であって、前記NFC規格の前記SNEPで定められているサーバの動作である、前記受信制御部と、
前記特定要求が受信されることに応じて、前記第1のインターフェースに前記第2の動作を実行させることによって、前記第2の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第2の送信制御部と、
を備える通信装置。」

(2)本件補正前の特許請求の範囲の記載
本件補正前の、平成29年5月17日にされた手続補正により補正された特許請求の範囲の請求項1の記載は次のとおりである。(以下、「本願発明」という。)

「通信装置であって、
NFC(Near Field Communicationの略)規格に従った通信方式であるNFC方式の無線通信を実行するための第1のインターフェースと、
制御部と、を備え、
前記制御部は、
前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第1のインターフェースを介した第1の接続が携帯端末と確立される場合に、前記第1の接続を利用して、前記携帯端末から要求を受信しなくても、前記エラー状態に関係する関係情報を前記携帯端末に送信する第1の送信制御部と、
前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第1のインターフェースを介した第2の接続が前記携帯端末と確立される場合に、前記第2の接続を利用して、前記携帯端末から特定要求を受信する受信制御部と、
前記特定要求が受信されることに応じて、前記第2の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第2の送信制御部と、
を備える通信装置。」

1 補正の適否
請求項1についての上記補正は、
本件補正前の請求項1に記載された発明を特定するために必要な事項である「前記エラー状態に関係する関係情報を前記携帯端末に送信する第1の送信制御部」について、「前記第1のインターフェースが前記NFC規格のP2P(Peer to Peerの略)モードに従って動作しており」「前記第1のインターフェースに第2の動作を実行させることによって」「前記第2の動作は、前記第1のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作であって、前記NFC規格のSNEP(Simple NDEF (NFC Data Exchange Formatの略) Exchange Protocolの略)で定められているクライアントの動作である」との限定を付加し、
本件補正前の請求項1に記載された発明を特定するために必要な事項である「前記携帯端末から特定要求を受信する受信制御部」について、「前記第1のインターフェースが前記NFC規格のP2Pモードに従って動作しており」「前記第1のインターフェースに第1の動作を実行させることによって」「前記第1の動作は、前記第1のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作であって、前記NFC規格の前記SNEPで定められているサーバの動作である」との限定を付加し、
本件補正前の請求項1に記載された発明を特定するために必要な事項である「前記関係情報とは異なる特定情報を前記携帯端末に送信する第2の送信制御部」について、「前記第1のインターフェースに前記第2の動作を実行させることによって」との限定を付加するものである。
そして、補正前の請求項1に記載された発明と補正後の請求項1に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるから、当該補正は、特許法17条の2第5項2号の特許請求の範囲の減縮を目的とするものに該当する。そして、同法第17条の2第3項、第4項に違反するところはない。
そこで、本願補正発明が同条第6項において準用する同法第126条第7項の規定に適合するか(特許出願の際独立して特許を受けることができるものであるか)について、以下、検討する。

(1)本願補正発明
本願補正発明は、上記「1 本件補正について」の「(1)本件補正後の特許請求の範囲の記載」の本願補正発明のとおりのものと認める。

(2)引用発明、周知事項
ア 引用発明
原査定の拒絶の理由で引用された特開2013-187567号公報(以下、「引用例」という。)には、図面とともに、以下の事項が記載されている。(下線は当審が付与。)

(ア)「【0011】
本実施例では、低速通信の近接無線通信方式を用いて認証を行ってから、高速通信の無線通信に切り替えて印刷データを送信する例を説明する。具体的には、NFC(Near Field Communication)のような近距離無線通信で認証を行い、他の通信方式の無線通信に通信を引き継ぐ(ハンドオーバ)技術を用いた印刷方法について説明する。
【0012】
図1は、本実施例における無線通信システムの構成を示す図である。ネットワーク100を中心にサーバ装置101、携帯型通信端末装置200、情報処理装置の一例であるマルチファンクションプリンタ(MFP)300が接続されている。(中略)印刷装置の一例となるMFP300は、原稿台に原稿を載せて原稿を読み取る読取機能と、インクジェットプリンタなどの印刷部を用いる印刷機能を有している。(中略)携帯型通信端末装置200とMFP300は、共にWLANの機能を有するので、相互認証をすることによりピアツーピア(P2P)の通信が可能である。
(中略)
【0017】
次に、NFC通信について説明する。NFCユニットによる近接通信を行う場合に、始めにRFフィールド(Radio Frequency Field)を発信して近距離無線通信を開始する装置をイニシエータと呼ぶ。また、イニシエータの発する命令に応答することで、イニシエータとの通信を行う装置をターゲットと呼ぶ。NFCユニットの通信モードには、パッシブモードとアクティブモードが存在する。パッシブモードでは、ターゲットは、イニシエータの命令に対して、イニシエータの発するRFフィールドを負荷変調することで応答する。一方、アクティブモードでは、ターゲットは、イニシエータの命令に対して、ターゲット自らがRFフィールドを発することにより応答する。
(中略)
【0024】
携帯型通信端末装置200には無線通信するための構成が3つ設けられており、携帯型通信端末装置200は、WLAN、NFC、Bluetooth(登録商標)で無線通信することができる。WLANユニット817、NFCユニット818、BTユニット821は、MFPなどの他の装置とのデータ通信を行う通信部である。各ユニット817、818、821は、データをパケットに変換して、他の装置にパケット送信を行う。逆に、外部の他の装置からのパケットをデータに変換して、CPU802に対して送信する。WLANユニット817、NFCユニット818、BTユニット821は、それぞれバスケーブル815、816、820でシステムバス819と接続されている。WLANユニット817、NFCユニット818、BTユニット821は、規格に準拠した通信を実現するためのユニットである。NFCユニット818の詳細は、図10において後述する。
(中略)
【0026】
図9は、MFP300の概略構成を示すブロック図である。MFP300は、装置のメインの制御を行うメインボード901と、WLAN通信を行うWLANユニット917と、NFC通信を行うNFCユニット918と、Bluetooth(登録商標)通信を行うBTユニット919とを含む。
【0027】
メインボード901のCPU902は、システム制御部であり、MFP300の全体を制御する。ROM903は、CPU902が実行する制御プログラムや組み込みオペレーティングシステム(OS)プログラム等を格納する。本実施例では、ROM903に格納されている各制御プログラムは、ROM903に格納されている組み込みOSの管理下で、スケジューリングやタスクスイッチ等のソフトウェア制御を行う。
【0028】
RAM904は、SRAM(static RAM)等で構成され、プログラム制御変数やユーザが登録した設定値やMFP300の管理データ等を格納し、また、各種ワーク用バッファ領域が設けられている。不揮発性メモリ905は、フラッシュメモリ(flash memory)等で構成され、電源がオフされた時でも保持していたいデータを格納する。例えば、ネットワーク接続情報、ユーザデータである。画像メモリ906は、DRAM(dynamic RAM)等で構成され、各通信ユニットを介して受信した画像データや、符号復号化処理部912で処理した画像データや、メモリカードコントローラ516を介して取得した画像データなどを蓄積する。また、携帯型通信端末装置200のメモリ構成と同様に、メモリ構成は上記に限定されるものではない。データ変換部907は、ページ記述言語(PDL)等の解析や、画像データから印刷データへの変換などを行う。
(中略)
【0032】
図10は、NFCユニット818やNFCユニット918として用いられるNFCユニット1000の詳細構成を示す図である。NFCユニット1000は、NFCコントローラ部1001と、アンテナ部1002と、RF部1003と、送受信制御部1004と、NFCメモリ1005と、電源1006と、デバイス接続部1007とを有する。アンテナ部1002は、他のNFCデバイスから電波やキャリアを受信したり、他のNFCデバイスに電波やキャリアを送信したりする。RF部1003はアナログ信号をデジタル信号に変復調する機能を備えている。RF部103はシンセサイザを備えていて、バンド、チャネルの周波数を識別し、周波数割り当てデータにより、バンド、チャネルを制御する。送受信制御部1004は、送受信フレームの組み立て及び分解、プリアンブル付加及び検出、フレーム識別など、送受信に関する制御を行う。送受信制御部1004は、NFCメモリ1005の制御も行い、各種データやプログラムを読み書きする。
(中略)
【0036】
図13は、MFPのRAM904の構成を示す図である。1301は、RAM全体を表している。ワークメモリ1302は、プログラムの実行のために確保されるメモリである。画像処理バッファ1303は、画像処理のために一時的なバッファとして使用される領域である。機器状態記憶部1304は、MFP300の現在の状態に関する様々な情報が記憶されている。エラー状態1305は、MFP300のエラーに関する状態を記憶している。エラーに関する状態とは、例えば、インク少警告、インク無エラー、紙ジャムエラー、用紙無し警告、印字画像画像不良警告、読取画像不良エラー、ネットワーク切断警告、である。(中略)
【0038】
図14は、MFP300のフラッシュメモリ905の構成を示す図である。1401は、フラッシュメモリ全体を表している。ユーザデータ1402は、ユーザに関する情報が記憶されており、例えばFAXの電話番号、通信履歴、ネットワーク情報などが格納されている。過去に接続した装置リスト1403は、MFP300がこれまでに接続した装置のリストが格納されている。例えばスマートホンとNFCで通信した場合には、スマートホンの識別子がリスト1405として記憶される。また、カメラとNFCで通信した場合には、カメラの識別子がリスト1404として記憶される。
【0039】
スマートホンとWLANでP2Pで接続した場合は、WLANで接続するための識別情報が記憶される。例えば、WLAN接続のためにWPS(Wi-Fi Protected Setup)が使用される場合には、WPS Credential認証情報が記憶される。スマートホンとBluetoothで接続した場合には、OOB認証情報が記憶される。サーバ装置とLAN経由で接続した場合には、サーバ装置のネットワーク情報が記憶される。設定情報1406はMFP装置の設定情報が記憶される。例えば印刷モードなどのメニュー項目や、インクジェット記録方式における記録ヘッドの補正情報などが記憶される。その他1407には、他の不揮発情報が記憶される。
【0040】
図15は、MFP300のNFCメモリ1005の構成を示す図である。1501は、NFCメモリ全体を表している。機器状態記憶部1502は、所定のタイミングで機器状態記憶部1304の内容がコピーされる。従って、エラー状態1503、インク残量1504、次回推定起動時間1505はそれぞれ、エラー状態1305、インク残量1306、次回推定起動時間1307に対応する。(中略)
【0044】
図19は、図14で説明したWPS Credential認証情報とOOB認証情報の一例を示す図である。WPS CrEdential認証情報には、SSID、Encryption、Auth Type、Network Key、MAC adressなどが含まれる。また、OOB認証情報には、BTaddress、Hash C、Randomizer Rなどが含まれる。これらの情報を、認証元から認証先に渡すことで認証を行い、WLANやBluetoothによるピアツーピアの通信が可能となる。」(4?11ページ)

(イ)「【0045】
図20は、NFCユニットがイニシエータとして動作する手順を示すフローチャートである。図20に示す各処理は、NFCユニットが搭載されている装置のCPU等によって実行される。まず、S2001において、全てのNFCユニットはターゲットとして動作し、イニシエータからの命令を待機する状態になる。次に、S2002において、NFCユニットは、NFC規格に準拠する通信を制御するアプリケーションからの要求により、イニシエータに切り替わることができる。NFCユニットがイニシエータに切り替わる要求に応じた場合、S2003において、アプリケーションは、アクティブモードまたはパッシブモードのいずれかを選択して、伝送速度を決定する。次に、S2004において、イニシエータは、自装置以外が出力するRFフィールドの存在を検出する。外部のRFフィールドの存在を検出した場合には、イニシエータは自らのRFフィールドは発生させない。外部のRFフィールドの存在を検出しなかった場合には、S2005に進み、イニシエータは、自らのRFフィールドを発生させる。以上の工程を経て、NFCユニットは、イニシエータとして動作を開始する。
【0046】
図21は、パッシブモードによるデータ交換を行うシーケンスを示す図である。また、図24は、図21の流れをフローチャートとして示す図である。図21に基づいて、図24の各工程と対応付けながら説明する。図24に示す各処理は、NFCユニットが搭載されている装置のCPU等によって実行される。以下、第1のNFCユニット2101がイニシエータ、第2のNFCユニット2102がターゲットとして動作している場合について説明する。まず、S2101において、第1のNFCユニット2101は、単一デバイス検知を行い、第2のNFCユニット2102を特定する(S2401)。つまり、S2101において第1のNFCユニット2101と第2のNFCユニット2102とは、お互いの存在を検出している。次に、S2102において、第1のNFCユニット2101は、属性要求として自身の識別子や、送受信のビット伝送速度、有効データ長などを相手先に送信する(S2402)。また、属性要求は汎用バイトを有しており、任意に選択して使用することができる。第2のNFCユニット2102は、有効な属性要求を受信した場合に、S2103において、属性応答を送信する。ここで、第2のNFCユニット2102からの送信は負荷変調によって行われており、図中では、負荷変調によるデータ送信を点線の矢印で示す。
【0047】
有効な属性応答を確認した後(S2403)、第1のNFCユニット2101は、S2104において、パラメータ選択要求を送信して、引き続く伝送プロトコルのパラメータを変更することができる。パラメータ選択要求に含まれるパラメータとは、例えば、伝送速度と有効データ長である。第2のNFCユニット2102は、有効なパラメータ選択要求を受信した場合に、S2105においてパラメータ選択応答を送信してパラメータを変更する(S2404?S2409)。なお、S2104及びS2105は、パラメータ変更を行わない場合には省略しても良い。
【0048】
次に、S2106において、第1のNFCユニット2101と第2のNFCユニット2102は、データ交換要求およびデータ交換応答によってデータ交換を行う(S2410)。データ交換要求およびデータ交換応答の際に、通信相手が有するアプリケーションに対する情報などをデータとして伝送することができ、データサイズが大きい場合には分割して送信することもできる。
【0049】
データ交換が終了すると、S2107に移行し、第1のNFCユニット2101は、選択解除要求または解放要求のいずれかを送信する(S2411、S2414)。選択解除要求を送信した場合に、第2のNFCユニット2102は、S2108において選択解除応答を送信する(S2412)。第1のNFCユニット2101は、選択解除応答を受信すると、第2のNFCユニット2102を示す属性を解放して(S2413)、S2101に戻る。また、解放要求を送信した場合に、第2のNFCユニット2102は、S2108で解放応答を送信して初期状態に戻る(S2415)。第1のNFCユニット2101は、解放応答を受信すれば、ターゲットは完全に解放されているので、初期状態に戻っても良い。
【0050】
図22は、アクティブモードによるデータ交換を行うシーケンスを示す図である。また、図25は、図22の流れをフローチャートとして示す図である。図22に基づいて、図25の各工程と対応付けながら説明する。図25に示す各処理は、NFCユニットが搭載されている装置のCPU等によって実行される。以下、第1のNFCユニット2201がイニシエータ、第2のNFCユニット2202がターゲットとして動作している場合について説明する。まず、S2201において、第1のNFCユニット2201は、属性要求として自身の識別子や送受信のビット伝送速度、有効データ長などを送信する(S2501)。第2のNFCユニット2202は、有効な属性要求を受信した場合に、S2202において属性応答を送信する。ここで、第2のNFCユニット2202からの送信は、自らの発したRFフィールドによって行われる。このため、第1および第2のNFCユニットは、データ送信が終了する際にはRFフィールドの出力を停止する。
【0051】
有効な属性応答を確認した後(S2502)、第1のNFCユニット2201は、S2203において、パラメータ選択要求を送信して伝送プロトコルのパラメータを変更することができる(S2504?2508)。パラメータ選択要求に含まれるパラメータは、伝送速度と有効データ長である。第2のNFCユニット2202は、有効なパラメータ選択要求を受信した場合に、S2204においてパラメータ選択応答を送信してパラメータを変更する。なお、パッシブモードの場合と同様に、S2203及びS2204は、パラメータ変更を行わない場合には、省略しても良い。
【0052】
次に、S2205において、第1のNFCユニット2201と第2のNFCユニット2202は、データ交換要求およびデータ交換応答によってデータの交換を行う(S2509)。データ交換要求およびデータ交換応答の際に、アプリケーションに対する情報などをデータとして伝送することができ、データサイズが大きい場合には、分割して送信することもできる。
【0053】
データ交換が終了するとS2206に移行し、第1のNFCユニット2201は、選択解除要求または解放要求のいずれかを送信する(S2509、S2510)。選択解除要求を送信した場合に(S2510)、第2のNFCユニット2202は、S2207において選択解除応答を送信する(S2511)。第1のNFCユニット2201は、選択解除応答を受信すると、第2のNFCユニット2202を示す属性を解放する(S2512)。その後、S2208において、第1のNFCユニット2201は、識別子が既知な別のターゲットに対して起動要求を送信する(S2513)。起動要求を受けたターゲットは、起動応答をS2209において送信し(S2514)、S2201に戻る。また、S2206で解放要求を送信した場合に(S2515)、第2のNFCユニット2202は、S2207で解放応答を送信して初期状態に戻る(S2516)。第1のNFCユニット2201は、解放応答を受信すると、ターゲットは完全に解放されているので、初期状態に戻っても良い。」(11?12ページ)

(ウ)「【0058】
図26は、NFCとWLANとを切り換えてデータ転送を行うシーケンスを示す図である。NFCは、通信速度が数百bpsと比較的低速であるので、NFCを用いて認証等を行い、容量の大きいデータは、高速なWLANで行うことで効率的なデータ転送を図ることができる。図26は、携帯型通信端末装置2601上に存在する画像データを印刷装置2602で印刷するために、携帯型通信端末装置2601が主体となって転送する、いわゆるプッシュ型の一例を示す図である。図26に示す携帯型通信端末装置側の処理は、例えばCPU802により実行され、印刷装置側の処理は、例えばCPU902により実行される。
【0059】
S2601において、NFC通信を確立するため、NFC通信部2603がイニシエータとなって、NFC通信部2605をターゲットとして検知する。NFC通信部2605が正しく検知された場合に、S2602において、NFC通信部2605は、検知応答を送信する。なお、図26は携帯型通信端末装置2601がイニシエータとなる場合を示しているが、操作表示部305などからの入力に基づいて印刷装置2602がイニシエータとなっても良い。検知応答を正しく受信した場合に、NFC通信部2603は、S2603においてNFC通信を行うための属性要求を送信する。属性要求を受信したNFC通信部2605は、S2604で属性応答を返信する。ここで、属性要求および属性応答では、それぞれイニシエータおよびターゲットのNFC-IDを送信し、このIDによって通信相手を特定する。
【0060】
S2605において相互認証が行われ、データ暗号化のための暗号鍵等を渡すことができる。なお、暗号鍵を渡す必要がない場合などは、この相互認証を行わなくても良い。その後、S2606において、NFC通信部2603は、NFC通信部2605に対して、印刷装置2602が利用可能な通信プロトコルの情報を要求する。この要求には携帯型通信端末装置2601が利用可能な通信プロトコルの情報が含まれており、NFC通信部2605は、この要求を受信した際に、携帯型通信端末装置2601のWLAN通信が利用可能であることを認識することができる。NFC通信部2605は、S2607において、S2606で受信した要求に対して、自身の利用可能な通信プロトコルの情報を応答する。これによって互いの装置は、互いの利用可能な通信プロトコルを認識することができる。
【0061】
ここで、認識したNFC以外のプロトコルであるWLANが、NFCよりも高速なデータ転送が可能であり、WLANに切り換えて通信を行うことがイニシエータである携帯型通信端末装置2601によって決定されたとする。なお、切り換えを行うための決定は、印刷装置2602が行っても良い。その場合、S2608およびS2609において、WLANで通信を行うために必要な、通信相手を特定するアドレス等の情報を交換する。その後、S2610に移行し、NFC通信部2603は、NFC通信からWLAN通信へと切り換える要求を送信する。NFC通信部2605は、切り換えの要求を受信すると、S2611において、その要求に対する応答を行う。
【0062】
正しい切り換え応答が得られたら、S2612において、NFC通信部2603からWLAN通信部2604へと、S2613において、NFC通信部2605からWLAN通信部2606へと、それぞれ切り換えを行う。切り換えを行った後、S2614において、NFC通信部2603は、解放要求を送信する。解放要求を受信したNFC通信部2605は、S2615において解放応答を送信し、NFC通信を終了する。
【0063】
S2616以降では、S2608およびS2609で交換したWLAN通信のための情報に基づいてWLAN通信が行われる。(後略)」(13?14ページ)

(エ)「【0067】
図28のシーケンスを実行する際に、印刷装置2802が紙詰まり等のエラー状態であった場合、携帯型通信端末装置2801のユーザは気がつかずに印刷ジョブを送信してしまう可能性がある。また、携帯型通信端末装置2801上で印刷設定を行ってから印刷装置2802に印刷ジョブを送信する際に印刷装置2802がエラー状態であると、それまでに行った画像の選択等の操作が無駄になってしまう。
【0068】
そこで、本実施例においては、図29に示す処理を実行することで、携帯型通信端末装置2801のユーザが無駄な操作を行うことを防ぐ。図29に示す各処理は、印刷装置2802のCPU902により実行される。S2901において、印刷装置2802がエラー状態であるか否かを判定する。ここで、エラー状態の判定とは、印刷装置2802が印刷に影響を与える状態であるか否かということである。例えば、インク無しエラー、紙ジャムエラーなどである。エラー以外でも影響を与える可能がある警告をエラー状態として判定しても良い。例えば、そのような警告として、インク少警告、用紙無し警告など、印刷している最中に発生する可能性が高いものであったり、印刷はできるのだが画質に影響がある状態である印刷画像不良警告などがある。このような状態が検知された場合には、S2902に進み、状態通知アプリ1を起動する。
【0069】
状態通知アプリ1とは、印刷装置2802がエラーなどの印刷に影響を与える状態である場合に、NFCで印刷ジョブを送信してくる装置にエラーの旨を通知するためのアプリケーションである。印刷装置2802の表示部911にエラーを表示させても良い。S2903において、状態通知アプリ1がNFC通信部2805をイニシエータモードに遷移させてS2904に進む。S2904において、NFC機器が接近(近接)したことを検知すると、S2905に進む。ここで接近するNFC機器は、イニシエータモードとターゲットモードとのいずれでも良い。イニシエータモードのNFC機器が近づいてきた場合には、印刷装置2802のNFC機器はターゲットモードに戻って、携帯型通信端末装置2801と通信を行う。一方、ターゲットモードのNFC機器が近づいてきた場合には、印刷装置2802のNFC機器は、そのまま携帯型通信端末装置2801と通信を行う。通信の確立ができたらS2905に進み、印刷装置2802の状態を通知し、S2906に進み、本処理を終了する。
【0070】
本実施例においては、図29に示す処理を実施することで携帯型通信端末装置2801のユーザは印刷装置2802のエラーを事前に知ることができるので、画像の選択等無駄な操作を行うことを防ぐことができる。例えば、携帯型通信端末装置上では何も操作しない状態で、ユーザが印刷したい印刷装置に近づけるだけで印刷可能かどうかを知ることができる。また、印刷以外の操作で近づけた場合でも優先してエラー情報を通知してくれるので、ユーザは印刷装置2802のエラー状態を把握することができる。また、イニシエータモードに遷移をすると電力消費量が大きくなるため、前述したスリープモード(省電力モード)の時はイニシエータモードに遷移をしない制御を行っても良い。」(15?16ページ)

(オ)


上記(ア)?(オ)の各記載及び当該技術分野の技術常識を考慮すると、
a 上記(ア)の段落0012、0026?0027及び上記(オ)の図9の記載によれば、印刷装置であるMFP300は、NFC通信を行うNFCユニット918と、システム制御部であるCPU902を備える。そして、上記(ア)の段落0024の記載によれば、NFCユニット818は規格に準拠した通信を実現するためのユニットであるから、NFCユニット918も同様に準拠していることは明らかであり、上記(ア)の段落0011の記載によれば、NFCは近距離無線通信といえる。
したがって、引用例には、「印刷装置であって、NFC規格に準拠した近距離無線通信を実行するためのNFCユニットと、システム制御部であるCPUと、を備え」る、「印刷装置」が記載されている。

b 上記(エ)の記載における印刷装置2802のNFC通信部2805及び印刷装置2802のNFC機器はいずれも、図9の印刷装置であるMFP300のNFCユニット918に対応するといえる。
上記(エ)の段落0068の記載によれば、印刷装置2802のCPU902により、以下の段落0068?0070及び図29に示す処理が実行される。

上記(エ)の段落0068?0069及び上記(オ)の図29の記載によれば、印刷装置2802のCPU902は、印刷装置2802でインク無しエラーや紙ジャムエラーなどのエラーが発生しているエラー状態であることを判定すると、状態通知アプリを起動し、NFC通信部2805をイニシエータモードに遷移させる。
ここで、上記イニシエータモードに関し、上記(イ)の段落0045の記載によれば、全てのNFCユニットはまずターゲットとして動作し、アプリケーションからの要求によりイニシエータに切り替わるので、イニシエータモードとは、イニシエータとして動作する状態といえる。
よって、印刷装置のCPUは、「印刷装置でエラーが発生しているエラー状態であることを判定すると、NFC通信部(NFCユニット)をイニシエータに遷移させ」るといえる。

そして、上記(エ)の段落0069及び上記(オ)の図29の記載によれば、ターゲットモードのNFC機器が近づいてきた場合、印刷装置2802のNFC機器は、携帯型通信端末装置2801と通信を行い、通信の確立ができたら、印刷装置2802の状態を通知する。
ここで、上記「通信の確立」に関し、上記(ウ)の段落0059の記載によれば、NFC通信を確立するために、イニシエータとターゲットは、互いを検知し、属性要求と属性応答を送信することでNFC-IDを送信し、通信相手を特定する。そして、上記(ウ)の段落0062の記載によれば、イニシエータとターゲットは、解放要求と解放応答を送信してNFC通信を終了する。よって、引用例において、NFCの「通信の確立」がされることは、NFC通信のための「接続が確立」されることといえる。また、上記(ア)の段落0038からも、接続を確立して通信していることは明らかである。
よって、印刷装置のCPUは、「NFC機器(NFCユニット)を介して、携帯型通信端末装置との接続が確立されると」、印刷装置2802の状態を通知するといえる。

そして、上記「状態を通知」することに関し、上記(エ)の段落0070の記載によれば、携帯型通信端末装置2801を印刷装置2802に近づけると、印刷装置2802がエラー情報を通知し、携帯型通信端末装置2801のユーザは印刷装置2802のエラー状態を把握できることから、印刷装置2802のNFC機器(NFCユニット)は、「エラー状態であることを示すエラー情報を携帯型通信端末装置に送信」するといえる。
また、上記(イ)の段落0046?0053の記載によれば、要求を送信するのがイニシエータであり、応答を送信するのがターゲットであるから、イニシエータモードに遷移した印刷装置のNFCユニットは、ターゲットモードの「携帯型通信端末装置」のNFCユニット「から要求を受信しなくても」、送信することは明らかである。
そして、上記NFC機器(NFCユニット)が送信する処理は、上記(エ)の段落0068より、印刷装置2802のCPU902により実行されるから、印刷装置のCPUは、「NFC機器(NFCユニット)に送信動作を実行させる」といえる。
よって、印刷装置のCPUは、「NFC機器(NFCユニット)に送信動作を実行させることによって、携帯型通信端末装置から要求を受信しなくても、エラー状態であることを示すエラー情報を携帯型通信端末装置に送信」するといえる。

ここで、エラー状態であることを示すエラー情報を携帯型通信端末装置に送信する「送信動作」に関し、上記(ア)の段落0032、0036及び0040の記載によれば、印刷装置であるMFP300のRAM904に記憶されたエラー状態は、所定のタイミングでNFCユニット918のNFCメモリ1005にコピーされ、当該コピーは印刷装置のCPUが行うといえるから、NFCユニットは、CPUからエラー状態であることを示すエラー情報を取得し、携帯型通信端末装置に送信するといえる。
よって、「上記送信動作は、NFCユニットが、CPUから取得する情報を、携帯型通信端末装置に送信する動作であ」るといえる。

したがって、引用例には、印刷装置のCPUは、「印刷装置でエラーが発生しているエラー状態であることを判定すると、NFCユニットをイニシエータに遷移させ、NFCユニットを介して、携帯型通信端末装置との接続が確立されると、NFCユニットに送信動作を実行させることによって、携帯型通信端末装置から要求を受信しなくても、エラー状態であることを示すエラー情報を携帯型通信端末装置に送信し、前記送信動作は、NFCユニットが、CPUから取得する情報を、携帯型通信端末装置に送信する動作であ」ることが記載されている。

c 上記(ウ)及び上記(オ)の図26の記載における印刷装置2602のNFC通信部2605は、図9の印刷装置であるMFP300のNFCユニット918に対応するといえる。
上記(ウ)の段落0058の記載によれば、印刷装置2602のCPU902により、以下の段落0059?0063及び図26に示す印刷装置2602側の処理が実行される。

上記(ウ)の段落0059及び上記(オ)の図26の記載によれば、NFC通信を確立するために、携帯型通信端末装置2601のNFC通信部2603がイニシエータとなって、印刷装置2602のNFC通信部2605をターゲットとして検知し、イニシエータとターゲットは属性要求と属性応答を送信することでNFC-IDを送信し、通信相手を特定する。このとき、印刷装置2602のNFC通信部2605はターゲットとして動作しているといえる。そして、上記(ウ)の0062の記載によれば、イニシエータとターゲットは、解放要求と解放応答を送信してNFC通信を終了する。これらの一連の動作からみて、ターゲットとして動作する印刷装置2602のNFC通信部2605と、イニシエータとなった携帯型通信端末装置2601のNFC通信部2603との、NFC通信を確立することは、NFC通信のための「接続が確立」されることといえる。
よって、印刷装置のCPUによって、「ターゲットとして動作するNFC通信部(NFCユニット)を介して、携帯型通信端末装置との接続が確立される」といえる。

そして、上記(ウ)の段落0060及び上記(オ)の図26の記載によれば、印刷装置2602のNFC通信部2605は、携帯型通信端末装置2601のNFC通信部2603から、「利用可能な通信プロトコルの情報の要求」を受信し、この要求には携帯型通信端末装置2601が利用可能な通信プロトコルとしてWLAN情報が含まれ、当該要求を受信した印刷装置2602のNFC通信部2605は、「自身の利用可能な通信プロトコルとしてWLAN情報」を「応答」する。
また、上記(ウ)の段落0061及び0063の記載によれば、印刷装置2602のNFC通信部2605は、携帯型通信端末装置2601のNFC通信部2603と、WLANで通信を行うために必要な情報を交換する。ここで、上記(イ)の段落0046、0048、0050、0052の記載によれば、データ交換は、イニシエータからのデータ交換要求及びターゲットからのデータ交換応答によりなされるので、上記「WLANで通信を行うために必要な情報」の交換も、イニシエータである携帯型通信端末装置2601のNFC通信部2603からの「データ交換要求」、及び、ターゲットである印刷装置2602のNFC通信部2605からの「データ交換応答」により、なされると解することができる。
これらの処理は、印刷装置2602のCPU902により実行されるので、印刷装置のCPUは、「携帯型通信端末装置から」要求を「受信」する際に「NFC通信部(NFCユニット)に受信動作を実行させ」、応答を「携帯型通信端末装置に送信」する際に「NFC通信部(NFCユニット)に送信動作を実行させ」るといえる。
よって、印刷装置のCPUは、「NFC通信部(NFCユニット)に受信動作を実行させることによって、携帯型通信端末装置から、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信し」、「前記利用可能な通信プロトコルの情報の要求、又は、前記WLANで通信を行うために必要な情報についてのデータ交換要求が受信されることに応じて、NFC通信部(NFCユニット)に送信動作を実行させることによって、自身の利用可能な通信プロトコルとしてWLAN情報の応答、又は、WLANで通信を行うために必要な情報についてのデータ交換応答を、携帯型通信端末装置に送信」するといえる。
また、これらの処理は、印刷装置でエラーが発生している状態での動作ではないから、「印刷装置でエラーが発生していない状態において」行われるといえる。

そして、上記(ア)の段落0038?0039及び0044の記載によれば、印刷装置であるMFP300のフラッシュメモリ905に、ネットワーク情報や、WLAN接続のためのSSID、MACアドレス等のWPA Credential認証情報が記憶されている。また、上記(ア)の段落0024の記載によれば、携帯型通信端末装置200のNFCユニット818は、他の装置からのパケットをデータに変換してCPU802に対して送信するので、印刷装置2602のNFCユニットも同様に、他の装置からパケットを受信した際に、データに変換してCPUに送信するといえる。
よって、「受信動作」として、印刷装置2602のNFC通信部(NFCユニット)が、携帯型通信端末装置2601から、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信すると、当該要求を印刷装置2602のCPUへ送信する動作を行い、「送信動作」として、印刷装置2602のNFC通信部(NFCユニット)が、印刷装置2602のCPUから、自身の利用可能な通信プロトコルとしてWLAN情報、又は、WLANで通信を行うために必要な情報を取得し、携帯型通信端末装置2601に送信する動作を行うといえる。
よって、「前記受信動作は、NFCユニットが、携帯型通信端末装置から受信する情報を、CPUへ送信する動作であり」、「前記送信動作は、NFCユニットが、CPUから取得する情報を、携帯型通信端末装置に送信する動作である」といえる。

したがって、引用例には、印刷装置のCPUは、「印刷装置でエラーが発生していない状態において、ターゲットとして動作するNFCユニットを介して、携帯型通信端末装置との接続が確立されると、NFCユニットに受信動作を実行させることによって、携帯型通信端末装置から、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信し、前記受信動作は、NFCユニットが、携帯型通信端末装置から受信する情報を、CPUへ送信する動作であり」、「前記利用可能な通信プロトコルの情報の要求、又は、前記WLANで通信を行うために必要な情報についてのデータ交換要求が受信されることに応じて、NFCユニットに送信動作を実行させることによって、自身の利用可能な通信プロトコルとしてWLAN情報の応答、又は、WLANで通信を行うために必要な情報についてのデータ交換応答を、携帯型通信端末装置に送信し、前記送信動作は、NFCユニットが、CPUから取得する情報を、携帯型通信端末装置に送信する動作である」ことが記載されている。

以上を総合すると、引用例には、次の発明(以下、「引用発明」という。)が記載されていると認める。

「印刷装置であって、NFC規格に準拠した近距離無線通信を実行するためのNFCユニットと、
システム制御部であるCPUと、を備え、
前記CPUは、
前記印刷装置でエラーが発生しているエラー状態であることを判定すると、前記NFCユニットをイニシエータに遷移させ、前記NFCユニットを介して、携帯型通信端末装置との接続が確立されると、前記NFCユニットに送信動作を実行させることによって、前記携帯型通信端末装置から要求を受信しなくても、エラー状態であることを示すエラー情報を前記携帯型通信端末装置に送信し、前記送信動作は、前記NFCユニットが、前記CPUから取得する情報を、前記携帯型通信端末装置に送信する動作であり、
前記印刷装置でエラーが発生していない状態において、ターゲットとして動作する前記NFCユニットを介して、前記携帯型通信端末装置との接続が確立されると、前記NFCユニットに受信動作を実行させることによって、前記携帯型通信端末装置から、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信し、前記受信動作は、前記NFCユニットが、前記携帯型通信端末装置から受信する情報を、前記CPUへ送信する動作であり、
前記利用可能な通信プロトコルの情報の要求、又は、前記WLANで通信を行うために必要な情報についてのデータ交換要求が受信されることに応じて、前記NFCユニットに送信動作を実行させることによって、自身の利用可能な通信プロトコルとしてWLAN情報の応答、又は、WLANで通信を行うために必要な情報についてのデータ交換応答を、前記携帯型通信端末装置に送信し、前記送信動作は、前記NFCユニットが、前記CPUから取得する情報を、前記携帯型通信端末装置に送信する動作である、
印刷装置。」

イ 周知事項1、周知事項2
本願の出願日前に公知となった、NFC規格について解説した書籍である、株式会社ブリリアントサービス、NFC HACKS プロが教えるテクニック&ツール、株式会社オライリー・ジャパン、2013年11月29日(以下、「周知例1」という。)には、図面と共に以下の事項が記載されている。

(ア)「HACK#1 RFIDと非接触ICカード
NFC(Near Field Communication)は近距離無線通信技術として2003年に国際標準規格となりましたが、見方によってはそれ以前にあったRFIDや非接触標準規格の一部をなしているともいえます。そこでNFC解説の導入としてこのHackでは、歴史的に関係の深いRFIDと非接触ICカードについて解説します。
(中略)
HACK#4 NECデバイスの3つのモード
NECデバイスが備えるべきと定められている3つのモードについて解説します。
NFC Forumが設立された当初、NFCデバイスが備えるべき機能として以下の3つのモードを定めました。NFCデバイスとは、NFC Forumが定めている要件を満たしている端末のことです。

Reader/Writerモード
NFCタグを読み書きするためのモードです。

Peer-to-Peerモード
NFCデバイス同士でデータ交換するためのモードです。

Card Emulationモード
NFCデバイスを非接触ICカードのように見せかけるモードです。
(中略)
アナログ技術仕様(NFC Analog Technical Specification)
(中略)
NFCデバイスは3つのモードを実現するために、4つの役割を担わなければなりません。4つの役割とは、Peer-to-Peerモード用のイニシエータとターゲットそれぞれの役割、Reader/Writerモードとしての役割、そしてCard Emulation モードとしての役割のことです。」(11?12ページ)

(イ)「HACK#6 Peer-to-Peerモード
NFCデバイス同士でデータ交換するためのモード、Peer-to-Peerモードについて解説します。

Peer-to-Peerモードでは、2台のNFCデバイスでデータを交換することができます。このモードを使うことで、BluetoothやWi-Fiリンクの設定パラメータを共有したり、名刺や写真のデータを交換したりすることができるようになります。Peer-to-PeerモードはISO/IEC 18092の標準に準拠しています。図6-1に、Peer-to-Peerモードを構成する要素を示します。[Hack #5]同様、図の背景が色つきの部分はNFC Forum のスコープ外であることを示します。

(中略)
Simple NDEF Exchange Protocol(SNEP)
SNEP([Hack#21])を用いれば、Peer-to-Peerモードの際にNFC対応デバイス上のアプリケーションが他のNFC ForumデバイスとNDEFメッセージを交換できるようになります。このプロトコルは信頼性の高いデータ交換を提供するためにLLCPのコネクション指向転送方式を使用しています。SNEPの内容にはNDEFのやり取りという面で、Reader/WriterモードにおけるType Tagオペレーションの内容と似ている部分が多くあります。」(15?17ページ)

(ウ)「HACK#19 NFC-DEPについて学ぶ
NFC Digital Protocol 1.0のNFC-DEP仕様について解説します。
NFC-DEPはNFC ForumデバイスのPeer-to-PeerモードでNFC Forumデバイス同士の通信を実現するためのデータ伝送プロトコルです。

プロトコル概要
ISO/IEC 14443 Type AとFeliCaの通信規格を統合してISO/IEC 18092(NFCIP-1)規格が制定されました。ISO/IEC 18092をベースとして一部を簡略にして制定されたのがNFC Forum のNFC-DEPプロトコルです。ISO/IEC 18092ではActive communication modeとPassive communication modeが定義されていますが、NFC-DEPはPassive communication modeのみを採用しています。NFC-DEPの特徴は以下の通りです。
●106kbps通信はNFC-Aが、212 kbps/424kbps通信はNFC-Fが利用される
●Target Activation後からDeactivationが行われるまで、定義されたPDUを使って、上位層のデータを交換する
交換されるデータとして、NFC ForumではLLC PDUが定義されている
●機能の観点から、InitiatorとTargetの区別があり、それぞれリーダ/ライタとカードに対応する
●通信を発起するのは常にInitiatorである。Target側はInitiatorのコマンド受信後、レスポンスを返す
(中略)
NFC ForumデバイスのPeer-to-Peerモードにおいて、Initiator側及びTarget側双方の通信にNFC-DEPプロトコルが利用されます。(後略)」(89?90ページ)

(エ)「HACK#21 SNEPについて学ぶ
LLCPの上位層にあたるSNEP(Ver.1.0)について解説します。
スマートフォンには、端末同士を重ね合わせることでURL等の情報を共有できる機能を持ったものがありますが、それにはSNEPが利用されています。

概要を知る
SNEP(Simple NDEF Exchange Protocol)はその名の通りNDEFメッセージ([Hack#22])を交換するためのプロトコルです。SNEPはクライアント/サーバモデルを採り、クライアントからの要求に対してサーバが応答する流れになります。先に紹介したスマートフォンでの情報共有機能は、情報を送信するデバイスがSNEPクライアント、受信するデバイスがSNEPサーバとなり、クライアントからサーバヘNDEFメッセージを伝送することで実現しています。
(中略)
SNEPメッセージを理解する
クライアントの要求およびサーバの応答はSNEPメッセージで行われます。
(中略)
Request/Response
クライアント要求(Request)またはサーバ応答(Response)の種別を指定します。
(中略)
Request/Responseの種類には表21-1、表21-2に示すものがあります。


(中略)
処理開始のトリガーとなるSNEPリクエストはGetとPutです。GetはサーバからNDEFメッセージを取得するためのメッセージ(NDEFメッセージの返送要求)であり、PutはサーバヘNDEFメッセージを送信するためのメッセージ(NDEFメッセージの受諾要求)です。サーバは、それらクライアントからの要求を正常に受け入れることができる場合にはSuccessを、受け入れることができない場合にはNot Found など理由に応じたエラーをSNEPレスポンスとして返信します。Get要求に対するSuccess応答では、そのInformation Filed にNDEFメッセージを乗せて返信します。(後略)」(117?120ページ)

本願の出願日前に公知となった、NFC規格について解説した技術雑誌である、金本俊範、近接無線通信技術 NFCの基礎知識、Interface2012年4月号、CQ出版社、2012年4月1日、P.36?44(以下、「周知例2」という。)には、図面と共に以下の事項が記載されている。

(オ)「(1)プロトコル仕様
『Digital Protocol』には,その名の通り,ディジタル・プロトコルの基本事項(Coding/Frame Format/Command/Protocol)が記載されています。(中略)また,受動通信モードにおいて,コマンドを送信できる状態をPollモード,コマンドを受信できる状態をListenモードと呼んでいます。(中略)
・Pollモード
テクノロジ検出アクティビティは,Pollingコマンドを用いて対向デバイスを検知するためのものです。(中略)
デバイス活性化アクティビティは,対向デバイスを活性化させるための処理であり,この処理の中で得られる情報によって,対向デバイスがどのTypeのタグに対応しているか,あるいは,P2Pに対応しているかどうかを判別することができます。P2Pを実現する場合は,ATR_REQ,PSL_REQを用いた属性情報の交換に進みます。
データ交換アクティビティにおいて,P2Pの場合はDEP_REQとDEP_RESを使ったデータ送受信を行い,デバイス非活性化アクティビティではDSL_REQとRLS_REQを使った通信後の非活性化処理を実行します。
・Listenモード
Listenモードの場合はIDLE状態からスタートし,対向デバイスがデバイス活性化アクティビティで送信するコマンドによって,P2Pまたはカード・エミュレーションの状態に遷移し,それぞれの処理を行います。

」(41?42ページ)

NFC規格について解説した書籍である周知例1の上記(ア)、(ウ)、及び、NFC規格について解説した技術雑誌である周知例2の上記(オ)の図10に記載されているように、
「NFCデバイスは、Reader/Writerモード、Peer-to-Peerモード、Card Emulationモードの3つのモードを備え、イニシエータとターゲットはPeer-to-Peerモードで用いられる機能である。」ことは、技術常識ともいえる周知事項(以下、「周知事項1」という。)である。

また、NFC規格について解説した書籍である周知例1の上記(イ)、(エ)に記載されているように、
「NFCのPeer-to-Peerモードにおいて、上位レイヤプロトコルにSNEP(Simple NDEF Exchange Protocol)を用いることができる。」ことは、技術常識ともいえる周知事項(以下、「周知事項2」という。)である。

(3)対比
ア 本願補正発明と引用発明を対比する。
(ア)引用発明の「印刷装置」は近距離無線通信を実行するので、「通信装置」といえる。
引用発明の「NFC規格に準拠した近距離無線通信を実行するためのNFCユニット」は、本願補正発明の「NFC(Near Field Communicationの略)規格に従った通信方式であるNFC方式の無線通信を実行するための第1のインターフェース」に相当する。
引用発明の「システム制御部であるCPU」は、本願補正発明の「制御部」に相当する。
よって、引用発明の「印刷装置であって、NFC規格に準拠した近距離無線通信を実行するためのNFCユニットと、システム制御部であるCPUと、を備え」ることは、本願補正発明の「通信装置であって、NFC(Near Field Communicationの略)規格に従った通信方式であるNFC方式の無線通信を実行するための第1のインターフェースと、制御部と、を備え」ることに相当する。

(イ)引用発明のCPUが、「前記印刷装置でエラーが発生しているエラー状態であることを判定する」という状況は、印刷装置の状態が、印刷装置でエラーが発生しているエラー状態であるといえるから、本願補正発明の「通信装置の状態が、通信装置でエラーが発生しているエラー状態である状況」に相当する。
引用発明の「携帯型通信端末装置」は、本願補正発明の「携帯端末」に相当する。
引用発明において、NFCユニットをイニシエータに遷移させ、前記NFCユニットを介して、携帯型通信端末装置との「接続が確立」されることを、「第1の接続が確立」されると称することは任意である。
よって、引用発明の「前記NFCユニットをイニシエータに遷移させ、前記NFCユニットを介して、携帯型通信端末装置との接続が確立されると」は、本願補正発明と、「前記第1のインタフェースを介した第1の接続が携帯端末と確立される場合」の点で一致する。

引用発明の「送信動作」を「第2の動作」と称することは任意である。
引用発明の「エラー状態であることを示すエラー情報」は、「エラー状態に関係する関係情報」といえる。
引用発明のCPUは、NFCユニットに送信動作を実行させることによって、エラー状態であることを示すエラー情報を携帯型通信端末装置に送信するから、送信するための「送信制御部」を備えるといえ、当該「送信制御部」を「第1の送信制御部」と称することは任意である。そして、当該送信が、「前記第1の接続を利用して」行われることは明らかである。
よって、引用発明の「CPU」が、「前記NFCユニットに送信動作を実行させることによって、前記携帯型通信端末装置から要求を受信しなくても、エラー状態であることを示すエラー情報を前記携帯型通信端末装置に送信」することから、引用発明と本願補正発明とは、「制御部」が、「前記第1のインターフェースに第2の動作を実行させることによって、前記第1の接続を利用して、前記携帯端末から要求を受信しなくても、前記エラー状態に関係する関係情報を前記携帯端末に送信する第1の送信制御部」を備える点で一致する。

引用発明の「前記送信動作は、前記NFCユニットが、前記CPUから取得する情報を、前記携帯型通信端末装置に送信する動作であ」ることは、本願補正発明と、「前記第2の動作は、前記第1のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作であ」る点で一致する。

したがって、引用発明のCPUが「前記印刷装置でエラーが発生しているエラー状態であることを判定すると、前記NFCユニットをイニシエータに遷移させ、前記NFCユニットを介して、携帯型通信端末装置との接続が確立されると、前記NFCユニットに送信動作を実行させることによって、前記携帯型通信端末装置から要求を受信しなくても、エラー状態であることを示すエラー情報を前記携帯型通信端末装置に送信し、前記送信動作は、前記NFCユニットが、前記CPUから取得する情報を、前記携帯型通信端末装置に送信する動作であ」ることと、本願補正発明は、制御部が、「前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第1のインターフェースを介した第1の接続が携帯端末と確立される場合に、前記第1のインターフェースに第2の動作を実行させることによって、前記第1の接続を利用して、前記携帯端末から要求を受信しなくても、前記エラー状態に関係する関係情報を前記携帯端末に送信する第1の送信制御部であって、前記第2の動作は、前記第1のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作である、前記第1の送信制御部」を備える点で一致する。

(ウ)引用発明の「印刷装置でエラーが発生していない状態」は、本願補正発明の「通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況」に相当する。
引用発明において、ターゲットとして動作するNFCユニットを介して、携帯型通信端末装置との「接続が確立」されることを、イニシエータに遷移して動作する際の第1の接続に対して、「第2の接続が確立」されると称することは任意である。
よって、引用発明の「前記印刷装置でエラーが発生していない状態において、ターゲットとして動作する前記NFCユニットを介して、前記携帯型通信端末装置との接続が確立されると」は、本願補正発明と、「前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第1のインターフェースを介した第2の接続が前記携帯端末と確立される場合」である点で一致する。

引用発明の「受信動作」を、第2の動作である送信動作に対して、「第1の動作」と称することは任意である。
引用発明の「利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求」は、本願補正発明の「特定要求」に含まれる。
そして、引用発明のCPUは、NFCユニットに受信動作を実行させることによって、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信するから、受信するための「受信制御部」を備えるといえる。そして、当該受信が、「前記第2の接続を利用して」行われることは明らかである。
よって、引用発明の「CPU」が、「前記NFCユニットに受信動作を実行させることによって、前記携帯型通信端末装置から、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信」することから、引用発明と本願補正発明とは、「制御部」が、「前記第1のインターフェースに第1の動作を実行させることによって、前記第2の接続を利用して、前記携帯端末から特定要求を受信する受信制御部」を備える点で一致する。

そして、引用発明の「前記受信動作は、前記NFCユニットが、前記携帯型通信端末装置から受信する情報を、前記CPUへ送信する動作であ」ることは、本願補正発明と、「前記第1の動作は、前記第1のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作であ」る点で一致する。

したがって、引用発明のCPUが「前記印刷装置でエラーが発生していない状態において、ターゲットとして動作する前記NFCユニットを介して、前記携帯型通信端末装置との接続が確立されると、前記NFCユニットに受信動作を実行させることによって、前記携帯型通信端末装置から、利用可能な通信プロトコルの情報の要求、又は、WLANで通信を行うために必要な情報についてのデータ交換要求を受信し、前記受信動作は、前記NFCユニットが、前記携帯型通信端末装置から受信する情報を、前記CPUへ送信する動作であ」ることと、本願補正発明は、制御部が、「前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第1のインターフェースを介した第2の接続が前記携帯端末と確立される場合に、前記第1のインターフェースに第1の動作を実行させることによって、前記第2の接続を利用して、前記携帯端末から特定要求を受信する受信制御部であって、前記第1の動作は、前記第1のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作である、前記受信制御部」を備える点で一致する。

(エ)上記(イ)のとおり、引用発明の「送信動作」を「第2の動作」と称することは任意である。
引用発明の「自身の利用可能な通信プロトコルとしてWLAN情報の応答、又は、WLANで通信を行うために必要な情報についてのデータ交換応答」は、エラー情報とは異なるから、本願補正発明のエラー状態に関係する「前記関係情報とは異なる特定情報」に含まれる。
引用発明のCPUは、NFCユニットに送信動作を実行させることによって、自身の利用可能な通信プロトコルとしてWLAN情報の応答、又は、WLANで通信を行うために必要な情報についてのデータ交換応答を送信するから、「送信制御部」を備えるといえ、当該「送信制御部」を「第2の送信制御部」と称することは任意である。そして、当該送信が、「上記第2の接続を利用して」行われることは明らかである。
したがって、引用発明のCPUが、「前記利用可能な通信プロトコルの情報の要求、又は、前記WLANで通信を行うために必要な情報についてのデータ交換要求が受信されることに応じて、前記NFCユニットに前記送信動作を実行させることによって、自身の利用可能な通信プロトコルとしてWLAN情報の応答、又は、WLANで通信を行うために必要な情報についてのデータ交換応答を、前記携帯型通信端末装置へ送信し、前記送信動作は、前記NFCユニットが、前記CPUから取得する情報を、前記携帯型通信端末装置に送信する動作である」ことと、本願補正発明は、制御部が、「記特定要求が受信されることに応じて、前記第1のインターフェースに前記第2の動作を実行させることによって、前記第2の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第2の送信制御部」を備える点で一致する。

イ 以上のことから、本願補正発明と引用発明との一致点及び相違点は、次のとおりである。
(一致点)
「通信装置であって、
NFC(Near Field Communicationの略)規格に従った通信方式であるNFC方式の無線通信を実行するための第1のインターフェースと、
制御部と、を備え、
前記制御部は、
前記通信装置の状態が、前記通信装置でエラーが発生しているエラー状態である状況において、前記第1のインターフェースを介した第1の接続が携帯端末と確立される場合に、前記第1のインターフェースに第2の動作を実行させることによって、前記第1の接続を利用して、前記携帯端末から要求を受信しなくても、前記エラー状態に関係する関係情報を前記携帯端末に送信する第1の送信制御部であって、前記第2の動作は、前記第1のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作である、前記第1の送信制御部と、
前記通信装置の状態が、前記通信装置でエラーが発生していない非エラー状態である状況において、前記第1のインターフェースを介した第2の接続が前記携帯端末と確立される場合に、前記第1のインターフェースに第1の動作を実行させることによって、前記第2の接続を利用して、前記携帯端末から特定要求を受信する受信制御部であって、前記第1の動作は、前記第1のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作である、前記受信制御部と、
前記特定要求が受信されることに応じて、前記第1のインターフェースに前記第2の動作を実行させることによって、前記第2の接続を利用して、前記関係情報とは異なる特定情報を前記携帯端末に送信する第2の送信制御部と、
を備える通信装置。」

(相違点1)
一致点の「第1のインタフェース」が、本願補正発明では、「NFC規格のP2P(Peer to Peerの略)モードに従って動作して」いるのに対して、引用発明では、イニシエータ又はターゲットとして動作している点。

(相違点2)
一致点の「第2の動作」及び「第1の動作」が、本願補正発明では「前記NFC規格のSNEP(Simple NDEF (NFC Data Exchange Formatの略) Exchange Protocolの略)で定められているクライアントの動作」及び「前記NFC規格の前記SNEPで定められているサーバの動作」であるのに対して、引用発明では「第2の動作」として送信動作を行い、「第1の動作」として受信動作を行っているが、当該発明特定事項が特定されていない点。

(4)判断
以下、相違点について検討する。
(相違点1について)
上記「イ 周知事項1、周知事項2」のとおり、「NFCデバイスは、Reader/Writerモード、Peer-to-Peerモード、Card Emulationモードの3つのモードを備え、イニシエータとターゲットはPeer-to-Peerモードで用いられる機能である。」ことは、当業者にとって技術常識ともいえる周知事項(周知事項1)である。
そうすると、引用発明のNFCユニットは、イニシエータ又はターゲットとして動作するのであるから、NFC規格のP2P(Peer to Peerの略)モードに従って動作していることは明らかである。
したがって、相違点1は、実質的に相違点ではない。
仮に、引用発明のNFCユニットがイニシエータ又はターゲットとして動作することが、NFC規格のP2Pモードであることまで特定していないとしても、NFC規格に準拠した近距離無線通信を実行する引用発明のイニシエータとターゲットとの間の通信に、NFC規格のP2Pモードを採用することに格別困難な点はなく、当業者であれば適宜成し得た事項である。

(相違点2について)
上記「イ 周知事項1、周知事項2」のとおり、「NFCのPeer-to-Peerモードにおいて、上位レイヤプロトコルにSNEP(Simple NDEF Exchange Protocol)を用いることができる。」ことは、当業者にとって技術常識ともいえる周知事項(周知事項2)である。
ここで、本願明細書の段落0029には、「SNEPのサーバ動作は、NFCI/F22が、外部機器(例えば携帯端末50)から受信する情報を、制御部30(即ちCPU32)に供給する動作である。SNEPのクライアント動作は、NFCI/F22が、制御部30(即ちCPU32)から取得する情報を、外部機器(例えば携帯端末50)に送信する動作である。」と定義されている。
したがって、引用発明のP2Pモードに従って動作しているといえるイニシエータとターゲットとの通信の上位レイヤプロトコルとして、SNEPを採用することに格別困難な点はなく、SNEPを採用する際に、引用発明の「前記NFCユニットが、前記CPUから取得する情報を、前記携帯型通信端末装置に送信する動作」である「送信動作」について、SNEPのクライアント動作と定義し、引用発明の「前記NFCユニットが、前記携帯型通信端末装置から受信する情報を、前記CPUに供給する動作」である「受信動作」について、SNEPのサーバ動作と定義してみることは、当業者であれば適宜成し得た事項である。

そして、これらの相違点を総合的に勘案しても、本願補正発明の奏する作用効果は、引用発明及び周知事項に記載された技術の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。

したがって、本願補正発明は、引用発明及び周知事項に記載された技術に基づいて、当業者が容易に発明をすることができたものであり、特許法29条2項の規定により、特許出願の際独立して特許を受けることができないものである。

3 本件補正についてのむすび
よって、本件補正は、特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するものであるから、同法第159条第1項で読み替えて準用する同法第53条第1項の規定により却下されるべきものである。
よって、上記補正の却下の決定の結論のとおり決定する。

第3 本願発明について
1 本願発明
本件補正は、上記のとおり却下されたので、本願の請求項1?7に係る発明は、平成29年5月17日にされた手続補正により補正された特許請求の範囲の請求項1?7に記載された事項により特定されるところ、その請求項1に係る発明は、上記「第2 平成30年2月27日にされた手続補正についての補正の却下の決定」の[理由]「1 本件補正について」の「(2)本件補正前の特許請求の範囲の記載」で示した本願発明のとおりのものと認める。

2 原査定の拒絶の理由の概要
原査定の拒絶の理由の概要は、
(新規性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明であるから、特許法第29条第1項第3号に該当し、特許を受けることができない、
(進歩性)この出願の下記の請求項に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない、
というものであり、本件補正前の請求項1に対して、引用例(特開2013-187567号公報)が引用されている。

3 引用発明
引用発明は、上記「第2 平成30年2月27日にされた手続補正についての補正の却下の決定」の[理由]「2 補正の適否」の「(2)引用発明、周知事項」の「ア 引用発明」のとおりである。

4 対比・判断
本願発明は、上記「第2 平成30年2月27日にされた手続補正についての補正の却下の決定」の[理由]「2 補正の適否」で検討した上記本願補正発明から、「前記第1のインターフェースが前記NFC規格のP2P(Peer to Peerの略)モードに従って動作しており」「前記第1のインターフェースに第2の動作を実行させることによって」「前記第2の動作は、前記第1のインターフェースが、前記制御部から取得する情報を、前記携帯端末に送信する動作であって、前記NFC規格のSNEP(Simple NDEF (NFC Data Exchange Formatの略) Exchange Protocolの略)で定められているクライアントの動作である」、「前記第1のインターフェースが前記NFC規格のP2Pモードに従って動作しており」「前記第1のインターフェースに第1の動作を実行させることによって」「前記第1の動作は、前記第1のインターフェースが、前記携帯端末から受信する情報を、前記制御部に供給する動作であって、前記NFC規格の前記SNEPで定められているサーバの動作である」及び「前記第1のインターフェースに前記第2の動作を実行させることによって」に係る限定事項を削除するものである。
そうすると、本願発明と引用発明とに相違はなく、本願発明は、引用発明と同一であり、また、引用発明に基づいて、当業者が容易に発明をすることができたものである。

第4 むすび
以上のとおり、本願発明は、特許法第29条第1項第3号及び特許法第29条第2項の規定により特許を受けることができないから、他の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。

よって、結論のとおり審決する。
 
審理終結日 2019-03-18 
結審通知日 2019-03-19 
審決日 2019-04-03 
出願番号 特願2013-271480(P2013-271480)
審決分類 P 1 8・ 121- Z (H04W)
P 1 8・ 113- Z (H04W)
P 1 8・ 575- Z (H04W)
最終処分 不成立  
前審関与審査官 倉本 敦史廣川 浩  
特許庁審判長 中木 努
特許庁審判官 本郷 彰
羽岡 さやか
発明の名称 通信装置  
代理人 特許業務法人快友国際特許事務所  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ