DETAILED ACTION
Response to Amendment
This Action is in response to the amendment dated 11/20/2025, 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. This Action is made FINAL.
Response to Arguments
Applicant's arguments filed 11/20/2025 have been fully considered, but are not persuasive.
On page 7 of the arguments, the applicant argues Herrick does not describe at least "determining, depending on said at least one obtained datum, a connectivity 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 connectivity.", stating that this feature, as recited, is distinct from the mere selection of an address or channel for message delivery. Rather, amended Claim 1 recites explicitly determining the type or mode of connectivity - such as Wi-Fi, cellular, Bluetooth, etc. - that will be used for communication with the mobile terminal and also stating that Herrick describes a system, SMES 110, that manages the registration of channels, which are associated with device identifiers, application identifiers, and push addresses. See Herrick, at para. [0065]. The push address or channel is used as the destination for notifications. See Herrick, at paras. [0066], [0094], and [0095].
Examiner respectfully disagrees.
Rather, amended Claim 1 reciting explicitly determining the type or mode of connectivity - such as Wi-Fi, cellular, Bluetooth, etc., the connectivity being related to Wi-Fi, cellular, Bluetooth or otherwise is not recited explicitly in any of the claims. It is also not recited implicitly in any of the claims, because determining a type of connectivity does not imply (state indirectly) a determination is made of a type of network. For example, determining a type of connectivity could simply mean determining a secure type of connection or determining a type of connection with a particular quality or priority. In the case of Herrick, a secure type of connection is determined, and therefore, a type of secure connectivity. Regarding the limitations actually recited by amended claim 1, based on this amendment, the rejection now includes citations not related to the selection of an address or channel for message delivery, and as explained in the newly cited [0047] and [0062], the SMES determines an HTTS secured, encrypted type of connection used to communicate with the device and token used for accessing the event notification, based on filtered data regarding different types of information, including notifications received within the last 2 minutes, notifications of OPEN or SEND type, notifications that match users with a particular name and others, the different types of information used for the filtering being a piece of information and thus a datum used for the device to receive the event notifications, indicating Herrick discloses determining, depending on said at least one obtained datum (filtered data), a connectivity (secured/encrypted connection) to be used to communicate with said mobile terminal and an access parameter (token used to access the notifications) for access to at least one communication device able to communicate with said mobile terminal depending on the determined connectivity, as required by the claim.
In making the argument, applicant also states amended Claim 1 explicitly recites determining the type or mode of connectivity and subsequently states Herrick does not describe any process or logic for dynamically determining or selecting among multiple types of connectivity - such as Wi-Fi, cellular, Bluetooth, etc. - for communication with the mobile terminal. However, nowhere in any of the claims is there any limitation that includes dynamically determining or selecting any information, much less dynamically determining or selecting among multiple types of connectivity - such as Wi-Fi, cellular, Bluetooth, etc. Therefore, in response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a process or logic for dynamically determining or selecting among multiple types of connectivity - such as Wi-Fi, cellular, Bluetooth, etc. - for communication with the mobile terminal) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Three-Prong Test
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure (such as “printer means”), material, or acts for performing the claimed function.
This application includes one or more claim limitations that use the word “means,” and are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the word “means” is modified by functional language and is linked by a transition word without reciting sufficient structure to perform the recited function, and the word “means” is not preceded by a structural modifier. Such claim limitation(s) are: “means for receiving said notification” in claim 12.
By virtue of their dependency on claim 12, claim 13 is also being
interpreted under 35 U.S.C. 112(f).
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is modified by functional language and is linked by a transition word without reciting sufficient structure to perform the recited function, and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) are: “module for receiving…”, “module for obtaining…”, “module for determining…” and “module for transmitting…” in claim 10.
By virtue of their dependency on claim 10, claim 11 is also being
interpreted under 35 U.S.C. 112(f).
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
More specifically, at least the paragraphs from the specification recite sufficient structure, material, or acts to entirely perform the recited functions from claims 10 and 12.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-7 and 9-14 are rejected under 35 U.S.C. 102(a1) as being anticipated by Herrick, et al (US PG Publication 2020/0153922), hereafter Herrick.
Regarding claim 1, Herrick 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
([0019] SMES 110 may include one or more server computers
[0031] The identifiers comprising messages associated with a received mobile event notification received by SMES 110 may comprise, at least, an applicationID, a deviceID
(Device 120 receives mobile event notification from SMES server 110, the message/notification comprising deviceID, applicationID));
obtaining, based on said at least one identifier of said mobile terminal, at least one datum relating to the connectivity of said mobile terminal
([0031] The identifiers comprising messages associated with a received mobile event notification received by SMES 110 may comprise a deviceID
[0047] The SMES 110 contains an HTTP server and generates a secure encrypted connection for communication between a customer device 120 and the SMES 110. For example, the mobile event token stream 216 comprises a HTTPS connection for this secured communication
[0062] The received HTTP POST request also contains one or more filter preferences defining one or more filters to be associated with the generated stream. Filters defined in this way, may allow a customer associated with a customer device 120 to indicate one or more mobile event tokens associated with a received mobile notification that the customer is interested in
(The SMES determines filter data (datum) that relates to connection for secured encrypted type of communication, based on the deviceid included in the mobile event notification));
determining, depending on said at least one obtained datum, a type of connectivity 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 connectivity
([0047] The SMES 110 contains an HTTP server and generates a secure encrypted connection for communication between a customer device 120 and the SMES 110. For example, the mobile event token stream 216 comprises a HTTPS connection for this secured communication
[0062] The received HTTP POST request also contains one or more filter preferences defining one or more filters to be associated with the generated stream. A customer device 120 to indicate one or more mobile event tokens associated with a received mobile notification that the customer is interested in. For example, a customer may specify a filter to only receive mobile event tokens that occurred on an iOS™ device, in the last two minutes, pertaining to the generated push, “fae0658c-930e-4f66-bc78-80f46222bc8c”, are of the “OPEN” or “SEND” type, and match the user named “Coolest User Ever.”
(The SMES determines secured encrypted type of connection used to communicate with the device and token used for accessing the notification (parameter), based on the filter data (datum))); and
transmitting said notification to said communication device accessible via said access parameter
([0036] Based on the destination associated with a generated mobile event token, the SMES 110 may transmit the mobile event token to device 120 over network 140
[0062] A customer associated with a customer device 120 to indicate one or more mobile event tokens associated with a received mobile notification that the customer is interested in. For example, a customer may specify a filter to only receive mobile event tokens that occurred on an iOS™ device, in the last two minutes, pertaining to the generated push, “fae0658c-930e-4f66-bc78-80f46222bc8c”, are of the “OPEN” or “SEND” type, and match the user named “Coolest User Ever.”
(Notification to communication device, based on the token (parameter) being associated with a received notification and transmitted and made accessible to device)).
Regarding claim 2, Herrick 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
([0028] A mobile event source is a user device 130 running an app 132 associated with a customer device 120
[0029] The SMES 110 may receive a mobile event notification from user device 130 comprising a message and a destination that is a network address associated with the customer device 120 configured to receive data streams from SMES 110. For example, the destination may be a specified universal resource locator (URL), e.g., www.customer.com/proxyserver (IP address/terminal identifier)
(The event notification is sent/routed from the communication device (user device 130) to the device 120 through usage of network/IP address/URL (terminal identifier), the event sent to app 132 associated with a customer device 120)).
Regarding claim 3, Herrick teaches the method of claim 1,
wherein the obtaining step also depends on said identifier of said application
([0031] The identifiers comprising messages associated with a received mobile event notification received by SMES 110 may comprise an applicationID, a deviceID
[0047] The SMES 110 contains an HTTP server and generates a secure encrypted connection for communication between a customer device 120 and the SMES 110. For example, the mobile event token stream 216 comprises a HTTPS connection for this secured communication
[0062] The received HTTP POST request also contains one or more filter preferences defining one or more filters to be associated with the generated stream
(The SMES determines filter data (datum) that relates to connection for secured encrypted type of communication, also based on application identifier))
Regarding claim 4, Herrick teaches the method of claim 1,
wherein the reception step is followed by a step of storing said notification
([0040] The mobile event notifications received by the SMES 110 via network 140 from one or more user devices 130 or IoT devices 150, may be received by, and stored in an event source repository 210
(The mobile event notification is received and then stored in an event source repository 210)).
Regarding claim 5, Herrick 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
([0082] The load balancer 362 also may monitor the status and quality of the connection between the SMES 110 and the customer device 120 via network 140 periodically by pinging the destination address associated with the customer device 120
(Device 120 receives pinging data to determine connection quality regarding communication interface between the SMES server 110 and the device 120)).
Regarding claim 6, Herrick 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
([0063] To facilitate the various SMES 110 services, a customer associated with a customer device 120 may create an account with SMES 110 using the user accounts application 330 for storing customer provided information in customer account database 352, which may store customer profile information including filter preferences, event types, customer server destination, and predictive and automation settings for registered users. The customer account database 352 may also store additional services that the customer device 120 would like to interface with including the number of active streams associated with the customer device 120. A customer may specify a filter to only receive mobile event tokens that occurred on an iOS™ device, in the last two minutes, pertaining to the generated push, “fae0658c-930e-4f66-bc78-80f46222bc8c”, are of the “OPEN” or “SEND” type, and match the user named “Coolest User Ever.”
(Connectivity includes a preference/priority indicated to filter out particular devices and only receive mobile event communications from other particular devices (iOS device in the example given) over communication interface of the device 120)).
Regarding claim 7, Herrick teaches the method of claim 1,
wherein said at least one connectivity datum comprises a quality indicator associated with said at least one communication interface of said mobile terminal
([0082] The load balancer 362 also may monitor the status and quality of the connection between the SMES 110 and the customer device 120 via network 140 periodically by pinging the destination address associated with the customer device 120
(Device 120 receives pinging data to determine connection quality regarding communication interface between the SMES server 110 and the device 120)).
Regarding claim 9, Herrick teaches the method of claim 1,
wherein said at least one connectivity datum comprises a connection state of at least one server located in the network
([0082] The load balancer 362 also may monitor the status and quality of the connection between the SMES 110 and the customer device 120 via network 140 periodically by pinging the destination address associated with the customer device 120
(Device 120 receives pinging data to determine connection quality of the SMES server 110)).
Regarding claim 10, Herrick 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
([0019] SMES 110 may include one or more server computers
[0031] The identifiers comprising messages associated with a received mobile event notification received by SMES 110 may comprise, at least, an applicationID, a deviceID
[0036] Based on the destination associated with a generated mobile event token, the SMES 110 may transmit the mobile event token to device 120 over network 140
(Device 120 receives mobile event notification from SMES server 110, the message/notification comprising deviceID, applicationID));
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
([0031] The identifiers comprising messages associated with a received mobile event notification received by SMES 110 may comprise a deviceID
[0047] The SMES 110 contains an HTTP server and generates a secure encrypted connection for communication between a customer device 120 and the SMES 110. For example, the mobile event token stream 216 comprises a HTTPS connection for this secured communication
[0062] The received HTTP POST request also contains one or more filter preferences defining one or more filters to be associated with the generated stream. Filters defined in this way, may allow a customer associated with a customer device 120 to indicate one or more mobile event tokens associated with a received mobile notification that the customer is interested in
(The SMES determines filter data (datum) that relates to connection for secured encrypted type of communication, based on the deviceid included in the mobile event notification));
a module for determining, depending on said at least one obtained datum, a type of connectivity 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 connectivity
([0047] The SMES 110 contains an HTTP server and generates a secure encrypted connection for communication between a customer device 120 and the SMES 110. For example, the mobile event token stream 216 comprises a HTTPS connection for this secured communication
[0062] The received HTTP POST request also contains one or more filter preferences defining one or more filters to be associated with the generated stream. A customer device 120 to indicate one or more mobile event tokens associated with a received mobile notification that the customer is interested in. For example, a customer may specify a filter to only receive mobile event tokens that occurred on an iOS™ device, in the last two minutes, pertaining to the generated push, “fae0658c-930e-4f66-bc78-80f46222bc8c”, are of the “OPEN” or “SEND” type, and match the user named “Coolest User Ever.”
(The SMES determines secured encrypted type of connection used to communicate with the device and token used for accessing the notification (parameter), based on the filter data (datum)));
a module for transmitting said notification to said communication device via said access parameter
([0036] Based on the destination associated with a generated mobile event token, the SMES 110 may transmit the mobile event token to device 120 over network 140
[0062] A customer associated with a customer device 120 to indicate one or more mobile event tokens associated with a received mobile notification that the customer is interested in. For example, a customer may specify a filter to only receive mobile event tokens that occurred on an iOS™ device, in the last two minutes, pertaining to the generated push, “fae0658c-930e-4f66-bc78-80f46222bc8c”, are of the “OPEN” or “SEND” type, and match the user named “Coolest User Ever.”
(Notification to communication device, based on the token (parameter) being associated with a received notification and transmitted and made accessible to device)).
Regarding claim 11, Herrick teaches the device of claim 10,
wherein the device includes said communication device
([0048] The SMES 110 depicted in FIG. 3 may comprise a network interface module 310 to enable communication with one or more user devices 130 and IoT devices 150
(communication with one or more user devices 130 and IoT devices 150).
Regarding claim 12, Herrick 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
([0019] SMES 110 may include one or more server computers
[0031] The identifiers comprising messages associated with a received mobile event notification received by SMES 110 may comprise, at least, an applicationID, a deviceID
[0036] Based on the destination associated with a generated mobile event token, the SMES 110 may transmit the mobile event token to device 120 over network 140
(Device 120 receives mobile event notification from SMES server 110, the message/notification comprising deviceID, applicationID)),
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
([0065] Channels associated with SMES 110 are communication and data channels. A registered channel comprises: deviceID
[0066] The SMES 110 associates a channel and enables the communication of generated notifications to each device associated with a generated channel
(The device 120 obtains a connection over data channels, based on the deviceID)),
Determining a type of connectivity 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 connectivity depending on said at least one obtained connectivity datum
([0065] Channels associated with SMES 110 are communication and data channels. A registered channel comprises: deviceID and metadata (e.g., named user) and may include additional properties such as push address, NamedUserID
[0066] The SMES 110 associates a channel for each device to the Named User “john_doe_123”. Customer device 120 may utilize a Named User to send messages. The SMES 110 may maintain a mapping of a Named User to one or more User Devices 130 including IoT Devices 150
(The device 120 determines, based on the data channels, a Named User that the device 120 utilizes to send messages to (communicate with) communication device (user device 130 or IoT device 150))), and
transmitting said notification to said communication device
([0066] A customer device 120 may utilize a Named User to send messages. The SMES 110 may maintain a mapping of a Named User to one or more User Devices 130 including IoT Devices 150
[0093] For delivering, receiving, and processing mobile event notifications to one or more devices (e.g., user device 130 and IoT device 150). The process begins at 510 when the SMES 110 receives an API request from a customer device 120 to create a channel 520
[0094] Once a channel is created a user may associate 530 one or more user devices 130 including one or more IoT devices 150 with the SMES 110. A request to associate a device may comprise a NamedUserID
(The device 120 transmits event notification to communication device (user device 130 or IoT device 150), based on the Named User that the device 120 utilizes to send messages)));
a communication device, accessible via said access parameter comprising means for receiving said notification
([0066] A customer device 120 may utilize a Named User to send messages. The SMES 110 may maintain a mapping of a Named User to one or more User Devices 130 including IoT Devices 150
[0093] For delivering, receiving, and processing mobile event notifications to one or more devices (e.g., user device 130 and IoT device 150). The process begins at 510 when the SMES 110 receives an API request from a customer device 120 to create a channel 520
[0094] Once a channel is created a user may associate 530 one or more user devices 130 including one or more IoT devices 150 with the SMES 110. A request to associate a device may comprise a NamedUserID
(The communication device (user device 130 or IoT device 150) receives notification from device 120, based on the Named User that the device 120 utilizes to send messages)))
and
routing said notification to said mobile terminal depending on said at least one identifier of said mobile terminal
([0028] A mobile event source is a user device 130 running an app 132 associated with a customer device 120
[0029] The SMES 110 may receive a mobile event notification from user device 130 comprising a message and a destination that is a network address associated with the customer device 120 configured to receive data streams from SMES 110. For example, the destination may be a specified universal resource locator (URL), e.g., www.customer.com/proxyserver (IP address/terminal identifier)
(The event notification is sent/routed from the communication device (user device 130) to the device 120 through usage of network/IP address/URL (terminal identifier), the event sent to app 132 associated with a customer device 120)).
Regarding claim 13, Herrick teaches the system of claim 12,
wherein said communication device comprises a server of a telecommunication operator able to communicate with said mobile terminal
([0019] SMES 110 may include one or more server computers
[0036] Based on the destination associated with a generated mobile event token, the SMES 110 may transmit the mobile event token to device 120 over network 140
(Device 120 receives mobile event notification from (communicates with) SMES server 110)).
Regarding claim 14, Herrick 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
([0097] The computer 600 can be used as part or all of the systems described, for example, the customer device 120, with memory 606 and storage device 608
[0098] The storage device 608 is any non-transitory computer-readable storage medium. The memory 606 holds software (comprised of instructions) and data used by the processor 602).
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Herrick, in view of Raley (US PG Publication 2016/0063223).
Regarding claim 8, Herrick teaches the method of claim 1.
Herrick does not teach
wherein the determination step also depends on an access rights datum associated with the secure hardware element.
In the same field of endeavor, Raley teaches
wherein the determination step also depends on an access rights datum associated with the secure hardware element
([0077] The license location information may be a unique URL corresponding to the received rights package that allows a requester to request a license to the content associated with content location information
(determining URL connection data is based on rights to access content)).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the invention of Herrick, which includes receiving information, based on access parameter, to include Raley’s teaching of receiving information, based on access parameter associated with access rights, for the benefit of federated control of content (see [0002]).
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.
Li, et al (US PG Publication 2021/0314795), hereafter Li, teaches communicating a notification message that includes the ID of the application, where the notification message is used to indicate to perform data collection on the application.
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 extension fee 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 date of this final action.
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