Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
  • H04W60/02—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration by periodical registration
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/09—Mapping addresses
  • H04L61/10—Mapping addresses of different types
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
  • G07C5/00—Registering or indicating the working of vehicles
  • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L61/00—Network arrangements, protocols or services for addressing or naming
  • H04L61/50—Address allocation
  • H04L61/5053—Lease time; Renewal aspects
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W84/00—Network topologies
  • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

• the present invention generally relates to the field of vehicles and the transmission of vehicle related data between vehicles and vehicle support centres. More particularly the invention relates to a method, vehicle communication handling device, vehicle and computer program product for simplifying connection of a vehicle support centre to the vehicle as well as to a method, vehicle support centre and computer program product for sending information to a vehicle.
• the type of data transmitted can typically be transport order data, like for instance information sent from the support centre to the vehicle regarding where and when different shipments are to be made. It is also of interest to transfer for instance driver log information, like information about the activities that a driver has performed during the execution of a transport order, like when he has been active, rested etc and where he is located at different instances in time. It is furthermore of interest to also supply information about the vehicle to the vehicle support centre in order to for instance in time identify possible faults and malfunctions in the vehicle.
• US2004/0090950 describes the sending of data to and from vehicles using MDPP messages.
• a vehicle sends a registration MDPP message to a base system and receives a confirmation signal in an MDDP data packet. Retransmission of the MDPP message is performed.
• Such data packets do however use the identity of the radio communication device (MIN number) for communication between network and vehicle.
• MIN number the identity of the radio communication device
• WO2004/070503 describes queuing of messages that are sent between applications via a network.
• One object of the present invention is to solve the problem of simplifying for a vehicle support centre to be able to contact a vehicle that is communicating with a connectionless communication protocol via a network supporting packet based communication.
• this object is achieved by method, provided in a vehicle equipped with a radio communication unit, for simplifying connection of a vehicle support centre to the vehicle using a radio communication network supporting packet based communication, comprising the steps of: requesting communication from the network, and sending a registration packet according to a connectionless communication protocol to the vehicle support centre, wherein the steps of requesting communication and sending a registration packet are performed regularly at a fixed interval, where the interval is short enough for the probability to be high of each registration packet receiving a dynamic source connectivity identity that is the same.
• this object is also achieved by method of sending information to a vehicle from a vehicle support centre using a radio communication network supporting packet based communication and comprising the steps of: receiving registration packets addressed to the vehicle support centre according to a connectionless communication protocol, each including a dynamic connectivity identity as a source identity in the packet, which registration packets have been sent at a fixed interval, the interval being short enough for the probability to be high of each registration packet receiving a dynamic source connectivity identity that is the same, when receiving the first registration packet having a new dynamic connectivity identity, associating the dynamic connectivity identity with the vehicle, when receiving at least some registration packets, checking if there is any data to be sent to the vehicle in a vehicle data queue, and sending such possible data in a return packet with the dynamic connectivity identity as destination address.
• a vehicle communication handling device for simplifying connection of a vehicle support centre to a vehicle via a radio communication network supporting packet based communication
• a vehicle communication handling device for simplifying connection of a vehicle support centre to a vehicle via a radio communication network supporting packet based communication
• a radio communication unit for communication using the radio communication network
• a control unit arranged to order the radio communication unit to request communication from the network, and order the communication unit to send a registration packet according to a connectionless communication protocol to the vehicle support centre
• the control unit is arranged to order the radio communication unit to perform said requesting of communication and sending of registration packets repeatedly at a fixed interval, the interval being short enough for the probability to be high of each registration packet receiving a dynamic source connectivity identity that is the same
• the vehicle communication handling device is provided in a vehicle.
• a vehicle support centre for sending information to a vehicle using a radio communication network supporting packet based communication and comprising: a communication unit arranged to receive registration packets addressed to the vehicle support centre according to a connectionless communication protocol and each including a dynamic connectivity identity as a source identity in the packets, which registration packets have been sent regularly at a fixed interval (REGI), the interval being short enough for the probability to be high of each registration packet receiving a dynamic source connectivity identity that is the same, and a server arranged to, associate the dynamic connectivity identity with the vehicle, when receiving a first registration packet having a new dynamic connectivity identity, check if there is any data to be sent to the vehicle in a vehicle data queue, when receiving at least some registration packets, and order the communication unit to send a return packet with such possible data with the dynamic connectivity identity as destination address
• a communication unit arranged to receive registration packets addressed to the vehicle support centre according to a connectionless communication protocol and each including a dynamic connectivity identity as a source identity in the packets, which registration packets have been sent regularly at a
• this object is also achieved by a computer program product for simplifying connection of a vehicle support centre to a vehicle using a radio communication network supporting packet based communication and comprising computer program code to make a computer perform, when said computer program code is loaded therein: at least order the requesting of communication from the network, and at least order the sending of a registration packet according to a connectionless communication protocol to the vehicle support centre, wherein the requesting and sending are performed repeatedly at a fixed interval, where the interval is short enough for the probability to be high of each registration packet receiving a dynamic source connectivity identity that is the same.
• this object is also achieved by a computer program product for sending information to a vehicle from a vehicle support centre using a radio communication network supporting packet based communication and comprising computer program code to make a computer perform, when said computer program code is loaded therein: receive registrations packets addressed to the vehicle support centre according to a connectionless communication protocol and each including a dynamic connectivity identity as a source identity in the packet, which registration packets have been sent at a fixed interval, where the interval is short enough for the probability to be high of each registration packet receiving a dynamic source connectivity identity that is the same, associate the dynamic connectivity identity with the vehicle, when receiving a first registration packet having a new dynamic connectivity identity, check if there is any data to be sent to the vehicle in a vehicle data queue, when receiving at least some registration packets, and at least order the sending of such possible data with the dynamic connectivity identity as destination address
• a return message window associated with each registration packet in which return packets can be received using the same dynamic connectivity identity. This has the advantage of making sure that the vehicle support centre can use the dynamic connectivity identity for sending data.
• acknowledgement of receipt of at least the first registration packet is requested. This has the advantage of ensuring that the vehicle can receive data packets from the vehicle support centre or that an alternative channel is to be opened.
• the identity of the radio communication network is determined and a network indicator is set in registration packets in dependence of this network identity. This has the advantage of allowing both the vehicle and vehicle support centre to change communication settings depending on the network.
• a radio communication network message of a type using an identity associated with the radio communication unit as destination identity is sent from the vehicle support centre to the vehicle, where the message comprises at least a static connectivity identity of the vehicle support centre to be used in communication using said connectionless communication protocol and a preferred interval to be used for registration packets.
• At least some registration packets also include at least one status indicator indicating the status of an application provided in the vehicle. This has the advantage of allowing the vehicle support centre to limit transmission of data to data that is actually needed for the vehicle.
• the invention has a number of advantages.
• the vehicle support centre is able to continuously send data as response to registration packets to the vehicle as long as the vehicle is connected to the network.
• the amount of data transmitted is furthermore low because of the connectionless protocol.
• fig. 1 schematically shows a vehicle connected to a vehicle support centre via a radio communication network
• fig. 2 shows a block schematic of parts within the vehicle that are relevant for the present invention
• fig. 3 shows a block schematic of parts within the vehicle support centre that are relevant for the present invention
• fig. 4 schematically shows a message sent from the vehicle support centre to the vehicle in order to initiate data transfer capabilities in the vehicle
• fig. 5 shows the general outline of data packets sent from vehicle to vehicle support centre and vice versa
• fig. 6 shows a flow chart of a method according to the present invention provided in the vehicle
• fig. 7 shows a flow chart of a method according to the present invention provided in the vehicle support centre
• fig. 8 schematically shows a computer program product in the form of a CD ROM disc comprising computer program code for performing the present invention.
• the present invention is directed towards providing communication between a vehicle and a vehicle support centre.
• This type of communication might be necessary.
• One such situation is for the transmission of transport orders to the vehicle from the vehicle support centre and the reporting of the status of the vehicle and driver in relation to that order.
• Other situations are the transmission of driver log information between the vehicle and vehicle support centre and the report of status concerning the vehicle, like for instance how it is working and if any components are faulty etc.
• Fig. 1 shows a block schematic of a vehicle 10 connected to a vehicle support centre 16 via a wireless network 14.
• the network 14 is in an exemplifying embodiment a GPRS network, why the vehicle communicates with this network via a base station 12.
• a first message M sent from the vehicle support centre 16 to the vehicle 10 a registration packet Pl sent from the vehicle to the vehicle support centre and a response packet P2 sent from the vehicle support centre 16 to the vehicle 10 are also shown.
• the nature of these messages and packets will be described shortly.
• the network does not need to be a GPRS network, but can be any other type of wireless network supporting address based data communication, like for instance a UMTS network or a wireless LAN network.
• Fig. 2 shows a block schematic of the vehicle 10 and some parts of it that are relevant to the present invention.
• the vehicle includes a data bus 20, which may be a so called CAN bus.
• a data bus 20 there are connected a number of processors 22, 24 and 26, which are arranged for measuring different types of properties of the vehicle, like for instance engine temperature, lambda sensor and other typical vehicle data like odometer data.
• a vehicle communication handling device 28 indicated by a dashed box, which handles some of the functionality according to the present invention.
• the vehicle communication handling device 28 includes a control unit 30 that interfaces with the bus 20.
• a positioning unit 32 which here is in the form of a GPS receiver, a radio communication unit 36 for communication with the network, a local storage 34 as well as a user input unit 38 for receiving inputs from a user, normally the operator of the vehicle.
• the user input unit 38 is preferably provided in the form of a keyboard or a keypad preferably in the form of a touch screen, but also other types of input are feasible, like for instance the use of voice inputs and voice recognition.
• the user input unit 38 can be provided in a separate handheld device like for instance in a hand held computer like a personal digital assistant.
• the processors 22, 24, 26, the positioning unit 32 and the user input unit 38 all allow the provision of data of one or more types to the control unit 30.
• the control unit 30 furthermore provides a number of applications, where one application is a positioning application providing positioning information and other applications are various types of vehicle handling applications, like a driver log application, a transport order application and a vehicle performance application.
• Fig. 3 schematically shows a block schematic of the vehicle support centre 16.
• the vehicle support centre 16 includes a communication unit 44 for communication with the network.
• the communication unit 44 may or may not be a radio communication unit depending on how the interface to the wireless network is realised. Since the centre 16 is stationary it is however not necessary that this part of the connection to the network is wireless.
• the communication unit 44 is connected to a server 42, which is in turn connected to a storage 48 and to an input unit 46.
• the input unit 46 can be provided in the form of a web page, which a shipping firm may access in order to enter and receive data. It can also or additionally include a keyboard or similar input means.
• the input unit 46 allows the provision of data of one or more types to the server 42 and is therefore also termed data providing unit.
• the present invention aims to reduce the communication considerably, which lowers the cost and also allows a more efficient data transmission reducing the load of the network.
• a connectionless communication protocol and preferably one lacking security mechanisms.
• UDP which is a preferred protocol according to the present invention.
• UDP UDP
• this protocol the amount of data communicated in a network is kept to a minimum.
• connections set up which means that the vehicle support centre does not have to keep several parallel connections. This is important especially if there are several vehicles to keep track of.
• this protocol does not have any safety mechanisms, i.e. there is no guarantee by the network that packets are delivered as they should. Transmission of data is therefore also fast.
• the vehicle support centre does according to a preferred variation of the present invention have a fixed connectivity identity for packet based communication, which is here a fixed IP address and a fixed port number, while the vehicle communication handling device because of its mobile nature would receive a dynamic connectivity identity, i.e. a dynamic IP address and port number, from the network.
• a dynamic connectivity identity i.e. a dynamic IP address and port number
• the normal procedure would then be to connect to a DNS server with a query regarding the vehicle communication handling device and in return get an IP address and port number, which may then be used for communication.
• the query may for instance be based on the phone number associated with the radio communication unit.
• One object of the present invention is therefore to simplify for a vehicle support centre to be able to transmit data to a vehicle when using connectionless packet based communication.
• fig. 1 - 3 shows the structure of an initiating message
• fig. 5 which shows the data packet structure used
• fig. 6 which shows a flow chart of a method performed in the vehicle as well as fig. 7 which shows a flow chart of a corresponding method performed in the vehicle support centre.
• the server 42 of the vehicle support centre 16 Before any communication can take place, the server 42 of the vehicle support centre 16 generates a configuration message M and orders the communication unit 44 to send this message M to the vehicle 10, step 74.
• This configuration message M is of a type using an identity associated with the radio communication unit 36 as destination identity. This identity is normally the phone number associated with the radio communication unit 36.
• the message M is an SMS message. It can however be an MMS message or a similar message sent in the radio communication network 14.
• the message M comprises information that is of interest for the control unit 30 when communicating with the vehicle support centre.
• the message includes the static IP address AS of the communication unit 44 as well as an associated port number PS of the communication unit 44 of the vehicle support centre 16.
• the reporting intervals REPI are intervals that are to be used in standard reporting of events in the vehicle, when a normal packet connection is provided, while the fall back times specify intervals to be used for reporting when an alternative, less preferred network is at hand, for instance one where communication costs are higher.
• the message M is received by the radio communication unit 36 of the vehicle, step 50, forwarded to the control unit 30, which goes on and stores the message in a safe part of the storage 34, i.e. a part that cannot be manipulated by neither the user of the vehicle nor by other people.
• the vehicle is set for reporting events that occur in the vehicle. Typically the position is to be reported about every 5 minutes, while other applications may have a longer interval when reporting information. It is now a simple task for the vehicle to report information relating to the different applications using a packet based communication mechanism. However the vehicle support centre can still not easily get hold of the vehicle.
• control unit 30 of the vehicle communication handling device 28 first sets an interval timer to a time defined by the registration interval REGI specified in the message M. It thereafter orders the radio communication unit 36 to request communication from the network, step 56. It then generates the payload PL of a registration packet Pl set out according to fig. 4, step 58.
• the payload then includes a vehicle identifier in the form of a unit identity UID, which is typically the telephone number associated with the radio communication unit 36 (although other ways are feasible as long as they uniquely identity the vehicle), a time stamp TS, status indications STATUS for the applications (are they running or not), a packet or sequence number PNR for the packet in question as well as CRC code.
• the payload is normally encrypted.
• the message structure also has a data field DATA and a first acknowledgement flag AFl. However for these registration messages this data field DATA is normally empty. The flag AFl will be described later on.
• the control unit 30 then checks if this is the first or last registration message Pl created or not, step 60, and if it is, a second acknowledgement flag AF2 is set in the payload, step 62. A last packet is also denoted a deregistration packet.
• the flag AF2 indicates that the control unit 30 expects to receive an acknowledgement of receipt of this packet by the vehicle support centre 16.
• the control unit 30 then orders the radio communication unit 36 to send the registration packet Pl, step 64.
• the radio communication unit then sets the destination address and destination port number Al + Pl of the packet Pl to be the fixed address and port number AS and PS associated with the communication unit 44 as well as a source identity A2 + P2, which a node in the network 14 will change into a connectivity identity in the form of a dynamic address and port number AD + PD that is assigned to the radio communication unit 36. If the packet Pl was not the first or last packet, step 60, the control unit 30 would order the radio communication unit 36 to send the packet Pl immediately without setting the flag AF2. The control unit 30 at the same time orders the radio communication unit 36 to provide a return packet window in which it can receive return packets from the vehicle support centre 16.
• control unit 30 checks if the packet was the last, step 66, and if it was, the method is ended, step 68, while if it was not the timer is decreased, step 70.
• the control unit 30 then waits until the timer reaches the value of zero, step 72, and then goes back and restores the timer interval, step 54, and sends a new registration packet, step 64.
• the timing interval is set such that the probability is high that the network will associate the same connectivity identity, here in the form of an IP address and a port number, to the vehicle for all such registration packets sent during the same session.
• This connectivity identity is the one which the vehicle support centre sees for communication purposes. The advantage of this will be discussed in more detail later.
• the timing interval is thus adapted to how fast the network is in assigning new addresses and port numbers to the same entity requesting communication.
• the timing interval has according to some embodiments a shortest length of 30 seconds and has preferably a length of approximately 60 seconds.
• the return packet window is in some embodiments between 15 and 60 seconds wide and preferably approximately 30 seconds wide. Normally the first and last packet includes a request for acknowledgement, whereas the registration packets in-between do not include such a request. If no acknowledgement is received, the control unit selects an alternative communication mode and for instance one using messages like SMS or MMS messages. For this type of communication there is no need of registration packets. Here also the timing interval might be different.
• the registration packets are furthermore sent independently of if there is data to be transmitted to the vehicle support centre or not. In fact they do not have to include any application data at all. In this way the size of registration packets is also limited.
• the control unit does normally also send packets reporting events in applications, like for instance the position. This information is sent using the same type of packets, but where the data field includes some kind of report data. As mentioned before these packets have a different timing interval.
• the sending might also be event driven, i.e. initiated by some event taking place in the vehicle.
• Each sending of application data from the vehicle to the vehicle support centre is furthermore accompanied by a request for acknowledgment of reception of the data. Since this information is sent in addition to the registration packets, they will also receive the same IP address and port number assignment as the registration packets. However they can as an alternative be combined with or replace a pure registration packet.
• the communication unit 44 of the vehicle support centre 16 thus receives a number of registration packets Pl where normally the first and the last one include an acknowledgement flag AF2.
• the communication unit 44 receives a first packet of the type Pl, step 76, which is forwarded to the server 42.
• the server 42 compares the dynamic IP number and port number AD + PD of the packet Pl associated with the sender with a possible earlier identity associated with the user identity UID, which is stored in storage 48, step 78. If the current association does not exist, step 80, the new connectivity identity is associated with the unit identity UID, step 82, and stored in storage 48.
• the server checks if there is any data intended for the vehicle support centre in the registration packet Pl and if there were, this data is stored in the server in a data section associated with the user identity UID, step 83. Thereafter the server 42 checks if the packet Pl includes a request for acknowledgement, step 84. If the association existed in step 80, the server immediately checks if there was a request for acknowledgment, i.e. if the AF2 flag was set. If there was such an acknowledgement request, which would exist for the first registration packet sent, a response packet P2, which is here an acknowledgement packet, is generated, step 86. Also this packet looks essentially the same as the packet in fig. 5.
• the server sets the first acknowledgement flag AFl, which indicates that it is a response to the received packet Pl, step 88.
• This response packets P2 is furthermore sent using the same packet or sequence number PNR as was used for the registration packet Pl including the request for acknowledgement. Normally the data field DATA does not include any data here.
• the destination address and port numbers Al+Pl are furthermore set to the assigned address and port number AD+PD, while the source address and port number A2+P2 are set to fixed address and port number AS+PS of the vehicle support centre 16.
• the server 42 then orders the communication unit 44 to send the packet P2, step 90.
• the response packet P2 is here sent fast enough to for the vehicle 10 to be able to receive it in the return packet window.
• the server 42 checks if the received packet Pl was the last packet or not, step 92. If it was the method is ended, step 94, while if it was not the vehicle support centre goes back to step 76 for receiving a new registration packet Pl. If the registration packet Pl did not include a request for acknowledgement, the server 42 goes on and checks if it has data that needs to be sent to the vehicle, step 96. If it has no data to transmit, it goes back and awaits new registration packets Pl, step 76, while if it has it generates a response packet P2, step 98. It then checks what applications are running by looking at the status field STATUS and selects data to be transmitted from an output queue. Data to be transmitted may then only be data directed towards applications that are running in the vehicle.
• the server then adds this data to the data field DATA from the output queue, step 100. Thereafter the response packet P2 is sent, step 102, and the vehicle support centre 16 yet again awaits new registration packets Pl, step 76.
• the response packet P2 is also normally provided with a request for acknowledgment, so that the vehicle acknowledges the reception of this data. In this way the vehicle support centre is able to continuously send data as response to these registration packets to the vehicle as long as the vehicle is connected to the network. Because of the status field, the vehicle support centre can furthermore directly see what application it can send data to or not.
• the radio communication unit of the vehicle can determine the identity of the network it is connected to and provide this information to the control unit.
• the control unit may then include a network indicator setting in the registration packets. This setting may be used to indicate if the network is a preferred network, like a home network or another network, like a roamed network. Because the costs associated with data transfer in a roamed network are normally much higher than in a home network and because of other reasons, such as because times for assigning dynamic connectivity identities are different, timing and reporting intervals may be set differently for such a network than for a home network. In fact some type of data may not be sent at all.
• the server and the control unit decide what data to send or not to send. It is then also possible for the vehicle to change communication strategy and move over to a message based communication, like for instance using SMS. Such changes may furthermore be necessitated by the fact that a current network does not support packet based communication. For each such change it is thus possible to change reporting intervals for the applications or to temporarily refrain from reporting until the vehicle once again moves to a preferred network. It is furthermore not necessary to use two acknowledgement flags. It is possible to combine their functions using only one flag.
• the vehicle support centre may set a flag indicating this. Once the vehicle receives a packet with this indicator it will resend the packet in question. If the situation prevails, communication is then stopped and the vehicle support centre sends a new message M with a new correct encryption key.
• the use of the configuration message allows the vehicle support centre to provide the vehicle with the communication information it needs in a flexible manner. This measure furthermore allows the configuration data to be updated if changes are made. However the invention is possible to practise without this configuration message.
• the information therein can as an alternative be provided in the vehicle beforehand.
• a first advantage is that the amount of data transmitted is reduced.
• the amount of data communicated in a network is kept to a minimum.
• the radio communication unit in the vehicle is preferably provided as a radio communication module, having the communication abilities of a cellular phone. Also the communication unit of the vehicle support centre can be provided in this way.
• the storages can be provided in the form of standard memories, but are preferably flash memories or hard discs..
• the control unit in the vehicle and the server are each preferably provided in the form of a processor with program memories comprising computer program code which performs the method according to the invention.
• the program code can also be provided in the form of a computer program product, which may be in the form of a portable memory device, like a CD ROM disc.
• a portable memory device like a CD ROM disc.
• One such disc 104 is schematically shown in fig. 8. It may also be provided in the form of pure computer program code, which may be provided on a server and downloaded from there to a vehicle or the server of the vehicle support centre.
• the network is normally a GSM-type of network or a GPRS network. It is of course also possible that the network is a UMTS network.
• the protocol used is not limited to UDP, but any other connectionless packet type may be used. Therefore the present invention is only to be limited by the following claims.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Health & Medical Sciences (AREA)
• Computing Systems (AREA)
• General Health & Medical Sciences (AREA)
• Medical Informatics (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=37771861

Family Applications (1)

Country Status (4)

Cited By (1)

Citations (8)

• 2005
  • 2005-08-25 SE SE0501883A patent/SE532087C2/sv not_active IP Right Cessation
• 2006
  • 2006-07-07 EP EP06758107.4A patent/EP1938561A4/en not_active Withdrawn
  • 2006-07-07 BR BRPI0615118-3A patent/BRPI0615118A2/pt not_active Application Discontinuation
  • 2006-07-07 WO PCT/SE2006/050250 patent/WO2007024188A1/en active Application Filing

Patent Citations (8)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events