【事件の表示】
　特願２００９−５１５５２１「分散無線システムにおけるマルチキャスティングのための無線リソースの統制制御の方法」拒絶査定不服審判事件〔平成１９年１２月２７日国際公開、ＷＯ２００７／１４９３４９、平成２１年１１月１９日国内公表、特表２００９−５４０７６０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
　
１．手続の経緯・本件発明
　
　本願は、２００７年６月１４日（パリ条約による優先権主張外国庁受理２００６年６月１９日、米国）を国際出願日とする出願であって、その請求項１に係る発明は、明細書及び図面の記載からみて、特許請求の範囲の請求項１に記載された次のとおりのものと認める。（以下、「本件発明」という）
　
「分散無線リソース管理においてマルチキャスト／ブロードキャストサービスを統制するための方法であって、
　少なくとも１つのアクセス端末（１２０）にマルチキャストサービス及びブロードキャストサービスのうちの少なくとも１つを提供するために、第１のｅノードＢ（２３０）及び少なくとも１つの第２のｅノードＢ（２３０）によって使用される無線リソース割り当て戦略を交渉するのに使用される情報を、該第１のｅノードＢ（２３０）と該少なくとも１つの第２のｅノードＢ（２３０）との間で通信するステップを含み、
　該少なくとも１つのアクセス端末（１２０）が、マルチキャストサービス又はブロードキャストサービスの少なくとも一方に加入している方法。」
　
２．引用例記載の発明
　
　これに対して、原査定において使用されたCATT, Consideration on MBMS in E-UTRAN, 3GPP TSG RAN WG3 Meeting #52, 3GPP, ２００６年５月８日, R3-060755, URL, http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_52/docs/R3-060755.zip（以下「引用例１」という。）には、
　
「LTE MBMS transmissions may be performed in the following two ways: Multi-Cell Tansmission and Single-Cell Transmission.
For Multi-Cell Transmission, conbining will bring much complexity to MBMS E-UTRAN architecture. According to the current E-UTRAN architecture, the eNodeB is responsible for resource allocation, scheduling and layer 2 segmentation etc. However, in case of implement of macro diversity, either selective combining mode of soft combining mode requires centralized resource or layer 2 information management and harmonization between different eNodeBs. For selective combining mode, it needs to apply SN of RLC to identify the same RLC PDU from different cells. For soft combining, it can be expected that layer 2 of neighbor cells must be abｌe to transmit MBMS packets with identical segmentation and MAC headers in a synchronized manner. The same time-frequency resource for the MBMS transmission must also be utilized in each cell of the cell group.
If combining process for Multi-cell transmissions is located above the eNodeB, it is possible to bring some problems to the current E-UTRAN architecture, such as how to coordinate resource allocation between different assignment nodes, how to solve the RRC termination, and so on.
It should be investigated what is optimal solution of combining process for Multi-cell transmissions.」
（２頁１９行〜３頁３行）
（当審訳：
LTE MBMS伝送は、次の2つの方法：マルチセル伝送及びシングルセル伝送で行うことができる。
マルチセル伝送においては、合成することはMBMS E-UTRANのアーキテクチャに多くの複雑さをもたらすであろう。現在のE-UTRANアーキテクチャによれば、eNodeBは、リソースの割り当て、スケジューリング及びレイヤ2セグメンテーション等を担当する。しかし、マクロダイバーシティを実装する場合、ソフト合成モードと選択合成モードとのどちらの場合にも集中されたリソースやレイヤー2の情報の管理と他のeNodeB間での調和を必要とする。選択合成モードの場合は、異なるセルから同一のRLC PDUを識別するために、RLCのSNを適用する必要がある。ソフト合成の場合は、隣接セルのレイヤ2は同一のセグメントIDとMACヘッダを有するMBMSパケットを同期状態で送信することができなければならない。 MBMS伝送のための同一の時間−周波数リソースは、セル群の各セルに利用されなければならない。
マルチセル伝送のための合成処理がeNodeB上に配置されている場合は、現在のE-UTRANアーキテクチャにおいて、いくつかの問題、異なる割当ノード間でリソース割り当てを調整する方法やRRC終端を解決する方法等をもたらす可能性がある。
なお、マルチセル伝送するための合成方法の最適解が何であるか調査すべきである。）
　
　の記載がある。
　
　上記記載によれば、引用例１には、
　
「LTE MBMS伝送は、次の2つの方法：マルチセル伝送及びシングルセル伝送で行うことができ、
　eNodeBはリソースの割当て、スケジューリング及びレイヤ２セグメンテーション等を担当し、
　マクロダイバーシティを実装する場合、ソフト合成モードと選択合成モードとのどちらの場合にも集中されたリソースやレイヤー2の情報の管理と別のeNodeB間での調和を必要とする
　方法」
　
　が記載されている。（以下「引用発明」という）
　
３．本件発明と引用発明の対比
　
　「MBMS」は「Multimedia Broadcast and Multicast Service」の略語であるから、引用発明の「MBMS」は「マルチキャスト／ブロードキャストサービス」と、
　引用発明の「eNodeB」は「ｅノードＢ」と呼ばれることはそれぞれ周知である。
　
　また、LTEは無線通信に関する技術であるから、「リソース管理」は「無線リソース管理」であり、無線リソースの管理と割当てをeNodeBが担当している。
　そして、「無線リソースの管理と割当て」を担当しているeNodeBが他のeNodeB間での調和を必要としていることは、他のeNodeBでも「無線リソースの管理と割当て」が行われているから、調和を必要としているということなので、「無線リソースの管理と割当て」が各eNodeBで行われていることが前提である。
　一方、前記「無線リソースの管理と割当て」が各eNodeBで行われていることは、「分散」して行われているといえる。
　つまり、引用発明において「無線リソースの管理と割当て」は、eNodeBで分散して行われている。
　
　したがって、本件発明と引用発明は、
　「分散無線リソース管理においてマルチキャスト／ブロードキャストサービスを統制するための方法であって、
　無線リソース管理をｅノードＢで行う
　方法。」
　
　で一致し、下記の点で相違する。
　
　相違点１
　本件発明が、
　「該少なくとも１つのアクセス端末（１２０）が、マルチキャストサービス又はブロードキャストサービスの少なくとも一方に加入している」
　のに対し、引用発明はマルチキャスト／ブロードキャストサービスとアクセス端末の関係について明記されていない点。
　
　相違点２
　無線リソース管理に関し、本件発明は、「少なくとも１つのアクセス端末（１２０）にマルチキャストサービス及びブロードキャストサービスのうちの少なくとも１つを提供するために、第１のｅノードＢ（２３０）及び少なくとも１つの第２のｅノードＢ（２３０）によって使用される無線リソース割り当て戦略を交渉するのに使用される情報を、該第１のｅノードＢ（２３０）と該少なくとも１つの第２のｅノードＢ（２３０）との間で通信するステップ」を有するのに対し、引用発明は、当該ステップが明記されていない点。
　
４．相違点についての検討
　
　相違点１に関し、
　ネットワークでデータを伝送するにあたり、データを受信するアクセス端末が存在することは自明である。
　引用発明はMBMS伝送に関する発明であるから、「マルチキャスト又はブロードキャストサービスの少なくとも１つ」に「アクセス端末が加入」していることは当然である。
　
　相違点２に関し、
　ネットワークでデータを伝送するにあたり、データを受信するアクセス端末が存在することは自明である。
　引用発明はMBMS伝送におけるリソース管理に関する発明であるから、「少なくとも１つのアクセス端末」に「マルチキャスト又はブロードキャストサービスの少なくとも１つ」を提供するための無線リソース管理であることは当然である。
　
　原査定において使用されたLucent Technologies, Coordinated Radio Resource Management for LTE, 3GPP TSG-RAN WG3#51bis, 3GPP, ２００６年４月３日, R3-060487, ＵＲＬ, http://www/3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_51bis/docs/Rd-060487.zip（以下「引用例２」という）には、
「The RRM architecture in LTE categorizes the RRM functions into decentralized RRM and centralized handling of certain RRM functions as in [8].  Most of the RRM functions fall in the decentralized functions category with the centralized RRM function to handle coordination among distributed RRM functions.  The architecture of the centralized handling of certain RRM functions could have two alternatives; the centralized RRM function locates at a higher hierarchical node or distributed among the RRM functions in the decentralized RRM.」
（１頁１９〜２３行：「2. Discussion」の第１パラグラフ）
（当審訳：
　[8]は、LTEのRRMアーキテクチャを、非集中RRMと集中処理を行う特定RRMに分類します。多くのRRM機能は、分散RRM機能間の調整を処理する集中RRM機能を有する非集中機能に分類されます。特定RRM機能の集中処理アーキテクチャには、集中RRM機能が、高い階層ノードに集中RRMが存在するか、非集中RRM中のRRM機能に分散しているか、という２つの選択肢があります。）
　
「The distributed RRM architecture for the centralized RRM handling is shown in Figure 2.  The distributed RRM architecture is designed to have one of the decentralized RRM functions as the designated supervisor to trigger centralized handling and to coordinate among RRM functions.  The distributed RRM architecture would allow the decentralized RRM to have a direct communication and to reach to decision on coordination.  This would minimize the delay of RRM coordination.  However, a protocol of coordinated RRM needs to be defined in the distributed RRM architecture to have a general coordination agreement and to avoid competing decision among RRMs.」
（２頁２〜７行）
（当審訳：
　集中RRM処理のための分散RRMアーキテクチャを図2に示す。分散RRMアーキテクチャは、集中処理の開始とRRM機能間の調整を行う指定スーパーバイザーとして１つの分散型RRM機能を指定するように設計されている。分散RRMアーキテクチャは、非集中RRMが直接通信を行いコーディネートを行って決定をすることができる。これはRRM調整の遅れを最小限にするであろう。しかしながら、協調RRMプロトコルは、分散RRMアーキテクチャで、総合調整合意とRRM間の競合回避の決定をする必要がある。）
　
　そして図２には、eNodeB-1、eNodeB-2、eNodeB-3が共にRRM+集中RRMであって、eNodeB-1からeNodeB-2とeNodeB-3へIM Reconfig Requestを送信し、eNodeB-2とeNodeB-3からeNode-1へIM Reconfig Responseが送信されることが記載されている。
　
「The coordinated RRM scheme is a protocol defined for the centralized RRM handling in the distributed RRM architecture. The coordinated RRM scheme would jointly optimize the cluster radio resource control by coordinating the decision of distributed RRM functions in the cluster.   The multi-cell RRM decisions, such as load-based handover and reconfiguration of radio resources for interference coordination are one of the issues in the LTE e-UTRAN architecture consideration.  The multi-cell RRM decisions would benefit the overall resource allocation and system performance.  However, it is necessary to avoid the potential competing RRM points when multi-cell RRM decisions are considered.  The coordinated RRM scheme is to define the inter-RRM communication protocol, radio resource elements and functions for joint management, and the decision function for joint radio resource management.  The defined functions in the coordinated RRM scheme would allow the system to perform the resource management jointly in a cluster and to avoid any competing decision among RRM functions.   The coordinated RRM schemes need to perform coordination of multi-vendor RRM in a cluster without specifying the actual RRM algorithm running at the each distributed node.  The required functions of the coordinated RRM scheme are as follows,
・ Protocol for inter-RRM communication - The RRM functions in the hierarchical network structure are usually in a centralized location (e.g., RNC) with distributed sub-functions in the distributed nodes (e.g. Power management in HSDPA in the Node B) in UMTS.   The inter-RRM communication is a client-server one-to-one communication between the node B and the RNC.  The majority of the RRM functions are located in the RNC.  Since the majority of the RRM functions envision locating at the e-NB, the inter-RRM communication is a distributed protocol design with multiple capabilities.  The inter-RRM communication protocol in the LTE needs to support peer-to-peer, one-to-many, and broadcast communication.
   o  The peer-to-peer communication allows inter-RRM direct negotiation between 2 distributed nodes (e-NBs) in a cluster without going through the centralized node (RRM server or RNC). The peer-to-peer communication capability would minimize the process delay and jointly optimize the system resource control.  A typical example of peer-to-peer RRM communication is the handover between 2 e-NBs.  The direct RRM communication between 2 e-NBs would expedite the handover process and reduce the potential performance degradation during handover.」
（２頁１１行〜３頁２１行）
（当審訳：
　協調RRM方式は、分散RRMアーキテクチャの集中RRM処理のために定義されたプロトコルである。協調RRM方式は、クラスタ内の分散RRM機能の決定を調整することによって、クラスタの無線リソース制御を共同で最適化します。負荷ベースハンドオーバや干渉調整のための無線リソースの再構成などのマルチセルRRMの決定は、LTE E-UTRANのアーキテクチャを考慮した問題の一つである。マルチセルRRMの決定は、全体の資源配分とシステム性能に利益をもたらす。しかし、マルチセルRRMの決定には、潜在的な競合RRM点を避ける必要がある。調整されたRRM方式は、RRM間通信プロトコル、無線リソース要素及び共同管理のための機能、および共同RRMのための関数の決定、を定義することである。協調RRM方式において定義された関数は、システムがクラスタ内で共同で資源管理を実行して、RRM機能のうち任意の競合する決定を避けることができる。協調RRMスキームは、各分散ノードで実行されている実際のRRMアルゴリズムを指定せずにクラスタ内のマルチベンダーRRMの調整を実行する必要があります。調整されたRRMスキームの必要な機能を下記に示す。
・RRM間通信プロトコル−階層型ネットワーク構造のRRM機能は、UMTSの分散ノード（例：ノードBでのHSDPAの電源管理）におけるサブ機能分散を有する集中配置（例えば、RNC）が通常である。RRM間の通信は、ノードBとRNCとの間の1対1の通信クライアントサーバーである。RRMの機能の大部分はRNCに位置している。RRMの機能の大半をeNodeBに配置しようとすると、RRM間通信は、複数の機能を備えた分散プロトコル設計である。LTEにおけるRRM間通信プロトコルは、１対１、１対多、ブロードキャスト通信をサポートする必要がある。
ｏ　１対１通信は、集中ノード（RRMサーバまたはRNC）を経由せずにクラスタ内の２つの分散ノード（例：eNodeB）間のRRM間で直接交渉することができる。ピアツーピア通信機能は、処理遅延を最小限に抑え、共同システムのリソース制御を最適化するであろう。典型的なピアツーピアRRM通信の例は、２つのeNodeB間のハンドオーバである。２つのeNodeB間の直接RRM通信はハンドオーバ処理を迅速化し、ハンドオーバ中の潜在的なパフォーマンス低下を減らすことができる。）
　
　の記載がある。
　
　したがって、引用例２には
　分散RRMアーキテクチャの集中RRM処理に定義された協調RRM方式として、１つのeNodeBが集中RRMで他のeNodeBが非集中RRMとなる分散RRMアーキテクチャが存在し、
　RRM間通信プロトコルは１対１，１対多、ブロードキャストをサポートする必要があり、
　１対１通信では、２つのeNodeB間のRRMで直接交渉をすることが可能である
　分散機能間の調整を行うRRMアーキテクチャ
が記載されている。
　
　引用例２のRRMは「Radio Resource Management」の略語であるから、分散RRMは「分散無線リソース管理」である。
　また、１対１通信における各eNodeB間のRRMで直接交渉を行うためには、各eNodeB間のRRMで使用する情報を通信する必要があることは明らかである。
　つまり、分散無線リソース管理の方法として、「第１のｅノードＢ及び少なくとも１つの第２のｅノードＢによって使用される無線リソース割当て戦略を交渉するのに必要とされる情報を第１のｅノードＢ間と少なくとも１つのｅノードＢとの間で通信する」方法は、引用例２に記載されている。
　
　引用発明は、前記のように「少なくとも１つのアクセス端末（１２０）にマルチキャストサービス及びブロードキャストサービスのうちの少なくとも１つを提供するため」の無線リソース管理であることは当然であり、具体的な管理方法については記載されていないもののeNodeBで分散して無線リソースを管理している。
　そして、引用例２には、分散無線リソース管理の方法として、「第１のｅノードＢ及び少なくとも１つの第２のｅノードＢによって使用される無線リソース割当て戦略を交渉するのに必要とされる情報を第１のｅノードＢ間と少なくとも１つのｅノードＢとの間で通信する」方法が記載されている。
　よって、引用発明における「少なくとも１つのアクセス端末（１２０）にマルチキャストサービス及びブロードキャストサービスのうちの少なくとも１つを提供するため」の「分散無線リソース管理」方法として、引用例２に記載されるような「第１のｅノードＢ及び少なくとも１つの第２のｅノードＢによって使用される無線リソース割当て戦略を交渉するするのに必要とされる情報を第１のｅノードＢ間と少なくとも１つのｅノードＢとの間で通信する」方法を用いることは容易である。
　
５．むすび
　
　したがって、請求項１記載の発明は引用発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論の通り審決する。