Systems and Methods for Presenting Information on Mobile Devices
`
`4: Tight Integration with Phone Functions
`As described above as a prerequisite for messaging and social networking, there are a large and
`expanding set of phone based resources that must be tightly integrated with any consumer facing
`application to be a viable robust solution. This list will continue to grow, but it already includes:
`> Placing and receiving phone calls
`> Access to the phone's PIM data
`
`> Access to the phone's camera
`
`5: Mashups
`The efficient and robust integration of different web services to create a value-added seamless user
`experience should be an inherent attribute of the Authoring Platform. Some of the facilities that support
`mashups are:
`> The Feed Collector
`
`Utilizing a vendor supplied rules based populator, dynamic content from different feeds and/or web
`services can be logically consolidated.
`'~
`’ Extensible Attributes for Complex Objects
`
`Slide shows, virtual tours, GlS Service objects, and child objects, can consolidate content in a
`logical way, whether it be text. video, audio, pictures and/or vectors.
`> Vendor Supplied Web Services
`Services such as dynamic binding and Server Pages further help facilitate the mashup of logically
`related dynamic content.
`‘
`
`Graphlc 15: Web Services Objects
`
`
`
`Docket: XPROOZPR
`
`17
`
`Page 864 of 1295
`
`GOOGLE EXHIBIT 1006 (Part 3 of 3)
`
`Page 864 of 1295
`
`GOOGLE EXHIBIT 1006 (Part 3 of 3)
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`Example: Location Awareness Integration with all Relevant Services
`More and more social networking applications require the use of geographical information services (GIS)
`and location-based services (LBS) as integral components. For example, a social networking application
`may detect the location of “friends" within a certain radius of the mobile device using GIS and phone
`triangulation (location based on the three nearest mobile cell towers near the respective phone) or
`through the GPS received on the phone. GIS images may be used for mapping to theaters or restaurants,
`detect optimal travelling routes based on traveling conditions, etc. A broad array of mobile GIS web
`services have been built into the proposed delivery platform for location-aware applications.
`
`Graphic 16A and Graphic 168 are two examples of possible implementations.
`
`Graphic 16A: LBS Optimal Travel Route
`
`Step 1
`Select the E icon or fire after moving a soft cursor to zoom in to
`the desired geography.
`
`
` Step 3
`
`Step 2
`
`West directions from two User-Defined geospatial points. Select the
`icon and move cursor to a desired start-point ‘A'. Move your
`cursor to a desired end-point 'B’.
`
`To get the directions, select 5‘" icon again
`
`Result
`
`You will start off with a raster image of a map with two points selected. The optimal route will be displayed as a
`green vector graphic on top of the raster image of the map. You call zoom in closer to the optimized directions for
`a closer look. You can also see points of Interest, by viewing a 360-degree virtual tour. See Graphic 17 LBS
`Enhanced Services
`
`
`Docket: XPHOOZPR
`
`18
`
`Page 865 of 1295
`
`Page 865 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`Graphic 168: L88 Enhanced Services Demo
`
`Step 1
`The user could, as a short cut, select a point of interest through a
`button or any other navigation object.
`
`Step 2
`Alternatively. the user could select the E icon or fire after moving a
`soft cursor to zoom in to the desired geography so that the point of
`interest becomes visible and is selected. Or the user could enter in or
`select an address. The user could then fire on the button labeled ‘Take
`Tour'
`
`displayed.
`
`Step 3
`
`Immediately a virtual tour of the point of interest becomes available in
`which the user can now pan and zoom throughout the virtual
`representation of the point of interest.
`
`Alternatively. if a video cam is operational. a live video feed could be
`
`Docket: XPROOZPR
`
`19
`
`Page 866 of 1295
`
`Page 866 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`E: Maximum Distribution to Internet Connected Devices
`
`1: Removal of Most Device & Network Constraints
`
`Thick vs. Thin Client
`
`Most current implementations that support rich and highly interactive user experiences are computer
`programs that are written either to the Operating System (OS) or Virtual Machine (VM) of the device.
`From a development point—of~view this is a far quicker path to take. However, it means that all significant
`changes to the application require reprogramming the application and then complete the required Q/A
`cycle. a process that can take severai months. Also, for feature phones, the entire application must be
`downloaded and placed into the limited heap of the device. For any robust and full featured application
`this design will, at best, quickly restrict its use to a very limited number of devices.
`
`Graphic 17: Thlck vs. Thin Client
`
`Thick Client (500K+)
`- Resident Program
`
`Custom Code and Data
`
`
`Ultra-thin Client (<1 30K)
`- Application management
`- \firtual memory manager
`- Multi-Ievel cache manager
`- Anticipatory streaming
`
`a:
`
`+
`
`
`
`-JJ
`
`Code and Data Compaction
`
`+-
`
`—l
`
`Docket: XPR002PR
`
`20
`
`Page 867 of 1295
`
`Page 867 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`As mentioned before, the Proposed
`Platform is based on an ultra—thin
`client architecture. The Client is light
`weight and extends the OS and/or VM
`of the device to:
`'
`
`’ Extend the capability of the
`device to that of a desktop
`computer
`
`Graphic 18: Ultra-thin Client Engine and Its extensions
`'
`
`
`
`' Manage all applications and
`application upgrades
`’ Resolve device, 08, VM and
`language fragmentation
`A thin client architecture requires that
`a language be adopted that manages
`resources efficiently, is extensible,
`supports a robust application model, and has no device specific dependencies. .
`
`Virtual Memory and Multi-Level Cache Architecture
`
`Virtual Memory
`Desktop systems all support virtual memory by using a physical
`page model with supporting hardware. The proposed platform
`should implement a logical page virtual memory manager. This
`architecture requires no supporting hardware and works efficiently
`with constrained devices. All page view images. which could span
`multiple applications, are placed in a table as highly compacted
`and compressed code. A typical page view will range from 500
`bytes up to about 1,500 bytes. When rolled into the heap and
`instantiated this code increases to the more typical 50,000 up to
`250,000 bytes. Additional alert pages may also be rolled into the
`heap and superimposed on the current page view. Any changes
`to any page currently downloaded are placed in a highly compact
`change vector for each page, and rolled out when the page is
`discarded. Note that whenever an application is visited that had
`previously been placed in virtual memory the Server is
`interrogated to see if a more current version is available, and, if
`so, downloads it. This means that application logic can be
`changed in real-time and the results immediately available to
`mobile devices.
`
`Docket: XPROOZPR
`
`2"
`
`Page 868 of 1295
`
`
`Change Vectors E‘IIIIIIIII'
`
`App 1
`Page Images
`Charge Vectors
`
`App N
`Page Images
`
`
`
`. as .<
`
`
`Record Store or File System
`Cache for all Medla
`
`Page 868 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`Gra htc 21:
`Cod: and Data Compaction
`
`Java Objects
`
`'
`
`6
`3
`
`((
`2:)
`‘3”
`
`((
`2:)
`9:”
`
`Reassembled Primitives
`
`no
`00
`00
`
`0000000
`
`O O O
`
`Logical Compression
`
`00
`
`§§
`
`
`Anticipatory Streaming and Multi-Level Caching
`To operate efficiently with the bandwidth constraints of mobile devices,
`this delivery platform also features anticipatory streamingTM and multi-Ievel
`caching. Anticipatory streaming looks ahead in the current application to
`see if there is content that is likely to be visited in yet untouched page
`views.
`With the multi—level caching system, mobile applications are bounded so
`that the handsets don't run out of memory. Multi-level caching is a
`memory management system with results similar to embedding, without
`the overhead of instantiating the content. In other words, with multi-level
`caching. handset users get an “embedded" performance without the
`embedded download. Multi-level caching determines the handset’s heap
`through an API, and also looks at the record store to see how much
`memory is resident. This content is placed in record store and/or the file
`system, and may, if there is available heap, also place the content there
`as well. Note that when content is flagged as cacheable and is placed in
`persistent storage, a digital rights management (DRM) solution will be
`”56"
`Graphic 20; Memory Speed vs. Volume
`
`Network HTTP
`
`File System {it available)
`
`L2 Encoded
`Code and Data Compaction
`This delivery platform uses compaction to transform the code and data in
`&
`an intelligent way while preserving all of the original classes, methods and
`attributes. This requires both an intelligent server engine and client
`(handset) player, both of which fully understand what the data means and how it will be used.
`This compaction technology should include transformation algorithms that deconstruct the logic and data
`into their most primitive representations, and then reassembles them in a way that can be optimally
`digested by further compression processing. This reassembled set of primitive representations define the
`"proposed PDL.
`
`Prior to compression the code has already been transformed so that:
`> There are no dependencies on the original programming language (Java)
`> The code and data have been reduced by 4 to 10 times
`
`Compression has two distinct phases. The first takes advantage of how the primitive representations had
`been assembled, while the second utilizes standard LZ encoding.
`Docket: XPROOZPR
`22
`
`Page 869 of 1295
`
`Page 869 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`The final result is an overall reduction of 40 to 100 times the original size as
`represented by Java serialized objects.
`
`The player, when preparing a page view for execution, will decompress and
`then regenerate the original objects, but this time in compliance with the
`programming APls exposed by that device.
`
`2: Solution for Device Fragmentation
`
`Response Director for wide coverage of the wireless device
`market
`
`The heart of this proposed deployment platform resides in its Response
`Director, which determines a user’s handset, fetches the correct application
`from different databases, and delivers a respective highly compressed
`application in a Postscript-like Portable Description Language (PDL) format
`over the air (OTA)
`With the Response Director, any mobile device can be serviced, and the
`most appropriate application for the device will be delivered to the device,
`based on the characteristics of the device.
`
`How the Response Director Works
`Let’s take a look at how it works. First, an SMS message is generated to the
`mobile device, which then automatically sends an http:// stream that includes
`handset information and its phone number to the Response Director. The
`Response Director then looks at a field in the http header (which includes the
`user agent and IP address) that identifies the browser (i.e., the User Agent).
`The User Agent prompts a database lookup table that brings back a slew of
`data (for example, make, model, attributes, MIDP 1.0 MIDP 2.0. WAP). The
`database also distinguishes the same models from different countries. There
`is another IP address database, which identifies the cam'er/operator. A
`decision tree determines which application to fetch and send to the handset.
`
`Graphic 22: Decompression
`
`Compacted Page Images
`
`
`*1:
`
`Cache Manager
`Retrieve. Decompress. Reassemble
`
`
`
`Device Objects
`
`fad?»
`
`Graphic 23: Response Director
`
`HTTP Header (User Agent/IF Address)
`
`
`
`Find Make, Model
`Using User Agent
`
`. z; 0!:th ggiifigg'c) ?
`
`‘i"""
`“I!"IIIIIIII‘”
`'
`r
`W"
`Determine
`carrier/Operator
`
`Using IP Address
`Characteristics
`
`, - _,, __,
`
`
`Sammie”...
`llllllllllllllll
`Xpresmo File Database
`(jam, Jada, htrnl, waplwmt, sms)
`
`gm?
`(ISP, Carrier]
`Operator)
`
`User Agent
`Database
`
`lv
`
`Display Page
`
`Fifi
`
`inaour‘D
`a (himI 6310 Big
`
`
`
`ommuflmmumm
`owns. “Flinn-mull
`
`Open Toolbar
`
`Docket: XPROOZPR
`
`23
`
`Page 870 of 1295
`
`Page 870 of 1295
`
`

`

`Systems and Methods for Presenting lnforrnation on Mobile Devices
`
`Another Vendor supplied database should contain the data types such as jad1, jad2, html, wmI/wap2, and
`so on. A list of available applications are returned to the decision tree, which then returns, to the handset,
`the application that is appropriate for the respective handset. For each file type, there is an attributes list
`(e.g., streaming video. embedded video, streaming audio. etc.) so that there is enough information to
`determine what to send to the handset.
`
`If there is an application that has a data type that the handset cannot support, for example. video, the
`Response Director sends an alternative application to the handset. for example one that has a slide show
`instead. If the device cannot support a slide show. an application might have text and images and display
`a message that indicates it does not support video.
`
`Another proposed feature of the Response Director is its exposed API from the decision tree that permits
`the Vendor solution providers to override the default output of the decision tree. The Vendor solution
`providers will be given a choice of applications and then can decide to use the defaults or force other
`applications.
`
`Device Scaling for Reduced Fragmentation
`One of the most visible forms of fragmentation resides in the various form factors of wireless. and
`particularly mobile, devices, which range from 128x128, 176x208, 240x260, 320x320, and many other
`customized sizes in between. Often, developers must create hundreds of builds for one mobile
`application.
`'
`
`This proposed platform should automatically scale applications at publishing time to various form factors
`to reduce the amount of fragmentation among devices, and the Response Director would then serve the
`appropriately scaled version to the device. For example, a QVGA application will automatically scale to
`the QCIF form factor.
`
`Player Abstraction and Device Adaptation for Eliminating Fragmentation
`The proposed player architecture includes an abstraction interface that separates all device, operating
`system and virtual machine dependencies from the player's application model business logic.
`The advantages of this abstraction interface are:
`
`Porting to other operating systems and virtual machines is far more efficient.
`’
`' Adding extensions to the application model and PDL can be implemented once and then
`seamlessly propagated across all platform implementations.
`
`' Less robust platforms can be augmented by extending higher end capabilities inside that
`platform's abstraction interface implementation.
`
`The players also extend the power of the Response Director by adapting the application to the resources
`and limitations of any particular device.
`Some of these areas of adaptation include:
`
`D The speed of the device's microprocessor.
`
`D The presence of device resources such as cameras and touch screens.
`D The Heap. Record Store and File System memory constraints.
`
`For example. the player will automatically throttle down an animation to the frame rate that the device can
`handle so that the best possible user experience is preserved.
`
`Docket: XPROOZPR
`
`24
`
`Page 871 of 1295
`
`Page 871 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`Automatic Deployment around the Globe
`Finally, the Response Director can automate the deployment of applications acrossnational boundaries,
`supporting both traditional and double byte Asiatic languages.
`‘
`
`Graphic 24: Reduce Fragmentation
`
`Xpreesmo Authoring Tool
`
`I Ina-nnnT-Iunuu
`
`Docket: XPROOZPR
`
`25
`
`Page 872 of 1295
`
`Page 872 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`3: Application Model Support for Operator Extensions and Advanced JSRs
`Over time, the operators, device manufacturers, operating system and virtual machine vendors,
`responding to market demand, will increase the robustness of the IP Stack. This is already being seen as
`numerous optional JSRs have been released that extend the power of the Java MIDP virtual machine,
`new versions of operating systems with ever increasing capability are now available on mobile devices,
`and operators such as DoCoMo, Vodafone and Sprint have released numerous extensions that are
`specific to their networks.
`
`The proposed platform should have a facility, when it makes business sense, to extend its application
`model to support these new capabilities, without fragmenting application deployment over legacy devices
`that do not support these capabilities. Generally, this would be accomplished by using the following
`criteria to determine which new capabilities to add to the application model.
`
`b
`>
`
`Is this capability useful to a broad segment of the market?
`Is there a reasonable comparable or fail-softimplementation that can be added to the players for
`devices that do not support this capability?
`The processes below are largely automated in order to efficiently generate and support an expanding
`data base of Player Profiles.
`
`Graphic 25: Player Profiles
`
`cuties.
`
`03 and VM
`Dependent APIs
`
`
`
`
`1.
`
`*PHG‘HL‘E
`
`Device Profile
`Fall Soft Implementation
`
`Device
`Dependent APIs
`
`
`
`
`Géfisfié'P'léyer: ' ‘
`, W9 méfltétiOn.
`
`Operator Extension
`
` Dependent APis
`t"
`
`EROTEIL‘E:
`.......‘...‘..’.’.‘.
`
`Operator Profile
`Fall Soft implementation
`
`, .x' p.
`C!Illllll.-_I|IIII_IIPllI'llloll-ClIIII’IIllIii-IQII‘IDIIIIIIIIIIIIn.
` Iran-Input..-..V'DU‘.
`
`
`
`
`Native API Implementations
`Fall Soft Implementation
`
`.
`h -.» .‘. ; . .'
`
`Advanced and
`OptionalAPls
`
`Docket: XPROOZPR
`
`26
`
`Page 873 of 1295
`
`Page 873 of 1295
`
`

`

`S stems and Methods for Presentin Information on Mobile Devices
`
`As discussed previously, the Response Director manages the deployment of all players.
`
`Graphic 26: Player Deployment
`
`Receive HTTP Header
`
`
`
`Query for
`Device Characteristics
`Operator and Locale
`
`
`
`
`
`EEEE
`
`
`‘
`
`
`
`' ”
`
`tll
`
`yrs—"a vr
`:z-g-Ixnr «~15: vrrn
`‘llllll *Illllllli
`
`
`
`
`Response Director
`
`
`
`
`
`Query and Receive
`URL for Matchan Player
`
`Device Appropriate Player Install
`
`Player Profile
`Database
`
`
`
`
`
`liltilllllmlljlli
`
`Player Build Process
`Generate Players for all
`Abstraction implementations
`
`This does not preclude the support for advanced capabilities when there is no reasonable way to
`implement some reasonable representation on legacy devices.
`it does, however, infer that:
`D Legacy devices will, when receiving PDL instructions that it cannot support, ignore those
`instructions.
`I
`
`t The vendor, or its customers, may release advanced versions of this proposed Platform targeted
`for these more capable environments.
`
`Docket: XPR002PR
`
`27
`
`Page 874 of 1295
`
`Page 874 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`-
`
`4: Robust and Extensible Cross-Platform Application Model
`It would not be possible, with modern technology, to have a solution for deploying rich intelligent content
`to the wide array of 21st Century Internet applications that span set-top boxes, game consoles, PCs, and
`mobile devices without the implementation of a well conceived Application Model as the conceptual
`framework for all applications and services.
`
`Graphic 27: Cross Platform Application Model
`
`
`
`Docket: XPROOZPR
`
`28
`
`Page 875 of 1295
`
`Page 875 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`F: Complete Analytic Reporting
`
`Analytics can be tracked and reported by:
`> Application
`t User Demographic
`’ Time of Day
`t Location
`
`In addition, the type of analytic content is really only limited by which listeners have been activated for
`which objects and for which pages. Some of the choices are:
`> Player-side forms-based content
`> Player-side user interactions
`
`> Player-side object status
`' Server-side driven dynamic content events
`
`Graphic 26: Reporting and Management
`
`End Users
`sends SMS code
`ACME CEREAL
`
`Text ACME:
`PROMO
`for latest
`
`:'
`
`Interactive
`Promotion
`
`promotion ACME
`
`Mobile Phcnu
`
`
`.
`
`._.:-.;l
`
`Xpressmo Sewer
`
`ACME Server
`receives SMS
`
`Docket: XPROOZPR
`
`29
`
`Page 876 of 1295
`
`Page 876 of 1295
`
`

`

`Systems and Methods for Presenting Information on Mobile Devices
`
`G: Enhanced User Experience
`
`The quality of the user experience will be determined by a number of factors. All of the sections above
`address various components that will affect the user experience. in summary, they are:
`D Mlnlmized Handset Response Time Delay
`This will have been addressed by the suggested Cache and Virtual Memory Manager, anticipatory
`streaming, compaction of code and data, and the design of the proposed player.
`> Navigation
`This includes the various launch strips, graphical lists, intelligent test objects, and the overall power
`the proposed Event Manager Model.
`’ Entertaining Presentation Layer
`
`By empowering the designer and UI Engineer with the Publishing Tool, by offering, through
`massive analytic reporting the behaviors of the consumer, and with the rapid iteration capability to
`continue to adapt the presentation layer to consumer needs, the likelihood of success goes way up
`while the risk of failure is greatly minimized.
`> Personalization
`
`With both extensive customization choices available to the consumer on both the phone and
`
`desktop. and with the adaptive technologies based on actual usage, the consumer will find the
`experience familiar, pleasing and intimate.
`D Coverage
`
`Although this discussion has been primary focused on the feature phone, the consumer already is
`connected to the intemet with office and hone PCs, through the television and its STB, and possibly
`through other mobile devices such as laptops, PDAs, Blackberries, etc. Since this proposed
`platform can operate on all these devices, and can create an integrated and adaptive experience
`that will follow the consumer anywhere in this interconnected world, the intemet world becomes
`human centric, not device centric.
`
`' Docket: XPROOZPR
`
`30
`
`Page 877 of 1295
`
`Page 877 of 1295
`
`

`

`Systems and Methods for Presenting information on Mobile Devices
`
`The following appendices are illustrative of one embodiment of the present invention.
`
`Appendices
`
`Docket: XPFl002PFi
`
`31
`
`Page 878 of 1295
`
`Page 878 of 1295
`
`

`

`PTO/SB/14 (07-07)
`Approved for use through 06/30/2010. OMB 0651—0032
`U.S. Patent and Trademark Office; US. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995. no persons are required to respond to a collection of Information unless It contains a valid OMB control number.
`
`Application Data Sheet 37 CFR 1.75
`
`Application Number
`
`Aft
`
`D k tNumber
`
`XPR.002PR
`
`Title of Invention
`
`SYSTEMS AND METHODS FOR PRESENTING INFORMATION ON MOBILE DEVICES
`
`document may be printed and included in a paper filed application.
`
`The application data sheet is part of the provisional or nonprovisional application for which it is being submitted. The following form contains the
`bibliographic data arranged in a format specified by the United States Patent and Trademark Office as outlined in 37 CFR 1.76.
`This document may be completed electronically and submitted to the Office in electronic format using the Electronic Filing System (EFS) or the
`
`Secrecy Order 37 CFR 5.2
`
`
`
`E] Portions or all of the application associated with this Application Data Sheet may fall under a Secrecy Order pursuant to
`37 CFR 5.2 (Paper filers only. Applications that fall under Secrecy Order may not be filed electronically.)
`
`
`
`A- - licant Information:
`
`
`
`Applicant Authority ©lnventor
`m-‘
`
`Steven
`
`Ifi
`I:
`
`OLegal Representative under 35 U.S.C. 117
`Middle Name
`
`Party of Interest under 35 U.S.C. 118i
`
`Rempell
`
`
`
`
`
` ii
`
`
`
`
`
`
`Residence Information (Select One) 6) US Residency 0 Non US Residency 0 Active US Military Service
`Ci
`Novato
`State/Province
`Country of Residencei
`US
`
` !
`
`Citizenship under 37 CFR 1.41 (b) i
`Mailing Address of Applicant:
`Address 1
`38 Washington Street
`Address 2
`
`US
`
`City
`
`Novato
`
`Applicant Authority ©Invent0r
`
`I1’(D--2x
`
`David
`
`State/Province
`
`C
`
`OLegal Representative under 35 U.S.C. 117
`Middle Name
`
`Party of Interest under 35 U.S.C. 118i
`(n C:9,X
`
`Chrobak
`
`Residence Information (Select One) © US Residency 0 Non US Residency 0 Active US Military Service
`City
`Pleasant Hill
`State/Province
`Country of Residence i
`US
`
`Citizenship under 37 CFR 1.41 (b) I
`Mailing Address of Applicant:
`Address 1
`132 Shadowood Drive
`
`Address 2
`
`Pleasant Hill
`City
`Postal Code
`
`94523
`
`Applicant AUthority @lnventor
`Prefix
`
`Ken
`
`State/Province
`us
`
`CA
`
`Legal Representative under 35 U.S.C. 117
`Middle Name
`
`Party of Interest under 35 U.S.C. 118
`a: E:gx
`
`Brown
`
`Residence Information (Select One) 6) US Residency O Non US Residency 0 Active US Military Service
`E
`Ci
`State/Province
`Country of Residencei
`US
`EFS Web 2.2.1
`
`Page 879 of 1295
`
`Page 879 of 1295
`
`

`

`PTO/SB/14 (07-07)
`Approved for use through 06/30/2010. OMB 0651-0032
`U.S. Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE
`Under the PapenNork Reduction Act of 1995. no persons are required to respond to a collection of information unless It contains a valid OMB control number.
`
`
`
`
`Application Data Sheet 37 CFR 1. 76
`
`
`
`Title of Invention
`
`
`
`SYSTEMS AND METHODS FOR PRESENTING INFORMATION ON MOBILE DEVICES
`
`
`
`
`Citizenship under 37 CFR 1.41 (b) i
`Mailing Address of Applicant.
`
`generated within this form by selecting the Add button.
`
`All
`
`Inventors Must Be Listed - Additional Inventor Information blocks may be
`
`Correspondence Information:
`Enter either Customer Number or complete the Correspondence Information section below.
`For further information see 37 CFR 1.33(a).
`
`
`
`
`
`
`[:1 An Address is being provided for the correspondence Information of this application.
`Customer Number
`40280
`
`Email Address
`
`svosen@Pthatents.com
`
`gifg‘aaEEma’igfi
`
`
`m
`
`
`
`
`Application Information:
`
`
`Title of the Invention
`SYSTEMS AND METHODS FOR PRESENTING INFORMATION ON MOBILE DEVICES
`
`
`
`
`—_
`
`—— Suggested Figure for Publication (if any) -
`
`Publication Information:
`
`
`
`
`
`
`1:] Request Early Publication (Fee required at time of Request 37 CFR 1.219)
`
`Request Not to Publish. I hereby request that the attached application not be published under 35 U.S.
`E] C. 122(b) and certify that the invention disclosed in the attached application has not and will not be the subject of
`an application filed in another country, or under a multilateral international agreement, that requires publication at
`eighteen months after filing.
`
`
`
`
`
`
`Representative Information:
`
` Representative information should be provided for all practitioners having a power of attorney in the application. Providing
`
`
`this information in the Application Data Sheet does not constitute a power of attorney in the application (see 37 CFR 1.32).
`Enter
`either Customer Number
`or
`complete
`the Representative Name
`section
`below.
`If
`both
`sections
`are completed the Customer Number will be used for the Representative Information during processing.
`
`
`
`
`Please Select One:
`
`6) Customer Number
`
`0 us Patent Practitioner 0 Limited Recognition (37 CFR 11.9)
`
`
`
`
`EFS Web 2.2.1
`
`Page 880 of 1295
`
`Page 880 of 1295
`
`

`

`PTO/SB/14 (07—07)
`Approved for use through 06/30/2010. OMB 0651-0032
`US. Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995. no persons are required to respond to a collection of information unless it contains a valid OMB control number.
`
`
`
`
`
`
`_
`_
`Application Data Sheet 37 CFR 1.76
`
`Attorney Docket Number
`_
`.
`
`XPR.002PR
`
`
`
`Title of Invention
`
`SYSTEMS AND METHODS FOR PRESENTING INFORMATION ON MOBILE DEVICES
`
`I Customer Number
`
`I 40280
`
`
`|
`
`Domestic Benefit/National Stage Information:
`
`This section allows for the applicant to either claim benefit under 35 U.S.C. 119(e), 120, 121, or 365(c) or indicate National Stage
`
`
`
`entry from a PCT application. Providing this information in the application data sheet constitutes the specific reference required by
`35 U.S.C. 119(e) or 120, and 37 CFR 1.78(a)(2) or CFR 1.78(a)(4), and need not otherwise be made part of the specification.
`
`
`
`
`
`Additional Domestic Benefit/National Stage Data may be generated within this form
`
`by selecting the Add button.
`
`Application Number
`
`Continuity Type
`
`Prior Application Number
`
`Filing Date (YYYY—MM-DD)
`
`Foreign Priority Information:
`This section allows for the applicant to claim benefit of foreign priority and to identify any prior foreign application for which priority is
`not claimed. Providing this information in the application data sheet constitutes the claim for priority as required by 35 U.S.C. 119(b)
`and 37 CFR 1.55(a).
`
`Add button.
`
`Priority Claimed
`Parent Filing Date (YYYY-MM-DD)
`Application Number
`0 Yes ® No
`Additional Foreign Priority Data may be generated within this form by selecting the
`
`rm
`
`Assignee Information:
`
`Providing this information in the application data sheet does not substitute for compliance with any requirement of part 3 of Title 37
`of the CFR to have an assignment recorded in the Office.
`
`
`D
`If the Assignee is an Organization check here.
`Prefix
`Middle Name
`Family Name
`Suffix
`
`Malling Address information:
`
`
`AddressZ
`QQ
`
`
`
`
`
`
`
`
`
`
`
`
`
`Email Address
`
`
`Additional ASSIgnee Data may be generated Within this form by selecting the Add
`button.
`
`Fax Number
`Phone Number
`
`
`
`
`Signature:
`Ari-I A Al.n :__u__ 1-....- -lu._ -:_._-‘......
`
`A signature of the applicant or representative is required in accordance with 37 CFR 1.33 and 10.18. Please see 37
`EFS Web 2.2.1
`
`
`
`Page 881 of 1295
`
`Page 881 of 1295
`
`

`

`PTO/SBI14 (07—07)
`Approved for use through 06/30/2010. OMB 0651-0032
`u.s. Patent and Trademark Office: U.S. DEPARTMENT OF COMMERCE
`Under the Papenuork Reduction Act of 1995, no persons are required to respond to a oollectlon of Information unless it contains a valid OMB control number.
`
`Application Data Sheet 37 CFR 1.75
`
`Att
`
`D cket Number
`
`XPR.002PR
`
`Application Number Title of Invention
`
`SYSTEMS AND METHODS FOR PRESENTING INFORMATION ON MOBILE DEVICES
`
`
`
`
`
`
`m feat/H W
`
`
`
`
`This collection of information is required by 37 CFR 1.76. The information is required to obtain or retain a benefit by the public which
`is to file (and by the USPTO to process) an application. Confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1.14. This
`collection is estimated to take 23 minutes to complete, including gathering, preparing, and submitting the completed application data
`sheet form to the USPTO. Time will vary depending upon the individual case. Any comments on the amount of time you require to
`complete this form and/or suggestions for reducing this burden. should be sent to the Chief Information Officer, U.S. Patent and
`Trademark Office. US. Department of Commerce, PO. Box 1450, Alexandria, VA 22313-1450. DO NOT SEND FEES OR
`COMPLETED FORMS TO THIS ADDRESS. SEND TO: Commissioner for Patents, PO. Box 1450, Alexandria. VA 22313-1450.
`
`EFS Web 2.2.1
`
`Page 882 of 1295
`
`Page 882 of 1295
`
`

`

`8010170llllillilililllilllMilliHill“
`
`
`
`
`
`.I
`
`I;O
`I\)
`
`(O
`
`C
`<0
`‘D
`_'
`
`PTO/SENS (10-07)
`Approved for use through 08/30/2010. OMB 0651-0032
`US. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act of 1995, no persons are required to respond to a collection of Information unless it displays a valid OMB control number.
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET - Page 1 of 2
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c).
`prress Mail Label No. ED zgzfimgfi U§
`
`Given Name (first and middle [if any])
`
`Family Name or Surname
`'
`
`Ci
`
`Residence
`and either State or Forei un Count
`
`Steven H.
`
`Rempe"
`
`u.s. PTO
`61/123438
`04/07/2008
`
`
`
`
`Chrobak
`
`Pleasant Hill, CA
`
`San Martin, CA
`
`
`
`
`
`
`
`separately numbered sheets attached hereto
`Additional inventors are being named on the
`TITLE OF THE INVENTION (500 characters max):
`
`SYSTEMS AND METHODS FOR PRESENTING INFORMATION ON MOBILE DEVICES
`
`
`
`Country
`
`Telephone
`
` Direct all correspondence to: CORRESPONDENCE ADDRESS
`
`The address corresponding to Customer Number:
`
`
`40280
`OR
`
`
`
`Firm or
`
`
`individual Name
`Address
`
`
`
`
`
`
`
`
`
`ENCLOSED APPLICATION PARTS (check all that apply)
`
` Cl CD(s), Number of CDs Application Data Sheet. See 37 CFR 1.76
`
`[:1 Drawing(s) Number of Sheets
`D Other (specify)
`
`
`
`251
`Specification (e.g. description of the Invention) Number of Pages
`
`
`Fees Due: Filing Fee of $210 ($105 for small entity).
`If the specification and dra'iw ngs exceed 100 sheets of paper, an application size tee is
`
`also due. which is $2