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 .
The following is a Final Office Action in response to communications received on 4/6/2026. Claims 1, 5-16, 18-22 are currently pending and have been examined. Claims 1, 5, 6, 11, 18, have been amended. Claims 2-4 and 17 have been cancelled. Claims 21 and 22 have been added.
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.
Claims 1, 7-11, 15-16, and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Riva (US 20190294606) in view of Davenport (US 20220345464).
Regarding claim 1, Riva discloses:
An enhanced connectivity computer platform comprising:
a central handler comprising at least one processor in communication with at least one memory device, the central handler configured to maintain a cloud-based infrastructure for a connector application downloadable and executable on a plurality of user computing devices in communication with the central handler; (see Figure 12 with a cloud supported environment for the analytics service 1220 communicating with devices 1230, 1240, 1250; and see [0054-0056])
a first instance of the connector application executed on a first user computing device, the first instance including executable instructions causing a first processor of the first user computing device to display an interactive graphical user interface (GUI) on the first user computing device; and [0051] One or more of the apps 110 can be downloaded and installed in the app space of device 100, as apps 110a, . . . , 110b. Each of the apps may include a user interface (UI) framework 302a, . . . , 302b, respectively, which may allow one or more other components of device 100 (e.g., the analytics service 340) to subscribe for and get notifications upon occurrence of a UI event (e.g., a user using the app touches on a button, enters text, scrolls, likes a page, etc.)
a background operator of the connector application executed via the first processor, (the tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348); and see analytics service 340 running on plurality of applications in Figure 5; and main processor in [0055]) the background operator including executable instructions causing the first processor to: log user interaction with one or more software applications executed on the first user computing device; and [0052] The analytics service 340 may comprise suitable circuitry, interfaces, logic and/or code and may be operable to log user interactions with one or more of the apps 110a, . . . , 110b, analyze the user interactions using the templates 328, and extract one or more user data items 350, which may be stored in the store 346. The analytics service 340 may include a tracer component 342, an analyzer component 344, and a store component 346. The tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348), which may include one or more events 304 (e.g., user action such as button click, pressing a Like button, etc.) and a UI tree 306 with one or more text strings 307 (the UI tree may include the content consumed by a user in a given page class of an app, including text strings in that page class; e.g., a user may like a restaurant showing on a given restaurant app page, and the restaurant name will be a text string 307, the like action can be the event 304, and the page class where the Like action was entered can be the UI tree 306).
write an activity profile to at least one of (i) a first memory of the first user computing device or (ii) the at least one memory device of the central handler, the activity […] including a plurality of logged user interactions, [0025]The analytics service stores the behavioral data (e.g., BDIs/UDIs) collected from all apps in an OS-protected analytics store that apps (with permission) can programmatically query (e.g., using a SQL-like declarative language). The analytics service may also provide APIs for the OS, OS services, and apps to consume the behavioral information (e.g., the BDIs) from the analytics store or from another store (e.g., a cloud BDI/UDI store). [0054] The store 346 may be implemented at the device 100 (i.e., locally) and/or in the cloud (e.g., at the cloud server such as 512 in FIGS. 5, 310 and/or 320). The store 346 at device 100 stores the UDIs 350 associated with usage of the apps 110 at device 100. However, if the store is implemented in a cloud server, then the store 346 may store UDIs associated with application use not only at device 100 but at a plurality of other devices (of the same or different users). In this regard, the store 346 may additionally provide access to UDIs to apps, OS, OS services from the same device 100 and/or from other devices (of the same user or different users). Access to the UDI information may be provided using an API and upon access authentication (as illustrated in FIG. 4). In accordance with one or more embodiments, the store 346 may also provide UDIs automatically to one or more apps 110, the OS 112, an OS service (e.g., a digital personal assistant that may be an OS service or a stand-alone app), and/or one or more other devices that have pre-authorized access and have a subscription to one or more types of UDIs.
wherein the central handler is further configured to (see Figure 12 with a cloud supported environment for the analytics service 1220 communicating with devices 1230, 1240, 1250; and see [0054-0056]):
transmit the one or more data elements to the requestor device in a response message. [0101]the example method 800 may start at 810, when in-app data for at least one of the plurality of apps (110a) running on a computing device (100) is extracted. The in-app data (348) includes content consumed by a user (e.g., 306, 307) while the at least one app is running, and/or at least one user action (304) taken in connection with the content. At 820, an entity template (328) associated with the at least one app may be used to classify a plurality of text strings (307) within the in-app data into at least one of a plurality of data types (354, . . . , 356) specified by the entity template (328). At 830, at least one user data item (UDI 350) is generated (e.g., by the analyzer 344) by combining at least a portion of the classified plurality of text strings (307). The at least one UDI 350 may be accessible by at least one of the following: a second app of the plurality of apps, an operating system (112) running on the computing device, a service of the operating system (e.g., a digital personal assistant service), and/or a service running on at least another device (e.g., at least another device of the user of device 100) and shown in Figures 3A and B.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
maintain a repository of registered users that are registered with the central handler;
the activity profile;
receive, from a requestor device, a first request for first information associated with a user of the first user computing device, the requestor device including a second user computing device communicatively coupled to the first user device and executing a second instance of the connector application, the first request being initiated with the second instance of the connector application and including a registration tag identifying the requestor device;
in response to receiving the first request, confirm, via the registration tag, that the requestor device is or is associated with a registered user;
in response to the confirmation, access the activity profile to retrieve one or more data elements responsive to the first request; and
However Davenport teaches:
maintain a repository of registered users that are registered with the central handler; [0039] In one or more implementations, the electronic device 106 may correspond to a personal device associated with a user account (e.g., of a user named “Alison”). Alison may reside in or be a guest of the home/residence (e.g., corresponding to the connected home environment 116), which is the home of another user (e.g., named “Bob”). The electronic device 107 may also be associated with a user account for Allison, and the electronic devices 102-104 may correspond to an account such as a home account or a cloud-based account for Bob. In an example, the electronic device 105 may also correspond to the user account of Alison. For example, the respective users may register and/or associate their respective electronic devices 102-106 to their respective user accounts, through a service provider, such as through the cloud-based service 114.
the activity profile [0038] One of more of the electronic devices 102-107 may be configured to receive user authorization to access respective user account profiles for single user accounts and/or group accounts, in order to provide access to content, applications, services, or storage within the connected home environment 116, and/or with servers 112-114.
receive, from a requestor device, a first request for first information associated with a user of the first user computing device, the requestor device including a second user computing device communicatively coupled to the first user device and executing a second instance of the connector application, the first request being initiated with the second instance of the connector application [0068] At block 702, a system process of a device (e.g., electronic device 104) receives, from an application (e.g., application 302) on the device, a request for authentication information for the application. The application may be, for example, associated with a content provider (e.g., content provider 112) or a cloud-based service (e.g., cloud-based service 114). [0072] In various implementations, the one of the one or more proximate devices may be a device of a registered member of the home of the user of the device, a registered member of a family of the user of the device, another device of the user of the device, or a device that has previously paired with the device. For example, the device may be a device of a first user, and the other device may be a device associated with a member of a family of the first user or a home of the first user. And shown in at least Figure 6 and including a registration tag identifying the requestor device; [0074] At block 716, the received authentication information may be provided from the system process to the application. The authentication information may include, as examples, a token, or a password that can be used by the other device for authentication of a user account of the application.
in response to the confirmation, access the activity profile to retrieve one or more data elements responsive to the first request; and [0089] FIG. 10 illustrates an operational scenario in which, responsive to receiving a user input (e.g., a selection of the selectable option 904) indicating that companion device authorization of the purchase is desired, the electronic device 104 may provide a purchase handoff to the electronic device 106 (e.g., over a secure direct peer-to-peer connection 600 established as discussed above in connection with FIG. 6). The purchase handoff may be or include a request for companion device approval that is provided to any or all electronic devices that are in proximity of the electronic device 104 and/or that are associated with the same user (e.g., proximate electronic devices that are logged into the same user account as the user account of the current user of the electronic device 104). For example, in one or more implementations, the electronic device 104 may have multiple registered users, and the purchase handoff may be provided only to the electronic devices of a current one of the multiple users, and not to any devices of any other users of the electronic device 104 (e.g., even if devices of other users of the electronic device 104 are in proximity to and/or paired with the electronic device 104). In this way, the purchase handoff for a purchase by a user can include information identifying the purchase without exposing any personal user information associated with the purchase to any devices other than the devices of the user. As other examples, in one or more implementations, the request may be provided to any proximate device, any previously paired proximate device, any proximate device associated with a same user account as any profile on the electronic device 104, any proximate device in the same group (e.g., family) as the current profile on the electronic device 104, and/or any other devices that are associated with and/or proximate to the electronic device 104.
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 11, Riva discloses:
A computer-implemented method for enhanced resource sharing, the method implemented using a central handler including at least one processor in communication with at least one memory device, the central handler configured to (i) maintain a cloud-based infrastructure for a connector application downloadable and executable on a plurality of user computing devices in communication with the central handler, (see Figure 12 with a cloud supported environment for the analytics service 1220 communicating with devices 1230, 1240, 1250; and see [0054-0056]) and a first instance of the connector application executed on a first user computing device including a first processor, the method comprising: [0051] One or more of the apps 110 can be downloaded and installed in the app space of device 100, as apps 110a, . . . , 110b. Each of the apps may include a user interface (UI) framework 302a, . . . , 302b, respectively, which may allow one or more other components of device 100 (e.g., the analytics service 340) to subscribe for and get notifications upon occurrence of a UI event (e.g., a user using the app touches on a button, enters text, scrolls, likes a page, etc.)
executing, on the first processor, the first instance of the connector application;
causing, by the first instance of the connector application, the first processor to display an interactive graphical user interface (GUI) on the first user computing device; [0051] One or more of the apps 110 can be downloaded and installed in the app space of device 100, as apps 110a, . . . , 110b. Each of the apps may include a user interface (UI) framework 302a, . . . , 302b, respectively, which may allow one or more other components of device 100 (e.g., the analytics service 340) to subscribe for and get notifications upon occurrence of a UI event (e.g., a user using the app touches on a button, enters text, scrolls, likes a page, etc.)
executing, on the first processor, a background operator of the connector application; (the tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348); and see analytics service 340 running on plurality of applications in Figure 5; and main processor in [0055])
logging, by the background operator, user interaction with one or more software applications executed on the first user computing device; [0052] The analytics service 340 may comprise suitable circuitry, interfaces, logic and/or code and may be operable to log user interactions with one or more of the apps 110a, . . . , 110b, analyze the user interactions using the templates 328, and extract one or more user data items 350, which may be stored in the store 346. The analytics service 340 may include a tracer component 342, an analyzer component 344, and a store component 346. The tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348), which may include one or more events 304 (e.g., user action such as button click, pressing a Like button, etc.) and a UI tree 306 with one or more text strings 307 (the UI tree may include the content consumed by a user in a given page class of an app, including text strings in that page class; e.g., a user may like a restaurant showing on a given restaurant app page, and the restaurant name will be a text string 307, the like action can be the event 304, and the page class where the Like action was entered can be the UI tree 306).
writing, by the background operator, an activity […] to at least one of (i) a first memory of the first user computing device or (ii) the at least one memory device of the central handler, the activity […] including a plurality of logged user interactions; [0025]The analytics service stores the behavioral data (e.g., BDIs/UDIs) collected from all apps in an OS-protected analytics store that apps (with permission) can programmatically query (e.g., using a SQL-like declarative language). The analytics service may also provide APIs for the OS, OS services, and apps to consume the behavioral information (e.g., the BDIs) from the analytics store or from another store (e.g., a cloud BDI/UDI store). [0054] The store 346 may be implemented at the device 100 (i.e., locally) and/or in the cloud (e.g., at the cloud server such as 512 in FIGS. 5, 310 and/or 320). The store 346 at device 100 stores the UDIs 350 associated with usage of the apps 110 at device 100. However, if the store is implemented in a cloud server, then the store 346 may store UDIs associated with application use not only at device 100 but at a plurality of other devices (of the same or different users). In this regard, the store 346 may additionally provide access to UDIs to apps, OS, OS services from the same device 100 and/or from other devices (of the same user or different users). Access to the UDI information may be provided using an API and upon access authentication (as illustrated in FIG. 4). In accordance with one or more embodiments, the store 346 may also provide UDIs automatically to one or more apps 110, the OS 112, an OS service (e.g., a digital personal assistant that may be an OS service or a stand-alone app), and/or one or more other devices that have pre-authorized access and have a subscription to one or more types of UDIs.
receiving, by the central handler from a requestor device, a first request for first information associated with a user of the first user computing device, [0099] For example, one or more of the apps 110a, . . . , 110b may request access to the UDIs, and the access control module 402 (which may be part of the analytics service 340) may determine whether the requesting app is authorized to access the store 346 and/or the analyzer 344 to obtain UDIs. The access control 402 may be designated via a policy document, which may specify what type of data can be shared between apps, OS, OS services, and/or other devices (e.g., other devices of the same user). Information associated with the user is interpreted as the user data item representing user activity
transmitting, by the central handler, the one or more data elements to the requestor device in a response message. [0101]the example method 800 may start at 810, when in-app data for at least one of the plurality of apps (110a) running on a computing device (100) is extracted. The in-app data (348) includes content consumed by a user (e.g., 306, 307) while the at least one app is running, and/or at least one user action (304) taken in connection with the content. At 820, an entity template (328) associated with the at least one app may be used to classify a plurality of text strings (307) within the in-app data into at least one of a plurality of data types (354, . . . , 356) specified by the entity template (328). At 830, at least one user data item (UDI 350) is generated (e.g., by the analyzer 344) by combining at least a portion of the classified plurality of text strings (307). The at least one UDI 350 may be accessible by at least one of the following: a second app of the plurality of apps, an operating system (112) running on the computing device, a service of the operating system (e.g., a digital personal assistant service), and/or a service running on at least another device (e.g., at least another device of the user of device 100) and shown in Figures 3A and B.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
maintain a repository of registered users that are registered with the central handler;
the activity profile;
from a requestor device, a first request for first information associated with a user of the first user computing device, the requestor device including a second user computing device communicatively coupled to the first user device and executing a second instance of the connector application, the first request being initiated with the second instance of the connector application and including a registration tag identifying the requestor device;
in response to receiving the first request, confirming, by the central handler via the registration tag, that the requestor device is or is associated with a registered user;
in response to the confirming, accessing, by the central handler, the activity profile to retrieve one or more data elements responsive to the first request; and
However Davenport teaches:
maintain a repository of registered users that are registered with the central handler; [0039] In one or more implementations, the electronic device 106 may correspond to a personal device associated with a user account (e.g., of a user named “Alison”). Alison may reside in or be a guest of the home/residence (e.g., corresponding to the connected home environment 116), which is the home of another user (e.g., named “Bob”). The electronic device 107 may also be associated with a user account for Allison, and the electronic devices 102-104 may correspond to an account such as a home account or a cloud-based account for Bob. In an example, the electronic device 105 may also correspond to the user account of Alison. For example, the respective users may register and/or associate their respective electronic devices 102-106 to their respective user accounts, through a service provider, such as through the cloud-based service 114.
the activity profile [0038] One of more of the electronic devices 102-107 may be configured to receive user authorization to access respective user account profiles for single user accounts and/or group accounts, in order to provide access to content, applications, services, or storage within the connected home environment 116, and/or with servers 112-114.
from a requestor device, a first request for first information associated with a user of the first user computing device, the requestor device including a second user computing device communicatively coupled to the first user device and executing a second instance of the connector application, the first request being initiated with the second instance of the connector application and including a registration tag identifying the requestor device; [0068] At block 702, a system process of a device (e.g., electronic device 104) receives, from an application (e.g., application 302) on the device, a request for authentication information for the application. The application may be, for example, associated with a content provider (e.g., content provider 112) or a cloud-based service (e.g., cloud-based service 114). [0072] In various implementations, the one of the one or more proximate devices may be a device of a registered member of the home of the user of the device, a registered member of a family of the user of the device, another device of the user of the device, or a device that has previously paired with the device. For example, the device may be a device of a first user, and the other device may be a device associated with a member of a family of the first user or a home of the first user. And shown in at least Figure 6 [0074] At block 716, the received authentication information may be provided from the system process to the application. The authentication information may include, as examples, a token, or a password that can be used by the other device for authentication of a user account of the application.
in response to receiving the first request, confirming, by the central handler via the registration tag, that the requestor device is or is associated with a registered user; in response to the confirming, accessing, by the central handler, the activity profile to retrieve one or more data elements responsive to the first request; and [0089] FIG. 10 illustrates an operational scenario in which, responsive to receiving a user input (e.g., a selection of the selectable option 904) indicating that companion device authorization of the purchase is desired, the electronic device 104 may provide a purchase handoff to the electronic device 106 (e.g., over a secure direct peer-to-peer connection 600 established as discussed above in connection with FIG. 6). The purchase handoff may be or include a request for companion device approval that is provided to any or all electronic devices that are in proximity of the electronic device 104 and/or that are associated with the same user (e.g., proximate electronic devices that are logged into the same user account as the user account of the current user of the electronic device 104). For example, in one or more implementations, the electronic device 104 may have multiple registered users, and the purchase handoff may be provided only to the electronic devices of a current one of the multiple users, and not to any devices of any other users of the electronic device 104 (e.g., even if devices of other users of the electronic device 104 are in proximity to and/or paired with the electronic device 104). In this way, the purchase handoff for a purchase by a user can include information identifying the purchase without exposing any personal user information associated with the purchase to any devices other than the devices of the user. As other examples, in one or more implementations, the request may be provided to any proximate device, any previously paired proximate device, any proximate device associated with a same user account as any profile on the electronic device 104, any proximate device in the same group (e.g., family) as the current profile on the electronic device 104, and/or any other devices that are associated with and/or proximate to the electronic device 104.
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 18, Riva discloses:
At least one non-transitory computer-readable storage medium having stored thereon computer-executable instructions that, when executed by at least one processor, cause the at least one processor to: [0056] The system memory 113 may comprise suitable logic, circuitry, interfaces, and/or code that may enable permanent and/or non-permanent storage, buffering, and/or fetching of data, code and/or other information, which may be used, consumed, and/or processed. In this regard, the system memory 113 may comprise different memory technologies, including, for example, read-only memory (ROM), random access memory (RAM), Flash memory, solid-state drive (SSD), and/or field-programmable gate array (FPGA). The system memory 113 may store, for example, configuration data, which may comprise parameters and/or code, comprising software and/or firmware.
maintain a cloud-based infrastructure for a connector application downloadable and executable on a plurality of user computing devices; (see Figure 12 with a cloud supported environment for the analytics service 1220 communicating with devices 1230, 1240, 1250; and see [0054-0056])
execute, on a first user computing device, a first instance of the connector application; cause display of an interactive graphical user interface (GUI) on the first user computing device; [0051] One or more of the apps 110 can be downloaded and installed in the app space of device 100, as apps 110a, . . . , 110b. Each of the apps may include a user interface (UI) framework 302a, . . . , 302b, respectively, which may allow one or more other components of device 100 (e.g., the analytics service 340) to subscribe for and get notifications upon occurrence of a UI event (e.g., a user using the app touches on a button, enters text, scrolls, likes a page, etc.)
execute, on the first user computing device, a background operator; (the tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348); and see analytics service 340 running on plurality of applications in Figure 5; and main processor in [0055])
log user interaction with one or more software applications executed on the first user computing device; [0052] The analytics service 340 may comprise suitable circuitry, interfaces, logic and/or code and may be operable to log user interactions with one or more of the apps 110a, . . . , 110b, analyze the user interactions using the templates 328, and extract one or more user data items 350, which may be stored in the store 346. The analytics service 340 may include a tracer component 342, an analyzer component 344, and a store component 346. The tracer 342 and the analyzer 344 are referred herein as an “analytics engine.” The tracer 342 may be operable to capture raw application content (e.g., in-app data 348), which may include one or more events 304 (e.g., user action such as button click, pressing a Like button, etc.) and a UI tree 306 with one or more text strings 307 (the UI tree may include the content consumed by a user in a given page class of an app, including text strings in that page class; e.g., a user may like a restaurant showing on a given restaurant app page, and the restaurant name will be a text string 307, the like action can be the event 304, and the page class where the Like action was entered can be the UI tree 306).
write an activity profile to at least one memory, the activity […] including a plurality of logged user interactions; [0025]The analytics service stores the behavioral data (e.g., BDIs/UDIs) collected from all apps in an OS-protected analytics store that apps (with permission) can programmatically query (e.g., using a SQL-like declarative language). The analytics service may also provide APIs for the OS, OS services, and apps to consume the behavioral information (e.g., the BDIs) from the analytics store or from another store (e.g., a cloud BDI/UDI store). [0054] The store 346 may be implemented at the device 100 (i.e., locally) and/or in the cloud (e.g., at the cloud server such as 512 in FIGS. 5, 310 and/or 320). The store 346 at device 100 stores the UDIs 350 associated with usage of the apps 110 at device 100. However, if the store is implemented in a cloud server, then the store 346 may store UDIs associated with application use not only at device 100 but at a plurality of other devices (of the same or different users). In this regard, the store 346 may additionally provide access to UDIs to apps, OS, OS services from the same device 100 and/or from other devices (of the same user or different users). Access to the UDI information may be provided using an API and upon access authentication (as illustrated in FIG. 4). In accordance with one or more embodiments, the store 346 may also provide UDIs automatically to one or more apps 110, the OS 112, an OS service (e.g., a digital personal assistant that may be an OS service or a stand-alone app), and/or one or more other devices that have pre-authorized access and have a subscription to one or more types of UDIs.
transmit the one or more data elements to the requestor device in a response message. [0101]the example method 800 may start at 810, when in-app data for at least one of the plurality of apps (110a) running on a computing device (100) is extracted. The in-app data (348) includes content consumed by a user (e.g., 306, 307) while the at least one app is running, and/or at least one user action (304) taken in connection with the content. At 820, an entity template (328) associated with the at least one app may be used to classify a plurality of text strings (307) within the in-app data into at least one of a plurality of data types (354, . . . , 356) specified by the entity template (328). At 830, at least one user data item (UDI 350) is generated (e.g., by the analyzer 344) by combining at least a portion of the classified plurality of text strings (307). The at least one UDI 350 may be accessible by at least one of the following: a second app of the plurality of apps, an operating system (112) running on the computing device, a service of the operating system (e.g., a digital personal assistant service), and/or a service running on at least another device (e.g., at least another device of the user of device 100) and shown in Figures 3A and B.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
maintain a repository of registered users;
activity profile
receive, from a requestor device, a first request for first information associated with a user of the first user computing device, the requestor device including a second user computing device communicatively coupled to the first user device and executing a second instance of the connector application, the first request being initiated with the second instance of the connector application and including a registration tag identifying the requestor device;
in response to receiving the first request, confirm, via the registration tag, that the requestor device is or is associated with a registered user;
in response to the confirmation, access the activity profile to retrieve one or more data elements responsive to the first request; and
However Davenport teaches:
maintain a repository of registered users that are registered with the central handler; [0039] In one or more implementations, the electronic device 106 may correspond to a personal device associated with a user account (e.g., of a user named “Alison”). Alison may reside in or be a guest of the home/residence (e.g., corresponding to the connected home environment 116), which is the home of another user (e.g., named “Bob”). The electronic device 107 may also be associated with a user account for Allison, and the electronic devices 102-104 may correspond to an account such as a home account or a cloud-based account for Bob. In an example, the electronic device 105 may also correspond to the user account of Alison. For example, the respective users may register and/or associate their respective electronic devices 102-106 to their respective user accounts, through a service provider, such as through the cloud-based service 114.
the activity profile [0038] One of more of the electronic devices 102-107 may be configured to receive user authorization to access respective user account profiles for single user accounts and/or group accounts, in order to provide access to content, applications, services, or storage within the connected home environment 116, and/or with servers 112-114.
receive, from a requestor device, a first request for first information associated with a user of the first user computing device, the requestor device including a second user computing device communicatively coupled to the first user device and executing a second instance of the connector application, the first request being initiated with the second instance of the connector application and including a registration tag identifying the requestor device; [0068] At block 702, a system process of a device (e.g., electronic device 104) receives, from an application (e.g., application 302) on the device, a request for authentication information for the application. The application may be, for example, associated with a content provider (e.g., content provider 112) or a cloud-based service (e.g., cloud-based service 114). [0072] In various implementations, the one of the one or more proximate devices may be a device of a registered member of the home of the user of the device, a registered member of a family of the user of the device, another device of the user of the device, or a device that has previously paired with the device. For example, the device may be a device of a first user, and the other device may be a device associated with a member of a family of the first user or a home of the first user. And shown in at least Figure 6 [0074] At block 716, the received authentication information may be provided from the system process to the application. The authentication information may include, as examples, a token, or a password that can be used by the other device for authentication of a user account of the application.
in response to receiving the first request, confirm, via the registration tag, that the requestor device is or is associated with a registered user; in response to the confirmation, access the activity profile to retrieve one or more data elements responsive to the first request; and [0089] FIG. 10 illustrates an operational scenario in which, responsive to receiving a user input (e.g., a selection of the selectable option 904) indicating that companion device authorization of the purchase is desired, the electronic device 104 may provide a purchase handoff to the electronic device 106 (e.g., over a secure direct peer-to-peer connection 600 established as discussed above in connection with FIG. 6). The purchase handoff may be or include a request for companion device approval that is provided to any or all electronic devices that are in proximity of the electronic device 104 and/or that are associated with the same user (e.g., proximate electronic devices that are logged into the same user account as the user account of the current user of the electronic device 104). For example, in one or more implementations, the electronic device 104 may have multiple registered users, and the purchase handoff may be provided only to the electronic devices of a current one of the multiple users, and not to any devices of any other users of the electronic device 104 (e.g., even if devices of other users of the electronic device 104 are in proximity to and/or paired with the electronic device 104). In this way, the purchase handoff for a purchase by a user can include information identifying the purchase without exposing any personal user information associated with the purchase to any devices other than the devices of the user. As other examples, in one or more implementations, the request may be provided to any proximate device, any previously paired proximate device, any proximate device associated with a same user account as any profile on the electronic device 104, any proximate device in the same group (e.g., family) as the current profile on the electronic device 104, and/or any other devices that are associated with and/or proximate to the electronic device 104.
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 7, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
display the GUI including an interface prompting the first user to provide user input including user preferences; generate a plurality of manual data elements representing the user preferences; and write the plurality of manual data elements to the activity profile.
However Davenport teaches:
display the GUI including an interface prompting the first user to provide user input including user preferences; generate a plurality of manual data elements representing the user preferences; and [0041] Alison may access her media content (e.g., music and/or video) on one or more of the electronic devices 105-107. For example, the electronic device 105 (e.g., a digital media player) may have a remote control device that Alison can use (e.g., via physical button(s), touch surface(s), and/or voice requests spoken to the remote) to control output of video and/or music via the content provider 112 in association with her user account. [0042] In one or more implementations, the cloud-based service 114 may be configured to perform operations in association with user accounts such as: storing data (e.g., voice profiles, user settings/preferences, files such as documents and/or photos, etc.) with respect to user accounts, sharing and/or sending data with other users with respect to user accounts, backing up device data with respect to user accounts, and/or associating devices and/or groups of devices with user accounts. Also see Figure 6 GUI options
write the plurality of manual data elements to the activity profile. [0042] In one or more implementations, the cloud-based service 114 may be configured to perform operations in association with user accounts such as: storing data (e.g., voice profiles, user settings/preferences, files such as documents and/or photos, etc.) with respect to user accounts, sharing and/or sending data with other users with respect to user accounts, backing up device data with respect to user accounts, and/or associating devices and/or groups of devices with user accounts. And see [0039-0041]
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Claim 15 recite parallel claim language to claim 7 and therefore are also rejected as claim 7 is rejected by Riva in view of Davenport.
Regarding claim 8, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
wherein the first instance of the connector application further causes the first processor to display the GUI including an interface prompting the first user to provide user input including access parameters.
However Davenport teaches:
wherein the first instance of the connector application further causes the first processor to display the GUI including an interface prompting the first user to provide user input including access parameters. (shown in Figure 6 604 message of "would you like to sign in to APP1 on DEVICE2 using this device?" on device 106)
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 9, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
wherein the central handler is further configured to determine, based upon the access parameters, the requestor device has permission to access the activity profile and the one or more data elements.
However Davenport teaches:
wherein the central handler is further configured to determine, based upon the access parameters, the requestor device has permission to access the activity profile and the one or more data elements. [0057] As illustrated in FIG. 6, responsive to receiving the nomination signal 500, electronic device 104 discontinues broadcasting the beacon, and establishes a secure direct connection 600 (e.g., a secure direct peer-to-peer channel) with the electronic device 106 (e.g., using the encryption information 308 and 310 discussed above in connection with FIG. 3). FIG. 6 also illustrates how, once the secure direct connection 600 is established, the electronic device 104 provides an authentication request 602 to the electronic device 106. As illustrated in FIG. 6, because the authentication request 602 is provided over a secure direct connection 600, the authentication request 602 can include sufficient information to allow an initial notification 604 provided by the electronic device 106 to include meaningful information for the user about the companion device authentication request (e.g., including the application and the device for which the companion device authentication is desired).
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 10, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
wherein the access parameters define which entities have permission to access the activity profile, and which data elements of the activity profile can be accessed by each of the entities.
However Davenport teaches:
wherein the access parameters define which entities have permission to access the activity profile, and which data elements of the activity profile can be accessed by each of the entities. [0060] For example, in one or more implementations, electronic device 106 may have a token for authentication with application 302, content provider 112, and/or cloud-based service 114 stored in memory, that can be transferred to the electronic device 104 to allow the electronic device to authenticate with application 302, content provider 112, and/or cloud-based service 114. In one or more implementations, in order to authorize the transfer of the token, the user of the electronic device 106 may be required to provide an unlock passcode, a biometric authentication, or other local authentication that is used to access the electronic device 106. and see merchant purchase example in [0093-0096]
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Claim 16 recites parallel claim language to claims 8-10 and therefore are also rejected as claims 8-10 are rejected by Riva in view of Davenport.
Regarding claim 19, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
wherein the computer-executable instructions further cause the at least one processor to: cause display of a prompt for the first user to provide biometric authentication data or a password before permitting access the activity profile or transmit the response message.
However Davenport teaches:
wherein the computer-executable instructions further cause the at least one processor to: cause display of a prompt for the first user to provide biometric authentication data or a password before permitting access the activity profile or transmit the response message.[0060] For example, in one or more implementations, electronic device 106 may have a token for authentication with application 302, content provider 112, and/or cloud-based service 114 stored in memory, that can be transferred to the electronic device 104 to allow the electronic device to authenticate with application 302, content provider 112, and/or cloud-based service 114. In one or more implementations, in order to authorize the transfer of the token, the user of the electronic device 106 may be required to provide an unlock passcode, a biometric authentication, or other local authentication that is used to access the electronic device 106. and see merchant purchase example in [0093-0096]
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 20, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
wherein the computer-executable instructions further cause the at least one processor to: cause display of the GUI including an interface prompting the first user to provide at least one of: (i) user input including user preferences, (ii) access parameters, or (iii) monitoring parameters.
However Davenport teaches:
wherein the computer-executable instructions further cause the at least one processor to: cause display of the GUI including an interface prompting the first user to provide at least one of: (i) user input including user preferences, (ii) access parameters, or (iii) monitoring parameters. [ (shown in Figure 6 604 message of "would you like to sign in to APP1 on DEVICE2 using this device?" on device 106)
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Regarding claim 21, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI, the reference does not expressly disclose:
wherein the background operator includes executable instructions that further cause the first processor to: during accessing the activity profile, determine that the one or more data elements responsive to the first request are permissioned for passive sharing; and transmit the one or more data elements without requesting permission from the first user after the accessing the activity profile.
However Davenport teaches:
wherein the background operator includes executable instructions that further cause the first processor to: during accessing the activity profile, determine that the one or more data elements responsive to the first request are permissioned for passive sharing; and transmit the one or more data elements without requesting permission from the first user after the accessing the activity profile. [0051] As illustrated in FIG. 3, responsive to launching the application 302 when a user is not logged into the application 302, a system process that is separate from the application 302 may provide a notification 322, such as using a display 300 that is connected to or is integral with the electronic device 104. As shown in FIG. 3, electronic device 104 may have previously stored encryption information 310 that can be used for establishing a secure direct connection (e.g., a secure direct peer-to-peer channel) with electronic device 106. FIG. 3 also shows how electronic device 106 may have previously stored encryption information 308 that can be used for establishing a secure direct connection with electronic device 104. For example, the electronic device 104 and the electronic device 106 may have previously exchanged the encryption information 308 and 310 (e.g., public keys, link keys, or the like) as part of a prior pairing operation, or as part of registration operations to register the devices as devices of members of a family or a home. In one or more implementations, the encryption information 308 and/or 310 may have been exchanged by the electronic devices 104 and 106 via a direct peer-to-peer connection between the electronic devices 104 and 106 and/or the encryption information 308 and/or 310 may have been exchanged by the electronic devices 104 and 106 via a server-based transport mechanism. [0052] For example, electronic device 104 may have previously paired with electronic device 106 and exchanged encryption information that can be stored for later establishment of a secure direct connection. In another example, electronic device 106 may be a device that is associated with the user account for the electronic device 104 (e.g., electronic device 104 and electronic device 106 may be registered devices of the same user). In another example, the electronic device 106 may be a device associated with its own user account that is different from but associated with an account of the electronic device 104 (e.g., and electronic device 106 may be a device that is registered as a family member device of a family member of the user of electronic device 104, or a device of another user that is associated with a home environment of the user of electronic device 104). And see [0026]
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva to include the limitations above, as taught in Davenport, in order to allow for an expanded use of companion devices to authenticate access to applications and/or services at the first device. (see paragraph 019).
Claims 5, 6, 12, 13, 14, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Riva (US 20190294606) in view of Davenport (US 20220345464) in further view of Beye (US20180039924).
Regarding claims 5, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI and Davenport determines authorization and preferences/stored activities across devices, the references do not expressly teach:
wherein at least one of the background operator or the central handler is configured to process the logged user interactions to generate a plurality of learned data elements identifying learned preferences of the first user, and wherein the first instance of the connector application further causes the first processor to display the GUI including: display of the learned preferences of the first user, display of a request for validation of the learned preferences, and provision of an interactive option for the first user to interact with the GUI to provide user input including user validation or user decline of one or more of the learned preferences.
However Beye teaches:
wherein at least one of the background operator or the central handler is configured to process the logged user interactions to generate a plurality of learned data elements identifying learned preferences of the first user, and wherein the first instance of the connector application further causes the first processor to display the GUI including: display of the learned preferences of the first user, display of a request for validation of the learned preferences, and provision of an interactive option for the first user to interact with the GUI to provide user input including user validation or user decline of one or more of the learned preferences. [0094] As illustrated in block 616 of FIG. 4, the dynamic payment decisioning system 208 enables the user 202 to modify the user profile on the user device 204 associated with the user 202 ensuring that the user profile contains current user preferences, historic trends, and resources available to the user 202. Upon request by the user 202, any updates to the user profile may be transmitted by the dynamic payment decisioning system 208 to the user device 204. Upon the user 202 updating the user profile on the user device 204, the user profile may be transmitted by the user device 204 concurrently with instructions causing the dynamic payment decisioning system 208 to update its copy of the user profile. These instructions and the updated user profile may be received by the dynamic payment decisioning system 208 and stored on the cloud network 301 maintained by the dynamic payment decisioning system 208. In other words, in some embodiments of the invention, the user profile may be stored on the user device 204 and received by the dynamic payment decisioning system 208 upon the user 202 updating the user profile, where the user profile with the current user preferences, historic trends, and resources available to the user 202. In some embodiments, the dynamic payment decisioning system 208 may automatically transmit the user profile to the user device 204 in response to a predefined period of user inactivity, wherein the dynamic payment decisioning system 208 prompts the user 202 to update the user profile and/or confirm that all user preferences, historic trends, and resources available to the user 202 are current. Upon the user 202 updating and/or confirming the user profile, the user profile may be transmitted from the user device 204 and received by the dynamic payment decisioning system 208, where some or all the user profile with the current user preferences, historic trends, and resources available to the user 202 may be provided to the resource manager systems 206 for regular updating of resource characteristics. And see Figure 4
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva and the authentication across devices in Davenport to include wherein at least one of the background operator or the central handler is configured to process the logged user interactions to generate a plurality of learned data elements identifying learned preferences of the first user, and wherein the first instance of the connector application further causes the first processor to display the GUI including: display of the learned preferences of the first user, display of a request for validation of the learned preferences, and provision of an interactive option for the first user to interact with the GUI to provide user input including user validation or user decline of one or more of the learned preferences, as taught in Beye, in order to offer a wide variety of terms to fit the needs of users. The terms and/or user needs may continually change over a period of time without adjustments to resource utilization. (paragraph 001).
Claims 12 and 13 recite parallel claim language to claim 5 and therefore are also rejected as claim 5 is rejected by Riva in view of Davenport in further view of Beye.
Regarding claim 6, Riva in view of Davenport in further view of Beye teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI and Davenport determines authorization and preferences/stored activities across devices, the references do not expressly teach:
wherein the first instance of the connector application further causes the first processor to receive the user input from the GUI in response to the first user interacting with the interactive option displayed at the GUI, the user input including user validation of at least one of the learned preferences, and wherein the first instance of the software application or the background operator further causes the first processor to write the plurality of learned data elements to the activity profile in response to the preferences being validated by the first user
However Beye teaches:
wherein the first instance of the connector application further causes the first processor to receive the user input from the GUI in response to the first user interacting with the interactive option displayed at the GUI, the user input including user validation of at least one of the learned preferences, and wherein the first instance of the software application or the background operator further causes the first processor to write the plurality of learned data elements to the activity profile in response to the preferences being validated by the first user [0094] As illustrated in block 616 of FIG. 4, the dynamic payment decisioning system 208 enables the user 202 to modify the user profile on the user device 204 associated with the user 202 ensuring that the user profile contains current user preferences, historic trends, and resources available to the user 202. Upon request by the user 202, any updates to the user profile may be transmitted by the dynamic payment decisioning system 208 to the user device 204. Upon the user 202 updating the user profile on the user device 204, the user profile may be transmitted by the user device 204 concurrently with instructions causing the dynamic payment decisioning system 208 to update its copy of the user profile. These instructions and the updated user profile may be received by the dynamic payment decisioning system 208 and stored on the cloud network 301 maintained by the dynamic payment decisioning system 208. In other words, in some embodiments of the invention, the user profile may be stored on the user device 204 and received by the dynamic payment decisioning system 208 upon the user 202 updating the user profile, where the user profile with the current user preferences, historic trends, and resources available to the user 202. In some embodiments, the dynamic payment decisioning system 208 may automatically transmit the user profile to the user device 204 in response to a predefined period of user inactivity, wherein the dynamic payment decisioning system 208 prompts the user 202 to update the user profile and/or confirm that all user preferences, historic trends, and resources available to the user 202 are current. Upon the user 202 updating and/or confirming the user profile, the user profile may be transmitted from the user device 204 and received by the dynamic payment decisioning system 208, where some or all the user profile with the current user preferences, historic trends, and resources available to the user 202 may be provided to the resource manager systems 206 for regular updating of resource characteristics.
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva and the authentication across devices in Davenport to include wherein the first instance of the connector application further causes the first processor to receive the user input from the GUI in response to the first user interacting with the interactive option displayed at the GUI, the user input including user validation of at least one of the learned preferences, and wherein the first instance of the software application or the background operator further causes the first processor to write the plurality of learned data elements to the activity profile in response to the preferences being validated by the first user, as taught in Beye, in order to offer a wide variety of terms to fit the needs of users. The terms and/or user needs may continually change over a period of time without adjustments to resource utilization. (paragraph 001).
Claim 14 recite parallel claim language to claim 6 and therefore are also rejected as claim 6 is rejected by Riva in view of Davenport in further view of Beye.
Regarding claim 22, Riva in view of Davenport teaches the limitations set forth above.
While Riva discloses the logging of user activity in order to determine the elements to show to a user on a GUI and Davenport determines authorization and preferences/stored activities across devices, the references do not expressly teach:
wherein the first request has one or more contextual parameters, and wherein the background operator includes executable instructions that further cause the first processor to: during accessing the activity profile, determine that two data elements are responsive to the first request; and select one of the two data elements based upon the context parameters of the first request.
However Beye teaches:
wherein the first request has one or more contextual parameters, and wherein the background operator includes executable instructions that further cause the first processor to: during accessing the activity profile, determine that two data elements are responsive to the first request; and select one of the two data elements based upon the context parameters of the first request. (see Figure 5 workflow; the examiner interprets the first request to be the trigger and the updated resource characteristics to be the two data elements based on the trigger and the selection of the data element to the list of ranked resources)
Therefore it would have been obvious before the effective filing date of the claimed invention to modify the logging of user activity in Riva and the authentication across devices in Davenport to include wherein the first request has one or more contextual parameters, and wherein the background operator includes executable instructions that further cause the first processor to: during accessing the activity profile, determine that two data elements are responsive to the first request; and select one of the two data elements based upon the context parameters of the first request, as taught in Beye, in order to offer a wide variety of terms to fit the needs of users. The terms and/or user needs may continually change over a period of time without adjustments to resource utilization. (paragraph 001).
Response to Arguments
With respect to the remarks filed on 4/6/2026 regarding 35 USC 101, the examiner has found the amended claims to overcome the previous rejection and they are no longer rejected under 35 USC 101. The features are now more than just peripherally incorporated into the claims to implement the abstract idea. Thus, the claimed features would require that a computer is an integral part of the claimed method, and therefore the claims recite eligible subject matter because the claimed features integrate the judicial exception into a practical application. As set forth in the specification, in at least [0063-64], [0063] At least one of the technical problems addressed by this system may include: (i) siloed data between applications executed on a computing device; (ii) nonuniform access to data between user computing device; and/or (iii) inability for a user to define access privileges to their data. […] [0064] The enhanced connectivity platform of the present disclosure may provide technical solutions to at least these technical problems. This platform may facilitate inter-application and inter-device data sharing that is consistent and implemented according to user-set permissions and parameters. Input and learned information about a user can be stored and shared in a manner that improves connectivity without sacrificing data security, facilitating improved user experience. The data sharing between resources is therefore more secure than in at least some other systems, and the user is the owner of their own data and provided the ability and authority to securely select what data to share and with whom. The solution to the technical problems identified here are reflected in the claimed invention.
With respect to the remarks directed to 35 USC 103, the examiner has found the remarks to be persuasive in light of the claim amendments. The claims no longer rely upon Eberstadt. The combination of Riva in view of Davenport is now relied upon for teaching the claimed invention. The claims remain rejected under 35 USC 103.
Relevant Art Not Cited
Dunn (US 20110119732) discloses determining existing access permissions set by a user.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VICTORIA E. FRUNZI whose telephone number is (571)270-1031. The examiner can normally be reached Monday- Friday 7-4 (EST).
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, 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.
VICTORIA E. FRUNZI
Primary Examiner
Art Unit TC 3689
/VICTORIA E. FRUNZI/Primary Examiner, Art Unit 3689 5/20/2026
Prosecution Insights