Q:

Is there really a "USB communication protocol"?

According to Wikipedia, USB:

defines the cables, connectors and communications protocols used in a bus for connection, communication, and power supply between computers and electronic devices

But is there really a "USB communication protocol"? My understanding is that:

You connect a USB device to a machine (say, Ubuntu or any kind of Linux)
Linux finds the device driver for that device (somehow - bonus if you know!) and loads it
The device is now connected under /dev/theDevice
User space apps can now read/write to /dev/theDevice and the driver handles the low-level IO to the underlying device/hardware

To me, nowhere in this flow does a "USB communication protocol" appear. If my understanding is correct, the USB is just the cable and electrical connection between the PC and the device.
Am I wrong here? Does USB actually implement some kind of low-level protocol the underscores the flow above? If so, what is it and how does it work at a 30,000 foot view?

A:

Yes, see USB protocols
As I understand it, the USB spec defines a complex set of layered protocols and device profiles. 
For example, USB devices can conform to high-level templates like mass-storage, keyboard (or Human Interface Device, etc) and be managed by a generic device driver. Some USB devices can communicate at a lower level such that the OS low level USB support can recognise that device-specific higher level drivers are needed.

A:

Question: Is there a low-level USB communication protocol in action and what is it?
Answer:
Yes there is, the USB specification includes the USB protocol which defines the way the bus is used on a bit level. This would be the 'low-level' protocol that underlies the higher level protocols i.e. mass-storage, HID, etc.
For specifics on how the USB protocol works, this OSDev wiki is helpful. Here is another interesting description using sequence diagrams to describe the various data transactions per the USB protocol.
Bonus Question: How does Linux find and load the device driver for that device?
Bonus answer:
'On Linux when using a USB-enabled kernel, a working USB device will be detected via the hardware and kernel due to the USB specification. On the hardware side the detection is done by the USB Host Controller. Then in the kernel the Host Controller Driver takes over and translates the low-level bits on the wire to USB protocol formatted information. This information then gets populated in the USB core driver in the kernel.'
I paraphrased from this excellent Opensourceforu article, which has much more detail and clarity about your question in the Linux context.

A:

Like nearly every other type of communication interface, USB is implemented as a protocol stack. The levels within this stack that are common to all or multiple types of devices are defined by the USB standards themselves, which both enables compatibility and prevents each device from doing redundant protocol design. Furthermore, each layer of the protocol abstracts away details that the next layer up doesn't need to worry about. So, when you're actually writing the device-specific layer, you just have generic 'send' and 'receive' functions that get data from endpoint A to endpoint B. You, as the device designer, don't have to care about how that happens. Furthermore, lower levels within the protocol stack can change implementation as long as they expose a common interface to the layer above them. This way, when one part of the protocol stack changes, the rest of the stack doesn't necessarily have to change. Ideally, protocols at higher levels of the stack don't even have to care exactly which protocol is being used at some lower level of the stack. Generally speaking, each consecutive layer down the stack will encapsulate the message produced by the next-highest layer within its own payload field as a message is being sent. When a message is received, each layer peels off the part relevant to that layer and forwards its payload to the next appropriate layer up the stack. This is true of, not just USB, but almost every communication bus. The TCP/IP/Ethernet stack is probably the most commonly used of these, for instance. The tasks that given layers are commonly responsible for are described in models, such as the OSI model.
In USB, there's a physical layer protocol that defines voltage states/timing/etc. on the wire and how they should be interpreted. This protocol obviously needs to be part of the USB standards themselves, not specific to a given device (especially since the host has no way of knowing what kind of device is about to be plugged into a given USB port.)
Next, there's a bus management protocol, used for describing who can talk on the bus when. This is called the media access layer in the OSI model. In USB this layer can pretty much be summed up as "the device can transmit when the host tells it to do so," so there's not a particularly complicated protocol at this layer in USB.
Next up, there's a standard protocol for describing a packet of data and how it should be routed from the sender to the receiver. This layer also needs to be part of the USB standard itself, so that initial communication to discover what type of device has been attached can happen before the specific type of device is actually known by the host. In addition to each device having a particular ID at this layer, there is also the concept in USB of an endpoint ID. This allows any given device to have multiple USB endpoints, which are multiplexed and demultiplexed by the standard USB stack, much in the same way that sockets are multiplexed and demultiplexed by the standard TCP/IP stack. An application can treat each of these endpoints as separate data streams.
Finally, there's the protocol defined for the device itself. Note that there actually are some common pre-designed ones included as part of the USB standard for common use cases, such as mass storage devices, mice, keyboards, etc., so that every device manufacturer doesn't have to re-invent the wheel. However, more complicated devices are free to design their own custom protocol at this layer. The output of this layer for a given transmission is passed as the payload of a data packet at the previous layer. Note that, for sufficiently complicated devices, the device-specific portion of the protocol may itself be divided into multiple independent layers, but the lower levels don't have to know or care about that. All they need to know is that they need to pass a given set of bytes from the host to a particular device endpoint or from a particular device endpoint to the host. Again, having the standard interface between layers allows separation of concerns, so one layer doesn't have to care about the inner workings of another layer, but only the specific data that it should pass to or expect to receive from the layers immediately above or below it in the stack.

