Firstly, 256 bits is 32 bytes, which is less than 117 bytes, so that fits and there is no need for any kind of splitting.
It could be argued that it is useless to have a 256-bit key for symmetric encryption if it is protected with a 1024-bit RSA key, because, due to its mathematical structure (the structure which enables the public/private key magic), the RSA key is of much lower robustness against attacks, down to the relatively low strength of "about" 80 bits (that's still out of reach of what can be done right now, but at least a machine which breaks 1024-bit RSA key can be designed and its price computed, contrary to a brute force search on a 256-bit symmetric key space, which is way beyond Science and even science-fiction).
The kind of splitting you are asking for would not be trivial to do securely. This would require some careful analysis. No such analysis has been performed yet, to my knowledge, because there is no practical situation which calls for it.
But, most importantly, thou shallt not reinvent the wheel. Establishing a secure communication between a client and a server, with a key exchange and then symmetric encryption, is very tricky to do correctly. There is a standard solution called SSL (well, now it is called TLS, but that's the same). This protocol has been broken and repaired and analysed and optimized for almost two decades, and now it seems safe enough. It is highly doubtful that you (or, for that matter, any human being) could produce something as good (or at least "not worse") by yourself, in substantially less time. There are zillions of design and implementation details which can go wrong. So do the smart thing, use SSL; even smarter, use an existing implementation of SSL instead of writing your own. It will save you a lot of worries, time and money.