I just don't get anything related to it.
How does that exactly work?

Is calc-to-calc( you know, getCalc stuff) serial transfer?

I am completely oblivious to all terms in all facts of life (you would be surprised at how I do in my honors geometry class when I call shapes such as trapezoids 'parallel median base quadrilaterals' and isosceles triangles 'bicongruent triple angular entities') but I can somewhat explain how calc to calc transfer works in a way.

Calc to calc is actually a pretty simple process -- as far as I know, a cable sends pure, raw data in 8 bit form across the wire.  The thing is, this can prove to create bad transfers, because if the two calcs are not synced up at the same frequency (again, IDK the term) then you might only transfer half the data correctly.  But, depending on how you detect byte sending, you might make the calculator wait until it receives a non zero (or sometimes a non -1) from the opposite end.  And, when it does receive it, it might send back a value such as 1 to the output machine to say 'I got it already!' and then output machine will then proceed to the next 8 bit value until it's all done.

USB, however, I believe that is a whole different story.  I don't plan on explaining it or even learning about it, I've heard it's extremely complex.

Ashbad, for comparison, learning USB protocols without using a pre-made library is like recreating OpenGL in machine code without system calls. Advanced networking protocols are probably the most difficult [normal] form of programming.

As for Serial, Runer is right. It's one bit at a time, over frames of a certain number of bits (8, I think). However, there are networking protocols involved in serial transfer too. It's not just "send bits whenever you feel like it," though that's certainly possible to do.

The above is what I have been lead to believe in my limited studies of serial networking. If anyone else is more knowledgeable, take their advice.