throbber
t|||||||||||||ll||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`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. 1006 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. 1006 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. 1006 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. 1006 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. 1006 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. 1006 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. 1006 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. 1006 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. 1006 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. 1006 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 bu

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket