DETAILED ACTION
The Response to the Requirement for Restriction/Election filed on 5/28/26 has been entered. Claims 1-4, 10-15 and 17 have been elected, claims 5-9 have been withdrawn-amended, claim 16 has been canceled and claim 19 has been added.
Claims 1-15, 17 and 19 are pending.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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 .
Election/Restrictions
Applicant’s election with traverse of Group I: claims 1-4, 10-15 and 17 in the reply filed on 5/28/26 is acknowledged.
Applicant has amended claims 5-9 to depend from new claim 19. Accordingly, non-elected claims 5-9 will be rejoined and reconsidered along with elected claims 1-4, 10-15 and 17.
Claims 1-15, 17 and 19 are presented for examination.
Paper Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Information Disclosure Statement(s) as received on 5/9/24 and 5/28/24 are considered by the Examiner.
Allowable Subject Matter
Claim 7 is objected to as being dependent upon a rejected base claim, but would be allowable if the Objections to the Specification and Claim Objections listed in the paragraph(s) below are corrected and the claim is rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The disclosure is objected to because of the following informalities:
Typically abbreviations/acronyms are used after an expansion is provided to the abbreviations/acronyms. However, in the Specification, “RFC,” “IETF,” “ROM,” “CD-ROM,” “DYOS,” “HTTP,” “WebRTC,” “WLAN,” “QUIC,” “POST,” “URI,” etc. are used before they are expanded. It is suggested to use expansions before using their abbreviations/acronyms. Appropriate correction is required.
Claim Objections
Claims 1-15, 17 and 19 are objected to because of the following informalities:
The phrases “such that” and “so as” in claims 1, 10, 13, 15, 17 and 19 should be avoided. Appropriate correction is required. It is unclear whether the limitations following the phrases “such that” and “so as” are part of the claimed invention.
The limitation “…said triggering conditional upon…” in claim 2, lines 1-2, should be “…said triggering is conditional upon…” (emphasis added) in order to resolve the typographical/grammatical error in the limitations. Appropriate correction is required.
The limitation “…selecting said at least one checking entity on based on at least one constraint…” in claim 3, lines 1-2, should be “…selecting said at least one checking entity [[on]] based on at least one constraint…” (emphasis added) in order to resolve the typographical/grammatical error in the limitations. Appropriate correction is required.
The numbering of amended claims 5-9 is not appropriate. Amended claims 5-9 depend from new independent claim 19. Dependent claims should follow their corresponding independent claim. In the instant case, claims 5-9 should be cancelled and these claims should be added after claim 19. Appropriate correction is required.
The limitation “…the checking entity…” in claim 5, line 11, should be “…the at least one checking entity…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required. Similar corrections are required in claim 6, lines 2 and 5; claim 7, line 2; claim 8, line 2 and 3-4; and claim 9, lines 2, 3-4 and 5.
The limitation “…receiving data conveyed…” in claim 5, line 12, should be “… receive data conveyed…” (emphasis added) in order to resolve the typographical/grammatical error in the limitations. Appropriate correction is required.
The limitation “…in relation to the user being obtained from said received data, on the basis of said at least one obtained item of identification information, updating a digital identity…” in claim 5, lines 14-16, should be “…in relation to the user being obtained from said received data, update a digital identity…” (emphasis added) in order to resolve the typographical/grammatical error in the limitations. Appropriate correction is required.
The limitation “…relaying said data…” in claim 5, line 18, should be “… relay said data…” (emphasis added) in order to resolve the typographical/grammatical error in the limitations. Appropriate correction is required.
The last limitation recited in claim 8 should be preceded by a connecting word such as “and” or “or” (emphasis added). Appropriate correction is required.
The limitation “…redirection of data…” in claim 13, line 8, should be “…redirection of the data…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required.
The limitation “…the control entity…” in claim 19, line 9, should be “…the at least one control entity…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required.
The limitation “…for the provision of the service…” in claim 19, lines 12-13, should be “…for [[the]] provision of the service…” (emphasis added) in order to resolve the lack of antecedent basis in the limitations. Appropriate correction is required.
All dependent claims are objected to as having the same deficiencies as the claims they depend from.
Note: For examination purposes, the claims will be interpreted based on the claim language suggested by the Examiner.
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-5, 8, 10-13, 15, 17 and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “Wynn et al.” (US PGPUB 2011/0040870) (Hereinafter Wynn).
With respect to claim 1, Wynn teaches a control method (Abstract) for controlling a check carried out on data conveyed in at least one communication network (local area network 106 and/or communication network 114; Fig. 1, [0053]) when a first device (digital device 102; Fig. 1, [0052]) of a user accesses a service provided by a second device via a primary connection established between the first and the second device (network credential request form may also receive the SSID as a network service selection. In one example, the network credential request form comprises a pull down menu of different service providers and/or hotspots that the user may select. For example, a user may select “Starbucks” or “San Francisco International Airport” as a hotspot. The user may be given further options to such as geographic locations of the hotspot. The user may also select the service provider. For example, the user may select “T-Mobile” as a service provider; Fig. 1, [0109]), said method being implemented by a control entity and comprising:
triggering, with a coordinating entity, a configuration of the service such that the data conveyed on said primary connection and on at least one secondary connection established on fringes of said primary connection (communication network interface (com. network interface) 908 can be coupled to a network (e.g., the local area network 106 and communication network 114) via the link 912. The communication network interface 908 may support communication over an Ethernet connection, a serial connection, a parallel connection, or an ATA connection, for example. The communication network interface 908 may also support wireless communication (e.g., 802.11 a/b/g/n, WiMax); Figs. 1 and 9, [0119], [0175]) for provision of the service pass through at least one checking entity selected by said control entity to analyze said data (the digital device 102 first enters into a hotspot, the digital device 102 may scan for the local area network 106. As a result of the scan, the network device 104 may provide network configuration information. The network configuration information may comprise one or more IP addresses for access to the DNS server 110. A credential request is generated by the digital device 102. Subsequently, the credential request may be sent to the DNS server 110 using one of the IP addresses previously received from the network device 104. Based on the credential request, the credential server 116 is identified by the DNS server 110. In other embodiments, the DNS server 110 forwards the credential request to the credential server 116; Figs. 1 and 3, [0077]-[0079]); and
notifying said coordinating entity, in response to a determined event being detected in a digital identity of said user conveyed when accessing said service and comprising identification information in relation to the user obtained from said data analyzed by said at least one checking entity (credential server 116 identifies the network credential needed based on the credential request. For example, the credential request may comprise an identifier (i.e., the DDID) for the digital device 102 as well as an identifier for the hotspot SSID (e.g., the service provider such as an operator). The identifiers may be compared against a table (e.g., network record) of such identifiers by the credential request module 204 or the credential request response module 206 to determine the proper network credential. Network device 1006 acts as a proxy by providing the attributes and list via DNS to the rules server 1010. Rules server 1010 retrieves the network identifiers from the list and retrieves network profiles associated with the network identifiers; Figs. 1, 3, 10 and 13, [0079]-[0080], [0088], [0142], [0175]-[0177]).
With respect to claim 2, Wynn teaches the control method as claimed in claim 1, wherein said triggering conditional upon prior acceptance of said coordinating entity to carry out the analysis of said data (the digital device 102 transmits a request to the credential server 116 to determine if the communication network 114 is available. In some embodiments, the query or command contains the sequence identifier previously submitted within the credential request. If network access is successful, the credential server 116 may receive the request and retrieve the sequence identifier. The credential server 116 may then confirm that network access was successful; Fig. 1, [0105]).
With respect to claim 3, Wynn teaches the control method as claimed in claim 1, comprising selecting said at least one checking entity on based on at least one constraint of said service that is predetermined or transmitted by said coordinating entity (the digital device 102 first enters into a hotspot, the digital device 102 may scan for the local area network 106. As a result of the scan, the network device 104 may provide network configuration information. The network configuration information may comprise one or more IP addresses for access to the DNS server 110. A credential request is generated by the digital device 102. Subsequently, the credential request may be sent to the DNS server 110 using one of the IP addresses previously received from the network device 104. Based on the credential request, the credential server 116 is identified by the DNS server 110. In other embodiments, the DNS server 110 forwards the credential request to the credential server 116; Fig. 1, [0053], [0057], [0077]-[0080]).
With respect to claim 4, Wynn teaches the control method as claimed in claim 1, wherein the triggering comprises providing said coordinating entity with reachability information in relation to said at least one checking entity (credential server 116 identifies the network credential needed based on the credential request. For example, the credential request may comprise an identifier (i.e., the DDID) for the digital device 102 as well as an identifier for the hotspot SSID (e.g., the service provider such as an operator). The identifiers may be compared against a table (e.g., network record) of such identifiers by the credential request module 204 or the credential request response module 206 to determine the proper network credential. Network device 1006 acts as a proxy by providing the attributes and list via DNS to the rules server 1010. Rules server 1010 retrieves the network identifiers from the list and retrieves network profiles associated with the network identifiers; Fig. 1, [0053], [0057], [0077]-[0080]).
The limitations of claims 10, 15, 17 and 19 are rejected in the analysis of claim 1 above and these claims are rejected on that basis. Furthermore, Wynn discloses entity/entities comprising processor(s) and non-transitory computer readable medium (Fig. 9, [0115]-[0117]) as recited in claims 15, 17 and 19.
With respect to claim 5, Wynn teaches the checking system of claim 19, wherein the checking system further comprises the at least one checking entity, wherein each of the at least one checking entity comprises:
at least one second processor (processor 900; Fig. 9, [0115]); and
at least one second non-transitory computer readable medium comprising instructions stored thereon which when executed by the at least one second processor (memory system 902 and the storage system 904 comprise computer readable media which may store instructions or programs that are executable by a computer processor including the processor 900; Fig. 9, [0115]-[0117]) configure the checking entity to:
receiving the data conveyed via said primary connection and/or at least one of the at least one secondary connection (the digital device 102 first enters into a hotspot, the digital device 102 may scan for the local area network 106. As a result of the scan, the network device 104 may provide network configuration information. The network configuration information may comprise one or more IP addresses for access to the DNS server 110. A credential request is generated by the digital device 102. Subsequently, the credential request may be sent to the DNS server 110 using one of the IP addresses previously received from the network device 104. Based on the credential request, the credential server 116 is identified by the DNS server 110. In other embodiments, the DNS server 110 forwards the credential request to the credential server 116; Figs. 1 and 3, [0077]-[0079]);
in response to at least one item of the identification information in relation to the user being obtained from said received data, on the basis of said at least one obtained item of identification information, updating the digital identity of the user conveyed when accessing said service; and relaying said data to a recipient of said data (credential server 116 identifies the network credential needed based on the credential request. For example, the credential request may comprise an identifier (i.e., the DDID) for the digital device 102 as well as an identifier for the hotspot SSID (e.g., the service provider such as an operator). The identifiers may be compared against a table (e.g., network record) of such identifiers by the credential request module 204 or the credential request response module 206 to determine the proper network credential. Network device 1006 acts as a proxy by providing the attributes and list via DNS to the rules server 1010. Rules server 1010 retrieves the network identifiers from the list and retrieves network profiles associated with the network identifiers; Figs. 1, 3, 10 and 13, [0079]-[0080], [0088], [0142], [0175]-[0177]).
With respect to claim 8, Wynn teaches the checking system as claimed in claim 5, wherein the instructions further configure the checking entity to report to said at least one control entity, at least one event detected by the checking entity from among: a new data collection platform involved when accessing said service; a level of exposure of identification information in relation to the user above a given threshold; new user identification information detected by said at least one checking entity in said analyzed data; user identification information transmitted to a third-party entity that does not comply with terms and conditions of use of said service approved by said user (once a connection is established, the new attributes are provided to the rules server 1010 or profile server 1014 to update the network profile associated with the network device 1004; Fig. 10, [0179]-[0181], [0225]-[0228]).
With respect to claim 11, Wynn teaches the configuration method as claimed in claim 10, wherein the configuring is preceded by checking whether said control entity is authorized to trigger analysis of said data by said at least one checking entity (rules server 1010 provides the wireless network selection and credentials via DNS back to the network device 1006 to function as a proxy to send the information to the digital device 1002; Fig. 10, [0179]).
With respect to claim 12, Wynn teaches the configuration method as claimed in claim 10, comprising transmitting, to said control entity, at least one constraint of said service to be taken into account to select said at least one checking entity (rules server 1010 selects one or more wireless networks from the list of available wireless networks based on the attribute analysis. In one example, the rules server 1010 applies rules to the attributes. The rules may comprise minimum requirements, personalized settings, and attribute comparisons; Fig. 10, [0135], [0138]).
With respect to claim 13, Wynn teaches the configuration method as claimed in claim 10, wherein the configuring comprises triggering: modification of a domain name resolution mechanism so as to include reachability information in relation to said at least one checking entity; or activation of a service function chaining mechanism involving said at least one checking entity; or a routing mechanism at a source; or redirection of data to said at least one checking entity (rules server 1010 selects one or more wireless networks from the list of available wireless networks based on the attribute analysis. In one example, the rules server 1010 applies rules to the attributes. The rules may comprise minimum requirements, personalized settings, and attribute comparisons; Fig. 10, [0135], [0138]).
Claim Rejections - 35 USC § 103
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 of this title, 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.
Claims 6, 9 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Wynn in view of “Froger” (US PGPUB 2019/0166210).
With respect to claim 6, Wynn teaches the checking system as claimed in claim 5. Wynn does not teach comprising wherein the instructions further configure the checking entity to analyze the received data to determine whether the received data convey the at least one item of identification information in relation to the user, said analyzing using at least one parameter with which said checking entity has been configured beforehand and/or that the checking entity has acquired via executing a machine learning algorithm.
However, Froger teaches comprising wherein the instructions further configure the checking entity to analyze the received data to determine whether the received data convey the at least one item of identification information in relation to the user, said analyzing using at least one parameter with which said checking entity has been configured beforehand and/or that the checking entity has acquired via executing a machine learning algorithm (in order to select a contents server 50-1 which is close to the user terminal independently of the access network to which this terminal connects, the DNS server 210 can use a lookup table of correspondence between location indications of various access networks; Fig. 1, [0041], [0078]).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate analyzing data using parameters to Wynn because Wynn discloses analyzing data ([0080]) and Froger suggests analyzing data using parameters ([0078]).
One of ordinary skill in the art would be motivated to utilize the teachings of Froger in the Wynn system in order to provide more effective data analysis.
With respect to claim 9, Wynn teaches the checking system as claimed in claim 5. Wynn does not teach wherein the instructions further configure the checking entity to send, to the first device, a header comprising reachability information in relation to said checking entity, said header indicating to said first device that the first device should send domain name resolution requests to said checking entity.
However, Froger teaches wherein the instructions further configure the checking entity to send, to the first device, a header comprising reachability information in relation to said checking entity, said header indicating to said first device that the first device should send domain name resolution requests to said checking entity (terminal contacts its primary DNS server 100 which itself invokes the authority DNS server 120 for the name of the host of the contents server 50-2 and which can therefore actually provide the IP address of this server exhibiting the content which the terminal 10 wishes to access. The terminal 10 dispatches a DNS request to the authority DNS server 210 of the CDN server indicated in the response message dispatched; Fig. 1, [0070]-[0072]).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate sending reachability information of an entity to Wynn because Wynn discloses sending requests to an entity ([0078]) and Froger suggests sending reachability information of an entity ([0070]).
One of ordinary skill in the art would be motivated to utilize the teachings of Froger in the Wynn system in order to provide more effective data redirection.
With respect to claim 14, Wynn teaches the configuration method as claimed in claim 13. Wynn does not teach wherein the configuring comprises triggering the modification of the domain name resolution mechanism, and wherein triggering the modification of the domain name resolution mechanism comprises, on an entity involved in provision of the service, activating sending, to the first device, a header comprising said reachability information in relation to said at least one checking entity, said header indicating to said first device that the first device should send all or some of the first device's domain name resolution requests to said at least one checking entity.
However, Froger teaches wherein the configuring comprises triggering the modification of the domain name resolution mechanism, and wherein triggering the modification of the domain name resolution mechanism comprises, on an entity involved in provision of the service, activating sending, to the first device, a header comprising said reachability information in relation to said at least one checking entity, said header indicating to said first device that the first device should send all or some of the first device's domain name resolution requests to said at least one checking entity (terminal contacts its primary DNS server 100 which itself invokes the authority DNS server 120 for the name of the host of the contents server 50-2 and which can therefore actually provide the IP address of this server exhibiting the content which the terminal 10 wishes to access. The terminal 10 dispatches a DNS request to the authority DNS server 210 of the CDN server indicated in the response message dispatched; Fig. 1, [0070]-[0072]).
It would have been obvious to a person with ordinary skill in the art before the effective filing date of the claimed invention to incorporate sending reachability information of an entity to Wynn because Wynn discloses sending requests to an entity ([0078]) and Froger suggests sending reachability information of an entity ([0070]).
One of ordinary skill in the art would be motivated to utilize the teachings of Froger in the Wynn system in order to provide more effective data redirection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
Imbimbo et al. US 2012/0059913. Discloses controlling communication in an internet protocol multimedia subsystem.
Shaffer et al. US 2020/0259829. Discloses providing access control and identity verification for communications.
Lanc. US 2023/0155818. Discloses multi-party, multi-user sender-receiver authentication method.
Burbridge et al. US 2014/0280963. Discloses selection of service nodes for provision of services.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Johnny B Aguiar whose telephone number is (571)272-3563. The examiner can normally be reached on Monday to Friday 7:30 am - 5:30 pm 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, Joon Hwang can be reached on (571) 272-4036. 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.
/JOHNNY B AGUIAR/
Primary Examiner, Art Unit 2447
September 1, 2026
Prosecution Insights