if you've got llGetOwner as the key, you don't ALSO need the owner's name in name. The only reason you'd want to pair them, or hardcode the name, is if you ONLY EVER wanted it to work FOR YOU, while YOU owned it. Doing it the way you did above, would break it if you tried to sell it or give a copy to a friend.
llListen(channel, name, key, filter)
...channel - integer number to listen on
... name - specific name of avatar or object to listen to. (ignores all others)
...key - specific UUID of avatar or object to listen to. (ignores all others)
...filter - specific message to listen for. (ignores everything that doesn't match)
Compare this to the event.
listen(channel, name, key, message)
...channel - channel message was heard on
...name - name of avatar or object that was heard.
...key - UUID of avatar or object that was heard.
...filter - message that was heard.
the listen event, will NEVER hear something that the script is not "listening for".. here's what different listen configurations do.
llListen(5, "", NULL_KEY, ""

;
Fully open listen on channel 5. ANYTHING said on 5, by anyone or anything, will trigger the listen event.
llListen(5, "Object", NULL_KEY, ""

;
Listen is open on channel 5, for anything with the name "Object". the name filter is handy if you know the name of an object that's going to be talking, but don't know it's key. Same with filtering some sort of "conversation recorder"... you don't need to know the people's keys, just their names. This doesn't support a wildcard, so a listen for "Winter" would not hear me. Note that while this is a handy filter style, it's not very secure. the script will hear ANYTHING said by ANY OBJECT with that name, on channel 5.
llListen(5, "", llGetOwner(), ""

;
Thie listen is open on channel 5, for the person who owns the scripted device. it will *NOT* hear a hud.... even if the hud is owned by the same owner
llListen(5, "", llGetCreator(), ""

;
Something of a backdoor... this allows you to open a persisting listen on channel 5, for the creator of the object housing the script. Of course, scripts can be moved to other prims..
llListen(5, "", llGetInventoryCreator(llGetScriptName()), ""

;
This is a better backdoor... opens a listen for the creator of the script. Of course, moddable scripts can be copy-pasted into new scripts.. at this point however...
llListen(5, "", "145b5e86-fcb2-4351-877a-0dfe65e80518", ""

;
That's my key there.. This is an open listen that will ONLY listen to me, on channel 5 of course. Not my HUD's.. just me. Again, not really secure as a backdoor in a moddable script (for the obvious reason that it can be modded) but it seems like it might be slightly more efficient than the previous example. Also useful if you want to open backdoors for several avatars.
llListen(5, "", NULL_KEY, "activate"

;
Now here's an interesting use for the word filter. On channel 5.. it's ONLY listening for the word "activate". Now, my understanding is a little fuzzy here.. I'm not sure which of these will trigger it.
This will for sure: /5activate
Pretty sure this will too: /5 activate
I don't think this will: /5 activate me
That's the nasty bit about the filter. it's not all THAT handy.
However, you could open a listen JUST for a specific word.. maybe from a specific avatar name... I'm thinking of the SLX registration process... Where you tell them what your inworld name is, and then they tell you to got to an atm and say a magic word. That listen might look something like this:
llListen(0, "Winter Ventura", NULL_KEY, "register"

;
With this listen, the ONLY thing it's listening for, is for SOMEONE, an avatar or object, with the name "Winter Ventura" to say the word "register" in open chat. Then the listen will probably store the UUID of the person who said that magic word.. and do whatever it does from there.
There's a LOT more to learn about listens, handles, listenremoves, compounding and layering listens.. but the specific fix for your problem, is in my earlier post.