The usual approach is to offer methods on the service which do what you want, instead of on the client creating predicates that are 1:1 bypassed to the service and executed as-is.
So instead of e.g. service.GetCustomer(IPredicate predicate) you do service.GetCustomer(string country) and build the predicate in that method using the country specified.
It's easier to limit the service's API this way to what you want to expose.
Another way is to use the XML pipeline.
You can serialize the predicate to XML using predicate.WriteXml(xmlwriter). It will write the xml string to the writer specified. You can deserialize the predicate's contents then again by using predicate.ReadXml(string)
To do that easily, use the XmlHelper class that's part of the ORMSupportClasses:
var xml = XmlHelper.SerializeObjectToXmlString(toSerialize, serializationFunc);
where 'serializationFunc' is e.g. (a, b)=>a.WriteXml(b)
a is a predicate, b is an XmlWriter.
To get the object back, use:
var toSerializeDeserialized = XmlHelper.DeserializeObjectFromXmlString<FieldLikePredicate>(deSerializationFunc, xml);
where deSerializationFunc is (a, b) => ((IPredicate)a).ReadXml(b)
You can then pass the string to the service if you want or store in a DB.
Be aware that this doesn't version. Storing serialized data in a Database to be used later sounds great, but it might be the types change in the future and the data can't be deserialized to the object. With predicates and the like I don't expect that to happen tho, but it's a thing to take into account, also with e.g. keeping serialized entities in a database (some people do that... )