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.

 

The best 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 Seattle:

 

  1. Jack launches an address book search application on his mobile phone.
  2. The application displays a screen with input areas for First Name, Last Name, and Office Location and a “Submit” button.
  3. Jack uses his keypad to enter “Joe” in the First Name, “Saunders” in the Last Name and leaves Location blank.  Entering the data is slow since Jack’s phone has a standard phone keypad (digits 1 through 9 and 0 and a navigation key to move the cursor).  Each character takes multiple keystrokes using the standard method of entering text with a phone keypad (e.g. the “S” requires entering “7777”).
  4. Jack uses the navigation key to get to the “Submit” button and selects it.
  5. The application sends a search request to the server, and the server responds “name not found”
  6. Jack changes the First Name to Joseph and hits Submit again.
  7. The application sends a search request to the server, and the server responds that the name is ambiguous.
  8. Jack fills in the Location field and hits Submit again.

 

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:

  1. Since the database is on a server, not on the mobile device, there is a server component required and a highly efficient communication mechanism;
  2. Mobile phone contact lists are typically fairly small (tens to hundreds of entries) while public databases can be very large (thousands to millions of entries).  The approach has to work well with large databases and be very efficient with large indexes.

 

Use cases

 

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

 

  • Joe is on the way to pick up his daughter at the Johnson’s in Newton and realizes he forgot to bring the address and phone number
  • He pulls over and opens the MDA client to search for Johnson in Newton (the MDA client could be either on a phone, or another device such as a car navigator)
  • He finds a Johnson on the right street and goes to the address (or calls the number to get directions)

 

MDA Use Case 2 – Getting enterprise e-mail address

 

  • Francis is in the airport on her way to a meeting with Joanne Snyder in the Denver office who she doesn’t know well
  • Her plane is delayed and she wants to send Joanne a quick e-mail to say she will be late
  • She enters the message using her phone e-mail client, but realizes she doesn’t have Joanne’s address
  • She invokes the MDA client while adding recipients to find Joanne Snyder in the Denver office
  • Since Francis doesn’t know exactly how to spell Snyder, and whether Joanne goes by Jo, she quickly checks multiple spellings

 

MDA Use Case 3 – Reverse lookup

 

  • Jack receives a call which he can’t answer because he is in a meeting
  • The caller doesn’t leave a message
  • When he looks through his call log, Jack sees a number he doesn’t recognize, but there is no caller id since it is a mobile number
  • He wants to know who it’s from because he is anticipating a call from sales about the McGregor account
  • He selects the MDA reverse lookup option and gets the contact information for the caller
  • It is from sales, so he returns the call and tells the MDA client to add the name to his personal address book for future reference

 

Architecture

 

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 1: Enterprise based server

 

 

 

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:

 

Command

Function

Getln

Gets matching last names given character or numeric partial last name.  Used for last name first lookup.

Getfn

Gets matching first names given full character last name and character or partial first name. Used for last name first lookup.

Getffn

Gets matching first names given character or numeric partial first name. Used for first name first lookup.

Getfln

Gets matching last names given full character first name and character or partial last name.  Used for first name first lookup.

Getq1

Gets first qualifiers (e.g. branch office) given full character first and last names.  Other Getqx commands could be added if addition qualifiers needed.

Getdetail

Gets full directory record information (phone numbers, addresses, etc.) for one or more directory entries given character first name, last name and qualifier(s).

Quit

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.

 

The user in the demo is looking for Dorothy Chandler in the New York office.  The demo system defaults to asking for the last name first in predictive (T9) mode.  By using the Option menu, the user could change the search to first name first and/or change the character entry to normal characters (non-t9).  The non-t9 mode makes sense for mobile devices with full (qwerty) keyboards, and even with standard phone keyboards it can be easier to use.  However, we will use last name first, predictive mode for the first part of the demo.

 

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.

 

Since Chandler has not shown up yet, the user enters the second character “4” for “h”.  The application makes a query to the server for “24” last names and returns:

 

 

 

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 “Chandler” is listed on the screen, so the user uses the navigation key to get to Chandler and selects it. 

 

There are 317 Chandlers in the directory, so the MDA client makes a request to get the most common Chandlers and returns a list of first names for Chandlers in the directory (sorted by frequency):

 

 

 

    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

 

At this point, the user uses the navigation key to select New York and the user is given detailed information about all the Dorothy Chandlers in New York (in this case there is only 1):

 

  

 

                  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.

 

More videos

 

The 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 San Jose office.  These demos were done with the same one million user directory with the J2ME client:

 

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:

 

  1. While looking at the phone contact list;
  2. While specifying a recipient for a message (e.g., SMS, MMS and email);
  3. While looking through the call log through a reverse (phone number) lookup to get detailed information about the caller.

 

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.