DETAILED ACTION
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 .
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 filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual 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/apply/applying-online/eterminal-disclaimer.
Claims 1-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 12354168. Although the claims at issue are not identical, they are not patentably distinct from each other.
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-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (abstract idea) without significantly more.
Under the broadest reasonable interpretation, the following claim terms are presumed to have their plain meaning consistent with the specification as it would be interpreted by one of ordinary skill in the art. MPEP § 2111.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03) Claim 1 and 21 recite an apparatus (product), which is a statutory category of invention (Step 1: YES). Claim 11 recites a process, which is a statutory category of invention (Step 1: YES).
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a)). Yes.
The claims are analyzed to determine whether it is directed to a judicial exception. The following claims identify the limitations that recite additional elements in bold and the abstract idea without bold. Underlined claim limitations denote newly added claim limitations:
Claim 1, 11 and 21 recite a mobile computing device communicating with a central server to manage a digital wallet card within a mobile wallet on the mobile computing device, the mobile computing device comprising a processor and a storage device storing instructions, which when executed by the processor, configure the mobile computing device to: periodically send communication messages to the central server, to determine whether there is an update to policy information associated with the digital wallet card stored on the central server; and automatically generate in real-time, upon receiving from the central server an indication that the update exists in response to the communication messages, a notification displayed on a user interface of the mobile computing device comprising an embedded website update link for automatically downloading the update from the central server. These limitations, as drafted, under its broadest reasonable interpretation, covers performance via certain methods of organizing human activity, but for the recitation of generic computer components. Under human activity, the limitations are fundamental economic practice. More specifically, under fundamental economic practice, the claims involve insurance. Also, the limitations are commercial interactions, such insurance administration and business relations (such as commercial communication with a policyholder) as well as managing interactions between people (Notifying a policyholder of a policy change is a long-standing practice in the insurance industry). Accordingly, the claim recites an abstract idea. The mere recitation of generic computer components in the claims does not necessarily preclude that claim from reciting an abstract idea. (Step 2A-Prong 1: Yes. The claims recite an abstract idea).
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d)). No.
The above judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a mobile computing device, a central server, a digital wallet card, a processor, a storage device, instructions, computer implemented method, computer program product, non-transient storage device, communication messages, embedded website update link, notification display, and user interface. The additional elements of a mobile computing device, a central server, a digital wallet card, a processor, a storage device, instructions, computer implemented method, computer program product, non-transient storage device, communication messages, embedded website update link, are just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)). The additional elements of notification display and user interface are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of Graphical User Interfaces (MPEP 2106.05(h)). The computer components are recited at such a high-level of generality (i.e. as a generic computer components) such that it amounts to no more than mere instructions to apply the exception using generic computer components, and the claims fail to recite technological detail as to how the step of the judicial exception is accomplished. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. (Step 2A-Prong 2: NO. The judicial exception is not integrated into a practical application).
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05). No.
The claims are next analyzed to determine if there are additional claim limitations that individually, or as an ordered combination, ensure that the claim amounts to significantly more than the abstract ideas (whether claim provides inventive concept). As discussed with respect to Step 2A2 above, the additional elements of (a mobile computing device, a central server, a digital wallet card, a processor, a storage device, instructions, computer implemented method, computer program product, non-transient storage device, communication messages, embedded website update link, notification display, and user interface) in the claims amount to no more than mere instructions to apply the exception using a generic computer component and generally linking the use of GUI’s to judicial exception. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component and generally linking the use of GUI’s to judicial exception cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea itself. Therefore, the claims do not amount to significantly more than the recited abstract idea (Step 2B: NO; The claims do not provide significantly more, and are not patent eligible).
Claim 2 and 12 recite wherein the communication messages comprise a status check message, the status check message comprising current account information in the digital wallet card for determination of whether the update exists for the digital wallet card based on the policy information stored on the central server, wherein the current account information comprises insurance policy information. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of communication messages, digital wallet card, and central server are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 3 and 13 recite wherein upon receiving the notification and the embedded website update link, the instructions configure the mobile computing device to automatically select the embedded website update link and thereby automatically update the digital wallet card to an updated digital wallet card based on said update including policy amendment information reflecting a policy change for an account associated with the digital wallet card. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of embedded website update link, mobile computing device, digital wallet card and updated digital wallet card are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 4 and 14 recites wherein the instructions further configure the mobile computing device to: store a set of customizable notification settings on the storage device of the mobile computing device, the notification settings displayed and customizable via the user interface of the mobile computing device for defining how the notification of the update is displayed on the user interface. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of instructions, and mobile computing device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of notification setting displayed and customizable and user interface are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of graphical user interface (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 5 and 15 recites, wherein the instructions configure the mobile computing device to communicate the notification settings, customizable via the user interface of the mobile computing device, with the central server for customizing the notifications. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of instructions, mobile computing device, communicate the notification settings, and customizing the notifications are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of user interface, and customizable are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of graphical user interface (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 6 and 16 recite wherein the notification settings communicated with the central server defines at least one of: a frequency with which to receive the notification; and an additional receipt method for displaying the notification on the mobile computing device, the receipt method consisting of: email, SMS, and presented on a software application on the mobile computing device. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of central server, mobile computing device, email and SMS are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of displaying the notification, presented on a software application on the mobile computing device are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of graphical user interface (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 7 and 17 recite wherein the digital wallet card represents a physical card and is created on the mobile wallet by the instructions configuring the mobile computing device to: retrieve a policy information package from the central server with the policy information comprising details for an account associated with the digital wallet card; and format the retrieved policy information according to a format information scheme retrieved from a content management system (CMS) specific to display capabilities for the mobile computing device. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of digital wallet card, mobile wallet, instructions, mobile computing device, central server, and content management system (CMS) are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 8 and 18 recite wherein the digital wallet card represents an electronic representation of a vehicle insurance card. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of the digital wallet card are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of the electronic representation are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of graphical user interface (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 9 and 19 recite wherein the digital wallet card is displayed on a lock screen of the mobile computing device without unlocking the mobile computing device. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of the digital wallet card and mobile computing device are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of the lock screen of the mobile computing device are generally linking the use of the judicial exception to a particular technological environment or field of use, for the particular technology of graphical user interface (MPEP 2106.05(h)), and the claim fails to recite technological detail as to how the step of the judicial exception is accomplished. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim 10 and 20 recite further comprising sharing updates to the digital wallet card with other related mobile computing devices having a respective digital wallet card associated with a shared policy. These limitations are also part of the abstract idea identified in claim 1 and 11, and the additional elements of the digital wallet card, and other related mobile computing devices are addressed in the Steps 2A2 and B as just applying generic computer components to the recited abstract limitations (MPEP 2106.05(f)) as in the claim 1 and 11 analysis above. Therefore, this claim is similarly rejected under the same rationale as claim 1 and 11, supra.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 11 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Tye US 11861721, in view of Carlson US 10636096.
Regarding Claim 1, 11 and 21, Tye discloses a mobile computing device communicating with a central server to manage a digital wallet card within a mobile wallet on the mobile computing device, the mobile computing device comprising a processor and a storage device storing instructions, which when executed by the processor (Tye, Fig. 2, mobile device 202 with mobile application 208, data store 210 storing insurance-image card 216 that communicates with insurance system 204; See also Fig. 3, disclosing creating and storing of insurance card), configure the mobile computing device to:
periodically send communication messages to the central server, to determine whether there is an update to policy information associated with the digital wallet card stored on the central server (Tye, “The mobile application 208 may be configured to automatically request the insurance card image 216 from the insurance system 204 on a periodic basis (e.g., once a month, once a quarter, or once a year”; “The mobile application 208 may also periodically query the insurance system 204 to determine whether a new insurance card image 216 is available”; “the mobile application 208 may query the insurance system 204 each time the mobile application launches in order to determine whether a new insurance card image 216 is available”; A new card is generated when new customer information is available… “Whenever the customer information 236 is updated, the image generator 226 may generate a new insurance card image 232 that includes the updated customer information”…” The image generator 226 may store the new insurance card image 232 at the data store 234 such that the new insurance card image replaces an existing insurance card image 216 for the insurance customer. The insurance system 204 may then provide the new insurance card image 232 to the mobile device 202 for storage or display. In this way, the insurance card image 216 stored at the data store 234 of the insurance system 204 and at the data store 210 of the mobile device 202 may include the most up-to-date information 236 associated with the insurance customer”);
and automatically generate in real-time, upon receiving from the central server an indication that the update exists in response to the communication messages, a notification displayed on a user interface of the mobile computing device (Tye, A server indication indicates that an update exists, which then notifies the mobile device UI, with a user-selectable control that causes a request to the server and download of the new card; “the distributor 230 may simply provide a push notification message that informs the insurance customer a new insurance card image 232 is available from the insurance system 204. In response to receipt of the push notification message, the mobile application 208 at the mobile device 202 may present the push notification message to the user and allow the user to accept or deny the new insurance card image 232. If the user selects to receive the new insurance card image 232, the mobile application 208 may submit a request to the insurance system 204 for the new insurance card image, and the insurance system may deliver the new insurance card image to the mobile device in response to receipt of the request.”).
Tye fails to disclose that the notification update comprises an embedded website update link for automatically downloading the update from the central server. However, Carlson discloses automatically altering a insurance policy through push/pull updates via a renew link displayed on a user device (Carlson, Fig. 8, “Click to Renew”; “The alert mechanism 830 can also include a deep link (e.g., “Click to RENEW”) that enables a user to renew their policy regardless of which state the policy is in.”; “because each policy element field is configured to present the dynamic data elements and because the dynamic data elements are based on at least the policy information, the card management system and method can automatically detect policy information updates and actively alter (via push or pull methods) the dynamic data elements to reflect the policy information updates”; Examiner notes, that the currently recited “for automatically downloading the update from the central server” in Claim 1 and 11 is written as “intended use.”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the update link of for downloading a renewable policy from Carlson. Doing so allows ease-of-use for the user, making it easy to update policy accordingly and when necessary from the touch-of-a-button.
Claim(s) 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Tye US 11861721, in view of in view of Carlson US 10636096, as applied to claims 1 and 11 above, further in view of Evans US 20140279474.
Regarding Claim 2 and 12 modified Tye discloses a communication message, as well as current account information with insurance policy information, but fails to disclose a status check message, where the status check message comprises current account information in the digital wallet card for determination of whether the update exists for the digital wallet card based on the policy information stored on the central server. However, Evans discloses sending a status update message based on an update request 447 from an merchant server 420 that updates a wallet entry 451 based on usage policy rules for the user account 449 (Fig. 4).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the status message of the determined account information based on user rules of Evans. Doing so enables the user to better understand limits to account healthcare treatment usage (Para. 25, Para. 115), as well as better account for balance limits and whether registration still needs to occur in order to receive the healthcare service (Para. 115, “the user may be provided the option to register with MPOC service when the user enrolls in a healthcare benefit program”; Para. 119 and 120).
Claim(s) 4-6 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Tye US 11861721, in view of in view of Carlson US 10636096, as applied to claims 1 and 11 above, further in view of Hughes US 10839354.
Regarding Claim 4 and 14 modified Tye discloses sending user notifications when a policy change is needed (Carlson, “the management application 112 can also send notifications to the user/insured at the time of a policy change (e.g., renewal or expiration of the policy”) but fails to disclose where the instructions further configure the mobile computing device to: store a set of customizable notification settings on the storage device of the mobile computing device, the notification settings displayed and customizable via the user interface of the mobile computing device for defining how the notification of the update is displayed on the user interface. However, Hughes discloses an option for user notifications on an iOS for auto insurance, where the user to select to opt in or opt out of the notification (“iOS auto insurance customers may have the ability to turn on Local Notifications to be notified when their saved insurance card(s) have expired (or are about to expire). An auto insurance customer may have opted in to access their insurance card when they are not logged in, and may be able to turn on local notifications. A customer may turn on notifications for expired insurance cards whether they are logged in or logged out (as long as they had previously logged in to turn on saved data). Users may be prompted to confirm notifications the first time they turn them on. There may be a difference in the flow across iOS operating systems, and the user may receive different messaging based upon operating system”), and may tailor the notifications via text, banner or alerts (“Customers may tailor local notifications to their preference (Badges, Banners, Alerts, etc.”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the tailored notification setting based on insurance update message. Doing so allows the user to be notified prior to expiration of an insurance card, or when it is about to expire (Hughes, “OS auto insurance customers may have the ability to turn on Local Notifications to be notified when their saved insurance card(s) have expired (or are about to expire”).
Regarding Claim 5 and 15 modified Tye fails to disclose wherein the instructions configure the mobile computing device to communicate the notification settings, customizable via the user interface of the mobile computing device, with the central server for customizing the notifications. However, Hughes discloses allowing the user to opt-in for notification (Hughes, “iOS auto insurance customers may have the ability to turn on Local Notifications to be notified when their saved insurance card(s) have expired (or are about to expire)”) with the user opting in on their PocketAgent from device setting (“To begin receiving notifications from Pocket Agent®, a customer must ensure that they have turned on Pocket Agent® notifications in their Device Settings”) and being able to tailor the notifications (Hughes, “From the settings menu, the customer may tap on Notifications, scroll until they locate Pocket Agent®, and make sure they are allowing notifications for Pocket Agent®. Customers may tailor local notifications to their preference (Badges, Banners, Alerts, etc.))”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the tailored customizable notification settings based on insurance update message. Doing so allows the user to be notified prior to expiration of an insurance card, or when it is about to expire (Hughes, “OS auto insurance customers may have the ability to turn on Local Notifications to be notified when their saved insurance card(s) have expired (or are about to expire”).
Regarding Claim 6 and 16 Tye discloses wherein the notification settings communicated with the central server defines at least one of: a frequency with which to receive the notification and presented on a software application (Tye, “The mobile application 208 may be configured to automatically request the insurance card image 216 from the insurance system 204 on a periodic basis (e.g., once a month, once a quarter, or once a year)”, but fails to disclose and an additional receipt method for displaying the notification on the mobile computing device, the receipt method consisting of: email, and SMS. However, Carlson discloses notifications that can include SMS and email (Carlson, “ Examples of notifications may include, but are not limited to, text messaging (e.g., short message service), audio alerts (e.g., telephone calls, cellphone calls, VoIP calls, voicemails, loudspeaker announcements, etc.), electronic mail (e.g., post office protocol, internet message access protocol, simple mail transfer protocol)”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the notification methods of Carlson. Doing so allows the user to have more methods of delivered communications regarding insurance status, in order to better information of future events (Carlson, “The alert mechanism 830 can comprise a warning of future events (e.g., ‘this policy will expire at a future date’), an indication of a present state (e.g., ‘this policy will expire today’), and/or an indication of a past event (e.g., ‘this policy expired today’).”).
Claim(s) 7-8 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Tye US 11861721, in view of in view of Carlson US 10636096, as applied to claims 1 and 11 above, further in view of Meoli US 93258007.
Regarding Claim 7 and 17 modified Tye teaches using wherein the digital wallet card represents a physical card and is created on the mobile wallet by the instructions (Tye, “Hardcopy insurance cards are associated with a number of disadvantages. A driver may misplace a hardcopy insurance card or forget to place the hardcopy insurance card in the vehicle. An insurance company must continually replace hardcopy insurance cards as insurance policies are renewed and insurance information changes. Moreover, an insurance company is not able to determine when a driver accesses the hardcopy insurance card, e.g., following a vehicle collision. Instead, the driver may initiate contact with the insurance company when insurance services are needed”) but fails to disclose configuring the mobile computing device to: retrieve a policy information package from the central server with the policy information comprising details for an account associated with the digital wallet card; and format the retrieved policy information according to a format information scheme retrieved from a content management system (CMS) specific to display capabilities for the mobile computing device. However, Meoli discloses a processor that receives formatting information associated with an identification required organization from a digital identification sever (Meoli, “the processor may be configured to receive formatting information associated with an identification-requiring organization from a digital identification server. Further, the processor may be configured to receive identification information from the digital identification server”) that generates the digital ID cased on identification information and formatting information and information package from an IRO (“generate the digital identification card based on the identification information and the formatting information”; policy information package - “Once the identification information has been transferred to device 530 (Step 650), device 530 may recognize the metadata of the identification information and use it to populate a form, database, etc., used by IRO 106 (Step 670). Alternatively, IRO 106 may store the identification information for later use (Step 660).”… “The identification information may contain metadata identifiable and compatible with the components, infrastructure, and other elements of device 530 and/or IRO 106 such that the identification information can be used by the systems of IRO 106.”) and to format the information based on the physical card (“generate the digital identification card based on formatting information associated with the identification-requiring organization, such as, for example, field position, field size, field shape, type of font, font size, color of text, color of field, color of background, transparency of text, transparency of color, transparency of field, text to display, image information, and watermark information.”; Fig. 3, 310, 320, and 330; Template 11A, for figures 8-10; See also Fig. 11B, for fields of different types, with database 1100 as the content management system) and update accordingly based on changes to identification information and formatting information (“the processor of the mobile device may be further configured to update the digital identification card based on changes to the identification information or changes to the formatting information associated with the identification-requiring organization”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the formatting capabilities and content management capabilities of Meoli. Doing so helps the information displayed in the user device be easily accessible by the user, and for following formatting standards set by the information-requiring organization and allows re-formatting when information standards change (Meoli, “Certain disclosed embodiments include methods and systems for providing digital identification cards to account holders' mobile devices which conform to the formatting standards set by an identification-requiring organization (IRO)”; “the digital identification card may be re-formatted if an IRO's formatting standards or information requirements change, or a new identification card may be generated to comply with a new IRO's formatting standards and information requirements. In one embodiment, a digital identification mobile app provides an IRO with identification information or a subset of the identification information”; “In certain embodiments, IROs may be any type of organization that may require identification information to be formatted in a particular way for acceptance by the IRO. In some embodiments, the IRO issues identification cards with the identification information in the format it requires. In other embodiments, the IRO may rely on a third party to issue identification cards in the format the IRO requires. The IRO requiring the identification (or the third party supplying the identification) may include, for example, a government agency (e.g., a state's Department of Motor Vehicles, etc.), a business (e.g., an insurance company, etc.), or an organization (e.g., AAA, etc.).”)
Regarding Claim 8 and 18 modified Tye discloses where the digital wallet card represents an electronic representation of a vehicle insurance card (Tye, Element 240, “The customer information 236 may, for example, include: information 238 relating to one or more drivers insured by the insurance company, e.g., the name, age, driver's license number, address, and contact information of a driver; information 240 relating to the vehicles associated with the insurance customer, e.g., the make, model, year, and color of a vehicle; and information 242 relating to the insurance policies associated with the customer, e.g., the insurance provider name, insurance provider contact information, insurance policy number, effective dates, and vehicles insured under the insurance policy.”… “It will be appreciated that the customer information 236 may include additional or alternative information relating to the insurance customer, a vehicle associated with the insurance customer, or an insurance policy associated with the insurance customer. The insurance card image 216 may include some or all of this example driver information 236.”).
Claim(s) 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tye US 11861721, in view of in view of Carlson US 10636096, as applied to claims 1 and 11 above, further in view of Van Os US 10255595.
Regarding Claim 9 and 19 modified Tye fails to disclose wherein the digital wallet card is displayed on a lock screen of the mobile computing device without unlocking the mobile computing device. However, Van Os discloses a digital wallet on a locked screen (Fig. 13B and 13C), a digital wallet card is displayed on a locked screen (Fig. 13B shows locking, while 13C shows mobile device in a locked state; “At FIG. 13C, in accordance with a determination that the fingerprint is consistent with the enrolled fingerprint and a determination that the set of one or more criteria is met (e.g., a double-press of the physical input mechanism 204 was detected), the device transitions to a second short-range communication radio payment mode different from the first short-range communication radio payment mode”… “As illustrated in FIG. 13C, the user interface of the device while in the second short-range communication radio payment mode may include an indication 1302 of a payment account to be used for a payment transaction. The user interface may also include one or more affordance 1304, which when activated, change the payment account to be used for a payment transaction. While in the second short-range communication radio payment mode, the device will enabled a contactless payment terminal to engage in a payment transaction by transmitting payment account information to the contactless payment terminal. Thus, to make a payment using their electronic device while it is in a locked state”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the displayed digital wallet payment in locked phone state. Doing so allows transaction execution without the unease-of-use and inefficiency of requiring a complete unlocking of the device.
Claim(s) 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tye US 11861721, in view of in view of Carlson US 10636096 and Meoli US 93258007, as applied to claim 7 and 17 above, further in view of Belleville US 20190073665.
Regarding Claim 10 and 20 modified Tye discloses that customer information 230 can relate to multiple drivers of a insurance policy (Tye, “As shown by way of example in FIG. 2 , the data store 234 stores customer information 236 for the insurance customers of the insurance company. The customer information 236 may, for example, include: information 238 relating to one or more drivers insured by the insurance company, e.g., the name, age, driver's license number, address, and contact information of a driver”), but fails to disclose further comprising sharing updates to the digital wallet card with other related mobile computing devices having a respective digital wallet card associated with a shared policy. However, Belleville discloses an instance identifier that is associated with one ore more devices in digital wallet context (“an instance identifier can be associated with more than one device identifier, for example indicating that an asset derived from a logical instance has been installed on multiple discrete devices (e.g., any two installations of the same instance on discrete devices will be associated with different device identifiers”) with an update engine 238 that can push new assets to all devices (Para. 85, “Update engine 238 is configured to facilitate the updating of digital wallet assets. Updating digital wallet assets can include updating the content (e.g., images, text, etc.) of logical instances, the assets derived from the instances, and the installations of the derived assets”… “If Alice has her boarding pass installed on both her smartphone and tablet, location event information collected on her smartphone can be used to influence updating of both the boarding pass on the smartphone as well as the boarding pass installed on the tablet.”).
It would have been obvious to one of ordinary skill in the art, before the effective date of filing, to have modified Tye with the digital wallet across multiple devices associated with a same policy. Doing so allows ease-of-use when one update occurs between all of the devices, preventing the user from having to update multiple different devices at different times.
Allowable Subject Matter
Claims 3 and 13 would be allowable if rewritten or amended to overcome the rejection(s) under 35 U.S.C. 101; set forth in the above Office Action. The following is a statement of reasons for the indication of allowable subject matter: The prior art fails to disclose: wherein upon receiving the notification and the embedded website update link, the instructions configure the mobile computing device to automatically select the embedded website update link and thereby automatically update the digital wallet card to an updated digital wallet card based on said update including policy amendment information reflecting a policy change for an account associated with the digital wallet card. However, the claims still do not overcome the 101 rejection.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON M DUCK whose telephone number is (469)295-9049. The examiner can normally be reached 8am - 5pm.
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, Michael Anderson can be reached at 571-270-0508. 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.
/BRANDON M DUCK/Examiner, Art Unit 3693
Prosecution Insights