 |
Description  |
|
|
BACKGROUND OF THE INVENTION
The present invention relates generally to graphical user interfaces in
telephony, and more particularly to scrolling lists with automatic
compression and expansion.
In light of the rapid technological developments and globalization of the
world economy, the role of telecommunication is becoming increasingly
important. As such, there is a growing focus on using state of the art
computer technology to provide new and improved telecommunication
capabilities. The capability of combining voice and digital data
transmission is enabled by the GSM (Global System for Mobile
Communications) protocol.
One popular feature, commonly referred to as Caller ID or CLID (Calling
Line Identification), displays the caller's name and telephone number on
the receiver's device as shown in FIG. 1A. CLID information is stored at a
public telephone network and delivered to the receiver's display device if
the receiver subscribes to the Caller ID feature.
There are also telephones that can store a list containing names, multiple
telephone numbers, and address information. PDAs (Personal Digital
Assistants), provide graphical icons associated with particular telephone
numbers.
Also available today are communicators that facilitate various types of
communication such as voice, faxes, SMS (Short Messaging Services)
messages, and Internet-related applications. One such product offers a
"contacts" feature for managing contact information including names,
telephone numbers, and addresses. It also allows exchanging contact
information as business cards in an SMS message.
Conventional devices, however, have two distinct modes of operation: open
and closed. When closed, the product operates as a telephone and the user
cannot access the display of the contacts cards. To display the contacts
cards, the product must be open and in hands-free mode. When the product
is open, if the phone part of the product was not previously turned on,
the user must close the product and turn on the phone part of the product,
then reopen the product in PDA mode to make a call.
Additionally, the product has separate, distinct applications that handle
each type of communication tasks. The distributed interface of the product
is highly compartmentalized by applications, thus restricting the sharing
of information between applications. Specifically, the telephone
application and contacts application are completely independent and must
be launched separately. Because the two applications do not share
information, it sometimes requires the user to input the same information
in both applications. Furthermore, features of each application may only
be activated within the respective application.
When a user is in a telephone application, for example, a user cannot
manipulate a contacts card. Therefore, to modify or update a contacts card
information, the user must launch a contacts application. Similarly, the
user can initiate a call only from a telephone application and not from a
contacts card. Even if a user enters a telephone number in a telephone
application, this information cannot be saved in a contacts application as
a new contacts card. Likewise, the product does not allow information to
be shared between the telephone application and the contacts application.
To create a contacts card, the user must launch the contacts application,
select "logs," choose a communication event (such as call received), then
press "create card" to create a new contacts card. Even so, these series
of steps only transfers the telephone number but not the associated name
to a new contacts card, and any additional information must be entered
within the contacts application. To initiate a call, the user must leave
the contacts application by pressing the hard key for "telephone." The
telephone directory displays only the names but not related fields.
Current telecommunication features also do not take full advantage of CLID
information. Specifically, CLID information is used for display purposes
only in providing information to the receiver about the caller. After the
CLID information is displayed, it cannot be manipulated, transferred to
another device or user, or used in other application programs.
Additionally, besides the name and the number of the caller, CLID does not
provide additional information that further defines the type of
communication device or the location of the caller. For example, the
receiver may not know or remember whether the displayed number is a
wireline or wireless, or a work or home telephone number. This type of
information would further assist the receiver in determining the caller's
device and location, thus, further defining the importance of the call.
Generally, telephone networks only transmit the caller's CLID information
to the receiver. There are currently some private networks that transmit
CLID information to both the caller and the receiver. As mentioned above,
however, the transmitted CLID information has been limited to only the
name and the number of the other party.
Moreover, directories are stored in the memory of the communication device,
which generally has limited storage capacity. This restricts the device's
ability to store a desired amount of information in the device. Related to
this problem is the need to store information at different locations
within the device. For example, speed dial data is stored separately from
the main directory data. Not only does this duplicate the data entry
process, data maintenance and updates need to be performed for each
location to avoid unsynchronization of the data.
Searching for an entry in the directory can also be tedious. Unless the
user remembers the name of the entry and conducts a text search for the
desired entry, the user must scroll through each entry sequentially. In
doing so, if each entry contains many related fields, scrolling through
each entry while displaying other unnecessary fields reduces the
efficiency of the search. Not only does this slow down the search
significantly, it also makes the search more difficult. Additionally, the
directory does not present additional information that further defines the
type of communication device or the location of the caller in an easily
recognizable manner.
Therefore, it is desirable to integrate various telecommunication
applications to simplify user interfaces and facilitate efficient
information sharing.
It is also desirable to manipulate the CLID information to provide enhanced
user interfaces.
It is further desirable to provide additional information related to the
CLID to better identify the caller's identity and location of the call.
In addition, it is further desirable to improve the search feature to
scroll through the directory more easily.
SUMMARY OF THE INVENTION
Systems and methods consistent with the present invention automatically
compress and expand the display of the directory during scrolling.
Specifically, a method for providing electronic business cards for a
communication device consistent with this invention comprises several
steps.
Initially, a plurality of electronic business cards, each including a
telephone number and associated information, are stored in a memory. A
user input selecting one of the electronic business cards is received,
upon which, the selected one of the electronic business cards is
displayed. Thereafter, a user input selecting the telephone number of the
displayed electronic business card is received, and a all is initiated
automatically to the selected telephone number of the electronic business
card.
A system for providing electronic business cards for a communication device
comprises a database, a first and second receiving means, a display, and
an initiating means. A database stores a plurality of electronic business
cards each including a telephone number and associated information and
first means receives a user input selecting one of the electronic business
cards. A display then displays the selected one of the electronic business
cards. Second receiving means receives a user input selecting the
telephone number of the displayed electronic business card, and the
initiating means initiates a call automatically to the selected telephone
number of the electronic business card.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part
of this specification, illustrate the invention and together with the
description, serve to explain the principles of the invention.
In the drawings,
FIG. 1 shows a prior art CLID display;
FIG. 2 is a diagram of a communication network consistent with the
principles of the present invention;
FIG. 3 is a diagram of a mobile telephone shown in FIG. 2;
FIG. 4 is a block diagram showing the elements of the mobile telephone of
FIG. 3;
FIG. 5 is a block diagram showing the components of the memory of FIG. 4;
FIG. 6 is a table illustrating the format of the information stored in the
directory;
FIG. 7 is a flowchart illustrating the process for creating a new
Electronic Business Card (EBC);
FIGS. 8A-8D show sample screens for creating a new EBC;
FIG. 9 is a table illustrating exemplary icons;
FIG. 10 is a sample screen for creating or modifying an icon;
FIGS. 11A-11B show sample screens illustrating a completed EBC;
FIGS. 12A-12C show sample screens for creating an EBC using CLID
information;
FIGS. 13A-13B show sample screens of the directory view of the entries;
FIG. 14 is a flowchart illustrating the process for the scrolling feature;
FIGS. 15A-15B show sample screens of compressed and expanded view of the
directory during scroll;
FIG. 16 is a flowchart illustrating the process for transmitting an EBC;
FIGS. 17A-17B show sample screens for sending an EBC;
FIGS. 18A-18B show sample screens for receiving an EBC;
FIG. 19 is a flowchart illustrating the process for the drag-and-drop
feature;
FIGS. 20A-20B show sample screens showing the drag-and-drop feature; and
FIGS. 21A-21B show sample screens illustrating an exemplary application of
the drag-and-drop feature.
DESCRIPTION OF THE PREFERRED EMBODIMENT
Reference will now be made in detail to the present preferred embodiment of
the invention, an example of which is illustrated in the accompanying
drawings. Where appropriate, the same reference numerals refer to the same
or similar elements. While the appended claims define the scope of the
invention, the following description does not limit that scope.
System Architecture
FIG. 2 shows a communications network containing mobile telephone 210
preferably having the multitasking graphical user interface of the present
invention. A user communicates with a: variety of communication equipment,
including external servers and databases, such as network services
provider 220, using mobile telephone 210.
The user also uses mobile telephone 210 to communicate with callers having
different types of communication equipment, such as ordinary telephone
230, caller mobile telephone 240, similar to user mobile telephone 210,
facsimile equipment 250, computer 260, and Analog Display Services
Interface (ADSI) telephone 270. The user communicates with
network-services provider 220 and caller communication equipment 230
through 270 over a communications network, such as GSM switching fabric
280. FIG. 2 shows caller communication equipment 230 through 270 directly
connected to GSM switching fabric 280. Although FIG. 2 shows caller
communication equipment 230 through 270 directly connected to GSM
switching fabric 280, more typically, this equipment connects to GSM
switching fabric 280 via another type of network, such as a Public
Switched Telephone Network (PSTN).
The user communicates with a caller or network services provider 220 by
establishing either a voice call, a data call, or by sending an SMS
message. GSM networks provide an error-free, guaranteed delivery transport
mechanism by which callers can send short point-to-point messages, i.e.,
SMS messages, through the GSM network, such as GSM switching fabric 280,
in a GSM signaling channel, simultaneously with, or without, a voice or
data call. GSM protocol limits the length of the short messages to a
maximum of 140 bytes in length. GSM protocol limits the length of the
standard SMS text message to a maximum of 140 bytes. However, GSM protocol
permits longer messages to be formed by concatenating several messages
together, transparent to the caller. Because GSM protocol performs
concatenation transparently, the caller is not subject to any restriction
on message length.
GSM telephone networks can transfer data as CLID information and USSD. One
example of such network is the GSM network, which facilitates the transfer
of custom defined data. The switches handling the call, however, require
an application program, consistent with the standard industry practice,
capable of recognizing the USSD data structure to complete the transfer of
data from one device to another device.
Mobile telephone 210 provides a user-friendly interface to facilitate
incoming and outgoing communication by the user. FIG. 3 shows that mobile
telephone 210 includes main housing 310, antenna 320, keypad 330, and
display 340.
FIG. 4 shows the hardware elements in mobile telephone 210 include antenna
410, communications module 420, feature processor 430, memory 440, sliding
keypad 450, analog controller 460, display module 470, battery pack 480,
and switching power supply 490.
Antenna 410 transmits and receives radio frequency information for mobile
telephone 210. Antenna 410 preferably comprises a planar inverted F
antenna (PIFA)-type or a short stub (2 to 4 cm) custom helix antenna.
Antenna 410 communicates over GSM switching fabric 280 using a
conventional voice B-channel, data B-channel, or GSM signaling channel
connection.
Communications module 420 connects to antenna 410 and provides the GSM
radio, baseband, and audio functionality for mobile telephone 210.
Communications module 420 includes GSM radio 421, VEGA 423, BOCK 425, and
audio transducers 427.
GSM radio 421 converts the radio frequency information to/from the antenna
into analog baseband information for presentation to VEGA 423. VEGA 423 is
preferably a Texas Instruments VEGA device, containing analog-to-digital
(A/D)/digital-to-analog (D/A) conversion units 424. VEGA 423 converts the
analog baseband information from GSM radio 421 to digital information for
presentation to BOCK 425.
BOCK 425 is preferably a Texas Instruments BOCK device containing a
conventional ARM microprocessor and a conventional LEAD DSP device. BOCK
425 performs GSM baseband processing for generating digital audio signals
and supporting GSM protocols. BOCK 425 supplies the digital audio signals
to VEGA 423 for digital-to-analog conversion. VEGA 423 applies the analog
audio signals to audio transducers 427. Audio transducers 427 include
speaker 428 and microphone 429 to facilitate audio communication by the
user.
Feature processor 430 provides graphical user interface features and a Java
Virtual Machine (JVM). Feature processor 430 communicates with BOCK 425
using high level messaging over an asynchronous (UART) data link. Feature
processor 430 contains additional system circuitry, such as a liquid
crystal display (LCD) controller, timers, UART and bus interfaces, and
real time clock and system clock generators (not shown).
Memory 440 stores data and program code used by feature processor 430.
Memory 440 includes static RAM 442 and flash ROM 444. Static RAM 442 is a
volatile memory that stores data and other information used by feature
processor 430. Flash ROM 444, on the other hand, is a non-volatile memory
that stores the program code executed by feature processor 430.
Sliding keypad 450 enables the user to dial a telephone number, access
remote databases, and manipulate the graphical user interface features.
Sliding keypad 450 preferably includes a mylar resistive key matrix that
generates analog resistive voltage in response to actions by the user.
Sliding keypad 450 preferably connects to main housing 310 (FIG. 4) of
mobile telephone 210 through two mechanical "push pin"-type contacts.
Analog controller 460 is preferably a Phillips UCB 1100 device that acts as
an interface between feature processor 430 and sliding keypad 450. Analog
controller 460 converts the analog resistive voltage from sliding keypad
450 to digital signals for presentation to feature processor 430.
Display module 470 is preferably a 160 by 320 pixel LCD with an analog
touch screen overlay and an electroluminescent backlight. Display module
470 operates in conjunction with feature processor 430 to display the
graphical user interface features.
Battery pack 480 is preferably a single lithium-ion battery with active
protection circuitry. Switching power supply 490 ensures highly efficient
use of the lithium-ion battery power by converting the voltage of the
lithium-ion battery into stable voltages used by the other hardware
elements of mobile telephone 210.
FIG. 5 is a block diagram illustrating the components of memory 440. Static
RAM 442 contains a database 510 storing various types of data including a
table representing a telephone directory.
Flash ROM 444 contains various programs including a program 520, a dialpad
program 525, a handwriting recognition program 530, an icon edit program
535, and a call object program 540. Program 520, preferably written in
languages such as Java, C, or C++ for Macintosh, is a main program
overseeing the operation of mobile telephone 210.
Dialpad program 525 facilitates data entry using keypad 330 using a typical
keypad algorithm. Handwriting recognition program 530 recognizes and
translates handwriting input from display 340. Icon edit program 535
facilitates graphical input as bitmaps. Programs 525, 530, and 535 may be
one of any commercially available packages. Finally, call object program
540 may be a user-defined special feature program or a macro for
telephony.
Currently, CLID information is stored in a telephone network and delivered
to the receiver's device. Mobile telephone 210, consistent with the
present invention, stores and interacts with highly descriptive
information in database 510 of FIG. 5. Alternatively, all or part of the
descriptive information may be stored at an external device or a central
server.
Table 600 of FIG. 6 is a table illustrating the format of the information
stored. Each row represents a single entry and each column within a row
represents a field of the entry. In one embodiment of the present
invention, table 600 contains many fields including fields for the name of
the person, title of the person, name of the organization, communication
addresses or numbers (e.g., multiple telephone numbers, faxnumber, e-mail
address) as well as their associated icon, and a field for user-defined
text. For exemplary purposes, features of the present invention may be
explained using a telephone number. However, telephone number is used
hereinafter to refer to any communication address or number. Program 520
displays each entry containing the fields in FIG. 6 in the form of a
business card (hereinafter referred as Electronic Business Card or EBC).
EBCs, including location icons, may be formatted as USSD (Unstructured
Supplementary Service Data) and may be transmitted among users in the GSM
network.
FIG. 7 shows a flowchart for creating a new EBC, and FIGS. 8A-8D show
sample screens. First, a user selects a "Name List" icon in screen 810
(step 700), which in turn displays an action menu 811 as shown in FIG. 8A
(step 705). A display driver oversees the display in display 340. If the
user selects a "Create card" option (step 710), program 520 presents
screen 820 from which the user may enter the data for the new EBC (step
715).
The present invention facilitates many modes of data entry. For example,
the user may enter the data using keypad 330, in which case dialpad
program 525 interprets the input data. Alternatively, the user may input
data by touching an on-screen keyboard 822. Also, the user may enter data
by writing on display 340, which is then interpreted by handwriting
recognition program 530. Voice command is another mode of data entry
facilitated by state-of-the-art voice recognition technology.
Screen 820 (FIG. 8B) shows a blank EBC as it first appears. To assist the
user, the blank EBC preferably contains watermark headings for each field.
If display 340 cannot display the full screen, program 520 displays scroll
buttons 821 and 831 for the user to scroll the display up or down by
simply touching. scroll buttons 821 and 831. Alternatively, the user may
scroll using the hard keys on keypad 330. In screen 820, the user is in
the process of entering the name "Bobby Bon" (step 720).
Screen 830 (FIG. 8C) is the bottom portion of the blank EBC displaying
additional user-defined text at the bottom. If the user selects an icon
selection button 832, program 520 displays a screen 840 (FIG. 8D) with an
icon menu 841 containing several predesigned icons for various
communication devices and locations, for example, home, cellular,
business, facsimile, e-mail, or others. In an embodiment consistent with
the present invention, the icons. preferably represent some characteristic
of the associated telephone number.
FIG. 9 is a table 900 illustrating certain exemplary icons. Row 910 of
table 900 shows exemplary icons representing the location or type of
communication terminal of the telephone number, e.g., home, office,
cellular, or car/mobile. Next, row 920 shows exemplary icons representing
the type of communication channel, e.g., e-mail, fax, SMS, or paging.
Finally, row 930 shows exemplary custom icons, e.g., special person or
group, corporate/business identifiers, or special service.
As illustrated, icons may present a certain group of people. Custom icons
may also represent specialized services or pre-programmed macros. For
example, a macro may perform all steps necessary to set up a conference
call to a predetermined group of people. One skilled in the art may,
however, easily modify the number and the type of icons shown in icon menu
841 and table 900.
The user also has an option of creating a new icon or modifying an existing
one under "Others" option of icon menu 841. If the user selects the
"Other" option, program 520 initiates icon edit program 535, which opens
an icon editing screen 1010 shown in FIG. 10. Icon editing screen 1010
contains an eraser button 1011 and a draw button 1012 to create or edit an
icon.
In the example icon editing screen 1010, a user has selected to edit an
existing home icon. Icon edit program 535 displays the actual size icon in
an icon view button 1013 as it would appear in the name list. Icon edit
program 535 also provides an enlarged view of the icon in an icon bitmap
view 1014. The user may erase or draw in the bits of the icon using eraser
button 1011 and draw button 1012.
Alternatively, rather than using erasure button 1011 or draw button 1012, a
user may turn on or off each bit of the icon simply by touching each block
of icon shown in icon editing screen 1010. In this embodiment, a user may
utilize erasure button 1011 and draw button 1012 to erase or draw a large
section of the icon.
When the user finishes modifying the icons, the user may select a "Save"
icon 1015 to save the modifications. Icon edit program 535 then stores the
updated icon in the corresponding icon field of table 600. Program 520
also facilitates the user to add the new icon in icon menu 841 upon user
selection. The user may also select to display the new icon in icon
selection button 832 associated with a corresponding phone number.
FIGS. 11A and 11B show exemplary screens 1110 and 1120, respectively,
displaying a completed EBC. In one embodiment consistent with the present
invention, the EBC may be stored in memory 440 of mobile telephone 210 or
at a central location (step 725). The central location may be a server,
which may be connected to a telephone network or a data network.
A user can also create a new EBC using the CLID information transmitted
over a telephone network, such as the GSM network. Specifically, if the
user's device receives and displays the CLID information, i.e., the phone
number of the caller, the user can create a new EBC by transferring the
CLID information to the new EBC.
Referring to FIG. 12A, screen 1210 is an exemplary display, consistent with
the present invention, of when the user receives a call from a caller.
CLID information, "Bobby Bonito" and "738-9157," appears in the name and
number fields, respectively. The user, while on the phone with the caller,
may select an information icon 1211 to display the EBC associated with the
caller. Upon selection, program 520 searches either the name or telephone
field of stored EBCs to locate the match. If program 520 finds a match,
program 520 displays the corresponding EBC.
If, however, there is no match, screen 1220 (FIG. 12B) presents an option
to create a new EBC corresponding to the caller as shown in screen 1220.
If the user selects not to create a new EBC, program 520 displays screen
1210 again for the remainder of the call. If the user chooses to create a
new EBC for the caller, program 520 presents a blank EBC and automatically
transfers the name and telephone numbers included in the CLID to the
corresponding fields in the EBC.
For example, screen 1230 (FIG. 12C) illustrates that the caller's name
"Bobby Bonito" and telephone number with the appropriate area code is
transferred to the appropriate fields of the new EBC. The telephone number
is identified as a home number by the associated home icon in the CLID
information. Accordingly, program 520 also assigns a home icon with the
caller's number. The user may input the remaining information through any
input method described above. Thereafter, program 520 stores the EBC as a
new entry in table 600.
A new EBC may be created using information manually entered by the user to
initiate a call. After the user has manually entered the telephone number
of the recipient, the user may select the "Create card" option of action
menu 811 before initiating the call, during the call, or after the
completion of the call. After selecting the "Create card" option, the user
may enter other fields for that entry to be stored in table 600.
Once the EBCs have been created and stored, program 520 can present the
EBCs to the user as a directory. A user can specify the fields of the EBC
to be displayed in the directory by modifying program 520. In an exemplary
display shown in FIG. 113A, screen 1310 displays the EBCs as a name list
with corresponding telephone numbers.
Referring to FIG. 14, which is a flowchart of a process for implementing a
scrolling feature, a user may view or search the name list by scrolling
using screen-based graphical scroll keys or the hard scroll keys on keypad
330. A tap on the scroll key (step 1400) advances the display of the name
list incrementally, providing the full name list view in display 340 (step
1405). One skilled in the art may easily vary the amount of advancement in
the display. For example, program 520 may advance to the next telephone
number with a tap on the scroll key. If the bottom line of display 340 is
the last of several telephone numbers associated with a particular name,
then program 520 may advance the display to the first telephone number of
the next name.
From the full view of the name list, a user may activate a call. To do so,
the user simply touches the name or telephone field of the desired entry,
which in turn causes program 520 to display the corresponding name and
first telephone number with the associated icon in a call object 1311.
Program 520 also displays associated information icon 1211 (FIG. 12A) in
call object 1311 (FIG. 13A).
Information icon 1211, displayed in call object 1311 or within the name
list, may be selected to instantly display the EBC associated with the
selected information icon 1211 as shown in screen 1320 of FIG. 13B.
To select another one of the several telephone numbers associated with the
selected name, a user touches the desired telephone number. Program 520
then displays the selected telephone number in call object 1311. Call
object 1311 is in a ready-mode, able to activate the associated object
upon user selection. In one embodiment, call object 1311 activates call
object program 540, which automatically initiates a call to the telephone
number in call object 1311. If the user selects either the name or the
telephone number field in call object 1311, program 520 activates call
object program 540 to initiate a call.
If the scroll key is pressed and held for a continuous scroll (step 1410),
program 520 displays a compressed view of the name list in display 340
(step 1415). In one embodiment of the present invention, the compressed
view displays only the name field of the name list as shown in screen 1510
of FIG. 15A. One skilled in the art may, however, easily modify the fields
to be displayed in the compressed view of the name list.
As shown in screen 1510, during the scroll, program 520 displays the first
entry in display 340 in a call object 1311. The user may stop scrolling by
releasing the scroll key. Upon release (step 1420), program 520
automatically displays a full view of the entries from the compressed view
as shown in screen 1520 of FIG. 15B (step 1425).
As mentioned above, a user may initiate a call to the telephone number in
call object 1311 by selecting a "Dial" button 1521. If the user wants to
select another entry for call object 1311, the user simply selects the
name or telephone field of the desired entry from display 340 and program
520 displays the selected entry in call object 1311. Although the
automatic compression and expansion feature is described in a telephony
setting using mobile telephone 210 for explanatory purposes, one skilled
in the art may easily apply this feature in any program or platform.
From the directory, a user may navigate easily between the name list view
and the EBC view. From the name list, if the user selects information icon
1211, program 520 displays the EBC view of the entry associated with the
selected information icon 1211. The EBC view floats in its own window over
top of any existing displays. The user may return to the name list view by
selecting a "Close" icon 1321.
While screen 1310 is displayed, a user may edit the entries of the
directory using any one of the input methods discussed above. If the user
selects information icon 1211, program 520 displays the EBC in full view.
At this point, the user may add or edit any field of the EBC. The EBC
floats on top of any currently running application and does not require
the user to exit current application to launch a separate application to
edit the EBC. Program 520 updates the stored EBC with the edits in the
corresponding fields in table 600.
A user may also locate a particular entry of the name list without
scrolling through each entry. Specifically, the user inputs a search text,
for example, a specific name or keyword, and program 520 searches the
fields of EBCs in table 600. The present invention employs an incremental
search algorithm to make the search easier for the user. For example, if
user enters the letter "M" of "Mike," program 520 will display the portion
of the directory with names starting with the letter "M." A particular
icon may also be used as a search criteria. Once program 520 locates the
desired EBC, it displays the portion of the name list corresponding to the
located entry.
As previously mentioned, CLID information is stored at a telephone network
and includes names and telephone numbers. Referring to FIG. 16, in one
embodiment consistent with the present invention, the telephone network
may also store icons associated with the telephone numbers (step 1600). In
one implementation consistent with the present invention, telephone
networks may receive location icons from individual subscribers and store
the icons with the associated telephone numbers. For a private telephone
switch, there may be a uniform location icon for all telephone numbers
within the private switch. One example is a large corporation having a
private switch and associating all telephone numbers of the corporation
with a corporate location icon.
When a call is initiated (step 1605), the telephone network transmits the
CLID information (step 1610). Shortly thereafter, the telephone network
also transmits any USSD, such as a location icon (step 1615).
Once a call is transmitted to the receiver's mobile telephone 210, program
520 searches table 600 for an entry corresponding to the telephone number
included in the CLID (step 1620). If there is a match (step 1625), then
program 520 displays the CLID information with the icon associated with
the transmitted telephone number from table 600 (step 1630).
If there is no match in table 600 (step 1625), then program 520 displays
the CLID information with the transmitted icon in display 340 (step 1635).
As described above in connection with FIGS. 12A-12C, program 520 presents
an option to create an EBC using the transmitted CLID information and the
associated icon (step 1640).
The location icon provides visual assistance to the receiver in quickly
determining the location or the type of device of the caller.
Additionally, if the caller's device can display graphical images, the
telephone network transmits the recipient's CLID information including the
associated icon. There are efforts to develop standards and designing
systems for capturing and transmitting GPS (Global Positioning System)
protocol. The present invention is well suited to incorporate such a
feature. For example, the user may be presented with more precise GPS
information about the caller's location by touching the location icon.
USSD is transmitted with a call from a caller or a non-ringing call from
the switch over the telephone network. A non-ringing call from the switch
occurs when the user's device is turned on and communication takes place
between the telephone network and the device for standard maintenance
transactions such as determining the location of the device or updating
the program on the user's device for a subscriber feature. The transmitted
information may be sent as a data packet of approximately 140 bytes. There
are typically two possible times for transmitting USSD with respect to the
timing of a call. It may be transmitted either shortly after the CLID
information transfer but before user pick up, or after the completion of
the call. USSD may be transmitted, however, at other times.
The user can also send and receive an EBC to another user over the GSM
network. The transmitted EBC may contain the data shown in table 600. The
EBC may be transmitted as an SMS text message in a similar environment as
described above in connection with CLID and associated icons.
Alternatively, EBCs may be stored at a central server accessible by any
third party from which third party users may download the EBCs. The EBCs
stored at the central server might be voluntarily submitted by users
wanting to provide public access to their BC.
To send an EBC to another user, the user selects the "Send Card" option of
action menu 811 in FIG. 8. Upon the user's selection. program 520 prompts
the user to input the name and phone number of the recipient as well as
the name field of the EBC to be sent.
An exemplary display 1710 of FIG. 17A illustrates the user sending an EBC
of "Arlan Anderson" to "Bobby Bonito." Upon verifying this information,
the user activates the transmission by selecting a "Send" icon 1721 of
screen 1720 of FIG. 17B. The user may also abort the send option by
selecting a "Quit" icon 1722. Alternatively, the user may send an EBC
while the user is engaged in a voice call with the recipient or a third
party.
The user can also receive an EBC from another user regardless of whether
the user is engaged in a voice call. When mobile telephone 210 receives an
EBC, program 520 displays the source of the EBC and the EBC itself as
shown in screen 11810 of FIG. 18A. In this sample display, "Colin Smith"
is engaged in a voice call with the user. "Colin Smith" has also sent an
EBC of "Bobby Bonito" to the user, who has an option to select any one of
"Save" icon 1811, "Discard" icon 1812, or "Quit" icon 1813.
If the user selects "Save" icon 1811, program 520 automatically
incorporates the fields of the received EBC into the corresponding fields
of a new EBC in table 600. For example, "Bobby Bonito" is automatically
saved in the name field of the new EBC. After program 520 s | | |
