Patent Application
20200356998
Embodiments of the invention relate generally to the field of electronic commerce systems, and more particularly, to transaction gateways for processing electronic commerce transactions.
Application service providers that support electronic commerce typically use payment gateways to enable vendors, such as retailers or merchants, and their customers transact business. A gateway, such as a payment gateway, enables the transfer of information between the vendor and the customer's and vendor's banks to authorize and settle financial transactions.
To initiate a transaction using a payment gateway a website or customer service agent of a retailer typically requires that the customer provide sensitive financial account information which the retailer then relays to the payment gateway. For example, when a customer uses a credit card, the customer provides the credit card number and the card verification value (CVV) number to a website or to the customer service agent during a telephone call or at a point-of-sale (POS) location. This sensitive information is entered into the retailer's order system and forwarded to the payment gateway. The payment gateway notifies the retailer whether the payment was successful, and the customer and retailer complete the transaction.
The included drawings, by way of example only and not limitation, illustrate possible structures and operations for implementing the disclosed inventive systems, apparatus, methods, and computer-readable storage media. The drawings do not limit any changes in form and detail that may be made by one skilled in the art consistent with the spirit and scope of the disclosed implementations.
Revealing financial account information as well as other sensitive information, such as residence and telephone number, to a customer service agent or online can jeopardize the security of a customer's account and his or her privacy. Although some payment gateways have automated the process for vendors and customers, such as PayPal, they still require the customer to provide sensitive information, such as credit card information and the CVV numbers as part of the process for authenticating and authorizing payment for a financial transaction.
To minimize the risk to the security of the customer's account and his or her privacy, embodiments of a voice transaction gateway provides an architecture for application service providers to exploit the use of voice imprint technology, also referred to as voice fingerprinting, or voice signatures, to authenticate transactions before they are processed by a gateway for authorization of payment for or access to the vendor's goods and services.
In one embodiment, instead of requiring customers to provide sensitive account information, vendors and their customers can use a voice transaction gateway integrated with a gateway, such as a payment gateway or other type of gateway (subscription-based, etc.), to facilitate authentication of the transaction using the customer's PH # and voice.
In one embodiment the voice transaction gateway includes a voice transaction registrar to register a customer profile for a customer, including an account number, one or more payment methods, the customer's PH # and a voice signature representing a unique biometric marker identifying the customer by their voice as captured during a telephone call or other type of voice communication. In addition, the customer can register secondary PH # s for family members and others for whom the customer can authorize transactions.
In one embodiment, registered customers of the voice transaction gateway can transact business with vendors using their registered PH # and their voice to authenticate their transactions. The voice transaction gateway can then submit the authenticated transaction to a gateway, such as a payment gateway, for authorizing payment for or access to requested goods and services.
In one embodiment, the registered PH # is a first authentication factor and the customer's voice is a second authentication factor. The voice transaction gateway authenticates transaction requests using the first and second authentication factors in accordance with multi-factor authentication algorithms. For example, the first authentication factor can be confirmed when a call to the registered PH # is answered. The second authentication factor can be confirmed when a voice imprint of the answering voice matches the unique voice fingerprint/signature registered for a customer.
In one embodiment, to further facilitate authentication of the transaction using the customer's PH # and voice, the voice transaction gateway can analyze a sentiment of the customer's voice to approve or disapprove a transaction request otherwise authenticated based on the first and second authentication factors. For example, the voice transaction gateway can analyze whether the customer voiced a “YES” or a “NO” when answering the voice transaction gateway call to confirm a transaction request.
In one embodiment, the voice transaction gateway can be integrated with a gateway, such as a payment gateway, capable of authorizing or not authorizing a transaction authenticated by the voice transaction gateway.
In one embodiment, customers can use a voice transaction app to initiate voice transactions using the voice transaction gateway. The voice transaction app can provide an additional level of authentication through a login process. For example, a successful login to the voice transaction app can add to and/or substitute for the first authentication factor in the authentication of a voice transaction initiated via the app.
In this manner, the voice transaction gateway provides an architecture for application service providers to exploit the use of voice fingerprinting/signatures to enable vendors to conduct business without risking liability for unauthorized use of the customer's sensitive information. Likewise, customers can conduct business without jeopardizing exposure of their sensitive information to vendors that might not have adequate security measures in place to safeguard sensitive information against misuse.
In one embodiment, a customer 102 visits or initiates a telephone call to place an order 104 with a retailer, such as a fast-food restaurant. The retailer customer agent 108 takes the order 104 from the customer and enters the information into the order management system 110. Alternatively, the customer can enter the information using a self-service feature of the order management system 110. The customer 102 is offered the use of the voice transaction option 112. Instead of taking sensitive information from the customer to complete the order, such as financial information (credit card, debit card numbers and the like) or other personal information, the customer agent 108 (or self-service customer) invokes the voice transaction option 112. In one embodiment, the voice transaction option 112 generates a voice transaction request 114 that includes the vendor ID, customer's PH # and a dollar amount 114a associated with the request. In one embodiment, the voice transaction request 114 can include other information 114a that the customer can pre-register for use with the voice transaction option 112, such as residence information for delivery and so forth. The voice transaction request 114 is transmitted to the voice transaction gateway API 116 whereupon a voice confirmation process 118 authenticates the voice transaction request 114 using the customer's PH # and a voice imprint captured from the customer as part of the voice confirmation process.
For example, in one embodiment, the voice confirmation process 118 generates a voice transaction confirmation request 122 by initiating a voice call to the customer 102 using the customer's PH #114a included in the voice transaction request 114. The successful completion of the voice call to the customer 102, along with the capture of the customer's voice imprint during the voice call, functions as the respective first and second authentication factors returned to the voice confirmation process 118 in voice transaction confirmation 124. Now authenticated, the voice transaction request 114 is ready for processing by a gateway 127, such as a payment gateway.
For example, in one embodiment, after authenticating the voice transaction request 114 using the first and second authentication factors (as part of a multi-factor authentication algorithm), the voice confirmation process 118 sends an authenticated voice transaction 126a to the gateway 127 for authorization, such as authorization for payment (e.g., for goods or services) or authorization for access (e.g., for content delivery). Upon processing by the gateway 127, the voice confirmation process 118 receives the return of an authenticated voice transaction 126b that has either been authorized or not authorized.
For example, in one embodiment, a customer's authenticated voice transaction 126a can still be rejected by a payment gateway 127 if authorization for payment is declined due to the customer's credit limit having been reached or for insufficient funds, or for other reasons that a payment gateway uses to reject a transaction. The rejection can result in an authenticated but unauthorized voice transaction 126b. On the other hand, if the payment gateway 127 authorization for payment is successful, then the customer's authenticated voice transaction 126a results in an authenticated and authorized voice transaction 126b. The voice confirmation process 118 transmits to the order management system 110 a voice transaction authorization notification 120 to notify the customer agent 108 (or self-serve customer) that the payment for the order has been any of authorized or not authorized depending on the voice transaction result 126b.
In one embodiment, once the first authentication factor 130 has been confirmed, the voice transaction app 128 prepares to call the customer agent 108 of the vendor system 106 by optionally executing a call anonymizer and customer-to-Random PH # mapping process 132 which uses a random dialer to initiate the call to place the order 104. The customer's PH # is thereby masked from view of the customer agent 108. Since the customer 102 is pre-registered with the voice transaction gateway 116, the voice transaction option 112 can automatically be activated after the customer agent 108 takes the order and enters the order (or the customer enters the order using a self-service feature of the order system).
Upon activation of the voice transaction option 112, the vendor system adds the amount charged for the order into the order management system 110 and generates a voice transaction request 114 that includes the order amount and, optionally, the Customer-to-Random PH # mapping 132 as part 114b of the request 114. Other information 114b provided by the customer can be included in the request 114 as well, such as delivery information and the like. The voice confirmation process 118 generates a voice/app confirmation request 122 like the voice transaction confirmation request 122 in
For example, because the customer 102 has already activated the voice transaction app 128 on their device, the voice transaction request 114 is already partly authenticated by confirmation of the first authentication factor in the voice transaction app. The voice confirmation process 118 completes the authentication of the voice transaction request 114 by obtaining the voice imprint of the customer's voiced response using an existing connection to the customer 102 via the voice transaction app 128 to confirm the voice transaction request 114. Alternatively, the voice confirmation process 118 obtains confirmation of the voice transaction request using other means, such as a response to a text message sent to the customer's device in which the voice transaction app 128 is installed.
In one embodiment, it can be necessary to initiate a separate voice call to a primary person to authenticate voice transaction requests 114 initiated by a customer 102 registered to the primary person's customer profile as a secondary customer. For example, if the customer that initiated the voice transaction request 114 is a child (secondary) whose parent (primary) is responsible for authenticating the voice transaction request 114, then the voice confirmation process 118 initiates the separate voice call to the primary customer's registered PH # as the first authentication factor and obtains the voice imprint of the primary customer's voiced response as the second authentication factor.
In one embodiment, after using the first and second authentication factors (as part of a multi-factor authentication algorithm) to authenticate the voice transaction request 114, the voice confirmation process 118 sends an authenticated voice transaction 126a to the gateway 127 for authorization, such as authorization for payment (e.g., for goods or services) or authorization for access (e.g., for subscription-based content delivery). Upon processing by the gateway 127, the voice confirmation process 118 receives the return of an authenticated voice transaction 126b that has either been authorized or not authorized.
For example, in one embodiment, a customer's authenticated voice transaction 126a can still be rejected by a payment gateway 127 if authorization for payment is declined due to the customer's credit limit having been reached or for insufficient funds, or for other reasons that a payment gateway can use to reject a transaction (e.g., flagged as stolen card). The rejection can result in an authenticated but unauthorized voice transaction 126b. On the other hand, if the payment gateway 127 authorization for payment is successful, then the customer's authenticated voice transaction 126a results in an authenticated and authorized voice transaction 126b. The voice confirmation process 118 transmits to the vendor system 106 (e.g., the order management system 110) a voice transaction authorization notification 120 to notify the customer agent 108 and customer 102 that the payment for the order has been any of authorized or not authorized depending on the result 126b.
In one embodiment the enterprise computing platform in which embodiments of the voice transaction gateway 116 using architectures 100/101 can be implemented includes application servers and databases of the vendor system 106, voice transaction gateway 116 and transaction gateway 127 connected via a network (not shown). During operation, different combinations of application servers and data servers can execute the vendor system 106, voice transaction gateway 116 and transaction gateway 127 and access data stored in the databases.
In one example, enterprise computing platform in which the vendor system 106 operates can be a multi-tenant system (MTS). A multi-tenant system refers to a database system such as vendor system 106 where different hardware and software can be shared by one or more vendors (or other organizations/businesses) represented as tenants. For example, enterprise computing platform can associate a first tenant with an organization that sells airline services, associate a second tenant with an organization that sells pizzas, and associate a third tenant with an organization that sells office supplies and equipment. The multi-tenant system can effectively operate as multiple virtual databases each associated with one of tenants.
In one embodiment, at 304 the voice transaction gateway verifies that the request is valid based on a token passed from the vendor, the vendor ID and the amount. At 306, the voice transaction gateway determines whether the customer PH # included in the request is, in fact, registered for a primary or secondary customer(s) based on the customer profile associated with the customer PH #. If not, at 312, the voice transaction gateway rejects the request and returns control to the vendor for a regular payment process since the customer has not registered and is ineligible to use the voice transaction option 112 of the vendor system 106 (e.g., the order management system 110).
In one embodiment, if there is a registered Customer PH # that can be used to perform the voice confirmation process, where the Customer PH # is registered to a primary customer, then at 308 the voice transaction gateway initiates a callback to the Customer PH # to begin the voice confirmation process. If, at 310, the call is successfully completed (i.e., if the customer answers the call) then the voice transaction gateway at 314 confirms the first authentication factor used to authenticate the voice transaction request. At 316 the voice transaction gateway continues the voice confirmation process (at
In one embodiment, at 406, the voice transaction app determines whether to optionally anonymize the customer PH # before initiating the voice transaction with the vendor. For example, in one embodiment, at 408 the voice transaction app fetches a random output PH # to use in place of the customer PH # when calling the vendor. At 410, to ensure that the customer's PH # remains private but is still passed through to the voice transaction gateway, the voice transaction app creates a mapping between the random outbound PH # and the customer PH #. At 412 the voice transaction app is now ready to dial the vendor PH # to place the customer's call using the Customer PH # (or the random outbound PH # if anonymized), and additional processing 414 continues in
In one embodiment, at 432, the voice transaction gateway determines whether the customer PH # is, in fact, a registered PH # (primary or secondary) based on the customer profile associated with the customer PH # and stored in a database of registered Customer PH # s. If not, then at 438, the voice transaction gateway rejects the voice transaction request and returns control to the vendor for regular payment processing since the customer either has not registered or the registration is no longer valid, and the customer is ineligible to use the voice transaction option of the vendor's order management system. For voice transactions initiated through the voice transaction app, most customers will ordinarily be currently registered.
In one embodiment, if the Customer PH # is determined to be a registered PH #, whether registered to a primary customer or to a secondary customer, then at 434 the voice transaction gateway continues by muting the vendor to ensure that the customer's privacy is protected against exposure of sensitive information to the vendor and/or vendor's customer agent during the remainder of the voice confirmation process of authenticating and approving the voice transaction request. Once muted, at 436 the voice transaction gateway proceeds to contact the primary customer associated with the registered account via the primary's Customer PH #.
In one embodiment, if the Customer PH # is associated with a secondary customer (e.g., a child), then the voice transaction gateway first determines the primary customer responsible for confirming requests made by the secondary customer (e.g., the parent responsible for confirming requests made by the child). The voice transaction gateway then initiates a call to the Customer PH # registered for the primary customer. In one embodiment, after establishing a voice connection with the primary's Customer PH # on behalf of a secondary customer's request, the voice transaction gateway proceeds to confirm the primary's Customer PH # as an additional authentication factor based on a completed call to the primary's Customer PH # since the first authentication factor confirmed at 404 was based only on successful login to the voice transaction app by a secondary customer (e.g., the child). Processing continues 440 at
In one embodiment, if the Customer PH # included in the voice transaction request is registered to the primary customer, then the voice connection with the primary is already established and the first authentication factor confirmed at 404 is acceptable since it was based on successful login to the voice transaction app by the primary customer (e.g., a parent or other primary customer capable of authenticating voice transaction requests. Processing continues 440 at
In one embodiment, at 506, the voice transaction gateway proceeds to obtain a voice imprint of the answering speaker (i.e., the purported primary customer) during the separate call to the primary customer or during the voice connection already established via the voice transaction app. The voice imprint functions as the second authentication factor. At 508, the voice transaction gateway compares the voice imprint from 506 to the voice signature that the primary customer registered with the voice transaction gateway registrar (
In one embodiment, at process 514, if the sentiment of “NO” was received, the voice transaction gateway rejects the voice transaction request and returns control to the vendor for regular processing. If, however, the sentiment of “YES” was received, the voice transaction gateway proceeds at 516 to submit the voice transaction request to a gateway integrated with the voice transaction gateway to carry out the transaction details. For example, if the gateway is a payment gateway, the gateway carries out the task of verifying the funds available through a payment method selected by the customer, crediting the vendor account, debiting the customer account and so forth. Finally, at 518 the voice transaction gateway generates a voice transaction notification to transmit to the vendor and the customer's registered PH # to alert them to the completed voice transaction request, and lastly, at 520, the voice transaction gateway returns control to the vendor to complete the transaction with the customer. In this manner, the voice confirmation process (
Environment 600 is an environment in which an on-demand database service exists. User system 620 may be any machine or system that is used by a user to access a database user system. For example, any of user systems 620 can be a handheld computing device, a mobile phone, a laptop computer, a work station, and/or a network of computing devices. As illustrated in
An on-demand database service, such as system 602, is a database system that is made available to outside users that do not need to necessarily be concerned with building and/or maintaining the database system, but instead may be available for their use when the users need the database system (e.g., on the demand of the users). Some on-demand database services may store information from one or more tenants stored into tables of a common database image to form a multi-tenant database system (MTS). Accordingly, “on-demand database service 602” and “system 602” is used interchangeably herein. A database image may include one or more database objects. A relational database management system (RDMS) or the equivalent may execute storage and retrieval of information against the database object(s). Application platform 610 may be a framework that allows the applications of system 602 to run, such as the hardware and/or software, e.g., the operating system. In an embodiment, on-demand database service 602 may include an application platform 610 that enables creation, managing and executing one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems 620, or third party application developers accessing the on-demand database service via user systems 620.
The users of user systems 620 may differ in their respective capacities, and the capacity of a user system 620 might be entirely determined by permissions (permission levels) for the current user. For example, where a salesperson is using a user system 620 to interact with system 602, that user system has the capacities allotted to that salesperson. However, while an administrator is using that user system to interact with system 602, that user system has the capacities allotted to that administrator. In systems with a hierarchical role model, users at one permission level may have access to applications, data, and database information accessible by a lower permission level user, but may not have access to certain applications, database information, and data accessible by a user at a higher permission level. Thus, different users will have different capabilities when accessing and modifying application and database information, depending on a user's security or permission level.
Network 618 is any network or combination of networks of devices that communicate with one another. For example, network 618 can be any one or any combination of a LAN (local area network), WAN (wide area network), telephone network, wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. As the most common type of computer network in current use is a TCP/IP (Transfer Control Protocol and Internet Protocol) network, such as the global internetwork of networks often referred to as the “Internet” with a capital “I,” that network will be used in many of the examples herein. However, it is understood that the networks that the claimed embodiments may utilize are not so limited, although TCP/IP is a frequently implemented protocol.
User systems 620 might communicate with system 602 using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, user system 620 might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages to and from an HTTP server at system 602. Such an HTTP server might be implemented as the sole network interface between system 602 and network 618, but other techniques might be used as well or instead. In some implementations, the interface between system 602 and network 618 includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. At least as for the users that are accessing that server, each of the plurality of servers has access to the MTS' data; however, other alternative configurations may be used instead.
In one embodiment, system 602, shown in
One arrangement for elements of system 602 is shown in
Several elements in the system shown in
According to one embodiment, each user system 620 and all its components are operator configurable using applications, such as a browser, including computer code run using a central processing unit such as an Intel Pentium® processor or the like. Similarly, system 602 (and additional instances of an MTS, where more than one is present) and all of their components might be operator configurable using application(s) including computer code to run using a central processing unit such as processor system 612, which may include an Intel Pentium® processor or the like, and/or multiple processor units.
According to one embodiment, each system 602 is configured to provide webpages, forms, applications, data and media content to user (client) systems 620 to support the access by user systems 620 as tenants of system 602. As such, system 602 provides security mechanisms to keep each tenant's data separate unless the data is shared. If more than one MTS is used, they may be located in close proximity to one another (e.g., in a server farm located in a single building or campus), or they may be distributed at locations remote from one another (e.g., one or more servers located in city A and one or more servers located in city B). As used herein, each MTS may include one or more logically and/or physically connected servers distributed locally or across one or more geographic locations. Additionally, the term “server” is meant to include a computer system, including processing hardware and process space(s), and an associated storage system and database application (e.g., OODBMS or RDBMS) as is well known in the art. It is understood that “server system” and “server” are often used interchangeably herein. Similarly, the database object described herein can be implemented as single databases, a distributed database, a collection of distributed databases, a database with redundant online or offline backups or other redundancies, etc., and might include a distributed database or storage network and associated processing intelligence.
User system 620, network 618, system 602, tenant data storage 604, and system data storage 606 were discussed above in
Application platform 610 includes an application setup mechanism 624 that supports application developers' creation and management of applications, which may be saved as metadata into tenant data storage 604 by save routines 626 for execution by subscribers as one or more tenant process spaces 630_1 managed by tenant management process space 630 for example. Invocations to such applications may be coded using PL/SOQL 628 that provides a programming language style interface extension to API 634. Invocations to applications may be detected by one or more system processes, which manage retrieving application metadata 605_3 for the subscriber making the invocation and executing the metadata as an application in a virtual machine.
Each application server 622 may be communicably coupled to database systems, e.g., having access to system data 607 and tenant data 605, via a different network connection. For example, one application server 622i might be coupled via the network 618 (e.g., the Internet), another application server 622N-1 might be coupled via a direct network link, and another application server 622N might be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are typical protocols for communicating between application servers 622 and the database system. However, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.
In certain embodiments, each application server 622 is configured to handle requests for any user associated with any organization that is a tenant. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server 622. In one embodiment, therefore, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 622 and the user systems 620 to distribute requests to the application servers 622. In one embodiment, the load balancer uses a least connections algorithm to route user requests to the application servers 622. Other examples of load balancing algorithms, such as round robin and observed response time, also can be used. For example, in certain embodiments, three consecutive requests from the same user may hit three different application servers 622, and three requests from different users may hit the same application server 622. In this manner, system 602 is multi-tenant, in which system 602 handles storage of, and access to, different objects, data and applications across disparate users and organizations.
As an example of storage, one tenant might be a company that employs a sales force where each salesperson uses system 602 to manage their sales process. Thus, a user might maintain contact data, leads data, customer follow-up data, performance data, goals and progress data, etc., all applicable to that user's personal sales process (e.g., in tenant data storage 604). In an example of an MTS arrangement, since all of the data and the applications to access, view, modify, report, transmit, calculate, etc., can be maintained and accessed by a user system having nothing more than network access, the user can manage his or her sales efforts and cycles from any of many different user systems. For example, if a salesperson is visiting a customer and the customer has Internet access in their lobby, the salesperson can obtain critical updates as to that customer while waiting for the customer to arrive in the lobby.
While each user's data might be separate from other users' data regardless of the employers of each user, some data might be organization-wide data shared or accessible by a plurality of users or all the users for a given organization that is a tenant. Thus, there might be some data structures managed by system 602 that are allocated at the tenant level while other data structures might be managed at the user level. Because an MTS might support multiple tenants including possible competitors, the MTS may have security protocols that keep data, applications, and application use separate. Also, because many tenants may opt for access to an MTS rather than maintain their own system, redundancy, up-time, and backup are additional functions that may be implemented in the MTS. In addition to user-specific data and tenant specific data, system 602 might also maintain system level data usable by multiple tenants or other data. Such system level data might include industry reports, news, postings, and the like that are sharable among tenants.
In certain embodiments, user systems 620 (which may be client systems) communicate with application servers 622 to request and update system-level and tenant-level data from system 602 that may require sending one or more queries to tenant data storage 604 and/or system data storage 606. System 602 (e.g., an application server 622 in system 602) automatically generates one or more SQL statements (e.g., one or more SQL queries) that are designed to access the desired information. System data storage 606 may generate query plans to access the requested data from the database.
Each database can generally be viewed as a collection of objects, such as a set of logical tables, containing data fitted into predefined categories. A “table” is one representation of a data object and may be used herein to simplify the conceptual description of objects and custom objects as described herein. It is understood that “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Each row or record of a table contains an instance of data for each category defined by the fields. For example, a CRM database may include a table that describes a customer with fields for basic contact information such as name, address, phone number, fax number, etc. Another table might describe a purchase order, including fields for information such as customer, product, sale price, date, etc. In some multi-tenant database systems, standard entity tables might be provided for use by all tenants. For CRM database applications, such standard entities might include tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. It is understood that the word “entity” may also be used interchangeably herein with “object” and “table.”
In some multi-tenant database systems, tenants may be allowed to create and store custom objects, or they may be allowed to customize standard entities or objects, for example by creating custom fields for standard objects, including custom index fields. In certain embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. It is transparent to customers that their multiple “tables” are in fact stored in one large table or that their data may be stored in the same table as the data of other customers.
The term “user” may refer to a system user, such as, but not limited to, a software/application developer, a system administrator, a database administrator, an information technology professional, a program manager, product manager, etc. The term “user” may also refer to an end-user, such as, but not limited to, an organization (e.g., a business, a company, a corporation, a non-profit entity, an institution, an agency, etc.) serving as a customer or client of the provider (e.g., Salesforce.com®) of a user device (such as user system 620 in
It is to be noted that any references to software codes, data and/or metadata (e.g., Customer Relationship Model (“CRM”) data and/or metadata, etc.), tables (e.g., custom object table, unified index tables, description tables, etc.), computing devices (e.g., server computers, desktop computers, mobile computers, such as tablet computers, smartphones, etc.), software development languages, applications, and/or development tools or kits (e.g., Force.com®, Force.com, Salesforce 1®, Apex™ code, JavaScript™, jQuery™, Developerforce™, Visualforce™, Service Cloud Console Integration Toolkit™ (“Integration Toolkit” or “Toolkit”), Platform on a Service™ (“PaaS”), Chatter® Groups, Sprint Planner®, MS Project®, etc.), domains (e.g., Google®, Facebook®, LinkedIn®, Skype®, etc.), etc., discussed in this document are merely used as examples for brevity, clarity, and ease of understanding and that embodiments are not limited to any particular number or type of data, metadata, tables, computing devices, techniques, programming languages, software applications, software development tools/kits, etc.
The exemplary computer system 700 includes a processing device (processor) 702, a main memory 704 (e.g., ROM, flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 706 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 720, which communicate with each other via a bus 710.
Processor 702 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, processor 702 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processor 702 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processor 702 is configured to execute instructions 726 for performing the operations and steps discussed herein. Processor 702 may have one or more processing cores.
Computer system 700 may further include a network interface device 708. Computer system 700 also may include a video display unit 712 (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), or a touch screen), an alphanumeric input device 714 (e.g., a keyboard), a cursor control device 716 (e.g., a mouse or touch screen), and a signal generation device 722 (e.g., a loud speaker).
Power device 718 may monitor a power level of a battery used to power computer system 700 or one or more of its components. Power device 718 may provide one or more interfaces to provide an indication of a power level, a time window remaining prior to shutdown of computer system 700 or one or more of its components, a power consumption rate, an indicator of whether computer system is utilizing an external power source or battery power, and other power related information. In some implementations, indications related to power device 718 may be accessible remotely (e.g., accessible to a remote back-up management module via a network connection). In some implementations, a battery utilized by power device 718 may be an uninterruptable power supply (UPS) local to or remote from computer system 700. In such implementations, power device 718 may provide information about a power level of the UPS.
Data storage device 720 may include a computer-readable storage medium 724 (e.g., a non-transitory computer-readable storage medium) on which is stored one or more sets of instructions 726 (e.g., software) embodying any one or more of the methodologies or functions described herein. Instructions 726 may also reside, completely or at least partially, within main memory 704 and/or within processor 702 during execution thereof by computer system 700, main memory 704, and processor 702 also constituting computer-readable storage media. Instructions 726 may further be transmitted or received over a network 745 via network interface device 730.
In one implementation, instructions 726 include instructions for performing any of the implementations described herein. While computer-readable storage medium 724 is shown in an exemplary implementation to be a single medium, it is to be understood that computer-readable storage medium 724 may 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.
While the subject matter disclosed herein has been described by way of example and in terms of the specific embodiments, it is to be understood that the claimed embodiments are not limited to the explicitly enumerated embodiments disclosed. To the contrary, the disclosure is intended to cover various modifications and similar arrangements as are apparent to those skilled in the art. Therefore, the scope of the appended claims is to be accorded the broadest interpretation to encompass all such modifications and similar arrangements. It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the disclosed subject matter is therefore to be determined in reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
