This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
Freelance translator and/or interpreter, Verified member
Data security
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
English to Italian: SOURCES General field: Law/Patents Detailed field: Law: Contract(s)
Source text - English Fatto salvo quanto previsto al successivo articolo 3, le parti si danno vicendevolmente atto che il Fornitore avra' la piu' completa autonomia nell'esecuzione del presente contratto e nella prestazione dei Servizi, ferma restando il rispetto delle tempistiche e delle modalita' di esecuzione dei Servizi.
Translation - Italian Subject to the provisions of article 3) hereunder, the parties confirm to each other that the Supplier shall enjoy the fullest possible autonomy in giving effect to the present contract and in performing the Services, provided that the aforesaid is done in compliance with the time scope and methods of implementation of the Services.
English to Italian: الانتخابات البرلمانية المصرية، الواقع واحتمالات المستقبل General field: Other Detailed field: Government / Politics
Source text - English انتهت يوم الأحد، 5 ديسمبر/ كانون أول، الجولة الثانية والأخيرة من الانتخابات البرلمانية المصرية، التي حسمت مصير المقاعد التي لم تحسم في الجولة الأولى، التي عقدت في الأحد السابق. وطبقاً للنتائج الرسمية، فقد فاز الحزب الوطني الديمقراطي (الحاكم) بأغلبية كاسحة من مقاعد البرلمان، وتجاوزت نسبة ما حصل عليه من مقاعد 83% (متوقع أن تزداد بعد أن ينضم إليه حوالي 70 عضوا من الوطني رشحوا أنفسهم كمستقلين خروجا على تعاليم الحزب)، في حين لم تفز أحزاب المعارضة التي شاركت في الجولتين الأولى والثانية سوى بـ 15 مقعدا فقط، ولم تحصل جماعة الإخوان المسلمين على أي مقعد بعد أن كان لها في البرلمان السابق 88 عضوا.
ستنظر هذه الورقة إلى سياق هذه الدورة من الانتخابات البرلمانية المصرية، وإلى الدلالات التي تحملها نتائجها على مستقبل الحكم وعلاقته بقوى المعارضة، كما ستشير إلى التحديات المقبلة التي تواجه الحياة السياسية المصرية.
Translation - Italian On Sunday, 5 December / Kanun I, the second and last session of Egyptian parliamentary elections was concluded. This session decisively traced the way in which the seats which had yet to be filled in at the conclusion of the first session, held on the preceding Sunday, would be allocated.
In accordance with the official results, the ruling Democratic National Party cleanly swept the vast majority of parliamentary seats, with a share in excess of 83% (a percentage that is expected to increase further, when the holders of such seats will be joined by approximately 70% of the members of the Democratic National Party who had presented their candidatures as part of an independent list, contrary to the party’s teachings).
At the same time, the opposition parties which had taken part in both the first and the second electoral sessions did not win more than 15 seats. As for the Muslim Brotherhood organization, it did not manage to win a single seat, after it had boasted 88 MP’s in the previous legislature.
This paper shall examine this round of Egyptian parliamentary elections, and shall further inspect the indications ensconced in their results, as far as the future of the Egyptian government and its relationship with the opposition forces are concerned. In the course of its analysis, this paper shall also make reference to the challenges that lie ahead of the Egyptian political life.
Italian to English: Comparsa di costituzione General field: Law/Patents Detailed field: Law: Patents, Trademarks, Copyright
Source text - Italian 1 EP 1 925 142 B1
1. EP 1 925 142 B1 (di seguito “EP ‘142”) è stato depositato il 22/8/2006, rivendicando la priorità della domanda provvisionale di brevetto americana con n. di serie 60/710,193 del 23/8/2005, ed è stato concesso il 28/10/2015 (doc. …).
2. Non è stata presentata alcuna opposizione contro il brevetto.
2 Il contesto tecnico
3. Come ormai noto, nel campo delle trasmissioni digitali le informazioni da trasmettere sono organizzate a pacchetti di dati, che vengono separatamente inviati nella rete per essere poi riassemblati all’arrivo a destinazione.
4. Per convenzione, la lunghezza dei singoli pacchetti è spesso data in numero di “ottetti” che compongono il pacchetto, dove un ottetto è definito come composto da otto bit (un bit è la dimensione minima di informazione di un dato digitale e che può assumere solo i valori 0 oppure 1). L’ottetto in sostanza è quello che oggigiorno viene generalmente indicato come “byte” (cfr. doc. … https://it.wikipedia.org/wiki/Byte).
5. Un generico pacchetto è quindi facilmente visualizzabile graficamente come una “tabella”, nella quale le righe sono composte ciascuna da un ottetto (un “byte”) di otto bit, che impilati formano il pacchetto.
6. Naturalmente, ogni pacchetto deve contenere in sé anche le informazioni necessarie per essere correttamente riassemblato una volta giunto a destinazione.
7. Nelle trasmissioni digitali tale informazione è contenuta nella cosiddetta “intestazione” o “header” di ciascun pacchetto, vale a dire un assieme di dati ausiliari che il sistema che forma i pacchetti aggiunge in testa al pacchetto, che poi prosegue con il cosiddetto “carico pagante” o “payload” del pacchetto, vale a dire le effettive informazioni digitali da trasportare.
8. In una moderna rete di telecomunicazioni, come è ad esempio la rete di telefonia cellulare, per vari motivi di efficienza e di gestione, il processo complessivo di formazione dei pacchetti di dati effettivamente da trasmettere nella rete è composto come un sistema a strati (o “layer”) dove ogni layer è formato da un “entità” che esegue una particolare funzione di trattamento dei dati che riceve dallo strato precedente e che, una volta trattati, passa allo strato successivo.
3 L’oggetto di EP ‘142
9. Il brevetto in questione (nel seguito indicato per brevità anche come EP ‘142) ha per oggetto alcune particolarità dello strato intermedio noto come RLC (Radio Link Control) che sovraintende a varie funzioni di controllo del radiocollegamento e che, a tale scopo, riceve dal layer a lui superiore un flusso di pacchetti (in gergo chiamati “Service Data Unit” o, in sigla, “SDU” o “RLC SDU”), che per loro natura hanno dimensioni variabili, e li tratta per formare nuovi pacchetti di dimensioni prestabilite (in gergo chiamati “Protocol Data Unit” del RLC o, in sigla “PDU” o “RLC PDU”) da passare allo strato successivo.
10. Le dimensioni dei pacchetti RLC PDU sono scelte fra un predefinito numero di possibili dimensioni in base alle caratteristiche del canale fisico di trasmissione realmente impiegato e a specifiche esigenze di trasporto della rete. Ciò porta al fatto che in ciascun pacchetto RLC PDU può essere presente un intero pacchetto RLC SDU, più di un pacchetto RLC SDU, o ancora solo dei segmenti di un pacchetto RLC SDU di ingresso, a seconda delle dimensioni dei pacchetti RLC SDU in ingresso rispetto alle dimensioni scelte per i pacchetti RLC PDU in uscita.
11. Nel header di ciascun pacchetto prodotto dal layer RLC è perciò innanzitutto necessario inserire l’informazione della lunghezza dei dati inseriti nel pacchetto, per poterli correttamente recuperare. Tale informazione di lunghezza (in genere indicata in sigla come “LI”, acronimo che sta per “Length Indicator”) è in sostanza un numero (rappresentato in notazione binaria come una sequenza di bit nell’ottetto dedicato) e che nell’header del pacchetto indica quanti ottetti di dati di un pacchetto RLC SDU sono contenuti nello specifico pacchetto RLC PDU.
12. In uno stesso header di un pacchetto RLC PDU possono anche essere presenti più informazioni di lunghezza LI, poiché come si è detto in uno stesso pacchetto RLC PDU possono anche essere presenti più gruppi di dati di successivi pacchetti di ingresso al layer RLC. Per segnalare tale eventualità a ciascun LI può seguire un bit, chiamato di estensione (da cui il fatto che tale elemento è indicato in gergo come “E-bit” o anche solo “E”), che ha il compito di indicare se quello che segue è un altro LI (impostando l’E-bit a 1), oppure se lo LI è l’ultimo dell’header, dopo il quale inizia il “carico pagante” (in tal caso l’E-bit è impostato a 0).
13. In sostanza, una struttura di un pacchetto RLC PDU può essere quella della figura seguente, con un primo ottetto che contiene il numero di sequenza del pacchetto (anch’esso terminato con un E-bit che indica che segue un LI) e poi, in ogni ottetto successivo, un eventuale LI (Length indicator) con il proprio E-bit che indica se segue un altro LI, fino all’ultimo LI che è seguito da un E-bit=0 per indicare che subito dopo cominciano i dati del carico pagante.
Fig. 1. Struttura di un pacchetto RLC PDU secondo la tecnica nota
14. Come si vede nella figura, se avanza spazio nel pacchetto dopo avervi inserito tutti i dati utili, possono venire inseriti uno o più ottetti di riempimento (PAD) privi di significato e che all’arrivo verranno semplicemente scartati.
15. Per permettere un corretto riassemblaggio delle informazioni all’arrivo, non basta però indicare solo le lunghezze in numero di ottetti dei segmenti di dati entro il pacchetto, ma è necessario anche indicare quantomeno se quei segmenti sono solo la parte iniziale, finale o intermedia di un pacchetto di ingresso RLC SDU, che è stato necessario suddividere e sarà poi necessario assemblare con quanto contenuto in un successivo pacchetto, oppure se sono già un pacchetto completo RLC SDU.
16. Come viene immediato pensare, a tal fine basterebbe naturalmente inserire nell’header del pacchetto, oltre agli indicatori di lunghezza LI, anche un ulteriore separato indicatore per segnalare i possibili casi di riempimento del pacchetto RLC PDU.
17. Al contrario, la tecnica nota che è citata nel brevetto EP ‘142 non vuole aggiungere all’header ulteriori indicatori oltre agli LI e tenta di inserire entrambe le indicazioni all’interno delle sole informazione di lunghezza LI del pacchetto, ricorrendo ad un trucco alquanto complicato.
18. Infatti, sempre secondo la tecnica nota menzionata nel brevetto, una volta selezionate alcune lunghezze fra tutte le possibili indicazioni di lunghezza da 0 al massimo numero che può essere indicato in una LI, si impongono delle condizioni al layer RLC in modo che non possa creare pacchetti con le lunghezze scelte, e si usano tali lunghezze (oramai “fittizie” o speciali) per indicare i voluti casi di riempimento invece che lunghezze reali dei dati nel pacchetto.
19. In sostanza, il pacchetto RLC PDU conterrà nell’header indicatori LI “reali” di lunghezza e indicatori LI “fittizi” di lunghezza. All’arrivo, i primi saranno interpretati dal sistema per estrarre dai pacchetti i dati in essi contenuti e i secondi (riconosciuti perché le lunghezze che indicano sono state preventivamente stabilite come non possibili) per sapere se e come raggruppare nuovamente i dati fra loro.
20. Lo stesso EP ‘142 cita che già nella tecnica nota le reali lunghezze più frequenti dei pacchetti prodotti dall’entità RLC sono 11, 15, 36, 40 e 98 ottetti. Basta perciò scegliere qualche valore di lunghezza differente da tali lunghezze e dargli il significato di un tipo di riempimento.
21. Con tale modo di procedere può sorgere però un problema.
22. Infatti, per particolari combinazioni fra le dimensioni (vale a dire il numero di ottetti) dei pacchetti RLC PDU che si susseguono e le dimensioni dei pacchetti RLC SDU da inserire in essi, eventualmente segmentandoli, può accadere che in un pacchetto formato dall’RLC vi sia ad esempio lo spazio per inserire nell’header del pacchetto l’indicatore di lunghezza fittizio che è stato scelto per indicare l’inizio di una sequenza, ma non vi sia spazio sufficiente per inserire nell’header anche l’indicatore di lunghezza fittizio che indica che tale pacchetto contiene anche la fine di una sequenza di segmenti di dati.
23. La tecnica nota che viene citata nel brevetto EP ‘142 risolveva il problema prevedendo, in tali sfavorevoli casi di mancanza di spazio, di inserire nel pacchetto successivo un indicatore di lunghezza fittizio che indica la fine della sequenza di dati nel pacchetto precedente.
24. Tale soluzione risolve il problema precedente ma genera un ulteriore problema, facilmente immaginabile: nel caso sfortunato che si presenti la mancanza di spazio in un pacchetto RLC PDU e quindi l’indicatore di lunghezza fittizio che indica la fine di una sequenza venga posto nel pacchetto successivo, il ricevitore che riceve i pacchetti e deve interpretarli per estrarne i dati in essi contenuti, riassemblandoli, non può sapere se una sequenza è terminata fino a che non riceve il pacchetto successivo a quello nel quale la sequenza di dati effettivamente termina. Se nella trasmissione dei pacchetti viene perso per qualche motivo proprio tale pacchetto successivo, il ricevitore non potrà sapere di avere già ricevuto una sequenza di dati completa.
25. E’ in questo contesto che si inserisce la soluzione proposta nel brevetto EP ‘142.
26. In sostanza, il brevetto EP ‘142 si allinea alla idea iniziale della tecnica nota, vale a dire quella di impiegare solo gli indicatori di lunghezza LI con indicazioni reali e indicazioni fittizie di lunghezza, e propone semplicemente di assegnare ad alcune lunghezze fittizie significati più estesi, in modo che, ad esempio, si possa indicare che in un pacchetto RLC PDU è presente sia l’inizio che la fine di una sequenza impiegando un solo indicatore di lunghezza fittizio anziché due, risolvendo così il problema di spazio mancante per due indicatori che affliggeva la tecnica nota dalla quale EP ‘142 partiva.
27. Per chiarire ciò, ci si può affidare all’esempio mostrato nella parte inferiore della figura 1 di EP ‘142, qui sotto riprodotta:
Fig. 2. Estratto della Fig. 1 EP ‘142
28. Tale figura mostra a confronto due pacchetti sequenziali nei quali è possibile inserire un solo indicatore LI fittizio ma che contengono l’intera sequenza di dati da trasmettere. A sinistra i due pacchetti sono ottenuti con la soluzione della tecnica anteriore da cui parte EP ‘142 mentre a destra sono ottenuti con la soluzione proposta nel brevetto.
29. Tutti i pacchetti contengono nel primo ottetto il proprio numero identificativo (genericamente indicato con SN+1 nel primo pacchetto e SN+2 nel secondo) seguito dal bit E=1 che indica che segue un LI e poi l’LI stesso seguito da un bit E=0 per indicare che seguono i dati.
30. In entrambe le soluzioni l’indicatore LI del primo pacchetto è uguale al numero binario “1111100” che in decimale corrisponde al numero 124 che rappresenta una lunghezza fittizia. La differenza è però che nel caso a sinistra a tale lunghezza fittizia è stato assegnato solo il significato di “nel primo ottetto di dati in questo pacchetto inizia una nuova sequenza di dati”.
31. È perciò necessario mettere un indicatore di lunghezza fittizio LI nel pacchetto successivo (in questo caso è stato scelto “0000000”), con il significato: “nel pacchetto precedente nell’ultimo ottetto di dati terminava una sequenza di dati e in questo pacchetto il primo ottetto di dati ne inizia una nuova”.
32. È evidente che se tale secondo pacchetto andasse perduto, il sistema ricevente non potrebbe sapere del termine della sequenza di dati precedente.
33. Nell’esempio a destra si vede invece la soluzione proposta nel brevetto: alla lunghezza riservata rappresentata dal numero binario “1111100” è stato semplicemente aggiunto al significato secondo la tecnica nota (“il primo ottetto di dati in questo pacchetto inizia una nuova sequenza di dati”) anche l’ulteriore significato “e l’ultimo ottetto in questo pacchetto termina una sequenza di dati”. Basta perciò solo tale indicatore nel primo pacchetto e non è necessaria una ulteriore indicazione per esso nel successivo pacchetto. Tale nuovo significato viene così impiegato ogni volta che in un pacchetto inizia e anche finisce una sequenza di dati (come ad esempio mostrato nel successivo pacchetto SN+2 a destra in figura 1).
34. La soluzione proposta in EP ‘142 è, quindi, a dir poco banale, essendo niente più che una soluzione di progetto al problema, tipico di tutte le trasmissioni di dati a pacchetto, dell’eventuale perdita del pacchetto successivo. Tale problema viene affrontato secondo la struttura dei pacchetti PDU utilizzata nel protocollo di comunicazione dello standard allora vigente, utilizzando gli elementi lì disponibili (gli indicatori di lunghezza LI), senza modificarne la struttura. Inoltre, nei casi dove non c’è un problema di spazio nel header, la soluzione descritta nel brevetto è identica a quella della tecnica nota menzionata nello stesso brevetto. A tale proposito si vedano ad esempio le figure 2, 4, 9 o anche i primi due pacchetti in alto delle figure 1, 3, 7, 8 e 12, dove il funzionamento del sistema precedente (a sinistra) e di quello secondo l’invenzione (a destra) è assolutamente identico, come sono identiche le figure degli esempi.
3.1 Le rivendicazioni di EP1925142
35. La rivendicazione 1 del brevetto recita:
1. Metodo comprendente:
inserire, in un’entità di controllo del radiocollegamento, RLC, almeno una unità dati di servizio (SDU) in una unità dati di protocollo (PDU) avente una dimensione appropriata;
caratterizzato dal fatto di comprendere ulteriormente:
a) fornire almeno un indicatore comprendente un indicatore di lunghezza (LI) per indicare che
a1) un primo ottetto di dati dell’unità dati di protocollo (PDU) è un primo ottetto di una prima unità dati di servizio (SDU1) e che
a2) almeno un altro ottetto dell’unità dati di protocollo (PDU) è l’ultimo ottetto di un’altra unità dati di servizio (SDU2),
b) la prima unità dati di servizio (SDU1)
b1) coincidendo con o
b2) essendo diversa
dall’altra unità dati di servizio (SDU2),
c) in cui l’almeno un altro ottetto è l’ultimo ottetto dell’unità dati di protocollo (PDU).
36. Per chiarezza si sono qui aggiunte fra parentesi le sigle PDU, SDU, LI, SDU1 e SDU2 e si sono divise in paragrafi le varie parti della rivendicazione.
37. La parte introduttiva della rivendicazione che precede il “caratterizzato dal fatto di..” semplicemente afferma che, secondo il metodo, l’entità RLC riceve pacchetti di dati (SDU) e li inserisce nei pacchetti che crea (i propri pacchetti PDU), come lo stesso brevetto definisce essere ovviamente il processo realizzato da una qualsiasi entità RLC già ben nota al tempo del deposito del brevetto.
38. La parte dopo il “caratterizzato dal fatto di” è alquanto involuta, ma si vede che essa, in sostanza, rivendica il fatto che un indicatore di lunghezza (ossia, ovviamente, un indicatore di lunghezza LI, come evidente dalla descrizione e come in ogni caso intrinseco al sistema di trasmissione cui si inseriva la soluzione di EP ‘142) deve poter indicare i due casi (ovviamente come indicatore di lunghezza “fittizio”):
CASO 1:
a1) l’inizio dei dati nel pacchetto è l’inizio della SDU1; e
a2+c): la fine dei dati nel pacchetto è la fine della SDU2;
con
b1) SDU1 e SDU2 che coincidono (sono la stessa SDU) e perciò:
l’inizio e la fine della SDU sono rispettivamente l’inizio e la fine dei dati nel pacchetto;
CASO 2:
a1) l’inizio dei dati nel pacchetto è l’inizio della SDU1; e
a2+c): la fine dei dati nel pacchetto è la fine della SDU2;
con
b1) SDU1 e SDU2 diverse e perciò:
SDU1 e SDU2 sono contenute una dietro l’altra nello stesso pacchetto.
39. In altri termini, secondo il metodo della rivendicazione 1, in un pacchetto PDU prodotto dal layer RLC deve esistere un indicatore di lunghezza fittizio che anziché indicare una lunghezza reale indica che tale pacchetto include SDU che iniziano entro il pacchetto e che finiscono con l’ultimo ottetto dello stesso pacchetto.
40. Ciò è esattamente quanto è descritto negli esempi della descrizione del brevetto e nessun’altra interpretazione della rivendicazione 1 del brevetto è possibile, non esistendo alcun differente esempio o una diversa spiegazione nell’intero testo descrittivo del brevetto.
41. Si è già vista la banalità della scelta, oggetto del brevetto e da esso rivendicata nella prima rivendicazione indipendente.
42. Rivolgendo ora l’attenzione alle rivendicazioni successive, la rivendicazione 2 segnala che l’entità RLC è una entità RLC che opera in modalità senza riscontro.
43. E’ però da notare che (fin dal titolo) in tutto il brevetto è espressamente dichiarato che l’invenzione è solo per l’ottimizzazione delle intestazioni delle unità dati di protocollo in modalità senza riscontro. Si veda ad esempio a pagina 5 dove si legge: “La presente invenzione riguarda l’ottimizzazione delle intestazioni delle unità dati di protocollo (PDU, Protocol Data Unit) in modalità senza riscontro (UM, Unacknowledged Mode)”. Tale rivendicazione 2 appare perciò ridondante perché la caratteristica in essa dichiarata è già implicitamente una caratteristica essenziale della rivendicazione 1.
44. La rivendicazione 3 semplicemente segnala che l’indicatore di lunghezza può essere di 7bit e/o 15bit, che sono appunto le due dimensioni in bit degli indicatori di lunghezza LI della tecnica nota precedente al brevetto.
45. Le rivendicazioni 4, 5, 6, 7 e 8 semplicemente elencano esempi di quali indicazioni di lunghezza a 7bit possono essere riservate per l’indicatore di lunghezza “fittizio” da usare come indicatore della condizione rivendicata nella rivendicazione 1. La scelta di un numero piuttosto che un altro è però assolutamente arbitraria, non portando ad alcun vantaggio particolare: si tratta solo di scegliere un numero qualsiasi che non si vuole impiegare come lunghezza reale di un pacchetto RLC PDU. Non vi è perciò alcun rilevante significato tecnico nella scelta dei valori menzionati in tali rivendicazioni.
46. Le rivendicazioni 9, 10, 11 e 12 semplicemente elencano ulteriori esempi di quali indicazioni di lunghezza possono alternativamente essere riservate per l’indicatore di lunghezza “fittizio” quando l’indicatore di lunghezza è di 15bit. Anche in questo caso la scelta è assolutamente arbitraria e anche tali rivendicazioni non aggiungono alcun rilevante significato tecnico.
47. Infine, la rivendicazione 13 di metodo rivendica semplicemente che si può ulteriormente fornire una segnalazione di livello superiore ad un apparato utente per identificare se l’indicatore di lunghezza è in uso o meno. Tale caratteristica non ha alcuna spiegazione nell’intero testo brevettuale e manca di qualsiasi supporto descrittivo che permetta di comprenderla o di metterla in pratica. Essa, inoltre, non è (non a caso) neanche menzionata nel parere tecnico sub avv. doc. 6, e, conseguentemente, non è stata azionata nel presente giudizio.
48. Le rivendicazioni 14-25 di apparato differiscono dalle rivendicazioni 1-12 di metodo solo per l’aggiunta di generici “mezzi per” mettere in pratica il metodo delle rivendicazioni 1-12. Le considerazioni fatte per le rivendicazioni d metodo 1-12 possono perciò essere riversate integralmente sulle rivendicazioni 14-25, e, in particolare, sulle rivendicazioni 14 e 15, le uniche rivendicazioni di apparato espressamente menzionate nell’avv. doc. 6 e quindi azionate nel presente giudizio.
49. La rivendicazione 26, anch’essa menzionata nell’avv. doc. 6, semplicemente precisa che “i mezzi per inserire comprendono un’unità di inserimento e i mezzi per fornire comprendono un’unità di fornitura”, con una evidente definizione tautologica che certo non può contribuire a differenziare tale rivendicazione dalle precedenti.
50. Infine, l’ultima rivendicazione 27, anch’essa menzionata nell’avv. doc. 6, semplicemente menziona che il metodo delle rivendicazioni precedenti può essere realizzato con un programma informatico, senza ulteriori precisazioni. Anche tale rivendicazione non aggiunge alcun rilevante significato tecnico all’oggetto delle rivendicazioni indipendenti (qualsiasi metodo di formazione di pacchetti per le comunicazioni digitali è ovviamente implementato con un adatto programma informatico).
* *** *
4 EP ‘142 e lo standard LTE
51. Secondo controparte, EP ‘142 coprirebbe aspetti dello standard LTE e, per tale unico motivo, qualsiasi apparecchio funzionante secondo tale standard dovrebbe essere considerato automaticamente interferente con l’ambito di protezione del brevetto.
52. Si tratta quindi di verificare se le caratteristiche delle rivendicazioni sono previste o meno dallo standard LTE. Nel seguito ci si concentrerà sulla rivendicazione 14, come visto identica alla rivendicazione 1 (l’unica differenza essendo che la rivendicazione 14 rivendica l’apparato che realizza le fasi del metodo di cui alla rivendicazione 1), essendo solo questa la rivendicazione principale esaminata nel parere tecnico sub avv. doc. 6.
53. Secondo controparte (cfr. nuovamente avv. doc. 6), la specifica tecnica da prendere a riferimento per stabilire l’interferenza è la specifica 3GPP TS 36.322, versione 10.0.0 (nel seguito in breve “TS-322”, qui allegata come doc. …). Controparte anche precisa che “altre versioni, come ad esempio la più recente 15.1.0, contengono i medesimi dettagli tecnici in relazione a quanto rivendicato nel brevetto EP142”, confermando così la scelta della specifica tecnica a cui fare riferimento.
54. Secondo la specifica TS-322, in una prima modalità di funzionamento, detta TM (“Trasparent Mode”), i pacchetti RLC SDU che arrivano alla entità RLC sono direttamente trasferiti all’uscita senza alcuna modifica o aggiunta. Ciò è chiaramente indicato per esempio al paragrafo 5.1.1.1.1 di TS-322 che recita: “When submitting a new TMD PDU to lower layer, the transmitting TM RLC entity shall: - submit a RLC SDU without any modification to lower layer”. In pratica, l’entità RLC non opera alcun intervento di elaborazione e non aggiungere alcun header ai pacchetti che l’attraversano.
55. Non esiste perciò alcun header prodotto dall’entità RCL con qualsivoglia caratteristica. Esplicativa è anche la figura 6.2.1.2-1: TMD PDU, a pagina 22 di TS-322, qui sotto riprodotta, sulla struttura che deve avere un pacchetto nel modo TM e che mostra in modo incontestabile che in modalità TM i pacchetti in uscita dall’RLC sono di soli dati, senza alcun header:
Fig. 3. TMD PDU (pag. 22 di TS-322)
56. Quando l’RLC opera in modalità TM, non vi è perciò alcun “Indicatore di lunghezza” e nessuna necessità di individuare inizi o fine di sequenze di dati nei pacchetti prodotti, che sono l’oggetto del brevetto EP ‘142, e per conseguenza nessuna interferenza con il brevetto EP ‘142 può esistere quando un apparato LTE opera con il layer RCL in modalità TM.
57. Già questo fatto prova che un apparato LTE può funzionare senza alcuna interferenza con l’ambito di protezione di EP ‘142, con conseguente mancato assolvimento dell’onere della prova gravante su Sisvel.
58. Ma vi è ben di più. Si considerino infatti gli unici altri due possibili modi di funzionamento che può avere una entità RLC, vale a dire i modi UM (“Unacknoledged mode”) e AM (“Acknoledged mode”) .
59. In ciascuno dei due modi UM e AM, l’entità RLC provvede ad elaborare i pacchetti SDU entranti per farne il “carico pagante” dei propri pacchetti PDU in uscita, aggiungendo anche un corrispondente header.
60. Gli header dei due modi UM o AM sono fra loro differenti ma per entrambi i progettisti dello standard LTE hanno comunque fatto una scelta che è completamente diversa dalla soluzione che è oggetto del brevetto EP ‘142.
61. Infatti, come si è scritto più sopra, sia la tecnica nota citata nel brevetto sia la soluzione proposta nel brevetto stesso hanno scelto di impiegare gli stessi indicatori LI di lunghezza dei pacchetti per indicare anche il tipo di riempimento dei pacchetti. Secondo tale soluzione, l’header può contenere in una stessa posizione o un numero che rappresenta la lunghezza reale del pacchetto oppure un numero che rappresenta una lunghezza fittizia (non più utilizzabile come lunghezza reale) e che è da interpretare con un diverso significato, complicando però non poco la creazione e gestione dei pacchetti.
62. Al contrario, lo standard LTE abbandona completamente tale idea, con tutti i problemi che essa comporta, e, sia nel modo UM sia nel modo AM, impiega semplicemente degli indicatori di lunghezza LI nell’header sempre e solo per indicare le reali lunghezze dei gruppi di dati nei pacchetti e aggiunge sempre nell’header un nuovo elemento (chiamato “Framing Info”, vale a dire “informazione di composizione”, in breve FI) che serve esclusivamente per definire in quale caso di riempimento ricade il pacchetto RLC creato secondo lo standard LTE.
63. Tale elemento FI ha naturalmente una forma e un contenuto completamente differente da quella degli indicatori di lunghezza LI ed è inserito, una volta sola, in due bit del primo ottetto dell’header di ciascun pacchetto.
64. Per chiarire tale fatto, si riporta qui di seguito la figura “6.2.1.3-3: UMD PDU with 5 bit SN (odd number of LIs,i.e. K=1, 3, 5,…)” presente a pagina 23 di TS-322 che descrive la forma più generale di un pacchetto prodotto dall’entità RLC secondo lo standard LTE quando si utilizza il modo UM :
Fig. 4. UMD PDU con SN a 5 bit (pag. 23 di TS-322)
65. In tale figura è chiaramente visibile la composizione del pacchetto in modo UM secondo lo standard LTE, con l’header seguito dai dati (“Data”): la prima riga (il primo ottetto) del pacchetto contiene i due bit che costituiscono l’elemento FI, un bit con il parametro “E” e il numero seriale del pacchetto (SN) posto nei restanti 5 bit dell’ottetto.
66. Possono poi seguire gli indicatori di lunghezza LI, in numero qualsiasi. Tali indicatori LI sono numeri binari di 11 bit (perciò né 7bit né 15bit come richiesto in EP ‘142), ai quali è associato il bit E che segnala se segue un ulteriore LI (E=1) oppure no (E=0). Se gli LI sono in numero dispari allora alla fine dell’ultimo LI rimane dello spazio vuoto nell’ottetto, spazio che viene riempito semplicemente con dei bit qualsiasi di riempimento (“Padding”) fino a completare l’ultimo ottetto dell’Header.
67. Sempre secondo la norma LTE, esiste anche la possibilità di realizzare pacchetti con numero seriale del pacchetto (SN) a 10 bit, anziché 5bit. In tale caso, i primi tre bit del primo ottetto sono inutilizzati e vengono riempiti con tre zeri in modo da modificare solo il primo ottetto e mantenere invariata la disposizione degli ottetti seguenti rispetto alla disposizione con SN a 5 bit. Ciò è ben mostrato nella figura “6.2.1.3-5: UMD PDU with 10 bit SN (Odd number of LIs,i.e. K=1, 3, 5,…)” a pagina 24 di TS-322, qui di seguito riportata:
Fig. 5. UMD PDU con SN a 10 bit (pag. 24 di TS-322)
68. In tale figura, i tre bit iniziali inutilizzati e uguali a 0 sono indicati con R1.
69. Una struttura simile dell’header è imposta dallo standard LTE anche per i pacchetti RLC quando si opera nel modo AM, come ad esempio ricavabile dalla figura esplicativa “6.2.1.4-2: AMD PDU (Odd number of LIs, i.e. K=1, 3, 5,…)” presente a pagina 25 di TS-322, che mostra la struttura generale del pacchetto RCL in modo AM come imposta dallo standard LTE:
Fig. 6. AMD PDU (pag. 25 di TS-322)
70. Come si vede, l’unica differenza rispetto al pacchetto del modo UM è che lo standard LTE impone che nel modo AM il Serial Number SN sia in ogni caso a 10bit, e i primi tre bit del primo ottetto, che erano inutilizzati e marcati R1 nel modo UM, vengono impiegati nel modo AM per indicare ulteriori caratteristiche del pacchetto, utili per il funzionamento della rete nel modo AM, e che sono siglati con D/C (“Data/Control”, un elemento che segnala se il pacchetto è di dati o di semplice controllo), RF (“Re-segmentation Flag”, che segnala se il pacchetto è ri-segmentato o meno), P (“Polling Bit”, per richiedere o meno un rapporto di STATUS dal ricevitore).
71. Anche solo dalle figure qui sopra riprodotte e che mostrano la struttura generale degli header dei pacchetti imposta (senza possibilità di deroga) dallo standard LTE, risulta chiaro che tali pacchetti non hanno alcuna somiglianza con i pacchetti descritti in EP ‘142 (dove gli header erano semplicemente composti da un primo ottetto con un Serial Number SN e un bit E, seguiti da uno o più indicatori di lunghezza LI (alcuni veri, alcuni fittizi) che occupavano ciascuno o i primi sette bit di un ottetto terminato con un bit E (se gli LI erano a 7bit) o due ottetti di cui il secondo terminato con un bit E (se gli LI erano a 15bit), e nient’altro.
72. Inoltre, è tassativo che nessun indicatore LI dello standard LTE può avere una funzione differente da quella di indicare la vera lunghezza dei dati nel pacchetto. Gli LI da 11 bit imposti dallo standard LTE possono rappresentare liberamente tutte le lunghezze da 1 (in numero binario a 11bit è “000 0000 0001”) a 2047 (in numero binario a 11bit è “111 1111 1111”) senza alcuna limitazione. Infatti, nello standard LTE non esistono lunghezze riservate negli LI per indicare lunghezze fittizie, come è invece necessario sia secondo EP ‘142 sia secondo la tecnica nota in esso citata. Nello standard LTE solo la lunghezza 0 è, se vogliamo, riservata, ma solo perché in tale standard non ha senso indicare una lunghezza nulla del pacchetto.
73. Tutto ciò è chiaramente normato nel paragrafo 6.2.2.5 di TS-322, dove viene definito il contenuto che deve avere l’indicatore di lunghezza LI secondo lo standard LTE, vale a dire:
74. Traducendo (sottolineature aggiunte): “Il campo LI indica la lunghezza in byte del corrispondente elemento del campo dati presente nel PDU di dati RLC inviato/ricevuto da una entità RLC UM o AM. Il primo LI presente nell’Header della PDU di dati RLC corrisponde al primo elemento del campo dati presente nel campo dati nel PDU di dati RLC, il secondo LI presente nell’Header della PDU di dati RLC corrisponde al secondo elemento del campo dati presente nel campo dati nel PDU di dati RLC, e così via. Il valore 0 è riservato”. [Per chiarezza, si rammenta qui che con la sigla PDU è indicato il pacchetto dati prodotto dalla entità RLC]
75. Il campo LI resta perciò sempre e solo un numero che indica di quanti byte è composto ciascun gruppo di dati nel pacchetto prodotto dall’unità RLC.
76. E’ invece il separato elemento FI a due bit che rappresenta tutti i possibili casi di segmentazione dei dati fra i vari pacchetti RLC, applicando una soluzione molto più rapida e intuitiva di quella inutilmente complessa di EP ‘142.
77. Il paragrafo 6.2.2.6 a pagina 29 di TS-322, qui sotto riportato, impone la forma del campo FI:
78. Traducendo: “Il campo FI indica se una SDU RLC è segmentata all’inizio e/o alla fine di un campo dati. In particolare, il campo FI indica se il primo bute del campo dati corrisponde al primo byte di una SDU RLC e se l’ultimo byte del campo dati corrisponde all’ultimo byte di una SDU RLC. L’interpretazione del campo FI è fornito nella tabella 6.2.2.6-1” [Per chiarezza, si rammenta qui che con la sigla SDU RLC è indicato un pacchetto dati che giunge all’entità RLC e deve venire inserito, intero o segmentato, nel pacchetto prodotto dall’entità RLC].
79. La menzionata tabella 6.2.2.6-1, presente sempre a pagina 29 di TS-322, è anch’essa qui sotto riprodotta:
80. Come si vede, i valori a due bit associati a FI (colonna “value”) e i significati ad essi associati (colonna “Description”) non hanno alcuna somiglianza con valori “fittizi” a 7 o a 15 bit dell’indicatore di lunghezza LI secondo EP ‘142 (si vedano ad esempio per confronto le due tabelle di valori LI riservati riportate a pagina 15 della versione italiana di EP ‘142).
81. In sostanza, è chiaro che secondo lo standard LTE non è previsto, al fine di distinguere i vari casi di segmentazione dei dati, di “fornire almeno un indicatore comprendente un indicatore di lunghezza per indicare che un primo ottetto di dati dell’unità dati di protocollo è un primo ottetto di una prima unità dati di servizio e che almeno un altro ottetto dell’unità dati di protocollo è l’ultimo ottetto di un’altra unità dati di servizio”, nel senso richiesto da EP ‘142 (sia dalla rivendicazione 14 di apparato, l’unica rivendicazione indipendente azionata nel presente giudizio, che dalla identica rivendicazione 1 di metodo).
82. Ciò è confermato dallo stesso parere depositato da controparte, che appunto cerca di sostenere la contraffazione di EP ‘142 esclusivamente facendo riferimento al campo FI, ossia, come detto, a qualcosa di completamente diverso dall’indicatore di lunghezza di cui ad EP ‘142.
83. Per concludere, un qualsiasi dispositivo che implementa lo standard LTE, proprio perché deve sottostare a tale standard, non può interferire in alcun modo con EP ‘142, un brevetto che nulla ha a che vedere con quanto oggi previsto dallo standard LTE, che, come visto, rispetto alla tecnica anteriore, comporta un vero e proprio cambio di paradigma nella struttura dei pacchetti PDU, eliminando lo stesso contesto tecnico in cui si inseriva la soluzione di EP ‘142.
5 La nullità di EP ‘142
84. Abbiamo già detto della banalità, e quindi dell’intrinseca carenza di altezza inventiva, delle rivendicazioni indipendenti di EP ‘142, così come di tutte le rivendicazioni da esse dipendenti. Tale banalità risulta ancor più evidente alla luce della tecnica anteriore.
85. Ciò è innanzitutto indiscutibile ove si seguisse l’infondata argomentazione espressa nel parere sub avv. doc. 6, secondo cui, diversamente da quanto solo insegnato in EP ‘142, anche l’uso di un separato indicatore di riempimento diverso dall’indicatore di lunghezza LI (come prevede ad esempio lo standard LTE) ricadrebbe nella nozione di indicatore di lunghezza di cui ad EP ‘142. In tal caso, infatti, il brevetto sarebbe addirittura nullo per mancanza di novità.
86. Soluzioni che prevedevano di avere nell’header dei pacchetti prodotti dal layer RLC indicatori di lunghezza dei pacchetti e completamente separati indicatori di riempimento dei pacchetti erano infatti già note in varie forme precedentemente alla data del 23 agosto 2005 di priorità del brevetto EP ‘142.
87. Si vedano, a titolo esemplificativo, i seguenti documenti.
5.1 Documento R2-051441-13 (doc. …)
88. È una proposta pubblicata il 13 maggio 2005, fatta dalla società Qualcomm durante una riunione del gruppo di lavoro TSG-RAN WG2, responsabile in sede di standardizzazione per le specifiche del Radio Access Network che comprende anche il layer RLC.
89. Nelle prime righe del capitolo 2 “RLC LI optimization”, è sottolineato che in quella che al tempo era l’ultima versione delle specifiche RLC veniva già inserito nell’header di una PDU un indicatore di lunghezza “speciale” (fittizio) con valore “1111100” o (in caso di indicatore a 15bit) “111111111111100”, per indicare l’inizio di una SDU (e ciò in ragione dell’altrimenti inevitabile “ambiguity in case of a PDU loss”), e che in una precedente riunione del gruppo di lavoro, ossia la riunione RAN2#46bis tenutasi dal 4 all’8 aprile 2005 a Pechino, era stato concordato che lo schema poteva essere ulteriormente migliorato se si fosse impiegato nell’header dei pacchetti RLC PDU un separato indicatore (nominato “SDU beginning flag”) lungo 1bit per indicare “if the SDU’s first octet is located in the same PDU as its last octet”. In questo modo si sarebbe sia risparmiata la necessità dell’indicatore di lunghezza “speciale” “1111100” o “111111111111100”, sia evitato il problema di non poter stabilire la fine di una sequenza di dati se fosse stato perso il pacchetto successivo al pacchetto contenente l’ultima parte di tale sequenza.
5.2 Documento R2- 050969 (doc. …)
90. Tale documento, pubblicato l’8 aprile, contiene due proposte di ottimizzazioni per il layer RLC per il supporto VoIP, avanzate anch’esse dalla società Qualcomm nella riunione citata nel summenzionato documento R2-051441-13, ossia la riunione RAN2#46bis avvenuta a Pechino dal 4-8 aprile 2005.
91. La seconda delle due proposte (descritta nel paragrafo 3 “RLC SDU beginning signalling”) riguarda proprio le possibili soluzioni di un problema dello standard allora in uso, che non poteva stabilire se una intera sequenza era terminata o meno in un pacchetto PDU RLC nel caso di perdita di un altro pacchetto PDU RLC.
92. Per risolvere il problema, nel documento R2-050969 venivano prospettate due differenti possibili soluzioni. La prima soluzione era quella di introdurre un ulteriore indicatore di lunghezza LI “fittizio” in LI, per segnalare direttamente in un pacchetto se l’intera sequenza era contenuta in tale pacchetto.
93. La seconda soluzione era quella di usare un bit aggiuntivo (tolto dall’indicatore di lunghezza LI, che quindi diventava più corto di un bit) per indicare se l’inizio di una sequenza era contenuto nel pacchetto attuale oppure no. Ulteriori dettagli su tale bit aggiuntivo sono poi contenuti, come visto, nel citato documento R2-051441-13, che rinvia espressamente al documento R2-050969 (cfr. il rinvio ad esso già al § 1) ed è pertanto da considerarsi un tutt’uno con esso .
5.3 Documento R2-051311 (doc. …)
94. E’ una ulteriore proposta di ottimizzazione, pubblicata il 9 maggio 2005, fatta dalla società Samsung durante la stessa riunione 3GPP TSG-RAN WG-2 meeting #47 summenzionata.
95. Anche in tale ulteriore proposta è suggerita l’introduzione di un indicatore, completamente separato dall’Indicatore di lunghezza LI, che segnali se nel pacchetto è contenuta una intera sequenza di dati. Tale completa separazione è ancora più evidente se si considera che non veniva proposto di ricavare il bit aggiuntivo togliendolo dal numero di bit che compongono l’indicatore di lunghezza (come si suggeriva nelle proposte precedenti), ma si proponevano le due soluzioni alternative di accorciare di un bit il “Sequence number” SN, che indica la posizione dei pacchetti rispetto agli altri, oppure di assegnare un nuovo significato ad un altro indicatore di un bit presente nel pacchetto, vale a dire l’Espansion bit (E-bit), che normalmente segnala se l’header è finito o se prosegue.
96. In sostanza, il contenuto dei documenti di tecnica nota sopra menzionati rende evidente che ben prima della data di priorità di EP ‘142 era già ben nota la soluzione tecnica di impiegare un indicatore di una situazione di riempimento del pacchetto RLC PDU completamente separata dall’indicatore di lunghezza LI, ossia una soluzione che, come detto, è ben diversa dalla soluzione proposta da EP ‘142, ma che se per ipotesi volesse considerarsi ricompresa nel relativo ambito di protezione, sarebbe sicuramente anticipata da tali documenti anteriori.
97. Peraltro, come subito brevemente diremo facendo riferimento ad alcuni documenti esemplificativi, anche la specifica soluzione oggetto di EP ‘142 era, oltre che di per sé certamente banale, anche anticipata da ulteriori documenti anteriori.
5.4 Le domande di brevetto EP1180878A2 (doc. …) e KR2000-0048143 (doc. …)
98. EP1180878A2, pubblicato il 20 febbraio 2002, e KR2000-0048143, pubblicato il 1 novembre 2003, citano come tecnica nota l’operazione di inserire un indicatore di lunghezza fittizio nel pacchetto RLC PDU successivo per segnalare che nel pacchetto attuale non c’è lo spazio necessario per inserire in esso un indicatore di lunghezza della fine di un segmento di dati. Tale tecnica nota è simile alla tecnica nota descritta anche in EP ‘142.
99. Sia EP1180878A2 sia KR2000-0048143 propongono poi di evitare di inserire tale indicatore fittizio nel pacchetto successivo quando vi sono particolari condizioni degli indicatori di lunghezza del pacchetto attuale.
100. In sostanza, era già nota da tali due documenti l’idea di evitare l’inserimento dell’indicatore fittizio di lunghezza nel pacchetto successivo (si noti che in entrambi tale indicatore è proprio LI=000000, come citato nel brevetto EP ‘142) mediante qualche modifica degli indicatori di lunghezza del pacchetto attuale.
101. EP1180878A2 e KR2000-0048143 confermano ulteriormente la ovvietà della soluzione rivendicata in EP ‘142, che definisce unicamente quale forma tali indicatori devono realmente prendere.
Translation - English 1 EP 1 925 142 B1
1. EP 1 925 142 B1 (hereinafter, “EP ‘142”) was filed on 22/08/2006, claiming priority of United States Provisional Patent Application Serial No. 60/710,193 of 23/08/2005, and was granted on 28/10/2015 (doc. …).
2. No opposition to the patent was lodged.
2 The technical context
3. As we already know, in the field of digital transmissions the information to be transmitted is organised in data packets, which are separately sent to the network to be subsequently reassembled when arriving at destination.
4. By convention, the length of individual packets is often provided in number of “octets” making up the packet, where an octet is defined as consisting of eight bits (a bit is the minimum information size of a digital data, which can only take the values 0 or 1). An octet is, essentially, what nowadays is generally indicated as “byte” (cf. doc. … https://it.wikipedia.org/wiki/Byte).
5. A generic packet can thus be easily viewed graphically as a “table”, in which each of the lines consists in an octet (a “byte”) of eight bits, which, when stacked, make up a packet.
6. Each packet, of course, must also contain in itself the information necessary to be correctly reassembled once it arrives at destination.
7. In digital transmissions, such information is contained in the so-called “header” of each packet, i.e., a set of auxiliary data the system forming the packets adds at the top of the packet, which then continues with the so-called “payload” of the packet, namely, the actual digital information to be transported.
8. In a modern telecommunications network, such as the cellular phone network, due to various reasons of efficiency and management, the overall process of formation of packets of data to be actually transmitted to the network consists in a “layer” system, where every layer is made up of a “unit” that performs a special function of processing the data it receives from the previous layer, and which, once processed, it passes onto the next layer.
3 The subject matter of EP ‘142
9. The patent in question (hereinafter also referred to shortly as EP ‘142) deals with some specificities of the intermediate layer known as RLC (Radio Link Control), which is in charge of some radio link control functions and which, to that end, receives from the layer above it a flow of packets (termed in jargon “Service Data Unit” or by the acronym “SDU” or “RLC SDU”), by nature of variable size, and processes them to form new packets of predetermined size (termed in jargon “Protocol Data Unit” of the RLC or by the acronym “PDU” or “RLC PDU”) to be passed onto the next layer.
10. The sizes of RLC PDU packets are chosen from a predefined number of possible sizes based on the characteristics of the physical transmission channel actually used and on specific transport requirements of the network. What ensues from it is that each RLC PDU packet might contain an entire RLC SDU packet, more than one RLC SDU packet, or even mere segments of an incoming RLC SDU packet, depending on the sizes of incoming RLC SDU packets compared to the sizes chosen for the outgoing RLC PDU packets.
11. Therefore, what must first of all be inserted in the header of each packet produced by the RLC layer is the information on the length of the data inserted in the packet, to be able to retrieve it correctly. Such length information (generally indicated in abbreviated form as “LI”, an acronym standing for “Length Indicator”) is essentially a number (represented in binary notation as a sequence of bits in the dedicated octet), which in the packet header indicates how many data octets of an RLC SDU packet are contained in the specific RLC PDU packet.
12. A single header of an RLC PDU packet can also include more than one length information - LI, given that, as mentioned earlier, the same RLC PDU packet can host several groups of data of subsequent packets of input to the RLC layer. To indicate such a possibility, each LI might be followed by a bit, called extension bit (whence the reference to it in jargon as “E-bit” or even merely as “E”), whose task is to indicate whether what follows it is another LI (by setting the E-bit at 1), or whether the LI is the last one of the header, after which the “payload” begins (in that case, the E-bit is set at 0).
13. Basically, the structure of an RLC PDU packet might be as evinced by the following figure, with a first octet containing the sequence number of the packet (likewise ending with an E-bit indicating the fact that it is followed by an LI) and then, in each subsequent octet, a possible LI (Length indicator) with its own E-bit indicating whether another LI will follow, until the last LI that is followed by an E-bit=0 to indicate that the payload data begins immediately thereafter.
Fig. 1. Structure of an RLC PDU packet according to the prior art
14. As shown in the figure, if some space is left in the packet after inserting in it all the useful data, one or more meaningless padding octets (PAD), which upon arrival will simply be discarded, can be inserted.
15. In order to enable a correct reassembly of the incoming information, it is however not enough to merely indicate the lengths in number of octets of the data segments inside the packet, as it is in fact necessary to also indicate at least whether such segments are the initial, final or intermediate part of an incoming RLC SDU packet, which had to be subdivided and which must later be assembled with the content of a subsequent packet, or whether they already form a complete RLC SDU packet.
16. As we might think at once, it would of course be sufficient to that end to also insert in the packet header, besides the length indicators - LI, an additional separate indicator to signal the possible instances of padding the RLC PDU packet.
17. On the contrary, the prior art mentioned in the EP ‘142 patent does not intend to add to the header any other indicators apart from the LIs, and seeks to include both indications purely inside the length information - LI of the packet, resorting in the process to a rather complex trick.
18. Again according to the prior art mentioned in the patent, in fact, once some lengths have been selected among all possible length indications from 0 to the maximum number that can be indicated in one LI, conditions are imposed on the RLC layer so that it cannot possibly create packets with the selected lengths, and such lengths (by now “fictitious” or special) are used to indicate the intended instances of padding instead of real lengths of data in the packet.
19. Essentially, the RLC PDU packet will contain in the header “real” length indicators and “fictitious” length indicators. On arrival, the former will be interpreted by the system to extract from the packets the data contained therein and the latter (recognised because the lengths they indicate have been predetermined as not possible) to know whether and how to group the data together again.
20. EP ‘142 itself mentions that already in the prior art the most frequent real lengths of the packets produced by the RLC entity are 11, 15, 36, 40 and 98 octets. All we need, therefore, is to choose some length value different from those lengths and assign to it the meaning of a padding type.
21. However, a problem could arise with this modus operandi.
22. It might in fact occur, for particular combinations between the sizes (i.e., the number of octets) of the successive RLC PDU packets and the sizes of the RLC SDU packets to be inserted in them, if need be by dividing them into segments, that in a packet formed by the RLC there is for instance the space to insert in the packet header the fictitious length indicator chosen to indicate the beginning of a sequence, but there is not enough space to likewise insert in the header the fictitious length indicator indicating that such packet also contains the end of a sequence of data segments.
23. The prior art mentioned in the EP ‘142 patent solved the problem by envisaging, in such unfavourable cases of lack of space, the insertion in the next packet of a fictitious length indicator that indicates the end of the sequence of data in the previous packet.
24. This solution, while solving the previous problem, generates a further, easily conceivable problem: in the unfortunate case that space is lacking in an RLC PDU packet, and the fictitious length indicator that indicates the end of a sequence is accordingly placed in the next packet, the receiver that receives the packets and must interpret them to extract the data therein contained, reassembling them, cannot possibly know whether a sequence has ended until it receives the packet following the one in which the sequence of data actually ends. If, in the transmission of packets, precisely such subsequent packet is lost for some reason, the receiver will not be able to know that it has already received a complete sequence of data.
25. It is in this context that the solution proposed in the EP ‘142 patent comes to the fore.
26. In essence, the EP ‘142 patent is in line with the initial idea of the prior art, to wit, that of using only the length indicators LI with real length indications and fictitious length indications, and merely proposes to assign broader meanings to some fictitious lengths, so that, for instance, we might possibly indicate that in an LC PDU packet both the beginning and the end of a sequence are present by using only one fictitious length indicator rather than two, thereby solving the problem of lack of space for two indicators that beset the prior art EP ‘142 stepped from.
27. To clarify this, we could for instance rely on the example shown in the lower part of figure 1 of EP ‘142, as reproduced below:
Fig. 2. Estratto della Fig. 1 EP ‘142
28. This figure shows a comparison between the two sequential packets in which it is possible to insert a single fictitious length indicator while nevertheless containing the entire data sequence to be transmitted. On the left, the two packets are obtained through the prior art solution EP ‘142 uses as its starting premise, whereas on the right they are obtained through the solution put forward in the patent.
29. All the packets contain in the first octet their own identification number (generically indicated by SN+1 in the first packet and SN+2 in the second) followed by the E=1 bit indicating the fact that an LI is next, then by the LI itself followed by an E=0 bit to indicate that the data will follow suit.
30. In both solutions, the length indicator of the first packet is the same as the binary number “1111100”, which in decimal figures corresponds to the number 124 representing a fictitious length. The difference, however, is that in the scenario on the left such fictitious length has only been assigned the meaning of “a new sequence of data begins in the first data octet in this packet”.
31. It is therefore necessary to place a fictitious length indicator in the next packet (in this case, “0000000” has been chosen), with the meaning: “a sequence of data ended in the previous packet in the last data octet and in this packet the first data octet begins a new one”.
32. It is clear that if this second packet is lost, the receiving system would not know about the end of the previous sequence of data.
33. In the example on the right, instead, we see the solution proposed in the patent: at the reserved length represented by the binary number “1111100”, the additional meaning “and the last octet in this packet ends a sequence of data” is all that was added to the meaning according to the prior art (“the first data octet in this packet begins a new sequence of data”). All that is required, therefore, is this indicator in the first packet, and an additional indication for it in the next packet is unnecessary. This new meaning is accordingly used whenever in a packet a sequence of data begins and ends as well (as shown for instance in the next SN+2 packet on the right in figure 1).
34. The solution proposed in EP ‘142 is, therefore, trivial to say the least, as it is no more than a design solution to the problem, typical of all data transmissions to packet, of the possible loss of the next packet. This problem is tackled in accordance with the structure of PDU packets utilised in the standard communication protocol then in force, by using the elements therein available (the LIs, length indicators), without modifying their structure. Moreover, in those cases where there is no problem of space in the header, the solution described in the patent is identical to that of the prior art mentioned in the patent itself. In this regard, see for instance figures 2, 4 and 9 or even the first two packets on the top of figures 1, 3, 7, 8 and 12, where the operation of the previous system (on the left) and of the one in accordance with the invention (on the right) is absolutely the same, just as the figures of the examples are the same.
3.1 The claims of EP1925142
35. Claim 1 of the patent reads:
1. A method comprising:
inserting, in a radio link control (RLC) entity, at least one service data unit (SDU) to a protocol data unit (PDU) of an appropriate size;
characterized in that it further comprises:
a) providing at least one indicator including a length indicator (LI) for indicating that
a1) a first data octet of the protocol data unit (PDU) is a first octet of a first service data unit (SDU1) and
a2) at least one other octet of the protocol data unit (PDU) is the last octet of another service data unit (SDU2),
b) the first service data unit (SDU1)
b1) being either the same or
b2) different
from the other service data unit (SDU2),
c) wherein at least one other octet is the last octet of the protocol data unit (PDU).
36. For the sake of clarity, we added here in brackets the acronyms PDU, SDU, LI, SDU1 and SDU2, and the various parts of the claim were divided into paragraphs.
37. The introductory part of the claim preceding the phrase “characterised in that ...” merely asserts that, according to the method, the RLC entity receives data packets (SDU) and inserts them in the packets it creates (its own PDU packets), as the patent says the process implemented by any RLC entity already known at the time of filing the patent obviously amounts to.
38. The part after the phrase “characterised in that ...” is rather convoluted, but we can see that it essentially claims the fact that a length indicator (that is, of course, a length indicator LI, as the description makes clear, and as it is in any event intrinsic to the transmission system the solution of EP ‘142 fitted into) must be able to indicate the two cases (obviously as “fictitious” length indicator):
CASE 1:
a1) the beginning of the data in the packet is the beginning of the SDU1; and
a2+c): the end of the data in the packet is the end of the SDU2;
with
b1) SDU1 and SDU2 are the same (they are the same SDU) and, therefore:
the beginning and the end of the SDU are respectively the beginning and the end of the data in the packet;
CASE 2:
a1) the beginning of the data in the packet is the beginning of the SDU1; and
a2+c): the end of the data in the packet is the end of the SDU2;
with
b1) SDU1 and SDU2 are different and, therefore:
SDU1 and SDU2 are contained one behind the other in the same packet.
39. In other terms, according to the method of claim 1, in one PDU packet produced by the RLC layer there must be a fictitious length indicator that instead of indicating a real length indicates the fact that such packet includes SDUs beginning inside the packet and ending with the last octet of the same packet.
40. This is exactly what is set out in the descriptive examples of the patent and no other interpretation of claim 1 of the patent is possible, as there is no different example or a different explanation in the entire descriptive text of the patent.
41. We have already seen the triviality of the choice, subject matter of the patent and claimed by it in its first independent claim.
42. If we now turn our attention to the next claims, claim 2 signals that the RLC entity is an RLC entity that operates in Unacknowledged mode.
43. We must nonetheless observe that (from its title onwards) throughout the patent it is expressly stated that the invention is only for the optimisation of protocol data unit headers in Unacknowledged mode. See for instance page 5, where we can read: “This invention concerns the optimisation of PDU, Protocol Data Unit, headers in UM, Unacknowledged Mode”. This claim 2 is thus seemingly redundant, since the characteristic therein stated is already implicitly an essential characteristic of claim 1.
44. Claim 3 merely signals that the length indicator can be of 7 bits and/or 15 bits, which are precisely the two sizes in bit of the length indicator of the prior art preceding the patent.
45. Claims 4, 5, 6, 7 and 8 do no more than list examples of which 7bit length indications can be reserved for the “fictitious” length indicator to be used as indicator of the condition claimed in claim 1. The choice of a number instead of another is however utterly arbitrary, resulting in no particular advantage: it is only a matter of choosing any number not intended to be used as real length of an RLC PDU packet. There is thus no significant technical meaning in the choice of values mentioned in those claims.
46. Claims 9, 10, 11 and 12 merely list further examples of which length indications can alternatively be reserved for the “fictitious” length indicator where the length indicator is of 15 bits. In this case, too, the choice is entirely arbitrary, and these claims, too, do not add any significant technical meaning.
47. Lastly, method claim 13 simply claims the fact that we can additionally provide a higher layer signalling to a user equipment to identify whether or not the length indicator is in use. This characteristic has no explanation in the entire text of the patent and lacks any descriptive support enabling it to be understood or implemented. Moreover, it is (not incidentally) not even mentioned in the technical opinion filed as the opponent’s doc 6, and, accordingly, its enforcement has not even been sought in these proceedings.
48. Apparatus claims 14-25 only differ from method claims 1-12 because of the addition of generic “means for” implementing the method of claims 1-12. The remarks put forward in respect of method claims 1-12 can thus be transposed in full to claims 14-25, especially to claims 14 e 15, the only apparatus claims expressly mentioned in the opponent’s doc. 6, and as such sought to be enforced in these proceedings.
49. Claim 26, likewise mentioned in the opponent’s doc. 6, merely specifies that “the means for inserting comprise an inserting unit and the means for providing comprise a providing unit”, with a clearly tautological definition that cannot certainly contribute to differentiate this claim from the previous ones.
50. Finally, the last claim, 27, similarly mentioned in the opponent’s doc. 6, contents itself with observing that the method of the previous claims can be implemented through a computer program, without any further specifications. This claim, too, adds no significant technical meaning to the subject matter of the independent claims (any packet formation method for digital communications is obviously implemented through a suitably adapted computer program).
* *** *
4 EP ‘142 and the LTE standard
51. According to the opponent, EP ‘142 copies aspects of the LTE standard and, therefore, any equipment operating according to such standard should be seen as automatically interfering with the scope of protection of the patent.
52. It is thus a case of ascertaining whether or not the characteristics of the claims are envisaged by the LTE standard. Hereunder we will focus on claim 14, which as we saw is identical to claim 1 (the only difference being that claim 14 claims the apparatus that implements the phases of the method referred to in claim 1), as this is the only main claim examined in the technical opinion filed as the opponent’s doc. 6.
53. According to the opponent (see again opponent’s doc. 6), the technical specification to be taken as reference in order to establish the interference is the 3GPP TS 36.322 specification, version 10.0.0 (hereinafter shortly referred to as “TS-322”, annexed hereto as doc. …). The opponent furthermore specifies that “other versions, such as the more recent 15.1.0, contain the same technical details in relation to what is claimed in patent EP142”, thereby confirming the choice of technical specification to refer to.
54. According to specification TS-322, in a first operational mode, called TM (“Transparent Mode”), the RLC SDU packets that arrive at the RLC entity are directly transferred at the outfeed without any modification or addition. This is clearly indicated, for instance, in paragraph 5.1.1.1.1 of TS-322, which reads: “When submitting a new TMD PDU to lower layer, the transmitting TM RLC entity shall: - submit a RLC SDU without any modification to lower layer”. Essentially, the RLC entity does not perform any processing intervention and does not add any header to the packets that traverse it.
55. There is thus no header produced by the RLC entity with any characteristic whatsoever. Likewise explanatory is figure 6.2.1.2-1: TMD PDU, on page 22 of TS-322, reproduced below, on the structure a packet must take in Transparent Mode, TM, which indisputably shows that in TM the packets exiting the RLC consist purely of data, without any header:
Fig. 3. TMD PDU (p. 22 of TS-322)
56. When the RLC operates in TM, there is thus no “Length Indicator” and no need to identify any beginning or end of sequences of data in the packets produced, which are the subject matter of the EP ‘142 patent, and, accordingly, there can be no interference with the EP ‘142 patent when an LTE apparatus operates in TM with the RCL layer.
57. This fact alone proves that an LTE apparatus can work without any interference with the scope of protection of EP ‘142, resulting in the failure to discharge the onus of proof resting on Sisvel.
58. There is however far more. Let us in fact consider the only other two possible modes of operation of an RLC entity, namely, UM (“Unacknowledged mode”) and AM (“Acknowledged mode”) .
59. In each of the two modes, UM and AM, the RLC entity processes the incoming SDU packets to make them the “payload” of its own outgoing PDU packets, adding a corresponding header as well.
60. The headers of the two modes, UM and AM, differ from one another, but for both of them, however, the designers of the LTE standard have made a choice that is completely different from the solution that forms the subject matter of the EP ‘142 patent.
61. As already written above, in fact, both the prior art mentioned in the patent and the solution proposed in the patent itself have chosen to employ the same length indicators of the packets to also indicate the type of padding of the packets. According to this solution, the header can contain in one position either a number that represents the real length of the packet or a number that represents a fictitious length (no longer susceptible of use as a real length), which must be interpreted with a different meaning, thereby complicating other than in a negligible way the creation and management of packets.
62. By contrast, the LTE standard entirely abandons this idea, with all the problems it entails, and, both in the Unacknowledged mode (UM) and in the Acknowledged one (AM), it limits itself to using length indicators in the header solely and exclusively to indicate the real lengths of the groups of data in the packets and adds, again in the header, a new element (called “Framing Info”, in other words, “compositional information”, FI in short), the exclusive purpose of which is to define which case of padding the RLC packet created according to the LTE standard falls under.
63. This FI element has of course a form and a content radically different from that of length indicators and is inserted, once only, in two bits of the first octet of each packet header.
64. To clarify this fact, we set out below the figure “6.2.1.3-3: UMD PDU with 5 bit SN (odd number of LIs, i.e., K=1, 3, 5,…)” found on page 23 of TS-322, which describes the most general form of a packet produced by the RLC entity according to the LTE standard when the Unacknowledged mode (UM) is used:
Fig. 4. UMD PDU with 5 bit SN (p. 23 of TS-322)
65. This figure clearly shows the composition of the packet in Unacknowledged mode (UM) according to the LTE standard, with the header followed by the data (“Data”): the first line (the first octet) of the packet contains the two bits making up the FI element, one bit with the parameter “E” and the serial number of the packet (SN) placed in the remaining 5 bits of the octet.
66. Thereafter, the length indicators might follow, in any number. These length indicators are binary numbers of 11 bits (hence neither 7bit nor 15bit as required in EP ‘142), to which the E bit signalling whether a further LI (E=1) follows or none at all (E=0) is associated. If the LIs are in odd number, then at the end of the last LI some empty space remains in the octet, a space that is simply filled with any “Padding” bits until the octet of the Header is completed.
67. Again according to the LTE standard, there is also the possibility of producing packets with serial number of packet (SN) in 10 bits, instead of 5 bits. In that case, the first three bits of the first octet are unused and are filled with three zeros in such a way as to modify only the first octet and retain the arrangement of the following octets compared to the arrangement with a 5bit SN. This is illustrated clearly in figure “6.2.1.3-5: UMD PDU with 10 bit SN (Odd number of LIs, i.e., K=1, 3, 5,…)” on page 24 of TS-322, set out hereunder:
Fig. 5. UMD PDU with 10 bit SN (p. 24 of TS-322)
68. In this figure, the three unused initial bits, equal to 0, are indicated by R1.
69. A similar structure of the header is imposed by the LTE standard for the RLC packets as well when we operate in Acknowledged mode, AM, as we can for instance infer from the explanatory figure “6.2.1.4-2: AMD PDU (Odd number of LIs, i.e., K=1, 3, 5 ,…)” encountered on page 25 of TS-322, which shows the general structure of the RCL packet in AM as imposed by the LTE standard:
Fig. 6. AMD PDU (p. 25 of TS-322)
70. As we can see, the only difference compared to the packet in Unacknowledged mode, UM, is the fact that the LTE standard lays down that in Acknowledged mode, AM, the Serial Number (SN) is invariably in 10 bits, and the first three bits of the first octet, which were unused and marked R1 in UM, are utilised in AM to indicate further characteristics of the packet that assist the operation of the network in AM, which are marked D/C (“Data/Control”, an element signalling whether the packet is one of data or of mere control), RF (“Re-segmentation Flag”, signalling whether or not the packet is re-segmented), and P (“Polling Bit”, whether or not to request a STATUS report from the receiver).
71. It is already sufficiently clear from the figures herein reproduced, which show the general structure of the packet headers imposed (without any possible exemption) by the LTE standard, that such packets bear no resemblance to the packets described in EP ‘142 (where the headers merely consisted of a first octet with a Serial Number (SN) and an E-bit, followed by one or more length indicator (some real, others fictitious), each of which occupied either the first seven bits of an octet ending with an E-bit (if the LIs were of 7 bits) or two octets the second of which ended with an E-bit (if the LIs were of 15 bits), and nothing else.
72. It is moreover a peremptory requirement that no length indicator (LI) of the LTE standard should have a function other than that of indicating the real length of the data in the packet. The 11bit LIs imposed by the LTE standard can freely represent all the lengths from 1 (in 11bit binary number it is “000 0000 0001”) to 2047 (in 11bit binary number it is “111 1111 1111”) without any limitation. In the LTE standard, in fact, there are no reserved LIs to indicate fictitious lengths, unlike what is instead necessary according to both EP ‘142 and the prior art mentioned therein. In the LTE standard, only the length 0 is, if we want to call it that way, reserved, but only because in that standard it would be senseless to indicate a null length of the packet.
73. All of this is clearly regulated in paragraph 6.2.2.5 of TS-322, where the content the length indicator (LI) must have according to the LTE standard is defined, namely:
74. [For the sake of clarity, we should bear in mind that by the initials PDU we indicate the data packet produced by the RLC entity]
75. The LI field, therefore, always remains a mere number indicating how many bytes make up each group of data in the packet produced by the RLC unit.
76. It is instead the separate two-bit FI element that represents all the possible instances of data segmentation among the various RLC packets, by applying a far quicker and more intuitive solution than the unnecessarily complex one of EP ‘142.
77. Paragraph 6.2.2.6 on page 29 of TS-322, set out below, imposes the form of the FI field:
78. [For the sake of clarity, we should bear in mind that by the initials SDU RLC we indicate a data packet that reaches the RLC entity and must be inserted, in full or segmented, in the packet produced by the RLC entity].
79. The aforementioned table 6.2.2.6-1, likewise present on page 29 of TS-322, is also reproduced below:
80. As we can see, the two-bit values associated with FI (“value” column) and the meanings associated with them (“Description” column) bear no resemblance to “fictitious” 7 to 15- bit values of the length indicator according to EP ‘142 (see for instance the two tables of reserved LI values set out on page 15 of the Italian version of EP ‘142).
81. It is basically clear that the LTE standard does not envisage, to distinguish the various instances of data segmentation, the “providing at least one indicator including a length indicator for indicating that a first data octet of the protocol data unit, PDU, is a first octet of a first service data unit and at least one other octet of the protocol data unit, PDU, is the last octet of another service data unit”, in the sense required by EP ‘142 (both by apparatus claim 14, the only independent claim sought to be enforced in these proceedings, and by the identical method claim 1).
82. This is confirmed by the very opinion filed by the opponent, which seeks precisely to corroborate the infringement of EP ‘142 exclusively by reference to the FI field, in other words, as stated earlier, to something entirely different from the length indicator EP ‘142 is concerned with.
83. To conclude, any device that implements the LTE standard, precisely because it must submit to that standard, cannot interfere in any way with EP ‘142, a patent that has nothing to do with what is currently stipulated by the LTE standard, which, as remarked before, compared to the prior art entails a fully-fledged paradigm shift in the structure of PDU packets, eliminating the actual technical context within which the solution of EP ‘142 operated.
5 The invalidity of EP ‘142
84. We have already mentioned the triviality, and thus the intrinsic lack of inventive step, of the independent claims of EP ‘142, as well as all the claims dependent on them. This triviality is even clearer in the light of the prior art.
85. This is first and foremost indisputable if we were to follow the unfounded argument voiced in the opinion under the opponent’s doc. 6, according to which, unlike what alone is taught in EP ‘142, even use of a separate padding indicator differing from the length indicator (as envisaged for instance by the LTE standard) would fall within the notion of length indicator dealt with in EP ‘142. In that case, in fact, the patent would even be invalid for lack of novelty.
86. Solutions that contemplated in the header of packets produced by the RLC layer packet length indicators and completely separate packet padding indicators were in fact already known in various forms prior to the priority date of 23 August 2005 of the EP ‘142 patent.
87. See, for example, the following documents.
5.1 Document R2-051441-13 (doc. …)
88. It is a proposal published on 13 May 2005, put forward by Qualcomm during a meeting of the TSG-RAN WG2 working group, in charge during the standardisation phase of the specifications of the Radio Access Network that comprises the RLC layer as well.
89. Underlined in the first lines of chapter 2 headed “RLC LI optimization” is the fact that in what was at the time the latest version of RLC specifications, a “special” (fictitious) length with value “1111100” or (in the event of 15bit indicator) “111111111111100” was already inserted in a PDU header to indicate the beginning of an SDU (by virtue of the otherwise unavoidable “ambiguity in case of a PDU loss”), and that, at a previous meeting of the working group, namely, the RAN2#46bis meeting held from 4 to 8 April 2005 in Beijing, it was agreed that the scheme could be further improved if in the RLC PDU packet header a separate 1bit-long indicator (termed “SDU beginning flag”) was used to indicate “if the SDU’s first octet is located in the same PDU as its last octet”. This would have both spared the need for the “special” “1111100” or “111111111111100” length indicator and avoided the problem of being unable to establish the end of a sequence of data if the packet next to the one containing the last part of that sequence had been lost.
5.2 Document R2- 050969 (doc. …)
90. This document, published on 8 April, contains two optimisation proposals for the RLC layer for the VoIP support, likewise put forward by Qualcomm at the meeting referred to in the aforementioned document R2-051441-13, i.e., the RAN2#46bis meeting held in Beijing from 4 to 8 April 2005.
91. The second of the two proposals (described in paragraph 3 headed “RLC SDU beginning signalling”) concerns precisely the possible solutions to a problem of the standard then in use, which could not establish whether or not an entire sequence had ended in a PDU RLC packet in the event of loss of another PDU RLC packet.
92. To solve the problem, two possible different solutions were advanced in document R2-050969. The first solution was to introduce a further “fictitious” length indicator in LI, to signal directly in a packet whether the entire sequence was contained in such packet.
93. The second solution was to use an additional bit (removed from the length indicator, which would then become one bit shorter) to indicate whether or not the beginning of a sequence was contained in the current packet. Further details on such additional bit are then included, as we saw, in the abovementioned document R2-051441-13, which makes express reference to document R2-050969 (see the reference thereto already in § 1) and must thus be seen as forming an integral whole with it .
5.3 Document R2-051311 (doc. …)
94. It is an additional optimisation proposal, published on 9 May 2005, put forward by Samsung during the same 3GPP TSG-RAN WG-2 meeting #47 mentioned above.
95. This further proposal, too, suggests the introduction of an indicator, completely detached from the length indicator, which signals whether an entire sequence of data is contained in the packet. This complete separation is even clearer if we consider that the proposal was not to obtain the additional bit by removing it from the number of bits making up the length indicator (as suggested instead in the previous proposals). What was in fact proposed were the two alternative solutions of shortening by one bit the “Sequence number” (SN), which indicates the position of the packets compared to the others, or assigning a new meaning to another one-bit indicator present in the packet, namely, the Expansion bit (E-bit), which normally signals whether the header has ended or carries on.
96. Essentially, the content of the aforementioned prior art documents highlights the fact that, long before the priority date of EP ‘142, the technical solution of using an indicator of a situation of padding the RLC PDU packet, completely separated from the length indicator, was already well known, being a solution which, as already pointed out, is quite different from the solution proposed by EP ‘142, yet which, assuming it was held to fall within the relevant scope of protection, had no doubt been anticipated by such prior documents.
97. Moreover, as we will briefly state at once by referring to some exemplifying documents, even the specific solution claimed in EP ‘142 was, besides being certainly trivial in itself, anticipated by further prior documents as well.
5.4 The claims of the EP1180878A2 (doc. …) and KR2000-0048143 (doc. …) patents
98. EP1180878A2, published on 20 February 2002, and KR2000-0048143, published on 1 November 2003, mention as prior art the operation of inserting a fictitious length indicator in the next RLC PDU packet to signal that the current packet lacks the space necessary to insert therein a length indicator of the end of a data segment. Such prior art is similar to the prior art described in EP ‘142 as well.
99. Both EP1180878A2 and KR2000-0048143 then propose to avoid including such fictitious indicator in the next packet where there are special conditions of length indicators of the current packet.
100. Essentially, the idea of avoiding the fictitious length indicator in the next packet was already known from those two documents (it should be noted that in both, such indicator is precisely LI=000000, as mentioned in patent EP ‘142) via some modifications to the length indicators of the current packet.
101. EP1180878A2 and KR2000-0048143 further confirm the obvious nature of the solution claimed in EP ‘142, which merely defines the form such indicators must actually take.
Italian to English: Lettera di assunzione
Source text - Italian DIGITAL ATTITUDE SRL
P. IVA: 09964900964
VIA MELLERIO 3
20123 MILANO (MI)
Gent.mo Signor
MICHAL MARCIN KWIATEK
Via Benefattori dell'Ospedale 24
20162 - Milano
C.F. KWTMHL97C13Z127H
Milano, 4 febbraio 2020
OGGETTO: lettera di assunzione
Facendo seguito alle intese intercorse Le comunichiamo, con piacere, la Sua assunzione in servizio, alle condizioni contrattuali di seguito elencate.
Articolo 1- ASSUNZIONE - DECORRENZA - DURATA DEL CONTRATTO
1.1 In quanto dichiaratosi libero da ogni impegno e da qualsivoglia patto di non concorrenza, Lei verrà assunto dal giorno 6 febbraio 2020 con un contratto di lavoro a tempo pieno e indeterminato.
1.2 Il rapporto di lavoro sarà regolato dalle norme del diritto italiano, da quelle del Contratto Collettivo Nazionale di Lavoro del settore Metalmeccanica Industria, dagli accordi aziendali di secondo livello, se esistenti, e dalle disposizioni indicate nella presente lettera.
1.3 Il rapporto di lavoro è da considerarsi a tempo indeterminato. Ciascuna parte potrà, pertanto, recedere dal contratto dando il preavviso ai sensi dell’articolo 2118 del Codice civile, nei termini e secondo le modalità previste dal Contratto Collettivo Nazionale di Lavoro a Lei applicato.
Articolo 2 - PERIODO DI PROVA
2.1 É stabilito un periodo di prova pari a 30 giorni. Durante tale periodo, ciascuna delle parti sarà libera di recedere dal contratto senza alcun obbligo di preavviso.
L'insorgere di eventuali eventi sospensivi della prova, quali la malattia, l'infortunio, la gravidanza, i permessi, lo sciopero, il godimento delle ferie annuali, avrà l'effetto di prolungare l'anzidetto termine.
Articolo 3 - QUALIFICA — LIVELLO - MANSIONI
3.1 Lei verrà assunto con la qualifica di IMPIEGATO DIRETTIVO, LIVELLO 5S del C.C.N.L. per le imprese del settore Metalmeccanica Industria.
3.2 Le mansioni a cui sarà adibito, nel corso del rapporto di lavoro, saranno le seguenti: Full Stack Web Developer. Il datore di lavoro si riserva la facoltà di modificare le mansioni a Lei attribuite nei limiti consentiti dall’articolo 13 della legge 300/70 e dalla disciplina contrattuale in materia.
Articolo 4 — ORARIO DI LAVORO
4.1 L’orario di lavoro normale sarà di 40 ore settimanali, così suddivise:
• Lun: 8
• Mar: 8
• Mer: 8
• Gio: 8
• Ven: 8
• Sab: 0
• Dom: 0
Articolo 5 - LUOGO DI LAVORO
5.1 Lei svolgerà le Sue mansioni presso la sede di MILANO, VIA MELLERIO 3.
5.2 Il datore di lavoro si riserva, per comprovate esigenze tecniche, organizzative e produttive, la facoltà di trasferirLa o distaccarLa presso altra sede, stabilimento, filiale, ufficio o reparto autonomo. L’eventuale trasferimento o distacco, accompagnato dalla sua motivata giustificazione, Le sarà comunicato con un preavviso congruo. Verificata la sussistenza delle ragioni indicate, Lei si impegna fin d’ora ad accettare il trasferimento o il distacco.
Articolo 6 — DILIGENZA - ESCLUSIVA — RISERVATEZZA E FEDELTA’
6.1 Lei si impegna a prestare la Sua attività lavorativa con particolare regolarità, diligenza e correttezza professionale, nel rispetto delle direttive impartite dai superiori, delle prescrizioni generali contenute nel regolamento aziendale, nelle circolari e disposizioni di servizio, in vista degli obiettivi produttivi e di sviluppo dell’azienda.
6.2 Sottoscrivendo la presente lettera Lei si obbliga a non esercitare alcuna attività in aggiunta a quella prevista dal presente contratto e a non trattare affari, per conto proprio o di terzi, in concorrenza con lo scrivente datore di lavoro.
6.3 Assume, inoltre, l’impegno a non divulgare, comunicare, utilizzare direttamente o indirettamente informazioni di qualsiasi tipo di cui verrà a conoscenza nell’esercizio delle Sue mansioni né divulgare notizie attinenti l’organizzazione e i metodi di produzione o farne un uso tale da recare pregiudizio al datore di lavoro. Questo impegno resterà valido durante l’attuazione del presente contratto e dopo la sua risoluzione senza limiti di durata.
Articolo 7 — RETRIBUZIONE
7.1 Il trattamento economico a Lei spettante sarà quello stabilito dal citato Contratto Nazionale con riferimento al Suo livello d’inquadramento. Viene pertanto definita una retribuzione annua lorda pari a 34.000,00= € così suddivisa:
• 25.178,79 € a titolo di retribuzione base;
• un elemento retributivo, denominato superminimo assorbibile, pari a 4.921,28 €. Tale superminimo, in quanto riconosciuto a titolo di futuri aumenti contrattuali, potrà essere oggetto di assorbimento nell’eventualità che la sua retribuzione base possa aumentare per rinnovo contrattuale o per passaggio di livello;
• un elemento retributivo, denominato forfait straordinari, pari a 3.900,00= €. Detto trattamento sostituisce, nei limiti della capienza, la remunerazione del lavoro eventualmente prestato in eccedenza rispetto al normale orario di lavoro;
7.2 Pertanto le competenze economiche mensili lorde a Lei spettanti saranno cosi quantificate:
• Paga Base 1.936,83= €.
• Superm. Assorbibile 378,56= €.
• Forfait Straordinari 300,00= €.
• Totale retribuzione lorda 2.615,39= €.
Le verranno corrisposte n. 13 mensilità. Per il primo anno di servizio, i ratei relativi alle mensilità supplementari Le saranno corrisposti in proporzione all’anzianità maturata. Per quanto concerne il periodo di pagamento della retribuzione si rinvia espressamente all’art. 4 “Corresponsione Retribuzione”, Titolo IV, del C.C.N.L. settore Metalmeccanica Industria a Lei applicato.
7.3 Le sarà riconosciuto annualmente, in aggiunta a quanto sopra, anche un piano Welfare quantificato in 600 €/anno (di cui all’allegato regolamento interno).
7.4 Qualora le mansioni da Lei espletate siano normalmente e stabilmente svolte presso una sede fissa ed il datore di lavoro la comandasse a svolgere temporaneamente la Sua attività lavorativa in luogo diverso dalla sede contrattuale di lavoro, Lei avrà diritto alle indennità e al rimborso delle spese cosi come previsto dal Contratto Collettivo di settore.
7.5 Per quanto concerne la durata delle ferie retribuite si rinvia espressamente all’art. 10 “Ferie”, Titolo III del C.C.N.L. settore Metalmeccanica Industria a Lei applicato.
Articolo 8 — DISCIPLINA SANZIONATORIA
8.1 L'inosservanza delle disposizioni derivanti dalle norme contenute nella presente lettera di assunzione o di quelle derivanti dal CCNL potrà dar luogo da parte del datore di lavoro a sanzioni disciplinari (compreso il licenziamento) secondo la gravita delle infrazioni e in conformità alla disciplina legislativa e contrattuale in materia. Per tutto quanto concerne il procedimento per l’irrogazione delle sanzioni disciplinari e i successivi mezzi d’impugnazione si rinvia a quanto stabilito dall’articolo 7 della Legge n. 300/70 e a quanto stabilito dal Contratto Collettivo Nazionale di Lavoro.
Articolo 9 — ISCRIZIONE LIBRO UNICO DEL LAVORO
9.1 Ad ogni effetto di legge, La informiamo che abbiamo iscritto il Suo nominativo nel Libro unico del lavoro di cui all’articolo 39, comma 1 della Legge 133/2008; inoltre, ai sensi dell’art. 4 bis, comma 2, D.lgs. 21 aprile 2000, n. 181, come modificato dall’art. 40, D. L. 25 giugno 2008, n. 112, Le consegniamo copia della comunicazione di instaurazione del rapporto di lavoro (che contiene tutte le informazioni previste dal D. Lgs. 26 maggio 1997, n. 152).
Articolo 10— DISPOSIZIONI FINALI
10.1 Qualsiasi modifica del presente contratto dovrà avvenire per iscritto.
Per tutto quanto non previsto nella presente lettera di assunzione, varranno le disposizioni contrattuali e di legge in materia.
Voglia restituirci l’unita copia della presente lettera, sottoscritta in segno di integrale accettazione e per conferma di aver preso visione delle norme disciplinari relative alle infrazioni e alle procedure di contestazione previste dalla L. 25 maggio 1970, n. 300 e dal contratto collettivo di lavoro e delle norme relative agli obblighi derivanti dal D.lgs. 9 aprile 2008, n. 81
Dipendente Datore di Lavoro
Il Sottoscritto dichiara di aver ricevuto informazione/formazione in materia di sicurezza sugli ambienti di lavoro cosi come previsto (dalla vigente legislazione in materia) dall’articolo 36 del Decreto Legislativo 81/2008 e successive modifiche.
Dipendente
_________________________________
Translation - English DIGITAL ATTITUDE SRL
VAT NUMBER: 09964900964
VIA MELLERIO 3
20123 MILAN (MI)
Dear Sir
MICHAL MARCIN KWIATEK
Via Benefattori dell'Ospedale 24
20162 - Milan
Tax Code: KWTMHL97C13Z127H
Milan, 4 February 2020
SUBJECT: letter of appointment
Pursuant to the agreements reached, we are pleased to inform you that you are hired on the under-mentioned contractual terms and conditions.
Article 1- APPOINTMENT – EFFECTIVE DATE – TERM OF THE CONTRACT
1.1 Since you declared yourself free from any commitment and any restraint of trade, you are hired from 6 February 2020 on a full-time employment contract of indefinite duration.
1.2 The work relationship will be governed by the provisions of Italian law, the National Collective Agreement for the Metal Industry, and the second-level company agreements, if any, and by the provisions set out in this letter of appointment.
1.3 The employment relationship is to be understood as one for indefinite duration. Each party, accordingly, may withdraw from the contract by giving the other party notice in accordance with Article 2118 of the Italian Civil Code, in the manner and within the time limits laid down by the National Collective Agreement applicable to you.
Article 2 – PROBATIONARY PERIOD
2.1 The appointment is subject to a 30 days’ probationary period. During such period, each of the parties will be freely entitled to withdraw from the contract without notice.
The onset of any events suspending the probation, such as illness, injury, pregnancy, leave, strike, or enjoyment of annual leave, will have the effect of extending its period.
Article 3 - TITLE — LEVEL – JOB DUTIES
3.1 You will be employed with the title of EXECUTIVE EMPLOYEE, LEVEL 5S of the National Collective Agreement for companies operating in the Metal Industry.
3.2 The job duties you will be assigned to, during the work relationship, are going to be the following: Full Stack Web Developer. The employer reserves the right to amend your job duties within the limits permitted by Article 13 of Law No. 300/70 and by the applicable contractual regulations.
Article 4 — WORKING HOURS
4.1 The normal working hours will consist of 40 hours a weak, thus divided:
• Mon: 8
• Tue: 8
• Wed: 8
• Thu: 8
• Fri: 8
• Sat: 0
• Sun: 0
Article 5 – WORKING HOURS
5.1 You will perform your job functions at the MILAN premises situated in VIA MELLERIO 3.
5.2 The employer reserves the right, for proven technical, organisational and production requirements, to transfer or second you to another company venue, plant, branch, office or autonomous department. You will be informed of any transfer or secondment, accompanied by its motivated reasons, upon adequate notice. Once the aforementioned grounds are ascertained you hereby undertake to accept any such transfer or secondment.
Article 6 — DILIGENCE – EXCLUSIVE EMPLOYMENT — CONFIDENTIALITY AND LOYALTY
6.1 You undertake to perform your work with particular regularity, diligence and professional correctness, in compliance with the instructions issued by your superiors, and with the general prescriptions set out in the company regulations, circulars and service orders, bearing in mind the company’s production and developmental objectives.
6.2 By signing this letter of appointment, you bind yourself not to exercise any activity additional to what is stipulated by this contract, and not to do business, on your own behalf or on behalf of third parties, in competition with the undersigned employer.
6.3 Furthermore, you hereby undertake not to disclose, communicate, and directly or indirectly use information of any type you will come to know while discharging your job functions, and not to disclose news relating to the organisation and the production methods or use the same in such a manner as to undermine the employer. This commitment will remain valid during performance of this contract and after its termination without any time restriction.
Article 7 — REMUNERATION
7.1 The remuneration owed to you is the one stipulated by the aforementioned National Collective Agreement in respect of your employment level. Accordingly, you will earn a gross annual remuneration of EUR 34,000.00, divided as follows:
• EUR 25.178,79 as basic remuneration;
• a remunerative element, termed extra allowance over minimum pay, in a sum of EUR 4,921.28. This extra allowance, being recognised by way of future contractual rises, may be absorbed in the event that your basic remuneration is increased pursuant to contractual renewal or improvement in level;
• a remunerative element, termed extraordinary lump sums, in a sum of EUR 3,900.00. This remuneration represents, within the limits of capacity, the remuneration for any work performed over and above normal working hours.
7.2 Accordingly, the gross monthly dues you are entitled to are quantified as follows:
• Basic Salary: EUR 1,936.83.
• Extra allowance over basic pay: EUR 378.56.
• Extraordinary Lump Sums: EUR 300.00.
• Total gross remuneration: EUR 2,615.39.
You will be paid 13 salaries. For the first year of employment, the accrued income relating to the supplementary monthly payments will be disbursed to you proportionally to the actual length of service. As regards the payment period of remuneration, you are expressly referred to Article 4: “Payment of Remuneration”, Title IV of the National Collective Agreement for the Metal Industry applicable to you.
7.3 In addition to the foregoing, you will also be the annual beneficiary of a Welfare plan quantified in EUR 600 per annum (as per the attached internal regulation).
7.4 If the job functions performed by you are normally and regularly carried out in a fixed venue and the employer instructs you to temporarily conduct your work activity in a place other than the contractually defined workplace, you will be entitled to allowances and to the reimbursement of expenses as stipulated by the National Collective Agreement for the sector.
7.5 With regard to the length of paid leave, you are expressly referred to Article 10: “Leave”, Title III of the National Collective Agreement for the Metal Industry applicable to you.
Article 8 — DISCIPLINARY PENALTIES
8.1 Failure to comply with the provisions arising from the rules set out in this letter of appointment or those arising from the National Collective Agreement could result in the employer imposing disciplinary penalties (including dismissal) depending on the seriousness of the breaches and in accordance with legislative and contractual rules in force. As regards the procedure for imposing disciplinary penalties and the subsequent means of appealing against them, reference should be made to the provisions of Article 7 of Law No. 300/70 and to what is laid down by the National Collective Agreement.
Article 9 — REGISTRATION IN THE SINGLE EMPLOYMENT LEDGER
9.1 For all legal intents and purposes, we hereby inform you that we have registered your name in the single employment Ledger referred to in Article 39, paragraph 1 of Law No. 133/2008; moreover, in accordance with Article 4-bis, paragraph 2 of Legislative Decree No. 181 of 21 April 2000, as amended by Article 40 of Decree-Law No. 112 of 25 June 2008, we hereby deliver to you copy of the notice of commencement of the employment relationship (which contains all information prescribed by Legislative Decree No. 152 of 26 May 1997).
Article 10 — FINAL PROVISIONS
10.1 Any amendment to this contract must be in writing.
The applicable contractual and legal provisions will apply to whatever is not regulated by this letter of appointment.
Please return to us the only copy of this letter of appointment, signed in full acceptance and as acknowledgment of having perused the disciplinary rules relating to breaches and dispute procedures laid down by Law No. 300 of 25 May 1970, by the National Collective Agreement, and by the rules governing the obligations arising from Legislative Decree No. 81 of 9 April 2008.
Employee Employer
The Undersigned hereby declares that he has received information/training on workplace safety as stipulated (by the applicable legislation in force) by Article 36 of Legislative Decree No. 81/2008 as subsequently amended.
Employee
_________________________________
More
Less
Translation education
PhD - UNIVERSITY OF THE WITWATERSRAND (BA) - JOHANNESBURG
Experience
Years of experience: 26. Registered at ProZ.com: Dec 2010. Became a member: May 2011.
Adobe Acrobat, Microsoft Excel, Microsoft Office Pro, Microsoft Word, Trados Studio, Wordfast
Professional objectives
Meet new translation company clients
Meet new end/direct clients
Network with other language professionals
Get help with terminology and resources
Learn more about translation / improve my skills
Get help on technical issues / improve my technical skills
Learn more about additional services I can provide my clients
Learn more about the business side of freelancing
Stay up to date on what is happening in the language industry
Help or teach others with what I have learned over the years
Bio
Translation work, English – Italian – Arabic, in writing and orally, as team player and team leader, regardless of the industry concerned. Such work encompasses all types of documents, legal, judicial, commercial, technical, literary, etc. Done work like that in the past in the field of IT.
Many years' experience in the field.
Legal documents are my specialization within the specialization.
Interpretation work, in the said languages, including simultaneous interpretation and court-related work.
Meticulous look at work, timeliness, professionalism, excellent writing skills and very good in verbal communication, did a lot of personal interaction and negotiation in my job, consistently dealt with clientele as well as management (line / senior), colleagues and subordinates, formidable talent in research, structuring and organizing, innovation, dealt with many organizations
Keywords: translator english italian arabic law general subjects
Member since May '11
Expertise 
Portfolio