Method and a system for displaying product information on electronic labels
10031713 ยท 2018-07-24
Assignee
Inventors
Cpc classification
G09G2340/02
PHYSICS
G09G2340/14
PHYSICS
G09G2330/022
PHYSICS
G09G2370/022
PHYSICS
International classification
Abstract
A method for displaying product information on at least one electronic label having a graphic display and a data reception unit is disclosed. The method includes: generating, at a server connected to the label, an individual glyph corresponding to each different character or symbol of the product information; generating at least a display script comprising reference and position data of said glyphs in the product information; transmitting the display script to the label; broadcasting the individual glyphs; selecting and loading in the label individual glyphs corresponding to the reference data comprised in the display script and displaying the selected and loaded individual glyphs according to the position data comprised in the display script. A server, an electronic label and a sever thereof are also provided.
Claims
1. A method for displaying product information on a plurality of electronic labels, each having a graphic display the method comprising the steps of: (a) generating, at a server connected to the plurality of electronic labels, an individual glyph corresponding to each different character or symbol of the product information; (b) generating at least one display script comprising reference and position data of said glyphs in the product information for at least a first electronic label and a second electronic label of the plurality of labels, the reference data of said glyphs being common to the at least first and second electronic labels; (c2) unicasting a preamble to the first electronic label, said preamble comprising reference data of glyphs which are not shared between the at least first and second electronic labels; (c) multicasting the display script to the at least first and second electronic labels the label; (d) broadcasting the individual glyphs to the plurality of electronic labels; (e) determining which of the individual glyphs correspond to one of the reference data comprised in the display script and the preamble, and then selecting and downloading for each of the plurality of electronic labels only the individual glyphs corresponding to the reference data comprised in the display script and the preamble; and (f) for each of the plurality of electronic labels, displaying the selected and downloaded individual glyphs according to the position data comprised in the display script.
2. The method according to claim 1, wherein the display script further comprises kerning data of the glyphs in the product information.
3. The method according to claim 1, wherein a plurality of display scripts is generated at step (b), each display script corresponding to a part of the product information.
4. The method according to claim 1, wherein a plurality of labels is simultaneously involved, each label displaying a specific product information.
5. The method according to claim 1, wherein each label of the plurality of electronic labels is in a standby mode except during steps (c) and (d).
6. The method according to claim 5, wherein step (c) is implemented following a previous step of (c1) broadcasting a wakeup message for ending standby mode; and wherein a step of (d2) broadcasting a sleep message for going into standby mode is implemented following step (d).
7. The method according to claim 6, wherein step (d) is implemented following a previous step of (d1) broadcasting a synchronization message.
8. The method according to claim 1, wherein reference data of glyphs are coded in the preambles according to a Huffman algorithm.
9. A plurality of electronic labels, each comprising: a graphic display; a memory; wherein each of the electronic labels is configured to: receive and download into the memory: at least one multicasted display script comprising reference and position data of glyphs corresponding to the characters and symbols in a product information for at least a first electronic label and a second electronic label of the plurality of labels, the reference data of said glyphs being common to the at least first and second electronic labels; and receive a sequence of glyphs with their reference data and a unicasted preamble at the first electronic label, said preamble comprising reference data of glyphs which are not shared between the at least first and second electronic label; and a processing unit configured to: determine, for each glyph, if its reference data corresponds to one of the reference data downloaded in the memory; select and download into the memory only the individual glyphs corresponding to the reference data comprised in the display script and the preamble; and order the displaying by the graphic display of the selected and downloaded individual glyphs according to the position data of the display script.
10. A system comprising: a server comprising a processing unit configured to: generate, for each different character or symbol of a product information, an individual glyph; generate at least one display script comprising reference and position data of said glyphs in the product information for at least a first electronic label and a second electronic label of the plurality of labels, the reference data of said glyphs being common to the at least first and second electronic labels of a plurality of labels; multicasting the at least one display script to the first and second electronic labels; unicastinq a preamble to at least one of the first and second electronic labels, said preamble comprising reference data of glyphs which are not shared between the at least first and second electronic labels; broadcasting the glyphs to the plurality of electronic labels, and each of the plurality of electronic labels comprising: a graphic display, a memory, wherein each electronic label is configured to: receive and download into the memory the at least one multicasted display script comprising reference and position data of glyphs corresponding to the characters and symbols in a product information and the unicasted preamble; and receive a sequence of glyphs with their reference data; and an another processing unit, wherein the another processing unit of each electronic label is configured to determine, for each glyph, if its reference data corresponds to one of the reference data downloaded in the memory; select and download into the memory only the individual glyphs corresponding to the reference data comprised in the multicasted display script and the unicasted preamble; and order the displaying by the graphic display of the selected and downloaded individual glyphs according to the position data of the multicasted display script.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) The above and other objects, features and advantages of this invention will be apparent in the following detailed description of an illustrative embodiment thereof, with is to be read in connection with the accompanying drawings wherein:
(2)
(3)
(4)
(5)
(6)
DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
(7) Referring to the drawings, a method according to the invention will now be described.
(8) The method according to this invention comprises two parts. During the first part, product information to be displayed is processed by a server, and during the second part, which is actually represented in
(9) Generally, the server is a computer located in the store. On this computer, products are managed thanks to databases. Thus there are generally two components of the product information: consumer data, and management data.
(10) Consumer data constitute a large majority of the total data amount, but only a small part of the daily transferred data. They comprise price data and other data which are directly related to the product (mass, composition, brand . . . ), etc. These data hardly ever changes, except sometimes the price. A modification of such data is often manually done on the database, and immediately implies a transmission from the server to labels displaying product information related to this data.
(11) Management data change everyday. These data are essential to manage the store, but are generally not visible for the consumer. For example, they comprise stock information, barcode. Such data are updated every morning on the labels. Because of this daily transmission, the management data constitute the largest part of the transferred data amount.
(12) First Part: Processing of the Product Information by the Server
(13) The first step of the method according to the invention is the processing of the product information to be transmitted. Indeed, on the server, this information is a String, for example the word Grape, associated with a font, for example Arial 12. A program of the server, called the glyph unit, recognizes each character or symbol of the product information and separates them. For each character or symbol, a glyph is generated. To this end, the glyph may be directly drawn by a dedicated program. Else, there may be a table in the memory of the server, said table associating for each individual character the corresponding glyph. For a given character, there is a glyph per font.
(14) For our example, five glyphs are generated, as it can be seen in
(15) During a second step, a script coding reference and position data of the glyph is generated: the display script. The invention is not limited to a particular syntax of the display script. In the described preferred embodiment, the width w and the height h of every glyph are known. Thanks to these parameters and to the text of the product information, the position of each glyph (defined by the coordinates of its left upper corner) is calculated. In the case of the word Grape, G is a capital letter. Its corresponding glyph has to be shifted to the up with respect to the other glyphs (see
(16) Advantageously, the display script further comprises kerning data. The kerning is the process of adjusting spacing between consecutive characters. In a well-kerned font, the two-dimensional blank spaces between each pair of letters all have similar area. For example, in the case of the pair of letters VA, the two glyphs are slightly overlaying. Moreover, kerning enables ligatures (ex: encyclopaedia). Besides, it enables a better integration of a plurality of languages.
(17) When the position of every glyph in the information to be displayed is known, the corresponding display script is generated. An example of display script, and its corresponding product information is represented in
(18) For example, the weight 5000 G is coded by:
(19) TABLE-US-00001 MOVE_ABS 1 64 //positioning of the left upper corner PLACE_GLYPH 16 //5 MOVE_REL -1 0 //kerning between 5 and 0 PLACE_GLYPH 17 //0 PLACE_GLYPH 17 //0 PLACE_GLYPH 17 //0 MOVE_REL -36 18 //space between 0 and G PLACE_GLYPH 18 //G
(20) In this example, one display script is coding the whole product information to be displayed on a label, one such script is generated for each label. However, some parts of a product information are often common to a plurality of labels. In the example represented in
(21) Advantageously, such recurrent parts of the product information are coded by a specific display which is sent once, instead of being sent as a part of each display script.
(22) To reduce the bandwidth as much as possible, the product information is divided into a plurality of display script, each of them being shared with the maximum of labels.
(23) An example of such a division is represented in
(24) Second Part: Transmission of the Processed Product Information
(25) The at least one display script and the glyphs are then sent from the server to the labels.
(26) The labels can be connected to the server by any mean known by a man skilled in the art. For example, the server may be linked to ceiling antenna streamers, which will send radio waves to each label of the store. Else, a plurality of Infra Red emitter can be used. In combination with these transmission systems, each label comprises a data reception unit. This unit is adapted for receiving signals and making them understandable by the label.
(27) Three kinds of message transmissions are used in the method according to the invention: broadcast (every label receives the message), unicast (only one label receives the message) and multicast (a group of labels receives the message).
(28) Preferably, to reduce the energy consumption, the data reception units of the labels are off when no data is transmitted. This state of the label is called the standby mode. So in the advantageous embodiment described, the transmission protocol starts with a wakeup message. This wake up message is broadcast, and makes every label to switch its data reception unit on. However, the invention is not limited to an embodiment in which the labels are waken up and then shut off at each data transmission.
(29) In a first embodiment, display scripts are then directly sent to the labels. For each display script received, the list of indexes of glyphs to be retrieved is established by the label. This is the key point of the method according to the invention: each glyph has only to be sent once for the entire store. As the number of glyphs is not proportional to the number of labels but increases logarithmically, there is no more a maximum number of labels to be supported.
(30) Thanks to a second embodiment, corresponding to the diagram of
(31) The solution is to build only one display script ?????????? and to send separately the missing data in messages called preambles, such messages only containing lists of indexes of glyphs to be used for filling the blanks. In our example, the first preamble would contain the sequence [S, T, R, A, W, B, E, R, R, Y] and the second [B, L, A, C, K, B, E, R, R, Y].
(32) In this embodiment, preambles (which are inherent to only one label) are unicast. Display scripts, which can now be shared between labels once products information present similitaries, are then multicast. However, the invention is not limited to a method using preambles, only display scripts are required.
(33) Preambles may be used even more advantageously for still reducing redundant data. In our example, it could be noticed that the common part BERRY will be coded twice. The solution is to build a display script ?????BERRY and to send lighter preambles comprising only the missing data (i.e. only lists of indexes of unshared glyphs). The first preamble would thus contain the sequence [S, T, R, A, W] and the second [B, L, A, C, K].
(34) Before beginning to send the glyphs, a synchronization message is advantageously broadcast to indicate the labels that the glyphs are ready to be sent. Indeed, preambles and display scripts are sent consecutively, and queued by each label they are addressed to. Consequently, they sometimes need a few seconds to process these messages. The synchronization guarantees that no label will miss a glyph because of a lag. Such message is also not compulsory.
(35) Glyphs are then sent one by one. They are multicast, or even broadcast. Glyph messages are voluminous, because each glyph is a bitmap. Such glyph message begins with the index of the following glyph. The glyph itself is then coded, line by line. A 168 glyph, without compression but with interlaced lines has a typical weight of nearly 0.2 kb.
(36) With respect to preambles and display scripts, each label selects and downloads each glyph required. Other glyphs are ignored.
(37) When the last glyph has been sent, advantageously a sleep message is broadcast. This message commands the label to shut off their data reception unit until the next transmission.
(38) HELLO WORLD Example
(39) In this example, product information HELLO WORLD and WORLD HELLO are to be respectively displayed on two labels, following a method according to the invention.
(40) We assume that the pre-processing part has already been performed by the server. The display script is written and each glyph is generated:
(41) TABLE-US-00002 Glyph Hexadecimal index H 100 E 101 L 102 O 103 (Space) 104 W 105 R 106 D 107
(42) The first message to be sent is the wakeup message. This message is broadcast and announces that preambles and display scripts are following.
(43) TABLE-US-00003 Quartet number Data Comments 5 DFFFF Broadcast adress 6 1 Preamble/Display script mode (wakeup) 7 0 Padding 8 CRC4
(44) A quartet is a group of 4 bits (2 quartets make an octet). Each quartet corresponds to a hexadecimal character. The padding consists in adding meaningless bits at the end of the message to have a number of quartet which is multiple of 4 (i.e. a number of bits which is multiple of 16), to have a structure by blocks. CRC4 means Cyclic Redundancy Check 4-bits. This is a checksum aiming to detect transmission errors.
(45) The awaken labels are then waiting for preambles/display scripts. The two alternative embodiment previously described will be compared.
(46) Strategy with Display scripts only
(47) A display script is required per label. Both are unicast.
(48) Display Script of Label 1
(49) TABLE-US-00004 Quartet number Data Comments 5 FFFFE Label 1 adress 6 0 Display script start code 7 0 VERSION(0); 10 191 FILL FRAME(1); //White frame 12 80 USE_PEN(0); //Black pen 15 310 SET_GLYPH_OFFSET(0x10); 18 400 PLACE_GLYPH(0); //H 21 401 PLACE_GLYPH(1); //E 24 402 PLACE_GLYPH(2); //L 27 402 PLACE_GLYPH(2); //L 30 403 PLACE_GLYPH(3); //O 33 404 PLACE_GLYPH(4); // 36 405 PLACE_GLYPH(5); //W 39 403 PLACE_GLYPH(3); //O 42 406 PLACE_GLYPH(6); //R 45 402 PLACE_GLYPH(2); //L 48 407 PLACE_GLYPH(7); //D 50 00 Display script end code 52 00 Padding 56 CRC16
Display Script of Label 2
(50) TABLE-US-00005 Quartet number Data Comments 5 FFFF1 Label 2 adress 6 0 Display script start code 7 0 VERSION(0); 10 191 FILL_FRAME(1); //White frame 12 80 USE_PEN(0); //Black pen 15 310 SET_GLYPH_OFFSET(0x10); 18 405 PLACE_GLYPH(5); //W 21 403 PLACE_GLYPH(3); //O 24 406 PLACE_GLYPH(6); //R 27 402 PLACE_GLYPH(2); //L 30 407 PLACE_GLYPH(7); //D 33 404 PLACE_GLYPH(4); // 36 400 PLACE_GLYPH(0); //H 39 401 PLACE_GLYPH(1); //E 42 402 PLACE_GLYPH(2); //L 45 402 PLACE_GLYPH(2); //L 48 403 PLACE_GLYPH(3); //O 50 00 Display script end code 52 00 Padding 56 CRC16
(51) We note that 256 quartets are sent during this phase, i.e. 450 bits.
(52) Strategy preambles+Display scripts
(53) Preamble of Label 1
(54) TABLE-US-00006 Quartet number Data Comments 5 FFFFE Label 1 adress 6 0 H 7 1 E 8 2 L 9 2 L 10 3 O 11 4 12 5 W 13 3 O 14 6 R 15 2 L 16 7 D 19 000 Padding 20 CRC4
Preamble of Label 2
(55) TABLE-US-00007 Quartet number Data Comments 5 FFFF1 Label 2 adress 6 5 W 7 3 O 8 6 R 9 2 L 10 7 D 11 4 12 0 H 13 1 E 14 2 L 15 2 L 16 3 O 19 000 Padding 20 CRC4
(56) The two labels have received the sequence of the indexes of glyphs which do not share the same place in both labels. Indeed, as there is only one block of data in each product information, the best solution is to multicast a unique display script to reduce to the maximum the data volume to be transferred.
(57) TABLE-US-00008 Quartet number Data Comments 5 DFFFE Multicast adress 6 0 Display script start code 7 0 VERSION(0); 10 191 FILL_FRAME(1); //White frame 12 80 USE_PEN(0); //Black pen 15 310 SET_GLYPH_OFFSET(0x10); 16 5 PLACE_GLYPH CD( ); //H W 17 5 PLACE_GLYPH CD( ); //E O 18 5 PLACE_GLYPH CD( ); //L R 19 5 PLACE_GLYPH CD( ); //L L 20 5 PLACE_GLYPH CD( ); //O D 21 5 PLACE_GLYPH CD( ); // 22 5 PLACE_GLYPH CD( ); //W H 23 5 PLACE_GLYPH CD( ); //O E 24 5 PLACE_GLYPH CD( ); //R L 25 5 PLACE_GLYPH CD( ); //L L 26 5 PLACE_GLYPH CD( ); //D O 28 00 Display script end code 32 CRC16
(58) Than to the preambles, both HELLO WORLD and WORLD HELLO can be coded by a unique display script: missing letters are completed thanks to preambles.
(59) With this second strategy, only 20+20+32 quartets are sent during this phase, i.e. 280 bits. The data volume is reduced by a third.
(60) Whatever the strategy, labels are now synchronized before launching glyphs transmission.
(61) TABLE-US-00009 Quartet number Data Comments 5 DFFFF Broadcast adress 6 2 Glyph mode (Synchronization) 7 0 Padding 8 CRC4
(62) Glyphs are then broadcast one by one.
(63) Glyph H
(64) TABLE-US-00010 Quartet number Data Comments 5 DE100 Multicast adress/Glyph index 100 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 42 0100 0010 20 00 0100 0010 22 00 0100 0010 24 00 0100 0010 26 3B 0111 1110 28 00 0111 1110 30 3B 0100 0010 32 00 0100 0010 34 00 0100 0010 36 00 0100 0010 38 00 0100 0010 40 00 0100 0010 42 42 0000 0000 44 00 0000 0000 48 CRC16
Glyph E
(65) TABLE-US-00011 Quartet number Data Comments 5 DE101 Multicast adress/Glyph index 101 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 7E 0111 1110 20 3E 0100 0000 22 00 0100 0000 24 00 0100 0000 26 3C 0111 1100 28 00 0111 1100 30 3C 0100 0000 32 00 0100 0000 34 00 0100 0000 36 00 0100 0000 38 00 0100 0000 40 3E 0111 1110 42 7E 0000 0000 44 00 0000 0000 48 CRC16
Glyph L
(66) TABLE-US-00012 Quartet number Data Comments 5 DE102 Multicast adress/Glyph index 102 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 40 0100 0000 20 00 0100 0000 22 00 0100 0000 24 00 0100 0000 26 00 0100 0000 28 00 0100 0000 30 00 0100 0000 32 00 0100 0000 34 00 0100 0000 36 00 0100 0000 38 00 0100 0000 40 3E 0111 1110 42 7E 0000 0000 44 00 0000 0000 48 CRC16
Glyph O
(67) TABLE-US-00013 Quartet number Data Comments 5 DE103 Multicast adress/Glyph index 103 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 3C 0011 1100 20 7E 0100 0010 22 00 0100 0010 24 00 0100 0010 26 00 0100 0010 28 00 0100 0010 30 00 0100 0010 32 00 0100 0010 34 00 0100 0010 36 00 0100 0010 38 00 0100 0010 40 7E 0011 1100 42 3C 0000 0000 44 00 0000 0000 48 CRC16
Glyph
(68) TABLE-US-00014 Quartet number Data Comments 5 DE104 Multicast adress/Glyph index 104 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 00 0000 0000 20 00 0000 0000 22 00 0000 0000 24 00 0000 0000 26 00 0000 0000 28 00 0000 0000 30 00 0000 0000 32 00 0000 0000 34 00 0000 0000 36 00 0000 0000 38 00 0000 0000 40 00 0000 0000 42 00 0000 0000 44 00 0000 0000 48 CRC16
Glyph W
(69) TABLE-US-00015 Quartet number Data Comments 5 DE105 Multicast adress/Glyph index 105 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 42 0100 0010 20 00 0100 0010 22 00 0100 0010 24 18 0101 1010 26 00 0101 1010 28 00 0101 1010 30 00 0101 1010 32 00 0101 1010 34 00 0101 1010 36 00 0101 1010 38 3C 0110 0110 40 42 0010 0100 42 24 0000 0000 44 00 0000 0000 48 CRC16
Glyph R
(70) TABLE-US-00016 Quartet number Data Comments 5 DE106 Multicast adress/Glyph index 106 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 78 0111 1000 20 3C 0100 0100 22 00 0100 0100 24 00 0100 0100 26 00 0100 0100 28 3A 0111 1110 30 3C 0100 0010 32 00 0100 0010 34 00 0100 0010 36 00 0100 0010 38 00 0100 0010 40 00 0100 0010 42 42 0000 0000 44 00 0000 0000 48 CRC16
Glyph D
(71) TABLE-US-00017 Quartet number Data Comments 5 DE107 Multicast adress/Glyph index 107 6 2 Glyph sending 11 02008 Glyph width: 8/Glyph height: 16 12 0 No compression/Interlacing 1 line 14 00 0000 0000 16 00 0000 0000 18 78 0111 1000 20 3C 0100 0100 22 06 0100 0010 24 00 0100 0010 26 00 0100 0010 28 00 0100 0010 30 00 0100 0010 32 00 0100 0010 34 00 0100 0010 36 00 0100 0010 38 06 0100 0100 40 3C 0111 1000 42 78 0000 0000 44 00 0000 0000 48 CRC16
(72) With eight glyph, nearly 1.5 kbits have to be transferred.
(73) Finally, label are shut off for battery saving.
(74) TABLE-US-00018 Quartet number Data Comments 5 DFFFF Broadcast adress 6 F Sleep 7 0 Padding 8 CRC4
Additional Data Compression
(75) Advantageously, syntax of preamble may be further improved. Thus, in the HELLO WORLD example, each glyph index is coded by 4 bits in a preamble. Instead of using a constant-length code, it should be interesting to code some frequent glyphs with less than 4 bits. Algorithms enabling such data compression are known in the field of data coding under the name of Huffman algorithms. The idea is to build a table or a tree sorted with respect to the estimated probability of occurrence for each possible character, and to affect variable-length codes for indexes: given a glyph, the highest is its occurrence frequency, the shortest is its code. This method has been proved as the most efficient.
(76) If we apply a Huffman algorithm to the HELLO WORLD example, we can build this table:
(77) TABLE-US-00019 Glyph Huffman code H 010 E 011 L 100 O 00 W 101 R 110 D 111
(78) By using such compressed varible-length code instead of constant 4-bits code, only 16 quartets (20 quartets previously) would have to be transferred per preamble.
(79) Furthermore, data volume may still more reduced by using data compression algorithm on the glyphs, such as bitmap compression algorithms known to the skilled person.
(80) Server, Label, and System
(81) According to other aspects, the invention proposes a server and an electronic label, both being adapted for implementing the method according to the first aspect of the invention.
(82) To this, end, the server according to the second aspect of the invention comprises: a glyph unit configured for generating for each different character or symbol of a product information an individual glyph; a script generator unit configured for generating at least a display script comprising reference and position data of said glyphs in the product information to be displayed in at least one electronic label; a data emitting unit configured for transmitting the glyphs and the at least one display script to at least one electronic label.
(83) The electronic label according to the third aspect of the invention comprises a graphic display (in other words a pixel array display, as already explained), a processing unit, a memory, a data reception unit, and is characterized in that: the data reception unit is configured to receive and load into the memory at least one display script comprising reference and position data of glyphs corresponding to the characters and symbols in a product information to be displayed; the data reception unit is further configured to receive a sequence of glyphs with their reference data; the processing unit is configured to determine, for each glyph if its reference data corresponds to one of the reference data loaded in the memory, and to select the glyph and load it into the memory if it is the case; the processing unit is further configured to order the displaying by the graphic display of the selected and loaded individual glyphs according to the position data of the display script.
(84) The invention also proposes a system comprising in combination a server and at least one electronic label as previously described.