The receiver is a simple OOK receiver. Do you already have a companion transmitter? I once took apart a similar device that was part of a IR proximity alarm. It would sense a warm body, and send out a 24 bit stream of data which included it's address, and the alarm state. I reverse engineered a receiver for it that looked at the incoming noise for a particular pattern of data. For instance, let's say that the transmitter put out four short bursts and four long bursts to indicate it was in an alarm state. The receiver looked for a burst of the proper length. If it got it, it looked for the next, then the next, until all matched up in the right order, and each individual pulse was the right length. If for some reason, the pulse length or position was wrong, it fell through to the beginning. If all was right, and I got three correct sequences in a row, I had an alarm state, and the microprocessor put out the proper response.
With the receiver you have, the data slicer is going to be constantly transitioning from 0 to 1 and back again due to random noise. You need to be able to differentiate the signal from the noise. Most OOK systems that transmit data, will start with a preamble that will set the data slicer to the midpoint. Following this is a character that tells the receiver to listen up, then it's followed by the data, and a checksum so the receiver has some form of error detection. In your case, three characters repeated over and over will be enough to signal to the receiver what is going on, as long as they are relatively balanced between ones and zeros. Manchester encoding takes care of this for you, but it raises the level of complication above what you need.
I have used the Micrel receivers in the past for this, and have found them much easier and cheaper to use than the Philips parts.

Ron