I've implemented RSA encryption algorithm to encrypt the symmetric key used in data encryption, but the key size and the ciphertext size of RSA created a memory issue, so I searched other methods of public key cryptography for the solution. I found elliptic curve integrated encryption scheme (ECIES) and understand the theory behind it, however, I am a bit unclear that how this method be used as public/asymmetric encryption algorithm. The method computes the symmetric encryption with the key derived from the shared secret for both encryption and decryption (using the same key).
So how could it be taken as an asymmetric encryption algorithm? Or Is there any method to implement it as asymmetric encryption?
Meta: this isn't really a programming or development question or problem. It probably belongs on crypto.SX; you might ask for migration.
To be exact, ECIES is a hybrid public-key encryption scheme, but so are most others. For example RSA is commonly used, just as you said, to encrypt a working (per-message) symmetric key, not to directly encrypt data.
Paraphrasing the wikipedia description:
2-5. Alice generates an ephemeral keypair, derives the shared DEK, and encrypts the data, and sends it with her ephemeral publickey (edit) and destroys the ephemeral privatekey
ADDED, and expanded below, per comments: Yes the DEK is the same at both ends (notice I used 'the' meaning one and not several) and that's why this scheme works; and the part of ECIES that uses DEK for data encryption and decryption is symmetric, but all the other operations (which securely create the ephemeral shared DEK) are not.
It is vital no one besides Alice (or Bob) learns her ephemeral privatekey; if they do they can decrypt. But she doesn't need to explicitly keep it secret because she destroys it immediately after using it to send a message; that's what ephemeral means.
Let's see:
the recipient's publickey is public and anyone can encrypt
the recipient has the (static) privatekey and can decrypt
nobody else has Bob's (static) privatekey or Alice's ephemeral privatekey, and nobody else can decrypt
the recipient needs only one keypair; if there are multiple senders they can all use the same publickey but can't decrypt each other's traffic, and don't need to get the publickey secretly; for a thousand or a million senders this costs the same as or very little more than one sender
Consider the properties of a standard/traditional symmetric scheme instead:
the two parties must have a key (only one, not a pair) shared in advance; both must keep it secret and not share with anybody else
this typically requires the parties meet in advance, or use a physically secure means such as a courier to carry the key from one to the other or perhaps from a central authority to both
each key can only be used by one pair of parties; for multiple senders, Bob must have and manage that many different keys, and each sender (Alice, Abby, Anne, etc) must have a different key. Each sender must separately meet Bob, or they must each have a separate courier (or two), before they communicate with him. For a thousand or a million senders this becomes immensely costly
ECIES has none of these properties of a conventional or symmetric system, and all of the properties of a publickey or asymmetric system above, although it does also use some symmetric operations along with its asymmetric operations.
And that's why it sounds like (hybrid) public-key encryption to me!