• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) H04W
管理番号 1322945
審判番号 不服2015-10491  
総通号数 206 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-02-24 
種別 拒絶査定不服の審決 
審判請求日 2015-06-03 
確定日 2016-12-14 
事件の表示 特願2013-519871「マルチユーザ伝送のためのメディアアクセス手法」拒絶査定不服審判事件〔平成24年 1月26日国際公開、WO2012/012420、平成25年10月 3日国内公表、特表2013-537739〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続きの経緯

本件特許出願は、2011年(平成23年)7月19日(パリ条約による優先権主張外国庁受理2010年(平成22年)7月20日,米国)を国際出願日とする出願であって、その手続の経緯は以下のとおりである。

平成25年12月27日付け:拒絶理由の通知
平成26年 4月14日 :意見書、手続補正書の提出
平成26年 9月 5日付け:拒絶理由の通知
平成26年12月 9日 :意見書、手続補正書の提出
平成27年 1月27日付け:拒絶査定
平成27年 6月 3日 :審判請求書、手続補正書の提出
平成27年 7月17日付け:前置審査における拒絶理由の通知
平成27年11月30日 :意見書、手続補正書の提出
平成27年12月18日付け:前置報告
平成28年 3月 1日付け:当審における拒絶理由の通知
平成28年 6月 7日 :意見書、手続補正書の提出


第2.本件発明について

本件の請求項1に係る発明(「以下、本件発明」という。)は、平成28年6月7日に提出された特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものと認める。

「複数の宛先装置のうちの1つ又は複数の宛先装置を選択するステップと、
前記選択された1つ又は複数の宛先装置のうちの少なくとも一宛先装置との第1の交換を開始するステップであって、前記選択された1つ又は複数の宛先装置のうちの少なくとも一宛先装置にメッセージを送信するステップを含む、ステップと、
前記第1の交換の結果に基づき、前記選択された1つ又は複数の宛先装置のうちの少なくともいくつかの宛先装置にマルチユーザマルチ入力マルチ出力(MU-MIMO)無線データ送信をするかバックオフ時間に入るか選ぶステップであって、前記バックオフ時間は第2の交換が開始される前の時間を含むステップと
を有する方法。」


第3.引用文献について

1.引用文献1の記載
当審における平成28年3月1日付けで通知した拒絶理由にて引用した、本件の優先権主張の日前に公開された刊行物である国際公開第2009/027931号(2009年(平成21年)3月5日公開、以下「引用文献1」という。)には、図面とともに次の事項が記載されている。(なお、下線は当審にて付した。)

(1)第6頁第6行から第19行
「Accordingly, an enhanced MAC frame, i.e., the MU-RTS, is defined. This frame is different from the ordinary RTS frame because it has multiple recipient MAC addresses. This enables an improved way of communicating the list of identifications or addresses to the other transmission ends. Although the proposed enhanced MAC frame has specific fields which are only meaningful/understandable to MU devices, the frame can be transmitted in the legacy physical layer and has common fields, that are understandable by all legacy devices. Therefore, legacy devices can decode the bits, interpret common fields and initiate appropriate settings. The interpretation of the enhanced MAC frame may be a pure MAC process, so that no further information is required from the physical layer. Moreover, there is no need to change interpretation rules for corresponding existing or legacy MAC frames. In view of the fact that all other transmission ends can be at least partially interpreted by all other transmission ends, its transmission can be regarded as a broadcast transmission from the physical layer perspective. Consequently, legacy devices and procedures require little modifications.」
当審訳:
「結果的に、改善されたMACフレーム(すなわちMU-RTS)が定義される。このフレームは、複数の受信側MACアドレスを持つので、通常のRTSフレームと異なる。これは、他の伝送端に識別情報又はアドレスのリストを伝達するための改善された方法を可能にする。提案された改善されたMACフレームは、MU装置に対してのみ意味があり理解可能な特定のフィールドを持つが、このフレームは、レガシー物理レイヤにおいて送信されることができ、全てのレガシー装置が理解できる共通のフィールドを持つ。したがって、レガシー装置は、ビット列を復号することができ、共通のフィールドを解釈することができて、適切な設定を開始することができる。改善されたMACフレームの解釈は、純粋なMACプロセスであってよく、物理レイヤからのさらなる情報は必要とされない。さらに、対応する既存の又はレガシーMACフレームのための解釈ルールを変更する必要はない。全ての他の伝送端が全ての他の伝送端によって少なくとも部分的に解釈され得るという事実を考慮すると、その伝送は、物理レイヤの観点からはブロードキャスト伝送であるとみなされ得る。結果的に、レガシー装置及び手順は、ほとんど変更を必要としない。」

(2)第10頁第5行から第7行
「The following embodiments provide enhancements for multi-user support for IEEE 802.11 based networks by using MU-RTS and M-CTS frames for accessing the channel, and M-ACK for acknowledging the correctly received packets.」
当審訳:
「以下の実施の形態は、チャネルにアクセスするためのMU-RTS及びM-CTSフレーム並びに正常に受信されたパケットに肯定応答するためのM-ACKを用いることによりIEEE 802.11ベースのネットワークのマルチユーザサポートのための拡張を提供する。」

(3)第10頁第16行から第19行
「Fig. 2 shows a four-way handshake procedure according to a first embodiment. The proposed MU-DCF is based on the conventional M-DCF, wherein the four-way handshake procedure is proposed to facilitate channel access with multiple users prior to data transmission.」
当審訳:
「図2は、第1の実施の形態による四方向のハンドシェイク手順を示す。提案されるMU-DCFは、従来のM-DCFに基づいており、四方向のハンドシェイク手順が提案され、これによってデータ伝送に先立ち複数のユーザでのチャネルアクセスを支援する。」

(4)第10頁第22行から第25行
「According to Fig. 2, the transmission is initiated e.g. by the AP 10 by broadcasting an MU-RTS frame as shown in Fig. 3 which is a MAC frame including multiple receiver addresses used for addressing e.g. three (R#l to R#3) of the four exemplary stations 21 to 24 shown on Fig. 1.」
当審訳:
「図2によれば、例えばAP 10が図3に示されるようなMU-RTSフレームをブロードキャストすることによって送信が開始され、このMU-RTSフレームは、4つの例示的なステーション21から24のうちの例えば3つ(R#1からR#3)をアドレス指定するために使用される複数の受信機アドレスを含むMACフレームである。」

(5)第10頁第31行から第32行
「After receiving the MU-RTS frame, the selection of stations (R#1 to R#3) which are present in the receiver list reply with an M-CTS frame.」
当審訳:
「MU-RTSフレームを受信した後に、受信機リスト中に含まれる選択されたステーション(R#1からR#3)は、M-CTSフレームで応答する。」

(6)第11頁第3行から第20行
「The above procedure can be programmed as a software routine based on the following pseudo code structure:

n is the position of the station in the receiver list in MU-RTS frame
after receiving MU-RTS, wait for SIFS
while(the station still did not transmit its M-CTS)
if (n=l)
transmit M-CTS
else
if (the channel gets occupied){
wait that the channel gets free
n = n-1
wait for RIFS
}
else{
n = n-1
wait for RIFS
} 」
当審訳:
「上述の手順は、以下の擬似コード構造に基づくソフトウェアルーチンとしてプログラムされ得る。

nをMU-RTSフレーム中の受信機リストでの当該ステーションの位置とする
M-RTSを受信後、SIFSの期間待機する
while(当該ステーションがまだ自身のM-CTSを送信していない)
if (n=1)
M-CTSを送信する
else
if (チャネルが占有されている){
チャネルが解放されるのを待つ
n = n-1
RIFSの期間待機する
}
else{
n = n-1
RIFSの期間待機する
} 」

(7)第11頁第33行から第12頁第9行
「The transmitter (e.g. AP 10) receives none, some, or all of the M-CTS frames from the addressed subset of stations. From the received ones, it may read the information provided in the CAB field (or any other channel state information that could be included in M-CTS frame), and may create a MIMO frame from those packets destined only to stations which replied. This can be expressed by the following pseudo code structure:

if (# of M-CTS received > 0)
create and transmit a MIMO frame from the packets for stations that replied, optionally applying some scheduling strategy;
else
start accessing the channel for the next transmission; 」
当審訳:
「送信機(例えばAP 10)は、ステーションのうちのアドレス指定されたサブセットからのM-CTSフレームのどれも受信しないか、それらの幾つかを受信するか、又はそれらの全てを受信する。受信されたものから、それは、CABフィールド中に提供される情報(又はM-CTSフレーム中に含まれ得る任意の他のチャネル状態情報)を読んでもよく、応答したステーションにのみ宛てられたパケットからMIMOフレームを作成してもよい。これは、以下の擬似コード構造によって表現され得る。

if (受信したM-CTSの数 > 0)
応答したステーション宛てのパケットからMIMOフレームを作成し送信する、オプションとして何らかのスケジューリング戦略を適用する;
else
次回の送信のためにチャネルにアクセスする; 」

(8)上記摘記事項(7)にて摘記した擬似コード構造によって表現される部分(引用文献1の第12頁第5から9行まで)
「if (# of M-CTS received > 0)
create and transmit a MIMO frame from the packets for stations that replied, optionally applying some scheduling strategy;
else
start accessing the channel for the next transmission;」
は、if else制御文による条件分岐を記述したものであって、以下の意味であると理解できる。
〈擬似コードの意味〉
受信したM-CTSが1つでもある場合には、応答したステーション宛てのパケットからMIMOフレームを作成して送信し、オプションとして何らかのスケジューリング戦略を適用してもよく、受信したM-CTSが全く無い場合には、次回の送信のためにチャネルにアクセスする。

(9)第13頁第3行から第5行
「Additionally, other options of IEEE 802.11e, such as trasmission opportunities(TxOP), block acknowledgement(BA), or no acknowledgement may also be combined with the above procedures, so as to further improve the performance.」
当審訳:
「更なるパフォーマンスの改善に関して、追加的に、送信機会(TxOP)、ブロックアックナレッジメント(BA)、又はノーアックナレッジメント、のような、IEEE 802.11eの他のオプションも同様に上記処理手順と組み合わせることができる。」


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

[引用発明1]
「チャネルにアクセスするためのMU-RTS及びM-CTSフレームを用いることによるIEEE 802.11ベースのネットワークのマルチユーザサポートの方法であって、
四方向のハンドシェイク手順を含み、これによってデータ伝送に先立ち複数のユーザでのチャネルアクセスを支援し、
四方向のハンドシェイク手順は、
AP 10がMU-RTSフレームをブロードキャストすることによって送信が開始され、このMU-RTSフレームは、4つの例示的なステーション21から24のうちの例えば3つ(R#1からR#3)をアドレス指定するために使用される複数の受信機アドレスを含むMACフレームであり、
MU-RTSフレーム中の受信機リスト中に含まれる選択されたステーション(R#1からR#3)は、MU-RTSフレームを受信した後に、M-CTSフレームで応答し、
AP 10は、ステーションのうちのアドレス指定されたサブセットからのM-CTSフレームのどれも受信しないか、それらの幾つかを受信するか、又はそれらの全てを受信し、
受信したM-CTSが1つでもある場合には、応答したステーション宛てのパケットからMIMOフレームを作成して送信し、受信したM-CTSが全く無い場合には、次回の送信のためにチャネルにアクセスする
ことを含み、
改善されたMACフレームすなわちMU-RTSフレームは、
複数の受信側MACアドレスを持つので、通常のRTSフレームと異なり、
MU装置に対してのみ意味があり理解可能な特定のフィールドを持つが、このフレームは、レガシー物理レイヤにおいて送信されることができ、全てのレガシ装置が理解できる共通のフィールドを持つため、レガシー装置は、ビット列を復号することができ、共通のフィールドを解釈することができて、適切な設定を開始することができるものであり、対応する既存の又はレガシーMACフレームのための解釈ルールを変更する必要はない
ものである、
IEEE 802.11ベースのネットワークのマルチユーザーサポートの方法。」

3.引用文献2について
当審における平成28年3月1日付けで通知した拒絶理由にて引用した、本件の優先権主張の日前に公開された刊行物である特開2008-278483号公報(平成20年11月13日公開、以下「引用文献2」という。)には、図面とともに次の事項が記載されている。(なお、下線は当審にて付した。)

(10)第0006段落
「【0006】
IEEE802.11eEDCA規格は、トラフィックを4つのAC、すなわち音声(VO)、映像(VI)、ベストエフォート(BE)、及びバックグラウンド(BK)にグループ分けすることによって、異なるQｏSを提供している。上位層からの各送信フレームは優先値(0?7)を有し、MAC層に伝えられる。優先値に基づいて、送信フレームはMAC層において4つのACにマッピングされる。音声ACは最高の優先度を有し、映像ACは2番目に高い優先度を有し、ベストエフォートACは3番目に高い優先度を有し、バックグラウンドACは最も低い優先度を有する。各ACは、それぞれ、送信キュー及びACに影響を受けやすいメディアアクセスパラメータ、すなわち調停用フレーム間隔(AIFS)、コンテンションウィンドウ(CW、CWminm、及びCWmaｘ)、及び送信権(TXOP)を有する。トラフィックの優先順位付けは、メディアアクセスパラメータを使用して、優先度の高いACが優先度の低いACよりも相対的にメディアアクセスの機会が多くなるようにする。」

(11)第0009段落から第0012段落
「【0009】
これらメディアアクセスパラメータを使用して、EDCAは以下のように機能する。
【0010】
送信局は、何らかの送信を開始する前に、少なくともAIFS時間間隔中にチャネルが(物理的且つ仮想的に)アイドル状態であることを検出しなければならない。初期AIFS間隔後にチャネルがアイドルである場合、送信局はRTS送信を開始し、受信局からのCTS送信を待つ。
【0011】
RTS送信中にコリジョンが発生した場合、又はCTSが受信されない場合、送信局は、バックオフ手続きを呼び出し、バックオフカウンタを使用して0?CW(最初はCWminに設定される)から選択されるランダムなバックオフタイムスロットをカウントダウンする。送信局は、チャネルがアイドル状態であることを検出している限り、バックオフカウンタを一つ減算する。送信局は、バックオフ手続き中にチャネルがビジーであることを検出した場合、現在のバックオフ手続きを一時中断し、チャネルがAIFS間隔にわたってアイドル状態であることが再び検出されるまでバックオフカウンタを停止させる。そして、チャネルがAIFS間隔の後にもアイドル状態が継続した場合には、送信局は残りのバックオフカウンタの減算を再開する。
【0012】
バックオフカウンタがゼロに達すると、送信局はRTS送信を開始し、受信局からのCTS送信を待つ。RTS送信中にコリジョンが発生した場合、又はCTSが受信されない場合、送信局は、可能な場合にはCWのサイズを大きくして別のバックオフ手続きを呼び出す。すなわち、上述したように、各送信が失敗した後、CWは基本的に、CWmaｘに達するまで2倍になる。送信成功後、CWはデフォルト値であるCWminに戻る。トランザクション中、無線局は、合計送信時間がTXOP持続時間を超えない限り、競合することなく複数のフレーム送信を開始することができる。」

4.引用文献2から把握できる周知技術について
IEEE 802.11e EDCA規格が周知であることを踏まえると、引用文献2の記載には、次の周知技術(以下、「周知技術1」という。)が記載されていると認められる。

[周知技術1]
「IEEE 802.11e EDCA規格における技術であって、
送信局は、何らかの送信を開始する前に、少なくともAIFS時間間隔中にチャネルが(物理的且つ仮想的に)アイドル状態であることを検出し、初期AIFS間隔後にチャネルがアイドルである場合、送信局はRTS送信を開始し、受信局からのCTS送信を待ち、
CTSが受信されない場合、送信局は、バックオフ手続きを呼び出し、バックオフカウンタを使用して0?CW(最初はCWminに設定される)から選択されるランダムなバックオフタイムスロットをカウントダウンし、
バックオフカウンタがゼロに達すると、送信局はRTS送信を開始し、受信局からのCTS送信を待つ、
というように機能するIEEE 802.11e EDCA規格における技術。」


第4.対比

1.本件発明と引用発明1との対比
本件発明と引用発明1とを対比する。

(1)引用発明1の「ステーション」及び「MU装置」は、本件発明の「宛先装置」に相当する。

(2)引用発明1の「MU-RTSフレーム」及び「改善されたMACフレーム」は、本件発明の「メッセージ」に相当する。

(3)引用発明1の「四方向のハンドシェイク手順」におけるRTSとCTSのやり取りは、AP 10とステーションとがMU-RTSフレームとM-CTSフレームとを交換するものであるから、本件発明の「第1の交換」に相当する。

(4)引用発明1の「四方向のハンドシェイク手順」におけるRTSとCTSのやり取りは、「AP 10がMU-RTSフレームをブロードキャストすることによって送信が開始され、このMU-RTSフレームは、4つの例示的なステーション21から24のうちの例えば3つ(R#1からR#3)をアドレス指定するために使用される複数の受信機アドレスを含む」ものであるから、引用発明1と本件発明とは、「複数の宛先装置のうちの少なくとも一宛先装置との第1の交換を開始するステップであって、前記複数の宛先装置のうちの少なくとも一宛先装置にメッセージを送信するステップを含む、ステップ」を含む方法である点で一致する。

(5)引用発明1の「M-CTSフレーム」は、「四方向のハンドシェイク手順」におけるRTS送信の結果としてAP 10が得るものであるから、AP 10が受信した「M-CTSフレーム」の数は、本件発明の「第1の交換の結果」に相当する。

(6)引用発明1の「MIMOフレームを作成して送信」することは、MIMOフレームがステーションすなわちMU装置宛てであることから、本件発明の「マルチユーザマルチ入力マルチ出力(MU-MIMO)無線データ送信」に相当する。

(7)引用発明1は、AP 10が受信したM-CTSフレームが1つでもあるか否かに基づいて、MIMOフレームを作成して送信するか、次回の送信のためにチャネルにアクセスするかを選択しているのであるから、引用発明1と本件発明とは、「前記第1の交換の結果に基づき、複数の宛先装置のうちの少なくともいくつかの宛先装置にマルチユーザマルチ入力マルチ出力(MU-MIMO)無線データ送信をするか他の動作をするか選ぶステップ」を有する点で一致する。

2.一致点について
したがって、本件発明と引用発明1とは、以下の点で一致する。

[一致点]
「1つ又は複数の宛先装置のうちの少なくとも一宛先装置との第1の交換を開始するステップであって、前記1つ又は複数の宛先装置のうちの少なくとも一宛先装置にメッセージを送信するステップを含む、ステップと、
前記第1の交換の結果に基づき、前記1つ又は複数の宛先装置のうちの少なくともいくつかの宛先装置にマルチユーザマルチ入力マルチ出力(MU-MIMO)無線データ送信をするか他の動作をするか選ぶステップとを有する方法。」

3.相違点について
一方、本件発明と引用発明1は、以下の点で相違する。

[相違点1]
本件発明は、「複数の宛先装置のうちの1つ又は複数の宛先装置を選択するステップ」を有するのに対し、引用発明1は1つ又は複数の宛先装置を複数の宛先装置から選択しているか否かが明確ではない点。

[相違点2]
本件発明は、第1の交換の結果に基づいて、MU-MIMO無線データ送信をするか、第2の交換が開始される前の時間を含むバックオフ時間に入るかを選んでいるのに対し、引用発明1では、第1の交換の結果に基づいて、MU-MIMO無線データ送信をするか他の動作をするか選ぶものの、他の動作として、第2の交換が開始される前の時間を含むバックオフ時間に入ることについて言及がない点。


第5.当審の判断

1.[相違点1]について
引用発明1のMU-RTSフレームは、4つの例示的なステーション21から24のうちの例えば3つ(R#1からR#3)をアドレス指定するために使用される複数の受信機アドレスを含んでおり、このMU-RTSに応答してM-CTSフレームを送信するステーションは、このMU-RTSフレーム中の受信機リスト中に含まれる選択されたステーション(R#1からR#3)である。つまり、引用発明1は、MU-RTSフレーム中に宛先となる3つステーションのアドレスが存在しており、MU-RTSフレームを受け取ったステーションは、自身のアドレスがMU-RTSフレームに含まれているか否かによって、MU-RTSフレームが自身に宛てられたものであるか否かを判断し、自身に宛てられた場合には、M-CTSフレームを返送し、自身に宛てられていない場合には、M-CTSフレームを返送しないものである。以上から、MU-RTSフレームの送信は、物理レイヤの観点からはブロードキャストであるが、MACレイヤの観点では、指定された宛先にのみ送信されるマルチキャストであると理解できる。
してみると、AP 10がMU-RTSフレームを送信する時点よりも前に、4つあるステーションのうちから宛先となる3つのステーションが何らかの方法によって選択されていなければならないことは、明らかである。
したがって、引用発明1において、MU-RTSフレームを送信する前に、複数のステーションを選択するステップを設けることは、当業者の通常の創作能力の発揮に過ぎず、格別のことではない。

2.[相違点2]について
上記した周知技術1は、IEEE 802.11eのEDCA規格における技術であって、送信局は、送信に先立ってチャネルがアイドル状態であることを検出し、チャネルがアイドルである場合、RTS送信を開始し、受信局からのCTS送信を待ち、CTSが受信されない場合、バックオフ手続きを呼び出し、バックオフカウンタを使用して0?CWから選択されるランダムなバックオフタイムスロットをカウントダウンし、バックオフカウンタがゼロに達すると、再びRTS送信を開始し、受信局からのCTS送信を待つ、というものである。
これは、最初のRTS送信においてCTSが受信できない場合、その回でのデータ送信をあきらめ、次回の送信に備えてバックオフ手続きに入る動作であると理解できる。また、バックオフ手続きではバックオフタイムスロットがゼロに達すると、再びRTS送信を開始することから、バックオフ手続きのバックオフタイムスロットは、再びRTS送信を開始する前の時間で設定されるといえる。
してみると、当該周知技術1における、最初のRTS送信からCTSが受信できないと判断するまでの一連の動作は、本件発明における「第1の交換」に相当し、当該周知技術1における、再びRTS送信を行いCTS送信を待つという一連の動作は「第2の交換」に相当する。また、当該周知技術1のバックオフタイムスロットは、再びRTS送信を行うという動作の前の時間で設定されるから、本件発明のように「第2の交換が開始される前の時間を含む」ものである。
このことから、当該[相違点2]に係る「第1の交換の結果に基づいて、第2の交換が開始される前の時間を含むバックオフ時間に入る」という技術的事項は、当該周知技術1の有する技術的事項であるといえる。

そして、引用発明1の改善されたMACフレームすなわちMU-RTSフレームは、通常のRTSフレームと異なり、MU装置に対してのみ意味があり理解可能な特定のフィールドを持つが、レガシー物理レイヤにおいて送信されることができ、全てのレガシ装置が理解できる共通のフィールドを持つため、レガシー装置は、ビット列を復号することができ、共通のフィールドを解釈することができて、適切な設定を開始することができるものであり、対応する既存の又はレガシーMACフレームのための解釈ルールを変更する必要はないものである(「第3.引用文献について」「1.引用文献1の記載」の摘記事項(1)を参照)。
ここで、引用発明1がIEEE 802.11ベースのネットワークのマルチユーザサポートであることから、引用発明1のMU-RTSフレームは、周知のIEEE 802.11ベースのRTSフレームに対して後方互換性を有さねばならず、MU-RTSフレームに関係するプロトコルも、周知のIEEE 802.11ベースの規格に対して後方互換性を有さなければならないことは明らかである。
加えて、「第3.引用文献について」「1.引用文献1の記載」の摘記事項(9)にもあるように、引用文献1では、IEEE 802.11eの他のオプションも処理手順に組み合わせることができる旨の示唆もある。

そうすると、引用発明1における、M-CTSが受信されなかった場合に、次回の送信のためにチャネルにアクセスするという動作を具体化するために、IEEE 802.11eのEDCA規格の上記周知技術1を採用することで、バックオフ手続きに入ってバックオフ時間を待った後、再びRTS送信を開始し、CTS送信を待つようにすることは、当業者が容易に想到し得ることである。

3.効果について
また、本件発明の構成によってもたらされる効果は、引用発明1及び周知技術1より当業者であれば容易に予測することができる程度のものである。

4.まとめ
よって、本件発明は、引用発明1及び周知技術1に基づいて、当業者が容易に発明をすることができたものである。


第6.むすび
以上のとおり、本件発明は、引用文献1に記載された引用発明1及び周知技術1に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

したがって、本願のその余の請求項に係る発明について検討するまでもなく、本願は拒絶されるべきものである。

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


第7.その他
なお、平成28年6月7日提出の意見書において、審判請求人が主張している下記事項についても言及しておく。

1.意見書「D.(2)」(周知技術1の「バックオフ手続き」は、本件発明の「バックオフ時間は第2の交換が開始される前の時間を含む」ものではない、とする点)について

審判請求人は、意見書にて、「前記バックオフ時間は第2の交換が開始される前の時間を含むステップ」との補正は、図5-12及び図13等の記載に基づき、当初明細書等に記載した事項の範囲内にあります。」とした上で、周知技術1の「「バックオフ手続き」は、「バックオフ時間は第2の交換が開始される前の時間を含む」ものではないと思料いたします。」と主張する。

そこでまず、「第2の交換」について検討する。
本願明細書等には「第2の交換」についての直接的な記載は無い。また、補正の根拠として挙げている図5-12及びそれに関連する明細書の記載には「第2の交換」といえる構成を見出せない。
一方で、図13には、交換の結果に基づいて(ブロック1308)、バックオフ時間だけ待った後(ブロック1312)、再度交換を始める(ブロック1306)という流れが記載されていることから、「第2の交換」とは、図13におけるブロック1308からブロック1312を経た上で実行される、ブロック1306を意味すると解される。

そうすると、「第5.当審の判断」「2.[相違点2]について」にて既に述べたように、周知技術1における、再びRTS送信を行いCTS送信を待つという一連の動作は、本件発明の「第2の交換」に相当し、周知技術1の「バックオフタイムスロット」は、この再びRTS送信を行うことによる一連の動作より前の時間を含む時間で設定されるから、本件発明の「バックオフ時間」のように「第2の交換が開始される前の時間を含む」ものといえる。

よって、周知技術1の「バックオフ手続き」は本件発明の「バックオフ時間は第2の交換が開始される前の時間を含む」ものではないとする出願人の主張は採用できない。

2.意見書「D.(3)」(当業者は引用発明1に周知技術1を採用することを想到しない、とする点)について

審判請求人は、意見書にて、「引用文献1に記載された発明の目的は、「レガシー装置及び手順の変更をあまり必要としない、より柔軟なマルチユーザ伝送スキームを提供すること」(段落0016)です。
したがって、『引用文献1において、M-CTSが受信されなかった場合の、次回の送信のためにチャネルにアクセスするという動作を、IEEE 802.11e規格に対する後方互換性の観点から、引用文献2に記載されたようなIEEE 802.11eのEDCA規格に準拠するよう、バックオフ手続きに入ってバックオフ時間を待つ動作とする』と、引用文献1に記載された発明の目的が達成できなくなるため、当業者は引用文献1に記載された発明に、かかる変更を行うことには想到しないと思料いたします。」と主張する。

まず、引用文献1には段落0016はないが、審判請求人は、引用文献1の次の記載に言及していると思われる。

第6頁第2行から3行
「It is an object of the present invention to provide a more flexible multi-user transmission scheme which requires less modifications of legacy devices and procedures.」
当審訳:
「この発明の目的は、レガシー装置及び手順の変更をあまり必要としない、より柔軟なマルチユーザ伝送スキームを提供すること」

しかしながら、なぜ引用発明1に周知技術1を適用すると、この目的が達成できなくなるのか意見書の記載からは把握できない。
引用発明1は、このような目的のために、IEEE 802.11ベースのネットワークのマルチユーザサポートのための拡張を提供するものであること(「第3.引用文献について」「1.引用文献1の記載」の「摘記事項(2)」参照)を踏まえると、IEEE802.11ベースのネットワークであるIEEE 802.11eの技術に関する周知技術1を適用することで、IEEE 802.11eベースのマルチユーザサポートのための拡張を提供することができることは明らかであって、発明の目的である、レガシー装置及び手順の変更をあまり必要としない、より柔軟なマルチユーザ伝送スキームを提供すること、と何ら矛盾しないと思料する。
加えて、IEEE 802.11eと組み合わせることについての示唆(「第3.引用文献について」「1.引用文献1の記載」の「摘記事項(9)」参照)があることも勘案すると、引用発明1に周知技術1を組み合わせることに何ら阻害要因を発見しない。

よって、当業者は引用発明1に周知技術1を適用することを想到しない、とする審判請求人の主張についても採用できない。
 
審理終結日 2016-07-12 
結審通知日 2016-07-19 
審決日 2016-08-01 
出願番号 特願2013-519871(P2013-519871)
審決分類 P 1 8・ 121- WZ (H04W)
最終処分 不成立  
前審関与審査官 冨永 達朗、米倉 明日香、伊東 和重  
特許庁審判長 佐藤 智康
特許庁審判官 吉田 隆之
古市 徹
発明の名称 マルチユーザ伝送のためのメディアアクセス手法  
代理人 伊東 忠彦  
代理人 伊東 忠重  
代理人 大貫 進介  

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