The instruction is loading a new EIP value from memory at ds:[40207A]. i.e. there's a function pointer at address 40207A. (And it pushes a return address because this is a call not just a jmp.)
The ds: means the instruction is referencing memory in the Data Segment - and can pretty much be ignored on modern OSes, since they run with a flat address space model (code, data and stack segments all refer to the same memory range, and memory protection is handled with paging).
The ds: is there to show you it's definitely a memory operand, and to remind you which segment it uses / show that there were no segment override prefixes (except maybe a ds prefix because that's already the default).
EDIT:
A little elaboration - note that, to keep things simple, this is in the context of 32bit protected mode running Windows.
A segment register (CS,DS,SS,ES,FS,GS) holds a selector pointing to a descriptor. There's two descriptor tables: global (GDT) and local (LDT), and the selector has a bit indicating which to use. Windows (almost?) exclusively uses the global table.
A descriptor is basically a {beginning-address, size} pair - there's more to it, but that's outside the scope of this post.
Windows uses a Flat Memory Model: each process has a 4GB address space starting at memory address 0, and uses paging to isolate processes from eachother.
Since processes have this flat view of the world, they run with all segments using {0, 4GB} descriptors - and thus, instead of allocating per-process descriptors, Windows can use only a few global descriptors and have all processes use those.
EDIT 2:
The Portable Executable format defines sections, which are unrelated to the x86 segments - even if there's some conceptual overlap. The PE EXEs can have pretty much any section layout you wish, but the normal is to split into (at least) code (read/execute), data (read/write), resources (readonly?). Splitting the executable into sections makes it possible to apply x86 page-level memory protection to the memory ranges.
EDIT 3:
While the normal segments don't change per-process, Windows uses the FS register to point to the per-thread TIB structure.
EDIT 4:
See this for an overview. This is from an old document on the 80386, but the information still applies.
