• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1393853
総通号数 14 
発行国 JP 
公報種別 特許審決公報 
発行日 2023-02-24 
種別 拒絶査定不服の審決 
審判請求日 2022-04-04 
確定日 2023-01-24 
事件の表示 特願2020−146121「通信機器」拒絶査定不服審判事件〔令和 3年 3月11日出願公開、特開2021− 40310、請求項の数(10)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯
本願は、令和2年8月31日(優先権主張令和元年8月29日)の出願であって、令和2年11月10日付けで拒絶理由が通知され、令和3年1月18日に意見書が提出されるとともに手続補正がされ、令和3年6月8日付けで拒絶理由が通知され、令和3年8月6日に意見書が提出されるとともに手続補正がされ、令和3年12月20日付けで拒絶査定がされ、これに対して令和4年4月4日に拒絶査定不服審判の請求がされ、その後、令和4年9月7日付けで当審より拒絶理由が通知され(以下、「当審拒絶理由」という。)、令和4年11月14日に意見書が提出されるとともに手続補正がなされたものである。

第2 原査定の概要
原査定(令和3年12月20日付け拒絶査定)の概要は次のとおりである。

理由1(進歩性) 本願請求項1−10に係る発明は、以下の引用文献A−Fに基づいて、その発明の属する技術の分野における通常の知識を有する者(以下、「当業者」という。)が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
A.特開2017−69661号公報
B.特開2007−13675号公報
C.特開2004−343701号公報
D.特開2012−216104号公報
E.特開2015−162139号公報
F.特開2007−327656号公報

第3 当審拒絶理由の概要
理由1(サポート要件) この出願は、特許請求の範囲の請求項6−10の記載が、特許法第36条第6項第1号に規定する要件を満たしていない。
(1) 請求項6の「空きドライバ(228)の数に基づいて、前記データ送信要求を決定する」との構成は、発明の詳細な説明において発明の課題を解決できることを当業者が認識できるように記載された範囲を超えるものである。
請求項7−10についても同様である。
(2) 請求項10の「送信バッファ(23)の空きサイズに応じて、前記送信端末(10)への前記データ送信要求を決定する」との構成は、発明の詳細な説明において発明の課題を解決できることを当業者が認識できるように記載された範囲を超えるものである。

理由2(進歩性) 本願請求項1−5に係る発明は、以下の引用文献1−4に基づいて、本願請求項6−10に係る発明は、以下の引用文献1−5に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

1.特開2000−216819号公報(当審において新たに引用した文献)
2.国際公開第2004/077741号(当審において新たに引用した文献)
3.特開2006−114973号公報(当審において新たに引用した文献)
4.特開2009−141565号公報(当審において新たに引用した文献)
5.特開2017−69661号公報(拒絶査定時の引用文献A)

第4 本願発明
本願請求項1−10に係る発明(以下、それぞれ「本願発明1」−「本願発明10」という。)は、令和4年11月14日付けの手続補正で補正された特許請求の範囲の請求項1−10に記載された事項により特定される発明であって、本願発明1−3は以下のとおりの発明である。

「【請求項1】
コネクションレス型プロトコルを利用して、空調に関するデータを送信する装置である送信端末(10)から送信されたデータを受信する通信機器(20)であって、
自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、
前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整する、
通信機器(20)。
【請求項2】
コネクションレス型プロトコルを利用して、空調に関するデータを送信する装置である送信端末(10)から送信されたデータを受信する通信機器(20)であって、
自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、
前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整し、
前記データ送信要求の決定は、前記データの項目の決定、及び/又は、前記送信端末(10)への前記データ送信要求の間隔の決定を含む、
通信機器(20)。
【請求項3】
コネクションレス型プロトコルを利用して、空調に関するデータを送信する装置である送信端末(10)から送信されたデータを受信する通信機器(20)であって、
自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、
前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整し、
前記通信機器(20)は、さらに、
少なくとも前記データを受信する処理を実行する複数のドライバ(228)を保持し、
前記複数のドライバ(228)のうち、前記データを受信する処理を実行していない空きドライバ(228)の数に基づいて、前記データ送信要求を決定する、
通信機器(20)。」

なお、本願発明4−10は、本願発明1−3のいずれかを減縮した発明である。

第5 引用文献、引用発明等
1 引用文献1及び引用発明
(1) 引用文献1
当審拒絶理由に引用した引用文献1には、図面とともに、以下の記載がある(下線は、特に着目した箇所を示す。以下同様。)。

ア 段落【0002】−【0005】
「【従来の技術】今日、ネットワークの普及に伴って、1つのネットワーク上に、様々なアプリケーションプログラムにおける通信データが同時に流れるようになっている。そのため、アプリケーションごとに適した保証帯域を持たせることが要求される。この要求に対応するため、ルータや専用装置を用いて、ネットワーク帯域の制御を行っている。
【0003】インターネットの普及によって普及したTCP/IPプロトコルには、OSI(開放型システム間相互接続:Open System Interconection)のトランスポート層に対応する部分として、コネクション型の通信サービスを提供するTCP(Transmission Control Protocol)とコネクションレス型の通信サービスを提供するUDP(UserDatagram Protocol)とがあり、アプリケーションによってどちらかのプロトコルが選択されて使用されている。TCPを使用するアプリケーションとしては、FTP、TELNET、SMTP等があり、UDPを使用するアプリケーションとしては、TFTP、SNMP、NTP等がある。また、現在増えている不特定端末に対して送信を行うマルチキャストを使ったアプリケーションでは、主にUDPを使用する。
【0004】図10にTCPのフォーマットを、図11にTCPを用いた場合の通信処理の流れを示す。図11に示す様に、TCPは、送信側が受信側からの到達応答(ACK)を受け取って、次に送信すべきパケットを送信する。既存する帯域制御装置には、この仕組みを利用し、単なるバッファリングではなく、ACKパケットを操作することによって効率よくトラフィック量を制御しているものがある。
【0005】図12に、UDPのフォーマットを示す。UDPでは到達確認を行わないため、到達確認が必要な場合はアプリケーションにて行っている。したがって、アプリケーションごとに到達確認の方法が異なることとなるため、既存する帯域制御装置では、UDPの場合、バッファリングのみで帯域制御を行っている。」

イ 【図11】




ウ 段落【0015】−【0020】
「【0015】
【発明の実施の形態】以下、本発明の実施の形態について図面を参照して詳細に説明する。
【0016】図1は、本発明の位置実施形態による帯域制御装置の構成を示すブロック図、図2は本実施形態の帯域制御装置を含むネットワーク構成を示す概略図である。図1を参照すると、本実施形態の帯域制御装置10は、ネットワーク上の他の装置との間で通信フレームの送受信を行なうために用いる送信バッファ11及び受信バッファ12と、ネットワーク上のUDPトラフィックの送信レートを解析すると共に必要に応じてソース抑制メッセージを生成するフレーム生成解析部13と、ソース抑制メッセージの送出タイミングを制御するためのフレーム送出タイミング制御部14及びタイマー15と、帯域状態を管理する帯域状態テーブル16と、帯域制御装置10のUDPトラフィックの帯域設定を行う帯域設定保存部17とを備える。なお、図1には本実施形態における特徴的な構成のみを記載し、他の一般的な構成については記載を省略してある。
【0017】 上記各構成要素は、例えばパーソナルコンピュータやワークステーションその他のコンピュータシステムにおけるプログラム制御されたCPUとRAMその他の内部メモリとで実現される。CPUを制御するコンピュータプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の一般的な記憶媒体に格納して提供される。そして、帯域制御装置10を構成するコンピュータシステムの内部メモリにロードされてCPUを制御し、各構成要素の機能を実行する。
【0018】フレーム生成解析部13は、ネットワーク上のUDPトラフィックの送信レートを解析すると共に、必要に応じて、受信バッファ12を介して入力されるネットワーク上の通信における送信バッファ11及び受信バッファ12に対するバッファ使用率を計算する。そして、帯域テーブル16を参照し、必要があれば、所定の装置の送信レートを落とすためにソース抑制メッセージを生成して出力する。図8に、IETF(Internet Engineering TaskForce)のRFC792で規定されたソース抑制メッセージ(SourceQuench Message)のフォーマットを示す。
【0019】フレーム送出タイミング制御部14は、タイマー15を用いてバッファ使用率検出間隔を計時する。そして、当該バッファ使用率検出タイミングに基づいて、フレーム生成解析部13におけるソース抑制メッセージの送出タイミングを制御する。
【0020】帯域状態テーブル16は、帯域制御装置10のバッファ11、12の総容量を格納すると共に、予め設定されたバッファ漏れ危険使用率を格納する。バッファ漏れ危険使用率とは、帯域制御装置10のバッファ11、12の総容量に対する所定のUDPトラフィックにおける帯域制御装置10のバッファ11、12の使用量の割合であって、これ以上バッファ11、12の使用量が増加すればバッファ漏れを発生するおそれがあるとして設定された値である。バッファ漏れ危険使用率をどの程度の値とするかは、ネットワークやアプリケーションの種類、実際の使用状況等に応じて、ユーザが任意に定めることができる。」

エ 【図1】




オ 段落【0028】−【0030】
「【0028】一方、バッファ使用率がバッファ漏れ危険使用率以上である場合、すなわち【0029】
【数3】

である場合は、フレーム生成解析部13は、フレーム送出タイミング制御部14の制御にしたがって、ソース抑制メッセージを生成して送信側の装置に対して送信する(ステップ304)。ソース抑制メッセージには、送信側から送られたオリジナルパケットのIPヘッダ及びUDPヘッダ部分が含まれているので、レートを落とすべき装置やUDPポート番号等を特定することが可能である。
【0030】ソース抑制メッセージを受け取った送信側装置は、図6に示すように、送信レートを落とす。これにより、パケット使用量が低下するため、パケット使用率が減少する。」

カ 【図6】




(2) 引用発明
したがって、上記引用文献1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。

「帯域制御装置10は、
ネットワーク上の他の装置との間で通信フレームの送受信を行なうために用いる送信バッファ11及び受信バッファ12と、ネットワーク上のUDPトラフィックの送信レートを解析すると共に必要に応じてソース抑制メッセージを生成するフレーム生成解析部13と、ソース抑制メッセージの送出タイミングを制御するためのフレーム送出タイミング制御部14及びタイマー15と、帯域状態を管理する帯域状態テーブル16と、帯域制御装置10のUDPトラフィックの帯域設定を行う帯域設定保存部17とを備え、
フレーム生成解析部13は、ネットワーク上のUDPトラフィックの送信レートを解析すると共に、必要に応じて、受信バッファ12を介して入力されるネットワーク上の通信における送信バッファ11及び受信バッファ12に対するバッファ使用率を計算し、そして、帯域テーブル16を参照し、必要があれば、所定の装置の送信レートを落とすためにソース抑制メッセージを生成して出力し、
フレーム送出タイミング制御部14は、タイマー15を用いてバッファ使用率検出間隔を計時し、そして、当該バッファ使用率検出タイミングに基づいて、フレーム生成解析部13におけるソース抑制メッセージの送出タイミングを制御し、
帯域状態テーブル16は、帯域制御装置10のバッファ11、12の総容量を格納すると共に、予め設定されたバッファ漏れ危険使用率を格納し、バッファ漏れ危険使用率とは、帯域制御装置10のバッファ11、12の総容量に対する所定のUDPトラフィックにおける帯域制御装置10のバッファ11、12の使用量の割合であって、これ以上バッファ11、12の使用量が増加すればバッファ漏れを発生するおそれがあるとして設定された値であり、
バッファ使用率がバッファ漏れ危険使用率以上である場合、フレーム生成解析部13は、フレーム送出タイミング制御部14の制御にしたがって、ソース抑制メッセージを生成して送信側の装置に対して送信し(ステップ304)、
ソース抑制メッセージを受け取った送信側装置は、送信レートを落とし、これにより、パケット使用量が低下するため、パケット使用率が減少する、
帯域制御装置10。」

2 引用文献2について
当審拒絶理由に引用した引用文献2には、以下の記載がある。

(1) 6ページ13−14行
「バッファ23は、例えばメモリで構成され、情報伝達に関するデータや手順などの情報を格納する。」

(2) 7ページ19−21行
「電気機器3は、例えば、エアコン、冷蔵庫、洗濯機、電子レンジ、炊飯器、掃除機、調理機器、ガス給湯器、セントラルヒーティングシステム、電気温水器、家庭用コジェネ装置等、いろいろな種類の機器で構成される。」

(3) 8ページ19−23行
「なお、本実施形態では、コネクションレス型プロトコルとして、UDPプロトコルを用い、コネクション型プロトコルとして、TCPプロトコルを用いているが、本発明は特にこれに限定されず、UDPプロトコル以外の他のコネクションレス型プロトコルを用いてもよく、TCPプロトコル以外の他のコネクション型プロトコルを用いてもよい。」

(4) 11ページ13行−12ページ1行
「ここで、定期UDPは、必ずしも一定間隔で送出され続けるのではなくほぼ一定の間隔で送出され続ければよいものである。また、UDPプロトコルに基づく信号は、信号伝達時にACK信号を返送しないため、TCPプロトコルに基づく信号に比べて信頼性が低くなる。そこで、サーバ2の送受信部21は、定期UDP61,63,71を受信すると、確認UDP62,64,72を情報盤1の第1送受信部11に送信する。このように、定期UDP61,63,71に対して確認UDP62,64,72がサーバ2から情報盤1に対して送出されるので、情報伝達の信頼性を高めることができる。また同様に、要求応答UDP66に対しては確認UDP67を送出することによって、上記問題を解決することができ、情報伝達の信頼性を高めることができる。
また、情報盤1は表示部13や操作部14を備えることにより、情報盤1で電気機器3の状態や、サーバ2との通信状態の確認などの情報を確認することができ、情報送出の内容を設定できるなどの極めて大きな効果が創出できる。
なお、電気機器3は情報盤1と通信により制御を行うのではなく情報盤1の端子等に直接接続していて制御できるとしても良いのは言うまでもない。また、要求応答UDP66はTCPプロトコルの信号でも良い。この場合、要求応答UDP66に対する確認UDP67が不要となり、TCPプロトコルに基づく信号により、確実に要求応答情報を送信することができる。」

3 引用文献3について
当審拒絶理由に引用した引用文献3には、以下の記載がある。

(1) 段落【0038】
「【0038】
更に、具体的に説明すると、図5に示すように、まず、ドライバ部204からの出力データをTCP検出部202でOSI参照モデルレイヤ4(TCP/UDP)ヘッダか判別し、TCPデータか否かを検出する。TCPデータを検出した場合には、TCP ACK生成部203にてTCPデータのACKを生成し(図5の(3)TCPデータのACK生成)、TCP検出部202は無線I/F201へTCPデータを送信する(図5の(2)TCPデータ)。無線I/F201は無線ネットワークを介して無線基地局100へTCPデータを送信する(図5の(4)無線TCPデータ)。」

(2) 段落【0050】
「【0050】
更に、詳しく説明すると、TCP ACK生成部103はRFC793に定められたTCPプロトコルのフロー制御において受信側のバッファ量に応じて変動するウィンドウサイズというパラメータを変更する手段を有する(ウィンドウサイズのパラメータの変更はTCP/IPの標準動作である)。」

(3) 段落【0053】
「【0053】
また、TCPバッファ部105の空きバッファ量が予め定めたバッファ量より少なくなった場合には、TCP ACK生成部103から送信するACKのタイミングをタイマー109で遅延させ、次のTCPデータが送信元から送信されるTCPデータを制限する。以上により、無線ネットワークの混雑に合わせた効率的な送信を行うことができる。」

4 引用文献4について
当審拒絶理由に引用した引用文献4には、以下の記載がある。

(1) 段落【0017】
「【0017】
本発明によれば、複数の接続先に通知するACKの各送信先に向けて返信する送信間隔を拡げることにより、送信端末装置ではその返信されたACKを受信したタイミングを基にパケットの送信を行うため、ネットワーク負荷分散を考慮でき、輻輳を回避できることからネットワーク上でのパケット損失を防ぎ、ネットワークの利用効率の向上が図れる。」

(2) 段落【0062】
「【0062】
また、TCPを用いて説明した各実施の形態は例示であって、本発明の範囲を限定するものでは無く、その他フロー制御を行う同様のプロトコルにおいても適用可能である。」

5 引用文献5について
当審拒絶理由に引用した引用文献5(原査定の引用文献A)には、段落【0031】に、以下の記載がある。

「【0031】第1の方法における収集サーバ10は、複数のAP12からアソシエーションデータを収集するためのプロセスを、並列に実行する。状況によっては、1つの収集サーバ10は、一周期内に数十万のAPからアソシエーションデータを収集することがある。このような場合に、AP12からUser Datagram Protocol(UDP)で送信される大量の情報を受信すると、収集サーバ10のバッファがオーバーフローする可能性がある。このため、収集サーバ10が一時期に収集する情報量がプロセス数で制限され、一周期の時間内に、複数個のプロセスのそれぞれが所定数(例えば数個)のAPをポーリングし、アソシエーションデータを収集する。」

第6 対比・判断
1 本願発明1について
(1) 対比
本願発明1と、引用発明とを対比すると、以下のことがいえる。

ア 引用発明の「UDP」とは、「コネクションレス型の通信サービスを提供するUDP(UserDatagram Protocol)」(引用文献1の「従来の技術」欄の段落【0003】を参照。)であるから、本願発明1の「コネクションレス型プロトコル」に相当する。
引用発明の「ネットワーク上の他の装置」は、本願発明1の「空調に関するデータを送信する装置である送信端末(10)」と、「データを送信する装置である送信端末(10)」である点で共通するといえる。
よって、引用発明の「ネットワーク上の他の装置との間で通信フレームの送受信を行なう」装置であって、「UDPトラフィック」を受信している「帯域制御装置10」は、本願発明1の「コネクションレス型プロトコルを利用して、空調に関するデータを送信する装置である送信端末(10)から送信されたデータを受信する通信機器(20)」と、「コネクションレス型プロトコルを利用して、データを送信する装置である送信端末(10)から送信されたデータを受信する通信機器(20)」である点で共通するといえる。

イ 引用発明の「ソース抑制メッセージ」は、本願発明1の「前記送信端末(10)から前記データを受信するためのデータ送信要求」と、「制御信号」である点で共通するといえる。
よって、引用発明の「フレーム生成解析部13は、ネットワーク上のUDPトラフィックの送信レートを解析すると共に、必要に応じて、受信バッファ12を介して入力されるネットワーク上の通信における送信バッファ11及び受信バッファ12に対するバッファ使用率を計算し、そして、帯域テーブル16を参照し、必要があれば、所定の装置の送信レートを落とすためにソース抑制メッセージを生成して出力し、
フレーム送出タイミング制御部14は、タイマー15を用いてバッファ使用率検出間隔を計時し、そして、当該バッファ使用率検出タイミングに基づいて、フレーム生成解析部13におけるソース抑制メッセージの送出タイミングを制御し、
帯域状態テーブル16は、帯域制御装置10のバッファ11、12の総容量を格納すると共に、予め設定されたバッファ漏れ危険使用率を格納し、バッファ漏れ危険使用率とは、帯域制御装置10のバッファ11、12の総容量に対する所定のUDPトラフィックにおける帯域制御装置10のバッファ11、12の使用量の割合であって、これ以上バッファ11、12の使用量が増加すればバッファ漏れを発生するおそれがあるとして設定された値であり、
バッファ使用率がバッファ漏れ危険使用率以上である場合、フレーム生成解析部13は、フレーム送出タイミング制御部14の制御にしたがって、ソース抑制メッセージを生成して送信側の装置に対して送信し(ステップ304)、
ソース抑制メッセージを受け取った送信側装置は、送信レートを落とし、これにより、パケット使用量が低下するため、パケット使用率が減少する」ことは、本願発明1の「自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し」ていることと、「自身の受信可能サイズに応じて、制御信号を決定し」ている点で共通するといえる。

ウ よって、本願発明1と引用発明との一致点・相違点は次のとおりであるといえる。

[一致点]
「コネクションレス型プロトコルを利用して、データを送信する装置である送信端末(10)から送信されたデータを受信する通信機器(20)であって、
自身の受信可能サイズに応じて、制御信号を決定する、
通信機器(20)。」

[相違点1]
本願発明1では、「空調に関する」データを送信するのに対して、引用発明では、送信されるデータが特定されていない点。

[相違点2]
本願発明1では、「コネクションレス型プロトコルを利用」する通信機器が、「自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整する」のに対して、引用発明では、コネクションレス型プロトコルである「UDP」プロトコルを利用する帯域制御装置(10)が、「ソース抑制メッセージ」を用いて「送信レート」を制御するものであって、「前記送信端末(10)から前記データを受信するためのデータ送信要求」を決定しておらず、「前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整する」ものではない点。

(2) 当審の判断
事案に鑑み、まず、上記[相違点2]について検討する。
上記[相違点2]に係る、「コネクションレス型プロトコルを利用」する通信機器が、「自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整する」構成は、上記引用文献1−5には記載されておらず、周知技術であるともいえない。

すなわち、上記引用文献2(上記第5の2を参照。)には、データ通信において、空調に関するデータを送受信する周知技術が開示されているが、上記[相違点2]に係る構成は、記載されていない。

上記引用文献1の「従来の技術」欄(上記第5の1(1)アーイを参照。)、及び、上記引用文献3−4(上記第5の3−4を参照。)には、コネクション型プロトコルの1つであるTCPプロトコルを利用する通信機器が、フロー制御のために、TCPプロトコルにおける「ACK信号」の送信タイミングを調整する周知技術が開示されているが、上記[相違点2]に係る構成は、記載されていない。
なお、引用文献4(上記第5の4(2)を参照。)には、「その他フロー制御を行う同様のプロトコルにおいても適用可能である」ことが記載され、TCP以外の「フロー制御を行うプロトコル」にも、上記周知技術が適用可能である旨の開示がある。しかしながら、コネクションレス型プロトコルでは、そもそも「ACK信号」等によるフロー制御を行わないプロトコルであるから(例えば、上記引用文献1の「従来の技術」欄の段落【0005】「UDPでは到達確認を行わないため・・・したがって、・・・UDPの場合、バッファリングのみで帯域制御を行っている。」の記載を参照。)、上記引用文献4の上記記載に基づいて、コネクションレス型プロトコルに対してまで、上記周知技術を適用することはできない。

上記引用文献5(上記第5の5を参照。)には、データ通信におけるトラフィック制御の手法として、データ通信を実行するプロセスの数(「ドライバの数」に相当。)を制限する周知技術が開示されているが、上記[相違点2]に係る構成は、記載されていない。

したがって、本願発明1は、当業者であっても引用発明、引用文献2−5に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2 請求項2−10について
本願発明2−10も、本願発明1の上記[相違点2]に係る、「コネクションレス型プロトコルを利用」する通信機器が、「自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整する」構成と、(実質的に)同一の構成を備えるものであるから、本願発明1と同様の理由により、当業者であっても、引用発明、引用文献2−5に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。

第7 当審拒絶理由の理由1(特許法第36条第6項第1号)について
当審では、請求項6−10において、(1)請求項6の「空きドライバ(228)の数に基づいて、前記データ送信要求を決定する」との構成、(2)請求項10の「送信バッファ(23)の空きサイズに応じて、前記送信端末(10)への前記データ送信要求を決定する」との構成は、発明の詳細な説明において発明の課題を解決できることを当業者が認識できるように記載された範囲を超えるとの拒絶の理由を通知しているが、令和4年11月14日付けの手続補正において、(1)「空きドライバ(228)の数に基づいて、前記データ送信要求を決定する」との構成、(2)「送信バッファ(23)の空きサイズに応じて、前記送信端末(10)への前記データ送信要求を決定する」との構成に、「さらに、」を追加して、新たな請求項3、10とする補正がなされた結果、この拒絶の理由は解消した。

第8 原査定についての判断
令和4年11月14日付けの手続補正により、補正後の請求項1−10は、本願発明1の上記[相違点2]に係る、「コネクションレス型プロトコルを利用」する通信機器が、「自身の受信可能サイズに応じて、前記送信端末(10)から前記データを受信するためのデータ送信要求を決定し、前記データ送信要求によって、前記送信端末(10)から前記データを受信するタイミングを調整する」という技術的事項を有するものとなった。
当該技術的事項は、原査定における引用文献A−Fには記載されておらず、周知技術でもないので、本願発明1−10は、当業者であっても、原査定における引用文献A−Fに基づいて容易に発明をすることができたものではない。
したがって、原査定を維持することはできない。

第9 むすび
以上のとおり、原査定の理由によって、本願を拒絶することはできない。
他に本願を拒絶すべき理由を発見しない。
よって、結論のとおり審決する。


 
審決日 2023-01-06 
出願番号 P2020-146121
審決分類 P 1 8・ 537- WY (H04L)
P 1 8・ 121- WY (H04L)
最終処分 01   成立
特許庁審判長 ▲吉▼田 耕一
特許庁審判官 稲葉 和生
富澤 哲生
発明の名称 通信機器  
代理人 新樹グローバル・アイピー特許業務法人  

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