The Projector Cell Phone

31 July 2008 at 23:33 | Posted in Cell Phone, Inventions, Mobile Phone, Projector Phone | Leave a comment
Tags: , , , , , ,

[Category: Inventions. If you are new to my blog please read the “About itimes3” page first]

You probably know this from experience: you’ve got your cell phone (or mobile phone, depending on where in the world you live) beside your bed, and at some stage in the middle of the night it rings. Half asleep, you try to grab it, and after some stumbling in the dark to get hold of it, you activate the display (depending on model) and try to focus on that, squinting to see who is calling, trying to decide whether or not to answer.

Personally, I find this one of the most irritating features of my cell phone: the fact that I have to grope for it in the dark when it rings in the night (as it does with some frequency) in order to determine who is calling.

The solution to this would be a mini-projector built into the unit. Before going to bed, the user would position the cellphone with its “projector side” facing a nearby wall which is easy to see from the bed without effort.

Should the phone ring during the night, the projector would be activated and would project the name or number of the caller onto the wall at perhaps a 45-degree angle and a distance of between one and two meters (the projector probably being powered by bright LEDs rather than a traditional light source to reduce energy requirements). At the same time, voice activation and speakerphone would be available so the user can tell the phone whether to take the call and if yes, can have the conversation whilst staying in bed and not having to reach out and grab the phone and manipulate it.

The same projector could be used during the daytime to project onto objects closer to the projector in a daylight setting (say 5 to 20 centimeters away; not further as it would require too much power for the projector): the user could position it close to a white surface on a desk or table and thus see who is calling without having to look at the display on the phone.

As the projector would use extra battery power, it should be possible to activate/deactivate easily, ideally using a small switch on the side of the phone or similar.

An additional feature could be to have this function available from a docking station next to the bed, which the user would already have positioned facing the wall as required. The docking station would be connected to the power supply, and when the phone is placed in the docking station, it would be charged up, whilst at the same time projecting a clock (including the alarm time set) onto a nearby wall. Because the phone is on mains power, it could project the clock all night long, and should a call come in, switch to projecting the caller details onto the wall.

So: which is the first cell phone company that’s going to build this little feature into their products?

If you like this idea and you work in a type of industry where this is relevant, I would be happy to discuss in more detail, answer questions or assist in other ways. For details and contact information please see the “About itimes3” page.

George Spark

Disclaimer: Any trademarks mentioned herein are the property of their respective owners.
All usage of this site is entirely at users risk.

The Ultimate Travel Booking Website

30 July 2008 at 23:52 | Posted in Airlines, Budget Airlines, Innovations, Online Booking, Online Travel Booking, Travel | Leave a comment
Tags: , , , , , , ,

[Category: Innovations. If you are new to my blog please read the “About itimes3” page first]

If you have ever tried to book a somewhat complex travel itinerary online, say six or seven cities within a fairly tight schedule, and you also wanted to have a choice of all available airlines (including budget airlines) and see all available flights and prices, *and* don’t pay more than you have to, you know how time consuming this can be.

A short while ago I did this, wanting to book a trip from¬†Sydney to Thailand to Singapore to Hong Kong to Indonesia to Malaysia to Thailand and back to Sydney. It took me the better part of a day. Why? First I had to find out all the airlines that operate on all the sectors I wanted to fly. Using “popular” sites such as Expedia, Zuji and the like is not an option as they work with a limited selection of airlines and tend to be more expensive than if using airline websites directly. Amadeus.net can help find some prices but it also operates only with some of the bigger airlines, not all of them. Budget airlines in particular are almost never featured on the major travel booking sites. So you go and google for all the airlines in the region, which takes awhile. Particularly budget airlines, new ones come up all the time and may offer new destinations, cheaper flights, etc.

After an hour or two you have a list of all the websites of all the airlines that fly each of the sectors you want, and a bit of an idea what the reputation of these airlines is (the smaller ones I tend to google for reputation, to see how many wrecks they had in recent times, just to be on the safe side ūüėČ –¬†but it takes more time).

Then you have to go and find the best flights for each sector you want. The required time of arrival and/or departure. The price difference between the various flights available. The availability of seats on each flight. Any caveats and hidden extras (such as below-standard baggage allowances, which a number of budget airlines use). Running all the prices in local currency through oanda.com to have an idea what you’re actually going to pay. This takes, in my experience, another two to three hours if you want all the details on six or seven sectors.

Then, when you have all the information you want, you have a look at it all and make your decisions. Then you go back in and book each flight – usually on the airline’s own website, which not only offers the best price in most cases, but also extras such as direct selection of your preferred seat etc. However this once again takes half an hour or so, stepping through the various screens on each site, entering the credit card details, and waiting for confirmation etc.

Finally, you have to check and print out each of the e-tickets, which takes another 10 minutes or so (only when travelling in Brazil last year did I have my e-tickets txt-ed to my cellphone, but then Brazil is surprisingly more modern than many people think).

So after the above experiences, I was wondering why nobody has yet come up with the Ultimate Travel Booking Website, which I believe should look like this (or something very similar; details to be finetuned, this is an initial “draft sketch” of the proposed site):

  • Website asks for size of itinerary: one country only; one continent only; or multiple continents: select which country or continent(s).
  • Website shows map of selected area (one country, one continent, multiple continents or whole world), below a box as follows:
  • Box shows “Details of first sector” or similar asking user to check boxes of required flight details:
    – date of flight
    – economy, business or first class (or no preference)
    – include or exclude budget airlines
    – preferred departure time (precise time to be entered; or am or pm preference, has to be this date; or flexible with dates)
    – list airlines based on lowest cost first, or list airlines based on flights available as close as possible to requested time
    – only show flights with available seats in preferred class, or list all flights regardless of availability
    – only show direct flights or show all flights
  • After completing above box of details, user draws, using the mouse, a line from one city to another, representing the first sector of the itinerary.
  • Once the line has been drawn, the system extracts the relevant data from its database which contains all flight data for all commercial flights in the world (including budget airlines), and presents it on screen, for the user to select the preferred flight for that sector. IMPORTANT: the user has the option to “tentatively select” so changes can be made later. Each airline will have a rating based on user input (using up to five stars, or a system using percentages such as on eBay for example) – this will give an initial indication of user experiences with an airline. If the airline has less than say 25 ratings, it will show as “unrated”, so the user knows it may be good to google for details on this airline prior to making a booking decision.
  • Once the preferred flight has been selected, user has option to finish or to continue building the itinerary.
  • Alternatively, the user can draw lines to other cities which will immediately and rapidly bring up the details for the new choice.
  • Upon the choice to continue, the above procedure repeats, positioning a new “Details of second sector” box for the user to fill out. This box inserts itself below the first box, but above the map.
  • After filling out the second box, the user draws the second line (from the city first arrived in to the next city).
  • And so forth.
  • At the end of the process, the user is redirected, sector by sector, to the websites of the airlines for payment (or this would be handled by the system, which could present a single invoice).

The main ideas being:

  • The user fills out an on-screen box (web page) with details for each sector, which forms the basis for the searches conducted thereafter.
  • Once the on-screen box has been completed, the system is highly flexible. It allows the user to “experiment” drawing lines between different cities at will and immediately brings up the relevant data, so the user has an overview of all available options to any city nearly immediately. This¬†type of system would allow¬†for flexible and fast travel planning, including researching alternative options. This is, to my knowledge, not available anywhere on the Internet today.
  • The user has flexibility to make changes in one box, which then “ripple through” to other boxes (the system keeps track of changes across the itinerary).
  • The user gets charged the same price as the airlines charge (to avoid the user only using the system for information, then booking at the airline website).

The business model would be that the airlines agree to pay the site operator a small amount, such as two dollars per sector booked, for example, which they agree to deduct off their own website’s ticket price (so for example if Qantas charges $100 for a sector on their website, they agree to sell that sector for $98 to the site operator, which charges the customer $100 for it, and keeps $2). The cost to develop the website would be the main expense. After¬†the site¬†is online, costs would be mainly with chasing up airlines to provide their databases to the website in time, plus general support and administration. This can be automated to a large degree. Airlines would be inclined to agree to the $2 charge because¬†this type of¬†website would quickly become a major player in the online travel sales game. Different people would use the site: those looking for a bargain, and those looking for the best possible connection. For this reason, all airlines will be interested in participating.

The site could generate additional revenue by offering hotel deals, car rental, etc. ideally also using the same model, e.g. the customer can select from hotels and car rental outlets in arrival cities based on a price or availability. The site could make deals with the likes of wotif.com for the hotels for example, and once again gain a modest but fully automatic commission from each deal.

For people looking at booking first class travel, the site could also offer private jet and share jet options, earning commission from this type of booking.

Additional features could be added to the site, such as organising of conferences and getting all delegates tickets and hotels booked through the system, local entertainment and restaurant bookings, and even migration features including linking to information about local rental accommodation, car dealerships, employment websites etc. in arrival cities. This would obviously be done using database feeds from these operators, so the site would not need to worry about content, only design the initial user interface/presentation for it.

I have many detailed ideas about this website opportunity however in the interest of (relative) brevity I shall leave it at this.

If you like this idea and you work in a type of industry where this is relevant, I would be happy to discuss in more detail, answer questions or assist in other ways. For details and contact information please see the “About itimes3” page.

George Spark

Disclaimer: Any trademarks mentioned herein are the property of their respective owners.
All usage of this site is entirely at users risk.

Next Generation Bar Automation

29 July 2008 at 22:49 | Posted in bar automation, Bars and Pubs, Beer Tap Machines, Drink Mixer Machines, Innovations | Leave a comment
Tags: , , , , , ,

[Category: Innovations. If you are new to my blog please read the “About itimes3” page first]

Friday or Saturday night at the pub: in too many pubs, limited staff, a small bar area or other issues cause the ordering process to be slow. On busy nights, more often than not, it can be more or less a fight to get to the bar and order drinks in quite a few pubs and bars.

I have walked away from pubs and went elsewhere due to this issue, as often I can’t be bothered to spend part of my evening waiting in a queue to buy a few drinks.

Much of the reason for this is slow processing of the drinks orders. The reason for the slow processing is often the mechanics of preparing the drinks, which are either labour intensive or restricted by maximum output speeds of equipment used and people working.

Take beer for example: the speed at which a glass of beer is filled is relatively slow. Usually, bar staff place one or two glasses under the tap and wait until they are filled. This is technically a waste of time, but they have to do this as the taps are slow.

Another cause for slowness is the mixed drinks: all mixed drinks are manually mixed, however the majority of mixed drinks are standard mixes (rum & coke, vodka & soda, etc.) and there is no technical need to manually prepare them.

The third cause for slowness is payment: the process of paying for drinks using a variety of cards or the cash change procedure often adds significantly to the order processing time.

For the above reasons I would like to propose that relevant industries develop automated solutions, so that the pub of the future may feature the following systems at the bar:

Automated beer tap machine. One of the reasons beer tapping using traditional taps is slow is the narrow diameter of the pipe. This is presumably done to make sure not much beer is spilled should the tap not be shut off in time. The beer tap machine will have a much wider pipe diameter, to allow for much faster filling of the glass.

The way I see this work is as follows: glasses are fed into the machine automatically (after someone feeds them into a glass guide which can hold at least 10 glasses on a small machine, or entire trays of glasses for bigger models, and through which the glasses are fed into the machine). When a customer orders a beer, the bartender presses one of a set of big buttons on the machine which each represent a different type of beer. The machine rotates the correct nozzle for the selected type of beer over the glass, and fills it within about one second at high speed.

This can be done because the filling is automatic, and the level until which the beer is filled into the glass is automatically scanned by a laser or similar, so the machine stops filling at exactly the right time, preventing spillage. This will need to be calibrated for each type of beer and special foam-shaping devices may need to be designed and fitted to ensure the beer does not foam excessively as a result of the high-speed filling process.

A “robotic hand” moves the filled glass onto a rotating tray which space for a number of glasses, from which the bartender then removes the glass and presents it to the customer.

Larger machines could be equipped with a labeler that attaches a small disposable thin paper label to the glass with the beer logo (using either just water or a glue that quickly dissolves in water). This will enable staff and users to see which beer is in the glass, which is handy if the machine can dispense 10 different types of beer or so and glasses come out at a rate of 20 per minute.

The machine should also indicate beer levels in the connected vats, and sound alarms at appropriate times so bar staff will know well in advance when a vat is near empty and a new one will need to be connected up. However of each type of beer two vats should be connected, so when one is empty it can be swapped out whilst the other vat is fully operational, and it is not necessary to interrupt the dispensing of beer.

These machines should be able to deal with different types and sizes of glasses, and also be adaptable to use plastic glasses, to be used at events.

The second machine required is the drink mixer machine. This could be operated alongside the beer machine, in some cases, depending on how busy the environment is, by the same operator. This machine would be used to prepare the most commonly ordered standard cocktails, such as rum and coke, whiskey and soda, etc. as these drinks take a relatively long time to prepare: taking a glass, filling with ice, finding the bottle, filling up with the soft-drink and finding a straw.

The drink mixer machine could be made in a simple or a complex design, depending on volumes required (size of the pub or bar, etc.). The machine would have large, easy to hit buttons: one button for ice, one button for each liquor, and one button for each soft drink. The operator would in quick succession hit the required buttons and the glass would be filled and ready within three seconds, including a straw that would be shot into the glass by a dispenser in the machine.

The simple version of the machine would simply have liquor bottles and vats of soft drink connected and sound an alarm when anything is near empty. The more complex design would use larger quantities of liquor with a rotation system so there would also be bottles of any drink hooked up, whilst empty bottles can be swapped out whilst the machine is still fully operational.

Other drinks, such as complex cocktails, wine, and special drinks would still be done manually, at a third “step” in the drink ordering process. People ordering drinks would first walk past the beer machine, then the drink mixer machine, and then the manual drink ordering bar.

At this point, there would also be the pay stations. Because paying is one of the most time-consuming elements of a drinks order, this will need to be automated by means of a row of pay stations (as orders can be processed quicker than people can pay, there would need to be at least five or more pay stations). These would be like the pay stations at self-service checkouts at the supermarket, where there is a card swipe, a bank-note inlet, and a coin inlet, as well as a proximity-card reader to enable manual override by bar managers, if required.

When a customer orders his or her drinks, he or she is assigned a pay station number which subsequently flashes above the assigned pay station. Once the order is placed the customer goes to the pay station and pays, and a display or colour code indicates to the bar staff that the order has been paid for, and the drinks are subsequently released (note: it could be that it would be easier to pre-pay the drinks, so that once paid the machines and if necessary the manual drink ordering bar would have the drinks ready near immediately for collection).

Equipping a bar with the above setup would, I believe, increase bar output three- or fourfold and lead to happier customers.

This scenario, however, is only useful in places where the bars and pubs tend to be big (such as in Sydney), or at events such as pop concerts and sports venues where large crowds need to be served quickly. In some countries, many bars are small and intimate and this type of setup will probably not apply there.

If you like this idea and you work in a type of industry where this is relevant, I would be happy to discuss in more detail, answer questions or assist in other ways. For details and contact information please see the “About itimes3” page.

George Spark

Disclaimer: Any trademarks mentioned herein are the property of their respective owners.
All usage of this site is entirely at users risk.

Taxi Safety Monitoring Solution

28 July 2008 at 11:24 | Posted in Inventions, Taxi Driver Safety, Taxi Passenger Safety | Leave a comment
Tags: , , , , , , ,

[Category: Inventions. If you are new to my blog please read the “About itimes3” page first]

My girlfriend often has to take a taxi home when she finishes work. The problem is, she is rather attractive and a small percentage of taxi drivers are, well, perverts.

A few times per year, in all cities I have so far lived in on several different continents, stories pop up in the news about taxi drivers assaulting their female passengers (taxi drivers also get assaulted by criminals and scum, but that is another story).

The above issues, plus the fact that my girlfriend is not comfortable taking taxis because she fears one day a driver might be a truly nasty one (yesterday she called me from a taxi as she was worried about the driver), inspired me to the following.

What if a service were available that would make women feel safe taking taxis at all times? I know some cities have “safe taxi” services but these tend to be either not available when you need them (small numbers of taxis in the company), expensive, or both. So I came up with the following:

In its most basic form, it could be a cellphone application in which the woman passenger would enter, at the start of the journey in the taxi, the taxi number, if required the taxi company name (depending on the numbering system in the city concerned) and the destination of the taxi (this would assume the cellphone is GPS enabled and would “snapshot” the start of the journey at the time of entry; if there is no GPS in the cellphone, the starting point would also need to be manually added).

The cellphone application would send the data to the cellular service provider (Vodafone, Orange, etc.). The cellular service provider would have an application that tracks the approximate journey time. At the end of say the journey time +5, an operator calls the cellphone and asks the owner of the cellphone to confirm the journey was OK. Failure to respond would trigger an alert and initially a call to the taxi driver concerned, and if there would be any doubt, an emergency call could be placed. This service could be charged for as a subscription by the cellular service provider, which could distribute the application as a download to its customers.

As an extra security step, the user of system could be asked to use two types of passwords, one meaning “all OK” and the other meaning “distress” irrespective of what the user would otherwise say on the phone (she could be under duress to say the journey went OK, but by providing the “distress” password the operator would know there is a problem).

The system could be taken one step further by requiring taxi drivers to have a transponder in their cabs which would enable the taxi to be tracked via satellite at all times.

This transponder could then also provide the taxi details (taxi company, taxi number, and departure location based on GPS) via bluetooth or similar to the cellphone of the user, if equipped with (a somewhat more advanced version of) the security application described before. The information would be displayed on the cellphone of the user enabling her to verify the details (to ensure the transponder provides the correct taxi number for example). If the transponder were not installed or switched off, the cellphone application could warn the user at the time of entering the taxi.

With this system, the passenger entering the taxi would only have to provide the destination, after which the cellphone company could track the taxi and its passenger (via an automated application that hooks into the GPS and the transponder). The moment the passenger leaves the taxi, the transponder in the taxi would send a “disconnect” to the system (for example triggered by the bluetooth of the passenger going out of range in the approximate destination area), and this would trigger an alert at the cellphone company to call the passenger to confirm safe arrival at destination.

Also, during the trip, as the taxi would be tracked by GPS, a warning could be sent to the system if the taxi strayed considerably from the most reasonable route to the destination.

Finally, the system could be equipped with a combination of alert keys on the cellphone: if, during the journey, something ontoward happened, the user could press a combination of two or three keys simultaneously (this requirement to prevent accidental triggering) which would cause a distress call to be sent out immediately.

The above is something that a software company specialising in mobile software applications could take up. Conceivably, the software could be a modified version of software presently in use with courier companies to track vehicles and parcels.

Cellphone operators would implement the system as it would provide a source of revenue through subscriptions.

Taxi companies could differentiate themselves by implementing the system and marking their vehicles with stickers indicating support for it.

Note: until there is such a system, a woman entering a taxi could text the taxi number, origin, destination and estimated arrival time to a friend. Then subsequently call the friend upon safe arrival at destination. This would at least provide a basic measure of security.

Incidentally, the more advanced version system could be adapted to also protect the safety of taxi drivers, by allowing the driver to key in the destination of the journey and a risk level: for example if the driver based on his/her experience thinks that a particular passenger or load of passengers pose a potential threat, a code could be entered indicating an elevated risk level, which in turn would trigger an alert at the cellphone provider company to monitor this particular journey and call the driver at its completion to ensure all is OK. Additionally, the system with the distress keys outlined above could also be included in this system (possibly using the taxi computer rather than a cellphone).

If you like this idea and you work in a type of industry where this is relevant, I would be happy to discuss in more detail, answer questions or assist in other ways. For details and contact information please see the “About itimes3” page.

George Spark

Disclaimer: Any trademarks mentioned herein are the property of their respective owners.
All usage of this site is entirely at users risk.

The Benefit of Clustered Robots

27 July 2008 at 11:12 | Posted in Innovations, Robotics, Robots | Leave a comment
Tags: , , , , , , ,

[Category: Innovations. If you are new to my blog please read the “About itimes3” page first]

The traditional image of a robot is that of essentially a stand-alone device. The industrial robot, the Roomba at home, the humanoid robot in movies or Japanese tv shows, or the battlefield robot in Iraq all have one thing in common: they are a single entity with a narrowly defined set of purposes (or single purpose).

The reason for this could possibly be the fact that human thinking tends to follow the same time-honoured principles, and does not automatically innovate and stray from those principles.

I believe that what I call “clustered robots” are a better solution in many cases. What I mean by this is a set of robots working together, and in many cases also partly physically integrated.

For example, say I have a humanoid robot at home, which can do basic things around the house. One of these things is opening the fridge and extracting a can of beer. Now traditional thinking (and you see this out there in practice all the time when the subject is robots) will see the robot extract the can of beer, and then walk a relatively long distance to present the beer to its owner. The reason for this is that a human would do it this way, and the robot is modelled after the human.

If we look at the situation with an independent practical eye however, we can see that there are better options.

The humanoid robot opening the fridge and extracting the beer: so far so good (although in a fully robotized home, we will need to “rethink” the fridge and in fact the entire kitchen and home – reinvent the environment for robotics, not adapt robotics to an environment that was made for humans). However – to continue the story – once the beer is extracted from the fridge, there are quicker ways to get it to its destination: how about an indoor helicopter-robot for example?

The unit could be about a foot long and several of them could be perched atop the humanoid robot and be part of its “network”. Once the can of beer is extracted, the helicopter grabs it and flies it to its destination. Faster and more efficient. If there are several people awaiting drinks, several helicopter robots could be launched simultaneously to deliver them. Similarly, other specialist robots could be “clustered” together with the humanoid and its helicopters and be launched as required.

This just as an example. Other types of robots could benefit from similar “cluster” designs. So far, I have seen no true clustered robots although I can imagine that some already exist (I guess you could call a Predator drone equipped with a Hellfire missile a clustered robot in a sense – the Hellfire being a robot in itself).

What I am getting at is that I believe robots would often be able to offer more advanced functionality by being clustered together, with the “cluster” of robots (the robotic entity) functioning as one. Some robots in the cluster would physically stick together (such as the helicopters perched atop the humanoid so they are immediately ready for action), others would “roam” in the vicinity and be available to be summoned into action as required, all depending on their individual functionality. By adding more robots to the cluster, the overall functionality of the robotic entity as a whole can be significantly expanded.

If you like this idea and you work in a type of industry where this is relevant, I would be happy to discuss in more detail, answer questions or assist in other ways. For details and contact information please see the “About itimes3” page.

George Spark

Disclaimer: Any trademarks mentioned herein are the property of their respective owners.
All usage of this site is entirely at users risk.

Next Page »

Create a free website or blog at WordPress.com.
Entries and comments feeds.