I would argue this along the following lines:
- Why exactly does your method return multiple values? What kind of cohesion are we talking about - should those values actually be fields on a single class, or are they just coincidentally returned by the same method, but otherwise unrelated? If it's the latter, you might want to consider splitting the method into two methods, rather. Edit: use your judgement here; sometimes a type of "coincidental" cohesion may be the best option. Another option is to use a pair or tuple construct, although in OOP, these are usually not seen in public APIs (some notable exceptions being standard collections, etc).
- If the values do deserve to form a class, I would probably advise against using an inner class. Inner classes are typically used as internal implementation details, which are hidden from the outside. Is there any reason why this result shouldn't be a "full-blown" class, in its own right?
- Other than holding data, what operations are applicable to this new class? In object oriented design, you want to have the related behaviour close to the relevant data (which seem to be your intentions, too). Should the method you are referring to not live on this class rather?
To summarise, I would see if I can turn this "data object" into a fledged-out class with both data and behaviour. As an additional comment, you may want to make the class immutable, since its state is set once. Making it immutable will help prevent it being incorrectly set, or modified later (say, someone setting one of the fields to null and passing it along).
Edit: As Patkos Csaba correctly points out, the principle being applied here is the Single Responsibility Principle (SRP) - the class you are trying to create should really have one responsibility (defined as a reason for changing). This design guideline should help you figure out whether your two fields belong in a single class, or not. To stick with the Wikipedia example, your class could be a seen as a type of report, in which case it's conforming to SRP, but it's difficult to comment without further information.