I think you'd have to write a replacement driver which would allow for that. I was about to say that it depends what the USB is, but in any case, whether it be straight USB communications like an STM32, or USB serial like FT232, or USB access to a drive or thumbstick, the kernel has it's own drivers in place which are designed to be the interface to whatever the subservient USB device is, and all that I can think of will likely restrict to some singular point of access. I'm no expert on say the file system, but if you have a USB drive, several processes can probably have open file handles on a USB attached drive; however those processes' access points are really through the Linux file system driver.
As far as serial goes, you're not restricted totally, you can open a serial USB and I believe if you fork() another process, that new child also has the same handle. It's not advisable because you both can try to access the device, not knowing the sequence of data that's there, you can end up putting partial packets of data and interleaving them, because the two processes may not know about what each are doing. I've made that programming mistake.
What you can do is have one side be a receiver and one side be a transmitter, which is necessary sometimes in order to not lose data on the receiver when you're doing too much on the transmit side.
These could be a bunch of incorrect guesses. What USB technology do you wish to be able to access by more than one process? Why do you feel that you need to do this? And by multiple processes, do you mean processes/threads in the same programming architecture? Or do you mean entirely separate processes from different programs?