Secure indirect addressing
Summary by NHIP
Secure Indirect Addressing Method
The method communicates fragments by having a sender add a cryptographic message integrity code before a router modifies a group address into a specific receiver address. The sender and receiver share a common cryptographic key to compute the code and optionally encrypt content, allowing the receiver to restore the original address for verification.
Claim Score by NHIP
Abstract
An efficient solution for secure implementation of indirect addressing (IA) is described. IA may be used, for example, in networks of which the routing algorithms are not capable of multicast but also contain very constrained devices that, although requiring multicast, are not capable of repeated unicast. This ID is useful in wireless networks containing low-power low-cost devices.

Term
Term ended
Expired 8 September 2025, 1 year ago.
- Priority
- Filed
- Granted
- Expired
- Today
14 claims: 8 independent, 6 dependent
- 1A method of communicating a communication fragment, the communication fragment comprising a first target address reference identifying a group of target devices including at least one receiver device, the method comprising acts of:a sender device adding a cryptographic message integrity code to protect at least part of the communication fragment including the first target address resulting in a protected communication fragment, the sender device transmitting the protected communication fragment to a router device, the router device, for the at least one receiver device in the group of target devices, modifying the first target address reference into an address reference of the at least one receiver device, while maintaining the cryptographic message integrity code unchanged resulting in a modified protected communication fragment, and subsequently forwarding the modified protected communication fragment to the at least one receiver device, the at least one receiver device receiving the modified protected communication fragment, and the at least one receiver device restoring the protected communication fragment including substituting the first target address for the address reference of the at least one receiver device to allow verification of the protected communication fragment using the cryptographic message integrity code.
- 8A router device being arranged to route a communication fragment from a sender device towards a receiver device, the communication fragment comprising a first target address reference identifying a group of at least one receiver device, the router device comprising:receiving means being arranged to receive the communication fragment, comprising a first address reference identifying the group of at least one receiver device, the communication fragment including the first target address at least partly being protected by a cryptographic message integrity code, modifying means being arranged to modify the communication fragment, by replacing the first target address reference by an address reference identifying the at least one receiver device, while maintaining the cryptographic message integrity code unchanged resulting in a modified communication fragment, and transmitting means to transmit the modified communication fragment to the at least one receiver device.
- 9A receiver device being arranged to receive a modified communication fragment originating from a transmitter device through a router device, the modified communication fragment comprising a cryptographic message integrity code and an address identifying the receiver device, the modified communication fragment and the cryptographic message integrity code being derived from a communication fragment comprising a first target address reference identifying a group of at least one receiver device, the receiver device comprising:receiving means being arranged to receive the modified communication fragment, restoring means being arranged to restore the communication fragment that was used to compute the cryptographic message integrity code by modifying the address reference of the at least one receiver device into the first target address reference, and verification means being arranged to verify the communication fragment using the cryptographic message integrity code.
- 10A method of communicating a communication fragment, comprising acts of:a sender device assembling the communication fragment, the communication fragment including a first target address reference identifying a group of at least one receiver device, adding a cryptographic message integrity code to protect at least part of the communication fragment including the first target address resulting in a protected communication fragment, and transmitting the protected communication fragment to a router device, the router device, for the at least one receiver device in the group of at least one receiver device, modifying the first target address reference into an address reference of the at least one receiver device, while maintaining the cryptographic message integrity code unchanged resulting in a modified protected communication fragment, and subsequently forwarding the modified protected communication fragment to the at least one receiver device, the at least one receiver device receiving the modified protected communication fragment, and the at least one receiver device restoring the protected communication fragment including modifying the address reference of at least one receiver device into the first target address to verify of the protected communication fragment using the cryptographic message integrity code.
- 11A router device for routing a communication fragment from a sender device towards a receiver device, the router device comprising:a receiver arranged to receive the communication fragment from the sending device, the communications fragment comprising a first target address reference identifying a group of at least one receiver device, the communication fragment including the first target address at least partly being protected by a cryptographic message integrity code, a processor programmed to modify the communication fragment, by replacing the first target address reference by an address reference identifying the at least one receiver device, while maintaining the cryptographic message integrity code unchanged resulting in a modified communication fragment, and a transmitter arranged to transmit the modified communication fragment to the at least one receiver device.
- 12Broadest claimClaim Score 63, broad(NHIP)A receiver device for receiving a modified communication fragment originating from a transmitter device through a router device, the receiver device comprising:a receiver arranged to receive the modified communication fragment, the modified communication fragment comprising a cryptographic message integrity code and an address reference of the receiver device, the modified communication fragment and the cryptographic message integrity code being derived from a communication fragment comprising a first target address reference identifying a group of at least one receiver device, and a processor programmed to restore the communication fragment that was used to compute the cryptographic message integrity code by modifying the address reference of the at least one receiver device into the first target address reference, and to verify the communication fragment using the cryptographic message integrity code.
- 13A system comprising:a router device being arranged to route a communication fragment from a sender device towards a receiver device, the router device including: first receiving means being arranged to receive the communication fragment, comprising a first target address reference identifying a group of at least one receiver device, the communication fragment including the first target address at least partly being protected by a cryptographic message integrity code, modifying means being arranged to modify the communication fragment, by replacing the first target address reference by an address reference referring to the at least one receiver device, while maintaining the cryptographic message integrity code unchanged resulting in a modified communication fragment, and transmitting means to transmit the modified communication fragment to the at least one receiver device;a receiver device being arranged to receive the modified communication fragment originating from a transmitter device through the router device, the receiver device including: second receiving means being arranged to receive the modified communication fragment from the routing device, restoring means being arranged to restore the communication fragment that was used to compute the cryptographic message integrity code by modifying the address reference of the at least one receiver device into the first target address reference, and verification means being arranged to verify the communication fragment using the cryptographic message integrity code.
- 14A system for communicating a communication fragment, the system comprising:a sender device adapted for adding a cryptographic message integrity code to protect at least part of the communication fragment including a first target address resulting in a protected communication fragment, the communication fragment comprising the first target address reference identifying a group of at least one receiver device, and for transmitting the protected communication fragment to a router device, the router device, for the at least one receiver device, being adapted for modifying the first target address reference into an address reference of the at least one receiver device, while maintaining the cryptographic message integrity code unchanged resulting in a modified protected communication fragment, and subsequently forwarding the modified protected communication fragment to the at least one receiver device, and the at least one receiver device being adapted for receiving the modified protected communication fragment, and restoring the communication fragment including modifying the address reference of at least one receiver device into the first target address to allow verification of the communication fragment using the cryptographic message integrity code.
Independent claims8
45 paragraphs, as filed
0001This is a continuation of prior application Ser. No. 10/562,543 filed Dec. 28, 2005 which issued as U.S. Pat. No. 8,015,413 on Sep. 6, 2011 and is incorporated by reference herein and which is the National Stage of International Application No. PCT/IB2004/051066, filed Jun. 30, 2004, which claims priority of foreign application EP 03101998 filed Jul. 3, 2003.
0002The invention relates to a method of communicating a communication fragment. The invention further relates to the corresponding sender device, router device, receiver device, system, and signal implementing this method.
0003In communication networks often the distinction is made between unicast, multicast and broadcast. Unicast is the situation where a single device (the sender device) sends a message to a single other device (the receiver device). In multicast, the sender device sends a message to a number (more than one, but not all) of receiver devices, while in broadcast, the sender device sends a message to all devices in the network.
0004While nearly all networks contain routing algorithms that support unicast, this is not always the case for multicast. When the routing algorithms do not support multicast and a single device still wants to address several devices, multicast can be achieved by repeated unicast.
0005However, the sender device might not be able or allowed to do repeated unicast due to, for example, power or cost constraints. An example is a wireless control network used to control lights in large public spaces. Here a single, cheap light switch must be capable of switching more than, say, 50 lights. It is obvious that many more application examples can be found.
0006A solution to this problem can be found in indirect addressing (IA). where a second device (the router device) is available in the vicinity of the sender device. The sender device will then send a single message to the router device which will subsequently perform repeated unicast.
0007However, problems are related to the security aspects of IA. For example, the application running on the sender device might want to encrypt its message using a cryptographic key K<sub>G </sub>known only to members of a group G. Further the sender device might want to apply a Message Integrity Code (MIC) on parts of the communication such as its own address ID<b>1</b> and the destination address G in the message also using K<sub>G</sub>. The result is that only the members of G (but not the router device) can read the message and receiving devices can verify if indeed the message is intended for them and if it was sent by the sender device ID<b>1</b>.
0008Communication protocols are commonly described using a layered, OSI-like stack. Part of this stack are, from bottom to top, the physical layer (PHY), the medium access control layer (MAC), the network layer (NWK) and the application layer (APL). Frames exchanged between equal layers on different devices consist of a header and a payload. A frame at level n in the stack is physically sent as the payload of a frame at layer n−1. The abbreviations to identify some of the fields in these headers are as follows: SRC for source address, DEST for destination address, and INF for information field.
0009A straightforward but inefficient solution to the problem would be to have the application layer compute a MIC on the message, and on its destination address and on its source address using the group key K<sub>G</sub>.
0010The NWK layer will then also add the NWK-DEST and NWK-SRC addresses, as they are usually required by the routing algorithms. It might further compute an additional MIC on these two NWK addresses. As compared to the solutions given above this will result in more overhead (one or two more addresses) and one additional MIC to be sent which makes this solution less efficient. A second drawback is that the APL level is concerned with verifying address information, a task which more naturally belongs at a lower layer.
0011It is therefore an object of the invention to provide a method that improves the efficiency of indirect addressing while providing security.
0012This object is realized by a method of communicating a communication fragment, the communication fragment comprising a first target address reference referring to a group of at least one receiver device, comprising the steps of:—a sender device adding a cryptographic message integrity code to protect at least part of the communication fragment,—the sender device transmitting the protected communication fragment to a router device,—the router device, for at least one receiver device in the group of target devices, modifying the first target address reference into an address of the at least one receiver device, while maintaining the unchanged cryptograph message integrity code, and subsequently forwarding the modified protected communication fragment to the at least one receiver device,—the at least one receiver device receiving the modified protected communication fragment,—the at least one receiver device restoring the original protected communication fragment in order to allow verification of the original protected communication fragment using the message integrity code.
0013For security reasons, the addressing information should be protected with a MIC using the key K<sub>G</sub>. However, the router device should be able to change the addressing information in order to do repeated unicast. Obviously, since G is protected by the MIC, it cannot simply be substituted by a target address to do repeated unicast: when the receiver device receives the communication fragment with the substituted address and it checks the MIC, it will find a mismatch because the protected information should contain G and not the receiver device ID. As a result, it will probably ignore the message.
0014The sender device therefore indicates the usage of indirect addressing by for example setting a special IA bit field in the message. (Alternatively, the router device may indicate the usage of indirect addressing by for example setting a special IA bit field in the message, after detecting, for example because the target address is a group identity, that indirect addressing is used). The addresses MAC-DEST and MAC-SRC indicate that a message is sent from ID<b>1</b> to ID<b>2</b>. The addresses NWK-DEST and NWK-SRC indicate that the final destination of the message is all the members in G (possibly except ID<b>1</b> itself) and that the message was sent by ID<b>1</b>. The NWK-INF field further indicates that the message is used in the context of indirect addressing (IA=1) and the application on ID<b>1</b> encrypted the string m using the group key K<sub>G </sub>(indicated by E<sub>KG</sub>(m)).
0015On receipt of the message from the sender device, the router device notices that it is an IA message by inspecting the IA bit in the NWK-INF field and it will perform a multiple unicast to all the members of group G (possibly except the sender device ID<b>1</b>). From its routing information (e.g. routing tables), the router device knows that a way to reach the receiver device is sending it to intermediate nodes. The router changes, for each receiver device, the NWK-DEST field from the entry G to the address of the receiver device ID, as intermediate hops are not aware of a group identity G and the unicast routing algorithms need a single, known device address as a final destination. Note further that, because of the replacement, the MIC and the protected information are no longer consistent. The receiver device upon receiving the message will replace the modified information, for example the receiver device ID by the group ID, and is subsequently able to verify the MIC. The receiver device should know the identity of all devices in G in order to perform this action. An alternative solution is that the sender device or the router device copies the group identity G somewhere in the communication fragment, for example in the NWK-INF field in the NWK frame. This way the receiver devices do not have to store the link between device identities and group identities and they can still substitute the group identity in the NWK-DEST field before verifying the MIC. In addition, multiple overlapping groups are supported in this manner.
0016The advantage of this solution is that the sender device only requires storing a very limited amount of information, and sending very short and few communication fragments. The activities of the router device (ID<b>2</b>) and intermediate hops are independent of the fact if the message by the sender device (here ID<b>1</b>) is secured or not. Only the group members and (of course) the router device need to be aware of indirect addressing; the intermediate nodes between the router device and the receiver devices are not aware of the indirect addressing mode. The router device need not be trusted with application data.
0017An advantageous implementation of the method according to the invention is described in claim <b>2</b>. Use of a single bit field IA to indicate the use of the indirect addressing mode is simple and efficient.
0018An advantageous implementation of the method according to the invention is described in claim <b>4</b>. Using a single common key both to encrypt the message content and to generate or verify the MIC results in an efficient implementation.
0019An advantageous implementation of the method according to the invention is described in claim <b>5</b>. The receiver device attempts multiple substitutions of the target address reference by the groups the receiver device is a member of. This way, the receiver device is able to find the group identity for which the MIC matches. This alleviates the need to add the group identity in the communication fragment, therefore optimizing the communication fragment length.
0020An advantageous implementation of the method according to the invention is described in claim <b>6</b>. This implementation allows the receiver device to restore the communication fragment without local information or without having to perform multiple attempts to find the matching group identity by storing or copying the original first target address reference into the modified protected communication fragment.
0021The sender device, router device, receiver device, system, and signal according to the invention are characterized as described in claims <b>7</b>-<b>11</b>.
0022These and other aspects of the invention will be further described by way of example and with reference to the schematic drawings in which:
0023<figref idref="DRAWINGS">FIG. 1</figref> shows an exploded view of a message at the MAC layer for a four-layer protocol stack,
0024<figref idref="DRAWINGS">FIG. 2</figref> shows a schematic example of indirect addressing,
0025<figref idref="DRAWINGS">FIG. 3</figref> shows a detailed example of indirect addressing, and
0026<figref idref="DRAWINGS">FIG. 4</figref> shows the message formats on the MAC level during indirect addressing
0027Throughout the figures, same reference numerals indicate similar or corresponding features. Some of the features indicated in the drawings are typically implemented in software, and as such represent software entities, such as software modules or objects.
0028Communication protocols are commonly described using a layered, OSI-like stack. An example stack comprises, from bottom to top, the physical layer (PHY), the medium access control layer (MAC), the network layer (NWK) and the application layer (APL). Frames exchanged between equal layers on different devices consist of a header and a payload and a frame at level n in the stack is physically sent as the payload of a frame at layer n−1. Thus, considering the top three layers in this four-layer protocol stack, <figref idref="DRAWINGS">FIG. 1</figref> illustrates a message <b>100</b> sent by the MAC layer.
0029In many cases there is a close relation between the addresses at the APL layer and at the NWK layer which makes it possible to leave out duplicated address information in the APL layer in order to arrive at an efficient solution. Address information at the NWK layer can usually not be omitted because it is required by the routing algorithms. Because the APL addresses are usually equal to the NWK addresses or can be derived easily, they are not always present in order to reduce the size of the message.
0030The INF fields contain information for a receiving device on the different layers on what kind of information is present in the rest of the message and how it should be treated. For example, the MAC-INF field might indicate that the MAC-PAYLOAD is encrypted. This will show to the receiving device that it must first decrypt the payload before dealing with it further. Also, the NWK-INF field might indicate that the received frame is generated in the context of indirect addressing and should be treated accordingly. Indirect addressing is schematically depicted in <figref idref="DRAWINGS">FIG. 2</figref>. ID<b>1</b>, sender device <b>201</b>, member of the group G={ID<b>1</b>, ID<b>3</b>, ID<b>4</b>, ID<b>5</b>}, sends a message <b>211</b> containing the final destination address G, its own address ID<b>1</b> and a string m (i.e. the actual information to be sent to the group) to ID<b>2</b>, the router device <b>202</b>. When ID<b>2</b> receives the message and notices that the message coming from ID<b>1</b> is intended for the group G, it will forward the message to ID<b>3</b><b>203</b>, ID<b>4</b><b>204</b> and ID<b>5</b><b>205</b> whose addresses it found in, for example, a pairing table <b>212</b>.
0031As a security measure, the application running on ID<b>1</b> generating the string m, might want to encrypt m using a cryptographic key K<sub>G </sub>known only to members of G. Further it might want to apply a Message Integrity Code (MIC) on its own address ID<b>1</b> and the destination address G in the message also using K<sub>G</sub>. The result of these security measures is that only the members of G (but not the router device) can read the message and receiving devices can verify if indeed the message is intended for them and if it was sent by ID<b>1</b>.
0032As the router device ID<b>2</b> is not trusted by ID<b>1</b>, ID<b>2</b> has no access to the key K<sub>G</sub>. However, the router node should be able to change the addressing information on the NWK level in order to perform repeated unicast. Since G is protected by the MIC, it cannot simply be substituted by ID<b>3</b>, ID<b>4</b> and ID<b>5</b> to do repeated unicast: when the receiving devices ID<b>3</b>, ID<b>4</b> and ID<b>5</b> check the MIC, they will find a mismatch because the protected information should contain G and not ID<b>3</b>, ID<b>4</b> or ID<b>5</b>, respectively. As a result, they will ignore the message.
0033As illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, ID<b>1</b> knows the cryptographic group key K<sub>G</sub>, the identity of the group G (but not necessarily the addresses of all the group members) and the address of its router device ID<b>2</b>. Router device ID<b>2</b> knows or is able to retrieve the addresses of all the members of G.
0034ID<b>1</b> sends the message <b>301</b> to the router ID<b>2</b><b>302</b> that, on the MAC level, will look like the message <b>401</b> in <figref idref="DRAWINGS">FIG. 4</figref> where, as compared to <figref idref="DRAWINGS">FIG. 1</figref>, fields that are not relevant in the current explanation are omitted for clarity. The addresses MAC-DEST and MAC-SRC indicate that a message is sent from ID<b>1</b> to ID<b>2</b>. The addresses NWK-DEST and NWK-SRC indicate that the final destination of the message is all members of G (possibly except ID<b>1</b> itself) and that the message was sent by ID<b>1</b>. The NWK-INF field further indicates that it concerns a message in the context of indirect addressing (IA=1) and the application on ID<b>1</b> encrypted the string m using the group key K<sub>G </sub>(indicated by E<sub>KG</sub>(m)) in APL-PAYLOAD. A dark gray background in a message means that its content is protected by a MIC using K<sub>G</sub>. As an alternative solution, the application on the sender device ID<b>1</b> can decide not to encrypt m but only do add a MIC. In this case, E<sub>KG</sub>(m) in message <b>401</b> will be replaced by m.
0035On receipt of the message from sender device ID<b>1</b><b>301</b>, router device ID<b>2</b><b>302</b> notices that it is an IA message by inspecting the IA bit in the NWK-INF field and it will perform a multiple unicast to all the members of G <b>303</b>,<b>304</b>,<b>305</b> (again, possibly except ID<b>1</b>). In an alternative implementation, on receipt of a message from a sender device, the router device, rather than checking the IA bit in the NWK-INF field, can also check the NWK-DEST field to conclude that the sender device sent an IA message.
0036Subsequently, the router device substitutes in the NWK-DEST field the value G by ID<b>3</b>, ID<b>4</b> and ID<b>5</b>, respectively, hereby ignoring the resulting inconsistency between the information protected by the MIC and the MIC itself. The router is allowed to make other modifications to the protected information as long as the receiver devices are capable of undoing the modifications before verifying the MIC.
0037As an example, the unicast message from ID<b>2</b> to ID<b>4</b> is described. From its routing information (e.g. routing tables), ID<b>2</b> knows that a way to reach ID<b>4</b> is sending it to ID<b>7</b> after which multiple hops might follow, as indicated in <figref idref="DRAWINGS">FIG. 3</figref>. The message ID<b>2</b> sends to ID<b>7</b> on the MAC level will then look like message <b>402</b> in <figref idref="DRAWINGS">FIG. 4</figref>. In the NWK-DEST field the entry G is replaced by ID<b>4</b>, because intermediate hops are not aware of a group identity G and the unicast routing algorithms need a single, known device address as a final destination. Because of this replacement, the MIC and the protected information are no longer consistent which is indicated by the striped/light gray background of the NWK-DEST field.
0038After possibly more hops, a message <b>313</b> finally ends up at ID<b>4</b>. If the one but last hop address was ID<b>8</b> (see <figref idref="DRAWINGS">FIG. 3</figref>), the message looks like message <b>403</b>. If ID<b>4</b> knows the identity of all devices in G it can receive a message from (indicated by ID<b>1</b>→{G} in <figref idref="DRAWINGS">FIG. 3</figref>), then, by inspecting the NWK-SRC field in the received message, ID<b>4</b> can obtain the group identity G. Before verifying the MIC on the message using K<sub>G</sub>, it will replace ID<b>4</b> in the NWK-DEST field by G.
0039Although this solution is very efficient in simple situations, there will be problems in more complicated situations. It might be, for example, that both ID<b>1</b> and ID<b>4</b> are a member of G but also of a different group G′ in which ID<b>1</b> is also a sender device. Upon receipt of a message, ID<b>4</b> is not sure if it should replace ID<b>4</b> in the NWK-DEST field by G or by G′ because it will have stored ID<b>1</b>→{G, G′}. Clearly ID<b>4</b> can try all the group identities in the list belonging to ID<b>1</b> until a recomputed MIC matches the MIC in the message. An alternative solution is that ID copies the group identity G in the NWK frame, for example in the NWK-INF field. This way the receiver devices do not have to store the link between device identities and group identities and they can still substitute the group identity in the NWK-DEST field before verifying the MIC. The cost is that in this case, the messages to be sent will be longer.
0040As an alternative solution to storing G in the NWK frame, the receiver device can attempt multiple substitutions of the target address reference by the groups the receiver device and sender device are a member of. This way, the receiver device is able to find the group identity for which the MIC matches. This alleviates the need to add the group identity in the communication fragment, therefore optimizing the communication fragment length.
0041The advantages of the method according to the invention are as summarized below. The sender device only requires storing a very limited amount of information. The activities of the router device (ID<b>2</b>) and intermediate hops are independent of the fact if the message by the sender device (here ID<b>1</b>) is secured or not. Only the group members and (of course) the router device are aware of a group G. There is only one bit overhead in the messages (the IA bit in the NWK-INF field). The receiver devices have to store the links between device IDs and group IDs, which can be done efficiently. The router device need not be trusted with application data.
0042It is clear to a person skilled in the art that minor modifications to the solutions presented above still constitute the same solutions.
0043For example, to further reduce the size of the message from sender device ID<b>1</b> to router device ID<b>2</b>, the identity of the router (ID<b>2</b>) might be omitted if it is clear from context. Receiving a message from ID<b>1</b>, the router might deduce from context that it must forward the message to the group G. This reduces even further the required amount of storage on the sender device and the length of the message to be sent by the sender device.
0044As a second example, to further reduce the size of the message from sender device ID<b>1</b> to router device ID<b>2</b>, the sender device identity ID<b>1</b> can be omitted from the group definition on the router device (here G={ID<b>1</b>, ID<b>3</b>, ID<b>4</b>, ID<b>5</b>}), if the router device is only acting as router for a single device in G (in this case ID<b>1</b>),
0045Alternatives are possible. In the description above, “comprising” does not exclude other elements or steps, “a” or “an” does not exclude a plurality, and a single processor or other unit may also fulfill the functions of several means recited in the claims.
6 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| WO0062503A2 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| EP0902569A1 | Cites | European Patent Office (EPO) | Applicant |
| EP1032178A1 | Cites | European Patent Office (EPO) | Applicant |
| JP2000261429A | Cites | Japan | Applicant |
| US2002042875A1 | Cites | United States of America | Search report |
| US2002078353A1 | Cites | United States of America | Applicant |
| US2003223402A1 | Cites | United States of America | Applicant |
| US2004015570A1 | Cites | United States of America | Search report |
| US2004029576A1 | Cites | United States of America | Search report |
| US2004193876A1 | Cites | United States of America | Search report |
| US2005220125A1 | Cites | United States of America | Applicant |
| US2007014237A1 | Cites | United States of America | Search report |
| US2007115977A1 | Cites | United States of America | Search report |
| US2007260879A1 | Cites | United States of America | Search report |
| US2011010547A1 | Cites | United States of America | Search report |
| US5455865A | Cites | United States of America | Search report |
| US5748736A | Cites | United States of America | Search report |
| US5917820A | Cites | United States of America | Search report |
| US6092191A | Cites | United States of America | Search report |
| US6507908B1 | Cites | United States of America | Search report |
| US6643773B1 | Cites | United States of America | Search report |
| US6725276B1 | Cites | United States of America | Search report |
| US6795917B1 | Cites | United States of America | Search report |
| US6842456B1 | Cites | United States of America | Applicant |
| US6957346B1 | Cites | United States of America | Search report |
| US7106730B1 | Cites | United States of America | Applicant |
| US7240199B2 | Cites | United States of America | Search report |
| US7328009B2 | Cites | United States of America | Applicant |
| US7340509B2 | Cites | United States of America | Search report |
| US7441043B1 | Cites | United States of America | Search report |
| US7734913B2 | Cites | United States of America | Search report |
| US8245028B2 | Cites | United States of America | Search report |
| US8245032B2 | Cites | United States of America | Search report |
| US8301882B2 | Cites | United States of America | Search report |
| US8302160B2 | Cites | United States of America | Search report |
| US8555056B2 | Cites | United States of America | Search report |
| US8769267B2 | Cites | United States of America | Search report |
| US20020042875A1 | Cites | United States of America | Search report |
| US20020078353A1 | Cites | United States of America | Applicant |
| US20030223402A1 | Cites | United States of America | Applicant |
| US20040015570A1 | Cites | United States of America | Search report |
| US20040029576A1 | Cites | United States of America | Search report |
| US20040193876A1 | Cites | United States of America | Search report |
| US20050220125A1 | Cites | United States of America | Applicant |
| US20070014237A1 | Cites | United States of America | Search report |
| US20070115977A1 | Cites | United States of America | Search report |
| US20070260879A1 | Cites | United States of America | Search report |
| US20110010547A1 | Cites | United States of America | Search report |
| EP902569A1 | Cites | European Patent Office (EPO) | Applicant |
| JP20000261429A | Cites | Japan | Applicant |
| WO62503A1 | Cites | World Intellectual Property Organization (WIPO) | Applicant |
| Peter S. Kruus, et al, “Techniques and Issues in Multicast Security”, IEEE, Oct. 1998, pp. 1028-1032, XP0100307977. | Non-patent | – | Applicant |
| Peter S. Kruus, et al, "Techniques and Issues in Multicast Security", IEEE, Oct. 1998, pp. 1028-1032, XP0100307977. | Non-patent | – | Applicant |
16 members in 9 offices
Priority claims4
| Document | Office | Kind | Date |
|---|---|---|---|
| 03101998 | European Patent Office (EPO) | – | |
| 03101998 | European Patent Office (EPO) | A | |
| 2004051066 | International Bureau of the World Intellectual Property Organization (WIPO) | W | |
| 56254305 | United States of America | A |
Members16
| Document | Office | Kind | |
|---|---|---|---|
| WO2005004393A1 | World Intellectual Property Organization (WIPO) | A1 | |
| KR20060028482A | Republic of Korea | A | |
| EP1645071A1 | European Patent Office (EPO) | A1 | |
| US2006156015A1 | United States of America | A1 | |
| CN1816998A | China | A | |
| JP2007519277A | Japan | A | |
| CN1816998B | China | B | |
| EP1645071B1 | European Patent Office (EPO) | B1 | |
| JP4606410B2 | Japan | B2 | |
| AT492958T | Austria | T | |
| ATE492958T1 | Austria | T1 | |
| DE602004030685D1 | Germany | D1 | |
| US2011035597A1 | United States of America | A1 | |
| ES2358111T3 | Spain | T3 | |
| US8015413B2 | United States of America | B2 | |
| US9015488B2This record | United States of America | B2 |
68 transactions on the USPTO file
Allowed after 2 non-final rejections, 2 final rejections and 1 RCE.
- Non-final rejections
- 2
- Final rejections
- 2
- RCEs
- 1
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Expire PatentEXP. | EXP. | |
| Maintenance Fee Reminder MailedREM. | REM. | |
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Paralegal or electronic terminal disclaimer approvedP574 | P574 | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Terminal Disclaimer FiledDIST | DIST | |
| Response after Final ActionA.NE | A.NE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Preliminary AmendmentA.PE | A.PE | |
| Preliminary AmendmentA.PE | A.PE | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail Advisory Action (PTOL - 303)MCTAV | MCTAV | |
| Advisory Action (PTOL-303)CTAV | CTAV | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Final ActionA.NE | A.NE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Final Rejection (PTOL - 326)Final rejectionMCTFR | MCTFR | |
| Final RejectionFinal rejectionCTFR | CTFR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Request for Foreign Priority (Priority Papers May Be Included)RQPR | RQPR | |
| Application Is Now CompleteCOMP | COMP | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Preliminary AmendmentA.PE | A.PE | |
| Request from applicant for the USPTO to retrieve the Priority DocumentPDREQUST | PDREQUST | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
9 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapsed due to failure to pay maintenance feeLapsedFP | FP | |
| Lapse for failure to pay maintenance feesLapsedPATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYLAPS | LAPS | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| AssignmentAS | AS | |
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF |
Numbers
- Publication
- 9015488
- Application
- 12908034
Titles
- English
- Secure indirect addressing
Patent term adjustment
- A delay
- +435 daysthe office missed an examination deadline
- Net adjustment
- 435 days
Classification
- CPC, 4
- H04L45/00
- H04L12/22
- H04L12/18
- H04L45/16
- IPC, 7
- H04L29 06
- H04L12 701
- H04L12 18
- H04L12 761
- H04L12 56
- H04L45 00
- H04L45 16