APPENDIX A2
`
`Infringement Claim Chart re: U.S. Patent No. 7,742,759
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`Claim Language
`
`
`The preamble is presumed not to be limiting. In the case that this preamble were
`determined to be limiting, AT&T’s Multimedia Message Service Center (“MMSC”) and
`related server computers for Multimedia Message Service (“MMS”) messaging include a
`programmable memory, because they are computers with both Random Access Memory
`and persistent storage necessary for storage and execution of program code, including code
`for receipt, content adaptation, and delivery of MMS messages between two devices.
`
`
`
`What is claimed is:
`53. A programmable memory
`having stored thereon a plurality
`of sequences of instructions
`including sequences of
`instructions which, when
`executed by one or more
`processors cause one or more
`electronic devices to:
`
`
`
`
`
`pre
`
`1
`
`AT&T - Exhibit 1023
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`
`
`“5.7.1 MMS Environment
`
`The MMS Environment (MMSE) refers to the set of MMS elements, under the control of a
`single administration (MMS provider, e.g., mobile network operator), in charge of providing
`the service to MMS subscribers. Recipient and originator MMS clients are attached,
`respectively, to the recipient and originator MMSEs.
`
`
`2
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`5. 7.2 MMS Client
`
`The MMS client (also known as MMS user agent in the 3GPP terminology) is the software
`application shipped with the mobile handset, which allows the composition, viewing,
`sending, retrieval of multimedia messages, and the management of reports. For the
`exchange of a multimedia message, the MMS client that generates and sends the multimedia
`message is known as the originator MMS client, whereas the MMS client that receives the
`multimedia message is known as the recipient MMS client.
`
`The MMS client offers the following features:
`• Management of messages, notifications, and reports: devices are commonly shipped
`with a "unified" message box for the management of MMS elements (messages,
`notifications, and reports) and other elements such as SMS/EMS messages, WAP
`push messages, and so on.
`
`
`
`
`
`• Message composition: the message composer is used for creating new multimedia
`messages.
`
`• Message viewing: the message viewer is used to render received messages or to
`preview newly created messages before sending.
`
`…
`
`5.7.3 MMS Center
`
`The MMS Center (MMSC) is a key element in the MMS architecture. Logically, the MMSC
`is composed of an MMS relay and an MMS server. The relay is responsible for routing
`messages not only within the MMSE but also outside the MMSE, whereas the server is in
`charge of storing messages. The MMSC server is in charge of temporarily storing messages
`that are awaiting retrieval from recipient MMS clients. The MMSC may have built-in
`transcoding capabilities, functions for supporting legacy users, databases for storing user
`
`3
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`profiles. However, these functions can also be realized with specialized components
`implemented outside the MMSC.”
`
`Source: Gwenael Le Bodic, Mobile Messaging Technologies and Services: SMS, EMS,
`and MMS, 2nd Ed., 2005, at 218-220 (SCRN00004700-772 at 757-759).
`
`AT&T provides access to one such MMSC at the following address:
`
` http://mmsc.cingular.com
`See http://apn-settings.com/us/att-apn-settings/ (SCRN00004773-775)
`
`AT&T provides MMS message services to its subscribers:
`
`“Picture/Video Messaging
`Picture & Video Messaging-capable devices use Multimedia Messaging Service (MMS) to send
`messages that include multimedia content to and from mobile devices. With a Picture & Video
`Messaging-capable device, you can:
`• Send pictures, animations, videos, and voice messages to any 10-digit wireless number or
`email address.
`• Personalize the message with text or a voice recording.
`• Receive picture and video messages on your device sent to your 10-digit wireless number
`or emailed to your 10-digit wireless number@mms.att.net.
`
`…
`Send Picture & Video Messages
`To learn to send Picture & Video Messages from your device, please visit the Device How-To
`Center:
`1. If needed, select your device, brand, and model and then click Save.
`2. Under Device instructions, select Messaging & email:
`
`4
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`• To send a picture or video message, select Text & picture messaging, and then,
`from the Interactive tutorials, select Send a multimedia message.
`• To send a picture or video as an email, select Email, and then, from the Interactive
`tutorials, select Send email.
`
`…
`Don't have a Picture & Video Messaging-capable device?
`If you don't have a Picture & Video Messaging-capable device and receive a picture or video
`message, you'll receive a text message explaining how to view your picture or video message. The
`text message will include a link to an internet address where the message can be viewed online (a
`login and password will be provided). You'll need to download and install Quicktime Player to watch
`a video message.
`
`If you send a message to a device incapable of viewing a Picture & Video Message, your recipient
`receives a text message with a link to view your message online. Some wireless providers may
`choose not to deliver these message notifications to their customers.
`…
`
`
`Picture & Video Message size limits and file types
`The AT&T mobile broadband network will deliver MMS (picture, video or audio) messages of up to
`600 kilobytes (KB). Media file attachments will be compressed on the device prior to being sent in
`order to keep the message size below 600 KB. The maximum size for sending and receiving MMS
`messages is also dependent upon the recipient's device and the limitations of other carriers'
`networks (e.g., other carriers may have a lower MMS size limit than AT&T).
`
`Image, video, and audio files come in several formats. Compatible file types vary from device to
`device. Please visit the Device How-To Center to determine the specifications of your device.
`
`5
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`Supported image formats:
`• JPEG (Baseline JPEG)
`• GIF 87a (still images)
`• GIF89a (animated images)
`• WBMP (Wireless bitmap still images)
`• BMP (still images)
`• PNG (still images)
`• WBMP (animated images)
`
`Supported audio formats:
`• MIDI
`iMelody
`•
`• AMR
`• SP
`
`Supported video formats:
`• H.263
`• MPEG4”
`
`See http://www.att.com/esupport/article.jsp?sid=53119&cv=820#fbid=uM7xjcxMRKA
`(SCRN00004776-777)
`
`The operation of MMSCs and related servers is informed by several standards, including
`3GPP TS 22.140, 3GPP TS 23.140, and 3GPP TS 26.140, and Open Mobile Alliance
`(“OMA”) Multimedia Messaging Service Releases v1.1, 1.2, and 1.3. In accordance with
`
`6
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`these standards, the typical handling of MMS message transmission between two devices by
`MMSCs and associated servers is as follows:
`
`
`
`
`
`
`7
`
`

`
`
`
`
`Claim Language
`
`APPENDIX A2
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`• “MMS Client: A device through which the user receives or sends
`multimedia messages. This might be a phone or a PC-based MMS
`client. The Client sends messages to and receives messages from the
`MMSC using WAP/HTTP as transport.
`• MMS Gateway: Switches messages between different MMS clients
`and between MMS and Email. The Gateway may also interface with
`other gateways to exchange messages destined for foreign networks.
`This is also more properly known as the MMSC.
`• MMS Server: This component provides persistent storage of
`messages on the network. Typically users can access stored
`messages via a web interface.
`• Other MMS Systems:Other systems, such as Third Party MMS
`systems (e.g. MMS VAS providers) can interface to the MMSC to
`receive and send MMS content. The Interface used is termed MM7.
`• SMSC: The MMSC utilises WAP Push to send notifications to MMS
`Clients. These are typically sent using SMS as the bearer service,
`hence the need for a link to a Short Message Service Centre.
`Typically, the message cycle begins with a user sending a multimedia
`message (MM) from the MMS client. The client must be configured for MMS,
`which includes bearer settings (i.e. GPRS or GSM/CSD settings), WAP
`gateway address and MMS Gateway address (a URL). On receipt of the
`message, the MMSC decides how to deliver the message (e.g. to another
`MMS client or to a VASP), and proceeds to dispatch the message. A VASP
`may also originate a message to the MMSC, for onward delivery.
`
`8
`
`

`
`
`
`
`Claim Language
`
`APPENDIX A2
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`An MM is typically a multi-part message with pictures, sound, text and other
`media. Each part of the message is identified by media (MIME) type, name
`and/or Content ID. Usually the message is of a multipart/related MIME type,
`with the start element being a SMIL part that controls how the message
`should be displayed.
`
`When submitting a message, the MMS client indicates the intended recipient
`list, but usually not the sender address, which the MMSC retrieves from the
`WAP gateway. Like Email, a single MMS can specify multiple recipients
`(MSISDNs and Email addresses), and it is up to the MMSC to ensure correct
`delivery to each of the recipients.
`When the MMSC receives a message destined for an email address, it
`typically re-codes the message as standard MIME and passes it on to an
`SMTP server for delivery. Email messages received are similarly re-coded as
`MMS and forwarded to the relevant MMS Client.
`When the MMSC receives a message destined to MMS Clients in the area
`served by the MMSC, the message is stored and an MMS notification sent to
`the recipient via WAP Push. On receipt of the notification, the client
`typically fetches the message via a URL provided in the notification.
`When a recipient requests an incoming MM from the server, it indicates to
`the server its capabilities for a User Agent Profile URL. The profile data
`includes such things as supported media types, screen size, supported
`character sets, etc. Typically, the MMSC will re-code the MM to suit the
`
`9
`
`

`
`
`
`
`Claim Language
`
`[a]
`
`receive a video file in a native
`playback format;
`
`APPENDIX A2
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`client's capabilities before returning the message. Messages destined to
`email may also be re-coded to make them more suitable for email readers.”
`[http://mbuni.org/userguide.shtml#Section_.1.1.1] (SCRN00001347-399). See also
`http://www.nowsms.com/faq/how-mms-works (SCRN00001340-344)
`
`Pursuant to P.R. 3-1(g), Plaintiff asserts this limitation is implemented in software.
`
`AT&T’s MMSC and associated servers include sequences of instructions which, when
`executed by one or more processors, cause an MMSC to receive a video file in a native
`playback format, because AT&T provides MMS message services to its subscribers, which
`requires an MMSC to receive from a mobile device a video file, such as an image, or movie,
`in a playback format native to the originating device, for transmission to another device.
`The originating device could be a device in AT&T’s network, or one outside of it.
`
`AT&T provides MMS message services to its subscribers on all MMS-capable devices:
`“Picture/Video Messaging
`Picture & Video Messaging-capable devices use Multimedia Messaging Service (MMS) to send
`messages that include multimedia content to and from mobile devices. With a Picture & Video
`Messaging-capable device, you can:
`• Send pictures, animations, videos, and voice messages to any 10-digit wireless number or
`email address.
`• Personalize the message with text or a voice recording.
`• Receive picture and video messages on your device sent to your 10-digit wireless number
`or emailed to your 10-digit wireless number@mms.att.net.
`
`…
`Send Picture & Video Messages
`To learn to send Picture & Video Messages from your device, please visit the Device How-To
`
`10
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`Center:
`If needed, select your device, brand, and model and then click Save.
`1.
`2. Under Device instructions, select Messaging & email:
`• To send a picture or video message, select Text & picture messaging, and then,
`from the Interactive tutorials, select Send a multimedia message.
`• To send a picture or video as an email, select Email, and then, from the Interactive
`tutorials, select Send email.
`
`…
`Don't have a Picture & Video Messaging-capable device?
`If you don't have a Picture & Video Messaging-capable device and receive a picture or video
`message, you'll receive a text message explaining how to view your picture or video message. The
`text message will include a link to an internet address where the message can be viewed online (a
`login and password will be provided). You'll need to download and install Quicktime Player to watch
`a video message.
`
`If you send a message to a device incapable of viewing a Picture & Video Message, your recipient
`receives a text message with a link to view your message online. Some wireless providers may
`choose not to deliver these message notifications to their customers.
`…
`
`Picture & Video Message size limits and file types
`The AT&T mobile broadband network will deliver MMS (picture, video or audio) messages of up to
`600 kilobytes (KB). Media file attachments will be compressed on the device prior to being sent in
`order to keep the message size below 600 KB. The maximum size for sending and receiving MMS
`messages is also dependent upon the recipient's device and the limitations of other carriers'
`networks (e.g., other carriers may have a lower MMS size limit than AT&T).
`
`
`11
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`Image, video, and audio files come in several formats. Compatible file types vary from device to
`device. Please visit the Device How-To Center to determine the specifications of your device.
`
`Supported image formats:
`• JPEG (Baseline JPEG)
`• GIF 87a (still images)
`• GIF89a (animated images)
`• WBMP (Wireless bitmap still images)
`• BMP (still images)
`• PNG (still images)
`• WBMP (animated images)
`
`Supported audio formats:
`• MIDI
`iMelody
`•
`• AMR
`• SP
`
`Supported video formats:
`• H.263
`• MPEG4”
`
`
`See http://www.att.com/esupport/article.jsp?sid=53119&cv=820#fbid=uM7xjcxMRKA
`(SCRN00004776-777)
`
`According to the relevant standards described above, all MMS messages between two end
`
`12
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`devices are relayed through an MMSC. See, e.g., 3GPP TS 22.140 (SCRN00000101-120),
`3GPP TS 23.140 (SCRN00000282-507), and 3GPP TS 26.140 (SCRN00000607-621).
`
`At least the following video file types are supported for receipt by MMSCs that comply
`with 3GPP standards, including 3GPP TS 26.140: JPEG, JFIF, GIF, PNG, H.264, MPEG-4,
`H.263. See, e.g., 3GPP TS 26.140 version 11.1.0, Release 11 (SCRN00000607-621)
`
`In the case of inter-network MMS messaging, MMS messages are relayed from an
`originating network’s MMSC to the terminating (receiving) network’s MMSC for possible
`content adaptation and delivery to the recipient mobile device.
`
`See CTIA MMS Interoperability Guidelines, Revision: 3.0 at 22 (SCRN00000622-654 at
`643)(“It is recommended that transcoding responsibility rest with the terminating service
`provider’s network, either in the service provider’s MMSC or through a third party
`contracted by the terminating network (i.e, an ICV). The content types in Section 4 of this
`document are the supported types for Interoperable MMS Messaging. The current list of
`supported content will be updated on an “as-needed” basis and the Working Group will
`continue to meet in order to update these guidelines.”)
`According to CTIA MMS Interoperability Guidelines, Revision: 3.0, U.S. wireless carriers
`should support receiving at least the following native video types:
`
`
`13
`
`

`
`4. File Types
`
`Each participating service provider should handle inbound MMS messaging traffic with
`their own network capabilities and feature sets. Message types and feature sets are
`APPENDIX A2
`defined later in this document.
`
`The following media types should be supported (at a minimum) by the participating
`U.S. Patent No. 7,742,759
`service providers. Support does not imply device or service capability, but rather
`infrastructure support (i.e., transcoding can be performed at the terminating network).
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`
`
`JPEG (same as JPG
`PNG
`
`IMAGES
`BMP
`87a GIF (same as GIF)
`
`TEXT
`AMR
`
`AUDIO
`
`mp3
`mpeg
`qcelp
`sp-mid (same as sp-midi)
`vnd.qcelp (same as QCELP)
`
`wav
`x-wav
`mid
`ogg
`
`
`VIDEO
`
`
`
`SMIL
`
`
`
`3gpp
`3gpp2
`amr
`evrc
`midi
`
`
`
`
`
`Claim Language
`
`h264
`3g2
`3gpp
`mp4
`h263-2000
`3gp
`egpp2
`h263
`mp4v-es
`
`CTIA MMS Interoperability Guidelines, Revision: 3.0, at 19 (SCRN00000622-654 at 640).
`It is recommended that all service providers support H.264 media type.
`
`
`
`14
`
`
`
`
`
`[b]
`
`convert the video file to a native
`playback format usable by a
`playback device; and
`
`Pursuant to P.R. 3-1(g), Plaintiff asserts this limitation is implemented in software.
`
`AT&T’s MMSC and associated servers include sequences of instructions which, when
`executed by one or more processors, cause an MMSC to convert the video file to a native
`playback format usable by a playback device, because AT&T’s MMS message services
`supports content adaptation, which provides for the conversion of video files transmitted by
`MMS Interoperability Guidelines Rev.3.0
`Page 19
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`an originating device into formats suitable for display on a terminating (receiving) device.
`“9. Content Adaptation
`
`9.1 Overview
`
`The MM Content Classes defined for the Core MM Content Domain lay out basis for
`interoperable messaging with simple but mandatory requirements for multimedia support.
`The MM Content Classes permit media types as specified by both [CS0045] and [TS26140].
`The reception of MMs conformant to the MM Content Classes including media formats
`defined in either Table 1 or Table 2 is supported directly within the terminal, or through
`transcoding within the network. The MM Content Classes provide seamless interoperability
`only within each content class, in other words, if the sender and recipient both support the
`same content class.
`
`…
`
`The term content adaptation consists of a series of functions and definitions, which alter the
`content not supported by the recipient MMS Client to a content which is supported by the
`recipient yet preserving the original information content to the extent possible. These
`functions, called transcoding functions, may resize multimedia objects, perform conversion
`between media formats, perform conversion between media types and, ultimately, even drop
`off some unsupported media objects.
`
`The purpose of content adaptation is to bridge the gaps between MM Content Classes in
`core MM Content Domain to minimise the requirement for sending MMS Client to know
`the capabilities of the recipient MMS Client for person-to-person messaging. Content
`adaptation for MM Content Classes Content Rich and Content Basic are not specified.
`
`The content adaptation is divided into two categories, minor adaptation and major
`adaptation.
`
`15
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`“Minor adaptation” refers to transcoding functions, which mainly adapt the message size,
`image resolution, sound and video quality to match the capabilities of the receiving MMS
`Client while preserving the information content of the multimedia message. Minor
`adaptation does not in general contain removal of media content or media type conversions.
`Adaptations between media formats are considered minor if end-user perceives no drastic
`loss of quality or loss of content.
`
`“Major adaptation” refers to transcoding functions, which perform more drastic message
`size, image resolution, sound and video quality adaptations which generally result to loss of
`information content. Major adaptation may include removal of media content and media
`type conversions. Adaptations between media formats are considered major if end-user
`perceives drastic loss of quality or content.”
`Source: OMA-TS-MMS-CONF-V1_3-20110913-A, p. 31(SCRN00001042-121 at 072).
`See also OMA-MMS-CONF-V1_2-20050301-A at 22 (SCRN00000693-740 at 714).
`
`
`“9.5 Requirements for Content Adaptation
`
`9.5.1 MMS Client and Terminal Requirements.
`
`The requirements for MMS Client to support content adaptation are:
`
`• The recipient MMS Client SHALL NOT reject the multimedia message based on the
`message size indicated in the MMS notification
`
`• MMS Client SHALL support UAProf [UAProf] for MMS Client capability negotiation.
`
`The requirements for the terminal to support content adaptation are:
`
`16
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`•
`
`If the MMS Client and a camera are integrated into the terminal, the terminal
` SHALL be able to reduce in size any image taken by the integrated camera such
`that it fits into an MM of the Core MM Content Domain.
`
` 9.5.2 MMS Proxy-Relay Requirements
`
`The MMS Proxy-Relay requirements for the content adaptation are:
`
`• MMS Proxy-Relay SHALL support UAProf [UAProf] for MMS Client capability
`negotiation
`
`• MMS Proxy-Relay SHALL be able to perform minor content adaptation as specified in
`this document.
`
`• MMS Proxy-Relay MAY be able to perform major content adaptation
`
`• If the MMS Proxy-Relay is able to perform major content adaptation it SHALL provide
`means to the MMS service provider to enable or disable the major content adaptation
`function.”
`• When major content adaptation is or needs to be applied to an MM, the original
`content of the MM SHOULD be available to the end-user through subsequent
`MMS transactions or by other means (e.g., web or IMAP interface store or
`forwarding to e-mail). No additional constraints on multimedia message
`retention time are implied.
`When a media format/type adaptation is accomplished, the extension of the files and
`the MIME types MUST be modified accordingly in the corresponding header fields.
`These changes MUST be reflected in the presentation element.
`
`17
`
`

`
`
`
`
`Claim Language
`
`APPENDIX A2
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`When a media type adaptation is accomplished, the labels in the presentation element
`MUST be modified if appropriate (e.g., <video> to <img> in the adaptation from
`video to image)
`If major content adaptation was performed or a media element is dropped during the
`content adaptation the MMS Proxy- Relay SHALL insert information in the MM
`(e.g., by modification of the text element contained in the same slide) to inform the
`user of this fact.”
`Source: OMA-TS-MMS-CONF-V1_3-20110913-A, p. 36-37 (SCRN00001042-121 at
`077-078). See also OMA-MMS-CONF-V1_2-20050301-A at 25 (SCRN00000693-740 at
`717).
`
`“13.Content  Adaptation  
`
`One  of  the  possible  services  that  an  MMS  system  may  be  able  to  provide  is  content  
`adaptation.  In  effect,  there  may  be  the  opportunity  to  convert,  replace  or  delete  certain  
`data  elements  from  a  multimedia  message  before  delivering  it  to  the  MMS  Client.  
`
`13.1  Determining  Need  for  Content  Adaptation  
`
`Such  service  may  be  prompted  for  a  variety  of  reasons:  
`
`• Device  Capability  –  Devices  may  have  limitations  that  may  prevent  them  from  being  able  
`to  handle  some  data  elements  in  an  MMS  message.  These  limitations  may  be  based  
`upon  content  type,  characteristics  or  size  (e.g.  buffer  space).    
`
`• Bandwidth  Considerations  –  Certain  data  types  may  be  inappropriate  for  a  particular  
`type  of  bearer  (e.g.  streaming  over  SMS).  Such  considerations  may  be  based  upon  
`
`18
`
`

`
`
`
`
`Claim Language
`
`U.S. Patent No. 7,742,759
`Infringement by AT&T Mobility, LLC (“AT&T”)
`
`APPENDIX A2
`
`factors  set  by  a  user  or  a  network  operator.    
`
`• Roaming  Considerations  –  There  may  be  issues  having  various  multimedia  data  
`conveyed  over  an  alternate  carrier’s  network.  There  may  be  service  constraints  or  
`pricing  considerations  that  may  impact  the  delivery  of  message  elements.  Such  
`filtering  should  occur  at  the  ‘home’  system.    There  are  various  services  that  may  
`assist  the  MMS  system  to  determine  whether  content  adaptation  is  needed.  In  
`particular,  the  WAP  UAProf  [UAPROF]  provides  a  mechanism  to  inform  the  MMS  
`Proxy-­‐Relay  with  information  about  the  MMS  Client.  This  information  relates  to  
`characteristics  of  the  device  and  serving  network.    
`
`13.2  Content  Adaptation  Activities  
`
`Various  forms  of  content  adaptation  may  be  performed.  For  example,  graphic  images  may  
`be  removed,  scaled  or  colour  converted.”  
`Source: OMA-AD-MMS-V1_3-20110913-A at 23 (SCRN00000932-957 at 954)
`AT&T’s MMSC and related server computers include sequences of instructions which,
`when executed by one or more processors, determine the video format capabilities of the
`receiving device, including through evaluation of a User Agent Profile (UAProf) provided
`by the receiving device during the MMS messaging process, which describes the video
`capabilities of the receiving device. Based on the capabilities of the receiving device, or on
`other rules, AT&T’s MMSC and related computers can convert the video file to a format
`compatible with the receiving device, including by resizing, changing formats, or changing
`the file size.
`
`19
`
`

`
`Mobile Messaging Technologies and Services
`
`Multimedia Messaging Service
`
`241
`
`Of course, the VAS provider needs to set up a commercial agreement with the MMS
`provider (e.g., network operator) in order to apply the chosen billing model for the value-
`A VAS provider can achieve mass distribution of information to mobile users with MMS.
`Furthermore, the provider can also control how message contents are redistributed using
`
`appropriate DRM mechanisms. DRM in the context of MMS is defined in the standards from
`MMS 1.2 [OMA-MMS-Conf].
`
`Claim Language
`
`5.21 Content Adaptation
`In an environment in which mobile devices have heterogeneous capabilities, adapting the
`message contents according to the capabilities of receiving devices can greatly improve the
`overall user experience. From Release 5, 3GPP mandates the support of content adaptation
`for mobile devices and highly recommends its support by MMSCs [3GPP-23.140]. In the
`WAP environment, the user agent profile (UAProf) technique, introduced in Section 1.6.4, is
`used for this purpose. Content adaptation is performed on messages during the retrieval
`process and is not applied to message notifications.
`The recipient MMS client provides its capabilities to the MMSC during the message
`retrieval process. Typically, these capabilities are communicated as part of the message
`retrieval request and the content-adapted message is provided as part of the retrieval
`response. The recipient MMS client can communicate its capabilities in the following
`
`1. Provision of the entire set of device capabilities.
`2. Indication of a URL (e.g., http://wap.sonyericsson.com/UAprof/P900R10l.xml) pointing
`to a capability profile in a remote profile repository (usually maintained by the device
`manufacturer). It is common for MMS providers (e.g., network operators) to copy profiles
`in their own internal systems to avoid having to rely on external systems but this is at the
`cost of additional work to update regularly the internal systems with new profiles.
`3. Provision of a differential set of information indicating changes to previously advertised
`capability information.
`
`Content adaptation performed by the MMSC consists of removing media objects that are
`not supported by the receiving device or adjusting media objects to the capabilities of the
`receiving device (e.g., media format conversions, reduction of color depth, reduction of
`video frame rate, replacement of a video clip by an animated image, etc.). The capability
`profile of a device includes the following MMS characteristics:
`
`• Supported MMS version.
`• Maximum supported message size.
`• Maximum supported image resolution.
`• Maximum supported color depth.
`• List of supported content types.
`• List of supported character sets.
`• Indication of whether or not the device supports streaming.
`
`• List of supported Synchronized Multimedia Integration Language (SMIL) profiles (e.g.,
`MMS SMIL, 3GPP SMIL Release 4, 3GPP SMIL Release 5).
`APPENDIX A2
`• List of supported message content classes (text, image basic, image rich, megapixel, video
`basic, video rich, content basic, and content rich).
`• Whether or not content adaptation should be disabled.
`U.S. Patent No. 7,742,759
`Figure 5.8 shows the basic course of retrieving a message when content adaptation is
`Infringement by AT&T Mobility, LLC (“AT&T”)
`applied. In this scenario, the MMSC has built-in transcoding capabilities for adapting the
`
`MMS
`Client
`
`MMSCiient
`The MMS Client
`provides its capability
`profile to the MMSC
`as part of the retrieval
`request
`
`0
`
`MM$ R!llav!Server-MMSC
`The MMSC is in charge of ·
`adapting the message
`contents before the message
`ilS retrieved by the device.
`
`Capability profile
`repos.itorv contains a set of
`profiles for: mobile devioes.
`
`
`Figure 5.8 Content negotiation
`message contents and does not rely on an external transcoder. Note, however, that OMA has
`“In an environment in which mobile devices have heterogeneous capabilities, adapting the
`standardized the Standard Transcoding Interface (STI) that specifies how an MMSC can
`interact with an external transcoder (possibly shared with other application platforms). The
`message contents according to the capabilities of receiving devices can greatly improve the
`transcoding process with STI is further described in Section 6.12.
`overall user experience. From Release 5, 3GPP mandates the support of content adaptation
`As shown in Section 1.6.4, the user agent profile' advertises the device hardware and
`software capabilities and provides the network, WAP, browser, push, and MMS device
`for mobile devices and highly recommends its support by MMSCs [3GPP-23.140]. In the
`characteristics. In addition to MMS-specific parameters, generic user agent profile para-
`WAP environment, the user agent profile (UAProf) technique, introduced in Section 1.6.4,
`meters can be used by the MMSC for the content adaptation of multimedia messages. MMS-
`is used for this purpose. Content adaptation is performed on messages during the retrieval
`specific user agent profile parameters are defined in [OMA-MMS-CTR] and are listed in
`Table 5.4. Figure 5.9 shows the partial representation of the user agent profile for an MMS-
`process and is not applied to message notifications.
`capable device.
`·
`The recipient MMS client provides its capabilities to the MMSC during the message
`retrieval process. Typically, these capabilities are communicated as part of the message
`1 A list of pointers to known user agent profiles for MMS mobile devices is available from this book's companion
`website at http://ww