U.S. patent application number 15/005011 was filed with the patent office on 2016-05-19 for dynamic menus for multi-prefix interactive mobile searches.
The applicant listed for this patent is TROPARE, INC.. Invention is credited to G Gregory Carpenter, Timothy L Kay.
Application Number | 20160140127 15/005011 |
Document ID | / |
Family ID | 46689891 |
Filed Date | 2016-05-19 |
United States Patent
Application |
20160140127 |
Kind Code |
A1 |
Carpenter; G Gregory ; et
al. |
May 19, 2016 |
Dynamic Menus for Multi-Prefix Interactive Mobile Searches
Abstract
The present invention includes systems and methods for
retrieving information via a flexible and consistent targeted
search model that employs interactive multi-prefix, multi-tier and
dynamic menu information retrieval techniques that provide
context-specific functionality tailored to particular information
channels, as well as to records within or across such channels, and
other known state information. Users are presented with a
consistent search interface among multiple tiers across and within
a large domain of information sources, and need not learn different
or special search syntax. A thin-client server-controlled
architecture enables users of resource-constrained mobile
communications devices to locate targeted information more quickly
by entering fewer keystrokes and performing fewer query iterations
and web page refreshes, which in turn reduces required network
bandwidth.
Inventors: |
Carpenter; G Gregory;
(Laguna Beach, CA) ; Kay; Timothy L; (Los Altos
Hills, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
TROPARE, INC. |
Laguna Beach |
CA |
US |
|
|
Family ID: |
46689891 |
Appl. No.: |
15/005011 |
Filed: |
January 25, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14593142 |
Jan 9, 2015 |
9251278 |
|
|
15005011 |
|
|
|
|
14096363 |
Dec 4, 2013 |
8965913 |
|
|
14593142 |
|
|
|
|
13563669 |
Jul 31, 2012 |
8639713 |
|
|
14096363 |
|
|
|
|
12142725 |
Jun 19, 2008 |
8255382 |
|
|
13563669 |
|
|
|
|
12620195 |
Nov 17, 2009 |
8255411 |
|
|
13563669 |
|
|
|
|
61048073 |
Apr 25, 2008 |
|
|
|
60947099 |
Jun 29, 2007 |
|
|
|
60945300 |
Jun 20, 2007 |
|
|
|
61247440 |
Sep 30, 2009 |
|
|
|
61149281 |
Feb 2, 2009 |
|
|
|
61115665 |
Nov 18, 2008 |
|
|
|
Current U.S.
Class: |
707/723 |
Current CPC
Class: |
G06F 16/9535 20190101;
G06F 3/0482 20130101; G06F 16/24578 20190101; G06F 16/3322
20190101; G06F 16/24539 20190101; G06F 3/0488 20130101; G06F 16/245
20190101; G06F 16/9537 20190101; G06F 16/248 20190101 |
International
Class: |
G06F 17/30 20060101
G06F017/30; G06F 3/0488 20060101 G06F003/0488; G06F 3/0482 20060101
G06F003/0482 |
Claims
1. An interactive information retrieval system, including
non-transitory computer-accessible storage media, that searches a
database of content items, the system comprising: a. a multi-prefix
search module, embodied in a first non-transitory
computer-accessible storage medium, that receives keystrokes as
they are entered by a user into a mobile device, searches for
content items within the database that contain words having a
prefix matching the keystrokes, and generates a first-tier set of
search results containing matching content items; b. a first-tier
search result delivery module, embodied in the first non-transitory
computer-accessible storage medium, that delivers the first-tier
set of search results to the mobile device; c. a client
application, embodied in a second non-transitory
computer-accessible storage medium on the mobile device that sorts
at least a portion of the first-tier set of search results
utilizing a data set from the mobile device and displays the sorted
portion of the first-tier set of search results to the user of the
mobile device.
2. The interactive information retrieval system of claim 1, wherein
the data set comprises a predefined channel of content items.
3. The interactive information retrieval system of claim 1, wherein
the data set comprises a user-defined location.
4. The interactive information retrieval system of claim 1, wherein
the data set comprises a location obtained from a GPS module of the
mobile device.
5. The interactive information retrieval system of claim 1, wherein
the data set comprises one or more results of a prior search by the
user.
6. The interactive information retrieval system of claim 1, wherein
the data set comprises a time of day obtained from the mobile
device.
7. The interactive information retrieval system of claim 1, wherein
the data set comprises a telephone number stored on the mobile
device.
8. The interactive information retrieval system of claim 1, wherein
the data set comprises an email address stored on the mobile
device.
9. The interactive information retrieval system of claim 1, wherein
the data set comprises a text message address stored on the mobile
device.
10. The interactive information retrieval system of claim 1,
wherein the data set comprises an image stored on the mobile
device.
11. The interactive information retrieval system of claim 1,
wherein the data set comprises a data set accessible by the mobile
device from a website.
12. The interactive information retrieval system of claim 1,
wherein at least one of the sorted portion of the first-tier set of
search results is associated with a dynamic menu item.
13. The interactive information retrieval system of claim 12,
wherein when the dynamic menu item can be activated in a first
manner by the user using a first gesture or in a second manner by
the user using a second gesture, the first and second gestures
being different gestures.
14. The interactive information retrieval system of claim 13,
wherein the first manner of activation comprises pressing a
touchscreen of the mobile device proximate to the dynamic menu item
for a first length of time.
15. The interactive information retrieval system of claim 14,
wherein the second manner of activation comprises pressing the
touchscreen of the mobile device proximate to the dynamic menu item
for a second length of time, the second length of time being longer
than the first length of time.
16. The interactive information retrieval system of claim 14,
wherein the first manner of activation selects the dynamic menu
item.
17. The interactive information retrieval system of claim 15,
wherein the second manner of activation actuates the dynamic menu
item.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. patent
application Ser. No. 14/593,142 entitled "Dynamic Menus for
Multi-Prefix Interactive Mobile Searches," filed Jan. 9, 2015;
which in turn claims the benefit of U.S. patent application Ser.
No. 14/096,363 entitled "Dynamic Menus for Multi-Prefix Interactive
Mobile Searches," filed Dec. 4, 2013; which in turn claims the
benefit of U.S. patent application Ser. No. 13/563,669 entitled
"Dynamic Menus for Multi-Prefix Interactive Mobile Searches," filed
Jul. 31, 2012 and issued as U.S. Pat. No. 8,639,713; U.S. patent
application Ser. No. 12/142,725 entitled "Dynamic Menus for
Multi-Prefix Interactive Mobile Searches," filed Jun. 19, 2008 and
issued as U.S. Pat. No. 8,255,382; Provisional Patent Application
No. 61/048,073 entitled "Multi-Tier Desktop Search," filed Apr. 25,
2008; Provisional Patent Application No. 60/947,099 entitled
"Dynamic Menu Feature," filed Jun. 29, 2007; and Provisional Patent
Application No. 60/945,300 entitled "Dynamic Menu Feature" filed
Jun. 20, 2007. This application also claims priority to U.S. patent
application Ser. No. 12/620,195 entitled "Dynamic Menus for
Multi-Prefix Interactive Mobile Searches." filed Nov. 17, 2009 and
issued as U.S. Pat. No. 8,255,411, which in turn claims the benefit
of U.S. Provisional Patent Application No. 61/115,665 entitled
"Smart PreFix Query Optimization," filed Nov. 18, 2008; U.S.
Provisional Patent Application No. 61/149,281 entitled "Smart
Prefix Query Optimization," filed Feb. 2, 2009; and U.S.
Provisional Patent Application No. 61/247,440 entitled "Building
and Sharing Apps Using Collaborative Services," filed Sep. 30,
2009. Each of the patent applications cited herein are incorporated
herein by reference in their entireties.
BACKGROUND
[0002] 1. Field of Art
[0003] This application relates generally to the field of
information retrieval and, in particular, to multi-prefix,
multi-tier, dynamic menu and related interactive search techniques
that facilitate the retrieval of information within a mobile
communications environment.
[0004] 2. Description of Related Art
[0005] In the last few years, web-enabled mobile telephones have
become enormously popular. More web-enabled mobile phones ship each
year than do desktop and notebook computers combined. Such mobile
phones are similar to desktop and mobile computers in that they
offer display screens, a keyboard, and, sometimes, a pointing
device. However, because of portability requirements, the
capabilities of the displays, keyboards, and pointers on mobile
phones are significantly reduced. Displays are relatively small
with little area to display content as well as menus, toolbars, and
other navigation and status information. The keyboards are often
telephone keypads or thumb keyboards. The pointer, when provided,
is often a scroll wheel or joystick that can be used to indicate a
direction of movement or pressed to indicate a click. Sometimes,
the pointer is simply a set of arrow keys on the keyboard.
Furthermore, because of speed and latency issues, navigation among
web pages is typically much slower on mobile phones than on desktop
and notebook computers.
[0006] The human interface limitations of mobile phones, combined
with slower navigation, significantly constrain a user's ability to
interact with web pages. Additionally, Hypertext Markup Language
(HTML) forms are difficult to use on mobile phones due to data
input and related limitations. These difficulties arise in many
ways. For example, the mobile keyboard and pointer are less
effective than their counterparts on desktop and personal
computers.
[0007] Keyboards are less effective because their small form factor
makes it more difficult to type characters. In some case, the
keyboard is smaller and has fewer keys. The smaller keyboards
usually require thumbing: typing with one's thumbs rather than
using ten fingers. The reduction in keys makes it more difficult to
key in digits and special characters. Some keyboards are telephone
dial pads with multiple letters on each key. Various technologies,
including triple tap (pressing the same key until the desired
letter appears) and predictive text, help to improve the
effectiveness of such keyboards, but the effectiveness is still far
below that of a full-size keyboard.
[0008] The pointer is also less effective. HTML forms often contain
multiple input fields and the pointer is used to navigate among
them. Pointers on mobile phones, when available, are less effective
than pointers or mice used with desktop computers for navigating
among input fields, as well as hyperlinks and other screen objects.
For example, tabbing between fields using a full-size keyboard
enables the field for typing when it has received focus. On a
mobile phone, the tabbing is typically done via a directional pad
and the field often has to subsequently be selected to be enabled
for typing. Additionally, on desktop computers, mice can be used to
move from one field to another without having to move through the
fields in between. On mobile phones, moving from one field to
another is typically done sequentially from one field to the next,
without the ability to skip any fields along the way.
[0009] However, some web-enabled mobile phones have touchscreens
that provide for direct interaction with objects on the display
screen. For example, users can touch a screen object directly with
their fingertip or a stylus, rather than indirectly navigate to
that object via a pointing device. Yet, even this "improved" user
interface technique raises usability issues, as the distinction
between "selecting" and "activating" an object becomes blurred.
Potential solutions for distinguishing the two include providing an
icon or other visible identifier on a portion of the object, or
discerning the number of times a user clicks or taps it, or the
amount of time a user "presses down" on the object.
[0010] In any event, the ability to select an object without also
activating it becomes particularly important in systems that
provide alternative functionality specific to a particular object.
For example, when a user activates an HTML hyperlink in a web
browser, the program typically navigates to a new web page
corresponding to the URL embedded within that hyperlink object. The
user, however, might want to examine the URL before making the
decision to activate the hyperlink.
[0011] A common mechanism for offering a user alternative
functionality specific to a selected object is a "context menu."
Context menus provide a user with one or more alternative functions
available within a particular "context" or state of a program or
device, such as the selection of a particular object. Context menu
items can change dynamically as the context changes, as different
objects are selected and as a program enters a different state.
[0012] In a mobile communications environment, however, providing
context menus with which users can quickly interact is easier said
than done. The state of an information retrieval system can change
frequently, for example, as new search results are received from
remote servers (or as information becomes known to the system, such
as the time of day or a user's location as indicated by a mobile
phone's GPS equipment). In addition to the problem noted above of
distinguishing the selection from the activation of an object,
other constraints include processing speed and memory limitations
on mobile devices, as well as bandwidth and latency limitations
inherent in mobile communications networks. These constraints,
coupled with the many different types of information that can be
retrieved from remote web sites, for example, make it even more
difficult to provide context menu items that are customized to
particular objects or categories of objects.
[0013] In contrast to the "random" full-text searches users often
perform on desktop computers in home and office environments (in
which multiple iterative searches and analyses of resulting web
pages can be completed relatively quickly due to greater bandwidth
and local computing resources), users in a mobile communications
environment often perform more "targeted" searches for lists,
schedules and other information the existence and perhaps even the
location of which is often known in advance. Such information must
nevertheless be retrieved relatively quickly in order to be useful.
For example, common mobile searches include requests for stock
quotes, sports scores, movie times and nearby restaurants or coffee
shops, to name a few.
[0014] Targeted searches are less amenable to the random keyword
search techniques commonly employed on existing desktop and mobile
devices, in which users enter complete keywords and navigate
through results and web pages across a large domain of web sites.
Mobile devices, in particular, are in need of solutions in which
targeted information can be found relatively quickly with minimal
user interaction. Such solutions ideally would still afford users
access to both the breadth of a large domain of information (such
as the web with its diverse collection of web sites, or a large
enterprise database) and the depth of any particular "channel" or
information category (which may lend itself to unique
functionality, whether within or across one or more web sites or
databases).
[0015] Some mobile devices support applications that have been
customized for highly targeted information retrieval, such as the
"Pocket Express" application from Handmark Inc.
(http://express.handmark.com/) which provides discrete modules for
retrieving news, stock quotes, sports scores and various other
specific types of information. Though useful for rapid retrieval of
certain specific data, the domain of available information is
inherently very limited, in part because each desired category of
information requires its own custom module. Such an approach is not
very scalable, given the vast array of information channels
available via the web. Moreover, without a generic mechanism to
locate information by searching within a particular module, users
typically are limited to browsing or selecting items from within
each module's predefined data structure. For example, users can
browse news headlines and select one to retrieve the full story,
but they cannot search for particular news stories, much less
headlines.
[0016] Other products have attempted to reduce user interaction to
perform targeted searches by enabling users to enter only word
prefixes or word fragments, and providing results interactively as
a user types characters. See, for example, a presentation at Google
(http://video.google.com/videoplay?docid=7012265262667474421&-q=type%3Ago-
ogle+engEDU) in this area, or the "vTap" program from Veveo, Inc.
(http://www.vtap.com), as well as Veveo's various published patent
applications, including both PCT publications (WO/2007/062035) and
US publications (2008011473, 20080086704, 20070255693, 20070130128,
20070088681, 200701754, 20070050337, 20070005563 and 20060101499).
While providing an information retrieval mechanism that is more
suitable to targeted searches, such approaches nevertheless lack a
generic search mechanism that can be utilized to narrow a search
request within a broad domain of information channels (to provide a
more focused or targeted search), as well as provide additional
functionality specific to particular channels.
[0017] Google, in a recent talk
(http://jhtc.org/meeting.php?meeting=march08), discussed a
"multi-tier" search technique in which a user first searches for a
web site (for example, "Wikipedia"), the result of which contains
not only a link to that site, but also a search box in which a
"second-tier" search can be typed (thus saving the step of clicking
on the link and then typing in the second-tier search). Other
similar solutions include special search keywords that identify the
second-tier site within the search query itself. Such solutions
rely, however, on the differing search engines available across
various second-tier sites, which not only force users to adapt to
different search query formats, but also may provide inferior
results when compared to more powerful search engines such as the
one provided by Google. A more integrated multi-tier approach could
avoid such anomalies by providing a consistent search mechanism
among various tiers (within as well as across particular
information channels), particularly one which also offered
additional context-specific functionality.
[0018] In short, existing technologies have not adequately
addressed the problems intrinsic to targeted searches, particularly
when conducted in a mobile communications environment. Information
must be retrieved more quickly, but with less user interaction, in
light of the hardware, user interface, network bandwidth and
latency limitations inherent in such an environment. In addition, a
more integrated and scalable search mechanism is needed to allow
users to request information from a broad domain of information
channels and quickly locate desired information within one or more
of those channels, preferably with the availability of additional
functionality that is tailored to those channels within the context
of user requests and other available state information.
[0019] The present invention addresses the problems discussed above
by employing novel combinations of various information retrieval
techniques designed to facilitate targeted searches, particularly
in a mobile communications environment. In one embodiment,
multi-prefix search techniques are employed in an effort to
minimize a user's data entry requirements. Moreover, user queries
can be executed on a remote server interactively, during the query
construction process, with results transmitted back for display so
as to enable users, prior to entering an entire query, to revise
that query or select a desired result.
[0020] To facilitate targeted searches, users can employ multi-tier
search techniques to constrain queries to one or more information
channels. In one embodiment, users can simply select one or more
channels from a list, which could include previously designated
"favorite" channels. In another embodiment, users can employ
multi-prefix searches to locate desired channels as well as desired
information within particular channels (and, in some cases, within
multiple tiers of one or more such channels).
[0021] For example, after locating a "yellow pages" channel with a
"first-tier" search (such as "yel pag"), the user might be
presented with a "second-tier" opportunity to search for "zip
codes." After entering only a few digits, the user might see the
desired zip code result displayed and, upon selecting it, be
presented with a "third-tier" opportunity to search for a vendor
within that selected zip code. Such a multi-tier approach
facilitates targeted mobile searches by reducing user interaction
and data entry, and, in another embodiment, by leveraging a
consistent multi-prefix search mechanism among multiple tiers.
[0022] In one embodiment, a mobile communications device includes a
window, which comprises a search area and a results area. An
application is launched and a landing page is displayed in a
display area of the mobile communications device. The search area
includes a search query field. A keystroke is inputted into a
search query field and a multi-prefix search is performed. The
landing page within the display area is replaced by the results of
the search. The results contain a first tier of search results,
which can include channels or links to web pages associated with
the user input. If the selected search result is a channel, the
channel is displayed. If it is a web page, the web page is
displayed. In other embodiments, a separate web browser application
is launched and the web page is displayed via the web browser
application. The channel or the web page may then be searched or
explored. If the desired channel is not displayed within the first
tier of search results, one or more additional keystrokes may be
inputted. Again, the results page refreshes accordingly and
additional keystrokes may be entered until the desired channel is
displayed.
[0023] The above-described embodiments provide for multi-prefix,
interactive search capability on a mobile communications device.
Prefix delimiters denote the beginning of another search prefix. In
some embodiments, space characters may be used as prefix
delimiters. In other embodiments, users may input space character
keystrokes as well as alphabetic or numeric keystrokes. If a user's
query seeks results containing multiple words, the user might enter
one or more prefixes of such words separated by spaces to create a
multi-prefix search query. The embodiments described above enable
users to enter fewer keystrokes to obtain a desired search result.
The search is interactive because a user is provided feedback (the
displayed search results are refreshed) with each keystroke (or, in
another embodiment, after a predefined time lapse between
keystrokes). Based on partial query results, a user can determine
that a search is complete and obtain the desired search result
without having to enter the entire text or word of one or more
search terms.
[0024] To further leverage targeted searches, in which search
results often share common attributes (including similar types of
fields and data formats), the data extracted from an information
channel (from a given web site, for example, or a portion thereof)
can, in one embodiment, be pre-processed for functional as well as
aesthetic display purposes. Whether captured as keywords via a "web
crawling" engine, or as structured data via higher-level data
extraction techniques (with or without the assistance of the
proprietor of the data), such channel data typically is or can be
organized into separate "records" (such as individual restaurants,
books or movies) containing discrete "fields" that represent
different types of data (such as titles, dates, addresses and phone
numbers) common to some or all records. This is primarily due to
the fact that most web sites employ databases (typically standard
relational, flat-file or object-oriented databases) as the
underlying organizational structure for their data.
[0025] In one embodiment, channel data records and fields can be
indexed as such in order to enable structured searches based upon
these records and fields. In another embodiment, the indexing
process ignores data field distinctions but is optimized for
multi-prefix searches. The frequency of extracting data from remote
information sources (whether for indexing or otherwise) will vary
depending upon how frequently such data typically will be updated.
For example, sports scores may be updated more frequently than
movie listings, which in turn may be updated more frequently than
restaurant listings. Whether or not field (or other) metadata is
retained during the indexing process (if any), the channel data
still may be susceptible to "field recognition" sufficient to
enable the performance of discrete actions specific to a particular
field. For example, if standard ten-digit phone numbers can be
extracted from individual channel data records, such as
restaurants, then such extracted data can be used to enable actions
specific to a particular record, such as using a mobile phone
device to call one of the restaurants displayed in the result list
of a user's query.
[0026] Having extracted and maintained field data related to one or
more channels (or even to particular records within one or more
channels), various contextual actions can be enabled as
alternatives to simply selecting and activating a particular record
(which might activate a hyperlink to a web page related to that
record). In one embodiment, "dynamic menus" are employed to enable
a wide variety of alternative actions specific to a selected
record, including calling a person or a place, sending a selected
person an email, SMS or other type of message, utilizing a known
location (of a user's mobile device, for example, via GPS data, or
of a particular place in the result list of a user's query) to view
the location of, or directions to, nearby places, or to obtain a
map of a desired area, or even linking to a web page related to a
particular aspect of a record (to display, for example, images of a
selected person). The possibilities are virtually limitless, as
they may involve not only actions of which a mobile communications
device is capable (such as initiating phone calls and sending
messages), but also actions relating to the channel data being
retrieved, which are as numerous as the many different types of
information available throughout the Internet.
[0027] This relationship, between different fields or types of
available data and the actions that relate to such data, can be
leveraged, even in a mobile communications environment, not only by
pre-processing the channel data itself, but by pre-defining the
related actions specific to that channel data (with or without the
assistance of the proprietor of the channel data) and transmitting
them, in response to user queries, along with the channel data
query results. In one embodiment, these actions are transmitted to
a user's mobile device in the form of Hypertext Transfer Protocol
("HTTP") headers that define both the name of a dynamic menu item
and the action to be taken if the user selects and/or activates
that item (and are followed by the "body" of the transmission
including, for example, the results of a user's query). In another
embodiment, if the functionality of the client application on the
user's mobile device is integrated into a web browser (using, for
example, Javascript and an Ajax application), then these HTTP
headers can be incorporated into the body of the transmission
itself.
[0028] For example, if a user employs a multi-prefix query to
search a channel containing a collection of restaurant records, the
server might return a series of HTTP headers (followed by the
resulting restaurant records matching the user's query)
representing dynamic menu items that enable the user to initiate a
call to a selected restaurant, or obtain a map and directions to
that restaurant from a given location. Yet, if that user queried a
different channel containing, for example, a collection of movie
records, then the HTTP headers delivered with the results of the
user's query might represent a different set of dynamic menu items
providing actions such as displaying movie reviews, or playing
video trailers.
[0029] In other embodiments, these dynamic menu items and their
associated actions might vary depending not only upon the channel
being queried, but upon the particular channel records the user
selects. For example, in one embodiment, if a selected record did
not contain a value for a particular field (such as a phone
number), then any corresponding dynamic menu item relating to that
field (such as a "Call Restaurant" item) would not appear, because
the action could not be performed. More generic "dynamic dynamic
menus" can be implemented, in another embodiment, by integrating
menu item names and associated actions as discrete data fields
within one or more channel records. As a result, menu item names
and actions will vary as a user selects different records, even
within a given channel. In yet another embodiment, certain actions,
such as dialing a selected restaurant, can be invoked without
requiring a user to display, select or activate a dynamic menu
item. Instead, a user might simply press a key or push a button on
the user's mobile device (such as the "Talk" button) to which such
actions have been mapped. As noted above, dynamic menu items might
also vary depending upon any particular state of a user's query or
other known information, such as whether a user has logged into a
particular web site (in which case a "Log In" menu item and
associated action might alternate with a "Log Out" menu item and
action, depending upon the user's login state).
[0030] In other embodiments, information channels can be
implemented as a type of "smart bookmark" in a mobile web browser.
After a user selects (or searches for) one or more channels, the
user may perform a "second-tier" search constrained to that channel
utilizing, for example, an interactive multi-prefix query. A mobile
search engine can provide similar functionality, whether or not
integrated into a mobile web browser. Such functionality can be
enabled, in one embodiment, by pre-processing channel data as
described above at a remote server from which search results are
transmitted. Moreover, dynamic menus can be implemented in a manner
similar to that described above by transmitting menu items and
associated actions along with such interactive search results. In
yet another embodiment, such functionality can be implemented as a
standalone application limited to one or more predefined
channels.
[0031] When a consistent targeted search mechanism (such as one
that employs the interactive multi-prefix and multi-tier
information retrieval techniques described above) is coupled with a
dynamic menu mechanism that provides context-specific functionality
(tailored, for example, to particular channels, records within or
across those channels, or other state information), users are
presented with a consistent search interface among multiple tiers
across and within information channels, and need not learn
different or special search syntax. Moreover, due to the
constraints of a mobile communications environment, data entry
requirements are limited, enabling users to enter fewer keystrokes
and perform fewer query iterations, which in turn reduces network
bandwidth in both directions, due in part to the interactive nature
of the multi-prefix search mechanism. As a result, users can obtain
desired results quickly, or revise queries, even before completing
an intended query.
[0032] For example, a user with a particular preference for
Starbucks coffee might want to locate the closest Starbucks coffee
shop quickly while traveling in an unfamiliar city, and then call
that shop to ensure the user's order is ready upon arrival. Upon
entering a few keystrokes into a mobile phone device, a local
yellow pages channel can be located (assuming a "favorite"
Starbucks channel was not present) and queried for a nearby
Starbucks coffee shop, perhaps using the phone's GPS data by
default as a base location. Due to a consistent multi-prefix search
interface, data entry is limited, and channel-specific
functionality can then be invoked. For example, a phone number
field, associated with the user's selected Starbucks record, can
then be leveraged via a simple mechanism, such as a phone button or
dynamic menu item, to enable the user to call the desired Starbucks
coffee shop and place an order. Another dynamic menu item might
provide a map and directions to that Starbucks, enabling the user
to arrive in time to pick up that order. Most importantly, all of
this functionality can be provided within the context of a highly
constrained mobile communications environment.
[0033] The features and advantages described in the specification
are not all inclusive, and, in particular, many additional features
and advantages will be apparent to one of ordinary skill in the art
in view of the drawings, specification and claims. Moreover, it
should be noted that the language used in the specification has
been principally selected for readability and instructional
purposes, and may not have been selected to delineate or
circumscribe the disclosed subject matter.
BRIEF DESCRIPTION OF DRAWINGS
[0034] FIG. 1A illustrates an environment adapted to support
multi-prefix, interactive searching on a mobile communications
device in accordance with some embodiments.
[0035] FIG. 1B is a high level block diagram illustrating the data
structure contained within the channel database in accordance with
some embodiments.
[0036] FIG. 2 is a high level block diagram illustrating a
functional view of a typical mobile communications device in
accordance with some embodiments.
[0037] FIG. 3A is a flowchart illustrating a process of
client-server interaction during multi-prefix, interactive
searching in accordance with some embodiments.
[0038] FIG. 3B is a flowchart illustrating a process of
client-server interaction during multi-prefix, interactive
searching in accordance with some other embodiments.
[0039] FIG. 3C is a flowchart illustrating a process of
client-server interaction during multi-prefix, interactive
searching in accordance with some other embodiments.
[0040] FIG. 4 is a flowchart illustrating a process for interactive
searching in accordance with some embodiments.
[0041] FIG. 5 is a flowchart illustrating a process for creating a
multi-term prefix index in accordance with some embodiments.
[0042] FIG. 6 is a flowchart illustrating a process for creating a
table of contents in accordance with some embodiments.
[0043] FIG. 7 is a flowchart illustrating a process for sending
interactive search results in accordance with some embodiments.
[0044] FIG. 8 is a flowchart illustrating a process for sending
interactive search results in accordance with some embodiments.
[0045] FIGS. 9A-9M illustrate graphical representations of
screenshots of a display of a mobile communications device in
accordance with some embodiments.
[0046] FIGS. 10A-10C illustrate graphical representations of
screenshots of a display of a mobile communications device in
accordance with another embodiment.
[0047] FIGS. 11A-11C illustrate graphical representations of
screenshots of a display of a mobile communications device in
accordance with an embodiment of the dynamic menu aspect of the
present invention.
[0048] FIGS. 12A-12G illustrate graphical representations of
screenshots of a display of a mobile communications device in
accordance with another embodiment of the dynamic menu aspect of
the present invention.
[0049] The figures depict various embodiments of the present
invention for purposes of illustration only. One skilled in the art
will readily recognize from the following discussion that
alternative embodiments of the structures and methods illustrated
herein may be employed without departing from the principles of the
invention described herein.
DETAILED DESCRIPTION
[0050] The Figures (FIGS.) and the following description relate to
preferred embodiments by way of illustration only. It should be
noted from the following discussion that alternative embodiments of
the structures and methods disclosed herein will be readily
recognized as viable alternatives that may be employed without
departing from the principles of what is claimed.
[0051] Reference will now be made in detail to several embodiments,
examples of which are illustrated in the accompanying figures. It
is noted that wherever practicable similar or like reference
numbers may be used in the figures and may indicate similar or like
functionality.
[0052] The figures depict embodiments of the disclosed system (or
method) for purposes of Illustration only. One skilled in the art
will readily recognize from the following description that
alternative embodiments of the structures and methods illustrated
herein may be employed without departing from the principles
described herein.
I. Search Architecture
[0053] FIG. 1A is a block diagram illustrating an architecture for
providing multi-prefix, interactive search capability on a mobile
communications device. The network 122 enables communications
between a client 118 and a search server 128 coupled to a data
store 112. Thus, the network 122 can include links using
technologies such as Wi-Fi, Wi-Max, 2G, Universal Mobile
Telecommunications System (UMTS), 3G, Ethernet, 802.11, integrated
services digital network (ISDN), digital subscriber line (DSL),
asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced
Switching, etc. Similarly, the networking protocols used on the
network 122 can include the transmission control protocol/Internet
protocol (TCP/IP), multi-protocol label switching (MPLS), the User
Datagram Protocol (UDP), the hypertext transport protocol (HTTP),
the simple mail transfer protocol (SMTP), the file transfer
protocol (FTP), lightweight directory access protocol (LDAP), Code
Division Multiple Access (CDMA), Wideband Code Division Multiple
Access (WCDMA), Global System for Mobile communications (GSM),
High-Speed Downlink Packet Access (HSDPA), etc. The data exchanged
over the network 122 can be represented using technologies and/or
formats including the hypertext markup language (HTML), the
extensible markup language (XML), etc. In addition, all or some of
links can be encrypted using conventional encryption technologies
such as the secure sockets layer (SSL), Secure HTTP and/or virtual
private networks (VPNs) or Internet Protocol security (IPsec). In
another embodiment, the entities can use custom and/or dedicated
data communications technologies instead of, or in addition to, the
ones described above. Depending upon the embodiment, the network
122 can also include links to other networks such as the
Internet.
[0054] The client 118 executes a browser 120, comprises client
applications 124 and can connect to the search server 128 via a
network 122, which is typically the Internet, but may also be any
network, including but not limited to a LAN, a MAN, a WAN, a
mobile, wired or wireless network, a private network, or a virtual
private network, and any combination thereof. While only a single
client 118 is shown, it is understood that very large numbers
(e.g., millions) of clients are supported and can be in
communication with the search server 128 and search result update
module 116 at any time. The client 118 may be a mobile
communications device similar to the one described in FIG. 2.
[0055] The search server 128 includes a search result update module
116, a multi-prefix search module 150, a multi-tier search module
152, and a result delivery search module 154. The search server 128
facilitates multi-prefix, multi-tier, interactive searching by
enabling a user to enter prefixes of words or text of a search
query to obtain various tier levels of search results. The search
server 128 also facilitates multi-prefix, interactive, result
delivery searching by enabling a user to enter prefixes of words or
text to obtain desired results without having to go through
intermediary steps to get those results. The search server 128 also
facilitates multi-prefix searching on a mobile communications
device.
[0056] The search result update module 116 facilitates the update
of the search results when a user inputs a keystroke (or pauses for
a certain amount of time after entering multiple keystrokes),
therefore allowing for interactive search capability. Multi-prefix
search module 150 facilitates multi-prefix searching by providing
the user the ability to enter the prefix of one or more words of an
entire query to obtain desired search results. The multi-tier
search module 152 facilitates multi-tier searching by providing
different tier levels of results. The result delivery search module
154 facilitates result delivery by searching a plurality of data
fields associated with a particular data set in order to produce
desired results. Further description regarding usage of these
modules is provided below.
[0057] The search server 128 is coupled to a data store 112. The
data store 112 includes a channel database 114, an index database
130 and a table of contents database 132. A channel represents a
content category, such as news, flight information, recipes, etc.
The channel database 114 contains records. Each record contains a
heading and one or more URLs. The record also contains an
indication as to whether each URL references a channel. Then index
database 130 contains lists of prefixes and, for each prefix, a
list of record IDs that contain words with the prefix, as well as
relevancy factors for use in ranking. The table of contents
database 132 contains prefix entries to aid in traversing the
index. The number of entries contained in the table of contents
database 132 affects the time spent traversing the index to find
relevant record ID lists. A greater number of entries in the table
of contents will slow down the search of the table of contents
database 132, but reduce the time spent traversing the index to
find relevant record ID lists. Fewer entries contained in the table
of contents database 132 will speed up the search of the table of
contents, but increase the time spent traversing the index to find
relevant record ID lists. Further description regarding usage of
these modules is provided below.
[0058] As illustrated in FIG. 1B, the channel database 114 includes
channel data sets 140. Each channel data set 140 includes a list of
records 142. Each record contains data fields 144. Each record is
associated with at least one heading and a "deep link" (a hypertext
link to a page or a web site other than its home page). In some
embodiments, each record contains a heading and a parameter that
can be inserted into a URL template to create a deep link. A
heading may be the displayed title associated with a particular
record. For example, in a list of Wikipedia articles, an example of
a heading may be "John Fitzgerald Kennedy," "High School Musical,"
or "World Wide Web." Headings in a directory of people might
include a person's name, telephone number or address.
[0059] Each data field 144 contains identifying information related
to that particular channel. A data field 144 may also contain other
information related to that particular channel. For example, in an
AMAZON.TM. Books channel, the data fields 144 may contain items
such as a title, an author, an International Standard Book Number
(ISBN) and a price. In a White Pages channel, the data fields 144
may contain a name, an address, a home phone number and a mobile
phone number. In some embodiments, one data field 144 contains
multiple items. In other embodiments, each data field 144 contains
separate items.
[0060] In some embodiments, a data field 144 may be associated with
additional items that represent terms that are equivalent to the
original items contained in the data field. For example, in a name
data field containing "Robert," that data field may be associated
with terms such as "Bob," "Bobby" or "Rob" (i.e. terms that are
equivalent to the term "Robert").
[0061] Those skilled in the art will recognize that the search
server 128 is implemented as a server program executed on a desktop
computer, laptop computer, or server-class computer comprising a
CPU, memory, network interface, peripheral interfaces and other
well known components. The computers themselves preferably run an
open-source operating system such as LINUX, have generally high
performance CPUs, 1G or more of memory, and 100G or more of disk
storage. Of course, other types of computers can be used, and it is
expected that as more powerful computers are developed in the
future, they can be configured in accordance with the teachings
here. The functionality implemented by any of the elements can be
provided from computer program products that are stored in tangible
computer accessible storage mediums (e.g., RAM, hard disk, or
optical/magnetic media).
[0062] For purposes of illustration, FIG. 1A shows the search
result update module 116, the multi-prefix search module 150, the
multi-tier search module 152, the result delivery search module
154, the channel database 114, the index database 130 and the table
of contents database 132 as discrete modules. However, in various
embodiments, any or all of the result update module 116, the
multi-prefix search module 150, the multi-tier search module 152,
the result delivery search module 154, the channel database 114,
the index database 130, and the table of contents database 142 can
be combined for operation on a single computing device having
storage. This allows a single module to perform the functions of
one or more of the above-described modules. Further, the search
server 128 and the data store 112 are shown as discrete components
for purposes of illustration. In other embodiments, the search
server 128 and the data store 112 can also be combined for
operation on a single computing device having storage.
[0063] FIG. 2 is a high level block diagram illustrating a
functional view of a typical mobile communications device 200 in
accordance with some embodiments. Illustrated are at least one
processor 202 coupled to a bus 204. Also coupled to the bus 204 are
a memory 206, a storage device 208, a graphics adapter 212, a
network adapter, and a mobile transceiver 210 including a display,
keyboard, and optionally, a pointing device (not shown). In some
embodiments, the display is a touchscreen display. In one
embodiment, the functionality of the bus 204 is provided by an
interconnecting chipset.
[0064] The storage device 208 is any device capable of storing
data, such as a memory stick, a secure digital (SD) card, a
solid-state memory device or a hard drive. The memory 206 stores
instructions and data used by the processor 202. The optional
pointing device (not shown) is used in combination with the
keyboard (also not shown) to input data into the mobile
communications device 200. The graphics adapter 212 displays images
and other information on the display of the mobile communications
device 200. The network adapter 216 couples the mobile
communications device 200 to a local or wide area network.
[0065] As is known in the art, a mobile communications device 200
can have different components from those shown in FIG. 2.
Furthermore, the mobile communications device 200 can lack certain
illustrated components or include certain components not shown.
[0066] As is known in the art, the mobile communications device 200
is adapted to execute computer program modules for providing
functionality described herein. As used herein, the term "module"
refers to computer program logic utilized to provide the specified
functionality. Thus, a module can be implemented in hardware,
firmware and/or software. In one embodiment, program modules are
stored on the storage device 208, loaded into the memory 206 and
executed by the processor 202. The modules may be loaded as part of
the client applications 124.
[0067] Embodiments of the entities described herein can include
other and/or different modules than the ones described here. In
addition, the functionality attributed to the modules can be
performed by other or different modules in other embodiments.
Moreover, this description occasionally omits the term "module" for
purposes of clarity and convenience.
II. Search Operation
[0068] FIG. 3A is a flowchart illustrating a process 300 of
client-server interaction during multi-prefix, multi-tier,
interactive searching in accordance with some embodiments. An
application for multi-prefix, multi-tier, interactive searching is
initialized 301 by a mobile communications device. The server sends
302 an initial information to display in a window of the mobile
communications device. The window is displayed 303 on a display of
the client device. In one embodiment, the window appears like the
window 902 as illustrated in FIG. 9A. The window 902 includes a
search area 903, which includes a search query field 904, and a
display area 905. The display area 905 includes a landing page 901,
which contains headings 906 for associated channels for user
selection. Each heading 906 refers to either another channel (list
of headings) or to a URL, which may be a deep link into a web site.
The headings 906 are links to categorized information, such as
news, celebrity photos or flight status. The headings 906 may also
be links to various websites, such as gmail.com and fandango.com. A
keystroke associated with an alphanumeric character is input 304 on
the mobile communications device in the search query field 904 as
shown in FIG. 9A, and sent 304 to the server. The user input is
received 306, a search 307 of the channel database 114 is performed
using the input, and sent 308 to the client. The display area 905
is updated accordingly. The display area 905 displays 309 a first
tier of search results, which include channels associated with the
user input. As shown in FIG. 9B, a user inputs "St" in the search
query field 904, and the display area is refreshed to display
results corresponding to the "St" search query. In this example,
"St" corresponds to search results "STARBUCKS.TM. Store Locator,"
"FlightView Airline Flight Status," "Stock Quotes," etc. In one
embodiment, the displayed result, such as shown in FIG. 9B, may
also include other organizational information such as the labels
910 ("Popular Channels" or "All Channels") to provide the user with
additional information such that the headings are intuitively
recognized and understood by the user. The displayed results may
also include selectable links 915 to channels or websites as shown
in FIG. 9B.
[0069] If the desired result is displayed (310--Yes), a result may
be selected 312. The result selection is received 314 and the
corresponding channel or web page is sent 315 to the client. The
channel or web page is then displayed 316 on the display of the
mobile communications device. The selection directs the user to the
channel or website corresponding to the selected result where the
user can input 318 a search query in the channel or web page or
simply explore 318 the displayed page. In some embodiments, if the
result selected is a web page, a separate web browser is launched
to display the web page. As shown in FIG. 9C, the user has selected
the STARBUCKS.TM. Store Locator channel 906 (FIG. 9B). This
selection directs the user to the STARBUCKS.TM. Coffee Store
Locator channel as shown in FIG. 9C.
[0070] If the desired result is not displayed (310--No) within the
search results, another keystroke may be inputted 304. Again, the
user input is received 306, the channel database 114 is searched
307, results are sent 308, and the display area is refreshed
accordingly by displaying 309 the search results. Additional
keystrokes may be entered until the desired channel is displayed.
With each keystroke, the results list is updated by the search
result update module 116.
[0071] In some other embodiments, users may input space character
keystrokes as well as alphabetic or numeric character keystrokes.
As shown in FIGS. 9E and 9F, a user has selected the Starbucks
Coffee Locator channel and has entered a search query in the search
query field 904 that includes a prefix delimiter, such as a space
character. The user's search entry in the search query field 904
represents the prefixes for each word of a multi-prefix search
query. The user has entered a first prefix (first letter or first
several letters of a word or text), separated by a space character,
and a second prefix, and is provided with a list of search results
corresponding to the user input by the multi-prefix search module
150. This allows users to input fewer keystrokes to obtain the
desired search results. In other embodiments, a wild card character
or a symbol can be used in place of spaces between multiple
prefixes of a search.
[0072] The method described above provides for a multi-prefix,
interactive search capability. The search is multi-prefix because
if the search term contains multiple words, the user enters the
prefix of one or more words of the multi-term search query,
therefore, providing the capability for users to enter less
keystrokes and obtain a desired search result. The search is
interactive because a user is provided feedback (displayed search
results) with each keystroke. Based on partial query results, a
user can determine when the search is complete and can obtain the
desired search result without having to enter the entire search
term. Therefore, fewer keystrokes are needed as compared to
searching using the current technologies available.
[0073] FIG. 3B is a flowchart illustrating a process 320 of
client-server interaction during multi-prefix, interactive
searching in accordance with another embodiment. A channel or web
page is sent 315 to the client. The window, including a search area
and a display area, of the channel or web page is then displayed
316 on the display of the mobile communications device. In one
embodiment, the window may look like the window 920 as illustrated
in FIG. 9C or 91. The search area 921 includes a search query field
924. A user inputs 324 keystrokes in the search query field 924.
The server receives 326 the user input and searches 328 the data
fields of the records in the channel for search results that match
the search query. For example, if the White Pages channel was being
searched, the server would receive the search query and search the
name, address, and telephone number fields of the records to
determine if there was a match for the received search query. The
result list is then sent 329 to the mobile communications
device.
[0074] Search results 926 that match the search query are displayed
330 in the display area 933 as shown in FIG. 9D. In some
embodiments, as shown in FIG. 9D, additional information 925
associated with the search result is displayed in the display area
933 along with the search result 926. If the desired result in the
list of results 926 is displayed (332--Yes), then the desired
result may be selected 334 and additional information about the
result may be displayed. However, if the desired result is not
displayed in the list of results (332--No), another keystroke may
be inputted 324 to receive and display different search results.
Space character keystrokes may also be inputted to indicate that
the search query has multiple terms.
[0075] When the server 128 searches for a search result that
matches the search query, the server searches the various data
fields and records within a channel data set. In one embodiment,
the search is performed on structured data, such as the data set
described in the channel database 114. In other embodiments, the
search is performed on unstructured data, which includes data and
links without categorized fields.
[0076] FIGS. 9C-9G provide an illustration of the method. In FIG.
9C, the window 920 for the STARBUCKS.TM. Coffee Locator includes a
search area 921 and display area 933. The search area 921 includes
a search query field 924. The display area 933 in FIG. 9C shows an
initial landing page 931. In some embodiments, the landing page 931
may also include selectable links 932 to additional information.
Keystrokes, which include alphanumeric characters, are entered into
the search query field 924 as seen in FIG. 9D. Search results 926
are displayed in the display area 933 as shown in FIG. 9D.
Additional keystrokes are entered into the search query field 924
(FIGS. 9E and 9F) to input a second prefix, and the search results
list 926 is refreshed with search results that match the updated
search query having two prefixes. In the illustrations provided in
FIGS. 9E and 9F, the prefix of a word is entered into the search
query field 924, followed by a space character and the prefix of
another word of the search term. A prefix is the first letter or
first few letters of a word of the search term. When the desired
result is displayed, a result is selected and the display area 933
is updated to display additional information regarding the search
query. In this example, the records and data fields of the
STARBUCKS.TM. Coffee Locator channel have been searched to
determine the matching search results. In this case, the data
fields contain information related to location and telephone
contact of the STARBUCKS.TM. stores that match the search query.
Those skilled in the art will understand how the present invention
is advantageous because simply by entering the keystrokes and
selecting a single channel, the mobile communications device
displays the exact web page or channel the user is seeking.
[0077] FIGS. 9H-9M also provide an illustration of the above. The
Caltrain Train Schedule channel (950 in FIG. 9H) has been selected
to display the associated landing page 955 (FIG. 9I) in the display
area 953 of the window 952 of the channel. Characters of a search
query are entered into the search query field 954. When the desired
result is displayed, such as in FIG. 9I, the result heading may be
selected and additional information may be received. In this
example, the Burlingame--Mountain View schedule is selected and the
schedule page 960 is displayed as shown in FIG. 9M.
[0078] Another illustrative example of the flow chart in FIG. 3B
may be seen in FIGS. 10A-10C. FIG. 10A shows a window 1002
displaying the Loyola School Directory channel. The window 1002
includes a search area 1003 and a display area 1005. The search
area 1003 includes a search query field 1004. The display area 1005
of FIG. 10A includes a landing page 1007 that contains instructions
1006 and other information 1008. In some embodiments, the landing
page 1007 may also Include links to additional information (not
shown). In this example, a prefix is entered into the search query
field 1004 and display area 1005 is refreshed to show results 1022
as shown in FIG. 108. The search results 1022 include information
associated with a record. The information represents the items
contained in the data fields associated with the record. In this
example, the additional information 1014 includes name of
parent(s), name(s) of siblings, grade and name of teacher, and
address, which is associated with the record "Elayna Pacman." As
shown in FIG. 10C, when an additional prefix is entered into the
search query field 1004, the display area 1005 is refreshed with
new results 1024. In this example, the prefixes ("EI 5") are found
across multiple data fields, therefore displaying results matching
a name that includes "EI" and a grade that includes "5." In some
embodiments, the result 1022 or 1024 may be selected to display
additional results.
[0079] FIG. 3C is a flowchart illustrating a process 340 of
client-server interaction during multi-prefix searching on a mobile
communications device in accordance with some embodiments. An
application for multi-prefix searching is initialized 341 and
information is sent 342 to be displayed in a window of the mobile
communications device. A window is displayed 343 on a display of a
mobile communications device. A search query is input 344 into a
search query field, and a confirmation is made to indicate that the
search query string is complete and the search query is sent 344 to
the server. The search query is a multi-term search query and
contains the prefix of at least one of the terms of the entire
search query. The search query is received 346 by the server, which
sends 347 a result list to be displayed 348 on the mobile
communications device. If the desired result is displayed
(350--Yes), the result may be selected 352 and additional
information may be displayed. If the desired result is not
displayed (350--No) the process is started again when another
search query is input and sent to the server.
[0080] FIG. 4 is a flowchart illustrating a process 400 for
interactive searching in accordance with some embodiments. The
mobile communications device displays 402 a window (902, FIG. 9A),
which contains instructions. In some embodiments, the display of
the mobile communications device initially displays a first tier of
channels, which is obtained by submitting a base channel uniform
resource location (URL) with no search terms. The system monitors
404 for the user input. The user then performs a sequence of
actions. The user can key characters into the input area (as shown
in FIG. 9B), or the user can select an item from the list of
headings displayed on the window. If the user inputs a key
character, or keystroke, into the input area (406--Yes), the user
input field is updated 408. A query URL is constructed 410 and
submitted by combining the base URL with the characters that the
user has inputted in the search query field. The resulting records
from the URL are retrieved and the headings containing those
results records is displayed in the output area. The system
continues to wait 404 for another user input. The aforementioned
steps are repeated until the user selects an entry.
[0081] If the user did not input a key character, or keystroke
(406--No), a determination 414 is made as to whether an entry is
selected. If the user selects an entry (414--Yes), a determination
416 is made to determine whether the entry is marked as a channel.
If the entry is marked as a channel (416--Yes), the base URL is
updated 412 to the URL in the selected record and the search query
field is cleared 412. If the entry is not marked as a channel
(416--No), the web browser is activated and the browser is directed
418 to the URL in the selected record.
[0082] FIG. 5 is a flowchart illustrating a process 500 for
creating a multi-term prefix Index in accordance with some
embodiments. Each record of the database contains a heading and one
or more URLs. The record also contains an Indication whether each
URL references a channel. The headings in each record are
conditioned 502, which includes removing extra space characters
from the beginning and end of the headings. Records with duplicate
headings are removed 502. The records are sorted and assigned 504
sequential IDs. In some embodiments, the record IDs can be used as
the relevancy factors when ranking the results, thereby causing the
results to be displayed in sorted heading order without having to
sort the headings themselves. The headings are split into words and
a list of words is constructed 506. Utilizing the list of words, a
list of word prefixes is created and the number of incidences is
counted 508. An optimization of the list is performed. Prefixes
that do not help to disambiguate between headings are not needed in
the index. For example, given the headings "rat," "sat," "saw" and
"say," the prefix "sa" disambiguates as well as the prefix "s," so
"s" does not need to be included in the index. Entries that are
prefixes of other prefixes and have the same incidence are removed
510 from the list of word prefixes. From the example above, "s" is
a prefix of "sa" and both occur three times; therefore, "s" does
not need to be included in the index.
[0083] Index entries are created 512 for each prefix in each word
in each heading of the record if the prefix is in the list of
disambiguating prefixes. Each entry contains the prefix and the
record ID, as well as the position that the word occurred in the
heading, which is used as a relevancy factor in ranking. The
entries are sorted 514 in alphabetical order by prefix. The list of
index entries is split 516 into lists--one list for each prefix.
The list of record IDs is compressed 518.
[0084] FIG. 6 is a flowchart illustrating a process 600 for
creating a table of contents in accordance with some embodiments.
The table of contents is created based on a threshold. Smaller
threshold values cause the table of contents to contain more
entries, which slows the search of the table of contents, but
reduces the time spent traversing the index to find relevant record
ID lists. Larger threshold values cause the table of contents to
contain fewer entries, which speeds the search of the table of
contents, but increases the time spent traversing the index to find
relevant record ID lists. With this trade-off in mind, the
threshold value is user-definable and can be adjusted to maximize
prefix search performance on a particular hardware system and user
preferences.
[0085] Process 600 begins and two offsets are initialized 602 at
the start of the index. The record ID list that begins at the
offset is retrieved 604 from the index. The prefix and length are
retrieved from the record ID list. The difference between the
offset and the last offset is determined 606. If the difference
between the offset and the last offset is smaller than the
predetermined threshold (606--No), the length is added 612 to the
offset. A determination 614 is then made as to whether the offset
is greater than the size of the index. If the offset is greater
than the size of the index (614--Yes), then the creation of the
table of contents is complete. If the offset is not greater than
the size of the index, the record ID list that begins at the offset
is retrieved 604 from the index.
[0086] If the difference between the offset and the last offset is
at least as large as the threshold (greater or equal to the
threshold) (606--Yes), then the prefix and offset are appended 608
to the table of contents. The last offset is then set 610 to the
offset and the length is added 612 to the offset.
[0087] FIG. 7 is a flowchart illustrating a process 400 for sending
interactive search results in accordance with some embodiments.
When a query is received, it is split 702 into individual prefix
terms. For each prefix, the record ID list corresponding to the
particular prefix is retrieved 704 (a detailed description of the
process of this step is outlined in the description for FIG. 8
below). A "next ID" for each list is set to be the first ID in each
list and a results list that holds certain information regarding
each match is initialized 706. A determination 708 is made as to
whether the next IDs are the same for all ID lists. If they are the
same (708--Yes), the ID and relevancy factors are added 710 to the
result list, which contains a list of all record IDs that occurred
in each of the prefix lists, and, therefore, match the query. If
that ID is the last ID in any of the ID lists (712--Yes), then the
results are ordered 714 by relevancy and the result list sent 716
for display.
[0088] If the ID is not the last ID on the list (712--No), the
current ID is dropped 718 from each list. Again, a determination
708 is made as to whether the next IDs are the same for all ID
lists. If the next IDs are not the same (708--No), the list with
the smallest next ID is selected 720. If that ID is the last ID in
any of the ID lists (722--Yes), the result list is ordered 714 by
relevancy and sent 716 for display. If that ID is not the last ID
in any of the ID lists (722--No), that ID is dropped 724 from that
ID list and a determination 708 is made as to whether the next IDs
are the same for all ID lists.
[0089] FIG. 8 is a flowchart illustrating a process 800 for sending
interactive search results in accordance with some embodiments. In
particular, FIG. 8 is a detailed description of step 704 from FIG.
7 and illustrates the retrieval of a record ID list that
corresponds to a given search term. The first part of the process
800 involves scanning the table of contents to find the largest
entry that is no larger than the search term. An index offset is
initialized 802 to the beginning of the index. The process is
initialized 804 to start at the beginning of the table of contents.
The next entry in the table of contents is retrieved 806, thus
yielding a prefix and an offset into the index. A determination 808
is made as to whether the prefix is less than the search term. If
the prefix is smaller than the search term (808--Yes), then the
index offset is set to the offset that was retrieved from the table
of contents and the process repeats at step 806.
[0090] If the prefix is not smaller than the search term (808--No),
then the index is processed 812 at the index offset and the table
of contents scan is complete. The next entry from the index is
retrieved 814. A determination 816 is made as to whether the prefix
is smaller than the search term. If the prefix is smaller than the
search term (816--Yes), the process repeats at step 814.
[0091] If the prefix is greater than the search term (816--No), the
scanning of the index is completed and a determination 818 is made
as to whether the search term is prefix of the prefix. If the
search term is a prefix of the prefix, then the record ID list is
used 820 at the index offset. If the search term is not a prefix of
the prefix, then no match is found for the particular search
term.
III. Dynamic Menus
[0092] As noted above, a consistent search mechanism, particularly
one that employs variations of the interactive, multi-prefix and
multi-tier techniques described above, facilitates targeted
searches in a mobile communications environment by reducing the
requirements for user interaction and data entry, which in turn
reduces the use of local processing and network bandwidth
resources. As also noted above, results of these targeted searches
are often organized into lists of "records" that share common
attributes or "fields" (from train schedules and movie times to
famous people, places and events, to restaurant addresses and phone
numbers, and various other diverse types of relatively structured
information).
[0093] As a result, these data fields, such as phone numbers, often
can be "recognized" and extracted to enable actions specific to a
particular record, such as calling a selected restaurant (even if
the phone number data associated with that restaurant was also
maintained as unstructured text with respect to the user's query).
Other actions may become relevant as a result of the context of a
user's query or other state information (such as the time of day,
or the user's location, as detected by GPS equipment on the user's
mobile phone).
[0094] Whether these additional actions are specific to one or more
particular records or to all records within one or more particular
channels, or are available generally among all channels (or
combinations of the above), they can provide users with
alternatives to simply selecting and activating a particular
record. In one embodiment, dynamic menus are employed to enable a
wide variety of alternative actions that are not only appropriate
to particular channels or records, but are also well-suited to the
limitations of a mobile communications environment, in that they
can be invoked with relatively minimal user interaction and use of
limited resources.
[0095] For example, having located a restaurant via a multi-prefix
search within a "favorite" local restaurant channel, a user could
place a call to that restaurant via a single menu selection or push
of a phone's talk button. Another menu selection might display a
map of that restaurant, or directions from the user's current
location (utilizing GPS data). A related search for an after-dinner
movie (within a movie channel) might include a different set of
menu selections, such as "movie reviews" or "starring actors." The
result is a consistent targeted search mechanism across different
Information domains (channels) that provides users with alternative
sets of actions appropriate to the information found as a result of
one or more user queries. Users can locate this information and
invoke these ancillary actions with relatively few keystrokes, menu
selections and button presses, which in turn reduces the use of
local processing and memory resources, as well as network latency
and bandwidth.
[0096] In one embodiment, the client portion of this
(client-server) dynamic menu mechanism is implemented as a
standalone application on a resource-constrained mobile
communications device, such as client 118, illustrated in FIG. 1A
(components of which are further detailed as device 200 in FIG. 2).
The architecture of this dynamic menu mechanism is based on an
extensible thin-client model which, as will be explained in greater
detail below, permits the bulk of the resource-intensive
functionality to be implemented and performed on search server 128
(also illustrated in FIG. 1A), rather than on resource-constrained
client 118.
[0097] Such reliance on server 128 is also advantageous because
mobile communications devices vary widely in their ability to
support more complex functionality, such as the use of Javascript
and Ajax to create interactive web-based applications. Moreover,
additional functionality can be implemented on server 128 without
modifying any of the client applications 124 on client 118, thereby
providing users over time not only with the promise of new
channels, for example, but also with added functionality associated
with one or more existing channels.
[0098] To facilitate this level of extensibility, the client
(implemented, for example, as one of the client applications 124 on
client 118, and sometimes referred to herein interchangeably with
client 118) provides relatively general-purpose functionality. In
other embodiments, such functionality could be integrated into
browser 120, or into another application such as a search engine,
or into a special-purpose application dedicated to one or more
information channels. Server 128, however, remains in control,
relying upon client 118 to interpret the specific instances of the
"dynamic menu structure" provided to client 118 by server 128 in
response, for example, to user queries.
[0099] In one embodiment, this general-purpose functionality
implemented by a client application on client 118 includes (i)
sending HTTP requests to search server 128 (such requests
containing, for example, keystrokes of a user's multi-prefix query
or a URI resulting from a user's selection of a channel, a record
or a dynamic menu item), (ii) receiving HTTP responses from server
128 (containing, for example, HTTP headers along with search
results and related data), (iii) parsing these HTTP responses (for
example, to extract and render this data on the screen of client
118, as well as to extract dynamic menu information from the HTTP
headers), and (iv) interacting with the user of client 118 to
facilitate subsequent user queries and selections of search results
or dynamic menu items, which can be utilized to generate and send
additional HTTP requests (in some cases via browser 120), as well
as to invoke "built-in" functionality on client 118, such as
placing a phone call or sending an email in response to a user
request.
[0100] Much of the basic search-related functionality implemented
on both client 118 and server 128 has been explained above in great
detail. The integrated dynamic menu mechanism described below,
however, significantly extends such functionality by providing
users with alternatives to simply selecting and activating a
particular record.
[0101] For example, as explained above, search server 128 generates
results at various tiers of a multi-tier user query, and sends
those results to client 118. Such results include a collection of
records 142 with associated fields 144 (illustrated in FIG. 1B),
typically associated with a particular channel being queried by a
user of client 118. A given record 142 typically includes one or
more fields 144 that are displayed to the user on the screen of
client 118, and which identify the record (such as the name of a
channel or category of channels, or an item within a channel,
perhaps including a name, address and phone number), as well as a
field containing a URI (for example, a link) representing the
action to be performed when the user selects and activates that
record.
[0102] For example, when a user activates record 906 in FIG. 9B
(representing the "Starbucks Store Locator" channel), client 118
accesses the URI associated with that record (which it previously
received from server 128 in response to its single prefix "St"
query for a desired channel) and uses it to generate an HTTP
request to server 128. In response, server 128 sends to client 118
a landing page 931 associated with that channel for display on
client 118, as illustrated in FIG. 9C. Similarly, after the user
activates the "Los Altos Rancho" record 935 illustrated in FIG. 9F,
client 118 accesses the URI associated with that record (which it
had received from server 128 in response to its multi-prefix "Ran I
a" query for a particular Starbucks store) and uses it to generate
an HTTP request to server 128. In response, server 128 sends to
client 118 a web page 941 (with additional detail corresponding to
selected "Los Altos Rancho" record 935) for display on client 118,
as illustrated in FIG. 9G. Note that web page 941 could, in one
embodiment, be retrieved and displayed via browser 120 without the
assistance of server 128 while, in other embodiments, it could be
retrieved by server 128 and displayed on client 118 without the
assistance of browser 120.
[0103] In one embodiment, Server 128 extends this functionality (to
provide users with alternatives to simply selecting and activating
a particular record) by generating additional fields associated
with the records of a particular channel (or with multiple channels
or channel categories). For example, with respect to the Starbucks
Store Locator channel 906, server 128 might generate an additional
field containing the phone number of each Starbucks store record.
Server 128 would send such additional fields to client 118 (for
example, in response to user queries) along with the other fields
noted above that identify each record and provide a URI
representing the action to be taken when the user selects and
activates that record. As noted above, while the phone number
displayed in record 935 could, in one embodiment, be unstructured
text for the purposes of a user's multi-prefix query, server 128
could generate (and reformat, if necessary) a separate phone number
field for each record containing the phone number (if available) of
that particular Starbucks store.
[0104] Moreover, in one embodiment, server 128 generates one or
more HTTP headers representing alternative actions a user could
invoke, for example, with respect to a particular selected record.
Such actions can utilize not only the additional fields generated
by server 128, but also any other data or state information
discernible by client 118 (such as elapsed time or user location
via GPS services).
[0105] One such HTTP header might contain a dynamic menu item that
enables a user to call the phone number of a selected record. For
example, if a user selects "Los Altos Rancho" record 935 and
activates the dynamic menu mechanism (rather than the action
associated with the record itself), client 118 could display a
dynamic menu containing a "Call Store" item and, if the user
selects that item, client 118 could then dial the phone number of
the Los Altos Rancho Starbucks store (contained in the additional
phone number field previously sent to client 118 by server 128 in
response to the user's multi-prefix "Ran I a" query).
[0106] As noted above, users can select a record without activating
it in various ways, depending upon the capabilities of the user's
particular mobile communications device. For example, some devices
have buttons that are dedicated (or can be assigned) to prompt a
client application to invoke a menu. Others, such as touchscreen
devices, often do not distinguish between the selection and
activation of an object, in which case an icon or other visible
identifier could be displayed next to each record, or client 118
could distinguish the number of times a record was "tapped," or how
long it had been "held down."
[0107] In one embodiment, an HTTP header includes not only the name
of the dynamic menu item that is displayed to the user (for
example, "Call Store"), but also the actions to be performed when
the user activates that dynamic menu item (whether directly or
indirectly, for example, by pressing a phone button while a
particular record is selected). Such actions are designed to be
extremely dynamic, taking into account not only the context of a
user's queries but also the state of the user's mobile
communications device, which can change frequently.
[0108] The HTTP header architecture allows dynamic menu items to be
applicable globally to all channels, as well as to one or more
particular channels, and even to particular records within or
across channels. In one embodiment, a dynamic menu item can be
specified to appear only if data pertaining to that item is
available for a particular selected record. For example, a "Call
Store" menu item might not appear if a phone number was not
available for the particular store record selected by the user.
These HTTP headers can leverage virtually any state information
known to the user's mobile communications device (including
information obtained via a remote server), such as a user's GPS
location or whether a user is logged into a particular channel or
web site.
[0109] In one embodiment, HTTP headers can reference data fields
which not only can vary from one record to the next (such as phone
numbers), but which can themselves contain record-specific dynamic
menu item names and actions. In other words, distinct data fields
can be defined (and populated on a per-record basis) such that the
name of the dynamic menu item itself (and its associated action)
will vary from record to record, even within a selected channel
(due to the ability of the HTTP header to reference these distinct
data fields).
[0110] This extensible "dynamic dynamic menu" feature enables the
generation of record-specific, as well as channel-specific, menu
items. For example, a movie channel might contain various types of
field data, such as movie titles and actor names. Moreover, the
"many-to-many" relationships among such data might well be
maintained in a relational database that can be queried, for
example, for a list of movie titles in which a given actor has
appeared, or for a list of actors that have appeared in a given
movie. A dynamic menu could, in one embodiment, display different
menu items for search result "actor" records (for example, "Show
Bio" or "Show Filmography") than for search result "movie" records
(for example, "Show Actors" or "Show Reviews"), even if a user's
multi-prefix query was applied to actors as well as movies
(provided the type of search result could be ascertained by server
128).
[0111] The architecture of these HTTP headers, including their use
of state information as well as additional fields added by server
128, is discussed in greater detail below.
[0112] B. Dynamic Menu HTTP Header Architecture
[0113] One embodiment of this dynamic menu HTTP header architecture
is illustrated in Table 1 below, which includes six distinct fields
of a dynamic menu HTTP header. The utility of this dynamic menu
HTTP header architecture will become apparent from the following
explanation of these fields with reference to the "SAMPLE Dynamic
Menu HTTP Headers" listed in Table 2 below,
TABLE-US-00001 TABLE 1 HTTP HEADER FIELD VALUES COMMENTS Header
Name B-Menu-Entry-nnn Number "nnn" determines Order of Menu Item
within Dynamic Menu Context C Current Channel Indicates whether
Menu Item can apply to Current I Current Selected Item Channel,
Selected Item or BOTH B BOTH Menu Item will NOT be visible/enabled
if Focus on Channel when "I" set or Focus on Selected Item when "C"
set Processing Type I Processed IN Client Upon Menu Item
activation, Client issues HTTP or O Processed OUT of Client other
Request (via URI constructed in accordance (eg, Launch Browser)
with "Action" field) either: To Server (to retrieve data for
display IN Client, and including built-in client application and
mobile device functionality) OR To Browser or Other Client App
(launched to retrieve data OUTSIDE of Client, eg, via URI passed
from Client) Next Step F Follow Link After processing the Action
(specified below), Client R Refresh Channel might "Do Nothing" (N)
or perform an additional S Refresh Channel and action, such as:
Clear Search Filter "Follow Link" (F) as if user had activated
Selected N Do Nothing Item (row or record) OR "Refresh Channel"
.RTM. to provide updated/refreshed data (or "S" to also clear any
existing search filter) Menu Item Name [TEXT of Menu Item name]
This is the text that will be displayed in the Dynamic Menu Menu
Items displayed in the order specified in the "Header Name" field
Action *** [Used to construct URI] See explanation below regarding
the process for constructing a URI to be processed in accordance
with the "Processing Type" field
TABLE-US-00002 TABLE 2 SAMPLE Dynamic Menu HTTP Headers
B-Menu-Entry-1: BIN; Add to favorites;
http://live.boopsie.com/service/set/?favorite=$1&base=$0&uri=$2\r\n
B-Menu-Entry-3; IIF; Click to call; tel:$4/; Talk\r\n
B-Menu-Entry-2: IIS; Search from here;
http://live.boopsie.com/service/set/?name=$1&latlon=$3&response=text\r\n
B-Menu-Entry-4: CIN; Change location; i:change%20location\r\n
B-Menu-Entry-6: ION; Directions to here;
http://live.boopsie.com/service/directions/?latlon=$3\r\n
B-Menu-Entry-5: BIS; Clear location;
http://live.boopsie.com/service/set/?latlon=\r\n B-Menu-Entry-7:
ION; Movie details;
http://wap.aol.com/moviefone/Movie.do?theaterid=$6&movieid=$7&showtime=$8&-
showsynopsis=true\r\n
[0114] Each row of the SAMPLE Dynamic Menu HTTP Headers" shown in
Table 2 represents a distinct dynamic menu HTTP header, delimited
from other headers (in one embodiment) by "carriage return\newline"
or "\r\n" characters. Each header in turn represents a dynamic menu
item (such as "Add to favorites") that might appear when the
dynamic menu is invoked and displayed on a user's mobile
communications device.
[0115] As noted above, in one embodiment, users can also invoke
such dynamic menu items via built-in functionality on a mobile
device, such as pressing a "Talk" button that is mapped to invoke a
"Click to call" dynamic menu item. In this embodiment, the mapping
occurs by adding a symbolic name to the header after the Action
field (for example, "Talk" in row 2 of Table 2 to invoke this
dynamic menu item whenever the client application detects that the
user presses the built-in "Talk" button on client 118).
[0116] In another embodiment, these symbolic names can also be used
to modify the functionality of a dynamic menu item. For example, a
"Map" symbolic name could direct the client application to pass a
URI to a third-party mapping application (such as Google Maps), if
one is installed on client 118, rather than to a web browser, such
as browser 120. In yet another embodiment, a web browser might
automatically detect certain location-related information in a URL
obtained from the client application and elect to utilize a
third-party application that it knows has been installed on client
118 (such as Google Maps), by reformatting the URL (intended for a
web server) in accordance with a published API defined by such
third-party application.
[0117] As noted above, in one embodiment, whenever server 128 (see
FIG. 1A) sends data to client 118, it also sends a set of HTTP
headers which can include dynamic menu HTTP headers representing
dynamic menu items. Thus, a different set of dynamic menu items may
be "active" depending upon which HTTP headers were most recently
sent. In one embodiment, a set of "global" dynamic menu items is
always active, along with any additional dynamic menu items sent by
server 128 at any given time. In another embodiment, a set of
"default" dynamic menu items might become active once a channel has
been chosen, unless the server overrides some or all of those
default dynamic menu items. Many other combinations are apparent
and will depend upon the requirements of any particular
implementation.
[0118] The first field of each header, illustrated in Table 1, is
the "Header Name" field. This field identifies the header as a
"dynamic menu" HTTP header by virtue of the "B-Menu-Entry-nnn"
designation, where "nnn" serves to determine the order in which the
"Menu Item Name" (discussed below) will appear when the dynamic
menu is displayed. Referring to the headers in Table 2, it can be
seen that their display order is determined by the number following
the "B-Menu-Entry-" designation, as opposed to the order in which
they were transmitted to the client (reflected as the order of the
rows in Table 2). For example, the header in row 2 of Table 2 would
appear as the third menu item in the dynamic menu actually
displayed to the user. Finally, note that this "Header Name" field
is delimited, in one embodiment, from the next field ("Context") by
a colon (":") character.
[0119] The "Context" field in Table 1 is a single-character field
that relates to the context or circumstances in which the header's
dynamic menu item will be displayed. In other words, even when the
dynamic menu is displayed on a user's device, not every dynamic
menu item will necessarily be displayed. In one embodiment, the
dynamic menu item might be displayed only when the "focus" is on
the current channel (C), or only when the focus is on a particular
selected record or item (I) displayed in response to a query within
that channel. Otherwise, it might always be displayed (for example,
in both (B) cases) whenever the dynamic menu is displayed
(assuming, in one embodiment, that referenced data fields are
non-empty).
[0120] In one embodiment, the "focus" will typically be on the
"channel" (or channel category) when results are received from
server 128 (for example, in response to a user query or menu
selection). But, when a user selects (but does not activate) a
particular item or record within a channel, the focus is then
switched to that particular item or record.
[0121] The header in row 3 of Table 2, for example, containing a
"Search from here" dynamic menu item, would, in this example, not
be displayed unless the focus was on a particular selected record
or item (I). In the case of a "Yellow Pages" channel, for example,
it would not make sense (contextually) to display a "Search from
here" dynamic menu item before the user enters a search query (in
which case no records would be visible) or after the user enters a
partial or complete query but before the user selects a record (in
which case multiple items might be visible). But, once the user
selects a particular record, it makes sense in this context to
display the "Search from here" menu item, which, if activated,
would replace the "reference location" for future searches with the
location associated with that selected store. As noted above,
however, in the event that the particular selected store did not
have a listed address, then the client application could detect
that the "address" field was empty and (using a different mechanism
discussed below) prevent the display of the "Search from here" menu
item for that particular selected record.
[0122] In the case of the "Add to favorites" header in row 1 of
Table 2, the "B" designation indicates that this function could
apply to the current channel as well as to the selected item.
Continuing with the above Yellow Pages example, if the focus is
still on the channel (for example, before the user enters a query
and selects a record), then activation of the "Add to favorite"
dynamic menu item would add the Yellow Pages channel to the user's
list of "favorites." But, if the user selects a particular store,
and then activates the "Add to favorite" dynamic menu item, then
the selected store (not the Yellow Pages channel) would be added to
the user's list of "favorites."
[0123] Yet, the "Change location" header in row 4 of Table 2 would
only be displayed if the focus was on the channel, as opposed to a
particular record (due to the "C" designation in the Context
field). Continuing with the Yellow Pages example, consider the
scenario in which a user first activates that channel, and has not
yet entered a query. If the user had previously set a "search
center" location, then the client application might initially
display a list of stores nearest that location. But, if the user
desires to search for stores in another geographical area, then the
user most likely would not select one of those displayed store
records. Instead, the user could activate the "Change location"
dynamic menu item, which might display a list of zip codes and
prompt the user to enter zip code digits until the user sees and
activates a desired zip code. The user might then enter a query
into the Yellow Pages channel, resulting in the display of a list
of stores nearby the user's new "search center" location.
[0124] Note that, in the SAMPLE Dynamic Menu HTTP Headers in Table
2, the "Context" field (in one embodiment) has no delimiter, as it
is a single-character field followed by another single-character
field, the "Processing Type" field, which also has no delimiter, as
it is followed by a third single-character field, the "Next Step"
field, which has a semicolon (";") delimiter to separate it from
the following "Menu Item Name" field.
[0125] Returning to Table 1, the "Processing Type" field indicates
whether, upon activation of the dynamic menu item by the user, the
associated action will be performed inside (I) this client
application (including invocation of a built-in feature of the
user's mobile device, such as placing a phone call) or outside (O)
this client application (for example, by launching another client
application, such as a web browser or mapping application). In
either case, as will be discussed below with respect to the
"Action" field shown in Table 1, activation of the dynamic menu
item will result in generation of a URI, which will either be
transmitted to server 128 (or handled internally, for example, via
built-in functionality) or be passed to another client application,
such as web browser 120.
[0126] Returning to Table 2, it is apparent that many of the
actions associated with these headers are performed inside (I) the
client application. For example, in addition to the "Add to
favorites," "Change location" and "Search from here" headers, the
"Clear location" header in row 6 of Table 2 will also direct the
client application to transmit an HTTP request (containing the
relevant URI) to server 128 (or, in other embodiments, to
third-party servers hosting particular channel functionality).
Instead of setting the user's "latlon" variable to a selected "zip
code" value (containing the latitude and longitude coordinates
corresponding, for example, to a desired zip code), the client
application would request that server 128 clear that variable by
setting it to a null value. Even the "Click to call" header in row
2 of Table 2 will utilize the client application to invoke built-in
functionality of the user's mobile device (in this case, to place a
call to a selected item, such as a store or movie theater).
[0127] Other headers in Table 2, however, include actions that are
intended to be performed outside (O) the client application, for
example by invoking another client application, such as a web
browser. For example, the "Movie details" header in row 7 of Table
2 directs the client application to construct a URI utilizing
various field data (discussed below) and then pass it to a client
web browser to retrieve a web page from a third-party web server.
Moreover, the "Directions to here" header in row 5 of Table 2 will
appear only if the user selects a particular item, which typically
will include one or more location fields. In one embodiment, the
client application will pass the relevant location information (for
the starting "search center" as well as the destination of the
selected item) to another client application, such as a web
browser, which will retrieve a web page containing relevant
directions (and perhaps a map of the route). In another embodiment,
a dedicated mapping application could be employed instead of a web
browser.
[0128] The "Next Step" field in Table 1 is also a single-character
field that indicates whether the client application, after it
performs the action associated with this dynamic menu header, will
perform another action. For example, a "Follow Link" (F) action
would instruct the client application to perform the same action
that it would have performed had the user activated the selected
record. For example, after performing the action associated with
the "Click to call" header in row 2 of Table 2 (such as calling the
phone number associated with a selected store or other record), the
client application will then follow the link associated with that
selected item (for example, by passing its associated URL to web
browser 120 to retrieve a merchant's web page). In another
embodiment, in which client 118 cannot initiate voice and data
communications simultaneously, the (F) designation could be
ignored.
[0129] Other options include a "Refresh Channel" (R) action, in
which the current channel is refreshed by virtue of the client
application again sending the most recent HTTP request to server
128 (or, in other embodiments, to another third-party server
hosting channel data). As a result, server 128 sends back updated
results to the client application and the screen is refreshed. A
related option is the "Refresh Channel and Clear Search Filter" (S)
action, which clears any search filter (such as a multi-prefix
search query) from the HTTP request before sending it to server
128.
[0130] For example, if a user searched a "Starbucks Store Locator"
channel for a store near a particular city, and saw a nearby store
in the results list, the user might select that store record and
activate "Search from here" dynamic menu item, which would update
the user's "search center" based upon the location of that selected
store. In that case, however, the user likely would want to see
updated search results reflecting the new location, but would not
necessarily want those results filtered by any particular city. The
"S" designation in the "Search from here" header in row 3 of Table
2 would direct the client to issue a "Refresh" request after
removing the existing search filter. Note that, in one embodiment,
all of these steps occur without requiring the user to leave the
client application, access the web browser or supply a user ID
externally.
[0131] The fourth and final "Next Step" action is to "Do Nothing"
(N), in which case the client application performs only the action
specified in the "Action" field shown in Table 1. For example, the
"Add to favorites" header in row 1 of Table 2 would simply add the
channel or selected record to the user's list of "favorites" (due
to the "N" designation in the header's "Next Step" field). In
another embodiment, a different "Next Step" action might cause the
user's list of "favorites" to appear (for example, as it would when
the client application is initially invoked). As noted above, the
"Next Step" field, in one embodiment, is delimited by a semicolon
(";").
[0132] The next to last field illustrated in Table 1 is the "Menu
Item Name" field which, in one embodiment, is also delimited by a
semicolon (";") to separate it from the final "Action" field. This
"Menu Item Name" field contains the text of the name that will
appear in the dynamic menu when it is displayed to the user on the
screen of client 118. As noted above, the order of these menu items
is determined by the "Header Name" field.
[0133] The sixth and final field of the embodiment of a dynamic
menu HTTP header illustrated in Table 1 is the "Action" field. This
field determines the action that the client application will
perform if the dynamic menu item in this header is activated by the
user. This field provides a flexible and dynamic mechanism that
facilitates the construction of a URI that can be sent to server
128 (or used to invoke a built-in function of the user's mobile
device) or passed to another client application, such as browser
120 (depending upon the value of the "Processing Type" field
discussed above).
[0134] The dynamic features of this Action field, in one
embodiment, include the ability to extract data fields associated
with a current channel or selected record by referencing a "field
number" or "column" with a dollar sign (for example, "$1" for field
1, and so forth). The text in the data field associated with the
referenced column replaces the reference ("$1") and is inserted
into the URI under construction. Moreover, the URI can include
variable names to which a server will assign values, such as the
value of a referenced data field (such as "varname=$1").
[0135] For example, the action associated with the "Add to
favorites" header in row 1 of Table 2 is a template for a URI the
first portion of which (for example,
http://live.boopsie.com/service/set/) appears to be a typical HTTP
request to server 128 (or, in another embodiment, to another server
hosting channel data). Based upon its use of the service/set
directory structure, server 128 (in one embodiment) implicitly
knows to set variables to specified values based upon the remainder
of the URI (following the "?" delimiter, indicating that parameters
will follow).
[0136] In this case, the remaining portion of the URI consists of
three variable assignments separated by "ampersand" ("&")
delimiters, followed by (as noted above) "carriage return/newline"
or "\r\n" characters, which serve to separate individual dynamic
menu HTTP headers from one another. Thus, the "favorite" variable
will be assigned the value contained within "field 1" (in one
embodiment, the name of a channel, category or selected record).
The "base" variable is used, in one embodiment, to provide a
standard reference directory location (stored in "field 0") to
which additional directories can be appended, such as the "uri"
(assigned to the value of "field 2"), which might contain the
channel-specific location, for example, of the selected favorite
channel.
[0137] Looking at row 2 of Table 2, this "Click to call" dynamic
menu item will perform a special "tel" action that is built into
the user's mobile device and accessible from the client
application. In one embodiment, the client application would
extract the data from "field 4" (for example, the phone number of
the selected record) and pass it to the built-in function of the
user's mobile device to initiate a phone call. Depending upon the
capabilities of this built-in functionality, the phone number might
be dialed automatically, or a dialog box might pop up displaying
the phone number and asking the user whether to initiate the phone
call. As noted above, this functionality can even be invoked
without requiring the user to activate the dynamic menu item. For
example, if the client application detects that the user pressed
the "Talk" button on client 118, it would know to invoke this
"Click to call" dynamic menu item due to the presence of the
symbolic name "Talk" after the Action field in this header, as
shown in row 2 of Table 2.
[0138] The "Action" field of the "Search from here" dynamic menu
item in row 3 of Table 2 is similar to that of the "Add to
favorites" item discussed above. The "name" variable is set to the
value of "field 1," which represents the name of the selected
record whose location is being used as the new "search center." The
"latlon" variable is set to the value of "field 3," which contains
the latitude and longitude data defining the location of the
selected item. The "response" variable simply indicates, in one
embodiment, that the server is to generate a textual response, as
opposed to returning a web page.
[0139] The "Change location" action in row 4 of Table 2 is a
special command, in one embodiment, to enable the current channel
to be changed temporarily and then refreshed after the user
specifies a new "search center" location. For example, upon
activating the "Change location" dynamic menu item, the special URI
sent to server 128 requests a temporary change of channel (the data
for which is located via that URI) in response to which server 128
sends a list of zip codes (the data corresponding to a "Change
location" channel) to be displayed on the client. The user can then
search into, select and activate a desired zip code, whereupon the
user will be returned to the prior channel, which will be refreshed
to reflect the new location.
[0140] The "Directions to here" action in row 5 of Table 2 is
processed, in one embodiment, outside the client (based on the "I"
designation in the "Processing Type" field) and passed to web
browser 120 on the user's mobile device. The URI will also include
the user's current "search center" location (not shown). In one
embodiment, this URI is sent via web browser 120 to a web server on
server 128 which, based on the use of the "directions" directory,
will set the "latlon" variable to the value of the data extracted
into the URI from "field 3," and use both the "to" and "from"
locations passed in the URI to return a web page containing, for
example, a map along with textual directions. In one embodiment,
server 128 relies upon a third-party web server to return this web
page, after passing it the location data.
[0141] The "Action" field of the "Clear location" dynamic menu item
in row 6 of Table 2 is also similar to that of the "Add to
favorites" item discussed above. The "latlon" variable is set to
the value of "field 3," which contains the latitude and longitude
data defining the location of the selected item. After setting this
variable, server 128 is directed (by the "S" designation in the
"Next Step" field) to clear the search filter and refresh the
currently selected channel (as described above).
[0142] The "Action" field of the "Movie details" dynamic menu item
in row 7 of Table 2 is processed outside of the client application
(as is the "Directions to here" dynamic menu item). In this case,
the user, after querying the AOL Moviefone channel for a desired
movie, selects that movie record and activates the "Movie details"
dynamic menu item. The client application constructs a relatively
complicated URI (explained below) and passes it to web browser 120.
In one embodiment, this URI is sent via browser 120 to a
third-party site (AOL's Moviefone web site) with a standard HTTP
command and a set of parameters (assigning data extracted from
channel data columns to specified variables). The "Movie.do"
command instructs the Moviefone web server to return a "movie
details" web page to browser 120 based upon the specified parameter
values.
[0143] The "theaterid" variable is set to the data extracted into
the URI from "field 6" (containing a unique ID of the theater at
which the selected movie is playing). The "movieid" variable is set
to the data extracted into the URI from "field 7" (containing a
unique ID of the selected movie). The "showtime" variable is set to
the data extracted into the URI from "field 8" (defining showtimes
for the selected movie). Finally, the "showsynopsis" variable is
set to a constant value of "true," indicating that the selected
movie's synopsis should be included with the other movie
details.
[0144] As noted above, in one embodiment, dynamic menu items are
not displayed if data fields referenced in a header's "Action"
field (for example, using the "$" replacement mechanism discussed
above) are empty. This behavior can be modified, in another
embodiment, by including a "question mark" ("?") character after
the "$" character (for example, "$?1"), in which case the dynamic
menu item would be displayed even if the referenced data field is
empty. Similarly, use of an "exclamation point" ("!") character
(for example, "$!1") would invert this behavior, and cause the
dynamic menu item to be displayed only if the referenced data
column is empty. In yet another embodiment, a "percent" ("%")
character (following a "$" or "$?" or "$!" character combination)
will direct the client application not to URL-encode the referenced
field data.
[0145] In still another embodiment, a "$p" character combination is
used to reference the mobile device's GPS latitude/longitude
coordinates (if GPS functionality is present on the device). An
HTTP header sent by server 128, such as "8-GPS: 45.394280,
-132.224830," could inform the client of the current "search
center" location (for example, previously set by the user via a
"Search from here" dynamic menu item). In another embodiment,
client 118 sends a standard "geo.position: lat; Ion" header to
server 128 with every request, which server 128 can use, for
example, to sort search results. In other embodiments, additional
HTTP headers can be employed to cause channel "refreshes" under
program control. For example, a "B-Action: refresh=10 sec" header
would direct the client to request a refresh of the current channel
every 10 seconds. Such a feature could be useful, for example, to
obtain updated sporting event scores (perhaps even based upon the
time remaining in an event). Similarly, a "B-Action: refresh=0.25
mi" header would direct the client to request a refresh of the
current channel whenever the user's mobile phone device had
traveled one-quarter of a mile (as indicated by the GPS data). This
feature could be useful to update a map, for example, showing the
nearest Starbucks locations while the user is traveling, or the
nearest "homes for sale" while a realtor is driving across town.
Server 128 could also notify client 118 when the user is within a
certain distance of a selected destination.
[0146] Many other dynamic menu and related features will become
apparent in the context of the following discussion of operational
aspects of dynamic menus with reference to FIGS. 11A-C and FIGS.
12A-G below.
[0147] C. Dynamic Menu Operation
[0148] Referring to FIG. 11A, a client application in one
embodiment of the present invention displays a window 1102 when
initially invoked by a user of a mobile communications device (such
as client 118 in FIG. 1A or device 200 in FIG. 2) on which the
client application is loaded. It should be noted that another
similar embodiment of window 1102 is also illustrated as window 902
in FIG. 9A.
[0149] In one embodiment, Window 1102 contains various component
display areas, including a small area 1103 for display of real-time
and related status information, such as the level of network
connectivity to a mobile communications or other network. It also
includes a search query field 1104, to facilitate the entry of user
queries, including the multi-prefix queries discussed above, as
well as a results display area 1105 to display the results of such
user queries.
[0150] When the client application is initially invoked, results
display area 1105 contains a list of various categories of
channels, including a user's previously designated "favorite"
channels 1106 (as well as links and other previously designated
records) and other available channel categories 1107. As noted
above, results are provided to client 118 by server 128 (typically
in response to user requests), and may be updated over time. In
addition, window 1102 may display certain headings, such as the
"Favorite Channels" heading 1108, which describes the collection of
user-defined "favorites" displayed below heading 1108 (but which
cannot. In one embodiment, be selected or activated to perform any
additional function).
[0151] In one embodiment, window 1102 also includes a "fixed menu"
display area 1109 containing certain commonly-used features, such
as a "Back" menu item that will refresh window 1102 with the
results of the previously entered user query (in one embodiment, by
resending the prior user request to server 128 and displaying the
updated results of such request). A "Menu" item is also included in
display area 1109 to invoke a menu with a set of items that provide
additional functionality, as will be explained below. In one
embodiment, the "Back" and "Menu" items can be mapped to and
invoked by keystrokes or buttons on the user's mobile device.
[0152] At this point, a user typically desires to locate a desired
channel (for example, in a "first-tier" search) within which
desired information can then be located (for example, via a
"second-tier" or subsequent-tier query). To facilitate user
queries, a user can enter characters into search query field 1104,
or simply select and activate a channel or channel category. In
either case, client 118 submits such user requests to server 128,
which returns a collection of filtered results which client 118
displays in results display area 1105. Examples of such
multi-tiered and multi-prefix user queries have been illustrated
above in great detail.
[0153] In other situations, however, users desire additional
functionality beyond that which is afforded by simply entering user
queries and activating channel, channel category and intra-channel
records. As discussed above, the dynamic menu architecture of the
present invention provides such alternative functionality in the
context of the user's query and other related state
information.
[0154] In one embodiment, when the user initially invokes the
client application, client 118 sends an HTTP "GET" Request as
illustrated in Table 3 below. This request includes the "imenu"
function and a reference to the "Home" directory, which is
interpreted by server 128 as a request for the initial "top-level"
set of channels, categories and favorites that is illustrated in
FIG. 11A. The remaining information contains data regarding the
capabilities of the mobile device, such as its operating system and
version, and display resolution, as well as the version of the
client application.
[0155] In response, server 128 also sends a "GET" request, which
directs client 118 to display the "list" of data that follows the
HTTP headers. Server 128 also informs client 118 that the
"Incremental Search" capability is turned "on" (to provide
interactive results as the user types characters into search query
field 1104 in FIG. 11A). Finally, it Indicates the length of the
data that follows.
[0156] The HTTP headers include 3 dynamic menu headers ("Remove
from favorites," "Add to favorites," and "Refresh"), as well as a
"B-Action: skip-empty-links" header that directs the client, while
navigating, to skip over rows of data that do not have associated
links (for example, to avoid selecting items such as the "Favorite
Channels" heading 1108 in FIG. 11A, since it has no associated
action). As explained above, the "Refresh" dynamic menu item will
request that server 128 refresh the current channel and remove the
user's current search filter, if any. It will be visible regardless
of whether the focus is on any selected channel or category.
[0157] The "Add to favorites" and "Remove from favorites" dynamic
menu items will apply only when an item is selected (due to the "I"
designation in the "Context" field), and will refresh this
top-level collection of channels and categories to update the list
of the user's "favorites" (for example, after adding or removing a
selected item). The Action fields of these two headers is similar
to that explained in the examples above in Table 2, in that it sets
the "base," "favorite," and "uri" variables to the values of the
data in fields 0, 1, and 2, respectively. In addition, the "Remove
from favorites" Action field includes a "remove" parameter to
enable server 128 to distinguish this request from an "Add to
favorites" request.
[0158] Note, however, that a third field ("field 3") is referenced,
which is used by client 118 to determine whether to display the
"Add to favorites" or "Remove from favorites" dynamic menu item
based on whether the user selected an item on the user's list of
favorites. For example, as will be discussed below, each record
includes (in one embodiment) a "1" in "field 3" if it is on the
user's list of favorites. Otherwise, "field 3" is left empty. By
using the "$3" designation, the "Remove from favorites" dynamic
menu item will be displayed only if "field 3" is non-empty, and
thus only if the user has selected an item on the user's list of
"favorites." Conversely, the "Add to favorites" dynamic menu item
contains a "$13" designation, which directs client 118 to display
this menu item only if "field 3" is empty, and thus only if the
user has selected an item that is not on the user's list of
"favorites."
[0159] Following these HTTP headers in Table 3 is the body of the
transmitted message containing the list of data to be displayed by
client 118 in results display area 1105 of window 1102 shown in
FIG. 11A. The hex-formatted digits at the beginning of certain rows
of data specify standard color and aesthetic display information.
The "name" to be displayed for each channel or category (or header)
is deemed "field 1" with a space delimiter separating it from the
"uri" in "field 2." This "uri," in one embodiment, is a relative
path to assist server 128 in locating the data (HTTP headers and
channel data) should a particular record be selected and activated.
Following the "uri," the data for "field 3" is displayed, which (in
one embodiment) includes a "1" if the record is on the user's list
of "favorites," and is otherwise left empty.
[0160] To illustrate how these HTTP headers and associated data
records shown in Table 3 are utilized, consider a common scenario
illustrated in FIG. 11B. A user might desire to remove a previously
defined favorite channel (or other record). In one embodiment, the
user selects a favorite channel which the user desires to remove,
such as "Loyola School Directory" channel 1116 in window 1112, and
invokes menu item 1119a in menu display area 1119, which results in
the display of dynamic menu 1115. At this point, client 118 detects
that selected record 1116 is on the user's list of favorites (based
on the presence of a "1" in "field 3"), and thus displays the
"Remove from favorites" dynamic menu item 1115a (but not the "Add
to favorites" dynamic menu item, due to the "$!3" designation in
its header). It should also be noted that, in one embodiment,
additional menu items are displayed (for example, "Home" and "All
Channels" and others) on dynamic menu 1115. These "global" menu
items can be "hardwired" into client 118 (for example, not relying
on this dynamic menu HTTP header architecture), or can be
considered as "default" menu items to be displayed unless server
128 indicates otherwise (as discussed above).
[0161] Having selected channel 1116, the user can select and
activate "Remove from favorites" dynamic menu item 1115a, which
will cause client 118 (in accordance with the Action field
associated with the "Remove from favorites" header illustrated in
Table 3) to construct a URI (extracting information from designated
data fields) and send an HTTP request to server 128, which will set
the relevant variables (as explained above). It will then issue a
"Refresh" request (due to the "R" designation in the "Next Step"
field) to server 128 to refresh this "top-level" channel and
category list, reflecting the removed record.
[0162] If, however, the user selects a record that is not on the
user's list of "favorites," then the "Remove from favorites" Item
is not contextually relevant and is not displayed (in one
embodiment) when the user invokes a dynamic menu. Turning to FIG.
11C, for example, if the user selects a record such as "Business"
channel category 1126, and then invokes menu item 1129a in menu
display area 1129, client 118 displays dynamic menu 1125, which
does not contain a "Remove from favorites" dynamic menu item, but
does contain an "Add to favorites" menu item 1125a.
[0163] As discussed above, client 118 detects that selected
"Business" channel category record 1126 is not on the user's list
of favorites (based on an empty "field 3"), and thus displays the
"Add to favorites" dynamic menu item 1125a (but not the "Remove
from favorites" dynamic menu item, due to the "$3" designation in
its header). Having selected channel 1126, the user can select and
activate "Add to favorites" dynamic menu item 1125a, which will
cause client 118 (in accordance with the Action field associated
with the "Add to favorites" header Illustrated in Table 3) to
construct a URI (extracting information from designated data
fields) and send an HTTP request to server 128, which will set the
relevant variables (as explained above). It will then issue a
"Refresh" request (due to the "R" designation in the "Next Step"
field) to server 128 to refresh this "top-level" channel and
category list, reflecting the added record.
[0164] One embodiment of the dynamic menu mechanism illustrated in
FIGS. 11A-11C provides users with contextually relevant alternative
functionality not only by distinguishing whether a selected record
is on the user's list of favorites (and displaying the contextually
appropriate dynamic menu item), but also by receiving dynamic menu
HTTP headers along with the results of the user's request. In other
words, as the user queries different channels for different types
of data, the dynamic menu items also can change to reflect such
differences, even at the level of a particular record.
TABLE-US-00003 TABLE 3 REQUEST GET
/imenu?u=http://live.boopsie.com/i/Home/ HTTP/1.1 UA-OS: WinCE
(Smartphone) - Version (5.1); Carrier (none); Boopsie - Version
(2.0.2.2) UA-pixels: 320x240 (9 lines) RESPONSE (not logged in) GET
/list HTTP/1.1 Incremental-Search: on Content-Length: 1017
B-Menu-Entry-1: IIR; Remove from favorites;
http://live.boopsie.com/service/set/?remove&favorite=$1&base=$0&uri=$2&if=-
$3 B-Menu-Entry-2: IIR; Add to favorites;
http://live.boopsie.com/service/set/?favorite=$1&base=$0&uri=$2&if=$!3
B-Menu-Entry-4: BIS; Refresh B-Action: skip-empty-links #fff#008
Favorite Channels CitySearch Silicon Valley
i:../CitySearch%20Silicon%20Valley/ 1 Google Gmail
http://gmail.com/ 1 Loyola School Directory
i:../Loyola%20School%20Directory/ 1 Nokia Music Store
i:../Nokia%20Music%20Store/ 1 Wikipedia English The Free
Encyclopedia i:../Wikipedia%20English%20The%20Free%20Encyclopedia/
1 #fff#35a All Channels i:../All%20Channels/ #fff#35a Business
i:../Business/ #fff#35a Dating i:../Dating/ #fff#35a Entertainment
i:../Entertainment/ #fff#35a Food and Wine i:../Food%20and%20Wine/
#fff#35a Google i:../Google/ #fff#35a Health i:../Health/ #fff#35a
How To i:../How%20To/ #fff#35a Local i:../Local/ #fff#35a News
i:../News/ #fff#35a Reference i:../Reference/ #fff#35a Religion
i:../Religion/ #fff#35a Shopping i:../Shopping/ #fff#35a Social
Networking i:../Social%20Networking/ #fff#35a Sports and Recreation
i:../Sports%20and%20Recreation/ #fff#35a Store Locator
i:../Store%20Locator/ #fff#35a Technical i:../Technical/ #fff#35a
Tools i:../Tools/ #fff#35a Travel i:../Travel/
[0165] Referring now to FIG. 12A, consider the operation of one
embodiment of the dynamic menu mechanism of the present invention
in the context of a user activating the "Facebook Friends" channel.
Upon locating and activating this channel (in the manner discussed
above), client 118 sends a "GET" request to server 128, illustrated
in Table 4. This request is very similar to the one shown in Table
3, the primary difference being the URI path to the "Facebook
Friends" directory on server 128, instead of to the "Home"
directory (containing the list of channels, categories and
favorites).
[0166] Yet, server 128 detects that the user has not yet logged
into the Facebook web site (at least via the client application),
and thus cannot yet leverage the client application (including, for
example, the interactive multi-prefix, multi-tier and dynamic menu
features of the present invention) to obtain user-specific profile
information, including information regarding the user's Facebook
friends. Although the user could be logged into the Facebook web
site via web browser 120, this would not afford the user the
benefits of the integrated experience provided by the Facebook
Friends channel (described in greater detail below).
[0167] In one embodiment, before server 128 delivers to client 118
the "Log into Facebook" page shown in FIG. 12A, server 128 accesses
the Facebook web server (via a published API), obtains an "API key"
(in effect logging server 128 into Facebook) and provides
information to Facebook, including a "user callback URL" that the
Facebook web server will supply to browser 120 in response to a
successful authentication request (which contains the API key).
When browser 120 subsequently accesses this "user callback URL," it
will access the web browser on server 128, effectively notifying
server 128 of the user's successful authentication, and providing
it with the user's "session ID" generated by the Facebook web
server.
[0168] By leveraging this relatively common API mechanism (and
other techniques discussed in greater detail below), server 128 can
provide users with a significant degree of interoperability between
the client-server application of the present invention and standard
web browsers such as web browser 120. For example, because the
Facebook web server is aware of server 128 (via the API key), it
can deliver to browser 120 the "Log into Facebook" web page shown
in FIG. 12A, which includes information specific to the
client-server application of the present invention (for example,
the message 1207 requesting the user to log into Facebook to enable
the "Boopsie" application to deliver the user's list of
friends).
[0169] Returning to Table 4, the "GET" request in the "Response"
from server 128 is also very similar to the one discussed above and
shown in Table 3. The associated data is relatively simple,
including only textual directions to the user and a single
selectable record with an associated "login" action. The single
dynamic menu "Refresh" HTTP header is very similar to the Refresh
header shown in Table 3, except that it does not clear the user's
search filter (due to the "R" designation in the header's "Next
Step" field).
[0170] One major difference, however, is the presence of security
information, since the user must log into (albeit somewhat
indirectly) the actual "Facebook" web site. In one embodiment,
server 128 generates a "MOFIID," which is a form of user or session
ID that is specific to the "pairing" of the user and a particular
channel, such as the Facebook Friends channel. To enhance security,
each user is assigned different authentication credentials with
respect to each channel the user accesses (assuming such channels
or web sites require user authentication). This strengthens
security (as will become apparent below) by preventing multiple web
sites from having access to a user's "common" authentication
credentials, while still affording server 128 the ability to
communicate with the Facebook web server on behalf of the user to
obtain user-specific information and provide enhanced functionality
to users of both the Facebook web site and the Facebook Friends
channel.
[0171] The "B-MOFIID: 2wl6n9pX5z4cV" header shown in Table 4
provides the user's MOFIID to the client application. In addition,
the URI (shown in Table 4) associated with the user's activation of
the "Log into Facebook" record (illustrated in FIG. 12A) contains
both the API key (connecting server 128 with Facebook) and the
MOFIID (used by server 128 to distinguish among users of the
Facebook Friends channel). These mechanisms are used, in one
embodiment, to enable users to log into Facebook via a standard web
browser, such as browser 120, without foregoing the functionality
provided by the Facebook Friends channel.
[0172] At this point, the user's only effective choice is to
activate the "Log into Facebook" link or record 1206 to initiate
the login process. In one embodiment, the client application then
passes the URI shown in Table 4 to browser 120, which the client
application launches to initiate the process of logging the user
into the Facebook web site. In response, the Facebook web server
delivers to browser 120 the web page 1212 shown in FIG. 128. Note
that this web page also includes information specific to the
client-server application of the present invention, such as the
message 1214 requesting that the user log into Facebook via web
page 1212 to enjoy the full functionality of the "Boopsie"
application. Message 1214 also provides the user with an optional
link to log into Facebook directly (for example, if the user
desires to circumvent the "Boopsie" client application and the
benefits afforded by the Facebook Friends channel).
[0173] Web page 1212 includes fields in which the user can enter
standard authentication information, including email address or
phone number field 1216, password field 1217 and an optional save
login info checkbox 1218. After filling in the relevant login Info,
as illustrated in FIG. 12C, and activating the "Log in" link 1225,
the Facebook web server proceeds not only to log the user into
Facebook and generate a session ID (for subsequent access to
user-specific information on the Facebook web site), but also to
use the "user callback URL" described above to redirect web browser
120 to a web page on server 128 corresponding to that URL (as well
as provide the user's session ID). This process effectively serves
to notify server 128 of the user's successful Facebook login, as
well as provide server 128 with the user's newly-generated Facebook
session ID. Server 128 utilizes the user's MOFIID (which is also
forwarded by the Facebook web server, along with the session ID
that it generated) to distinguish among its own users that access
the Facebook Friends channel.
[0174] At this point, server 128 can utilize the user's MOFIID and
session ID to issue requests to the Facebook web server for
user-specific information, such as the user's list of friends.
However, in one embodiment, rather than leave the user in the web
browser interface, the web server on server 128 can respond to the
request from browser 120 (for the web page at the "user callback
URL" located on server 128) by downloading a ".MOFI" file, which
will cause browser 120 to invoke the client application
automatically--much in the same way that any downloaded file with
an extension to a third-party application (such as ".xls" for
Microsoft Excel or ".pdf" for Adobe Acrobat), can cause a web
browser to launch that application automatically upon downloading
that file.
[0175] This non-standard use of a relatively standard mechanism
enables the user, after having logged into Facebook via browser
120, to automatically be returned to the client application
providing the Facebook Friends channel.
TABLE-US-00004 TABLE 4 REQUEST GET
/imenu?u=http://live.boopsie.com/i/Facebook%20Friends/ HTTP/1.1
UA-OS: WinCE (Smartphone) - Version (5.1); Carrier (none); Boopsie
- Version (2.0.2.2) UA-pixels: 320x240 (9 lines) RESPONSE (not
logged in) GET /list HTTP/1.1 Incremental-Search: on
Content-Length: 257 B-MOFIID: 2wl6n9pX5z4cV B-Action:
skip-empty-links B-List-Mode: refreshs B-Menu-Entry-1: BIR; Refresh
#fff#3b5998 facebook #fff#6d84b4 please log in Please log in, so
that Boopsie for Facebook may load your Friends list. Log into
Facebook\thttp://m.facebook.com/login.php
?api_key=4a7075ed59a1884c5e741c13a83c25e0&v=1.0&next=mofiid%3d2wl6nghj5z4c-
V
[0176] When the client application "refreshes" its request for the
"Facebook Friends" channel (automatically upon activation, for
example, in one embodiment), it reissues the same GET request, now
shown in Table 5. However, because server 128 now knows that the
user is logged into Facebook, it issues a different response,
illustrated in FIG. 12D.
[0177] The HTTP headers shown in Table 5 include the MOFIID data
and progress information (indicating, for example, that records 1
to 20 of 97 records have been retrieved), as well as seven dynamic
menu HTTP headers that provide functionality specific to the
Facebook Friends channel, in addition to the data that follows,
which includes a list of the user's friends and identifying
information (including a unique "friend ID" that server 128 can use
to obtain information specific to a particular "friend" record from
the Facebook web server).
[0178] Turning to FIG. 12D, window 1232 includes user search query
field 1234 and results display area 1235, which contains data
headings 1238 indicating that Facebook friends 1-20 of 97 are
displayed below. These "friend" records 1236 contain summary
information about the user's friends. If any such record is
activated, an associated action will be performed, such as invoking
web browser 120 to request a "deep link" from the Facebook web site
for a profile of the selected friend. In addition, menu display
area 1239 includes menu item 1239a, which enables the user to
display a dynamic menu.
[0179] The dynamic menu HTTP headers shown in Table 5 provide a
variety of Facebook-specific functionality. With the exception of
the "Refresh" and "Log out" headers, which are performed by the
client application, the remaining headers contains URIs that, when
constructed, will be passed to browser 120. Yet, using the
mechanisms discussed above with respect to the Facebook login
process, the client application can be invoked from browser 120,
enabling additional functionality to be performed from within the
client application, apart from simply issuing a "deep link" and
leaving the user in the web browser.
[0180] The "My Profile" header references a location on server 128
in which the user's Facebook profile information is stored. The
other dynamic menu headers extract the ID of a selected friend
(using, for example, the "$2" replacement mechanism discussed
above) to enable server 128 to obtain information relating to that
friend from the Facebook web server on behalf of the user (using
the "session ID" and "MOFIID" as discussed above).
[0181] If the user selects a particular friend, such as friend
record 1246 shown in FIG. 12E and invokes dynamic menu 1245 (for
example, via menu item 1239a in FIG. 12D), the user can elect to
perform various alternative Facebook-specific functions related to
that selected friend (apart from the retrieval of that selected
friend's profile, for example, by activating the selected friend's
record). For example, the user could activate dynamic menu item
1245a to "poke" selected friend 1246 (via Facebook).
[0182] Upon activation of the "Poke friend" dynamic menu item
1245a, the client application constructs the URI (from the Action
field shown in Table 5), and passes it to browser 120 (including
the "poke" parameter containing the selected friend's user ID
extracted from "field 3" of the data shown in Table 5). In one
embodiment, after "poking" the selected friend, browser 120 may
notify the user that the "poke" was successful and then (using the
".MOFI" technique discussed above) automatically invoke the client
application, which will "refresh" the user's list of friends. In
another embodiment, the user will remain in the browser 120, but
can still return manually to the client application, which will be
refreshed automatically.
TABLE-US-00005 TABLE 5 REQUEST (same as before) GET
/imenu?u=http://live.boopsie.com/i/Facebook%20Friends/ HTTP/1.1
UA-OS: WinCE (Smartphone) - Version (5.1); Carrier (none); Boopsie
- Version (2.0.2.2) UA-pixels: 320x240 (9 lines) RESPONSE (logged
in) GET /list HTTP/1.1 Incremental-Search: on Content-Length: 1140
B-MOFIID: 2wl6n9pX5z4cV B-Action: skip-empty-links B-Progress: 1 to
20 of 97 B-Menu-Entry-1: ION; Add to friends;
http://live.boopsie.com/host/facebookfriends/?add=$4
B-Menu-Entry-2: ION; Poke friend;
http://live.boopsie.com/host/facebookfriends/?poke=$3
B-Menu-Entry-3: ION; Message friend;
http://live.boopsie.com/host/facebookfriends/?message=$3
B-Menu-Entry-4: ION; Wall of friend;
http://live.boopsie.com/host/facebookfriends/?wall=$2
B-Menu-Entry-5: BON; My profile;
http://live.boopsie.com/host/facebookfriends/?profile
B-Menu-Entry-6: BIS; Refresh B-Menu-Entry-7: BIR; Log out;
http://live.boopsie.com/host/facebookfriends/?logout #fff#3b5998
facebook #fff#6d84b4 97 friends (1 to 20 of 97) Aaron Levie|Box.net
/ USC / Silicon Valley, CA 3402659 3402659 Adam
Fritzler|BitTorrent, Inc. / San Francisco, CA 545323645 545323645
Adriane Rose|RIT / CCRI 24416529 24416529 Alex Feinberg|Santa Clara
/ Yahoo! / Silicon Valley, CA 7305243 7305243 Allan Pichler|
651958736 651958736 Andy Wick|Virginia Tech / Washington, DC
691927740 691927740 Ardy F.|Silicon Valley, CA 512018645 512018645
Bahram Afshari|Silicon Valley, CA / Stanford 681147213 681147213
Barbara Meier|Brown / Providence, RI 1013164 1013164 Brad
Cleveland|Silicon Valley, CA 587478487 587478487 Brad
Kay.Goodman|Boston, MA 713076764 713076764 Brian Greenberg|East
Bay, CA 593872292 593872292
[0183] The user might also desire to filter a large list of friends
to locate a desired friend. For example, the user might enter a "d
m" multi-prefix query into search query field 1254 in FIG. 12F, the
results of which can be displayed by the client application in
window 1252. The heading information 1258 is updated to reflect the
filtered list of 4 friends, and only these 4 friend records 1256
are now displayed (in accordance with the results received by
client 118 and shown in Table 6).
[0184] If the user selects friend record 1266 shown in window 1262
in FIG. 12G, and invokes dynamic menu 1265 (for example, via menu
item 1259a in FIG. 12F), the user might then elect, for example, to
activate dynamic menu item 1265a to "message" that selected friend
1266 (via Facebook).
[0185] Upon activation of the "Message friend" dynamic menu item
1265a, the client application constructs the URI (from the Action
field shown in Table 6), and passes it to browser 120 (including
the "message" parameter containing the selected friend's user ID
extracted from "field 3" of the data shown in Table 6). In one
embodiment, after "messaging" the selected friend, browser 120 may
notify the user that the "message" was sent successfully and then
(using the ".MOFI" technique discussed above) automatically invoke
the client application, which will "refresh" the user's list of
friends. In another embodiment, the user will remain in the browser
120, but can still return manually to the client application, which
will be refreshed automatically.
[0186] Turning to Table 6, it can be seen that the "GET" request
has changed only slightly to reflect the search query ("c=d+m") and
to employ a "wwu" (instead of an "imenu") command, which is a
relatively minor implementation decision. The dynamic menu HTTP
headers have not changed in response to the user's query (though,
in other embodiments, they could be modified under control of
server 128 to reflect a different state or context). Finally, the
filtered set of results (4 "friend" records) are included for
display by client 118, as shown in FIGS. 12F and 12G.
TABLE-US-00006 TABLE 6 REQUEST (with filter "d m") GET
/wwu?c=d+m&u=http://live.boopsie.com/i/Facebook%20Friends/
HTTP/1.1 UA-OS: WinCE (Smartphone) - Version (5.1); Carrier (none);
Boopsie - Version (2.0.2.3) UA-pixels: 320x240 (9 lines) RESPONSE
GET /list HTTP/1.1 Incremental-Search: on Content-Length: 305
B-MOFIID: 2wl6n9pX5z4cV B-Action: skip-empty-links B-Progress: 1 to
4 of 4 B-Menu-Entry-1: ION; Add to friends;
http://live.boopsie.com/host/facebookfriends/?add=$4
B-Menu-Entry-2: ION; Poke friend;
http://live.boopsie.com/host/facebookfriends/?poke=$3
B-Menu-Entry-3: ION; Message friend;
http://live.boopsie.com/host/facebookfriends/?message=$3
B-Menu-Entry-4: ION; Wall of friend;
http://live.boopsie.com/host/facebookfriends/?wall=$2
B-Menu-Entry-5: BON; My profile;
http://live.boopsie.com/host/facebookfriends/?profile
B-Menu-Entry-6: BIS; Refresh B-Menu-Entry-7: BIR; Log out;
http://live.boopsie.com/host/facebookfriends/?logout #fff#3b5998
facebook #fff#6d84b4 4 friends Dan Manheim|Los Angeles, CA / UCLA /
Threshold Marketing 596495304 596495304 Dave McNabola|Austin, TX /
Duke 1079384606 1079384606 Denis Ford|Seattle, WA / Microsoft
757528454 757528454 Douglas Cheline|Thunderbird School of Global
Management 293500041 293500041
[0187] From the above descriptions of the various embodiments of
the interactive, multi-prefix, multi-tier and dynamic menu aspects
of the present invention, many additional features and applications
of these techniques will become apparent. For example, as noted
above, these techniques could be incorporated wholly within a web
browser (such as Firefox Mobile) or an integrated or standalone
search engine (such as Google). One or more channels could be
searchable, or simply selected from a list of "smart bookmarks."
Moreover, a vertical web site or sites (such as Amazon, Wikipedia
or IMDB) could provide various combinations of these features as a
standalone application containing one or more channels.
[0188] Multiple channels could be searched at one time,
particularly if they are related, and dynamic menus could be
employed to perform functions and retrieve information from
channels/web sites in advance of relying upon a client web browser.
Moreover, the interoperability between a client application and a
client web browser, as discussed above, greatly enhances the user's
experience by enabling the user to switch between these
applications when the particular context makes one or the other
more useful or desirable.
[0189] In a mobile communications environment, the advantages of
interactive multi-prefix queries, particularly when targeted across
one or more tiers of channels, are quite significant. Avoiding
multiple web page refreshes and links, providing results quickly
and interactively and enabling users to minimize data entry is of
great importance in such a resource-constrained environment.
Moreover, adding contextual functionality such as dynamic menus
that can vary among channels and even individual records or program
states (particularly when deployed using a thin-client
server-controlled architecture), significantly enhances these
advantages, by providing a high degree of context-specific
functionality while minimizing iterations among resource-intensive
steps such as following links or refreshing web pages.
[0190] Some portions of above description describe the embodiments
in terms of algorithms and symbolic representations of operations
on information. These algorithmic descriptions and representations
are commonly used by those skilled in the data processing arts to
convey the substance of their work effectively to others skilled in
the art. These operations, while described functionally,
computationally or logically, are understood to be implemented by
computer programs or equivalent electrical circuits, microcode, or
the like. Furthermore, it has also proven convenient at times, to
refer to these arrangements of operations as modules, without loss
of generality. The described operations and their associated
modules may be embodied in software, firmware, hardware, or any
combinations thereof.
[0191] As used herein any reference to "one embodiment" or "an
embodiment" means that a particular element, feature, structure, or
characteristic described in connection with the embodiment is
included in at least one embodiment. The appearances of the phrase
"in one embodiment" in various places in the specification are not
necessarily all referring to the same embodiment.
[0192] Some embodiments may be described using the expression
"coupled" and "connected" along with their derivatives. It should
be understood that these terms are not intended as synonyms for
each other. For example, some embodiments may be described using
the term "connected" to indicate that two or more elements are in
direct physical or electrical contact with each other. In another
example, some embodiments may be described using the term "coupled"
to indicate that two or more elements are in direct physical or
electrical contact. The term "coupled," however, may also mean that
two or more elements are not in direct contact with each other, but
yet still co-operate or interact with each other. The embodiments
are not limited in this context.
[0193] As used herein, the terms "comprises." "comprising,"
"includes," "including," "has," "having" or any other variation
thereof, are intended to cover a non-exclusive inclusion. For
example, a process, method, article, or apparatus that comprises a
list of elements is not necessarily limited to only those elements
but may include other elements not expressly listed or inherent to
such process, method, article, or apparatus. Further, unless
expressly stated to the contrary, "or" refers to an inclusive or
and not to an exclusive or. For example, a condition A or B is
satisfied by any one of the following: A is true (or present) and B
is false (or not present), A is false (or not present) and B is
true (or present), and both A and B are true (or present).
[0194] In addition, use of the "a" or "an" are employed to describe
elements and components of the embodiments herein. This is done
merely for convenience and to give a general sense of the
invention. This description should be read to include one or at
least one and the singular also includes the plural unless it is
obvious that it is meant otherwise.
[0195] Upon reading this disclosure, those of skill in the art will
appreciate still additional alternative structural and functional
designs for a system and a process for providing multi-prefix,
interactive search capabilities on a mobile communications device
through the disclosed principles herein. Thus, while particular
embodiments and applications have been illustrated and described,
it is to be understood that the disclosed embodiments are not
limited to the precise construction and components disclosed
herein. Various modifications, changes and variations, which will
be apparent to those skilled in the art, may be made in the
arrangement, operation and details of the method and apparatus
disclosed herein without departing from the spirit and scope
defined in the appended claims.
* * * * *
References