Patent ID: 12254026

Although similar reference numbers may be used to refer to similar elements for convenience, it can be appreciated that each of the various example embodiments may be considered to be distinct variations.

The present embodiments will now be described hereinafter with reference to the accompany drawings, which form a part thereof, and which illustrate example embodiments which may be practiced. As used in the disclosures and the appending claims, the terms “embodiment” and “example embodiment” do not necessarily refer to a single embodiment, although it may, and various example embodiments may be readily combined and interchanged, without departing from the scope or spirit of the present embodiments. Furthermore, the terminology as used herein is for the purpose of describing example embodiments only, and are not intended to be limitations. In this respect, as used herein, the term “in” may include “in” and “on,”

DETAILED DESCRIPTION OF INVENTION

The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

Referring now toFIG.5, an exemplary user interface is shown depicting the current modal synchronization process that prohibits the access to the application while the synchronization is in progress. A modal501shows the current status of the synchronization process. However, while the synchronization is being executed, the application is not accessible in the background. This inconvenience limits the user's productivity. Embodiments disclosed in the present invention allow for non-blocking synchronization of secure customer data for an enterprise data management architecture.

FIG.1is a system overview illustrating an embodiment of a non-blocking synchronization of secure customer data system100. The presently disclosed embodiment comprises a controlled content repository102, a Customer Relationship Management (CRM)108, and a multichannel processing engine110. The CRM108comprises a customer relationship management subsystem104and a customer relationship management server106. The customer relationship management server106may provide access to a customer relationship management subsystem104, and the multichannel processing engine110. In one embodiment, the customer relationship management subsystem104may be operated by a third party.

The multichannel processing engine110may be accessed by users such as company sales representatives through web clients or through mobile apps (such as iOS, Android, Blackberry, or Windows Mobile systems), communicating with the multichannel processing engine108through web servers. Although the users may be described in the present application as being company sales representatives, this particular described embodiment is not intended to limit the generality of the claims that may eventually issue in patents stemming from the present disclosure.

The controlled content repository102is designed to have a process for developing approved content that is sharable across multiple users, such as shareholders, reviewers, managers, marketing personnel, sales representatives, etc. The content generated in the controlled content repository102may be accessed on a regulated basis and used to generate approved electronic communications. This regulated basis may be determined, in part, by the company as a whole and additionally by interaction with data from the customer relationship management subsystem104, described in further detail below. In one embodiment, approved content, customer profile information, customer preferences, and regulatory limitations and requirements may be stored in a table in the controlled content repository102. In addition to storage and development of content, the controlled content repository102may also store an audit trail150, tracking exact content of communications as they were sent by the user (e.g. pharmaceutical representative), as well as metadata about the communications and information regarding the content accessed by recipients (e.g. HCP).

In one implementation, the controlled content repository102may be a multi-tenant system where various elements of hardware and software may be shared by one or more customers. For instance, a server may simultaneously process requests from a plurality of customers. In a multi-tenant system, a user is typically associated with a particular customer. For instance, a user could be an employee of one of a number of pharmaceutical companies which are tenants, or customers. In one embodiment, the controlled content repository may run on a cloud computing platform.

The customer relationship management subsystem104contains all professional information of health care providers (HCPs) that may be available to users, including contact information, licensing information, areas of practice, and specialties. In addition, the customer relationship management subsystem may also be capable of storing configurations regarding specific preferences, regulatory limitations and requirements, and other fields that will facilitate the generation of appropriate approved electronic communications, in general or on a by recipient basis. These preferences and/or requirements include both the preferences of the user (e.g., maintaining account lists) as well as the preferences of the enterprise (e.g., employers of the users). In other examples, the customer relationship management subsystem may have a content management subsystem and may provide approved content and templates of approved communications.

In this embodiment, the customer relationship management subsystem104is capable of communication with multiple sources through the customer relationship management server106or through other channels to maintain a current and accurate collection of information regarding customer accounts. The interface with the multiple sources can be, for example, through an Applications Programming Interface or API, as the API interface will allow compatibility with a flexible array of third-party provider servers. The information being updated may include, but is not limited to, licensing information, area of practice, and location of the various customer contacts. In this manner, the customer relationship management subsystem104pulls the approved version of what represents an account or physician, which then pulls from multiple networks to ensure that the information regarding an account is up-to-date. The customer relationship management subsystem104may also be used to determine the type of domain an email communication is delivered through. A recipient in Spain may receive an email from “Companyx.es, whereas a recipient in Germany would receive the same email from “Companyx.ge.” This may allow for additional branding options for the company controlling and sending the electronic communications.

With further reference to the customer relationship management subsystem104, this system may be a cloud-based customer database that provides a central access to store and distribute consistent data across customer companies as well as their possible third-party partners and agencies that are used to keep this data updated. This system can provide standard data formats and provide an easy and automated way for customers (e.g. pharmaceutical companies) and/or users (e.g. pharmaceutical reps) to have access to coordinated and frequently updated CRM data and to use that coordinated data for sending approved electronic communications in accordance with the system described herein. In an embodiment, the multichannel processing engine110is responsible for combining the customer account information from the customer relationship management subsystem with content available from a controlled content repository. Within the customer relationship management subsystem104, customer accounts may be assigned a set of alignment rules which determine specific pieces of content that are available for use from the controlled content repository102. The multichannel processing engine110may apply these rules and supply the user with a list of approved communication templates and pieces of content that may then be used to construct a tailored approved communication.

Communication between the multichannel processing engine110and the customer relationship management subsystem104may occur via the customer relationship management server106, which acts as an interface between the two. The customer relationship management server106may act solely as an entry and exit point for the customer relationship management subsystem104. The user may access the multi-channel processing engine110through either a Web Client or through the mobile apps (such as IOS, Android, Blackberry, or Windows Mobile systems).

FIG.2illustrates an exemplary block diagram of a computing device200which can be used as the user computing devices120a-120ninFIG.1. The computing device200is only one example of a suitable computing environment and is not intended to suggest any limitation as to scope of use or functionality. The computing device200may include a processing unit201, a system memory202, an input device203, an output device204, a network interface205, and a system bus206that couples these components to each other.

The processing unit201may be configured to execute computer instructions that are stored in a computer-readable medium, for example, the system memory202. The processing unit201may be a central processing unit (CPU).

The system memory202typically includes a variety of computer readable media which may be any available media accessible by the processing unit201. For instance, the system memory202may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). By way of example, but not limitation, the system memory202may store instructions and data, e.g., an operating system, program modules, various applications programs, and program data.

A user can enter commands and information to the computing device200through the input device203. The input device203may be, e.g., a keyboard, a touchscreen input device, a touch pad, a mouse, a microphone, and/or a pen.

The computing device200may provide its output via the output device204which may be a monitor or other type of display device, a speaker, or a printer.

The computing device200, through the network interface205, may operate in a networked or distributed environment using logical connections to one or more other computing devices, which may be a personal computer, a server, a router, a network PC, a peer device, a smart phone, or any other media consumption or transmission device, and may include any or all of the elements described above. The logical connections may include a network (e.g., the network150) and/or buses. The network interface205may be configured to allow the computing device200to transmit and receive data in a network, for example, the network150. The network interface205may include one or more network interface cards (NICs).

FIG.3illustrates an exemplary high level block diagram of a user computing device (e.g.,120a) wherein the present invention may be implemented. The user computing device120amay be implemented by the computing device200described above, and may have a processing unit1201, a system memory1202, an input device1203, an output device1204, and a network interface1205, coupled to each other via a system bus1206. The client application121and the client database122may be stored in the system memory1202. In one embodiment, the client database122may be maintained in a local store, e.g., a hard disk, relational store, cache memory, etc. The system memory1202may also store a synchronization controller123, which may facilitate the non-blocking synchronization of secure customer data between the client database122, the customer relationship management subsystem104, and the controlled content repository102. The synchronization controller123may serve as an interface between the various data sources including the client database122, the customer relationship management subsystem104and the controlled content repository102.

In one embodiment, the client application121is a sales tool for helping users (e.g., sales representatives) of customers (e.g., pharmaceutical companies) to promote products to health care professionals (HCPs). Each of the customers (e.g., pharmaceutical companies) may store physician professional information it collected and/or purchased in the CRM subsystem104which may be a multi-tenant, cloud based CRM database system. Each customer (e.g., pharmaceutical company) may manage data availability to its users (e.g., pharmaceutical representatives) by territories, which could be a geographic area, or a product. Each user may access data in the CRM subsystem104of one of the customers, specifically data for physicians in the territory he/she is assigned. A customer may store information of tens of thousands of physicians and hundreds of products in the CRM subsystem104, but a user (e.g., pharmaceutical representative) may be allowed access to information of only a subset of the physicians (e.g., hundreds) and/or a subset of the products (e.g., tens) which are in the territory he/she is assigned.

To enable a user (e.g., pharmaceutical representative) to use the client application121even when the user computing devices120a-120nare disconnected and provide seamless transition between online and offline use, data relevant to a user's (e.g., pharmaceutical representative) use of the client application121may be stored in the client database122. Such information may include, e.g., data related to the subset of physicians and/or products in his/her territory. The user (e.g., sales representative) may further be allowed to access the closed loop marketing (“CLM”) content for the subset of products in his/her territory. The user (e.g., pharmaceutical representative) may further be allowed to access analytics data about the subset of physicians and/or products in his/her territory. The CLM content for the subset of products and analytics data about the subset of physicians and/or products may be stored in the client database122as well. The client application121may be used by the users (e.g., pharmaceutical representatives) to, e.g., search for a physician, schedule a meeting with the physician, search for and display CLM content during the meeting with the physician, record the call, and update physician and/or product information.

In order to provide a user (e.g., pharmaceutical representative) correct and newest information, and to share new information from a user with other users for the same customer (e.g., pharmaceutical company), client databases122on user computing devices120a-120nand the enterprise data storage (e.g., CRM subsystem104) need to be synchronized from time to time. The client database122and the enterprise data storage may be synchronized regularly according to a present schedule, in response to a user request, and/or when the user computing device120a-120nis back online.

FIGS.4A and4Billustrate an exemplary flowchart of a method for non-blocking synchronization of secure customer data in the enterprise data management architecture100(as shown inFIG.1) from a client application according to one embodiment of the present invention. Referring now toFIG.4A, the process may start at401.

At402, determination is made whether the user ID is authenticated to access the enterprise data storage. In one implementation, the data storage may be the CRM subsystem104. The user (e.g., pharmaceutical representative) may log into the client application121, and be authenticated to access the CRM subsystem104.

At403, after the user ID is authenticated to access the enterprise data storage, the synchronization controller123establishes a reference database and staging database in the system memory1202. The reference database may store a subset of the enterprise data storage (e.g., CRM subsystem104) that client applications (e.g.,121) in user computing devices120a-120nmay use. In one embodiment, the reference database may store data that pharmaceutical companies may need when promoting new products, which may include physician professional information (e.g., name, specialty, license information, affiliated health care organization (“HCO”), contact information at the affiliated HCO, prior interaction record, electronic signature for samples, and medical inquiry submission), product information (e.g., name, category, lot and statistics), pharmaceutical representative information (e.g., name, territory information, sharing rules and sales reports). It should be understood that the reference database may store data for other industries as well. In another embodiment, the reference database may store CRM data for managing opportunities and tracking employee success rates.

In one implementation, the staging database may contain an initial copy of the reference database. New changes (updates, additions, deletions, etc.) may be performed on the staging database as will be described in further detail below.

At404, the synchronization controller123establishes an upload queue and a tracking table for recording all changed data fields and their associated timestamps. Maintaining a tracking table stores information about what data object records have been modified. In one implementation, the tracking table includes entries for every change (e.g., creation, deletion, modification, etc.), timestamps, relevant UUIDs, relevant changed data fields, and indication whether the record was deleted as part of the operation. For example, for an auto sync download the system modified timestamp or the last modified date for the data object record will be stored. For auto sync uploads, a constant distant future timestamp is used when placed into the upload queue and updated with the server timestamp on successful upload. Storing the information in the tracking table eliminates the need for extra queries and accessing the database to query the timestamps. Storing relevant universal unique identifiers (UUIDs) may be needed for uploads, specifically the UUID needs to match the UUID of the upload transaction in the tracking table so the timestamp can be updated after the upload is completed. Storing relevant changed fields are useful when copying local changes because standard updates on offline clients only update/upload data fields that the user has explicitly changed. Indication of whether the data object record was deleted may be useful for special handling, as will be described in further detail below.

At405, the synchronization controller123writes the new metadata and data object field changes on the staging database. In one implementation, the reference database will still contain the subset of the enterprise data storage after the most recent refresh or synchronization. The reference database is clean and does not contain any user or local changes. The reference database is kept in a state that is what the offline client application121should have.

At406, when the new metadata and data object field changes are finished downloading into the staging database, the synchronization controller123may determine whether the reference database needs migration. Referring now toFIG.6, an exemplary user interface for initiating non-blocking synchronization of secure customer data is shown. Either the “Refresh” button601, or the “Full Database Refresh” button602requires the migration of the reference database. In another implementation, a synchronization may be regularly initiated according to a present schedule, and/or when the user computing device120a-120nis back online. When the refresh or synchronization is identified, the synchronization controller123may continue to step407. Otherwise, the synchronization controller will continue to write the new metadata and data object field changes on the staging database in405.

Referring now toFIG.7, another exemplary user interface700is shown for initiating non-blocking synchronization of secure customer data that depicts the status of the non-blocking synchronization process701. As shown, the client application121is still accessible while the non-blocking synchronization is in process. In another implementation, the “Update could not be applied” message may be displayed to indicate a synchronization error.

Referring now toFIG.4B, at407, actions are needed to ensure the client application121is in a good state when applying changes. In one implementation, the synchronization controller123ensures changes are placed in the upload queue and corresponding entries are created in the tracking table. Other actions may include existing cleanup for upload, auto sync, geocoder, and account address mapping.

At408, the synchronization controller clones the reference database. In one implementation, the synchronization controller123copies both the metadata and the data objects of the reference database to generate a cloned reference database which will contain the local changes as will be described in further detail below.

At409, background processes that may invalidate the database connections are preemptively stopped. In one implementation, the synchronization controller123stops the background processes that modify the staging database in the background. For example, some upload processes may create duplicate calls. Similarly, auto sync merging, geocoder, and account address mapping may modify the staging database in the background.

At410, local changes are applied and written to the cloned reference database based on compared timestamps stored in the tracking table. In one implementation, the timestamp may be the timestamp when the data object record was last modified or acknowledged online and is a server based timestamp. If a record is saved or merged by auto sync, the record id, mobile id, and object type are stored along with the data object record timestamp in the tracking table. If the record exists in the cloned reference database and the timestamp for the record id in the cloned reference database is older, the record corresponds to a local change. In this case, the staging database record kept. However, if the timestamp for the record id in the cloned reference database is newer, the record is up to date in the cloned reference database. In this case, the staging database record can be removed. If the record ID does not exist in the cloned reference database and there is a pending upload in the upload queue, then the record corresponds to a local change and the staging database record kept. If the record ID does not exist in the cloned reference database and there is not a pending upload in the upload queue, then the record should not exist offline and the staging record can be removed. In one implementation, timestamps of entries in the tracking table are compared to the timestamps for the record ids in the cloned reference database. When the timestamps for the record id in the tracking table are newer than the timestamps for the record id in the cloned reference database, this corresponds to a local change and the local change is written to the cloned reference database.

At411, certain special exceptions need to be handled to ensure a seamless user experience. In one implementation, some user options are not captured as local changes that would be saved in the cloned reference database, but need to be carried over to ensure a positive user experience. One example may be filters on the secure customer data. As will be described in more detail further below, the staging database will be swapped and if these user configurations or options are not propagated, the user experience will be disturbed. Another example is when new users are created, these are not captured by the tracking table, but need to be. In another implementation, some options need to be excluded from the cloned reference database. One example may be the timestamp since these timestamps will be modified by the synchronization process as detailed above.

At412, the synchronization controller123deletes the staging database. In one implementation, the local changes from the staging database were transferred to the cloned reference database in410above.

At413, the synchronization controller123replaces the deleted staging database with the cloned reference database that includes the local changes. In one implementation, the synchronization controller123ensures the proper data storage mapping. When there are any issues during the database migration (e.g., cannot create mapping model, or cannot write metadata/data from the staging database to the cloned reference database due to a corrupt database), the reference database is deleted and a full refresh is performed.

At414, the synchronization controller123sends notification of the status of the synchronization. Referring to theFIG.8, a synchronization status is displayed at801. As depicted, the color indicator as well as the last sync date and time are provided. In another implementation, a “downloading update” status may be displayed to indicate the reference database is being established in403. In one implementation, if there is a synchronization error, the user may be prompted with a modal indicating the failed refresh and the option to cancel the refresh. The synchronization controller123then deletes the staging database and makes a copy of the reference database to use as the staging database.

At415, the synchronization controller123records the audit trail to include any synchronization errors. The process ends at416.

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the claims and their equivalents for any patent that issues claiming priority from the present provisional patent application.

In all descriptions of “servers” or other computing devices herein, whether or not the illustrations of those servers or other computing devices similarly show a server-like illustration in the figures, it should be understood that any such described servers or computing devices will similarly per form their described functions in accordance with computer readable instructions stored on a computer-readable media that are connected thereto.

Resources may encompass any types of resources for running instances including hardware (such as servers, clients, mainframe computers, networks, network storage, data sources, memory, central processing unit time, Scientific instruments, and other computing devices), as well as software, software licenses, available network services, and other non-hardware resources, or a combination thereof.

A networked computing environment may include, but is not limited to, computing grid systems, distributed computing environments, cloud computing environment, etc. Such networked computing environments include hardware and Software infrastructures configured to form a virtual organization comprised of multiple resources which may be in geographically disperse locations.

The approved content may be in any format, e.g., text, audio, video, picture, multimedia, or PDF.

Various terms used herein have special meanings within the present technical field. Whether a particular term should be construed as such a “term of art, depends on the context in which that term is used. “Connected to,” “in communication with or other similar terms should generally be construed broadly to include situations both where communications and connections are direct between referenced elements or through one or more intermediaries between the referenced elements, including through the Internet or some other communicating network. “Network,” “system,” “environment,” and other similar terms generally refer to networked computing systems that embody one or more aspects of the present disclosure. These and other terms are to be construed in light of the context in which they are used in the present disclosure and as those terms would be understood by one of ordinary skill in the art would understand those terms in the disclosed context. The above definitions are not exclusive of other meanings that might be imparted to those terms based on the disclosed context.

Words of comparison, measurement, and timing such as “at the time.” “equivalent,” “during,” “complete,” and the like should be understood to mean “substantially at the time.” “substantially equivalent,” “substantially during,” “substantially complete,” etc., where “substantially” means that such comparisons, measurements, and timings are practicable to accomplish the implicitly or expressly stated desired result.

The steps and/or operations described above in relation to an embodiment of the present disclosure may occur in a different order, or in parallel, or concurrently for different epochs, etc. depending on the specific embodiment and/or implementation, as would be understood by one of ordinary skill in the art. Different embodiments may perform actions in a different order or by different ways or means. As would be understood by one of ordinary skill in the art, some drawings are simplified representations of the actions performed, their descriptions herein simplified overviews, and real-world implementations would be much more complex, require more stages and/or components, and would also vary depending on the requirements of the particular implementation. Being simplified representations, these drawings do not show other required steps as these may be known and understood by one of ordinary skill in the art and may not be pertinent and/or helpful to the present description.

Similarly, some drawings are simplified block diagrams showing only pertinent components, and some of these components merely represent a function and/or operation well-known in the field, rather than an actual piece of hardware, as would be understood by one of ordinary skill in the art. In such cases, some or all of the components/modules may be implemented or provided in a variety and/or combinations of manners, such as at least partially firmware and/or hardware, including, but not limited to one or more application-specific integrated circuits (“ASICS”), standard integrated circuits, controllers executing appropriate instructions, and including microcontrollers and/or embedded controllers, field-programmable gate arrays (“FPGAs”), complex programmable logic devices (“CPLDs”), and the like. Some or all of the system components and/or data structures may also be stored as contents (e.g., as executable or other machine-readable software instructions or structured data) on a non-transitory computer-readable medium (e.g., as a hard disk; a memory; a computer network or cellular wireless network or other data transmission medium; or a portable media article to be read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) so as to enable or configure the computer-readable medium and/or one or more associated computing systems or devices to execute or otherwise use or provide the contents to perform at least some of the described techniques.

One or more processors, simple micro controllers, controllers, and the like, whether alone or in a multi-processing arrangement, may be employed to execute sequences of instructions stored on non-transitory computer-readable media to implement embodiments of the present disclosure. In some embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments of the present disclosure are not limited to any specific combination of hardware circuitry, firmware, and/or software.

The term “computer-readable medium” as used herein refers to any medium that stores instructions which may be provided to a processor for execution. Such a medium may take many forms, including but not limited to, non-volatile and volatile media. Common forms of non-transitory computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, or any other medium on which instructions which can be executed by a processor are stored.

Additionally, the section headings herein are provided for consistency with the suggestions under 37 CFR 1.77 or otherwise to provide organizational cues. These headings shall not limit or characterize the invention(s) set out in any claims that may issue from this disclosure. Specifically and by way of example, although the headings refer to a “Technical Field, such claims should not be limited by the language chosen under this heading to describe the so-called technical field. Further, a description of a technology in the “Background is not to be construed as an admission that technology is prior art to any invention(s) in this disclosure. Neither is the “Brief Summary” to be considered as a characterization of the invention(s) set forth in issued claims. Furthermore, any reference in this disclosure to “invention’ in the singular should not be used to argue that there is only a single point of novelty in this disclosure. Multiple inventions may be set forth according to the limitations of the multiple claims issuing from this disclosure, and such claims accordingly define the invention(s), and their equivalents, that are protected thereby. In all instances, the scope of such claims shall be considered on their own merits in light of this disclosure, but should not be constrained by the headings set forth herein.