US20160044150A1 - Intelligent Adaptation of Address Books - Google Patents
Intelligent Adaptation of Address Books Download PDFInfo
- Publication number
- US20160044150A1 US20160044150A1 US14/918,855 US201514918855A US2016044150A1 US 20160044150 A1 US20160044150 A1 US 20160044150A1 US 201514918855 A US201514918855 A US 201514918855A US 2016044150 A1 US2016044150 A1 US 2016044150A1
- Authority
- US
- United States
- Prior art keywords
- address
- mobile device
- favorites
- contact
- icons
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
- G06F3/04817—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance using icons
-
- H04M1/274583—
-
- G06F17/214—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0487—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
- G06F3/0488—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures
- G06F3/04886—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures by partitioning the display area of the touch-screen or the surface of the digitising tablet into independently controllable areas, e.g. virtual keyboards or menus
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/103—Formatting, i.e. changing of presentation of documents
- G06F40/109—Font handling; Temporal or kinetic typography
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T3/00—Geometric image transformation in the plane of the image
- G06T3/20—Linear translation of a whole image or part thereof, e.g. panning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T3/00—Geometric image transformation in the plane of the image
- G06T3/40—Scaling the whole image or part thereof
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/003—Details of a display terminal, the details relating to the control arrangement of the display terminal and to the interfaces thereto
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/36—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of a graphic pattern, e.g. using an all-points-addressable [APA] memory
- G09G5/37—Details of the operation on graphic patterns
- G09G5/373—Details of the operation on graphic patterns for modifying the size of the graphic pattern
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/26—Devices for calling a subscriber
- H04M1/27—Devices whereby a plurality of signals may be stored simultaneously
- H04M1/274—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc
- H04M1/2745—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips
- H04M1/27453—Directories allowing storage of additional subscriber data, e.g. metadata
- H04M1/2746—Sorting, e.g. according to history or frequency of use
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/26—Devices for calling a subscriber
- H04M1/27—Devices whereby a plurality of signals may be stored simultaneously
- H04M1/274—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc
- H04M1/2745—Devices whereby a plurality of signals may be stored simultaneously with provision for storing more than one subscriber number at a time, e.g. using toothed disc using static electronic memories, e.g. chips
- H04M1/27467—Methods of retrieving data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72448—User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions
- H04M1/72454—User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions according to context-related or environment-related conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72469—User interfaces specially adapted for cordless or mobile telephones for operating the device by selecting functions from two or more displayed items, e.g. menus or icons
- H04M1/72472—User interfaces specially adapted for cordless or mobile telephones for operating the device by selecting functions from two or more displayed items, e.g. menus or icons wherein the items are sorted according to specific criteria, e.g. frequency of use
-
- H04M1/72586—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M1/00—Substation equipment, e.g. for use by subscribers
- H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
- H04M1/724—User interfaces specially adapted for cordless or mobile telephones
- H04M1/72448—User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions
- H04M1/72451—User interfaces specially adapted for cordless or mobile telephones with means for adapting the functionality of the device according to specific conditions according to schedules, e.g. using calendar applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0251—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity
- H04W52/0254—Power saving arrangements in terminal devices using monitoring of local events, e.g. events related to user activity detecting a user operation or a tactile contact or a motion of the device
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Definitions
- FIG. 1 is a simplified schematic illustrating an environment in which exemplary embodiments may be implemented
- FIG. 2 is a more detailed block diagram illustrating the operating environment, according to exemplary embodiments
- FIG. 3 is a schematic illustrating detection of conditions, according to exemplary embodiments.
- FIG. 4 is a schematic illustrating operational states, according to exemplary embodiments.
- FIG. 5 is a schematic illustrating a database of iconic arrangements, according to exemplary embodiments.
- FIG. 6 is a schematic illustrating a log of usage, according to exemplary embodiments.
- FIG. 7 is a schematic illustrating a learning mode, according to exemplary embodiments.
- FIG. 8 is a schematic illustrating a home button on a mobile device, according to exemplary embodiments.
- FIGS. 9-10 are schematics illustrating radial distances from the home button, according to exemplary embodiments.
- FIGS. 11-14 are schematics illustrating a thumb radius, according to exemplary embodiments.
- FIG. 15 is a schematic illustrating a landscape orientation, according to exemplary embodiments.
- FIGS. 16-17 are schematics further illustrating the learning mode, according to exemplary embodiments.
- FIG. 18 is a schematic further illustrating the database of iconic arrangements, according to exemplary embodiments.
- FIG. 19 is a graphical illustration of a three-dimensional mapping, according to exemplary embodiments.
- FIGS. 20-21 are schematics illustrating handedness, according to exemplary embodiments.
- FIGS. 22-24 are schematics illustrating adaptation of sizing, according to exemplary embodiments.
- FIGS. 25-26 are schematics illustrating adaptation of an address book, according to exemplary embodiments.
- FIG. 27 is a schematic illustrating an alternate operating environment, according to exemplary embodiments.
- FIGS. 28-29 depict still more operating environments for additional aspects of the exemplary embodiments.
- first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.
- FIG. 1 is a simplified schematic illustrating an environment in which exemplary embodiments may be implemented.
- FIG. 1 illustrates a mobile device 20 having a display device 22 .
- the mobile device 20 for simplicity, is illustrated as a smart phone 24 , but the mobile device 20 may be any mobile or stationary processor-controlled device (as later paragraphs will explain).
- the display device 22 displays a home screen 26 with icons 28 . Each icon 28 typically corresponds to one of several software applications 30 executed by the mobile device 20 .
- the display device 22 may be a touch screen, thus allowing the user to touch, tap, or otherwise select any icon 28 . Should the user select one of the icons 28 , the mobile device 20 launches, resumes, or calls the corresponding software application 30 .
- iconic representation is well known, this disclosure need not provide a detailed explanation.
- Exemplary embodiments may automatically rearrange the icons 28 . As the user carries the mobile device 20 , various conditions 40 are sensed or determined. The icons 28 may then be rearranged on the home screen 26 , according to the conditions 40 . For example, exemplary embodiments may rearrange the icons 28 according to time 42 , location 44 , and/or state 46 of mobility. At a certain time 42 of day, for example, one of the software applications 30 may be preferred, based on historical use. At a particular location 44 , another one of the software applications 30 may be preferred. When the mobile device 20 travels, the state 46 of mobility may force some of the software applications 30 to be unavailable, while other software applications 30 may be brought to the home screen 26 .
- exemplary embodiments determine which of the software applications 30 is preferred, and the corresponding icon(s) 28 may be promoted for display by the home screen 26 .
- the user may thus have quick access to the preferred icon 28 without fumbling through secondary screens.
- Demotion may be required. Sometimes there are more icons 28 that can be displayed on the home screen 26 . When the mobile device 20 stores or accesses many software applications 30 , there may be too many icons 28 to simultaneously display on the single home screen 26 . The mobile device 20 may thus generate and store one or more secondary screens 48 that, when selected, display remaining ones of the icons 28 . So, when a preferred icon 28 is promoted to the home screen 26 , one or more remaining icons 28 may be removed from the home screen 26 . That is, some icons 28 may be demoted to the secondary screens 48 .
- the home screen 26 may thus intelligently adapt to the conditions 40 .
- the mobile device 20 evaluates the conditions 40 .
- the home screen 26 learns and adapts to the user, based on the conditions 40 .
- the icons 28 displayed on the home screen 26 may thus be intelligently promoted and demoted according to the conditions 40 .
- the user has quick and easy access to the corresponding software applications 30 .
- FIG. 2 is a more detailed block diagram illustrating the operating environment, according to exemplary embodiments.
- the mobile device 20 may have a processor 50 (e.g., “ ⁇ P”), application specific integrated circuit (ASIC), or other component that executes an algorithm 52 stored in a local memory 54 .
- the memory 54 may also store the software applications 30 (such as an SMS texting application, a call application, calendar application, and a web browser application).
- the algorithm 52 has instructions, code, and/or programs that may cause the processor 50 to generate a ranking 56 of the software applications 30 , according to the conditions 40 .
- the algorithm 52 may also instruct the processor 50 to adapt the corresponding icons 28 according to the conditions 40 .
- FIG. 3 is a schematic illustrating detection of the conditions 40 , according to exemplary embodiments.
- the algorithm 52 may obtain the time 42 of day, the location 44 , and the state 46 of mobility.
- the home screen 26 (or user interface) is rarely used under the same conditions at all times and locations. Indeed, smartphones have become popular due to their flexibility and usefulness under most, if not all, of the conditions 40 the user experiences each day. This flexibility is primarily enabled by the variety of the software applications 30 that may be stored and executed. Even though the mobile device 20 has the flexibility to run many different software applications 30 , each specific software application 30 may only be useful, or safe, for a narrow subset of the conditions 40 .
- a GPS-based navigation application may be useful when driving, but GPS signals are usually not received indoors and useless when stationary.
- an email client may be useful when stationary, but useless and unsafe when driving.
- Social networking applications are typically useful when at home during non-work hours, but generally used less at work during the day. Exemplary embodiments, then, detect the conditions 40 in which the mobile device 20 and/or any of the software applications 30 are used.
- the algorithm 52 thus acquires the time 42 and the location 44 .
- the time 42 may be determined from a clock signal, from a network signal, or from any known method.
- the time 42 may also be retrieved from a calendar application.
- the time 42 may be expressed along with the current day, month, and year.
- the location 44 is commonly determined from a global positioning system (“GPS”) receiver, but the location 44 may be determined from WI-FI® access points, network identifiers, and/or any known method.
- GPS global positioning system
- the time 42 and the location 44 may be adaptively combined.
- the algorithm 52 may determine the mobile device 20 is currently at the “home” location 44 based on detection of a residential network, along with morning or night hours.
- a “work” location 44 may be determined from detection of an office network, along with weekday daytime hours (e.g., 9 AM to 5 PM).
- the algorithm 52 may also distinguish between a “home” and a “visiting” market, perhaps again based on radio network identifiers (e.g., LTE tracking area or UMTS Location Area). Should the algorithm 52 detect a never-before seen tracking area, the algorithm 52 may assume the mobile device 20 is located in a non-home, visiting market.
- the algorithm 52 may also generate a prompt on the display device 22 , asking the user to confirm or input the time 42 and/or the location 44 .
- BLUETOOTH® pairing may also be used.
- the mobile device 20 When the mobile device 20 is operating in an automobile, the mobile device 20 may electronically pair, mate, or interface with a BLUETOOTH® transceiver for hands-free operation. If the mobile device 20 automatically pairs with the automobile, the algorithm 52 may assume the user is the driver of the automobile. Conversely, if the mobile device 20 is manually paired with the automobile, the algorithm 52 may assume the user is the passenger of the automobile. That is, automatic or manual pairing may determine whether the user is the driver or the passenger. The algorithm 52 may thus adapt the home screen 26 according to whether the mobile device 20 is used by the driver or the passenger.
- Exemplary embodiments also determine the state 46 of mobility.
- the state 46 of mobility may be determined from information received from the global positioning system (“GPS”) receiver (such as GPS information or coordinates 60 ).
- GPS global positioning system
- the state 46 of mobility may also be determined using sensor output from an accelerometer 62 and/or from a kinetic generator 64 .
- the accelerometer 62 and/or the kinetic generator 64 senses different levels or measurements of vibration 66 .
- the vibration 66 may be random or cyclic motion, perhaps in one or more axes.
- the accelerometer 62 and/or the kinetic generator 64 outputs a digital or analog signal (e.g., amplitude, frequency, voltage, current, pulse width) that is indicative of the vibration 66 during use of the mobile device 20 .
- the algorithm 52 may use any parameter of the signal as an indication of the vibration 66 to determine the state 46 of mobility.
- the kinetic generator 64 may detect the vibration 66 .
- the kinetic generator 64 is any device that converts the vibration 66 , or any motion, to electric current.
- the kinetic generator 64 for example, may be mechanical, piezoelectric, chemical, or any other technology.
- Output from a microphone 68 may also be used.
- the mobile device 20 may have the microphone 68 to receive audible sounds and to output signals indicative of the sounds.
- the algorithm 52 may use the output from the microphone 68 to further determine the state 46 of mobility.
- the algorithm 52 may determine the state 46 of mobility as stationary, in response to little to no vibration 66 compared to a threshold value for stationary positions.
- the state 46 of mobility may be determined as walking, in response to the vibration 66 greater than some other threshold for human walking.
- a frequency of the vibration 66 may also be compared to a threshold frequency for the walking determination.
- Vehicular movement may be determined in response to random frequencies of the vibration 66 , perhaps coupled with known, low frequency road noises received by the microphone 68 .
- FIG. 4 is a schematic illustrating operational states 80 , according to exemplary embodiments.
- the algorithm 52 determines the operational state 80 for the mobile device 20 . That is, the algorithm 52 analyzes the conditions 40 (e.g., the time 42 of day, the location 44 , and the state 46 of mobility) and concludes how best to characterize the operational state 80 for the mobile device 20 . For example, the algorithm 52 may query a database 82 of operational states.
- FIG. 4 illustrates the database 82 of operational states as a table 84 that maps, relates, or associates different combinations of the conditions 40 to different operational states 80 .
- the database 82 of operational states stores different operational states for different combinations of the conditions 40 (e.g., the time 42 , the location 44 , and/or the state 46 of mobility).
- the database 82 of operational states may thus be populated with entries for many different conditions 40 and their corresponding operational states 80 . While FIG. 4 only illustrates a few entries, in practice the database 82 of operational states may contain hundreds, perhaps thousands, of entries.
- a simple, partial listing of some operational states 80 is provided below:
- FIG. 5 is a schematic illustrating a database 90 of iconic arrangements, according to exemplary embodiments.
- the algorithm 52 may then consult the database 90 of iconic arrangements.
- the database 90 of iconic arrangements stores iconic arrangements 92 for the icons 28 on the home screen 26 for different operational states 80 .
- FIG. 5 illustrates the database 90 of iconic arrangements as a table 94 that maps, relates, or associates the different operational states 80 to their corresponding iconic arrangement 92 .
- Each entry in the database 90 of iconic arrangements may thus be populated with a different arrangement 92 for the icons 28 on the home screen 26 , depending upon the corresponding operational state 80 .
- the algorithm 52 may query the database 90 of iconic arrangements for the operational state 80 . If the operational state 80 of the mobile device 20 matches one of the entries in the database 90 of iconic arrangements, the algorithm 52 retrieves the corresponding arrangement 92 for the icons 28 in the home screen 26 . While FIG. 5 only illustrates a few entries, in practice the database 90 of iconic arrangements may contain many entries.
- the algorithm 52 then adapts the home screen 26 . Once the arrangement 92 is retrieved for the operational state 80 , the algorithm 52 then moves the icons 28 on the home screen 26 . That is, some icons 28 may be demoted from the home screen 26 , and other icons 28 may be promoted to the home screen 26 (as earlier paragraphs explained). The algorithm 52 automatically rearranges the icons 28 to suit the operational state 80 of the mobile device 20 . Should the operational state 80 again change, the algorithm 52 may again reconfigure the icons 28 to suit some new operational state 80 .
- FIG. 6 is a schematic illustrating a log 100 of usage, according to exemplary embodiments.
- the algorithm 52 may store usage information in the log 100 of usage.
- the algorithm 52 may observe and record which software applications 30 are used for any combination of the conditions 40 (e.g., the time 42 of day, the location 44 , and the state 46 of mobility). Over time the algorithm 52 learns which ones of the software applications 30 are used most often for each condition 40 . For example, the algorithm 52 may monitor how often each software application 30 is started, how often each software application 30 is moved to the home screen 26 , and/or how long each software application 30 remains on the home screen 26 for each condition 40 . The algorithm 52 thus logs usage for the different operational states 80 of the mobile device 20 .
- FIG. 7 is a schematic illustrating a learning mode 110 for the mobile device 20 , according to exemplary embodiments.
- the algorithm 52 may self-configure the icons 28 on the home screen 26 . That is, the algorithm 52 may intelligently learn the user's iconic preferences for the different operational states 80 . Even though the mobile device 20 may have the arrangements 92 pre-stored or pre-determined (as explained with reference to FIG. 5 ), the algorithm 52 may tailor the iconic arrangement 92 to best suit the user's personal usage habits.
- the algorithm 52 may record which software applications 30 are preferred for the different conditions 40 . The algorithm 52 may thus tally the usage information and learn what software applications the user prefers for the different operational states 80 .
- the algorithm 52 may then self-determine the arrangement 92 of the icons on the home screen 26 , in response to the usage information in the log 100 of usage. That is, the algorithm 52 may configure the icons 28 for a user-friendly home screen 26 , according to the operational state 80 . Again, the algorithm 52 may arrange the application icons 28 so that the most frequently used software applications 30 are prominently placed on the home screen 26 . Lesser-used icons 28 may be removed from the home screen 26 and demoted to the secondary screen 48 .
- FIG. 8 is a schematic illustrating a home button 120 on the mobile device 20 , according to exemplary embodiments.
- the mobile device 20 displays the home screen 26 . While the home button 120 may be located at any location on the mobile device 20 , FIG. 8 illustrates the home button 120 on a front face of the smart phone 24 .
- Exemplary embodiments may cluster the icons 28 .
- the algorithm 52 may arrange the icons 28 about the home button 120 . That is, once the algorithm 52 determines the most frequently used software application(s) 30 during the operational state 80 , the algorithm 52 may arrange the corresponding icons 28 around the home button 120 . So, not only are the popular icons 28 promoted to the home screen 26 , but the popular icons 28 may also be clustered around the home button 120 . The popular icons 28 during the operational state 80 are thus arranged for easy access about the home button 120 .
- FIG. 8 thus illustrates a grid 122 of the icons 28 .
- the algorithm 52 may arrange the application icons 28 on the home screen 26 .
- FIG. 8 illustrates the application icons 28 arranged in the grid 122 , with each individual icon 28 having a row and column position. Each position in the grid 122 corresponds to a rank in the ranking 56 . That is, once the algorithm 52 determines which icons 28 are promoted to the home screen 26 , the algorithm 52 may further generate assign the icon 28 to a position in the grid 122 , according to the ranking 56 .
- the ranking 56 may start near the home button 120 .
- the most popular icons 28 may be reserved for positions closest to the home button 120 . That is, a first position in the ranking 56 may correspond to one of the row/column positions that is closest to the home button 120 .
- a text messaging icon 28 may be assigned the first position in the grid 122 .
- Next popular may be a news-feed application, which is assigned a second position in the grid 122 .
- the third most popular application icon 28 is assigned a fourth position
- a fifth most popular application icon 28 is assigned a fifth position, and so on.
- the application icons 28 may thus be arranged according to the ranking 56 , with the more popular software application icons 28 reserved for the closest positions to the home button 120 . Because the icons 28 are positioned near the home button 120 , the icons are within easy reach of the user's thumb (as later paragraphs will explain).
- FIGS. 9-10 are schematics illustrating radial distances from the home button 120 , according to exemplary embodiments.
- the algorithm 52 generates the ranking 56 of the software applications 30 , and the corresponding icons 28 are still clustered about the home button 120 .
- the icons 28 are arranged according to a radial distance from the home button 120 . That is, the most popular icons 28 may be reserved for positions in an arc 130 that are closest to the home button 120 .
- the arc 130 has a corresponding radius R arc (illustrated as reference numeral 132 ) about which the icons 28 are aligned.
- the radius 132 may be determined from the home button 120 .
- less popular icons 134 may be aligned on a second arc 136 that corresponds to a greater, second radius 138 .
- the least popular icons 140 may be aligned on a third arc 142 that corresponds to a still greater, third radius 144 .
- Exemplary embodiments may thus rank and arrange the icons 28 about successive radial arcs from the home button 120 . This radial arrangement positions the icons 28 near the home button 120 , within easy reach of the user's thumb.
- FIGS. 11-14 are schematics illustrating a thumb radius 150 , according to exemplary embodiments.
- FIG. 11 illustrates one-handed operation of the smart phone 24 .
- the smart phone 24 is held in a portrait orientation and cradled in a palm of the user's hand.
- the user's thumb 152 reaches to select the icons 28 on the home screen 26 .
- the application icons 28 may be radially arranged with respect to the thumb radius 150 of the user's thumb 152 .
- the ranked icons 28 may thus be positioned to always be within easy reach of the user's thumb 152 .
- FIG. 11 thus illustrates another radial arrangement of the icons 28 .
- the icons 28 may again be positioned along the arc 130 .
- the user's thumb radius 150 determines the arc 130 .
- the radial arrangement of the icons 28 may be adjusted to suit the length of the user's thumb 152 .
- FIG. 12 also illustrates the thumb radius 150 .
- the algorithm 52 determines which icons 28 should be displayed (according to the operational state 80 )
- the algorithm 52 positions the icons 28 on the home screen 26 .
- the algorithm 52 retrieves the user's thumb radius 150 from the memory 54 , mathematically plots the arc 130 , and aligns the icons 28 to the arc 130 .
- the icons 28 for the operational state 80 are thus radially aligned within easy reach of the user's thumb (illustrated as reference numeral 152 in FIG. 11 ).
- FIGS. 11 and 12 also illustrates an origin 154 for the thumb radius 150 .
- the origin 154 is a reference position from which the arc 130 is centered. That is, the user's thumb radius 150 is calculated from the origin 154 , thus determining where on the home screen 26 that the icons 28 are radially aligned.
- the origin 154 may thus be selected by the user to ensure the radial alignment coincides with the user's thumb 152 .
- Exemplary embodiments, then, may permit the user to select the origin 154 from which the arc 130 is defined.
- the user for example, may touch or tap a location on the home screen 26 (if touch sensored) to define the origin 154 .
- the user may specify coordinates on the home screen 26 for the origin 154 . Touch sensors on a body or shell of the mobile device 20 may even determine the origin 154 , as the mobile device 20 is held in the user's hand. Regardless, the user may personalize the radial arrangement to suit her one-handed operation.
- FIG. 13 illustrates measurement of the user's thumb radius 150 .
- the algorithm 52 may present a prompt 160 for measuring the user's thumb radius 150 .
- the prompt 160 instructs the user to place her thumb on the display device 22 .
- the algorithm 52 may then cause the mobile device 20 to capture a full-size image of the user's thumb 152 , from which the thumb radius 150 is determined by image analysis.
- the algorithm 52 may use pressure points or inputs to detect the length of the user's thumb 152 .
- Exemplary embodiments may use any measures of measuring the length of the user's thumb 152 , including manual entry. Regardless, once the user's thumb radius 150 is known, the algorithm 52 may use the thumb radius 152 to align the icons (as earlier paragraphs explained).
- FIG. 14 also illustrates radial alignment from the home button 120 .
- the icons 28 may be radially arranged from the home button 120 , according to the user's thumb radius 150 .
- the algorithm 52 retrieves the user's thumb radius 150 and aligns the most popular icons 28 within the arc 130 defined by the thumb radius 150 from the home button 120 .
- the most popular icons 28 are within easy reach of the user's thumb during single-handed use.
- Exemplary embodiments may even arrange the icons 28 along multiple arcs (as explained with reference to FIG. 10 ). Some of the multiple arcs may have a radius less than or equal to the user's thumb radius 150 , measured from the home button 120 .
- Less popular icons 28 may be arranged along an arc having a radius greater than the user's thumb radius 150 from the home button 120 .
- the popular icons 28 in other words, may be arranged within easy reach of the home button 120 , but less popular icons 28 may be positioned beyond the user's thumb radius 150 .
- FIG. 15 is a schematic illustrating a landscape orientation 170 , according to exemplary embodiments.
- the mobile device 20 may be oriented for two-handed operation.
- the application icons 28 may be arranged within easy reach of the user's left thumb and/or the user's right thumb. That is, as the ranking 56 is generated, some of the application icons 28 may be arranged within a left thumb radius 172 .
- Other icons 28 may be arranged within a right thumb radius 174 . If the user is right-handed, for example, the most popular icons 28 may be clustered within the right thumb radius 174 about a right corner 176 of the display device 22 .
- Less popular icons 28 may be arranged within the left thumb radius 172 about a left corner 178 of the display device 22 .
- a left-handed user may prefer a vice versa arrangement.
- the icons 28 may be arranged within arcs 180 and 182 , within easy of the user's respective left and right thumbs.
- FIGS. 16-17 are schematics further illustrating the learning mode 110 for the mobile device 20 , according to exemplary embodiments.
- the algorithm 52 may further record a selection area 190 for each icon 28 . That is, when any icon 28 is selected, the algorithm 52 may record whether the mobile device 20 was in the landscape orientation 170 or in the portrait orientation 192 .
- the selection area 190 may also record a quadrant, zone, or region of the home screen 26 from which the icon 28 was selected.
- the selection area 190 thus allows the algorithm 52 to infer whether the user's left thumb or right thumb made the selection. For example, if the icon 28 is selected from the lower right corner portion of the home screen 26 , then the algorithm 52 may determine that the user's right thumb likely made the selection. If the icon 28 is selected from the lower left corner portion of the home screen 26 , then the algorithm 52 may determine that the user's left thumb made the selection. That is, the algorithm 52 may associate a handedness 194 with each icon 28 recorded in the log 100 of usage.
- FIG. 17 further illustrates the iconic arrangement.
- the application icons 28 may be arranged according to the handedness 194 .
- the algorithm 52 generates the ranking 56 for the corresponding operational state 80
- the application icons 28 may be arranged according to the ranking 56 and clustered according to the handedness 194 .
- the most popular icons 28 with right-handedness 194 may be arranged within the right thumb radius 174 about the right bottom corner 176 of the home screen 26 .
- the most popular icons 28 with left-handedness 194 may be arranged within the left thumb radius 172 about the left bottom corner 178 of the home screen 26 .
- the icons 28 may be arranged within the arcs 180 and 182 about the preferred thumbs for easy access.
- Some examples of the ranked icons 28 are provided. Consider, for example, that some software applications 30 may be unsafe for some operational states 80 . When the algorithm 52 determines the operational state 80 involves driving, some software applications 30 (such as email and text) may be categorized as unsafe or even prohibited. The algorithm 52 , then, may deliberately demote the corresponding application icons 28 to the secondary screen 48 . Other software applications 30 , however, may be categorized as safe driving enablers, such as voice control and telephony applications. The corresponding safe application icons 28 may be promoted to prominent, high-ranking positions on the home screen 26 .
- FIG. 18 is a schematic further illustrating the database 90 of iconic arrangements, according to exemplary embodiments.
- FIG. 18 again illustrates the database 90 of iconic arrangements as the table 94 that associates the different operational states 80 to their corresponding iconic arrangements 92 .
- the iconic arrangements 92 may be augmented with and the positional ranking 200 . That is, once the software applications 30 are ranked, the algorithm 52 may assign iconic positions on the home screen 26 .
- Each icon 28 may have its positional ranking 200 expressed as the row and column (as explained with reference to FIG. 8 ).
- Each icon 28 may also be radially arranged with respect to the home button 12 and/or the user's thumb radius 150 (as explained with reference to FIGS. 9-17 ). Referencing FIG.
- FIG. 18 thus illustrates examples of entries in the database 90 of iconic arrangements. Again, FIG. 18 only illustrates several entries. In practice the database 90 of iconic arrangements may contain hundreds, perhaps thousands, of entries.
- the algorithm 52 thus dynamically builds the home screen 26 . Any time the operational state 80 changes, the home screen 26 may adapt throughout the day as operational states 80 change. For example, should the mobile device 20 pair with a BLUETOOTH® interface (perhaps for hands-free operation in a vehicle), and/or detect the vibration (as explained with reference to FIG. 3 ), the algorithm 52 may reconfigure the home screen 26 . That is, the home screen 26 may change from a “morning home stationary” arrangement 92 to a “non ⁇ work home market driving” arrangement 92 . Should an office WI-FI® network be detected, perhaps without low-frequency vehicular sounds and the vibration 66 , then the algorithm 52 may further change the home screen 26 to a “work office stationary” arrangement 92 .
- the algorithm 52 may again change the home screen 26 to a “non ⁇ work home market driving” arrangement 92 . If a home network is detected (perhaps from a home FEMTO identifier), perhaps without recognized vehicular vibration 66 and low-frequency sounds, the home screen 26 may reconfigure to an “evening home stationary” arrangement 92 . Finally, in the evening of the day, the home screen 26 may reconfigure to a “non-work home market walking” arrangement 92 in response to slow, cyclic vibration 66 while the user walks a dog, and the home FEMTO is out of range. While only these few examples are provided, many more combinations are possible, depending on the operational states 80 .
- FIG. 19 is a graphical illustration of a three-dimensional mapping 210 of the conditions 40 , according to exemplary embodiments. While the algorithm 52 may dynamically arrange the icons 28 based on only one of the conditions 40 , exemplary embodiments may dynamically arrange based on any combination of the time 42 of day, the location 44 , and the state 46 of mobility. FIG. 19 thus illustrates the three-dimensional mapping 210 of the conditions 40 . As this disclosure above explains, the icons 28 on the home screen 26 are rarely used under the same conditions 40 . Each specific software application 30 may only be useful for certain combinations of the conditions 40 . Exemplary embodiments, then, detect the conditions 40 and consult the three-dimensional mapping 210 to determine the operational state 80 .
- FIG. 19 thus graphs the conditions 40 .
- the different conditions 40 e.g., the time 42 of day, the location 44 , and the state 46 of mobility
- the location 44 may be quantified from some reference location, such as the distance from the user′ home address.
- the algorithm 52 determines the time 42 of day, the location 44 , and the state 46 of mobility
- the algorithm 52 consults the three-dimensional mapping 210 .
- One or more state functions 212 may be defined to determine the operational state 80 . That is, the state function 212 may be expressed as some function of the time 42 , the location 44 , and the state 46 of mobility.
- Different three-dimensional geometrical regions 214 of the three-dimensional mapping 210 may also define different, corresponding operational states 80 .
- the algorithm 52 may consult the three-dimensional mapping 210 for the time 42 of day, the location 44 , and/or the state 46 of mobility. The algorithm 52 retrieves the corresponding operational state 80 and then determines the arrangement 92 (as earlier paragraphs explained).
- FIGS. 20-21 are schematics further illustrating the handedness 194 , according to exemplary embodiments.
- the application icons 28 displayed on the home screen 26 may be configured for right-hand operation 220 or for left-hand operation 222 . That is, the icons 28 may be rearranged for left hand use or for right hand use.
- a left-handed user for example, may have difficulty reaching, or selecting, an icon 28 arranged outside the left thumb radius 172 .
- a right-handed user likely has difficulty selecting icons positioned beyond the right thumb radius 174 . These difficulties may be especially acute for larger display screens held in smaller hands. Over-extension may produce very different experiences between left- and right-handed users. Most users, in other words, may be dissatisfied with the same iconic arrangement 92 .
- Exemplary embodiments may thus adapt to the handedness 194 .
- the algorithm 52 may detect whether the mobile device 20 is held in the user's right hand or in the user's left hand. The algorithm 52 may then arrange the icons 28 on the home screen 26 to suit the right-handed operation 220 or the left-hand operation 222 .
- the algorithm 52 may cluster or arrange higher-ranking icons 28 to the user's right thumb. Conversely, the higher-ranking icons 28 may be arranged to the user's left thumb for the left-hand operation 222 .
- FIG. 20 illustrates touch sensors 224 .
- the touch sensors 224 detect the number and locations of contact points with the user's fingers and thumb. As the mobile device 20 is held, the user's fingers and thumb grasp and cradle the mobile device 20 .
- the touch sensors 224 detect the number and pattern of contact points between the hand and the mobile device 20 . While the touch sensors 224 may be located anywhere on the mobile device 20 , FIG. 20 illustrates the touch sensors 224 along left and right sides. The number of the contact points, and the pattern of those contact points, may thus be used to determine the right-handed operation 220 or the left-hand operation 222 .
- the touch sensors 224 may detect the user's palm as a left-side, single, wide contact point.
- the touch sensors 224 may also detect the user's left fingers as two or more narrow contact points on the right side of the mobile device 20 . Should the mobile device 20 be held in the right hand, the user's palm appears as a single, wide contact point on the right and the fingers appear as two or more narrow contact points on the left.
- Exemplary embodiments may then arrange the icons 28 .
- the algorithm 52 determines the operational state 80 and retrieves the corresponding arrangement 92 . However, the algorithm 52 may then adapt the arrangement 92 according to the handedness 194 . If the left-hand operation 222 is determined, the icons 28 may be arranged about the user's left thumb. That is, the icons 28 may be arranged within the user's left thumb radius 172 (as explained with reference to FIGS. 15-17 ). If the right-handed operation 220 is determined, the icons 28 may be arranged within the user's right thumb radius 174 (again as explained with reference to FIGS. 15-17 ). Exemplary embodiments may thus rearrange the home screen 26 such that higher-ranking icons 28 are closest to the user's preferred thumb for easy selection.
- FIG. 20 illustrates an arrangement for morning habits. If the operational state 80 is “morning home stationary,” an alarm clock application may be high ranking. Exemplary embodiments may thus position the corresponding application icon 28 in the bottom left corner 178 for the left-hand operation 222 . This position puts the high-ranking icon 28 within easy reach of the user's left thumb. A right-handed user, however, may prefer the icon 28 in the bottom right hand corner 176 for the right-handed operation 220 . Moreover, this positioning also reduces the area over which the display device 22 is blocked by the user's thumb. As the user's thumb reaches to select the icons 28 , the user's thumb and/or hand may block significant portions of the display device 22 . Positioning according to the handedness 194 may thus improve visibility and reduce incorrect or accidental selection of the wrong icon 28 .
- FIG. 21 is another schematic illustrating the database 90 of iconic arrangements, according to exemplary embodiments.
- the database 90 of iconic arrangements again associates the different operational states 80 to their corresponding iconic arrangements 92 .
- the iconic arrangements 92 may be augmented with the handedness 194 .
- the algorithm 52 queries the table 94 for the operational state 80 and retrieves the corresponding iconic arrangement 92 of the home screen 26 , along with the handedness 194 .
- the algorithm 52 then arranges the icons 28 on the home screen 26 , as this disclosure explains.
- the algorithm 52 will improve with time. As the algorithm 52 gains experience with the user, the algorithm 52 may determine that the user always, or usually, prefers the right-handed operation 220 or the left-hand operation 222 . The icons 28 on the home screen 26 may thus be arranged according to habitual handedness 194 . The algorithm 52 , of course, may determine how the mobile device 20 is currently held and adapt to the current handedness 194 . Even though the left-hand operation 222 may be habitually preferred, the icons 28 may be rearranged when currently held in the user's right hand.
- FIGS. 22-24 are schematics illustrating adaptation of sizing, according to exemplary embodiments.
- a size 230 of an icon 28 may adapt, according to the operational state 80 . That is, the size 230 of any of the icons 28 may increase, or decrease, in response to the operational state 80 .
- High-ranking icons 28 may have a larger size 230 than lesser ranking icons 28 . Indeed, the highest-ranking icon 28 (perhaps representing a most popular software application 30 ) may be sized greater than all other icons 28 displayed by the home screen 26 .
- Rarely used icons 28 may be reduced in the size 230 , thus allowing the home screen 26 to be dominated by the popular icons 28 .
- the size 230 of an individual icon 28 may determine its user friendliness. Screen size, resolution, and user dexterity are among the various factors that limit the number and user-friendliness of the application icons 28 that can fit on the home screen 26 . Indeed, with the small display device 22 of the smart phone 24 , user friendliness becomes even more of an important consideration. For example, small sizes for the icons 28 may be well suited for stationary use (e.g., when the mobile device 20 and user are not separately moving or shaking). However, small sizes for the icons 28 are not suited during mobile situations when the user and the mobile device 20 are separately moving or shaking. The state 46 of mobility, in other words, may cause small icons to be difficult to read and select. Accidental, unwanted selection of an adjacent icon often results.
- Sizing may thus adapt.
- the algorithm 52 determines the operational state 80 (from the conditions 40 )
- the algorithm 52 retrieves the corresponding arrangement 92 .
- the algorithm 52 may also adapt the size 230 of any icon 28 according to the operational state 80 .
- the algorithm 52 may enlarge the four (4) highest ranking 56 , most important application icons 28 . Indeed, lesser ranking 56 and even rarely used icons 28 may be demoted to the secondary screen 48 .
- the algorithm 52 may enlarge the four (4) icons 28 to consume most of the home screen 26 . This enlargement allows reliable selection, despite the state 46 of mobility. Indeed, even spacing between the icons 28 may be adjusted, based on the operational state 80 . Should the mobile device 20 be nearly stationary, conversely smaller-sized icons 28 may be adequate, thus allowing more icons to be simultaneously displayed by the home screen 26 .
- FIG. 23 illustrates text sizing.
- any text 232 displayed on the home screen 26 may be sized according to the operational state 80 . Fonts may be enlarged, or decreased, in response to the operational state 80 .
- weather information may be enlarged in some operational states 80 and reduced in others.
- the text 232 may be sized according to the operational state 80 .
- FIG. 24 is another schematic illustrating the database 90 of iconic arrangements.
- the database 90 of iconic arrangements again associates the different operational states 80 to their corresponding iconic arrangements 92 .
- the iconic arrangements 92 may be augmented with sizing adaptations 234 .
- the algorithm 52 may size 230 the icons 28 and the text 232 according to the operational state 80 .
- the algorithm 52 queries the table 94 for the operational state 80 and retrieves the corresponding iconic arrangement 92 with the sizing adaptations 234 .
- the algorithm 52 then dynamically arranges and sizes the icons 28 and the text 232 , as this disclosure explains. Large sizing of the icons 28 and the text 232 enable reliable use where mobility and vibration impact readability and selectability. The risk of incorrect selections and distractions whilst driving is thus reduced. Small sizing, on the other hand, enables comprehensive and flexible use where mobility and vibration may not impact safety, readability and selectability.
- the algorithm 52 also removes the hassle associated with manually adapting the home screen 26 .
- FIGS. 25-26 are schematics illustrating adaptation of an address book 240 , according to exemplary embodiments.
- the user's address book 240 may adapt, according to the operational state 80 .
- the user's address book 240 may sort its contacts entries according to the time 42 of day, the location 44 , and the state 46 of mobility.
- the size 230 of the text 232 may also adjust, according to the operational state 80 .
- one of the software applications 30 is the electronic address book 240 that stores voice, text, and other contacts.
- the mobile device 20 may store many, perhaps hundreds, of contact entries in the address book 240 .
- the mobile device 20 may thus store many email addresses, phone numbers, street addresses, and even notes regarding the many contact entries.
- the mobile device 20 may thus sort and display the address book 240 with entries that are easy to see, reach, and select on a single screen. With this in mind, conventional mobile devices commonly spread the user's contact entries over multiple screens, through which the user must scroll.
- Exemplary embodiments may be applied to the user's address book 240 .
- the user's needs and habits may change, according to the operational state 80 .
- the user has very different visibility and calling habits when driving a vehicle on personal time, versus when the user is sitting in the office during the workday.
- exemplary embodiments may record calling behaviors, texting behaviors, and the other usage information in the log 100 of usage (as explained with reference to FIG. 5 ).
- the address book 240 may store hundreds of contact entries, small sets of contacts are generally only useful for a narrow subset of conditions. For example, a work contact may be useful during workday hours, but the work contact may be unavailable outside those hours. Likewise, a subset of contacts is called and needed while driving, but perhaps not so important at other conditions 40 .
- the algorithm 52 may thus intelligently adapt the user's address book 240 in order to improve the usability and safety.
- the user's address book 240 may thus intelligently adapt.
- the algorithm 52 determines the operational state 80 (from the time 42 of day, the location 44 , and the state 46 of mobility). Over time the algorithm 52 learns which contacts are used most often for each condition. For example, the algorithm 52 learns how often each contact is called, how often each contact is texted, and/or how long any communication with each contact is displayed for each condition. The algorithm 52 thus determines which contacts are used most often for each condition 40 .
- the algorithm 52 may then generate address favorites 242 for the operational state 80 . That is, the algorithm 52 sorts and condenses the hundreds of entries in the address book 240 to only those contacts that are historically relevant to the operational state 80 .
- the algorithm 52 thus causes the mobile device 20 to visually display (and/or audibly present) the address favorites 242 for the operational state 80 .
- the most frequently used contacts may be positioned closest to the user's preferred thumb (as earlier paragraphs explained). Lesser-used contacts may be positioned further from the user's thumb or even demoted to the secondary screen 48 .
- the operational state 80 warrants, some contacts may be categorized, such as “unavailable after hours” and deliberately demoted to the secondary screen 48 .
- Other contacts for example, may be categorized “safe driving enablers” (E911 and roadside assistance) and prominently positioned for close, quick selection.
- Sizing and fonting may also be adapted.
- the size 230 of the text 232 for any contact may also adjust, according to the operational state 80 . That is, once the algorithm 52 generates the address favorites 242 for the operational state 80 , the font size 230 of the contacts listing may be enlarged, or reduced, to suit the state 46 of mobility and most likely contact use. For example, if the user is walking, the algorithm 52 may enlarge the four (4) highest ranking, most important contact text lines to fill the home screen 26 . This textual enlargement enables reliable use where the relative position of the mobile device 20 and user are constantly changing by large amounts.
- the algorithm 52 may enlarge the six (6) most important contact text lines to fill the home screen 26 , thus enabling safer operation when required whilst driving.
- FIG. 26 illustrates the address favorites 242 .
- the mobile device 20 may store associations in the memory 54 . That is, the address favorites 242 may be stored in a database 250 of address favorites.
- FIG. 26 illustrates the database 250 of address favorites as a table 252 that maps, relates, or associates the different operational states 80 to their corresponding address favorites 242 .
- the algorithm 52 determines the operational state 80
- the algorithm 52 queries the database 250 of address favorites for the operational state 80 . If a match exists, the algorithm 52 retrieves the corresponding address favorites 242 . As FIG.
- each address favorite 242 may also include the sizing adaptations 234 for the text 232 and the positional ranking 200 for the location of the contacts.
- the algorithm 52 then positions the address favorites 242 to the user's desired location (such as the home button 120 or the user's preferred thumb, as explained above).
- FIG. 27 is a schematic illustrating an alternate operating environment, according to exemplary embodiments.
- the database 90 of iconic arrangements may be remotely stored and accessed from any location within a network 260 .
- the database 90 of iconic arrangements may be stored in a server 262 .
- the algorithm 52 determines the conditions 40
- the algorithm 52 instructs the mobile device 20 to send a query to the server 262 . That is, the mobile device 20 queries the server 262 for the conditions 40 . If a match is found, the server 262 sends a response, and the response includes the operational state 80 .
- Remote, central storage relieves the mobile device 20 from locally storing and maintaining the database 90 of iconic arrangements.
- any portion of the exemplary embodiments may be remotely stored and maintained to relieve local processing by the mobile device 20 .
- Exemplary embodiments may be applied regardless of networking environment. Exemplary embodiments may be easily adapted to mobile devices having cellular, WI-FI®, and/or BLUETOOTH® capability. Exemplary embodiments may be applied to mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). Exemplary embodiments, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain.
- IP Internet Protocol
- Exemplary embodiments may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN).
- Exemplary embodiments may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, exemplary embodiments may be applied regardless of physical componentry, physical configuration, or communications standard(s).
- FIG. 28 is a schematic illustrating still more exemplary embodiments.
- FIG. 28 is a more detailed diagram illustrating a processor-controlled device 300 .
- the algorithm 52 may operate in any processor-controlled device.
- FIG. 28 illustrates the algorithm 52 stored in a memory subsystem of the processor-controlled device 300 .
- One or more processors communicate with the memory subsystem and execute either, some, or all applications. Because the processor-controlled device 300 is well known to those of ordinary skill in the art, no further explanation is needed.
- FIG. 29 depicts other possible operating environments for additional aspects of the exemplary embodiments.
- FIG. 29 illustrates the algorithm 52 operating within various other devices 400 .
- FIG. 29 illustrates that the algorithm 52 may entirely or partially operate within a set-top box (“STB”) ( 402 ), a personal/digital video recorder (PVR/DVR) 404 , a Global Positioning System (GPS) device 408 , an interactive television 410 , a tablet computer 412 , or any computer system, communications device, or processor-controlled device utilizing the processor 50 and/or a digital signal processor (DP/DSP) 414 .
- STB set-top box
- PVR/DVR personal/digital video recorder
- GPS Global Positioning System
- DP/DSP digital signal processor
- the device 400 may also include watches, radios, vehicle electronics, clocks, printers, gateways, mobile/implantable medical devices, and other apparatuses and systems. Because the architecture and operating principles of the various devices 400 are well known, the hardware and software componentry of the various devices 400 are not further shown and described.
- Exemplary embodiments may be physically embodied on or in a computer-readable storage medium.
- This computer-readable medium may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks.
- This computer-readable medium, or media could be distributed to end-subscribers, licensees, and assignees.
- a computer program product comprises processor-executable instructions for intelligent adaptation of icons, text, fonts, and address books, as the above paragraphs explained.
Abstract
Address books may be intelligently adapted. A sensor output is received indicating a measure of vibration of a mobile device. An address book associated with the mobile device is retrieved and condensed according to the measure of the vibration to generate address favorites. The address favorites are displayed on a display device of the mobile device, such that the vibration experienced by the mobile device determines which contacts in the address book are preferred.
Description
- This application is a continuation of prior U.S. patent application Ser. No. 14/036,030, filed Sep. 25, 2013, which is herein incorporated by reference in its entirety.
- A portion of the disclosure of this patent document and its attachments contain material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyrights whatsoever.
- Mobile communications have revolutionized our lives. Today mobile applications may be downloaded for all manner of services and games. As users download more and more applications, however, their mobile devices become cluttered with iconic representations. In other words, there are simply too many application icons for most users to manage.
- The features, aspects, and advantages of the exemplary embodiments are understood when the following Detailed Description is read with reference to the accompanying drawings, wherein:
-
FIG. 1 is a simplified schematic illustrating an environment in which exemplary embodiments may be implemented; -
FIG. 2 is a more detailed block diagram illustrating the operating environment, according to exemplary embodiments; -
FIG. 3 is a schematic illustrating detection of conditions, according to exemplary embodiments; -
FIG. 4 is a schematic illustrating operational states, according to exemplary embodiments; -
FIG. 5 is a schematic illustrating a database of iconic arrangements, according to exemplary embodiments; -
FIG. 6 is a schematic illustrating a log of usage, according to exemplary embodiments; -
FIG. 7 is a schematic illustrating a learning mode, according to exemplary embodiments; -
FIG. 8 is a schematic illustrating a home button on a mobile device, according to exemplary embodiments; -
FIGS. 9-10 are schematics illustrating radial distances from the home button, according to exemplary embodiments; -
FIGS. 11-14 are schematics illustrating a thumb radius, according to exemplary embodiments; -
FIG. 15 is a schematic illustrating a landscape orientation, according to exemplary embodiments; -
FIGS. 16-17 are schematics further illustrating the learning mode, according to exemplary embodiments; -
FIG. 18 is a schematic further illustrating the database of iconic arrangements, according to exemplary embodiments; -
FIG. 19 is a graphical illustration of a three-dimensional mapping, according to exemplary embodiments; -
FIGS. 20-21 are schematics illustrating handedness, according to exemplary embodiments; -
FIGS. 22-24 are schematics illustrating adaptation of sizing, according to exemplary embodiments; -
FIGS. 25-26 are schematics illustrating adaptation of an address book, according to exemplary embodiments; -
FIG. 27 is a schematic illustrating an alternate operating environment, according to exemplary embodiments; and -
FIGS. 28-29 depict still more operating environments for additional aspects of the exemplary embodiments. - The exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings. The exemplary embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the exemplary embodiments to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).
- Thus, for example, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating the exemplary embodiments. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer.
- As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless expressly stated otherwise. It will be further understood that the terms “includes,” “comprises,” “including,” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being “connected” or “coupled” to another element, it can be directly connected or coupled to the other element or intervening elements may be present. Furthermore, “connected” or “coupled” as used herein may include wirelessly connected or coupled. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
- It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first device could be termed a second device, and, similarly, a second device could be termed a first device without departing from the teachings of the disclosure.
-
FIG. 1 is a simplified schematic illustrating an environment in which exemplary embodiments may be implemented.FIG. 1 illustrates amobile device 20 having adisplay device 22. Themobile device 20, for simplicity, is illustrated as asmart phone 24, but themobile device 20 may be any mobile or stationary processor-controlled device (as later paragraphs will explain). Thedisplay device 22 displays ahome screen 26 withicons 28. Eachicon 28 typically corresponds to one ofseveral software applications 30 executed by themobile device 20. Thedisplay device 22 may be a touch screen, thus allowing the user to touch, tap, or otherwise select anyicon 28. Should the user select one of theicons 28, themobile device 20 launches, resumes, or calls thecorresponding software application 30. As iconic representation is well known, this disclosure need not provide a detailed explanation. - Exemplary embodiments may automatically rearrange the
icons 28. As the user carries themobile device 20,various conditions 40 are sensed or determined. Theicons 28 may then be rearranged on thehome screen 26, according to theconditions 40. For example, exemplary embodiments may rearrange theicons 28 according totime 42,location 44, and/orstate 46 of mobility. At acertain time 42 of day, for example, one of thesoftware applications 30 may be preferred, based on historical use. At aparticular location 44, another one of thesoftware applications 30 may be preferred. When themobile device 20 travels, thestate 46 of mobility may force some of thesoftware applications 30 to be unavailable, whileother software applications 30 may be brought to thehome screen 26. So, as theconditions 40 change throughout the day, exemplary embodiments determine which of thesoftware applications 30 is preferred, and the corresponding icon(s) 28 may be promoted for display by thehome screen 26. The user may thus have quick access to thepreferred icon 28 without fumbling through secondary screens. - Demotion may be required. Sometimes there are
more icons 28 that can be displayed on thehome screen 26. When themobile device 20 stores or accessesmany software applications 30, there may be toomany icons 28 to simultaneously display on thesingle home screen 26. Themobile device 20 may thus generate and store one or moresecondary screens 48 that, when selected, display remaining ones of theicons 28. So, when apreferred icon 28 is promoted to thehome screen 26, one or more remainingicons 28 may be removed from thehome screen 26. That is, someicons 28 may be demoted to thesecondary screens 48. - The
home screen 26 may thus intelligently adapt to theconditions 40. As the user carries themobile device 20, themobile device 20 evaluates theconditions 40. Thehome screen 26 learns and adapts to the user, based on theconditions 40. Theicons 28 displayed on thehome screen 26 may thus be intelligently promoted and demoted according to theconditions 40. At anytime 42,location 44, and/orstate 46 of mobility, the user has quick and easy access to thecorresponding software applications 30. -
FIG. 2 is a more detailed block diagram illustrating the operating environment, according to exemplary embodiments. Themobile device 20 may have a processor 50 (e.g., “μP”), application specific integrated circuit (ASIC), or other component that executes analgorithm 52 stored in alocal memory 54. Thememory 54 may also store the software applications 30 (such as an SMS texting application, a call application, calendar application, and a web browser application). Thealgorithm 52 has instructions, code, and/or programs that may cause theprocessor 50 to generate aranking 56 of thesoftware applications 30, according to theconditions 40. When thedisplay device 22 displays thehome screen 26, thealgorithm 52 may also instruct theprocessor 50 to adapt the correspondingicons 28 according to theconditions 40. -
FIG. 3 is a schematic illustrating detection of theconditions 40, according to exemplary embodiments. Whenever themobile device 20 is powered on, thealgorithm 52 may obtain thetime 42 of day, thelocation 44, and thestate 46 of mobility. The home screen 26 (or user interface) is rarely used under the same conditions at all times and locations. Indeed, smartphones have become popular due to their flexibility and usefulness under most, if not all, of theconditions 40 the user experiences each day. This flexibility is primarily enabled by the variety of thesoftware applications 30 that may be stored and executed. Even though themobile device 20 has the flexibility to run manydifferent software applications 30, eachspecific software application 30 may only be useful, or safe, for a narrow subset of theconditions 40. For example, a GPS-based navigation application may be useful when driving, but GPS signals are usually not received indoors and useless when stationary. Likewise, an email client may be useful when stationary, but useless and unsafe when driving. Social networking applications are typically useful when at home during non-work hours, but generally used less at work during the day. Exemplary embodiments, then, detect theconditions 40 in which themobile device 20 and/or any of thesoftware applications 30 are used. - The
algorithm 52 thus acquires thetime 42 and thelocation 44. Thetime 42 may be determined from a clock signal, from a network signal, or from any known method. Thetime 42 may also be retrieved from a calendar application. Thetime 42 may be expressed along with the current day, month, and year. Thelocation 44 is commonly determined from a global positioning system (“GPS”) receiver, but thelocation 44 may be determined from WI-FI® access points, network identifiers, and/or any known method. - The
time 42 and thelocation 44 may be adaptively combined. Thealgorithm 52 may determine themobile device 20 is currently at the “home”location 44 based on detection of a residential network, along with morning or night hours. A “work”location 44 may be determined from detection of an office network, along with weekday daytime hours (e.g., 9 AM to 5 PM). Thealgorithm 52 may also distinguish between a “home” and a “visiting” market, perhaps again based on radio network identifiers (e.g., LTE tracking area or UMTS Location Area). Should thealgorithm 52 detect a never-before seen tracking area, thealgorithm 52 may assume themobile device 20 is located in a non-home, visiting market. Thealgorithm 52 may also generate a prompt on thedisplay device 22, asking the user to confirm or input thetime 42 and/or thelocation 44. - BLUETOOTH® pairing may also be used. When the
mobile device 20 is operating in an automobile, themobile device 20 may electronically pair, mate, or interface with a BLUETOOTH® transceiver for hands-free operation. If themobile device 20 automatically pairs with the automobile, thealgorithm 52 may assume the user is the driver of the automobile. Conversely, if themobile device 20 is manually paired with the automobile, thealgorithm 52 may assume the user is the passenger of the automobile. That is, automatic or manual pairing may determine whether the user is the driver or the passenger. Thealgorithm 52 may thus adapt thehome screen 26 according to whether themobile device 20 is used by the driver or the passenger. - Exemplary embodiments also determine the
state 46 of mobility. Thestate 46 of mobility may be determined from information received from the global positioning system (“GPS”) receiver (such as GPS information or coordinates 60). However, thestate 46 of mobility may also be determined using sensor output from anaccelerometer 62 and/or from akinetic generator 64. As the user carries themobile device 20, theaccelerometer 62 and/or thekinetic generator 64 senses different levels or measurements ofvibration 66. Thevibration 66 may be random or cyclic motion, perhaps in one or more axes. Regardless, theaccelerometer 62 and/or thekinetic generator 64 outputs a digital or analog signal (e.g., amplitude, frequency, voltage, current, pulse width) that is indicative of thevibration 66 during use of themobile device 20. Thealgorithm 52 may use any parameter of the signal as an indication of thevibration 66 to determine thestate 46 of mobility. - The
kinetic generator 64 may detect thevibration 66. Thekinetic generator 64 is any device that converts thevibration 66, or any motion, to electric current. Thekinetic generator 64, for example, may be mechanical, piezoelectric, chemical, or any other technology. - Output from a
microphone 68 may also be used. Themobile device 20 may have themicrophone 68 to receive audible sounds and to output signals indicative of the sounds. As the user carries themobile device 20, thealgorithm 52 may use the output from themicrophone 68 to further determine thestate 46 of mobility. For example, thealgorithm 52 may determine thestate 46 of mobility as stationary, in response to little to novibration 66 compared to a threshold value for stationary positions. Thestate 46 of mobility may be determined as walking, in response to thevibration 66 greater than some other threshold for human walking. Moreover, a frequency of thevibration 66 may also be compared to a threshold frequency for the walking determination. Vehicular movement may be determined in response to random frequencies of thevibration 66, perhaps coupled with known, low frequency road noises received by themicrophone 68. -
FIG. 4 is a schematic illustratingoperational states 80, according to exemplary embodiments. Once thealgorithm 52 determines the one ormore conditions 40, the algorithm determines theoperational state 80 for themobile device 20. That is, thealgorithm 52 analyzes the conditions 40 (e.g., thetime 42 of day, thelocation 44, and thestate 46 of mobility) and concludes how best to characterize theoperational state 80 for themobile device 20. For example, thealgorithm 52 may query adatabase 82 of operational states.FIG. 4 illustrates thedatabase 82 of operational states as a table 84 that maps, relates, or associates different combinations of theconditions 40 to differentoperational states 80. Thedatabase 82 of operational states stores different operational states for different combinations of the conditions 40 (e.g., thetime 42, thelocation 44, and/or thestate 46 of mobility). Thedatabase 82 of operational states may thus be populated with entries for manydifferent conditions 40 and their corresponding operational states 80. WhileFIG. 4 only illustrates a few entries, in practice thedatabase 82 of operational states may contain hundreds, perhaps thousands, of entries. A simple, partial listing of someoperational states 80 is provided below: -
- morning home stationary,
- evening home stationary,
- weekend home stationary,
- work home stationary,
- work office stationary,
- work home market driving,
- work visiting market driving,
- non-work home market driving,
- non-work visiting market driving,
- work home market passenger,
- non-work visiting market passenger,
- non-work home market walking, and/or
- non-work visiting market walking.
There may be many otheroperational states 80, depending on how theconditions 40 are categorized, valued, or delineated. Once thealgorithm 52 determines theconditions 40, thealgorithm 52 queries thedatabase 82 of operational states for theconditions 40. If theconditions 40 match one of the entries in thedatabase 82 of operational states, thealgorithm 52 retrieves the correspondingoperational state 80.
-
FIG. 5 is a schematic illustrating adatabase 90 of iconic arrangements, according to exemplary embodiments. Once thealgorithm 52 determines theoperational state 80, thealgorithm 52 may then consult thedatabase 90 of iconic arrangements. Thedatabase 90 of iconic arrangements storesiconic arrangements 92 for theicons 28 on thehome screen 26 for differentoperational states 80.FIG. 5 , for example, illustrates thedatabase 90 of iconic arrangements as a table 94 that maps, relates, or associates the differentoperational states 80 to their correspondingiconic arrangement 92. Each entry in thedatabase 90 of iconic arrangements may thus be populated with adifferent arrangement 92 for theicons 28 on thehome screen 26, depending upon the correspondingoperational state 80. Once thealgorithm 52 determines theoperational state 80, thealgorithm 52 may query thedatabase 90 of iconic arrangements for theoperational state 80. If theoperational state 80 of themobile device 20 matches one of the entries in thedatabase 90 of iconic arrangements, thealgorithm 52 retrieves thecorresponding arrangement 92 for theicons 28 in thehome screen 26. WhileFIG. 5 only illustrates a few entries, in practice thedatabase 90 of iconic arrangements may contain many entries. - The
algorithm 52 then adapts thehome screen 26. Once thearrangement 92 is retrieved for theoperational state 80, thealgorithm 52 then moves theicons 28 on thehome screen 26. That is, someicons 28 may be demoted from thehome screen 26, andother icons 28 may be promoted to the home screen 26 (as earlier paragraphs explained). Thealgorithm 52 automatically rearranges theicons 28 to suit theoperational state 80 of themobile device 20. Should theoperational state 80 again change, thealgorithm 52 may again reconfigure theicons 28 to suit some newoperational state 80. -
FIG. 6 is a schematic illustrating alog 100 of usage, according to exemplary embodiments. As themobile device 20 is used, thealgorithm 52 may store usage information in thelog 100 of usage. Thealgorithm 52, for example, may observe and record whichsoftware applications 30 are used for any combination of the conditions 40 (e.g., thetime 42 of day, thelocation 44, and thestate 46 of mobility). Over time thealgorithm 52 learns which ones of thesoftware applications 30 are used most often for eachcondition 40. For example, thealgorithm 52 may monitor how often eachsoftware application 30 is started, how often eachsoftware application 30 is moved to thehome screen 26, and/or how long eachsoftware application 30 remains on thehome screen 26 for eachcondition 40. Thealgorithm 52 thus logs usage for the differentoperational states 80 of themobile device 20. -
FIG. 7 is a schematic illustrating alearning mode 110 for themobile device 20, according to exemplary embodiments. Once thelog 100 of usage is built over time, thealgorithm 52 may self-configure theicons 28 on thehome screen 26. That is, thealgorithm 52 may intelligently learn the user's iconic preferences for the differentoperational states 80. Even though themobile device 20 may have thearrangements 92 pre-stored or pre-determined (as explained with reference toFIG. 5 ), thealgorithm 52 may tailor theiconic arrangement 92 to best suit the user's personal usage habits. As thelog 100 of usage is built, thealgorithm 52 may record whichsoftware applications 30 are preferred for thedifferent conditions 40. Thealgorithm 52 may thus tally the usage information and learn what software applications the user prefers for the differentoperational states 80. Thealgorithm 52 may then self-determine thearrangement 92 of the icons on thehome screen 26, in response to the usage information in thelog 100 of usage. That is, thealgorithm 52 may configure theicons 28 for a user-friendly home screen 26, according to theoperational state 80. Again, thealgorithm 52 may arrange theapplication icons 28 so that the most frequently usedsoftware applications 30 are prominently placed on thehome screen 26. Lesser-usedicons 28 may be removed from thehome screen 26 and demoted to thesecondary screen 48. -
FIG. 8 is a schematic illustrating ahome button 120 on themobile device 20, according to exemplary embodiments. When the user touches or depresses thehome button 120, themobile device 20 displays thehome screen 26. While thehome button 120 may be located at any location on themobile device 20,FIG. 8 illustrates thehome button 120 on a front face of thesmart phone 24. - Exemplary embodiments may cluster the
icons 28. As thealgorithm 52 learns the user's preferences, thealgorithm 52 may arrange theicons 28 about thehome button 120. That is, once thealgorithm 52 determines the most frequently used software application(s) 30 during theoperational state 80, thealgorithm 52 may arrange the correspondingicons 28 around thehome button 120. So, not only are thepopular icons 28 promoted to thehome screen 26, but thepopular icons 28 may also be clustered around thehome button 120. Thepopular icons 28 during theoperational state 80 are thus arranged for easy access about thehome button 120. -
FIG. 8 thus illustrates agrid 122 of theicons 28. Once theicons 28 for thehome screen 26 are determined (according to the operational state 80), thealgorithm 52 may arrange theapplication icons 28 on thehome screen 26.FIG. 8 illustrates theapplication icons 28 arranged in thegrid 122, with eachindividual icon 28 having a row and column position. Each position in thegrid 122 corresponds to a rank in theranking 56. That is, once thealgorithm 52 determines whichicons 28 are promoted to thehome screen 26, thealgorithm 52 may further generate assign theicon 28 to a position in thegrid 122, according to theranking 56. - The ranking 56 may start near the
home button 120. As theapplication icons 28 are ranked, the mostpopular icons 28 may be reserved for positions closest to thehome button 120. That is, a first position in theranking 56 may correspond to one of the row/column positions that is closest to thehome button 120. Consider, for example, when theoperational state 80 is “morning home stationary,” the user may popularly text with friends and workers. Atext messaging icon 28, then, may be assigned the first position in thegrid 122. Next popular may be a news-feed application, which is assigned a second position in thegrid 122. The third mostpopular application icon 28 is assigned a fourth position, a fifth mostpopular application icon 28 is assigned a fifth position, and so on. Theapplication icons 28 may thus be arranged according to theranking 56, with the more popularsoftware application icons 28 reserved for the closest positions to thehome button 120. Because theicons 28 are positioned near thehome button 120, the icons are within easy reach of the user's thumb (as later paragraphs will explain). -
FIGS. 9-10 are schematics illustrating radial distances from thehome button 120, according to exemplary embodiments. Here, thealgorithm 52 generates theranking 56 of thesoftware applications 30, and the correspondingicons 28 are still clustered about thehome button 120. Yet, here theicons 28 are arranged according to a radial distance from thehome button 120. That is, the mostpopular icons 28 may be reserved for positions in anarc 130 that are closest to thehome button 120. Thearc 130 has a corresponding radius Rarc (illustrated as reference numeral 132) about which theicons 28 are aligned. Theradius 132 may be determined from thehome button 120. AsFIG. 10 illustrates, lesspopular icons 134 may be aligned on asecond arc 136 that corresponds to a greater,second radius 138. The leastpopular icons 140 may be aligned on athird arc 142 that corresponds to a still greater,third radius 144. Exemplary embodiments may thus rank and arrange theicons 28 about successive radial arcs from thehome button 120. This radial arrangement positions theicons 28 near thehome button 120, within easy reach of the user's thumb. -
FIGS. 11-14 are schematics illustrating athumb radius 150, according to exemplary embodiments. As the reader will recognize,FIG. 11 illustrates one-handed operation of thesmart phone 24. Thesmart phone 24 is held in a portrait orientation and cradled in a palm of the user's hand. The user'sthumb 152 reaches to select theicons 28 on thehome screen 26. Here, though, theapplication icons 28 may be radially arranged with respect to thethumb radius 150 of the user'sthumb 152. The rankedicons 28 may thus be positioned to always be within easy reach of the user'sthumb 152. -
FIG. 11 thus illustrates another radial arrangement of theicons 28. Theicons 28 may again be positioned along thearc 130. Here, though, the user'sthumb radius 150 determines thearc 130. Even though one-handed operation is common, different people's hands come in different sizes. That is, our hands are not equal in size. So, the radial arrangement of theicons 28 may be adjusted to suit the length of the user'sthumb 152. -
FIG. 12 also illustrates thethumb radius 150. Once thealgorithm 52 determines whichicons 28 should be displayed (according to the operational state 80), thealgorithm 52 positions theicons 28 on thehome screen 26. Thealgorithm 52 retrieves the user'sthumb radius 150 from thememory 54, mathematically plots thearc 130, and aligns theicons 28 to thearc 130. Theicons 28 for theoperational state 80 are thus radially aligned within easy reach of the user's thumb (illustrated asreference numeral 152 inFIG. 11 ). -
FIGS. 11 and 12 also illustrates anorigin 154 for thethumb radius 150. Theorigin 154 is a reference position from which thearc 130 is centered. That is, the user'sthumb radius 150 is calculated from theorigin 154, thus determining where on thehome screen 26 that theicons 28 are radially aligned. Theorigin 154 may thus be selected by the user to ensure the radial alignment coincides with the user'sthumb 152. Exemplary embodiments, then, may permit the user to select theorigin 154 from which thearc 130 is defined. The user, for example, may touch or tap a location on the home screen 26 (if touch sensored) to define theorigin 154. The user may specify coordinates on thehome screen 26 for theorigin 154. Touch sensors on a body or shell of themobile device 20 may even determine theorigin 154, as themobile device 20 is held in the user's hand. Regardless, the user may personalize the radial arrangement to suit her one-handed operation. -
FIG. 13 illustrates measurement of the user'sthumb radius 150. Before theicons 28 may be radially arranged with respect to the user's thumb (asFIGS. 11-12 illustrated), the length of the user'sthumb 152 may be needed. Thealgorithm 52 may present a prompt 160 for measuring the user'sthumb radius 150. The prompt 160 instructs the user to place her thumb on thedisplay device 22. Thealgorithm 52 may then cause themobile device 20 to capture a full-size image of the user'sthumb 152, from which thethumb radius 150 is determined by image analysis. Alternatively, if themobile device 20 includes a touch screen, thealgorithm 52 may use pressure points or inputs to detect the length of the user'sthumb 152. Exemplary embodiments, however, may use any measures of measuring the length of the user'sthumb 152, including manual entry. Regardless, once the user'sthumb radius 150 is known, thealgorithm 52 may use thethumb radius 152 to align the icons (as earlier paragraphs explained). -
FIG. 14 also illustrates radial alignment from thehome button 120. Here, though, theicons 28 may be radially arranged from thehome button 120, according to the user'sthumb radius 150. Thealgorithm 52 retrieves the user'sthumb radius 150 and aligns the mostpopular icons 28 within thearc 130 defined by thethumb radius 150 from thehome button 120. As such, the mostpopular icons 28 are within easy reach of the user's thumb during single-handed use. Exemplary embodiments may even arrange theicons 28 along multiple arcs (as explained with reference toFIG. 10 ). Some of the multiple arcs may have a radius less than or equal to the user'sthumb radius 150, measured from thehome button 120. Lesspopular icons 28, or even least popular icons, may be arranged along an arc having a radius greater than the user'sthumb radius 150 from thehome button 120. Thepopular icons 28, in other words, may be arranged within easy reach of thehome button 120, but lesspopular icons 28 may be positioned beyond the user'sthumb radius 150. -
FIG. 15 is a schematic illustrating alandscape orientation 170, according to exemplary embodiments. As the reader understands, themobile device 20 may be oriented for two-handed operation. When themobile device 20 is held in thelandscape orientation 170, theapplication icons 28 may be arranged within easy reach of the user's left thumb and/or the user's right thumb. That is, as theranking 56 is generated, some of theapplication icons 28 may be arranged within aleft thumb radius 172.Other icons 28 may be arranged within aright thumb radius 174. If the user is right-handed, for example, the mostpopular icons 28 may be clustered within theright thumb radius 174 about aright corner 176 of thedisplay device 22. Lesspopular icons 28 may be arranged within theleft thumb radius 172 about aleft corner 178 of thedisplay device 22. A left-handed user, of course, may prefer a vice versa arrangement. Regardless, theicons 28 may be arranged withinarcs -
FIGS. 16-17 are schematics further illustrating the learningmode 110 for themobile device 20, according to exemplary embodiments. As thelog 100 of usage is built over time, thealgorithm 52 may further record aselection area 190 for eachicon 28. That is, when anyicon 28 is selected, thealgorithm 52 may record whether themobile device 20 was in thelandscape orientation 170 or in theportrait orientation 192. Theselection area 190 may also record a quadrant, zone, or region of thehome screen 26 from which theicon 28 was selected. Theselection area 190 thus allows thealgorithm 52 to infer whether the user's left thumb or right thumb made the selection. For example, if theicon 28 is selected from the lower right corner portion of thehome screen 26, then thealgorithm 52 may determine that the user's right thumb likely made the selection. If theicon 28 is selected from the lower left corner portion of thehome screen 26, then thealgorithm 52 may determine that the user's left thumb made the selection. That is, thealgorithm 52 may associate ahandedness 194 with eachicon 28 recorded in thelog 100 of usage. -
FIG. 17 further illustrates the iconic arrangement. When themobile device 20 is held in thelandscape orientation 170, theapplication icons 28 may be arranged according to thehandedness 194. Once thealgorithm 52 generates theranking 56 for the correspondingoperational state 80, theapplication icons 28 may be arranged according to theranking 56 and clustered according to thehandedness 194. For example, the mostpopular icons 28 with right-handedness 194 may be arranged within theright thumb radius 174 about theright bottom corner 176 of thehome screen 26. The mostpopular icons 28 with left-handedness 194 may be arranged within theleft thumb radius 172 about theleft bottom corner 178 of thehome screen 26. Once again, then, theicons 28 may be arranged within thearcs - Some examples of the ranked
icons 28 are provided. Consider, for example, that somesoftware applications 30 may be unsafe for someoperational states 80. When thealgorithm 52 determines theoperational state 80 involves driving, some software applications 30 (such as email and text) may be categorized as unsafe or even prohibited. Thealgorithm 52, then, may deliberately demote thecorresponding application icons 28 to thesecondary screen 48.Other software applications 30, however, may be categorized as safe driving enablers, such as voice control and telephony applications. The correspondingsafe application icons 28 may be promoted to prominent, high-ranking positions on thehome screen 26. -
FIG. 18 is a schematic further illustrating thedatabase 90 of iconic arrangements, according to exemplary embodiments.FIG. 18 again illustrates thedatabase 90 of iconic arrangements as the table 94 that associates the differentoperational states 80 to their correspondingiconic arrangements 92. Here, though, theiconic arrangements 92 may be augmented with and thepositional ranking 200. That is, once thesoftware applications 30 are ranked, thealgorithm 52 may assign iconic positions on thehome screen 26. Eachicon 28 may have itspositional ranking 200 expressed as the row and column (as explained with reference toFIG. 8 ). Eachicon 28, however, may also be radially arranged with respect to the home button 12 and/or the user's thumb radius 150 (as explained with reference toFIGS. 9-17 ). ReferencingFIG. 18 , theoperational state 80 of “morning home stationary” has an alarm clock icon at positional ranking “P1” and a news icon at positional ranking “P2.” A weather icon is moved to positional ranking “P5.”FIG. 18 thus illustrates examples of entries in thedatabase 90 of iconic arrangements. Again,FIG. 18 only illustrates several entries. In practice thedatabase 90 of iconic arrangements may contain hundreds, perhaps thousands, of entries. - The
algorithm 52 thus dynamically builds thehome screen 26. Any time theoperational state 80 changes, thehome screen 26 may adapt throughout the day asoperational states 80 change. For example, should themobile device 20 pair with a BLUETOOTH® interface (perhaps for hands-free operation in a vehicle), and/or detect the vibration (as explained with reference toFIG. 3 ), thealgorithm 52 may reconfigure thehome screen 26. That is, thehome screen 26 may change from a “morning home stationary”arrangement 92 to a “non□work home market driving”arrangement 92. Should an office WI-FI® network be detected, perhaps without low-frequency vehicular sounds and thevibration 66, then thealgorithm 52 may further change thehome screen 26 to a “work office stationary”arrangement 92. Should themobile device 20 again pair with the BLUETOOTH® interface (again for hands-free operation in a vehicle), and/or detect once again detectvibration 66, then thealgorithm 52 may again change thehome screen 26 to a “non□work home market driving”arrangement 92. If a home network is detected (perhaps from a home FEMTO identifier), perhaps without recognizedvehicular vibration 66 and low-frequency sounds, thehome screen 26 may reconfigure to an “evening home stationary”arrangement 92. Finally, in the evening of the day, thehome screen 26 may reconfigure to a “non-work home market walking”arrangement 92 in response to slow,cyclic vibration 66 while the user walks a dog, and the home FEMTO is out of range. While only these few examples are provided, many more combinations are possible, depending on the operational states 80. -
FIG. 19 is a graphical illustration of a three-dimensional mapping 210 of theconditions 40, according to exemplary embodiments. While thealgorithm 52 may dynamically arrange theicons 28 based on only one of theconditions 40, exemplary embodiments may dynamically arrange based on any combination of thetime 42 of day, thelocation 44, and thestate 46 of mobility.FIG. 19 thus illustrates the three-dimensional mapping 210 of theconditions 40. As this disclosure above explains, theicons 28 on thehome screen 26 are rarely used under thesame conditions 40. Eachspecific software application 30 may only be useful for certain combinations of theconditions 40. Exemplary embodiments, then, detect theconditions 40 and consult the three-dimensional mapping 210 to determine theoperational state 80. -
FIG. 19 thus graphs theconditions 40. The different conditions 40 (e.g., thetime 42 of day, thelocation 44, and thestate 46 of mobility) may be plotted along different orthogonal coordinate axes. Thelocation 44 may be quantified from some reference location, such as the distance from the user′ home address. Once thealgorithm 52 determines thetime 42 of day, thelocation 44, and thestate 46 of mobility, thealgorithm 52 consults the three-dimensional mapping 210. One ormore state functions 212 may be defined to determine theoperational state 80. That is, thestate function 212 may be expressed as some function of thetime 42, thelocation 44, and thestate 46 of mobility. Different three-dimensionalgeometrical regions 214 of the three-dimensional mapping 210 may also define different, corresponding operational states 80. When the current thetime 42 of day, thelocation 44, and thestate 46 of mobility are plotted, the final coordinate location is matched to one of thegeometrical regions 214 to determine theoperational state 80. Regardless, thealgorithm 52 may consult the three-dimensional mapping 210 for thetime 42 of day, thelocation 44, and/or thestate 46 of mobility. Thealgorithm 52 retrieves the correspondingoperational state 80 and then determines the arrangement 92 (as earlier paragraphs explained). -
FIGS. 20-21 are schematics further illustrating thehandedness 194, according to exemplary embodiments. Here theapplication icons 28 displayed on thehome screen 26 may be configured for right-hand operation 220 or for left-hand operation 222. That is, theicons 28 may be rearranged for left hand use or for right hand use. A left-handed user, for example, may have difficulty reaching, or selecting, anicon 28 arranged outside theleft thumb radius 172. Similarly, a right-handed user likely has difficulty selecting icons positioned beyond theright thumb radius 174. These difficulties may be especially acute for larger display screens held in smaller hands. Over-extension may produce very different experiences between left- and right-handed users. Most users, in other words, may be dissatisfied with the sameiconic arrangement 92. - Exemplary embodiments may thus adapt to the
handedness 194. As themobile device 20 is held, thealgorithm 52 may detect whether themobile device 20 is held in the user's right hand or in the user's left hand. Thealgorithm 52 may then arrange theicons 28 on thehome screen 26 to suit the right-handed operation 220 or the left-hand operation 222. When themobile device 20 is held in the right hand, thealgorithm 52 may cluster or arrange higher-rankingicons 28 to the user's right thumb. Conversely, the higher-rankingicons 28 may be arranged to the user's left thumb for the left-hand operation 222. -
FIG. 20 illustratestouch sensors 224. Thetouch sensors 224 detect the number and locations of contact points with the user's fingers and thumb. As themobile device 20 is held, the user's fingers and thumb grasp and cradle themobile device 20. Thetouch sensors 224 detect the number and pattern of contact points between the hand and themobile device 20. While thetouch sensors 224 may be located anywhere on themobile device 20,FIG. 20 illustrates thetouch sensors 224 along left and right sides. The number of the contact points, and the pattern of those contact points, may thus be used to determine the right-handed operation 220 or the left-hand operation 222. For example, when themobile device 20 is held in the user's left hand, thetouch sensors 224 may detect the user's palm as a left-side, single, wide contact point. Thetouch sensors 224 may also detect the user's left fingers as two or more narrow contact points on the right side of themobile device 20. Should themobile device 20 be held in the right hand, the user's palm appears as a single, wide contact point on the right and the fingers appear as two or more narrow contact points on the left. - Exemplary embodiments may then arrange the
icons 28. Thealgorithm 52 determines theoperational state 80 and retrieves thecorresponding arrangement 92. However, thealgorithm 52 may then adapt thearrangement 92 according to thehandedness 194. If the left-hand operation 222 is determined, theicons 28 may be arranged about the user's left thumb. That is, theicons 28 may be arranged within the user's left thumb radius 172 (as explained with reference toFIGS. 15-17 ). If the right-handed operation 220 is determined, theicons 28 may be arranged within the user's right thumb radius 174 (again as explained with reference toFIGS. 15-17 ). Exemplary embodiments may thus rearrange thehome screen 26 such that higher-rankingicons 28 are closest to the user's preferred thumb for easy selection. -
FIG. 20 illustrates an arrangement for morning habits. If theoperational state 80 is “morning home stationary,” an alarm clock application may be high ranking. Exemplary embodiments may thus position thecorresponding application icon 28 in the bottomleft corner 178 for the left-hand operation 222. This position puts the high-rankingicon 28 within easy reach of the user's left thumb. A right-handed user, however, may prefer theicon 28 in the bottomright hand corner 176 for the right-handed operation 220. Moreover, this positioning also reduces the area over which thedisplay device 22 is blocked by the user's thumb. As the user's thumb reaches to select theicons 28, the user's thumb and/or hand may block significant portions of thedisplay device 22. Positioning according to thehandedness 194 may thus improve visibility and reduce incorrect or accidental selection of thewrong icon 28. -
FIG. 21 is another schematic illustrating thedatabase 90 of iconic arrangements, according to exemplary embodiments. Thedatabase 90 of iconic arrangements again associates the differentoperational states 80 to their correspondingiconic arrangements 92. Here, though, theiconic arrangements 92 may be augmented with thehandedness 194. Thealgorithm 52 queries the table 94 for theoperational state 80 and retrieves the correspondingiconic arrangement 92 of thehome screen 26, along with thehandedness 194. Thealgorithm 52 then arranges theicons 28 on thehome screen 26, as this disclosure explains. - The
algorithm 52 will improve with time. As thealgorithm 52 gains experience with the user, thealgorithm 52 may determine that the user always, or usually, prefers the right-handed operation 220 or the left-hand operation 222. Theicons 28 on thehome screen 26 may thus be arranged according tohabitual handedness 194. Thealgorithm 52, of course, may determine how themobile device 20 is currently held and adapt to thecurrent handedness 194. Even though the left-hand operation 222 may be habitually preferred, theicons 28 may be rearranged when currently held in the user's right hand. -
FIGS. 22-24 are schematics illustrating adaptation of sizing, according to exemplary embodiments. Here asize 230 of anicon 28 may adapt, according to theoperational state 80. That is, thesize 230 of any of theicons 28 may increase, or decrease, in response to theoperational state 80. High-rankingicons 28, for example, may have alarger size 230 than lesser rankingicons 28. Indeed, the highest-ranking icon 28 (perhaps representing a most popular software application 30) may be sized greater than allother icons 28 displayed by thehome screen 26. Rarely usedicons 28 may be reduced in thesize 230, thus allowing thehome screen 26 to be dominated by thepopular icons 28. - The
size 230 of anindividual icon 28 may determine its user friendliness. Screen size, resolution, and user dexterity are among the various factors that limit the number and user-friendliness of theapplication icons 28 that can fit on thehome screen 26. Indeed, with thesmall display device 22 of thesmart phone 24, user friendliness becomes even more of an important consideration. For example, small sizes for theicons 28 may be well suited for stationary use (e.g., when themobile device 20 and user are not separately moving or shaking). However, small sizes for theicons 28 are not suited during mobile situations when the user and themobile device 20 are separately moving or shaking. Thestate 46 of mobility, in other words, may cause small icons to be difficult to read and select. Accidental, unwanted selection of an adjacent icon often results. - Sizing may thus adapt. When the
algorithm 52 determines the operational state 80 (from the conditions 40), thealgorithm 52 retrieves thecorresponding arrangement 92. However, thealgorithm 52 may also adapt thesize 230 of anyicon 28 according to theoperational state 80. For example, if the user is walking, thealgorithm 52 may enlarge the four (4)highest ranking 56, mostimportant application icons 28. Indeed,lesser ranking 56 and even rarely usedicons 28 may be demoted to thesecondary screen 48. As only the highest-rankingicons 28 need be displayed, thealgorithm 52 may enlarge the four (4)icons 28 to consume most of thehome screen 26. This enlargement allows reliable selection, despite thestate 46 of mobility. Indeed, even spacing between theicons 28 may be adjusted, based on theoperational state 80. Should themobile device 20 be nearly stationary, conversely smaller-sized icons 28 may be adequate, thus allowing more icons to be simultaneously displayed by thehome screen 26. -
FIG. 23 illustrates text sizing. Here, anytext 232 displayed on thehome screen 26 may be sized according to theoperational state 80. Fonts may be enlarged, or decreased, in response to theoperational state 80. For example, weather information may be enlarged in someoperational states 80 and reduced in others. Similarly, a time display may be enlarged in someoperational states 80 and reduced in others. SMS text messages may be enlarged for easier reading, even though a response text may be prohibited (perhaps when driving). Whatever thetext 232, thetext 232 may be sized according to theoperational state 80. -
FIG. 24 is another schematic illustrating thedatabase 90 of iconic arrangements. Thedatabase 90 of iconic arrangements again associates the differentoperational states 80 to their correspondingiconic arrangements 92. Here, though, theiconic arrangements 92 may be augmented with sizingadaptations 234. Thealgorithm 52 may size 230 theicons 28 and thetext 232 according to theoperational state 80. Thealgorithm 52 queries the table 94 for theoperational state 80 and retrieves the correspondingiconic arrangement 92 with the sizingadaptations 234. Thealgorithm 52 then dynamically arranges and sizes theicons 28 and thetext 232, as this disclosure explains. Large sizing of theicons 28 and thetext 232 enable reliable use where mobility and vibration impact readability and selectability. The risk of incorrect selections and distractions whilst driving is thus reduced. Small sizing, on the other hand, enables comprehensive and flexible use where mobility and vibration may not impact safety, readability and selectability. Thealgorithm 52 also removes the hassle associated with manually adapting thehome screen 26. -
FIGS. 25-26 are schematics illustrating adaptation of anaddress book 240, according to exemplary embodiments. Here the user'saddress book 240 may adapt, according to theoperational state 80. As theoperational state 80 changes, the user'saddress book 240 may sort its contacts entries according to thetime 42 of day, thelocation 44, and thestate 46 of mobility. Thesize 230 of thetext 232 may also adjust, according to theoperational state 80. As the reader likely understands, one of thesoftware applications 30 is theelectronic address book 240 that stores voice, text, and other contacts. Themobile device 20 may store many, perhaps hundreds, of contact entries in theaddress book 240. Themobile device 20 may thus store many email addresses, phone numbers, street addresses, and even notes regarding the many contact entries. Themobile device 20 may thus sort and display theaddress book 240 with entries that are easy to see, reach, and select on a single screen. With this in mind, conventional mobile devices commonly spread the user's contact entries over multiple screens, through which the user must scroll. - Exemplary embodiments, then, may be applied to the user's
address book 240. As the user carries themobile device 20 throughout the day, the user's needs and habits may change, according to theoperational state 80. For example, the user has very different visibility and calling habits when driving a vehicle on personal time, versus when the user is sitting in the office during the workday. As themobile device 20 is used, exemplary embodiments may record calling behaviors, texting behaviors, and the other usage information in thelog 100 of usage (as explained with reference toFIG. 5 ). Even though theaddress book 240 may store hundreds of contact entries, small sets of contacts are generally only useful for a narrow subset of conditions. For example, a work contact may be useful during workday hours, but the work contact may be unavailable outside those hours. Likewise, a subset of contacts is called and needed while driving, but perhaps not so important atother conditions 40. Thealgorithm 52 may thus intelligently adapt the user'saddress book 240 in order to improve the usability and safety. - The user's
address book 240 may thus intelligently adapt. Thealgorithm 52 determines the operational state 80 (from thetime 42 of day, thelocation 44, and thestate 46 of mobility). Over time thealgorithm 52 learns which contacts are used most often for each condition. For example, thealgorithm 52 learns how often each contact is called, how often each contact is texted, and/or how long any communication with each contact is displayed for each condition. Thealgorithm 52 thus determines which contacts are used most often for eachcondition 40. Thealgorithm 52 may then generateaddress favorites 242 for theoperational state 80. That is, thealgorithm 52 sorts and condenses the hundreds of entries in theaddress book 240 to only those contacts that are historically relevant to theoperational state 80. Thealgorithm 52 thus causes themobile device 20 to visually display (and/or audibly present) theaddress favorites 242 for theoperational state 80. For example, the most frequently used contacts may be positioned closest to the user's preferred thumb (as earlier paragraphs explained). Lesser-used contacts may be positioned further from the user's thumb or even demoted to thesecondary screen 48. If theoperational state 80 warrants, some contacts may be categorized, such as “unavailable after hours” and deliberately demoted to thesecondary screen 48. Other contacts, for example, may be categorized “safe driving enablers” (E911 and roadside assistance) and prominently positioned for close, quick selection. - Sizing and fonting may also be adapted. As this disclosure explains, the
size 230 of thetext 232 for any contact may also adjust, according to theoperational state 80. That is, once thealgorithm 52 generates theaddress favorites 242 for theoperational state 80, thefont size 230 of the contacts listing may be enlarged, or reduced, to suit thestate 46 of mobility and most likely contact use. For example, if the user is walking, thealgorithm 52 may enlarge the four (4) highest ranking, most important contact text lines to fill thehome screen 26. This textual enlargement enables reliable use where the relative position of themobile device 20 and user are constantly changing by large amounts. If themobile device 20 is stationary, the relative position of themobile device 20 and user does not relatively change, so more contacts may be displayed with smaller text on thesame home screen 26. If the user is driving, thealgorithm 52 may enlarge the six (6) most important contact text lines to fill thehome screen 26, thus enabling safer operation when required whilst driving. -
FIG. 26 illustrates theaddress favorites 242. As there may bedifferent address favorites 242 for differentoperational states 80, themobile device 20 may store associations in thememory 54. That is, theaddress favorites 242 may be stored in adatabase 250 of address favorites.FIG. 26 illustrates thedatabase 250 of address favorites as a table 252 that maps, relates, or associates the differentoperational states 80 to theircorresponding address favorites 242. Once thealgorithm 52 determines theoperational state 80, thealgorithm 52 queries thedatabase 250 of address favorites for theoperational state 80. If a match exists, thealgorithm 52 retrieves thecorresponding address favorites 242. AsFIG. 26 also illustrates, eachaddress favorite 242 may also include the sizingadaptations 234 for thetext 232 and thepositional ranking 200 for the location of the contacts. Thealgorithm 52 then positions theaddress favorites 242 to the user's desired location (such as thehome button 120 or the user's preferred thumb, as explained above). -
FIG. 27 is a schematic illustrating an alternate operating environment, according to exemplary embodiments. Here thedatabase 90 of iconic arrangements may be remotely stored and accessed from any location within anetwork 260. Thedatabase 90 of iconic arrangements, for example, may be stored in aserver 262. Once thealgorithm 52 determines theconditions 40, thealgorithm 52 instructs themobile device 20 to send a query to theserver 262. That is, themobile device 20 queries theserver 262 for theconditions 40. If a match is found, theserver 262 sends a response, and the response includes theoperational state 80. Remote, central storage relieves themobile device 20 from locally storing and maintaining thedatabase 90 of iconic arrangements. Similarly, any portion of the exemplary embodiments may be remotely stored and maintained to relieve local processing by themobile device 20. - Exemplary embodiments may be applied regardless of networking environment. Exemplary embodiments may be easily adapted to mobile devices having cellular, WI-FI®, and/or BLUETOOTH® capability. Exemplary embodiments may be applied to mobile devices utilizing any portion of the electromagnetic spectrum and any signaling standard (such as the IEEE 802 family of standards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band). Exemplary embodiments, however, may be applied to any processor-controlled device operating in the radio-frequency domain and/or the Internet Protocol (IP) domain. Exemplary embodiments may be applied to any processor-controlled device utilizing a distributed computing network, such as the Internet (sometimes alternatively known as the “World Wide Web”), an intranet, a local-area network (LAN), and/or a wide-area network (WAN). Exemplary embodiments may be applied to any processor-controlled device utilizing power line technologies, in which signals are communicated via electrical wiring. Indeed, exemplary embodiments may be applied regardless of physical componentry, physical configuration, or communications standard(s).
-
FIG. 28 is a schematic illustrating still more exemplary embodiments.FIG. 28 is a more detailed diagram illustrating a processor-controlleddevice 300. As earlier paragraphs explained, thealgorithm 52 may operate in any processor-controlled device.FIG. 28 , then, illustrates thealgorithm 52 stored in a memory subsystem of the processor-controlleddevice 300. One or more processors communicate with the memory subsystem and execute either, some, or all applications. Because the processor-controlleddevice 300 is well known to those of ordinary skill in the art, no further explanation is needed. -
FIG. 29 depicts other possible operating environments for additional aspects of the exemplary embodiments.FIG. 29 illustrates thealgorithm 52 operating within variousother devices 400.FIG. 29 , for example, illustrates that thealgorithm 52 may entirely or partially operate within a set-top box (“STB”) (402), a personal/digital video recorder (PVR/DVR) 404, a Global Positioning System (GPS)device 408, aninteractive television 410, atablet computer 412, or any computer system, communications device, or processor-controlled device utilizing theprocessor 50 and/or a digital signal processor (DP/DSP) 414. Thedevice 400 may also include watches, radios, vehicle electronics, clocks, printers, gateways, mobile/implantable medical devices, and other apparatuses and systems. Because the architecture and operating principles of thevarious devices 400 are well known, the hardware and software componentry of thevarious devices 400 are not further shown and described. - Exemplary embodiments may be physically embodied on or in a computer-readable storage medium. This computer-readable medium, for example, may include CD-ROM, DVD, tape, cassette, floppy disk, optical disk, memory card, memory drive, and large-capacity disks. This computer-readable medium, or media, could be distributed to end-subscribers, licensees, and assignees. A computer program product comprises processor-executable instructions for intelligent adaptation of icons, text, fonts, and address books, as the above paragraphs explained.
- While the exemplary embodiments have been described with respect to various features, aspects, and embodiments, those skilled and unskilled in the art will recognize the exemplary embodiments are not so limited. Other variations, modifications, and alternative embodiments may be made without departing from the spirit and scope of the exemplary embodiments.
Claims (20)
1. A method, comprising:
generating, by a sensor in a mobile device, an output in response to a vibrational input, the output indicating a measure of the vibrational input;
determining, by a processor in the mobile device, an operational state of the mobile device based on the measure of the vibrational input;
retrieving, by the processor, an address book having electronic database associations between different contact addresses to different operational states of the mobile device;
determining, by the processor, a contact address of the contact addresses in the address book that has an electronic database association with the operational state determined from the measure of the vibrational input, the measure of the vibrational input determining the contact address in the address book;
adjusting a display size of the contact address in accordance with the operational state determined from the measure of the vibrational input and an individual ranking associated with the contact address; and
displaying the contact address on a display device of the mobile device using the display size.
2. The method of claim 1 , further comprising:
associating the different contact addresses to different measures of the vibrational input.
3. The method of claim 2 , further comprising:
retrieving a position that is associated with the measure of the vibrational input;
and
positioning the contact address at the position on the display device.
4. The method of claim 3 , further comprising:
adjusting a font size of the contact address based on the position retrieved.
5. The method of claim 4 , wherein the adjusting the font size reduces a portion of the contact address.
6. The method of claim 4 , wherein the adjusting the font size enlarges a portion of the contact address.
7. The method of claim 1 , wherein the contact address is associated with a frequency of use.
8. The method of claim 1 , wherein the contact address is associated with a communication duration between a user of the mobile device and a contact associated with the contact address.
9. The method of claim 1 , further comprising:
ranking each contact address of the contact addresses, each contact address being associated with an individual rank.
10. The method of claim 9 , wherein the determining the contact address of the contact addresses uses the individual rank associated with the contact address to determine the contact address in the address book.
11. A system, comprising:
a processor; and
a memory storing instructions that when executed cause the processor to perform operations comprising:
receiving a sensor output generated in response to a measure of a vibrational input to a mobile device;
retrieving an address book having electronic database associations between different contact addresses to different measures of the vibrational input to the mobile device;
generating address favorites from the address book having the electronic database associations that match the measure of the vibrational input to the mobile device;
adjusting a display size of the address favorites in accordance with the measure of the vibrational input to the mobile device and an individual ranking associated with each of the address favorites; and
displaying the address favorites on a display device of the mobile device using the display size.
12. The system of claim 11 , wherein the operations further comprise:
retrieving a position that is associated with the measure of the vibrational input; and
positioning the address favorites at the position on the display device.
13. The system of claim 12 , wherein the operations further comprise:
adjusting a font size of particular ones of the address favorites based on the position retrieved.
14. The system of claim 13 , wherein the adjusting the font size of the particular ones of the address favorites reduces the font.
15. The system of claim 13 , wherein the adjusting the font size of the particular ones of the address favorites enlarges the font.
16. The system of claim 12 , wherein each address favorite is associated with a frequency of use.
17. The system of claim 11 , wherein the operations further comprise:
ranking the address favorites, each address favorite of the address favorites being associated with an individual rank.
18. A computer readable medium storing computer program instructions for an adaptable address book, which, when executed on a processor, cause the processor to perform operations comprising:
receiving a sensor output generated in response to a measure of a vibrational input to a mobile device;
retrieving the address book having electronic database associations between different contact addresses to different measures of the vibrational input to with the mobile device;
generating address favorites from the address book having the electronic database associations that match the measure of the vibrational input to the mobile device;
adjusting a display size of the address favorites in accordance with the measure of the vibrational input to the mobile device and an individual ranking associated with each of the address favorites; and
displaying the address favorites on a display device of the mobile device using the display size.
19. The computer readable medium of claim 18 , wherein the operations further comprise:
retrieving a position having one of the electronic database associations with the measure of the vibrational input; and
positioning the address favorites at the position on the display device.
20. The computer readable medium of claim 19 , wherein the operations further comprise:
ranking the address favorites, each address favorite of the address favorites being associated with an individual rank.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/918,855 US20160044150A1 (en) | 2013-09-25 | 2015-10-21 | Intelligent Adaptation of Address Books |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/036,030 US9204288B2 (en) | 2013-09-25 | 2013-09-25 | Intelligent adaptation of address books |
US14/918,855 US20160044150A1 (en) | 2013-09-25 | 2015-10-21 | Intelligent Adaptation of Address Books |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/036,030 Continuation US9204288B2 (en) | 2013-09-25 | 2013-09-25 | Intelligent adaptation of address books |
Publications (1)
Publication Number | Publication Date |
---|---|
US20160044150A1 true US20160044150A1 (en) | 2016-02-11 |
Family
ID=52691361
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/036,030 Expired - Fee Related US9204288B2 (en) | 2013-09-25 | 2013-09-25 | Intelligent adaptation of address books |
US14/918,855 Abandoned US20160044150A1 (en) | 2013-09-25 | 2015-10-21 | Intelligent Adaptation of Address Books |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/036,030 Expired - Fee Related US9204288B2 (en) | 2013-09-25 | 2013-09-25 | Intelligent adaptation of address books |
Country Status (1)
Country | Link |
---|---|
US (2) | US9204288B2 (en) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103595846A (en) * | 2012-08-17 | 2014-02-19 | 中兴通讯股份有限公司 | Mobile terminal address list sorting method and system |
US9588643B2 (en) * | 2014-12-18 | 2017-03-07 | Apple Inc. | Electronic devices with hand detection circuitry |
US10134368B2 (en) * | 2015-06-04 | 2018-11-20 | Paypal, Inc. | Movement based graphical user interface |
KR20170016752A (en) | 2015-08-04 | 2017-02-14 | 엘지전자 주식회사 | Mobile terminal and method for controlling the same |
CN108475495B (en) | 2016-02-12 | 2021-01-19 | 本田技研工业株式会社 | Image display device and image display method |
USD930676S1 (en) * | 2018-09-07 | 2021-09-14 | Samsung Display Co., Ltd. | Display device with generated image for display |
JP2022016943A (en) * | 2020-07-13 | 2022-01-25 | キヤノン株式会社 | Image processing device, control method of the same, and program |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6809724B1 (en) * | 2000-01-18 | 2004-10-26 | Seiko Epson Corporation | Display apparatus and portable information processing apparatus |
Family Cites Families (49)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2185099A (en) | 1998-03-05 | 1999-09-20 | Mitsubishi Denki Kabushiki Kaisha | Portable terminal |
US6538636B1 (en) | 1999-07-06 | 2003-03-25 | Intel Corporation | Apparatus and method for configuring a hand-held interactive device |
US7137073B2 (en) | 1999-12-18 | 2006-11-14 | Lg Electronics Inc. | Method for managing menu function in mobile station |
EP1307807B1 (en) | 2000-07-28 | 2007-11-14 | Symbian Limited | Computing device with improved user interface for menus |
US7023326B2 (en) * | 2001-05-26 | 2006-04-04 | Samsung Electronics Co., Ltd. | Vibration apparatus for a mobile telecommunication terminal and method for controlling the same |
GB2377858B (en) | 2001-07-19 | 2005-04-20 | Inventec Appliances Corp | Method for simplifying cellular phone menu selection |
US20030040850A1 (en) | 2001-08-07 | 2003-02-27 | Amir Najmi | Intelligent adaptive optimization of display navigation and data sharing |
JP4437633B2 (en) | 2001-08-10 | 2010-03-24 | 富士通株式会社 | Mobile device |
FI20020847A (en) | 2002-05-03 | 2003-11-04 | Nokia Corp | Method and device for accessing menu functions |
US7386279B2 (en) | 2003-04-02 | 2008-06-10 | Sun Microsystems, Inc. | Context based main screen for mobile device |
US8990688B2 (en) | 2003-09-05 | 2015-03-24 | Samsung Electronics Co., Ltd. | Proactive user interface including evolving agent |
US20050054381A1 (en) | 2003-09-05 | 2005-03-10 | Samsung Electronics Co., Ltd. | Proactive user interface |
US7725419B2 (en) | 2003-09-05 | 2010-05-25 | Samsung Electronics Co., Ltd | Proactive user interface including emotional agent |
US20060095864A1 (en) | 2004-11-04 | 2006-05-04 | Motorola, Inc. | Method and system for representing an application characteristic using a sensory perceptible representation |
US8037421B2 (en) | 2005-10-11 | 2011-10-11 | Research In Motion Limited | System and method for organizing application indicators on an electronic device |
JP2007109114A (en) | 2005-10-17 | 2007-04-26 | Matsushita Electric Ind Co Ltd | Function operating screen display control method |
KR100649149B1 (en) | 2005-11-24 | 2006-11-27 | 주식회사 팬택 | Mobile communication device having display-hot keys and method of the same |
JP2007300346A (en) * | 2006-04-28 | 2007-11-15 | Fujitsu Ltd | Call terminating operation control unit and call terminating operation control method, and program therefor |
US7578193B2 (en) * | 2006-06-28 | 2009-08-25 | Sauer-Danfoss Inc. | Method of measuring vibration on a device |
JPWO2008020537A1 (en) | 2006-08-16 | 2010-01-07 | 日本電気株式会社 | Portable terminal device, function list providing method used therefor, and program thereof |
US8209631B2 (en) | 2006-08-24 | 2012-06-26 | Nokia Corporation | User interface for an electronic device |
US20080074384A1 (en) | 2006-09-22 | 2008-03-27 | Research In Motion Limited | System and method for adjusting icons, text and images on an electronic device |
CN101755259A (en) * | 2007-07-20 | 2010-06-23 | Nxp股份有限公司 | Automatic address assignment for communication bus |
US9619143B2 (en) | 2008-01-06 | 2017-04-11 | Apple Inc. | Device, method, and graphical user interface for viewing application launch icons |
WO2009062176A2 (en) | 2007-11-09 | 2009-05-14 | Google Inc. | Activating applications based on accelerometer data |
KR20110036079A (en) * | 2008-06-27 | 2011-04-06 | 쿄세라 코포레이션 | Portable electronic apparatus |
KR20100030968A (en) | 2008-09-11 | 2010-03-19 | 엘지전자 주식회사 | Terminal and method for displaying menu thereof |
US20100087230A1 (en) | 2008-09-25 | 2010-04-08 | Garmin Ltd. | Mobile communication device user interface |
CN101729636A (en) | 2008-10-16 | 2010-06-09 | 鸿富锦精密工业(深圳)有限公司 | Mobile terminal |
JP5182047B2 (en) * | 2008-12-04 | 2013-04-10 | 富士通株式会社 | Wireless terminal device, wireless terminal device control method, and control program |
US20100146444A1 (en) | 2008-12-05 | 2010-06-10 | Microsoft Corporation | Motion Adaptive User Interface Service |
US8693993B2 (en) | 2008-12-24 | 2014-04-08 | Microsoft Corporation | Personalized cloud of mobile tasks |
US20100218141A1 (en) | 2009-02-23 | 2010-08-26 | Motorola, Inc. | Virtual sphere input controller for electronics device |
US8626141B2 (en) | 2009-07-30 | 2014-01-07 | Qualcomm Incorporated | Method and apparatus for customizing a user interface menu |
KR101612283B1 (en) | 2009-09-10 | 2016-04-15 | 삼성전자주식회사 | Apparatus and method for determinating user input pattern in portable terminal |
CN102087575B (en) | 2009-12-03 | 2015-04-08 | 中山市云创知识产权服务有限公司 | Electronic device and method for dynamic arrangement of icons |
CN102088498A (en) * | 2009-12-04 | 2011-06-08 | 深圳富泰宏精密工业有限公司 | Mobile phone and method for assisting in keeping fit with same |
JP2011239143A (en) * | 2010-05-10 | 2011-11-24 | Denso Corp | Recording system, on-vehicle device and portable device |
JP2012178753A (en) * | 2011-02-28 | 2012-09-13 | Nec Access Technica Ltd | Terminal, control method, and terminal program |
US9781540B2 (en) | 2011-07-07 | 2017-10-03 | Qualcomm Incorporated | Application relevance determination based on social context |
US20130019192A1 (en) | 2011-07-13 | 2013-01-17 | Lenovo (Singapore) Pte. Ltd. | Pickup hand detection and its application for mobile devices |
US20130082974A1 (en) | 2011-09-30 | 2013-04-04 | Apple Inc. | Quick Access User Interface |
KR101880968B1 (en) | 2011-10-27 | 2018-08-20 | 삼성전자주식회사 | Method arranging user interface objects in touch screen portable terminal and apparatus therof |
US8760426B1 (en) | 2012-03-26 | 2014-06-24 | Amazon Technologies, Inc. | Dominant hand detection for computing devices |
US9256349B2 (en) | 2012-05-09 | 2016-02-09 | Microsoft Technology Licensing, Llc | User-resizable icons |
KR20140087731A (en) | 2012-12-31 | 2014-07-09 | 엘지전자 주식회사 | Portable device and method of controlling user interface |
US10217064B2 (en) | 2013-02-21 | 2019-02-26 | Apple Inc. | Intelligent home screen for mobile and desktop operating systems |
US9080878B2 (en) * | 2013-02-21 | 2015-07-14 | Apple Inc. | Automatic identification of vehicle location |
US20150026624A1 (en) | 2013-07-16 | 2015-01-22 | Qualcomm Incorporated | Methods and systems for deformable thumb keyboard |
-
2013
- 2013-09-25 US US14/036,030 patent/US9204288B2/en not_active Expired - Fee Related
-
2015
- 2015-10-21 US US14/918,855 patent/US20160044150A1/en not_active Abandoned
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6809724B1 (en) * | 2000-01-18 | 2004-10-26 | Seiko Epson Corporation | Display apparatus and portable information processing apparatus |
Also Published As
Publication number | Publication date |
---|---|
US20150087275A1 (en) | 2015-03-26 |
US9204288B2 (en) | 2015-12-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20150089359A1 (en) | Intelligent Adaptation of Home Screens | |
US20150089386A1 (en) | Intelligent Adaptation of Home Screens According to Handedness | |
US20150089360A1 (en) | Intelligent Adaptation of User Interfaces | |
US9204288B2 (en) | Intelligent adaptation of address books | |
US10420064B2 (en) | Tactile feedback in an electronic device | |
EP2686747B1 (en) | System and method for providing direct access to an application when unlocking a consumer electronic device | |
US10191614B2 (en) | Panel displaying method, portable electronic device and recording medium using the method | |
EP2614418B1 (en) | Method of operating mobile device by recognizing user's gesture and mobile device using the method | |
US20170257427A1 (en) | Systems, methods, and computer readable media for sharing awareness information | |
US20130154926A1 (en) | Device and method for executing function of portable terminal | |
US20090326815A1 (en) | Position Fix Indicator | |
US20130268396A1 (en) | Method and system for providing personalized application recommendations | |
US9536224B2 (en) | Method, apparatus and recording medium for displaying tasks | |
WO2011102447A1 (en) | Behavior control system and behavior control method of information processing device | |
CN108762613B (en) | State icon display method and mobile terminal | |
CN107832067B (en) | Application updating method, mobile terminal and computer readable storage medium | |
CN108491125B (en) | Operation control method of application store and mobile terminal | |
CN107967086B (en) | Icon arrangement method and device for mobile terminal and mobile terminal | |
CN108449259B (en) | Communication processing method and mobile terminal | |
CN107888761B (en) | User name modification method and device, mobile terminal and readable storage medium | |
CN106657278B (en) | Data transmission method and device and computer equipment | |
CN111107213A (en) | Mobile terminal, call reminding method and storage device | |
JP2015225646A (en) | Information processing device | |
CN110633114A (en) | Application program starting method and terminal equipment | |
JP2019009501A (en) | Information processing device, information processing method, program, and information processing system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: AT&T MOBILITY II LLC, GEORGIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BRISEBOIS, ARTHUR RICHARD;REEL/FRAME:036848/0755 Effective date: 20130924 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |