https://www.patentlyapple.com/2020/09/apple-sued-a-second-ti...
> In November, a California federal judge ruled that a former Masimo engineer stole trade secrets related to Masimo’s pulse oximetry technology. The judge blocked US sales by True Wearables Inc.—a company launched by the engineer after a stint at Apple—of the Oxxiom device “in its current iteration that includes the trade secrets.”
Here's the actual patent, unpaywalled:
https://patents.google.com/patent/US10945648B2/en
Claim 1 (as claim language goes, this isn't too bad):
1. A user-worn device configured to non-invasively determine measurements of physiological parameter of a user, the user-worn device comprising:
a plurality of light emitting diodes (LEDs);
four photodiodes configured to receive light emitted by the LEDs, the four photodiodes being arranged to capture light at different quadrants of tissue of a user;
a protrusion comprising a convex surface and a plurality of openings extending through the protrusion, the openings arranged over the photodiodes and configured to allow light to pass through the protrusion to the photodiodes;
and one or more processors configured to receive one or more signals from at least one of the photodiodes and determine measurements of oxygen saturation of the user.
https://support.ouraring.com/hc/en-us/articles/7328398760851...
The way I understand it, and I could be totally wrong, that’s somewhere between dead and impossible within the span of 2 hours.
You get the occasional outliers from a bad reading but in general that's how I've experienced, and I've had nurses and doctors say that they are "good enough".
And yeah in my experience, anything less than 90-93% in a hospital and they will have you on high flow oxygen pretty quick. So 85% as a single bad reading is fine, but a sustained 85% on a watch means you probably want to head to a medical facility.
There simply haven't been enough (or sometimes, any) tests comparing what are normal/safe readings for continuous monitoring in normal life settings of many of these parameters, especially for healthy people, and doubly especially for these types of non-invasive simplistic sensors.
Basically, we don't know how much should a healthy person's pulse/SpO2/... as measured with a smart watch sensor vary during the day. We also don't know which values, if any, should be considered emergencies, or which values should scare you into a programmed visit.
Note that over-monitoring is often just as harmful as under-monitoring in medicine, especially give that the vast majority of the population is healthy (so any false positive is likely to affect many more people than a false negative does, even if in lighter ways).
See the video for the Apple Watch Series 6 [0], and Series 7 [1].
There's also tests for the Series 8 [2], although it doesn't include data collected in a low oxygen environment.
[0] https://youtube.com/watch?v=8HIcwMhEny0
If I open the app and stay still for the full 15 seconds the reading seems much more accurate.
I can confirm with the other poster, I've found them to only be ~1 or 2 different from other oximeters.
I'd always assume bad read first if you have an outlier.
The main use cases are for detecting sleep apnea and high altitude hypoxia. If you aren't subject to those issues then you can just disable the pulse oximeter to save battery life.
Deliberately infringing a patent can trigger punitive (3x) damages. "Convergent evolution" could be a defence against that kind of claim. That's a reason big-co lawyers tell devs to NOT read other companies patents.
The US used to have a first-to-invent system, but changed about a decade ago. The first-to-file system is more common in other countries, and generally favors large companies since they can spend lots of resources on filing patents.
However, I believe there is (or maybe just was?) a grace period of a few months, where you can claim it just took a few months to file and your patent can still be granted even if prior art appeared in these X months between your invention and the actual filing (I have no idea how this is adjudicated).
There is, however, an exception: if an invention is likely to be obvious to a person skilled in the art given access to prior art, the invention is not considered not patentable
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2399580
"obvious to try" is probably what you're imagining. This is a real legal doctrine, and it's deplorably underutilized with software, as I explain.
I had a patent lawyer read over this carefully, and he took particular interest in the notion that, as he put it, "software engineers have a bag of tricks they use."
We all know that we do. But the legal system needs some kind of official blessing for the contents of the bag, and "our" ACM and IEEE are never going to give us one.
So, they cannot reasonably know what prior art might be in that field, if for example they are not allowed to hire anyone with a CS degree, for example.
Yes, that was the case for a long time. Only recently have they been allowed to hire patent examiners with CS degrees.
So, yay -- fucked up USPTO, as per usual.
It also fails to do anything about patent thickets.
Otherwise though, the purpose of patent law is to force companies to publish their discoveries instead of keeping them as trade secrets. If a drug company today tried to keep some process or substance as a trade secret, they would run the risk of another company discovering the same process and/or substance and blocking them from producing the thing they discovered first. So, they are essentially forced to publish it.
I'm glad I couldn't find Garmin here, I love their sensor data.
For a secret that can't easily be reverse-engineered, that means the biggest difference between patents and trade secrets is how long you expect to have a monopoly for. For patents, if you are granted one, then you get a monopoly for exactly 20 years, which for almost any idea is enough time to make a lot of money if it's a good idea or at least get enough of a head start. But once 20 years are up, that idea has been in the open for 20 years already. For trade secrets, the number of years depends on you. Some companies can make it for more than 20 years. Employee retention helps. Spending lots of money on information security helps. Not letting Chinese companies through the door who pretend to want to buy yours, do some due diligence and then back out once they figure out a few of your trade secrets, also helps.
This might be unrelated to this post , but I just read a post you wrote back at 2014 , talking about how to get a quant job.
And I aspire to be one day in it.
I was an engineering background now current at Risk management .intermediate in python, SQL and shell scripting.
I work in non finance field before and 3 years ago I break into finance by joining a risk consultancy as a data analyst for automation and data centralisation.
Then now I m in a small Investment Bank in market risk as analyst to automation all the report for them.
I m applying for a master of statistics currently
And now I have a dilemma for current next job opportunities. I m Googling around and trying to collect enough data for making career decisions.
1 offer i got : A Swiss asset management firm - Junior trader (no programming , only VBA) and it came with a pay cut as I don’t have direct experience
2 offer in a retail bank: Data engineer with 25 % pay raise doing digital transformation and automation like my first finance related job.
Question: While I m working toward a master degree (part time)
Q1) Would getting offer 2 be putting in a bad track record on CV and driving me away from the path into becoming a quant - who trade
Would getting a data engineer job completely throw me off the path of trying to become a quant in the future even tho I m working on getting a master in statistics and phd after ?
Q2) being now in middle office, would staying in market risk (which I m just doing automation for report ) be better to make a better track record
Q3) would job offer 3 be better while working toward my master in statistics be better in your opinion (pay cut to trade off for experience)