WO2008157730A1 - Menu dynamique pour recherche mobile interactive multipréfixe - Google Patents

Menu dynamique pour recherche mobile interactive multipréfixe Download PDF

Info

Publication number
WO2008157730A1
WO2008157730A1 PCT/US2008/067555 US2008067555W WO2008157730A1 WO 2008157730 A1 WO2008157730 A1 WO 2008157730A1 US 2008067555 W US2008067555 W US 2008067555W WO 2008157730 A1 WO2008157730 A1 WO 2008157730A1
Authority
WO
WIPO (PCT)
Prior art keywords
user query
information retrieval
retrieval system
client device
user
Prior art date
Application number
PCT/US2008/067555
Other languages
English (en)
Inventor
G. Gregory Carpenter
Timothy Kay
Original Assignee
Boopsie, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/970,414 external-priority patent/US8255377B2/en
Application filed by Boopsie, Inc. filed Critical Boopsie, Inc.
Publication of WO2008157730A1 publication Critical patent/WO2008157730A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques

Definitions

  • 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.
  • HTML Hypertext Markup Language
  • the mobile keyboard and pointer are less effective than their counterparts on desktop and personal computers.
  • Keyboards are less effective because their small form factor makes it more difficult to type characters.
  • 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.
  • 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.
  • 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. 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).
  • 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.
  • 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.
  • common mobile searches include requests for stock quotes, sports scores, movie times and nearby restaurants or coffee shops, to name a few.
  • 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).
  • 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.
  • Google 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.
  • 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.
  • multi-prefix search techniques are employed in an effort to minimize a user's data entry requirements.
  • 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.
  • users can employ multi-tier search techniques to constrain queries to one or more information channels.
  • users can simply select one or more channels from a list, which could include previously designated "favorite" channels.
  • 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).
  • 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.
  • 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.
  • Prefix delimiters denote the beginning of another search prefix.
  • space characters may be used as prefix delimiters.
  • 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.
  • the data extracted from an information channel can, in one embodiment, be pre-processed for functional as well as aesthetic display purposes.
  • 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.
  • channel data records and fields can be indexed as such in order to enable structured searches based upon these records and fields.
  • the indexing process ignores data field distinctions but is optimized for multi-prefix searches.
  • the frequency of extracting data from remote information sources 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.
  • 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.
  • 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.
  • 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).
  • "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 ⁇ selected person).
  • 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).
  • HTTP Hypertext Transfer Protocol
  • these HTTP headers can be incorporated into the body of the transmission itself.
  • 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.
  • 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.
  • 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.
  • certain actions 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.
  • 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).
  • 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.
  • a consistent targeted search mechanism such as one that employs the interactive multi-prefix and multi-tier information retrieval techniques described above
  • 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.
  • 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.
  • users can obtain desired results quickly, or revise queries, even before completing an intended query.
  • 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.
  • 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.
  • a phone number field associated with the user's selected Starbucks record
  • a simple mechanism such as a phone button or dynamic menu item
  • 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.
  • FIG. IA illustrates an environment adapted to support multi-prefix, interactive searching on a mobile communications device in accordance with some embodiments.
  • FIG. 1 B is a high level block diagram illustrating the data structure contained within the channel database in accordance with some embodiments.
  • FIG. 2 is a high level block diagram illustrating a functional view of a typical mobile communications device in accordance with some embodiments.
  • FIG. 3A is a flowchart illustrating a process of client-server interaction during multi-prefix, interactive searching in accordance with some embodiments.
  • FIG. 3B is a flowchart illustrating a process of client-server interaction during multi-prefix, interactive searching in accordance with some other embodiments.
  • FIG. 3C is a flowchart illustrating a process of client-server interaction during multi-prefix, interactive searching in accordance with some other embodiments.
  • FIG. 4 is a flowchart illustrating a process for interactive searching in accordance with some embodiments.
  • FIG. 5 is a flowchart illustrating a process for creating a multi-term prefix index in accordance with some embodiments.
  • FIG. ⁇ is a flowchart illustrating a process for creating a table of contents in accordance with some embodiments.
  • FIG. 7 is ⁇ flowchart illustrating a process for sending interactive search results in accordance with some embodiments.
  • FIG. 8 is a flowchart illustrating a process for sending interactive search results in accordance with some embodiments.
  • FIGS. 9A-9M illustrate graphical representations of screenshots of a display of a mobile communications device in accordance with some embodiments.
  • FIGS. 1 OA-I OC illustrate graphical representations of screenshots of a display of a mobile communications device in accordance with another embodiment.
  • FIGS. 1 1 A-1 1 C 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.
  • 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.
  • FIG. IA 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 1 18 and a search server 128 coupled to a data store 1 12.
  • the network 122 can include links using technologies such as Wi-Fi, Wi-Max, 2G, Universal Mobile Telecommunications System (UMTS), 3G, Ethernet, 802.1 1 , integrated services digital network (ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc.
  • technologies such as Wi-Fi, Wi-Max, 2G, Universal Mobile Telecommunications System (UMTS), 3G, Ethernet, 802.1 1 , integrated services digital network (ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM), InfiniBand, PCI Express Advanced Switching, etc.
  • ISDN integrated services digital network
  • DSL digital subscriber line
  • ATM asynchronous transfer mode
  • InfiniBand PCI Express Advanced Switching
  • 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.
  • 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).
  • SSL secure sockets layer
  • VPNs virtual private networks
  • IPsec Internet Protocol security
  • the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
  • the network 122 can also include links to other networks such as the Internet.
  • the client 1 18 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, ⁇ WAN, ⁇ mobile, wired or wireless network, ⁇ private network, or a virtual private network, and any combination thereof.
  • the search server 128 includes a search result update module 1 1 ⁇ , 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.
  • the search result update module 1 16 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.
  • the search server 128 is coupled to a data store 1 12.
  • the data store 1 12 includes a channel database 1 14, 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 1 14 contains
  • Each record contains a heading and one or more URLs. The record also contains an indication as to whether each URL references a channel.
  • 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.
  • the channel database 1 14 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).
  • 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.
  • 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.
  • the data fields 144 may contain items such as a title, an author, an International Standard Book Number (ISBN) and a price.
  • the data fields 144 may contain a name, an address, a home phone number and a mobile phone number.
  • one data field 144 contains multiple items. In other embodiments, each data field 144 contains separate items.
  • 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”).
  • 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, 1 G or more of memory, and 10OG or more of disk storage.
  • LINUX open-source operating system
  • 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).
  • Figure IA shows the search result update module 1 16, the multi-prefix search module 150, the multi-tier search module 152, the result delivery search module 154, the channel database 1 14, the index database 130 and the table of contents database 132 as discrete modules.
  • any or all of the result update module 1 16, the multi-prefix search module 150, the multi-tier search module 152, the result delivery search module 154, the channel database 1 14, 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.
  • the search server 128 and the data store 1 12 are shown as discrete components for purposes of illustration. In other embodiments, the search server 128 and the data store 1 12 can also be combined for operation on a single computing device having storage.
  • 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.
  • 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.
  • 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.
  • the mobile communications device 200 is adapted to execute computer program modules for providing functionality described herein.
  • module refers to computer program logic utilized to provide the specified functionality.
  • a module can be implemented in hardware, firmware and/or software.
  • 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.
  • Embodiments of the entities described herein can include other and/or different modules than the ones described here.
  • the functionality attributed to the modules can be performed by other or different modules in other embodiments.
  • this description occasionally omits the term "module" for purposes of clarity and convenience.
  • 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.
  • 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 1 14 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.
  • 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.
  • "St" corresponds to search results "SJARBUCKSTM Store Locator,” "FlightView Airline Flight Status,” “Stock Quotes,” etc.
  • 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.
  • 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.
  • the result selected is a web page
  • a separate web browser is launched to display the web page.
  • the user has selected the STARBUCKSTM Store Locator channel 906 (FIG. 9B). This selection directs the user to the STARBUCKSTM Coffee Store Locator channel as shown in FIG. 9C.
  • 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 1 14 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 1 16. 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.
  • a wild card character or a symbol can be used in place of spaces between multiple prefixes of a search.
  • 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.
  • 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.
  • 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.
  • Search results 926 that match the search query are displayed 330 in the display area 933 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.
  • the desired result in the list of results 926 is displayed (332-Yes)
  • the desired result may be selected 334 and additional information about the result may be displayed.
  • 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.
  • 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.
  • the search is performed on structured data, such as the data set described in the channel database 1 14.
  • the search is performed on unstructured data, which includes data and links without categorized fields.
  • FIGS. 9C-9G provide an illustration of the method.
  • the window 920 for the STARBUCKSTM 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.
  • the search results list 926 is refreshed with search results that match the updated search query having two prefixes.
  • 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.
  • 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. 91) 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.
  • the desired result such as in FIG. 91, the result heading may be selected and additional information may be received.
  • FIG. 1OA 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. 1 OA 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).
  • a prefix is entered into the search query field 1004 and display area 1005 is refreshed to show results 1022 as shown in FIG. 1 OB.
  • the search results 1022 include information associated with a record. The information represents the items contained in the data fields associated with the record.
  • 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.”
  • the display area 1005 is refreshed with new results 1024.
  • the prefixes (“El 5") are found across multiple data fields, therefore displaying results matching a name that includes "El" and a grade that includes "5.”
  • the result 1022 or 1024 may be selected to display additional results.
  • 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.
  • 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.
  • 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.
  • 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. 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.
  • 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.
  • 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.
  • 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.
  • 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 51 ⁇ into lists - one list for each prefix.
  • the list of record IDs is compressed 518.
  • FIG. ⁇ 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.
  • the threshold value is user-definable and can be adjusted to maximize prefix search performance on a particular hardware system and user preferences.
  • 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.
  • FIG. 7 is a flowchart illustrating a process 400 for sending interactive search results in accordance with some embodiments.
  • a query is received, it is split 702 into individual prefix terms.
  • 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.
  • 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.
  • FIG. 8 is a flowchart illustrating a process 800 for sending interactive search results in accordance with some embodiments.
  • 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.
  • 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. 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
  • a consistent search mechanism 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.
  • 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).
  • these data fields such as phone numbers
  • these data fields 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).
  • 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. 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 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.
  • 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 1 18, illustrated in FIG. IA (components of which are further detailed as device 200 in FIG. 2).
  • client 1 18, illustrated in FIG. IA 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. IA), rather than on resource-constrained client 1 18.
  • server 128 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 1 18, 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.
  • the client (implemented, for example, as one of the client applications 124 on client 1 18, and sometimes referred to herein interchangeably with client 1 18) 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.
  • this general-purpose functionality implemented by a client application on client 1 18 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 1 18, as well as to extract dynamic menu information from the HTTP headers), and (iv) interacting with the user of client 1 18 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 1 18, such as placing a phone call or sending an email in response to a user request.
  • search server 128 such requests containing, for example, keystrokes of a user'
  • search server 128 generates results at various tiers of a multi-tier user query, and sends those results to client 1 18.
  • results include a collection of records 142 with associated fields 144 (illustrated in FIG. I B), typically associated with a particular channel being queried by a user of client 1 18.
  • a given record 142 typically includes one or more fields 144 that are displayed to the user on the screen of client 1 18, 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.
  • URI for example, a link
  • client 1 18 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.
  • server 128 sends to client 1 18 a landing page 931 associated with that channel for display on client 1 18, as illustrated in FIG. 9C.
  • the user activates the "Los Altos Collinso" record 935 illustrated in FIG.
  • client 1 18 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.
  • server 128 sends to client 1 18 a web page 941 (with additional detail corresponding to selected "Los Altos Collinso" record 935) for display on client 1 18, as illustrated in FIG. 9G.
  • 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 1 18 without the assistance of browser 120.
  • 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 1 18 (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.
  • 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.
  • 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 1 18 (such as elapsed time or user location via GPS services).
  • HTTP header might contain a dynamic menu item that enables a user to call the phone number of a selected record.
  • client 1 18 could display a dynamic menu containing a "Call Store” item and, if the user selects that item, client 1 18 could then dial the phone number of the Los Altos Rancho Starbucks store (contained in the additional phone number field previously sent to client 1 18 by server 128 in response to the user's multi- prefix "Ran I a" query).
  • 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 1 18 could distinguish the number of times a record was "tapped,” or how long it had been "held down.”
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • This extensible "dynamic dynamic menu” feature enables the generation of record-specific, as well as channel-specific, menu items.
  • a movie channel might contain various types of field data, such as movie titles and actor names.
  • 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).
  • search result "actor” records for example, “Show Bio” or “Show Filmography”
  • search result “movie” records for example, “Show Actors” or “Show Reviews”
  • This dynamic menu HTTP header architecture is illustrated in Table 1 below, which includes six distinct fields of a dynamic menu HTTP header.
  • Table 1 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.
  • B-Menu-Entry-4 CIN; Change location; i:change%20location ⁇ r ⁇ n
  • 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.
  • 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.
  • 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 1 18).
  • these symbolic names can also be used to modify the functionality of a dynamic menu item.
  • 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 1 18, rather than to a web browser, such as browser 120.
  • 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 1 18 (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.
  • server 128 see FIG.
  • the first field of each header 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.
  • nnn serves to determine the order in which the "Menu Item Name” (discussed below) will appear when the dynamic menu is displayed.
  • 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).
  • the header in row 2 of Table 2 would appear as the third menu item in the dynamic menu actually displayed to the user.
  • this 'Header Name" field is delimited, in one embodiment, from the next field ("Context") by a colon (":”) character.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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).
  • the "B" designation indicates that this function could apply to the current channel as well as to the selected item.
  • activation of the "Add to favorite" dynamic menu item would add the Yellow Pages channel to the user's list of "favorites.”
  • the selected store not the Yellow Pages channel
  • 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).
  • 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.
  • 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.
  • 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).
  • this client application including invocation of a built- in feature of the user's mobile device, such as placing a phone call
  • O for example, by launching another client application, such as a web browser or mapping application.
  • 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.
  • 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).
  • HTTP request containing the relevant URI
  • server 128 or, in other embodiments, to third-party servers hosting particular channel functionality.
  • server 128 clear that variable by setting it to a null value.
  • 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).
  • headers in Table 2 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.
  • the "Movie details" header in row 7 of Table 2 directs the client application to construct ⁇ 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.
  • 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.
  • 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).
  • a dedicated mapping application could be employed instead of a web browser.
  • 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.
  • 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).
  • the (F) designation could be ignored.
  • R Refresh Channel
  • S Clear Search Filter
  • 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.
  • 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).
  • 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).
  • the "Next Step” field in one embodiment, is delimited by a semicolon (";").
  • 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 1 18. As noted above, the order of these menu items is determined by the "Header Name” field.
  • 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).
  • the dynamic features of this Action field 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.
  • 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).
  • server 128 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).
  • the remaining portion of the URI consists of three variable assignments separated by "ampersand” ("&") delimiters, followed by (as noted above) "carriage retum/newline” or “ ⁇ r ⁇ n” characters, which serve to separate individual dynamic menu HTTP headers from one another.
  • 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.
  • 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.
  • 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.
  • 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.
  • this functionality can even be invoked without requiring the user to activate the dynamic menu item.
  • the client application detects that the user pressed the "Talk” button on client 1 18, 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • server 128 relies upon a third-party web server to return this web page, after passing it the location data.
  • 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).
  • 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).
  • the user after querying the AOL Movietone 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.
  • this URI is sent via browser 120 to a third-party site (AOL's Movietone 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 Movietone web server to return ⁇ "movie details" web page to browser 120 based upon the specified parameter values.
  • 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).
  • 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.
  • 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.
  • use of an "exclamation point” (“!) character for example, "$!1 ”
  • a "percent" (“%) character (following a "$" or "$?" or "$! character combination) will direct the client application not to URL-encode the referenced field data.
  • a "$p" character combination is used to reference the mobile device's GPS latitude/longitude coordinates (if GPS functionality is present on the device) .
  • client 1 18 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.
  • additional HTTP headers can be employed to cause channel "refreshes" under program control.
  • Server 128 could also notify client 1 18 when the user is within a certain distance of a selected destination.
  • ⁇ client application in one embodiment of the present invention displays a window 1 102 when initially invoked by a user of a mobile communications device (such as client 1 18 in FIG. IA or device 200 in FIG. 2) on which the client application is loaded. It should be noted that another similar embodiment of window 1 102 is also illustrated as window 902 in FIG. 9A.
  • Window 1 102 contains various component display areas, including a small area 1 103 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 1 104, to facilitate the entry of user queries, including the multi-prefix queries discussed above, as well as a results display area 1 105 to display the results of such user queries.
  • search query field 1 104 to facilitate the entry of user queries, including the multi-prefix queries discussed above, as well as a results display area 1 105 to display the results of such user queries.
  • results display area 1 105 contains a list of various categories of channels, including a user's previously designated “favorite” channels 1 106 (as well as links and other previously designated records) and other available channel categories 1 107.
  • results are provided to client 1 18 by server 128 (typically in response to user requests), and may be updated over time.
  • window 1 102 may display certain headings, such as the "Favorite Channels" heading 1 108, which describes the collection of user-defined “favorites” displayed below heading 1 108 (but which cannot, in one embodiment, be selected or activated to perform any additional function).
  • window 1 102 also includes a "fixed menu" display area 1 109 containing certain commonly-used features, such as a "Back" menu item that will refresh window 1 102 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 1 109 to invoke a menu with a set of items that provide additional functionality, as will be explained below.
  • the "Back" and “Menu” items can be mapped to and invoked by keystrokes or buttons on the user's mobile device.
  • 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).
  • a user can enter characters into search query field 1 104, or simply select and activate a channel or channel category.
  • client 1 18 submits such user requests to server 128, which returns a collection of filtered results which client 1 18 displays in results display area 1 105. Examples of such multi-tiered and multi-prefix user queries have been illustrated above in great detail.
  • client 1 18 when the user initially invokes the client application, client 1 18 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. 1 IA.
  • 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.
  • server 128 also sends a "GET" request, which directs client 1 18 to display the "list” of data that follows the HTTP headers.
  • Server 128 also informs client 1 18 that the "Incremental Search” capability is turned “on” (to provide interactive results as the user types characters into search query field 1 104 in FIG. 1 IA).
  • 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 1 108 in FIG.
  • 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.
  • 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.
  • the "Remove from favorites" Action field includes ⁇ "remove” parameter to enable server 128 to distinguish this request from an "Add to favorites" request.
  • a third field (“field 3") is referenced, which is used by client 1 18 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.
  • 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.”
  • the "Add to favorites" dynamic menu item contains a "$!3" designation, which directs client 1 18 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.”
  • Following these HTTP headers in Table 3 is the body of the transmitted message containing the list of data to be displayed by client 1 18 in results display area 1 105 of window 1 102 shown in FIG. 1 IA.
  • the hex-formatted digits at the beginning of certain rows of data specify standard color and aesthtic 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.
  • 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.
  • FIG. 1 1 B A user might desire to remove a previously defined favorite channel (or other record).
  • the user selects a favorite channel which the user desires to remove, such as "Loyola School Directory" channel 1 1 1 ⁇ in window 1 1 12, and invokes menu item 1 1 19a in menu display area 1 1 19 , which results in the display of dynamic menu 1 1 15.
  • client 1 18 detects that selected record 1 1 16 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 1 1 15a (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 1 1 15. These "global” menu items can be “hardwired” into client 1 18 (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).
  • the user can select and activate "Remove from favorites" dynamic menu item 1 1 15a, which will cause client 1 18 (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.
  • the "Remove from favorites” item is not contextually relevant and is not displayed (in one embodiment) when the user invokes a dynamic menu.
  • FIG. 1 1 C for example, if the user selects a record such as "Business" channel category 1 126, and then invokes menu item 1 129a in menu display area 1 129, client 1 18 displays dynamic menu 1 125, which does not contain a "Remove from favorites" dynamic menu item, but does contain an "Add to favorites" menu item 1 125a.
  • client 1 18 detects that selected "Business” channel category record 1 126 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 1 125a (but not the “Remove from favorites” dynamic menu item, due to the "$3" designation in its header). Having selected channel 1 126, the user can select and activate "Add to favorites” dynamic menu item 1 125a, which will cause client 1 18 (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.
  • URI extract information from designated data fields
  • FIGS. 1 IA- 1 1 C 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.
  • the dynamic menu items also can change to reflect such differences, even at the level of a particular record.
  • UA-OS WinCE (Smartphone) - Version (5.1 ); Carrier (none); Boopsie - Version
  • Loyola School Directory i:../Loyola%20School%20Directory/ 1
  • client 1 18 Upon locating and activating this channel (in the manner discussed above), client 1 18 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).
  • 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).
  • server 128 before server 128 delivers to client 1 18 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).
  • browser 120 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.
  • 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.
  • server 128 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).
  • 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).
  • One major difference, however, is the presence of security information, since the user must log into (albeit somewhat indirectly) the actual "Facebook" web site.
  • 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.
  • MOFIID 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.
  • 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.
  • the "B-MOFIID: 2wl6n9pX5z4cV" header shown in Table 4 provides the user's MOFIID to the client application.
  • the URI shown in Table 4
  • the API key connecting server 128 with Facebook
  • the MOFIID used by server 128 to distinguish among users of the F ⁇ cebook Friends channel.
  • 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.
  • the Facebook web server delivers to browser 120 the web page 1212 shown in FIG. 12B.
  • 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).
  • 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.
  • the Facebook web server 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.
  • 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.
  • 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.
  • a third-party application such as ".xls" for Microsoft Excel or ".pdf” for Adobe Acrobat
  • 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.
  • UA-OS WinCE (Smartphone) - Version (5.1 ); Carrier (none); Boopsie - Version
  • B-MOFIID 2wl ⁇ n9pX5z4cV
  • B-Action skip-empty-links
  • B-List-Mode refreshs
  • B-Menu-Entry-1 BIR; Refresh
  • server 128 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.
  • 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).
  • 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.
  • menu display area 1239 includes menu item 1239a, which enables the user to display a dynamic menu.
  • the dynamic menu HTTP headers shown in Table 5 provide a variety of Facebook-specific functionality.
  • the client application 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.
  • 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).
  • 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).
  • the user could activate dynamic menu item 1245a to "poke” selected friend 1246 (via Facebook).
  • 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).
  • 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.
  • the user will remain in the browser 120, but can still return manually to the client application, which will be refreshed automatically.
  • UA-OS WinCE (Smartphone) - Version (5.1 ); Carrier (none); Boopsie - Version
  • B-Menu-Entry-5 BON; My profile; http://live.boopsie.com/host/facebookfriends/?profile
  • B-Menu-Entry-7 BIR; Log out; http://live.boopsie.com/host/facebookfriends/?logout
  • 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 125 ⁇ are now displayed (in accordance with the results received by client 1 18 and shown in Table 6).
  • 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).
  • 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).
  • 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.
  • the user will remain in the browser 120, but can still return manually to the client application, which will be refreshed automatically.
  • 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).
  • the filtered set of results (4 "friend” records) are included for display by client 1 18, as shown in FIGS. 12F and 12G.
  • REQUEST (with filter "d m")
  • Wi ⁇ CE (Sm ⁇ rtpho ⁇ e) - Version (5.1 ); Carrier (none); Boopsie - Version
  • B-Menu-Entry-5 BON; My profile; http://live. boopsie. com/host/facebookfriends/?profile
  • B-Menu-Entry-7 BIR; Log out; http://live. boopsie. com/host/facebookfriends/?logout
  • 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.”
  • a vertical web site or sites such as Amazon, Wikipedia or IMDB
  • 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.
  • the interoperability between a client application and a client web browser 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.
  • 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.
  • the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having” or any other variation thereof, are intended to cover a nonexclusive inclusion.
  • 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.
  • "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).

Abstract

La présente invention concerne des systèmes et des procédés pour récupérer des informations. La récupération d'informations est réalisée au moyen d'un modèle de recherche ciblé flexible et cohérent qui emploie des techniques de récupération d'informations de menu interactives, multipréfixes, multi-étages et dynamiques. Ces techniques fournissent une fonctionnalité spécifique du contexte spécialement adaptée à des canaux d'informations particuliers ainsi que des enregistrements à l'intérieur ou à travers de tels canaux et d'autres informations d'état connues. Une interface de recherche cohérente parmi de multiples étages à travers et à l'intérieur d'un grand domaine de sources d'informations est présentée à des utilisateurs qui n'ont pas besoin d'apprendre une syntaxe de recherche différente ou spéciale. Une architecture mince commandée par serveur client permet à des utilisateurs de dispositifs de communication mobiles à ressources limitées de localiser des informations ciblées plus rapidement en entrant un plus petit nombre de frappes de touche et en effectuant un plus petit nombre d'itération de requête et de rafraîchissement de page Web, ce qui permet de réduire la largeur de bande de réseau nécessaire.
PCT/US2008/067555 2007-06-20 2008-06-19 Menu dynamique pour recherche mobile interactive multipréfixe WO2008157730A1 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US94530007P 2007-06-20 2007-06-20
US60/945,300 2007-06-20
US94709907P 2007-06-29 2007-06-29
US60/947,099 2007-06-29
US11/970,414 2008-01-07
US11/970,414 US8255377B2 (en) 2007-01-07 2008-01-07 Multi-prefix interactive mobile search
US4807308P 2008-04-25 2008-04-25
US61/048,073 2008-04-25

Publications (1)

Publication Number Publication Date
WO2008157730A1 true WO2008157730A1 (fr) 2008-12-24

Family

ID=40156704

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/067555 WO2008157730A1 (fr) 2007-06-20 2008-06-19 Menu dynamique pour recherche mobile interactive multipréfixe

Country Status (1)

Country Link
WO (1) WO2008157730A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108684206A (zh) * 2017-05-18 2018-10-19 华为技术有限公司 一种搜索方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070006099A1 (en) * 2004-03-11 2007-01-04 Eric Johnson Restricted user interface navigation
US20070055652A1 (en) * 2005-08-24 2007-03-08 Stephen Hood Speculative search result for a search query
US20070067267A1 (en) * 2005-09-21 2007-03-22 Stephen Ives Systems and methods for managing the display of sponsored links together with search results in a search engine system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070006099A1 (en) * 2004-03-11 2007-01-04 Eric Johnson Restricted user interface navigation
US20070055652A1 (en) * 2005-08-24 2007-03-08 Stephen Hood Speculative search result for a search query
US20070067267A1 (en) * 2005-09-21 2007-03-22 Stephen Ives Systems and methods for managing the display of sponsored links together with search results in a search engine system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108684206A (zh) * 2017-05-18 2018-10-19 华为技术有限公司 一种搜索方法及装置
US11321407B2 (en) 2017-05-18 2022-05-03 Honor Device Co., Ltd. Search method, and apparatus

Similar Documents

Publication Publication Date Title
US11500883B2 (en) Multi-prefix query optimization
US8255382B2 (en) Dynamic menus for multi-prefix interactive mobile searches
US20210132917A1 (en) Leveraging Collaborative Cloud Services to Build and Share Apps
US20200110782A1 (en) Dynamic Menus for Multi-Prefix Interactive Searches Using Predictive Text to Yield Targeted Advertisements
US20110078243A1 (en) Leveraging Collaborative Cloud Services to Build and Share Apps
US7840579B2 (en) Mobile device retrieval and navigation
US20170024424A1 (en) Suggestive search engine
WO2010132491A2 (fr) Menus dynamiques pour recherches mobiles interactives à préfixes multiples utilisant du texte prédictif pour produire des publicités ciblées
US20080168039A1 (en) Multi-Prefix Interactive Mobile Search
RU2633180C2 (ru) Система и способ управления браузерным приложением, постоянный машиночитаемый носитель и электронное устройство
KR102146261B1 (ko) 전자 장치 및 전자 장치의 대화 메시지에서 의미개체 추출 및 이용방법
WO2008157730A1 (fr) Menu dynamique pour recherche mobile interactive multipréfixe
US20140359426A1 (en) Method and apparatus for providing suggestion for browser address bar input, browser and terminal thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08771515

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08771515

Country of ref document: EP

Kind code of ref document: A1