DETAILED ACTION
This action is in reply to the original application filed on 07/24/2025.
Claims 1-20 are rejected.
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
Information Disclosure Statement received 11/01/2024 has been reviewed and considered.
Priority
The current Application claims priority from Parent Patent No. 12,165,183 filed 07/08/2021. Therefore, the instant claims receive the effective filing date of 07/08/2021.
Notice of Pre-AIA or AIA Status
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
Claims 5-7 and 16-17 are objected to because of the following informalities:
-Claim 5 reads “the entity” but should likely read “an entity”
Claims 6-7 inherit the deficiencies noted in claim 5, and are therefore objected to on the same basis.
-Claim 16 reads “performing … with a server device, wherein the predetermined identifying information is for the entity” but should likely read “performing … with the server device, wherein the predetermined identifying information is for an entity”
Claims 17 inherit the deficiencies noted in claim 16, and are therefore objected to on the same basis.
Appropriate correction is required.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories (see MPEP 2106.03). All the claims are directed to one of the four statutory categories (YES).
Under Step 2A of the Subject Matter Eligibility Test, it is determined whether the claims are directed to a judicially recognized exception (see MPEP 2106.04). Step 2A is a two-prong inquiry.
Under Prong 1, it is determined whether the claim recites a judicial exception (YES). Taking Claim 1 as representative, the claim recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including:
-a processor;
-a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the processor to:
-permit a plurality of transactional workflows for a product or service to be initiated and saved;
-save each transactional workflow of the plurality of transactional workflows to a corresponding storage location;
-update a [storage document] retrieval manifest associated with each transactional workflow with a unique identifier, the [storage document] retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional workflow;
-provide a first option to retrieve details of the plurality of transactional workflows;
-receive a request to retrieve details of the plurality of transactional workflows;
-determine the unique identifier of-each transactional workflow based on the request;
-provide a second option to resume one or more transactional workflows of the plurality of transactional workflows associated with the determined unique identifiers;
-in response to a corresponding selection associated with the second option:
-retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows from the [storage document] retrieval manifest; and
-serve workflow elements based on information recovered from the storage location to resume the one or more transactional workflows of the plurality of transactional workflows
The above limitations recite the concept of saving and resuming transactional workflows. The above limitations fall within the “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a).
Certain methods of organizing human activity include:
fundamental economic principles or practices (including hedging, insurance, and mitigating risk)
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; and business relations)
managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)
The limitations of permit a plurality of transactional workflows for a product or service to be initiated and saved; save each transactional workflow of the plurality of transactional workflows to a corresponding storage location; provide a first option to retrieve details of the plurality of transactional workflows; receive a request to retrieve details of the plurality of transactional workflows; determine the unique identifier of-each transactional workflow based on the request; provide a second option to resume one or more transactional workflows of the plurality of transactional workflows associated with the determined unique identifiers; in response to a corresponding selection associated with the second option: serve workflow elements based on information recovered from the storage location to resume the one or more transactional workflows of the plurality of transactional workflows module are processes that, under their broadest reasonable interpretation, cover a commercial interaction. For example, “permit,” “save,” “provide,” “receive,” “determine,” “provide,” “selection,” and “serve” in the context of this claim encompass advertising, and marketing or sales activities.
Similarly, the limitations of update a [storage document] retrieval manifest associated with each transactional workflow with a unique identifier, the [storage document] retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional workflow; and retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows from the [storage document] retrieval manifest are processes that, under their broadest reasonable interpretation, cover a commercial interaction. That is, other than reciting that storage document is a retrieval manifest, nothing in the claim element precludes the step from practically being performed by people. For example, but for the “retrieval manifest” language, “update” and “retrieve” in the context of this claim encompasses advertising, and marketing or sales activities.
Under Prong 2, it is determined whether the claim recites additional elements that integrate the exception into a practical application of the exception. This judicial exception is not integrated into a practical application (NO).
-a processor;
-a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the processor to:
-permit a plurality of transactional workflows for a product or service to be initiated and saved;
-save each transactional workflow of the plurality of transactional workflows to a corresponding storage location;
-update a retrieval manifest associated with each transactional workflow with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional workflow;
-provide a first option to retrieve details of the plurality of transactional workflows;
-receive a request to retrieve details of the plurality of transactional workflows;
-determine the unique identifier of-each transactional workflow based on the request;
-provide a second option to resume one or more transactional workflows of the plurality of transactional workflows associated with the determined unique identifiers;
-in response to a corresponding selection associated with the second option:
-retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows from the retrieval manifest; and
-serve workflow elements based on information recovered from the storage location to resume the one or more transactional workflows of the plurality of transactional workflows
These limitations are not indicative of integration into a practical application because:
The additional elements of claim 1 are recited at a high level of generality (i.e. as generic computing hardware) such that they amount to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea) as supported by paragraph [0048] of Applicant’s specification – “While not delineated in FIG. 5, the transactional workflow system 10 includes at least one memory or memory device that can include a tangible and non-transitory computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by processor 60.” Specifically, the additional elements of server device, a processor, a memory coupled to the processor, the memory storing computer executable instructions, and a retrieval manifest are recited at a high-level of generality (i.e. as a generic processor performing the generic computer functions of permitting data, saving data, updating data, providing data, receiving data, determining data, selecting data, retrieving data, and serving data) such that they amount do no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. Further, the additional elements do no more than generally link the use of the judicial exception to a particular technological environment or field of use (such as computers or computing networks). Employing well-known computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not integrate the exception into a practical application.
Additionally, the additional elements are insufficient to integrate the abstract idea into a practical application because the claim fails to i) reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, ii) apply the judicial exception with, or use the judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, iii) effect a transformation or reduction of a particular article to a different state or thing, or iv) apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, the judicial exception is not integrated into a practical application.
Under Step 2B, it is determined whether the claims recite additional elements that amount to significantly more than the judicial exception. The claims of the present application do not include additional elements that are sufficient to amount to significantly more than the judicial exception (NO).
In the case of claim 1, taken individually or as a whole, the additional elements of claim 9 do not provide an inventive concept. As discussed above under step 2A (prong 2) with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed functions amount to no more than a general link to a technological environment.
Even considered as an ordered combination (as a whole), the additional elements do not add anything significantly more than when considered individually.
Claim 12 is a method reciting similar functions as claim 1. Examiner notes that claim 12 recites the additional elements of a server device and a retrieval manifest, however, claim 12 does not qualify as eligible subject matter for similar reasons as claim 1 indicated above.
Claim 20 is a non-transitory computer-readable storage medium reciting similar functions as claim 1. Examiner notes that claim 20 recites the additional elements of a non-transitory computer-readable storage medium and a retrieval manifest, however, claim 20 does not qualify as eligible subject matter for similar reasons as claim 1 indicated above.
Therefore, claims 1, 12, and 20 do not provide an inventive concept and do not qualify as eligible subject matter.
Dependent claims 2-11 and 13-19, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. § 101 because they do not add “significantly more” to the abstract idea. More specifically, dependent claims 2-11 and 13-19 further fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas in that they recite commercial interactions. Dependent claims 4, 7, 10, 14-15, and 19 do not recite any farther additional elements, and as such are not indicative of integration into a practical application for at least similar reasons discussed above. Dependent claims 2-3, 5-6, 8-9, 11, 13, and 16-18 recite the additional elements of the computer executable instructions, the processor, the retrieval manifest, a client device, an interface, the server device, a machine learning module, but similar to the analysis under prong two of Step 2A these additional elements are used as a tool to perform the abstract idea. As such, under prong two of Step 2A, claims 2-11 and 13-19 are not indicative of integration into a practical application for at least similar reasons as discussed above. Thus, dependent claims 2-4, 6-8, and 10-12 are “directed to” an abstract idea. Next, under Step 2B, similar to the analysis of claims 1, 12, and 20, dependent claims 2-11 and 13-19 when analyzed individually and as an ordered combination, merely further define the commonplace business method (i.e. saving and resuming transactional workflows) being applied on a general-purpose computer and, therefore, do not amount to significantly more than the abstract idea itself. Accordingly, the Examiner concludes that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. The analysis above applies to all statutory categories of invention.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 1 of the current application as follows:
Claim 1 of current Application
Claim 1 of 12,165,183
a processor;
a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the processor to:
permit a plurality of transactional workflows for a product or service to be initiated and saved;
save each transactional workflow of the plurality of transactional workflows to a corresponding storage location;
update a retrieval manifest associated with each transactional workflow with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional workflow;
provide a first option to retrieve details of the plurality of transactional workflows;
receive a request to retrieve details of the plurality of transactional workflows;
determine the unique identifier of-each transactional workflow based on the request;
provide a second option to resume one or more transactional workflows of the plurality of transactional workflows associated with the determined unique identifiers;
in response to a corresponding selection associated with the second option:
retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows from the retrieval manifest; and
serve workflow elements based on information recovered from the storage location to resume the one or more transactional workflows of the plurality of transactional workflows.
a processor;
a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the processor to:
permit, by a client device, a plurality of transactional workflows for a product or service to be initiated, at least partially completed, and saved by the client device on the server device, prior to completion;
save each transactional workflow of the plurality of transactional workflows to a corresponding storage location;
update a retrieval manifest associated with each transactional workflow with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional workflow;
map the unique identifier to an entity associated with the client device, wherein the client device is used to initiate a corresponding transactional workflow;
provide a first option for the client device to retrieve, from the server device, details of the plurality of transactional workflows;
receive a request at a later time to retrieve details of the plurality of transactional workflows;
provide an interface and receive, at the interface, predetermined identifying information to perform authentication of a user associated with the request with the server device;
perform an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating the client device with the server device, wherein the predetermined identifying information is for the entity;
use the predetermined identifying information to determine the unique identifier of each transactional workflow;
provide a second option for the client device to resume one or more transactional workflows of the plurality of transactional workflows, wherein the one or more transactional workflow of the plurality of transactional workflows are associated with the determined unique identifiers;
in response to a corresponding selection associated with the second option:
retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows from the retrieval manifest; and
serve workflow elements based on information recovered from the storage location to resume the one or more transactional workflows of the plurality of transactional workflows;
wherein each transactional workflow is saved in a format that permits the server device to execute and complete a binding outcome in obtaining the product or the service upon resumption of the one or more transactional workflows of the plurality of corresponding-transactional workflows
Claim 12 recites limitations directed towards a method. The limitations recited in claim 12 are parallel in nature to those addressed above for claim 1, and are therefore rejected for those same reasons set forth above in claim 1.
Claim 20 recites limitations directed towards a non-transitory computer readable medium. The limitations recited in claim 20 are parallel in nature to those addressed above for claim 1, and are therefore rejected for those same reasons set forth above in claim 1.
Claim 2 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 4 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 4 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 2 of the current application as follows:
Claim 2 of current Application
Claim 4 of 12,165,183
wherein the computer executable instructions further cause the processor to:
track an expiry date, via the retrieval manifest, associated with the corresponding transactional workflow of the plurality of transactional workflows;
mark the corresponding transactional workflow as an expired transactional workflow after the expiry date; and
provide an indication of the expiry date passing to a client device
wherein the computer executable instructions further cause the processor to:
track an expiry date, via the retrieval manifest, associated with the corresponding transactional workflow of the plurality of transactional workflows;
mark the corresponding transactional workflow as an expired transactional workflow after the expiry date; and
provide an indication of the expiry date passing to the client device
Claim 3 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 5 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 5 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 3 of the current application as follows:
Claim 3 of current Application
Claim 5 of 12,165,183
wherein the indication of the expiry date passing is provided in response to attempting to retrieve the expired transactional workflow from the retrieval manifest
wherein the indication of the expiry date passing is provided in response to attempting to retrieve the expired transactional workflow from the retrieval manifest
Claim 4 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 6 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 6 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 4 of the current application as follows:
Claim 4 of current Application
Claim 6 of 12,165,183
wherein the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date
wherein the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date
Claim 15 recites limitations directed towards a method. The limitations recited in claim 15 are parallel in nature to those addressed above for claim 4, and are therefore rejected for those same reasons set forth above in claim 4.
Claim 5 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 5 of the current application as follows:
Claim 5 of current Application
Claim 1 of 12,165,183
wherein the computer executable instructions further cause the processor to:
provide an interface and receive, at the interface, predetermined identifying information to perform authentication of a user associated with the request with the server device;
perform an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device, wherein the predetermined identifying information is for the entity; and
wherein the predetermined identifying information is used to determine the unique identifier.
provide an interface and receive, at the interface, predetermined identifying information to perform authentication of a user associated with the request with the server device;
perform an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating the client device with the server device, wherein the predetermined identifying information is for the entity;
use the predetermined identifying information to determine the unique identifier of each transactional workflow
Claim 6 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 2 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 2 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 6 of the current application as follows:
Claim 6 of current Application
Claim 2 of 12,165,183
wherein the predetermined identifying information comprises limited information to avoid storing personally identifiable information during a current session and not returning the personally identifiable information until the client device is authenticated
wherein the predetermined identifying information comprises limited information to avoid storing personally identifiable information during a current session and not returning the personally identifiable information until the client device is authenticated
Claim 17 recites limitations directed towards a method. The limitations recited in claim 17 are parallel in nature to those addressed above for claim 6, and are therefore rejected for those same reasons set forth above in claim 6.
Claim 7 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 3 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 3 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 7 of the current application as follows:
Claim 7 of current Application
Claim 3 of 12,165,183
wherein the limited information comprises a phone number used to initiate the authentication process using a security code
wherein the limited information comprises a phone number used to initiate the authentication process using a security code
Claim 8 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 8 of the current application as follows:
Claim 8 of current Application
Claim 1 of 12,165,183
wherein each transactional workflow is saved in a format that permits the server device to execute and complete a binding outcome in obtaining the product or the service upon resumption of the one or more transactional workflows of the plurality of transactional workflows
wherein each transactional workflow is saved in a format that permits the server device to execute and complete a binding outcome in obtaining the product or the service upon resumption of the one or more transactional workflows of the plurality of corresponding-transactional workflows
Claim 9 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 10 of U.S. Patent No. 12,165,183 in view of Bryant et al. (US 2022/0129926 A1), hereinafter Bryant as follows:
Claim 9 of current Application
Claim 10 of 12,165,183
wherein the retrieval manifest comprises preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module
wherein the retrieval manifest comprises preference data for displaying the plurality of transactional workflows
Patent No. 12,165,183 does not explicitly teach the retrieval manifest comprises preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module.
Bryant, however, teaches receiving quotes (i.e. [0021]), including the known technique of data storage comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module (Bryant, see at least: “The machine-learning component 124 can access a question set 308 and provider data 306 associated with the product providers 134 of FIG. 1 to customize the question selection and presentation as part of an interview process. The machine-learning component 124 can select an order of questions from the question set 308 and may eliminate some questions or expand the questions to cover additional products. User experience can be customized by selecting between various types of input interfaces, such as pulldown lists, radio buttons, checkboxes, free-form text, voice-enabled data entry, natural language interfaces, and the like. Initial configurations can be established based on preferences of operators of the websites 118. The machine-learning component 124 can modify the user experience in presenting options in the presentation component 304. For example, the order of presenting offers can be modified to promote offers that have had a higher rate of acceptance based on learned patterns [i.e. determined by analyzing client data using a machine learning module]. Geographic region, household size, credit rating, driving data, billing, retention, coverage level, engagement, and other such factors may be observed by the machine-learning component 124 [i.e. determined by analyzing client data using a machine learning module] to adjust result ordering and display attributes in the presentation component 304 [i.e. comprising preference data for displaying the plurality of transactional workflows] … As the machine-learning component 124 observes results, the provider data 306 and/or question set 308 can be updated. The provider data 306 and/or question set 308 can be stored, for example, in databases 120 [i.e. data storage comprising preference data] of FIG. 1” [0033] and “Preferences may be stored in the settings database 830 [i.e. data storage comprising preference data]” [0045] and “alternative database structures to those described may be readily employed, and (ii) other memory structures besides databases may be readily employed” [0078]). This known technique is applicable to the server device of Patent No. 12,165,183 as they both share characteristics and capabilities, namely, they are directed to receiving quotes.
It would have been recognized that applying the known technique of data storage comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module, as taught by Bryant, to the teachings of Patent No. 12,165,183 would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modification of data storage comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module, as taught by Bryant, into the server device of Patent No. 12,165,183 would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would enhance the user experience (Bryant, [0021]).
Claim 10 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 8 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 8 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 10 of the current application as follows:
Claim 10 of current Application
Claim 8 of 12,165,183
wherein corresponding storage locations store each transactional workflow based on graphs that atomize the process into a plurality of nodes
wherein corresponding storage locations store each transactional workflow based on graphs that atomize the process into a plurality of nodes
Claim 13 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 13 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 13 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 13 of the current application as follows:
Claim 13 of current Application
Claim 13 of 12,165,183
tracking an expiry date associated with the corresponding transactional workflow of the plurality of transactional workflows;
marking the corresponding transactional workflow as an expired transactional workflow after the expiry date; and
providing an indication of the expiry date passing to the client device
tracking an expiry date associated with the corresponding transactional workflow of the plurality of transactional workflows;
marking the corresponding transactional workflow as an expired transactional workflow after the expiry date; and
providing an indication of the expiry date passing to the client device
Claim 14 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 14 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 14 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 14 of the current application as follows:
Claim 14 of current Application
Claim 14 of 12,165,183
wherein the indication of the expiry date passing is provided in response to attempting to retrieve the expired transactional workflow
wherein the indication of the expiry date passing is provided in response to attempting to retrieve the expired transactional workflow
Claim 16 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 11 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 11 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 16 of the current application as follows:
Claim 16 of current Application
Claim 11 of 12,165,183
providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user associated with the request;
performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with a server device, wherein the predetermined identifying information is for the entity; and
wherein the predetermined identifying information is used to determine the unique identifier
providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user associated with the request with the server device;
performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating the client device with the server device, wherein the predetermined identifying information is for the entity;
using the predetermined identifying information to determine the unique identifier of each transactional workflow
Claim 18 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 16 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 16 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 18 of the current application as follows:
Claim 18 of current Application
Claim 16 of 12,165,183
wherein the request is initiated from a reminder sent to a client device by the server device
wherein the request is initiated from a reminder sent to the client device by the server device
Claim 19 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 17 of U.S. Patent No. 12,165,183. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 17 of U.S. Patent No. 12,165,183 contains all of the limitations recited in claim 19 of the current application as follows:
Claim 19 of current Application
Claim 17 of 12,165,183
wherein the format represents each transactional workflow based on graphs that atomize the process into a plurality of nodes
wherein the format represents each transactional workflow based on graphs that atomize the process into a plurality of nodes
Examiner Note: Regarding Claim 11, there is no double patenting as US Patent No. 12,165,183 and claim 11 of the current claims are distinct inventions.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 1-3, 8, 11-14, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Clawson et al. (US 9,652,805 B1), hereinafter Clawson, in view of Bates et al. (US 2019/0391972 A1), hereinafter Bates.
Regarding claim 1, Clawson discloses a server device for managing multiple transactional workflows, the server device comprising:
-a processor (Clawson, see at least: “a system may include a computer-based system, a processor-containing system, or another system that includes an input and output interface that may communicate with a publicly accessible distributed network through a wireless or tangible communication bus through a public and/or proprietary protocol and may respond to commands, events, actions, and/or requests” Col. 16 Ln. 4-11);
-a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor (Clawson, see at least: “The methods and descriptions described may be programmed in one or more servers or may be encoded in a non-transitory signal bearing medium, a computer readable medium such as a memory that may comprise unitary or separate logic, programmed within a device such as one or more integrated circuits, retained in memory and/or processed by a controller or a computer. If the methods are performed through software, the software or logic may reside in a memory resident to or interfaced to one or more processors or controllers that may support a tangible communication interface, wireless communication interface, or a wireless system. The memory may include an ordered listing of executable instructions for implementing logical functions” Col. 15 Ln. 50-63) cause the processor to:
-permit a plurality of transactional workflows for a product or service to be initiated and saved (Clawson, see at least: “When complete, incomplete [i.e. permit a plurality of transactional workflows for a product or service to be initiated] or abandoned, the process may be confirmed or re-solicited by email messages 408, text messaging, postal services, or through other visual, aural, or tactile medium” Col. 10 Ln. 31-34 and “A record of all of the activities that occur through the process may be saved [i.e. and saved] in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5” Col. 10 Ln. 39-44 and “Details of the exemplary types of product quoting systems that the work flow orchestration engine 704 [i.e. of transactional workflows for a product or service] may orchestrate are shown in FIG. 7. The product quoting applications may include direct auto applications 716, residency applications 718, special lines applications 720, umbrella quoting applications 722, and commercial quoting applications” Col. 12 Ln. 40-45 and Fig. 7 displays the end-to-end digital flow to acquire the product or service of “select products->collect common data->collect data quote for products->display combined rates->collect buy data for products->buy products” : Examiner notes that MPQ stands for “multiproduct quoting” [i.e. a plurality of transactional workflows] see at least Col. 2 Ln. 4-6);
-save each transactional workflow of the plurality of transactional workflows to a corresponding storage location (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse [i.e. save each transactional workflow of the plurality of transactional workflows to a corresponding storage location]. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes” Col. 10 Ln. 39-53);
-each transactional workflow being associated with a unique identifier and mapping the unique identifier to the corresponding storage location for each transactional workflow (Clawson, see at least: “Because comparative rating may occur in real-time or near real-time, the data may be collected prior to an MPQ quote. To begin a comparative rate, the MPQ quote process 300 will pass quote data and transfer control to the comparative rating application 1302. During this period, remapping of the quote data may occur that may result in a new or updated quoted rate. The new or updated quoted rate may be provided by the MPQ quote process 300 to the comparative rating application 1302 via a service. Should a user elect to purchase an insurance product under a new or updated quote (after remapping), the comparative rating application 1302 may transmit quote data back to the MPQ quote process 300 that delivers the quotes to the MPQ buy process 400” Col. 15 Ln. 7-20 and “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes [i.e. each transactional workflow being associated with a unique identifier], insurance products, insurance carriers, and/or data associated with one or more insurance quotes” Col. 10 Ln. 39-53 and “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5. Alternatively, the user may select a hyperlink associated with one or more insurance quotes, insurance products, insurance carriers, etc. that are embedded in an email message 506. Hyperlinks associated with the selection may include additional information embedded in a predetermined format. In one implementation, the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes [i.e. mapping the unique identifier to the corresponding storage location for each transactional workflow]” Col. 10 Ln. 39-51 and “The data marts 232 and/or data warehouses may store data about how the data marts 232 and/or data warehouses 234 are organized, where the information can be accessed, and any connections or links between the stored data [i.e. mapping the unique identifier to the corresponding storage location]” Col. 5 Ln. 41-45);
-provide a first option to retrieve details of the plurality of transactional workflows (Clawson, see at least: “the user may enter information through a remote computer online or through an online servicing interface at 512 [i.e. provide a first option] that allows quotes to be retrieved in real-time [i.e. to retrieve details of the plurality of transactional workflows] or after some delay. In some implementations, a household view or dashboard may render and transmit all of the quotes offered to a user through the MPQ quote process 300 to a client via a document. In alternative implementations the household view 514 or dashboard may render all of the quotes offered to a user including quotes offered through other quoting processes to a client” Col. 11 Ln. 14-24);
-receive a request to retrieve details of the plurality of transactional workflows (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page [i.e. a request to retrieve details of the plurality of transactional workflows] or access point at 302 and a search engine 402 shown in FIG. 5. Alternatively, the user may select a hyperlink associated with one or more insurance quotes, insurance products, insurance carriers, etc. that are embedded in an email message 506 [i.e. receive a request to retrieve details of the plurality of transactional workflows]” Col. 10 Ln. 39-47);
-determine the unique identifier of each transactional workflow based on the request (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 [i.e. based on the request] and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes [i.e. determine the unique identifier of each transactional workflow], insurance products, insurance carriers, and/or data associated with one or more insurance quotes. When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process or automate access to secure or private information customized to the user [i.e. determine the unique identifier of each transactional workflow based on the request]. A hyperlink selection may update the MPQ Quote Process 300” Col. 10 Ln. 39-61);
-provide a second option to resume one or more transactional workflows of the plurality of transactional workflows associated with the determined unique identifiers (Clawson, see at least: “once the quote(s) are retrieved, the quote search and search retrieval flow 500 will verify 520 some or all of the data that may vary with the quoted insurance products at 520. In some implementations, errors are identified through a document or a pop help screen. The quote search and search retrieval flow 500 may dynamically generate links or hyperlinks to the pages or documents containing the errors [i.e. provide a second option], which allow the user or representative to access and correct the errors [i.e. to resume one or more transactional workflows of the plurality of transactional workflows associated with the determined unique identifiers] in a fast and sometimes sequential order before transmitting the combined rates page at 404 that may precede the verification of each of the quoted rates” Col. 11 Ln. 26-37);
-in response to a corresponding selection associated with the second option (Clawson, see at least: “once the quote(s) are retrieved, the quote search and search retrieval flow 500 will verify 520 some or all of the data that may vary with the quoted insurance products at 520. In some implementations, errors are identified through a document or a pop help screen. The quote search and search retrieval flow 500 may dynamically generate links or hyperlinks to the pages or documents containing the errors [i.e. in response to a corresponding selection associated with the second option], which allow the user or representative to access and correct the errors in a fast and sometimes sequential order before transmitting the combined rates page at 404 that may precede the verification of each of the quoted rates” Col. 11 Ln. 26-37):
-retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5. Alternatively, the user may select a hyperlink associated with one or more insurance quotes, insurance products, insurance carriers, etc. that are embedded in an email message 506. Hyperlinks associated with the selection may include additional information embedded in a predetermined format. In one implementation, the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes [i.e. retrieve the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows]” Col. 10 Ln. 39-51 and “The data marts 232 and/or data warehouses may store data about how the data marts 232 and/or data warehouses 234 are organized, where the information can be accessed, and any connections or links between the stored data [i.e. the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows]” Col. 5 Ln. 41-45); and
-serve workflow elements based on information recovered from the storage location to resume the one or more transactional workflows of the plurality of transactional workflows (Clawson, see at least: “once the quote(s) are retrieved [i.e. based on information recovered from the storage location], the quote search and search retrieval flow 500 will verify 520 some or all of the data that may vary with the quoted insurance products at 520. In some implementations, errors are identified through a document or a pop help screen. The quote search and search retrieval flow 500 may dynamically generate links or hyperlinks to the pages [i.e. in response to a corresponding selection associated with the second option:] or documents containing the errors, which allow the user or representative to access and correct the errors [i.e. serve workflow elements to resume the one or more transactional workflows of the plurality of transactional workflows] in a fast and sometimes sequential order before transmitting the combined rates page at 404 that may precede the verification of each of the quoted rates” Col. 11 Ln. 26-37 and “The interface 706 may render combined rates screens or forms and common data collection screens or forms [i.e. serve workflow elements to resume the one or more transactional workflows of the plurality of transactional workflows] that may be serviced by local or distributed fill applications 714. The common data management services 708 provide services for storing and retrieving common data that may be processed by the MPQ workflow” Col. 12 Ln. 23-28 and “The data marts 232 and/or data warehouses may store data about how the data marts 232 and/or data warehouses 234 are organized, where the information can be accessed, and any connections or links between the stored data [i.e. recovered from the storage location]” Col. 5 Ln. 41-45).
Clawson does not explicitly disclose updating a retrieval manifest associated with each transactional workflow with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional workflow; and the retrieving of the corresponding storage location of the one or more transactional workflows of the plurality of transactional workflows being in response to selection of second option and being from the retrieval manifest.
Bates, however, teaches insurance workflows (i.e. [0028]), including the known technique of updating a retrieval manifest associated with each transactional data with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional data (Bates, see at least: “The Attestiv server receives back from the distributed ledger an address which can be used to later retrieve that transaction, which it then passes on to the Attestiv app at step 602. The app, in turn, embeds that address into every piece of content 600 which can store its own metadata, and also builds a manifest 606 containing the timestamp of the transaction, the blockchain address [i.e. the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional data], and a list of every content item [i.e. with a unique identifier] and its related edits by filename and content fingerprint” [0089] and “A transaction to be updated is received, including its distributed ledger ID [i.e. associated with each transactional data with a unique identifier]. The associated content list is then retrieved from the transaction 604. A new manifest object is then created [i.e. update a retrieval manifest]” [0090]); and
the known technique of, in response to a corresponding selection associated with the second option: retrieve the corresponding storage location of the one or more transactional data objects of the plurality of transactional data objects from the retrieval manifest (Bates, see at least: “Content metadata may be updated with this distributed ledger ID 536, 600 and saved on the manifest 538, 740 [i.e. from the retrieval manifest]” [0082] and “Content metadata for a transaction may also be updated as per the flow in FIG. 6. A transaction to be updated is received, including its distributed ledger ID [i.e. retrieve the corresponding storage location of the one or more transactional data objects of the plurality of transactional data objects]. The associated content list is then retrieved from the transaction 604. A new manifest object is then created” [0090] and “This approach can also provide visual indication of validation of content objects. Here, the first fingerprint is mapped to an address within an immutable distributed ledger which contains metadata related to the first content object. A second content object is displayed via a user interface [i.e. in response to a corresponding selection associated with the second option:], and a second fingerprint is calculated from the second content object. The immutable distributed ledger is then used to locate the first fingerprint that was previously mapped to the first content object. The first fingerprint and the second fingerprint are compared, and the second data object validated when the two fingerprints match” [0008] and “The first and a second content objects may be selected via a guided user workflow [i.e. in response to a corresponding selection associated with the second option:] to ensure that a user is following a procedure for collecting related objects” [0006]). These known techniques are applicable to the server device of Clawson as they both share characteristics and capabilities, namely, they are directed to insurance workflows.
It would have been recognized that applying the known techniques of updating a retrieval manifest associated with each transactional data with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional data; and, in response to a corresponding selection associated with the second option: retrieve the corresponding storage location of the one or more transactional data objects of the plurality of transactional data objects from the retrieval manifest, as taught by Bates, to the teachings of Clawson would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modifications of updating a retrieval manifest associated with each transactional data with a unique identifier, the retrieval manifest mapping the unique identifier to the corresponding storage location for each transactional data; and, in response to a corresponding selection associated with the second option: retrieve the corresponding storage location of the one or more transactional data objects of the plurality of transactional data objects from the retrieval manifest, as taught by Bates, into the server device of Clawson would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would provide a higher level of security (Bates, [0032]).
Regarding claim 2, Clawson in view of Bates teaches the server device of claim 1. Clawson further discloses:
-wherein the computer executable instructions further cause the processor to:
-track an expiry date, associated with the corresponding transactional workflow of the plurality of transactional workflows (Clawson, see at least: “The business event publisher component 1002 may deliver messages over clients' protocol of choice (e.g., HTTP, email, SMS, etc.) through a “push” mechanism (e.g., at the instigation of the server) that eliminates the need to periodically check or “poll” for new information and updates. Through the business event publisher component 1002 notifications related to time-sensitive information updates [i.e. track an expiry date], mobile applications quote notifications, complete quote notifications, buy confirmations, and many others that may be delivered to subscribing users in real-time” Col. 13 Ln. 32-41 and “A reconciliation and exception process enables real-time resolution of insurance quote issues not resolved by the other MPQ processes. A rules-based exception engine may trigger when a user retrieves an MPQ quote or MPQ quote bundle (both referred to as an MPQ quote) after a rate revision, a user attempts to retrieve an expired MPQ quote (e.g., after one, thirty, and ninety days, for example) [i.e. track an expiry date associated with the corresponding transactional workflow of the plurality of transactional workflows]” Col. 11 56-62);
-mark the corresponding transactional workflow as an expired transactional workflow after the expiry date (Clawson, see at least: “A reconciliation and exception process enables real-time resolution of insurance quote issues not resolved by the other MPQ processes. A rules-based exception engine may trigger when a user retrieves an MPQ quote or MPQ quote bundle (both referred to as an MPQ quote) after a rate revision, a user attempts to retrieve an expired MPQ quote (e.g., after one, thirty, and ninety days, for example) [i.e. the corresponding transactional workflow as an expired transactional workflow after the expiry date]” Col. 11 56-62 Examiner notes that in order for the rules-based exception engine to trigger when the user attempts to retrieve the expired MPQ quote, the MPQ quote must be marked as expired in some way so that the processor can recognize that the MPQ is expired); and
-provide an indication of the expiry date passing to a client device (Clawson, see at least: “Quote data validation may be required due to the expiration of a quote [i.e. an indication of the expiry date passing], the passage of time or a rate revision, etc. If a quote needs validation, in some implementation a user may manually or automatically (e.g., through a quick-fill application that may automatically prefill or suggest responses) verify quote information prior to receipt of a quote [i.e. provide an indication of the expiry date passing to the client device] or a bundle of quotes” Col. 14 Ln. 47-53).
Clawson does not explicitly disclose tracking an expiry date, via the retrieval manifest.
Bates, however, teaches insurance workflows (i.e. [0028]), including the known technique of track data, via the retrieval manifest (Bates, see at least: “All edits that are made are tracked [i.e. track data] and data about the changes is included in the transaction” [0073] and “The Attestiv server receives back from the distributed ledger an address which can be used to later retrieve that transaction, which it then passes on to the Attestiv app at step 602. The app, in turn, embeds that address into every piece of content 600 which can store its own metadata, and also builds a manifest 606 containing the timestamp of the transaction, the blockchain address and its related edits [i.e. track data, via the retrieval manifest] by filename and content fingerprint” [0089] and “A transaction to be updated is received, including its distributed ledger ID. The associated content list is then retrieved from the transaction 604. A new manifest object is then created [i.e. track data, via the retrieval manifest]” [0090]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Clawson with Bates for the reasons identified above with respect to claim 1.
Regarding claim 3, Clawson in view of Bates teaches the server device of claim 2. Clawson further discloses:
-wherein the indication of the expiry date passing is provided in response to attempting to retrieve the expired transactional workflow (Clawson, see at least: “Quote data validation may be required due to the expiration of a quote [i.e. the indication of the expiry date passing], the passage of time or a rate revision, etc. If a quote needs validation, in some implementation a user may manually or automatically (e.g., through a quick-fill application that may automatically prefill or suggest responses) verify quote information prior to receipt of a quote [i.e. is provided in response to attempting to retrieve the expired transactional workflow] or a bundle of quotes” Col. 14 Ln. 47-53 and “A reconciliation and exception process enables real-time resolution of insurance quote issues not resolved by the other MPQ processes. A rules-based exception engine may trigger when a user retrieves an MPQ quote or MPQ quote bundle (both referred to as an MPQ quote) after a rate revision, a user attempts to retrieve an expired MPQ quote (e.g., after one, thirty, and ninety days, for example) [i.e. in response to attempting to retrieve the expired transactional workflow]” Col. 11 56-62).
Clawson does not explicitly disclose retrieving the expired transactional workflow from the retrieval manifest.
Bates, however, teaches insurance workflows (i.e. [0028]), including the known technique of retrieving transactional data from the retrieval manifest (Bates, see at least: “The Attestiv server receives back from the distributed ledger an address which can be used to later retrieve that transaction [i.e. retrieve transactional data], which it then passes on to the Attestiv app at step 602. The app, in turn, embeds that address into every piece of content 600 which can store its own metadata, and also builds a manifest 606 [i.e. from the retrieval manifest] containing the timestamp of the transaction, the blockchain address and its related edits by filename and content fingerprint” [0089]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Clawson with Bates for the reasons identified above with respect to claim 1.
Regarding claim 8, Clawson in view of Bates teaches the server device of claim 1. Clawson further discloses:
-wherein each transactional workflow is saved in a format that permits the server device to execute and complete a binding outcome in obtaining the product or the service upon resumption of the one or more transactional workflows of the plurality of transactional workflows (Clawson, see at least: “Through the retrieval process, the MPQ server or cluster 702 and the MPQ orchestration engine 704 may maintain the validity of multiple quotes [i.e. each transactional workflow is saved in a format that permits the server device to execute and complete a binding outcome in obtaining the product or the service upon resumption of the one or more transactional workflows of the plurality of transactional workflows] through common or different network domains” Col. 14 Ln. 53-56 and “When the data acquisition process is completed, purchase may occur through a single payment that may be distributed to the insurance carriers underwriting the insurance products or they may be paid separately at 406 through a payment module. The optional combined rates page or document at 404 may precede a request for payment to confirm the quoted rates of each elected insurance product [i.e. that permits the server device to execute and complete a binding outcome in obtaining the product or the service upon resumption of the one or more transactional workflows of the plurality of transactional workflows] …When complete, incomplete or abandoned, the process may be confirmed or re-solicited by email messages 408, text messaging, postal services, or through other visual, aural, or tactile medium” Col. 10 Ln. 16-34 and “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse [i.e. each transactional workflow is saved in a format]” Col. 10 Ln. 39-41).
Regarding claim 11, Clawson in view of Bates teaches the server device of claim 1. Clawson further discloses:
-wherein the computer executable instructions further cause the processor to:
-update the storage location with adjusted transactional workflows resulting from the corresponding selection associated with the second option (Clawson, see at least: “The data marts 232 and/or data warehouses may store data about how the data marts 232 and/or data warehouses 234 are organized, where the information can be accessed, and any connections or links between the stored data. Some data marts 232 and/or data warehouses 234 are accessed by the scoring processor 218, and in some systems a data aggregator 240, to aggregate or organize user data, coordinate updates [i.e. update the storage location], identify relationships and/or establish operational and functional links between data gathered from the user in real-time or in near real-time 230 with data acquired from internal data providers 234, third party data providers 236 and/or other sources” Col. 5 Ln. 32-52 and “Whether information is collected off-line, on-line, or through a representative's or agent's interface, once the quote(s) are retrieved, the quote search and search retrieval flow 500 will verify 520 some or all of the data that may vary with the quoted insurance products at 520. In some implementations, errors are identified through a document or a pop help screen. The quote search and search retrieval flow 500 may dynamically generate links or hyperlinks to the pages or documents containing the errors, which allow the user or representative to access and correct the errors [i.e. with adjusted transactional workflows resulting from the corresponding selection associated with the second option] in a fast and sometimes sequential order before transmitting the combined rates page at 404 that may precede the verification of each of the quoted rates” Col. 11 Ln. 25-37); and
-update the corresponding storage to reflect the changes to the adjusted transactional workflows (Clawson, see at least: “The data marts 232 and/or data warehouses may store data about how the data marts 232 and/or data warehouses 234 are organized, where the information can be accessed, and any connections or links between the stored data. Some data marts 232 and/or data warehouses 234 are accessed by the scoring processor 218, and in some systems a data aggregator 240, to aggregate or organize user data, coordinate updates [i.e. update the corresponding storage to reflect the changes], identify relationships and/or establish operational and functional links between data gathered from the user in real-time or in near real-time 230 with data acquired from internal data providers 234, third party data providers 236 and/or other sources” Col. 5 Ln. 32-52 and “Whether information is collected off-line, on-line, or through a representative's or agent's interface, once the quote(s) are retrieved, the quote search and search retrieval flow 500 will verify 520 some or all of the data that may vary with the quoted insurance products at 520. In some implementations, errors are identified through a document or a pop help screen. The quote search and search retrieval flow 500 may dynamically generate links or hyperlinks to the pages or documents containing the errors, which allow the user or representative to access and correct the errors [i.e. to reflect the changes to the adjusted transactional workflows] in a fast and sometimes sequential order before transmitting the combined rates page at 404 that may precede the verification of each of the quoted rates” Col. 11 Ln. 25-37).
Clawson does not explicitly disclose updating the corresponding retrieval manifest to reflect the changes.
Bates, however, teaches insurance workflows (i.e. [0028]), including the known technique of update the corresponding retrieval manifest to reflect the changes (Bates, see at least: “The Attestiv server receives back from the distributed ledger an address which can be used to later retrieve that transaction, which it then passes on to the Attestiv app at step 602. The app, in turn, embeds that address into every piece of content 600 which can store its own metadata, and also builds a manifest 606 containing the timestamp of the transaction, the blockchain address, and a list of every content item and its related edits [i.e. update the corresponding retrieval manifest to reflect the changes] by filename and content fingerprint” [0089] and “A transaction to be updated is received, including its distributed ledger ID [i.e. update the corresponding retrieval manifest to reflect the changes]. The associated content list is then retrieved from the transaction 604. A new manifest object is then created” [0090]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Clawson with Bates for the reasons identified above with respect to claim 1.
Claim 12 recites limitations directed towards a method. The limitations recited in claim 12 are parallel in nature to those addressed above for claim 1, and are therefore rejected for those same reasons set forth above in claim 1.
Regarding claim 13, Clawson in view of Bates teaches the method of claim 12. Clawson further discloses:
-tracking an expiry date associated with the corresponding transactional workflow of the plurality of transactional workflows (Clawson, see at least: “The business event publisher component 1002 may deliver messages over clients' protocol of choice (e.g., HTTP, email, SMS, etc.) through a “push” mechanism (e.g., at the instigation of the server) that eliminates the need to periodically check or “poll” for new information and updates. Through the business event publisher component 1002 notifications related to time-sensitive information updates [i.e. tracking an expiry date], mobile applications quote notifications, complete quote notifications, buy confirmations, and many others that may be delivered to subscribing users in real-time” Col. 13 Ln. 32-41 and “A reconciliation and exception process enables real-time resolution of insurance quote issues not resolved by the other MPQ processes. A rules-based exception engine may trigger when a user retrieves an MPQ quote or MPQ quote bundle (both referred to as an MPQ quote) after a rate revision, a user attempts to retrieve an expired MPQ quote (e.g., after one, thirty, and ninety days, for example) [i.e. tracking an expiry date associated with the corresponding transactional workflow of the plurality of transactional workflows]” Col. 11 56-62);
-marking the corresponding transactional workflow as an expired transactional workflow after the expiry date (Clawson, see at least: “A reconciliation and exception process enables real-time resolution of insurance quote issues not resolved by the other MPQ processes. A rules-based exception engine may trigger when a user retrieves an MPQ quote or MPQ quote bundle (both referred to as an MPQ quote) after a rate revision, a user attempts to retrieve an expired MPQ quote (e.g., after one, thirty, and ninety days, for example) [i.e. the corresponding transactional workflow as an expired transactional workflow after the expiry date]” Col. 11 56-62 Examiner notes that in order for the rules-based exception engine to trigger when the user attempts to retrieve the expired MPQ quote, the MPQ quote must be marked as expired in some way so that the processor can recognize that the MPQ is expired); and
-providing an indication of the expiry date passing to the client device (Clawson, see at least: “Quote data validation may be required due to the expiration of a quote [i.e. an indication of the expiry date passing], the passage of time or a rate revision, etc. If a quote needs validation, in some implementation a user may manually or automatically (e.g., through a quick-fill application that may automatically prefill or suggest responses) verify quote information prior to receipt of a quote [i.e. provide an indication of the expiry date passing to the client device] or a bundle of quotes” Col. 14 Ln. 47-53).
Regarding claim 14, Clawson in view of Bates teaches the method of claim 13. Clawson further discloses:
-wherein the indication of the expiry date passing is provided in response to attempting to retrieve the expired transactional workflow (Clawson, see at least: “Quote data validation may be required due to the expiration of a quote [i.e. the indication of the expiry date passing], the passage of time or a rate revision, etc. If a quote needs validation, in some implementation a user may manually or automatically (e.g., through a quick-fill application that may automatically prefill or suggest responses) verify quote information prior to receipt of a quote [i.e. is provided in response to attempting to retrieve the expired transactional workflow] or a bundle of quotes” Col. 14 Ln. 47-53 and “A reconciliation and exception process enables real-time resolution of insurance quote issues not resolved by the other MPQ processes. A rules-based exception engine may trigger when a user retrieves an MPQ quote or MPQ quote bundle (both referred to as an MPQ quote) after a rate revision, a user attempts to retrieve an expired MPQ quote (e.g., after one, thirty, and ninety days, for example) [i.e. in response to attempting to retrieve the expired transactional workflow]” Col. 11 56-62).
Regarding claim 18, Clawson in view of Bates teaches the method of claim 12. Clawson further discloses:
-wherein the request is initiated from a reminder sent to a client device by the server device (Clawson, see at least: “When a quote is complete, incomplete or abandoned, the occurrence may be confirmed or re-solicited by email messages at 352-356 [i.e. a reminder sent to the client device by the server device], text messaging, by postal mail, or through other visual, aural, or tactile media. Deficient submissions may receive notifications that specify the deficiencies, may prompt the user for information, and/or resolicit the user on a programmed or scheduled basis” Col. 9 Ln. 56-62 and “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5. Alternatively, the user may select a hyperlink associated with one or more insurance quotes, insurance products, insurance carriers, etc. that are embedded in an email message 506 [i.e. wherein the request is initiated from a reminder sent to the client device]” Col. 10 Ln. 39-47).
Claim 20 recites limitations directed towards a non-transitory computer readable medium. The limitations recited in claim 20 are parallel in nature to those addressed above for claim 1, and are therefore rejected for those same reasons set forth above in claim 1.
Claims 4-5 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Clawson, in view of Bates, in further view of Shambach et al. (US 2014/0278582 A1), hereinafter Shambach.
Regarding claim 4, Clawson in view of Bates teaches the server device of claim 2.
Clawson in view of Bates does not explicitly teach the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date.
Shambach, however, teaches presenting multiple insurance quotations (i.e. abstract), including the known technique of the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date (Shambach, see at least: “calendar section 630 may comprise a list of reminders about expiring insurance policies. As illustrated in FIG. 6, the list of reminders comprises a row for each insurance policy purchased by the business-user that includes the number of days until the policy expires [i.e. prior to the expiry date] and an identifier of the insurance policy and/or the type of insurance policy. It should be understood that less, additional, or different information may be provided than illustrated in FIG. 6. For instance, instead of a time until expiration, a date of expiration may be provided. Furthermore, other upcoming events, besides policy expirations, may also be listed (e.g., expiration of quotations for insurance [i.e. of the corresponding transactional workflow], expiration of a request for insurance, expiration of a time to select an insurance policy, etc.). In some embodiments, in addition to or as an alternative to the reminders in calendar section 630, notifications may be sent to the business-user (e.g., via email message and/or text message, automated telephone call, etc.) with reminders of upcoming dates or deadlines [i.e. wherein the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date]” [0083] and “the cut-off or expiration date for submitting quotations [i.e. to enable resumption of the corresponding transactional workflow prior to the expiry date]” [0060]). This known technique is applicable to the server device of Clawson in view of Bates as they both share characteristics and capabilities, namely, they are directed to presenting multiple insurance quotations.
It would have been recognized that applying the known technique of the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date, as taught by Shambach, to the teachings of Clawson in view of Bates would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modification of the indication of the expiry date passing is provided prior to the expiry date to enable resumption of the corresponding transactional workflow prior to the expiry date, as taught by Shambach, into the server device of Clawson in view of Bates would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would provide efficient user interfaces and tools that would further streamline and advance the online insurance application and purchase process (Shambach, [0009]).
Regarding claim 5, Clawson in view of Bates teaches the server device of claim 1. Clawson further discloses:
-wherein the computer executable instructions further cause the processor to:
-predetermined identifying information to perform authentication of a user associated with the request with the server device (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes … When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process [i.e. predetermined identifying information to perform authentication of a user associated with the request with the server device]” Col. 10 Ln. 39-49);
-perform an authentication process based on the predetermined identifying information, wherein the predetermined identifying information is for the entity (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes… When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process [i.e. perform an authentication process based on the predetermined identifying information, wherein the predetermined identifying information is for the entity]” Col. 10 Ln. 39-49); and
-wherein the predetermined identifying information is used to determine the unique identifier (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5. Alternatively, the user may select a hyperlink associated with one or more insurance quotes, insurance products, insurance carriers, etc. that are embedded in an email message 506. Hyperlinks associated with the selection may include additional information embedded in a predetermined format. In one implementation, the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes. When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process [i.e. wherein the predetermined identifying information is used to determine the unique identifier] or automate access to secure or private information customized to the user. A hyperlink selection may update the MPQ Quote Process 300” Col. 10 Ln. 39-61).
Clawson in view of Bates does not explicitly teach providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user; and perform an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device.
Shambach, however, teaches presenting multiple insurance quotations (i.e. abstract), including the known technique of providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user (Shambach, see at least: “FIG. 5A illustrates a user interface comprising inputs for collecting user information for a business-user [i.e. provide an interface and receive, at the interface, predetermined identifying information], according to an embodiment. This user information may comprise a business-user's first name, last name, contact information (e.g., email address, phone number, phone number extension), password (which may be used in conjunction with the business-user's email address, or a separate user identifier entered into an additional field (not shown), as the business-user's login credentials), password confirmation (i.e., to verify the entered password), and/or the like [i.e. predetermined identifying information to perform authentication of a user]” [0073] and “The system may comprise a set of one or more servers 110 (also referred to herein as a "platform") which host and/or execute one or more of the various functions, processes, methods, and/or software modules described herein” [0033]); and
the known technique of performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device (Shambach, see at least: “FIG. 5A illustrates a user interface comprising inputs for collecting user information for a business-user [i.e. received in the interface], according to an embodiment. This user information may comprise a business-user's first name, last name, contact information (e.g., email address, phone number, phone number extension), password (which may be used in conjunction with the business-user's email address, or a separate user identifier entered into an additional field (not shown), as the business-user's login credentials), password confirmation (i.e., to verify the entered password), and/or the like [i.e. perform an authentication process based on the predetermined identifying information, the authentication process authenticating a client device with the server device]” [0073] and “The system may comprise a set of one or more servers 110 (also referred to herein as a "platform") [i.e. with the server device] which host and/or execute one or more of the various functions, processes, methods, and/or software modules described herein” [0033]). These known techniques are applicable to the server device of Clawson in view of Bates as they both share characteristics and capabilities, namely, they are directed to presenting multiple insurance quotations.
It would have been recognized that applying the known techniques of providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user; and performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device, as taught by Shambach, to the teachings of Clawson in view of Bates would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modifications of providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user; and performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device, as taught by Shambach, into the server device of Clawson in view of Bates would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would provide efficient user interfaces and tools that would further streamline and advance the online insurance application and purchase process (Shambach, [0009]).
Claim 15 recites limitations directed towards a method. The limitations recited in claim 15 are parallel in nature to those addressed above for claim 4, and are therefore rejected for those same reasons set forth above in claim 4.
Regarding claim 16, Clawson in view of Bates teaches the method of claim 12. Clawson further discloses:
-predetermined identifying information to perform authentication of a user associated with the request (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes … When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process [i.e. predetermined identifying information to perform authentication of a user associated with the request]” Col. 10 Ln. 39-49);
-performing an authentication process based on the predetermined identifying information, wherein the predetermined identifying information is for the entity (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5…the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes… When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process [i.e. performing an authentication process based on the predetermined identifying information, wherein the predetermined identifying information is for the entity]” Col. 10 Ln. 39-49); and
-wherein the predetermined identifying information is used to determine the unique identifier (Clawson, see at least: “A record of all of the activities that occur through the process may be saved in a local or distributed data warehouse. In some processes, quotes may be retrieved by gathering information about the user through a home page or access point at 302 and a search engine 402 shown in FIG. 5. Alternatively, the user may select a hyperlink associated with one or more insurance quotes, insurance products, insurance carriers, etc. that are embedded in an email message 506. Hyperlinks associated with the selection may include additional information embedded in a predetermined format. In one implementation, the information may include unique identifiers which identify or encodes the recipient's identity and an identifier of one or more insurance quotes, insurance products, insurance carriers, and/or data associated with one or more insurance quotes. When transmitted in an email message, the hyperlink may identify or encode the identity of the recipient, and the selection of which may identify the identity of the recipient to the insurance servers or clusters. In some alternative implementations, the selection of the hyperlink may validate the user and may automate a login process [i.e. wherein the predetermined identifying information is used to determine the unique identifier] or automate access to secure or private information customized to the user. A hyperlink selection may update the MPQ Quote Process 300” Col. 10 Ln. 39-61).
Clawson in view of Bates does not explicitly teach providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user; and performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device.
Shambach, however, teaches presenting multiple insurance quotations (i.e. abstract), including the known technique of providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user (Shambach, see at least: “FIG. 5A illustrates a user interface comprising inputs for collecting user information for a business-user [i.e. provide an interface and receive, at the interface, predetermined identifying information], according to an embodiment. This user information may comprise a business-user's first name, last name, contact information (e.g., email address, phone number, phone number extension), password (which may be used in conjunction with the business-user's email address, or a separate user identifier entered into an additional field (not shown), as the business-user's login credentials), password confirmation (i.e., to verify the entered password), and/or the like [i.e. predetermined identifying information to perform authentication of a user]” [0073] and “The system may comprise a set of one or more servers 110 (also referred to herein as a "platform") which host and/or execute one or more of the various functions, processes, methods, and/or software modules described herein” [0033]); and
the known technique of performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device (Shambach, see at least: “FIG. 5A illustrates a user interface comprising inputs for collecting user information for a business-user [i.e. received in the interface], according to an embodiment. This user information may comprise a business-user's first name, last name, contact information (e.g., email address, phone number, phone number extension), password (which may be used in conjunction with the business-user's email address, or a separate user identifier entered into an additional field (not shown), as the business-user's login credentials), password confirmation (i.e., to verify the entered password), and/or the like [i.e. perform an authentication process based on the predetermined identifying information, the authentication process authenticating a client device with the server device]” [0073] and “The system may comprise a set of one or more servers 110 (also referred to herein as a "platform") [i.e. with the server device] which host and/or execute one or more of the various functions, processes, methods, and/or software modules described herein” [0033]). These known techniques are applicable to the method of Clawson in view of Bates as they both share characteristics and capabilities, namely, they are directed to presenting multiple insurance quotations.
It would have been recognized that applying the known techniques of providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user; and performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device, as taught by Shambach, to the teachings of Clawson in view of Bates would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modifications of providing an interface and receive, at the interface, predetermined identifying information to perform authentication of a user; and performing an authentication process based on the predetermined identifying information received in the interface, the authentication process authenticating a client device with the server device, as taught by Shambach, into the method of Clawson in view of Bates would have been recognized by those of ordinary skill in the art as resulting in an improved method that would provide efficient user interfaces and tools that would further streamline and advance the online insurance application and purchase process (Shambach, [0009]).
Claims 6-7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Clawson, in view of Bates, in further view of Shambach, in further view of Ramaswamy et al. (US 2020/0167861 A1), hereinafter Ramaswamy.
Regarding claim 6, the combination of Clawson/Bates/Shambach teaches the server device of claim 5.
The combination of Clawson/Bates/Shambach does not explicitly teach the predetermined identifying information comprising limited information to avoid storing personally identifiable information during a current session and not returning the personally identifiable information until the client device is authenticated.
Ramaswamy, however, teaches an electronic transaction (i.e. [0048]), including the known technique of the predetermined identifying information comprises limited information to avoid storing personally identifiable information during a current session and not returning the personally identifiable information until the client device is authenticated (Ramaswamy, see at least: “The customer will be asked to enter their mobile phone number and press a button displayed on the screen that says “Verify” [i.e. the predetermined identifying information comprises limited information to avoid storing personally identifiable information during a current session]. The next screen presented will ask the customer to enter a unique code. The customer will also receive a text message on their phone or mobile computing device 130 that contains a code (e.g. a six-digit number). The customer enters the unique code and presses a button on the screen that says “Verify”. If the verification process determines that the customer does in fact own the mobile number entered, the application will then present a screen that displays a confirmation of “Verified”. If the verification process determines that the customer is not the true owner of the mobile number entered (e.g. number incorrectly entered; potential fraud), the application will then present a screen that displays a message that mobile number ownership could not be verified [i.e. and not returning the personally identifiable information until the client device is authenticated]. The customer may be prompted to “try again”, and if after a certain number of attempts the mobile number still cannot be verified, the application may stop prompting for retries and may ask the customer to try again later” [0053]). This known technique is applicable to the server device of the combination of Clawson/Bates/Shambach as they both share characteristics and capabilities, namely, they are directed to an electronic transaction.
It would have been recognized that applying the known technique of the predetermined identifying information comprises limited information to avoid storing personally identifiable information during a current session and not returning the personally identifiable information until the client device is authenticated, as taught by Ramaswamy, to the teachings of the combination of Clawson/Bates/Shambach would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modification of the predetermined identifying information comprises limited information to avoid storing personally identifiable information during a current session and not returning the personally identifiable information until the client device is authenticated, as taught by Ramaswamy, into the server device of the combination of Clawson/Bates/Shambach would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would establish a secure communication session with the customer and provide a streamlined application process for the customer that is as convenient and seamless as possible (Ramaswamy, [0040]).
Regarding claim 7, the combination of Clawson/Bates/Shambach/Ramaswamy teaches the server device of claim 6.
The combination of Clawson/Bates/Shambach does not explicitly teach the limited information comprising a phone number used to initiate the authentication process using a security code.
Ramaswamy, however, teaches an electronic transaction (i.e. [0048]), including the known technique of the limited information comprising a phone number used to initiate the authentication process using a security code (Ramaswamy, see at least: “The customer will be asked to enter their mobile phone number [i.e. wherein the limited information comprises a phone number] and press a button displayed on the screen that says “Verify”. The next screen presented will ask the customer to enter a unique code. The customer will also receive a text message on their phone or mobile computing device 130 that contains a code (e.g. a six-digit number). The customer enters the unique code and presses a button on the screen that says “Verify”. [i.e. used to initiate the authentication process using a security code] If the verification process determines that the customer does in fact own the mobile number entered, the application will then present a screen that displays a confirmation of “Verified”” [0053]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the combination of Clawson/Bates/Shambach with Ramaswamy for the reasons identified above with respect to claim 6.
Claim 17 recites limitations directed towards a method. The limitations recited in claim 17 are parallel in nature to those addressed above for claim 6, and are therefore rejected for those same reasons set forth above in claim 6.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Clawson, in view of Bates, in further view of Bryant et al. (US 2022/0129926 A1), hereinafter Bryant.
Regarding claim 9, Clawson in view of Bates teaches the server device of claim 1.
Clawson does not explicitly disclose the retrieval manifest comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module.
Bates, however, teaches insurance workflows (i.e. [0028]), including the known technique of the retrieval manifest comprising data (Bates, see at least: “The Attestiv server receives back from the distributed ledger an address which can be used to later retrieve that transaction, which it then passes on to the Attestiv app at step 602. The app, in turn, embeds that address into every piece of content 600 which can store its own metadata, and also builds a manifest 606 containing the timestamp of the transaction, the blockchain address, and a list of every content item [i.e. the retrieval manifest comprises data] and its related edits by filename and content fingerprint” [0089]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Clawson with Bates for the reasons identified above with respect to claim 1.
Clawson in view of Bates does not explicitly teach the retrieval manifest comprises preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module.
Bryant, however, teaches receiving quotes (i.e. [0021]), including the known technique of data storage comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module (Bryant, see at least: “The machine-learning component 124 can access a question set 308 and provider data 306 associated with the product providers 134 of FIG. 1 to customize the question selection and presentation as part of an interview process. The machine-learning component 124 can select an order of questions from the question set 308 and may eliminate some questions or expand the questions to cover additional products. User experience can be customized by selecting between various types of input interfaces, such as pulldown lists, radio buttons, checkboxes, free-form text, voice-enabled data entry, natural language interfaces, and the like. Initial configurations can be established based on preferences of operators of the websites 118. The machine-learning component 124 can modify the user experience in presenting options in the presentation component 304. For example, the order of presenting offers can be modified to promote offers that have had a higher rate of acceptance based on learned patterns [i.e. determined by analyzing client data using a machine learning module]. Geographic region, household size, credit rating, driving data, billing, retention, coverage level, engagement, and other such factors may be observed by the machine-learning component 124 [i.e. determined by analyzing client data using a machine learning module] to adjust result ordering and display attributes in the presentation component 304 [i.e. comprising preference data for displaying the plurality of transactional workflows] … As the machine-learning component 124 observes results, the provider data 306 and/or question set 308 can be updated. The provider data 306 and/or question set 308 can be stored, for example, in databases 120 [i.e. data storage comprising preference data] of FIG. 1” [0033] and “Preferences may be stored in the settings database 830 [i.e. data storage comprising preference data]” [0045] and “alternative database structures to those described may be readily employed, and (ii) other memory structures besides databases may be readily employed” [0078]). This known technique is applicable to the server device of Clawson in view of Bates as they both share characteristics and capabilities, namely, they are directed to receiving quotes.
It would have been recognized that applying the known technique of data storage comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module, as taught by Bryant, to the teachings of Clawson in view of Bates would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modification of data storage comprising preference data for displaying the plurality of transactional workflows determined by analyzing client data using a machine learning module, as taught by Bryant, into the server device of Clawson in view of Bates would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would enhance the user experience (Bryant, [0021]).
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Clawson, in view of Bates, in further view of Pilot et al. (US 2015/0248730 A1), hereinafter Pilot.
Regarding claim 10, Clawson in view of Bates teaches the server device of claim 1.
Clawson in view of Bates does not explicitly teach corresponding storage locations storing each transactional workflow based on graphs that atomize the process into a plurality of nodes.
Pilot, however, teaches an electronic claim scoping method (i.e. abstract), including the known technique of corresponding storage locations storing each transactional workflow based on graphs that atomize the process into a plurality of nodes (Pilot, see at least: “A workflow generation module 166 is configured to generate workflows that administer a claim scoping process for each insurance claim passed into the core system 106. Once generated, the workflow directs actions taken to process the claim. Embodiments of a workflow include a kind of flowchart or “form,” which is presented via a claim scoping software application 119 on a computing device such as the portable computing device 116 associated with a claims adjuster 114. The flowchart comprises a plurality of “nodes” generally associated with flowcharts, such as labels, decision nodes, action nodes, branches, and the like [i.e. based on graphs that atomize the process into a plurality of nodes]. Many of the nodes (e.g., decision nodes, action nodes) are arranged to receive nodal user input from the developer that is generating the workflow and nodal user input from a claims adjuster that is later executing the workflow” [0089] and “The workflow generation module 166 is configured to create, control, edit, and manage workflow processes. The workflows are created in the workflow generation module 166 using a flowchart-based interface [i.e. based on graphs] and saved to a workflow database [i.e. wherein corresponding storage locations store each transactional workflow]. A workflow can be created from scratch, or one or more workflows can be retrieved (e.g., from the workflow database) and used as a template to build a different workflow. These features may permit faster and more efficient workflow generation” [0093]). This known technique is applicable to the server device of Clawson in view of Bates as they both share characteristics and capabilities, namely, they are directed to an electronic claim scoping method.
It would have been recognized that applying the known technique of corresponding storage locations storing each transactional workflow based on graphs that atomize the process into a plurality of nodes, as taught by Pilot, to the teachings of Clawson in view of Bates would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar server devices. Further, adding the modification of corresponding storage locations storing each transactional workflow based on graphs that atomize the process into a plurality of nodes, as taught by Pilot, into the server device of Clawson in view of Bates would have been recognized by those of ordinary skill in the art as resulting in an improved server device that would allow workflows to be customized to the process (Pilot, [0096]).
Claim 19 recites limitations directed towards a method. The limitations recited in claim 19 are parallel in nature to those addressed above for claim 10, and are therefore rejected for those same reasons set forth above in claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
-Hatch et al. (US 2021/0264535 A1) teaches a quote comparison tool.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIELLE E WEINER whose telephone number is (571)272-9007. The examiner can normally be reached M-F 8:30-5:00.
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, Maria-Teresa (Marissa) Thein can be reached at 571-272-6764. 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.
/ARIELLE E WEINER/ Primary Examiner, Art Unit 3689