Patent Application
20150180857
The present invention is related to providing a service to manage users in websites or apps, and more particularly, to ensure said providing is done in a simple, secure, and spam-free manner. Furthermore, the present invention also enables the easy integration of third-party services that utilize managed user data, such as: e-commerce, advertising, payments, content management, and any kind of service that includes user-generated content.
User authentication directly between a user client and an app server, without any other server or third-party service to assist with the process, is well-known in the field. In
The architecture shown in
Unfortunately, spammer attacks have made it increasingly difficult to use the architecture set forth in
The architecture shown in
Another shortcoming of the architecture shown in
Although the architecture set forth in
A system is presented that provides simple and secure user management for websites and applications. While being secure, the system is simple, meaning it can be implemented by developers with minimal difficulty. The system can be used for any type of website or application, including electronic commerce, free or paid content delivery, games, social networks, and services. Furthermore, the system can be used for traditional websites delivered to desktop computers, for mobile websites, and for any kind of native software application including mobile apps.
The system enables simple provisioning of security by leveraging the domain name system. The system can also provision security using cookies. Furthermore, the system enables simple and secure delegation of services involving user information to third-party providers. Examples of such services that can be provided securely by third-parties as enabled by the system include: an e-commerce service, an advertising service, a payment service, a content management service (“CMS”) including user-submitted comments, and a forum service including user-generated content.
A number of embodiments exist for the present invention. They are described below. The following terminology is used in the context of the subject matter described herein.
An entity is a natural person or corporation or partnership other similar legal construct that provides a website or app for users to connect to and use. Such providing can be for-profit or not-for-profit. An entity is usually responsible for the implementation, configuration, and ongoing maintenance of a website or app and its associated components (including one or more app servers).
A user is a natural person connecting to a website or app through a user client. Alternatively, a user may be an agent of the natural person, such as an automated script that performs actions on behalf of the natural person.
A user client is a computing device connected to a global computer network running a software program that allows a user to interact with an app server that is also connected to the global computer network. Examples of user clients include: A laptop computer equipped with the Microsoft Windows operating system and running the Internet Explorer web browser, a touchscreen device such as the Apple iPhone or iPad running the Safari web browser or a software program such as Pandora radio, Bank of America banking application, Facebook social network application, or the CNN news viewer application.
A website or app is a service delivered to a user by an entity. A website or app is usually implemented as a collection of software programs running on one or more app servers.
An app server is a computing device connected to a global computer network running a plurality of software programs that responds to requests from a user client, and in so doing implements a website or app.
A backend-as-a-service (“BaaS”) server is a computing device connected to a global computer network. A BaaS server has the capability to be operated by a first entity, and provided as an arms-length service to a second entity and a third entity without necessarily allowing the second entity to access the data of the third entity. A BaaS server can provide a variety of services, including (but not limited to): a user management service (“UMS”) server, a search service, an RSS service, a payment service, a content management service (“CMS”), an analytics service, a compliance service, a notifications service, an email service, an email marketing service, an A/B testing service, a forum service, a customer-service ticketing service, an advertising service, an affiliate marketing service, a shopping-cart service, an e-commerce service, an operations/status monitoring service, a collaborative filtering service, a recommender service, a queuing service, a robots service, a comments service, and an accessibility service.
A user management service (“UMS”) server is a BaaS server configured to provide user authentication and identity services. An exemplary UMS server is described in detail herein.
A cookie is a small payload of data, associated with a domain name, that can be written to or read from a user client by an app server. A cookie can be used to track the state of a given user client with respect to an app server. In at least one of the embodiments presented herein, cookies can also be written to or read from a user client by a BaaS server, and the cookies are used as a conduit of information between the BaaS server and an app server.
A domain name is a string of characters that uniquely identify a resource or set of resources in a global network. In the present invention, a domain name is used to direct a user client to one or more app servers and one or more BaaS servers that deliver a website or app to a user. The configuration of the domain name is usually exclusively controlled by the entity that delivers the website or app.
A domain name system (“DNS”) is a distributed network of computing devices connected to a global computer network, that translate domain names into IP addresses that are subsequently used to locate and access computing devices such as app servers and BaaS servers. A DNS name server is a server that stores the DNS records for a domain name, such as address (A or AAAA) records, name server (NS) records, mail exchanger (MX) records, canonical name (CNAME) records, and other types of DNS records. A DNS name server responds with answers to queries against its database, much as a phone book can be used to convert a name into a telephone number.
When the user client 16 accesses the BaaS server 17 or app server 18 through an app.com domain name, either server has the capability to read and write cookies to/from the user client, the cookies associated with the app.com domain name. Therefore, the configuration provides a convenient conduit for the app server and the BaaS server to exchange information, including access tokens. Furthermore, since the entity that controls the exemplary app.com domain name is able to exercise control over the DNS that is authoritative over the domain name, then the entity is also explicitly extended the ability to control the existence or absence of the conduit between the app server and the BaaS server to exchange information. For example, if the entity that controls app.com decides to grant or revoke the BaaS server's ability to read and write cookies containing access tokens, then the entity also controls the BaaS server's ability to act as a user management service or provide any other related services to the app server. Therefore, by using cookies to communicate state between the BaaS server and the app server, the app server developer avoids the difficulty and challenges associated with OAuth or other prior art. Instead, the developer may rely upon the cookie mechanism widely available in user clients to pass information accurately and timely between the UMS server and the app server.
It will be understood that there are a number of alternative DNS configurations available with equivalent results. For example, rather than using a CNAME record to direct subdomain.app.com to the BaaS server by referencing its own domain name (baas-server.net in the example shown in
It will also be understood that the present disclosure may be expanded beyond cookies because it is designed for any set of identifiers or configuration that are set using hierarchical namespaces such as domains, class names in code, and configuration that may be shared among related apps on a mobile device, where a BaaS server is granted the right to operate in a namespace by an entity that controls the namespace. Therefore, by using a common mechanism, all groups in the entity may take advantage of the third-party service without having use a mechanism specific to the BaaS server to read the configuration.
The present embodiment enables the BaaS server 17 to act separately on behalf of two or more separate entities, each controlling its own app server and its own domain name. For example, in
Care must be taken when using the configuration set forth in
In step 1, a user client 24 and the app server exchange requests and responses in which the state of the user client is not signed in. During the requests and responses, the app server has the option to write and read cookies to and from the user client within an app.com domain related to the app server. One reason for the app server to write and read the cookies is to track the session of the user client, even before a user has formally signed in to the app server. Many server environments, such as the well-known Linux+Apache+PHP stack, perform this function automatically.
In step 2, a user desires to formally sign into the app server, and requests a registration or signin form. Depending on the configuration desired by the entity that controls the app server, there are a number of variants available to complete steps 2 and 3. The first variant is illustrated in
Once the user submits credentials, the credentials are transmitted by the user client to the UMS server in step 4. The UMS server processes the credentials, and makes a determination as to whether to allow or disallow the request to sign-in or register. A number of methods for making the determination are disclosed herein; in step 5, the UMS server responds with the determination/result, and if registration/signin is allowed, creates an access token and writes a cookie with the access token within the app.com domain. Alternatively, an access token cookie may be preemptively written by the UMS server in step 3 (if using the variant illustrated in
In step 6, the user client sends one or more requests & receives responses to and from the app server. However, in each of the requests, an access token cookie is included in the app.com domain, and the cookie is readable by the app server. The access token is transmitted to the UMS server in steps 7 and 8 to validate the user. If the user is validated, subsequent requests & responses (step 9) between the user client and app server
There are a number of methods of creating an access token. One method is to create an access token related to the user, either by using the user's id itself, by encrypting the id, or by creating a combination of a user's id plus a random or pseudo-random value. Another method, the preferred method, is to create a cryptographic nonce, such nonce being a random or pseudo-random value created by the UMS server and indexed to the user's id, and the nonce being presentable once, and only once, to the UMS server to change the state of the user from being “signed out” to being “signed in”. Therefore, if the nonce is presented a second time to the UMS server with the request to change the state of the user from being “signed out” to being “signed in”, such request will be rejected, which can help avoid security issues related with CSRF attacks and replay attacks.
Once the registration request is received, the UMS server must determine whether to allow or to disallow the registration. Step 28 is to check all registration factors that are pre-configured for the app server. Registration factors that may be pre-configured for each individual app server include: requiring that the registration originates from a page delivered by the UMS server and not forged by an unauthorized server, requiring that the registration parameters be submitted over an SSL or otherwise encrypted connection, requiring the correct answer to a CAPTCHA or similar challenge, performing a unique browser identifier check using Panopticlick or a similar technology, checking that the user reads and accepts one or more legal agreements associated with the app server, checking if the user is already registered, checking that the submitted user email address is valid, checking a reputation of the IP address of the user client, checking if the submitted user name is valid or includes unacceptable words such as known trademarks, checking if the app server is allowing registrations at the time that the registration is submitted, flagging a given registration as requiring further approval by the app server, checking for required parameters (such as first name, last name, username, email, birthday, ZIP code, or other desired combinations), checking if the age of the user meets certain criteria, checking if the location of the user meets certain criteria, checking if the user agent is acceptable, checking if the user (based on an IP address, a session ID, or other indicia) has created too many accounts in a given period of time, checking if the email address is capable of receiving emails, checking if the email address resolves to a blacklist of known spammers, and checking if the entity that owns the app server has paid all due fees to the UMS server entity. In an alternative embodiment, the step 28 may include an additional step wherein the checking of registration factors includes sending a request to the app server with the proposed registration, and receiving from the app server a response indicative of whether to allow or disallow the registration.
If the registration is allowed, a user account and access token are created in step 29. The creation of the user account involves adding a new row or record to a user database with the user information, using any number of well-known techniques and databases such as MySQL. In step 30, the UMS server responds to the user client with an indication that the registration is allowed, and with the access token. In the preferred embodiment, the response is a direct response to the HTTP post from step 27, and the response contains an HTTP “set-cookie” header containing the access token, for the user client to store, the storing of the access token associated with the domain name associated with the HTTP post from step 27. In an alternative embodiment, the response also contains cookies from the app server.
If the registration is disallowed, the UMS server responds to the user client in step 31 with an indication that the registration is disallowed. In the preferred embodiment, a reason for disallowing may be included in the response.
Once the sign-in request is received, the UMS server must determine whether to allow or to disallow the sign-in. Step 33 is to check the credentials against a user database. The checking involves retrieving an existing row or record from a user database with the user information and comparing it to the provided credentials; any number of well-known techniques and databases such as MySQL may be used.
There are a number of alternative credentials available for signing in, including: A digital certificate, a username, a one-time password delivered via a non-browser channel such as email, SMS message, first-party app push notification, third-party app push notification, and a friend's account. The preferred embodiment is an email address and a password.
Step 34 is to check the pre-configured sign-in factors. Such factors are used as additional checks beyond the basic credential, are pre-configured for each individual app server, and include: checking a reputation of a user session associated with the user client, checking the IP address associated with the user client, requiring that the sign-in originate from a page delivered by the UMS server and not from a forged server, requiring that the sign-in credentials be provided over an SSL or otherwise encrypted connection, checking a user agent identifier associated with the user client, checking an OS version identifier associated with the user client, checking a browser software vendor and version associated with the user client, checking an accept-language field associated with the user client, checking a screen resolution field associated with the user client, performing a unique browser identifier check using Panopticlick or a similar technology, checking an ETAG associated with a user avatar, checking the results of a CAPTCHA challenge, checking if the app server is accepting logins, checking if an account associated with the user has been disabled or blocked, checking if an account associated with the user is in good billing standing, checking if an account associated with the app server is in good billing standing, checking if a portion of the credentials have been used too many times within a period of time, checking if a user has provided all required information, and checking that the user reads and accepts one or more legal agreements associated with the app server. In an alternative embodiment, the step 34 may include an additional step wherein the checking of sign-in factors includes sending a request to the app server with the proposed sign-in, and receiving from the app server a response indicative of whether to allow or disallow the sign-in.
In an alternative embodiment, steps 34 and 33 may be performed in reverse sequence. In another alternative embodiment, step 34 may be skipped if step 33 indicates a disallowed sign-in. In another alternative embodiment, step 33 may be skipped if step 34 indicates a disallowed sign-in.
If the sign-in is allowed, a user account is retrieved and an access token is created in step 35. In step 36, the UMS server responds to the user client with an indication that the sign-in is allowed, and with the access token. In the preferred embodiment, the response is a direct response to the HTTP post from step 32, and the response contains an HTTP “set-cookie” header containing the access token, for the user client to store, the storing of the access token associated with the domain name associated with the HTTP post from step 32. In an alternative embodiment, the response also contains cookies from the app server.
If the sign-in is disallowed, the UMS server responds to the user client in step 37 with an indication that the sign-in is disallowed. In the preferred embodiment, a reason for disallowing may be included in the response.
In step 1, a user client 38 and the app server exchange requests and responses in which the state of the user client is not signed in. During the requests and responses, the app server has the option to write and read cookies to and from the user client within an app.com domain related to the app server. The foregoing is analogous to the step 1 disclosed for
In step 2, a user desires to formally sign into the app server, and requests a registration or signin form. Depending on the configuration desired by the entity that controls the app server, there are a number of variants available to complete steps 2 and 3. The foregoing is analogous to the step 2 disclosed for
Once the user submits credentials, the credentials are transmitted by the user client to the UMS server in step 4. The UMS server processes the credentials, and makes a determination as to whether to allow or disallow the request to sign-in or register. A number of methods for making the determination are disclosed herein
If the UMS server disallows sign-in or registration, the UMS server goes to step 7 (skipping steps 5 and 6) and responds to the user client with an indication that the registration or sign-in is disallowed.
If the UMS server conditionally allows sign-in or registration, the UMS server executes step 5 by submitting the proposed sign-in or registration to the app server 40. In addition to submitting the proposed sign-in or registration to the app server, the UMS server may also submit the app.com cookies it received in step 4. By doing so, the UMS server is impersonating the user client 38, so in addition, it may also mimic other aspects of the request from step 4 from the user client. The foregoing impersonating is convenient because many existing web technologies include rudimentary protection against fraudulent requests; therefore, by mimicking the user client, the UMS server enables the app server to continue to use the rudimentary protection without modification.
Step 5 occurs as a request to the app server from the UMS server. The app server must be protected from fraudulent servers posing as the UMS server attempting to fraudulently create or sign-in users. There are many ways to protect the app server, some of which can be used in combination, including: Requiring the use of SSL or other forms of encryption on the registration or sign-in data, requiring the use of a secret shared key between the UMS server and the app server, requiring the request from the UMS server to be submitted through a secret URL on the app server, and requiring the use of the OpenSSL security protocol.
Once the request from step 5 is successfully received by the app server, the app server makes its own determination as to whether to allow or disallow the proposed sign-in or registration. One determination that most app servers will have in common is whether a data processing error occurred; if so, the registration or sign-in will be denied. Other reasons for the own determination as used by the app server are many and varied, and depend on the website or app and its associated entity.
In step 6, the app server responds to the UMS server with an indication as to whether the proposed registration/sign-in is allowed or disallowed. In addition, the app server has the option to instruct the UMS server to write app.com cookies to the user client in the subsequent step 7. Such instructions can be passed as part of the response body, or as part of the response header. If passed in the response header, the HTTP ‘set-cookie’ header may be used.
Once the UMS server receives the response from step 6, the UMS server records the successful registration or sign-in, as disclosed herein, and then responds to the user client in step 7. Note that the response in step 7 is actually a response from step 4, because the user client is kept waiting for a response during the time that the UMS and app servers are executing step 4 (and steps 5 and 6 if the registration/sign-in is conditionally allowed by the UMS server pending full allowance by the app server). Step 7 includes an indication to the user client as to whether the registration was allowed or disallowed, and optionally may also include instructions to write cookies to the user client as previously disclosed, the preferred embodiment being an HTTP ‘set-cookie’ header.
An alternative embodiment includes the UMS server creating an access token and writing a cookie with the access token within the app.com domain as an additional sub-step of step 7. The creating of an access token is the same as described herein for
In
In step 1.1, the user client sends a request to the BaaS server, the request including the access token. The BaaS server begins to process the exemplary request, but the processing of the request requires that the BaaS server read and/or write user data to the UMS server 47. In order to do this, the BaaS server sends a request to the UMS server in step 1.2, and the request includes the access token (which identifies the user) and a secret key assigned to the BaaS server by the entity that controls the app server. The UMS server checks the access token and the secret key, and if they are valid for the requested operation, performs the operation. In step 1.3, the UMS server responds to the request. The BaaS server completes the request and responds to the user client in step 1.4. Therefore, the UMS server produces and consumes user identity information to and from the BaaS server.
In step 2.1, the user client sends a request to the UMS server, the request including the access token. The UMS server checks the access token, and if it is valid for the requested operation, performs the operation. In step 2.2, the UMS server responds to the request. Therefore, the UMS server produces and consumes user identity information to and from the user client.
In step 3.1, the app server sends a request to the UMS server, the request including a secret key and optionally the access token. The UMS server checks the secret key (and access token if provided), and if they are valid for the requested operation, performs the operation. In step 3.2, the UMS server responds to the request. Therefore, the UMS server produces and consumes user identity information to and from the app server.
The secret keys used in steps 1.2 and 3.1 of
When the UMS server 47 receives a request, the request may include a secret key, an access token, an app identifier corresponding to column 51, additional parameters, or any combination of the foregoing, along with a requested operation. Furthermore, through well-known methods, it is possible for the app identifier to be embedded into the access token and/or the secret key. Exemplary operations include a request to read or write a user's name, write email marketing data, or any number of other operations relating to the UMS server. Upon receipt of the request, the UMS server first searches the table of secret keys and apps against the information included in the request. If the request includes a valid combination of secret key, app, and rights, then the request is performed. If not, the request is not performed. Therefore, the secret key and/or access token are used to grant the BaaS server, the app server, and the user client the ability to read and write user information to and from the UMS server, the user information being specific to the app server corresponding to the given secret key and/or access token. In exemplary table 49, exemplary row 54 describes an entry that will grant full access to app1 to all of the user data in the UMS server that pertains to app1. In exemplary table 49, exemplary row 60 describes an entry that will grant limited access to user clients that can provide an access token relating to app2.
An exemplary use of the foregoing disclosure is an exemplary search service enabled to customize search results and save preferences for each user; an exemplary entry 55 is in the secret key and app table 49. Another exemplary use is an RSS service that can customize an RSS feed and save preferences and settings for each user. Another exemplary use is a payment service that can customize a payment experience based on the identity of a user, utilize user information to check for fraud, and/or save preferences and settings and payment information for each user. Another exemplary use is an analytics service that can utilize user identity information to track users. Another exemplary use is a compliance service that can utilize user identity information and/or user client information to ensure that users read, understand, and agree to legal terms and conditions set forth by an entity that provides the app or website.
It will be understood by one skilled in the art that the present disclosure enables a wide variety and types of services to be implemented within a BaaS server enabled to read and write user data to and from a UMS server. It will also be understood by one skilled in the art that, for convenience, any number of BaaS servers may be implemented within the same computing device. Furthermore, multiple services may be deployed for any one website or app; for example, an exemplary app server intended for selling and marketing transistor radios may be configured to interoperate with a UMS server, a payment service, a content management service, an email marketing service, and an e-commerce service. This configuration enables the exemplary app server to easily integrate compliance, email marketing, e-commerce, payments, and content, for each user of the exemplary app server.
In the next step, 1.5 and 2.5, the advertising server 62 sends the contents of the cookies in app1.com and app2.com cookies to the UMS server to request correlation. For example, if the user has signed into the first app server, a first access token will be included the app1.com cookies. If the user has signed into the second app server, a second access token will be included in the app2.com cookies. When the first and second access tokens are provided to the UMS server, the UMS server is able to compare the two access tokens and detect whether the two access tokens correspond to the same user client (and user by implication). There are a number of methods to perform the detection, including utilizing the user identity information (such as name, email address, and other user identifying information). If the two access tokens are determined to be from the same user client, then a targeted advertisement can be selected by the advertising server, and provided back to the user client in steps 1.6 and 2.6.
Although the time dimension in
In an additional embodiment of the advertising server 62, the entities providing the first and second app servers can be individually rewarded for serving advertisements that ultimately result in a sale, even if the user operating user client 61 does not click on any of the advertisements. In the embodiment, the advertising server tracks and correlates the identity of the user, the identity of each advertiser sponsoring each of the advertisements, and the identity of each entity operating each app server. Whenever a sale to a known user of a product or service related to an advertisement occurs, the advertising server is able to correlate the sale to the serving of each related advertisement by a plurality of app servers, and assign a monetary reward to each of the entities operating the plurality of app servers.
For example, a shoe seller chooses to place an advertisement with the advertising server 62. The advertising server places an advertisement related to the shoe seller within eight different websites or apps operated by eight different entities, each operating eight different app servers. The advertising server maintains a record of each placed advertisement. Subsequently, a user operating a user client purchases shoes from the shoe seller; upon doing so, a portion of the sale (a commission) is submitted to the advertising server, along with the identity of the user that purchased the shoes. Using the record of each placed advertisement, the advertising server assigns a portion of the commission to each of the eight different entities. Furthermore, each of the portions may be adjusted based on the number of times the advertisement was shown by each of the eight app servers, by the recency of the advertisements relative to the date the sale is completed, by the type or size of the advertisements, and/or by any other relevant adjustment criteria.
In a variant of the foregoing embodiment, the location of the user client is used by the advertising server to apply a plurality of policies in order to comply with local privacy laws. The determining of the location is implemented using geolocation within mobile devices, by querying a web browser, by determining the closest web server in a CDN network, or by other methods.
In another variant of the foregoing embodiment, the advertising server is configured to track promotional content beyond mere advertisements. For example, it is well known that some blogs and articles and reviews are written with the express purpose of promoting a given seller or product. In this example, the advertising server tracks users that read the blogs and articles and reviews, and includes the entities that provide the content in the sharing of revenue when a relevant sale occurs.
In yet another variant of the foregoing embodiment, in order to protect user privacy, the identity of the user is masked by a hash function. For example, the hash function MD5 can be applied to the user's email address by the shoe seller, prior to submission to the advertising server 62 for assignment of commission. Doing so protects the identity of the user, while still enabling the advertising server to compare MD5-hashed versions of each user email in its database to the submitted hash, and therefore still make the payments described herein.
The user clients, BaaS servers, UMS servers, and app servers, are all computing devices. The global network, including the internet, is a global computer network. Computing devices and global networks are described below.
The following description of
Access to the Internet 184 is typically provided by Internet service providers (ISP), such as the ISPs 186 and 188. Users on client systems, such as client computer systems 194, 198, 202, and 206 obtain access to the Internet through the Internet service providers, such as ISPs 186 and 188. Access to the Internet allows users of the client computer systems to exchange information, receive and send e-mails, and view documents, such as documents which have been prepared in the HTML format. These documents are often provided by web servers, such as web server 190 which is considered to be “on” the Internet. Often these web servers are provided by the ISPs, such as ISP 186, although a computer system can be set up and connected to the Internet without that system also being an ISP.
The web server 190 is typically at least one computer system which operates as a server computer system and is configured to operate with the protocols of the World Wide Web and is coupled to the Internet. Optionally, the web server 190 can be part of an ISP which provides access to the Internet for client systems. The web server 190 is shown coupled to the server computer system 192 which itself is coupled to web content 218, which can be considered a form of a media database. While two computer systems 190 and 192 are shown in
Client computer systems 194, 198, 202, and 206 can each, with the appropriate web browsing software, view HTML pages provided by the web server 190. The ISP 186 provides Internet connectivity to the client computer system 194 through the modem interface 196 which can be considered part of the client computer system 194. The client computer system can be a personal computer system, a network computer, a Web TV system, a wireless PDA or cellular phone or automobile navigation console, or other such computer system.
Similarly, the ISP 188 provides Internet connectivity for client systems 198, 202, and 206, although as shown in
Client computer systems 202 and 206 are coupled to a LAN 210 through network interfaces 204 and 208, which can be Ethernet network or other network interfaces. The LAN 210 is also coupled to a gateway computer system 220 which can provide firewall and other Internet related services for the local area network. This gateway computer system 220 is coupled to the ISP 188 to provide Internet connectivity to the client computer systems 202 and 206. The gateway computer system 220 can be a conventional server computer system. Also, the web server system 190 can be a conventional server computer system.
Alternatively, a server computer system 212 can be directly coupled to the LAN 210 through a network interface 214 to provide files 216 and other services to the clients 202, 206, without the need to connect to the Internet through the gateway system 220.
The computer system 222 includes a processor 224, which can be a conventional microprocessor such as an Intel® Pentium® microprocessor or Motorola® PowerPC® microprocessor. Memory 232 is coupled to the processor 224 by a bus 242. Memory 232 can be dynamic random access memory (DRAM) and can also include static RAM (SRAM). The bus 242 couples the processor 224 to the memory 232, to display controller 228, and to the input/output (I/O) controller 238.
The interface display controller 228 controls in the conventional manner a display on a display device 230 which can be a cathode ray tube (CRT) or liquid crystal display (LCD). The input/output devices 236 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 228 and the I/O controller 238 can be implemented with conventional well known technology. A digital image input device 240 can be a digital camera which is coupled to an I/O controller 238 in order to allow images from the digital camera to be input into the computer system 222.
One of skill in the art will immediately recognize that the terms “machine readable medium” or “computer-readable medium” includes any type of storage device that is accessible by the processor 224 and also encompasses a carrier wave that encodes a data signal.
The computer system 222 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an input/output (I/O) bus for the peripherals and one that directly connects the processor 224 and the memory 232 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of computer system that can be used with the present invention. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 232 for execution by the processor 224. A Web TV system, which is known in the art, is also considered to be a computer system according to the present invention, but it may lack some of the features shown in
In addition, the computer system 222 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of an operating system software with its associated file management system software is the family of operating systems known as Windows from Microsoft Corporation of Redmond, Wash., and their associated file management systems. Another example of an operating system software with its associated file management system software is the LINUX operating system and its associated file management system. The file management system is typically stored in the memory 232 and causes the processor 224 to execute the various acts required by the operating system to input and output data and to store data in memory.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention, in some embodiments, also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language, and various embodiments may thus be implemented using a variety of programming languages.
The systems described in
While the above description contains many specificities, these should not be construed as limitations on the scope of any embodiment, but as exemplifications of various embodiments thereof. One skilled in the art will appreciate that although specific embodiments of the present system and methods have been described for purposes of illustration, various modifications can be made without deviating from the scope or spirit of the present invention. Many other ramifications and variations are possible within the teachings of the various embodiments. Thus the scope should be determined by the appended claims and their legal equivalents, and not by the examples given.
