ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1154932 |
| 審判番号 | 不服2004-8589 |
| 総通号数 | 89 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2007-05-25 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2004-04-26 |
| 確定日 | 2007-03-28 |
| 事件の表示 | 特願2000-571355「インターネットキャッシングシステム、方法およびそのシステムの構成」拒絶査定不服審判事件〔平成12年 3月30日国際公開、WO00/17765、平成14年 8月13日国内公表、特表2002-525749〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
1.手続きの経緯・本願発明 本願は、1999年9月22日(パリ条約による優先権主張外国庁受理1998年9月24日、スウェーデン国)を国際出願日とする出願であって、平成15年6月5日付けで拒絶理由通知がなされ、これに対し、同年12月10日付けで手続補正がなされたが、平成16年1月20日付けで拒絶査定がなされ、これに対し、同年4月26日に審判請求がなされたものである。 そして、その請求項1に係る発明(以下本願発明という。)は、特許請求の範囲の請求項1に記載された次のとおりのものと認める。 「ローカルインターネットキャッシュサーバにおいて、ユーザからインターネット情報ファイルを求めるユーザ要求を受信するステップと、 受信された前記要求に応答して、前記情報ファイルが前記ローカルサーバによってキャッシュされていない場合に前記情報ファイルを問い合わせるステップと、 前記問い合わせに対するリプライに応答して、前記情報ファイルを求めるファイル要求を生成するステップであって、キャッシュされたインターネット情報ファイルを格納する中央ファイルサーバが前記情報ファイルをキャッシュしていることを前記リプライが示す場合には、前記ファイル要求をフィーダー手段に送る、ステップと、 前記ファイル要求に応答して、前記フィーダー手段から前記中央ファイルサーバに前記情報ファイルを問い合わせるステップと からなる、インターネットキャッシングシステムでインターネット情報ファイルの要求に供される方法。」 2.引用文献 A.これに対して、原査定の拒絶の理由に引用された特開平10-21174号公報(以下、「引用例」という。)には図面とともに以下の事項が記載されている。 (ア)「【0012】 【発明の実施の形態】以下、本発明を図面に基づいて説明する。図1は、請求項1から4のいずれかに記載のデータ転送システムの構成を示す概略図である。図1において、1a、1b・・・はクライアント、20はキャッシュサーバ、10aは少なくともクライアント1a、1b・・・とキャッシュサーバ20を高速通信回線3aを介して接続したLANが構築された事業所であって、クライアント1a、1b・・・は、各々個別にキャッシュサーバ20にデータ要求することができる。このような事業所10a、10b・・・毎に構築されたLANは電話回線等の低速通信回線4を介して相互に接続され、WAN100を構成している。WAN100には全ての事業所10a、10b・・・のLANに接続されたクライアントが共通に使用できるデータサーバ5を備えたセンター30が設置されており、データサーバ5はセンター30において一括して管理、運用が行われる。 【0013】次に、本発明の特徴であるキャッシュサーバ20の構成について図2にブロック図を示す。キャッシュサーバ20は、クライアント1からのデータ要求を受け付けるとともに、クライアント1に該当するデータを転送する入出力機能を有するクライアントインターフェイス(クライアントI/F)部21、データサーバ5にデータ要求を送るとともに、データサーバ5から転送されるデータを受ける入出力機能を有するサーバインターフェイス(サーバI/F)部22、クライアント1からのデータ要求の際に受け取る識別信号(ID)等にしたがって、要求されたデータが格納されたデータ内に存在するか否かを調べるとともに、データサーバ5から転送されたデータの格納位置を求めるデータ管理部23、データ管理部23からの指示にしたがってデータサーバ5から転送されたデータをデータファイル群25の所定の位置に格納するとともに、データファイル群25の記憶容量の残量および格納されるデータのサイズに応じて既存のデータを削除するデータ格納部24、クライアント1からキャッシュサーバ20に格納された各データへのアクセス(参照)時刻あるいはアクセス(参照)回数等の参照情報を参照情報管理ファイル27に格納し、データサーバ5からのデータを格納する際、データファイル群25の記憶容量の残量および格納されるデータのサイズに応じて、データファイル群25に格納されたデータから参照時刻の古い、あるいは参照回数の少ないデータを判別し、その判別結果をデータ格納部24に通知するデータ参照情報管理部26とを有して構成される。」 (イ)「【0019】次に、キャッシュサーバ20におけるデータ要求チェック処理の他の実施例について、図5のフローチャートを参照して説明する。 ・・・(中略)・・・ 【0020】キャッシュサーバ20は、クライアント1からデータ要求を受けると(S21)、データの識別子からデータの位置を判別し(S22)、データファイル群25の該当する位置にデータが存在するか否かをチェックする(S23)。該当するデータが存在する場合には、上述した実施例同様、データファイル群25から該当するデータを取り出して高速通信回線3を介してクライアント1に転送し(S44)、参照情報管理ファイル27の該当データの参照情報を更新する(S25)。データファイル群25の該当する位置にデータが存在しない場合には、データ管理部23は、サーバI/F部22から低速通信回線4を介して近傍のLANに接続された複数のキャッシュサーバ20′、20″・・・に対して該当するデータが存在するか否かを問い合わせる(S26)。問い合わせを受けた各キャッシュサーバ20′、20″・・・は自己のデータファイル群に該当するデータが存在するか否かをチェックし(S27)、その結果をキャッシュサーバ20に返す。キャッシュサーバ20は、問い合わせ結果に基づいて、該当するデータを格納しているキャッシュサーバのうち最も近傍に位置するキャッシュサーバ(たとえば20″)に対してデータ要求を行なう(S28)。キャッシュサーバ20″は、データ要求を受け取って自己のデータファイル群から該当するデータを取り出し、低速通信回線4を介してキャッシュサーバ20に転送する。キャッシュサーバ20は、転送されたデータを高速通信回線3を介してクライアント1へ転送し、次いでデータ格納部24を介して自己のデータファイル群25へ格納する。また近傍のキャッシュサーバ20′、20″・・・への問い合わせに対し、いずれのキャッシュサーバ20′、20″・・・も該当するデータを格納していないことが判明した場合には、キャッシュサーバ20は、低速通信回線4を介してデータサーバ5にデータ要求を行ない(S29)、データサーバ5は、該当するデータを取り出して、キャッシュサーバ20へ転送する。キャッシュサーバ20は、データサーバ5から受け取ったデータを高速通信回線3を介してクライアント1へ転送し、次いでデータファイル群25へ格納する。」 ここで、(ア)の段落【0012】記載の「クライアント1a、1b・・・は、各々個別にキャッシュサーバ20にデータ要求することができる。」からすると、キャッシュサーバ20は、クライアント1a、1b・・・に対するローカルキャッシュサーバであると解される。 同じく、段落【0012】記載の「このような事業所10a、10b・・・毎に構築されたLANは電話回線等の低速通信回線4を介して相互に接続され、」及び(イ)の段落【0020】全体の記載からすると、キャッシュサーバ20′、20″・・・は、キャッシュサーバ20と連携する連携キャッシュサーバであると解される。 次に、キャッシュ連携について、詳細を見てみる。 まず、(イ)の段落【0020】記載の「キャッシュサーバ20は、クライアント1からデータ要求を受けると」からすると、キャッシュサーバ20は、ユーザからデータを求めるユーザ要求を受信するステップを有するものと解される。 同じく、段落【0020】記載の「データファイル群25の該当する位置にデータが存在しない場合には、データ管理部23は、サーバI/F部22から低速通信回線4を介して近傍のLANに接続された複数のキャッシュサーバ20′、20″・・・に対して該当するデータが存在するか否かを問い合わせる(S26)。」からすると、キャッシュサーバ20は、受信された前記要求に応答して、前記データが前記キャッシュサーバ20によってキャッシュされていない場合に問い合わせるステップを有するものと解される。 そして、段落【0020】記載の「問い合わせを受けた各キャッシュサーバ20′、20″・・・は自己のデータファイル群に該当するデータが存在するか否かをチェックし(S27)、その結果をキャッシュサーバ20に返す。キャッシュサーバ20は、問い合わせ結果に基づいて、該当するデータを格納しているキャッシュサーバのうち最も近傍に位置するキャッシュサーバ(たとえば20″)に対してデータ要求を行なう(S28)。」とあり、また前記キャッシュサーバが「サーバI/F部22」を介して送受信していることからすると、キャッシュサーバ20は、前記問い合わせに対するリプライに応答して、前記データを求めるデータ要求を生成するステップを有するとともに、キャッシュされたデータを格納するキャッシュサーバ20″が前記データをキャッシュしていることを前記リプライが示す場合には、前記データ要求を前記キャッシュサーバ20″のサーバI/F部22に送るステップを有するとともに、前記キャッシュサーバ20″のサーバI/F部22が、前記データ要求を受け取るものと解される。 そして、段落【0020】記載の「キャッシュサーバ20″は、データ要求を受け取って自己のデータファイル群から該当するデータを取り出し、」からすると、キャッシュサーバ20″は、前記データ要求に応答して、該当するデータを取り出すステップを有するものと解される。 そして、段落【0020】に「キャッシュサーバ20は、クライアント1からデータ要求を受けると(S21)、データの識別子からデータの位置を判別し(S22)、データファイル群25の該当する位置にデータが存在するか否かをチェックする(S23)。該当するデータが存在する場合には、上述した実施例同様、データファイル群25から該当するデータを取り出して」と記載があるように、キャッシュサーバからデータを取り出す際には、データの識別子からデータの位置を判別し(S22)、データファイル群25の該当する位置にデータが存在するか否かをチェックしていることから、データの格納位置を問い合わせていると認められる。 してみれば、前記取り出すステップは、データファイル群25に前記データを問い合わせるステップを有すると認められる。 そして、引用例に記載された技術は、キャッシングシステムでデータの要求に供される方法を開示していると認められる。 したがって、引用例には、次の発明(以下「引用発明」という。)が記載されている。 ローカルキャッシュサーバにおいて、ユーザからデータを求めるユーザ要求を受信するステップと、 受信された前記要求に応答して、前記データが前記ローカルキャッシュサーバによってキャッシュされていない場合に前記データを問い合わせるステップと、 前記問い合わせに対するリプライに応答して、前記データを求めるデータ要求を生成するステップであって、キャッシュされたデータを格納する連携キャッシュサーバが前記データをキャッシュしていることを前記リプライが示す場合には、前記データ要求を前記連携キャッシュサーバのサーバI/F部に送るステップと、 前記データ要求に応答して、連携キャッシュサーバのサーバI/F部を介して、前記連携キャッシュサーバに前記データを問い合わせるステップと、 からなる、キャッシングシステムでデータの要求に供される方法。 3.対比 引用発明の「ローカルキャッシュサーバ」と、本願発明の「ローカルインターネットキャッシュサーバ」とは、ともに、ローカルキャッシュサーバである点で共通する。 また、引用発明の「データ」と、本願発明の「インターネット情報ファイル」とは、ともに、データである点で共通する。 また、引用発明の「連携キャッシュサーバ」と、本願発明の「中央ファイルサーバ」とは、ともに、キャッシュされたデータを格納することから、キャッシュデータ格納手段である点で共通する。 そして、引用発明の「連携キャッシュサーバのサーバI/F部」と本願発明の「フィーダー手段」とは、ともに、データ要求を受信することから、通信フロントエンド手段である点で共通する。 そして、引用発明の「前記データ要求に応答して、連携キャッシュサーバのサーバI/F部を介して、前記連携キャッシュサーバに前記データを問い合わせるステップ」と本願発明の「前記ファイル要求に応答して、前記フィーダー手段から前記中央ファイルサーバに前記情報ファイルを問い合わせるステップ」とは、ともに、前記データ要求に応答して、通信フロントエンド手段を介して、前記キャッシュデータ格納手段に前記データを問い合わせるステップである点で共通する。 したがって、本願発明と引用発明とは、以下の点で一致し、また、相違している。 (一致点) ローカルキャッシュサーバにおいて、ユーザからデータを求めるユーザ要求を受信するステップと、 受信された前記要求に応答して、前記データが前記ローカルキャッシュサーバによってキャッシュされていない場合に前記データを問い合わせるステップと、 前記問い合わせに対するリプライに応答して、前記データを求めるデータ要求を生成するステップであって、キャッシュされたデータを格納するキャッシュデータ格納手段が前記データをキャッシュしていることを前記リプライが示す場合には、前記データ要求を通信フロントエンド手段に送る、ステップと、 前記データ要求に応答して、通信フロントエンド手段を介して、前記キャッシュデータ格納手段に前記データを問い合わせるステップと、 からなる、キャッシングシステムでデータの要求に供される方法。 (相違点1) 「キャッシュ」及び「データ」に関し、本願発明は、「インターネット」をベースとした「インターネットキャッシュ」および「インターネット情報ファイル」であるのに対して、引用発明は、「インターネット」をベースとした「インターネットキャッシュ」および「インターネット情報ファイル」を構成としていない点。 (相違点2) 「通信フロントエンド手段」、及び「キャッシュデータ格納手段」に関し、本願発明は、それぞれ、「フィーダー手段」、及び「中央ファイルサーバ」であるのに対して、引用発明は、それぞれ「連携キャッシュサーバのサーバI/F部」、及び「連携キャッシュサーバ」である点。 (相違点3) 「前記データ要求に応答して、通信フロントエンド手段を介して、前記キャッシュデータ格納手段に前記データを問い合わせるステップ」に関し、本願発明は、「前記ファイル要求に応答して、前記フィーダー手段から前記中央ファイルサーバに前記情報ファイルを問い合わせるステップ」であるのに対して、引用発明は、「前記データ要求に応答して、連携キャッシュサーバのサーバI/F部を介して、前記連携キャッシュサーバに前記データを問い合わせるステップ」である点。 4.判断 まず、相違点1について検討する。 本願の優先権主張の日前である平成10年2月26日に頒布された刊行物(酒井明広、他3名、”分担型キャッシングシステムの設計と実装”、情報処理学会研究報告、社団法人情報処理学会、1998年2月26日、第98巻 第15号、P173-178)に 「今日のインターネットではWWW(Wｏｒld Wide Web)が代表的な情報サービスとなっている。 ・・・(中略)・・・ このため現在のインターネットではWWWにおける通信量の増加と帯域浪費が深刻な問題となっている。 これらの問題を解決するために、キャッシングプロキシサーバを用いる方法がある[1]。これは各クライアントが独自にオリジンサーバ(WWWサーバ)に情報を要求するのではなく、キャッシングプロキシサーバがクライアントに代わりオリジンサーバに情報を要求し、その情報をキャッシュする。クライアントからの要求するWWWの情報が、キャッシュにあればそれをクライアントに送る。このことによりオリジンサーバとキャッシングプロキシサーバ間の通信量が削減できる。」(173頁左欄2行目?174頁左欄9行目。)と記載されているように、インターネットをベースとしたキャッシュシステムは、当業者にとって周知である。 してみれば、インターネットをベースとするキャッシュを引用発明におけるキャッシュに適用することで、引用発明の「キャッシュ」及び「データ」を、それぞれ本願発明のように、「インターネットキャッシュ」及び「インターネット情報ファイル」とすることは、当業者であれば、適宜なし得たことである。 よって、相違点1は格別のものではない。 次に相違点2、3について検討する。 本願発明の「中央ファイルサーバ」における「中央」がどのような技術的態様を意味するか、特許請求の範囲の請求項1の記載において限定されていない。 したがって、引用発明の「連携キャッシュサーバ」と本願発明の「中央ファイルサーバ」とは、実質的に同等の連携キャッシュファイルサーバであると認められる。 なお、仮に「中央」がキャッシュサーバの階層関係を意味するとした場合においても、本願の優先権主張の日前である平成10年2月26日に頒布された刊行物(酒井明広、他3名、”分担型キャッシングシステムの設計と実装”、情報処理学会研究報告、社団法人情報処理学会、1998年2月26日、第98巻 第15号、P173-178)に 「また、これを応用した方法としてネットワークの階層的な構成にあわせて、複数のキャッシングプロキシサーバを階層的に構成し、ネットワーク全体としての通信量の削減がなされている[2]。」(174頁左欄10行目?174頁左欄13行目。)と記載されているように、また、本願の優先権主張の日前である平成10年7月1日に頒布された刊行物(的場謙一郎、”モダンネットワーキング第13回 Modern Networking”、SｕnWｏｒld、株式会社IDGコミュニケーションズ、1998年7月1日 、第8巻 第7号、P86-90)に、 「NeｔｒaPｒｏｘｙCacheは、ICPをサポ-トする。このICPは、複数のキャッシュ上のデ-タを相互利用することによって、効率の高いキャッシングを実現するプロトコルだ。 図3は、キャッシュ・サ-バを単純な親子関係で構成した例だ。ここでは、Webクライアントはプロキシ先をAに設定しているため、クライアントからの要求はまずAに送られる。要求されたオブジェクトがAにあればそれをそのまま利用する。オブジェクトがAに存在しない場合には、Aは自分の親であるBに間い合わせる。」(88頁右欄7行目?89頁左欄1行目。)」と記載されているように、連携キャッシュサーバ構成を階層構造とすることは当業者にとって周知技術である。 そして、本願の優先権主張の日前である平成10年7月31日に頒布された刊行物である特開平10-198642号公報に、 「【0003】 【従来の技術】 ・・・(中略)・・・ この方式では、サーバはクライアントからのリクエストを受けるフロントエンドノード(FEPノード)と、クライアントからのリクエストを処理する機能を複数台のノードに分散配置したバックエンドノード(BEPノード)群から構成されていた。全てのクライアントはFEPノードに対してリクエストを送り、FEPノードは要求されたサービスに対して適切なBEPノードにリクエストを転送して負荷分散を行っていた。」と記載されているように、 また、本願の優先権主張の日前である平成4年10月31日に頒布された刊行物(井上望、”クライアント/サーバー・システム構築法”、日経オープンシステム、日経BP社、1992年10月31日、第1号、P64-69)に、 「クライアント,APサーバー,DBサーバーの3階層で構成。増強時は比較的安いAPサーバー台数を増やす。負荷分散など高度な技術が必要」(64頁表1の(3)の概要。)と記載されているように、サーバを適宜、リクエストを受信するフロントエンドノード(もしくはAPサーバー)と該リクエストを処理するバックエンドノード(DBサーバー)とに分けて、フロントエンドノード(もしくはAPサーバー)からバックエンドノード(DBサーバー)に対して処理を依頼する(もしくは問い合わせる)ようなサーバの分散構成は、当業者にとって周知の常套手段である。 してみれば、仮に「中央」がキャッシュサーバの階層関係を意味するとした場合においても、連携キャッシュサーバ構成を階層構造として、連携キャッシュサーバのサーバI/F部をフロントエンドノード(もしくはAPサーバー)とするサーバの分散構成を採用することで、引用発明の「連携キャッシュサーバ内のサーバI/F部」、及び「連携キャッシュサーバ」を、それぞれ本願発明のように、「フィーダー手段」、及び「中央ファイルサーバ」とすることは、当業者であれば、適宜なし得たことである。 そして、そうすることで、引用発明における「前記データ要求に応答して、連携キャッシュサーバのサーバI/F部を介して、前記連携キャッシュサーバに前記データを問い合わせるステップ」が、本願発明のように、「前記ファイル要求に応答して、前記フィーダー手段から前記中央ファイルサーバに前記情報ファイルを問い合わせるステップ」となることは、論理的必然である。 よって、相違点2、3は格別のものではない。 そして、本願発明の作用効果も引用発明、及び前記周知技術から当業者が予測できる範囲のものである。 したがって、本願発明は、引用発明、及び前記周知技術から容易に発明することができたものである。 5.結び 以上のとおり、本願発明は、引用発明、及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 よって、結論のとおり、審決する。 |
| 審理終結日 | 2006-10-26 |
| 結審通知日 | 2006-10-31 |
| 審決日 | 2006-11-13 |
| 出願番号 | 特願2000-571355(P2000-571355) |
| 審決分類 |
P
1
8・
121-
Z
(G06F)
|
| 最終処分 | 不成立 |
| 前審関与審査官 | 鳥居 稔 |
| 特許庁審判長 |
赤川 誠一 |
| 特許庁審判官 |
成瀬 博之 小田 浩 |
| 発明の名称 | インターネットキャッシングシステム、方法およびそのシステムの構成 |
| 代理人 | 青山 葆 |
| 代理人 | 石野 正弘 |