【事件の表示】
　特願２００５−３０３１２０「通信装置及び通信方法」拒絶査定不服審判事件〔平成１９年　５月１０日出願公開、特開２００７−１１６２６０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、平成１７年１０月１８日の出願であって、平成２３年４月２６日付けで拒絶査定がなされ、これに対し、同年８月５日に拒絶査定に対する審判請求がなされるとともに、同日付けで審判請求時の手続補正がなされたものである。
　
第２．補正却下の決定
［補正却下の決定の結論］
　　平成２３年８月５日付けの手続補正を却下する。
　
［理由］
１．本願発明と補正後の発明
　上記手続補正（以下、「本件補正」という。）は補正前の平成２２年１１月８日付けの手続補正書の特許請求の範囲の請求項１に記載された
　「管理装置を介して他の通信装置と通信する通信システムにおいて用いられる通信装置であって、
　通信部と、
　所定のＩＤ情報を記憶する記憶部と、
　前記通信部により、通信開始のための情報の記載される通信開始要求を受信すると、当該情報を用いて前記管理装置に接続するよう前記通信部を制御する制御部と
　を備え、
　前記制御部は、前記通信開始要求を受信すると、当該通信開始要求に含まれるＩＤ情報が前記記憶部に記憶されているものである場合には、前記通信部に前記管理装置に接続させないよう制御する通信拒否処理を行う
　ことを特徴とする通信装置。」
という発明（以下、「本願発明」という。）を、補正後の特許請求の範囲の請求項１に記載された
　「管理装置を介して他の通信装置と通信する通信システムにおいて用いられる通信装置であって、
　通信部と、
　所定のＩＤ情報を記憶する記憶部と、
　前記通信部により、通信開始のための情報が記載される通信開始要求を受信すると、当該情報を用いて前記管理装置に接続するよう前記通信部を制御する制御部と
　を備え、
　前記制御部は、前記通信開始要求を受信すると、当該通信開始要求に含まれるＩＤ情報が前記記憶部に記憶されているものである場合には、前記通信開始要求の受信を表示すること無く、前記通信部に前記管理装置に接続させないよう制御する通信拒否処理を行う
　ことを特徴とする通信装置。」
という発明（以下、「補正後の発明」という。）に補正することを含むものである。
　
２．新規事項の有無、補正の目的要件について
　本件補正は、願書に最初に添付した明細書又は図面に記載した事項の範囲内において、補正前の「前記制御部は、前記通信開始要求を受信すると、当該通信開始要求に含まれるＩＤ情報が前記記憶部に記憶されているものである場合には、前記通信部に前記管理装置に接続させないよう制御する通信拒否処理を行う」という構成を「前記制御部は、前記通信開始要求を受信すると、当該通信開始要求に含まれるＩＤ情報が前記記憶部に記憶されているものである場合には、前記通信開始要求の受信を表示すること無く、前記通信部に前記管理装置に接続させないよう制御する通信拒否処理を行う」という構成に限定することにより特許請求の範囲を減縮するものである。
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第３項（新規事項）及び平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号（補正の目的）の規定に適合している。
　
３．独立特許要件について
　本件補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。
　
（１）補正後の発明
　上記「１．本願発明と補正後の発明」の項で「補正後の発明」として認定したとおりである。
　
（２）引用発明
　原査定の拒絶の理由に引用された国際公開２００４／７５００１号（以下、「引用例」という。）には図面とともに以下の事項が記載されている。
　
　イ．「Description of the Preferred Embodiment of the Invention
 
　FIG. 1 depicts a communication system for facilitating dispatch call services. Communication system 100 includes a communication network 10 which has call processing server 50 to facilitate switching and transmission of bearer traffic between terminals 20-40. While a call processing server 50 is shown in the preferred embodiment, it is an optional element. Distributed call processing is also possible where each of the terminals provides necessary origination or termination call processing without the need for a call processing server 50. For purposes of explanation of the present invention, mobile unit 20 will be the originating unit and mobile units 30 and/or 40 will be the target units. Typically originating unit 20 would send a dispatch call request through network 10 and call processing server 50 for target mobile unit 40, for example. Server 50 and network 10 would automatically connect target unit 40 with originating unit 20 and target unit's loudspeaker would begin blaring the communication of originating unit 20. This is termed a forced dispatch call.」（２頁１２行〜３１行）
　（邦訳）
　「発明を実施するための最良の形態
　
  図１には、ディスパッチ呼出サービスを促進する通信システムを示す。通信システム１００には通信ネットワーク１０が含まれ、通信ネットワーク１０には、端末２０と端末４０との間のベアラ・トラフィックの交換および伝送を促進する、呼出処理サーバ５０が含まれる。好適な実施態様には呼出処理サーバ５０を示したが、呼出処理サーバ５０は随意の要素である。呼出処理サーバ５０を必要とせずに各々の端末が呼出の発信または着信の必要な処理を提供する、分散型の呼出処理も可能である。本発明を説明する目的において、移動体装置２０は発信元の装置であり、移動体装置３０および移動体装置４０のうちの１つ以上は目標の装置である。典型的には、例えば、発信元装置２０は、通信ネットワーク１０および呼出処理サーバ５０を通じて、目標の移動体装置４０へディスパッチ呼出の要求を送信する。呼出処理サーバ５０および通信ネットワーク１０が目標装置４０を発信元装置２０と自動的に接続すると、目標装置のラウドスピーカが発信元装置２０の通信を鳴らし始める。これを強制ディスパッチ呼出と称する。」
　
　ロ．「Referring to FIG. 2, a flow chart of a method for dispatch call setup for originating unit 20 is shown. The method is started and block 101 is entered. Block 101 determines which type of call start method has been selected by the originator. If the dispatch call type is a forced call, block 101 transfers control to block 105. The originating user may have a default dispatch call method if none is selected in real time.
　Block 105 sends a forced dispatch call request through network 10 and call processing server 50 to target mobile units 30 and/or 40. For group calls, both target units 30 and 40 would typically be selected. For an individual dispatch call, one or the other of target units 30 or 40 would be selected.
　Next, block 109 waits to gather call accept or reject responses from the target units for a configurable period of time which is appropriate for forced call processing. This time may be set to a default in the subscriber device, or it may be controlled by user preference, and would usually be set prior to the call. For forced calls, the time would typically be set to be relatively short, for example 0.5 to 2 seconds, since it is expected that most targets will immediately respond to a forced call request. As another example, if the originator is unconcerned about target party participation (as determined in block 121) , then this time may be set to zero to speed call processing.
　Next, block 121 determines whether the originating unit 20 is concerned about which target units participate in the call. If the originating unit 20 is not concerned about which of the target units participate in the dispatch call, block 121 transfers control to block 113 via the no path. Such transmission by the originating unit 20 would typically be a broadcast message to a group of target units who are not required to respond in real time . 
　If the originating unit 20 is concerned about which targets participate in the dispatch call, block 121 transfers control to block 115 via the yes path.
　If the selected type of dispatch call start method is the invite, block 101 transfers control to block 103. Block 103 sends an invite request to each of the target user or users via network 10 and call processing server 50.
　Next, block 107 waits to gather call accept or reject responses from the target units for a configurable period of time which is appropriate for invited call processing. This time may be set to a default in the subscriber device, or it may be controlled by user preference, and would usually be set prior to the call. For invited calls, the time would typically be set to be longer than for forced calls, for example 10 to 20 seconds, since it is expected that it may take some time for the users of target subscriber units to interact with the subscriber unit and respond to an invited call request.」（３頁３行〜４頁１８行）
　（邦訳）
　「図２には、発信元装置２０におけるディスパッチ呼出の設定方法の流れ図を示す。方法が開始され、ブロック１０１に進む。ブロック１０１では、発信者に選択された呼出開始方法の型を判定する。ディスパッチ呼出の型が強制呼出の場合、ブロック１０１からブロック１０５へ制御が移る。実時間で何も選択されない場合、発信元のユーザはデフォルトのディスパッチ呼出方法を有し得る。
  ブロック１０５は、通信ネットワーク１０および呼出処理サーバ５０を通じて、目標の移動体装置３０および４０のうちの１つ以上へ強制ディスパッチ呼出の要求を送信する。グループ呼出では、典型的には目標装置３０，４０の両方が選択される。個別ディスパッチ呼出では、目標装置３０または４０の一方または他方が選択される。
  次に、ブロック１０９は、強制呼出処理に適切なように設定可能な時間の間、目標装置からの呼出受容または呼出拒否の応答を収集するために待機する。この時間は、加入者のデバイスのデフォルトに設定されてもよく、またはユーザ・プリファレンスに制御されてもよく、通常は呼出以前に設定される。強制呼出では、大抵の目標装置は強制呼出要求に即座に応答することが期待されるので、この時間は比較的短い時間、例えば、０．５〜２秒に典型的には設定される。別の例として、発信者が目標パーティの参加を考慮しない（ブロック１２１で判定されるように）場合、呼出処理を速めるため、この時間が零に設定されてもよい。
  次に、ブロック１２１は、どの目標装置が呼出に参加するかを発信元装置２０が考慮するか否かを判定する。どの目標装置がディスパッチ呼出に参加するかを発信元装置２０が考慮しない場合、ブロック１２１から「ＮＯ」の経路を通じてブロック１１３へ制御が移る。典型的には、発信元装置２０によるそのような伝送は、実時間での応答が必要でない目標装置の１つのグループに対する、ブロードキャスト・メッセージである。
　どの目標装置がディスパッチ呼出に参加するかを発信元装置２０が考慮する場合、ブロック１２１から「ＹＥＳ」の経路を通じてブロック１１５へ制御が移る。
　選択したディスパッチ呼出開始方法が招請の場合、ブロック１０１からブロック１０３へ制御が移る。ブロック１０３は、通信ネットワーク１０および呼出処理サーバ５０を介して、各々の目標ユーザへ、招請要求を送信する。
　次に、ブロック１０７は、招請呼出処理に適切なように設定可能な時間の間、目標装置からの呼出受容または呼出拒否の応答を収集するために待機する。この時間は、加入者のデバイスのデフォルトに設定されてもよく、またはユーザ・プリファレンスに制御されてもよく、通常は呼出以前に設定される。招請呼出では、目標の加入者装置のユーザが加入者装置と相互作用して招請呼出の要求に応答するには幾分時間を要する場合があることが期待されるので、この時間は強制呼出より長い時間、例えば、１０〜２０秒に典型的には設定される。」
　
　ハ．「Referring to FIG. 3, a flow chart of a dispatch call startup method for target mobile units 30 and 40 is shown. This method allows the target mobile unit 30 and 40 to optionally select the behavior upon receiving either forced or invited dispatch calls. This method allows a user of the target mobile unit to select the preferences that the target mobile unit will exhibit.」（５頁１５行〜２１行）
　（邦訳）
　「図３には、目標装置３０，４０におけるディスパッチ呼出の開始方法の流れ図を示す。この方法によって、強制または招請ディスパッチ呼出を受信する際、目標装置３０，４０が随意で挙動を選択することが可能となる。この方法によって、目標の移動体装置が提示するプリファレンスを目標の移動体装置のユーザが選択することが可能となる。」（５頁１５行〜２１行）
　
　ニ．「If the target unit 30 or 40 has determined that the originator's requested dispatch call request was an invite request, block 125 transfers control to block 139. Block 139 determines the preferences of the target unit. If the target units 30 or 40 preference is set to automatically accept, block 139 transfers control to block 141. Block 141 automatically accepts the invite dispatch call and responds to the originating unit with an accept message. The target unit 30 and/or 40 then accepts bearer traffic. The method is then ended. If the target unit's 30 or 40 preference is set to automatically reject an invited dispatch call, block 139 transfers control to block 149. Block 149 sends a reject message to the originating unit and does not accept any bearer traffic. The method is then ended. If the preferences of the target unit 30 or 40 are set to indicate that the user controls the response in real time, block 139 transfers control to block 143. Block 143 notifies the target user of the incoming invited dispatch call and displays caller ID type information. Next, block 145 determines whether the target user has accepted the invited dispatch call. If the target user does not accept the invite dispatch call in real time, block 145 transfers control to block 149 via the no path. Block 149 sends a reject message to the originating unit and does not accept any bearer traffic. If the target user accepts the invite dispatch call, block 145 transfer control to block 147 via the yes path. Block 147 sends an accept message to the originating unit 20 and accepts the bearer traffic when it is sent. The method is then ended .」（６頁３３行〜７頁２４行）
　（邦訳）
　「発信者が要求したディスパッチ呼出の要求は招請要求であると目標装置３０または４０が判定した場合、ブロック１２５からブロック１３９へ制御が移る。ブロック１３９は目標装置のプリファレンスを判定する。目標装置３０または４０のプリファレンスが自動受容に設定されていた場合、ブロック１３９からブロック１４１へ制御が移る。ブロック１４１は、招請ディスパッチ呼出を自動的に受容し、発信元装置へ受容メッセージを応答する。続いて、目標装置３０および４０のうちの１つ以上は、ベアラ・トラフィックを受容する。ここで方法が終了する。目標装置３０または４０のプリファレンスが、招請ディスパッチ呼出を自動拒否に設定されていた場合、ブロック１３９からブロック１４９へ制御が移る。ブロック１４９は、発信元装置へ拒否メッセージを送信し、いかなるベアラ・トラフィックも受容しない。ここで方法が終了する。目標装置３０または４０のプリファレンスが、実時間でユーザが応答を制御することを示すように設定されていた場合、ブロック１３９からブロック１４３へ制御が移る。ブロック１４３は、着呼の招請ディスパッチ呼出を目標ユーザに通知し、呼出者のＩＤ型情報を表示する。次に、ブロック１４５は、目標ユーザが招請ディスパッチ呼出を受容したか否かを判定する。目標ユーザが実時間で招請ディスパッチ呼出を受容しない場合、「ＮＯ」の経路を通じて、ブロック１４５からブロック１４９へ制御が移る。ブロック１４９は発信元装置へ拒否メッセージを送信し、いかなるベアラ・トラフィックも受容しない。目標ユーザが招請ディスパッチ呼出を受容した場合、「ＹＥＳ」の経路を通じて、ブロック１４５からブロック１４７へ制御が移る。ブロック１４７は発信元装置２０へ受容メッセージを送信し、ベアラ・トラフィックが送信されると受容する。ここで方法が終了する。」
　
　上記摘記事項イ及び図１を参照すると、移動体装置は、呼出処理サーバを介して他の移動体装置と通信する通信システムにおいて用いられるものであるといえる。
　移動体装置は、通信部及び制御部を備えるものであることは技術常識である。上記摘記事項ニ及び図３には、招請ディスパッチ呼出を受信した場合の動作が記載されており、この動作は制御部により制御されるものであるといえる。
　上記摘記事項ニの「ブロック１４３は、着呼の招請ディスパッチ呼出を目標ユーザに通知し、呼出者のＩＤ型情報を表示する。」という記載からすると、「招請ディスパッチ呼出」には、「呼出者のＩＤ型情報」が含まれているといえる。
　
　したがって、この分野における技術常識を考慮すると、上記引用例には以下の発明（以下、「引用発明」という。）が開示されているものと認められる。
　
　「呼出処理サーバを介して他の移動体装置と通信する通信システムにおいて用いられる移動体装置であって、
　通信部と、
　前記通信部により呼出者のＩＤ型情報を含んだ招請ディスパッチ呼出を受信すると、プリファレンスが自動受容に設定されていた場合には、ベアラ・トラフィックを受容するように制御し、プリファレンスが自動拒否に設定されていた場合には、ベアラ・トラフィックを受容しないように制御する制御部を備える移動体装置。」
　
（３）対比
　補正後の発明と引用発明を対比する。
　引用発明の「呼出処理サーバ」、「移動体装置」は、補正後の発明の「管理装置」、「通信装置」にそれぞれ相当する。
　引用発明の「招請ディスパッチ呼出」は、ベアラ・トラフィックの通信開始を要求するものといえるから、補正後の発明の「通信開始要求」に相当する。
　引用発明の「呼出者のＩＤ型情報」は、補正後の発明の「通信開始のための情報」に相当する。
　引用発明の「ベアラトラフィックを受容する」ことは、通信を許可することを意味するものであり、また、補正後の発明の「当該情報を用いて前記管理装置に接続するよう前記通信部を制御する」ことは、本願明細書及び図面の記載を参酌すると、「通信開始要求に含まれる情報が、通信許可として記憶されているＩＤ情報である場合に、管理装置に接続するよう通信部を制御するして通信を許可する」ことを含むものであるといえる。
　そうすると、引用発明の「プリファレンスが自動受容に設定されていた場合には、ベアラ・トラフィックを受容するように制御」することと、補正後の発明の「当該情報を用いて前記管理装置に接続するよう前記通信部を制御する」こととは、「第１の場合に、通信許可処理を行う」ことで共通している。
　引用発明の「プリファレンスが自動拒否に設定されていた場合には、ベアラ・トラフィックを受容しないように制御する」ことと、補正後の発明の「当該通信開始要求に含まれるＩＤ情報が前記記憶部に記憶されているものである場合には、前記通信開始要求の受信を表示すること無く、前記通信部に前記管理装置に接続させないよう制御する通信拒否処理を行う」こととは、「第２の場合には、通信拒否処理を行う」ことで共通している。
　
　したがって、補正後の発明と引用発明は、以下の点で一致し、また、相違している。
　
　「管理装置を介して他の通信装置と通信する通信システムにおいて用いられる通信装置であって、
　通信部と、
　前記通信部により、通信開始のための情報の記載される通信開始要求を受信すると、第１の場合に、通信許可処理を行う制御部と
　を備え、
　前記制御部は、前記通信開始要求を受信すると、第２の場合には、通信拒否処理を行う通信装置。」
　
［相違点１］
　補正後の発明の通信装置は、「所定のＩＤ情報を記憶する記憶部」を備えているのに対して、引用発明の通信装置は、そのような手段を備えていない点。
　
［相違点２］
　「第１の場合」が、補正後の発明では、「通信開始要求に含まれる情報」が、通信を許可されるものである場合であるのに対して、引用発明では、「プリファレンスが自動受容に設定されていた場合」である点。
　
［相違点３］
　「通信許可処理を行う」ことが、補正後の発明では、「前記管理装置に接続するよう前記通信部を制御する」ことであるのに対して、引用発明では「ベアラ・トラフィックを受容するように制御する」ことである点。
　
［相違点４］
　「第２の場合」が、補正後の発明では、「当該通信開始要求に含まれるＩＤ情報が前記記憶部に記憶されているものである場合」であるのに対して、引用発明は、「プリファレンスが自動拒否に設定されていた場合」である点。
　
［相違点５］
　「通信拒否処理を行う」ことが、補正後の発明では「前記通信開始要求の受信を表示すること無く、前記通信部に前記管理装置に接続させないように制御する」ことであるのに対して、引用発明は、「ベアラ・トラフィックを受容しないように制御する」ことである点。
　
（４）判断
　上記相違点について検討する。
　通話を行う通信装置において、通話を許可する電話番号と通話を拒否する電話番号とを記憶しておいて、着信があった場合に、通話を許可または拒否することは、例えば、特開２００２−２２３２７９号公報、特開２００３−１７９６８４号公報、特開２００４−１０４４８８号公報に示されるように周知事項と認められる。
　引用発明は、着信の一種である「招請ディスパッチ呼出」を受信すると通話を許可または拒否するものといえるので、当該周知事項を引用発明に適用することに困難性はない。
　当該周知事項を引用発明に適用すれば、通信装置は、通話を許可する電話番号と通話を拒否する電話番号を記憶する手段を備えることになるが、電話番号は「ＩＤ情報」の一種であるから、その手段は「所定のＩＤ情報を記憶する記憶部」であるといえるので、相違点１の構成とすることは格別のことではない。
　そして、引用発明において、通信開始要求にはＩＤ情報が含まれていることから、「プリファレンスが自動受容に設定されていた場合」に代えて、「通信開始要求に含まれる情報が、通信を許可されるものである場合」として、相違点２の構成とすることも格別のことではない。同様に、「プリファレンスが自動拒否に設定されていた場合」に代えて、「通信開始要求に含まれるＩＤ情報が記憶部に記憶されているものである場合」として、相違点４の構成とすることも格別のことではない。
　また、引用発明における「ベアラ・トラフィック」は、管理装置を介して受信されるものであるから、「ベアラ・トラフィックを受容するように制御する」ために「管理装置に接続するように通信部を制御する」ようにして、相違点３の構成とすることは容易なことである。
　通話を拒否する場合に、着信表示を行わないようにすることも、例えば、特開２０００−５９５０２号公報、特開２００４−４８４１２号公報に示されるように周知事項であり、引用発明の「ベアラ・トラフィックを受容しないように制御する」ことは、通話を拒否することであることは自明であるから、通話を拒否するために「通信開始要求の受信を表示すること無く、通信部に管理装置に接続させないように制御する」ようにして、相違点５の構成とすることは容易なことである。
　
　以上のとおりであるから、補正後の発明は、引用発明及び周知事項に基づいて容易に発明できたものであり、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
４．結語
　以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する特許法第１２６条第５項の規定に適合していない。
　したがって、本件補正は、特許法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　
第３．本願発明について
１．本願発明
　本件補正は上記のとおり却下されたので、本願発明は、上記「第２．補正却下の決定」の「１．本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。
　
２．引用発明
　引用発明は、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項中の「（２）引用発明」の項で認定したとおりである。
　
３．対比・判断
　そこで、本願発明と引用発明とを対比するに、本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。
　そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第２．補正却下の決定」の項中の「３．独立特許要件について」の項で検討したとおり、引用発明及び周知事項に基づいて容易に発明できたものであるから、上記補正後の発明から当該補正に係る限定を省いた本願発明も、同様の理由により、容易に発明できたものである。
　
４．むすび
　以上のとおり、本願発明は、引用発明及び周知事項に基づいて当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により、特許を受けることができない。
　
　よって、結論のとおり審決する。