Yes, this could be done, but what would the point be? It wouldn't verify anything about the document. A signature (slightly simplified) is just an encryption of a secure hash of a document using one of the keys in the pair. The private key is used to prove that only the private key holder could sign it. In the case of signing with the public key, anyone could alter the document and sign it, so it doesn't prove anything. Not only that, the only person who would be able to verify the "signature" would be the holder of the private key, so there is absolutely no use to it.
Reading the paper, I can't see how they expect the process to work and it appears to be using the term signature in error. What they are likely describing is protecting the session ID as a secure token by use of encrypting with the public key and then decrypting on the server with the private key. The use of the term signature is incorrect and would not provide the necessary security in their use case. The paper isn't very well written and has some other poorly worded sections. I wonder if it may be a poorly translated paper where English wasn't the original language since I see one author is from Taiwan. Though the US co-authors should have proofread it so I wouldn't trust the paper too much.
Update: On further reading I now understand what they are saying in the paper. It is a very poorly worded summary. They are using a system where both the merchant and the purchaser have a key pair. The merchant provides a signed invoice which the client can verify is from the merchant. They then sign their purchase order which includes the invoice which they are ordering. The merchant then verifies that the client signed the purchase request and verifies that their invoice was unaltered. It's rather a bit more convoluted than it seems to need to be, but it is accurate when you take the appropriate instances of public and private keys.
