拒絶査定不服の審決｜不服2015-8510 - 特許審決データベース

会員機能

ランキング

請求人別審判件数

判例データベース

審決データベース

ポートフォリオ機能

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

この審決の個人情報、企業機密に関する修正依頼をする

PDF	PDFをダウンロード

審決分類	審判査定不服 2項進歩性特許、登録しない(前置又は当審拒絶理由) H04J 審判査定不服 1項3号刊行物記載特許、登録しない(前置又は当審拒絶理由) H04J
管理番号	1325402
審判番号	不服2015-8510
総通号数	208
発行国	日本国特許庁(JP)
公報種別	特許審決公報
発行日	2017-04-28
種別	拒絶査定不服の審決
審判請求日	2015-05-07
確定日	2017-02-22
事件の表示	特願2012-500936「ビームフォーミング動作に対するフィードバックメカニズム」拒絶査定不服審判事件〔平成22年 9月23日国際公開,WO2010/107945,平成24年 9月10日国内公表,特表2012-521180〕について,次のとおり審決する。
結論	本件審判の請求は,成り立たない。
理由	1 手続の経緯・本願発明本願は,2010年3月17日(パリ条約による優先権主張外国庁受理 2009年3月20日米国,2010年3月16日米国)を国際出願日とする出願であって,平成26年12月12日付けで拒絶査定がされ,これに対し,平成27年5月7日に拒絶査定不服審判が請求されるとともに同日付けで手続補正がされ,その後,当審において平成28年2月1日付けで拒絶理由が通知され,同年5月25日付けで手続補正がされたものである。その請求項1に係る発明(以下,「本願発明」という。)は,平成28年5月25日付け手続補正書により補正された特許請求の範囲の請求項1に記載された次のとおりのものと認める。「ワイヤレス通信デバイスによりフィードバックデータを発生させるための方法において, 前記方法は, 基地局からダウンリンクメッセージを受信することと, フィードバックデータ発生に対するモードを決定することと, 前記決定したモードに基づいて,前記フィードバックデータを発生させることと, 前記基地局に対して前記フィードバックデータを送信することとを含み, 前記決定したモードが,チャネル方向性についての情報に関する閉ループモードまたは部分的フィードバックモードであるとき,前記フィードバックデータは,チャネル品質インジケータ(CQI)とランクと1つ以上のプリコーディングベクトルとを含み, 前記決定したモードが,チャネル方向性についての情報に関する開ループモードであるとき,前記フィードバックデータは,CQIとランクとを含み,前記CQIと前記ランクは,完全なチャネル相互関係または部分的なチャネル相互関係が前記基地局の送信機において使用可能であるか否かに基づいて計算される方法。」 2 引用発明 (1)引用例が電気通信回線を通じて公衆に利用可能となった時についてまず,当審から通知した拒絶の理由に引用されたQualcomm Europe,Feedback options in support of dual-stream beamforming[online], 3GPP TSG-RAN WG1#56b R1-091449,インターネット＜URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip＞(以下,「引用例」という。)が電気通信回線を通じて公衆に利用可能となった時について,検討する。ア 3GPPによる公式な見解 (ア)3GPPのホームページ(http://www.3gpp.org/)にはFAQのページ(http://www.3gpp.org/about-3gpp/3gpp-faqs)があり,そのうちの「How can I determine when a meeting contribution document (TDoc) became publicly available?」の項には,以下の記載がある。「How can I determine when a meeting contribution document (TDoc) became publicly available? TDoc numbers start to be allocated some weeks before a 3GPP meeting, and the authors then create them and they or the group's secretary uploads them to the public file server as soon as possible. Some may have been distributed to the group's members in draft form for review, using the email exploder, in advance of the final one becoming available, and for some groups, it is normal to distribute even the final TDoc via the exploder, where the secretary picks it up and copies it to the public server. Typically, at the start of a meeting, around 50% of the TDocs are available. This distribution on the group's email exploder is important, because once that happens, the document is effectively in the public domain, since membership of the exploder is open to all and is unpoliced. During the meeting, further TDocs are created, mostly revisions of ones available before the meeting, but probably some brand new ones too - for example, outgoing liaison statements. These are uploaded to the meeting server, but (until recently) may or may not be uploaded to the public server during the meeting. (Since 2014, for most meetings, meeting server contents have been mirrored to a folder on the public server, but these copies are deleted shortly after the end of the meeting.) Soon after the end of the meeting - same day, or at worst within a few days - the TDocs created during the meeting are uploaded by the secretary to the public server. Occasionally, some matters from the meeting cannot be resolved until maybe one week later, and these might result in some very late TDocs which are produced well after the end of the meeting, and thus uploaded onto the public server correspondingly late. When the secretary copies from the meeting server (or from his own PC) to the public server, he may opt to only copy the missing files (i.e. the new ones), which is the best approach; or he may decide to overwrite everything and thus do a complete refresh of the files on the public server, which will now get an upload date/time-stamp of the new upload. This latter approach is now deprecated but has sometimes happened; you can detect this most easily when a meeting shows the same date/time-stamp for all TDoc files. In cases such as this, one has to descend to greater subterfuge to narrow down the likely "public availability" moment. The zip file for a TDoc typically contains a Word file which has a particular date/time-stamp, which puts an absolute limit on the earliest moment that the TDoc could have become available in that form. Searching the group's email exploder archive (http://list.etsi.org/scripts/wa.exe?INDEX) on or about the suspected production date gleaned from the file date/time-stamp may well reveal the message in which the TDoc was first distributed, or perhaps the message by which the group's secretary announced that it was available on the server. Note however that this technique does not reveal any earlier versions of the TDoc which might have been circulated, either as draft versions of the identified TDoc or as other Tdocs which were ultimately revised into the actual TDoc of interest. In order to identify this latter case, it is necessary to refer to the official secretary's report of the meeting, where the train of revisions will be evident.」 ([当審仮訳]: 会議寄稿文書(TDoc)が公的に利用可能になった時は,どのようにして決定できますか? TDoc番号は,3GPPの会議の数週間前に割り当てが開始され,それから著者はTDocを作成し,著者又はグループの秘書は,できるだけ早くTDocを公開ファイルサーバにアップロードします。いくつかのものは,最終的なものが利用可能となる前に,email exploderを使用して,レビュー用のドラフト形式でグループのメンバーに配布され,いくつかのグループでは最終的なTDocでさえemail exploderを介して配布することが普通であり,秘書がそれをピックアップして公開サーバにコピーします。一般的に,会議の開始時には,TDocsの約50%が利用可能です。 email exploderのメンバーシップはすべての者に対してオープンであり規制されていないため,一旦配布が起こると文書は事実上パブリックドメインに存在することになるので,このグループのemail exploder上での配布は,重要です。会議中に更なるTDocsが作成され,大半は会議の前に利用可能となったものの改訂版ですが,例えばoutgoing liaison statements等,おそらく全く新規なものもあります。それらは,会議サーバにアップロードされますが,(最近まで)会議中は公開サーバにアップロードされてもされなくてもよいとされています。(2014年以降,ほとんどの会議のために,会議サーバーの内容は公開サーバ上のフォルダにミラーリングされていますが,これらのコピーは会議の終了後すぐに削除されます。) 会議の終了後すぐ-同日又は最悪でも数日以内-に,会議中に作成されたTDocsは秘書によって公開サーバへアップロードされます。時折,会議からのいくつかの事項について多分1週間後までに解決できず,会議の終了後に作成される非常に遅いTDocsとなる可能性があり,その分,公開サーバへのアップロードが遅れることがあります。秘書が会議サーバから(又は自分のPCから)公開サーバへコピーするとき,最適なアプローチである欠落しているファイル(すなわち新しいもの)のみをコピーすることを選ぶことができ,又は,すべてを上書きすることを決定し,新しいアップロードのアップロード日付/タイムスタンプを取得する,公開サーバ上のファイルの完全リフレッシュを行うかもしれません。この後者のアプローチは現在反対されていますが,時々発生しています。会議がすべてのTDocファイルに同じ日付/タイムスタンプを示しているとき,最も簡単にこれを検出することができます。このようなケースでは,「公的に利用可能」といえる瞬間を絞り込むために,より詳細な検討をしなければなりません。TDocのzipファイルには,通常,特定の日付/タイムスタンプを持つWordファイルが含まれており,当該日付/タイムスタンプがTDocがそのフォームで利用可能になっている可能性が最も早い瞬間の絶対的な制限を置きます。ファイルの日付/タイムスタンプから収集される疑わしい作成日についてグループのemail exploderのアーカイブ(http://list.etsi.org/scripts/wa.exe?INDEX)を検索することは,TDocが最初に配布されたメッセージ,又は,ことによるとそれによりグループの秘書がそれがサーバ上で利用可能であることをアナウンスしたメッセージを明らかにする可能性があります。しかしながら,識別されたTDocのドラフトバージョンとして,あるいは最終的に関心のある実際のTDocに改訂された他のTDocsのいずれかとして,循環されている可能性があるTDocについては,このテクニックは初期のバージョンを明らかにしないことに注意してください。この後者のケースを識別するためには,一連の改訂が明らかな公式秘書会議報告書を参照する必要があります。) (イ)同じく「Is it possible to determine the date and time of publication of a particular version of a 3GPP Spec?」の項には,以下の記載がある。「Is it possible to determine the date and time of publication of a particular version of a 3GPP Spec? During the drafting phase (versions lower than 3.0.0), 3GPP TSs and TRs ("Specs") are under the control of their authors ("rapporteurs") and are handled like normal meeting contributions (see above). Revised versions incorporating text agreed by the responsible working group are often made available by the rapporteur via the group's email exploder shortly after the end of the meeting at which such text was discussed. Again, consultation of the exploder archives can reveal this. Alternatively, a revised draft may be sent directly to the 3GPP Support Team, and it will be uploaded to the public file server (specs archive directory) shortly afterwards. Again, the time stamp of the Zip file can be relied upon to indicate when the upload occurred. After formal approval by the TSG (versions 3.0.0 or greater), Specs are edited only by the Support Team. The first approved version is based upon the draft version formally approved by the TSG, and thereafter versions are generated whenever Change Requests are approved by the TSG. These versions are made available shortly after the TSG meeting at which such approval occurred. The date (year and month) shown at the top of the Spec's cover page indicates either the date of (the last day of) the meeting, or the month in which the new version was prepared. However a more precise indication of the date of availability can be obtained from the Spec's web page (via the table at http://www.3gpp.org/specifications/) where a precise date is shown in the "available" column. More information on the procedures relating to Spec handing can be found in 3GPP TR 21.900. Note that, in accordance with the statement at the foot of the cover page of all 3GPP Specs, 3GPP does not "publish" its Specs per se. Formal publication is the responsibility of the individual Standards Development Organizations which comprise the Organizational Partners of 3GPP. For further information, see http://www.3gpp.org/specifications/63-official-publications.」 ([当審仮訳]: 3GPPの仕様の特定のバージョンの公表の日付と時間を決定することは可能ですか? ドラフティング・フェーズ(バージョン3.0.0未満)の間に,3GPPのTSとのTR(「仕様」)は,その著者(「ラポーチャー」)の制御下にあり,通常の会議寄稿(上記参照)と同様に処理されます。責任あるワーキンググループによって合意されたテキストを組み込んだ改訂版は,多くの場合,そのようなテキストが議論された会議の終了後すぐに,グループのemail exploderを介してラポーチャーによって利用できるようになります。ここでも,email exploderアーカイブの参照はこれを明らかにすることができます。あるいはまた,改訂案は3GPPサポートチームに直接送付することができ,それはその後すぐに公開ファイルサーバ(仕様アーカイブ・ディレクトリ)にアップロードされます。ここでも,Zipファイルのタイムスタンプは,アップロードが発生したことを示すために頼ることができます。 TSG(バージョン3.0.0以上)による正式な承認後は,仕様はサポートチームによってのみ編集されます。最初の承認バージョンはTSGにより正式に承認されたドラフト版に基づいており,変更要求がTSGにより承認されるたびにその後のバージョンが生成されます。これらのバージョンは,その承認がなされたTSG会議後すぐに使用可能になります。仕様のカバーページの上部に表示される日付(年月)は,会議の日付(最終日)又は新しいバージョンが用意された月のいずれかを示しています。利用可能となった日付のより正確な表示は,仕様のWebページ(http://www.3gpp.org/specifications/のテーブルを介して)から入手することができ,そこでは正確な日付は「available」の欄に示されています。仕様の扱いに関する手続の詳細については,3GPP TR21.900に記載されています。すべての3GPP仕様のカバーページの最下部の声明に従って,3GPPは,その仕様自体を「刊行」しない,ことに注意してください。正式な出版物は,3GPPの組織上のパートナーを構成する個々の規格開発組織の責任です。詳細については,http://www.3gpp.org/specifications/63-official-publicationsを参照してください。) (ウ)3GPP(3rd Generation Partnership Project)は,米国のATIS,欧州のETSI,日本のARIB,TTC,韓国のTTAといった各国・各地域の標準化団体により1998年12月に設立された標準化団体間のプロジェクトであり,W-CDMAとGSM発展型ネットワークを基本とする第3世代携帯電話システム及びそれに続く第3.9世代移動通信システムに対応するLTE,第4世代移動通信システムに対応するLTE-Advanced等,移動通信システムの仕様の検討・作成を行っている国際的な標準化組織であるから,そのホームページの情報は十分に信用がおけるものである。そして,プロジェクトにおけるIPRポリシーが規定されており,IPRにおける公知日の重要性を十分に認識しているからこそ,上記FAQにTDocや仕様の公知日(公的に利用可能となった時)の決定方法が詳述されていると解される。したがって,上記FAQには,3GPPの会議寄稿文書(TDoc)及び仕様(Spec)の特定のバージョンが公的に利用可能になった時点をどのようにして決定するかについての,3GPPの公式な見解が示されていることは明らかである。そして,上記FAQの記載によれば,3GPPの会議寄稿文書(TDoc)は,少なくともTDocを作成した著者自身又はグループの秘書がTDocを公開ファイルサーバにアップロードした時点で,公的に利用可能になるといえる(上記(ア)本文の第1段落参照。)。そして,アップロードした日時は,TDocファイルのアップロード日付/タイムスタンプに示されるものである(上記(ア)本文の第5段落及び(イ)本文の第1段落参照。)。イ引用例(R1-091449)に関する3GPPの公開ファイルサーバ上の情報 (ア)3GPPのホームページ(http://www.3gpp.org/)の「Search」欄には「ADVANCED FTP SEARCH」なるボタンが表示されており,当該ボタンをクリックするとサーチ用画面が開く。当該サーチ用画面には,サーチ項目として,「with all the words」等のキーワードによる検索項目の外,「Return files updated after」,「Return files updated before」なる入力欄が存在する。ここで,「with all the words」の欄に「R1-091449」を入力し,サーチエリアとして「TSG RAN(UTRAN/LTE)」を選択し,Calenderにより「Return files updated after」及び「Return files updated before」の欄に「20090319」を入力して,Searchボタンをクリックすると, 1件ヒットしたサーチ結果画面が表示され, 「3GPP TSG-RAN WG #55bis 19 Mar 2009 3GPP TSG-RAN WG #56bis R1-091449 R1-091449.zip-> R1-091449 Feedback Dual-stream beamforming.doc - 19 Mar 2009 - Details 」との項目が表示される。また,例えば,「with all the words」の欄に引用例の題名の一部である「dual-stream beamforming」を入力し,サーチエリアとして「TSG RAN(UTRAN/LTE)」を選択し,「Return files updated after」の欄に「20090319」,「Return files updated before」の欄に「20090320」を入力して,Searchボタンをクリックすると, 4件ヒットしたサーチ結果画面が表示され,いずれのヒット項目についても,記載されている日付は「Return files updated after」と「Return files updated before」の日付の範囲内のものである。したがって,サーチ用画面にて,キーワードを入力し,サーチエリアを選択し,「Return files updated after」,「Return files updated before」に日付を入力して,Searchボタンをクリックすると,当該キーワードを含む文献をファイルのupdate日を特定して検索していることは明らかである。 (イ)次に,ヒットした項目の詳細な情報を見るために,上記(ア)の1件ヒットしたサーチ結果画面の項目中の「Details」の部分をクリックすると,「R1-091449」のDocument Informationが示される。その「Filename:」欄は「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip」とされており,そのファイル名からして,当該ファイルが公開ファイルサーバのTDocファイルに該当すると解される。そして,当該ファイル名は当審における拒絶理由通知の引用文献一覧のURL情報と同一である。そして,「Date:」欄は「19-Mar-2009」となっており,これは上記(ア)のサーチ結果画面の日付「19 Mar 2009」と対応するものであり,公開ファイルサーバの「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip」なるファイルのアップデートの日付に対応するものと解するのが自然である。 (ウ)なお,上記URL情報の一部である「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/」では,3GPP TSG-RAN WG1の56bis会議のTDocのリスト一覧の画面が表示され,その中の「R1-091449.zip」をクリックすることによっても「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip」なるzipファイルが開き,その中のwordファイルが選択可能となる。ここで,当該リスト一覧の画面にはTDoc名の欄の左端に日付及び時刻が表示され,「R1-091449.zip」の欄は「3/19/2009 8:19 AM」と表示されており,当該表示の少なくとも日付は,上記サーチ結果画面の日付及び上記Document Informationの「Date:」欄の日付に対応している。ウ当審の判断上述のとおり,3GPPのホームページのFAQによれば,少なくともTDocを作成した著者自身又はグループの秘書がTDocを公開ファイルサーバにアップロードした時点で,当該TDocは公的に利用可能になるといえる。請求人は平成28年5月25日付け意見書において,アップロードの際に別途掲載日時を設定することやアップロード後に許可を得てから掲載されることなどがあることを例に挙げて,アップロードされると即掲載されるとは限らずアップロード日時と掲載日時は必ずしも一致するものではない旨主張するとともに,メールに添付されたファイルを事務官([当審注]:[当審仮訳]では,「secretary」を「事務官」と訳す代わりに「秘書」と訳している。)が公開サーバにコピーした後に実際に公開された時が公開日時となる旨主張している。すなわち,公開ファイルサーバへのアップロードと公開とは別であることを主張している。しかしながら,FAQは,「会議寄稿文書(TDoc)が公的に利用可能になった時は,どのようにして決定できますか?」との問いに対して,公開ファイルサーバへのアップロードについて詳述しているものであり,アップロードと公開とが別であることを前提として回答しているものではない。そして,もしも請求人が主張するように,アップロードと公開とが別であるのであれば,FAQは「会議寄稿文書(TDoc)が公的に利用可能になった時は,どのようにして決定できますか?」との問いに対して何ら回答をしていないこととなるから,そのようなことは不自然である。また,請求人の主張は,一般例としての単なる可能性に基づくものにすぎず,3GPPの具体的な手続を根拠としているものではなく,また,具体的事実や証拠を提示しているわけでもない。したがって,請求人の主張は,根拠がなく,FAQの内容に照らして不自然であるから,採用することができない。ここで,公開サーバ上のTDocに関する情報(上記イ参照。)を見ても,updateに関する情報は存在するものの,uploadについては明らかでない。そして,サーチ用画面の「Return files updated after」,「Return files updated before」は「upload」ではなく「update」であり,上記Document Informationは単に「Date:」とあるのみであってuploadの日付なのか否かは明らかされていない。しかしながら,上述のとおり「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip」なるファイルは,そのファイル名からして公開ファイルサーバのTDocファイルであるから,そのupdateとは,3GPPの公開ファイルサーバがそのTDocファイルである「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip」をアップデートしたことを意味していることは明らかである。すなわち,当該updateは,公開ファイルサーバのファイルに関する事項であって,例えば著者が3GPPに送付する前に著者自身のPC内でwordファイルをアップデートしたことを意味するものではない。そして,サーバ技術における技術常識によれば,公開ファイルサーバはTDocがuploadされることによりupdateされることは明らかである。また,上記FAQは,updateとuploadとを区別しておらず,「アップロードのアップロード日付/タイムスタンプ」しか言及しておらず,また,「すべてを上書きすることを決定し,新しいアップロードのアップロード日付/タイムスタンプを取得する,公開サーバ上のファイルの完全リフレッシュを行うかもしれません。この後者のアプローチは現在反対されていますが,時々発生しています。会議がすべてのTDocファイルに同じ日付/タイムスタンプを示しているとき,最も簡単にこれを検出することができます。」(上記ア(ア)参照。)と述べられていること,及び「Zipファイルのタイムスタンプは,アップロードが発生したことを示すために頼ることができます。」(上記ア(イ)参照。)と述べられていることに鑑みれば,会議のTDocのリスト一覧の画面の左端の日時(上記イ(ウ)参照。)は,アップロードがなされた時点のアップロード日付/タイムスタンプと解し得るものである。そして,上述したように,当該日時のうちの日付はTDocファイルのDocument InformationのDateに対応するものである。してみると,「http://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_56b/Docs/R1-091449.zip」なるTDocファイルは,19 Mar 2009に3GPPの公開ファイルサーバにアップロードされることにより,公衆に利用可能となったと解するのが相当である。したがって,引用例は,本件出願の最先の優先日である2009年3月20日より前の2009年3月19日に,電気通信回線を通じて公衆に利用可能となっていたと認める。 (2)引用例に記載された発明引用例には,図面とともに以下の事項が記載されている。ア「」(1/5?2/5ページ) ([当審仮訳]: 2.1 ビームフォーミング動作 [4],[5]に示されるように,送信機側のビームフォーミングは,送信機においてチャネル知識が利用可能であるときに,著しい利得を提供することができる。単一レイヤのビームフォーミングに対して,送信は,最も大きい固有値に対応するチャネル共分散行列の固有ベクトルに沿って生じる。このケースでは,受信したSINRを改善することにより,容量利得が取得される。 MIMOセットアップでは,固有ビームフォーミングは,最も大きい固有値に対応する固有ベクトルに沿って送信することにより適用され得るので,ビームフォーミングを提供し,利得を多重化する。これらのベクトルが,送信されるビームであると仮定して,ランク選択とチャネル品質インジケータ(CQI)計算とを行うことができる。最後に,送信機におけるチャネルの知識が不完全又は部分的であるシナリオでは,複数のストリームの送信に擬似固有ビームフォーミングを使用することができる。・擬似固有ビームフォーミングでは,ビームフォーミングベクトルはチャネルの方向についての知識に基づいて構築される。観察できないチャネルの部分については,既知の固有方向に直交する部分空間中にランダムな方向を仮定することができる。・例として,ダウンリンクにおける8Tｘ,2Rｘセットアップを検討する。eノードBは,(SRS送信を通して)UEの受信アンテナのうちの1本に対するチャネルの知識を有しており,他の受信アンテナに対する量子化されたチャネル情報が提供されると仮定する。その後,ノードBは,これら2本の受信アンテナに対するチャネルに対応する固有ベクトルを,ビーム方向として使用することができる。・その他の例として,eノードBはRｘアンテナのうちの1本だけに対するチャネルの知識を有していると仮定する。このケースでは,eノードBはこの受信アンテナに対するチャネルの方向で,及び,前の方向と直交するランダムビーム方向で,送信することができる。より良好なダイバーシティ及び/又はより正確なレート予測を提供するために,使用されるランダムビームは,周波数と時間にわたって異なることができる。・ランク及びCQIを計算する際の,類似するビームフォーミング構築にしたがって,UEにより,このケースにおける送信とフィードバックとを整列させることができる。) イ「」(2/5ページ) ([当審仮訳]: 2.2 UE及びeノードBにおけるチャネル知識まず,本稿で頻繁に使用される2つの表記を定義する。N_BFは,ビームフォーミングに使用されるアンテナの数とする。また,N_RSは,ユーザがCQI/RI及び場合によってはPMI計算のために送信機からのチャネルの推定を得るための,RSポートの数とする。フィードバックメカニズム設計は,DLチャネルに関してUE及びeノードBにおいて利用可能な知識に依存する。 1. UEにおけるチャネル知識:リリース8のLTE CRSはせいぜい4アンテナポートに対してチャネル推定を提供することができる。ビームフォーミングに対して使用されるアンテナの数(N_BF)は,CRSポートの数よりも大きいことがある。このケースでは,UEフィードバックはN_RS個のアンテナポートから観測されるチャネルのみに基づくことができ,ビームフォーミング利得を完全に捕捉することができない。このことは,FDD及び場合によってはTDDシステムのためのデュアルストリームビームフォーミングの性能に影響する。リリース8のLTE CRSポートは,復調とフィードバックの双方の目的のために使用される。低デューティーサイクルでフィードバックRSを導入することにより,異なるUEは,フィードバック目的のためにチャネルの知識を取得することができる。このような基準信号のオーバーヘッドは非常に小さい。このようなRS構造を有していることは,FDDとTDDシステムの双方に対して,(RS送信に使用されるアンテナポートだけでなく,)すべての送信アンテナからのビームフォーミング利得を提供する。 2. eノードBにおけるチャネル知識:TDDシステムでは,DLチャネルとULチャネルとの相互関係のために,eノードBは,ULを通して送信されるサウンディング基準信号(SRS)により,DLにおけるチャネル推定を獲得することができる。しかしながら,UEにおけるULのための送信アンテナの数がDLにおける受信アンテナの数と等しくないときには,eノードBはUEのいくつかの特定の受信アンテナへのDLチャネルについての部分的な知識を持つ。このような場合を「部分的なチャネル相互関係」と呼び,このようなシナリオにおける動作に取り組む。リリース8のLTEでは,ULにおいてアンテナスイッチングSRS送信が可能であることに留意すべきである。しかしながら,これは,必須な特徴ではなく,例えばスイッチによりもたらされる挿入損失のため,いくつかのUEインプリメンテーションでは望ましくない。アンテナスイッチングにより,eノードBは,UEにおけるすべての受信アンテナのためのDLチャネル知識を得ることができる。以下の動作モードはUEにより報告されるフィードバックのタイプに基づいて類別される。) ウ「」(2/5?3/5ページ) ([当審仮訳]: 2.3 閉ループモード: 閉ループ動作では,UEは,利用可能なN_RS個のアンテナポートから得られたチャネル推定に基づいてCQI,ランクそして好ましいプリコーディングベクトルを計算し,eノードBにその値をフィードバックする。eノードBは,報告されたプリコーディングベクトルを使用し,報告されたCQI及びランクに基づいて,UEに送信する。このようなスキームは,FDDとTDDの双方に対して適用可能である。このケースの動作は,送信は,UEにより報告されるプリコーディングベクトルに沿っているので,UEにおけるTｘ/Rｘアンテナの非対称的なコンフィギュレーションと,TX/RXチェーンにおける可能性ある較正のミスマッチとにより影響を受けない。閉ループ動作を可能とするために,以下のメカニズムが導入されることが必要である。・eノードBにおけるより多い数の送信アンテナに対するプリコーディング設計・ランクと好ましいプリコーディング行列とのシグナリング及びフィードバックもしN_RSがN_BFよりも少ない場合に,このような動作により取得されるビームフォーミング利得は限定されることにも留意すべきである。それゆえ,このシナリオにおいてフィードバック目的のためにリリース8のCRSを使用することは,ビームフォーミングにより取得される利得を減少させることがある。そのような限定に関する損失は将来検討される必要がある。代替として,(復調のためではなく)測定と報告のためにのみ使用されるN_BF個のアンテナに対する低デューティーサイクルチャネル状態情報RS(CSI-RS)を提供する。このようなフィードバックRSに対応するオーバーヘッドは非常に小さくすることができる。それゆえ,リリース9において,フィードバック目的のために低デューティーサイクルCSI-RSの導入を考えることは,高次MIMOに対して構想されているCSI-RSやリリース10の協調送信と同じく,価値がある。) エ「」(3/5ページ) ([当審仮訳]: 2.4 開ループモード: このシナリオでは,UEはチャネルの方向性について何の情報も提供せず,CQIと,場合によってはランクとを報告するだけである。 FDDモードでは,UEにおけるCQIとランクの計算は,1組の予め規定されたプリコーディング行列に基づくことができる。UEとeノードBの双方は,送信において適用されるだろうプリコーディング動作(すなわち,大幅な遅延CDD,ビームスイーピング)に合意することができる。CQIとランクの計算は,大幅なレートの予測ミスマッチを避けるために,この知識に基づくことができる。UEは,計算されたCQIとランクをeノードBに報告する。 TDDモードでは,以下のシナリオを考慮することができる: 1. UEは,部分的に干渉を捕捉するために,リリース8の送信モード7を仮定して,CQIのみを報告する。eノードBは,チャネル知識と,報告されたCQIとに基づいて,ランクを選択し,異なるレイヤに対するCQIを調節する。 2. 送信機において完全なチャネル相互関係が仮定されれば,以下のオプションが考慮され得る。 a. すべてのアンテナに対するフィードバックRSが存在する(すなわち,N_RS=N_BF)ならば,UEは,チャネルに適用された固有ビームフォーミングを仮定してCQI,ランクの選択をすることができる。このケースのランクとCQIの計算は,すべてのアンテナからのビームフォーミング利得と同様に,受信機における干渉構造を考慮することができることに留意すべきである。UEは計算されたCQI及びランクをeノードBに報告する。このシナリオでは,UEにおけるCQIの計算が,eノードBにおける送信ビームフォーミングにマッチしている限り,プリコーダ情報を送信する必要はない。 b. N_RS＜N_BFの場合,RSポートにおける固有ビームフォーミングを使用して利用可能なN_RS個のポートに基づいて,ランク及びCQI選択はUEにおいてなされ得る。eノードBは,報告が基づいているN_RSとは対照的に,N_BF個のアンテナからの送信による余分なビームフォーミング利得を捕捉するよう,CQIを調整することができる。 3. 「部分的なチャネル相互関係」が適用可能であれば,以下のオプションを考慮することができる。 a. UEは,次の2つの動作のうちの1つを仮定して,CQI及びランクを計算することができる。 i. ランク及びCQIの計算においてプリコーディングされていないチャネルを仮定する。 ii. ランク及びCQIの計算において擬似固有ビームフォーミングを仮定する。このケースでは,UEはRｘアンテナのためにアップリンクにおけるSRS送信に対応するチャネル推定を用い,他のレイヤに対して,これらのチャネルに対して直交するランダムなビームを仮定する。ランク及びCQIの計算はそのようなビームフォーミング構造に基づく。 b. eノードBは,ビーム方向を形成する際に,擬似固有ビームフォーミングを使用する。eノードBは,取得した方向に沿って送信するために,UEにより報告されたCQIとランクとを使用する。) オ「」(3/5?4/5ページ) ([当審仮訳]: 2.5 部分フィードバックモード: このケースでは,UEは,CQI及びランク情報とともに,観測したチャネル方向性の部分的な表示を提供する。この情報は,FDDにおける好ましいプリコーディング行列の一部分とすることができ,またULにおけるSRS送信が起こらないRｘアンテナから見たチャネルの量子化したバージョンとすることができる。 FDDでは,UEは擬似固有ビームフォーミングスキームに基づいてCQI及びランクを計算することができる。ランク2について,UEは,プリコーディングベクトルを用い,そして選択されたプリコーダに直交する他の方向を選んで,CQI計算を実行し,組み合わせたプリコーディング行列を用いてCQIを計算する。eノードBは,ランクとフィードバックを通して提供された部分的なチャネル情報とにしたがって,擬似固有ビームフォーミングを用いる。 UEにおける,「部分的なチャネル相互関係」又は著しい較正ミスマッチを持つ,TDDシステムにおける部分フィードバック送信モードもまた,考慮することができる。このケースでは,RXアンテナ上で観測されるが,ノードBにより観測可能でないチャネルに関する付加的な情報を,UEが提供することができる。・UEにおけるCQI及びランク計算:UEは,他の受信アンテナに対するチャネルを近似するプリコーディングベクトルとともに,eノードBにおいて知られている,受信アンテナに対するチャネルの推定を使用して,最良のCQI及びランクを計算する。その後,CQIと,ランクと,選んだプリコーディングベクトルとをeノードBに対して報告する。・eノードBにおけるスケジューリング:eノードBは,ビームフォーミングプリコーダを構築するために,そのチャネルの知識とともに,チャネルフィードバック情報を使用する。構築したプリコーダとともに,UEにより選択されたCQIとランクとを使用して,UEをスケジュールする。) カ「」(4/5ページ) ([当審仮訳]: 3 検討次の見解が適っている。・UEがすべてのビームフォーミングアンテナに対するチャネルの推定を獲得する場合,UE報告は送信機のすべての送信アンテナからの干渉とビームフォーミング利得を捕捉する。このケースでは,FDD及びTDDシステムの双方に対してデュアルストリームビームフォーミング利得が獲得できる。 ○リリース8においてアドバタイズされているCRSポートの数はせいぜい4個(商業的な展開では多分2個)であり,それは復調において使用されるので,それに関係するオーバーヘッドは大きい。同時に,ビームフォーミング動作に対する送信アンテナの数は,アドバタイズされているCRSポートの数よりも多いことがある。 ○リリース10に対して構想されているCSI-RSの線に沿って,チャネル局情報フィードバックのためにだけ使用される低デューティサイクル基準信号を導入してもよい。CRSアンテナポートのみを使用するものに比べて,すべての送信アンテナを使用するビームフォーミング利得は,大きいことがある。すべての送信アンテナに対して低オーバーヘッドCSI-RSを有することは,FDDシステムと,場合によってはTDDシステムとにおいて,ビームフォーミング利得を提供することがある。・送信アンテナの数が4本よりも多いケースに対して,(特にFDDシステムにおいて)ビームフォーミング利得を捕捉するために,新しいプリコーディング構造を考える必要がある。・時間及び周波数における報告の粒度は,将来検討可能である。特に,周波数選択報告(すなわち,サブバンドベース)又はワイドバンド報告は,リリース8におけるものと同様に考えることができる。・異なる動作モードにおいて,ランク2送信に対するレイヤシフティングを考えることができる。このようなメカニズムは,部分的フィードバックモードにおいて利益があるかもしれず,オーバーヘッド低減のためにも使用することができる。・次のパケット送信に対するCQI/RIを計算するために,(N_RSポートから取得されるチャネル推定とともに)DM-RSを使用することが可能である。このケースでは,CQI/RI報告は,ノードBからの要求により,非周期的である必要がある。この方法でのCQI/RIの計算は,ビームフォーミング利得を捕捉するが,このようなメカニズムは,バンドの小さな部分にUE-RSが割り振られているケースに対しては,又は,バースト的なトラフィックソースを持つユーザに対しては,信頼性が低いかもしれない。この報告メカニズムは正確であるが,これは,UEによる頻繁な報告を必要とするので,極端でない移動においてさえ,効率が良くないことがある。・空間干渉構造とそれらに関係する利得に関する情報をシグナリングする方法もまた,将来調査可能である。これは,UEが,チャネルの部分的な推定を有しているケースに対しても適用可能である。このようなシグナリングの例は以下のとおりである。 ○UEは,eノードBに対して,CQI/RI/PMIフィードバックとを提供することできる。このケースは,実質的に,先に論じた閉ループプリコーディングである。このケースのビームフォーミング動作は,干渉及びチャネル構造を同時に捕捉することができる。 ○eノードBに対して,干渉共分散構造を信号で知らせてもよい。例えば,これは,支配的な干渉方向がUEにおいて検出されるときに適用可能である。これは低デューティサイクル(おそらくは,上位レイヤ)シグナリングに基づいて達成でき,干渉の持続的で長期的な共分散構造が存在するときに使用できる。eノードBは,ビームフォーミングベクトルと,ランクと,CQIとを計算する際に,この構造を使用できる。報告目的のために使用される共分散構造は,特定の時間-周波数粒度で計算されることができる。) キ「」(4/5?5/5ページ) ([当審仮訳]: 4 結論本稿では,リリース9のためにTDD及びFDD双方においてデュアルストリームビームフォーミングのサポートにおけるフィードバックメカニズムに対する異なるオプションを概略を述べた。フィードバックメカニズムの選択は,UE及びeノードBにおいて利用可能なDLチャネルの知識に依存する。UEがすべての送信アンテナからのチャネルを推定することができれば,FDD及びTDDシステムの双方においてデュアルビームフォーミング利得を活用することが可能である。利得は,UEにおけるTｘ/Rｘに対する非対称的なアンテナコンフィギュレーションに対して達成可能であり,UEにおけるTｘ/Rｘチェーンにおける較正のミスマッチにより影響を受けない。さらに,このようなシナリオでは,UEからのCQI報告は,干渉に対応し,ビームフォーミング利得を捕捉することができる。このケースでは,ビームフォーミング利得は,CRSを送信するアンテナだけでなく,送信において使用されるすべてのアンテナからのものであってもよい。リリース8は,4つのCRS送信までサポートし,それに関連する大きなオーバーヘッドを有するので,閉ループ又は部分フィードバック動作を可能とするために,リリース10で構想されているCSI-RSと同様の低デューティーサイクルで低オーバーヘッドのRSの導入を検討する価値がある。このような動作は明らかにFDDにおいて必要であるが,TDD,換言すればチャネルの相互関係原理に基づくeノードBにおける開ループチャネル状態推定が,ダウンリンクチャネルについての部分的な情報のみを提供することができる又は較正の問題が存在するシナリオにおいても,また有益である。それゆえ,以下を推奨する。・チャネル状態測定のためのCSI-RSのサポート及び対応するCQI/RI/PMI報告メカニズムを含む,FDDシステムに対するデュアルストリームビームフォーミングのサポートにおける閉ループモード。・TDD動作に対する開ループ又は部分フィードバックモード。TDDに対する閉ループモードもまた考慮されるべき。) なお,上記ア?キの記載は,本件の2009年3月20日を優先日とする優先権主張の基礎となるUS61/162118に記載されている内容と全く同一である。上記ア?キの記載及び図面並びに当業者の技術常識を考慮すると, a 上記ア?キの記載によれば,UEはeノードBにフィードバックしており,UEはフィードバック情報を発生していることは明らかであるから,引用例には,UEによりフィードバック情報を発生させるための方法が記載されていると認められる。また,eノードBに対してフィードバック情報を送信していることも明らかである。 b 上記イの記載によれば,UEにおけるチャネル知識として,CRSポートをチャネル推定に用いることが示されており,上記ウには,測定と報告のためにCSI-RSが提供されること,上記カには,CQI/RIを計算するためにDM-RSを使用することも,それぞれ記載されている。そして,CRS,CSI-RS,DM-RS等のRS(基準信号)は,eノードBからダウンリンクで送信される情報であることは,当業者における技術常識である。したがって,引用例には,eノードBからダウンリンクの情報を受信することが記載されていると認められる。 c 上記イの記載によれば,動作モードはUEにより報告されるフィードバックのタイプに基づいて類別されるものであり,上記ウ,エ,オの記載によれば,各モードにおいてそれぞれに対応するフィードバック情報を生成するところ,上記キの記載によれば,フィードバックメカニズムの選択は,UE及びeノードBにおいて利用可能なDLチャネルの知識に依存するものである。したがって,引用例には,フィードバック情報発生に対するモードを選択すること,及び,選択したモードに基づいてフィードバック情報を発生させること,が記載されていると認められる。 d 上記ウの記載によれば,閉ループモードでは,UEは,CQIとランクと好ましいプリコーディングベクトルを,eノードBにフィードバックしている。また,上記オの記載によれば,部分フィードバックモードでは,UEは,CQIとランクと選んだプリコーディングベクトルを,eノードBにフィードバックしている。したがって,引用例には,選択したモードが,閉ループモードまたは部分的フィードバックモードであるとき,フィードバック情報は,CQIとランクとプリコーディングベクトルとを含むことが記載されていると認められる。 e 上記エの記載によれば,開ループモードでは,UEは,CQIとランクとを,eノードBにフィードバックしている。そして,上記エの記載によれば,完全なチャネル相互関係が仮定される場合と,部分的にチャネル相互関係が適用可能である場合とで,それぞれの方法でCQIとランクとが計算されることが記載されている。そして,上記エには「送信機において完全なチャネル相互関係が仮定されれば,以下のオプションが考慮され得る。」と記載されているところ,当該オプションでは「eノードBにおける送信ビームフォーミング」,「b. eノードBは,ビーム方向を形成する際に,擬似固有ビームフォーミングを使用する。eノードBは,取得した方向に沿って送信するために,UEにより報告されたCQIとランクとを使用する。」と記載されているから,ここで言う「送信機」とはeノードBの送信機であることは明らかである。したがって,引用例には,選択したモードが,開ループモードであるとき,フィードバック情報は,CQIとランクとを含み,前記CQIと前記ランクは,完全なチャネル相互関係または部分的なチャネル相互関係がeノードBの送信機において使用可能であるか否かに基づいて計算されることが記載されていると認められる。以上を総合すると,引用例には以下の発明(以下,「引用発明」という。)が記載されていると認める。「UEによりフィードバック情報を発生させるための方法において, 前記方法は, eノードBからダウンリンクの情報を受信することと, フィードバック情報発生に対するモードを選択することと, 前記選択したモードに基づいて,前記フィードバック情報を発生させることと, 前記eノードBに対して前記フィードバック情報を送信することとを含み, 前記選択したモードが,閉ループモードまたは部分的フィードバックモードであるとき,前記フィードバック情報は,CQIとランクとプリコーディングベクトルとを含み, 前記選択したモードが,開ループモードであるとき,前記フィードバック情報は,CQIとランクとを含み,前記CQIと前記ランクは,完全なチャネル相互関係または部分的なチャネル相互関係がeノードBの送信機において使用可能であるか否かに基づいて計算される方法。」 3 対比・判断本願発明と引用発明とを対比すると, (1)引用発明の「UE」,「eノードB」,「フィードバック情報」は,明らかに本願発明の「ワイヤレス通信デバイス」,「基地局」,「フィードバックデータ」に相当する。 (2)本願明細書の【0009】を参酌すれば,本願発明の「ダウンリンクメッセージ」は,共通基準信号(CRS),チャネル状態情報基準信号(CSI-RS),復調基準信号(DM-RS)を含むから,同様の信号を含む引用発明の「ダウンリンクの情報」は本願発明の「ダウンリンクメッセージ」に相当する。 (3)本願発明の「モードを決定する」と引用発明の「モードを選択する」とは,表現が異なるのみであって,実質的な差異は無い。 (4)引用発明は「プリコーディングベクトル」が「1つ以上」か否かを明らかにしていないが,「1つ以上」は「1つ」を含むから,この点は差異にならない。以上を総合すると,本願発明と引用発明とは「ワイヤレス通信デバイスによりフィードバックデータを発生させるための方法において, 前記方法は, 基地局からダウンリンクメッセージを受信することと, フィードバックデータ発生に対するモードを決定することと, 前記決定したモードに基づいて,前記フィードバックデータを発生させることと, 前記基地局に対して前記フィードバックデータを送信することとを含み, 前記決定したモードが,閉ループモードまたは部分的フィードバックモードであるとき,前記フィードバックデータは,チャネル品質インジケータ(CQI)とランクとプリコーディングベクトルとを含み, 前記決定したモードが,開ループモードであるとき,前記フィードバックデータは,CQIとランクとを含み,前記CQIと前記ランクは,完全なチャネル相互関係または部分的なチャネル相互関係が前記基地局の送信機において使用可能であるか否かに基づいて計算される方法。」の点で一致し, 上記「閉ループモードまたは部分的フィードバックモード」及び「開ループモード」に関し,本願発明は「チャネル方向性についての情報に関する閉ループモードまたは部分的フィードバックモード」,「チャネル方向性についての情報に関する開ループモード」とされているのに対し,引用発明は「チャネル方向性についての情報に関する」との事項が明らかでない点で,一応相違している。以下,上記相違点について検討する。本願発明の「チャネル方向性についての情報に関する」との事項は,平成28年5月25日付け手続補正で追加された事項であるが,同日付け意見書では手続補正の根拠は【0051】,【0074】,【0083】とされており,本願明細書には「チャネル方向性」に関して以下の記載がある。「【0051】開ループモード271では,ワイヤレス通信デバイス201bは,チャネル方向性についての何らかの情報を基地局201aに提供しなくてもよい。・・・部分的フィードバックモード225では,ワイヤレス通信デバイス201bは,チャネル品質インジケータ(CQI)とランク情報とともに,観測したチャネル方向性の部分的な表示を,フィードバックデータ208として提供してもよい。・・・」「【0074】・・・開ループモード271において,ワイヤレス通信デバイス201bは,基地局201aに対して,チャネル方向性についての情報を何も提供しないだろう。・・・」「【0083】・・・部分的フィードバックモード225では,ワイヤレス通信デバイス201bは,チャネル品質インジケータ(CQI)438およびランク439情報とともに,観測したチャネル方向性の部分的な表示を提供してもよい。ワイヤレス通信デバイス201bがFDDを使用して動作している場合に,この情報は,好ましいプリコーディング行列441の一部分とすることができる。代替的に,この情報は,アップリンクチャネル218におけるサウンディング基準信号(SRS)226送信が起こらない受信アンテナから見たチャネル442の量子化したバージョンとすることができる。」以上の記載によれば,本願発明の「チャネル方向性についての情報に関する・・・部分的フィードバックモード」とは,「チャネル方向性の部分的な表示を提供する部分的フィードバックモード」を含み,また,本願発明の「チャネル方向性についての情報に関する開ループモード」とは,「チャネル方向性についての情報を何も提供しない開ループモード」を含むと解するのが自然である。ここで,閉ループモードについての言及は見当たらないが,【0083】の「この情報は,好ましいプリコーディング行列441の一部分とすることができる。」との開示によれば,プリコーディングベクトルをフィードバックする本願発明の「閉ループモード」もまた,「部分フィードバックモード」と同様に,チャネル方向性についての情報を提供するものと解するのが自然である。一方,引用例の上記2(2)エの記載によれば,引用発明の「開ループモード」はチャネルの方向性について何の情報も提供しないものであり,同オの記載によれば,引用発明の「部分フィードバックモード」はチャネル方向性の部分的な表示を提供するものである。そして同オの記載によれば,チャネル方向性の部分的な表示の情報はプリコーディング行列の一部分とすることができるのであるから,好ましいプリコーディング行列をフィードバックする引用発明の「閉ループモード」もまた,「部分フィードバックモード」と同様に,チャネル方向性についての情報を提供するものと解するのが自然である。したがって,上記相違点には実質的な相違はない。本願発明の作用効果についても,引用発明との差異は認められない。よって,本願発明は引用発明との間に差異は無く,同一である。また,引用発明に基づいて,引用発明と同一である本願発明を発明することは,当業者にとって容易である。 4 むすび以上のとおり,本願発明は,引用発明と同一であるから,特許法第29条第1項第3号の規定により,特許を受けることができない。また,本願発明は,引用発明に基づいて当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により,特許を受けることができない。よって,結論のとおり審決する。
審理終結日	2016-09-21
結審通知日	2016-09-27
審決日	2016-10-12
出願番号	特願2012-500936(P2012-500936)
審決分類	P 1 8・ 121- WZ (H04J) P 1 8・ 113- WZ (H04J)
最終処分	不成立
前審関与審査官	岡裕之、佐々木洋
特許庁審判長	大塚良平
特許庁審判官	中野浩昌菅原道晴
発明の名称	ビームフォーミング動作に対するフィードバックメカニズム
代理人	井関守三
代理人	奥村元宏
代理人	蔵田昌俊
代理人	福原淑弘

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