【事件の表示】
　特願２０００−２８４８６１「データ配信システムおよびデータ端末装置」拒絶査定不服審判事件〔平成１４年　３月２９日出願公開、特開２００２−　９１８８３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　この出願は，平成１２年９月２０日の出願であって，平成２０年１２月２６日付けの拒絶理由の通知に対して，平成２１年３月６日に意見書の提出とともに手続補正がなされ，平成２１年３月２５日付けの拒絶査定に対して平成２１年４月２７日に審判請求がなされるとともに平成２１年４月２８日付けで手続補正がなされ，平成２２年１２月１５日付けの当審の前置報告を引用した審尋に対して，平成２３年２月１４日に回答がなされ，平成２３年５月２５日付けの当審の拒絶理由の通知に対して，平成２３年７月２８日に意見書が提出されたものである。  
 　  
２．本願発明について
　本願の請求項１に係る発明（以下「本願発明」という。）は，平成２１年４月２８日付けの手続補正（以下「本件補正」という。）で補正された明細書の特許請求の範囲の請求項１に記載された事項により特定される，次のとおりのものである。  
「受信したコンテンツデータを記録手段に記録する記録部と，
　前記記録手段に記録したコンテンツデータの曲名およびアーティスト名を含むコンテンツメールを作成するメール作成部と，
　前記コンテンツメールを他のデータ端末装置に送信する送信部とを備える，データ端末装置。」 
 　 
３．当審における拒絶の理由について
　当審における平成２３年５月２５日付けで通知した拒絶理由の概要は，以下のとおりである。 
『この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
 　 
 　　　　　　　　　　　　　　　　記 
 　 
 　　　　　　　　　　　引　用　文　献　等　一　覧 
 引用例１：国際公開第００／３９７３３号 
 　 
・請求項１ 
・引用例１ 
・備考 
　ア　引用例１には，以下のことが記載されている。 
 「（略）」 
 （第６２ページ第９行〜第７０ページ末行） 
 （当審仮訳：（略））
　イ　ここで，引用例１と本願の請求項１に係る発明（以下「本願発明」という。）とを対比すると，引用例１の「コンテンツ」「消費者プレーヤー」「ダウンロード」「タイトル」「演奏家」「電子メール」「友人や他の消費者のプレーヤー」は，それぞれ本願発明の「コンテンツデータ」「データ端末装置」「受信して記録すること」「曲名」「アーティスト」「メール」「他のデータ端末装置」に相当するものと言えることから，引用例１には，本願発明の以下の事項に相当する事項が開示されていると言える。（以下「引用例１開示事項」という。） 
「受信したコンテンツデータを記録し， 
　記録したコンテンツデータの曲名およびアーティスト名を含むコンテンツに係るメールを作成し， 
　コンテンツに係るメールを他のデータ端末装置に送信する， 
　データ端末装置。」 
 　 
　ウ　引用例１開示事項を引用例１発明として本願発明と比較すると，本願発明は，以下の点で相違する。 
［相違点１］ 
　本願発明では，「コンテンツに係るメール」が「コンテンツメール」であるのに対し，引用例１発明ではそのような構成になっていない点。 
［相違点２］ 
　本願発明では，コンテンツデータを記録手段に記録する記録部を有するのに対し，引用例１発明ではそのような構成になっていない点。 
［相違点３］ 
　本願発明では，コンテンツメールを作成するためのメール作成部を有するのに対し，引用例１発明ではそのような構成になっていない点。 
［相違点４］ 
　本願発明では，コンテンツメールを他のデータ端末装置に送信するための送信部を有するのに対し，引用例１発明ではそのような構成になっていない点。 
 　 
　エ　以上の相異点について，以下に判断する。 
［相違点１について］ 
　本願発明の「コンテンツメール」は，発明の詳細な説明の【０１６６】段落の記載によれば，コンテンツ情報，つまり曲名およびアーティスト名をメールに付加したものである。　友人に知らせたい情報をメールに付加することは，設計上の必要性に応じて当業者が適宜なし得る設計的事項である。（以下「設計的事項Ａ」という。） 
　してみると，引用例１発明に設計的事項Ａを適用することにより，「コンテンツに係るメール」を「コンテンツメール」とすることには何ら困難性がなく，当業者が容易に想到することができたものである。 
［相違点２〜４について］ 
　データ端末装置に，コンテンツデータを記録手段に記録する記録部を設け，メールを作成するためのメール作成部を設け，メールを他のデータ端末装置に送信するための送信部を設けることは，設計上の必要性に応じて当業者が適宜なし得る設計的事項である。（以下「設計的事項Ｂ」という。） 
　してみると，引用例１発明に設計的事項Ｂを適用することにより，コンテンツデータを記録手段に記録する記録部を有するよう構成し，コンテンツメールを作成するためのメール作成部を有するよう構成し，コンテンツメールを他のデータ端末装置に送信するための送信部を有するよう構成することには何ら困難性がなく，当業者が容易に想到することができたものである。 
　オ　以上判断したとおり，本願発明における上記［相違点１］ないし［相違点４］に係る発明特定事項は，いずれも当業者が容易に想到することができたものであり，上記各相違点を総合しても，想到することが困難な格別の事項は見いだせない。  
　また，本願発明の作用効果も，引用例１発明及び設計的事項から当業者が予測できる範囲のものである。  
　したがって，本願発明は，引用例１発明及び設計的事項に基づいて，当業者が容易に発明をすることができたものである。』 　  
 　　  
４．当審の判断
４−１．引用例について
（１）引用例記載事項について
　平成２３年５月２５日付けで通知した拒絶理由で引用した引用例（国際公開第００／３９７３３号）には，以下のことが記載されている。（以下「引用例記載事項」という。）
「10. The Content References 
　　　The system transports electronic digital media to consumers in a timely and efficient manner. Electronic digital media content such as music are referred to generically as content. The nature of content is that they are large objects, typically multiple megabytes in size. Their transport requires a balance of bandwidth and time to get it to consumers. In addition, storage of content requires significant resources if it is to be kept by the consumer. 
The solution to this challenge is to separate descriptive information from the content itself. This is analogous to a World Wide Web Uniform Resource Locator (URL). The URL is a small amount of descriptive information that can be displayed on a web page or easily moved around or e-mailed from one consumer to another. The resource, which the URL points to, may be an HTML web page or a large file. These may be large and bulky to move around, but the URL can be remembered and used as a simple mechanism to get to the resource when needed. The System introduces the content reference as the analogous mechanism to avoid copying large content files any more than necessary. 
　　　Content references provide a lightweight mechanism used by consumers to receive, save, and share content identification information and to send it to other consumers without having to move large binary files around. A content reference can be thought of as an address or pointer to content and is the mechanism to refer to content indirectly. A content reference contains a small amount of descriptive information about a piece of content. This descriptive information contains sufficient information to allow a consumer with a Consumer Player to determine what the content is and how to get to the content, but does not contain the actual content. 
　　　As an example, a fan club web site may include content references to songs for a particular artist without having to store large, unsecured content of that artist. Visitors to the web site will then download the content reference and through the Reference Server they will be directed to a Delivery Service from which they can download the content. That same consumer can also email the content reference to friends or place it on their web site for further dissemination of the content reference. Content references also provide a mechanism for consumers to share a music-listening experience synchronously and remotely. When a consumer is listening to music and wishes to share the experience with another consumer at a remote location he can drag a content reference into an email or chat client and send it to the other consumer. When the content reference arrives at the remote location the content reference can be opened, and using the time synchronization, the Consumer Player is able to start playing the referenced content at the same point the original user's content is playing. 
　　　Extensible Markup Language (XML) may be used for representing content references. XML provides a standardized method for structuring data in a loose fashion, allowing flexibility in defining the structure while constraining the content. 
　　　Content references take the form of a message that is used system wide for inter-module communication. Each message contains at least a header section and an ID section and may contain additional sections, such as, an offer section, a synchronization section, a debug section and a support section (reserved for future use). For a content reference, the message must contain a meta-data section. 
　　　The following XML document is an example of a content reference. This content reference has the following sections, namely: a header section (line 1), an ID section (line 11), and a meta-data section, (line 16), in addition to following optional sections: an offer section (line 24) and a time-sync section (line 38). Below is a Document Type Definition for the XML document as described by the XML version 1.0 specification. The numbers in the left-hand column are line numbers that are not part of the document and are included only for reference purposes. Each tag with its set of allowable attributes is defined following the XML document. !-- Header Section mandatory--gt; 
1. ? xml version='1.0' 
2. content-reference version=0.1 
3. signature=012345 
4. BaseID=1234567... 64gt; 
5. 
6. debug !-- optional section-- 
7. !-- arbitrary attributes here-- 
8. lt;/debuggt; 
9. !-- there can be multiple item sections-- 
10. item 
11. id !-- ID Section mandatory--
12. DRID=1CHID=1OFRID=1 
13. PRID=lMDID=lOBID=IGRID=l 
14. INID=1PLID=l 
15. id/ 
16. desc !-- Description Section-Basic Meta Data mandatory--
17. title=Title 
18. artist=Artist 
19. producer=Producer 
20. publisher=Publisher 
21. length=HH: MM: SS 
22. desc/ 
23. 
24. !-- offer-container section optional-- 
25. offer-container locator=inline 
26. formatVENDOR 
27. version--1 
28. encoding=base64 
29. sdata !-- secure data section-- 
30. OFRID=234567 
31. CERT=12345678910 
32. Countl 
33. ;/sdata 
34. /offer-container 
35. supportdata !-- support-container section optional-- 
36. reserved for future use 
37. /supportdata 
38. time sync !-- time-sync section optional-- 
39. GTID=1999-02-24T14:30:23 
40. LTID=HH:MM:SS:MM! Offset  
41. STID=Pause 
42. time sync/ 
43. /item 
44. /content-reference
　　　Line 1 is the XML document standard opening that defines the document as a document complying with XML specification version 1.0. 
　　　Line 2 begins the content of the content reference. The tag content-reference begins the body of the reference. The version attribute takes the format of major#. minor#. The version is incremented by the owner of the content reference specification. 
　　　Line 3 is the signature attribute. The signature format is an alphanumeric sequence that may be either a checksum of the reference or a digital signature for validation by another system module. This attribute may need to be a separate section or be included with each section that needs to be protected. 
　　　Line 4 is the Base ID which is the random 64 bit number typically assigned to the content reference by the back office system used for indexing. The purpose of this number is to establish the uniqueness of the content reference. 
　　　Empty lines such as 5,23, are optional. 
　　　Line 6 begins an optional debug section. This section allows for the inclusion of any debug information or commands that developers of the system may require. 
　　　Line 7 indicates that debug tags and attributes are placed here. 
　　　Line 8 closes the debug section. 
　　　Line 9 is an informational comment. 
　　　Line 10 begins an individual item section. The item tag for each reference must generally have at least one item section, but may optionally have more than one item section. All item sections must conform to the same syntax requirements. 
　　　Line 11 starts the ID section. Each item section must generally have an id clause. 
　　　Line 12 contains the value chain ID. The attribute CHID is the Retailer ID and/or Channel ID. It is uniquely assigned to a specific retailer and/or retail channel by the system. The attribute DRID is the Distributor ID. It is uniquely identifies a distributor within the system. The attribute OFRID is the Offer ID and is optional. It is set when the offer is created and is unique to a retailer, channel or distributor. If the CHID is different from the DRID, then the offer was created either by a retailer or channel or the production systems on behalf of that retailer or channel and the offer ID is unique to the CHID. If the offer is a default offer from the distributor (i. e., CHID = DRID) then the offer ID is unique to the DRID. If the Content Reference simply refers to content, there may not be an offer ID. 
　　　Line 13 contains the Content ID. The attribute PRID is the Product ID. This is the unique media container in which the content is located. The attribute MDID is the Media ID and is optional. This is the physical media on which the content resides. This can be a CD, ECD or DVD disk or some other physical distribution media. The attribute OBID is the Object ID. It uniquely identifies the digital media object from a specific DRID. This is equivalent to the media object (MOB) described above. The attribute GRID is the Group ID and is optional. It must be included if the object ID is defined as a part of a group and identifies that group (e. g., the content reference is for a single OBID from an Album GRID). It uniquely identifies a group object from a specific DRID. 
　　　This is equivalent to the group object (GOB) described above. 
　　　Line 14 contains the Client ID. The attribute INID is the Instantiator ID. The entity that creates the reference is the instantiator. This can be the distributor, the retailer, or the user. For example, when the user creates a reference by dragging a song from the playlist in the player, they create a reference with the IID set to the user ID. INIDs, CHIDs, and DRIDs are generally distinguishable. The attribute PLID is the Player ID. This is the ID of the player which is assigned by the back office system (s) in a range and/or prefix to enable the Consumer Player to be uniquely identified. 
　　　Line 15 ends the ID section. 
　　　Line 16 begins the description section. The desc tag and section is the minimum meta data set of the Content. 
　　　Line 17 is the attribute title and is the title of the content referenced in the current item section. 
　　　Line 18 is the attribute artist. This will be a comma-separated list for multiple artists. 
　　　Line 19 is the attribute producer. This will be a comma-separated list for multiple producers. 
　　　Line 20 is the attribute publisher. 
　　　Line 21 is the attribute length and is the length of the content referenced in the current item section. The format is hours: minutes: seconds (e. g., 16: 56: 21). 
　　　Line 22 ends the description section. 
　　　Line 24 is an informational comment. 
　　　Line 25 begins the offer container section with the lt;offer-containergt; tag. When the reference is simply a reference to content and does not include an offer, then the offer container section will be omitted. The offer ID in the ID section may still be valid. The implication is that the user will need to get the offer from the Reference Service. If the offer is included with the reference, then it can beattachedin one of three ways. The locator attribute indicates if the offer container is inline, append, or external. These are the three options for the location attribute. If locator-inline then the offer container is base64 encoded and inserted in the following sdata section. If locator=append then the offer container is concatenated to the reference file immediately following the /content- reference close tag. If locator=extemal then the offer container is a separate file pointed to by the optional attribute URL. This attribute is not optional if locator=external. In this case, line 21 would read: lt;offer-container locator=externalURL=file://c: \temp\file. ref. 
　　　Line 26 is the format attribute. Allowable values for the format attribute indicate the format of the offer container data. This is dependent on what the vendor used to provide the offer security technology. Therefore, the format will be set to a meaningful value associated with the technology supplied by the security vendor. These values are defined and assigned by the back office system or the production system. 
　　　Line 27 is the version attribute which represents the version of the security technology used to enclose the offer. This is vendor-dependent. 
　　　Line 28 is the encoding attribute which indicates what technique has been used to encode the offer container data, which will originally be in some binary format, into the same encoding as the reference/XML. Typically the value for encoding isbase64. 
　　　Line 29 begins the secure data section with the sdata tag. This is the section in which the offer container data is inlined, if locator=inline. 
　　　Line 30 is the attribute OFRID which is the Offer ID. It is set when the offer is created by the Production System and is a one way hash function of the BaseID This is identical to the OFRID in the ID section. 
　　　Line 31 is the attribute CERT which is the identity of any certificates or public keys associated with the offer. 
　　　Line 32 is the attribute COUNT which is the count field that gets incremented if additional certificates are provided indicating that the offer has been super distributed. This will be used to in managing the super distribution value chain. 
　　　Line 33 closes the secure data section with the /sdata tag. 
　　　Line 34 closes the offer container section with the coffer-contained tag. 
　　　Line 35 begins the attribute support section. This section contains the support reference data that will be delivered to the client if this section is included. 
　　　Line 36 indicates that the support section is reserved for future use. 
　　　Line 37 ends the support section. 
　　　Line 38 begins the time synchronization section with the time sync tag. 
　　　Line 39 is the GTID attribute which is a date/time stamp based on ISO 8601 and received from the system time reference server. GTID is set to GMT at creation of the reference. 
　　　Line 40 is the LTID attribute which is the offset of the local machine from the start of a piece of Content. This is expressed as hours: minutes: seconds: milliseconds. 
　　　Line 41 is the STID attribute which is the condition of the local content expressed as eitherplayorpause. 
　　　Line 42 ends the time sync section. 
　　　Line 43 closes the item section with the item tag. 
　　　Line 44 closes the content reference section with the lt;/content-reference tag.」
（第６２ページ第９行〜第７０ページ末行）
（当審仮訳：
１０．コンテンツ参照
　システムは，タイムリーに効率的な方法で消費者に電子デジタル媒体を送る。音楽のような電子デジタル媒体コンテンツは，通常，コンテンツと呼ばれる。コンテンツの本来の性質は，通常，大きさが数メガバイトの大きなオブジェクトである。このようなコンテンツを送るには，それを消費者に送るために，帯域幅と時間とのバランスをとる必要がある。さらに，
消費者が保持するために
コンテンツ自身から記述情報が分離される
　
コンテンツ参照は，コンテンツ識別情報を受信し，セーブし，共有するために，また
それを他の消費者に送るために，消費者が使用する軽量の機構を供給する
コンテンツ参照は，１つのコンテンツについての短い記述情報を含む。この記述情報は，消費者が消費者プレーヤーを使用して，コンテンツがどんなものであるか，また，そのコンテンツをどうしたら入手できるかを判断することができるだけの十分な情報を含んでいるが，実際のコンテンツは含んでいない
　一例を挙げると，ファン・クラブ・ウェブサイトは，その演奏家の大きな機密保護がされていないコンテンツを記憶しないでも，特定の演奏家に対する歌へのコンテンツ参照を含むことができる。その後で，ウェブサイトへのビジターは，コンテンツ参照をダウンロードし，参照サービスを通して配布サービスに導かれ，そこから
コンテンツをダウンロードする。同じ消費者は，また，友人に電子メールを送ることができ
消費者が同時に遠隔地で音楽のリスニングの経験を共有するための機構も供給する
消費者は，コンテンツ参照を電子メール
へドラッグして，それを他の消費者に送ることができる。コンテンツ参照が遠隔地に到着すると，コンテンツ参照を開くことができ
消費者プレーヤーは
　
拡張可能なマークアップ言語（ＸＭＬ）は，コンテンツ参照を表示するために使用することができる。
　
コンテンツ参照は
メッセージの形をとる
各メッセージは，少なくともヘッダ・セクションと，ＩＤセクションとを含み，提供セクション，同期セクション，デバッグ・セクション，およびサポート・セクション
のような追加のセクションを含むことができる。コンテンツ参照に対しては，メッセージは，メタデータ・セクションを含んでいなければならない。
下記のＸＭＬ文書は，コンテンツ参照の一例である
このコンテンツ参照は
下記のセクション
すなわち，ヘッダ・セクション（第１行），ＩＤセクション（第１１行），およびメタデータ・セクション（第１６行）を含む。
1.   ?xml version='1.0'
2.   content-reference version=0.1
3.   signature=012345
4.   Base_ID=1234567...64
5.
6.      debug     !--optional section--
7.         !--arbitrary attributes here--
8.      /debug
9.   !--there can be multiple item sections--
10.   item
11.      id !--ID Section mandatory--
12.            DRID=1CHID=1OFRID=1
13.            PRID=1MDID=1OBID=1GRID=1
14.            INID=1PLID=1
15.      id/
16.      desc !--Description Section-Basic Meta Data mandatory--17.            title=Title18.            artist=Artist
20.            publisher=Publisher
21.            length=HH:MM:SS
22.      desc/
23.
24.      !--offer-container section optional--
25.      offer-containerlocator=inline
26.            format=VENDOR
27.            version=1
28.            encoding=base64
29.            sdata     !--secure data section--
30.               OFRID=234567
31.               CERT=12345678910
32.               Count=1
33.            /sdata
34.      /offer-container
35.      support_data!--support-container section optional--
36.                        reserved for future use
37.      /support_data
38.      time sync  !--time-sync section optional--
39.            GTID=1999-02-24T14:30:23
40.            LTID=HH:MM:SS:MM!Offset
41.            STID=Pause
42.      time sync/
43.   /item
44.   /content-reference
　第１行は，この文書をＸＭＬ仕様バージョン１．０に適合する文書として定義しているＸＭＬ文書の標準の冒頭部分である。
　第２行は，コンテンツ参照のコンテンツの始めの部分である。タグ＜content-reference＞は，参照の本体の始めの部分である。バージョン属性は，ｍａｊｏｒ＃．ｍｉｎｏｒ＃．の形をしている。このバージョンは，コンテンツ参照仕様の所有者により増分だけ増大する。
　第３行は，署名属性である。署名のフォーマットは，参照のチェックサム，または他のシステム・モジュールによる確認のためのデジタル署名であってもよい英数字のシーケンスである。この属性は，別のセクションにする必要がある場合もあるし，または保護を必要とする各セクションと一緒にする必要がある場合もある。
　第４行は，索引のために使用される社内システムによりコンテンツ参照に通常割り当てられるランダムな６４ビットの番号であるベースＩＤである。この番号の目的は，コンテンツ参照の一意性を確立することである。
　第５行，第２３行のような空欄の行は，オプションとしての行である。
  第６行は，任意のデバッグ・セクションの始めの部分である。このセクションは，任意のデバッグ情報，またはシステムの開発者が必要とするかもしれないコマンドを含むことができる。
　第７行は，デバッグ・タグおよびそこに挿入される属性を示す。
　第８行は，デバッグ・セクションの終わりである。
　第９行は，情報コメントである。
　第１０行は，個々の項目セクションの始めの部分である。各参照の項目タグは，通常，少なくとも１つの項目セクションを持っていなければならないが，そうしたい場合には，１つ以上の項目セクションを持つことができる。すべての項目セクションは，同じシンタックス要件に適合しなければならない。
　第１１行は，ＩＤセクションの始めの部分である。各項目セクションは，通常，１つのｉｄ節を持っていなければならない。
　第１２行は，バリュー・チェーンＩＤを含む。属性ＣＨＩＤは，小売業者ＩＤおよび／またはチャネルＩＤである。属性ＣＨＩＤは，システムにより特定の小売業者および／または小売チャネルに一意に割り当てられる。属性ＤＲＩＤは，配給業者ＩＤである。属性ＤＲＩＤは，システムの配給業者を一意に識別する。属性ＯＦＲＩＤは，提供ＩＤであり，任意のものである。この属性は，提供が生成され，それが小売業者，チャネルまたは配給業者に対して一意なものである場合に設定される。ＣＨＩＤがＤＲＩＤとは異なるものである場合には，提供は，その小売業者またはチャネルの代わりに，小売業者，またはチャネル，または製作システムが生成したものであり，提供ＩＤは，ＣＨＩＤに対して一意のものである。提供が，配給業者からのデフォールト提供である場合（すなわち，ＣＨＩＤ＝ＤＲＩＤである場合）には，提供ＩＤはＤＲＩＤに対して一意である。コンテンツ参照が単にコンテンツを参照する場合には，提供ＩＤが存在しない場合がある。
　第１３行は，コンテンツＩＤである。属性ＰＲＩＤは作品ＩＤである。これは，その内部にコンテンツが位置する一意の媒体コンテナである。属性ＭＤＩＤは，媒体ＩＤであり，任意のものである。これは，その上にコンテンツが常駐する物理的媒体である。これは，ＣＤであっても，ＥＣＤであっても，またはＤＶＤディスクであっても，または他のある種の物理的配布媒体であってもよい。属性ＯＢＩＤは，オブジェクトＩＤである。この属性は，特定のＤＲＩＤからデジタル媒体オブジェクトを一意に識別する。この属性は，上記の媒体オブジェクト（ＭＯＢ）に等しい。属性ＧＲＩＤは，グループＩＤであり，任意のものである。オブジェクトＩＤがグループの一部として定義され，そのグループを識別する（例えば，コンテンツ参照が，アルバムＧＲＩＤからの１つのＯＢＩＤに対するものである）場合には，この属性を内蔵させなければならない。この属性は，特定のＤＲＩＤからあるグループ・オブジェクトを一意に識別する。これは，上記のグループ・オブジェクト（ＧＯＢ）と同じものである。
　第１４行は，クライアントＩＤを含む。属性ＩＮＩＤは，実例提示ＩＤである。参照を生成する構成要素が実例提示部分である。実例提示部分は，配給業者であっても，小売業者であっても，またはユーザであってもよい。例えば，ユーザが，プレーヤー内の演奏リストからある歌をドラッグして参照を生成した場合には，ユーザは，ユーザＩＤへの一組のＩＩＤを含む参照を生成する。ＩＮＩＤ，ＣＨＩＤおよびＤＲＩＤは，通常，区別することができる。属性ＰＬＩＤは，プレーヤーＩＤである。これは，ある範囲内で社内システムにより割り当てられるプレーヤーのＩＤであり，および／または消費者プレーヤーを一意に識別できるようにするプレフィクスである。
　第１５行は，ＩＤセクションの終りの部分である。
　
第１６行は，記述セクションの始めの部分である。ｄｅｓｃタグおよびセクションは，コンテンツの一組の最小のメタデータである
　
第１７行は，属性のタイトルであり，現在の項目セクションで参照されたコンテンツのタイトルである
　
第１８行は，属性演奏家である。この行は，複数の演奏家に対するコンマで区切られたリストである
　第１９行は，属性プロデューサである。この行は，複数のプロデューサに対するコンマで区切られたリストである。
　第２０行は，属性発行者である。
　第２１行は，属性の長さであり，現在の項目セクション内で参照されたコンテンツの長さである。フォーマットは，時間：分：秒（例えば，１６：５６：２１）である。
　第２２行は，記述セクションの終りの部分である。
　第２４行は，情報コメントである。
　第２５行は，＜ｏｆｆｅｒ−ｃｏｎｔａｉｎｅｒ＞タグを含む提供コンテナ・セクションの始めの部分である。参照が，単にコンテンツに対する参照であり，提供を含んでいない場合には，提供コンテナ・セクションは省略される。ＩＤセクション内の提供ＩＤは，依然として有効である場合がある。ということは，ユーザは参照サービスから提供を入手しなければならないことを意味する。提供が参照と一緒に含まれている場合には，それを，３つの方法の中の１つで「取り付ける」ことができる。ロケータ属性は，提供コンテナが，インラインのものか，付属のものか，外部のものかを示す。これらは，位置属性に対する３つのオプションである。ｌｏｃａｔｏｒ＝ｉｎｌｉｎｅである場合には，提供コンテナは，ｂａｓｅ６４コード化され，下記のｓｄａｔａセクションに挿入される。もしｌｏｃａｔｏｒ＝ａｐｐｅｎｄである場合には，提供コンテナは＜／ｃｏｎｔｅｎｔ−ｒｅｆｅｒｅｎｃｅ＞終了タグの直後の参照ファイルに鎖状に接続される。ｌｏｃａｔｏｒ＝ｅｘｔｅｒｎａｌである場合には，提供コンテナは，任意の属性ＵＲＬによりポイントされている独立ファイルである。ｌｏｃａｔｏｒ＝”ｅｘｔｅｒｎａｌ”である場合には，この属性は任意のものではない。その場合には，第２１行は，＜ｏｆｆｅｒ−ｃｏｎｔａｉｎｅｒｌｏｃａｔｏｒ＝”ｅｘｔｅｒｎａｌ”ＵＲＬ＝ｆｉｌｅ：／／ｃ：＼ｔｅｍｐ＼ｆｉｌｅ．ｒｅｆ．となる。
　第２６行は，フォーマット属性である。フォーマット属性に対する許容値は，提供コンテナ・データのフォーマットを示す。この許容値は，提供機密保護技術を供給するために，販売業者が何を使用しているかにより異なる。それ故，フォーマットは，機密保護販売業者が供給する技術に関連する，意味のある値に設定される。これらの値は，社内システムまたは製作システムにより定義され，割り当てられる。
　第２７行は，提供を包むのに使用する機密保護技術のバージョンを表わすバージョン属性である。これは，販売業者により異なる。
　第２８行は，もとはある種の２進法のフォーマットである提供コンテナ・データを参照／ＸＭＬと同じコードにコード化するために使用した技術が何であったかを示すコード化属性である。通常，コード化に対する値は「ｂａｓｅ６４」である。
　第２９行は，＜ｓｄａｔａ＞タグを含む，機密保護データ・セクションの始めの部分である。この行は，ｌｏｃａｔｏｒ＝ｉｎｌｉｎｅである場合には，その内部で，提供コンテナ・データがインライン状態にあるセクションである。
　第３０行は，提供ＩＤである属性ＯＦＲＩＤである。提供が製作システムにより生成され，Ｂａｓｅ＿ＩＤの一方向関数である場合には，この属性が設定される。この属性は，ＩＤセクション内のＯＦＲＩＤと同じものである。
　第３１行は，提供に関連する証明書または公開キーの識別である属性ＣＥＲＴである。
　第３２行は，提供がスーパー配布されたことを示す追加の証明書が供給された場合には，増分増大するカウント・フィールドである属性ＣＯＵＮＴである。この属性は，スーパ配布バリュー・チェーンを管理する際に使用される。
　第３３行は，＜／ｓｄａｔａ＞タグを含む機密保護データ・セクションの終りの部分である。
　第３４行は，＜／ｏｆｆｅｒ−ｃｏｎｔａｉｎｅｒ＞タグを含む，提供コンテナ・セクションの終りの部分である。
　第３５行は，属性サポート・セクションの始めの部分である。このセクションは，このセクションが含まれている場合には，クライアントに供給されるサポート参照データを含む。
　第３６行は，サポート・セクションが，将来の使用のために確保されていることを示す。
　第３７行は，サポート・セクションの終りの部分である。
　第３８行は，＜ｔｉｍｅ  ｓｙｎｃ＞タグを含む時間的同期セクションの始めの部分である。
　第３９行は，ＩＳＯ８６０１に基づく，システム時間参照サーバから受信した日付／時間スタンプであるＧＴＩＤ属性である。ＧＴＩＤは，参照の生成の際にＧＭＴに設定される。
　第４０行は，１つのコンテンツのスタートからのローカルマシンのズレであるＬＴＩＤ属性である。この属性は，時間：分：秒：ミリ秒で表示される。
　第４１行は，「演奏」または「ポーズ」として表わされるローカルコンテンツの条件であるＳＴＩＤ属性である。
　第４２行は，時間的同期セクションの終りの部分である。
　第４３行は，＜／ｉｔｅｍ＞タグを含む項目セクションの終りの部分である。
　第４４行は，＜／ｃｏｎｔｅｎｔ−ｒｅｆｅｒｅｎｃｅ＞タグを含むコンテンツ参照セクションの終りの部分である。）
　
（２）引用例発明について
　引用例記載事項によれば，引用例には，以下の発明（以下「引用例発明」という。）が記載されている。  
「消費者が，消費者プレーヤーでコンテンツ識別情報を受信し，セーブし，他の消費者に送るために，消費者が使用する軽量の機構を供給するものであって，
　コンテンツ参照が用いられ，
　コンテンツ参照は，
　コンテンツ自身から記述情報が分離され，
　記述情報は，消費者が消費者プレーヤーを使用して，コンテンツがどんなものであるか，そのコンテンツをどうしたら入手できるかを判断することができる情報を含み，
　実際のコンテンツは含んでおらず，
　ウェブサイトへのビジターである消費者は，コンテンツ参照をダウンロードし，参照サービスを通して配布サービスに導かれ，そこからコンテンツをダウンロードし，友人に電子メールを送ることができ，
　遠隔地で他の消費者とその経験を共有したい場合には，その消費者は，コンテンツ参照を電子メールへドラッグして，それを他の消費者に送ることができ，
　コンテンツ参照が遠隔地に到着すると，コンテンツ参照を開き，消費者プレーヤーは，もとのユーザである消費者のコンテンツが演奏されているのと同じ箇所で参照されたコンテンツの演奏をスタートさせることができ，
　コンテンツ参照を表示するために，拡張可能なマークアップ言語（ＸＭＬ）が使用され，
　コンテンツ参照のＸＭＬ文書には，コンテンツのタイトル，演奏家が含まれるもの。」
　
４−２．対比
　引用例発明と本願発明とを比較する。  
　ア　引用例発明の「コンテンツ」，「消費者プレーヤー」，「ダウンロード」，「タイトル」，「演奏家」，「友人や他の消費者のプレーヤー」は，それぞれ本願発明の「コンテンツデータ」，「データ端末装置」，「受信して記録すること」，「曲名」，「アーティスト」，「他のデータ端末装置」に相当する
　イ　引用例発明は，「ウェブサイトへのビジターである消費者は，コンテンツ参照をダウンロードし，参照サービスを通して配布サービスに導かれ，そこからコンテンツをダウンロード」するものである。
　してみると，引用例発明と本願発明とは，後記する点で相違するものの，「受信したコンテンツデータを記録」する点で共通する。
　ウ　引用例発明は，「コンテンツをダウンロードし，友人に電子メールを送ることができる」ものであり，「その消費者は，コンテンツ参照を電子メールへドラッグして，それを他の消費者に送ることができる」ものであり，「コンテンツ参照が遠隔地に到着すると，コンテンツ参照を開き，消費者プレーヤーは，もとのユーザである消費者のコンテンツが演奏されているのと同じ箇所で参照されたコンテンツの演奏をスタートさせることができる」ものであり，「コンテンツ参照を表示するために，拡張可能なマークアップ言語（ＸＭＬ）が使用され，コンテンツ参照のＸＭＬ文書には，コンテンツのタイトル，演奏家が含まれる」ものである。
　ここで，引用例発明の「友人に送られる電子メール」は，「ダウンロードしたコンテンツのタイトルと演奏家とを表示するための情報」が含まれることから，本願発明の「コンテンツメール」とは，「記録したコンテンツデータの曲名およびアーティスト名を含むコンテンツに係るメール」という概念に包摂される。
　してみると，引用例発明と本願発明とは，後記する点で相違するものの，「記録したコンテンツデータの曲名およびアーティスト名を含むコンテンツに係るメールを作成し，コンテンツに係るメールを他のデータ端末装置に送信」する点で共通する。
　
　してみると，引用例発明と本願発明とは以下の点で一致する。  
［一致点］  
「受信したコンテンツデータを記録し， 
　記録したコンテンツデータの曲名およびアーティスト名を含むコンテンツに係るメールを作成し， 
　コンテンツに係るメールを他のデータ端末装置に送信する， 
　データ端末装置。」  
 　  
　そして両者は以下の点で相違する。  
［相違点１］ 
　本願発明では，「コンテンツに係るメール」が「コンテンツメール」であるのに対し，引用例発明ではそのような構成になっていない点。 
［相違点２］ 
　本願発明では，コンテンツデータを記録手段に記録する記録部を有するのに対し，引用例発明ではそのような構成になっていない点。 
［相違点３］ 
　本願発明では，コンテンツメールを作成するためのメール作成部を有するのに対し，引用例発明ではそのような構成になっていない点。 
［相違点４］ 
　本願発明では，コンテンツメールを他のデータ端末装置に送信するための送信部を有するのに対し，引用例発明ではそのような構成になっていない点。
　　
４−３．判断
　以上の各相違点について以下に検討する。  
［相違点１について］ 
　本願発明の「コンテンツメール」は，発明の詳細な説明の【０１６６】段落の記載によれば，コンテンツ情報，つまり曲名およびアーティスト名をメールに付加したものである。
　友人に知らせたい情報をメールに付加することは，設計上の必要性に応じて当業者が適宜なし得る設計的事項である。（以下「設計的事項Ａ」という。） 
　してみると，引用例発明に設計的事項Ａを適用することにより，「コンテンツに係るメール」を「コンテンツメール」とすることには何ら困難性がなく，当業者が容易に想到することができたものである。
［相違点２〜４について］ 
　データ端末装置に，コンテンツデータを記録手段に記録する記録部を設け，メールを作成するためのメール作成部を設け，メールを他のデータ端末装置に送信するための送信部を設けることは，設計上の必要性に応じて当業者が適宜なし得る設計的事項である。（以下「設計的事項Ｂ」という。） 
　してみると，引用例発明に設計的事項Ｂを適用することにより，コンテンツデータを記録手段に記録する記録部を有するよう構成し，コンテンツメールを作成するためのメール作成部を有するよう構成し，コンテンツメールを他のデータ端末装置に送信するための送信部を有するよう構成することには何ら困難性がなく，当業者が容易に想到することができたものである。
（なお，メールを作成して送信するためのアルゴリズムが自動的なものである点については，後記の「４−４．」で判断する。）
　
　以上判断したとおり，本願発明における上記［相違点１］ないし［相違点４］に係る発明特定事項は，いずれも当業者が容易に想到することができたものであり，上記各相違点を総合しても，想到することが困難な格別の事項は見いだせない。  
　また，本願発明の作用効果も，引用例発明及び設計的事項から当業者が予測できる範囲のものである。  
　したがって，本願発明は，引用例発明及び設計的事項に基づいて，当業者が容易に発明をすることができたものである。
 　 
４−４．審判請求人の主張について
　審判請求人は，平成２３年７月２８日付けの意見書で，以下のとおり主張している。
　
（ア）「これに対し，拒絶引用例１には，ダウンロードするための必要情報として，コンテンツのタイトル及び演奏家に関する記載がありますが，これはあくまでもコンテンツをダウンロードするために利用するものであって，コンテンツデータの曲名およびアーティスト名をメール送信することについては全く想定されていません。」
（イ）「この点につき，審判官殿のご見解では，「友人に知らせたい情報をメールに付加することは，設計上の必要性に応じて当業者が適宜なし得る設計的事項である。（以下「設計的事項Ａ」という。）してみると，引用例１発明に設計的事項Ａを適用することにより，「コンテンツに係るメール」を「コンテンツメール」とすることには何ら困難性がなく，当業者が容易に想到することができたものである。」と御指摘され，さらに，「データ端末装置に，コンテンツデータを記録手段に記録する記録部を設け，メールを作成するためのメール作成部を設け，メールを他のデータ端末装置に送信するための送信部を設けることは，設計上の必要性に応じて当業者が適宜なし得る設計的事項である。（以下「設計的事項Ｂ」という。）してみると，引用例１発明に設計的事項Ｂを適用することにより，コンテンツデータを記録手段に記録する記録部を有するよう構成し，コンテンツメールを作成するためのメール作成部を有するよう構成し，コンテンツメールを他のデータ端末装置に送信するための送信部を有するよう構成することには何ら困難性がなく，当業者が容易に想到することができたものである。」と御指摘されました。」
（ウ）「しかしながら，友人に知らせたい情報をメールに付加することはユーザの自由意思であり，言い換えれば，タイトル及び演奏家に関する情報を書かなくても全く問題ありません。
　すなわち，拒絶引用例１には，本願発明における「記録手段に記録したコンテンツデータの曲名およびアーティスト名を含むコンテンツメールを作成するメール作成部」に関する記載が無く，また，そのような構成を想到するための示唆や必要性もありません。」
（なお，（ア）〜（ウ）は，審理を整理するために当審で付加したものである。）
　
（１）審判請求人の上記（ア）の主張を以下に検討する。
　引用例発明の，コンテンツのタイトル及び演奏家に関する必要情報の記載は，ダウンロードをするための必要情報としてのものであるのみならず，これを含む情報がメール送信されるものであることは，前記「４−１．（２）」で判断したとおりである。
　したがって，審判請求人の上記（ア）の主張を採用することはできない。
　
（２）審判請求人の上記（イ），（ウ）の主張を以下に検討する。
　ア　本願の発明の詳細な説明には，以下の記載がある。
（ア）「【００１４】
【発明が解決しようとする課題】しかし，コンテンツデータを配信する従来のシステムにおいては，
サーバからダウンロードしたコンテンツデータのタイトル，およびアーティスト名等，コンテンツデータの関連情報であるコンテンツ情報を他人に送信したり，他人から受信したりすることがなく，ユーザ間でコンテンツ情報をやり取りすることができないという問題があった
【００１５】そこで，
本発明は，かかる問題を解決するためになされたものであり，その目的は，ユーザ間でコンテンツ情報を自由にやり取りすることができるデータ配信システムおよびそのデータ配信システムに用いられるデータ端末装置を提供することである
（イ）「【００２１】したがって，
この発明によれば，データ端末装置は，自動的にコンテンツメールを作成し，他の端末装置へコンテンツメールを送信するので，表示機能や操作機能の乏しい端末装置におけるユーザの負荷を軽減できるとともに，コンテンツメールを受取った他の端末装置のユーザはタグに基づいてコンテンツデータの配信をサーバへ要求することができる。その結果，ユーザの負荷を一層軽減できる
（ウ）「【００９３】
携帯電話機１００は，さらに，外部からの指示を携帯電話機１００に与えるためのキー操作部１１０８
とを含む
（エ）「【０１０１】
携帯電話機１００は，さらに，配信サーバ１０から配信されたコンテンツデータのコンテンツ情報４２０をメール文に付加してコンテンツメールを作成するメール作成部１２２６を含む
（オ）「【０１１７】まず，
携帯電話ユーザの携帯電話機１００から，携帯電話ユーザによるキー操作部１１０８のキーボタンの操作等によって，配信リクエストがなされる
（カ）「【０１４４】次に，図１２および図１３を参照してメモリカード１１０に配信されたコンテンツデータの携帯電話機１００における再生動作について説明する。図１２を参照して，再生動作の開始とともに，
携帯電話機１００のユーザからキー操作部１１０８を介して再生指示が携帯電話機１００にインプットされる
（キ）「【０１６３】本発明においては，携帯電話機１００は，配信サーバ３０から暗号化コンテンツデータ｛Ｄａｔａ｝Ｋｃをメモリカード１１０に受信した後，
携帯電話機１００のユーザからの要求に応じて
コンテンツ情報をメールに付加してコンテンツメールを作成し，その作成したコンテンツメールを他の携帯電話機に送信する
（ク）「【０１６６】
図１５を参照して，携帯電話機１００が携帯電話網２０を介して携帯電話機１２０へコンテンツ情報をメールに付加したコンテンツメールを送信する動作について説明する
携帯電話機１００のユーザからキー操作部１１０８を介してコンテンツ情報の配信要求が入力される
ファイルシステムの管理情報を参照してファイルヘッダ４１０を読出す
アーティスト名および曲名は，コンテンツファイルのコンテンツ情報４２０に含まれる
【０１６７】携帯電話機１００のコントローラ１１０６は，ファイルヘッダ４１０を読出した後，コンテンツ情報４２０の読出要求をメモリインタフェース１２００を介してメモリカード１１０へ出力する。そうすると，メモリカード１１０のコントローラ１４２０は，端子１２０１およびバスＢＳ３を介してコンテンツ情報４２０の読出要求を受取り，メモリカード１１０上に構築されたファイルシステムの管理情報を参照しながらメモリ１４１５から
コンテンツ情報４２０を読出す
携帯電話機１００のコントローラ１１０６は
コンテンツ情報４２０を受取り
コンテンツ情報４２０をメール作成部１２２６へ出力する
【０１６８】
メール作成部１２２６は，コンテンツ情報４２０をバスＢＳ２を介して受取り，コンテンツ情報４２０であるアーティスト名および曲名を，字間，字体等を整えながらメール本体に付加してコンテンツメールを作成し，コンテンツメールを出力する
コンテンツメールに次々とコンテンツ情報４２０が追加される
【０１６９】
メモリカード１１０から全てのファイルヘッダ４１０が読出されたと判断されると
メール作成部１２２６から出力されたコンテンツメールをバスＢＳ２を介して受取り
送受信部１１０４へコンテンツメールを出力する
送受信部１１０４は，アンテナ１１０２を介してコンテンツメールを送信し
携帯電話網２０はコンテンツメールをメールサーバ１５０へ送る
　イ　本願の発明の詳細な説明の上記（ア）〜（ク）の記載を参照すると，審判請求人は，引用例発明は，消費者が，（電子メールを起動して）コンテンツ参照を電子メールへドラッグし，（消費者が）他の消費者へ送信するのに対し，本願発明は，ユーザが，携帯電話機のキー操作部でコンテンツ情報の配信を要求すると，携帯電話機は以降自動的に，そのコントローラがコンテンツ情報をメール作成部へ出力し，メール作成部はコンテンツメールを出力し，（これを繰り返して）全てのコンテンツ情報が処理されると，（ユーザが操作することなく）メール作成部から出力されたコンテンツメールが送信部へ出力されて送信されること，つまり本願発明は引用例発明とは，メールを作成して送信するためのアルゴリズムが自動的なものであって異なることを主張している。
　ウ　しかし，メールを作成して送信するためのアルゴリズムが自動的なものであって，引用例発明とは異なることを本願発明は特定しない。
　エ　したがって，審判請求人の上記（イ），（ウ）の主張は，特許請求の範囲の記載に基づかない主張であるから，これを採用することはできない。
 　 
４−５．進歩性に関する結論
　したがって，本願発明は，引用例発明及び設計的事項に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
　  
４−６．まとめ
　以上のとおり，本願発明は，引用例発明及び設計的事項に基づいて，当業者が容易に発明をすることができたものであり，発明の効果についてみても，引用例発明及び設計的事項から予測される範囲のものにすぎない。  
  
５．むすび
　以上のとおり，本願発明は，引用例発明及び設計的事項に基づいて，当業者が容易に発明をすることができたものであり，特許法第２９条第２項の規定により特許を受けることができない。  
　したがって，本願は当審で通知した上記拒絶理由によって拒絶されるべきものである。  　 
　よって，結論のとおり審決する。