This is slightly incorrect in a meaningful way: prototypal inheritance works through delegation, not cloning.

Instead of cloning the prototype object, it is attached (as a reference) to the newly created object as the value of a hidden property (usually denoted with the double-bracket notation: "[[prototype]]"). When a property is requested on an object and that property doesn't exist directly on the object then the request is passed up to its prototype (recursively, so a prototype can have it's own prototype, etc, leading to a "prototype chain").

It's an important distinction because the behavior is different. In your ATV example below, if you assign a new value to `atv.make`, for instance, that change will also be visible on secondATV. That would not be the case if the prototype was cloned, acting more like a template than a delegate.

Note that the reverse is not true: if you assign a different value to `secondATV.make`, it attaches that property directly to the secondATV object, eclipsing the property of the same name on the prototype and now the two ATV objects have different values for that property.

Your article gives a nice high level look at prototypal inheritance, but I'm wary of calling it a design pattern because it's built into the runtime and not something you can actually opt in or out of; even if you don't specify a prototype or use `Object.create`, even if you use the `class` keyword, you still have a prototype.