Does Facade Design Pattern inherits the concept of Facade from architecture? I mean in architecture the term Facade usually represents the front side or the exterior of any building. Does the Facade Design Pattern also serves this kind of purpose in software architecture? If this is true, is the concept also applicable for "Factory Pattern" vs "Factory", "Bridge Pattern" vs "Bridge", "Proxy Pattern" vs "Proxy" and other design patterns ?
Facade Pattern refers to filtering informations or walling large implementations / complex details.
It serves as putting like a curtain or wall over some complex methods or architecture to allow easier access. That's how the Facade Pattern is presented (see the answer here for "What's the Facade Pattern"). You may also, via Facade, hide some methods or functionalities to your classes.
One of the finest examples is the Repository pattern. You may hide all the database logic (DTOs to Business object) behind some walls, since you may, one day, change databases (like SQL to MySql or Oracle, SQL to EntityFramework). It hides things, like a wall, while showing some things, like windows.
For the rest of your list, it is pretty much applicable.
Factory pattern creates objects from a certain context without exposing the implementation of the instanciation (your class calling the factory doesn't create, the Factory does)Bridge pattern help to link abstraction with implementation without dependency (I want to save to multiple databases, but I want one entry point for all the implementations of differents technologies)Proxy pattern put a mask in front of objects that you may not want to create now.So yeah, pretty much all patterns have a real life application to some extent.