Cupertino conciata per le feste

Apple condannata per violazione di un brevetto sulla gestione della memoria cache e accusata di infrangerne altri relativi alla fotocamera di iPhone. Ad accusarla società che si concentrano solo sulle battaglie legali

Roma – Il giudice della corte distrettuale del Texas ha confermato la decisione secondo cui Apple violerebbe il brevetto ‘ 291 in possesso di OPTi, e l’ha condannata a pagare 21,7 milioni di dollari (19 di risarcimento e 2,7 di interessi) all’azienda detentrice della privativa sulla memoria cache. Chiudendo così, momentaneamente, un caso aperto nel gennaio 2007.

La OPTi dal 2003 ha cessato le sue attività produttive e commerciali per concentrarsi sulle cause legali: è andata in tribunale anche con AMD e si è già aggiudicata 10 milioni di dollari da NVIDIA (da cui ha ottenuto anche un buon accordo di licenza) e 650 mila dollari dalla produttrice di chip taiwanese Via . Tutti questi casi riguardato argomenti simili, e nel caso Apple ad essere portato all’attenzione del giudice è il brevetto dal titolo Predictive Snooping of Cache Memory for Master-Initiated Accesses ottenuto su una tecnologia per la gestione della memoria cache nel sistema operativo.

La difesa di Cupertino aveva tentanto di dimostrare che il brevetto era di per sé invalido perché non innovativo, ovvio cioè rispetto allo stato dell’arte. Tali argomentazioni sono state respinte dal giudice, che ha però riconosciuto a Apple l’attenuante della non volontarietà. Contro la sua decisione, tuttavia, Cupertino ha già dichiarato di voler ricorrere in appello.

Non è l’unico problema legale della Mela, costretta ora a difendersi anche dall’accusa di St. Clair Intellectual Propert Consultants (società costituita da due avvocati) per cui la fotocamera di iPhone violerebbe quattro suoi brevetti. Il caso è stato denunciato alla corte distrettuale del Delaware. Con le stesse tecnologie la società ha già vinto contro Sony e Canon, aggiudicandosi quasi 60 milioni di dollari in danni. Mentre la maggior parte degli altri soggetti portati in tribunale, praticamente tutti i maggiori produttori di fotocamere nel mondo, hanno deciso di siglare un accordo di licenza.

Claudio Tamburrino

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • Lepaca scrive:
    A conferma
    a conferma dei dubbi sollevati alla presentazione del progetto.Implementare via software (tra l'altro in un'architettura non specializzata come x86) porta maggiore flessibilita', ma anche prestazioni piu' scadenti, e nell'ambito delle schede video, dove le prestazioni sono tutto, la storia era gia' scritta...
    • pabloski scrive:
      Re: A conferma
      la questione però è più complessaoggi i motori grafici usano directx o opengl per le loro necessità e quindi sono costretti ad operare entro un determinato recinto sia come funzionalità supportate che come implementazioneovviamente potendo creare un motore grafico software vuol dire che puoi usare delle scorciatoie, compattare il codice, renderlo più veloce in termini di numero di operazioni rispetto alla controparte hardware e ottenere così risultati migliori dell'hardwarequesto però sempre che sotto ci sia un hardware adeguato e realisticamente gli x86 non sono quella che si può definire un'architettura flessibile, moderna e leggeragli arm lo dimostrano riuscendo ad erogare le stesse performance ad una frazione del costo in termini di silicio e di corrente consumatasecondo me intel se proprio vuole provarci deve usare un'architettura nuova oppure giocare la carta degli fpga, cosa che per loro non dovrebbe essere troppo difficile, anche se attualmente ati e nvidia ci arriverebbero molto prima
      • . . scrive:
        Re: A conferma

        oggi i motori grafici usano directx o opengl per
        le loro necessità e quindi sono costretti ad
        operare entro un determinato recinto sia come
        funzionalità supportate che come
        implementazioneI motori grafici si appoggiano a directx o a opengl per una infinita' di motivi, primo fra tutti la compatibilita'. Non vedo inoltre come tali librerie possano essere viste come un "recinto", dato che supportano tutte le chiamate grafiche necessarie, e te lo garantisce uno che ha programmato in opengl 17 anni fa ...Se proprio vuoi uscire dal recinto, esiste CUDA. L'architettura x86 e' obsoleta da almeno un decennio, ma siamo costretti a contiunare ad usarla (principalmente per colpa di M$).
        • pabloski scrive:
          Re: A conferma
          se hai usato cuda, avrai notato però che mancano molte cose....la flessibilità del modello a kernel non è lontanamente paragonabile a quella del modello di programmazione delle cpualtro problema è la possibilità di avere un modello di memoria coerente, non essere sbatacchiato tra ram video e ram di sistema continuamentealtro problema è la possibilità di avere un supporto al c++ e agli oggetti....cuda usa il c fondamentalmentecuda usa la gpu e gli stream proXXXXXr e quindi è limitato ad operare su matrici, vettori, a far conti in sostanza...manca la flessibilità necessaria per manipolare efficacemente stringhe, supportare il branchinge poi perchè no, bisogna ragionare in parallelo con le gpu e tenendo conto che i programmatori odiano ragionare in termini di multithread, multiprocessi, ecc... non è uno svantaggio da pocodel resto se le gpu fossero general purpose verrebbero usate al posto delle cpu
          • Vault Dweller scrive:
            Re: A conferma
            - Scritto da: pabloski
            se hai usato cuda, avrai notato però che mancano
            molte cose....la flessibilità del modello a
            kernel non è lontanamente paragonabile a quella
            del modello di programmazione delle
            cpu?!?!?!?!?!?
            altro problema è la possibilità di avere un
            modello di memoria coerente, non essere
            sbatacchiato tra ram video e ram di sistema
            continuamenteAttualmente in fase di programmazione tu te ne sbatti della memoria video e della memoria di sistema, in quanto sono i driver a gestire la memoria in base alle chiamate alle varie api.Operando direttamente sull'hw è diverso; CUDA e Stream ti permettono di programmare direttamente sulla GPU e di conseguenza vedi unicamente le risorse GPU.
            altro problema è la possibilità di avere un
            supporto al c++ e agli oggetti....cuda usa il c
            fondamentalmenteNon ti sta bene che CUDA sia modellato sul C? diventa presidente di Nvidia e cambia le cose; comunque vi sono binding per un fot*io di linguaggi.
            cuda usa la gpu e gli stream proXXXXXr e quindi è
            limitato ad operare su matrici, vettori, a far
            conti in sostanza...manca la flessibilità
            necessaria per manipolare efficacemente stringhe,
            supportare il
            branchingSo it shall be written so it shall be doneTradotto se un auto viene progettata per essere un mezzo di trasporto terrestre è assurdo volerla usare come supposta.
            e poi perchè no, bisogna ragionare in parallelo
            con le gpu e tenendo conto che i programmatori
            odiano ragionare in termini di multithread,
            multiprocessi, ecc... non è uno svantaggio da
            pocoed è per questo che cuda o chi per esso ha delle funzioni per gestire agilmente i thread senza andare con fork(); if (pid==0){..}else{..} ...
            del resto se le gpu fossero general purpose
            verrebbero usate al posto delle
            cpuFermo ... inverti .. Bravo, ora sai cosa vuole fare intel, più o meno il contrario di quello che eri convinto.
          • pabloski scrive:
            Re: A conferma
            - Scritto da: Vault Dweller
            - Scritto da: pabloski

            se hai usato cuda, avrai notato però che mancano

            molte cose....la flessibilità del modello a

            kernel non è lontanamente paragonabile a quella

            del modello di programmazione delle

            cpu

            ?!?!?!?!?!?
            è lunga da spiegare, leggiti la documentazione di cuda
            Attualmente in fase di programmazione tu te ne
            sbatti della memoria video e della memoria di
            sistema, in quanto sono i driver a gestire la
            memoria in base alle chiamate alle varie
            api.ah si? e la necessità di copiare da e verso la memoria video tutti i dati da elaborare? a volte si parla di matrici di enormi dimensioni
            Operando direttamente sull'hw è diverso; CUDA e
            Stream ti permettono di programmare direttamente
            sulla GPU e di conseguenza vedi unicamente le
            risorse
            GPU.
            no il software gira sulla cpu e invia kernels e dati alla gpupuoi allocare degli oggetti dati in memoria video e usare i kernel per manipolarli
            Non ti sta bene che CUDA sia modellato sul C?
            diventa presidente di Nvidia e cambia le cose;
            comunque vi sono binding per un fot*io di
            linguaggi.
            che risposta è inutile....i binding servono per interfacciarsi a cuda non per scrivere i kernel da eseguire sulla gpu
            So it shall be written so it shall be done

            Tradotto se un auto viene progettata per essere
            un mezzo di trasporto terrestre è assurdo volerla
            usare come
            supposta.
            appunto, quindi larrabee un senso ce l'ha
            ed è per questo che cuda o chi per esso ha delle
            funzioni per gestire agilmente i thread senza
            andare con fork(); if (pid==0){..}else{..}
            ...
            ci sono pure sistemi operativi che gestiscono i thread, il fork riguardo il multiprocessing non il multithreading, sono due cose completamente differenti
            Fermo ... inverti .. Bravo, ora sai cosa vuole
            fare intel, più o meno il contrario di quello che
            eri
            convinto.ecco, finiscila di dire XXXXXXX
          • Vault Dweller scrive:
            Re: A conferma
            - Scritto da: pabloski
            - Scritto da: Vault Dweller

            - Scritto da: pabloski


            se hai usato cuda, avrai notato però che
            mancano


            molte cose....la flessibilità del modello a


            kernel non è lontanamente paragonabile a
            quella


            del modello di programmazione delle


            cpu



            ?!?!?!?!?!?



            è lunga da spiegare, leggiti la documentazione di
            cuda


            Attualmente in fase di programmazione tu te ne

            sbatti della memoria video e della memoria di

            sistema, in quanto sono i driver a gestire la

            memoria in base alle chiamate alle varie

            api.

            ah si? e la necessità di copiare da e verso la
            memoria video tutti i dati da elaborare? a volte
            si parla di matrici di enormi
            dimensioniScusa l'incomprensione ma visto che avevi risposto ad un commento che parlava di opengl &co ho creduto che ti colleggassi ad esso. Comunque è assolutamente logico, in quanto per varie questioni, tra cui la sicurezza e l'integrità dei dati le GPU non possono accedere autonomamente ai dati nella memoria di sistema; le GPU sono come ogni altro componente asservite alla CPU, non a caso essa si chaima così anziche Superflous Processing Unit.

            Operando direttamente sull'hw è diverso; CUDA e

            Stream ti permettono di programmare direttamente

            sulla GPU e di conseguenza vedi unicamente le

            risorse

            GPU.



            no il software gira sulla cpu e invia kernels e
            dati alla
            gpu

            puoi allocare degli oggetti dati in memoria video
            e usare i kernel per
            manipolarliKernel = modulo CUDASoftware : vede interfaccia CUDACiò implica che se tu scrivi in CUDA scrivi codice per la GPU, che richiami in software ttramite l'interfaccia driver di cuda.

            So it shall be written so it shall be done



            Tradotto se un auto viene progettata per essere

            un mezzo di trasporto terrestre è assurdo
            volerla

            usare come

            supposta.



            appunto, quindi larrabee un senso ce l'haNo perché se è solo la divisone della memoria che tu lamenti essa esisterebbe anche con larrabee, in quanto essa non sostituirebbe la cpu nel suo ruolo di controlore e arbitro del sistema.

            ed è per questo che cuda o chi per esso ha delle

            funzioni per gestire agilmente i thread senza

            andare con fork(); if (pid==0){..}else{..}

            ...



            ci sono pure sistemi operativi che gestiscono i
            thread, il fork riguardo il multiprocessing non
            il multithreading, sono due cose completamente
            differentiEhm ... NO! il multiprocessing è l'abilità di utilizzare più unità elaborative su una stessa macchina, il multi threading implica l'utilizzo di più thread nello scope di esecuzione di un programma; a a meno che scrivendo in C l'istruzione fork ti cresca una cpu in più sulla motherboard, esso è multithreading e non multiprocessing.

            Fermo ... inverti .. Bravo, ora sai cosa vuole

            fare intel, più o meno il contrario di quello
            che

            eri

            convinto.

            ecco, finiscila di dire XXXXXXXAh, mi sembra quasi che dovella mi abbia accusato di essere un M4 fanboy...
  • MAH scrive:
    Il dominio delle DirectX

    a differenza delle tradizionali architetture video, in Larrabee le funzionalità richieste dalle API DirectX sono implementate esclusivamente a livello di software. Tempo fa Intel ha citato come esempio la specifica Pixel Shader 5.0, che in Larrabee potrà essere supportata attraverso un semplice aggiornamento software (mentre le GPU tradizionali andranno riprogettate a livello hardware).Non avevo capito questa cosa, il fallimento di Larrabee è scontato.Le GPU andranno riprogettate a livello hardware?Puo' darsi, ma poi andranno n volte piu' veloci di Larrabee.MAH
    • iosonodio scrive:
      Re: Il dominio delle DirectX
      e che c'entra la frase "il dominio delle directx"? mi pare che le gpu moderne supportino pure opengl
      • Ste scrive:
        Re: Il dominio delle DirectX
        - Scritto da: iosonodio
        e che c'entra la frase "il dominio delle
        directx"? mi pare che le gpu moderne supportino
        pure
        openglIn realtà anche quelle non troppo "moderne". Il supporto opengl è già presente da anni su molte schede.Poi tutto dipende dagli utilizzi. Se rimaniamo nel campo gaming allora directx fa il 99%. In altri campi il discorso cambia.Comunque come già le schede attuali dimostrano, la vera chiave di sucXXXXX non è solo la GPU fine a se stessa, ma l'architettura complessiva della scheda, unita soprattutto alla bontà del driver abbinato.
        • pabloski scrive:
          Re: Il dominio delle DirectX
          nemmeno nel gaming, le directx hanno questo dominiopensa a playstation e wii tanto per citarne due....parliamo di miliardi di consolle che usano openglè che molti sono abituati a pensare informatica=pc=windows=ie=directx=....
          • ruppolo scrive:
            Re: Il dominio delle DirectX
            - Scritto da: pabloski
            nemmeno nel gaming, le directx hanno questo
            dominio

            pensa a playstation e wii tanto per citarne
            due....parliamo di miliardi di consolle che usano
            openglAh, non sapevo.Ma allora altro che 99%... se aggiungiamo i giochi per iPhone, direi che possiamo parlare di 0,99%, più che 99%...
        • ruppolo scrive:
          Re: Il dominio delle DirectX
          - Scritto da: Ste
          Poi tutto dipende dagli utilizzi. Se rimaniamo
          nel campo gaming allora directx fa il 99%. In
          altri campi il discorso
          cambia.Io direi che questo 99% sta scendendo a vista d'occhio...
  • Enjoy with Us scrive:
    Incredibile occasione per AMD!
    Spero che AMD rilasci al più presto la sua CPU/GPU multicore, potrebbe specie nei sistemi economici spazzare via la concorrenza di Intel e di nVidia e anche nei sistemi di fascia medio/alta impiegando la GPU interna in associazione con una scheda grafica discreta potrebbe coniugare performance con il risparmio energetico... speriamo che AMD che certo una GPU convenzionale ma ben performante la sa disegnare senza problemi si dia una mossa!
    • Vault Dweller scrive:
      Re: Incredibile occasione per AMD!
      La roadmap per fusion è già stata stillata, e accelerare i tempi sarebbe controproducente in quanto si andrebbe a tagliare sul testing; e nulla nuoce di più alle vendite di un errore in progettazione.Sinceramente spero che il progetto vada in porto, secondo i tempi stabiliti, in modo da fornire una migliore soluzione per i pc di fascia media.
    • iosonodio scrive:
      Re: Incredibile occasione per AMD!
      col fallimento di larrabee, amd avrà vita facileallo stato attuale nvidia è troppo impegnata a cazzeggiare con i supercomputer per accorgersi che la fascia media se la sta mangiando tutta amd e intel l'ha fatta fuori dal vaso pensando di usare l'architettura fatiscente x86 per fare calcoli matriciali
    • James Kirk scrive:
      Re: Incredibile occasione per AMD!
      E tu pensi che sia finita qui ?Molti già da tempo ritenevano che Larrabee non potesse avvicinarsi alle prestazioni di ATI/Nvidia e l'uscita del chip è stata ritardata, ma non cancellata.Intel ha risorse per sviluppare un proprio chip ma è chiaro il ritardo da ATI/Nvidia è duro da colmenre e non tanto a livello hardware, quanto software. Magari ci metterà ancora un paio di anno ma vedrei che arriva..... e se si comprasse Nvidia?
      • Vault Dweller scrive:
        Re: Incredibile occasione per AMD!
        - Scritto da: James Kirk
        E tu pensi che sia finita qui ?Sinceramente lo spero per loro.
        Molti già da tempo ritenevano che Larrabee non
        potesse avvicinarsi alle prestazioni di
        ATI/Nvidia e l'uscita del chip è stata ritardata,
        ma non
        cancellata.Il passo è breve ed è auspicabile.
        Intel ha risorse per sviluppare un proprio chip
        ma è chiaro il ritardo da ATI/Nvidia è duro da
        colmenre e non tanto a livello hardware, quanto
        software. Magari ci metterà ancora un paio di
        anno ma vedrei che
        arriva.Se fosse così tecnicamente avanzato mi spieghi perché i due competitor principali nell'ambito grafico si orientano verso stream proXXXXXr RISC superscalabili invece che verso x86; e ti ricordo che AMD produce e ha licenza di produrre hardware con arch x86.
        .... e se si comprasse Nvidia?AMD otterrebbe il monopolio, sempre se non abbandonano quest'assurda idea.P.S. William Shatner si sta rivoltando nella tomba, scavata per l'occasione.
        • James Kirk scrive:
          Re: Incredibile occasione per AMD!
          Sinceramente non ho capito le tue obiezioni (forse un po' affrettate), comunque se vuoi approfondire eccoti questi links:http://www.appuntidigitali.it/5374/gpu-arriva-larrabee-no-fermi/ http://www.semiaccurate.com/2009/12/04/intel-kills-consumer-larrabee-focuses-future-variants/
          • Vault Dweller scrive:
            Re: Incredibile occasione per AMD!
            - Scritto da: James Kirk
            Sinceramente non ho capito le tue obiezioni
            (forse un po' affrettate), comunque se vuoi
            approfondire eccoti questi
            links:

            http://www.appuntidigitali.it/5374/gpu-arriva-larr

            http://www.semiaccurate.com/2009/12/04/intel-killsLe mie obbiezioni sono semplici in realtà: dubito fortemente che terminato uno studio di fattibilità, valutante le possibili prestazioni di Larrabee, intel decida di continuare il progetto; in quanto pur conoscendo bene l'arch x86 essa non è adatta allo sviluppo di GPU (neanche di CPU, in quanto per migliorare le performance le istruzioni x86 dal pentium pro ad oggi vengono traslate da un chip posto sullla cpu in istruzioni RISC eseguite dal vero proXXXXXre, e questo comunque genera un overhead tale da ridurre di un terzo le performance possibili dalle cpu odierne), inoltre il concetto di programmabilità si scontra anch'esso con le performance della scheda, in quanto si passerebbe effettivamente ad un rendering software.
          • James Kirk scrive:
            Re: Incredibile occasione per AMD!
            Infatti il progetto verrà probabilmente deviato per un utilizzo GPGPU, in cui un sistema x86 fortemente ottimizzatoi per operazioni FB vettoriali potrebbe avere vantaggi su una architettura Tesla che deriva da GPU ed ha i suoi limiti ... ma tutto è da vedere, in particilare alla luce di 'Fermi'.Ciò non toglie che Intel si debba prima o poi dotare du una GPU decente, sia per migliorare quei chipset da battaglia che produce, sia per contrastare AMD che è in grado di offire tutto il pacchetto completo CPU+Chipset (e che chipset!) + GPU , per non parlare di quando riuscitanno a mettere tutto in us solo Chip (grossomodo tra un anno abbondante).Per cui il progetto Larrabee continua, ma probabilmente (IMHO) con una approccio più tradizionale ... altrimenti, ripeto, si compra Nvidia (che al momento non sta benissimo).
          • ruppolo scrive:
            Re: Incredibile occasione per AMD!
            - Scritto da: Vault Dweller
            (neanche di CPU, in quanto per migliorare le
            performance le istruzioni x86 dal pentium pro ad
            oggi vengono traslate da un chip posto sullla cpu
            in istruzioni RISC eseguite dal vero proXXXXXre,
            e questo comunque genera un overhead tale da
            ridurre di un terzo le performance possibili
            dalle cpu odierne),Oltre che un numero maggiore di componenti, quindi di costo e di consumo energetico.Ma di tutto questo dobbiamo ringraziare Microsoft, è questa putrida azienda che non vuole schiodarsi da x86.
Chiudi i commenti