US20080068519A1 - Networked personal audiovisual device having flexible housing - Google Patents

Networked personal audiovisual device having flexible housing Download PDF

Info

Publication number
US20080068519A1
US20080068519A1 US11/845,021 US84502107A US2008068519A1 US 20080068519 A1 US20080068519 A1 US 20080068519A1 US 84502107 A US84502107 A US 84502107A US 2008068519 A1 US2008068519 A1 US 2008068519A1
Authority
US
United States
Prior art keywords
chumby
user
widget
assembly
stage
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
Application number
US11/845,021
Inventor
Steven Adler
Joseph Grand
Andrew Huang
Duane Maxwell
Kenneth Steele
Stephen Tomlin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CHUMBY INDUSTRIES Inc
Original Assignee
CHUMBY INDUSTRIES Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by CHUMBY INDUSTRIES Inc filed Critical CHUMBY INDUSTRIES Inc
Priority to US11/845,018 priority Critical patent/US9654589B2/en
Priority to US11/845,021 priority patent/US20080068519A1/en
Publication of US20080068519A1 publication Critical patent/US20080068519A1/en
Assigned to CHUMBY INDUSTRIES, INC. reassignment CHUMBY INDUSTRIES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ADLER, STEVEN M., HUANG, ANDREW S., MAXWELL, DUANE S., STEELE, KENNETH E., TOMLIN, STEPHEN L., GRAND, JOSEPH B.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1626Constructional details or arrangements for portable computers with a single-body enclosure integrating a flat display, e.g. Personal Digital Assistants [PDAs]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1637Details related to the display arrangement, including those related to the mounting of the display in the housing
    • G06F1/1643Details related to the display arrangement, including those related to the mounting of the display in the housing the display being associated to a digitizer, e.g. laptops that can be used as penpads
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1656Details related to functional adaptations of the enclosure, e.g. to provide protection against EMI, shock, water, or to host detachable peripherals like a mouse or removable expansions units like PCMCIA cards, or to provide access to internal components for maintenance or to removable storage supports like CDs or DVDs, or to mechanically mount accessories
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1684Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/20Cooling means
    • G06F1/203Cooling means for portable computers, e.g. for laptops
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/01Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481Interaction 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/303Terminal profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/725Cordless telephones
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2129Authenticate client device independently of the user
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/72Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72409User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories
    • H04M1/72412User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by interfacing with external accessories using two-way short-range wireless interfaces

Definitions

  • 60/823,493 entitled NETWORKED PERSONAL AUDIOVISUAL DEVICE HAVING FLEXIBLE HOUSING, to co-pending U.S. Provisional Application Ser. No. 60/823,496, entitled SYSTEM AND METHOD FOR AUTOMATICALLY UPDATING THE SOFTWARE OF A NETWORKED PERSONAL AUDIOVISUAL DEVICE, to co-pending U.S. Provisional Application Ser. No. 60/945,900, entitled REGISTRATION SYSTEMS AND METHODS FOR PERSONALIZED PORTABLE DEVICES, and to co-pending U.S. Provisional Application Ser. No.
  • PCs personal computers
  • one aspect of the present invention relates to a portable information device including a frame structure.
  • the device further includes communications circuitry and a core electronics unit supported by the frame structure.
  • the core electronics unit includes memory in which are stored instructions for one or more computer programs received by the communications circuitry and executed by a processor.
  • a user interface in electrical communication with the core electronics unit is disposed to receive user instructions pertinent to execution of the one or more computer programs.
  • the device also includes a flexible housing attached to the frame structure, the flexible housing at least partially defining a compartment containing the core electronics unit.
  • the portable information device may contain resilient fill material interposed between the core electronics unit and the flexible housing.
  • the present invention relates to a portable information device including a core electronics unit including a main circuit board and a display.
  • the core electronics unit also includes memory in which are stored instructions for one or more computer programs executed by a processor.
  • a flexible housing structure at least partially defines a compartment containing the core electronics unit and an opening within which is positioned the display.
  • the device contains a resilient fill material interposed between the core electronics unit and the flexible housing.
  • the flexible housing structure includes a flexible frame member and flexible material attached to the frame member.
  • the present invention also relates to a method for assembling a portable information device.
  • the method includes providing a first electronics sub-assembly and securing the first electronics sub-assembly using a flexible frame.
  • the method further includes attaching a flexible housing to the flexible frame such that the flexible housing at least partially defines a compartment surrounding the first electronics sub-assembly.
  • the method may also include flexibly connecting the first electronics sub-assembly and a second electronics sub-assembly.
  • the present invention pertains to a method for assembling a portable information device.
  • the method includes forming a plastic frame by bending a piece of plastic material into a desired shape.
  • the method also includes attaching a first electronics sub-assembly to the plastic frame, the first electronics sub-assembly including a processor and a display.
  • the method includes sewing a flexible material to the plastic frame.
  • the method includes flexibly connecting the first electronics sub-assembly and a second electronics sub-assembly.
  • FIG. 1 is a block diagram illustrating a set of networked components comprising an exemplary embodiment of the system of the invention.
  • FIG. 2 illustrates an exemplary distribution of CHUMBYTM devices throughout a residence or other building having a number of rooms.
  • FIG. 3 provides a block diagrammatic representation of the principal components of an embodiment of a CHUMBYTM device of the present invention.
  • FIG. 4 shows an exemplary user interface generated through a screen of a CHUMBYTM device during operation of the CHUMBYTM device in a control panel mode.
  • FIGS. 5A-5E provides various perspective views of an exemplary CHUMBYTM device configured with a malleable housing.
  • FIGS. 6A-6D provide various partially transparent perspective, side and plan views of an embodiment of the CHUMBYTM device.
  • FIGS. 6E-6G depict the core electronics and other components contained within the housing of a CHUMBYTM device and the arrangement of certain of these components within a housing of the device.
  • FIG. 7 provides a block diagrammatic representation of the server components and other infrastructure which may be utilized to facilitate the operations of a CHUMBYTM service provider.
  • FIG. 8 provides a database model diagram of an exemplary object-oriented database schema utilized by a system database.
  • FIG. 9 is a signal flow diagram representative of one manner in which a configuration is provided to a CHUMBYTM device by a service provider.
  • FIG. 10 is a signal flow diagram which represents one manner in which a profile is provided to a CHUMBYTM device by a service provider.
  • FIG. 11 is a signal flow diagram which depicts processing of changes made to the parameters of a widget instance through the interface of a CHUMBYTM device in which the widget is instantiated.
  • FIG. 12 shows a signal flow diagram illustrating an exemplary widget instance download operation in which a service provider is requested to push values of widget-specific parameters to a requesting CHUMBYTM device.
  • FIG. 13 is a signal flow diagram which illustratively represents the process of obtaining content from the service provider for a widget of a CHUMBYTM device.
  • FIG. 14 is a flowchart which depicts an exemplary sequence of operations performed by a CHUMBYTM device upon initial power-up.
  • FIG. 15 is a flowchart illustrating an exemplary routine used to calibrate a touchscreen of a CHUMBYTM device.
  • FIGS. 16A-16D provide a set of screen shots of the user interface of a CHUMBYTM device being calibrated pursuant to the routine of FIG. 15 .
  • FIG. 17 is a flowchart illustrating the operations performed in selecting a wireless base station upon initial power-up of a CHUMBYTM device.
  • FIG. 18 is a flowchart of an exemplary account creation and registration process.
  • FIG. 19 is a flowchart representative of an exemplary Web-based interaction between a user and a service provider in connection with associating a particular CHUMBYTM device with the user's account.
  • FIG. 20 is a flowchart of an exemplary Web-based interaction between a user and the service provider with regard to disabling a CHUMBYTM device that has been previously associated with the user's account.
  • FIG. 21 is a flowchart of an exemplary Web-based interaction between a user and the service provider in connection with “mirroring” CHUMBYTM devices.
  • FIG. 22 is a top-level flowchart of exemplary Web-based or CHUMBYTM device-based interaction between a device user and the service provider with regard to adding, removing and configuring widget profiles relative to the user's CHUMBYTM device.
  • FIG. 23 is a flowchart representative of exemplary Web-based or CHUMBYTM device-based interaction between a device user and the service provider with respect to the addition of widgets to the current configuration of the user's CHUMBYTM device.
  • FIG. 24 is a flowchart representative of exemplary Web-based or CHUMBYTM device-based interaction between a device user and a service provider in connection with the removal of widgets from a channel, which may also be active on the user's CHUMBYTM device.
  • FIG. 25 is a flowchart depicting an exemplary set of operations involved in configuring parameters specific to of one or more widgets currently associated with a given CHUMBYTM device.
  • FIGS. 26A-26E are screen shots of exemplary user interfaces presented by a Web browser used to facilitate certain of the processes described by FIGS. 22-25 .
  • FIG. 27 is a signal flow diagram which illustratively represents the process of downloading the code for a widget from a service provider.
  • FIG. 28 provides an alternative illustration of a CHUMBYTM device in which is identified a core electronics unit and flexible housing of the device.
  • FIG. 29 illustrates various components interior to a flexible housing of an exemplary CHUMBYTM device.
  • FIGS. 30-31 provide an example of a flat pattern used to define the exterior structure of a flexible housing of an exemplary CHUMBYTM device.
  • FIGS. 32-33 show exemplary user interface screens of a CHUMBYTM device applicable to a process for calibration of one or more bend sensors within the device.
  • FIG. 34 is a process flow diagram of a text/image processing service within the infrastructure of CHUMBYTM service provider configured to parse e-mail messages from mobile devices and extract the relevant content.
  • FIG. 35 is a process flow diagram illustrating an alternate implementation of an image processing service for CHUMBYTM devices.
  • FIGS. 36A-36H provide a more comprehensive tabular representation of an exemplary object-oriented database schema capable of being utilized by the system database.
  • FIG. 37 is a top-level flowchart of exemplary Web-based interaction between a device user and the service provider with regard to adding, removing and configuring widget profiles relative to the user's CHUMBYTM device.
  • FIG. 38 is a flowchart representative of exemplary Web-based interaction between a device user and the service provider with respect to the addition of widgets to the current configuration of the user's CHUMBYTM device.
  • FIGS. 39A-39H are screen shots of exemplary user interfaces presented by a Web browser used to facilitate certain of the processes described by FIGS. 25 and 37 - 38 .
  • FIGS. 40A-40B are screen shots of exemplary user interfaces presented by a CHUMBYTM device used to facilitate certain of the processes described by FIG. 41 .
  • FIG. 41 is a flowchart representative of exemplary CHUMBYTM device-based interaction between a device user and a service provider in connection with the removal of widgets from the current channel of the user's CHUMBYTM device.
  • the present invention generally relates a system comprised of a set of personalized audiovisual devices in Internet-based communication with a service provider. It is anticipated that the personalized audiovisual devices will be commercially distributed under the trademark CHUMBYTM, and may also be referred to herein as “CHUMBYTM devices”.
  • CHUMBYTM commercially distributed under the trademark CHUMBYTM
  • CHUMBYTM devices may also be referred to herein as “CHUMBYTM devices”.
  • each CHUMBYTM device periodically receives a set of application programs, or “widgets”, which are sequentially executed by the CHUMBYTM device after being received from the service provider or locally from a personal computer (e.g., via a USB connection).
  • each CHUMBYTM device is typically Internet-enabled, each may also be remotely configured and otherwise personalized via the CHUMBYTM service provider through a Web browser executed by a remote terminal (e.g., a PC or wireless handset).
  • a remote terminal e.g., a PC or wireless handset.
  • Such personalization may include, for example, specifying the set of widgets provided to a given CHUMBYTM device as well as their sequence and priority of execution.
  • a user configuring a CHUMBYTM device via an interface provided by the CHUMBYTM service provider may “drag and drop” icons representative of various widgets onto a rectangular or other portion of the interface representative of the screen of the CHUMBYTM device being configured.
  • a user may select textual and/or graphical representations of widgets and select a button or other graphical representation of a user interface (UI) control to “add” the widget to the CHUMBYTM device being configured.
  • UI user interface
  • each CHUMBYTM device will preferably be capable of being configured in this manner, in certain embodiments each may also come “loaded” with a default set of widgets (e.g., an “alarm clock” widget) disposed to be executed by the CHUMBYTM device upon its registration with the CHUMBYTM service provider.
  • a CHUMBYTM device Once a CHUMBYTM device has been configured (i.e., with either a “default” or user-specified configuration), it may execute the widgets defined by the configuration without user intervention. Alternatively, users may opt to “stay” on a given widget by explicitly instantiating the system interface on the device and selecting a “stay” UI control.
  • the sequential execution of widgets can be continued by terminating the “stay” command via the system interface. If a user interacts with a widget which presents user interface controls to the user through one of a number of alternative input methods, such as via a touchscreen or accelerometer, the currently active widget will continue to execute on the device until some timeout period expires following the cessation of user interaction with the widget.
  • the configuration of a CHUMBYTM device may also specify the events or conditions under which the sequence of execution of widgets is to be altered or interrupted, and allows certain widgets to be accorded the highest available priority with respect to execution. For example, an “alarm clock” widget could be granted such priority in order to ensure that its alarm function would not be prevented from being actuated at the scheduled time due to contemporaneous execution of another widget.
  • the Web interface provided by the CHUMBYTM service provider is in the form of a “timeline” enabling the sequence of execution of the widgets associated with a given CHUMBYTM device to be controlled in an intuitive manner.
  • the timeline defines the order in which the widgets are to be played in a constantly repeating sequence; that is, the timeline is representative of the complete set of widgets played by a given CHUMBYTM device as well as their relative order and duration of execution.
  • certain widgets e.g., the “alarm clock” widget
  • a system configuration widget may be utilized to run concurrently with each such content-related widget in order to, for example, control the relative priority of execution of such content-related widgets and system settings such as loudness, brightness, navigation, and the like.
  • CHUMBYTM devices are each capable of wireless communication in accordance with an accepted wireless networking standard, such as the 802.11b or 802.11g standard. Accordingly, in homes or other environments containing one or more wireless access points, multiple CHUMBYTM devices may be distributed throughout the coverage area of the access points. Alternatively, a CHUMBYTM device may use a wired connection as a backup to, or in lieu of, a wireless connection to the extent convenient or necessary.
  • each CHUMBYTM device could change in accordance with the nature of the widget currently being executed by the device.
  • a “clock radio” widget could be employed to produce audio and visual imagery consistent with a conventional alarm clock at an appointed time in the morning.
  • the clock radio widget would allow for the selection of a standard “wake up” chime or choice of several different audio programs.
  • the device interface could be devoted to a rotating selection of several standard information screens such as news headlines, local weather, sports scores, stock market updates, horoscope and the like.
  • CHUMBYTM devices may optionally participate in a “CHUMBYTM Network” along with other users by logging on to a Web site (e.g., www.chumby.com) hosted by the CHUMBYTM service provider.
  • a Web site e.g., www.chumby.com
  • CHUMBYTM site a site that a user will be able to register with the CHUMBYTM Network and access services enabling the basic capabilities of the user's CHUMBYTM device.
  • Basic capabilities may comprise, for example, the opportunity to send/receive widgets and other content to/from other CHUMBYTM users, for improved personalization of the device's generic information features, more detailed alarm-setting capabilities, and better selection and configuration of audio capabilities.
  • CHUMBYTM Network Registration with the CHUMBYTM Network, which would potentially require payment of a periodic subscription fee, enables members of the Network to access a wide array of widgets. It is contemplated that certain of such widgets would be developed by the entity operating the CHUMBYTM Network while other widgets would be developed by independent developers. In addition, members of the “CHUMBYTM Network would also be able to communicate with the CHUMBYTM devices of other members, provided that permission for such communication has been authorized by the other members.
  • Such communication could entail, for example, the sending of a widget and corresponding data from the CHUMBYTM service provider to a member of the CHUMBYTM Network (the “receiving member”) in response to a request sent to the CHUMBYTM service provider by another member (the “sending member”).
  • a sending member could, after receiving permission from a receiving member, request the CHUMBYTM service provider to send a “photo-viewer” widget to the receiving member.
  • the sending member could specify that a link be established between the photo-viewer widget and pictures uploaded by the sending member to the CHUMBYTM service provider.
  • the receiving member could, without any effort other than providing authorization to the sending member, enable their CHUMBYTM device to essentially automatically receive and display a sequence of photos provided by the sending member.
  • a sending member could send a personalized “wake up” message to the CHUMBYTM device of a consenting receiving member.
  • a sending member could send widgets to a group of receiving members included on a “buddy list” of the sending member, which could be established after the receipt of suitable permissions from those proposed to be included on the list.
  • members of the CHUMBYTM Network are enabled to completely configure, through any Web browser, their respective CHUMBYTM devices by specifying a set of “premium” widget programs or content to play or be shown rotationally (or in some other user-defined sequence) on their respective CHUMBYTM devices.
  • premium widgets and content may include, for example, webcam shots, RSS readers, filtered news reports, personalized stock performance data, short animations or movies, podcasts or audio files to function as the audio sources for alarms or reminders scheduled to be triggered at different times throughout the day.
  • a CHUMBYTM device is comprised of a malleable housing attached to a rigid “core” structure supporting a display screen and the electrical components of the device.
  • the malleable housing would generally encompass all of the electrical components of the CHUMBYTM device, and will preferably be filled with an appropriate material or otherwise constructed to enable it to be “squeezed” or otherwise deformed by a user.
  • the core structure is designed to be capable of being removed from the housing and mated in to a different housing.
  • a set of “squeeze sensors” are enclosed by the malleable housing in order to permit the detection of such a squeezing or similar action by a user.
  • a user is afforded the opportunity of conveying information through physical deformation of the CHUMBYTM device in addition to the more conventional textual and other modes of communication facilitated by the display screen.
  • a user could initiate the conveying of a “hug” to another user by squeezing the housing of the user's CHUMBYTM device in a particular manner.
  • the electrical signals generated by the sensor array in response to this squeeze would be appropriately interpreted and the user's CHUMBYTM device would communicate, via the CHUMBYTM service provider, a “hug” message to the intended recipient user.
  • the recipient's CHUMBYTM device could register receipt of the hug message by, for example, illuminating an indicator light or sending a message to the display of the device.
  • the CHUMBYTM device is not limited to an implementation in a malleable housing; all of the features associated with such a malleable housing may be emulated using a rigid housing in combination with alternative sensors (e.g., force-sensitive or virtually emulated sensors).
  • FIG. 1 is a block diagram illustrating a set of networked components comprising an exemplary embodiment of the system 100 of the invention.
  • the system 100 comprises one or more CHUMBYTM personal audiovisual devices 102 in communication with a central service provider 106 via one or more access networks 110 and the Internet 116 .
  • the access networks 110 are representative of various intermediary network routing and other elements between the Internet 116 and the CHUMBYTM personal audiovisual devices 102 .
  • Such intermediary elements may include, for example, gateways or other server devices, and other network infrastructure provided by Internet service providers (ISPs).
  • ISPs Internet service providers
  • the CHUMBYTM personal audiovisual devices 102 obtain application programs (“widgets”) for execution from the central service provider 106 or locally from a mass storage device, personal computer or other computing device.
  • the service provider 106 typically contains a repository of widgets and has access to other content capable of being communicated to a given CHUMBYTM device 102 upon the request of its authorized user or another user to which appropriate permission has been granted.
  • the system 100 also includes a plurality of user computers 120 disposed for communication with the service provider 106 via an access network (not shown) and the Internet 116 .
  • Each user computer 120 executes a Web browser 122 capable of displaying Web pages generated by the service provider 106 through which a user may configure one or more CHUMBYTM personal audiovisual devices 102 .
  • such configuration may include, for example, specifying a set of widgets to be sent to a particular device 102 and their sequence of execution, adjusting audio or visual parameters relating to such execution, defining and managing a user's CHUMBYTM network (including, for example, defining a “buddy list” comprised of other CHUMBYTM users with respect to which the device 102 is permitted to communicate), and defining the layout or other aspects of the user interface presented through the screen of the device 102 .
  • a given Web browser 122 may, when in communication with the service provider 106 , present a rectangular configuration window which displays the widgets currently configured to “play” within the named “channel”.
  • a user may personalize the behavior and user interface presented by the corresponding CHUMBYTM device 102 .
  • a user may select textual and/or graphical representations of widgets and select a button or other graphical representation of a user interface control to “add” the widget to the CHUMBYTM device being configured.
  • users may access the service provider 106 via a Web browser 122 for the purpose of sending widgets or other information to other users for execution or display by their respective CHUMBYTM devices 102 .
  • the service provider 106 maintains a record of the permissions granted among users of CHUMBYTM devices in order to determine which users are authorized to provide, via the service provider 106 , a given user with widgets, messages or other information, and vice-versa. Such permissions may be granted or withdrawn by a given user via appropriate pages presented by a Web browser 122 in communication with the service provider 106 .
  • a configuration window may be utilized to configure one or more CHUMBYTM devices 102 consistent with the permissions granted by the users of such devices 102 .
  • a user of a given CHUMBYTM device 102 may elect to have the interface of the device 102 “mirror” or otherwise replicate that of another device 102 subject to the requisite permissions being granted.
  • one or more CHUMBYTM devices 102 may be configured to mirror the interface for a “virtual” CHUMBYTM device (or vice-versa) defined via a configuration window.
  • Different users of a given CHUMBYTM device 102 may be accorded different roles or privileges in configuring the device 102 .
  • user-granted supervisory privileges could be given the authority to filter or monitor the widgets or content sent to the CHUMBYTM device 102 .
  • administrators of the system 100 would typically possess an elevated level of privilege relative to users of CHUMBYTM devices 102 within the system 100 .
  • the developer of the widget may create a hierarchical user model to regulate such access (and perhaps the functions of the widget).
  • FIG. 2 illustrates an exemplary distribution of CHUMBYTM devices 102 throughout a residence 200 or other building having a number of rooms 204 .
  • each CHUMBYTM device 102 is equipped with wireless transceiver (e.g., a Wi-Fi transceiver) to facilitate communication with one or more access points 210 .
  • Each access point is interconnected with an access network 110 by way of, for example, a local area network, thereby enabling Internet-based communication to be established between the service provider 106 and the devices within the residence 200 .
  • the device includes a central processing unit (CPU) 302 , memory including volatile (e.g., SDRAM) 306 and non-volatile memory 310 (e.g., flash memory), an audio interface 312 , a wireless communications interface 314 , and a sensor interface 370 .
  • the CPU 302 comprises a microprocessor (e.g., based upon an ARM core) configured to run a Linux kernel and having attendant capabilities for graphics rendering.
  • the device may or may not include a battery backup unit, which serves to preserve real-time information in the event of a power outage, and may also serve as a primary power source if the user desires untethered operation.
  • the battery may or may not be rechargeable.
  • the operating system is made aware of the power status and actively configures the CHUMBYTM device and the running widget to either save power or modify the user interface consistent with untethered operation.
  • the device may or may not include a Security Module (not shown) If included, the Security Module serves to store secrets and compute authentication algorithms in a fashion that fully isolates core security routines from otherwise unsecured code running on CPU 302 .
  • the secret storage and authentication capability may or may not be used by the client-server communication protocol to enable authenticated and encrypted communication capabilities for, among other things, financial transactions.
  • the Security Module is initialized in such a way that there is no default mapping of the secrets contained within the module versus the identity of the hardware of the user. Furthermore, the secrets are revocable and a routine may exist for generating new secrets based upon a master secret that is never associated with a specific user's profile.
  • the anonymous trust network can be extended with a variety of client-server protocols to enable a wide range of anonymous transactions, including but not limited to cash and content transactions.
  • widgets 350 or other applications received from the service provider 106 are stored in memory 310 and loaded into SDRAM 306 or non-volatile memory 310 for execution by the CPU 302 .
  • widgets are downloaded from the service provider 106 to CHUMBYTM devices in the format of a “Adobe Flash” file, also referred to as a “Flash movie”.
  • Flash movies are usually accorded a “.swf” file extension and may be played by a Flash Player developed and distributed by Adobe Systems.
  • the memory 310 also includes a Flash Player 360 as well as a copy of the operating system 364 executed by the CPU 302 .
  • widgets may be developed in accordance with other formats and played by players compatible with such other formats.
  • widgets are not “permanently” stored in memory 310 of CHUMBYTM devices. Rather, widgets are executed by the CPU and then either discarded or cached in temporary memory for future use. This enables widgets to be “pushed” from the service provider 106 as necessary to support the sequence of widget execution specified for each CHUMBYTM device. That is, the service provider 106 may operate to provide a “stream” of widgets to each CHUMBYTM device, where the widgets within each such stream are temporarily cached within the memory of the applicable CHUMBYTM device until their execution.
  • each widget program This enables the service provider 106 and/or the creator of each widget program to maintain a degree of control over the content and behavior of each widget program, since each such program is typically not permanently downloaded (thereby facilitating modification) but is rather temporarily cached and erased after some predetermined time has passed or a memory use threshold has been reached.
  • the CHUMBYTM device also includes a liquid crystal display (LCD) 320 controlled by an LCD controller 322 , which may or may not be integrated into the CPU 302 .
  • the display 320 visually renders iconic representations of the widget programs stored within the CHUMBYTM device and images generated in connection with the execution of such widgets by the CPU 302 .
  • a touchscreen 330 overlays the LCD 320 and is responsive to a touchscreen controller 334 .
  • a user may induce the CHUMBYTM device to enter a “control panel mode” by touching the a sensor such as the squeeze sensor (not shown in FIG. 3 ), touchscreen 330 or other sensor device.
  • widgets and the system control panel may present the user with different “user interface”, or “UI”, elements to enable the user to interact with the widget/system control panel.
  • UI elements may include, but are not limited to, buttons, scroll bars, drop down combo boxes and menus.
  • the touchscreen controller 334 informs the CPU 302 that the touchscreen has been touched at a specific location and that location is converted by the CPU 302 to a UI control actuation event based on the configuration of the currently displayed widget 350 or system control panel screen (not shown in FIG. 3 ).
  • the LCD 320 and touchscreen 330 may comprise an integral device controlled by an integrated controller.
  • FIG. 4 there is shown an exemplary user interface 400 generated by the LCD 320 during operation of the CHUMBYTM device in control panel mode.
  • the interface 400 defines an mute button 404 , a channel button 406 , a night button 408 , a music button 410 , a settings button 412 , a clock button 414 , a delete button 418 , a rate button 420 , a send button 422 , a stay button 424 , a right arrow button 428 , a left arrow button 426 , and a hide control panel mode button 416 .
  • Selection of the mute button 404 toggles the mute state of the CHUMBYTM device.
  • Selection of the channel button 406 instantiates another control panel screen which enables users to view the content of all of their CHUMBYTM “channels” and/or select a new “channel” to be loaded and run on the CHUMBYTM device.
  • a “channel” is a collection of widgets configured by a user in a named grouping via an interaction between a page rendered on a web browser 122 and the CHUMBYTM service provider, such collection of widgets generally running on the CHUMBYTM device in a sequential, repetitive fashion.
  • Selection of the night button 408 places the CHUMBYTM device into a “night mode” in which the screen is dimmed and a low intensity clock is displayed.
  • Selection of the music button 410 instantiates another control panel screen which enables the user to interact with and control various continuous music sources, such as, for example, MP3 players, storage devices, and music services. Such sources may reside on either the local network or on the Internet.
  • Selection of the settings button 412 instantiates another control panel screen which enables the user to configure various CHUMBYTM device settings, such as, for example, wireless network setup, speaker volume and touchscreen calibration.
  • Selection of the clock button 414 instantiates another control panel screen which enables the user to configure the time, date and alarm functions of CHUMBYTM device.
  • Selection of the delete button 418 deletes the currently displayed widget to be deleted, with user confirmation, from the current “channel”.
  • Selection of the rate button 420 instantiates another control panel screen which enables the user to provide a rating on a fixed scale for the currently displayed widget.
  • Selection of the send button icon 422 instantiates another control panel screen which displays a personalized list of other users of CHUMBYTM users to which it may be desired to send widgets or otherwise communicate.
  • Selection of the stay button 424 toggles the “stay” state of the currently selected widget. When the “stay” state of a widget is selected, the widget plays continuously on the CHUMBYTM device.
  • Selection of the right arrow button 426 or left arrow button 428 causes the CHUMBYTM device to display the previous or next widget in the channel, respectively.
  • a user may, from any Web browser 122 , access a Web page generated by the service provider 106 and designate a “favorite” widget.
  • a user may press a virtual, touchscreen-based button on his or her CHUMBYTM device 102 to designate the current widget as the new “favorite” widget.
  • the user selects the heart-shaped icon (not shown in FIG. 4 ) on his or her CHUMBYTM device, an iconic representation of this favorite widget (e.g., a clock widget) replaces the heart-shaped icon and enables the user to immediately activate (i.e., cause the CPU 302 to execute) the program instructions corresponding to such favorite widget.
  • heart-shaped icon or other predefined icon
  • CHUMBYTM device becoming configured in accordance with a “favorite” or other profile rather than executing a favorite widget.
  • certain profiles may be specified to include only a single widget such as, for example, an “alarm clock” or “photo viewer widget.
  • selection of the right arrow button 426 advances one widget in a user-defined (or default) widget sequence (“channel”), or just skips ahead in implementations in which widgets are chosen to be displayed randomly.
  • selection of the left arrow button 428 results in “going back” one widget in the user-defined (or default) widget sequence (“channel”).
  • an iconic representation or avatar corresponding to the currently active widget is displayed in a display box 430 . If it is desired to return to the currently active widget, the hide control panel mode button 416 is selected and the control panel mode interface 400 changes to a screen through which the user views the sequence of widgets currently configured to be executing on the CHUMBYTM device.
  • a physical button element may be provided proximate the LCD screen 320 to enable navigation through menus and the like presented by the LCD screen 320 .
  • this button element is cross-shaped in order to facilitate two-dimensional navigation, and may further include a smaller, dedicated button (e.g., in the center of the cross) associated with a specific widget (e.g., clock widget). Pressing this dedicated widget would interrupt the operation of all other widgets.
  • users may be provided with the ability to navigate forward and back in the configured widget timeline. Similarly, users may navigate up and down a stack of related widgets. This function depends on the implementation of the concept of widget categories—i.e., associating widgets into logical categories that can be displayed sequentially, if configured to be displayed.
  • An example of a category could be “News”. Widgets included within this category could include, for example, a local news widget, a sports news widget, an entertainment news widget, a business news widget, and the like.
  • For each category there would be a default widget, which is designated by the user on the CHUMBYTM web site for each category selected to be displayed by the user's CHUMBYTM device.
  • the widgets are conceptually “stacked” with the default widget being:
  • the widget that is displayed as the CHUMBYTM device automatically cycles through configured widgets.
  • a widget for a given category e.g., “News”
  • these additional widgets are “stacked” below the displayed widget.
  • the user may take some predefined action with respect to the user's CHUMBYTM device (e.g., perhaps selecting a control on the touchscreen or accessing a function via the control panel, which is instantiated via actuating the squeeze sensor) in order to cause the next widget in the “stack” for that category to be displayed.
  • the CHUMBYTM device may be configured such that taking further predefined actions of the same type will cause the widgets either above or below in the stack to be displayed, as designated by the user.
  • the last widget that is displayed in the stack for the applicable category when the CHUMBYTM device cycles to the next widget category will be the widget displayed in the next cycle for the just exited category (e.g, News).
  • FIGS. 5-6 and 28 - 29 provide various views of an exemplary CHUMBYTM device in accordance with the present invention.
  • Embodiments of a CHUMBYTM device will typically include one or more assemblies of electronic components integrated into a soft housing. Each such assembly may or may not include components that are externally visible.
  • PCBA printed circuit board assembly
  • Embodiments of the CHUMBYTM device may include one or more electronics sub-assemblies; an exemplary embodiment described herein employs three such sub-assemblies.
  • One such sub-assembly is included within a core electronics unit of the CHUMBYTM device, and contains heat-generating electronics components, an LCD, and a microphone.
  • Another such electronic sub-assembly comprises a WiFi riser containing a WiFi communications module.
  • the third electronics sub-assembly included within the exemplary embodiment of the CHUMBYTM device comprises a “daughtercard sub-assembly”.
  • the daughtercard contains a plurality of external connectors (e.g., USB connectors) and a set of audio transducers.
  • a mechanical switch is grafted onto the daughtercard sub-assembly facilitates the “squeeze sensing” described below.
  • An accelerometer may also be included upon the daughtercard sub-assembly.
  • FIG. 5 provides various perspective views of an exemplary CHUMBYTM device configured with a malleable housing 502 comprising a rubber-type frame 504 in combination with a fabric material 508 .
  • the housing 502 surrounds a core electronics unit 512 , bezel 514 for daughtercard sub-assembly, and a plush interior fill material (not shown in FIG. 5 ).
  • the frame 504 , fabric 508 and fill materials collectively impart a soft and malleable feel to users handling the CHUMBYTM device.
  • the frame 504 is composed of SantopreneTM or Texin, a soft, flexible, tactile, rubber-like material similar to TPE (thermo plastic elastomer).
  • the frame 504 is composed of a very low durometer PVC (Polyvinyl Chloride).
  • the exact frame composition will generally balance considerations of flexibility, feel, look, and manufacturing properties, namely, the ability to be sewn and to have items tacked onto the side with adhesive to improve production tolerances.
  • the frame 504 provides structure and form to the housing 502 and allows the core electronics unit 512 to be replaced and inserted.
  • the frame 504 will generally be manufactured in a relatively flattened configuration and then manually flexed or curved and stitched to the fabric or other soft material when assembling the housing 502 of the CHUMBYTM device.
  • the CHUMBYTM frame, fabric, or a combination thereof is created out of molded EVA (Ethylene Vinyl Acetate) foam. The molding process renders a slightly different feel but generally provides greater fidelity to CAD-related artwork.
  • FIG. 28 provides an alternative illustration of a CHUMBYTM device in which are identified the core electronics unit 512 and the flexible housing 502 .
  • the flexible housing of a CHUMBYTM device may be created using any number of exterior fabric materials such as those used in soft-goods or plush toy manufacturing. Such materials may include, for example, leather, suede, Neoprene, rubber, vinyl, etc.
  • Interior to the flexible housing may be contained any number of fill materials, such as Poly-Fil, polyester beads, gel, foam, metal beads, etc., not unlike a pillow, stuffed animal, or plush toy.
  • Such interior fills enable the CHUMBYTM device to be “squishable.” Moreover, such interior fill enables the device to retain its shape after being “squeezed” or “pressed” by a user in order to trigger an internal squeeze sensor 650 .
  • an electric field/capacitance sensor may be used in lieu of a squeeze sensor to detect the location/distance of a user's hand to the sensor; that is, since the user's hand moves closer to the sensor as the user squeezes the flexible housing of the CHUMBYTM device, the sensor is capable of indicating that a “squeeze” event has occurred).
  • the daughtercard circuitry containing an external power switch, external power supply connector, external headphone connector, one or more external USB connectors, internal left and right speaker connectors, internal 9V back-up battery connector 2904 , internal squeeze sensor connector, and internal cable assembly or “ChumbilicalTM” connector 2910 .
  • the Chumbilical connector 2910 is used to connect all the signals received/processed by the daughtercard sub-assembly to the core electronics unit 512 of the CHUMBYTM device, which is press-fit into the soft frame.
  • a pair of speakers 630 for left and right audio output
  • the speakers are affixed to a rigid plate, constructed of plastic or other similar material, located on the back of the CHUMBYTM device, coincident to the headphone connector, USB ports, power switch and power connector.
  • the division of the circuitry into a core board with greater complexity and cost and a daughtercard which breaks out many of the peripheral connections and features is a significant feature of the design of exemplary embodiments of the CHUMBYTM device. So segregating the design enables quicker adaptation to market and product changes, since the most volatile components of a system are often “on the edge”. The segregation of the core and the peripherals in this manner also provides a key benefit, in that the peripheral card can be customized at a lower cost, which helps enable the growth of an ecosystem of accessories and custom housings around the CHUMBYTM device.
  • an example of a flat pattern is used to define the exterior structure of the flexible housing 3002 or “bag” of an exemplary CHUMBYTM device (“CHUMBYTM bag”).
  • CHUMBYTM bag Any number of artistic/design elements can be added to the exterior fabric material of the CHUMBYTM bag to add dimension and visual features.
  • the use of a fabric-type enclosure for the CHUMBYTM device provides for unlimited possibilities for product housing creation, both by the original manufacturer and end-users (such as craftspeople, hobbyists, etc.), and is believed to represent a novel approach in the design of consumer electronic and/or wireless devices.
  • Fabric tags, patches, or other fabric/garment-related items can be stitched or otherwise attached to the exterior housing of the CHUMBYTM device to convey product or corporate information, such as a logo.
  • FIG. 31 provides a sample flat pattern drawing 3100 for the flexible housing 3002 or “bag” of a CHUMBYTM device, showing individual fabric panel shapes, stitching details, and design elements:
  • FIGS. 6A-6D provide various partially transparent perspective, side and plan views of an embodiment of the CHUMBYTM device.
  • FIGS. 6E-6F depict the core electronics unit and other components contained within the housing of the CHUMBYTM device, and FIG. 6G illustrates the arrangement of certain of these elements within the housing.
  • the core electronics unit 512 will generally include, for example, a main circuit board onto which are populated a plurality of electronic components.
  • the main circuit board will generally then be integrated into a hard sub-frame made of a rigid material such as, for example, stiff plastic or metal, thereby yielding an electronics sub-assembly.
  • the core electronics unit 512 will also typically include an LCD display, touchscreen, ambient light sensor, microphone, USB WiFi dongle 610 , backup battery 620 , and any number of RF shields.
  • This core module is designed to be removable from the frame by the user of the CHUMBYTM device. It is typically connected into the housing CHUMBYTM by the ChumbilicalTM connector 2910 .
  • the WiFi dongle 610 is connected to the WiFi riser (not shown) of the core electronics unit and facilitates WiFi wireless networking.
  • the backup battery 620 may be realized using, for example, a standard 9V alkaline, and is used to provide backup/supplemental power to the CHUMBYTM device in the event of failure of the primary power supply.
  • the backup battery 620 is mounted onto an RF shield positioned on a back side of the core electronics unit 512 and is intended to be replaceable by the user.
  • the battery 620 is contained in the soft housing of the CHUMBYTM device and is accessible via a velcro-sealed hole in the exterior material for user service.
  • the daughtercard 640 provides connectors available to the user, including power input, headphone output, and external USB-style connectors for future accessories and/or facilitating device upgrades.
  • the daughtercard sub-assembly 640 is clamped to the fabric in between the daughtercard sub-assembly front and rear bezel components 514 , which are made of rigid ABS-type plastic.
  • the daughtercard sub-assembly connects to the core electronics 512 via the ChumbilicalTM 2910.
  • the CHUMBYTM device includes a pair of internally-mounted speakers 630 to provide stereo sound.
  • the speakers 630 are held in place using square pouches sewn into the interior of the unit.
  • the pouches each have a small drawstring to keep the speakers 630 in a relatively fixed position within the interior of the CHUMBYTM device.
  • the speakers are retained in the rear bezel molding. Both speakers 630 connect to the daughtercard sub-assembly 640 .
  • the squeeze sensor 650 may be implemented in a variety of different ways to facilitate sensing of “squeezing” of the CHUMBYTM device.
  • the squeeze sensor 650 is typically connected to the daughtercard sub-assembly 640 and in one particular embodiment comprises a flexible resistive element which varies in resistance based upon the angle of flex of the sensor.
  • the squeeze sensor 650 may be comprised of a canonical snap action switch with a lever protruding into the body of the CHUMBYTM device and buffered by the surrounding fill material to give an overall soft feel. Accordingly, the squeeze sensor 650 is capable of detecting physical “squeezing” of the soft housing of the CHUMBYTM device.
  • Signals from the squeeze sensor 650 are processed (e.g., by the core electronics module 512 or dedicated electronic circuitry) and generally will precipitate performance a defined action, which may be dependent upon characteristics of the currently active widget.
  • the squeeze sensor 650 connects to the daughtercard sub-assembly 640 .
  • the squeeze sensor 650 will generally be attached to the inside of the CHUMBYTM bag and oriented parallel to the vertical access of the CHUMBYTM device. In other embodiments, one or more displacement sensors may be used to effect the same function.
  • the squeeze sensor 650 may be implemented in a variety of different forms to accomplish “squeeze sensing” within a CHUMBYTM device:
  • a mechanical switch such as a “snap action” switch, may be mounted with its actuator lever curled over so that it does not catch on any of the internal fabric seams.
  • Soft fill may be packed between the lever and the bag surface so as to spread the force of the squeeze around, thereby increasing the effective active area of the snap action switch.
  • Soft fill may also be packed between the lever and the switch so as to provide extra restoring force so that the switch does not become stuck in one position.
  • a strip such as a resistive bend sensor, or a force sensor consisting of a resistive material, a spacer, and intercalated electrodes, may be adhered or sewn into the fabric. The deformation of the fabric modulates the resistance of these sensors, which could then be post-processed by the electronics in the bag into a bend signal.
  • a capacitive field sensor may be used, which creates a sensing field that extends up to the edge of the bag. When the bag is squeezed, the deformation and presence of the fingers will change the dielectric properties of the air within the bag. This change in dielectric property can be detected using a number of techniques, including but not limited to the shift in frequency of a resonant tank.
  • Acceleration sensor An accelerometer inside the bag may be used to detect the signature of a deformation event based upon how the sensor moves inside the bag.
  • a set of advanced signal identification primitives may be required, which may take the form of kalman filters, matched filters, and/or hidden markov estimators.
  • a plastic lip may be attached to an opening defined by the soft housing in the manner described below.
  • the lip is preferably configured to have a smaller opening than the size of the core electronics sub-assembly. This difference in diameter or relevant dimension prevents the core from easily falling out of the plastic lip.
  • the soft housing may internally include a set of buttresses that press against the core electronics sub-assembly to keep the housing from being easily pushed inward.
  • the buttresses may take the form of a structural foam or of a rigid mechanical piece attached to the housing.
  • the lip may have a set of friction-locking points, thus enabling it to engage into the core electronics sub-assembly through mating friction-lock points.
  • the lip and core electronics sub-assembly may be glued together using a variety of adhesives.
  • a brittle drying adhesive such as a cyanoacrylate
  • the lip of the soft housing may be engineered using a soft but semi-tacky plastic, such as TPE, which inherently provides friction.
  • an overmolded soft plastic lip (such as a TPE compound) can be applied to the plastic edge of the bezel for the daughtercard sub-assembly to facilitate blending.
  • a viscous or semi-solid adhesive (such as VHB) can be applied to the daughtercard bezel prior to mounting to assist with minimizing gapping.
  • a jig-shaped element may be used to hold the bezel component so as to facilitate alignment of the applicable components.
  • a set of screw holes may be made in the fabric of the soft housing in alignment with mating screw-through pegs in the daughtercard bezel to facilitate both alignment and retention of the fabric.
  • a friction-fit rim consisting of an exterior piece sandwiching an interior piece may be used to enhance the snugness of the seam between the soft housing and the daughtercard bezel.
  • a number of approaches may be used during the fabrication process to reduce the buildup of within the soft housing during operation of the CHUMBYTM device. Since in certain embodiment a CHUMBYTM device may gain its shape and resilience due to air trapped between the fibers of a compound similar to polyfill, the fill material and soft housing collectively act as an insulator around the various electronics sub-assemblies. Strategies for mitigating this potential insulating effect are described below.
  • One heat dissipation strategy involves filling the soft housing of the CHUMBYTM device with thermally-conductive materials.
  • the materials may be dispersed in whole or in part through the soft fill material interposed between the electronics sub-assemblies and the soft housing.
  • thermally-conductive materials may be composed of, for example, hollow aluminum beads or pellets, or plastics having relatively good thermal conduction characteristics.
  • Another embodiment uses a thermally-conductive gel material to conduct the heat from the core electronics sub-assembly to the surface of the soft housing.
  • a heat pipe may be used to conduct heat to a metal plate glued to the surface of the soft housing.
  • Such approaches may advantageously leverage a large surface area and utilize relatively thin fabric material for the soft housing so as to minimize overall heat retention.
  • Heat dissipation may also be facilitated by “stacking” the various electronic sub-assemblies and other components in such a way that a low-thermal resistance path exists from each heat-generating component within the device to one of the solid structures facing exterior to the CHUMBYTM device (e.g., the daughtercard bezel or LCD display).
  • solid structures effectively function as heats sinks.
  • Each low-thermal resistance path may be completed by interposing a thermal compound (e.g., in the form of soft, gel-like gap filling pads) between the heat generating electronics sub-assemblies and the externally facing solid structure.
  • the LCD display is held in place with an aluminum heat spreader plate, and a thermal compound is applied between the heat spreader and the LCD.
  • the PCB of the core electronics sub-assembly may contain thermal vias and copper planes to enhance heat flow.
  • the WiFi module When the WiFi module is mounted directly to the PCB of the core electronics module, heat conduction may be enhanced using positioning a soft gel-like gap filling between the WiFi module to this PCB and ultimately through the LCD display to the ambient air.
  • the WiFi module is placed on a WiFi riser in order to enable generation of an improved antenna pattern.
  • the WiFi module is positioned such that a suitably low-resistance thermal path is established between the module and the PCB of the core electronics module through any of the metal connectors or devices exposed on the PCB.
  • Assembling pieces of a soft, flexible material into the soft housing of CHUMBYTM device poses a number of challenges.
  • One exemplary approach involves first sewing the pieces of flexible material inside out and then “turning” the resultant aggregation into its final bag-like configuration for mating (e.g., sewing) to the flexible frame 504 .
  • mating e.g., sewing
  • Binding of the flexible frame to the sewing machine In one approach a spray-on lubricant may be applied to a back of the flexible frame 504 to prevent binding of the soft housing to the foot of a sewing machine used to attach the soft housing to the frame 504 . Such binding may also be reduced by laminating a piece of smooth paper to the back of the frame 504 .
  • Another process improvement that may be employed in combination with any or all of the above is to use a post-style or anvil-style sewing machine rather than a flatbed machine.
  • Misalignment due to operator error may occur due to the compound curves involved in realizing exemplary embodiments of the CHUMBYTM device, thereby making visual alignment difficult. Such mismatch may be reduced by integrating notches, marks, and dots into the plastic frame 504 and flat pattern to act as guides for the operator of the sewing machine.
  • Edge finishing is anticipated that small errors in sewing will tend to be more apparent or otherwise noticeable if the edges of the fabric of the soft housing are rough. This degradation in appearance may be addressed by treating the edges of the fabric to make them appear finished.
  • the specific process employed depends upon the type of fabric material used. For example, in exemplary embodiments which use leather as the fabric material for the soft housing, the edges may be painted.
  • the edges may first be heat-treated (either with an open flame or a heated metal die).
  • a heated metal die may be utilized create a melted emboss pattern around the area of the die used for cutting the fabric. The melted emboss pattern will act to bind the fibers together and create a finished looking edge.
  • the edges may be painted, folded under, or have sewing tape applied.
  • the plastics or other substances forming the frame 504 are pressed in high-precision molds; in contrast, the fabric materials used for the soft housing are the products of imprecise processes. Mismatch in height between the two can create objectionable visual artifacts. When leather is used as the fabric material, these artifacts may be ameliorated by skiving the leather so as to control its height prior to sewing to the frame 504 . Also, the plastics or other materials used for the frame 504 will generally be molded such that they rise above the height of the finished leather over anticipated manufacturing tolerances. This reduces the visual impact of any imperfections, particularly when the device is viewed from “head-on”.
  • the process of initially integrating multiple pieces of flexible material into the soft prior to attachment to the frame 504 also poses a number of challenges.
  • One exemplary process pertinent to a soft housing comprised of leather is described below.
  • the soft housing is assembled with the four leather panels, each of which forms one of the sides of the soft housing.
  • the leather is flipped over, glued, and pounded flat so as to reduce the profile and puckering of the seams when viewed from the front.
  • the leather has its thickness skived, at least in the area of any seam, so as to reduce puckering in the area of the seam.
  • the back of the soft housing is attached at the last stage of the process, and then the device is turned inside out.
  • the leather seams are given excess length, and the material is sewn back upon itself to create a triple-stitch.
  • darts may be used to relieve stress around the curved edges of the soft housing.
  • the use of darts may adversely affect the aesthetics of the device.
  • a modified flat pattern having sufficient tolerance to handle any stresses that build up around such curved edges is utilized.
  • exemplary embodiments of the CHUMBYTM device may develop a permanent, assymetric bias in shape. The following techniques may be applied to limit the impact of these stresses.
  • a hot melt may be applied to the frame 504 after the CHUMBYTM device has been assembled.
  • the hot melt is applied on a shaped jig such that the when the hot melt cures it forces the device into a prescribed shape.
  • a stiffer fabric may be laminated to the back of soft fabrics used in the process. Although not visible from exterior to the CHUMBYTM device, the stiffness allows the natural shape of the fabric (as embodied by the flat pattern) to dominate the forces built into the stitch seams between the frame 504 and the fabric.
  • Natural fabrics such as leather, contain defects that can impact the yield of the process.
  • coarser pieces of leather may be cut using the pattern for the bottom and back pieces, so as to lessen the visual impact of these pieces while increasing the overall usage of the leather hide.
  • the material selection for the frame 504 plays a large role in the manufacturability of the soft housing.
  • the soft frame 504 will preferably comprise a material which is flexible yet does not stretch easily. It will typically be sufficiently soft to permit a sewing needle to penetrate without breaking.
  • One embodiment uses a TPU type of plastic to implement the frame 504 . This type of plastic has the advantage that the soft housing may be attached to using glue, but is relatively hard and sewing needles may have trouble penetrating its surface.
  • Another embodiment uses a TPE type of plastic, which is flexible, does not stretch easily, and may be easily penetrated by a needle. However, it is difficult to induce adherence to the surface of TPE.
  • Another embodiment uses a PVC/PU type of plastic, which is flexible, admits the application of glue, and is soft enough for a needle to easily penetrate.
  • an EVA foam is used for both the frame 504 and the fabric of the soft housing, or just for the frame.
  • the EVA may be cast over a mold of the desired size and allowed to set. This process may advantageously produce an integrated frame and flexible housing without sewing, and is capable accurately realizing precise geometries.
  • the use of an EVA foam for both the frame and housing of a CHUMBYTM device results in the device exhibiting a stiffer feel than other implementations.
  • FIGS. 32-33 Attention is now directed to the exemplary user interface screens of a CHUMBYTM device shown in FIGS. 32-33 , to which reference will be made in describing a process for calibration of the one or more bend sensors 650 within the device.
  • the Control Panel function is activated and the appropriate user interface is displayed ( FIG. 32 ).
  • the user can then access the “squeeze” calibration function 3300 ( FIG. 33 ) to recalibrate the bend sensor.
  • each CHUMBYTM device is intended to be essentially permanent and not replaced, in other embodiments such housings may comprise interchangeable “skins” designed to be easily detached and replaced at the discretion of the user.
  • the CHUMBYTM device may be configured to operate in accordance with various profiles depending upon the particular “skin” currently attached to the underlying hardware “core” of the device.
  • one or more sensors could be deployed upon the core of the CHUMBYTM device in order to read electronic identifiers embedded within the various skins disposed to be employed as the housing for the CHUMBYTM device.
  • Each identifier could consist of a persistent (non-volatile) storage module containing unique identifying information, and would be physically configured so as to make electrical or radio contact with a corresponding sensor on the core of the CHUMBYTM device upon its skin becoming attached to the device core.
  • the information read from such embedded identifiers could be used to inform the control system of the CHUMBYTM device of the identity of the skin currently enveloping the core of the device.
  • Certain of such skins could, for example, include characteristics or features suggestive of various applications (e.g., “clock radio”, or “boom box”) or intended operating environments (e.g., “car”, “kitchen”, “workshop”).
  • an identifier can be written into non-volatile storage integral to a “skin”. When such “skin” is mated to the core, a wired connection is established between the non-volatile storage and the “core” in such a fashion that the identifier can be read directly from such.
  • the CHUMBYTM device may send a message to the service provider 106 indicative of its current skin (e.g., “skin # 1 ”).
  • the service provider 106 may reply with a message instructing the CHUMBYTM device to utilize a particular profile (e.g., “profile # 3 ”).
  • users may elect to define, via a Web browser 122 in communication with the service provider 106 , profiles for each of their skins or simply utilize default profiles available from the service provider 106 .
  • Each profile could define, for example: (i) the widgets to be executed, (ii) the configuration to be used for executing the widgets, and (iii) the style and theme information (color schemes, control decorations, fonts, backgrounds, etc) utilized in presenting information via the LCD display 320 .
  • FIG. 7 a block diagrammatic representation is provided of the server components and other infrastructure which may be utilized to facilitate the operations of the CHUMBYTM service provider 106 . It is understood that the representation of FIG. 7 is functional in nature, and single or multiple computers may be adapted to execute software designed to perform one or more than one of the functions described below. For example, the functionality provided by the load balancers 704 may be provided by a single load balancing device or multiple load balancing devices. Similarly, each of the servers represented in FIG. 7 may be realized using either a single server computer or using a cluster comprised of primary, secondary and backup server computers interconnected in configurations familiar to those skilled in the art.
  • one or more Web servers 710 are used to define the Web interface presented by the CHUMBYTM service provider 106 to users or other interested parties.
  • a system database 712 may include, among other things, CHUMBYTM user account information, CHUMBYTM device configuration information, CHUMBYTM widget configuration and instance information, marketing materials, press information, and contact information relating to the CHUMBYTM service that is served by the Web servers 710 . Also included may be information relating to registration and first-level support.
  • a user account server 714 maintains user account data in the system database 712 and provides authentication services to the other servers depicted in FIG. 7 .
  • One or more widget servers 718 are used to serve widgets to CHUMBYTM devices 102 .
  • Each widget server 718 will typically be sufficiently powerful to encrypt and sign widgets on demand.
  • each server 718 will be configured to “store-and-forward” widgets being sent from one user to another.
  • the service provider 106 may also utilize a number of content servers 724 to provide information (e.g., new, weather, stock market information) to CHUMBYTM devices 102 .
  • information e.g., new, weather, stock market information
  • all content servers function in a “pull” mode of operation; that is, CHUMBYTM device 102 polls the applicable content server 724 for new data on some periodic basis.
  • Each response from a content server 724 preferably contains the schedule and frequency for subsequent polls.
  • a content server 724 disposed to provide stock market information can change the polling frequency to reflect whether or not the stock market is open.
  • a CHUMBYTM device 102 may be provided with the capability to change polling frequencies on the basis of, for example, environmental conditions (e.g., ambient room brightness) or other factors.
  • One or more of the content servers 724 may be used for serving certain types of content uploaded by users for use on their own or other CHUMBYTM devices 102 and stored within the system database 712 .
  • the CHUMBYTM service provider 106 will typically maintain a small number of load-balanced Network Time Protocol (NTP) servers 730 to provide time to CHUMBYTM devices 102 .
  • NTP Network Time Protocol
  • Each such server 730 will be configured to fetch their time from a “primary” NTP server, which fetches time from an upstream external public NTP server. If the primary NTP server 730 is inoperative, secondary NTP servers 730 will synchronize with a random selection of upstream servers. If all servers 730 are unavailable, a CHUMBYTM device 102 will either fetch time information from random public NTP servers or simply have its time adjusted via user input. In one embodiment each CHUMBYTM device 102 requests time upon connecting to the Internet and at jittered intervals thereafter, no more frequently than once a day.
  • NTP Network Time Protocol
  • FIG. 8 a database model diagram is provided of an exemplary object-oriented database schema 800 utilized by the system database 712 .
  • the schema 800 includes the following tables: buddies, categories, CHUMBYTM devices, parameters, profiles, skins, users, widget instance, widgets, ratings, registrations, activations, movies, templates, thumbnails.
  • Each rectangular object in FIG. 8 is an entity object representation of a table in the database 712 , with the primary key denoted with the acronym “PK”; ownership relationships indicated by dashed arrows which originate at the owned entity and terminate at the owning entity, and which are keyed by the asterisked column in the owned object; and solid arrows indicating a relationship between entities.
  • the user registration and account creation process is initiated by a user through submission, via a Web browser 122 , of a CHUMBYTM ID so as to identify a particular CHUMBYTM device 102 .
  • the act of creating a user account results in the construction of a default profile and one or more widget instances, each of which is automatically assigned to the CHUMBYTM device 102 (as identified by its CHUMBYTM ID) currently being registered.
  • a user adds a widget to the user's profile the user is presented with a list of potential categories based upon information within the categories table. The user then selects a category from the categories table, and the user is presented with a list of widgets belonging to the chosen category.
  • a widget instance is constructed and information is entered into the appropriate fields (e.g., profile id, widget id, index).
  • the user is then presented a user interface via the Web browser 122 for editing the widget-specific parameters associated with the selected widget.
  • records are appropriately updated in the parameters table.
  • FIGS. 36A-36H provide a more comprehensive tabular representation of an exemplary object-oriented database schema capable of being utilized by the system database 712 .
  • each CHUMBYTM device 102 will function as a client relative to various servers existing within the CHUMBYTM service provider 106 .
  • the CHUMBYTM devices 102 do not engage in direct communication with each other, but may do so via independent client-sever relationships established with the service provider 106 .
  • the service provider 106 may facilitate the communication of a variety of different types of executable files (e.g., widgets or other computer programs, audio clips, short “Flash” movies, etc.) among CHUMBYTM devices 102 , subject to the permission of the content owner and potential recipient.
  • a user may designate that a widget or other content be sent to another user, or to the members of a user's “buddy list” or the like. This designation may be made via a Web browser 122 in communication with the service provider 106 , or directly through the interface of the user's CHUMBYTM device 102 .
  • executable files may be created by users of CHUMBYTM devices 102 or other third parties and loaded within the system database 712 after being approved by the entity operating the service provider 106 .
  • a widget or other executable file Once a widget or other executable file has been created and stored within the system database 712 , it is made available for use by all those users of CHUMBYTM devices 102 that have been granted the requisite permission.
  • Various schemes for granting permissions among and between users are possible. For example, one such type of permission could entail that any user X that is given permission by a user Y to send widgets to user Y's CHUMBYTM device may select any widget for which user X has usage rights and “send” such widget to user Y's CHUMBYTM device.
  • widgets and other executable files could be transferred between the service provider 106 and CHUMBYTM devices 102 in a number of different formats, in one embodiment such transfers will occur in the Flash movie format (i.e., as .swf files, when not signed or encrypted).
  • the process for downloading widgets from the service provider 106 includes receiving a notification at a CHUMBYTM device 102 that a “new” widget is ready for downloading. Since in the exemplary embodiment each CHUMBYTM device 102 acts in a “pull” mode, each device 102 periodically polls the service provider and inquires as to whether any configuration changes are available to load. In the case in which a new widget is available for downloading, the CHUMBYTM device 102 will generally use standard HTTP (or HTTPS) protocols in downloading the applicable widget file.
  • FIGS. 9-13 are a series of signal flow diagrams representative of the client-server communication protocol established between a CHUMBYTM device 102 and the CHUMBYTM service provider 106 .
  • each CHUMBYTM device 102 functions as a client relative to the CHUMBYTM service provider 106 .
  • the basic protocol established between each CHUMBYTM device and the corresponding server entity of the CHUMBYTM service provider 106 may be characterized as XML using a Representational State Transfer (REST) architecture transmitted using HTTP.
  • REST Representational State Transfer
  • the CHUMBYTM device 102 issues periodic HTTP GET or POST requests and the service provider 106 responds with a block of XML.
  • the CHUMBYTM device 102 will use HTTP GET for relatively simple requests, and POST for more complex requests, which will be in encapsulated in XML. Individual data elements are uniquely identified by Global Unique Identifiers (GUID). In one embodiment, there will be some form of cryptographic key exchange and transactions will be encrypted using those keys. Furthermore, XML may be compressed in order to facilitate transfer between the CHUMBYTM device 102 and the CHUMBYTM service provider 106 .
  • GUID Global Unique Identifiers
  • Each CHUMBYTM device 102 will have a unique GUID.
  • time codes will be represented in ISO-8061 format.
  • a signal flow diagram 900 illustratively represents one manner in which a “CHUMBYTM configuration” is provided to a CHUMBYTM device 102 by the service provider 106 .
  • each CHUMBYTM device 102 operates in accordance with a configuration, which specifies the profile to be loaded by the CHUMBYTM device 102 under various conditions.
  • the user specifies the profile for the CHUMBYTM device 102 via a web interface at the CHUMBYTM web site.
  • the profile contains several operational parameters for the CHUMBYTM device 102 .
  • the requesting of a configuration is initiated when the CHUMBYTM device 102 sends an HTTP GET request containing the GUID of the requested configuration to a CHUMBYTM configuration object within the system database 712 maintained by the service provider 106 (stage 902 ).
  • HTTP GET request containing the GUID of the requested configuration to a CHUMBYTM configuration object within the system database 712 maintained by the service provider 106 (stage 902 ).
  • An example of such a request is provided below:
  • the service provider 106 receives the request (stage 904 ), and retrieves the requested configuration from the system database 712 (stage 908 ). If the requested configuration exists, the service provider responds with an XML-based configuration; if not, the service provider 106 responds with an XML-based error message (stage 912 ).
  • a signal flow diagram 1000 illustratively represents one manner in which a “profile” is provided to a CHUMBYTM device 102 by the service provider 106 .
  • each CHUMBYTM device 102 operates in accordance with a profile, which specifies the set of widgets to be executed by the CHUMBYTM device 102 under various conditions. This enables a user to specify that a certain subset of the available set of widgets is to be instantiated and utilized during a particular time frame, based upon the location of the user's CHUMBYTM device 102 or the skin (or housing) within which the CHUMBYTM device 102 is currently seated. For instance, the user may desire that local weather and traffic information be provided while the user is located at home, but would prefer that airline flight information be available from the CHUMBYTM device 102 when the user is traveling.
  • the requesting of a profile is initiated when the CHUMBYTM device 102 sends an HTTP GET request containing the GUID of the requested profile to a profile object within the system database 712 maintained by the service provider 106 (stage 1002 ).
  • HTTP GET request containing the GUID of the requested profile to a profile object within the system database 712 maintained by the service provider 106 (stage 1002 ).
  • An example of such a request is provided below:
  • the service provider 106 receives the request (stage 1004 ), and retrieves the requested profile from the system database 712 (stage 1008 ). If the requested profile exists, the service provider responds with an XML-based profile; if not, the service provider 106 responds with an XML-based error message (stage 1012 ).
  • Each Profile has a name, a description, a skin, and a list of “Widget Instances”.
  • the Profile will be periodically refetched in order to reflect changes made by the owner, for instance, adding and removing Widget Instances.
  • the Profile may also contain a “buddies_of” node, which contains information about users and profiles that have indicated the owner of the Profile to be a “buddy” in order to facilitate the sending of widget instances.
  • the CHUMBYTM device 102 processes each Widget Instance in turn, fetching the settings for each widget, and the Widget itself, and displays the Widget with the settings encapsulated by the Widget Instance.
  • a process similar to that described with reference to FIG. 9 may be used to change a profile.
  • An example of an HTTP POST containing an the GUID of the profile to modify and an XML-based request to change a profile generated by the CHUMBYTM device 102 is given below:
  • FIGS. 11-12 there are shown signal flow diagrams representative of the communication of widget instance information from the CHUMBYTM device 102 to the service provider 106 , and vice-versa.
  • the set of parameters associated with a widget instance determine the user-specified manner in which the behavior of the widget is modified when executed by a CHUMBYTM device 102 . That is, the parameters fetched by the CHUMBYTM device 102 from the service provider 106 for a given widget constitute the user's “customized” settings, rather than dynamic content.
  • the applicable parameters could comprise the names and symbols of the stocks within the user's portfolios, but would not define or relate to the current prices of the stocks (which would be furnished by another service supplied by the service provider 106 ).
  • FIG. 11 is a signal flow diagram which depicts processing of changes made to the parameters of a widget instance through the interface of the CHUMBYTM device 102 in which the widget is instantiated.
  • parameter changes could include changing a location of interest in the case of a “weather” widget, or adding/removing stock ticker symbols in the case of a “stock market” widget.
  • the service provider 106 will effectively “expand” the parameter change data into a full parameter record once received.
  • a zip code could be sufficient to uniquely identify a location in the case of a weather widget, and the associated city, state, etc. could be supplied to the applicable record during processing of the parameter change request by the service provider 106 .
  • the widget instance change operation is initiated when the CHUMBYTM device 102 sends an HTTP POST and an XML request to a widget instance object within the system database 712 maintained by the service provider 106 (stage 1102 ).
  • This type of “UPLOAD” operation informs the service 106 that the parameters of a specific widget instance have been updated by the applicable user.
  • the updated parameters are received by the service provider (stage 1104 ), and are attempted to be written to a corresponding widget instance object within the system database 712 (stage 1108 ). If this attempted write operation is unsuccessful (stage 1112 ), the service provider 106 responds with an error message that is processed by the requesting CHUMBYTM device 102 (stage 1120 ). If the write operation is successful, the newly updated widget instance are retrieved from the system database 712 (stage 1116 ) and sent to the applicable CHUMBYTM device 102 (stage 1120 ).
  • the widget instance is processed by the CHUMBYTM device 102 (stage 1124 ).
  • the processing of the parameters contained in a widget instance are dependent upon the characteristics of the particular widget.
  • the parameters may be sufficient to enable the widget to display information, while other widgets may use the parameters to fetch content from another service.
  • a “clock” widget capable of displaying information following receipt of a parameter indicating a time zone.
  • a “stock widget” may have stock symbols as parameters and use such symbols to fetch quote information.
  • FIG. 12 there is shown a signal flow diagram illustrating an exemplary widget instance download operation in which the service provider 106 is requested to push values of widget-specific parameters to a requesting CHUMBYTM device 102 .
  • the requesting of a parameter download is initiated when the CHUMBYTM device 102 sends an HTTP GET containing the GUID of the requested widget instance request to a parameter object within the system database 712 maintained by the service provider 106 (stage 1202 ).
  • An example of such a request in the case of a “weather” widget is provided below:
  • the service provider 106 receives the request (stage 1204 ), and retrieves the requested parameters from the system database 712 (stage 1208 ). If the requested parameters exist, the service provider 106 responds with an XML-based widget instance message (stage 1212 ).
  • a weather widget which utilizes a zip code to identify the location for which weather is to be retrieved
  • ⁇ widget_instance id “5D81823A-E77D-11DA-B4BD-00306555C864”>
  • ⁇ widget href “/xml/widgets/BF4CE814-DFB8-11DA-9C82-00306555C864”
  • id “BF4CE814- DFB8-11DA-9C82-00306555C864”/>
  • profile href “/xml/profiles/00000000-0000-0000-
  • the CHUMBYTM device 102 uses the GUID in the “widget” tag to fetch the information about the Widget to be displayed. Once the widget has been started, it is passed the name/value pairs in the “widget parameters” section, in order to customize the behavior of the widget.
  • the “mode” tag indicates how long the widget is to be played. A value of “default” in the mode attribute indicates that the timing will be specified by the widget description, an attribute value of “timeout” will use the duration specified in the “time” attribute (in seconds), and the value of “cooperative” will display the widget until the user explicitly commands it to stop through a UI element, or the widget itself indicates that it wishes to discontinue operation.
  • the presence of a “received” node indicates that the widget instance has been “sent” by a buddy.
  • the value of the “accepted” attribute indicates whether or not the widget instance has been accepted by the recipient, which is done either through the web interface or through the UI of the device.
  • the “forward” attribute indicates whether this widget instance can be sent on to another user.
  • a default widget instance is attempted to be retrieved from the system database 712 (stage 1224 ). If such a widget instance exists (stage 1228 ), the service provider 106 responds with an XML-based parameters message that is processed by the CHUMBYTM device 102 upon receipt (stage 1220 ). If such a default widget instance does not exist, an error message is returned to the CHUMBYTM device 102 (stage 1232 ).
  • a signal flow diagram 2700 is provided which illustratively represents the process of downloading the code for a widget (e.g., a .swf file) from the service provider 106 for execution on a CHUMBYTM device 102 .
  • the process is initiated when the CHUMBYTM device 102 sends an HTTP GET request containing the GUID of the requested widget to a specific widget description object within the system database 712 maintained by the service provider 106 (stage 1302 ).
  • An example of such a request is provided below:
  • the service provider 106 receives the request (stage 2704 ), and attempts to retrieve the requested widget description from the system database 712 or other data source available to the service provider 106 (stage 2708 ). If the requested widget description is able to be retrieved, the service provider 106 responds with an XML-based widget description message; if not, the service provider 106 responds with an XML-based error message (stage 2712 ).
  • the CHUMBYTM device 102 uses the URL referencing the “movie” for the requested widget to download the movie (e.g., .swf) file from the service provider 106 .
  • the CHUMBYTM device 102 sends an HTTP GET request containing the GUID of the requested movie to a specific movie object within the system database 712 maintained by the service provider 106 (stage 1320 ).
  • An example of such a request is provided below:
  • the service provider 106 receives the request (stage 2724 ), and attempts to retrieve the requested movie from the system database 712 or other data source available to the service provider 106 (stage 2728 ). If the requested movie is able to be retrieved, the service provider 106 responds with the .swf file which implements the movie; if not, the service provider 106 responds with an XML-based error message (stage 2732 ). Once the requested movie is received by the CHUMBYTM device 102 , it is loaded by the Master Controller and queued for subsequent execution (stage 2736 ). If an error is instead received, it is processed accordingly (stage 2740 ).
  • a signal flow diagram 1300 is provided which illustratively represents the process of obtaining content from the service provider 106 for a widget of a CHUMBYTM device 102 .
  • the process is initiated when the CHUMBYTM device 102 sends an HTTP GET and an optional XML request to a specific content object within the system database 712 maintained by the service provider 106 (stage 1302 ).
  • An example of such a request for content for a “tide” widget is provided below: http://content.chumby.com/tides/United%20States/ National%20City%2C%20San%20Diego%20Bay% 2C%20California
  • the service provider 106 receives the request (stage 1304 ), and attempts to retrieve the requested content from the system database 712 , internal content service, external content service or other data source available to the service provider 106 (stage 1308 ). If the requested content is able to be retrieved, the service provider 106 responds with an XML-based content message; if not, the service provider 106 responds with an XML-based error message (stage 1312 ). Once the requested content is received by the CHUMBYTM device 102 , corresponding audiovisual output is generated by the device 102 for the benefit of its user (stage 1316 ). If an error is instead received, it is processed accordingly (stage 1320 ).
  • CHUMBYTM devices 102 may optionally include a hardware security module, which in one implementation is accessed via a character driver interface in the operating system (“OS”) of the device 102 .
  • the module may or may not be installed.
  • the OS preferably virtualizes the hardware security module by emulating it in software. While losing all the tamper-resistance benefits of a hardware module, this feature enables cost reduction savings while maintaining protocol interoperability with a secured system.
  • the hardware security module of a CHUMBYTM device 102 may be implemented in a number of ways.
  • the hardware security module may be implemented using a monolithic security processor or a cryptographic Smart Card module. This module, or its emulated counterpart, is capable of at a minimum, the following operations: (1) storage of secret numbers in hardware; (2) the ability to compute public-key signatures; (3) the ability to compute one-way cryptographic hashes; and (4) the ability to generate trusted random numbers.
  • the hardware security module is initialized with a set of secret numbers that are only known to the module and to the CHUMBYTM service provider 106 .
  • These secret numbers may or may not consist of public and private keys. If the numbers consist of public and private keys, then a mutual key-pair is stored by both the CHUMBYTM service provider 106 and the hardware module, along with a putative, insecure identifier number for the pair. Furthermore, these numbers are preferably not recorded by the CHUMBYTM service provider 106 in association with any other identifying information, such as the MAC address for the WLAN interface, or any other serial numbers that are stored in insecure memory for customer service purposes.
  • the CHUMBYTM device 102 sends the putative insecure key-pair identifier to the service provider 106 .
  • the service provider 106 looks up the putative insecure key-pair identifier and issues a challenge to the hardware module, consisting of a random number
  • the challenge is packetized and sent through the Internet to the CHUMBYTM device 102 .
  • the device 102 unpacks the challenge and passes it directly to the hardware module.
  • the hardware module adds another random number to the packet and signs the pair of numbers, along with other transaction information (such as the version number of the protocol) with a private key that is only known to the CHUMBY cryptoprocessor.
  • an “owner key” may optionally be encrypted to the server public key.
  • this message is packetized and transmitted by the device 102 to the service provider 106 over the Internet.
  • the service provider 106 verifies the signature of the packet using the device's public key, which was generated and recorded at the time of manufacture and indexed by the hash of the putative insecure key-pair identifier.
  • the CHUMBY device is deemed authentic if the signature is correct and the signed packet contains the exact random number that was generated by the service provider in the first step of the challenge.
  • the service provide 106 also decrypts the owner key, whose purpose is discussed in the next paragraph.
  • this authentication transaction does not involve uniquely associating the hardware module with user information. Rather, the service provider 106 is simply aware of the existence of the approved hardware module and upon completion of the authentication transaction may safely trust the integrity of the secrets stored therein.
  • the owner key comprises a random number (or one of a set of random numbers) generated at the time of manufacture and stored only within the cryptographic processor.
  • the owner key is transmitted to the server, encrypted using the server public key, and used as a shared secret to protect any other secrets (user passwords, credit card information, etc.) that may be stored on the server.
  • a user of the device 102 may opt-out of privacy mode and provide identifying information, as required by some billing services such as credit cards and banks.
  • some billing services such as credit cards and banks.
  • an anonymous cash-based transaction network can be established where accounts are opened and managed only by secrets contained within the hardware module.
  • the specific embodiment of the master authentication protocol should operate on a set of clean-room servers with a multiplicity of connections that are trusted by the CHUMBYTM service provider 106 , and authenticated session keys are then passed on laterally to the content servers.
  • the anonymity of the master authentication key is nominally preserved, although it is possible to recreate and correlate transactions from forensic logs and transaction timings.
  • the use of multiple servers and multiple connections, along with network routing randomization techniques, can be used to increase the anonymization resistance to forensic logging (cf. Tor network), but this configuration is in no way essential to the network's operation.
  • FIGS. 14-21 are a set of flowcharts representative of the calibration, registration and initial operation of a CHUMBYTM device and associated account management functions.
  • FIG. 14 is a flowchart 1400 which depicts an exemplary sequence of operations performed by a CHUMBYTM device 102 upon initial power-up.
  • a user initially connects a CHUMBYTM device 102 to a power source
  • the device 102 undergoes a touchscreen calibration process described below with reference to FIGS. 15-16 (stage 1404 ).
  • the device 102 selects a wireless base station in the manner described below with reference to FIG. 17 (stage 1408 ).
  • a proxy server is identified (stage 1412 )
  • information relating to the proxy server is configured into the CHUMBYTM device 102 to enable it to with the Web site maintained by the service provider 106 (as well as with the Web sites of content providers) (stage 1416 ).
  • the user of the CHUMBYTM device 102 is prompted to set the time zone in which the device 102 is located (stage 1420 ). If an NTP server is determined to be available (stage 1430 ), then time is set automatically based upon information acquired from such a server (stage 1440 ). If not, the CHUMBYTM device 102 is referenced to a time set manually (stage 1444 ). After the time of the CHUMBYTM device 102 has been set, the registration process described below with reference to FIG. 18 is initiated (stage 1450 ).
  • a CHUMBYTM device downloads configuration information from the service provider 106 each time it is powered on or otherwise re-establishes communication with the service provider 106 .
  • a minimal amount of widget and configuration information may be locally stored on a CHUMBYTM device so that it may continue to function in the absence of network connectivity.
  • a clock widget may be permanently stored on a CHUMBYTM device so that its clock function could remain operational at all times.
  • a CHUMBYTM device will typically include sufficient memory capacity to hold configuration information received from the service provider 106 for all of the widgets to be executed by the device, up to some reasonable number of widgets.
  • a polling function implemented on the corresponding CHUMBYTM device will typically be used to “pull” the modified configuration information from the service provider 106 .
  • an operation may be manually initiated via the interface of the corresponding CHUMBYTM device in order to obtain this information (e.g., an “Update My CHUMBYTM Device Now” operation).
  • FIG. 15 there is shown a flowchart which illustrates an exemplary routine used to calibrate the touchscreen of a CHUMBYTM device 102 .
  • FIGS. 16A-16E provide a set of screen shots of the user interface of the CHUMBYTM device 102 being calibrated pursuant to the routine of FIG. 15 .
  • the calibration routine involves determining an upper left set point (stage 1502 ). This set point is determined by generating a target 1602 ( FIG. 16A ) through the LCD screen 320 which the user is then prompted to tap. A lower right set point is then determined by prompting the user to tap a target 1604 depicted in FIG. 16D (stage 1506 ).
  • the user is instructed to test the touch screen calibration (stage 1510 ) by dragging the ball 1605 depicted in FIG. 16C from ring A 1606 to ring B 1607 .
  • a notification of success 1608 as depicted in FIG. 16D will be displayed and done button 1609 will be activated.
  • the results of the calibration process are then stored (stage 1514 ).
  • the CPU 302 executes a program to generate calibration information used during subsequent operation of the device 102 .
  • FIG. 17 is a flowchart illustrating the operations performed in selecting a wireless base station upon initial power-up of the device 102 .
  • the Wi-Fi communications interface 314 of the device initially searches for one or more access points 210 emitting a beacon signal (stage 1702 ). If the device is configured to search for access points not emitting a beacon signal (stage 1706 ), then a keyboard is accessed (stage 1710 ) and data designating an access point is entered (stage 1714 ).
  • the keyboard may comprise a physical keyboard connected to the device 102 as a peripheral component. Alternatively, an “onscreen” keyboard generated by the LCD screen 320 and interacted with via the touchscreen 330 may be utilized.
  • a subsequent scan (stage 1715 ) will be initiated in an attempt to find the access point that was not emitting a beacon signal.
  • the user is given the option to select one from a list (stage 1717 ).
  • the CPU 302 executes a program to determine various aspects of the chosen wireless network (stage 1718 ), including but not limited to authentication mode, encryption type, channel/frequency, etc. If a suitable network is not detected, the user may be given the choice to enter the network configuration properties (e.g. SSID, authentication mode, etc) manually (stage 1730 ).
  • a keyboard (stage 1710 ) is displayed and the user is prompted to enter the network properties (stage 1731 ). If the selected or designated network requires authentication (e.g., WPA, WPA2, etc) and/or or is otherwise encrypted (e.g., WEP, AES, TKIP, etc), a keyboard (stage 1710 ) is displayed and the user is given the opportunity to enter the applicable key (stage 1720 ). In the event that a user enters a WEP key, the key size will be determined automatically by the length of the key entered by the user. The user is then presented with a choice of automatic or manual IP allocation (stage 1732 ).
  • a keyboard (stage 1710 ) is displayed and the user is prompted to enter IP related configuration data (stage 1733 ) such as IP address, netmask, gateway, nameservers, etc.
  • IP related configuration data such as IP address, netmask, gateway, nameservers, etc.
  • the user will be asked to confirm the network settings (stage 1735 ).
  • a connection is then attempted to be established with a detected or designated access point (stage 1740 ). If a connection is so established (stage 1750 ), then the information relating to the connection is stored within the memory of the device 102 (stage 1755 ); otherwise the user is given the option to reattempt to establish the connection.
  • FIG. 18 a flowchart is provided of an exemplary account creation and registration process 1450 .
  • the process begins upon presentation by the device, via its LCD screen 320 , of its serial number or other identifying information (stage 1802 ).
  • the user logs in, via a Web browser 122 , to a web site operated by the service provider 106 (e.g., www.chumby.com) (stage 1804 ).
  • the user may then select a “create new user account” tab or the like (stage 1808 ), and is prompted to enter an email address (stage 1810 ), password (stage 1812 ), and name (stage 1816 ).
  • the user may also be offered the opportunity to enter his or her address (stage 1820 ), while in other implementations the user is not prompted to provide an address until this information is required for some particular purpose (e.g., to provide a billing information for a subscription or shipping information for a product purchase). If this option is selected, the user enters his or her address (stage 1824 ). In certain implementations, the user may be prompted to provide other identifying and/or demographic information (not shown in this figure). At this point the service provider 106 sends an email to the address entered in stage 1810 which contains a “click through” account activation hyperlink (stage 1830 ).
  • stage 1834 the user is provided with the opportunity to take advantage of various customer service options in order to remedy the account creation difficulties being experienced (stages 1840 - 1841 ).
  • the account creation process is then finalized (stage 1850 ), and the CHUMBYTM device being registered is associated within the system database 712 with a particular user account in the manner described below (stage 1854 ). Once this has occurred a default configuration and a number of widget instances are established for the newly registered CHUMBYTM device (stage 1860 ).
  • FIG. 19 is a flowchart representative of exemplary Web-based interaction occurring between a user and the service provider 106 in connection with associating a particular CHUMBYTM device with the user's account.
  • the process is initiated when the user logs in to a Web site operated by the service provider 106 (stage 1902 ) and selects an “Activate a CHUMBYTM” link or the equivalent (stage 1904 ).
  • the user enters a name of the CHUMBYTM device (e.g., bedroom, study, Fred, evening, etc.) (stage 1908 ) and then, as described in the above-referenced co-pending U.S. Provisional Application Ser. No.
  • the user duplicates the “captcha grid” pattern displayed on the “Activate a CHUMBYTM” page on the corresponding “Activate CHUMBYTM” screen on the CHUMBYTM device and selects “OK” (stage 1910 ).
  • the CHUMBYTM device then transmits the encoded pattern along with the putative id (unique serial number) of the CHUMBYTM device to the server for verification and association with the user's account.
  • the user may directly enter the putative id (unique serial number) of the user's CHUMBYTM device into the Web page and selects “OK” (stage 1910 ).
  • An association is then created between the user's CHUMBYTM device and the applicable account within the system database 712 .
  • user accounts are configured to be capable of hosting and moderating sub-accounts.
  • FIG. 20 a flowchart is provided of exemplary Web-based interaction occurring between a user and the service provider 106 with regard to disabling a CHUMBYTM device that has been previously associated with the user's account.
  • the user logs in to the account via a Web browser 122 (stage 2002 ) and selects a “Disable CHUMBYTM device” tab or the equivalent (stage 2004 ).
  • the user selects the CHUMBYTM device to be disabled from a list based upon either the device's serial number or description (stage 2006 ).
  • the user is prompted to confirm the selection (stage 2010 ), and if so all references to the disabled CHUMBYTM device are removed from the directory maintained within the system database 712 (stage 2014 ).
  • the process is then completed whether or not the selection is confirmed (stage 2020 ), at which point the service provider 106 no longer responds to requests from the CHUMBYTM device which has been disabled.
  • FIG. 21 is a flowchart which represents exemplary Web-based interaction occurring between a user and the service provider 106 in connection with “mirroring” CHUMBYTM devices; that is, enabling one CHUMBYTM device to utilize the widget set and configuration of another CHUMBYTM device.
  • a given CHUMBYTM device i.e., the “slave device”
  • another CHUMBYTM device i.e., the “master device”
  • the user logs in to the applicable account via a Web browser 122 (stage 2102 ) and selects a “Mirror this CHUMBYTM device” tab or the equivalent (stage 2104 ). The user then selects the CHUMBYTM device to be the “master” (stage 2108 ) and further selects the CHUMBYTM device to the “slave” (stage 2112 ).
  • the master CHUMBYTM device need not correspond to a physical device, but could instead constitute a “virtual” CHUMBYTM device defined within the system database 712 . In this case changes made to the widget set or configuration of the virtual CHUMBYTM device would be mirrored by all of its slave CHUMBYTM devices.
  • the slave CHUMBYTM device need not correspond to a physical device, but could instead constitute a “virtual” CHUMBYTM device defined within the system database 712 .
  • FIGS. 22-25 , 37 and 38 are a set of flowcharts representative of Web-based widget selection, removal and configuration processes contemplated by embodiments of the present invention.
  • Screen shots of exemplary user interfaces presented by the Web browser 122 or, alternatively, the screen 320 of the applicable CHUMBYTM personal audiovisual device 102 , which are used to facilitate certain of these processes are illustrated in FIG. 26 .
  • FIG. 22 a top-level flowchart 2200 is provided of exemplary Web-based interaction occurring between a device user and the service provider 106 with regard to adding, removing and configuring widget profiles relative to the user's CHUMBYTM device.
  • this interaction between a device user and the service provider 106 may be effected through user interface screens presented by the user's CHUMBYTM device in lieu of the Web browser 122 .
  • a user may have the impression that a CHUMBYTM device itself is being configured through the process of FIG. 22
  • a profile currently assigned to the user's CHUMBYTM device is instead configured.
  • the user logs in to the user's account maintained with the service provider 106 via a Web browser 122 (stage 2202 ) and proceeds to the user's “home page” or the equivalent (stage 2204 ). From this home page the user selects a “Set Up” device tab or the like (stage 2208 ) and the Web browser 122 presents a corresponding “Set Up” page (stage 2210 ). The user then selects the CHUMBYTM device profile to be configured from a list based upon either the device's serial number or description (stage 2212 ). The current configuration for the selected device profile is then retrieved from the system database 712 and loaded into the device (stage 2216 ).
  • Such actions may include, for example, adding, deleting or editing widget profiles. If the user opts to add widget profiles (stage 2224 ), then the Web browser 122 displays an “Add Widgets Page” through which widget profiles may be added to the current configuration of the applicable CHUMBYTM device in the manner described below with reference to FIG. 23 (stage 2228 ). If the user instead chooses to delete widget profiles from such current configuration (stage 2232 ), then a “Delete Widgets Page” is presented through which the deletion operation may be completed consistent with the approach described below with reference to FIG. 24 (stage 2236 ). Alternatively, the user may select another CHUMBYTM device profile to configure (stage 2240 ), or simply exit and return to the user's home page (stage 2244 ).
  • FIG. 37 an alternate top-level flowchart 3700 is provided of exemplary Web-based interaction occurring between a device user and the service provider 106 with regard to adding, removing and configuring widget profiles relative to the user's CHUMBYTM device.
  • a user may have the impression that a CHUMBYTM device itself is being configured through the process of FIG. 37
  • a profile currently assigned to the user's CHUMBYTM device is instead configured.
  • the user logs in to the user's account maintained with the service provider 106 via a Web browser 122 (stage 3702 ) and proceeds to the user's “MY CHUMBYTM page” or the equivalent, as is illustrated by FIG. 39A (stage 3704 ).
  • the user optionally selects the CHUMBYTM device to be configured from a list or the like, as is illustrated by FIG. 39B (stage 3706 ) and the Web browser 122 loads the currently configured widget channel into the current page (stage 3708 ).
  • the user then optionally selects the CHUMBYTM widget channel to be configured from a list or the like, as is illustrated by FIG. 39C (stage 3710 ).
  • the current channel configuration for the selected CHUMBYTM device is then updated in the system database 712 , loaded into the current page (stage 3712 ) and loaded by the currently selected CHUMBYTM device (stage 3713 ).
  • the user may select the “Edit Channel” option (stage 3714 ), following which a “Edit Channel Page” is presented, as is illustrated by FIG. 39D (stage 3716 ), with the widget configuration for the selected channel is loaded into the page (stage 3718 ).
  • the user may select an action to be performed (stage 3720 ).
  • Such actions may include, for example, changing, renaming, deleting or creating new widget channels; adding widgets to, removing widgets from, changing playback order of widgets within or configuring widgets within the selected channel.
  • the widget instance for the affected widget and/or the configuration for the selected channel within the system database 712 are updated, which subsequently effects a corresponding update to the local copy of the channel configuration of all CHUMBYTM devices currently “playing” the selected channel (stage 3728 ).
  • the configuration for the selected channel within the system database 712 is updated which subsequently effects a corresponding update to the local copy of the channel configuration of all CHUMBYTM devices currently “playing” the selected channel (stage 3734 ).
  • the user may select another channel to configure (stage 3740 ), or navigate to another page (stages 3742 , 3744 ).
  • FIG. 23 is a flowchart 2300 representative of exemplary Web-based interaction occurring between a device user and the service provider 106 with respect to the addition of widgets to the current configuration of the user's CHUMBYTM device.
  • this interaction between a device user and the service provider 106 may be effected through user interface screens presented by the user's CHUMBYTM device in lieu of the Web browser 122 .
  • the user is provided with the opportunity to choose, through an appropriate category selection page (see, e.g., FIG. 26B ) presented by a Web browser 122 , among various widget categories retrieved from the categories table of the system database 712 (stage 2302 ).
  • both the widgets included within the selected category and the current widget configuration of the applicable CHUMBYTM device are presented to the user (stage 2308 ).
  • the user selects an action to perform (stage 2312 ) including, for example, exiting the widget addition process (stage 2316 ) or navigating the list of widgets presented for the selected category (stage 2320 ). If the latter action is selected (see, e.g., FIGS. 26C-26D ), the user then selects a widget to be added to the current configuration (e.g., by selecting a corresponding icon) and the service provider 106 constructs an instance of the selected widget (stage 2324 ).
  • a widget configuration phase (stage 2332 ) may be entered (see, e.g., FIG. 26E ). If the user declines to select a widget while navigating the list of widgets presented for a selected category during stage 2320 , a new category of widgets may be selected (stage 2340 ).
  • the user may perform one of several actions, including, but not limited to: select another CHUMBYTM device to configure; navigate to another page on the CHUMBYTM site; log out from the CHUMBYTM site; or close the applicable browser window (stage 2316 ). If the user instead chooses to save the current widget configuration for the applicable CHUMBYTM device (stage 2350 ), the user selects a “Submit”, “Commit”, “Ok” or similar button to cause any changes made to be recorded in the system database 712 (stage 2354 ). After either saving the current widget configuration or electing to exit the process, the user may be directed to a predefined page (stage 2360 ).
  • FIG. 38 is an alternate flowchart 3800 representative of exemplary Web-based interaction occurring between a device user and the service provider 106 with respect to the addition of widgets to a channel configuration.
  • the user is provided with the opportunity to choose, through an appropriate category selection list on the EDIT CHANNEL Page (see, e.g., FIG. 39D ) presented by a Web browser 122 , among various widget categories retrieved from the categories table of the system database 712 (stage 3802 ).
  • the widgets included within the selected category are presented to the user, as is illustrated by FIG. 39F (stage 3808 ).
  • the user selects an action to perform including, for example, navigating to another page (stage 3832 ) or navigating the list of widgets presented for the selected category (stage 3812 ). If the latter action is selected (see, e.g., FIG. 39G ), the user then selects a widget to be added to the current configuration by selecting a widget from the “widgets” list (stage 3816 ), which causes the selected widget to be displayed (stage 3820 ), and then selecting the ADD TO CHANNEL button (stage 3824 ), which causes the service provider 106 to construct an instance of the selected widget and update the configuration for the current channel in the system database 712 (stage 3828 ).
  • an action to perform including, for example, navigating to another page (stage 3832 ) or navigating the list of widgets presented for the selected category (stage 3812 ). If the latter action is selected (see, e.g., FIG. 39G ), the user then selects a widget to be added to the current configuration by selecting a widget from the “widgets”
  • the user may also opt to iteratively navigate the widget list (stage 3812 ), select widgets (stage 3816 ) and add more widgets to the current configuration (stage 3824 ).
  • other widget and/or channel operations may be selected and/or executed by the user (stage 3840 ), including, but not limited to: configuring a widget instance (see, e.g., FIG. 39H ), a widget deletion, altering widget playback ordering within the channel, renaming the current channel, deleting the current channel, creating a new channel and/or selecting a new category of widgets may be selected (stage 3850 ).
  • the user may perform one of several actions, including, but not limited to: select another channel to configure, as is illustrated by FIG. 39E ; navigate to another page on the CHUMBYTM site (stage 3832 ); log out from the CHUMBYTM site; or close the applicable browser window.
  • a flowchart 2400 is provided which is representative of exemplary Web-based interaction occurring between a device user and the service provider 106 in connection with the removal of widgets from the current configuration of the user's CHUMBYTM device.
  • this interaction between a device user and the service provider 106 may be effected through user interface screens presented by the user's CHUMBYTM device in lieu of the Web browser 122 .
  • the user may elect to either de-activate a selected widget (stage 2406 ), delete (or remove) a selected widget (stage 2410 ), or select some other widget, channel and/or page navigation operation (stage 2414 ). If widget de-activation is chosen, the user is prompted to confirm the choice (stage 2418 ). Once such confirmation has been provided the widget is marked as “inactive” on the page currently being rendered by the Web browser 122 (stage 2420 ). In addition, the widget instance configuration for the selected channel is updated within the system database 712 (stage 2424 ) and any CHUMBYTM devices currently displaying the selected channel are updated.
  • the user is optionally prompted to confirm the choice (stage 2438 ).
  • the widget is removed from the page currently being rendered by the Web browser 122 (stage 2440 ), the widget instance is “deleted” from the channel configuration in the system database 712 (stage 2424 ) and any CHUMBYTM devices currently displaying the selected channel are updated. If confirmation to de-activate or delete the selected widget is required, but not provided (stages 2418 and 2438 ), the operation is aborted.
  • an alternate flowchart 4100 is provided which is representative of exemplary interaction occurring, via the CHUMBYTM device of a user, between such user and the service provider 106 in connection with the removal of widgets from the current configuration of the user's CHUMBYTM device.
  • a widget displayed on the screen 320 of the CHUMBYTM device stage 4102
  • the user performs the gesture which selects the Control Panel (stage 4104 ).
  • the Control Panel Upon being presented with the Control Panel, as is illustrated by FIG.
  • the user may optionally use the widget navigation controls to singly or iteratively select a new current widget (stage 4116 ), in which case the new current widget is loaded (stage 4120 ) and its avatar displayed (stage 4112 ).
  • the user may then elect to delete (or remove) the current widget by selecting DELETE (stage 4124 ). If widget deletion is chosen, the user is prompted to confirm the choice, as is illustrated by FIG. 40B (stage 4128 ). If the user confirms the deletion (stage 4132 ), the widget instance is deleted from the channel on the CHUMBYTM device and the widget instance is “deleted” from the channel configuration in the system database 712 (stage 4136 ).
  • the delete confirmation screen is exited (stage 4140 ) and the Control Panel is displayed.
  • the user has the option to select HIDE CONTROL PANEL (stage 4144 ), which exits the control panel and resumes normal widget play.
  • FIG. 25 is a flowchart 2500 depicting an exemplary set of operations involved in configuring parameters specific to of one or more widgets currently associated with a given CHUMBYTM device.
  • the process is initiated by accessing the configuration of a selected widget instance maintained within the system database (stage 2502 ).
  • An appropriate user interface through which the existing configuration of the selected widget may be edited is then generated based upon such existing configuration (stage 2504 ). This may involve, for example, establishing various inter-field dependencies based upon the existing configuration (stage 2508 ).
  • stage 2508 Once the user interface has been generated it is presented to the user via a Web browser 122 in order to enable desired changes to the configuration to be made, as is illustrated by FIG. 39H (stage 2512 ).
  • the user interface defining the widget configuration is correspondingly changed (stage 2520 ). If a user elects to not edit any of these fields, the user is given the option of selecting a “default configuration” (stage 2524 ). To the extent this option is selected, all fields are reset to default values (stage 2528 ); otherwise, the user is given the option to exit the process or return to stage 2516 (stage 2540 ). When the process is exited, the user is given the option of saving the edited version of the configuration in the system database 712 (stage 2544 ). If this option is selected, the current widget configuration is saved to the database 712 (stage 2550 ). The “Edit Channel Page” is then presented to the user, irrespective of whether or not the user elected to save the widget configuration (stage 2560 ).
  • the service provider 106 populates a corresponding widget and parameters tables within the system database in accordance with the user's parameter selections.
  • the widget table may include an XML-based “param_desc_ ⁇ ml” field containing instructions enabling the construction of associated records in parameters table. For example, for a “clock” widget the XML-based instructions could indicate that a time zone should be a valid parameter, and could also be utilized to create appropriate records in the parameters table.
  • CHUMBYTM devices Users of CHUMBYTM devices will have the ability to send electronic greeting cards in the form of rich Flash animations.
  • a user Upon visiting a predefined web site (e.g., ‘http://greetings.chumby.com’) and optionally being authenticated by presenting appropriate credentials, a user will be presented with a catalog of “CHUMBYTM Greetings”. In one embodiment access to certain “CHUMBYTM Greetings” may be dependent on membership status. Any authenticated user, irrespective of the number of registered CHUMBYTM devices, will have the permission to send CHUMBYTM Greetings to one or more arbitrary email addresses or, alternatively, one or more users registered with the CHUMBYTM network.
  • CHUMBYTM Greetings to be forwarded directly to such a device using the existing widget transfer infrastructure of the service provider 106 .
  • the transferred CHUMBYTM Greetings will be added to the channel or profile in which the recipient has designated for receipt of widgets or other delivered content. Once the widget has been delivered to a channel or profile, the recipient will have the option of accepting or rejecting the delivered content.
  • the CHUMBYTM Greeting will be added to the recipient's widget slideshow rotation in accordance with the applicable profile of the device.
  • a visitor to the web site may choose to assign a certain level of priority to a CHUMBYTM Greeting such that it may be displayed by the recipient CHUMBYTM device immediately following actuation of the device's alarm function.
  • a priority assigned to a CHUMBYTM Greeting may define the placement of the CHUMBYTM Greeting in the recipient's widget rotation.
  • CHUMBYTM Greetings sent to email addresses that are not bound to physical CHUMBYTM devices will be forwarded as an SMTP email message.
  • This message will originate from, for example, “greetings@chumby.com” (or a user supplied email address), and will contain a URL or hyperlink pointing to a temporary web page hosting the Flash movie comprising the CHUMBYTM Greeting in addition to an optional user-defined message.
  • Authenticated users will have the ability to select one or more peers from their CHUMBYTM “Buddy List” as recipients of a preconfigured CHUMBYTM Greeting.
  • a subscription may be required for access to certain features such as CHUMBYTM Greetings.
  • CHUMBYTM may wish to elect a “pay-per-view” model where the use of a “premium” CHUMBYTM Greetings may be charged as a micro-transaction.
  • CHUMBYTM Greeting recipients that are not bound to physical CHUMBYTM devices will be presented with an option to forward the CHUMBYTM Greeting to alternate email addresses or physical CHUMBYTM devices.
  • the infrastructure of the CHUMBYTM service provider will support a service capable of receiving an email message from a mobile communication device (e.g., a cellular phone) containing text and/or an image.
  • a mobile communication device e.g., a cellular phone
  • the email would be addressed to a given user (e.g., ‘user’@chumby.com) within the “chumby” domain; alternatively, a special email domain may be created for content from mobile devices in order to facilitate its detection (e.g., ‘user’@chumby-mobile.com).
  • a text/image processing service within the infrastructure of the CHUMBYTM service provider 106 is configured to parse e-mail messages from mobile devices and extract the relevant content. As shown, the e-mail messages are provided to a CHUMBYTM e-mail gateway 3410 by provider service gateway 3412 .
  • the text/image processing service makes the content available to the appropriate widget (mobile text or mobile imaging) and optionally caches that content in a service in the infrastructure of the CHUMBYTM service provider 106 .
  • the appropriate widget mobile text or mobile imaging
  • such infrastructure includes a text server 3420 and an image server 3430 respectively operative to process textual and image information extracted from incoming e-mail messages by the CHUMBYTM e-mail gateway 3410 .
  • a text server 3420 and an image server 3430 respectively operative to process textual and image information extracted from incoming e-mail messages by the CHUMBYTM e-mail gateway 3410 .
  • the recipient user has the appropriate text or imaging widget configured to display on their CHUMBYTM device 102 , then the subject text or image will be retrieved and displayed when the widget becomes active (after all previously queued text or images have been retrieved). If such a widget is not currently configured to run on the recipient user's CHUMBYTM device 102 , the content will remain stored within the appropriate service's cache until such time that the widget is configured to run or a cache aging utility deletes it as unreferenced content.
  • FIG. 35 is a process flow diagram 3500 illustrating an alternate implementation of an image processing service for CHUMBYTM devices 102 .
  • the image processing service may not be performed by the CHUMBYTM service provider 106 , but is instead handled by an imaging service provider 3502 .
  • e-mail messages originating at mobile devices are provided to an imaging service e-mail gateway 3510 by provider service gateway 3512 .
  • the service provider 3502 also operates an image server 3520 that makes the extracted image content available to the appropriate image widget executing on the applicable CHUMBYTM device 102 .
  • CHUMBYTM devices will often be utilized within private residential environments, in certain cases “generic” CHUMBYTM devices may be deployed in public or quasi-public spaces such as hotel lobbies, hotel rooms, or airports. In such cases a user would be permitted to “log-in” to a generic or multi-user CHUMBYTM device (i.e., a CHUMBYTM device not associated with a single user). Such log-in may be effected by the entry of a username/password combination into the generic CHUMBYTM device or through other conventional means of user identification (e.g., using “RFID” tags, USB Flash Storage devices, SIM cards or biometric techniques).
  • the log-in information is communicated from the generic CHUMBYTM device to the CHUMBYTM service provider.
  • the service provider sends a user-specific profile and related configuration information corresponding to the log-in information back to the generic CHUMBYTM device.
  • the interface of the generic CHUMBYTM device may be customized in accordance with the setting and preferences of multiple different users of the device.
  • profiles pertinent to various specialty interests or activities may be developed and maintained by the service provider 106 or other users of CHUMBYTM devices.
  • Each such profile, or “channel”, could be subscribed to by interested users of CHUMBYTM devices. This may be considered a special case of mirroring to a “virtual” CHUMBYTM device as described above, but would further involve effort on the part of the “owners” of each channel to keep its widget set and other content updated.
  • Channels could somewhat broadly focus upon a particular subject (e.g., recipes, football), or could be more specific in nature (e.g., vegetarian recipes, NFL football).
  • CHUMBYTM devices may also be equipped with BluetoothTM transceivers or the like to facilitate communication with similarly equipped wireless handsets, headsets, or other BluetoothTM-enabled devices.
  • the CHUMBYTM device could execute a widget designed to use the BluetoothTM transceiver to “pull” information from or alternately “push” information to the wireless handset via the BluetoothTM link.
  • Such an arrangement could be used to obtain information from or send information to the BluetoothTM enabled device such as, for example, alarm settings, images, videos, calendar appointments, voice and other stored data (e.g., music, messages).
  • the CHUMBYTM device may be used as a Bluetooth enabled dialer and speakerphone accessory for mobile phones.
  • the CHUMBYTM device may communicate with portable BluetoothTM enabled GPS devices and optionally render maps and navigation routes to the LCD 320 .
  • a CHUMBYTM device may be capable of accessing a user's “home network” and identifying particular types of server infrastructure which may be present via multicast DNS, Universal Plug and Play, or other means.
  • the CHUMBYTM device would then configure itself to act as a client to the detected server and participate in the network.
  • the CHUMBYTM device could be configured to act as a peer to other devices connected to the home network.
  • the CHUMBYTM device may discover and connect to a media server running on the “home network” and stream audio and video feeds.
  • the CHUMBYTM device may discover and connect to a digital video recorder and provide scheduling and optionally stream audio and video data stored on the remote device.
  • Some embodiments of the CHUMBYTM device may be equipped with an FM radio device that will allow the CHUMBYTM device to play audio from local FM radio stations.

Abstract

A portable information device including a frame structure is disclosed herein. The device includes communications circuitry and a core electronics unit supported by the frame structure. The core electronics unit includes memory in which are stored instructions for one or more computer programs received by the communications circuitry and executed by a processor. A user interface in electrical communication with the core electronics unit is disposed to receive user instructions pertinent to execution of the one or more computer programs. The device also includes a flexible housing attached to the frame structure, the flexible housing at least partially defining a compartment containing the core electronics unit.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application claims priority under 35 U.S.C. §119(e) to co-pending U.S. Provisional Application Ser. No. 60/805,830, entitled CONFIGURABLE PERSONAL AUDIOVISUAL DEVICE FOR USE IN NETWORKED APPLICATION SHARING SYSTEM, to co-pending U.S. Provisional Application Ser. No. 60/823,491, entitled SYSTEM AND METHOD FOR TRANSFERRING ELECTRONIC CONTENT TO NETWORKED PERSONAL AUDIOVISUAL DEVICES, to co-pending U.S. Provisional Application Ser. No. 60/823,493, entitled NETWORKED PERSONAL AUDIOVISUAL DEVICE HAVING FLEXIBLE HOUSING, to co-pending U.S. Provisional Application Ser. No. 60/823,496, entitled SYSTEM AND METHOD FOR AUTOMATICALLY UPDATING THE SOFTWARE OF A NETWORKED PERSONAL AUDIOVISUAL DEVICE, to co-pending U.S. Provisional Application Ser. No. 60/945,900, entitled REGISTRATION SYSTEMS AND METHODS FOR PERSONALIZED PORTABLE DEVICES, and to co-pending U.S. Provisional Application Ser. No. 60/869,297, entitled SYSTEM AND METHODS FOR LOCATION, MOTION, AND CONTACT DETECTION AND TRACKING IN A NETWORKED AUDIOVISUAL DEVICE, each of which is incorporated herein by reference in its entirety. This application is related to U.S. patent application Ser. No. ______, entitled CONFIGURABLE PERSONAL AUDIOVISUAL DEVICE FOR USE IN NETWORKED APPLICATION SHARING SYSTEM, filed on even date herewith, to U.S. patent application Ser. No. ______, entitled SYSTEM AND METHOD FOR TRANSFERRING ELECTRONIC CONTENT TO NETWORKED PERSONAL AUDIOVISUAL DEVICES, filed on even date herewith, and to U.S. patent application Ser. No. ______, entitled SYSTEM AND METHOD FOR AUTOMATICALLY UPDATING THE SOFTWARE OF A NETWORKED PERSONAL AUDIOVISUAL DEVICE, filed on even date herewith, all of which are incorporated by reference in their entirety.
  • BACKGROUND OF THE INVENTION
  • It is well known that broadband Internet connectivity is becoming substantially more pervasive among consumers as a result of competition among service providers utilizing various different technologies (e.g., cable, digital subscriber line (DSL), satellite). In many households personal computers (PCs) constitute the primary users of the bandwidth furnished by these broadband connections. In order to facilitate sharing of the Internet connection among PCs in a given household, a variety of “wired” and “wireless” home networking technologies have been utilized.
  • As a result of the impracticality of installing Ethernet cable throughout a residence, RF-based wireless networking technology is becoming increasingly commonplace among consumers. Although systems based upon the 802.11b, or “Wi-Fi”, wireless networking standard may currently be the most pervasive, versions of the 802.11 standard offering increased bandwidth have been introduced and yet higher-bandwidth approaches have been proposed.
  • The increased bandwidth available within the home has increased the usage of a number of different services, such as Internet-based delivery of digital audio, video and graphic content. However, since many of these services are facilitated by a desktop or notebook PC capable of communication over a broadband Internet connection, users are forced to remain proximate to their respective computers in order to utilize such services. Although other strategies to leverage the availability of broadband Internet connectivity within the home are currently being developed, many of these approaches involve creation of a relatively powerful, costly centralized communications “hub” (e.g., a PC with enhanced media capabilities, or a multi-purpose cable set-top box). Unfortunately, this typically requires either the purchase of an expensive hardware device or extended subscription plan, and constrains the extent to which Internet-enabled entertainment or other services are enjoyed outside of the immediate vicinity of the centralized hub device.
  • Accordingly, the increasing availability of wireless bandwidth within the home and elsewhere creates an opportunity for economically leveraging this bandwidth in a flexible, consumer-friendly manner.
  • SUMMARY OF THE INVENTION
  • In summary, one aspect of the present invention relates to a portable information device including a frame structure. The device further includes communications circuitry and a core electronics unit supported by the frame structure. The core electronics unit includes memory in which are stored instructions for one or more computer programs received by the communications circuitry and executed by a processor. A user interface in electrical communication with the core electronics unit is disposed to receive user instructions pertinent to execution of the one or more computer programs. The device also includes a flexible housing attached to the frame structure, the flexible housing at least partially defining a compartment containing the core electronics unit. In particular embodiments the portable information device may contain resilient fill material interposed between the core electronics unit and the flexible housing.
  • In another aspect the present invention relates to a portable information device including a core electronics unit including a main circuit board and a display. The core electronics unit also includes memory in which are stored instructions for one or more computer programs executed by a processor. A flexible housing structure at least partially defines a compartment containing the core electronics unit and an opening within which is positioned the display. The device contains a resilient fill material interposed between the core electronics unit and the flexible housing. In particular embodiments the flexible housing structure includes a flexible frame member and flexible material attached to the frame member.
  • The present invention also relates to a method for assembling a portable information device. The method includes providing a first electronics sub-assembly and securing the first electronics sub-assembly using a flexible frame. The method further includes attaching a flexible housing to the flexible frame such that the flexible housing at least partially defines a compartment surrounding the first electronics sub-assembly. The method may also include flexibly connecting the first electronics sub-assembly and a second electronics sub-assembly.
  • In yet another aspect the present invention pertains to a method for assembling a portable information device. The method includes forming a plastic frame by bending a piece of plastic material into a desired shape. The method also includes attaching a first electronics sub-assembly to the plastic frame, the first electronics sub-assembly including a processor and a display. In addition, the method includes sewing a flexible material to the plastic frame. In particular embodiments the method includes flexibly connecting the first electronics sub-assembly and a second electronics sub-assembly.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a better understanding of the nature of the features of the invention, reference should be made to the following detailed description taken in conjunction with the accompanying drawings, in which:
  • FIG. 1 is a block diagram illustrating a set of networked components comprising an exemplary embodiment of the system of the invention.
  • FIG. 2 illustrates an exemplary distribution of CHUMBY™ devices throughout a residence or other building having a number of rooms.
  • FIG. 3 provides a block diagrammatic representation of the principal components of an embodiment of a CHUMBY™ device of the present invention.
  • FIG. 4 shows an exemplary user interface generated through a screen of a CHUMBY™ device during operation of the CHUMBY™ device in a control panel mode.
  • FIGS. 5A-5E provides various perspective views of an exemplary CHUMBY™ device configured with a malleable housing.
  • FIGS. 6A-6D provide various partially transparent perspective, side and plan views of an embodiment of the CHUMBY™ device.
  • FIGS. 6E-6G depict the core electronics and other components contained within the housing of a CHUMBY™ device and the arrangement of certain of these components within a housing of the device.
  • FIG. 7 provides a block diagrammatic representation of the server components and other infrastructure which may be utilized to facilitate the operations of a CHUMBY™ service provider.
  • FIG. 8 provides a database model diagram of an exemplary object-oriented database schema utilized by a system database.
  • FIG. 9 is a signal flow diagram representative of one manner in which a configuration is provided to a CHUMBY™ device by a service provider.
  • FIG. 10 is a signal flow diagram which represents one manner in which a profile is provided to a CHUMBY™ device by a service provider.
  • FIG. 11 is a signal flow diagram which depicts processing of changes made to the parameters of a widget instance through the interface of a CHUMBY™ device in which the widget is instantiated.
  • FIG. 12 shows a signal flow diagram illustrating an exemplary widget instance download operation in which a service provider is requested to push values of widget-specific parameters to a requesting CHUMBY™ device.
  • FIG. 13 is a signal flow diagram which illustratively represents the process of obtaining content from the service provider for a widget of a CHUMBY™ device.
  • FIG. 14 is a flowchart which depicts an exemplary sequence of operations performed by a CHUMBY™ device upon initial power-up.
  • FIG. 15 is a flowchart illustrating an exemplary routine used to calibrate a touchscreen of a CHUMBY™ device.
  • FIGS. 16A-16D provide a set of screen shots of the user interface of a CHUMBY™ device being calibrated pursuant to the routine of FIG. 15.
  • FIG. 17 is a flowchart illustrating the operations performed in selecting a wireless base station upon initial power-up of a CHUMBY™ device.
  • FIG. 18 is a flowchart of an exemplary account creation and registration process.
  • FIG. 19 is a flowchart representative of an exemplary Web-based interaction between a user and a service provider in connection with associating a particular CHUMBY™ device with the user's account.
  • FIG. 20 is a flowchart of an exemplary Web-based interaction between a user and the service provider with regard to disabling a CHUMBY™ device that has been previously associated with the user's account.
  • FIG. 21 is a flowchart of an exemplary Web-based interaction between a user and the service provider in connection with “mirroring” CHUMBY™ devices.
  • FIG. 22 is a top-level flowchart of exemplary Web-based or CHUMBY™ device-based interaction between a device user and the service provider with regard to adding, removing and configuring widget profiles relative to the user's CHUMBY™ device.
  • FIG. 23 is a flowchart representative of exemplary Web-based or CHUMBY™ device-based interaction between a device user and the service provider with respect to the addition of widgets to the current configuration of the user's CHUMBY™ device.
  • FIG. 24 is a flowchart representative of exemplary Web-based or CHUMBY™ device-based interaction between a device user and a service provider in connection with the removal of widgets from a channel, which may also be active on the user's CHUMBY™ device.
  • FIG. 25 is a flowchart depicting an exemplary set of operations involved in configuring parameters specific to of one or more widgets currently associated with a given CHUMBY™ device.
  • FIGS. 26A-26E are screen shots of exemplary user interfaces presented by a Web browser used to facilitate certain of the processes described by FIGS. 22-25.
  • FIG. 27 is a signal flow diagram which illustratively represents the process of downloading the code for a widget from a service provider.
  • FIG. 28 provides an alternative illustration of a CHUMBY™ device in which is identified a core electronics unit and flexible housing of the device.
  • FIG. 29 illustrates various components interior to a flexible housing of an exemplary CHUMBY™ device.
  • FIGS. 30-31 provide an example of a flat pattern used to define the exterior structure of a flexible housing of an exemplary CHUMBY™ device.
  • FIGS. 32-33 show exemplary user interface screens of a CHUMBY™ device applicable to a process for calibration of one or more bend sensors within the device.
  • FIG. 34 is a process flow diagram of a text/image processing service within the infrastructure of CHUMBY™ service provider configured to parse e-mail messages from mobile devices and extract the relevant content.
  • FIG. 35 is a process flow diagram illustrating an alternate implementation of an image processing service for CHUMBY™ devices.
  • FIGS. 36A-36H provide a more comprehensive tabular representation of an exemplary object-oriented database schema capable of being utilized by the system database.
  • FIG. 37 is a top-level flowchart of exemplary Web-based interaction between a device user and the service provider with regard to adding, removing and configuring widget profiles relative to the user's CHUMBY™ device.
  • FIG. 38 is a flowchart representative of exemplary Web-based interaction between a device user and the service provider with respect to the addition of widgets to the current configuration of the user's CHUMBY™ device.
  • FIGS. 39A-39H are screen shots of exemplary user interfaces presented by a Web browser used to facilitate certain of the processes described by FIGS. 25 and 37-38.
  • FIGS. 40A-40B are screen shots of exemplary user interfaces presented by a CHUMBY™ device used to facilitate certain of the processes described by FIG. 41.
  • FIG. 41 is a flowchart representative of exemplary CHUMBY™ device-based interaction between a device user and a service provider in connection with the removal of widgets from the current channel of the user's CHUMBY™ device.
  • DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION Overview
  • The present invention generally relates a system comprised of a set of personalized audiovisual devices in Internet-based communication with a service provider. It is anticipated that the personalized audiovisual devices will be commercially distributed under the trademark CHUMBY™, and may also be referred to herein as “CHUMBY™ devices”. During communication with the service provider, each CHUMBY™ device periodically receives a set of application programs, or “widgets”, which are sequentially executed by the CHUMBY™ device after being received from the service provider or locally from a personal computer (e.g., via a USB connection). Since each CHUMBY™ device is typically Internet-enabled, each may also be remotely configured and otherwise personalized via the CHUMBY™ service provider through a Web browser executed by a remote terminal (e.g., a PC or wireless handset). Such personalization may include, for example, specifying the set of widgets provided to a given CHUMBY™ device as well as their sequence and priority of execution.
  • As is described hereinafter, it is a feature of embodiments of the invention that a user configuring a CHUMBY™ device via an interface provided by the CHUMBY™ service provider may “drag and drop” icons representative of various widgets onto a rectangular or other portion of the interface representative of the screen of the CHUMBY™ device being configured. Alternatively, a user may select textual and/or graphical representations of widgets and select a button or other graphical representation of a user interface (UI) control to “add” the widget to the CHUMBY™ device being configured. In these ways the “layout” of the screen of the CHUMBY™ device may be remotely configured by the owner of the device. Although each CHUMBY™ device will preferably be capable of being configured in this manner, in certain embodiments each may also come “loaded” with a default set of widgets (e.g., an “alarm clock” widget) disposed to be executed by the CHUMBY™ device upon its registration with the CHUMBY™ service provider. Once a CHUMBY™ device has been configured (i.e., with either a “default” or user-specified configuration), it may execute the widgets defined by the configuration without user intervention. Alternatively, users may opt to “stay” on a given widget by explicitly instantiating the system interface on the device and selecting a “stay” UI control. If a user has explicitly selected a widget to “stay”, the sequential execution of widgets can be continued by terminating the “stay” command via the system interface. If a user interacts with a widget which presents user interface controls to the user through one of a number of alternative input methods, such as via a touchscreen or accelerometer, the currently active widget will continue to execute on the device until some timeout period expires following the cessation of user interaction with the widget.
  • The configuration of a CHUMBY™ device may also specify the events or conditions under which the sequence of execution of widgets is to be altered or interrupted, and allows certain widgets to be accorded the highest available priority with respect to execution. For example, an “alarm clock” widget could be granted such priority in order to ensure that its alarm function would not be prevented from being actuated at the scheduled time due to contemporaneous execution of another widget. In one embodiment the Web interface provided by the CHUMBY™ service provider is in the form of a “timeline” enabling the sequence of execution of the widgets associated with a given CHUMBY™ device to be controlled in an intuitive manner. In an exemplary implementation the timeline defines the order in which the widgets are to be played in a constantly repeating sequence; that is, the timeline is representative of the complete set of widgets played by a given CHUMBY™ device as well as their relative order and duration of execution. However, certain widgets (e.g., the “alarm clock” widget) can be specified to be actuated at a given time by appropriately setting the applicable configuration element of such widgets.
  • Although in exemplary embodiments it is not contemplated that more than a single “content-related” widget be operative at any given time, a system configuration widget may be utilized to run concurrently with each such content-related widget in order to, for example, control the relative priority of execution of such content-related widgets and system settings such as loudness, brightness, navigation, and the like.
  • In one embodiment CHUMBY™ devices are each capable of wireless communication in accordance with an accepted wireless networking standard, such as the 802.11b or 802.11g standard. Accordingly, in homes or other environments containing one or more wireless access points, multiple CHUMBY™ devices may be distributed throughout the coverage area of the access points. Alternatively, a CHUMBY™ device may use a wired connection as a backup to, or in lieu of, a wireless connection to the extent convenient or necessary.
  • Among the features of the invention is the capability of the interface presented by each CHUMBY™ device to change in accordance with the nature of the widget currently being executed by the device. For example, a “clock radio” widget could be employed to produce audio and visual imagery consistent with a conventional alarm clock at an appointed time in the morning. In exemplary embodiments the clock radio widget would allow for the selection of a standard “wake up” chime or choice of several different audio programs. Later in the day the device interface could be devoted to a rotating selection of several standard information screens such as news headlines, local weather, sports scores, stock market updates, horoscope and the like.
  • In accordance with another aspect of the invention, users of CHUMBY™ devices may optionally participate in a “CHUMBY™ Network” along with other users by logging on to a Web site (e.g., www.chumby.com) hosted by the CHUMBY™ service provider. At this site (also referred to hereinafter as the “CHUMBY™ site”) a user will be able to register with the CHUMBY™ Network and access services enabling the basic capabilities of the user's CHUMBY™ device. Basic capabilities may comprise, for example, the opportunity to send/receive widgets and other content to/from other CHUMBY™ users, for improved personalization of the device's generic information features, more detailed alarm-setting capabilities, and better selection and configuration of audio capabilities.
  • Registration with the CHUMBY™ Network, which would potentially require payment of a periodic subscription fee, enables members of the Network to access a wide array of widgets. It is contemplated that certain of such widgets would be developed by the entity operating the CHUMBY™ Network while other widgets would be developed by independent developers. In addition, members of the “CHUMBY™ Network would also be able to communicate with the CHUMBY™ devices of other members, provided that permission for such communication has been authorized by the other members. Such communication could entail, for example, the sending of a widget and corresponding data from the CHUMBY™ service provider to a member of the CHUMBY™ Network (the “receiving member”) in response to a request sent to the CHUMBY™ service provider by another member (the “sending member”). For example, a sending member could, after receiving permission from a receiving member, request the CHUMBY™ service provider to send a “photo-viewer” widget to the receiving member. In addition, the sending member could specify that a link be established between the photo-viewer widget and pictures uploaded by the sending member to the CHUMBY™ service provider. In this way the receiving member could, without any effort other than providing authorization to the sending member, enable their CHUMBY™ device to essentially automatically receive and display a sequence of photos provided by the sending member. Similarly, while traveling a sending member could send a personalized “wake up” message to the CHUMBY™ device of a consenting receiving member. Finally, a sending member could send widgets to a group of receiving members included on a “buddy list” of the sending member, which could be established after the receipt of suitable permissions from those proposed to be included on the list.
  • In an exemplary embodiment members of the CHUMBY™ Network are enabled to completely configure, through any Web browser, their respective CHUMBY™ devices by specifying a set of “premium” widget programs or content to play or be shown rotationally (or in some other user-defined sequence) on their respective CHUMBY™ devices. Such premium widgets and content may include, for example, webcam shots, RSS readers, filtered news reports, personalized stock performance data, short animations or movies, podcasts or audio files to function as the audio sources for alarms or reminders scheduled to be triggered at different times throughout the day.
  • As is discussed further below, one exemplary implementation of a CHUMBY™ device is comprised of a malleable housing attached to a rigid “core” structure supporting a display screen and the electrical components of the device. The malleable housing would generally encompass all of the electrical components of the CHUMBY™ device, and will preferably be filled with an appropriate material or otherwise constructed to enable it to be “squeezed” or otherwise deformed by a user. Moreover, the core structure is designed to be capable of being removed from the housing and mated in to a different housing. A set of “squeeze sensors” are enclosed by the malleable housing in order to permit the detection of such a squeezing or similar action by a user. In this way a user is afforded the opportunity of conveying information through physical deformation of the CHUMBY™ device in addition to the more conventional textual and other modes of communication facilitated by the display screen. For example, in one exemplary system a user could initiate the conveying of a “hug” to another user by squeezing the housing of the user's CHUMBY™ device in a particular manner. The electrical signals generated by the sensor array in response to this squeeze would be appropriately interpreted and the user's CHUMBY™ device would communicate, via the CHUMBY™ service provider, a “hug” message to the intended recipient user. At this point the recipient's CHUMBY™ device could register receipt of the hug message by, for example, illuminating an indicator light or sending a message to the display of the device. Significantly, the CHUMBY™ device is not limited to an implementation in a malleable housing; all of the features associated with such a malleable housing may be emulated using a rigid housing in combination with alternative sensors (e.g., force-sensitive or virtually emulated sensors).
  • System Components
  • FIG. 1 is a block diagram illustrating a set of networked components comprising an exemplary embodiment of the system 100 of the invention. As shown, the system 100 comprises one or more CHUMBY™ personal audiovisual devices 102 in communication with a central service provider 106 via one or more access networks 110 and the Internet 116. As those skilled in the art will appreciate, the access networks 110 are representative of various intermediary network routing and other elements between the Internet 116 and the CHUMBY™ personal audiovisual devices 102. Such intermediary elements may include, for example, gateways or other server devices, and other network infrastructure provided by Internet service providers (ISPs). As is discussed below, the CHUMBY™ personal audiovisual devices 102 obtain application programs (“widgets”) for execution from the central service provider 106 or locally from a mass storage device, personal computer or other computing device. In this regard the service provider 106 typically contains a repository of widgets and has access to other content capable of being communicated to a given CHUMBY™ device 102 upon the request of its authorized user or another user to which appropriate permission has been granted.
  • Referring again to FIG. 1, the system 100 also includes a plurality of user computers 120 disposed for communication with the service provider 106 via an access network (not shown) and the Internet 116. Each user computer 120 executes a Web browser 122 capable of displaying Web pages generated by the service provider 106 through which a user may configure one or more CHUMBY™ personal audiovisual devices 102. As mentioned above, such configuration may include, for example, specifying a set of widgets to be sent to a particular device 102 and their sequence of execution, adjusting audio or visual parameters relating to such execution, defining and managing a user's CHUMBY™ network (including, for example, defining a “buddy list” comprised of other CHUMBY™ users with respect to which the device 102 is permitted to communicate), and defining the layout or other aspects of the user interface presented through the screen of the device 102. To this end a given Web browser 122 may, when in communication with the service provider 106, present a rectangular configuration window which displays the widgets currently configured to “play” within the named “channel”. By “dragging and dropping” iconic representations of widgets or content files into such a configuration window, a user may personalize the behavior and user interface presented by the corresponding CHUMBY™ device 102. Alternatively, a user may select textual and/or graphical representations of widgets and select a button or other graphical representation of a user interface control to “add” the widget to the CHUMBY™ device being configured. Moreover, users may access the service provider 106 via a Web browser 122 for the purpose of sending widgets or other information to other users for execution or display by their respective CHUMBY™ devices 102. In one embodiment the service provider 106 maintains a record of the permissions granted among users of CHUMBY™ devices in order to determine which users are authorized to provide, via the service provider 106, a given user with widgets, messages or other information, and vice-versa. Such permissions may be granted or withdrawn by a given user via appropriate pages presented by a Web browser 122 in communication with the service provider 106.
  • In the exemplary embodiment a configuration window may be utilized to configure one or more CHUMBY™ devices 102 consistent with the permissions granted by the users of such devices 102. In addition, a user of a given CHUMBY™ device 102 may elect to have the interface of the device 102 “mirror” or otherwise replicate that of another device 102 subject to the requisite permissions being granted. Similarly, one or more CHUMBY™ devices 102 may be configured to mirror the interface for a “virtual” CHUMBY™ device (or vice-versa) defined via a configuration window.
  • Different users of a given CHUMBY™ device 102 may be accorded different roles or privileges in configuring the device 102. For example, user-granted supervisory privileges could be given the authority to filter or monitor the widgets or content sent to the CHUMBY™ device 102. This would enable, for example, parents to manage and/or monitor the widgets and content executed and displayed by the one or more CHUMBY™ devices 102 used by their children. Moreover, administrators of the system 100 would typically possess an elevated level of privilege relative to users of CHUMBY™ devices 102 within the system 100. Also, if a specific widget performs functions requiring communication with a web site controlled by a third party in order to access content, the developer of the widget may create a hierarchical user model to regulate such access (and perhaps the functions of the widget).
  • Attention is now directed to FIG. 2, which illustrates an exemplary distribution of CHUMBY™ devices 102 throughout a residence 200 or other building having a number of rooms 204. In the embodiment of FIG. 2, each CHUMBY™ device 102 is equipped with wireless transceiver (e.g., a Wi-Fi transceiver) to facilitate communication with one or more access points 210. Each access point is interconnected with an access network 110 by way of, for example, a local area network, thereby enabling Internet-based communication to be established between the service provider 106 and the devices within the residence 200.
  • Turning now to FIG. 3, a block diagrammatic representation is provided of the principal components of an embodiment of a CHUMBY™ device of the present invention. As shown, the device includes a central processing unit (CPU) 302, memory including volatile (e.g., SDRAM) 306 and non-volatile memory 310 (e.g., flash memory), an audio interface 312, a wireless communications interface 314, and a sensor interface 370. In an exemplary implementation the CPU 302 comprises a microprocessor (e.g., based upon an ARM core) configured to run a Linux kernel and having attendant capabilities for graphics rendering. The device may or may not include a battery backup unit, which serves to preserve real-time information in the event of a power outage, and may also serve as a primary power source if the user desires untethered operation. The battery may or may not be rechargeable. The operating system is made aware of the power status and actively configures the CHUMBY™ device and the running widget to either save power or modify the user interface consistent with untethered operation.
  • The device may or may not include a Security Module (not shown) If included, the Security Module serves to store secrets and compute authentication algorithms in a fashion that fully isolates core security routines from otherwise unsecured code running on CPU 302. The secret storage and authentication capability may or may not be used by the client-server communication protocol to enable authenticated and encrypted communication capabilities for, among other things, financial transactions. The Security Module is initialized in such a way that there is no default mapping of the secrets contained within the module versus the identity of the hardware of the user. Furthermore, the secrets are revocable and a routine may exist for generating new secrets based upon a master secret that is never associated with a specific user's profile. This enables opt-in policies for privacy and a limited ability to revoke identity information, barring forensic network analysis, thereby enabling anonymity as well. The anonymous trust network can be extended with a variety of client-server protocols to enable a wide range of anonymous transactions, including but not limited to cash and content transactions.
  • As shown, software comprising widgets 350 or other applications received from the service provider 106 are stored in memory 310 and loaded into SDRAM 306 or non-volatile memory 310 for execution by the CPU 302. In one embodiment widgets are downloaded from the service provider 106 to CHUMBY™ devices in the format of a “Adobe Flash” file, also referred to as a “Flash movie”. As is known by those skilled in the art, Flash movies are usually accorded a “.swf” file extension and may be played by a Flash Player developed and distributed by Adobe Systems. Accordingly, the memory 310 also includes a Flash Player 360 as well as a copy of the operating system 364 executed by the CPU 302. In other embodiments widgets may be developed in accordance with other formats and played by players compatible with such other formats.
  • In the exemplary embodiment widgets are not “permanently” stored in memory 310 of CHUMBY™ devices. Rather, widgets are executed by the CPU and then either discarded or cached in temporary memory for future use. This enables widgets to be “pushed” from the service provider 106 as necessary to support the sequence of widget execution specified for each CHUMBY™ device. That is, the service provider 106 may operate to provide a “stream” of widgets to each CHUMBY™ device, where the widgets within each such stream are temporarily cached within the memory of the applicable CHUMBY™ device until their execution. This enables the service provider 106 and/or the creator of each widget program to maintain a degree of control over the content and behavior of each widget program, since each such program is typically not permanently downloaded (thereby facilitating modification) but is rather temporarily cached and erased after some predetermined time has passed or a memory use threshold has been reached.
  • The CHUMBY™ device also includes a liquid crystal display (LCD) 320 controlled by an LCD controller 322, which may or may not be integrated into the CPU 302. The display 320 visually renders iconic representations of the widget programs stored within the CHUMBY™ device and images generated in connection with the execution of such widgets by the CPU 302. In an exemplary implementation a touchscreen 330 overlays the LCD 320 and is responsive to a touchscreen controller 334. In one embodiment a user may induce the CHUMBY™ device to enter a “control panel mode” by touching the a sensor such as the squeeze sensor (not shown in FIG. 3), touchscreen 330 or other sensor device. In an exemplary embodiment, widgets and the system control panel may present the user with different “user interface”, or “UI”, elements to enable the user to interact with the widget/system control panel. These UI elements may include, but are not limited to, buttons, scroll bars, drop down combo boxes and menus. When a user touches the screen to interact with one of these UI elements, the touchscreen controller 334 informs the CPU 302 that the touchscreen has been touched at a specific location and that location is converted by the CPU 302 to a UI control actuation event based on the configuration of the currently displayed widget 350 or system control panel screen (not shown in FIG. 3). In alternate implementations the LCD 320 and touchscreen 330 may comprise an integral device controlled by an integrated controller.
  • Turning to FIG. 4, there is shown an exemplary user interface 400 generated by the LCD 320 during operation of the CHUMBY™ device in control panel mode. As shown, the interface 400 defines an mute button 404, a channel button 406, a night button 408, a music button 410, a settings button 412, a clock button 414, a delete button 418, a rate button 420, a send button 422, a stay button 424, a right arrow button 428, a left arrow button 426, and a hide control panel mode button 416. Selection of the mute button 404 toggles the mute state of the CHUMBY™ device. Selection of the channel button 406 instantiates another control panel screen which enables users to view the content of all of their CHUMBY™ “channels” and/or select a new “channel” to be loaded and run on the CHUMBY™ device. A “channel” is a collection of widgets configured by a user in a named grouping via an interaction between a page rendered on a web browser 122 and the CHUMBY™ service provider, such collection of widgets generally running on the CHUMBY™ device in a sequential, repetitive fashion.
  • Selection of the night button 408 places the CHUMBY™ device into a “night mode” in which the screen is dimmed and a low intensity clock is displayed. Selection of the music button 410 instantiates another control panel screen which enables the user to interact with and control various continuous music sources, such as, for example, MP3 players, storage devices, and music services. Such sources may reside on either the local network or on the Internet. Selection of the settings button 412 instantiates another control panel screen which enables the user to configure various CHUMBY™ device settings, such as, for example, wireless network setup, speaker volume and touchscreen calibration. Selection of the clock button 414 instantiates another control panel screen which enables the user to configure the time, date and alarm functions of CHUMBY™ device. Selection of the delete button 418 deletes the currently displayed widget to be deleted, with user confirmation, from the current “channel”. Selection of the rate button 420 instantiates another control panel screen which enables the user to provide a rating on a fixed scale for the currently displayed widget. Selection of the send button icon 422 instantiates another control panel screen which displays a personalized list of other users of CHUMBY™ users to which it may be desired to send widgets or otherwise communicate. Selection of the stay button 424 toggles the “stay” state of the currently selected widget. When the “stay” state of a widget is selected, the widget plays continuously on the CHUMBY™ device. Selection of the right arrow button 426 or left arrow button 428 causes the CHUMBY™ device to display the previous or next widget in the channel, respectively. A user may, from any Web browser 122, access a Web page generated by the service provider 106 and designate a “favorite” widget. Alternatively, a user may press a virtual, touchscreen-based button on his or her CHUMBY™ device 102 to designate the current widget as the new “favorite” widget. When the user then selects the heart-shaped icon (not shown in FIG. 4) on his or her CHUMBY™ device, an iconic representation of this favorite widget (e.g., a clock widget) replaces the heart-shaped icon and enables the user to immediately activate (i.e., cause the CPU 302 to execute) the program instructions corresponding to such favorite widget. Alternatively, selection of the heart-shaped icon (or other predefined icon) results in the CHUMBY™ device becoming configured in accordance with a “favorite” or other profile rather than executing a favorite widget. Of course, certain profiles may be specified to include only a single widget such as, for example, an “alarm clock” or “photo viewer widget.
  • Referring again to FIG. 4, selection of the right arrow button 426 advances one widget in a user-defined (or default) widget sequence (“channel”), or just skips ahead in implementations in which widgets are chosen to be displayed randomly. Similarly, selection of the left arrow button 428 results in “going back” one widget in the user-defined (or default) widget sequence (“channel”). As the buttons 426 and 428 are selected, an iconic representation or avatar corresponding to the currently active widget is displayed in a display box 430. If it is desired to return to the currently active widget, the hide control panel mode button 416 is selected and the control panel mode interface 400 changes to a screen through which the user views the sequence of widgets currently configured to be executing on the CHUMBY™ device.
  • In certain embodiments a physical button element (not shown) may be provided proximate the LCD screen 320 to enable navigation through menus and the like presented by the LCD screen 320. In one implementation this button element is cross-shaped in order to facilitate two-dimensional navigation, and may further include a smaller, dedicated button (e.g., in the center of the cross) associated with a specific widget (e.g., clock widget). Pressing this dedicated widget would interrupt the operation of all other widgets.
  • In implementations in which two-dimensional navigation through the user interface of the CHUMBY™ device is supported, users may be provided with the ability to navigate forward and back in the configured widget timeline. Similarly, users may navigate up and down a stack of related widgets. This function depends on the implementation of the concept of widget categories—i.e., associating widgets into logical categories that can be displayed sequentially, if configured to be displayed. An example of a category could be “News”. Widgets included within this category could include, for example, a local news widget, a sports news widget, an entertainment news widget, a business news widget, and the like. For each category, there would be a default widget, which is designated by the user on the CHUMBY™ web site for each category selected to be displayed by the user's CHUMBY™ device.
  • If more than one widget in a category is selected, then the widgets are conceptually “stacked” with the default widget being:
  • on the top of the stack; and
  • the widget that is displayed as the CHUMBY™ device automatically cycles through configured widgets.
  • If a widget for a given category (e.g., “News”) is displayed and there exist additional widgets in the category which are also configured for display, then in the exemplary embodiment these additional widgets are “stacked” below the displayed widget. In this case the user may take some predefined action with respect to the user's CHUMBY™ device (e.g., perhaps selecting a control on the touchscreen or accessing a function via the control panel, which is instantiated via actuating the squeeze sensor) in order to cause the next widget in the “stack” for that category to be displayed. The CHUMBY™ device may be configured such that taking further predefined actions of the same type will cause the widgets either above or below in the stack to be displayed, as designated by the user. The last widget that is displayed in the stack for the applicable category when the CHUMBY™ device cycles to the next widget category will be the widget displayed in the next cycle for the just exited category (e.g, News).
  • The tabular illustration below provides a conceptual layout of exemplary widget stacks in various categories:
    Figure US20080068519A1-20080320-C00001
  • The following provides a conceptual representation of the case in which the user has navigated into widget stacks for News, Entertainment and Sports:
    Figure US20080068519A1-20080320-C00002

    CHUMBY™ Device Structure
  • FIGS. 5-6 and 28-29 provide various views of an exemplary CHUMBY™ device in accordance with the present invention. Embodiments of a CHUMBY™ device will typically include one or more assemblies of electronic components integrated into a soft housing. Each such assembly may or may not include components that are externally visible.
  • In general, the electronics of each assembly are populated onto a printed circuit board, thereby forming a printed circuit board assembly (PCBA). The PCBA is integrated into a hard sub-frame made out of a typically stiff material, such as a plastic (ABS) or a metal (steel or aluminum). The integration of the sub-frame and PCBA is referred to an “electronics sub-assembly”.
  • Embodiments of the CHUMBY™ device may include one or more electronics sub-assemblies; an exemplary embodiment described herein employs three such sub-assemblies. One such sub-assembly is included within a core electronics unit of the CHUMBY™ device, and contains heat-generating electronics components, an LCD, and a microphone. Another such electronic sub-assembly comprises a WiFi riser containing a WiFi communications module. The third electronics sub-assembly included within the exemplary embodiment of the CHUMBY™ device comprises a “daughtercard sub-assembly”. The daughtercard contains a plurality of external connectors (e.g., USB connectors) and a set of audio transducers. In the exemplary embodiment a mechanical switch is grafted onto the daughtercard sub-assembly facilitates the “squeeze sensing” described below. An accelerometer may also be included upon the daughtercard sub-assembly.
  • The general subdivision into these three sub-assemblies confers several benefits. By confining the heat generating components to the core electronics unit and WiFi riser, a more cost-effective heat path may be engineered. By confining the connectors and large transducers to the daughtercard, logistical advantages may be conferred to the supply chain. This may add a new level of rapid reconfigurability of the CHUMBY™ device for end user customization. By bridging between the sub-assemblies with flexible connectors, the CHUMBY™ device retains a soft and flexible feel.
  • Attention is now directed to FIG. 5, which provides various perspective views of an exemplary CHUMBY™ device configured with a malleable housing 502 comprising a rubber-type frame 504 in combination with a fabric material 508. The housing 502 surrounds a core electronics unit 512, bezel 514 for daughtercard sub-assembly, and a plush interior fill material (not shown in FIG. 5). The frame 504, fabric 508 and fill materials collectively impart a soft and malleable feel to users handling the CHUMBY™ device.
  • In one embodiment the frame 504 is composed of Santoprene™ or Texin, a soft, flexible, tactile, rubber-like material similar to TPE (thermo plastic elastomer). In another embodiment, the frame 504 is composed of a very low durometer PVC (Polyvinyl Chloride). The exact frame composition will generally balance considerations of flexibility, feel, look, and manufacturing properties, namely, the ability to be sewn and to have items tacked onto the side with adhesive to improve production tolerances. The frame 504 provides structure and form to the housing 502 and allows the core electronics unit 512 to be replaced and inserted. The frame 504 will generally be manufactured in a relatively flattened configuration and then manually flexed or curved and stitched to the fabric or other soft material when assembling the housing 502 of the CHUMBY™ device. In another embodiment, the CHUMBY™ frame, fabric, or a combination thereof is created out of molded EVA (Ethylene Vinyl Acetate) foam. The molding process renders a slightly different feel but generally provides greater fidelity to CAD-related artwork.
  • FIG. 28 provides an alternative illustration of a CHUMBY™ device in which are identified the core electronics unit 512 and the flexible housing 502. As opposed to existing wireless or other consumer electronic devices in which the device electronics are typically simply mounted into rigid plastic enclosures that are not subject to any user modification or customization, in an exemplary embodiment the flexible housing of a CHUMBY™ device may be created using any number of exterior fabric materials such as those used in soft-goods or plush toy manufacturing. Such materials may include, for example, leather, suede, Neoprene, rubber, vinyl, etc. Interior to the flexible housing may be contained any number of fill materials, such as Poly-Fil, polyester beads, gel, foam, metal beads, etc., not unlike a pillow, stuffed animal, or plush toy. Such interior fills enable the CHUMBY™ device to be “squishable.” Moreover, such interior fill enables the device to retain its shape after being “squeezed” or “pressed” by a user in order to trigger an internal squeeze sensor 650. (In other embodiments an electric field/capacitance sensor may be used in lieu of a squeeze sensor to detect the location/distance of a user's hand to the sensor; that is, since the user's hand moves closer to the sensor as the user squeezes the flexible housing of the CHUMBY™ device, the sensor is capable of indicating that a “squeeze” event has occurred).
  • Turning now to FIG. 29, interior to the flexible housing of an exemplary embodiment of the device there is included the daughtercard circuitry containing an external power switch, external power supply connector, external headphone connector, one or more external USB connectors, internal left and right speaker connectors, internal 9V back-up battery connector 2904, internal squeeze sensor connector, and internal cable assembly or “Chumbilical™” connector 2910. In one implementation the Chumbilical connector 2910 is used to connect all the signals received/processed by the daughtercard sub-assembly to the core electronics unit 512 of the CHUMBY™ device, which is press-fit into the soft frame. Also positioned interior to the flexible housing are a pair of speakers 630 (for left and right audio output) (FIG. 6F), as well as a squeeze sensor 650 (FIG. 6G) and various cabling required to attach such elements to the daughtercard sub-assembly 640. In the preferred embodiment, the speakers are affixed to a rigid plate, constructed of plastic or other similar material, located on the back of the CHUMBY™ device, coincident to the headphone connector, USB ports, power switch and power connector.
  • The division of the circuitry into a core board with greater complexity and cost and a daughtercard which breaks out many of the peripheral connections and features is a significant feature of the design of exemplary embodiments of the CHUMBY™ device. So segregating the design enables quicker adaptation to market and product changes, since the most volatile components of a system are often “on the edge”. The segregation of the core and the peripherals in this manner also provides a key benefit, in that the peripheral card can be customized at a lower cost, which helps enable the growth of an ecosystem of accessories and custom housings around the CHUMBY™ device.
  • Referring to FIGS. 30-31, an example of a flat pattern, commonly used in soft-goods and garment manufacturing, is used to define the exterior structure of the flexible housing 3002 or “bag” of an exemplary CHUMBY™ device (“CHUMBY™ bag”). Any number of artistic/design elements can be added to the exterior fabric material of the CHUMBY™ bag to add dimension and visual features. The use of a fabric-type enclosure for the CHUMBY™ device provides for unlimited possibilities for product housing creation, both by the original manufacturer and end-users (such as craftspeople, hobbyists, etc.), and is believed to represent a novel approach in the design of consumer electronic and/or wireless devices. Fabric tags, patches, or other fabric/garment-related items can be stitched or otherwise attached to the exterior housing of the CHUMBY™ device to convey product or corporate information, such as a logo.
  • FIG. 31 provides a sample flat pattern drawing 3100 for the flexible housing 3002 or “bag” of a CHUMBY™ device, showing individual fabric panel shapes, stitching details, and design elements:
  • FIGS. 6A-6D provide various partially transparent perspective, side and plan views of an embodiment of the CHUMBY™ device. FIGS. 6E-6F depict the core electronics unit and other components contained within the housing of the CHUMBY™ device, and FIG. 6G illustrates the arrangement of certain of these elements within the housing.
  • The core electronics unit 512 will generally include, for example, a main circuit board onto which are populated a plurality of electronic components. The main circuit board will generally then be integrated into a hard sub-frame made of a rigid material such as, for example, stiff plastic or metal, thereby yielding an electronics sub-assembly. The core electronics unit 512 will also typically include an LCD display, touchscreen, ambient light sensor, microphone, USB WiFi dongle 610, backup battery 620, and any number of RF shields. This core module is designed to be removable from the frame by the user of the CHUMBY™ device. It is typically connected into the housing CHUMBY™ by the Chumbilical™ connector 2910.
  • The WiFi dongle 610 is connected to the WiFi riser (not shown) of the core electronics unit and facilitates WiFi wireless networking.
  • The backup battery 620 may be realized using, for example, a standard 9V alkaline, and is used to provide backup/supplemental power to the CHUMBY™ device in the event of failure of the primary power supply. In one embodiment, the backup battery 620 is mounted onto an RF shield positioned on a back side of the core electronics unit 512 and is intended to be replaceable by the user. In another embodiment, the battery 620 is contained in the soft housing of the CHUMBY™ device and is accessible via a velcro-sealed hole in the exterior material for user service.
  • In the exemplary embodiment the daughtercard 640 provides connectors available to the user, including power input, headphone output, and external USB-style connectors for future accessories and/or facilitating device upgrades. The daughtercard sub-assembly 640 is clamped to the fabric in between the daughtercard sub-assembly front and rear bezel components 514, which are made of rigid ABS-type plastic. The daughtercard sub-assembly connects to the core electronics 512 via the Chumbilical™ 2910.
  • In the exemplary embodiment the CHUMBY™ device includes a pair of internally-mounted speakers 630 to provide stereo sound. In one embodiment, the speakers 630 are held in place using square pouches sewn into the interior of the unit. The pouches each have a small drawstring to keep the speakers 630 in a relatively fixed position within the interior of the CHUMBY™ device. In another embodiment, the speakers are retained in the rear bezel molding. Both speakers 630 connect to the daughtercard sub-assembly 640.
  • As is discussed below, the squeeze sensor 650 may be implemented in a variety of different ways to facilitate sensing of “squeezing” of the CHUMBY™ device. The squeeze sensor 650 is typically connected to the daughtercard sub-assembly 640 and in one particular embodiment comprises a flexible resistive element which varies in resistance based upon the angle of flex of the sensor. Alternatively, the squeeze sensor 650 may be comprised of a canonical snap action switch with a lever protruding into the body of the CHUMBY™ device and buffered by the surrounding fill material to give an overall soft feel. Accordingly, the squeeze sensor 650 is capable of detecting physical “squeezing” of the soft housing of the CHUMBY™ device. Signals from the squeeze sensor 650 are processed (e.g., by the core electronics module 512 or dedicated electronic circuitry) and generally will precipitate performance a defined action, which may be dependent upon characteristics of the currently active widget. The squeeze sensor 650 connects to the daughtercard sub-assembly 640. The squeeze sensor 650 will generally be attached to the inside of the CHUMBY™ bag and oriented parallel to the vertical access of the CHUMBY™ device. In other embodiments, one or more displacement sensors may be used to effect the same function.
  • The squeeze sensor 650 may be implemented in a variety of different forms to accomplish “squeeze sensing” within a CHUMBY™ device:
  • Mechanical sensor: As mentioned above, a mechanical switch, such as a “snap action” switch, may be mounted with its actuator lever curled over so that it does not catch on any of the internal fabric seams. Soft fill may be packed between the lever and the bag surface so as to spread the force of the squeeze around, thereby increasing the effective active area of the snap action switch. Soft fill may also be packed between the lever and the switch so as to provide extra restoring force so that the switch does not become stuck in one position.
  • Force or bend sensitive sensor: A strip, such as a resistive bend sensor, or a force sensor consisting of a resistive material, a spacer, and intercalated electrodes, may be adhered or sewn into the fabric. The deformation of the fabric modulates the resistance of these sensors, which could then be post-processed by the electronics in the bag into a bend signal.
  • Field sensor: A capacitive field sensor may be used, which creates a sensing field that extends up to the edge of the bag. When the bag is squeezed, the deformation and presence of the fingers will change the dielectric properties of the air within the bag. This change in dielectric property can be detected using a number of techniques, including but not limited to the shift in frequency of a resonant tank.
  • Acceleration sensor: An accelerometer inside the bag may be used to detect the signature of a deformation event based upon how the sensor moves inside the bag. A set of advanced signal identification primitives may be required, which may take the form of kalman filters, matched filters, and/or hidden markov estimators.
  • Fabrication of CHUMBY™ Device
  • As is described hereinafter, a number of process innovations have been developed to address a number of issues pertinent to fabrication of exemplary embodiments of the CHUMBY™ device. For example, challenges exist in ensuring that the soft housing retain each electronics sub-assembly; that is, ensuring that such sub-assemblies remain appropriately positioned within, and do not fall out of, the soft housing of the CHUMBY™ device. In particular, it will generally be desired that the core electronics unit be accessible with a small amount of effort on the part of the end user. A number of methods may be used to ensure a solid mating between the core electronics unit and the soft frame:
  • First, a plastic lip may be attached to an opening defined by the soft housing in the manner described below. The lip is preferably configured to have a smaller opening than the size of the core electronics sub-assembly. This difference in diameter or relevant dimension prevents the core from easily falling out of the plastic lip.
  • Second, the soft housing may internally include a set of buttresses that press against the core electronics sub-assembly to keep the housing from being easily pushed inward. The buttresses may take the form of a structural foam or of a rigid mechanical piece attached to the housing.
  • Third, the lip may have a set of friction-locking points, thus enabling it to engage into the core electronics sub-assembly through mating friction-lock points.
  • Fourth, the lip and core electronics sub-assembly may be glued together using a variety of adhesives. Using a brittle drying adhesive (such as a cyanoacrylate) allows the seal to be broken with minimal cosmetic impact.
  • In addition, the lip of the soft housing may be engineered using a soft but semi-tacky plastic, such as TPE, which inherently provides friction.
  • With respect to mating of the bezel of the daughtercard sub-assembly to the soft housing, it will typically be desired that the sub-assembly be mounted in place without any visible gapping so as to create a “seamless” look with respect to the remainder of the soft housing. A number of methods may be employed to ensure such a seamless mating:
  • First, an overmolded soft plastic lip (such as a TPE compound) can be applied to the plastic edge of the bezel for the daughtercard sub-assembly to facilitate blending.
  • Second, a viscous or semi-solid adhesive (such as VHB) can be applied to the daughtercard bezel prior to mounting to assist with minimizing gapping.
  • Third, a jig-shaped element may be used to hold the bezel component so as to facilitate alignment of the applicable components.
  • Fourth, a set of screw holes may be made in the fabric of the soft housing in alignment with mating screw-through pegs in the daughtercard bezel to facilitate both alignment and retention of the fabric.
  • Fifth, a friction-fit rim consisting of an exterior piece sandwiching an interior piece may be used to enhance the snugness of the seam between the soft housing and the daughtercard bezel.
  • In exemplary embodiments of the CHUMBY™ device a number of approaches may be used during the fabrication process to reduce the buildup of within the soft housing during operation of the CHUMBY™ device. Since in certain embodiment a CHUMBY™ device may gain its shape and resilience due to air trapped between the fibers of a compound similar to polyfill, the fill material and soft housing collectively act as an insulator around the various electronics sub-assemblies. Strategies for mitigating this potential insulating effect are described below.
  • One heat dissipation strategy involves filling the soft housing of the CHUMBY™ device with thermally-conductive materials. The materials may be dispersed in whole or in part through the soft fill material interposed between the electronics sub-assemblies and the soft housing. Such thermally-conductive materials may be composed of, for example, hollow aluminum beads or pellets, or plastics having relatively good thermal conduction characteristics. Another embodiment uses a thermally-conductive gel material to conduct the heat from the core electronics sub-assembly to the surface of the soft housing. Alternatively, a heat pipe may be used to conduct heat to a metal plate glued to the surface of the soft housing. Such approaches may advantageously leverage a large surface area and utilize relatively thin fabric material for the soft housing so as to minimize overall heat retention.
  • Heat dissipation may also be facilitated by “stacking” the various electronic sub-assemblies and other components in such a way that a low-thermal resistance path exists from each heat-generating component within the device to one of the solid structures facing exterior to the CHUMBY™ device (e.g., the daughtercard bezel or LCD display). In this embodiment such solid structures effectively function as heats sinks. Each low-thermal resistance path may be completed by interposing a thermal compound (e.g., in the form of soft, gel-like gap filling pads) between the heat generating electronics sub-assemblies and the externally facing solid structure. For example, in one embodiment the LCD display is held in place with an aluminum heat spreader plate, and a thermal compound is applied between the heat spreader and the LCD. In addition, the PCB of the core electronics sub-assembly may contain thermal vias and copper planes to enhance heat flow.
  • When the WiFi module is mounted directly to the PCB of the core electronics module, heat conduction may be enhanced using positioning a soft gel-like gap filling between the WiFi module to this PCB and ultimately through the LCD display to the ambient air. In another embodiment, the WiFi module is placed on a WiFi riser in order to enable generation of an improved antenna pattern. In this embodiment the WiFi module is positioned such that a suitably low-resistance thermal path is established between the module and the PCB of the core electronics module through any of the metal connectors or devices exposed on the PCB.
  • Assembling pieces of a soft, flexible material into the soft housing of CHUMBY™ device poses a number of challenges. One exemplary approach involves first sewing the pieces of flexible material inside out and then “turning” the resultant aggregation into its final bag-like configuration for mating (e.g., sewing) to the flexible frame 504. A number of difficulties which may be potentially encountered during this type manufacturing process and possible resolutions to such difficulties are described below.
  • Binding of the flexible frame to the sewing machine—In one approach a spray-on lubricant may be applied to a back of the flexible frame 504 to prevent binding of the soft housing to the foot of a sewing machine used to attach the soft housing to the frame 504. Such binding may also be reduced by laminating a piece of smooth paper to the back of the frame 504. Another process improvement that may be employed in combination with any or all of the above is to use a post-style or anvil-style sewing machine rather than a flatbed machine.
  • Misalignment due to mismatch of fabric and plastic durometer—As the sewing machine feeds the interface between the frame 504 and the fabric of the soft housing, the fabric will tend to stretch more and faster than the plastic frame 504. This may be compensated for by pre-distorting the fabric pattern by an amount matching the amount of distortion introduced by the sewing machine feed.
  • Misalignment due to operator error—Mismatch of the fabric of the soft housing and the frame 504 may occur due to the compound curves involved in realizing exemplary embodiments of the CHUMBY™ device, thereby making visual alignment difficult. Such mismatch may be reduced by integrating notches, marks, and dots into the plastic frame 504 and flat pattern to act as guides for the operator of the sewing machine.
  • Fabric puckering—Once a seam is created between the frame 504 and the fabric material of the soft housing, the fabric will tend to pucker away from the seam due to the fabric crushing in the vicinity of the seam. This may be compensated for by gluing the fabric onto the frame 504 prior to sewing. The glue acts both as a scaffolding to hold the fabric in place and to prevent the fabric from lifting off the surface of the frame 504.
  • Edge finishing—It is anticipated that small errors in sewing will tend to be more apparent or otherwise noticeable if the edges of the fabric of the soft housing are rough. This degradation in appearance may be addressed by treating the edges of the fabric to make them appear finished. The specific process employed depends upon the type of fabric material used. For example, in exemplary embodiments which use leather as the fabric material for the soft housing, the edges may be painted. When woven synthetics are used as the fabric material, the edges may first be heat-treated (either with an open flame or a heated metal die). In particular, when using synthetic fabrics for the soft housing a heated metal die may be utilized create a melted emboss pattern around the area of the die used for cutting the fabric. The melted emboss pattern will act to bind the fibers together and create a finished looking edge. For natural fabrics, the edges may be painted, folded under, or have sewing tape applied.
  • Height matching—In exemplary embodiments the plastics or other substances forming the frame 504 are pressed in high-precision molds; in contrast, the fabric materials used for the soft housing are the products of imprecise processes. Mismatch in height between the two can create objectionable visual artifacts. When leather is used as the fabric material, these artifacts may be ameliorated by skiving the leather so as to control its height prior to sewing to the frame 504. Also, the plastics or other materials used for the frame 504 will generally be molded such that they rise above the height of the finished leather over anticipated manufacturing tolerances. This reduces the visual impact of any imperfections, particularly when the device is viewed from “head-on”.
  • The process of initially integrating multiple pieces of flexible material into the soft prior to attachment to the frame 504 also poses a number of challenges. One exemplary process pertinent to a soft housing comprised of leather is described below.
  • First, the soft housing is assembled with the four leather panels, each of which forms one of the sides of the soft housing. When joining these seams, the leather is flipped over, glued, and pounded flat so as to reduce the profile and puckering of the seams when viewed from the front.
  • The leather has its thickness skived, at least in the area of any seam, so as to reduce puckering in the area of the seam.
  • The back of the soft housing is attached at the last stage of the process, and then the device is turned inside out.
  • In another embodiment, the leather seams are given excess length, and the material is sewn back upon itself to create a triple-stitch.
  • In other embodiments darts may be used to relieve stress around the curved edges of the soft housing. However, the use of darts may adversely affect the aesthetics of the device. Accordingly, in yet another embodiment a modified flat pattern having sufficient tolerance to handle any stresses that build up around such curved edges is utilized.
  • Due to the stresses that are stored in the flexible frame 504 and fabric housing, exemplary embodiments of the CHUMBY™ device may develop a permanent, assymetric bias in shape. The following techniques may be applied to limit the impact of these stresses.
  • First, the effects of friction at the interface between the sewing machine and the materials being sewn may be reduced in the manner described above.
  • Second, a hot melt may be applied to the frame 504 after the CHUMBY™ device has been assembled. The hot melt is applied on a shaped jig such that the when the hot melt cures it forces the device into a prescribed shape.
  • A stiffer fabric may be laminated to the back of soft fabrics used in the process. Although not visible from exterior to the CHUMBY™ device, the stiffness allows the natural shape of the fabric (as embodied by the flat pattern) to dominate the forces built into the stitch seams between the frame 504 and the fabric.
  • Natural fabrics, such as leather, contain defects that can impact the yield of the process. During the die cutting phase, coarser pieces of leather may be cut using the pattern for the bottom and back pieces, so as to lessen the visual impact of these pieces while increasing the overall usage of the leather hide.
  • The material selection for the frame 504 plays a large role in the manufacturability of the soft housing. The soft frame 504 will preferably comprise a material which is flexible yet does not stretch easily. It will typically be sufficiently soft to permit a sewing needle to penetrate without breaking. One embodiment uses a TPU type of plastic to implement the frame 504. This type of plastic has the advantage that the soft housing may be attached to using glue, but is relatively hard and sewing needles may have trouble penetrating its surface. Another embodiment uses a TPE type of plastic, which is flexible, does not stretch easily, and may be easily penetrated by a needle. However, it is difficult to induce adherence to the surface of TPE. Another embodiment uses a PVC/PU type of plastic, which is flexible, admits the application of glue, and is soft enough for a needle to easily penetrate.
  • In another embodiment, an EVA foam is used for both the frame 504 and the fabric of the soft housing, or just for the frame. The EVA may be cast over a mold of the desired size and allowed to set. This process may advantageously produce an integrated frame and flexible housing without sewing, and is capable accurately realizing precise geometries. However, the use of an EVA foam for both the frame and housing of a CHUMBY™ device results in the device exhibiting a stiffer feel than other implementations.
  • Attention is now directed to the exemplary user interface screens of a CHUMBY™ device shown in FIGS. 32-33, to which reference will be made in describing a process for calibration of the one or more bend sensors 650 within the device. When a user “squeezes” the back of a CHUMBY™ device and displaces the applicable squeeze sensor 650 beyond the threshold tolerance, the Control Panel function is activated and the appropriate user interface is displayed (FIG. 32). From a “settings” screen accessed 3220 via the Control Panel 3210 of FIG. 32, the user can then access the “squeeze” calibration function 3300 (FIG. 33) to recalibrate the bend sensor.
  • Although in certain embodiments the flexible or malleable housing of each CHUMBY™ device is intended to be essentially permanent and not replaced, in other embodiments such housings may comprise interchangeable “skins” designed to be easily detached and replaced at the discretion of the user. In such implementations the CHUMBY™ device may be configured to operate in accordance with various profiles depending upon the particular “skin” currently attached to the underlying hardware “core” of the device. Specifically, one or more sensors could be deployed upon the core of the CHUMBY™ device in order to read electronic identifiers embedded within the various skins disposed to be employed as the housing for the CHUMBY™ device. Each identifier could consist of a persistent (non-volatile) storage module containing unique identifying information, and would be physically configured so as to make electrical or radio contact with a corresponding sensor on the core of the CHUMBY™ device upon its skin becoming attached to the device core. The information read from such embedded identifiers could be used to inform the control system of the CHUMBY™ device of the identity of the skin currently enveloping the core of the device. Certain of such skins could, for example, include characteristics or features suggestive of various applications (e.g., “clock radio”, or “boom box”) or intended operating environments (e.g., “car”, “kitchen”, “workshop”). In another embodiment, an identifier can be written into non-volatile storage integral to a “skin”. When such “skin” is mated to the core, a wired connection is established between the non-volatile storage and the “core” in such a fashion that the identifier can be read directly from such.
  • Once a new skin has been attached or otherwise secured to the core of a CHUMBY™ device and the information from the embedded identifier has been read, the CHUMBY™ device may send a message to the service provider 106 indicative of its current skin (e.g., “skin # 1”). In response, the service provider 106 may reply with a message instructing the CHUMBY™ device to utilize a particular profile (e.g., “profile #3”). It is contemplated that users may elect to define, via a Web browser 122 in communication with the service provider 106, profiles for each of their skins or simply utilize default profiles available from the service provider 106. Each profile could define, for example: (i) the widgets to be executed, (ii) the configuration to be used for executing the widgets, and (iii) the style and theme information (color schemes, control decorations, fonts, backgrounds, etc) utilized in presenting information via the LCD display 320.
  • CHUMBY™ Service Provider
  • Referring now to FIG. 7, a block diagrammatic representation is provided of the server components and other infrastructure which may be utilized to facilitate the operations of the CHUMBY™ service provider 106. It is understood that the representation of FIG. 7 is functional in nature, and single or multiple computers may be adapted to execute software designed to perform one or more than one of the functions described below. For example, the functionality provided by the load balancers 704 may be provided by a single load balancing device or multiple load balancing devices. Similarly, each of the servers represented in FIG. 7 may be realized using either a single server computer or using a cluster comprised of primary, secondary and backup server computers interconnected in configurations familiar to those skilled in the art.
  • As shown in FIG. 7, one or more Web servers 710 are used to define the Web interface presented by the CHUMBY™ service provider 106 to users or other interested parties. A system database 712 may include, among other things, CHUMBY™ user account information, CHUMBY™ device configuration information, CHUMBY™ widget configuration and instance information, marketing materials, press information, and contact information relating to the CHUMBY™ service that is served by the Web servers 710. Also included may be information relating to registration and first-level support.
  • A user account server 714 maintains user account data in the system database 712 and provides authentication services to the other servers depicted in FIG. 7.
  • One or more widget servers 718 are used to serve widgets to CHUMBY™ devices 102. Each widget server 718 will typically be sufficiently powerful to encrypt and sign widgets on demand. In addition, each server 718 will be configured to “store-and-forward” widgets being sent from one user to another.
  • The service provider 106 may also utilize a number of content servers 724 to provide information (e.g., new, weather, stock market information) to CHUMBY™ devices 102. In an exemplary embodiment all content servers function in a “pull” mode of operation; that is, CHUMBY™ device 102 polls the applicable content server 724 for new data on some periodic basis. Each response from a content server 724 preferably contains the schedule and frequency for subsequent polls. For example, a content server 724 disposed to provide stock market information can change the polling frequency to reflect whether or not the stock market is open. In other implementations a CHUMBY™ device 102 may be provided with the capability to change polling frequencies on the basis of, for example, environmental conditions (e.g., ambient room brightness) or other factors. One or more of the content servers 724 may be used for serving certain types of content uploaded by users for use on their own or other CHUMBY™ devices 102 and stored within the system database 712.
  • The CHUMBY™ service provider 106 will typically maintain a small number of load-balanced Network Time Protocol (NTP) servers 730 to provide time to CHUMBY™ devices 102. Each such server 730 will be configured to fetch their time from a “primary” NTP server, which fetches time from an upstream external public NTP server. If the primary NTP server 730 is inoperative, secondary NTP servers 730 will synchronize with a random selection of upstream servers. If all servers 730 are unavailable, a CHUMBY™ device 102 will either fetch time information from random public NTP servers or simply have its time adjusted via user input. In one embodiment each CHUMBY™ device 102 requests time upon connecting to the Internet and at jittered intervals thereafter, no more frequently than once a day.
  • Turning now to FIG. 8, a database model diagram is provided of an exemplary object-oriented database schema 800 utilized by the system database 712. As shown, the schema 800 includes the following tables: buddies, categories, CHUMBY™ devices, parameters, profiles, skins, users, widget instance, widgets, ratings, registrations, activations, movies, templates, thumbnails. Each rectangular object in FIG. 8 is an entity object representation of a table in the database 712, with the primary key denoted with the acronym “PK”; ownership relationships indicated by dashed arrows which originate at the owned entity and terminate at the owning entity, and which are keyed by the asterisked column in the owned object; and solid arrows indicating a relationship between entities. Although the type of information contained within a number of these tables will be readily apparent to those skilled in the art in view of the discussion herein, a simplified example of various steps performed during user registration and the adding of a widget to a “profile” is provided in order to further illuminate the structure of the database schema 800.
  • In one embodiment the user registration and account creation process is initiated by a user through submission, via a Web browser 122, of a CHUMBY™ ID so as to identify a particular CHUMBY™ device 102. The act of creating a user account results in the construction of a default profile and one or more widget instances, each of which is automatically assigned to the CHUMBY™ device 102 (as identified by its CHUMBY™ ID) currently being registered. When a user adds a widget to the user's profile, the user is presented with a list of potential categories based upon information within the categories table. The user then selects a category from the categories table, and the user is presented with a list of widgets belonging to the chosen category. After the user chooses a widget, a widget instance is constructed and information is entered into the appropriate fields (e.g., profile id, widget id, index). The user is then presented a user interface via the Web browser 122 for editing the widget-specific parameters associated with the selected widget. In response to the user's parameter selections, records are appropriately updated in the parameters table.
  • FIGS. 36A-36H provide a more comprehensive tabular representation of an exemplary object-oriented database schema capable of being utilized by the system database 712.
  • System Operation Client-Server Communication Protocol
  • In general, it is contemplated that embodiments of the invention will be implemented such that each CHUMBY™ device 102 will function as a client relative to various servers existing within the CHUMBY™ service provider 106. In these embodiments the CHUMBY™ devices 102 do not engage in direct communication with each other, but may do so via independent client-sever relationships established with the service provider 106. In this way the service provider 106 may facilitate the communication of a variety of different types of executable files (e.g., widgets or other computer programs, audio clips, short “Flash” movies, etc.) among CHUMBY™ devices 102, subject to the permission of the content owner and potential recipient. A user may designate that a widget or other content be sent to another user, or to the members of a user's “buddy list” or the like. This designation may be made via a Web browser 122 in communication with the service provider 106, or directly through the interface of the user's CHUMBY™ device 102.
  • In one embodiment executable files may be created by users of CHUMBY™ devices 102 or other third parties and loaded within the system database 712 after being approved by the entity operating the service provider 106. Once a widget or other executable file has been created and stored within the system database 712, it is made available for use by all those users of CHUMBY™ devices 102 that have been granted the requisite permission. Various schemes for granting permissions among and between users are possible. For example, one such type of permission could entail that any user X that is given permission by a user Y to send widgets to user Y's CHUMBY™ device may select any widget for which user X has usage rights and “send” such widget to user Y's CHUMBY™ device. Other restrictions could be placed on the transferability of widgets or other files from the service provider 106 to a CHUMBY™ device at the request of another user. For example, a user could be provided with the capability to “lock” certain widgets on only the user's CHUMBY™ device, or a CHUMBY™ device could reach a “full” state and advertise itself as being incapable of receiving any additional widgets.
  • Although widgets and other executable files could be transferred between the service provider 106 and CHUMBY™ devices 102 in a number of different formats, in one embodiment such transfers will occur in the Flash movie format (i.e., as .swf files, when not signed or encrypted). In this case the process for downloading widgets from the service provider 106 includes receiving a notification at a CHUMBY™ device 102 that a “new” widget is ready for downloading. Since in the exemplary embodiment each CHUMBY™ device 102 acts in a “pull” mode, each device 102 periodically polls the service provider and inquires as to whether any configuration changes are available to load. In the case in which a new widget is available for downloading, the CHUMBY™ device 102 will generally use standard HTTP (or HTTPS) protocols in downloading the applicable widget file.
  • Attention is now directed to FIGS. 9-13, which are a series of signal flow diagrams representative of the client-server communication protocol established between a CHUMBY™ device 102 and the CHUMBY™ service provider 106. As mentioned above, each CHUMBY™ device 102 functions as a client relative to the CHUMBY™ service provider 106. In one embodiment the basic protocol established between each CHUMBY™ device and the corresponding server entity of the CHUMBY™ service provider 106 may be characterized as XML using a Representational State Transfer (REST) architecture transmitted using HTTP. In general, the CHUMBY™ device 102 issues periodic HTTP GET or POST requests and the service provider 106 responds with a block of XML. The CHUMBY™ device 102 will use HTTP GET for relatively simple requests, and POST for more complex requests, which will be in encapsulated in XML. Individual data elements are uniquely identified by Global Unique Identifiers (GUID). In one embodiment, there will be some form of cryptographic key exchange and transactions will be encrypted using those keys. Furthermore, XML may be compressed in order to facilitate transfer between the CHUMBY™ device 102 and the CHUMBY™ service provider 106.
  • Each CHUMBY™ device 102 will have a unique GUID. In some embodiments, time codes will be represented in ISO-8061 format.
  • Requesting a CHUMBY™ Configuration
  • Referring to FIG. 9, a signal flow diagram 900 illustratively represents one manner in which a “CHUMBY™ configuration” is provided to a CHUMBY™ device 102 by the service provider 106. In one embodiment each CHUMBY™ device 102 operates in accordance with a configuration, which specifies the profile to be loaded by the CHUMBY™ device 102 under various conditions. The user specifies the profile for the CHUMBY™ device 102 via a web interface at the CHUMBY™ web site. The profile contains several operational parameters for the CHUMBY™ device 102.
  • As shown in FIG. 9, the requesting of a configuration is initiated when the CHUMBY™ device 102 sends an HTTP GET request containing the GUID of the requested configuration to a CHUMBY™ configuration object within the system database 712 maintained by the service provider 106 (stage 902). An example of such a request is provided below:
  • http://server.chumby.com/xml/chumbies/CB6A8A20-DFB8-11DA-98FA-00306555C864
  • The service provider 106 receives the request (stage 904), and retrieves the requested configuration from the system database 712 (stage 908). If the requested configuration exists, the service provider responds with an XML-based configuration; if not, the service provider 106 responds with an XML-based error message (stage 912). An exemplary XML-based response generated by the service provider 106 is given below:
    <?xml version=“1.0” encoding=“UTF-8”?>
    <chumby id=“CB6A8A20-DFB8-11DA-98FA-00306555C864”>
     <name>Bathroom</name>
     <profile href=“/xml/profiles/00000000-0000-0000-0000-000000000001”
     name=“Default”
     id=“00000000-0000-0000-0000-000000000001”/>
     <user username=“Frank” href=“/xml/users/00000000-0000-0000-0000-
     000000000001”
     id=“00000000-0000-0000-0000-000000000001”/>
    </chumby>

    Once the response is received by the CHUMBY™ device 102, it is processed by the Master Controller (stage 916). If an error is instead received, it is processed by the Master Controller as well (stage 920).
  • Requesting a Profile
  • Referring to FIG. 10, a signal flow diagram 1000 illustratively represents one manner in which a “profile” is provided to a CHUMBY™ device 102 by the service provider 106. In one embodiment each CHUMBY™ device 102 operates in accordance with a profile, which specifies the set of widgets to be executed by the CHUMBY™ device 102 under various conditions. This enables a user to specify that a certain subset of the available set of widgets is to be instantiated and utilized during a particular time frame, based upon the location of the user's CHUMBY™ device 102 or the skin (or housing) within which the CHUMBY™ device 102 is currently seated. For instance, the user may desire that local weather and traffic information be provided while the user is located at home, but would prefer that airline flight information be available from the CHUMBY™ device 102 when the user is traveling.
  • As shown in FIG. 10, the requesting of a profile is initiated when the CHUMBY™ device 102 sends an HTTP GET request containing the GUID of the requested profile to a profile object within the system database 712 maintained by the service provider 106 (stage 1002). An example of such a request is provided below:
  • http://server.chumby.com/xml/profiles/00000000-0000-0000-0000-000000000001
  • The service provider 106 receives the request (stage 1004), and retrieves the requested profile from the system database 712 (stage 1008). If the requested profile exists, the service provider responds with an XML-based profile; if not, the service provider 106 responds with an XML-based error message (stage 1012). An exemplary XML-based response generated by the service provider 106 is given below:
    <?xml version=“1.0” encoding=“UTF-8”?>
    <profile id=“00000000-0000-0000-0000-000000000001”>
     <name>Default</name>
     <description>Default profile for your Chumby</description>
     <user username=“chumby” href=“/xml/users/00000000-0000-0000-0000-000000000001”
     id=“00000000-0000-0000-0000-000000000001”/>
     <skin href=“/xml/skins/00000000-0000-0000-0000-000000000001” name=“Standard”
     id=“00000000-0000-0000-0000-000000000001”/>
     <access access=“private” id=“EC667B90-EC41-11DA-8774-00306555C864”/>
     <widget_instances>
      <widget_instance href=“/xml/widgetinstances/B2BE8552-E7F2-11DA-B4BD-00306555C864”
      id=“B2BE8552-E7F2-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/033BFBC2-E794-11DA-B4BD-00306555C864”
      id=“033BFBC2-E794-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/94177E18-E777-11DA-B4BD-00306555C864”
      id=“94177E18-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/9AA50336-E777-11DA-B4BD-00306555C864”
      id=“9AA50336-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/9E4647F2-E777-11DA-B4BD-00306555C864”
      id=“9E4647F2-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/7AC67832-E77D-11DA-B4BD-00306555C864”
      id=“7AC67832-E77D-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/B4C35F06-E777-11DA-B4BD-00306555C864”
      id=“B4C35F06-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/5D81823A-E77D-11DA-B4BD-00306555C864”
      id=“5D81823A-E77D-11DA-B4BD-00306555C864”/>
     </widget_instances>
      <buddies_of>
       <buddy profile=“A9BF0AC6-07DB-11DC-A700-0017F2D98B02” name=“fredgarvin”
      profilename=“Default” id=“9790F788-07DB-11DC-A700-0017F2D98B02”/>
       </buddies_of>
    </profile>

    Once the response is received by the CHUMBY™ device 102, it is processed by the Master Controller (stage 916). If an error is instead received, it is processed by the Master Controller as well (stage 920).
  • Each Profile has a name, a description, a skin, and a list of “Widget Instances”. The Profile will be periodically refetched in order to reflect changes made by the owner, for instance, adding and removing Widget Instances. The Profile may also contain a “buddies_of” node, which contains information about users and profiles that have indicated the owner of the Profile to be a “buddy” in order to facilitate the sending of widget instances.
  • The CHUMBY™ device 102 processes each Widget Instance in turn, fetching the settings for each widget, and the Widget itself, and displays the Widget with the settings encapsulated by the Widget Instance.
  • A process similar to that described with reference to FIG. 9 may be used to change a profile. An example of an HTTP POST containing an the GUID of the profile to modify and an XML-based request to change a profile generated by the CHUMBY™ device 102 is given below:
  • http://server.chumby.com/xml/profiles/00000000-0000-0000-0000-000000000001
    <?xml version=“1.0” encoding=“UTF-8”?>
    <profile id=“00000000-0000-0000-0000-000000000001”>
     <name>Default</name>
     <description>Default profile for your Chumby</description>
     <user username=“chumby” href=“/xml/users/00000000-0000-0000-0000-000000000001”
     id=“00000000-0000-0000-0000-000000000001”/>
     <skin href=“/xml/skins/00000000-0000-0000-0000-000000000001” name=“Standard”
     id=“00000000-0000-0000-0000-000000000001”/>
     <access access=“private” id=“EC667B90-EC41-11DA-8774-00306555C864”/>
     <widget_instances>
      <widget_instance href=“/xml/widgetinstances/B2BE8552-E7F2-11DA-B4BD-00306555C864”
      id=“B2BE8552-E7F2-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/033BFBC2-E794-11DA-B4BD-00306555C864”
      id=“033BFBC2-E794-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/94177E18-E777-11DA-B4BD-00306555C864”
      id=“94177E18-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/9AA50336-E777-11DA-B4BD-00306555C864”
      id=“9AA50336-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/9E4647F2-E777-11DA-B4BD-00306555C864”
      id=“9E4647F2-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/7AC67832-E77D-11DA-B4BD-00306555C864”
      id=“7AC67832-E77D-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/B4C35F06-E777-11DA-B4BD-00306555C864”
      id=“B4C35F06-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/10A66395-8500-215E-81F0-003256F98257”
      id=“10A66395-8500-215E-81F0-003256F98257”/>
     </widget_instances>
    </profile>
  • An exemplary XML-based response corresponding to such a request which contains the updated profile could be provided by the service provider 106 as follows:
    <?xml version=“1.0” encoding=“UTF-8”?>
    <profile id=“00000000-0000-0000-0000-000000000001”>
     <name>Default</name>
     <description>Default profile for your Chumby</description>
     <user usename=“chumby” href=“/xml/users/00000000-0000-0000-0000-000000000001”
     id=“00000000-0000-0000-0000-000000000001”/>
     <skin href=“/xml/skins/00000000-0000-0000-0000-000000000001” name=“Standard”
     id=“00000000-0000-0000-0000-000000000001”/>
     <access access=“private” id=“EC667B90-EC41-11DA-8774-00306555C864”/>
     <widget_instances>
      <widget_instance href=“/xml/widgetinstances/B2BE8552-E7F2-11DA-B4BD-00306555C864”
      id=“B2BE8552-E7F2-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/033BFBC2-E794-11DA-B4BD-00306555C864”
      id=“033BFBC2-E794-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/94177E18-E777-11DA-B4BD-00306555C864”
      id=“94177E18-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/9AA50336-E777-11DA-B4BD-00306555C864”
      id=“9AA50336-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/9E4647F2-E777-11DA-B4BD-00306555C864”
      id=“9E4647F2-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/7AC67832-E77D-11DA-B4BD-00306555C864”
      id=“7AC67832-E77D-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/B4C35F06-E777-11DA-B4BD-00306555C864”
      id=“B4C35F06-E777-11DA-B4BD-00306555C864”/>
      <widget_instance href=“/xml/widgetinstances/10A66395-8500-215E-81F0-003256F98257”
      id=“10A66395-8500-215E-81F0-003256F98257”/>
     </widget_instances>
    </profile>
  • Widget Instance Upload/Download
  • Turning now to FIGS. 11-12, there are shown signal flow diagrams representative of the communication of widget instance information from the CHUMBY™ device 102 to the service provider 106, and vice-versa. In one embodiment the set of parameters associated with a widget instance determine the user-specified manner in which the behavior of the widget is modified when executed by a CHUMBY™ device 102. That is, the parameters fetched by the CHUMBY™ device 102 from the service provider 106 for a given widget constitute the user's “customized” settings, rather than dynamic content. For example, in the case of a “stock ticker” widget the applicable parameters could comprise the names and symbols of the stocks within the user's portfolios, but would not define or relate to the current prices of the stocks (which would be furnished by another service supplied by the service provider 106).
  • FIG. 11 is a signal flow diagram which depicts processing of changes made to the parameters of a widget instance through the interface of the CHUMBY™ device 102 in which the widget is instantiated. Examples of parameter changes could include changing a location of interest in the case of a “weather” widget, or adding/removing stock ticker symbols in the case of a “stock market” widget. In the exemplary embodiment it is not necessary for the user to set or otherwise modify all parameters of a given widget, and the service provider 106 will effectively “expand” the parameter change data into a full parameter record once received. For instance, a zip code could be sufficient to uniquely identify a location in the case of a weather widget, and the associated city, state, etc. could be supplied to the applicable record during processing of the parameter change request by the service provider 106.
  • As shown, the widget instance change operation is initiated when the CHUMBY™ device 102 sends an HTTP POST and an XML request to a widget instance object within the system database 712 maintained by the service provider 106 (stage 1102). This type of “UPLOAD” operation informs the service 106 that the parameters of a specific widget instance have been updated by the applicable user. As shown, the updated parameters are received by the service provider (stage 1104), and are attempted to be written to a corresponding widget instance object within the system database 712 (stage 1108). If this attempted write operation is unsuccessful (stage 1112), the service provider 106 responds with an error message that is processed by the requesting CHUMBY™ device 102 (stage 1120). If the write operation is successful, the newly updated widget instance are retrieved from the system database 712 (stage 1116) and sent to the applicable CHUMBY™ device 102 (stage 1120).
  • Once received, the widget instance is processed by the CHUMBY™ device 102 (stage 1124). In general, the processing of the parameters contained in a widget instance are dependent upon the characteristics of the particular widget. In certain cases the parameters may be sufficient to enable the widget to display information, while other widgets may use the parameters to fetch content from another service. As an example of the former, consider a “clock” widget capable of displaying information following receipt of a parameter indicating a time zone. In contrast, a “stock widget” may have stock symbols as parameters and use such symbols to fetch quote information.
  • Referring now to FIG. 12, there is shown a signal flow diagram illustrating an exemplary widget instance download operation in which the service provider 106 is requested to push values of widget-specific parameters to a requesting CHUMBY™ device 102. The requesting of a parameter download is initiated when the CHUMBY™ device 102 sends an HTTP GET containing the GUID of the requested widget instance request to a parameter object within the system database 712 maintained by the service provider 106 (stage 1202). An example of such a request in the case of a “weather” widget is provided below:
  • http://server.chumby.com/xml/widgetinstances/5D81823A-E77D-11DA-B4BD-00306555C864
  • The service provider 106 receives the request (stage 1204), and retrieves the requested parameters from the system database 712 (stage 1208). If the requested parameters exist, the service provider 106 responds with an XML-based widget instance message (stage 1212). Using the example of a weather widget, which utilizes a zip code to identify the location for which weather is to be retrieved, such a message could comprise:
    <?xml version=“1.0” encoding=“UTF-8”?>
    <widget_instance id=“5D81823A-E77D-11DA-B4BD-00306555C864”>
     <widget href=“/xml/widgets/BF4CE814-DFB8-11DA-9C82-00306555C864” id=“BF4CE814-
     DFB8-11DA-9C82-00306555C864”/>
     <profile href=“/xml/profiles/00000000-0000-0000-0000-000000000001” id=“00000000-0000-0000-
     0000-000000000001”/>
     <access access=“private”/>
     <mode time=“10” mode=“timeout”/>
     <received buddy=“9790F788-07DB-11DC-A700-0017F2D98B02” forward=“true”
     accepted=“false”/>
     <widget_parameters>
      <widget_parameter id=“BF4CE814-DFB8-11DA-9C82-00306643C864”>
       <name>ZipCode</name>
       <value>92037</name>
      </widget_parameter>
     </widget_parameters>
    </widget_instance>
  • The CHUMBY™ device 102 uses the GUID in the “widget” tag to fetch the information about the Widget to be displayed. Once the widget has been started, it is passed the name/value pairs in the “widget parameters” section, in order to customize the behavior of the widget. The “mode” tag indicates how long the widget is to be played. A value of “default” in the mode attribute indicates that the timing will be specified by the widget description, an attribute value of “timeout” will use the duration specified in the “time” attribute (in seconds), and the value of “cooperative” will display the widget until the user explicitly commands it to stop through a UI element, or the widget itself indicates that it wishes to discontinue operation. The presence of a “received” node indicates that the widget instance has been “sent” by a buddy. The value of the “accepted” attribute indicates whether or not the widget instance has been accepted by the recipient, which is done either through the web interface or through the UI of the device. The “forward” attribute indicates whether this widget instance can be sent on to another user.
  • If the requested parameters do not exist, a default widget instance is attempted to be retrieved from the system database 712 (stage 1224). If such a widget instance exists (stage 1228), the service provider 106 responds with an XML-based parameters message that is processed by the CHUMBY™ device 102 upon receipt (stage 1220). If such a default widget instance does not exist, an error message is returned to the CHUMBY™ device 102 (stage 1232).
  • Downloading a Widget
  • Referring now to FIG. 27, a signal flow diagram 2700 is provided which illustratively represents the process of downloading the code for a widget (e.g., a .swf file) from the service provider 106 for execution on a CHUMBY™ device 102. The process is initiated when the CHUMBY™ device 102 sends an HTTP GET request containing the GUID of the requested widget to a specific widget description object within the system database 712 maintained by the service provider 106 (stage 1302). An example of such a request is provided below:
  • http://server.chumby.com/xml/widgets/BF4CE814-DFB8-11DA-9C82-00306555C864
  • The service provider 106 receives the request (stage 2704), and attempts to retrieve the requested widget description from the system database 712 or other data source available to the service provider 106 (stage 2708). If the requested widget description is able to be retrieved, the service provider 106 responds with an XML-based widget description message; if not, the service provider 106 responds with an XML-based error message (stage 2712). An exemplary XML-based response generated by the service provider 106 is given below:
    <?xml version=“1.0” encoding=“UTF-8”?>
    <widget id=“BF4CE814-DFB8-11DA-9C82-00306555C864”>
     <name>Time Zones</name>
     <description>A time zone selector</description>
     <version>1.0</version>
     <protection protection=“none”/>
     <mode time=“15” mode=“default”/>
     <access sendable=“true” deleteable=“true” access=“public” virtualable=“true”/>
     <user username=“chumby” href=“/xml/users/00000000-0000-0000-0000-000000000001”
     id=“00000000-0000-0000-0000-000000000001”/>
     <category href=“/xml/categories/00000000-0000-0000-0000-000000000001” name=“Chumby”
     id=“00000000-0000-0000-0000-000000000001”/>
     <thumbnail contenttype=“image/jpeg” href=“/xml/thumbnails/BF4CE814-DFB8-11DA-9C82-
     00306555C864”/>
     <template contenttype=“text/xml” href=“/xml/templates/BF4CE814-DFB8-11DA-9C82-
     00306555C864”/>
     <movie contenttype=“application/x-shockwave-flash” href=“/xml/movies/BF4CE814-DFB8-11DA-
     9C82-00306555C864”/>
     <rating count=“0” rating=“0.0”/>
    </widget>
  • Once the requested widget description is received by the CHUMBY™ device 102, the CHUMBY™ device 102 uses the URL referencing the “movie” for the requested widget to download the movie (e.g., .swf) file from the service provider 106. The CHUMBY™ device 102 sends an HTTP GET request containing the GUID of the requested movie to a specific movie object within the system database 712 maintained by the service provider 106 (stage 1320). An example of such a request is provided below:
  • http://server.chumby.com/xml/movies/BF4CE814-DFB8-11DA-9C82-00306555C864
  • The service provider 106 receives the request (stage 2724), and attempts to retrieve the requested movie from the system database 712 or other data source available to the service provider 106 (stage 2728). If the requested movie is able to be retrieved, the service provider 106 responds with the .swf file which implements the movie; if not, the service provider 106 responds with an XML-based error message (stage 2732). Once the requested movie is received by the CHUMBY™ device 102, it is loaded by the Master Controller and queued for subsequent execution (stage 2736). If an error is instead received, it is processed accordingly (stage 2740).
  • Requesting Content
  • Referring now to FIG. 13, a signal flow diagram 1300 is provided which illustratively represents the process of obtaining content from the service provider 106 for a widget of a CHUMBY™ device 102. The process is initiated when the CHUMBY™ device 102 sends an HTTP GET and an optional XML request to a specific content object within the system database 712 maintained by the service provider 106 (stage 1302). An example of such a request for content for a “tide” widget is provided below:
    http://content.chumby.com/tides/United%20States/
    National%20City%2C%20San%20Diego%20Bay%
    2C%20California
  • The service provider 106 receives the request (stage 1304), and attempts to retrieve the requested content from the system database 712, internal content service, external content service or other data source available to the service provider 106 (stage 1308). If the requested content is able to be retrieved, the service provider 106 responds with an XML-based content message; if not, the service provider 106 responds with an XML-based error message (stage 1312). Once the requested content is received by the CHUMBY™ device 102, corresponding audiovisual output is generated by the device 102 for the benefit of its user (stage 1316). If an error is instead received, it is processed accordingly (stage 1320). An exemplary XML-based response generated by the service provider 106 is given below:
    <tideitems>
     <tideitem timestamp=“2006-05-31T00:39:11Z”>
      <location>
       <locationstring string=“National City, San Diego Bay, California”/>
       <station id=“National City, San Diego Bay”/>
       <state name=“California”/>
       <country name=“United States”/>
       <coordinates lat=“32.6667A° N”, lon=“117.1167A° W”/>
      </location>
      <tides>
       <tide dateTime=‘2006-05-31T12:44:00Z’, tidedescription=“Low Tide”, tidelevel=“0.85
       meters”/>
       <tide dateTime=‘2006-05-31T02:50:00Z’, tidedescription=“Sunset”/>
       <tide dateTime=‘2006-05-31T06:30:00Z’, tidedescription=“Moonset”>
       <tide dateTime=‘2006-05-31T06:56:00Z’, tidedescription=“High Tide”, tidelevel=“1.80
       meters”/>
       <tide dateTime=‘2006-05-31T24:41:00Z’, tidedescription=“Sunrise”/>
       <tide dateTime=‘2006-05-31T14:46:00Z’, tidedescription=“Low Tide”, tidelevel=“−0.13
       meters”/>
       <tide dateTime=‘2006-05-31T16:38:00Z’, tidedescription=“Moonrise”/>
       <tide dateTime=‘2006-05-31T21:55:00Z’, tidedescription=“High Tide”, tidelevel=“1.14
       meters”/>
       <tide dateTime=‘2006-06-01T01:38:00Z’, tidedescription=“Low Tide”, tidelevel=“0.92
       meters”/>
       <tide dateTime=‘2006-06-01T02:50:00Z’, tidedescription=“Sunset”/>
       <tide dateTime=‘2006-06-01T07:06:00Z’, tidedescription=“Moonset”/>
       <tide dateTime=‘2006-06-01T07:41:00Z’, tidedescription=“High Tide”, tidelevel=“1.64
       meters”/>
       <tide dateTime=‘2006-06-01T24:41:00Z’, tidedescription=“Sunrise”/>
       <tide dateTime=‘2006-06-01T15:37:00Z’, tidedescription=“Low Tide”, tidelevel=“−0.01
       meters”/>
       <tide dateTime=‘2006-06-01T17:38:00Z’, tidedescription=“Moonrise”/>
       <tide dateTime=‘2006-06-01T22:59:00Z’, tidedescription=“High Tide”, tidelevel=“1.18
       meters”/>
       <tide dateTiine=‘2006-06-02T02:51:00Z’, tidedescription=“Sunset”/>
       <tide dateTime=‘2006-06-02T02:58:00Z’, tidedescription=“Low Tide”, tidelevel=“0.96
       meters”/>
       <tide dateTime=‘2006-06-02T07:37:00Z’, tidedescription=“Moonset”/>
       <tide dateTime=‘2006-06-02T08:35:00Z’, tidedescription=“High Tide”, tidelevel=“1.47
       meters”/>
       <tide dateTime=‘2006-06-02T24:41:00Z’, tidedescription=“Sunrise”/>
       <tide dateTime=‘2006-06-02T16:28:00Z’, tidedescription=“Low Tide”, tidelevel=“0.09
       meters”/>
       <tide dateTime=‘2006-06-02T18:35:00Z’, tidedescription=“Moonrise”/>
       <tide dateTime=‘2006-06-02T23:51:00Z’, tidedescription=“High Tide”, tidelevel=“1.26
       meters”/>
       <tide dateTime=‘2006-06-03T02:51:00Z’, tidedescription=“Sunset”/>
       <tide dateTime=‘2006-06-03T04:44:00Z’, tidedescription=“Low Tide”, tidelevel=“0.93
       meters”/>
       <tide dateTime=‘2006-06-03T08:04:00Z’, tidedescription=“Moonset”/>
       <tide dateTime=‘2006-06-03T09:46:00Z’, tidedescription=“High Tide”, tidelevel=“1.31
       meters”/>
       <tide dateTime=‘2006-06-03T24:41:00Z’, tidedescription=“Sunrise”/>
       <tide dateTiine=‘2006-06-03T17:17:00Z’, tidedescription=“Low Tide”, tidelevel=“0.19
       meters”/>
       <tide dateTime=‘2006-06-03T19:31:00Z’, tidedescription=“Moonrise”/>
       <tide dateTime=‘2006-06-03T23:06:00Z’, tidedescription=“First Quarter”/>
       <tide dateTime=‘2006-06-04T12:30:00Z’, tidedescription=“High Tide”, tidelevel=“1.35
       meters”/>
      <tides>
     </tideitem>
    </tideitems>
  • In the case where content is retrieved directly from an external content service provider (i.e., from other than the service provider 106), a series of web-based transactions (most likely HTTP and/or XML-based) defined by such content service provider will take place between the CHUMBY™ device 102 and such provider.
  • CHUMBY™ Security Protocol
  • CHUMBY™ devices 102 may optionally include a hardware security module, which in one implementation is accessed via a character driver interface in the operating system (“OS”) of the device 102. The module may or may not be installed. When the module is not installed, the OS preferably virtualizes the hardware security module by emulating it in software. While losing all the tamper-resistance benefits of a hardware module, this feature enables cost reduction savings while maintaining protocol interoperability with a secured system.
  • The hardware security module of a CHUMBY™ device 102 may be implemented in a number of ways. As an example, the hardware security module may be implemented using a monolithic security processor or a cryptographic Smart Card module. This module, or its emulated counterpart, is capable of at a minimum, the following operations: (1) storage of secret numbers in hardware; (2) the ability to compute public-key signatures; (3) the ability to compute one-way cryptographic hashes; and (4) the ability to generate trusted random numbers.
  • During the manufacturing process the hardware security module, or its emulated counterpart, is initialized with a set of secret numbers that are only known to the module and to the CHUMBY™ service provider 106. These secret numbers may or may not consist of public and private keys. If the numbers consist of public and private keys, then a mutual key-pair is stored by both the CHUMBY™ service provider 106 and the hardware module, along with a putative, insecure identifier number for the pair. Furthermore, these numbers are preferably not recorded by the CHUMBY™ service provider 106 in association with any other identifying information, such as the MAC address for the WLAN interface, or any other serial numbers that are stored in insecure memory for customer service purposes.
  • When the user or service wishes to initiate a strong authenticated transaction, the CHUMBY™ device 102 sends the putative insecure key-pair identifier to the service provider 106. The service provider 106 looks up the putative insecure key-pair identifier and issues a challenge to the hardware module, consisting of a random number In particular, the challenge is packetized and sent through the Internet to the CHUMBY™ device 102. The device 102 unpacks the challenge and passes it directly to the hardware module. The hardware module adds another random number to the packet and signs the pair of numbers, along with other transaction information (such as the version number of the protocol) with a private key that is only known to the CHUMBY cryptoprocessor. In addition, an “owner key” may optionally be encrypted to the server public key. Again, this message is packetized and transmitted by the device 102 to the service provider 106 over the Internet. Upon receipt, the service provider 106 verifies the signature of the packet using the device's public key, which was generated and recorded at the time of manufacture and indexed by the hash of the putative insecure key-pair identifier. The CHUMBY device is deemed authentic if the signature is correct and the signed packet contains the exact random number that was generated by the service provider in the first step of the challenge. The service provide 106 also decrypts the owner key, whose purpose is discussed in the next paragraph. At the conclusion of this transaction, the service provider 106 has authenticated the device 102, and can fall back to any number of session keys that can be either dynamically generated or statically stored for further secured transactions. Advantageously, this authentication transaction does not involve uniquely associating the hardware module with user information. Rather, the service provider 106 is simply aware of the existence of the approved hardware module and upon completion of the authentication transaction may safely trust the integrity of the secrets stored therein.
  • The owner key comprises a random number (or one of a set of random numbers) generated at the time of manufacture and stored only within the cryptographic processor. The owner key is transmitted to the server, encrypted using the server public key, and used as a shared secret to protect any other secrets (user passwords, credit card information, etc.) that may be stored on the server. Once a user decides they no longer wish to continue with the service, or desire to sell or transfer their CHUMBY™ device, or otherwise wish to revoke any secrets entrusted to the server, the user can instruct the cryptographic processor to delete the key from memory, thereby abolishing the server's ability to decrypt the secrets entrusted to it.
  • A user of the device 102 may opt-out of privacy mode and provide identifying information, as required by some billing services such as credit cards and banks. Optionally, an anonymous cash-based transaction network can be established where accounts are opened and managed only by secrets contained within the hardware module.
  • To enable limited revocation of user-identifying information, the specific embodiment of the master authentication protocol should operate on a set of clean-room servers with a multiplicity of connections that are trusted by the CHUMBY™ service provider 106, and authenticated session keys are then passed on laterally to the content servers. Thus, the anonymity of the master authentication key is nominally preserved, although it is possible to recreate and correlate transactions from forensic logs and transaction timings. The use of multiple servers and multiple connections, along with network routing randomization techniques, can be used to increase the anonymization resistance to forensic logging (cf. Tor network), but this configuration is in no way essential to the network's operation.
  • CHUMBY™ Device Calibration, Registration and Account Management
  • Attention is now directed to FIGS. 14-21, which are a set of flowcharts representative of the calibration, registration and initial operation of a CHUMBY™ device and associated account management functions.
  • Initial Power-Up
  • FIG. 14 is a flowchart 1400 which depicts an exemplary sequence of operations performed by a CHUMBY™ device 102 upon initial power-up. When a user initially connects a CHUMBY™ device 102 to a power source, the device 102 undergoes a touchscreen calibration process described below with reference to FIGS. 15-16 (stage 1404). The device 102 then selects a wireless base station in the manner described below with reference to FIG. 17 (stage 1408). If a proxy server is identified (stage 1412), then information relating to the proxy server is configured into the CHUMBY™ device 102 to enable it to with the Web site maintained by the service provider 106 (as well as with the Web sites of content providers) (stage 1416). At this point the user of the CHUMBY™ device 102 is prompted to set the time zone in which the device 102 is located (stage 1420). If an NTP server is determined to be available (stage 1430), then time is set automatically based upon information acquired from such a server (stage 1440). If not, the CHUMBY™ device 102 is referenced to a time set manually (stage 1444). After the time of the CHUMBY™ device 102 has been set, the registration process described below with reference to FIG. 18 is initiated (stage 1450).
  • In one embodiment a CHUMBY™ device downloads configuration information from the service provider 106 each time it is powered on or otherwise re-establishes communication with the service provider 106. However, a minimal amount of widget and configuration information may be locally stored on a CHUMBY™ device so that it may continue to function in the absence of network connectivity. For example, a clock widget may be permanently stored on a CHUMBY™ device so that its clock function could remain operational at all times. A CHUMBY™ device will typically include sufficient memory capacity to hold configuration information received from the service provider 106 for all of the widgets to be executed by the device, up to some reasonable number of widgets. If a user changes the configuration for a CHUMBY™ device through the Web site maintained by the service provider 106, a polling function implemented on the corresponding CHUMBY™ device will typically be used to “pull” the modified configuration information from the service provider 106. Alternatively, an operation may be manually initiated via the interface of the corresponding CHUMBY™ device in order to obtain this information (e.g., an “Update My CHUMBY™ Device Now” operation).
  • Touchscreen Calibration
  • Turning now to FIG. 15, there is shown a flowchart which illustrates an exemplary routine used to calibrate the touchscreen of a CHUMBY™ device 102. FIGS. 16A-16E provide a set of screen shots of the user interface of the CHUMBY™ device 102 being calibrated pursuant to the routine of FIG. 15. As shown, the calibration routine involves determining an upper left set point (stage 1502). This set point is determined by generating a target 1602 (FIG. 16A) through the LCD screen 320 which the user is then prompted to tap. A lower right set point is then determined by prompting the user to tap a target 1604 depicted in FIG. 16D (stage 1506). After the lower right set point target 1604 has been tapped, the user is instructed to test the touch screen calibration (stage 1510) by dragging the ball 1605 depicted in FIG. 16C from ring A 1606 to ring B 1607. Once the ball 1605 has been successfully placed in ring B 1607, a notification of success 1608 as depicted in FIG. 16D will be displayed and done button 1609 will be activated. Once the done button 1609 has been pressed, the results of the calibration process are then stored (stage 1514). Based upon the coordinate data received from the touchscreen 330 during each of stages 1502 and 1506, the CPU 302 executes a program to generate calibration information used during subsequent operation of the device 102.
  • Wireless Base Station Selection
  • FIG. 17 is a flowchart illustrating the operations performed in selecting a wireless base station upon initial power-up of the device 102. As shown, the Wi-Fi communications interface 314 of the device initially searches for one or more access points 210 emitting a beacon signal (stage 1702). If the device is configured to search for access points not emitting a beacon signal (stage 1706), then a keyboard is accessed (stage 1710) and data designating an access point is entered (stage 1714). The keyboard may comprise a physical keyboard connected to the device 102 as a peripheral component. Alternatively, an “onscreen” keyboard generated by the LCD screen 320 and interacted with via the touchscreen 330 may be utilized. Once data designating an access point has been entered, a subsequent scan (stage 1715) will be initiated in an attempt to find the access point that was not emitting a beacon signal. Once one or more wireless networks have been discovered, the user is given the option to select one from a list (stage 1717). When a wireless network is selected, the CPU 302 executes a program to determine various aspects of the chosen wireless network (stage 1718), including but not limited to authentication mode, encryption type, channel/frequency, etc. If a suitable network is not detected, the user may be given the choice to enter the network configuration properties (e.g. SSID, authentication mode, etc) manually (stage 1730). If the user chooses to manually enter network properties, a keyboard (stage 1710) is displayed and the user is prompted to enter the network properties (stage 1731). If the selected or designated network requires authentication (e.g., WPA, WPA2, etc) and/or or is otherwise encrypted (e.g., WEP, AES, TKIP, etc), a keyboard (stage 1710) is displayed and the user is given the opportunity to enter the applicable key (stage 1720). In the event that a user enters a WEP key, the key size will be determined automatically by the length of the key entered by the user. The user is then presented with a choice of automatic or manual IP allocation (stage 1732). Should the user select a manual IP allocation, a keyboard (stage 1710) is displayed and the user is prompted to enter IP related configuration data (stage 1733) such as IP address, netmask, gateway, nameservers, etc. After the IP allocation method has been chosen and optionally configured, the user will be asked to confirm the network settings (stage 1735). A connection is then attempted to be established with a detected or designated access point (stage 1740). If a connection is so established (stage 1750), then the information relating to the connection is stored within the memory of the device 102 (stage 1755); otherwise the user is given the option to reattempt to establish the connection.
  • Registration
  • Referring now to FIG. 18, a flowchart is provided of an exemplary account creation and registration process 1450. The process begins upon presentation by the device, via its LCD screen 320, of its serial number or other identifying information (stage 1802). The user then logs in, via a Web browser 122, to a web site operated by the service provider 106 (e.g., www.chumby.com) (stage 1804). In one embodiment the user may then select a “create new user account” tab or the like (stage 1808), and is prompted to enter an email address (stage 1810), password (stage 1812), and name (stage 1816). In certain implementations the user may also be offered the opportunity to enter his or her address (stage 1820), while in other implementations the user is not prompted to provide an address until this information is required for some particular purpose (e.g., to provide a billing information for a subscription or shipping information for a product purchase). If this option is selected, the user enters his or her address (stage 1824). In certain implementations, the user may be prompted to provide other identifying and/or demographic information (not shown in this figure). At this point the service provider 106 sends an email to the address entered in stage 1810 which contains a “click through” account activation hyperlink (stage 1830). If the user does not receive this message (stage 1834), the user is provided with the opportunity to take advantage of various customer service options in order to remedy the account creation difficulties being experienced (stages 1840-1841). In any event, the account creation process is then finalized (stage 1850), and the CHUMBY™ device being registered is associated within the system database 712 with a particular user account in the manner described below (stage 1854). Once this has occurred a default configuration and a number of widget instances are established for the newly registered CHUMBY™ device (stage 1860).
  • Account Association
  • FIG. 19 is a flowchart representative of exemplary Web-based interaction occurring between a user and the service provider 106 in connection with associating a particular CHUMBY™ device with the user's account. The process is initiated when the user logs in to a Web site operated by the service provider 106 (stage 1902) and selects an “Activate a CHUMBY™” link or the equivalent (stage 1904). The user enters a name of the CHUMBY™ device (e.g., bedroom, study, Fred, evening, etc.) (stage 1908) and then, as described in the above-referenced co-pending U.S. Provisional Application Ser. No. 60/945,900, the user duplicates the “captcha grid” pattern displayed on the “Activate a CHUMBY™” page on the corresponding “Activate CHUMBY™” screen on the CHUMBY™ device and selects “OK” (stage 1910). The CHUMBY™ device then transmits the encoded pattern along with the putative id (unique serial number) of the CHUMBY™ device to the server for verification and association with the user's account. Alternatively, the user may directly enter the putative id (unique serial number) of the user's CHUMBY™ device into the Web page and selects “OK” (stage 1910). An association is then created between the user's CHUMBY™ device and the applicable account within the system database 712.
  • In one embodiment user accounts are configured to be capable of hosting and moderating sub-accounts.
  • Disabling a CHUMBY™ Device
  • Referring now to FIG. 20, a flowchart is provided of exemplary Web-based interaction occurring between a user and the service provider 106 with regard to disabling a CHUMBY™ device that has been previously associated with the user's account. As shown, the user logs in to the account via a Web browser 122 (stage 2002) and selects a “Disable CHUMBY™ device” tab or the equivalent (stage 2004). The user then selects the CHUMBY™ device to be disabled from a list based upon either the device's serial number or description (stage 2006). Next the user is prompted to confirm the selection (stage 2010), and if so all references to the disabled CHUMBY™ device are removed from the directory maintained within the system database 712 (stage 2014). The process is then completed whether or not the selection is confirmed (stage 2020), at which point the service provider 106 no longer responds to requests from the CHUMBY™ device which has been disabled.
  • Mirroring a CHUMBY™ Device
  • FIG. 21 is a flowchart which represents exemplary Web-based interaction occurring between a user and the service provider 106 in connection with “mirroring” CHUMBY™ devices; that is, enabling one CHUMBY™ device to utilize the widget set and configuration of another CHUMBY™ device. In one embodiment once a given CHUMBY™ device (i.e., the “slave device”) has been mirrored to another CHUMBY™ device (i.e., the “master device”), widget-related changes made to the master device are automatically reflected in the slave device. As shown in FIG. 21, the user logs in to the applicable account via a Web browser 122 (stage 2102) and selects a “Mirror this CHUMBY™ device” tab or the equivalent (stage 2104). The user then selects the CHUMBY™ device to be the “master” (stage 2108) and further selects the CHUMBY™ device to the “slave” (stage 2112). In certain embodiments the master CHUMBY™ device need not correspond to a physical device, but could instead constitute a “virtual” CHUMBY™ device defined within the system database 712. In this case changes made to the widget set or configuration of the virtual CHUMBY™ device would be mirrored by all of its slave CHUMBY™ devices. In certain embodiments the slave CHUMBY™ device need not correspond to a physical device, but could instead constitute a “virtual” CHUMBY™ device defined within the system database 712.
  • Widget Selection, Removal and Configuration
  • Attention is now directed to FIGS. 22-25, 37 and 38, which are a set of flowcharts representative of Web-based widget selection, removal and configuration processes contemplated by embodiments of the present invention. Screen shots of exemplary user interfaces presented by the Web browser 122 or, alternatively, the screen 320 of the applicable CHUMBY™ personal audiovisual device 102, which are used to facilitate certain of these processes are illustrated in FIG. 26.
  • Overview of Widget Management Process
  • Turning now to FIG. 22, a top-level flowchart 2200 is provided of exemplary Web-based interaction occurring between a device user and the service provider 106 with regard to adding, removing and configuring widget profiles relative to the user's CHUMBY™ device. Alternatively, this interaction between a device user and the service provider 106 may be effected through user interface screens presented by the user's CHUMBY™ device in lieu of the Web browser 122. Although a user may have the impression that a CHUMBY™ device itself is being configured through the process of FIG. 22, in the exemplary embodiment a profile currently assigned to the user's CHUMBY™ device is instead configured.
  • As shown in FIG. 22, the user logs in to the user's account maintained with the service provider 106 via a Web browser 122 (stage 2202) and proceeds to the user's “home page” or the equivalent (stage 2204). From this home page the user selects a “Set Up” device tab or the like (stage 2208) and the Web browser 122 presents a corresponding “Set Up” page (stage 2210). The user then selects the CHUMBY™ device profile to be configured from a list based upon either the device's serial number or description (stage 2212). The current configuration for the selected device profile is then retrieved from the system database 712 and loaded into the device (stage 2216). Once this has occurred the user selects an action to be performed, as is illustrated by FIG. 26A (stage 2220). Such actions may include, for example, adding, deleting or editing widget profiles. If the user opts to add widget profiles (stage 2224), then the Web browser 122 displays an “Add Widgets Page” through which widget profiles may be added to the current configuration of the applicable CHUMBY™ device in the manner described below with reference to FIG. 23 (stage 2228). If the user instead chooses to delete widget profiles from such current configuration (stage 2232), then a “Delete Widgets Page” is presented through which the deletion operation may be completed consistent with the approach described below with reference to FIG. 24 (stage 2236). Alternatively, the user may select another CHUMBY™ device profile to configure (stage 2240), or simply exit and return to the user's home page (stage 2244).
  • Turning now to FIG. 37, an alternate top-level flowchart 3700 is provided of exemplary Web-based interaction occurring between a device user and the service provider 106 with regard to adding, removing and configuring widget profiles relative to the user's CHUMBY™ device. Although a user may have the impression that a CHUMBY™ device itself is being configured through the process of FIG. 37, in the exemplary embodiment a profile currently assigned to the user's CHUMBY™ device is instead configured.
  • As shown in FIG. 37, the user logs in to the user's account maintained with the service provider 106 via a Web browser 122 (stage 3702) and proceeds to the user's “MY CHUMBY™ page” or the equivalent, as is illustrated by FIG. 39A (stage 3704). From this MY CHUMBY™ page the user optionally selects the CHUMBY™ device to be configured from a list or the like, as is illustrated by FIG. 39B (stage 3706) and the Web browser 122 loads the currently configured widget channel into the current page (stage 3708). The user then optionally selects the CHUMBY™ widget channel to be configured from a list or the like, as is illustrated by FIG. 39C (stage 3710). The current channel configuration for the selected CHUMBY™ device is then updated in the system database 712, loaded into the current page (stage 3712) and loaded by the currently selected CHUMBY™ device (stage 3713). At any point the user may select the “Edit Channel” option (stage 3714), following which a “Edit Channel Page” is presented, as is illustrated by FIG. 39D (stage 3716), with the widget configuration for the selected channel is loaded into the page (stage 3718). Once this has occurred, the user may select an action to be performed (stage 3720). Such actions may include, for example, changing, renaming, deleting or creating new widget channels; adding widgets to, removing widgets from, changing playback order of widgets within or configuring widgets within the selected channel. If the user opts to perform a widget action (stage 3724), then the widget instance for the affected widget and/or the configuration for the selected channel within the system database 712 are updated, which subsequently effects a corresponding update to the local copy of the channel configuration of all CHUMBY™ devices currently “playing” the selected channel (stage 3728). If the user opts to perform a channel action (stage 3732), then the configuration for the selected channel within the system database 712 is updated which subsequently effects a corresponding update to the local copy of the channel configuration of all CHUMBY™ devices currently “playing” the selected channel (stage 3734). Alternatively, the user may select another channel to configure (stage 3740), or navigate to another page (stages 3742, 3744).
  • Adding Widgets
  • FIG. 23 is a flowchart 2300 representative of exemplary Web-based interaction occurring between a device user and the service provider 106 with respect to the addition of widgets to the current configuration of the user's CHUMBY™ device. Alternatively, this interaction between a device user and the service provider 106 may be effected through user interface screens presented by the user's CHUMBY™ device in lieu of the Web browser 122. In one embodiment the user is provided with the opportunity to choose, through an appropriate category selection page (see, e.g., FIG. 26B) presented by a Web browser 122, among various widget categories retrieved from the categories table of the system database 712 (stage 2302). After selecting a widget category (stage 2304), both the widgets included within the selected category and the current widget configuration of the applicable CHUMBY™ device are presented to the user (stage 2308). The user then selects an action to perform (stage 2312) including, for example, exiting the widget addition process (stage 2316) or navigating the list of widgets presented for the selected category (stage 2320). If the latter action is selected (see, e.g., FIGS. 26C-26D), the user then selects a widget to be added to the current configuration (e.g., by selecting a corresponding icon) and the service provider 106 constructs an instance of the selected widget (stage 2324). At this point the user may also opt to add yet more widgets to the current configuration (stage 2328). Once the user has indicated that no additional widgets are to be added, a widget configuration phase (stage 2332) may be entered (see, e.g., FIG. 26E). If the user declines to select a widget while navigating the list of widgets presented for a selected category during stage 2320, a new category of widgets may be selected (stage 2340).
  • If the user decides to exit the process of adding widgets to the current configuration, the user may perform one of several actions, including, but not limited to: select another CHUMBY™ device to configure; navigate to another page on the CHUMBY™ site; log out from the CHUMBY™ site; or close the applicable browser window (stage 2316). If the user instead chooses to save the current widget configuration for the applicable CHUMBY™ device (stage 2350), the user selects a “Submit”, “Commit”, “Ok” or similar button to cause any changes made to be recorded in the system database 712 (stage 2354). After either saving the current widget configuration or electing to exit the process, the user may be directed to a predefined page (stage 2360).
  • FIG. 38 is an alternate flowchart 3800 representative of exemplary Web-based interaction occurring between a device user and the service provider 106 with respect to the addition of widgets to a channel configuration. In one embodiment the user is provided with the opportunity to choose, through an appropriate category selection list on the EDIT CHANNEL Page (see, e.g., FIG. 39D) presented by a Web browser 122, among various widget categories retrieved from the categories table of the system database 712 (stage 3802). After selecting a widget category (stage 3804), the widgets included within the selected category are presented to the user, as is illustrated by FIG. 39F (stage 3808). The user then selects an action to perform including, for example, navigating to another page (stage 3832) or navigating the list of widgets presented for the selected category (stage 3812). If the latter action is selected (see, e.g., FIG. 39G), the user then selects a widget to be added to the current configuration by selecting a widget from the “widgets” list (stage 3816), which causes the selected widget to be displayed (stage 3820), and then selecting the ADD TO CHANNEL button (stage 3824), which causes the service provider 106 to construct an instance of the selected widget and update the configuration for the current channel in the system database 712 (stage 3828). At this point the user may also opt to iteratively navigate the widget list (stage 3812), select widgets (stage 3816) and add more widgets to the current configuration (stage 3824). At any time in this process, other widget and/or channel operations may be selected and/or executed by the user (stage 3840), including, but not limited to: configuring a widget instance (see, e.g., FIG. 39H), a widget deletion, altering widget playback ordering within the channel, renaming the current channel, deleting the current channel, creating a new channel and/or selecting a new category of widgets may be selected (stage 3850).
  • If the user decides to exit the process of adding widgets to the current configuration, the user may perform one of several actions, including, but not limited to: select another channel to configure, as is illustrated by FIG. 39E; navigate to another page on the CHUMBY™ site (stage 3832); log out from the CHUMBY™ site; or close the applicable browser window.
  • Widget Removal
  • Referring now to FIG. 24, a flowchart 2400 is provided which is representative of exemplary Web-based interaction occurring between a device user and the service provider 106 in connection with the removal of widgets from the current configuration of the user's CHUMBY™ device. Alternatively, this interaction between a device user and the service provider 106 may be effected through user interface screens presented by the user's CHUMBY™ device in lieu of the Web browser 122. Upon being presented with the “EDIT CHANNEL Page”, as is illustrated by FIG. 39D (stage 2402), the user may elect to either de-activate a selected widget (stage 2406), delete (or remove) a selected widget (stage 2410), or select some other widget, channel and/or page navigation operation (stage 2414). If widget de-activation is chosen, the user is prompted to confirm the choice (stage 2418). Once such confirmation has been provided the widget is marked as “inactive” on the page currently being rendered by the Web browser 122 (stage 2420). In addition, the widget instance configuration for the selected channel is updated within the system database 712 (stage 2424) and any CHUMBY™ devices currently displaying the selected channel are updated. Similarly, if it is instead chosen to delete the selected widget, the user is optionally prompted to confirm the choice (stage 2438). Once the widget is deleted or after optionally required confirmation has been provided, the widget is removed from the page currently being rendered by the Web browser 122 (stage 2440), the widget instance is “deleted” from the channel configuration in the system database 712 (stage 2424) and any CHUMBY™ devices currently displaying the selected channel are updated. If confirmation to de-activate or delete the selected widget is required, but not provided (stages 2418 and 2438), the operation is aborted.
  • Referring now to FIG. 41, an alternate flowchart 4100 is provided which is representative of exemplary interaction occurring, via the CHUMBY™ device of a user, between such user and the service provider 106 in connection with the removal of widgets from the current configuration of the user's CHUMBY™ device. With a widget displayed on the screen 320 of the CHUMBY™ device (stage 4102), the user performs the gesture which selects the Control Panel (stage 4104). Upon being presented with the Control Panel, as is illustrated by FIG. 40A (stage 4108), which displays the avatar for the current widget (stage 4112), the user may optionally use the widget navigation controls to singly or iteratively select a new current widget (stage 4116), in which case the new current widget is loaded (stage 4120) and its avatar displayed (stage 4112). The user may then elect to delete (or remove) the current widget by selecting DELETE (stage 4124). If widget deletion is chosen, the user is prompted to confirm the choice, as is illustrated by FIG. 40B (stage 4128). If the user confirms the deletion (stage 4132), the widget instance is deleted from the channel on the CHUMBY™ device and the widget instance is “deleted” from the channel configuration in the system database 712 (stage 4136). If confirmation is not provided, the operation is aborted. At this point, the delete confirmation screen is exited (stage 4140) and the Control Panel is displayed. The user has the option to select HIDE CONTROL PANEL (stage 4144), which exits the control panel and resumes normal widget play.
  • Widget Configuration
  • FIG. 25 is a flowchart 2500 depicting an exemplary set of operations involved in configuring parameters specific to of one or more widgets currently associated with a given CHUMBY™ device. The process is initiated by accessing the configuration of a selected widget instance maintained within the system database (stage 2502). An appropriate user interface through which the existing configuration of the selected widget may be edited is then generated based upon such existing configuration (stage 2504). This may involve, for example, establishing various inter-field dependencies based upon the existing configuration (stage 2508). Once the user interface has been generated it is presented to the user via a Web browser 122 in order to enable desired changes to the configuration to be made, as is illustrated by FIG. 39H (stage 2512). If a user elects to edit one or more fields presented by the interface (2516), the user interface defining the widget configuration is correspondingly changed (stage 2520). If a user elects to not edit any of these fields, the user is given the option of selecting a “default configuration” (stage 2524). To the extent this option is selected, all fields are reset to default values (stage 2528); otherwise, the user is given the option to exit the process or return to stage 2516 (stage 2540). When the process is exited, the user is given the option of saving the edited version of the configuration in the system database 712 (stage 2544). If this option is selected, the current widget configuration is saved to the database 712 (stage 2550). The “Edit Channel Page” is then presented to the user, irrespective of whether or not the user elected to save the widget configuration (stage 2560).
  • In an exemplary embodiment the service provider 106 populates a corresponding widget and parameters tables within the system database in accordance with the user's parameter selections. In this regard the widget table may include an XML-based “param_desc_×ml” field containing instructions enabling the construction of associated records in parameters table. For example, for a “clock” widget the XML-based instructions could indicate that a time zone should be a valid parameter, and could also be utilized to create appropriate records in the parameters table.
  • Distribution of Electronic Greetings Among CHUMBY™ Devices
  • Users of CHUMBY™ devices will have the ability to send electronic greeting cards in the form of rich Flash animations. Upon visiting a predefined web site (e.g., ‘http://greetings.chumby.com’) and optionally being authenticated by presenting appropriate credentials, a user will be presented with a catalog of “CHUMBY™ Greetings”. In one embodiment access to certain “CHUMBY™ Greetings” may be dependent on membership status. Any authenticated user, irrespective of the number of registered CHUMBY™ devices, will have the permission to send CHUMBY™ Greetings to one or more arbitrary email addresses or, alternatively, one or more users registered with the CHUMBY™ network. If a visitor to the web site is aware of the globally and temporally unique email address of an existing CHUMBY™ device, the account name in which the CHUMBY™ device is registered, or other means of identifying individual CHUMBY™ devices, they may specify CHUMBY™ Greetings to be forwarded directly to such a device using the existing widget transfer infrastructure of the service provider 106. Upon receipt at the CHUMBY™ device, the transferred CHUMBY™ Greetings will be added to the channel or profile in which the recipient has designated for receipt of widgets or other delivered content. Once the widget has been delivered to a channel or profile, the recipient will have the option of accepting or rejecting the delivered content. In the event that a user accepts the CHUMBY™, the CHUMBY™ Greeting will be added to the recipient's widget slideshow rotation in accordance with the applicable profile of the device. In one example, a visitor to the web site may choose to assign a certain level of priority to a CHUMBY™ Greeting such that it may be displayed by the recipient CHUMBY™ device immediately following actuation of the device's alarm function. Alternatively, a priority assigned to a CHUMBY™ Greeting may define the placement of the CHUMBY™ Greeting in the recipient's widget rotation.
  • CHUMBY™ Greetings sent to email addresses that are not bound to physical CHUMBY™ devices will be forwarded as an SMTP email message. This message will originate from, for example, “greetings@chumby.com” (or a user supplied email address), and will contain a URL or hyperlink pointing to a temporary web page hosting the Flash movie comprising the CHUMBY™ Greeting in addition to an optional user-defined message. Authenticated users will have the ability to select one or more peers from their CHUMBY™ “Buddy List” as recipients of a preconfigured CHUMBY™ Greeting. In one embodiment of CHUMBY™ Greetings, a subscription may be required for access to certain features such as CHUMBY™ Greetings. In such an embodiment, users subscribing to the CHUMBY™ Network will have access to “premium” CHUMBY™ Greetings. In one embodiment, CHUMBY™ may wish to elect a “pay-per-view” model where the use of a “premium” CHUMBY™ Greetings may be charged as a micro-transaction. In one embodiment, CHUMBY™ Greeting recipients that are not bound to physical CHUMBY™ devices will be presented with an option to forward the CHUMBY™ Greeting to alternate email addresses or physical CHUMBY™ devices.
  • Content Transfer from Personal Communication Device to CHUMBY™ Device
  • In one embodiment the infrastructure of the CHUMBY™ service provider will support a service capable of receiving an email message from a mobile communication device (e.g., a cellular phone) containing text and/or an image. The email would be addressed to a given user (e.g., ‘user’@chumby.com) within the “chumby” domain; alternatively, a special email domain may be created for content from mobile devices in order to facilitate its detection (e.g., ‘user’@chumby-mobile.com).
  • Referring to the process flow diagram 3400 of FIG. 34, a text/image processing service within the infrastructure of the CHUMBY™ service provider 106 is configured to parse e-mail messages from mobile devices and extract the relevant content. As shown, the e-mail messages are provided to a CHUMBY™ e-mail gateway 3410 by provider service gateway 3412. The text/image processing service makes the content available to the appropriate widget (mobile text or mobile imaging) and optionally caches that content in a service in the infrastructure of the CHUMBY™ service provider 106. In the embodiment of FIG. 3400, such infrastructure includes a text server 3420 and an image server 3430 respectively operative to process textual and image information extracted from incoming e-mail messages by the CHUMBY™ e-mail gateway 3410. If the recipient user has the appropriate text or imaging widget configured to display on their CHUMBY™ device 102, then the subject text or image will be retrieved and displayed when the widget becomes active (after all previously queued text or images have been retrieved). If such a widget is not currently configured to run on the recipient user's CHUMBY™ device 102, the content will remain stored within the appropriate service's cache until such time that the widget is configured to run or a cache aging utility deletes it as unreferenced content.
  • FIG. 35 is a process flow diagram 3500 illustrating an alternate implementation of an image processing service for CHUMBY™ devices 102. As shown, in the implementation of FIG. 35 the image processing service may not be performed by the CHUMBY™ service provider 106, but is instead handled by an imaging service provider 3502. In particular, e-mail messages originating at mobile devices are provided to an imaging service e-mail gateway 3510 by provider service gateway 3512. The service provider 3502 also operates an image server 3520 that makes the extracted image content available to the appropriate image widget executing on the applicable CHUMBY™ device 102.
  • Other Exemplary Operative Modes and Environments
  • “Hotel” CHUMBY™ Device
  • Although it is contemplated that CHUMBY™ devices will often be utilized within private residential environments, in certain cases “generic” CHUMBY™ devices may be deployed in public or quasi-public spaces such as hotel lobbies, hotel rooms, or airports. In such cases a user would be permitted to “log-in” to a generic or multi-user CHUMBY™ device (i.e., a CHUMBY™ device not associated with a single user). Such log-in may be effected by the entry of a username/password combination into the generic CHUMBY™ device or through other conventional means of user identification (e.g., using “RFID” tags, USB Flash Storage devices, SIM cards or biometric techniques). Once entered, the log-in information is communicated from the generic CHUMBY™ device to the CHUMBY™ service provider. In response, the service provider sends a user-specific profile and related configuration information corresponding to the log-in information back to the generic CHUMBY™ device. In this way the interface of the generic CHUMBY™ device may be customized in accordance with the setting and preferences of multiple different users of the device. Once the power of the device is cycled or the device is otherwise rebooted, its behavior will revert to that of the “generic” CHUMBY™ device.
  • CHUMBY™ Channels
  • In certain embodiments profiles pertinent to various specialty interests or activities (e.g., sports, cooking) may be developed and maintained by the service provider 106 or other users of CHUMBY™ devices. Each such profile, or “channel”, could be subscribed to by interested users of CHUMBY™ devices. This may be considered a special case of mirroring to a “virtual” CHUMBY™ device as described above, but would further involve effort on the part of the “owners” of each channel to keep its widget set and other content updated. Channels could somewhat broadly focus upon a particular subject (e.g., recipes, football), or could be more specific in nature (e.g., vegetarian recipes, NFL football).
  • Pairing of CHUMBY™ Device and Wireless Handset
  • In addition to including Wi-Fi communication capabilities, in certain implementations CHUMBY™ devices may also be equipped with Bluetooth™ transceivers or the like to facilitate communication with similarly equipped wireless handsets, headsets, or other Bluetooth™-enabled devices. In such cases the CHUMBY™ device could execute a widget designed to use the Bluetooth™ transceiver to “pull” information from or alternately “push” information to the wireless handset via the Bluetooth™ link. Such an arrangement could be used to obtain information from or send information to the Bluetooth™ enabled device such as, for example, alarm settings, images, videos, calendar appointments, voice and other stored data (e.g., music, messages). In one embodiment, the CHUMBY™ device may be used as a Bluetooth enabled dialer and speakerphone accessory for mobile phones. In another embodiment, the CHUMBY™ device may communicate with portable Bluetooth™ enabled GPS devices and optionally render maps and navigation routes to the LCD 320.
  • Networked Home Entertainment Device
  • In certain embodiments a CHUMBY™ device may be capable of accessing a user's “home network” and identifying particular types of server infrastructure which may be present via multicast DNS, Universal Plug and Play, or other means. The CHUMBY™ device would then configure itself to act as a client to the detected server and participate in the network. Alternatively, the CHUMBY™ device could be configured to act as a peer to other devices connected to the home network. In one embodiment, the CHUMBY™ device may discover and connect to a media server running on the “home network” and stream audio and video feeds. In another embodiment, the CHUMBY™ device may discover and connect to a digital video recorder and provide scheduling and optionally stream audio and video data stored on the remote device. Some embodiments of the CHUMBY™ device may be equipped with an FM radio device that will allow the CHUMBY™ device to play audio from local FM radio stations.
  • The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the invention. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the invention. In other instances, well-known circuits and devices are shown in block diagram form in order to avoid unnecessary distraction from the underlying invention. Thus, the foregoing descriptions of specific embodiments of the present invention are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, obviously many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the following Claims and their equivalents define the scope of the invention.

Claims (38)

1. A portable information device comprising:
a frame structure;
communications circuitry;
a core electronics unit supported by the frame structure, the core electronics unit including memory in which are stored instructions for one or more computer programs received by the communications circuitry and executed by a processor;
a user interface in electrical communication with the core electronics unit, the user interface receiving user instructions pertinent to execution of the one or more computer programs; and
a flexible housing attached to the frame structure, the flexible housing at least partially defining a compartment containing the core electronics unit.
2. The portable information device of claim 1 further including resilient fill material interposed between the core electronics unit and the flexible housing.
3. The portable information device of claim 1 wherein the core electronics unit includes a display for the user interface and a supporting frame surrounding a periphery of the display.
4. The portable information device of claim 3 wherein the supporting frame is press-fit into the frame structure.
5. The portable information device of claim 1 further including a sensor arrangement disposed within the compartment, the sensor arrangement being responsive to deformation of the flexible housing.
6. The portable information device of claim 5 further including a daughtercard assembly electrically connected to the core electronics unit, the squeeze sensor arrangement including one or more electronic components mounted upon the daughtercard assembly.
7. The portable information device of claim 1 wherein the frame structure is constructed from a flexible material to which the flexible housing is sewn.
8. The portable information device of claim 3 wherein the display defines at least a portion of a front side of the portable information device and a rigid plate defines at least a portion of a rear side of the portable information device opposed to the front side.
9. The portable information device of claim 8 further including a daughtercard assembly attached to the rigid plate, the daughtercard assembly being electrically connected to the core electronics unit.
10. The portable information device of claim 5 wherein the processor is configured to control execution of the one or more computer programs based upon signals generated by the sensor arrangement.
11. The portable information device of claim 5 wherein the one or more computer programs are executed by the processor in a defined sequence, the processor being configured to advance through at least a portion of the sequence based upon signals generated by the sensor arrangement.
12. The portable information device of claim 1 wherein the communications circuitry comprises a wireless transceiver.
13. A portable information device comprising:
a core electronics unit including a main circuit board and a display, the core electronics unit including memory in which are stored instructions for one or more computer programs executed by a processor;
a flexible housing structure at least partially defining a compartment containing the core electronics unit and an opening within which is positioned the display; and
a resilient fill material interposed between the core electronics unit and the flexible housing.
14. The portable information device of claim 13 wherein the flexible housing structure includes a flexible frame member and flexible material attached to the frame member.
15. The portable information device of claim 14 wherein the flexible material is sewn to the flexible frame member.
16. The portable information device of claim 13 further including a wireless transceiver, the one or more computer programs being received by the wireless transceiver.
17. The portable information device of claim 13 further including at least one sensor disposed within the compartment.
18. The portable information device of claim 17 wherein the at least one sensor is responsive to deformation of the flexible housing, the resilient fill material flexing at least one element of the sensor arrangement in response to the deformation.
19. The portable information device of claim 13 further including a daughtercard assembly electrically connected to the core electronics unit.
20. The portable information device of claim 19 wherein at least one sensor is connected to the daughtercard assembly.
21. A method for assembling a portable information device, the method comprising:
providing a first electronics sub-assembly;
securing the first electronics sub-assembly using a flexible frame; and
attaching a flexible housing to the flexible frame such that the flexible housing at least partially defines a compartment surrounding the first electronics sub-assembly.
22. The method of claim 21 further including:
providing a second electronics sub-assembly; and
flexibly connecting the first electronics sub-assembly and the second electronics sub-assembly.
23. The method of claim 22 further including:
attaching the second electronics sub-assembly to a rigid plate; and
attaching the rigid plate to the flexible housing.
24. The method of claim 21 wherein the attaching comprises sewing.
25. The method of claim 21 further including creating the flexible frame by bending a rubber-like material into a desired shape.
26. The method of claim 21 further including:
defining an opening in the flexible housing;
attaching a plastic lip to a periphery of the opening.
27. The method of claim 26 further including gluing the plastic lip to the first electronics sub-assembly.
28. The method of claim 21 further including placing thermally conductive fill material into the compartment.
29. The method of claim 21 further including:
attaching a display to the first electronics sub-assembly; and
placing thermally conductive material between the first electronics sub-assembly and the display such that heat is conducted from the first electronics sub-assembly to the display.
30. The method of claim 22 further including mounting a mechanical switch sensor on the second electronics sub-assembly.
31. The method of claim 21 further including attaching a bend-sensitive sensor to the flexible housing.
32. The method of claim 21 further including attaching a force sensor to the flexible housing.
33. The method of claim 21 further including attaching an accelerometer to the flexible housing.
34. A method for assembling a portable information device, the method comprising:
forming a plastic frame by bending a piece of plastic material into a desired shape;
attaching a first electronics sub-assembly to the plastic frame, the first electronics sub-assembly including a processor and a display; and
sewing a flexible material to the plastic frame.
35. The method of claim 34 further including:
providing a second electronics sub-assembly; and
flexibly connecting the first electronics sub-assembly and the second electronics sub-assembly.
36. The method of claim 35 further including:
attaching the second electronics sub-assembly to a rigid plate; and
attaching the rigid plate to the flexible housing.
37. The method of claim 34 wherein the plastic frame is shaped such that the sewing results in creation of a compartment at least partially defined by the flexible housing, the compartment containing the first electronics sub-assembly.
38. The method of claim 37 further including placing fill material within the compartment.
US11/845,021 2006-08-24 2007-08-24 Networked personal audiovisual device having flexible housing Abandoned US20080068519A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/845,018 US9654589B2 (en) 2006-08-24 2007-08-24 Configurable personal audiovisual device for use in application-sharing system
US11/845,021 US20080068519A1 (en) 2006-08-24 2007-08-24 Networked personal audiovisual device having flexible housing

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US82349106P 2006-08-24 2006-08-24
US82349606P 2006-08-24 2006-08-24
US82349306P 2006-08-24 2006-08-24
US80583006P 2006-09-05 2006-09-05
US86929706P 2006-12-08 2006-12-08
US94590007P 2007-06-22 2007-06-22
US11/845,021 US20080068519A1 (en) 2006-08-24 2007-08-24 Networked personal audiovisual device having flexible housing

Publications (1)

Publication Number Publication Date
US20080068519A1 true US20080068519A1 (en) 2008-03-20

Family

ID=38983773

Family Applications (4)

Application Number Title Priority Date Filing Date
US11/845,027 Active 2031-04-01 US8261256B1 (en) 2006-08-24 2007-08-24 System and method for automatically updating the software of a networked personal audiovisual device
US11/845,021 Abandoned US20080068519A1 (en) 2006-08-24 2007-08-24 Networked personal audiovisual device having flexible housing
US13/596,364 Active 2027-11-27 US8839224B2 (en) 2006-08-24 2012-08-28 System and method for automatically updating the software of a networked personal audiovisual device
US14/459,906 Active US9256420B2 (en) 2006-08-24 2014-08-14 System and method for automatically updating the software of a networked personal audiovisual device

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/845,027 Active 2031-04-01 US8261256B1 (en) 2006-08-24 2007-08-24 System and method for automatically updating the software of a networked personal audiovisual device

Family Applications After (2)

Application Number Title Priority Date Filing Date
US13/596,364 Active 2027-11-27 US8839224B2 (en) 2006-08-24 2012-08-28 System and method for automatically updating the software of a networked personal audiovisual device
US14/459,906 Active US9256420B2 (en) 2006-08-24 2014-08-14 System and method for automatically updating the software of a networked personal audiovisual device

Country Status (7)

Country Link
US (4) US8261256B1 (en)
EP (2) EP2082564A2 (en)
JP (1) JP2010503052A (en)
KR (1) KR20090082349A (en)
AU (1) AU2007288991A1 (en)
TW (2) TW200828032A (en)
WO (2) WO2008025017A2 (en)

Cited By (100)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070200830A1 (en) * 2006-02-28 2007-08-30 Nintendo Co., Ltd. Input device using touch panel
US20090109283A1 (en) * 2007-10-26 2009-04-30 Joshua Lynn Scott Integrated storage for industrial inspection handset
US20090157792A1 (en) * 2007-12-13 2009-06-18 Trevor Fiatal Content delivery to a mobile device from a content service
US20100030901A1 (en) * 2008-07-29 2010-02-04 Bryan Severt Hallberg Methods and Systems for Browser Widgets
US20110185279A1 (en) * 2010-01-22 2011-07-28 Stephen Ingkavet Methods and systems for requesting and delivering melody messages
US20110201304A1 (en) * 2004-10-20 2011-08-18 Jay Sutaria System and method for tracking billing events in a mobile wireless network for a network operator
US20110207436A1 (en) * 2005-08-01 2011-08-25 Van Gent Robert Paul Targeted notification of content availability to a mobile device
US8166164B1 (en) 2010-11-01 2012-04-24 Seven Networks, Inc. Application and network-based long poll request detection and cacheability assessment therefor
US20120131095A1 (en) * 2010-11-22 2012-05-24 Michael Luna Optimization of resource polling intervals to satisfy mobile device requests
US20120131184A1 (en) * 2010-11-22 2012-05-24 Michael Luna Aligning data transfer to optimize connections established for transmission over a wireless network
US8190701B2 (en) 2010-11-01 2012-05-29 Seven Networks, Inc. Cache defeat detection and caching of content addressed by identifiers intended to defeat cache
US20120290940A1 (en) * 2011-05-12 2012-11-15 Google Inc. Data Model Generation Based on User Interface Specification
US8316098B2 (en) 2011-04-19 2012-11-20 Seven Networks Inc. Social caching for device resource sharing and management
US8326985B2 (en) 2010-11-01 2012-12-04 Seven Networks, Inc. Distributed management of keep-alive message signaling for mobile network resource conservation and optimization
US8364181B2 (en) 2007-12-10 2013-01-29 Seven Networks, Inc. Electronic-mail filtering for mobile devices
KR101227769B1 (en) 2012-02-28 2013-01-30 세븐 네트워크스, 아이엔씨. Mobile network background traffic data management with optimized polling intervals
US8412675B2 (en) 2005-08-01 2013-04-02 Seven Networks, Inc. Context aware data presentation
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
US20130173698A1 (en) * 2011-12-30 2013-07-04 Ramandeep Sethi Dynamic Content Adaptation
US8484314B2 (en) 2010-11-01 2013-07-09 Seven Networks, Inc. Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
US8494510B2 (en) 2008-06-26 2013-07-23 Seven Networks, Inc. Provisioning applications for a mobile device
US20130196646A1 (en) * 2012-01-26 2013-08-01 Samsung Electronics Co., Ltd Apparatus and method for exchanging information on device in communication between devices
US8549587B2 (en) 2002-01-08 2013-10-01 Seven Networks, Inc. Secure end-to-end transport through intermediary nodes
US8561086B2 (en) 2005-03-14 2013-10-15 Seven Networks, Inc. System and method for executing commands that are non-native to the native environment of a mobile device
US8621075B2 (en) 2011-04-27 2013-12-31 Seven Metworks, Inc. Detecting and preserving state for satisfying application requests in a distributed proxy and cache system
US8693494B2 (en) 2007-06-01 2014-04-08 Seven Networks, Inc. Polling
US8700728B2 (en) 2010-11-01 2014-04-15 Seven Networks, Inc. Cache defeat detection and caching of content addressed by identifiers intended to defeat cache
US8750123B1 (en) 2013-03-11 2014-06-10 Seven Networks, Inc. Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network
US8761756B2 (en) 2005-06-21 2014-06-24 Seven Networks International Oy Maintaining an IP connection in a mobile network
US8775631B2 (en) 2012-07-13 2014-07-08 Seven Networks, Inc. Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications
US8774844B2 (en) 2007-06-01 2014-07-08 Seven Networks, Inc. Integrated messaging
US8787947B2 (en) 2008-06-18 2014-07-22 Seven Networks, Inc. Application discovery on mobile devices
US8799410B2 (en) 2008-01-28 2014-08-05 Seven Networks, Inc. System and method of a relay server for managing communications and notification between a mobile device and a web access server
US8805334B2 (en) 2004-11-22 2014-08-12 Seven Networks, Inc. Maintaining mobile terminal information for secure communications
US8801643B2 (en) 2010-02-12 2014-08-12 Covidien Lp Compression garment assembly
US8812695B2 (en) 2012-04-09 2014-08-19 Seven Networks, Inc. Method and system for management of a virtual network connection without heartbeat messages
US20140245015A1 (en) * 2012-04-27 2014-08-28 Intralinks, Inc. Offline file access
US8832228B2 (en) 2011-04-27 2014-09-09 Seven Networks, Inc. System and method for making requests on behalf of a mobile device based on atomic processes for mobile network traffic relief
US8838783B2 (en) 2010-07-26 2014-09-16 Seven Networks, Inc. Distributed caching for resource and mobile network traffic management
US8843153B2 (en) 2010-11-01 2014-09-23 Seven Networks, Inc. Mobile traffic categorization and policy for network use optimization while preserving user experience
US8849902B2 (en) 2008-01-25 2014-09-30 Seven Networks, Inc. System for providing policy based content service in a mobile network
US8861354B2 (en) 2011-12-14 2014-10-14 Seven Networks, Inc. Hierarchies and categories for management and deployment of policies for distributed wireless traffic optimization
US8868753B2 (en) 2011-12-06 2014-10-21 Seven Networks, Inc. System of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation
US8873411B2 (en) 2004-12-03 2014-10-28 Seven Networks, Inc. Provisioning of e-mail settings for a mobile terminal
US8874761B2 (en) 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
US8886176B2 (en) 2010-07-26 2014-11-11 Seven Networks, Inc. Mobile application traffic optimization
US8909202B2 (en) 2012-01-05 2014-12-09 Seven Networks, Inc. Detection and management of user interactions with foreground applications on a mobile device in distributed caching
US8909759B2 (en) 2008-10-10 2014-12-09 Seven Networks, Inc. Bandwidth measurement
US8909192B2 (en) 2008-01-11 2014-12-09 Seven Networks, Inc. Mobile virtual network operator
US20140364034A1 (en) * 2013-06-06 2014-12-11 HLL Design, Inc. Collapsible plush pillow toy with sound trigger
US8918503B2 (en) 2011-12-06 2014-12-23 Seven Networks, Inc. Optimization of mobile traffic directed to private networks and operator configurability thereof
USRE45348E1 (en) 2004-10-20 2015-01-20 Seven Networks, Inc. Method and apparatus for intercepting events in a communication system
US8984581B2 (en) 2011-07-27 2015-03-17 Seven Networks, Inc. Monitoring mobile application activities for malicious traffic on a mobile device
US9002828B2 (en) 2007-12-13 2015-04-07 Seven Networks, Inc. Predictive content delivery
US9009250B2 (en) 2011-12-07 2015-04-14 Seven Networks, Inc. Flexible and dynamic integration schemas of a traffic management system with various network operators for network traffic alleviation
US9021021B2 (en) 2011-12-14 2015-04-28 Seven Networks, Inc. Mobile network reporting and usage analytics system and method aggregated using a distributed traffic optimization system
US9021048B2 (en) 2010-11-01 2015-04-28 Seven Networks, Inc. Caching adapted for mobile application behavior and network conditions
US9043433B2 (en) 2010-07-26 2015-05-26 Seven Networks, Inc. Mobile network traffic coordination across multiple applications
US9055102B2 (en) 2006-02-27 2015-06-09 Seven Networks, Inc. Location-based operations and messaging
US9060032B2 (en) 2010-11-01 2015-06-16 Seven Networks, Inc. Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic
US9065765B2 (en) 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
US9077630B2 (en) 2010-07-26 2015-07-07 Seven Networks, Inc. Distributed implementation of dynamic wireless traffic policy
US9161258B2 (en) 2012-10-24 2015-10-13 Seven Networks, Llc Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion
US9173128B2 (en) 2011-12-07 2015-10-27 Seven Networks, Llc Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol
US9203864B2 (en) 2012-02-02 2015-12-01 Seven Networks, Llc Dynamic categorization of applications for network access in a mobile network
US9241314B2 (en) 2013-01-23 2016-01-19 Seven Networks, Llc Mobile device with application or context aware fast dormancy
US9251193B2 (en) 2003-01-08 2016-02-02 Seven Networks, Llc Extending user relationships
US9307493B2 (en) 2012-12-20 2016-04-05 Seven Networks, Llc Systems and methods for application management of mobile device radio state promotion and demotion
US9326189B2 (en) 2012-02-03 2016-04-26 Seven Networks, Llc User as an end point for profiling and optimizing the delivery of content and data in a wireless network
US9325662B2 (en) 2011-01-07 2016-04-26 Seven Networks, Llc System and method for reduction of mobile network traffic used for domain name system (DNS) queries
US9330196B2 (en) 2010-11-01 2016-05-03 Seven Networks, Llc Wireless traffic management system cache optimization using http headers
US9433532B2 (en) 2008-09-30 2016-09-06 Covidien Lp Tubeless compression device
US9547770B2 (en) 2012-03-14 2017-01-17 Intralinks, Inc. System and method for managing collaboration in a networked secure exchange environment
US9596227B2 (en) 2012-04-27 2017-03-14 Intralinks, Inc. Computerized method and system for managing an email input facility in a networked secure collaborative exchange environment
US20170092227A1 (en) * 2015-09-25 2017-03-30 Fresenius Medical Care Holdings, Inc. Automated Display Dimness Control for a Medical Device
US9613190B2 (en) 2014-04-23 2017-04-04 Intralinks, Inc. Systems and methods of secure data exchange
US9654450B2 (en) 2012-04-27 2017-05-16 Synchronoss Technologies, Inc. Computerized method and system for managing secure content sharing in a networked secure collaborative exchange environment with customer managed keys
WO2017143281A1 (en) * 2016-02-17 2017-08-24 Estimote, Inc. System and method for providing content using beacon systems
US9826356B2 (en) 2015-09-02 2017-11-21 Estimote Polska Sp. Z O. O. Systems and methods for object tracking with wireless beacons
US9826351B2 (en) 2015-09-02 2017-11-21 Estimote Polska Sp. Z O. O. System and method for beacon fleet management
US9832095B2 (en) 2011-12-14 2017-11-28 Seven Networks, Llc Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic
US9866996B1 (en) 2016-07-07 2018-01-09 Estimote Polska Sp. Z O. O. Method and system for content delivery with a beacon
US9867009B2 (en) 2016-03-22 2018-01-09 Estimote Polska Sp. Z O. O. System and method for multi-beacon interaction and management
EP3299927A1 (en) * 2011-09-30 2018-03-28 Apple Inc. Flexible electronic devices
US9955297B2 (en) 2013-08-19 2018-04-24 Estimote Polska Sp. Z O. O. Systems and methods for object tracking using wireless beacons
US9998863B2 (en) 2013-08-19 2018-06-12 Estimote Polska Sp. Z O. O. System and method for providing content using beacon systems
US10033702B2 (en) 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
WO2018170495A1 (en) * 2017-03-17 2018-09-20 VICIS, Inc. Removable communications module pocket
US10136250B2 (en) 2015-09-02 2018-11-20 Estimote Polska Sp. Z O. O. System and method for lower power data routing
US10263899B2 (en) 2012-04-10 2019-04-16 Seven Networks, Llc Enhanced customer service for mobile carriers using real-time and historical mobile application and traffic or optimization data associated with mobile devices in a mobile network
US10346937B2 (en) 2013-11-14 2019-07-09 Intralinks, Inc. Litigation support in cloud-hosted file sharing and collaboration
US10356095B2 (en) 2012-04-27 2019-07-16 Intralinks, Inc. Email effectivity facilty in a networked secure collaborative exchange environment
US10523685B1 (en) 2018-08-22 2019-12-31 Estimote Polska Sp z o.o. System and method for verifying device security
US10852441B2 (en) 2018-08-24 2020-12-01 Estimote Polska Sp z o.o. Method and system for asset management
US10873357B2 (en) 2017-05-02 2020-12-22 Deere & Company Smart attachment for a work vehicle
US11054804B2 (en) * 2015-06-15 2021-07-06 Comau S.P.A. Portable safety control device for industrial machines in particular robots
AU2020239726B1 (en) * 2020-03-10 2021-08-05 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11567654B2 (en) 2017-05-16 2023-01-31 Apple Inc. Devices, methods, and graphical user interfaces for accessing notifications
US11747969B1 (en) 2022-05-06 2023-09-05 Apple Inc. Devices, methods, and graphical user interfaces for updating a session region
US11842028B2 (en) 2022-05-06 2023-12-12 Apple Inc. Devices, methods, and graphical user interfaces for updating a session region

Families Citing this family (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130019019A1 (en) * 2004-11-15 2013-01-17 Peter Ar-Fu Lam Cloud servicing system configured for servicing smart phone or touch pad circuit applications and consumer programmable articles
US7779401B2 (en) * 2006-06-26 2010-08-17 Research In Motion Limited Method and system for generating a reverse binary patch for undoing a software update
US7797696B1 (en) * 2006-06-30 2010-09-14 American Megatrends, Inc. Dynamically updating a computer system and firmware image utilizing an option read only memory (OPROM) data structure
US7590835B1 (en) 2006-06-30 2009-09-15 American Megatrends, Inc. Dynamically updating a computer system firmware image
US9395968B1 (en) 2006-06-30 2016-07-19 American Megatrends, Inc. Uniquely identifying and validating computer system firmware
US8261256B1 (en) 2006-08-24 2012-09-04 Bby Solutions, Inc. System and method for automatically updating the software of a networked personal audiovisual device
US8521857B2 (en) 2006-08-24 2013-08-27 Bby Solutions, Inc. Systems and methods for widget rendering and sharing on a personal electronic device
US8726259B2 (en) * 2007-04-09 2014-05-13 Kyocera Corporation System and method for preserving device parameters during a FOTA upgrade
WO2009002804A2 (en) * 2007-06-22 2008-12-31 Chumby Industries, Inc. Systems and methods for device registration
US9069575B2 (en) 2008-03-25 2015-06-30 Qualcomm Incorporated Apparatus and methods for widget-related memory management
US9269059B2 (en) 2008-03-25 2016-02-23 Qualcomm Incorporated Apparatus and methods for transport optimization for widget content delivery
US9110685B2 (en) 2008-03-25 2015-08-18 Qualcomm, Incorporated Apparatus and methods for managing widgets in a wireless communication environment
US9747141B2 (en) 2008-03-25 2017-08-29 Qualcomm Incorporated Apparatus and methods for widget intercommunication in a wireless communication environment
US9600261B2 (en) * 2008-03-25 2017-03-21 Qualcomm Incorporated Apparatus and methods for widget update scheduling
TWI399692B (en) * 2008-07-25 2013-06-21 Hon Hai Prec Ind Co Ltd Electronic device, system and method for controlling volume thereof
TWI581184B (en) * 2008-09-25 2017-05-01 Zhu yu-hua Methods and systems for building multi - level toolsets
US8872646B2 (en) * 2008-10-08 2014-10-28 Dp Technologies, Inc. Method and system for waking up a device due to motion
KR101541543B1 (en) * 2008-12-18 2015-08-03 주식회사 알티캐스트 Method and System for providing widget service
KR101547960B1 (en) * 2008-12-30 2015-08-27 삼성전자주식회사 Broadcast reception device and method for providing a widget service thereof
US8686921B2 (en) 2008-12-31 2014-04-01 Intel Corporation Dynamic geometry management of virtual frame buffer for appendable logical displays
KR20100086677A (en) * 2009-01-23 2010-08-02 삼성전자주식회사 Method and apparatus for providing community widget
JP5342302B2 (en) * 2009-03-30 2013-11-13 株式会社日立ソリューションズ Firmware update system, firmware distribution server, and program
KR101606816B1 (en) * 2009-10-19 2016-03-28 삼성전자 주식회사 Display apparatus, system and control method for application programs thereof
KR101624137B1 (en) * 2009-11-18 2016-06-07 삼성전자주식회사 Method for updating display and mobile terminal using the same
KR20110068098A (en) * 2009-12-15 2011-06-22 삼성전자주식회사 Software upgrade apparatus and method of customer premise equipment
KR101642833B1 (en) * 2010-02-05 2016-07-26 삼성전자주식회사 clock embedded interface method, transceiver and display device using the method
KR20110092411A (en) * 2010-02-09 2011-08-18 삼성전자주식회사 Apparatus and method for providing extended network community service
US8739150B2 (en) * 2010-05-28 2014-05-27 Smartshift Gmbh Systems and methods for dynamically replacing code objects via conditional pattern templates
JP5449044B2 (en) * 2010-06-10 2014-03-19 シャープ株式会社 Server device, terminal device, and application control system
JP5054177B2 (en) * 2010-09-28 2012-10-24 楽天株式会社 Authentication system, authentication method, authentication device, information terminal, program, and information recording medium
KR101383691B1 (en) * 2010-10-25 2014-04-09 한국전자통신연구원 Apparatus and method for cooperatively updating firmware on wireless mesh network
KR101847073B1 (en) 2011-02-11 2018-05-29 삼성전자주식회사 Method and apparatus for managing content in processing device
JP2012226623A (en) * 2011-04-21 2012-11-15 Hidefumi Miyahara Terminal device, motion picture display system and program
US9524531B2 (en) * 2011-05-09 2016-12-20 Microsoft Technology Licensing, Llc Extensibility features for electronic communications
US20120317504A1 (en) * 2011-06-13 2012-12-13 Microsoft Corporation Automated user interface object transformation and code generation
US8756594B2 (en) * 2011-10-28 2014-06-17 Microsoft Corporation Reactive anti-tampering system for protected services in an enterprise computing system
CN102546753A (en) * 2011-12-08 2012-07-04 上海博泰悦臻电子设备制造有限公司 Method and system for mobile terminal to share vehicle side network
JP5961081B2 (en) * 2012-09-06 2016-08-02 キヤノン株式会社 Monitoring device, management system, firmware update method, and program
US8813061B2 (en) * 2012-10-17 2014-08-19 Movimento Group Module updating device
US8930936B2 (en) * 2012-11-06 2015-01-06 International Business Machines Corporation Loading remote binaries onto a write-protected device
CN105164281B (en) * 2013-01-29 2018-12-18 格柏科技国际有限公司 Leather processing automatic technology for mold cutting operation
KR101992680B1 (en) * 2013-02-05 2019-06-25 휴렛-팩커드 디벨롭먼트 컴퍼니, 엘.피. Image forming apparatus, tracking apparatus, managing apparatus and method for updating firmware of image forming apparatus
US10613914B2 (en) 2013-04-01 2020-04-07 Oracle International Corporation Orchestration service for a distributed computing system
CN105408830A (en) * 2013-05-15 2016-03-16 塔科图特科有限责任公司 Enabling arrangement for an electronic device with housing-integrated functionalities and method therefor
USD768144S1 (en) * 2014-01-03 2016-10-04 Samsung Electronics Co., Ltd. Display screen or portion thereof with graphical user interface
USD767606S1 (en) * 2014-02-11 2016-09-27 Samsung Electronics Co., Ltd. Display screen or portion thereof with graphical user interface
USD765690S1 (en) * 2014-02-11 2016-09-06 Samsung Electronics Co., Ltd. Display screen or portion thereof with graphical user interface
KR101542987B1 (en) * 2014-04-25 2015-08-12 현대자동차 주식회사 Diagnostic system and method for vehicle terminal
KR20150129972A (en) * 2014-05-12 2015-11-23 에스케이플래닛 주식회사 Method for updating of firmware in beacon apparatus, beacon apparatus and system using the same
US9389973B2 (en) * 2014-05-30 2016-07-12 Oracle International Corporation Memory error propagation for faster error recovery
USD779517S1 (en) * 2014-09-11 2017-02-21 Shuttersong Incorporated Display screen or portion thereof with graphical user interface
USD779516S1 (en) * 2014-09-11 2017-02-21 Shuttersong Incorporated Display screen or portion thereof with graphical user interface
USD779515S1 (en) * 2014-09-11 2017-02-21 Shuttersong Incorporated Display screen or portion thereof with graphical user interface
TWI569604B (en) * 2015-01-21 2017-02-01 智邦科技股份有限公司 Network switch system and operating method thereof
US9706388B2 (en) 2015-08-26 2017-07-11 International Business Machines Corporation Wireless network identification
US11593342B2 (en) 2016-02-01 2023-02-28 Smartshift Technologies, Inc. Systems and methods for database orientation transformation
US10592228B2 (en) * 2016-02-12 2020-03-17 Microsoft Technology Licensing, Llc Stylus firmware updates
US9866905B1 (en) 2016-02-23 2018-01-09 CSC Holdings, LLC Set-top box reboot and polling tool
US10585655B2 (en) 2016-05-25 2020-03-10 Smartshift Technologies, Inc. Systems and methods for automated retrofitting of customized code objects
US11092446B2 (en) 2016-06-14 2021-08-17 Motional Ad Llc Route planning for an autonomous vehicle
US10126136B2 (en) 2016-06-14 2018-11-13 nuTonomy Inc. Route planning for an autonomous vehicle
US10309792B2 (en) 2016-06-14 2019-06-04 nuTonomy Inc. Route planning for an autonomous vehicle
EP3260255B1 (en) * 2016-06-24 2019-08-21 Zünd Systemtechnik Ag System for cutting
US10204011B1 (en) * 2016-06-30 2019-02-12 EMC IP Holding Company LLC Techniques for partially restarting a computing device in response to a configuration change
US10829116B2 (en) 2016-07-01 2020-11-10 nuTonomy Inc. Affecting functions of a vehicle based on function-related information about its environment
US10089103B2 (en) 2016-08-03 2018-10-02 Smartshift Technologies, Inc. Systems and methods for transformation of reporting schema
WO2018063260A1 (en) * 2016-09-29 2018-04-05 Intel IP Corporation Firmware update for internet of things devices
US10681513B2 (en) 2016-10-20 2020-06-09 nuTonomy Inc. Identifying a stopping place for an autonomous vehicle
US10857994B2 (en) 2016-10-20 2020-12-08 Motional Ad Llc Identifying a stopping place for an autonomous vehicle
US10473470B2 (en) 2016-10-20 2019-11-12 nuTonomy Inc. Identifying a stopping place for an autonomous vehicle
US10331129B2 (en) 2016-10-20 2019-06-25 nuTonomy Inc. Identifying a stopping place for an autonomous vehicle
US10404664B2 (en) * 2016-10-25 2019-09-03 Arm Ip Limited Apparatus and methods for increasing security at edge nodes
CN107147711B (en) * 2017-05-04 2020-03-13 浙江数链科技有限公司 Application service updating method and device
CN107436780B (en) * 2017-06-20 2021-05-28 武汉斗鱼网络科技有限公司 Method and device for updating Flash player and electronic equipment
US10496469B2 (en) 2017-07-25 2019-12-03 Aurora Labs Ltd. Orchestrator reporting of probability of downtime from machine learning process
US10534725B2 (en) 2017-07-25 2020-01-14 International Business Machines Corporation Computer system software/firmware and a processor unit with a security module
US10445694B2 (en) 2017-08-07 2019-10-15 Standard Cognition, Corp. Realtime inventory tracking using deep learning
US11250376B2 (en) 2017-08-07 2022-02-15 Standard Cognition, Corp Product correlation analysis using deep learning
US10650545B2 (en) 2017-08-07 2020-05-12 Standard Cognition, Corp. Systems and methods to check-in shoppers in a cashier-less store
US10474988B2 (en) 2017-08-07 2019-11-12 Standard Cognition, Corp. Predicting inventory events using foreground/background processing
US10474991B2 (en) 2017-08-07 2019-11-12 Standard Cognition, Corp. Deep learning-based store realograms
US10853965B2 (en) 2017-08-07 2020-12-01 Standard Cognition, Corp Directional impression analysis using deep learning
US11232687B2 (en) 2017-08-07 2022-01-25 Standard Cognition, Corp Deep learning-based shopper statuses in a cashier-less store
US11200692B2 (en) 2017-08-07 2021-12-14 Standard Cognition, Corp Systems and methods to check-in shoppers in a cashier-less store
US11023850B2 (en) 2017-08-07 2021-06-01 Standard Cognition, Corp. Realtime inventory location management using deep learning
CN107908307A (en) * 2017-11-09 2018-04-13 苏州佳世达光电有限公司 The false-touch prevention of mobile terminal and its touch-screen controls method, apparatus
US10740075B2 (en) 2018-02-06 2020-08-11 Smartshift Technologies, Inc. Systems and methods for code clustering analysis and transformation
US10698674B2 (en) 2018-02-06 2020-06-30 Smartshift Technologies, Inc. Systems and methods for entry point-based code analysis and transformation
US10528343B2 (en) 2018-02-06 2020-01-07 Smartshift Technologies, Inc. Systems and methods for code analysis heat map interfaces
AU2020201852A1 (en) * 2019-03-15 2020-10-01 Carrier Corporation Configuring firmware for a target device
US11232575B2 (en) 2019-04-18 2022-01-25 Standard Cognition, Corp Systems and methods for deep learning-based subject persistence
CN110460435B (en) * 2019-07-01 2021-01-01 创新先进技术有限公司 Data interaction method and device, server and electronic equipment
US10735189B2 (en) 2019-07-01 2020-08-04 Alibaba Group Holding Limited Data exchange for multi-party computation
DE102019127856A1 (en) * 2019-10-16 2021-04-22 Avl Software And Functions Gmbh Procedure for safely booting a control unit and control unit
US11301464B2 (en) * 2020-01-14 2022-04-12 Videoamp, Inc. Electronic multi-tenant data management system
US11361468B2 (en) 2020-06-26 2022-06-14 Standard Cognition, Corp. Systems and methods for automated recalibration of sensors for autonomous checkout
US11303853B2 (en) 2020-06-26 2022-04-12 Standard Cognition, Corp. Systems and methods for automated design of camera placement and cameras arrangements for autonomous checkout
CN113360316A (en) * 2021-06-01 2021-09-07 苏州震坤科技有限公司 Product serial number coding device, coding method and method for updating product serial number code
CN117289958A (en) * 2022-06-17 2023-12-26 英业达科技有限公司 Device and method for updating dependency library required by test program to perform device test

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5376038A (en) * 1994-01-18 1994-12-27 Toy Biz, Inc. Doll with programmable speech activated by pressure on particular parts of head and body
US5607054A (en) * 1995-03-14 1997-03-04 Port, Inc. Folio carrying case for a notebook computer
US6139394A (en) * 1999-11-24 2000-10-31 Maxim; John G. Stuffed animal figure with sound and illuminated face
US6142846A (en) * 1999-10-07 2000-11-07 Ojakaar; Linda Stuffed animal toy
US6160540A (en) * 1998-01-12 2000-12-12 Xerox Company Zoomorphic computer user interface
US6494762B1 (en) * 2000-03-31 2002-12-17 Matsushita Electrical Industrial Co., Ltd. Portable electronic subscription device and service

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4980833A (en) 1988-07-26 1990-12-25 The University Of Tennessee Research Corporation Airplane take-off monitor with learning feature
US5295089A (en) * 1992-05-28 1994-03-15 Emilio Ambasz Soft, foldable consumer electronic products
JPH08263438A (en) 1994-11-23 1996-10-11 Xerox Corp Distribution and use control system of digital work and access control method to digital work
US6560707B2 (en) 1995-11-06 2003-05-06 Xerox Corporation Multimedia coordination system
US5862511A (en) 1995-12-28 1999-01-19 Magellan Dis, Inc. Vehicle navigation system and method
US6237004B1 (en) 1998-02-24 2001-05-22 International Business Machines Corporation System and method for displaying data using graphical user interface control elements
US6499062B1 (en) 1998-12-17 2002-12-24 Koninklijke Philips Electronics N.V. Synchronizing property changes to enable multiple control options
JP2001265472A (en) * 2000-03-17 2001-09-28 Atr Adaptive Communications Res Lab Method for realizing user interface and computer readable recording medium with program for the same recorded
KR20030022876A (en) 2000-07-28 2003-03-17 아메리칸 캘카어 인코포레이티드 Technique for effective organization and communication of information
KR100352124B1 (en) 2000-08-07 2002-09-12 주식회사 맥시스템 Apparatus for Digital Device Connection
US7685183B2 (en) * 2000-09-01 2010-03-23 OP40, Inc System and method for synchronizing assets on multi-tiered networks
JP3659149B2 (en) 2000-09-12 2005-06-15 ヤマハ株式会社 Performance information conversion method, performance information conversion device, recording medium, and sound source device
US7913286B2 (en) 2000-10-20 2011-03-22 Ericsson Television, Inc. System and method for describing presentation and behavior information in an ITV application
US6832373B2 (en) * 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
JP3497834B2 (en) 2001-03-30 2004-02-16 株式会社東芝 Route repeater, USB communication system, USB communication control method
DE10126847A1 (en) 2001-06-01 2002-12-05 Siemens Ag Multimedia message handling method in send application or send-receive application in mobile radio apparatus, by transmitting reference to externally stored file
US8200988B2 (en) 2001-08-03 2012-06-12 Intel Corporation Firmware security key upgrade algorithm
WO2003021798A2 (en) 2001-09-04 2003-03-13 Soft2B Llc Browser-to-browser, dom-based, peer-to-peer communication with delta synchronization
US20040098715A1 (en) * 2002-08-30 2004-05-20 Parixit Aghera Over the air mobile device software management
US7072672B1 (en) * 2002-11-01 2006-07-04 Nokia Corporation Disposable mini-applications
US7007049B2 (en) 2002-11-18 2006-02-28 Innopath Software, Inc. Device memory management during electronic file updating
US7480907B1 (en) * 2003-01-09 2009-01-20 Hewlett-Packard Development Company, L.P. Mobile services network for update of firmware/software in mobile handsets
KR100513278B1 (en) * 2003-04-17 2005-09-09 삼성전자주식회사 System for supporting user interface and method thereof
DE10324143A1 (en) * 2003-05-26 2004-12-16 Uwe Christof Beyer Mobile information processing device for processing text and graphical data, comprises a flexible housing, circuitry, display and input means together with local wireless communications and a removable memory unit reader
US20050039134A1 (en) 2003-08-11 2005-02-17 Sony Corporation System and method for effectively implementing a dynamic user interface in an electronic network
US20130097302A9 (en) * 2003-10-01 2013-04-18 Robert Khedouri Audio visual player apparatus and system and method of content distribution using the same
US7549042B2 (en) 2003-12-16 2009-06-16 Microsoft Corporation Applying custom software image updates to non-volatile storage in a failsafe manner
US7876469B2 (en) * 2003-12-26 2011-01-25 Panasonic Corporation Image forming apparatus and updating method
US20050182715A1 (en) 2004-02-17 2005-08-18 Hideaki Kawahara Method and system for charging for repeated use of a digital content item
US10156959B2 (en) 2005-03-16 2018-12-18 Icontrol Networks, Inc. Cross-client sensor user interface in an integrated security network
US7546543B2 (en) 2004-06-25 2009-06-09 Apple Inc. Widget authoring and editing environment
US8566732B2 (en) 2004-06-25 2013-10-22 Apple Inc. Synchronization of widgets and dashboards
US7490295B2 (en) * 2004-06-25 2009-02-10 Apple Inc. Layer for accessing user interface elements
EP1645944B1 (en) 2004-10-05 2012-08-15 Sony France S.A. A content-management interface
JP2006191540A (en) * 2004-12-09 2006-07-20 Ntt Docomo Inc Service providing system, and portable terminal and control program of same
AU2006292506B2 (en) 2005-09-15 2010-04-22 Fourthwall Media, Inc Self-contained mini-applications system and method for digital television
US20070067738A1 (en) 2005-09-16 2007-03-22 Microsoft Corporation Extensible, filtered lists for mobile device user interface
US7558597B2 (en) 2005-09-19 2009-07-07 Silverbrook Research Pty Ltd. Retrieving a ringtone via a coded surface
US7730236B2 (en) 2005-09-30 2010-06-01 Mediatek Inc. Cellular phone and portable storage device using the same
KR100742363B1 (en) 2005-10-07 2007-07-25 엘지전자 주식회사 Mobile terminal for united management of alert
US20070101279A1 (en) 2005-10-27 2007-05-03 Chaudhri Imran A Selection of user interface elements for unified display in a display environment
US7707514B2 (en) 2005-11-18 2010-04-27 Apple Inc. Management of user interface elements in a display environment
US7667686B2 (en) 2006-02-01 2010-02-23 Memsic, Inc. Air-writing and motion sensing input for portable devices
US7685132B2 (en) 2006-03-15 2010-03-23 Mog, Inc Automatic meta-data sharing of existing media through social networking
KR20080001290A (en) 2006-06-29 2008-01-03 삼성전자주식회사 System, apparatus and method for providing mixtures of customizable function
US8869027B2 (en) 2006-08-04 2014-10-21 Apple Inc. Management and generation of dashboards
US8521857B2 (en) 2006-08-24 2013-08-27 Bby Solutions, Inc. Systems and methods for widget rendering and sharing on a personal electronic device
US9654589B2 (en) 2006-08-24 2017-05-16 Bby Solutions, Inc. Configurable personal audiovisual device for use in application-sharing system
US8261256B1 (en) 2006-08-24 2012-09-04 Bby Solutions, Inc. System and method for automatically updating the software of a networked personal audiovisual device
US7778792B2 (en) 2006-12-08 2010-08-17 Chumby Industries, Inc. Systems and methods for location, motion, and contact detection and tracking in a networked audiovisual device
KR100789738B1 (en) 2007-05-22 2008-01-03 주식회사 미니게이트 System for transmitting widget type idle-screen contents data of mobile terminal
US20090044144A1 (en) 2007-08-06 2009-02-12 Morris Robert P Methods And Apparatus For Sharing User Interface Widget Annotations
US20090049384A1 (en) 2007-08-13 2009-02-19 Frank Yau Computer desktop multimedia widget applications and methods

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5376038A (en) * 1994-01-18 1994-12-27 Toy Biz, Inc. Doll with programmable speech activated by pressure on particular parts of head and body
US5607054A (en) * 1995-03-14 1997-03-04 Port, Inc. Folio carrying case for a notebook computer
US6160540A (en) * 1998-01-12 2000-12-12 Xerox Company Zoomorphic computer user interface
US6142846A (en) * 1999-10-07 2000-11-07 Ojakaar; Linda Stuffed animal toy
US6139394A (en) * 1999-11-24 2000-10-31 Maxim; John G. Stuffed animal figure with sound and illuminated face
US6494762B1 (en) * 2000-03-31 2002-12-17 Matsushita Electrical Industrial Co., Ltd. Portable electronic subscription device and service

Cited By (170)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8549587B2 (en) 2002-01-08 2013-10-01 Seven Networks, Inc. Secure end-to-end transport through intermediary nodes
US8811952B2 (en) 2002-01-08 2014-08-19 Seven Networks, Inc. Mobile device power management in data synchronization over a mobile network with or without a trigger notification
US8989728B2 (en) 2002-01-08 2015-03-24 Seven Networks, Inc. Connection architecture for a mobile network
US9251193B2 (en) 2003-01-08 2016-02-02 Seven Networks, Llc Extending user relationships
USRE45348E1 (en) 2004-10-20 2015-01-20 Seven Networks, Inc. Method and apparatus for intercepting events in a communication system
US20110201304A1 (en) * 2004-10-20 2011-08-18 Jay Sutaria System and method for tracking billing events in a mobile wireless network for a network operator
US8831561B2 (en) 2004-10-20 2014-09-09 Seven Networks, Inc System and method for tracking billing events in a mobile wireless network for a network operator
US8805334B2 (en) 2004-11-22 2014-08-12 Seven Networks, Inc. Maintaining mobile terminal information for secure communications
US8873411B2 (en) 2004-12-03 2014-10-28 Seven Networks, Inc. Provisioning of e-mail settings for a mobile terminal
US8561086B2 (en) 2005-03-14 2013-10-15 Seven Networks, Inc. System and method for executing commands that are non-native to the native environment of a mobile device
US9047142B2 (en) 2005-03-14 2015-06-02 Seven Networks, Inc. Intelligent rendering of information in a limited display environment
US8839412B1 (en) 2005-04-21 2014-09-16 Seven Networks, Inc. Flexible real-time inbox access
US8438633B1 (en) 2005-04-21 2013-05-07 Seven Networks, Inc. Flexible real-time inbox access
US8761756B2 (en) 2005-06-21 2014-06-24 Seven Networks International Oy Maintaining an IP connection in a mobile network
US8468126B2 (en) 2005-08-01 2013-06-18 Seven Networks, Inc. Publishing data in an information community
US20110207436A1 (en) * 2005-08-01 2011-08-25 Van Gent Robert Paul Targeted notification of content availability to a mobile device
US8412675B2 (en) 2005-08-01 2013-04-02 Seven Networks, Inc. Context aware data presentation
US9055102B2 (en) 2006-02-27 2015-06-09 Seven Networks, Inc. Location-based operations and messaging
US20070200830A1 (en) * 2006-02-28 2007-08-30 Nintendo Co., Ltd. Input device using touch panel
US8693494B2 (en) 2007-06-01 2014-04-08 Seven Networks, Inc. Polling
US8774844B2 (en) 2007-06-01 2014-07-08 Seven Networks, Inc. Integrated messaging
US8805425B2 (en) 2007-06-01 2014-08-12 Seven Networks, Inc. Integrated messaging
US8253782B2 (en) * 2007-10-26 2012-08-28 Ge Inspection Technologies, Lp Integrated storage for industrial inspection handset
US20090109283A1 (en) * 2007-10-26 2009-04-30 Joshua Lynn Scott Integrated storage for industrial inspection handset
US8738050B2 (en) 2007-12-10 2014-05-27 Seven Networks, Inc. Electronic-mail filtering for mobile devices
US8364181B2 (en) 2007-12-10 2013-01-29 Seven Networks, Inc. Electronic-mail filtering for mobile devices
US8793305B2 (en) 2007-12-13 2014-07-29 Seven Networks, Inc. Content delivery to a mobile device from a content service
US20090157792A1 (en) * 2007-12-13 2009-06-18 Trevor Fiatal Content delivery to a mobile device from a content service
US9002828B2 (en) 2007-12-13 2015-04-07 Seven Networks, Inc. Predictive content delivery
US9712986B2 (en) 2008-01-11 2017-07-18 Seven Networks, Llc Mobile device configured for communicating with another mobile device associated with an associated user
US8914002B2 (en) 2008-01-11 2014-12-16 Seven Networks, Inc. System and method for providing a network service in a distributed fashion to a mobile device
US8909192B2 (en) 2008-01-11 2014-12-09 Seven Networks, Inc. Mobile virtual network operator
US8849902B2 (en) 2008-01-25 2014-09-30 Seven Networks, Inc. System for providing policy based content service in a mobile network
US8862657B2 (en) 2008-01-25 2014-10-14 Seven Networks, Inc. Policy based content service
US8838744B2 (en) 2008-01-28 2014-09-16 Seven Networks, Inc. Web-based access to data objects
US8799410B2 (en) 2008-01-28 2014-08-05 Seven Networks, Inc. System and method of a relay server for managing communications and notification between a mobile device and a web access server
US8787947B2 (en) 2008-06-18 2014-07-22 Seven Networks, Inc. Application discovery on mobile devices
US8494510B2 (en) 2008-06-26 2013-07-23 Seven Networks, Inc. Provisioning applications for a mobile device
US20100030901A1 (en) * 2008-07-29 2010-02-04 Bryan Severt Hallberg Methods and Systems for Browser Widgets
US9433532B2 (en) 2008-09-30 2016-09-06 Covidien Lp Tubeless compression device
US8909759B2 (en) 2008-10-10 2014-12-09 Seven Networks, Inc. Bandwidth measurement
US20110185279A1 (en) * 2010-01-22 2011-07-28 Stephen Ingkavet Methods and systems for requesting and delivering melody messages
US8801643B2 (en) 2010-02-12 2014-08-12 Covidien Lp Compression garment assembly
US9049179B2 (en) 2010-07-26 2015-06-02 Seven Networks, Inc. Mobile network traffic coordination across multiple applications
US8886176B2 (en) 2010-07-26 2014-11-11 Seven Networks, Inc. Mobile application traffic optimization
US8838783B2 (en) 2010-07-26 2014-09-16 Seven Networks, Inc. Distributed caching for resource and mobile network traffic management
US9077630B2 (en) 2010-07-26 2015-07-07 Seven Networks, Inc. Distributed implementation of dynamic wireless traffic policy
US9043433B2 (en) 2010-07-26 2015-05-26 Seven Networks, Inc. Mobile network traffic coordination across multiple applications
US9407713B2 (en) 2010-07-26 2016-08-02 Seven Networks, Llc Mobile application traffic optimization
US8484314B2 (en) 2010-11-01 2013-07-09 Seven Networks, Inc. Distributed caching in a wireless network of content delivered for a mobile application over a long-held request
US8782222B2 (en) 2010-11-01 2014-07-15 Seven Networks Timing of keep-alive messages used in a system for mobile network resource conservation and optimization
US8166164B1 (en) 2010-11-01 2012-04-24 Seven Networks, Inc. Application and network-based long poll request detection and cacheability assessment therefor
US9330196B2 (en) 2010-11-01 2016-05-03 Seven Networks, Llc Wireless traffic management system cache optimization using http headers
US9275163B2 (en) 2010-11-01 2016-03-01 Seven Networks, Llc Request and response characteristics based adaptation of distributed caching in a mobile network
US9021048B2 (en) 2010-11-01 2015-04-28 Seven Networks, Inc. Caching adapted for mobile application behavior and network conditions
US8190701B2 (en) 2010-11-01 2012-05-29 Seven Networks, Inc. Cache defeat detection and caching of content addressed by identifiers intended to defeat cache
US9060032B2 (en) 2010-11-01 2015-06-16 Seven Networks, Inc. Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic
US8843153B2 (en) 2010-11-01 2014-09-23 Seven Networks, Inc. Mobile traffic categorization and policy for network use optimization while preserving user experience
US8326985B2 (en) 2010-11-01 2012-12-04 Seven Networks, Inc. Distributed management of keep-alive message signaling for mobile network resource conservation and optimization
US8966066B2 (en) 2010-11-01 2015-02-24 Seven Networks, Inc. Application and network-based long poll request detection and cacheability assessment therefor
US8204953B2 (en) 2010-11-01 2012-06-19 Seven Networks, Inc. Distributed system for cache defeat detection and caching of content addressed by identifiers intended to defeat cache
US8291076B2 (en) 2010-11-01 2012-10-16 Seven Networks, Inc. Application and network-based long poll request detection and cacheability assessment therefor
US8700728B2 (en) 2010-11-01 2014-04-15 Seven Networks, Inc. Cache defeat detection and caching of content addressed by identifiers intended to defeat cache
US20120158908A1 (en) * 2010-11-22 2012-06-21 Michael Luna Mobile network background traffic data management with optimized polling intervals
US8539040B2 (en) * 2010-11-22 2013-09-17 Seven Networks, Inc. Mobile network background traffic data management with optimized polling intervals
US8903954B2 (en) * 2010-11-22 2014-12-02 Seven Networks, Inc. Optimization of resource polling intervals to satisfy mobile device requests
US8417823B2 (en) * 2010-11-22 2013-04-09 Seven Network, Inc. Aligning data transfer to optimize connections established for transmission over a wireless network
US9100873B2 (en) 2010-11-22 2015-08-04 Seven Networks, Inc. Mobile network background traffic data management
US20120131095A1 (en) * 2010-11-22 2012-05-24 Michael Luna Optimization of resource polling intervals to satisfy mobile device requests
US20120131184A1 (en) * 2010-11-22 2012-05-24 Michael Luna Aligning data transfer to optimize connections established for transmission over a wireless network
US9325662B2 (en) 2011-01-07 2016-04-26 Seven Networks, Llc System and method for reduction of mobile network traffic used for domain name system (DNS) queries
US8316098B2 (en) 2011-04-19 2012-11-20 Seven Networks Inc. Social caching for device resource sharing and management
US9300719B2 (en) 2011-04-19 2016-03-29 Seven Networks, Inc. System and method for a mobile device to use physical storage of another device for caching
US9084105B2 (en) 2011-04-19 2015-07-14 Seven Networks, Inc. Device resources sharing for network resource conservation
US8356080B2 (en) 2011-04-19 2013-01-15 Seven Networks, Inc. System and method for a mobile device to use physical storage of another device for caching
US8635339B2 (en) 2011-04-27 2014-01-21 Seven Networks, Inc. Cache state management on a mobile device to preserve user experience
US8832228B2 (en) 2011-04-27 2014-09-09 Seven Networks, Inc. System and method for making requests on behalf of a mobile device based on atomic processes for mobile network traffic relief
US8621075B2 (en) 2011-04-27 2013-12-31 Seven Metworks, Inc. Detecting and preserving state for satisfying application requests in a distributed proxy and cache system
US9465822B2 (en) 2011-05-12 2016-10-11 Google Inc. Data model generation based on user interface specification
US8806348B2 (en) * 2011-05-12 2014-08-12 Google Inc. Data model generation based on user interface specification
US20120290940A1 (en) * 2011-05-12 2012-11-15 Google Inc. Data Model Generation Based on User Interface Specification
US8984581B2 (en) 2011-07-27 2015-03-17 Seven Networks, Inc. Monitoring mobile application activities for malicious traffic on a mobile device
US9239800B2 (en) 2011-07-27 2016-01-19 Seven Networks, Llc Automatic generation and distribution of policy information regarding malicious mobile traffic in a wireless network
US10318061B2 (en) 2011-09-30 2019-06-11 Apple Inc. Flexible electronic devices
US9971448B2 (en) 2011-09-30 2018-05-15 Apple Inc. Flexible electronic devices
US10739908B2 (en) 2011-09-30 2020-08-11 Apple Inc. Flexible electronic devices
EP3299927A1 (en) * 2011-09-30 2018-03-28 Apple Inc. Flexible electronic devices
US11675390B2 (en) 2011-09-30 2023-06-13 Apple Inc. Flexible electronic devices
US8977755B2 (en) 2011-12-06 2015-03-10 Seven Networks, Inc. Mobile device and method to utilize the failover mechanism for fault tolerance provided for mobile traffic management and network/device resource conservation
US8918503B2 (en) 2011-12-06 2014-12-23 Seven Networks, Inc. Optimization of mobile traffic directed to private networks and operator configurability thereof
US8868753B2 (en) 2011-12-06 2014-10-21 Seven Networks, Inc. System of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation
US9208123B2 (en) 2011-12-07 2015-12-08 Seven Networks, Llc Mobile device having content caching mechanisms integrated with a network operator for traffic alleviation in a wireless network and methods therefor
US9277443B2 (en) 2011-12-07 2016-03-01 Seven Networks, Llc Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol
US9009250B2 (en) 2011-12-07 2015-04-14 Seven Networks, Inc. Flexible and dynamic integration schemas of a traffic management system with various network operators for network traffic alleviation
US9173128B2 (en) 2011-12-07 2015-10-27 Seven Networks, Llc Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol
US8861354B2 (en) 2011-12-14 2014-10-14 Seven Networks, Inc. Hierarchies and categories for management and deployment of policies for distributed wireless traffic optimization
US9021021B2 (en) 2011-12-14 2015-04-28 Seven Networks, Inc. Mobile network reporting and usage analytics system and method aggregated using a distributed traffic optimization system
US9832095B2 (en) 2011-12-14 2017-11-28 Seven Networks, Llc Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic
US20130173698A1 (en) * 2011-12-30 2013-07-04 Ramandeep Sethi Dynamic Content Adaptation
US9131397B2 (en) 2012-01-05 2015-09-08 Seven Networks, Inc. Managing cache to prevent overloading of a wireless network due to user activity
US8909202B2 (en) 2012-01-05 2014-12-09 Seven Networks, Inc. Detection and management of user interactions with foreground applications on a mobile device in distributed caching
US20130196646A1 (en) * 2012-01-26 2013-08-01 Samsung Electronics Co., Ltd Apparatus and method for exchanging information on device in communication between devices
US8929824B2 (en) * 2012-01-26 2015-01-06 Samsung Electronics Co., Ltd. Apparatus and method for exchanging information on device in communication between devices
US9203864B2 (en) 2012-02-02 2015-12-01 Seven Networks, Llc Dynamic categorization of applications for network access in a mobile network
US9326189B2 (en) 2012-02-03 2016-04-26 Seven Networks, Llc User as an end point for profiling and optimizing the delivery of content and data in a wireless network
KR101227769B1 (en) 2012-02-28 2013-01-30 세븐 네트워크스, 아이엔씨. Mobile network background traffic data management with optimized polling intervals
US9547770B2 (en) 2012-03-14 2017-01-17 Intralinks, Inc. System and method for managing collaboration in a networked secure exchange environment
US8812695B2 (en) 2012-04-09 2014-08-19 Seven Networks, Inc. Method and system for management of a virtual network connection without heartbeat messages
US10263899B2 (en) 2012-04-10 2019-04-16 Seven Networks, Llc Enhanced customer service for mobile carriers using real-time and historical mobile application and traffic or optimization data associated with mobile devices in a mobile network
US9654450B2 (en) 2012-04-27 2017-05-16 Synchronoss Technologies, Inc. Computerized method and system for managing secure content sharing in a networked secure collaborative exchange environment with customer managed keys
US9596227B2 (en) 2012-04-27 2017-03-14 Intralinks, Inc. Computerized method and system for managing an email input facility in a networked secure collaborative exchange environment
US20140245015A1 (en) * 2012-04-27 2014-08-28 Intralinks, Inc. Offline file access
US10142316B2 (en) 2012-04-27 2018-11-27 Intralinks, Inc. Computerized method and system for managing an email input facility in a networked secure collaborative exchange environment
US9807078B2 (en) 2012-04-27 2017-10-31 Synchronoss Technologies, Inc. Computerized method and system for managing a community facility in a networked secure collaborative exchange environment
US10356095B2 (en) 2012-04-27 2019-07-16 Intralinks, Inc. Email effectivity facilty in a networked secure collaborative exchange environment
US8775631B2 (en) 2012-07-13 2014-07-08 Seven Networks, Inc. Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications
US9161258B2 (en) 2012-10-24 2015-10-13 Seven Networks, Llc Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion
US9307493B2 (en) 2012-12-20 2016-04-05 Seven Networks, Llc Systems and methods for application management of mobile device radio state promotion and demotion
US9241314B2 (en) 2013-01-23 2016-01-19 Seven Networks, Llc Mobile device with application or context aware fast dormancy
US9271238B2 (en) 2013-01-23 2016-02-23 Seven Networks, Llc Application or context aware fast dormancy
US8874761B2 (en) 2013-01-25 2014-10-28 Seven Networks, Inc. Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols
US8750123B1 (en) 2013-03-11 2014-06-10 Seven Networks, Inc. Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network
US20140364034A1 (en) * 2013-06-06 2014-12-11 HLL Design, Inc. Collapsible plush pillow toy with sound trigger
US9065765B2 (en) 2013-07-22 2015-06-23 Seven Networks, Inc. Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network
US10856107B2 (en) 2013-08-19 2020-12-01 Estimote Polska Sp z o.o. System and method for providing content using beacon systems
US11202171B2 (en) 2013-08-19 2021-12-14 Estimote Polska Sp z o.o. System and method for providing content using beacon systems
US11297460B2 (en) 2013-08-19 2022-04-05 Estimote Polska Sp z o.o. Wireless beacon and methods
US9955297B2 (en) 2013-08-19 2018-04-24 Estimote Polska Sp. Z O. O. Systems and methods for object tracking using wireless beacons
US9998863B2 (en) 2013-08-19 2018-06-12 Estimote Polska Sp. Z O. O. System and method for providing content using beacon systems
US10244348B2 (en) 2013-08-19 2019-03-26 Estimote Polska Sp z o.o. Methods for authenticating communication between a mobile device and wireless beacon at a remote domain name system, projecting a level of interest in a nearby product, and providing and ordering option or product data
US10346937B2 (en) 2013-11-14 2019-07-09 Intralinks, Inc. Litigation support in cloud-hosted file sharing and collaboration
US9762553B2 (en) 2014-04-23 2017-09-12 Intralinks, Inc. Systems and methods of secure data exchange
US9613190B2 (en) 2014-04-23 2017-04-04 Intralinks, Inc. Systems and methods of secure data exchange
US11054804B2 (en) * 2015-06-15 2021-07-06 Comau S.P.A. Portable safety control device for industrial machines in particular robots
US10033702B2 (en) 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
US9826351B2 (en) 2015-09-02 2017-11-21 Estimote Polska Sp. Z O. O. System and method for beacon fleet management
US10136250B2 (en) 2015-09-02 2018-11-20 Estimote Polska Sp. Z O. O. System and method for lower power data routing
US11006237B2 (en) 2015-09-02 2021-05-11 Estimote Polska Sp z o.o. System and method for low power data routing
US10771917B2 (en) 2015-09-02 2020-09-08 Estimote Polska Sp z o.o. System and method for low power data routing
US10616709B2 (en) 2015-09-02 2020-04-07 Estimote Polska Sp z o.o. System and method for lower power data routing
US9942706B2 (en) 2015-09-02 2018-04-10 Estimote Polska Sp. Z O. O. System and method for beacon fleet management
US9826356B2 (en) 2015-09-02 2017-11-21 Estimote Polska Sp. Z O. O. Systems and methods for object tracking with wireless beacons
US10524083B2 (en) 2015-09-02 2019-12-31 Estimote Polska Sp z o.o. System and method for low power data routing
US9930486B2 (en) 2015-09-02 2018-03-27 Estimote Polska Sp. Z O. O. Systems and methods for object tracking with wireless beacons
US10332482B2 (en) * 2015-09-25 2019-06-25 Fresenius Medical Care Holdings, Inc. Automated display dimness control for a medical device
US20170092227A1 (en) * 2015-09-25 2017-03-30 Fresenius Medical Care Holdings, Inc. Automated Display Dimness Control for a Medical Device
WO2017143281A1 (en) * 2016-02-17 2017-08-24 Estimote, Inc. System and method for providing content using beacon systems
US10009729B2 (en) 2016-03-22 2018-06-26 Estimote Polska Sp. Z O. O. System and method for multi-beacon interaction and management
US9872146B2 (en) 2016-03-22 2018-01-16 Estimote Polska Sp. Z O. O. System and method for multi-beacon interaction and management
US9867009B2 (en) 2016-03-22 2018-01-09 Estimote Polska Sp. Z O. O. System and method for multi-beacon interaction and management
US10142786B2 (en) 2016-03-22 2018-11-27 Estimote Polska Sp. Z O. O. System and method for multi-beacon interaction and management
US9936345B1 (en) 2016-07-07 2018-04-03 Estimote Polska Sp. Z O. O. Method and system for content delivery with a beacon
US9866996B1 (en) 2016-07-07 2018-01-09 Estimote Polska Sp. Z O. O. Method and system for content delivery with a beacon
WO2018170495A1 (en) * 2017-03-17 2018-09-20 VICIS, Inc. Removable communications module pocket
US10873357B2 (en) 2017-05-02 2020-12-22 Deere & Company Smart attachment for a work vehicle
US11567654B2 (en) 2017-05-16 2023-01-31 Apple Inc. Devices, methods, and graphical user interfaces for accessing notifications
US10523685B1 (en) 2018-08-22 2019-12-31 Estimote Polska Sp z o.o. System and method for verifying device security
US11218492B2 (en) 2018-08-22 2022-01-04 Estimote Polska Sp. Z .O.O. System and method for verifying device security
US10852441B2 (en) 2018-08-24 2020-12-01 Estimote Polska Sp z o.o. Method and system for asset management
AU2020239726B1 (en) * 2020-03-10 2021-08-05 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11416127B2 (en) 2020-03-10 2022-08-16 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11455085B2 (en) 2020-03-10 2022-09-27 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11474674B2 (en) 2020-03-10 2022-10-18 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11188202B2 (en) 2020-03-10 2021-11-30 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11137904B1 (en) 2020-03-10 2021-10-05 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11762538B2 (en) 2020-03-10 2023-09-19 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11921993B2 (en) 2020-03-10 2024-03-05 Apple Inc. Devices, methods, and graphical user interfaces for interacting with user interface objects corresponding to applications
US11747969B1 (en) 2022-05-06 2023-09-05 Apple Inc. Devices, methods, and graphical user interfaces for updating a session region
US11775128B1 (en) 2022-05-06 2023-10-03 Apple Inc. Devices, methods, and graphical user interfaces for updating a session region
US11842028B2 (en) 2022-05-06 2023-12-12 Apple Inc. Devices, methods, and graphical user interfaces for updating a session region

Also Published As

Publication number Publication date
US20150040118A1 (en) 2015-02-05
US8261256B1 (en) 2012-09-04
US20130061216A1 (en) 2013-03-07
US9256420B2 (en) 2016-02-09
WO2008025018A3 (en) 2009-01-08
WO2008025018A2 (en) 2008-02-28
JP2010503052A (en) 2010-01-28
WO2008025017A2 (en) 2008-02-28
WO2008025017A3 (en) 2009-03-19
US8839224B2 (en) 2014-09-16
KR20090082349A (en) 2009-07-30
TW200828032A (en) 2008-07-01
TW200830876A (en) 2008-07-16
EP2082564A2 (en) 2009-07-29
EP2434724A2 (en) 2012-03-28
AU2007288991A1 (en) 2008-02-28

Similar Documents

Publication Publication Date Title
US9654589B2 (en) Configurable personal audiovisual device for use in application-sharing system
US20080068519A1 (en) Networked personal audiovisual device having flexible housing
US7778792B2 (en) Systems and methods for location, motion, and contact detection and tracking in a networked audiovisual device
US9344522B2 (en) Systems and methods for widget rendering and sharing on a personal electronic device
JP5922709B2 (en) System and method for simplifying data transfer
US10164984B2 (en) Method and apparatus for sharing data
US20090024943A1 (en) Systems and methods for alarm tone selection, distribution, and playback in a networked audiovisual device
KR102312336B1 (en) Method for sharing data and apparatus thereof
CN101548531A (en) Configurable personal audiovisual device for use in networked application-sharing system
WO2010099551A2 (en) Systems and methods for widget rendering and sharing on a personal electronic device
AU2014200631A1 (en) Terminal apparatus, server and method of controlling the same
CN114584412A (en) Method for obtaining equipment control right and communication system
CN112612397B (en) Multimedia list management method, device, equipment and storage medium

Legal Events

Date Code Title Description
AS Assignment

Owner name: CHUMBY INDUSTRIES, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ADLER, STEVEN M.;GRAND, JOSEPH B.;HUANG, ANDREW S.;AND OTHERS;SIGNING DATES FROM 20071108 TO 20071126;REEL/FRAME:025179/0893

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION