Patent Application
20100070419
This patent document pertains generally to electronic communication and more particularly, but not by way of limitation, to initiating a function with an email message.
A machine associated with one or more processors may be connected to a network. A processor may execute instruction to implement one or more operating systems. An operating system may cause execution of instructions to implement one or more applications. An application may cause the execution of instructions to provide a function.
Email messages are typically communicated between a sender and a receiver over a network. An email message may include multiple fields that are to include information related to the email message.
In the drawings, which are not necessarily drawn to scale, like numerals describe substantially similar components throughout the several views. Like numerals having different letter suffixes represent different instances of substantially similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.
In various example embodiments, a payment may be made from one value holding account to another value holding account holder, via an email message signed with a digital signature.
A payor, using a machine (e.g., handheld or desktop), may compose an email message using, for example, an email application or a web-based email interface. The email message may include one or more commands that may cause one or more functions to be executed. The one or more commands may be included in a subject field (e.g., subject line) of the email message. In some example embodiments, the email message may include in its subject line a payment command, an email address indicating a payee and a dollar or other currency amount to be paid to the payee. In some example embodiments, a payor may address the email message to an example secure server and digitally sign it before transmitting the email message to the secure server, via the Internet.
For some example embodiments, the secure server is to receive the email message and attempt to validate the sender of the email message by verifying the digital signature. The sender may be validated or invalidated based on an email address in the “From” field of the email message or based on an alias email address associated with the sender. Based on validating the sender, the secure server may extract the function command, the currency amount to be paid, and the payee from the email message. In some example embodiments, the secure server may generate a function call based on the payment command, the currency amount, and the payee and forward the function call to a payment application to be processed.
It may be noted that, although the example embodiments refer to the email messages being related to payment functions, the methods and systems described herein may also be used with the email messages that are related to other types of function.
In various example embodiments, execution of the function call may include the payment application accessing a user database to identify a value holding account associated with the email addresses of the payor and the payee. Execution of the function call may further include the payment application transferring the dollar or other currency amount to be paid from the value holding account of the payor to the value holding account of the payee. The example embodiments above describe examples of making a payment from a payor to a payee, via email message.
This overview is intended to provide an overview of the subject matter of the present patent application. It is not intended to provide an exclusive or exhaustive explanation of what is claimed. The detailed description is included to provide further information about the subject matter of the present patent application.
The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the claimed subject matter. The embodiments may be combined, other embodiments may be utilized, or structural, logical and electrical changes may be made without departing from the scope what is claimed. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. Furthermore, all publications, patents and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) should be considered supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.
The example network 102 is a communicative coupling of two or more machines. One or more types of networks and/or communication protocols may be used to implement the example network. In an example embodiment, the network may include a wide area network (WAN) and a local area network (LAN) that carries Internet protocol (IP) frames over various transmission media 103 such as twisted pairs, wireless and/or optical fiber. Example embodiments may include other types of networks, network topologies and/or communication protocols without departing from the claimed subject matter.
The example client machine 104 is to execute various instructions. In an example embodiment, one or more processors are included within the machine to process instructions associated with one or more virtual machines, operating systems and/or applications. In an example embodiment, the client machine 104 includes a central processing unit (CPU) to process instructions for an email application. The example email application (e.g., a desktop email application) may allow a user of the client machine 104 to send and/or receive email messages to and from other users using other client machines that are communicatively coupled to the network 102. Any email application may be used to allow the client machine 104 to send and/or receive email. In some example embodiments, the client machine 104 may include a web browser (not shown) allowing a user of the client machine 104 to send and receive email messages via the email server 106.
For some example embodiments, the client machine 104 allows a user to generate and send an email message that includes sender validation information, a function command and function input information. For some example embodiments, the sender validation information includes at least one of a public key certificate and/or a digital signature.
The email server 106 is to provide email services to the user using the client machine 104. In an example embodiment, the email server 106 is to receive an email message from the client machine 104 and forward the email message to a desired recipient. The email message may be sent from an email application or a web browser being implemented on the client machine 104. The email server 106 may include a CPU to execute instructions associated with providing email services to the client machine 104 or multiple client machines to which the email server 106 is communicatively coupled. An example email server 106 may include instructions to allow an email address to be validated by a receiver of the email message. For example, the email server 106 may forward an email message with validation information (e.g., a public key certificate and/or digital signature).
The application module 108 may be associated with one or more processors and application modules to execute instructions for the purpose of implementing one or more applications. In an example embodiment, an application may provide a function or various functions based on one or more function calls, which are themselves instructions. Some function calls that are expressed according to a particular protocol or language may be integrated with other instructions that are expressed according to a different protocol or language than the function call is expressed. Some function calls may include an input parameter or value. In various example embodiments, the application module 108 is to receive a function call from the email machine 112 (e.g., from the function module 118, discussed below) and may return an output based on the received function call. In some example embodiments, the function call is based on an email message originally from the client machine 104 that may include a function command and input data associated with the function call.
The email machine 112 is to allow the operation of the communication module 114, the validator 116, the function module 118 and the application module 120, which the email machine 112 is shown to include. For some example embodiments, one or more of the communication module 114, the validator 116, the function module 118 and the application module 120 may be implemented outside or independent of the email machine 112.
The communication module 114 is to receive email messages from the client machine 104 and/or the email server 106, via the transmission media 103. The communication module 114 may further transmit various data from the email machine to machines that are communicatively coupled to the network 102. In an example embodiment, the communication module 114 may receive a function call from the function module 118 (discussed below) and transmit the function call to the application module 108. Alternatively or additionally, the communication module 114 may receive a function output from the application module 120 (discussed below) and transmit the function output to the client machine 104 or any other machine communicatively coupled to the network.
The example validator 116 may validate a sender of an email message received by the email machine 112. For some example embodiments, the validator 116 includes instructions to identify validation information sent with or associated with an email message and determine whether the sender is valid, based on the identified validation information (e.g., embedded within the email message). Validation may include authentication (e.g., determining that the sender is who the sender says the sender is) and if authenticated, ensuring that the sender is authorized regarding a service, action or access (e.g., authorized to cause a function to be executed). There are currently several techniques used to validate email from a sender. In an example embodiment the validator 116 may include instructions to implement a digital signature technique for providing validation. An example validation technique is discussed in more detail with respect to
In an example embodiment, a purpose of a digitally signed email message 212 includes authenticating the sender of an original email message 202 and ensuring that the content of the original email message 202 has not been altered from its original form.
In some example embodiments, fingerprint instructions 206 (e.g., a hash algorithm) are to generate a fingerprint of the original email message 208 based on the original email message 202. Public key infrastructure (PKI) 204 information may include a private key, a public key and a certificate for the public key. The certificate for the public key may ensure that a particular sender is associated with the public key. In an example embodiment, the sender may attach the certificate to an email message before sending the email. The certificate may be stored in a sender's machine (e.g., computer or handheld device) at a hardware level (e.g., a CPU), in the sender machine's storage hard-drive or in the email server. The digital signature instructions 210 may encrypt the fingerprint of the original email message 208 using the private key of the PKI information, and combine the certificate, the public key and the encrypted email fingerprint. An example result of the above described combination is shown to be a digitally signed email message 212.
On the receiver side 230, the example digitally signed email message 212 may be divided into a received email message 214 portion and a digital signature 216 portion. The fingerprint instructions 218 may generate a fingerprint of the received email message 220 based on the received email message 214. Decryption instructions 221 may decrypt the fingerprint of the original email message 208 based on the public key within the digitally signed document.
In an example embodiment, if the validation instructions 224 determine that the fingerprint of the received email message 220 matches the fingerprint of the original email message 222, the validation instructions 224 may determine (e.g., with a degree of confidence) that the received email message 214 has not been corrupted, either deliberately or accidentally. The validation instructions 224 may further determine (e.g., with a degree of confidence) that the claimed sender (e.g., identified by the sender's email address) actually did send the email message.
The certificate 223 for the public key may be obtained from the digital signature 216 by the validation instructions 224. In some example embodiments, the validation instructions may reference a trusted third party that issued the certificate 223 who may verify that the sender of the received email message 214 (e.g., who may be identified by the sender's email address) is associated with the public key used to decrypt the encrypted fingerprint of the original email message 208. Alternatively or additionally, the certificate 223 may be used to determine whether the sender who has used the public key is the same sender (e.g., has the same email address) who has been issued the private key used to create the digitally signed email message 212.
If the validator 116 of
If the validator 116 of
The function module 118 of
The application module 120 may optionally provide function output in response to an email message embedding a function command and input data. In some example embodiments, the function output may be provided by the application module 120 within the email machine 112, which also receives the email message. Alternatively or additionally, as described above, the application module 108 may generate the function output after receiving a function call or other function related data from the email machine 112 via function module 118, the communication module 114 and the transmission media 103 of
The data repository 122 may further contain account information related to a sender of the email message and/or a receiver of the email message. In an example embodiment, the application module 120 is to identify a payor account associated with an email address (e.g., belonging to the sender) and a payee account associated with an email receiver (e.g., belonging to the payee). Based on a payment function embedded within the email message, the application modules 108 and/or 120 may access a data repository such as the data repository 122 to credit the payee's account with funds from the payor's account.
At block 302, the method 300 may include the communication module 114 receiving an email message from a sender operating the client machine 104 of
At block 304, the method 300 may include the validator 116 determining whether the sender is a valid sender or an invalid sender, based on validation data associated with the email message.
Referring to
In example embodiments in which the email message is digitally signed, the validation data may further include a fingerprint of the original email message that is encrypted with the public key associated (e.g., registered via the sender's email address) with the sender.
Responsive to receiving the validation data, the validator 114 may: fingerprint the received email message; decrypt the fingerprint of the original email message with the public key; and determine whether the decrypted fingerprint of the original email message matches the fingerprint of the received email address. In an example embodiment, a match between the fingerprints of the received and original email message indicates a valid sender.
In some example embodiments, the validator 116 may obtain the registered email address and to determine validation, the validator 116 may determine whether the sender email address matches the registered email address.
In various example embodiments, an email address such as “payor@webmail.com” in the “From” field 402 may be associated with a value holding account. For example, an email address may be an identifier for a bank account, credit account, gift account, rewards account and the like.
The email message interface 400 is further shown to include a “To” field indicating that the email message interface 400 is to a user with the email address: “server@function.” It may be noted that a user may include a human user and/or a user that is a machine or a program based on instructions executed by a processor. For some example embodiments, a user with the email address in the “To” field 404 includes a secure server (e.g., such as the email machine 112 of FIG. 1) that may initiate execution of a function based on the email message interface 400.
The email message interface is further shown to include a “Subject” field 406 indicating a subject of an email message. The “Subject” field is shown to include the subject “Pay $30 to payee@internetmail.com.” In various example embodiments the “Subject” field may include the function commands and/or input data that have been described above. For example, function commands may include the words “Pay” and “To” while input data may include the strings “$30” and “payee@internetmail.com.”
In an example embodiment that includes a payment from one user to another, both the email address associated with the “From” field 402 and an email address associated with the “Subject” field 406 may each identify a value holding account of any type. Of course, users' email addresses are not limited to being associated with a value holding account. Any entity or subject matter may be associated with an email address without departing from the claimed subject matter.
Referring again to
If the sender is determined to be a valid sender, the example method may continue with block 306. At block 306, the example method 300 may include the function module 118 identifying function data included within the received email message and at 308, input data associated with the function data. The identification of function and input data may occur in parallel (e.g., simultaneously) or in series (e.g., one after another).
Alternatively or additionally, input data may be provided or retrieved from other than the email message. In an example embodiment, the function module 118 is to request input data from a machine connected to the network 102 such as the data repository 122. The particular input data provided or retrieved may depend on the function data included in the email message.
In example embodiments, the function module 118 is to identify a function command (e.g., “Pay,” “To” or any other function command) in the subject field of the email message, and identify the input data in the subject line of the email message (e.g., “$30,” “payee@internetmail.com,” any dollar or currency amount, any recipient or any other type of function input).
At block 310, the method 300 may include the function module 118 initiating the execution of a function, based on the function data and the input data. In some example embodiments, the example function module 118 is to generate a function call associated with the example function command and the input data. The example function module 118 may then forward the function call to the example application module 108 or 120 both of
Returning to block 304 of
At block 502, the example method 500 may include the application module 120 accessing the data repository 122 of
At block 504, the example method 500 may include the example application module 120 determining that the function command is a payment command (e.g., as described above) allowing the sender to make a payment to a payee associated with a payee name. At block 506, the example method 500 may include the application module 120 identifying an amount to be paid and the payee name in the input data (e.g., as described above).
At block 508, the example method 500 may include the application module 120 accessing the data repository 122 to identify a value holding account associated with the payee name. At block 510, the example method 500 may include the application module 120 crediting the further value holding account with the amount determined from the input data.
If the validator 116 of
At block 602, the example method 600 may include the validator 116 of
At block 604, the example method 600 may include the validator 116 of
At block 606, the example method 600 may include validating the sender based on determining that the alias email addresses is associated with at least one of the registered email address and the public key. If the alias email address is associated with the sender email address and the registered email address, the alias email address may indicate a valid sender. Alternatively or additionally, if the public key associated with the registered email address is also associated with the alias email address, the sender may be determined to be valid.
At block 608, the example method 600 may include the validator 116 invalidating the sender based on making a determination that any identified alias email addresses are not associated with either the registered email address or the public key.
A networked system 702, in the example forms of a network-based marketplace or publication system, provides server-side functionality, via a network 704 (e.g., the Internet over a WAN) to one or more clients.
An Application Program Interface (API) server 714 and web servers 716 are communicatively coupled to, and provide programmatic and web interfaces respectively to, one or more application servers 718. The application servers 718 host one or more marketplace applications 720 and payment applications 722.The application servers 718 are, in turn, shown to be coupled to one or more databases servers 724 that facilitate access to one or more databases 726.
The marketplace applications 720 and the payment applications 722 may exist in a production environment, where the applications 720 and 722 provide functions and services associated with actual commercial activity relating to subject matter of value and real users or entities. Alternatively or additionally the marketplace applications 720 and the payment applications 722 may exist in a testing environment (e.g., testing of API calls) associated with fictitious commercial activity relating to fictitious subject matter and fictitious users or entities.
The marketplace applications 720 may provide a number of marketplace functions and services to users that access the networked system 702. The payment applications 722 may likewise provide a number of payment services and functions to users. The payment applications 722 may allow users to accumulate value (e.g., in a commercial currency, such as the U.S. dollar, or a proprietary currency, such as “points”) in accounts, and then later to redeem the accumulated value for products (e.g., goods or services) that are made available via the marketplace applications 720. While the marketplace and payment applications 720 and 722 are shown in
Further, while the system 700 shown in
The programmatic client 708 accesses the various services and functions provided by the marketplace and payment applications 720 and 722 via the programmatic interface provided by the API server 714. The programmatic client 708 may, for example, be a seller application (e.g., the TurboLister application developed by eBay Inc., of San Jose, Calif.) to enable sellers to author and manage listings on the networked system 702 in an off-line manner, and to perform batch-mode communications between the programmatic client 708 and the networked system 702.
The web client 706 may access the various marketplace and payment applications 720 and 722 via the one or more web interface supported by the web servers 716. As described above, the example web client 706 (e.g., a web browser) may be used an interface to submit API calls and related information for the purpose of testing an API call.
Alternatively or additionally, the third party application 728 may, utilizing information retrieved from the networked system 702, support one or more features or functions on a website hosted by the third party. The third party website may, for example, provide one or more promotional, marketplace or payment functions that are supported by the relevant applications of the networked system 702.
The networked system 702 may provide a number of publishing, listing, and price-setting mechanisms whereby a seller may list (or publish information concerning) goods or services for sale, a buyer can express interest in or indicate a desire to purchase such goods or services, and a price can be set for a transaction pertaining to the goods or services. To this end, the marketplace applications 720 are shown to include at least one publication application 800 and one or more auction applications 802 which support auction-format listing and price setting mechanisms (e.g., English, Dutch, Vickrey, Chinese, Double, Reverse auctions etc.). The various auction applications 802 may also provide a number of features in support of such auction-format listings, such as a reserve price feature whereby a seller may specify a reserve price in connection with a listing and a proxy-bidding feature whereby a bidder may invoke automated proxy bidding.
One or more of the applications 720 and 722 may allow an email message from a client machine 710 and/or 712 (e.g., carrying a function command and input data) to make use of functionality provided by one or more of the other applications 720 and 722.
A number of fixed-price applications 804 support fixed-price listing formats (e.g., the traditional classified advertisement-type listing or a catalogue listing) and buyout-type listings. Specifically, buyout-type listings (e.g., including the Buy-It-Now (BIN) technology developed by eBay Inc., of San Jose, Calif.) may be offered in conjunction with auction-format listings, and allow a buyer to purchase goods or services, which are also being offered for sale via an auction, for a fixed-price that is typically higher than the starting price of the auction.
Store applications 806 allow a seller to group listings within a “virtual” store, which may be branded and otherwise personalized by, and for, the seller. Such a virtual store may also offer promotions, incentives and features that are specific and personalized to a relevant seller.
Reputation applications 808 allow users that transact, utilizing the networked system 702 of
Personalization applications 810 allow users of the networked system 702 to personalize various aspects of their interactions with the networked system 702. For example a user may, utilizing an appropriate personalization application 810, create a personalized reference page at which information regarding transactions to which the user is (or has been) a party may be viewed. Further, a personalization application 810 may enable a user to personalize listings and other aspects of their interactions with the networked system 702 and other parties.
The networked system 702 may support a number of marketplaces that are customized, for example, for specific geographic regions. A version of the networked system 702 may be customized for the United Kingdom, whereas another version of the networked system 702 may be customized for the United States. Each of these versions may operate as an independent marketplace, or may be customized (or internationalized) presentations of a common underlying marketplace. The networked system 702 may accordingly include a number of internationalization applications 812 that customize information (and/or the presentation of information) by the networked system 702 according to predetermined criteria (e.g., geographic, demographic or marketplace criteria). For example, the internationalization applications 812 may be used to support the customization of information for a number of regional websites that are operated by the networked system 702 and that are accessible via respective web servers 716 of
Navigation of the networked system 702 may be facilitated by one or more navigation applications 814. For example, a search application (as an example of a navigation application) may enable key word searches of listings published via the networked system 702. A browse application may allow users to browse various category, catalogue or inventory data structures according to which listings may be classified within the networked system 702. Various other navigation applications may be provided to supplement the search and browsing applications.
In order to make listings, available via the networked system 702, as visually informing and attractive as possible, the marketplace applications 720 may include one or more imaging applications 816 utilizing which users may upload images for inclusion within listings. An imaging application 816 also operates to incorporate images within viewed listings. The imaging applications 816 may also support one or more promotional features, such as image galleries that are presented to potential buyers. For example, sellers may pay an additional fee to have an image included within a gallery of images for promoted items.
Listing creation applications 818 allow sellers conveniently to author listings pertaining to goods or services that they wish to transact via the networked system 702 and listing management applications 820 allow sellers to manage such listings. Specifically, where a particular seller has authored and/or published a large number of listings, the management of such listings may present a challenge. The listing management applications 820 provide a number of features (e.g., auto-relisting, inventory level monitors, etc.) to assist the seller in managing such listings. One or more post-listing management applications 822 may also assist sellers with a number of activities that typically occur post-listing. For example, upon completion of an auction facilitated by one or more auction applications 802, a seller may wish to leave feedback regarding a particular buyer. To this end, a post-listing management application 822 may provide an interface to one or more reputation applications 808, so as to allow the seller conveniently to provide feedback regarding multiple buyers to the reputation applications 808.
Dispute resolution applications 824 provide mechanisms whereby disputes arising between transacting parties may be resolved. For example, the dispute resolution applications 824 may provide guided procedures whereby the parties are guided through a number of steps in an attempt to settle a dispute. In the event that the dispute cannot be settled via the guided procedures, the dispute may be escalated to a third party mediator or arbitrator.
A number of fraud prevention applications 826 implement fraud detection and prevention mechanisms to reduce the occurrence of fraud within the networked system 702.
Messaging applications 828 are responsible for the generation and delivery of messages to users of the networked system 702, such messages for example advising users regarding the status of listings at the networked system 702 (e.g., providing “outbid” notices to bidders during an auction process or to provide promotional and merchandising information to users). Respective messaging applications 828 may utilize any one have a number of message delivery networks and platforms to deliver messages to users. For example, messaging applications 828 may deliver electronic mail (e-mail), instant message (IM), Short Message Service (SMS), text, facsimile, or voice (e.g., Voice over IP (VoIP)) messages via the wired (e.g., the Internet), Plain Old Telephone Service (POTS), or wireless (e.g., mobile, cellular, Wi-Fi, WiMAX) networks.
Merchandising applications 830 support various merchandising functions that are made available to sellers to enable sellers to increase sales via the networked system 702. The merchandising applications 830 also operate the various merchandising features that may be invoked by sellers, and may monitor and track the success of merchandising strategies employed by sellers.
The networked system 702 itself, or one or more parties that transact via the networked system 702, may operate loyalty programs that are supported by one or more loyalty/promotions applications 832. For example, a buyer may earn loyalty or promotions points for each transaction established and/or concluded with a particular seller, and be offered a reward for which accumulated loyalty points can be redeemed.
The email function application 834 in example embodiments may allow a sender to use functionality provided by one or more of the applications 720-722. For some example embodiments, the email function applications 834 may receive an email message from a client machine 710 or 712, process the email message and forward a function call to the one or more applications 720, 722 on behalf of the sender of the email address.
A validation table 903 may include tables referenced for the purpose of validating a sender of an email message. The validation table 904 may be linked with the user table 902. Similar to the technique described above with respect to the validator 116 of
A function mapping table 905 may be accessed to associate a function command in an email message to a function call used to elicit a function from a particular application. The function mapping table 905 may be linked to the validation table 903. In an example embodiment, access to the function mapping table 905 is depends upon on whether a sender is considered to be a valid sender.
The tables 900 also include an items table 904 in which are maintained item records for goods and services that are available to be, or have been, transacted via the networked system 702 of
A transaction table 906 contains a record for each transaction (e.g., a purchase or sale transaction) pertaining to items for which records exist within the items table 904.
An order table 908 is populated with order records, each order record being associated with an order. Each order, in turn, may be with respect to one or more transactions for which records exist within the transaction table 906.
Bid records within a bids table 910 each relate to a bid received at the networked system 702 of
The example computer system 1000 includes a processor 1002 (e.g., a CPU) a graphics processing unit (GPU) or both), a main memory 1004 and a static memory 1006, which communicate with each other via a bus 1008. The computer system 1000 may further include a video display unit 1010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1000 also includes an alphanumeric input device 1012 (e.g., a keyboard), a cursor control device 1014 (e.g., a mouse), a disk drive unit 1016, a signal generation device 1018 (e.g., a speaker) and a network interface device 1020.
The disk drive unit 1016 includes a machine-readable medium 1022 on which is stored one or more sets of instructions 1024 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 1024 may also reside, completely or at least partially, within the main memory 1004 and/or within the processor 1002 during execution thereof by the computer system 1000, the main memory 1004 and the processor 1002 also constituting machine-readable media.
The instructions 1024 may further be transmitted or received over a network 1026 via the network interface device 1020.
While the machine-readable medium 1022 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present subject matter. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media and carrier wave signals.
The above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments (or one or more aspects thereof) may be used in combination with each other. Other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the claims should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on subject matter.
The Abstract is provided to comply with 37 C.F.R. §1.72(b), which requires that it allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
