【事件の表示】
　特願２００４−３０６２２２「移動体通信端末及びマルチメディアメッセージ用情報処理装置」拒絶査定不服審判事件〔平成１８年　５月１１日出願公開、特開２００６−１１９８５３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１　手続の経緯
　本願は、平成１６年１０月２０日の出願であって、平成２１年１１月１８日付けで拒絶をすべき旨の査定がされ、これに対し平成２２年２月２２日に拒絶査定不服審判の請求がなされ、その後、当審において通知した平成２３年６月２４日付けの拒絶の理由に対して、同年８月２９日付けで意見書が提出されるとともに、同日付けで手続補正がなされたものである。
　
２　本願発明
　本願の請求項１に係る発明（以下「本願発明」という。）は、平成２３年８月２９日付けの手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「通信ネットワークを介してマルチメディアメッセージ用情報処理装置から、複数のメディアタイプのデータを含めることができるマルチメディアメッセージの着信通知を受信する移動体通信端末であって、
　通信ネットワークを介してマルチメディアメッセージ用情報処理装置から、該マルチメディアメッセージの差出人及び件名の情報とともに該マルチメディアメッセージのメッセージ本文の少なくとも一部を含む着信通知を、その着信通知が分割された所定サイズの複数の分割データそれぞれを含む複数のＳＭＳによって受信する通信手段と、
　該通信手段で受信した着信通知の受信データを記憶する記憶手段と、
　該メッセージ本文の少なくとも一部を含む着信通知の受信データを出力する出力手段と、該通信手段及び該出力手段を制御する制御手段とを備え、
　上記着信通知の受信データは、その着信通知に上記マルチメディアメッセージのメッセージ本文の全体が含まれているか否かを識別するための、該メッセージ本文の文末識別情報を有し、
　上記制御手段は、上記文末識別情報に基づいて上記着信通知に上記マルチメディアメッセージのメッセージ本文の全体が含まれているか否かを判断し、
　上記文末識別情報は、上記着信通知が分割されＳＭＳで送信される上記複数の分割データそれぞれのヘッダーに設定した上記メッセージ本文の文末有無判断用フィールドの１ビットのフラグデータであることを特徴とする移動体通信端末。」
　
３　当審の拒絶の理由
　当審において通知した平成２３年６月２４日付けの拒絶の理由の概要は、本願発明は、国際公開２００４／０２１２３２号（２００４年３月１１日国際公開。以下「引用例」という。）に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない、というものである。
　
４　引用例の記載
　引用例には、図面とともに次の事項が記載されている。
　
ア　「The present invention relates to a method and a system for the retrieval of data. More in particular, the present invention relates to a method of retrieving electronic messages, such as e-mail messages, from a server. 
　　　Electronic messages intended for a particular recipient are typically stored on a server from where the recipient can retrieve her messages. The stored messages are kept in an electronic mail box which can be remotely accessed. To this end, the recipient's user device or terminal establishes a connection with the server. This connection may involve a telephone dial-in connection, an ADSL connection or a wireless connection. The time required for retrieving the message depends on the bandwidth of the connection and the size (number of bytes) of the message. 
Messages that only contain plain text usually require relatively little time to retrieve, unless the text is very long and/or the bandwidth is limited, as may be the case when a wireless connection of relatively poor quality is used. Electronic messages are sometimes so large (that is, consist of so many bytes) that their retrieval takes half an hour or more, which obviously is inconvenient. Extremely large messages can sometimes prove impossible to retrieve.」（１頁３〜１８行）（当審訳（引用例の日本語ファミリである特表２００５−５３６９６２号公報の記載を参考に当審が作成。以下同様。）：本発明は、データを取得する方法及びシステムに関する。より詳細には、本発明は、電子メール・メッセージのような電子的メッセージをサーバから取得する方法に関する。
　特定の受信者に宛てられた電子的メッセージは、典型的には、サーバに格納され、受信者は該サーバから自分のメッセージを取得することが可能である。格納されたメッセージは、リモートからアクセス可能な電子的メール・ボックスに保持される。このため、受信者のユーザ装置又は端末は、サーバとの接続を確立する。この接続には、電話によるダイアル・イン接続、ＡＤＳＬ接続又は無線接続が含まれ得る。メッセージの取得に要する時間は、接続の帯域幅とメッセージのサイズ（バイト数）に依存する。単純なテキストのみを含むメッセージは、テキストが非常に長かったり、及び／又は、比較的品質の悪い無線接続を利用している場合などのように帯域幅が制限されていたりしない限り、通常は比較的短い時間で取得できる。電子的メッセージは、場合によっては非常に大きく（即ち、多くのバイト数からなっていて）、取得に３０分又はそれ以上かかることがあるが、これは明らかに不便である。過剰に大きなメッセージは、場合によっては、取得が不可能であることもある。）
　
イ　「This known method has the advantage that the overall size of the message is considerably reduced by the removal of the attachments. In addition, a rendering device can be selected which is suitable for the specific type of attachment. However, this known method has the disadvantage that it leaves the body of the message, that is the text part, unaffected. Particularly long message bodies can still take an undesirably long time to retrieve. In addition, rendering the attachments on a different device from the user device may be impractical as the user may not be in the vicinity of such a device. 
　　　It is an object of the present invention to overcome these and other problems of the Prior Art and to provide a method of and a system for retrieving electronic messages which even further reduces the transmission time required. 
　　　Accordingly, the present invention provides a method of retrieving an electronic message from a server using a terminal device, the message comprising a header and a body capable of containing characters, the method comprising the steps of : 
　・establishing a communications link between the server and the terminal device, 
　・the server transmitting the header and the first N characters of the body to the terminal device, where N is a predetermined integer, while holding back any remaining characters of the body and any attachments, 
　・the server transmitting a flag indicative of any remaining characters of the body and/or any attachments to the terminal device. 
　　　By not transmitting the attachments with the initial message, an important time and bandwidth saving is achieved. By additionally limiting the body of the initial message to N characters, where N may be any suitable number such as 100 or 1000, a further time and bandwidth reduction is achieved. By additionally transmitting a flag indicative of any remaining parts of the message, the user can selectively retrieve the electronic message in consecutive phases.」（１頁２４行〜２頁２０行）（当審訳：この既知の方法は、添付ファイルを取り除くことによりメッセージの全体としてのサイズが相当に低減されるという利点を有する。更に、特定の種別の添付ファイルに適した提示装置を選択することができる。しかしながら、この既知の方法は、テキスト部分であるメッセージの本文は影響を受けずにそのままであるという不都合を有する。特に長いメッセージ本文では、取得のために、望ましくない長い取得時間がかかり得る。更に、ユーザ装置とは異なる装置に添付ファイルを提示することは、ユーザがそのような装置の近くにいないかもしれないために、非実用的であり得る。
　本発明の目的は、従来技術のこれらの及び他の問題点を克服し、必要とされる送信時間を更に低減するような、電子的メッセージの取得方法及びシステムを提供することである。
　従って、本発明は、端末装置を用いてサーバからヘッダと文字を含む本文とを備える電子的メッセージを取得する方法を提供し、該方法は、
　サーバと端末装置との間の通信リンクを確立するステップと、
　サーバが、ヘッダと本文の最初のＮ個の文字（Ｎは所定の整数）とを、本文の任意の残りの文字と任意の添付ファイルとを保持したままで端末装置に送信するステップと、
　サーバが、本文の任意の残りの文字及び／又は任意の添付ファイルを示すフラグを端末装置に送信するステップと
を含む。
　添付ファイルを最初のメッセージとともに送信しないことにより、貴重な時間及び帯域の節約が実現される。更に、最初のメッセージの本文をＮ個の文字（Ｎは１００又は１０００のような適切な数値であり得る）に制限することにより、更なる時間及び帯域の低減が達成される。更に、メッセージの任意の残りの部分を示すフラグを送信することにより、ユーザは、電子的メッセージを連続的な「段階」において選択的に取得することが可能である。）
　
ウ　「The system 10 shown merely by way of non-limiting example in Fig. 1 comprises a user terminal 1, a server 2, a communications network 3, and remote units 4. The terminal 1 is operated by a user 5. 
　　　The terminal 1 may be a mobile telephone device, a PDA (Personal Digital Assistant) having communications facilities, a laptop or desktop computer having communications facilities, or any other suitable device. The terminal 1 preferably is a handheld device having a screen and being capable of mobile data communications, for example but not limited to a GSM device having i-mode capabilities. 
　　　The server 2 may be any suitable commercially available server capable of handling electronic messages, such as e-mail messages. The server 2 preferably is capable of supporting i-mode data communications. A communications network 3 is coupled to the server 3 and to remote units 4. The network 3 may be any suitable network, such as the Internet, a LAN (Local Area Network) or a WAN (Wide Area Network). The remote units 4 may be further servers which may, for example, produce electronic messages destined for the user 5. 
　　　A communications link 6 can be established between the terminal 1 and the server 2 using, for example, antennas 7. The link 6 allows messages to be exchanged between the server 2 and the terminal 3. It will be understood that it is not necessary for the link to be continuous as long as the link 6 allows data to be exchanged between the server 2 and the terminal at certain intervals. 
　　　The link 6 is preferably, but not necessarily, at least partially mobile (cellular), that is, wireless. Such communications links typically have a limited bandwidth which may be further reduced by interferences due to bad weather, buildings blocking the transmission path, and other adverse influences. It will be clear that the transmission time required for a message depends on the available bandwidth and the length of the message: when bandwidth is limited, relatively long messages will require a substantial transmission time, which is not always acceptable. 
　　　An exemplary e-mail message as may be used in the system 10 is schematically presented in Fig. 2. The message 20 comprises a header 21, a body 22 and attachments 23. The header 21 contains transmission information such as the origin and the destination of the message. The attachments 23 may contain images, sound items, text documents, and other parts of the message which are not part of the body 22. The number of attachments may of course vary and any message may have a single attachment, several attachments or no attachments at all. 
　　　The body 22 of the message 20 contains text characters 24. The length of the body 22 may vary as some messages contain no text at all (e. g. only a header and possibly one or more attachments) whereas other message bodies contain thousands of characters.  　　　In accordance with the present invention the transmission time of electronic messages is drastically reduced by substantially reducing the length of the message (it is noted that the length of the message, as this term is used here, may be interpreted as the total number of bytes of the message). This is accomplished by: 
　・removing any attachments,
　・shortening the body of the message, and
　・initially sending the message header and the shortened body only, 
while saving any removed parts of the message for later retrieval, if desired. The transmission of the message is therefore broken down into separate phases: an initial phase in which only the message header and the shortened message body is transmitted, and optional second and subsequent phases in which the remainder of the message body (or part of the remainder) and/or any attachments are retrieved. To facilitate the retrieval in the second (and any subsequent) phase, the server (2 in Fig. 1) may transmit flags to the terminal, a first flag indicating whether any remainder of the message body is available and at least one second flag indicating the availability of any attachments. 
　　　As schematically shown in Fig. 2, the message body 22 may be shortened to N characters where N is, for example, equal to 1000. This results in a shortened message body 22a and a remainder 22b. In accordance with the present invention, initially only the shortened body 22a is transmitted, the remainder 22b (as well as any attachments 23) being retained by the server. 
　　　It will be understood that the number N may be 20,100, 500,512, 1000, 1024,4096 or any other suitable number. The number N may be determined by the user or by her terminal 1, but in a preferred embodiment the number N is determined by the server 2. Any remainder of the message body may, upon transmission, also be limited to the number N, or be limited to another suitable number. A long message body may be retrieved in more than two phases, the number of characters retrieved in each phase being equal to N, P, Q, etc. respectively, where P and Q are not necessarily equal to N. 
　　　Although it is preferred that the shortened message body has a maximum number of N characters, embodiments can be envisaged in which a maximum number of lines, words or sentences is defined. 
　　　An embodiment of the method of the present invention is schematically illustrated in the flow diagram of Fig. 3. In step 101 the communications link (6 in fig. 1) between the server and the terminal is established. In step 102 the server (2 in Fig. 1) transmits the header, the shortened message body and any flags to the terminal (1 in Fig. 1). In step 103, the terminal presents a message identification (ID) to the user. The message identification may, for example, be a subject line and/or the entire shortened message body. 
　　　In step 104, it is determined whether any flags are present. If no flags have been received, the message is complete and the transmission is finished. If there is at least one flag, it is presented to the user in step 105. The user may then select a message part identified by a flag in step 106. If a flag was selected, the terminal sends a request to the server for the retrieval of the selected message part (s) and the server responds by transmitting the requested message part in step 107. The corresponding flag (s) is/are deleted and the routine returns to step 104. The routine ends when no more flags are available or when no more flags are selected by the user. 
　　　The message identification (ID) mentioned above and which is used to provide a message identification to the user may be used during the method described above to uniquely identify the message and its parts. That is, in any exchange of information between the server and the terminal, the message ID may be used to retrieve further parts of a message, all parts of the same message having the same message ID. When a new message is to be retrieved, either phased or in full, the message ID is typically not available to the terminal prior to the retrieval. 
　　　The server may be arranged for deleting a message once it is completely transmitted. The server may also delete a message which is only partially transmitted but for which no further retrieval requests are received within a certain time period. 
　　　A flag as used in the present invention is schematically illustrated in Fig. 4. The flag 30 comprises a first section (first flag) 31 and a second section (second flag) 32. The first flag 31 is indicative of any remaining characters, that is, any remaining part of the body (22 in Fig. 2) of the message (20 in Fig. 2). For example, the flag may be1if there are remaining characters and0if there are no remaining characters. 
　　　The second flag 32 is indicative of any (remaining) attachments (23 in Fig. 2). The second flag may contain sub-flags (not shown), each identifying an individual attachment. Embodiments can be envisaged in which the second flag is not sent to the terminal if the message has no attachments, or if all attachment have already been retrieved. Similarly, embodiments can be envisaged in which no flag at all is sent to the terminal. This may be the case when the message contains less than N characters and has no attachments. However, it is preferred to send a flag, if only the first flag, to indicate whether or not any remaining message parts are retrievable.」（６頁１７行〜１０頁２行）（当審訳：　図１に非限定的な例としてのみ示されるシステム１０は、ユーザ端末１、サーバ２、通信ネットワーク３、及び遠隔ユニット４を含む。端末１はユーザ５により操作される。
　端末１は、携帯電話機、通信機能を有するＰＤＡ（個人情報端末）、通信機能を有するラップトップ又はデスクトップのコンピュータ、或いは任意の他の適切な装置であり得る。端末１は、画面を備え、移動データ通信が可能なハンドヘルド装置であることが望ましく、例えばｉ−ｍｏｄｅ（登録商標）機能を有するＧＳＭ装置であるが、それに限定されるものではない。
　サーバ２は、電子メール・メッセージのような電子的メッセージを処理することができる任意の適切な商業的に入手可能なサーバであり得る。サーバ２は、ｉ−ｍｏｄｅ（登録商標）によるデータ通信をサポート可能であることが望ましい。通信ネットワーク３は、サーバ３及び遠隔ユニット４に結合される。ネットワーク３は、インターネット、ＬＡＮ（ローカル・エリア・ネットワーク）又はＷＡＮ（広域ネットワーク）のような任意の適切なネットワークであり得る。遠隔ユニット４は、例えばユーザ５に宛てた電子的メッセージを生成し得るような、更なるサーバであり得る。
　通信リンク６は、例えばアンテナ７を用いて、端末１及びサーバ２の間に確立され得る。リンク６は、サーバ２と端末３とのメッセージ交換を可能とする。リンク６が特定の間隔でサーバ２と端末とのデータ交換を可能とする間ずっと、リンクが途切れないものである必要はないことが理解される。
　リンク６は、少なくとも部分的に移動（セルラー式）即ち無線であることが望ましいが、必ずしもそうでなくてもよい。そのような通信リンクは、典型的に、悪天候による干渉、通信経路を遮蔽する建築物及び他の悪影響により更に低減され得るような限られた帯域を有する。メッセージに必要な通信時間は、利用可能な帯域及びメッセージの長さに依存することが明らかである。帯域が限られている場合、比較的長いメッセージは、常には受け入れ難いようなかなりの通信時間を要する。
　図２は、システム１０において利用され得る例としての電子メール・メッセージを概略的に示す。メッセージ２０は、ヘッダ２１、本文２２及び添付ファイル２３を含む。ヘッダ２１は、メッセージの送信元及び宛て先などの送信情報を含む。添付ファイル２３には、画像、音声、テキスト文書、及び本文２２の一部ではないメッセージの他の部分が含まれ得る。添付ファイルの数は、もちろん変動し得る。任意のメッセージは、１つの添付ファイル又は幾つかの添付ファイルを有し、或いは添付ファイルを全く有さないこともあり得る。
　メッセージ２０の本文２２は、テキスト文字２４を含む。本文２２の長さは、テキストを全く含まないメッセージ（ヘッダ及び場合によっては１つ又はそれ以上の添付ファイルのみ）もあれば、何千文字も含むメッセージ本文もあるというように変動し得る。
　本発明によれば、電子的メッセージの送信時間は、メッセージの長さを実質的に低減することにより劇的に低減される（本明細書で使用されるメッセージの長さという用語は、メッセージの総バイト数と解釈され得ることに注意すべきである）。これは、
　全ての添付ファイルを取り除くステップと、
　メッセージの本文を短くするステップと、
　メッセージの任意の取り除かれた部分を要望に応じた後の取得のために蓄積し、まずメッセージのヘッダ及び短くされた本文のみを送信するステップと、
により実現される。メッセージの送信は、従って、別々の段階に分割される。即ち、メッセージのヘッダ及び短くされたメッセージ本文のみが送信される第１段階と、メッセージ本文の残り（又は残りの一部）及び／又は添付ファイルが取得されるオプションとしての第２及びそれ以降の段階とである。第２（及び任意のそれ以降の）段階における取得を促進するために、サーバ（図１の２）は、メッセージ本文の残りがあるか否かを示す第１のフラグと、添付ファイルがあるか否かを示す少なくとも１つの第２のフラグとからなるフラグを端末に送信し得る。
　図２に概略的に示されるように、メッセージ本文２２は、例えば１０００と等しいＮ個の文字に短くされ得る。これにより、短くされたメッセージ本文２２ａと残り２２ｂが生ずる。本発明によれば、まず短くされた本文２２ａのみが送信され、残り２２ｂ（及び添付ファイル２３）はサーバに保持される。
　数値Ｎは、２０、１００、５００、５１２、１０００、１０２４、４０９６又は任意の他の適切な数値であってよいことが理解されるべきである。数値Ｎは、ユーザ又はユーザの端末１により決定され得るが、好ましい実施の形態において、数値Ｎはサーバ２により決定される。メッセージ本文の残りは、送信の際に、やはりＮ個の文字に制限され、又は、任意の他の適切な数に制限される。長いメッセージ本文は３つ以上の段階で取得されてもよく、各段階で取得される文字数はそれぞれＮ、Ｐ、Ｑ等であって、Ｐ及びＱは必ずしもＮと等しくなくてもよい。
　短くされたメッセージ本文は、Ｎという最大文字数を持つことが望ましいが、最大の行数、単語数又は文数が規定される実施の形態も考えられる。
　図３は、本発明に係る方法の実施の形態を概略的に示すフロー図である。ステップ１０１において、サーバと端末との間に通信リンク（図１の６）が確立される。ステップ１０２において、サーバ（図１の２）は、ヘッダ、短くされたメッセージ本文及び任意のフラグを端末（図１の１）に送信する。ステップ１０３において、端末は、ユーザにメッセージ識別子（ＩＤ）を提示する。メッセージ識別子は、例えば、主題の行及び／又は短くされたメッセージ本文全体であり得る。
　ステップ１０４において、フラグが提示されているか否かが判断される。フラグが受信されていない場合、メッセージは完全であり、送信は終了している。少なくとも１つのフラグがある場合、該フラグは、ステップ１０５においてユーザに提示される。すると、ユーザは、ステップ１０６において、フラグにより識別されるメッセージの部分を選択し得る。フラグが選択されると、端末は、選択されたメッセージ部分の取得要求をサーバに送信し、サーバは、ステップ１０７において、要求されたメッセージ部分を送信することにより応答する。対応する１つ又は複数のフラグが削除され、ルーチンはステップ１０４に戻る。ルーチンは、それ以上フラグがなくなった場合、又はそれ以上のフラグがユーザにより選択されなくなった場合に終了する。
　ユーザにメッセージ識別を提供するために利用される上記のメッセージ識別子（ＩＤ）は、上記の方法の期間に、メッセージ及びその部分を一意に識別するために利用され得る。即ち、サーバと端末との間における任意の情報の交換において、メッセージの更なる部分を取得するためにメッセージＩＤが利用され、同一のメッセージの全ての部分が、同一のメッセージＩＤを有する。新しいメッセージが段階的に又は全体で取得される場合、メッセージＩＤは、典型的に、取得前には端末にとって利用可能ではない。
　サーバは、メッセージが完全に送信されると、メッセージを削除するよう構成され得る。サーバは、また、部分的に送信されたのみであるが、特定の時間間隔内に更なる取得要求が受信されないメッセージを削除し得る。
　図４は、本発明において利用されるフラグを概略的に示す。フラグ３０は、第１の部分（第１のフラグ）３１と、第２の部分（第２のフラグ）３２とを備える。第１のフラグ３１は、任意の残りの文字、即ちメッセージ（図２の２０）の本文（図２の２２）の任意の残りの部分を示す。例えば、フラグは、残りの文字がある場合に「１」となり、残りの文字がない場合に「０」となり得る。
　第２のフラグ３２は、任意の（残りの）添付ファイル（図２の２３）を示す。第２のフラグは、それぞれが個別の添付ファイルを示すサブ・フラグ（図示せず）を含み得る。メッセージが添付ファイルを含まないか、全ての添付ファイルが既に取得されている場合には端末に第２のフラグが送信されない実施の形態も考えられる。同様に、端末にフラグが一切送信されない実施の形態も考えられる。これは、メッセージがＮ個の文字を含まず、添付ファイルを有さない場合であり得る。しかし、任意の残りのメッセージ部分が取得可能であるか否かを示す第１のフラグのみであるとしても、フラグを送信することが望ましい。）
　
エ　「A preferred embodiment of the present invention is based upon the i-mode mail protocol. In this embodiment, both full retrieval according to the Prior Art and phased retrieval according to the present invention are available. Existing parameters of the i-mode mail protocol are used to convey the additional information required. For example, the ATT parameter in the GET request and the X-EID header are used to distinguish between full retrieval and phased retrieval and to identify messages respectivley. An additional HTTP header, X-MP, is introduced to act as the flags of the present invention, that is, to allow the server to communicate to the client whether there are any remaining message parts. No changes to the syntax of the existing protocol are necessary. 
　　　When full retrieval of all new messages is required, the terminal sends a request in which ATT = ALL while the X-EID value in the GET command is equal to 00000: ALL indicates full retrieval while 00000 indicates all messages. In the response from the server the X-EID value identifies the current message and the next message. 
　　　When phased retrieval of all new messages is required, the terminal sends a request in which ATT = PH while the X-EID value in the GET command is again equal to 00000. Again, in the response from the server the X-EID value identifies the current message and the next message. If the current message is not fully retrieved because there are remaining parts on the server, the X-MP flags are set allowing the terminal device to alert the user to the possibility of downloading further parts of the message. When the retrieval of any remaining parts of the message is required, the X-EID value is used to identify the message while the ATT attribute may be used to indicate which part (s) is/are to be retrieved. 
　　　The retrieval of messages according to the present embodiment is schematically illustrated in the diagram of Fig. 5, which shows the data exchanged between the terminal 1 and the server 2 during the retrieval of a message xxxxx containing attachments and a message yyyyy which has less than N characters and which has no attachments. 
　　　In the non-limiting example of Fig. 5, a first step 201 is carried out upon the receipt of a mail notification or a manual retrieval command. In step 201, the terminal 1 sends the following data to the server: 
　　　　　　　　　　　GET ATT = PH 
　　　　　　　　　　　X-EID: 00000
indicating that phased retrieval (PH) is to be carried out and that all messages (00000) are to be (partially) retrieved. 
　　　In step 202 the server responds by sending the message xxxxx and the following data to the terminal: 
　　　　　　　　　　　HTTP/1. 1 200 OK 
　　　　　　　　　　　X-EID: xxxxx/yyyyy 
　　　　　　　　　　　X-MP: True 
where the value of X-EID indicates that the server is sending message xxxxx and has message yyyyy available, while the value of X-MP indicates that there are remaining parts of current message xxxxx (X-MP is True). In step 202, therefore, the server transmits partial message xxxxx to the terminal while storing the remainder of xxxxx. Note that in this embodiment, the server automatically transmits any available shortened message, in the present example xxxxx. Step 202 concludes by the terminal receiving message xxxxx and marking this message as partial in response to the (first) flag X-MP. 
　　　In step 203, the terminal issues an automatic request by transmitting the following data to the server: 
　　　　　　　　　　　GET ATT = PH 
　　　　　　　　　　　X-EID: xxxxx/yyyyy 
where the value of X-EID confirms the receipt of the data sent by the server. In response, the server marks message xxxxx as partially read and sends message yyyyy in step 204, also transmitting the following data: 
　　　　　　　　　　　HTTP/1. 1 200 OK 
　　　　　　　　　　　X-EID: yyyyy/EIEOF 
　　　　　　　　　　　X-MP: False 
where EIEOF indicates that there are no further messages and where X-MP: False indicates that there are no remaining parts. The terminal receives message yyyyy. 
　　　In step 205, the terminal issues an automatic request: 
　　　　　　　　　　　GET ATT = PH 
　　　　　　　　　　　X-EID: yyyyy/EIEOF 
which causes the server to delete message yyyyy, thus freeing storage space. Finally, the server sends in step 206 the following data to the terminal : 
　　　　　　　　　　　HTTP/1. 1 251 FIN 
　　　　　　　　　　　X-EID : 00000/00000 
which concludes the procedure. 
　　　It is noted that in step 206 no flag (X-MP) is transmitted as there are no remaining message parts. 
　　　Although the invention has been explained with specific reference to e-mail messages, it is noted that the invention is not so limited and that other messages, such as data messages, can be retrieved in the manner described above. 
　　　The present invention is based upon the insight that transmitting entire electronic messages may require too much time and/or bandwidth and that more effective use can be made of available resources by dividing messages, including message bodies, into parts which may be retrieved separately. The present invention benefits from the further insight that a user may not wish to retrieve all parts of a message, thus further reducing the time and bandwidth required.」（１０頁３行〜１２頁１９行）（当審訳：　本発明の好ましい実施の形態は、ｉ−ｍｏｄｅ（登録商標）メール・プロトコルに基づく。この実施の形態では、従来技術による全体の取得、及び本発明に係る段階的な取得の両方が利用可能である。ｉ−ｍｏｄｅ（登録商標）メール・プロトコルの既存のパラメータは、必要な追加情報を伝達するために利用される。例えば、ＧＥＴリクエストにおけるＡＴＴパラメータ、及びＸ−ＥＩＤヘッダは、それぞれ、全体の取得と段階的な取得とを区別するため、及び、メッセージを識別するために利用される。追加のＨＴＴＰヘッダであるＸ−ＭＰは、本発明のフラグとして振舞うよう、即ち、残りのメッセージ部分があるか否かをサーバがクライアントに通信可能とするよう導入される。既存のプロトコル・シンタックスの変更は不要である。
　新しいメッセージの全体の取得が要求される場合、端末は、ＡＴＴ＝ＡＬＬであり、ＧＥＴコマンド内のＸ−ＥＩＤ値が０００００である要求を送信する。ＡＬＬは全体の取得を示し、０００００は全てのメッセージを示す。サーバからの応答において、Ｘ−ＥＩＤ値は現在のメッセージ及び次のメッセージを識別する。
　全ての新しいメッセージの段階的な取得が要求される場合、端末は、ＡＴＴ＝ＰＨであり、ＧＥＴコマンド内のＸ−ＥＩＤ値がやはり０００００である要求を送信する。この場合も、サーバからの応答におけるＸ−ＥＩＤ値は、現在のメッセージ及び次のメッセージを識別する。サーバに残りの部分があるために現在のメッセージが完全に受信されない場合、メッセージの更なる部分のダウンロードの可能性があることを端末装置がユーザに警告することを可能とするＸ−ＭＰフラグが設定される。メッセージの任意の残りの部分の取得が要求されると、Ｘ−ＥＩＤ値はメッセージを識別するために利用され、ＡＴＴ属性はどの部分が取得されるべきかを示すために利用され得る。
　本発明の実施の形態におけるメッセージの取得は、添付ファイルを含むメッセージｘｘｘｘｘとＮ個の文字を含まず且つ添付ファイルを有さないメッセージｙｙｙｙｙとの取得期間に端末１とサーバ２との間で交換されるデータを示す図５に概略的に示される。
　図５の非限定的な例において、第１のステップ２０１は、メール通知又は手動による取得コマンドの受信に際して実行される。ステップ２０１において、端末１は、段階的な取得（ＰＨ）が実行されてメッセージ全体（０００００）が（部分的に）取得されるべきことを示す以下のデータをサーバに送信する。即ち、
ＧＥＴ　ＡＴＴ＝ＰＨ
Ｘ−ＥＩＤ：０００００
である。
　ステップ２０２において、サーバは、メッセージｘｘｘｘｘ及び以下のデータを端末に送信することにより応答する。即ち、
ＨＴＴＰ／１．１　２００　ＯＫ
Ｘ−ＥＩＤ：ｘｘｘｘｘ／ｙｙｙｙｙ
Ｘ−ＭＰ：Ｔｒｕｅ
であり、Ｘ−ＥＩＤの値はサーバがメッセージｘｘｘｘｘを送信しておりメッセージｙｙｙｙｙを有していることを示し、Ｘ−ＭＰの値は現在のメッセージｘｘｘｘｘの残りの部分があること（Ｘ−ＭＰがＴｒｕｅであること）を示す。従って、ステップ２０２において、サーバは、ｘｘｘｘｘの残りを蓄積したまま、部分的なメッセージｘｘｘｘｘを端末に送信する。この実施の形態において、サーバは、この例ではｘｘｘｘｘであるような任意の短くされたメッセージを自動的に送信することに注意すべきである。ステップ２０２は、端末がメッセージｘｘｘｘｘを受信し、（第１の）フラグＸ−ＭＰに応じて、このメッセージを部分的なものであると印付けることにより終了する。
　ステップ２０３において、端末は、以下のデータをサーバに送信することにより、自動的な要求を発行する。即ち、
ＧＥＴ　ＡＴＴ＝ＰＨ
Ｘ−ＥＩＤ：ｘｘｘｘｘ／ｙｙｙｙｙ
であり、Ｘ−ＥＩＤの値は、サーバから送られたデータの受信を確認する。それに応じて、サーバは、メッセージｘｘｘｘｘを部分的に読まれたものと印付け、ステップ２０４において、以下のデータとともにメッセージｙｙｙｙｙを送信する。即ち、
ＨＴＴＰ／１．１　２００　ＯＫ
Ｘ−ＥＩＤ：ｙｙｙｙｙ／ＥＩＥＯＦ
Ｘ−ＭＰ：Ｆａｌｓｅ
であり、ＥＩＥＯＦは更なるメッセージがないことを示し、Ｘ−ＭＰ：Ｆａｌｓｅは残りの部分がないことを示す。端末はメッセージｙｙｙｙｙを受信する。
　ステップ２０５において、端末は自動的な要求を発行する。即ち、
ＧＥＴ　ＡＴＴ＝ＰＨ
Ｘ−ＥＩＤ：ｙｙｙｙｙ／ＥＩＥＯＦ
であり、これによりサーバはメッセージｙｙｙｙｙを削除して、記憶領域を解放する。最後に、サーバは、ステップ２０６において、以下のデータを端末に送信する。即ち、
ＨＴＴＰ／１．１　２５１　ＦＩＮ
Ｘ−ＥＩＤ：０００００／０００００
であり、これにより処理が終了する。
　残りのメッセージ部分がないため、ステップ２０６ではフラグ（Ｘ−ＭＰ）が送信されないことに注意すべきである。
　本発明を特に電子メール・メッセージについて説明したが、本発明はそのように限定されるものではなく、データ・メッセージのような他のメッセージが上記の方法で取得され得ることに注意すべきである。
　本発明は、電子的メッセージ全体の送信には余りに長い時間及び／又は余りに広い帯域を必要とし、メッセージ本文を含むメッセージを別々に取得され得る部分に分割することにより、利用可能な資源の一層効率的な利用ができるとの知見に基づく。本発明は、ユーザがメッセージの全ての部分を取得したいとは望まないかもしれないという更なる知見の恩恵を受けており、そのために、必要とされる時間及び帯域を更に低減することができる。）
　
　以上の記載によれば、引用例には、次の発明（以下「引用発明」という。）が記載されている。
　
「ユーザ端末、サーバを含むシステムにおいて、
　ユーザ端末は、画面を備え、移動データ通信が可能な携帯電話機であり、
　サーバは、メッセージを処理することができ、
　通信リンクは、アンテナを用いて、ユーザ端末及びサーバの間に確立され、また、少なくとも部分的に移動（セルラー式）即ち無線であり、
　メッセージは、ヘッダ、本文及び添付ファイルを含み、
　ヘッダは、メッセージの送信元及び宛て先などの送信情報を含み、
　本文は、テキスト文字を含み、
　添付ファイルには、画像、音声、テキスト文書、及び本文の一部ではないメッセージの他の部分が含まれ、
　第１のフラグは、ＨＴＴＰヘッダに設けられ、また、本文の残りの文字を示し、残りの文字がある場合に「１」となり、残りの文字がない場合に「０」となり、
　サーバが、メッセージの全ての添付ファイルを取り除き、メッセージの本文を本文の最初のＮ個の文字にし、本文の残りの文字と添付ファイルとを保持し、
　サーバとユーザ端末との間に通信リンクが確立され、
　サーバは、ヘッダ、本文の最初のＮ個の文字及び第１のフラグをユーザ端末に送信し、
　ユーザ端末は、ユーザにメッセージ識別子を提示し、また、メッセージ識別子は、主題の行及び本文の最初のＮ個の文字であり、
　第１のフラグが「０」である場合、メッセージは完全であり、送信は終了し、
　第１のフラグが「１」である場合、第１のフラグは、ユーザに提示され、第１のフラグが選択されると、ユーザ端末は、本文の残りの文字の取得要求をサーバに送信し、サーバは、要求された本文の残りの文字を送信することにより応答する
　システム。」
　
５　対比
　本願発明と引用発明を対比する。
　引用発明の「通信リンク」は、本願発明の「通信ネットワーク」に相当する。
　引用発明の「メッセージ」と本願発明の「マルチメディアメッセージ」は、「メッセージ」である点で一致する。
　引用発明において、サーバはメッセージを処理することから、引用発明の「サーバ」と本願発明の「マルチメディアメッセージ用情報処理装置」は、「メッセージ用情報処理装置」である点で一致する。
　引用発明の「ヘッダ、本文の最初のＮ個の文字及び第１のフラグ」は、メッセージの着信通知に該当することが明らかであるから、本願発明の「着信通知」に相当する。
　引用発明の「ユーザ端末」は、携帯電話機であるから、本願発明の「移動体通信端末」に相当する。
　引用発明において、サーバとユーザ端末との間に通信リンクが確立され、サーバは、ヘッダ、本文の最初のＮ個の文字及び第１のフラグをユーザ端末に送信することから、ユーザ端末が、通信リンクを介してサーバから、ヘッダ、本文の最初のＮ個の文字及び第１のフラグを受信することは明らかである。
　引用発明の「送信元」「の送信情報」は、本願発明の「差出人」「の情報」に相当する。
　引用発明の「主題」は、本願発明の「件名の情報」に相当する。
　引用発明の「本文」は、本願発明の「メッセージ本文」に相当する。
　引用発明の「本文の最初のＮ個の文字」は、本願発明の「メッセージ本文の少なくとも一部」に相当する。
　引用発明において、ヘッダは、メッセージの送信元及び宛て先などの送信情報を含み、サーバは、ヘッダ、本文の最初のＮ個の文字及び第１のフラグをユーザ端末に送信し、ユーザ端末は、ユーザに主題の行及び本文の最初のＮ個の文字であるメッセージ識別子を提示することから、ヘッダの送信情報に主題の行が含まれていることは明らかである。そうすると、引用発明において、「ヘッダ、本文の最初のＮ個の文字及び第１のフラグ」は、メッセージの送信元の送信情報及び主題の行とともに本文の最初のＮ個の文字を含むものといえる。したがって、引用発明のユーザ端末の、サーバからヘッダ、本文の最初のＮ個の文字及び第１のフラグを受信する構成と本願発明の「通信ネットワークを介してマルチメディアメッセージ用情報処理装置から、該マルチメディアメッセージの差出人及び件名の情報とともに該マルチメディアメッセージのメッセージ本文の少なくとも一部を含む着信通知を受信する通信手段」は、「通信ネットワークを介してメッセージ用情報処理装置から、該メッセージの差出人及び件名の情報とともに該メッセージのメッセージ本文の少なくとも一部を含む着信通知を受信する通信手段」である点で一致する。
　引用発明において、ユーザ端末が、ヘッダ、本文の最初のＮ個の文字及び第１のフラグというデータを受信した際に、これらの受信データを記憶手段に記憶していることは明らかである。
　引用発明の「画面」及び「提示」は、それぞれ本願発明の「出力手段」及び「出力」に相当する。
　引用発明において、サーバは、ヘッダ、本文の最初のＮ個の文字及び第１のフラグをユーザ端末に送信し、ユーザ端末は、ユーザに主題の行及び本文の最初のＮ個の文字であるメッセージ識別子を提示し、また、第１のフラグが「１」である場合、第１のフラグは、ユーザに提示されることから、ユーザ端末は、ヘッダ、本文の最初のＮ個の文字及び第１のフラグという受信データを画面に提示しているといえる。
　引用発明において、ユーザ端末が、通信及び提示についての制御を行っていることは明らかであるから、ユーザ端末がその制御を行う制御手段を備えていることは明らかである。
　引用発明において、第１のフラグは、本文の残りの文字を示し、残りの文字がある場合に「１」となり、残りの文字がない場合に「０」となることから、第１のフラグは、ヘッダ、本文の最初のＮ個の文字及び第１のフラグにメッセージの本文の全体が含まれているか否かを識別するための本文の文末を識別する情報であるといえる。
　引用発明において、第１のフラグが「０」である場合、メッセージは完全であり、送信は終了し、第１のフラグが「１」である場合、第１のフラグは、ユーザに提示され、第１のフラグが選択されると、ユーザ端末は、本文の残りの文字の取得要求をサーバに送信することから、第１のフラグに基づいて、ヘッダ、本文の最初のＮ個の文字及び第１のフラグにメッセージの本文の全体が含まれているか否かを判断しているといえる。また、この判断を、ユーザ端末の制御手段が行っていることは、明らかである。
　引用発明において、第１のフラグは、ＨＴＴＰヘッダに設けられることから、第１のフラグが、ヘッダーに設定した第１のフラグ用のフィールドの１ビットのフラグデータであることは、明らかである。
　
　すると、本願発明と引用発明とは、次の点で一致する。
＜一致点＞
「通信ネットワークを介してメッセージ用情報処理装置から、メッセージの着信通知を受信する移動体通信端末であって、
　通信ネットワークを介してメッセージ用情報処理装置から、該メッセージの差出人及び件名の情報とともに該メッセージのメッセージ本文の少なくとも一部を含む着信通知を受信する通信手段と、
　該通信手段で受信した着信通知の受信データを記憶する記憶手段と、
　該メッセージ本文の少なくとも一部を含む着信通知の受信データを出力する出力手段と、該通信手段及び該出力手段を制御する制御手段とを備え、
　上記着信通知の受信データは、その着信通知に上記メッセージのメッセージ本文の全体が含まれているか否かを識別するための、該メッセージ本文の文末識別情報を有し、
　上記制御手段は、上記文末識別情報に基づいて上記着信通知に上記メッセージのメッセージ本文の全体が含まれているか否かを判断し、
　上記文末識別情報は、ヘッダーに設定した上記メッセージ本文の文末有無判断用フィールドの１ビットのフラグデータであることを特徴とする移動体通信端末。」
　
　一方、両者は次の点で相違する。
＜相違点１＞
　本願発明では、メッセージが、複数のメディアタイプのデータを含めることができるマルチメディアメッセージであり、また、メッセージ用情報処理装置が、マルチメディアメッセージ用情報処理装置であるのに対し、引用発明では、メッセージが、画像及び音声などの添付ファイルを含むことについては記載があるが、本願発明の上記構成については明確な記載がない点。
＜相違点２＞
　本願発明では、着信通知を、その着信通知が分割された所定サイズの複数の分割データそれぞれを含む複数のＳＭＳによって受信するのに対し、引用発明では、この構成について明確な記載がない点。
＜相違点３＞
　本願発明では、メッセージ本文の文末有無判断用フィールドが、着信通知が分割されＳＭＳで送信される複数の分割データそれぞれのヘッダーに設定されるのに対し、引用発明では、ＨＴＴＰヘッダに設定される点。
　
６　当審の判断
　上記相違点について検討する。
＜相違点１についての検討＞
　複数のメディアタイプのデータを含むマルチメディアメッセージを通信するマルチメディア・メッセージング・サービス（ＭＭＳ：Multimedia Messaging Service）は、例えば、Ｍｕｌｔｉｍｅｄｉａ　Ｍｅｓｓａｇｉｎｇ　Ｓｅｒｖｉｃｅ　Ａｒｃｈｉｔｅｃｔｕｒｅ　Ｏｖｅｒｖｉｅｗ　Ｖｅｒｓｉｏｎ　１．２　Ｃａｎｄｉｄａｔｅ　Ｖｅｒｓｉｏｎ　２０−Ｓｅｐｔｅｍｂｅｒ−２００３、米国、２００３年９月２０日発行、Ｐａｇｅ　１〜２６[online]URL: http://read.pudn.com/downloads75/ebook/277228/OMA-MMS-ARCH-V1_2-20030920-C.pdf、特開２００２−２８１５５０号公報及び塚田晴史ほか３名、ＭＭＳ（Multimedia Messaging Service）、ＮＴＴ　ＤｏＣｏＭｏテクニカル・ジャーナル　Ｖｏｌ．１１　Ｎｏ．１、社団法人電気通信協会、平成１５年４月１日発行、１０６−１１５頁に記載され、また、本願の背景技術でも述べられているように、本願出願前周知である。したがって、引用発明において、当該周知技術を適用して、メッセージを複数のメディアタイプのデータを含めることができるマルチメディアメッセージとし、また、メッセージ用情報処理装置をマルチメディアメッセージ用情報処理装置とすることは、当業者が容易に想到し得ることである。　
　
＜相違点２及び３についての検討＞
　メッセージシステムにおいて、３８４バイトのメッセージを３つの１２８バイトのＳＭＳで送信する技術は、例えば、特開２００１−１９７５５３号公報（特に、段落【０００３】及び【００６６】参照。）及び特開２００３−３０４２９１号公報（特に、段落【００１１】、【００２６】〜【００２７】及び図７参照。）に記載されているように、本願出願前周知である。したがって、引用発明の着信通知に、当該周知技術を適用して、着信通知を、その着信通知が分割された所定サイズの複数の分割データそれぞれを含む複数のＳＭＳによって受信するように構成することは、当業者が容易に想到し得ることである。
　また、メッセージ本文の文末有無判断用フィールドを、複数の分割データのうち、その１つのヘッダー又はそれぞれのヘッダーに設定するかは、当業者が必要に応じて適宜なし得る設計的事項にすぎない。したがって、引用発明の着信通知に、当該周知技術を適用して、メッセージ本文の文末有無判断用フィールドが、着信通知が分割されＳＭＳで送信される複数の分割データそれぞれのヘッダーに設定されるように構成することは、当業者が容易に想到し得ることである。
　
　また、本願発明の構成によって生じる効果も、引用発明及び周知技術から当業者が予測できる程度のものである。
　
　したがって、本願発明は、引用発明及び周知技術に基づいて当業者が容易に発明をすることができたものである。
　
　なお、本願発明の「上記文末識別情報は、上記着信通知が分割されＳＭＳで送信される上記複数の分割データそれぞれのヘッダーに設定した上記メッセージ本文の文末有無判断用フィールドの１ビットのフラグデータであること」という構成（特に、複数の分割データそれぞれのヘッダーに設定する構成）は、本願の願書に添付した明細書、特許請求の範囲又は図面（以下「当初明細書等」という。）に明示的に記載された事項及び当初明細書等のすべての記載を総合することにより導かれる技術的事項との関係において新たな技術的事項を導入しないものといえないと認められる。平成２３年８月２９日付けの意見書において、審判請求人は、「補正の根拠は、本願の出願当初の明細書における段落００１５、００１６、００２５、００２６、００４３、００４５、００５０、００５８〜００６１の記載、並びに、図１１〜１３の記載等です。」と述べているが、これらの記載には、着信通知のデータは、所定のサイズのパケットに分割されて送信される旨などが記載されているが、上記構成についての記載はない。
　
７　むすび
　以上のとおり、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。
　したがって、その余の請求項について論及するまでもなく、本願は、拒絶すべきものである。
　よって、結論のとおり審決する。