DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 7/1/2026 has been entered.
Response to Amendment
This Action is in response to the amendment dated 7/01/2026, for which the amendment and corresponding arguments filed on the same date have been entered. Claims 1-14 are currently pending in this application, with claims 1, 10 and 12 being independent. Claims 1, 10 and 12 have been amended. No claims have been cancelled or added.
Response to Arguments
Applicant’s arguments have been considered, but are moot, because the new ground of rejection was caused by the amendment and does not rely on any reference applied in the aforementioned rejection for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-14 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gross, et al (US PG Publication 2019/0141494), hereafter Gross.
Regarding claim 1, Gross teaches
a method for transmitting a notification to an application of a mobile terminal, said mobile terminal having a secure hardware element allowing the authentication of said mobile terminal in a telecommunication network,
the method comprising:
receiving said notification from an application server, said notification comprising at least one identifier of said mobile terminal and at least one identifier of said application
([1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906
[1216] Push notification server 31_906 can store a mapping of device tokens (e.g., identifier for mobile device 31_100) to push filters 31_914 for each mobile device serviced by push notification server 31_906. Push filters 31_914 can include information identifying applications that have received authorization to receive push notifications on mobile device 31_100, for example
(Mobile device receives notifications from server that include information identifying authorized applications and a mobile device identifier));
obtaining, based on said at least one identifier of said mobile terminal, at least one datum relating to the connectivity of said mobile terminal
([1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(The mobile device determines data related to communication/connection state with another mobile device, based on the mobile device identifier));
determining, depending on said at least one obtained datum, a type of communication interface to be used to communicate with said mobile terminal and an access parameter for access to at least one communication device able to communicate with said mobile terminal depending on the determined communication interface
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205
[0940] FIG. 23E, in response to detecting a selection of the selectable user interface element shown in suggestions portion 2307, the device updates the text-input field to include the address that may correspond to an address shared with the user by other users (e.g., via email, a social networking application, etc.)
[1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(Mobile device determines, depending on the data relating to communication/connection state with another mobile device, to use a type of communication interface (Bluetooth, Wi-Fi) to communicate and an e-mail address (access parameter) for access to another communication device sharing the e-mail address and able to communicate with the mobile device)); and
transmitting said notification to said communication device accessible via said access parameter
([0940] FIG. 23E, in response to detecting a selection of the selectable user interface element shown in suggestions portion 2307, the device updates the text-input field to include the address that may correspond to an address shared with the user by other users (e.g., via email, a social networking application, etc.)
[2217] A communication application (e.g., instant messaging, text messaging, email, telephone, etc.) can remind the user about a received message. Each of these notifications, reminders, alerts, etc., is directed to the user and will prompt or cause the user to interact with the computing device
(Mobile device receives message notification, based on the e-mail address (access parameter))).
Regarding claim 2, Gross teaches the method of claim 1,
characterized in that the transmission step comprises a substep of routing said notification by said communication device to said application of said mobile terminal identified via said at least one identifier of said mobile terminal
([1216] Mobile device 31_100 can send information identifying authorized push applications to push notification server 31_906. For example, mobile device 31_100 can send a message that includes push filter 31_926 containing push notification filters 31_914 and the device token for mobile device 31_100 to push notification server 31_906. Push notification server 31_906 can store a mapping of device tokens (e.g., identifier for mobile device 31_100) to push filters 31_914 for each mobile device serviced by push notification server 31_906. Push filters 31_914 can include information identifying applications that have received authorization to receive push notifications on mobile device 31_100, for example
(Push notification routed to authorized application on the mobile device that is identified based on the mobile device identifier)).
Regarding claim 3, Gross teaches the method of claim 1,
wherein the obtaining step also depends on said identifier of said application
([01319] The mobile device 31_100 can receive event data related to system state (e.g., battery state, network state, foreground application identifier, etc.) of mobile device 31_1600
[1321] If the attribute event forecasts received from the peer device 31_1600 indicate that the conditions (e.g., battery state, thermal level, etc.) of peer device 31_1600 are such that initiating communication with peer device 31_1600 will not deplete the battery or make the thermal state worse, then sampling daemon 31_102 can approve the transmission of the message
(The mobile device determines data related to communication/connection state with another mobile device, based on the application identifier))
Regarding claim 4, Gross teaches the method of claim 1,
wherein the reception step is followed by a step of storing said notification
([1175] Attributes or attribute values that have received a ‘no’ vote from thermal daemon 31_110 can be notified when the thermal condition value maintained by sampling daemon 31_102 is reset to indicate normal operating temperatures (e.g., true value). For example, sampling daemon 31_102 can store data that identifies clients, attributes and attribute values that have received a ‘no’ vote).
Regarding claim 5, Gross teaches the method of claim 1,
wherein said at least one connectivity datum comprises a connection state of at least one communication interface of said mobile terminal at a given time
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205
[1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(Mobile device determines, based on the data relating to communication/connection state with another mobile device), to use a type of communication interface (Bluetooth, Wi-Fi))).
Regarding claim 6, Gross teaches the method of claim 1,
wherein said at least one connectivity datum comprises a priority indicator associated with said at least one communication interface of said mobile terminal
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205
[1219] In some implementations, notification server 31_906 can be configured to process high priority push notifications and low priority push notifications. For example, push provider 31_902 can send a high priority push notification 31_910 and/or a low priority push notification 31_912 to push notification server 31_906. Push provider 31_902 can identify a push notification as high or low priority by specifying the priority of the push notification in data contained within the push notification sent to push notification server 31_906 and mobile device 31_100).
Regarding claim 7, Gross teaches the method of claim 1.
Gross further teaches
wherein said at least one connectivity datum comprises a quality indicator associated with said at least one communication interface of said mobile terminal
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205).
Regarding claim 8, Gross teaches the method of claim 1.
Gross further teaches
wherein the determination step also depends on an access rights datum associated with the secure hardware element
([1828] The present disclosure further contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. Such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining personal information data private and secure. Further, such collection should occur only after receiving the informed consent of the users. Additionally, such entities would take any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures).
Regarding claim 9, Gross teaches the method of claim 1.
Gross further teaches
wherein said at least one connectivity datum comprises a connection state of at least one server located in the network
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205
[1225] Push notifications stored in push data store 31_922 will remain in push data store 31_922 until the application identifier associated with a stored push notification is moved from the no wake list 31_918 to wake list 31_916 or until a network connection is established between push notification server 31_906 and mobile device 31_100
(Mobile device determines, based on wake (active connection state with server), a type of communication interface (Bluetooth, Wi-Fi))).
Regarding claim 10, Gross teaches
a device for transmitting a notification to an application of a mobile terminal, said mobile terminal having a secure hardware element allowing the authentication of said mobile terminal in a telecommunication network, said device comprising:
a module for receiving said notification from an application server, said notification comprising at least one identifier of said mobile terminal and at least one identifier of said application
([1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906
[1216] Push notification server 31_906 can store a mapping of device tokens (e.g., identifier for mobile device 31_100) to push filters 31_914 for each mobile device serviced by push notification server 31_906. Push filters 31_914 can include information identifying applications that have received authorization to receive push notifications on mobile device 31_100, for example
(Mobile device receives notifications from server that include information identifying authorized applications and a mobile device identifier));
a module for obtaining, based on said first identifier of said mobile terminal, at least one datum relating to the connectivity of said mobile terminal
([1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(The mobile device determines data related to communication/connection state with another mobile device, based on the mobile device identifier));
a module for determining, depending on said at least one obtained datum, a type of communication interface to be used to communicate with said mobile terminal and an access parameter for access to at least one communication device able to communicate with said mobile terminal depending on the determined communication interface
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205
[0940] FIG. 23E, in response to detecting a selection of the selectable user interface element shown in suggestions portion 2307, the device updates the text-input field to include the address that may correspond to an address shared with the user by other users (e.g., via email, a social networking application, etc.)
[1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(Mobile device determines, depending on the data relating to communication/connection state with another mobile device, to use a type of communication interface (Bluetooth, Wi-Fi) to communicate and an e-mail address (access parameter) for access to another communication device sharing the e-mail address and able to communicate with the mobile device));
a module for transmitting said notification to said communication device via said access parameter
([0940] FIG. 23E, in response to detecting a selection of the selectable user interface element shown in suggestions portion 2307, the device updates the text-input field to include the address that may correspond to an address shared with the user by other users (e.g., via email, a social networking application, etc.)
[2217] A communication application (e.g., instant messaging, text messaging, email, telephone, etc.) can remind the user about a received message. Each of these notifications, reminders, alerts, etc., is directed to the user and will prompt or cause the user to interact with the computing device
(Mobile device receives message notification, based on the e-mail address (access parameter))).
Regarding claim 11, Marcellino, in view of Gross, teaches the device of claim 10,
wherein the device includes said communication device
([1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906
(Device that transmits notification includes server)).
Regarding claim 12, Gross teaches
a system for transmitting a notification to an application of a mobile terminal, said mobile terminal having a secure hardware element allowing the authentication of said mobile terminal in a telecommunication network,
the system comprising:
a first device comprising means for receiving said notification from an application server, said notification comprising at least one identifier of said mobile terminal and at least one identifier of said application
([1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906
[1216] Push notification server 31_906 can store a mapping of device tokens (e.g., identifier for mobile device 31_100) to push filters 31_914 for each mobile device serviced by push notification server 31_906. Push filters 31_914 can include information identifying applications that have received authorization to receive push notifications on mobile device 31_100, for example
(Mobile device receives notifications from server that include information identifying authorized applications and a mobile device identifier)),
obtaining based on said at least one identifier of said mobile terminal at least one connectivity datum relating to the connectivity of said mobile terminal
([1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(The mobile device determines data related to communication/connection state with another mobile device, based on the mobile device identifier)),
determining a type of communication interface to be used to communicate with said mobile terminal and an access parameter for access to at least one communication device depending on the determined communication interface depending on said at least one obtained connectivity datum
([0605] The wireless communication optionally uses any of a plurality of communications standards, protocols and technologies, including but not limited to Bluetooth and Wi-Fi
[0721] The user interface displayed on the touch screen 112 includes the following elements, or a subset or superset thereof: [0722] Signal strength indicator(s) 202 for wireless communication(s), such as cellular and Wi-Fi signals; [0723] Time 203; [0724] Bluetooth indicator 205
[0940] FIG. 23E, in response to detecting a selection of the selectable user interface element shown in suggestions portion 2307, the device updates the text-input field to include the address that may correspond to an address shared with the user by other users (e.g., via email, a social networking application, etc.)
[1306] The device description can include a device identifier and a model identifier that identifies the model of the device, the device description used to lookup forecast data and/or event data for the device in peer data store 31_1622. Once mobile device 31_100 and mobile device 31_1600 have exchanged forecast and/or event data, the mobile devices can use the exchanged information to determine when to communicate with each other using the remote admission control mechanism below. By allowing devices to share information only when the information is needed and when the battery state of the devices can support sharing the information
(Mobile device determines, depending on the data relating to communication/connection state with another mobile device, to use a type of communication interface (Bluetooth, Wi-Fi) to communicate and an e-mail address (access parameter) for access to another communication device sharing the e-mail address and able to communicate with the mobile device)), and
transmitting said notification to said communication device
([1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906
(Mobile device receives message notification from server));
a communication device, accessible via said access parameter comprising means for receiving said notification and routing said notification to said mobile terminal depending on said at least one identifier of said mobile terminal
([0940] FIG. 23E, in response to detecting a selection of the selectable user interface element shown in suggestions portion 2307, the device updates the text-input field to include the address that was shown in the suggestions portion 2307, the address may correspond to an address shared with the user by other users (e.g., via email, a social networking application, etc.)
[2217] A communication application (e.g., instant messaging, text messaging, email, telephone, etc.) can remind the user about a received message. Each of these notifications, reminders, alerts, etc., is directed to the user and will prompt or cause the user to interact with the computing device
[1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906
[1216] Push notification server 31_906 can store a mapping of device tokens (e.g., identifier for mobile device 31_100) to push filters 31_914 for each mobile device serviced by push notification server 31_906. Push filters 31_914 can include information identifying applications that have received authorization to receive push notifications on mobile device 31_100, for example
(Mobile device receives message notification from server, based on the address shared with the user by other users and mobile device identifier)).
Regarding claim 13, Marcellino, in view of Gross, teaches the system of claim 12,
wherein said communication device comprises a server of a telecommunication operator able to communicate with said mobile terminal
([1214] Mobile device 31_100 can be configured to receive push notifications. For example, a push notification can be a message that is initiated by a push provider 31_902 and sent to a push service daemon 31_904 running on mobile device 31_100 through push notification server 31_906).
Regarding claim 14, Gross teaches
a non-transitory computer-readable medium having stored thereon instructions which, when executed by a processor, cause the processor to implement the method of claim 1
([0007] Executable instructions for performing these functions are, optionally, included in a non-transitory computer-readable storage medium or other computer program product configured for execution by one or more processors).
Conclusion
Citation of Pertinent Prior Art not Applied
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kulkarni, et al (US PG Publication 2019/0191219), hereafter Kulkarni, teaches parameters regulate and restrict access to a preview segment by a non-subscriber presentation device. The server system receives an access request from a non-subscriber presentation device that is processed to determine access parameters for the preview segment applicable to the requesting device, and access is granted or denied based on the determined access parameters.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Examiner Frank Donado whose telephone number is (571) 270-5361. The examiner can normally be reached Mondays through Fridays between 8 am and 4 pm.
Examiner interviews are available via telephone 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 Patent Examiner (SPE) Charles Appiah can be reached at 571-272-7904. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov.
Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FRANK E DONADO/Examiner, Art Unit 2641
/CHARLES N APPIAH/Supervisory Patent Examiner, Art Unit 2641
Prosecution Insights