ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04L |
|---|---|
| 管理番号 | 1267461 |
| 審判番号 | 不服2011-12949 |
| 総通号数 | 158 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2013-02-22 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2011-06-16 |
| 確定日 | 2012-12-05 |
| 事件の表示 | 特願2008-547830「メディアゲートウェイおよびターミネーション統計パラメータの値の報告方法」拒絶査定不服審判事件〔平成19年 7月 5日国際公開、WO2007/073679、平成21年 6月 4日国内公表、特表2009-521884〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続の経緯・本願発明 本願は、2006年12月20日(パリ条約による優先権主張外国庁受理2005年12月26日、中華人民共和国)を国際出願日とする出願であって、原審において平成23年4月5日付けで拒絶査定され、同年6月16日に審判請求がなされたものであるところ、 本件出願の請求項1に係る発明(以下、「本願発明」という。)は、平成20年7月28日付け国際出願翻訳文提出書の特許請求の範囲、明細書および図面の記載からみて、その特許請求の範囲の請求項1に記載された次のとおりのものである。(以下「本願発明」という。) (本願発明) 「 メディアゲートウェイにより端末の統計パラメータの値を報告する方法において、 メディアゲートウェイにおいて事象を構成し検出し、事象のパラメータ中で報告される少なくとも1つの統計パラメータの識別子を設定し、 事象に対するトリガー条件が満たされていることを検出したとき、事象のパラメータ中に設定された統計パラメータの識別子にしたがってメディアゲートウェイ制御装置へ統計パラメータの値を報告するステップを含んでいる方法。」 2.引用例に記載された発明 原査定の拒絶の理由に引用された刊行物である国際公開第02/05538号パンフレット(以下、「引用例」という。)には、「CHARGING IN COMMUNICATION NETWORKS HAVING SPLIT CONTROL PLANES AND USER PLANES」(邦訳:分離された制御平面とユーザ平面を有する通信ネットワークにおける課金)として図面と共に次の記載がある。 イ.「 BACKGROUND This invention relates to methods and apparatus for telecommunication and in particular to charging in a packet-switched communication system having a split control- plane/user-plane architecture and to use of Media Gateway Control protocol mechanisms to handle parameters needed in call detail records in such a communication system. In a packet data communication system, information is exchanged as packets of digital data, or datagrams. Each data packet includes address information that enables the system to direct each packet on its own way through the system from a sender to a receiver. Thus, a packet data communication system does not maintain a continuous connection between a sender and a receiver. Packet data communication systems are sometimes called "connection-less" and packet-switched systems, distinguishing them from traditional telephony systems in which continuous connections are established between senders and receivers. Thus, traditional telephony systems are sometimes called "connection-oriented" and circuit-switched systems.」 (1頁4?18行) (イ.邦訳) 「 背景 この発明は、通信のための方法および装置に関し、特に、分離された制御平面/ユーザ平面構造を有するパケット交換通信システムにおける課金、および、そのような通信システムでの詳細な発信記録作成に必要なパラメータを扱うためにメディアゲートウエイ制御プロトコル機構を使用することに関します。 パケットデータ通信システムでは、情報はデジタルデータのパケット、即ちデータグラムとして交換されます。 各データパケットはそれぞれ、システムがその各パケットを、送り手から受け手に至るシステムを通過する経路上を方向付けることを可能にするアドレス情報を含んでいます。 したがって、パケットデータ通信システムは、送り手と受け手の間に持続的な接続を維持しません。 パケットデータ通信システムは“コネクションレス”なパケット交換システムと呼ばれることがあり、持続的な接続が送り手と受けての間で確立される従来の電話システムと相違します。 そして、従来の電話システムは“コネクション指向”の回線交換システムと呼ばれることがあります。」 ロ.「 Many network operators see an advantage in physically splitting node(s) in a network like that depicted in FIG. 1 into control plane node(s) and user plane node(s), thus better enabling independent scalability of signaling traffic and data traffic. In particular, the number of end-users is scalable independently of the end-user traffic. By connecting each user-plane node to several control-plane nodes and vice versa, it is possible to use the total network capacity more efficiently. Moreover, it is possible to dispose common user-plane nodes between the circuit-switched and the packet- switched portions of the communication network to reduce the necessary network resources even further and to provide a better migration path when circuit-switched equipment is replaced packet-switched equipment. Also, this enables cheaper replacement of the network nodes handling user-plane traffic as technology evolves.」 (4頁37行?5頁9行) (ロ.邦訳) 「 多くのネットワーク事業者が、図1に記載されたようなネットワーク中のノードを、制御平面ノードとユーザ平面ノードへと物理的に分割することによって、制御信号トラフィックとデータトラフィックを独立に拡張可能とする利点を見いだしています。 特に、エンドユーザの数は、エンドユーザトラフィックと独立に拡大可能です。 各ユーザ平面ノードをいくつかの制御平面ノードに接続すること、およびその逆によって、トータルのネットワーク容量をより効率的に使用することが可能になります。 さらに、通信網の回線交換部分とパケット交換部分の間に共通ユーザ平面ノードを配置することによって、必要なネットワーク資源をさらに減らし、かつ回路交換設備をパケット交換設備に置き換えるときに、より良い移行パスを提供することが可能です。 さらに、この手法は、ユーザ平面トラフィックを扱うネットワークノードを、技術が発展するにつれてより安いものに置換することを可能にします。」 ハ.「 When a split architecture is implemented, a protocol for communications between control- and user-plane entities must be defined. Two such protocols are the H.248 and Media Gateway Control (MEGACO) protocols, which are similar enough that they will be called the H.248/MEGACO protocol in this application. The H.248/MEGACO protocol defines, in an open and flexible way, a generic framework for information exchange between control-plane and user-plane entities as well as application-specific packages that can be tailored to the different needs of an application like GPRS. The H.248 protocol is being developed by Study Group 16 of the International Telecommunications Union (ITU) (see Draft Recommendation H.248, ITU (June 15, 2000), which is incorporated here by reference). The MEGACO protocol is being developed in the lETF's MEGACO working group (see N. Greene et al., "Megaco Protocol version 0.8", RFC 2885, IETF (Aug. 2000) and T. Taylor, "Megaco Errata", RFC 2886, IETF (Aug. 2000), which are the successors to N. Greene et al., "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, IETF (Apr. 1999)). In these standardization protocols, the call/application function located in the control plane is called a Media Controller (MC) and the bearer/resource function located in the user plane is called a Media Gateway (MG). An MG normally converts media provided in one type of network to a format required in another type of network, and an MC controls the parts of a call state that pertain to connection control for media channels in an MG. For example, an MG may terminate bearer channels from a circuit- switched network (e.g., DS0 channels in a PSTN) and media streams from a packet- switched network (real-time transport protocol (RTP) streams in an IP network). FIG. 4 depicts such a network that has two nodes and a split architecture. The nodes 402, 404 include respective MCs 406, 408 and respective MGs 410, 412. Communications on the interface between the media controllers, i.e., the control-plane entities, are conducted according to a call/application control protocol. Communications on the interface between the media gateways, i.e., the user-plane entities, are conducted according to a bearer/resource protocol. Communications on the interface between the control-plane and user-plane entities can be conducted according to the H.248/MEGACO protocol. The H.248/MEGACO protocol provides a mechanism called an Event. A Media Controller can send an Event to a Media Gateway to instruct the Media Gateway to detect a condition, parameter, etc. If the Media Gateway detects the identified condition, the Media Gateway informs the Media Controller that the Event has occurred. For example, conditions that might be monitored are the transferred information volume (e.g., the number of sent/received octets/packets) and the time duration of a communication session, which can be used as bases for charging a subscriber for the service provided.」(5頁17行?6頁17行) (ハ.邦訳) 「 分離したアーキテクチャを実装する場合、制御およびユーザ平面実体間の通信用のプロトコルが定義されなければなりません。 そのようなプロトコルの2つの例が、H.248とメディアゲートウエイ制御(MEGACO)プロトコルであり、それらは十分に類似しているので、この出願ではH.248/MEGACOプロトコルと呼ぶことにします。 H.248/MEGACOプロトコルは、オープンで柔軟な方法で、制御平面とユーザ平面実体の間の情報交換用の総括的なフレームワークを定義し、特定応用パッケージと同様にGPRSのようなアプリケーションの異なる必要に適合することができます。 H.248プロトコルは国際電気通信連合(ITU)の研究会16によって開発されています(勧告草案H.248、ITU(2000年6月15日)を参照、それは参照によりここに組込まれます)。 MEGACOプロトコルは、lETFのMEGACO作業グループ(N.グリーンらの「Megacoプロトコル・バージョン0.8」、RFC 2885、IETF(2000年8月)、およびT.テーラーの「Megaco正誤表」、RFC 2886、IETF(2000年8月)を参照、これらはN.グリーンらの「メディアゲートウエイ制御プロトコル・アーキテクチャおよび必要条件」、RFC 2805、IETF(1999年4月)の後継である)の中で開発されています。 これらの標準化プロトコルでは、制御平面にある呼び出し/応用機能はメディアコントローラ(MC)と呼ばれ、ユーザ平面にあるベアラ/リソース機能はメディアゲートウエイ(MG)と呼ばれます。 MGは通常、1つのタイプのネットワーク中で提供されるメディアを、別のタイプのネットワーク中で要求されるフォーマットに変換します。また、MCは、MGの中のメディア・チャンネルの接続制御に関係する、通話状態の一部分を制御します。 例えば、MGは、回線交換網(例えばPSTNの中のDS0チャンネル)からのベアラー・チャンネルを終端するかもしれませんし、パケット交換網からのメディアストリーム(IPネットワークの中のリアル・タイム・トランスポート・プロトコル(RTP)ストリーム)を終端するかもしれません。 図4は、2つのノードがある分離アーキテクチャのネットワークを示します。 ノード402および404はそれぞれのMC 406、408、それぞれのMG 410、412を含みます。 メディアコントローラ(つまり制御平面実体)間のインターフェース上の通信は、呼び出し/業務処理制御プロトコルによって導かれます。 メディアゲートウエイ(つまりユーザ平面実体)間のインターフェース上の通信は、ベアラ/資源プロトコルによって導かれます。 制御平面とユーザ平面実体間のインターフェース上の通信は、H.248/MEGACOプロトコルによって導くことができます。 H.248/MEGACOプロトコルは、イベントと呼ばれる機構を提供します。 メディアコントローラは、メディアゲートウエイへイベントを送って、メディアゲートウエイに条件、パラメータなどを検知するように命じることができます。 メディアゲートウエイが識別された条件を検知した場合、メディアゲートウエイはメディアコントローラにイベントが生じたことを通知します。 例えば、モニターされるかもしれない条件は、転送された情報の量(例えば送信/受信されたオクテット/パケットの数)および通信セッションの時間期間です。それらは加入者に提供したサービスに対する課金の基礎として使用することができます。」 ニ.「 This procedure is depicted in FIG. 6, which for simplicity, assumes that a communication path is already established between peer entities 1, 2 and shows only the signaling required for volume-based or time-based charging. As step 1 of the procedure, the Media Controller sends/sets an Event to order the Media Gateway to report back when a specific volume threshold is encountered. In steps 2a, 2b, 2c, user-plane packets are transferred between the peer entities. In step 3, the Media Gateway discovers that the volume threshold is reached (i.e., the event has occurred), and it therefore notifies the Media Controller of the occurrence. In accordance with the H.248/MEGACO protocol, an MG can notify an MC of the occurrence of an event by sending a Notify command, which may include a TerminationlD and an ObservedEvents Descriptor to inform the MC of the event(s) detected. The ObservedEvents Descriptor might include the RequestlD of the Events Descriptor that triggered the notification and the event(s) detected, with the parameters associated with the event(s) and the detection time(s).」(10頁1?14行) (ニ.邦訳) 「 この手続きは、図6に示されており、そこでは単純化のために同位エンティティ1,2間で通信路が既に確立されていると仮定し、ボリュームに基づいた、または時間に基づいた課金に必要とされるシグナリングだけを示しています。 手続きのステップ1として、メディアコントローラは、メディアゲートウエイに特定のボリュームしきい値に達したときに報告を返すように命じるために、イベントを送信/設定します。 ステップ2a、2b、2cの中で、ユーザ平面パケットが同位エンティティ間で転送されます。 ステップ3で、メディアゲートウエイは、ボリュームしきい値に達した(つまり、イベントが発生した)ことを発見し、その発生をメディアコントローラに通知します。 H.248/MEGACOプロトコルに従って、MGは、Notifyコマンドを送ることにより、イベントの発生をMCに通知することができます。このNotifyコマンドには、検知されたイベントをMCに通知するために、TerminationlDおよびObservedEventsディスクリプタを含めることができます。 このObservedEventsディスクリプタは、イベントおよび検知時刻に関連したパラメータと共に、検知されたイベントおよび通知を引き起こしたイベント・ディスクリプタのRequestlDを含んでいるかもしれません。」 上記引用例の記載及び関連する図面ならびにこの分野における技術常識を考慮すると、 まず、上記引用例記載の方法は、上記ハ.引用例図4にあるような「メディアゲートウエイ」と「メディアコントローラ」の間の通信を行う「H.248/MEGACOプロトコル」を前提とする方法であって、 上記ハ.後段の記載によれば、該「H.248/MEGACOプロトコル」には、「イベント」と呼ばれる機構が存在して、 「メディアコントローラは、メディアゲートウエイへイベントを送って、メディアゲートウエイに条件、パラメータなどを検知するように命じることができ」、「メディアゲートウエイが識別された条件を検知した場合、メディアゲートウエイはメディアコントローラにイベントが生じたことを通知」するとあるから、 『メディアゲートウエイによりイベントが生じたことを通知する方法』ということができる。 したがって、上記引用例には以下の発明(以下、「引用発明」という。)が開示されている。 (引用発明) 「メディアゲートウエイによりイベントが生じたことを通知する方法において、 メディアコントローラは、メディアゲートウエイへイベントを送って、メディアゲートウエイに条件、パラメータなどを検知するように命じ、 メディアゲートウエイが識別された条件を検知した場合、メディアゲートウエイはメディアコントローラにイベントが生じたことを通知するステップを含んでいる方法」 3.対比・判断 本願発明と引用発明とを対比する。 まず、引用発明の「メディアゲートウエイ」は、本願発明の「メディアゲートウェイ」であり、、 引用発明の「メディアコントローラ」における「コントローラ」とは「制御装置」のことであって、「メディアゲートウエイ」を制御しているから、本願発明の「メディアゲートウェイ制御装置」にあたる。 また、引用発明の「イベント」は「事象」であり、「通知」は「報告」ということができ、 本願発明の「端末の統計パラメータの値」も一つの事象の現れた結果であるから、引用発明の「イベントが生じたこと」と対比すると、ともに「事象の発生」の点で一致する。 また、引用発明の「メディアコントローラは、メディアゲートウエイへイベントを送って、メディアゲートウエイに条件、パラメータなどを検知するように命じ」るステップの部分において、この動作を「メディアゲートウェイ」の側からみれば、「メディアゲートウェイ」において検知すべきイベント(事象)の構成が、「条件、パラメータなど」として設定されており、結果として検出されて報告されているといえるから、 本願発明と引用発明は、「メディアゲートウェイにおいて事象を構成し検出し、パラメータを設定」する点で一致する。 そして、引用発明の「メディアゲートウエイが識別された条件を検知した場合、メディアゲートウエイはメディアコントローラにイベントが生じたことを通知するステップ」の部分において、 「メディアゲートウエイが識別された条件を検知した場合」とは、「事象に対する条件が満たされていることを検出したとき」ということであり、 その結果として、「メディアコントローラにイベントが生じたことを通知」(メディアゲートウェイ制御装置へ事象の発生を報告)しているから、前記の「条件」は通知(報告)動作の引き金(トリガー)となる条件であって『トリガー条件』ということができる。 したがって、本願発明と引用発明とは、以下の点で一致し、また相違する。 (一致点) 「 メディアゲートウェイにより事象の発生を報告する方法において、 メディアゲートウェイにおいて事象を構成し検出し、パラメータを設定し、 事象に対するトリガー条件が満たされていることを検出したとき、メディアゲートウェイ制御装置へ事象の発生を報告するステップを含んでいる方法。」 (相違点) (1)「事象の発生」に関し、本願発明は「(端末の)統計パラメータの値」であるのに対し、引用発明は単に「イベントが生じたこと」である点。 (2)設定し、報告する「パラメータ」に関し、 本願発明は「事象のパラメータ中で報告される少なくとも1つの統計パラメータの識別子」を設定し、「事象のパラメータ中に設定された統計パラメータの識別子にしたがって」報告するのに対し、 引用発明は「メディアコントローラは、メディアゲートウエイへイベントを送って、メディアゲートウエイに条件、パラメータなどを検知するように命じ、 メディアゲートウエイが識別された条件を検知した場合、メディアゲートウエイはメディアコントローラにイベントが生じたことを通知する」点。 上記相違点(1)の「(端末の)統計パラメータの値」の点に関し検討するに、 引用発明の「メディアゲートウエイ」において検知される「条件、パラメータ」として、引用例には、「(端末間で)転送された情報の量(例えば送信/受信されたオクテット/パケットの数)および通信セッションの時間期間」(上記ハ.6ページ14?16行)などが例示されており、これらが統計量としての「値」を有するのは自明であり、その値を報告するのも適宜なことであるから、「(端末の)統計パラメータの値」とした相違点(1)は格別のことではない。 上記相違点(2)の「事象のパラメータ中で報告される少なくとも1つの統計パラメータの識別子」を設定し、「事象のパラメータ中に設定された統計パラメータの識別子にしたがって」報告する点について検討する。 一般に、複数のデータ項目を区別して取り扱うために、識別力のある「識別子」などを設定して、このような識別子にしたがってデータ項目を取り扱うのは慣用手段に過ぎないが、 引用例の上記ニ.後段の記載によれば、引用発明の「イベント」(事象)に関連して通知(報告)される「Notifyコマンド」には種々の「ディスクリプタ」、「ID」などから構成されるデータ項目を含み得るものと認められ、これらの「ディスクリプタ」、「ID」などは各データ項目(パラメータ)を区別して取り扱うための識別力のある「識別子」ということができるから、「パラメータの識別子」であって、上記相違点(1)で述べた「統計パラメータ」の「識別子」とすることも当業者であれば適宜になし得ることに過ぎない。 したがって、「事象のパラメータ中で報告される少なくとも1つの統計パラメータの識別子」を設定し、「事象のパラメータ中に設定された統計パラメータの識別子にしたがって」報告するとした相違点(2)も、引用例の記載より当業者であれば容易になし得たことであって、格別のことではない。 そして、本願発明の効果も引用発明および引用例の記載から当業者が予測し得る範囲のものである。 4.むすび 以上のとおり、本願発明は、引用発明および引用例の記載に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
| 審理終結日 | 2012-07-04 |
| 結審通知日 | 2012-07-10 |
| 審決日 | 2012-07-25 |
| 出願番号 | 特願2008-547830(P2008-547830) |
| 審決分類 |
P
1
8・
121-
Z
(H04L)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 吉田 隆之 |
| 特許庁審判長 |
石井 研一 |
| 特許庁審判官 |
神谷 健一 矢島 伸一 |
| 発明の名称 | メディアゲートウェイおよびターミネーション統計パラメータの値の報告方法 |
| 代理人 | 佐伯 義文 |
| 代理人 | 渡邊 隆 |
| 代理人 | 実広 信哉 |