I've suspected loyalty points programs are just an accounting trick. You're creating your own currency which doesn't always get used up, and you can devalue whenever you need to make your quarterly numbers.
And if your program really catches on, you can get other retailers to sign on, creating a side business, or spin it off as a separate business if someone is willing to pay you for it (it's easy to segment off from your core business).
In general, store points and so forth are something that stores hope you'll perceive as being of greater value (and hence encourage loyalty) than they'll every have to actually deliver on.
The norm with grocery stores though seems to be more in the vein of giving instant savings to card holders. Some chains (Safeway out West is one of them I think) have so many and such deep special prices that I have a card even though I only shop there on vacation sometimes.
(Interestingly, Shaws--which is an Eastern US chain now owned by European company I believe--discontinued their card in this vein a few years back.)
An island outside Seattle. We don't have any large chain stores on the island. There are 4 grocery stores, all independent, serving a community of about 15k people. There's also only one fast food chain, a Dairy Queen.
The only loyalty card I actually use is the coop feed store, I think the hardware store might have one too, but I've never bothered with that.
I'm confused as to why anyone would invest in Bitcoin companies as opposed to Bitcoins directly. The impression I got was that investing in companies provided added risks (co-founder separation, business failure, legal risks), without providing a significant advantage (risk mitigation, upside multiplication) over just buying Bitcoins directly.
The distinction is subtle, but important. Let's say, for example, that I have no real idea what the price of bitcoin should be in five years -- but I am confident that enthusiasm for, and interest in, bitcoin buying and trading will grow dramatically all the while. I'd rather own the company processing the transactions than the bitcoin itself. The bitcoin might soar, and it might tank, and it might do both of those things in a mostly unpredictable, haphazard fashion. (As has been happening.) But the companies trading bitcoin don't necessarily need to buy and hold. They can make money off of transaction volume, or off of leverage against their bitcoin assets, or off of any number of things only tangentially affected by the nominal value of bitcoin.
This is sort of like the old saying about how to make money in a gold rush. You don't mine for gold; you sell picks and shovels.
There are scenarios in which the Bitcoin "sector" grows without the value of Bitcoins themselves appreciating significantly (or at least, to the same extent). For example it could become a common medium of exchange but an uncommon medium to hold, if a large portion of the growth is in Bitcoin exchange platforms that convert payments immediately to national currencies, like BitPay. In such a situation there could be a large volume of business going through companies like BitPay, but with only transient demand for the coins themselves.
Without the infrastructure to support bitcoins, the value bitcoins will remain stagnate or may even go down. Investing in companies to build out infrastructure for this currency is only "sure" bet you can take unless you gamble on someone else to make the investment.
Bitcoin companies may quickly move to focus on properties of the blockchain that are not related (and, perhaps more importantly, more profitable), than the bitcoin currency.
Also, importantly, bitcoins may be extraordinarily profitable for a bitcoin company, but never increase in value, whereas if you purchased a bitcoin today for $700, and 5 years from now, the bitcoin was still $700, you would likely be unhappy.
The consensus based global ledger of script based transactions. Bitcoin currency is just one application of such a system. Others, such as Contracts, Escrow, Title Assignment have been proposed as well - and the transaction fees of such might be much more profitable than simply identifying a input/output of a bitcoin transaction.
Regardless of the legal enforceability of these rules, I do think Amazon and the FAA need to be certain that a swarm of package-delivering drones don't cause, say, a passenger airplane crash or the failure of an airport's air traffic control system, before we see general deployment of these drones.
I suspect the true difficult technical challenge here will be upgrading the planes and airports to handle hundreds of little drones flying around, with the legal framework to follow.
And then I'll tell him that with just a Mac (which he might already own) and a $100 dollar subscription, he can program and even sell iPad apps worldwide, to a market of half a billion people.
People seem to forget how, in those 80s computers, to get a compiler (besides the built-in BASIC one) you usually paid lots of money. And that a worldwide distribution network for your apps, with automatic payment handling et al was also out of the question. As was an SDK even 10% as complete as Cocoa Touch or the Android one.
An iPad could be a good stepping stone. For me it was Nintendo as a kid that then got me into computer games, which then got me into making my own stuff, which then made me into a programmer today heh.
Google Maps actually already does some of the things listed in the article (such as indicating multiple alternatives between two particular stops) but its ability to do so depends on the quality of the data provided by the local transit agencies.
Yes, sometimes I feel sad I have to read about all this cool stuff that is just "not available in your country" usually because it's a too small market or whatever. In particular transport data (and maps and even streetview) for Dublin, Ireland is very bad, which is weird given that it hosts Google's EU HQ.
Transport data for Google Maps is something you have to (and can) lobby your municipal government for. (I'm assuming your transit authorities are under municipal jurisdiction, like the ones in Canada and the US.)
It took us the better part of the last decade, but virtually every transit operator in the Toronto, Ontario, Canada area is now on Google Maps. Not necessarily with real-time GPS, although the transit authorities in more well-to-do municipalities tend to have it.
But you have to work with your neighbours to make it a priority. Whenever they ask for comments (hopefully your municipality is modern enough to ask for this through online forms) then fill it out and ask for them to provide Google Maps data.
(On the other hand, local lawsuits also had a part in it -- a disabled (blind or deaf, I forget which) person sued a local transit authority saying that not having the stops announced was preventing him from using public transit and won. So every transit authority had to have drivers read out every stop until they could install computers with GPS and LCD displays and text-to-speech to read out all the stops. Once the buses and trains all had GPS and computers on-board, adding real-time tracking was just a matter of installing a GSM modem on each vehicle.)
Considering how expensive point-of-sale systems are, I'm not surprised that these systems are running old, vulnerable software. Heck, there are still ATMs running OS/2 Warp in the United States; the only reason people don't hack those is because it's so obscure.
My father still uses a small pre-computer cash register to this day; I've had no luck convincing him to buy a new computerized one so he can accept credit cards.
> I've had no luck convincing him to buy a new computerized one so he can accept credit cards
You can still accept credit cards without a new register. It's just a different machine. They don't have to be integrated.
Almost every single doctor's office accepts credit card and exactly NONE of them have a register.
The way it works is you charge the card on a separate machine, type in the total, have them sign and put the slip somewhere and press "paid with credit" on the register if it is computerized or if it isn't then just ignore the register for that transaction.
In europe typical deployment solves this problem (EMV is quite orthogonal to this) by the fact that card data does not touch the PoS system itself. In fact any other approach is not feasible as PoS systems themselves are invariably horrible mess of accumulated kludges and backward compatibility restrictions. And there are quite powerful economic incentives to keep this state of things. Security-wise this is one of the few situations where semi-air-gapped network makes sense (for the PoS part, with card terminals having their separate network).