【事件の表示】
　特願２０１２−５００９３６「ビームフォーミング動作に対するフィードバックメカニズム」拒絶査定不服審判事件〔平成２２年　９月２３日国際公開，ＷＯ２０１０／１０７９４５，平成２４年　９月１０日国内公表，特表２０１２−５２１１８０〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は，２０１０年３月１７日（パリ条約による優先権主張外国庁受理　２００９年３月２０日　米国，２０１０年３月１６日　米国）を国際出願日とする出願であって，平成２６年１２月１２日付けで拒絶査定がされ，これに対し，平成２７年５月７日に拒絶査定不服審判が請求されるとともに同日付けで手続補正がされ，その後，当審において平成２８年２月１日付けで拒絶理由が通知され，同年５月２５日付けで手続補正がされたものである。
　その請求項１に係る発明（以下，「本願発明」という。）は，平成２８年５月２５日付け手続補正書により補正された特許請求の範囲の請求項１に記載された次のとおりのものと認める。
「ワイヤレス通信デバイスによりフィードバックデータを発生させるための方法において，
　前記方法は，
　基地局からダウンリンクメッセージを受信することと，
　フィードバックデータ発生に対するモードを決定することと，
　前記決定したモードに基づいて，前記フィードバックデータを発生させることと，
　前記基地局に対して前記フィードバックデータを送信することとを含み，
　前記決定したモードが，チャネル方向性についての情報に関する閉ループモードまたは部分的フィードバックモードであるとき，前記フィードバックデータは，チャネル品質インジケータ（ＣＱＩ）とランクと１つ以上のプリコーディングベクトルとを含み，
　前記決定したモードが，チャネル方向性についての情報に関する開ループモードであるとき，前記フィードバックデータは，ＣＱＩとランクとを含み，前記ＣＱＩと前記ランクは，完全なチャネル相互関係または部分的なチャネル相互関係が前記基地局の送信機において使用可能であるか否かに基づいて計算される方法。」
２　引用発明
（１）引用例が電気通信回線を通じて公衆に利用可能となった時について
　まず，当審から通知した拒絶の理由に引用された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等，おそらく全く新規なものもあります。それらは，会議サーバにアップロードされますが，（最近まで）会議中は公開サーバにアップロードされてもされなくてもよいとされています。（２０１４年以降，ほとんどの会議のために，会議サーバーの内容は公開サーバ上のフォルダにミラーリングされていますが，これらのコピーは会議の終了後すぐに削除されます。）
　会議の終了後すぐ−同日又は最悪でも数日以内−に，会議中に作成されたTDocsは秘書によって公開サーバへアップロードされます。時折，会議からのいくつかの事項について多分１週間後までに解決できず，会議の終了後に作成される非常に遅い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といった各国・各地域の標準化団体により１９９８年１２月に設立された標準化団体間のプロジェクトであり，W-CDMAとGSM発展型ネットワークを基本とする第３世代携帯電話システム及びそれに続く第３．９世代移動通信システムに対応するLTE，第４世代移動通信システムに対応するLTE-Advanced等，移動通信システムの仕様の検討・作成を行っている国際的な標準化組織であるから，そのホームページの情報は十分に信用がおけるものである。そして，プロジェクトにおけるIPRポリシーが規定されており，IPRにおける公知日の重要性を十分に認識しているからこそ，上記FAQにTDocや仕様の公知日（公的に利用可能となった時）の決定方法が詳述されていると解される。したがって，上記FAQには，3GPPの会議寄稿文書（TDoc）及び仕様（Spec）の特定のバージョンが公的に利用可能になった時点をどのようにして決定するかについての，3GPPの公式な見解が示されていることは明らかである。
　そして，上記FAQの記載によれば，3GPPの会議寄稿文書（TDoc）は，少なくともTDocを作成した著者自身又はグループの秘書がTDocを公開ファイルサーバにアップロードした時点で，公的に利用可能になるといえる（上記（ア）本文の第１段落参照。）。そして，アップロードした日時は，TDocファイルのアップロード日付／タイムスタンプに示されるものである（上記（ア）本文の第５段落及び（イ）本文の第１段落参照。）。
イ　引用例（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ボタンをクリックすると，
　
　　
　
１件ヒットしたサーチ結果画面が表示され，
「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ボタンをクリックすると，
　
　
　
４件ヒットしたサーチ結果画面が表示され，いずれのヒット項目についても，記載されている日付は「Return files updated after」と「Return files updated before」の日付の範囲内のものである。
　
　
　
　したがって，サーチ用画面にて，キーワードを入力し，サーチエリアを選択し，「Return files updated after」，「Return files updated before」に日付を入力して，Searchボタンをクリックすると，当該キーワードを含む文献をファイルのupdate日を特定して検索していることは明らかである。
（イ）次に，ヒットした項目の詳細な情報を見るために，上記（ア）の１件ヒットしたサーチ結果画面の項目中の「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は公的に利用可能になるといえる。
　請求人は平成２８年５月２５日付け意見書において，アップロードの際に別途掲載日時を設定することやアップロード後に許可を得てから掲載されることなどがあることを例に挙げて，アップロードされると即掲載されるとは限らずアップロード日時と掲載日時は必ずしも一致するものではない旨主張するとともに，メールに添付されたファイルを事務官（［当審注］：［当審仮訳］では，「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の公開ファイルサーバにアップロードされることにより，公衆に利用可能となったと解するのが相当である。
　したがって，引用例は，本件出願の最先の優先日である２００９年３月２０日より前の２００９年３月１９日に，電気通信回線を通じて公衆に利用可能となっていたと認める。
（２）引用例に記載された発明
　引用例には，図面とともに以下の事項が記載されている。
ア　「
」（１／５〜２／５ページ）
（［当審仮訳］：
２．１　ビームフォーミング動作
　[4]，[5]に示されるように，送信機側のビームフォーミングは，送信機においてチャネル知識が利用可能であるときに，著しい利得を提供することができる。単一レイヤのビームフォーミングに対して，送信は，最も大きい固有値に対応するチャネル共分散行列の固有ベクトルに沿って生じる。このケースでは，受信したＳＩＮＲを改善することにより，容量利得が取得される。
　ＭＩＭＯセットアップでは，固有ビームフォーミングは，最も大きい固有値に対応する固有ベクトルに沿って送信することにより適用され得るので，ビームフォーミングを提供し，利得を多重化する。これらのベクトルが，送信されるビームであると仮定して，ランク選択とチャネル品質インジケータ（ＣＱＩ）計算とを行うことができる。
　最後に，送信機におけるチャネルの知識が不完全又は部分的であるシナリオでは，複数のストリームの送信に擬似固有ビームフォーミングを使用することができる。
・擬似固有ビームフォーミングでは，ビームフォーミングベクトルはチャネルの方向についての知識に基づいて構築される。観察できないチャネルの部分については，既知の固有方向に直交する部分空間中にランダムな方向を仮定することができる。
・例として，ダウンリンクにおける８Ｔｘ，２Ｒｘセットアップを検討する。ｅノードＢは，（ＳＲＳ送信を通して）ＵＥの受信アンテナのうちの１本に対するチャネルの知識を有しており，他の受信アンテナに対する量子化されたチャネル情報が提供されると仮定する。その後，ノードＢは，これら２本の受信アンテナに対するチャネルに対応する固有ベクトルを，ビーム方向として使用することができる。
・その他の例として，ｅノードＢはＲｘアンテナのうちの１本だけに対するチャネルの知識を有していると仮定する。このケースでは，ｅノードＢはこの受信アンテナに対するチャネルの方向で，及び，前の方向と直交するランダムビーム方向で，送信することができる。より良好なダイバーシティ及び／又はより正確なレート予測を提供するために，使用されるランダムビームは，周波数と時間にわたって異なることができる。
・ランク及びＣＱＩを計算する際の，類似するビームフォーミング構築にしたがって，ＵＥにより，このケースにおける送信とフィードバックとを整列させることができる。）
イ　「
」（２／５ページ）
（［当審仮訳］：
２．２　ＵＥ及びｅノードＢにおけるチャネル知識
　まず，本稿で頻繁に使用される２つの表記を定義する。Ｎ＿ＢＦは，ビームフォーミングに使用されるアンテナの数とする。また，Ｎ＿ＲＳは，ユーザがＣＱＩ／ＲＩ及び場合によってはＰＭＩ計算のために送信機からのチャネルの推定を得るための，ＲＳポートの数とする。
　フィードバックメカニズム設計は，ＤＬチャネルに関してＵＥ及びｅノードＢにおいて利用可能な知識に依存する。
　1.　ＵＥにおけるチャネル知識：リリース８のＬＴＥ　ＣＲＳはせいぜい４アンテナポートに対してチャネル推定を提供することができる。ビームフォーミングに対して使用されるアンテナの数（Ｎ＿ＢＦ）は，ＣＲＳポートの数よりも大きいことがある。このケースでは，ＵＥフィードバックはＮ＿ＲＳ個のアンテナポートから観測されるチャネルのみに基づくことができ，ビームフォーミング利得を完全に捕捉することができない。このことは，ＦＤＤ及び場合によってはＴＤＤシステムのためのデュアルストリームビームフォーミングの性能に影響する。
　リリース８のＬＴＥ　ＣＲＳポートは，復調とフィードバックの双方の目的のために使用される。低デューティーサイクルでフィードバックＲＳを導入することにより，異なるＵＥは，フィードバック目的のためにチャネルの知識を取得することができる。このような基準信号のオーバーヘッドは非常に小さい。このようなＲＳ構造を有していることは，ＦＤＤとＴＤＤシステムの双方に対して，（ＲＳ送信に使用されるアンテナポートだけでなく，）すべての送信アンテナからのビームフォーミング利得を提供する。
　2.　ｅノードＢにおけるチャネル知識：ＴＤＤシステムでは，ＤＬチャネルとＵＬチャネルとの相互関係のために，ｅノードＢは，ＵＬを通して送信されるサウンディング基準信号（ＳＲＳ）により，ＤＬにおけるチャネル推定を獲得することができる。しかしながら，ＵＥにおけるＵＬのための送信アンテナの数がＤＬにおける受信アンテナの数と等しくないときには，ｅノードＢはＵＥのいくつかの特定の受信アンテナへのＤＬチャネルについての部分的な知識を持つ。このような場合を「部分的なチャネル相互関係」と呼び，このようなシナリオにおける動作に取り組む。リリース８のＬＴＥでは，ＵＬにおいてアンテナスイッチングＳＲＳ送信が可能であることに留意すべきである。しかしながら，これは，必須な特徴ではなく，例えばスイッチによりもたらされる挿入損失のため，いくつかのＵＥインプリメンテーションでは望ましくない。アンテナスイッチングにより，ｅノードＢは，ＵＥにおけるすべての受信アンテナのためのＤＬチャネル知識を得ることができる。
　以下の動作モードはＵＥにより報告されるフィードバックのタイプに基づいて類別される。）
ウ　「
」（２／５〜３／５ページ）
（［当審仮訳］：
２．３　閉ループモード：
　閉ループ動作では，ＵＥは，利用可能なＮ＿ＲＳ個のアンテナポートから得られたチャネル推定に基づいてＣＱＩ，ランクそして好ましいプリコーディングベクトルを計算し，ｅノードＢにその値をフィードバックする。ｅノードＢは，報告されたプリコーディングベクトルを使用し，報告されたＣＱＩ及びランクに基づいて，ＵＥに送信する。
　このようなスキームは，ＦＤＤとＴＤＤの双方に対して適用可能である。このケースの動作は，送信は，ＵＥにより報告されるプリコーディングベクトルに沿っているので，ＵＥにおけるＴｘ／Ｒｘアンテナの非対称的なコンフィギュレーションと，ＴＸ／ＲＸチェーンにおける可能性ある較正のミスマッチとにより影響を受けない。
　閉ループ動作を可能とするために，以下のメカニズムが導入されることが必要である。
　・ｅノードＢにおけるより多い数の送信アンテナに対するプリコーディング設計
　・ランクと好ましいプリコーディング行列とのシグナリング及びフィードバック
　もしＮ＿ＲＳがＮ＿ＢＦよりも少ない場合に，このような動作により取得されるビームフォーミング利得は限定されることにも留意すべきである。それゆえ，このシナリオにおいてフィードバック目的のためにリリース８のＣＲＳを使用することは，ビームフォーミングにより取得される利得を減少させることがある。そのような限定に関する損失は将来検討される必要がある。
　代替として，（復調のためではなく）測定と報告のためにのみ使用されるＮ＿ＢＦ個のアンテナに対する低デューティーサイクルチャネル状態情報ＲＳ（ＣＳＩ−ＲＳ）を提供する。このようなフィードバックＲＳに対応するオーバーヘッドは非常に小さくすることができる。それゆえ，リリース９において，フィードバック目的のために低デューティーサイクルＣＳＩ−ＲＳの導入を考えることは，高次ＭＩＭＯに対して構想されているＣＳＩ−ＲＳやリリース１０の協調送信と同じく，価値がある。）
エ　「
」（３／５ページ）
（［当審仮訳］：
２．４　開ループモード：
　このシナリオでは，ＵＥはチャネルの方向性について何の情報も提供せず，ＣＱＩと，場合によってはランクとを報告するだけである。
　ＦＤＤモードでは，ＵＥにおけるＣＱＩとランクの計算は，１組の予め規定されたプリコーディング行列に基づくことができる。ＵＥとｅノードＢの双方は，送信において適用されるだろうプリコーディング動作（すなわち，大幅な遅延ＣＤＤ，ビームスイーピング）に合意することができる。ＣＱＩとランクの計算は，大幅なレートの予測ミスマッチを避けるために，この知識に基づくことができる。ＵＥは，計算されたＣＱＩとランクをｅノードＢに報告する。
　ＴＤＤモードでは，以下のシナリオを考慮することができる：
　1.　ＵＥは，部分的に干渉を捕捉するために，リリース８の送信モード７を仮定して，ＣＱＩのみを報告する。ｅノードＢは，チャネル知識と，報告されたＣＱＩとに基づいて，ランクを選択し，異なるレイヤに対するＣＱＩを調節する。
　2.　送信機において完全なチャネル相互関係が仮定されれば，以下のオプションが考慮され得る。
　　a.　すべてのアンテナに対するフィードバックＲＳが存在する（すなわち，Ｎ＿ＲＳ＝Ｎ＿ＢＦ）ならば，ＵＥは，チャネルに適用された固有ビームフォーミングを仮定してＣＱＩ，ランクの選択をすることができる。このケースのランクとＣＱＩの計算は，すべてのアンテナからのビームフォーミング利得と同様に，受信機における干渉構造を考慮することができることに留意すべきである。ＵＥは計算されたＣＱＩ及びランクをｅノードＢに報告する。このシナリオでは，ＵＥにおけるＣＱＩの計算が，ｅノードＢにおける送信ビームフォーミングにマッチしている限り，プリコーダ情報を送信する必要はない。
　　b.　Ｎ＿ＲＳ＜Ｎ＿ＢＦの場合，ＲＳポートにおける固有ビームフォーミングを使用して利用可能なＮ＿ＲＳ個のポートに基づいて，ランク及びＣＱＩ選択はＵＥにおいてなされ得る。ｅノードＢは，報告が基づいているＮ＿ＲＳとは対照的に，Ｎ＿ＢＦ個のアンテナからの送信による余分なビームフォーミング利得を捕捉するよう，ＣＱＩを調整することができる。
　3.　「部分的なチャネル相互関係」が適用可能であれば，以下のオプションを考慮することができる。
　　a.　ＵＥは，次の２つの動作のうちの１つを仮定して，ＣＱＩ及びランクを計算することができる。
　　　i.　 ランク及びＣＱＩの計算においてプリコーディングされていないチャネルを仮定する。
　　　ii.　ランク及びＣＱＩの計算において擬似固有ビームフォーミングを仮定する。このケースでは，ＵＥはＲｘアンテナのためにアップリンクにおけるＳＲＳ送信に対応するチャネル推定を用い，他のレイヤに対して，これらのチャネルに対して直交するランダムなビームを仮定する。ランク及びＣＱＩの計算はそのようなビームフォーミング構造に基づく。
　　b.　ｅノードＢは，ビーム方向を形成する際に，擬似固有ビームフォーミングを使用する。ｅノードＢは，取得した方向に沿って送信するために，ＵＥにより報告されたＣＱＩとランクとを使用する。）
オ　「
」（３／５〜４／５ページ）
（［当審仮訳］：
２．５　部分フィードバックモード：
　このケースでは，ＵＥは，ＣＱＩ及びランク情報とともに，観測したチャネル方向性の部分的な表示を提供する。この情報は，ＦＤＤにおける好ましいプリコーディング行列の一部分とすることができ，またＵＬにおけるＳＲＳ送信が起こらないＲｘアンテナから見たチャネルの量子化したバージョンとすることができる。
　ＦＤＤでは，ＵＥは擬似固有ビームフォーミングスキームに基づいてＣＱＩ及びランクを計算することができる。ランク２について，ＵＥは，プリコーディングベクトルを用い，そして選択されたプリコーダに直交する他の方向を選んで，ＣＱＩ計算を実行し，組み合わせたプリコーディング行列を用いてＣＱＩを計算する。ｅノードＢは，ランクとフィードバックを通して提供された部分的なチャネル情報とにしたがって，擬似固有ビームフォーミングを用いる。
　ＵＥにおける，「部分的なチャネル相互関係」又は著しい較正ミスマッチを持つ，ＴＤＤシステムにおける部分フィードバック送信モードもまた，考慮することができる。このケースでは，ＲＸアンテナ上で観測されるが，ノードＢにより観測可能でないチャネルに関する付加的な情報を，ＵＥが提供することができる。
　・ＵＥにおけるＣＱＩ及びランク計算：ＵＥは，他の受信アンテナに対するチャネルを近似するプリコーディングベクトルとともに，ｅノードＢにおいて知られている，受信アンテナに対するチャネルの推定を使用して，最良のＣＱＩ及びランクを計算する。その後，ＣＱＩと，ランクと，選んだプリコーディングベクトルとをｅノードＢに対して報告する。
　・ｅノードＢにおけるスケジューリング：ｅノードＢは，ビームフォーミングプリコーダを構築するために，そのチャネルの知識とともに，チャネルフィードバック情報を使用する。構築したプリコーダとともに，ＵＥにより選択されたＣＱＩとランクとを使用して，ＵＥをスケジュールする。）
カ　「
」（４／５ページ）
（［当審仮訳］：
３　検討
　次の見解が適っている。
・ＵＥがすべてのビームフォーミングアンテナに対するチャネルの推定を獲得する場合，ＵＥ報告は送信機のすべての送信アンテナからの干渉とビームフォーミング利得を捕捉する。このケースでは，ＦＤＤ及びＴＤＤシステムの双方に対してデュアルストリームビームフォーミング利得が獲得できる。
　○リリース８においてアドバタイズされているＣＲＳポートの数はせいぜい４個（商業的な展開では多分２個）であり，それは復調において使用されるので，それに関係するオーバーヘッドは大きい。同時に，ビームフォーミング動作に対する送信アンテナの数は，アドバタイズされているＣＲＳポートの数よりも多いことがある。
　○リリース１０に対して構想されているＣＳＩ−ＲＳの線に沿って，チャネル局情報フィードバックのためにだけ使用される低デューティサイクル基準信号を導入してもよい。ＣＲＳアンテナポートのみを使用するものに比べて，すべての送信アンテナを使用するビームフォーミング利得は，大きいことがある。すべての送信アンテナに対して低オーバーヘッドＣＳＩ−ＲＳを有することは，ＦＤＤシステムと，場合によってはＴＤＤシステムとにおいて，ビームフォーミング利得を提供することがある。
・送信アンテナの数が４本よりも多いケースに対して，（特にＦＤＤシステムにおいて）ビームフォーミング利得を捕捉するために，新しいプリコーディング構造を考える必要がある。
・時間及び周波数における報告の粒度は，将来検討可能である。特に，周波数選択報告（すなわち，サブバンドベース）又はワイドバンド報告は，リリース８におけるものと同様に考えることができる。
・異なる動作モードにおいて，ランク２送信に対するレイヤシフティングを考えることができる。このようなメカニズムは，部分的フィードバックモードにおいて利益があるかもしれず，オーバーヘッド低減のためにも使用することができる。
・次のパケット送信に対するＣＱＩ／ＲＩを計算するために，（Ｎ＿ＲＳポートから取得されるチャネル推定とともに）ＤＭ−ＲＳを使用することが可能である。このケースでは，ＣＱＩ／ＲＩ報告は，ノードＢからの要求により，非周期的である必要がある。この方法でのＣＱＩ／ＲＩの計算は，ビームフォーミング利得を捕捉するが，このようなメカニズムは，バンドの小さな部分にＵＥ−ＲＳが割り振られているケースに対しては，又は，バースト的なトラフィックソースを持つユーザに対しては，信頼性が低いかもしれない。この報告メカニズムは正確であるが，これは，ＵＥによる頻繁な報告を必要とするので，極端でない移動においてさえ，効率が良くないことがある。
・空間干渉構造とそれらに関係する利得に関する情報をシグナリングする方法もまた，将来調査可能である。これは，ＵＥが，チャネルの部分的な推定を有しているケースに対しても適用可能である。このようなシグナリングの例は以下のとおりである。
　○ＵＥは，ｅノードＢに対して，ＣＱＩ／ＲＩ／ＰＭＩフィードバックとを提供することできる。このケースは，実質的に，先に論じた閉ループプリコーディングである。このケースのビームフォーミング動作は，干渉及びチャネル構造を同時に捕捉することができる。
　○ｅノードＢに対して，干渉共分散構造を信号で知らせてもよい。例えば，これは，支配的な干渉方向がＵＥにおいて検出されるときに適用可能である。これは低デューティサイクル（おそらくは，上位レイヤ）シグナリングに基づいて達成でき，干渉の持続的で長期的な共分散構造が存在するときに使用できる。ｅノードＢは，ビームフォーミングベクトルと，ランクと，ＣＱＩとを計算する際に，この構造を使用できる。報告目的のために使用される共分散構造は，特定の時間−周波数粒度で計算されることができる。）
キ　「
」（４／５〜５／５ページ）
（［当審仮訳］：
４　結論
　本稿では，リリース９のためにＴＤＤ及びＦＤＤ双方においてデュアルストリームビームフォーミングのサポートにおけるフィードバックメカニズムに対する異なるオプションを概略を述べた。
　フィードバックメカニズムの選択は，ＵＥ及びｅノードＢにおいて利用可能なＤＬチャネルの知識に依存する。ＵＥがすべての送信アンテナからのチャネルを推定することができれば，ＦＤＤ及びＴＤＤシステムの双方においてデュアルビームフォーミング利得を活用することが可能である。利得は，ＵＥにおけるＴｘ／Ｒｘに対する非対称的なアンテナコンフィギュレーションに対して達成可能であり，ＵＥにおけるＴｘ／Ｒｘチェーンにおける較正のミスマッチにより影響を受けない。
　さらに，このようなシナリオでは，ＵＥからのＣＱＩ報告は，干渉に対応し，ビームフォーミング利得を捕捉することができる。このケースでは，ビームフォーミング利得は，ＣＲＳを送信するアンテナだけでなく，送信において使用されるすべてのアンテナからのものであってもよい。
　リリース８は，４つのＣＲＳ送信までサポートし，それに関連する大きなオーバーヘッドを有するので，閉ループ又は部分フィードバック動作を可能とするために，リリース１０で構想されているＣＳＩ−ＲＳと同様の低デューティーサイクルで低オーバーヘッドのＲＳの導入を検討する価値がある。このような動作は明らかにＦＤＤにおいて必要であるが，ＴＤＤ，換言すればチャネルの相互関係原理に基づくｅノードＢにおける開ループチャネル状態推定が，ダウンリンクチャネルについての部分的な情報のみを提供することができる又は較正の問題が存在するシナリオにおいても，また有益である。
　それゆえ，以下を推奨する。
・チャネル状態測定のためのＣＳＩ−ＲＳのサポート及び対応するＣＱＩ／ＲＩ／ＰＭＩ報告メカニズムを含む，ＦＤＤシステムに対するデュアルストリームビームフォーミングのサポートにおける閉ループモード。　
・ＴＤＤ動作に対する開ループ又は部分フィードバックモード。ＴＤＤに対する閉ループモードもまた考慮されるべき。）
　なお，上記ア〜キの記載は，本件の２００９年３月２０日を優先日とする優先権主張の基礎となるＵＳ６１／１６２１１８に記載されている内容と全く同一である。
　上記ア〜キの記載及び図面並びに当業者の技術常識を考慮すると，
ａ　上記ア〜キの記載によれば，ＵＥはｅノードＢにフィードバックしており，ＵＥはフィードバック情報を発生していることは明らかであるから，引用例には，ＵＥによりフィードバック情報を発生させるための方法が記載されていると認められる。また，ｅノードＢに対してフィードバック情報を送信していることも明らかである。
ｂ　上記イの記載によれば，ＵＥにおけるチャネル知識として，ＣＲＳポートをチャネル推定に用いることが示されており，上記ウには，測定と報告のためにＣＳＩ−ＲＳが提供されること，上記カには，ＣＱＩ／ＲＩを計算するためにＤＭ−ＲＳを使用することも，それぞれ記載されている。そして，ＣＲＳ，ＣＳＩ−ＲＳ，ＤＭ−ＲＳ等のＲＳ（基準信号）は，ｅノードＢからダウンリンクで送信される情報であることは，当業者における技術常識である。
　したがって，引用例には，ｅノードＢからダウンリンクの情報を受信することが記載されていると認められる。
ｃ　上記イの記載によれば，動作モードはＵＥにより報告されるフィードバックのタイプに基づいて類別されるものであり，上記ウ，エ，オの記載によれば，各モードにおいてそれぞれに対応するフィードバック情報を生成するところ，上記キの記載によれば，フィードバックメカニズムの選択は，ＵＥ及びｅノードＢにおいて利用可能なＤＬチャネルの知識に依存するものである。
　したがって，引用例には，フィードバック情報発生に対するモードを選択すること，及び，選択したモードに基づいてフィードバック情報を発生させること，が記載されていると認められる。
ｄ　上記ウの記載によれば，閉ループモードでは，ＵＥは，ＣＱＩとランクと好ましいプリコーディングベクトルを，ｅノードＢにフィードバックしている。
　また，上記オの記載によれば，部分フィードバックモードでは，ＵＥは，ＣＱＩとランクと選んだプリコーディングベクトルを，ｅノードＢにフィードバックしている。
　したがって，引用例には，選択したモードが，閉ループモードまたは部分的フィードバックモードであるとき，フィードバック情報は，ＣＱＩとランクとプリコーディングベクトルとを含むことが記載されていると認められる。
ｅ　上記エの記載によれば，開ループモードでは，ＵＥは，ＣＱＩとランクとを，ｅノードＢにフィードバックしている。そして，上記エの記載によれば，完全なチャネル相互関係が仮定される場合と，部分的にチャネル相互関係が適用可能である場合とで，それぞれの方法でＣＱＩとランクとが計算されることが記載されている。
　そして，上記エには「送信機において完全なチャネル相互関係が仮定されれば，以下のオプションが考慮され得る。」と記載されているところ，当該オプションでは「ｅノードＢにおける送信ビームフォーミング」，「b.　ｅノードＢは，ビーム方向を形成する際に，擬似固有ビームフォーミングを使用する。ｅノードＢは，取得した方向に沿って送信するために，ＵＥにより報告されたＣＱＩとランクとを使用する。」と記載されているから，ここで言う「送信機」とはｅノードＢの送信機であることは明らかである。
　したがって，引用例には，選択したモードが，開ループモードであるとき，フィードバック情報は，ＣＱＩとランクとを含み，前記ＣＱＩと前記ランクは，完全なチャネル相互関係または部分的なチャネル相互関係がｅノードＢの送信機において使用可能であるか否かに基づいて計算されることが記載されていると認められる。　
　以上を総合すると，引用例には以下の発明（以下，「引用発明」という。）が記載されていると認める。
「ＵＥによりフィードバック情報を発生させるための方法において，
　前記方法は，
　ｅノードＢからダウンリンクの情報を受信することと，
　フィードバック情報発生に対するモードを選択することと，
　前記選択したモードに基づいて，前記フィードバック情報を発生させることと，
　前記ｅノードＢに対して前記フィードバック情報を送信することとを含み，
　前記選択したモードが，閉ループモードまたは部分的フィードバックモードであるとき，前記フィードバック情報は，ＣＱＩとランクとプリコーディングベクトルとを含み，
　前記選択したモードが，開ループモードであるとき，前記フィードバック情報は，ＣＱＩとランクとを含み，前記ＣＱＩと前記ランクは，完全なチャネル相互関係または部分的なチャネル相互関係がｅノードＢの送信機において使用可能であるか否かに基づいて計算される方法。」
３　対比・判断
　本願発明と引用発明とを対比すると，
（１）引用発明の「ＵＥ」，「ｅノードＢ」，「フィードバック情報」は，明らかに本願発明の「ワイヤレス通信デバイス」，「基地局」，「フィードバックデータ」に相当する。
（２）本願明細書の【０００９】を参酌すれば，本願発明の「ダウンリンクメッセージ」は，共通基準信号（ＣＲＳ），チャネル状態情報基準信号（ＣＳＩ−ＲＳ），復調基準信号（ＤＭ−ＲＳ）を含むから，同様の信号を含む引用発明の「ダウンリンクの情報」は本願発明の「ダウンリンクメッセージ」に相当する。
（３）本願発明の「モードを決定する」と引用発明の「モードを選択する」とは，表現が異なるのみであって，実質的な差異は無い。
（４）引用発明は「プリコーディングベクトル」が「１つ以上」か否かを明らかにしていないが，「１つ以上」は「１つ」を含むから，この点は差異にならない。
　以上を総合すると，本願発明と引用発明とは
「ワイヤレス通信デバイスによりフィードバックデータを発生させるための方法において，
　前記方法は，
　基地局からダウンリンクメッセージを受信することと，
　フィードバックデータ発生に対するモードを決定することと，
　前記決定したモードに基づいて，前記フィードバックデータを発生させることと，
　前記基地局に対して前記フィードバックデータを送信することとを含み，
　前記決定したモードが，閉ループモードまたは部分的フィードバックモードであるとき，前記フィードバックデータは，チャネル品質インジケータ（ＣＱＩ）とランクとプリコーディングベクトルとを含み，
　前記決定したモードが，開ループモードであるとき，前記フィードバックデータは，ＣＱＩとランクとを含み，前記ＣＱＩと前記ランクは，完全なチャネル相互関係または部分的なチャネル相互関係が前記基地局の送信機において使用可能であるか否かに基づいて計算される方法。」
の点で一致し，
　上記「閉ループモードまたは部分的フィードバックモード」及び「開ループモード」に関し，本願発明は「チャネル方向性についての情報に関する閉ループモードまたは部分的フィードバックモード」，「チャネル方向性についての情報に関する開ループモード」とされているのに対し，引用発明は「チャネル方向性についての情報に関する」との事項が明らかでない点で，一応相違している。
　以下，上記相違点について検討する。
　本願発明の「チャネル方向性についての情報に関する」との事項は，平成２８年５月２５日付け手続補正で追加された事項であるが，同日付け意見書では手続補正の根拠は【００５１】，【００７４】，【００８３】とされており，本願明細書には「チャネル方向性」に関して以下の記載がある。
「【００５１】
  開ループモード２７１では，ワイヤレス通信デバイス２０１ｂは，チャネル方向性についての何らかの情報を基地局２０１ａに提供しなくてもよい。・・・部分的フィードバックモード２２５では，ワイヤレス通信デバイス２０１ｂは，チャネル品質インジケータ（ＣＱＩ）とランク情報とともに，観測したチャネル方向性の部分的な表示を，フィードバックデータ２０８として提供してもよい。・・・」
「【００７４】
  ・・・開ループモード２７１において，ワイヤレス通信デバイス２０１ｂは，基地局２０１ａに対して，チャネル方向性についての情報を何も提供しないだろう。・・・」
「【００８３】
  ・・・部分的フィードバックモード２２５では，ワイヤレス通信デバイス２０１ｂは，チャネル品質インジケータ（ＣＱＩ）４３８およびランク４３９情報とともに，観測したチャネル方向性の部分的な表示を提供してもよい。ワイヤレス通信デバイス２０１ｂがＦＤＤを使用して動作している場合に，この情報は，好ましいプリコーディング行列４４１の一部分とすることができる。代替的に，この情報は，アップリンクチャネル２１８におけるサウンディング基準信号（ＳＲＳ）２２６送信が起こらない受信アンテナから見たチャネル４４２の量子化したバージョンとすることができる。」
　以上の記載によれば，本願発明の「チャネル方向性についての情報に関する・・・部分的フィードバックモード」とは，「チャネル方向性の部分的な表示を提供する部分的フィードバックモード」を含み，また，本願発明の「チャネル方向性についての情報に関する開ループモード」とは，「チャネル方向性についての情報を何も提供しない開ループモード」を含むと解するのが自然である。ここで，閉ループモードについての言及は見当たらないが，【００８３】の「この情報は，好ましいプリコーディング行列４４１の一部分とすることができる。」との開示によれば，プリコーディングベクトルをフィードバックする本願発明の「閉ループモード」もまた，「部分フィードバックモード」と同様に，チャネル方向性についての情報を提供するものと解するのが自然である。
　一方，引用例の上記２（２）エの記載によれば，引用発明の「開ループモード」はチャネルの方向性について何の情報も提供しないものであり，同オの記載によれば，引用発明の「部分フィードバックモード」はチャネル方向性の部分的な表示を提供するものである。そして同オの記載によれば，チャネル方向性の部分的な表示の情報はプリコーディング行列の一部分とすることができるのであるから，好ましいプリコーディング行列をフィードバックする引用発明の「閉ループモード」もまた，「部分フィードバックモード」と同様に，チャネル方向性についての情報を提供するものと解するのが自然である。
　したがって，上記相違点には実質的な相違はない。
　本願発明の作用効果についても，引用発明との差異は認められない。
　よって，本願発明は引用発明との間に差異は無く，同一である。
　また，引用発明に基づいて，引用発明と同一である本願発明を発明することは，当業者にとって容易である。
４　むすび
　以上のとおり，本願発明は，引用発明と同一であるから，特許法第２９条第１項第３号の規定により，特許を受けることができない。また，本願発明は，引用発明に基づいて当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により，特許を受けることができない。
　よって，結論のとおり審決する。