• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 2項進歩性  H04W
審判 全部申し立て 1項3号刊行物記載  H04W
管理番号 1368128
異議申立番号 異議2020-700474  
総通号数 252 
発行国 日本国特許庁(JP) 
公報種別 特許決定公報 
発行日 2020-12-25 
種別 異議の決定 
異議申立日 2020-07-13 
確定日 2020-11-10 
異議申立件数
事件の表示 特許第6630559号発明「無線通信システム」の特許異議申立事件について、次のとおり決定する。 
結論 特許第6630559号の請求項1及び2に係る特許を維持する。 
理由 第1 手続の経緯
特許第6630559号の請求項1及び2に係る特許についての出願は,平成27年12月11日に出願され,令和1年12月13日にその特許権の設定登録がされ,令和2年1月15日に特許掲載公報が発行された。その後,その特許に対し,令和2年7月13日に特許異議申立人小倉啓七が,令和2年7月14日に特許異議申立人奥野宏美が,それぞれ特許異議の申立てを行い,令和2年8月21日に特許異議申立人小倉啓七は手続補正書(方式)を提出した。

第2 本件発明
特許第6630559号の請求項1及び2の特許に係る発明は,それぞれ,その特許請求の範囲の請求項1及び2に記載された事項により特定される次のとおりのものである。
「【請求項1】
受信機が送信機に向けて周期的にRIT Data Request Frameの送信を試みるRIT方式の通信を行う無線通信システムであって,
前記受信機は,
前記送信機に対して前記RIT Data Request Frameを送信した後,所定期間,受信待受状態となる受信側制御部を備え,
前記送信機は,
送信対象となるデータである対象データがあれば受信待受状態となり,受信待受状態において前記受信機から前記RIT Data Request Frameを受信すると,該対象データを該受信機に送信する送信側制御部を備え,
前記受信側制御部は,
前記RIT Data Request Frameの送信前に,送信に利用する周波数帯域の受信待受状態に移行することで該周波数帯域の受信電波強度を測定するキャリアセンスを行い,該周波数帯域の受信電波強度が閾値を超えていると,該受信待受状態を継続せずに該受信待受状態を解除し,今回のRIT Data Request Frameの送信を中止し,次回のRIT Data Request Frameの送信タイミングまで,該キャリアセンスを休止し,
前記送信側制御部は,
前記RIT Data Request Frameを受信した後,前記対象データを送信する前に,該RIT Data Request Frameに示される前記受信機のアドレス情報を前記対象データとは別個のフレームで該受信機に送信し,
前記受信側制御部は,
受信待受状態において自機のアドレス情報を受信した場合にのみ,続いて送信された,自機のアドレス情報が格納されたフレームとは別個のフレームに格納された前記対象データを受信することを特徴とする無線通信システム。
【請求項2】
前記受信側制御部は,
アドレス情報として前記受信機のアドレス情報のみが含まれる前記RIT Data Request Frameを前記送信機に対して送信することを特徴とする請求項1に記載の無線通信システム。」

第3 特許異議申立人小倉啓七の特許異議の申立てについて
1.申立理由の概要
特許異議申立人小倉啓七は,下記の甲第1ないし3号証を提出し,請求項1に係る発明は,甲第1号証に記載された発明であって,特許法第29条第1項第3号に該当するから,請求項1に係る特許は,特許法第29条第1項の規定に違反してされたものであり,また,請求項1に係る発明は,甲第1号証に記載された発明と甲第2号証に記載された発明とに基いて,当業者が容易に発明することができたものであるから,請求項1に係る特許は,特許法第29条第2項の規定に違反してされたものであり,更に,請求項2に係る発明は,甲第1号証に記載された発明と甲第2号証に記載された発明と甲第3号証に記載された発明とに基いて,当業者が容易に発明することができたものであるから,請求項2に係る特許は,特許法第29条第2項の規定に違反してされたものである。よって,請求項1及び2に係る特許を取り消すべきものである旨主張する。
また,甲第1号証が,特許第6630559号の出願前に公知であったことを示すものとして,下記の甲第4ないし7号証を提出している。
甲第1号証:Uバスエア(メッシュ方式)通信仕様書 研究部会事務局(案)ver.2.0,NPO法人テレメータリング推進協議会
甲第2号証:特開2010-28175号公報
甲第3号証:国際公開第2008/136446号
甲第4号証:「Wi-SUNベースの次世代ガス・スマートメータリングシステムの標準規格「U-Bus/U-Bus Air」」
https://sgforum.impress.co.jp/article/1369?page=0%2Cl
甲第5号証の1:「NPO法人テレメータリング推進協議会」の仕様書ダウンロードページ(その1)https://teleme-r.or.jp/u-bus-j/index.php/specific/
甲第5号証の2:「NPO法人テレメータリング推進協議会」の仕様書ダウンロードページ(その2)https://teleme-r.or.jp/u-bus-j/index.php/specific/download_gas/
甲第6号証:特開2015-188171号公報
甲第7号証:藤原純,ガススマートメータ用低消費電力通信プロトコルに関する研究,京都大学

2.甲第1号証の公知性
特許異議申立人小倉啓七は,甲第1号証の公知性について,「3 申立ての理由」の「(4)具体的理由」の「ウ」において「甲第5号証の1及び甲第5号証の2は,NPO法人テレメータリング推進協議会の仕様書ダウンロードページであり,甲第5号証の1の2頁目の記載に従って取得したパスワードを用いれば,甲第5号証の2に一覧表示された各仕様書等を誰もがダウンロードすることができる。この中には,上記「Uバスエア(多段中継無線)通信仕様書Ver.2.0」が表記されており,これを選択することで実際にダウンロードしたものが甲第1号証(「Uバスエア(メッシュ方式)通信仕様書研究部会事務局(案)Ver.2.0」)である。」と主張している。
ここで,甲第5号証の1には,仕様書をダウンロードするにあたり,同意書に同意する必要があることが記載されており,甲第5号証の1の「NPO法人テレメータリング推進協議会」の仕様書ダウンロードページ(その1)からダウンロードすることができる当該同意書には,第3条において,仕様書をダウンロードおよび閲覧を行う個人または法人に対し,秘密保持義務が生じることが記載されている。
そうすると,甲第1号証をダウンロード及び閲覧する個人または法人は秘密保持義務を負っているから,甲第1号証に記載された発明は,不特定多数の者が見得るような状態におかれているとはいえず、「頒布された刊行物に記載された発明」とは認められない。よって、甲第1号証に記載された発明は,特許法第29条第1項第3号による「頒布された刊行物に記載された発明」ではない。
さらに,甲第5号証の1によれば,仕様書は,テレメータリング推進協議会より発行されたパスワードを使用してダウンロードすることができるものであるが,ダウンロードする個人または法人は秘密保持義務を負っているから,甲第1号証が不特定多数の者である「公衆に利用可能になった」とはいえない。よって,甲第1号証に記載された発明は,特許法第29条第1項第3号による「電気通信回線を通じて公衆に利用可能となった発明」でもない。
また,特許異議申立人小倉啓七は,甲第1号証の公知性について,甲第4,6及び7号証を用いた主張もしているが,甲第4,6及び7号証には,単に甲第1号証の文献名が記載されているだけなので,甲第4,6及び7号証から,甲第1号証に記載された発明が「頒布された刊行物に記載された発明」又は「電気通信回線を通じて公衆に利用可能となった発明」であるとも認められない。
よって,甲第1号証は,請求項1に係る発明が特許法第29条第1項3号に該当するか否かを判断する証拠として採用することはできない。また、請求項1に係る発明及び請求項2に係る発明が特許法第29条第2項の規定に違反してなされたものであるか否かを判断する証拠としても採用することはできない。

3.小活
以上のとおり,甲第1号証は証拠として採用することはできないから,甲第1号証ないし甲第3号証の記載内容を検討するまでもなく,特許異議申立人小倉啓七の特許異議の申立ての理由によっては,請求項1及び2に係る特許を取り消すことはできない。

第4 特許異議申立人奥野宏美の特許異議の申立てについて
1.申立理由の概要
特許異議申立人奥野宏美は,甲第1号証として,特開2015-211373号公報を提出し,甲第2号証として,特開2015-195506号公報を提出し,甲第3号証として,特開2009-010703号公報を提出し,甲第4号証として,特開2008-103896号公報を提出し,甲第5号証として,国際公開第2008/136446号を提出し,また,申立ての理由において,周知技術を示す文献として、国際公開第2014/119284号(以下,「文献1」という。)及び特開2008-271382号公報(以下,「文献2」という。)を挙げ,請求項1に係る発明は甲第1号証に記載された発明と甲第2号証に記載された発明及び甲第3号証及び甲第4号証に例示される周知技術に基いて,当業者が容易に発明することができたものであるから,請求項1に係る特許は,特許法第29条第2項の規定に違反してされたものであり,請求項2に係る発明は甲第1号証に記載された発明と甲第2号証に記載された発明と甲第5号証に記載された発明及び甲第3号証及び甲第4号証に例示される周知技術とに基いて,当業者が容易に発明することができたものであるから,請求項2に係る特許は,特許法第29条第2項の規定に違反してされたものである。よって,請求項1及び2に係る特許を取り消すべきものである旨主張する。

2.甲各号証等の記載
(1)甲第1号証について
甲第1号証として提出された特開2015-211373号公報には,以下の事項が記載されている。(下線は,当審で付した。)

「【0015】
(1)ネットワーク構成
ネットワークの構成例を図1に示す。図1に示したネットワークは無線で通信する基地局(001)と複数のランクをもつ階層化された端末(002a?002e)から構成される。なお,符号を括弧で囲って記載する。このネットワークは複数の端末から基地局へ伝送する上り通信,及び基地局から各端末へ伝送する下り通信を対象としている。」

「【0017】
(2)上り通信の制御
下位の端末が上位の端末へ伝送する際のシーケンス例を図2に示す。特定の無線チャンネルを使用してランク2の端末(002c)と端末(002d)がデータをランク1の端末(002a?002b)に送信する場合である。全ての端末は定期的にRITリクエストをブロードキャスト(アドレス)で送信する。端末(002c)と端末(002d)はランク1の端末(002a)からのRITリクエストを受信する。データ送信を予定しているランク2の端末(002c?002d)は、RITリクエストを受信した後、所定の時間キャリアセンスを行い、他からの無線信号が検出されない場合すなわち無線チャンネルがアイドルの場合にデータ送信を行う。キャリアセンスを行う時間は、各端末で異なる値になるように設定する。例えば、その都度ランダムの値にしてもよい。また、RITリクエストの信号強度に反比例した値を利用してもよい。
【0018】
図2の例では、キャリアセンス時間が端末(002c)より端末(002d)の方が長く設定されており、その結果、端末(002c)がデータ送信することに成功している。ランク1の端末(001a)ではRITリクエスト信号を送信後に受信待ち受けに入り、端末(002c)からのデータを受信し、無事に受信した場合はACK(確認信号)を端末(002c)に送信する。これにより、端末(002c)はランク1にデータ送信することに成功する。
【0019】
一方、端末(002d)はデータをランク1へ送信することに失敗した。この場合、次のRITリクエストを受信するのを待つ。図2の例では、ランク1の他の端末(002b)からのRITリクエスト信号を受信し、同様のシーケンスでデータ送信を行う。
【0020】
RITリクエストは図3に示すように周期的に送信され,その周期(T)及び送信タイミング(S),周期(T)内の送信回数(N)は下位ランクの端末(002)に共有される。1つの周期(T)はいわゆるスーパーフレームである。このようにRITリクエスト信号の送信されるタイミングが決まっているため,RITリクエスト信号が送信されるタイミング直前に受信待ち受け状態に入る動作を可能にし,それまではスリープさせておき,消費電力を低減することができる。また,全体の周期を分割して,各ランクにRITリクエストを送信する期間を割り当て,更に各ランクの期間を分割して各端末(002)へタイムスロットを割り当てることにより,RITリクエスト信号の衝突を防ぐことができる。図3の例では,周期の最初はランク2の各端末,次にランク1の各端末,最後に基地局のRITリクエスト送信タイミングに割り当てている。また,図3の例では,周期中,各端末に2回RITリクエストの送信を許可されている。」

「【0025】
図30はRITリクエスト信号のフレーム構成例を示す図である。RITリクエスト信号のフレーム(パケット)は一般的な無線フレーム(無線パケット)の物理層ヘッダとMACヘッダに加えてRITヘッダとRITリクエスト信号情報を有する。物理層ヘッダは無線フレームの復調に必要な情報を有する。MACヘッダは無線フレームのあて先アドレスを有し、RITリクエスト信号においては既に説明したようにブロードキャストのアドレスである。また、無線フレームを送信した送信元アドレスとその他フレーム識別に必要な情報を有する。RTIヘッダはフレームのデータタイプここではRITリクエストというデータタイプと送信元のランク情報を有する。」

「【0028】
(3)下り通信
基地局(001)からの下り通信のシーケンス例について図5を用いて説明する。下り通信においても,図2で説明したシーケンスと同様な手順を用いる。ただし,下り通信の場合のルーティング情報は,明確なルーティング情報を持たない(特定のルーティングに固定しない)上り通信と異なり,パケット内にルーティング情報が格納される。下り通信のルーティング情報は上り通信の受信の統計的情報に基づいて決定される。
【0029】
図5では,基地局(001)からランク2の端末(002d)にデータ伝送する例を示している。ランク1の端末(002b)を経由する場合,端末(002b)からのRITリクエストの受信を待って,データ送信する。例えば基地局(001)での端末(002d)からの転送に端末(002b)経由の回数が多い場合は端末(002b)経由の通信実績があるとして端末(002b)経由に決定してもよい。受信した端末(002b)は,ランク2のあて先端末(002d)からのRITリクエストの受信を待って,データ送信する。以上の動作により,下り通信を可能とする。
【0030】
なお,下位ランクの端末の送信タイミング(S)は上位ランクの端末に共有されないため,基地局(001)は周期(T)のランク1の割り当て期間の先頭からスリープせずに受信を開始し,ランク1の端末(002b)は周期(T)のランク2の割り当て期間の先頭からスリープせずに受信を開始し,それぞれ送信先となる端末のRITリクエスト信号を受信する。また,後述するように基地局(001)は伝送すべきデータが用意できた時点から受信を開始し,ランク1の端末(002b)は基地局(001)から伝送すべきデータを受信した時点から受信を開始してもよい。」

「【0034】
(4)端末及び基地局の構成
以上で説明した制御を行なうための端末(002)の構成例を図6に示す。ただし,図6及び以降の図を用いて説明する構成は,専用ハードウェア,FPGA,及びプロセッサ上のソフトウェア等,いずれのものを用いても実装可能であり,実装の形態を限定するものでない。
【0035】
端末(002)は,送受信部(011),通信制御部(012),アプリケーション部(017),電源管理部(018),イベントスケジューラ(019)で構成される。さらに通信制御部(012)は,MAC制御部(013),上りバッファ部(014),下りバッファ部(015),NW制御部(016)で構成される。」

「【0040】
以降,図8?図18のフローチャートを用いて,端末(002)の通信制御部(012)の動作を説明する。図8は通信制御部(012)の状態遷移の例を示したものである。電源投入後,ネットワーク未接続状態(C001)とネットワーク接続状態(C002)の状態がある。ネットワーク未接続状態(C001)からネットワーク接続状態(C002)からの遷移は,基地局(001)からネットワーク接続許可が得られた場合に行われる。逆に,RITリクエスト信号が所定の条件で受信されなくなった場合,ネットワーク未接続状態(C001)に遷移する。なお,ここでのネットワーク接続とは図2?5を用いて説明したRITリクエスト信号に基づく通信動作に参加することであり,ネットワーク未接続状態(C001)であっても基地局(001)からの接続許可の通信等は可能である。」

「【0044】
図11は端末(002)のネットワーク接続状態(C002)におけるMAC制御部(013)の動作例を示す図である。端末(002)は間欠動作を行うため,イベントが発生するまでスリープを行う(S031)。イベントには,基地局から与えられた送信タイミングで与えられるRITリクエスト送信イベント(S033),上り送信データが存在する場合に上位ランクの端末からのRITリクエストを受信するRITリクエスト受信イベント(S034),NW制御部(016)からの上りデータが登録される上りバッファ登録イベント(S035),NW制御部(016)からの下りデータが登録される下りバッファ登録イベント(S036)がある。以下,図12?図16を用いて各イベント時の動作例について説明する。なお,各動作例において処理を終了するとスリープの状態へ移行する。
【0045】
図12はRITリクエスト送信イベント時の動作例を示す図である。まず所定のタイミングでRITリクエストを,キャリアセンスを行った後に送信をする(S041)。RITリクエスト送信後,受信待ち受けに入る(S042)。データ受信された場合(S043),ACKを送信し(S044),NW制御部(016)へ受信されたデータを転送する(S045)。所定の時間が経過してもデータ受信されない場合(S043),そのまま終了する。」

「【0049】
図15は,下りバッファ登録イベント時の動作例を示したものである。下りバッファ(015)にNW制御部(016)からデータが登録された時,ただちに受信待ち受けに入り,所望の端末からのRITリクエストの受信を待つ(S081)。所望の端末からRITリクエストが所定時間受信されなかった場合,タイムアウトとして下りバッファからデータをクリアする(S085)。所望の端末から受信された場合,図14で示したシーケンスによりデータ送信を行う(S006)。送信が成功した場合,下りバッファから送信したデータをクリアし送信成功として終了する(S084)。送信が成功しなかった場合,受信待ち受け(S081)に戻る。上位ランク端末からRITリクエストを受信した場合,図13で示したのと同様のシーケンスで,上りバッファ(014)にデータがある場合にデータ送信を行う(S086?S089)。また,所望の端末及び上位ランク端末以外の端末から受信した場合は,受信待ち受け(S081)に戻る。」

上記記載及び当業者における技術常識から以下のことがいえる。

ア 甲第1号証の段落[0015]によれば,無線で通信する基地局と複数の端末を含んで構成されるネットワークは,「無線通信ネットワーク」といえ,甲第1号証の段落[0029],[0045],[0049]によれば,データを受信する端末からデータを送信する端末にRITリクエストが送信されているから,ネットワークは,「データを受信する端末からデータを送信する端末に向けてRITリクエストが送信される通信を行う」ものである。
また,甲第1号証の段落[0020]によれば,RITリクエストは,「周期的に」送信される。
そうすると,甲第1号証のネットワークは,「データを受信する端末からデータを送信する端末に向けて周期的にRITリクエストが送信される通信を行う無線通信ネットワーク」であるといえる。

イ 甲第1号証の段落[0035]によれば,端末は「通信制御部」を備えており,甲第1号証の段落[0040],[0045]によれば,端末の通信制御部は,「RITリクエストを送信した後,所定の時間,受信待ち受けに入る」といえる。
また,段落[0029],[0045],[0049]によれば,RITリクエストは「データを受信する端末」から,「データを送信する端末に対して」送信される。
そうすると,甲第1号証では,「データを受信する端末は,データを送信する端末に対してRITリクエストを送信した後,所定の時間,受信待ち受けに入る通信制御部を備え」ているといえる。

ウ 甲第1号証の段落[0035]によれば,端末は「通信制御部」を備えており,甲第1号証の段落[0040],[0049]によれば,端末の通信制御部は,「下りバッファにデータが登録された時,受信待ち受けに入り,所望の端末からRITリクエストを受信すると,下りバッファからデータ送信を行う」といえる。また,当該端末は,データ送信を行うのであるから,「データを送信する端末」である。
そうすると,甲第1号証では,「データを送信する端末は,下りバッファにデータが登録された時,受信待ち受けに入り,所望の端末からRITリクエストを受信すると,下りバッファからデータ送信を行う通信制御部を備え」ているといえる。

エ 甲第1号証の段落[0040],[0045]によれば,「データを受信する端末の通信制御部」は,「RITリクエストの送信前に,キャリアセンスを行い」,RITリクエストを送信する。

オ 甲第1号証の段落[0040],[0049]によれば,「データを送信する端末の通信制御部は,RITリクエストを受信した後,データを送信し」ている。

カ 甲第1号証の段落[0040],[0045]によれば,「データを受信する端末の通信制御部は,受信待ち受けにおいて,送信されたデータを受信する」ものといえる。

以上を総合すると,甲第1号証には,次の発明(以下,「甲1発明」という。)が記載されていると認められる。

「 データを受信する端末からデータを送信する端末に向けて周期的にRITリクエストが送信される通信を行う無線通信ネットワークであって,
データを受信する端末は,データを送信する端末に対してRITリクエストを送信した後,所定の時間,受信待ち受けに入る通信制御部を備え,
データを送信する端末は,下りバッファにデータが登録された時,受信待ち受けに入り,所望の端末からRITリクエストを受信すると,下りバッファからデータ送信を行う通信制御部を備え,
データを受信する端末の通信制御部は,
RITリクエストの送信前に,キャリアセンスを行い,
データを送信する端末の通信制御部は,RITリクエストを受信した後,データを送信し,
データを受信する端末の通信制御部は,受信待ち受けにおいて,送信されたデータを受信する
無線通信ネットワーク。」

(2)甲第2号証について
甲第2号証として提出された特開2015-195506号公報には,以下の事項が記載されている。

「【0036】
図7(a)に,無線端末X12における中継段数テーブル13の内容を,図7(b)には,無線端末X12が保持する未転送端末情報を示す。無線端末X12は,宛先である無線端末X11に隣接するため,通信データを受信すると,未転送端末情報を参照して同時転送を実行する。無線端末X12は,図7(b)に示すように,隣接する(論理中継数が1の)無線端末Xのうち未転送状態である無線端末X(X11,X13,X14,X15)を送信対象として同時転送を行う。
【0037】
図8に,同時転送時のシーケンスを示す。無線端末X12は,パケット送受信制御装置10により同時転送の実行が要求されると,あらかじめ設定された同期待ち時間の間(図中「同期ビーコン待ち」で示す間),他の無線端末Xからのビーコン信号を待ち受けられるようにアクティブな状態に設定される。他の無線端末X(X11)からビーコン信号を受信すると,通信データの送信を開始する旨を知らせる「転送要求」通知を送信した後,続けて通信データ(図中「転送データ」)を送信する。無線端末X11は,通信データを受信し終えると,通信データの受信を終えた旨を知らせる「転送完了」通知を送信し,無線端末X12は,「転送完了」通知を受信したことをもって無線端末X11とのセッションを終了する。同様にして,無線端末X12は,他の無線端末X(X13,X14,X15)に通信データを送信し,未転送状態の無線端末Xがなくなると,ビーコンの受信を中断し,同時転送を終了する。」

(3)甲第3号証について
甲第3号証として提出された特開2009-010703号公報には,以下の事項が記載されている。

「【0080】
ステップS55では目的の無線端末からID通知信号(間欠送信信号)を受信したかを判定する。つまり,受信待ち状態R12となっている送信端末11bによってID通知信号P11が受信されると,送信端末11bは,ID通知信号P11に含まれる受信端末11aの識別コードに基づいて,その受信端末11aが送信相手であるかどうかを判断する。ステップS51で受信端末11a側において無線送信部13aが送信状態T11に移行され,無線送信部13aはアンテナ16aを介してID通知信号P11を送信し,受信待ち状態R12となっている送信端末11bによりID通知信号P11が受信されとステップS57に移行する。受信できないときはステップS56に移行する。上記判定はID通知信号判定部36bにより判定する。
【0081】
なお,ID通知信号P11には無線端末の識別をするための固有のコードを設定されている。本例では,受信端末11aを示す識別コードが設定されている。
ステップS56では,メモリなどに記録された(2)式を満たす受信待ち状態R12の最大待ち時間TWの間にID通知信号P11が受信されたかを判定する。TW時間の範囲内であればステップS55に移行する。TW時間外(タイムアウト)であればステップS58に移行する。
【0082】
ステップS57では,受信端末11aが送信相手であると確認された場合には,送信端末11bは送信状態T12に移行し,送信信号P12を受信端末11aに送信する。
ステップS58ではスリープ処理へ移行する。つまり,制御部12bが次の送信事象までスリープ状態になる。」

(4)甲第4号証について
甲第4号証として提出された特開2008-103896号公報には,以下の事項が記載されている。

「【0019】
また,請求項7記載の無線通信方法によれば,受信側が動作状態にあることを送信側に知らせるための間欠送信信号には受信側に固有なコードが含まれ,前記受信待ち状態において前記送信側は前記固有なコードを受信し,前記固有なコードに基づいて前記受信側が送信相手であると前記送信側で確認された場合に,前記送信側は前記受信側にデータを送信することを特徴とする。
これにより,送信側は間欠送信信号を受信側から受信することで,受信側が動作状態にあるかどうかだけでなく,その受信側が今回のデータの送信相手であるかどうかも併せて確認することができ,空間のチャンネルを有効活用しつつ,データが無駄な送信相手に送信させるのを防止することができる。」

(5)甲第5号証について
甲第5号証として提出された国際公開第2008/136446号(特許異議申立人小倉啓七が提出した甲第3号証)には,以下の事項が記載されている。

「[0143] 無線通信端末100は,無線基地局200に送信されるデータフレームの送信先MACアドレスがブロードキャストアドレスであるか否かを判定し,ブロードキャストアドレスである場合には当該送信先MACアドレスの送信を省略するとともに,BCフラグに1を設定する。これにより,送信先MACアドレスがブロードキャストアドレスであっても,送信先MACアドレスを省略可能となる。したがって,ブロードキャストアドレスの送信に代えて,ゲートウェイ500宛てのユーザデータを送信することによって,ユーザデータのスループットを向上させることができる。」

(6)文献1について
申立ての理由において挙げられた文献1(国際公開第2014/119284号)には,以下の事項が記載されている。

「[0005] また,検針用通信端局は,パケットの送信前に,利用チャネルが空き状態であるか否かを検出するため,キャリアセンスを行う。検針用通信端局は,キャリアセンスによって利用チャネルが空き状態であることを検出した後に,利用チャネルを用いたパケット送信を開始する。
[0006] 具体的に,キャリアセンスを実行する検針用通信端局は,利用チャネルにおいて5msecに亘って信号が発生しなければ,利用チャネルが空き状態であると判断する。検針用通信端局は,利用チャネルが空き状態であることを検出できない場合,このキャリアセンスを5msec毎に繰り返す。」

そうすると,文献1には,「検針用通信端局は,パケットの送信前に利用チャネルのキャリアセンスを行い,利用チャネルが空き状態であることを検出できない場合,キャリアセンスを繰り返す。」という技術的事項が記載されていると認められる。

(7)文献2について
申立ての理由において挙げられた文献2(特開2008-271382号公報)には,以下の事項が記載されている。(下線は,当審で付した。)

「【0038】
[実施の形態1]
図1は,本発明の実施の一形態に係る無線認証システムの構成を示すブロック図である。この無線認証システムは,検知対象であるユーザの移動空間1に沿って複数のセンサS1,S2,S3,S4,・・・(総称するときは,以下参照符号Sで示す)が配置され,前記ユーザに携行される無線タグTGがいずれかのセンサSと通信を行ってゆき,その検知結果が上位装置2でモニタされることで,該上位装置2によってユーザの所在や通過した軌跡を検知するものである。前記各センサSは,天井などに取付けられ,その検知対象エリアA1,A2,A3,A4,・・・(総称するときは,以下参照符号Aで示す)は,そのようなユーザを漏れなく検知できるように,隣接するセンサS間でその一部が相互に重なるように配置されている。無線タグTGは,前記検知対象エリアA内であれば,どこに移動してもその検知対象エリアAを有するセンサSで検知可能となっている。
【0039】
そして,注目すべきは,本実施の形態では,各センサSが時分割多元接続(TDMA),周波数分割多元接続(FDMA),符号分割多元接続(CDMA)などの前記各センサS間で相互に等しい無線通信手法を使用して多元接続によってセンサS間で干渉しないように前記無線タグTGと通信を行うにあたって,設定モードとなると,各センサSが,空いているタイムスロット(TDMA),周波数(FDMA),符号(CDMA)などの接続手法を探索して,自動的に設定することである。なお,以下の説明では,前記多元接続の手法として,TDMAを例に説明するが,FDMAやCDMAなどの他の接続手法にも同様に適用可能であることは言うまでもない。前記設定モードには,後述する設定釦の操作や無線(リモコン)での設定指示などに応答して切換わる。」

「【0054】
図4は,上述のような機能を実現するセンサSの一構成例を示すブロック図である。このセンサSは,他のセンサおよび無線タグTGと通信を行い,無線通信部である無線信号送受信部11と,前記無線信号送受信部11を介して他のセンサとの間で上述のようなスロット設定動作を行うスロット選択部12と,前記スロット設定動作などに使用されるユーザインタフェイス13と,前記無線信号送受信部11を介して無線タグTGと通信を行い,それを認証するタグ管理部14と,前記タグ管理部14で得られた認証データを前記上位装置2へ送信するとともに,前記上位装置2からこのセンサSの制御データを受信するネットワークインタフェイス15とを備えて構成される。」

「【0061】
図5は,図4で示すスロット選択部12による前述の図2や図3で示すスロット設定動作を詳しく説明するためのフローチャートである。設定にあたって,前述のようにユーザインタフェイス部13の設定スイッチ33の操作や無線での設定指示などによって,該スロット選択部12は設定モードとなっており,状態表示手段31が設定モードであることを表示している。この状態で,前記設定スイッチ33の操作や無線でのスタート指示などによって,或いは他のセンサからの使用スロット通知を受信すると,それらをトリガとして,この図5で示す設定動作が開始される。
【0062】
ステップS1では,この設定動作を開始したのが(上位側のセンサからの)使用スロット通知の受信であるか否かが判断され,そうであるとき,すなわち途中または末端のセンサであるときにはステップS2で,前記使用スロット通知受信処理部213に受信した識別情報IDが記憶された後ステップS3に移り,そうでないとき,すなわち始端のセンサであるときには直接ステップS3に移る。ステップS3では,空きスロット検出処理部211が前述のように空きスロットを探索する。
【0063】
ステップS4では,次の送信周期W1が始まるまで待機し,次の送信周期W1となると,ステップS5で,任意の時間待機した後,ステップS6で通常のCSMA-CAなどの方法でキャリアセンスし,他のセンサからのキャリアが検出されると前記ステップS4に戻って次の送信周期W1まで待機し,キャリアが検出されないとステップS7に移って,前記使用スロット通知送信処理部212から使用スロット通知を送信する。
【0064】
ステップS8では,衝突通知受信処理部223が前記所定期間W2のWindowを設定し,ステップS9で衝突検知通知が受信されたか否かが判断され,受信された場合は前記ステップS4に戻って,再送制御部224が前記空きスロット検出処理部211に空きスロットの検出から使用スロット通知をやり直させ,衝突検知通知が受信されなかった場合は自機での使用スロットを確定する。
【0065】
続いて,ステップS11では,次の送信周期W1に,他のセンサ(下位側のセンサ)からの使用スロット通知が使用スロット通知受信処理部213で受信されるか待機し,ステップS12で受信されなかった場合,すなわち自機が末端のセンサであった場合にはステップS13に移り,設定終了検出処理部241がそれを判定し,設定終了通知処理部242に前記スロット設定終了通知を送信させる。ステップS14では,前記状態表示手段31に,設定モードを終了し,通常の運用状態に切換わったことを表示させ,ステップS15で通常の運用状態での同期信号待ちとなって設定モードを終了する。」

(ア)文献2の段落[0038]によれば,「無線タグとセンサとが通信する無線認証システム」が記載されている。

(イ)文献2の段落[0054]によれば,センサは,「スロット選択部」を備える。

(ウ)文献2の段落[0061]によれば,スロット選択部は「スロット設定動作」を行う。

(エ)文献2の段落[0063]によれば,スロット設定動作は,「送信周期にキャリアセンスを行い,キャリアが検出されると次の送信周期まで待機すること,キャリアが検出されないと使用スロットを送信する」ものである。

以上を総合すると,文献2には,次の技術的事項が記載されていると認められる。

「 無線タグとセンサとが通信する無線認証システムにおいて,
センサが備えるスロット選択部は,送信周期にキャリアセンスを行い,キャリアが検出されると次の送信周期まで待機すること,キャリアが検出されないと使用スロット通知を送信するスロット設定動作を行う。」

(8)特開2010-28175号公報について
特許異議申立人小倉啓七が甲第2号証として提出した特開2010-28175号公報(以下,「文献3」という)には,以下の事項が記載されている。

「【0131】
図14に示す変形例では、受信待ち状態R12になっている任意の送信側無線端末が、任意の受信側無線端末からの間欠送信信号P11を受信すると、この間欠送信信号P11の送信元の無線端末に対して、まず受信時間延長要求を送信し、その後に送信すべきデータのパケット(上記送信信号P12に相当)を送信する。上述した基本動作では、受信状態R11となる期間TRは一定であるが、本例では、受信時間延長要求を受信すると、期間TRを延長する。どの程度延長するかは、予め任意に決めて設定しておく。
【0132】
上述した基本動作では、間欠送信信号P11を受信すると直ちに送信信号P12を送信していたが、送信信号P12のデータを準備するのに時間が掛かる場合もあり得る。この為、本例では、上記の通り、まず受信時間延長要求を送信し、受信状態R11の期間を延ばすようにしている。」

「【図14】



3.当審の判断
(1)請求項1に係る発明について
請求項1に係る発明(以下,「本件発明」という。)と甲1発明とを対比する。

ア 甲1発明の「データを受信する端末」,「データを送信する端末」,「RITリクエスト」,「無線通信ネットワーク」は,それぞれ,本件発明の「受信機」,「送信機」,「RIT Data Request Frame」,「無線通信システム」に相当する。
また,甲1発明は,データを受信する端末からデータを送信する端末にRITリクエストを送信するのであるから,RITリクエストの送信を試みるRIT方式であることは明らかである。
そうすると,甲1発明の「データを受信する端末からデータを送信する端末に向けて周期的にRITリクエストが送信される通信を行う無線通信ネットワーク」は,本件発明と同様に,「受信機が送信機に向けて周期的にRIT Data Request Frameの送信を試みるRIT方式の通信を行う無線通信システム」といえる。

イ 甲1発明の「所定の時間」と「受信待ち受け」は,それぞれ本件発明の「所定の時間」と「受信待受状態」に相当することから,甲1発明において,「データを受信する端末は,データを送信する端末に対してRITリクエストを送信した後,所定の時間,受信待ち受けに入る通信制御部を備え」ることは,本件発明の「前記受信機は,前記送信機に対して前記RIT Data Request Frameを送信した後,所定期間,受信待受状態となる受信側制御部を備え」ることに相当する。

ウ 甲1発明のデータを送信する端末は下りバッファからデータ送信が行われるのであるから,下りバッファに登録されるデータは,送信対象となるデータである対象データであり,そうすると,甲1発明の「下りバッファにデータが登録された時,受信待ち受けに入り」は,本件発明の「送信対象となるデータである対象データがあれば受信待受状態となり」に相当する。
そして、甲1発明のデータを送信する端末は,受信待ち受けに入り,所望の端末からRITリクエストを受信するのであるから,受信待ち受けにおいて,所望の端末からRITリクエストを受信するものであること,また,所望の端末がデータを受信する端末であり、データ送信はデータを受信する端末に送信することであることは明らかである。よって,甲1発明の「データを送信する端末は,下りバッファにデータが登録された時,受信待ち受けに入り,所望の端末からRITリクエストを受信すると,下りバッファからデータ送信を行う通信制御部を備え」は,本件発明の「送信機は,送信対象となるデータである対象データがあれば受信待受状態となり,受信待受状態において前記受信機から前記RIT Data Request Frameを受信すると,該対象データを該受信機に送信する送信側制御部を備え」に相当する。

エ キャリアセンスが送信に利用する周波数帯域の電波を受信し,当該周波数帯域の受信電波強度を測定するものであることは技術常識であるので,甲1発明の「データを受信する端末の通信制御部は,RITリクエストの送信前に、キャリアセンスを行い」と本件発明の「受信側制御部は,前記RIT Data Request Frameの送信前に,送信に利用する周波数帯域の受信待受状態に移行することで該周波数帯域の受信電波強度を測定するキャリアセンスを行い,該周波数帯域の受信電波強度が閾値を超えていると,該受信待受状態を継続せずに該受信待受状態を解除し,今回のRIT Data Request Frameの送信を中止し,次回のRIT Data Request Frameの送信タイミングまで,該キャリアセンスを休止し,」とは,「受信側制御部は,前記RIT Data Request Frameの送信前に,送信に利用する周波数帯域の受信待受状態に移行することで該周波数帯域の受信電波強度を測定するキャリアセンスを行」う点で一致する。

以上のことから,本件発明と甲1発明との一致点及び相違点は,次のとおりである。

(一致点)
「 受信機が送信機に向けて周期的にRIT Data Request Frameの送信を試みるRIT方式の通信を行う無線通信システムであって,
前記受信機は,
前記送信機に対して前記RIT Data Request Frameを送信した後,所定期間,受信待受状態となる受信側制御部を備え,
前記送信機は,
送信対象となるデータである対象データがあれば受信待受状態となり,受信待受状態において前記受信機から前記RIT Data Request Frameを受信すると,該対象データを該受信機に送信する送信側制御部を備え,
前記受信側制御部は,
前記RIT Data Request Frameの送信前に,送信に利用する周波数帯域の受信待受状態に移行することで該周波数帯域の受信電波強度を測定するキャリアセンスを行う無線通信システム。」

(相違点1)
受信側制御部のキャリアセンスに関し,本件発明では,「該周波数帯域の受信電波強度が閾値を超えていると,該受信待受状態を継続せずに該受信待受状態を解除し,今回のRIT Data Request Frameの送信を中止し,次回のRIT Data Request Frameの送信タイミングまで,該キャリアセンスを休止」するのに対し,甲1発明では,データを受信する端末では,RITリクエストの送信前にキャリアセンスを行うが,当該発明特定事項が特定されていない点。

(相違点2)
送信側制御部の動作に関し,本件発明では,「RIT Data Request Frameを受信した後,前記対象データを送信する前に,該RIT Data Request Frameに示される前記受信機のアドレス情報を前記対象データとは別個のフレームで該受信機に送信」するのに対し,甲1発明では,RITリクエストを受信すると,下りバッファからデータ送信するが当該発明特定事項が特定されていない点。

(相違点3)
受信側制御部での対象データの受信に関し,本件発明では,「受信待受状態において自機のアドレス情報を受信した場合にのみ,続いて送信された,自機のアドレス情報が格納されたフレームとは別個のフレームに格納された前記対象データを受信する」のに対し,甲1発明では,受信待ち受けにおいて,送信されたデータを受信するが当該発明特定事項が特定されていない点。

そこで,まず,上記相違点1について検討する。
上記「2.」の「(7)」で説示したとおり,文献2に記載の技術的事項は,「送信周期にキャリアセンスを行い,キャリアが検出されると次の送信周期まで待機する」ものであるが,キャリアが検出されないと送信するものは,スロット設定動作における使用スロット通知であって,甲1発明のデータを受信する端末がデータを受信するために用いるRITリクエストとは前提となる技術が大きく異なるものであるから,甲1発明のデータを受信する端末の通信制御部がRITリクエストを送信する前に行うキャリアセンスの際に,文献2に記載の技術的事項を適用する動機付けは存在しない。
また,文献1には,「検針用通信端局は,パケットの送信前に利用チャネルのキャリアセンスを行い,利用チャネルが空き状態であることを検出できない場合,キャリアセンスを繰り返す。」という技術的事項が記載されており、キャリアセンスを繰り返しているから(上記「2.」の「(6)」参照。)、本件発明の休止動作とは相違するものである。なお,特許異議申立人は,上記文献1及び文献2を挙げて,キャリアセンスを行った結果,空き状態にない場合に送信を中止し,次回の送信タイミングで再度キャリアセンスを行うことは周知の技術である旨主張している(特許異議申立書の第10頁第8-11行目)が,上述のとおり文献1にはそのような技術事項は記載されていないから、特許異議申立人の当該主張は採用することができない。
そして,文献1び文献2以外の上記甲各号証及び文献3には,上記相違点1に係る本件発明の発明特定事項について何ら記載も示唆もされていない。
よって,相違点2及び相違点3について検討するまでもなく,本件発明は,特許異議申立人が提出した甲第1号証ないし甲第5号証、文献1ないし文献3に記載された発明又は技術事項に基づいて,当業者が容易に想到し得るものではない。

(2)請求項2に係る発明ついて
請求項2に係る発明は,請求項1に係る発明に対して,さらに「前記受信側制御部は,アドレス情報として前記受信機のアドレス情報のみが含まれる前記RIT Data Request Frameを前記送信機に対して送信する」という技術的事項を付加したものである。
よって,上記(1)に示した理由と同様の理由により,請求項2に係る発明は,特許異議申立人が提出した甲第1号証ないし甲第5号証、文献1ないし文献3に記載された発明又は技術事項に基づいて,当業者が容易に想到し得るものではない。

4.小活
以上のとおり,請求項1及び2に係る発明は,特許異議申立人が提出した甲第1号証ないし甲第5号証、文献1ないし文献3に記載された発明又は技術事項に基づいて,当業者が容易に発明をすることができたものではないから,特許異議申立人奥野宏美の特許異議の申立ての理由及び証拠によっては,請求項1及び2に係る特許を取り消すことはできない。

第5 むすび
したがって,特許異議の申立ての理由及び証拠によっては,請求項1及び2に係る特許を取り消すことはできない。
また,他に請求項1及び2に係る特許を取り消すべき理由を発見しない。
よって,結論のとおり決定する。
 
異議決定日 2020-10-28 
出願番号 特願2015-242046(P2015-242046)
審決分類 P 1 651・ 121- Y (H04W)
P 1 651・ 113- Y (H04W)
最終処分 維持  
前審関与審査官 倉本 敦史新井 寛  
特許庁審判長 中木 努
特許庁審判官 廣川 浩
永田 義仁
登録日 2019-12-13 
登録番号 特許第6630559号(P6630559)
権利者 国立大学法人京都大学 東京瓦斯株式会社
発明の名称 無線通信システム  
代理人 特許業務法人青海特許事務所  
代理人 特許業務法人青海特許事務所  

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