WO2010075870A1 - Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles - Google Patents

Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles Download PDF

Info

Publication number
WO2010075870A1
WO2010075870A1 PCT/EP2008/068307 EP2008068307W WO2010075870A1 WO 2010075870 A1 WO2010075870 A1 WO 2010075870A1 EP 2008068307 W EP2008068307 W EP 2008068307W WO 2010075870 A1 WO2010075870 A1 WO 2010075870A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
filter
availability
information
request
Prior art date
Application number
PCT/EP2008/068307
Other languages
English (en)
Inventor
Pavel Dostal
Ivo Sedlacek
Original Assignee
Nokia Siemens Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2008/068307 priority Critical patent/WO2010075870A1/fr
Publication of WO2010075870A1 publication Critical patent/WO2010075870A1/fr

Links

Classifications

    • 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/54—Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users
    • 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/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability

Definitions

  • the present invention is related to the filtering of subscribed information, such as presence information.
  • Presence is a term used to define the willingness or ability of a person (or some other entity) called presentity to communicate with others.
  • Presence information may simply specify that a particular person is either "available” or “unavailable”. More sophisticated systems might offer more options, particularly specifying reasons why a person or an entity might be unavailable. Options include, for example, "in a meeting” or “out to lunch", or simply "busy”. Presence information might also distinguish between a person who is unavailable by virtue of not being connected to a network, and a person who is connected, but is asking not to be contacted (e.g. because they are busy).
  • FIG. 1 is a block diagram of a system making use of presence information.
  • the system indicated generally by the reference numeral 2, comprises a presence source 4, a presence server 6 and a watcher 8.
  • the presence source 4 may be part of a user's terminal (e.g. a computer or a mobile communication device) or a network entity (e.g. location server).
  • the presence source 4 is used to upload presence information to the presence server 6, typically via a network connection.
  • the presence server 6 typically stores presence information (referred to a presentity) for a number of users and makes the presentity data available to other users, such as the watcher 8.
  • the watcher 8 can obtain the data from the server 6, typically via another network connection.
  • the watcher 8 may make use of the Session Initiation Protocol (SIP) for obtaining presence information from the presence server 6, as described, for example, in the article "Session Initiation Protocol (S ⁇ P)-Specific Event Notification” available at httj3://www.ietf.org/rfc/rfc3265.txt (the "RFC3265 article”).
  • S ⁇ P Session Initiation Protocol
  • RFC3265 article describes a subscriber issuing SUSCRIBE messages and a notifier responding to the SUBSCRIBE messages by issuing NOTIFY messages.
  • SUBSCRIBE messages are used to request the current state of a remote node and to request state updates from that node.
  • NOTIFY messages are used to inform subscribers of the state of a resource.
  • the watcher 8 may issue SUBSCRIBE requests to the presence server 6 requesting presence information and the presence server may respond by issuing NOTIFY responses including the requested presence information.
  • Presence information is widely used in instant messaging systems, which enable watchers to determine whether other users are available. In this way, a user can select people to contact on the basis of the likelihood of obtaining an instant reply.
  • PTT and PoC systems provide a form of two-way communication that allows users to engage in immediate communication with one or more other users.
  • a user presses a button to talk with an individual other user, or to broadcast to a group of participants.
  • the receiving participant(s) hear the sender's voice without having to take any direct action (i.e. without having to answer a call).
  • the receiving participant(s) need to accept a call.
  • the communication is half-duplex, since only one person can talk at any one time and all other participants hear the speech.
  • Presence and other availability information can be very simple. For example, presence information can simply take the form of textual data (e.g. "available", “busy”, “in a meeting", “not connected” etc.). However, presence information can be more complicated. For example, logos and other graphics may be used. A particular user device requesting presence information may not wish to obtain all of this data. This might be the case, for example, if the user device is a mobile communications device and the presence information will need to be sent over an expensive wireless connection, or a link with low bandwidth. In such circumstances, an end user device may wish to limit the data being sent. Mobile communication devices being used to access presence information may also have low data processing capabilities and/or limited display capabilities. Filtering data offers the possibility of preventing data that cannot be handled by the device concerned from be sent over the wireless link.
  • the RFC4660 article and the RFC4661 article describe the communication of filter rules from a user (such as the watcher 8) to a server (such as the presence server 6).
  • the filter rules are in the form of an XML filter, which is sent to the server (such as the presence server 6) with a SIP SUBSCRIBE request.
  • the use of a filter enables a subscriber to specify preferences of when notifications should be sent, and what those notifications should (or should not, as the case may be) contain, thereby defining a subset of presence information that the subscriber wants to obtain.
  • FIG. 2 shows a message sequence, indicated generally by the reference numeral 10 showing how the watcher 8 can be used to obtain filtered presence information from the presence server 6.
  • the message sequence 10 begins with the watcher 8 issuing a SIP SUBSCRIBE message 12 to the presence server 6.
  • the SUBSCRIBE message 12 includes a body describing an XML filter.
  • the presence server 6 responds to the SUBSCRIBE message 12 by issuing a 200 response 14, which indicates that the presence server has received and accepted the SIP SUBSCRIBE request 12.
  • possible responses to a SUBSCRIBE message include 200-class responses, such as 200 (which indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource) and 202 (which indicates that the subscription has been understood, and that authorization may or may not have been granted), and non-200 class responses (such as "401 Authorisation Required”), which indicate that the request has failed.
  • the message sequence 10 continues with the presence server 6 providing the presence information requested in the SIP SUBSCRIBE request 12 to the watcher 8 in the form of a SIP NOTIFY message 16.
  • the watcher 8 issues a "200" OK message 18, indicating that the NOTIFY message 16 has been received and accepted by the watcher 8.
  • the NOTIFY message 16 includes the presence information stored at the presence server 6 that has been filtered in accordance with the XML filter included in the body of the SUBSCRIBE message 12.
  • the functionality of the filter may take many different forms.
  • the content filtering could be expressed in positive terms.
  • a filter may specify what the notification should contain.
  • the content filtering could be expressed in negative terms.
  • a filter may specify what the notification should not contain.
  • the filter may include trigger information specifying changes that a resource has to encounter before the content should be delivered to the subscriber.
  • trigger information specifying changes that a resource has to encounter before the content should be delivered to the subscriber.
  • an advantage of enabling presence information to be filtered is that the amount of data sent from the presence server to the device issuing the SUBSCRIBE request can be kept to a minimum, thereby reducing the quantity of data that is transmitted. This advantage is reduced if the size of each SUBSCRIBE request is large.
  • the present invention seeks to address at least some of the problems outlined above.
  • a method comprising: receiving, from a first entity (for example, via a wireless network), a request for data (or information) concerning the availability of a second entity; obtaining a filter for said availability data; generating a modified request for data concerning the availability of the second entity, the modified request including the filter; and forwarding the modified request to a store of availability data (such as a presence server).
  • the method may further comprise receiving filtered availability data from said store of availability data.
  • the method may further comprise returning said filtered availability data to the first entity.
  • an apparatus (such as a watcher agent) comprising: a first input for receiving (for example, from a first entity) a request for data (or information) concerning the availability of a second entity; a controller adapted to obtain a filter for said availability data and to generate a modified request by adding said filter to said request for data concerning the availability of the second entity; and a first output adapted to forward the modified request to a store of availability data (such as a presence server).
  • the first input may be adapted to receive said request via a wireless link.
  • the apparatus of the present invention may further comprise a second input for receiving filtered availability data from said store of availability data.
  • the apparatus may further comprise a second output adapted to return said filtered availability data to the first entity.
  • filtered availability information may be received at the apparatus and forwarded to the first entity.
  • the filtered availability information may be sent directly from the store of availability data to the first entity.
  • the apparatus may further comprise a filter store, wherein the controller obtains said filter from said filter store.
  • the present invention enables an apparatus, such as a watcher agent, to receive a request for availability information for a user from a first entity and to provide filtered availability information to that first entity, without the first entity needing to provide the filter in the request.
  • Avoiding the need to include filter information (for example in the form of an XML filter) in each request issued by the first entity can significantly reduce the amount of data sent over a link. This can be a significant advantage if, for example, that link is expensive or has a low bandwidth.
  • the availability data may be presentity data.
  • the availability data may be used in an Instant Messaging system.
  • the availability data may be used in a PTT or PoC system.
  • the availability data may, for example, be PoC session participant information.
  • the request for data concerning the availability of a second entity may take the form of a SIP SUBSCRIBE request.
  • Filtered availability data may be sent to the first entity as a SIP NOTIFY message.
  • the step of obtaining a filter for said availability data may comprise selecting a filter on the basis of the identity of the first entity, or on the basis of the device being used by the first entity. This enables, for example, data formats that are not supported by the first entity (or by the device being used by the first entity) to be omitted from the availability data sent to the first entity, thereby avoiding unnecessary data transfer.
  • the request for availability data for a user issued by the first entity includes information identifying the first entity (or the device being used by the first entity).
  • the request for data concerning the availability of a second entity received from said first entity may include an indication of the filter that should be used. This may, for example, take the form of a file name, or some other indicator.
  • the filter is selected based on the nature of the link with the first entity.
  • the filter may be dependent on one or more of the cost of the link and the available bandwidth of the link.
  • an entity (such as the first entity) is able to upload a filter for future use.
  • the entity which uploads a filter may, for example, specify that that filter is always used for that entity, or that that filter should be used for that entity in the absence of instructions to the contrary.
  • filters can be generated by combining the features of two or more stored filters.
  • the rules for combining said two or more filters may, for example, be specified by the first entity.
  • a computer program comprising: code for receiving, from a first entity, a request for data (or information) concerning the availability of a second entity; code for obtaining a filter for said availability data; code for generating a modified request for data concerning the availability of the second entity, the modified request including the filter; and code for forwarding the modified request to a store of availability data.
  • the computer program may further comprise: code for receiving said filtered availability data from said store of availability data.
  • the computer program may further comprise code for returning said filtered availability data to the first entity.
  • the computer program is a computer program product comprising a computer-readable medium bearing computer program code embodied therein for use with a computer.
  • a computer program product comprising: means for receiving, from a first entity, a request for data or information concerning the availability of a second entity; means for obtaining a filter for said availability data or information; means for generating a modified request for data or information concerning the availability of the second entity, the modified request including the filter; and means for forwarding the modified request to a store of availability data or information.
  • the computer program product may further comprise: means for receiving said filtered availability data or information from said store of availability data.
  • the computer program product may further comprise means for returning said filtered availability data or information to the first entity.
  • an apparatus comprising: means for receiving, from a first entity, a request for data or information concerning the availability of a second entity; means for obtaining a filter for said availability data or information; means for generating a modified request for data or information concerning the availability of the second entity, the modified request including the filter; and means for forwarding the modified request to a store of availability data or information.
  • the apparatus may further comprise: means for receiving said filtered availability data or information from said store of availability data or information.
  • the apparatus may further comprise means for returning said filtered availability data or information to the first entity.
  • Figure 1 is a block diagram of a known system for providing presence information on request
  • Figure 2 is a message sequence demonstrating an exemplary functionality of the system of Figure 1 ;
  • Figure 3 is a block diagram of a system in accordance with an aspect of the present invention.
  • Figure 4 is a message sequence demonstrating an aspect of the present invention.
  • Figure 5 is a message sequence demonstrating an aspect of the present invention.
  • FIG 3 shows a block diagram of a system, indicated generally by the reference numeral 20, in accordance with an aspect of the present invention.
  • the system 20 includes a presence source 22 and a watcher 30 that are similar to the presence source 4 and the watcher 8 described above with reference to Figures 1 and 2.
  • the system 20 also includes a server indicated by the reference numeral 24.
  • the server 24 includes a presence server 26 and a watcher agent 28. The server 24 therefore differs from the presence server 6 by providing the watcher agent 28.
  • the presence source 22 provides presence information to the presence server 26.
  • the watcher 30 liaises with the watcher agent 28 that forms part of the server 24 in order to obtain presence information from the presence server 26.
  • the watcher agent 28 controls the watcher's use of the presence service in the watcher's domain.
  • the watcher agent 28 authorises the watcher's use of the presence server and may also optimise the delivery of notifications to the watcher 30 based on the current presence status of the watcher.
  • the watcher agent 28 is used to store and/or manage filters and include them in the watcher's subscription request.
  • SUBSCRIBE requests can be sent from the watcher 30 to the presence server 26 via the watcher agent 28, without the filter characteristics needing to be included in the message that passes from the watcher 30 to the watcher agent 28.
  • the watcher agent 28 can be collocated with an XML Document Management Server (XDMS) supporting the storage of filters, such as SIP for Instant Messaging and Presence Leveraging Extension (SIMPLE) filters.
  • XDMS XML Document Management Server
  • filters such as SIP for Instant Messaging and Presence Leveraging Extension (SIMPLE) filters.
  • the watcher agent may be separated from the XDMS. Further, the watcher 30 can manage filters using XML Document Management (XDM) procedures.
  • XDM XML Document Management
  • a service provider may have the possibility to set the filters that are applied to the subscriptions of a particular watcher. Such service provider-defined filters can be used also with previous Presence clients that do not support this feature.
  • Figure 4 is a message sequence, indicated generally by the reference numeral 40, demonstrating an exemplary use of the system 20.
  • the message sequence 40 begins with the watcher 30 issuing a SIP SUBSCRIBE message 42 to the watcher agent 28.
  • the SUBSCRIBE message 42 does not include a filter and so the quantity of data transferred from the watcher 30 to the watcher agent in the message 42 is small.
  • the watcher agent issues a 200 response 44, indicating that the SUBSCRIBE request has been accepted.
  • the watcher agent 28 checks a number of pre-stored filters to determine whether any are specified as applying to presence information for the watcher 30.
  • the watcher agent 28 issues a SIP SUBSCRIBE request 48 to the presence server 26.
  • the SUBSCRIBE request 48 includes any filter found in the step 46 in the body of the message.
  • the presence server 26 issues a 200 response 50.
  • the presence server 26 provides the requested presence information to the watcher agent as a SIP NOTIFY message 52. If a filter has been selected for use, then the presence information is filtered in accordance with that filter.
  • the watcher agent 28 issues a 200 response 54 to the presence server 26 and forwards the filtered presence information to the watcher 30 in the form of a SIP NOTIFY message 56.
  • the watcher 30 responds with a 200 response 58.
  • the watcher 30 receives filtered presence information in the form of the SIP NOTIFY message 56, without needing to include filter information in the original SUBSCRIBE request 42.
  • data transfer over the connection between the watcher 30 and watcher agent 28 (which is typically a wireless connection and may be expensive, slow and/or unreliable), is kept to a minimum.
  • the message sequence 48 to 54 between the watcher agent 28 and the presence server 26 is the same as the message sequence 10 described above with reference to Figure 2, with the exception that in the example of Figure 4, the watcher agent 28 takes the role of the watcher 8. This is important since the transfer of data between the watcher 8 and the presence server 6 typically takes place over a wireless connection, whereas the transfer of data between the watcher agent 28 and the presence server 26 typically takes place within the server 24.
  • the SUBSCRIBE message 42 includes no information regarding filtering of presence information. This is possible in many circumstances since, for a particular device, the filter requirements may be constant. This may be the case, for example, if filtering is carried out to remove presence information that cannot be processed by that particular device. In such a case, the filtering required may always be the same. In order for the filter to be selected to match the device being used to access the availability information, the SUBSCRIBE message 42 may include an identifier for the device being used.
  • the desired filtering may be dependent on the circumstances. For example, in the event that the only available connection between the watcher 30 and the watcher agent 28 is a low bandwidth connection, or an unusually expensive connection, the user may want to request that data transfer be kept to a minimum and to select a filter accordingly. In other circumstances (for example, if a better and/or cheaper connection is available), that user may wish to obtain more user data (for example, including graphical symbols associated with the presentities).
  • the SUBSCRIBE message 42 includes, in the body of the request, an indication of a previously stored filter that should be selected in the filter selection step 46. This could, for example, take the form of a file name, or some other simple reference. In this manner, a user can select a filter from a plurality of available filters. That filter selection may, for example, be dependent on the circumstances.
  • a user may wish to define a filter.
  • the user may wish to upload the filter to the watcher agent 28 and be able to use that filter, without needing include the filter in every SUBSCRIBE message.
  • FIG. 5 is a message sequence, indicated generally by the reference numeral 60, showing the uploading of a filter from the watcher 30 to the watcher agent 28.
  • the message sequence 60 begins with a filter being created at the watcher 30 and then uploaded to the watcher agent 28 in a message 62.
  • the watcher agent then returns a 200 message 64 to the watcher 30 indicating that the filter has been received.
  • the user can instruct the watcher agent 28 to select that filter in the filter selection step 46, without needing to include the details of the filter in each SUBSCRIBE request.
  • the user may, for example, indicate that all presence information forwarded to that user should be filtered using the uploaded filter.
  • the user may indicated that all presence information forwarded to that user should be filtered using the uploaded filter, unless a different filter is specified in the relevant request.
  • the presence server 26 and the watcher agent 28 are provided as part of the same server 24. It is not, however, essential that the watcher agent and the presence server be located at the same physical location. The elements of the server 24 may be physically dispersed. Indeed, the presence server 26 and the watcher agent 28 need not necessarily be provided as part of the same server.
  • the embodiment described above with reference to Figure 3 shows a system 20 including a single watcher 30, a single watcher agent 28 and a single presence server 26. This arrangement is not essential.
  • the watcher agent 28 may provide communications between a watcher 30 and a plurality of presence servers, possibly including presence servers in different domains.
  • a single watcher 30 may be in communication with a number of different watcher agents 28, each of which may be in communication with one or more presence servers 26.
  • a single filter is used. This is not essential. Of course, it is possible that in many circumstances, no filter is used. Also, it is possible for multiple filters to be used. In some embodiments of the invention, a watcher can specify several filters for use and can also specify the way in which the filters are combined. Thus, if a number of filters are stored at a watcher agent, quite complex filter arrangements can be defined without needing to include a further filter definition in a SUBSCRIBE request.
  • the filtered availability information is sent from the presence server 26 to the watcher 30 via the watcher agent 28.
  • the filtered availability information could be sent directed from the presence server 26 to the watcher 30 in response to an instruction sent from the watcher agent 28 to the presence server 26.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un agent d'observation destiné à fournir des données filtrées concernant la disponibilité d'utilisateurs (telles que des informations de présence filtrées). L'agent d'observation reçoit une demande d'informations concernant la disponibilité d'une entité; ajoute des informations de filtre à la demande, et envoie une demande modifiée comprenant les informations de filtre à un serveur de présence. Ledit serveur de présence renvoie les informations de disponibilité filtrées en réponse à la demande modifiée. Les informations de disponibilité d'utilisateurs peuvent être filtrées, par exemple, en fonction du coût ou de la largeur de bande d'une liaison sans fil sur laquelle les informations doivent être envoyées, ou en fonction de la capacité de traitement du dispositif auquel les informations doivent être envoyées.
PCT/EP2008/068307 2008-12-29 2008-12-29 Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles WO2010075870A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/068307 WO2010075870A1 (fr) 2008-12-29 2008-12-29 Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/068307 WO2010075870A1 (fr) 2008-12-29 2008-12-29 Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles

Publications (1)

Publication Number Publication Date
WO2010075870A1 true WO2010075870A1 (fr) 2010-07-08

Family

ID=41279475

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/068307 WO2010075870A1 (fr) 2008-12-29 2008-12-29 Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles

Country Status (1)

Country Link
WO (1) WO2010075870A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1788785A1 (fr) * 2005-11-18 2007-05-23 Alcatel Lucent Système et procédé de représentation d'états de présence pour des contacts dans une liste de contacts
US20080010301A1 (en) * 2004-11-04 2008-01-10 Huawei Technologies Co., Ltd Method and system for notifying presence information

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080010301A1 (en) * 2004-11-04 2008-01-10 Huawei Technologies Co., Ltd Method and system for notifying presence information
EP1788785A1 (fr) * 2005-11-18 2007-05-23 Alcatel Lucent Système et procédé de représentation d'états de présence pour des contacts dans une liste de contacts

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KHARTABIL TELIO E LEPPANEN M LONNFORS J COSTA-REQUENA NOKIA H: "Functional Description of Event Notification Filtering; rfc4660.txt", IETF STANDARD, INTERNET ENGINEERING TASK FORCE, IETF, CH, 1 September 2006 (2006-09-01), XP015047411, ISSN: 0000-0003 *

Similar Documents

Publication Publication Date Title
JP5436571B2 (ja) 通信履歴を提供する方法及び装置
CN101355797B (zh) 获得用户终端设备信息的方法和通信业务功能实体
EP1520388B1 (fr) Actualisation d'informations de presence
KR101181001B1 (ko) 푸쉬 투 토크 오버 셀룰러 시스템의 Ｃｈａｔ ＰｏＣ 그룹초대 예약을 통한 세션 합류 방법 및 그 시스템
US9357026B2 (en) Presentity authorization of buddy subscription in a communication system
US20110282957A1 (en) Method for processing deferred message
US20130205228A1 (en) Method for managing presence information
KR20100057096A (ko) 액티브 프로파일 선택
US20100094952A1 (en) Method and Apparatus for Notifying Clients in a Communication Network
US8054843B2 (en) Method for securing privacy in automatic answer mode of push-to service
CN101115094B (zh) 提供通信业务的方法和系统及触发器装置
JP6254530B2 (ja) 連絡先情報の購読を招待する装置及び方法
WO2010075802A1 (fr) Procédé et dispositif d'envoi de message de notification
US20120028614A1 (en) Method and system for processing unified state change notifications
KR101245389B1 (ko) 활성 통신 세션 확인 방법 및 통신 세션 정보 서버
WO2010075870A1 (fr) Filtrage d'informations concernant la disponibilité d'utilisateurs disponibles
US9692845B2 (en) Permanent presence for polite block and confirm
TW201021490A (en) System and method for re-publication of information in a network-based communication system
WO2009121974A1 (fr) Procédé et système de traitement de messages de données et de chaînes de message par comparaison de l'adresse d'origine et de l'adresse de destination pour détecter une concordance
KR20050016989A (ko) 프리젠스 정보의 갱신
KR20120040625A (ko) 통합 주소록 서비스 기반의 주소 상태를 제공하기 위한 장치 및 방법
KR101322990B1 (ko) Ｐｔ 서비스의 자동 응답 모드에서의 프라이버시 확보 방법
Wu et al. SIP Presence Location Service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08875546

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08875546

Country of ref document: EP

Kind code of ref document: A1