U.S. patent application number 14/049828 was filed with the patent office on 2015-04-09 for customer controlled management of shipments.
This patent application is currently assigned to United Parcel Service of America, Inc.. The applicant listed for this patent is United Parcel Service of America, Inc.. Invention is credited to Carrie Parris.
Application Number | 20150100514 14/049828 |
Document ID | / |
Family ID | 52777792 |
Filed Date | 2015-04-09 |
United States Patent
Application |
20150100514 |
Kind Code |
A1 |
Parris; Carrie |
April 9, 2015 |
Customer Controlled Management of Shipments
Abstract
Computer program products, methods, systems, apparatus, and
computing entities are provided for customer controlled management
of shipments. For example, customers can define handling
identifiers to determine how items should be handled based on the
handling identifier. Further, customers can define refund
classifications to determine when refunds should be initiated.
Inventors: |
Parris; Carrie; (Atlanta,
GA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
United Parcel Service of America, Inc. |
Atlanta |
GA |
US |
|
|
Assignee: |
United Parcel Service of America,
Inc.
Atlanta
GA
|
Family ID: |
52777792 |
Appl. No.: |
14/049828 |
Filed: |
October 9, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14049605 |
Oct 9, 2013 |
|
|
|
14049828 |
|
|
|
|
Current U.S.
Class: |
705/340 |
Current CPC
Class: |
G06Q 10/083 20130101;
G06Q 10/0837 20130101 |
Class at
Publication: |
705/340 |
International
Class: |
G06Q 10/08 20060101
G06Q010/08 |
Claims
1. A method comprising: receiving one or more notifications
associated with an item being returned, the item associated with a
refund classification identifying one or more triggering events
that indicate when a refund for the item being returned is to be
initiated; determining whether the one or more triggering events of
the refund classification have occurred based at least in part on
the one or more notifications; and responsive to determining that
the one or more triggering events of the refund classification have
occurred based at least in part on the one or more notifications,
initiating the refund for the item.
2. The method of claim 1 further comprising associating the refund
classification with the item being returned.
3. The method of claim 1 further comprising: receiving a request to
return the item; and determining whether to authorize the return
based at least in part on one or more business rules for processing
returns.
4. The method of claim 1 further comprising: responsive to
determining to authorize the return based at least in part on one
or more business rules for processing returns, associating a
handling identifier with the item, the handling identifier
comprising a collection method portion, a return category portion,
and a delivery point portion, wherein (a) the collection method
portion indicates collection methods that are available for the
item, (b) the return category portion indicates whether to
consolidate the item with similar items, and (c) the delivery point
portion indicates a delivery destination of the item.
5. The method of claim 1, wherein the handling identifier is
selected from the group consisting of alphanumeric text, a barcode,
a Quick Response code, and a MaxiCode.
6. The method of claim 1, wherein the one or more notifications are
received based at least in part on one or more communications
preferences.
7. An apparatus comprising at least one processor and at least one
memory including program code, the at least one memory and the
program code configured to, with the processor, cause the apparatus
to at least: receive one or more notifications associated with an
item being returned, the item associated with a refund
classification identifying one or more triggering events that
indicate when a refund for the item being returned is to be
initiated; determine whether the one or more triggering events of
the refund classification have occurred based at least in part on
the one or more notifications; and responsive to determining that
the one or more triggering events of the refund classification have
occurred based at least in part on the one or more notifications,
initiate the refund for the item.
8. The apparatus of claim 7, wherein the memory and program code
are further configured to, with the processor, cause the apparatus
to associate the refund classification with the item being
returned.
9. The apparatus of claim 7, wherein the memory and program code
are further configured to, with the processor, cause the apparatus
to: receive a request to return the item; and determine whether to
authorize the return based at least in part on one or more business
rules for processing returns.
10. The apparatus of claim 7, wherein the memory and program code
are further configured to, with the processor, cause the apparatus
to: responsive to determining to authorize the return based at
least in part on one or more business rules for processing returns,
associate a handling identifier with the item, the handling
identifier comprising a collection method portion, a return
category portion, and a delivery point portion, wherein (a) the
collection method portion indicates collection methods that are
available for the item, (b) the return category portion indicates
whether to consolidate the item with similar items, and (c) the
delivery point portion indicates a delivery destination of the
item.
11. The apparatus of claim 7, wherein the handling identifier is
selected from the group consisting of alphanumeric text, a barcode,
a Quick Response code, and a MaxiCode.
12. The apparatus of claim 7, wherein the one or more notifications
are received based at least in part on one or more communications
preferences.
13. A computer program product, the computer program product
comprising at least one non-transitory computer-readable storage
medium having computer-readable program code portions stored
therein, the computer-readable program code portions comprising: an
executable portion configured to receive one or more notifications
associated with an item being returned, the item associated with a
refund classification identifying one or more triggering events
that indicate when a refund for the item being returned is to be
initiated; an executable portion configured to determine whether
the one or more triggering events of the refund classification have
occurred based at least in part on the one or more notifications;
and an executable portion configured to, responsive to determining
that the one or more triggering events of the refund classification
have occurred based at least in part on the one or more
notifications, initiate the refund for the item.
14. The computer program product of claim 13, wherein the memory
and program code are further configured to, with the processor,
cause the apparatus to associate the refund classification with the
item being returned.
15. The computer program product of claim 13 further comprising: an
executable portion configured to receive a request to return the
item; and an executable portion configured to determine whether to
authorize the return based at least in part on one or more business
rules for processing returns.
16. The computer program product of claim 13 further comprising: an
executable portion configured to, responsive to determining to
authorize the return based at least in part on one or more business
rules for processing returns, associate a handling identifier with
the item, the handling identifier comprising a collection method
portion, a return category portion, and a delivery point portion,
wherein (a) the collection method portion indicates collection
methods that are available for the item, (b) the return category
portion indicates whether to consolidate the item with similar
items, and (c) the delivery point portion indicates a delivery
destination of the item.
17. The computer program product of claim 13, wherein the handling
identifier is selected from the group consisting of alphanumeric
text, a barcode, a Quick Response code, and a MaxiCode.
18. The computer program product of claim 13, wherein the one or
more notifications are received based at least in part on one or
more communications preferences.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. application Ser.
No. 14/049,605 filed Oct. 9, 2013, which is hereby incorporated
herein in its entirety by reference.
BACKGROUND
[0002] Shipping customers are increasing their expectations
regarding various delivery services. Thus, new concepts are needed
to enhance customer experience and loyalty by improving the
delivery experience.
BRIEF SUMMARY
[0003] In general, embodiments of the present invention provide
systems, methods, apparatus, and computer program products for
customer controlled management of shipments.
[0004] In accordance with one aspect, a method is provided. In one
embodiment, the method comprises (1) receiving a request to return
an item; (2) determining whether to authorize the return based at
least in part on one or more business rules for processing returns;
and (3) responsive to determining to authorize the return based at
least in part on one or more business rules for processing returns,
associating a handling identifier with the item, the handling
identifier comprising a collection method portion, a return
category portion, and a delivery point portion, wherein (a) the
collection method portion indicates collection methods that are
available for the item, (b) the return category portion indicates
whether to consolidate the item with similar items, and (c) the
delivery point portion indicates a delivery destination of the
item.
[0005] In accordance with another aspect, a computer program
product is provided. The computer program product may comprise at
least one computer-readable storage medium having computer-readable
program code portions stored therein, the computer-readable program
code portions comprising executable portions configured to (1)
receive a request to return an item; (2) determine whether to
authorize the return based at least in part on one or more business
rules for processing returns; and (3) responsive to determining to
authorize the return based at least in part on one or more business
rules for processing returns, associate a handling identifier with
the item, the handling identifier comprising a collection method
portion, a return category portion, and a delivery point portion,
wherein (a) the collection method portion indicates collection
methods that are available for the item, (b) the return category
portion indicates whether to consolidate the item with similar
items, and (c) the delivery point portion indicates a delivery
destination of the item.
[0006] In accordance with yet another aspect, an apparatus
comprising at least one processor and at least one memory including
computer program code is provided. In one embodiment, the at least
one memory and the computer program code may be configured to, with
the processor, cause the apparatus to (1) receive a request to
return an item; (2) determine whether to authorize the return based
at least in part on one or more business rules for processing
returns; and (3) responsive to determining to authorize the return
based at least in part on one or more business rules for processing
returns, associate a handling identifier with the item, the
handling identifier comprising a collection method portion, a
return category portion, and a delivery point portion, wherein (a)
the collection method portion indicates collection methods that are
available for the item, (b) the return category portion indicates
whether to consolidate the item with similar items, and (c) the
delivery point portion indicates a delivery destination of the
item.
[0007] In accordance with one aspect, a method is provided. In one
embodiment, the method comprises (1) receive one or more
notifications associated with an item being returned, the item
associated with a refund classification identifying one or more
triggering events that indicate when a refund for the item being
returned is to be initiated; (2) determine whether the one or more
triggering events of the refund classification have occurred based
at least in part on the one or more notifications; and (3)
responsive to determining that the one or more triggering events of
the refund classification have occurred based at least in part on
the one or more notifications, initiate the refund for the
item.
[0008] In accordance with another aspect, a computer program
product is provided. The computer program product may comprise at
least one computer-readable storage medium having computer-readable
program code portions stored therein, the computer-readable program
code portions comprising executable portions configured to (1)
receive one or more notifications associated with an item being
returned, the item associated with a refund classification
identifying one or more triggering events that indicate when a
refund for the item being returned is to be initiated; (2)
determine whether the one or more triggering events of the refund
classification have occurred based at least in part on the one or
more notifications; and (3) responsive to determining that the one
or more triggering events of the refund classification have
occurred based at least in part on the one or more notifications,
initiate the refund for the item.
[0009] In accordance with yet another aspect, an apparatus
comprising at least one processor and at least one memory including
computer program code is provided. In one embodiment, the at least
one memory and the computer program code may be configured to, with
the processor, cause the apparatus to (1) receive one or more
notifications associated with an item being returned, the item
associated with a refund classification identifying one or more
triggering events that indicate when a refund for the item being
returned is to be initiated; (2) determine whether the one or more
triggering events of the refund classification have occurred based
at least in part on the one or more notifications; and (3)
responsive to determining that the one or more triggering events of
the refund classification have occurred based at least in part on
the one or more notifications, initiate the refund for the
item.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)
[0010] Having thus described the invention in general terms,
reference will now be made to the accompanying drawings, which are
not necessarily drawn to scale, and wherein:
[0011] FIG. 1 is an overview of a system that can be used to
practice embodiments of the present invention.
[0012] FIG. 2 is an exemplary schematic diagram of a carrier system
according to one embodiment of the present invention.
[0013] FIG. 3 is an exemplary schematic diagram of a mobile station
according to one embodiment of the present invention.
[0014] FIGS. 4 and 32 are flowcharts illustrating operations and
processes that can be used in accordance with various embodiments
of the present invention.
[0015] FIGS. 5-31 and 33 show exemplary input and output of various
embodiments of the present invention.
DETAILED DESCRIPTION
[0016] Various embodiments of the present invention now will be
described more fully hereinafter with reference to the accompanying
drawings, in which some, but not all embodiments of the inventions
are shown. Indeed, these inventions may be embodied in many
different forms and should not be construed as limited to the
embodiments set forth herein; rather, these embodiments are
provided so that this disclosure will satisfy applicable legal
requirements. The term "or" is used herein in both the alternative
and conjunctive sense, unless otherwise indicated. The terms
"illustrative" and "exemplary" are used to be examples with no
indication of quality level. Like numbers refer to like elements
throughout.
I. METHODS, APPARATUS, SYSTEMS, AND COMPUTER PROGRAM PRODUCTS
[0017] As should be appreciated, various embodiments may be
implemented in various ways, including as methods, apparatus,
systems, or computer program products. Accordingly, various
embodiments may take the form of an entirely hardware embodiment or
an embodiment in which a processor is programmed to perform certain
steps. Furthermore, various implementations may take the form of a
computer program product on a computer-readable storage medium
having computer-readable program instructions embodied in the
storage medium. Any suitable computer-readable storage medium may
be utilized including hard disks, CD-ROMs, optical storage devices,
or magnetic storage devices.
[0018] Various embodiments are described below with reference to
block diagrams and flowchart illustrations of methods, apparatus,
systems, and computer program products. It should be understood
that each block of the block diagrams and flowchart illustrations,
respectively, may be implemented in part by computer program
instructions, e.g., as logical steps or operations executing on a
processor in a computing system. These computer program
instructions may be loaded onto a computer, such as a special
purpose computer or other programmable data processing apparatus to
produce a specifically-configured machine, such that the
instructions which execute on the computer or other programmable
data processing apparatus implement the functions specified in the
flowchart block or blocks.
[0019] These computer program instructions may also be stored in a
computer-readable memory that can direct a computer or other
programmable data processing apparatus to function in a particular
manner, such that the instructions stored in the computer-readable
memory produce an article of manufacture including
computer-readable instructions for implementing the functionality
specified in the flowchart block or blocks. The computer program
instructions may also be loaded onto a computer or other
programmable data processing apparatus to cause a series of
operational steps to be performed on the computer or other
programmable apparatus to produce a computer-implemented process
such that the instructions that execute on the computer or other
programmable apparatus provide operations for implementing the
functions specified in the flowchart block or blocks.
[0020] Accordingly, blocks of the block diagrams and flowchart
illustrations support various combinations for performing the
specified functions, combinations of operations for performing the
specified functions, and program instructions for performing the
specified functions. It should also be understood that each block
of the block diagrams and flowchart illustrations, and combinations
of blocks in the block diagrams and flowchart illustrations, can be
implemented by special purpose hardware-based computer systems that
perform the specified functions or operations, or combinations of
special purpose hardware and computer instructions.
II. EXEMPLARY SYSTEM ARCHITECTURE
[0021] FIG. 1 provides an illustration of a system that can be used
in conjunction with various embodiments of the present invention.
As shown in FIG. 1, the system may include one or more carrier
systems 100, one or more mobile stations 105, one or more consignee
computing devices 110, one or more networks 115, and one or more
consignor computing devices 120. Each of the components of the
system may be in electronic communication with, for example, one
another over the same or different wireless or wired networks
including, for example, a wired or wireless Personal Area Network
(PAN), Local Area Network (LAN), Metropolitan Area Network (MAN),
Wide Area Network (WAN), or the like. Additionally, while FIG. 1
illustrates certain communication system entities as separate,
standalone entities, the various embodiments are not limited to
this particular architecture.
1. Exemplary Carrier System
[0022] FIG. 2 provides an exemplary schematic of a carrier system
100 according to one embodiment of the present invention. In
general, the term "system" may refer to, for example, one or more
computers, computing devices, mobile phones, desktops, notebooks or
laptops, distributed systems, servers, blades, gateways, switches,
processing devices, or combination of processing devices adapted to
perform the functions described herein. However, the carrier system
100 may also comprise various other systems, such as an Address
Matching System (AMS), an Internet Membership System (IMS), a
Customer Profile System (CPS), a Package Center Information System
(PCIS), a Customized Pickup and Delivery System (CPAD), a Web
Content Management System (WCMS), a Notification Email System
(NES), a Fraud Prevention System (FPS), and a variety of other
systems and their corresponding components.
[0023] As will be understood from FIG. 1, in one embodiment, the
carrier system 100 includes one or more processors 205 that
communicate with other elements within the carrier system 100 via a
system interface or bus 261. The processor 205 may be embodied in a
number of different ways. For example, the processor 205 may be
embodied as a processing element, processing circuitry, a
coprocessor, a controller or various other processing devices
including integrated circuits such as, for example, an application
specific integrated circuit (ASIC), a field programmable gate array
(FPGA), a hardware accelerator, or the like.
[0024] In an exemplary embodiment, the processor 205 may be
configured to execute instructions stored in memory or otherwise
accessible to the processor 205. As such, whether configured by
hardware or software methods, or by a combination thereof, the
processor 205 may represent an entity capable of performing
operations according to embodiments of the present invention when
configured accordingly. A display device/input device 264 for
receiving and displaying data may also be included in the carrier
system 100. This display device/input device 264 may be, for
example, a keyboard or pointing device that is used in combination
with a monitor. The carrier system 100 may further include
transitory and non-transitory memory 263, which may include both
random access memory (RAM) 267 and read only memory (ROM) 265. The
carrier system's ROM 265 may be used to store a basic input/output
system (BIOS) 226 containing the basic routines that help to
transfer information to the different elements within the carrier
system 100.
[0025] In addition, in one embodiment, the carrier system 100 may
include at least one storage device 268, such as a hard disk drive,
a CD drive, and/or an optical disk drive for storing information on
various computer-readable media. The storage device(s) 268 and its
associated computer-readable media may provide nonvolatile storage.
The computer-readable media described above could be replaced by
any other type of computer-readable media, such as embedded or
removable multimedia memory cards (MMCs), secure digital (SD)
memory cards, Memory Sticks, electrically erasable programmable
read-only memory (EEPROM), flash memory, hard disk, or the like.
Additionally, each of these storage devices 268 may be connected to
the system bus 261 by an appropriate interface.
[0026] Furthermore, a number of executable instructions,
applications, program modules, and/or the like may be stored by the
various storage devices 268 and/or within RAM 267. Such executable
instructions, applications, program modules, and/or the like may
include an operating system 280, a registration module 270, an
alert module 260, a delivery options module 250, and identification
module 245. As discussed in more detail below, these executable
instructions, applications, program modules, and/or the like may
control certain aspects of the operation of the carrier system 100
with the assistance of the processor 205 and operating system
280--although their functionality need not be modularized. In
addition to the program modules, the carrier system 100 may store
or be in communication with one or more databases, such as database
240.
[0027] Also located within the carrier system 100, in one
embodiment, is a network interface 274 for interfacing with various
computing entities (e.g., with one or more mobile stations 105).
For example, the carrier system 100 may be able to receive data
and/or messages from and transmit data and/or messages to the
mobile station 105, consignee computing devices 110, and consignor
computing devices 120. This communication may be via the same or
different wired or wireless networks (or a combination of wired and
wireless networks). For instance, the communication may be executed
using a wired data transmission protocol, such as fiber distributed
datan interface (FDDI), digital subscriber line (DSL), Ethernet,
asynchronous transfer mode (ATM), frame relay, data over cable
service interface specification (DOCSIS), or any other wired
transmission protocol. Similarly, the carrier system 100 may be
configured to communicate via wireless external communication
networks using any of a variety of protocols, such as 802.11,
general packet radio service (GPRS), Universal Mobile
Telecommunications System (UMTS), Code Division Multiple Access
2000 (CDMA2000), CDMA2000 1X (1xRTT), Wideband Code Division
Multiple Access (WCDMA), Time Division-Synchronous Code Division
Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Evolved
Universal Terrestrial Radio Access Network (E-UTRAN),
Evolution-Data Optimized (EVDO), High Speed Packet Access (HSPA),
High-Speed Downlink Packet Access (HSDPA), IEEE 802.11 (Wi-Fi),
802.16 (WiMAX), ultra wideband (UWB), infrared (IR) protocols, near
field communication (NFC) protocols, Bluetooth.TM. protocols,
wireless universal serial bus (USB) protocols, and/or any other
wireless protocol.
[0028] It will be appreciated that one or more of the carrier
system's 100 components may be located remotely from other carrier
system 100 components. Furthermore, one or more of the components
may be combined and additional components performing functions
described herein may be included in the carrier system 100.
2. Exemplary Mobile Station
[0029] FIG. 3 provides an illustrative schematic representative of
a mobile station 105 that can be used in conjunction with the
embodiments of the present invention. Mobile stations 105 can be
operated by various parties, including carrier personnel (e.g.,
delivery drivers, sorters, and/or the like). As shown in FIG. 3,
the mobile station 105 can include an antenna 312, a transmitter
304 (e.g., radio), a receiver 306 (e.g., radio), and a processing
device 308 (e.g., a processor, controller, and/or the like) that
provides signals to and receives signals from the transmitter 304
and receiver 306, respectively.
[0030] The signals provided to and received from the transmitter
304 and the receiver 306, respectively, may include signaling
information in accordance with an air interface standard of
applicable wireless systems. In this regard, the mobile station 105
may be capable of operating with one or more air interface
standards, communication protocols, modulation types, and access
types. More particularly, the mobile station 105 may operate in
accordance with any of a number of wireless communication standards
and protocols, such as those described above with regard to the
carrier system 100. In a particular embodiment, the mobile station
105 may operate in accordance with multiple wireless communication
standards and protocols (e.g., using a Gobi radio), such as GSM,
UMTS, 1xRTT, and EVDO, and use multiple wireless carriers. To do
so, the mobile station 105 may include integrated mobile reception
diversity and integrated power management. Such a configuration can
provide for global connectivity to the user.
[0031] Via these communication standards and protocols, the mobile
station 105 can communicate with various other entities using
concepts such as Unstructured Supplementary Service Data (USSD),
Short Message Service (SMS), Multimedia Messaging Service (MMS),
Dual-Tone Multi-Frequency Signaling (DTMF), and/or Subscriber
Identity Module Dialer (SIM dialer). The mobile station 105 can
also download changes, add-ons, and updates, for instance, to its
firmware, software (e.g., including executable instructions,
applications, program modules), and operating system.
[0032] According to one embodiment, the mobile station 105 may
include a location determining device and/or functionality. For
example, the mobile station 105 may include a Global Positioning
System (GPS) module adapted to acquire, for example, latitude,
longitude, altitude, geocode, course, and/or speed data. In one
embodiment, the GPS module acquires data, sometimes known as
ephemeris data, by identifying the number of satellites in view and
the relative positions of those satellites.
[0033] The mobile station 105 may also comprise a user interface
(that can include a display 316 coupled to a processing device 308)
and/or a user input interface (coupled to the processing device
308). The user input interface can comprise any of a number of
devices allowing the mobile station 105 to receive data, such as a
keypad 318, a touch display, voice or motion interfaces, or other
input device. In embodiments including a keypad 318, the keypad 318
can include the conventional numeric (0-9) and related keys (#, *),
and other keys used for operating the mobile station 105 and may
include a full set of alphabetic keys or set of keys that may be
activated to provide a full set of alphanumeric keys. In addition
to providing input, the user input interface can be used, for
example, to activate or deactivate certain functions, such as
screen savers and/or sleep modes.
[0034] The mobile station 105 can also include volatile memory 322
and/or non-volatile memory 324, which can be embedded and/or may be
removable. For example, the non-volatile memory may be embedded or
removable MMCs, secure digital SD memory cards, Memory Sticks,
EEPROM, flash memory, hard disk, or the like. The memory can store
any of a number of pieces or amount of information and data used by
the mobile station 105 to implement the functions of the mobile
station 105. The memory can also store content, such as computer
program code for an application and/or other computer programs.
3. Exemplary Consignee Computing Device
[0035] The consignee computing devices 110 may each include one or
more components that are functionally similar to those of the
carrier system 100 and/or mobile station 105. For example, in one
embodiment, each of the consignee computing devices may include:
(1) a processor that communicates with other elements via a system
interface or bus; (2) a user interface; (3) transitory and
non-transitory memory; and (4) a communications interface. As
noted, the consignee computing device 110 may comprise a user
interface (that can include a display device/input device coupled
to a processing element 308) and/or a user input interface (coupled
to a processing element 308). For example, the user interface may
be a carrier application, browser, user interface, dashboard,
webpage, and/or similar words used herein interchangeably executing
on and/or accessible via the consignee computing device 110 to
interact with and/or cause display of information from the carrier
system 100, as described herein. These architectures are provided
for exemplary purposes only and are not limiting to the various
embodiments. The term "computing device" is used generically to
refer to any computer, computing device, desktop, notebook or
laptop, distributed system, carrier system, gateway, switch, or
other processing device adapted to perform the functions described
herein. A customer may refer to either a consignor (e.g., a party
shipping an item via carrier) or a consignee (e.g., a party
receiving an item from a carrier). In the returns context, a
consignee who received an item can become a consignor when
returning an item.
4. Exemplary Consignor Computing Device
[0036] The consignor computing devices 120 may each include one or
more components that are functionally similar to those of the
carrier system 100 and/or mobile station 105. For example, in one
embodiment, each of the consignor computing devices may include:
(1) a processor that communicates with other elements via a system
interface or bus; (2) a user interface; (3) transitory and
non-transitory memory; and (4) a communications interface. As
noted, the consignor computing device 120 may comprise a user
interface (that can include a display device/input device coupled
to a processing element 308) and/or a user input interface (coupled
to a processing element 308). For example, the user interface may
be a carrier application, browser, user interface, dashboard,
webpage, and/or similar words used herein interchangeably executing
on and/or accessible via the consignor computing device 120 to
interact with and/or cause display of information from the carrier
system 100, as described herein. These architectures are provided
for exemplary purposes only and are not limiting to the various
embodiments. The term "computing device" is used generically to
refer to any computer, computing device, desktop, notebook or
laptop, distributed system, carrier system, gateway, switch, or
other processing device adapted to perform the functions described
herein. A customer may refer to either a consignor (e.g., a party
shipping an item via carrier) or a consignee (e.g., a party
receiving an item from a carrier). In the returns context, a
consignor who shipped an item can become a consignee when an item
is being returned.
III. EXEMPLARY SYSTEM OPERATION
[0037] Reference will now be made to FIGS. 4-26. FIGS. 4 and 32 are
flowcharts illustrating operations and processes that may be
performed for customer controlled management of shipments. FIGS.
5-31 and 33 show exemplary input and output for customer controlled
management of shipments.
1. Registration
[0038] In one embodiment, as indicated in Block 400 of FIG. 4, the
process may begin with the enrollment/registration of one or more
customers (e.g., consignors and/or consignees) for a customer
pickup, delivery, and/or returns program. A customer (e.g.,
consignor or consignee) may be an individual, a family, a company,
an organization, an entity, a department within an organization, a
representative of an organization and/or person, and/or the like.
To register, a customer (e.g., a customer or customer
representative operating a consignee computing device 110 or
consignor computing device 120) may access a webpage or portal of a
carrier, such as United Parcel Service of America, Inc. (UPS). For
instance, as shown in FIGS. 5 and 6, the carrier system 100 may
transmit a webpage that provides the customer with an option of
logging into a customer account or enrolling/registering for a
customer pickup, delivery, and/or returns program.
[0039] In one embodiment, as part of the enrollment/registration
process, the customer (e.g., operating a consignee computing device
110 or consignor computing device 120) may be requested to provide
biographic and/or geographic information by the carrier system 100
(e.g., via the registration module 270). For instance, the customer
may provide the customer's name, such as a first name, a last name,
a company name, an entity name, and/or an organization name. The
customer (e.g., consignor or consignee) may also provide any
aliases associated with the customer. For instance, if the customer
(e.g., consignor or consignee) were an individual named Joseph
Brown, the customer (e.g., consignor or consignee) may provide Joe
Brown or Joey Brown as aliases. The customer (e.g., consignor or
consignee) may also provide one or more addresses associated with
the customer (e.g., street address, city, state, postal code,
and/or country). For instance, Joseph Brown's address may be 105
Main Street, Atlanta, Ga. 30309, USA. As indicated, the customer
(e.g., consignor or consignee) may have multiple addresses
associated with the account. For instance, Joseph Brown may have a
home address and a business address associated with his account.
Similarly, an organization may have multiple locations (e.g.,
addresses) associated with its account. For example, an Amazon
account may have one or more address associated with outbound
shipments, one or more addresses associated with inbound shipments,
and/or one or more addresses associated with return shipments. When
multiple addresses are provided, the customer may indicate which
address should be used as the primary address. As will be
recognized, the customer (e.g., consignor or consignee) may provide
other biographic and/or geographic information to adapt to various
needs and circumstances.
[0040] In one embodiment, once the carrier system 100 receives the
necessary biographic and/or geographic information from the
customer, the carrier system 100 may perform one or more validation
operations. For example, the carrier system 100 may determine
whether the primary address (and/or other addresses) in the
specified country or postal code is eligible for a customer pickup,
delivery, and/or returns program. The carrier system 100 may also
determine whether the primary address (and/or other addresses) is
valid, e.g., by passing the primary address through one or more
address cleansing or standardization systems. The carrier system
100 may perform a variety of fraud prevention measures as well,
such as determining whether the customer (e.g., consignor or
consignee) or one of the customer's addresses has been
"blacklisted" from customer pickup, delivery, and/or returns
programs. As will be recognized, a variety of other approaches and
techniques can be used to adapt to various needs and
circumstances.
[0041] In one embodiment, the carrier system 100 may create a
customer (e.g., consignor or consignee) profile for the customer
via the enrollment/registration process. Accordingly, the carrier
system 100 may create and store various customer profiles (e.g.,
via database 240). In addition to at least the information
described above, a customer profile may include one or more
corresponding usernames and passwords. Additionally, the carrier
system 100 may also create and store a carrier-assigned customer
identifier in association with the customer profile. In one
embodiment, a carrier-assigned customer identifier may be used to
uniquely identify a customer profile. In another embodiment, a
carrier-assigned customer identifier may be used to uniquely
identify a given address associated with a customer profile. In
such an embodiment, if a customer profile is associated with four
addresses, the carrier system 100 may create and store four
carrier-assigned customer identifiers in association with the
customer profile. The carrier-assigned customer identifier may also
be stored in association with shipping data for an item to
associate the item (and its shipping data) with the (a) correct
customer (e.g., customer profile) and/or (b) correct address for a
customer.
[0042] In one embodiment, a customer profile may correspond to one
or more customer pickup, delivery, and/or returns programs. For
instance, a customer (e.g., operating a consignee computing device
110 or consignor computing device 120) may subscribe to a specific
customer pickup, delivery, and/or returns program. In one
embodiment, there may be several customer pickup, delivery, and/or
returns programs from which to choose, such as a free customer
pickup, delivery, and/or returns program and a premium customer
pickup, delivery, and/or returns program. Each customer pickup,
delivery, and/or returns program may have different benefits, such
as those shown in FIG. 7 and Table 1 below.
TABLE-US-00001 TABLE 1 Membership Options Member (Free Premium
Member Services Enrollment) ($40 Annual Subscription) Delivery
Alerts I - Unlimited I - Unlimited Approximate Delivery Time I -
Unlimited I - Unlimited Delivery Options I - Unlimited I -
Unlimited Authorize Shipment Release I - Unlimited I - Unlimited
Will Call (hold for pickup at I - Unlimited I - Unlimited a UPS
facility) Printable InfoNotice I - Unlimited I - Unlimited Deliver
to a Retail Location I - $5.00 Fee I - Unlimited (UPS Store)
Reschedule Delivery I - $5.00 Fee I - Unlimited Deliver to Another
Address I - $5.00 Fee I - Unlimited "Leave At" Instructions X I -
Unlimited Leave With Neighbor X I - Unlimited Confirmed Delivery
Window X I - $5.00 Additional Fee Delivery Planner X I Close
[0043] As shown in Table 1 above and in FIG. 7 for illustrative
purposes, the free customer pickup, delivery, and/or returns
program and the premium customer pickup, delivery, and/or returns
program may have different benefits. For example, the free customer
pickup, delivery, and/or returns program may allow customers to
have access to certain features, e.g., delivery alerts, approximate
delivery times, change delivery options, electronically authorize
the release of an item, and/or route items to will call. Similarly,
the premium customer pickup, delivery, and/or returns program
(e.g., requiring a fee) may allow customers to have access to
certain features in addition to those provided via the free
customer pickup, delivery, and/or returns program, e.g., route
items to other retail locations, reschedule deliveries, request
that items be delivered to another address, and/or provide
instructions for pickup or delivery. As will be recognized, these
features are provided for illustrative purposes and are not
limiting to embodiments of the present invention. Moreover, a
variety of other approaches and techniques can be used to adapt to
various needs and circumstances.
[0044] In one embodiment, once a customer profile has been created
by the carrier system 100, the customer (e.g., operating a
consignee computing device 110 or consignor computing device 120)
can provide various preferences associated with the customer
pickup, delivery, and/or returns program to the carrier system 100
via a webpage (Block 405 of FIG. 4), for example. For instance, as
shown in FIGS. 8 and 9, the customer (e.g., operating a consignee
computing device 110 or consignor computing device 120) can provide
a variety of preferences, such communication preferences,
pickup/delivery preferences, pickup/delivery options, and/or
pickup/delivery instructions.
2. Customer and Item Matching
[0045] In one embodiment, once a customer (e.g., consignor or
consignee) profile has been created by the carrier system 100, one
or more items to be delivered to the customer by the carrier may
need to be identified. By identifying items to be delivered to the
customer, the carrier system 100 can provide the customer with
access to various features of a customer pickup, delivery, and/or
returns program for the item. As will be recognized, an item may be
one or more packages, parcels, bags, containers, loads, crates,
items banded together, vehicle parts, pallets, drums, the like,
and/or similar words used herein interchangeably. In one
embodiment, each item may include an item/shipment identifier, such
as a barcode, a MaxiCode, electronic representation, and/or text
(e.g., alphanumeric text). The unique item/shipment identifier
(e.g., 123456789) may be used by the carrier to identify and track
the item as it moves through the carrier's transportation network.
Such item/shipment identifiers can be affixed to items by, for
example, using a sticker (e.g., label) with the unique
item/shipment identifier printed thereon (in human and/or machine
readable form) or an RFID tag with the unique item/shipment
identifier stored therein. Additionally, or alternatively, as will
be described in greater detail below, customer-defined handling
identifiers (and/or carrier-assigned customer identifiers) can also
be used with the shipment of items being returned, for example. The
customer-defined handling identifiers (also referred to herein as
handling identifiers) may directly map to a given customer or
customer profile and provide various information about handling and
transporting the items and/or information about the corresponding
customer.
[0046] In one embodiment, the carrier system 100 may store an
item/shipment identifier, a carrier-assigned customer identifier,
and/or a customer-defined handling identifier in association with
shipping data for the item. The shipping data may include
information about the item, such as delivery service level. For
example, the delivery service level may be Next Day Air, Overnight,
Express, Next Day Air Early AM, Next Day Air Saver, Jetline,
Sprintline, Secureline, 2nd Day Air, Priority, 2nd Day Air Early
AM, 3 Day Select, Ground, Standard, First Class, Media Mail,
SurePost, Freight, and/or the like. The shipping data may include
information about the party shipping the item (e.g., consignor),
such as the party's address, the party's phone number, the party's
return address, the party's name, and/or the like. The shipping
data may also include information about the customer to whom the
item is to be delivered (e.g., consignee), such as the customer's
address (e.g., delivery location), the customer's phone number, the
customer's name, and/or the like.
[0047] In one embodiment, the shipping data may include information
about the item itself and any tracking information. The tracking
information may reflect the item's movement in the carrier's
transportation network, including expected pickup or delivery date
and time. To reflect the item's movement, an item/shipment
identifier and/or a customer-defined handling identifier associated
with the item may be scanned or otherwise electronically read at
various points as the item is transported through the carrier's
transportation network. For example, the unique item/shipment
identifier, the carrier-assigned customer identifier, and/or the
customer-defined handling identifier may be automatically scanned
by a barcode or MaxiCode device, an RFID interrogator, by a camera
controller, or by a carrier employee using a handheld device (e.g.,
mobile station 105). In one embodiment, each time the unique
item/shipment identifier is scanned or read, an appropriate device
can transmit the unique item/shipment identifier and other
appropriate information (e.g., location and time of the scan or
reading) to the carrier system 100. The carrier system 100 can then
receive and use the information to track the item as it is
transported though the carrier's transportation network and update
the shipping data accordingly.
[0048] In one embodiment, the carrier system 100 can use the
shipping data, the unique item/shipment identifier, and/or the
customer-defined handling identifier to identify one or more
customer profiles corresponding to the item (e.g., via the
identification module 245). With regard to using shipping data,
each customer profile may include one or more addresses associated
with the customer. Thus, when the carrier system 100 receives
shipping data (or a portion of shipping data) for an item (Block
410 of FIG. 4), the carrier system 100 can automatically determine
whether the item corresponds to any customers enrolled/registered
for a customer pickup, delivery, and/or returns program. In
particular, the carrier system 100 can use the delivery address of
the intended recipient (e.g., consignee) in the shipping data for
an item to identify any customer profiles with a substantially
similar delivery address (Block 415 of FIG. 4). For example, if the
shipping data of an item indicates that the delivery address of the
intended recipient is 105 Main St., Atlanta, Ga. 30309, the carrier
system 100 may identify Joseph Brown's customer profile as
corresponding to the item even though the address in Joseph Brown's
profile is 105 Main Street, Atlanta, Ga. 30309, USA. In other
words, in making such determinations, the carrier system 100 can
accommodate variations for a given address. As will be recognized,
the carrier system 100 may be configured to compensate for various
discrepancies.
[0049] In one embodiment, as a secondary measure, the carrier
system 100 can use the delivery name of the intended recipient
(e.g., consignee) in the shipping data to confirm that the
identified customer profile is correct. To do so, the carrier
system 100 may compare the delivery name of the intended recipient
in the shipping data to the primary name and/or any aliases in the
identified customer profile. If the names are substantially
similar, the carrier system 100 can confirm that the identified
customer profile is correct. By way of example, if the shipping
data indicates that the delivery name of the intended recipient is
Joe Brown and Joseph Brown listed Joe as a first name alias, the
carrier system 100 could confirm Joseph Brown's customer profile as
corresponding to the item. As will be recognized, a variety of
other approaches and techniques can be used to identify a customer
profile corresponding to at least one item to be delivered by the
carrier.
[0050] As will be recognized, a variety of techniques and
approaches can be used to adapt to various needs and circumstances.
For example, in one embodiment, the customer-defined handling
identifier and/or the carrier-assigned customer identifier may be
used to identify the corresponding customer from or to whom items
are being shipped. Similarly, the unique item/shipment identifier
may be used for similar purposes.
[0051] In one embodiment, after identifying the appropriate
customer profile (e.g., based on the shipping data, the
carrier-assigned customer identifier, the unique item/shipment
identifier, and/or the customer-defined handling identifier), the
carrier system 100 can associate the shipping data with the
customer profile (Block 420 of FIG. 4). This may include appending
the shipping data with the appropriate carrier-assigned customer
identifier (or other identifier corresponding to the customer
profile). For instance, the shipping data for all shipments
corresponding to Joseph Brown's customer profile may be appended
with the carrier-assigned customer identifier (or other identifier)
created for Joseph Brown. In various embodiments, using this
approach allows items (and their shipping data) to be linked to
appropriate customer profiles. Thus, when Joseph Brown accesses his
account, he can view all of his shipments (e.g., those shipments
with shipping data appended with his carrier-assigned customer
identifier (or other identifier)). Similarly, any actions selected
by the customer for an item can be passed to the shipping data for
the item.
3. Item Tracking
[0052] In one embodiment, by appending the shipping data with the
appropriate carrier-assigned customer identifier, the corresponding
customer can view tracking information for any shipments associated
with the customer profile. For instance, as shown in FIGS. 10-12,
the carrier system 100 can be used to identify (e.g., retrieve the
shipping data with the appropriate carrier-assigned customer
identifier) all shipments associated with a customer (e.g.,
customer profile) using the carrier-assigned customer identifier
(and/or item/shipment identifier and/or a customer-defined handling
identifier) and provide them to the customer for viewing in a
customer-friendly format, such as via an interface (e.g., browser,
dashboard, application). For example, FIG. 10 shows an interface
(e.g., browser, dashboard, application) with a list of all inbound
shipments to a customer. FIG. 11 shows an interface (e.g., browser,
dashboard, application) with a calendar (which may have a day view,
a week view, a multiple week view, and/or a month view) having a
list of all inbound shipments to a customer. In FIG. 11, the
calendar is sorted by delivery address, indicating that the
customer has more than one delivery address associated with the
customer profile. FIG. 12 shows another an interface (e.g.,
browser, dashboard, application) with a list of all inbound
shipments to a customer. As will be recognized, a variety of other
approaches and techniques can be used to adapt to various needs and
circumstances, such as only displaying the deliveries for a defined
time period (e.g., the past 90 days)
[0053] In various embodiments, these concepts can provide customers
with ongoing visibility of all inbound packages (e.g., FIGS. 10,
11, and 12), as well as preferences, regardless of carrier. Such
multi-carrier techniques are described in U.S. Publ. No.
20130024525, which is incorporated herein in its entirety. For
instance, for each item, the interface (e.g., browser, dashboard,
application) can be used to show the unique item/shipment
identifier, the customer-defined handling identifier, the
carrier-assigned customer identifier, the item price, the shipping
cost, the order number, the order date, a status indicator, a
pickup or delivery indicator, last activity scan date, a
non-confirmed pickup or delivery window, a confirmed pickup or
delivery window a commit time, whether an in-person signature is
requested for delivery, a pickup or delivery service level, and/or
various other information. Thus, through such an interface (e.g.,
browser, dashboard, application), customers (e.g., operating
customer computing devices 110/120) can review and access all
inbound shipments (from one or more carriers) using a single
interface. As will be recognized, though, a variety of other
approaches and techniques can be used to provide tracking
information to a customer.
4. Messages/Alerts
[0054] In one embodiment, the interface (e.g., browser, dashboard,
application) in communication with the carrier system 100 can be
used to customize and/or provide communication preferences
regarding items to be delivered to customers (shown in FIG. 13).
For example, the communication preferences may provide customers
with the ability to request messages, alerts, notifications, and/or
similar words used herein interchangeably at various stages of the
delivery and reverse logistics cycles. In the returns context, such
messages can be used to address the challenge of operational
planning for "lumpy" return volume and to reduce end-to-end cycle
times for processing recovered assets.
[0055] In one embodiment, as shown in FIG. 14, a customer (e.g.,
operating a consignee computing device 110 or consignor computing
device 120) can identify one or more communication formats for
communicating with the customer. The communication formats may
include text messages (e.g., Short Message Service (SMS) and/or
Multimedia Messaging Service (MMS), email messages, voice messages,
and/or a variety of other messages in various communication
formats. In addition to identifying one or more communication
formats, the customer (e.g., operating a consignee computing device
110 or consignor computing device 120) can identify the
corresponding electronic destination addresses to be used in
providing information regarding items to be delivered to the
customer. For instance, for text messages, the customer may provide
one or more cellular phone numbers. For email messages, the
customer may provide one or more email addresses. And for voice
messages, the customer may provide one or more cellular or landline
phone numbers. Additionally, in one embodiment, validation
operations can be performed with respect to each input destination
address--to ensure their accuracy. As will be recognized, a variety
of other types of destination addresses can be used to adapt to
various needs and circumstances.
[0056] In one embodiment, customers (e.g., operating a consignee
computing device 110 or consignor computing device 120) may
indicate the type of messages they want to receive (e.g., the
content). For example, a customer may indicate that he only wants
to receive messages when the shipping data for an item indicates
that an in-person signature from the customer is requested for
delivery of the item, when the pickup or delivery options for the
item can be changed, when instructions for pickup or delivery of
the item can be provided, or when the pickup or delivery service
level of the item can be changed. In another example, a customer
may indicate that he wants to receive messages for all items to be
delivered to the customer with expected delivery dates and delivery
times. In yet another example, a customer may indicate that it
wants to receive message for returns that have been authorized for
return, sorted, consolidated, shipped, repaired, refurbished,
recycled, disposed of, and/or the like. As will be recognized,
customers may indicate that they want to receive messages regarding
items in a variety of other circumstances.
[0057] In one embodiment, customers (e.g., operating a consignee
computing device 110 or consignor computing device 120) may
identify/define time periods in which the messages providing
information regarding items to be delivered should be transmitted
to the customer (e.g., including real-time or near real-time). For
instance, the time periods may include (a) after shipment and the
day before an item is delivered and (b) after shipment and the
morning of the day of delivery. In such cases, the messages can
serve as a reminder to the customer that an item is being
delivered. Similarly the time periods may be after delivery for
confirmation of delivery. The carrier system 100 can store
communication preferences for providing information in association
with the customer profiles. Moreover, the communication preferences
may apply to the customer profile globally, to selected customer
addresses, to groups of items, and/or on an item-by-item basis.
[0058] In one embodiment, customers (e.g., operating a consignee
computing device 110 or consignor computing device 120) may
identify/define triggering events (e.g., one or more parameters)
for which the messages providing information regarding items should
be transmitted to the customer (e.g., including real-time or near
real-time). For instance, the triggering events (e.g., one or more
parameters) may be generating a label or receipt for returning an
item, authorizing an item for return, receiving/collecting an item
from a consignor for induction into the carrier's transportation
and logistics network, sortation and/or consolidation of items as
defined by a customer-defined handling identifier for returns,
delivery of items to intermediate or final delivery points, after a
repair has been started or completed for an item, and/or the like.
The carrier system 100 can store such communication preferences for
providing information in association with the customer profiles.
Moreover, the communication preferences may apply to the customer
profile globally, to selected customer addresses, to groups of
items, and/or an item-by-item basis.
[0059] In one embodiment, the carrier system 100 may impose time
constraints for placing, generating, and/or transmitting messages
within the time periods identified by the customers. For example,
the carrier system 100 may only transmit text messages to customers
between 6:00 am-11:00 pm (based on time zones). Similarly, the
carrier system 100 may place calls and transmit automated voice
messages between 8:00 am-9:00 pm (based on time zones). And for
email messages, the carrier system 100 may generate and transmit
them without time constraints.
[0060] In one embodiment, the carrier system 100 can automatically
generate (e.g., via the message module 260) one or more messages
providing information regarding an item to be delivered to the
customer (Block 425 of FIG. 4) in compliance with the customer's
communication preferences and/or the carrier's time constraints.
Similarly, the carrier system 100 can automatically transmit the
one or more messages to the electronic destination addresses in
compliance with the customer's communication preferences and the
carrier's time constraints. For example, the carrier system 100 may
generate (including select) and transmit an email message to Joseph
Brown's email address and a text message to Joseph's cellular phone
the day before an item is to be delivered to Joseph's home address.
The messages may indicate the expected delivery date and/or
delivery time, such as shown in FIGS. 15A and 15B, and a variety of
other information. Similarly, the carrier system 100 can transmit
notification messages to Amazon, for example, when corresponding
triggering events (e.g., one or more parameters) for returns occur.
As will be recognized, a variety of other operations and processes
may be used with embodiments of the present invention. These
operations and processes can be customized to adapt to various
needs and circumstances.
5. Pickup/Delivery Times
[0061] In one embodiment, the interface (e.g., browser, dashboard,
application) can be used to view expected pickup or delivery times
(estimate pickup or delivery windows and/or confirmed pickup or
delivery windows). In one embodiment, estimated time windows may
indicate an estimated pickup or delivery time of an item based on
historical pickup or delivery times to the area. Such information
may be included in messages to customers prior to the first pickup
or delivery attempt. As shown in FIG. 13, the interface (e.g.,
browser, dashboard, application) may also be used by the customer
(e.g., operating an appropriate customer computing device 110/120)
to request that items be delivered within a delivery window. That
is, the customer may want an item delivered within a specific time
window. The carrier may provide such services as part of a customer
pickup, delivery, and/or returns program or on a fee basis, as
shown in FIGS. 16 and 17. Table 2 below provides illustrative
estimated delivery windows and confirmed pickup or delivery windows
from which the customer can select to have an item picked up or
delivered.
TABLE-US-00002 TABLE 2 Estimated Windows Confirmed Windows 11:45
am-3:45 pm 11:45 am-1:45 pm 12:45 pm-2:45 pm 1:45 pm-3:45 pm 11:30
am-3:30 pm 11:30 am-1:30 pm 12:30 pm-2:30 pm 1:30 pm-3:30 pm 2:00
pm-5:45 pm 2:00 pm-4:00 pm 3:45 PM-5:45 pm 1:00 pm-4:15 pm 1:00
pm-3:00 pm 2:15 pm-4:15 pm 8:00 am-11:00 pm 8:00 am-10:00 am 9:00
am-11:00 am 3:00 pm-6:00 pm 3:00 pm-5:00 pm 4:00 pm-6:00 pm 3:00
pm-5:45 pm 3:00 pm-5:00 pm 3:45 pm-5:45 pm 4:00 pm-6:00 pm 4:00
pm-6:00 pm
[0062] Additional information regarding estimated delivery windows
and confirmed delivery windows can be found in U.S. Pat. No.
6,701,299, U.S. Pat. No. 7,233,907, and U.S. Pat. No. 7,925,524,
all of which are incorporated herein in their entireties by
reference. As will be recognized, a variety of other operations and
processes may be used with embodiments of the present invention.
These operations and processes can be customized to adapt to
various needs and circumstances.
6. Electronic Authorization for Item Release
[0063] In one embodiment, consignors, consignees, and/or the
carrier may request that a recipient's signature be obtained at the
point of delivery for certain items. In-person signature requests
may be for high-value and/or high-risk items, such as cellular
phones, computers, narcotic medications, and/or a variety of other
items. Similarly, in-person signature requests may be designated by
the carrier for items being delivered in non-driver release areas.
A non-driver release area may be an area in which items have been
stolen after being left at the delivery location (e.g., not
delivered to a person) and/or for various other reasons. The
following describes two separate approaches for delivering such
packages without in-person signatures.
A. Electronic Authorization for Item Release
[0064] In one embodiment, items that are shipped with a request for
an in-person signature at the point of delivery may have a
non-driver release status. The non-driver release status may be
indicated in the shipping data. For example, the shipping data for
an item may indicate that an in-person signature from a recipient
(e.g., customer or representative of the customer) is requested for
delivery of the item. In one embodiment, such information may be
displayed via the interface (e.g., browser, dashboard,
application)--shown in FIG. 13. For instance, the shipping data for
the item represented in FIG. 13 indicates that an in-person
signature is requested for delivery of the item. In addition to an
in-person signature, in this example, payment of $25.00 is also
needed for delivery.
[0065] In one embodiment, the customer (e.g., operating a consignee
computing device 110 or consignor computing device 120) may
electronically authorize delivery of the item without an in-person
signature. To do so, the customer (e.g., operating a consignee
computing device 110 or consignor computing device 120) may
electronically authorize release of the item without an in-person
signature through the interface (e.g., browser, dashboard,
application) in communication with the carrier system 100, for
example. Operatively, in one embodiment, the customer (e.g.,
operating a consignee computing device 110 or consignor computing
device 120) may select a hyperlink (e.g., shown in FIG. 13) that
reads "Authorize Shipment Release." After (e.g., in response to)
the carrier system 100 receives the request to authorize shipment
release, the carrier system 100 can provide the appropriate
information via the interface (e.g., browser, dashboard,
application) for the customer. For instance, as shown in FIG. 18,
the carrier system 100 may provide an interface (e.g., browser,
dashboard, application displayed via a consignor/consignee
computing device) that provides a disclaimer for delivering the
item without an in-person signature (e.g., delivering the item by
leaving it at a front door of a house). The interface (e.g.,
browser, dashboard, application) may require the customer to check
a box, type in his name, and/or perform other affirmative steps.
The appropriate customer computing device 110/120 can then transmit
the input authorization to the carrier system 100. The carrier
system 100 can then receive the input authorization to deliver the
item without an in-person signature (Block 430 of FIG. 4). After
(e.g., in response to) receiving the authorization, the carrier
system 100 can update the shipping data to reflect that the item
can now be delivered without an in-person signature at the point of
delivery.
[0066] In certain embodiments, an electronic authorization may have
the same effect as an in-person signature at the point of the
delivery. Such electronic signatures may apply to the customer
profile globally (e.g., allowing all items for a particular address
to be delivered without in-person signatures), to selected customer
addresses, to groups of items, and/or an item-by-item basis. Such
authorizations may be provided prior to the first delivery attempt
by the carrier, further streamlining carrier operations and
increasing customer satisfaction.
[0067] In addition to providing for electronic authorization to
release items, the carrier system 100 can provide for payment of
items so that cash-on-delivery items do not require an in-person
transaction for delivery. As will be recognized, a variety of other
operations and processes may be used with embodiments of the
present invention. These operations and processes can be customized
to adapt to various needs and circumstances.
B. Automatic Electronic Authorization for Item Release
[0068] In one embodiment, an interface (e.g., browser, dashboard,
application) in communication with the carrier system 100 can be
used to automatically authorize delivery of items without in-person
signatures even when the corresponding shipping data indicates that
in-person signatures are requested for delivery. For example, the
customer (e.g., operating a consignee computing device 110 or
consignor computing device 120) may access the interface (e.g.,
browser, dashboard, application) in communication with the carrier
system 100 to provide authorization to allow all (or select) items
to be delivered without in-person signatures even when the
corresponding shipping data indicates that in-person signatures are
requested for delivery.
[0069] Operatively, in one embodiment, the customer (e.g.,
operating a consignee computing device 110 or consignor computing
device 120) may select a hyperlink (e.g., shown in FIG. 13) that
reads "Authorize All Shipment Release." After (e.g., in response
to) the carrier system 100 receives the request to authorize the
release of all (or select) items, the carrier system 100 can
provide the appropriate information via the interface (e.g.,
browser, dashboard, application) for the customer. For instance, as
shown in FIG. 18, the carrier system 100 may provide an interface
(e.g., browser, dashboard, application displayed via a
consignor/consignee computing device) that provides a disclaimer
for delivering the items without in-person signatures (e.g.,
delivering the item by leaving it at a front door of a house). The
interface (e.g., browser, dashboard, application) may require the
customer to check a box, type in his name, and/or perform other
affirmative steps to properly acknowledge consent. The appropriate
customer computing device 110/120 can then transmit the input
authorization to the carrier system 100. The carrier system 100 can
then receive the input authorization to deliver the items without
in-person signatures (Block 430 of FIG. 4). After (e.g., in
response to) receiving the authorization, the carrier system 100
can update the customer profile to reflect that the items with
corresponding shipping data indicating that in-person signatures
are requested for delivery can be delivered without in-person
signatures. This feature can be configured for items that have yet
to be purchased, shipped, or delivered (e.g., for future
transactions).
[0070] Thus, when an item to be delivered to the customer is
matched to the customer profile and has corresponding shipping data
indicating that an in-person signature is requested for delivery,
the carrier system 100 can automatically change the corresponding
shipping data to reflect that the item can be delivered without an
in-person signature (e.g., based on the customer profile). In
certain embodiments, this may require applying a new item/shipment
identifier and/or label. For example, the carrier system 100 can
transmit to the appropriate mobile stations 105 (and/or other
computing entities) updated shipping data indicating that the item
can be delivered without an in-person signature. In one embodiment,
the appropriate mobile stations 105 (and/or other computing
entities) can receive the updated shipping data. Then, when carrier
personnel sorting items or loading delivery vehicles, for example,
scan the unique item/shipment identifier (e.g., using a mobile
station 105), the mobile station 105 can provide the carrier
personnel with an indication that the item can be delivered without
an in-person signature. This may include indicating that a new
label (and/or item/shipment identifier) needs to be affixed to the
item. The item can then be transported and delivered with the new
label by the carrier and delivered without requiring an in-person
signature.
[0071] In another embodiment, this feature may also require that
items satisfy certain criteria in order to automatically allow an
item to be delivered without an in-person signature. For example,
the customer may indicate that only items originating from
identified consignors (e.g., Amazon, Lands' End, William Robinson,
etc.) can be delivered without in-person signatures. In this
example, customer Joseph Brown can update his customer profile such
that all items to be delivered to him that originate from Lands'
End are to be delivered without in-person signatures. Thus, as
described above, in this example, all items to be delivered to
Joseph Brown originating from Lands' End can be delivered without
in-person signatures (if they were originally requested). As will
be recognized, a variety of other approaches and techniques can be
used to adapt to various needs and circumstances.
[0072] In various embodiments, the carrier may include such
services as part of a customer pickup, delivery, and/or returns
program and/or require a fee on a transaction basis. Moreover, a
variety of other operations and processes may be used with
embodiments of the present invention. For example, such features
can be used in conjunction with customer and item matching
features, item tracking features, messaging features, delivery time
features, instructions for delivery features, delivery option
features, and/or the like. Thus, these operations and processes can
be customized to adapt to various needs and circumstances.
7. Instructions for Pickup or Delivery
[0073] In one embodiment, pickup or delivery persons working for a
carrier (and other carrier personnel) may carry and operate mobile
stations 105 to assist in the pickup or delivery of items. For
example, shipping data (or at least a portion of shipping data)
corresponding to items to be delivered can be transmitted
regularly, periodically, continuously, and/or on demand to the
appropriate mobile stations 105. Thus, for instance, carrier
personnel can scan an item/shipment identifier on an item (e.g.,
using a mobile station 105) to view information about the pickup or
delivery of the item. The mobile station 105 may also be used to
provide instructions for pickup or delivery to carrier personnel.
The instructions may include information, such as where an item
should be left at a delivery location and/or access codes needed to
pick up or deliver an item. The pickup or delivery person can also
use the mobile station 105 to record information about the pickup
or delivery of the item, such as where and at what time the item
was picked up or delivered.
[0074] As will be recognized, in one embodiment, an interface
(e.g., browser, dashboard, application) in communication with the
carrier system 100 (e.g., via the delivery options module 250) can
be used to provide instructions regarding items to be delivered to
customers (e.g., prior to a delivery attempt by the carrier). For
example, the customer (e.g., operating a consignee computing device
110 or consignor computing device 120) may access the interface
(e.g., browser, dashboard, application) to view items to be
delivered. The interface (e.g., browser, dashboard, application)
may also provide the customer with the option of providing
instructions for delivering one or more items.
[0075] In one embodiment, to provide such instructions, the
customer (e.g., operating a consignee computing device 110 or
consignor computing device 120) may select a button (e.g., shown in
FIG. 13) that reads "Provide Delivery Instructions." After (e.g.,
in response to) the carrier system 100 receives the request to
provide instructions, the carrier system 100 can provide the
information to the customer via an appropriate interface (e.g.,
browser, dashboard, application). For instance, as shown in FIGS.
19A, 19B, and 20, the carrier system 100 may provide an interface
(e.g., browser, dashboard, application) to the customer (e.g.,
displayed via an appropriate customer computing device 110/120)
that provides the ability to input (e.g., via an input form) one or
more instructions for using a code to enter an area proximate the
pickup or delivery address, such as building code(s), door code(s),
and/or gate code(s). The carrier system 100 may also provide an
interface (e.g., browser, dashboard, application) to the customer
(e.g., displayed via an appropriate customer computing device
110/120) that provides the ability to input (e.g., via a drop-down
menu) one or more instructions that identify a location at the
delivery address at which the item should be left. Table 3 below
provides illustrative instructions and corresponding codes.
TABLE-US-00003 TABLE 3 Leave-At Instructions Optional Leave at -
Front Door Security Code to Access Front Door Leave at - Rear Door
Security Code to Access Rear Door Leave at - Side Door Security
Code to Access Side Door Leave at - Garage Security Code to Access
Garage Leave at - Porch Security Code to Access Porch Leave at -
Deck Security Code to Access Deck Leave at - Patio Security Code to
Access Patio Leave at - Reception Security Code to Access Reception
Leave at - Management Office Security Code to Access Office Leave
at - Door Person Security Code to Reach Door Person Leave at -
Neighbor Security Code for Neighbor
[0076] In one embodiment, as indicated in Block 435 of FIG. 4, the
carrier system 100 can receive the one or more instructions for
delivery (e.g., before a first delivery attempt). After (e.g., in
response to) receiving the one or more instructions for delivery,
the carrier system 100 can update the shipping data to reflect that
the item should be delivered in accordance with the one or more
instructions. The updated shipping data (or at least a portion of
updated shipping data) can be transmitted regularly, periodically,
continuously, and/or on demand by the carrier system 100 to the
appropriate mobile stations 105. The appropriate mobile station 105
can receive the updated shipping data (or at least a portion of
updated shipping data). Then, a delivery person can scan an
item/shipment identifier on an item (e.g., using a mobile station
105) to view information about the delivery of the item, and the
updated shipping data (or at least a portion of updated shipping
data) can be displayed, including the one or more instructions for
delivery. The delivery person can then deliver the item in
accordance with the one or more instructions for delivery. For
instance, as shown in FIG. 21. The instructions may be to leave an
item at a rear door at a delivery location and further provide a
gate code needed to access the rear door. A variety of other
instructions for pickup or delivery can be provided as well.
[0077] As will be recognized, the one or more instructions for
pickup or delivery may apply to the customer profile globally
(e.g., providing that all items be delivered in accordance with the
instructions), to selected customer addresses, to groups of items,
and/or an item-by-item basis. As indicated, such instructions may
be provided prior to the first delivery attempt by the carrier.
Moreover, a variety of other operations and processes may be used
with embodiments of the present invention. These operations and
processes can be customized to adapt to various needs and
circumstances. For instance, the carrier may include such services
as part of a customer pickup, delivery, and/or returns program
and/or require a fee.
8. Pickup/Delivery Options
[0078] In one embodiment, as described, shipping data (or at least
a portion of shipping data) corresponding to items to be delivered
can be transmitted regularly, periodically, continuously, and/or on
demand by the carrier system 100 to the appropriate mobile stations
105. Thus, for instance, carrier personnel can scan an
item/shipment identifier on an item (e.g., using a mobile station
105) to view, access, provide, and/or retrieve information about
the item or pickup or delivery of the item. In one embodiment,
shipping data can be updated to change pickup or delivery options,
such as changing the pickup or delivery location, the pickup or
delivery date, the pickup or delivery time, and/or the pickup or
delivery service level.
A. Non-Vacation Delivery Options
[0079] In one embodiment, an interface (e.g., browser, dashboard,
application) in communication with the carrier system 100 (e.g.,
via the delivery options module 250) can be used to change delivery
options regarding items to be delivered to customers (e.g., prior
to a delivery attempt by the carrier). For example, the customer
(e.g., operating a consignee computing device 110 or consignor
computing device 120) may access the interface (e.g., browser,
dashboard, application) in communication with the carrier system
100 to view items to be delivered. The interface (e.g., browser,
dashboard, application) may provide the customer with the option of
changing delivery options for one or more items.
[0080] In one embodiment, to change delivery options, the customer
(e.g., operating a consignee computing device 110 or consignor
computing device 120) may select a button (e.g., shown in FIG. 13)
that reads "Change Delivery." After (e.g., in response to) the
carrier system 100 receives the request to change delivery options,
the carrier system 100 can provide the information to the customer
via an appropriate interface (e.g., browser, dashboard,
application). For instance, as shown in FIG. 22, the carrier system
100 may provide an interface (e.g., browser, dashboard,
application) to the customer (e.g., displayed via an appropriate
customer computing device 110/120) that provides the ability to
change delivery options. The delivery options may allow the
customer to request to have the item held at a carrier facility for
pick up (e.g., will call or same day will call). The delivery
options may allow the customer to request to reschedule delivery of
the item for another date and/or time (e.g., a future date and
time). The delivery options may allow the customer to change the
delivery service level of the item (e.g., change the delivery
service level from Ground to 2nd Day Air or Ground to SurePost)
after the item has been shipped. In one embodiment, this may allow
for the item to be delivered earlier than initially indicated
(e.g., both date and time). The delivery options may allow the
customer request to change the delivery location to a carrier
facility (or other location), such as a UPS Store. And the delivery
options may allow the customer to request to return the item to the
consignor. As will be recognized, embodiments of the present
invention may also allow a customer to change a variety of other
delivery options.
[0081] In one embodiment, as indicated in Block 435 of FIG. 4, the
carrier system 100 can receive the changed delivery options as
input from the customer. After (e.g., in response to) the changed
delivery options, the carrier system 100 can accept the requested
changes (e.g. including validating the changes). The carrier system
100 can then update the shipping data to reflect that the item
should be delivered in accordance with the changed delivery
options. In one embodiment, the change in delivery options may
require applying a new item/shipment identifier and/or label. For
example, as described, the updated shipping data (or at least a
portion of updated shipping data) corresponding to items to be
delivered can be transmitted regularly, periodically, continuously,
and/or on demand by the carrier system 100 to the appropriate
mobile stations 105 (and/or other computing entities).
[0082] In one embodiment, the appropriate mobile stations 105
(and/or other computing entities) can receive the updated shipping
data (or at least a portion of updated shipping data) corresponding
to items to be delivered. Thus, carrier personnel sorting items or
loading delivery vehicles can scan an item/shipment identifier
(e.g., using a mobile station 105) on an item to view information
about the delivery of the item, and the updated shipping data (or
at least a portion of updated shipping data) can be displayed. The
updated shipping information may indicate that a new label (and/or
item/shipment identifier) needs to be affixed to the item (e.g.,
the new label may indicate the new delivery address). The item can
then be delivered in accordance with the changed delivery
options.
[0083] In various embodiments, the carrier may include such
services as part of a customer pickup, delivery, and/or returns
program and/or require a fee. As indicated, in one embodiment, the
delivery options may be changed prior to the first delivery attempt
by the carrier. Moreover, a variety of other operations and
processes may be used with embodiments of the present invention.
These operations and processes can be customized to adapt to
various needs and circumstances.
B. Vacation Delivery Options
[0084] In one embodiment, an interface (e.g., browser, dashboard,
application) in communication with the carrier system 100 (e.g.,
via the delivery options module 250) can be used to change delivery
options regarding items to be delivered to customers while the
customers are on vacation (or otherwise away from the delivery
location, such as being out of town on a business trip). For
example, a customer (e.g., operating a consignee computing device
110 or consignor computing device 120) may access the interface
(e.g., browser, dashboard, application) in communication with the
carrier system 100 to input delivery options while the customer is
on vacation.
[0085] In one embodiment, to input such delivery options, the
customer (e.g., operating a consignee computing device 110 or
consignor computing device 120) may select a button (e.g., shown in
FIG. 23) that reads "Add a Vacation." After (e.g., in response to)
the carrier system 100 receives the request to add a vacation, the
carrier system 100 can provide the information to the customer via
an appropriate interface (e.g., browser, dashboard, application).
For instance, as shown in FIGS. 24, 25, 26A, and 26B, the carrier
system 100 may provide an interface (e.g., browser, dashboard,
application) to the customer (e.g., displayed via an appropriate
customer computing device 110/120) that provides the ability to
input vacation dates and/or delivery options (e.g., the delivery
location, the delivery date, and/or the delivery time). During the
vacation time period, the delivery options may allow the customer
to request to have items held at a carrier facility for will call
or to be rescheduled for delivery on another date. Similarly,
during the vacation time period, the delivery options may allow the
customer to request to have all items delivered to a carrier
facility, such as a UPS Store.
[0086] In one embodiment, as indicated in Block 435 of FIG. 4, the
carrier system 100 can receive the input vacation dates and/or
delivery options. After (e.g., in response to) receiving the input
vacation dates and/or delivery options, the carrier system 100 can
apply the vacation delivery options to all items to be delivered to
the customer (and/or one of the customer's addresses in his
customer profile) during the vacation time period. For instance, as
shown in FIG. 26A, all items to be delivered to a customer between
Jul. 5, 2011 and Jul. 11, 2011 can be rescheduled for delivery on
Jul. 12, 2011. Similarly, as shown in FIG. 26B, all items to be
delivered to a customer between Jul. 5, 2011 and Jul. 11, 2011 can
be delivered to a carrier facility (such as a UPS Store) for later
pickup by the customer. In one embodiment, vacation options may
require applying a new label (and/or item/shipment identifier) to
items to be delivered during the vacation time period.
C. Change in Pickup or Delivery Service Level
[0087] In one embodiment, an interface (e.g., browser, dashboard,
application) in communication with the carrier system 100 can be
used to change pickup or delivery service levels for items to be
picked up from or delivered to customers. For example, the customer
(e.g., operating a consignee computing device 110 or consignor
computing device 120) may access the interface (e.g., browser,
dashboard, application) in communication with the carrier system
100 to view items to be delivered. The interface (e.g., browser,
dashboard, application) may provide the customer with the option of
changing the delivery service levels for one or more items (e.g.,
change the delivery service level from Ground to 2nd Day Air or
from Ground to SurePost).
[0088] In one embodiment, to change the delivery service level for
an item, the customer (e.g., a customer or customer representative
operating a consignee computing device 110 or consignor computing
device 120) may select a button, icon, or graphic (similar to FIG.
13, although not shown in FIG. 13) that reads "Change Service
Level." After (e.g., in response to) the carrier system 100
receives the request to change the delivery service level, the
carrier system 100 can provide the appropriate information via the
interface (e.g., browser, dashboard, application) to the customer.
For instance, the carrier system 100 may be in communication with
an interface (e.g., browser, dashboard, application displayed via a
consignor/consignee computing device) that provides the ability to
change the delivery service level. For example, this may allow the
customer to change the delivery service level from SurePost to
Ground, from Ground to 2nd Day Air, from 2nd Day Air to Next Day
Air, from 2nd Day Air to Ground, and/or the like. Thus, the
delivery service level can be changed from a first delivery service
level with which it was originally shipped to a second delivery
service level (after the item has been shipped but) prior to the
first delivery attempt of the item. In one embodiment, this may
allow for the item to be delivered earlier or later than initially
indicated (e.g., both date and time).
[0089] In one embodiment, as indicated in Block 435 of FIG. 4, the
carrier system 100 can receive the request to change the delivery
service level as input from the customer. After (e.g., in response
to) receiving such a request, the carrier system 100 can accept the
requested changes (e.g. including validating the changes). The
carrier system 100 can then update the shipping data to reflect
that the item should be delivered in accordance with the second
(e.g., changed) delivery service level, which may automatically
change the delivery date and/or cost associated with delivering the
item. In one embodiment, the change in the delivery service level
may require applying a new item/shipment identifier and/or label.
For example, as described, the updated shipping data (or at least a
portion of updated shipping data) corresponding to items to be
delivered can be transmitted regularly, periodically, continuously,
and/or on demand by the carrier system 100 to the appropriate
mobile stations 105 (and/or other computing entities).
[0090] In one embodiment, the appropriate mobile stations 105
(and/or other computing entities) can receive the updated shipping
data (or at least a portion of updated shipping data) corresponding
to items to be delivered. Thus, carrier personnel sorting items or
loading delivery vehicles can scan an item/shipment identifier
(e.g., using a mobile station 105) on an item to view information
about the delivery of the item, and the updated shipping data (or
at least a portion of updated shipping data) can be displayed. The
updated shipping information may indicate that a new label (and/or
item/shipment identifier) needs to be affixed to the item (e.g.,
the new label may indicate the new delivery service level). The
item can then be transported and delivered with the new label by
the carrier in accordance with the second (e.g., changed) delivery
service level.
[0091] In various embodiments, the carrier may include such
services as part of a customer pickup, delivery, and/or returns
program and/or require a fee on a transaction basis. As indicated,
in one embodiment, the delivery options may be changed prior to the
first delivery attempt by the carrier. Moreover, a variety of other
operations and processes may be used with embodiments of the
present invention. For example, changing the delivery service level
feature can be used in conjunction with other features described
herein, such as customer and item matching features, item tracking
features, messaging features, delivery time features, electronic
authorization for item release features, instructions for delivery
features, and/or delivery option features. Thus, these operations
and processes can be customized to adapt to various needs and
circumstances.
D. Automatic Change in Pickup or Delivery Service Level
[0092] In one embodiment, an interface (e.g., browser, dashboard,
application) in communication with the carrier system 100 can be
used to automatically change pickup or delivery service levels for
items to be picked up from or delivered to customers. For example,
the customer (e.g., a customer or customer representative operating
a consignee computing device 110 or consignor computing device 120)
may access the interface (e.g., browser, dashboard, application) in
communication with the carrier system 100 to view delivery service
level options for items that have yet to be purchased, shipped, or
delivered. In one embodiment, the interface (e.g., browser,
dashboard, application) may provide the customer with the option of
automatically changing the delivery service level for all (or
select) items to be delivered via a specific delivery service level
(e.g., Next Day Air, Next Day Air Early AM, Next Day Air Saver, 2nd
Day Air, 2nd Day Air Early AM, 3 Day Select, Ground, and/or
SurePost).
[0093] In one embodiment, to automatically change the delivery
service level for all (or select) items to be delivered via a
specific delivery service level, the customer (e.g., a customer or
customer representative operating a consignee computing device 110
or consignor computing device 120) may select a button, icon, or
graphic that reads "Automatic Service Level Change." After (e.g.,
in response to) the carrier system 100 receives the request to
automatically change delivery service levels, the carrier system
100 can provide the appropriate information via the interface
(e.g., browser, dashboard, application) to the customer. For
instance, the carrier system 100 may be in communication with an
interface (e.g., browser, dashboard, application displayed via a
consignor/consignee computing device) that provides the ability to
set automatic delivery service level changes for all (or select)
items to be delivered via the specific delivery service level. For
instance, the customer can input that all (or select) items to be
delivered via a first delivery service level (e.g., SurePost)
should automatically be changed to a second delivery service level
(e.g., Ground). Thus, this feature may allow the customer to
automatically change the delivery service level for all items to be
delivered via a first delivery service level to a second delivery
service level (e.g., from SurePost to Ground, from Ground to 2nd
Day Air, from 2nd Day Air to Next Day Air, from 2nd Day Air to
Ground, and/or the like). Thus, delivery service levels can be
automatically changed from a first delivery service level (used
when originally shipped) to a second delivery service level, which
may automatically change the delivery dates and/or costs associated
with delivering the item. As indicated, this may even occur after
the items have been shipped but prior to the first delivery attempt
of the items.
[0094] In one embodiment, as indicated in Block 435 of FIG. 4, the
carrier system 100 can receive the request to automatically change
the delivery service level as input from the customer. After (e.g.,
in response to) receiving such a request, the carrier system 100
can accept the requested changes (e.g. including validating the
changes). The carrier system 100 can then update the customer
profile to reflect that items to be delivered in accordance with
the first delivery service level (and/or from a specific consignor)
should be automatically changed to a second delivery service level
during transport by the carrier.
[0095] Thus, when an item to be delivered to the customer is
matched to the customer profile and is to be delivered via the
first delivery service level (e.g., SurePost), the carrier system
100 can automatically change the first delivery service level to
the second delivery service level as reflected in the customer
profile. As described, this may require applying a new
item/shipment identifier and/or label. For example, the carrier
system 100 can transmit regularly, periodically, continuously,
and/or on demand to the appropriate mobile stations 105 (and/or
other computing entities) that the first delivery service level
(e.g., SurePost) should be changed to a second delivery service
level (e.g., Ground) for the item. In one embodiment, the
appropriate mobile stations 105 (and/or other computing entities)
can receive the indication. Then, when carrier personnel sorting
items or loading delivery vehicles, for example, scan the unique
item/shipment identifier (e.g., using a mobile station 105), the
mobile station 105 can provide the carrier personnel with an
indication that the first delivery service level should be changed
to the second delivery service level. This may include indicating
that a new label (and/or item/shipment identifier) needs to be
affixed to the item (e.g., the new label may indicate the new
delivery service level). The item can then be transported and
delivered with the new label by the carrier in accordance with the
second (e.g., changed) delivery service level.
[0096] In another embodiment, this feature may also require that
items satisfy other criteria in order to automatically change the
delivery service level. For example, the customer may indicate that
only items originating from identified consignors (e.g., Amazon,
Lands' End, William Robinson, etc.) have their delivery service
levels changed automatically. In this example, customer Joseph
Brown can update his customer profile such that all items to be
delivered to him that originate from Lands' End are to be
automatically changed to the Second Day Air delivery service level
(if not already Second Day Air). Similarly, customer Joseph Brown
can update his profile such that all items originating from
identified consignors (e.g., Amazon, Lands' End, William Robinson,
etc.) and to be delivered via a first delivery service level (e.g.,
SurePost) have their delivery service level automatically changed
to a second delivery service level (e.g., Ground). In this example,
all items to be delivered to Joseph Brown via SurePost and
originating from Lands' End can be automatically changed from the
SurePost delivery service level to the Ground delivery service
level. As will be recognized, a variety of other approaches and
techniques can be used to adapt to various needs and
circumstances.
[0097] In various embodiments, the carrier may include such
services as part of a customer pickup, delivery, and/or returns
program and/or require a fee on a transaction basis. As indicated,
in one embodiment, the delivery options may be changed prior to the
first delivery attempt by the carrier. Moreover, a variety of other
operations and processes may be used with embodiments of the
present invention. For example, changing the delivery service level
feature can be used in conjunction with other features, such as
customer and item matching features, item tracking features,
messaging features, delivery time features, electronic
authorization for item release features, instructions for delivery
features, delivery option features, and/or the like. Thus, these
operations and processes can be customized to adapt to various
needs and circumstances.
9. Returns
[0098] In various embodiments, the carrier system 100, in
coordination with a variety of other computing entities, can be
used to initiate and carry out the return of items in the reverse
logistics cycle. The term "return" may refer to returning an item
(a) to a consignor; (b) to inventory managed by a carrier or
another entity; (c) for limited or full repair or refurbishment;
(d) for liquidation, recycling, destruction, donation; and/or (e)
the like. Further, in the returns context, an original or initial
consignee (e.g., first consignee) who received an item can become a
consignor (e.g., second consignor) when returning an item. Thus, an
original or initial consignor (e.g., first consignor) can also
become a consignee (e.g., second consignee).
[0099] In one embodiment, the carrier system 100 can provide or be
in communication with an interface through which a customer (e.g.,
a customer or customer representative operating a consignee
computing device 110 or consignor computing device 120) can
initiate the return of items that have been previously delivered or
are in the possession of a customer. As will be recognized, returns
may be initiated by a customer (e.g., a consignee or a consignor)
via the interface shown in FIG. 10 (showing a list of all inbound
shipments to the customer), for example. Similarly, returns may be
initiated by a customer (e.g., a customer or customer
representative operating a consignee computing device 110 or
consignor computing device 120) via the interfaces shown in FIG. 11
or 12 with a calendar or list of all inbound shipments to a
customer for the past 90 days, for example. In yet another
embodiment, a customer (e.g., a customer or customer representative
operating a consignee computing device 110 or consignor computing
device 120) can initiate a return via a carrier returns
portal/interface (e.g., browser, dashboard, application) in a
variety of ways--see FIG. 28. In one embodiment, returns may be
initiated through these and various other interfaces regardless of
by whom or how the items were delivered to the customer.
[0100] In one embodiment, there may be two types of returns:
authorized returns and unauthorized returns. Authorized returns may
be for items being returned to consignors (e.g., first consignors)
that participate in a returns program with the carrier. Through
such returns programs, consignors can ensure that carriers return
items in compliance with the consignors' return policies. For
example, through such a program, consignors can approve the returns
and pay for the shipping of the items. Such payments/refunds may be
in a variety of forms, such as via debit cards, credit cards,
direct credits, direct debits, cash, check, money order, Internet
banking, e-commerce payment networks/systems (e.g., PayPal.TM.,
Google Wallet, Amazon Payments), virtual currencies (e.g.,
Bitcoins), award or reward points, and/or the like. Such payments
may be made using a variety of techniques and approaches, including
through NFC technologies such as PayPass, Android Beam,
BlueTooth.TM. low energy (BLE), and various other contactless
payment systems. Further, such payment technologies may include
PayPal Beacon, Booker, Erply, Leaf, Leapset, Micros, PayPal Here,
Revel, ShopKeep, TouchBistro, Vend, and/or the like. Similarly,
unauthorized returns may be for items being returned to consignors
that do not participate in a returns program with the carrier. The
following describes exemplary processes for both authorized returns
and unauthorized returns.
A. Authorized Returns
[0101] For authorized returns (Block 2700 of FIG. 27), the carrier
system 100 may provide the ability to initiate/request returns via
an interface (e.g., browser, dashboard, application) provided by
the carrier on behalf of specific consignors, for example. For
instance, to offload the processing of returns for participating
consignors, the carrier system 100 can provide return merchandise
authorizations (RMA) or RMA integration with consignors (e.g., via
consignors' websites) to provide return authorizations, processing,
shipping, routing, and handling in accordance with consignors'
return policies. In one embodiment, this process with a customer
can occur remotely (e.g., via a customer accessing an online
interface) or in-person (e.g., at a carrier location or
carrier-designated location of a third party). A carrier location
may be, for example, a carrier store (e.g., UPS Store) or a carrier
kiosk, while carrier-designated locations of third parties may be
electronics stores, grocery stores, post offices of the United
States Postal Service (USPS), and/or the like. As will be
recognized, such carrier-designated locations need not be the
stores, for example, from which the items were purchased. That is,
a carrier may contract with Publix Supermarkets, for instance, to
handle all or select in-person returns for the carrier. In such an
example, customers may be able to take items to be returned to any
Publix Supermarket for processing and shipping in accordance with
the respective return policies of various consignees.
[0102] In one embodiment, the returns process may require an RMA
for a participating consignor. Thus, a user may be required to
input return item attributes regarding the return via an interface
(e.g., customer or third party operating a computing device). For
each item or groups of items being returned, the return attributes
may include a stock keeping unit (SKU) or item number, an item
class or category (e.g., apparel, consumer electronics, sports
equipment, medical devices), a return category, a reason for the
return (e.g., damaged, not wanted, duplicate, and/or the like), an
order or confirmation number from the purchase of the item, the
date the order was placed for the item, the date the item was
delivered to the consignee, the carrier that delivered the item, an
indication of whether the item is seasonal, the geographic zone of
original fulfillment (e.g., Kentucky, California), and/or the like.
In some embodiments, the customer may not need to input the return
attributes; rather, the carrier system 100 may pull, access, or
identify the return item attributes based on the order or
confirmation number, for example, by accessing the consignee's
email or communicating with the first consignors. As will be
recognized, a variety of return attributes can be used to adapt to
various needs and circumstances.
[0103] In one embodiment, to implement the return polices for
returns based on the return attributes, the consignor may define
business rules for execution by the carrier system 100 that
indicate (based on the input for the return) whether a return for
an item should be authorized. Further, if authorized, the business
rules may indicate how the item should be processed, the location
to which the item should be shipped, how the item should be
transported through the carrier's transportation and logistics
network, whether multiple items should be consolidated before
shipment, whether the item should be repaired, how carrier
personnel or those associated with the carrier should handle the
item, delivery point information, and/or the like. Further, use of
the return attributes may allow the carrier (e.g., via the carrier
system 100) to limit returns to items that are in compliance with
the corresponding consignor's return policies, such as requiring
(a) that items be returned within 30 days of delivery, (b) that
non-functioning electronics be sent directly for repair, (c) that
all returns be inspected prior to acceptance, and/or (d) the like.
As will be recognized, a variety of business rules can be used to
adapt to various needs and circumstances.
[0104] In one embodiment, if the carrier system 100 (or other
appropriate computing entity) determines that a return is in
compliance with the corresponding consignor's business rules (e.g.,
based at least in part on the return attributes), the carrier
system 100 can authorize the return. The carrier system 100 can
also assign or associate therewith an RMA number to the item being
returned. The RMA process can be used by the first consignor as a
gatekeeping process in the reverse logistics cycle.
[0105] In addition to or as an alternative to assigning to or
associating therewith an RMA number, the carrier system 100 may
determine a customer-defined handling identifier for, assign a
customer-defined handling identifier to, and/or associate a
customer-defined handling identifier (see FIGS. 29-32) with each
item or group of items being returned (Block 2705 of FIG. 27). The
customer-defined handling identifier (e.g., handling identifier)
can be used to indicate (e.g., based on the business rules
application) how the item should be processed, the available
methods of collection, the location to which the item should be
shipped, how the item should be transported through the carrier's
transportation and logistics network, whether multiple items should
be consolidated before shipment (e.g., for reduce shipping costs),
whether the item should be repaired, how carrier personnel or those
associated with the carrier should handle the item, delivery point
information, and/or the like. In one embodiment, to do so, the
customer-defined handling identifier may be an alphanumeric string
that comprises a return category portion, a collection method
portion, and a delivery point portion. Although the
customer-defined handling identifier shows the portions in a
specific order, the order and length of each portion of the
customer-defined handling identifier may vary to adapt to various
needs and circumstances. Further, the customer-defined handling
identifier may also be in the form of a barcode (see FIG. 30), a
Quick Response (QR) code (see FIG. 31), a MaxiCode, and/or the
like. The customer-defined handling identifier may also be in the
form of an RFID tag or other readable medium. Thus, the
customer-defined handling identifier may take many forms to adapt
to various needs and circumstances.
[0106] In one embodiment, as part of the collection, after the RMA
is approved, the carrier system 100 can transmit a shipping label,
a web form, a barcode, a QR code, a receipt image, and/or the like
that comprises or is associated with the RMA, a carrier-assigned
customer identifier, an item/shipment identifier, a
customer-defined handling identifier to the corresponding customer
(e.g., operating a customer computing device 110/120)--see FIG. 33.
Similarly, the carrier system 100 may also provide such information
to the original or initial consignor (e.g., second consignee). The
shipping label, web form, barcode, QR code, receipt image, and/or
the like can be used to induct the item into the carrier's
transportation and logistics network (e.g., via pickup, drop-off,
etc.), which may include picking up, dropping off, packing,
labeling, and/or beginning shipment of the item or groups of items
(Block 2710 of FIG. 27).
[0107] In one embodiment, the collection method portion may be used
to indicate the collection methods that are available for a given
consignor and/or item. For example, a first consignor may want to
restrict the potential available paths within a carrier's
transportation and logistics network to maximize the yield of the
various return categories. This may be because the various paths
within a transportation and logistics network have cost and time
implications associated therewith. For instance, the collection
methods may include or exclude carrier personnel pickup of returns,
carrier location drop-offs, carrier-designated locations for
drop-offs (e.g., grocery stores, post offices, and/or the like).
Thus, a consignor may define business rules that allow for consumer
electronics to use all the available paths for return in a
carrier's transportation and logistics network, while limiting
apparel returns to carrier locations and carrier-designated
locations. The collection methods may be defined by a customer by
SKU or item number, item class or category (e.g., apparel, consumer
electronics, sports equipment, medical devices), return category,
return code (e.g., reason for the return), return timing (e.g.,
within 30 days, 45 days, 60 days, >90 days, unknown timing),
seasonal return, geographic zone of original fulfillment (e.g.,
returns to Kentucky, California, etc.), and/or the like. As will be
recognized, a variety of collection method concepts can be used to
adapt to various needs and circumstances--including exception
handling.
[0108] Operatively, carrier personnel can scan or read (e.g., using
a mobile station 105) the customer-defined handling identifier of
an item and/or other identifying indicia associated with the item
as described herein. For instance, carrier personnel can scan or
read the shipment identifier that can be used to access the
customer-defined handling identifier. With the customer-defined
handling identifier, the carrier system 100 can determine what
collection methods are available for the item and/or whether the
collection method being used is available for the item (based at
least in part on the collection method portion). Responsive to such
a determination, the carrier system 100 can provide such an
indication for display to an appropriate computing entity.
[0109] In one embodiment, the return category portion may be used
to indicate to the carrier whether, how, and when, for example, the
items should be sorted and/or consolidated for a given consignor
(e.g., first consignor). For example, a first consignor may want to
consolidate items in specific return categories, of similar types,
during certain times of the year, or that have been damaged to be
returned in bulk (e.g., 20 or more items) or in minimum collection
numbers. To do so, the return category portion may represent the
sortation and consolidation (in accordance with the business rules)
defined by a customer. Thus, the sortation and consolidation may be
defined by a customer by SKU or item number, item class or category
(e.g., apparel, consumer electronics, sports equipment, medical
devices), return category, return code (e.g., reason for the
return), return timing (e.g., within 30 days, 45 days, 60 days,
>90 days, unknown timing), seasonal return, geographic zone of
original fulfillment (e.g., returns to Kentucky, California, etc.),
and/or the like.
[0110] In one embodiment, the carrier may simply sort and/or
consolidate items assigned to a unique return category portion
(Block 2715 of FIG. 27). For instance, all items with the same
return category portion of the customer-defined handling identifier
(e.g., consumer electronics or 7th Generation iPod nanos, sports
shirts or Nike Core Compression S/S Top 1.2 shirts, delivered
>90 days ago or delivered to zip code 30097>90 days ago) can
be sorted together. After or as a part of sortation, items with the
same return category portion for a consignor can also be
consolidated for return based on the customer-defined handling
identifier. In one example, the carrier system 100 can implement a
low level of sortation and/or consolidation, such as by using a
fixed attribute value that would prevent the separation of return
items (e.g., returns would remain in the carrier's transportation
and logistics network to be delivered (unsorted and unconsolidated)
to a delivery point). In another example, the carrier system 100
can implement a medium level of sortation and/or consolidation
using the customer-defined handling identifier, such as by having
set values for each return category to instruct carrier personnel
and/or equipment to sort and/or consolidate the return items of the
corresponding category (e.g., return items can be delivered in the
carrier's transportation and logistics network to be sorted,
consolidated, and/or aged). In yet another example, the carrier
system 100 can implement a high level of sortation and/or
consolidation, for instance, by having a link between each return
category and the contents of the return shipment (e.g., SKU level
detail). In high level of sortation and/or consolidation, the
customer-defined handling identifier can be used to change the
delivery location (e.g., having the delivery location change from
one identifier to another). Further, the returns can be sorted by
customer-defined handling identifiers with each identifier having a
different destination (e.g., based on customer and/or carrier
business rules). For instance, customer business rules could
establish the level of sorting and the locations for delivery
(customer site or carrier site). If a carrier site is to be used,
then the carrier business rules can automatically determine the
final delivery address. As will be recognized, a variety of
sortation and consolidation concepts can be used to adapt to
various needs and circumstances.
[0111] In one embodiment, as described, shipping data and/or the
various identifiers (e.g., item/shipment identifier,
carrier-assigned customer identifier, and/or customer-defined
handling identifier) corresponding to items can be transmitted
regularly, periodically, continuously, and/or on demand (e.g., in
response to certain triggers) by the carrier system 100 to the
appropriate mobile stations 105. Thus, for instance, carrier
personnel can scan or read a customer-defined handling identifier
and/or item/shipment identifier (or other identifier) on an item
(e.g., using a mobile station 105) to view, access, provide, and/or
retrieve information about the handling, processing, sorting,
and/or consolidating of the item and carry out the instructions
regarding the same. With the customer-defined handling identifier,
the carrier system 100 can determine whether and how the item
should be sorted and/or consolidated and provide such an indication
for display to an appropriate computing entity (based at least in
part on the return category portion).
[0112] In one embodiment, the delivery point portion may be used to
indicate the delivery destination/point of the item or items being
returned and/or what actions should be performed at the delivery
destination/point (see FIG. 32). For instance, in one embodiment,
the goal may be to deliver the item or items in accordance with a
consignor's business rules for yield maximization in the reverse
logistics cycle. In one embodiment, the item or groups of items may
be returned to the original vendor (e.g., the first consignor) or
to inventory managed by the carrier or another entity. In another
embodiment, the carrier may deliver the item or groups of items to
a center or facility for liquidation or resale. With regard to
liquidation and resale, the carrier system 100 may provide yield
performance metrics to the carrier and/or the original vendor
(e.g., first consignor) regarding the same. In another embodiment,
the carrier may deliver the item or groups of items to a recycling
center or facility for recycling or a donation center or facility
for donation (and provide yield metrics regarding the same). In
still another embodiment, the carrier may deliver the item or
groups of items to repair centers or facilities, whether operated
by the carrier, the original vendor (e.g., first consignor), or a
third party. And in still another embodiment, the carrier may
deliver the item or groups of items to a facility or center for
destruction, disposal, or aging. In one embodiment, the carrier may
provide such services for a standard transportation and delivery
fee, for a percentage of any liquidation or resale profits, as a
premium service with a transaction fee, and/or the like. As will be
recognized, the items or groups of items can be delivered to a
variety of delivery points to adapt to various needs and
circumstances.
[0113] By way of example, the carrier system 100 can implement a
low level of delivery point selection/routing, such as by using a
fixed attribute value that routes all of a consignor's returns to a
single delivery point (e.g., a consignor's dedicated returns
processing center). In another example, the carrier system 100 can
implement a higher level of delivery point selection/routing using
the customer-defined handling identifier, such as by routing
returned items by the return category and collection method values,
such as delivery point=5 (a third party liquidator) may be used if
the returns category=1 (post-season apparel) and the collection
method=3 (drop-off at carrier-designated locations). Similarly,
delivery point=1 (consignor's original fulfillment location) may be
used if the returns category=3 (current inventory high tech.) and
the collection method=2 (carrier pickup).
[0114] In one embodiment, as described, shipping data and/or the
various identifiers (e.g., item/shipment identifier,
carrier-assigned customer identifier, and/or customer-defined
handling identifier) corresponding to items can be transmitted
regularly, periodically, continuously, and/or on demand (e.g., in
response to certain triggers) by the carrier system 100 to the
appropriate mobile stations 105. Thus, for instance, carrier
personnel can scan an item/shipment identifier (or other
identifier) on an item (e.g., using a mobile station 105) to view,
access, provide, and/or retrieve information about the handling
and/or delivery of the item and carry out the instructions
regarding the same (Block 2720 of FIG. 27). With the
customer-defined handling identifier, the carrier system 100 can
determine to where the item should be routed and/or handled within
and outside the carrier's transportation and logistics network.
B. Unauthorized Returns
[0115] For unauthorized returns, the carrier system 100 may provide
the ability to initiate returns via an interface (e.g., browser,
dashboard, application) provided by the carrier. For example, as
shown in FIG. 28, a customer (e.g., a customer or customer
representative operating a consignee computing device 110 or
consignor computing device 120) can initiate a return via a carrier
returns portal/interface (e.g., browser, dashboard, application) in
a variety of ways regardless of by whom or how the items were
delivered to the customer--see FIG. 28. Via the carrier returns
portal/interface (e.g., browser, dashboard, application), a
customer (e.g., a customer or customer representative operating a
consignee computing device 110 or consignor computing device 120)
can input information regarding the return, which may include
return attributes as described above with regard to authorized
returns. Via the carrier returns portal/interface (e.g., browser,
dashboard, application), the customer (e.g., a customer or customer
representative operating a consignee computing device 110 or
consignor computing device 120) can input or select addresses from
his or her address book or from a list of consignors corresponding
to the customer's profile.
[0116] In one embodiment, based on the attributes or
characteristics of the shipment, the carrier system 100 can provide
shipping options, rates, and collection methods available to the
customer. The customer (e.g., a customer or customer representative
operating a consignee computing device 110 or consignor computing
device 120) can then select and pay for the desired shipping
services. In one embodiment, the carrier system 100 may also offer
incentives to customers for increased returns volume. For instance,
the carrier system 100 may offer reduced rates or additional
collection methods to customers with a minimum number of items
being returned or with an average shipping volume, for example.
[0117] As part of this process, the carrier system 100 may
determine a customer-defined handling identifier for, assign a
customer-defined handling identifier to, and/or associate a
customer-defined handling identifier with each item or group of
items being returned. As previously described, the customer-defined
handling identifier can be used to indicate (e.g., based on the
business rules application) how the item should be processed,
shipped, and/or handled. In one embodiment, for unauthorized
returns, the carrier system 100 may determine a customer-defined
handling identifier for, assign a customer-defined handling
identifier to, and/or associate a customer-defined handling
identifier with each item or group of items being returned as
described above with regard to authorized returns. In another
embodiment, though, the carrier system 100 can use fixed or static
return category portions, collection method portions, and delivery
point portions such that the item or group of items will
transported through the carrier's transportation and logistics
network to the delivery point identified by the original or initial
consignee (e.g., second consignor). As will be recognized, a
variety of other approaches and techniques can be used to adapt to
various needs and circumstances.
[0118] In one embodiment, after the return is completed via the
carrier returns portal/interface (e.g., browser, dashboard,
application), the carrier system 100 can transmit a shipping label,
a web form, a barcode, a QR code, a receipt image, and/or the like
that comprises or is associated with a carrier-assigned customer
identifier, an item/shipment identifier, a customer-defined
handling identifier, and/or the like to the corresponding customer
(e.g., operating a customer computing device 110/120)--see FIG. 33.
Similarly, the carrier system 100 may also provide such information
to the original or initial consignor (e.g., second consignee). The
shipping label, web form, barcode, QR code, receipt image, and/or
the like can be used to induct the item into the carrier's
transportation and logistics network (e.g., via pickup, drop-off,
etc.), which may include picking up, dropping off, packing,
labeling, and/or beginning shipment of the item or groups of
items.
[0119] In one embodiment, as described, shipping data and/or the
various identifiers (e.g., item/shipment identifier,
carrier-assigned customer identifier, and/or customer-defined
handling identifier) corresponding to items can be transmitted
regularly, periodically, continuously, and/or on demand (e.g., in
response to certain triggers) by the carrier system 100 to the
appropriate mobile stations 105. Thus, for instance, carrier
personnel can scan an item/shipment identifier (or other
identifier) on an item (e.g., using a mobile station 105) to view,
access, provide, and/or retrieve information about the handling
and/or delivery of the item and carry out the instructions
regarding the same.
C. Return Messages/Notifications/Alerts & Customized
Refunds
[0120] As described previously, customers can customize their
communication preferences for notifications they wish to receive
regarding shipments. This also includes items being returned. In
one embodiment, the notifications regarding returns can be used to
address the challenge of operational planning for "lumpy" return
volume and to reduce end-to-end cycle times for processing
recovered assets.
[0121] In one embodiment, customers (e.g., original vendors) can
refund original consignees (e.g., purchasers) for items being
returned at a variety of stages in the reverse logistics cycle. For
example, customers (e.g., operating a consignee computing device
110 or consignor computing device 120) may identify/define
triggering events (e.g., one or more parameters) for which the
notifications providing information regarding items should be
transmitted from the carrier system 100 to the customer (e.g.,
original vendor or associated party) to trigger/initiate refunds.
In one embodiment, a customer may track any number (e.g., four in
the following example) of different triggering events (e.g., one or
more parameters) in the returns logistics cycle: generating a label
or receipt for returning an item and/or authorizing an item for
return, receiving/collecting an item from a consignor for induction
into the carrier's transportation and logistics network, sortation
and/or consolidation of items, delivery of items to intermediate or
final delivery points, and/or the like. Based on the previously
discussed communication preferences, the carrier system 100 can
automatically generate (e.g., via the message module 260) one or
more notifications providing information regarding a return item to
the customer in compliance with the customer's communication
preferences. Such notifications may include the RMA, the
carrier-assigned customer identifier, the item/shipment identifier,
the customer-defined handling identifier, the triggering event,
and/or the like. And the carrier system 100 can automatically
transmit the one or more notifications to the electronic
destination addresses in compliance with the customer's
communication preferences.
[0122] In one embodiment, with an address associated with the
original consignor (e.g., second consignee or vendor), the RMA, the
return address, the carrier-assigned customer identifier, the
item/shipment identifier, and/or the customer-defined handling
identifier, the carrier system 100 can provide notifications to the
corresponding customers (e.g., operating customer computing devices
110/120) in accordance with the communication preferences as
described above. These notifications may be triggered based on
matching return addresses, names, RMAs, carrier-assigned customer
identifiers, item/shipment identifiers, customer-defined handling
identifiers, and/or the like. In one embodiment, in the returns
context, the carrier system 100 may provide notifications to
customers (e.g., operating customer computing devices 110/120) when
an RMA has been approved, when a customer-defined handling
identifier has been assigned, when an item has been collected by a
carrier, when a minimum number of items have been consolidated by a
carrier, when an item reaches various points in the carrier's
transportation and logistics network, when an item has been shipped
and is being transported by a carrier (e.g., confirmed as being in
transit), when an item has been repaired or refurbished, when an
item has been recycled or disposed of, when an item has been
returned to the appropriate returns location, when an item has been
returned to the appropriate returns location and has been inspected
upon return, and/or the like. Such events can be used to
trigger/initiate refunds for items being returned.
[0123] As previously noted, the appropriate party can define
various refund triggers or parameters that can be used to
automatically determine when customers (e.g., original vendors) are
to refund initial or original consignees (e.g., purchasers) for
items being returned at a variety of stages in the reverse
logistics cycle. For instance, a customer (e.g., original vendor or
associated party) and/or a carrier can define any number of refund
triggers that are to be used to provide refunds for specific items.
In the following example, four different refund triggers are
described for illustrative purposes--see Table 4 below.
TABLE-US-00004 TABLE 4 CLASSIFICATION TRIGGER/PARAMETER R1
Initiation of return R2 Item in transit R3 Item delivered via
return R4 Item returned and inspected
[0124] As shown in the above table, in this example, for refund
classification as "R1," an appropriate computing entity (e.g.,
carrier system 100, customer computing device 110/120, payment
system) can be used to determine and initiate payment for a refund
for an item being returned when the return is initiated, such as by
issuance of an RMA. R1 may be used for valued customers (e.g.,
participating in a vendor program, such as a reward program) to
help make their refunds as fast and efficient as possible. Further,
for the refund classification as "R2," an appropriate computing
entity (e.g., carrier system 100, customer computing device
110/120, payment system) can be used to determine and initiate
payment for a refund for an item being returned when the item has
been received by the carrier and is in transit. For the refund
classification as "R3," an appropriate computing entity (e.g.,
carrier system 100, customer computing device 110/120, payment
system) can be used to determine and initiate payment for a refund
for an item being returned when the item has been delivered by the
carrier as a return. For the refund classification as "R4," an
appropriate computing entity (e.g., carrier system 100, customer
computing device 110/120, payment system) can be used to determine
and initiate payment for a refund for an item being returned when
the item has been delivered by the carrier as a return and has been
inspected by the customer (e.g., original vendor). R4 may be used
for returns of high-value items to ensure that they are received in
the proper condition before a refund is processed. As will be
recognized, any number or return classifications can be defined to
adapt to various needs and circumstances.
[0125] In one embodiment, the returns process may require an RMA.
In such an embodiment, if an appropriate computing entity (e.g.,
carrier system 100, customer computing device 110/120, payment
system) determines that a return is in compliance with the
corresponding consignor's business rules (e.g., based at least in
part on the return attributes), the appropriate computing entity
(e.g., carrier system 100, customer computing device 110/120,
payment system) can authorize the return and assign or associate
therewith an RMA number to the item being returned. In addition to
the RMA, a refund classification can be assigned to or associated
with the RMA, the carrier-assigned customer identifier, the
item/shipment identifier, the customer-defined handling identifier,
and/or the like. Table 5 below shows the RMA, the refund
classification, and the item/shipment identifier for four items
being returned.
TABLE-US-00005 TABLE 5 RMA CLASSIFICATION Item ID 5PRGF R1
123456789 76LOE R2 123456788 98FOR R3 123456787 99CBD R4
123456786
[0126] As items progress through the carrier's transportation and
logistics network, the carrier system 100 can provide notifications
to the corresponding customers (e.g., operating customer computing
devices 110/120) in accordance with the communication preferences
as described above. As previously described, in the returns
context, the carrier system 100 may provide notifications to
customers (e.g., operating customer computing devices 110/120) when
an RMA has been approved, when a customer-defined handling
identifier has been assigned, when an item has been collected by a
carrier, when a minimum number of items have been consolidated by a
carrier, when an item reaches various points in the carrier's
transportation and logistics network, when an item has been shipped
and is being transported by a carrier (e.g., confirmed as being in
transit), when an item has been repaired or refurbished, when an
item has been recycled or disposed of, when an item has been
returned to the appropriate returns location, when an item has been
returned to the appropriate returns location and has been inspected
upon return, and/or the like. As a result of such notifications, an
appropriate computing entity (e.g., carrier system 100, customer
computing device 110/120, payment system) can automatically
determine regularly, periodically, continuously, or in response to
certain triggers (e.g., notifications received) whether a refund
payment should be initiated based on the refund classification
corresponding to the appropriate item or items.
[0127] Continuing with the above example, once the RMA is generated
for the item corresponding to shipment identifier 123456789, an
appropriate computing entity (e.g., carrier system 100, customer
computing device 110/120, payment system) can receive such a
notification and initiate payment of the refund based at least in
part on the refund classification R1 and its associated refund
parameters (e.g., triggering events). Similarly, once the item
corresponding to shipment identifier 123456788 has been received by
the carrier, an appropriate computing entity (e.g., carrier system
100, customer computing device 110/120, payment system) can receive
such a notification and initiate payment of the refund based at
least in part on the refund classification R2 and its associated
refund parameters (e.g., triggering events). Further, once the item
corresponding to shipment identifier 123456787 has been delivered
by the carrier as a return, the appropriate computing entity (e.g.,
carrier system 100, customer computing device 110/120, payment
system) can receive such a notification and initiate payment of the
refund based at least in part on the refund classification R3 and
its associated refund parameters (e.g., triggering events). And
once the item corresponding to shipment identifier 123456786 has
been delivered by the carrier as a return and has been inspected by
the customer (e.g., original vendor), the appropriate computing
entity (e.g., carrier system 100, customer computing device
110/120, payment system) can receive such a notification and
initiate payment of the refund based at least in part on the refund
classification R4 and its associated refund parameters (e.g.,
triggering events).
[0128] In one embodiment, once a refund is initiated by the
appropriate computing entity, a payment system may complete the
refund to the customer (e.g., purchaser). As previously described,
such payments/refunds may be in a variety of forms, including via
debit cards, credit cards, direct credits, direct debits, cash,
check, money order, Internet banking, e-commerce payment
networks/systems (e.g., PayPal.TM., Google Wallet, Amazon
Payments), virtual currencies (e.g., Bitcoins), award or reward
points, and/or the like. Notification of the processed refund can
also be provided to the customers (e.g., operating customer
computing devices 110/120). As will be recognized, a variety of
techniques and approaches can be used to adapt to various needs and
circumstances.
IV. CONCLUSION
[0129] Many modifications and other embodiments of the inventions
set forth herein will come to mind to one skilled in the art to
which these inventions pertain having the benefit of the teachings
presented in the foregoing descriptions and the associated
drawings. Therefore, it is to be understood that the inventions are
not to be limited to the specific embodiments disclosed and that
modifications and other embodiments are intended to be included
within the scope of the appended claims. Although specific terms
are employed herein, they are used in a generic and descriptive
sense only and not for purposes of limitation.
* * * * *