【事件の表示】
　特願２００６−１５０６９５「サーバ」拒絶査定不服審判事件〔平成１９年１２月１３日出願公開、特開２００７−３２４７７２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１８年５月３０日の出願であって、平成２３年７月６日付けで拒絶査定がなされ、これに対し、同年１０月１１日に拒絶査定に対する審判請求がなされたが、当審において平成２４年１１月２９日付けで拒絶理由通知がなされ、これに対し、平成２５年２月４日付けで意見書が提出されたものである。
　
２．本願発明 
　本願の請求項１に係る発明(以下、「本願発明」という。)は、平成２３年３月２５日付け手続補正書の特許請求の範囲の請求項１に記載された、以下のとおりのものと認める。
　
「グループ通話を管理するサーバであって、
　前記グループ通話に対して通話データを送信する権利である送信権を割り当てている移動局である送信権保有移動局によって送信される通話データを監視する監視部と、
　前記監視部によって監視される前記通話データが所定期間に亘って検出されない場合に、前記送信権保有移動局に割り当てている前記送信権を他の移動局に対して開放する開放部と、
を備えることを特徴とするサーバ。」
　
３．引用発明
　当審の拒絶理由に引用された特表２００４−５３５０９７号公報(以下、「引用例」という。)には、「パケットモードスピーチ通信」に関し、図面とともに以下の事項が記載されている。
　
ア．「【請求項１１】
通信システムのためのパケットモードグループ通信サービスを提供するサーバーシステムであって、上記通信システムの最上部に設けられたグループサーバーを備えたサーバーシステムにおいて、上記グループサーバーが、更に、
少なくとも１つのグループ通信グループ内のグループメンバーの個々のアドレスを記憶するための手段と、
上記グループメンバーからボイスパケットを受信するための手段であって、各受信したボイスパケットは、各パケットがアドレスされる通信グループを識別する情報を含むような手段と、
通信グループ当たり１つのグループメンバーへのスピーチアイテムを順次に許可するための手段と、
グループ通信グループにおけるスピーチアイテムを有する上記グループメンバーから受信した各ボイスパケットを、上記個々のアドレスに基づいて、上記各グループ通信グループにおける各受信メンバーへ別々にユニキャストするための手段と、
を備えたサーバーシステム。
【請求項１２】
通信グループを識別する上記情報は、上記グループサーバーにおいて上記グループに指定されたポートを識別する請求項１１に記載のサーバーシステム。
【請求項１３】
上記移動通信システムの最上部に設けられたコール処理サーバーを更に備え、このコール処理サーバーは、上記グループサーバーにおいてグループ通信の制御平面管理を行う請求項１１に記載のサーバーシステム。
【請求項１４】
スピーチアイテムを許可する上記手段は、更に、
上記許可に応答して、上記許可から所定のアイドル周期の測定をスタートする第１タイマーと、
上記許可されたスピーチアイテムを有する上記１つのグループメンバーからボイスパケットが受信されるたびに上記第１タイマーをリセットする手段と、
上記第１タイマーが時間切れして、上記許可から、又は上記１つのグループメンバーからのボイスパケットの最後の受信から、上記所定のアイドル周期が経過したことを指示する場合に、上記許可されたスピーチアイテムを終了する手段と、
を備えた請求項１１に記載のサーバーシステム。」（３−４頁、【請求項１１】−【請求項１４】）
　
イ．「【００２６】
以下、添付図面を参照して、本発明の好ましい実施形態を詳細に説明する。
本発明は、エンドユーザ間のパケットモード通信と、オーバーレイパケットモードグループ通信サービスとを許すアクセスネットワークとして使用することのできるいかなるデジタル通信システムにも適用できる。本発明は、ＧＰＲＳ型パケット無線をベースとする移動通信システムに特に好ましく使用される。以下、本発明の好ましい実施形態は、ＧＰＲＳサービス及びＵＭＴＳ又はＧＳＭシステムにより説明するが、本発明は、この特定のパケット無線システムに限定されるものではない。本発明の好ましい実施形態に使用されるＩＰボイス通信方法は、ボイスオーバーＩＰ（ＶｏＩＰ）であるが、本発明は、この特定の方法に限定されるものではない。」（１９頁、段落【００２６】）
　
ウ．「【００３５】
制御平面要素については、この論理的分割は、Ｇ−ＵＰＦ及びＵ−ＵＰＦ実施の間に物理的な分離を必ずしも必要とせず、従って、それらを同じコンピュータに配置することができる。
ユーザ及びグループのセッションを管理する役割を果たすＵ−ＣＰＦ２２及びＧ−ＣＰＦ２３は、各々、特定の制御平面シグナリングを必要とする。ＥＴＳＩの３ＧＰＰ（ヨーロピアン・テレコミュニケーションズ・スタンダーズ・インスティテュート、第３世代パートナーシッププロジェクト）の仕様は、いわゆる全ＩＰネットワークにおいてＩＰベースのボイス通信を含む。このような全ＩＰネットワークは、ＩＰネットワークにおいてボイス通信（ボイスオーバーＩＰ即ちＶｏＩＰ）を可能にする。ＶｏＩＰの場合に、ＲＦＣ２５４３において定義されるセッション開始プロトコル（ＳＩＰ）のようなコール制御シグナリングが指定される。それ故、好ましい実施形態では、ＳＩＰは、ＰｏＣコールセッションをサポートしそして管理するように選択される。しかしながら、他のＩＰセッションプロトコルを使用してもよい。更に、本発明の好ましい実施形態では、ＩＰ層のトラフィック分布に含まれるＧ−ＵＰＦ２１及びＵ−ＵＰＦ２０を制御するためにＧ−ＣＰＦ２３及びＵ−ＣＰＦ２２によってメガコ(Megaco)（ＲＦＣ３０１５において定義された）が使用される。しかしながら、ユーザ平面要素のスイッチングを制御するための他の対応するプロトコルが使用されてもよい。更に、転送を取り扱うためにＲＴＰ（ＲＦＣ１８８９において定義されたリアルタイム搬送プロトコル）が選択されており、そしてボイスパケット（ＶｏＩＰ）の配送を取り扱うためにＱｏＳメカニズムが必要とされる。」（２２頁、段落【００３５】）
　
エ．「【００８２】
上述した暗示的シグナリング解決策では、各ユーザは、希望するときに、選択されたグループへ話をするように試みることができる。図８の例を参照すれば、ＭＳのユーザがＰＴＴをプッシュするときには、アップリンクリソースが上述したように予約され、ＭＳは、Ｕ−ＵＰＦ２０を経てＧ−ＵＰＦ２１へリーダーＲＴＰパケットを送信する。スピーチアイテムが得られ、そしてＭＳへ許可される。同時に、以下に述べるタイマーが初期化される。リーダーＲＴＰパケットは、それらの各Ｕ−ＵＰＦを経てグループの全てのアクティブな受信メンバーへ転送され、アクティブなメンバーがスピーチアイテムを得てグループへのトークをスタートするたびに、グループの全てのアクティブな受信メンバーへ現在話し手の認識を指示する。このリーダーパケットは、埋め込まれた制御シグナリングに対する特殊なペイロード形式及びＲＴＰペイロードを使用して、送信者の認識に関する情報（ニューモニック、番号等）と、同じ話し手により送信される後続のＲＴＰパケットを確認するのに使用されるＳＳＲＣ値とを搬送する。次いで、リーダーＲＴＰパケットの後に、実際のグループの音声ストリーム（ＶｏＩＰ  ＲＴＰパケット）が続く。
【００８３】
通常、スピーチアイテムが得られず、そしてＧ−ＵＰＦ２１がリーダーＲＴＰパケットの受信に応答してユーザへのスピーチアイテムを許可しないときには、ユーザは、同じグループトラフィックから別のメンバーの音声を受信したときに自分の音声が転送されないことに気付く。しかしながら、これはユーザが別のグループを同時に聴取する場合には充分ではなく、従って、グループのＧ−ＵＰＦ２１は、要求されたスピーチアイテムをユーザが得ないことをユーザのＵ−ＵＰＦ２０に信号しなければならない（埋め込まれたＲＴＰシグナリングを使用して）。ユーザのＵ−ＵＰＦ２０は、次いで、この特殊なＲＴＰパケットをユーザへと送信する。このパケットは、スピーチアイテムがユーザターミナルに許可されなかったことをユーザターミナルに指示し、そしてＭＳがあるハードウェアメカニズム（視覚又は音声指示のような）をスイッチオンしてユーザに警告できるようにする。
【００８４】
スピーチアイテムは、暗示的シグナリングによって管理されるので、グループ通信中に更に別の特定の明確なシグナリングを必要としない。
各Ｇ−ＣＰＦ２３は、グループにアタッチするユーザに対して独特のＳＳＲＣ値を発生する。グループアタッチ中に、Ｇ−ＣＰＦ２３は、このＳＳＲＣ値をユーザに返送し、そしてそれをＧ−ＣＰＦ２３及びＧ−ＵＰＦ２１に記憶する。このでは、ＳＳＲＣは、グループのコンテクストにおいてユーザを独特に識別し、一方、ユーザの各１対１コールに対してＵ−ＵＰＦ２０により関連付けされた異なるＳＳＲＣは、１対１コールにおいて発呼者
を指示し、そしてそのコールにおいて発呼者及び被呼者の両方に同じ値が使用される。
Ｕ−ＵＰＦ２０により転送されたユーザトラフィックは、次いで、トラフィックが向けられるグループを取り扱うＧ−ＵＰＦ２３のＩＰアドレスと、Ｇ−ＵＰＦ２３がそのグループのトラフィックに対して割り当てた特定のポート番号とにより識別される。
【００８５】
入力フィルタリングにおけるトークスパートタイマー
ユーザにより見たグループにおけるトラフィックは、特定のユーザから到来する若干連続するスピーチのトークスパート（即ちスピーチアイテム）で構成される。しかしながら、Ｕ−ＵＰＦ２０及びＧ−ＵＰＦ２１は、スピーチのパケットを受信し、そして多数のユーザが同じグループにおいて同時に話そうと試みる。グループにおける現在話し手からのスピーチが中断されたり又は他のユーザからのパケットで干渉されたりすることのないように確保するために、Ｇ−ＵＰＦ２１は、各アクティブなグループに対してトークスパート連続性タイマーを実施する。タイマーに加えて、現在話しているユーザの認識が記憶される。
【００８６】
典型的なトークスパートでは、ユーザがＰＴＴを押している間に、自分のスピーチコーデックがスピーチパケット（フレーム）を発生し、これらは、規則的な間隔で送信される。もちろん、パケットは若干不規則な間隔でＧ−ＵＰＦ２１に到着する。ユーザが話をしていないときでも、ＭＳは、ＤＴＸパッケージを送信する（不連続送信）。従って、パケット間にソフト状態を保持するためにタイマーが必要とされる。タイマーは、到来するパケットのたびに再スタートされ、そしてタイマー値は、送信されるパケット（例えば、ＤＴＸフレーム）間の間隔、及びユーザとＧ−ＵＰＦ２１との間の遅延の変化とを考慮して、パケット間に間隔を許すに充分なものでなければならない。従って、タイマー値は、数百ミリ秒程度である。
【００８７】
考え方は、ユーザがＰＴＴを放した場合にユーザに対して予約された順番を保つことではない。それ故、本発明の一実施形態は、トレーラーパケットを使用してトークスパートの終りを信号し、これは、ターマーの時間切れと同等であると考えねばならない。トークスパート連続性タイマーは、Ｇ−ＵＰＦ２１において実施される。というのは、ここでは、同じグループにおいて異なる話し手が話をしようと競い合うからである。
【００８８】
又、最大トークスパート時間を制限する必要もある。ユーザの観点から、単一のユーザがグループを不必要に長時間占有して他のものが話すのを妨げてはならない。ユーザのＰＴＴが送信位置において偶発的にジャミングした場合にもグループを阻止してはならない。オペレータは、サービス及び料率をプロフィーリングする理由で、トークスパート時間を限定することを望む。トークスパート最大値タイマーの典型的な値は、３０ｓ、６０ｓ又はそれ以上である。タイマーは、ユーザが現在話し手となったときに、第１パケットにおいてスタートする。タイマーが時間切れしたときには、他の話し手がいなくても、現在話し手のトークスパートが停止される。再び話をできるようにするために、ＰＴＴを放しそしてもう一度プッシュする必要がある。特殊な埋め込まれたＲＴＰシグナリングパケットがＧ−ＵＰＦによりＭＳへ送信されて、送信を停止させる。
【００８９】
トークスパート最大値タイマーは、Ｕ−ＵＰＦ２０又はＧ−ＵＰＦ２１或いはその両方において実施できるが、その結果は、各場合に同じではない。Ｕ−ＵＰＦ２０におけるタイマーは、ユーザ特有の最大トークスパート時間を実施し、Ｇ−ＵＰＦ２１におけるタイマーは、グループ特有の最大トークスパート時間を実施する。これらは、いずれも有用であり、両方ともの場合もそうである。アーキテクチャーは、両方ともをサポートする。
【００９０】
図９は、Ｇ−ＵＰＦ２１におけるトークスパートタイマープロセスを示すフローチャートである。トークグループ連続性タイマー及びトークスパート最大値タイマーは、スピーチ
アイテムがユーザに許可されたときにスタートする（ステップ９２）。ステップ９１では、ユーザから新たなパケットが受信されたかどうかチェックされる。もしそうでなければ、連続性タイマーが時間切れしたかどうかチェックされる（ステップ９２）。連続性タイマーが時間切れした場合には、スピーチアイテムが終了となる（ステップ９７）。連続性タイマーが時間切れしない場合には、最大値タイマーが時間切れしたかどうかチェックされる（ステップ９３）。最大値タイマーが時間切れした場合には、スピーチアイテムが終了となる（ステップ９７）。最大値タイマーが時間切れしていない場合には、プロセスは、ステップ９１へ戻る。ステップ９１においてユーザから新たなパケットが受け取られた場合には、その受け取られたパケットが、ＰＴＴの解除に応答してユーザ装置により送信されたテイラーパケットであるかどうかチェックされる（ステップ９７）。テイラーパケットが受け取られた場合には、スピーチアイテムが終了される（ステップ９４）。受け取られたパケットがテイラーパケットでない場合には、最大値タイマーが時間切れしたかどうかチェックされる（ステップ９５）。最大値タイマーが時間切れした場合には、スピーチアイテムが終了となる（ステップ９７）。最大値タイマーが時間切れしない場合には、トークスパートタイマーが再スタートされ（ステップ９６）、そしてプロセスは、ステップ９１へ戻る。」（３１−３３頁、段落【００８２】−段落【００９０】）
　
　上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、
ａ．上記引用例に記載された「サーバシステム」は、「通信システムのためのパケットモードグループ通信サービスを提供する」ものであり（摘記事項アの【請求項１１】）、
ｂ．上記「サーバシステム」が備える「通信グループ当たり１つのグループメンバーへのスピーチアイテムを順次に許可するための手段」（摘記事項アの【請求項１１】）は、「上記許可に応答して、上記許可から所定のアイドル周期の測定をスタートする第１タイマーと、上記許可されたスピーチアイテムを有する上記１つのグループメンバーからボイスパケットが受信されるたびに上記第１タイマーをリセットする手段と、上記第１タイマーが時間切れして、上記許可から、又は上記１つのグループメンバーからのボイスパケットの最後の受信から、上記所定のアイドル周期が経過したことを指示する場合に、上記許可されたスピーチアイテムを終了する手段」（摘記事項アの【請求項１４】）を備えているものであって、上記タイマーを用いてスピーチアイテムを終了させる具体的な処理フローは【図９】に示されるものであるが、
ｂ１．上記「ボイスパケット」は、「グループ通信グループにおけるスピーチアイテムを有する上記グループメンバーから受信した各ボイスパケット」（摘記事項アの【請求項１１】）であり、
ｂ２．上記「許可するための手段」は、ボイスパケットが受信されるたびに、その受信間隔を所定のアイドル周期（【図９】の連続性タイマーの時間切れまで）と比較しているが、このような動作は「監視」と言うことができ、
ｂ３．上記「ボイスパケット」が「所定のアイドル期間」に亘って受信されない場合には「許可されたスピーチアイテムを終了する」ものであるが、上記「許可するための手段」は「通信グループ当たり１つのグループメンバーへのスピーチアイテムを順次に許可する」（摘記事項アの【請求項１１】）ものであって、上記「スピーチアイテムを終了」した後には、該スピーチアイテムを「他のグループメンバーに順次に許可する」ものと認められ、
　
　以上を総合すれば、上記引用例には、以下の発明（以下、「引用発明」という。）が記載されていると認める。
　
「通信システムのためのパケットモードグループ通信サービスを提供するためのグループサーバであって、
　前記グループ通信グループにおけるスピーチアイテムを有するグループメンバーから受信したボイスパケットを監視し、
　前記監視される前記ボイスパケットが所定のアイドル期間に亘って受信されない場合に、前記グループメンバーに許可されたスピーチアイテムを他のグループメンバーに順次に許可する、許可するための手段、
を備えるサーバシステム。」
　
４．対比・判断
　本願発明と引用発明を対比すると、
ａ．引用発明の「グループサーバ」が、「通信システムのためのパケットモードグループ通信サービスを提供する」ためにグループ通話を管理していることは明らかであるから、
　引用発明の「通信システムのためのパケットモードグループ通信サービスを提供するためのグループサーバ」と本願発明の「グループ通話を管理するサーバ」の間に実質的な差異は無い。
ｂ．引用発明の「前記グループ通信グループにおけるスピーチアイテム」は、グループサーバから許可されるものであり、また、これを許可されたグループメンバーの「ボイスパケット」が「グループ通信グループにおける各受信メンバーへ別々にユニキャスト」（摘記事項アの【請求項１１】）されるものであるから、上記「スピーチアイテム」は「送信権」と言い得るものである。
　また、上記「ボイスパケット」が「データ」であることは自明であるから、結局、引用発明の「前記グループ通信グループにおけるスピーチアイテム」は、実質的に「グループ通信に対してデータを送信する権利である送信権」と言える。
　とすると、引用発明の「前記グループ通信グループにおけるスピーチアイテム」と本願発明の「前記グループ通話に対して通話データを送信する権利である送信権」とは「前記グループ通話に対してデータを送信する権利である送信権」で共通する。
ｃ．引用発明の「スピーチアイテム」はグループサーバから許可されるものであるから、これを「有する」グループメンバーは、送信権を「割り当てている」グループメンバーと言える。
ｄ．上記「グループメンバー」は、「本発明は、ＧＰＲＳ型パケット無線をベースとする移動通信システムに特に好ましく使用される。以下、本発明の好ましい実施形態は、ＧＰＲＳサービス及びＵＭＴＳ又はＧＳＭシステムにより説明する」（摘記事項イの【００２６】）等の記載から、「移動局」であることは明らかである。
ｅ．上記ｂ．で検討したように、引用発明の「ボイスパケット」が「データ」であることは自明であって、引用発明の「から受信したボイスパケット」と本願発明の「によって送信される通話データ」とは、「によって送信されるデータ」で共通する。
ｆ．引用発明の「許可する手段」のうち、「監視」を行う部分を「監視部」と称することは任意である。
ｇ．引用発明の「所定のアイドル期間に亘って受信されない場合に」は本願発明の「所定期間に亘って検出されない場合に」に含まれる。
ｈ．引用発明の「（スピーチアイテムを）他のグループメンバーに順次に許可する」と本願発明の「（送信権を）他の移動局に対して開放する」とは実質的に同義であり、また、引用発明の「許可する手段」のうち、「許可」を行う部分を「開放部」と称することは任意である。
　
　以上をまとめると、本願発明と引用発明は、以下の点で一致ないし相違する。
　
（一致点）
「グループ通話を管理するサーバであって、
　前記グループ通話に対してデータを送信する権利である送信権を割り当てている移動局である送信権保有移動局によって送信されるデータを監視する監視部と、
　前記監視部によって監視される前記データが所定期間に亘って検出されない場合に、前記送信権保有移動局に割り当てている前記送信権を他の移動局に対して開放する開放部と、
を備えることを特徴とするサーバ。」
　
（相違点）
　「データ」が、
　本願発明では「通話データ」であるのに対し、
　引用発明では「ボイスパケット」である点。
　
　以下に、上記（相違点）につき検討する。
　
　引用発明の「ボイスパケット」を監視する目的について、引用例には「グループにおける現在話し手からのスピーチが中断されたり又は他のユーザからのパケットで干渉されたりすることのないように確保するため」（摘記事項エの段落【００８５】）と記載されている。即ち、引用発明は、現在話し手のスピーチが継続中か否かを監視しているのであり、この意味で、引用発明の「ボイスパケット」は本願発明の「通話データ」と同じ目的で「監視」されているものであると言える。
　また、引用発明の「ボイスパケット」は、具体的には、ユーザがＰＴＴを押している間送出される「ＶｏＩＰ　ＲＴＰパケット」であって（摘記事項ウの【００３５】、摘記事項エの【００８２】参照）、通話時のユーザの音声データを含むパケットであることは明らかであるから、本願発明の「通話データ」とは表現が異なるものの実質的な相違はないものである。
　
　なお、意見書において請求人は、『本願発明は、「通話データが所定期間に亘って検出されない場合に、送信権保有移動局に割り当てている送信権を他の移動局に対して開放する」ことに特徴があります。
　これに対し、引用発明１は、ユーザが話をしているか否かに関わらず、ＰＴＴを押しているときに送信されるフレーム間間隔を計測して、トークスパート（スピーチアイテム）の終了を検出するものであって、ユーザの話の間隔（無通話時間）を計測して、トークスパート（スピーチアイテム）の終了を検出するものではなく、上述した本願発明の構成に対応する直接的な記載やこれを示唆する記載ではありません。』と主張している。
　確かに、引用例には、（トークスパート）連続性タイマーのタイマー値に関して「送信されるパケット（例えば、ＤＴＸフレーム）間の間隔、及びユーザとＧ−ＵＰＦ２１との間の遅延の変化とを考慮して、パケット間に間隔を許すに充分なものでなければならない」（摘記事項エの【００８６】）として、ＤＴＸフレームも監視対象に加えることが例示されている。
　しかしながら、【図９】のステップ９１では「ステップ９１では、ユーザから新たなパケットが受信されたかどうかチェックされる。もしそうでなければ、連続性タイマーが時間切れしたかどうかチェックされる（ステップ９２）。」（摘記事項エの【００９０】）とあるように、ユーザから送信される全てのパケット（通話データであるボイスパケットを含む）について、所定期間に亘る受信の有無がチェックされているから、本願発明の「前記通話データが所定期間に亘って検出されない場合」に相当する処理が行われているものである。
　したがって、上記請求人の主張は採用できない。
　
　そして、本願発明の作用・効果も引用発明から当業者が予測し得る範囲のものである。
　
５．むすび
　したがって、本願発明は、引用発明に基づいて、当業者が容易に想到し得たものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。