U.S. patent application number 16/595684 was filed with the patent office on 2020-02-13 for codeset communication format and related methods and structures.
The applicant listed for this patent is Universal Electronics Inc.. Invention is credited to George Vergis.
Application Number | 20200051425 16/595684 |
Document ID | / |
Family ID | 41692223 |
Filed Date | 2020-02-13 |
![](/patent/app/20200051425/US20200051425A1-20200213-D00000.png)
![](/patent/app/20200051425/US20200051425A1-20200213-D00001.png)
![](/patent/app/20200051425/US20200051425A1-20200213-D00002.png)
![](/patent/app/20200051425/US20200051425A1-20200213-D00003.png)
![](/patent/app/20200051425/US20200051425A1-20200213-D00004.png)
United States Patent
Application |
20200051425 |
Kind Code |
A1 |
Vergis; George |
February 13, 2020 |
CODESET COMMUNICATION FORMAT AND RELATED METHODS AND STRUCTURES
Abstract
A codeset is described in a Public Codeset Communication Format
(PCCF) as a format block including a plurality of fields having
readily decipherable values, such as ASCII character values. One
field is a mark/space information field that includes a sequence of
mark time indicators and space time indicators for an operational
signal of the codeset. A second field is a signal characteristic
information field for the operational signal. Signal characteristic
information may include carrier on/off information, repeat frame
information, toggle control information, and last frame
information. The PCCF is a codeset interchange format of general
applicability.
Inventors: |
Vergis; George; (Fremont,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Universal Electronics Inc. |
Santa Ana |
CA |
US |
|
|
Family ID: |
41692223 |
Appl. No.: |
16/595684 |
Filed: |
October 8, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16248941 |
Jan 16, 2019 |
10490064 |
|
|
16595684 |
|
|
|
|
15380130 |
Dec 15, 2016 |
10192428 |
|
|
16248941 |
|
|
|
|
14276466 |
May 13, 2014 |
9582996 |
|
|
15380130 |
|
|
|
|
12706080 |
Feb 16, 2010 |
8761199 |
|
|
14276466 |
|
|
|
|
11359149 |
Feb 21, 2006 |
7668197 |
|
|
12706080 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G08C 23/04 20130101;
G08C 19/28 20130101; H04N 21/42221 20130101; H04N 21/42204
20130101 |
International
Class: |
G08C 23/04 20060101
G08C023/04; G08C 19/28 20060101 G08C019/28; H04N 5/44 20060101
H04N005/44 |
Claims
1. A controlling device, comprising: a microcontroller; a
transmitting device; an input device; and a memory storing an
encrypted codeset information; wherein the microcontroller further
comprises both a decryptor that decrypts a command generating
information that is caused to be retrieved from the encrypted
codeset information in response to an input received via use of the
input device and a rendering engine that uses the command
generating information as decrypted by the decryptor to generate a
command signal for transmission by the transmitting device to a
controllable device and wherein the command signal generated by the
rendering engine has both a format recognizable by the controllable
device and a data indicative of a functional operation of the
controllable device that corresponds to the input received via use
of the input device.
2. The controlling device as recited in claim 1, wherein the
transmitting device comprises an infrared transmitting device.
3. The controlling device as recited in claim 1, wherein the input
element comprises a hard key.
4. The controlling device as recited in claim 1, wherein the
encrypted codeset information comprises a compressed format block
having first data fields that each describe, via use of one or more
characters taken from an alphabet, an input element of the
controlling device and second data fields that each describe, via
use of one or more characters taken from the alphabet, at least one
function that is to be performed by a controllable device in
response to an activation of the input element.
5. The controlling device as recited in claim 4, wherein the
compressed format block further has a third data field that
describes, via use of one or more characters selected from the
alphabet, a type for the controllable device.
6. The controlling device as recited in claim 5, wherein the
compressed format block further has a fourth data field that
describes, via use of one or more characters selected from the
alphabet, a type for the controllable device.
Description
RELATED APPLICATION
[0001] This application claims the benefit of and is a continuation
of U.S. application Ser. No. 16/248,941, filed on Jan. 16, 2019,
which application claims the benefit of and is a continuation of
U.S. application Ser. No. 15/380,130, filed on Dec. 15, 2016, which
application claims the benefit of and is a continuation of U.S.
application Ser. No. 14/276,466, filed on May 13, 2014, which
application claims the benefit of and is a continuation of U.S.
application Ser. No. 12/706,080, filed on Feb. 16, 2010, which
application claims the benefit of and is a continuation of U.S.
application Ser. No. 11/359,149, filed on Feb. 21, 2006. These
applications are incorporated herein by reference in their
entirety.
TECHNICAL FIELD
[0002] The present invention relates generally to codesets that are
used by remote control devices to generate operational signals that
control electronic consumer devices.
BACKGROUND
[0003] Manufacturers of electronic consumer devices, such as
televisions, radio tuners, digital video disk players, video
cassette recorders, set-top cable television boxes, set-top
satellite boxes, etc., typically supply a remote control device
along with each electronic consumer device. The remote control
device can control the associated electronic consumer device by
sending an operational signal to the electronic consumer device.
The operational signal may, for example, be the envelope of an
infrared signal. The operational signal carries a key code. Each
such key code corresponds to a function of the selected electronic
consumer device, such as power on, volume down, play, stop, select,
channel advance, channel back, etc. Thus, an electronic device is
controlled by a codeset of key codes.
[0004] Codesets can differ from each other not only by the
different key codes, but also by the carrier, timing and framing
protocols used to output the key codes as operational signals. In
order to avoid the situation where an operational signal containing
a key code operates an electronic device that is not selected,
manufacturers of electronic consumer devices may use different
codesets for different devices. Although each model of electronic
consumer device might not have a unique codeset, there are
nevertheless thousands of codesets used to operate the various
types, brands and models of electronic consumer devices sold in the
world market today.
[0005] Handheld remote control devices typically include an amount
of storage, a processor, and a transmitting device. Where the
remote control device is a handheld infrared remote control device,
the storage is typically semiconductor memory that is on the same
microcontroller integrated circuit as the processor. The
transmitting device may, for example, be an infrared light emitting
diode (LED). Information on one or more codesets is stored in the
memory of the microcontroller. When a key is pressed on the remote
control device, the microcontroller accesses the codeset
information and generates an appropriate key code signal. The key
code signal is modulated with the appropriate carrier and is
supplied to the LED, thereby causing the operational signal to be
transmitted as an envelope of the infrared signal.
[0006] Such microcontrollers are typically supplied to remote
control manufacturers preloaded with codesets that operate the
various types, brands and models of electronic devices that the
remote control device is to operate. It is therefore of significant
value to such a microcontroller manufacturer to be able to supply
the appropriate codesets needed for each possible remote control
application. A microcontroller manufacturer that has the codeset
needed for a particular remote control application has a
competitive advantage over another microcontroller manufacturer
that does not have the needed codeset. Some microcontroller
manufacturers therefore devote great effort and expense amassing
large and comprehensive databases of codesets. These codeset
databases are valuable to the microcontroller manufacturers.
[0007] Such microcontroller manufacturers have therefore
conventionally attempted to keep their codeset databases
proprietary. When working with a remote control device
designer/manufacturer, the microcontroller manufacturer is careful
not to disclose the format of the codeset information stored in the
microcontroller. The codeset information may only be provided to
the remote control manufacturer in the form of information stored
in a mask-programmable read only memory (ROM) on the
microcontroller integrated circuits. Reading this codeset
information out of the microcontroller may be difficult, thereby
helping to keep the information confidential. Even if a remote
control device manufacturer were to be able to read the codeset
information out of the microcontroller memory, the remote control
device manufacturer would not know the format of the codeset
information. Because a rendering engine in the microcontroller
receives information in a particular format and converts that
information into the operational signals, and because how the
rendering engine does this conversion is not known to the remote
control device manufacturer, the remote control manufacturer's
knowledge of the codeset information stored in the microcontroller
does not allow the remote control manufacturer to use the codeset
information in a microcontroller from another microcontroller
manufacturer. By concealing how the rendering engine works and the
format of information that the rendering engine receives as inputs,
the deciphering of the codeset information stored on the
microcontroller is prevented. Conventionally, considerable care is
exercised keeping the format of codeset information as supplied to
the rendering engine as much of a secret as is reasonably possible.
Conventionally, the microcontroller manufacturer does not share the
format of the codeset information with any other entity, even its
best remote control device manufacturing customers.
SUMMARY
[0008] A codeset is described in a Public Codeset Communication
Format (PCCF) as a format block. The PCCF format block includes a
plurality of readily decipherable fields of ASCII character values.
Where the various fields are in the block and what the various
fields contain is made public as part of the PCCF. One field of the
PCCF format block is a mark/space information field that includes a
sequence of mark time indicators and space time indicators for an
operational signal of the codeset. A second field is a signal
characteristic information field for the operational signal. Signal
characteristic information may include carrier on/off information,
repeat frame information, toggle control information, and last
frame information. The PCCF is a codeset interchange format of
general applicability. The PCCF may, for example, be made public by
posting it on a publicly available web-site.
[0009] In one method, a first entity (for example, a remote control
device designer) describes a codeset in the PCCF format and then
communicates the PCCF format information to a second entity (for
example, a microcontroller manufacturer). The communication can be
by any suitable mechanism, but is preferably communication of an
ASCII file by reliable electronic means. The second entity converts
the information into a format usable by a rendering engine. The
rendering engine may, for example, be a part of a microcontroller
supplied and/or manufactured by the second entity. The rendering
engine is then usable in the remote control device to generate
operational signals of the codeset.
[0010] Where the rendering engine is part of a microcontroller
supplied by the second entity, the second entity may preload the
information in the format usable by the rendering engine into
memory in the microcontroller. The second entity then supplies the
microcontroller preloaded with the codeset information to the first
entity so that the first entity can incorporate the microcontroller
into the remote control device being designed. The remote control
device can then use the preloaded information to generate
operational signals in the codeset.
[0011] A valuable database of codesets compiled by the second
entity (the microcontroller manufacturer) can also be preloaded
into the microcontroller. Codesets in the database are described in
the same PCCF format as PCCF format blocks. The PCCF format blocks
are compressed and reformatted by the second entity into the format
that is usable by the rendering engine of the microcontroller. The
compressed and reformatted information is then encrypted by the
second entity and is preloaded into the microcontroller along with
the unencrypted codeset information described above. The
microcontroller is then supplied to the first entity and is
incorporated into the remote control device being designed. The
encrypted form of the codeset information in the microcontroller
helps maintain the proprietary nature of the codeset database
information.
[0012] When a key is pressed on the remote control device such that
an operational signal in one of the codesets of the database is to
be generated, the encrypted information is retrieved from
microcontroller memory, is decrypted by the decryptor within the
microcontroller, and is supplied in unencrypted form to the
rendering engine. The rendering engine uses the unencrypted
information to generate the desired operational signal for the
desired codeset in the database. In this way, a microcontroller can
include both encrypted codeset information from a codeset database
compiled by the second entity (the microcontroller manufacturer) as
well as unencrypted codeset information that was originally written
by the first entity (the remote control device designer) in the
PCCF format.
[0013] The PCCF format is a codeset interchange format of general
applicability and can be used to describe and communicate codeset
information between various different types of entities. The
interchange is not limited to the interchanges described
microcontroller manufacturers/suppliers and remote control device
designers/manufacturers. Accordingly, other embodiments involving
other uses of PCCF format blocks are described in the detailed
description below.
[0014] This summary does not purport to define the invention. The
invention is defined by the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] The accompanying drawings, where like numerals indicate like
components, illustrate embodiments of the invention.
[0016] FIG. 1 is a simplified diagram that illustrates a novel
method involving a PCCF format block.
[0017] FIG. 2 is a simplified diagram of multiple codesets
described in PCCF format blocks.
[0018] FIG. 3 is a more detailed diagram of one PCCF format
block.
[0019] FIG. 4 is a diagram of a remote control device showing the
X-Y coordinate grid that is used to describe the location of keys
and text in the key layout table of a PCCF format block.
DETAILED DESCRIPTION
[0020] Rather than maintaining the format of information in a
codeset database proprietary, a novel Public Codeset Communication
Format (PCCF) is disclosed. A first entity (for example, a company
that supplies and/or makes microcontrollers and that has also
compiled a codeset database) describes the codesets in its database
in accordance with the PCCF format. (The term database is used here
in a general non-technical sense and refers to a group of codesets
and possibly related information, where the codesets are stored in
association with one another.) A second entity (for example, a
remote control device manufacturer) can also describe codesets in
the PCCF format.
[0021] A particular codeset is describable in the PCCF format as a
readily decipherable format block of ASCII (American Standard Code
for Information Interchange) character values. The format block has
multiple fields. One of the fields is a mark/space information
field that specifies mark times and space times for generating the
operational signal. Another of the fields is a signal
characteristic information field that specifies other information
about how to render the operational signal. The signal
characteristic information field may include information such as:
carrier information, information on how to repeat the operational
signal, toggle control information, and last frame information. The
PCCF format block may also contain other fields including a key
layout table. The key layout table sets forth the physical location
of keys on the remote control device to which the codeset being
described pertains. The key layout table may also set forth text
that appears printed on the remote control device. The PCCF format
block may also contain other fields including a key function
identification table. The key function identification table
indicates how a device that receives a particular operational
signal will respond to receiving the operational signal. The layout
of the various fields in the format block as well as the meaning of
information in each field is made public. The information content
of the various fields is easily decipherable because the PCCF
format block is a block of ASCII character values.
[0022] In one novel method, a first entity (for example, a
microcontroller supplier and/or manufacturer that has compiled a
valuable database of codesets) wishes to receive royalty income for
the licensing of the codeset database to a second entity (for
example, a manufacturer or designer of a new remote control
device). The microcontroller supplier supplies the remote control
device manufacturer with: 1) an encrypted version of the codeset
database, and 2) a microcontroller that includes a rendering
engine, a decryptor, and a memory. If the rendering engine receives
codeset information in a particular format, then the rendering
engine can generate operational signals in the codeset. The format
of the codeset information received by the rendering engine is
proprietary to the microcontroller supplier.
[0023] All the codesets in the codeset database are described in
accordance with the PCCF format. The information in the resulting
PCCF format blocks is then compressed and reformatted as necessary
to put the information into a form required by the rendering engine
on the microcontroller. The compressed and reformatted information
is then encrypted and stored in encrypted form in the memory in the
microcontroller. The memory may, for example, be mask programmable
read-only-memory (ROM) such that the storing actually occurs at the
time of microcontroller integrated circuit manufacture.
[0024] After microcontroller manufacture, the microcontroller can
be incorporated into the new remote control device. If a key were
pressed on the new remote control device such that an operational
signal from one of the codesets in the data were to be generated by
the remote control device, then the appropriate encrypted
information in memory would be retrieved, would be decrypted by the
decryptor on the microcontroller, and would be supplied to the
rendering engine. The rendering engine would output an appropriate
operational signal that would drive a transmitting device (for
example, an infrared light emitting diode) on the remote control
device. The resulting infrared signal would be transmitted from the
remote control device and would carry the operational signal to the
consumer device to be controlled. If, for example, the operational
signal is the operational signal for the power on command in the
proper codeset understood by the receiving electronic consumer
device, then the electronic consumer device powers on as
desired.
[0025] In the present example, the remote control device
manufacturer (the second entity) wants the new remote control
device to be able to generate operational signals in a special
codeset that is not present in the codeset database of the
microcontroller manufacturer. The remote control device
manufacturer, however, is aware of the Public Codeset Communication
Format (PCCF). The remote control device manufacturer describes the
special codeset in accordance with the PCCF. The resulting PCCF
format block is then communicated from the remote control device
manufacturer (the second entity) to the microcontroller supplier
(the first entity). The microcontroller supplier compresses and
reformats the information in the PCCF format block as required to
put the information into a form that can be understood by the
rendering engine on the microcontroller. If the rendering engine on
the microcontroller were to receive the compressed and reformatted
information, then the rendering engine would be able to generate
operational signals in the special codeset. Accordingly, the
microcontroller supplier (the first entity) stores in
microcontroller memory both the compressed and reformatted PCCF
information for the special codeset as well as the compressed,
reformatted and encrypted information from the microcontroller
supplier's codeset database. As a result, when the microcontroller
is used in the new remote control device, the new remote control
device will be able to generate operational signals in the special
codeset and well as operational signals in any codeset in the
database.
[0026] Because the microcontroller is designed to make the
intercepting of information between the output of the decryptor and
the rendering engine difficult, the remote control device
manufacturer will not be able to readily decipher the content of
the unencrypted codeset database information as it passes from the
output of the decryptor to the rendering engine. The proprietary
content of the codeset database is therefore not compromised. Due
to the encryption, the codeset database information as supplied by
the microcontroller manufacturer is only usable on microcontrollers
supplied by the microcontroller supplier (the first entity) that
have the proper decryptor. The supplier's income stream from the
sale of microcontrollers and from the licensing of the codeset
database is therefore protected. The description of codesets in the
same PCCF format regardless of whether the descriptions were
generated by the microcontroller supplier (the first entity) or
were generated by the remote control device manufacturer (the
second entity) simplifies the compressing and formatting operations
that the microcontroller supplier has to do to put the PCCF format
blocks generated by the second entity in a proper form for being
used by the rendering engine.
[0027] FIG. 1 is a simplified diagram that corresponds to the novel
method set forth above. Block 1 represents the database of codesets
that were compiled by the microcontroller supplier (the first
entity). The codesets are described in the PCCF format as a
plurality of PCCF format blocks.
[0028] Block 2 represents the PCCF format block that describes the
special codeset. The PCCF format block was generated by the remote
control device manufacturer or designer (the second entity).
[0029] Blocks 3 and 4 represent the compression and reformatting
performed by the microcontroller manufacturer to convert the PCCF
format blocks into a format that can be received and used by the
rendering engine of the microcontroller. The rendering engine is
represented by block 5. Dashed block 6 represents an operational
signal rendering device such as, for example, a
microcontroller.
[0030] Block 7 represents the new remote control device that is
being designed and/or manufactured by the remote control device
manufacturer (the second entity). The remote control device 7 can
be a handheld infrared remote control device of the form typically
used to control electronic consumer devices such as televisions in
the home. The remote control device 7 can alternatively be another
type of remote control device such as a personal computer that has
a television tuner expansion card installed. Codeset information is
stored in the personal computer in mass storage on hard disc or
elsewhere. A processor (for example, a microcontroller supplied by
the first entity) on the expansion card uses this information to
generate operational signals. The operational signals are supplied
to a transmitter (for example, an IR LED) that is coupled to the
expansion card. A signal (for example, an infrared signal) that
carries an operational signal is transmitted from the transmitter
and to an electronic consumer device so that the personal computer
can control the electronic consumer device. The handheld remote
control device and the personal computer having the expansion card
are but two examples of remote control devices. The remote control
device 7 can take other forms as well.
[0031] As described above, the compressed and reformatted codeset
information from block 3 is encrypted before it is loaded into the
operational signal rendering device 6. Block 8 represents this
encryption. The encryption is performed by the microcontroller
supplier. The operational signal rendering device (in this case, a
microcontroller) includes a decryptor 9 for decrypting the
information encrypted by block 8. The output of the decryptor 9 is
in the compressed and reformatted form required by the rendering
device 5. Accordingly, the rendering engine 5 of FIG. 1 can receive
properly compressed and formatted codeset information from the
first entity's codeset database or from the second entity's special
codeset. The supplying of these two sources of compressed and
properly formatted information are represented by arrows 10 and
11.
[0032] The operational signal rendering device 6, in response to
receiving key press information, uses codeset information received
via source 10 or source 11 to generate an operational signal in an
appropriate codeset. Where the remote control device is a handheld
remote control device of a typical form, the microcontroller has
key scanning functionality that detects when a key is pressed and
reports which key it was that was pressed. Block 12 represents this
key press information that causes the rendering engine to output an
operational signal.
[0033] Block 13 represents the transmitting device that
communicates the operational signal. In the present example, the
transmitting device is an infrared LED. Block 14 represents the
electronic consumer device that receives the infrared signal and
responds to the operational signal.
[0034] FIG. 2 is a simplified diagram that shows the PCCF format
block 2 generated by the remote control device manufacturer (the
second entity) as well as the PCCF format blocks 1 of the codeset
database of the microcontroller supplier (the first entity). The
PCCF format block 2 for the special codeset includes a first
portion 15 of type 1 as well as a second portion 16 of type 2.
[0035] FIG. 3 is a more detailed diagram of the PCCF format block 2
of FIG. 2. First portion 15 includes general information that
pertains to all operational signals of the codeset. In first
portion 15, the first asterisk-delimited ASCII field 17 is a title
field that contains the value "RCA VCR-DVD COMBO". This value
indicates the type of device to be controlled by the codeset. There
may be multiple different codesets that control the device. For
example, a first codeset may be used to control the RCA VCR-DVD
COMBO device when the device is operating as a VCR whereas a second
codeset may be used to control the device when the device is
operating as a DVD. In the present example, there is only one
codeset that is used to control the RCA VCR-DVD COMBO device,
regardless of whether the device is operating as a VCR or a
DVD.
[0036] The second asterisk-delimited ASCII field 18 is a field that
contains the value "D1=DEVICE_VCR". There may be multiple different
models of the "RCA VCR-DVD COMBO" device type. Each such different
model would be designated with a different device number. The "D1"
in the example of FIG. 3 denotes the first such device. The value
"DEVICE_VCR" is an indicator of the first device. In the example of
FIG. 3, there is only one device of the type "RCA VCR-DVD
COMBO".
[0037] The third asterisk-delimited ASCII field 19 is a field 19
called the "key layout table". The key layout table includes a set
of semicolon-delimited subfields. The first subfield is
"1,0,SAT,;." This subfield includes a set of comma separated
subsubfields. The "1" in the first subsubfield denotes the X
coordinate location of a key on the remote control device. The "0"
in the second subsubfield denotes the Y coordinate location of the
key. FIG. 4 is a diagram of the remote control device. The key
referred to is the key bearing the text "SAT". It is located at X-Y
location "1,0". The next subsubfield contains the value "SAT". This
value is the text that appears on the key. The last subsubfield is
blank. This subsubfield could contain a value where the value is
text that is printed on the remote control device body in
association with the key. The value being blank indicates that
there is no text printed on the remote control device body that
corresponds to the key.
[0038] The second semicolon-delimited subfield is "11,0,S,S-POWER."
The "11,0" denotes the X-Y location of the next key. The next "S"
indicates that a symbol is printed on the key (rather than text).
The next "N-POWER" denotes that the text "POWER" is printed on the
body of the remote at location to the "north" (above) the key. If
the text had appeared below the key, then the subsubfield would
have the value "S-POWER", where the "S-" denotes "south". In the
same way, other possible prefixes for the value include "E-" and
"W-" for "east" and "west".
[0039] The fourth asterisk-delimited ASCII field is a field 20
called the "key function identification table". The key function
identification table includes a set of semicolon delimited
subfields. The first subfield is
"KEY_POWER=VCR_PW_Poweron/Poweroff". The subfield indicates that
the "KEY_POWER" function has the value "VCR_PW_Poweron/Poweroff."
This value indicates that on each subsequent press of the power
key, the VCR power is turned on, then off, then on, as so forth.
The "KEY_POWER" function could alternatively have been assigned the
value "VCR_PW_Poweron". This value would have meant that pressing
the power key would turn the VCR power on. If the VCR power had
already been on at the time of the key press, then the VCR power
would have remained on.
[0040] The second semicolon-delimited subfield is
"KEY_PLAY=VCR_PLAY_Play/Pause". The "VCR_PLAY_Play/Pause" value
means that successive pressings of the "PLAY" key cause the VCR to
play, to pause, to play, to pause, and so forth. The "KEY_PLAY"
function could alternatively have been assigned the value
"VCR_PLAY_Play". This value would mean that pressing the play key
would cause the VCR to play. If the VCR was already playing, then
the VCR would continue playing.
[0041] The third and fourth semicolon-delimited subfields are
interpreted in a similar manner. Functions of the form "KEY_XXX"
denote what function or functions is or are to be performed when
the key "XXX" is pressed. A series of functions can be specified to
be performed in association with a single key. In one example, the
value assigned indicates a function and also indicates that the
function is only to be performed if another key is pressed. For
example, pressing the "SOURCE" key may change the designated source
of input for the receiving device from one source to another, but
the actual change of the source will only take place if the "OK"
key is pressed next. This is sometimes called an "activate"
feature. The activate feature may be indicated by following the
first function value with "-A(OK)". This attribute indicates that
the prior function is activated by pressing the "OK" key.
[0042] In the example of FIG. 3, there are only four
asterisk-delimited fields in the first portion 15 of the PCCF
format block 2. The second portion 16 of PCCF format block 2
contains a set of asterisk-delimited fields, where there in one
such field for each operational signal to be generated. Two such
fields 21 and 22 are illustrated in the example of FIG. 3. The
first field 21 contains values that relate to the generation of a
first operational signal that is output when the power key is
pressed. The second field 22 contains values that relate to the
generation of a second operational signal that is output when the
exit key is pressed.
[0043] Field 21 includes two semicolon-delimited subfields. The
first semicolon-delimited subfield "D:1,C:0000,K:KEY_POWER" is a
subfield that contains multiple comma-delimited subsubfields. The
first subsubfield contains "D:1". This indicates that field 21 is
for device "D1". As defined above in field 18, device D1 is
"DEVICE_VCR". The second subsubfield contains "C:0000". This
indicates that field 21 is for codeset number "0000". The third
subsubfield is a key identification subsubfield of value
"K:KEY_POWER". This subsubfield indicates that field 21 is for the
function "KEY_POWER". The "KEY_POWER" function, as set forth above,
defines what happens when the key "POWER" is pressed.
[0044] The second semicolon-delimited subfield includes numerous
comma delimited subsubfields. A first set of the subsubfields is a
"signal characteristic information" set of subsubfields. (This
"set" of subsubfields is also referred to using the general term
"field" in this patent document in order to simplify claim
terminology. Accordingly, one field may be contained in another
field. Not all fields are asterisk delimited.)
[0045] The "signal characteristic information" in the example is
"9,9,RF,IR". The "9,9" denotes the carrier on time, and carrier off
time, respectively. During a mark portion of an operational signal,
the operational signal is not actually at a digital high for the
entire duration of the mark portion, but rather is modulated on and
off rapidly at what is called the "carrier" frequency. The first
"9" designates the number of time units that the carrier is high
during one cycle of the carrier. The second "9" designates the
number of time units that the carrier is low during one cycle of
the carrier. Accordingly, "9,9" designates a 50/50 duty cycle
carrier having a total period of 18 time units.
[0046] The "RF" indicates that the operational signal is a "repeat
frame". The term "repeat frame" means that a frame as defined by
the following mark/space values is repeated multiple times. There
are different types of repeat frames. One type of repeat frame is
an "infinite repeat frame". The term infinite repeat means that the
frame is repeated over and over as long as the key is held pressed
down by the user of the remote control device. Another type of
repeat frame is a repeat frame that only repeats a specified number
of times. If, for example, the operational signal that corresponds
to field 21 were a repeat frame that was to repeat twice, then the
"RF" designating "repeat frame" would be followed by a
comma-delimited "2R". The "2R" would designate that the repeat
frame was to be repeated twice regardless of how long the key is
pressed. If the frame is only to appear once in the operational
signal, then the frame is termed a non-repeat frame. A non-repeat
frame is designated with the comma-delimited value "NR". In the
example of operational signal of field 21, the frame is an infinite
repeat frame. This is designated by the "IR" that follows the "RF"
designator.
[0047] The next comma-delimited values of the semicolon-delimited
subfield are mark/space information values. The various mark/space
values are comma-delimited. (These mark/space information values
are referred to together using the general term "field" in this
patent document in order to simply claim terminology. Accordingly,
one field may be contained in another field. Not all fields are
asterisk delimited.)
[0048] The first "M4000" indicates a mark of a duration of 4000
time units. The second "S4000" indicates a space of a duration of
4000 time units. When the key "POWER" is pressed, the operational
signal includes a frame that has a series of mark and space times
that correspond to the string of mark and space values in the
mark/space information.
[0049] In the example of the operational signal to be output when
the "POWER" key is pressed, all the frames of the operational
signal are to be the same. In some operational signals, however,
there may be one or more "last" frames that are different than
preceding frames. A last frame is denoted by a separate
semicolon-delimited subfield. The separate semicolon-delimited
subfield starts with carrier on/off information and ends with
mark/space information. The fact that the subfield describes a last
frame is designated by a "LF" in the "signal characteristic
information" subsubfields that define the frame. If, for example,
the last frame is to be repeated twice, then the "signal
characteristic information" may be "5,5,RF,2R,LF". The "5,5"
designate the carrier on/off timing. The "LF" indicates that the
frame is a last frame. The "RF" indicates that the frame is a
repeat frame. The "2R" indicates that the last frame is to be
repeated twice. Accordingly, multiple such semicolon-delimited
frame descriptions can be chained together to describe an
operational signal.
[0050] Although not illustrated in the figures, the signal
characteristic information can include a toggle control
subsubfield, and this information can reference descriptions of
toggle frames. In one example, "T0,XY" and "T1,XY" are two labels
that are usable to delimit toggle frames. The first time the
associated key is pressed, a first frame whose description follows
the first "T0,XY" label and precedes the second "T1,XY" label is
transmitted. The next time the key is pressed, the frame whose
description follows the second "T1,XY" label is transmitted. The
descriptions of each of the two frames is in accordance with the
manner of describing a frame as described above. The value "X" is
an ASCII character value that indicates the number of different
types of toggle frames there are. The "X" is a binary exponent such
that a "X" value of one indicates two toggle frames. The first
toggle frame is denoted by label "T0". The second toggle frame is
denoted by label "T1". The value "Y" is a one ASCII character value
that can have special predefined meanings that describe different
toggle frame types. In the present ordinary case where each time
the key is pressed the type of frame transmitted is alternated
between two different types of frames, the "Y" bit is zero.
[0051] In the example of FIG. 1, the designer of the remote control
device (the second entity) describes the new codeset in the PCCF
format as the format block of FIG. 3. This format block is then
communicated (for example, as an ASCII text file) to the
microcontroller supplier (the first entity). The first entity then
compresses and reformats the codeset information as represented by
block 4 in FIG. 1. One way that this compression and reformatting
can be done is set forth below.
[0052] When a key is pressed on the remote control device, the
microcontroller determines what action to take. This typically
involves identifying the appropriate signal characteristic
information and mark/space information for the operational signal
to be generated. The signal characteristic information and
mark/space information is stored at a location in memory. The
microcontroller uses the information in the first set of subfields
to generate a pointer to the appropriate information in memory. If,
for example, the remote control device were in the "VCR" mode where
the remote control device is to control the "DEVICE_VCR", and
codeset "0000" is to be used, and the "POWER" key was pressed, then
this information would be used to point to a location in memory
where the signal characteristic information and mark/space
information for field 21 is stored. Accordingly, the compression
and reformatting operation packs the various pairs of signal
characteristic and mark/space information fields together in memory
and builds a corresponding amount of pointer information that
allows the microcontroller to generate an offset pointer to the
appropriate place in memory depending on the key that was pressed
and the mode in which the remote control device is operating.
[0053] Although the signal characteristic information values appear
in PCCF format block 2 as ASCII character values so that they will
be readily readable by a human, the various values of the signal
characteristic information do not actually need eight bits or more
to convey the needed information. For example, the subsubfield that
designates whether the frame is a repeat frame or a non-repeat
frame can only have one of two values. The "RF" value corresponds
to one value. The "NR" value corresponds to the other value. When
the PCCF format block 2 is compressed and reformatted by block 4,
the value of this subsubfield is converted into a single-bit value.
In a similar way, the various other subsubfields of the signal
characteristic information are representable by smaller numbers of
bits than the ASCII character values consume in the PCCF format
block. There is a one-to-one correspondence between the various
ASCII subsubfields in the PCCF format block and the smaller
subsubfields in the compressed and reformatted information. The
rendering engine 5 includes a parser that knows where the various
smaller subsubfields are located in the compressed and reformatted
information.
[0054] Block 4 also compresses and reformats the mark/space
information. Rather than representing each mark space by multiple
human-readable ASCII characters such as "M4000", the same
information is representable by a table that contains the mark time
of 4000 units, and a pointer that points to the 4000 units entry in
the table. Block 4 creates a table containing one entry for each
different mark and space time value, and then replaces the
mark/space time values in the description of the operational signal
with a string of short pointers to entries in the table where the
actual mark and space times can be found. Because there is a
relatively small number of entries in the table, the pointers to
the table entries can have a relatively small number of bits. The
rendering engine 5 knows where the table is found in memory, and
uses the pointer values to obtain the actual mark and space times
in order to generate the operational signal.
[0055] Although a method is described above that involves
describing codesets of a codeset database in the PCCF format, and
then compressing, reformatting and encrypting the information
before it is communicated from the entity that compiled the codeset
database (the first entity) to another entity (the second entity),
the PCCF format can be used in another method to communicate PCCF
format blocks in the decipherable ASCII form from the first entity
to the second entity in uncompressed, unreformatted, and
unencrypted form. PCCF format blocks may, for example, be
communicated from one entity to another under license to protect
the proprietary nature of the codeset information contained in the
PCCF format blocks. The PCCF format is a codeset interchange format
of general utility.
[0056] Where the remote control device is a personal computer or
other device that has a relatively large amount of memory storage
space available to hold the codeset database information, storing
the codeset database information in the larger PCCF format blocks
may be preferable to storing the information in a compressed and
reformatted format that is not so readily read by a human. The
personal computer can be programmed to receive the PCCF format
blocks in ASCII form, to parse the PCCF format blocks to extract
the various values as explained above, and to generate operational
signals that are used to drive a transmitter (for example, an IR
LED) coupled to the personal computer. Alternatively, a
microcontroller having the rendering engine described above is
provided by the first entity for incorporation onto an expansion
card that is in turn incorporated into the personal computer remote
control device being designed by the second entity. Software that
executes on the personal computer is written to perform the
necessary compression and reformatting needed to convert the PCCF
format block ASCII information into a form that can be received and
understood by the rendering engine in the microcontroller. PCCF
format blocks in ASCII form are read out of memory in the personal
computer, are compressed and reformatted, and are supplied to the
microcontroller such that the microcontroller outputs operational
signals. The operational signals are supplied to a transmitter (for
example, an IR LED) to communicate the operational signals to an
electronic consumer device to be controlled.
[0057] Although the present invention has been described in
connection with certain specific embodiments for instructional
purposes, the present invention is not limited thereto. A file of
PCCF format blocks can include a machine-readable PCCF version
number field that indicates the version of the PCCF format that is
used in the file. The PCCF format field allows the PCCF format to
be revised and added to over time in an upward compatible way. The
file of PCCF format blocks can include human-readable text
information fields at various places in the file that set forth the
various fields of the PCCF format, how they can be delimited, and
what kind of information each of the fields can contain. A person
who has such a file can use the embedded text information fields to
determine how a particular codeset can be described in a way that
is consistent with the PCCF format of the file. The various fields
in the PCCF format block can be delimited with any particular ASCII
character or group of ASCII characters. The delimiter examples set
forth above involving asterisks, semicolons, and commas are just
examples. Although the codeset communication format is explained
above to be public, the codeset communication format may be
supplied to selected entities pursuant to an agreement that the
recipient use the knowledge of the format in a particular way only.
The codeset communication format may, in such an example, see
limited and controlled distribution and in this sense is not
public. The description of codesets in text in the PCCF format is
not, however, an incidental occurrence, but rather is to be more
widely practiced as a way for codeset information to be
communicated between an entity that maintains a codeset database
(for example, a microcontroller supplier) and other entities (for
example, remote control device designers) that license use of the
codeset database or parts of the codeset database. Accordingly,
various modifications, adaptations, and combinations of various
features of the described embodiments can be practiced without
departing from the scope of the invention as set forth in the
claims.
* * * * *