• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 4号2号請求項の限定的減縮 取り消して特許、登録 H04W
審判 査定不服 5項独立特許用件 取り消して特許、登録 H04W
審判 査定不服 2項進歩性 取り消して特許、登録 H04W
審判 査定不服 特17条の2、3項新規事項追加の補正 取り消して特許、登録 H04W
管理番号 1315265
審判番号 不服2015-15325  
総通号数 199 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2016-07-29 
種別 拒絶査定不服の審決 
審判請求日 2015-08-17 
確定日 2016-06-23 
事件の表示 特願2013-516954「モバイルアドホックネットワークにおけるデータ送信」拒絶査定不服審判事件〔平成24年 1月12日国際公開、WO2012/003637、平成25年 9月12日国内公表、特表2013-535854、請求項の数(14)〕について、次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は、特許すべきものとする。 
理由 第1 手続の経緯

本願は,2010年(平成22年)7月8日を国際出願日とし,平成25年2月21日付けで手続補正書の提出がなされ,平成26年1月6日付けで拒絶理由が通知され,同年3月24日付けで意見書とともに手続補正書の提出がなされ,同年8月15日付けで拒絶理由が通知され,同年11月11日付けで意見書とともに手続補正書の提出がなされ,平成27年4月17日付けで拒絶査定され,同年8月17日に拒絶査定不服審判の請求と同時に手続補正がなされ,同年10月30日付けで前置報告書が作成されたものである。


第2 本件補正

1.本件補正の概要
平成27年8月17日付け手続補正(以下「本件補正」という。)は,次の<本件補正前>の特許請求の範囲における請求項1,3,6及び10の記載を,次の<本件補正後>のようにすることを含むものである。(下線は請求人が付与。)

<本件補正前>
【請求項1】
モバイルアドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法であって、
第2のノードによって、第1のノードからルート応答パケットを受信することと、
前記第2のノードによって、前記ルート応答パケットを漏れ聞かれたルート応答パケットとして識別することと、
前記第2のノードによって、前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第2のノードのルーティングテーブルに追加することと、
前記第2のノードによって、前記第1のルーティングエントリに関連付けられたルーティングエントリ追加済みのメッセージをブロードキャストすることと、
前記第2のノードによって、第3のノードから送信されたデータを受信することであって、前記データは、前記ルーティングエントリ追加済みのメッセージに応答して前記第3のノードにより送信されたものである、ことと、
前記第2のノードによって、前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリに基づいて確立されたアクティブなルート経由で、前記第3のノードから受信されたデータを前記宛先ノードに向けて送信することとを含み、
前記第1のルーティングエントリが前記第1のノードを前記宛先ノードに向う次のホップとして含む、方法。

【請求項3】
モバイルアドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法であって、
第1のノードからのルート応答パケットを漏れ聞いた第2のノードからブロードキャストされた、前記漏れ聞かれたルート応答パケットに関連付けられたルーティングエントリ追加済みのメッセージを、第3のノードによって受信することと、
前記第3のノードによって、前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第3のノードのルーティングテーブルに追加することと、
前記第3のノードによって、前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリに基づいて確立された第1のアクティブなルートを経由して、前記宛先ノードに向けてデータを送信することと
を含み、
前記第1のルーティングエントリが前記第2のノードを前記宛先ノードに向う次のホップとして含む、方法。

【請求項6】
モバイルアドホックネットワークにおいて宛先ノードに向けてデータを送信するための第2のノードにおける装置であって、
メモリと、
前記メモリとインターフェースをとるように構成された処理ユニットとを備え、
前記処理ユニットが、
第1のノードからルート応答パケットを受信し、
前記ルート応答パケットを漏れ聞かれたルート応答パケットとして識別し、
前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第2のノードのルーティングテーブルに追加し、
前記第1のルーティングエントリに関連付けられたルーティングエントリ追加済みのメッセージをブロードキャストし、
第3のノードが前記ルーティングエントリ追加済みのメッセージに応答して送信した、前記第3のノードから送信されたデータを受信し、
前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリに基づいて確立されたアクティブなルート経由で、前記第3のノードから受信されたデータを前記宛先ノードに向けて送信するように構成され、
前記第1のルーティングエントリが前記第1のノードを前記宛先ノードに向う次のホップとして含む、装置。

【請求項10】
モバイルアドホックネットワークにおいて宛先ノードに向けてデータを送信するための第3のノードにおける装置であって、
メモリと、
前記メモリとインターフェースをとるように構成された処理ユニットとを備え、
前記処理ユニットが、
第1のノードからのルート応答パケットを漏れ聞いた第2のノードによってブロードキャストされた、前記漏れ聞かれたルート応答パケットに関連付けられたルーティングエントリ追加済みのメッセージを受信し、
前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第3のノードのルーティングテーブルに追加し、
前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリに基づいて確立された第1のアクティブなルートを経由して、前記宛先ノードに向けてデータを送信するように構成され、
前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリが、前記第2のノードを前記宛先ノードに向う次のホップとして含む、装置。

<本件補正後>
【請求項1】
モバイルアドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法であって、
第2のノードによって、第1のノードからルート応答パケットを受信することと、
前記第2のノードによって、前記ルート応答パケットを漏れ聞かれたルート応答パケットとして識別することと、
前記第2のノードによって、前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第2のノードのルーティングテーブルに追加することと、
前記第2のノードによって、前記第1のルーティングエントリに関連付けられたルーティングエントリ追加済みのメッセージをブロードキャストすることと、
前記第2のノードによって、第3のノードから送信されたデータを受信することであって、前記データは、前記ルーティングエントリ追加済みのメッセージに応答して前記第3のノードにより送信されたものである、ことと、
前記第2のノードによって、前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記第3のノードから受信されたデータを前記宛先ノードに向けて送信することとを含み、
前記第1のルーティングエントリが前記第1のノードを前記宛先ノードに向う次のホップとして含む、方法。

【請求項3】
モバイルアドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法であって、
第1のノードからのルート応答パケットを漏れ聞いた第2のノードからブロードキャストされた、前記漏れ聞かれたルート応答パケットに関連付けられたルーティングエントリ追加済みのメッセージを、第3のノードによって受信することと、
前記第3のノードによって、前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第3のノードのルーティングテーブルに追加することと、
前記第3のノードによって、前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記宛先ノードに向けてデータを送信することと
を含み、
前記第1のルーティングエントリが前記第2のノードを前記宛先ノードに向う次のホップとして含む、方法。

【請求項6】
モバイルアドホックネットワークにおいて宛先ノードに向けてデータを送信するための第2のノードにおける装置であって、
メモリと、
前記メモリとインターフェースをとるように構成された処理ユニットとを備え、
前記処理ユニットが、
第1のノードからルート応答パケットを受信し、
前記ルート応答パケットを漏れ聞かれたルート応答パケットとして識別し、
前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第2のノードのルーティングテーブルに追加し、
前記第1のルーティングエントリに関連付けられたルーティングエントリ追加済みのメッセージをブロードキャストし、
第3のノードが前記ルーティングエントリ追加済みのメッセージに応答して送信した、前記第3のノードから送信されたデータを受信し、
前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記第3のノードから受信されたデータを前記宛先ノードに向けて送信するように構成され、
前記第1のルーティングエントリが前記第1のノードを前記宛先ノードに向う次のホップとして含む、装置。

【請求項10】
モバイルアドホックネットワークにおいて宛先ノードに向けてデータを送信するための第3のノードにおける装置であって、
メモリと、
前記メモリとインターフェースをとるように構成された処理ユニットとを備え、
前記処理ユニットが、
第1のノードからのルート応答パケットを漏れ聞いた第2のノードによってブロードキャストされた、前記漏れ聞かれたルート応答パケットに関連付けられたルーティングエントリ追加済みのメッセージを受信し、
前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第3のノードのルーティングテーブルに追加し、
前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記宛先ノードに向けてデータを送信するように構成され、
前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリが、前記第2のノードを前記宛先ノードに向う次のホップとして含む、装置。

2.本件補正に関する検討
(1) 審判請求書における記載
審判請求書において,請求人は,本件補正について次のように主張する。(下線は当審が付与。)

3-2.補正の説明
(1)補正後の請求項1の補正事項は、出願当初明細書段落0019等の記載に基づき、「前記第3のノードから受信されたデータを前記宛先ノードに向けて送信する」ための「ルート」を限定的に減縮するものです。また、請求項1以外の独立請求項についても、請求項1と同様の補正を行いました。
(2)従属請求項の補正事項は、独立請求項の補正に伴い微修正するものです。
したがって、各請求項に係る補正事項は、審判請求時に係る補正の制限を満たすものであると思料致します。

(2) 前置報告書における記載
前置報告書には,次の記載がある。(下線は当審が付与。)

補正後の請求項1には「前記第2のノードによって、前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記第3のノードから受信されたデータを前記宛先ノードに向けて送信すること」という記載があるが、当該記載は新規事項の追加に該当する。
すなわち、上記記載では、第2のノード(図1Aの111)が2つのルートを順に使用することでデータを送信する旨が規定されているといえるが、本願明細書等には、第2のノードが2つのルートを使用してデータを送信することは記載されていない。
出願人が審判請求書にて[0019]を補正の根拠としているが、当該[0019]では、第3のノードに該当する図1Aの103が2つのルートを使用して送信することのみが記載されているに過ぎない。そして、明細書等の他の記載を検討しても、第2のノードが2つのルートを順に使用することは記載されておらず、第2のノードが2つのルートを順に使用することが自明な事項といえる記載も見出せない。

(3) 本件補正に関する当審の見解
ア 本件補正が特許法第17条の2第3項(同法第184条の12第2項参照。)の規定に違反するものであるか否か(本件補正が新たな技術的事項を導入しようとするものであるか否か)について

請求人の主張によると,本件補正は,明細書段落0019の記載に基づくものである。
そこで,該段落0019の記載を確認する。(下線は当審が付与。)
なお,段落0019は,この審判請求の時まで,補正も誤訳訂正もなされていない。

【0019】
例示的なルーティングテーブルが、既存のルーティングエントリ(すなわち、テーブル2の第2の行)を最初に有するものと想定されたい。ノード103は、ルーティングエントリ追加済みのメッセージを受信した後、第1のルーティングエントリ(すなわち、テーブル2の第3の行)を追加する。この既存のルーティングエントリは、ノード103が、送信元ノード101を発信元とするデータを、宛先ノード109に向う次のホップとしてノード105にルーティングするように構成されることを示す。新たに追加された第1のルーティングエントリは、送信元ノード101を発信元とするデータを、宛先ノード109に向う次のホップとしてスヌープノード111にルーティングするようにノード103が構成されることを示す。したがって、ノード103は、既存のルーティングエントリを選択して、既存のルーティングエントリに基づいて確立された第1のアクティブなルート(たとえば、図1Aのルート121)を経由して、または第1のルーティングエントリを選択して、第1のルーティングエントリに基づいて確立された第2のアクティブなルート(たとえば、図1Bのルート131)を経由して、送信元ノード101と宛先ノード109の間でデータを送信することが可能である。一部の実施形態において、ノード103は、データを送信するために、ノード103のルーティングテーブルから既存のルーティングエントリと第1のルーティングエントリの両方を選択することが可能である。たとえば、ノード103は、既存のルーティングエントリおよび第1のルーティングエントリに基づく2つのルートを順に使用することが可能である。ノード103は、既存のルーティングエントリに基づいてノード105に第1のパケットを送信し、第1のルーティングエントリに基づいてノード111に第2のパケットを送信し、ノード105に第3のパケットを送信し、ノード111に第4のパケットを送信し、以下同様であることが可能である。

当該記載によると,次のことがいえる。
「ノード103」は,「データを送信するために、ノード103のルーティングテーブルから既存のルーティングエントリと第1のルーティングエントリの両方を選択することが可能である」のだから,「ノード103」の中に「既存のルーティングエントリ」と「第1のルーティングエントリ」があるといえることは明白である。
そして,「ノード103」は,「既存のルーティングエントリおよび第1のルーティングエントリに基づく2つのルートを順に使用することが可能である」のだから,「データを送信するために,ノード103によって,ノード103のルーティングテーブルの中の第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルート順に使用すること」が,段落0019には記載されているといえることは明らかである。

ここで,段落0019には,ノードとして,「送信元ノード101」,「宛先ノード109」,「ノード103」,「ノード105」,そして「スヌープノード111」が記載されているところ,該段落0019の記載に本件補正後の請求項1の記載を照らすならば,同請求項1記載の「第2のノード」が該段落0019記載の「ノード103」に相当するということができる。そして,該「第2のノード」は,「第1のノード」からの「ルート応答パケット」を「漏れ聞かれたルート応答パケットとして識別する」のであるから,該「第1のノード」は該段落0019に記載された「スヌープノード111」に相当するということができる。更に,該「第2のノード」は,「第3のノード」から「送信されたデータを受信」し,「宛先ノードに向けて送信する」のであるから,該「第3のノード」は該段落0019に記載された「送信元ノード101」に相当するということができる。
そして,同様のことが,本件補正後の請求項6に記載された「第1のノード」,「第2のノード」及び「第3のノード」についてもいえる。
次に,該段落0019の記載に本件補正後の請求項3の記載を照らすならば,同請求項記載の「第3のノード」が該段落0019記載の「ノード103」に相当するということができる。
そして,同請求項3記載の「第2のノード」は,「第1のノード」からの「ルート応答パケット」を漏れ聞くのであるから,該「第2のノード」は該段落0019に記載された「スヌープノード111」に相当するということができ,また,該「第1のノード」は該段落0019に記載された「ノード107」に相当するということができる。
そして,同様のことが,本件補正後の請求項10に記載された「第1のノード」,「第2のノード」及び「第3のノード」についてもいえる。

以上のことは,本件補正が,新たな技術的事項を導入しようとするものでないことを示している。
したがって,本件補正が,特許法第17条の2第3項(同法第184条の12第2項参照。)の規定に違反するものであるということはできない。
また,ほかに,当該規定に違反するということができる理由を発見しない。


イ 本件補正が特許法第17条の2第5項第2号に掲げる目的に該当するか否か(本件補正が特許請求の範囲の減縮を目的とするものであるか否か),そして,本件補正が特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するか否か(特許出願の際独立して特許を受けることができるか否か)について

審判請求書における記載も参酌すると,本件補正は,「前記第3のノードから受信されたデータを前記宛先ノードに向けて送信する」ための「ルート」を限定的に減縮したと解することができる。

そこで,本件補正が特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するか否か(本件補正後の請求項1から14に記載された発明が,特許出願の際独立して特許を受けることができるか否か)について検討する。

(ア) 引用文献及び記載事項
原査定の理由に,引用文献1として引用された刊行物は次のとおりである。

中国特許出願公開第101335701号明細書(2008年(平成20年)12月31日中国国内公開(CN101335701A)。以下,単に「引用文献」と呼ぶ。)

上記引用文献には,図面とともに次の事項が記載されている。

<引用文献記載事項>


(当審訳(下線は当審が付与。)
詳細な説明
以下の実施例は,本発明が提供するマルチホップ無線アドホックネットワークのオンデマンド(On-demand)動的メンテナンス方法であり,実施例のネットワーク構成は図11に示すとおりであり,15のノードから成り,当初のノードは最初のノードとし,そのノードS,Rそれぞれを送信元ノードと宛先ノードとし,ノード間の接続は無線リンクの存在を示し,直接通信もできる。

第一,プライマリルート確立処理(図3)

(1)宛先ノードRへ,送信元ノードSは,プライマリルート要求メッセージPRREQ(PRREQフォーマットは図1を参照)をブロードキャストする。
(2)最初,PRREQのノードシーケンス情報に基づいて,PRREQを中間ノードA,B,E等が受信し,Sへのルートを確立し,自身のIDがPRREQを介してノードシーケンスに追加され,同じPRREQを受信した場合は,破棄される。
(3)中間ノードは,Rに到達するルートがある場合,このルートを介してPRREQは送信され,再びブロードキャストしない,そうでない場合はPRREQをブロードキャストし続ける。
(4)RがPRREQを受信した後,受信したPRREQメッセージすべてを比較し,プライマリルートとして最適なルートを選択し(本実施形態の最適条件は,ホップ数が最小),これにより,この例示的実施形態における最適なルート,ノードシーケンスABCDERを取得する。
(5)最適ルートの逆ルート,SへのREDCBASに沿ってRは,プライマリルート応答メッセージPRREP(PRREQ<*PRREP*>フォーマットは図2に示す)を返信し,それにはルートに沿ったノードシーケンスを含む。
(6)Rへのプライマリルートを確立するために,ルートを介したノードシーケンスの中間ノードでPRREP及びノードIDを受信し,そして,自己のタイプをプライマリノードに設定し,その後,PRREPを転送する。
(7)PRREPを受信した送信元ノードSは,RのプライマリルートSABCDERが到達してから確立する。

(当審注:上記(5)における「PRREQ<*PRREP*>」は原文では「PRREQ」と記載されているが,当該記載が正しくは「PRREP」の明らかな誤記であることを示している。)

第二,バックアップルート確立処理(図5)

(1)プライマリルート確立処理において,EのようなノードがPRREPを受信した場合,まず,自分自身に送信することにより,PRREPかどうかを決定し,自身によって送信された場合,パケットを破棄する;
そうでない場合,次に続ける;
Rに対し送信するPRREPに関し,Eは受信することができ,Dの送信するPRREPに対して,Eは破棄することができる
(2)例えば,E,D,C,B,A等のノードIDが,ルートに沿ったノードのシーケンスに含まれている場合は,自分自身のタイプをプライマリノードに設定し,宛先ノードへのプライマリルートを確立し,PRREPを転送する;
(3)H,G,F,P,Q等のノードIDが,ルートに沿ったノードのシーケンスに含まれていない場合,自分自身のタイプをバックアップノードに設定し,Rへのバックアップルートを確立する;
Hのようにバックアップノードとなり,RへのバックアップルートHER,HDERを確立する;
G,F,P,Qは,バックアップノードとなり,Rへのバックアップルートとなる;
(4)バックアップノードH,G,F,P,Qは,バックアップルート更新メッセージBRUM(BRUMフォーマットは,図4に示されている)によって,自分自身のバックアップルート情報を作成し,自分自身に隣接するノードにブロードキャストする;
(5)BRUMのプライマリノード及びバックアップノードを受信し,そのルート情報が新しいルート情報かあるいは更に優れたルート情報化を判断し,そうであれば,ルート情報が格納される;
BのようにプライマリルートBCDERを確立するほか,さらに,複数のバックアップルート:BFGHER,BFGHDER,BFGCDER,BPQCDER等を確立する。
各プライマリノードが確立しプライマリルートとバックアップルートは表1に示すとおり:

表1

(6)バックアップノードがバックアップルートに更新があることを検出したとき,隣接ノードにバックアップルート更新情報を通知するBRUMをブロードキャストする;
(7)最初のノードがBRUMを受信するとき,そのパケットは廃棄される。

プライマリルートとバックアップルートが確立した後のネットワークは図12に示すとおり。

第三,ルートメンテナンス処理(図10)

前記のオンデマンドルート動的メンテナンス方法は,ルートメンテナンス処理は二つの部分で構成され,第一の部分は,バックアップルートに故障が発生したとき,故障したバックアップノードを検出すると,エラーメッセージをバックアップルートに通知する;第二の部分は,プライマリルートに故障が発生したとき,
プライマリルートに対し,動的メンテナンスを実行する。

第一部分:バックアップルートに故障が発生したとき

実施例において,バックアップノードGに故障が生じると,Gの5つのバックアップルートBFGHER,BFGHDER,BFGCDER,CGHER,CGHDERを通過するのに影響するだろう。

バックアップノードFがバックアップルートBFGHER,BFGHDERとBFGCDER故障を検出すると,バックアップルートエラーメッセージBRERR(BRERRフォーマットは,図6に示されている)をブロードキャストする,エラーのバックアップロート情報を通知し,プライマリノードBが,FのブロードキャストしたBRERRを受信した後,故障したバックアップルートBFGHER,BFGHDERとBFGCDERはルートテーブルから削除できる。

プライマリノードCがGの故障を検出すると,故障したバックアップルートCGHERとCGHDERをルートテーブルから削除する,しかし,CはBRERRをブロードキャストできない。

バックアップノードに利用可能なバックアップルートがないとき,もし規定の時間T(T=30秒のように)内に利用可能なバックアップルートがない場合,バックアップノードは自分自身のタイプを最初のノードに設定するだろう。

第二部分:プライマリルートに故障が発生したとき

実施例において,プライマリノードCに故障が生じると,プライマリルートSABCDERに影響し,プライマリノードBはCの故障を検出できる(リンク層の故障をネットワーク層に通知する)。

(1)Bが下流ノードCの故障を検出したとき,宛先ノードRに到達することができるバックアップルートがあるか否かを確認する。Rに到達可能な二つのバックアップルートBFGHERとBFGHDERの発見を経て,最良のバックアップルートBFGHERをプライマリルートとし選択するだろう,そして,同時に新しいプライマリルートに沿って,送信元ノードSと宛先ノードR向け,プライマリルート更新情報PRUM(PRUMフォーマットは,図7に示されている)を送信する。
(2)PRUMを受信したバックアップノードF,G,H,Pは,F,G,Hがプライマリルート更新ノードシーケンスに含まれることにより,F,G,Hは自分自身のタイプをプライマリノードに設定するだろう;
Pはプライマリルート更新ノードシーケンスにないので,Pはまだバックアップノードである;
(3)PRUMを受信したDのようなプライマリノードについて,Dはルート更新ノードシーケンスに含まれないことにより,その後,Dは自分自身のタイプをバックアップノードに設定するだろう,Dが宛先ノードRに到達するルートDERは,バックアップルートに設定し,ルートに更新があるとき,バックアップルート更新メッセージBRUMをブロードキャストする;
(4)PRUMを受信した最初のノードI,J,Kは自分自身のタイプをバックアップノードに設定し,そして,バックアップノード更新メッセージBRUMをブロードキャストし,バックアップルートを確立する;
プライマリルート修復後のプライマリノードのプライマリルートとバックアップルートは表2に示すとおり:

表2

(5)バックアップノードQがCの故障を検出した後,
もとのバックアップルートQCDERの故障する,なぜなら,
規定時間T(例えば,T=30秒)内でバックアップルートを持たないQがあるためであり,バックアップノードが最初のノードとなるだろう。

プライマリノードCが故障し,プライマリルート修復後のネットワーク構造は図13に示すとおり。

実施例において,プライマリノードCは故障していないがBは故障しているとき,プライマリノードはプライマリルートの下流ノードの故障を検出できる,その上,Aもバックアップルートを持たない,この場合,Aは送信元ノードSへプライマリルートエラーメッセージPRERR(PRERRのフォーマットは図8に示される)を送信し,Sに再びプライマリルートの確立処理を開始することを通知する;

PREERを受信するプライマリノードとバックアップノードは自分自身を最初のノードに設定するだろう,そして,それに応じたルート情報を削除する;

プライマリルートCDERが規定時間T(例えばT=30秒)内に使用されないとき,宛先ノードRはプライマリルートに沿って,送信元ノードS方向にプライマリルート解放メッセージPRR(PRRのフォーマットは図9に示される)を送信し,PRRを受信したプライマリノードE,D,C及びバックアップノードQ,G,H,全てが自分自身のタイプを最初のノードに設定し,そして,対応するルート情報を削除するだろう。その上,Q,G,Hは,BRERRをブロードキャストするだろう,削除するバックアップルート情報から既に故障していることを通知し,バックアップノードF,PがBRERRを受信した後,対応するバックアップルート情報を削除するだろう。所定時間Tの後,F,Pにはバックアップルートがないので,バックアップノードは最初のノードになる。

第四,ルート選択処理

(1)プライマリルート確立処理によってプライマリノードS,A,B,C,D,E,Rはプライマリルートを取得し,それは表1に示すとおりである;

(2)バックアップルート確立処理によってプライマリノードB,C,Dはバックアップルートを取得し,それは表1に示すとおりである;

(3)プライマリルートSABCDERが正常であるとき,このプライマリルートを介してデータを伝送する;

(4)プライマリルートSABCDERが故障したとき,バックアップルートを有するプライマリノードである場合には,最良のバックアップルートを介してデータを伝送し,そして,該バックアップルートがプライマリルートとしてアップグレードする;
ノードCが故障したとき,Bは,利用可能なバックアップルートBFGHER及びBFGHDERを有し,最良のBFGHERを選択し,データを伝送し,そして,このルートをプライマリルートとし,その後,SとRの間のプライマリルート:SABFGHERを得る。

(5)ノードBが故障したとき,Aはバックアップルートを有さず,プライマリルートは利用できない,その後,Aは送信元ノードSに新たなプライマリルートを確立することを通知する。

本発明は,一種のマルチホップ無線アドホックネットワークのオンデマンドルートの動的メンテナンス方法を提供するものであり,既存のオンデマンドルートプロトコルの持つルートメンテナンス面の不足を克服し,メインルートの故障の前にバックアップルートを確立し,そしてバックアップルートに対し適時に更新をし,同時にバックアップルートの確立が規定の範囲内に制限され,オンデマンドルートプロトコルとプロアクティブ(Proactive)プロトコルの利点を結合するだけではなく,ルートメンテナンスのコストを可能な限り下げた。)

(イ) 引用発明
上記の記載によると,引用文献には,次の発明(以下「引用文献」という。)が記載されているといえる。

プライマリルート確立処理,バックアップ確立処理及びルートメンテナンス処理を含むマルチホップ無線アドホックネットワークのオンデマンド(On-demand)動的メンテナンス方法であって,
前記プライマリルート確立処理にあっては,
宛先ノードRへ,送信元ノードSは,プライマリルート要求メッセージPRREQをブロードキャストし,
宛先ノードRがPRREQを受信した後,受信したPRREQメッセージすべてを比較し,プライマリルートとして最適なルートを選択し,これにより,最適なルート,ノードシーケンス(ABCDER)を取得し,
最適ルートの逆ルート,SへのREDCBASに沿って宛先ノードRは,プライマリルート応答メッセージPRREPを返信し,それにはルートに沿ったノードシーケンスを含み,
宛先ノードRへのプライマリルートを確立するために,ルートを介したノードシーケンスの中間ノードでPRREP及びノードIDを受信し,そして,自己のタイプをプライマリノードに設定し,その後,PRREPを転送し,
PRREPを受信した送信元ノードSは,宛先ノードRのプライマリルート(SABCDER)が到達してから確立する
プライマリルート確立処理と,
前記バックアップルート確立処理にあっては,
ノードID(例えば,E,D,C,B,A等)が,ルートに沿ったノードのシーケンスに含まれている場合は,自分自身のタイプをプライマリノードに設定し,宛先ノードへのプライマリルートを確立し,PRREPを転送し,
ノードID(H,G,F,P,Q等)が,ルートに沿ったノードのシーケンスに含まれていない場合,自分自身のタイプをバックアップノードに設定し,宛先ノードRへのバックアップルートを確立し,バックアップノード(Hのように)となり,宛先ノードRへのバックアップルート(HER,HDER)を確立し,
バックアップノード(G,F,P,Q)を構成し,宛先ノードRへのバックアップルートとなり,
バックアップノード(H,G,F,P,Q)は,バックアップルート更新メッセージBRUMによって,自分自身のバックアップルート情報を作成し,自分自身に隣接するノードにブロードキャストし,
BRUMのプライマリノード及びバックアップノードを受信し,そのルート情報が新しいルート情報かあるいは更に優れたルート情報化を判断し,そうであれば,ルート情報が格納され,Bのようにプライマリルート(BCDER)を確立するほか,さらに,複数のバックアップルート(BFGHER,BFGHDER,BFGCDER,BPQCDER等)を確立する
バックアップルート確立処理と,
前記ルートメンテナンス処理にあっては,
バックアップノード(F)がバックアップルート(BFGHER,BFGHDERとBFGCDER)故障を検出すると,バックアップルートエラーメッセージBRERRをブロードキャストし,エラーのバックアップロート情報を通知し,プライマリノード(B)が,前記バックアップノード(F)のブロードキャストしたBRERRを受信した後,故障したバックアップルート(BFGHER,BFGHDERとBFGCDER)はルートテーブルから削除でき,
プライマリノード(C)がバックアップノード(G)の故障を検出すると,故障したバックアップルート(CGHERとCGHDER)をルートテーブルから削除する
ルートメンテナンス処理と
を含むマルチホップ無線アドホックネットワークのオンデマンド動的メンテナンス方法。


第3 当審の判断

1.対比及び検討
本件補正後の請求項1,3,6及び10に記載された発明(以下,それぞれを「本願第1発明」,「本願第3発明」,「本願第6発明」及び「本願第10発明」という。)それぞれと,引用発明とを対比すると次のことがいえる。

(1) 本願第1発明について
引用発明における「プライマリルート応答メッセージPRREP」も本願第1発明における「ルート応答パケット」もともに,「ルート応答」に関する信号である点において共通するといえる。
そして,上記「プライマリルート応答メッセージPRREP」に含まれる「ノードE,D,C,B,A」は,該PRREPを送信するとき,本願第1発明における「第1のノード」ということができ,また,該PRREPを受信するとき本願第1発明における「第2のノード」ということができる。
そして,引用発明においては,該PRREPを送信元ノードSが受信することによって,「プライマリルート(SABCDER)」が確立し,該プライマリルート上をデータが転送される。このため,プライマリルートのノードA,B,C,D,Eは,データを送信する時本願第1発明における「第3のノード」といえ,データを受信するとき「第2のノード」ということができる。
ここで,引用発明におけるバックアップノード(H,G,F,P,Q等)についてみると,該バックアップノードは,自身のノードIDが上記「PRREP」に含まれていなくとも,該「PRREP」を受信しているのである。このことは,該「バックアップノード」が該「PRREP」を「漏れ聞いた」ということができることを示している。

引用発明における「ルートテーブル」は本願第1発明における「ルーティングテーブル」に相当する。

これらを踏まえると,本願第1発明と引用発明は次の点で一応共通し,少なくとも次の相違があるといえる。

<本願第1発明と引用発明の共通点>
アドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法であって、
第2のノードによって、第1のノードからルート応答パケットを受信することと、
前記第2のノードによって、前記ルート応答パケットを漏れ聞かれたルート応答パケットとして識別することと、
前記第2のノードによって、前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第2のノードのルーティングテーブルに追加することと、
前記第2のノードによって、前記第1のルーティングエントリに関連付けられたルーティングエントリ追加済みのメッセージをブロードキャストすることと、
前記第2のノードによって、第3のノードから送信されたデータを受信することであって、前記データは、前記ルーティングエントリ追加済みのメッセージに応答して前記第3のノードにより送信されたものである、ことと、
を含み、
前記第1のルーティングエントリが前記第1のノードを前記宛先ノードに向う次のホップとして含む、方法。

<本願第1発明と引用発明の相違点><1> 本願第1発明は,「モバイルアドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法」であるのに対し,引用発明における「アドホックネットワーク」が「モバイルアドホックネットワーク」であるとの特定がない点(相違点1)。
<2> 本願第1発明は,「前記第2のノードによって、前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記第3のノードから受信されたデータを前記宛先ノードに向けて送信する」ことを発明特定事項として有するのに対して,引用発明においては,「前記第2のノード」によって,「前記第3のノードから受信されたデータを前記宛先ノードに向けて送信する」のに,「前記第2のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用する」ことで送信することの特定がない点(相違点2)。

<本願第1発明に関する相違について>
[相違点1,2について]
「アドホックネットワーク」を「モバイル端末」により構成することは,例を示すまでもなく周知であり,引用発明に対し周知技術を適用することによって,相違点1のように構成することは当業者が適宜なしえた事項であるといえる。
しかし,相違点2のように,「前記第2のノード」によって,「前記第3のノードから受信されたデータを前記宛先ノードに向けて送信する」のに,「前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用する」ことで送信することを,引用発明に基づいて,当業者がなしえたということができる理由を発見しない。

したがって,原査定の理由によって,本願第1発明が,特許出願の際独立して特許を受けうることができないということはできない。
また,ほかに,本願第1発明が,特許出願の際独立して特許を受けることができないといい得る理由を発見しない。

(2) 本願第6発明について
本願第6発明についても,上記(1)に述べたのと同様であり,原査定の理由によって,本願第6発明が,特許出願の際独立して特許を受けうることができないということはできない。
また,ほかに,本願第6発明が,特許出願の際独立して特許を受けることができないといい得る理由を発見しない。

(3) 本願第3発明について
引用発明における「プライマリルート応答メッセージPRREP」も本願第3発明における「ルート応答パケット」もともに,「ルート応答」に関する信号である点において共通するといえる。
そして,そして,上記「プライマリルート応答メッセージPRREP」に含まれる「ノードE,D,C,B,A」は,該PRREPを送信するとき,本願第1発明における「第1のノード」ということができ,また,引用発明における「バックアップノード(G,F,P,Q)」が,上記PRREPを受信することは,上記「ノードE,D,C,B,A」からの応答パケットを「漏れ聞く」ということができる。このため,上記「バックアップノード(G,F,P,Q)」は,本願発明における「第2のノード」と,「応答パケット」を漏れ聞く点において共通するということができる。

これらを踏まえると,本願第3発明と引用発明は次の点で一応共通し,少なくとも次の相違があるといえる。

<本願第3発明と引用発明の共通点>
アドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法であって、
第1のノードからのルート応答パケットを漏れ聞いた第2のノードからブロードキャストされた、前記漏れ聞かれたルート応答パケットに関連付けられたルーティングエントリ追加済みのメッセージを、第3のノードによって受信することと、
前記第3のノードによって、前記漏れ聞かれたルート応答パケットに関連付けられた第1のルーティングエントリを前記第3のノードのルーティングテーブルに追加することと、
を含み、
前記第1のルーティングエントリが前記第2のノードを前記宛先ノードに向う次のホップとして含む、方法。

<本願第3発明と引用発明の相違点> <1> 本願第3発明は,「モバイルアドホックネットワークにおいて送信元ノードから宛先ノードにデータを送信するための方法」であるのに対し,引用発明における「アドホックネットワーク」が「モバイルアドホックネットワーク」であるとの特定がない点(相違点1)。
<2> 本願第3発明は,「前記第3のノードによって、前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用することで、前記宛先ノードに向けてデータを送信する」ことを発明特定事項として有するのに対して,引用発明においては,「前記第3のノード」によって,「前記宛先ノードに向けてデータを送信する」のに,「前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用する」ことで送信することの特定がない点(相違点2)。

<本願第3発明に関する相違について>
[相違点1,2について]
相違点1については,上記(1)の「<本願第1発明に関する相違について>」に述べたのとおりであって,当業者が適宜なし得た事項であるといえる。
しかし,相違点2のように,「前記第3のノード」によって,「前記宛先ノードに向けてデータを送信する」のに,「前記第2のノードを経由し、かつ前記第3のノードの前記ルーティングテーブルの中の前記第1のルーティングエントリ及び既存のルーティングエントリに基づく2つのルートを順に使用する」ことで送信することを,引用発明に基づいて,当業者がなし得たということができる理由を発見しない。

したがって,原査定の理由によって,本願第3発明が,特許出願の際独立して特許を受けうることができないということはできない。
また,ほかに,本願第3発明が,特許出願の際独立して特許を受けることができないといい得る理由を発見しない。

(4) 本願第10発明について
本願第10発明についても,上記(3)の述べたのと同様であり,原査定の理由によって,本願第10発明が,特許出願の際独立して特許を受けることができないということはできない。
また,ほかに,本願第10発明が,特許出願の際独立して特許を受けることができないといい得る理由を発見しない。

(5) 本件補正後の請求項2,4,5,7から9,11から14に記載された発明について

本件補正後の請求項2,4,5,7から9,11から14は,請求項1,3,6及び10を,直接的又は間接的に引用している。

そうすると,本件補正後の本件補正後の請求項2,4,5,7から9,11から14に記載された発明も,原査定の理由によって,特許出願の際独立して特許を受けうることができないということはできない。
また,ほかに,これら発明が,特許出願の際独立して特許を受けることができないといい得る理由を発見しない。

(6) まとめ
上記(1)から(5)の述べたとおり,本件補正後の請求項1から14に記載された発明は,特許出願の際独立して特許を受けることができるものである。
したがって,本件補正を,特許法第17条の2第6項において準用する同法第126条第7項の規定に違反するものとして,同法第159条第1項の規定において読み替えて準用する同法第53条第1項の規定により却下すべきものであるということはできない。
そして,ほかに,本件補正を却下すべき理由を発見しない。


第4 本件出願

上記第2及び第3に述べたとおりであるから,本件出願の請求項1から14に係る発明は,本件補正後の特許請求の範囲に記載されたとおりのものである。
したがって,本件出願の請求項1から14に係る発明は,特許を受けることができるものであるということができる。
また,本件出願を拒絶べきものであるということができる理由も発見しない。


第5 むすび

以上のとおりであって,本件出願の請求項1から14に係る発明は,特許受けることができるものである。
また,本件出願について拒絶の理由も発見しない。

したがって,結論のとおり審決する。
 
審決日 2016-06-13 
出願番号 特願2013-516954(P2013-516954)
審決分類 P 1 8・ 121- WY (H04W)
P 1 8・ 575- WY (H04W)
P 1 8・ 572- WY (H04W)
P 1 8・ 561- WY (H04W)
最終処分 成立  
前審関与審査官 古市 徹  
特許庁審判長 加藤 恵一
特許庁審判官 近藤 聡
吉田 隆之
発明の名称 モバイルアドホックネットワークにおけるデータ送信  
代理人 江口 昭彦  
代理人 稲葉 良幸  
代理人 内藤 和彦  
代理人 土屋 徹雄  
代理人 大貫 敏史  

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