Obviousness

To analyze the obviousness of US patent 11937145 under 35 U.S.C. § 103, we must consider prior art available before the patent's priority date of October 12, 2007. The provided patent text explicitly lists US 2009/0100342 A1 as the publication of application US 11/974,258, from which the present patent claims priority, and thus its disclosure as of its priority date serves as relevant prior art.

A direct ancestor, US 2009/0100342 A1, published on April 16, 2009, is based on a continuation-in-part application filed on October 12, 2007 (US 11/974,258), making its disclosure effective prior art for US 11937145.

The abstract of US 2009/0100342 A1 discloses a method and apparatus for automatically creating or updating a digital map to include a new location in response to a user's selection of location information from a software application. This includes:

• Receiving location information from a software application.
• Identifying location references in the information.
• Converting location references to geographic coordinates.
• Plotting the new location on a digital map.
• Adjusting the map's zoom level to include the new location.

The patent further details that the software application can be an email program, web browser, or other content-displaying application, and that the map can be displayed on a mobile device or desktop. It also describes selecting text (e.g., an address) from a non-mapping application and using a context menu or drag-and-drop to send it to a mapping component for display on a map. Critically, it describes displaying the new location on the "same digital map" with "previously-displayed mapping content" or on a "new digital map".

Obviousness Analysis of Claim 1

Claim 1 of US 11937145 describes:

1. A memory of a mobile device storing a first non-browser application and a second non-browser application.
2. A processor executing the first non-browser application.
3. A touch screen displaying a first user interface of the first non-browser application, showing a first map, an icon for a location, and associated text.
4. A GPS device determining the mobile device's location.
5. A mapping component in the first non-browser application communicating with an online mapping service.
6. Upon touch of the text, the mapping component transmits a query including the mobile device's location and the icon's location to the online mapping service.
7. In response, the touch screen displays in a second user interface of the second non-browser application a second map of the mobile device's location, the icon's location, and a route between them.

Combination of US 2009/0100342 A1 and General Knowledge/Common Practice in 2007:

US 2009/0100342 A1 clearly teaches many elements of Claim 1:

• A mobile device with memory and a processor, capable of running multiple applications and displaying maps (implied by "portable electronic device, such a smart phone, personal digital assistant, etc.").
• A mapping component that can receive location information from other applications (both browser and non-browser, e.g., "email program, word processing application, instant messenger client, etc.") and plot it on a map.
• The ability to select text (location information) from one application and relay it to a mapping component (via drag-and-drop or context menu) for display on a digital map.
• The concept of displaying multiple points of interest on a single map.
• The adjustment of zoom level to ensure all mappable content is visible.

What '342 A1 doesn't explicitly state in combination with all aspects of Claim 1:

• The explicit distinction between a "first non-browser application" displaying a map with an icon and text, and a "second non-browser application" receiving the query result. While it discusses different applications sending data to a mapping component, the specific structure of two non-browser apps where the first already has a map/icon/text and the second then displays a route is not explicitly delineated.
• The explicit inclusion of the mobile device's current GPS location in the query transmitted upon touching the text, along with the icon's location, specifically for the purpose of generating a route between these two points in a second application. While '342 A1 mentions obtaining geographic coordinates and plotting them, and implies device location (e.g., for navigation), it doesn't explicitly tie the device's live GPS location to the query triggered by user interaction with an icon's text in another app, for the specific purpose of showing a route to that icon.

However, a person having ordinary skill in the art (PHOSITA) in 2007 would have understood the following:

• Mobile devices with GPS capabilities: GPS devices were common in mobile phones and PDAs by 2007, and mapping applications routinely used the device's current GPS location to center maps or provide "current location" markers.
• Online mapping services offering routing: Services like Google Maps, Yahoo! Maps, and MapQuest were well-established by 2007 and commonly provided driving directions (routes) between two or more specified locations.
• Inter-application communication: Techniques for applications to communicate and share data (e.g., via APIs, intents, or clipboard operations) were known in mobile operating systems (e.g., early versions of iOS and Android, as well as Windows Mobile and Palm OS).

Motivation to Combine:

A PHOSITA would have been motivated to combine the teachings of US 2009/0100342 A1 with common knowledge regarding mobile device capabilities and online mapping services for the following reasons:

1. Enhanced User Experience for Navigation: The primary motivation for combining a known location (from an icon/text) with the user's current GPS location and displaying a route is to facilitate navigation. If a user sees an interesting point on a map in one application (as disclosed in '342 A1), they would naturally desire to get directions to that point from their current location. Automatically transmitting both locations in a query and displaying a route would be an obvious and desirable enhancement to the "mashing mapping content" functionality taught by '342 A1.
2. Convenience and Efficiency: Requiring a user to manually input their current location into a mapping application after selecting a destination from another app ('342 A1) would be cumbersome. Automatically including the device's GPS location in the query streamline this process, making the mapping feature more convenient and efficient for the user.
3. Leveraging Existing Technologies: The components for this combination (GPS, online routing services, inter-application data transfer) were all independently known and mature by 2007. It would have been a straightforward engineering decision to integrate these existing functionalities with the content-mashing capabilities described in '342 A1 to provide a more complete and useful navigational experience. The abstract of US 2009/0100342 A1 itself identifies "navigation devices" as one example of devices that may utilize the invention.
4. Optimized Display for Routing: While '342 A1 focuses on displaying multiple points of interest, the specific requirement of Claim 1 to display a "second map" in a "second non-browser application" with a route is a natural extension. A dedicated mapping application (potentially a "second non-browser application") is typically better equipped to handle dynamic route calculations and display, rather than simply plotting points on an existing, potentially less specialized, map displayed in a "first non-browser application." This division of labor between applications is a common software design pattern.

Therefore, a PHOSITA would have found it obvious to combine the functionality of "mashing mapping content" from disparate applications onto a map (as taught by US 2009/0100342 A1) with the common knowledge of GPS location services on mobile devices and online mapping services' routing capabilities. The motivation would be to provide a more practical, convenient, and feature-rich user experience for mobile navigation, specifically by automatically calculating and displaying a route from the user's current location to a newly selected point of interest.

The distinction of using a "second non-browser application" for the route display, when the "first non-browser application" already has a map, would be an obvious implementation choice to leverage existing, potentially specialized, mapping applications for routing tasks, or to separate concerns in software design.