imagine: [a lot of things]

Richard Franks richard.franks at
Tue Nov 21 19:29:52 CET 2006

On Tue, 2006-11-21 at 17:05 +0100, Robert Michel wrote:
> What a fu** mines field with patents... Thinking 1 Minutes about an
> idea, hacking would be faster than the shipping of the IC - but fighting
> with the lawer would take you month or years...

Yup, you can pretty much bet that there are patents for just about
everything you could want to do with a cell phone, and some things that
you wouldn't. However, there are a few neat solutions to this potential
quagmire, and I suspect quite strongly (from observing the strategy so
far) that the team has this in hand.

> The Neo1973 has AGPS, but GPS could not work as a compas
> - it could only calculate directions when you move. But
> when you are standing at a crossing - rotatet to look which
> street you will choose - your map on your device will not
> rotate - it would be great to have a compass inside....

Or add a bread-crumb trail to the map.

> indoor-navigation
>   accelerometer become a piedometer together with the compass
>   also direction. It should be possible to detect waking on
>   steps - using lift or escalator
>   by walking into the building AGPS told the location,
>   inside it could be neccessary to calibrate - manual,
>   or the device please you to walk to a given point..

Or drop bread-crumbs inside the building ;-)

> ebook:page turn
> gaming

Fun until you elbow someone in the eye whilst playing on the subway.

> menue selection
> program start  
> textinput
>   you deaf language by talking with your hands - I think it
>   could be easy to learn 30 or more fast figures to move
>   the device to write with moving the device

Or send an offensive email to your mum as you walk down the street!

> music instrument
> phone profile

Some really interesting ideas/uses, despite my trite comments.. for
gaming/navigation/ebooks I can't help feeling that perhaps existing
products geared towards these needs 'own' that application area -- in
that adding an accelerometer wouldn't give a desirable effort/reward

> no incomming calls beside my girlfrind when I walk
> inside the park or visiting the park bank that she and I
> likes most, by comming from the North side will call her
> automaticaly...
> :)))))

Yup - I can totally see GPS-based location behaviour alteration holding
massive potential for interesting new applications. I do hope the OM SDK
does carry multi-layered support for this. e.g.

* Will each 'GPS' application query the GPS driver directly by default,
or will they be encouraged to go through the API -- if I have 5 GPS
applications, I don't need them all to perform their own raw calcuations
-- the API could query (say) once a second and give the same value back
to multiple applications.

* What if your 'girlfriend/park' application conflicts with your
'football team/park' application, and all of your buddies interrupt your
romantic stroll expecting to play football? Defining location-areas, and
managing priorities might work better then as a centralised
decision-making implementation that calls your specific 'girlfriend'
code. Any new location-app registers its boundary-polygon-event and
waits to be called. This would also allow for a nice google maps API
mashup, showing all of your 'locations of interest' at once, despite the
fact that each location could be calling a completely different

> Ok most of my ideas (today) are frisky...

Oh my.

> but with freeing the mind from the restriction
> todays mobile have we will find also smart ideas
> that the mass market would like to have.

Agreed - there are definitely some interesting ideas which you've put
forward here.

> PS:
> It would be fun when the caller (of course only friends of
> you) could decide wich sound is used for ringing the phone
> and that they could start taking to you bevore you pick up
> the call to activate your mic....

This raises another another huge question I have about the SDK/API right
now - with regards how it handles event-conflicts. For example, what if
your buddy calls you, so your code recognises their privileged status
and allows them to talk instead of the ringtone (your idea above), but
what if this happens before the park-location code is called which would
otherwise have blocked his call?

If the API ships with such ambiguities then it's going to get quite
messy (in the chaotic, unpredictable sense) when you've installed
multiple applications which end up stepping upon each others toes.


More information about the community mailing list