ポートフォリオを新規に作成して保存 |
|
|
既存のポートフォリオに追加保存 |
|
PDFをダウンロード |
審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 H04L 審判 査定不服 5項独立特許用件 特許、登録しない。 H04L |
---|---|
管理番号 | 1263575 |
審判番号 | 不服2011-10014 |
総通号数 | 155 |
発行国 | 日本国特許庁(JP) |
公報種別 | 特許審決公報 |
発行日 | 2012-11-30 |
種別 | 拒絶査定不服の審決 |
審判請求日 | 2011-05-12 |
確定日 | 2012-09-20 |
事件の表示 | 特願2006-260830「IPアプリケーションサービス提供システム」拒絶査定不服審判事件〔平成20年 4月10日出願公開、特開2008- 85470〕について、次のとおり審決する。 |
結論 | 本件審判の請求は、成り立たない。 |
理由 |
第1.手続の経緯 本件出願は、平成18年9月26日の出願であって、平成22年9月17日付け拒絶理由通知に対して同年11月10日付けで意見書と手続補正書が提出されたが、平成23年2月7日付けで拒絶査定がなされ、これに対し、同年5月12日に拒絶査定不服の審判請求がなされるとともに同日付けで手続補正がなされたものである。 第2.補正却下の決定 [補正却下の決定の結論] 平成23年5月12日付けの手続補正を却下する。 [理由] 1.本願発明と補正後の発明 平成23年5月12日付けの手続補正は、補正前の平成22年11月10日付け手続補正書の特許請求の範囲の請求項1に記載された 「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するIPアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするIPアプリケーションサービス提供システムであって; 前記ゲートウェイ装置配下の前記内部ノードが、 前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と; 維持されている制御チャネルを通して、前記接続支援装置から前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と; 前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくIPアプリケーションのデータチャネルをアクティブにオープンする手段とを備え; 前記制御パケットを定期送信する処理及び前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理は非同期で遂行され、前記制御パケットの定期送信の期間中に前記接続支援装置が前記外部ノードから接続要求を受信したとき、前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理は実行される IPアプリケーションサービス提供システム。」 という発明(以下、「本願発明」という。)を、補正後の特許請求の範囲の請求項1に記載された 「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での意図するIPアプリケーション通信での外部から内部向けへのインバウンド通信も可能にするIPアプリケーションサービス提供システムであって; 前記ゲートウェイ装置配下の前記内部ノードが、 前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と; 維持されている制御チャネルを通して、前記接続支援装置から前記外部ノード対応の接続先アドレス及びポートの通知を受ける手段と; 前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくIPアプリケーションのデータチャネルをアクティブにオープンする手段とを備え; 前記制御パケットを定期送信する処理及び前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理は非同期で遂行され、前記非同期は、前記制御パケットの定期送信の期間中に前記接続支援装置が前記外部ノードから接続要求を受信したとき、前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されることであるIPアプリケーションサービス提供システム。」 という発明(以下、「補正後の発明」という。)に変更することを含むものである。 2.新規事項の有無、補正の目的要件について 上記補正は、願書に最初に添付した明細書、特許請求の範囲又は図面に記載した事項の範囲内において、「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理」が「前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されること」を付加することにより、該「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理」を限定し、特許請求の範囲を減縮するものであるから、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第3項(新規事項)及び特許法第17条の2第4項第2号(補正の目的)の規定に適合している。 3.独立特許要件について 上記補正は特許請求の範囲の減縮を目的とするものであるから、上記補正後の発明が特許出願の際独立して特許を受けることができるものであるのかどうかについて以下に検討する。 (1)補正後の発明 上記「1.本願発明と補正後の発明」の項で認定したとおりである。 (2)引用発明 原査定の拒絶理由に引用された特開2004-120547号公報(以下、「引用例」という。)には、「インターネットに接続するサーバ、機器および通信システム」に関し、図面とともに以下の事項が記載されている。 ア.「【0044】 (実施の形態1) 図1は本発明の実施の形態1の通信システムの通信シーケンスを説明した図である。図2は本発明の通信システムのネットワーク接続図である。本発明の通信システムはローカルエリアネットワーク(LAN)106上の機器とインターネット105上の機器間の通信を実現するものであり、LAN106に接続された機器101と、インターネット105上に接続されたサーバ104と、LAN106とインターネットを接続するルータ103とを含む。インターネット105には通信端末102も接続されている。 【0045】 ルータ103はNAPT機能を実装している。機器101のIPアドレスはプライベートIPアドレス”192.168.1.2”であり、サーバ104のIPアドレスはグローバルIPアドレス”4.17.168.6”であるとする。ルータ103のインターネット105側アドレスは一般にインターネットサービスプロバイダーからDHCPやPPP等のプロトコルにより割り当てられ、動的に変化するが、この時点でルータ103のインターネット側アドレスはグローバルIPアドレス”202.224.159.142”であるとする。説明の便宜上、ルータ103のインターネット105側アドレスは1つしかないとする。なお、本実施の形態において、IPアドレスはIPver4に準拠している。 【0046】 図1を参照し、本実施形態の通信シーケンスを説明する。 機器101はまず、サーバ104に対し最大アクセス確認周期情報要求107を送信する。サーバはこの応答として、最大アクセス確認周期情報通知108を送信する。これらの通信107、108はUDPによってもTCPによっても良く、LAN106側に接続された機器101から開始されるため、NAPT機能を備えたルータ103を越えて支障なく通信できる。ここで、最大アクセス確認周期とは、機器101からサーバ104へ送信される通知UDPパケット(後述)の送信時間間隔の最大値を示すものであり、例えば「5分」というような値となる。 【0047】 次に、機器101は周期的に通知UDPパケット109を送信する。この周期は先に取得した最大アクセス確認周期の値(例えば5分)より小さい間隔で送られる。通知UDPパケット109は機器101に固有に付与された機器識別子である「機器ID」を含む。通知UDPパケット109はルータ103により、往路のNAPT変換が行なわれた後インターネット105に送出され、サーバ104にて受信される。 【0048】 図3の(a)、(b)に各々変換される前後の通知UDPパケットの内容を示す。通知UDPパケットの送信周期は、ルータ103がUDPパケットのNAPTテーブルをタイムアウトにより破棄する時間よりも短く設定する。これによりルータ103には、図9(b)に示したようなNAPTテーブルがタイムアウトせず継続的に保持される。 【0049】 図1に戻り、サーバ104は、通知UDPパケット109を受信すると、ヘッダ内のSA、DA、SP、DPの各アドレスと機器IDを取り出し、図4に示すように、これらの情報を機器101(機器ID=”1234”)に対応する1組のエントリとしてサーバ内に登録保存する(ステップS119)。また、ステップS119では、最終アクセス時刻をエントリに付加し、サーバ104が通知UDPパケット109を受信した時刻を記録する。以後、サーバ104は、通知UDPパケット109を受信するたびにステップS120に示すように機器に対応するエントリの最終アクセス時刻を更新する。また、この際、通知UDPパケット109のヘッダ内のSA、SPの各アドレスが変更されていた場合は、エントリ中のそれらのアドレスの値も更新する。これにより、ルータ103のインターネット(WAN)105側IPアドレスが動的に割り振られていても、最新のアドレスがエントリに保持される。以上のシーケンスの実行により、通信の準備が完了する。 【0050】 以上の通信準備が完了している状況で、端末102から機器101に対する通信を開始したい場合、端末102は機器101の機器IDをパラメータに指定して、サーバ104に対し機器接続要求110を送信する。なお、機器IDは端末102が予め認識しているものとする。機器接続要求110を受信したサーバ104は、端末102により指定された機器IDを検索キーとして図4に示すテーブルからサーバ内に登録された機器IDを検索し、機器101が登録した対応エントリを得る(ステップS121)。 【0051】 次に、サーバ104はエントリ内の最終アクセス時刻を確認し、現在時刻との差が最大アクセス確認周期を超えている場合は機器接続要求110を拒否し、最大アクセス確認周期以下の場合は、ステップS122以後に進んで機器101に接続要求UDPパケット111を送信する。 【0052】 このように最終アクセス時刻を確認することで、機器101が正常に動作し、かつ、ごく最近まで正常に通信できていたか否かが直ちに確認できるため、機器接続要求110の受諾可否判定が高速にできる。また、ルータ103のインターネット(WAN)105側IPアドレスはISPによって動的に割り当てられているため、機器101の電源遮断後ある程度時間が経過すると、サーバ104に登録された機器101のIPアドレスが別の機器に割り当てられてしまう場合があるが、この場合でも誤って関係の無い別の機器に接続要求を行うことを防止できる。 【0053】 次に、サーバ104は、一意なセッション識別子を生成してサーバ内に保存する(ステップS122)。さらに、サーバ104は機器101に対応するエントリからSA、DA、SP、DPの各アドレスを取得し、これらを用いてセッション識別子をペイロードに含む接続要求UDPパケット111を送信する。ここで、接続要求UDPパケット111は通知UDPパケット109に対する応答として構成されている。図3(c)にインターネット(WAN)105上に送出された接続要求UDPパケットの内容を示す。図3(c)に示すパケットのアドレスとポートの値は、それぞれ図3(b)に示すパケットにおいてアドレスとポートのソースとディスティネーションの値を入れ替えた値となっている。これにより、接続要求UDPパケット111は通知UDPパケット109の応答パケットであることが分かる。接続要求UDPパケット111は、ルータ103において復路のNAPT変換により図3(c)に示す構成から図3(d)に示す構成に変換され、機器101に転送される。 【0054】 接続要求UDPパケット111を受信した機器101は、サーバ104に対してTCP接続要求112を送信する。TCP接続要求112についての詳細な説明は省略するが、syn,ack/syn,ackパケットによって接続を確立する通常のTCP接続確立手順である。TCP接続要求112はLAN側からWAN側に対して行なわれるものであるため、NAPT機能を備えたルータ103を越えて支障なくTCP接続を確立することができる。 【0055】 以上によりサーバ104と機器101の間でTCP接続が確立されたが、UDPパケットはコネクションレス型であるため、そのままではサーバ104において、TCP接続が接続要求UDPパケット111に応えて確立されたか否かの判定ができない。そのために以下で説明する手順が実行される。 【0056】 まず、機器101はそのTCP接続上で、接続要求UDPパケット109により通知されたセッション識別子を、セッション識別子通知113によってサーバへ返送する。サーバ104はセッション識別子を受信すると、ステップS123においてセッション識別子の照合を行う。照合の結果、このセッション識別子が機器接続要求110により生成されたものであることを検出すると、サーバ104はこのTCP接続を、接続要求110に答えて端末102と機器101間の通信の転送に使用することを決定する。 【0057】 なお、セッション識別子に代えて機器IDを用いてもTCP接続と接続要求UDPパケットを対応付けることはできるが、その場合はサーバ104と機器101の間には同時に複数のTCP接続を確立することができないという問題が生じる。本実施の形態によれば、サーバ104と機器101の間に複数のTCP接続を確立することができ、その際の個々のTCP接続上の通信内容を別々のセッション識別子で管理することで、複数の通信の内容を無秩序に混合してしまうことなく、別々のTCP接続上で各々一貫性を保持した通信の転送を行ない、端末102から機器101に対しセッション識別子毎に並列して複数の通信を行うことが可能となる。 【0058】 以上述べた手順により、サーバ104と機器101の間でTCP接続が確立されると、サーバ104はそのTCP接続上で端末102と機器101間の通信の転送を開始する。すなわち、サーバ104は端末102からの通信114を通信115として機器101に転送し、機器101からの通信116を端末102に通信117として転送する。最後に、通信が完了すると、サーバ104または機器101からTCP切断118を行い、通常のTCP接続の切断を行なって一連のシーケンスが完了する。」(14?16頁) イ.「【0072】 なお、本実施の形態では機器101からの接続先はサーバ104のみであり、サーバ104が端末102と機器101間の通信を転送したが、接続要求UDPパケット109により端末102のアドレスを通知すれば、機器101が端末102に対し直接TCP接続要求110を送信する構成も可能である。この構成によれば、端末102と機器101が直接通信を行なうことが可能になり、サーバ104の転送負荷が低減されるなど別の効果がある。」(17?18頁) ウ.「【0075】 (実施の形態2) 本発明に係る通信システムの別の実施形態を説明する。 本実施形態のネットワーク接続は図2で示したとおりである。アドレス付与も第1の実施の形態と同じであり、通信シーケンスのみが異なっている。本実施の形態では端末としてWebブラウザを備えたPCや携帯電話を用いており、これを用いてLANに接続された機器101とHTTPによる通信を行なって操作やコンテンツ取得などを行なうものである。 ・・・(中略)・・・ 【0086】 その後、サーバ104はHTTPリクエスト411に対する応答としてHTTPレスポンス415を端末102に送信する。このHTTPレスポンス415は、端末102に表示すべきHTMLコンテンツを含んでおり、かつ、このHTMLコンテンツにはセッション識別子”5678”が、例えば「<A HREF=”control.cgi?SessionID=5678&Target=deviceFunc.cgi&Param=abcd”>リンク</A>」のようにリンクやボタンとして埋め込まれている。以上の手順により、端末102には機器101に対応するページ(画像)が表示される。 【0087】 次に、ユーザが表示されたページ内のリンクをクリックすると、”GET control.cgi?SessionID=5678&Target=deviceFunc.cgi&Param=abcd”等のようにセッション識別子を含むHTTPリクエスト416が生成されてサーバ104に送信される。サーバ104はHTTPリクエスト416を受信すると、指定されたcontrol.cgiが起動し、セッション識別子”5678”を照合する(ステップS426)。照合した結果、セッション識別子”5678”のTCP接続が既に確立済みであることを検出すると、サーバ104のcontrol.cgiは、HTTPリクエスト416の内容を”GET deviceFunc.cgi?Param=abcd”のように変換してHTTPリクエスト転送417としてそのTCP接続上に転送する。このようにして、端末102は、機器101に対するHTTPリクエストを送信できる。」(18?20頁) 上記引用例の記載及び図面並びにこの分野における技術常識を考慮すると、 a.上記引用例の図2に記載された通信システムは、NAPT機能を実装しLAN106とインターネット105とを接続するルータ103を介して、LAN106に接続された機器101とインターネット105に接続された通信端末102との間で通信を行うものであるが(摘記事項ア.の段落【0044】-【0045】)、 a1.一般に、NAPT機能が、内部から外部向けへのアウトバウンド通信のみ許容し、内部ネットワークに属するノードを外部ネットワークから隠蔽するものであることは技術常識であり、 a2.「サーバ104はそのTCP接続上で端末102と機器101間の通信の転送を開始する。すなわち、サーバ104は端末102からの通信114を通信115として機器101に転送し」(摘記事項ア.の段落【0058】)とあるように、LAN106に接続された機器101とインターネット105に接続された通信端末102との間でのTCP接続上での通信端末102から機器101への通信も可能としており、 b.機器101は、LAN106を介してルータ103と接続するが、該機器101は、 b1.「周期的に通知UDPパケット109を送信する」(摘記事項ア.の段落【0047】)もので、「通知UDPパケット109はルータ103により、往路のNAPT変換が行なわれた後インターネット105に送出され、サーバ104にて受信される」(摘記事項ア.の段落【0047】)ものであり、また、「サーバ104は、通知UDPパケット109を受信すると、ヘッダ内のSA、DA、SP、DPの各アドレスと機器IDを取り出し、図4に示すように、これらの情報を機器101(機器ID=”1234”)に対応する1組のエントリとしてサーバ内に登録保存する(ステップS119)。」(摘記事項ア.の段落【0049】)及び「通知UDPパケットの送信周期は、ルータ103がUDPパケットのNAPTテーブルをタイムアウトにより破棄する時間よりも短く設定する。これによりルータ103には、図9(b)に示したようなNAPTテーブルがタイムアウトせず継続的に保持される。」(摘記事項ア.の段落【0048】)の記載によれば、上記通知UDPパケット109は、ヘッダ内のSA、DA、SP、DPの各アドレスと機器IDを対応付けた情報の通知及びNAPTテーブルの維持を行うためのものといえるから、結局、機器101は、インターネット105上のサーバ104に対し、ヘッダ内のSA、DA、SP、DPの各アドレスと機器IDを対応付けた情報の通知及びNAPTテーブルの維持を目的とする通知UDPパケット109を周期的に送信し、 b2.通信端末102から機器101に対する通信を開始したい場合、通信端末102は機器101の機器IDをパラメータに指定して、サーバ104に対し機器接続要求110を送信し(摘記事項ア.の【0050】)、該機器接続要求110を受信したサーバ104は、一意なセッション識別子を生成し、機器101に対応するエントリからSA、DA、SP、DPの各アドレスを取得し、これらを用いてセッション識別子をペイロードに含む接続要求UDPパケット111を通知UDPパケット109に対する応答として送信する(図1および摘記事項ア.の段落【0053】)から、結局、機器101は、通知UDPパケット109に対する応答として、前記サーバ104から前記セッション識別子をペイロードに含む接続要求UDPパケット111を受信し、 b3.機器101は、サーバ104に対してTCP接続要求112を送信してTCP接続を開始し(図1及び摘記事項ア.の段落【0054】)、 b4.機器101は、上記b1.?b3.の動作を行う以上、そのための手段を備えていることは自明であり、 c.上記b2.の接続要求UDPパケット111の受信は、通信端末102がサーバ104に対して送信する機器接続要求110を契機として行われることは図1の記載から明らかであり、また、該機器接続要求110が上記b1.の周期的な通知UDPパケット109の送信とは無関係に発生することも明らかであるから、通知UDPパケット109を周期的に送信する処理及び接続要求UDPパケット111を受信する処理は非同期に遂行されるといえ、 d.上記c.の非同期に遂行される処理に関し、 d1.通信端末102からの機器接続要求110を受信したサーバ104は、通知UDPパケット109に基づくエントリを参照し、「エントリ内の最終アクセス時刻を確認し、現在時刻との差が最大アクセス確認周期を超えている場合は機器接続要求110を拒否し、最大アクセス確認周期以下の場合は、ステップS122以後に進んで機器101に接続要求UDPパケット111を送信する」(摘記事項ア.の段落【0051】)が、「機器101は周期的に通知UDPパケット109を送信する。この周期は先に取得した最大アクセス確認周期の値(例えば5分)より小さい間隔で送られる」(摘記事項ア.の段落【0047】)のであるから、通知UDPパケット109の周期的な送信の期間中にサーバ104が通信端末102から機器接続要求110を受信したときには、エントリ内の最終アクセス時刻と現在時刻との差が最大アクセス確認周期以下であることは自明であって、その場合、通知UDPパケット109に対する応答としてサーバ104から送信された接続要求UDPパケット111を機器101が受信する処理が実行され、 以上を総合すれば、結局、上記引用例には、以下の発明(以下、「引用発明」という。)が開示されている。 「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているNAPT機能を実装するルータ103により外部ネットワークから隠蔽され、かつLAN106に接続された機器101と、インターネット105に接続された通信端末102との間でのTCP接続上での通信端末102から機器101への通信も可能にする通信システムであって; 前記LAN106を介してルータ103と接続する機器101が、 前記インターネット105上のサーバ104に対し、ヘッダ内のSA、DA、SP、DPの各アドレスと機器IDを対応付けた情報の通知及びNAPTテーブルの維持を目的とする通知UDPパケット109を周期的に送信する手段; 前記通知UDPパケット109に対する応答として、前記サーバ104からセッション識別子をペイロードに含む接続要求UDPパケット111を受信する手段; 前記サーバ104とTCP接続を開始する手段とを備え; 前記通知UDPパケット109を周期的に送信する処理及び前記接続要求UDPパケット111を受信する処理は非同期に遂行され、前記非同期に遂行される処理では、前記通知UDPパケット109の周期的な送信の期間中にサーバ104が通信端末102から機器接続要求110を受信したとき、前記通知UDPパケット109に対する応答として前記サーバ104から送信された前記接続要求UDPパケット111を前記機器101が受信する処理が実行される、 通信システム。」 (3)対比・判断 補正後の発明と引用発明とを対比すると、 a.引用発明の「NAPT機能を実装するルータ103」は、インターネット105とLAN106との境界に設けられた装置であって、補正後の発明の「ゲートウェイ装置」に含まれる。 b.引用発明の「LAN106」、「機器101」、「インターネット105」、「通信端末102」、「サーバ104」は、それぞれ、補正後の発明の「内部ネットワーク」、「内部ノード」、「外部ネットワーク」、「外部ノード」、「接続支援装置」に相当する。 c.引用発明の「ネットワーク」に「接続された」は、補正後の発明の「ネットワーク」に「属する」と同義である。 d.引用発明の「通信端末102から機器101への通信」は、外部から内部への通信であって、明らかに補正後の発明の「外部から内部向けへのインバウンド通信」に相当するから、引用発明の「TCP接続上での通信端末102から機器101への通信」と補正後の発明の「意図するIPアプリケーション通信での外部から内部向けへのインバウンド通信」とは、「外部から内部向けへのインバウンド通信」で共通する。 e.補正後の発明の「IPアプリケーションサービス提供システム」が、通信を行うシステムであることは明らかであって、引用発明の「通信システム」とは、「通信システム」である点で共通する。 f.引用発明の「前記LAN106を介してルータ103と接続する機器101」に関し、ルータ103は、NAPT機能を有し機器101のアドレス変換などを行うものであって、機器101を配下に置くものといえるから、引用発明の「前記LAN106を介してルータ103と接続する機器101」と補正後の発明の「前記ゲートウェイ装置配下の前記内部ノード」との間に実質的な差異は無く、 g.引用発明の「ヘッダ内のSA、DA、SP、DPの各アドレス」は、機器101が周期的に送信する通知UDPパケット109が、ルータ103により往路のNAPT変換された後のアドレスであるから(摘記事項ア.の段落【0047】)、上記「SP」は、上記通知UDPパケット109を送信する際に使われた、機器101のための外部ネットワークにおけるポートであり、補正後の発明の「制御チャネルポート」に相当するといえる。 とすると、引用発明の「ヘッダ内のSA、DA、SP、DPの各アドレスと機器IDを対応付けた情報の通知」は、補正後の発明の「制御チャネルポートの通知」に含まれるといえる。 h.引用発明の「NAPTテーブル」とは、具体的には、機器101が周期的に送信する通知UDPパケット109が、ルータ103により往路のNAPT変換されるときに作られる、図9のようなNAPTエントリであると認められるが(摘記事項ア.の段落【0048】)、このようなNAPTエントリが、通知UDPパケット109に対する応答として構成された接続要求UDPパケット111(摘記事項ア.の段落【0053】)の通信を許容するために用いられることは明らかであるから、結局、引用発明の「NAPTテーブル」は補正後の発明の「制御チャネルパスの通信許容エントリ」に相当する。 i.上記g.及びh.における検討から、引用発明の「通知UDPパケット109」は明らかに補正後の発明の「制御パケット」に相当する。 j.引用発明の「周期的に送信し」は補正後の発明の「定期送信する」と同義である。 k.上記h.における検討から明らかなように、引用発明の「前記通知UDPパケット109に対する応答として」は、補正後の発明の「維持されている制御チャネルを通して」に相当する。 l.引用発明の「セッション識別子をペイロードに含む接続要求UDPパケット111」は、通信端末102からの機器接続要求110の送信を契機として作られるから(図1及び摘記事項ア.の段落【0050】-【0056】)、「通信端末102に関連する通知」といえる。一方、補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知」も「外部ノードに関連する通知」であることは明らかであるから、両者は、「外部ノードに関連する通知」である点で共通する。 m.補正後の発明の「IPアプリケーションのデータチャネルをアクティブにオープンする」に関し、本願明細書には、「第3の処理(第3のステップ):内部ノードAは、通知を受けた接続先IPアドレス:ポートに対し、トランスポート層プロトコル(TCP(Transmission Control Protocol)/UDP(User Datagram Protocol))接続を開始、すなわちIPアプリケーションデータチャネルをアクティブにオープンする。」(段落【0027】)と記載されているから、「TCP接続を開始する」を意味するものと認められる。 とすると、引用発明の「前記サーバ104とTCP接続を開始する手段」と補正後の発明の「前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくIPアプリケーションのデータチャネルをアクティブにオープンする手段」とは、「TCP接続を開始する手段」である点で共通する。 n.上記i.及びj.における検討によれば、引用発明の「前記通知UDPパケット109を周期的に送信する処理」は、補正後の発明の「前記制御パケットを定期送信する処理」に相当し、 o.上記l.における検討によれば、引用発明の「前記接続要求UDPパケット111を受信する処理」と補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理」とは、「前記外部ノードに関連する通知を受ける処理」で共通する。 p.引用発明の「前記非同期に遂行される処理では」と補正後の発明の「前記非同期は」とは実質的に同義であり、 q.上記i.及びj.における検討によれば、引用発明の「前記通知UDPパケット109の周期的な送信の期間中に」は、補正後の発明の「前記制御パケットの定期送信の期間中に」に相当し、 r.引用発明の「機器接続要求110」は、明らかに補正後の発明の「接続要求」に相当するから、引用発明の「サーバ104が通信端末102から機器接続要求110を受信したとき」と補正後の発明の「前記接続支援装置が前記外部ノードから接続要求を受信したとき」との間に差異は無く、 s.引用発明の「前記通知UDPパケット109に対する応答として前記サーバ104から送信された前記接続要求UDPパケット111を前記機器101が受信する処理が実行される」と補正後の発明の「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」とを対比するに、 s1.上記k.における検討によれば、引用発明の「前記通知UDPパケット109に対する応答として」は、補正後の発明の「維持されている制御チャネルを通して」に相当し、 s2.上記l.における検討によれば、引用発明の「接続要求UDPパケット111」と、補正後の発明の「外部ノード対応の接続先アドレス及びポートの通知」とは、「外部ノードに関連する通知」で共通し、 s3.引用発明の接続要求UDPパケット111はサーバ104から送信されるから、引用発明の「前記接続要求UDPパケット111を前記機器101が受信する処理」は、「サーバ104を起点として」実行されると言い得るものであり、 s4.上記s1.?s3.より、結局、引用発明の「前記通知UDPパケット109に対する応答として前記サーバ104から送信された前記接続要求UDPパケット111を前記機器101が受信する処理が実行される」と、補正後の発明の「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」とは、「前記内部ノードで前記外部ノードに関連する通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」点で共通している。 以上をまとめると、両者は、以下の点で一致ないし相違している。 (一致点) 「内部から外部向けへのアウトバウンド通信のみを許容するように設定されているゲートウェイ装置により外部ネットワークから隠蔽され、かつ内部ネットワークに属する内部ノードと、前記外部ネットワークに属する外部ノードとの間での外部から内部向けへのインバウンド通信も可能にする通信システムであって; 前記ゲートウェイ装置配下の前記内部ノードが、 前記外部ネットワーク上の接続支援装置に対し、制御チャネルポートの通知及び制御チャネルパスの通信許容エントリの維持を目的とする制御パケットを定期送信する手段と; 維持されている制御チャネルを通して、前記接続支援装置から前記外部ノードに関連する通知を受ける手段と; TCP接続を開始する手段とを備え; 前記制御パケットを定期送信する処理及び前記外部ノードに関連する通知を受ける処理は非同期で遂行され、前記非同期は、前記制御パケットの定期送信の期間中に前記接続支援装置が前記外部ノードから接続要求を受信したとき、前記内部ノードで前記外部ノードに関連する通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されることである通信システム。」 (相違点1) 「外部から内部向けへのインバウンド通信」が、 補正後の発明では、「意図するIPアプリケーション通信での外部から内部向けへのインバウンド通信」であるのに対し、 引用発明では、「TCP接続上での通信端末102から機器101への通信」である点。 (相違点2) 「通信システム」が、 補正後の発明では、「IPアプリケーションサービス提供システム」であるのに対し、 引用発明では、単に「通信システム」である点。 (相違点3) 「外部ノードに関連する通知」が、 補正後の発明では、「前記外部ノード対応の接続先アドレス及びポートの通知」であるのに対し、 引用発明では、「セッション識別子をペイロードに含む接続要求UDPパケット111」である点。 (相違点4) 「TCP接続を開始する手段」が、 補正後の発明では、「前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくIPアプリケーションのデータチャネルをアクティブにオープンする手段」であるのに対し、 引用発明では、「前記サーバ104とTCP接続を開始する手段」である点。 (相違点5) 「前記内部ノードで前記外部ノードに関連する通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」が、 補正後の発明では、「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行されることである」であるのに対し、 引用発明では、「前記通知UDPパケット109に対する応答として前記サーバ104から送信された前記接続要求UDPパケット111を前記機器101が受信する処理が実行される」である点。 以下に、上記各相違点につき検討する。 (相違点1)について まず、引用発明の「通信端末102から機器101への通信」が、補正後の発明の「外部から内部向けへのインバウンド通信」に相当することは明らかである。 そして、引用発明の「TCP接続上での通信端末102から機器101への通信」として、引用例には「HTTPによる通信を行なって操作やコンテンツ取得などを行なう」(摘記事項ウ.の段落【0075】)ことが例示され、さらに、HTTPリクエストやHTTPレスポンスなどのメッセージにより端末102に表示すべきHTMLコンテンツを取得することが記載されている(摘記事項ウ.の段落【0086】-【0087】)。 ここで、HTTPがIPアプリケーションであることは技術常識であり、上記のような、HTTPリクエストやHTTPレスポンスなどのメッセージにより端末102に表示すべきHTMLコンテンツを取得することは、「意図するIPアプリケーション通信」といいうるものである。また、上記の例では、端末102がHTMLコンテンツを取得しているが、これとは逆に、機器101がHTMLコンテンツを取得する通信も可能であることは当業者にとって明らかである。 したがって、引用発明の「TCP接続上での通信端末102から機器101への通信」を、補正後の発明の「意図するIPアプリケーション通信での外部から内部向けへのインバウンド通信」とすることは、引用例の記載に基づいて当業者が容易に想到し得るものである。 (相違点2)について 上記「(相違点1)について」で検討したように、引用例には、「通信」の例としてHTTPによるコンテンツ取得が記載されているが、この通信を、コンテンツを取得する側から見れば、「IPアプリケーションサービス」の「提供」を受けていると見ることができるから、引用発明の「通信システム」を補正後の発明のように「IPアプリケーションサービス提供システム」とすることは、当業者が必要に応じて適宜なし得るものである。 (相違点3)及び(相違点4)について 引用例には、「なお、本実施の形態では機器101からの接続先はサーバ104のみであり、サーバ104が端末102と機器101間の通信を転送したが、接続要求UDPパケット109により端末102のアドレスを通知すれば、機器101が端末102に対し直接TCP接続要求110を送信する構成も可能である。この構成によれば、端末102と機器101が直接通信を行なうことが可能になり、サーバ104の転送負荷が低減されるなど別の効果がある。」(摘記事項イ.の段落【0072】、なお、「接続要求UDPパケット109」は「接続要求UDPパケット111」の誤記と認められる。)と記載されており、機器101が、サーバ104を介することなく、通信端末102に直接TCP接続を開始することが記載されている。 この記載に基づけば、引用発明の接続要求UDPパケット111に含ませる情報を通信端末102のアドレスとすることにより、引用発明の「セッション識別子をペイロードに含む接続要求UDPパケット111」を、補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知」と変更すること(相違点3)は当業者が容易に想到し得るものである。 また、該通知を受けた後のTCP接続について、接続先を通信端末102とすることにより、引用発明の「前記サーバ104とTCP接続を開始する手段」を、補正後の発明の「前記通知を受けた接続先アドレス及びポートに対して、前記接続支援装置を介することなくIPアプリケーションのデータチャネルをアクティブにオープンする手段」とすること(相違点4)も当業者が容易に想到し得るものである。 (相違点5)について まず、上記「k.」で対比したように、引用発明の「前記通知UDPパケット109に対する応答として」は、補正後の発明の「維持されている制御チャネルを通して」に相当する。 また、引用発明の「前記サーバ104から送信された」は、明らかに、補正後の発明の「前記接続支援装置を起点として」に相当する。 さらに、上記「(相違点3)及び(相違点4)について」で検討したように、引用発明の(セッション識別子をペイロードに含む)「接続要求UDPパケット111」を、補正後の発明の「前記外部ノード対応の接続先アドレス及びポートの通知」とすることは当業者が容易に想到し得るものである。 とすると、結局、引用発明の「前記通知UDPパケット109に対する応答として前記サーバ104から送信された前記接続要求UDPパケット111を前記機器101が受信する処理が実行される」を、補正後の発明の「前記内部ノードで前記外部ノード対応の接続先アドレス及びポートの通知を受ける処理が前記接続支援装置を起点として前記維持されている制御チャネルを通して実行される」とすることは、当業者が容易に想到し得るものである。 そして、補正後の発明の作用・効果も引用発明から当業者が予測し得る範囲のものである。 4.結語 以上のとおり、本件補正は、補正後の発明が特許出願の際独立して特許を受けることができないものであるから、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する特許法第126条第5項の規定に適合していない。 したがって、本件補正は、特許法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3.本願発明について 1.本願発明 平成23年5月12日付けの手続補正は上記のとおり却下されたので、本願発明は上記「第2.補正却下の決定」の項中の「1.本願発明と補正後の発明」の項で「本願発明」として認定したとおりである。 2.引用発明 引用発明は、上記「第2.補正却下の決定」の項中の「3.独立特許要件について」の項中の「(2)引用発明」の項で認定したとおりである。 3.対比・判断 そこで、本願発明と引用発明とを対比するに、 本願発明は上記補正後の発明から当該補正に係る限定を省いたものである。 そうすると、本願発明の構成に当該補正に係る限定を付加した補正後の発明が、上記「第2.補正却下の決定」の項中の「3.独立特許要件について」の項で検討したとおり、引用発明に基づいて当業者が容易に発明できたものであるから、本願発明も同様の理由により、容易に発明できたものである。 4.むすび 以上のとおり、本願発明は、引用例の記載に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり審決する。 |
審理終結日 | 2012-07-19 |
結審通知日 | 2012-07-24 |
審決日 | 2012-08-07 |
出願番号 | 特願2006-260830(P2006-260830) |
審決分類 |
P
1
8・
121-
Z
(H04L)
P 1 8・ 575- Z (H04L) |
最終処分 | 不成立 |
前審関与審査官 | 衣鳩 文彦 |
特許庁審判長 |
竹井 文雄 |
特許庁審判官 |
山本 章裕 新川 圭二 |
発明の名称 | IPアプリケーションサービス提供システム |
代理人 | 高田 大輔 |
代理人 | 松倉 秀実 |
代理人 | 平川 明 |