It's one of scope. In RUP business use cases often explore the fundamental business activities which the system may address. System use cases, called use cases in RUP, describe the detailed manner in which the system will implement the functionality. System use cases reflect architectural decisions, such as using J2EE instead of Fat Java instead of a manual solution.
One source we used at work (sorry I can't remember it) talked about business processes, the things the company does regardless of electronic systems. For example my company issues new insurance policies (among a million other things) and you can describe the new issue process without mentioning computers ... send credit check request, get results, schedule a physical, get results, evaluate hobbies and occupation for risk, compute a premium amount, write up the policy, deliver it, get signatures, etc. I was thinking "business use case" might be a name for all that, but we're not USING anything so maybe not. It's a valuable step, however, and helps you tell the difference between requirements and premature design decisions when you talk to customers.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi