EDIT: In a comment to another answer the OP wrote:
I've gone back and forth between a single-class design and a two-class design as the one shown in my question. I'm back on the two-class approach b/c something needs to contain the run-time configurable resource object prior to the Person object being created.
This scenario clarify that the design-patter should be the Proxy (a.k.a. Surrogate). The original description from the GOF says:
...one reason for controlling access to an object is to defer the full cost of its creation and initialization until we actually need to use it... the solution is to use another object, an image proxy, that acts as a stand-in for the real image.
Following is the original answer (still valid in many ways, this is why I am leaving it)
Thinking to architectural patterns, and more specifically to the Model-View-Controller:
PersonController, as it looks like the Person class will hold data (and you might have a View displaying the data in some way.
Thinking to design patterns, the name would really derive from the use you make of the class.
It could be an Adapter because it converts the native interface of an object to a different one, or could be a Flyweight if you use it for all persons adding a lot of heavy methods and data to it and keeping the underlaying
Person as light as possible or still a Proxy if you would implement some sort of logic in how and if users could access the underlying instance of
I can only speak for myself, but I often find myself to blend different design patterns together, according to the specificities of the software I am coding.