Abstract:
Portable electronic devices typically have reduced computing resources, including reduced available bandwidth to receive communications. A method, apparatus and system is provided to manage packet delivery to electronic devices to mitigate some of these problems.

Description:
FIELD 
     The present specification relates generally to telecommunications and more specifically relates to a method, apparatus and system for managing packet delivery. 
     BACKGROUND 
     Even as wired and wireless access technologies continue to increase their bandwidth, and correspondingly increase their capacity to carry traffic, the access technologies nonetheless represent a limited resource. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a schematic representation of a system for managing packet delivery. 
         FIG. 2  shows a schematic representation of the electronic device shown in the system of  FIG. 1 . 
         FIG. 3  shows a flow-chart depicting a method of updating a whitelist. 
         FIG. 4  shows a flow-chart depicting a method of managing packet delivery. 
         FIG. 5  shows a modified version of the system of  FIG. 1 . 
         FIG. 6  shows the system of  FIG. 5  according to a first configuration. 
         FIG. 7  shows the system of  FIG. 5  according to a second configuration. 
         FIG. 8  shows a flow-chart depicting a method of associating an electronic device with a content server. 
         FIG. 9  shows flow-chart depicting a method of one exemplary way of performing block  825  of the method of  FIG. 8 . 
         FIG. 10  shows flow-chart depicting a method of another exemplary way of performing block  825  of the method of  FIG. 8 . 
         FIG. 11  shows a flow-chart depicting a modified version of the method of  FIG. 4 . 
     
    
    
     DESCRIPTION 
     An aspect of this specification provides a method of managing packet delivery comprising: receiving a message at a transport intermediation server from an origination content computer; said message including an origination identifier associated with said origination content computer; said message including an absolute destination identifier uniquely associated with an electronic device to which said message is addressed; said message including a payload encrypted by said content computer using an encryption mechanism that is unique to said electronic device and said content computer such that said intermediation server cannot decrypt said payload; extracting, at said transport intermediation server, said origination identifier associated with origination content computer; extracting, at said transport intermediation server, said unique absolute destination identifier; receiving, at said transport intermediation server, a delivery policy associated with said unique absolute destination identifier; and, forwarding, at said transport intermediation server, said message to said electronic device if said origination identifier is a permitted sender according to said delivery policy and otherwise, dropping said message. 
     The unique absolute destination identifier can comprise one of an International Mobile Equipment Identity (IMEI) identifier, or a BlackBerry™ PIN. 
     The origination content computer can be a content server. 
     The delivery policy can comprise a white list expressly authorizing deliveries from said origination identifier. The message further can further comprise an indication if said payload comprises activation information for establishing a unique association between a server at said origination identifier and said electronic device; and wherein said delivery policy deems said origination identifier to be a permitted sender if said payload comprises activation information. 
     The method according can further comprise: prior to receiving said message, receiving an association request from said electronic device at said intermediation server to associate said electronic device with a server associated with said origination identifier; recording said association request; and, wherein said delivery policy deems said origination identifier to be a permitted sender based on said recorded association request. 
     The message can have a format according to one of the following: a Multipurpose Internet Mail Extension (MIME) format email, an instant message (IM), a vCal calendar appointment, an iCal calendar appointment, a vCard, a video file, or an audio file. 
     The delivery policy can be unique to said format. 
     A separate delivery policy can be maintained according to each said format, and each said message can further comprise a message format indication; and said method further comprises; extracting said method format indication; selecting an appropriate said delivery policy based on said method format indication. 
     Another aspect of the specification provides a computer-readable medium containing programming instructions that are executable on a server in order to configure the server to operate according to any of the foregoing. 
     Another aspect of the specification provides a transport intermediation server comprising: an interface configured to receive a message from an origination content computer via a network; said message including an origination identifier associated with said origination content computer; said message including an absolute destination identifier uniquely associated with an electronic device to which said message is addressed; said message including a payload encrypted by said content computer using an encryption mechanism that is unique to said electronic device and said content computer such that said intermediation server cannot decrypt said payload; a processor configured to extract said origination identifier associated with origination content computer; said processor further configured to extract said unique absolute destination identifier; said processor further configured to receive a delivery policy associated with said unique absolute destination identifier; and, said processor further configured to forward, via said network interface, said message to said electronic device if said origination identifier is a permitted sender according to said delivery policy and otherwise configured to drop said message. 
     Referring now to  FIG. 1 , a system for managing packet delivery is indicated generally at  50 . In a present embodiment system  50  comprises a portable electronic device  54  and at least one intermediation server  58 . A wireless base station  62  interconnects electronic device  54  and intermediation server  58 . A backhaul link  66  interconnects base station  62  with server  58 . At least one bearer path  70 , typically wireless, can be used to interconnect base station  62  with electronic device  54 . In a present exemplary embodiment, bearer path  70  can be based on one or more of Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), Enhanced Data Rates for GSM Evolution (EDGE), the Third-generation mobile communication system (3G), Evolution-Data Optimized (EVDO), Institute of Electrical and Electronic Engineers (IEEE) 802.11 (WiFi) or other wireless protocols. In variations, path  70  can be wired. 
     Intermediation server  58  is also connected to a network  74  via another backhaul link  78 . Network  74  can be any type of network that can deliver content to device  54 . In a present embodiment, network  74  is the Internet and connects to a sending server  82  which connects to network  74  by another backhaul link  86 . 
     Referring now to  FIG. 2 , electronic device  54  can be any type of computing device that can be used in a self-contained manner and to interact with content available over network  74 . Interaction includes displaying of information on electronic device  54  as well as to receive input at electronic device  54  that can in turn be sent back over network  74 . It should be emphasized that the structure in  FIG. 2  is purely exemplary, and contemplates a device that be used for both wireless voice (e.g. telephony) and wireless data (e.g. email, web browsing, text) communications. In a present embodiment, electronic device  54  is a portable electronic device with the combined functionality of a personal digital assistant, a cell phone, and an email paging device. (Although variants on device  54  can include a palm top computer or laptop computer with a reduced screen such as an ASUS EEE from ASUSTek Computer Inc. of Taiwan). Many known cellular telephone models, or variants thereof, are suitable for the present embodiment. 
     Device  54  thus includes a plurality of input devices which in a present embodiment includes a keyboard  100 , a pointing device  102 , and a microphone  104 . Pointing device  102  can be implemented as a track wheel, trackball or the like. Other input devices, such as a touch screen are also contemplated. Input from keyboard  100 , pointing device  102  and microphone  104  is received at a processor  108 . Processor  108  is configured to communicate with a non-volatile storage unit  112  (e.g. Erasable Electronic Programmable Read Only Memory (“EEPROM”), Flash Memory) and a volatile storage unit  116  (e.g. random access memory (“RAM”)). Programming instructions that implement the functional teachings of device  54  as described herein are typically maintained, persistently, in non-volatile storage unit  112  and used by processor  108  which makes appropriate utilization of volatile storage  116  during the execution of such programming instructions. 
     Processor  108  in turn is also configured to control a speaker  120  and a display  124 . Processor  108  also contains at least one network interface  128 , which are implemented in a present embodiment as radios configured to communicate over bearer path  70 . In general, it will be understood that interface(s)  128  is (are) configured to correspond with the network architecture that defines a particular bearer path  70 . It should be understood that in general a wide variety of configurations for device  54  are contemplated. 
     In a present embodiment, device  54  is also configured to maintain a unique device identifier  134 , a message application  136 , and a configuration file  138  maintained within non-volatile storage  112 . 
     Device identifier  134  represents a unique absolute identifier of device  54 . Exemplary device identifiers can include, but are not limited to, an International Mobile Equipment Identity (IMEI) identifier, or a BlackBerry™ PIN as commonly employed in BlackBerry™ devices from Research In Motion Inc., Waterloo, Ontario Canada. Other exemplary device identifiers will now occur to those skilled in the art. It is thus presently preferred that identifier  134  is absolute, non-changeable and non-transferrable, being specifically assigned to the hardware of device  54 . 
     Processor  108  is also configured to execute message application  136 , which is able to receive messages at device  54  which are addressed to unique device identifier  134 . Device identifier message application  136  is also configured to send messages to other devices (not shown), using any suitable destination address identifier, including but not limited to a unique device identifier for the destination. For sent messages, unique device identifier  134  can be used to identify the sender of such messages, although this is not required. 
     While the use of unique device identifiers is specific to the receipt of messages via message application  136 , the type of messages that can be sent and received via device identifier message application  136  is not specific, and can include emails (e.g. Multipurpose Internet Mail Extensions (MIME)), instant messages (IM), calendar appointments (e.g. vCal, iCal), contact information (e.g. vCard), video files, or audio files or other types of messages as well. In general the type of messages sent and received by message application  136  is not particularly limited. It will be understood that other applications can also be provided in non-volatile storage  112  that interact with messages that are also handled by device identifier message application  136 . 
     Processor  108  is configured to access configuration file  136  in order to establish initial settings for one or more applications, including message application  136 , as well as to define any relevant communication gateways on network  74  that correspond to each of those applications. As will be discussed further below, configuration file  138  is configured in a present embodiment to maintain a whitelist of sending addresses that are permitted to send messages to device  54  using message application  136 . While a BlackBerry™ computing environment is not required to implement the present teachings, where a BlackBerry™ computing environment is used to implement device  54 , then configuration file  138  can be implemented as a BlackBerry™ Service Book or as one or more specific entries within a BlackBerry™ Service Book. 
     Processor  108  is also configured to receive input from keyboard  100  relative to message application  136  and to generate graphical interfaces on display  124 . Processor  108  is further configured to send and receive messages associated with message application  136 , via network  74  and bearer path  70 , utilizing configuration file  136 , as will be discussed further below. 
     Device  54  also includes a battery  144  or other power supply. Battery  144  provides power to components within device  54 . 
     Server  58  can be based on any well-known server environment including a module that houses one or more central processing units, volatile memory (e.g. random access memory), persistent memory (e.g. hard disk devices) and network interfaces to allow server  58  to communicate over network  74  and with base station  62 . For example, server  58  can be a Sun Fire V480 from Sun Microsystems, Inc. of Palo Alto Calif., running a UNIX operating system, and having four central processing units each operating at about nine-hundred megahertz and having about sixteen gigabytes of random access memory. However, it is to be emphasized that this particular server is merely exemplary, and a vast array of other types of computing environments for server  58  is contemplated. 
     Intermediation server  58  maintains a copy of device identifier  134 , and is configured to send messages that are addressed using device identifier  134 , to device  54 . Intermediation server  58  and device  54  are thus complementary to each other in that device identifier  134  is used by intermediation server  58  to send messages to device  54 . While a BlackBerry™ computing environment is not required to implement the present teachings, where a BlackBerry™ computing environment is used to implement system  50 , then intermediation server  58  can be implemented as a “Relay” server that is specific to a BlackBerry™ computing environment. 
     Server  82  can be based on the same or different computing environment as server  58 . Sending server  82  is, in turn, configured to maintain a message  90  that can be marked for delivery to device  54  via message application  136  using unique identifier  134 . Message  90  can be any of the types discussed above. 
     Referring now to  FIG. 3 , a flowchart depicting a method of updating a whitelist is indicated generally at  300 . Method  300  can be implemented on system  50  or a suitable variation thereof. Method  300  can be performed once or several times, as needed, to provide an up-to-date whitelist. 
     Block  305  comprises receiving a whitelist identifier. Block  305  can be effected by receiving input using keyboard  100  and generating a graphical interface on display  124  that shows the received input. The graphical interface can be configured to also provide a menu of options so that the received whitelist identifier can be viewed, edited, saved or deleted. Such a whitelist identifier indicates any address on network  74  which is permitted to send messages to message application  136  using device identifier  134 . The whitelist address itself can be in any format (e.g. internet protocol (IP) address, MAC address, email address), and need not be, though can be, of the same format as unique device identifier  134 . 
     Various types of different graphical interfaces can be generated to effect block  305 , including the entry via keyboard  100  of the whitelist identifier, or by selecting whitelist identifiers that are loaded onto device  54 , such as through a contact manager application (not shown). Whitelist identifiers can also be received as being implicit during the provisioning of device  54 ; for example, assuming device  54  connects to server  82  as part of its provisioning, then server  82  can be automatically included to the whitelist received at block  305 . 
     At block  310 , the whitelist identifier received at block  305  is saved. In a present embodiment the whitelist identifier is stored within configuration file  138 . At blocks  315  and  320 , the whitelist is sent to and received by intermediation server  58 , which saves a local copy of the whitelist. Again, in a present embodiment, blocks  315  and  320  are effected by sending configuration file  138  to intermediation server  58 , which then saves a local copy of the whitelist. 
     Referring now to  FIG. 4 , a flowchart depicting a method of managing packet delivery is indicated generally at  400 . Method  400  can be implemented on system  50  or a suitable variation thereof. Method  400  assumes that a whitelist has been generated and saved on intermediation server  58 , using method  300  or a suitable variation thereof. Method  400  can be performed by intermediation server  58 . 
     Block  405  comprises receiving a message. The message is received at intermediation server  58 . The message includes a destination identifier  134  that is extractable by intermediation server  58 . The destination identifier  134  indicates the message is destined for device  54 . The message also includes an origination address of server  82  that is extractable by intermediation server  58 . The message also includes a payload. The payload can optionally be encrypted using an encryption mechanism that is unique to the electronic device and said originating server such that the intermediation server  58  cannot decrypt the payload. 
     Block  410  therefore comprises extracting destination identifier  134 , and block  415  comprises extracting the origination identifier. 
     For purpose of explaining method  400 , assume that the message received at block  405  is message  90 , and that message  90  is sent from server  82  and bears the destination identifier  134  as the destination address, and is therefore destined for device  54 . 
     At block  420 , the whitelist respective to the destination identifier received at block  410  is received. Where method  300  was performed, the whitelist retrieved at block  420  corresponds to the whitelist that was saved at block  320  of method  300 . 
     At block  425 , a determination is made as to whether the origination identifier from block  415  is in the whitelist received at block  420 . If “no”, (in other words, delivery to device  54  is not permitted according to the whitelist) then at block  430  the message is discarded. If “yes” (in other words, delivery to device  54  is permitted according to the whitelist) then at block  435  the message is forwarded to device  54  over bearer path  70 . 
     Variations of the foregoing are contemplated. For example,  FIG. 5  shows system  50   a  which is a variation on system  50  and like elements in system  50   a  include like references to their counterparts in system  50 , except followed by the suffix “a”. System  50   a  reflects a “scaled-up” version of system  50 , and thus includes a plurality of devices  54   a , a plurality of base stations  62   a , a plurality of intermediation servers  58   a , and a plurality of sending servers  82   a . Upon further review of this specification, it will become apparent that system  50   a  can be “scaled-up” further to, for example, several thousand servers  58   a , several thousand servers  82   a  and millions of devices  54   a.    
     In  FIG. 5 , it can be noted that device  54   a - 1  and device  54   a - 2  are shown in communication with base station  62   a - 1 , while device  54   a - 3  is shown in communication with base station  62   a - 2 . This is merely an exemplary structure, and it should be understood that each device  54   a  can communicate with either base station  62   a  depending on their proximity to a given base station  62   a.    
     Also of note, in system  50   a  servers  82   a  can be implemented, in a non-limiting example, as enterprise servers, such as BlackBerry™ Enterprise Servers that are hosted and maintained by an enterprise that is associated with each device  54   a , and servers  58   a  can be implemented as relay servers such as Relay Servers that are hosted and maintained by a carrier, or a carrier partner such as Research In Motion Limited. However, the entity (or entities) that host(s) and maintain(s) each server  82   a  and each server  58   a  is not particularly limited and is discussed herein for an example of a potential real-world implementation. In terms of technical structure, servers  82   a  can also be referred to as content servers  82   a , whereas servers  58   a  can be referred to as transport intermediation servers. 
     In a present embodiment, a message  90   a  can be sent from its corresponding server  82   a  to a device  54   a  uniquely associated with that particular server  82   a . Such messages  90   a , or at least their payloads, can be passed in encrypted form, if desired, by providing a key pair or other encrypting means at one server  82   a  and a corresponding device  54   a , such that communications carried through server  58   a  are secure. Key pairing or other encryption means is one example of how a particular device  54   a  can be uniquely associated with a given server  82   a . In practice, such a unique association can arise as a given enterprise acquires a server  82   a  and one or more devices  54   a , and then distributes those acquired devices  54   a  to its employees, so that the employees can conduct the business of the enterprise using their device  54   a . A technological association is made between such devices  54   a  and server  82   a  in the form a key pair or other encrypting means, such that the electronic communications conducted on the devices  54   a  are confidential from other parties that also connect to network  74   a  and may inadvertently or intentionally intercept such electronic communications. 
     To explain the present embodiment further, assume that, in a first exemplary configuration of system  50   a , device  54   a - 1  is associated with server  82   a - 1 ; device  54   a - 2  is associated with server  82   a - 1 ; and that device  54   a - 3  is associated with server  82   a - 2 .  FIG. 6  shows this exemplary first configuration, where a first enterprise Ea- 1  is associated with server  82   a - 1 , device  54   a - 1  and device  54   a - 2 , and a second enterprise Ea- 2  is associated with server  82   a - 2 , and device  54   a - 3 . Configuration files  138   a  for each device  54   a  are stored on each transport intermediation server  52   a , as a result of, for example, a prior performance of method  300  in relation to each device  54   a . (Note that in other embodiments, not shown, one transport intermediation servers  52   a  could be dedicated to only certain devices  54   a ). As part of multiple performances of method  300 , the above-described associations are technologically configured into system  50   a , such that server  82   a - 1  is on the whitelist for device  54   a - 1 , and server  82   a - 1  on the whitelist for device  54   a - 2 ; and likewise server  82   a - 2  is on the whitelist for device  54   a - 3 . Thus, during performances of method  400 , if message  90   a - 1  was addressed to device  54   a - 3 , then message  90   a - 1  would be dropped by servers  58   a , but if message  90   a - 1  was addressed to device  54   a - 1  or device  54   a - 2 , then message  90   a  would be delivered by servers  58   a ; likewise, if message  90   a - 2  was addressed to device  54   a - 3 , then message  90   a - 2  would be delivered by servers  58   a , but if message  90   a - 2  was addressed to device  54   a - 1  or device  54   a - 2 , then message  90   a - 2  would be dropped by servers  58   a.    
     A feature of the present specification is the ability to change the association of one device  54   a  from an association with one server  82   a  to another server  82   a , without exposing that device  54   a  to subsequent unwanted packet deliveries from the original server  82   a . For example, assume that device  54   a - 2  is currently associated with server  58   a - 1  according to the first configuration in  FIG. 5 , but that device  54   a - 2  needs to be reconfigured to drop the association with server  82   a - 1  and establish a new association with server  82   a - 2 . The desired result of such reconfiguration is shown in  FIG. 7 , as a second exemplary configuration. In  FIG. 7 , configuration file  138   a - 1  and configuration file  138   a - 3  as they are stored on servers  82   a  are unchanged, but a new configuration file  138   a - 2 ′ is stored on servers  58   a , such that method  400   a  would deliver message  90   a - 2  if message  90   a - 2  was addressed device  54   a - 2 , but method  400  would drop message  90   a - 1  if message  90   a - 1  was addressed to device  54   a - 2 . 
     Various methods are contemplated of performing the transition from the configuration in  FIG. 6  to the configuration in  FIG. 7 . Method  800  in  FIG. 8  shows an example of one such method for performing the transition. At block  805 , it is assumed that system  50   a  is configured according to  FIG. 6 , but by block  840 , system  50   a  is configured according to  FIG. 7 . (While  FIG. 8  makes specific reference to device  54   a - 2  and server  82   a - 2 , it is to be understood that method  800  can be employed in relation to any one of devices  54   a  establishing association with any one of servers  82   a ). At block  805 , device  54   a - 2  sends an association request. The association request at device  54   a - 2  can be formed using an email address or other unique identifier of server  82   a - 2 , and, if desired, a password that is known to server  82   a - 2 . For added security, if desired, the association request can be encrypted using a public encryption key paired with a private encryption key that is local to server  82   a - 2 , where the public encryption key can be fetched from a public encryption key repository that is accessible to device  54   a - 2 . 
     The association request is sent through one of the servers  58   a  to server  82   a - 2 , where it is received thereby at block  810 . At block  815 , server  82   a  performs a series of association operations in order to locally associate device  54   a - 2  with server  82   a - 2 , including the generation of one or more configuration files that will be sent to and used by device  54   a - 2  to locally associate device  54   a - 2  with server  82   a - 2 . The association operations at block  815  are not particularly limited. In general where device  54   a - 2 , server  58   a , and server  82   a - 2  are based on a BlackBerry™ infrastructure, then blocks  805  through block  815  can include substantially the same steps that are involved with a current activation technique of a BlackBerry™ device (which is one non-limiting example of a way to implement of device  54   a - 2 ) on a particular BlackBerry™ Enterprise Server (which is one non-limiting example of a way to implement of server  82   a - 2 ). In this specific implementation, the configuration files can be implemented as a Service Book within the BlackBerry™ infrastructure. 
     At block  820 , the configuration files generated at block  815  are sent back over network  74   a  and addressed device  54   a - 2  via server  58   a . Again, such files are typically sent back in encrypted format—and indeed such files typically include the new encryption keys that reflect a unique pairing between device  54   a - 2  and server  82   a . However, once those configuration files reach server  58   a , at block  825 , server  58   a  makes a determination as to whether to forward or drop the configuration files. Block  825  is performed for substantially the same reason as method  400 . Typically, due to the fact that the configuration files that are sent at block  820  are encrypted, then block  825  is performed as an extension to method  400 , since server  58   a  cannot examine the payload itself and is only aware that certain encrypted data is being addressed for delivery to device  54   a - 2 . 
     If a “drop” determination is made at block  825 , then method  800  ends. If a “forward” determination is made at block  825  then the configuration files are actually sent to device  54   a - 2 , and at block  830  the configuration files are received by device  54   a - 2 . 
     At block  835 , device  54   a - 2  performs local configurations to complete the association of device  54   a - 2  with server  82   a - 2 . Again, to provide a non-limiting specific exemplary implementation of block  835 , if device  54   a - 2 , server  58   a , and server  82   a - 2  are based on a BlackBerry™ infrastructure, then blocks  835  can include substantially the same completion steps that are involved with a current activation technique of a BlackBerry™ device. In such BlackBerry™ environment, block  835  can include the storing and local processing of the configuration files (i.e. Service Books). 
     At block  840 , method  300  is invoked so that servers  58   a  are informed of the new association between device  54   a - 2  and server  82   a - 2 . At this point, the transition to the configuration is  FIG. 6  is complete. 
     As discussed above, block  825  can be effected in a variety of ways. Method  900  in  FIG. 9  shows one possible way of implementing block  825 . Method  900  is performed by server  58   a . At block  905  a message is received. The type of message received at block  905  can either be a configuration file of the type sent according to block  820 , or a payload message of the type received at block  405 . In this manner method  900  serves to augment method  400 . At block  910  the destination identifier is extracted—substantially in the same manner that block  410  is implemented. At block  915  a message type is extracted. Method  900  thus assumes that a flag or other type of identifier is generated as part of block  820  which indicates that configuration files are being sent—and that such a flag can only be used by server  82   a  for configuration files. At block  920  a determination is made as to whether the message type indicates that an activation is occurring. An activation will be deemed to be occurring at block  920  if the message type at block  915  indicates has a flag indicating configuration files. A “yes” determination will lead to the configuration files being forwarded to the destination device  54   a  at block  930 , at which point method  800  can continue from block  830 . A “no” determination will lead to the invocation of method  400  at block  925 . To further augment security, block  915  can be effected by using a predefined set of encryption keys between servers  58   a  and each server  82   a  whereby the message type is encrypted by server  82   a , but so that server  58   a  can still ascertain the message type. 
     Method  950  in  FIG. 10  shows another possible way of implementing block  825 . Method  950  is performed by server  58   a . At block  955  a message is received. The type of message received at block  955  can either be a configuration file of the type sent according to block  820 , or a payload message of the type received at block  405 . In this manner method  950  serves to augment method  400 . At block  960  the destination identifier is extracted—substantially in the same manner that block  410  is implemented. At block  965  the origination identifier is extracted—substantially in the same manner that block  415  is implemented. At block  970  a determination is made as to whether a previous association request had been made from the destination identifier device to origination identifier device. Performance of block  970  can be based on, for example, server  58   a  making a record of the forwarding of the association request that was carried by server  58   a  between block  805  and block  810  of method  800 . A “yes” determination will lead to the configuration files being forwarded to the destination device  54   a  at block  980 , at which point method  800  can continue from block  830 . A “no” determination will lead to the invocation of method  400  at block  985 . 
     As a still further variation, method  400   a  is shown in  FIG. 11 . Method  400   a  is substantially the same as method  400 , except like blocks bear like references except followed by the suffix “a”. Of note is that method  400   a  includes a further block in the form of block  431   a . Block  431   a  contemplates that additional filtering can be performed, beyond that performed in block  425   a . The filtering can be based on other characteristics of the message including, for example, packet type, IP ports, or a combination of thereof. For example, messages involving transport control protocol (TCP) packets from a given server  82  can be flagged as not being permitted, whereas messages with CMIME, ITADMIN, IPPP, and CICAL packets from that same server  82  can be flagged as being permitted. Thus the filtering in method  400   a  is generally more powerful than the filter in method  400 . However, method  400  can be faster since it omits block  431   a . To achieve a compromise, a combination of method  400  and method  400   a  can be employed, whereby certain origination identifiers are purely whitelisted, whereas other origination identifiers require further filtering. Those origination identifiers that are purely whitelisted can send messages that bypass block  431 a altogether, but those origination identifiers that require further filtering can be forwarded onto block  431   a . It will now occur to those skilled in the art that block  431   a  would involve creation of a whitelist (which can also be more generally referred to as a filtering policy) that provides criteria usable at block  430   a  and  431   a . Note that the amount of filtering that can be performed at block  431   a  can be reduced depending on the level of encryption of the payload messages being carried. Where messages are not encrypted, then more filtering options are available at block  431   a,  but where message payload is fully encrypted such that it cannot be examined by server  58 , then the possible types of filtering at block  431   a  can be limited. 
     It will now be apparent that method  400 , (and method  400   a ) and block  825 ) have the benefit stopping delivery of unwanted packets to device  54   a  and thereby reduce wasted bandwidth over link  70   a  and reduce wastage of limited processing and memory resources on device  54   a . The teachings herein permit servers  58   a  to perform the function of stopping delivery of unwanted packets (or messages), while at the same time permitting servers  58   a  to preserve the encryption of those packets (or messages). In the specific example given above, it can be possible that server  82   a - 1  never disassociates itself from device  58   a - 2  and may continue, erroneously, to try and send message  90   a - 1  to device  54   a - 2 . In this scenario, message  90   a - 1  will be dropped by servers  58   a  as part of performance of method  400 . One can note that without the teachings herein, where encryption used as part of the association between servers  82   a  and devices  54   a  are employed, message  90   a - 1  could not be opened by device  54   a - 2  even if message  90   a - 1  was actually delivered to device  54   a - 2 , due to the fact that message  90   a - 1  would be encrypted with an encryption key that is not stored on device  54   a - 2 . However, bandwidth of link  70   a  and processing resources of device  54   a - 2  are still consumed simply having to receive the message  90   a - 1  and trying to decrypt it. Further, an operator of server  82   a - 1  erroneously continually retries to send message  90   a - 1  (or different messages) to device  54   a - 2 , the constant receipt of messages  90   a - 1  could slow down the operation of device  54   a - 2  until server  82   a - 1  stops sending the message  90   a - 1 . The teachings herein thereby mitigate this problem and thereby provide a further benefit. 
     Variations of the foregoing are contemplated. For example, block  815  of method  800  can be performed so that the configuration file generated at block  815  can include establishment of a configuration file that includes a whitelist, which automatically includes server  82   a - 2 . This whitelist can be suitable for use as part of method  300 , but obviating the need for blocks  305  and  310  in method  300  as server  82   a - 2  will already be include in that whitelist. In this manner other identifiers can also be automatically added into the whitelist by server  82   a - 2 . 
     It should be noted that separate configuration files  138 , or records within one configuration file  138 , can be maintained for different message types, including emails (e.g. Multipurpose Internet Mail Extensions (MIME)), instant messages (IM), calendar appointments (e.g. vCal, iCal), contact information (e.g. vCard), video files, or audio files or other types of messages as well, such that different message types have different whitelists associated with the same or different content servers. 
     It should be noted that the whitelists can also include originating devices other than content servers. More generically, a whitelist can be considered a delivery policy, which can include whitelisted addresses or blacklisted addresses or both. 
     Combinations, variations and subsets of the foregoing are contemplated. 
     The claims attached hereto define the scope of the monopoly sought.