DETAILED ACTION
Status of the Claims
1. This action is in response to the application filed on March 7, 2025.
2. Claims 1-22 are currently pending and have been examined.
Notice of Pre-AIA or AIA Status
3. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
4. Claims 15 and 19 are objected to because of the following informalities:
In Claim 15, the third limitation recites in part “identifying one or mor electronic records…”.
This appears to be a typographical error and should more properly read “identifying one or more electronic records…”. For purposes of examination, the claim will be interpreted in this manner, however appropriate correction is required.
In Claim 19, the third limitation recites in part “identifying one or mor electronic records…”.
This appears to be a typographical error and should more properly read “identifying one or more electronic records…”. For purposes of examination, the claim will be interpreted in this manner, however appropriate correction is required.
Claim Interpretation – Broadest Reasonable Interpretation
5. In determining patentability of an invention over the prior art, all claim limitations have been considered and interpreted using the “broadest reasonable interpretation consistent with the specification during the examination of a patent application since the applicant may then amend his claims.” See In re Prater and Wei, 162 USPQ 541, 550 (CCPA 1969); MPEP § 2111. Applicant always has the opportunity to amend the claims during prosecution, and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. See In re Prater, 162 USPQ 541, 550-51 (CCPA 1969); MPEP § 2111. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 26 USPQ2d 1057 (Fed. Cir. 1993). See also MPEP 2173.05(q) All claim limitations have been considered. Additionally, all words in the claims have been considered in judging the patentability of the claims against the prior art. See MPEP 2143.03.
Language in a method or system claim that states only the intended use or intended result, but does not result in a manipulative difference in the steps of the method claim nor a structural difference between the system claim and the prior art, fails to distinguish the claims from the prior art. In other words, if the prior art structure is capable of performing the intended use, then it meets the claim.
Claim limitations that contain statement(s) such as “if, may, might, can, could”, are treated as containing optional language. As matter of linguistic precision, optional claim elements do not narrow claim limitations, since they can always be omitted.
Claim limitations that contain statement(s) such as “wherein, whereby”, that fail to further define the steps or acts to be performed in method claims or the discrete physical structure required of system claims.
The subject matter of a properly construed claim is defined by the terms that limit its scope. It is this subject matter that must be examined. As a general matter, the grammar and intended meaning of terms used in a claim will dictate whether the language limits the claim scope.
Language that suggests or makes a feature or step optional but does not require that feature or step does not limit the scope of a claim under the broadest reasonable claim interpretation. Claim scope is not limited by claim language that suggests or makes optional but does not require steps to be performed, or by claim language that does not limit a claim to a particular structure. In addition, when a claim requires selection of an element from a list of alternatives, the prior art teaches the element if one of the alternatives is taught by the prior art. See, e.g., Fresenius USA, Inc. v. Baxter Int’l, Inc., 582 F.3d 1288, 1298 (Fed. Cir. 2009). See MPEP 2111.04, 2143.03. The following types of claim language may raise a question as to its limiting effect (this list is not exhaustive):
Preamble (MPEP 2111.02);
Clauses such as “adapted to”, “adapted for”, “wherein”, and “whereby” (MPEP 2111.04)
Contingent limitations (MPEP 2111.04)
Printed matter (MPEP 2111.05) and
Functional language associated with a claim term (MPEP 2181)
Examiner notes that during examination, “claims … are to be given their broadest reasonable interpretation consistent with the specification, and … claim language should be read in light of the specification as it would be interpreted by one of ordinary skill in the art.” See In re Bond, 15 USPQ 1566, 1568 (Fed. Cir. 1990), citing In re Sneed, 218 USPQ 385, 388 (Fed. Cir. 1983). However, "in examining the specification for proper context, [the examiner] will not at any time import limitations from the specification into the claims". See CollegeNet, Inc. v. ApplyYourself, Inc., 75 USPQ2d 1733, 1738 (Fed. Cir. 2005). Construing claims broadly during prosecution is not unfair to the applicant, because the applicant has the opportunity to amend the claims to obtain more precise claim coverage. See In re Yamamoto, 222 USPQ 934, 936 (Fed. Cir. 1984), citing In re Prater, 162 USPQ 541, 550 (CCPA 1969).
As such, while all claim limitations have been considered and all words in the claims have been considered in judging the patentability of the claimed invention, the following language is interpreted as not further limiting the scope of the claimed invention.
The preamble of the instant claim 1 recites "A system to access and update electronic record information via a back-end application computer server of an enterprise” In general, a preamble limits the invention if it recites essential structure or steps, or if it is "necessary to give life, meaning, and vitality" to the claims. Pitney Bowes, Inc. v. Hewlett-Packard Co. 51 USPQ2d 1161 (Fed. Cir. 1999), Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002). Conversely, where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or an intended use for the invention, the preamble is not a claim limitation given patentable weight. Rowe v. Dror, 42 USPQ2d 1550 (Fed. Cir. 1997); Catalina Marketing International Inc. v. Coolsavings.com Inc., 62 USPQ2d 1781 (Fed. Cir. 2002); Bell Communications Research, Inc. v. Vitalink Communications Corp., 34 USPQ2d 1816 (Fed. Cir. 1995) If a prior art structure is capable of performing the intended use as recited in the preamble, then it meets the claim. See, e.g., In re Schreiber, 128 F.3d 1473, 1477, 44 USPQ2d 1429, 1431 (Fed. Cir. 1997) See MPEP 2111.02
In the instant case, “to access and update electronic record information” as recited in the preamble only states a purpose and/or the intended use of the invention and accordingly is not being assigned any patentable weight.
Independent Claims 15 and 19 recite the same intended use language in the preambles of the respective method and computer readable medium claim and are being similarly interpreted as not being assigned any patentable weight.
Further, the following italicized limitations are stating a purpose and/or intended use of the invention and accordingly are not being given further weight.
As in Claim 1:
determine an authorization status to access one or more suppressible electronic records of the electronic records;
identify one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status;
generate a user interface display including a link to access a subset of the one or more suppressible electronic records, the subset excluding the suppressed one or more electronic records;
transmit, to a first remote user device of a first user associated with the enterprise, a grid display of information about the subset of the electronic records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about electronic records not in the subset is blocked from being transmitted to the first remote user device to avoid misappropriation and misuse of the blocked data;
store the received annotation such that the annotation is accessible via a second remote user device of a second user associated with the enterprise; and
(d) a communication port coupled to the back-end application computer server to facilitate a transmission of data with the first and second remote user devices to support interactive user interface displays via a distributed communication network.
As in Claim 15:
accessing, by a back-end application computer server, information in a potential risk relationship data store containing electronic records that represent a plurality of potential risk relationships with the enterprise and for each potential risk relationship, an electronic record identifier and a set of entity attribute values including an entity identifier, wherein the electronic records include one or more suppressible electronic records;
determining an authorization status to access one or more suppressible electronic records;
identifying one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status;
generating a user interface display including a link to access a subset of the one or more suppressible electronic records, the subset excluding the suppressed one or more electronic records;
transmitting, to a first remote user device of a first user associated with the enterprise, a grid display of information about the subset of the electronic records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about electronic records not in the subset is blocked from being transmitted to the first remote user device to avoid misappropriation and misuse of the blocked data;
storing the received annotation such that the annotation is accessible via a second remote user device of a second user associated with the enterprise.
As in Claim 19:
determining an authorization status to access one or more suppressible electronic records;
identifying one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status;
generating a user interface display including a link to access a subset of the one or more suppressible electronic records, the subset excluding the suppressed one or more electronic records;
transmitting, to a first remote user device of a first user associated with the enterprise, a grid display of information about a subset of the electronic records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about electronic records not in the subset is blocked from being transmitted to the first remote user device to avoid misappropriation and misuse of the blocked data;
storing the received annotation such that the annotation is accessible via a second remote user device of a second user associated with the enterprise.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
6. Claims 1-22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As currently presented, Applicant has presented the following limitations which are not properly supported by the specification as currently claimed. Independent Claims 1, 15 and 19 recite substantially similar limitations, as demonstrated by the limitations in exemplary Claim 1.
“determine an authorization status to access one or more suppressible electronic records of the electronic records;
identify one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status;”
Applicant’s specification does not disclose “an authorization status” or “the determined authorization status” as currently claimed. There is no mention of an authorization status in the specification. The closest recitation is as follows:
“FIG. 3 is an example of a landing page display 300 for an insurance policy cross-sell information access and update tool in accordance with some embodiments. The landing page 300 might comprise an initial view of tool and provide a navigation structure 310 and/or links to let the user access information in various ways. The links might include, for example, cross sell lists 320 for one or more sub-organizations associated with an enterprise. For each sub-organization, a list of insurance segment links may be provided (and selection of one of those links, e.g., via touchscreen or computer mouse pointer 390, may result in a grid display such as the one described in connection with FIG. 4). According to some embodiments, links for executive dashboards 330 may also be provided to those who are authorized to access that information. The display 300 may further include a quick-start guide icon 340 and/or a “view my accounts” icon 350. (e.g., resulting in a display such as the one described in connection with FIG. 10)” (See Applicant Spec para 33)
This is the only mention of “authorized” in the disclosure. There is no recitation of a status or an authorized status or a determination of an authorized status.
Applicant also recites the following in Claim 1:
a coupled communication port
(d) a communication port coupled to the back-end application computer server to facilitate a transmission of data with the first and second remote user devices to support interactive user interface displays via a distributed communication network.
The specification does not disclose a “communication port”, rather the specification only discloses a communication device associated with a back-end application computer server and that the communication device exchanges information with remote devices in connection with an interactive graphical user interface. (See Applicant Spec paras 6 and 43)
Further, while the communications device disclosed may be used to communicate with one or more remote administrator computers and/or communication devices, it does not further disclose “to support interactive user interface displays” as currently claimed.
Rather, the specification indicates that in some embodiments, the elements of the system automatically transmit information associated with an interactive user interface display over a distributed communication network (See Applicant Spec para 27) The recitation of “to support interactive user interface displays” appears to recite that there is some sort of support functionality that impacts interactive user interface displays, which is not disclosed.
Dependent Claims 2-14, 16-18 and 20-21 are further rejected as based on a rejected base claim.
Applicant is required to cancel the new matter in the reply to this Office Action.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
7. Claims 1-22 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
ANALYSIS:
STEP 1:
Does the claimed invention fall within one of the four statutory categories of invention (process, machine, manufacture or composition matter?
Claim 1 recites a system claim. Claim 15 recites a method claim. Claim 19 recites a computer-readable medium claim. Currently, the computer-readable medium claim has a separate rejection as being non-statutory (as shown below), however Examiner assumes that Applicant will rectify the claims to properly claim the invention as within statutory categories.
STEP 2A:
Prong One: Does the Claim Recite A Judicial Exception (An Abstract Idea, Law of Nature or Natural Phenomenon)? (If Yes, Proceed to Prong Two, If No, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material)
Claim 1 recites the abstract idea of accessing and updating record information. The idea is described by the following limitations:
a potential risk relationship data store containing records that represent a plurality of potential risk relationships with the enterprise and, for each potential risk relationship, a record identifier and a set of entity attribute values including an entity identifier;
an existing risk relationship data store containing records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise;
determine an authorization status to access one or more suppressible records of the records;
identify one or more records of the one or more suppressible records for suppression based on the determined authorization status;
to access a subset of the one or more suppressible records, the subset excluding the suppressed one or more records;
receive selection, and in response to the received selection, access information in the potential risk relationship data store and the existing risk relationship data store;
generate a first grid display including the subset of records, avoiding transmission of data about all risk relationships;
transmit, to a first user associated with the enterprise, a grid display of information about the subset of the records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about records not in the subset is blocked from being transmitted to the first user to avoid misappropriation and misuse of the blocked data;
receive, from the first user, an annotation associated with a selected entity; and
store the received annotation such that the annotation is accessible by a second user associated with the enterprise; and
facilitate a transmission of data with the first and second users.
Claim 15 recites the abstract idea of accessing and updating record information. The idea is described by the following limitations:
accessing, information in a potential risk relationship data store containing records that represent a plurality of potential risk relationships with the enterprise and for each potential risk relationship, a record identifier and a set of entity attribute values including an entity identifier, wherein the records include one or more suppressible records;
determining an authorization status to access one or more suppressible records;
identifying one or more records of the one or more suppressible records for suppression based on the determined authorization status;
to access a subset of the one or more suppressible records, the subset excluding the suppressed one or more records;
receiving selection and, in response to the received selection, accessing, information in an existing risk relationship data store containing records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise;
transmitting, to a first user associated with the enterprise, a grid display of information about the subset of the records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about records not in the subset is blocked from being transmitted to the first user to avoid misappropriation and misuse of the blocked data;
receiving, from the first user, an annotation associated with a selected entity; and
storing the received annotation such that the annotation is accessible via a second user associated with the enterprise.
Claim 19 recites the abstract idea of accessing and updating record information. The idea is described by the following limitations:
accessing information in a potential risk relationship data store containing records that represent a plurality of potential risk relationships with the enterprise and, for each potential risk relationship, a record identifier and a set of entity attribute values including an entity identifier;
determining an authorization status to access one or more suppressible records;
identifying one or more records of the one or more suppressible records for suppression based on the determined authorization status;
to access a subset of the one or more suppressible records, the subset excluding the suppressed one or more records;
receiving selection and, in response to the received selection, accessing, information in an existing risk relationship data store containing records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise;
transmitting, to a first user associated with the enterprise, a grid display of information about a subset of the records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about records not in the subset is blocked from being transmitted to the first user to avoid misappropriation and misuse of the blocked data;
receiving, from the first user, an annotation associated with a selected entity; and
storing the received annotation such that the annotation is accessible via a second user associated with the enterprise.
Under a BRI, the claims may reflect no more than selection of records based on authorization status to be provided to a user in a display along a first and second axis, annotating and subsequently storing the records so that they are able to be accessed by a second user.
As such, the abstract ideas describe mental processes and certain methods of organizing human activity.
As to mental processes, the steps describe concepts performed in the human mind including an observation, evaluation, judgment and/or opinion. (i.e., accessing, information in a potential risk relationship data store containing records that represent a plurality of potential risk relationships with the enterprise and for each potential risk relationship, a record identifier and a set of entity attribute values including an entity identifier, wherein the records include one or more suppressible records; determining an authorization status to access one or more suppressible records; identifying one or more records of the one or more suppressible records for suppression based on the determined authorization status; to access a subset of the one or more suppressible records, the subset excluding the suppressed one or more records; receiving selection and, in response to the received selection, accessing, information in an existing risk relationship data store containing records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise; transmitting, to a first user associated with the enterprise, a grid display of information about the subset of the records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about records not in the subset is blocked from being transmitted to the first user to avoid misappropriation and misuse of the blocked data; receiving, from the first user, an annotation associated with a selected entity; and storing the received annotation such that the annotation is accessible via a second user associated with the enterprise.) These steps are performing a mental process in a computer environment that recites limitations observing, receiving, evaluating information and making judgments and with the exception of generic computer-implemented steps, there is nothing in the claims themselves that foreclose them from being performed by a human mentally.
As to certain methods of organizing human activity, the steps are involving managing personal behavior or relationships or interactions between people including following rules or instructions; commercial interactions including advertising, marketing or sales activities or behaviors and business relations (i.e., accessing, information in a potential risk relationship data store containing records that represent a plurality of potential risk relationships with the enterprise and for each potential risk relationship, a record identifier and a set of entity attribute values including an entity identifier, wherein the records include one or more suppressible records; determining an authorization status to access one or more suppressible records; identifying one or more records of the one or more suppressible records for suppression based on the determined authorization status; to access a subset of the one or more suppressible records, the subset excluding the suppressed one or more records; receiving selection and, in response to the received selection, accessing, information in an existing risk relationship data store containing records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise; transmitting, to a first user associated with the enterprise, a grid display of information about the subset of the records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about records not in the subset is blocked from being transmitted to the first user to avoid misappropriation and misuse of the blocked data; receiving, from the first user, an annotation associated with a selected entity; and storing the received annotation such that the annotation is accessible via a second user associated with the enterprise.) (Step 2A, Prong 1: Yes, the claims are abstract)
Prong Two: Does the Claim Recite Additional Elements That Integrate The Judicial Exception Into A Practical Application of the Exception? (If Yes, the claim is not directed to a judicial exception and qualifies as subject matter patent eligible material. If No, Proceed to Step 2B)
The claims do not include additional elements that integrate the judicial exception into a practical application of the exception because the claims do not provide improvements to another technology or technical field, improvements to the functioning of the computer itself, are not applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, are not applying the judicial exception with, or by use of a particular machine, are not effecting a transformation or reduction of a particular article to a different state or thing, and are not applying the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Claim 1 recites a back-end application computer server including a computer processor and a computer memory coupled to the computer processor and a coupled communication port; instructions; a user interface display; a link; touch screen or computer mouse pointer; a first remote user device; a second remote user device, interactive user displays, a distributed communication network and an indication that records and record identifiers are electronic.
Claim 15 recites a back-end application computer server; a user interface display; a first remote user device; a second remote user device and an indication that records and record identifiers are electronic.
Claim 19 recites a non-tangible, computer-readable medium; instructions; a processor; a back-end application computer server; a user interface display; a first remote user device; a second remote user device and an indication that records and record identifiers are electronic.
The claims recite a back-end application computer server including a computer processor, a computer memory, a coupled communication port; a user interface display; touch screen or computer mouse pointer; a first remote user device; a second remote user device; interactive user displays; a distributed communication network; a non-tangible, computer-readable medium; a processor; instructions, a link, and an indication that records and record identifiers are electronic which are recited at a high level of generality (i.e., as a generic processor performing generic computer functions) such that it amounts to no more that mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, Claims 1, 15 and 19 are directed to an abstract idea without a practical application. (Step 2A – Prong 2: No, the additional claimed elements are not integrated into a practical application)
STEP 2B: If there is an exception, determine if the claim as a whole recites significantly more than the judicial exception itself.
The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: i) receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); ii) performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims."); iii) electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv) storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; v) electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition); and vi) a web browser’s back and forward button functionality, Internet Patent Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1418 (Fed. Cir. 2015). (MPEP §2106.05(d)(II))
This listing is not meant to imply that all computer functions are well‐understood, routine, conventional activities, or that a claim reciting a generic computer component performing a generic computer function is necessarily ineligible. Courts have held computer‐implemented processes not to be significantly more than an abstract idea (and thus ineligible) where the claim as a whole amounts to nothing more than generic computer functions merely used to implement an abstract idea, such as an idea that could be done by a human analog (i.e., by hand or by merely thinking). On the other hand, courts have held computer-implemented processes to be significantly more than an abstract idea (and thus eligible), where generic computer components are able in combination to perform functions that are not merely generic. (MPEP §2106.05(d)(II) – emphasis added)
Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: recording a customer’s order, Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1244, 120 USPQ2d 1844, 1856 (Fed. Cir. 2016); shuffling and dealing a standard deck of cards, In re Smith, 815 F.3d 816, 819, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016); restricting public access to media by requiring a consumer to view an advertisement, Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 716-17, 112 USPQ2d 1750, 1755-56 (Fed. Cir. 2014); identifying undeliverable mail items, decoding data on those mail items, and creating output data, Return Mail, Inc. v. U.S. Postal Service, -- F.3d --, -- USPQ2d --, slip op. at 32 (Fed. Cir. August 28, 2017); presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; determining an estimated outcome and setting a price, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93; and arranging a hierarchy of groups, sorting information, eliminating less restrictive pricing information and determining the price, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1331, 115 USPQ2d 1681, 1699 (Fed. Cir. 2015) (MPEP 2106.05(d))
Here, the steps are receiving or transmitting data over a network; storing and retrieving information and electronically scanning or extracting data – all of which have been recognized by the courts as well-understood, routine and conventional functions.
The claims are directed to an abstract idea with additional generic computer elements that do not add meaningful limitations to the abstract idea because they require no more than a generic computer to perform generic computer functions that are well-understood, routine, and conventional activities previously known in the industry.
For the next step of the analysis, it must be determined whether the limitations present in the claims represent a patent-eligible application of the abstract idea. A claim directed to a judicial exception must be analyzed to determine whether the elements of the claim, considered both individually and as an ordered combination are sufficient to ensure that the claim as a whole amounts to significantly more than the exception itself.
For the role of a computer in a computer implemented invention to be deemed meaningful in the context of this analysis, it must involve more than performance of “well-understood, routine, [and] conventional activities previously known to the industry.” Further, “the mere recitation of a generic computer cannot transform a patent ineligible abstract idea into a patent-eligible invention.”
Applicant’s specification discloses the following:
“In some embodiments, a communication device associated with a back-end application computer server exchanges information with remote devices in connection with an interactive graphical user interface. The information may be exchanged, for example, via public and/or proprietary communication networks.” (See Applicant Specification paragraph 6)
“FIG. 1 is a high-level block diagram of a system 100 according to some embodiments of the present invention. In particular, the system 100 includes a back-end application computer 150 server that may access information in a potential risk relationship data store 110 (e.g., storing a set of electronic records representing risk associations, each record including, for example, one or more risk relationship identifiers, attribute variables, resource values, etc.) The back-end application computer 150 may also retrieve information from other data stores or sources, such as an existing risk relationship data store 120, in connection with an access and update engine 155 to view, analyze, and/or update the electronic records. The back-end application computer server 150 may also exchange information with a first remote user device 160 and a second remote user device 162 (e.g., via a firewall 165) According to some embodiments, an interactive graphical user interface platform of the back-end application computer server 150 (and, in some cases, third-party data) may facilitate forecasts, decisions, predictions, and/or the display of results via one or more remote administrator computers (e.g, to gather additional information about a potential or existing association) and/or the remote user devices 160, 162. For example, the first remote user device 160 may transmit annotated and/or tagged information to the back-end application computer 150. Based on the updated information, the back-end application computer server 150 may adjust data in the potential risk relationship data store 110 and the change may be viewable via the second remote user device 162. Note that the back-end application computer server 150 and/or any of the other devices and methods described herein might be associated with a third party, such as a vendor that performs a service for an enterprise.” (See Applicant Specification paragraph 23)
“The back-end application computer server 150 and/or the other elements of the system 100 might be, for example, associated with a Personal Computer (“PC”), laptop computer, smartphone, an enterprise server, a server farm, and/or a database or similar storage devices. According to some embodiments, an “automated” back-end application computer server 150 (and/or other elements of the system 100) may facilitate the access and/or update of electronic records in the potential risk relationship data store 110. As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.” (See Applicant Specification paragraph 24)
“As used herein, devices, including those associated with the back-end application computer server 150 and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.” (See Applicant Specification paragraph 25)
“The back-end application computer server 150 may store information into and/or retrieve information from the potential risk relationship data store 110 and/or existing risk relationship data store 120. The data stores 110, 120 may be locally stored or reside remote from the back-end application computer server 150. As will be described further below, the potential risk relationship data store 110 may be used by the back-end application computer server 150 in connection with an interactive user interface to access and update electronic records. Although a single back-end application computer server 150 is shown in FIG. 1, any number of such devices may be included. Moreover, various devices described herein might be combined according to embodiments of the present invention. For example, in some embodiments, the back-end application computer server 150 and an enterprise resource management server might be co-located and/or may comprise a single apparatus.” (See Applicant Specification paragraph 26)
“Note that the system 100 of FIG. 1 is provided only as an example, and embodiments may be associated with additional elements or components. According to some embodiments, the elements of the system 100 automatically transmit information associated with an interactive user interface display over a distributed communication network. FIG. 2 illustrates a method 200 that might be performed by some or all of the elements of the system 100 described with respect to FIG. 1, or any other system, according to some embodiments of the present invention. The flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software, or any combination of these approaches. For example, a computer-readable storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.” (See Applicant Specification paragraph 27)
“The embodiments described herein may be implemented using any number of different hardware configurations. For example, FIG. 12 illustrates an apparatus 1200 that may be, for example, associated with the systems 100, 1100 described with respect to FIGS. 1 and 11, respectively. The apparatus 1200 comprises a processor 1210, such as one or more commercially available Central Processing Units (“CPUs”) in the form of one-chip microprocessors, coupled to a communication device 1220 configured to communicate via a communication network (not shown in FIG. 12). The communication device 1220 may be used to communicate, for example, with one or more remote administrator computers or communication devices (e.g., PCs and smartphones). Note that communications exchanged via the communication device 1220 may utilize security features, such as those between a public internet user and an internal network of the insurance enterprise. The security features might be associated with, for example, web servers, firewalls, and/or PCI infrastructure. The apparatus 1200 further includes an input device 1240 (e.g., a mouse and/or keyboard to enter information about potential customers, etc.) and an output device 1250 (e.g., to output reports regarding insurance appetite, likely future sales results, etc.). (See Applicant Specification paragraph 43)
“The processor 1210 also communicates with a storage device 1230. The storage device 1230 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 1230 stores a program 1215 and/or a risk evaluation tool or application for controlling the processor 1210. The processor 1210 performs instructions of the program 1215, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1210 may access information about potential risk relationships data store and existing risk relationships. The processor 1210 may then transmit, to a first user device, a grid display of information about a subset of the electronic records in the potential risk relationship data store. Moreover, information about electronic records not in the subset is blocked by the processor 1210 from being transmitted to the first user device. The processor 1210 may then receive, from the first remote user device, an annotation associated with a selected entity and store the received annotation such that it is accessible via a second user device.” (See Applicant Specification paragraph 44)
“The program 1215 may be stored in a compressed, uncompiled and/or encrypted format. The program 1215 may furthermore include other program elements, such as an operating system, database management system, and/or device drivers used by the processor 1210 to interface with peripheral devices.” (See Applicant Specification paragraph 45)
“Referring to FIG. 13, a table is shown that represents the potential risk relationship database 1300 that may be stored at the apparatus 1300 according to some embodiments. The table may include, for example, entries associated with insurance policies might be sold by an enterprise in the future. The table may also define fields 1302, 1304, 1306, 1308, 1310 for each of the entries. The fields 1302, 1304, 1306, 1308, 1310 may, according to some embodiments, specify: a customer identifier 1302, a customer name 1304, a date and time 1306, an annotation 1308, and an estimated premium value 1310. The potential risk relationship database 1300 may be created and updated, for example, based on information electrically received from various computer systems, including those associated with an insurance enterprise.” (See Applicant Specification paragraph 48)
Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system.
Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. The collective functions appear to be implemented using conventional computer systemization.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Upon reconsideration of the indicia noted under Step 2A in concert with the Step 2B considerations, the additional claim element(s) amounts to no more than mere instructions to apply the exception using generic computer components. The same analysis applies in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The claim does not provide an inventive concept significantly more than the abstract idea.
Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The independent claims 1, 15 and 19 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent Claims 2-14, 16-18 and 20-22 further define the abstract idea that is presented in the respective independent Claims 1, 15 and 19 and are further grouped as certain methods of organizing human activity and are abstract for the same reasons and basis as presented above. No additional hardware components other than those found in the respective independent claims is recited, thus it is presumed that the claim is further utilizing the same generic systemization as presented above. The dependent claims do not include any additional elements that integrate the abstract idea into a practical application of the exception or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination.
Therefore, the dependent claims are also directed to an abstract idea.
Claims 19-22 are rejected under 35 U.S.C. §101 because, in order to comply with §101, a computer program product claim must recite that the computer program product comprises a non-transitory computer readable medium having program instructions (or code) embodied thereon and said instructions are configured to control a computer to perform specific functional steps. The claim must then recite the specific functional steps performed by execution of the instructions contained on the computer-readable medium by the computer, rather than reciting the code or software itself (i.e. software per se is not patentable).
The preamble for a computer program product has to state that (1) the product is stored on a non-transitory computer-readable medium (which is not present), (2) the product can be executed on a computer (which is not present) and (3) when executed the product causes the computer to perform a method (which is present) where the further claim limitations are written as method steps. It is the actual the method being performed by the computer which is patentable, rather than the software itself.
The current preamble recites a “non-tangible, computer-readable medium storing instructions…” There is no recitation of non-transitory in the claim and the recitation of non-tangible further implies that the computer-readable medium is not instantiated on a physical medium. Dependent Claims 20-22 are further rejected as based upon a rejected base claim. Appropriate correction is required.
Thus, Claims 1-22 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
8. Claim(s) 1-22 are rejected under 35 U.S.C. 103 as being unpatentable over Faherty et al. (US PG Pub. 2018/0165767) (“Faherty”) in view of Rakshe et al. (US PG Pub. 2018/0293660) (“Rakshe”)
Regarding Claim 1, Faherty discloses the following:
A system to access and update electronic record information via a back-end application computer server of an enterprise, comprising: (See Faherty paragraphs 27, 31, Fig. 2)
(a) a potential risk relationship data store containing electronic records that represent a plurality of potential risk relationships with the enterprise [assignment computer store/assignment and relationship computer store] and, for each potential risk relationship, an electronic record identifier [relationship identifiers] and a set of entity attribute values [relationship characteristic values] including an entity identifier; (See Faherty Abstract, paragraphs 3-4, 30-34, 38, 60 and Cl. 1-2, 15, Fig. 2)
(b) an existing risk relationship data store containing electronic records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise; (See Faherty Abstract and paragraphs 3-4, 30-34, 38, 41 and Cl. 1, 3, 15, Fig. 2)
(c) the back-end application computer server, coupled to the potential risk relationship data store, including: (See Faherty paragraphs 27, 31, 58-59, Cl. 1)
a computer processor, and (See Faherty paragraphs 42, 58-59)
a computer memory coupled to the computer processor and storing instructions that, when executed by the computer processor, cause the back-end application computer server to: (See Faherty paragraphs 32, 42, 58-62 and Fig. 1-2)
determine an authorization status to access one or more suppressible electronic records of the electronic records; (See Faherty paragraphs 27, 30-34, 36 – hierarchy in the risk relationship management platform, may store and/or retrieve information based on internal assignment manager)
identify one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status; (See Faherty paragraphs 30-36 – the assignment computer store may store electronic records associated with a hierarchy where each relationship handler is linked to a number of different risk relationship)
generate a user interface display including a link to access a subset of the one or more suppressible electronic records, the subset excluding the suppressed one or more electronic records; (See Faherty paras 30-38, 45-49, 59 – interactive user interface display facilitates a communication link)
receive selection, via touch screen or computer mouse pointer, of the link on the user interface display and in response to the received selection, access information in the potential risk relationship data store and the existing risk relationship data store; (See Faherty paras 30-38, 45-49, 56, 59)
generate a first grid display including the subset of electronic records, avoiding transmission of data about all risk relationships; (See Faherty paras 46-49, 56, 59, Figs. 5-6, 9, 16)
transmit, to a first remote user device of a first user associated with the enterprise, a grid display of information about the subset of the electronic records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about electronic records not in the subset is blocked from being transmitted to the first remote user device to avoid misappropriation and misuse of the blocked data; (See Faherty paragraphs 25-27, 30-33, 35, 41, 44, 48, 50, 59-61, 63-65, 73, Cl. 1, 11, 19, Fig. 2, Fig. 19 – information may be processed, managed, and/or assigned via a risk relationship management platform and results may then be analyzed accurately and used to initiate workflows and/or establish communication links, thus improving overall performance associated with message storage requirements and/or bandwidth considerations – reducing the number of messages that need to be transmitted via a network or communication links; internal assignment managers, remote assignment management terminals 160 [first remote user device of a first user associated with the enterprise];risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler may be assigned; whether the client is a VIP [already existing client], previous claims advisor; previous disposition, etc.); the assignment computer store might store electronic records associated with a hierarchy wherein an internal assignment manager might be linked to a number of different internal relationship handlers/claims advisor [second user] – manager is only given an assigned set [subset – by same manager identifier] and then might assign or reassign to a relationship handler terminal); table [grid] discloses entity information on one axis and existing relationship type on a second axis). In an embodiment, each insurance policy is linked to a single insurance claims advisor [only electronic records assigned to a particular manager/claims advisor are accessible – records not in the subset are blocked]
receive, from the first remote user device, an annotation associated with a selected entity; and (See Faherty paragraphs 30-31, 36, 45, 55, 61, 64 – comments, manager may enter a description and save the information related to an opportunity; the manager may assign or reassign the risk relationship and the information in the computer store may be updated [assignment is updated, relationship handler/claims advisor assigned = annotation]
store the received annotation such that the annotation is accessible via a second remote user device of a second user associated with the enterprise; and (See Faherty paragraph 27, 30-33, 45, 48-49, 55, 65 – the information in the computer store may be updated and information about the newly assigned risk relationship may be received by a relationship handler terminal/claims advisor [second remote user device] (associated with internal relationship handlers [second user]; also manager can enter a comment and save the information in the display)
(d) a communication port coupled to the back-end application computer server to facilitate a transmission of data with the first and second remote user devices to support interactive user interface displays via a distributed communication network. (See Faherty Cl. 1 and 19, Fig. 2, paragraphs 4, 37, 58)
Faherty discloses his invention as to information that may be processed, managed, and/or assigned via a risk relationship management platform and the results may then be analyzed accurately and used to automatically initiate workflows and/or establish communication links. (See Faherty paragraph 25) In some cases, an enterprise might manage a substantial number of risk relationships with various entities. (See Faherty paragraph 26) For example, an enterprise might have a number of internal assignment managers and relationship handlers that interact with entities. (See Faherty paragraph 26) The handlers might, for example, help facilitate potential new risk relationships and/or existing risk relationship for the enterprise (e.g., a handler might interact with an entity and/or respond to events that arise in connection [with] that entity. (See Faherty paragraph 26) Different risk relationships might be associated with different priority values with respect to the enterprise (that is, some risk relationships and/or entities might be considered a higher priority as compared to others). (See Faherty paragraph 26)
FIG. 1 is a high level block diagram of a system 100 according to some embodiments of the present invention. (See Faherty paragraph 27 and Fig. 1) In particular, the system includes a risk relationship management platform that may access information in an assignment computer store 110 (e.g., storing information about internal assignment managers 162, internal relationship handlers 172, risk relationships, etc.) (See Faherty paragraph 27) The risk relationship management platform 150 may also exchange information with remote assignment management terminals 160 and/or relationship handler terminals 170. (See Faherty paragraph 27 – transmitting information with remote assignments) According to some embodiments, a back-end application computer server of the risk relationship management platform 150 may facilitate management, assignment and viewing of information via the one or more terminals 160, 170. (See Faherty paragraph 27)
The risk relationship management platform 150 may store information into and/or retrieve information from the assignment computer store 110. (See Faherty paragraph 30) The assignment computer store might, for example, store electronic records associated with a hierarchy wherein an internal assignment manager might be linked to a number of different internal relationship handlers which may in turn be linked to a number of different risk relationships. (See Faherty paragraph 30) According to embodiments, the system may automatically assign and manage risk relationships for an enterprise. (See Faherty paragraph 31) For example, at (1) a manager at a manager terminal might access the risk management platform to determine if there are any new unassigned risk relationships or currently assigned risk relationships that might be reassigned) (See Faherty paragraph 31) The back-end application computer server may access the assignment computer store 110 [risk relationship data store] to help determine this information and the manager might then assign (or re-assign that risk relationship and the information in the computer store may be updated. (See Faherty paragraph 31) Information about the newly assigned risk relationship may be received by a relationship handler terminal and he or she might take actions as appropriate, such as establishing a communication link with an internal entity terminal. (See Faherty paragraph 31) Information about the various interactions associated with the risk relationship (e.g., a time, date of the interaction, a description of the interaction, etc.) may then be stored into assignment computer store 110. (See Faherty paragraph 31)
Faherty notes that the system of FIG. 1 is provided as an example and embodiments may be associated with additional elements or components where FIG. 2 illustrates a method that might be performed by some or all of the elements of the system described with respect to FIG. 1 or any other system and the embodiments of the invention may be practiced in any order. (See Faherty paragraph 32)
The system may manage an assignment computer store [risk relationship data store] containing a set of internal assignment manager identifiers, with each internal assignment manager identifier being linked to a plurality of internal relationship handler identifiers. (See Faherty paragraph 33) According to some embodiments, each internal relationship handler is further linked to a plurality of relationship identifiers between the enterprise and entities. (See Faherty paragraph 33) According to some embodiments, each internal relationship handler is further linked to a plurality of relationship identifiers between the enterprise and entities. (See Faherty paragraph 33) According to some embodiments, at least one risk relationship represents a potential future risk relationship between the enterprise and an entity and in some embodiments, at least one risk relationship represents an existing, ongoing risk relationship between the enterprise and an entity. (See Faherty paragraph 33 – risk relationships may be potential future risk relationships between the entity and enterprise and existing risk relationship between the enterprise and the entity – assignment computer store can contain electronic records regarding both potential and existing risk relationships)
The system may manage a risk relationship computer store containing a set of electronic data records each representing a risk relationship between the enterprise and an entity. (See Faherty paragraph 34 – risk relationship data store containing electronic records) According to some embodiments, each electronic data record including a relationship identifier and a set of relationship characteristic values with at least one characteristic value being a priority value for that risk relationship. (See Faherty paragraph 34 – entity attribute values)
An automated risk relationship management platform may retrieve a selected electronic data record from the risk relationship computer store. (See Faherty paragraph 35) The automated risk relationship management platform computer may determine that the priority value of the risk relationship represented by the selected electronic data record is both above a pre-determined minimum threshold priority value and below a pre-determined maximum threshold priority value. (See Faherty paragraph 35) That is, a risk relationship with a priority value above the pre-determined maximum threshold priority value might be handled by a different process (e.g., a single internal relationship handler might be assigned in such a situation). (See Faherty paragraph 35) Similarly, a risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler might be assigned in such a situation.) (See Faherty paragraph 35)
Responsive to a determination of a priority value of the risk relationship, the system may arrange for the selected relationship identifier to be assigned to one of the internal assignment manager identifiers and linked relationship handler identifier in the assignment computer store. (See Faherty paragraph 36) The system may generate a set of tasks for the risk relationship associated with the selected electronic data record. (See Faherty paragraph 36)
Electronic messages may be exchanged via a distributed communication network to present an interactive user interface at a remote relationship handler terminal associated with the assigned relationship handler identifier. (See Faherty paragraph 37) According to some embodiments, the interactive user interface display at the remote relationship handler terminal automatically facilitates a communication link with a remote external entity terminal. (See Faherty paragraph 37) For example, the automatically established communication link might be associated with a telephone call, a web chat, a video link, an electronic mail message and/or a postal mail message generated via a distribution center. (See Faherty paragraph 37)
Embodiments of the present invention might be associated with a number of different types of “risk relationships”. (See Faherty paragraph 38) As used herein, the phrase “risk relationship” might refer to, for example, an existing insurance policy between an insurer and an insured entity (e.g., whose policy is up for renewal) or potential insurance policy (e.g., associated with an entity who is considering purchasing insurance from the insurer). (See Faherty paragraph 38 – potential and existing risk relationships with an entity) In FIG. 3, a risk relationship management system for an insurer which as before is disclosed that the system includes a risk relationship management platform that may access information in an assignment and relationship computer store. (See Faherty paragraph 38) For example, the assignment and relationship computer store might store [information] about insurance enterprise claims advisor managers, insurance claim advisors, and insurance policies. (See Faherty paragraph 38) According to this embodiment, the assignment and relationship computer store further stores a set of electronic data records each representing a risk relationship between the enterprise and an entity (that is an insurance policy between the insurer and an insured) and moreover, each electronic data record includes a relationship identifier (that is an insurance policy identifier) and a set of relationship characteristic values with at least one characteristic value being a premium value for that insurance policy. (See Faherty paragraph 38 – the electronic data records are each representing a risk relationship between the enterprise and the entity – and as noted above, risk relationships include both existing and potential risk relationships, thus the assignment computer store stores records for both types of risk relationships)
According to some embodiments, the risk relationship platform might assign (or re-assign) insurance policies insurance policies to insurance claims advisors based at least in part on a type of insurance (e.g., a workers’ compensation insurance policy as compared to a business insurance policy), information from an insurance underwriter, a type of industry associated with the insured, an opportunity age, an opportunity likelihood of success (e.g., a high or low likelihood of eventually being converted into a sale), an entity priority (e.g., whether an entity is considered a Very Important Part (“VIP”) client and/or an insurer office. (See Faherty paragraph 44)
According to some embodiments, an interactive graphical user interface provided by the risk relationship management platform includes a claims manager workflow and FIGS. 4 though 8 illustrate a claims management workflow according to some embodiments. (See Faherty paragraph 45) In particular, FIG. 4 illustrates a display 400 that might be provided when an opportunity record enters the claims process. (See Faherty paragraph 45) The display might include, for example, an opportunity owner, an opportunity name, an agency name, a primary contact, a market segment, a confidence level, comments, a policy effective date, a targeted premium value, a stage description, a current carrier, and/or a lead source. (See Faherty paragraph 45)
Fig. 7 illustrates a claim advisor information display 700 in accordance with some embodiments. (See Faherty paragraph 48) The display 700 might include, for example, a claims advisor, a disposition, a claims advisor primary reason lost, a renewal status, claims advisor comments 710, an insured’s contact, an insured’s phone number, an insured’s email, a date a renewal status was set to “not renewed,” a date state was set to “quoted,” a date stage was set to “won/lost,” a date the claims advisor was assigned, and/or a name of a previous claims advisor. (See Faherty Cl. 11, 19 and paragraph 48 – entity information; each claims advisor identifier being linked to a plurality of policy identifiers between the insurer and insureds)
It would have been obvious to one having ordinary skill in the art at the time the invention was made to have modified Faherty by separating one composite claim element contained in Faherty (i.e. the assignment computer store/assignment and relationship computer store) into component claim elements (e.g. a potential risk relationship data store and an existing risk relationship data store) wherein each component claim element would serve the same separate function performed when it was a component in the original composite claim element. In the separation each component claim element, would merely have performed the same function as it did previously, and one of ordinary skill in the art at the time the invention was made would have recognized that the results of the separation were predictable. See MPEP §2144.04 (V)(C)
While Faherty discloses that each electronic data record includes a relationship identifier 392 (that is, an insurance policy identifier) and a set of relationship characteristic values which implies that the entity has been identified by virtue of the insurance policy identifier and information regarding the insured, it is not explicitly taught by Faherty.
Rakshe discloses his invention as to a back-end application computer server that may receive a request along with a descriptive term. (See Rakshe Abstract) The user may select one of the potential descriptions, and a user identifier may be associated with the request. (See Rakshe Abstract and paragraph 4 – user identifier [entity identifier]) A series of dynamic information exchanges may then help assign a category to the user identifier. (See Rakshe Abstract) A partial set of initial request details may be received from a third-party device and the user may adjust and/or add details to create a complete set. (See Rakshe Abstract) A potential value may then be calculated for the request. (See Rakshe Abstract and paragraph 4) An indication of the potential value may be transmitted to the user, and information about the user identifier may be transmitted to a user response terminal to facilitate communication between the user response terminal and the user. (See Rakshe Abstract and paragraph 4)
The present invention provides significant technical improvements to facilitate electronic messaging and dynamic data processing. (See Rakshe paragraph 28) The invention may directly exchange information with an enterprise in an automated and efficient manner, thus improving the overall performance of the system associated with an enterprise (e.g., by reducing the amount of communication required between parties and reducing errors). (See Rakshe paragraph 28)
A user may be interested in establishing a risk relationship with an enterprise. (See Rakshe paragraph 29) For example, a business might want to purchase property and liability insurance, workers’ compensation insurance, etc. from an insurer. (See Rakshe paragraph 29) When deciding whether or not to enter into such a relationship, the business will typically provide information describing the business to the insurer and receive an insurance quote, including an estimated insurance premium value, from the insurer. (See Rakshe paragraph 29 – insurance quote including estimated insurance premium value)
According to some embodiments, the system 100 may automatically facilitate an exchange of information via interactive user interface displays. (See Rakshe paragraph 34) For example, at (1) a front-end user device 160, associated with a user, might transmit a potential risk relationship request to the back-end application computer server 150 (e.g., via the communication interface 155). (See Rakshe paragraph 34) The back-end application computer server 150 may then use information from the description data store at (2) to exchange information with the remote front end user device 160 at (3) to determine an appropriate description of the business (e.g., an appropriate industry code). (See Rakshe paragraph 34) The back-end application computer server 150 may also use the information from the categorization data store at (4) to exchange information with the remote front end user device 160 at (5) to assign an appropriate category to the user (e.g., via series of dynamic information exchanges). (See Rakshe paragraph 34)
The back-end application computer server 150 may then receive a partial set of initial request details from a third party device 130 at (6). (See Rakshe paragraph 35) This information might, for example, be used to “pre-populate” information fields in an interactive user interface display. (See Rakshe paragraph 35) The user may then adjust and/or complete the request details and a potential value (e.g., an estimated insurance premium quote) may be automatically calculated and transmitted to the front-end user device 160 at (7). (See Rakshe paragraph 35) According to some embodiments, the back-end application computer server 150 may also transmit information to a user response terminal 140 at (8). (See Rakshe paragraph 35) For example, a user’s telephone number might be transmitted to the user response terminal 140 to facilitate a telephone call to the user at (9) to discuss the insurance quote in more detail. (See Rakshe paragraph 35 – phone number of the user is an entity identifier)
Figure 2 illustrates a method that might be performed by some or all of the elements of the system 100 described with respect to Figure 1, or any other system according to some embodiments of the invention. (See Rakshe paragraph 36) At 210, a back-end application computer server may receive, directly from a remote front-end user device associated with the user, an initial request. (See Rakshe paragraph 37)
At 220, a user identifier is associated with the request. (See Rakshe paragraph 43) The user identifier might be associated with, for example, a user name, an email address, an Internet protocol address, a telephone number, and/or a postal address. (See Rakshe paragraph 43 – entity identifiers) According to some embodiments, the user identifier may be used to communicate with a user and/or to save a partially completed request for the user. (See Rakshe paragraph 43) For example, the user’s telephone address, email address, etc. might be supplied so that a sales representative can contact the business to discuss the estimated insurance premium in more detail (and potentially complete the sale of the insurance policy). (See Rakshe paragraph 48)
Referring to Fig. 16, a table is shown that represents the request database that may be stored at the back-end application computer server 1500 according to some embodiments. (See Rakshe paragraph 65 and Fig. 16) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65 and Fig. 16) The table may also define fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 for each of these entries. The fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 may, according to some embodiments, specify: a potential relationship request identifier 1602, a user identifier 1604, potential pre-determined descriptions 1606, a selected description 1608, an assigned category 1610, a calculated potential value 1612, and a user response terminal identifier 1614. (See Rakshe paragraph 65) The request database 1600 may be created and updated, for example, based on information electronically received from remote front-end user devices. (See Rakshe paragraph 65)
The potential relationship request identifier 1602 may be, for example, a unique alphanumeric code identifying a user who is asking for a personalized insurance premium quote (e.g., “RR_101”). (See Rakshe paragraph 66 – an entity [user] identifier used by the insurer) The user identifier 1604 might be, for example, a user name, email address, telephone phone number, etc. that can be used to identify the request. (See Rakshe paragraph 66 – entity [user] identifiers)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals that implies (by virtue of disclosing an insurance policy identifier) that an entity is identified as disclosed by Faherty with the specific disclosure of a user identifier [entity identifier] as taught by Rakshe in order to further facilitate processing of risk relationships for an enterprise.
Regarding Claim 15, Faherty discloses the following:
A computerized method to access and update electronic record information via a back-end application computer server of an enterprise, comprising: (See Faherty paragraphs 27, 31, Fig. 2)
accessing, by a back-end application computer server, information in a potential risk relationship data store containing electronic records that represent a plurality of potential risk relationships with the enterprise and for each potential risk relationship, an electronic record identifier and a set of entity attribute values including an entity identifier, wherein the electronic records include one or more suppressible electronic records; (See Faherty Abstract, paragraphs 3-4, 27, 30-34, 38, 42, 58-60, and Cl. 1-2, 15, Fig. 1-2)
determining an authorization status to access one or more suppressible electronic records; (See Faherty paragraphs 27, 30-34, 36 – hierarchy in the risk relationship management platform, may store and/or retrieve information based on internal assignment manager)
identifying one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status; (See Faherty paragraphs 30-36 – the assignment computer store may store electronic records associated with a hierarchy where each relationship handler is linked to a number of different risk relationship)
generating a user interface display including a link to access a subset of the one or more suppressible electronic records, the subset excluding the suppressed one or more electronic records; (See Faherty paras 30-38, 45-49, 59 – interactive user interface display facilitates a communication link)
receiving selection of the link on the user interface display and, in response to the received selection, accessing, by the back-end application computer server, information in an existing risk relationship data store containing electronic records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise; (See Faherty paras 30-38, 45-49, 56, 59)
transmitting, to a first remote user device of a first user associated with the enterprise, a grid display of information about the subset of the electronic records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about electronic records not in the subset is blocked from being transmitted to the first remote user device to avoid misappropriation and misuse of the blocked data; (See Faherty paragraphs 25-27, 30-33, 35, 41, 44, 48, 50, 59-61, 63-65, 73, Cl. 1, 11, 19, Fig. 2, Fig. 19 – information may be processed, managed, and/or assigned via a risk relationship management platform and results may then be analyzed accurately and used to initiate workflows and/or establish communication links, thus improving overall performance associated with message storage requirements and/or bandwidth considerations – reducing the number of messages that need to be transmitted via a network or communication links; internal assignment managers, remote assignment management terminals 160 [first remote user device of a first user associated with the enterprise];risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler may be assigned; whether the client is a VIP [already existing client], previous claims advisor; previous disposition, etc.); the assignment computer store might store electronic records associated with a hierarchy wherein an internal assignment manager might be linked to a number of different internal relationship handlers/claims advisor [second user] – manager is only given an assigned set [subset – by same manager identifier] and then might assign or reassign to a relationship handler terminal); table [grid] discloses entity information on one axis and existing relationship type on a second axis). In an embodiment, each insurance policy is linked to a single insurance claims advisor [only electronic records assigned to a particular manager/claims advisor are accessible – records not in the subset are blocked]
receiving, from the first remote user device, an annotation associated with a selected entity; and (See Faherty paragraphs 30-31, 36, 45, 55, 61, 64 – comments, manager may enter a description and save the information related to an opportunity; the manager may assign or reassign the risk relationship and the information in the computer store may be updated [assignment is updated, relationship handler/claims advisor assigned = annotation]
storing the received annotation such that the annotation is accessible via a second remote user device of a second user associated with the enterprise. (See Faherty paragraph 27, 30-33, 45, 48-49, 55, 65 – the information in the computer store may be updated and information about the newly assigned risk relationship may be received by a relationship handler terminal/claims advisor [second remote user device] (associated with internal relationship handlers [second user]; also manager can enter a comment and save the information in the display)
Faherty discloses his invention as to information that may be processed, managed, and/or assigned via a risk relationship management platform and the results may then be analyzed accurately and used to automatically initiate workflows and/or establish communication links. (See Faherty paragraph 25) In some cases, an enterprise might manage a substantial number of risk relationships with various entities. (See Faherty paragraph 26) For example, an enterprise might have a number of internal assignment managers and relationship handlers that interact with entities. (See Faherty paragraph 26) The handlers might, for example, help facilitate potential new risk relationships and/or existing risk relationship for the enterprise (e.g., a handler might interact with an entity and/or respond to events that arise in connection [with] that entity. (See Faherty paragraph 26) Different risk relationships might be associated with different priority values with respect to the enterprise (that is, some risk relationships and/or entities might be considered a higher priority as compared to others). (See Faherty paragraph 26)
FIG. 1 is a high level block diagram of a system 100 according to some embodiments of the present invention. (See Faherty paragraph 27 and Fig. 1) In particular, the system includes a risk relationship management platform that may access information in an assignment computer store 110 (e.g., storing information about internal assignment managers 162, internal relationship handlers 172, risk relationships, etc.) (See Faherty paragraph 27) The risk relationship management platform 150 may also exchange information with remote assignment management terminals 160 and/or relationship handler terminals 170. (See Faherty paragraph 27 – transmitting information with remote assignments) According to some embodiments, a back-end application computer server of the risk relationship management platform 150 may facilitate management, assignment and viewing of information via the one or more terminals 160, 170. (See Faherty paragraph 27)
The risk relationship management platform 150 may store information into and/or retrieve information from the assignment computer store 110. (See Faherty paragraph 30) The assignment computer store might, for example, store electronic records associated with a hierarchy wherein an internal assignment manager might be linked to a number of different internal relationship handlers which may in turn be linked to a number of different risk relationships. (See Faherty paragraph 30) According to embodiments, the system may automatically assign and manage risk relationships for an enterprise. (See Faherty paragraph 31) For example, at (1) a manager at a manager terminal might access the risk management platform to determine if there are any new unassigned risk relationships or currently assigned risk relationships that might be reassigned) (See Faherty paragraph 31) The back-end application computer server may access the assignment computer store 110 [risk relationship data store] to help determine this information and the manager might then assign (or re-assign that risk relationship and the information in the computer store may be updated. (See Faherty paragraph 31) Information about the newly assigned risk relationship may be received by a relationship handler terminal and he or she might take actions as appropriate, such as establishing a communication link with an internal entity terminal. (See Faherty paragraph 31) Information about the various interactions associated with the risk relationship (e.g., a time, date of the interaction, a description of the interaction, etc.) may then be stored into assignment computer store 110. (See Faherty paragraph 31)
Faherty notes that the system of FIG. 1 is provided as an example and embodiments may be associated with additional elements or components where FIG. 2 illustrates a method that might be performed by some or all of the elements of the system described with respect to FIG. 1 or any other system and the embodiments of the invention may be practiced in any order. (See Faherty paragraph 32)
The system may manage an assignment computer store [risk relationship data store] containing a set of internal assignment manager identifiers, with each internal assignment manager identifier being linked to a plurality of internal relationship handler identifiers. (See Faherty paragraph 33) According to some embodiments, each internal relationship handler is further linked to a plurality of relationship identifiers between the enterprise and entities. (See Faherty paragraph 33) According to some embodiments, each internal relationship handler is further linked to a plurality of relationship identifiers between the enterprise and entities. (See Faherty paragraph 33) According to some embodiments, at least one risk relationship represents a potential future risk relationship between the enterprise and an entity and in some embodiments, at least one risk relationship represents an existing, ongoing risk relationship between the enterprise and an entity. (See Faherty paragraph 33 – risk relationships may be potential future risk relationships between the entity and enterprise and existing risk relationship between the enterprise and the entity – assignment computer store can contain electronic records regarding both potential and existing risk relationships)
The system may manage a risk relationship computer store containing a set of electronic data records each representing a risk relationship between the enterprise and an entity. (See Faherty paragraph 34 – risk relationship data store containing electronic records) According to some embodiments, each electronic data record including a relationship identifier and a set of relationship characteristic values with at least one characteristic value being a priority value for that risk relationship. (See Faherty paragraph 34 – entity attribute values)
An automated risk relationship management platform may retrieve a selected electronic data record from the risk relationship computer store. (See Faherty paragraph 35) The automated risk relationship management platform computer may determine that the priority value of the risk relationship represented by the selected electronic data record is both above a pre-determined minimum threshold priority value and below a pre-determined maximum threshold priority value. (See Faherty paragraph 35) That is, a risk relationship with a priority value above the pre-determined maximum threshold priority value might be handled by a different process (e.g., a single internal relationship handler might be assigned in such a situation). (See Faherty paragraph 35) Similarly, a risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler might be assigned in such a situation.) (See Faherty paragraph 35)
Responsive to a determination of a priority value of the risk relationship, the system may arrange for the selected relationship identifier to be assigned to one of the internal assignment manager identifiers and linked relationship handler identifier in the assignment computer store. (See Faherty paragraph 36) The system may generate a set of tasks for the risk relationship associated with the selected electronic data record. (See Faherty paragraph 36)
Electronic messages may be exchanged via a distributed communication network to present an interactive user interface at a remote relationship handler terminal associated with the assigned relationship handler identifier. (See Faherty paragraph 37) According to some embodiments, the interactive user interface display at the remote relationship handler terminal automatically facilitates a communication link with a remote external entity terminal. (See Faherty paragraph 37) For example, the automatically established communication link might be associated with a telephone call, a web chat, a video link, an electronic mail message and/or a postal mail message generated via a distribution center. (See Faherty paragraph 37)
Embodiments of the present invention might be associated with a number of different types of “risk relationships”. (See Faherty paragraph 38) As used herein, the phrase “risk relationship” might refer to, for example, an existing insurance policy between an insurer and an insured entity (e.g., whose policy is up for renewal) or potential insurance policy (e.g., associated with an entity who is considering purchasing insurance from the insurer). (See Faherty paragraph 38 – potential and existing risk relationships with an entity) In FIG. 3, a risk relationship management system for an insurer which as before is disclosed that the system includes a risk relationship management platform that may access information in an assignment and relationship computer store. (See Faherty paragraph 38) For example, the assignment and relationship computer store might store [information] about insurance enterprise claims advisor managers, insurance claim advisors, and insurance policies. (See Faherty paragraph 38) According to this embodiment, the assignment and relationship computer store further stores a set of electronic data records each representing a risk relationship between the enterprise and an entity (that is an insurance policy between the insurer and an insured) and moreover, each electronic data record includes a relationship identifier (that is an insurance policy identifier) and a set of relationship characteristic values with at least one characteristic value being a premium value for that insurance policy. (See Faherty paragraph 38 – the electronic data records are each representing a risk relationship between the enterprise and the entity – and as noted above, risk relationships include both existing and potential risk relationships, thus the assignment computer store stores records for both types of risk relationships)
According to some embodiments, the risk relationship platform might assign (or re-assign) insurance policies insurance policies to insurance claims advisors based at least in part on a type of insurance (e.g., a workers’ compensation insurance policy as compared to a business insurance policy), information from an insurance underwriter, a type of industry associated with the insured, an opportunity age, an opportunity likelihood of success (e.g., a high or low likelihood of eventually being converted into a sale), an entity priority (e.g., whether an entity is considered a Very Important Part (“VIP”) client and/or an insurer office. (See Faherty paragraph 44)
According to some embodiments, an interactive graphical user interface provided by the risk relationship management platform includes a claims manager workflow and FIGS. 4 through 8 illustrate a claims management workflow according to some embodiments. (See Faherty paragraph 45) In particular, FIG. 4 illustrates a display 400 that might be provided when an opportunity record enters the claims process. (See Faherty paragraph 45) The display might include, for example, an opportunity owner, an opportunity name, an agency name, a primary contact, a market segment, a confidence level, comments, a policy effective date, a targeted premium value, a stage description, a current carrier, and/or a lead source. (See Faherty paragraph 45)
Fig. 7 illustrates a claim advisor information display 700 in accordance with some embodiments. (See Faherty paragraph 48) The display 700 might include, for example, a claims advisor, a disposition, a claims advisor primary reason lost, a renewal status, claims advisor comments 710, an insured’s contact, an insured’s phone number, an insured’s email, a date a renewal status was set to “not renewed,” a date state was set to “quoted,” a date stage was set to “won/lost,” a date the claims advisor was assigned, and/or a name of a previous claims advisor. (See Faherty Cl. 11, 19 and paragraph 48 – entity information; each claims advisor identifier being linked to a plurality of policy identifiers between the insurer and insureds)
It would have been obvious to one having ordinary skill in the art at the time the invention was made to have modified Faherty by separating one composite claim element contained in Faherty (i.e. the assignment computer store/assignment and relationship computer store) into component claim elements (e.g. a potential risk relationship data store and an existing risk relationship data store) wherein each component claim element would serve the same separate function performed when it was a component in the original composite claim element. In the separation each component claim element, would merely have performed the same function as it did previously, and one of ordinary skill in the art at the time the invention was made would have recognized that the results of the separation were predictable. See MPEP §2144.04 (V)(C)
While Faherty discloses that each electronic data record includes a relationship identifier 392 (that is, an insurance policy identifier) and a set of relationship characteristic values which implies that the entity has been identified by virtue of the insurance policy identifier and information regarding the insured, it is not explicitly taught by Faherty.
Rakshe discloses his invention as to a back-end application computer server that may receive a request along with a descriptive term. (See Rakshe Abstract) The user may select one of the potential descriptions, and a user identifier may be associated with the request. (See Rakshe Abstract and paragraph 4 – user identifier [entity identifier]) A series of dynamic information exchanges may then help assign a category to the user identifier. (See Rakshe Abstract) A partial set of initial request details may be received from a third-party device and the user may adjust and/or add details to create a complete set. (See Rakshe Abstract) A potential value may then be calculated for the request. (See Rakshe Abstract and paragraph 4) An indication of the potential value may be transmitted to the user, and information about the user identifier may be transmitted to a user response terminal to facilitate communication between the user response terminal and the user. (See Rakshe Abstract and paragraph 4)
The present invention provides significant technical improvements to facilitate electronic messaging and dynamic data processing. (See Rakshe paragraph 28) The invention may directly exchange information with an enterprise in an automated and efficient manner, thus improving the overall performance of the system associated with an enterprise (e.g., by reducing the amount of communication required between parties and reducing errors). (See Rakshe paragraph 28)
A user may be interested in establishing a risk relationship with an enterprise. (See Rakshe paragraph 29) For example, a business might want to purchase property and liability insurance, workers’ compensation insurance, etc. from an insurer. (See Rakshe paragraph 29) When deciding whether or not to enter into such a relationship, the business will typically provide information describing the business to the insurer and receive an insurance quote, including an estimated insurance premium value, from the insurer. (See Rakshe paragraph 29 – insurance quote including estimated insurance premium value)
According to some embodiments, the system 100 may automatically facilitate an exchange of information via interactive user interface displays. (See Rakshe paragraph 34) For example, at (1) a front-end user device 160, associated with a user, might transmit a potential risk relationship request to the back-end application computer server 150 (e.g., via the communication interface 155). (See Rakshe paragraph 34) The back-end application computer server 150 may then use information from the description data store at (2) to exchange information with the remote front end user device 160 at (3) to determine an appropriate description of the business (e.g., an appropriate industry code). (See Rakshe paragraph 34) The back-end application computer server 150 may also use the information from the categorization data store at (4) to exchange information with the remote front end user device 160 at (5) to assign an appropriate category to the user (e.g., via series of dynamic information exchanges). (See Rakshe paragraph 34)
The back-end application computer server 150 may then receive a partial set of initial request details from a third party device 130 at (6). (See Rakshe paragraph 35) This information might, for example, be used to “pre-populate” information fields in an interactive user interface display. (See Rakshe paragraph 35) The user may then adjust and/or complete the request details and a potential value (e.g., an estimated insurance premium quote) may be automatically calculated and transmitted to the front-end user device 160 at (7). (See Rakshe paragraph 35) According to some embodiments, the back-end application computer server 150 may also transmit information to a user response terminal 140 at (8). (See Rakshe paragraph 35) For example, a user’s telephone number might be transmitted to the user response terminal 140 to facilitate a telephone call to the user at (9) to discuss the insurance quote in more detail. (See Rakshe paragraph 35 – phone number of the user is an entity identifier)
Figure 2 illustrates a method that might be performed by some or all of the elements of the system 100 described with respect to Figure 1, or any other system according to some embodiments of the invention. (See Rakshe paragraph 36) At 210, a back-end application computer server may receive, directly from a remote front-end user device associated with the user, an initial request. (See Rakshe paragraph 37)
At 220, a user identifier is associated with the request. (See Rakshe paragraph 43) The user identifier might be associated with, for example, a user name, an email address, an Internet protocol address, a telephone number, and/or a postal address. (See Rakshe paragraph 43 – entity identifiers) According to some embodiments, the user identifier may be used to communicate with a user and/or to save a partially completed request for the user. (See Rakshe paragraph 43) For example, the user’s telephone address, email address, etc. might be supplied so that a sales representative can contact the business to discuss the estimated insurance premium in more detail (and potentially complete the sale of the insurance policy). (See Rakshe paragraph 48)
Referring to Fig. 16, a table is shown that represents the request database that may be stored at the back-end application computer server 1500 according to some embodiments. (See Rakshe paragraph 65 and Fig. 16) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65 and Fig. 16) The table may also define fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 for each of these entries. The fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 may, according to some embodiments, specify: a potential relationship request identifier 1602, a user identifier 1604, potential pre-determined descriptions 1606, a selected description 1608, an assigned category 1610, a calculated potential value 1612, and a user response terminal identifier 1614. (See Rakshe paragraph 65) The request database 1600 may be created and updated, for example, based on information electronically received from remote front-end user devices. (See Rakshe paragraph 65)
The potential relationship request identifier 1602 may be, for example, a unique alphanumeric code identifying a user who is asking for a personalized insurance premium quote (e.g., “RR_101”). (See Rakshe paragraph 66 – an entity [user] identifier used by the insurer) The user identifier 1604 might be, for example, a user name, email address, telephone phone number, etc. that can be used to identify the request. (See Rakshe paragraph 66 – entity [user] identifiers)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals that implies (by virtue of disclosing an insurance policy identifier) that an entity is identified as disclosed by Faherty with the specific disclosure of a user identifier [entity identifier] as taught by Rakshe in order to further facilitate processing of risk relationships for an enterprise.
Regarding Claim 19, Faherty discloses the following:
A non-tangible, computer-readable medium storing instructions, that, when executed by a processor, cause the processor to perform a method to access and update electronic record information via a back-end application computer server of an enterprise, the method comprising: (See Faherty paragraphs 32, 61)
accessing, by a back-end application computer server, information in a potential risk relationship data store containing electronic records that represent a plurality of potential risk relationships with the enterprise and, for each potential risk relationship, an electronic record identifier and a set of entity attribute values including an entity identifier; (See Faherty Abstract, paragraphs 3-4, 27, 30-34, 38, 42, 58-60, and Cl. 1-2, 15, Fig. 1-2)
determining an authorization status to access one or more suppressible electronic records; (See Faherty paragraphs 27, 30-34, 36 – hierarchy in the risk relationship management platform, may store and/or retrieve information based on internal assignment manager)
identifying one or more electronic records of the one or more suppressible electronic records for suppression based on the determined authorization status; (See Faherty paragraphs 30-36 – the assignment computer store may store electronic records associated with a hierarchy where each relationship handler is linked to a number of different risk relationship)
generating a user interface display including a link to access a subset of the one or more suppressible electronic records, the subset excluding the suppressed one or more electronic records; (See Faherty paras 30-38, 45-49, 59 – interactive user interface display facilitates a communication link)
receiving selection of the link on the user interface display and, in response to the received selection, accessing, by the back-end application computer server, information in an existing risk relationship data store containing electronic records that represent a plurality of existing risk relationships, of various types, between entities and the enterprise; (See Faherty paras 30-38, 45-49, 56, 59)
transmitting, to a first remote user device of a first user associated with the enterprise, a grid display of information about a subset of the electronic records in the potential risk relationship data store arranged by entity along a first grid axis and by existing risk relationship type along a second axis, wherein information about electronic records not in the subset is blocked from being transmitted to the first remote user device to avoid misappropriation and misuse of the blocked data; (See Faherty paragraphs 25-27, 30-33, 35, 41, 44, 48, 50, 59-61, 63-65, 73, Cl. 1, 11, 19, Fig. 2, Fig. 19 – information may be processed, managed, and/or assigned via a risk relationship management platform and results may then be analyzed accurately and used to initiate workflows and/or establish communication links, thus improving overall performance associated with message storage requirements and/or bandwidth considerations – reducing the number of messages that need to be transmitted via a network or communication links; internal assignment managers, remote assignment management terminals 160 [first remote user device of a first user associated with the enterprise];risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler may be assigned; whether the client is a VIP [already existing client], previous claims advisor; previous disposition, etc.); the assignment computer store might store electronic records associated with a hierarchy wherein an internal assignment manager might be linked to a number of different internal relationship handlers/claims advisor [second user] – manager is only given an assigned set [subset – by same manager identifier] and then might assign or reassign to a relationship handler terminal); table [grid] discloses entity information on one axis and existing relationship type on a second axis). In an embodiment, each insurance policy is linked to a single insurance claims advisor [only electronic records assigned to a particular manager/claims advisor are accessible – records not in the subset are blocked]
receiving, from the first remote user device, an annotation associated with a selected entity; and (See Faherty paragraphs 30-31, 36, 45, 55, 61, 64 – comments, manager may enter a description and save the information related to an opportunity; the manager may assign or reassign the risk relationship and the information in the computer store may be updated [assignment is updated, relationship handler/claims advisor assigned = annotation]
storing the received annotation such that the annotation is accessible via a second remote user device of a second user associated with the enterprise. (See Faherty paragraph 27, 30-33, 45, 48-49, 55, 65 – the information in the computer store may be updated and information about the newly assigned risk relationship may be received by a relationship handler terminal/claims advisor [second remote user device] (associated with internal relationship handlers [second user]; also manager can enter a comment and save the information in the display)
Faherty discloses his invention as to information that may be processed, managed, and/or assigned via a risk relationship management platform and the results may then be analyzed accurately and used to automatically initiate workflows and/or establish communication links. (See Faherty paragraph 25) In some cases, an enterprise might manage a substantial number of risk relationships with various entities. (See Faherty paragraph 26) For example, an enterprise might have a number of internal assignment managers and relationship handlers that interact with entities. (See Faherty paragraph 26) The handlers might, for example, help facilitate potential new risk relationships and/or existing risk relationship for the enterprise (e.g., a handler might interact with an entity and/or respond to events that arise in connection [with] that entity. (See Faherty paragraph 26) Different risk relationships might be associated with different priority values with respect to the enterprise (that is, some risk relationships and/or entities might be considered a higher priority as compared to others). (See Faherty paragraph 26)
FIG. 1 is a high level block diagram of a system 100 according to some embodiments of the present invention. (See Faherty paragraph 27 and Fig. 1) In particular, the system includes a risk relationship management platform that may access information in an assignment computer store 110 (e.g., storing information about internal assignment managers 162, internal relationship handlers 172, risk relationships, etc.) (See Faherty paragraph 27) The risk relationship management platform 150 may also exchange information with remote assignment management terminals 160 and/or relationship handler terminals 170. (See Faherty paragraph 27 – transmitting information with remote assignments) According to some embodiments, a back-end application computer server of the risk relationship management platform 150 may facilitate management, assignment and viewing of information via the one or more terminals 160, 170. (See Faherty paragraph 27)
The risk relationship management platform 150 may store information into and/or retrieve information from the assignment computer store 110. (See Faherty paragraph 30) The assignment computer store might, for example, store electronic records associated with a hierarchy wherein an internal assignment manager might be linked to a number of different internal relationship handlers which may in turn be linked to a number of different risk relationships. (See Faherty paragraph 30) According to embodiments, the system may automatically assign and manage risk relationships for an enterprise. (See Faherty paragraph 31) For example, at (1) a manager at a manager terminal might access the risk management platform to determine if there are any new unassigned risk relationships or currently assigned risk relationships that might be reassigned) (See Faherty paragraph 31) The back-end application computer server may access the assignment computer store 110 [risk relationship data store] to help determine this information and the manager might then assign (or re-assign that risk relationship and the information in the computer store may be updated. (See Faherty paragraph 31) Information about the newly assigned risk relationship may be received by a relationship handler terminal and he or she might take actions as appropriate, such as establishing a communication link with an internal entity terminal. (See Faherty paragraph 31) Information about the various interactions associated with the risk relationship (e.g., a time, date of the interaction, a description of the interaction, etc.) may then be stored into assignment computer store 110. (See Faherty paragraph 31)
Faherty notes that the system of FIG. 1 is provided as an example and embodiments may be associated with additional elements or components where FIG. 2 illustrates a method that might be performed by some or all of the elements of the system described with respect to FIG. 1 or any other system and the embodiments of the invention may be practiced in any order. (See Faherty paragraph 32)
The system may manage an assignment computer store [risk relationship data store] containing a set of internal assignment manager identifiers, with each internal assignment manager identifier being linked to a plurality of internal relationship handler identifiers. (See Faherty paragraph 33) According to some embodiments, each internal relationship handler is further linked to a plurality of relationship identifiers between the enterprise and entities. (See Faherty paragraph 33) According to some embodiments, each internal relationship handler is further linked to a plurality of relationship identifiers between the enterprise and entities. (See Faherty paragraph 33) According to some embodiments, at least one risk relationship represents a potential future risk relationship between the enterprise and an entity and in some embodiments, at least one risk relationship represents an existing, ongoing risk relationship between the enterprise and an entity. (See Faherty paragraph 33 – risk relationships may be potential future risk relationships between the entity and enterprise and existing risk relationship between the enterprise and the entity – assignment computer store can contain electronic records regarding both potential and existing risk relationships)
The system may manage a risk relationship computer store containing a set of electronic data records each representing a risk relationship between the enterprise and an entity. (See Faherty paragraph 34 – risk relationship data store containing electronic records) According to some embodiments, each electronic data record including a relationship identifier and a set of relationship characteristic values with at least one characteristic value being a priority value for that risk relationship. (See Faherty paragraph 34 – entity attribute values)
An automated risk relationship management platform may retrieve a selected electronic data record from the risk relationship computer store. (See Faherty paragraph 35) The automated risk relationship management platform computer may determine that the priority value of the risk relationship represented by the selected electronic data record is both above a pre-determined minimum threshold priority value and below a pre-determined maximum threshold priority value. (See Faherty paragraph 35) That is, a risk relationship with a priority value above the pre-determined maximum threshold priority value might be handled by a different process (e.g., a single internal relationship handler might be assigned in such a situation). (See Faherty paragraph 35) Similarly, a risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler might be assigned in such a situation.) (See Faherty paragraph 35)
Responsive to a determination of a priority value of the risk relationship, the system may arrange for the selected relationship identifier to be assigned to one of the internal assignment manager identifiers and linked relationship handler identifier in the assignment computer store. (See Faherty paragraph 36) The system may generate a set of tasks for the risk relationship associated with the selected electronic data record. (See Faherty paragraph 36)
Electronic messages may be exchanged via a distributed communication network to present an interactive user interface at a remote relationship handler terminal associated with the assigned relationship handler identifier. (See Faherty paragraph 37) According to some embodiments, the interactive user interface display at the remote relationship handler terminal automatically facilitates a communication link with a remote external entity terminal. (See Faherty paragraph 37) For example, the automatically established communication link might be associated with a telephone call, a web chat, a video link, an electronic mail message and/or a postal mail message generated via a distribution center. (See Faherty paragraph 37)
Embodiments of the present invention might be associated with a number of different types of “risk relationships”. (See Faherty paragraph 38) As used herein, the phrase “risk relationship” might refer to, for example, an existing insurance policy between an insurer and an insured entity (e.g., whose policy is up for renewal) or potential insurance policy (e.g., associated with an entity who is considering purchasing insurance from the insurer). (See Faherty paragraph 38 – potential and existing risk relationships with an entity) In FIG. 3, a risk relationship management system for an insurer which as before is disclosed that the system includes a risk relationship management platform that may access information in an assignment and relationship computer store. (See Faherty paragraph 38) For example, the assignment and relationship computer store might store [information] about insurance enterprise claims advisor managers, insurance claim advisors, and insurance policies. (See Faherty paragraph 38) According to this embodiment, the assignment and relationship computer store further stores a set of electronic data records each representing a risk relationship between the enterprise and an entity (that is an insurance policy between the insurer and an insured) and moreover, each electronic data record includes a relationship identifier (that is an insurance policy identifier) and a set of relationship characteristic values with at least one characteristic value being a premium value for that insurance policy. (See Faherty paragraph 38 – the electronic data records are each representing a risk relationship between the enterprise and the entity – and as noted above, risk relationships include both existing and potential risk relationships, thus the assignment computer store stores records for both types of risk relationships)
According to some embodiments, the risk relationship platform might assign (or re-assign) insurance policies insurance policies to insurance claims advisors based at least in part on a type of insurance (e.g., a workers’ compensation insurance policy as compared to a business insurance policy), information from an insurance underwriter, a type of industry associated with the insured, an opportunity age, an opportunity likelihood of success (e.g., a high or low likelihood of eventually being converted into a sale), an entity priority (e.g., whether an entity is considered a Very Important Part (“VIP”) client and/or an insurer office. (See Faherty paragraph 44)
According to some embodiments, an interactive graphical user interface provided by the risk relationship management platform includes a claims manager workflow and FIGS. 4 through 8 illustrate a claims management workflow according to some embodiments. (See Faherty paragraph 45) In particular, FIG. 4 illustrates a display 400 that might be provided when an opportunity record enters the claims process. (See Faherty paragraph 45) The display might include, for example, an opportunity owner, an opportunity name, an agency name, a primary contact, a market segment, a confidence level, comments, a policy effective date, a targeted premium value, a stage description, a current carrier, and/or a lead source. (See Faherty paragraph 45)
Fig. 7 illustrates a claim advisor information display 700 in accordance with some embodiments. (See Faherty paragraph 48) The display 700 might include, for example, a claims advisor, a disposition, a claims advisor primary reason lost, a renewal status, claims advisor comments 710, an insured’s contact, an insured’s phone number, an insured’s email, a date a renewal status was set to “not renewed,” a date state was set to “quoted,” a date stage was set to “won/lost,” a date the claims advisor was assigned, and/or a name of a previous claims advisor. (See Faherty Cl. 11, 19 and paragraph 48 – entity information; each claims advisor identifier being linked to a plurality of policy identifiers between the insurer and insureds)
It would have been obvious to one having ordinary skill in the art at the time the invention was made to have modified Faherty by separating one composite claim element contained in Faherty (i.e. the assignment computer store/assignment and relationship computer store) into component claim elements (e.g. a potential risk relationship data store and an existing risk relationship data store) wherein each component claim element would serve the same separate function performed when it was a component in the original composite claim element. In the separation each component claim element, would merely have performed the same function as it did previously, and one of ordinary skill in the art at the time the invention was made would have recognized that the results of the separation were predictable. See MPEP §2144.04 (V)(C)
While Faherty discloses that each electronic data record includes a relationship identifier 392 (that is, an insurance policy identifier) and a set of relationship characteristic values which implies that the entity has been identified by virtue of the insurance policy identifier and information regarding the insured, it is not explicitly taught by Faherty.
Rakshe discloses his invention as to a back-end application computer server that may receive a request along with a descriptive term. (See Rakshe Abstract) The user may select one of the potential descriptions, and a user identifier may be associated with the request. (See Rakshe Abstract and paragraph 4 – user identifier [entity identifier]) A series of dynamic information exchanges may then help assign a category to the user identifier. (See Rakshe Abstract) A partial set of initial request details may be received from a third-party device and the user may adjust and/or add details to create a complete set. (See Rakshe Abstract) A potential value may then be calculated for the request. (See Rakshe Abstract and paragraph 4) An indication of the potential value may be transmitted to the user, and information about the user identifier may be transmitted to a user response terminal to facilitate communication between the user response terminal and the user. (See Rakshe Abstract and paragraph 4)
The present invention provides significant technical improvements to facilitate electronic messaging and dynamic data processing. (See Rakshe paragraph 28) The invention may directly exchange information with an enterprise in an automated and efficient manner, thus improving the overall performance of the system associated with an enterprise (e.g., by reducing the amount of communication required between parties and reducing errors). (See Rakshe paragraph 28)
A user may be interested in establishing a risk relationship with an enterprise. (See Rakshe paragraph 29) For example, a business might want to purchase property and liability insurance, workers’ compensation insurance, etc. from an insurer. (See Rakshe paragraph 29) When deciding whether or not to enter into such a relationship, the business will typically provide information describing the business to the insurer and receive an insurance quote, including an estimated insurance premium value, from the insurer. (See Rakshe paragraph 29 – insurance quote including estimated insurance premium value)
According to some embodiments, the system 100 may automatically facilitate an exchange of information via interactive user interface displays. (See Rakshe paragraph 34) For example, at (1) a front-end user device 160, associated with a user, might transmit a potential risk relationship request to the back-end application computer server 150 (e.g., via the communication interface 155). (See Rakshe paragraph 34) The back-end application computer server 150 may then use information from the description data store at (2) to exchange information with the remote front end user device 160 at (3) to determine an appropriate description of the business (e.g., an appropriate industry code). (See Rakshe paragraph 34) The back-end application computer server 150 may also use the information from the categorization data store at (4) to exchange information with the remote front end user device 160 at (5) to assign an appropriate category to the user (e.g., via series of dynamic information exchanges). (See Rakshe paragraph 34)
The back-end application computer server 150 may then receive a partial set of initial request details from a third party device 130 at (6). (See Rakshe paragraph 35) This information might, for example, be used to “pre-populate” information fields in an interactive user interface display. (See Rakshe paragraph 35) The user may then adjust and/or complete the request details and a potential value (e.g., an estimated insurance premium quote) may be automatically calculated and transmitted to the front-end user device 160 at (7). (See Rakshe paragraph 35) According to some embodiments, the back-end application computer server 150 may also transmit information to a user response terminal 140 at (8). (See Rakshe paragraph 35) For example, a user’s telephone number might be transmitted to the user response terminal 140 to facilitate a telephone call to the user at (9) to discuss the insurance quote in more detail. (See Rakshe paragraph 35 – phone number of the user is an entity identifier)
Figure 2 illustrates a method that might be performed by some or all of the elements of the system 100 described with respect to Figure 1, or any other system according to some embodiments of the invention. (See Rakshe paragraph 36) At 210, a back-end application computer server may receive, directly from a remote front-end user device associated with the user, an initial request. (See Rakshe paragraph 37)
At 220, a user identifier is associated with the request. (See Rakshe paragraph 43) The user identifier might be associated with, for example, a user name, an email address, an Internet protocol address, a telephone number, and/or a postal address. (See Rakshe paragraph 43 – entity identifiers) According to some embodiments, the user identifier may be used to communicate with a user and/or to save a partially completed request for the user. (See Rakshe paragraph 43) For example, the user’s telephone address, email address, etc. might be supplied so that a sales representative can contact the business to discuss the estimated insurance premium in more detail (and potentially complete the sale of the insurance policy). (See Rakshe paragraph 48)
Referring to Fig. 16, a table is shown that represents the request database that may be stored at the back-end application computer server 1500 according to some embodiments. (See Rakshe paragraph 65 and Fig. 16) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65 and Fig. 16) The table may also define fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 for each of these entries. The fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 may, according to some embodiments, specify: a potential relationship request identifier 1602, a user identifier 1604, potential pre-determined descriptions 1606, a selected description 1608, an assigned category 1610, a calculated potential value 1612, and a user response terminal identifier 1614. (See Rakshe paragraph 65) The request database 1600 may be created and updated, for example, based on information electronically received from remote front-end user devices. (See Rakshe paragraph 65)
The potential relationship request identifier 1602 may be, for example, a unique alphanumeric code identifying a user who is asking for a personalized insurance premium quote (e.g., “RR_101”). (See Rakshe paragraph 66 – an entity [user] identifier used by the insurer) The user identifier 1604 might be, for example, a user name, email address, telephone phone number, etc. that can be used to identify the request. (See Rakshe paragraph 66 – entity [user] identifiers)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals that implies (by virtue of disclosing an insurance policy identifier) that an entity is identified as disclosed by Faherty with the specific disclosure of a user identifier [entity identifier] as taught by Rakshe in order to further facilitate processing of risk relationships for an enterprise.
Regarding Claims 2 and 16, these substantially similar claims recite the limitations of Claims 1 and 15 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Faherty in view of Rakshe discloses the following:
wherein entities are sorted along the first axis based on a concentration value calculated for each entity using information in the existing risk relationship data store. (See Faherty paragraphs 34-35, 59, Cl. 1, Fig. 19)
In addition to the rejection presented above as if fully set forth herein, Faherty discloses that an automated risk relationship management platform may retrieve a selected electronic data record from the risk relationship computer store. (See Faherty paragraph 35) The automated risk relationship management platform computer may determine that the priority value of the risk relationship represented by the selected electronic data record is both above a pre-determined minimum threshold priority value and below a pre-determined maximum threshold priority value. (See Faherty paragraph 35) That is, a risk relationship with a priority value above the pre-determined maximum threshold priority value might be handled by a different process (e.g., a single internal relationship handler might be assigned in such a situation). (See Faherty paragraph 35) Similarly, a risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler might be assigned in such a situation.) (See Faherty paragraph 35)
Further, while Faherty discloses a table [grid] that discloses information regarding an entity on a first axis using information in the existing risk relationship data store and makes reference to a priority value or entity priority of the risk relationship and how that impacts workflow, Faherty does not fully disclose a concentration value calculated for each entity using information in the existing risk relationship data store.
In addition to the disclosure of Rakshe above, in reference to Fig. 2, Rakshe discloses that the system may receive, from the front-end user device, adjustments to the partial set of initial request details along with additional initial request details to establish a complete set of request details. (See Rakshe paragraph 46) Types of information that might be in the complete set of request details include a number of business locations, a number of employees, a business ZIP code, an indication of one or more types of insurance, a time period (e.g., a policy start and/or end date), a business location, contact information, a legal entity type (e.g., a corporation, sole proprietorship, etc.), an indication of when a business was established, an office type, an estimated annual sales or gross revenue value, an online sales estimate, a number of property losses, a business personal property limit, a personal property of others limit, a number of liability losses, a general liability limit, building information, workers’ compensation insurance data, and/or optional coverage selections. (See Rakshe paragraph 46 and Fig. 2)
At S228, the system may automatically calculate (e.g., based on the selected description, the assigned category, the complete set of request details, and information from an enterprise platform associated with the enterprise) a potential value associated with the request. (See Rakshe paragraph 47 – concentration value) For example, information from an underwriting platform associated with an insurer might be used to estimate an insurance premium value for a business. (See Rakshe paragraph 47)
At S230, the system may transmit an indication of the automatically calculated potential value directly from the back-end application server to the front-end user device via the communication network. (See Rakshe paragraph 48 – concentration value) In some embodiments, the system calculates a priority score for each request and transmits that information to the user response terminal (e.g., indicating which users should be contacted first based on the information received from the user, business goals, etc.) (See Rakshe paragraph 48)
Referring to Fig. 16, a table is shown that represents the request database that may be stored at the back-end application computer server 1500 according to some embodiments. (See Rakshe paragraph 65 and Fig. 16) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65 and Fig. 16) The table may also define fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 for each of these entries. The fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 may, according to some embodiments, specify: a potential relationship request identifier 1602, a user identifier 1604, potential pre-determined descriptions 1606, a selected description 1608, an assigned category 1610, a calculated potential value 1612, and a user response terminal identifier 1614. (See Rakshe paragraph 65) The request database 1600 may be created and updated, for example, based on information electronically received from remote front-end user devices. (See Rakshe paragraph 65)
The potential relationship request identifier 1602 may be, for example, a unique alphanumeric code identifying a user who is asking for a personalized insurance premium quote (e.g., “RR_101”). (See Rakshe paragraph 66 – an entity [user] identifier used by the insurer) The user identifier 1604 might be, for example, a user name, email address, telephone phone number, etc. that can be used to identify the request. (See Rakshe paragraph 66 – entity [user] identifiers)
The calculated potential value 1612 may represent a personalized insurance quote for the user. (See Rakshe paragraph 66) The user response terminal identifier 1614 might be associated with, for example, a customer service representative who can contact the user to provide or receive more information about the request. (See Rakshe paragraph 66)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals using a table display to arrange information of a subset of the electronic records by entity and providing management of tasks using a priority value as disclosed by Faherty with the additional disclosure of calculating a potential value associated with a request as taught by Rakshe in order to select an appropriate workflow path to improve insurance quote processing.
Regarding Claims 3 and 17, these substantially similar claims recite the limitations of Claims 2 and 16 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Faherty in view of Rakshe discloses the following:
wherein the grid display includes an icon, displayed along first axis and the second axis, representing a concentration value for each entity on a risk relationship type-by-type basis. (See Faherty paragraphs 44-45, Cl. 14 and Figs 6, 14-15)
In addition to the rejections above as if fully set forth herein disclosing a table display arranging information of a subset of the electronic records and using a priority value to provide management of tasks as disclosed by Faherty and the disclosure of calculating a potential value associated with the request as taught by Rakshe, Rakshe further teaches that potential value can be viewed in a grid and a priority score can be used to indicate which users should be contacted first.
At S228, the system may automatically calculate (e.g., based on the selected description, the assigned category, the complete set of request details, and information from an enterprise platform associated with the enterprise) a potential value associated with the request. (See Rakshe paragraph 47 – concentration value) For example, information from an underwriting platform associated with an insurer might be used to estimate an insurance premium value for a business. (See Rakshe paragraph 47)
At S230, the system may transmit an indication of the automatically calculated potential value directly from the back-end application server to the front-end user device via the communication network. (See Rakshe paragraph 48 – concentration value) In some embodiments, the system calculates a priority score for each request and transmits that information to the user response terminal (e.g., indicating which users should be contacted first based on the information received from the user, business goals, etc.) (See Rakshe paragraph 48 – ranked icon as an alphanumeric character)
Referring to Fig. 16, a table is shown that represents the request database that may be stored at the back-end application computer server 1500 according to some embodiments. (See Rakshe paragraph 65 and Fig. 16) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65 and Fig. 16) The table may also define fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 for each of these entries. The fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 may, according to some embodiments, specify: a potential relationship request identifier 1602, a user identifier 1604, potential pre-determined descriptions 1606, a selected description 1608, an assigned category 1610, a calculated potential value 1612, and a user response terminal identifier 1614. (See Rakshe paragraph 65) The request database 1600 may be created and updated, for example, based on information electronically received from remote front-end user devices. (See Rakshe paragraph 65)
The potential relationship request identifier 1602 may be, for example, a unique alphanumeric code identifying a user who is asking for a personalized insurance premium quote (e.g., “RR_101”). (See Rakshe paragraph 66 – an entity [user] identifier used by the insurer) The user identifier 1604 might be, for example, a user name, email address, telephone phone number, etc. that can be used to identify the request. (See Rakshe paragraph 66 – entity [user] identifiers)
The calculated potential value 1612 may represent a personalized insurance quote for the user. (See Rakshe paragraph 66) The user response terminal identifier 1614 might be associated with, for example, a customer service representative who can contact the user to provide or receive more information about the request. (See Rakshe paragraph 66)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals using a table display to arrange information of a subset of the electronic records by entity and providing management of tasks using a priority value as disclosed by Faherty with the additional disclosure of calculating a potential value associated with a request that can be sorted in a grid display using a priority score as taught by Rakshe in order to select an appropriate workflow path to improve insurance quote processing.
Regarding Claims 4 and 18, these substantially similar claims recite the limitations of Claims 3 and 17 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty in view of Rakshe discloses the following:
wherein each icon graphically represents a level of concentration via: (i) an icon color, (ii) an icon size, (iii) an icon shape, and (iv) at least one alphanumeric character.
In addition to the rejections above as if fully set forth herein, while an icon described as a priority score that is ranked and represented as an alphanumeric character representing a value of the potential value, icon color, shape and size are not addressed by Faherty in view of Rakshe
While the combination of Faherty in view of Rakshe discloses the claimed invention except for the color, shape and size of the icon. It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention was made to allow for any size, shape or color that the inventor desired. In re Kuhle, 526 F.2d 553, 555, 188 USPQ 7, 9 (CCPA 1975).
Regarding Claim 5, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein entity attribute values in the potential risk relationship data store include at least one of: (i) an entity name, (ii) an entity location, (iii) an entity address, (iv) entity contact information, (v) entity industry information, (vi) an industry code, (vii) an industry description, and (vii) an indication of whether or not the entity has an existing relationship with the enterprise. (See Faherty paragraphs 38, Cl. 8, 11, Figs. 9-12)
Regarding Claim 6, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein the backend application computer server is further programmed to:
receive an indication of the selected entity from the first remote user device, and (See Faherty paragraphs 30-33, 42, 45)
responsive to the received indication, transmitting additional entity attribute values associated with the selected entity to the first remote user device. (See Faherty paragraphs 30-33, 42, 45)
Regarding Claim 7, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein the backend application computer server is further programmed to:
receive at least one filter criteria from the first remote user device, (See Faherty paragraphs 30-31, 36, 46-48 and Fig 5)
apply the at least one filter criteria to the electronic records in the potential risk relationship data store, and (See Faherty paragraphs 30-31, 46-48 and Fig 5)
update the grid display with a filtered subset of the electronic records in the potential risk relationship data store. (See Faherty paragraphs 27, 30-33, 46-48 and Fig 5)
Regarding Claims 8 and 20, these substantially similar claims recite the limitations of Claims 7 and 19 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein the existing risk relationships comprise insurance policies. (See Faherty Cl. 6, paragraph 38)
Regarding Claims 9 and 21, these substantially similar claims recite the limitations of Claims 8 and 20 and as to those limitations are rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein the existing risk relationship types include at least one of: (i) automobile insurance, (ii) property insurance, (iii) general liability insurance, (iv) umbrella insurance, (v) workers’ compensation insurance, and (vi) special general liability insurance. (See Faherty paragraph 38, 44, Cl. 8)
Regarding Claim 10, this claim recites the limitations of Claim 8 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein the at least one filter criteria includes at least one of: (i) an insurance broker identifier, (ii) territory information, (iii) an insurance policy renewal date range, (iv) an industry, (v) an industry code, (vi) an enterprise sub-organization, and (vii) an underwriter identifier. (See Faherty paragraphs 45-46)
Regarding Claims 11 and 22, these substantially similar claims recite the limitations of Claims 8 and 19 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty in view of Rakshe discloses the following:
wherein entities are sorted along the first axis based on a concentration value calculated for each entity using information in the existing risk relationship data store including at least one of: (i) a number of insurance policies, and (ii) an overall total insurance premium value.
In addition to the rejections presented above as if fully set forth herein, Faherty discloses that an automated risk relationship management platform may retrieve a selected electronic data record from the risk relationship computer store. (See Faherty paragraph 35) The automated risk relationship management platform computer may determine that the priority value of the risk relationship represented by the selected electronic data record is both above a pre-determined minimum threshold priority value and below a pre-determined maximum threshold priority value. (See Faherty paragraph 35) That is, a risk relationship with a priority value above the pre-determined maximum threshold priority value might be handled by a different process (e.g., a single internal relationship handler might be assigned in such a situation). (See Faherty paragraph 35) Similarly, a risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (e.g., no internal relationship handler might be assigned in such a situation.) (See Faherty paragraph 35) The system includes a risk relationship management platform that may access information in an assignment and relationship computer store, for instance storing information about insurance policies. (See Faherty paragraph 38)
Further, while Faherty discloses a table [grid] that discloses information regarding an entity on a first axis using information in the existing risk relationship data store and makes reference to a priority value or entity priority of the risk relationship and how that impacts workflow, Faherty does not fully disclose a concentration value calculated for each entity using information in the existing risk relationship data store.
Rakshe discloses his invention as to a back-end application computer server that may receive a request along with a descriptive term. (See Rakshe Abstract) The user may select one of the potential descriptions, and a user identifier may be associated with the request. (See Rakshe Abstract and paragraph 4 – user identifier [entity identifier]) A series of dynamic information exchanges may then help assign a category to the user identifier. (See Rakshe Abstract) A partial set of initial request details may be received from a third-party device and the user may adjust and/or add details to create a complete set. (See Rakshe Abstract) A potential value may then be calculated for the request. (See Rakshe Abstract and paragraph 4) An indication of the potential value may be transmitted to the user, and information about the user identifier may be transmitted to a user response terminal to facilitate communication between the user response terminal and the user. (See Rakshe Abstract and paragraph 4)
The present invention provides significant technical improvements to facilitate electronic messaging and dynamic data processing. (See Rakshe paragraph 28) The invention may directly exchange information with an enterprise in an automated and efficient manner, thus improving the overall performance of the system associated with an enterprise (e.g., by reducing the amount of communication required between parties and reducing errors). (See Rakshe paragraph 28)
A user may be interested in establishing a risk relationship with an enterprise. (See Rakshe paragraph 29) For example, a business might want to purchase property and liability insurance, workers’ compensation insurance, etc. from an insurer. (See Rakshe paragraph 29) When deciding whether or not to enter into such a relationship, the business will typically provide information describing the business to the insurer and receive an insurance quote, including an estimated insurance premium value, from the insurer. (See Rakshe paragraph 29 – insurance quote including estimated insurance premium value)
According to some embodiments, the system 100 may automatically facilitate an exchange of information via interactive user interface displays. (See Rakshe paragraph 34) For example, at (1) a front-end user device 160, associated with a user, might transmit a potential risk relationship request to the back-end application computer server 150 (e.g., via the communication interface 155). (See Rakshe paragraph 34) The back-end application computer server 150 may then use information from the description data store at (2) to exchange information with the remote front end user device 160 at (3) to determine an appropriate description of the business (e.g., an appropriate industry code). (See Rakshe paragraph 34) The back-end application computer server 150 may also use the information from the categorization data store at (4) to exchange information with the remote front end user device 160 at (5) to assign an appropriate category to the user (e.g., via series of dynamic information exchanges). (See Rakshe paragraph 34)
The back-end application computer server 150 may then receive a partial set of initial request details from a third party device 130 at (6). (See Rakshe paragraph 35) This information might, for example, be used to “pre-populate” information fields in an interactive user interface display. (See Rakshe paragraph 35) The user may then adjust and/or complete the request details and a potential value (e.g., an estimated insurance premium quote) may be automatically calculated and transmitted to the front-end user device 160 at (7). (See Rakshe paragraph 35) According to some embodiments, the back-end application computer server 150 may also transmit information to a user response terminal 140 at (8). (See Rakshe paragraph 35) For example, a user’s telephone number might be transmitted to the user response terminal 140 to facilitate a telephone call to the user at (9) to discuss the insurance quote in more detail. (See Rakshe paragraph 35 – phone number of the user is an entity identifier)
Figure 2 illustrates a method that might be performed by some or all of the elements of the system 100 described with respect to Figure 1, or any other system according to some embodiments of the invention. (See Rakshe paragraph 36) At 210, a back-end application computer server may receive, directly from a remote front-end user device associated with the user, an initial request. (See Rakshe paragraph 37)
At 220, a user identifier is associated with the request. (See Rakshe paragraph 43) The user identifier might be associated with, for example, a user name, an email address, an Internet protocol address, a telephone number, and/or a postal address. (See Rakshe paragraph 43 – entity identifiers) According to some embodiments, the user identifier may be used to communicate with a user and/or to save a partially completed request for the user. (See Rakshe paragraph 43)
In reference to Fig. 2, Rakshe discloses that the system may receive, from the front-end user device, adjustments to the partial set of initial request details along with additional initial request details to establish a complete set of request details. (See Rakshe paragraph 46) Types of information that might be in the complete set of request details include a number of business locations, a number of employees, a business ZIP code, an indication of one or more types of insurance, a time period (e.g., a policy start and/or end date), a business location, contact information, a legal entity type (e.g., a corporation, sole proprietorship, etc.), an indication of when a business was established, an office type, an estimated annual sales or gross revenue value, an online sales estimate, a number of property losses, a business personal property limit, a personal property of others limit, a number of liability losses, a general liability limit, building information, workers’ compensation insurance data, and/or optional coverage selections. (See Rakshe paragraph 46 and Fig. 2)
At S228, the system may automatically calculate (e.g., based on the selected description, the assigned category, the complete set of request details, and information from an enterprise platform associated with the enterprise) a potential value associated with the request. (See Rakshe paragraph 47 – concentration value) For example, information from an underwriting platform associated with an insurer might be used to estimate an insurance premium value for a business. (See Rakshe paragraph 47)
At S230, the system may transmit an indication of the automatically calculated potential value directly from the back-end application server to the front-end user device via the communication network. (See Rakshe paragraph 48 – concentration value) In some embodiments, the system calculates a priority score for each request and transmits that information to the user response terminal (e.g., indicating which users should be contacted first based on the information received from the user, business goals, etc.) (See Rakshe paragraph 48)
For example, the user’s telephone address, email address, etc. might be supplied so that a sales representative can contact the business to discuss the estimated insurance premium in more detail (and potentially complete the sale of the insurance policy). (See Rakshe paragraph 48)
Referring to Fig. 16, a table is shown that represents the request database that may be stored at the back-end application computer server 1500 according to some embodiments. (See Rakshe paragraph 65 and Fig. 16) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65) The table may include, for example, entries identifying potential risk relationship requests received by an enterprise from users. (See Rakshe paragraph 65 and Fig. 16) The table may also define fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 for each of these entries. The fields 1602, 1604, 1606, 1608, 1610, 1612, 1614 may, according to some embodiments, specify: a potential relationship request identifier 1602, a user identifier 1604, potential pre-determined descriptions 1606, a selected description 1608, an assigned category 1610, a calculated potential value 1612, and a user response terminal identifier 1614. (See Rakshe paragraph 65) The request database 1600 may be created and updated, for example, based on information electronically received from remote front-end user devices. (See Rakshe paragraph 65)
The potential relationship request identifier 1602 may be, for example, a unique alphanumeric code identifying a user who is asking for a personalized insurance premium quote (e.g., “RR_101”). (See Rakshe paragraph 66 – an entity [user] identifier used by the insurer) The user identifier 1604 might be, for example, a user name, email address, telephone phone number, etc. that can be used to identify the request. (See Rakshe paragraph 66 – entity [user] identifiers)
The calculated potential value 1612 may represent a personalized insurance quote for the user. (See Rakshe paragraph 66) The user response terminal identifier 1614 might be associated with, for example, a customer service representative who can contact the user to provide or receive more information about the request. (See Rakshe paragraph 66)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals using a table display to arrange information of a subset of the electronic records by entity and providing management of tasks using a priority value as disclosed by Faherty with the additional disclosure of calculating a potential value associated with a request as taught by Rakshe in order to select an appropriate workflow path to improve insurance quote processing.
Regarding Claim 12, this claim recites the limitations of Claim 8 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Further, Faherty discloses the following:
wherein electronic records are excluded from the subset of records included in the grid display based on at least one of: (i) historical insurance claim information associated with an entity, (ii) a risk score associated with an entity, and (iii) a prior underwriting or renewal decision associated with an entity. (See Faherty paragraphs 35, 65, 69, Cl. 8, Fig. 24 – risk relationship with a priority value below the pre-determined minimum threshold priority value might be handled by a different process (i.e., no internal relationship handler may be assigned)
Regarding Claim 13, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty in view of Rakshe discloses the following:
wherein information from the potential risk relationship data store is supplemented with at least one of: (i) third-party data, (ii) governmental data, (iii) payroll data, (iv) credit score data, and (v) social media information. (See Faherty paragraphs 25, 27, 39 – may involve interaction of data from third party systems)
While Faherty discloses that information may be supplemented with at least third party data, Rakshe further discloses that the system may receive, from a third-party device (e.g., based on the selected description, the user identifier, and/or the assigned category), a partial set of initial request details. (See Rakshe paragraph 45) For example, the third-party device might be associated with a Customer Relationship Management (“CRM”) platform, a governmental platform (e.g., associated with a Department of Motor Vehicles), a real estate platform, a credit score platform, etc.) (See Rakshe paragraph 45) As another example, information from search platforms, advertisement systems, data stored locally at the front-end user device and/or social media sites might be used to pre-populate some information for the user. (See Rakshe paragraph 45)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk relationship management platform that may access information in an assignment computer store that facilitates management, assignment and viewing of insurance information via one or more terminals with supplemental information from third-parties as disclosed by Faherty with the additional supplemental data sources as disclosed by Rakshe in order to calculate a more accurate risk score to further improve insurance quote processing.
Regarding Claim 14, this claim recites the limitations of Claim 1 and as to those limitations is rejected for the same basis and reasons as disclosed above. Further, Faherty discloses the following:
wherein the back-end application server is further programmed to utilize at least one of: (i) automatically generated email reminders, (ii) automatically generated text message reminders, (iii) a chatbot text interface, (iv) a streaming video interface, and (v) voice recognition. (See Faherty paragraph 31, 36-39, 42, Cl. 4-5 & 16)
Prior Relevant Art of Record Not Currently Applied
Summerson et al. (US PG Pub. 2019/0318420) (“Summerson”) - discloses his invention as to systems, methods, apparatus, computer program code and means are provided to automatically create risk scores for electronic records in a way that provides faster, more accurate results and that allow for flexibility and effectiveness when responding to those results. (See Summerson paragraph 3) In some cases, a risk value associated with an enterprise system may depend at least in part on attribute values of electronic records representing a plurality of potential associations with the enterprise system. (See Summerson paragraph 21) For example, the risk value might tend to increase when a specific type of attribute value increases (or decrease when another type of attribute value increases). (See Summerson paragraph 21) The systems and methods are disclosed to automatically create risk scores for electronic records using an automated scoring analysis computer that may be access information in a potential association computer store (e.g., storing a set of electronic records representing risk associations, each record including, for example, one or more communication addresses, attribute values, etc.) (See Summerson paragraph 23) Each potential insurance policy might be associated with, for example, an insurance policy quote, an existing insurance policy quote, or an insurance policy renewal. (See Summerson paragraph 29) At least one of the attribute values of a potential insurance policy might include information about an insured associated with the insurance policy, such as an annual sales amount, an industry classification, prior claim information, etc. (See Summerson paragraph 29)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMBREEN A. ALLADIN whose telephone number is (571)270-3533. The examiner can normally be reached Monday - Friday 9-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abhishek Vyas can be reached at 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMBREEN A. ALLADIN/Primary Examiner, Art Unit 3691 March 20, 2026