There are several reasons why this is a really bad idea.

First, services shouldn't interact with user sessions at all. This is a
security risk and poor design to boot, since services should run correctly
even when nobody is logged on.

Second, the clipboard should only be filled with data in response to a user
action. The clipboard is *not* a general mechanism for applications to
communicate, it's a way for users to transfer information of their own
choosing between applications. If you're not an interactive application, you
have no business accessing the clipboard.

The clipboard is associated with a window station. Services run in a
separate, noninteractive window station. The clipboard *does* contain your
data, but the user (who is logged on in another window station) does not
(and cannot) access that clipboard.

What you want to do can probably be done better. First of all, there is no
need to use a Windows service to read from a serial port -- a regular
application can do that just fine. It may need elevated privileges to run,
but these can be asked for. You could make your application invisible
(displaying no forms) and have it start at user logon if it is desirable
that the user doesn't need to start and stop it explicitly.

Second, your application should not pump data to the clipboard without being
asked to. A much cleaner way of achieving the same effect is to give the
application an interface with the data in a textbox, so the user can copy
the data themselves. You could supply a "copy to clipboard" button to
quickly copy all data gathered so far.

Finally, if it's necessary that the application supply the data without
being asked for, using the clipboard is still not a good idea. You could
have the application write to a file, which people or applications can read
at their leasure, or you could communicate the data through remoting
(consult the MSDN for more information on that).