Patent Application
20170270589
The present invention relates to shopper assistance and physical analytics, and more particularly, to techniques for making shopping recommendations based on a user's social ties to friends and family.
Analyzing physical browsing of users in brick and mortar stores enables one to better understand user behavior in the physical world and to leverage that knowledge in assisting users in their shopping decisions. Techniques have been proposed to analyze a shopper's purchase history. See, for example, U.S. Pat. No. 6,129,274 issued to Suzuki, entitled “System and Method for Updating Shopping Transaction History Using Electronic Personal Digital Shopping Assistant.” Techniques have also been proposed for suggesting a shopping route based on prior shopping history. See, for example, U.S. Patent Application Publication Number 2008/0154720 by Gounares et al., entitled “Shopping Route Optimization and Personalization.”
Current solutions for analyzing shopping decisions focus primarily on the preference of an individual shopper and base recommendations on the shopper's past shopping history. Shopping decisions, however, aren't always based solely on the shopper's preferences. For instance, current solutions do not assist users in their shopping decisions in relation to their family and/or friends. Take for example the situation where a user is shopping for an item for a family member or friend, e.g., as a gift, as an item the family member/friend needs at home, etc. No system currently exists for making shopping recommendations for the user's family/friends.
Accordingly, improved techniques for making shopping recommendations based on a user's preferences, as well as the preferences of the user's family and friends, would be desirable.
The present invention provides techniques for making shopping recommendations based on a user's social ties to friends and family. In one aspect of the invention, a method for making shopping recommendations is provided. The method includes the steps of: collecting shopping data from users, wherein the users comprise a first user and one or more second users with social ties to the first user; and making recommendations to the first user based on the shopping data while the first user is shopping at a store, wherein the recommendations include preferences of the second users with social ties to the first user.
In another aspect of the invention, a system for making shopping recommendations is provided. The system includes: at least one store having a recommendation engine configured to: collect shopping data from users, wherein the users comprise a first user and one or more second users with social ties to the first user; and make recommendations to the first user based on the shopping data while the first user is shopping at the store, wherein the recommendations include preferences of the second users with social ties to the first user.
A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.
As provided above, shoppers can be aided by tools that make recommendations to the shopper based on their past purchases. For instance, when a user is shopping at a grocery store, the user's past shopping history at that store can be leveraged to make recommendations about what the user should pick up on their current visit. For example, if the user typically buys milk, bread and eggs at every visit to that store, then it would be helpful to remind the user if he/she has forgotten to pick up any of these items. Stores typically track purchases made by a user, such as through a loyalty card, therefore purchase history data is readily available.
Tracking an individual user's purchase history to make shopping recommendations is, however, only one aspect of a shopping experience. Users regularly make purchases based on other's preferences and past shopping histories, such as those of their family and friends. To date, no solutions exist for a user to take into account the shopping preferences of his/her family/friends in a seamless manner.
For instance, when shopping for a household, a user might not know what other family members typically purchase. As a result, the user might miss items and/or buy items, brands, etc. that are not what other family members want. Also, other family members might have an established shopping route through a particular store that enables them to easily find the items they like (i.e., based on a given layout of the store) and/or to seek out particular deals, specials, etc. It would be desirable for a person to be able to leverage this information to use this same route through the store, vastly cutting down on the time needed to find each of these items in a random fashion. That way, even if a user is unfamiliar with a particular store, he/she can easily determine what (and where) each item that members of the family typically buy is in the store.
Another example might be a situation where a user wants to buy a gift for a friend or family member. When visiting a store, the user would greatly benefit from knowledge about which items in the store, areas of the store, etc. that friend or family member typically purchases or visits. This information would help reduce the guessing in making the purchase. Also, for example, say that a user sees an item at a store that he/she knows a family member or friend might like to purchase. There is currently no convenient way to alert the family member/friend when they visit that store about the item.
Advantageously, provided herein are techniques for identifying family and friends of a user, and for leveraging family and friend preferences in making shopping recommendations to the user. The present techniques employ smart mobile technology (e.g., smart phone, smart watch, smart glasses, etc.) to establish connections between users (i.e., to determine family and friend connections), collect shopping preference data, and make shopping recommendations.
The present techniques enable customized shopping assistance to aid shoppers by leveraging their physical analytics data. For instance, when shoppers are not sure of what to buy, the present system reminds them of the items bought in the past and their locations in the store, along with recommended items (e.g., similar items, items which are on sale, or when they will go on sale, etc.). The present system allows family physical browsing data to be used automatically using mobile phones, i.e., family and social ties are automatically detected and can be used to help shoppers in deciding what to buy and where in store to pick up the items from. Some other notable benefits of the present system include: enabling usage of data from user end as well as store end from multiple store locations visited by user, e.g., using data from all of a particular brand of stores visited by user, and data collected both on the user's smart mobile device(s) as well as the store's purchase tracking system, surveillance system, etc.; reducing the amount of data to be shipped to the server by processing the raw data locally at the mobile device itself; helping shoppers not to forget to buy the items they need.
A description of the present system architecture 100 and implementation details are now described by way of reference to
It is further assumed that Store 1, Store 2, and Store 3 share data related to the shopping preferences of user 102 and family/friends 104 of user 102. For instance, according to one exemplary embodiment, Store 1, Store 2, and Store 3 are separate units of the same chain (e.g., units with the same chain of grocery stores, department stores, etc.). However, other cooperative data sharing structures can be envisioned. For instance, stores within the same shopping center, state, city, town, etc. can share shopper preference data in the manner described herein.
Referring now to methodology 200 of
By way of example only, a (predetermined) threshold can be set for the number of times two (or more) mobile devices are spotted in the same store at the same time to establish a social tie between the respective users. For instance, the threshold can be anywhere between 3-10 times for a given (predetermined) time period, e.g., from about 1 week to 1 month. Setting a threshold will eliminate erroneous connections made merely by chance. To use a simple example, if the mobile devices of a User A and a User B are detected in the same store more than 5 times within a one month period, then it may be assumed that User A and User B have social ties to one another. It is unlikely that strangers would happen to be in the same place at the same time more than 5 times in a month-long period. Additional mechanisms can also be implemented to prevent erroneous ties between users. By way of example only, the condition can be imposed that users (e.g., User A and User B) shop at multiple (i.e., more than one) stores together. Also, the user whose preferences are to be shared with his/her friends could be asked if he/she would like the products to be recommended to a particular person.
It may be the case that some users with social ties do not shop together. However, as mentioned above, many stores issue shoppers loyalty cards. These cards are uniquely tied to an individual shopper and are typically registered whenever the shopper makes a purchase. Further, family members might, as a group, get loyalty cards tied, e.g., to the same account. Thus, establishing social ties might be done simply by determining which loyalty cards are on the same account.
Other metrics are anticipated herein for establishing social ties amongst users that take into account a variety of different shopping habits, and apply to many real-world scenarios. For instance, users with social ties often might not visit a store at the same time. For example, family members often shop at different times based on their individual work, school, etc. schedules. Even if users shop in a store at the same time, they often linger at different parts of the store while shopping. As will be described in detail below, techniques are presented herein for employing user trajectory analysis to determine social ties. Namely, current mobile technology permits tracking of user movements via a series of time-stamped locations, referred to in the art as ‘trajectories.’ See, for example, Zheng et al., “GeoLife: A Collaborative Social Networking Service among Users, Location and Trajectory,” IEEE Data Eng. Bull. 33(2):32-39 (2010), the contents of which are incorporated by reference as if fully set forth herein. Thus, trajectories permit the collection of a knowledge base of location history for users.
According to an exemplary embodiment, data relating to the social ties of the users (as well as the purchasing history/shopping preferences of the users) is stored locally in each of the stores—e.g., in a recommendation engine (see local Recommendation Engines 1, 2, 3, in Stores 1, 2, 3, respectively, in
In step 204 (of
As highlighted above, the presence of a user in a given store can be established via the mobile device(s) the user carries on their person. Other ways for establishing the presence of a user at a store can include use of a loyalty card by the user. Further, some stores may have a kiosk or desk where users can check in using their loyalty card. As an incentive, users may be given coupons, suggestions for items (based on their preference and/or the preference of their social ties), etc. when they check in. Thus, according to an exemplary embodiment, methodology 200 (of
It is notable that, while the instant description presents a series of steps, it is to be understood that the various tasks described may be performed simultaneously and/or in an order different than described/depicted. For example, according to methodology 200 (of
In step 206 (of
Other useful data that may be obtained in step 206 is the user's browsing path through the store. For instance, it may be useful to know which departments, sections, aisles, etc. of the store the user visits, how frequently, and how long the user spends browsing these sections. Sections of the store that the user browses most frequently can be assumed to be of interest to the user. Further, the browsing history of the user might be helpful in establishing purchasing/browsing patterns. For instance, a particular user might routinely take a certain path through a grocery store which enables them to find the items, brands, specials, they want. This data can be leveraged to inform other users with social ties an efficient route through the store to find these items.
The browsing path data can be obtained using, for example, the store's surveillance system. For instance, stores typically employ camera systems to monitor shoppers. Shoppers might consent to those images being used to determine their movements throughout the store. Tracking algorithms are well known in the computer vision field that can be used to monitor movements based on images from the surveillance system. See, for example, Yilmaz et al., “Object Tracking: A Survey,” ACM Computing Surveys, vol. 38, no. 4, Article 13, pgs. 1-45 (December 2006), the contents of which are incorporated by reference as if fully set forth herein. Additionally, electronic beacons may be used throughout the store which send identifier data (via Bluetooth technology) to users' mobile devices when in close proximity. Thus, a shopper's route through the store may be established based on the beacons the shopper's mobile device passes.
From the above, it is apparent that the data collection process can involve data collected from the store side (e.g., surveillance data, loyalty card data, store-provided scanner data, etc.) as well as data collected by the shopper (e.g., mobile device data, such as shopping lists, mobile app barcode scanned data, photos, etc.). In order to enhance their shopping experience, users might consent to this data collected via their mobile devices to be retrieved by the store. This data retrieval is performed in step 208.
Other data that can be obtained from the user in step 206 relates to products the user specifically marks/tags as being something the user likes. Namely, as will be described in detail below, the present techniques offer users the option to mark products while shopping that the user likes. The users can then go back at their leisure (so as not to interrupt their shopping experience) and validate/provide the reasons why they liked a particular product (e.g., it is a good product, it is on sale, the coffee from a particular coffee machine is hot, the size of the table is right for a mid-size living room, etc. this information is much richer than marking the products you see online, as in the brick and mortar retail store, you get to describe the look and feel as well and that is the power of this system). This data can then be used in making recommendations to the users' social ties. According to an exemplary embodiment, this marking process is carried out locally in each of the stores—e.g., via a marking engine (see local Marking Engines 1, 2, 3, in Stores 1, 2, 3, respectively, in
In step 210, the data collected from the store side (e.g., via step 206) and/or the data collected from the shopper/user side (e.g., via step 208) is then analyzed to determine shopping preferences. For instance, in its simplest form, the list of items the user purchased is used in step 210 to establish a list of products favored by the user. However, as provided above, the present process is performed in an iterative manner, and data is collected every time the user shops at the store(s). Thus a more detailed shopping history can be established using archived data which reflects shopping trends, preferences etc. over time. For example, the user might purchase a certain item on one visit, and then never again. That might in fact indicate that the user didn't like the product, and thus is not something to recommend for future purchase. The user might purchase a particular item(s) only at certain times of the year, such as certain produce in the summer, or certain clothing (e.g., jackets, hats, etc.) in the winter. By evaluating a purchase history, these trends can be revealed.
As highlighted above, browsing history can also provide useful information. For example, the particular browsing patterns the user and/or the user's family/friends take through a particular store or chain of stores can help establish preferences. For instance, individual units within the same chain of stores often have a similar layout. Thus, the browsing history in one unit can be useful for making recommendations for other units. Further, even if the layouts of the units differ, the present analysis can zero in on the particular departments, sections, etc. the users visited (and preferably in what order, how frequently, etc.).
Based on the analysis performed in step 210, recommendations are made to the user about his/her shopping preferences and those of the users he/she has social ties to. For instance, the user's own preferences may be used to make recommendations based on past purchases to remind the user not to forget to purchase something they may need, to make suggestions for things the user might like, etc. These recommendations can extend beyond products the user has purchased in the past. For instance, based on the user having purchased an item X in the past, the present techniques may be employed to suggest another product of the same brand, type, use, that the user might like, another brand of the same type of product that might currently be on sale, etc.
Regarding recommendations of products purchased by family/friends, the user might not know what items his/her family/friends like to purchase. With the present techniques, the data collected from those having social ties to the user can be used to make recommendations for purchases. Take for instance the example from above where a user is shopping for a household, the user might not know the items, brands, quantity, etc. each of the members of the household likes. Without guidance, the user would likely miss a number of these items (or purchase an incorrect brand, quantity, etc.) he/she needs to purchase for the household. The same applies in situations where a user might be purchasing a present for a family member or friend. The present techniques can provide recommendations based on the user's family/friends previous purchases and/or browsing history.
Further, the user might not be shopping for another, but the user might have similar tastes as a family member or friend. The user might benefit from knowing what the family member or friend found interesting at a store so that the user might consider the product as well. If the user seeks out the product then, based on the present techniques, that product can be associated with the user him/herself and/or be available for recommendation to other family/friends of the user, etc.
The recommendations can be made to the user in step 210 in a variety of different ways. For instance, recommendations can be made to the user via his/her mobile device. For instance, using
Alternatively (or addition to) sending mobile device messages, the user might be able to retrieve recommendations via a monitor, printout, etc. provided at a front desk of the store and/or kiosks at one or more locations in the store. Users can be uniquely identified based, for example, on their loyalty card, mobile device signatures, etc.
As provided above, and as shown in
As noted above, users are given the option of whether or not they want their data collected and/or shared. This can be regulated at different levels. For instance, a user might opt out of the process altogether. In that case, data will not be collected from that user and the user will not receive data about other users to which he/she has social ties. Alternatively, a user might consent to his/her data being collected and recommendations being made based on his/her own past purchases, but not to share any of this information with family/friends. Alternatively, a user might consent to collecting/receiving/sharing all shopping data with family/friends.
As provided above, user trajectory analysis may be leveraged herein to determine social ties amongst users. As noted above, in many real-world scenarios users with social ties often do not shop together. For instance, they often shop at different times or, when together in the same store, they often browse in different areas. In order to tie these users, an exemplary methodology 300 is provided in
Namely, as shown in step 302 of methodology 300 (of
For instance, in step 304 of methodology 300 (of
Another useful metric that can be used to establish social ties amongst users is determining whether the users appear at the store checkout counter together. See step 306 of methodology 300 (of
So, for instance, two users (who are shopping at the same time) might browse different parts of the store. However, their ties can still be recognized based on their meeting up at the checkout counter when they are ready to leave the store. It may be useful to set a threshold number of occurrences. For instance, it may be meaningful to look at users whose appear together at the checkout counter more than once over a month-long period. That way, chance encounters can be eliminated.
Another useful metric is whether the users have shopped together in other locations of the same store in the past. See step 308. If 2 (or more) users have been detected together at other locations of the store, then it becomes increasingly more likely that these users have social ties.
A determination may also be made in step 310 as to whether the users appear at the same store at different times of the day and/or week. Basically, just like looking if the two users shop together at different locations of the store together, this metric is checking if the users shop together at the store at different times of the day, or different days of the week. This is also to eliminate chance encounters. For instance, it is possible that two unrelated users shop at a store every Sunday at 10 AM. But it is more unlikely that the same two unrelated users shop at a store every Sunday 10 AM and every Wednesday at 3 PM. If two users are spotted together at different times (in the same store) then they are likely to be related.
Each of these qualifiers (from steps 304-310) helps in automatically determining the likelihood of social ties amongst users. For instance, if the data collected indicates that two users are in close proximity to one another while browsing, check out together, and have shopped together at other locations in the past, then it is considered more likely than not that the users have social ties. By comparison, if two users happen to browse similar areas but are not present together at checkout, and have not shopped other locations together before, then it may be assumed that the similar browsing pattern is just a coincidence, and it is likely that no social ties exist. As will be described in detail below, weighting factors can be assigned to each qualifier based, e.g., on a learning algorithm of past recommendations or direct observation.
As noted above, it may be that case that users with social ties simply do not shop at the same time. However, knowing their connection is useful. In that case, one may explore whether these users look for similar types of products. To do so, one may leverage users' shopping trajectories. See step 312. Like the user trajectories, shopping trajectories relate to a specific location and time. In this case, however, one is interested in the items the user browses, picks up, etc. The items in a store are generally in a fixed location. Thus, for instance, user similarities may be governed by the items in the store they pick up in common, even if they shop at different times. A standard similarity score can be used to establish commonality based, for example, on the number of items purchased in common. Thus, to use a simple example, if User A and User B pick up only 1 item in common, the similarity score would be below a (predetermined) threshold, and no commonality might exist. However, being above the threshold score (i.e., the users have picked up multiple items in common) might indicate social ties. Again, it is noted that the various factors can be considered together in making the determination. Thus, for instance, without any other indicators of commonality, purchasing many of the same items might not be considered sufficient to socially tie 2 users. Other algorithms like dynamic time warping can also be used to measure the distance between the locations that the two users visited in their trajectory.
Based on the above-described trajectory-based metrics, in step 314 of methodology 300 (of
The weights assigned to the features can be application-specific. For instance, user shopping patterns can vary depending on the types of store, location, etc. and thus different factors can be useful in determining social ties. For instance, users might browse differently in a supermarket than they would in a convenience store, or a clothing store, or a department store that has a variety of different categories of products. According to one exemplary embodiment, weights are assigned to the features using a learning algorithm that evaluates past social ties based on the value of the recommendations. Thus, for instance, the process might begin with all of the above-described features being given an equal weight. However, it is found over time that the recommendations based on social ties drawn using some of the features are better than those drawn using other features. The features can then be weighted accordingly to yield more meaningful recommendations.
Alternatively, in another exemplary embodiment, volunteers can be recruited to explicitly get the ground truth. For instance, shoppers can be asked to evaluate the recommendations via their mobile devices. A volunteer shopper can be given recommendations as they browse the store such as “you might like this product” or “this product is on sale.” The volunteer shopper can then evaluate the recommendation, such as accept, dismiss, apply a rating system, etc. Incentives can be provided to the volunteers for their compliance, e.g., via coupons, gift cards, etc. This can help weight the usefulness of the several heuristics explained above in detecting social ties.
As provided above, the present techniques leverage a user's shopping preference data. In that regard, methodology 400 of
The ability to ‘like’ content online is widely used. In the physical context of shopping, it is more powerful as the user can see, feel, test out the product, etc. However, the user might not want to take the time while browsing the store to stop and tell social ties why the user likes this product. The present techniques offer the advantage to permit users to quickly/easily mark products while they are shopping (e.g., by taking a picture, scanning a barcode, etc.) and then, when at leisure, the user can provide details on why he/she has tagged a certain product.
Namely, in step 402 of methodology 400 (of
In step 404 of methodology 400 (of
In step 406 of methodology 400 (of
It might also be useful to know whether the product is popular with other users. For instance, the user might have marked the product since it is a popular newly released book, movie, etc. This information would be useful in making recommendations to the user's social ties.
When it is detected that the user is at leisure, in step 408 of methodology 400 (of
By way of example only, the user can be presented (on his/her mobile device) with the marked products and a selection of the reasons for marking the products. The user can then select the right reason (or provide another reason). According to an exemplary embodiment, this validation process can be presented to the user in the form of a game wherein (optionally) incentives to participate can be offered (such as coupons, gift cards, etc.). Feedback regarding how many of the recommended products the user's social ties found useful (e.g., purchased, liked, etc.) can be used to judge the user's score, and the incentives can be provided accordingly.
Finally, in step 410 of methodology 400 (of
The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
Turning now to
Apparatus 500 includes a computer system 510 and removable media 550. Computer system 510 includes a processor device 520, a network interface 525, a memory 530, a media interface 535 and an optional display 540. Network interface 525 allows computer system 510 to connect to a network, while media interface 535 allows computer system 510 to interact with media, such as a hard drive or removable media 550.
Processor device 520 can be configured to implement the methods, steps, and functions disclosed herein. The memory 530 could be distributed or local and the processor device 520 could be distributed or singular. The memory 530 could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. Moreover, the term “memory” should be construed broadly enough to encompass any information able to be read from, or written to, an address in the addressable space accessed by processor device 520. With this definition, information on a network, accessible through network interface 525, is still within memory 530 because the processor device 520 can retrieve the information from the network. It should be noted that each distributed processor that makes up processor device 520 generally contains its own addressable memory space. It should also be noted that some or all of computer system 510 can be incorporated into an application-specific or general-use integrated circuit.
Optional display 540 is any type of display suitable for interacting with a human user of apparatus 500. Generally, display 540 is a computer monitor or other similar display.
Although illustrative embodiments of the present invention have been described herein, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope of the invention.
