Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1069—Session establishment or de-establishment
• • 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
• • 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/45—Network directories; Name-to-address mapping
  • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
• • 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
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1073—Registration or de-registration
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1083—In-session procedures
  • H04L65/1094—Inter-user-equipment sessions transfer or sharing
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/1066—Session management
  • H04L65/1101—Session protocols
  • H04L65/1104—Session initiation protocol [SIP]
• • 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/14—Session management
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
  • H04L67/63—Routing a service request depending on the request content or context
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/10—Architectures or entities
  • H04L65/1016—IP multimedia subsystem [IMS]

Definitions

• the invention relates to a method for instance identification in a communication system, in particular in an Internet Protocol Multimedia Subsystem (IMS), and also to a corresponding network control element.
• IMS Internet Protocol Multimedia Subsystem
• the invention relates to SIP (Session Initiation Protocol) and the 3GPP (Third Generation Partnership Project) IMS (Internet Protocol (IP) Multimedia Subsystem) .
• SIP Session Initiation Protocol
• 3GPP Third Generation Partnership Project
• IMS Internet Protocol (IP) Multimedia Subsystem
• Fig. 1 The basic situation for this is shown in Fig. 1. Now, it is assumed that a first user, John (A) has 2 devices, for example mobile phones, (UE-Al and UE-A2) which are registered to the same Public User ID (e.g., sip:john@nokia.com) , and there is ongoing session between John and a second user, Mary (B), having the device UE-B.
• UE-Al and UE-A2 2 devices, for example mobile phones, (UE-Al and UE-A2) which are registered to the same Public User ID (e.g., sip:john@nokia.com)
• Mary (B) having the device UE-B.
• the REFER method indicates that the recipient (identified by the Request-URI) should contact a third party using the contact information provided in the request.
• the REFER message includes a Refer-to header field which provides a URL to a reference.
• the Refer-to field indicates the Public User ID of user A, which is indicated in Fig. 1 by X.
• the transferred session needs to go to that particular device (namely UE-Al) John was holding in his hands, not the other one.
• the ' SIP INVITE message issued from UE-C in response to receiving the REFER message may go to both user entities of user A, as indicated by messages 2a and 2b in Fig. 1.
• the transferred session can be routed to any of John's device, or to all of them (parallel forking) , or to any set of them.
• A has multiple devices registered to the same Public User ID.
• a and B have an ongoing SIP session.
• B wants to add C to the same session.
• B needs to establish an ad-hoc conference and invite A and C to this conference session.
• B may send REFER to the Conference application server, which then sends INVITE to A and C. Again, this INVITE might be routed to any device A has registered to the Public User ID.
• GRUU Globally Routable User Agent Uniform Resource Identifier
• This object is solved by a method for instance identification in a Session Initiation Protocol (SIP) used in a communication system, comprising the steps of using a Globally Routable User Agent Uniform Resource Identifier (GRUU) for uniquely identifying an instance, wherein the Globally Routable User Agent Uniform Resource Identifier (GRUU) is related to a serving network control element of the instance.
• SIP Session Initiation Protocol
• a generic control element comprising means for identifying an instance by using a Globally Routable User Agent Uniform Resource Identifier (GRUU) in a Session Initiation Protocol (SIP), wherein the Globally Routable User Agent Uniform Resource Identifier (GRUU) is related to a serving network control element of the instance.
• GRUU Globally Routable User Agent Uniform Resource Identifier
• SIP Session Initiation Protocol
• GRUU Globally Routable UA (User Agent) URI (Uniform Resource Identifier)
• GRUU Globally Routable UA (User Agent) URI (Uniform Resource Identifier)
• IMS Internet Engineering Task Force
• the GRUU points to the user equipment (i.e., the instance device) instead of the user. Therefore, the invention proposes the use of GRUU in 3GPP IMS and similar networks.
• the invention provides solutions for the problems created due to distributed architectures such as IMS. That is, in particular, the GRUU is related to the serving network control element of the instance in order to surely routing messages/communication to the instance through the serving network control element.
• the GRUU it is possible to reliably start a session with a user equipment of a user, which comprises several user entities identified by the same Public User ID.
• Fig. 1 shows a scenario where an ongoing SIP session is to be transferred to another party
• Fig. 2 shows a flowchart illustrating a procedure of generating a GRUU according to a first embodiment of the invention
• Fig. 3 shows a signal flow illustrating GRUU generation and GRUU usage according to the first embodiment of the invention
• Fig. 4 shows a signal flow illustrating GRUU generation and GRUU usage according to a second embodiment of the invention
• Fig. 5 shows a signal flow illustrating GRUU generation and GRUU usage according to a third embodiment of the invention.
• Fig. 6 shows a signal flow illustrating GRUU generation and GRUU usage according to a fourth embodiment of the invention.
• GRUU According to a first embodiment of the invention, GRUU
• UE user equipment
• GRUU is a unique instance ID that is globally routable.
• a GRUU is generated by the SIP registrar (e.g., S-CSCF) at registration time, and transported to the User Agent (e.g., UE) for its usage at a later time.
• S-CSCF S-CSCF
• UE User Agent
• a GRUU points to the UE instead of the user.
• a GRUU is valid for the duration of the UE registration.
• the definition of GRUU is as follows:
• a GRUU is a SIP URI that has a specific set of characteristics:
• Global It can be used by any UAC (User Agent Client) connected to the Internet. In that regard, it is like an Address-Of-Record (AOR) for a user.
• AOR Address-Of-Record
• Temporally Scoped It may be temporally scoped. In that regard, it is not like an Address-Of-Record (AOR) for a user.
• AOR Address-Of-Record
• the general assumption is that an AOR for a user is valid so long as the user resides within that domain (of course, policies can be imposed to limit its validity, but that is not the default case) .
• a GRUU has a limited lifetime by default. It can never be valid for longer than the duration of the registration of the UA to which it is bound. For example, if a PC registers to the SIP network, a GRUU for this PC is only valid as long as the PC is registered. If the PC unregisters, the GRUU is invalid; calls to it would result in a 404 (Not Found) message. If the PC comes back, the GRUU will be valid once more. Furthermore, it will frequently be the case that the GRUU has a lifetime shorter than the duration of the registration.
• Instance Routing It routes to a specific UA instance, and never forks. In that regard, it is unlike an Address- Of-Record.
• routing logic is applied in proxies to deliver the call to one or more UAs. That logic can result in a different routing decision based on the time- of-day, or the identity of the caller.
• the routing logic is much more static. It has to cause the call to be delivered to a very specific UA instance. That UA instance has to be the same UA instance for any request sent to that GRUU. This does not mean that a GRUU represents a fundamentally different type of URI; it only means that the logic a proxy applies to a GRUU is going to generally be simpler than that it applies to a normal AOR.
• the GRUU can be used at any time to force routing of SIP signalling to the same instance running at the same device that requests the GRUU.
• This allows the UA to execute call transfer, ad-hoc conferences and presence based initiated communications with the guarantee that the execution will end up in the required device, out of a collection of possible devices that the user may be using.
• the other party will contact the GRUU and the network will route to this specific instance in this specific UE.
• any SIP (Session Initiation protocol) request addressed to a GRUU will make the I-CSCF (Interrogating Call/Session Control Function) to query the HSS asking for routing information.
• I-CSCF Interrogating Call/Session Control Function
• the GRUU effectively is a Temporary Public User Identity allocated to the combination of the real Public User Identity and contact address. Generating and informing the UE of a GRUU does not represent a problem in IMS. However, if at a later stage, the UE populates the Contact header field of a SIP request (e.g., INVITE) with a GRUU, the remote User Agent will use the GRUU to route further signalling, and perhaps execute any of the mentioned services (e.g., call transfer, ad-hoc conference, etc.) . This will not work in IMS, because a request that contains a GRUU in the Request-URI field will be received at an I-CSCF, which will send a Diameter query to the HSS requesting the address of the S-CSCF allocated to the user.
• a SIP request e.g., INVITE
• the remote User Agent will use the GRUU to route further signalling, and perhaps execute any of the mentioned services (e.g., call transfer,
• the HSS only contains a database of real Public User Identities, but is not aware of GRUUs. Therefore the HSS will return a
• Diameter code "User unknown” and the I-CSCF will generate a SIP 404 Not Found response. As a consequence, the call transfer, ad-hoc conference, or such service will fail.
• the GRUU is related to the S-CSCF (as an example for a serving network control element) of the UE. This is described later in more detail by referring to first to fourth embodiments.
• Refer- To contains 1) A's IP address 2) A's Public User ID 3) A's GRUU, as according to the present embodiment of the invention.
• user C After receiving the REFER message from user B, user C sends INVITE to the address indicated in the Refer-To header field.
• the INVITE request will be received by the S- CSCF where the user is registered.
• the S-CSCF will fork the request to any device user A has registered to the
• Public User ID or to all of them, or to any set of them (in case there are more than two) , depending whether the IMS supports callee capabilities, what are the registered callee capabilities in the devices, and what are the caller preferences.
• the invention proposes the use of GRUU in 3GPP IMS and similar networks.
• the invention provides solutions for the problems created due to distributed architectures such as IMS.
• a S-CSCF Server Call/Session Control Function gets the registrations (REGISTER method) from UE-Al and UE-A2 (referring to the situation shown in Fig. 1), it allocates a GRUU for each of them. That is, when the S- CSCF receives the register message from UE-Al in step S21, it allocates a GRUUl for UE-Al in step S22. For this purpose, the S-CSCF generates a GRUU where the domain part is the user's home domain name, e.g., network.com.
• the user part must be unigue in this domain, and can be calculated as defined in GRUU Internet Draft document mentioned above (http://www.ietf.org/internet- drafts/draft-ietf-sip-gruu-01.txt) . Effectively, the GRUU is a temporarily scoped Public User ID allocated to the user.
• the S-CSCF submits the GRUU, i.e., GRUUl in this example, to the HSS (Home Subscriber Server) over the Cx interface as part of a Diameter SAR (Server-Assignment-Request) message. This is shown in step S23.
• the HSS binds the GRUUl to the Public User ID (step S24), which in turn is already bound to the S-CSCF allocated to the user.
• HSS can allocate the GRUU once it receives the registration notification from the S-CSCF. In this case, the HSS returns the GRUU to the S-CSCF in a
• Diameter SAA (Server-Assignment-Answer) response. That is, the S-CSCF and the HSS are both examples for a generic control element according to the invention.
• the S-CSCF generates a 200 OK response to the SIP REGISTER request.
• the response contains a new parameter in the Contact header field that conveys the allocated GRUU to the particular UA instance for the duration of the registration. This parameter is already defined in GRUU Internet draft mentioned above (step S25) .
• the S- CSCF sends the response to the UE-Al via the I-CSCF and the P-CSCF.
• step S24 the same procedure is carried out for the UE-A2, i.e., when a REGISTER request is received from UE-A2. That is, the S-CSCF allocates a second different GRUU to UE-A2. In step S24, then GRUU2 is bound to the same Public User ID of A in the HSS.
• the use of home network domain in the GRUU guarantees that initial requests are routed to an I-CSCF (Interrogating CSCF) located in the home network.
• I-CSCF Interrogating CSCF
• the I-CSCF uses the GRUU to query the HSS.
• the GRUU looks like any other Public User ID to the HSS, it is bound (perhaps indirectly, via a real Public User ID) to the S-CSCF allocated to the user.
• the HSS returns the address of the S-CSCF bound to the GRUU.
• the I-CSCF then forwards the SIP request to that S-CSCF.
• the S-CSCF is aware (from the registration procedure) of the route to the particular UE (in the example of Fig. 1, UE-Al) and the UE contact IP address.
• the S-CSCF populates this stored route set to the Route header field, as per regular SIP procedures.
• the S-CSCF populates the Request-URI with the UE contact IP address and forwards the INVITE request to the next hop address.
• the INVITE request originated by user C is sent to the correct UE of user A, namely UE-Al.
• the INVITE request 2a is sent, and the INVITE request 2a is never sent to any UE (including the wrong user equipment UE-A2) .
• a SIP REGISTER request is forwarded from the UE to the P-CSCF (Proxy CSCF), which forwards the SIP REGISTER request to the I-CSCF in the home network of the user in message (3-2) .
• the I-CSCF performs an authorization procedure, namely forwards a UAR (User Authorization Request) to the HSS in message (3-3), and the HSS responds with a UAA (User Authorization Answer) in message (3-4) . After this is done, the I-CSCF forwards the SIP REGISTER request to the S-CSCF in message (3-5) .
• UAR User Authorization Request
• UAA User Authorization Answer
• the S-CSCF creates a GRUU that follows the pattern of the real Public User Identity, e.g., sip: [crypto- GRUU] ⁇ homel.net.
• the part "crypto GRUU” is also referred to in the following as GRUU user part and is a unique identifier for the instance in the domain of the user.
• the second part "homel.net” is an example for a home domain of the user.
• the S-CSCF is responsible to maintain a state of the GRUU in the HSS.
• the S-CSCF when the S-CSCF creates a GRUU, it informs the HSS (with a Diameter request) of the newly created GRUU, so the HSS is able to map the GRUU to the S-CSCF that keeps the user registration state. Hence, the HSS binds the GRUU to the S-CSCF.
• Diameter SAR (Server Assignment Request) in message (3-6) to the HSS.
• the SAR message is extended to convey the GRUU.
• the HSS responds with a SAA command (Server Assignment Answer) in message (3-7) .
• SAA Service Assignment Answer
• the S-CSCF knows that the binding of the GRUU to the S-CSCF is performed, and sends a 200 OK message (3-8) to the I-CSCF, which is forwarded to the P- CSCF in message (3-9) and to the UE in message (3-10) .
• the GRUU generation is completed.
• the S-CSCF When the Public User Identity de-registers (explicitly or due to a registration expiration) , the S-CSCF also informs the HSS to remove any state associated to the GRUU.
• the I-CSCF executes the regular procedures, as also shown in the lower part of signal flow shown in Fig. 3. That is, upon receiving a SIP request (message 3-11), which can a SIP INVITE request (as shown by 2a in Fig. 1), the I-CSCF contacts the HSS to find out the address of the S-CSCF that keeps the registration state of the URI included in the Request- URI. That is, the I-CSCF sends a LIR (Location Information Request) containing the GRUU in message (3- 12) to the HSS.
• a SIP request messages 3-11
• SIP INVITE request as shown by 2a in Fig. 1
• LIR Location Information Request
• the HSS returns the address of the S-CSCF allocated to the GRUU in a LIA (Location Information Answer) (message 3-13) .
• the I-CSCF does not replace the GRUU contained in the Request-URI field of the INVITE request. Thereafter, the INVITE request (including the GRUU) is forwarded to the S-CSCF (message 3-14) .
• the S- CSCF finds the Contact UE out of the registration procedure of the GRUU, and then forwards the request to the P-CSCF (message 3-15) .
• the P-CSCF forwards it to the UE (message 3-16) , which responds with a 200 OK message (3-17) .
• This 200 OK message is forwarded via the P-CSCF, the S-CSCF (message 3-18) and the I-CSCF (message 3-19) to the calling entity (message 3-20) .
• the relation between the GRUU and the S-CSCF is established by binding the GRUU to the S-CSCF in the HSS.
• the GRUU userpart is generated such that it contains S-CSCF ID.
• the S-CSCF creates GRUU userparts, i.e. crypto-GRUU' s based on a configured pattern, so that it can be used in I-CSCFs to locate the correct S-CSCF.
• the signal flow is basically the same as that of Fig. 3 according to the first embodiment, so that only differences to the first embodiment are described.
• the GRUU generation format differs to the first embodiment. That is, according to the second embodiment it is sip: [S-CSCF URI + crypto- GRUU] ⁇ homel.net.
• the SAR and SAA messages (4-6) and (4-7) are therefore regular Diameter SAR and SAA, since they do not contain the GRUU.
• the messages (4-1) to (4-5) and (4- 8) to (4-10) are identical to the messages (3-1) to (3-5) and (3-8) to (3-10) according to the first embodiment.
• the GRUU usage as shown in the lower part of Fig. 4 differs from that of Fig. 3. Namely, after receiving the INVITE Request (4-11), the I-CSCF determines that the
• Request-URI does not follow the pattern of a real Public User Identity, because the I-CSCF is able to extract the S-CSCF address from the GRUU. In this way, it is not necessary to send Diameter messages to the HSS, and no mapping between GRUUs and S-CSCFs at the HSS is required. That is, the messages (3-12) and (3-13) shown in Fig. 3 can be omitted.
• the relation between the GRUU and the S-CSCF is established by the S-CSCF when it includes the S- CSCF's ID into the GRUU.
• a routable GRUU to the S-CSCF hostname is created, i.e., the S-CSCF creates a GRUU that provides direct routing to the S-CSCF hostname.
• the S-CSCF Upon the GRUU generation as shown in the upper part of Fig. 5, the S-CSCF creates a GRUU that provides direct routing to the IP address allocated to the S-CSCF. For instance, the GRUU may follow the pattern sip: [crypto- GRUU] ⁇ scscfl.homel.net. This approach does not require the S-CSCF to inform the HSS whenever a GRUU is created/deleted. That is, similar as in the signal flow of Fig. 4, the messages (5-6) and (5-7) are normal Diameter SAR and SAA and do not contain the GRUU. The messages (5-1) to (5-5) and (5-8) to (5-10) are similar to the messages (3-1) to (3-5) and (3-8) to (3-10) according to the first embodiment.
• the I-CSCF determines that the Request-URI does not follow the pattern of a real Public User Identity, because the right hand side of the URI contains a hostname rather than a domain name. That is, the I-CSCF extracts the S-CSCF URI from the GRUU. Hence, the I-CSCF, instead of querying the HSS for routing information, forwards the request directly to the S-CSCF.
• the remaining procedures are basically the same as shown in Fig. 4.
• the INVITE message comprises the SAR instead of the GRUU, since the S-CSCF URI was extracted from the GRUU.
• the messages (5-13) to (5-18) are similar to messages (4-13) to (4-18) according to the second embodiment.
• NAPTR NAPTR
• This solution does require some more initial configuration, as it requires adding NAPTR and SRV records to each S-CSCF in the network. These records, otherwise, are not required for the operation of the DNS. Note that the A/AAAA records of all the S-CSCFs are required and already present in the DNS, but not necessarily the NAPTR and SRV records.
• the advantage of the solution according to the third embodiment is the lack of HSS involvement. Therefore, faster session setup times might be expected.
• the relation between the GRUU and the S-CSCF is established by creating a routable GRUU to the S-CSCF hostname.
• a fourth embodiment is described, according to which a routable GRUU to the S-CSCF IP address is created.
• this solution is a slight variation of the solution described in the third embodiment:
• the GRUU that the S-CSCF creates contains an IP address rather than a hostname.
• the GRUU may follow the pattern sip: [crypto-GRUU] @ [IP address] . This is illustrated in the signal flow shown in Fig. 6.
• the messages (6-1) to (6-10) during the GRUU generation are the same as the messages (5-1) to (5-10) in Fig. 5, whereas only the format of the GRUU differs.
• the I- CSCF can simply forward the INVITE request to the S-CSCF in message (6-12), that is, in contrast to message (4-12) according to the second embodiment, the INVITE request in message (6-12) does not contain the GRUU.
• the remaining messages (6-11) and (6-13 to 6-18) are similar to the messages (5-11) and (5-13 to 5-18) according to the third embodiment.
• this approach does not require the S-CSCF to inform the HSS whenever a GRUU is created/deleted.
• this solution does not require to configure the DNS by adding a NAPTR and SRV entries per S-CSCF.
• it requires the home network to configure the firewalls so that SIP signalling can reach directly each of the S- CSCFs in the network.
• the embodiments may be freely combined.
• the GRUU may be allocated or created alternatively also by a HSS. This can also be applied to the second, the third and the fourth embodiment, so that the GRUU is not created in the S-CSCF, but in the HSS. In this case, however, the S-CSCF has to be notified regarding the GRUU.
• the user equipment described above is only an example for an instance, i.e., a particular network element.
• S-CSCF is only an example for a serving network control element according to the invention.
• the generic control element according to the invention is, for example, an S-CSCF, I-CSCF, HSS etc., in which the basic operation according to the invention can be performed.
• the I-CSCF is an example for an edge control element according to the invention.
• the edge control element is a network element which provides access to the IMS (or a similar communication system) for the user equipment (i.e., the instance) .
• the HSS is only an example for a central network element according to the invention.
• the central network element is an element which stores data regarding the instance.
• the IMS is only an example for a communication system.
• the invention may be applied in other communication systems, for example a Multimedia Domain (MMD) defined by 3GPP2.
• MMD Multimedia Domain

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Multimedia (AREA)
• Telephonic Communication Services (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Vending Machines For Individual Products (AREA)
• Holo Graphy (AREA)
• Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Priority Applications (1)

Applications Claiming Priority (4)

Publications (2)

Family

ID=35657018

Family Applications (1)

Country Status (5)

Families Citing this family (47)

Family Cites Families (10)

• 2004
  • 2004-11-01 US US10/976,894 patent/US20060018272A1/en not_active Abandoned
• 2005
  • 2005-07-14 EP EP05763603A patent/EP1774752B1/de not_active Not-in-force
  • 2005-07-14 AT AT05763603T patent/ATE456896T1/de not_active IP Right Cessation
  • 2005-07-14 WO PCT/IB2005/002008 patent/WO2006011017A1/en active Application Filing
  • 2005-07-14 DE DE602005019170T patent/DE602005019170D1/de not_active Expired - Fee Related

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events