`
`US 20020163504A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. N0.: US 2002/0163504 A1
`Pallakolf
`(43) Pub. Date:
`NOV. 7, 2002
`
`(54) HAND-HELD DEVICE THAT SUPPORTS
`FAST TEXT TYPING
`
`(76) Inventor: Matthew G. Pallako?', Mountain View,
`CA (US)
`
`gcgig$cgigéevsggrgssé FREIDENRICH LLP
`1755 EMB ARC ADERO ROAD
`PALO ALTO’ CA 9430363 40 (Us)
`
`(21) APPL NO:
`
`10/107,903
`
`(22) Filed;
`
`Man 11, 2002
`
`Related US, Application Data
`
`(60) Provisional application No. 60/275,572, ?led on Mar.
`13, 2001.
`
`Publication Classi?cation
`
`.... .. G09G 5/00
`(51) Int. c1.7 .
`(52) US. Cl. ............................................................ .. 345/169
`
`ABSTRACT
`(57)
`The invention comprises a hand-held device With multiple
`keys on its face (“face-keys”) and With one or more buttons
`on its side (“side-buttons”). A user types a character (or
`invokes a function) by pressing one of the face-keys using
`a ?nger on the hand that is not holding the device While
`simultaneously holding in combinations of the side-buttons
`With ?ngers on the hand that is holding the device. Pressing
`a face-key Without holding in any of the side-keys produces
`a given character (or function). Pressing the same face-key
`While simultaneously holding in a given combination of the
`side-keys can result in a different character (or function).
`The invention alloWs for faster typing of teXt on cell phone
`handsets and other hand-held devices.
`
`"Web-phone" handset that enables fast typing,
`and fast application navigation
`
`“f @f“
`
`308 \
`
`3
`2
`1
`¥_/p_);_
`T. Tm 3rd f“
`4
`5
`6 Letter
`
`prs
`
`tuv m
`
`SCEA Ex. 1008 Page 1
`
`
`
`Patent Application Publication
`
`Nov. 7, 2002 Sheet 1 0f 4
`
`US 2002/0163504 A1
`
`Figure 1 -- Phone handset that enabtes fast typing
`
`100
`
`\
`
`Are we still on for Tuesday?
`
`108 \
`
`I110
`@ Shift
`I104
`‘ @
`2nd
`e (d a?
`Letter
`
`j
`
`1
`k
`W iif. \/
`a
`0
`mn
`
`3rd
`Letter
`
`L
`
`6
`
`k
`( wxy
`9
`L J
`
`SCEA Ex. 1008 Page 2
`
`
`
`Patent Application Publication
`
`Nov. 7, 2002 Sheet 2 0f 4
`
`US 2002/0163504 A1
`
`Figure 2 -- Phone handset that enables fast typing
`
`200
`
`\f
`
`I205 I}
`
`Are we still on for Tuesday?
`
`208 1 211 f
`
`ghi rjklwfmno\ 3rd
`4
`5
`6 Letter
`
`J
`
`7
`
`8
`
`9 Num
`
`SCEA Ex. 1008 Page 3
`
`
`
`Patent Application Publication
`
`Nov. 7, 2002 Sheet 3 0f 4
`
`US 2002/0163504 A1
`
`Figure 3 -- "Web-phone" handset that enables fast typing,
`and fast application navigation
`
`300 \ f
`
`305 \
`
`(D @1167
`
`Are we stilt on for Tuesday?
`
`a
`
`o
`
`2nd
`
`302
`
`309K
`I31 0
`301
`t@ @ f
`\ f
`I 304
`311
`@
`312lf§f£k$& (a b? rd ef\Le?er] /
`1
`2
`3
`fghiw rikij fmno\ 3161f
`4
`5
`6 Letter
`\ J! JL J
`( \f if i
`prs
`X
`7
`e
`9 \\
`
`p J p
`
`303
`
`y J p J \
`
`J
`
`314
`
`313lfshpice ‘v f
`
`_\ f ' ? x
`
`@Tab bzQ
`
`y J \
`J
`Select D {Tab Q \
`\
`:::f315 j 316
`
`SCEA Ex. 1008 Page 4
`
`
`
`Patent Application Publication
`
`Nov. 7, 2002 Sheet 4 0f 4
`
`US 2002/0163504 A1
`
`Figure 4 -- "Web-phone“ handset that enables fast typing,
`and fast application navigation
`
`1K
`
`[405 \
`
`Are we still on for Tuesday?
`
`4°“
`
`I410
`401
`[5 @ f
`
`(gab
`
`) (Tab 4) j
`
`1:: X415
`
`\ 416
`
`417
`
`SCEA Ex. 1008 Page 5
`
`
`
`US 2002/0163504 A1
`
`Nov. 7, 2002
`
`HAND-HELD DEVICE THAT SUPPORTS FAST
`TEXT TYPING
`
`BACKGROUND OF THE INVENTION
`
`[0001] The invention generally relates to a hand-held
`electronic device. More speci?cally, the invention relates to
`a device that alloWs a person to type teXt quickly on
`hand-held electronic devices.
`
`[0002] Typing on most cell phone handsets (and other
`hand-held devices) is sloW and aWkWard. Yet the need to
`type teXt using hand-held devices is groWing quickly, thanks
`largely to the emergence of Wireless data services (such as
`GoAmerica and OmniSky in the United States, and NTT
`DoCoMo in Japan), the proliferation of “Internet-enabled”
`cell phone handsets and personal digital assistants (PDAs),
`and the groWing popularity of mobile Internet-based ser
`vices such as email, instant messaging, and Web-broWsing.
`
`[0003] Most cell phone handsets include a “Start call”
`button and an “End call” button. As With all other buttons
`described in this patent, the precise names, symbols or
`graphics on the buttons are for illustrative purposes and can
`vary Without departing from the spirit or scope of the
`invention. When a user presses the “Start call” button, the
`cell phone handset behaves like any other phone: Pressing
`the face-keys With the numbers 0 through 9, “*” and “#”,
`generates the appropriate tones and dials the phone number.
`When ?nished With the call, the user Will press the “End
`call” button or perhaps just turn the phone off using an on/off
`button.
`
`[0004] HoWever, many modern mobile devices alloW
`users to do more than place phone calls: Many modern cell
`phone handsets (and other hand-held devices) alloW users to
`enter and vieW personal information management data, such
`as addresses, check and ansWer email, send instant mes
`sages, or even broWse the Web —among a groWing list of
`features. When using these features, users Will often ?nd
`themselves in a conteXt that calls for typing teXt.
`
`[0005] SiZe is a key constraint in the design of hand-held
`devices, especially cell phone handsets. In general, the goal
`is to keep the device small. But current handset designs have
`not been very successful in facilitating teXt typing Within the
`constraints of a small form-factor. For eXample, on today’s
`cell phone handsets the alphabet is represented across the
`number keys. In most case, A, B and C are on the key labeled
`2, D, E and F are on the 3 key, and so on. Many phones leave
`out Q and Z. Others put “PQRS” on the 7 key and “WXYZ”
`on the 9 key. Users type by pressing the number keys. On
`most cell phones today, to type the Word “Baby” a user
`Would type the 2 key tWice quickly (because “B” is the
`second letter on the 2 key), pause for a second so as not to
`type the letter “C”, type the 2 key once (because the letter
`“A”is the ?rst letter on the 2 key), pause for a second so as
`not to type the letter “B”, type the 2 key tWice again (for the
`second “b” in Baby), then type the 9 key three times
`(because the letter “Y” is the third letter on the 9 key).
`
`[0006] In another but still sloW con?guration, the phone
`may be programmed to automatically capitaliZe the ?rst
`letter in a sentence and leave the others loWercase. Or the
`user may be able to determine capitaliZation by typing keys
`even more times: For eXample, typing the 2 key once may
`result in a loWercase “a”, tWice results in a loWercase “b”,
`
`three times results in a loWercase “c”, four times results in
`an uppercase “A”, ?ve times results in an uppercase “B”, siX
`times in an uppercase “C”—and perhaps seven times results
`in a “2” (the number associated With that key). Further
`typing on that key Will typically loop around and start over
`on loWercase letter “a”. This is also prone to error. For
`eXample, to type a given letter tWice, the user must type the
`letter once, pause (so the hand-set knoWs the user isn’t just
`cycling past that letter on the key being pressed) and then
`type that letter again. For eXample, to type the letter “I”
`tWice (for eXample, When typing the Word “hello”), the user
`Would press the 5 key three times (since “I” is the third letter
`on that key), pause, and then press the 5 key three more
`times (to type the second “I”). Pressing the 5 key siX times
`(Without pausing) Would type the capital letter “L” once on
`a typical current handset, rather than typing the loWercase
`letter “I” tWice.
`
`[0007] Some phones and phone-accessible applications
`(such as E*Trade’s phone-based stock-trading service) use a
`different, equally aWkWard typing scheme: Auser Who Wants
`to type the letter J Would type the number key 5 (Which has
`the letters J K and L) folloWed by the number 1 (because J
`is the ?rst letter on that key). To type the letter K, a user
`Would type the 5 key folloWed by the number 2 (because K
`is the second letter on the 5 key). And to type the letter L,
`the user Would type the 5 key folloWed by the number 3
`(because L is the third letter on the 5 key).
`
`[0008] Typing With either of the schemes outlined above is
`aWkWard and sloW. Also, the system must either guess the
`capitaliZation of each letter (e.g. capitaliZe the ?rst letter of
`the ?rst Word in each sentence, make the rest loWercase), or
`require the user to use additional keystrokes to convert a
`given letter into an upper case letter. Both schemes make it
`nearly impossible for a person to develop the sort of hand
`eye, mind-eye, and muscle coordination that alloW for fast
`typing.
`[0009] Other telephone handset typing schemes alloW
`users to type letters and numbers by holding multiple
`handset face-keys doWn simultaneously. US. Pat. No.
`6,184,803 and US. Pat. No. 6,043,761, both incorporated
`herein by reference, describe tWo examples. These schemes
`can alloW for quicker typing by letting users type each
`character With one event—simultaneously holding tWo face
`keys doWn. But they require considerable deXterity by the
`user. For eXample, typing the letter “C” can require that the
`user type the 2 key and the # key at the same time. Since
`many users Will ?nd this difficult to learn and use, these
`handset typing schemes also alloW a user to revert to
`sequential typing—e.g. typing the 2 key folloWed by the #
`key. The schemes covered in these tWo patents also require
`users to either type in all loWer case, all upper case, or in a
`mode that requires an additional keystroke to capitaliZe a
`letter. In other Words, typing miXed upper and loWer case
`letters requires the user to revert to a multi-keys-per-letter
`typing style—Which makes typing sloWer and more aWk
`Ward than it Would be if every key, upper and loWer case,
`could be typed With a single event.
`
`[0010] One softWare developer for mobile devices, Tegic
`Communications
`t9. com), has developed softWare
`for cell phones that uses dictionaries and algorithms to alloW
`people to type most Words by typing just one key per letter.
`With Tegic’s T9 Text Input softWare, if a user types the
`
`SCEA Ex. 1008 Page 6
`
`
`
`US 2002/0163504 A1
`
`Nov. 7, 2002
`
`sequence of cell phone handset keys imprinted With the
`letters “h-o-m-e” (Which are the keys 4-6-6-3 on most cell
`phone handsets today), then Tegic’s softWare identi?es all
`Words that could correspond to that key sequence (there
`could be more than once since each key corresponds to three
`letters), shoWs one of those Words, and alloWs the user to
`accept it or scroll through the alternatives if Tegic’s softWare
`chose the Wrong Word. As the user types a Word, the
`softWare shoWs a match for the keys typed so far. Since most
`of the keys contain three letters (such as A, B and C on the
`2 key; D, E, and F on the 3 key, etc.), a sequence of key
`presses can correspond to several different Words in Tegic’s
`SoftWare’s dictionaries.
`
`[0011] For example, suppose a user types “home”: When
`the user types the 4 key (corresponding to the letter “h”),
`Tegic’s softWare shoWs “i” (Which is also on the 4 key).
`When the user types the 6 key (corresponding to the second
`letter in the Word “home”, “o”) then Tegic’s softWare shoWs
`“in” (since “n” is also on the 6 key). When the user types the
`6 key again (corresponding to the third letter in “home”,
`“m”) then Tegic’s softWare shoWs “inn”. When the user
`types the key 3 (corresponding to the ?nal letter in the Word
`“home”, “e”) then Tegic’s softWare changes What it has
`shoWn so far from “inn” to “good”—the ?rst Word in its
`dictionaries that matches the keys pressed so far. Like the
`Word “home”, the Word “good” happens also to correspond
`to the keys 4-6-6-3 on most telephone handsets. Since
`“good” isn’t the Word the user Wanted to type (Which Was
`“home”), Tegic’s softWare alloWs users to scroll through
`other matches using an appropriate button on the cell phone
`(such as the 0 key at the bottom center on most handsets).
`When the user types this “next Word” button, Tegic’s soft
`Ware shoWs the next Word in its dictionary corresponding to
`the keys that Were hit. In this example, the next Word is
`likely to be “home”. So the user can hit the 0 key once to
`sWitch the Word “good” to the Word “home”. In this
`example, the user had to press ?ve keys to type the Word
`“home”: 4-6-6-3-0. In many cases, the ?rst Word presented
`by Tegic Will be the correct Word (because that Will be the
`?rst Word Tegic ?nds in its dictionary corresponding to the
`sequence of keys hit). In other cases, the user may have to
`hit the “next-Word” button several times to get to the right
`Word in the dictionary. In still other cases, the Word the user
`Wants to type Will not be in the dictionary at all. So Tegic’s
`softWare often alloWs users to type Words With feWer key
`strokes than the multi-key-presses-per-letter schemes out
`lined earlier. In many cases, the user can type one key per
`letter, and Tegic’s softWare Will come up With the correct
`Word. But Tegic’s approach has several draWbacks. First, if
`a Word is not in the dictionaries used by Tegic’s softWare
`(Which Will often be the case for proper nouns and acro
`nyms, such as company names for example), then the Word
`Will not be successfully typed by Tegic’s softWare—either as
`the ?rst choice presented or as any of the alternatives. In this
`case, the user has to revert to one of the multi-keys-per-letter
`schemes outlined earlier. Second, as a user is part Way
`through typing a Word, Tegic’s softWare Will often display a
`different partial Word than the one that has been typed. For
`example, as noted earlier, after typing the ?rst three keys for
`the Word “home”—the user Will see the characters “inn” on
`the display, instead of seeing “hom”. Similarly, after typing
`the ?rst three letters of the Word “meeting”, the user Will see
`“off” on the display. This can be confusing for users—
`especially since typing on today’s cell phone keypads is a
`
`fairly neW and sloW process for most users, so they need
`visual con?rmation of their progress. If a user looks up and
`sees “off” When they thought they Were half Way through
`typing the Word “meeting“, the typical reaction is to Want to
`use the backspace key to erase the apparent typo. (This is
`Why Tegic’s documentation instructs users to “ignore What’s
`on the screen until you’ve typed the Word completely”.) A
`third issue With Tegic’s softWare is that it uses dictionaries
`and lookup softWare, Which can consume precious memory
`and CPU time on loW-cost and loW-poWer mobile devices.
`A dictionary With 50,000 Words Would typically consume
`150-300 kilobytes of memory.
`
`[0012] Some neW hand-held device designs alloW users to
`type using their thumbs or index ?ngers on a tiny, so-called
`“Qwerty,” keyboard—tiny versions of the keyboards used
`With most desktop computers. An example of such a device
`With a tiny QWerty keyboard is seen in US. Pat. No.
`6,278,442 B1 incorporated herein by reference. But a
`QWerty keyboard on a cell phone looks strange to most cell
`phone consumers today—limiting the percentage of poten
`tial cell phone customers Who Would consider buying a cell
`phone With a QWerty keyboard. And even the smallest
`thumb-QWerty keyboards that most people can comfortably
`type are Wider than most cell phones sold today—so they
`require non-standard cell phone form-factors.
`
`[0013] Other hand-held devices use character recognition
`softWare to alloW users to draW letters on touch-pads using
`a stylus or a ?nger. While some of these input schemes are
`signi?cantly easier and faster to use than the multiple-key
`presses-per-letter cell phone typing schemes discussed ear
`lier, they are still signi?cantly sloWer to use than computer
`keyboards, at least for experienced typists.
`[0014] In short, there is a groWing need for neW cell phone
`handset designs (and, more generally, hand-held device
`designs) that alloW users to type text faster, While keeping
`the device small.
`
`SUMMARY OF INVENTION
`
`[0015] The most general form of the present invention is
`a hand-held device With multiple keys on its face (hereafter
`called “face-keys”) and With one or more buttons on its side
`(hereafter called “side-buttons” or “modi?er buttons”). A
`user types a character (or invokes a function) by pressing
`one of the face-keys using a ?nger on the hand that is not
`holding the device While simultaneously holding in combi
`nations of the side-buttons With ?ngers on the hand holding
`the device. Pressing a face-key Without holding in any of the
`side-keys types one character (or performs a function).
`Pressing the same face-key While simultaneously holding in
`a given combination of side-keys can type a different char
`acter (or perform a different function).
`[0016] The present invention alloWs users to type quickly
`on hand-held devices—particularly cell phone handsets.
`Many other types of devices can use this same input mecha
`nism including PDAs, hand-held computers, smart-phones,
`Web-phones, pagers, instant-messaging devices, input-de
`vices connected to ?eld equipment, and so on. The invention
`can be implemented on cell phone handsets While retaining
`traditional cell phone form-factors (as Well as non-standard
`form-factors). The invention is easy and intuitive for begin
`ners to learn and use—so they can immediately type fairly
`quickly. Further, the invention enables motivated users to
`
`SCEA Ex. 1008 Page 7
`
`
`
`US 2002/0163504 A1
`
`Nov. 7, 2002
`
`learn to type very quickly—by developing the sort of
`“mind-hand” coordination and muscle-memory that lets fast
`touch-typists type quickly on regular computer keyboards
`and lets check-out clerks operate 10-key number pads very
`quickly at supermarket checkout stands.
`
`DESCRIPTION OF PREFERRED
`EMBODIMENTS
`
`[0017] The ?rst preferred embodiment of the present
`invention adds three neW buttons to the side of a typical cell
`phone handset, as shoWn in FIG. 1. Although FIG. 1 is
`draWn shoWing a display, it is not necessary that there
`actually be a display, depending on the requirements of the
`hand-held device implementing my invention. For eXample,
`my invention could easily be implemented in a hand-held
`device that does not require a display. The three neW
`side-buttons seen in FIG. 1 are a “Shift” side-button 101, a
`“2nd Letter” side-button 102, and a “3rd Letter” side-button
`103. In contexts Where the phone is being used to type teXt,
`a user Would hold the handset depicted in FIG. 1 in the left
`hand and use that hand’s indeX, middle, and ring ?ngers to
`hold in combinations of the “Shift”, “2nd Letter”, and “3rd
`Letter” side-buttons, respectively, While simultaneously
`using the right hand to press keys on the face of the handset.
`
`[0018] If none of the side-buttons are held in, then press
`ing one of the face keys simply types the ?rst letter on that
`key. For eXample, pressing the “2” key on the handset in
`FIG. 1 results in a character Which is the loWercase letter “a”
`being typed in conteXts Where the phone is being used to
`type teXt. To type a character that is an uppercase version of
`the ?rst letter on a given face-key (such as the uppercase
`letter “A”), the user holds in the “Shift” side-button 101
`While pressing that face-key. So the “Shift” side-button 101
`behaves like it does on a regular computer keyboard, modi
`fying the behavior of other keys. The “Shift” and “Ctrl”
`keys, on many regular computer keyboards are sometimes
`called “modi?er”, keys. The side-buttons discussed in this
`invention description are modi?er buttons in that, When held
`in, they modify the behavior of the device’s face-keys. To
`type a loWercase version of the second letter on a given
`face-key (such as the letter “b” on the “2” key), the user
`holds in the “2nd Letter” side-button 102 While simulta
`neously pressing that face-key. To type an uppercase version
`of the 2nd letter on a given face-key (such as the uppercase
`letter “B”), the user holds in both the “Shift” side-button 101
`and the “2nd Letter” side-button 102 While pressing that
`face-key.
`
`[0019] To type a loWercase version of the 3rd letter on a
`given face-key (such as the letter “c” on the “2” key), the
`user holds in the “3rd Letter” side-button 103 While simul
`taneously pressing that face-key. To type an uppercase
`version of the 3rd letter on a given face-key (such as the
`uppercase letter “C”), the user holds in both the “Shift”
`side-button 101 and the “3rd Letter” side-button 103 While
`pressing that face-key. All references to letters and keys in
`this eXample refer to the sample layout illustrated in FIG. 1.
`Handsets can also be designed With letters positioned on
`different keys, as We Will see beloW When We discuss FIG.
`4.
`
`[0020] Some people may ?nd it slightly aWkWard to
`simultaneously press the Shift side-button and the “3rd
`Letter” side-button Without also pressing the “2nd Letter”
`
`side-button -betWeen them (see FIG. 1). So one preferred
`embodiment of a device (and the device’s softWare pro
`cesses and storage systems) could interpret simultaneous
`pressing of all three side buttons (“Shift”, “2nd Letter”, and
`“3rd Letter”) the same as simultaneous pressing of just the
`Shift and “3rd Letter” side-buttons. Or an embodiment could
`simply ignore the “2nd Letter” button When the “3rd Letter”
`button is being pressed.
`
`[0021] The entire alphabet, plus some common punctua
`tion, a space character, and backspace character (Which
`behaves like the backspace key on a computer keyboard)
`should appear on a handset made for typing. FIG. 1 shoWs
`an eXample. FIG. 2, 3, and 4 shoW other eXamples and are
`discussed in detail subsequently.
`
`[0022] Sometimes users need to type numbers While in a
`text-typing conteXt—for eXample, to enter a street address in
`their personal information management database. FIG. 1
`shoWs a handset With a “Num Lock” face-button 104. When
`the user presses the “Num Lock” button once then the phone
`enters a mode in Which the face-keys behave similarly to a
`the number keypad on many computer keyboards: When in
`the number-lock mode, pressing a given face-key simply
`types the main number or symbol on the face-keys (1, 2, 3,
`4, 5, 6, 7, 8, 9, 0, *, or #). This number lock mode can be
`indicated by an LED just beloW the “Num Lock” button,
`shoWn as a tiny circle on FIG. 1 beloW the “Num Lock”
`button 104. When the user presses the “Num Lock” face
`button 104 again, the phone eXits the number-lock mode and
`returns to the non-numeric typing mode described earlier,
`and the Num Lock LED light Would turn off.
`
`[0023] The softWare necessary to implement the foregoing
`embodiment can be easily Written by one of ordinary skill in
`the art from the foregoing teachings. An eXample of this
`folloWs. Each modi?er button and each face key of the
`device could be implemented as a simple sWitch. As is Well
`knoWn, a hardWare sWitch’s contact is either open or closed
`at any given time. When a user presses any given button or
`key (e.g. closes the corresponding sWitch’s contact), then
`?rmWare on the device sends a unique code corresponding
`to that button or key being pressed, such as a unique number
`or character, to a queue to be read by softWare running on the
`device. And When a user releases that button or key (e.g.
`opens the corresponding sWitch’s contact), then the ?rm
`Ware on the device sends a unique code corresponding to
`that button or key being released to the queue. When a user
`presses a key a single time, the sWitch’s contact often brie?y
`closes and opens multiple times—i.e. it “bounces”. This can
`also happen When the user releases the key. So ?rmWare
`developers commonly develop ?rmWare that “debounces”
`key presses and releases. The ?rmWare tracks Whether
`multiple contacts are made in a very short period of time—
`such as 1/50th of a second (or some other brief period) and, if
`so, treats them as a single press or release (depending on
`What state the sWitch Was in and What state it Winds up in.
`
`[0024] SoftWare on the device continuously looks for neW
`codes to appear in the queue mentioned above—codes
`supplied by the ?rmWare. The softWare reads those codes
`and proceeds to interpret them as typing. This interpretation
`softWare could also be implemented as part of the device’s
`“?rmWare,” or it could be Written to run on a processor that
`also runs a high level operating system such as Pocket PC or
`LinuX. The pseudo code beloW describes one softWare
`
`SCEA Ex. 1008 Page 8
`
`
`
`US 2002/0163504 A1
`
`Nov. 7, 2002
`
`procedure for interpreting the codes generated When the user
`operates buttons and keys on a device like the one shoWn in
`FIG. 1.
`
`[0025] // Codes that ?rmware sends to queue as device
`keys and buttons are pressed
`
`[0026] // Codes corresponding to Modi?er buttons in
`FIG. 1 phone illustration
`
`[0027] #de?ne kShiftDoWn=1; // shift modi?er button
`pressed
`[0028] #de?ne kShiftUp=2; // shift modi?er button
`released
`
`[0029] #de?ne k2ndLetterDoWn=3; // 2Dd letter button
`pressed
`[0030] #de?ne k2ndLetterUp=4; // 3rd letter button
`released
`
`[0031] #de?ne k3rdLetterDoWn=5; // 3rd letter button
`pressed
`[0032] #de?ne k3rdLetterUp=6; // 3rd letter button
`released
`
`[0033] // Codes corresponding to 12-keys in FIG. 1
`phone illustration
`
`[0034] // Note that the DoWn codes are even and the Up
`codes are odd in this eXample
`[0035] #de?ne k1KeyDoWn=10; // 1 key pressed
`[0036] #de?ne k1KeyUp=11; // 1 key released
`[0037] #de?ne k2KeyDoWn=12; // 2 key pressed
`[0038] #de?ne k2KeyUp=13; // 2 key released
`[0039] #de?ne k3KeyDoWn=14; // 3 key pressed
`[0040] #de?ne k3KeyUp=15; // 3 key released
`[0041] #de?ne k4KeyDoWn=16; // 4 key pressed
`[0042] #de?ne k4KeyUp=17; // 4 key released
`[0043] #de?ne k5KeyDoWn=18; // 5 key pressed
`[0044] #de?ne k5KeyUp=19; // 5 key released
`[0045] #de?ne k6KeyDoWn=20; // 6 key pressed
`[0046] #de?ne k6KeyUp=21; // 6 key released
`[0047] #de?ne k7KeyDoWn=22; // 7 key pressed
`[0048] #de?ne k7KeyUp=23; // 7 key released
`[0049] #de?ne k8KeyDoWn=24; // 8 key pressed
`[0050] #de?ne k8KeyUp=25; // 8 key released
`[0051] #de?ne k9KeyDoWn=26; // 9 key pressed
`[0052] #de?ne k9KeyUp=27; // 9 key released
`[0053] #de?ne kStarKeyDoWn=28; // * key pressed
`[0054] #de?ne kStarKeyUp=29; // * key released
`[0055] #de?ne k0KeyDoWn=30; // 0 key pressed
`[0056] #de?ne k0KeyUp=31; // 0 key released
`[0057] #de?ne kPoundKeyDoWn=32; // # key pressed
`[0058] #de?ne kPoundKeyUp=33; // # key released
`
`[0059] #de?ne kMinTypingKey=k1KeyDoWn;
`[0060] #de?ne kMaXTypingKey=kPoundKeyUp;
`[0061] #de?ne kNumLockDoWn=40; // Num Lock key
`pressed
`[0062] #de?ne kNumLockUp=41; // Num Lock key
`pressed
`[0063] // Assume that there is a queue—such as a serial
`port queue—Where
`[0064] // the ?rmware Writes one of the above codes
`Whenever a user presses or releases
`
`[0065] // one of the modi?er buttons or face keys in the
`device shoWn in FIG. 1.
`
`[0066] IntegerQueue Q; // de?ne queue for the integer
`codes used in this pseudocode
`
`[0067] // in various contexts, the device should interpret
`key and button presses
`
`[0068] // as typing—for example, to let the user type
`email or instant messages
`
`[0069] int code=0;
`[0070] boolean gShift=false;
`[0071] boolean g2ndLetter=false;
`[0072] boolean g3rdLefter=false;
`[0073] boolean gNumLock=false;
`[0074] char charToType=null;
`[0075] While (in-typing-conteXt) {
`[0076] charToType=null;
`[0077] code=ReadFromQueue(Q); // fetch the neXt code
`from Queue
`[0078] // set shift, 2Dd letter, and 3rd letter variables
`according to most recent
`
`[0079] // press or release of corresponding modi?er
`button
`[0080] if (code==kShiftDoWn) gShift=true;
`[0081] else if (code==kShiftUp) gshift=false;
`[0082] else if (code==k2ndLetterDoWn) g2ndLetter=
`true;
`[0083] else if (code==k2ndLetterUp) g2ndLetter=false;
`[0084] else if (code==k3rdLetterDoWn) g3rdLetter=
`true;
`[0085] else if (code==k3rdLetterUp) g3rdLetter=false;
`[0086] // Toggle state of Num Lock variable Whenever
`the corresponding Num Lock
`[0087] // key is pressed. Ignore releases of that key.
`(Other embodiments could use
`
`[0088] // a separate Num modi?er button instead of a
`NumLock key.)
`
`[0089] else if (code==kNumLockDoWn) gNumLock=
`not gNumLock;
`
`SCEA Ex. 1008 Page 9
`
`
`
`US 2002/0163504 A1
`
`Nov. 7, 2002
`
`[0090] // If none of the modi?er buttons or Num Lock
`key Were pressed,
`
`[0091] // maybe it a face key Was typed that needs to be
`interpreted as
`
`[0092] // a character, accounting for the modi?ers and
`Num Lock state.
`
`[0093] // In this particular example, the 1 key is a little
`different than most of the
`
`[0094] // character keys, because the shift key is ignored
`for the 1 key...
`
`[0095] // else if (code==k1KeyDoWn) {// user pressed 1
`key
`
`[0096] if (gNumLock) charToType=“1”; // if Num
`Lock is doWn, We’ll type number
`
`[0097] else if (g3rdLetter) // else if 3Id letter modi?er
`button is being held
`
`[0098] charToType=“&”; // We’ll type 3rd character
`on the 1 key
`
`[0099] else if (g2ndLetter) // else if 2Dd letter modi?er
`button is being held
`
`[0100] charToType=“$”; // We’ll type 2Dd character
`on the 1 key
`
`[0101] else charToType=BackSpaceKey; // else We’ll
`type 1St character on 1 key
`
`[0102] v
`
`[0103] // Te 2 key is typical of most of the character
`
`keys .
`
`.
`
`.
`
`[0104] else if (code==k2KeyDoWn) {// user pressed 2
`key
`[0105] if (gNumLock) charToType=“2”; // if Num
`Lock is doWn, We’ll type number
`
`[0106] else if (g3rdLetter) {// else if 3Id letter modi
`?er button doWn
`
`[0107] if (gshift) charToType=“C”; // 3rd character
`on the 2 key, capitaliZed
`
`[0108] else charToType=“c”; // 3rd character on the
`2 key, not capitaliZed
`
`[0109] // Note: It’s ?ne to ignore the “2nd letter”
`modi?er button if the user
`
`[0110] // is holding the “3rd letter” modi?er button.
`That lets user type “C” by holding
`
`[0111] // “shift”, “2nd letter”, and “3rd letter” but
`tons simultaneously, While typing the
`
`[0112] // 2 key—Which is a little easier for some
`people than typing just the “shift”
`
`[0113] // and “3rd letter” buttons With the hand
`holding the phone.
`[0114] }
`
`[0115] else if (g2ndLetter) {// else if 2Dd letter modi
`?er button is doWn
`[0116] if (gshift) charToType=“B”; // 2Dd character
`on the 2 key, capitaliZed
`
`[0117] else charToType=“b”; // 2Dd character on the
`2 key, not capitaliZed
`[0118] }
`[0119] else {// else user is typing 1St letter on 2 key
`[0120] if (gshift) charToType=“A”; // 1St character
`on the 2 key, capitaliZed
`
`[0121] else charToType=“a”; // 1St character on the
`2 key, not capitaliZed
`[0122] }
`[0123] }
`[0124] // The 3 key is similar to the 2 key .
`
`.
`
`.
`
`[0125] else if (code==k3KeyDoWn){// user pressed 3
`key
`[0126] if (gNumLock) charToType=“3”; // if Num
`Lock is doWn, We’ll type number
`[0127] else if (g3rdLetter) { // else if 3rd letter
`modi?er button doWn
`[0128] if (gshift) charToType=“F”; // 3rd character
`on the 3 key, capitaliZed
`
`[0129] else charToType=“f”; // 3Id character on the
`3 key, not
`[0130] capitaliZed
`[0131] }
`[0132] else if (g2ndLetter) {// else if 2Dd letter modi
`?er button is doWn
`[0133] if (gshift) charToType=“E”; // 2Dd character
`on the 3 key, capitaliZed
`
`[0134] else charToType=“e”; // 2Dd character on the
`3 key, not capitaliZed
`[0135] }
`[0136] else {// else user is typing 1St letter on 3key
`[0137] if (gshift) charToType=“D”; // 1St character
`on the 3 key, capitaliZed
`
`[0138] else charToType=“d”; // 1St character on the
`3 key, not
`[0139] capitaliZed
`[0140] }
`[0141] } .
`[0142]
`[0143]
`[0144] // The other keys Would be interpreted much like
`the 2 and 3 keys above.
`
`[0145] // Characters like the punctuation on the # key
`can be processed much like
`
`SCEA Ex. 1008 Page 10
`
`
`
`US 2002/0163504 A1
`
`Nov. 7, 2002
`
`[0146] // the “$” and “&” characters on the 1 key Were
`processed above—i.e. they
`
`[0147] // aren’t affected by the shift key. (Of course, a
`developer might choose to
`
`[0148] // have different characters generated When the
`shift modi?er is held.)
`[0149]
`[0150]
`[0151]
`[0152] // if there’s a character to type after all that
`processing, type it.
`
`[0153] // We’ll just call a routine here that proceeds to
`type the character,
`
`[0154] // i.e. to display it and/or add it to a teXt buffer,
`as occurs When
`
`[0155] // a user types on a regular computer keyboard.
`[0156] // if (charToType !=null) Type(charToType);
`[0157] }// end of main loop
`[0158] // end of pseudo-code eXample
`[0159] Reasonably skilled programmers can develop
`many other Ways to implement softWare that interprets the
`keys and modi?er buttons in a