Any model of 'processes' - especially of communications between software components - might be called a ProcessModel.  Some examples include the ActorModel, CommunicatingSequentialProcesses, PiCalculus, and FunctionalReactiveProgramming, and even SharedMemory MultiThreading 
* Note that while most programs can be multi-threaded, MultiThreading cannot be said to be the language's "process model" unless the language ''explicitly'' provides support for it (via syntax, semantics, or a ''standard'' library).  MultiThreading is one of the least 'safe' and most difficult to comprehend or correctly program models of all, and is popular only because it is simple to implement efficiently - a fine example of failing the KISS principle by going from 'simple' to 'simplistic' where you need to start AddingEpicycles.

Merely having an explicit ProcessModel does not imply support for FirstClass processes, but is a precondition for it.  The ProcessModel is required as a basis for mobility, persistence, and runtime construction of new processes.

Not all languages have a ProcessModel, especially those that were largely procedural in design like CeeLanguage or CeePlusPlus, pure functional languages or declarative languages, etc.  However, some languages that do have a ProcessModel include ErlangLanguage (which is based on the ActorModel), VeryHighDefinitionLanguage (FunctionalReactiveProgramming), and various WorkflowLanguage''''''s.