ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 5項独立特許用件 特許、登録しない。 G06F 審判 査定不服 2項進歩性 特許、登録しない。 G06F |
|---|---|
| 管理番号 | 1267920 |
| 審判番号 | 不服2010-16628 |
| 総通号数 | 158 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 2013-02-22 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2010-07-23 |
| 確定日 | 2012-12-26 |
| 事件の表示 | 特願2003-521979「データにメタデータを加える方法」拒絶査定不服審判事件〔平成15年 2月27日国際公開、WO03/17141、平成17年 1月 6日国内公表、特表2005-500623〕について、次のとおり審決する。 |
| 結論 | 本件審判の請求は、成り立たない。 |
| 理由 |
第1 手続の経緯 本願は、2002年8月14日(パリ条約による優先権主張外国庁受理2001年8月17日、米国、2002年3月4日、米国)を国際出願日とする出願であって、平成22年3月12日付けで平成21年10月23日付けの手続補正が却下されて拒絶査定がなされ(発送日:同年3月23日)、これに対して平成22年7月23日に審判の請求がなされ、同時に手続補正と誤訳訂正がなされたものである。 第2 平成22年7月23日付けの手続補正についての補正却下の決定 [補正却下の結論] 平成22年7月23日付けの手続補正(以下、「本件補正」という。)を却下する。 [理由] 1.本願補正発明 本件補正により、特許請求の範囲の請求項1は、 「データの集合と、該データに関連付けられた第1のメタデータとに、メタデータを追加するための、コンピュータで実行する方法であって、 前記第1のメタデータと、前記集合における前記データ及び/又は前記第1のメタデータの1以上の位置とに基づいて、前記集合中のデータを識別するステップと、 該識別されたデータに基づいて、前記集合に第2のメタデータを追加するステップであって、該第2のメタデータは前記識別されたデータに対応する1以上のラベルであることを特徴とするステップと、 を具備することを特徴とする方法。」 と補正された。(下線は、補正箇所を示す。) 上記補正は、請求項1に記載した発明を特定するために必要な事項のうち、本件補正前(平成21年3月9日付け手続補正書参照)に、「前記第1のメタデータに基づく前記集合中のデータと、該データ及び/又は前記集合中の前記第1のメタデータの1以上の位置とを、識別するステップ」とあったものを、「前記第1のメタデータと、前記集合における前記データ及び/又は前記第1のメタデータの1以上の位置とに基づいて、前記集合中のデータを識別するステップ」とする限定を付加し、「該識別されたデータに基づいて、第2のメタデータを追加するステップ」とあったものを、「該識別されたデータに基づいて、前記集合に第2のメタデータを追加するステップであって、該第2のメタデータは前記識別されたデータに対応する1以上のラベルであることを特徴とするステップ」とする限定を付加するものであって、特許法第17条の2第4項第2号の特許請求の範囲の減縮を目的とするものに該当する。 そこで、本件補正後の前記請求項1に記載された発明(以下、「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか(特許法第17条の2第5項において準用する同法第126条第5項の規定に適合するか)について以下に検討する。 2.引用例及び周知例 A.引用例1(「はじめて使うdBASEIII」) 原査定の拒絶の理由で引用された、本願の優先日前である1987年2月10日に公開された、(株)バインス情報センター、「はじめて使うdBASEIII」、日本、技術評論社、1987年2月10日、初版第3刷、ｐ.20-26、47-51(以下「引用例1」という。)には、図面と共に、次の事項が記載されている(下線は当審にて付与。以下同様。)。 (1) 49ページ1-8行 「データの合計をとる?TOTAL 売上金額集計のためにURIAGEファイル内の同一の担当コードで合計を取り,これをファイル名URIAGE_Tとします(図1.41)。ここではTOTALコマンドを利用して同一の担当者コードで合計を取る処理を行います。TOTALコマンドは指定した数値フィールドの合計を取ったりするために用意されています。ただし,合計を取るためのキーはソート(昇順)されていなければなりません。USEコマンドでURIAGE_Tのファイルを開き,URIAGE_Tのリストを取ります(図1.42)。」 (2) 49ページ図1.42 49ページ「図1.42 担当コードごとに合計される」には、URIAGE_Tファイルのリスト表示として、以下の記載があると認められる。 「.USE URIAGE_T .LIST レコード 日付 担当コード 売上金額 1 07/01/61 1001 2100000 2 07/02/61 1002 1100000 3 07/04/61 1003 4000000 4 08/02/61 1004 1000000 5 08/03/61 1005 3500000 6 08/04/61 1006 2000000」 (3) 50ページ7-12行 「ファイルを結合する?JOIN この第1ファイル(TANTONDX)と第2ファイル(URIAGE_T)をJOINコマンドでリンク(結合)します。TANTONDXのコードフィールドとURIAGE_Tの担当コードフィールドが同じ場合は,フィールド,コード,担当者名,売上目標額,売上金額で構成されるデータベースファイルTANTONDX(審決注:「TANTONDX」は、2つのファイルをJOINコマンドでリンク(結合)する以前の一方のファイルの名前であるから、「TANLIST」の誤記と認める。)を作成します(図1.44)。」 (4) 50ページ図1.44 50ページ「図1.44 ファイルのリンク」には、以下の記載があると認められる。 「. .SELECT 1 .JOIN WITH URIAGE_T TO TANLIST FOR コード=URIAGE_T-＞担当コード FIELDS コード,担当者名,売上目標額,売上金額 6レコード結合されました」 (5) 50ページ12行-51ページ1行 「JOINコマンドとは2つのデータベースファイル内にある共通の内容を持つフィールドを捜し,1つのデータベースファイルを作成する強力なコマンドです。本例の処理を他のプログラム言語で行うと大変な作業になります。TANLISTファイルを開き,LISTコマンドで出力します(図1.45)。」 (6) 51ページ図1.45 51ページ「図1.45 2つのファイルがリンクされた」には、TANLISTファイルのリスト表示として、以下の記載があると認められる。 「.USE TANLIST .LIST レコード コード 担当者名 売上目標額 売上金額 1 1001 田中太郎 20000000 2100000 2 1002 山田一郎 15000000 1100000 3 1003 高橋啓介 10000000 4000000 4 1004 前田五郎 8000000 1000000 5 1005 大西紀久 6000000 3500000 6 1006 伊東静恵 3000000 2000000」 これらの記載から、引用例1には、次の発明(以下、「引用発明」という。)が記載されていると認められる。 「第1ファイル(TANTONDX)と第2ファイル(URIAGE_T)をJOINコマンドでリンク(結合)する方法であって、 JOINコマンドは、JOIN WITH URIAGE_T TO TANLIST FOR コード=URIAGE_T-＞担当コード FIELDS コード,担当者名,売上目標額,売上金額、であり、 TANTONDXのコードフィールドとURIAGE_Tの担当コードフィールドが同じ場合は、フィールド、コード、担当者名、売上目標額、売上金額で構成されるデータベースファイルTANLISTを作成し、 ここで、第2ファイル(URIAGE_T)には、「日付、担当コード、売上金額」の3つのフィールドと、各フィールドのデータがあり、 第1ファイル(TANTONDX)と第2ファイル(URIAGE_T)がJOINコマンドで結合されたファイル(TANLIST)には、「コード、担当者名、売上目標額、売上金額」の4つのフィールドと、各フィールドのデータがある、方法。」 B.引用例2(特開2001-34513号公報) 原査定の拒絶の理由で引用された特開2001-34513号公報(2001年2月9日公開。以下、「引用例2」という。)には、図面(特に図3を参照。)とともに、段落【0039】-【0040】に、次の事項が記載されている。 (7) 「次に、抽出データ受け渡し領域160に格納された属性名と属性値の組に対して、テーブルのカラムに格納すべきデータを作成する。図3においては、“注文番号”という属性名に対して“ORDERID”というカラム名が対応づけられており(1001)、その属性値が“O501001”なので、カラム名領域403にカラム名“ORDERID”を、カラム値領域404に属性値の“O501001”を組にして書き込んでいる(1005)。同様に、“個数”という属性名に対して“AMOUNT”というカラム名が対応づけられており(1002)、その属性値は“10”なので、カラム名領域403にカラム名“AMOUNT”を、カラム値領域404に属性値の“10”を組にして書き込んでいる(1006)。 次に、開きタグと閉じタグの間のテキストデータに対応して、カラムに格納すべきデータを作成する。図3においては、“注文明細”というタグの開きタグと閉じタグの間のテキストデータに対して “PRODNAME”というカラム名が対応づけられており(1003)、該当個所の構文データとして“電気冷蔵庫”という文字列が格納されているので、カラム名領域403にカラム名“PRODNAME”を、カラム値領域404に構文データの“電気冷蔵庫”を組にして書き込んでいる(1007)。」 C.周知例1(特開2001-43118号公報) 特開2001-43118号公報(2001年2月16日公開。以下、「周知例1」という。)には、図面(特に図4の「40」、「40a」(置換)、「40b」(追加)を参照。)とともに、次の事項が記載されている。 (8) 段落【0010】-【0011】 「更に、上述した2通りの方法のいずれにおいても、メタデータの変更や改訂をする場合には以下のような問題がある。すなわち、メタデータがすでに存在する場合に、新たにメタデータを登録しようとすると、過去のメタデータは自動的に上書きされてしまう。従って、既存のメタデータを残したければ、ユーザはまずこの既存のメタデータを取得し、このメタデータに対して追加更新するという手順が必要となる。 また、異なる言語(自然言語)でメタデータを持つ場合には、所望の言語に翻訳したメタデータを作成し、新たに追加するか置き換えなければならなかった。置き換えた場合には、以前のデータは失われてしまうし、追加した場合には、同じ内容が言語を変えて表示されてしまい、わずらわしいという問題点があった。」 (9) 段落【0050】-【0053】 「以上のメタデータの登録処理における、置換・追加・中止のそれぞれの処理の概要を図4に示す。例えば、既にメタデータが登録されたバイナリデータ40に対して、「置換」による新メタデータの登録が指示された場合には、メタデータ43を削除し(ステップS403)、新メタデータ44を最後尾に接続して(ステップS404)、新たなデータ40aを生成することになる。 また、「追加」による新メタデータ44の登録が指示された場合には、当該データの最後尾に新メタデータ44を登録し(ステップS404)、データ40bを生成する。また、「中止」が指示された場合は、新メタデータ44は接続されない。 以上のように、本実施形態のメタデータ登録処理によれば、図4に示されるように、バイナリデータ(ヘッダ41とデータ42からなる)の最後にXMLファイルで書かれた1つ又は複数のメタデータ(43或いは44)が接続される。 ・・・(中略)・・・ さらに、メタデータはXMLで記述されているため、このXMLデータ部分を抽出しておくことにより、XMLデータを理解するツールがあれば、メタデータの追加・変更・参照が可能であり、非常に汎用性に優れている。なお、XMLで記述されたメタデータ部分の抽出については第2の実施形態で詳しく説明する。」 D.周知例2(特開2001-22740号公報) 特開2001-22740号公報(2001年1月26日公開。以下、「周知例2」という。)には、図面(特に図2-図4を参照。)とともに、次の事項が記載されている。 (10) 段落【0015】-【0021】 「RTF文書1は、たとえば図2に示すような議事録であるが、技術レポート、論文等いかなる文書であってもよい。構造解析部2では、このRTF文書が入力されると(ファイルとして読み込まれると)その文書構造を解析して構造ファイル4を生成する。この構造解析は定義ファイル3を参照することによって行われる。ここで定義ファイル3は図3に示すように、書式とラベルとで構成されている。 ・・・(中略)・・・ また、同図中にアンダーラインを付した31aの場合、「^[1-9][.][^1-9]」は、書式部分である。ここで「^」はスペースを無視するという意味であり、この場合、左側にあるスペースを無視して1から9の数字があり、さらに「.」および数字が続く場合には、「連1.」という構造名であることを定義している。 同様に、図3の31bも、左側のスペースを無視して丸付き数字の後にスペースが続いている場合を「連○1(審決注:「○1」は丸数字1を表す。以下同様。)」と定義している。構造解析部2は入力されたRTF文書1をこの定義ファイル3を参照しながらパターンマッチングを行い、RTF文書1中の文字列が定義ファイル3の定義に該当した場合は当該文字列を構造要素として抽出する。 図2はRTF文書1から構造要素を抽出した例を示している。同図では「1.日 時:平成10年9月8日(火) 午後5時・・・・」の行が図3の定義ファイル3の31aに基づいて「連1.」という構造名割り当てられている。同様に、「2.場 所:3階大会議室」の行、「4.議 題:コンピュータ西暦2000年問題・・・」の行、「5.会議経過」の行が「連1.」として抽出されている。 また、「○1 最初に、△○内閣総理大臣・・・・」の行は定義ファイル3の31bに基づいて「連○1」の構造名が割り当てられている。同様に、「○2 ×○内閣内政審議室長から・・・」の行および「○3 引き続き・・・・」の行がそれぞれ「連○1」として抽出されている。」 (11) 段落【0026】-【0028】 「図4に示したように、構造ファイルの構造名(左分割画面42)と形式定義ファイル6のタグ名(右上分割画面43)とを対比表示させて、これをユーザーにマウス等を用いて関係付けさせることにより、両項目が関連付けられる。この作業は、たとえば、左分割画面42中の項目をマウスでクリックすることにより指定する。同図では、構造名の「本文要素」の「本文0001」が反転表示されて指定状態となっている。この状態で、マウスカーソル45を右上分割画面43に移動させて関連付けを行う形式定義ファイル6のタグ名にマウスカーソル45を合わせてクリックする。この作業により、RTF文書1から抽出された構造名「本文0001」とSGML文書の形式定義ファイルのタグ名「date」とが関連付けられる。 このようにして、全ての構造名とタグ名が関連付けられ、操作ボックス41の実行ボタンがマウスカーソルで指示されると、変換部8により文書形式の変換が開始される。この変換作業では、前記の関連付け作業7によって決定された対応関係に基づいて、元のRTF文書1に対してSGML準拠のタグが埋め込まれる。 このようにして、タグによるスタイル情報が付加されたSGML文書12が得られる。また、この変換部8では、かならずしもSGML文書12への変換作業のみを行うわけではなく、元のRTF文書1をそのまま維持して、これに関連付け作業7で得られたタグ名を元に、スタイル情報を付加し、スタイル情報付きRTF文書11を得るようにしてもよい。図5は、このようにして得られたスタイル情報の付加されたRTF文書11を汎用的のワードプロセッサソフトで表示した例である。同図では、本文画面51の左側にスタイル表示画面52が表示されており、ここに構造名が表示されるようになっている。」 3.対比 本願補正発明と引用発明とを対比する。 (1) 引用発明の第2ファイル(URIAGE_T)には、「日付」、「担当コード」、「売上金額」の3つのフィールドがある。 一方、第1ファイル(TANTONDX)と第2ファイル(URIAGE_T)とがJOINコマンドで結合されたファイル(TANLIST)には、「コード」、「担当者名」、「売上目標額」、「売上金額」の4つのフィールドがある。 よって、引用発明の第1ファイル(TANTONDX)には、JOINコマンドで結合されたファイル(TANLIST)の「コード、担当者名、売上目標額、売上金額」の4つのフィールドと各フィールドのデータのうち、第2ファイル(URIAGE_T)に含まれていないフィールド、すなわち、「コード」、「担当者名」、「売上目標額」の3つのフィールドと各フィールドのデータとが、少なくとも含まれると認められる。 引用発明の「第1ファイル(TANTONDX)」における、「コード」、「担当者名」、「売上目標額」の各フィールド内に含まれるデータは、全体として、本願補正発明の「データの集合」に相当するといえる。 引用発明の「第1ファイル(TANTONDX)」における、「コード」、「担当者名」、「売上目標額」の各フィールドは、各フィールドのデータについての説明を記述するデータであるから、本願補正発明の「該データに関連付けられた第1のメタデータ」に相当する。 引用発明のJOINコマンドの具体的なコマンド文は、「JOIN WITH URIAGE_T TO TANLIST FOR コード=URIAGE_T-＞担当コード FIELDS コード,担当者名,売上目標額,売上金額」であって、特にコマンド文の下線部を参照すると、第1ファイル(TANTONDX)の「コード」フィールドが指定されて、第1ファイル(TANTONDX)の「コード」フィールドと第2ファイル(URIAGE_T)の「担当コード」フィールドが同じである場合に、第1ファイル(「TANTONDX」)からの「コード、担当者名、売上目標額」の3つのフィールド及び各フィールドのデータに対して、第2ファイル(URIAGE_T)からの「売上金額」フィールド及び「売上金額」データを追加することによって、4つのフィールドからなる「TANLIST」ファイルが作成されていると認められる。 引用発明において追加される、第2ファイル(URIAGE_T)からの「売上金額」フィールド及び「売上金額」データは、本願発明において追加される「メタデータ」と、「情報」である点で共通するといえる。 引用発明において、第1ファイル(TANTONDX)と第2ファイル(URIAGE_T)をJOINコマンドでリンク(結合)する、JOINコマンドによる処理は、「コンピュータで実行する」ものと認められる。 よって、引用発明のJOINコマンドによって、第1ファイルに、第2ファイルをリンクする処理は、本願補正発明の「データの集合と、該データに関連付けられた第1のメタデータとに、メタデータを追加するための、コンピュータで実行する方法」と、「データの集合と、該データに関連付けられた第1のメタデータとに、情報を追加するための、コンピュータで実行する方法」である点で一致するといえる。 (2) 上記(1)記載のとおり、引用発明のJOINコマンドによって、第1ファイル(TANTONDX)の「コード」フィールドが指定されて、第2ファイル(URIAGE_T)の「担当コード」フィールドと同じであるかが判定されると認められる。 そして、第1ファイル(TANTONDX)の「コード」フィールドと、第2ファイル(URIAGE_T)の「担当コード」フィールドとが、同じであるかを判定するためには、比較を実行するために、第1ファイル(TANTONDX)からの、「コード」フィールドに含まれるデータが、識別され、抽出されていると認められる。 よって、JOINコマンドにおける、第1ファイル(TANTONDX)の「コード」フィールドの指定に基づいて、「TANTONDXのコードフィールドとURIAGE_Tの担当コードフィールドが同じ場合」を判定する引用発明は、本願補正発明の「前記第1のメタデータと、前記集合における前記データ及び/又は前記第1のメタデータの1以上の位置とに基づいて、前記集合中のデータを識別するステップ」と、「前記第1のメタデータに基づいて、前記集合中のデータを識別するステップ」の点で一致するステップを備えるといえる。 (3) 上記(1)記載のとおり、引用発明は、JOINコマンドによって、「TANTONDXのコードフィールドとURIAGE_Tの担当コードフィールドが同じ場合」を判定して、第1ファイル(「TANTONDX」)からの「コード、担当者名、売上目標額」の3つのフィールド及び各フィールドのデータに対して、第2ファイル(URIAGE_T)からの「売上金額」フィールド及び「売上金額」データを追加することによって、4つのフィールドからなる「TANLIST」ファイルが作成しているから、本願補正発明の「該識別されたデータに基づいて、前記集合に第2のメタデータを追加するステップであって、該第2のメタデータは前記識別されたデータに対応する1以上のラベルであることを特徴とするステップ」と、「該識別されたデータに基づいて、前記集合に情報を追加するステップ」である点で一致するステップを備えるといえる。 したがって、両者の一致点、相違点は以下のとおりである。 [一致点] 「データの集合と、該データに関連付けられた第1のメタデータとに、情報を追加するための、コンピュータで実行する方法であって、 前記第1のメタデータに基づいて、前記集合中のデータを識別するステップと、 該識別されたデータに基づいて、前記集合に情報を追加するステップと、 を具備することを特徴とする方法。」である点。 [相違点1] 本願補正発明は、「データの集合と、該データに関連付けられた第1のメタデータとに、メタデータを追加するための、コンピュータで実行する方法」であって「メタデータ」が追加されるのに対して、引用発明は、第1ファイル(「TANTONDX」)ファイルからの「コード、担当者名、売上目標額」の3つのフィールド及び各フィールドのデータに対して、追加される「情報」が、第2ファイル(URIAGE_T)からの「売上金額」フィールド及び「売上金額」データである点。 [相違点2] 本願補正発明は、「前記第1のメタデータと、前記集合における前記データ及び/又は前記第1のメタデータの1以上の位置とに基づいて、前記集合中のデータを識別するステップ」を含むのに対して、引用発明は、「TANTONDXのコードフィールドとURIAGE_Tの担当コードフィールドが同じ場合」を判定する過程において、JOINコマンドの「コード」フィールドの指定に基づいて、「コード」フィールドに含まれるデータを識別するものであって、第1のメタデータに加えて、データ及び/又は第1のメタデータの位置とに基づいて、データを識別するものではない点。 [相違点3] 本願補正発明は、「該識別されたデータに基づいて、前記集合に第2のメタデータを追加するステップであって、該第2のメタデータは前記識別されたデータに対応する1以上のラベルであることを特徴とするステップ」を含むのに対して、引用発明は、第1のファイルに追加する「情報」が、第2ファイル(URIAGE_T)からの「売上金額」フィールドと、「売上金額」データである点。 4.相違点についての判断 [相違点1、相違点3について] 一般に、データに付随する、データの説明を記述する「メタデータ」を、必要に応じて、変更したり、追加することは、周知技術である(上記2.B.「引用例2」の(7)において、属性名「注文番号」にカラム名「ORDERID」を対応付け、属性名「個数」にカラム名「AMOUNT」を対応付けると共に、(属性名を持たない)「電気冷蔵庫」データに、カラム名「PRODNAME」を対応づけている点を参照。上記2.C.「周知例1」の(8)、(9)、上記2.D.「周知例2」の(11)の、それぞれ、特に下線部の記載を参照。)。 また、データに付加するメタデータの種別として「ラベル」を用いる点は、普通に行われている(上記2.D.「周知例2」の(10)の、特に下線部の記載を参照。)。 また、引用発明は、第1ファイルの「コード」フィールドと、第2ファイルの「担当コード」フィールドが、JOINコマンドによる統合により「コード」フィールドに統合されるものであって、「担当コード」と「コード」という2つの異なるフィールド(本願発明の「メタデータ」に対応する。)を持つデータの集合について、「コード」という一方のフィールドのみを残すという、メタデータの修正をしていると認められる。 よって、メタデータの修正を行う引用発明において、データに付随する、データを説明する「メタデータ」を、必要に応じて、追加する周知技術を採用すると共に、この際、メタデータの種別として、「ラベル」を採用することによって、「データの集合と、該データに関連付けられた第1のメタデータとに、メタデータを追加するための、コンピュータで実行する方法」を備えるとともに、「該識別されたデータに基づいて、前記集合に第2のメタデータを追加するステップであって、該第2のメタデータは前記識別されたデータに対応する1以上のラベルであることを特徴とするステップ」を備える、相違点1及び相違点3に係る構成とすることは、当業者が容易に推考し得ることである。 [相違点2について] 一般に、データの集合に含まれる、特定のデータを識別するために、データの集合における、そのデータの「位置」や関連するメタデータの「位置」を利用することは、普通に行われている(上記2.B.「引用例2」の(7):「図3においては、“注文明細”というタグの開きタグと閉じタグの間のテキストデータに対して “PRODNAME”というカラム名が対応づけられており(1003)」の記載を参照。上記2.C.「周知例1」の(9):「当該データの最後尾に新メタデータ44を登録し」の記載を参照。上記2.D.「周知例2」の(10):「丸付き数字の後にスペースが続いている場合を「連○1」と定義している」の記載を参照。)。 よって、引用発明において、メタデータに基づくデータの識別に加えて、そのデータの「位置」や、そのデータに関連するメタデータの「位置」をも利用することによって、「前記第1のメタデータと、前記集合における前記データ及び/又は前記第1のメタデータの1以上の位置とに基づいて、前記集合中のデータを識別するステップ」を備える、相違点2に係る構成とすることは、当業者が容易に推考し得ることである。 そして、本願補正発明のように構成したことによる効果も引用発明及び各周知技術から予測できる程度のものである。 5.むすび 以上のとおり、本願補正発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 したがって、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。 第3 本願発明について 1.本願発明 平成22年7月23日付けの手続補正は上記のとおり却下されたので、本願の請求項1に係る発明(以下「本願発明」という。)は、平成21年3月9日付け手続補正書の特許請求の範囲の請求項1に記載された事項により特定される次のとおりのものである。 「データの集合と、該データに関連付けられた第1のメタデータとに、メタデータを追加するための、コンピュータで実行する方法であって、 前記第1のメタデータに基づく前記集合中のデータと、該データ及び/又は前記集合中の前記第1のメタデータの1以上の位置とを、識別するステップと、 該識別されたデータに基づいて、第2のメタデータを追加するステップと、 を具備することを特徴とする方法。」 2.引用例 引用例の記載については、上記「第2、2.引用例及び周知例」で述べたとおりである。 3.対比・判断 本願発明は、前記「第2」の「1.本願補正発明」で検討した本願補正発明の、「前記第1のメタデータに基づく前記集合中のデータと、該データ及び/又は前記集合中の前記第1のメタデータの1以上の位置とを、識別するステップ」とあったものを、「前記第1のメタデータと、前記集合における前記データ及び/又は前記第1のメタデータの1以上の位置とに基づいて、前記集合中のデータを識別するステップ」とする限定を省略し、「該識別されたデータに基づいて、第2のメタデータを追加するステップ」とあったものを、「該識別されたデータに基づいて、前記集合に第2のメタデータを追加するステップであって、該第2のメタデータは前記識別されたデータに対応する1以上のラベルであることを特徴とするステップ」とする限定を省略したものである。 そうすると、実質的に、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、上記「第2」の「4.相違点についての判断」に記載したとおり、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。 4.むすび 以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願は、特許法第29条第2項の規定により特許を受けることができない。 したがって、他の請求項について論及するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。 |
| 審理終結日 | 2012-07-24 |
| 結審通知日 | 2012-07-31 |
| 審決日 | 2012-08-13 |
| 出願番号 | 特願2003-521979(P2003-521979) |
| 審決分類 |
P
1
8・
575-
Z
(G06F)
P 1 8・ 121- Z (G06F) |
| 最終処分 | 不成立 |
| 前審関与審査官 | 松田 直也、原 秀人、上嶋 裕樹 |
| 特許庁審判長 |
大野 克人 |
| 特許庁審判官 |
稲葉 和生 山田 正文 |
| 発明の名称 | データにメタデータを加える方法 |
| 代理人 | 杉山 直人 |
| 代理人 | 白銀 博 |
| 代理人 | 山崎 行造 |
| 代理人 | 赤松 利昭 |