METHOD AND SYSTEM FOR GENERATING AND TRANSMITING ELECTRONIC LABELS FOR SENDING RETURN
FIELD OF THE INVENTION
The present invention is a method and system that uses a networked computer environment, such as the internet, to generate and send a return shipping label to a customer.
BACKGROUND OF THE INVENTION
A typical return transaction involves a customer contacting a merchant, via email or phone, to inform the merchant about the item the customer wants to return. After approving the return, the merchant obtains a return shipping label from a shipping courier and mails the return shipping label to the customer, along with any special instructions on how to pack the item being returned. The customer then prepares the package, sets the return shipping label to the package and sends the package to the merchant. The typical return procedure results in several delays. Figure 1 illustrates some of them and, in particular, shows that in general it takes a trader between three and six days to obtain a label of
l AitiiJÁ-'1 ** - * - * - * l f return shipment and send it to the customer. In addition, the procedure described above is labor intensive by staff in that it requires a trader to have employees available to receive the return request, approve the return request, and obtain and send a
5 Return shipping label to the customer. Accordingly, there is an unmet need for an improved method and system for handling product returns that overcome deficiencies in the prior art, some of which are explained above. BRIEF DESCRIPTION OF THE INVENTION
The present invention comprises systems and methods for generating and providing an electronic return shipping label to a customer
15 allow the client to return goods to a merchant or seller. In accordance with one embodiment of the present invention, a method is described for a merchant to provide an electronic shipping label to a customer to allow the customer to return goods. According to one aspect of the present invention, the customer receives a
20 return request, you get shipping information related to the return request and generates a return shipping label that can be printed and set to a package for the return of the goods. In a modality that is described, the client sends the return request to
^^^ á & amp through a site in the merchant's network. According to another modality, the client sends the return request by contacting a representative of the merchant and the representative sends the return request through the merchant's website. According to another aspect of the invention, the shipping information related to the return request includes a customer address and information related to the size and weight of the goods being returned. Another aspect of the invention has at least a portion of the shipping information obtained from a customer order database. According to another aspect of the present invention, a portion of the shipping information is obtained from a product database. In one embodiment of the present invention, the return shipping label is formatted as an HTML document and the shipping label is provided to the customer by providing the customer with a URL corresponding to the return shipping label. In another modality, the client is provided with a file that contains an electronic image of the return shipping label. In another form, a return shipping label is sent to a courier with instructions to collect the goods from the customer's address. According to another embodiment of the present invention, a method is described for providing an electronic return shipping label to a customer to allow the customer to return goods. The method described comprises the steps of receiving a return request
For the goods from the customer, obtain shipping information related to the return request, transmit the shipping information to an application service provider, the application service provider configured to process the shipping information and generate a return shipping label, generating the return shipping label and providing the customer with access to the return shipping label. According to yet another embodiment of the present invention, a system is described for a merchant to electronically provide a return shipping label to a customer who wishes to return an asset and who comprises a merchant server, who hosts a network site of the merchant. merchant and that is capable of communicating with an application service provider and at least one client computer, an application service provider computer in communication with the merchant server, an application service provider application, residing in the application service provider server that is configured to generate a return shipping label based at least in part on the shipping information received from the merchant server, and a customer computer to receive a return shipping label.
»- ^ * - • - if t f BRIEF DESCRIPTION OF THE DRAWINGS
Having thus described the invention in general terms, reference will be made to the appended drawings, which are not necessarily drawn to scale, and in which: Figure 1 is a high-level block diagram illustrating a process typical return that is used in the prior art. Figure 2 is a high-level block diagram of an electronic return system according to an embodiment of the present invention. Figure 3 is a high level block diagram illustrating the operation of an electronic return system according to an embodiment of the present invention. Figures 4A-4F show the type of network pages that a merchant could use according to an embodiment of the present invention to allow a customer to send an electronic return request. Figure 5 illustrates a typical electronic return shipping label that is generated and sent to a customer in accordance with an embodiment of the present invention. Figure 6 illustrates a network page including a return shipping label and other text related to the return according to one embodiment of the present invention.
i. ". d¿, i ¿¿i.t ..É-f? Fig. 7 illustrates a network page that lists messaging delivery locations according to one embodiment of the present invention. Figure 8 illustrates a network page of a map detailing the location of a particular messaging delivery location.
DETAILED DESCRIPTION OF THE INVENTION
The present invention will be described more fully below with reference to the appended drawings, in which preferred embodiments of the invention are shown. However, this invention can be made in many different forms and should not be considered as limited to the modalities set forth herein; rather, these modalities are provided so that this description is thorough and complete, and will bring the scope of the invention to those skilled in the art. Similar numbers refer to similar elements through it. Many modifications and other embodiments of the invention will occur to one skilled in the art to which this invention pertains having the benefit of the teachings which are presented in the descriptions mentioned above and in the associated drawings. Accordingly, it should be understood that the invention is not limited to the specific embodiments that are described and that the modifications and other embodiments are designed to be included within the scope of the appended claims. Although specific terms are used in this, are used in a generic and descriptive sense only and not for purposes of tation. The following paragraphs describe the present invention within an Internet environment. This is only for illustration purposes. It will be readily apparent to the person skilled in the art that the present invention can be applied in any network environment. Figure 2 is a high-level block diagram of an electronic merchant return system 10 for practicing various aspects of the present invention. The present invention includes a merchant server 110 in communication with the computer network 100 and a network site 120 associated with the merchant server 110. The merchant server 110 generates and stores information that can be accessed by other computers. in a computer network 100. In a preferred embodiment, the information is stored as network pages and accessed through the World Wide Web using network searchers that are well known in the art. The present invention also includes a messaging server 130 in communication with a computer network 100 and the merchant server 110. Figure 2 shows a messaging server 130 operated by United Parcel Service (UPS). The present invention however is not ted to UPS servers and the messaging server 130 may be
.. .. - -. jaJtau. - ..... ... j ... ^ _ ^ »u. taaréáiO? jm? LiiaMt? MjJtíb? IuBMeMLA? - ^^ Hfll jiütet ll owned or operated by another courier or by any other entity. For this reason, the messaging server 130 is sometimes referred to generically herein as an application service provider (ASP). The messaging server 130 includes an ASP 140 application (the operation of which is described below) which, in accordance with the present invention, processes the sent information received from the merchant server 110 to generate return shipping labels. Again with reference to Figure 2, the present invention includes at least one user computer 150 in connection with the computer network 100 and the merchant server 110. In a preferred embodiment, a user computer 150 is equipped with a web browser. network capable of accessing the merchant network site 120. Figure 3 is a high-level block diagram that exposes the operation of an embodiment of the present invention. In step 305, a user has access to the merchant network site 120 and sends a return request, in which the user notifies the merchant that a customer wishes to return a good. In a preferred embodiment, the user is the client who wishes to return the good and the client uses a user computer 150 to make contact with the merchant network site 120. But it must be evident that the user who has access to the network site Merchant 120 does not have to be the customer. In an alternate mode, for example, the user is a customer service representative who works for the merchant and who
i * í? ÉlJtÍ?. .ulk..i? lUtr * *. * - i * ^ ju. l. . .. al.- jjB-., _ ».- !. *. + jbk ^? a? t * JF ^ - ^? - ~ ^ J ^ * 'í ^^ * Md áU lÍl¡ktk? A¡Mb enters the return request for the benefit of a customer after receiving a call Telephone or email message from a customer. Figures 4A-4F illustrate network pages that a merchant could provide in accordance with the present invention to allow a user to send a return request. The base page shown in Figure 4A illustrates a typical entry point to a merchant network site 120. In a preferred embodiment, the base page identifies the merchant and offers users the option to enter the site or Sign in as a new user. Figure 4B is an example of a network entry page that identifies the user by email address and password. When the user enters, the merchant system links the user to a directory page of the merchant network site, as illustrated in Figure 4C. From the directory page, the user can select from a panel of options on the left of the page. In a preferred embodiment, the options include "store directory", "Search", "Observe basket", "Exit", and "Returns" and each option has a corresponding hypertext link that directs the user to a corresponding network page. To send a return request, the user selects the "Return" option and links to a network page such as the one shown in figure 4D. The network page shown in Figure 4D displays a list of orders that the customer has previously placed with the merchant and allows the user to select the order corresponding to the
I ??? Á? R ^ '^ l ^ - &"• ^^" * "- article that the client wishes to return. In the preferred embodiment, the client's order list is stored in a customer order database and indexed by a customer identifier. Therefore, when the user selects the "Return" option from the directory page, the system automatically withdraws and displays the list of client orders that correspond to that user. The list of customer orders shown in figure 4D identifies the item that the customer wants to return. It will be readily apparent to the person skilled in the art that using a list of customer orders is one of many methods to identify the good the customer wishes to return. In an alternative modality, for example, you can ask the user to enter the relevant product information. Following with this illustration, the user immediately selects an order number that corresponds to the article that the client wishes to return. The selection of the user of an order number causes the user to link to a network page such as the one shown in Figure 4E where a product box listing the items of products corresponding to the selected number is displayed. The product box shown in Figure 4E lists the description, quantity and item number for each item corresponding to the selected order number. The fields in the product box shown in Figure 4 are designed to be illustrative. In alternative modalities, a product box may include such additional information as purchase price, retail price, color and weight.
it + r u n í- ü .... mni. ». , raffle », .ti unttir i. .Mki iimt ^? ? iití ilÉMtouMMi Á "** '** s In the next step, the user selects the article to be returned from the selected product box a hypertext link corresponding to the appropriate article number In this example, a user wishes to return a teapot and therefore selects the hypertext link 5 for the item number 987654-28.This link sends the user to Figure 4F where the user is required to identify the number of teapots that the customer wishes to return. gives the user the opportunity to select one of a list of pre-approved reasons for the return Three pre-approved reasons for return are shown in Figure 4F:
10"damaged", "incorrect", and "blag!" In a preferred embodiment, the customer's return request is pre-approved and occurs instantaneously. In another modality, a merchant may choose to review the reasons for the return request before approving the return, or alternatively, may completely skip the approval procedure. Y
15 It will be readily apparent that a merchant approval procedure may occur instantaneously or the return procedure may be stopped by further pending acts of the customer or merchant. Returning to the block diagram of Figure 3, the merchant approval procedure is shown in step 310. Once
20 approves the return request, the procedure proceeds to step 315 in which the merchant server 110 (see also figure 2) establishes a link to the ASP server 130 via the computer network 100 and transmits related shipping information with the request for refund of
front. The shipping information may include any information that a courier uses to send a package from a customer to a merchant, including without limitation, the customer's address, the merchant's address, the level of service, and the weight and dimensions of the package that is being delivered. will send. In a preferred embodiment, the merchant server 110 obtains the customer address from a customer order database and obtains information about the measures and weight of the article to be sent from one or more product databases. In an alternate mode, the customer, the merchant or a third party seller can feed some or all of the shipping information. If a product database is used, it may reside on the merchant server 110 or it may reside on a separate server such as a third-party vendor or vendor server (not shown). In step 320 of Figure 3, the ASP server receives the return request and the related shipping information and proceeds to step 325 where the transaction is manifested. In step 325, the shipping information is validated against the messaging delivery rules. If necessary shipping information is missing, or alternatively, if an inappropriate messaging service level is requested, an error code is generated and sent to the merchant. An illustration of an inadequate messaging shipment level request is a request for ground service for a shipment from California to Hawaii. If the system determines that the transaction is valid, the ASP server sends the submission information to the server.
messaging (step 330). In a preferred embodiment, the sending information is sent to the messaging in a registration format known as a packet level detail (PLD). But it will be readily apparent to the person skilled in the art that the shipping information can be sent to the courier in any format. In a preferred embodiment, in step 330 the messaging initiates the billing procedure and generates an invoice to the merchant for the shipping charges. And the messaging assigns a packet tracking number to the transaction and transmits the tracking information to the ASP server. In step 335, the ASP application uses the merchant's shipping information and tracking information from the courier to generate an electronic return shipping label. In one mode, the ASP application creates a network page in a hypertext markup (HTML) format that displays the electronic image of the return shipping label and assigns a uniform resource locator address to the network page (URL ). Figure 5 illustrates a typical return shipping label 200 and includes: a shipment from address 215, shipping to address 220, Maxicode ™ 225, postal office code 235, postal office bar code 240, tracking number of messaging 245, messaging bar code 250, and service identification 255. In the preferred embodiment, the shipment from address 215 is the customer's address and the shipment to address 220 is the address of the merchant or seller accepting the shipment of the returned item.
Fig. 6 shows another embodiment of a network page created by the ASP application in step 355. In this embodiment, a text area 300 accompanies the shipping label 200 and the text area 300 includes written instructions about printing of a tag 305 and takes a packet to a delivery messenger 310. The text area 300 also includes a messenger delivery location link 315. A click on the delivery location link 315 causes the ASP application to access a base of courier delivery data and remove a list of courier delivery locations that are close to the customer's address. In a preferred embodiment, the ASP application removes messaging delivery locations within 15 km of the customer's address. Figure 7 shows a typical network page that is displayed when a user clicks on the delivery location link 315. The network page shown in figure 7 lists courier delivery locations 350 that are close to the address of the delivery address. client 215. A type of location 355, address 360, hours of operation 365, telephone number 370 and distance from the address of the customer 375 is displayed for each delivery location. In addition, a delivery link 380 is displayed that will provide detailed information about each delivery location when selected. In one embodiment, this detailed information includes a map from the customer's address 215 to the delivery location (Figure 8). Returning to Figure 3, after the ASP application creates the network site that displays the return shipping label, the procedure proceeds to step 345 and the ASP application transmits an email notification to a vendor indicating that it is returning a good. In a preferred embodiment, this step occurs only if the good being returned is not being sent directly to the merchant but instead is sent to a third party vendor or supplier of the good. Alternatively, step 345 could provide an email notification to another merchant division or other entity that the merchant uses to process returns. In step 355, the ASP application sends the URL of the return shipping label on the network page to the merchant server 110. In a preferred embodiment, the network page is actually stored in the ASP server and a link to the server. the URL is sent to the merchant server 110. Alternatively, the ASP application can send the actual HTML document, return shipping label and allow the merchant to publish the page on the merchant server 110. In any of these modalities, the merchant is responsible for providing the customer with the URL of the network page that contains the return shipping label. In alternate modes, the ASP application sends the return shipping label directly to the customer. In one mode, the ASP application sends an email to the client that includes the URL of the network page that contains the return shipping label. In another mode, the ASP application can format the return shipment label as a graphic file and can attach the graphic file to an email to the customer. In a preferred embodiment, the image of a return shipping label is formatted as a portable data file (PDF), but it will be readily apparent to a person skilled in the art that an image of a return shipping label can be stored. in other data formats such as portable network graphics (PNG) or graphics interchange format (GIF). In another mode, the customer does not receive a return shipping label. Instead, the ASP application generates a return shipping label and transmits it directly to a messaging facility that is close to the customer's address. In this modality, the courier sends a driver to pick up the customer's package instead of requiring the customer to take the package to a courier delivery facility. The ASP application accomplishes this by having access to a messaging installation database (not shown) to determine which messaging facility is responsible for shipments to the customer's address. The ASP application then generates a return shipping label and transmits it directly to the local messaging installation. A driver of the courier facility then takes the return shipping label to the customer's address, picks up the package to be returned, sets the shipping label to the package and places the package in the courier shipping system for shipping to the merchant.
Üfl iitált **** '* "' ^ HfcJMl •? Ir, t * jM'a-- --- -" * • «- -? - *. ^. ***** *** - * * ^ *. * ...-- »* - ... ^ ..-- - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ your database records in response to a notification from the ASP application that a return shipping label was generated for the return transaction. Trader updates to the database can include general statistics that refer to product returns as well as specific details about the particular transaction such as package tracking numbers, return shipping cost, and product inventory update. In step 365, the customer receives the return shipping label and the delivery location information. In Figure 3, the merchant sends the client the URL of the network site containing the shipping label and delivery information. However, as explained above, in alternate modalities the customer can receive the return shipping label directly from the ASP application or a courier can send a driver to the customer's address as part of the courier service. At step 370, the customer prints the return shipping label, sets the label to a package containing the item to be returned, and takes the package to a courier delivery location. And at step 375, the courier receives the package and supplies it for shipment to the address specified on the return shipping label. In a preferred embodiment, the messaging tracks the packet through the sending procedure using the packet tracking number in the
Return shipping label and invoice to the merchant or other suitable party for the shipping fee when confirming the delivery. In the preferred mode, the package tracking number provides the delivery confirmation and activates the billing procedure. In addition, multiple billing options are available and a merchant can be billed by means of a credit card, check or debit account. Upon completion of the detailed description, it should be noted that it will be apparent to those skilled in the art that many variations and modifications can be made to the preferred embodiment without departing substantially from the principles of the present invention. In addition, such variations and modifications are designed to be included within the scope of the present invention as set forth in the appended claims. Additionally, in the following claims, the structures, materials, acts and equivalents of all the means or elements of function of each additional step are designed to include any structure, materials or acts to perform their aforementioned functions.