EP1500246A1 - Automatisierte anpassung und transformation von medienströmen - Google Patents

Automatisierte anpassung und transformation von medienströmen

Info

Publication number
EP1500246A1
EP1500246A1 EP03722289A EP03722289A EP1500246A1 EP 1500246 A1 EP1500246 A1 EP 1500246A1 EP 03722289 A EP03722289 A EP 03722289A EP 03722289 A EP03722289 A EP 03722289A EP 1500246 A1 EP1500246 A1 EP 1500246A1
Authority
EP
European Patent Office
Prior art keywords
data stream
description
transformation
bsd
data
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP03722289A
Other languages
English (en)
French (fr)
Inventor
Christian Timmerer
Harald Kosch
Hermann Hellwagner
Andreas Hutter
Jörg Heuer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of EP1500246A1 publication Critical patent/EP1500246A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G06F16/88—Mark-up to mark-up conversion
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/56—Provisioning of proxy services
    • 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/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Definitions

  • the invention relates to the transformation of data streams.
  • the transformation descriptions are used to incorporate an XML document that conforms to a media stream-specific BSDL version, that is, a schema according to the "XML Schema Language” 3C Recommendation of May 2, 2001 or a DTD (Document Type Definition) transform adapted XML document. This document is then used in turn to generate a transformed data stream from a first data stream with the help of the BSDL execution.
  • a media stream-specific BSDL version that is, a schema according to the "XML Schema Language” 3C Recommendation of May 2, 2001 or a DTD (Document Type Definition) transform adapted XML document.
  • a first data stream a_l in the form of a binary bit stream is fed to a first bit stream parser BP_1.
  • the bitstream parser BP_1 uses a BSDL scheme BSDL_a, the bitstream parser BP_1 generates a first data stream description BSD_1 / 1 for the first data stream in the form of an XML document from the first data stream a_l.
  • An XSL processor XSLP then generates a second data stream description BSD_l / 2 for the first data stream from the first data stream description BSD_1 / 1 for the first data stream using an XSLT style sheet XSL.
  • a second bitstream parser BP_2 finally transforms the first data stream a_l using the BSDL scheme BSDL_a and the second data stream description BSD_l / 2 for the first data stream in the second data stream a_2.
  • This method can be used, for example, to adapt an instance of a media stream, for example a video stream, present on a media server to the requirements of a requesting client such that, after the adaptation, for example, the image format of the video stream corresponds to the screen resolution available at the terminal or, for example, that on the Transmission path from the server to the client's preferred bit rate is optimally used.
  • BSDL version e.g. as a schema or as a DTD, exist and be known to the system.
  • the second data stream description BSD_l / 2 for the first data stream is not a correct description of the second data stream a_2, because the data stream addresses contained in the second data stream description BSD_l / 2 for the first data stream for the elements in the second data stream description BSD_l / 2 for the first data stream were copied directly from the first data stream description BSD_1 / 1 for the first data stream without, for example address changes caused by discarding parts of the data stream.
  • the first data stream contains partial data stream areas that can be referenced and / or classified.
  • the second data stream also contains partial data stream areas that can be referenced and / or classified.
  • a data stream description is provided for the first data stream, in which at least some, preferably at least almost all, of the data stream subareas in the first data stream are referenced and / or classified.
  • the data stream description can contain a series of address details, each of which references a sub-area of the data stream. Classification details are assigned to the address details, by means of which the respective sub-areas referenced by the address details are classified.
  • the first data stream is transformed into the second data stream by a data stream transformation.
  • a first data stream description for the second data stream is generated, in which at least some, preferably at least almost all, of the data stream subareas in the second data stream are referenced and / or classified. In the first data stream description for the second data stream, in particular the references regarding the second data stream are correct.
  • a parser By generating a first data stream description for the second data stream, a parser can be omitted in subsequent transformations. Insofar as a parser is not necessary for the provision of the first data stream description for the first data stream, for example, if it is provided by an encoder, the Procedures completely without the use of a parser for the data stream. This is an enormous advantage, especially in networks and when using data streams in different formats, since it is often not possible to provide a suitable parser here.
  • the first data stream description for the first data stream is preferably transformed into the first data stream description for the second data stream by a data stream description transformation.
  • the first data stream description for the second data stream is thus generated from the first data stream description for the first data stream.
  • the generation of the first data stream description for the second data stream can even take place parallel to the data stream transformation and also in the same process step.
  • the data stream description transformation then takes place parallel to the data stream transformation.
  • the parallel success stands in contrast to a sequential success, i.e. that the generation of the first data stream description for the second data stream can be carried out independently of the data stream transformation and vice versa.
  • the first data stream is preferably transformed into the second data stream using the first data stream description for the first data stream.
  • the first data stream is transformed into the second data stream using a data stream transformation description.
  • the first data stream description for the first data stream can be transformed into the first data stream description for the second data stream using a data stream description transformation description. Then in particular the data stream transformation can be described. exercise is the same as the data stream description transformation description.
  • At least one of the data streams is preferably a data record, a bit, media, audio, still picture and / or video stream.
  • the data stream is encoded in particular in the MPEG-4 or JPEG2000 standard.
  • the data stream description is especially in XML (Extensible Markup Language).
  • the data stream transformation description and / or the data stream description transformation description is preferably a style sheet in XSL and / or in Javascript.
  • the method is particularly suitable for use cases in which further transformations follow the first transformation in order to further adapt the data stream in terms of content and / or scope.
  • the second data stream is preferably transformed into a third data stream using the first data stream description for the second data stream.
  • a method in which the first data stream description for the first data stream functions as a look-up table for the data stream transformation is based on the same inventive idea as the previously described methods.
  • the first data stream description for the first data stream is used directly, ie without the conversion known from the prior art, into a second data stream description for the first data stream for the data stream transformation.
  • the first data stream description for the first data stream is used completely and unchanged in that the data stream transforma- the references or classes of interest are looked up directly in the first data stream description for the first data stream.
  • a device which is set up to carry out a method of the type described above can be implemented, for example, by providing corresponding means for each of the method steps mentioned, which means carry out the method steps.
  • Advantageous configurations of the device result analogously to the advantageous configurations of the method.
  • a program product for a data processing system which contains software code sections with which one of the described methods can be carried out on the data processing system, can be implemented by suitable implementation of the method in a programming language and translation into code that can be executed by the data processing system.
  • the software code sections are stored for this.
  • a program product is understood to mean the program as a tradable product. It can be in any form, for example on paper, a computer-readable data medium or distributed over a network.
  • FIG. 2 shows a method for transforming a first data stream into a second data stream.
  • FIG. 2 shows an encoder Enc which supplies a first data stream a_l and a first data stream description BSD 1/1 for the first data stream.
  • the first data stream description BSD_1 / 1 for the first data stream which describes the first data stream a_l and is compliant with a structural specification BSDL, is used in two ways: First, uses the first data stream description BSD_1 / 1 for the first data stream together with a data stream transformation description XSL_a in order to transform the first data stream a_l in the form of a media stream into a second data stream a_2 in the form of a media stream.
  • the first data stream description BSD_1 / 1 is then transformed into a first data stream description BSD_2 / 1 for the second data stream, even under the guidance of a data stream description transformation description XSL_b.
  • the data stream description transformation description XSL_b can advantageously be designed such that the data stream addresses in the first data stream description BSD_2 / 1 for the second data stream are correct with respect to the second data stream a_2.
  • a further transformation which accordingly contains further transformation descriptions in the form of data stream transformation descriptions and data stream description transformation descriptions, can be carried out again directly and according to exactly the same procedure without additional intermediate processing steps. Direct cascading of transformations is thus possible in a uniform manner.
  • the structure specification for the BSDL schemes can correspond to the definition according to the prior art described at the outset or else advantageously correspond to the general data stream description described below.
  • the data stream contains data stream subareas that can be referenced and classified. It also has a data stream syntax that is given by the format and / or the content of the data stream. At least some data stream subareas are referenced. This means that they are provided with a reference that clearly identifies them. bar makes. The most prominent example of such a reference is the description of the position of a data stream sub-area in the data stream by means of address data.
  • the data stream subareas are also classified by a division into at least one class of a class division. By dividing them into a class, they are assigned a property that is predetermined by the class and characteristic of them.
  • the classification is at least partially independent of the syntax of the data stream. This means that it does not follow the structure and syntax of the data stream to be described, but contains classes that are independent of the structure, in particular the coding format, of the data stream and are not related to the content.
  • a marker ms_l [x] is assigned to a data stream sub-area a_l [x] of the data stream a_l, which specifies the meaning of the data stream sub-area a_l [x] for the data stream a_l.
  • This marker ms_l [x] does not have to be generic, but can be bitstream-specific, e.g. a VOP can be marked in an MPEG-4 video stream. This can be used to support the methods for transforming data streams described in the introduction. This has the advantage that the description of the data stream, in particular the class division, is generic and only the values of the markers ms_l [x] can vary, for example based on a classification scheme. The language can thus be parsed with a processor independent of the bit stream, regardless of the type of bit stream a_l.
  • the description of the data stream can have the following special properties:
  • the data stream description assigns one or more markers m_l [i] to data stream subareas a_l [x] in the data stream a_l.
  • the markers m_l [i] are used to translate the instructions of the transformation descriptions XSL onto the data stream.
  • An interpretation of the meaning of a Markers m_l [i] and / or the data stream subarea a_l [x] for the data stream a_l are not necessary and are not necessarily present.
  • the same marker m_l [i] can be used for several data stream sub-areas, e.g. a_l [x] and a_l [y] are used if, for example, the different data stream subareas a_l [x] and a_l [y] belong to a semantic unit in the data stream a_l or comprise, for example, syntactic elements of the same type.
  • a data stream subarea a_l [x] marked with the marker m_l [i] can contain data stream subareas a_l [z], which in turn are marked with markers m_l [j]. This is advantageous, for example, with regard to the speed of execution of the transformation if different transformation descriptions allow XSL to be carried out with different granularity.
  • these data stream subareas a_l [z] can be identified recursively on the basis of the identification of the data stream subarea a_l [x].
  • a data stream sub-area a_l [x] can be assigned a value v [x] which corresponds, for example, to the value represented by a_l [x] in the bit stream.
  • a transformation e.g. with XSLT, this value can be changed.
  • Referencing in the form of addressing the data stream subareas a_l [x] can be implemented in one of the following ways: Specification of the beginning and / or end of the data stream subarea a_l [x] by counting units from the beginning of the data stream.
  • the beginning of the data stream subarea a_l [x] follows the end of the previous data stream subarea a_l [w] or corresponds to the beginning of the data stream subarea a_l [a], if the data stream subarea a_l [x] is first contained in the data stream subarea a_l [a].
  • the specification of these values can be done by counting units. One or more units, for example bits or bytes, can be used here.
  • the data stream transformation description XSL_a and the data stream description transformation description XSL_b can be generated in advance or can be generated automatically by a processing unit which, for example, takes additional transmitted information about the requesting terminal into account in a client-server scenario.
  • first data stream description BSDL_1 / 1 for the first data stream is not provided by the encoder Enc when the first data stream a_l is generated, it can be generated from the first data stream a_l using a parser in accordance with the prior art method. In the exemplary embodiment shown, the generation of second data stream descriptions for the first and / or second data stream is completely dispensed with.
  • the data stream transformation of the first data stream a_l into the second data stream a_2 using the first data stream description BSD_1 / 1 for the first data stream and the data stream transformation description XSL_a takes place in an XSL and data stream processor XBP.
  • the data stream description transformation of the first data stream description BSD_1 / 1 for the first data stream into the first data stream description BSD_2 / 1 for the second data stream takes place, in particular in parallel, in an XSL processor XSLP.
  • Data stream transformation and data stream description transformation can also be combined in one process.
  • the data stream transformation description XSL_a and the data stream description transformation description XSL_b can be combined in one document.

Abstract

Bei einer Transformation eines ersten Datenstroms in einen zweiten Datenstrom wird parallel dazu eine erste Datenstrombeschreibung für den ersten Datenstrom in eine erste Datenstrombeschreibung für den zweiten Datenstrom transformiert

Description

Beschreibung
Automatisierte Anpassung und Transformation von Medienströmen
Die Erfindung betrifft die Transformation von Datenströmen.
In Devillers S.: "Bitstream Syntax Definition Language: An Input to MPEG-21 Content Representation" ist ein Verfahren beschrieben, mit dem auf Basis einer Sprache BSDL (Bitstream Description Language) zur Beschreibung von Datenströmen Adaptationsvorgänge für gegebene Medienströme durchgeführt werden können. Hierzu werden Transformationsbeschreibungen benutzt, die beispielsweise in der Sprache XSL (Extensible Stylesheet Language) geschrieben sein können. XSL-Transformationen wer- den in "XSL Transformations (XSLT)" Version 1.0, W3C Recom- mendation vom 16. November 1999 erläutert. Die Transformationsbeschreibungen werden verwendet, um ein zu einer medien- stromspezifischen BSDL-Ausführung konformes, das heißt einem Schema gemäß "XML Schema Language" 3C Recommendation vom 2. Mai 2001 bzw. einer DTD (Dcoument Type Definition) entsprechendes, XML-Dokument in ein adaptiertes XML-Dokument zu transformieren. Dieses Dokument wird dann wiederum benutzt, um mit Hilfe der BSDL-Ausführung aus einem ersten Datenstrom einen transformierten Datenstrom zu erzeugen.
Mit Bezug auf Figur 1 wird dieser Ablauf näher erläutert. Ein erster Datenstrom a_l in Form eines binären Bitstroms wird einem ersten Bitstromparser BP_1 zugeleitet. Unter Verwendung eines BSDL-Schemas BSDL_a erzeugt der Bitstromparser BP_1 aus dem ersten Datenstrom a_l eine erste Datenstrombeschreibung BSD_1/1 für den ersten Datenstrom in Form eines XML- Dokuments. Ein XSL-Prozessor XSLP erzeugt dann aus der ersten Datenstrombeschreibung BSD_1/1 für den ersten Datenstrom unter Verwendung eines XSLT-Style-Sheets XSL eine zweite Daten- Strombeschreibung BSD_l/2 für den ersten Datenstrom. Ein zweiter Bitstromparser BP_2 transformiert schließlich den ersten Datenstrom a_l unter Verwendung des BSDL-Schemas BSDL_a und der zweiten Datenstrombeschreibung BSD_l/2 für den ersten Datenstrom in den zweiten Datenstrom a_2.
Dieses Verfahren kann beispielsweise dazu eingesetzt werden, eine auf einem Medienserver vorliegende Instanz eines Medienstroms, beispielsweise eines Videostroms, an die Anforderungen eines anfragenden Clients derart anzupassen, dass nach der Adaption beispielsweise das Bildformat des Videostroms der am Endgerät vorhandenen Bildschirmauflösung entspricht oder beispielsweise die auf dem Übertragungsweg vom Server zum Client bevorzugte Bitrate optimal genutzt wird.
Das beschriebene Verfahren weist allerdings einige Nachteile auf. So muss für die Adaption ein Parser vorhanden sein, der die Bitstromsyntax des zur Kodierung der Datenströme a_l bzw. a_2 verwendeten Codecs kennt.
Weiterhin muss für jeden unterschiedlichen Mediencodec eine spezifische BSDL-Ausführung, z.B. als Schema oder als DTD, existieren und dem System bekannt sein.
Schließlich stellt die zweite Datenstrombeschreibung BSD_l/2 für den ersten Datenstrom keine korrekte Beschreibung des zweiten Datenstroms a_2 dar, weil die in der zweiten Daten- Strombeschreibung BSD_l/2 für den ersten Datenstrom enthaltenen Datenstromadressen für die Elemente in der zweiten Datenstrombeschreibung BSD_l/2 für den ersten Datenstrom direkt aus der ersten Datenstrombeschreibung BSD_1/1 für den ersten Datenstrom kopiert wurden, ohne z.B. durch Verwerfen von Tei- len des Datenstroms verursachte Adressänderungen nachzuziehen.
Die Aufgabe ist es daher, eine, neue verbesserte Transformation zur Verfügung zu stellen, die die Funktionen des Verfah- rens nach dem Stand der Technik ebenfalls erfüllt, jedoch die beschriebenen Nachteile vermeidet. Diese Aufgabe wird durch die in den unabhängigen Ansprüchen angegebenen Erfindungen gelöst. Vorteilhafte Ausgestaltungen ergeben sich aus den ünteransprüchen.
In einem Verfahren zur Transformation eines ersten Datenstroms in einem zweiten Datenstrom enthält der erste Datenstrom Datenstromteilbereiche, die referenzierbar und/oder klassifizierbar sind. Auch der zweite Datenstrom enthält Datenstromteilbereiche, die referenzierbar und/oder klassifi- zierbar sind. Es ist eine Datenstrombeschreibung für den ersten Datenstrom vorgesehen, in der zumindest einige, vorzugsweise zumindest nahezu alle, der Datenstromteilbereiche im ersten Datenstrom referenziert und/oder klassifiziert sind. Die Datenstrombeschreibung kann dazu eine Reihe von Adressan- gaben enthalten, von denen jede einen Teilbereich des Datenstrom referenziert. Den Adressangaben sind Klassifizierungsangaben zugeordnet, durch die die jeweiligen durch die Adressangaben referenzierten Teilbereiche klassifiziert sind. Der erste Datenstrom wird durch eine Datenstromtransformation in den zweiten Datenstrom transformiert. Dabei können beispielsweise wie bei den im Stand der Technik beschriebenen Verfahren Inhalte ausgefiltert, eine Bildauflösung reduziert und/oder die Reihenfolge der Daten im Datenstrom umsortiert werden. Es wird eine erste Datenstrombeschreibung für den zweiten Datenstrom erzeugt, in der zumindest einige, vorzugsweise zumindest nahezu alle, der Datenstromteilbereiche im zweiten Datenstrom referenziert und/oder klassifiziert sind. In der ersten Datenstrombeschreibung für den zweiten Datenstrom sind insbesondere die Referenzen bezüglich des zweiten Datenstroms korrekt.
Durch die Erzeugung einer ersten Datenstrombeschreibung für den zweiten Datenstrom kann bei nachfolgenden Transformationen auf einen Parser verzichtet werden. Soweit auch für die Bereitstellung der ersten Datenstrombeschreibung für den ersten Datenstrom kein Parser notwendig ist, indem diese beispielsweise von einem Encoder bereitgestellt wird, kann im Verfahren vollständig auf den Einsatz eines Parsers für den Datenstrom verzichtet werden. Dies ist insbesondere in Netzwerken und bei der Verwendung von Datenströmen in unterschiedlichen Formaten ein enormer Vorteil, da hier oft gar kein geeigneter Parser zur Verfügung gestellt werden kann.
Vorzugsweise wird die erste Datenstrombeschreibung für den ersten Datenstrom durch eine Datenstrombeschreibungstransfor- mation in die erste Datenstrombeschreibung für den zweiten Datenstrom transformiert. Die erste Datenstrombeschreibung für den zweiten Datenstrom wird somit also aus der ersten Datenstrombeschreibung für den ersten Datenstrom erzeugt.
Das Erzeugen der ersten Datenstrombeschreibung für den zwei- ten Datenstrom kann sogar parallel zur Datenstromtransformation sowie auch im selben Prozessschritt erfolgen. Im Falle der zuvor beschriebenen Datenstrombeschreibungstransformation erfolgt dann die Datenstrombeschreibungstransformation parallel zur Datenstromtransformation. Das parallele Erfolgen steht hier im Gegensatz zu einer sequentiellen Folge, d.h. dass die Erzeugung der ersten Datenstrombeschreibung für den zweiten Datenstrom unabhängig von der Datenstromtransformati- on vorgenommen werden kann und umgekehrt.
Vorzugsweise wird der erste Datenstrom unter Verwendung der ersten Datenstrombeschreibung für den ersten Datenstrom in den zweiten Datenstrom transformiert.
Auch ist es bevorzugt, dass der erste Datenstrom unter Ver- wendung einer Datenstromtransformationsbeschreibung in den zweiten Datenstrom transformiert wird.
Analog dazu kann die erste Datenstrombeschreibung für den ersten Datenstrom unter Verwendung einer Datenstrombeschrei- bungstransformationsbeschreibung in die erste Datenstrombeschreibung für den zweiten Datenstrom transformiert werden. Dann kann insbesondere die Datenstromtransformationsbeschrei- bung gleich der Datenstrombeschreibungstransformationsbe- schreibung sein.
Zumindest einer der Datenströme ist vorzugsweise ein Daten- satz, ein Bit-, Medien-, Audio-, Standbild- und/oder Videostrom. Dabei ist der Datenstrom insbesondere im MPEG-4- oder JPEG2000-Standard codiert.
Die Datenstrombeschreibung ist insbesondere in XML (Exten- sible Markup Language) . Die Datenstromtransformationsbe- schreibung und/oder die Datenstrombeschreibungstransformati- onsbeschreibung ist vorzugsweise ein Style-Sheet in XSL und/oder in Javascript.
Das Verfahren ist besonders für Anwendungsfälle geeignet, in denen auf die erste Transformation noch weitere Transformationen folgen, um den Datenstrom inhaltlich und/oder vom Umfang her weiter anzupassen. Entsprechend wird der zweite Datenstrom vorzugsweise unter Verwendung der ersten Datenstrombe- Schreibung für den zweiten Datenstrom in einen dritten Datenstrom transformiert.
Auf der gleichen erfinderischen Idee wie die zuvor dargestellten Verfahren basiert ein Verfahren, bei dem die erste Datenstrombeschreibung für den ersten Datenstrom für die Da- tenstromtransformation als Look-up-Tabelle fungiert. In diesem Fall wird die erste Datenstrombeschreibung für den ersten Datenstrom direkt, also ohne die aus dem Stand der Technik bekannte Umwandlung in eine zweite Datenstrombeschreibung für den ersten Datenstrom für die Datenstromtransformation herangezogen. Dadurch wird der Aufwand für die Umwandlung der ersten Datenstrombeschreibung für den ersten Datenstrom in die zweite Datenstrombeschreibung für den ersten Datenstrom sowie der Speicherplatz für die zweite Datenstrombeschreibung für den ersten Datenstrom gespart. Die erste Datenstrombeschreibung für den ersten Datenstrom wird dabei vollständig und unverändert herangezogen, indem bei der Datenstromtransformati- on jeweils direkt in der ersten Datenstrombeschreibung für den ersten Datenstrom die interessierenden Referenzen bzw. Klassen nachgeschaut werden.
Eine Vorrichtung, die eingerichtet ist, ein Verfahren der zuvor geschilderten Art auszuführen, lässt sich beispielsweise dadurch ausführen, dass für jeden der genannten Verfahrensschritte entsprechende Mittel vorgesehen werden, die die Verfahrensschritte ausführen. Vorteilhafte Ausgestaltungen der Vorrichtung ergeben sich analog zu den vorteilhaften Ausgestaltungen des Verfahrens.
Ein Programmprodukt für eine Datenverarbeitungsanlage, das Softwarecodeabschnitte enthält, mit denen eines der geschil- derten Verfahren auf der Datenverarbeitungsanlage ausgeführt werden kann, lässt sich durch geeignete Implementierung des Verfahrens in einer Programmiersprache und Übersetzung in von der Datenverarbeitungsanlage ausführbaren Code ausführen. Die Softwarecodeabschnitte werden dazu gespeichert. Dabei wird unter einem Programmprodukt das Programm als handelbares Produkt verstanden. Es kann in beliebiger Form vorliegen, so zum Beispiel auf Papier, einem computerlesbaren Datenträger oder über ein Netz verteilt.
Weitere wesentliche Vorteile und Merkmale der Erfindung ergeben sich aus der Beschreibung eines Ausführungsbeispiels anhand der Zeichnung. Dabei zeigt:
Figur 2 ein Verfahren zur Transformation eines ersten Da- tenstroms in einen zweiten Datenstrom.
In Figur 2 erkennt man einen Encoder Enc, der einen ersten Datenstrom a_l und eine erste Datenstrombeschreibung BSD 1/1 für den ersten Datenstrom liefert. Die erste Datenstrombe- Schreibung BSD_1/1 für den ersten Datenstrom, die den ersten Datenstrom a_l beschreibt und konform ist bezüglich einer Strukturvorgabe BSDL, wird zweifach verwendet: Zunächst wird die erste Datenstrombeschreibung BSD_1/1 für den ersten Datenstrom gemeinsam mit einer Datenstromtransformationsbe- schreibung XSL_a genutzt, um den ersten Datenstrom a_l in Form eines Medienstroms in einen zweiten Datenstrom a_2 in Form eines Medienstroms zu transformieren. Danach wird die erste Datenstrombeschreibung BSD_1/1 selbst unter Anleitung einer Datenstrombeschreibungstransformationsbeschreibung XSL_b in eine erste Datenstrombeschreibung BSD_2/1 für den zweiten Datenstrom transformiert. Die Datenstrombeschrei- bungstransformationsbeschreibung XSL_b kann dabei vorteilhaft derart ausgeführt sein, dass die Datenstromadressen in der ersten Datenstrombeschreibung BSD_2/1 für den zweiten Datenstrom korrekt in Bezug auf den zweiten Datenstrom a_2 sind. Auf diese Weise kann eine weitere Transformation, die ent- sprechend weitere Transformationsbeschreibungen in Form von Datenstromtransformationsbeschreibungen und Datenstrombeschreibungstransformationsbeschreibungen enthält, ohne zusätzliche Zwischenverarbeitungsschritte direkt und nach exakt der gleichen Vorgehensweise wieder durchgeführt werden. Somit ist eine direkte Kaskadierung von Transformationen auf eine einheitliche Weise möglich. Die Strukturvorgabe für die BSDL- Schemata kann der Definition nach dem eingangs geschilderten Stand der Technik entsprechen oder aber vorteilhaft der im folgenden beschriebenen allgemeinen Datenstrombeschreibung entsprechen.
Diese Datenstrombeschreibung, das heißt die Strukturvorgabe BSDL, ist generisch, also unabhängig von speziellen Codierformaten, insbesondere unabhängig vom Codierformat des be- schriebenen Datenstroms. Dennoch wird eine Typisierung der Elemente hinsichtlich spezifischer Codierformate ermöglicht. Dazu enthält der- Datenstrom Datenstromteilbereiche, die referenzierbar und klassifizierbar sind. Er weist weiterhin eine Datenstromsyntax auf, die durch das Format und/oder den In- halt des Datenstroms gegeben ist. Zumindest einige Datenstromteilbereiche werden referenziert. Das heißt, sie werden mit einer Referenz versehen, die sie eindeutig identifizier- bar macht. Prominentestes Beispiel für eine solche Referenz ist die Beschreibung der Lage eines Datenstromteilbereiches im Datenstrom durch Adressdaten. Die Datenstromteilbereiche werden darüber hinaus durch eine Einteilung in zumindest eine Klasse einer Klasseneinteilung klassifiziert. Durch die Einteilung in eine Klasse wird ihnen eine durch die Klasse vorgegebene und für sie charakteristische Eigenschaft zugeordnet. Die Klasseneinteilung ist zumindest teilweise unabhängig von der Syntax des Datenstroms. Das heißt, sie folgt nicht der Struktur und Syntax des zu beschreibenden Datenstroms, sondern enthält Klassen, die unabhängig vom Aufbau, insbesondere vom Codierungsformat, des Datenstroms sind und inhaltlich nicht mit ihm in Zusammenhang stehen.
Zur Klassifizierung wird einem Datenstromteilbereich a_l [x] des Datenstroms a_l ein Marker ms_l [x] zugewiesen, der die Bedeutung des Datenstromteilbereichs a_l [x] für den Datenstrom a_l spezifiziert. Dieser Marker ms_l[x] muss nicht ge- nerisch, sondern kann bitstromspezifisch sein, z.B. kann ein VOP in einem MPEG-4 Videostrom gekennzeichnet werden. Hiermit kann in der Einleitung beschriebene Verfahren zur Transformation von Datenströmen unterstützt werden. Dadurch ergibt sich der Vorteil, dass die Beschreibung des Datenstroms, insbesondere die Klasseneinteilung, generisch ist und nur die Werte der Marker ms_l [x] beispielsweise basierend auf einem Klassifikationsschema variieren können. Somit kann die Sprache unabhängig von der Art des Bitstroms a_l mit einem bitstrom- unabhängigen Prozessor geparst werden.
Die Beschreibung des Datenstroms kann dabei die folgenden besonderen Eigenschaften aufweisen:
- Die Datenstrombeschreibung weist Datenstromteilbereichen a_l[x] im Datenstrom a_l einen oder mehrere Marker m_l [i] zu. Die Marker m_l[i] werden genutzt um die Anweisungen der Transformationsbeschreibungen XSL auf den Datenstrom zu übersetzen. Eine Interpretation der Bedeutung eines Markers m_l[i] und/oder des Datenstromteilbereichs a_l[x] für den Datenstrom a_l ist hierbei nicht notwendig und nicht notwendigerweise vorhanden.
Der gleiche Marker m_l[i] kann für mehrere Datenstromteil- bereiche, z.B. a_l [x] und a_l[y] benutzt werden, wenn beispielsweise die unterschiedlichen Datenstromteilbereiche a_l[x] und a_l[y] zu einer semantischen Einheit im Datenstrom a_l gehören oder beispielsweise syntaktische Elemente des gleichen Typs umfassen. - Ein mit dem Marker m_l[i] gekennzeichneter Datenstromteil- bereich a_l [x] kann Datenstromunterteilbereiche a_l[z] enthalten, die wiederum mit Markern m_l[j] gekennzeichnet sind. Dies ist beispielsweise vorteilhaft hinsichtlich der Ausführungsgeschwindigkeit der Transformation, wenn durch unterschiedliche Transformationsbeschreibungen XSL mit unterschiedlicher Granularität Transformationen durchgeführt werden können. In einer Ausführungsmöglichkeit können diese Datenstromteilbereiche a_l[z] ausgehend von der Kennzeichnung des Datenstromteilbereichs a_l [x] rekursiv ge- kennzeichnet werden.
- Einem Datenstromteilbereich a_l[x] kann ein Wert v[x] zugeordnet werden, der beispielsweise dem durch a_l[x] im Bitstrom repräsentierten Wert entspricht. Bei einer Transformation, z.B. mit XSLT, kann dieser Wert verändert wer- den.
Die Referenzierung in Form einer Adressierung der Datenstromteilbereiche a_l[x] kann in einer Ausführung in einer der folgenden Möglichkeiten realisiert werden: Spezifikation des Anfangs und/oder Endes des Datenstrom- teilbereichs a_l [x] durch Abzählen von Einheiten vom Anfang des Datenstroms.
Spezifikation des Anfangs und/oder Endes des Datenstromteilbereichs a_l [x] durch Abzählen von Einheiten vom Anfang des vorhergehenden Datenstromteilbereichs a_l [w] . - Spezifikation des Anfangs und/oder Endes des Datenstromteilbereichs a_l[x] durch Abzählen von Einheiten vom Ende des vorhergehenden Datenstromteilbereichs a 1 [w] . Spezifikation des Anfangs und/oder Endes des Datenstromteilbereichs a_l[x] durch Abzählen von Einheiten vom Anfang des Datenstromteilbereichs a_l[a], in dem der Daten- stromteilbereich a_l[x] enthalten ist. - Spezifikation des Endes des Datenstromteilbereichs a_l[x] durch Abzählen von Einheiten vom Anfang des Datenstromteilbereichs a_l[x].
Ohne explizite Spezifikation des Anfangs des Datenstromteilbereichs a_l[x] kann spezifiziert werden, dass der An- fang des Datenstromteilbereichs a_l[x] sich dem Ende des vorhergehenden Datenstromteilbereichs a_l [w] anschließt o- der dem Anfang des Datenstromteilbereichs a_l[a] entspricht, wenn der Datenstromteilbereich a_l[x] als erster in dem Datenstromteilbereich a_l[a] enthalten ist. Die Spezifikationen dieser Werte kann durch Abzählen von Einheiten geschehen. Hierbei kann eine oder mehrere Einheiten, beispielsweise Bits oder Bytes, verwendet werden.
Es müssen in einer Beschreibung nicht alle der obigen Eigen- Schäften vorhanden sein, sondern die Strukturelemente, die diese Eigenschaften modellieren, können auch unabhängig voneinander eingesetzt werden.
Die Datenstromtransformationsbeschreibung XSL_a und die Da- tenstrombeschreibungstransformationsbeschreibung XSL_b können vorab generiert oder aber durch eine Verarbeitungseinheit, die beispielsweise zusätzliche übermittelte Informationen ü- ber das anfragende Endgerät in einem Client-Server-Szenario berücksichtigt, automatisch erzeugt werden.
Falls die erste Datenstrombeschreibung BSDL_1/1 für den ersten Datenstrom nicht gleich bei der Erzeugung des ersten Datenstroms a_l vom Encoder Enc bereitgestellt wird, kann sie entsprechend dem Verfahren im Stand der Technik mittels eines Parsers aus dem ersten Datenstrom a_l erzeugt werden. Im dargestellten Ausführungsbeispiel wird auf die Erzeugung von zweiten Datenstrombeschreibungen für den ersten und/oder zweiten Datenstrom vollständig verzichtet.
Die Datenstromtransformation des ersten Datenstroms a_l in den zweiten Datenstrom a_2 unter Verwendung der ersten Datenstrombeschreibung BSD_1/1 für den ersten Datenstrom und der Datenstromtransformationsbeschreibung XSL_a erfolgt in einem XSL- und Datenstromprozessor XBP.
Die Datenstrombeschreibungstransformation der ersten Datenstrombeschreibung BSD_1/1 für den ersten Datenstrom in die erste Datenstrombeschreibung BSD_2/1 für den zweiten Datenstrom erfolgt, insbesondere parallel dazu, in einem XSL- Prozessor XSLP.
Datenstromtransformation und Datenstrombeschreibungstransformation können auch in einem Prozess zusammengefasst sein.
Die Datenstromtransformationsbeschreibung XSL_a und die Datenstrombeschreibungstransformationsbeschreibung XSL_b können in einem Dokument zusammengefasst sein.

Claims

Patentansprüche
1. Verfahren zur Transformation eines ersten Datenstroms (a_l) in einen zweiten Datenstrom (a_2), bei dem - der erste Datenstrom (a_l) Datenstromteilbereiche enthält, die referenzierbar und/oder klassifizierbar sind,
- der zweite Datenstrom (a_2) Datenstromteilbereiche enthält, die referenzierbar und/oder klassifizierbar sind,
- eine erste Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom vorgesehen ist, in der zumindest einige der Datenstromteilbereiche im ersten Datenstrom (a_l) referenziert und/oder klassifiziert sind,
- der erste Datenstrom (a_l) durch eine Datenstromtransformation in den zweiten Datenstrom (a_2) transformiert wird, dadurch gekennzeichnet, dass eine erste Datenstrombeschreibung (BSD_2/1) für den zweiten Datenstrom erzeugt wird, in der zumindest einige der Datenstromteilbereiche im zweiten Datenstrom (a_2) referenziert und/oder klassifiziert sind.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die erste Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom durch eine Datenstrombeschreibungstransforma- tion in die erste Datenstrombeschreibung (BSD_2/1) für den zweiten Datenstrom transformiert wird.
3. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Erzeugen der ersten Datenstrombeschreibung (BSD_2/1) für den zweiten Datenstrom parallel zur Datenstromtransformation erfolgt.
4. Verfahren nach zumindest einem der Ansprüche 1 und 2, dadurch gekennzeichnet, dass das Erzeugen der ersten Datenstrombeschreibung (BSD_2/1) für den zweiten Datenstrom sowie die Datenstromtransformation in einem gemeinsamen Prozess erfolgt.
5. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der erste Datenstrom (a_l) unter Verwendung der ersten Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom in den zweiten Datenstrom (a_2) transformiert wird.
6. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der erste Datenstrom (a_l) unter Verwendung einer Datenstromtransformationsbeschreibung (XSL_a) in den zweiten Datenstrom (a_2) transformiert wird.
7. Verfahren nach zumindest Anspruch 2, dadurch gekennzeichnet, dass die erste Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom unter Verwendung einer Datenstrombeschrei- bungstransformationsbeschreibung (XSL_b) in die erste Datenstrombeschreibung (BSD_2/1) für den zweiten Datenstrom trans- formiert wird.
8. Verfahren nach zumindest den Ansprüchen 6 und 7, dadurch gekennzeichnet, dass die Datenstromtransformationsbeschreibung (XSL_a) zumin- dest im Wesentlichen gleich der Datenstrombeschreibungstrans- formationsbeschreibung (XSL_b) ist.
9. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zumindest einer der Datenströme (a_l, a_2) ein Bit-, Medien-, Audio-, Bild- und/oder Videostrom ist.
10. Verfahren nach zumindest einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass zumindest eine Datenstrombeschreibung (BSD_1/1, BSD_2/1) zumindest teilweise in XML ist.
11. Verfahren nach zumindest Anspruch 6 oder 7, dadurch gekennzeichnet, dass die Datenstromtransformationsbeschreibung (XSL_a) und/oder die Datenstrombeschreibungstrans- formationsbeschreibung (XSL_b) in XSL und/oder in einer Scriptsprache verfasst ist.
12. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der zweite Datenstrom (a_2) unter Verwendung der ersten Datenstrombeschreibung (BSD_2/1) für den zweiten Datenstrom in einen dritten Datenstrom transformiert wird.
13. Verfahren, insbesondere nach zumindest einem der vorhergehenden Ansprüche, zur Transformation eines ersten Datenstroms (a_l) in einen zweiten Datenstrom (a_2) bei dem
- der erste Datenstrom (a_l) Datenstromteilbereiche enthält, die referenzierbar und/oder klassifizierbar sind, - der zweite Datenstrom (a_2) Datenstromteilbereiche enthält, die referenzierbar und/oder klassifizierbar sind,
- eine erste Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom vorgesehen ist, in der zumindest einige der Datenstromteilbereiche dem ersten Datenstrom (a_l) referenziert und/oder klassifiziert sind,
- der erste Datenstrom (a_l) durch eine Datenstromtransformation in den zweiten Datenstrom (a_2) transformiert wird,
- der erste Datenstrom (a_l) unter Verwendung der ersten Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom in den zweiten Datenstrom (a_2) transformiert wird, dadurch gekennzeichnet, dass die erste Datenstrombeschreibung (BSD_1/1) für den ersten Datenstrom für die Datenstromtransformation als Look-up- Tabelle fungiert.
14. Vorrichtung, die eingerichtet ist, ein Verfahren nach zumindest einem der vorhergehenden Ansprüche auszuführen.
15. Programmprodukt für eine Datenverarbeitungsanlage, das Softwarecodeabschnitte enthält, mit denen ein Verfahren nach zumindest einem der Ansprüche 1 bis 13 auf einer Datenverarbeitungsanlage ausgeführt werden kann.
EP03722289A 2002-04-26 2003-04-17 Automatisierte anpassung und transformation von medienströmen Withdrawn EP1500246A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10218813A DE10218813B4 (de) 2002-04-26 2002-04-26 Verfahren zur Transformation eines Medienstroms in einen zweiten Medienstrom, Vorrichtung und Programmprodukt zur Ausführung des Verfahrens
DE10218813 2002-04-26
PCT/DE2003/001306 WO2003092238A1 (de) 2002-04-26 2003-04-17 Automatisierte anpassung und transformation von medienströmen

Publications (1)

Publication Number Publication Date
EP1500246A1 true EP1500246A1 (de) 2005-01-26

Family

ID=29224808

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03722289A Withdrawn EP1500246A1 (de) 2002-04-26 2003-04-17 Automatisierte anpassung und transformation von medienströmen

Country Status (4)

Country Link
EP (1) EP1500246A1 (de)
AU (1) AU2003229522A1 (de)
DE (1) DE10218813B4 (de)
WO (1) WO2003092238A1 (de)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7114147B2 (en) * 2000-03-09 2006-09-26 Electronic Data Systems Corporation Method and system for reporting XML data based on precomputed context and a document object model
WO2001069936A2 (en) * 2000-03-13 2001-09-20 Sony Corporation Method and apparatus for generating compact transcoding hints metadata
WO2001076174A2 (en) * 2000-04-04 2001-10-11 Dimon-Hugbunadarhus Ehf. A system for wireless communication of data between a web server and a device using a wireless application protocol
US7702995B2 (en) * 2000-04-24 2010-04-20 TVWorks, LLC. Method and system for transforming content for execution on multiple platforms
CN1618234A (zh) * 2001-11-26 2005-05-18 康宁克里克菲利浦电子股份有限公司 用于使用模式而在句法上分析位流的方法以及根据其来生成位流的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03092238A1 *

Also Published As

Publication number Publication date
DE10218813B4 (de) 2005-12-08
AU2003229522A1 (en) 2003-11-10
DE10218813A1 (de) 2003-11-13
WO2003092238A1 (de) 2003-11-06

Similar Documents

Publication Publication Date Title
DE10218812A1 (de) Generische Datenstrombeschreibung
EP1522028B1 (de) Verfahren und vorrichtungen zum kodieren/dekodieren von strukturierten dokumenten, insbesondere von xml-dokumenten
EP1344403B1 (de) Verfahren zur verbesserung der funktionalität der binären repräsentation von mpeg-7 und anderen xml-basierten inhaltsbeschreibungen
DE60123596T2 (de) Verfahren zur Komprimierung einer Baumhierarchie, zugehöriges Signal und Verfahren zur Dekodierung eines Signals
DE10297520T5 (de) Transformieren von Multimediadaten zur Abgabe an mehrere heterogene Geräte
WO2006056531A1 (de) Verfahren zur transcodierung sowie transcodiervorrichtung
DE10120806B4 (de) Vorrichtung und Verfahren zur Übertragung von multimedialen Datenobjekten
DE10309336B4 (de) Verfahren zur Codierung eines strukturierten Dokuments
EP1869860A1 (de) Verfahren zum synchronisieren von inhaltsbezogenen datensegmenten von dateien
DE10218813B4 (de) Verfahren zur Transformation eines Medienstroms in einen zweiten Medienstrom, Vorrichtung und Programmprodukt zur Ausführung des Verfahrens
DE102015115797B4 (de) Verfahren zum Erzeugen von elektronischen Dokumenten
EP1435025B1 (de) System und verfahren zum zugriff auf ein gerät, insbesondere ein automatisierungsgerät mit einer standardisierten schnittstelle
EP1435026B1 (de) System und verfahren zur datenausgabe eines geräts, insbesondere eines automatisierungsgerät über eine standardisierte schnittstelle mit variablenersetzung über einen echoserver
DE10248758B4 (de) Verfahren und Vorrichtungen zum Encodieren/Decodieren von XML-Dokumenten
DE102011112076A1 (de) Verfahren zum Erzeugen eines Druckproduktes
WO2022013114A1 (de) Bereitstellung und anzeige von videodaten
WO2012171965A1 (de) Verfahren und vorrichtungen zum austausch von daten
DE10138532A1 (de) Verfahren zum dynamischen, priorisierbaren und wahlfreien Zugriff auf Bildbereiche in JPEG2000-komprimierten Bildern sowie darauf aufbauende Client-Server-Architektur
DE102018218656A1 (de) Messbedingungskorrektur für Digitaldruckmaschinen
EP1687984A1 (de) Verfahren zum erzeugen und/oder verarbeiten einer datenstrombeschreibung
DE102005004132A1 (de) Verfahren zur Aufbereitung und Komprimierung von Videobildern
DE4344836A1 (de) Adaptives Datenübertragungssystem
DE102007012389A1 (de) Verfahren zur Handhabung von Metadaten und Set-Top-Box-Vorrichtung
DE19911462A1 (de) Verfahren zur Übertragung von Computerdaten an ein Ausgabegerät
WO2004051502A2 (de) Verfahren zur codierung eines xml-basierten dokuments

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20041006

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HEUER, JOERG

Inventor name: HUTTER, ANDREAS

Inventor name: HELLWAGNER, HERMANN

Inventor name: KOSCH, HARALD

Inventor name: TIMMERER, CHRISTIAN

RIN1 Information on inventor provided before grant (corrected)

Inventor name: HEUER, JOERG

Inventor name: HUTTER, ANDREAS

Inventor name: HELLWAGNER, HERMANN

Inventor name: KOSCH, HARALD

Inventor name: TIMMERER, CHRISTIAN

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20140305

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

INTG Intention to grant announced

Effective date: 20140526

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20141007