Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L43/00—Arrangements for monitoring or testing data switching networks
  • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
  • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/14—Session management
  • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/50—Network services
  • H04L67/535—Tracking the activity of the user
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Definitions

• the present invention generally relates to websites and applications. More specifically, the present invention relates to timestamp-based session association (e.g., of the same device).
• content related to a designated webpage may be downloaded to the user computing device, which may further render the webpage to be displayed.
• Such downloaded content may include a variety of different types of files, including documents, graphics, audio and video, etc., as well as related data (e.g., metadata, stylesheets including cascading stylesheets).
• the downloaded content may be stored in a browser cache in local memory of the computing device.
• Various elements and components of a particular webpage or website may change over time (e.g., as a publisher publishes new or updated content). Some components or elements, however, remain static and unchanged.
• the browser cache allows the computing device to retrieve static, unchanged files related to the associated webpage from local memory, rather than re-downloading the same web objects when a user wishes to revisit the webpage.
• Embodiments of the present invention allow for transmission control protocol (TCP) timestamp-based session association.
• TCP transmission control protocol
• a collection of data packets received during one or more TCP sessions within a time period may be retrieved.
• Each packet in the collection may be associated with a unique identifier of a respective session (i.e., the originating IP address and Port of the session).
• a skew for packets of a selected session within the time period may be determined based on a rate difference between a respective receiving device clock and a respective sending device clock of at least two data packets associated with the unique identifier of the selected session.
• the selected session may be associated with a computing device.
• An uptime may be calculated for each of the retrieved data packets based on the determined skew and respective timestamp information of each data packet. It may be identified as to whether each of the calculated uptimes matches a previously calculated uptime for a packet associated with a previous session or a session that has previously been associated with a selected session. A list of sessions associated with the computing device may be updated based on one or more identified matches between the respective calculated uptime and the previously calculated uptime.
• Various embodiments may include methods for TCP timestamp-based session association. Such methods may include retrieving a collection of data packets received during one or more sessions within a time period where each packet is associated with a unique identifier of a respective session, determining a skew for packets of a selected session (which is associated with a computing device) based on a rate difference between a respective receiving device clock and a respective sending device clock of at least two data packets associated with the unique identifier of the selected session, calculating an uptime for each of the retrieved data packets based on the determined skew and respective timestamp information of the data packet, identifying whether each of the calculated uptimes matches a previously calculated uptime for a packet associated with a previous session or a session that has previously been associated with a selected session, and updating a list of sessions associated with the computing device based on one or more identified matches between the respective calculated uptime and the previously calculated uptime.
• Additional embodiments may include server systems for timestamp-based session association.
• Such systems may include a processor that executes instructions to retrieve a collection of data packets received during one or more sessions within a time period where each packet is associated with a unique identifier of a respective session, to determine a skew for packets of a selected session based on a rate difference between a respective receiving device clock and a respective sending device clock of at least two data packets associated with the unique identifier of the selected session, to calculate an uptime for each of the retrieved data packets based on the determined skew and respective timestamp information of the data packet, and to identify whether each of the calculated uptimes matches a previously calculated uptime for a packet associated with a previous session or a session that has previously been associated with a selected session.
• Such systems may further include memory that stores a list of sessions associated with the computing device where the stored list of session may be updated based on one or more identified matches between the respective calculated uptime and the previously calculated uptime.
• FIGURE 1 illustrates an exemplary network environment in which a system for timestamp-based session association may be implemented.
• FIGURE 2 is a flowchart illustrating a method for timestamp-based session association.
• FIGURE 3 illustrates an exemplary computing system that may be used to implement an embodiment of the present invention.
• Embodiments of the present invention allow for timestamp-based session association.
• a collection of data packets received during one or more sessions within a time period may be retrieved.
• Each packet in the collection may be associated with a unique identifier of a respective session, (e.g., the client IP address and port of the session).
• a skew for a selected session within the time period may be determined based on a rate difference between a respective receiving device clock and a respective sending device clock of at least two data packets associated with the unique identifier of the selected session.
• the selected session may be associated with a computing device.
• An uptime may be calculated for each of the retrieved data packets based on the determined skew and respective timestamp information of the data packet.
• each of the calculated uptimes may be identified as to whether each of the calculated uptimes matches a previously calculated uptime for a packet associated with a previous session or a session that has previously been associated with a selected session.
• a list of sessions associated with the computing device may be updated based on one or more identified matches between the respective calculated uptime and the previously calculated uptime.
• FIGURE 1 illustrates a network environment 100 in which a system for timestamp-based analysis of identifiers may be implemented.
• Network environment 100 may include a communication network 110, one or more user devices 120A-D, server 130, identifier server 140, and one or more service providers 150.
• Devices in network may include a communication network 110, one or more user devices 120A-D, server 130, identifier server 140, and one or more service providers 150.
• environment 100 may communicate with each other via communications network 110.
• Communication network 110 may be a local, proprietary network (e.g., an intranet) and/or may be a part of a larger wide-area network.
• the communications network 110 may be a local area network (LAN), which may be communicatively coupled to a wide area network (WAN) such as the Internet.
• LAN local area network
• WAN wide area network
• IP Internet Protocol
• Examples of network service providers are the public switched telephone network, cellular or mobile service providers, a cable service provider, a provider of digital subscriber line (DSL) services, or a satellite service provider.
• Communications network 110 allows for communication between the various components of network environment 100.
• Users may use any number of different electronic user devices 120A-D, such as general purpose computers, mobile phones, smartphones, smartwatches, wearable devices, personal digital assistants (PDAs), portable computing devices (e.g., laptop, netbook, tablets), desktop computing devices, handheld computing device, or any other type of computing device capable of communicating over communication network 110.
• User devices 120 may also be configured to access data from other storage media, such as local caches, memory cards, or disk drives as may be appropriate in the case of downloaded services.
• User device 120 may include standard hardware computing components such as network and media interfaces, non-transitory computer-readable storage (memory), and processors for executing instructions that may be stored in memory.
• user devices 120 may include a variety of applications, including browser applications that allow the user to request certain webpages and other network accessible data.
• references to browser and browser identifier are exemplary, and teachings regarding the same are applicable to other types of applications and application identifiers (e.g., Apple IDFA, Google AdID).
• a user may enter a uniform resource locator (URL) into a browser application.
• Such a browser may send such request to an associated web server (e.g., server 130), receive responsive data (e.g., webpage file with references to other files to download), and use such responsive data to render and display the requested webpage.
• Webpage files that may be downloaded to the user device 120 may include not only files corresponding to content that is actually displayed as part of the webpage, but also associated files.
• Server 130, identifier server 140, and service providers 150 may include any type of server or other computing device as is known in the art, including standard hardware computing components such as network and media interfaces, non-transitory computer-readable storage (memory), and processors for executing instructions or accessing information that may be stored in memory.
• the functionalities of multiple servers may be integrated into a single server. Any of the aforementioned servers (or an integrated server) may take on certain client-side, cache, or proxy server characteristics. These characteristics may depend on the particular network placement of the server or certain configurations of the server.
• Server 130 may be any kind of server used to host web content, including any type of webpage or website data.
• the particular files associated with each website may be controlled by a publisher (or designated administrator).
• the website file may include links to files under control by other parties.
• the website files downloaded from server 130 may include a reference (e.g., URL) to an identifier file, as well as an optional loader application (e.g., Javascript commands) and associated code library to be used with the identifier file.
• identifier file may be specific to the website.
• an identifier for a particular website may include or otherwise be based on a domain (or other characteristic) of that website.
• each website visited by a particular user device using a particular browser (or other application) may be associated with a unique and different identifier.
• Such identifier may be generated and managed in manners similar to those disclosed with respect to the browser identifiers disclosed in related co-pending U.S. patent application number 14/716,187, the disclosure of which is incorporated by reference herein. Moreover, the browser identifiers disclosed herein may be used in conjunction with the disclosed invention of related U.S. patent application number 14/716,187.
• a browser identifier may be associated with different browser sessions on a device. Because different browser and different browser sessions may be used on the same device, various indicators (e.g., timestamp) may be used to associate such different browsers and sessions to a common device. Further, each session may likewise be associated with certain identifiers, including TLS session identifier, TLS session ticket, etc., as discussed below.
• the identifier server 140 may further be able to draw associations between the various identifiers (e.g., session identifiers, browser identifiers, device identifiers).
• a particular user device 120 (as identified by a device identifier) may be associated with one or more sessions and browsers (or other applications).
• the identifier server 140 may therefore be capable of identifying one or more such identifiers (whether website, browser, session, or device) based on examination of received data packets.
• the identifier server 140 may store associations between various indicators by creating and updating tables.
• SSL sessions may allow for session resumption, which occurs where a client and server negotiates SSL information and then later reuses that negotiated SSL information for future connections.
• SSL session setup is generally very time-consuming, so not having to renegotiate is therefore desirable.
• a client In order to resume a session, a client must be able to identify the session.
• SSL session IDs and TLS session tickets are two mechanisms that allow for the identification and resumption of a previously selected session.
• Additional indicators may be based on use of transmission control protocol
• TCP Transmission Control Protocol
• TCP Internet Protocol
• Information associated with use of TCP by a particular device may be inclusive or indicative of various timestamp information.
• Other time-related information may be associated with a TCP packet, including current time, uptime, and clock skew.
• the identifier server 140 may receive a packet (e.g., associated with TCP timestamp information, such as a particular current time, uptime, source IP address, clock skew) of a selected session, determine whether the associated timestamp information (e.g., uptime) of a packet matches any timestamp information of a previously received packet that may be associated with a selected session, and if so, drawing an association between the sessions. Further, a stored packet list may be maintained with associated identifiers or other indicators that may be used to make associations among different identifiers (e.g., different device identifiers for the same device).
• a packet e.g., associated with TCP timestamp information, such as a particular current time, uptime, source IP address, clock skew
• the associated timestamp information e.g., uptime
• a stored packet list may be maintained with associated identifiers or other indicators that may be used to make associations among different identifiers (e.g., different device identifier
• client timestamp is generally included in the TCP packet and server timestamp is generally added automatically when the TCP packet is received by the server, further calculations may also be applied to determine other timestamp related information (e.g., uptime and clock skew).
• the client timestamp for example, provides a measure of time typically reflective of the elapsed time since a computing device was started and continuously working.
• the calculated uptime when the device was last started may be able to uniquely identify a particular device as all packets for that device received within some window of time of each other would share the same calculated uptime.
• a device may record and report an elapsed time since the last time the device was started or the elapsed time was reset. That elapsed time may reset based on different schedules for different computing devices (e.g., some devices reset every few days and others reset every few weeks). Elapsed time may increment with a different granularity for different devices and operating systems. The granularity of the increment is measured in ticks. A tick may also represent a different amount of time for different systems, so there may be some device- specific calculations involved to determine type of device by determining the amount of time represented by a tick. The result is a timestamp that is incrementing consistently in real time. Calculating that backwards provides the uptime, which may be the time the device was last started or the last time the timestamp was reset. As such, the uptime generally remains the same even elapsed time increases, until such time that the timestamp is reset.
• Such indicators used by identifier server 140 may therefore include session identifiers (e.g., transport layer security (TLS), secure sockets layer (SSL)), transmission control protocol (TCP) identifiers (e.g., uptime, current time, clock skew), internet protocol (IP) address, user agent identifiers, and others.
• session identifiers e.g., transport layer security (TLS), secure sockets layer (SSL)
• TCP transmission control protocol
• IP internet protocol
• Such indicators may be used individually or in any combination (e.g., SSL session identifier and TCP timestamp) to identify a particular common browser and/or a particular user device 120 based on common matches.
• An exemplary embodiment may select a certain set of indicators based on their respective deterministic value in identifying connections between identifiers for different browsers or devices.
• a SSL session identifier is unique to a collection of one or more sessions and can therefore be used to associate different browser identifiers for the same browser together.
• the combination of current time, uptime, clock skew, and source IP address is unique to a particular device, thereby allowing for connections to be drawn between different identifiers associated with the device.
• a particular request to download website may refer to an identifier that is associated with one or more indicators (e.g., SSL session identifier).
• Such SSL session identiner may be compared to stored information and determined by identifier server 140 as having been previously used in conjunction with the same or different browser identifier and/or device identifier.
• an uptime associated with the requesting computing device may be determined by identifier server 140 as having been previously identified or used in conjunction with the same or other browser identifiers and/or device identifiers.
• Information regarding identifiers may be stored in a table, which may further include a list of identifiers determined to be associated with the same browser, application, session, or device. Where no stored table existed for the referenced identifier (or any of its associated indicators or identifiers), a new table may be created. Where a stored table does exist, such stored table may be updated. As such, tables having one or more of these identifiers may be created and updated based on newly incoming identifiers (associated with certain indicators) and matches with stored identifiers (associated with the same or different indicators).
• the identiner server 140 may determine that the respective sessions are originating from the same device.
• the lifespans, availability, and uniqueness of each indicator may vary across different browsers, user agents, and/or operating systems. As such, indicators may be used in combination to exclude certain devices, for example, thereby facilitating the search for a match.
• a first party cookie may be used as the persistent identifier for each website. Although a cookie may persist for a time, such cookie may be changed periodically. Thereafter, various matching parameters (e.g., SSL and uptime) may be used to identify and to draw associated cookies together as described in further detail below.
• the identifier server 140 should be understood as having the ability to use any persistent identifier to associate to other persistent identifiers. Over time, therefore, the tables constructed by the identifier server 140 may grow to identify new connections and associations between various identifiers.
• Service providers 150 may include servers or other computing devices that may provide various services based on identification of a browser. For example, a service provider 140 may use information regarding repeat visits to provide targeted advertising to repeat visitors (versus first-time visitors).
• FIGURE 2 is a flowchart illustrating an exemplary method 200 for timestamp- based session association.
• the method 200 of FIGURE 2 may be embodied as executable instructions in a non-transitory computer readable storage medium including but not limited to a CD, DVD, or non-volatile memory such as a hard drive.
• the instructions of the storage medium may be executed by a processor (or processors) to cause various hardware components of a computing device hosting or otherwise accessing the storage medium to effectuate the method.
• the steps identified in FIGURE 2 (and the order thereof) are exemplary and may include various alternatives, equivalents, or derivations thereof including but not limited to the order of execution of the same.
• Method 200 may be used to allow for timestamp-based session association despite various network anomalies and inconsistencies that may occur over time.
• Timestamp-based metrics—including skew— may therefore seem to vary.
• method 200 may evaluate packets that are received over time. Such packets may be associated with a unique identifier for a session of a device 120. Identifying uptime matches may then allow for identification that multiple sessions belong to the same device 120 (e.g., based on common uptime s) despite being associated with different device identifiers, browser identifiers, TLS Session IDs, user agents, etc..
• the steps are illustrated and described in sequence, some steps may be performed concurrently or in a different order.
• data packets may be retrieved from a data store for a predefined window of time (e.g., 24 hours).
• Data packets may be sent from one or more of the user devices 120A-D operating a network-enabled application, such as a browser, and are received and captured at identifier server 140. Over the course of the predefined window of time, further, data packets associated with different sessions may have been received.
• Each data packet may include various identifiers, including IP address, port, computing device timestamp, server timestamp, device identifier, browser identifier, user agent, operating system and version, session information (start time) and other information.
• the period of time during which the data packets are captured may be configurable.
• the retrieved data packets may be sorted by time of receipt (e.g., from most recently received to oldest) as indicated by the server timestamp.
• step 215 the set of packets being evaluated may be filtered based on various factors, including session, device of origin, time of receipt (e.g., last 24 hours), etc. Data packets not meeting the parameters of interest may be discarded from further evaluation. For example, in step 220, data packets may be filtered out based on not having any timestamp information. Further, the set of packets may be refined based on time of receipt in steps 230 (too recent) and 235 (too old).
• packets may also be discarded from evaluation for being outliers. Further, anomalies may arise when a computing device goes into sleep mode during which the clock may run much more slowly. Outlier packets may be identified based on falling into a predetermined percentile (e.g., 95th percentile) with respect to difference between computing device timestamps and server timestamps. If the difference is much larger than expected (e.g., 95th percentile), for example, the packet may not be selected for inclusion in calculations and comparisons.
• a predetermined percentile e.g., 95th percentile
• the list of packets After the list of packets has been filtered, two packets are selected for analysis with respect to skew. Because network latency may not be constant, selecting different sets of packets may result in different skew values due to variations in when the server receives a packet (which results in variable differences between computing device timestamp and server timestamps).
• the selected packets may be the most recently received packet and the next most recently received packet that was received at least a predetermined time period (e.g., at least one second) from receipt of the most recently received packet. In other implementations, the most recently received packet and the oldest received packet may be selected. [0038] In step 240, the most recently received packet in the retrieved list is set as the last known packet.
• step 245 the next most recently received packet may be searched for that was received at least a predetermined minimum of time (e.g., at least one second later) from receipt of the last known packet.
• step 250 it may be determined whether the next packet was found. If not, the method exits without any device matches. If the next packet was found, the method process to step 255.
• a skew may be calculated.
• the data packets received from the same session or identifier may be further analyzed together (e.g., two data packets received at least a predetermined time interval apart).
• Each data packet is associated with a computing device (client) timestamp and a server timestamp.
• the computing device timestamp is placed in the packet by the computing device 120 under TCP protocol.
• the computing device timestamp represents an amount of time since the computing device was restarted (or the timestamp reached is maximum value and rolled over).
• the server timestamp is the actual time that the packet was received according to the server clock. Both the server timestamp and the computing device timestamp advance in real time.
• skew may represent the speed at which a client (e.g.,
• a skew value may be a difference in the rate of advance of the client timestamp and the server timestamp, which may be due to differences in CPU architecture, clock speed, and other differences between the client and the server.
• an uptime may be calculated for each packet.
• uptime represents an amount of time since the client (e.g., computing device) timestamp was at zero.
• each data packet being evaluated may be associated with an uptime.
• the first packet in the set e.g., where there is no previously received packet
• skew may be calculated for different sets of packets and then averaged for use in calculating uptime.
• step 275 it may be determined whether the session identifier associated with the next packet is found in the known session list. If yes, the method proceeds to step 280, in which the next packet is designated the last known packet. If the session identifier associated with the next packet is not found in the known session list, the method proceeds to step 285, in which it may be determined whether the uptime of the next packet matches the uptime of the last known packet. A match may be found when two uptime values are within a predefined range. As such, minor variations may nevertheless result in a match. A match indicates that the associated data packets likely originated from the same device. If an uptime match is found, the method proceeds to step 280, in which the next packet is designated the last known packet.
• step 290 it may be determined whether there is another packet in the retrieved list. If yes, the method reverts back to step 265, in which another next packet in the list may be obtained for evaluation. If there is no other packet in the list, the method may exit with an updated known session list, which may be used to update various databases with respect to the newly determined matches between different session identifiers.
• Such updates may include merging of various fields (e.g., in stored table) to include information regarding the data packets having a uptime matching a primary uptime associated with the stored table, which may be associated with a device identifier. As such, multiple identifiers may be determined to be associated with the same device, and information regarding the different identifiers may be incorporate or otherwise merged into a combined record that corresponds to a common device.
• a primary uptime may be designated. Where multiple uptimes have been calculated for a device (as identified by one or more device identifiers), one uptime may be selected to be designated as the primary uptime for the table. For example, the most recently calculated uptime associated with the device may be designated as the primary uptime, which may then be used for comparison with subsequently calculated uptimes. As such, the primary uptime associated with a specific device may be maintained and updated as necessary in light of network anomalies and jitter effects.
• the method 200 may be iterated
• n the index of the packet in the array
• k the index of the last packet for the known device
• sessionList is a list of all session that have been determined to be the same device as the initial known session (including the initial known session to start)
• matches refers to values that are within a predetermined, configurable time period.
• FIGURE 3 illustrates an exemplary computing system 300 that may be used to implement an embodiment of the present invention.
• System 300 of FIGURE 3 may be implemented in the contexts of the likes of user devices 120A-D, server 130, identifier server 140, and service provider 150.
• the computing system 300 of FIGURE 3 includes one or more processors 310 and memory 310.
• Main memory 310 stores, in part, instructions and data for execution by processor 310.
• Main memory 310 can store the executable code when in operation.
• the system 300 of FIGURE 3 further includes a mass storage device 330, portable storage medium drive(s) 340, output devices 350, user input devices 360, a graphics display 370, and peripheral devices 380.
• FIGURE 3 The components shown in FIGURE 3 are depicted as being connected via a single bus 390. However, the components may be connected through one or more data transport means.
• processor unit 310 and main memory 310 may be connected via a local microprocessor bus 390, and the mass storage device 330, peripheral device(s) 380, portable storage device 340, and display system 370 may be connected via one or more input/output (1/0) buses 390.
• Mass storage device 330 which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 310. Mass storage device 330 can store the system software for implementing embodiments of the present invention for purposes of loading that software into main memory 310.
• Portable storage device 340 operates in conjunction with a portable nonvolatile storage medium, such as a floppy disk, compact disk (CD) or digital video disc (DVD), to input and output data and code to and from the computer system 300 of FIGURE 3.
• a portable nonvolatile storage medium such as a floppy disk, compact disk (CD) or digital video disc (DVD)
• CD compact disk
• DVD digital video disc
• the system software for implementing embodiments of the present invention may be stored on such a portable medium and input to the computer system 300 via the portable storage device 340.
• Input devices 360 provide a portion of a user interface.
• Input devices 360 may include an alpha-numeric keypad, such as a keyboard, for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys.
• a pointing device such as a mouse, a trackball, stylus, or cursor direction keys.
• the system 300 as shown in FIGURE 3 includes output devices 350. Examples of suitable output devices include speakers, printers, network interfaces, and monitors.
• Display system 370 may include a liquid crystal display (LCD) or other suitable display device.
• Display system 370 receives textual and graphical information, and processes the information for output to the display device.
• LCD liquid crystal display
• Peripherals 380 may include any type of computer support device to add additional functionality to the computer system.
• peripheral device(s) 380 may include a modem or a router.
• the components contained in the computer system 300 of FIGURE 3 are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent a broad category of such computer components that are well known in the art.
• the computer system 300 of FIGURE 3 can be a personal computer, hand held computing device, telephone, mobile computing device, workstation, server, minicomputer, mainframe computer, or any other computing device.
• the computer can also include different bus configurations, networked platforms, multiprocessor platforms, etc.
• Various operating systems can be used including Unix, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems.
• Non-transitory computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit (CPU) for execution. Such media can take many forms, including, but not limited to, non-volatile and volatile media such as optical or magnetic disks and dynamic memory, respectively. Common forms of non-transitory computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, RAM, PROM, EPROM, a FLASHEPROM, and any other memory chip or cartridge.
• a bus (e.g., bus 390) carries the data to system RAM, from which a CPU retrieves and executes the instructions.
• the instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
• Various forms of storage may likewise be implemented as well as the necessary network interfaces and network topologies to implement the same.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Health & Medical Sciences (AREA)
• Cardiology (AREA)
• General Health & Medical Sciences (AREA)
• Computer Hardware Design (AREA)
• General Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer And Data Communications (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (1)

Family

ID=63583720

Family Applications (1)

Country Status (4)

Cited By (3)

Families Citing this family (4)

Citations (6)

Family Cites Families (28)

• 2017
  • 2017-03-24 US US15/469,162 patent/US10715413B2/en active Active - Reinstated
• 2018
  • 2018-03-19 EP EP18770352.5A patent/EP3602970A4/en not_active Withdrawn
  • 2018-03-19 WO PCT/US2018/023177 patent/WO2018175342A1/en not_active Ceased
  • 2018-03-19 JP JP2019552566A patent/JP7130659B2/ja active Active

Patent Citations (6)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events