【事件の表示】
　特願２０１２−５３０１８４「統一リソース識別子（ＵＲＩ）による、アプリケーション状態情報の管理」拒絶査定不服審判事件〔平成２３年　３月３１日国際公開、ＷＯ２０１１／０３５９４４、平成２５年　２月２１日国内公表、特表２０１３−５０６１７５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，２０１０年７月９日（パリ条約による優先権主張外国庁受理２００９年９月２５日（以下，「優先日」という。），欧州特許庁）を国際出願日とする出願であって，平成２６年５月２７日付けの拒絶理由通知に対して平成２６年９月２日付けで意見書が提出されるとともに手続補正がなされたが，平成２６年１０月３１日付けで拒絶査定がなされ，これに対して平成２７年２月２０日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ，平成２７年５月８日付けで前置報告がなされ，平成２７年８月２８日付けで上申書が提出され，平成２８年３月１１日付けの当審の拒絶理由通知に対して，平成２８年６月８日付けで意見書が提出されるとともに手続補正がなされ，さらに，平成２８年９月２日付けの当審の拒絶理由通知（以下，「当審拒絶理由通知」という。）に対して，平成２８年１１月１８日付けで意見書が提出されるとともに手続補正がなされたものである。
２．本願発明
　本願の請求項８に係る発明（以下，「本願発明」という。）は，平成２８年１１月１８日付けの手続補正書により補正された特許請求の範囲の請求項８に記載された事項により特定される次のとおりのものである。
　
「コンピュータによって処理される，アプリケーション状態情報に関するコンピュータ・データ構造であって，前記データ構造は，コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子（ＵＲＩ）を含み，前記ＵＲＩは文字のストリングで表現され，前記ストリングは，アプリケーションの前記アプリケーション状態情報を，前記ＵＲＩ中のハッシュ文字で識別されるアンカー部分として定義される一つの第１のデータ配列と，前記アンカー部分を構成し，前記第１のデータ配列に入れ子になる一つ以上の第２のデータ配列と，前記アンカー部分を構成し，前記第２のデータ配列に入れ子になる一つ以上の第３のデータ配列とを有する入れ子状になった複数のデータ配列によって表現する，前記ＵＲＩ中のアンカー部分のサブストリングを含み，前記第２のデータ配列の各々は，前記入れ子状になった複数のデータ配列のうちの前記第１のデータ配列のエレメントであり，前記第３のデータ配列の各々は，前記入れ子状になった複数のデータ配列のうちの前記第２のデータ配列のエレメントである，構造。」
　
３．引用例
（１）引用例１に記載されている技術的事項及び引用発明
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，当審拒絶理由通知において引用された，米国特許出願公開第２００９／００１５５９９号明細書（２００９年１月１５日公開，以下，「引用例１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ａ　「[0016] 
FIG. 1  is a diagram illustrating a generic format of a Uniform Resource Identifier (URI). A URI generally is a compact sequence of characters that identifies an abstract or physical resource.
a hash character ‘#’
（当審仮訳：［００１６］
図１は，ユニフォームリソースアイデンティファイア（ＵＲＩ）の一般的なフォーマットを示す図である。ＵＲＩは，一般に，抽象的な，あるいは物理的なリソースを識別する簡潔な文字列である。
ハッシュ文字‘＃’
Ｂ　「[0017] 
FIG. 2  is a diagram illustrating one embodiment of a mechanism for identifying a state of an application. In one embodiment, this mechanism may take the form of a URI or Uniform Resource Locator (URL) with metadata embodying additional state information appended in the fragment identifier portion of the URI. 
The URI may also include a hierarchical component  220 , such as a domain name. The URI may also include a path  230  to further identify the resource location.
[0018] In this embodiment, while the mechanism may point to a location of an image, such that an image is displayed in a web browser, through the fragment component of the URI, the mechanism also may identify the state of an application which plays a video or multimedia file. 
The fragment component  240  may specify a namespace that is defined in a way to enable other applications to parse and process this mechanism. In this embodiment, the namespace may define a URL which has its own scheme, hierarchical component, path, and queries. The queries may serve to identify various aspects of the state of the video or multimedia file being executed on the video player application. In this embodiment, such aspects may include a video identifier, the current time elapsed of the video file being played, the size or resolution of the video file, whether the video file is currently being played or is paused or stopped, the identifier of the next video to be played, and the URL of the video file.
（当審仮訳：［００１７］
図２は，アプリケーションの状態を識別するためのメカニズムの１つの実施形態を示す図である。１つの実施形態では，このメカニズムは，ＵＲＩのフラグメント識別子部分に付加される追加の状態情報を具現化するメタデータを伴うＵＲＩあるいはユニフォームリソースロケータ（ＵＲＬ）の形をとるであろう。
ＵＲＩは，また，ドメイン名のような，階層的なコンポーネント２２０を含むであろう。ＵＲＩは，また，リソースの位置をさらに識別するためのパス２３０を含んでもよい。
［００１８］この実施形態では，メカニズムは，Ｗｅｂブラウザで表示されるような画像の場所をＵＲＩのフラグメントコンポーネントを通じて指し示すと同時に，メカニズムは，また，ビデオあるいはマルチメディアファイルを再生するアプリケーションの状態を識別するかもしれない。
フラグメントコンポーネント２４０は，他のアプリケーションがこのメカニズムを解析して処理することができるように定義される名前空間を明示するであろう。この実施形態では，名前空間は，それ自身のスキーム，階層的コンポーネント，パス，及びクエリを備えるＵＲＬを定義してもよい。クエリは，ビデオプレーヤーアプリケーションで実行されているビデオあるいはマルチメディアファイルの状態の様々な側面を識別するのに役立つであろう。この実施形態では，そのような側面は，ビデオの識別子，再生されているビデオファイルの現在の経過時間，ビデオファイルのサイズ又は解像度，ビデオファイルが現在再生されているか，一時停止されているか，あるいは停止されているか，再生する次のビデオの識別子，及びビデオファイルのＵＲＬを含むかもしれない。
Ｃ　「[0022]
Upon execution of the mechanism, the multimedia file may be played at the same state on a multimedia player on the recipient's computing device through the Internet messaging application's parsing of the application state information appended to the URI embedded within the mechanism.
the fragment component  240  of the URI includes a namespace defined in such a manner as to enable other applications to properly parse and process the application state information, the Internet messaging application may parse the metadata identifying application state information appended to the URI of the draggable mechanism
（当審仮訳：［００２２］
メカニズムが実行されると，マルチメディアファイルは，インターネットメッセージングアプリケーションがメカニズム内に埋め込まれたＵＲＩに付加されたアプリケーションの状態情報を解析することによって，受信者のコンピューティングデバイス上のマルチメディアプレーヤにおいて同じ状態で再生される
ＵＲＩのフラグメントコンポーネント２４０は，他のアプリケーションがアプリケーションの状態情報を適切に解析及び処理できるように定義された名前空間を含んでいる
インターネットメッセージングアプリケーションは，ドラッガブルメカニズムのＵＲＩに付加されたアプリケーションの状態情報を識別するメタデータを解析
Ｄ　「　
」
　ここで，上記引用例１に記載されている事項を検討する。
（ａ）上記Ｂの「図２は，アプリケーションの状態を識別するためのメカニズム・・・を示す図である。・・・このメカニズムは，ＵＲＩのフラグメント識別子部分に付加される追加の状態情報を具現化するメタデータを伴うＵＲＩ・・・の形をとるであろう。」旨の記載から，“アプリケーションの状態を識別するための”メカニズムにおいて使用される“ＵＲＩ”を読み取ることができるから，引用例１には，「アプリケーションの状態を識別するためのＵＲＩ」が記載されているものと認められる。
（ｂ）上記Ａの「図１は，ユニフォームリソースアイデンティファイア（ＵＲＩ）の一般的なフォーマットを示す図である。ＵＲＩは，一般に，抽象的な，あるいは物理的なリソースを識別する簡潔な文字列である。」旨の記載から，“ＵＲＩ”は，“リソースを識別する文字列”であることが読み取れる。
（ｃ）上記Ｂの「ＵＲＩは，また，ドメイン名のような，階層的なコンポーネント２２０を含むであろう。ＵＲＩは，また，リソースの位置をさらに識別するためのパス２３０を含んでもよい。」旨の記載，上記Ｂの「フラグメントコンポーネント２４０」との旨の記載，及び上記Ｄで引用した図２の記載から，“ＵＲＩ”は，“ドメイン名（２２０）”，“リソースの位置をさらに識別するためのパス（２３０）”，及び“フラグメントコンポーネント（２４０）”を“含む”ことが読み取れるから，引用例１には，「ＵＲＩは，ドメイン名（２２０），リソースの位置をさらに識別するためのパス（２３０），及びフラグメントコンポーネント（２４０）を含む」ことが記載されているものと認められる。
（ｄ）上記Ａの「ハッシュ文字‘＃’」との旨の記載，及び上記Ｄで引用した図２の記載から，パス（２３０）と“フラグメントコンポーネント（２４０）”とは，“ハッシュ文字‘＃’”で区切られており，“フラグメントコンポーネント（２４０）”は，“ハッシュ文字‘＃’”で“識別され”ているといえる。
　また，上記Ｃの「ＵＲＩのフラグメントコンポーネント２４０は，他のアプリケーションがアプリケーションの状態情報を適切に解析及び処理できるように定義された名前空間を含んでいる」旨の記載，同じく上記Ｃの「インターネットメッセージングアプリケーションは，ドラッガブルメカニズムのＵＲＩに付加されたアプリケーションの状態情報を識別するメタデータを解析」する旨の記載から，“フラグメントコンポーネント（２４０）”は，“アプリケーションの状態情報”を“識別する”“メタデータ”を有することが読み取れる。
　また，上記Ｂの「フラグメントコンポーネント２４０は，・・・名前空間を明示する・・・。・・・名前空間は，・・・クエリを備える・・・。クエリは，・・・ビデオあるいはマルチメディアファイルの状態の様々な側面を識別する・・・。・・・そのような側面は，ビデオの識別子，再生されているビデオファイルの現在の経過時間，ビデオファイルのサイズ又は解像度，ビデオファイルが現在再生されているか，一時停止されているか，あるいは停止されているか，再生する次のビデオの識別子，及びビデオファイルのＵＲＬを含む」旨の記載，及び上記Ｄで引用した図２の“フラグメントコンポーネント（２４０）”の部分の「vid=121220time=70vidsize=320x240state=playingnextvid=121300mediaurl=http://domain.com/videos/video121220.flv」との記載から，“フラグメントコンポーネント（２４０）”の“メタデータ”が，“ビデオの識別子，再生されているビデオファイルの現在の経過時間，ビデオファイルのサイズ又は解像度，ビデオファイルが現在再生されているか，一時停止されているか，あるいは停止されているか，再生する次のビデオの識別子，及びビデオファイルのＵＲＬ”などの“複数のデータ”を“含”むことが読み取れる。
　してみれば，引用例１には，「ハッシュ文字‘＃’で識別されるフラグメントコンポーネント（２４０）は，アプリケーションの状態情報を識別する複数のデータを含むメタデータを有する」ことが記載されているものと認められる。
（ｅ）上記Ｃの「メカニズムが実行されると，マルチメディアファイルは，インターネットメッセージングアプリケーションがメカニズム内に埋め込まれたＵＲＩに付加されたアプリケーションの状態情報を解析することによって，受信者のコンピューティングデバイス上のマルチメディアプレーヤで同じ状態で再生される」旨の記載から，“インターネットメッセージングアプリケーション”は，“ＵＲＩに付加されたアプリケーションの状態情報を解析する”ことが読み取れ，また，“インターネットメッセージングアプリケーション”は，受信者の“コンピューティングデバイス上”で“動作”しているものと解されることから，引用例１には「コンピューティングデバイス上で動作するインターネットメッセージングアプリケーションは，ＵＲＩに付加されたアプリケーションの状態情報を解析する」ことが記載されているものと認められる。
　以上の（ａ）〜（ｅ）の検討から，引用例１には，次のとおりの発明（以下，「引用発明」という。）が記載されていると認められる。
「アプリケーションの状態を識別するためのＵＲＩであって，
　前記ＵＲＩは，リソースを識別する文字列であり，
　前記ＵＲＩは，ドメイン名（２２０），リソースの位置をさらに識別するためのパス（２３０），及びフラグメントコンポーネント（２４０）を含み，
　ハッシュ文字‘＃’で識別されるフラグメントコンポーネント（２４０）は，アプリケーションの状態情報を識別する複数のデータを含むメタデータを有し，
　コンピューティングデバイス上で動作するインターネットメッセージングアプリケーションは，ＵＲＩに付加されたアプリケーションの状態情報を解析する。」
（２）引用例２に記載されている技術的事項
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，当審拒絶理由通知において引用された，特表２００７−５２５７４５号公報（２００７年９月６日公表，以下，「引用例２」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｅ　「【請求項１】
  ネットワークに接続された各々のクライアント上で動いている複数の異種のユーザーアプリケーションを用いてデザインを操作するために該ネットワーク上でコラボレーションする，コンピューターによる方法であって，該方法は：
  コラボレーションセッションに参加するために，該ネットワーク上でセッションクライアントプロセスをセッションマネージャーに接続する工程；
  該セッションマネージャーに接続された他のセッションクライアントプロセスとセッションコントロールメッセージを共有する工程；
  該デザインを表すデザインデータを該クライアント上で動いているローカルアプリケーションへロードする工程；
  
該ローカルアプリケーションの少なくとも１つの状態を表す少なくとも１つのアプリケーション状態ファイルを
作成する
  少なくとも１つのアプリケーション状態ファイルを該セッションマネージャーを介して該セッションクライアントプロセスから該他のセッションクライアントプロセスへ通信する工程；および
  他のローカルアプリケーションによって作成され，該セッションマネージャーを介して該他のセッションクライアントから通信された少なくとも１つのアプリケーション状態ファイルをロードする工程；
を包含する，方法。
【請求項２】
  請求項１に記載の方法であって，
前記少なくとも１つのアプリケーション状態が，少なくとも１つのアプリケーション状態ファイルを作成するために，規格化されたＸＭＬ構造を用いてコード化され，該少なくとも１つのアプリケーション状態ファイルがＸＭＬメッセージとして通信される
Ｆ　「【００１５】
  
アプリケーション状態は，好ましくは，内蔵インタープリターを介して様々なアプリケーションによる使用のためにデザインされ規格化されたＸＭＬ構造のセットでコード化される。
ＸＭＬフォーマットでのアプリケーション状態ファイルの一例は，図６に示される。
Ｇ　「　
」
　ここで，上記引用例２に記載されている事項を検討する。
（ａ）上記Ｅの「該ローカルアプリケーションの少なくとも１つの状態を表す少なくとも１つのアプリケーション状態ファイルを・・・作成する」との記載，同じく上記Ｅの「前記少なくとも１つのアプリケーション状態が，少なくとも１つのアプリケーション状態ファイルを作成するために，規格化されたＸＭＬ構造を用いてコード化され，該少なくとも１つのアプリケーション状態ファイルがＸＭＬメッセージとして通信される」との記載，及び上記Ｆの「アプリケーション状態は，好ましくは，内蔵インタープリターを介して様々なアプリケーションによる使用のためにデザインされ規格化されたＸＭＬ構造のセットでコード化される。」との記載から，引用例２には，「アプリケーションの状態を表すアプリケーション状態ファイルをＸＭＬ構造を用いてコード化する」との事項（以下，「引用例２記載事項Ａ」という。）が記載されているものと認められる。
（ｂ）また，上記Ｆの「ＸＭＬフォーマットでのアプリケーション状態ファイルの一例は，図６に示される。」との記載，及び上記Ｇで引用した図６の記載から，引用例２には，「ＸＭＬフォーマットでのアプリケーション状態ファイルは，InterComm_Macroと/InterComm_Macroで囲まれたInterComm_Macro要素の中にMacro_defineと/Macro_defineで囲まれたMacro_define要素が入れ子状に配置され，Macro_define要素の中に，Doと/Doで囲まれたDo要素が入れ子状に配置され，さらに，Do要素の中に，Unitsと/Unitsで囲まれたUnits要素，Visibility要素やWindow要素などを含む多数の要素が入れ子状に配置されている。」との事項（以下，「引用例２記載事項Ｂ」という。）が記載されているものと認められる。
（３）引用例３に記載されている技術的事項
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり，当審拒絶理由通知において引用された，「中鉢　欣秀　外２名，状態機械を用いるフレームワーク記述言語ＦｗＭＬの設計とＭＶＣアプリケーションへの適用，社団法人情報処理学会，２００３年１２月１５日，第４４巻，Ｎｏ．ＳＩＧ１６（ＰＲＯ２０），１〜１４頁」（以下，「引用例３」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｈ　「
ソフトウェアの実行時状態をＸＭＬで表現し
Ｉ　「本研究では，前節の課題点をふまえ，（１）
アプリケーションの実行時状態の表現にＸＭＬを用いる
Ｊ  「
「ＳｔａｔｅＭｏｄｅｌ」は，ＦｗＭＬ−ＳＭ仕様に基づいたＸＭＬで表現されたデータであり，実行時状態を格納する
Ｋ　「これらを３．２．１項で用意したプラグポイントに接続することで，ＳｔａｔｅＭｏｄｅｌの全体が定義される．
図９に住所録で使用するＳｔａｔｅＭｏｄｅｌの例を示す
Ｌ　「　
」
　ここで，上記引用例３に記載されている事項を検討する。
（ａ）上記Ｈの「ソフトウェアの実行時状態をＸＭＬで表現し」との記載，上記Ｉの「アプリケーションの実行時状態の表現にＸＭＬを用いる」との記載，上記Ｊの「「ＳｔａｔｅＭｏｄｅｌ」は，ＦｗＭＬ−ＳＭ仕様に基づいたＸＭＬで表現されたデータであり，実行時状態を格納する」との記載から，引用例３には，「アプリケーションの実行時状態をＸＭＬを用いて表現する」との事項（以下，「引用例３記載事項Ａ」という。）が記載されているものと認められる。
（ｂ）また，上記Ｊの「「ＳｔａｔｅＭｏｄｅｌ」は，ＦｗＭＬ−ＳＭ仕様に基づいたＸＭＬで表現されたデータであり，実行時状態を格納する」との記載，上記Ｋの「図９に住所録で使用するＳｔａｔｅＭｏｄｅｌの例を示す」との記載，及び上記Ｌで引用した図９の記載から，引用例３には，「ＸＭＬで表現され，実行時状態を格納するＳｔａｔｅＭｏｄｅｌは，StartModelと/StartModelで囲まれたStartModel要素の中にModelと/Modelで囲まれたModel要素が入れ子状に配置され，Model要素の中に，Recordと/Recordで囲まれた２つのRecord要素が入れ子状に配置され，さらに，各Record要素の中に，Jnameと/Jnameで囲まれたJname要素，Knameと/Knameで囲まれたKname要素などを含む多数の要素が入れ子状に配置されている。」との事項（以下，「引用例３記載事項Ｂ」という。）が記載されているものと認められる。
（４）参考文献１に記載されている技術的事項
　本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった，「吉濱　佐知子　外２名，Ｗｅｂ２．０アプリケーションにおける代表的な攻撃手法とその対策，情報処理，社団法人情報処理学会，２００９年０１月１５日，第５０巻，第１号，ｐ．４４〜５４」（以下，「参考文献１」という。）には，関連する図面とともに，以下の技術的事項が記載されている。（当審注：下線は，参考のために当審で付与したものである。）
Ｍ　「・・・
一般的にブラウザはＵＲＬのフラグメント識別子以降はサーバに送信せずにブラウザ内でのみ処理する
４．対比
　本願発明と引用発明とを対比する。
（ａ）引用発明の「ＵＲＩ」が本願発明「コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子（ＵＲＩ）」に相当する。また，引用発明の「アプリケーションの状態情報」が本願発明の「アプリケーション状態情報」に相当する。
　引用発明の「ＵＲＩ」は，“ドメイン名（２２０）”，“パス（２３０）”，及び“フラグメントコンポーネント（２４０）”などを含み，これらの“データ”が，所定の順序で結合された“構造”を有しているから，引用発明の「ＵＲＩ」は，“データ構造”に“含まれる”ものであると言える。
　また，引用発明の「ＵＲＩ」は，それに“付加されたアプリケーションの状態情報”が，“コンピューティングデバイス上で動作するインターネットメッセージングアプリケーション”によって解析されるものであるから，引用発明の「ＵＲＩ」は，「コンピュータによって処理される」ものであり，「アプリケーション状態情報に関する」ものであり，かつ，「コンピュータ・データ構造」であるということができる。
　そうすると，引用発明と本願発明とは，「コンピュータによって処理される，アプリケーション状態情報に関するコンピュータ・データ構造であって，前記データ構造は，コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子（ＵＲＩ）を含み」との点で一致する。
（ｂ）引用発明の「ＵＲＩ」は，“リソースを識別する文字列であ”り，この「文字列」が，本願発明の「文字のストリング」に相当するから，引用発明の「ＵＲＩ」は，“文字のストリングで表現され”ているということができる。
（ｃ）
（ｃ−１）引用発明の「ハッシュ文字‘＃’」は，“ＵＲＩ中”のものであるから，本願発明の「ＵＲＩ中のハッシュ文字」に相当する。
　引用発明の「フラグメントコンポーネント（２４０）」は，ＵＲＩ中で，「ハッシュ文字‘＃’」によって区切られて識別される“部分”であり，この“部分”が“アンカー”とも呼ばれることは，ＵＲＩの表記における常識であるから，引用発明の「フラグメントコンポーネント（２４０）」が本願発明の「アンカー部分」に対応する。
　また，引用発明の「フラグメントコンポーネント（２４０）」は，ＵＲＩのデータ構造において，「ハッシュ文字‘＃’」で区切られた“部分”として“定義される”ものである。
　引用発明の「フラグメントコンポーネント（２４０）」は，“アプリケーションの状態情報を識別する複数のデータを含むメタデータを有し”ており，当該メタデータは，“複数のデータ”を“配列”したものと言えるから，引用発明の“メタデータ”を有する“フラグメントコンポーネント（２４０）”が本願発明の「データ配列」に相当する。
　以上の検討から，引用発明の「ハッシュ文字‘＃’で識別されるフラグメントコンポーネント（２４０）」と本願発明の「ＵＲＩ中のハッシュ文字で識別されるアンカー部分として定義される一つの第１のデータ配列」とは，「ＵＲＩ中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列」である点で共通する。
（ｃ−２）引用発明の「フラグメントコンポーネント（２４０）」は“アプリケーションの状態情報を識別する複数のデータを含むメタデータを有し”ており，このメタデータによって，“アプリケーションの状態情報”を“表現する”ものである。
　また，「フラグメントコンポーネント（２４０）」は，「ＵＲＩ」の一部であるから，上記（ｂ）の検討を踏まえると，“ＵＲＩ”の“ストリング”の一部を構成する“サブストリング”であり，上記（ｃ−１）の検討も踏まえると，本願発明の「ＵＲＩ中のアンカー部分のサブストリング」に対応するものである。
（ｃ−３）上記（ｃ−１）及び（ｃ−２）の検討から，引用発明の「ＵＲＩ」（ストリング）は，“アプリケーションのアプリケーション状態情報”を“ＵＲＩ中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列”によって“表現する”，“ＵＲＩ中のアンカー部分のサブストリング”を“含む”ものであるということができる。
　してみれば，引用発明と本願発明とは，「ストリングは，アプリケーションのアプリケーション状態情報を，ＵＲＩ中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列によって表現する，前記ＵＲＩ中のアンカー部分のサブストリングを含」む点で一致する。
　そうすると，本願発明と引用発明とは，
　
「コンピュータによって処理される，アプリケーション状態情報に関するコンピュータ・データ構造であって，前記データ構造は，コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子（ＵＲＩ）を含み，前記ＵＲＩは文字のストリングで表現され，前記ストリングは，アプリケーションの前記アプリケーション状態情報を，前記ＵＲＩ中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列によって表現する，前記ＵＲＩ中のアンカー部分のサブストリングを含む，構造。」
　
　の点で一致し，次の点で相違する。
　
［相違点１］
　アプリケーション状態情報を表現するデータ配列が，本願発明では，「一つの第１のデータ配列と，前記アンカー部分を構成し，前記第１のデータ配列に入れ子になる一つ以上の第２のデータ配列と，前記アンカー部分を構成し，前記第２のデータ配列に入れ子になる一つ以上の第３のデータ配列とを有する入れ子状になった複数のデータ配列」であり，かつ，「前記第２のデータ配列の各々は，前記入れ子状になった複数のデータ配列のうちの前記第１のデータ配列のエレメントであり，前記第３のデータ配列の各々は，前記入れ子状になった複数のデータ配列のうちの前記第２のデータ配列のエレメントである」のに対して，引用発明では，そのように特定されていない点。
５．当審の判断
　上記相違点について検討する。
　
［相違点１］について
　引用例２には，「アプリケーションの状態を表すアプリケーション状態ファイルをＸＭＬ構造を用いてコード化する」との事項（引用例２記載事項Ａ）が記載されており，また，引用例３には，「アプリケーションの実行時状態をＸＭＬを用いて表現する」との事項（引用例３記載事項Ａ）が記載されていることからみて，「アプリケーションの状態をＸＭＬを用いて表現すること」は，本願の優先日前に，当該技術分野における周知技術であったものと認められる。
　また，引用例２に，「ＸＭＬフォーマットでのアプリケーション状態ファイルは，InterComm_Macroと/InterComm_Macroで囲まれたInterComm_Macro要素の中にMacro_defineと/Macro_defineで囲まれたMacro_define要素が入れ子状に配置され，Macro_define要素の中に，Doと/Doで囲まれたDo要素が入れ子状に配置され，さらに，Do要素の中に，Unitsと/Unitsで囲まれたUnits要素，Visibility要素やWindow要素などを含む多数の要素が入れ子状に配置されている。」との事項（引用例２記載事項Ｂ）が記載され，引用例３に，「ＸＭＬで表現され，実行時状態を格納するＳｔａｔｅＭｏｄｅｌは，StartModelと/StartModelで囲まれたStartModel要素の中にModelと/Modelで囲まれたModel要素が入れ子状に配置され，Model要素の中に，Recordと/Recordで囲まれた２つのRecord要素が入れ子状に配置され，さらに，各Record要素の中に，Jnameと/Jnameで囲まれたJname要素，Knameと/Knameで囲まれたKname要素などを含む多数の要素が入れ子状に配置されている。」との事項（引用例３記載事項Ｂ）が記載されているように，ＸＭＬでは，データに含まれる各要素（親要素）が，入れ子状に複数の子要素を有することができ，子要素が更に入れ子状に複数の孫要素を有するようにすることができることが技術常識である。
　そして，ＲＦＣには，ＵＲＩのフラグメント部分に入れる情報について特に指定がないことから，この部分にどのような情報を入れるかは任意であり，また，ＵＲＩのフラグメント部分は，上記参考文献１（上記Ｍの記載を参照）に記載されているように，ブラウザで処理されるものであることからすれば，この部分にブラウザで処理するＸＭＬ構造の情報を入れるように構成することに格別の困難性はない。
　してみれば，引用発明のＵＲＩにおいて，アプリケーションの状態情報を表現する際に，上記周知技術を適用して，アプリケーションの状態情報を識別するメタデータをＸＭＬを用いて表現するようにし，その際，ＸＭＬの入れ子の構造を用いることによって，アンカー部分として定義されるデータ配列を，
　(1)一つの第１のデータ配列と，
　(2)アンカー部分を構成し，前記第１のデータ配列に入れ子になる一つ以上の第２のデータ配列と，
　(3)前記アンカー部分を構成し，前記第２のデータ配列に入れ子になる一つ以上の第３のデータ配列と
を有する入れ子状になった複数のデータ配列となるように構成するとともに，
　(4)前記第２のデータ配列の各々が，前記入れ子状になった複数のデータ配列のうちの前記第１のデータ配列のエレメントであり，
　(5)前記第３のデータ配列の各々が，前記入れ子状になった複数のデータ配列のうちの前記第２のデータ配列のエレメントであるように構成すること，
　すなわち，上記相違点１に係る構成とすることは，当業者が容易に想到し得たことである。
　そして，本願発明の作用効果も，引用発明及び周知技術から当業者が予測できる範囲のものである。
　
　したがって，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
６．むすび 
　以上のとおり，本願発明は，引用発明及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　したがって，本願は他の請求項について検討するまでもなく拒絶されるべきものである。
　よって，結論のとおり審決する。