I'd be curious to know what the minimum number of connections necessary to link any two persons is, over the average.
Probably infinity as there are most likely some small subgroups that don't contain a friend with an account that links outside that subgroup. That means that Facebook can't reliably measure a maximum connectivity estimate without saying 'infinity'. And even if they remove the infinity outliers, there would still be some higher number linkages simply due to a lack of active friending between people that do know each other, but don't want them to be 'friends'.
In the real world, one of those people in the outlier groups probably 'knows' someone outside of the clique group. But, within Facebook, they may not have an account (or may be intentionally 'non friended') so are not a measurable link.
This brings us back to the old claim of a maximum 6 degrees of separation between any two people on the planet.
1) Maintain up to date contact details for the copyright owners (the moment these lapse, the work tentatively goes into the public domain) 2) Maintain an automatably searchable index of all submitted tunes, lyrics, etc. 3) Allow downloadable access to all submitted features of the music (ie. lyrics, recording, etc) 4) Maintain an easy (ie. instant) online payment system for people/organisations to submit payments based on plays/prints/downloads/public performance/etc. 5) Pay creators based on the information in their database. (This might have been hard 50 years ago, but data storage and technology have been more than adequate since the 1980s to do this properly.) 6) Allow automated submissions so the likes of iTunes, Amazon, radio stations, churches, etc can easily submit their play/purchase/performance information. 7) Provide standardised contracts for recording artists, book authors, so the guy that's making his debut into the industry isn't guaranteed to get ripped off the moment he approaches a publisher / producer / etc.
and
A) Force all copyright 'holders' to submit their works to the foundation for protection - with all non-submitted works are deemed public domain (with a 12 month grace period). The previous system of registered copyrights was so much better than the crap fest that we have now. The way it works now, it's nearly impossible to track down copyright holders for anything that's not currently mainstream - especially when the works tend not to contain attributions with valid contact information (if any).
B) Make it the onus of the copyright holder to keep the contact information up to date.
C) Reduce copyright durations to sane periods of time (ie. 7 years) (with optional extensions that are available for a nominal payment which increases exponentially as time passes).
All of the above would effectively make it possible to do this efficiently. The way it stands now, I have no idea who the current copyright owner really is on anything at all (how can I know if something has been sold on?), and any organisation that exists today that emulates this type of service only represent a small percentage of the works created. And those organisations have such huge 'profit' overheads that hardly anything gets paid to anyone that isn't a top tier act.
Even if hybrids didn't exist, this is a recipe to guarantee you won't live to see your grandkids. Pretty much any new car that is coasting and/or isn't revving the shit out of its engine is virtually inaudible amidst the general city din.
I always look, even if I don't hear a thing. Hearing is useful as a double redundancy, but should never be used as a sole source of information when performing a potentially life threatening manoeuvre. It's not like you can't lean forward and stick your head around the hedge to double check - and then continually check the blind zone while you cross the street. You don't just have a quick look, turn your brain off and keep walking.
I do agree that assholes that cut their hedges right to the street line (and councils that plant hedges in a similar fashion) should be held accountable. It is much more effort and far less pleasant to safely cross a street as the visible distances decrease.
Apple purchasing this patent from Xerox is essentially equivalent to Apple outsourcing their R&D. Same end result.
Actually, Apple purchasing this from Xerox probably had nothing to do with using it to enhance their development efforts. You can pretty much guarantee that this patent would have been found by dedicated patent attorneys, probably while trying to file their own after Apple's engineers had already developed their implementation. Their options would have been to try to work around the overtly broad claims, find convincing prior art that circumvents all the claims, or just buy the patent at a reasonable price to add to their 'war chest'.
I can imagine Steve saying that he wanted a way to be able to see a map on his upcoming iPhone - kinda like a handheld GPS but on a phone! An engineer says, well we can avoid huge licensing and update hassles by using Google Maps - with all the advantages of ancillary information that can also be included on these maps - e.g. restaurants, traffic, weather, etc. Steve says, well get to it. I'm sure every software developer reading this would consider any 'location services' solution from this point as obvious.
Not: Steve saying that he's found a really neat patent about sending location information to a server that remotely processes the information and sends back some info to a remote device. An engineer then saying, we'll start a brain storming session on how we can make use of this, and then coming up with the location services / mapping implementation. No.
And not: Steve asking the engineers why they are having trouble implementing a GPS on their new phone. They say they just can't work out a solution. So Steve has his patent attorneys trawl the patent system for something that could help them. They find this patent and give it to the engineers who say: "Thanks Steve! This is a totally novel and inventive idea that we would never have thought of if not for the luck of finding a solution in this patent!" Again, no.
This is why engineers hate patents.
Re:The culprit is gonna be associated with Android
on
Siri Protocol Cracked
·
· Score: 1
What will happen next are events reinforcing the myth that Android is a stolen product.
It's a sad day indeed.
You're telling me. I was trying to use my iPhone yesterday and half the OS was missing! Stolen from right under my nose.
Isn't AAC just the MPEG4 version of what we know as mp3 (which is really just MPEG1/Audio layer 3)? There are already many open source implementations of AAC, so I don't see it as the same thing.
The real problem with AAC is the MPEG patent swamp. Even if Apple were to release an open source codec, it would still be under the same shadow that hangs over anyone that isn't lining the pockets of the MPEG licensing body.
In my experience, the response of acoustic speakers is not that great for anything other than speech and music. If you have a smartphone, try generating a white noise signal and watch the spectrum of the audio input (there are audio spectrum analyzer apps around); it won't be anywhere near flat.
On the other hand, my acoustic signal processing experience mainly has been with signals that were somewhat spread out (data communications), which is where the non-linear frequency response of audio I/O messed things up. The chirp signals these guys use probably occupy a much more linear part of the spectrum.
Unless the transducer has a significantly non-linear or narrow band response, it is extremely easy to compensate for this with only a minor signal to noise / distortion degradation. An impulse response and deconvolution is a good starting point when trying to subtract out the effects of imperfect devices (obviously within reason - you can't reverse the effects of a null or total signal cancellation, but a +/-10dB variation across the required spectrum wouldn't be too much to ask).
Here's the part that I've found really problematic on iOS devices: audio processing latency. Most signal processing of the type you describe typically work with real-time systems which makes timing straightforward. But this is not so on iOS devices, even with their low-latency API... Worse than the latency, there is a fair bit of jitter. Sure, you can do real-time stuff at the driver-level, but an app in the app store does not get that level of control. I have some idea about how to account for it, but I'm not sure how these guys have done it (I'd guess the "multi-cycle" approach has something to do with it).
In a system like this, the continuous streaming nature of the conversion process (crystal locked ADC/DAC sample clocks) acts as the synchroniser, and a 100ms (or even a few hundred milliseconds) latency isn't likely to cause a major problem (unless you have a huge number of feedback rounds between the two devices and expect instant results). Fractional sample rate conversion is useful for perfect synchronisation, but probably not necessary here. And jitter is only problematic if you're seriously underpowered (in which case you just increase the latency until all your processing can be completed before you are required to output a result based on that data), or you're trying to drive the sampling clock source from a recovered clock source (generally a bad idea and obviated by use of fractional sample rate conversion if required).
Patents are a different matter. Sure, you'll find standard stuff described all over in the text of the patent, but what really matters are the claims. The rest of the patent is only to provide background information and detailed description of what the claims cover. Of course, often patents do slip through with claims covering existing stuff, but in my experience this is not as common as/. tends to think. In my experience, in the past few years, the various patent offices have become very good about finding relevant prior art.
I have seen many times the 'standard stuff' claimed as the 'inventive step' underpinning the patent. Patents are hard to read at the best of times and I have mostly only ever reviewed them when requested to by a client that requires an interpretation of what is really being claimed. It doesn't take long to get pretty jaded when you've been doing that for a while. That being said, it's been a couple of years since I've done this, so maybe as you say things have improved. But, since this has been going on for over 20 years (and probably since the dawn of the patent system), I very much doubt it. Maybe they're rejecting more things that are obvious, but it really does take someone skilled in the field to be able to understand the problem and do this properly - including point out the prior art that may not use the same terminology as used in the patent. (eg.
Keep in mind that all that 'specialised equipment' evolved out of a need to improve the simpler predecessor systems.
Sonar and sonic range finding systems use all that 'extra equipment' to achieve ranges far in excess of 25m and in mediums much more variable than air. The impulse response of miniature consumer grade condenser microphones and speakers are more than adequate for air use within an octave of the audible spectrum. The speakers in the iPhone are primarily limited by their output power, and the fairly omnidirectional nature of the microphones may lack overall sensitivity, but both are simple parameters that really only end up reducing total available range and accuracy (as compared to specialised custom hardware using the same algorithmic solutions).
Applying the same design principles that would normally be applied to a specialised system design to an iPhone implementation, would be very unlikely to provide anything unknown to someone in the industry. This is very similar to early stage engineering "proofs of concept" that are used to test various parameters within a system design, without the interactive complexity of implementing the entire system.
There is nothing within this extremely simple setup that hasn't been done as part of a larger system design. A single (consumer grade) speaker + microphone used in transmissive, active echo, or for passive echolocation is not unusual. Considering the iPhone has excessive processing capability to implement all the standard approaches (correlation, convolution, deconvolution, filtering, impulse response measurement, etc), there is no real need to be 'clever' as such.
'Back in the day', when trying to do this with a 10MIPS DSP in real time with moving objects, it was much more important to come up with better algorithms and shortcuts. Of course, this could otherwise have easily been done with standard theoretical methods and a modern processor a hundred times more powerful.
I see patents pop up all the time that describe things that are far from novel. Most of those patents are usually 'invented' by people with no real experience in the given fields. ie. Ideas that seem like earth shattering discoveries to the uninitiated, but are really just standard techniques used by properly skilled engineers.
I'm not saying that this iPhone app is bad/good, just that it is VERY unlikely to contain any actual improvements to the current state of the art (or the state of the art 20 years ago for that matter). I say this, because there is no real need to do anything new to achieve the results that they are claiming.
BTW, in the past I've worked on sonar/radar systems for air, ocean and rock. The biggest problem in 'noisy' environments is a lack of output level. Multipath isn't a major problem for a point to point (ie. line of sight, shortest path) ranging device - unless you're talking about wave guide shapes/sizes over long distances.
When I see the word 'novel' applied to techniques that have been used for decades, I smell 'patent lawyer'. And be extension: astroturf.
Signal processing techniques applied to sonar (whether active, passive or beaconed) including signal correlation, spectral adaptation/equalisation, and filtering are standard fare in this field.
Maybe by novel they mean "on an iPhone"?
That being said, there is nothing that says this won't work - as it worked extremely well 20 years ago on dedicated systems with far less processing power. (Those systems, however, used multiple arrayed transducers and tailored beam patterns to significantly reduce the effective noise floor.)
The previous system in the US allowed that to happen due to the 'first to invent' principle trumping certain extents of prior publication.
Conversely, it is established case law in countries with 'first to file' that any non protected disclosure at all is usable as a prior art defence. Winning a case is of course related to how good the lawyers are and how impartial the judge is.
Around 10 years ago I saw a patent invalidated in an Australian court because one of the inventors had, prior to filing, verbally told a group of people about the key claim outside of a non-disclosure agreement. The decision was upheld on appeal. So I suspect there were other conditions in your linked example that allowed the prior art to be dismissed. And by all accepted definitions of the phrase (legal or otherwise), that example did constitute prior art.
I suppose you could argue that it's all about the crap shoot that is the legal system, and you'd probably be right. Which further justifies the argument that the patent/legal system is as it stands still very very broken.
True. But the alternative to that is untrusted computing - ie. any app you install gets more control over the device than you.
The vast majority of users are not even remotely capable of providing a higher level of trust than a competent third party. This is akin to representing yourself in court instead of hiring a lawyer who is an expert in the laws and defence techniques that apply to your case. Step and repeat for each app you install.
No. First to file only differs from the previous system (ie. first to 'invent') in that two equivalent patents filed with in a year or two used to go to the inventor that could prove first invention date; whereas with 'first to file' it goes to the one with the earliest filing date.
They also dropped the ability to file within 1 year of prior publication of the invention. This makes prior art much more effective as a defence. It also makes it harder to file patents based on someone else's (or your own) publication.
So, as long as people don't "tell you their best ideas" in secret, your patent can be effectively invalidated with that prior art. In the old system, they'd probably have been screwed if they didn't maintain fully witnessed and officially notarised log books.
This has also existed on trucks for decades in what is known generically as the 'engine retarder'. There are many different types of retarders from just using engine compression, hydraulic systems and regenerative braking systems. Most trucks have options to augment the brake lights when the vehicle is decelerating due to use of the retarder.
In any system of huge interactive complexity, there is virtually no way to test every possible combination of options/features/revisions. This appears to be an issue that can only be replicated by taking a complex series of steps, not just a stateless change of a setting or two.
In your analogy it would be more like Ford shipping thousands of vehicles and a few of them use excessive fuel in certain hard to predict situations (eg. driving in 40 degree C heat, windows exactly half way down, air conditioner on econ mode while being set to recirculate, and cruise control enabled but disengaged).
However, in the case of iOS5, v5.0.0 seems to work fine for the _vast_ majority of users. The fact that they have been forced to contact customers to help with tracking down the problem means that they can't easily replicate it in the lab.
That is a far cry from having "MAJOR problems in Beta", "HUBRIS", and "released it anyway on schedule".
There was a documentary on this in the 1980s where scientists were using beams to trap ghosts. Seemed to work pretty well then, I don't know why this has taken so long.
Too risky.
Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light. Total protonic reversal. That's bad.
Perhaps by the time these cars are commonplace, having valid insurance will be enforced by the car itself - if you don't have an insurance plan, the car won't move. Making your question of who pays in an accident moot -- the insurance company pays.
What's more likely to happen is that the cars will be sold 'pre-insured' (ie. insured by the manufacturer). This is because the probability of an 'at fault' collision being caused by the vehicle is unrelated to the skill/etc of the driver. Also, if the car causes an accident, the responsibility will end up pointing back to the manufacturer anyway - so it's pointless having the end user take out insurance if their insurance is just going to push the cost back to the manufacturers insurer.
Insurance is required at present because people are unpredictable and regularly make mistakes. Some people are more careful than others, and some people like to live on the edge and drive by the seat of their pants. In humans, these factors are variable; in a machine, they are constant.
Based on that video, I should just drive close enough to the car in front of me that half or less of my license plate is readable by the camera. Thanks for increasing road safety, automated ticket systems.
That only works if the guy in front of you is also speeding. If he's not speeding, then you can't sit close enough to avoid a collision without driving slowly yourself (ie. not speeding). And if he is speeding, there's a good chance he'll dump full anchors when he wakes up and notices the speed camera (ie. tail gater gets what he deserves as his insurance goes up after rear ending someone on an open stretch of road).
It seems to me that this would encourage less tailgating, not more.
The real problem with speed cameras (and especially combined with ever decreasing tolerance bands) is that now everyone drives around constantly staring at their speedometers instead of paying full attention to the road. I have no problem with the cameras picking up someone that is excessively above the limit, but once the infringement tolerance drops below 10 to 15% of the posted limit, the benefits no longer outweigh the negatives.
Taking internal photos and posting them online brings up some security questions, but Google says its photographs will 'capture nothing different to what a customer would see by visiting the business in real life.'"
And it also raises other equally valid questions like should I eat lunch today, and how far will it be to the nearest toilet if I get a sudden attack of diarrhoea. Oh wait, no it doesn't.
Slashdot Mirror
Inconceivable.
I'd be curious to know what the minimum number of connections necessary to link any two persons is, over the average.
Probably infinity as there are most likely some small subgroups that don't contain a friend with an account that links outside that subgroup. That means that Facebook can't reliably measure a maximum connectivity estimate without saying 'infinity'. And even if they remove the infinity outliers, there would still be some higher number linkages simply due to a lack of active friending between people that do know each other, but don't want them to be 'friends'.
In the real world, one of those people in the outlier groups probably 'knows' someone outside of the clique group. But, within Facebook, they may not have an account (or may be intentionally 'non friended') so are not a measurable link.
This brings us back to the old claim of a maximum 6 degrees of separation between any two people on the planet.
Why? Imagine if the entity's mandate was to:
1) Maintain up to date contact details for the copyright owners (the moment these lapse, the work tentatively goes into the public domain)
2) Maintain an automatably searchable index of all submitted tunes, lyrics, etc.
3) Allow downloadable access to all submitted features of the music (ie. lyrics, recording, etc)
4) Maintain an easy (ie. instant) online payment system for people/organisations to submit payments based on plays/prints/downloads/public performance/etc.
5) Pay creators based on the information in their database. (This might have been hard 50 years ago, but data storage and technology have been more than adequate since the 1980s to do this properly.)
6) Allow automated submissions so the likes of iTunes, Amazon, radio stations, churches, etc can easily submit their play/purchase/performance information.
7) Provide standardised contracts for recording artists, book authors, so the guy that's making his debut into the industry isn't guaranteed to get ripped off the moment he approaches a publisher / producer / etc.
and
A) Force all copyright 'holders' to submit their works to the foundation for protection - with all non-submitted works are deemed public domain (with a 12 month grace period). The previous system of registered copyrights was so much better than the crap fest that we have now. The way it works now, it's nearly impossible to track down copyright holders for anything that's not currently mainstream - especially when the works tend not to contain attributions with valid contact information (if any).
B) Make it the onus of the copyright holder to keep the contact information up to date.
C) Reduce copyright durations to sane periods of time (ie. 7 years) (with optional extensions that are available for a nominal payment which increases exponentially as time passes).
All of the above would effectively make it possible to do this efficiently. The way it stands now, I have no idea who the current copyright owner really is on anything at all (how can I know if something has been sold on?), and any organisation that exists today that emulates this type of service only represent a small percentage of the works created. And those organisations have such huge 'profit' overheads that hardly anything gets paid to anyone that isn't a top tier act.
Even if hybrids didn't exist, this is a recipe to guarantee you won't live to see your grandkids. Pretty much any new car that is coasting and/or isn't revving the shit out of its engine is virtually inaudible amidst the general city din.
I always look, even if I don't hear a thing. Hearing is useful as a double redundancy, but should never be used as a sole source of information when performing a potentially life threatening manoeuvre. It's not like you can't lean forward and stick your head around the hedge to double check - and then continually check the blind zone while you cross the street. You don't just have a quick look, turn your brain off and keep walking.
I do agree that assholes that cut their hedges right to the street line (and councils that plant hedges in a similar fashion) should be held accountable. It is much more effort and far less pleasant to safely cross a street as the visible distances decrease.
Apple purchasing this patent from Xerox is essentially equivalent to Apple outsourcing their R&D. Same end result.
Actually, Apple purchasing this from Xerox probably had nothing to do with using it to enhance their development efforts. You can pretty much guarantee that this patent would have been found by dedicated patent attorneys, probably while trying to file their own after Apple's engineers had already developed their implementation. Their options would have been to try to work around the overtly broad claims, find convincing prior art that circumvents all the claims, or just buy the patent at a reasonable price to add to their 'war chest'.
I can imagine Steve saying that he wanted a way to be able to see a map on his upcoming iPhone - kinda like a handheld GPS but on a phone! An engineer says, well we can avoid huge licensing and update hassles by using Google Maps - with all the advantages of ancillary information that can also be included on these maps - e.g. restaurants, traffic, weather, etc. Steve says, well get to it. I'm sure every software developer reading this would consider any 'location services' solution from this point as obvious.
Not: Steve saying that he's found a really neat patent about sending location information to a server that remotely processes the information and sends back some info to a remote device. An engineer then saying, we'll start a brain storming session on how we can make use of this, and then coming up with the location services / mapping implementation. No.
And not: Steve asking the engineers why they are having trouble implementing a GPS on their new phone. They say they just can't work out a solution. So Steve has his patent attorneys trawl the patent system for something that could help them. They find this patent and give it to the engineers who say: "Thanks Steve! This is a totally novel and inventive idea that we would never have thought of if not for the luck of finding a solution in this patent!" Again, no.
This is why engineers hate patents.
What will happen next are events reinforcing the myth that Android is a stolen product.
It's a sad day indeed.
You're telling me. I was trying to use my iPhone yesterday and half the OS was missing! Stolen from right under my nose.
Isn't AAC just the MPEG4 version of what we know as mp3 (which is really just MPEG1/Audio layer 3)? There are already many open source implementations of AAC, so I don't see it as the same thing.
The real problem with AAC is the MPEG patent swamp. Even if Apple were to release an open source codec, it would still be under the same shadow that hangs over anyone that isn't lining the pockets of the MPEG licensing body.
In my experience, the response of acoustic speakers is not that great for anything other than speech and music. If you have a smartphone, try generating a white noise signal and watch the spectrum of the audio input (there are audio spectrum analyzer apps around); it won't be anywhere near flat.
On the other hand, my acoustic signal processing experience mainly has been with signals that were somewhat spread out (data communications), which is where the non-linear frequency response of audio I/O messed things up. The chirp signals these guys use probably occupy a much more linear part of the spectrum.
Unless the transducer has a significantly non-linear or narrow band response, it is extremely easy to compensate for this with only a minor signal to noise / distortion degradation. An impulse response and deconvolution is a good starting point when trying to subtract out the effects of imperfect devices (obviously within reason - you can't reverse the effects of a null or total signal cancellation, but a +/-10dB variation across the required spectrum wouldn't be too much to ask).
Here's the part that I've found really problematic on iOS devices: audio processing latency. Most signal processing of the type you describe typically work with real-time systems which makes timing straightforward. But this is not so on iOS devices, even with their low-latency API... Worse than the latency, there is a fair bit of jitter. Sure, you can do real-time stuff at the driver-level, but an app in the app store does not get that level of control. I have some idea about how to account for it, but I'm not sure how these guys have done it (I'd guess the "multi-cycle" approach has something to do with it).
In a system like this, the continuous streaming nature of the conversion process (crystal locked ADC/DAC sample clocks) acts as the synchroniser, and a 100ms (or even a few hundred milliseconds) latency isn't likely to cause a major problem (unless you have a huge number of feedback rounds between the two devices and expect instant results). Fractional sample rate conversion is useful for perfect synchronisation, but probably not necessary here. And jitter is only problematic if you're seriously underpowered (in which case you just increase the latency until all your processing can be completed before you are required to output a result based on that data), or you're trying to drive the sampling clock source from a recovered clock source (generally a bad idea and obviated by use of fractional sample rate conversion if required).
Patents are a different matter. Sure, you'll find standard stuff described all over in the text of the patent, but what really matters are the claims. The rest of the patent is only to provide background information and detailed description of what the claims cover. Of course, often patents do slip through with claims covering existing stuff, but in my experience this is not as common as /. tends to think. In my experience, in the past few years, the various patent offices have become very good about finding relevant prior art.
I have seen many times the 'standard stuff' claimed as the 'inventive step' underpinning the patent. Patents are hard to read at the best of times and I have mostly only ever reviewed them when requested to by a client that requires an interpretation of what is really being claimed. It doesn't take long to get pretty jaded when you've been doing that for a while. That being said, it's been a couple of years since I've done this, so maybe as you say things have improved. But, since this has been going on for over 20 years (and probably since the dawn of the patent system), I very much doubt it. Maybe they're rejecting more things that are obvious, but it really does take someone skilled in the field to be able to understand the problem and do this properly - including point out the prior art that may not use the same terminology as used in the patent. (eg.
Keep in mind that all that 'specialised equipment' evolved out of a need to improve the simpler predecessor systems.
Sonar and sonic range finding systems use all that 'extra equipment' to achieve ranges far in excess of 25m and in mediums much more variable than air. The impulse response of miniature consumer grade condenser microphones and speakers are more than adequate for air use within an octave of the audible spectrum. The speakers in the iPhone are primarily limited by their output power, and the fairly omnidirectional nature of the microphones may lack overall sensitivity, but both are simple parameters that really only end up reducing total available range and accuracy (as compared to specialised custom hardware using the same algorithmic solutions).
Applying the same design principles that would normally be applied to a specialised system design to an iPhone implementation, would be very unlikely to provide anything unknown to someone in the industry. This is very similar to early stage engineering "proofs of concept" that are used to test various parameters within a system design, without the interactive complexity of implementing the entire system.
There is nothing within this extremely simple setup that hasn't been done as part of a larger system design. A single (consumer grade) speaker + microphone used in transmissive, active echo, or for passive echolocation is not unusual. Considering the iPhone has excessive processing capability to implement all the standard approaches (correlation, convolution, deconvolution, filtering, impulse response measurement, etc), there is no real need to be 'clever' as such.
'Back in the day', when trying to do this with a 10MIPS DSP in real time with moving objects, it was much more important to come up with better algorithms and shortcuts. Of course, this could otherwise have easily been done with standard theoretical methods and a modern processor a hundred times more powerful.
I see patents pop up all the time that describe things that are far from novel. Most of those patents are usually 'invented' by people with no real experience in the given fields. ie. Ideas that seem like earth shattering discoveries to the uninitiated, but are really just standard techniques used by properly skilled engineers.
I'm not saying that this iPhone app is bad/good, just that it is VERY unlikely to contain any actual improvements to the current state of the art (or the state of the art 20 years ago for that matter). I say this, because there is no real need to do anything new to achieve the results that they are claiming.
BTW, in the past I've worked on sonar/radar systems for air, ocean and rock. The biggest problem in 'noisy' environments is a lack of output level. Multipath isn't a major problem for a point to point (ie. line of sight, shortest path) ranging device - unless you're talking about wave guide shapes/sizes over long distances.
When I see the word 'novel' applied to techniques that have been used for decades, I smell 'patent lawyer'. And be extension: astroturf.
Signal processing techniques applied to sonar (whether active, passive or beaconed) including signal correlation, spectral adaptation/equalisation, and filtering are standard fare in this field.
Maybe by novel they mean "on an iPhone"?
That being said, there is nothing that says this won't work - as it worked extremely well 20 years ago on dedicated systems with far less processing power. (Those systems, however, used multiple arrayed transducers and tailored beam patterns to significantly reduce the effective noise floor.)
The previous system in the US allowed that to happen due to the 'first to invent' principle trumping certain extents of prior publication.
Conversely, it is established case law in countries with 'first to file' that any non protected disclosure at all is usable as a prior art defence. Winning a case is of course related to how good the lawyers are and how impartial the judge is.
Around 10 years ago I saw a patent invalidated in an Australian court because one of the inventors had, prior to filing, verbally told a group of people about the key claim outside of a non-disclosure agreement. The decision was upheld on appeal. So I suspect there were other conditions in your linked example that allowed the prior art to be dismissed. And by all accepted definitions of the phrase (legal or otherwise), that example did constitute prior art.
I suppose you could argue that it's all about the crap shoot that is the legal system, and you'd probably be right. Which further justifies the argument that the patent/legal system is as it stands still very very broken.
So why didn't the police get a warrant? Not enough direct evidence?
Would it be ok if a cop hid in the boot of your car without a warrant instead?
I agree completely. And the result should be published to expand the prior art and promote the usefulness of the sciences and arts.
True. But the alternative to that is untrusted computing - ie. any app you install gets more control over the device than you.
The vast majority of users are not even remotely capable of providing a higher level of trust than a competent third party. This is akin to representing yourself in court instead of hiring a lawyer who is an expert in the laws and defence techniques that apply to your case. Step and repeat for each app you install.
this won't matter too much longer now that we are going to implement "first to file" patents. previous art be damned. if i file, then its mine. so..... tell me your best ideas. http://en.wikipedia.org/wiki/First_to_file_and_first_to_invent
No. First to file only differs from the previous system (ie. first to 'invent') in that two equivalent patents filed with in a year or two used to go to the inventor that could prove first invention date; whereas with 'first to file' it goes to the one with the earliest filing date.
They also dropped the ability to file within 1 year of prior publication of the invention. This makes prior art much more effective as a defence. It also makes it harder to file patents based on someone else's (or your own) publication.
So, as long as people don't "tell you their best ideas" in secret, your patent can be effectively invalidated with that prior art. In the old system, they'd probably have been screwed if they didn't maintain fully witnessed and officially notarised log books.
This has also existed on trucks for decades in what is known generically as the 'engine retarder'. There are many different types of retarders from just using engine compression, hydraulic systems and regenerative braking systems. Most trucks have options to augment the brake lights when the vehicle is decelerating due to use of the retarder.
But not remembering the name of the function will make you a bad coder in this test.
Why? It's not like they're going to compile the result directly off the sheet of paper / blackboard / whiteboard.
WTF?
In any system of huge interactive complexity, there is virtually no way to test every possible combination of options/features/revisions. This appears to be an issue that can only be replicated by taking a complex series of steps, not just a stateless change of a setting or two.
In your analogy it would be more like Ford shipping thousands of vehicles and a few of them use excessive fuel in certain hard to predict situations (eg. driving in 40 degree C heat, windows exactly half way down, air conditioner on econ mode while being set to recirculate, and cruise control enabled but disengaged).
However, in the case of iOS5, v5.0.0 seems to work fine for the _vast_ majority of users. The fact that they have been forced to contact customers to help with tracking down the problem means that they can't easily replicate it in the lab.
That is a far cry from having "MAJOR problems in Beta", "HUBRIS", and "released it anyway on schedule".
No, but it's the de jour whipping boy for stories like this.
There was a documentary on this in the 1980s where scientists were using beams to trap ghosts. Seemed to work pretty well then, I don't know why this has taken so long.
Too risky.
Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light. Total protonic reversal. That's bad.
Perhaps by the time these cars are commonplace, having valid insurance will be enforced by the car itself - if you don't have an insurance plan, the car won't move. Making your question of who pays in an accident moot -- the insurance company pays.
What's more likely to happen is that the cars will be sold 'pre-insured' (ie. insured by the manufacturer). This is because the probability of an 'at fault' collision being caused by the vehicle is unrelated to the skill/etc of the driver. Also, if the car causes an accident, the responsibility will end up pointing back to the manufacturer anyway - so it's pointless having the end user take out insurance if their insurance is just going to push the cost back to the manufacturers insurer.
Insurance is required at present because people are unpredictable and regularly make mistakes. Some people are more careful than others, and some people like to live on the edge and drive by the seat of their pants. In humans, these factors are variable; in a machine, they are constant.
Based on that video, I should just drive close enough to the car in front of me that half or less of my license plate is readable by the camera. Thanks for increasing road safety, automated ticket systems.
That only works if the guy in front of you is also speeding. If he's not speeding, then you can't sit close enough to avoid a collision without driving slowly yourself (ie. not speeding). And if he is speeding, there's a good chance he'll dump full anchors when he wakes up and notices the speed camera (ie. tail gater gets what he deserves as his insurance goes up after rear ending someone on an open stretch of road).
It seems to me that this would encourage less tailgating, not more.
The real problem with speed cameras (and especially combined with ever decreasing tolerance bands) is that now everyone drives around constantly staring at their speedometers instead of paying full attention to the road. I have no problem with the cameras picking up someone that is excessively above the limit, but once the infringement tolerance drops below 10 to 15% of the posted limit, the benefits no longer outweigh the negatives.
From the summary:
Taking internal photos and posting them online brings up some security questions, but Google says its photographs will 'capture nothing different to what a customer would see by visiting the business in real life.'"
And it also raises other equally valid questions like should I eat lunch today, and how far will it be to the nearest toilet if I get a sudden attack of diarrhoea. Oh wait, no it doesn't.