Mobile Directory Access
Searching for records in a server-based structured database, such as a public directory/phone book, using a mobile device, such as a cell phone, can be slow and cumbersome. Mobile Directory Access (MDA) is a search facility that uses a patent pending approach to reduce the number of keystrokes required and cuts down substantially on the amount of time required. This is done by establishing a connection between the mobile device and a server application when the user starts the search process, and interacting as the user enters the name to look for. The server based application provides feedback as the user enters the search string, minimizing the amount the user has to enter usually only requiring a few characters.
way to understand how this improves the process is to show a typical search
process using the current state of the art.
Following are a typical sequence of steps Jack would use for looking in
a corporate address book for Joe Saunders in
As should be clear from the example, this process can require hundreds of keystrokes and, due to poor feedback, is slow and frustrating. It is not the type of interface generally used to search contact lists on a mobile phone. In a typical mobile phone contact list lookup, the user can narrow down the list of names by entering the first few characters, than page up and down through the contact lists. Mobile Directory Access provides an interface similar to the typical contact list lookup interface against a much larger server-based database.
There are two major challenges that have to be met to provide quick, convenient access to a server-based database:
There are several interesting uses of a network based directory that make sense once it is easy and seamless to access. Following are three examples:
MDA Use Case 1 – Getting address/ phone number
MDA Use Case 2 – Getting enterprise e-mail address
MDA Use Case 3 – Reverse lookup
The following two drawings show two possible implements of Mobile Directory Access; within an enterprise (for access to an enterprise directory), and outside an enterprise (for access to a public directory). Note that though Mobile Directory Access is designed and built specifically for address book access, the patented search technique can be used to access other structured databases.
Figure 2: Operator based server
In both figures, there are three basic components; the mobile device, the directory server, and a source of directory information. The connection between the directory source and the directory server is LDAP or some other protocol that provides directory entries to the directory server. The directory server keeps a full copy (cache) of the directory to maximize overall performance of the solution, so the connection to the directory source doesn’t have to be up all the time. It could be simply a nightly connection.
The connection between the mobile device and the directory server is over TCP/IP. The higher level protocol, called IDAP (Interactive Directory Access Protocol), has been created for MDA. It is designed to be compact to minimize the quantity of data transferred and provide fast response time. It is also stateless to simplify implementation.
The IDAP protocol contains seven commands issued by the client (mobile device) to the directory server as follows:
Gets matching last names given character or numeric partial last name. Used for last name first lookup.
Gets matching first names given full character last name and character or partial first name. Used for last name first lookup.
Gets matching first names given character or numeric partial first name. Used for first name first lookup.
Gets matching last names given full character first name and character or partial last name. Used for first name first lookup.
Gets first qualifiers (e.g. branch office) given full character first and last names. Other Getqx commands could be added if addition qualifiers needed.
Gets full directory record information (phone numbers, addresses, etc.) for one or more directory entries given character first name, last name and qualifier(s).
Log off and disconnect
For all the Get commands, options are available to control the maximum number of entries to return and
Demo of last name first predictive lookup
The best way to understand how this invention works is to see it demonstrated. Since that is not possible in a paper, a set of screenshots and short videos from a demo is the best we can do. These screen shots were made on a test system with a test corporate directory of one million entries. The directory was generated using US census data, with names randomly generated from the 89000 most common last names and 5500 most common first names. The occurrence of names is based on the frequency of names from the census data to make the demo more realistic (e.g. there are a lot more Smiths than Wattenbergers and a lot more Johns than Jaquelines). The demo was done with a mobile device emulator with a standard screen:
Figure 3: Phone menu
When the user selects the “Directory” application, the phone connects to the directory server and displays the entry screen below.
Figure 4: Main directory application screen
Before going through the demo, it’s necessary to explain the format of the screen. The following two figures show the fields:
Figure 5: Explanation of fields (part 1)
Figure 6: Explanation of fields (part 2)
Note that the screen format is for demo purposes only and should be simplified for a distributed product.
in the demo is looking for Dorothy Chandler in the
The demo user hits “2” first for the first character of the last name “C”. The MDA client makes a query to the MDA server to search for last names starting with A, B, and C and returns the most common:
Figure 7: Response from “2”
The server must be able to respond to these types of queries instantly, so the directory indexes are designed for both t9 and character lookup and are kept in memory.
Figure 8: Response from “24”
The MDA server
returns any exact matches first, in this case “Bi” and then the most common
names starting with “24”. Note that “
Figure 9: First names
At this point, the user could start entering the first name Dorothy with a “3” for “D”, or use the navigation key to move down and select Dorothy. In either case, once the first name is picked, the MDA client checks to see if there is more than one match. In this case, there are 4 Dorothy Chandlers, so a list of offices with a Dorothy Chandler is displayed (this requires a query to the server):
Figure 10: List of offices
point, the user uses the navigation key to select
Figure 11: Name detail
The user can hit Options to perform any of several functions, including adding the name to the contact list, calling the user, sending a message, etc.
Figure 12: Option menu
This demo shows how the interactive nature of the invention reduces the keystrokes required and minimizes server interaction. The user only had to enter 2 characters of the name, and there were 5 queries issued to the server. This is on the low end of characters required - a typical lookup requires 4 or 5 with a large directory. This is still substantially less than the current state of the art.
The client used to create the screenshots above is C++ Symbian based. Here is a video of the same search using a different client developed in J2ME.
Demo of first name first, non-t9 lookup
The second example shows a non-t9 query for the same name entering first name first. The user starts out by entering “D” on a qwerty device, or a single “3” on a non-qwerty device.
Figure 13: Start of non-t9 query
Note that the names are listed alphabetically, rather than most common first. This is less confusing, especially for the occasional user, but tends to require more keystrokes. The user can use the navigation key to move down to get to a name even names that are not shown on the screen. The application will ask for more names if the user navigates beyond the list returned. The server can be configured to set the number of names to return for a query.
The following figure shows the continuation of the conversation:
Figure 14: Continuation of non-t9 lookup
Note that since names are listed alphabetically, the user has to enter more characters, in this case, 6 in total.
following four short videos show how quick lookups are. They are around 10 to 20 seconds each and all
show lookups of “Sharon Lawrence” a Junior Programmer in the
1. Predictive last name first lookup. User enters “52” for first two chars of last name and selects first name from list.
2. Non-predictive last name first lookup. User enters “lawr” and “sh”.
3. Predictive first name first lookup. User enters “74” for first name and “5” for last name.
4. Non-predictive first name first lookup. User enters “sharo” and “law”
Other uses of directory
The demos above show only one possible way to get to the directory from the mobile device user interface. The directory should also be searchable during other mobile device operations, for example:
The directory should feel like a natural seamless extension to the contact list and be easy to access whenever the user is within network range.