Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
  • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
  • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
  • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
  • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/02—Services making use of location information
  • H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/52—Network services specially adapted for the location of the user terminal
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M1/00—Substation equipment, e.g. for use by subscribers
  • H04M1/02—Constructional features of telephone sets
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M1/00—Substation equipment, e.g. for use by subscribers
  • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
  • H04M1/725—Cordless telephones
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/50—Service provisioning or reconfiguring
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/75—Indicating network or usage conditions on the user display
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W74/00—Wireless channel access
  • H04W74/04—Scheduled access
  • H04W74/06—Scheduled access using polling
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
  • H04W8/24—Transfer of terminal data
  • H04W8/245—Transfer of terminal data from a network towards a terminal

Definitions

• the invention relates to the field of controlling electronic devices and to modifying their behavior responsive to the environment.
• US 2002/0174025 shows a method and system for providing targeted advertising and personalized customer services.
• This system envisions a shopping cart with RFID- tagged products.
• the RFID tags trigger a wireless communication device such as a PDA, mobile phone, pager, or special shopping cart attachment device to deliver customized advertising based on what products are in the shopping cart.
• a group of electronic devices premises might communicate with each other in order to affect application behavior, especially devices co-located within a user premises. Such communication might result in changes in program behavior; or changes in state of the devices; or changes in program content.
• Fig. 1 shows an embodiment of a system in accordance with the invention
• Fig. 2 shows an embodiment of a system in accordance with the invention.
• Fig. 3 shows a flow diagram for code associated with a procedure called ' 'getProces singDevice' '
• Fig. 4 shows a flow diagram for code associated with a procedure called getTransmitters.
• Fig. 5. shows a flow diagram for code associated with a procedure called getTransmittersStatus.
• Fig. 6 shows a flow diagram suitable for use at 309 of Fig. 3.
• Fig. 1 shows an embodiment of the invention.
• the system includes one or more devices 101. These might be of any sort, especially consumer devices such as telephones, microwave ovens, video game platforms, televisions, or the like.
• the system also includes a processor 102, which also might be of any sort, such as a PC, a set top box, a digital signal processor or a general processor, optionally embedded in some consumer device.
• Another element of the system is an output device 103, which again might be of any suitable sort, such as a monitor, a television, a loudspeaker, or a printer.
• the output device 103 is illustrated as being separate from the other devices, but it might also be housed together with the processor 102 or one of the devices 101, as shown by the dotted boxes 106 and 107, respectively.
• antennas 105 which allow them to communicate wirelessly, e.g. at radio frequencies ("RF").
• RF radio frequencies
• Other wireless technologies like the Bluetooth technology, described or Wireless Fidelity technology (“Wi-Fi”), described e.g. at could also be used to implement the system of Fig. 1.
• Wi-Fi Wireless Fidelity technology
• the output device 103 is housed together with another device, it might not need its own antenna.
• some of the devices may be connected via lines, such the optional connection shown as a dotted line at 104.
• the number of devices 101 may vary according to the user preferences.
• tags are preferably affixed by the manufacturer of a device, such as a consumer device, and programmed to contain an identification of the device. Manufacturers may do this for their own reasons.
• the tags may be affixed at the request of someone who wishes to implement the invention.
• This identification preferably includes brand name, type of product, and a serial or model number.
• the processor could then access some sort of database, whether local or remote, to get other information about the device. This database might be as simple as a table within the receiving device, or as complex as a remote server.
• the application see 210 discussed below, is running inside a television and detects both that one of the devices 101 is a telephone and that the state of the telephone is ringing, the application 210 might issue a control command to lower the volume of the television so that the user can hear the ringing.
• This is an example of an audio output device changing its audio output in response to a state of another device.
• the application 210 might signal the television to tune to a cooking program. This is an example of a consumer device choosing a transmitted signal in response to a state of anther device.
• the application 210 could make its skin, or other visual attribute, to look like the video game that is currently playing. More about skin can be found at
• the application 210 has several skins and wants to select one for every specific user. For this, it scans the status of all tags around the receiver. Suppose it finds two black phones, a metallic microwave and a silver game console. It could use this color information to select a skin that has a metallic look. This might be expected to be aesthetically pleasing to the user, since the user has other devices with metallic looks. Analogously, if several oval devices are in the room, a skin with oval theme can be selected. These are examples of a device changing a visual attribute in response to a state of another device.
• a transmitted program has selectable plot or character options, those might also be selected responsive to devices in the room. For instance, if children's toys are detected, plot or character options more suitable to children might be presented.
• Fig. 2 shows an embodiment of the invention.
• a central receiver 201 and two transmitters 206, 208.
• These contain RF (Radio Frequency) tags 204, 207, and 209, respectively.
• RF-ID tags currently have short range, such as less than 1 meter. Accordingly, these would operate best within the shelves of a home theater. Other longer-range technologies could extend to an entire room or apartment.
• the receiver 201 has a software (SW) portion 202 and a hardware (HW) portion 203.
• SW software
• HW hardware
• the antenna 214 receives RF signals from all three tags 204, 207, and 209, i.e. including from the tag of its own device. Accordingly, the RF reader 213 can act on all of this data.
• the receiver 201 will need to distinguish its own tag 204 from the tags 207, 209 of the other devices. There are several ways in which this might be accomplished.
• the one closest to the receiver i.e. the one with the greatest signal strength, is the one most likely to be the receiver's own tag 204.
• Current RF-ID software already provides the capacity to query the signal strength of a received signal. This heuristic is not 100% fail safe, however.
• One of the devices 206, 208 might be positioned immediately adjacent to the receiver, 201, for instance on the same shelf of a home theater or book case. In such a case, the other device's tag 207, 209 could be closer to the antenna 214 than the receiver' s own tag 204.
• Another possible way to distinguish the tag 204 from the tags 207, 209, would be an algorithm that determines from all the types of devices near the receiver, which one most likely is the receiver's own. For instance, if one assumes a TV, a telephone, and a game station are detected; the algorithm could decide that the TV is most likely the device that has the RF reader integrated, so it will consider the TV's RF tag as the receiver's own tag.
• the receiver's own tag might also have a direct connection with the RF reader, for instance a wired connection. This way the receiver could be 100% sure which tag is its own. However, this would involve greater expense and inconvenience for manufacturers, and therefore their compliance would be hard to obtain.
• the tags might have some kind of positioning system, like the Global Positioning System (GPS) such that all tags would have positional coordinates that they could transmit to the receiver.
• GPS Global Positioning System
• application 210 might be programmed to know that it is in a particular type of device, such as a television, and therefore look for the closest tag identifying that type of device -- and assume that that is the tag associated with the receiver.
• the SW portion includes several modules.
• One is a Multimedia Home Platform (MHP) 205 or OpenCable Applications Platform (OCAP). More information about MHP can be found at h ⁇ MlU ⁇ M ⁇ Ms& ⁇ iMESlMikMMMP.
• OCAP is a similar system to MHP, but intended for the US market.
• a second is the MHP application 210, which will be discussed further below.
• a third module is the RF extension to the MHP/OCAP 212, which obtains an identification number (ID) from the RF tags 207,209 associated with the various devices. If an application 210 can know on which brand it is running on, it can execute the program code that works for this specific brand.
• the module 212 is an Application Program Interface (API). More information about API's can be found at • The API interacts with a vendor data base 211. Code associated with the API and used to gather information as part of the invention is illustrated with respect to figures 3-5. Fig. 3 is useful for MHP interoperability, in other words, making sure that MHP applications can run on any brand hardware. Fig. 4 is useful for finding out characteristics of the environment of the user premises. Fig. 5 gives a more detailed picture of the environment by retrieving more details from the devices in the neighborhood.
• the invention could also be used in the context of an ordinary application, not based on MHP or OCAP middleware. In that case, instead of the RF extension to MHP/OCAP, there would be a software library.
• Fig 3 illustrates the operation of a procedure to collect information about the device
• the MHP application 210 issues the "getProcessingDevice" command 301. This triggers the RF extension to MHP/OCAP 212 to issue a command 302 to read the receiver tag. This command 302 in turn triggers the RF reader 213 to issue a Get ID command 303. This command 303 triggers the receiver's RF tag 214 to issue an ID at 304. This ID 304 then triggers the
• Block 212 then issues a "getBrand" command at 306 to get the brand associated with the receiver tag ID from the Vendor/product database 211.
• the database then returns the Brand name and product identification at 307 to the RF extension to the MHP/OCAP 212, which then sends information about the processing device at 308 to the MHP application 210.
• the MHP application 210 then adapts some application behavior at 309.
• Fig 4 illustrates the operation of a procedure to collect information about the transmitting devices 206 and 208 and adapt application behavior in response. While Fig. 2 only shows 2 transmitters, three transmitters are illustrated in fig 4, but the same reference numbers are used to show correspondence with Fig. 2.
• the MHP application 210 issues the "getTransmitters" command 401. This triggers the RF extension to MHP/OCAP 212 to issue a command 402 to read the transmitter tags 207, 209. This command 402 in turn triggers the RF reader 213 to issue a Get ID command 403. This command 403 triggers the transmitters' RF tags 207, 209 to issue an ID at 404.
• This ID 404 then triggers the RF reader 213 to issue at 405 the transmitter tag ID to the RF extension to the MHP/OCAP 212.
• Block 212 then issues a "getProduct(ID 1, ID 2, ID 3)" command at 406 to get the brand associated with transmitter tag ID from the Vendor/product database 211.
• the database then returns the product identification (prod 1, prod 2, prod 3) at 407 to the RF extension to the MHP/OCAP 212, which then sends information about the Transmitters (tl, t2, t3) at 408 to the MHP application 210.
• the MHP application 210 then adapts some application behavior at 409.
• Fig 5 illustrates the operation of a procedure to collect status information about the transmitting devices 206 and 208 and adapt application behavior in response.
• three transmitters are illustrated in fig 5, but the same reference numbers are used for the transmitters to show correspondence with Fig. 2. Again, any number of transmitters may actually be used.
• the MHP application 210 issues the "getTransmittersStatus" command 501. This triggers the RF extension to MHP/OCAP 212 to issue a command 502 to read the transmitter status, preferably from the tags 207, 209. This command 502 in turn triggers the RF reader 213 to issue a Get status command 503. This command 503 triggers the transmitters' RF tags 207, 209 to issue a status report at 504.
• This status 504 then triggers the RF reader 213 to issue at 505 the transmitter status to the RF extension to the MHP/OCAP 212.
• Block 212 then issues a "transmitters' status (statel, state2, state3)" report at 508.
• the MHP application 210 then adapts some application behavior at 509.
• MHP is an application execution environment that is independent of the underlying, vendor-specific hardware. This means that MHP applications, shown at 210, theoretically should be able to run on any MHP hardware of any brand. This is the theory, but in practice it is very hard to write applications that work on all brands. Some program code needs to be different for different brands.
• the receiver 201 decides that, in order to draw something on a display screen, it must hide the current video display of a television. How this is to be done will depend on the brand of the television.
• the MHP application 210 is designed to be general purpose therefore it has code for several brands to allow it to hide video in different ways dependent on the design of the various brands.
• the receiver scans its own device tag — or what it believes to be its own device tag — to determine what brand of television it finds itself in. If it determines that it is in a Brand A television, then at 605 it will issue a command to scale the video to (0,0).
• the MHP 210 will issue a command to hide the video layer. If a Brand C television is detected, than at 604 the MHP 210 will issue commands to pause the video and blank the screen. After the appropriate command is issued, control proceeds to 603, where other application tasks are continued.
• the embodiments described above relate to an MHP application.
• the invention could also be applied to a PC environment, with a PC application running under an operating system such as Windows, rather than an MHP application.
• the Windows environment would have to be extended with the RF extension API.
• Other intelligent appliances such as mobile phones and PDAs might implement the invention as well.
• middleware software could be used instead of MHP/OCAP, such as the standards devised by the Multimedia and Hypermedia information coding Expert Group ("MHEG") as described in htt ⁇ Z/eiLwjkjjjedja ⁇ oj ⁇ /wiki/MJieg, OpenTV as described in htt ⁇ fe
• MHEG Multimedia and Hypermedia information coding Expert Group
• OpenTV as described in htt ⁇ fe

Landscapes

• Engineering & Computer Science (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computer Hardware Design (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Mobile Radio Communication Systems (AREA)
• Selective Calling Equipment (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (2)

Family

ID=36972695

Family Applications (1)

Country Status (6)

Families Citing this family (13)

Family Cites Families (22)

• 2006
  • 2006-03-02 CN CN2006800074371A patent/CN101137948B/zh not_active Expired - Fee Related
  • 2006-03-02 US US11/908,021 patent/US8564414B2/en not_active Expired - Fee Related
  • 2006-03-02 JP JP2008500310A patent/JP5210855B2/ja not_active Expired - Fee Related
  • 2006-03-02 KR KR1020077022906A patent/KR101263668B1/ko not_active Expired - Fee Related
  • 2006-03-02 EP EP06755977.3A patent/EP1859335B1/en not_active Not-in-force
  • 2006-03-02 WO PCT/IB2006/050663 patent/WO2006097862A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events