SoylentNews is people
SoylentNews
https://blog.cloudflare.com/patent-troll-sable-pays-up/
Back in February, we celebrated our victory at trial in the U.S. District Court for the Western District of Texas against patent trolls Sable IP and Sable Networks. This was the culmination of nearly three years of litigation against Sable, but it wasn't the end of the story.
Today we're pleased to announce that the litigation against Sable has finally concluded on terms that we believe send a strong message to patent trolls everywhere — if you bring meritless patent claims against Cloudflare, we will fight back and we will win.
[...] While Sable's technical expert tried his hardest to convince the jury that various software and hardware components of Cloudflare's servers constitute "line cards," his explanations defied credibility. The simple fact is that Cloudflare's servers do not have line cards.
[...] Ultimately, the jury understood, returning a verdict that Cloudflare does not infringe claim 25 of the '919 patent.
In the end, Sable agreed to pay Cloudflare $225,000, grant Cloudflare a royalty-free license to its entire patent portfolio, and to dedicate its patents to the public, ensuring that Sable can never again assert them against another company.
Let's repeat that first part, just to make sure everyone understands:
Sable, the patent troll that sued Cloudflare back in March 2021 asserting around 100 claims across four patents, in the end wound up paying Cloudflare. While this $225,000 can't fully compensate us for the time, energy and frustration of having to deal with this litigation for nearly three years, it does help to even the score a bit. And we hope that it sends an important message to patent trolls everywhere to beware before taking on Cloudflare.
(Score: 5, Interesting) by DannyB on Friday October 04, @07:28PM (2 children)
I co-wrote it.
I built the back end "service" if you will. An "init" file that loaded at boot time. Another experienced programmer with the company longer than me (but we were the first two) was new to Mac so he wrote the Desk Accessory part of it.
In my code, I had to patch every single QuickDraw trap at boot time and replace it with a new routine in RAM. We pondered over how to make that use just a single 68000 JMP instruction back to the original location when Timbuktu was not capturing the screen contents.
I also patched the event manager so that every time the current application asked if there were any events, I would get a chance to either capture "custom" events that our desk accessory was sending me, or inject custom events which the desk accessory could ask for based on event type. Or something like that as I recall all these years later. Also at event time, I could impose extra operations into the foreground app without it knowing, such as pop up dialogs noting that Jane wanted to share your screen and did you want to allow this. This would actually occur in the execution thread of the foreground app because the app had called the event manager, and I was just doing some things the app could have done before it actually had called the event manager. These were the kinds of tricks we had to design.
But what about MacPaint and Hypercard? They draw directly to the screen memory and don't go through QuickDraw. We kept a 16 bit "checksum" of the pixels on each row of the screen. On every event manager call if a certain number of milliseconds had elapsed, I would calculate the checksum of what was on the next screen row of pixels and see if it matched what I last had. So we kind of "slow scanned" the screen for changes that were not attributable to QuickDraw. If we found any, we turned on a mode to send those rows of differing pixels across the wire to the other end so that it would fairly quickly paint in things from HyperCard, MacPaint or any other application that "cheated" and drew directly into screen memory.
Of course, we didn't draw into screen memory. We drew into a window belonging to the desk accessory showing a view of the remote machine's desktop.
There is, of course, much more I could describe. Those were fun daze. After that we got acquired just for that particular technology. It was adapted into two other products. A "Screen Recorder" that could save and play back what you did on the screen. And Timbuktu/Remote which worked over 9600 bps "high speed" modems. Back then these modems cost several thousand bucks each, and manufacturers were lining up to send me pairs of their product and I had two identical stacks of modems on my work table and would switch cables to test the product on different pairs (even mismatched) of modems through two phone lines in my office.
Santa maintains a database and does double verification of it.
(Score: 4, Interesting) by vux984 on Friday October 04, @09:26PM (1 child)
Thanks - what a trip
Yep, the company i worked for, had 5 branches connected together with USRobotics modems, in a line, with an SE/30s in each branch routing appletalk between two sites. It was a long distance call from one end of the 'network' to the other, but we had enough locations so that each could dial the next one locally. Like you said those modems were a thousand dollars at the time. We also had a small modem pool at one site, and I dialed into that from home. And then could remote manage the whole thing with Timbuktu. We also ran geez what was it called "QuickMail??" maybe over that network for email/messaging within the company.
Of course, I still had to go onsite for a variety of things, but timbuktu was a game changer for us. We stuck with timbuktu until the company gradually moved to TCP/IP with internet links over ADSL / ISDN.
(Score: 3, Interesting) by DannyB on Monday October 07, @03:10PM
Oh yes, QuickMail. [cnn.com] We used it. We had a leased fractional T1 line from an office where I worked near Kansas City to our new owners (Farallon) in San Francisco bay area. That T1 linked our Ethernets together, which meant linking AppleTalk, Novell SPX/IPX and NetBEUI which is the "butt sniffing" protocol that Windows machines used to find each other on the network.
QuickMail got acquired by Microsoft because it was too good and ate away Microsoft Mail on Macintosh preventing Microsoft from having the universal mail server.
During and after this period of Timbuktu and related products, we lived in an R&D Playground. We could do just about anything we wanted, very loosely supervised as long we it made new products that brought in more money. That is how we decided (in R&D) to build Timbuktu/Remote, add color capabilities with the Mac II, allow one desk accessory to open multiple windows into other remote Macs, and Screen Recorder which I described previously.
The last thing I did at the company was just barely complete the first prototype TCP/IP implementation of Timbuktu on Mac. At this point the company had a Windows version of Timbuktu actually working, and it was cross platform compatible across Windows and Macintosh.
I personally had to attend a MacWorld awards ceremony in (I think) San Francisco because Timbuktu/Remote was nominated for an award. Won 2nd place. I still have the trophy somewhere.
The R&D guys also got to attend all of the MacWorld trade shows. At one point where Timbuktu/Remote was still a prototype, I had to work in our booth and demo the product. The company had to arrange to get two phone lines installed at our trade show booth. I remember people from big companies asking questions "you mean we could share screens across offices like New York to San Francisco?" Again, those were very fun daze.
Santa maintains a database and does double verification of it.