• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1329812
審判番号 不服2015-3296  
総通号数 212 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2017-08-25 
種別 拒絶査定不服の審決 
審判請求日 2015-02-20 
確定日 2017-06-28 
事件の表示 特願2012-530184「統一リソース識別子(URI)による、アプリケーション状態情報の管理」拒絶査定不服審判事件〔平成23年 3月31日国際公開、WO2011/035944、平成25年 2月21日国内公表、特表2013-506175〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯
本願は,2010年7月9日(パリ条約による優先権主張外国庁受理2009年9月25日(以下,「優先日」という。),欧州特許庁)を国際出願日とする出願であって,平成26年5月27日付けの拒絶理由通知に対して平成26年9月2日付けで意見書が提出されるとともに手続補正がなされたが,平成26年10月31日付けで拒絶査定がなされ,これに対して平成27年2月20日に拒絶査定不服審判の請求がなされるとともに手続補正がなされ,平成27年5月8日付けで前置報告がなされ,平成27年8月28日付けで上申書が提出され,平成28年3月11日付けの当審の拒絶理由通知に対して,平成28年6月8日付けで意見書が提出されるとともに手続補正がなされ,さらに,平成28年9月2日付けの当審の拒絶理由通知(以下,「当審拒絶理由通知」という。)に対して,平成28年11月18日付けで意見書が提出されるとともに手続補正がなされたものである。

2.本願発明
本願の請求項8に係る発明(以下,「本願発明」という。)は,平成28年11月18日付けの手続補正書により補正された特許請求の範囲の請求項8に記載された事項により特定される次のとおりのものである。

「コンピュータによって処理される,アプリケーション状態情報に関するコンピュータ・データ構造であって,前記データ構造は,コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子(URI)を含み,前記URIは文字のストリングで表現され,前記ストリングは,アプリケーションの前記アプリケーション状態情報を,前記URI中のハッシュ文字で識別されるアンカー部分として定義される一つの第1のデータ配列と,前記アンカー部分を構成し,前記第1のデータ配列に入れ子になる一つ以上の第2のデータ配列と,前記アンカー部分を構成し,前記第2のデータ配列に入れ子になる一つ以上の第3のデータ配列とを有する入れ子状になった複数のデータ配列によって表現する,前記URI中のアンカー部分のサブストリングを含み,前記第2のデータ配列の各々は,前記入れ子状になった複数のデータ配列のうちの前記第1のデータ配列のエレメントであり,前記第3のデータ配列の各々は,前記入れ子状になった複数のデータ配列のうちの前記第2のデータ配列のエレメントである,構造。」

3.引用例
(1)引用例1に記載されている技術的事項及び引用発明
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審拒絶理由通知において引用された,米国特許出願公開第2009/0015599号明細書(2009年1月15日公開,以下,「引用例1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

A 「[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. ・・・ The hierarchical part is typically delimited from the scheme name by a double slash “//” and is terminated by either a single slash ‘/’, a question mark ‘?’, or a hash character ‘#’. ・・・」
(当審仮訳:[0016]図1は,ユニフォームリソースアイデンティファイア(URI)の一般的なフォーマットを示す図である。URIは,一般に,抽象的な,あるいは物理的なリソースを識別する簡潔な文字列である。・・・階層的な部分は,典型的には二重スラッシュ“//”によってスキーム名と区切られ,そして,単一スラッシュ‘/’,クエスチョンマーク‘?’,あるいはハッシュ文字‘#’のいずれかによって終了させられる。・・・)

B 「[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. A URL is a subset of a URI in which the URL not only identifies a resource, but also provides a location for the resource, e.g., a network location of the resource. The URI may include a scheme name 210 , which, in this embodiment, is the http scheme used for, among other things, publishing and retrieving html documents. 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. In the context of this embodiment, the scheme name 210 , hierarchical component 220 , and path component 230 may identify an image of the JPG format.
[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. Those of skill in the art should recognize that the various characteristics of the state of an application are not limited to these aforementioned characteristics, and that metadata embodying the characteristics or properties disclosed in the query component of the fragment component are entirely exemplary. Those of skill in the art should also recognize that the properties used to identify or describe a state of an application may vary and depend on the type of application. The type of application is not limited to a video or a multimedia application, but could be any application that can have different states at different times, and thus is amenable to the approach of the present invention.」
(当審仮訳:[0017]図2は,アプリケーションの状態を識別するためのメカニズムの1つの実施形態を示す図である。1つの実施形態では,このメカニズムは,URIのフラグメント識別子部分に付加される追加の状態情報を具現化するメタデータを伴うURIあるいはユニフォームリソースロケータ(URL)の形をとるであろう。URLは,URIのサブセットであり,URLはリソースを識別するだけでなく,リソースの位置,例えば,リソースのネットワーク位置も提供する。URIは,スキーム名210を含み,それは,この実施形態では,htmlドキュメントの公開,及び検索に特に使われるhttpスキームである。URIは,また,ドメイン名のような,階層的なコンポーネント220を含むであろう。URIは,また,リソースの位置をさらに識別するためのパス230を含んでもよい。この実施形態の文脈では,スキーム名210,階層的なコンポーネント220,及びパスコンポーネント230が JPGフォーマットの画像を識別するであろう。
[0018]この実施形態では,メカニズムは,Webブラウザで表示されるような画像の場所をURIのフラグメントコンポーネントを通じて指し示すと同時に,メカニズムは,また,ビデオあるいはマルチメディアファイルを再生するアプリケーションの状態を識別するかもしれない。フラグメントコンポーネント240は,他のアプリケーションがこのメカニズムを解析して処理することができるように定義される名前空間を明示するであろう。この実施形態では,名前空間は,それ自身のスキーム,階層的コンポーネント,パス,及びクエリを備えるURLを定義してもよい。クエリは,ビデオプレーヤーアプリケーションで実行されているビデオあるいはマルチメディアファイルの状態の様々な側面を識別するのに役立つであろう。この実施形態では,そのような側面は,ビデオの識別子,再生されているビデオファイルの現在の経過時間,ビデオファイルのサイズ又は解像度,ビデオファイルが現在再生されているか,一時停止されているか,あるいは停止されているか,再生する次のビデオの識別子,及びビデオファイルのURLを含むかもしれない。当業者は,アプリケーションの状態の様々な特徴が,前述の特徴に限定されないこと,そして,フラグメントコンポーネントのクエリコンポーネントで開示される特徴あるいは特性を具現化するメタデータが,すべて例示であることを認識するべきである。当業者はまた,アプリケーションの状態を識別あるいは記述するために使われる特性が,アプリケーションの型に依存して変化するかもしれないことを認識するべきである。アプリケーションのタイプは,ビデオあるいはマルチメディアアプリケーションに限られず,異なった時間に異なった状態を有し得,そしてそのために現在の発明のアプローチに従う任意のアプリケーションであり得る。)

C 「[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. Because 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 and launch the application needed to play or execute the video identified by the URL within the appended application state information.」
(当審仮訳:[0022]メカニズムが実行されると,マルチメディアファイルは,インターネットメッセージングアプリケーションがメカニズム内に埋め込まれたURIに付加されたアプリケーションの状態情報を解析することによって,受信者のコンピューティングデバイス上のマルチメディアプレーヤにおいて同じ状態で再生されるであろう。URIのフラグメントコンポーネント240は,他のアプリケーションがアプリケーションの状態情報を適切に解析及び処理できるように定義された名前空間を含んでいるので,インターネットメッセージングアプリケーションは,ドラッガブルメカニズムのURIに付加されたアプリケーションの状態情報を識別するメタデータを解析して,付加されたアプリケーションの状態情報内のURLによって識別されるビデオを再生,あるいは実行するために必要なアプリケーションを開始するであろう。)

D 「



ここで,上記引用例1に記載されている事項を検討する。

(a)上記Bの「図2は,アプリケーションの状態を識別するためのメカニズム・・・を示す図である。・・・このメカニズムは,URIのフラグメント識別子部分に付加される追加の状態情報を具現化するメタデータを伴うURI・・・の形をとるであろう。」旨の記載から,“アプリケーションの状態を識別するための”メカニズムにおいて使用される“URI”を読み取ることができるから,引用例1には,「アプリケーションの状態を識別するためのURI」が記載されているものと認められる。

(b)上記Aの「図1は,ユニフォームリソースアイデンティファイア(URI)の一般的なフォーマットを示す図である。URIは,一般に,抽象的な,あるいは物理的なリソースを識別する簡潔な文字列である。」旨の記載から,“URI”は,“リソースを識別する文字列”であることが読み取れる。

(c)上記Bの「URIは,また,ドメイン名のような,階層的なコンポーネント220を含むであろう。URIは,また,リソースの位置をさらに識別するためのパス230を含んでもよい。」旨の記載,上記Bの「フラグメントコンポーネント240」との旨の記載,及び上記Dで引用した図2の記載から,“URI”は,“ドメイン名(220)”,“リソースの位置をさらに識別するためのパス(230)”,及び“フラグメントコンポーネント(240)”を“含む”ことが読み取れるから,引用例1には,「URIは,ドメイン名(220),リソースの位置をさらに識別するためのパス(230),及びフラグメントコンポーネント(240)を含む」ことが記載されているものと認められる。

(d)上記Aの「ハッシュ文字‘#’」との旨の記載,及び上記Dで引用した図2の記載から,パス(230)と“フラグメントコンポーネント(240)”とは,“ハッシュ文字‘#’”で区切られており,“フラグメントコンポーネント(240)”は,“ハッシュ文字‘#’”で“識別され”ているといえる。
また,上記Cの「URIのフラグメントコンポーネント240は,他のアプリケーションがアプリケーションの状態情報を適切に解析及び処理できるように定義された名前空間を含んでいる」旨の記載,同じく上記Cの「インターネットメッセージングアプリケーションは,ドラッガブルメカニズムのURIに付加されたアプリケーションの状態情報を識別するメタデータを解析」する旨の記載から,“フラグメントコンポーネント(240)”は,“アプリケーションの状態情報”を“識別する”“メタデータ”を有することが読み取れる。
また,上記Bの「フラグメントコンポーネント240は,・・・名前空間を明示する・・・。・・・名前空間は,・・・クエリを備える・・・。クエリは,・・・ビデオあるいはマルチメディアファイルの状態の様々な側面を識別する・・・。・・・そのような側面は,ビデオの識別子,再生されているビデオファイルの現在の経過時間,ビデオファイルのサイズ又は解像度,ビデオファイルが現在再生されているか,一時停止されているか,あるいは停止されているか,再生する次のビデオの識別子,及びビデオファイルのURLを含む」旨の記載,及び上記Dで引用した図2の“フラグメントコンポーネント(240)”の部分の「vid=121220&time=70&vidsize=320x240&state=playing&nextvid=121300&mediaurl=http://domain.com/videos/video121220.flv」との記載から,“フラグメントコンポーネント(240)”の“メタデータ”が,“ビデオの識別子,再生されているビデオファイルの現在の経過時間,ビデオファイルのサイズ又は解像度,ビデオファイルが現在再生されているか,一時停止されているか,あるいは停止されているか,再生する次のビデオの識別子,及びビデオファイルのURL”などの“複数のデータ”を“含”むことが読み取れる。
してみれば,引用例1には,「ハッシュ文字‘#’で識別されるフラグメントコンポーネント(240)は,アプリケーションの状態情報を識別する複数のデータを含むメタデータを有する」ことが記載されているものと認められる。

(e)上記Cの「メカニズムが実行されると,マルチメディアファイルは,インターネットメッセージングアプリケーションがメカニズム内に埋め込まれたURIに付加されたアプリケーションの状態情報を解析することによって,受信者のコンピューティングデバイス上のマルチメディアプレーヤで同じ状態で再生される」旨の記載から,“インターネットメッセージングアプリケーション”は,“URIに付加されたアプリケーションの状態情報を解析する”ことが読み取れ,また,“インターネットメッセージングアプリケーション”は,受信者の“コンピューティングデバイス上”で“動作”しているものと解されることから,引用例1には「コンピューティングデバイス上で動作するインターネットメッセージングアプリケーションは,URIに付加されたアプリケーションの状態情報を解析する」ことが記載されているものと認められる。

以上の(a)?(e)の検討から,引用例1には,次のとおりの発明(以下,「引用発明」という。)が記載されていると認められる。

「アプリケーションの状態を識別するためのURIであって,
前記URIは,リソースを識別する文字列であり,
前記URIは,ドメイン名(220),リソースの位置をさらに識別するためのパス(230),及びフラグメントコンポーネント(240)を含み,
ハッシュ文字‘#’で識別されるフラグメントコンポーネント(240)は,アプリケーションの状態情報を識別する複数のデータを含むメタデータを有し,
コンピューティングデバイス上で動作するインターネットメッセージングアプリケーションは,URIに付加されたアプリケーションの状態情報を解析する。」

(2)引用例2に記載されている技術的事項
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審拒絶理由通知において引用された,特表2007-525745号公報(2007年9月6日公表,以下,「引用例2」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

E 「【請求項1】
ネットワークに接続された各々のクライアント上で動いている複数の異種のユーザーアプリケーションを用いてデザインを操作するために該ネットワーク上でコラボレーションする,コンピューターによる方法であって,該方法は:
コラボレーションセッションに参加するために,該ネットワーク上でセッションクライアントプロセスをセッションマネージャーに接続する工程;
該セッションマネージャーに接続された他のセッションクライアントプロセスとセッションコントロールメッセージを共有する工程;
該デザインを表すデザインデータを該クライアント上で動いているローカルアプリケーションへロードする工程;
該ローカルアプリケーションの少なくとも1つの状態を表す少なくとも1つのアプリケーション状態ファイルを,該ローカルアプリケーションを用いて該デザインの少なくとも1つの操作に基づいて作成する工程;
少なくとも1つのアプリケーション状態ファイルを該セッションマネージャーを介して該セッションクライアントプロセスから該他のセッションクライアントプロセスへ通信する工程;および
他のローカルアプリケーションによって作成され,該セッションマネージャーを介して該他のセッションクライアントから通信された少なくとも1つのアプリケーション状態ファイルをロードする工程;
を包含する,方法。
【請求項2】
請求項1に記載の方法であって,前記少なくとも1つのアプリケーション状態が,少なくとも1つのアプリケーション状態ファイルを作成するために,規格化されたXML構造を用いてコード化され,該少なくとも1つのアプリケーション状態ファイルがXMLメッセージとして通信される,方法。」

F 「【0015】
アプリケーション状態は,好ましくは,内蔵インタープリターを介して様々なアプリケーションによる使用のためにデザインされ規格化されたXML構造のセットでコード化される。全体のイメージをコード化する代わりに,これらのXMLは,関与するアプリケーション30?36に共通の抽象化レベルに関する状態およびデーターベースオブジェクトを参照する。言い換えると,アプリケーション30?36は,イメージを伝達する代わりに,それらのデータベースと比較してそれらの状態を伝達する。CADアプリケーションにおいて,例えば,アプリケーション状態としては,ズーム,パン,ユニット,視感度,色,ハイライトなどが挙げられ得,デザインオブジェクトとしては,レイヤー,クラス,コンポーネント,ピン,ネット,テストポイント,オブジェクトの属性およびプロパティなどが挙げられ得,アノテーションとしては,テキスト,図面,URLハイパーリンクなどが挙げられ得る。XMLフォーマットでのアプリケーション状態ファイルの一例は,図6に示される。」

G 「



ここで,上記引用例2に記載されている事項を検討する。

(a)上記Eの「該ローカルアプリケーションの少なくとも1つの状態を表す少なくとも1つのアプリケーション状態ファイルを・・・作成する」との記載,同じく上記Eの「前記少なくとも1つのアプリケーション状態が,少なくとも1つのアプリケーション状態ファイルを作成するために,規格化されたXML構造を用いてコード化され,該少なくとも1つのアプリケーション状態ファイルがXMLメッセージとして通信される」との記載,及び上記Fの「アプリケーション状態は,好ましくは,内蔵インタープリターを介して様々なアプリケーションによる使用のためにデザインされ規格化されたXML構造のセットでコード化される。」との記載から,引用例2には,「アプリケーションの状態を表すアプリケーション状態ファイルをXML構造を用いてコード化する」との事項(以下,「引用例2記載事項A」という。)が記載されているものと認められる。

(b)また,上記Fの「XMLフォーマットでのアプリケーション状態ファイルの一例は,図6に示される。」との記載,及び上記Gで引用した図6の記載から,引用例2には,「XMLフォーマットでのアプリケーション状態ファイルは,で囲まれた要素の中にで囲まれた要素が入れ子状に配置され,要素の中に,で囲まれた要素が入れ子状に配置され,さらに,要素の中に,で囲まれた要素,要素や要素などを含む多数の要素が入れ子状に配置されている。」との事項(以下,「引用例2記載事項B」という。)が記載されているものと認められる。

(3)引用例3に記載されている技術的事項
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となり,当審拒絶理由通知において引用された,「中鉢 欣秀 外2名,状態機械を用いるフレームワーク記述言語FwMLの設計とMVCアプリケーションへの適用,社団法人情報処理学会,2003年12月15日,第44巻,No.SIG16(PRO20),1?14頁」(以下,「引用例3」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

H 「ソフトウェアの実行時状態をXMLで表現し,MVC構造におけるコントローラを状態機械で記述することにより,再利用性のあるコントローラ部品を作成するための言語FrameworkMarkupLanguage(FwML)および実行環境FwMLRuntimeEngine(FwML-RE)を開発した.」(第1頁要約の1?3行)

I 「本研究では,前節の課題点をふまえ,(1)アプリケーションの実行時状態の表現にXMLを用いることによる,再利用可能なコントローラの実現,(2)コントローラが担うアプリケーションの実行時状態の変化を状態機械で制御するための専用言語の開発,の2つの観点から解決法を提案する.」(第2頁左欄19?24行)(当審注:原文の丸付き数字は,カッコ()で囲んだ数字で表記した。)

J 「「StateModel」は,FwML-SM仕様に基づいたXMLで表現されたデータであり,実行時状態を格納する.」(第3頁左欄12?14行)

K 「これらを3.2.1項で用意したプラグポイントに接続することで,StateModelの全体が定義される.図9に住所録で使用するStateModelの例を示す.」(第8頁左欄6?8行)

L 「



ここで,上記引用例3に記載されている事項を検討する。

(a)上記Hの「ソフトウェアの実行時状態をXMLで表現し」との記載,上記Iの「アプリケーションの実行時状態の表現にXMLを用いる」との記載,上記Jの「「StateModel」は,FwML-SM仕様に基づいたXMLで表現されたデータであり,実行時状態を格納する」との記載から,引用例3には,「アプリケーションの実行時状態をXMLを用いて表現する」との事項(以下,「引用例3記載事項A」という。)が記載されているものと認められる。

(b)また,上記Jの「「StateModel」は,FwML-SM仕様に基づいたXMLで表現されたデータであり,実行時状態を格納する」との記載,上記Kの「図9に住所録で使用するStateModelの例を示す」との記載,及び上記Lで引用した図9の記載から,引用例3には,「XMLで表現され,実行時状態を格納するStateModelは,で囲まれた要素の中にで囲まれた要素が入れ子状に配置され,要素の中に,で囲まれた2つの要素が入れ子状に配置され,さらに,各要素の中に,で囲まれた要素,で囲まれた要素などを含む多数の要素が入れ子状に配置されている。」との事項(以下,「引用例3記載事項B」という。)が記載されているものと認められる。

(4)参考文献1に記載されている技術的事項
本願の優先日前に頒布又は電気通信回線を通じて公衆に利用可能となった,「吉濱 佐知子 外2名,Web2.0アプリケーションにおける代表的な攻撃手法とその対策,情報処理,社団法人情報処理学会,2009年01月15日,第50巻,第1号,p.44?54」(以下,「参考文献1」という。)には,関連する図面とともに,以下の技術的事項が記載されている。(当審注:下線は,参考のために当審で付与したものである。)

M 「・・・一般的にブラウザはURLのフラグメント識別子以降はサーバに送信せずにブラウザ内でのみ処理する・・・」(第46頁右欄第40?42行)

4.対比
本願発明と引用発明とを対比する。

(a)引用発明の「URI」が本願発明「コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子(URI)」に相当する。また,引用発明の「アプリケーションの状態情報」が本願発明の「アプリケーション状態情報」に相当する。
引用発明の「URI」は,“ドメイン名(220)”,“パス(230)”,及び“フラグメントコンポーネント(240)”などを含み,これらの“データ”が,所定の順序で結合された“構造”を有しているから,引用発明の「URI」は,“データ構造”に“含まれる”ものであると言える。
また,引用発明の「URI」は,それに“付加されたアプリケーションの状態情報”が,“コンピューティングデバイス上で動作するインターネットメッセージングアプリケーション”によって解析されるものであるから,引用発明の「URI」は,「コンピュータによって処理される」ものであり,「アプリケーション状態情報に関する」ものであり,かつ,「コンピュータ・データ構造」であるということができる。
そうすると,引用発明と本願発明とは,「コンピュータによって処理される,アプリケーション状態情報に関するコンピュータ・データ構造であって,前記データ構造は,コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子(URI)を含み」との点で一致する。

(b)引用発明の「URI」は,“リソースを識別する文字列であ”り,この「文字列」が,本願発明の「文字のストリング」に相当するから,引用発明の「URI」は,“文字のストリングで表現され”ているということができる。

(c)
(c-1)引用発明の「ハッシュ文字‘#’」は,“URI中”のものであるから,本願発明の「URI中のハッシュ文字」に相当する。
引用発明の「フラグメントコンポーネント(240)」は,URI中で,「ハッシュ文字‘#’」によって区切られて識別される“部分”であり,この“部分”が“アンカー”とも呼ばれることは,URIの表記における常識であるから,引用発明の「フラグメントコンポーネント(240)」が本願発明の「アンカー部分」に対応する。
また,引用発明の「フラグメントコンポーネント(240)」は,URIのデータ構造において,「ハッシュ文字‘#’」で区切られた“部分”として“定義される”ものである。
引用発明の「フラグメントコンポーネント(240)」は,“アプリケーションの状態情報を識別する複数のデータを含むメタデータを有し”ており,当該メタデータは,“複数のデータ”を“配列”したものと言えるから,引用発明の“メタデータ”を有する“フラグメントコンポーネント(240)”が本願発明の「データ配列」に相当する。
以上の検討から,引用発明の「ハッシュ文字‘#’で識別されるフラグメントコンポーネント(240)」と本願発明の「URI中のハッシュ文字で識別されるアンカー部分として定義される一つの第1のデータ配列」とは,「URI中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列」である点で共通する。
(c-2)引用発明の「フラグメントコンポーネント(240)」は“アプリケーションの状態情報を識別する複数のデータを含むメタデータを有し”ており,このメタデータによって,“アプリケーションの状態情報”を“表現する”ものである。
また,「フラグメントコンポーネント(240)」は,「URI」の一部であるから,上記(b)の検討を踏まえると,“URI”の“ストリング”の一部を構成する“サブストリング”であり,上記(c-1)の検討も踏まえると,本願発明の「URI中のアンカー部分のサブストリング」に対応するものである。
(c-3)上記(c-1)及び(c-2)の検討から,引用発明の「URI」(ストリング)は,“アプリケーションのアプリケーション状態情報”を“URI中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列”によって“表現する”,“URI中のアンカー部分のサブストリング”を“含む”ものであるということができる。
してみれば,引用発明と本願発明とは,「ストリングは,アプリケーションのアプリケーション状態情報を,URI中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列によって表現する,前記URI中のアンカー部分のサブストリングを含」む点で一致する。

そうすると,本願発明と引用発明とは,

「コンピュータによって処理される,アプリケーション状態情報に関するコンピュータ・データ構造であって,前記データ構造は,コンピュータ・ネットワーク中のリソースを識別する統一リソース識別子(URI)を含み,前記URIは文字のストリングで表現され,前記ストリングは,アプリケーションの前記アプリケーション状態情報を,前記URI中のハッシュ文字で識別されるアンカー部分として定義されるデータ配列によって表現する,前記URI中のアンカー部分のサブストリングを含む,構造。」

の点で一致し,次の点で相違する。

[相違点1]
アプリケーション状態情報を表現するデータ配列が,本願発明では,「一つの第1のデータ配列と,前記アンカー部分を構成し,前記第1のデータ配列に入れ子になる一つ以上の第2のデータ配列と,前記アンカー部分を構成し,前記第2のデータ配列に入れ子になる一つ以上の第3のデータ配列とを有する入れ子状になった複数のデータ配列」であり,かつ,「前記第2のデータ配列の各々は,前記入れ子状になった複数のデータ配列のうちの前記第1のデータ配列のエレメントであり,前記第3のデータ配列の各々は,前記入れ子状になった複数のデータ配列のうちの前記第2のデータ配列のエレメントである」のに対して,引用発明では,そのように特定されていない点。

5.当審の判断
上記相違点について検討する。

[相違点1]について
引用例2には,「アプリケーションの状態を表すアプリケーション状態ファイルをXML構造を用いてコード化する」との事項(引用例2記載事項A)が記載されており,また,引用例3には,「アプリケーションの実行時状態をXMLを用いて表現する」との事項(引用例3記載事項A)が記載されていることからみて,「アプリケーションの状態をXMLを用いて表現すること」は,本願の優先日前に,当該技術分野における周知技術であったものと認められる。
また,引用例2に,「XMLフォーマットでのアプリケーション状態ファイルは,で囲まれた要素の中にで囲まれた要素が入れ子状に配置され,要素の中に,で囲まれた要素が入れ子状に配置され,さらに,要素の中に,で囲まれた要素,要素や要素などを含む多数の要素が入れ子状に配置されている。」との事項(引用例2記載事項B)が記載され,引用例3に,「XMLで表現され,実行時状態を格納するStateModelは,で囲まれた要素の中にで囲まれた要素が入れ子状に配置され,要素の中に,で囲まれた2つの要素が入れ子状に配置され,さらに,各要素の中に,で囲まれた要素,で囲まれた要素などを含む多数の要素が入れ子状に配置されている。」との事項(引用例3記載事項B)が記載されているように,XMLでは,データに含まれる各要素(親要素)が,入れ子状に複数の子要素を有することができ,子要素が更に入れ子状に複数の孫要素を有するようにすることができることが技術常識である。
そして,RFCには,URIのフラグメント部分に入れる情報について特に指定がないことから,この部分にどのような情報を入れるかは任意であり,また,URIのフラグメント部分は,上記参考文献1(上記Mの記載を参照)に記載されているように,ブラウザで処理されるものであることからすれば,この部分にブラウザで処理するXML構造の情報を入れるように構成することに格別の困難性はない。
してみれば,引用発明のURIにおいて,アプリケーションの状態情報を表現する際に,上記周知技術を適用して,アプリケーションの状態情報を識別するメタデータをXMLを用いて表現するようにし,その際,XMLの入れ子の構造を用いることによって,アンカー部分として定義されるデータ配列を,
(1)一つの第1のデータ配列と,
(2)アンカー部分を構成し,前記第1のデータ配列に入れ子になる一つ以上の第2のデータ配列と,
(3)前記アンカー部分を構成し,前記第2のデータ配列に入れ子になる一つ以上の第3のデータ配列と
を有する入れ子状になった複数のデータ配列となるように構成するとともに,
(4)前記第2のデータ配列の各々が,前記入れ子状になった複数のデータ配列のうちの前記第1のデータ配列のエレメントであり,
(5)前記第3のデータ配列の各々が,前記入れ子状になった複数のデータ配列のうちの前記第2のデータ配列のエレメントであるように構成すること,
すなわち,上記相違点1に係る構成とすることは,当業者が容易に想到し得たことである。

そして,本願発明の作用効果も,引用発明及び周知技術から当業者が予測できる範囲のものである。

したがって,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものである。

6.むすび
以上のとおり,本願発明は,引用発明及び周知技術に基づいて,当業者が容易に発明をすることができたものであるから,特許法第29条第2項の規定により特許を受けることができない。
したがって,本願は他の請求項について検討するまでもなく拒絶されるべきものである。

よって,結論のとおり審決する。
 
審理終結日 2017-01-30 
結審通知日 2017-01-31 
審決日 2017-02-14 
出願番号 特願2012-530184(P2012-530184)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 田中 幸雄  
特許庁審判長 高木 進
特許庁審判官 石井 茂和
須田 勝巳
発明の名称 統一リソース識別子(URI)による、アプリケーション状態情報の管理  
復代理人 間山 進也  
代理人 上野 剛史  
代理人 太佐 種一  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ