M2M (machine to machine) is defined well by Numerx as:
M2M communications employs a device (e.g., sensor, meter, etc.) to capture an "event" (e.g., temperature, inventory level, location, environment status, etc.), which is relayed through a network (e.g., wireless, wired or hybrid) to an application (software program), translating the captured event into usable information (e.g., there is a breach, corrosion requires attention, items need to be restocked, an accident has occurred, etc.)
Familiar companies such as Sprint, AT&T, Verizon, IBM; and other lesser known companies such as Numerx and Axeda push M2M. By at least one prediction, trillions of machines are just waiting to join the M2M party.
Even Google seems to be getting into M2M. This article has a section titled Will Google Flush M2M Down the Crapper?. This section of the article below mentions some things which might bring to mind statements you have heard when people talk about XBRL:
"It's going to raise the awareness of M2M. When executives in the board room say 'I see Google connected a smartphone to a dishwasher, why can't we connect to our equipment or our products?' it's going to raise the visibility of what you can do.
"What Google is going to find out is that connecting is pretty hard, a lot of devices aren't serving data that's usable. There is a need for a layer that turns the raw available data into usable data like temperatures, etc. into a data model that programmers can use.
"That's our secret sauce, our unique value proposition: our technology converts raw data into business data.
"It comes in obscure message format packets, with headers etc. we've got a whole set of parsers and translators that turn that into an asset, temperature. We have a rules engine that allows you to create notifications, web services layer available by REST, can do mashups with HTML or javascript."
So what does connecting a smartphone to a dishwasher or having SIRI start your car have to do with XBRL? In a word: lots.
Millions and millions, if not billions, of business reports are shared within and among businesses and governments. Those business reports are packets of information. Maybe they are a little more complex than M2M communications, but basically it is the same idea.
XBRL is part of what will enable business-to-business, business-to-government, and government-to-government digital business information exchange.
Most of the traction XBRL has been able to create thus far is business-to-government information exchange such as banks reporting to a regulator such as the FDIC or one of the 27 CEBS supervisors, public companies reporting to the SEC or a stock exchange, corporate tax reporting to HMRC or National Tax Agency of Japan, or Standard Business Reporting (SBR) type projects in the Netherlands and Australia. Those are only some examples.
But what about some of these use cases:
I could go on and on, there are plenty of these types of use cases if one really looks.
Imagine an inexpensive, easy to use, robust, reliable, error-free, scalable, secure, auditable, understandable (from a business semantics perspective); basically truly automated business-to-business, business-to-government, or government-to-government. What processes could you make better, faster, or cheaper in some way?
These processes could be within your organization or there your internal processes intersect with one of your business partners.