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 .
DETAILED ACTION
2. This action is in response to the application filed March 22, 2025.
3. Claims 1-26 have been examined and are pending with this action.
4. The Information Disclosure Statement filed May 6, 2025 has been considered.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
5. Claims 1-12, 14-20, and 22-28 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Griffiths et al. (US 2015/0242601 A1).
INDEPENDENT:
As per claim 1, Griffiths teaches a method performed by an electronic device comprising processor circuitry, the method comprising:
receiving media data associated with a media stream, the media data comprising one or both of (1) audio data representative of audio, and (2) video data representative of video (see Griffiths, [0029]: “In one embodiment of the invention, a trust broker (TB) may utilize multiple inputs from various biometric sensors, contextual sensors and user data input (e.g., names, IDs, passwords, PINs, etc.) to manage a two-way interaction between mobile device 100 and an authenticating entity.”);
determining a trust level associated with the media stream based on the media data (see Griffiths, [0029]: “The TB may extract and provision the credentials with an underlying mechanism to provide them. For example, a TB may generate a trust coefficient (TC) and/or a composite trust score that may be provided to the authenticating entity. The trust coefficients, trust scores, results of authentications performed by the mobile device using an authentication system and/or other sensor data, sensor information or data input may be included in one or more fields of a trust vector (TV) that may be provided to the authenticating entity.”); and
providing an output indicative of the trust level (see Griffiths, [0030]: “For example, the TB, responsive to user-established or user-approved preferences, may be configured to reveal personal information such as personal identity only to authenticating entities that the user trusts and to reveal to such authenticating entities only what is necessary, for example, to complete a particular user-desired transaction with a particular authenticating entity.”).
As per claim 27, Griffiths teaches an electronic device comprising an interface, memory circuitry, and processor circuitry, the processor circuitry configured to (see Griffiths, Abstract: “The mobile device may comprise a plurality of sensors and a processor”; and [0021]: “The system may be a computing device (e.g., a mobile device 100), which may include one or more processors 101, a memory 105, an I/O controller 125, and a network interface 110.”):
receive, via the interface, media data associated with a media stream, the media data comprising one or both of audio data representative of audio and video data representative of video (see claim 1 rejection above);
determine a trust level associated with the media stream based on the media data (see claim 1 rejection above); and
provide, via the interface, an output indicative of the trust level (see claim 1 rejection above).
DEPENDENT:
As per claim 2, which depends on claim 1, Griffiths further teaches wherein the audio data comprises audio device data indicative of an audio device used for capturing the audio, and wherein the act of determining the trust level based on the media data comprises determining the trust level based on the audio device data (see Griffiths, [0031]: “The system may be a computing device (e.g., a mobile device 100), which may include one or more processors 101, a memory 105, an I/O controller 125, and a network interface 110.”; [0035]: “As examples of various terms, a trust coefficient (TC) may be a level of trust based upon a composition of one or more inputs, such as user data inputs (e.g., username, password, etc.), sensor inputs (e.g., GPS location input, acceleration input, etc.), biometric sensor inputs (e.g., fingerprint scan from a fingerprint sensor, facial or iris scan from a camera, voiceprint, etc.), or an output of an authentication system.”; [0053]: “… session ID, user name, password, date stamp, time stamp, trust coefficients or trust scores based upon sensor device input from the previously described sensors, fingerprint template information, template information from multiple fingerprints, fingerprint matching score(s), face recognition, voice recognition, face location, behavior aspects, liveness, GPS location, visual location, relative voice location, audio location, relative visual location, altitude, at home or office, on travel or away, etc.”; and [0055]: “It should be appreciated that many of the trust vector components may be available from sensors that are installed on the mobile device, which may be typical or atypical dependent on the mobile device.”).
As per claim 3, which depends on claim 2, Griffiths further teaches wherein the audio device data comprises an audio device signature, and wherein the act of determining the trust level based on the audio device data comprises verifying the audio device signature (see Griffiths, [0054]: “TV components. Additional examples may include one or more TV components associated with sensor output information for iris, retina, palm, skin features, cheek, ear, vascular structure, hairstyle, hair color, eye movement, gait, behavior, psychological responses, contextual behavior, clothing, answers to questions, signatures, PINs, keys, badge information, RFID tag information, NFC tag information, phone numbers, personal witness, and time history attributes, for example.”).
As per claim 4, which depends on claim 2, Griffiths further teaches wherein the audio device data comprises an audio device identifier, wherein the method comprises obtaining an audio key based on the audio device identifier, and the act of determining the trust level based on the audio device data comprises verifying an audio device signature based on the audio key (see Griffiths, [0031]: “In some implementations, data from one or more sensors may be sent directly to the authenticating entity for authentication, while in alternative implementations the data from the sensors may be used (with local authentication) to release one or more credentials for remote authentication, such as encryption keys, a username/password, or a digital certificate.”; and [0056]: “For example, functions controlled by the trust broker may include storing keys and credentials for specific authentication schemes, providing APIs to change user security/privacy settings in response to user security and privacy preferences, providing an appropriate response based on user security/privacy settings, interacting with a CAM/CAE, interacting with an authentication system, or not revealing personal identities or information to unknown requests.”).
As per claim 5, which depends on claim 1, Griffiths further teaches wherein the video data comprises video device data indicative of a video device used for capturing the video, and wherein the act of determining the trust level based on the media data comprises determining the trust level based on the video device data (see claim 2 rejection above).
As per claim 6, which depends on claim 5, Griffiths further teaches wherein the video device data comprising a video device signature, and wherein the act of determining the trust level based on the video device data comprises verifying the video device signature (see claim 3 rejection above).
As per claim 7, which depends on claim 5, Griffiths further teaches wherein the video device data comprises a video device identifier, wherein the method comprises obtaining a video key based on the video device identifier, and wherein the act of determining the trust level based on the video device data comprises verifying a video device signature based on the video key (see claim 4 rejection above).
As per claim 8, which depends on claim 1, Griffiths further teaches wherein the media data comprises communication device data indicative of a communication device used for transmitting the media data, and wherein the act of determining the trust level based on the media data comprises determining the trust level based on the communication device data (see claim 1 & claim 2 rejections above).
As per claim 9, which depends on claim 8, Griffiths further teaches wherein the communication device data comprises a communication device signature, and wherein the act of determining the trust level based on the media data comprises verifying the communication device signature (see claim 3 rejection above).
As per claim 10, which depends on claim 8, Griffiths further teaches wherein the communication device data comprises a communication device identifier, wherein the method comprises obtaining a communication key based on the communication device identifier, and wherein the act of determining the trust level is performed based on the communication key (see claim 4 rejection above).
As per claim 11, which depends on claim 1, Griffiths further teaches wherein the act of determining the trust level comprises determining a trust score, and selecting the trust level from a set of trust levels based on the trust score (see Griffiths, [0035]: “As examples of various terms, a trust coefficient (TC) may be a level of trust based upon a composition of one or more inputs, such as user data inputs (e.g., username, password, etc.), sensor inputs (e.g., GPS location input, acceleration input, etc.), biometric sensor inputs (e.g., fingerprint scan from a fingerprint sensor, facial or iris scan from a camera, voiceprint, etc.), or an output of an authentication system. A trust coefficient may be a composition of one or more data inputs. Each of these inputs may be given scores. In some implementations, the sensor inputs may be given scores to indicate their authentication strength, allowing a composite TC to be generated based on weighted sensor inputs.”).
As per claim 12, which depends on claim 1, Griffiths further teaches wherein the act of providing the output indicative of the trust level comprises providing a first output if the trust level is a first trust level, or providing a second output if the trust level is a second trust level (see Griffiths, [0034]: “For example, a high level of authentication may require input from a variety of sensors, whereas a low level of authentication may require very little if any input from the sensors.”; and [0056]: “For example, if the trust coefficient value becomes too low, the local trust value may lock or limit accessibility to the mobile device until proper authentication by a user is received.”).
As per claim 13, which depends on claim 12, Griffiths further teaches wherein providing the first output comprises displaying a first user interface element on a display and/or outputting a first audio signal via a loudspeaker (see Griffiths, FIG. 2, “USER INTERFACE 216; and [0034]: “These types of authentication messages, authentication requests and authentication responses in the form of privacy vectors and trust vectors will be described in more detail hereinafter. In particular, local trust broker 220 may negotiate with the remote trust broker 222 of the authenticating entity 221 to determine a trust vector (e.g. authentication response 219) that satisfies the predefined user security/privacy preferences such that a suitable authentication response 219 that satisfies the authentication requirements of the authenticating entity 221 may be transmitted to the authenticating entity 221 to authenticate mobile device 100.”).
As per claim 14, which depends on claim 1, Griffiths further teaches wherein the audio data comprises biometric data indicative of biometric sensor data obtained with one or more sensors of an audio device, and wherein the act of determining the trust level associated with the media stream comprises determining the trust level based on the biometric data (see Griffiths, [0035]: “As examples of various terms, a trust coefficient (TC) may be a level of trust based upon a composition of one or more inputs, such as user data inputs (e.g., username, password, etc.), sensor inputs (e.g., GPS location input, acceleration input, etc.), biometric sensor inputs (e.g., fingerprint scan from a fingerprint sensor, facial or iris scan from a camera, voiceprint, etc.), or an output of an authentication system. A trust coefficient may be a composition of one or more data inputs. Each of these inputs may be given scores. In some implementations, the sensor inputs may be given scores to indicate their authentication strength, allowing a composite TC to be generated based on weighted sensor inputs.”).
As per claim 15, which depends on claim 14, Griffiths further teaches wherein the biometric data comprises one or more of EEG data, blood flow data, pulse data, motion data, jaw movement data, ear geometry data, fingerprint data, voiceprint data, ear canal geometry data, or face geometry data (see Griffiths, [0035]: “As examples of various terms, a trust coefficient (TC) may be a level of trust based upon a composition of one or more inputs, such as user data inputs (e.g., username, password, etc.), sensor inputs (e.g., GPS location input, acceleration input, etc.), biometric sensor inputs (e.g., fingerprint scan from a fingerprint sensor, facial or iris scan from a camera, voiceprint, etc.), or an output of an authentication system. A trust coefficient may be a composition of one or more data inputs. Each of these inputs may be given scores. In some implementations, the sensor inputs may be given scores to indicate their authentication strength, allowing a composite TC to be generated based on weighted sensor inputs.”).
As per claim 16, which depends on claim 14, Griffiths further teaches wherein the biometric data comprises a biometric signature, and wherein the act of determining the trust level based on the biometric data comprises verifying the biometric signature (see Griffiths, [0033]: “These types of authenticating entities may require some sort of verification.”; and claim 15 rejection above).
As per claim 17, which depends on claim 16, Griffiths further teaches wherein the act of verifying the biometric signature is performed based on an audio key (see claim 4 rejection above).
As per claim 18, which depends on claim 1, Griffiths further teaches wherein the media data comprises location data indicative of a device location, and wherein the act of determining the trust level associated with the media stream comprises determining the trust level associated with the media stream based on the location data (see Griffiths, [0035]: “s examples of various terms, a trust coefficient (TC) may be a level of trust based upon a composition of one or more inputs, such as user data inputs (e.g., username, password, etc.), sensor inputs (e.g., GPS location input, acceleration input, etc.), biometric sensor inputs (e.g., fingerprint scan from a fingerprint sensor, facial or iris scan from a camera, voiceprint, etc.), or an output of an authentication system. A trust coefficient may be a composition of one or more data inputs. Each of these inputs may be given scores. In some implementations, the sensor inputs may be given scores to indicate their authentication strength, allowing a composite TC to be generated based on weighted sensor inputs.”).
As per claim 19, which depends on claim 18, Griffiths further teaches wherein the location data comprises a location signature, and wherein the act of determining the trust level based on the location data comprises verifying the location signature (see Griffiths, [0033]: “These types of authenticating entities may require some sort of verification.”; and [0054]: “Additional examples may include one or more TV components associated with sensor output information for iris, retina, palm, skin features, cheek, ear, vascular structure, hairstyle, hair color, eye movement, gait, behavior, psychological responses, contextual behavior, clothing, answers to questions, signatures, PINs, keys, badge information, RFID tag information, NFC tag information, phone numbers, personal witness, and time history attributes, for example.”).
As per claim 20, which depends on claim 19, Griffiths further teaches wherein the act of verifying the location signature is performed based on an audio key (see claim 4 rejection above).
As per claim 22, which depends on claim 1, Griffiths further teaches the media data comprising one or more of a connection security parameter, a network identifier, and a connection identifier, and wherein determining a trust level associated with the media stream comprises determining the trust level based on one or more of the connection security parameter, a network identifier, and a connection identifier (see Griffiths, [0030]: “For example, the TB, responsive to user-established or user-approved preferences, may be configured to reveal personal information such as personal identity only to authenticating entities that the user trusts and to reveal to such authenticating entities only what is necessary, for example, to complete a particular user-desired transaction with a particular authenticating entity.”; [0035]: “As examples of various terms, a trust coefficient (TC) may be a level of trust based upon a composition of one or more inputs, such as user data inputs (e.g., username, password, etc.), sensor inputs (e.g., GPS location input, acceleration input, etc.), biometric sensor inputs (e.g., fingerprint scan from a fingerprint sensor, facial or iris scan from a camera, voiceprint, etc.), or an output of an authentication system. A trust coefficient may be a composition of one or more data inputs. Each of these inputs may be given scores. In some implementations, the sensor inputs may be given scores to indicate their authentication strength, allowing a composite TC to be generated based on weighted sensor inputs.”; and [0048]: “The persistence parameter may be, for example, a time constant in which the trust coefficient or trust score decays over time. The persistence parameter may be dynamic, in that the numerical value may change with time, with changes in location or behavior of the user, or with the type of content requested.”).
As per claim 23, which depends on claim 1, Griffiths teaches further comprising controlling a conference between participants based on the trust level (see Griffiths, [0043]: “In one embodiment, the continuous authentication manager 404 may perform functions including interacting with the local TB 220, controlling how and when trust scores for the trust vectors (TVs) are calculated, requesting specific information from the continuous authentication engine 406 when needed (e.g., as requested by the local trust broker 220), providing output to APIs of the mobile device 101 (e.g., device-level trust controls, keyboard locks, unauthorized use, etc.), and/or managing continuous authentication engine 406 (e.g., issuing instructions to or requesting actions from the continuous authentication engine to update trust scores and/or check sensor integrity when trust scores fall below a threshold value, etc.).”; and [0046]: “For example, with reference to trust-broker interaction 510, each device (e.g., Device A--mobile and Device B--authenticating entity such as another mobile device, e.g., peer-to-peer) may include a trust broker that interacts with a continuous authentication manager (CAM) and a continuous authentication engine (CAE) on each device. In another example, a trust-broker interaction 520 conveys an interaction between a user device and a remote (cloud-based) service or application.”).
As per claim 24, which depends on claim 23, Griffiths further teaches wherein the act of controlling the conference based on the trust level comprises determining whether the trust level satisfies a termination criterion, and terminating the conference and/or terminating a connection to a participant in the conference if the trust level satisfies the termination criterion (see Griffiths, [0039]: “In some implementations, the local TB 220 may update one or more components of the trust vector on a continuous basis, and transmit the updated trust vector only when requested by the authenticating entity or when a component of the trust vector falls or degrades below a threshold value.”; and [0040]: “In some implementations, the authentication information may be transmitted or otherwise sent to the authenticating entity continuously, quasi-continuously, periodically, or upon request by the authenticating entity. In some implementations, the authentication information may be transmitted when a component level or value falls below a predetermined threshold level or value. One or more components of the trust vector may be continuously updated within the mobile device to provide continuous authentication. The updated trust vector with the updated authentication information may be sent or otherwise transmitted to the authenticating entity, for example, in a continuous, quasi-continuous or periodic manner, upon request by the authenticating entity, or when one or more components of the trust vector fall below a predetermined threshold level or value.”).
As per claim 25, which depends on claim 1, Griffiths teaches further comprising an interface, memory circuitry, and processor circuitry, the processor circuitry configured to perform the method of claim 1 (see Griffiths, Abstract: “The mobile device may comprise a plurality of sensors and a processor”; and [0021]: “The system may be a computing device (e.g., a mobile device 100), which may include one or more processors 101, a memory 105, an I/O controller 125, and a network interface 110.”).
As per claims 26 and 28, which respectively depend on claims 25 and 27, Griffiths further teaches wherein the electronic device is a communication device or an audio device (see Griffiths, FIG. 5).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
6. Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Griffiths et al. (US 2015/0242601 A1) in view of Houser (US 2004/0181665 A1).
As per claim 21, which depends on claim 1, although Griffiths further teaches determining the trust level associated with the media stream based on the media data, audio data, and video data (see claim 1 rejection above), Griffiths does not explicitly teach wherein the act of determining the trust level associated with the media stream based on the media data comprises determining an artefact parameter indicative of presence of artefacts in one or both of the data, and determining the trust level based on the artefact parameter.
Houser teaches determining an artefact parameter indicative of presence of artefacts in one or both of the data, and determining the trust level based on the artefact parameter (see Houser, [0075]: “The same technology could be embedded in file transfer and terminal emulation technologies (e.g. SSH, SCP, ftp) to determine trustworthiness for logins, to protect file transfers and terminal emulation sessions. By placing trust assertion processing in e-mail gateways, spam can be deflected or routed based on the trust assertions embedded with the message, for example, by mail router trust assertions.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Griffiths in view of Houser by implementing determining an artefact parameter indicative of presence of artefacts in one or both of the data, and determining the trust level based on the artefact parameter. One would be motivated to do so because watermarks, certificates, keys, and so on embedded in messages for authentication is well-known, routine, and conventional.
Conclusion
7. For the reasons above, claims 1-28 have been rejected and remain pending.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
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, Nicholas R Taylor can be reached on 571-272-3889. 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.
/Michael Won/Primary Examiner, Art Unit 2443
Prosecution Insights