Factory to create Factory?

I refer to GoF Abstract Factory and Factory Method patterns. I understand their purpose but what bugs me is that both patterns omits the discussion of how the client gets an instance of the "factory object". For example, in the following abstract factory pattern, the discussion assumes that some other framework or driver code has already constructed the hierarchy, and that Application instance already holds an instance of GUIFactory (either WinFactory or OSXFactory)

(source: http://ift.tt/1Ckdzyz)

Similar argument goes towards Factory Method pattern. The discussion assumes something else outside has already instantiated MagicMazeGame.

(source:http://ift.tt/1AXaAaa)

Why does it bother me? Because we then need another pattern to construct these object hierarchies and that pattern is the one that many people actually mean when they say Factory. Basically the factory pattern is the following:

(source: Domain Driven Design, Eric Evans 2003)

This is a different pattern from either Abstract Factory or Factory Method, in my opinion. The client specifies requirements and the factory creates objects based on the requirements as well as based on configuration and context. As an hypothetical example, client specifies that it wants an abstract Connection object, the factory creates a MySQLConnection or OracleConnection depending on the database driver configured in the system.

So, my questions are:

• is there a term for the last pattern I described? (I tried researching but the term factory always mean factory patterns in GoF)
• what should the factory that create factories be named? GUIFactoryFactory???
• or am I completely wrong about all this?

I know that this question is just asking about how to name things, but using a Ubiquitous Language (source: Domain Driven Design, Eric Evans 2003. And I completely agree) is also very important in software engineering in my opinion.