PROCESSING BENEFIT ELIGIBILITY DATA

A provider of a service (e.g., a medical service) submits a request for authorization to bill for the service (e.g., a request for authorization to bill an insurance company of the recipient of the service). The recipient of the request (e.g., a medical services clearinghouse) informs a fraud prevention of the request. The fraud prevention communicates (e.g., by text message or email) with a computing device (e.g., a cell phone or desktop computer) associated with the recipient of the service to determine if the request is legitimate. If the request is not legitimate, the clearinghouse, the insurance company, the medical service provider or any suitable combination thereof is notified of the issue. By taking action on this notification, benefit eligibility fraud is avoided.

TECHNICAL FIELD

The subject matter disclosed herein generally relates to computerized methods and systems for processing benefit eligibility data. Specifically, in some example embodiments, the present disclosure addresses systems and methods for coordinating multiple systems in processing benefit eligibility data.

DETAILED DESCRIPTION

A provider of a service (e.g., a medical service) submits a request for authorization to bill for the service (e.g., a request for authorization to bill an insurance company of the recipient of the service). The recipient of the request (e.g., a medical services clearinghouse) informs a fraud prevention of the request. The fraud prevention communicates with a computing device (e.g., a cell phone) associated with the recipient of the service to determine if the request is legitimate.

If the request is not legitimate, the clearinghouse, the insurance company, the medical service provider or any suitable combination thereof is notified of the issue. By taking action on this notification, benefit eligibility fraud is avoided.

FIG. 1is a network diagram illustrating a network environment100suitable for processing benefit eligibility data, according to some example embodiments. The network environment100includes a clearinghouse server110, a database server120, a fraud prevention server130, and devices160A and160B, all communicatively coupled to each other via a network140. The devices160A and160B may be collectively referred to as “devices160,” or generically referred to as a “device160.” The clearinghouse server110, database server120, and fraud prevention server130are network-based systems. The devices160may interact with the servers110-130using a web client170A or an app client170B. The servers110-130and the devices160may each be implemented in a computer system, in whole or in part, as described below with respect toFIGS. 9-10.

The clearinghouse server110collects data regarding transactions via the network140. Many different insurance companies use unique protocols for requesting and providing authorization, receiving payment, and providing services. Thus, medical service providers face high overhead in interacting with multiple insurance companies. To alleviate this, a clearinghouse provides a single interface to users and handles the complexity of dealing with the multiple insurance companies. Intentionally or as a side effect of performing this intermediary function, the clearinghouse acquires information about the medical services being provided to medical consumers across multiple medical service providers and insurance companies.

Database services are provided by the database server120to one or more of the clearinghouse server110and the fraud prevention server130. In some example embodiments, distinct database servers are used by each of the servers110and130. The database services provided by the database server120include data storage and retrieval.

The fraud prevention server130provides one or more fraud preventions (e.g., health claims monitoring). Health claims monitoring provides an alert to a user whenever a medical claim is made against their identity, a request for billing authorization is made to their insurance company, or any suitable combination thereof.

Also shown inFIG. 1is a user150. The user150may be a human user (e.g., a human being), a machine user (e.g., a computer configured by a software program to interact with the devices160and one or more of the servers110-130), or any suitable combination thereof (e.g., a human assisted by a machine or a machine supervised by a human). The user150is not part of the network environment100, but is associated with the devices160and may be a user of the devices160(e.g., an owner of the devices160A or160B). For example, the device160may be a desktop computer, a vehicle computer, a tablet computer, a navigational device, a portable media device, or a smart phone belonging to the user150. In some example embodiments, a user of a first device160is a medical services provider and a user of a second device160is a medical services recipient.

The network140may be any network that enables communication between or among machines, databases, and devices (e.g., the fraud prevention server130and the devices160). Accordingly, the network140may be a wired network, a wireless network (e.g., a mobile or cellular network), or any suitable combination thereof. The network140may include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof.

FIG. 2is an architectural diagram200illustrating components of a fraud prevention server130in communication with other systems, according to some example embodiments. The fraud prevention server130includes a communication module210, an authentication module220, a claims module230, an alert module240, a user interface module250, and a storage module260, all configured to communicate with each other (e.g., via a bus, shared memory, a switch, or APIs). Any one or more of the modules described herein may be implemented using hardware (e.g., a processor of a machine) or a combination of hardware and software. For example, any module described herein may configure a processor to perform the operations described herein for that module. Moreover, any two or more of these modules may be combined into a single module, and the functions described herein for a single module may be subdivided among multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

The communication module210is configured to send and receive data. For example, the communication module210may receive from a medical service provider (e.g., using the device160B), over the network140, a request for authorization to bill a medical insurance company. The communication module210may provide the request to the user interface module250, transmit a user interface provided by the user interface module250to a device of the user receiving the medical service (e.g., the device160A), and receive user selections of options in the user interface for processing by the authentication module220, the claims module230, or the alert module240; storage by the storage module260; or any suitable combination thereof.

The authentication module220is configured to authenticate a user. For example, a question that only the user is expected to know the answer to may be presented to the user and the user authenticated only if the response is correct. In some example embodiments, multiple such questions are presented and the responses evaluated. The user may be permitted to proceed to view security status information, confirm or deny medical billing requests, or any suitable combination thereof, only after authentication is successful.

The claims module230is configured to determine if medical claims are valid and report, via the user interface module250, the results of the determination. The alert module240is configured to generate alerts. The generated alerts may be provided to users (e.g., to report data access status changes, such as credit status changes, to report data breaches, to report suspected identity theft, or any suitable combination thereof), to medical service providers (e.g., to report rejection by a medical consumer of a request for authorization from the medical service provider), to insurance companies (e.g., to report attempted medical service fraud), or any suitable combination thereof. Each alert may be in the form of e-mail, text message, automated voice message, or another suitable method of notification.

The user interface module250serves a website, via a hypertext transfer protocol (HTTP) connection, to the device160A. The fraud prevention server130is in communication, via a representational state transfer (REST) application programming interface (API), with one or more of the servers110and120. The user interface may include information regarding authenticating a user, determining if a request for medical service authorization is authentic, or any suitable combination thereof. For example, one or more of the user interfaces300and400, described below with respect toFIGS. 3-4, may be presented by the user interface module250, and selections may be received via an application interface or a web interface. The storage module260is configured to store data regarding users, entities, data access status, or any suitable combination thereof.

In some example embodiments, the database server120or the fraud prevention server130uses Structured Query Language (SQL) to access standard relational database and NoSQL to access databases other than standard relational databases. Dynamo NoSQL is a particular type of NoSQL based on key-value pairs. For example, a database may store usernames, passwords, authentication questions, user profiles, a user's name, social security number, birthdate, address, previous addresses, phone number, bank account numbers, or any suitable combination thereof.

FIG. 3is a block diagram illustrating a user interface300for verifying a user's identity, according to some example embodiments. As can be seen inFIG. 3, the user interface300includes a name310, prompts320, check boxes330, and button340. The name310identifies the user being verified. Each of the prompts320is a fact or falsehood regarding the user. The checkboxes330allow the user to indicate whether each prompt is true or false.

The medical consumer may indicate which of the prompts are accurate and which are inaccurate by clicking on the appropriate check box330. Once the accuracy of each prompt is indicated, the medical consumer may submit the responses by clicking the button340. If the responses are correct, then the enrollment process may continue. In some example embodiments, the prompts320are aggregated from multiple sources. For example, inFIG. 3, the prompts numbered1,3, and4relate to medical transactions and the prompt2relates to an address of the user. Data for the medical transactions may be received by the fraud prevention server130from the clearinghouse server110. Other data may be received from other servers (e.g., from a credit bureau server).

FIG. 4is a block diagram illustrating a user interface400for requesting a confirmation of an insurance verification request, according to some example embodiments. As can be seen inFIG. 4, the user interface400includes the name410, a status area420, and the buttons430and440. The name410identifies the user being verified. The status area420indicates the medical service provider that made the request on the identified user's identity. The buttons430and440allow the user to indicate if the request was initiated by the user or not. Thus, when the user goes to a doctor to request care and the doctor requests confirmation of the user's insurance, the user is notified of the request and can confirm that the request is valid. When another person goes to a doctor to request care and fraudulently presents the user's insurance information, the user is notified when the doctor requests insurance verification and can, by use of the button440, inform the fraud prevention provider that the request is fraudulent. In this way, the medical services fraud can be detected immediately.

FIG. 5is a block diagram illustrating a database schema500suitable for supporting processing benefit eligibility data, according to some example embodiments. The database schema500includes a user table510and an access table540. The user table510is defined by a table definition520, including a user identifier field, a name field, and a social security number (“SSN”) field, and includes rows530A,530B, and530C. The access table540is defined by a table definition550, including a user identifier field, a provider field, and a service field, and includes rows560A,560B, and560C.

Each of the rows530A-530C stores information for a user. The user identifier field stores a unique identifier for the user. The name field stores a name of the user. The SSN field stores a social security number for the user. In various example embodiments, additional or different fields are stored in the user table510. For example, an address field, a birthdate field, a phone number field, or any suitable combination thereof may be stored.

Each of the rows560A-560C stores data for an access of user data by a medical services provider. The row560A shows that data (e.g., insurance validation) for the user with identifier1234, “Adam Smith” of the user table510, was requested by Dr. Wilson, who billed for a physical examination. According to the row560B, the user with identifier2345, “John Jay.” has had his insurance verified by Dr. Smith. The user with identifier3456, “James Wilson,” as shown in the row560C, has been billed for a Naproxen prescription by Bob's Pharmacy.

Data from the user table510may be used in performing fraud preventions. For example, user data such as name, username, password, phone number, street address, and the like may be stored in the user table510and used for requesting data from the clearinghouse server110. Data from the access table540may be used to generate the user interface400to allow the user to confirm that access to data by medical providers is authorized.

FIG. 6is a flowchart illustrating operations of a computing device in performing a method600of confirming a user's identity, according to some example embodiments. The method600includes operations610,620,630,640, and650. By way of example and not limitation, operations in the method600are described as being performed by the fraud prevention server130, using modules described above with respect toFIG. 2.

In operation610, the communication module210receives identification information for a medical insurance account. For example, the user150of the client device160A may sign up for the medical fraud prevention by accessing a web page provided by the fraud prevention server130via the network140, displayed on a screen of the device160A by the web client170A. The received identification information is stored in the user table510.

The identification information may be provided by the medical consumer when, for example, the medical consumer signs up for a service offered by the fraud prevention service provider to reduce or prevent fraudulent use of the medical identity of the medical consumer. The medical consumer may provide the identification information online by accessing a website over the Internet, by sending an email, through a social media website, on paper by completing one or more forms and then transmitting the forms to a provider of the service, over the phone, or any other transmittal method known in the art now or in the future. In various embodiments, the identification information may be provided by a provider of medical insurance.

The identification information provided by the medical consumer may comprise any information that may be used to link the medical consumer with the medical insurance account of the medical consumer. In various embodiments, the medical identity may comprise any information shared between the medical consumer and the medical insurance provider that is providing medical insurance coverage to the medical consumer. The identification information may comprise general information about the medical consumer, such as name, home address, home telephone and cellular telephone number, electronic mail address, social media address, social security number, name and address of an employer of the medical consumer, or any suitable combination thereof.

The identification information may also comprise information specific to an insurance policy provided by the medical insurance provider to the medical consumer. The insurance policy information may comprise a name and address of the medical insurance provider, a policy number, a group number, a member number, a date that coverage under the insurance policy began, level of coverage, or any suitable combination thereof.

The communication module210, in operation620, receives medical claims data associated with the medical insurance account. For example, the clearinghouse server110provides, for validation purposes, at least a subset of the medical claims data stored by the clearinghouse server110to the fraud prevention server130, via the network140. In various embodiments, the medical claims data may be received from the medical insurance provider. In certain other embodiments, the medical claims data may be received from a provider of the medical goods or services.

The medical claims data may comprise any information or data that identifies particular medical goods or services reported against the medical insurance account of the medical consumer. For example, the medical claims data may comprise a name and address of the provider of the medical goods or services, such as the name of a doctor and the location of the office in which a medical service was provided. The medical claims data may also comprise a description of the goods or services provided. The description may comprise an alphanumeric medical billing code, such as Current Procedural Terminology (CPT) codes developed by the American Medical Association, or Healthcare Common Procedure Coding System (HCPCS) codes developed for Medicare use. The description may also comprise a diagnostic or procedural code, such as an International Statistical Classification of Diseases (ICD) codes. ICD codes may, for example, comprise a ICD-9-CM diagnostic code, a ICD-10-CM diagnostic code, or any other medical billing, diagnostic, or procedural code.

The description of the medical goods or services may also comprise a written description of the goods or service, such as a flu shot, a physical, a surgical procedure, a wheelchair, a prosthetic limb, a glucose test meter, a prescription medication, or any suitable combination thereof. The written description may comprise a description of the medical billing, diagnostic or procedural code. Additionally, the medical claims data may comprise the date or dates that the medical goods or services were provided.

While all medical goods or services are contemplated by the present disclosure, specific examples include: direct interaction with health practitioners, prescription medications, laboratory services, high technology diagnostic services, transportation by ambulance, blood supplies, eyeglasses, corrective lenses, external prosthetic devices, external orthotic devices, and internal medical devices.

Personal data associated with the medical insurance account is received by the communication module210(operation630). For example, a credit monitoring bureau provides, for validation purposes, at least a subset of the personal data stored by a server of the credit monitoring bureau using the network140.

In operation640, the user interface module250transmits at least some of the medical claims data, the personal data, and false data to a medical consumer associated with the medical insurance account. For example, the user interface300may be presented on a display of the device160A. The false data may be generated by the fraud prevention server130, the clearinghouse server110, the credit bureau server, or any suitable combination thereof.

The transmittal may occur via an email message, a message transmitted via a social media website, a telephone call, a letter, or any other transmittal method known in the art now or in the future. The transmittal may be in a secure mode to protect the privacy interests of the medical consumer. For example, the transmittal may be encoded such that a password may have to be entered prior to viewing. In various embodiments, the transmittal may be a notice that medical claims data have been received. In this situation, the medical consumer may securely log into a website (or make contact through another mechanism, such as a telephone call) and view the medical claims data.

The fraud prevention server130, in operation650, receives confirmation data from the medical consumer. For example, the medical consumer interacts with the user interface300to indicate which of the data items presented are true and which are false. Based on the user interaction correctly identifying the true and false elements, the user of the device160A is confirmed to be the medical consumer.

FIG. 7is a flowchart illustrating operations of a computing device in performing a method700of detecting a fraudulent request for billing authorization, according to some example embodiments. The method700includes operations710,720,730,740,750, and760. By way of example and not limitation, operations in the method700are described as being performed by the fraud prevention server130, using modules described above with respect toFIG. 2.

In operation710, the fraud prevention server130accesses an enrollment request for a medical fraud alert service for a medical consumer. For example, the medical consumer may use a web browser to access a website served by the fraud prevention server130. Using the website, the medical consumer provides identity information and requests the fraud prevention provider to provide the medical fraud alert service. Thus, in this example, the fraud prevention server accesses, via a network, the enrollment request from a first client device associated with the medical consumer. The enrollment request may include an identifier of a device (e.g., a phone number of a cellular phone) to which authentication requests are to be sent. Alternatively or additionally, the enrollment request may include other contact information, such as an email address, social media account name, or the like.

In response to the enrollment request, the authentication module220of the fraud prevention server130authenticates an identity of the medical consumer (operation720). For example, the method600may be used to confirm that the user requesting the medical fraud alert service is actually the medical consumer being enrolled.

The claims module230, in operation730, accesses an authorization request for billing a medical insurance provider associated with the medical consumer. For example, a medical services provider may use the device160B to submit an authorization request to bill a medical consumer's insurance provider. The authorization request is sent to a server of the insurance provider or to the clearinghouse server110. The insurance provider or the clearinghouse forwards the authorization request, via the network140, to the fraud prevention server130. Alternatively, the authorization request is sent by the insurance provider or the clearinghouse to the database server120and the fraud prevention server130periodically accesses the stored authorization requests. In some example embodiments, the authorization request is an electronic data interchange eligibility and benefit inquiry (EDI270).

In operation740, based on the authorization request, the alert module240causes the user interface module250to provide a user interface to the medical consumer. For example, the user interface400may be presented, comprising information about the medical services provider, the service provided, the medical insurance provider, the amount of the billing request, or any suitable combination thereof. The user interface400may be presented on the device identified in the enrollment request. For example, using a phone number provided in the enrollment request, the user interface400may be presented as a text message or push notification to the medical consumer.

The transmittal may occur via an email message, a message transmitted via a social media website, a telephone call, a letter, or any other transmittal method known in the art now or in the future. The transmittal may be in a secure mode to protect the privacy interests of the medical consumer. For example, the transmittal may be encoded such that a password may have to be entered prior to viewing. In various embodiments, the transmittal may be a notice that medical claims data have been received. In this situation, the medical consumer may securely log into a website (or make contact through another mechanism, such as a telephone call) and view the medical claims data.

In operation750, the fraud prevention server130receives, via the user interface, an indication that the authorization request was not initiated by the medical consumer. By way of example, the user may press or click on the button440, causing an HTTP transmission of data from the user's device (e.g., the device160A) to the fraud prevention server130via the network140.

Based on the received indication, the alert module240transmits, to the clearinghouse server110or to an insurance provider server, a notification that the authorization request is potentially fraudulent (operation760). Based on the notification, the clearinghouse server may notify the requesting medical service provider, deny the insurance authorization, request further instructions from the insurance provider, or any suitable combination thereof. Thus, in some example embodiments, the authorization request of operation730is sent from the medical services provider before a medical service is provided to the medical consumer or person attempting fraud in the medical consumer's name.

Alternatively, if the fraud prevention server130receives, via the user interface, an indication that the authorization request was initiated by the medical consumer, the insurance authorization request is allowed to proceed normally. Thus, the clearinghouse server110receives an authorization (or denial) from the insurance company server based on the information provided in the authorization request. In some example embodiments, the authorization response is an electronic data interchange eligibility and benefit inquiry response (EDI271).

In some example embodiments, when the fraud prevention server130does not receive an indication from the medical consumer as to whether the authorization request was initiated by the medical consumer or not, a default action is taken after a predetermined period of time. The default action may be to allow the authorization request to proceed normally or to reject the authorization request.

The medical consumer may provide a variety of responses to the data. The medical consumer may confirm that the data are accurate. For example, the medical claims data may specify that a claim was made against the medical insurance account of the medical consumer for a visit to a certain doctor on a given date. If the medical consumer recognizes the visit as one that the medical consumer actually made, then the medical consumer may provide a confirmation that the medical claims data are accurate.

However, the medical consumer may not recognize the medical goods or services specified in the medical claims data. In this situation, the medical consumer may be reasonably certain that he or she did not receive the medical goods or services. For example, the medical consumer may be certain that he or she was out of town on the date specified and could not have received the medical goods or services on the date or at the location specified. Thus, the medical consumer may provide confirmation that the medical claims data are inaccurate.

The medical consumer also may not recognize the medical goods or services because the medical consumer cannot recall whether the medical claims data are accurate, particularly if a date specified in the medical claims data is not recent. For example, the medical claims data may indicate that the medical consumer visited a certain doctor six months ago. The medical consumer may recognize the doctor as being one that he or she has visited, but is unsure whether the date of the visit is correct. Here, the medical consumer may provide a notification that he or she is unable to determine the accuracy of the medical claims data.

In various embodiments, the confirmation status may comprise a notification that the medical consumer has viewed the data. For example, when the medical consumer opens an email message containing the data, a notification may be automatically sent that the email message was viewed. In other embodiments, the medical consumer may log onto a website to view the data. In this situation, a notification may be sent that the medical consumer accessed the website containing the data.

A variety of actions may then be taken based on the confirmation status received from the medical consumer. If the confirmation status indicates that the medical claims data are accurate, then no further action may be taken. In various embodiments, a notification may be sent to the medical insurance provider that the medical consumer confirmed the data as accurate. The medical insurance provider may then take appropriate action with the claim. In the situation where the medical consumer indicates that the data are inaccurate, then the data may be flagged as being potentially fraudulent. Further investigation into the claim may be warranted, and the medical insurance provider may be notified of this status.

When the medical consumer is unable to determine the accuracy of the data, this may or may not indicate a possible fraudulent claim. Therefore, the claim may be flagged as needing further investigation, and the medical insurance provider may be so notified. In various embodiments, further communications may be initiated with the medical consumer when the medical consumer either confirms that the data are inaccurate, or is unable to determine the accuracy of the medical claims data.

Another possible situation is that the medical consumer does not respond to the transmittal of the data. In various embodiments, the claim may be assumed to be accurate and the medical consumer neglected to respond as such. Alternatively, the medical claims data may be flagged for further investigation, and notice provided to the medical insurance provider. In various embodiments, a reminder may be transmitted to the medical consumer if no response is received after a predetermined period of time. The reminder may be transmitted by the fraud prevention service provider, or by another entity tasked with this responsibility.

FIG. 8is a swim-lane diagram800illustrating communications between computer systems in performing a method of processing benefit eligibility data, according to some example embodiments. The swim-lane diagram800shows communications810,820,830,840,850, and860among the medical provider device160B, the clearinghouse server110, the fraud prevention server130, and the medical consumer device160A.

The medical provider device160B submits a request for insurance approval to the clearinghouse server110in communication810. For example, before seeing a patient, a doctor may submit a request to confirm that the insurance information provided by the patient is correct, and to request authorization from the insurance company to bill for the planned office visit. Rather than contacting the insurance company directly, the doctor may contact a clearinghouse, outsourcing the work of dealing with the various requirements of different insurance company's systems.

In communication820, the clearinghouse server110sends data for the approval request to the fraud prevention server130. For example, the name of the doctor and a description of the service to be performed may be sent.

The fraud prevention server130submits, in communication830, a verification request to the medical consumer device160A. As an example, the user interface400may be presented, including at least some of the data received in the communication820.

In communication840, the medical consumer device160A provides a verification response to the fraud prevention server130. For example, the user may press or click the button430or the button440, causing the medical consumer device160A to send an indication that the verification request was or was not initiated by the medical consumer.

The fraud prevention server130sends verification data, in communication850, to the clearinghouse server110. The verification data indicates whether the medical consumer verified the approval request or rejected it.

In communication860, the clearinghouse server110sends a response to the insurance approval request. The response is based on the verification data. Thus, if the medical consumer denies initiating the request, the request is denied. In this way, medical insurance fraud attempted by using someone else's medical insurance information can be prevented before the medical service is provided. By preventing the fraud at an earlier stage than was possible using prior art methods, resources expended in handling the medical services transaction, detecting fraud, and rectifying the situation are saved.

When these effects are considered in aggregate, one or more of the methodologies described herein may obviate a need for certain efforts or resources that otherwise would be involved in detecting fraud. Computing resources used by one or more machines, databases, or devices (e.g., within the network environment100) may similarly be reduced. Examples of such computing resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, and cooling capacity.

Modules, Components, and Logic

Electronic Apparatus and System

Software Architecture

FIG. 9is a block diagram900illustrating a software architecture902, which may be installed on any one or more of the devices described above.FIG. 9is merely a non-limiting example of a software architecture, and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. The software architecture902may be implemented by hardware such as a machine1000ofFIG. 10that includes processors1010, memory1030, and I/O components1050. In this example, the software architecture902may be conceptualized as a stack of layers where each layer may provide a particular functionality. For example, the software architecture902includes layers such as an operating system904, libraries906, frameworks908, and applications910. Operationally, the applications910invoke application programming interface (API) calls912through the software stack and receive messages914in response to the API calls912, according to some implementations.

In various implementations, the operating system904manages hardware resources and provides common services. The operating system904includes, for example, a kernel920, services922, and drivers924. The kernel920acts as an abstraction layer between the hardware and the other software layers in some implementations. For example, the kernel920provides memory management, processor management (e.g., scheduling), component management, networking, and security settings, among other functionality. The services922may provide other common services for the other software layers. The drivers924may be responsible for controlling or interfacing with the underlying hardware. For instance, the drivers924may include display drivers, camera drivers. Bluetooth® drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth.

In some implementations, the libraries906provide a low-level common infrastructure that may be utilized by the applications910. The libraries906may include system libraries930(e.g., C standard library) that may provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries906may include API libraries932such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as Moving Picture Experts Group-4 (MPEG4). Advanced Video Coding (H.264 or AVC). Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC). Adaptive Multi-Rate (AMR) audio codec. Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries (e.g., an OpenGL framework used to render in two dimensions (2D) and three dimensions (3D) in a graphic context on a display), database libraries (e.g., SQLite to provide various relational database functions), web libraries (e.g., WebKit to provide web browsing functionality), and the like. The libraries906may also include a wide variety of other libraries934to provide many other APIs to the applications910.

The frameworks908provide a high-level common infrastructure that may be utilized by the applications910, according to some implementations. For example, the frameworks908provide various graphic user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks908may provide a broad spectrum of other APIs that may be utilized by the applications910, some of which may be specific to a particular operating system or platform.

In an example embodiment, the applications910include a home application950, a contacts application952, a browser application954, a book reader application956, a location application958, a media application960, a messaging application962, a game application964, and a broad assortment of other applications such as a third-party application966. According to some embodiments, the applications910are programs that execute functions defined in the programs. Various programming languages may be employed to create one or more of the applications910, structured in a variety of manners, such as object-orientated programming languages (e.g., Objective-C, Java, or C++) or procedural programming languages (e.g., C or assembly language). In a specific example, the third-party application966(e.g., an application developed using the Android™ or iOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as iOS™, Android™, Windows® Phone, or other mobile operating systems. In this example, the third-party application966may invoke the API calls912provided by the mobile operating system (e.g., the operating system904) to facilitate functionality described herein.

Example Machine Architecture and Machine-Readable Medium

The machine1000may include processors1010, memory1030, and I/O components1050, which may be configured to communicate with each other via a bus1002. In an example embodiment, the processors1010(e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application-Specific Integrated Circuit (ASIC), a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor1012and a processor1014that may execute the instructions1016. The term “processor” is intended to include multi-core processors that may comprise two or more independent processors (also referred to as “cores”) that may execute instructions contemporaneously. AlthoughFIG. 10shows multiple processors1010, the machine1000may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

The memory1030may include a main memory1032, a static memory1034, and a storage unit1036accessible to the processors1010via the bus1002. The storage unit1036may include a machine-readable medium1038on which are stored the instructions1016embodying any one or more of the methodologies or functions described herein. The instructions1016may also reside, completely or at least partially, within the main memory1032, within the static memory1034, within at least one of the processors1010(e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine1000. Accordingly, in various implementations, the main memory1032, the static memory1034, and the processors1010are considered machine-readable media1038.

Communication may be implemented using a wide variety of technologies. The I/O components1050may include communication components1064operable to couple the machine1000to a network1080or devices1070via a coupling1082and a coupling1072, respectively. For example, the communication components1064include a network interface component or another suitable device to interface with the network1080. In further examples, the communication components1064include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices1070may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).

Transmission Medium

In example embodiments, the instructions1016are transmitted or received over the network1080using a transmission medium via a network interface device (e.g., a network interface component included in the communication components1064) and utilizing any one of a number of well-known transfer protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, in other example embodiments, the instructions1016are transmitted or received using a transmission medium via the coupling1072(e.g., a peer-to-peer coupling) to the devices1070. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions1016for execution by the machine1000, and includes digital or analog communications signals or other intangible media to facilitate communication of such software.

Language